数据库及数据仓库精要Ad-hoc报表系统解析.ppt

E-R图向关系模式的转换及主题数据库 通过实体—联系方法可以方便得得到现实世界的一个抽象模型，但这一模型并不能为数据库管理系统接受。要完成从现实世界到信息世界的转化，还必须将实体—联系方法所得的E-R图转化为关系表定义。 注意：一定要区分语义,包括名词性和动词性。先是动词性，代表联系集，其次是名词性，代表联系集的动词性所依赖、影响和作用的实体集 分析并确定主题：主题数据库是面向业务，面向事务，面向事实和事件的主题的数据组织存储，例如，企业中需要建立的典型的主题数据库有：产品、客户、零部件、供应商、订货、员工、文件资料、工程规范等。其中产品、客户、零部件等数据库的结构，是对有关单证、报表的数据项进行分析整理而设计的，不是按单证、报表的原样建立的。这些主题数据库与企业管理中要解决的主要问题相关联，而不是与通常的计算机应用项目相关联。 一个主题数据库的科学的数据结构：是由多个达到“基本表” Base Table 规范的数据实体构成的，这些基本表具有如下的特性： 1）原子性——基本表中的数据项是数据元素（即最小的、不能再分解的信息单元）； 2）演绎性——可由基本表中的数据生成全部输出数据（即这些基本表是精练的，经过计算或操作（自动化）处理可以产生全部企业管理所需要的数据）； 3）规范性——基本表中数据满足三范式 3NF 要求，这是依据科学的、能满足演绎性推算要求、并能保证快捷存取的数据结构。 实体的转换 将一个普通实体（非弱实体）转换为表定义是相当直观的，实体的每个属性对应表中的一个字段，实体的主键对应表的主键。 如Book实体转化到表的结果为： Book isbn#, title, price, press, stock 联系的转换 一个多对多联系在转换后也对应一个新的交叉实体表，表中的属性包括 参与联系各实体的主键 联系的描述属性 参与联系各实体的主键之和构成新的交叉实体表的超键。 如多对多联系Written_by转化为表之后其主键将由参与该联系的两个实体Book和Author的主键构成，如下： Written_by isbn#, author#, serial 联系的转换 一对一和一对多联系 A与B之间是一对多联系，不转换为一张单独的表，而只在B转换后的表中增加A的主键属性（当然这些属性将形成一个引用到A的主键的一个外键），以此表示某B实体所从属的A实体。 这种方法可以产生更少的表，有利于提高数据库性能，还可以表达更多的约束 如对于联系Possess，将在Order表中增加一列customer#表示订单从属的顾客 弱实体的转换 由于弱实体总是全参与它与它的标识实体之间的多对一联系，因此可以采用上面提出的一对多联系方法进行转换。 弱实体转换后生成的表的主键由标识实体的主键与弱实体本身的部分键组合而成。 如弱实体Item转换后，构成如下： Item（order# ,item# , isbn ,qty 实体层次的转换 将实体层次转换为表定义时可采用两种方法 父辈实体与子辈实体都转换为单独的表通用方法，任何情况适用。 每一个子辈实体转换为单独的表，其中既包含各子辈实体的特殊属性，也包含子辈与父辈实体的公有属性。只适用全参与泛化，因无法比哦啊是不从属于任何子辈实体的父辈实体 如Customer与VIP、NONVIP之间的全参与泛化可用第二种方法转换为： VIP customer#,name,gender,birthday,city,address,email,credit NONVIP customer# ,name,gender,birthday,city,address,email,discount 一些实际的考虑 一般来说，在将E-R图转换到关系表定义的过程中，需要考虑两个实际的问题：性能与数据规范化。 提高数据库性能的一个重要方法是进行数据冗余，不要跨表进行处理。 用一个表记录所有父子实体，而用一个字段来表示实体的类型。 请大家依据关系模式规范化理论讨论如下实体是否要拆分成不同的实体集和联系集，还是不拆分： 例如：Customer customer# ,name,gender,birthday,city,address,email,credit,discount,customer-type 在线书店数据库及关系模式 Book isbn#,title,price,press,stock Author author# ,name,city Written_by isbn,author# ,serial Category category# ,super# ,tag Customer customer# ,name,gender,birthday,city,addres