数据治理之数据梳理与建模

一、什么是数据模型

概念：根据DAMA-DMBOK2的描述， 数据模型是一组反映数据需求和设计的数据规范与相关图示 。

举例：买房时看到楼盘模型，模型对应实际房子的户型、绿化、周围设置等。
就像房子模型是对房子特征的描述一样， 数据模型就是对数据特征的描述。 换句话说， 数据模型就是用来描述数据的一组简单易懂、 便于计算机实现的标准符号的集合。

二、数据模型的类型

概念模型

概念：概念模型也叫业务模型， 是对业务实体、 业务操作、 操作规则的整体描述， 从全局上、 宏观上介绍业务设计的思路、 范围和内容。 概念模型的目的是组织、 审视和定义业务实体和规则， 它通常由业务人员和数据架构师创建。

概念模型是用来定义业务概念及其关系的，比如CRM系统中的客户、产品、供应商、合同等模型，概念模型侧重于业务逻辑，重点描述业务对象之间的关系，比如：客户下订单，订单关联产品等之间的关系。

概念模型的3个基本要素

• 实体：现实世界中的事物
• 属性：实体的特征或属性
• 关系：两个实体之间的关联关系

举例：客户属于实体，客户的名称、联系方式、工作地址、公司名称等属于客户属性；商品属于实体，商品名称、商品品类、商品价格属于商品属性，客户购买商品就表示客户实体和商品实体之间的关系。

概念模型的用途

概念模型是圈定建模范围、 划分建设主题、 理清主要业务关系、 构造逻辑数据模型的框架。
**在数据治理规划中， 概念模型经常用来做数据治理主题的规划， 梳理业务对象和业务对象之间的关联关系。 **
举例：下图是企业中概念模型的用途

逻辑模型

:::info
概念：逻辑模型是对概念模型的具体化， 它根据概念模型， 设计数据实体和数据属性， 着重于系统的逻辑实现， 不考虑物理属性。 该模型的目的是开发规则和数据结构的技术地图， 它通常由数据架构师和业务分析师创建 。
:::
逻辑模型是关于企业需求信息的完整模型， 包含数据实体和数据实体间的关系、 属性、 定义、 描述和范例等。 逻辑模型侧重系统实现， 可能会将多个实体归并为一个通用的对象来表现， 以确保系统的简洁性。

逻辑模型的特征

与概念模型相比， 逻辑模型增加了对数据元素和结构的定义， 并给出了每个数据元素的数据类型和字段长度等。 除此之外， 逻辑模型的设计通常需要遵循数据库的第三范式， 满足数据库系统的设计标准。 但逻辑模型是独立于数据库系统设计的， 到这一步还无法直接用于数据库的开发。
举例：下图是客户和商品物理模型，物理模型相对于概念模型增加了属性及其类型

逻辑模型的用途

逻辑模型能直接反映出业务部门的需求， 同时对系统的物理实施有着重要的指导作用， 它的作用在于通过实体和关系勾勒出企业的数据蓝图。 逻辑模型的设计目标是设计企业数据蓝图， 指导系统的建设； 逻辑模型采用业务语言设计， 是业务人员与技术人员之间沟通的手段和工具。

物理模型

概念：物理模型描述数据库中数据模型的具体实现， 其中包括逻辑模型中各种实体表的具体化， 如表的数据结构类型、 索引、 数据存放位置和数据存储资源分配等。 该模型描述如何使用特定的数据库系统实现业务，目的是实现数据存取， 它通常由DBA和开发人员创建 。

物理模型提供了数据库的抽象， 具有丰富的元数据， 有助于生成可视化的数据库结构， 有助于对数据库列键、 约束、 索引、 触发器以及其他DBMS功能进行建模。
举例：

物理模型特征

与逻辑模型相比， 物理模型包含了表之间的关系（主外键关系、 索引等） ， 所涉及数据元素的列都分配的是具体的数据类型、长度、 默认值、 字段约束、 访问配置文件和授权等。

物理模型用途

物理模型的作用是指定如何用数据库模式来实现逻辑模型， 以真正保存数据。 良好的物理模型设计能够节省数据存储空间， 保证数据的完整性， 并且方便进行数据库应用系统的开发。
举例：下图是逻辑模型到物理模型的示例

三、什么是数据梳理

:::info
所谓“数据梳理”即对企业数据资产的梳理。 通过对数据进行梳理， 可以知道企业到底有哪些数据， 这些数据存在哪里， 数据的质量如何。 数据梳理能够帮助我们对企业数据资产进行摸底， 为下一步的数据建模提供支撑。
:::

数据梳理两种流程

