基于面向对象的业务对象设计模式探讨V0.3

1 基于面向对象（OO）的数据库设计模式探讨 采用 Data Architect进行对象分层建模的方法 摘要 面向对象（OO）和三范式（3NF）是都很成熟的设计方法，本文基于面向对象设计思想和三 范式数据库设计方法，提出一种业务对象分层建模的思路，目的是设计简单明了、标准化的 数据库结构，同时能够更好的支持代码自动生成和代码复用，减少代码编写工作量。 面向对象的数据库设计 本模型探讨的一个重要意义是为《面向服务体系架构（SOA）和数据仓库（DW）的思考》（以 下简称《SOA 和 DW》）所述的共享库提供理论支持，建立一个清晰的、易于理解的业务对象 模型。同时为基于模型驱动（MDA）的设计方法提供一个简化的数据结构，更加容易根据数 据结构自动生成代码。 首先，我们来看几个概念，和本模型的适用范围。 面向对象 XXX 三范式 第一范式（1NF）无重复的列，实体中的属性不能有多个值或者不能有重复的属性。第二范 式（2NF）要求数据库 表 关于同志近三年现实表现材料材料类招标技术评分表图表与交易pdf视力表打印pdf用图表说话 pdf 中的每个实例或行必须可以被惟一地区分，不能存在仅依赖主关键 字一部分的属性。 第三范式（3NF）要求一个数据库表中不包含已在其它表中已包含的非主 关键字信息。 在本模型中，如果出现重复的属性，就需要增加一个业务对象，并根据新增对象和原对象的 主键关系确定其对象关系。从性能角度考虑，在数据表中增加了冗余外键对应关系。本模型 基于三范式来确定对象之间的关系，特别是根据主键的特点，设置对象的基本层级。 维度建模 XXX InfoSphere Data Architect InfoSphere Data Architect 是一种协作式的数据设计解决 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载 ，能用于发现、建模、关联 和标准化各异的分布式数据资产。主界面如下图所示，InfoSphere Data Architect能够很 好的支持分层的建模画图，可以到 IBM 网站下载使用版使用。 图 1 InfoSphere Data Architect 主界面 以下以面向对象设计为基础，按照三范式建模方式，采用 IBM InfoSphere Data Architect 2 7 工具，从最简单的模型入手，逐步细化模型，其基本框架模型下找出所有对象之间的关系 ， 并模式化。 模型适用范围 本模型仅限应用在数据库 管理 档案管理制度成本管理项目成本管理财务成本管理档案管理制度及流程 软件中，是面向数据库操作的业务对象建模模型。 本模型仅限解决业务对象之间的关系，如果要实现完整的代码自动生成，还需要界面层的设 计模型，复杂业务逻辑和业务规则则需要面向对象的相关方法支持。 本模型不打算解决数据处理层面的课题和数据查询方面的课题。 业务对象关系模型 业务对象包含复杂的逻辑关系，通过对对象之间的关系的分析，将对象的关系简化为对象基 本关系、对象变更关系、对象汇总关系、类别对象关系等，针对对象数据不确定的对象，建 立属性不确定对象关系。结合三范式建模的要求，建立了一个关系数据库表间关系建模的一 种方法。本方法可以更加有效规范的实现数据库表之间的关系建模，表结构清晰，特别是适 合基于本数据结构自动生成代码。除了对象之间的关系外，本模型增加了一个附属对象层， 包含树装结构、时间结构等。 对象基本关系模型 根据业务对象之间的关系，将业务对象分成元业务对象、基础业务对象和关联业务对象三类 。 这三类业务对象构成了业务系统的基本框架。 图 2 对象基本关系图 � 元业务对象：业务对象完全独立，不依赖于任何其他的业务对象，典型元业务对象如组 织机构、国家等内容。元业务对象完全独立，有标准的编码体系（一般都有国标或者国 3 际标准），不会因为在不同的系统不同而有不同编码体系。元业务对象只有一个主键。 � 基础业务对象：独立的业务对象，但是其一般没有一个唯一的标识符，需要增加一个唯 一标识符（比如单位编码，需要制定一个编码规则，主要目的在于未来数据合并的时候 不会因为多个系统合并而使得数据重复），然后才能唯一标示对象。一般来说基础业务 对象是建模中最基本、最核心的对象。如客户，订单、流程等，是业务逻辑、对外接口 的核心业务对象。 主数据：基本数据和数据之间的关联；变更数据 业务数据 � 关联业务对象：元业务对象、基础业务对象之间的关联对象，有些仅仅是简单的关联， 有些关联对象中含有其他的业务信息。前者仅仅是对应关系，后者包含对应关系的其他 属性。如具体一个公司的商品价格信息，是业务对象－商品和组织机构关联之后的信息 。 关联对象本身也是一个特殊的业务对象。关联业务对象主键一般是两个或者两个以上， 一般来说，应该尽量减少关联对象的主键数量。 除了以上基本关系之外，还有一些特殊的业务对象关系，包含附属关联业务对象、主从关联 业务对象等 � 附属关联业务对象：业务对象的附属信息，和业务对象是一对一或者一对多关系。一对 一关系一般是为了把一个属性太多的对象分解成多个；一对多关系采用增加序号的方 式，增加多条信息。如人员的学历、工作经历等。不同于关联对象，其只是简单的序号 的增加。 � 主从关联业务对象：关联业务对象的一种特殊情况，关联的两个对象之间有强烈的主从 关系，如订单和订单项，客户评估结果对象和客户评估指标明细结果等。主从管理业务 对象一般从对象内容有限，在软件实现中一般以单据方式进行展示。 除了基本的关联关系之外，对象和对象之间还有一个外键关系，外键关系不象关联关系那样 ， 是外键关联。 4 图 3 对象外键关系图 对象基本关系模型基本包含了常见的对象关系模型，除此之外，还有一些其他的关系模型。 对象变更关系模型 业务对象实例在业务活动过程中不断发生变化，根据业务的需要，需要记录业务对象实例的 变化信息（不同于流水业务对象，是多个对象实例，比如订单，随着业务的变化，订单不断 增加）。包括对象属性变更、对象整体变更、对象快照等。另外从业务上考虑，为了实现操 作痕迹化，需要对操作过程进行记录。 5 图 4 对象变更关系图 � 业务对象属性变更，对属性变化的历史进行记录。根据记录的先后顺序可以分成两种： 采用申请单的方式，先记录变化的信息，然后更改业务对象；监控对象变化，变化之后 记录变化之后的属性。对于不重要的属性可以选择不记录变更情况。 � 业务对象整体变更，对业务对象的变更情况整体记录，记录更改后的完整信息，一般适 合于流水业务对象，用于记录流水对象的变化情况。 � 业务对象快照，为了便于记录历史信息，可以完整的还原当时的场景，记当时录所有业 务对象的信息，作为业务对象的快照进行管理。 � 业务对象操作痕迹化管理，对于一些关键业务数据，业务上需要保留操作痕迹，比如订 单数量修改和删除需要记录相应的信息。采用两种方式来解决，一个是不允许删除业务 对象，只做业务对象除删除标记，适用于整条记录删除的情况；对于记录变更的情况， 采用增加一个废弃业务对象，记录业务对象的修改记录。 对象汇总关系模型 业务对象发生连续变化之后，需要对变化信息的汇总，和业务对象的关系为对象的汇总关系 ， 包括按照年、月、日等汇总，分别形成年、月、日的汇总表。 6 图 5 对象汇总关系图 由于汇总对象是对应的业务对象的按照年、月、日的汇总，因此其主键为原业务对象加年 ID、 月 ID 或日 ID。是和年、月、日对象的一种特殊的关联业务对象。 汇总对象更多的承担着报表查询的功能，为了提高查询性能，可以在汇总对象增加额外的外 键对应关系。（汇总对象建模需要参考星形建模，详见关于数据仓库建模） 如果是多个业务对象汇总为一个业务对象，需要考虑业务对象变更之后的影响，一般有两种 做法，一种是保留元对象的汇总，然后临时汇总；一种是重新汇总 类别对象关系模型 为了减少存储空间和便于统计，将对象的属性进行分类管理，以代码替代文字描述，成为类 别对象 7 图 6 类别对象关系图 � 类别对象：业务对象的属性描述信息，和元对象的差别是，类别对象仅仅是一个标识和 描述，没有具体的业务属性信息，一般不作为主键。 � 对于简单的属性，可以汇总为一个对象，记录所有的属性信息，通过分类进行管理，如 下图所示： 图 7 类别对象合并存储 由于是对象合并的，所以合并之后的对象需要增加一个主键，作为标识。 附属对象关系模型 附属对象一般不是一个独立的对象，需要附属于其他对象，但是其具有本身的一些特点，包 含树、图、修改日志等附属对象。 8 图 8 树附属对象关系图 � 树附属关联业务对象。根据业务对象是否可以有多个树，可以将树对象分成独立树对象 和内嵌树对象，独立树对象可以有多个树，即一个业务对象可以出现在不同的树对象中 ， 内嵌树只有一个树对象，树对象和业务对象是一一对应的，因此一般来说，内嵌树对象 和业务对象可以合并为为一个对象。根据业务对象在一个树对象中是否可以重复，可以 把独立树对象分成唯一独立树对象和复合独立的树对象两种。唯一独立树对象中的业务 对象在树中式唯一的，复合独立树对象的业务对象在树对象中式可以重复出现的，如上 图中的定制菜单，同一个菜单可以出现在不同的菜单目录中。 � 网对象是一种特殊的树对象，其特点是父对象不是一个，而是两个。网对象根据树对象 的划分相对应，也可以分成三种。 � 修改记录，包含创建修改时间、日期和用户等信息，所有的表都可以附加上，作为表结 构的一个部分。 � 每个表包含一个 ID，系统自动生成，作为对象的唯一标示，可以自动生成，数据迁移 之后，其数值会发生变化，不可以作为主键。 � 痕迹化管理：每个对象包含：创建时间、创建者、修改时间、修改者。 不定属性对象关系模型 由于有些对象的属性石不确定的，或者是，比如是动态增加或者属性很多，但是具体到一个 对象，其属性有数据的只是很少的几个，属于不定属性对象。 9 图 9 不定属性对象关系图 � 不定属性业务对象，不定属性业务对象属性多变，没有固定的属性，需要灵活处理每个 对象的各种属性，典型的如 考核 绩效考核绩效考核表绩效考核方案绩效考核系统绩效考核指标 指标、分类指标等。指标之间有关联关系，树对象组合 等。 � 不定属性对象其特点和一般的业务对象一样，其特殊之处在于其属性是变化的，对象实 例化的时候，对象是存储是在行上存储的。 业务对象关系模型应用 共享库的数据结构设计 在《SOA 和 DW》中提到了关于业务共享库的概念，共享库是为所有厂商提供一个标准数据来 源的共享库，因此需要其业务结构清晰明确，可以采用本模型进行数据库建设，建立企业级 的数据库模型。 其中对象基本关系模型 数据库的设计更加规范 企业数据库高阶数据架构 参与者 产品等 自动生成代码 业务对象实例化设计模式固化之后可以方便的实现自动代码生成，根据业务对象的层级以及 对象之间的关系，可以方便的自动生成代码，以提高代码编写效率。 比如主从表关系，可以自动生成所有单据类的代买，对类别对象，可以自动生成弹出或者下 拉窗口，在数据查询的时候可以自动根据代码转换成文字描述。 外键关系可以自动生成 10 1、简单列表方式 2、树型展示 3、外键的外键，简单树型显示 4、外键+外键，交叉树 另外本模型确定之后，基本的数据操作层面的代码可以全部自动生成，如简单的增删改查、 以自动完成删除订单，然后自动删除订单项等关联关系。 附属对象中的树对象，可以用一个通用的代码完成所有的树的维护。 总结 本文以面向对象设计方法为基础，提出了分层的业务对象模型，建立了一个简化的数据库关 系模型，同时为更多的自动生成代码提供基础。 基于面向对象（OO）的数据库设计模式探讨