一 什么是数据字典数据字典提供了从数据库创建相关业务报告所需的组成和步骤。UCMerced图书馆在“什么是数据字典”的说明中定义：数据字典是“数据库中使用或捕获的元素的名称、定义和属性的集合”。在用户实时输入、编辑和删除数据时，描述数据库的数组需要提供指导。数据库管理员可能要处理流动数据。Gartner的IT Glossary定义的活动数据字典提供了“存储动态可访问和可修改信息的工具”。

国际标准组织(ISO)在《理解数据字典》一书中提出了三个类别:业务概念、数据类型和消息概念。业务概念定义了一个业务元数据层，Zaino将其描述为“人们将在业务术语中访问的物理数据的定义”。数据类型描述被认为有效的数据元素的格式。消息概念是组织间的一种共享理解，以确保业务通信在相同的上下文中。这三个数据字典项:业务概念、数据类型和消息概念相互关联。二 数据字典的优点

数据字典帮助改变成为可能。这样可以节省更多的时间来分析数据的含义以及数据之间的相互关系。数据字典的优点包括:

•词汇的一致使用:有意义的信息需要关于词汇如何使用和上下文理解的说明。例如，“contact”数据元素。在大学的企业关系办公室里，联系人可能是指一个私人公司里愿意资助大学研究和奖学金的人。对于招生部门，“contact”数据元素由学生的父母或校友组成。对于刚被聘为行政助理的人来说，“contact”数据元素可能意味着他或她给他或她打过电话或发过邮件的人。如果没有明确的定义，在数据字典中，输入的数据可以采用任何一种含义。

•有价值的报告:密歇根大学信息和技术服务中心所说，“如果您不了解数据的结构、表之间的链接以及要使用的BusinessObjects文件夹，那么您的报告结果可能是不正确的。”增加了在动态环境中生成报告的需求，数据字典就变得必不可少了。

•更容易的数据文档管理:使一个数据字典响应变化只需要简单地使用文字处理程序或纸笔。Blaha在文档化数据模型中指出，数据字典可以很容易地打印出来。这样的资源“很容易接收，并且不需要建模工具技能。不需要工具成本，也不需要访问这些信息的特殊软件。

•更平滑的数据库升级:与Windows操作系统一样，Oracle等数据库软件也需要定期升级。要做到这一点，数据字典是至关重要的，它是程序的一个内置方面。例如，Oracle Financial Services analysis Applications (OFSAA)和Oracle Financial Services Data Foundation (OFSDF)详细说明了如何生成数据字典文档，“以解释Oracle站点特定的变化以及发布特定的变化”。

•更有意义的元数据:要获得可访问的数据，需要“适当地收集和存储”。元数据提供关于“一组数据的上下文、内容、质量、来源或可访问性”的信息。数据字典提供了一个集中的位置来描述关于数据库的元数据。

三 现实中数据字典的替代品

数据字典确实有一些缺点。首先，对于企业来说，维护和使用全面的数据字典既费时又麻烦。例如，客户为了下订单而学习元数据会很不方便。同样，业务分析人员在紧迫的最后期限下可能没有时间更新或查阅数据字典文档。启动环境可能不具备启动数据字典所需的信息。考虑以下数据字典的替代方案:

•表格和报告中的标题和提示:根据需要定义数据元素。例如，看一个典型电子商务网站的Address部分。一个“选择”标题，按省或市，指示用户从下拉列表中选择。选项只包括特定的菜单选项，这取决于所选的特定城市。这可以防止客户输入错误的数据，并保持数据的一致性。如果业务分析师需要报告来自特定状态的收入，可以使用类似的提示和下拉框。这种口头提示可以与其他数据元素一起使用，以保持业务元素的一致性。

•用户事例:在敏捷开发中，用户事例是创建新产品或更新产品(包括数据库)的基础。“用户事例是一种工件，描述了一个为了一个特定的目的想要做一个特定的操作。它还指定了显示或测量需要哪些步骤。”

当项目经理和参与者讨论程序的功能和客户的需求时，他们根据业务上下文、格式和消息定义数据元素。向事例添加关于需要在数据库中捕获或使用的内容的细节，并使用户事例集合可根据业务上下文进行搜索，以供未来的使用。这样，创建对数据元素的共同理解和词汇表的目标与敏捷开发过程中的目标同时发生。

