这些表是否在第三范式？

Question

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

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) 

从这个我已经创建了以下三个表格

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标准吗？

Answer 1

当您假设您推导出的FD是正确和完整的，为了在您的设置中达到第三范式，必须将Hotel(B,E,F) { B->E, E->F }分为HotelContract(B,E) { B->E }和Hotel(E,F) { E->F }。 形式上，在{ B->E, E->F }中，B是（唯一）密钥，E是“非首要”属性（即不是任何密钥的一部分），因此F通过非密钥属性传递依赖于密钥。这违反了第三范式。

对于违反3NF的模式Hotel(B,E,F) { B->E, E->F }，您将得到一个“删除异常”，即您从Hotel删除元组时丢失了更多信息。假设的Hotel以下扩展名：

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

当你删除的元组(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! 

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

Answer 2

看起来你是对的。酒店需要放在单独的桌子上。

另外我猜测员工有可能在多家酒店工作多个合同，而且一家酒店可能会为员工提供一个以上的合同。

所以，我规范化的形式将类似于：

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)