2

doctor我的数据库中有一个基表，其中有列

Name, d_ID, Age, Gender, Contact_NO, Speciality, beg_Date, End_Date

我希望规范化我的表。我发现医生表的依赖关系如下：

Name, d_ID ---> Age, gender, Speciality
d_ID----> Name, Contanct_NO, Beg_Date, End_Date

还有一些具有类似结构的基表。

我计算了闭包，发现我有 2 个候选键，它们是{d_ID}和{Name,d_ID}。我选择{d_ID}了做主键和{Name,d_ID}副键。

我的问题是：

  1. 我想知道我的桌子是否已经在 2NF 中。如果没有，请告诉我如何分解关系？

  2. 我有一个名为的中间表patient_record，它有 、 、 、doctor id等等patient id。我的困惑在于，如果只对中间表而不是其他基表进行规范化。我相信这一点，因为基表的列只有唯一标识符，因此它们会自动落入 2NF 之下？nurse idbed id (foreign key)

4

2 回答 2

2

我计算了闭包，发现我有 2 个候选键，它们是 {d_ID} 和 {Name,d_ID}（如果我错了，请纠正我）。

不，根据定义，候选键是不可约的。如果 d_ID 是候选键，则 {Name, d_ID} 不是。{Name, d_ID} 不是候选键，因为它是可约的。删除属性“名称”，您就有了一个候选键 (d_ID)。

1）我想知道我的桌子是否已经在 2NF 中。如果没有，请告诉我如何分解关系？

在这种情况下真的很难说。尽管您对每位医生都有一个唯一的 ID 号，但在您的情况下，它仅用于识别一行，而不是医生。您的表允许此类数据。

d_ID   Name         Age  Gender  Contact_NO     Speciality   beg_Date    End_Date
--
117    John Smith   45   M       123-456-7890   Cardio       2013-01-01  2015-12-31
199    John Smith   45   M       123-456-7890   Cardio       2013-01-01  2015-12-31
234    John Smith   45   M       123-456-7890   Cardio       2013-01-01  2015-12-31

有多少医生？（我编了数据，所以我真的是唯一知道正确答案的人。）有两个。234 是 117 的意外复制。199 与 117 是不同的医生；巧合的是，他们都是同一家医院的心脏病专家，而且他们的医院特权在同一天开始和结束。

这就是识别行和识别医生的区别。

它是否在 2NF 中取决于可能尚未确定的其他功能依赖关系。其中可能有几个。

2）我有一个名为 Patient_record 的中间表，其中包含医生 ID、患者 ID、护士 ID、床 ID（外键）等。如果只对中间表而不是其他基表进行规范化，我会感到困惑。

通常对所有表进行规范化。

因为基表只有列的唯一标识符，因此它们会自动属于 2NF？

不，那不是真的。如需澄清，请参阅我对 Learning database normalization 的回答，对 2NF 感到困惑。

识别行和识别事物

这是一个微妙的点，但它非常非常重要。

让我们看一个具有三个候选键的表现良好的表。

create table chemical_elements (
  element_name varchar(35) not null unique,
  symbol varchar(3) not null unique,
  atomic_number integer not null unique
);

该表中的所有三个属性都已声明not null unique，这是用于识别候选键的 SQL 习惯用法。如果您对没有将至少一个候选键声明为 感到不舒服primary key，那么只需选择一个。哪一个并不重要。

insert into chemical_elements
(atomic_number, element_name, symbol)
values
(1, 'Hydrogen', 'H'),
(2, 'Helium', 'He'),
(3, 'Lithium', 'Li'),
(4, 'Beryllium', 'Be'),
[snip]
(116, 'Ununhexium', 'Uuh'),
(117, 'Ununseptium', 'Uus'),
(118, 'Ununoctium', 'Uuo');

三个候选键中的每一个——atomic_number、element_name、symbol——都明确地标识了现实世界中的一个元素。“铍的原子序数是多少？”这个问题只有一个可能的答案。

现在看看医生表。对于这个问题，有不止一个可能的答案：“名叫‘约翰·史密斯’的医生的身份证号码是多少？” 事实上，对于同一个医生，有不止一个可能的答案，因为 234 和 117 指的是同一个人。

包含更多列没有帮助，因为两位医生的数据相同。你可以得到不止一个问题的答案，“这位名叫‘约翰·史密斯’的 45 岁男医生的身份证号码是多少，他的电话号码是 123-456-7890，专长是‘心电图’ ？”

如果您发现有人为这两位医生预约，您可能会发现他们的身份证号码写在黄色便签纸上并贴在他们的显示器上。

  • 约翰史密斯博士，他看起来像布拉德皮特 (!)，ID 117。
  • 其他 John Smith 博士，ID 199。

每个 ID 号明确地标识数据库中的一行，但每个 ID 号并没有明确地标识医生。您知道 ID 117 标识了一位名叫 John Smith 的医生，但如果两个 John Smith 都站在您面前，您将无法分辨哪一个属于 ID 号 117。（除非您读过那张黄色便签，并且你知道布拉德皮特长什么样子。但这些信息不在数据库中。）

这和你的问题有什么关系？

规范化是基于函数依赖的。当我们谈论“功能依赖”时，我们在谈论什么“功能”？我们正在谈论身份功能。

于 2013-03-26T02:13:34.900 回答
1

这是规范化过程：

  1. 识别关系的所有候选键。
  2. 识别关系中的所有功能依赖关系。
  3. 检查函数依赖的行列式。如果任何行列式不是候选键，则关系不是很好。然后

  4. i) 将函数依赖的列放在它们自己的新关系中。

    ii) 使函数依赖的行列式成为新关系的主键。

    iii) 在原始关系中保留一份行列式作为外键。

  5. 在原始关系和新关系之间创建参照完整性约束。
于 2013-03-25T09:41:20.740 回答