一个度为3的联系，包含3个实体，也称为三元联系（ternary relationship）。本书将利用下面的例子来展示三元联系。
MG (Manufacturing Guru) 公司想要记录它的供应商、零部件和产品。
特别地，MG公司想要记录哪家供应商提供了哪些零部件给哪类产品。在需求收集的过程中，MG提供了下列具体需求：
我公司有多类产品。
我公司有多家供应商。
我公司有多类零部件。
我公司想要记录哪家供应商提供了哪些零部件给哪类产品。
每类产品包含一个或多个零部件，每一零部件有一家或多家供应商供应。
每一家供应商可以提供多种零部件给多类产品，但是也可不提供任何零部件给任何产品。
每一类零部件可以被一家或多家供应商提供给一类或多类产品。
简单地在这三个实体之间创建三个二元联系并不能完整地描述以上需求。图2-52展示了三个联系，分别表示：哪类产品与哪些供应商有关联，哪家供应商与哪些零部件有关联，哪种零部件与哪些产品有关联（为简单起见，这部分中所有实体都没有带属性）。但是，基于图2-52创建的数据库并不能记录哪家供应商提供了哪些零部件给哪类产品。
比如，基于图2-52创建的数据库，我们可以描述供应商A1和A2是零部件B的供应方，同时，零部件B是产品C 的零部件之一。但是，假设供应商A1为产品C供应零部件B，供应商A2没有为产品C供应零部件B（即供应商A2供应零部件B，但是不为产品C 提供零部件B），则以图2-52为基础建立的数据库就不能描述这样一个场景。
为了涵盖所有可能的合理应用场景，所有三个实体都必须统一集中于一种联系，这样就得到了一个三元联系。
三元联系的一个棘手问题是在某一种三元联系中，不能明确地表示基数限制。图2-53中展示了一种包含实体SUPPLIER、PRODUCT和COMPONENT的三元联系Provides，图中没有给出基数限制的原因是无法毫无歧义地标明基数限制。
在图2-53中，对那些没有为任何产品提供任何零部件的供应商，图中并没有清楚表示我们可以在什么地方放置记录这些供应商的符号。若只是在联系的零部件一侧设置一个可选符号，这样虽然简洁但依然存在歧义：究竟是希望记录那些不为任何产品提供任何零部件的供应商，还是希望记录那些没有任何供应商为其提供任何零部件的产品。
换句话说，这种表示方式根本不能清楚地描述一个联系的基数。但是，如图2-54所示，如果用关联实体来替代的话，就可以清楚地描述三元联系的所有可能的基数限制了。
注意，图2-54描述了哪家供应商为哪类产品提供了哪些零部件。如果我们要为供应商记录下产品零部件的实际交付量，则需要增加额外的属性，如数量。但是，在图2-54所示的关联实体中仅简单地为供应商增加数量（quantity）这一属性也无法解决上述问题，因为同一家供应商可以不止一次地为同一产品提供同等数量的同一零部件。如果只增加数量这个属性，就没有办法唯一区分同一家供应商为同一产品提供等数量的同一零部件的不同实例。对这一情况的解决办法之一是创建另一属性作为一个唯一交付标识。如果给这些需求增加一项规定，对于每一供应商为某一特定产品供应特定零部件，都认为是一个单独的个体交付并且有自己独特的交付标识，这样一来，就不需要用关联实体来表示了，而是可以用图2-55所示的常规实体来表示。
三元联系中还需要注意的是，除了少数例外情况，三元联系适用于绝大多数像多对多对多（many-to-many-to-many）这样的联系。图2-56展示了一个多对多对一（many-to-many-one）的三元联系。
图2-56表示每一零部件都是由某一家供应商专门为某一产品供应的。因此，此图可以简化成如图2-57，从而消除了转化成三元关系的必要性。
但是，值得注意的是，若想记录实际的各种交易及其数量，还是不得不使用图2-55，除非联系IsIncluded是1∶1的。
在实际中，三元联系比较少见，度大于3的联系更为少见。在多数情况下，当设计者试图创建度大于2的联系时，往往会尝试创建额外的实体而非联系。
总结
表2-1总结了本章介绍的基本ER模型概念。
关键术语
associative entity（关联实体），43
attribute (of an entity)（（实体的）属性），14
binary relationship（二元联系），28
candidate key（候选码），24
cardinality constraint（基数约束），15
composite attribute（复合属性），22
composite unique attribute（复合的唯一属性），23
database requirement（数据库需求），13
degree of a relationship (联系的度)，28
derived attribute（派生属性），25
enhanced ER（EER，扩展的ER），40
entity（实体），13
entity instance/ entity member（实体实例/实体成员），14
entity-relationship/ER modeling（实体–联系建模/ER建模），13
ER diagram（ERD，ER图），13
exact minimum cardinality and/or maximum cardinality（最小基数和/或最大基数确切
值），27
identifying relationship（标识性联系），30
many-to-many relationship/M∶N relationship（多对多联系），17
maximum cardinality（最大基数），15
minimum cardinality/participation（最小基数/参与），15
multivalued attribute（多值属性），25
one-to-many relationship/1∶M relationship（一对多联系），17
one-to-one relationship/1∶1 relationship（一对一联系），17
optional attribute（可选属性），26
owner entity（主实体），30
partial key（部分码），31
relationship（联系），13
relationship attribute（联系属性），19
relationship instance（联系实例），18
relationship role（联系的角色），29
ternary relationship（三元联系），45
unary relationship/recursive relationship（一元联系/递归联系），28
unique attribute（唯一属性），14
weak entity（弱实体），30
复习题
Q2.1 ER建模的目的是什么？
Q2.2 ER模型的基础结构是什么？
Q2.3 唯一属性是什么？
Q2.4 基数限制的定义是什么？
Q2.5 四种可能的基数限制是什么？
Q2.6 三种基数的类型是什么（最大基数侧）？
Q2.7 复合属性是什么？
Q2.8 候选码是什么？
Q2.9 多值属性是什么？
Q2.10 派生属性是什么？
Q2.11 可选属性是什么？
Q2.12 最小基数和最大基数确切值限制在联系里是如何定义的？
Q2.13 二元联系是什么？
Q2.14 一元联系是什么？
Q2.15 弱实体是什么？
Q2.16 关联实体是什么？
Q2.17 三元联系是什么？
练习
E2.1 建立一个有多个属性的实体实例。
E2.2 为一个有两个实体（都包含多个属性）的应用场景创建需求和ER图，需要包含以下联系：
E2.2a 1∶M联系，参与要求是在1这方是强制性的而在M这方是可选择的参与。
E2.2b 1∶M联系，参与要求是在1这方是可选择的而在M这方是强制性的参与。
E2.2c 1∶M联系，参与要求是在两方都是强制性的参与。
E2.2d 1∶M联系，参与要求是在两方都是可选择的参与。
E2.2e M∶N联系，参与要求是在一方是强制性的而在另一方是可选择的参与。
E2.2f M∶N联系，参与要求是在两方都是强制性的参与。
E2.2g M∶N联系，参与要求是在两方都是可选择的参与。
E2.2h 1∶1联系，参与要求是在一方是强制性的而在另一方是可选择的参与。
E2.2i ? 1∶1联系，参与要求是在两方都是强制性的参与。
E2.2j 1∶1联系，参与要求是在两方都是可选择的参与。
E2.3 为一个有两个实体（都包含多个属性）的应用场景创建需求和ER图，要求是有联系属性的多对多联系。
E2.4 创建一个有复合属性的实体实例。
E2.5 创建一个有复合唯一属性的实体实例。
E2.6 创建一个有候选码（多个唯一属性）的实体实例。
E2.7 创建一个有多值属性的实体实例。
E2.8 创建一个有派生属性的实体实例。
E2.9 创建一个有可选属性的实体实例。
E2.10 为一个有两个实体（都包含多个属性）的应用场景创建需求和ER图，要求两个实体包含在一个有确切的最小和最大基数的联系里。
E2.11 为一个包含一元联系的实体的应用场景创建需求和带多个属性的ER图。
E2.12 为一个包含两个实体（均包含多个属性）的应用场景创建需求和ER图，两个实体是两个独立的联系。
E2.13 为一个有两个实体（都包含多个属性）的应用场景创建需求和ER图，要求在某一确定联系中一个是弱实体，另一个是其属主实体。
小案例
小案例1 Investco Scout
Investco Scout是一家投资研究公司，试为其资金数据库建立ER图，需求如下：
Investco Scout资金数据库需要记录投资公司、其管理的共同资金及包含在共同资金中的证券。
对于每一家投资公司，Investco Scout不仅会记录唯一的投资公司标识符和唯一的投资公司名称，而且会记录这家公司在不同地区的名字。
对于每一项共同资金，Investco Scout不仅会记录共同资金的唯一标识符，而且会记录共同资金的名称及其成立日期。
对于每一种证券，Investco Scout不仅会记录一个唯一的证券标识符，还会记录证券的名字和它的类型。
投资公司可以管理多种共同资金。Investco Scout不会记录没有管理任何共同资金的投资公司。同时，一项共同资金是由一家投资公司管理的。
一项共同资金可以包含一种或多种证券。一种证券可以被多项共同资金包含。Investco Scout会记录没有被任何共同资金包含的证券。
对于每一个包含在共同资金里的证券实例，Investco Scout会记录其被包含的数量。
小案例2 Funky Bizz
Funky Bizz提供租赁服务，主要是租赁乐器给乐队。试为Funky Bizz的运营数据库创建一个ER图，满足以下需求：
Funky Bizz的交易数据库需要记录乐器、乐队、维修技术人员以及演出。
对于每一件乐器，Funky Bizz需要记录唯一的乐器序列号、乐器型号、品牌、乐器制造年份以及乐器目前的寿命（以年计数）。
Funky Bizz的客户是乐队。对于每支乐队，Funky Bizz不仅需要记录乐队的名字和唯一的乐队标识符，而且要记录乐队地址、队员姓名及各种电话号码。
维修技术人员负责维护这些乐器。对于每一位技师，需要记录一个唯一的SSN以及姓名、地址、电话号码。
Funky Bizz也要记录客户乐队的演出信息。对于每一场演出，需要记录由演出场地和日期组成的唯一标识符，还要记录演出的类型和名字（一场演出可以有名字也可以没有）。
一支乐队可以不租借任何乐器，也可能租借30件乐器。一件乐器可以被一支乐队租借或者不被租借。
一名维修技术人员可以维护许多乐器或者不维护任何乐器；同样，一件乐器可以被多名技师维护或者没有被任何技师维护。
一支乐队可以在很多场演出中表演，但不必在每一场演出中都有表演。每一场演出至少有一支乐队表演，但通常会有多支乐队。
对于每一支乐队，Funky Bizz记录每一支乐队的表演次数。
小案例3 Snooty Fashions
Snooty Fashions提供独家定制的时装设计服务，试为Snooty Fashions的运营数据库创建ER图，满足以下需求：
对于每一位设计师：有唯一的设计师标识符和SSN，还要包含其姓名（全名）。
对于每一位顾客：有唯一的顾客标识符、姓名和各种电话号。
对于每一位裁缝技师：有唯一的SSN、姓名（全名）。
对于每一套搭配好的服饰：有唯一的标识符、完成日期和价格。
对于每一场时装表演：有唯一的标识符、日期和地点。
一位设计师可以设计很多套服饰，但每套服饰只有一位设计师。
一套服饰售（预售）给一位顾客。顾客可以买一套或多套服饰。（Snooty Fashions不会记录没有购买任何服饰的顾客）。
每位裁缝技师需要至少给一套服饰做剪裁，也可以为多套服饰做剪裁。每一套服饰有至少一位裁缝技师为其剪裁，也可以有多位。
Snooty Fashions会记录每位裁缝技师为某一套服饰剪裁的开始时间。
每位设计师可以参加很多场的时装表演，也可以不参加任何一场时装表演。每场时装表演可以以一位或两位Snooty Fashions设计师为主角（Snooty Fashions不会记录没有以Snooty Fashions设计师为主角的时装表演）。
小案例4 Signum Libri
Signum Libri（SL）是一家出版公司，试为SL运营数据库创建ER图，满足下列需求：
对于每一本由SL出版的书：有书名、流派类型、出版日期、页数。
对于每一位作者：有唯一的作者标识符及作者姓名。
对于每一家代理商：有唯一的代理商标识符及其姓名。
对于每一位编辑：有唯一的编辑标识符及其姓名。
每本书由一位作者撰写，一位作者可以撰写多本书。SL不会记录没有为SL写书的作者。同一作者写的不同的书有不同的书名。但是，不同的作者可以写书名相同的两本不同的书。
每位作者由一家代理商代理。每家代理商至少代理一位作者，也可以代理多位作者。
一本书有一位编辑。一位编辑至少负责编辑一本书，也可以是多本。
每位编辑可以指导一位或多位编辑，但是不可以指导任意一位编辑。每位编辑可以至多有一位导师编辑，但也可以没有。
小案例5 ExoProtect
ExoProtect是一家保险公司。试写出如图2-58所示ExoProtect员工电脑数据库ER图的所有需求。
小案例6 Jone Dozers
Jone Dozers是一家建筑设备公司。试写出如图2-59所示Jone Dozers的销售和租赁数据库ER图的所有需求。
小案例7 Midtown Memorial
Midtown Memorial是一家医院。试写出如图2-60所示Midtown Memorial医院的病人药品分发数据库ER图的所有需求。
4212
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
