Database design DKNF属性的版本控制

我有一个

person

表，有两个属性，

eye\u color

和

hair\u color

。如果我是正确的，如果我想将其规范化为DKNF，我将需要两个属性表，

person\u eye\u color

和

person\u hair\u color

。每个表将有一列用于原始

人员id

，一列用于属性值

但是，如果我想对

hair\u color

属性进行版本设置，我需要将其放在两个单独的表中：一个表（比如

hair\u color\u version

）将ID映射到值，而另一个表（例如

hair\u color\u value

）将相同的ID映射到值。在这种情况下，

person\u hair\u color

表需要

hair\u color id

而不是颜色值

当然，另一种选择是不设置属性值的版本，而是设置person和属性之间的关系的版本，例如创建单独的

person\u hair\u Color\u value

和

person\u hair\u Color\u version

表

问题：鉴于我上面的假设是正确的，哪种版本控制选择更有意义？属性是否应该进行版本控制或属性与其持有者实体之间的关系？

您似乎混淆了（费金的）DKNF和（日期的）6NF。如果要进行版本控制，可能需要6NF，这表示表并不总是较小表的连接。DKNF表示表上的唯一约束来自于其列类型和键。特别是，如果源表与目标表之间有FK，则源表按定义不在DKNF中。DKNF本身与版本控制无关，也不是5NF和6NF规范化的一部分

“6NF”的维基上说有些人叫DKNF 6NF，所以这可能会让你感到困惑。但是没有人叫6NF DKNF。除了“域/键正常形式”的wiki，它还包含其他无意义的内容。因此，请转到其他地方获取版本控制信息

---

无论如何，您的示例似乎涉及person_id和version的属性，但您不清楚。完整解释选项的表格。

我希望您的附加表格是“eye_color”和“hair_color”，分别包含eye color和hair color的所有有效值。是的，该示例存在缺陷，因为我选择了具有有限值集的属性（因此这些值可以是ID）。我想说这个例子是有缺陷的，因为你的“属性表”包含一个“person_id”属性。我想看看你在这方面的想法。用单列表和外键引用满足DKNF。添加表

person\u eye\u color

和

person\u hair\u color

满足6NF。带有时间戳的版本。（时间戳是非素数属性，但它不违反DKNF。）