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

Question

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

Lecture	Room	Date	NStudents	Lecturer	Tool
Graphical DP	209	Wed. 1	53	0210	Overhead-Pr.
Graphical DP	209	Fr. 3	53	0210	Overhead-Pr.
C	413	Tue. 1	86	0111	PC
C	413	Tue. 1	86	0111	Overhead-Pr.
C	413	Wed. 3	86	0111	PC
C	413	Wed. 3	86	0111	Overhead-Pr.
Mathematics	418	Mo. 1	76	0342	Board
Mathematics	318	Thur. 2	76	0342	Board
Data Structures	310	Fr. 2	32	0550	Board
Data Structures	310	Fr. 2	32	0550	Overhead-Pr.

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

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

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

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

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

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

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

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

令 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)+ 中

• (Room, Date)+ = {Room, Date, Lecture, NStudents, Lecturer}
• （讲座，日期）+ = {讲座，日期，房间，讲师}

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

• (Lecture, Date)+ = {Lecture, Date, Room, Lecturer, NStudents}
• （日期，讲师）+ = {日期，讲师，讲座}

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

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

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

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

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

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

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

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

Answer 1

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

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

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

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

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

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

例如，根据您的数据，可以生成一组这样的：

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

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

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

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