02数据库建模.pptVIP

第二章 数据库建模 当构建一个数据库应用时，如何以简单明确的方式描述各种数据的结构特征？ 从思想→E/R设计→关系模式→关系DBMS 主要内容： 实体/联系图: E/R图 设计原则 对约束建模 弱实体集 2.1 实体/联系图 Entity/Relationship图，简称E/R图，一种传统的图形化数据库建模语言。E/R模型。 E/R图的主要建模元素 ： 实体集entity set：与类class相对应。描述名称。矩形表示。 属性attribute：描述实体某一个性质的值。只描述名称，不描述类型。椭圆表示。 联系relationship：两个或多个实体集之间的连接关系。通常需要描述名称。菱形表示。 2.1 实体/联系图 2.1 实体/联系图 为仓库管理设计一个E/R模型。仓库主要管理零件(Part)的入库、出库和采购等事项。仓库根据需要 向外面厂家(Supplier)订购零件，而许多工程项目(Project)需要仓库供应零件。 工程项目的属性：项目编号，项目名称，项目开工日期。 零件的属性：零件编号，零件名称，规格，颜色，重量。 供应厂家的属性：工厂编号，工程名称，工程地址。 2.1.1 E/R联系的多重性（multiplicity） 多重性是实体之间存在的定量的约束关系。 本质上区分为两种多重性： 1：关联零个或一个实体，“最多一个” 多：关联零个到多个实体，“能超过一个” 组合起来，考虑实体集A到B的联系： 1对1：A的一个实体对应B的零个或一个实体；且B的一个实体对应A的零个或一个。 1对多：A的一个实体对应B的零个到多个实体；而B的一个实体对应A的零个或一个。（多对1是1对多的逆联系） 多对多：A到B是1对多、且B到A也是1对多。 2.1.1 E/R联系的多重性（multiplicity） 多重性之间的关系： 1对多是多对多的一种特例；多对多包含1对多的情形。 1对1是1对多的一种特例；1对多包含1对1的情形。 假设从实体集A到B有一个联系，确定B方多重性的方法： 先确定实体集A的一个实体时，再判断所联系的实体集B中关联一个还是多个实体。 E/R模型中如何表示多重性： 有箭头所指的实体集为1；无箭头所连接的实体集为多。 多重性是最基本定量关系，有决定数据库基本结构的意义。 2.1.2 多元联系 一个联系涉及两个以上的实体集，该联系就是多元联系。通常是三元联系。 2.1.2 多元联系 三元联系中的多重性是如何确定： 实体集A和B先分别确定一个实体，判断联系的C的实体是一个还是多个。 2.1.4 联系中的属性 除了实体集可定义属性之外，联系也可定义属性来扩展语义。 三元联系：Contracts可定义一个salary(片酬)和signdate(签约时间)的属性 。 二元联系：Movies和Stars之间的stars-in可定义时间等属性 。 2.1.5 把多元联系转换为二元联系 转换目的： 简化模型，方便设计和实现。 将多元联系（以三元联系为例）转换到二元联系，而不丢失信息的方法： 把三元联系表示为一个实体集，称为连接实体集（一种特殊的实体集，可等价表示一个联系。通常有属性）； 确定连接实体集的属性； 分别建立该实体集到三个原实体集的多对1的二元联系。 需要把联系转化为实体集的情况： 多元联系；多对多联系；有属性的联系 2.2 设计原则 设计原则是指导我们分析需求，设计解决方案的准则。 其目的是为了真实全面反应客观需求，以得到良好的设计，且应避免常见问题。 原则： 真实性； 避免冗余； 简单性； 选择合适的元素类型。 2.2.1 真实性 真实性原则： 忠实反映需求规范：实体集、联系和属性应反映客观的实际情况。 最基本原则：保持一致性，不自相矛盾。 若违背此原则，将会得到无效甚至有害的设计。 2.2.2 避免冗余 避免冗余原则： 对任何事物的任何性质的描述，都仅描述一次。 若违背此原则，会造成一致性难以维护，空间浪费等问题。 2.2.3 简单性 简单性原则： 避免引入多余的元素。 若违背此原则，多余实体集必然导致多余的联系，空间浪费；易出错等问题 要点： 对1对1联系的实体集要仔细研究是否多余。 若两个实体集之间是1对1联系，且有相同的键，则应考虑合并两个实体集。 避免冗余和简单性都是关于“独立性”。每个建模元素所表示的含义都不可替代。 2.2.4 选择合适的元素类型 “合适”原则： 表示事物的某个性质时，可能面临多种建模元素的选择。 相对的合理；更自然；更简单；更贴近需求。 是选择属性还是实体集： 若某事物具有除名称之外的更多信息，则应建模为一个实体集；否则应为属性。 是选