1.4 E-R模型

1.4.1 E-R模型的组成要素

E-R模型（Entity Relationship Model），也被称为实体-联系模型或E-R图，是一种描述概念数据模型的工具。E-R模型分别用实体、属性、联系描述现实世界中的对象、对象的属性、对象之间的联系，这三者被称为E-R模型的三要素。

E-R模型以规范的图例描述现实世界。常用的图例规范有两种，如图1-10所示。在第一种图例规范中，将实体、属性和联系分别用矩形、椭圆形和菱形表示；实体及其属性之间、联系及其属性之间用实线段连接；实体和联系之间也用实线段连接，连线旁标注联系的映射基数（Mapping Cardinality）。映射基数表示一个实体通过一个联系所关联的实体值的数量。映射基数的值可以是“一”或“多”。在第二种图例规范中，实体及其属性用一个两行的矩形表示，第一行为实体名，第二行为属性名；联系用菱形表示，联系的属性用矩形表示，联系及其属性之间用虚线连接；实体与联系之间用实线段连接，连线旁标注联系的映射基数。

假设某高校请你设计校园卡管理系统，你首先需要到该校不同部门去调研，了解校园卡管理涉及哪些人，哪些部门，他们分别有什么属性，会对校园卡进行什么操作。然后你需要进行数据抽象，把相关的人、物、事和概念按照共同特性进行归类，梳理各类对象的属性，以及对象与对象之间的联系。最后你需要调研和分析，结果是该高校拟实行一卡通管理，相关人员可以持校园卡在校内的食堂、超市、洗衣房和热水房等商户消费。该系统中校园卡和商户之间的消费关系可以描述为如图1-11和图1-12所示的E-R模型，两种描述形式是等价的，后文以第二种为例进行示例。其中，校园卡实体有卡号、密码、卡状态（分为正常使用、挂失和冻结三种状态，简称状态）与余额等四种属性；商户实体有编号、名称和地址等三种属性。一张卡可以在多个商户消费，一个商户可以接受多张校园卡消费，所以校园卡实体和商户实体之间是多对多的联系，消费时会产生消费日期和消费金额属性。

1. 实体

实体（Entity）是指现实世界中可区别于所有其他对象的一类“事物”或“对象”。例如，校园卡、商品、商户、消费行为等。实体可能是具象的，也可能是抽象的，如校园卡、商品、商户是具象的，而消费行为是抽象的。

同一类实体具有共性的属性，可以通过一组属性来表示一类实体，并与其他类实体区分开来。例如，校园卡可以用卡号、密码、状态、余额等属性来描述，而学生可以用学号、姓名、性别、学院等属性来描述。

实体有“型”和“值”的区别。实体型中的个体称为实体值（Entity Value），每个实体值的属性类型相同，但是可以取不同的属性值。例如，学生是实体型，张伟是学生、周萍是学生，他们是学生这个实体型的实体值，都可以用学号、姓名、性别、学院等属性来描述，只是不同个体的学号、姓名等属性的值是不同的，如表1-1所示。后文如不特别说明，实体指的是实体型。

同一个实体型内的若干个实体值的集合称为实体集（Entity Set）。实体集中每个实体值具有相同的属性。例如，张伟和他的同班同学构成了一个实体集。

2. 联系

放在同一个数据库系统中进行处理的实体往往存在联系，例如学生持有校园卡在商户消费，学生在教师的授课下完成课程的学习。在E-R模型中把实体之间会发生的关系称为联系（Relationship）。

（1）联系的度。

联系的度（Degree）是指参与联系的实体的数目。如果一个应用涉及两个实体及其联系，就建立一个二元联系，联系的度为2。例如，学生和校园卡之间是二元联系。如果一个应用同时涉及三个实体，且通过二元联系无法准确描述三个实体间的联系时，就要建立一个三元联系，联系的度为3。例如，超市中同一种商品有多个供应商，同一个供应商给多家超市供货且向同一家超市供应多种商品。供应商、商品和超市之间是三元联系。三元及以上的联系统称为多元联系。

（2）联系的属性。

实体一定有属性，某些情况下联系也有属性。例如，学生持卡在商户消费，产生的消费金额和消费日期既不是校园卡的属性，也不是商户的属性，而是消费行为发生后产生的“消费”联系的属性。

