我读过这句话: 数据取决于键 [1NF]、整个键 [2NF],除了键 [3NF] 什么都没有 。
但是,我无法理解所谓的 3.5NF 或 BCNF。这是我的理解:
那么为什么有些 3NF 表不在 BCNF 中呢?我的意思是,3NF 引用明确表示“只有键”,这意味着所有属性都仅取决于主键。毕竟,主键是一个候选键,直到它被选为我们的主键。
如果到目前为止我的理解有任何问题,请纠正我并感谢您提供的任何帮助。
您的比萨饼可以恰好有三种浇头类型:
所以我们点了两个比萨饼并选择以下配料:
Pizza Topping Topping Type -------- ---------- ------------- 1 mozzarella cheese 1 pepperoni meat 1 olives vegetable 2 mozzarella meat 2 sausage cheese 2 peppers vegetable
等一下,马苏里拉奶酪不能既是奶酪又是肉!香肠不是奶酪!
我们需要防止这些错误,让马苏里拉奶酪 永远 是奶酪。我们应该为此使用一个单独的表格,所以我们只在一个地方写下这个事实。
Pizza Topping -------- ---------- 1 mozzarella 1 pepperoni 1 olives 2 mozzarella 2 sausage 2 peppers Topping Topping Type ---------- ------------- mozzarella cheese pepperoni meat olives vegetable sausage meat peppers vegetable
这是一个8岁的孩子可能理解的解释。这是更技术性的版本。
仅当存在多个重叠的候选键时,BCNF 的行为与 3NF 不同。
原因是,如果是 的子集,则函数依赖X -> Y当然是正确的。因此,在任何只有一个候选键并且在 3NF 中的表中,它已经在 BCNF 中,因为没有列(键或非键)在功能上依赖于除该键之外的任何内容。Y``X
X -> Y
Y``X
因为每个比萨饼必须具有每种浇头类型中的一种,所以我们知道 (Pizza, Topping Type) 是候选键。我们也直观地知道,给定的浇头不能同时属于不同的类型。所以 (Pizza, Topping) 必须是唯一的,因此也是候选键。所以我们有两个重叠的候选键。
我展示了一个异常,我们将 mozarella 标记为错误的浇头类型。我们知道这是错误的,但导致错误的规则是依赖关系Topping -> Topping Type,它不是该表的 BCNF 的有效依赖关系。它依赖于整个候选键以外的东西。
Topping -> Topping Type
所以为了解决这个问题,我们从 Pizzas 表中取出 Topping Type 并使其成为 Toppings 表中的非键属性。