虽然标题、提示或用户事例可以立即解决定义数据库的问题，但随着时间的推移，企业成长，数据库发展可能不是一个很好的长期策略。此外，报告业务联系人如何使业务受益所需的数据元素也变得模糊和复杂。由于需要额外的时间来构建数据字典，因此可以尽早进行澄清。

四 数据字典的构建步骤

数据字典是带有定义的关键术语和度量的列表，即业务术语表。虽然它听起来简单，几乎微不足道，但是他对调整业务和消除混乱的能力可能是深远的。事实上，数据字典可能是数据团队可以交付给业务的最有价值的构件之一。

大多数业务至少有一个概念、术语或度量标准，这些概念、术语或度量标准在不同的团队中被使用或解释。当这种情况发生时，混乱就占据了上风。决策者可能不同意数据显示的内容和采取的行动。由于业务逻辑不一致，团队之间的报告可能显示来自相同数据源的相同度量的不同数字。团队甚至可能会争论正确的定义，并保卫他们的地盘，也许是因为他们的定义让他们的数据看起来更好。这不是对企业有利。

一旦您有了数据字典，它就是一个所有员工都可以引用并且处于同一页面的文档，它使新员工更容易上手，并且商业智能(BI)团队对实现这些指标有非常清楚的需求。

需要说明的是，这里我们不考虑原始数据库表文档，尽管这也很重要，但我们考虑的是更高级的业务术语和指标列表。整个企业是如何看待“用户”、“收益”或“获取成本”的?是否每个人都对“销售区域”、“平均出货时间”有相同的理解?目标应该是，初级、非技术人员(如客户服务代理)将能够阅读其业务部分的部分，并理解相关术语，但足够详细和准确地捕获这些指标的业务逻辑。

在这篇文章中，我将详细介绍一些关于数据字典的最佳实践，以及如何创建一个数据字典的过程。这绝不是唯一有效的方法，但至少对我来说是有效的。这里，假设BI团队正在推动这个过程。在我看来，他们应该拥有BI工具中的数据字典和指标实现。

1. 收集字典项

第一步是编制一个术语列表。也就是说，BI团队应该创建一个电子表格，其中包含业务概念和指标度量的名称，以及数据如何被划分维度。这听起来令人望而生畏，一种方法是让业务团队逐个进行，并检查所有标准报告和仪表板的样本。从图表中列出所有的轴标签，从报表中列出列标题，以及数据如何被使用的维度。因此，按地区显示收入的报告产生了两个关键术语:“收入”和“地区”。在这个阶段，您只是编译术语名称的列表，而不是它们的定义。

输出是一个团队名称、术语名称、数据类型、一个或两个示例值的列表，可能还有一个使用该术语的示例报告的链接。可以添加的其他列包括指示这是维度还是度量的列(通常维度比度量更一致)，以及指定事实来源的列。

根据业务域，如财务指标、市场指标、客户服务指标等，对列表进行组织和分组。你可能还想列出真正通用的维度(“年”，“product_id”，“国家”等)，这些维度也横跨许多团队到他们自己的部门。

这个列表可能没有你想象的那么长。这是因为团队往往有一个相对较小的指标集，他们试图用一个相对较小的工具来跟踪和优化——例如，在线营销可能关注几个关键方面，如活动、渠道、花费和细分。

请业务团队查看列表，特别是其中的部分，并添加任何缺少的术语。如果他们有一组健壮的仪表板和报告，那么您可能有一个全面的列表。如果没有，那么这就提供了有价值的附加概念。

2. 定义字典项

BI团队现在应该第一次尝试整理或创建定义。

首先，从任何现有文档中提取定义。这可能来自Wiki、年度报告或实际代码，如SQL查询或Excel。定义应该是清晰和明确的。如果用一个简单的公式(比如ARPU = total_revenue / number_subscribers)而不是写一个定义更清楚，那么就用这个公式。大多数工作人员应该能够理解定义，即使他们需要交叉引用一些术语。

