1

我已经分解了一种关系，它跟踪员工的关系以及他们在酒店工作的时间。原来的关系如下

R(national insurance number, contract Number, hours, eName, hotel Number,     hotel Location)

改写为

R(A, B, C, D, E, F)

我找到了功能依赖项

F:(A->D, E->F, AB->C, B->E, BA->E)

由此我创建了以下 3 个表

1.
Employees:
national insurance number(A)
eName(D)
PRIMARY KEY(A)


2.
Works at:
contract Number(B)
Hours(C)
national insurance number(A)
PRIMARY KEY(B, AND A)

3.
Hotel:
contract Number(B)
hotel Number(E)
hotel Location(F)
PRIMARY KEY(B)

在我的第三张表中，我有一个主键，可以确定酒店的数量和位置。但是酒店号码也可以确定酒店的位置。我应该将酒店位置移动到一张新桌子上，只有酒店号码吗？那会占用更多空间，但是否有必要达到 3RD 范式？

4

2 回答 2

1

当假设您导出的 FD 正确且完整时，要在您的设置中实现第三范式，确实有必要拆分Hotel(B,E,F) { B->E, E->F }为HotelContract(B,E) { B->E }和Hotel(E,F) { E->F }。形式上， in{ B->E, E->F }是B（唯一的）键，E是“非素数”属性（即不是任何键的一部分），因此F通过非素数属性传递地依赖于键。这违反了第三范式。

使用Hotel(B,E,F) { B->E, E->F }违反 3NF 的模式，您会得到“删除异常”，即从Hotel. 假设 的以下扩展Hotel：

Hotel
 B | E | F
---|---|---
b1 | e1| f1
b2 | e2| f2

当您删除 tuple(b2,e2,f2)时，您会丢失酒店e2所在的信息f2，尽管您只是想删除合同。

更糟糕的是，当您将方案翻译成

Hotel:
contract Number(B)
hotel Number(E)
hotel Location(F)
PRIMARY KEY(B)

那么您实际上省略了 FD E->F，这将允许同一家酒店e1获得两个不同的位置，例如f1和f2：

Hotel
 B | E | F
---|---|---
b1 | e1| f1
b2 | e1| f2  -> permitted by your scheme, but not intended!

因此，按照介绍中的建议拆分表格。

于 2017-03-07T00:11:42.040 回答
1

看来你是对的。酒店需要在单独的表中。

此外，我想员工有可能在不止一家酒店签订多份合同，而一家酒店可能与员工签订多份合同。

所以，对我来说，规范化的形式看起来像：

1. Employees:
   national insurance number(A)
   eName(D)
   PRIMARY KEY(A)

2. Hotels:
     hotel Number(E)
     hotel Location(F)
     PRIMARY KEY(E) 

3. Contracts:
    contract Number(B)
    hotel Number(E)
    PRIMARY KEY(B)
    FOREIGN KEY(Hotels.E)

4. Works at:
   work at(G),
   national insurance number(A)
   contract Number(B)
   Hours(C)
   PRIMARY KEY(G)
   FOREIGN KEY(Employees.A) 
   FOREIGN KEY(Contracts.B)
于 2017-03-07T00:13:20.103 回答