数据库设计和ER模型课件

*第五章:实体–联系模型*第五章:实体–联系模型设计过程建模约束E-R图设计中的问题

弱实体集

扩展的E-R特性银行数据库的设计数据库设计的其他问题*设计过程用户需求规格说明概念设计阶段E-R模型功能需求规格说明逻辑设计关系模式建立物理设计定义数据库物理特征

设计中主要陷阱冗余不完整性

*建立模型数据库可以被建模为:实体集合实体间的联系实体（entity）

是一个存在且区别于其他对象的对象例子:特定的一个人/公司/事件/工厂实体有属性（attributes）例子:人有名字和住址

实体集（entityset）是具有相同类型，即相同性质或属性的实体集合例子:所有人/公司/树/假期的集合*customer

和loan实体集合customer_idcustomer_customer_customer_loan_amount

namestreetcity

number*联系集联系（relationship）是一个几个实体间的关联

例子:

Hayes

depositor

A-102

customer

实体 联系集 account

实体联系集（relationshipset）是一个n

2实体集间的数学关系（这些实体集不必互异），来源于实体集 {(e1,e2,…en)|e1E1,e2E2,…,enEn}

这里(e1,e2,…,en)是联系例子: (Hayes,A-102)depositor*联系集

borrower*联系集(Cont.)属性可以是一个联系集中的性质（property）例如,customer和account实体集间的depositor联系集可以有属性access-date*联系集的度（degree）指参与一个联系集的实体集数目涉及两个实体集的联系集叫做二元（binary）

(或两度)。总体上，大多数数据库系统中的联系集是二元的。联系集可以涉及两个以上的实体集涉及两个以上的实体集的联系集很少见例子:假设银行的雇员（employees）可以在多个支行有工作,在不同支行有不同工作。

于是在实体集employee、job和branch间存在一个三元联系集*属性实体由属性集代表，即实体集所有属性具有的描述性的性质

域（Domain）

–每个属性允许的取值属性的类型:简单（simple）和复合（composite）属性单值（Single-valued）和多值（multi-valued）属性例子:多值属性phone_numbers派生（Derived）属性能够从其他属性计算得来例子:给定date_of_birth，得到age例子:

customer=(customer_id,customer_name, customer_street,customer_city)

loan=(loan_number,amount)*复合（composite）属性*映射基数约束表示一个实体通过一个联系集能够与多少个实体相关联在二元联系集中非常有用对二元联系集，映射基数必须是下列类型之一：一对一一对多多对一多对多

*映射基数（MappingCardinalities）一对一一对多注意:A

和B

中一些元素可以不被映射到另一集合中的任何元素上*映射基数（Cont.）多对一多对多注意:A

和B

中一些元素可以不被映射到另一集合中的任何元素上*码超码：唯一标识别实体集中一个实体的属性集候选码：最小的超码主码：被选中的候选码*联系集的码参与联系的实体集的主码的组合形成联系集的一个超码(customer_id,account_number)是depositor的一个超码注意：这意味着实体集对能在特定的联系集中最多有一个联系

例子:如果需要对每个customer访问每个account跟踪所有access_dates,我们不能对每次访问假定一个联系。但，我们可以使用多值属性当确定候选码时，必须考虑联系集的映射基数当在多于一个候选码中选择主码时，需要考虑联系集的语义*E-R图矩形：实体集菱形：联系集线段：将属性连接到实体集，将实体集连接到联系集椭圆：属性双线：多值属性虚线：派生属性下划线：主码属性*E-R图：复合、多值、派生属性*具有属性的联系集*角色一个联系的实体集不需要是相异的如下，标签“manager”和“worker”叫做角色（roles），

它们指定employee实体如何通过works_for联系集交互E-R图中通过标示连接矩形和菱形的线段来表示角色角色标签可选，用来阐明联系的语义*基数约束（CardinalityConstraints）基数约束表示为联系集和实体集间的有向或无向线段：

