谈谈大型集团如何构建全域一致性数据模型

简介: 数据建模包括概念模型、逻辑模型、物理模型。企业级数据模型设计通常有两种方法:自上而下和自下而上。

序言

   数据建模包括概念模型、逻辑模型、物理模型。企业级数据模型设计通常有两种方法:自上而下和自下而上。

   自上而下的方法是从业务需求分析开始逐步完成概念模型、逻辑模型和数据仓库物理模型的设计,然后进行数据的溯源、认责,与现有应用系统的模型匹配衔接,指导将现有数据采集到数据仓库。自上而下做法的好处是得到的模型很容易保障企业数据模型的全域一致,不存在重复定义、相互冲突的现象,但是这种做法的缺点是:当企业很大、业务非常复杂时,要对企业的全部业务进行需求分析工作量巨大,有时几乎不可行;现实中现有的应用系统在建设时已经对局部的应用进行了需求分析和模型设计,自上而下的做法无法复用现有成果;重新进行需求分析和设计难免使得企业级数据模型和已经存在的应用系统的模型之间会有巨大的差异,导致企业级数据模型失去指导意义;一般都会依据企业级数据模型

构建数据仓库,但由于企业级数据仓库是从头开始设计,使得已经存在的应用级模型和企业级数据模型之间的差异巨大,现有数据在灌入依据企业级数据模型设计的数据仓库时面临困难。

   自下而上的方法则是从现有应用级模型开始,逐渐整合,形成物理模型,再剥离与具体数据库实现有关的元素,整合出企业级逻辑模型、进一步抽象出企业级概念模型。自下而上的做法则复用了现有应用系统的设计,省去了对企业全部业务进行需求分析的巨大工作量,但这种方法也有一些明显的缺陷:由于应用级模型是在不同历史时期、由不同团队建设,这些模型之间普遍存在重复定义、相互冲突等情况,存在严重的不一致,对于一个大型企业的企业级数据模型,解决这些问题也需要付出巨大的努力。采用自下而上的建模方法时不一致性主要存在四个方面:实体层面、属性层面、编码取值层面、数据层面。

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

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

f81205504a200810c0a5ba6127408552.png

   处理域的应用系统在不同历史时期不同业务需求驱动又由不同厂商实施,形成了业务领域千差万别,众多互相独立的应用级数据模型,这些模型是相互隔离的,筒仓式的,存在明显的模型孤岛和数据孤岛现象。分析域的数据层分为贴源层、明细层、轻度汇总层和数据集市层,贴源层模型和数据基本保持和处理域各个源系统一致,因而和处理域一一样是分立的,充满不一致,不但存在模型孤岛,也存在数据孤岛;明细层是企业级逻辑模型的具体实现,试图在贴源层之上实现一个全域一致的数据模型,消除模型孤岛和数据孤岛,为轻度汇总层和分析域各项应用提供协调一致的数据环境。企业级数据模型则试图在这些模型之上实现数据模型的全域一致,形成规范统一的语义环境,做到实体唯一、属性统一、编码和取值统一,消除模型孤岛,从数据模型层面为消除数据孤岛、实现处理域各系统之间的信息共享提供保障同时为分析域的企业级数据仓库建设和处理域的各项系统的建设打下基础。而构建企业级数据模型时需要解决的首要问题是全域一致性问题,大致可分为四个层次的问题:实体的全域一致性、属性的全域一致性、编码取值的全域一致性、数据的全域一致性。具体如下:

   1、实体的全域一致性

eb80c25d73a908a6a246a25a1673324e.png

  2、属性的全域一致性

95efe3f026c2fafe1a171c4bcc825aa5.png

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

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

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

  • 同一语义的实体在不同的应用级模型中多次定义。
  • 同一语义的实体采用不同的名称重复定义。
  • 不同语义的实体采用相同的名字。
  • 相似语义的实体多次重复定义,概念内涵互相重叠、交叉,边界不清晰。
  • 属性值域的编码、取值没有站在企业级角度考虑,不能满足企业级数据模型的需要。

   要做到实体的全域一致性,就需要识别这些冲突的实体,重新定义和去重。重新定义就是调整相互交叉或者定义不明确的实体的语义;去重即识别实体的重复定义情况,合并重复定义的实体。假如需要处理的实体仅有数十个,人工识别即很容易完成,而通常情况下是企业级数据模型包含十个域,上万个实体,对如此数量级的实体进行逐个两两比较,从中识别重复、冲突、重叠交叉的实体,巨量的实体数量是实现实体一致性的主要困难,数量之大使得该项工作已接近不可行,且无规则的选取实体两两比较并不能确保识别出全部的不一致。

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

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

   去重和调整定义会影响泛化关系,故需要进行多次迭代,经过多次迭代调整,每次比上次更加收敛,更加接近正确模型集。实际工作中这样经过3次迭代后,即得到相对理想的一致性效果,达到实体全域一致性的设计目标。该方法的具体过程如下:

   1、构造实体集合

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

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

   识别实体之间的泛化关系,对实体进行归纳、分类,此时可以不处理语义的重复、交叉情况,但是要做两件事情:

