基于面向对象（OO）的数据库设计模式探讨

http://www.ibm.com/developerworks/cn/data/library/techarticles/dm-1007xiaojg/index.html

本模型探讨的一个数据库建模的方法，其意义主要是为《面向服务体系架构（SOA）和数据仓库（DW）的思考》（以下简称 《 SOA 和 DW 》）所述的共享库提供方法论支持，建立一个简单明了、易于理解的标准化的数据结构，共享库的主要目的是为了共享数据，需要建立一个简单明了，标准化的数据结构。同时为基于模型驱动 (Model Driven Architecture，MDA) 的设计方法提供一个简化的数据结构，更加容易根据数据结构自动生成代码。

本文采用 InfoSphere Data Architect 作为工具支持，主要针对需要持久化的业务对象（Business Object，BO)）进行实体对象（Entity Object 或者称持久化对象 Persistant Object，PO）的逻辑数据模型 (Logical Data Model) 设计。本文中业务对象设计不再详细论述，假设是已经做了业务对象分析，然后基于业务对象模型生成实体对象模型，并根据实体对象分层模型进一步完善业务对象模型。

面向对象（OO）

面向对象方法 (Object-Oriented Method，OO 方法 ) 是一种把面向对象的思想应用于软件开发过程中，指导开发活动的系统方法，是建立在“对象”概念基础上的方法学。面向对象包含面向对象的分析（Object Oriented Analysis，OOA），面向对象的设计（Object Oriented Design，OOD）、面向对象的编程实现（Object Oriented Programming，OOP）等，面向对象的分析（OOA）方法是本模型的基本方法。面向对象的方法，当前有成熟的基于 UML（Unified Modeling Language）建模方法论，本文不再详述。

范式理论（NF）

第一范式（1NF）无重复的列，实体中的属性不能有多个值或者不能有重复的属性。第二范式（2NF）要求数据库表中的每个实例或行必须可以被唯一地区分，不能存在仅依赖主关键字一部分的属性。 第三范式（3NF）要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。在本模型中，如果出现重复的属性，就需要增加一个实体对象，并根据新增对象和原对象的主键关系确定其对象关系。从性能角度考虑，在数据表中增加了冗余外键对应关系，即并非完全满足 3NF 的要求。

维度建模（DM）

维度建模（Dimensional Modeling，DM）是数据仓库建设中的一种数据建模方法。按照事实表，维表来构建数据仓库，数据集市。在本模型中，对象汇总关系部分采用了维度建模的思想，但是没有深入的探讨维度建模方法论，关于维度建模可以参考相关的资料。

模型驱动架构（MDA）

模型驱动架构 (Model Driven Architecture，MDA) 是由 OMG 定义的一个软件开发框架。它是一种基于 UML 以及其他工业标准的框架，支持软件设计和模型的可视化、存储和交换。和 UML 相比，MDA 能够创建出机器可读和高度抽象的模型，这些模型独立于实现技术，以标准化的方式储存。本模型的第二个目标就是为建立更高效率的自动生成代码提供一个数据基础。。

IBM InfoSphere Data Architect

IBM InfoSphere Data Architect（以下简称 IDA） 是一种协作式的数据设计解决方案，能用于发现、建模、关联和标准化各异的分布式数据资产。如图 1 所示，是实体对象分层模型最终完成之后的界面，IDA 能够很好的支持分层的建模，可以到 IBM 网站下载 IDA 试用版。

图 1. InfoSphere Data Architect 界面[/b]



示例模型说明

为了更好的描述对象模型 , 将以销售管理系统为例进行介绍 , 包含系统管理和销售管理两个部分 , 销售管理主要实现货物的采购和销售管理，包含组织机构、人员、仓库、商品批号、供应商、客户；销售订单、采购订单、出入库单等业务单据。其整体模型如图 2 所示：

图 2. 本文示例主要对象关系图[/b]



以下以面向对象设计为基础，按照三范式建模方式，采用 IDA 7 工具，从最简单的实体对象对象模型入手，逐步细化模型，其基本框架模型下找出所有对象之间的关系，并模式化。

回页首

对象关系模型

