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

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

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 数据库概念设计实例——大学选课系统

概念设计任务

• 概念设计(E-R模型)：根据需求分析规格说明书完成如下任务:
  • 定义实体集及属性，实体集的主码，并用数据字典描述实体集；
  • 定义联系集及属性，联系集的主码，联系的映射基数及参与约束,联系中实体的角色，并用E-R图描述被建模的联系集；
  • 分析初步E-R图中是否存在依赖约束、多值联系，并将其建模为依赖实体集或弱实体集；
  • 利用扩展E-R特征对对象进行分类及聚合(建模为联系实体集) ；
  • 将多元联系转化为二元联系进行建模(联系实体集、依赖实体集或弱实体集)；
  • 去除冗余数据，并保证满足所有数据需求不冲突；
  • 对照需求分析规格说明书，检查E-R模型，看其是否包含了所有数据、能否满足所有功能需求等。

“大学选课管理系统”需求分析

• 需求分析是数据库概念设计的基础。本节给出一个简化的大学选课系统的需求分析，重点是功能需求分析、数据需求分析和业务规则及完整性约束分析
• 系统需求分析
  • 需求概述和系统边界
  • 功能需求分析
  • 数据需求分析
  • 业务规则及完整性约束分析

需求概述和系统边界

• 随着学分制的普及，大学选课管理系统已成为大学信息管理系统中的重要组成部分。
• 大学选课管理系统面向全体师生，对学院、班级、教师、学生、课程等基本信息以及排课(每门课程开几个教学班？谁来任教？上课时间与教室安排等)、选修及成绩等进行统一管理，实现排课、选课及成绩管理的科学化、系统化和自动化，最大限度地为老师和学生提供方便和提高管理效率。
• 本系统不考虑课程退选、改选和考试安排等功能。

功能需求分析

• 学院基本信息管理：学院基本信息录入、维护与查询
• 班级基本信息管理：班级基本信息录入、维护与查询
• 学生基本信息管理：学生基本信息录入、维护与查询
• 教师基本信息管理：教师基本信息录入、维护与查询
• 课程基本信息管理：课程基本信息录入、维护与查询
• 教室基本信息管理：教室基本信息录入、维护与查询
• 排课管理：根据开课计划实现自动或半自动的排课
• 学生选课：提供选课、退选和改选功能
• 课表查询：提供不同人员以不同方式查询选课信息
• 成绩管理：学生考试成绩录入、修改及查询
• 大学学分制管理系统的功能需求？

数据需求分析

• 数据库的数据需求可以根据与用户的交流和设计者自己对企业或组织的业务分析得到，作为概念设计中确定实体集、联系集的基础。具体包括：
• 日常业务中涉及的各实体对象需要采集哪些数据？
• 各日常业务发生时需要采集哪些数据？
• 在对一个业务功能的数据需求(通常对应于业务表格或单据)进行描述时，可能会包含多个基本对象的属性，这是发现实体集之间联系的重要途径之一，也是定义用户界面和报表的依据。
• 学院需要记录学院编号、学院名称、学院地址等信息，由学院编号唯一标识
• 教师要求记录教师编号、教师姓名、职称、学位等信息，由教师编号唯一标识
  • 一个学院可聘用多名教师，但一名教师只能属于一个学院
• 班级需要记录班级编号、班级名称、年级、班级人数、所属学院等信息，由班级编号唯一标识
  • 一个学院有多个班级，一个班级只能归属于某一个学院
  • 班级人数为派生属性，它的值可通过统计学生实体集中属于该班学生的人数而得到
• 学生需要存储学号、姓名、性别、出生日期、家庭住址、电话号码、所属班级等信息，由学号唯一标识
  • 家庭住址由省份、城市、街道组成——复合属性；
  • 电话号码可能有多个，如宿舍电话、实验室电话、移动电话等——多值属性；
  • 年龄可由生日推算出来——派生属性，不作为存储属性
  • 学生可进一步分本科生和研究生两类，本科生需记录个人兴趣，研究生需记录研究方向、指导老师
  • 一个班级有多名学生，但一个学生只能属于某一个班级
  • 一个教师可以指导多名研究生，但一个研究生只能安排一名指导教师
• 课程需要记录课程号、课程名称、课时、学分、先修课、所属学院等信息，由课程号唯一标识（为实现分类管理，可增加课程类别属性）
  • 课程之间需设置先修要求，一门主课程至多可以指定一门先修课程，但一门先修课程可对应于多门主课程
  • 一个学院可管理多门课程，但一门课程只能归属一个学院
