这些表是否符合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. 列Addresss应该拥有自己的表吗？
  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表

• TITLE_ID ，PK
• NAME

TitleAutors表

• TITLE_ID ，
• AUTHOR_ID

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

Answer 3

在没有任何业务领域知识的情况下，您如何期望任何人认真回答这个问题？

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

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

Answer 4

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

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

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

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