关系数据库管理系统是最常见的数据库使用形式。IBM Rational 的 UML 数据建模配置文件提供了一种为满足数据库建模和数据库设计的需要而使用和理解 UML 的简单的方法。

数据库技术

数据库是按照一种易于利用程序进行存储和检索的方式组织的数据集合。数据库包含了存储和检索信息的方法。

这些信息以及组织这些信息的需求因应用程序类型的不同而异。但是，关系数据库可以满足大部分的市场和常见需求。其他类型的数据库，比如层次数据库、面向对象数据库和超文本数据库也在市场上占有一席之地。

关系数据库实现了实体的一个非常简单的原则，该原则可以看作是表，以及作为其他实体的引用的实体间的关系。关系数据库支持的其他概念用于实现更轻松的访问、速度和安全性。

关系数据库建模系统（Relational Data Base Modeling System）技术是市场上最可靠的技术之一。其基本思想已有三十多年的历史，第一个产品也于 25 年前就开发出来了。

标准化的呼声越来越高，于是就产生了 SQL，它是用于数据定义和数据操纵的标准化语言。有三个版本的标准，分别叫做 SQL-1、SQL-2 和 SQL-3。尽管早在 1992 年就已标准化，但 SQL-2 仍是目前主要供应商最常使用的一种标准。他们利用自己的语言和结构构造扩展了他们的实现，以涵盖市场需求。

统一建模语言

统一建模语言与 SQL 相比算是一种比较新的技术。UML 在 1997 年被标准化，之后有一些小的修订。但是 UML 的源头可追溯到上世纪 80 年代以及 90 年代初，当时不同的建模语言正试图建立一种描述和设计更好的应用程序的方法。

该语言最初针对软件开发，但是它有足够的远见，所以不仅限于任何方向。UML 隐含了自适应的概念，可用于描述软件相关和不相关的专业领域。配置文件在不偏离该语言标准的情况下将 UML 定制到一个领域。

统一建模的力量在于将所有领域的专业知识合并在一个统一平台中。不管使用哪种技术，都可以利用相同的语言对它们进行描述。

UML 数据建模配置文件

关系数据库管理系统是最常见的数据库使用形式。IBM Rational 的 UML 数据建模配置文件提供了一种为满足数据库建模和数据库设计的需要而使用和理解 UML 的简单的方法。数据库中使用的表和关系的概念在核心 UML 中被映射为类和关联的概念。但是在数据库建模中还有其他的构造和约束（比如数据库和模式）必须被可视化地建模。

图 1 显示了数据库部署的多样性。以下这些复杂分配：表与视图到模式、模式到数据库、数据库到表空间（tablespace）和节点，把需要底层构架的一种简单表示的每个数据库管理员（DBA）搞得晕头转向。因此计划数据库的分发和配置成为一项关键能力。

节点

数据库所在的物理实体（计算机）被表示为节点。该表示法是核心 UML 的一部分。

节点用于部署图中，代表了软件部署的物理配置。部署图包括节点以及节点间的连接。这些连接代表了通信协议。

"DB2 Server Lexington"、"Oracle Server Cupertino"和"Oracle Sever Redmond"代表了节点，XML、JDBC 和 OraNet代表了通信协议。所有的软件和数据库都必须部署在物理节点上。

部署图对于数据管理员配置服务器和跟踪问题很重要（首先开始部署，然后开始钻研细节）。

表空间

表空间是数据的存储器，代表了一个数据库系统。它是称为 Database 的用户透明物理结构（在下文中描述）和节点之间的链接。表空间是 UML 数据建模配置文件中的原型化组件。

表空间可理解为物理存储上的一个区域，其中该物理存储由数据库来维护。数据库本身可以被分发给数个表空间，这些表空间由数据的大小、数据访问需求和安全需求来决定。

表空间利用依赖关系在数据库中关联，并且在数据库实现的设计阶段是可选的。如果没有使用，将采用数据库维护的默认表空间。

表空间在数据库实现中的价值在于计划节点环境和建立节点需求。借助于组件图的帮助，跟踪部分数据库的问题变得更容易。可利用数据库或表空间来实现表。在利用数据库实现时，会使用默认的表空间。

表空间作为物理存储单元的基本结构是由不同的数据库供应商实现的。他们在存储需求和存储内部结构上给予表空间或多或少的控制。

数据库

数据库是用于物理数据存储以及对已存储数据的受控访问的系统。它是用于数据建模的最大的专门元素。数据库是一个原型化组件，并且是 UML 数据建模配置文件的一部分。

数据库定义了数据库类型，以及用于数据建模的约束，比如数据类型、存储过程、语法等。数据库级别是对信息的基本访问级别，可以在更高级别上进行精化。

数据库与组件图中的其他组件结合使用，来定义应用程序和数据库之间的依赖关系。

数据库组件对于设计者的价值在于计划数据库的可访问性。对数据库的模式分配定义了信息存储的基本结构。

数据库管理员使用部署图来找出应用程序和数据库之间的通信问题，并定义数据以及部署图的物理部署。

模式

表的基本组织单元就是模式。模式是 UML 的组织单元，用包表示。模式是原型化的包，并且是 UML 数据建模配置文件的一部分。

模式是应用程序使用的基本单元。它还是一个可以被授予特权的单元。模式在下一个细节级别上被指定给数据库组件。

模式是在类图中组织的。

模式应该分配给数据库，因为数据库定义了语言约束、数据类型、可用触发器、可能的数据库约束以及存储过程类型。

模式不仅仅是一个组织单元；它还是一种安全机制。类图允许数据库管理员和分析人员找出基于应用程序的包和数据之间的依赖关系，从而产生数据库的使用模式。

