试图理解实体关系图中的基数？答案

【问题标题】：Trying to understand cardinality in an entity relationship diagram?试图理解实体关系图中的基数？
【发布时间】：2015-12-23 02:26:26
【问题描述】：

我对关系数据库很陌生，最近在试图理解我得到的实体关系图时遇到了很多麻烦。

这里是：Solicitor ERD（ERD 是为一个虚构的律师公司）

基本上我的任务是获取这个 ERD 并编写一个 SQL 脚本来创建数据库，显然用我可以组成的数据填充表。 SQL 语法不是我难以理解的东西，它只是理解图中的基数。

对我来说，“1 对 1”、“1 对多”、“多对多”这些术语只是不点击，我不知道它们的含义以及它们如何影响主键和外键的位置。

我可以使用这些表并轻松创建相关列，例如，我知道“client”表将包含“client_name”之类的内容。但是，当谈到将“client”表与“case”表链接时，我怎么知道外键的去向？

“client”表是否会包含“case”表中的“caseID”以及包含“client”表中的“clientID”的“case”表？还是只有一张表有外键？就是这样的事情我就是不明白。

很抱歉这篇长文，如果有人能用简单的英语解释我如何开发这个 ERD，那将不胜感激！我已经困惑了两天了:(

【问题讨论】：

一个有趣且呈现良好的 Q，但基本上您要求的是教程，这对于 StackOverflow 来说是题外话。请阅读stackoverflow.com/help/mcve 以了解 S.O. 的正确范围 Q。 ...投票结束（不情愿地，你在下面有很好的答案）。祝你好运。

标签： database oracle diagram erd cardinality

【解决方案1】：

ERD 是一个很棒的工具，我相信一旦你开始了解它们，你就会同意。

关系对于执行始终很重要。在您的数据库中，客户和案例之间的关系是一对多。这意味着每个案例必须有一个且只有一个客户，但每个客户必须至少有一个案例，但他们可以有很多。在这种情况下，每个客户端都应该有一个 client_id，它是主键并且必须是唯一的等。这将在案例表中作为外键引用，以便案例表对于每个案例都有一个 client_id。这将强制两个表之间的一对多关系。

正如您所见，此图中的大多数关系都是一对多的，这就是设计良好的数据库应该如何强制引用完整性。唯一的不一致是案例和公司案例之间的关系，其中关系是 1 到 0 或 1。这意味着一个案例可能没有分配给它的公司，如果有，它必须只有 1。在这个案例我建议在公司案例中使用 PK 并将其链接到 FK 以防万一。

如果您需要有关这些关系如何翻译成英文的更多信息，此页面可能会有所帮助 http://www.informit.com/articles/article.aspx?p=27281&seqNum=3

祝你好运。

【讨论】：

感谢他们的帮助，我很感激。理解这些关系现在确实更有意义了。我试图在 Access 中制作关系图只是为了让我了解一些事情。我只是想知道您是否可以快速查看一下并确认我是否做对了？ Diagram谢谢
我已经对您的 Access 图进行了非常简短的查看，大部分情况下它看起来都不错。只需提及您从案例到公司案例的关系应该是 1 到 0 或 1 不是多到 1。可以使用两个外键创建此表，一个来自案例，一个来自公司。由于案例与公司案例的关系，这些键的组合应该始终是唯一的，这有时被称为复合键。

【解决方案2】：

这种风格的图表

每个框都有一个实体类型/类/集和表，每个标记线都有一个关系类型/类/集和表。

线的末端指向参与关系类型的实体类型。您需要了解在应用程序域方面的实体和关系是什么。表格的一行代表一个实体/关系实例。每个端点都有一个从关系类型表到实体类型表的外键。他们将引用实体类型的候选键。

行尾的基数告诉您对于给定的实体实例，它可以出现在多少关系实例/行中。如果给定的实例/值不必出现在实例/行中，则为 0。（一个人不必拥有宠物。）如果它只能出现在一个实例/行中，那就是 1。（一个人必须拥有一个头。）如果它可以出现不止一次，那就是很多。（一个人可以拥有许多宠物。所以 person-owns-pet 将是 0-or-MANY。）一般来说，我们将可能性的数量放在一行的两端并说“possibility-to -possibility" 或 "possibility:possibility" 在我们阅读标签的方向。

有“has”或“is”或“is associated with”行，而标签没有明确的关系类型/表，而真正的关系显示为实体类型（具体化/关联实体类型/类/集）。这些行实际上只是从表到参与者实体表的外键。（一个人可以与另一个人结婚；它的关系实例也是婚姻的关联实体实例。）大概这就是这种风格显示多元关系的方式。（令人困惑。）（这种标签的实际关系由关联实体类型表的投影表示。）

其他约定

某些方法将可能性限制为特定选择。有时“1”表示“0-或-1”。一些方法通过关系行不存在或存在与通过强制性但可为空的外键来区分关系中的 0 或 1 参与。一些方法允许与两个以上的参与者建立关系。（好主意。）然后你只需从标签到实体再画一条线。它是 X:Y:Z:.... 一些方法从实体及其基数。（不处理 n 元关系，除非您将它们编码为关联实体，因此所有“关系”都是二进制的。）某些方法具有标签符号。有些方法有未标记的行，它们只是外键。

wiki正好有一篇好文章。

外键

我们不需要外键来了解关系的含义或更新或查询数据库。关系表中将出现实体表的候选/主键列集，因为这些实体参与该关系。我们通过将关系和条件组合成其他关系进行查询，同时 DBMS 构建相应的表表达式并计算其值。

外键只是说一个列列表的子行值必须是另一个列列表的子行值，该值在其表中是唯一的。因此，如果是这样，请通过声明外键来说明。（这有助于 DBMS 拒绝错误的更新和优化，并且可以帮助人们理解关系或注意错误。）这通常是当实体表键列列表出现在关系表中时，因为该实体参与了该关系。（不幸的是，有些方法和工具称为外键关系，但它们不是；它们只是真实的陈述。看看在您自己的图中如何存在/具有/关联标签，不是关系，而是画喜欢他们。）

【讨论】：