业务对象（BO）包含复杂的逻辑关系，通过对业务对象及实体对象之间的关系的分析，将对象的关系简化为对象基本关系、对象变更关系、对象汇总关系、类别对象关系等，针对对象数据不确定的对象，建立属性不确定对象关系。除了对象之间的关系外，本模型增加了一个附加对象层，包含树装结构、时间结构等，用于处理一个特殊的业务需求。

在本模型中，实体对象基本关系是核心，确定了基本关系，也就把数据库的整体框架搭建起来了，其他模型可以看作仅仅是一个范式，在设计数据库的时候选择一个范式即可。本文虽然是以实体对象进行建模，但是其和业务对象是对应的，所以其关系模型也适应于业务对象。

对象基本关系模型

根据实体对象之间的关系，将实体对象分成标准元实体对象、元实体对象和关联实体对象三类。这三类实体对象构成了实体对象关系的基本框架。如图 3 所示：

图 3. 对象基本关系图[/b]



标准元实体对象：实体对象完全独立，不依赖于任何其他的实体对象，典型标准元实体对象如组织机构、国家等内容。标准元实体对象完全独立，有标准的编码体系（一般都有企业标准、国标或者国际标准），不会因为在不同的系统不同有不同编码体系。标准元实体对象只有一个主键。

元实体对象：独立的实体对象，和标准元实体对象不同，一般没有一个唯一的标识符，需要增加一个唯一标识符（比如单位编码，需要制定一个编码规则，主要目的在于未来数据合并的时候不会因为多个系统合并而使得数据重复），然后才能唯一标示对象。元实体对象是建模中最基本、最核心的对象。如客户，订单、流程等，是业务逻辑、对外接口的核心实体对象。标准元实体对象是有标准编码体系特殊的元实体对象。

根据元实体对象数量增长的快慢，可以把元实体对象分成基础元实体对象和流水元实体对象，前者实体对象一般变化缓慢，如客户数据（比较重要的基础元实体对象一般对应着的是主数据），后者变化快，如订单数据等。

关联实体对象：标准元实体对象、元实体对象之间的关联对象，有些仅仅是简单的关联，有些关联对象中含有其他的业务信息。前者仅仅是对应关系，后者包含对应关系的其他属性。如具体一个公司的商品价格信息，是实体对象－商品和组织机构关联之后的信息。关联对象本身也是一个特殊的实体对象。关联实体对象主键一般是两个或者两个以上，一般来说，应该尽量减少关联对象的主键数量。

除了以上基本关系之外，还有一些特殊的实体对象关系，包含附属关联实体对象、主从关联实体对象等

附属关联实体对象：实体对象的附属信息，和实体对象是一对一或者一对多关系。一对一关系一般是为了把一个属性太多的对象分解成多个（在 IDA 中可以用继承来描述）；一对多关系采用增加序号的方式，增加多条信息。如人员的学历、工作经历等。不同于关联对象，其只是简单的序号的增加。订单可以以客户编码和流水号作为主键，但是这种有流水号主键的一般是可以将几个主键合并为一个主键，如果能合并为一个主键，则合并为一个主键，从而简化模型的层次。附属关系一般是为了解决简单一对多的附属信息，如果附属对象需要复杂的业务逻辑，需要将多个主键合并为一个主键。

主从关联实体对象：关联实体对象的一种特殊情况，关联的两个对象之间有强烈的主从关系，如订单和订单项等。主从管理实体对象一般从对象内容有限，在软件实现中一般以单据方式进行展示。

除了基本的关联关系之外，对象和对象之间还有外键关系，外键关系不象关联关系那样是主键关系，外键关系是外键关联。如图 4 所示：

图 4. 对象外键关系图[/b]



在本模型中，比较一个关键的一点是要尽量多的建立元实体对象，特别是标准元实体对象，尽量减少关联实体对象。比如订单，是元实体对象不是关联实体对象，即客户和订单的关系不是主键关系而是外键关系。外键有多种，如一对一、一对多关系等，详见 IDA 中的设置。一个简单的原则可以来判断，如果关联实体对象除了关联的实体对象的主键之外还需要一个独立的主键，就应该考虑看作是一个元实体对象（附属关联实体对象除外）。

