• 当前位置:首页>>UML语言>>UML实例分析>>UML在关系型数据库设计中的应用
  • UML在关系型数据库设计中的应用

  • 1. 介绍

       许多人认为面向对象概念和关系型数据库相互不一致,并且不能结合。事实上完全相反!经过灵活的使用,一个关系型数据库能够为面向对象(OO)模型提供一套优秀的实现。同样的模型能够用来开发编程代码和关系型数据库结构。

       关系型数据库技术是意义深远的、强大的,但它比许多开发商使你相信的要难得多。单个表是简单易懂的、直观的。但由数以百计的表组成(这是常见的)的应用要彻底了解是相当困难的。这正是OO模型有用之处。 OO模型使你深入地、连贯地思考问题。

       OO模型提供一种问题的超结构(superstructure)的思考方式,然后该方式能够用关系型数据库的更低层的组成块来实现。

       本文章综合地讨论了关系型数据库技术,而不是集中于特定的产品上。我们将不讨论物理设计细节(例如存储分配和物理聚集),因为它们是依赖于产品的。

       用关系型数据库实现UML模型有两个方面:映射结构(第2节)和映射功能(第3节)。第4节注解了面向对象到关系型数据库的扩展。第5节总结本文章。

    2. 结构映射到表

       UML对象模型在本质上只是一个扩展的实体-关系(ER)模型 。使用设计数据库的ER模型的方式受到普遍接受,而我们以一种近似的但更强大的方式-使用UML对象模型。OO模型的主要优势在于编程和数据库的相同的模型工作。而且,作为考虑功能性的一种方式(第3节),我们强调OO模型的导航。这一节显示如何实现UML对象模型的主要构造。

    2.1 标识(identity)

       实现对象模型的第一步是处理标识。我们从定义几个术语开始。

       1)候选键(candidate key)是一个或多个属性的组合,它唯一地确定某个表里的记录。一个候选键里的属性集必须是最小化的;除非破坏唯一性,否则属性不能从候选键删除。候选键里的属性不能为空。

       2)主键(primary key)是一个特定地选定的候选键,用来优先地参考记录。

       3)外键(foreign key)是一个候选键的参考。外键必须包括每个要素属性的一个值,或者它必须全部为空。外键用来实现关联和一般化。

       正常地你应该为每个表定义一个主键,尽管偶尔有例外。我们强烈建议所有的外键都只指向主键而不是其它的候选键。

       定义主键有两种基本的方法:

       1)基于存在的标识。你应该为每个类表加一个对象标识符属性,并将它设为主键。每个关联表的主键包括一个或更多的相关类的标识符。基于存在的标识符有作为单独属性的优势,占位小且大小相同。只要你的关系型数据库管理系统(RDBMS)受支持,基于存在的标识符就没有性能的劣势。(多数RDBMS提供有效的基于存在的标识符的分配顺序号码。)唯一的劣势是基于存在的标识符在维护时内没有固有的意义。

       2)基于值的标识。一些真实世界的属性的组合确定了每个对象。基于值的标识有不同的优势。主键对于用户有固有的意义,容易进行调试和数据库维护。在另一面,基于值的主键很难改变。一个主键的改变需要传播到许多外键。一些对象没有自然的真实世界里的标识符。

       我们推荐你在超过30个类的RDBMS应用里使用基于存在的标识。基于存在和基于值的标识都是所有RDBMS应用的可行选项。

    2.2 域(属性类型)

       属性类型是UML术语,对应于数据库著作里的域的术语。比起直接用数据类型,域提升到更一致的设计,并便利了应用的定位。

       简单域很容易实现。你仅仅要定义相应的数据类型和大小。并且每个用了域的属性,你都必须为每个域约束加入一条SQL查询子句。简单域的一些例子是:名字(name),长字符(longString)和电话号码(phone-Number)。

       一个枚举域把一个属性限制在一系列的值里。枚举域比简单域实现起来更复杂,图表1显示了四个方法。



    图表1:枚举的实现方法

    2.3类

       正常情况下,我们把每个类映射为一个表,每个属性映射为一个列。你可能因一个已产生的标识符(基于存在的标识符)、隐藏的关联(第2.4节)和通用鉴别器(第2.5节)需要一些另外的列。

    2.4关联

       现在我们讨论关联的实现。我们已经把我们的陈述分为建议的映射(我们正常使用的映射),可选的映射(我们偶尔使用的映射)和不鼓励的映射(我们遇到的应该避免的错误)。我们所有的例子都采用基于存在的标识。

    2.4.1 建议的映射

       多对多关联。用一个特别的表(图表2)来实现一个多对多关联。关联的主键是每个类的主键的合并。那些省略号(...)表示在模型里没有显示出来的属性。主键用黑体字体显示。

       一对多关联。把一个外键隐藏在“多”表(图表3)。角色名字成为外键属性名字的一部分。

       零或一对一关联。把外键隐藏在“零或一”表(图表4)。

       其它一对一关联。把外键隐藏在任一表里。



    图表2:建议的实现:特殊的多对多关联表



    图表3:建议的实现:隐藏的一对多关联



    图表4:建议的实现:隐藏的零或一对一关联

       可选的映射 正常情况下我们使用建议的映射。但有些偶尔的情况,可选的映射更合适。

       特别的表。你也可以用特别的表(图表5)来实现一对多和一对一关联。特别的表给了你更统一的设计和更大的扩展性。无论如何,特别的关联表打碎了数据库,并增加了表的数量。此外,特别的关联表不能强迫一个更低的多重性限度为“一”。



    图表5:可选的实现:特别的一对x关联表

       不鼓励的映射 我们已经注意到有些开发者选择有缺陷的映射。我们要注意这些映射以便可以避免。 合并。不要合并多个类,不要把关联强制成为一个单独的表(图表6)。这样减少了表的数量,但会干扰第三范式。

       两次隐藏一对一关联。不要把一个一对一关联隐藏两次,每次隐藏在一个类里(图表7)。这是多余的,无助于性能。

       相同的属性。不要用相同的属性来实现多个关联角色(图表8)。相同的属性使编程复杂,降低了扩展性。 泛化 现在我们讨论泛化。我们这里只论述单个继承。 建议的映射 最简单的方法是只映射超类和每个子类为一个表。所有的表共享一个共同的主键。应用必须执行子类的划分,因为RDBMS支持。(关于后者的详尽的描述,请参阅第4节。)

       特别的表。映射超类和每个子类为一个表(图表9)。所有的表共享一个共同的主键。鉴别器指出每个子类记录的适当的超类表。

    [1] [2] [3] 下一页  

  • 上一篇:UML辅助网站规划和设计指南
    下一篇:以物件导向方法描述网路电脑辅助教学模型