元数据、数据元、数据单元、数据元素：从“厨房做饭”讲起，一次搞懂数据治理四大核心概念（完整版）

用做饭的故事，让你10分钟分清这四个“元”字辈兄弟，附SAP真实案例+国际标准+落地实践

标签：#数据治理 #元数据 #数据元素 #SAP入门

摘要：元数据、数据元、数据元素、数据单元，这四个概念是不是傻傻分不清？别急，今天我用“厨房做饭”这件事，帮你理清它们的关系，顺便看看SAP里到底怎么用的，还有国际标准和落地实践。

---

开场：从“做饭”到“数据”，原来是一回事

我刚开始接触SAP数据治理，领导扔给我一张CDHDR表结构图，问：“你知道这表里的字段对应的数据元素是什么吗？元数据又在哪里？”

我盯着那张图看了半天，脑子里全是“元”字在转圈。后来我请教了一位老顾问，他笑着说：“你把它想象成做饭，就全明白了。”

那一刻，我突然开窍了。今天，我就把这个“厨房类比”分享给你，还会深入拆解SAP的CDHDR/CDPOS表、讲透数据元素和域的区别、介绍国际标准ISO 11179，最后聊聊怎么在实际数据治理中落地。

---

一、先看一张SAP的真实截图（就是你提供的那张）

这张图是SAP CDHDR表（变更记录抬头表）的字段定义。我们挑一个字段来看看：

字段	键	初始值	数据元素	数据类型	长度	简短描述
USERNAME	☑		CDUSERNAME	CHAR	12	修改文档中的个人信息的用户名

在SAP里，这张表里每个字段都绑定了一个数据元素（比如CDUSERNAME）。那元数据在哪？数据元又是啥？数据单元呢？

别急，我们先建立一个“厨房模型”，然后把每个概念对号入座。

---

二、厨房烹饪类比：四大概念一次搞懂

假设你要在厨房做一道“番茄炒蛋”。我们来定义一下涉及的概念：

概念	厨房类比	一句话解释
元数据	你家厨房的**“菜谱规则”**：鸡蛋按“个”计量，番茄按“克”计量，盐按“勺”计量	描述数据应该怎么描述——规定你用哪些“单位”和“格式”
数据元素	“鸡蛋”这个食材的定义说明书：鸡蛋是什么？它是圆形的，外壳是黄色的，一个鸡蛋大约50克	告诉你一个数据元（比如“3个鸡蛋”）应该长什么样
数据元	“3个鸡蛋” 这个具体的数量	不可再分的最小数据，比如“3”和“鸡蛋”
数据单元	“3个鸡蛋 + 2个番茄 + 1勺盐” 这一整道菜的原材料清单	一组数据元的组合，构成一个完整的业务对象

这样一看，是不是清晰多了？下面我们每个概念都展开讲。

---

三、元数据：数据的“菜谱规则”

3.1 什么是元数据？

元数据 = 关于数据的数据

说白了，就是告诉你“数据应该用什么格式、什么单位、什么规则来记录”。

在厨房里，你有一本菜谱，菜谱上写着：

• 鸡蛋：单位是“个”
• 番茄：单位是“克”
• 盐：单位是“勺”

这些“个”、“克”、“勺”就是元数据。它们不是食材本身，而是描述食材的规则。

3.2 生活中的更多例子

• Excel表格的列头：“姓名”、“年龄”、“性别”——这些是元数据
• 图书馆的图书分类号：I247.5（文学类）——这是元数据
• 超市货架上的标签：“品名：牛奶，净含量：250ml”——标签本身是元数据

3.3 技术上的元数据

• 数据库：表名、列名、数据类型（VARCHAR、INT）、长度、是否允许空
• SAP：数据字典（SE11）里所有对象的定义
• XML：标签名、属性名、DTD/Schema

3.4 在SAP里，元数据在哪？

打开事务代码SE11，看到的所有数据字典对象都是元数据：

• 表定义
• 视图定义
• 数据类型
• 域
• 数据元素

这些定义本身不是业务数据，而是用来描述业务数据的规则。

3.5 小结

维度	说明
核心作用	定义数据的“语法”和“规则”
谁创建	数据架构师、系统管理员
谁使用	所有人（但不直接修改）
变化频率	极低，一旦确定基本不改
厨房类比	菜谱上写的单位（个、克、勺）