对象基本关系模型构成了对象关系模型的主要框架，除此之外，还有一些其他的关系模型，包括对象变更模型、对象汇总模型、类别对象关系模型、附加对象关系模型、不定属性对象关系模型。对于设计者来说，需要关注的仅仅是基本关系模型，其他模型的设计可以看作是固化了的设计范式，只需要设定范式即可。

对象变更关系模型

实体对象实例在业务活动过程中不断发生变化，根据业务的需要，需要记录实体对象实例的变化信息（不同于流水元实体对象，是多个对象实例，比如订单，随着业务的变化，订单不断增加）。包括对象属性变更、对象整体变更、对象快照等。另外从业务上考虑，为了实现操作痕迹化，需要对操作过程进行记录。如图 5 所示

图 5. 对象变更关系图[/b]



实体对象属性变更，对属性变化的历史进行记录。根据记录的先后顺序可以分成两种：采用申请单的方式，先记录变化的信息，然后更改实体对象；监控对象变化，变化之后记录变化之后的属性。对于不重要的属性可以选择不记录变更情况。

实体对象整体变更，对实体对象的变更情况整体记录，记录更改后的完整信息，一般适合于流水元实体对象，用于记录流水对象的变化情况。

实体对象快照，为了便于记录历史信息，可以完整的还原当时的场景，记录当时所有实体对象的信息，作为实体对象的快照进行管理。

实体对象操作痕迹化管理，对于一些关键业务数据，业务上需要保留操作痕迹，比如订单数量修改和删除需要记录相应的信息。采用两种方式来解决，一个是不允许删除实体对象，只做实体对象除删除标记，适用于整条记录删除的情况；对于记录变更的情况，采用增加一个废弃实体对象，记录实体对象的修改记录。

对象汇总关系模型

实体对象发生连续变化之后，需要对变化信息的汇总成为汇总对象，包含汇总和计数，和实体对象的关系为对象汇总关系，包括按照年、月、日、周、季等汇总，分别形成年、月、日、周、季的汇总表。根据汇总对象和原始对象之间的关系，可以分成简单汇总关系和分组汇总关系，后者根据原始对象的外键关系进行分组汇总。分组汇总关系又可以分成历史分组汇总和当前分组汇总。汇总对象属性可能来源于多个原始实体对象，为了统一模式可以先分别汇总，然后再进行合并。如图 6 所示：

图 6. 对象汇总关系图[/b]



简单汇总关系，直接基于原始对象按照时间进行汇总。

分组汇总关系，基于原始对象的外键关系进行分组汇总，比如客户渠道、客户组织机构等，根据外键对象是否变化可以分成历史分组汇总和当前分组汇总。前者按照原始实体对象历史上的状态进行汇总，当前分组汇总根据当前的分类情况进行汇总，其数据是动态的，需要根据最新的分组汇总情况进行重新汇总。

由于汇总对象是对应的实体对象的按照年、月、日的汇总，因此其主键为原实体对象加年 ID、月 ID 或日 ID。是和日期对象的一种特殊的关联实体对象。

汇总对象更多的承担着报表查询的功能，为了提高查询性能，可以在汇总对象增加额外的外键对应关系甚至把属性进行冗余存储。（汇总对象建模需要参考星形建模，详见关于数据仓库建模）

类别对象关系模型

为了减少存储空间和便于统计，将主实体对象（包含元实体对象和关联实体对象）的属性进行分类管理，以编码替代文字描述，成为类别对象，类别对象和主实体对象的关系式外键关联关系。如图 7 所示：

图 7. 类别对象关系图[/b]



类别对象：实体对象的属性描述信息，和元对象的差别是，类别对象仅仅是一个标识和描述，没有具体的业务属性信息，一般不作为主键。根据类别对象是否独立可以将类别对象分成独立类别对象和依附类别对象，前者跟其他的实体对象没有任何关系，后者需要根据关联的实体对象确定对应关系。

合并的类别对象：对于简单的属性，可以汇总为一个对象，通过分类进行管理，如图 8 所示。

图 8. 类别对象合并存储[/b]