• 每门课程可以安排多个开课班，开课班需存储课程号、开课班号、年份、学期、上课时间、上课地点、教室容量、选课人数、任课老师等信息，开课班号为部分码
  • 一个开课班可安排多名教师任教，需明确教师任教开课班的任教角色；一名教师也可同时任教多个开课班
  • 一个开课班被多名学生选修，每个学生可选修多个开课班
  • 但是，一个学生同一学期不能选修同一门课程的同一个开课班多次(非多值联系)；也不能选修同一门课程的多个不同开课班（请大家思考这是为什么？）
• 如何理解开课班与学生之间多对多联系的语义(约束)？
• 教室需要记录教室编号、所在教学楼、电话号码、教室类型、教室容量等信息，由教室编号唯一标识
  • 一个教室可安排多个开课班，一个开课班可安排多个时间和教室上课，且每次上课可能安排在相同或不同的教室
  • 一个教室在同一时间段不允许安排多个开课班上课
    （同一任课教师的同一门课程的多个开课班除外：合班）
• 一个学生在同一时间段不允许选修多个开课班 （重修课程是否除外？）
• 同一名教师不允许在同一时间段安排多个不同课程的开课班或非合班上课的相同课程的开课班
• 教师在所任教的开课班考试结束后，需在规定的时间内将所任教学生的成绩录入系统，并要求记录登分日期
• 如何理解教室与开课班之间多对多联系的语义？
  联系属性为上课时间，且是多值联系！

业务规则及完整性约束分析

• 在数据需求分析的同时，还要进行相应的完整性约束分析，主要包括：
  • 码约束，指出实体集的码属性；
  • 关联约束，即映射基数约束、参与约束和依赖约束等；
  • 用户自定义完整性约束，如属性取值约束、业务关系约束等。
• 完整性约束主要来源于业务规则。
• 与业务相关的操作规范、管理章程、规章制度、行业标准、会计准则和计算方法等都可以称为业务规则。
• 业务规则实质上可以理解为一组条件和在此条件下的操作，它是一组准确凝练的语句，用于描述、约束及控制企业的结构、运作和战略，是应用程序中的一段业务逻辑。
• 某大学选课系统的业务规则及完整性约束分析如下：
  • 实体集的码约束、实体集与实体集之间的映射基数约束等都已经在数据需求分析阶段进行了描述，这里不再重复
  • 班级中的班级人数为派生属性，可通过统计学生实体集中属于该班学生的人数得到；一个班级最多安排60名学生；课程中学分的值不能超过6；成绩只能在0～100分之间
  • 一个开课班可安排多个上课时间、上课地点授课，且每次授课可能安排在相同的或不同的上课地点
  • 开课班中的教室容量为派生属性，取自该开课班所安排授课教室的教室容量(若一个开课班安排了多个授课教室，则取多个教室中最小的教室容量)；选课人数也是派生属性，可统计选修该开课班的学生人数得到。开课班中的派生属性教室容量、选课人数是为了方便实现“一个开课班的选课人数不能超过该开课班所安排教室的教室容量”约束
  • 对于设置了先修关系的课程，只有在已经选修过某门课程的先修课程之后才允许选修该课程
  • 一个学生不允许同一学期选修同一门课程开设的多个教学班(即同一学期只允许选修同一门课程开设的一个教学班)，且一个学生同一学期选修的所有开课班不允许时间冲突
  • 一个学生同一学期所选修课程的总学分不能超过32
  • 一名教师同一学期所任教的多个开课班不允许时间冲突；一个教室同一学期所安排的多个教学班在时间上不能冲突
  • 对选课人数少于15人的开课班需取消或进行开课班合并调整
  • 当一门课程分多个学期开设时，如大学英语I、大学英语II，则当作不同课程看待，即具有不同的课程号，但序列课程之间需设置先修关系
  • 各种编号的编码规则（如学号的编码规则，不具体详述）

“大学选课管理系统”概念设计

• 数据库概念设计的主要步骤是：
  • 理解需求分析；
  • 发现基本实体集，并通过分析它们之间的核心业务，发现核心联系集；
  • 进一步完善并增加必要的实体集和联系集；
  • 定义完整的E-R图和数据字典

确定基本实体集及属性

