数据治理是一项综合性非常强的工作，涉及到的理论、方法及技术范围非常广。关注点不同，工作重点就不同。很多时候，我们都会根据自身的意图来选择表述的内容。本文论述的是在数据治理工作时，如何构建数据的框架。

我们在进行数据建模时，常用的数据建模方法在完成业务需求分析时，首先要建立概念模模型。概念模型就是初步制定要包含哪些实体，以及实体之间的关系。本文提到的数据框架，表现形式与概念模型有些类似，但设计目的和方法与数据建模的概念模型完全不同。本文中的数据框架，特指数据治理工作在数据标准重构时，用于统一各数据表描述的客观对象的标准，以及这些客观对象之间的联系。上述定义还是有些抽象，下面会从实战角度出发，讨论其设计的目的、意义和设计方法。

1、 数据描述的客观对象

如果单从数据表的结构信息来看，在确定一条记录的唯一性时，通常是以主键来识别的。（注：关系型数据库在数据量较大时，如果主外键的约束关系比较严密，在数据操作时会较影响性能。因此，有些系统设计要求数据库建设时，去除主外键约束关系，避免数据库在数据增、删、改时因数据规范性检查对系统性能的影响较大，而数据的质量和规范性通过其它手段，如采集环节的通过软件功能实现的数据规范性控制。但这并不影响数据表在设计环节中主键的设计）。所有非主键数据项是与主键相关联的。因此，这个数据表的主键所代表的客观对象就是这个数据表所描述的客观对象。

 现在许多设计以ID值为主键，就是一个随机的数值，本身没有任何实际意义。所以我们要分析出一个数据表的逻辑主键。即哪些数据项组合才能决定一条记录的唯一性。我们以一个实际例子来说明逻辑主键的意义。

从数据结构角度来说，打卡ID是主键，但它只是用于区分不同记录。而从实际意义上来说，某个人、某个时间才是打卡事件的区别条件。所以上表的逻辑主键应该是“打卡人、打卡时间”这个数据组合。我们再对这两个数据项进行区别，一个人具有唯一性，而打卡时间的时间是一个通用性的属性，只不过在事件中是一个具体值，不同人可能会有相同的时间。通常我们把打卡时间定义为“维度数据”，而把打卡人当成“客观对象”。而其它数据，如打卡地点、打卡方式、打卡类型则视为这个数据表的属性数据。

综上所述，我们在数据框架设计中所提到的客观对象就是各数据表中属性数据项所关联的、具有实际意义的事物。

2、 客观对象的定义方法

我们还以上面的打卡人为例，我们在数据上如何区别两条数据的打卡人是一个人还是两个人呢。示例中是以姓名来标识一个具体的打卡人，但实际两个人有可能名字相同。我们为了能够准确表示人的个体，可以用身份证号、员工编号、手机号等不同数据形式来表示一个人。所以一个客观对象在数据上的定义形式并不是唯一的。

3、 数据的粒度

我们先观察下面两张表：

表一：各单位产量月报

表二：各单位产量日报

表一中是厂为单位，每月车的大类的产量；而表二则是细分各厂的车间以及具体车的型号产量。虽然都是产量，但是数据的粒度并不同。表二无论从生产单位、产品分类还是时间都会更细。如果有表二，可以汇总生成表一，但反之则不能由表一拆分出表二。

所以我们观察数据表表述的业务内容时，还要观察各数据表描述的数据粒度。当两个数据表描述同一事物的不同属性时，如果数据粒度不同，这两组数据就无法关联。

4、 数据框架设计的必要性

我们在数据治理工作中，为什么要确定数据框架呢。我们从数据治理的目标来说，要实现数据的标准化、规范化，提升数据质量、消除数据孤岛。那么我们首先在数据标准定义这个层次上，就要保证数据互通互联。而数据治理工作是一个全局性的工作，笔者参与过的许多数据治理项目，通常会涉及到数十个系统，数据表数超万，数据项数更是可以高达几十万。这种工作根本不可能由一个人完成，通常需要一个团队分业务域、分系统来治理。如果不同人在治理时各自为政，就无法保证数据治理成果的全局性和统一性。所以必须建立统一的数据框架。我们以示例来说明数据框架的作用和设计方法。

我们把上面打卡数据做为某个安保系统的员工出入记录，这个系统是人名来定义员工的。而HR系统，则为每位员工定义了一个员工编号，其它数据以员工编号做为人的描述方式；而社保系统则以身份证号来进行唯一标识。在各系统各自为政时，每个系统都能正常运行。当我们要进行数据集成应用时，如HR系统要针对员工迟到早退情况进行统计，需要关联安保系统的出入记录，这时就需要将员工编号和姓名建立映射关系，如果迟到早退达到一定程度时，需要辞退该员工时，要在社保系统中终止用工，就需要使用该员工的身份证号。当然，上面示例一目了然，我们也能够通过姓名、员工编号、身份证号等建立一一对应关系，把不同系统的数据关联到一起。当我们统一了关于员工的定义方法，不同系统描述的与员工相关的数据，就能自然关联到一起，而不需要进行数据转换。