数据库系统原理与设计-第四章 数据库建模 下

数据库系统原理与设计-第四章 数据库建模 上

4.6 E-R建模问题（重点、难点）

E-R建模的基本原则

忠实性

• 设计应忠实于应用需求，这是首要的也是最重要的原则。即实体集、属性、联系集都应当反映现实世界及根据所了解的现实世界去建模。
• 例如，教师与开课班之间的联系集任教，是一对多还是多对多的联系集？如果规定一个开课班可能安排多名教师共同任教，则任教就是多对多联系集，联系属性为任教角色 (如“主讲”、“指导实验”、“辅导”等)。
  

简单性

• 除非有绝对需要，否则不要在设计中增加更多成分；
• 只需要对数据库使用者所关心、感兴趣的属性建模 。

避免冗余

• 原则：一个对象只存放在一个地方。

选择实体集还是属性

• 通常满足下述两条规则，均可作为属性对待：
  • 作为属性，不能再具有要描述的性质；
  • 属性不能和其它实体相联系。
• 对于复合属性，可将该复合属性的每一个子部分直接建模为一个属性，而不必建模为实体集。例如，学生实体集中的家庭住址可分成省份、城市、街道三个部分，因此可将省份、城市、街道分别单独作为学生实体集的属性进行建模。
• 对于一个事物，如果需要描述它的若干个性质，可考虑作为实体集建模。
  • 如，开课班弱实体集中的上课地点，如果除了教室编号之外，还需要描述更多信息，如所在教学楼、电话号码、教室类型、教室容量等，则需将属性上课地点转化为实体集教室，以实现教室管理功能。
    
• 假设一个教室允许安排多个开课班上课(上课时间不能冲突)，一个开课班也需要安排多个时间上课，且不同时间可能安排在相同的或不同的教室上课，则教室实体集与开课班弱实体集之间存在多对多的排时间教室联系集，上课时间为联系属性。
  • 说明：排时间教室不仅是多对多的联系集，而且是多值联系。因为一个开课班在不同的上课时间可能安排在同一个教室上课 (即一个开课班与一个教室之间可能存在多个联系)。
  • 如果一个开课班的每次上课时间都安排在不同的教室，那就不是多值联系了。
  • 4.6.3节进一步讨论这个问题。
• 选择实体集还是属性常犯两个错误：
  • 将一实体集的主码作为另一实体集的属性，而不是使用联系；
  • 将相关实体集的主码属性作为联系集的属性。因为联系集已隐含了实体集的主码属性。

选择实体集还是联系集

• 一事物是描述为实体集还是联系集并没有一个绝对的标准。
• 通常原则：
  • 实体对应于现实世界中实际存在的事物，是名词。
    • 如学生、教师和课程是名词，可作为实体集建模。
  • 联系对应的概念一般为一种动作，即描述实体间的一种行为。
    • 如选课、授课是动词，因此作为联系集建模。
• 依赖约束和多值联系可能会导致将联系集建模为依赖实体集或弱实体集。

多元联系转化为二元联系

• 如图(a)所示的是供应商、项目、零件之间的多对多三元联系集供需，联系属性有需求量、供应量等。
  
• 三元联系转化为二元联系的一般方法：
  • 通过聚合将二元联系集建模成一个联系实体集，再加上它与原来联系的实体集之间的二元联系，如图(b)所示；
  • 或者建立一个依赖实体集或弱实体集，再与原实体集之间建立二元联系，如图©、图(d)所示。
• 三元联系集选课-任教，描述了学生、课程、教师之间的多对多的联系语义。
  • 如果将其转化为学生与课程之间的选课以及教师与课程之间的授课2个二元联系，则这两个二元联系不能反映学生所选修课程是由谁授课的联系语义。
  • 问题出在一门课程可能会安排多个开课班，从而会安排多名教师授课(不同于一个开课班安排多名教师任教的语义)，而学生只是选择其中的一个开课班进行修读。
    
• 考虑学生、开课班、教师之间的三元联系集选课-任教。
  
  • 先在实体集开课班与教师之间建立一个二元联系集任教，再在联系实体集任教与学生实体集之间建立二元联系集选课，如图(b)所示。
    • 假设任教是多对多的联系语义，则联系实体集任教的主码是{课程号, 开课班号, 教师编号}。
    • 学生选课的语义是：选择了某课程的某开课班，也就选择了为该开课班所安排的所有任课教师，而不能选择该开课班的某个(些)任课教师.
  • 先在(弱)实体集开课班与教师之间引入一个依赖实体集(或弱实体集)开课班教师安排，再在依赖实体集开课班教师安排与学生实体集之间建立一个二元联系集选课，如图©所示。
    • 该方案本质上与图(b)所示的方案相同，差别在于联系实体集与依赖实体集(或弱实体集)的主码不同。
    • 而依赖实体集开课班教师安排的主码是编号，{课程号, 开课班号}和教师编号分别是参照(弱)实体集开课班和教师的外码。
    • 该方案也不能反映学生选课的语义
  • 正确的转化方案如下图所示，它间接地表示了学生、开课班、教师之间的多对多三元联系选课-任教。
    • 这是因为，若学生选修了某课程的某开课班，则可间接地通过开课班与教师之间的联系集任教来获得为该开课班所安排的所有任课教师(即为该学生授课的教师)。
      

