Chapter 13 UML及数据库设计UML and Database Design.pptVIP

Chapter 13 UML and Database Design UML和数据库设计 Chapter 13 UML and Database Design 13.1 数据库结构 数据库结构经历了各个阶段： 网状数据库 层次数据库 关系数据库 面向对象数据库 由于面向对象数据库技术尚未成熟，目 前使用的最普遍的仍是关系模型数据库 13.2 数据库设计 传统的数据库设计是基于E-R模型，其设计方法是自底向上的，即先设计数据库，然后根据数据库设计对象及方法。 需要设计者对E-R映射比较熟练，否则以后的可扩展性可能不好，或者虽然能扩展，但需要对结构做比较大的改动。 传统的数据库设计的优缺点 优点： 设计时可以把逻辑上的东西映射成表，以后数据库比较容易维护。 缺点 系统的可扩展性基本上在数据库设计时就已决定 由于开发模型的不同，不利于开发人员之间的信息交流和共享 使用UML模型设计数据库 UML对象模型在本质上是一个扩展的实体-关系（ER）模型 。 OO模型的主要优势在于编程和数据库的相同的模型工作，降低了设计的盲目性，同时有利于系统的扩展和测试。 把数据库的建模与设计过程统一到软件的分析与设计过程中，提高了开发的效率。 便于开发人员之间的交流和需求分析。 13.3 数据库结构的映射 实现对象模型的第一步是处理标识。 数据库中标识包括主键，外键，候选键。 定义主键有两种基本的方法：1）基于存在的标识。 为每个类表加一个对象标识符属性，并将它设为主键。每个关联表的主键包括一个或更多的相关类的标识符。基于存在的标识符有作为单独属性的优势，占位小且大小相同。唯一的劣势是基于存在的标识符在维护时没有固有的意义。2）基于值的标识。 一些真实世界的属性的组合确定了每个对象，把真实的属性作为主键对于用户有固有的意义，容易进行调试和数据库维护。在另一面，基于值的主键很难改变。一个主键的改变需要传播到许多外键。一些对象没有自然的真实世界里的标识符。 超过30个类的RDBMS应用里使用基于存在的标识。基于存在和基于值的标识都是所有RDBMS应用的可行选项。 13.4 类到表的映射 在将UML模型中的类转换（也可称为映射）为关系数据库中的表时，类中的属性可以映射为数据库表中的0个或者多个属性列，但并非类中所有的属性都需要映射。 如果类中的某个属性本身又是一个对象，则应将其映射为表中的若干列。除此之外，也可将若干个属性映射为表中的一个属性列。 通常情况下，应当为数据库中的每个表都定义一个主键，而将所有的外键都设计为对主键的引用。 13.4 类到表的映射 类图到E-R图的映射主要有类的属性映射和类之间关系的映射。 类中属性的映射就是把属性映射成关系数据库中的0或多列（一般映射为1列）。 对于一些在类中不能持久的属性，映射时可省去。 对于那些本身就可以作为对象的属性，可映射为数据库中的几列，例如两个类，第一个类中有个属性指向第二个类，那么这个属性映射时就可以对应几个列（对应第二个类中的属性）。 13.4.1 关系数据库中实现继承关系的不同方法 将所有的类都映射为表 将有属性的类都映射为表 子类映射的表中包含超类的属性 超类映射的表中包含子类的属性 将所有的类都映射为表 父类和子类都分别映射为表，共享一个主键。 可以最大程度的适合面向对象概念，但容易造成表的数量过多，降低运行速度。 将有属性的类都映射为表 只把有属性的类映射为表 可以适当减少表的数量，其他同方法1 子类映射的表中包含超类的属性 超类不映射为表，只将子类映射为数据库表，同时包含超类中的属性。 可减少表的数量，有利于报表的生成，但如果超类做出修改，则超类映射的每个表都需做相应修改。 超类映射的表中包含子类的属性 只将超类映射为表，子类不做映射。 大大减少表的数量，有利于报表的生成 增加了类层次键的耦合 13.4.1 关系数据库中实现继承关系的不同方法 以上方法各有优缺点，应根据具体情况选择使用。 13.5 关联关系的映射 以上方法各有优缺点，应根据具体情况选择使用。 13.5 关联关系的映射 关系数据库中的关系是通过表的外键来维护的，通过外键，表与表的记录才可以关联起来。 多对多关联的映射 1对多关联的映射 0或1对1关联的映射 1对1关联的映射 多对多关联的映射 类与类之间的多对多关系一般需映射成3个表，每个类映射到一个表，类与类之间的关系也映射到一个表（关联表），并将两个类的键映射为关联表中的属性。 1对多关联的映射 （1）将外部键放在“多”的一边，角色名成为外键属性名的一部分。 1对多关联的映射