MysI 想向您介绍元数据和一般数据在数据库中的作用。
级别 1：神秘数据集
让我们考虑以下示例 - 我们被要求列出所有现有员工以及所有可用的详细信息。
假设我们找到了这个原始数据表：
没有上下文，我们也没有关于我们实际查看的数据的信息。这看起来像一张人名表，但这些人是员工还是客户，或者只是随机的人？如果我们知道一些员工的名字，我们可能会弄清楚数据集代表什么。我们发现该表实际上包含员工，或者至少包括员工。但是 A 列和 D-I 列是什么？D 是出生日期吗？但这也可能是就业的开始（他们都是长期雇员）。H列呢，是最后一次记录更新、最后一次职位变动、最后一次加薪还是最后一次体检的日期？我似乎是某种旗帜。几乎无法分辨 F 和 G 列代表什么。
您需要一段时间才能弄清楚每个数据的含义，并且假设您有任何参考信息（一种根据其他信息来源测试这些数据的方法——您对公司的了解、对数据 UI 或报告的访问，纸质记录或询问其他人）。如果你不这样做，那么这些数据中的一些对你来说真的没用。
我们缺少的是关于我们的数据集的一些信息 - 元数据。
级别 2：基本元数据
让我们添加一些基本元数据 - 表名和列名：
现在，情况好多了。现在我们对数据集是什么以及特定列代表什么有了更好的理解。或者至少是理解了其中的大部分。我们确认表格上有员工。我们发现，A 列包含唯一的员工编号，D 包含出生日期，E 是卡号，F 似乎是教育水平，G 是员工部门。
我们不知道 eval 列代表什么——是员工绩效还是医疗评估，日期实际代表什么——第一次评估、最后一次评估或计划的下一次评估？
也不清楚教育和部门列中的具体值是什么意思——dept_id 表明有一个查找表。和教育栏一样吗？
这种元数据——表和列名——是所有现代数据库系统的标准元素。但是由于各种原因，这些名称可能无法告诉我们该表包含的内容：
- 名称含糊不清或令人困惑
- 列可能已更改其用途而不更改其名称
- 简短的名称可能不足以解释复杂的逻辑
我们需要更多元数据 - 我们需要一个数据字典。
级别 3：数据字典
假设我们很幸运，我们在公司存储的文件夹中发现了一个文件，标题中有“数据字典”，里面有下表：
这说明了很多：我们现在知道如何获取特定部门——我们需要使用部门查找表，我们知道如何破译教育——似乎没有查找表，逻辑有点混乱，我们知道eval 列保存上次员工绩效评估的日期。
这是我们准备报告所需要的。现在我们的工作很简单。在此之前，这是繁琐的分析和猜测。
那么我们如何获得数据字典呢？好吧，我们需要制作一个。需要有人来描述每个表、列和关系。这是一项需要认真对待的任务。它应该在数据建模和数据库设计阶段创建并在开发过程中维护。
实际上，开始收集元数据以开始构建数据字典永远不会太晚。正如上面的任务所示，随着我们对数据的了解越来越多，我们应该收集数据字典中的所有信息，在整个组织中共享，并确保每个人都可以在学到新东西时添加到其中。
支持元数据
今天的关系数据库支持这种元数据，但很大程度上取决于人。设计人员有义务为每一列提供名称和数据类型，但提供有意义的描述取决于他们的实践和善意。实践表明描述经常被省略。
结论
这是一个小型单表的简单示例。真正的数据库包含许多具有许多列的表。难度要高很多。如果您希望能够有效地使用您的数据，您需要处理有意义的元数据。
没有元数据，您将无法使用您的数据！