不就是表、字段么，怎么又叫数据结构、元数据、数据标准？

编 辑：老彭

来 源：大数据架构师

彭友们好，我是老彭。老彭在单位里的主业是负责数据治理、标准建设、人工智能业务的拓展与实施。顺便兼职给同事们解答各种奇奇怪怪的问题，提供各种资料。

嗯，各位彭友有任务需要参编国标、行标、团标的，有实力可以联系老彭哈~~~

最近各单位领导都在休假，工作节奏也稍微慢了一些。今天等着下班的功夫，一位做DCMM评估的同事过来问了我这么个问题：

“彭老师，在做DCMM评估的时候，跟被评估单位的技术人员对接数据模型、数据标准时沟通总是很费劲。

找他要数据模型，他给我一个表结构。要元数据，还给一个表结构。要数据标准，也给一个表结构。为什么这么乱？有什么办法能解决这个问题？”

其实这个问题解释起来比较麻烦，因为这是一个典型的“巴别塔”问题。核心原因就是两类人群的语言体系不匹配，而且涉及到结构化数据的本质。

语言体系不匹配的话，做好翻译、解释工作就行了。但是涉及到数据本质就不好弄了，得吃透概念，彻底理解它们之间的区别与联系，知其然，知其所以然。

数据结构

一般来说，系统开发的满编团队都会配备数据库工程师、数据建模工程师。

但是干过开发的都知道，大部分开发团队里都没有专职数据库工程师的，更别说数据建模工程师了。都是开发人员自己建表，属于是圣骑士既当奶妈又当T了。

前台页面输入的信息，在后台进行持久化存储的时候，基本上就是谁负责这个功能的开发，谁就负责数据结构的设计。对，就是在数据库里建一张表，设置对应的字段。

CREATE TABLE YGB

 ( 

    BH VARCHAR(8) NOT NULL PRIMARY KEY,

    XM VARCHAR(12) NOT NULL, 

    XB VARCHAR(2) NOT NULL, 

    BM VARCHAR(20) 

)

老彭注：这是一张典型的开发同学建的表，不用怀疑。开发的同学过来认领一下。

在这个阶段，根本没有数据库结构设计（数据建模）的环节，数据结构就等于表、字段。表现形式就是建表语句或者数据库里的表。提供的成果物可以导出为建表sql或者pdm文件。

数据模型

随着需求的不断增长，开发的工作量越来越大，需要存储的数据自然也就不断增加，系统里的表会越来越多。

另外，类似的功能会分给不同的人进行开发，还会导致另一个问题：类似的表越来越多，表间关系会越来越复杂。有些开发为了减少数据库查询，会进行冗余设计，就在在多个表中重复存储同一条数据。这会引发严重的数据一致性问题。

这个问题在数据库设计之初就已经解决了。关系数据库理论的奠基人英国计算机科学家和数学家埃德加·科德（Edgar F. Codd）在70年代就提出了“第三范式”（Third Normal Form,3rd NF）。

是的，这就是所有计算机相关专业必修的《数据库概论》里必考的三范式。

我们知道数据库中最核心的概念就是数据模型。三范式就是数据模型设计的基本原则。等同于机器人三原则。

在这个原则下设计出合理数据结构的工作就是数据建模，成果就是数据模型。长这个样子：

老彭懒得画图了，百度随便搜了一张，图片来自于知乎向上的夏夏

上图就是典型的“星型模型”。老彭之前有一篇文章专门分享了不同的数据模型，可以点击查阅“一口气讲完数据仓建模方法--数据仓库架构师碎碎念”

这个阶段的结果是数据模型，一般会有数据库设计文档，也可以导出为pdm文件。

与第1部分导出的pdm相比，经过数据库设计的pdm显然结构更加合理，表间关系更加清晰。

有一个非常简单的办法可以区分pdm是否设计合理：

通过数据库逆向导出的表，通常会缺失表间关系，也就是有很多单独的、没有跟其他表相连的表。

数据建模工程师建模的表是不太可能出现单独的表（极个别情况除外），而且表都是一堆一堆的，甚至能很清晰地看明白业务关系。

元数据和数据元

元数据是解释数据的数据。表中的字段等信息其实就属于元数据。但是元数据也是要看情况确定是否要管理的。

如果一个系统比较小，需求变化也不大，其实不用特意去管理元数据。但是如果业务比较复杂，比如在一个业务系统重的多个业务条线或者多个业务系统中都会用到同一个要素，那么就需要开始管理元数据了。

数据模型工程师在建模的时候，就会把常用的要素（其实就是数据结构中的字段的各种属性）提炼总结为数据建模时常用的数据标准。

