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

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

文章目录

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

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

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

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

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

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

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

在这里插入图片描述

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

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

在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表里，每一行记录就是一个数据单元：

USERNAMEUDATEUTIMETCODECHANGE IND
张三2024-01-1514:30:00SE11U
李四2024-01-1515:20:00SE38I

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

6.3 数据单元 vs 数据元

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

6.4 小结

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

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

维度元数据数据元素数据元数据单元
一句话定义数据的“语法规则”数据元的“身份证”最小数据原子数据元的业务组合
厨房类比菜谱上写的单位（个、克、勺）食材定义卡（鸡蛋是什么）3、鸡蛋、番茄整道菜的配方
技术例子数据库表结构、SE11里的对象定义CDUSERNAME的定义‘张三’CDHDR表的一行
SAP对应Data DictionaryData 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表的关键字段（部分）：

字段名数据元素域含义厨房类比
MANDTMANDTMANDT集团（客户端）你开的哪家分店
OBJECTCLASOBJECTCLASOBJECTCLAS对象类（如“EKKO”代表采购订单）菜系（川菜、粤菜）
OBJECTIDOBJECTIDOBJECTID对象实例的ID（如采购订单号）具体是哪道菜（麻婆豆腐）
CHANGENRCHANGENRCHANGENR变更文档编号（主键）这道菜的“身份证号”
USERNAMECDUSERNAMEUSERNAME_DOM修改人谁做的菜
UDATECDDATUMDATUM修改日期做菜的日期
UTIMECDUZEITUZEIT修改时间做菜的时间
TCODECDTCODETCODE事务代码（如ME21N）用的什么灶台（煤气灶、电磁炉）
CHANGE_INDCDCHNGINDHCDCHNGINDH变更类型（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表会插入一条记录：

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

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

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

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

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

字段名数据元素含义厨房类比
MANDTMANDT集团哪家分店
OBJECTCLASOBJECTCLAS对象类菜系
OBJECTIDOBJECTID对象实例ID具体菜名
CHANGENRCHANGENR变更文档编号（关联CDHDR）身份证号
TABNAMETABNAME表名（如“EKKO”）食材清单类别（肉类、蔬菜）
TABKEYTABKEY表主键（如采购订单号）具体食材
FNAMEFIELDNAME字段名（如“LIFNR”）食材属性（供应商）
VALUE_NEWCDVALUE新值新的数量/名称
VALUE_OLDCDVALUE旧值旧的数量/名称
CHNGINDCDCHNGIND变更类型（U/I/E）是加菜还是换菜
11.2.1 实际例子：两条CDPOS记录

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

记录1：供应商变更

CHANGENRTABNAMETABKEYFNAMEVALUE_OLDVALUE_NEWCHNGIND
0000001234EKKO4500012345LIFNR10000011000002U

记录2：采购组织变更

CHANGENRTABNAMETABKEYFNAMEVALUE_OLDVALUE_NEWCHNGIND
0000001234EKKO4500012345EKORG10002000U

每一条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总长度
小数位33位小数
输出长度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，一个数据元应该包含以下属性：

属性说明示例
标识符唯一IDDE-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 StewardSAP生态与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或数据治理时，有没有被这些“元”字辈概念绕晕过？欢迎在评论区分享你的“懵圈经历”。
如果你觉得这篇文章帮到了你，别忘了点赞+收藏，让更多小伙伴少走弯路。

# 大数据
Logo
腾讯云开发者社区

腾讯云面向开发者汇聚海量精品云计算使用和开发经验，营造开放的云计算技术生态圈。

更多推荐

Elasticsearch复杂数据类型终极指南：从入门到精通

Elasticsearch作为功能强大的搜索引擎，支持多种复杂数据类型，让开发者能够灵活处理各种结构化和非结构化数据。本文将带你全面了解Elasticsearch中的复杂数据类型，从基础概念到实际应用，助你轻松掌握数据建模的核心技巧。## 内部对象：构建层级化数据结构在Elasticsearch中，对象类型（Object）是最基础的复杂数据类型之一，用于表示具有嵌套关系的数据。例如，我们可

avatar 腾讯云开发者社区

终极指南：Flink SQL连接器版本管理从混乱到有序的升级之路

Apache Flink作为流处理领域的佼佼者，其SQL连接器的版本管理一直是开发者面临的核心挑战。本文将系统讲解Flink SQL连接器版本管理的最佳实践，帮助你轻松应对版本兼容性问题，实现从混乱到有序的升级之旅。## 连接器版本管理的常见痛点 😫在Flink应用开发中，连接器版本管理常常让开发者头疼不已。不同版本的连接器可能导致各种兼容性问题，例如API变更、功能差异甚至运行时错误。

avatar 腾讯云开发者社区

如何快速搭建Neon无服务器PostgreSQL：面向初学者的完整指南

Neon是一款革命性的无服务器PostgreSQL解决方案，它通过分离存储和计算层，实现了自动扩缩容、类代码式数据库分支以及零级扩展能力。本指南将帮助你从零开始搭建Neon开发环境，体验这款创新数据库的强大功能。## 准备工作：环境要求与依赖项在开始搭建Neon环境前，请确保你的系统满足以下要求：- Linux操作系统（推荐Ubuntu 20.04+或Debian 11+）- Git

avatar 腾讯云开发者社区