---

四、数据元素：食材的“定义说明书”

4.1 什么是数据元素？

数据元素 = 一个数据元的“身份证”

它告诉你某个数据元应该具备哪些属性：叫什么名字、什么类型、多长、取值范围是什么、业务含义是什么。

在厨房里，你有一种食材叫**“鸡蛋”，但什么是“鸡蛋”？你得有一份食材定义**：

• 名称：鸡蛋
• 分类：蛋类
• 计量单位：个
• 标准重量：约50克/个
• 颜色：外壳为白色或褐色
• 保质期：冷藏下14天

这张“食材定义卡”就是数据元素。

4.2 SAP里的数据元素

回到截图，字段“USERNAME”绑定的数据元素是CDUSERNAME。
例如在SAP中双击CDUSERNAME即可看到CDUSERNAME这个数据元的全部信息。

CDUSERNAME这个数据元的全部信息如下：

在SE11里查看CDUSERNAME的定义，你会看到：

属性	值
数据元素	CDUSERNAME
域	USERNAME_DOM
数据类型	CHAR
长度	12
简短描述	修改文档的用户名
字段标签	用户名

这个定义就是数据元素。它不是一个具体的用户名，而是一个模板，告诉系统“所有叫CDUSERNAME的字段都长这样”。

4.3 为什么要有数据元素？

你可能会问：“直接在表里定义VARCHAR(12)不就行了，干嘛多一层？”

✨核心原因：复用！

假设你有10张表都需要存“用户名”：

• 没有数据元素：每张表都要单独定义一遍VARCHAR(12)，哪天想改成20位，10张表都要改
• 有了数据元素：10张表都绑定同一个数据元素CDUSERNAME，改一处，10张表自动生效

这就像你开了10家分店，每家都用同一份食材定义卡，统一标准。

4.4 小结

维度	说明
核心作用	为数据元提供标准化定义，实现复用
厨房类比	食材定义卡（鸡蛋 = 蛋类、50克/个）
SAP名称	Data Element
关键操作	SE11 创建/修改
复用场景	多个表字段共用同一个数据元素

---

五、数据元：不可再分的“食材”

5.1 什么是数据元？

数据元 = 最小粒度的数据单元，不能再拆

在厨房里，你说“我需要3个鸡蛋”——这里的 “3” 和 “鸡蛋” 就是两个数据元。

• “3”是一个数值数据元
• “鸡蛋”是一个类别数据元

它们不能再拆了：

• 你不能把“3”拆成“1”和“2”，那是不同含义
• 你不能把“鸡蛋”拆成“鸡”和“蛋”，那会改变意思

5.2 数据元 vs 数据元素

最容易混淆的就是这两个。我们用表格彻底分清：

对比维度	数据元	数据元素
是什么	具体的值	值的定义模板
厨房类比	“3个鸡蛋”中的“3”	“鸡蛋”这个食材的定义说明书
技术例子	USERNAME = '张三'	CDUSERNAME 的定义
能否变化	每个业务记录都不同	全局固定，一般不改
存储位置	数据库表的具体字段值	数据字典（元数据）
在SAP里	表里存的具体用户名	SE11里定义的数据元素

5.3 用代码看区别

-- 数据元素：USERNAME_DEF（定义）
-- 数据类型：VARCHAR(12)
-- 含义：用户名

-- 数据元：具体的用户名值
INSERT INTO CDHDR (USERNAME) VALUES ('张三');   -- '张三' 是数据元
INSERT INTO CDHDR (USERNAME) VALUES ('李四');   -- '李四' 是另一个数据元

在SAP ABAP里，数据元就是一个TYPE，数据元是具体的变量值：

DATA: lv_username TYPE cdusername.  " cdusername 是数据元素
lv_username = '张三'.                " '张三' 是数据元

5.4 小结

维度	说明
核心作用	承载具体的业务数值
厨房类比	3、鸡蛋、番茄、盐
关键特性	原子性——不可拆分
SAP对应	表字段里存的值

---

六、数据单元：完整的“菜品配方”

6.1 什么是数据单元？

