sql - 识别传递依存关系

Question

所以，我相信我已经理解了完全功能依赖和部分依赖。我会提供一个简短的解释，以防我做错了什么，我不会在兔子洞里走得太远。
我正在处理一个表，它有一个复合主键，由两个属性组成，表中总共有10个属性，形式为1nf。
在我的情况下，完全功能依赖涉及依赖于主键中的两个属性。部分依赖项依赖于主键中的任一属性。传递依赖涉及函数依赖中的两个或多个非键属性，其中一个非键属性依赖于键属性（来自my pk）。
假设我没有弄错，不管我的理解如何，把传递依赖项从表中取出是在折磨我的大脑。看起来您在规范化之后会这样做，但是我的任务要求我们在绘制依赖关系图之前“标识所有函数依赖关系”，然后我们规范化表。
我将列出表中的属性，然后提供业务规则-括号标识pk属性：
(Student ID), Student Name, Student Address, Student Major, (Course ID), Course Title, Instructor ID, Instructor Name, Instructor Office, Student_crse_grade
Only one class is taught for each course ID. Students may take up to 4 courses. Each course may have a maximum of 25 students. Each course is taught by only one Instructor. Each student may have only one major.

Answer 1

从你的问题看来，你对基本知识的理解并不清楚。
应用关系和情况
首先，你必须接受别人告诉你的关于你的应用程序的信息（包括先验规则），并识别应用程序关系（aka associations）。每个都得到一个（基）表（aka relation）变量。这种应用程序关系的特征是行成员条件（aka谓词）（aka含义）。假设条件“student[student\u id]take course[course\u title]”具有表变量take。条件的参数是其表的列。我们可以使用带有列的表名（如sql声明）作为条件的简写。例如录取（学生证，课程名称）。一个标准加上一行就可以说明（命题）一种情况。例如行（17，cs101）给出“学生17修‘cs101’”即修（17，cs101）。给出true语句的行进入表中，而使false语句的行不在表中。
如果我们可以将一个标准重新表述为其他两个标准的and/连接，那么我们只需要具有这些其他标准的表。这是因为join的定义使得包含使其条件为true的行的两个表的join返回使其条件的and/conjunction为true的行。所以我们可以把这两张桌子连起来拿回原稿。（这就是标准化通过将表分解为组件所做的工作。）

-- student with id [si] has name [sn] and address [sa] and major [sm]
    and takes course [ci] with title [ct]
    from instructor with id [ii] and name [in] and office [io]
    with grade [scg]
T(si,sn,sa,sm,ci,ct,ii,in,io,scg)

-- student with id [si] has name [sn] and address [sa] and major [sm]
    and takes course [ci] with grade [scg]
SG(si,sn,sa,sm,ci,scg)

-- course [ci] with title [ct]
    is taught by instructor with id [ii] and name [in] and office [io]
CI(ci,ct,ii,in,io,scg)

-- T(si,sn,sa,sm,ci,ct,ii,in,io,scg)
    IFF SG(si,sn,sa,sm,ci,scg) AND CI(ci,ct,ii,in,io,scg)
T = SG JOIN CI

应用程序关系和可能出现的情况共同决定了规则和约束！它们只是每个应用程序情况或每个数据库状态（即一个或多个基表的值）的真实情况（它们是条件和可能的应用程序情况的函数）。
然后我们进行规范化以减少冗余。规范化将表变量替换为其他表变量，这些表变量的谓词和/或连接在一起，这样做是有益的。
唯一一次规则可以告诉你一些你不知道的事情，从（假设的）标准和（假设的）情况，是当你不真正了解标准或什么情况可以出现，先验规则是澄清了一些东西。向您提供规则的人已经在使用他们假定您理解的应用程序关系，他们只能通过使用这些关系和可能出现的所有应用程序情况（尽管是非正式的）来确定规则是否有效！
（遗憾的是，许多信息建模的演示甚至都没有提到应用程序关系。例如：如果有人说“存在x:y关系”，那么他们必须已经记住实体之间的特定二进制应用程序关系；知道它和可能出现的应用程序情况，他们报告它在某个方向上具有一定的基数。这将对应于一些应用程序关系和使用标识实体的列集的表。另外，一些presentions/methods称fks为“关系”（relationships）——将它们与那些关系混淆起来。）
查看对象角色建模或者（nijssen对niam的描述——而不是错误的解释）。
检查（&C）
给定将行放入或不放入表中的条件以及可能出现的所有情况，表变量中只能包含某些值（行集合）。
对于列的每个子集，您需要确定哪些其他列对于这些列的给定子行值只能有一个值。当它只能有一个时，我们说列的子集在功能上决定了该列。我们说有一个fd（函数依赖）列->列。这时我们可以将表的谓词表示为“……对于某些函数f，column=f（columns）”，但该子集的每个超集也会在功能上决定它，这样就减少了案例。相反，如果给定的集合不确定列，则集合的任何子集都不确定列。此外，您可能认为列集是唯一的；那么所有其他列在功能上都依赖于该集。这样的集合称为超级键。
只有在确定了FDS后，才能确定CK（候选钥匙）！ck是一个不包含较小超键的超键。（存在ck和/或superkey也是一个约束条件）我们可以选择ck作为pk（主键）。pks在关系理论中没有其他作用。
部分依赖项依赖于
主键。
不要用“涉及”或“依赖”来定义。说“当”或“iff”（“当且仅当”）。
阅读定义。当/iff使用行列式的适当子集给出具有相同确定列的fd时，保持的fd是部分的；否则它是满的。请注意，这不涉及cks。当所有非素属性在功能上完全依赖于每个ck时，关系为2nf。
传递依赖项涉及
其中一个非键属性依赖于
一个关键属性（来自我的pk）。
阅读定义。当/iff存在一个x时，s->t是可传递的，其中s->x和x->t不是（x->s）也不是（x=t）。请注意，这不涉及cks。当所有非素数属性都非传递依赖于每个ck时，关系为3nf。
"1NF" has no single meaning.