知识分类

文章推荐

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

工作中也许存在这种情况：与技术人员对接数据模型、数据标准时沟通总是很费劲。要数据模型，给到一个表结构；要元数据，还给一个表结构；要数据标准，也给一个表结构。为什么这么乱？有什么办法能解决这个问题？

其实这个问题是一个典型的“巴别塔”问题。核心原因就是两类人群的语言体系不匹配，且涉及到结构化数据的本质。需要我们吃透概念，彻底理解它们之间的区别与联系。

 

01数据结构

一般来说，系统开发的满编团队都会配备数据库工程师、数据建模工程师。但是大部分开发团队里是没有专职数据库工程师的，更别说数据建模工程师了。都是开发人员自己建表。

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

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文件。

 

02数据模型

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

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

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

 

 

 

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

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

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

 

 

 

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

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

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

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

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

 

03元数据和数据元

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

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

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

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

l 业务术语 

l 参考数据和主数据 

l 指标数据 

l 数据元

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

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

 

 

 

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

简单来说，不同阶段用：

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

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

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

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

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

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

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

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

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

 

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

回到本文开头提到的问题，前面其实已经把基础概念解释清楚了。现在可以正式回答这个问题：

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

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

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

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

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

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

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

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

 

05 总结

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

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

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

 

 

中翰软件：专注数据治理19年（http://www.jobhand.cn）

 

 

免责声明：本网站所发布的文章为本网站原创，或者是在网络搜索到的优秀文章进行的编辑整理，文章版权归原作者所有，仅供读者朋友们学习、参考。对于分享的非原创文章，有些因为无法找到真正来源，如果标错来源或者对于文章中所使用的图片、链接等所包含但不限于软件、资料等，如有侵权，请直接致电联系，说明具体的文章，后台会尽快删除。给您带来的不便，深表歉意。