我的桌子需要更多的标准化吗？答案

【问题标题】：Does my table need more normalization?我的桌子需要更多的标准化吗？
【发布时间】：2015-05-01 17:45:18
【问题描述】：

我正在制作一个简单的公共现金簿数据库表来计算我和朋友一起吃饭的费用。我的第一个表只有一个表，它有一个包含非原子值的“人”列，所以我把我的表分成两个表，就像上面一样。

但我不确定这是否足够标准化。是否有任何功能依赖应该被规范化但我不知道它的存在？

（我将使用 MySql，但您可以使用任何类型的 DBMS 来回答我。）

【问题讨论】：

付款人应该是我认为 Person 的外键。是否有可能一个人必须在同一天使用相同的膳食和内容进行交易？
我觉得我的解释还不够。我想表达的关系是“John Doe 和 Jane Doe 在 2015-03-02 一起吃午饭，John Doe 付钱了”。因此，带有#trade 和 person 的表可能具有重复性。我正在考虑用'personal_id'和'name'制作一个新表，并使用'personal_id'作为外键。但是……这是个好主意吗？？
为名称提供 id 的新表不会影响规范化。规范化从不涉及新列，只涉及新表中的旧列。
请将each 表的整个应用程序关系语句（谓词）编辑到您的问题中。还有对限制和不熟悉概念的任何解释。

标签： mysql database relational-database normalization database-normalization

【解决方案1】：

嗯，让我们看看如何标准化它：

在表 1 中，我们可以将 payer 替换为对表 2 的外键引用。
删除表 2 中的 dups，使其成为主键，（您可以稍后将其用于索引）

【讨论】：

这些变化都与规范化无关。 Normalizaiton 用表格的投影代替表格。（还有一个 OP 评论说付款人不一定是交易者，所以没有 FK。）

【解决方案2】：

规范化需要了解函数依赖关系 (FD) 和连接依赖关系 (FD)。你没有给他们。

您的应用程序如果我们确切地知道每个表的“我想要表达的关系”（即谓词）是什么（即到我们可以查看一个情况并知道每个可能的行是否从谓词中提出一个真实的命题并因此属于表中）以及可能出现的确切情况（通过关于可能的应用情况的“业务规则”，相当于对可能的约束数据库状态）。

你的“钥匙”你没有给 FD。你只给了一个候选键（CK）和一个“唯一键”。但是在不了解 FD 的某些情况的情况下，您无法确定部分或全部 CK。因此，当您给出 CK 时，这与说存在和不存在某些 FD 是一样的。当您提供一些标有 PK 或“唯一键”的列集时，您需要告诉我们您给了我们什么：“唯一键”是 CK（不包含更小的唯一子集）还是只是一个超级键（唯一）？你给了所有的CK还是可以有其他的？除了给定的超集之外，还有其他超键吗？如果您确切地告诉我们您知道哪些 FD 持有（通过最小的掩护）以及您知道哪些不持有，这将是最有帮助的。

猜测
我不知道is_calculated 是干什么用的。
也许给定的date 和meal 对只有一个content？

TL;DR您确实需要检查每组可能的列，看看它是否在功能上确定了其他列。即，对于每个数据库状态，是否只出现一组列的值的子行，该列的值只有一个。我们只能在没有清楚了解您的谓词和您的应用程序的情况下进行猜测。您可以通过以下方式减少工作：如果一组列是唯一的，则其超集确定所有其他列。如果一组列是最小唯一的（是 CK），则其较小的子集都不会确定所有其他列。您可以寻找假定 FD 的反例，其中两行对于假定的行列式可以具有相同的子行值，但对于假定的确定属性具有不同的值。阿姆斯特朗公理生成给定公理所隐含的所有 FD。

JDs 标准化为 4NF 和 5NF 涉及将表拆分为多个表，以消除 CK 未暗示的 JD。当一个表的谓词对应于谓词的列集时，表的谓词恰好可以表示为其他谓词的AND。当每个 JD 中的每个合取与至少一个 CK 上的某个其他合取重叠时，一个关系就属于 5NF。（费金的隶属算法。）

PS如果您关心约束，当您从一张桌子变为两张时，您是否失去了一个？

【讨论】：

我看了你的回答好几遍，又从头开始了。我首先定义了每个实体的关系。之后，我在此基础上绘制了 ER 图。最后我可以根据图表制作表格。现在我想我得到了我想要的结果。 :)