数据字典

数据字典是对数据及其结构作系统说明的元数据集合。它通常描述数据库、文件、消息或数据集中的对象如何命名、组织、表示和关联，并可附上业务解释、责任信息或维护规则。字典说明的是数据本身及其约定，而不是记录中的业务事实：描述“订单金额以何种币种、精度和规则保存”，属于字典内容；某笔订单的实际金额则是业务数据。

“数据字典”并非在所有行业和产品中都指同一种软件或固定格式。数据库文献常用它指数据库管理系统维护的系统目录；建模、应用开发与数据治理场景，也常以它指由团队编制、供人查阅的结构说明书；企业还可能把多个系统的元数据集中登记，形成元数据注册库或数据目录。三者可以互相交换信息，却在范围、维护者和用途上不同。谈论某个字典时，宜先说明它描述的是单个数据库、某类文件，还是跨系统的企业数据资产。

关系数据库需要知道有哪些表、列、类型、约束和用户权限，才能解析查询、执行定义变更并提供管理功能。数据库因此在内部保存关于对象的元数据，并通过可查询的视图或目录接口呈现。Oracle 文档将其数据字典描述为包含模式对象定义、列默认值、完整性约束、用户和权限等信息的一组只读视图；用户通过这些视图查询，而不是直接改写底层字典表。PostgreSQL 将同类内部对象称为系统目录，其中既有表和列的信息，也有类型、函数、约束等目录，且其系统目录在实现上是数据库表。

系统目录由数据库软件维护，准确反映该产品当前所管理对象的结构，适合管理工具、迁移程序或检查脚本读取。它不一定包含业务人员期望的全部解释，例如某个字段为何存在、报表口径是否已获认可、敏感等级如何判定。人工维护的字典文档可补足这些内容，但如果要靠人同步更新，就可能落后于实际结构。较成熟的做法是把可从系统读取的技术属性自动采集，同时让业务定义、负责人、质量规则等信息有明确维护流程，并标明各项说明的来源与更新时间。

字典可以按层次说明数据。数据集或表层记录对象名称、所在库与模式、用途、负责人、存储或更新说明；列或字段层记录稳定名称、显示名称、含义、数据类型、长度或精度、是否可空、默认值、编码或格式；关系层记录主键、唯一约束、外键、检查条件以及关联到的对象。若把字典用于分析或治理，还可注明业务口径、允许值、例外处理、来源系统、转换过程、质量检测和分类级别。具体字段取决于对象类型和使用目标，不存在一份所有系统都必须采用的通用清单。

类型名称背后有实际约束。整数与定点小数对可表示的值域不同；字符列的长度、编码和排序规则影响存储与比较；可空性不能简单等同“未知”或“尚未发生”；日期时间还涉及时区和精度。若字典只写“金额”或“日期”，不同程序便可能分别按元和分、当地时间和协调世界时解释，造成汇总差异。良好的条目通常把含义、表示方式、边界规则和适用场景写清，避免仅复制字段名或技术类型。

一个假设的线上书店可以用订单表说明这些层次。订单号可能是非空唯一键；客户号可能引用客户表；成交金额可能是定点小数，且非负；币种可能采用三位代码。字典应另外说明金额是下单时的商品与运费合计还是扣除优惠后的实付额，退款是否单独记录，以及币种代码遵循哪套约定。上述规则是为说明概念而设的假设示例，并不代表某个真实商店的设计。技术约束只能保证部分要求，例如非负检查不能独自证明退款和折扣口径正确，后者仍需业务规则和数据验证。

文件与交换接口也可以有字典。逗号分隔文件本身只给出行列文本，标题行和样例值未必能表达某列究竟是日期、金额还是代码。W3C 的表格元数据规范允许用结构化元数据描述表、列标题、数据类型、格式和列间外键关系，处理程序可据此解析或验证数据。比如每日导出的订单 CSV，可声明订单号与客户号列的语义、日期格式，并说明客户号关联客户表的主键。此类模式说明不等于 CSV 内嵌数据库约束；若实际文件未按模式校验，错误值仍可能存在。