数据单元 = 一组数据元的组合，构成一个有完整业务含义的实体

在厨房里，你炒一盘“番茄炒蛋”，需要用到：

• 3个鸡蛋（数据元）
• 200克番茄（数据元）
• 5克盐（数据元）
• 10克糖（数据元）

这四样东西组合在一起，就是这道菜的配方，也就是一个数据单元。

6.2 SAP里的数据单元

在CDHDR表里，每一行记录就是一个数据单元：

USERNAME	UDATE	UTIME	TCODE	CHANGE IND
张三	2024-01-15	14:30:00	SE11	U
李四	2024-01-15	15:20:00	SE38	I

这一行包含了多个数据元（用户名、日期、时间、事务码、修改类型），它们组合起来描述了一次完整的变更操作。这个“变更操作”就是一个数据单元。

6.3 数据单元 vs 数据元

对比维度	数据元	数据单元
粒度	最细（原子）	适中（组合）
能否独立存在	可以，但无业务含义	有完整业务含义
厨房类比	一个鸡蛋	整道菜的配方
例子	“张三”	“张三于2024-01-15修改了SE11的字段”

6.4 小结

维度	说明
核心作用	把多个数据元组合成业务对象
厨房类比	菜谱、配方、购物清单
关键特性	组合性——多个数据元按业务规则组合
SAP对应	表的一行记录、业务文档（订单、发票）

---

##✨ 七、四个概念的终极对比表

维度	元数据	数据元素	数据元	数据单元
一句话定义	数据的“语法规则”	数据元的“身份证”	最小数据原子	数据元的业务组合
厨房类比	菜谱上写的单位（个、克、勺）	食材定义卡（鸡蛋是什么）	3、鸡蛋、番茄	整道菜的配方
技术例子	数据库表结构、SE11里的对象定义	CDUSERNAME的定义	‘张三’	CDHDR表的一行
SAP对应	Data Dictionary	Data Element	字段的具体值	表记录、业务文档
粒度	规则层	定义层	原子层	组合层
复用性	全局	全局	不复用（每个值都不同）	不复用（每条记录都不同）
谁定义	架构师/顾问	数据建模师	业务用户输入	系统自动生成
变化频率	极低	低（偶尔调整）	高（随时变化）	高（随时增加）
修改影响	改错可能系统崩溃	改错可能影响多表	只影响当前数据	只影响当前记录

---

八、一个完整的SAP故事串联所有概念

场景：用户在公司用SAP创建一张采购订单

步骤1：元数据（规则层）
系统启动时加载数据字典，这里面包含了元数据：

• 采购订单表（EKKO）有哪些字段
• 每个字段叫什么（EBELN、BUKRS、LIFNR…）
• 每个字段什么类型（CHAR、NUMC…）
• 字段之间的关系（头表、行项表）

这些是系统的“骨架”，没有它们，你连输入界面都看不到。

步骤2：数据元素（定义层）
你点击创建按钮，系统调用数据元素来生成输入框：

• EBELN（采购订单号）这个数据元素说：我是CHAR类型，长度10，不能为空，业务含义是“采购凭证编号”
• BUKRS（公司代码）这个数据元素说：我是CHAR类型，长度4，必须存在于T001表
• MENGE（数量）这个数据元素说：我是QUAN类型，长度13，小数位3，必须关联单位

这些数据元素决定了输入框的格式和校验规则。

步骤3：数据元（原子层）
你在界面上输入数据：

• 订单号输入：4500012345（这是一个数据元）
• 公司代码输入：1000（这是一个数据元）
• 数量输入：100.000（这是一个数据元）
• 单位输入：PC（这是一个数据元）

每个输入都是一个数据元。

步骤4：数据单元（组合层）
你点击保存，系统把刚才输入的所有数据元组合成一个数据单元——也就是EKKO表里的一条完整记录。

这条记录包含了订单号、公司代码、供应商、采购组织、创建日期、总金额等信息。它被存储在数据库里，可以被其他程序（如收货、发票校验）使用。

---

九、踩坑总结：我见过最经典的5个“元”字坑

坑1：把“数据元素”当“数据元”改

场景：有同事发现CDUSERNAME的长度是12，但实际用户名有超过12位的，于是他直接去改了CDUSERNAME数据元素的长度。

