关系数据库模式 - 关系键和外键

Question

我有一个很难理解时，在下列情况下，实体之间的关系：

如果我有一些实体，其有一个外键，说一个字段中指定NODE_ID ，它代表一个票据的id和一个Notes实体，是否有必要在这些实体之间建立关系？

这里是我的架构的一个子集，如果设置一个字段作为您已经设置在数据库中的两个表之间的关系外键，这可能是更明确

Answer 1

，所以我想你的问题是只关于模式表示。

答案是肯定的。如果你有一个从表A到表B的外键，这意味着表A中的行与表B有连接，并且在你的模式中你需要指定和显示这个连接。

模式是有用的，因为它们给出了对数据库结构的快速和准确的解释，如果您省略了关系，读过您计划的人可能不明白为什么有一些字段或者可能找不到创建查询所需的最佳方法那种关系。

一个错误的模式或不完整的架构是真没用

Answer 2

你似乎混淆了实体，关系，图表，表格和FKS。

在这种风格的ER图（原件）中，盒子用于物体类型，钻石用于关系/关联类型。 （ER中的“R”意味着关系中的“关系”。）每种类型都有一张表格。从菱形到框的线表示参照实体参与关联。它们对应于引用实体表的关联表中的FK。

请注意：根据信息建模方法或其表示方式，“关系”有时候意味着“关联”，有时意味着“外键”，有时意味着一条在其中间会有关联钻石的行图样式。 （某些图表方法允许“关联实体”，一个关联实体是由一些关联中的参与者列表形成的，这样一个实体可以参与进一步的关联，这对应于由实体id组成的复合FK，这意味着不仅要组成关联实体的实体参与进一步关联，而且还必须参与原始关联，没有关联实体，关系图就不能表达这种关系。协会实体参与进一步的协会，您不需要明确表示其组成实体直接参与进一步的协会，也不需要相应的直接FKs）

Answer 3

在实体关系模型中，外键约束强制关系中设置的实体的类型。因此，如果您有FK，那意味着它们之间也存在关系。不要混淆两者，但 - FK是一个二元子集关系，它强制实施一个实体集合，一个关系是一个n元关系，可能涉及多个不同的实体集合（以及多个FK约束）。

您的示例描述了应该在您的图表中指出的与Notes的显式关系。