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

12-01-06 xjg95

简介: 面向对象(OO)和三范式(3NF)都是成熟的设计方法,本文基于面向对象设计思想和三范式数据库设计方法,提出一种实体对象分层建模的思路,其目的是设计简单明了、标准化的数据库结构,同时能够更好的支持模型驱动模型(MDA)的代码自动生成和代码复用,减少代码编写工作量。

本文的标签: fff, oo, 体系架构, 关于产品, 建模, 数据库, 数据访问, 设计

面向对象的数据库设计

本模型探讨的一个数据库建模的方法,其意义主要是为《面向服务体系架构(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 界面

图 1. InfoSphere Data Architect 界面

示例模型说明

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

图 2. 本文示例主要对象关系图

图 2. 本文示例主要对象关系图

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

回页首

对象关系模型

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

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

对象基本关系模型

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

图 3. 对象基本关系图

图 3. 对象基本关系图

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

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

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

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

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

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

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

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

图 4. 对象外键关系图

图 4. 对象外键关系图

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

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

对象变更关系模型

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

图 5. 对象变更关系图

图 5. 对象变更关系图

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

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

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

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

对象汇总关系模型

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

图 6. 对象汇总关系图

图 6. 对象汇总关系图

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

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

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

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

类别对象关系模型

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

图 7. 类别对象关系图

图 7. 类别对象关系图

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

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

图 8. 类别对象合并存储

图 8. 类别对象合并存储

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

附加对象关系模型

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

图 9. 树附加对象关系图

图 9. 树附加对象关系图

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

猜你喜欢