后果：所有引用CDUSERNAME的字段都变成了20位，导致数据库表结构变更，SAP传输请求没处理好，生产环境打补丁时锁表半小时。

教训：改数据元素前，一定要用WHERE USED LIST查引用关系，评估影响。

坑2：把“元数据”当成普通数据

场景：有人用SE16直接修改了数据字典表（如TADIR）里的条目，想调整一个程序状态。

后果：程序无法激活，传输请求混乱，系统提示“对象不一致”。

教训：元数据只能通过标准事务代码（SE11、SE80）修改，不能直接改表。

坑3：混淆“字段”和“数据元”

场景：在建模时，有人说“我们在这个字段里存两个数据元”，然后就在一个CHAR字段里塞了两个值用分隔符拼起来。

后果：查询时无法用索引，业务逻辑复杂，后来数据量大了性能崩溃。

教训：一个字段应该对应一个数据元，保持原子性。

坑4：认为数据单元越大越好

场景：有人设计接口时，把整个销售订单头+行项+计划行+合作伙伴打包成一个数据单元，一个报文几十个表。

后果：接口响应慢，网络传输大，而且一旦一个数据出错整个报文失败。

教训：数据单元的粒度要符合业务场景，大粒度保证一致性，小粒度提升灵活性和性能。

坑5：不清楚数据元素的“域”和“数据元素”的关系

场景：有同事创建数据元素时，直接定义了数据类型和长度，跳过了域（Domain）。

后果：后来很多数据元素需要统一定义取值范围时，发现没法通过域统一控制，只能每个数据元素单独改。

教训：在SAP里，数据元素应该基于域，域负责技术属性（类型、长度、值范围），数据元素负责业务含义，这样才可复用。

---

十、一句话总结（初版）

如果你看完文章只记住一句话，那就记这句：

元数据是菜谱规则，数据元素是食材定义卡，数据元是食材本身，数据单元是一道完整的菜。

这四个概念层层递进，从宏观到微观，从定义到实例，共同构成了数据治理的基础。

---

十一、深入实战：SAP CDHDR/CDPOS表详细分析

为了让你更透彻地理解这些概念在实际系统中的应用，我们来拆解SAP里最经典的变更文档表：CDHDR（变更文档抬头） 和 CDPOS（变更文档行项）。

11.1 CDHDR表：变更文档的“封面”

CDHDR存储了每一次变更的头部信息，它告诉你“谁在什么时间、用什么程序，对哪个业务对象做了变更”。

下面是CDHDR表的关键字段（部分）：

字段名	数据元素	域	含义	厨房类比
MANDT	MANDT	MANDT	集团（客户端）	你开的哪家分店
OBJECTCLAS	OBJECTCLAS	OBJECTCLAS	对象类（如“EKKO”代表采购订单）	菜系（川菜、粤菜）
OBJECTID	OBJECTID	OBJECTID	对象实例的ID（如采购订单号）	具体是哪道菜（麻婆豆腐）
CHANGENR	CHANGENR	CHANGENR	变更文档编号（主键）	这道菜的“身份证号”
USERNAME	CDUSERNAME	USERNAME_DOM	修改人	谁做的菜
UDATE	CDDATUM	DATUM	修改日期	做菜的日期
UTIME	CDUZEIT	UZEIT	修改时间	做菜的时间
TCODE	CDTCODE	TCODE	事务代码（如ME21N）	用的什么灶台（煤气灶、电磁炉）
CHANGE_IND	CDCHNGINDH	CDCHNGINDH	变更类型（U=更新，I=插入，E=删除）	这道菜是新的还是改了

11.1.1 从CDHDR看数据元素和域的关系

以USERNAME字段为例，它绑定的数据元素是CDUSERNAME。我们进SE11查看CDUSERNAME的定义：

数据元素：CDUSERNAME
域：USERNAME_DOM
简短描述：修改文档的用户名

再查看域USERNAME_DOM的定义：

域：USERNAME_DOM
数据类型：CHAR
长度：12
值范围：无固定值表（但可以通过检查表关联）

这个结构体现了SAP的设计思想：域（Domain）负责技术属性（类型、长度、值范围），数据元素（Data Element）负责业务语义（字段标签、文档描述）。 多个数据元素可以共享同一个域。

