如果我们使用自动递增的标识列和PK,则违反3NF

Elh*_*ani 2 database-design entity-relationship third-normal-form database-normalization

正如Thomas Connolly和Carolyn Begg在180页写的"数据库解决方案第二版"一书所述:

第三范式(3NF)
已经在1NF和2NF中的表,其中所有非主键列中的值只能从主键列而不是其他列中计算出来.

我已经看到很多人们使用标识列的情况,尽管他们的表中已经有了主键列.记录也可以从标识列中得出,如果我们在表中使用自动递增的标识列和主键,是不是违反了3NF?

更新:如果不是这样,哪个列应作为另一个表中的外键引用.主键列或标识列?

Erw*_*out 6

不可以.3NF定义的"官方"措辞通常使用术语"主要属性"或"非主要属性".如果你的书暗示这意味着"主键的属性",那么把你的书扔进垃圾箱.这是错误的."素属性"是指"属性,该属性是其一部分ANY键的"和"非黄金属性"是指"属性,该属性是不的一部分ANY键的".因此,在您的"自动增量属性"(以及将使其成为关键字的所有适用FD)的关系模式中的引入不可能引入3NF违规,因为它不会引入非主要属性.

  • @ElhamKohestani忘记约束并学习如何选择捕获业务/应用程序状态的表意义.你的(可怜的)短信书有副标题"一步一步的方法[...]".它说什么? (2认同)

nvo*_*gel 5

你引用的段落是错误的 - 或者至少它是如此非正式,以至于作为解释是无用的.

如果关系R处于第二范式并且R的每个非素属性非传递性地依赖于R的每个候选关键字,则关系R是第三范式.

Codd EF,"数据库关系模型的进一步规范化"

候选钥匙是重要的.具有多个键的表没有错.