这些表是否尊重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. Are these tables respect the 3NF Database Normalization?
2. What if 2 authors work together for the same title?
3. The column Addresss should have it's own table?
4. When a reader borrows a book, I make an entry in BORROWING table. After he returns the book, I delete that entry and I make another one entry in HISTORY table. Is this a good idea? Do I brake any rule? Should I have instead one single BORROWING table with a DATE\_OF\_RETURNING column?

​

Answer 1

这看起来有点像家庭作业问题，但无论如何让我回答：

1. 不，表不在3NF中；具有代理键的表很少存在。例如，READERS表有两个候选主键: READER_ID和(First_Name，Last_Name)。当然，这取决于您的问题域:如果您愿意拥有两个名称、地址和电话相同的独立个体，那么它就在3NF中。而且，在我的经验中，3NF通常比它更麻烦。
2. ，这又取决于您的问题域。您可以通过中间表在作者和标题之间创建多对多的关系。
3. 参见1.
4. 您可以不用借用，创建一个完美工作的应用程序，因为历史包含您需要的所有信息。需要跟踪的信息越少，越好。--

Answer 2

我会把标题改为多到多，留下地址。

TITLES表

• TITLE_ID，PK
• NAME

TitleAutors表

• TITLE_ID，
• AUTHOR_ID

您可以更改借用表，使其具有条目的状态(OUT、IN、缺失、未知)并具有STATUS_DATE。

Answer 3

你怎么能指望任何人在不了解你的业务领域的情况下认真回答这个问题？

为了认真回答这个问题，我们需要知道支配您的数据的全部功能依赖关系，而您还没有提供这些依赖关系。

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