11.1.2 实际例子：一条CDHDR记录

假设用户“张三”在2024年1月15日下午2:30，用事务代码SE11修改了采购订单号“4500012345”的抬头信息。CDHDR表会插入一条记录：

MANDT	OBJECTCLAS	OBJECTID	CHANGENR	USERNAME	UDATE	UTIME	TCODE	CHANGE_IND
100	EKKO	4500012345	0000001234	张三	20240115	143000	SE11	U

• MANDT=100：集团100
• OBJECTCLAS=EKKO：采购订单对象类
• OBJECTID=4500012345：具体的采购订单号
• CHANGENR=0000001234：这次变更的文档号
• USERNAME=张三：修改人（数据元）
• UDATE=20240115：修改日期（数据元）
• UTIME=143000：修改时间（数据元）
• TCODE=SE11：用的事务码（数据元）
• CHANGE_IND=U：更新操作（数据元）

这条记录本身就是一个数据单元，它描述了“一次完整的变更操作”的头部信息。

11.2 CDPOS表：变更文档的“内页”

CDPOS存储了具体的字段级变更内容，它告诉你“哪个字段、从什么值变成了什么值”。

CDPOS表的关键字段（部分）：

字段名	数据元素	含义	厨房类比
MANDT	MANDT	集团	哪家分店
OBJECTCLAS	OBJECTCLAS	对象类	菜系
OBJECTID	OBJECTID	对象实例ID	具体菜名
CHANGENR	CHANGENR	变更文档编号（关联CDHDR）	身份证号
TABNAME	TABNAME	表名（如“EKKO”）	食材清单类别（肉类、蔬菜）
TABKEY	TABKEY	表主键（如采购订单号）	具体食材
FNAME	FIELDNAME	字段名（如“LIFNR”）	食材属性（供应商）
VALUE_NEW	CDVALUE	新值	新的数量/名称
VALUE_OLD	CDVALUE	旧值	旧的数量/名称
CHNGIND	CDCHNGIND	变更类型（U/I/E）	是加菜还是换菜

11.2.1 实际例子：两条CDPOS记录

延续上面的例子，用户张三修改了采购订单的供应商（LIFNR） 和采购组织（EKORG）。系统会在CDPOS表插入两条记录：

记录1：供应商变更

CHANGENR	TABNAME	TABKEY	FNAME	VALUE_OLD	VALUE_NEW	CHNGIND
0000001234	EKKO	4500012345	LIFNR	1000001	1000002	U

记录2：采购组织变更

CHANGENR	TABNAME	TABKEY	FNAME	VALUE_OLD	VALUE_NEW	CHNGIND
0000001234	EKKO	4500012345	EKORG	1000	2000	U

每一条CDPOS记录也是一个数据单元，它描述了一个字段的单次变更详情。

11.2.2 CDPOS中“数据元”的体现

在CDPOS中：

• VALUE_OLD 和 VALUE_NEW 字段存的就是数据元（具体的旧值和新值）
• 这些字段绑定的数据元素是CDVALUE，而CDVALUE域是CHAR254（长度254的字符），能容纳各种类型的数据

11.3 CDHDR + CDPOS：完整的数据单元组合

如果把CDHDR的一条记录和它关联的N条CDPOS记录组合在一起，就构成了一个更大粒度的数据单元——一个完整的变更文档。

这个“变更文档”包含了：

• 头部信息（谁、何时、哪个对象）
• 明细信息（改了哪些字段、从什么改成什么）

在SAP里，你可以通过事务代码SCU3或SE16直接查看变更文档，也可以通过CHANGEDOCUMENT_READ_HEADERS和CHANGEDOCUMENT_READ_POSITIONS函数读取。

11.4 从CDHDR/CDPOS看数据治理

这两个表是SAP数据治理的核心组件，它们展示了：

• 元数据：表结构、数据元素、域的定义（SE11中查看）
• 数据元素：CDUSERNAME、CDVALUE等定义模板
• 数据元：具体的用户名、日期、旧值、新值
• 数据单元：一条CDHDR记录 + 多条CDPOS记录 = 一个完整的变更文档

