这些表是否符合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

我会将标题更改为MANY-TO-MANY，并保留地址。

TITLES表

• TITLE_ID，PK
• NAME

TitleAutors表

• TITLE_ID，
• AUTHOR_ID

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

Answer 3

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

为了认真回答这个问题，我们需要知道管理数据的整套功能依赖，而你却没有提供这些依赖。

例如，对于3NF的方案，它需要domainID - ＆gt; titleID，或换句话说，每个域只有一个标题，知道域意味着你可以知道标题。从表面上看，这似乎很奇怪，但唯一能够确定这是否是您正在处理的商业现实的准确表现的人就是您。

Answer 4

在阅读其他评论之后，我想到了另一个想法。

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

如果是这样，您可能会在系统中输入多余的名字和姓氏，并且可能会更新异常。例如，如果简史密斯是读者和作者并结婚并且她的姓氏改为威廉姆斯，则存在更新她的读者姓氏而不是她的作者姓氏的可能性。

您可以通过创建一个User表来修复此问题，其中您有两个用于作者和读者表的外键。只是一个想法...;）