关系架构与ER图/基数的差异

Question

如果我们有一个 ER图，并且想要转换为关系模式，我们将遵循特定的过程（例如Elmashri和Navathe书）。 我不清楚的是，当基数为 1：1对1：N 时是否存在差异。关系模式如何体现这种差异？

例如，在下图的Elmashri中，如果我们关注基数为1：N的Department-Project之间的关系，我们将采用以下关系模式。 如果基数为1：1，会有区别吗？

直接问一下：在下图中，如果有人只给我带有关系模式的左半部分，我怎么说两个关系（黑圈和红圈）是1：1还是1：N？

Answer 1

从ER和伪ER重新映射到关系

那是Chen风格的ER图。菱形表示关系（船）/关联，并具有相应的表/关系。线表示参加者并具有相应的FK。红衣主教是关于钻石的，即关系/关系/表/关系。他们告诉您有关实体的哪些组合可以参与关系/关系的某些信息。

您的教科书是Elmashri＆Navathe撰写的《数据库系统基础》第7版。它遵循上述用法并解释如何映射X：Y：etc并特别解释如何映射您的示例。 DDL可以通过将ERD映射到明显的“交叉引用” /“关系”表然后组合它们而产生。但是您的教科书只是提供了多种映射X：Y的方法，而没有清楚地说明快捷方式是如何通过明显的方式加组合而产生的。

例如：查询值select Dnum, Pnum from PROJECT的表表示“对于某些Pname和Plocation，部门Dnum控制项目Pnum”的二进制关系-大概在“部门Dnum控制项目Pnum”时正确。 -这是部门和项目上的关系控制。 ER图表明，相应的二进制关系在Dnum：Pnum中为1：N，在Pnum：Dnum中为N：1。 由于 CONTROLS在基数上具有特定的1，因此可以将其明显的表 与PROJECT实体表合并为表PROJECT。如果是M：N，则合并将存在某些问题，因此您的文本将给出不同的映射关系-但在以前的假设下，它仍然可能是 。而且，如果您这样做或只使用了明显的映射，则对于1：N和M：N，您的关系设计将是相同的。 1：1允许其他组合。

不同的设计和制图方法对于基数和关系映射有不同的约定。许多所谓的ER方法并不是真正的ER，因为它们只是ER的微不足道-一切都是（可能是）关联的实体。所有行的一端或两端都涉及1或1-或0-因为它们是与FK相关的某些隐式二进制关系和表-就像按上述方式组合明显的Chen表那样。也有“在这里看”和“在外看”基数以及其他约定，例如显式空FK。一切都取决于您使用的是什么教科书/参考书/方法。

您的DDL图“关系”是FK，但被伪ER方法错误地但普遍地称为“关系”。您没有在DDL图中有意义地使用“ X：Y”。您正在或多或少地使用它，伪ER图将如何标记FK。但基数是关于由FK参考表的某个投影表示的关系（船）/关联。

从关系到ER和伪ER的重新映射

如果您从Chen ER设计开始并且仅使用明显的映射，那么您将具有实体和关系的表1：1，而实体表将是没有FK的表。但是您的教科书有多种映射选择，涉及将ER图实体和关系表以多种方式组合到其他表中，因此数据库中的表不会告诉您它们来自的图实体和关系。

关系设计比Chen ER设计更笼统-表代表0个或更多值上的关系。 （每个基表和查询结果的每个超键都标识一个实体。）因此，并非所有合理的关系设计都对应于Chen ER设计。伪ER方法的一个好处是，它们实际上是在记录DDL，而不是区分实体和关系。但是，如果它们确实来自未记录在设计中的实体和关系。因此，您不能从这种关系/伪ER设计中映射回这些实体和关系。

除非您将DDL约束放入基数中，否则您将不知道基数，最好以声明性的方式将其放入-否则会触发。 FK和CK（通过PK和UNIQUE NOT NULL）足以表示二进制关系（船）/关联的Chen基数约束，但不是n元。伪ER方法可能会也可能不会解决超出PK和CK的约束。而且Chen ER的设计可能存在一些问题约束，必须通过一般的关系设计原则来解决-所以实际上它们只是临时的。 （而且-不必要。）

What is the difference between an entity relationship model and a relational model?