這些表是否符合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表來修復此問題，其中您有兩個用於作者和讀者表的外鍵。 只是一個想法... ;）