SQL 的 INFORMATION_SCHEMA 为查询数据库对象信息提供一组标准化视图。PostgreSQL 文档指出，这些视图依据 SQL 标准，通常比特定于 PostgreSQL 的系统目录更便于移植且较稳定；但产品专属特性可能不在其中，因此需要读取本地系统目录或其他视图。SQL Server 也提供符合 ISO 定义的 INFORMATION_SCHEMA 视图，同时提供更完整、面向引擎实现的系统目录视图。换言之，标准接口适合常见对象的跨产品访问，却不能被理解为覆盖一切元数据。

不同产品的内部目录名称、列、权限规则和版本演进并不相同。Oracle 文档举出 USER_、ALL_ 与 DBA_ 视图：它们大致分别呈现当前用户模式、该用户有权查看的信息和全库信息，后者仅对具备相应管理权限者开放。PostgreSQL 则区分标准信息模式视图与产品专属系统目录。SQL Server 说明元数据可见范围受对象所有权或已授予权限影响，且信息模式视图只反映对象元数据的一个子集。跨库采集时，不能把一个产品中的视图结构、可见范围或命名假定为另一个产品也适用。

数据库字典也不同于业务术语表。术语表着重定义“客户”“活跃用户”或“收入”等组织共识，通常描述概念和口径，不要求它一定对应某一张表或一个物理列；数据字典通常落到可识别的数据对象，并记录其结构。数据目录则多以发现和访问资产为目标，把字典、所有者、标签、血缘、质量状态等信息组织成可检索清单。元数据注册库侧重按明确模型登记元数据、标识和管理规则。边界会因产品而重叠，关键是分别看它们要解决的问题，而非只凭名称判断。

数据字典的可信度取决于内容是否准确、覆盖是否足够、术语是否一致，以及是否与实际数据同步。自动采集可从数据库接口取得表、列、类型、约束和某些依赖关系，减少结构说明的遗漏；但机器通常无法仅由列名推断准确业务含义。人工补充不宜成为无主的自由文本：可为条目指定业务责任人和技术责任人，约定命名、释义、单位、枚举值和日期格式，并在架构变更、业务口径调整或源系统替换时复核。

变更应尽量可追溯。删除或改名字段、改变小数精度、放宽空值条件，都可能影响报表、接口、训练数据或下游表。变更记录可以注明生效时间、旧新定义、兼容办法、受影响对象和批准责任；在自动化流水线中，还可以比较部署前后的模式并执行契约测试。字典本身也要经过质量检查，例如必填属性是否缺失，外键说明是否与实际约束一致，枚举和值域是否相互匹配，过期条目是否有复核日期。对关键指标，应把描述与计算逻辑、时间窗口和排除规则一起版本化。

使用者还需辨清“声明的结构”与“实际内容”之间的距离。一个字段被声明为整数，不等于历史数据没有越界或应用没有把空值编码为零；描述写着“必填”，也不一定意味着所有入口都强制验证。系统目录反映数据库登记和配置的状态，质量画像或抽样分析才回答数据值本身是否符合预期。字典可以指出应如何检查，却不能代替检查结果。

对开发者而言，字典可帮助理解陌生模式、编写查询、生成接口文档和审查变更；对数据库管理员而言，目录信息可用于盘点对象、核对权限、定位依赖和分析存储；对分析人员而言，清晰的字段定义与指标口径有助于减少重复计算和表间误配；对治理团队而言，责任人、分类、保留期限和来源说明有助于盘点资产并支持控制措施。价值来自元数据与真实工作流相连，而不只是把字段清单写得更长。

字典本身也可能包含敏感信息。表名、字段注释、权限描述、存储位置和血缘关系会暴露系统结构；安全缺陷记录或个人信息字段清单还可能揭示风险。因此，字典的访问权限应与其记录的信息相匹配，尤其是跨系统汇总后，不应因“只是元数据”而默认公开。复制或导出时也要注意版本、权限和数据保留要求。

总之，数据字典是关于数据的结构化说明，其技术形式可以是数据库目录视图、模式文件、设计文档或企业元数据登记服务。判断一个字典是否有用，应看它是否适合目标用户，能否解释对象含义与约束，能否及时反映变化，并明确哪些内容由系统采集、哪些需要业务治理。它让数据更易被理解和管理，但不能单独保证数据正确、口径一致或访问安全。