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显示了四个方法。

UML在关系型数据库设计中的应用（图一）

图表1：枚举的实现方法2.3类

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

2.4关联

现在我们讨论关联的实现。我们已经把我们的陈述分为建议的映射（我们正常使用的映射），可选的映射（我们偶然使用的映射）和不鼓励的映射（我们碰到的应该避免的错误）。我们所有的例子都采用基于存在的标识。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显示了四个方法。

UML在关系型数据库设计中的应用（图一）

图表1：枚举的实现方法2.3类

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

2.4关联

现在我们讨论关联的实现。我们已经把我们的陈述分为建议的映射（我们正常使用的映射），可选的映射（我们偶然使用的映射）和不鼓励的映射（我们碰到的应该避免的错误）。我们所有的例子都采用基于存在的标识。
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显示了四个方法。

UML在关系型数据库设计中的应用（图一）

图表1：枚举的实现方法2.3类

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

2.4关联

现在我们讨论关联的实现。我们已经把我们的陈述分为建议的映射（我们正常使用的映射），可选的映射（我们偶然使用的映射）和不鼓励的映射（我们碰到的应该避免的错误）。我们所有的例子都采用基于存在的标识。 QQread.com 推出各大专业服务器评测 Linux服务器的安全性能 SUN服务器 HP服务器 DELL服务器 IBM服务器联想服务器浪潮服务器曙光服务器同方服务器华硕服务器宝德服务器
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显示了四个方法。

UML在关系型数据库设计中的应用（图一）