识别传递依赖

Question

我正在处理一个表，该表具有一个复合主键，该主键由1NF形式的两个属性（总共10个）组成。

• 在我的情况下，全功能的依赖项涉及依赖项， 这 依赖于我的主键中的 两个 属性。
• 部分依赖项依赖于主键中的任一属性。
• 传递依赖关系涉及功能依赖关系中的两个或多个非关键属性，其中一个非关键属性依赖于我的主键中的某个关键属性。

将可传递的依赖关系从表中拉出，似乎 在 规范化 之后
执行了此操作，但是我的工作要求我们在绘制依赖关系图（然后对表进行规范化）之前，先确定所有功能性依赖关系。括号标识主要键属性：

(Student ID), Student Name, Student Address, Student Major, (Course ID), Course Title, Instructor ID, Instructor Name, Instructor Office, Student_crse_grade

• 每个课程ID仅教一门课程。
• 学生最多可以选修4门课程。
• 每门课程最多可容纳25名学生。
• 每门课程仅由一名讲师讲授。
• 每个学生可能只有一个专业。

Answer 1

从您的问题看来，您对基本知识没有清晰的了解。

应用程序关系和情况

首先，您必须采取关于应用程序的信息（包括业务规则），并确定应用程序关系（也称为关联）。每个都获得一个（基本）表（又称关系）变量。这样的应用程序关系可以通过作为语句模板的行成员资格条件（又称谓词）（也就是含义）来表征。例如，假设标准student [student_id] takes course [course_title]具有表变量TAKES。条件的参数是其表的列。我们可以将带有列的表名（如SQL声明）用作该条件的简写。例如TAKES(student_id,course_title)。一个标准加上一行就情况做出了陈述（又称命题）。例如，第（17，’CS101’）行给出student 17 takes course 'CS101'ie TAKES(17,'CS101')。给出正确语句的行进入表中，而给出错误语句的行则留在表外。

如果我们可以将一个标准改写为其他两个条件的AND
/和，那么我们只需要这些其他标准的表即可。这是因为定义了JOIN，以便两个表的JOIN包含使它们的条件为真的行返回返回使它们的条件的AND
/合取为真的行。因此，我们可以将两个表联接起来以获取原始表。（这是归一化通过将表分解为组件来完成的工作。）

/* 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

可能出现的应用程序关系和情况共同 决定
了规则和约束！它们只是在每种应用程序情况或每种数据库状态（即一个或多个基表的值）（取决于条件和可能的应用程序情况的函数）中都是正确的。

然后，我们进行归一化以减少冗余。规范化会用其他谓词将表变量替换为其他谓词，如果谓词这样做是有利的，则其谓词AND /会合在一起。

规则唯一可以告诉您从（假定）标准和（假定）情况中已经不知道的事情的时间是，当您 真正不了解
标准或可能出现的情况时，以及先验规则正在澄清一些事情。一个为您提供规则的人 已经在使用他们认为您理解的应用程序关系，他们 只能通过
使用它们以及所有可能出现的应用程序情况 （尽管是非正式的）来确定一条规则成立！

（不幸的是，许多信息建模演示 甚至都没有提到 应用程序关系。例如：如果有人说“存在X：Y关系”，那么他们必须已经牢记实体之间的 特定
二进制应用程序关系；知道了它以及什么应用程序情况可能会出现，他们报告它在某个方向上具有一定的基数，这将与某些应用程序关系和使用标识实体的列集的表相对应，再加上一些表示/方法将FK称为“关系”-将它们与这些关系相混淆）

查看“基于事实”的信息建模方法对象角色建模或（其前身）NIAM。

FD和CK

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

对于 列的每个子集，
您需要确定哪些其他列对于这些列的给定子行值只能具有一个值。当它只能有一个时，我们说列的子集在功能上决定了该列。我们说有一个FD（功能依赖）的列->列。这时我们可以将表谓词表示为某些函数F的“
… AND column =
F（columns）”。但是该子集的每个超集也将在功能上确定它，从而减少了用例。相反，如果给定集合未确定列，则该集合的子集都不会确定。应用
阿姆斯特朗公理 给出在给定FD保持时保持的所有FD。另外，您可能会认为列集是唯一的；那么所有其他列在功能上都依赖于该集合。这样的集合称为超键。

只有确定了FD后，才能确定CK（候选密钥）！CK是一个超级键，其中不包含更小的超级键。（存在CK和/或超键也是一个约束。）我们可以选择一个CK作为PK（主键）。PK在关系理论中没有其他作用。

部分依赖项依赖于主键中的任一属性。

不要使用“涉及”或“依赖”来给出定义。说“何时”或“仅当”（“仅当且仅当”）。

阅读定义。当/
iff使用行列式的适当子集时，持有的FD是部分的，而FD持有与确定的同一列相同的FD；否则，它已满。请注意，这不涉及CK。当所有非素数属性在功能上完全依赖于每个CK时，则关系为2NF。

传递依赖关系涉及功能依赖关系中的两个或多个非关键属性，其中一个非关键属性依赖于一个关键属性（来自我的PK）。

阅读定义。当/当存在X时，S-> T是可传递的，其中S-> X和X-> T而不是（X-> S）而不是（X =
T）。请注意，这不涉及CK。当所有非素数属性都非传递性地依赖于每个CK时，关系就是3NF。

“ 1NF”没有唯一含义。