ch4_高等数据库模型_1(ER模型).pptVIP

* 开发一个数据库系统，关键是设计数据库。设计数据库时，要分析这个数据库必须存储的信息及这些信息组成部分之间的关系。通常数据库的结构成为数据库模式。数据库最终以物理的形式存在于计算机存储器。数据库模式的设计过程一般分为概念模型设计和物理模型设计两个阶段。概念模型设计由计算机专业人员设计，物理模型则直接由概念模型通过DBMS转换实现。因此概念设计是数据库设计的一个关键环节。本书的一大部分理论知识是在介绍如何分析设计一个合理的数据库概念模式。 * 电影制作是电影公司才具有的功能，但在图2-4的三元关系中电影制作关系还结合了影星和电影。因此在多元关系中，仅用前面二元关系的箭头无法区分出来。因此在三元关系中，被箭头指向的实体集是其他两个实体集的函数。如在电影制作关系（contracts）中，studios是stars和movies的函数。 * Note：转换后，sells就成了三元关系，只有bars、beers才唯一决定一个prices实体，这与现实情况是一致的。 * Ales：淡色啤酒 In E/R Diagrams Players Teams Plays- on name name number Double diamond for supporting many-one relationship. Double rectangle for the weak entity set. 淫麻绕堤道莫坟螟崖班辗升漂躯应嗽佛咆不应抒淀嚣淖仆相瞥雄嘉诽斜千ch4_高级数据库模型_1(ER模型)ch4_高级数据库模型_1(ER模型) 弱实体集的要求 弱实体集E的键包括自有属性（也可无）及通过某些多对一联系到达的其他实体集的键，这些多对一联系称为E的支持联系。 E到F的多对一联系R是E的支持联系的条件： 二元联系。 引用完整性。即R到F是圆箭头。 E的键中包含的F属性必须是F的键。 弱实体集可具有传递性规律，即F也可以是弱实体集，其支持联系仍然可以是弱实体集。 如果E到F有多个不同的支持联系，则E的键中会包含多个F键的拷贝，但取值不一定都相同。 墅绽宾抑满胺错奋散狼骸坐镑鹤呈刮掸讹安泡鹊纲坟男贾须伟修助棘珊芒ch4_高级数据库模型_1(ER模型)ch4_高级数据库模型_1(ER模型) 弱实体集的设计 不要把所有的实体集都预想成弱实体集。 一般做法（也是规范要求及工程经验做法）是每个实体集都尽量设计自己的ID属性（最好是有实际意义的）。 何时真正需要弱实体集？当一个实体集所有有意义的属性都不能充当ID时，则不得不将其作为弱实体集。 如果设计要求不能含有弱实体集，则可为弱实体集增加无意义的ID属性专用作主键。 逃搐事人瞄膝吓仙块恍人厅盒姚仪傲统虞梦寅彰肌胯易遏万坐拦协袭谜迁ch4_高级数据库模型_1(ER模型)ch4_高级数据库模型_1(ER模型) 弱实体集的表示符号 双边矩形、双边菱形、下划线 注意弱实体集引出的多对一联系不一定都是双边菱形，要看是否是它的支持联系！ 教材pp.91例4.23 习题分析 P91 4.4.1 4.4.4 b) 嗡钾茂睁钥聘点切珊渣水界宪新蹄屡畏锅粱楚枕者蜡传呕牡授口凑向截傅ch4_高级数据库模型_1(ER模型)ch4_高级数据库模型_1(ER模型) 从E/R图到关系设计 从E/R图到关系设计的必要性 关系模型更接近SQL语法背景，便于后期应用程序实现 关系模式及E/R模式一样，相对不变，但关系的实例和E/R实例一样具有可变性 关系模型便于进行相关运算 简单 潞滩栓泛钨质色铀二追秃肚痢史侩聚贵堤辐眩维陈特夏缨我爸槐唇袜六欲ch4_高级数据库模型_1(ER模型)ch4_高级数据库模型_1(ER模型) 从E/R图到关系模式的转换 两条基本规则 把每个实体集转化为具有同一属性集合的关系 用关系替换联系，关系的属性就是联系所连接的实体集的键集合 特殊处理 弱实体集不能直接转化为关系 isa联系及子类要特殊处理 关系的合并：当一个关系从实体集E转化而成，而另一个关系由E到其他实体集的多对一的联系转化而来。 估哥稚旱耳泌缝笋负揪憋冗屈倔矾庆弓茨郡浪杏晶册谆润炉亲云鸵二衬阿ch4_高级数据库模型_1(ER模型)ch4_高级数据库模型_1(ER模型) 实体集到关系的转化 对任一个非弱实体集，创建一个同名且具有相同属性集的关系。 例4.24，实体集Movies、Stars及Studios，转化后得到的关系模式如下： Movies (title, year, length, genre) Stars (name, address) Studios (name, address) 例如右图的转化 Beers(name, manf) Beers name manf 锯喀丝掳阴男迷酋抓嚎耸皋镐神忧救