• 根据前面的数据需求和业务规则分析结果，可定义学院、班级、学生(含本科生和研究生两个子集)、教师、课程、教室等基本实体集，其属性定义的数据字典详见教材（P138-140页）

主要业务局部概念建模

• 基本实体集有：学院、班级、学生、教师、课程、教室
  
• 观察
  • 学生选修某学期的某门课程，只能从该学期该课程实际开设的若干个开课班中进行选修；
  • 教师安排教学任务，也是针对需开设的开课班进行分配；
  • 学生通过选修某个开课班来明确是哪位(些)教师给其授课；
  • 一个学生可能会出现多次选修同一门课程的情况(如重修)。即学生与课程之间的选课联系是多值联系。
  • 教师与课程、学生之间的任教、授课联系也是多值联系。
• 学生、课程、教师之间的建模
  • 引入开课班弱实体集，它依赖于课程实体集。
  • 学生选修课程是指选择为其所开设的某个开课班。
  • 某个开课班需要安排任课教师。因此，学生与教师之间的授课联系就转化为通过开课班与教师之间的任教联系来间接关联。
    
    上课时间、上课地点的建模
    
  • 假设一个开课班可能安排多个时间上课，且不同时间可能安排在相同的或不同的教室上课，则排时间教室联系集可能是多值联系。
    
    学生实体集的类层次及研究生指导的建模
    
    “录入成绩”联系集的聚合建模
    

定义完整的实体集及属性

• 学院：学院编号、学院名称、学院地址
• 班级：班级编号、班级名称、年级、班级人数。
  • 班级人数为派生属性
• 教师：教师编号、教师姓名、职称、学位
• 学生：学号、姓名、性别、出生日期、家庭住址、电话号码
  • 复合属性：家庭住址——省份、城市、街道
  • 多值属性：电话号码
• 本科生、研究生，它们具有学生的所有属性，此外
  • 本科生：个人兴趣
  • 研究生：研究方向
• 教室：教室编号、所在教学楼、电话号码、教室类型、教室容量
• 课程：课程编号、课程名称、学分、课时数
• 开课班：开课班号、年份、学期、教室容量、选课人数
  • 开课班号为部分码，能够区分同一门课程在不同学期及同一学期所开设的不同开课班
  • 教室容量、选课人数是派生属性
• 时间安排：上课时间
  • 上课时间为部分码，能够区分同一个开课班的不同上课时间
• 设置联系集：实体集学院与班级之间的一对多联系集
  • 表明一个学院可设置多个班级，但一个班级只属于一个学院
• 归属联系集：实体集课程与学院之间的多对一联系集
  • 表明一门课程只归属于一个学院，但一个学院可管理多门课程
• 聘用联系集：实体集学院与教师之间的一对多联系集
  • 表明一个学院可聘用多名教师，但一名教师只能受聘于一个学院
  • 联系属性为聘用日期
• 包含联系集：实体集班级与学生之间的一对多联系集
  • 表明一个班级可包含多名学生，但一名学生只属于一个班级
• 排课标识联系集：课程与开课班弱实体集之间的一对多联系集
  • 表明一门课程可安排多个开课班，开课班号为部分码
• 选课联系集：学生与开课班之间的多对多联系集
  • 表明一个学生可选修多个开课班，且一个开课班可包括多名学生
  • 联系属性为成绩
• 任教联系集：教师与开课班之间的多对多联系集
  • 表明一教师可任教多个开课班，且一开课班可安排多名教师任教
  • 联系属性为任教角色
• 排时间标识联系集：开课班与时间安排弱实体集之间的一对多联系集
  • 表明一个开课班可安排多个上课时间，上课时间为部分码
• 排教室联系集：弱实体集时间安排与教室之间的多对一联系集
  • 表明多个上课时间可安排在同一个教室上课，但一个教室在一个上课时间只能安排一个开课班上课
• 指导联系集：实体集教师与研究生之间的一对多联系集
  • 表明一教师可指导多名研究生，但一名研究生只能安排一名指导教师
• 先修要求联系集：由具有先修课程角色和具有主课程角色的课程实体之间的一对多联系集
  • 表明一门主课程至多指定一门先修课程，但一门先修课程可对应于多门主课程
• 录入成绩联系集：实体集教师与联系集选课之间的一对多联系集
  • 联系属性为录入日期
    
    
    
    

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)都不需要单独生成关系模式。