database - 第三范式的表，但有明显的冗余

Question

假设有以下 Reservations 表。 Reservation_Number 是唯一的候选键:

Reservation_Number  Guest_Name  
------------------  ------------
1                   john smith  
2                   john smith  
3                   john smith  
4                   jane doe  
5                   bob anderson  

这个表是第三范式吗？

1. 它不违反第一范式。当一个表有一个主键并且每个属性的域仅包含原子值，并且每个属性的值仅包含来自该域的单个值时，该表处于 1NF 中。 Reservation_Number 是主键，Reservation_Number 和 Guest_Name 都满足原子标准。
2. 它不违反第二范式。当表处于 1NF 时，它处于 2NF，并且表的每个非主要属性都依赖于每个候选键的整体。 Guest_Name 是唯一的非主要属性，它完全依赖于唯一的候选键 Reservation_Number。
3. 它不违反第三范式。当表处于 2NF 时，它处于 3NF，并且表的每个非主要属性都非传递地依赖于表的每个超键。唯一的非主要属性 Guest_Name 非传递地依赖于唯一的 super 键 Reservation_Number。

但是这个表中有冗余。我可以通过以下方式删除这些冗余:

1. 使用 Guest_Id 和 Guest_Name 创建一个 Guest 表。
2. 用 Guest_Id FK 替换 Reservations 表中的 Guest_Name。

原始的 Reservations 表怎么可能是第三范式，但在 Guest_Name 中却有冗余？如果它违反了正常形式，那么如何以及为什么？

Answer 1

您的示例不会违反第二和第三范式，但是如果您添加一列 Guest_Telephone 会怎么样。那么第三范式将被违反，因为您在 Guest_Name 和 Guest_Telephone 之间具有函数依赖性。

你可以记住:

如果关系是第二范式并且键中只有一个附加属性，那么它自动是第三范式。

在您的示例中，您可以简单地将属性名称 Guest_Name 修改为 Reservation_Description，冗余指示将不再那么明显。

同时尝试将 Guest_Name 拆分为两个属性 Guest_Firstname 和 Guest_Lastname，会发生什么情况？

仅指示冗余并不意味着您使用前 3 种正常形式中的一种，但正如您所说的正确，最好将预订和客人分开。

最后要提到的一件事

您的属性 Guest_Name 可以被视为一个键，没有要求键必须是一个数字。考虑一下您的酒店(或您的预订表是为了什么)容纳“数字”而不是人(好吧，我希望你有强大的想象力......)。拥有这样的架构是否有意义:

Reservation_PK Guest_FK
1              1
2              2
3              1

Guest_PK Guest_Name
1        34
2        57

当然不是，您可以将 Guest_Name 保留在原处:

Reservation_PK Guest_Name
1              34
2              57
3              34

因此，如果您不想保存除客人姓名以外的任何其他属性，我会将您的预订表保留原样(它甚至完全满足普通表格 3 的所有要求)。