Devolope Data Models for Biz__ Database.ppt

变换之前read实体的主码为{MeterNo,EmpNo}组成的组合码 变化之后，read实体添加了自己的主码ReadNo，而 MeterNo和EmpNo成了read实体的外码 这种转化使实体间的强联系（标识联系）弱化（成为非标识的了）从而使实体间参照的实现变得容易 尤其多用于N:M的二元联系及三元联系 对局部ER图的优化六 添加历史信息（以方案一为例） 往往出于战略考虑 应用于属性时，类似于把属性变换为实体，例如要 保存员工职位的历史信息 对局部ER图的优化七 考虑泛化（继承）层次（以方案一为例） 考虑用水用户有两类，住家用户和商业用户，因此可以考虑泛化 如果在继承结构中，存在多个属性不是适用于所有实体的，并且实体分类很有效，则应该考虑泛化 本题中，TaxPayerID（纳税机关编号）和EnterpriseZone（公司所在区域）显然不适合住家客户，反之，subsidized(个人补助)和DwellingType（住家房屋类型）也不适用于商业客户 泛化的另一个好处是避免了NULL，采用泛化后，商业住户和住家住户实体中都没有NULL值（数据库中，空值是一种很难处理的值） 生成全局ER并优化 将以上经过局部优化的ER合并起来，形成全局ER（ER的集成） 方案如下（为节约显示空间，省略了某些属性）： 局部优化的总结Summary of Transformations/Optimizations Attribute to entity type Compound attribute split Multi-Value attribute transform Entity type expansion Weak entity to strong entity Add history: attributes, 1-M relationships, and M-N relationships Generalization hierarchy addition 注意对局部的ER进行合并，形成全局ER以后，通常需要进行以下工作： 消除各局部ER之间的冲突 属性冲突 结构冲突 命名冲突 全局ER的优化 原则：实体尽可能少、属性尽可能少、无冗余联系 步骤一：合并实体（如可考虑将1：1联系的实体合并） 步骤二：冗余属性的消除（去掉出现在不同实体中的统一属性） 冗余联系的消除（用范式进行规范化处理） 关于本题的全局优化问题，只以“消除联系的冗余”为例 ER图如果形成环，则表示可能存在冗余的联系 例如： Customer和Bill之间的联系receive，可以由”calculated by”，”has”，”uses”推出 所以删除冗余联系“receive” 概念模型到关系表的转化 How to convert? Entity 1:M relationship N:M relationship Identifying relationship Optional 1-M relationship Generalization Hierarchy 1-1 Relationships 基本转化规则basic conversion rules 规则一、Each entity type becomes a table(实体转化为表，实体的主码成为表的主码，不包括弱实体，属性转化成列) 规则二、Each 1-M relationship becomes a foreign key in the table corresponding to the child entity（一对多联系转化为子表中参照父表的外键，如果父表对子表来说是强制mandatory的，则外键不能为NULL） 规则三、 Each M-N relationship becomes an associative table with a combined primary key.(多对多联系转化成为一张独立的表，其主码由联系两端的实体的主码共同组成) 规则四、 Each identifying relationship adds a column to a primary key.（标识依赖在转化时，将父表的主码添加到弱实体中，弱实体的主码包括：1 弱实体自己的主码 2标识实体【也就是父表】的主码） 规则五、Optional 1-M Rule （可选的一对多联系，所谓“可选”，指“1”端，也就是父表端不强制，最小基数可为0的情况） 如： 下图表示是一个可选的一对多联系，学生可以住宿舍，也可以不住宿舍（比如有回家住的学生）， 这里，dorm对student来说是可选的，因此dormNo作为Student表的外码，可以为空（Null） 为了避免这种空值，我们将live联系转化