（3）二元联系的映射基数。

二元联系的映射基数有一对一、一对多、多对一、多对多等四种情况，A、B实体二元联系的映射基数如表1-2所示，其中1表示“一”， n 或者 m 表示“多”。

一对一（One-to-one）：A中的一个实体值至多与B中的一个实体值关联，B中的一个实体值也至多与A中的一个实体值关联，记为1:1。例如，一个学生只能拥有一张校园卡，一张校园卡也只能由一个学生持有，学生与校园卡之间是一对一的联系，如图1-13所示。

一对多（One-to-many）：A中的一个实体值可与B中任意数目（0到多个）的实体值关联，B中的一个实体值至多与A中的一个实体值关联，记为1: n 。例如，一个部门中有若干名职工，每名职工只能在一个部门工作，则部门与职工之间是一对多的联系，如图1-14所示。

多对一（Many-to-one）：A中的一个实体值至多与B中的一个实体值关联，B中的一个实体值可与A中任意数目（0到多个）的实体值关联，记为 n ：1。上例中，职工与部门之间是多对一的联系。

多对多（Many-to-many）：A中的一个实体值可与B中任意数目（0到多个）的实体值关联，B中的一个实体值可与A中任意数目（0到多个）的实体值关联，记为 m : n 。例如，某高校的图书借阅制度是一个学生可以借阅多本图书，一本图书可以被多个学生借阅。学生与图书之间是多对多的联系，如图1-15所示。

（4）多元联系的映射基数。

多元联系映射基数的确定方法是分别以一个实体作为中心，假设另外的实体都只有一个实体值，根据关联的中心实体的数量进行判断。例如，三元联系中，分别以一个实体作为中心，假设另两个实体都只有一个实体值。若中心实体只有一个实体值能与另两个实体的实体值进行关联，则中心实体的连通数为“一”；若中心实体有多于一个实体值能与另两个实体的实体值进行关联，则中心实体的连通数为“多”。三元联系的映射基数有以下四种情况：一对一对一、一对一对多、一对多对多、多对多对多，分别表示为1:1:1、1:1: n 、1: m : n 、 m : n : p 。

假设A公司的技术员可能负责多个项目，而且一名技术员在每个项目中只使用一本手册，一名技术员在不同的项目中使用不同的手册，一个项目的每本手册只属于一名技术员。技术员、项目和手册之间是1:1:1的三元联系，如图1-16所示。

假设B公司中，每个员工在一个地点仅仅能被分配一个项目，但能够在不同地点做不同的项目。每个地点的一个项目能够由多个员工来做。项目、地点和员工之间的联系是1:1: n 的三元联系，如图1-17所示。

再如，C公司中，一名经理手下的一名工程师可能参与多个项目。一名经理管理的一个项目可能会有多名工程师。一个项目的每名工程师仅由一名经理管理。经理、工程师和项目之间的联系是1: m : n 的三元联系，如图1-18所示。

最后来看一个 m : n : p 联系的例子。D公司中，一位店员可以向一位顾客销售多种商品，而一名店员也可以将一种商品销售给多位顾客，一位顾客可以从不同店员处购买同一种商品。店员、顾客和商品之间的联系是 m : n : p 的三元联系，如图1-19所示。

（5）自环联系及其表示。

自环联系是一类特殊的联系，是指同一个实体以不同角色多次参与一个联系。例如，每个班只有一名班长，班长管理本班的所有学生，而班长也是一名学生。该联系中学生实体以班长和普通学生两种角色参与管理与被管理的联系。发生自环联系时，有必要在菱形和矩形的连线上标注角色名，指明实体是如何参与联系的，如图1-20所示。

3. 属性

E-R模型中的属性除了按照描述对象的不同，分为实体的属性和联系的属性之外，还可以按照其他标准进行分类。

（1）简单属性和复合属性。

简单属性是指不能划分为更小部分的基本属性，反之称为复合属性。复合属性中的子属性也可以是复合属性。E-R图中，复合属性用缩进式目录结构表示。例如，如图1-21所示的学生实体的属性中，学号、姓名、出生日期、学院都是不可再分的简单属性；通信地址是由省、市、区、街道组成的复合属性。其中，街道是由街道号、街道名和门牌号组成的复合属性。

