规范化两列表

Question

我正在尝试规范化数据库，我们目前有一个名为BOOK的表，其中ISBN（FK）和CoverType是列，它们连接在一起制作PK。

即

BOOK

|       ISBN       |  CoverType  |
|__________________|_____________|
|  978-0132354790  |   Hardback  |
|  978-0132354790  |   Paperback | 

此表已经标准化了吗？我假设它是，但我背后并没有多少理由。 感谢

Answer 1

因为它在您的帖子中BOOK(ISBN, COVERTYPE)被规范化，因为您的所有字段都是单值的，并且主键的任何部分都不能从它的子集中派生出来（例如，您无法分辨哪些是全部的只需查看ISBN本身就可以获得ISBN的CoverTypes，反之亦然。

Answer 2

假设将添加更多行，您可以预期“Hardback”和“Paperback”之类的值将被复制。将它们移动到单独的表（例如“CoverType”并加入ID？

）是否有意义

Answer 3

  

此表已经标准化了吗？

首先是警告，然后是答案。

谨慎

关系建模中的某些术语具有非常具体的含义。 规范化不是其中之一，至少当有人按照您的方式使用它时。

有问题的是，“这个表是否在3NF？”或“这个表是否在5NF？”，但是询问它是否正常化是没有意义的。仅在SO上，您可以找到“这是规范化”的答案

• 它在3NF
• 它在5NF
• 它有一个身份证号码
• 它少于20列
• 所有文字已被ID号替换

只有前两个才有意义。其余的与标准化完全无关。

最后，我的回答

我假设您的数据有意义。我从未处理过比会计层面更详细的书籍，所以我从来不需要知道ISBN和封面类型如何协同工作。

你可以像这样建立你的桌子。

create table books (
  isbn varchar(13) not null,
  cover_type varchar(10) not null,
  primary key (isbn, cover_type)
);

如果你这样做，你就没有非素数属性（所有列都是至少一个候选键的一部分），所以你至少有2NF。没有传递依赖，所以你至少有3NF。没有多值依赖，所以至少4NF。根本没有连接依赖关系，因此您处于6NF或“最终正常形式”。

在现实生活中，您需要对这些列进行更多限制。我建议至少两个。

1. “cover_type”上的检查约束或外键约束。
2. 计算并比较“isbn”的校验位。

如果您只是导入，则可以在导入之前编写外部程序以验证校验位。

Answer 4

我不确定不关于它的标准化是什么......

如果还有什么我不知道，但从我看到的情况来看，它看起来很好。

Answer 5

实际上在那张桌子上没有多少规范化......你没有裁员也没有关系。看起来很好。