第02节：E-R模型.pptVIP

§2.8设计数据库的E-R模式 数据库的设计过程 数据库系统的设计可以分为三个阶段： 概念设计 主要任务：概念模型与概念模式 技术手段：利用E-R模型 主要成果：数据库的E-R模式，即E-R图 逻辑设计 物理设计 在概念设计阶段，设计者主要关注的是如何描述数据及其相互关系，即用户数据需求的简单、明了的表达。 §2.8设计数据库的E-R模式 E-R模式设计的主要任务 定义所有的实体集、联系集、属性和映射约束等等，最终用E-R图来描述； 利用扩展E-R特性不断精简所设计的数据库模式，去除冗余，并确保满足所有的数据需求且不冲突； 针对需求规格说明书(包括数据需求、功能需求和性能需求)，检查概念模式： 它是不是包含了所有的数据？ 它能不能满足对数据的各种操作，如查询和增删改等，即满足功能需求？ 性能需求呢？…… §2.8设计数据库的E-R模式 E-R模式设计中的问题 用属性表示某个对象更恰当还是用实体集表示？ 用实体集表示某个对象好还是用联系集好？ 使用二元联系集还是多元联系集？ 用强实体集还是弱实体集？ 数据库中强实体集和依附于它的弱实体集可被视为单一的“对象”，因为弱实体存在依赖于强实体。 使用概括合适，还是使用特殊化合适？ 概括强调不同实体集的实体间的共性； 而特殊化强调同一实体集内不同实体间的差异。 使用聚集是否合适？ 聚集将E-R图的某个部分集成为单一实体集，使得可以将聚集实体看作是一个单元，而不必关心其内部结构。 §2.9将E-R图转换为表 为什么要把E-R图转换为表呢？ 将数据库的表示从E-R图转换为表的形式是由E-R图产生关系数据库设计的基础。 §2.9将E-R图转换为表 关系和表一样吗？ 关系数据库是关系的集合，而关系是一系列域上的笛卡儿积的子集，是数学上的概念； 而表是什么东西呢？ 广义表：可以看成是由一行一行的内容组成的一个格式； 狭义表：即关系数据库中的表，与关系的概念类似。 §2.9将E-R图转换为表 E-R图对应的表 E-R图中的每个实体集和联系集都有唯一的关系表与之对应： 关系表的表名即为相应的实体集或联系集的名称； 每个表有多个列，每列有唯一的列名； 每个列都与相关实体集或联系集的属性有关。 总之，数据库的E-R模式可以转化为一些表的集合。 §2.9将E-R图转换为表 用表表示强实体集 设E是具有描述性属性a1,a2,…,an的一个强实体集： 用具有n个不同列的表E来表示这个实体集，每列同实体集E的一个属性对应； 表中各行对应于实体集中的各个实体。 例如，实体集student 对应表student §2.9将E-R图转换为表 用表表示弱实体集 设A是具有属性a1,a2,…,am的弱实体集，而B是A所依赖的强实体集，且其主码包括属性b1,…,bn。用表A表示弱实体集A，表中各列对应于以下属性集合中的各个属性：{a1,a2,…,am}∪{b1,b2,…,bn}； 例如，弱实体集dependent对应表dependent： §2.9将E-R图转换为表 用表表示联系集 设R是联系集，而所有参与R的实体集的主码属性集合为{a1,a2,…,am}；如果R有描述性属性，则设为b1,b2,…,bn。用表R表示该联系集，表中各列对应以下属性集中的各个属性：{a1,a2,…,am}∪{b1,b2,…,bn} 例如，涉及两个实体集 student和course的 联系集selecting 对应表selecting： 假设联系集selecting 具有属性course_score 表的冗余 将弱实体集和相应强实体集相关联的标识性联系集比较特殊，如图： 联系集teacher_dependent对应表teacher_dependent(teacher_number, dependent_name)； 弱实体集dependent对应表dependent(teacher_number, dependent_name, dependent_sex, dependent_age)； 两个表的元组关系与全部参与。 §2.9将E-R图转换为表 表的合并 如图所示，按照前面的规则将产生三个表： student(student_number,student_name) student_department(student_number,department_name) department(department_name, deparment_location, department_leader) §2.9将E-R图转换为表 表的合并 由于一个学生不可能不与学校的任何系相联系而存在(全部参与)，因此可将前两个表： student(student_number,student_name) student_departme