如果你在做数据审计、数据追溯或数据合规，CDHDR/CDPOS就是你的“数据显微镜”。

---

十二、数据元素与域的深入对比（技术层面）

12.1 什么是域（Domain）？

在SAP数据字典中，域是比数据元素更低一层的技术对象。它定义了：

• 数据类型：CHAR、NUMC、DEC、INT等
• 长度：字段的长度（如12）
• 小数位：如果是DEC类型，小数位数
• 值范围：允许的值的集合（通过固定值表或检查表）

域是纯技术属性的容器，它不关心业务含义。

12.2 数据元素 vs 域：类比理解

概念	厨房类比	说明
域	“克”这个计量单位	定义了重量怎么表示：数值范围0-9999，小数位2，单位是克
数据元素	“鸡蛋”这个食材定义	业务上：“鸡蛋”使用“克”为单位，标准重量50克/个

一个域可以被多个数据元素复用：

• 域QUAN_13_3：定义数量类型，13位总长，3位小数
• 数据元素MENGE（数量）→ 使用QUAN_13_3域
• 数据元素BSTMG（采购数量）→ 也使用QUAN_13_3域

12.3 技术层面的域配置

在SE11创建一个域时，你需要填写：

属性	示例	说明
域	MENGE_DOM	域名
数据类型	QUAN	数量类型
长度	13	总长度
小数位	3	3位小数
输出长度	16	显示时的长度
值表	无	可以是固定值或值表
检查表	无	可以关联一个表进行值校验

值表（Value Table）：如果勾选了“值表”，并且填了一个表名（如T006单位表），系统会强制该域的所有字段只能从该表中取值。

固定值（Fixed Values）：你可以直接在域里定义允许的值列表，例如：

固定值	描述
X	是
空	否

12.4 数据元素基于域：业务语义注入

数据元素在域的基础上增加了业务语义：

属性	示例	说明
数据元素	MENGE	数据元素名
域	MENGE_DOM	引用域
字段标签	数量	在屏幕上的显示文本
文档描述	采购订单数量	业务含义说明
参数ID	无	可以用于内存参数传递

12.5 为什么要分离域和数据元素？

分离的好处：

1. 技术复用：多个数据元素可以共享同一个域，统一技术规范（长度、类型、值范围）
2. 业务独立：数据元素可以独立地赋予业务含义，而不互相影响
3. 维护简化：需要调整技术属性时，只改域；需要调整业务标签时，只改数据元素

实际场景：

• 你要把“数量”字段的默认长度从13位改成17位
• 如果直接改域QUAN_13_3，所有使用该域的数据元素（MENGE、BSTMG、MENGE_D等）自动生效
• 如果每个数据元素都单独定义技术属性，你就要改几十个地方，很容易漏掉

12.6 域的高级功能：检查表和值表

检查表（Check Table）：域可以关联一个检查表，系统会检查字段值是否存在于该表的某个字段中。例如：

• 域LAND1_DOM关联检查表T005（国家表）
• 所有使用该域的数据元素（如LAND1）输入的必须是T005中存在的国家代码

值表（Value Table）：类似于检查表，但更严格，常用于外键关联。

在CDHDR表的TCODE字段，数据元素CDTCODE引用的域TCODE就关联了检查表TSTC（事务代码表），确保用户输入的事务代码必须在系统中存在。

12.7 对比总结表

维度	域	数据元素
作用	定义技术属性（类型、长度、值范围）	定义业务属性（含义、标签、文档）
厨房类比	计量单位（克、个、毫升）	食材定义卡（鸡蛋、番茄）
复用范围	可以被多个数据元素复用	可以被多个表字段复用
是否可独立使用	不可直接用于表字段，必须通过数据元素	可直接用于表字段
是否可带业务含义	否	是
变更影响	影响所有引用的数据元素	影响所有引用的表字段
SAP事务码	SE11 创建域	SE11 创建数据元素

---

十三、数据元标准化的ISO/IEC 11179规范简介

13.1 什么是ISO/IEC 11179？

ISO/IEC 11179是数据元注册和管理的国际标准。它定义了一套方法论，用于标准化数据元的定义、命名、注册和维护。

简单说，它教你如何创建“全世界通用的数据元”。

13.2 厨房类比理解ISO 11179