请注意，这里的数据标准和DCMM里的数据标准是两码事。DCMM的数据标准指的是：

业务术语 

参考数据和主数据 

指标数据 

数据元

数据模型相关的数据标准，更贴近DCMM数据标准领域的数据元。

数据元在软件开发生命周期的不同阶段有不同的表现形式，如在软件需求分析阶段，数据元体现为面向对象中类的属性；在设计阶段，数据元体现为数据模型中的实体属性，数据库的字段、列；在编码阶段，数据元体现为接口参数。

来自于《GB/T 393445 公共信用信息数据元》

一般来说元数据我们用到的更多，数据元用的少。原因很简单，普及率不一样。换句话说，大多数公司里根本不管理元数据，更不用提管理数据元了。

简单来说，不同阶段用：

建设一个简单的系统，不用刻意管理元数据都是ok的。一个几十张表的业务系统，表的各种描述完全空着虽然不规范，但也没啥影响。

建设一个复杂的系统，或者需要在多个系统之间保持数据统一、让其他人能看明白表和字段的含义，则需要做好数据结构的描述和解释，认真管理好元数据。

需要跨多个企业甚至跨行业保持数据模型的一致，则需要建立数据元标准，便于保持同一个要素的一致性。

元数据和数据元的区别在于：

元数据是对数据的结构化描述，主要包括技术元数据、业务元数据、操作元数据。

数据元是组成实体数据的最小单元（原子数据），用一组属性描述定义、标识、表示和允许值的数据单元，由对象、特性、表示等部分组成。

因为元数据是在建模中必须要声明清楚的，目的是让大家都能看明白这个表/字段是什么意思，所以元数据归类在DCMM的数据架构域里。

而数据元实际上就是一个标准，让大家在设计数据模型的时候参照这个数据元进行设计，因此数据元归类在DCMM的数据标准域中。

DCMM和DAMA-DMBOK里元数据的概念是一致的。元数据其实有很多（比如管理元数据），但是考试的时候如果问元数据包括哪几种，标准答案应该选技术元数据、业务元数据和操作元数据，否则扣分。

老彭之前分享过一系列文章详细剖析元数据、数据元，可以到文末点开链接瞅瞅~~~

DCMM里的元数据、数据元怎么评？

回到老彭同事问的问题： 

找他要数据模型，他给我一个表结构。要元数据，还给一个表结构。要数据标准，也给一个表结构。为什么这么乱？有什么办法能解决这个问题？

前面其实已经把基础概念解释清楚了。现在可以正式回答这个问题：

1.数据模型的表现形式就是数据模型设计文件，正式一些就是数据库设计文档，技术一些就是PDM，或者EXCEL也可以。里面的内容就是表、字段等信息。

2.元数据，主要解释的就是各项数据。因此提供的结果打开也是各个表、字段的属性信息。

3.数据标准里的数据元，虽然不再是表、字段，但是业务上会与元数据有很多重合。看上去跟元数据的文档也差不太多。

解决这个问题，首先要理解吃透这三个概念，明白它们之间的区别与联系，在做评估的时候能跟对方的技术人员讲清楚。

其次，要明白评估数据架构域和数据标准域时，所需的资料和内容的差别，在收到评估文件的时候能看明白不同成果物评估侧重点。

1.评估数据模型的时候，核心是被评估单位是否建立不同级别的数据模型。企业级的数据模型是能在多个系统中参考使用的，项目级的数据模型就是某项目数据库设计说明书。

2.评估元数据的时候，核心是有没有做好元数据的管理（集成、变更、应用）。最简单的判断，是否能做血缘分析和影响分析。能随便查血缘，就证明元数据管理到位了。

3.评估数据元的时候，核心是看有没有建立数据元标准，有没有在新系统开发、老系统迁移的时候参照数据元标准进行贯标落实到位。

总结

数据模型是数据建模的结果，项目级别的数据模型就是数据库设计说明书。企业级的数据模型是企业公开发布的企业数据模型。

元数据是对数据结构化描述。元数据的管理水平可以通过元数据的采集、管理、应用程度来体现。所有系统的元数据都定期采集更新，并且能随便查血缘、做影响分析就很厉害了。

数据元是用于跨系统、跨企业、跨行业的数据元素标准。小企业用不上，一般是龙头企业定义，其他企业跟进。 

更多精彩：

数据元=元数据？

元数据是什么？怎么管？

什么是数据、元数据、主数据和参考数据？

一口气讲完数据仓建模方法--数据仓库架构师碎碎念

数仓的建模和BI的建模有啥区别？ 

建仓时，如何评估数据模型建的好不好？

排版 | 老彭

审校 | 老彭  主编 | 老彭