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

Question

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

这是：Solicitor ERD（ERD是针对一个组成的律师公司）

基本上我的任务是获取此ERD并编写一个SQL脚本来创建数据库，显然用我可以组成的数据填充表。 SQL语法不是我遇到困难的事情，它只是简单地理解图中的基数。

对我来说，条款＆＃39; 1到1＆＃39;，＆＃39; 1到多个＆＃39;，＆＃39;多对多＆＃39;只是不要点击，我不知道它们的意思以及它们如何影响主键和外键的位置。

我可以使用这些表格并轻松创建相关列，例如我知道客户＆＃39;表格将包含类似＆＃39; client_name＆＃39;。但是，当谈到将客户与客户联系起来时。表＆＃39;案例＆＃39;表，我怎么知道外键去哪儿了？

＆＃39;客户＆＃39;表格包含＆＃39; caseID＆＃39;来自＆＃39;案例＆＃39;表以及＆＃39;案例＆＃39;包含＆＃39; clientID＆＃39;的表格来自＆＃39;客户＆＃39;表？或者只有一张桌子有外键？它是这样的，我只是不明白。

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

Answer 1

这种风格的图表

有一个实体类型/类/集＆amp;每个框的表和关系类型/类/集＆amp;每个标记行的表格。

行的末尾指向参与关系类型的实体类型。您需要知道应用程序域中的实体和关系是什么。表的一行表示实体/关系实例。从关系类型表到每个端点的实体类型表都有一个外键。他们将引用实体类型的候选键。

一行末尾的基数告诉您给定的实体实例它可以出现多少个关系实例/行。如果给定的实例/值不必出现在实例/行中那么那么＆ ＃39; s 0.（一个人不必拥有宠物。）如果它只能出现在一个实例/行中那么那个1.（一个人必须拥有一个头。）如果它可能会出现不止一次的情况。 （一个人可以拥有很多宠物。所以人拥有宠物的人数可能是0或者很多。）一般来说，我们把可能性的数量放在一条线的两端并说出＆＃34; 的可能性 - 到 - 可能性＆＃34;或＆＃34; 可能性：可能性＆＃34;在我们阅读标签的方向上。

有＆＃34;有＆＃34;或＆＃34;是＆＃34;或＆＃34;与＆＃34;相关联标签没有显式关系类型/表的行，而实际关系显示为实体类型（具体化/关联实体类型/类/集）。这些行实际上只是从表到参与者实体表的外键。 （一个人可以与另一个人结婚;这种情况的关系实例也是婚姻的联想实体实例。）据推测，这种风格如何显示出一种关系。 （令人困惑。）（这种标签的实际关系由关联实体类型表的投影表示。）

其他约定

某些方法限制了特定选择的可能性。有时＆＃34; 1＆＃34;意味着＆＃34; 0-or-1＆＃34;。一些方法通过关系行不存在或存在与通过强制但可以为空的外键来区分关系中0或1的参与。一些方法允许与两个以上的参与者建立关系。 （好主意。）然后你只需从标签中绘制另一条线到实体。它的 X ： Y ： Z ：....某些方法标记了远的结尾来自具有基数的实体的一条线。 （除非您将它们编码为关联权限，否则不会处理n元关系，因此所有＆＃34;关系＆＃34;都是二进制的。）某些方法具有标签符号。有些方法有未标记的行，只是外键。

wiki中恰好有一篇好文章。

外键

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

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

Answer 2

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

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

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

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

祝你好运。