由于是对象合并的，所以合并之后的对象需要增加一个主键，作为标识。需要注意的是对象基本关系模型中涉及的标准元实体对象、元实体对象和关联实体对象，除了前两者有一个独立的主键之外，关联实体对象，除了附属关联实体对象外一般都是对应着一组关联对象的主键，关联对象一般没有自己的主键（附属关联对象比较特殊）

附加对象关系模型

附加对象一般不是一个独立的对象，需要附加于其他对象，但是其具有本身的一些特点，包含树、图、修改日志等附加对象。如图 9 所示：

图 9. 树附加对象关系图[/b]



树附加对象，根据实体对象是否可以有多个树，可以将树附加对象分成独立树对象和内嵌树附加对象

独立树对象可以有多个树，即一个实体对象可以出现在不同的独立树对象中。根据实体对象在一个独立树对象中是否可以重复，可以把独立树对象分成唯一独立树对象和复合独立树对象两种。唯一独立树对象中的实体对象在树中式唯一的，复合独立树对象的实体对象在树对象中式可以重复出现的，如上图中的定制菜单，同一个菜单可以出现在不同的菜单目录中。

内嵌树只有一个树附加对象，树附加对象和实体对象是一一对应的，因此一般来说，内嵌树附加对象和实体对象可以合并为为一个对象。

网附加对象是一种特殊的树附加对象，其特点是父对象不是一个，而是两个。网对象根据树附加对象的划分相对应，也可以分成三种。

操作痕迹化记录：每个对象包含：创建时间、创建者、修改时间、修改者。所有的表都可以附加上，作为表结构的一个部分。

对象标识符 ID，系统自动生成，作为对象的唯一标示，可以自动生成，数据迁移之后，其数值会发生变化，不可以作为主键。

不定属性对象关系模型

由于有些对象的属性是不确定的，可以动态增加或者所有对象的属性很多，但是具体到一个对象，其属性有只是很少的几个，属于不定属性对象，为了进行持久化，将对象的属性按照行进行存放。如图 10 所示：

图 10. 不定属性对象关系图[/b]



不定属性实体对象属性多变，没有固定的属性，需要灵活处理每个对象的属性，典型的如考核指标，不同的部门、不同的公司指标的差异非常大，因此需要按照每个指标的类别，在行上进行存储。一般来说，指标本身是一种树，指标本身有关联。

不定属性对象其特点和一般的实体对象一样，其特殊之处在于其属性是变化的，对象实例化的时候，对象是存储是在行上存储的。

如果属性数量是明确的，但是不同类别实体对象具有的属性不同，可以通过继承或者关联关系建立附属关联关系。比如商品信息，分别建立消费品商品信息、电器商品信息等，用与分别记录其不同的信息。

如果属性相对来说是稳定的，但是存在变化的可能，则需要考虑实体对象属性动态增加的模式。比如工资条，存在着工资条内容的增减，因此需要特殊考虑。

本模型以面向对象的分析为基本方法，首先找出业务对象（BO），然后基于范式理论把业务对象转化成实体对象（PO），并进行分类分层管理，根据主键的特点，设置实体对象的基本层级，最终建立实体对象分层模型。

回页首

实体对象关系模型应用

模型在数据结构设计中的应用

在《 SOA 和 DW 》中提到了关于共享库的概念，共享库是为所有厂商提供一个标准数据来源的共享库，是企业级的数据库，由多个厂家共同建设和使用，包含元数据、主数据、用户数据、业务数据等，因此需要共享库数据结构清晰明确，并建立统一的建模标准，因此可以采用本模型进行数据库建设，建立企业级的清晰、规范的数据库模型。《表 1 按照分层模型对数据库表进行分类》。

表 1. 按照分层模型对数据库表进行分类[/b]

