企业级数据模型设计方法论探讨

1、引言

数据模型设计是一个老生常谈的话题。在以往的数据仓库BI项目中，数据模型的方法论、概念通常围绕如何设计和建设数据仓库，而应用系统（OLTP系统）模型设计却缺乏方法论的指导，加之各应用系统通常都是由不同厂商在不同时期自行设计开发，彼此之间缺乏沟通，导致数据分散重复、口径不一致和数据兼容性差。由于数据仓库在企业整体信息化规划中属于下游系统，只能被动接收由各应用系统产生的数据，数据入仓之后，由于口径不一致、兼容性差，给数据整合带来极大困难。企业在投入大量的人力、物力和资金推进信息化建设，仍然出现大量的“信息孤岛”现象。

本文认为，企业信息化建设的成功很大程度上取决于系统模型的合理性和不同系统间概念的一致性，而企业级数据模型是企业信息化的核心问题，通过企业级数据模型定义整个企业信息化体系的数据标准，逐步统一企业内部数据标准，指导各应用系统数据模型统一设计，可以从根本上保证系统之间数据的兼容性和一致性，消除由于各应用系统自行设计开发而导致的数据分散重复、口径不一致和信息孤岛现象，推动企业内各类应用系统的整合和数据的共享，全面提升经营决策、运营管理、业务拓展和客户服务等方面的支撑能力。

本文将首先阐述企业级数据模型的定义和结构，分析其业务价值，通过描述企业级数据模型与应用系统模型间关系，划分两者之间的概念边界和区别，从而更好的理解企业级数据模型的真正内涵。其次，阐述企业级数据模型设计的基本方法和关键要点，使读者能够掌握企业级数据模型设计的整体思路，以便对后续工作提供借鉴和指导作用。最后，总结了多个项目的经验教训，分享企业级数据模型建模过程中的心得体会，希望对大家能有所帮助。

2 企业级数据模型定义2.1模型基本定义

企业级数据模型不能等同于数据仓库模型，企业级数据模型是站在整个企业业务的视角，对企业全部数据（包括生产数据和消费数据）全貌性、整体性描述。企业级数据模型是业务人员和IT人员进行沟通的媒介、也是企业内部与外部进行交流的纽带。

企业级数据模型是一种建设蓝图，它识别了企业内部跨功能、跨部门、跨组织的共享或冗余数据，为系统的规划、设计和实施提供一种可视化方式和支撑框架，是企业内部所有应用系统数据模型设计的起点，如ODS、EDW等系统的设计开发，有助于促进数据整合、消除数据孤岛和遗留系统保持一致。

企业级数据模型是一个数据集成定义，它不依赖于企业内部某个具体的系统或应用，也跟数据的物理实现无关（包括数据如何获取、如何存储、如何处理以及如何访问）。

2.2模型结构

企业级数据模型可分解为三个层级：主题域模型、概念模型和逻辑模型。三个层次模型逐级扩展。企业级数据模型的创建更是一种艺术而非一门科学，应集中企业的集体智慧，共同推进企业级数据模型的不断完善。

2.2.1主题域模型企业主题域模型在企业级数据模型中处于第一层次，其覆盖原则是“有需求才覆盖”，一个企业的平均主题域数量通常在10~20之间。

Ø 主题域模型内涵

• 主题（Subject）是在较高层次上将企业的数据进行综合、归类和分析利用的抽象概念，每一个主题通常对应一个宏观的业务分析领域。

• 主题域是对某个主题进行分析后确定的主题边界。典型的主题域包括参与人、产品、协议等。

• 主题域模型处于企业级数据模型的顶层，是针对企业关键业务领域、业务概念的分类方法和框架。

  
  
  

Ø 主题域模型特征

• 看似简单的主题域模型实际上凝聚了企业内部中高层管理者的共识，因而需要耗费较长时间进行充分的沟通和交流；

• 主题域模型的价值在于企业内部对业务的理解深度，以及体现企业内部各方达成的协议。

  
  
  

2.2.2概念模型

企业概念模型在企业级数据模型中处于第二层次，将每个主题域进一步细分为“概念”，通常每个主题域包括10~20个“概念”。企业概念模型由概念以及概念之间的关联关系组成。

Ø 概念内涵

• “概念”是对主题域、主题域范围的进一步定义和细化；

