1

我正在使用一个表，该表具有一个复合主键，该主键由两个 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 名学生。
  • 每门课程仅由一名讲师教授。
  • 每个学生可能只有一个专业。
4

2 回答 2

2

从您的问题来看，您似乎对基础知识没有清楚的了解。

应用关系和情况

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

如果我们可以将一个标准改写为其他两个标准的 AND/连接，那么我们只需要具有这些其他标准的表格。这是因为定义了 JOIN，以便包含使它们的条件为真的行的两个表的 JOIN 返回使它们的条件的 AND/连接为真的行。所以我们可以JOIN这两个表来取回原来的。（这就是规范化通过将表分解为组件所做的事情。）

/* 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 关系”，那么他们必须已经记住实体之间的特定二进制应用关系；知道它以及什么应用情况可能会出现，他们报告它在某个方向上具有一定的基数。这将对应于一些应用程序关系和使用标识实体的列集的表。加上一些表示/方法将 FK 称为“关系”——将它们与这些关系混淆.)

查看“基于事实的”信息建模方法 Object-Role Modeling 或（其前身）NIAM。

FD & CK

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

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

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

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

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

阅读定义。当/当且仅当使用行列式的适当子集时，保持的 FD 是部分的，给出了具有相同确定列的 FD；否则它是满的。请注意，这不涉及 CK。当所有非主属性在功能上完全依赖于每个 CK 时，关系处于 2NF。

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

阅读定义。S -> T 是传递的，当/当且仅当 S -> X 和 X -> T 而不是 (X -> S) 而不是 (X = T) 的 X 时。请注意，这不涉及 CK。当所有非主属性都非传递地依赖于每个 CK 时，关系处于 3NF 中。

“1NF”没有单一的含义。

于 2014-12-10T13:39:50.253 回答
0

我在推断您的业务规则中未列出的功能依赖关系。即，讲师 ID 确定讲师姓名。

如果这是真的，并且如果您在课程表中同时拥有讲师 ID 和讲师姓名，那么这不在 3NF 中，因为课程 ID、讲师 ID 和讲师姓名之间存在传递依赖关系。

为什么这是有害的？因为在教师教授的每门课程中复制教师姓名会使更新教​​师姓名变得困难，并且可能以不一致的方式进行。不一致的讲师姓名只是您必须注意的另一个错误，而 3NF 消除了该问题。同样的论点也适用于教官办公室。

于 2014-12-10T12:57:25.467 回答