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

《数据库设计和E-R模型.ppt》由会员分享，可在线阅读，更多相关《数据库设计和E-R模型.ppt（79页珍藏版）》请在三一办公上搜索。

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

2、是具有相同类型，即相同性质或属性的实体集合例子:所有人/公司/树/假期的集合,2023/9/11,customer 和 loan 实体集合,customer_id customer_ customer_ customer_ loan_ amount name street city number,2023/9/11,联系集,联系（relationship）是一个几个实体间的关联例子:HayesdepositorA-102customer 实体联系集account 实体联系集（relationship set）是一个n 2 实体集间的数学关系（这些实体集不必互异），来源于实体集(e1,e2,en

3、)|e1 E1,e2 E2,en En这里(e1,e2,en)是联系例子:(Hayes,A-102)depositor,2023/9/11,联系集 borrower,2023/9/11,联系集(Cont.),属性可以是一个联系集中的性质（property）例如,customer 和 account实体集间的depositor 联系集可以有属性access-date,2023/9/11,联系集的度（degree）,指参与一个联系集的实体集数目涉及两个实体集的联系集叫做二元（binary）(或两度)。总体上，大多数数据库系统中的联系集是二元的。联系集可以涉及两个以上的实体集涉及两个以上的实体集的联

4、系集很少见,例子:假设银行的雇员（employees）可以在多个支行有工作,在不同支行有不同工作。于是在实体集 employee、job 和 branch间存在一个三元联系集,2023/9/11,属性,实体由属性集代表，即实体集所有属性具有的描述性的性质域（Domain）每个属性允许的取值 属性的类型:简单（simple）和复合（composite）属性单值（Single-valued）和 多值（multi-valued）属性例子:多值属性 phone_numbers派生（Derived）属性能够从其他属性计算得来例子:给定 date_of_birth，得到 age,例子:customer=(

5、customer_id,customer_name,customer_street,customer_city)loan=(loan_number,amount),2023/9/11,复合（composite）属性,2023/9/11,映射基数约束,表示一个实体通过一个联系集能够与多少个实体相关联在二元联系集中非常有用对二元联系集，映射基数必须是下列类型之一：一对一一对多多对一多对多,2023/9/11,映射基数（Mapping Cardinalities）,一对一,一对多,注意:A 和 B 中一些元素可以不被映射到另一集合中的任何元素上,2023/9/11,映射基数（Cont.）,多对一,多

6、对多,注意:A 和 B 中一些元素可以不被映射到另一集合中的任何元素上,2023/9/11,码,超码：唯一标识别实体集中一个实体的属性集 候选码：最小的超码主码：被选中的候选码,2023/9/11,联系集的码,参与联系的实体集的主码的组合形成联系集的一个超码(customer_id,account_number)是 depositor 的一个超码注意：这意味着实体集对能在特定的联系集中最多有一个联系 例子:如果需要对每个customer访问每个account跟踪所有 access_dates,我们不能对每次访问假定一个联系。但，我们可以使用多值属性当确定候选码时，必须考虑联系集的映射基数当在多

7、于一个候选码中选择主码时，需要考虑联系集的语义,2023/9/11,E-R 图,矩形：实体集菱形：联系集线段：将属性连接到实体集，将实体集连接到联系集椭圆：属性双线：多值属性虚线：派生属性下划线：主码属性,2023/9/11,E-R 图：复合、多值、派生属性,2023/9/11,具有属性的联系集,2023/9/11,角色,一个联系的实体集不需要是相异的如下，标签“manager”和“worker”叫做角色（roles），它们指定employee 实体如何通过 works_for 联系集交互E-R图中通过标示连接矩形和菱形的线段来表示角色角色标签可选，用来阐明联系的语义,2023/9/11,基数

8、约束（Cardinality Constraints）,基数约束表示为联系集和实体集间的有向或无向线段：()表示“一”()表示“多”一对一联系：一个customer 通过联系borrower 最多与一个loan关联一个 loan通过联系borrower 最多与一个customer关联,2023/9/11,一对多联系,在一对多联系中，一个customer 通过联系borrower 与多个（包括零个）loan关联，一个 loan通过联系borrower 最多与一个customer关联,2023/9/11,多对一联系,在多对一联系中，一个customer 通过联系borrower最多与一个loan关

9、联，一个 loan通过联系borrower 与多个（包括零个）customer关联,2023/9/11,多对多联系,一个 customer 通过联系borrower 与多个loan（包括零个）关联一个 loan通过联系borrower 与多个（包括零个）customer关联,2023/9/11,实体集在联系集上的参与,全参与（双线表示）:实体集上每个实体参与联系集上的至少一个联系例如：loan 在 borrower 上的参与是全参与 每个 loan 必须有一个customer 通过borrower 与之关联部分参与：某些实体可以不参与联系集中任何联系例如:customer 在 borrower

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