（2）单值属性和多值属性。

如果某个属性对于一个特定的实体只有单独的一个值，这样的属性称为单值属性；反之称为多值属性。多值属性用{}表示。例如，绝大多数学生只有一个电话号码，但只要有学生有多个电话号码，则电话号码就是多值属性，如图1-21所示。

（3）派生属性。

派生属性是指可以从别的相关属性或实体派生出来的属性。派生属性用()表示。为了减少冗余和数据不一致，数据库中不存储派生属性，仅在需要时通过相应的公式计算得到。例如，图1-21中，学生的年龄是可由其出生日期计算得到的派生属性，故建议删除该属性。

1.4.2 数据抽象方法

常用的数据抽象方法有三种：分类、聚集和概括。

1. 分类

分类是指把现实世界中具有共性的个体抽象为一种实体型。例如，校园卡管理中，无论是张伟、周萍，还是其他个体都是学生，具有学号、姓名、性别、学院等共同属性，可以抽象为“学生”实体型，而张伟、周萍等个体为该实体型的实体值，和实体型之间是“is member of”的关系，如图1-22所示。

2. 聚集

聚集是将实体值之间的共性属性抽象为实体的属性，属性描述了实体的组成部分。属性和实体型之间是“is part of”的关系。例如，学号、姓名、性别、学院等都可以抽象为“学生”实体的属性，如图1-22所示。

3. 概括

如果实体之间存在子集联系，可以概括为子类和超类。子类和超类之间是“is subset of”的关系，子类继承超类所有的联系和属性，从而简化实体的设计。

E-R模型中分别用矩形和双竖边矩形表示超类和子类，用直线加小圆圈的形式表示超类-子类的关系。例如，研究生、本科生都是学生，都具有学生的基本属性，但是研究生有本科生没有的科研要求（研究方向）、本科生有研究生没有的军训和生产实习，研究方向，军训及生产实习分别是研究生和本科生的特有属性。如果抽象为学生、研究生、本科生三种实体型，一则实体型数量多，二则实体型之间存在较多的冗余属性。使用概括进行抽象后，把研究生、本科生抽象为学生的子类，继承学生超类的学号、姓名、性别、学院等基本属性，同时具有自己的特殊属性，如图1-23所示。

1.4.3 E-R模型的设计流程

复杂的数据库系统一般按照自底向上的设计策略，分模块进行设计。E-R模型的设计流程是先设计局部应用的局部E-R模型，然后把所有局部E-R模型合并为完整的数据库系统的全局E-R模型，最后把全局E-R模型优化为基本E-R模型，如图1-24所示。

1. 局部E-R模型设计

局部E-R模型设计的工作内容是基于对局部应用的需求分析结果，运用分类、聚集、概括等数据抽象方法，把一个局部应用抽象为实体、属性、标识实体的关键属性，并确定实体之间的联系及联系的类型。

局部E-R模型设计的难点是把现实世界的对象抽象为实体还是属性。实体和属性是相对而言的，往往要根据实际情况进行必要的调整。基本的判断依据有三个。一是属性要足够简单，复合属性需要升级为实体，或直接被其子属性替代。二是简化E-R模型的处理，现实世界中的事物凡能够作为属性对待的，应尽量作为属性。如果一个实体只有一个属性，则应该降级为属性。三是属性是对实体组成部分的描述，是实体的一部分，不允许属性与其他实体发生联系。例如，校园卡对于商户的经营管理而言是属性，他们只关注校园卡的卡号。但对于学生而言，除了卡号，还有卡的密码、余额等属性需要关注，校园卡应该抽象为包含多个属性的实体。

例1-1 如图1-25a）所示，局部E-R模型中的工资是职工的属性，工资构成包含岗位工资、薪级工资、绩效工资和津贴补贴四部分。这种设计方法是否合适？

不合适。因为工资不仅是派生属性，而且是包括四个子项的复合属性。处理方法有两种：一是用岗位工资、薪级工资、绩效工资、津贴补贴替代工资属性，如图1-25b）所示；二是把工资作为实体，如图1-25c）所示。

2. 全局E-R模型设计

