规范化数据字典答案

【问题标题】：Normalizing a Data Dictionary规范化数据字典
【发布时间】：2013-05-30 00:46:38
【问题描述】：

我正在为一个组织创建一个数据字典，它将在许多不同来源中找到的字段汇总在一起并对其进行定义。我有另一个 Access 数据库中的所有数据，但它是一个关系混乱。我是 Access 的新手，目前正在尝试规范化数据库并迁移数据。

来源目前是摘录和报告。更多资源即将推出。提取物有 2 个细分（旧的和新的），每个细分都有多个细分。报告有 6 个细分，没有进一步的细分。字段出现在 1 和所有报告和摘录之间的任意位置。无论字段出现在何处，数据定义大多相同，但有时会有所不同。数据定义在“提取”细分中是一致的，但在“提取”和“报告”之间以及在“报告”中可能有所不同。不同报告中相同字段名称的数据类型通常不同。

我在规范化数据库中的表（到目前为止）是：字段信息、来源和定义。每个的结构如下，

Tbl_[Field Info]    
Field Name (PK)         Full Name
---------------         ---------------------------
TSN                     Transaction Sequence Number

我认为这是正确的，因为全名不会因字段名称而异。

Tbl_[Sources]
Sources (PK)
-------------
New Extracts
Old Extracts

这是我开始认为事情不对劲的地方。除了来源本身之外，来源肯定应该在表格中包含其他内容吗？

Tbl_[Definitions]
ID (PK)             Field Name (FK)             Source              Definition
-------             ----------------            -----------         ---------------
1                   TSN                         Old Extracts        blahblah
2                   TSN                         New Extracts        blahblah
3                   ABC                         New Extracts        asdfghjkl

这就是我觉得我一定是错的地方。我在定义表中经常重复相同的定义。

到目前为止，我的组织系统有意义吗？我希望在以后添加更多详细说明数据类型以及该字段是否为数字的字段。

【问题讨论】：

“除了来源本身，来源肯定应该在表格中包含其他内容吗？” 可能，但不一定。除了名字之外，人们还需要知道关于“新提取物”的任何信息吗？
Definitions 表中的 Source 列是否是 FK，由 Sources 表中的 PK 验证？
如果您确定了目前数据中的所有函数依赖关系，您的问题会更容易理解。
“功能依赖”你能澄清一下这是什么意思吗？对不起，这个标准化业务很新。您是对的，定义表中的源列是由源表中的 PK 验证的 FK。
如果 a 确定 b，则 b 在功能上依赖于 a。维基百科中的文章不适合新手。如果我找到更好的，我会告诉你的。同时，如果不学习函数依赖，就无法学习规范化。对不起，但就是这样。

标签： database ms-access database-design normalization

【解决方案1】：

为数据字典构建一个体面的关系模型是一个已经讨论了三十多年的问题。这不是一个简单的问题。关于这个主题有相当多的文献，其中一些是有用的。还有很多产品可以解决管理数据字典的问题，但从这些产品中学习数据模型可能非常困难。

您说您是 Access 新手，但您没有说您是否对其他一些关系数据库系统（如 SQLServer 或 Oracle 等）有丰富的经验。如果您是关系建模的初学者，我建议您有很长的学习曲线，然后才能为数据字典想出一个像样的模型。

【讨论】：

我是关系数据库的新手，无论是作为概念还是作为应用程序。您对开始阅读有什么建议吗？
我在谷歌上搜索了“如何构建数据字典”并获得了一些点击。其中之一来自 Ehow，说明了如何在 Access 中构建一个。我不能保证这个答案，但我在其他事情上与 Ehow 相处得很好。您可能想阅读有关数据字典的 Wikipedia 文章。抱歉，我在 1980 年代的某个时候停止阅读有关数据字典的内容。也许其他参与者可以向您推荐当前的文献。

【解决方案2】：

有一个基本的期望，即旧提取和新提取中的“TSN”将具有相同的定义以及所有其他属性。

在创建数据映射时，我会根据您的标准尝试将旧的和新的连接成一条线，左边是新的，这会给您这个

Tbl_[Definitions]
ID (PK)             Field Name (FK)             Source              Definition          Field Name (Old)             Source (old)             Definition (old)

-------             ----------------            -----------         ---------------      -------             ----------------            -----------         ---------------

1                   TSN                         Old Extracts        blahblah                   TSN                         New Extracts        blahblah

2                   ABC                         New Extracts        asdfghjkl

【讨论】：

有时这并不成立。我可能有一个字段 Field1 表示旧数据提取中的一件事和一半的报告，新数据提取中的另一件事，另一个报告中的第三个，并且根本不会出现在其余 2 个报告中。最终用户将通过表单访问数据库，并希望看到一个字段名称的所有可能定义，这就是我尝试正确构建数据库的原因