元数据模型：实体-关系模型、属性定义与元数据标准

聊元数据，绕不开一个核心问题：怎么把元数据组织起来，让它能被机器读懂、被人用明白？

我个人习惯把元数据模型比作「乐高图纸」。图纸本身不是积木，但它规定了每块积木长什么样、能跟谁拼在一起。没有这张图纸，你手里的积木再多也是一堆散件。

这一章，我们就来拆解这张图纸的核心构件。

实体-关系模型：元数据的骨架

实体-关系模型，简称 E-R 模型。说白了，就是画一张图，把「有什么东西」和「这些东西怎么关联」说清楚。

我在项目中遇到过不少团队，一上来就急着填元数据，结果填到一半发现「这个字段到底属于哪个表？」「那个数据集的负责人是谁？」——全乱套了。根源就是没先画好 E-R 图。

实体（Entity）

实体就是你要描述的那个「东西」。在元数据的世界里，常见的实体有：

• 数据集（Data Set）—— 一张表、一个文件、一个 API 接口
• 字段（Field / Column）—— 表里的某一列
• 数据源（Data Source）—— 数据库、数据湖、外部系统
• 数据所有者（Data Owner）—— 负责这个数据的人或团队
• 数据质量规则（Quality Rule）—— 比如「年龄不能为负」

每个实体都有一个唯一的标识符，我习惯叫它「实体 ID」。这个 ID 在系统内部用来关联所有信息。

关系（Relationship）

实体之间怎么连？常见的关系类型就三种：

属性定义：给元数据「填肉」

实体和关系搭好了骨架，接下来就是填肉——属性定义。

每个实体都有属性。比如「数据集」这个实体，它的属性可能包括：

• 名称（Name）
• 描述（Description）
• 创建时间（Created At）
• 更新频率（Update Frequency）
• 数据量级（Data Volume）

定义属性时，我建议你问自己三个问题：

1. 这个属性是必需的还是可选的？ —— 比如「名称」必须填，「描述」可以空着。
2. 这个属性的数据类型是什么？ —— 字符串、整数、日期、枚举？
3. 这个属性有没有取值范围？ —— 比如「更新频率」只能取「每日」「每周」「每月」。

元数据标准：让不同系统说同一种语言

你想想看，如果 A 系统把「创建时间」叫 create_time，B 系统叫 createdAt，C 系统叫 crt_dt——那数据目录怎么统一管理？

这就是元数据标准要解决的问题。我重点讲两个最常用的标准。

Dublin Core：轻量级元数据标准

Dublin Core 起源于图书馆界，后来被广泛用于数字资源描述。它只有 15 个核心元素，非常轻量。

ISO 11179：企业级元数据标准

ISO 11179 就重多了。它是一整套关于「如何定义和管理元数据」的国际标准。核心概念包括：

• 数据元素（Data Element）—— 最基本的元数据单元，比如「客户年龄」
• 数据元素概念（Data Element Concept）—— 抽象的业务概念，比如「年龄」
• 值域（Value Domain）—— 允许的取值范围，比如「0-150」
• 表示（Representation）—— 数据类型、长度、格式

ISO 11179 强调元数据的注册与复用。什么意思呢？就是你在一个地方定义好「客户年龄」这个数据元素，所有系统都引用这个定义，而不是各自再定义一遍。

知识体系总览

下面这张图，把本章的核心知识点串在了一起。你可以把它当作一个「元数据模型速查地图」。

实战：用 E-R 模型描述一个数据目录

光说不练假把式。我们拿一个真实场景来走一遍。

假设你要为一个电商平台搭建数据目录。核心实体有哪些？

• 数据集（Data Set）—— 比如「订单表」「用户表」「商品表」
• 字段（Field）—— 每个表里的列
• 数据源（Data Source）—— 比如 MySQL 实例、Hive 表空间
• 数据所有者（Data Owner）—— 比如「交易团队」「用户增长团队」

它们之间的关系：

• 一个数据源包含多个数据集（1:N）
• 一个数据集包含多个字段（1:N）
• 一个数据集有一个数据所有者（N:1）

然后给每个实体定义属性。以「数据集」为例：