• “概念”描述企业生产和消费的核心业务信息，独立于具体实现问题和细节 ；

• “概念”应基于企业的主要业务，应由企业主要业务驱动“概念”定义；

• “概念”的要点在于表现企业重要的业务视角，而不是数据量的大小；

• “概念”还需考虑行业的适用性，如包括供应商、合作伙伴以及外部引用数据的概念。

  
  
  

Ø 概念模型特征

• 概念模型是一种高阶数据模型，以实体—关系（Entity-Relationship，简称E-R）理论为基础，通过主题域形式描述概念化的结构；

• 概念模型是对主题域模型的进一步细化；

• 概念模型定义了企业内主要业务实体及实体间的业务关系；

• 概念模型不描述业务实体的数据属性；

• 实体之间可能存在多对多关系，不对数据进行范式化处理。

  
  
  

2.2.3逻辑模型

企业逻辑模型在企业级数据模型中处于第三层次，并将每个概念进一步细分为“逻辑实体”。企业逻辑模型由逻辑实体、业务主键、关联关系和重要属性组成。

Ø 逻辑模型特征

• 逻辑模型是对概念模型的进一步分解和细化 ，通过关键数据属性描述更多业务细节。

• 逻辑模型描述实体、属性以及实体关系。

• 逻辑模型只包含关键数据属性，而不是全部实体和全部属性。关键数据属性是指那些如果缺失而导致企业无法正常运转的属性，但这种判断通常是非常主观的决定。

• 设计时一般遵从“第三范式”，以求达到最小的数据冗余，维护数据的完整性和可扩展性检查数据模型是否符合第三范式要求，有如下三条检验标准：

• 主键是唯一的，不具有多义性；

• 每个非主属性必须完全依赖于整个主键，而非主键的一部分；

• 关系模式中不存在传递依赖；

• 逻辑模型独立于具体技术，是IT人员和业务人员沟通的工具。

  
  
  

2.3企业级数据模型的业务价值

企业信息化建设的目的是通过运用信息化技术来提高企业的生产、运营效率，降低运营风险和经营成本，从而增加企业盈利和持续经营的能力。企业级数据模型定义了企业信息化体系的数据标准，是企业内部各应用系统能够实现相互协作、共享数据的前提，是企业信息化建设成功的必要条件，它的业务价值体现在以下几个方面：

提升数据质量。企业现有系统在与企业级数据模型映射过程中，能够暴露系统之间数据的差异性、内在的冗余数据，可以将许多潜在的数据质量问题在正式实施之前予以暴露、并解决。

厘清数据所有权。通过将跨业务、跨组织边界的企业数据之间的关联关系、依赖关系进行识别并文档化，企业级数据模型可以作为数据所有权管理工具，支持“共享”数据所有权的概念。

增强系统的可扩展性。企业级数据模型支持可扩展性的数据架构，基于战略业务视角，独立于具体的技术实现，支持可扩展性。能以很小的IT变更代价适用不断变化的环境。

整合行业数据。企业级数据模型吸收了企业外部视角，结合行业数据集成框架，提高了企业的行业数据适用性，从而提升了企业共享行业公用数据的能力，如客户、位置、供应商等基础数据。企业也可以与相关行业或合作伙伴共享数据。

整合套装应用软件。通过将套装应用软件映射到企业级数据模型中，提升了企业级数据模型在企业内部的匹配度，并能识别出套装应用软件和遗留系统之间的集成点，通过打包产品提供一致性、高质量的数据流转地图。

2.4企业级数据模型与应用系统数据模型间关系

企业级数据模型是企业内部所有应用系统数据模型设计的起点。企业级数据模型与应用系统数据模型之间的关系表现在以下三个方面：

• 企业级数据模型是企业内所有应用系统的基础数据模型。在构建企业数据存储架构（ODS、DW、数据集市和应用）之前，首先要基于企业级数据模型中的企业逻辑模型创建一个应用级逻辑模型，而该模型是企业逻辑模型的子集，因此，企业逻辑模型是所有数据存储架构的基础模型。
  
  
  

• 数据架构框架。企业级数据模型为企业数据设计和数据存储提供了一个数据架构框架，以支撑数据质量、可扩展性和完整性。业务数据需求和数据源（遗留系统）为企业的数据设计提供“装修材料”，这些“装修材料”以属性的形式“填充”到企业逻辑模型框架中。