第一对于定义不规范的实体要规范定义;

第二为了便于表达实体之间语义上的泛化关系,可以定义一些抽象的类,如收款凭证、付款凭证都是凭证的泛化,此时可能需要建立一个抽象的凭证实体。

由于此时模型由上万个实体构成,为了提高效率可以把整个设计团队分为多个小组,每组负责一个域并行进行,团队分头遍历自己域内所有实体,识别和构建泛化关系,经过上述步骤处理后各域在内部形成了一座按照语义继承关系组织的森林,但是此时兄弟节点之间还有可能存在重复定义或者语义交叉的情况。

   3、合并各森林为一座森林

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

b161789e64e9393b0268ad571ad34231.png

   具体工作方法如下:从语义分析入手,逐个对照树的根节点,分析其语义:

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

  • 统一命名
  • 合并这几个实体为一个实体
  • 合并以这几个实体为根的树

   (2)不同语义的实体采用相同的名字重新命名实体,从命名上区分开

   (3)相似语义的实体多次重复定义,概念内涵互相重叠、交叉,边界不清晰拆分实体,分别命名或者合并到已经存在的实体上,注意该树的子节点也要一起进行合并。

   4、递归上一步的合并过程

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

三、后记

   企业级数据模型必须在实体层面、属性层面、编码取值层面具有一致性,否则根据该模型构造的数据质量必然低下,一方面基于该模型开发分析类应用需要进行大量的清洗转换,增大开发难度,数据挖掘、大数据分析等高级形式的应用会愈加困难,甚至于某些场景的应用成为不可能。另一方面企业级数据模型无法指导制定数据共享的标准,数据交换停留在低效、复杂、割裂的数据交换层次,无法由数据交换提升为信息交换一致性不仅仅是企业级数据模型必须具备的基本特征,也是构建企业级数据模型过程中面临的主要困难,利用面向对象的方法可以有效解决实体、属性、编码取值等层面的一致性问题,为数据更好的采集、加工、应用奠定基础,也为数据价值的更好发挥起到至关重要的作用。

相关文章
|
存储 人工智能 Kubernetes
【企业架构】什么是数据架构? 管理数据的框架
【企业架构】什么是数据架构? 管理数据的框架
|
1月前
|
数据采集 数据安全/隐私保护
数据治理创新路:建设数据集市,强化数据报送一致性新实践
企业可以通过组织培训课程、提供操作手册等方式,提高数据报送人员的业务水平和数据意识,减少人为因素导致的数据不一致问题。
|
3月前
|
Cloud Native 领域建模 API
核心系统转型问题之建模平台在业务领域建模中的功能如何解决
核心系统转型问题之建模平台在业务领域建模中的功能如何解决
|
架构师 测试技术
【业务架构】业务架构师如何构建业务能力图?
【业务架构】业务架构师如何构建业务能力图?
【业务架构】业务架构师如何构建业务能力图?
|
数据采集 自然语言处理 算法
谈谈大型集团构建全域一致性数据模型的方法
数据建模包括概念模型、逻辑模型、物理模型。企业级数据模型设计通常有两种方法:自上而下和自下而上。
谈谈大型集团构建全域一致性数据模型的方法
|
存储 机器学习/深度学习 数据采集
谈谈数据湖分布式数据治理的数据目录应具备的四大能力【数据发现】
在过去几年中,数据湖已成为现代数据堆栈的必备要素。但是,虽然支持我们访问和分析数据的技术已经成熟,但在分布式环境中理解和信任这些数据的机制却落后了。
谈谈数据湖分布式数据治理的数据目录应具备的四大能力【数据发现】
|
数据采集 监控 Oracle
谈谈如何构建基于业务价值驱动的数据治理运营模式
成功的组织有各种各样的规模。这些公司的共同特点是,在优化业务流程执行的同时,通过最大化客户服务来挖掘其全部潜力。
谈谈如何构建基于业务价值驱动的数据治理运营模式
|
数据采集 存储 监控
数据治理框架:数据驱动型企业的基石
要解释数据治理框架,我们必须首先定义数据治理。
数据治理框架:数据驱动型企业的基石
|
数据采集 运维 监控
谈谈典型的数据治理体系框架
以规范的方式来管理企业的数据资产已经被广泛接受和认可,但还需要组织架构、原则、过程和规则,以确保数据管理的各项职能得到正确的履行。
谈谈典型的数据治理体系框架
|
存储 SQL 机器学习/深度学习
数据模型建设最佳实践和思考
信息系统、数据集成、主数据管理、数据仓库、大数据、数据湖和机器学习等所有这些都应该具有一个共同的基本要素:数据模型。
数据模型建设最佳实践和思考