企业级数据模型全域一致性的一种解决方案

一、建设企业级数据模型必须解决全域一致性问题

经过多年的信息化建设, 客户已经建成覆盖企业全业务链的应用系统, 但是系统繁多, 互相孤立;这些应用系统可以分为两个域:处理域和分析域, 处理域即传统的业务处理类应用系统和管理类应用系统, 分析域即各种辅助决策和数据挖掘分析类应用, 如图1。

处理域的应用系统在不同历史时期由不同团队开发, 业务领域也千差万别, 形成了数十套互相独立的应用级数据模型, 这些模型本身是分立的, 烟囱式的, 存在明显的模型孤岛和数据孤岛现象。分析域的数据层分为贴源层、明细层、轻度汇总层, 将来会有数据集市层, 贴源层模型和数据基本保持和处理域各个源系统一致, 因而和处理域一一样是分立的, 充满不一致, 不但存在模型孤岛, 也存在数据孤岛;明细层是企业级逻辑模型的具体实现, 试图在贴源层之上实现一个全域一致的数据模型, 消除模型孤岛和数据孤岛, 为轻度汇总层和分析域各项应用提供协调一致的数据环境。

企业级数据模型则试图在这些模型之上实现数据模型的全域一致, 形成规范统一的语义环境, 做到实体唯一、属性统一、编码和取值统一, 消除模型孤岛, 从数据模型层面为消除数据孤岛、实现处理域各系统之间的信息共享提供保障;同时为分析域的企业级数据仓库建设和处理域的各项系统的建设打下基础。而构建企业级数据模型时需要解决的首要问题是全域一致性问题, 大致可分为四个层次的问题:实体的全域一致性、属性的全域一致性、编码取值的全域一致性、数据的全域一致性。具体如下:

(一) 实体的全域一致性

见表1。

(二) 属性的全域一致性

见表2。

在自上而下的设计方法中, 概念模型是从业务空间中抽象出来的, 经过归纳和分类阶段, 抽象成一个体系化的模型, 自然就保障了一致性, 由概念模型演化出的逻辑模型自然也会具备一致性, 进而物理模型也会继承这一基因。但是实际上客户的企业级数据模型采用自底向上的方法, 从应用层模型反求企业级逻辑模型, 再从企业级逻辑模型反求企业级概念模型。而已经存在的诸多应用层模型是在不同时期由不同团队单独建立, 各不相同, 互相独立, 抽象程度不一, 分类标准不统一, 且没有站在企业级视角抽象和定义, 故应用层各模型之间语义关系混乱, 造成互相重叠交叉, 充满重复冲突的定义, 这一基因也就带入企业级的逻辑模型和概念模型。

二、利用面向对象的方法解决实体一致性问题

采用自下而上的方法从应用层模型反求企业级数据模型时不一致性的具体表现如下:

1.同一语义的实体在不同的应用级模型中多次定义。

2.同一语义的实体采用不同的名称重复定义。

3.不同语义的实体采用相同的名字。

4.相似语义的实体多次重复定义, 概念内涵互相重叠、交叉, 边界不清晰。

5.属性值域的编码、取值没有站在企业级角度考虑, 不能满足企业级数据模型的需要。

要做到实体的全域一致性, 就需要识别这些冲突的实体, 重新定义和去重。重新定义就是调整相互交叉或者定义不明确的实体的语义;去重即识别实体的重复定义情况, 合并重复定义的实体。

假如需要处理的实体仅有数十个, 人工识别即很容易完成, 而客户的企业级数据模型包含十个域, 上万个实体, 对如此数量级的实体进行逐个两两比较, 从中识别处重复、冲突、重叠交叉的实体, 巨量的实体数量是实现实体一致性的主要困难, 数量之大使的该项工作已接近不可行, 且无规则的选取实体两两比较并不能确保识别出全部的不一致。

在实际工作中, 我们使用面向对象的方法巧妙地解决了这个问题, 见下面详述。