常用的数据梳理方法主要有两种： 自上而下的数据梳理和自下而上的数据梳理。

自上而下梳理

自上而下的数据梳理是指对企业数据的采集、 处理、 传输和使用进行全面规划， 通过规划， 由数据域、 数据主题、 数据实体、 数据模型， 一步步细化、抽象、 设计出具体的实体数据模型的过程。
举例：从顶层出发逐级细化到某个实体

数据域梳理

一般情况下数据域对应企业的业务域，比如财务域、人力域、生产域、销售域等。

数据主题梳理

数据主题对应数据域的二级分类，比如人力域中的人事管理、 绩效管理、 薪酬管理、 培 训管理等。

数据实体梳理

数据实体是根据数据主题进行梳理的，细化业务主题所包含的数据实体和设计的数据元素。比如：人事管理主题中包含的数据实体有组织机构、 人员等。

设计数据模型

逻辑模型设计是对实体进行抽象， 描述实体之间的继承或关联关系， 明确数据结构的属性构成等。物理模型设计是描述数据的物理数据存储结构和数据关系。

优缺点

优点： 全面、 系统的梳理， 通过数据域→数据主题→数据实体→数据模型的逐层分解， 使企业清晰地了解到企业数据的来龙去脉， 有助于企业把握各类数据的源头， 确保信息的有效性、 完整性和一致性， 有效消除信息孤岛。
缺点： 全面的数据梳理意味着较大的成本和较长的时间周期。

自下而上梳理

自下而上的数据梳理常用于数据仓库项目的数据模型设计，其特点是比较有针对性， 直击目标和需求。 该方法以目标和需求为驱动， 采用一种“顺藤摸瓜”的方式， 一步步梳理出实现需求所需的数据， 并确定这些数据的来源、 数据结构以及数据实体之间的关系等。
举例：从需求出发，自下而上顺藤摸瓜的方式，一步步梳理出实现需求所需的数据

需求分析

数据治理项目是一个复杂的过程， 项目的开发涉及多方面的问题和风险，如技术风险、 数据质量问题、 项目管理问题等， 项目中最隐蔽、 最容易忽略、最难控制的一环就是需求的调研和分析。 需求分析应从IT现状、 业务部门、 高层希望等方面展开， 明确项目的目标和范围。

展现

虽然有了明确的需求， 但是客户往往更关注的是数据的展现形式和效果，因此将不同的数据分析结果推送给不同的客户是该阶段的重点。 采用原型展现的方式可以帮助理解和引导客户的需求。

分析逻辑

分析逻辑是指分析实现需求的业务逻辑， 其输出结果是数据仓库的逻辑模型。 逻辑模型用来表达实际业务中的具体业务关系和分析逻辑。

数据建模

数据建模是将逻辑模型转化为给数据库存储的物理模型。 目前业界较为流行的数据仓库建模方法非常多， 每种方法本质上就是从一个不同的角度看业务中的问题。

优缺点

优点： 目的性强， 从既定的需求出发到具体的数据结构设计， 越到底层变化的可能性越小。 与从整体出发的大规模调研规划相比， 这种方法的周期更短、 见效更快。
缺点： 局部梳理， 缺乏全面性和系统性， 无法支撑企业顶层的数据架构设计。 一般来说， 有了明确的项目目标和需求的情况下采用该方法较佳。

四、数据建模技术和方法

ER模型

不多介绍，百度自查

五、数据建模与数据治理

数据模型和数据治理的关系

数据模型VS元数据

在数据模型中， 业务模型描述了业务主题、 业务规则定义， 这些为业务元数据； 物理模型包含数据实体、 数据实体之间的关系、 数据结构、 主外键关系等内容， 这些为技术元数据； 数据关联关系是元数据血缘分析的基础。 所以从一定程度来说， 数据模型是描述企业业务需求的元数据集合。

数据模型VS主数据

从技术的角度来说， 主数据管理是由数据模型驱动的。 主数据管理涉及的主数据定义、 主数据管理、 主数据清洗、 主数据采集与分发、 主数据质量管理等核心功能都是以主数据的元模型为基础而展开的。 数据模型为主数据管理提供了清晰、 一致的数据结构定义， 指导主数据管理解决方案的实施。

数据模型VS数据质量

在多系统的信息化环境中， 数据模型不一致是导致数据质量问题的根本原因。 同时， 数据模型为数据质量管理提供业务元数据的一致性定义、 数据质量规则定义等关键元数据的输入， 为后续数据质量规则定义、 数据质量检核、 数据质量报告生成提供了基础。 良好的数据模型能改善数据统计口径的不一致性， 降低数据计算错误的可能性。

数据模型VS数据标准