表

表是关系数据库的基本建模结构。它代表了具有相同结构的一组记录，也被称作行（row）。每条记录都包含数据。有关表结构的信息存储在数据库中。

表是一种原型化类，并且是UML数据建模配置文件的一部分。

表是在数据模型图中表示的。

由于该图只是模型的一个视图，因此它可以代表面向表焦点的解决方案。这避免了由于构建一个巨型的模型图而导致无法找到您正在寻找的物理数据模型的范围。

该数据模型图具有表、视图、表间的关系、视图的依赖关系和存储过程容器，精确地表示了数据词典的一部分。数据管理员可以在更加可读的图形表示中找出数据库的结构。

在设计方面，利用图形表示更容易调整数据库，因为您能够看到表的内容以及文档的每个细节。由于调整经常是一个手动过程，所以表间的数据移动是一项必需的功能。只需要知道所有模型约束的知识就能实现该功能。

构架师不关心数据模型图的详细信息，但是他可以检查是否所有信息都表示在数据库中。

视图

视图是一个虚拟表。它代表了具有相同结构的一组记录，这与表完全一样，唯一的区别在于数据的物理资源在其他表中。

视图是一个原型化类，并且是 UML 数据建模配置文件的一部分。

视图是在数据模型图中表示的。

由于该图只是模型的一个视图，所以它可以代表面向视图中焦点表中焦点的解决方案。

在视图中对表进行建模的价值不仅仅在于为数据库定义数据结构，还在于数据的面向问题的分析（这不能在数据库本身的知识库中完成）。很容易发现数据结构和数据源之间的依赖关系。

列

列是关系数据库内部的基本组织元素。每个数据都必须存储在表中的行的一列中。这些列作为原型化属性是 UML 数据建模配置文件的一部分。

列添加了必须指定的数据类型标签值。另外，列数据可以作为工件物理存储在数据库中，或者利用表达式从其他列进行计算。

列还具有其他标签值，他们指定了数据模型的细节，比如 null 和唯一性。

列定义的价值在于数据结果的规格说明。另外，它还可用于不同数据源的集成以及实现互相之间相同点和不同点的发现。

键

键用于访问表。主键唯一标识了表中的一行，而外键则访问其他相关表中的数据。

主键通常是内容无关的，并且由数据库自动生成，以方便数据的更新。

外键总是从与其他表的关系派生而来。

键是键约束（Key Constraints）的实现。键约束指定了键的内容（哪些列生成了键），以及键的物理实现。为了轻松识别表中的键列，它们被用主键（<<PK>>）或外键（<<FK>>）原型标记。在将外键用做主键的情况下，组合键被标记为(<<PFK>>)原型。

键代表数据的识别。因此它们是识别数据库（所有链接都位于数据之间）的完整结构，以获得纯工件之外的信息所必需的。

索引

索引是支持快速数据访问的物理数据结构。它完全不改变数据的质量。

索引在 UML 数据建模配置文件中被表示为操作上的原型。

索引和键都包含了几个列。索引中的列必须有顺序。

索引规格说明不但包含索引的列，还包含索引的类型（唯一性等）。

当某些因素影响了应用程序的性能时，索引的价值就被体现出来。索引是首先要注意的地方。

约束

约束是应用于数据库结构的规则。该规则可应用于列和/或表，并且可能被限制到一个模式或数据库。

UML 数据建模配置文件中定义了几种类型的约束，但是，它们作为原型化操作来实现。

定义的约束值位于规格说明的细节中。约束描述了数据库的动态行为，而列和表则没有描述这些内容。

主键

主键约束定义了表的一个主键。每个表只能有一个主键。
主键约束在 UML 数据建模配置文件中使用了原型<<PK>>。

外键

外键是实现一个关系的约束。该约束总是在子表上实现的。
外键约束在 UML 数据建模配置文件中使用了原型<<FK>>。

触发器

作为其他活动的结果自动被执行的一个活动就是一个触发器。它经常是数据库中数据修改的副产品，并且大部分情况下保证了数据库的一致行为。
触发器约束在 UML 数据建模配置文件中使用了原型<<Trigger>>。

值验证

列中的值可以利用触发器验证。触发器不但能与固定范围的值进行比较，还能与数据库中的其他数据进行比较。
值验证约束在 UML 数据建模配置文件中使用了原型<<Check>>。

唯一性

唯一性约束保证了指定列的所有值都是不同的。
唯一性约束在UML数据建模配置文件中使用了原型<<Unique>>。

关系

数据模型中表之间任意种类的依赖关系被称作关系。

关系是原型化关联和一组主键和外键的汇总。每个关系都位于一个父表和一个子表之间，其中父表必须定义一个主键。子键创建了一个外键列和外键约束，以满足父表的要求。

non-identifying 关联代表了两个独立表之间的关系。子表的外键不包含所有的主键列。

一个识别关系是两个依赖表间的关系，其中如果没有父表子表就不能存在。父表（本例中为 Person）的所有主键在子表（Account）中同时变成了主键列和外键列。

一个关系有两个与之关联的角色。它们定义了与其他表关联的一个表的角色。可以利用不同角色在两个表间指定一个以上的关系。

每个关系都创建了从父表到子表的迁移键。

结束语

有了 UML 数据建模配置文件，UML 能够完全支持数据建模需要。它支持利用一种统一语言进行软件开发和数据建模。IBM Rational Rose 数据建模利用UML数据建模配置文件，借助一个单一的共享工具统一了软件开发团队。

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文。

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号