| 操作系统 办公 实用知识 设计 开发 WEB开发 移动开发 数据库 软件工程 网管 安全 管理 信息化 答疑 渠道 |
使用 UML 进行关系建模关系数据库 关系数据库是一种最常用的数据存储方式，这在很大程度上要归因于其存储原理的简单性给用户带来了更大的灵活性。而且，类表（table-like）结构很容易映射到现实生活中的一些数据格式，例如表单和电子表格。 实体关系（Entity Relationship ER）建模定义了在基于信息的系统的分析和设计中用到的方法学。其输出是一个实体类型、关系类型和约束的列表。ER 建模是基于工件（artifact）的，这里的工件既可以是实际工件的表示，例如 Product 或 Employee，也可以是工件之间的事务的表示，例如 Order 或 Delivery。 关系模型可以直接转换成数据库结构。这种模型包括关系概念中所有的基本元素，比如表和关系，以及现代数据库中增强的能力，比如表空间和索引。 关系建模描述基于工件的、带有关系数据库的系统的设计。关系建模用作对数据库实现的一种抽象。数据库设计人员是这种模型的第一用户。软件开发小组的分析员、开发人员、测试人员以及其他小组成员是第二用户。因此，让关系模型可以被每个人理解，以免在创建和使用数据库的过程中发生错误这一点很重要。 本白皮书将解释关系建模背后的基本概念，如何将关系建模应用到数据库，以及如何使用统一建模语言（Unified Modeling Language， UML）实现关系建模。此外，本白皮书还指出了 ER 建模与关系建模之间的不同点。ER 建模适于问题的分析，而关系建模则处理实现。 关系建模的核心元素 关系模型建立在表这个基本概念的基础之上。表是由一个个具有相同结构的元组（tuple）建立起来的，这些元组称作行（row）。每个行包含了赋给各个列的数据。 关系模型假设每个元组都有一个惟一标识符，这种假设是根据存储在元组中的数据作出的。这种惟一标识符可以是单独的一列，也可以是几个列的组合。但是，表要求所有的行都使用相同的列或列组合作为惟一标识符。同一个表或者不同表中的其他元组可以使用这个惟一标识符作为其所属元组的地址。 那些有其他元组地址的元组指定一个参考，该参考的格式是对应于标识符的列值。参考所需的列必须添加到元组的结构中，因而也就必须添加到表的结构中。 关系建模的两个基本元素是表和关系。 表 包含了具有相同结构的元组的这种元素称作表。表是关系模型的核心组成部件。元组又称作行，它包含了数个列。每个列使用一种能够存储在其中的数据类型定义了可能的内容。 下面的表表示了关于汽车的信息。该表有 5 行数据，描述了 5 辆不同的汽车。每辆汽车在一个有 5 个列的行中得到描述。这些列是 LicenseNumber、Make、Model、Year 和 Color。 LicenseNumber 是惟一地标识一个特定元组的一种途径。它是作为主键的列。表中的行没有排序。
各个列的标题确定了一个表的结构。 一个表的结构规定了这个表的列，反之亦然。列是通过一个名称来标识的，这个名称在表中必须惟一。可选的注释以人类语言定义了一个列的内容。数据类型告诉数据库如何处理这个列以及这个列中将存储什么类型的数据。 是否可以为空（null ability）表达了一个列是在每一行中都是必需的，还是可选的。只有在那些可能没有值的列中我们才可以明确地看到它。
在 UML 中，每个表都是通过一个名称标识的，并显示在一个方框中。我们为我们的表选择名称 Cars。这个名称显示在第一个格子里，同在这个格子里的还有一个将该方框标识为一个表的 stereotype。在 UML 中，stereotype 的作用是定义一个普通构件的特例以及扩展语义。在这里，stereotype table 定义该元素描述的是一个表的结构。 列在方框的第二个格子里定义。每个列由一个后面跟有冒号（:）和数据类型的名称来指定。在名称前面的附加符号定义了每个列是否可以为空。主键用一个 "PK" 来标识。 在下面的表中，LicenseNumber 是表 Cars 的主键。Brand 和 Year 不是可选的，在表 Cars 的每一行中都要为这两列提供数据。Model 和 Color 是可选的，因此并不要求在每一行中都为这两列提供数据。
关系 知道有哪些汽车固然很好，但是我们还想知道是谁拥有这些汽车。Residents 表指定了汽车的潜在车主。为了显示汽车的所有权，我们必须在 Residents 和 Cars 之间建立一个关系。Residents 表的主键是 SocialSecurityNumber。
Cars 和 Residents 是彼此独立的，并不是说有了一辆汽车就必须有一个居民。而且，虽然并不是每个居民都要有一辆汽车，但是一个居民可以有多辆汽车。在这个场景中，Residents 是关系中的父表，而 Cars 是子表。关系是通过将父表中的标识列包括进子表中来建立的。此外，由于表 Cars 与表 Residents 的关系，SocialSecurityNumber 被添加到表 Cars 中。
该表定义不仅包含了列中的数据，而且还包含了到这个列的源 - Residents 表的链接。这个链接是通过一个关系来定义的。 对彼此独立的表 Residents 和 Cars 之间的关系的建模使用一条直线来连接这两个表。伴随这条直线的是一些数字，这些数字指定了在多方参与的关系中每个表的基数。 在下面的例子中，数字定义了一个居民可以是任意数量的汽车的车主，也可以不是任何汽车的车主，而每辆汽车只能为一个居民所拥有。关系定义结尾处的文本定义了关系中参与者的角色。居民在这里的身份是汽车的车主。居民也可以是其他的角色，例如司机。
一个表中的外键（foreign key）是指与关系的父表中的列直接关联的列。 Cars 可以有一些已承认的更改（approved change）。例如，排气系统可能要进行更改，或者整个引擎要进行置换。已承认的更改是在一个名为 ApprovedChanges 的单独的表中表示的。
列 ChangeName 不足以指定一个行的惟一性。因此，这个表没有一个独立的主键。它完全依赖于汽车，因为更改是取决于某一辆特定的汽车的。在这种情况下，我们将父表的主键添加到子表中，并将父表的主键与子表的其他键（如果需要的话）组合起来形成子表的主键。
列 LicenseNumber 和 ChangeName 组合起来构 成主键。之所以需要 LicenseNumber，是因为对汽车的完全依赖。这种依赖被称作标识关系（identifying relationship），标识关系必须建立在两个表之间。
标识关系将另一个主键列添加到子表中。ApprovedChanges 表中的每一行都必须有一辆相关联的汽车。每辆汽车可以有任意数量的已承认的更改，也可以没有更改。关系中的角色名可以忽略。 经过扩展的关系建模 在过去的多年中，提供商们开发了非常强大的数据库，通过引入虚表（virtual table）、约束和可用于确保数据库中的一致性的功能组件，这些数据库提高了数据的适用性，这些举措扩展了关系建模背后的概念。 视图 表代表了数据在数据库中的物理结构。对于要过滤的数据，我们常常需要不同的视图，包含更少数量的行，或者将来自多个表的相关数据包括进来。 例如，如果我们想发现居民所拥有的汽车的品牌，就要对该数据生成一个视图。这个视图将创建一个虚表，表中包括车主和相关的汽车品牌。因此，这里必须联结 Cars 和 Residents 这两个表。这种联结是在关系中描述的。
这个视图的结构包含三个基本组成部分：数据的源，视图中数据的结构，以及转换信息 - 常常涉及选择。这里数据的源是表 Residents 和 Cars。数据的结构是在视图中显示的 4 列：FirstName，MiddleName，LastName，和 Make。转换信息描述如何从数据的源构建出视图中的行来。这个视图将 Residents 和 Cars 这两个表中在 SocialSecurityNumber 字段相匹配的行联结起来。 在 UML 中，视图是以一个方框表示的，其中有一个 stereotype <<database view>> 和名称。数据的源通过依赖来标识，依赖是连接到表或其他视图的直虚线。在更大的图中，可以给依赖命名，以便更容易理解。视图的结构在表示它的那个方框中的第二个格子中描述。有关结构的信息实际上是从源表得来的（在适当的时候直接使用，或经过计算），该信息显示在用于说明的格子里。这些信息包括是否可以为空、可以与源列区分开来的列的名称、数据类型以及列中数据的源。
存储过程 存储数据是数据库的功能之一。数据库必须提供一种存储、检索、计算和更新数据的方法。用户执行转换或业务逻辑来确保数据的一致性。用户经常不得不一次又一次地执行相同的操作。实际上，代码也可以存储在数据库中，而不必在每个请求中动态地执行代码。通过指定的参数（例如客户名称，订单号码，等等）可以使得代码的执行具有可变性。
应用程序不直接访问数据。存储过程隐藏了数据结构和数据构件之间的关系。对存储过程的调用提供了用于执行存储业务逻辑的参数。对于用户来说，存储过程犹如一个黑箱，它可以访问数据库中的任何数据。存储过程有非常稳定的接口，它允许在不与应用程序断开连接的情况下更改数据结构。 存储过程是在设计阶段成组放入容器中的，这样可以更好地概览接口。数据库可能有容器的实现，也可能没有，这取决于数据库的类型。在 UML 中，存储过程容器是由一个方框表示的，这个方框由三个格子组成。第一个格子包含存储过程容器的名称和 stereotype <<stored procedure container>>。通常存储过程被按照功能成组放入容器中。下面的例子展示了容器 SPCCheck ，这个容器将包含用于检查数据库中数据的状态的所有存储过程。 第三个格子包含存储过程的名称和一个参数列表。有两种类型的参数：一种是传递用来执行存储过程的参数，一种是作为存储过程结果返回的参数。此外，参数可以随调用一起提交，并由存储过程修改。存储过程标签中的修饰符有：[in]，用于随对存储过程的调用传递进来的参数；[out]，用于结果；[inout]，用于随调用传递进来的、可以被存储过程修改的参数。"存储过程容器"
函数是一种特殊类型的存储过程。函数是有类型的，它默认地返回一个参数。 约束 数据库的结构并不对数据提供任何强制性。例如，用户可以提供不在预期内的数据（状态‘UNKNOWN’），不正确的数据组合（生日迟于雇用日期），以及不受支持的数字（拥有的汽车数是 -2）。约束可用于阻止这种错误数据的出现。 在下面的例子中，我们创建一个约束，这个约束将批准日期限制为 1990 年 1 月 1 日之后的日期。对表 ApprovedChanges 中的数据的每个操作都将默认地检查这个约束。
关系也可以认为是约束。关系会添加主键或外键到表的规范说明中。主键的约束要求存储在所有键组合中的数据必须是惟一的。外键的约束则规定在被选作参考的列组合中的数据必须与父表的列组合中的数据相对应。 约束不是独立的。它们约束一定的数据结构。约束显示在表的第三个格子中。
stereotype 定义了约束的类型。约束没有参数。约束是隐式执行的。跟在约束名之后的圆括号意味着代码执行。 如果没有到另一个表的关系，外键约束就不能存在。外键约束的规范说明需要对关系的完整定义，包括父表、在父表中参考的约束或列以及在客户表中使用的列。 主键约束要求有与主键相关联的列。检查约束涉及单个的列或者列组合，这在该约束的代码中定义。 触发器 约束可以允许、也可以禁止数据库中的活动。当某个事件发生时，触发器会激活动作。这些事件可以是任何更改数据库内容的活动，包括删除、插入新数据以及更改现有的数据。例如，我们可以指定一个这样的触发器，当有一条用于某个居民的记录被删除时，该触发器将自动更改汽车的所有权。 下面是从数据库中删除 Ken Dietrich （SocialSecurityNumber 865947523）之前的数据快照。
在 Ken 被从数据库删除之前，他拥有两辆汽车。这两辆汽车分别是 BMW （LicenseNumber A17046） 和 VOLVO （LicenseNumber A13502）。
在删除居民记录并从汽车记录中删除所有权之前，触发器可以自动启动。
删除居民记录的这一活动将启动这个触发器，后者执行既定的代码（在本例中，是将 SocialSecurityNumber 设置为 NULL）。
每个触发器是根据启动它的事件（更新，删除，插入）来指定的，每个触发器都被指派给一个表。触发器显示在表的第三个格子中，使用 stereotype <<trigger>>，后面跟上一个名称。触发器没有显式的参数，如果触发器的代码需要参数，它们将使用被更改的那一行的值。 在下面的例子中，触发器事件是使用各种图标显示的（D 代表删除，U 代表更新，I 代表插入）。
ER 模型和关系建模
但是，ER 模型可以转换成关系模型的子集。 在我们前面使用过的有关居民、汽车和已承认的更改的例子中，ER 都是充当关系模型的源。Residents 和 Cars 实体是彼此关联的。实体 Residents 与任意数量的 Cars 相关联。每个 Car 与 0 或 1 个 Residents 相关联。"Entity"
聚集（aggregation）指定 Cars 和 ApprovedChanges 之间的关系。与该聚集相关的基数是无限的，这意味着每辆汽车可以有任意数量的已承认的更改。 与实体的属性相关的数据类型不是数据库相关的。在这个例子中，使用像 String、Date 和 Integer 这样的通用数据类型是允许的。这些数据类型会转换成特定于数据库的数据类型。
使用 UML 转换而来的关系表示采用的是几乎一样的语法。这种表示添加关系数据库的实现所需的附加信息。 这种转换也可以执行更复杂的操作。多对多的关联没有父实体和子实体。双方的实体都是完全独立的，因而要判断键移植中哪个实体扮演父实体的角色是不可能的。因此，多对多关联的转换将产生一个新表。
这个表表示了这种关联的复杂性。它有两个到父表的标识关系。标识关联将主键移植到新表中，作为惟一标识符的一部分。
在表示关系模型的图中，我们没有显示约束。UML 允许您自由选择最适合需求的格式进行显示。在本例中，最重要的是关系本身。 在 ER 模型中触发器没有相应的表示。触发器是数据库开发中用到的一个构件。 存储过程是数据库的过程接口。它们是独立于实体的。因此，在 ER 模型中也没有存储过程的表示。 结束语
UML 是分析员、开发人员和测试人员群体共同使用的语言。本白皮书讨论为增进整个开发小组对数据库的理解而对关系模型使用 UML 的这一方法。 要学习更多关于 ER 建模的知识，以及如何将 UML 应用到 ER 建模中，请参见 "Entity Relationship Modeling with UML"。 IBM 集成软件解决方案 IBM Rational 支持来自 IBM 软件的大量其他的功能。 IBM 软件解决方案使您有能力取得业务领先地位和达到 IT 目标。 DB2® 软件帮助您通过数据使能（data enablement）、数据管理（data management）和数据发布（data distribution）解决方案来利用数据。 IBM 的 Rational 软件帮助公司提高他们的软件开发能力，从而创造出商业价值。Rational 软件开发平台集成了软件工程的最佳实践、工具和服务。有了这个平台，公司就可以有更强的响应能力，有更大的弹性，并且更加集中，从而在随需应变的世界里得以健康发展。 Rational 基于标准的、跨平台的解决方案帮助软件开发小组创建和扩展商业应用软件、嵌入式系统以及软件产品。《财富》排名前 100 名的企业中有 98 家企业都依靠 Rational 工具来更快、更好地构建软件。其他信息请访问 www.rational.com 和 www.therationaledge.com，Rational 社区的电子杂志月刊。
今日推荐
|
重点推荐
领军企业技术文库
+更多领军技术文库
最新专题
电子杂志订阅
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