依赖约束的建模

• 对于商品销售业务，直观上的建模思路有：
  • 在员工、客户与商品实体集之间建立多对多的 3 元联系集“销售-购买” 。
    
• 该建模思路存在如下2个问题：
  • 数据冗余。在销售-购买联系集中，由于有的属性只依赖于一次销售-购买业务，而不依赖于该次业务中的每一件商品,如销售单号、销售日期等属性，这样将造成数据冗余。
  • 多值联系。由于一个员工、一个客户与一件商品之间可能发生多次销售-购买，即多对多的 3 元联系集销售-购买是多值联系。
• 伴随着商品销售业务的发生，会产生销货单(或购货单)。
  • 如果将销货单建模为实体集，则在销货单与商品、员工、客户实体集之间分别存在着商品销售、经销、采购联系集。
  • 销货单实体集与商品销售、经销、采购联系集之间存在依赖约束，销货单是依赖实体集。
    
• 依赖于联系集而存在的实体集一般是指伴随着业务发生而形成的单据。如员工、客户、商品之间发生销售/购买商品等业务时，伴随着会产生销货单/购货单。
  • 在E-R建模时，一般将依赖于业务的发生而产生的销货单/购货单等直接建模为依赖实体集(而不是联系集)，并将它直接与所依赖的联系集关联起来。
• 类似的业务有：
  • 领料员/采购员、仓库保管员、材料之间发生的出库/入库业务会伴随着产生出库单/入库单；
  • 读者、图书管理员、图书之间发生的借书业务会伴随着产生借书单；
  • 客户、员工、现金之间发生的存款/取款业务会伴随着产生存款单/取款单;
  • 病人、医生、药品之间发生的诊断业务会伴随着产生病历记录-处方单；
  • 旅客、员工、客房之间发生的入住业务会伴随着产生入住单；
  • 司机、警察、违章处罚目录之间发生的违章处罚业务会伴随着产生违章处罚单；
  • 员工、游客、景点之间发生的旅游业务会伴随着产生旅游安排单；
  • 公交车、车站之间发生的运行安排业务会伴随着产生公交线路。

在商品销售业务中，再对直观上的建模思路进行分析：

• 方案一：第一步先在员工与客户实体集之间建立多对多的销售/购买联系集，第二步再通过聚合在销售/购买联系集(即联系实体集)与商品实体集之间建立商品销售联系集。
  
  • 由于一个员工与一个客户之间可能会发生多次销售/购买业务，因此，多对多的销售/购买联系集是多值联系。
  • 根据4.6.3节关于多值联系的建模方法可知，只要将多值联系集单独建模为一个依赖实体集或弱实体集即可。
  • 在将多值联系集销售/购买转化为销货单/购货单依赖实体集建模之后，该E-R图将转化为图4-27所示的了。
• 方案二：第一步先在员工与商品实体集之间建立多对多的销售商品联系集，联系属性有销售日期、销售数量、销售单价等；第二步再通过聚合在销售商品联系集(即联系实体集)与客户实体集之间建立进货联系集。
  • 该建模思路存在如下2个问题：
    • 数据冗余。由于销售商品联系集中，有的属性只依赖于一次商品销售业务，而不依赖于该次业务中销售的每一件商品，如销售日期等属性，这样将造成数据冗余。
    • 多值联系。由于一个员工与一件商品之间可发生多次销售，因此，多对多的联系集销售商品是多值联系。
• 在商品销售业务中，再对直观上的建模思路进行分析：
  • 方案三：第一步先在客户与商品实体集之间建立多对多的购买商品联系集，联系属性有购买日期、购买数量、购买单价等；第二步再通过聚合在购买商品联系集与员工实体集之间建立办理联系集。
    
  • 方案三的建模思路与方案二类似，存在着相同的问题。

多值联系的建模

• 考虑实体集教师与课程之间的多对多授课联系集。由于一个教师可能会讲授同一门课程多次，即授课联系集是多值联系。
  

