在以下情况下，我很难理解何时在实体之间建立关系：
如果我有一些具有外键的实体，比如一个名为 node_id 的字段，它代表一个便笺的 id 和一个便笺实体，是否有必要在这些实体之间建立关系？
【问题讨论】：
标签： sql foreign-keys schema relational-database
您似乎对实体、关系、图表、表格和 FK 感到困惑。
在这种风格的 ER 图（原始）中，方框代表实体类型，菱形代表关系/关联类型。 （ER 中的“R”表示关联意义上的“关系”。）每种类型都有一个表。从菱形到方框的线表示关联中引用的实体的参与。它们对应于引用实体表的关联表中的 FK。
注意：根据信息建模方法或其表示，“关系”有时表示“关联”，有时表示“外键”，有时表示在此图中中间有关联菱形的线风格。
（一些图表方法允许“关联实体”。关联实体是由某个关联中的参与者列表形成的。这样的实体可以参与进一步的关联。这对应于由来自进一步关联的表到原始的。这意味着不仅形成关联实体的实体必须参与进一步的关联，而且它们还必须参与原始关联。没有关联实体，图表无法表达这一点。当你用图表参与关联实体在进一步关联中的关系，您不需要也明确表达其组成实体在进一步关联中的直接参与。也不需要相应的直接 FK。）
【讨论】：
在实体关系模型中，外键约束强制关系中实体集的类型。因此，如果您有 FK，则意味着也有关系。不过不要混淆这两者 - FK 是强制一个实体集的二元子集关系，关系是可以涉及多个不同实体集（和多个 FK 约束）的 n 元关系。
您的示例描述了与注释的显式关系，应在图表中指出。
【讨论】：
如果您将字段设置为外键，则您已经在数据库中的两个表之间设置了关系，所以我假设您的问题只是关于架构表示。
答案是肯定的。如果您有从表 A 到表 B 的外键，则意味着表 A 中的行与表 B 有连接，并且在您的架构中，您需要指定并可视化此连接。
架构很有用，因为它们可以快速准确地解释您的数据库结构，如果您省略了关系，阅读您的架构的人可能不明白为什么会有一些字段，或者可能找不到创建查询的最佳方法需要关系。
错误的架构或不完整的架构真的没用
【讨论】：