将关系转换为3NF

Question

给定的FD是 -

Epmployee#→Dept#,Manager# 
Dept#→Manager# 
course#→course_title

表格是 - 我已将其分解为3个关系。他们在3NF。

R1 (Employee#, Dept#)  --- Employee is PK
R2 (Employee#, Course#, course_title, date)  --- Emp# and Course# are PK
R3 (Dept#, Manager#) --- Dept# is PK

主键如上所述。
但是，当我将数据插入R2时，我发现主键冲突。它是红色的。 我哪里错了？任何帮助将非常感激。

Answer 1

错误是因为您的表中已经有这样的记录。结帐

002  ta01 Time Management 2014

而且仅供参考，这不是第三种正常形式。课程标题不应该在R2中出现。您应该有一个名为“{1}}”的课程表，它只是应该出现在R2中的课程编号（TA01等）

Answer 2

您的案例中的正确分解如下：

R1(Dept#, Manager#), with the only dependency Dept# → Manager#, so Dept# is the key
R2(Employee#, Dept#), with the only dependency Employee# → Dept#, with key Employee#
R3(Course#, Course_title), with the only dependency Course# → Course_title and key Course#
R4(Employee#, Course#, Date), with no dependency and key (Employee#, Course#, Date)

所有的关系都是Boyce-Codd Normal Form（因此他们也是3NF）。

最后请注意，人们可能想要合并两个关系R2和R4，但这会产生一个不在4NF中的分解（因为员工只有一个部门，但可以遵循几个课程）。

Answer 3

--- Emp# and Course# are PK

注意PK（主键）与规范化无关。 CK（候选键）很重要。

{employee＃，course＃}不是R2的CK，因为它不确定日期。唯一的CK是{employee＃，course＃，date}。

  

他们在3NF。

R2不在3NF或2NF中，因为非素列course_name在功能上依赖于CK，因为它在功能上依赖于{course＃}，CK的正确/较小子集。 （即使CK是你所声称的{employee＃，course＃}，也是如此。）无损分解导致{course＃，course_title}和{employee＃，course＃，date}上的3NF表。

Course# -> Course_title

这对原始表没有意义，因为它们不是它的列。说一门课程只有一个标题确实很有意义。这确实意味着在具有明显含义的那些列的表中，{course＃} - ＆gt; {课程名称}。这也意味着原始表受到一定的约束;它只是不是FD（功能依赖）约束。

  

写道，如果有多值属性，那么我应该形成一个新表并将表的主键（Employee＃）传播到新表中，并将它们都传递给复合PK。 [你的评论]

在原始表中，每个训练值都是一组记录。为了摆脱不属于CK的 set 列，我们可以使用某些CK的列拆分表，以获得一个新表，其中每个原始表CK子行的配对都有一行具有set元素的值。这里的集合元素是记录。在我们摆脱set列后，我们可以摆脱记录列。要删除记录列，我们将其替换为其字段的列。 现在应用 给你的R2。

最初摆脱表值列被Codd称为“规范化”。然后通过“进一步归一化”，Codd意味着无损分解为更高的正规形式。有时摆脱集值或记录值的列称为“规范化”。但事实并非如此。它只是改进设计。有时“标准化”用于表示无论是否有任何表值列，都会无损分解为更高的正规形式。

  

我为此创建了一个不同的表R2，R2已经在2NF [由你评论]

每当您更换其他人的表时，您必须确定新表的FD，CK和＆amp; NFS。如果无损地分解为更高的NF ，那么您就知道每个组件的最高NF高于原始NF。但是在这里你正在进行不同的转换 - 摆脱设置和记录列。这里R2的CK和FD涉及课程意味着它不在2NF，即使原来是。涉及原始关系课程的非FD约束导致某个FD在R2中持有。

  

我觉得约会应该是某些FD的一部分。 [你的评论]

也许你试图说你希望一个特定的员工只能在一年内参加一门课程。但这不是我们所说的。