模型	对象关系	备注
对象基本关系模型	标准元实体对象	标准元实体对象一般对应着主数据
元实体对象	业务系统的核心实体对象，包含基础元实体对象和流水元实体对象两种
关联实体对象	基于元实体对象的关联关系
附属关联实体对象	特殊的关联实体对象
主从关联实体对象	特殊的关联实体对象
对象变更关系	实体对象属性变更	仅记录某个属性变化信息
实体对象整体变更	记录对象整体变化信息
实体对象快照	记录所有对象的当时信息
实体对象操作痕迹化管理	记录操作者对实体对象的变更信息
对象汇总模型	简单汇总关系	包含日、月、年、周、季等，原始对象的简单汇总
历史分组汇总	原始对象的分组汇总，记录当时历史状况，记录是不可以修改的
当前分组汇总	按照当前分类情况，重新的汇总
类别对象关系模型	全局类别对象	整个系统全部统一
附属类别对象	隶属于元实体对象的类别，不同的元实体对象类别不同
合并的类别对象	对于简单的分类编码，可以汇总为一个实体对象，统一管理所有的分类实体对象
附加对象关系模型	唯一独立树对象	可以有多个树，树的节点实体对象不可以重复
复合独立树对象	可以有多个树，树的节点实体对象可以重复
内嵌树附加对象	实体对象和树附加对象一一对应
网对象	特殊的一种树附加对象，树节点的父节点可以有多个
其他附加对象属性	ID、操作痕迹化记录等
不定属性对象关系模型	包含以上所有对象关系	和前面对象的差异在于其属性由列存储变为行存储

采用本模型，设计者需要关注的仅仅是对象基本关系，即元实体对象和关联实体对象，如表 2 所描述，从而简化了数据结构，统一了数据库设计风格。

表 2. 描述对象关系的表格[/b]

元实体对象（包含是否标准实体对象信息）	关联实体对象（关联的元实体对象以及关联类别）	外键关系（包含实体对象、类别对象）	其他（汇总、变更、附属、不定属性等）
XX 元实体对象	XXX 关联实体对象	XXX 实体对象
XXXXX 实体对象
YY 元实体对象	YY 关联实体对象	YYY 实体对象
YYYY 实体对象

对象基本关系模型确定之后，其他关系可以通过设定已有的模型自动生成，只需要在设计的时候设定其他模型类别即可，比如根据实体对象的变更记录设置，自动生成变更表；根据设定的对象汇总关系可以自动生成汇总表；根据类别对象关系，自动对应类别对象；根据设定的附加对象自动生成树等结构；根据不定属性对象关系自动生成不定属性表等。相关信息可以参考元对象设施（Meta-Object Facility，MOF）的概念，即可以实现 MOF 的 M1 层模式化设计，本文不再详细探讨。

模型在模型驱动架构（MDA）中的应用

实体对象按照分层模型建立之后，在 IDA 中设置词汇表（Glossary），IDA 可以自动生成各种主流数据库的数据结构，同时分层模型建立了实体对象之间的关系，根据实体对象分层模型，进一步完善业务对象（BO）模型，可以设置更多的自动生成代码模板，提高代码生成效率。比如：

主从表关系，可以自动生成所有单据类的代码。

关联实体对象，自动生成对象关联的维护；根据外键关系可以自动生成：简单列表方式选择；外键的外键，简单树型显示；外键 + 外键，笛卡尔积的树显示。

类别对象关系，特殊的外键关系，可以自动生成弹出或者下拉窗口，在数据查询的时候可以自动根据代码转换成文字描述；

对象汇总关系，自动生成汇总程序，需要标记属性的类别，比如汇总还是计数。

对象变更关系，自动生成变更程序以及变更跟踪等。

附加对象关系，比如根据树的类别，自动生成树的维护程序。

不定属性关系，可以自动实现行列转换等的计算等。

基本的数据操作层面的代码可以全部自动生成，如简单的增删改查、以自动完成删除订单，然后自动删除订单项等关联关系。关于更多的 MDA 的实现，将在本文的续篇进一步探讨。

回页首

总结

本文以面向对象设计方法和三范式为基础，提出了分层的实体对象模型，建立了一个标准化的数据库关系模型。遵循这个标准，可以建立更加清晰易懂的数据结构，为建立企业级的共享库打下基础，同时本模型能为更有效的自动生成代码提供基础。

本模型的适用范围和不足：

本模型仅限应用在数据库管理软件中，是面向数据库操作的实体对象建模模型。

本模型仅限解决实体对象之间的关系，如果要实现完整的代码自动生成，还需要界面层的设计模型，复杂业务逻辑和业务规则则需要面向对象的相关方法支持。

本模型无法解决复杂数据处理逻辑的和数据查询方面的课题。