第五章数据库设计和E-R模型.ppt

1、2020年7月22日1时38分,第五章: 实体 联系模型,2020年7月22日1时38分,第五章: 实体 联系模型,设计过程 建模 约束 E-R 图 设计中的问题 弱实体集 扩展的 E-R 特性 银行数据库的设计 数据库设计的其他问题,2020年7月22日1时38分,设计过程,用户需求规格说明 概念设计阶段 E-R 模型 功能需求规格说明 逻辑设计 关系模式建立 物理设计 定义数据库物理特征 设计中主要陷阱 冗余 不完整性,2020年7月22日1时38分,建立模型,数据库可以被建模为: 实体集合 实体间的联系 实体（entity） 是一个存在且区别于其他对象的对象 例子: 特定的一个人/公司/

2、事件/工厂 实体有属性（attributes） 例子: 人有名字和住址 实体集（entity set）是具有相同类型，即相同性质或属性的实体集合 例子: 所有人/公司/树/假期的集合,2020年7月22日1时38分,customer 和 loan 实体集合,customer_id customer_ customer_ customer_ loan_ amount name street city number,2020年7月22日1时38分,联系集,联系（relationship） 是一个几个实体间的关联 例子:HayesdepositorA-102customer 实体联系集account

3、 实体 联系集（relationship set） 是一个n 2 实体集间的数学关系（这些实体集不必互异），来源于实体集 (e1, e2, en) | e1 E1, e2 E2, , en En这里 (e1, e2, , en) 是联系 例子: (Hayes, A-102) depositor,2020年7月22日1时38分,联系集 borrower,2020年7月22日1时38分,联系集 (Cont.),属性可以是一个联系集中的性质（property） 例如, customer 和 account实体集间的depositor 联系集可以有属性access-date,2020年7月22日1时3

4、8分,联系集的度（degree）,指参与一个联系集的实体集数目 涉及两个实体集的联系集叫做二元（binary） (或两度)。总体上，大多数数据库系统中的联系集是二元的。 联系集可以涉及两个以上的实体集 涉及两个以上的实体集的联系集很少见,例子: 假设银行的雇员（employees）可以在多个支行有工作, 在不同支行有不同工作。 于是在实体集 employee、 job 和 branch间存在一个三元联系集,2020年7月22日1时38分,属性,实体由属性集代表，即实体集所有属性具有的描述性的性质 域（Domain） 每个属性允许的取值 属性的类型: 简单（simple）和复合（composit

5、e）属性 单值（Single-valued）和 多值（multi-valued）属性 例子: 多值属性 phone_numbers 派生（Derived） 属性 能够从其他属性计算得来 例子: 给定 date_of_birth，得到 age,例子: customer = (customer_id, customer_name, customer_street, customer_city )loan = (loan_number, amount ),2020年7月22日1时38分,复合（composite）属性,2020年7月22日1时38分,映射基数约束,表示一个实体通过一个联系集能够与多少

6、个实体相关联 在二元联系集中非常有用 对二元联系集，映射基数必须是下列类型之一： 一对一 一对多 多对一 多对多,2020年7月22日1时38分,映射基数（Mapping Cardinalities）,一对一,一对多,注意: A 和 B 中一些元素可以不被映射到另一集合中的任何元素上,2020年7月22日1时38分,映射基数（Cont.）,多对一,多对多,注意: A 和 B 中一些元素可以不被映射到另一集合中的任何元素上,2020年7月22日1时38分,码,超码：唯一标识别实体集中一个实体的属性集 候选码：最小的超码 主码：被选中的候选码,2020年7月22日1时38分,联系集的码,参与联系的

7、实体集的主码的组合形成联系集的一个超码 (customer_id, account_number) 是 depositor 的一个超码 注意：这意味着实体集对能在特定的联系集中最多有一个联系 例子: 如果需要对每个customer访问每个account跟踪所有 access_dates, 我们不能对每次访问假定一个联系。但，我们可以使用多值属性 当确定候选码时，必须考虑联系集的映射基数 当在多于一个候选码中选择主码时，需要考虑联系集的语义,2020年7月22日1时38分,E-R 图,矩形：实体集 菱形：联系集 线段：将属性连接到实体集，将实体集连接到联系集 椭圆：属性 双线：多值属性 虚线：派