假设全世界厨师要统一食材标准：

• 番茄：必须定义清楚“番茄”是什么（植物学分类、颜色、大小）
• 计量：统一用“克”而不是“个”
• 命名：只能用“番茄”不能叫“西红柿”
• 注册：所有标准食材要存在一个“全球食材库”里，编号唯一

ISO 11179就是这套“全球食材标准化”的规则。

13.3 ISO 11179的六大核心部分

部分	内容	厨房类比
第1部分：框架	整体结构和概念	标准化工作的总体思路
第2部分：分类	数据元如何分类	食材分类（蔬菜、肉类、调料）
第3部分：注册	注册数据元的过程	把食材录入全球库的流程
第4部分：定义	如何编写数据元的定义	食材定义怎么写才规范
第5部分：命名和标识	命名规则和唯一标识	食材的学名和编号
第6部分：管理	维护和变更管理	食材标准更新流程

13.4 数据元的标准属性（ISO 11179）

根据ISO 11179，一个数据元应该包含以下属性：

属性	说明	示例
标识符	唯一ID	DE-001234
名称	数据元的名称	采购订单号
定义	明确的业务含义	用于唯一标识采购订单的编号
数据类型	技术类型	CHAR
长度	长度	10
值域	允许的取值范围	数字+字母，首位不能是0
对象类	属于哪个业务对象	采购订单
特性	描述对象类的哪个属性	订单号
表示词	数据元的表现形式	标识符

13.5 数据元命名规则（ISO 11179）

标准推荐的数据元命名结构是：

[对象类词] + [特性词] + [表示词]

例如：

• 采购订单号：对象类=采购订单，特性=订单号，表示词=标识符
• 员工姓名：对象类=员工，特性=姓名，表示词=文本

厨房类比：

• 番茄重量：对象类=番茄，特性=重量，表示词=数值

13.6 为什么需要ISO 11179？

在企业数据治理中，如果没有标准化：

• 同一个数据元在不同部门有不同名称（“客户ID” vs “客户编号”）
• 同一个名称在不同系统代表不同含义（“金额”在财务系统是含税，在销售系统是不含税）
• 数据元没有唯一标识，难以跨系统共享

ISO 11179提供了一套通用的语言，让数据元可以在企业内外被准确理解和使用。

13.7 ISO 11179在SAP中的应用

SAP的数据字典虽然没有完全遵循ISO 11179，但很多思想是相通的：

• 数据元素 ≈ ISO中的数据元
• 域 ≈ ISO中的值域
• 数据元素文档 ≈ ISO中的定义
• 数据元素的命名（如CDUSERNAME）遵循SAP内部命名规范

如果你要在SAP里实现ISO 11179标准，可以通过数据治理工具（如SAP Data Services、SAP Information Steward）来管理数据元的注册和发布。

---

十四、数据治理中如何落地这些概念

14.1 从概念到实践：数据治理的三个层次

层次	核心任务	涉及的概念
元数据管理	管理数据字典、表结构、业务术语	元数据、数据元素
主数据管理	统一核心业务实体（客户、产品、供应商）	数据单元
数据质量管理	监控数据的准确性、完整性、一致性	数据元

14.2 数据资产目录：让数据“看得见”

数据资产目录是企业所有数据资产的“图书馆”，它记录了：

• 元数据：有哪些表、字段、视图
• 数据元素：每个字段的业务含义、数据质量规则
• 数据元：字段的取值示例、分布情况
• 数据单元：业务对象（客户、订单）的完整定义

厨房类比：

• 数据资产目录 = 你的“厨房百科全书”
• 记录每种食材（数据元素）、每个菜品配方（数据单元）、每个烹饪工具（元数据）

14.2.1 常见数据资产目录工具

工具	类型	特点
Collibra	商业	功能全面，适合大型企业
Alation	商业	用户友好，数据搜索强
Informatica Enterprise Data Catalog	商业	元数据采集能力强
Apache Atlas	开源	Hadoop生态，适合大数据平台
Amundsen	开源	Lyft开源，搜索体验好
SAP Information Steward	SAP生态	与SAP系统深度集成

14.3 元数据管理平台：让数据“管得住”

元数据管理平台负责采集、存储、分析、发布元数据。它通常包含：

