0

想象一下下表。就我而言，我完全确定name需要unique和not null[unique+not null = 主键]。因此name是主键。由于某些原因（可能是习惯），我很自然地创建了一个idint 类型的主键列。

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

现在我的第一个问题是[可能是肯定或否的接近问题]：如果我创建这样一个表，我是否尊重 BCNF Boyce-Codd 范式？

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

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

2 回答 2

1

如果每一列都是唯一的，你可能想要

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
);

这里的FD是id->name和name->id。

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

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

于 2017-01-04T11:58:10.867 回答
1

尽管仅包含两个属性的关系始终在 BCNF 中，但您的问题有点难以回答，因为文本与表格设计不对应。

如果我将您的表格设计作为回答第一个问题的基础：您创建了一个Y包含两个属性id和的表格name，它们是唯一的属性，Y并且它们共同构成唯一的键，那么它总是在 BCNF 中。

当我采用您的文字描述时，您声明它name是唯一的（就关系模型而言，键），那么人们必须考虑代理属性（或键？）的含义id：

一个。如果id也是一个键，那么 FD 是id->name; name->id，其中id 是一个键，name是一个键，这样每个 FD 在他的左手边都有一个键。因此，BCNF 得到满足。

湾。如果id不是自己的密钥，但name->id持有，那么它仍然在 BCNF 中（因为唯一的 FD 在他的 LHS 上有一个密钥）。虽然我不明白为什么你有一个额外的属性id。

然而，主要的是，您的数据库方案根本不遵守文本中所述的规则：唯一的键(id, name)是完全错误的表达，因为您应该具有id作为主键和name唯一约束（即替代键）或反之亦然。那么它显然在 BCNF 中，并且对应于上面提到的选项 (a)。

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

于 2017-01-03T13:10:19.827 回答