• 数据“粘合剂” 。企业级数据模型为企业提供了一个数据集成框架，所有的应用级逻辑模型都可以被映射到企业逻辑模型中， 企业级数据模型就像“胶水”，将企业内部所有数据连接在一起，包括套装应用软件。

  
  
  

3、企业级数据模型设计

3.1模型设计方法

企业级数据模型设计可采用“业务需求驱动自顶向下”和“基于现状驱动自底向上”相结合模式，参照业界参考模型、行业最佳实践，共同形成数据模型。从业务需求驱动入手自顶向下，参照业界参考模型、行业最佳实践搭建数据模型整体框架

通过现状调研获取企业内部业务流程、设计文档、系统模型、接口规范等现状信息，现状驱动自底向上，细化和完善数据模型的设计。

3.2模型设计要点

本文不讨论企业级数据模型设计的具体细节，只讨论建模过程中的关键步骤和要点。企业级数据模型设计总体可分为四个步骤：前期准备、主题域模型设计、概念模型设计、逻辑模型设计。

3.2.1前期准备

在企业内部，涉及多个业务部门，对于一个业务问题通常会有多个不同的观点和看法，每个相关人员需要理解和沟通各自的观点和看法。为了阐明和沟通我们的观点，我们需要理顺企业内部所有核心术语定义以及术语定义的关系，形成一个精确的和公认的术语词典表。因此，在构建企业级数据模型之前，需要在企业范围内统一业务术语，在后续建模过程中给相关人员提供一个沟通的基础。

3.2.2主题域模型设计

   主题域模型设计凝聚了企业内部中高层管理者的共识，是企业内部各方相互妥协后达成的协议。主题域模型设计过程中注意以下几个要点：

Ø  设计依据

  设计依据来源于三个方面：立足需求和现状、行业最佳实践和业界理论支撑。

• 立足需求和现状。基于企业业务整体发展的需求以及行业监管要求，在企业范围内开展业务调研、信息调研获取企业的当前现状信息，作为主题域模型设计的输入信息。
• 行业最佳实践。借鉴国际、国内本行业相关企业的实践经验以及相关工作成果。了解相关企业在数据建模过程中所取得的成就和经验教训，确保企业在建模过程中少走弯路。
• 业界理论支撑。参考业界通用数据模型设计思路，推动业界参考模型产品的客户化处理。通常，每个行业都会有本行业的参考模型，例如：金融行业典型的参考模型包括TD FS-LDM和IBM FSDM模型；通信行业典型参考模型包括NGOSS-SID模型。
  
  
  

Ø  关键要点

• 设计过程需要整个企业内部各个部门的广泛参与 ，有助于形成合力、达成共识。
  
  
  

业务专家的深度参与和亲临指导，有助于识别、理解组织架构和业务功能；

• 主题域的定义和命名过程很重要，它有助于覆盖企业的重要业务主题，避免重大遗漏；
• 主题域名称应该清晰、简洁、易于理解。
  
  
  

3.2.3概念模型设计

概念模型设计是从企业角度出发，采用“自上而下”的开发模式。不局限于某个特定业务领域或应用。概念模型设计过程中注意以下几个要点：

Ø两个关键步骤

• 识别各主题域下的关键实体，对关键实体再进行细分类。

  
  
  

• 识别关键实体及其分类之间的关联关系。

  
  
  

Ø  关键要点

• 建立概念模型过程中必须得到业务领域专家和业务负责人的指导，并由业务用户提供模型的应用需求。
• 模型设计师完成初步设计以后，需通过多轮会议，由业务领域专家、相关主题域的专家验证本主题域概念是否符合要求；
• 会议过程中，概念模型初稿暴露出的概念重叠、冲突或其它关注的问题都将应记录下来，由模型设计师继续调整模型，概念模型的最终成稿通常需经历多轮迭代，迭代次数取决于概念模型的复杂程度和发现问题的数量。
  
  
  

3.2.4逻辑模型设计

逻辑模型基于概念模型进行扩展，包括扩充逻辑实体、提取关键数据属性、业务规则、值域填充到逻辑模型当中，它是业务人员、IT人员用来发现、记录和沟通业务的详细“蓝图”。逻辑模型设计过程中注意以下几个要点：