()表示“一”(—)表示“多”一对一联系：一个customer通过联系borrower最多与一个loan关联一个loan通过联系borrower最多与一个customer关联*一对多联系在一对多联系中，一个customer通过联系borrower与多个（包括零个）loan关联，一个loan通过联系borrower最多与一个customer关联*多对一联系在多对一联系中，一个customer通过联系borrower最多与一个loan关联，一个loan通过联系borrower与多个（包括零个）customer关联*多对多联系一个customer通过联系borrower与多个loan（包括零个）关联一个loan通过联系borrower与多个（包括零个）customer关联*实体集在联系集上的参与全参与（双线表示）:实体集上每个实体参与联系集上的至少一个联系例如：loan在borrower上的参与是全参与

每个loan必须有一个customer通过borrower与之关联部分参与：某些实体可以不参与联系集中任何联系例如:customer在borrower上的参与是部分参与*基数约束的另一种表示符号基数约束也能表示为参与约束*几种表示比较*三元联系E-R图*三元联系的基数约束我们只允许三元（或更高度数）联系最多有一个箭头来表示基数约束如：一个从works_on到job的箭头表示每个雇员在任一支行最多有一个工作如果有超过一个箭头，则有两种意思解释：

如：一个A,B和C间的三元联系R，箭头到

B和

C可以有如下意思： 1.每个A实体与B和C中唯一的实体相关联 2.每个(A,B)中实体对与C中唯一实体关联，且每个(A,C)中实体对与B中唯一实体关联上面二者有不同的形式为避免混乱，我们规定超过一个箭头为非法*设计问题实体集vs.属性

选择主要基于建模企业的结构，以及所讨论的属性的语义实体集vs.联系集

可能的指导在于设计一个联系集去描述两个实体间的动作二元联系集vs.n元联系集

尽管可能用多个互异的二元联系集代替任何一个非二元（n>2）联系集，一个n元联系集能够将多个实体参与一个联系表现的更清楚联系属性的布局*实体集vs.属性*实体集vs.联系集*二元联系vs.非二元联系有些非二元联系表示为二元联系更好例子：三元联系parents,关联一个child到他/她的father和mother，该联系以两个二元联系father

和mother表达更好

使用两个二元联系允许部分信息（如：只知道mother）但一些联系是“自然的”非二元例如:works_on思考：民政局要记录人的家庭（婚姻、亲子（血亲、非血亲））、社会（工作）关系。提示：一个实体“人”。*非二元联系转换为二元形式

总之，通过建立一个人为的实体集，任何非二元联系能够被二元联系替换。使用实体集

E以及三个联系集，代替A、B和C

间的联系

R: 1.RA,关联E和A 2.RB,关联E和B 3.RC,关联E和C为E建立一个特殊的标识属性如果联系集R有属性，将其赋给实体集E

对R中每个联系(ai,bi,ci)，建立 1.实体集E中的一个新的实体

ei

2.增加(ei,ai)到RA 3.增加(ei,bi

)到RB

4.增加(ei,ci)到RC*非二元联系转换为二元形式(Cont.)并需要约束转换转换所有约束也许不可能在转换后的模式的实例中，可能有的实例不能与R中任何实例相对应练习:

增加约束到联系RA、RB

和RC，以确保新建立的实体对应于实体集A、B

和C每个中严格的一个实体我们能够避免建立标识属性，通过使E成为一个被三个联系集标识的弱实体集*联系属性的布局：映射基数影响E-R设计如果每个帐户只能有一个客户，可以让access-date成为account的一个属性,而不是联系的属性,即是,该从account到customer联系是多对一（等价地，customer到account是一对多）*弱实体集（WeakEntitySets）一个没有主码的实体集称为弱实体集（weakentityset）弱实体集的存在依赖于标识实体集(identifyingentityset

)或属主实体集（ownerentityset）的存在它必须与标识实体集通过一个从标识实体集到弱实体集的完全、一对多的联系集相连标识性联系（Identifyingrelationship）使用双线菱形描画弱实体集的分辨符（discriminator）