其次，一个接一个地与团队坐下来，请他们帮助列出任何缺失的定义或完善定义。从定义开始，你会取得更好的进展，即使是错误的，比空白单元格要好。这可能需要一些反复，直到在团队中达成一致。它还可能需要一些关于当前如何计算度量的研究。

重要的是，不要问“当前的定义是什么?”而是“这应该如何定义?”如果当前的实现不是理想的定义，那么这是业务团队设定理想状态的绝佳机会。例如，如果您继承了一个过于复杂的定义，这是一个简化的机会。一旦获得了理想的定义，那么数据团队、技术团队或其他业务部门就会面临压力，以交付定义好的指标。

3.识别冲突

这是一个关键步骤:找出团队之间定义不同的术语。

4. 达成一致

对于那些团队之间存在差异的术语，将相关团队带到同一个房间，最好锁上门。让他们讨论如何以及为什么会有不同。

本次会议只应达成两项成果:

•一个团队同意采用另一个团队的定义。

•他们有合理的理由来解释他们的不同。在这种情况下，为一个或两个术语商定一个新名称。

•第三种选择是，两支团队都同意修改他们的定义，使之成为一些共同的定义，这是可能的，但可能性较小。

名称应尽可能长，以避免歧义或混淆。如果" community_adjusted_editba "是一个更合适和恰当的术语，将其与常规的" ebitda "区分开来，那么使用那个更长的、更描述性的术语。目的是为了消除混乱，而不是为了简洁。

5. 签字同意

必须有领导签字，这是至关重要的。您不希望BI团队定义一个术语，而业务团队私下里不同意。在这种情况下，企业将在Excel中实现自己的逻辑，而你又回到了起点。作为领域专家和将根据这些指标做出业务决策的人，这些业务所有者必须完全参与其中。在一些项目中，我们利用了首席执行官的帮助，要求团队负责人在特定日期前签字。团队负责人都很忙，即使他们能看到数据字典的价值，数据字典似乎也不是优先级最高的。因此，这种自上而下的支持被证明是非常有价值的。

6. 字典发布

将数据字典发布为统一的文档，供整个公司访问。因此，不只是在BI工具中。这些定义应该被广泛理解和采用，不仅是高管、分析师和决策者，而且是所有员工。因此，可见性至关重要。如果公司大量使用OA平台，在那里发布。它应该在人们期待的地方。

从概念上讲，这些术语独立于任何单个系统或数据源，因此不依赖于BI工具。但是，在可能的情况下，还应该将单独的定义集成到BI工具中。这个工具要支持这个功能，当你用鼠标移动一个维度或测量值时，定义和例子就会弹出。

如果这些定义可能出现在多个地方，那么数据团队应该努力从单个源(如数据库表或代码存储库)自动生成数据字典，而不是手动维护一个静态表。例如，我们的数据字典是由一个统一编辑平台生成的。如果存储库被修改，它会重新生成文档(一个专门的内部网站或所有数据文档的“数据手册”)。

7. 字典维护

虽然关键指标应该相对稳定，但可能存在必须更改指标定义的合理业务原因。该更改和新定义应该来自业务团队。然而，它需要数据团队的帮助来实现更改并与之沟通。

BI团队应该在推出更改之前评估更改的影响。例如，准备一个图表来显示度量标准的新旧定义，以设定对数字可能如何变化的期望。

将定义的更改视为产品发布:提前沟通定义更改，告诉人们将会发生什么，并将更改记录在数据字典中，例如在文档的底部设置更改日志。

不要让不同的系统失去同步;因此，自动生成文档是有价值的。

五 小结

按照上面的流程创建数据字典并不容易。由于需要很多工作人员之间的沟通和协调，预计需要几个月的时间。这是一个大型的团队工作，由BI团队驱动和协调，但需要广泛的认同、合作和努力，以及一些自上而下的强化。

我不建议把这个过程零敲碎打。例如，不要创建一个完整的营销数据字典，并期望在以后使用财务数据字典。这使得团队之间的协调讨论变得更加困难(上面的步骤4)，而这正是真正的收益发生的地方。此外,连续的特性使得它更容易失去动力。您需要具有共同的结束日期的团队之间的并发讨论来实现目标。