8、生属性 下划线：主码属性,2020年7月22日1时38分,E-R 图：复合、多值、派生属性,2020年7月22日1时38分,具有属性的联系集,2020年7月22日1时38分,角色,一个联系的实体集不需要是相异的 如下，标签 “manager” 和 “worker” 叫做角色（ roles）， 它们指定employee 实体如何通过 works_for 联系集交互 E-R图中通过标示连接矩形和菱形的线段来表示角色 角色标签可选，用来阐明联系的语义,2020年7月22日1时38分,基数约束（Cardinality Constraints）,基数约束表示为联系集和实体集间的有向或无向线段： ( )表

9、示 “一” ( )表示“多” 一对一联系： 一个customer 通过联系borrower 最多与一个loan关联 一个 loan通过联系borrower 最多与一个customer关联,2020年7月22日1时38分,一对多联系,在一对多联系中，一个customer 通过联系borrower 与多个（包括零个）loan关联，一个 loan通过联系borrower 最多与一个customer关联,2020年7月22日1时38分,多对一联系,在多对一联系中，一个customer 通过联系borrower最多与一个loan关联，一个 loan通过联系borrower 与多个（包括零个）custom

10、er关联,2020年7月22日1时38分,多对多联系,一个 customer 通过联系borrower 与多个loan （包括零个）关联 一个 loan通过联系borrower 与多个（包括零个）customer关联,2020年7月22日1时38分,实体集在联系集上的参与,全参与（双线表示）: 实体集上每个实体参与联系集上的至少一个联系 例如： loan 在 borrower 上的参与是全参与 每个 loan 必须有一个customer 通过borrower 与之关联 部分参与：某些实体可以不参与联系集中任何联系 例如: customer 在 borrower 上的参与是部分参与,2020年7

11、月22日1时38分,基数约束的另一种表示符号,基数约束也能表示为参与约束,2020年7月22日1时38分,几种表示比较,2020年7月22日1时38分,三元联系E-R图,2020年7月22日1时38分,三元联系的基数约束,我们只允许三元（或更高度数）联系最多有一个箭头来表示基数约束 如：一个从 works_on 到 job 的箭头表示每个雇员在任一支行最多有一个工作 如果有超过一个箭头，则有两种意思解释： 如： 一个A, B 和 C间的三元联系R，箭头到 B 和 C 可以有如下意思： 1. 每个A 实体与 B 和 C中唯一的实体相关联 2. 每个(A, B)中实体对与C中唯一实体关联，且每个(

12、A, C)中实体对与B中唯一实体关联 上面二者有不同的形式 为避免混乱，我们规定超过一个箭头为非法,2020年7月22日1时38分,设计问题,实体集 vs. 属性选择主要基于建模企业的结构，以及所讨论的属性的语义 实体集 vs. 联系集可能的指导在于设计一个联系集去描述两个实体间的动作 二元联系集 vs. n元联系集 尽管可能用多个互异的二元联系集代替任何一个非二元（ n 2 ）联系集，一个 n 元联系集能够将多个实体参与一个联系表现的更清楚 联系属性的布局,2020年7月22日1时38分,实体集 vs. 属性,2020年7月22日1时38分,实体集 vs. 联系集,2020年7月22日1时3

13、8分,二元联系 vs. 非二元联系,有些非二元联系表示为二元联系更好 例子：三元联系 parents, 关联一个 child 到 他/她的 father 和 mother，该联系以两个二元联系father 和 mother表达更好 使用两个二元联系允许部分信息（如：只知道mother ） 但一些联系是“自然的”非二元 例如: works_on 思考：民政局要记录人的家庭（婚姻、亲子（血亲、非血亲）、社会（工作）关系。提示：一个实体“人”。,2020年7月22日1时38分,非二元联系转换为二元形式,总之，通过建立一个人为的实体集，任何非二元联系能够被二元联系替换。 使用实体集 E以及三个联系集，

14、代替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,2020年7月22日1时38分,非二元联系转换为二元形式(Cont.),并需要约束转换 转换所有约束也许不可能 在转换后的模式的实例中，可能有的实例不能与 R 中任何

15、实例相对应 练习: 增加约束到联系RA、RB 和 RC， 以确保新建立的实体对应于实体集A、B 和 C每个中严格的一个实体 我们能够避免建立标识属性，通过使E 成为一个被三个联系集标识的弱实体集,2020年7月22日1时38分,联系属性的布局：映射基数影响E-R设计,如果每个帐户只能有一个客户，可以让 access-date 成为 account 的一个属性, 而不是联系的属性, 即是, 该从account到customer联系是多对一（等价地， customer到 account是一对多）,2020年7月22日1时38分,弱实体集（Weak Entity Sets）,一个没有主码的实体集称为