(或部分码）是区分弱实体集的所有实体的属性集合弱实体集的主码由弱实体集存在依赖于的强实体集的主码，加上弱实体集的分辨符组成*弱实体集(Cont.)使用双线矩形描画弱实体集使用虚线下划线描画弱实体集的分辨符payment_number–payment实体集的分辨符payment的主码–(loan_number,payment_number)

*弱实体集(Cont.)注意:

强实体集主码并不显式地存储在弱实体集中，因为它隐含在标识性联系中如果

loan_number

被显式存储，payment

应该成为强实体，但这样payment和loan间的联系被一个隐含联系重复了，该隐含的联系被payment

和loan共有的属性loan_number定义了弱实体集可以参与标识性联系以外的其他联系弱实体集可以作为属主参与到与另一个弱实体集的标识性联系中弱实体集可以与不止一个标识实体集联系如果弱实体集属性不多，也没有参与到标识性联系以外的其他联系，我们可以选择将弱实体集表示为属主实体集的一个多值复合属性*更多弱实体集例子在大学里，course

是强实体，course_offering能够被建模为弱实体course_offering的分辨符可以是semester(包括year)和section_number(如果有超过一个部分)如果我们建模

course_offering

为一个强实体，我们应该建模course_number为一个属性。这样，与course的联系应该隐含course_number属性，就重复了。*扩展的E-R特性:特殊化（Specialization）自上而下（top-down）的设计过程。我们在一个实体集中设计互异的子群这些子群变成低层实体集，这些实体集有属性或参与对高层实体集不适用的联系三角形组件描画，标示为ISA(如：customer“isa”person)属性继承

–一个低层实体集继承其相连高层实体集的全部属性，以及继承地参与到其高层实体集参与的联系中单继承：给定低层实体集参与到一个ISA联系中多继承：给定低层实体集参与到一个以上ISA联系中*特殊化例子*扩展E-R特性:泛化（Generalization）自下而上（bottom-up）设计过程–组合共享同样特性的实体集到高层实体集特殊化和泛化是简单的互逆过程，在E-R图中以同样方式描画术语特殊化和泛化常被互换地使用*特殊化和泛化(Cont.)基于不同的特性，实体集可以有多种特殊化方式如：permanent_employeevs.temporary_employee， 以及officervs.secretaryvs.teller每个特定的employee应该是

permanent_employee或temporary_employee

的一个成员同时也是officer、secretary或teller的一个成员ISA联系也用来指代父类—子类（superclass–subclass）

联系*特殊化/泛化上的约束设计判定哪些实体能够成为给定低层实体集的成员条件定义的成员资格的确定基于实体是否满足一个显式的条件或谓词例子：所有65岁以上的客户是senior-citizen的成员，senior-citizenISAperson用户定义的不是条件判定，而是用户指派约束或非约束的实体可以属于单一泛化中超过一个低层实体集分离的（disjoint）一个实体只能够属于一个低层实体集注意E-R图中在ISA三角旁书写disjoint

重叠的（overlapping）一个实体能够属于超过一个低层实体集*特殊化/泛化上的约束设计(Cont.)完全性约束（Completeness

constraint）

--指定一个高层泛化实体集是否必须属于至少一个低层实体集全部特殊化或泛化:一个实体必须属于低层实体集中的一个部分特殊化或泛化:一个实体不需要属于低层实体集中的一个*聚集（Aggregation）考虑前面提到的三元联系works_on

假设我们想要记录管理者，该管理者管理一个支行的一个雇员完成的工作*聚集(Cont.)联系集

works_on和manages

代表重叠的信息每个manages

联系对应于一个works_on

联系但是,一些

works_on

联系可以不对应于任何manages联系

所以我们不能丢弃works_on

联系通过聚集可以消除这种冗余允许联系间的联系把联系当成一个抽象实体对待抽象联系成为新实体不再引入冗余，下面图形代表:一个雇员在特定支行的特定工作（job）上工作(workon)一个雇员（employee）、支行（branch）、工作（job）的组合可以有一个关联的管理者（manager）*包含聚集的E-R图*E-R图使用的符号汇总*符号汇总(Cont.)*E-R设计决定使用属性或实体集代表一个对象一个真实世界中的概念最好表示为实体集或联系集使用三元联系或二元联系使用强实体集或弱实体集.使用特殊化/泛化–对设计中的模块结构有贡献使用聚集–能够将聚集实体集当成单个单元对待，而不必关心其内部结构正确的设计决定来源于对被建模企业的深刻理解！

*银行数据库设计银行数据库的数据需求银行数据库中的实体集银行数据库中的联系集银行数据库中的E-R图*银行数据库的数据需求银行有多个支行。每个支行位于某个城市，由唯一的名字标识。银行监控每个支行的资产。银行的客户通过其customer_id值来标识。银行存储每个客户的姓名及其居住的街道和城市。客户可以有账户，并且可以贷款。客户可能同某个银行员工发生联系，该员工作为此客户的贷款负责人或私人助理。银行员工通过其employee_id值来标识。银行的管理机构存储每个员工的姓名、电话号码、亲属姓名及其经理的employee_id号码。银行还需要知道员工开始工作的日期，由此日期可以推知员工的雇佣期。*银行数据库的数据需求（Cont.）银行提供两类账户——支票账户和储蓄存款账户。账户可以由两个或两个以上客户共有，一个客户也可以有两个或两个以上的账户。每个账户被赋予唯一的账户号。银行记录每个账户的余额以及每个账户拥有者访问该账户的最近日期。另外，每个储蓄存款账户有其利率，而每个支票账户有其透支额。每笔贷款由某个支行发放，能被一个或多个客户所共有。一笔贷款用一个唯一的贷款号标识。银行需要知道每笔贷款所贷金额以及逐次还款情况。虽然贷款的还款号并不能唯一地标识银行所有贷款中的某个特定的还款，但可以唯一地标识对某贷款的所还款项。对每次的还款需要记载其日期和金额。 真实的银行中，还应像记载对贷款的所还款项那样来记载每个储蓄存款账户或支票账户中取出或存入的金额。由于这些记载的建模过程类似，并且为了保持示例的简洁性，在我们的模型中不考虑对存款和取款的记录。

*银行数据库中的实体集 数据需求规格说明是建造数据库概念模式的出发点。由前面数据需求规格说明所列举的特点，我们开始标识实体集及其属性：实体集branch，具有属性branch_name、branch_city和assets。实体集customer，具有属性customer_id、customer_name、customer_street和customer_city。此外还可以考虑加上属性banker_name。实体集employee，具有属性employee_id、employee_name、telephone_number、salary和manager；此外还包括多值属性dependent_name，基属性start_date及其派生属性employment_length。*银行数据库中的实体集（Cont.）两个账户实体——savings_account和checking_account，它们共同的属性是account_number和balance；此外savings_account还具有属性interest_rate，checking_account还具有属性overdraft_amount。实体集loan，具有属性loan_number、amount和originating_branch。弱实体集payment，具有属性payment_number、payment_date和payment_amount。*银行数据库中的联系集 在前面的设计模式上，我们定义如下联系集和映射基数。在这个过程中我们还要对前面关于实体集属性的决策进一步精化。borrower，是customer和loan间的一个多对多联系集。loan_branch，指明产生贷款的银行支行的多对一联系集。注意这个联系代替了loan实体集的originating_branch属性。loan_payment，从loan到payment的一对多联系集，表明一笔款项是为某笔贷款而付的。*银行数据库中的联系集（Cont.）depositor，具有联系属性access_date，是customer和account间的多对多联系集，表明某个客户拥有某个账户。cust_banker，具有联系属性type的一个多对一联系集，表明一个客户可以从一个银行员工处获得建议，而一个银行员工可以为一个或多个客户提供建议。注意这个联系集代替了customer实体集的banker_name属性。works_for，具有manager角色和具有worker角色的employee实体之间的联系集；其映射基数表明了一个员工仅为一个经理工作，而一个经理监督一个或多个员工。请注意我们用这一联系集代替了employee实体集的manager属性。*银行的E-R图*从E-R图转换到关系模式主码允许实体集和联系集一律被表示为数据库的关系模式一个符合E-R图的数据库能够被模式集所表示对每个实体集和联系集有一个唯一的模式，该模式被赋予相应实体集或联系集的名字每个模式有限个列（总体上对应于属性），每个列有唯一的名字*实体集表示为模式强实体集转换为具有同样属性的模式弱实体集转换为包含标识实体集主码的表，如：

payment=

(loan_number,payment_number,payment_date,payment_amount)*联系集表示为模式一个多对多联系集表示为一个具有（两个）参与实体集主码的模式，并且该模式包含所有该联系集的描述性属性

例子:联系集borrower的关系模式：

borrower=(customer_id,loan_number)*模式中的冗余在多边全参与的多对一以及一对多联系集，能够被表示为：增加一个额外的属性到“多”边，该属性包含“一”边的主码例子:不是为联系集account_branch建立模式，而是增加一个属性branch_name到由实体集account建立的模式中模式account的主码应当还是account_number，但应当增加外码约束branch_name到模式branch）*模式中的冗余(Cont.)对一对一联系集，任何一边能够用来做“多”边对待即,额外的属性能够增加到与任何一个实体集相应的模式中

如果在“多”边是部分参与，可如前处理，但将造成“多”边(所增加的属性)的null值连接弱实体集和标识强实体集的联系集的相应模式是冗余的例子:payment

模式包含了出现在loan_payment模式中的属性(即，loan_number

和payment_number)*复合及多值属性复合属性处理：为每个组成属性建立一个分离的属性例子:实体集customer有复合属性name，

name包含组成属性first_name和last_name，则相应模式包含两个属性

first_name

和last_name实体E的多值属性M由单独的模式EM表示模式

EM

有对应于E的主码及多值属性M

组成的的属性集例子：employee的多值属性dependent_names

表示为如下模式:

employee_dependent_names=(

employee_id,dname)

每个多值属性的值映射到在模式EM上的关系的一个单独的元组例子：一个主码为123-45-6789的employee实体及亲属Jack和Jane映射到两个元组:

(123-45-6789,Jack)and(123-45-6789,Jane)*特殊化表示为模式方法1:为上层实体集建立一个模式为每个低层实体集建立一个模式，包含本地属性和高层实体集的主码

schema

attributes

person name,street,city

customer name,credit_rating

employee name,salary缺点:

得到关于的employee

的信息需要访问连个关系，分别对应于一个高层已一个低层模式*泛化表示为模式(Cont.)方法2:

对每个实体集建立模式，该模式包含所有本地和继承的属性

schema

attributes

person name,street,city

customer name,street,city,credit_rating

employee name,street,city,salary

如果是全部泛化，泛化的实体集(person)对应的模式不需要存储信息可以被定义为包含泛化关系的视图关系但因为外码约束，显式的模式定义可能依然需要缺点:

对同时是客户和雇员的人，street

和city

可能被重复存储*聚集表示为模式为表示聚集，建立模式包含如下内容：聚集的联系集的主码关联的实体集的主码联系集的所有描述性属性例子：为表示聚集works_on和实体集manager间的联系集manages，建立如下模式：

manages(employee_id,branch_name,title,manager_name)*银行的关系模式强实体集导出的模式多值属性导出的模式关联强实体集的联系集导出的模式弱实体集导出的模式ISA联系导出的模式外码约束*银行的关系模式(Cont.)强实体集导出的模式branch=(branch_name,branch_city,assets)customer=(customer_id,customer_name,customer_street,customer_city)loan

=(loan_number,amount)account

=(account_number,balance)employee

=(employee_id,employee_name,telephone_number,start_date)多值属性导出的模式dependent_