database - 从功能依赖中确定候选键：我们不使用最小超级键的例外情况？

问题描述

我目前正在尝试了解功能依赖关系以及如何从中派生候选键。在一项作业中，我得到了以下关系 R

演讲	房间	日期	学生	讲师	工具
图形 DP	209	星期三。1	53	0210	开销-公关。
图形 DP	209	神父。3	53	0210	开销-公关。
C	413	周二。1	86	0111	个人电脑
C	413	周二。1	86	0111	开销-公关。
C	413	星期三。3	86	0111	个人电脑
C	413	星期三。3	86	0111	开销-公关。
数学	418	月 1	76	0342	木板
数学	318	星期四。2	76	0342	木板
数据结构	310	神父。2	32	0550	木板
数据结构	310	神父。2	32	0550	开销-公关。

第一个任务是在关系 R 中找到所有有意义的函数依赖。

函数依赖在我们的讲座中定义为

对于具有任意属性集 X 和 Y 的关系 R，如果对于所有 (x1,y1) 和所有 (x2,y2) 具有 x1,x2∈X 和 y1，Y 在功能上依赖于 X（我们也说 X 确定 Y）， y2∈Y 成立：x1=x2 ⇒ y1=y2，即 X 中任何相同的值组合必须以 Y 中的相同值组合为条件。

使用此定义，我确定了以下一组功能依赖项

FD = {Lecture -> (NStudents, Lecturer), (Room, Date) -> (Lecture, Lecturer), (Lecture, Date) -> (Room, Lecturer), (Date, Lecturer) -> Lecture, (Date,工具）-> 讲座}

但是，我不知道它们是否有意义，因为没有指定有意义的确切含义。

下一个任务是识别候选键。

在我们的讲座中，超级键被定义为

令 A 为关系 R 的所有属性的集合，令 K 为 R 的任意属性集。

如果 K->A，则 K 称为超级键

全功能依赖在我们的讲座中定义为

如果没有 Z->Y 成立的 Z⊂X，则函数依赖 X -> Y 是完全函数依赖，否则 X->Y 是部分函数依赖。

因此，候选键定义为

如果 K->A 是全函数依赖，那么 K 称为 R 的候选键

接下来，我构造了属性闭包集来找到一组满足候选键定义的属性

（讲座）+ = {NStudents, Lecturer}
（房间，日期）+ = {房间，日期，讲座，讲师}

由于 NStudents 可以从 Lecture 派生，因此我将属性添加到闭包集 (Room, Date)+

（房间，日期）+ = {房间，日期，讲座，NStudents，讲师}
（讲座，日期）+ = {讲座，日期，房间，讲师}

由于 NStudents 可以从 Lecture 派生，我再次将 NStudents 添加到属性闭包集中

（讲座，日期）+ = {讲座，日期，房间，讲师，NStudents}
（日期，讲师）+ = {日期，讲师，讲座}

因为 NStudents 可以从 Lecture 和 Room 派生自 Lecture 和 Date 我将这些属性添加到闭包集中

（日期，讲师）+ = {日期，讲师，讲座，NStudents，房间}
（日期，工具）+ = {日期，工具，讲座}

NStudents 和 Lecturer 可以从 Lecture 派生，Room 可以从 Date and Lecturer 或 Date and Lecture 派生，所以我将这些属性添加到闭包集中

（日期，工具）+ = {日期，工具，讲座，NStudents，讲师，房间}

如果我没有遗漏任何东西，属性集 {Date, Tool} 是一个全功能依赖项，因为没有 Z->Y 的 Z⊂X。

但是，该练习的解决方案是以下属性集：

{讲座、工具、日期}
{房间、工具、日期}
{讲师，工具，日期}

我想知道为什么要添加另一个属性？这一步不是使属性集只是部分功能依赖吗？

标签： databasefunctional-dependenciescandidate-key

解决方案

通过关系给定特定的现实模型，其中包含的功能依赖关系来自所表示的数据的含义。一个样本数据集，如你的例子，只能给出这种含义的模糊建议，但不能完全表达。

例如，从您的示例中，可以得出结论 Lecturer -> Lecture（反之亦然），但仅从数据来看，我们无法确定同一 Lecturer 会在特定时间给出两个不同的 Lecture（反之亦然）。另一个推断依赖的例子可能是 Room -> Lecture，因为每个房间都有一个独特的、不同的讲座。

因此，给出一组函数依赖关系的正确方法是知道数据的含义，并用这种符号表示它们之间的依赖关系。

此外，请注意，不同的函数依赖集可以是等价的（从技术上讲，它们被称为关系中依赖的“覆盖”），以不同的方式描述相同的含义。

因此，当需要在特定情况下提供一组 FD 持有时，我们尝试提供最小的依赖集，因为有一些方法允许我们从中找到所有派生的依赖项，例如通过 so-称为阿姆斯特朗公理。

当提出一个练习时，比如在你的例子中，我们应该找到“<strong>有意义的函数依赖”，我们唯一能做的就是部分查看数据，部分尝试理解数据，找到一组没有太多冗余，但尽可能捕捉数据含义的FD。一般来说，最小值主要意味着两件事：a）具有最小可能的属性集，以及 b）具有不能从其他属性派生的依赖关系。

例如，根据您的数据，可以生成一组此类：

Lecture -> Lecturer
Lecturer -> Lecture
Room -> Lecture
Lecture -> NStudents
NStudents -> Lecture
Tool, Date -> Room

几乎不可能知道该集合是否完整并且在一般情况下为真（例如，可能有相同数量的学生的讲座，但有不同的学生，并且只是偶然学生的数量相等），尽管鉴于显示的数据，我们可以认为这是“合理的”。

在这种情况下，假设上面的 FD 覆盖了关系的依赖关系（所有其他 FD 都可以从上述集合派生），那么您认为唯一的候选键是（工具，日期）是正确的。

但也许在你的老师的脑海中，还有其他不存在的数据（或关于模型的其他信息）与这组 FD 相矛盾，因此练习的答案与我们可以从数据中做出的推论不同。

database - 从功能依赖中确定候选键：我们不使用最小超级键的例外情况？

问题描述

解决方案

推荐阅读