另一个表中的功能依赖

Question

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

所以有表格的字段

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

问题是 - 鉴于Warehouse只保留具有特定类型的项目，这会破坏什么数据库规范化规则？

此数据库是否已标准化？

（问题的例子已经弥补，但我现实生活中基本上都有这个问题。）

Answer 1

我只是在没有任何数据示例的情况下查看您的元数据做了一些假设，但乍看之下，您的架构似乎已经规范化了。从技术上讲，如果它符合以下所有标准，那么你的桌子就是3NF（应该是你的目标）：

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

请注意，还有更高的规范化表单，但是当您开始感觉性能下降时，它们主要是学术性的

鉴于此定义：

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

假设我正确地解释了你的模式，一旦你消除了冗余的Type表，那么我会说这个设置在技术上符合3NF。请注意您的要求

  

鉴于Warehouse仅保存具有特定类型

的项目

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