11、联上面二者有不同的形式为避免混乱，我们规定超过一个箭头为非法,2023/9/11,设计问题,实体集 vs.属性选择主要基于建模企业的结构，以及所讨论的属性的语义实体集 vs.联系集可能的指导在于设计一个联系集去描述两个实体间的动作二元联系集 vs.n元联系集 尽管可能用多个互异的二元联系集代替任何一个非二元（n 2）联系集，一个 n 元联系集能够将多个实体参与一个联系表现的更清楚联系属性的布局,2023/9/11,实体集 vs.属性,2023/9/11,实体集 vs.联系集,2023/9/11,二元联系 vs.非二元联系,有些非二元联系表示为二元联系更好例子：三元联系 parents,关联一个

12、 child 到 他/她的 father 和 mother，该联系以两个二元联系father 和 mother表达更好 使用两个二元联系允许部分信息（如：只知道mother）但一些联系是“自然的”非二元例如:works_on思考：民政局要记录人的家庭（婚姻、亲子（血亲、非血亲）、社会（工作）关系。提示：一个实体“人”。,2023/9/11,非二元联系转换为二元形式,总之，通过建立一个人为的实体集，任何非二元联系能够被二元联系替换。使用实体集 E以及三个联系集，代替A、B 和 C 间的联系 R:1.RA,关联 E 和 A 2.RB,关联 E 和 B3.RC,关联 E 和 C为 E 建立一个特殊的

13、标识属性如果联系集 R 有属性，将其赋给实体集 E 对 R 中每个联系(ai,bi,ci)，建立 1.实体集 E 中的一个新的实体 ei 2.增加(ei,ai)到 RA 3.增加(ei,bi)到 RB 4.增加(ei,ci)到 RC,2023/9/11,非二元联系转换为二元形式(Cont.),并需要约束转换转换所有约束也许不可能在转换后的模式的实例中，可能有的实例不能与 R 中任何实例相对应练习:增加约束到联系RA、RB 和 RC，以确保新建立的实体对应于实体集A、B 和 C每个中严格的一个实体我们能够避免建立标识属性，通过使E 成为一个被三个联系集标识的弱实体集,2023/9/11,联系属性

14、的布局：映射基数影响E-R设计,如果每个帐户只能有一个客户，可以让 access-date 成为 account 的一个属性,而不是联系的属性,即是,该从account到customer联系是多对一（等价地，customer到 account是一对多）,2023/9/11,弱实体集（Weak Entity Sets）,一个没有主码的实体集称为弱实体集（weak entity set）弱实体集的存在依赖于标识实体集(identifying entity set)或属主实体集（owner entity set）的存在它必须与标识实体集通过一个从标识实体集到弱实体集的完全、一对多的联系集相连标识性联

