Mysql 考虑下面的内容，为了清晰，已将其映射为字母

飞机id、飞行日期和飞行员姓名（如果我知道的话）之间存在功能依赖关系 航班的日期和使用的飞机（我可以找到驾驶该航班的特定飞行员）。即

AI-->G

这些属性之间还存在哪些其他功能依赖关系

答案应使用字母表示属性等 应该是：AI-->G

对于关系R（A，B，C，D，E，F，G，H，I），（即上述属性），使用函数 您在上面找到的依赖项使用密钥确定算法查找以下属性： 1.绝对是R键的一部分， 2.绝对不是R键的一部分，以及 3.也许在R的钥匙里。 最后，从以下公式导出R.

的键：

再申请关系和情况：

应用程序关系和情况一起决定规则和FD（以及其他约束）！它们只适用于每个应用程序情况或每个数据库状态（即一个或多个基表的值）（这是标准和可能的应用程序情况的函数），然后我们进行规范化以减少冗余

关于FDs和CKs：

给定将行放入表或将行从表中移出的标准以及可能出现的所有情况，该表中只能有一些值（行集）

对于列的每个子集，您需要决定哪些其他列对于这些列的给定子程序值只能有一个值。当它只能有一个列时，我们说列的子集在功能上决定了该列。但该子集的每个超集也将在功能上决定它，这样就减少了案例。相反，如果给定的集合不确定列，则集合的子集不确定。此外，您可能认为列集是唯一的；那么所有其他列在功能上都依赖于该集。这样的集合称为超级键

只有在确定FDs后，才能确定候选密钥！CK是不包含较小的超键的超键。（CKs和超级键的存在也是约束。）我们可以选择CK作为主键

---

请参阅和（以及我的其他涉及规范化的人员）。

抱歉，我无法理解您在这里试图实现的目标，但实际分配属性时，F-source的定义不清楚。来源包含什么？第二，飞行员需要一个身份证。姓名甚至dob与姓名的组合都不能依赖。您需要飞行员的唯一标识符。哦，对不起，如果对于源机场来说，这看起来像是一个家庭作业问题……我们对“清晰度”有非常不同的定义，那么您是如何被告知进行此操作的？你从谷歌搜索（查找或确定）（fds或“功能依赖项”）的某些资源中得到了什么？如果你不理解一个推荐人，那么就先问一个你不理解的问题。您声称存在哪些FD和非FD？为什么？

A - flight_date
B - plane ticket price
C - source_airport_country
D - ticket holder names
E - address 
F - source airport
G - Pilot_name
H - Pilot_grade
I - Plane_id