我目前正在处理这个问题，以确定它是哪种正常形式，因此我必须列出功能依赖项。我找到了解决方案，但仍有疑问。
在最后一年的项目选择过程中，学生要选择一个他/她的项目的研究主题。学生可以选择相同的研究主题。对于每个研究主题，主管被指派监督。一名监督员最多可以监督两名不同的研究主题，每个研究主题可能被分配不同的主管。每个研究主题都有一位主管监督，分配一个咨询日让学生见面并与主管讨论。
最后一年项目选择的信息存储在以下关系表中：财务年度项目(主管，研究主题，咨询日，学生)
这些是我列出的功能依赖项：
学生→研究主题，咨询日，主管
- 学生是候选人的关键
导师，研究主题，学生→咨询日
问题1:我可以从学生那里找到所有属性。但有了(导师、研究题目、学生)，我也能找到咨询日。然而，这些只是超级密钥，而不是候选密钥。那么它应该是一种依赖吗？
问题2:假设我的依赖项是正确的，我可以推断出这个关系表在BCNF中。然而，在我的讲义中，
Boyce-Codd正态形式(BCNF)的定义指出在BCNF中，当且仅当每个行列式都是候选键。
这与我在网上发现的非常不同(例如wiki)：
关系模式R为Boyce–Codd范式当且仅当它的每个依赖项X→Y、 以下至少一项条件保持：
X → Y is a trivial functional dependency (Y ⊆ X) X is a superkey for schema R
所以现在，根据我的选择笔记，找到依赖项后，该表将不在BCNF中，因为(主管、研究主题、学生)不是候选密钥，它只是一个超级密钥。然而，如果是根据wiki的，那么这个表将在BCNF中，因为所有的决定因素都是超级键。这张桌子在BCNF吗？
您引用的BCNF的两个定义都没有提到函数依赖项的集合，但这一点很重要。
你知道，给定一组函数依赖项，例如，通过对一个问题进行推理找到的，有许多等价集，或者更准确地说，有许多集覆盖了它；例如，一组FD的最小或规范覆盖是一个没有冗余依赖项或多余属性的覆盖，并且每个依赖项的右侧都有一个属性。
因此，实际上，很容易证明一个提到超级密钥的定义，比如维基定义，等同于一个提到候选密钥的定义——比如你的课堂笔记中的那些，当考虑的功能依赖性是最小覆盖的时候。事实上，对于最小覆盖的定义，在最小覆盖中，不存在琐碎的依赖关系，也不存在严格的超键(即，由候选键加上非空属性集形成的超键)作为任何依赖关系的左部分。
因此，在检查正常形式时，首先找到给定依赖项的最小覆盖总是一个好主意。
关于你的例子的功能依赖性，考虑到问题的具体说明，我不清楚学生是否选择了一个研究主题，然后可以去任何研究主题的主管那里讨论，或者也被分配给一个特定的主管。当然，这两种情况下的依赖关系是不同的。
学生将选择一个研究主题
student -> research-topic
因为每个学生只有一个研究主题，而这是这种关系中仅有的两个属性，所以我们知道学生是独一无二的，因此是一把候选钥匙。
学生可以选择相同的研究主题。
告诉我们的研究主题在同一关系中不是唯一的，不能是候选密钥。
对于每个研究主题，都会指派监督员进行监督。
research-topic -> supervisor
一名主管最多可以监督两个不同的研究主题
所以supervisor在这个关系中不是唯一的，不能是候选密钥。
每个研究主题可能被分配给不同的主管。
OK，修改(第一次)
research-topic, supervisor -> {}
每个研究者都有不止一个主题，每个主题也有不止一位研究者。
对于主管监督的每个研究主题，为学生分配一个咨询日
第二次修订：
research-topic, supervisor, student -> consultation-day
这有点混乱，也许是故意制造问题来解决的。由于每个学生只有一个研究主题，对于每个研究主题都是转移注意力。我们同样可以说：
第三次修订：
research-topic, supervisor -> {}
和
supervisor, student -> consultation-day
没有必要把话题放在第三关系的关键位置，因为当学生与导师会面时，这将是学生唯一的话题。如果一个学生可能有不止一个主题，我们必须将其添加到关系中，以了解咨询日的议程。
与主管会面并进行讨论。
打电话给这三位关系学生、主管和咨询师。我让你写一个连接来产生{学生，主题，主管，天}，并表明学生与主管的自然连接只产生1行。
我所做的只是将声明的需求表示为依赖项。每一个依赖都被最小化地捕获。从本质上讲，这就是BCNF。
你的学生桌不是BCNF。没有任何地方规定学生选择或分配一名导师。