将局部E-R模型合并为全局E-R模型，首先要识别各局部E-R模型中的公共实体，然后从公共实体开始进行两两合并，直到所有有关联的局部E-R模型合并为一个整体，最后加入独立的局部E-R模型后得到全局E-R模型。

对于较大的数据库系统，局部E-R模型很多，而且现实世界的同一个对象在不同的局部E-R模型中可能被给予了不同的抽象，将局部E-R模型合并为全局E-R模型时难免会出现冲突。检查并消除冲突是设计全局E-R模型的重要工作内容。常见的冲突有三种，分别是结构冲突、命名冲突和属性冲突。

（1）结构冲突。

结构冲突是指同一对象在不同应用中具有不同的抽象。

第一类结构冲突是同一对象在不同的局部应用中分别被抽象为实体和属性。调整的原则是能用属性表示的对象就不要用实体表示，但是当对象的属性难以用简单属性表示时，就要在整个系统范围内把该对象用实体表示。例如，校园卡在一个局部应用中作为属性，在另一个局部应用中可以是有多个属性的实体，则我们在合并局部E-R模型时应该把校园卡作为实体。

第二类结构冲突是同一对象在不同的局部E-R模型中都被抽象为实体，但是实体的属性并不完全相同或属性的排列次序并不完全相同。因为数据库要满足所有用户的数据处理需求，因此实体的属性应该取各局部E-R模型中该实体属性的并集，再按照由主到次的顺序调整属性的顺序。例如，校园卡在一个局部应用中有卡号、开卡日期、注销日期、密码、状态等属性，在另一个局部应用中有卡号、密码、余额等属性，两个局部E-R模型合并后，校园卡实体的属性是二者的并集：卡号、密码、余额、开卡日期、注销日期、状态。

第三类结构冲突是在不同的局部应用中，实体之间的联系类型不同。例如，在一个局部应用中校园卡与商户之间是二元联系，而在另一个局部应用中校园卡、商户、商品之间是三元联系。是二元联系合适，还是三元联系合适，没有一定之规，要根据应用语义具体分析，然后对实体之间的联系类型进行设计。调整的原则是能用二元联系表示就不要用三元联系表示。例如，校园卡、商户、商品之间的三元联系，可以调整为校园卡与商户之间的二元联系和商户与商品之间的二元联系。但是并非所有的三元联系都可以用多个二元联系来表示。

（2）命名冲突。

实体名、属性名、联系名都有可能冲突，其中以属性的命名冲突尤为常见。命名冲突分为同名异义和同义异名两种情况。

同名异义是指不同意义的对象在不同的局部应用中具有相同的名字，例如，在不用的局部应用中都将实体命名为“项目”，一个是指教师承担的科研课题，一个是指学生参加的大学生创新创业项目。二者的性质、研究内容、考核指标都是不一样的，是两种不同的实体，应该用不同的实体名加以区分。

同义异名是指同一对象在不同的局部应用中被定义了不同的名字。例如，同样是学生实体，在一个局部应用中被命名为“学生”，而在另一个局部应用中又被命名为“学员”，因此，在合并为全局E-R模型时需要统一。

（3）属性冲突。

属性冲突是指同一个属性的属性域冲突，或者属性取值单位冲突。

属性域包括属性的数据类型和取值范围。属性域冲突有可能是同一属性在不同的局部应用中被定义了不同的数据类型，或者同一属性在不同的局部应用中数据类型相同但是数据的取值范围不同。例如，校园卡的卡号在一个局部应用中被定义为整数类型，而在另一个局部应用中被定义为字符类型。又如，学号在两个局部应用中都被定义为字符类型，但是在一个局部应用中学号的长度为12，在另一个局部应用中学号的长度为10。

属性取值单位冲突也很常见。例如，商品的规格属性在一个局部应用中以箱为单位，在另一个局部应用中以瓶为单位。

3. 基本E-R模型设计

基本E-R模型设计是指在全局E-R模型的基础上，去掉冗余数据和冗余联系。冗余数据是指可由基本数据导出的数据。冗余联系是指可由其他联系导出的联系。冗余数据和冗余联系容易造成数据的不一致，增加数据库维护的难度。如果全局E-R模型中存在冗余数据和冗余联系，则需要对其进行优化。优化后的全局E-R模型被称为基本E-R模型。

