另一个表中的功能依赖答案

【问题标题】：Functional dependency in another table另一个表中的功能依赖
【发布时间】：2016-05-01 22:25:29
【问题描述】：

假设有仓库，每个仓库都存放特定类型的物品。

所以有带字段的表

仓库 - ID、名称、类型
项目 - ID、名称、类型
WarehouseItem - 仓库，物品
类型 - ID、名称

问题是 - 鉴于仓库只保存具有特定类型的项目，这违反了哪些数据库规范化规则？

这个数据库是否规范化了？

（问题的例子是编造的，但我在现实生活中基本有这个问题。）

【问题讨论】：

在这种情况下，不仅仅是违反规范化规则之一，我想说您的架构正在实现与您的要求不同的数据库。（如果仓库只包含相同类型的物品，则类型与仓库相关）。
不完全是，我想。仓库不包含给定类型的所有项目。您可能是正确的，应该有一个 Type 表和一个 Warehouse.Type 字段。但是仓库仍然只包含其中的一些项目。尚未标记为已解决。我将进行编辑以澄清。
我没有说要让warehouse.type字段唯一，只是如果关系存在，它必须被物化。多个仓库仍然可以拥有相同的物品类型（但每个只有一种类型）。
我会添加关系，但我想问题仍然存在。是否标准化？我会再次编辑。如果您有答案，请添加答案。（你为什么要评论呢？）

标签： mysql sql database-normalization

【解决方案1】：

我只是在没有任何数据示例的情况下查看您的元数据做出了一些假设，但乍一看，您的架构似乎大部分都是标准化的。从技术上讲，如果满足以下所有标准，您的桌子就是 3NF（这应该是您的目标）：

也是1NF - 每个条目只包含原子数据（或单个信息）
也是2NF - 没有候选键依赖意味着当你有一个composite primary key（一个由多于一列组成的键）时，所有数据都依赖于整个键
它是 3NF - 否 transitive dependency 表示所有数据仅依赖于 primary key 而不是表中的其他列

请注意，还有更高的规范化形式，但它们大多是学术性的，因为你越规范化就会开始体验性能下降

鉴于此定义：

Warehouse出现3NF假设每个仓库只能有一个Type。如果不是，那么您将无法传递传递依赖，并且需要将 Type 信息移动到新表中。
Item 也出现 3NF 假设只能分配一个 Type
Type 似乎包含冗余数据，应将其删除，除非您在Type 和Warehouse 和/或Item 之间存在many-to-many 关系。在这种情况下，您需要在Type 和Warehouse 或Item 之间引入bridge-entity（又名composite entry）来创建两个1-to-many 关系。
最后，如果我没看错的话，WarehouseItem 似乎是Warehouse 和Item 之间的桥梁实体，以打破它们之间的many-to-many 关系。如果这是正确的，假设Warehouse 和Item 的组合代表composite key，您应该可以认为该表是3NF。

所以假设我正确解释了您的架构，一旦您消除了多余的Type 表，那么是的，我会说这个设置在技术上符合 3NF。请注意，您的要求是

假设仓库只存放特定类型的物品

可能需要您引入一个新的 type 字段，这意味着您需要重新评估该表的规范化。如果您有两种不同的类型（WarehouseType 和 ItemType），那么您可能需要保留 Type 表并将其转换为映射这两个新字段之间的表。但我需要查看数据示例才能更好地评估。

【讨论】：

问题是关系不会阻止仓库拥有多种类型的项目。我认为这表明它不是某种正常形式。但是您似乎暗示无法通过规范化来解决问题。标记为正确答案。
通过向 WarehouseItem 表添加约束以确保必须存在匹配项，这应该相对容易解决。 MySQL 处理约束的方式与其他数据库略有不同，但您可以在此处找到更多信息：dev.mysql.com/doc/refman/5.7/en/constraints.html
“请注意，还有更高的规范化形式，但它们大多是学术性的，因为你越规范化就会开始体验性能下降” - 告诉人们这是不真实和危险的。我经常看到在某些查询引擎和模式中，规范化的模式比非规范化的模式执行更好。 simple-talk.com/blogs/2008/07/21/the-myth-of-over-normalization
@NWest 有趣的文章...我有兴趣看到量化他的提议的数据。尽管如此，“不真实和危险”是一个延伸......戴维斯先生正在打破行业和学术先例。如果他是对的，那么他将拥有更大的权力……但是，从务实的角度来看，我认为您将很难找到能够证明增加数据库规范化的开发成本的客户。 3NF 仍然是一项有价值的尝试，遗憾的是在现实世界中很少见。
@NWest 还有一些值得一提的事情……您需要考虑的不仅仅是数据库性能，还有开发人员或 BI 用户与表交互的能力。易用性与规范化之间存在反比关系，因此在节省 20 秒的查询时间时，您可能会为未来的开发提案增加数小时。你的观点仍然很好......我将不得不自己进一步研究。