对第三范式感到困惑答案

【问题标题】：Confused about the third normal form对第三范式感到困惑
【发布时间】：2013-09-06 19:52:03
【问题描述】：

我正在研究规范化并尝试在一些示例中实现，正在做第三范式，据我了解：“如果关系在 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？

谢谢，

【问题讨论】：

标签： entity-relationship foreign-key-relationship database-normalization

【解决方案1】：

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

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

【讨论】：

是的，我是新手，我一般是做编程的，只是意识到你必须使用你的常识以及代表性数据告诉我们的内容，谢谢

【解决方案2】：

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

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

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

【讨论】：

但它不是已经是第一范式了吗？抱歉，我是新手，如果它不是第一个正常的，为什么会这样？