UML与数据库设计56

UML建模与分析1第12章UML与数据库设计理解UML模型与数据库设计间的关系1将UML模型中的类映射为数据库表2UML模型中关联关系的转换3进行关系约束的验证4了解如何用SQL语句实现数据库功能5将UML模型映射为关系数据库6UML建模与分析2第12章UML与数据库设计在过去的几十年中，关系数据库模型征服了数据库软件市场，关系数据库技术为数据库行业作出了巨大贡献。尽管未来不再属于关系数据库模型，但是大型系统采用对象关系数据库技术或者对象数据库技术还需要若干年时间，还会有许多新的应用程序采用关系数据库技术。在关系数据库中，关系就是一张二维表格，表格的行代表了现实世界中的事物和概念（对象），列表示这些事物或概念的属性。表中事物之间的关联由附加列或附加表来表示。UML建模与分析3第12章UML与数据库设计随着面向对象技术的发展，许多建模人员都意识到了实体-关系模型的局限性；UML不仅可以完成实体-关系图可以做的所有建模工作，而且可以描述其不能表示的关系。本章将介绍UML模型到关系数据库的映射问题，主要涉及两个方面：模型结构的映射和模型功能的映射。UML建模与分析412.1数据库结构从数据库技术诞生到现在，经历了多种结构。1234•网状数据库•层次数据库•关系型数据•面向对象的数据库UML建模与分析512.1数据库结构在理想情况下，组织对象数据库的最好方式是直接存储对象及其属性、行为和关联。这种数据库称为面向对象数据库。面向对象型数据库管理系统（ODBMS）在理论是可用的，但还存在相对有限的有效性等问题。影响了这种系统的广泛应用。这里还有一个主要问题，传统型的数据库其理论已经相当成熟，其性能非常可靠并且已经被广泛应用，这导致了人们不愿意用他们非常有价值的资源来冒险。UML建模与分析612.2数据库接口数据库接口将实现从业务层对象中获取数据，保存到数据库。该接口必须调用DBMS所提供的性能来对对象及其关联进行操作，这些操作是独立于数据库结构的。对于对象程及其关联而言，一个对象需要有四种操作，关联需要两种操作，这些操作是独立于数据库的组织。UML建模与分析712.2数据库接口对象上的一般操作：Creat建立新对象Remove删除存在的对象Store更新已经存在的对象的一个或多个属性值Load读入对象的属性数据关联上的一般操作：Creat建立新链接Remove删除已存在的链接UML建模与分析812.3数据库结构转换在设计关系型数据库时，人们通常使用实体-关系模型来描述数据库的概念模型。与实体-关系模型相比，UML的类图模型具有更强的表达能力。本节将介绍从UML类图模型到关系数据库的结构转换问题。UML建模与分析912.3.1类到表的转换（1）转换原则在将UML模型中的类转换（也可称为映射）为关系数据库中的表时，类中的属性可以映射为数据库表中的0个或者多个属性列，但并非类中所有的属性都需要映射。如果类中的某个属性本身又是一个对象，则应将其映射为表中的若干列。除此之外，也可将若干个属性映射为表中的一个属性列。通常情况下，应当为数据库中的每个表都定义一个主键，而将所有的外键都设计为对主键的引用。主键定义方法：一是将对象标识符映射为表的主键（在表中添加一个对象标识列，并定义为主键）；二是将类的某属性映射为表的主键。UML建模与分析10（2）转换方法（包括继承关系的处理）方法一：将所有类都映射为表（类的属性映射为表的属性列）。此时，超类和子类都映射为表，它们共享一个主键。12.3.1类到表的转换很好地支持多态性，但是会导致数据库中表的数量过多，读写时间过长。UML建模与分析11方法二：将有属性的类映射为表可减少数据库中表的数量12.3.1类到表的转换UML建模与分析12方法三：子类映射的表中包含超类的属性。只将子类映射为表，超类并不映射为表。在子类映射而来的表中，属性列既有从子类属性映射而来的，也有从超类继承的属性映射而来的。可减少数据库数量。12.3.1类到表的转换缺点：修改超类时子类映射而来的数据表也要修改，并且不利于在支持多个角色的同时维护数据完整性。UML建模与分析13方法四：超类映射的表中包含子类的属性。只将超类映射为表，子类并不映射为表。在超类映射而来的表中，属性列既有从超类属性映射而来的，也有所有子类的属性。12.3.1类到表的转换减少了数据库表的数量，且有利于报表的生成。但是耦合性强，一个地方出错可能影响类层次结构中其他类。另会浪费系统存储空间。UML建模与分析14评价：以上四种方法各有所长，在实际应用中，根据具体情况选用。一般情况下，建议选用第三种方式，即只将子类映射为表，各表中包含子类自身的属性和继承自父类的属性。12.3.1类到表的转换UML建模与分析1512.3.2关联关系的转换在将UML模型向关系数据库转换时，不仅需要转换模型中的类，还需要转换类与类之间的关系，例如，关联关系、泛化关系等。聚合关系和组合关系是特殊的关联。关系数据库中的关系是通过表的外部键来维护的，通过外部键，一个表中的记录可以与另一个表中的记录关联起来。关联关系：一对一关联、一对多关联和多对多关联。“一”：多重性为“1”，“0..1”“多”：多重性为“1..n”，“0..n”UML建模与分析16要映射多对多关联关系，通常使用关联表。关联表是独立的表，它可以维护若干个表之间的关联。通常情况下，将参与关联关系的表的键映射为关联表中的属性。一般将关联表所关联的两个表的名字的组合作为关联表的名字，或是将关联表所实现的关联的名字作为关联表的名字。（1）多对多关联关系的映射12.3.2关联关系的转换UML建模与分析17（2）一对多关联关系的映射在映射一对多关联关系时，有两种方法：一是将外键放置在“多”的一边，而将角色名作为外键属性名的一部分；二是将一对多关联映射为关联表。方式一方式二12.3.2关联关系的转换UML建模与分析18（3）一对一关联关系的映射将相关联的两个类分别映射成两张表，并将任意一张表的主键放入另一张表中作为外键。12.3.2关联关系的转换UML建模与分析19注意事项1：不能将多个类与相应的关联合并成一张数据库表，这样违背了关系数据库的第三范式。12.3.2关联关系的转换UML建模与分析20第一范式：保证列的原子性，即数据库表的每一列都是不可分割的原子数据项，而不能是集合，数组，记录等非原子数据项。第二范式：当复合主键时，非主键字段必须与主键字段有直接依赖。满足第二范式必须先满足第一范式。第二范式要求数据库表中的每个实例或记录必须可以被唯一地区分。第三范式：非主键字段不能有直接依赖关系。满足第三范式必须满足第二范式。第三范式要求一个关系中不包含已在其它关系包含的非主关键字信息。12.3.2关联关系的转换UML建模与分析21注意事项2：实现一对一关联关系时不能将外键放在两个数据库表中。12.3.2关联关系的转换UML建模与分析2212.4完整性与约束验证UML模型中类与类之间的关系是对现实世界商业规则的反映，在将类图模型映射为关系数据库时，应当定义数据库中数据上的约束规则。如果使用对象标识符的方法映射数据库表的主键，在更新数据库时就不会出现完整性问题，但是对对象之间的交互和满足商业规则来说，进行约束验证是有意义的。本节将介绍如何进行关系约束的验证。UML建模与分析2312.4.1父表的约束对于类图模型中的关联关系来说，如果比较松散，则通常不需要进行映射，也就是说，关联的双方只在方法上存在交互，而不必保存对方的引用；但是如果双方的数据存在耦合关系，则通常需要进行映射。（1）强制对可选约束Coach和Footballer之间具有强制对可选约束，该图演示了如何将它们映射成数据库表。CoachFootballer10..*CoachtableFootballertablecoachID...footballID...coachID(referencesCoach)UML建模与分析24父表上操作的约束主要有：--插入操作：由于强制对可选约束的父亲可以没有子女，故父表中的记录可以不受限制地添加到表中。--修改键值操作：要修改父表的键值，必须首先修改子表中其所有子女的对应值，通常采用如下的步骤：（1）向父表中插入新记录，更新子表中原对应记录的外部键，然后删除父表中的原记录；（2）使用级联更新方法更新数据库。12.4.1父表的约束UML建模与分析25--删除操作：要删除父表记录，必须首先删除或者重新分配其所有子女。在Coach-Footballer关系中，所有的footballer都可以重新分配，可采用如下步骤：（1）首先删除子记录，再删除父记录；（2）先修改子记录的外键，再删除父记录；（3）采用级联删除方法更新数据库。12.4.1父表的约束UML建模与分析26（2）可选对可选约束可选对可选约束的关联及其映射的数据库表如图所示，其中Patient表中的doctorID为外键，并且该外键的值可以为空。此时，Doctor表和Patient表中的记录可根据需要进行修改，处理方法同下面的聚合关系的处理方法相同。12.4.1父表的约束UML建模与分析27（3）可选对强制约束（聚合关系）子表Student中的外键associationID可以取空值12.4.1父表的约束AssociationtableStudenttableassociationID…studentID…associationID(referencesAssociation)UML建模与分析28父表上操作的约束主要有：--插入操作：在可选对强制约束中，必须在至少有一个子女被加入或至少已存在一个合法子女的情况下，父亲才可以加入。具体采用如下的步骤：（1）首先向父表中添加记录，再修改子表中的外键；（2）以无序的形式同时加入父表和子表记录，然后再修改子表的外键。12.4.1父表的约束UML建模与分析29--修改键值操作：执行这种操作的前提是，必须至少有一个子女被创建或者至少已经有一个子女存在，具体采用如下的步骤：（1）在修改父表键值的同时将子表中的外键置空；（2）将子表按照从父亲到儿子再到孙子的次序进行级联修改。--删除操作：通常情况下，不使用级联删除子表的方法删除父表记录，而是将子表的外键置空。12.4.1父表的约束UML建模与分析30（4）组合关系（强制对强制约束）子表DailyCharge的外键enterpriseBillID是强制性的，不能取空值。12.4.1父表的约束UML建模与分析31父表上操作的约束主要有：--插入操作：可以在向父表执行插入操作后再向子表添加记录，也可以通过重新分配子表来实施完整性约束。--修改键值操作：该操作的执行前提是，必须先更新子表对应的外键的值，或者先创建新的父表记录，再更新子表所对应的记录，使其与父表中的新记录关联起来，最后删除原父表记录。--删除操作：要删除父表中的记录，必须首先删除或者重新分配子表中所有相关的记录。12.4.1父表的约束UML建模与分析3212.4.2子表的约束有时，要删除或者修改子表中的记录，必须在该记录有兄弟存在的情况下才能进行。在可选对强制、强制对强制约束中，就不能删除或者更新子表中的最后一个记录。在这种情况下，可以及时更新父表记录或者禁止这种操作。通过向数据库中加入触发器可以实现子表约束，但是更好的办法是在业务层中实现对子表的约束。UML建模与分析33子表的约束12.4.2子表的约束UML建模与分析3412.5关于存储过程和触发器存储过程是需要在数据库服务器端执行的函数/过程。在执行存储过程时，通常都会执行一些SQL语句，最终返回数据处理的结果，或者出错信息。总之，存储过程是关系数据库中的一个功能很强大的工具。在实现UML类模型到关系数据库的转换时，如果没有持久层并且出现如下两种情况，就应该使用存储过程：需要快速建立一个粗略的、不久后将抛弃的原型。必须使用原有数据库、而且不适合用面向对象方法设计数据库。UML建模与分析3512.5关于存储过程和触发器触发器也是一种存储过程，