Ø  逻辑模型承载着企业数据标准。通过逻辑模型中的实体、关键属性等可以有效地承载数据标准的内容，并传递到应用系统模型设计中。

Ø  逻辑模型承载着业务数据规则。

• 基数规则。例如：定义与两个实体间关系相关的某个实体的实例数量。譬如下图表示“一个客户可以在银行有多个存款账号，最多有一张白金理财卡”。基数规则有“一对一、一对多、多对多”三种类型。

• 参照性规则。例如：为确保正确有效的数值所定义的规则。譬如下图表示“存款不能没有存款客户，必须要有一个存款人。

  
  
  

Ø  逻辑模型承载着企业数据质量规则。通过逻辑模型，可以了解数据质量要求，提前数据质量的管控或检测，做到提前预防不合规的数据提交给下游数据使用者

• 针对前页的业务数据规则，可以对系统中数据进行如下质量规则的检查。例如：检查是否存在持有多张（大于1张）白金理财卡的客户； 检查是否存在没有存款人的存款帐户存在。
• 结合逻辑模型中实体属性的域定义的格式、取值范围等，在系统模型设计时继承该实体属性的质量检测管控，防止不合乎标准的数据进入系统。
  
  
  

Ø  关键要点

• 模型设计师创建逻辑模型的初始版本，通过工作会议的形式，由业务领域专家进一步验证逻辑模型的完整性和准确性；
• 逻辑模型的设计过程需要多轮迭代，迭代次数取决于实体概念的数量、业务的复杂程度或者发现问题的数量。
  
  
  

4 心得体会与总结

本人先后参与了金融数据模型、征信数据模型等多个大型企业的数据模型设计项目，具有扎实的理论基础和丰富的数据模型设计实践经验。通过总结项目期间的经验和教训，分享建模过程中的心得体会，希望对大家能有所帮助。

Ø  企业级数据模型设计应以“自顶向下”方法为主，应通过中高层访谈、规划研读等方式，充分理解公司发展战略目标、业务规划和信息化规划，以便站在企业整体业务视角上，洞察企业数据的全貌性和整体性；

Ø  在模型设计工作开始之前，应首先推动在企业范围内形成统一的业务术语词典，统一业务术语定义，“磨刀不误砍柴工”，各部门业务人员有了共同的沟通基础，在后续的模型设计工作中就可以起着事半功倍的效果；

Ø  主题域模型设计中，对于企业一级主题域的划分，并不是一定要按照本企业的主营业务分类作为划分依据，而是从数据模型知识更容易传播、共享的角度，参照本行业参考模型进行一级主题域划分，这样更利于吸收企业外部视角、整合行业数据。

Ø  概念模型设计需要业务领域专家的深度参与和业务负责人的亲临指导，模型成果才能紧贴企业实际需要，符合企业要求。业界参考模型和行业最佳实践，都只是参照物，业务需求才是模型设计工作的主要驱动力。通过业务领域专家的深度参与，才能获知本企业在该业务领域最关注的核心概念及分类，才能梳理出核心概念及分类之间的关联关系。业务负责人则是对设计成果的进一步完善和确认。

Ø  逻辑模型涉及到业务细节问题，同样离不开业务人员的深度参与。需要着重指出的是，逻辑模型是一种通用模型，模型设计师在面对大量的数据库设计文档、系统模型、接口规范时，应根据设计经验提炼出所需要的主要实体、关键属性、业务规则，以便对概念模型进行进一步细化和分解。

Ø  过程比结果更重要。通过建模工作，大家一起去讨论、交流和学习建模方法论、业务知识，共同推进模型设计工作的完善和改进，这本身就比模型交付结果更重要。因为在这个过程中，员工得到了成长，彼此之间增强了信任，为下一步的合作奠定基础。

Ø  企业级数据模型的建设不是一劳永逸的，需要持续不断的进行维护和改进。模型成果交付以后，并非静止不动，而是需要由专人持续不断的改进和完善。

作者简介

杨科学，御数坊高级咨询顾问，2006年硕士毕业于中南大学计算机专业，主要从事数据治理、数据标准、数据质量、数据模型设计等咨询和设计工作。先后为金融、电力等行业的多家大型企业提供数据治理咨询和企业数据模型设计服务工作。

来源：御数坊