15、系（Identifying relationship）使用双线菱形描画弱实体集的分辨符（discriminator）(或部分码）是区分弱实体集的所有实体的属性集合弱实体集的主码由弱实体集存在依赖于的强实体集的主码，加上弱实体集的分辨符组成,2023/9/11,弱实体集(Cont.),使用双线矩形描画弱实体集使用虚线下划线描画弱实体集的分辨符payment_number payment 实体集的分辨符payment 的主码(loan_number,payment_number),2023/9/11,弱实体集(Cont.),注意:强实体集主码并不显式地存储在弱实体集中，因为它隐含在标识性联系中如果

16、 loan_number 被显式存储，payment 应该成为强实体，但这样payment 和 loan 间的联系被一个隐含联系重复了，该隐含的联系被payment 和 loan共有的属性 loan_number 定义了弱实体集可以参与标识性联系以外的其他联系弱实体集可以作为属主参与到与另一个弱实体集的标识性联系中弱实体集可以与不止一个标识实体集联系如果弱实体集属性不多，也没有参与到标识性联系以外的其他联系，我们可以选择将弱实体集表示为属主实体集的一个多值复合属性,2023/9/11,更多弱实体集例子,在大学里，course 是强实体，course_offering 能够被建模为弱实体cour

17、se_offering的分辨符可以是 semester(包括 year)和section_number(如果有超过一个部分)如果我们建模 course_offering 为一个强实体，我们应该建模course_number 为一个属性。这样，与 course 的联系应该隐含course_number 属性，就重复了。,2023/9/11,扩展的 E-R 特性:特殊化（Specialization）,自上而下（top-down）的设计过程。我们在一个实体集中设计互异的子群这些子群变成低层实体集，这些实体集有属性或参与对高层实体集不适用的联系三角形组件描画，标示为 ISA(如：customer“i

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

19、nt_employee vs.temporary_employee，以及 officer vs.secretary vs.teller每个特定的 employee 应该是 permanent_employee 或 temporary_employee 的一个成员 同时也是officer、secretary 或 teller 的一个成员 ISA 联系也用来指代 父类 子类（superclass subclass）联系,2023/9/11,特殊化/泛化上的约束设计,判定哪些实体能够成为给定低层实体集的成员条件定义的成员资格的确定基于实体是否满足一个显式的条件或谓词例子：所有65岁以上的客户是 se

20、nior-citizen 的成员，senior-citizen ISA person用户定义的不是条件判定，而是用户指派约束或非约束的实体可以属于单一泛化中超过一个低层实体集分离的（disjoint）一个实体只能够属于一个低层实体集注意 E-R 图中在 ISA 三角旁书写disjoint 重叠的（overlapping）一个实体能够属于超过一个低层实体集,2023/9/11,特殊化/泛化上的约束设计(Cont.),完全性约束（Completeness constraint）-指定一个高层泛化实体集是否必须属于至少一个低层实体集全部特殊化或泛化:一个实体必须属于低层实体集中的一个部分特殊化或泛化

21、:一个实体不需要属于低层实体集中的一个,2023/9/11,聚集（Aggregation）,考虑前面提到的三元联系 works_on 假设我们想要记录管理者，该管理者管理一个支行的一个雇员完成的工作,2023/9/11,聚集(Cont.),联系集 works_on 和 manages 代表重叠的信息每个manages 联系对应于一个 works_on 联系但是,一些 works_on 联系可以不对应于任何manages 联系 所以我们不能丢弃 works_on 联系通过聚集可以消除这种冗余允许联系间的联系把联系当成一个抽象实体对待抽象联系成为新实体不再引入冗余，下面图形代表:一个雇员在特定支行

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

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

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

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

26、考虑加上属性banker_name。实体集employee，具有属性employee_id、employee_name、telephone_number、salary和manager；此外还包括多值属性dependent_name，基属性start_date及其派生属性employment_length。,2023/9/11,银行数据库中的实体集（Cont.）,两个账户实体savings_account和checking_account，它们共同的属性是account_number和balance；此外savings_account还具有属性interest_rate，checking_acc

27、ount还具有属性overdraft_amount。实体集loan，具有属性loan_number、amount和originating_branch。弱实体集payment，具有属性payment_number、payment_date和payment_amount。,2023/9/11,银行数据库中的联系集,在前面的设计模式上，我们定义如下联系集和映射基数。在这个过程中我们还要对前面关于实体集属性的决策进一步精化。borrower，是customer和loan间的一个多对多联系集。loan_branch，指明产生贷款的银行支行的多对一联系集。注意这个联系代替了loan实体集的origina

28、ting_branch属性。loan_payment，从loan到payment的一对多联系集，表明一笔款项是为某笔贷款而付的。,2023/9/11,银行数据库中的联系集（Cont.）,depositor，具有联系属性access_date，是customer和account间的多对多联系集，表明某个客户拥有某个账户。cust_banker，具有联系属性type的一个多对一联系集，表明一个客户可以从一个银行员工处获得建议，而一个银行员工可以为一个或多个客户提供建议。注意这个联系集代替了customer实体集的banker_name属性。works_for，具有manager角色和具有worke

29、r角色的employee实体之间的联系集；其映射基数表明了一个员工仅为一个经理工作，而一个经理监督一个或多个员工。请注意我们用这一联系集代替了employee实体集的manager属性。,2023/9/11,银行的 E-R 图,2023/9/11,从E-R图转换到关系模式,主码允许实体集和联系集一律被表示为数据库的关系模式一个符合E-R图的数据库能够被模式集所表示对每个实体集和联系集有一个唯一的模式，该模式被赋予相应实体集或联系集的名字每个模式有限个列（总体上对应于属性），每个列有唯一的名字,2023/9/11,实体集表示为模式,强实体集转换为具有同样属性的模式弱实体集转换为包含标识实体集主码

30、的表，如：payment=(loan_number,payment_number,payment_date,payment_amount),2023/9/11,联系集表示为模式,一个多对多联系集表示为一个具有（两个）参与实体集主码的模式，并且该模式包含所有该联系集的描述性属性 例子:联系集borrower的关系模式：borrower=(customer_id,loan_number),2023/9/11,模式中的冗余,在多边全参与的多对一以及一对多联系集，能够被表示为：增加一个额外的属性到“多”边，该属性包含“一”边的主码例子:不是为联系集account_branch 建立模式，而是增加一个属

31、性branch_name 到由实体集account建立的模式中模式account的主码应当还是account_number，但应当增加外码约束branch_name到模式branch）,2023/9/11,模式中的冗余(Cont.),对一对一联系集，任何一边能够用来做“多”边对待即,额外的属性能够增加到与任何一个实体集相应的模式中 如果在“多”边是部分参与，可如前处理，但将造成“多”边(所增加的属性)的null值连接弱实体集和标识强实体集的联系集的相应模式是冗余的例子:payment 模式包含了出现在loan_payment模式中的属性(即，loan_number 和 payment_numb

32、er),2023/9/11,复合及多值属性,复合属性处理：为每个组成属性建立一个分离的属性例子:实体集 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 上

33、的关系的一个单独的元组例子：一个主码为123-45-6789的 employee 实体及亲属Jack 和 Jane 映射到两个元组:(123-45-6789,Jack)and(123-45-6789,Jane),2023/9/11,特殊化表示为模式,方法 1:为上层实体集建立一个模式 为每个低层实体集建立一个模式，包含本地属性和高层实体集的主码 schema attributes person name,street,city customer name,credit_rating employee name,salary缺点:得到关于的 employee 的信息需要访问连个关系，分别对应于一

34、个高层已一个低层模式,2023/9/11,泛化表示为模式(Cont.),方法 2:对每个实体集建立模式，该模式包含所有本地和继承的属性schema attributes person name,street,city customer name,street,city,credit_rating employee name,street,city,salary如果是全部泛化，泛化的实体集(person)对应的模式不需要存储信息可以被定义为包含泛化关系的视图关系但因为外码约束，显式的模式定义可能依然需要缺点:对同时是客户和雇员的人，street 和 city 可能被重复存储,2023/9/11,

35、聚集表示为模式,为表示聚集，建立模式包含如下内容：聚集的联系集的主码关联的实体集的主码联系集的所有描述性属性例子：为表示聚集 works_on 和实体集manager间的联系集manages，建立如下模式：manages(employee_id,branch_name,title,manager_name),2023/9/11,银行的关系模式,强实体集导出的模式多值属性导出的模式关联强实体集的联系集导出的模式弱实体集导出的模式ISA联系导出的模式外码约束,2023/9/11,银行的关系模式(Cont.),强实体集导出的模式branch=(branch_name,branch_city,asse

36、ts)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),2023/9/11,银行的关系模式(Cont.),关联强实体集的联系集导出的模式account_branch=(account_n

37、umber,branch_name)loan_branch=(loan_number,branch_name)borrower=(customer_id,l oan_number)depositor=(customer_id,account_number)cust_banker=(customer_id,employee_id,type)works_for=(worker_employee_id,manager_employee_id)弱实体集导出的模式Payment=(loan_number,payment_number,payment_date,payment_amount)ISA联系导出

38、的模式(允许账户既不是储蓄存款账户也不是支票账户的情况)savings_account=(account_number,interest_rate)checking_account=(account_number,overdraft_amount)外码约束,2023/9/11,UML,UML:Unified Modeling LanguageUML 具有为整个系统建立图示模型的很多组件UML 类图（Class Diagrams）对应于 E-R 图,但有一些不同,2023/9/11,UML 类图符号汇总,UML中非二元联系使用菱形（同E-R图）,E-R,UML（1.3后也使用菱形表示联系）,20

39、23/9/11,UML 类图符号汇总(Cont.),*基数约束标画位置是反的（3项右边的图：E2 to E1是多对一）*泛化可以独立disjoint/overlapping于之外使用汇合或分支的箭头,overlapping,disjoint,2023/9/11,课堂练习,1。为车辆保险公司设计一个E-R图。每个客户有一辆或多辆车，每辆车可以关联0次或多次事故的纪录。,2023/9/11,课堂练习解答,2023/9/11,课后练习,考虑一个为期末考试安排教室的大学数据库。这个数据库可被建模为单个的实体集exam,它具有属性course_name、section_number、room_number 和 time。也可以定义一个或多个附加实体集，同时用联系集来代替 exam 实体集的一些属性，例如：course有属性name、department和c_numbersection有属性s_number和enrollment，并作为依赖于course的一个弱实体集。room有属性r_number、capacity 和 building。a用 E-R 图来说明如何使用这三个附加实体集。b对于每个附加实体集，解释哪些应用特点会对决定是否加入它产生影响。,2023/9/11,第五章结束,