根据第三范式，我们需要避免依赖于无关键属性。
所以，如果我有一个用户数据库
User(username varchar, full_name varchar, country varchar, SSN varchar, UID varchar)
对于每个用户，我都有他的用户名，全名，国家和社会安全号码（这是唯一的），以及另一个对每个用户都是唯一的号码。我想使用用户名作为PRIMARY KEY，但是如果你知道一个人的社会安全号码，你也可以获得有关该用户的所有信息，因为它也是'UNIQUE＆＃39;。
它是否违反了第三种正常形式？
我可以将它拆分为两个或更多表，例如从User中删除SSN
并把它放在一个不同的表中
SSN(ssn varchar, username varchar)
但是现在我在这个表中遇到了同样的问题，因为两个键可以用作＆＃39; PRIMARY KEY＆＃39;。
可以吗？或者它是否违反了第三种形式，如果确实存在，是否有任何巧妙的方法可以解决这个问题？
答案 0 :(得分：2)
数据库中常见的多列可能都是唯一的。你清楚地阐明了这种情况。这些被称为候选主键。
在这种情况下，应将这些列中的每一列明确声明为unique和not null。但是，只有一列可以作为主键。
一般来说，我赞成合成主键 - 一个自动递增的数值。确切的语法因数据库而异，但大多数数据库都支持这些密钥。
答案 1 :(得分：1)
你不应该把桌子分成两个，因为用户＆＃39; schema有三个列（用户名，SSN，UID），可以唯一标识，如果你正在使用＆＃39;用户名＆＃39;作为主键，其他两列（SSN，UID）是备用主键，称为候选键＆＃39;在用户架构中。 ＆安培;这不应该违反3NF。