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）候选键（candidatekey）是一个或多个属性的组合，它唯一地确定某个表里的记录。一个候选键里的属性集必须是最小化的；除非破坏唯一性，否则属性不能从候选键删除。候选键里的属性不能为空。2）主键（primarykey）是一个特定地选定的候选键，用来优先地参考记录。3）外键（foreignkey）是一个候选键的参考。外键必须包括每个要素属性的一个值，或者它必须全部为空。外键用来实现关联和一般化。正常地你应该为每个表定义一个主键，尽管偶尔有例外。我们强烈建议所有的外键都只指向主键而不是其它的候选键。定义主键有两种基本的方法：1）基于存在的标识。你应该为每个类表加一个对象标识符属性，并将它设为主键。每个关联表的主键包括一个或更多的相关类的标识符。基于存在的标识符有作为单独属性的优势，占位小且大小相同。只要你的关系型数据库管理系统（RDBMS）受支持，基于存在的标识符就没有性能的劣势。（多数RDBMS提供有效的基于存在的标识符的分配顺序号码。）唯一的劣势是基于存在的标识符在维护时内没有固有的意义。2）基于值的标识。一些真实世界的属性的组合确定了每个对象。基于值的标识有不同的优势。主键对于用户有固有的意义，容易进行调试和数据库维护。在另一面，基于值的主键很难改变。一个主键的改变需要传播到许多外键。一些对象没有自然的真实世界里的标识符。我们推荐你在超过30个类的RDBMS应用里使用基于存在的标识。基于存在和基于值的标识都是所有RDBMS应用的可行选项。2.2域（属性类型）属性类型是UML术语，对应于数据库著作里的域的术语。比起直接用数据类型，域提升到更一致的设计，并便利了应用的定位。简单域很容易实现。你仅仅要定义相应的数据类型和大小。并且每个用了域的属性，你都必须为每个域约束加入一条SQL查询子句。简单域的一些例子是：名字（name），长字符（longString）和电话号码（phone-Number）。一个枚举域把一个属性限制在一系列的值里。枚举域比简单域实现起来更复杂，图表1显示了四个方法。实现方法优势劣势建议枚举字符。定义一条SQL检查约束，把该枚举限制在允许的值里。简单。受控的方便搜索的词汇表。大的枚举难以使用检查。约束难以编码。我们正常的选择。每个枚举值一个标记。为每个枚举的值定义一个布尔型属性。回避命名的难处。冗长－每个值一个属性。当枚举值不是互相排斥的并且多个值可能同时地应用时使用。枚举表。把枚举定义存储到一个表里。不是每个枚举一个表，也不是所有的枚举一个表。高效地处理大的枚举。不用改变应用的代码就可以定义新的枚举值偶尔使用时很麻烦。必须编写通用的软件来阅读枚举表和加强值。适合大的枚举和没有结尾（open-ended）的枚举。枚举编码。把枚举值编码作为有序的数字。节省磁盘空间。有助于用多种语言处理。大大地复杂化了维护和调试。避免使用，除非你要用多种语言处理。图表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）。所有的表共享一个共同的主键。鉴别器指出每个子类记录的适当的超类表。图表9：建议的实现：分开的超类和子类表。可选的映射泛化有几个可选的映射。消除。你可以优化除去那些除了主键外没有别的属性的类（图表10）。这样减少了表的数量，但提供更少的正规实现。减少超类属性。你可以除去超类表并把超类属性复制到每个子类（图表11）。这样可以有描述每个对象为一个表的优势。无论如何，它将引起数据库结构的冗余，你查找一个对象时可能需要搜索多个子类表。增加子类属性。作为第三个可选项，你可以除去子类表并存储所有的子类属性到超类表里（图表12）。这样用一个表描述每个对象，但干扰了第二范式。图表10：可选的实现：消除不必的子类表图表11：可选的实现：减少超类属性。图表12：可选的实现：增加子类属性。参考完整性一旦你已经建立了表，你就应该定义参考完整性动作来明确对象模型的意义。（不要使用SQL触发器来实现参考完整性！）如果你使用基于存在的标识，你将不需要传播更新的结果。我们建议以下对删除的参考完整性方针：泛化。级联从泛化实现中产生的外键的删除。隐藏的关联，最小化多样性为零。正常地把外键设为空，但有时候你可能要禁止删除。隐藏的关联，最小化多样性为空。你可以级联一个删除的结果或者禁止该删除。关联表。正常地我们级联关联表里对记录的删除。可是，有时候我们禁止一个删除。我们已经简要地论及参考完整性，因为它是个高级话题。参考有更多的解释z和例子。索引实现数据库结构的最后的一步是加入索引来调整数据库性能。正常地，你应该为每个主键和候选键定义一个唯一的索引。（多数RDBMS作为SQL主键和候选键约束的副作用来建立唯一的索引。）你也应该为每个被主键或候选键所约束的外键建立一个索引。我们强调索引的重要性。外键和主键的索引使在对象模型里能快速地遍历是不容怀疑的。你必须包括这些索引否则你将使用户感到灰心。你应该在你的数据库开始设计阶段里加入索引，因为它们很容易加入并且也没有什么好理由推迟加入。数据库管理员（DBA）可能为经常请求的查询定义了额外的索引。DBA也可能采用产品相关的调整性能的机制。范式范式是关系型数据库设计的提高数据一致性的有效方法。我们的书3讨论了范式，但我们关于这个问题却言过甚微。我们将利用这篇文章的机会来澄清我们的观点。如果你不熟悉范式你可以跳过这节。我们的说明是针对关系型设计人员，他们正在尝试用面向对象适应他们原有的技能。范式是正确设计关系型数据库的精确的原则。同样地，它们与使用了什么开发技术是无关的－基于属性的设计、基于实体的设计、面向对象设计或其它什么。过去使用基于属性设计的方法，开发人员不得不非常注意范式；范式提供了分组数据的根据。相反地，范式对于基于面向对象（或基于实体）的开发不是很重要。如果你采用OO方法并且你的模型经过很好的构思，那你就正在把数据组织成为有意义的单位，也在本质上满足了范式的规定。如果你愿意，你仍能够检查范式，但这样的检查是不必要的。摘要图表13总结了我们已经陈述的映射规则。这些映射规则的完整例子，包括一个UML对象模型，能够在这篇完整的扩展版本里找到（AdobeAcrobatPDF文件）。概念对象模型构造推荐的RDBMS映射域简单域映射为一个数据类型和大小标识符用RDBMS顺序号枚举通常储存为一个字符串类类映射每个类为一个表关联多对多关联特别的表一对多关联隐藏的外键一对一关联泛化分开超类表和子类表图表13：推荐的映射规则的摘要。把功能映射到SQL命令对象模型为数据库应用提供三种主要的用途。结构。对象模型指明数据库结构。我们已经在第二节探讨了这个方面。约束。对象模型也指明了能存储的数据上的重要的约束。相匹配的实现必须为迎合这些约束而努力。我们的映射规则的处理方法以及第二节里的参考完整性指出了许多约束。（本文没有论及的另外的UML构造，能获取更多的约束。）潜在估算。一个对象模型指明潜在估算；它是关于引起哪些查询和如何公式化的蓝图。第三节将简要地阐明第三个目的。对象模型不仅仅是被动的数据结构，相反它们能够帮助你思考一个应用的功能。你可以根据遍历一个对象模型说出它的许多功能。例如，根据我们对一个模型检查用例时的遍历，我们进行思索。这强调对象模型的估算能力对于RDBMS应用是特别重要的，因为遍历表达式可以直接映射到SQL代码。UML对象约束语言（ObjectConstraintLanguage，OCL）有助于表达遍历。点符号导航从对象到对象和对象到属性。方括号表示对象集合的过滤器。我们加入冒号（：）操作符来表示泛化的遍历；因为我们正常地用多个表来实现一个泛化继承，清楚的遍历很有用。图表14里的遍历表达式例子是基于我们创建的UML对象模型上的（请参阅本文的扩展版本（AdobeAcrobatPDF文件）），我们把它们映射为SQL代码。我们用冒号开始SQL编程变量。遍历表达式含义SQL代码anAirline.Emploee给定的一条航线，找出相应的员工。SELECTemployeeIDFROMEmployeeWHEREarilineID=:anAirline;anAirline.Employee.name给定的一条航线，找出相应的员工的名字。SELECTnameFROMEmployeeWHEREairlineID=:anAirline;anAirline.Flight[getMo