Devolope Data Models for Biz__ Database.ppt

单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,*,为商业应用开发数据模型（一）,按照以下步骤，对商业应用进行,ER,设计,ER,的初始化（局部,ER,设计）,局部,ER,的优化,生成全局,ER,并优化,Case study-,市政用水的客户数据库,客户数据，包括编号，姓名，缴款通知单地址，类型（商用或住家），申请等级，水表数等,水表数据，包括水表编号，地址，规格和型号。一只水表和一个客户联系,工作人员在规定时间内抄写水表读数，每抄写一次，记录薄就记录一次水表编号，职工号，水表计数，水表读数的日期和时间以及用水量，水表第一次使用时，初始值为,0,Case study-,市政用水的客户数据库,费率，包括编码，说明，固定费率，限量，可变费率。消费低于限量的按固定费率计算，消费高于限量的按可变费率计算。限量和可变费率是根据客户类型和地址的不同给出的。费率分配给客户，多个客户可以被分配相同的费率。费率方案提出后，经政府批准生效后再分配给客户,水费缴款通知单，通知单由表头和明细行（多行）构成，表头由客户编号，准备日期和用水时间段构成，明细行由水表编号，消费量和金额构成。消费量是最近两次读数之差，消费金额是消费量和客户费率的乘积,ER,图的初始化（局部,ER,设计）,ER,图的初始化由以下步骤组成：,标识实体,标识主码,添加联系,Case study-,市政用水的客户数据库,客户数据，包括编号，姓名，缴款通知单地址，类型（商用或住家），申请等级，水表数等,水表数据，包括水表编号，地址，规格和型号。一只水表和一个客户联系,客户可以拥有多个水表（,1,：,M,）,参与性约束（,optional/mandatory,）需要根据实际业务确认,工作人员周期性地读取水表读数，每抄写一次，记录薄就记录一次水表编号，职工号，水表计数，水表读数的日期和时间以及用水量，水表第一次使用时，初始值为,0,工作人员读取水表产生水表读数，这个“读取”建模为联系还是实体？,没有提及工作人员其它信息，是否建模成实体？,水表：读数（,1,：,M,）,方案一：,不考虑员工,将水表读数建模为实体,方案二：,考虑员工,将水表读数建模为联系（弱实体）,Case study-,市政用水的客户数据库,费率，包括编码，说明，固定费率，限量，可变费率。消费低于限量的按固定费率计算，消费高于限量的按可变费率计算。限量和可变费率是根据客户类型和地址的不同给出的。,费率分配给客户，多个客户可以被分配相同的费率。费率方案提出后，经政府批准生效后再分配给客户,费率：客户,=1,：,M,参与性约束（,optional/mandatory,）需要根据实际业务确认,Case study-,市政用水的客户数据库,水费缴款通知单，通知单由表头和明细行构成，表头由客户编号，缴款截止日期和用水时间段构成，明细行（可能有多行）由水表编号，消费量和金额构成。消费量是最近两次水表读数之差，消费金额是消费量和客户的费率的乘积,消费量和消费金额由计算得来，是间接数据，暗示通知单和水表读数、通知单和费率有联系（回忆：导出属性的概念）,量,市政用水,CDM,方案一,(,未局部优化,),市政用水,CDM,方案二,(,未局部优化,),对局部,ER,图的优化,对局部,ER,图的优化一,将属性变换为实体（以方案一为例）,考虑,Reading,实体中的,EmpNo,，关于员工，只有这个员工编号信息,如果需要保存和访问员工的更多信息，则考虑将员工编号属性扩展为员工实体,于是有如下变换：,对局部,ER,图的优化二,分解复合属性（以方案一为例）,客户的住址是一个复合属性，可以考虑将其分解为由街道，城市，省，邮编组成,优点？,分解后可以直接支持按街道、城市、省份、邮编查询,对局部,ER,图的优化三,处理多值属性（以方案一为例）,假设水表实体中“水表规格”这一属性分为“外尺寸规格”和“接口口径规格”两个值，则这是一个多值属性,另（在员工的“联系方式”属性中也有同样的问题，因为联系方式有固定电话，手机等）,处理多值属性的两种方法如下：,方法一：将多值属性罗列在原实体中,方法二：创建一个新的实体并通过一个,1:M,的联系与原实体关联，这个联系实际上,是一个标识联系，新实体是依赖于原实体的弱实体,这样做的好处是可以在,meterSpec,中随意添加新的水表的,某个规格，而不改变两个实体中任何一个的结构,对,ER,图的优化四,实体扩展（将一个实体扩展为两个实体，以方案一为例）,以费率实体为例，考虑市政府在不同时期可能审批过多种费率方案，为了能够将这些费率的执行方案都保存下来，可以考虑采用更复杂的费率结构,将费率实体扩展为一个费率方案集合实体和一个费率方案具体信息实体，如下：,注意：一个实体扩展为两个实体时，不一定必然是一个标识实体，一个是弱实体,对局部,ER,图的优化五,弱实体到强实体的转换（以方案二为例）,把弱实体,(weak entity),转化为强实体,同时把标识联系转化为非标识联系,(non-identifying relationship),变换之前,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,联系转化成关系表,Optional,该表的主码是子表（,Student,实体）的主码,该表的外码是两端的实体的主码的组合,该表的外码不允许空,NULL,注意：规则五可以避免,NULL,，但是多生成了一个表，增加了查询的复杂性，许多应用中，避免额外的表比避免,NULL,更重要,规则六、转化泛化层次结构。,RDBMS,不直接支持泛化，各,CASE,工具的实现方法有别，后续课程再讨论,规则七、,1:1relationship,（转化一对一联系）,方法一：直接将,1,：,1,联系转化成两个外码（可能会产生,NULL,）,方法二：如果联系的某一端实体是可选的（,optional,），则可以在另一个实体中取消外码，以消除,NULL,举例：,方法一：,冗余联系,方法二：,在,Power Designer,中可通过设置,dominant,关系来实现,CREATE TABLE Office(PRIMARY KEY(OfficeNo),FOREIGN KEY(EmpNo)REFERENCES Employee,UNIQUE(EmpNo),本题转化为关系表的,LDM:,