• 元数据采集器：自动抓取数据库、ETL工具、BI工具中的元数据
• 元数据存储库：集中存储技术元数据、业务元数据、操作元数据
• 元数据血缘分析：展示数据从哪里来、到哪里去
• 元数据影响分析：修改一个字段会影响哪些下游

实战场景：你打算修改CDHDR表的USERNAME字段长度从12到20。在元数据平台里，你可以：

1. 影响分析：查看哪些程序、报表、接口使用了这个字段
2. 沟通通知：通知所有相关方评估影响
3. 变更执行：在SAP里修改数据元素和域
4. 验证测试：检查所有下游系统是否正常

如果没有元数据管理平台，你可能要手动翻代码、查文档，漏掉一处就可能导致生产事故。

14.4 数据治理落地步骤（实战版）

步骤1：识别核心数据元

召集业务和IT，确定企业核心数据元清单。例如：

• 客户ID
• 产品编码
• 订单金额
• 供应商税号

为每个数据元分配唯一标识符，参考ISO 11179。

步骤2：统一数据元素定义

为每个数据元创建标准化的数据元素，包括：

• 名称（统一命名规则）
• 定义（用业务语言描述）
• 技术属性（数据类型、长度、取值范围）
• 来源系统（哪个系统是黄金源）
• 数据质量规则（非空、唯一、值域）

步骤3：构建数据资产目录

将元数据、数据元素、数据单元导入数据资产目录，确保：

• 业务用户可以搜索和浏览
• 技术用户可以查看技术属性
• 数据管理者可以维护和更新

步骤4：建立变更管理流程

任何数据元素的变更都要经过评审，包括：

• 提交变更申请
• 影响分析
• 审批
• 实施
• 通知下游

步骤5：持续监控数据质量

基于数据元素的质量规则，定期监控数据元的准确性、完整性、一致性。例如：

• 客户ID是否重复
• 订单金额是否在合理范围内
• 供应商税号是否符合格式

14.5 避坑指南：数据治理落地中的“坑”

坑1：上来就搞大平台

• 场景：花几百万采购数据治理平台，但基础数据元都没梳理清楚
• 教训：先标准化，后工具化。从Excel开始梳理核心数据元，再引入工具。

坑2：IT自嗨，业务不参与

• 场景：数据团队闭门造车，定义了一堆数据元，业务部门根本不认
• 教训：数据元定义必须业务主导，IT负责技术落地。

坑3：元数据采集不全

• 场景：只采集了数据库的元数据，忽略了ETL脚本、BI报表中的逻辑
• 教训：数据血缘要覆盖全链路，才能做准确的影响分析。

坑4：变更管理形同虚设

• 场景：数据元素改了，但没通知下游，导致报表出错
• 教训：建立强制性的变更流程，元数据平台自动发送影响分析报告。

---

十五、终极总结

15.1 一张图总结四大概念（文字版）

元数据（菜谱规则）
   ↓ 定义
数据元素（食材定义卡）
   ↓ 实例化
数据元（具体的食材：3、鸡蛋）
   ↓ 组合
数据单元（一道完整的菜：番茄炒蛋）

15.2 一句话记住它们

元数据是菜谱规则，数据元素是食材定义卡，数据元是食材本身，数据单元是一道完整的菜。

15.3 从厨房到数据治理

在厨房里：

• 元数据：计量单位（克、个、勺）
• 数据元素：食材定义（鸡蛋、番茄）
• 数据元：具体数值（3、200、5）
• 数据单元：菜品（番茄炒蛋）

在SAP里：

• 元数据：SE11里的表、域、数据元素定义
• 数据元素：CDUSERNAME、MENGE
• 数据元：‘张三’、100.000
• 数据单元：CDHDR表的一条记录，或一个采购订单

在国际标准中：

• ISO 11179告诉你如何定义数据元
• 数据资产目录帮你管理数据元
• 元数据平台帮你掌控数据血缘

---

你在学习SAP或数据治理时，有没有被这些“元”字辈概念绕晕过？欢迎在评论区分享你的“懵圈经历”。
如果你觉得这篇文章帮到了你，别忘了点赞+收藏，让更多小伙伴少走弯路。

---