• 为了唯一标识多值联系中的多个联系，可以考虑将多值联系建模为一个依赖实体集或弱实体集，该弱实体集依赖于与它相关联的各个实体集，或该依赖实体集依赖于与它相关联的各个联系集。也就是说，多值联系的建模问题可转化为依赖约束的建模问题。

将多值联系建模为弱实体集

• 一方面，如果开课班还没有明确任课教师，则该开课班无法存在;
• 另一方面，如果一个开课班需要安排多名教师任教，则无法安排,因为弱实体集与其所依赖的实体集之间只能存在多对一的联系集.
• 因此，应该将开课班建模为仅依赖于课程实体集的弱实体集，同时弱实体集开课班也依赖于联系集任教。
  

将多值联系建模为依赖实体集

• 为了唯一标识多值联系中的多个联系，也可以将开课班直接建模为一个同时依赖于排课、任教联系集的依赖实体集，此时开课班号为主码，要求能够唯一标识所有课程在所有学期开设的教学班(即开课班号全局不允许出现重号)。
  

  • 考虑多对多的排时间教室联系集，假设一个开课班可能安排多个时间上课，且不同时间可能安排在相同的或不同的教室上课，则排时间教室联系集可能是多值联系。

  • 因此，可以考虑将排时间教室联系集建模为一个同时依赖于开课班和教室(弱)实体集的时间安排弱实体集，属性有上课时间(作为部分码)。
    

  • 同时依赖于开课班和教室(弱)实体集的时间安排弱实体集，要求排上课时间和排上课教室必须同时完成，显然这样的依赖约束不满足教学管理的需要。

  • 教学管理语义：先安排开课班的上课时间，再安排上课教室.

  • 应该将时间安排建模为仅依赖于开课班的弱实体集，同时弱实体集时间安排也依赖于联系集排教室。
    

总结

• E-R模型
  • 实体、属性与实体集（复合、多值属性）
  • 联系、联系属性与联系集，二元联系的主码与联系属性的安排
  • 映射基数(1:1、1:n、m:1、m:n联系)、依赖约束、多值联系
  • 弱实体集、部分码
  • 扩展特征：类层次与聚合(建模为联系实体集)
  • 依赖约束的建模：建模为依赖实体集或弱实体集
  • 多值联系的建模：转化为依赖约束的建模
• E-R模型设计原则
  • 忠实性、简单性、避免冗余
  • 选择实体集还是属性？
  • 选择实体集还是联系集？（依赖约束、多值联系的建模）
  • 多元联系转化为二元联系：联系实体集、依赖实体集或弱实体集

ER符号汇览

4.7 数据库概念设计实例——大学选课系统

4.8 逻辑设计——E-R模型转化为关系模型（重点）

E-R模型转化方法

• E-R模型(概念建模)和关系模型(逻辑建模)都是对现实世界的抽象。而E-R模型只是描述数据库的概念模型，若要被关系数据库所接受，必须进行信息转化，即将E-R模型转化为关系数据库所支持的逻辑模型——数据库模式(关系模式的集合) 。
• 转化方法
  • 强实体集转化方法
  • 弱实体集转化方法
  • 联系集转化方法
  • 复合属性及多值属性转化方法
  • 类层次转化方法
  • 聚合转化方法

强实体集转化方法

• 将强实体集映射成关系模式很直接，只需将实体集的每个属性对应为关系模式的属性，实体集的码作为关系模式的码。
• 设强实体集E具有a1, a2, …, an属性，其转化的关系模式定义如下：
  • 关系模式名：E；
  • 属性集：a1, a2, …, an；
  • 主码：实体集E的主码；
  • 外码：无。
• 例如，由实体集课程Course转化的关系模式为（加下划线的属性表示它是主码成员）：
  • Course (courseNo, courseName, creditHour, courseHour)

弱实体集转化方法

• 设弱实体集A具有属性集{a1, a2, …, am}，且{p1, p2, …, pk}为A的部分码(∀pi∈{a1, a2, …, am}, 1≤i≤k, k≤m)；B是A所依赖的强实体集且主码为属性集{b1, b2, …, bn}，则A转化的关系模式定义如下：
  • 关系模式名：A；
  • 属性集: {a1, a2, …, am} ∪ {b1, b2, …, bn}；
  • 主码: {b1, b2, …, bn} ∪ {p1, p2, …, pk}；
  • 外码: 参照关系B的属性b1, b2, …, bn。
• 例如，由弱实体集开课班CourseClass转化的关系模式为(外码属性成员用斜体表示\加下划线的属性表示它是部分码)：
  • CourseClass ( courseNo, cClassNo, year, semester, capacity, enrollNumber)