数据模型是对现实世界的复杂数据结构的一种抽象表达， 是对业务规则的描述。 从数据库角度看， 数据只有在其能正确反映所定义的业务规则时才有意义， 正确的业务规则才能定义实体、 属性、 联系和约束。 因此， 数据模型标准化是数据标准化的重要组成。 数据模型的业务规则来自对企业操作的详细描述， 可帮助企业创建和实施具体活动， 因此必须明确制定并及时更新， 以正确反映企业操作环境的变化， 帮助企业实现数据标准化。

数据模型VS数据安全

数据模型是数据安全管控要素之一。 在构建数据模型时， 需要定义实体、属性、 联系和约束， 并根据企业具体的数据安全需求标注出敏感字段/表。 企业需要参考数据模型来制定具体的数据安全技术实现需求与业务规则， 判断哪些字段可以被哪些人查看， 哪些字段需要脱敏等。

数据模型VS数据仓库

数据模型是数据仓库、 BI系统的核心， 良好的数据模型有利于数据的血统分析、 影响分析， 为高质量的决策提供保障。 在数据仓库建设过程中， 数据模型是数据组织和存储的方法， 它强调从业务、 数据存取和使用角度合理存储数据。 只有数据模型将数据有序地组织和存储起来， 大数据才能得到高性能、 低成本、 高效率、 高质量的使用。 数据模型的设计是数据仓库建设的基础， 数据模型提供全面的业务梳理和整体的数据视角， 促进业务与技术有效沟通， 形成对主要业务定义和术语的统一认识， 而且具有跨部门、 中性的特征， 可以表达和涵盖所有的业务。

数据模型VS数据集成

数据集成是把不同来源、 格式、 特点性质的数据在逻辑上或物理上有机地集中起来， 从而为企业提供全面的数据共享。 而要实现数据的集中共享， 充分分析现有数据模型就显得尤为重要。 保证数据模型中关键元素的一致性是数据集成时首先需要考虑的问题。

数据模型VS数据操作

数据模型所描述的内容包括三个部分： 数据结构、 数据操作和数据约束。数据操作主要描述在相应的数据结构上的操作类型和操作方式。 它是操作算符的集合， 为数据提供一个规范的结构。 规范化的结构和约束为数据存储和操作提供了保障， 降低了数据操作时发生数据异常的可能性。

数据模型管理存在的问题及解决办法

数据模型变更随意

大部分企业数据模型是开发人员自行决定，随意变更，在数据变更时没有从数据设计、 业务合理性、 数据质量规则、 数据库性能等方面进行综合评审。

应对方法：严控数据模型变更
控制数据模型变更是为了保证数据模型与数据库的一致性。 通过建立数据模型管理流程， 明确创建、 变更、 注销的流程和角色职责， 在模型变更之前设置相应的人员去判断变更的合理性， 并对变更的内容进行审计。 监控模型变更的过程， 确保按规划要求完成变更。

辅助性工具缺失

数据建模依据的数据标准、 建模规范、 编码规范、 模型管理工具等辅助性工具缺失， 导致无法对以下内容进行监督和管理： 修改操作是否符合规范， 修改的脚本是否按要求编写， 修改时是否先修改模型再编写脚本， 是否及时保证数据模型与数据库的同步等。
应对方法：使用辅助工具
在数据模型管理中， 辅助管理工具是管理数据模型的一个重要部分。 很多建模工具内置了大量模型管理工具， 例如模型查询和浏览、 模型版本管理等。另外， 数据建模管理还要有一套自动化的校验工具， 校验可以避免在使用中出现错误。 标准数据模型可以实现一定程度上的自动化校验， 但是无法实现100%校验。 不管是开发人员还是测试人员， 都需要制定一些规则去校验， 只有通过校验才能及时发现问题。 例如， 把“员工”的同义词定为“职员”， 那么即便在使用过程中， 大家没有使用标准用语， 有人用“职员”， 有人用“员工”， 自动校验工具也可以自动把它们都转换成“员工” 。

数据模型共享不及时

在数据模型修改后未将修改内容及时公开， 导致修改的内容仅有内部的部分人员知道， 其他人员均不知道。 同时， 未将修改的内容纳入数据模型统一管理体系， 致使系统出现问题无法追溯， 问题的排查难度较大， 而数据模型管理逐渐变成“黑盒子”。

应对方法：共享数据模型
在项目生命周期中， 在合适的时间、 合适的地点将合适的数据模型共享给合适的人非常重要。 只有将数据模型在管理人员、 业务人员、 技术人员中共享， 才能使他们更加理解定义、 生成和使用数据的业务和技术， 并将其作为日常工作的一部分。