sql数据库：带有2列（id名称）和2个主键的表第三范式Boyce-Codd范式

想象一下下表。在我的情况下，我完全确定name需要为unique和not null [unique + not null = primary key]。因此name是主键。由于某些原因（可能是习惯），我自然创建了一个int类型的主键id。sql数据库：带有2列（id名称）和2个主键的表第三范式Boyce-Codd范式

其他假设：我绝对需要在我的表中保留name，并且我绝对确定name（类型varchar）永远不会超过20个字符。

现在我的第一个问题是[可能是否有预期的接近问题]：如果我创建了这样的表，我尊重BCNF博伊斯 - 科德范式吗？

第二个可选问题[可能是开放式问题]：在这种情况下创建第id列是否很好？

CREATE TABLE Y (
    id int, 
    name varchar(20), 
    PRIMARY KEY(id, name) 
    );

2017-01-03 S12000

'name'和'id'都是候选键*。只有其中一个可以被选为主键。而违反BCNF，你至少需要三列（因为它有一个PK）。 – joop

* unique + not null =候选键* –

@ MikeSherrill'CatRecall'是的你是对的。这是我的错误。我应该说独特的+不空=候选人的关键 – S12000

如果每一列都是独一无二的，你可能想要么

CREATE TABLE Y (
    id int primary key, 
    name varchar(20) not null unique, 
);

或

CREATE TABLE Y (
    id int not null unique, 
    name varchar(20) not null unique 
);

的文件描述符这里有ID->的姓名和名称 - > ID。

非正式地，当您的FD中的每个箭头都是候选键的箭头时，您就会满足BCNF。所以这符合BCNF。

创建替代ID列出于习惯不是一件好事。首先想想，并让自己意识到权衡和副作用。

2017-01-04 11:58:10

虽然仅包括两个属性的关系总是在BCNF，你的问题是有点难以回答，因为文本不与表的设计相对应。

如果我把你的表设计为基础回答第一个问题：你创建一个表Y包括两个属性id和name，这是Y的唯一属性，以及共同形成唯一的关键，那么它总是在BCNF。

当我把你的文字说明，在那里你指出name是唯一的（在关系模型中的一个关键的方面），那么就必须考虑的替代属性的含义id（或钥匙）：

a。如果id也是密钥，则FD是id->name; name->id，其中id 是密钥而name是密钥，使得每个FD在其左边都有一个密钥。 BCNF因此得到满足。

b。如果id本身不是密钥，但是name->id成立，那么它在BCNF中仍然是（因为唯一的FD在他的LHS上有一个密钥）。虽然我会然后不明白为什么你有一个额外的属性id在所有。

最主要的是，不过，您的数据库方案并根本就没有坚持在文本中的规则：与(id, name)唯一关键的是完全错误的表达，因为你应该有id作为主键和name作为唯一约束（即替代键），反之亦然。那么它将在BCNF中清楚地表明，并且将对应于上述选项（a）。

所以它不是BCNF的问题，而是一个“方案正确表达与否”的问题。

2017-01-03 13:10:19

回答