数据库及数据仓库精要.pptVIP

E-R图向关系模式表的转换 通过实体—联系方法可以方便得得到现实世界的一个抽象模型，但这一模型并不能为数据库管理系统接受。要完成从现实世界到信息世界的转化，还必须将实体—联系方法所得的E-R图转化为关系表定义。 第二十八页，共四十九页。 实体的转换 将一个普通实体（非弱实体）转换为表定义是相当直观的，实体的每个属性对应表中的一个字段，实体的主键对应表的主键。 如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) 第三十三页，共四十九页。 一些实际的考虑 一般来说，在将ER图转换到表定义的过程中，需要考虑两个实际的问题：性能与数据规范化。 提高数据库性能的一个重要方法是进行数据冗余。 用一个表记录所有父子实体，而用一个字段来表示实体的类型。 例如：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,address,email,credit,discount,customer_type) Interest_in(customer# ,category# ,date) Wish_for(customer# ,isbn# ,date,status) Order(order# ,customer# ,date,status,payment,name,address) Item(item# ,order# ,isbn,qty) 第三十五页，共四十九页。 数据库及数据仓库精要 第一页，共四十九页。 前言 数据库扮演的角色 也叫联机事务处理OLAP(Online Transactional Processing)，数据库保存由日常管理过程中涉及的业务操作创建的操作型结构化数据，数据记录系统管理行为（通过各种业务逻辑来交互）。反映细粒度的事务数据，保存时间短。主要依赖关系模式建模方法论。 数据仓库扮演的角色 也叫联机分析处理OLAP(Online Analytical Processing)，数据由联机事务处理来，经过选择和聚集，变为统计分析事实产生的因果，辅助决策制