16、弱实体集（ weak entity set ） 弱实体集的存在依赖于标识实体集(identifying entity set )或属主实体集（owner entity set）的存在 它必须与标识实体集通过一个从标识实体集到弱实体集的完全、一对多的联系集相连 标识性联系（Identifying relationship）使用双线菱形描画 弱实体集的分辨符（discriminator） (或部分码）是区分弱实体集的所有实体的属性集合 弱实体集的主码由弱实体集存在依赖于的强实体集的主码，加上弱实体集的分辨符组成,2020年7月22日1时38分,弱实体集 (Cont.),使用双线矩形描画弱实体集 使

17、用虚线下划线描画弱实体集的分辨符 payment_number payment 实体集的分辨符 payment 的主码 (loan_number, payment_number),2020年7月22日1时38分,弱实体集 (Cont.),注意: 强实体集主码并不显式地存储在弱实体集中，因为它隐含在标识性联系中 如果 loan_number 被显式存储，payment 应该成为强实体，但这样payment 和 loan 间的联系被一个隐含联系重复了，该隐含的联系被payment 和 loan共有的属性 loan_number 定义了 弱实体集可以参与标识性联系以外的其他联系 弱实体集可以作为属主

18、参与到与另一个弱实体集的标识性联系中 弱实体集可以与不止一个标识实体集联系 如果弱实体集属性不多，也没有参与到标识性联系以外的其他联系，我们可以选择将弱实体集表示为属主实体集的一个多值复合属性,2020年7月22日1时38分,更多弱实体集例子,在大学里，course 是强实体，course_offering 能够被建模为弱实体 course_offering的分辨符可以是 semester (包括 year) 和section_number (如果有超过一个部分) 如果我们建模 course_offering 为一个强实体，我们应该建模course_number 为一个属性。这样，与 cour

19、se 的联系应该隐含course_number 属性，就重复了。,2020年7月22日1时38分,扩展的 E-R 特性: 特殊化（Specialization）,自上而下（top-down）的设计过程。我们在一个实体集中设计互异的子群 这些子群变成低层实体集，这些实体集有属性或参与对高层实体集不适用的联系 三角形组件描画，标示为 ISA (如： customer “is a” person) 属性继承 一个低层实体集继承其相连高层实体集的全部属性，以及继承地参与到其高层实体集参与的联系中 单继承：给定低层实体集参与到一个ISA联系中 多继承：给定低层实体集参与到一个以上ISA联系中,2020年

20、7月22日1时38分,特殊化例子,2020年7月22日1时38分,扩展 E-R 特性: 泛化（Generalization）,自下而上（bottom-up）设计过程 组合共享同样特性的实体集到高层实体集 特殊化和泛化是简单的互逆过程，在 E-R 图中以同样方式描画 术语特殊化和泛化常被互换地使用,2020年7月22日1时38分,特殊化和泛化 (Cont.),基于不同的特性，实体集可以有多种特殊化方式 如： permanent_employee vs. temporary_employee， 以及 officer vs. secretary vs. teller 每个特定的 employee 应

21、该是 permanent_employee 或 temporary_employee 的一个成员 同时也是officer、secretary 或 teller 的一个成员 ISA 联系也用来指代 父类 子类（superclass subclass） 联系,2020年7月22日1时38分,特殊化/泛化上的约束设计,判定哪些实体能够成为给定低层实体集的成员 条件定义的 成员资格的确定基于实体是否满足一个显式的条件或谓词 例子：所有65岁以上的客户是 senior-citizen 的成员，senior-citizen ISA person 用户定义的 不是条件判定，而是用户指派 约束或非约束的实体可

22、以属于单一泛化中超过一个低层实体集 分离的（disjoint） 一个实体只能够属于一个低层实体集 注意 E-R 图中在 ISA 三角旁书写disjoint 重叠的（overlapping） 一个实体能够属于超过一个低层实体集,2020年7月22日1时38分,特殊化/泛化上的约束设计 (Cont.),完全性约束（Completeness constraint） - 指定一个高层泛化实体集是否必须属于至少一个低层实体集 全部特殊化或泛化:一个实体必须属于低层实体集中的一个 部分特殊化或泛化: 一个实体不需要属于低层实体集中的一个,2020年7月22日1时38分,聚集（Aggregation）,考虑

23、前面提到的三元联系 works_on 假设我们想要记录管理者，该管理者管理一个支行的一个雇员完成的工作,2020年7月22日1时38分,聚集 (Cont.),联系集 works_on 和 manages 代表重叠的信息 每个manages 联系对应于一个 works_on 联系 但是, 一些 works_on 联系可以不对应于任何manages 联系 所以我们不能丢弃 works_on 联系 通过聚集可以消除这种冗余 允许联系间的联系 把联系当成一个抽象实体对待 抽象联系成为新实体 不再引入冗余，下面图形代表 : 一个雇员在特定支行的特定工作（job）上工作(work on) 一个雇员（emp

24、loyee） 、支行（branch） 、工作（job）的组合可以有一个关联的管理者（ manager）,2020年7月22日1时38分,包含聚集的E-R图,2020年7月22日1时38分,E-R 图使用的符号汇总,2020年7月22日1时38分,符号汇总(Cont.),2020年7月22日1时38分,E-R 设计决定,使用属性或实体集代表一个对象 一个真实世界中的概念最好表示为实体集或联系集 使用三元联系或二元联系 使用强实体集或弱实体集. 使用特殊化/泛化 对设计中的模块结构有贡献 使用聚集 能够将聚集实体集当成单个单元对待，而不必关心其内部结构 正确的设计决定来源于对被建模企业的深刻理解！

25、,2020年7月22日1时38分,银行数据库设计,银行数据库的数据需求 银行数据库中的实体集 银行数据库中的联系集 银行数据库中的E-R图,2020年7月22日1时38分,银行数据库的数据需求,银行有多个支行。每个支行位于某个城市，由唯一的名字标识。银行监控每个支行的资产。 银行的客户通过其customer_id值来标识。银行存储每个客户的姓名及其居住的街道和城市。客户可以有账户，并且可以贷款。客户可能同某个银行员工发生联系，该员工作为此客户的贷款负责人或私人助理。 银行员工通过其employee_id值来标识。银行的管理机构存储每个员工的姓名、电话号码、亲属姓名及其经理的employee_i

26、d号码。银行还需要知道员工开始工作的日期，由此日期可以推知员工的雇佣期。,2020年7月22日1时38分,银行数据库的数据需求（Cont.）,银行提供两类账户支票账户和储蓄存款账户。账户可以由两个或两个以上客户共有，一个客户也可以有两个或两个以上的账户。每个账户被赋予唯一的账户号。银行记录每个账户的余额以及每个账户拥有者访问该账户的最近日期。另外，每个储蓄存款账户有其利率，而每个支票账户有其透支额。 每笔贷款由某个支行发放，能被一个或多个客户所共有。一笔贷款用一个唯一的贷款号标识。银行需要知道每笔贷款所贷金额以及逐次还款情况。虽然贷款的还款号并不能唯一地标识银行所有贷款中的某个特定的还款，但可

27、以唯一地标识对某贷款的所还款项。对每次的还款需要记载其日期和金额。 真实的银行中，还应像记载对贷款的所还款项那样来记载每个储蓄存款账户或支票账户中取出或存入的金额。由于这些记载的建模过程类似，并且为了保持示例的简洁性，在我们的模型中不考虑对存款和取款的记录。,2020年7月22日1时38分,银行数据库中的实体集,数据需求规格说明是建造数据库概念模式的出发点。由前面数据需求规格说明所列举的特点，我们开始标识实体集及其属性： 实体集branch，具有属性branch_name、branch_city和assets。 实体集customer，具有属性customer_id、customer_name

28、、customer_street和customer_city。此外还可以考虑加上属性banker_name。 实体集employee，具有属性employee_id、employee_name、telephone_number、salary和manager；此外还包括多值属性dependent_name，基属性start_date及其派生属性employment_length。,2020年7月22日1时38分,银行数据库中的实体集（Cont.）,两个账户实体savings_account和checking_account，它们共同的属性是account_number和balance；此外sav

29、ings_account还具有属性interest_rate，checking_account还具有属性overdraft_amount。 实体集loan，具有属性loan_number、amount和originating_branch。 弱实体集payment，具有属性payment_number、payment_date和payment_amount。,2020年7月22日1时38分,银行数据库中的联系集,在前面的设计模式上，我们定义如下联系集和映射基数。在这个过程中我们还要对前面关于实体集属性的决策进一步精化。 borrower，是customer和loan间的一个多对多联系集。 lo

30、an_branch，指明产生贷款的银行支行的多对一联系集。注意这个联系代替了loan实体集的originating_branch属性。 loan_payment，从loan到payment的一对多联系集，表明一笔款项是为某笔贷款而付的。,2020年7月22日1时38分,银行数据库中的联系集（Cont.）,depositor，具有联系属性access_date，是customer和account间的多对多联系集，表明某个客户拥有某个账户。 cust_banker，具有联系属性type的一个多对一联系集，表明一个客户可以从一个银行员工处获得建议，而一个银行员工可以为一个或多个客户提供建议。注意这个

31、联系集代替了customer实体集的banker_name属性。 works_for，具有manager角色和具有worker角色的employee实体之间的联系集；其映射基数表明了一个员工仅为一个经理工作，而一个经理监督一个或多个员工。请注意我们用这一联系集代替了employee实体集的manager属性。,2020年7月22日1时38分,银行的 E-R 图,2020年7月22日1时38分,从E-R图转换到关系模式,主码允许实体集和联系集一律被表示为数据库的关系模式 一个符合E-R图的数据库能够被模式集所表示 对每个实体集和联系集有一个唯一的模式，该模式被赋予相应实体集或联系集的名字 每个模

32、式有限个列（总体上对应于属性），每个列有唯一的名字,2020年7月22日1时38分,实体集表示为模式,强实体集转换为具有同样属性的模式 弱实体集转换为包含标识实体集主码的表，如： payment = ( loan_number, payment_number, payment_date, payment_amount ),2020年7月22日1时38分,联系集表示为模式,一个多对多联系集表示为一个具有（两个）参与实体集主码的模式，并且该模式包含所有该联系集的描述性属性 例子: 联系集borrower的关系模式： borrower = (customer_id, loan_number ),20

33、20年7月22日1时38分,模式中的冗余,在多边全参与的多对一以及一对多联系集，能够被表示为：增加一个额外的属性到“多”边，该属性包含“一”边的主码 例子: 不是为联系集account_branch 建立模式，而是增加一个属性branch_name 到由实体集account建立的模式中 模式account的主码应当还是account_number，但应当增加外码约束branch_name到模式branch ）,2020年7月22日1时38分,模式中的冗余(Cont.),对一对一联系集，任何一边能够用来做“多”边对待 即, 额外的属性能够增加到与任何一个实体集相应的模式中 如果在“多”边是部分参

34、与，可如前处理，但将造成“多”边(所增加的属性)的null值 连接弱实体集和标识强实体集的联系集的相应模式是冗余的 例子: payment 模式包含了出现在loan_payment模式中的属性 (即， loan_number 和 payment_number),2020年7月22日1时38分,复合及多值属性,复合属性处理：为每个组成属性建立一个分离的属性 例子: 实体集 customer 有复合属性 name， name 包含组成属性first_name 和 last_name，则相应模式包含两个属性 first_name 和 last_name 实体 E 的多值属性 M 由单独的模式 EM

35、表示 模式 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),2020年7月22日1时38分,特殊化表示为模式,方法 1: 为上层实体集建立一

