这些表是否尊重 3NF 数据库规范化？

Question

AUTHOR表

• Author_ID，PK
• First_Name
• Last_Name

TITLES表

• TITLE_ID，PK
• NAME
• Author_ID，FK

DOMAIN表

• DOMAIN_ID，PK
• NAME
• TITLE_ID，FK

READERS表

• READER_ID，PK
• First_Name
• Last_Name
• ADDRESS
• CITY_ID，FK
• PHONE

CITY表

• CITY_ID，PK
• NAME

BORROWING表

• BORROWING_ID,pk
• READER_ID，fk
• TITLE_ID，fk
• DATE

HISTORY表

• READER_ID
• TITLE_ID
• DATE_OF_BORROWING

• DATE_OF_RETURNING

  1. 这些表是否遵守 3NF 数据库规范化？
  2. 如果 2 位作者共同创作同一个标题会怎样？
  3. 地址列应该有它自己的表吗？
  4. 当读者借书时，我会在 BORROWING 表中输入一个条目。在他还书后，我删除了那个条目，并在 HISTORY 表中创建了另一个条目。这是一个好主意吗？我是否违反任何规则？我应该使用一个包含 DATE_OF_RETURNING 列的单个 BORROWING 表吗？

Answer 1

这看起来有点像家庭作业问题，但还是让我回答吧：

1. 不，表格不在 3NF 中；带有代理键的表很少。例如，READERS 表有两个候选主键：READER_ID 和 (First_Name, Last_Name)。当然，这取决于您的问题域：如果您愿意让两个不同的人具有相同的姓名、地址和电话，那么它在 3NF 中。此外，根据我的经验，3NF 通常麻烦多于其价值。
2. 同样，这取决于您的问题域。您可以通过中间表在 AUTHORS 和 TITLES 之间创建多对多关系。
3. 见 1。
4. 您可以省去 BORROWING 并创建一个完美运行的应用程序，因为 HISTORY 包含您需要的所有信息。您需要跟踪的信息越少越好。

Answer 2

我会将 Titles 更改为 MANY-TO-MANY，并留下地址。

TITLES表

• TITLE_ID，PK
• NAME

TitleAutors表

• TITLE_ID,
• AUTHOR_ID

您可以将 BORROWING 表更改为具有条目的状态（OUT、IN、MISSING、UNKNOWN）并具有 STATUS_DATE。

Answer 3

您如何期望任何人在不了解您的业务领域的情况下认真回答这个问题？

为了认真回答这个问题，需要了解管理数据的整套函数依赖关系，而你没有提供这些。

例如，如果您的方案在 3NF 中，则需要 domainID -> titleID，或者换句话说，每个域只有一个标题，并且知道该域意味着您可以知道标题。从表面上看，这似乎很奇怪，但唯一能确定这是否准确代表您正在处理的业务现实的人就是您。

Answer 4

在阅读其他 cmets 后，我想到的另一个想法是。

• 作者可以成为读者吗？ （反之亦然）

如果是这样，您的系统中可能输入了多余的名字和姓氏，并且很容易出现更新异常。例如，如果 Jane Smith 既是读者又是作者，并且她结婚了并且她的姓氏更改为 Williams，那么将存在更新她的读者姓氏而不是她的作者姓氏的可能性。

您可以通过创建一个 User 表来解决此问题，其中您有两个外键用于 Authors 和 Readers 表。只是一个想法... ;)