1

我正在研究规范化并尝试在一些示例中实现，正在做第三范式，据我了解：“如果关系在 2NF 中并且没有任何传递依赖，则关系在 3NF 中”卡住了一个例子，即一个具有多个候选键的表，我们如何将这些表标准化为 3NF，

这是表，

---------------------------------------------------------------------------------
VIN     | Make |  Model  |  Year  | OwnerID  |Owner

----------------------------------------------------
11a     |Toyota| COrolla | 1988   | 11245    | John
----------------------------------------------------
11b     |Nissan| Caor    | 1988   | 12458    | Peter
----------------------------------------------------
11c     |BMW   | GMC     | 1956   | 15487    | Anne

这里 VIN 是主键，显然 make,model,ownerID owner 是候选键，它们之间和年份之间具有传递关系，我如何将其分解为 3NF？

谢谢，

4

2 回答 2

1

从示例数据推断依赖关系时要小心。您说 make、model、ownerId 是“显然”的候选键，但这对我来说似乎还很不清楚。您是否不希望在某些时候您可能拥有不止一辆相同品牌和/或型号的汽车？难道车主可能拥有不止一辆车吗？您必须考虑您实际想要强制执行的依赖关系，或者您希望业务域中所有可能（正确）数据群的情况。依赖关系是业务需求和被建模的现实的函数，而不仅仅是当前的数据群。

只有你的属性名称才能继续，我猜这个依赖关系OwnerId -> Owner可能会成立。如果碰巧 OwnerId不是候选键，那么这将是违反 3NF 的传递依赖的示例：Owner依赖于非键属性 ( OwnerId)。

于 2013-09-06T15:18:30.530 回答
1

如果您想严格遵守规范化并且它是正常形式，则必须从1NF开始。您可以为当前表创建单独的表Make,Model,Owner并将其重命名为Car. 然后可以foreign keys分别添加。

要支持2NF，您可能会想从 VIN 中获取年份属性，它包含作为模型年份编号（不一定必须与实际制造年份相同）。

3NF声明表列应该只包含完全依赖于主键的列，这现在可以了。

于 2013-09-03T14:51:57.313 回答