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

基于面向对象（OO）的数据库 设计 领导形象设计圆作业设计ao工艺污水处理厂设计附属工程施工组织设计清扫机器人结构设计 模式 探讨 采用 InfoSphere Data Architect 进行对象分层建模的方法 肖建国, 产品经理, 浪潮软件 简介： 面向对象（OO）和三范式（3NF）都是成熟的设计方法，本文基于面向 对象设计思想和三范式数据库设计方法，提出一种实体对象分层建模的思路，其 目的是设计简单明了、标准化的数据库结构，同时能够更好的支持模型驱动模型 （MDA）的代码自动生成和代码复用，减少代码编写工作量。 发布日期： 2010 年 7 月 29 日 级别： 初级 访问情况 ： 15078 次浏览 评论： 0 (查看 | 添加评论 - 登录) 平均分 (18个评分) 为本文评分 面向对象的数据库设计 本模型探讨的一个数据库建模的方法，其意义主要是为《面向服务体系架构（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）要求数据库 表 关于同志近三年现实表现材料材料类招标技术评分表图表与交易pdf视力表打印pdf用图表说话 pdf 中的每个实例或行必须可以被唯一地区分， 不能存在仅依赖主关键字一部分的属性。 第三范式（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 界面 示例模型说明 为了更好的描述对象模型 , 将以销售管理系统为例进行介绍 , 包含系统管理 和销售管理两个部分 , 销售管理主要实现货物的采购和销售管理，包含组织机 构、人员、仓库、商品批号、供应商、客户；销售订单、采购订单、出入库单等 业务单据。其整体模型如图 2 所示： 图 2. 本文示例主要对象关系图 以下以面向对象设计为基础，按照三范式建模方式，采用 IDA 7 工具，从最简 单的实体对象对象模型入手，逐步细化模型，其基本框架模型下找出所有对象之 间的关系，并模式化。 回页首 对象关系模型 业务对象（BO）包含复杂的逻辑关系，通过对业务对象及实体对象之间的关系的 分析，将对象的关系简化为对象基本关系、对象变更关系、对象汇总关系、类别 对象关系等，针对对象数据不确定的对象，建立属性不确定对象关系。除了对象 之间的关系外，本模型增加了一个附加对象层，包含树装结构、时间结构等，用 于处理一个特殊的业务需求。 在本模型中，实体对象基本关系是核心，确定了基本关系，也就把数据库的整体 框架搭建起来了，其他模型可以看作仅仅是一个范式，在设计数据库的时候选择 一个范式即可。本文虽然是以实体对象进行建模，但是其和业务对象是对应的， 所以其关系模型也适应于业务对象。 对象基本关系模型 根据实体对象之间的关系，将实体对象分成标准元实体对象、元实体对象和关联 实体对象三类。这三类实体对象构成了实体对象关系的基本框架。如图 3 所示： 图 3. 对象基本关系图 • 标准元实体对象：实体对象完全独立，不依赖于任何其他的实体对象，典 型标准元实体对象如组织机构、国家等内容。标准元实体对象完全独立， 有标准的编码体系（一般都有企业标准、国标或者国际标准），不会因为 在不同的系统不同有不同编码体系。标准元实体对象只有一个主键。 • 元实体对象：独立的实体对象，和标准元实体对象不同，一般没有一个唯 一的标识符，需要增加一个唯一标识符（比如单位编码，需要制定一个编 码 规则 编码规则下载淘宝规则下载天猫规则下载麻将竞赛规则pdf麻将竞赛规则pdf ，主要目的在于未来数据合并的时候不会因为多个系统合并而使得 数据重复），然后才能唯一标示对象。元实体对象是建模中最基本、最核 心的对象。如客户，订单、流程等，是业务逻辑、对外接口的核心实体对 象。标准元实体对象是有标准编码体系特殊的元实体对象。 • 根据元实体对象数量增长的快慢，可以把元实体对象分成基础元实体对象 和流水元实体对象，前者实体对象一般变化缓慢，如客户数据（比较重要 的基础元实体对象一般对应着的是主数据），后者变化快，如订单数据等。 • 关联实体对象：标准元实体对象、元实体对象之间的关联对象，有些仅仅 是简单的关联，有些关联对象中含有其他的业务信息。前者仅仅是对应关 系，后者包含对应关系的其他属性。如具体一个公司的商品价格信息，是 实体对象－商品和组织机构关联之后的信息。关联对象本身也是一个特殊 的实体对象。关联实体对象主键一般是两个或者两个以上，一般来说，应 该尽量减少关联对象的主键数量。 除了以上基本关系之外，还有一些特殊的实体对象关系，包含附属关联实体对象、 主从关联实体对象等 • 附属关联实体对象：实体对象的附属信息，和实体对象是一对一或者一对 多关系。一对一关系一般是为了把一个属性太多的对象分解成多个（在 IDA 中可以用继承来描述）；一对多关系采用增加序号的方式，增加多条 信息。如人员的学历、工作经历等。不同于关联对象，其只是简单的序号 的增加。订单可以以客户编码和流水号作为主键，但是这种有流水号主键 的一般是可以将几个主键合并为一个主键，如果能合并为一个主键，则合 并为一个主键，从而简化模型的层次。附属关系一般是为了解决简单一对 多的附属信息，如果附属对象需要复杂的业务逻辑，需要将多个主键合并 为一个主键。 • 主从关联实体对象：关联实体对象的一种特殊情况，关联的两个对象之间 有强烈的主从关系，如订单和订单项等。主从管理实体对象一般从对象内 容有限，在软件实现中一般以单据方式进行展示。 除了基本的关联关系之外，对象和对象之间还有外键关系，外键关系不象关联关 系那样是主键关系，外键关系是外键关联。如图 4 所示： 图 4. 对象外键关系图 在本模型中，比较一个关键的一点是要尽量多的建立元实体对象，特别是标准元 实体对象，尽量减少关联实体对象。比如订单，是元实体对象不是关联实体对象， 即客户和订单的关系不是主键关系而是外键关系。外键有多种，如一对一、一对 多关系等，详见 IDA 中的设置。一个简单的原则可以来判断，如果关联实体对 象除了关联的实体对象的主键之外还需要一个独立的主键，就应该考虑看作是一 个元实体对象（附属关联实体对象除外）。 对象基本关系模型构成了对象关系模型的主要框架，除此之外，还有一些其他的 关系模型，包括对象变更模型、对象汇总模型、类别对象关系模型、附加对象关 系模型、不定属性对象关系模型。对于设计者来说，需要关注的仅仅是基本关系 模型，其他模型的设计可以看作是固化了的设计范式，只需要设定范式即可。 对象变更关系模型 实体对象实例在业务活动过程中不断发生变化，根据业务的需要，需要记录实体 对象实例的变化信息（不同于流水元实体对象，是多个对象实例，比如订单，随 着业务的变化，订单不断增加）。包括对象属性变更、对象整体变更、对象快照 等。另外从业务上考虑，为了实现操作痕迹化，需要对操作过程进行记录。如图 5 所示 图 5. 对象变更关系图 • 实体对象属性变更，对属性变化的历史进行记录。根据记录的先后顺序可 以分成两种：采用申请单的方式，先记录变化的信息，然后更改实体对象； 监控对象变化，变化之后记录变化之后的属性。对于不重要的属性可以选 择不记录变更情况。 • 实体对象整体变更，对实体对象的变更情况整体记录，记录更改后的完整 信息，一般适合于流水元实体对象，用于记录流水对象的变化情况。 • 实体对象快照，为了便于记录历史信息，可以完整的还原当时的场景，记 录当时所有实体对象的信息，作为实体对象的快照进行管理。 • 实体对象操作痕迹化管理，对于一些关键业务数据，业务上需要保留操作 痕迹，比如订单数量修改和删除需要记录相应的信息。采用两种方式来解 决，一个是不允许删除实体对象，只做实体对象除删除标记，适用于整条 记录删除的情况；对于记录变更的情况，采用增加一个废弃实体对象，记 录实体对象的修改记录。 对象汇总关系模型 实体对象发生连续变化之后，需要对变化信息的汇总成为汇总对象，包含汇总和 计数，和实体对象的关系为对象汇总关系，包括按照年、月、日、周、季等汇总， 分别形成年、月、日、周、季的汇总表。根据汇总对象和原始对象之间的关系， 可以分成简单汇总关系和分组汇总关系，后者根据原始对象的外键关系进行分组 汇总。分组汇总关系又可以分成历史分组汇总和当前分组汇总。汇总对象属性可 能来源于多个原始实体对象，为了统一模式可以先分别汇总，然后再进行合并。 如图 6 所示： 图 6. 对象汇总关系图 • 简单汇总关系，直接基于原始对象按照时间进行汇总。 • 分组汇总关系，基于原始对象的外键关系进行分组汇总，比如客户渠道、 客户组织机构等，根据外键对象是否变化可以分成历史分组汇总和当前分 组汇总。前者按照原始实体对象历史上的状态进行汇总，当前分组汇总根 据当前的分类情况进行汇总，其数据是动态的，需要根据最新的分组汇总 情况进行重新汇总。 由于汇总对象是对应的实体对象的按照年、月、日的汇总，因此其主键为原实体 对象加年 ID、月 ID 或日 ID。是和日期对象的一种特殊的关联实体对象。 汇总对象更多的承担着报表查询的功能，为了提高查询性能，可以在汇总对象增 加额外的外键对应关系甚至把属性进行冗余存储。（汇总对象建模需要参考星形 建模，详见关于数据仓库建模） 类别对象关系模型 为了减少存储空间和便于统计，将主实体对象（包含元实体对象和关联实体对象） 的属性进行分类管理，以编码替代文字描述，成为类别对象，类别对象和主实体 对象的关系式外键关联关系。如图 7 所示： 图 7. 类别对象关系图 • 类别对象：实体对象的属性描述信息，和元对象的差别是，类别对象仅仅 是一个标识和描述，没有具体的业务属性信息，一般不作为主键。根据类 别对象是否独立可以将类别对象分成独立类别对象和依附类别对象，前者 跟其他的实体对象没有任何关系，后者需要根据关联的实体对象确定对应 关系。 • 合并的类别对象：对于简单的属性，可以汇总为一个对象，通过分类进行 管理，如图 8 所示。 图 8. 类别对象合并存储 由于是对象合并的，所以合并之后的对象需要增加一个主键，作为标识。需要注 意的是对象基本关系模型中涉及的标准元实体对象、元实体对象和关联实体对象， 除了前两者有一个独立的主键之外，关联实体对象，除了附属关联实体对象外一 般都是对应着一组关联对象的主键，关联对象一般没有自己的主键（附属关联对 象比较特殊） 附加对象关系模型 附加对象一般不是一个独立的对象，需要附加于其他对象，但是其具有本身的一 些特点，包含树、图、修改日志等附加对象。如图 9 所示： 图 9. 树附加对象关系图 树附加对象，根据实体对象是否可以有多个树，可以将树附加对象分成独立树对 象和内嵌树附加对象 • 独立树对象可以有多个树，即一个实体对象可以出现在不同的独立树对象 中。根据实体对象在一个独立树对象中是否可以重复，可以把独立树对象 分成唯一独立树对象和复合独立树对象两种。唯一独立树对象中的实体对 象在树中式唯一的，复合独立树对象的实体对象在树对象中式可以重复出 现的，如上图中的定制菜单，同一个菜单可以出现在不同的菜单目录中。 • 内嵌树只有一个树附加对象，树附加对象和实体对象是一一对应的，因此 一般来说，内嵌树附加对象和实体对象可以合并为为一个对象。 • 网附加对象是一种特殊的树附加对象，其特点是父对象不是一个，而是两 个。网对象根据树附加对象的划分相对应，也可以分成三种。 • 操作痕迹化记录：每个对象包含：创建时间、创建者、修改时间、修改者。 所有的表都可以附加上，作为表结构的一个部分。 • 对象标识符 ID，系统自动生成，作为对象的唯一标示，可以自动生成， 数据迁移之后，其数值会发生变化，不可以作为主键。 不定属性对象关系模型 由于有些对象的属性是不确定的，可以动态增加或者所有对象的属性很多，但是 具体到一个对象，其属性有只是很少的几个，属于不定属性对象，为了进行持久 化，将对象的属性按照行进行存放。如图 10 所示： 图 10. 不定属性对象关系图 不定属性实体对象属性多变，没有固定的属性，需要灵活处理每个对象的属性， 典型的如考核指标，不同的部门、不同的公司指标的差异非常大，因此需要按照 每个指标的类别，在行上进行存储。一般来说，指标本身是一种树，指标本身有 关联。 不定属性对象其特点和一般的实体对象一样，其特殊之处在于其属性是变化的， 对象实例化的时候，对象是存储是在行上存储的。 如果属性数量是明确的，但是不同类别实体对象具有的属性不同，可以通过继承 或者关联关系建立附属关联关系。比如商品信息，分别建立消费品商品信息、电 器商品信息等，用与分别记录其不同的信息。 如果属性相对来说是稳定的，但是存在变化的可能，则需要考虑实体对象属性动 态增加的模式。比如工资条，存在着工资条内容的增减，因此需要特殊考虑。 本模型以面向对象的分析为基本方法，首先找出业务对象（BO），然后基于范式 理论把业务对象转化成实体对象（PO），并进行分类分层管理，根据主键的特点， 设置实体对象的基本层级，最终建立实体对象分层模型。 回页首 实体对象关系模型应用 模型在数据结构设计中的应用 在《 SOA 和 DW 》中提到了关于共享库的概念，共享库是为所有厂商提供一个 标准数据来源的共享库，是企业级的数据库，由多个厂家共同建设和使用，包含 元数据、主数据、用户数据、业务数据等，因此需要共享库数据结构清晰明确， 并建立统一的建模标准，因此可以采用本模型进行数据库建设，建立企业级的清 晰、规范的数据库模型。《表 1 按照分层模型对数据库表进行分类》。 表 1. 按照分层模型对数据库表进行分类 模型 对象关系 备注 对象基本关系 模型 标准元实体对 象 标准元实体对象一般对应着主数据 元实体对象 业务系统的核心实体对象，包含基础元实体对象 和流水元实体对象两种 关联实体对象 基于元实体对象的关联关系 附属关联实体 对象 特殊的关联实体对象 主从关联实体 对象 特殊的关联实体对象 对象变更关系 实体对象属性 变更 仅记录某个属性变化信息 实体对象整体 变更 记录对象整体变化信息 实体对象快照 记录所有对象的当时信息 实体对象操作 痕迹化管理 记录操作者对实体对象的变更信息 对象汇总模型 简单汇总关系 包含日、月、年、周、季等，原始对象的简单汇 总 历史分组汇总 原始对象的分组汇总，记录当时历史状况，记录 是不可以修改的 当前分组汇总 按照当前分类情况，重新的汇总 类别对象关系 模型 全局类别对象 整个系统全部统一 附属类别对象 隶属于元实体对象的类别，不同的元实体对象类 别不同 合并的类别对 象 对于简单的分类编码，可以汇总为一个实体对象， 统一管理所有的分类实体对象 附加对象关系 模型 唯一独立树对 象 可以有多个树，树的节点实体对象不可以重复 复合独立树对 象 可以有多个树，树的节点实体对象可以重复 内嵌树附加对 象 实体对象和树附加对象一一对应 网对象 特殊的一种树附加对象，树节点的父节点可以有 多个 其他附加对象 属性 ID、操作痕迹化记录等 不定属性对象 关系模型 包含以上所有 对象关系 和前面对象的差异在于其属性由列存储变为行存 储 采用本模型，设计者需要关注的仅仅是对象基本关系，即元实体对象和关联实体 对象，如表 2 所描述，从而简化了数据结构，统一了数据库设计风格。 表 2. 描述对象关系的 表格 关于规范使用各类表格的通知入职表格免费下载关于主播时间做一个表格详细英语字母大小写表格下载简历表格模板下载 元实体对象（包含 是否标准实体对象 信息） 关联实体对象（关联的 元实体对象以及关联 类别） 外键关系（包含实 体对象、类别对 象） 其他（汇总、变更、 附属、不定属性等） XX 元实体对象 XXX 关联实体对象 XXX 实体对象 XXXXX 实体对象 YY 元实体对象 YY 关联实体对象 YYY 实体对象 YYYY 实体对象 对象基本关系模型确定之后，其他关系可以通过设定已有的模型自动生成，只需 要在设计的时候设定其他模型类别即可，比如根据实体对象的变更记录设置，自 动生成变更表；根据设定的对象汇总关系可以自动生成汇总表；根据类别对象关 系，自动对应类别对象；根据设定的附加对象自动生成树等结构；根据不定属性 对象关系自动生成不定属性表等。相关信息可以参考元对象设施（Meta-Object Facility，MOF）的概念，即可以实现 MOF 的 M1 层模式化设计，本文不再详细 探讨。 模型在模型驱动架构（MDA）中的应用 实体对象按照分层模型建立之后，在 IDA 中设置词汇表（Glossary），IDA 可 以自动生成各种主流数据库的数据结构，同时分层模型建立了实体对象之间的关 系，根据实体对象分层模型，进一步完善业务对象（BO）模型，可以设置更多的 自动生成代码模板，提高代码生成效率。比如： • 主从表关系，可以自动生成所有单据类的代码。 • 关联实体对象，自动生成对象关联的维护；根据外键关系可以自动生成： 简单列表方式选择；外键的外键，简单树型显示；外键 + 外键，笛卡尔 积的树显示。 • 类别对象关系，特殊的外键关系，可以自动生成弹出或者下拉窗口，在数 据查询的时候可以自动根据代码转换成文字描述； • 对象汇总关系，自动生成汇总程序，需要标记属性的类别，比如汇总还是 计数。 • 对象变更关系，自动生成变更程序以及变更跟踪等。 • 附加对象关系，比如根据树的类别，自动生成树的维护程序。 • 不定属性关系，可以自动实现行列转换等的计算等。 基本的数据操作层面的代码可以全部自动生成，如简单的增删改查、以自动完成 删除订单，然后自动删除订单项等关联关系。关于更多的 MDA 的实现，将在本 文的续篇进一步探讨。 回页首 总结 本文以面向对象设计方法和三范式为基础，提出了分层的实体对象模型，建立了 一个标准化的数据库关系模型。遵循这个标准，可以建立更加清晰易懂的数据结 构，为建立企业级的共享库打下基础，同时本模型能为更有效的自动生成代码提 供基础。 本模型的适用范围和不足： • 本模型仅限应用在数据库管理软件中，是面向数据库操作的实体对象建模 模型。 • 本模型仅限解决实体对象之间的关系，如果要实现完整的代码自动生成， 还需要界面层的设计模型，复杂业务逻辑和业务规则则需要面向对象的相 关方法支持。 • 本模型无法解决复杂数据处理逻辑的和数据查询方面的课题。 基于面向对象（OO）的数据库设计模式 探讨，第 2 部分一种基于指标矩阵的数 据建模的方法 现在大型的管理系统有几千甚至上万张表，但几乎没有谁能搞清楚所有的数据结构，如 何建立清晰明了的数据结构？如何让其他人对数据结构更加容易理解，本文以 “基于面 向对象（OO）的数据库设计模式探讨”为基础进一步对汇总表进行分析，通过建立指标 矩阵模型，“模式”化数据库建模，建立清晰可读的汇总数据模型。 免费下载：IBM® InfoSphere Data Architect V7.5.2 试用版 下载更多的 IBM 软件试用版，并加入 IBM 软件下载与技术交流群组，参与在线交流。 前言 软件开发中面临的问题 在软件开发过程中，几乎没有几个程序员喜欢报表开发，报表多、杂，需求多变，特别 是给人感觉没有什么技术含量，大家对报表都是退避三舍。如果采用 BI 工具开发，又 会因为 BI 工具五花八门，不同项目 BI 工具不同，需要开发不同的程序，增加了项目 开发成本，除非是固定一种报表工具，但是不同的客户需求不同，不得已需要不停的变 化展现工具；不用 BI 工具，自己开发应用，如果采用多维数据库，则需要程序员熟悉 多维数据库的 SQL 语法，增加了开发的难度；基于关系型数据，采用通用的查询工具 又往往面临着查询性能问题，报表的开发似乎成了一个死结。重复劳动、产品通用性差、 查询性能差等问题是当前所面临的一个重要的课题，特别是对于大型的管理系统，多变 的查询需求和海量数据处理，往往成为项目迟迟不能验收的一个最重要因素。 本文参照数据仓库建模的思路，解决查询性能问题，采用关系型数据结构，使用和业务 系统通用的 Java 开发，给出了一个建立简单清晰的数据模型的方法。 数据仓库的建模思路 在数据仓库建模中经常会采用空间换性能的方法，需要汇总的数据不是临时汇总而是提 前汇总好，比如销量指标，其年累计、同期、上期、 计划 项目进度计划表范例计划下载计划下载计划下载课程教学计划下载 、实际、增长比例等提前汇总 计算好，提高查询速度，在此简单介绍几个基本的数据仓库概念： 星型模式：（也称为星形连接的模式，数据立方体，或多维模式 ）是最简单的样式数据 仓库架构 。星型模式由一个或多个事实表中引用任何数量的维表 维表：维度表可以看作是用户来分析数据的窗口，维度表中包含事实数据表中事实记录 的特性，有些特性提供描述性信息，有些特性指定如何汇总事实数据表数据，以便为分 析者提供有用的信息，维度表包含帮助汇总数据的特性的层次结构。 事实表：事实数据表可能包含业务销售数据，如销售所产生的数据，事实数据表通常包 含大量的行。事实数据表的主要特点是包含数字数据（事实），并且这些数字信息可以 汇总，以提供有关单位作为历史的数据，每个事实数据表包含一个由多个部分组成的索 引，该索引包含作为外键的相关性维度表的主键，而维度表包含事实记录的特性，在本 文中称为汇总表。 本文采用的示例数据模型 为了更好的理解本项目的思路，以下以客户关系管理数据模型为例，按照对象关系模型 建模，主要的业务对象包含供应商、商品；客户、客户经理、客户业态；销售订单、采 购订单等基本业务对象，主要的汇总表包含客户商品日帐（即客户每天每个商品的销售 汇总）等，如下图所示： 图 1. 数据对象模型示例（查看大图） 另外在本文中提到几个指标：销量，是在一段时间内客户购买的数量；上柜率，是指一 个月内购买某一个商品的客户数占所有有效客户数的比率。即上柜率 = 本月购买本商 品的客户数 / 有效客户总数。 回页首 指标矩阵模型 根据当前所面临的问题，参考数据仓库建模理念，从以分析指标入手，建立指标模型， 然后根据汇总维度建立维度矩阵模型，最终结合指标模型和纬度矩阵模型建立指标矩阵 模型。 指标模型 在考虑建立那些汇总表之前，首先确定那些指标是原始指标，即已经存在的指标，不再 需要进行逐级汇总，可以直接使用的指标，这些指标属于原始指标，可以直接作为汇总 表的原始数据。然后把不能汇总的指标尽量分解为可以汇总或者可以计数的指标，以便 于进行数据汇总和查询（这一点对于简化模型很重要，可以把大部分指标分解为可以进 行汇总计算的指标）。整理好所有的指标之后，通过指标进行分类，建立元指标和扩展 指标，最终建立指标树模型： 1. 原始指标，从其他系统获取或者采集的原始数据，为原始指标，原始指标是其他指标 汇总指标的基础。 有些指标是不可以汇总，但是也无法分解，因为每个级别之间不是汇总关系，一般是单 独设置的。比如计划，并不是逐级汇总上去的。因此每一级的指标都是原始指标。有些 指标是从外部引入的，因此并不一定从最基础的地方开始汇总，比如系统外的数据， GPD、人口指标，可能直接从一个某一个级别开始统计，更细节的数据没有或者没有必 要。因此原始指标并不一定就是从最细粒度开始汇总的。 以上两种情况，需要把指标设置为原始指标，即从从其他系统获取或者采集的指标。 2. 计算指标，将不可以汇总、计数的指标分解到可以汇总的指标，比如上柜率，可以分 解为客户总数和购买本商品的客户数，在最细粒度数据客户方面可以分解为是否上柜 （可以计数），比如毛利率可以分解为毛利和金额。这一点很重要，只有进行类分解之 后，后续的汇总和查询才可以大大简化。被分解的指标称之为计算指标。 3. 元指标：首先根据业务报表需要，对所有的指标进行分类，找出元指标，元指标是不 含有任何维度信息的，比如销量、金额、毛利、上柜率等。一个企业可能有上百个指标， 为了便于管理，可以对指标进行分类管理，如销售类、财务类、人力资源类等。 4. 扩展指标，元指标是基本的指标，但实际应用中，根据指标在不同的时间维度、或者 某种算法，可以“模式化”很多扩展的指标，如： a) 年累计、年实际··· b) 月实际、同期、上期、同期增长、环比增长、月累计··· 扩展指标是某元指标的一个“模式化”扩展，适用于所有相关的指标。比如销量，可以有 年累计销量、年计划销量、年实际销量、月实际销量、同期销量、上期销量、销量同期 增长、销量环比增长、月累计销量等。这种模式化，通过分析会发现基本上可以适应到 大部分指标（如金额、毛利），通过扩展指标，可以建立一个矩阵，大大简化指标体系 的复杂度。 表 1. 基于时间维度的汇总表 序号 指标 年累计 同期 同比 上期 环比 ··· 1 销量 有 有 有 有 有 2 金额 有 有 有 有 有 3 毛利 有 有 有 有 有 4 毛利率 无 有 有 有 有 ··· 维度矩阵模型 5. 基础维度表，基于对象关系模型（详见 “基于面向对象（OO）的数据库设计模式探 讨”），建立基础维度，以及基于基础维度的原始事实表。基础维度包含日期（日）、数 据拥有者（所有者，客户、人员、部门）、商品等（如图 1 所示）。其中日期维度是必 须的，因为汇总表都是基于日期维度进行汇总的，没有日期的表是基础维度表。所有者 也是是必须的，因为每个数据一定是某一个所有者所拥有。除此之外的维度是可选的， 比如商品，可以有不含商品维度的客户月汇总表，包含商品维度的客户商品月汇总表两 个。 根据星型模式建模理论，基础维度应该可以获取所有相关信息，不需要在关联其他的维 度，如客户维度表，里面应该有客户经理、销售部门、客户类别等所有相关的信息，便 于提高查询效率。 注意，要把日期看成一种普通的维度，如月份，实际上也是一种“分类”，如 201001， 代表 2010年 1月，但是还可以直接用 01代表一月，这样后期报表处理就会简化。 6. 原始事实表，对应着对象关系模型中的流水实体对象，流水实体对象按照时间进行汇 总之后的为事实表，如：客户商品日表；供应商商品日表，仓库商品日表、考虑到行政 区划信息比较稳定，如 GDP 等，直接按照年表建立，即行政区划年表，作为最原始事 实表，当然根据需要，也可以建月表。 理论上，所有的原始事实表建立之后，所有的汇总数据都可以直接查询出来了，但是考 到性能问题，通过空间换时间的方式，按照维度的不同方向进行汇总。 7. 维度矩阵模型，基于原始事实表，根据基础维度，在基础维度的不同汇总方向上建立 维度汇总关系模型，如客户商品日表的汇总模型可以在不同维度方向上进行汇总， 首先是在日期维度 a) 日 - 月 - 年 b) 日 - 月 - 季度 - 年 c) 日 - 周 - 年 如下图所示，可以分别建立不同的汇总表，其中常见的是日、月、年等。 图 2. 基于时间维度的汇总表（查看大图） 在客户维度： d) 客户 - 客户经理 - 部门经理 - 公司 e) 客户 - 客户业态 如下图所示，通常按照组织机构建立汇总表。 图 3. 基于时间、客户维度的汇总表（查看大图） 在产品维度 f) 商品 - 品牌 - 供应商 - 省份 g) 商品 - 品类 h) 商品 - 大类 图 4. 基于时间、客户、商品维度的汇总表（查看大图） 维度矩阵模型，实际上是维表在不同的可以汇总的方向上的笛卡尔乘积，其中有些是不 需要的，如上图所示，根据这个模型，可以列出所有需要的汇总表。 维表的建设，可以参考当前比较成熟的建模方法，比如经常见到的数据高阶建模，一般 分为参与者、地点、产品、交易等，本文不再详述。 指标矩阵模型 8. 指标矩阵模型，分析每一个元指标及扩展指标在维度矩阵模型中是否存在，并根据指 标进一步完善维度矩阵模型。有些指标并不是在所有的汇总表中存在的，比如上柜率是 月度指标，所以在所有的年表、日表中是不存在的；比如日表中不需要同期、上期，但 是年累计、月累计等指标可能是需要的。 同维度矩阵模型一样，指标矩阵模型是在维度矩阵基础上的笛卡尔积的笛卡尔积矩阵， 数据是很庞大的（这也是为什么建立这个模型的原因，通过这个模型，可以建立更加容 易理解的数据模型），但是并不是每一个指标在不同的矩阵中都是存在的，需要根据这 个模型来分析哪些指标是存在的，哪些指标是不存在的。 在最终确定的模型中，有些数据表可能因为数据量很小，不存在性能问题，但是考虑到 统一风格，统一处理方便性，全部按照一个思路，即一个“模式”，这样程序开发就会简 单。 9. 对于指标灵活多变的，建立基于指标的汇总表，将每个指标的值存放在列上，指标可 以灵活增加。详见对象关系模型中不定属性对象的描述。 通过以上方式，即可建立一个汇总表模型，但是在实际建模过程中会出现一些特殊情况， 如过于个性化的指标，不好计算，则作为原始指标来看待，单独进行汇总处理。有些指 标因为维度值的变化不同，比如客户经理因为人员的更换以及客户所属客户经理更换， 同期销量，实际上可以有两个值，一个是所管理的当前客户的同期，一个是本人同期管 理的客户的实际值，因此需要根据需要，看看取哪一个指标。 根据“模式化”的思路，可以进一步把指标矩阵模型进一步进行扩展，有汇总数据，一般 会对应着有一个计划数据，结合以上思路，可以进一步建立一个计划、汇总模型的“模 式化”框架，本文不再详述。 回页首 模型在实际环境中的应用 为了更好的让指标矩阵模型发挥作用，以下分别从存储设计、性能角度及实际开发过程 中的应用功能来看本模型的应用。 模型表结构设计 根据查询频次，在不同的维度方向上确定是否需要建立汇总表进行物理存储，对于不经 常用的数据，可以采用实时汇总的方式，实时汇总基于最近的维度汇总表进行汇总的方 式，比如查询客户商品季度汇总，可以直接客户商品月汇总表中汇总数据；查询公司客 户业态月汇总数据直接从公司客户商品月汇总表中获取数据。 在数据查询的时候建议通过视图获取数据，一方面可以解决计算指标的问题，通过视图， 把计算指标直接封装，二是可以通过视图实现部分物理存储，如客户业态商品汇总表， 可以通过视图的方式进行汇总，而实际上并没有进行物理存储，适应于不是很常用的一 些汇总、数据量比较少的汇总表，这些汇总可以通过设置查询一次存在缓存中的方式， 进一步优化。 如果字段比较多，可以按照业务主题，分成多个表，在查询的时候通过多个表分别获取 数据。按照以上模型建立的汇总表，同样级别的数据可能会存放在不同的表中，比如客 户的销量信息和客户的上柜率可能是存放在不同的表中，如果在一个报表中同时查询这 两个信息，就需要同时查询两个表，可能会存在性能问题，解决这个的办法是在查询的 时候需要考虑如何优化查询性能，比如在考虑从多个汇总表表获取数据，然后合并为一 个，可以先建立几个临时表，分别把需要的数据从各个地方获取存放在临时表中，然后 在从临时表中获取数据，同时写入到一个表中，而不是先写一列，然后在修改，这样性 能会比较差。 是否建立汇总表，可以通过在这个维度上是否有大量的减少， 比如客户经理对客户来 说，一下子就减少了 200 倍的数据，所以汇总时值得的。如果是 10 倍，可以不汇总， 这需要根据实际数据来分析。10000 万的数据和 1000 万，性能还是会差别很大的。 模型查询性能优化 通过前文所提到的表结构方面的优化，从查询性能角度来看，本模型主要从几个层面， 采用空间换时间的思路，进行了优化： 基于星型模式的优化：建立简单星型模式，设置了维表，通过维表的冗余存放，减少的 维表之间的关联，取消了雪花模型带来的性能问题。 基于指标的优化：建立指标扩展模型，同时查询的数据存放在表的一行中，可以一次获 取，减少查询的次数，如同时获取同期、上期数据，避免数据的多次查询。 基于索引的优化：直接在事实表中建立外键，分类汇总不需要关联更多的维表中，可以 直接进行查询。同时直接在事实表中建立外键之后，可以保留历史痕迹，完整的反应当 时的数据情况，如客户的客户业态更换之后，还可以按照客户当时所属的客户客户业态 进行统计。 基于汇总表的优化：根据维表的不同汇总方向，建立多级汇总表，汇总的数据直接在汇 总表中查询，实现数据的优化。 灵活查询系统建设过程 基于汇总表体系，建立灵活查询系统，是本模型的目标之一，按照组件化的方式，可以 将灵活查询系统分成查询组件、数据获取组件、数据展示组件、数据汇总组件、元数据 组件。数据库层面还需要完善的内容包含数据权限、元数据两个部分，数据权限用与限 定使用者看到的数据范围，元数据用与描述本模型，如下图所示： 图 5. 灵活查询系统组件模型 灵活查询系统建立之后，可以实现自动的数据汇总，自定义查询条件和查询显示结果， 如果完全实现灵活查询系统，需要一个漫长的过程，而且很可能因为工期太长，系统过 于复杂，最终导致系统开发会失败，可以分步建设，逐步实现： 首先建立基于指标矩阵模型的数据库，基于本数据库进行查询，具体的查询可以采用原 来的查询方式和报表展示，数据汇总可以通过直接写程序或者手工汇总。 建立元数据管理，对数据模型进行管理，基于元数据管理建立独立查询模块，实现定义 各种查询条件，输出结果为一个标准化之后的查询的 XML，然后根据查询 XML 生成 查询结果。查询模块可以进一步完善，如保存查询条件等。 建立数据获取模块，数据获取模输入条件为标准化之后的查询的 XML，输出也是标准 化的 XML，进一步将数据获取模块进行分离，只要输入一个查询的 XML，就可以获取 一个查询结果，并以 XML 方式输出。 建立数据展示模块，根据 XML 格式自动展示，最终实现自定义数据展示。 建立数据汇总模块，基于元数据，实现自动汇总。 通过以上分析可以看到，虽然整个灵活查询系统体系非常复杂，但是可以分解为不同的 组件，分步建设，逐步实现。当然，也可以直接采用成熟的商品软件，特别对于大型的 项目，可以直接部分或者全部采用商品软件，如 IBM 产品体系，可以采用：数据汇总， 采用 ETL 工具，如 Datastage，数据展示采用 Cognos 等，进一步简化系统的开发， 如下图所示。 图 6. 基于 IBM 系统软件的灵活查询系统 以上根据前文提到的指标矩阵模型，就模型表结构设计、性能优化及灵活查询系统建设 做了一个简单说明。 回页首 总结 通过本文的介绍，描述了一个基于指标矩阵模型建立汇总表的方法，主要的目的是“模 式化”汇总表的建设，建立清晰明了的数据模型，本模型的主要适用场景为 “面向服务体 系架构（SOA）和数据仓库（DW）的思考” 中共享库的建设以及为基于关系型数据库， 采用 Java 开发的报表查询系统建立一个模式化的清晰可读的数据模型提供一个方法。 基于面向对象（OO）的数据库设计模式探讨 基于面向对象（OO）的数据库设计模式探讨，第 2 部分一种基于指标矩阵的数据建模的方法 前言 软件开发中面临的问题 数据仓库的建模思路 本文采用的示例数据模型 图 1. 数据对象模型示例（查看大图） 指标矩阵模型 指标模型 表 1. 基于时间维度的汇总表 维度矩阵模型 图 2. 基于时间维度的汇总表（查看大图） 图 3. 基于时间、客户维度的汇总表（查看大图） 图 4. 基于时间、客户、商品维度的汇总表（查看大图） 指标矩阵模型 模型在实际环境中的应用 模型表结构设计 模型查询性能优化 灵活查询系统建设过程 图 5. 灵活查询系统组件模型 图 6. 基于 IBM 系统软件的灵活查询系统 总结