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

,数据库及数据仓库精要,前言,数据库扮演的角色 也叫联机事务处理OLAP(Online Transactional Processing)，数据库保存由日常管理过程中涉及的业务操作创建的操作型结构化数据，数据记录系统管理行为（通过各种业务逻辑来交互）。反映细粒度的事务数据，保存时间短。主要依赖关系建模方法论。 数据仓库扮演的角色 也叫联机分析处理OLAP(Online Analytical Processing)，数据由联机事务处理来，经过选择和聚集，变为分析事实产生的因果，辅助决策制定（通过各种分析报表来交互）。反映大范围的事实数据，保存时间长。主要依赖多维建模方法论,问题的导入,结构良好的表，范式，SQL语言及关系 基本表与中间表、临时表不同，基本表及其字段之间的关系，应尽量满足第三范式，是结构良好的表，它可以消除删除行，改变行，修改行(实例)的错误和异常。它具有如下四个特性：(1) 原子性，基本表中的字段是不可再分解的。(2) 原始性，基本表中的记录是原始数据（基础数据）的记录。(3) 演绎性，由基本表与代码表中的数据，可以派生出所有的输出数据。(4) 稳定性，基本表的结构是相对稳定的，表中的记录是要长期保存的。(5)基本表的每个决定因子都必须是候选建。(6)菲基本表必须分解为两个或多个基本表。 三个基本范式：(1) 1NF是对属性的原子性约束，要求属性具有原子性，不可再分解。(2) 2NF是对记录的惟一性约束，要求记录有惟一标识，即实体的惟一性。(3) 3NF是对字段冗余性的约束，即任何字段不能由其他字段派生出来，它要求字段没有冗余 大多数结构不良好的表，会产生或包含大量的冗余数据，同时可能会出现删除行，改变行，修改行的错误和异常，这都是都是使用了SQL DML CURD语句产生的。像中间表、报表和临时表：(1) 中间表是存放统计数据的表，它是为数据仓库、输出报表或查询结果而设计的，有时它没有主键与外键(数据仓库除外)。(2) 临时表是程序员个人设计的，存放临时记录，为个人所用。(3) 基表和中间表由DBA维护，临时表由程序员自己用程序自动维护。 关系是一个由行和列组成的二维表，不一定结构良好，特征为：行包括实体的数据，列包含实体性质的数据，表中的单元格存储单个值，每列的所有实体类型一致，每列具有唯一名称，列的顺序任意，行的顺序任意，任意两行互不重复。这是最大的复合关系模式的条件，符合这个要求的表就是关系型表格。,统计，汇总，分析表自动用Excel做,目录,E-R模型的概念与表示 实体-联系方法(概念设计) E-R图向关系表的转换(逻辑设计),E-R模型的概念与表示,实体集-语义(名词类性) 实体（Entity） 事物就是在行动影响下物质本身的改变，或者进行。客观存在并可相互区别的事物称为实体。实体可以是具体的，也可以是抽象的概念或联系。 具有共性的一类实体可归类为一个实体集(Entity set)。 属性（Attribute） 实体所具有的某一特性称为属性。 一个实体可以由若干个属性来刻画。 域（Domain） 属性的取值范围或类型。 键或标识符（Key） 标识符是实体中一个或多个属性的集合，可用来唯一标识实体中的一个实例。每个实体都必须至少有一个标识符。如果实体只有一个标识符，则它为实体的主标识符。如果实体有多个标识符，则其中一个被指定为主标识符，其余的标识符就是次标识符了,E-R模型的概念与表示,联系集-语义(动词类型) 实体之间可以通过联系来相互关联。与实体和实体集对应，联系也可以分为联系和联系集，联系集是实体集之间的联系，联系是实体之间的联系，联系是具有方向性的。 联系具有方向性，每个方向上都有一个基数。 联系的两个方向上各自包含有一角色名，描述该方向联系的作用。 按照实体类型中实例之间的数量对应关系，通常可将联系分为4个基本联系分为类，即一对一（ONE TO ONE）联系、一对多（ONE TO MANY）联系、多对一（MANY TO ONE）联系和多对多联系（MANY TO MANY）。 三个特殊联系 每个实体类型都有自己的标识符，如果两个实体集之间发生联系，其中一个实体类型的标识符进入另一个实体类型并与该实体类型中的标识符共同组成其标识符时，这种联系则称为标定联系，也叫依赖联系。反之称为非标定联系，也叫非依赖联系。 递归联系是实体集内部实例之间的一种联系，通常形象地称为自反联系。同一实体类型中不同实体集之间的联系也称为递归联系。,E-R模型的概念与表示,E-R模型的概念与表示,E-R图的设计步骤 第一步：针对特定的应用，确定实体、属性和实体间的联系，画出局部E-R图。 第二步：综合各个局部E-R图，产生反映数据库整体概念的总体E-R图。,E-R模型的概念与表示,弱实体集 有些实体集的所有属性都不足以形成主码，这样的实体集称为弱实体集(Weak Entity Set)，依赖于其它实体集而存在。 与此相对，其属性可以形成主码的实体集称为强实体集。 弱实体集所依赖的实体集称为标识实体集（identifying entity set），相应的关系为标识联系（identifying relationship）。,E-R模型的概念与表示,弱实体集通常没有主键。 以订单的分项为例，订单项实体集可能有编号（局部的编号）、商品名称、数量、单价等属性，但是这些属性不足以识别一个定单项，因为完全有可能在另外一张订单中出现相同的内容。 必须把订单的关键字（如一个全局的订单编号）和定单项的局部编号结合起来才能标示一个定单项。 弱实体集的属性中，用来与标识实体集的键结合以识别一个弱实体集的属性称为部分键（partial key）。 弱实体集的主键=它的标识实体集的键+它的部分键,4.1 E-R模型的概念与表示,ER图使用双线矩形表示弱实体集，弱实体集与其标识实体集之间的联系用双线菱形表示，弱实体集的部分键使用虚下划线表示。,E-R模型的概念与表示,实体集的层次关系 现实世界中的很多概念之间都具体层次关系。 ER模型使用实体集间的继承和ISA关系来描述这种概念间的层次关系 实体集老师或学生都继承自实体集人，并且实体集老师或学生与实体集人之间都满足ISA关系，即老师或学生都是人的一种。 ISA关系可以从两个方向进行设计 从自上而下的方向，首先设计出人这一实体，然后根据属性的不同，将两种不同的人具体化（specification）为老师或者学生。 从自下而上的方向，首先设计出老师或学生，然后将他们的共性提取出来，泛化（generalization）为人。,E-R模型的概念与表示,层次关系的约束 从子实体集之间是否相交角度，不相交（disjoin）泛化要求继承自同一父辈的多个子实体集之没有交集，重叠（overlapping）泛化则允许有交集。 从泛化是否完全角度，全参与泛化要求所有父辈实体都必须同时也是某一子辈实体，部分泛化则允许不是任何子辈实体的父辈实体存在。 例如，在采用会员制的销售系统中，顾客被分为会员（VIP)与非会员(NONVIP)两种，会员拥有消费积分(credit)，非会员拥有固定的折扣率(discount)。一个顾客要么是会员、要么是非会员，二者必取其一，因此为全参与不相交。,E-R模型的概念与表示,E-R图例,实体-联系方法,实体还是属性 凡是满足以下两条准则的事物，一般均可作为属性对待。 作为属性，不能再具有需要描述的性质。属性必须是不可分的数据项，不能包含其他属性。 属性不能与其他实体具有联系，即E-R图中所表示的联系是实体之间的联系。 例如书籍是一个实体，书号、书名、作者、出版社、定价是书籍的属性，如果应用系统不再需要作者的其他信息，如电话、住址、个人主页等，那么根据原则1可以将作者作为书籍的属性对待。但是如果这些信息是必须的，那么作者作为一个实体看待更为恰当。,实体-联系方法,实体-联系方法,实体还是联系 一般来说，实体对应现实世界中实际存在的事物，是名词类型；联系对应的概念一般是一种动作，是动词类型。 例如： 书和作者都是现实世界中的名词，因此作为实体。 而written_by表示作者写书这一动作，因此作为联系。 映射基数往往影响到一个概念是作为实体还是联系的选择。 若一项贷款只能由一个分行发放，并且只能由一个客户借贷，则将Loan作为Customer与Branch之间的联系比较合适。 但如果允许多个客户共同借贷同一项贷款 ，在这种情况下，将Loan作为实体。,实体-联系方法,二元关系还是多元关系 数据库中使用得最多的是二元联系。 通常，将多元关系转换为二元关系。 如学校选课系统，涉及到学生、教室、教师、课程等多个实体，可表示为一个四元关系。,实体-联系方法,但也有一些情况下使用多元联系更好（如需要表达多个实体集间的约束时） 如学校选课系统中若一门课程可由多个教师教授，并且若课程和教师确定，则上课的地点也随之确定。,实体-联系方法,联系属性的放置 影响联系属性放置的主要因素是联系的映射基数。 对于一对一或一对多联系，选择作为联系属性或实体属性只是体现语义侧重点的不同 如销售系统需要记录顾客（Customer）与订单（Order）之间的关系（Possess）。由于一个订单只能由一个顾客所有，因此为顾客与订单之间为一对多关系。这时，记录生成订单日期的属性（date）既可以作为联系Possess的属性，也可作为订单的属性。,实体-联系方法,对于多对多联系，联系的属性不能作为实体的属性。 如，顾客与希望书籍之间的联系希望购买(Wish_for)。 Wish_for有一属性date，表示顾客发出购买意向的日期，这一属性不能作为参与联系的两个实体Customer或Book的属性。,实例在线书店数据库,类似于Amazon的在线书店系统所用的数据库 数据库中要求存储所有书籍的相关信息，并对书加以分类； 顾客的有关信息也要求存储在数据库中，并且允许用户选择自己感兴趣的书籍类别及希望购买的图书； 顾客在决定购买时可以发出订单，同一订单可以包含多种书，每种书可一次购买多本。顾客在订单中提供送货地址，系统根据订单发货。,实例在线书店数据库,合并分E-R图 各分E-R图之间的冲突主要有三类: 属性冲突 (1) 属性域冲突，即属性值的类型、取值范围或取值集合不同。 例如：属性“订单号”有的定义为字符型，有的为数值型。 (2) 属性取值单位冲突。 例如：属性“库存”有的以册为单位，有的以千册为单位。 命名冲突 (1) 同名异义。不同意义对象相同名称。 例如：Author和Customer均有属性name。 (2) 异名同义（一义多名）。同意义对象不相同名称。 例如：“项目”和“课题”。,实例在线书店数据库,结构冲突 (1) 同一对象在不同应用中具有不同的抽象。 例如： “作者”在某一局部应用中被当作实体，而在另一局部应用中则被当作属性。 (2) 同一实体在不同局部视图中所包含的属性不完全相同，或者属性的排列次序不完全相同。 (3) 实体之间的联系在不同局部视图中呈现不同的类型。 例如：实体E1与E2在局部应用A中是多对多联系，而在局部应用B中是一对多联系；又如在局部应用X中E1与E2发生联系，而在局部应用Y中E1、E2、E3三者之间有联系。 解决方法是根据应用的语义对实体联系的类型进行综合或调整。,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图转换到表定义的过程中，需要考虑两个实际的问题：性能与数据规范化。 提高数据库性能的