概念数据建模:如何阅读递归的多对多关系

时间:2016-11-08 03:17:25

标签: database-design data-modeling rdbms erd conceptual-model

我理解像下面那样的简单二元关系会从左到右阅读:用户“可能”有一张或多张图片。此外,如果你从右到左阅读它将是...图像“必须”属于一个且只有一个用户。 enter image description here

然而,当我看到以下内容时,我有点困惑。谁能告诉我你是怎么读这种关系的?另外,在下面右边的图像中,他们说同样的事情是不同的吗? enter image description here

enter image description here

最后,在这种递归关系中,用户可以成为另一个用户的朋友,是否有意义将两端指定为可选的多个,或者应该是一个必须和多个?

我看到的方式是,如果用户可以拥有零个或多个朋友而不是另一个朋友,那么它应该有一个或多个朋友,因为如果用户A是用户B的朋友,则用户B不再有零选项朋友。这个假设是正确的还是我错了?

任何想法都会有所帮助我只是阅读一本关于概念数据建模的书,并且在我继续学习实际表格之前真的想要理解这一点。

2 个答案:

答案 0 :(得分:4)

是的,这两张图显示了同样的事情。

有些人选择在概念图中留下未解决的多对多关系。一些描述这种关系的文字可能会有所帮助(我建议像"是#34的朋友;)。然后,我将其视为"用户可能是其他用户的朋友。"

第二张图显示了您决定解决多对多关系时所绘制的内容。有些人将其留下来进行逻辑建模,当你阅读它时,你会遇到相同的结构(在学习概念建模之后,我会建议这是下一步)。我会将用户和友谊之间的关系看作是"用户可能有友谊。"

这些关系始终是可选的,因为您要对大图进行建模,而不是一个特定的实例。在右侧显示为非可选项将表示每个用户必须在数据库中的友谊表的第二列中至少有一个条目,您最终会从此模型 - 那不是真的。

顺便说一句,我认为你读这篇文章真是值得称赞(太多的人建立数据库而没有试图掌握概念或逻辑建模!)。在尝试学习你所学的东西之前,我不会担心等到你觉得你完全理解它之后;一旦您将这些想法投入到您已经知道的真实数据中,这些想法可能会更有意义。如果您还没有学习,请尝试根据您自己的数据勾勒出概念图。

答案 1 :(得分:2)

这里有很多需要解开的东西。 Jo Douglass的答案涵盖了很多方面。

我相信你的一部分困惑来自于人们使用ER图来描绘两种截然不同的模型。第一个是实体关系模型,更好地称为ER模型。第二个是关系模型。从表面上看,这两个型号看起来几乎相同。但它们具有不同的功能,它们是为不同目的而构建的。

ER模型可以促进数据库设计者和主题专家之间的通信。主题专家可能对数据有深刻的理解:它看起来是什么,它意味着什么,它为什么重要,以及它是如何被使用的。同一主题专家可能对外键,参照完整性或数据规范化等技术主题几乎没有兴趣。

对于打算在一个流行的SQL数据库(如SQL Server,Oracle或其他数据库)中设计和构建数据库的设计人员而言,关系模型是一个很好的初步结果。

您的上一个图表,只有标有“用户”的框,非常简洁明了。它突出了这种关系的多对多性质。它在ER模型中完全有效,但关系建模师会告诉您它不合法,并且需要一个接线盒。

但确实没有这个关系的名称,即友谊。如果您可能有两个相同的关系,则命名关系很有用。它还为您提供了挂起属性的名称。在某些情况下,您可能会对给定友谊开始的日期感兴趣。

关系是强制性还是可选性可能取决于您是分析主题还是设计解决方案。如果是第一个,您可以查看主题,了解它是否是强制性的。在这里的技术专家无法为您回答这个问题,因为即使我们认为我们做了,我们也不会了解您的主题。

如果您正在设计解决方案,您可能希望从不同的角度来看待它。你是否过度约束数据?你不受约束吗?

我希望这可以解决你正在努力解决的问题。数据库设计并不复杂。但它很抽象。