database-design - 概念数据建模 : How to read a recursive many to many relationship

Question

我理解像下面这样的简单二元关系将从左到右阅读:用户“可能”拥有一张或多张图片。另外，如果您从右到左阅读它，则将是……图像“必须”属于一个且仅属于一个用户。

但是，当我看到以下内容时，我有点困惑。谁能告诉我您如何看待这种关系？另外，在下图后面的图片中，他们说的是同一件事，只是不同吗？

最后，在这种用户可以成为另一个用户的 friend 的递归关系中，将两端都指定为可选的许多有意义吗？或者一个应该是必须的吗？

我的看法是，如果一个用户可以有零个或多个 friend ，那么另一端应该有一个或多个 friend ，因为如果用户 A 是用户 B 的 friend ，那么用户 B 不再有零个选项 friend 们。这个假设是正确的还是我错了？

任何想法都会有所帮助，我刚刚通读了一本关于概念数据建模的书，并且在我继续进行实际表格练习之前真的很想了解这一点。

Answer 1

是的，这两个图显示的是同一件事。

有些人选择在概念图中留下 Unresolved 多对多关系。描述这种关系的一些文字可能会有所帮助(我建议使用“是 friend ”之类的内容)。然后我将其解读为“一个用户可能与其他用户成为 friend ”。

第二张图显示了如果您改为决定解决多对多关系，您将绘制什么。有些人将其保留到逻辑建模，当您阅读它时您会遇到相同的构造(我建议在学习概念建模后将其作为下一步)。我会将 User 和 Friendship 之间的关系理解为“一个 User 可能有 Friendships”。

这些关系始终是可选的，因为您要建模的是大局，而不是某个特定实例。在右侧将其显示为非可选表示每个用户必须在您最终从该模型创建的数据库中的 Friendship 表的第二列中至少有一个条目 -这不是真的。

顺便说一句，我认为您正在阅读这篇文章真的值得称赞(太多人在构建数据库时从未尝试掌握概念或逻辑建模!)。不过，我不担心等到您觉得自己完全理解它后再尝试所学的内容；一旦您将某些想法付诸实践，并根据您已知的真实数据进行实践，其中一些想法可能会更有意义。如果您还没有，请在学习的同时尝试根据您自己的数据绘制概念图。