联系集转化方法

联系集一般转化方法

• 设R是一联系集，其描述性属性集为{a1, a2, …, am}；参与R的所有实体集ES的主码的并集形成属性集合{b1, b2, …, bn}——联系集的超码，则由R转化的关系模式定义如下：
  • 关系模式名：R；
  • 属性集: {a1, a2, …, am} ∪ {b1, b2, …, bn}；
  • 主码: 按映射基数对应规则确定；
  • 外码: 参照参与关系Ei∈ES及各自对应的主码属性b1, b2, …, bn。

一对多或一对一联系集的转化

• 可不转化为单独的关系模式，而采用下列方法转化：
  • 若A到B联系集为一对多联系，则在由B(多方) 转化的关系模式中，增加A(一方)的主码属性作为参照A主码的外码，同时将联系属性也放入由B(多方)转化的关系模式中。
• 例如，联系集聘用(Engage)为实体集学院(Institute)与实体集教师(Teacher)之间的一对多联系集。 可转化为：(外码属性成员用斜体表示\加下划线的属性表示它是部分码\粗体是联系属性)
  • Teacher (teacherNo, tearcherName, title, degree, hireDate, instituteNo)
  • 若A到B联系集为一对一联系，则将某一方的主码属性增加到另一方实体集所转化的关系模式中去。

标识联系集的转化

• 不需转化为任何关系模式

复合属性转化方法

• 应为每个子属性创建一个单独的属性，而不是为复合属性自身创建一个单独的属性。
• 例如，由实体集学生Student转化而来的关系模式为：
  • Student (studentNo, studentName, sex, birthday, province, city, street)
  • address属性被其复合属性province, city, street代替。

多值属性转化方法

• 创建一个新的关系模式，其属性为多值属性所在的实体集(或联系集)的主码属性和该多值属性对应的属性组成，主码为全部属性。
• 设M为多值属性，M对应的属性集为A；E为M所在的实体集 (或联系集)，且E的主码为属性集 {b1, b2, …, bn}，则由M转化的关系模式定义如下：
  • 关系模式名：M；
  • 属性集：A ∪ {b1, b2, …, bn}；
  • 主码：A ∪ {b1, b2, …, bn}；
  • 外码：参照关系E的主码属性b1, b2, …, bn。
• 例如，Student的电话号码phoneNumber为多值属性，关系模式为：
  • phoneNumber (studentNo, pNumber)
    ——可以将多值属性建模为弱实体集！

类层次转化两种方法：

• 父类实体集和所有的子类实体集分别转化为单独的模式。其中，父类实体集对应的关系模式属性为父类实体集的属性（即公共属性）；而各子类实体集对应的模式由该子类实体集的特殊属性和父类实体集的主码属性组成，各子类实体集的主码与父类实体集的主码相同。

• 只将所有的子类实体集转化为关系模式，其属性由父类实体集的公共属性和各子类实体集的特殊属性组成。

• 例如，按第1种方法，父类实体集Student和子类实体集Undergraduate、Graduate可转化为3个关系模式：

  • Student (studentNo, studentName, sex, birthday, province, city, street)
  • Undergraduate (studentNo, interest)
  • Graduate (studentNo, direction)

• 按第2种方法，则只转化为2个关系模式：

  • Undergraduate (studentNo, studentName, sex, birthday, province, city, street, interest )
  • Graduate (studentNo, studentName, sex, birthday, province, city, street, direction)
    ——各自的优缺点分别是什么？

聚合的转化方法：

• 聚合是一种抽象。
• 内层联系集、外层联系集都是按其映射基数决定是否需要单独转化为一个独立的关系模式(多对多联系集才需要)；
  • 外层联系集的主码根据映射基数不同分别由内层联系集(即联系实体集)的主码、外层实体集的主码按不同方式产生。
• 如，由学生与课程之间的多对多的选课(Enroll)联系集(联系属性为score) ，以及联系实体集选课(Enroll)与教师之间的多对一的录入成绩(Record)联系集(联系属性为recordDate)共同转化而成的关系模式为：
  Enroll (studentNo, courseNo, cClassNo, score, teacherNo, recordDate)
  
  
  
  
• 注意：
  • 标识联系集排课(Arrange)、排时间(ScheduleTime)不必生成关系模式；
  • 一对多(或多对一)联系集设置(Set)、归属(Have)、聘用(Engage)、包含(Own)、排教室(ScheduleClassroom)、指导(Supervise)、录入成绩(Record)和先修要求(Require)都不需要单独生成关系模式。

原文地址：https://blog.csdn.net/rc4gyyc/article/details/138044475

免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！