例如，学生的平均分是由各科成绩加权平均后得到的数据，属于冗余数据。又如，发票的总金额是由发票中商品的单价和数量计算得到的数据，属于冗余数据。

例1-2 如图1-26所示的E-R模型中是否存在冗余联系？如果存在，请你消除冗余联系。

学生与商户之间的消费联系是一个冗余联系，因为该联系可以通过学生持有校园卡和刷卡在商户消费这两个联系推导出来。消除冗余联系后的E-R模型如图1-27所示。

基本E-R模型用尽可能少的实体、属性、联系，准确、全面地反映用户功能需求。但这并不意味着数据库中没有冗余，必要的冗余有时可以提高数据查询的效率。设计基本E-R模型时，哪些冗余信息要消除，哪些冗余信息允许存在，需要根据用户的整体需求来确定。

1.4.4 某高校校园卡管理E-R模型设计

某高校学生一直以来戏称自己为“有卡一族”：考试需要学生证，食堂消费需要饭卡，进出图书馆需要图书证，加上洗澡卡、洗衣卡、饮水卡、就诊卡，少了哪一张卡都不方便。为解决学生们的烦恼，提高学校信息管理水平，学校提出了“校园一张卡”信息化建设工程，其目标是将饭卡、图书证等卡合为一张校园卡，学生可通过校园卡完成校园内各种情况下的身份认证（如进出图书馆、在校医院挂号等），以及在图书馆、校医院、食堂、餐厅、超市等的小额消费业务，做到一张校园卡覆盖学生在校生活。假设让你来设计该校的校园卡管理数据库，你会怎么做？

统一的校园卡数据管理需要打破现有部门之间的壁垒，让各部门之间的数据库应用统一的数据标准。本书将以该高校的校园卡管理系统建设为背景，介绍数据库的分析与设计。

1. 系统需求分析

依据“校园一张卡”的目标，让每位学生最多持有一张校园卡，且持此卡可以在校内商户（超市、食堂、校医院、餐厅、校内循环车、自动售货机等）消费。校园卡管理系统涉及的功能主要包括以下几个。

（1）办理与注销校园卡。

新生入学后，可持学生证办理校园卡。学生毕业离校前由校园卡服务中心统一注销校园卡。

（2）交易结算。

校园卡账户不具备透支功能，必须先充值，后消费。基于校园卡账户的消费是联机实时交易，实时扣取账户余额，并在校园卡管理系统中产生相应的消费明细（包括消费金额、消费日期等信息）。当单次消费金额超过限额时（默认为30元），会要求学生本人输入密码才能完成消费。

（3）信息查询。

包括账户基本信息查询和消费信息统计等。

（4）挂失、冻结与解除挂失。

当校园卡丢失时，持卡人应及时持本人有效证件（身份证或学生证）去指定地点申请挂失。挂失后校园卡被冻结，在解除挂失之前不能使用。冻结的校园卡如果又找到了，可以通过解除挂失，恢复卡功能；如果需要办新卡，新卡沿用原卡的卡号，原卡的余额会转到新卡中。

2. 局部E-R模型设计

根据需求分析的结果，对现实世界进行数据抽象。校园卡管理系统有学生、校园卡、商户等实体。

（1）学生：学生的属性有学号、姓名、性别、学院等。

（2）校园卡：校园卡的属性有卡号、密码、余额、状态等。

（3）商户：食堂、超市、洗衣房、校医院、校内循环车等可以抽象为商户。商户的属性有编号、名称、地址等。

实体之间的联系如下。

（1）学生与校园卡之间是一对一的联系，局部E-R模型如图1-28所示。

（2）校园卡与商户之间是多对多的联系。刷卡时会生成消费日期、消费金额等属性，局部E-R模型如图1-29所示。

3. 全局E-R模型设计

合并两个局部E-R模型，并消除冲突。持卡消费的局部E-R模型中，校园卡实体的属性“持卡人”与学生实体的属性“学号”属于异名同义，在校园卡实体中属于冗余属性，合并后应该去掉。解决上述冲突之后，我们得到全局E-R模型，如图1-30所示。

该全局E-R模型中没有冗余数据和冗余联系，符合基本E-R模型的要求。