第9章-数据库设计-new分析.ppt

逻辑模型与物理模型 数据建模和系统开发生命周期 数据库的设计主要包含两个步骤： 首先是开发逻辑数据库模型，最常见的类型是关系数据库模型。 在逻辑数据库设计中，使用规范化方法建立数据模型，使得模型具有简单、无冗余性和最小维护成本等特性。 然后通过数据库物理设计定义用于存储数据的计算机文档和数据库的技术规范。 通常，逻辑与物理数据库设计可以和其他系统设计同步进行，如输入输出设计等。 在逻辑模型基础上进行物理数据库设计，包括每个属性的物理字段设计，数据量规划等。设计物理文件和数据库要利用此前SDLC阶段所收集并产生的信息。这些信息包括： 规范化关系，包括数据量的估计。 每一个属性的定义。 何时、何处利用数据的描述：输入、查询、删除和更新（包括频次）。 反应时间和数据完整性的预期或要求。 用于操作文件和数据库的技术描述，用于掌握策略需求和技术选择的范围。 在系统分析确定需求时需要收集每张表中有多少行和以上的信息。如果系统分析阶段没有收集到，在数据库设计过程中就需要去收集这些信息。 关系数据库模型 并不是所有的表都是关系。关系与非关系表的区别在与关系具有如下五个特征： 单元中的条目（entries）很简单。每一行和每一列的交点是一个只有单个值的条目。 一个列中的条目来自同一个集合的值。 每一行都是唯一确定的。其唯一性是由于关系中有一个非空的主码值。 列的顺序可以先后对换而不会改变在关系中的使用。 行能够以任意顺序对换或者存储。 关系结构良好。结构良好的关系具有以下特点：最小的冗余度和允许用户插入、修改和删除表中的行而不会出现错误或者不一致性。 员工1就是这样的一个关系。关系中每一行数据描述一个员工的资料，且修改某个员工资料的任何操作（比如，变动工资）都只限于表中的某一行。 E-R图转化到关系： （1）表示实体。E-R图中的每一个实体类型都转变成为一个关系。实体类型的标识符成为关系的主码，而实体类型的其他属性成为关系中的非主码属性。 （2）表示关系。在设计关系数据库时必须体现出E-R图中的每一种关系。要表达一种关系取决于它的内在性质。例如，有时候通过将一个属性在一个关系中设为主码而在另一个关系中设为外码来表达关系；而在另一些时候，用新建一个单独的关系来表示出这种联系。 （3）规范化关系。在前面两个步骤中建立的关系可能存在不必要的冗余，所以需要进行规范化使其结构完善。 （4）合并关系。到此为止，在数据库设计中已经建立了各种关系，既有从用户角度自下而上建立的关系，也有从一个或多个E-R图中转化而来的关系。在这些关系中可能存在冗余关系（多个关系描述同一个实体类型），它们必须被合并、重新规范化并消除冗余。 实体转换 E-R图中每一个常规的实体类型都被转成了一个关系。实体类型的标识符成为对应关系的主码，而实体类型的其他属性成为了关系中的非主码属性。需要对主码进行检验以确保其满足如下两条性质： 主码的值必须唯一地确定关系中的每一行。 主码应该是无冗余的，即在不破坏唯一性的前提下码中任何一个属性都不能删除。 关系转换 关系的表示方法既依赖于关系层次（一元、二元、三元的），也依赖于关系数量。 在E-R图中实现二元一对多（1：N）关系的方法如下：通过将1：N关系中1这边的实体的主码属性作为外码添加到关系中N这边的关系中。 注意，上述方法中存在一个特例。如果关系中N这边的实体需要关系中1这边的属性作为它的部分主码（称为弱实体），则被选择的属性不再作为非主码，而是作为主码的一部分加入到关系N这边。 对于两个实体A和B之间二元、一元的1：1关系（对于一元关系，A和B将是相同实体类），则可以用如下三种选择之一表示该关系： （1）将A中的主码作为外码加到B中。 （2）将B中的主码作为外码加到A中。 （3）兼有上述二者。 以客户配置订单的关系为例，配置关系连接了客户和订单两个实体，客户和订单分别是两个独立的实体类转化而来的关系（见图9.3）。关系CUSTOMER中的主码客户号（关系中1的这边）作为外码加到了关系ORDER中（关系中N的这边）。 对于二元和更多元的M：N关系，即假设在两个实体类A和B之间有一个二元的多对多（M：N）关系（或联合实体）。 对于这样一种关系，新建一个独立关系C，其主码是由该关系中两个实体的主码组成，而M：N关系中的所有非主码属性都要包含在关系C中。。 如图9.4所示，该请求关系（M：N）连接客户和订单两个实体。在转化时，可将该E-R图转换为三个关系（订单，订单线和产品）。其中订单线关系是由请求 关系生成的，它的主码由订单和产品的主码组成（订单号，产品号）。非主码属性订购数量也出现在订单项中。 有些时候，根据M：N关系新建关系的主码可能不只包括现有两个相关关系的所有主码，如图9.5所示。在这种情况下，日期必须是运送关系的