这种方法的核心是抽象, 抽象的本质是基于语义的分类和归纳, 识别实体之间的泛化关系, 建立继承树的过程就是反复分类和聚合的过程:向上归纳, 向下分类, 分类的原则是MCSE原则, 即“统一标准、无重复、无遗漏”。待全部实体归纳为有限几棵继承树后, 再在树的根节点构成的集合内进行语义比较和调整, 取得一致性, 以上过程在各个树中递归进行, 就达到了全域的一致性。这个方法是一种收敛的算法, 只要按照规定步骤递归进行下去, 必定会达到一致性的状态。

以上分析表明面向对象分析的方法能够帮助我们在全域范围内识别重复定义、交叉定义, 从而取得实体的全域一致, 实际工作中我们通过建立和识别实体之间的泛化关系, 不断抽象、归纳、分类, 形成由多棵语义继承树组成的森林, 把呈无序状态的实体集合组织成森林, 由于泛化关系是按照语义组织的, 因此只在同一父类兄弟节点之间才有可能存在重复和交叉, 树可以由多个层次的节点构成, 每个类的子类不会太多, 一般在数十个以下, 大大缩小了参与比较的实体数量, 把上万实体中的两两比较, 缩小为有限兄弟节点之间的比较, 呈几何级数地减少了工作量, 使得实体去重工作具备可行性。

需要说明的是因为去重和调整定义会影响泛化关系, 故需要进行多次迭代, 经过多次迭代调整, 每次比上次更加收敛, 更加接近正确答案。实际工作中这样经过3次迭代后, 即得到相对理想的一致性效果, 达到实体全域一致性的设计目标。

该方法的具体过程如下:

(1) 构造实体集合

合并应用层物理模型, 去掉汇总型表、记录型表、辅助表、日志表、临时表、控制表等不应在企业数据模型中出现的表, 从面向对象角度看, 此时每个表都可以看做一个类 (class) , 他们是相互孤立的实体, 有些实体定义模糊不清, 有些实体之间互相重叠、甚至重复。这些实体之间是平等的, 散列的。

(2) 分域识别实体之间的泛化关系, 建立继承树

识别实体之间的泛化关系, 对实体进行归纳、分类, 此时可以不处理语义的重复、交叉情况, 但是要做两件事情:第一对于定义不规范的实体要规范定义;第二为了便于表达实体之间语义上的泛化关系, 可以定义一些抽象的类, 如收款凭证、付款凭证都是凭证的泛化, 此时可能需要建立一个抽象的凭证实体。由于此时模型由上万个实体构成 (还没有排重等) , 为了提高效率可以把整个设计团队分为多个小组, 每组负责一个域并行进行, 团队分头遍历自己域内所有实体, 识别和构建泛化关系, 经过上述步骤处理后各域在内部形成了一座按照语义继承关系组织的森林, 但是此时兄弟节点之间还有可能存在重复定义或者语义交叉的情况。

(3) 合并各森林为一座森林

合并各域的森林, 形成一个大的、完整的森林。合并首先在树的根节点这一层展开, 此时需要要做两方面的事情:对于重复定义的实体做合并处理, 合并这重复实体的树为一棵树;对于语义有交叉的实体进行重新定义、分割、归并, 或者新建类, 或者拆分后合并入其余几棵树中, 目标是保证不同森林中树根节点节点之间的语义相互独立、不重复、不交叉, 经过这一步后整座森林的根部达到了“相互独立、不重复、不交叉”的状态。如图:

具体工作方法如下:

从语义分析入手, 逐个对照树的根节点, 分析其语义:

(1) 同一语义的实体发生多次定义 (有可能同名也有可能不同名)

1) 统一命名

2) 合并这几个实体为一个实体

3) 合并以这几个实体为根的树

(2) 不同语义的实体采用相同的名字

重新命名实体, 从命名上区分开

(3) 相似语义的实体多次重复定义, 概念内涵互相重叠、交叉, 边界不清晰

拆分实体, 分别命名或者合并到已经存在的实体上, 注意该树的子节点也要一起进行合并。

