我知道像下面这样的简单二元关系将从左到右读取：用户“可能”拥有一张或多张图片。此外，如果您从右到左阅读它会是......图像“必须”属于一个且只有一个用户。
但是，当我看到以下内容时，我会感到有些困惑。谁能告诉我你是怎么理解这种关系的？此外，在右下方的图片中，他们说的是同一件事，只是不同吗？
最后，在这种递归关系中，一个用户可以是另一个用户的朋友，将两端指定为可选的 many 是否有意义，或者一个必须是必须的和 many？
我看到的方式是，如果一个用户可以有零个或多个朋友，而不是另一端它应该有一个或多个朋友，因为如果用户 A 是用户 B 的朋友，那么用户 B 不再有零个朋友的选项。这个假设是正确的还是我错了？
任何想法都会对我只是阅读一本关于概念数据建模的书有所帮助，并且在我继续在真实表格上练习之前真的想了解这一点。
是的，这两个图表显示的是同一件事。
有些人选择在概念图中留下未解决的多对多关系。一些描述这种关系的文字可能会有所帮助（我建议使用“是朋友”之类的内容）。然后，我会将其解读为“用户可能与其他用户成为朋友”。
第二个图显示了如果您决定解决多对多关系，您将绘制什么。有些人把它留到逻辑建模之前，当你阅读它时你会遇到相同的构造（我建议在学习概念建模之后作为下一步）。我会将用户和友谊之间的关系解读为“用户可能有友谊”。
这些关系始终是可选的，因为您正在对全局进行建模，而不是对一个特定实例进行建模。在右侧将其显示为非可选表示每个用户必须在您最终使用此模型创建的数据库的友谊表的第二列中至少有一个条目 - 这不是真的。
顺便说一句，我认为您正在阅读这篇文章真的值得称赞（太多人构建数据库而没有尝试掌握概念或逻辑建模！）。不过，我不会担心等到您觉得自己完全理解它之后再尝试您正在学习的内容；一旦您将一些想法付诸实践，您已经知道这些想法可能会更有意义。如果您还没有，请在学习时尝试根据您自己的数据绘制概念图。
这里有很多东西要解开。Jo Douglass 的回答涵盖了很多方面。
我相信您的部分困惑来自于人们使用 ER 图来描述两种截然不同的模型。第一个是实体关系模型，更广为人知的是 ER 模型。第二个是关系模型。从表面上看，这两个模型看起来几乎相同。但是它们具有不同的功能，并且它们是为不同的目的而构建的。
ER 模型可以促进数据库设计者和主题专家之间的交流。主题专家可能对数据有深刻的理解：它看起来像什么，它意味着什么，为什么它很重要，以及如何使用它。同一位主题专家可能对外键、参照完整性或数据规范化等技术主题几乎没有兴趣。
对于打算在流行的 SQL 数据库之一（如 SQL Server、Oracle 或其他几十个数据库）中设计和构建数据库的设计人员来说，关系模型是一个很好的初步结果。
您的最后一张图，只有标有用户的框，非常简洁明了。它突出了关系的多对多性质。它在 ER 模型中完全有效，但关系建模者会告诉您它不合法，并且需要一个接线盒。
但是，它确实缺少这种关系的名称，即友谊。如果您可能有两个在其他方面相同的关系，则命名关系很有用。它还为您提供了一个名称来挂起属性。在某些情况下，您可能对特定友谊开始的日期感兴趣。
这种关系是强制性的还是可选的，可能取决于您是在分析主题，还是在设计解决方案。如果它是其中的第一个，您可以查看主题以了解它是否是强制性的。这里的技术专家无法为您回答问题，因为我们不知道您的主题，即使我们认为我们知道。
如果您正在设计解决方案，您可能希望从不同的角度来看待它。您是否过度约束数据？你是不是太压抑了？
我希望这能解决你正在努力解决的一些问题。数据库设计并不复杂。但它是抽象的。