36、个模式 为每个低层实体集建立一个模式，包含本地属性和高层实体集的主码 schema attributes person name, street, city customer name, credit_rating employee name, salary 缺点: 得到关于的 employee 的信息需要访问连个关系，分别对应于一个高层已一个低层模式,2020年7月22日1时38分,泛化表示为模式(Cont.),方法 2: 对每个实体集建立模式，该模式包含所有本地和继承的属性 schema attributes person name, street, city customer name,

37、 street, city, credit_rating employee name, street, city, salary 如果是全部泛化，泛化的实体集(person)对应的模式不需要存储信息 可以被定义为包含泛化关系的视图关系 但因为外码约束，显式的模式定义可能依然需要 缺点: 对同时是客户和雇员的人，street 和 city 可能被重复存储,2020年7月22日1时38分,聚集表示为模式,为表示聚集，建立模式包含如下内容： 聚集的联系集的主码 关联的实体集的主码 联系集的所有描述性属性 例子：为表示聚集 works_on 和实体集manager间的联系集manages，建立如下模式

38、： manages (employee_id, branch_name, title, manager_name),2020年7月22日1时38分,银行的关系模式,强实体集导出的模式 多值属性导出的模式 关联强实体集的联系集导出的模式 弱实体集导出的模式 ISA联系导出的模式 外码约束,2020年7月22日1时38分,银行的关系模式(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_name = (employee_id, d_name),2020年7月22日1时38分,银行的关系模