(4) 递归上一步的合并过程

在各棵树内部递归进行上述过程, 待递归处理完成后, 即达到了全域范围内的“相互独立、不重复、不交叉”状态。为了加快处理速度, 上述递归处理过程可以由多个独立小组并行进行。

三、后记

企业级数据模型必须在实体层面、属性层面、编码取值层面具有一致性, 否则根据该模型构造的数据质量必然低下, 一方面基于该模型开发分析类应用需要进行大量的清洗转换, 增大开发难度, 数据挖掘、大数据分析等高级形式的应用会愈加困难, 甚至于某些场景的应用成为不可能。

另一方面企业级数据模型无法指导制定数据共享的标准, 数据交换停留在低效、复杂、割裂的数据交换层次, 无法由数据交换提升为信息交换一致性不仅仅是企业级数据模型必须具备的基本特征, 也是构建企业级数据模型过程中面临的主要困难, 利用面向对象的思想方法可以有效解决实体、属性、编码取值等层面的一致性问题, 本文针对这种方法展开深入讨论。

摘要：最近刚刚完成某大型央企企业级数据模型的建设, 该项目的目标是建立企业级概念模型、企业级逻辑模型、企业级数据仓库明细层物理模型。一般企业级数据模型设计有两个工作思路:自上而下和自下而上, 前者从业务需求分析开始逐步完成概念模型、逻辑模型和数据仓库物理模型的设计, 然后进行数据的溯源、认责, 与现有应用系统的模型相衔接, 引导现有数据灌入数据仓库;后者则从现有应用级模型开始, 逐渐整合, 形成物理模型, 再剥离与具体数据库实现有关的元素, 整合出企业级逻辑模型、进一步抽象出企业级概念模型。自上而下做法的好处是得到的模型很容易保障全域协调一致, 不存在重复定义、相互冲突的现象, 但是这种做法的缺点也很明显:当企业很大、业务非常复杂时, 要对企业的全部业务进行需求分析工作量巨大, 有时几乎不可行;现实中现有的应用系统在建设时已经对局部的应用进行了需求分析和模型设计, 自上而下的做法无法复用现有成果;重新进行需求分析和设计难免使得企业级数据模型和已经存在的应用系统的模型之间会有巨大的差异, 导致企业级数据模型失去指导意义;一般都会依据企业级数据模型构建数据仓库, 但由于企业级数据仓库是从头开始设计, 使得已经存在的应用级模型和企业级数据模型之间的差异巨大, 现有数据在灌入依据企业级数据模型设计的数据仓库时面临困难。自下而上的做法则复用了现有应用系统的设计, 省去了对企业全部业务进行需求分析的巨大工作量 (事实上对于像客户这种超大型央企来说是唯一可行的方法) , 但这种方法也有一些明显的缺陷:由于应用级模型是在不同历史时期、由不同团队建设, 这些模型之间普遍存在重复定义、相互冲突等情况, 存在严重的不一致, 对于一个大型企业的企业级数据模型, 解决这些问题也需要付出巨大的努力。采用自下而上的建模方法时不一致性不要存在于四个方面:实体层面、属性层面、编码取值层面、数据层面。本文提出前实体层面不一致性的解决方案, 其余方面的解决方案另文描述。

关键词：企业级数据模型,面向对象,实体全域一致性

注释

1[1]严格的设计能够确保属性名称和语义一一对应, 即同名的属性其定义相同, 不同名的属性定义不同, 但是本文中企业级数据模型是从应用层模型反求而来的, 属性的命名有一定的历史原因与业务语境, 有的约定俗称, 如果强行规范反倒有些违背客观现实, 造成混乱, 故在此进行了妥协, 这种妥协并不影响企业级模型的权威性、可用性。

2[2]同上。

3[3]区分属性的关键元素是语义而不是名称 (见注1) , 语义相同的就是同一个属性, 语义不同的就是不同的属性, 相同语义的属性其domain相同, 是企业级数据模型中属性一致性的核心思想。