我正在研究规范化并试图在一些例子中实现，正在做第三种正常形式，并且从我的理解是：“如果它在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所有者是候选键，它们彼此之间具有传递关系，年份如何将其分解为3NF？
谢谢，
答案 0 :(得分：1)
如果您想严格遵守标准化及其正常形式，则必须从 1NF 开始。您可以为Make,Model,Owner创建单独的表，并将当前表重命名为Car。然后您可以分别添加foreign keys。
要坚持 2NF ，您可能想知道从VIN获取年份属性，它包含作为模型年份编号（不一定必须与实际制作年份相同）。
3NF 声明表格列应该只包含完全依赖主键的列，现在一切都好了。
答案 1 :(得分：1)
从示例数据中推断出依赖关系时要小心。你说make，model，ownerId是“明确”的候选键，但这对我来说似乎很不清楚。你不期望在某些时候你可能有多辆同一品牌和/或型号的车吗？不可能是拥有者拥有多辆车的情况吗？您必须考虑您实际要强制执行的依赖项，或者您希望业务域中所有可能（正确）数据群的情况。依赖性是业务需求和被建模的现实的函数，而不仅仅是当前的数据量。
只有您的属性名称才会继续，我猜是依赖项OwnerId -> Owner可能会成立。如果发生OwnerId 不候选键，那么这将是违反3NF的传递依赖的示例：Owner取决于非关键属性（OwnerId ）。