MySQL - 從第一範式移動到第二和第三範式

這個問題直接關係到前一個主題「MySQL - 從平臺移動到第一範式」（http://bit.ly/9pvS0Y） - 現在我正在問一個問題關於轉向第二和第三範式，我認爲最好開始一個新的話題。MySQL - 從第一範式移動到第二和第三範式

下面是我的第一個正常表單模式，我非常確定已經足夠用於我的目的，但如果我錯了，請糾正我。

我想知道如何將其轉移到第二個和第三個窗體，關於我的表如何受2NF和3NF規則影響的任何指針將非常有用，謝謝。

關係

- 活動和位置關係=一對多 - 一個活動可以具有一個位置，一個位置可以有許多活動（LocationID如FK在活動）

- 活動和周關係=一對多 - 一項活動可以有一週，一週可以有很多活動（WeekID爲活動中的FK）

- 的用戶和活動 =多對多 - 一個用戶可以有多個活動，一個活動可以有很多用戶

User Table - UserID PK 
+------------+-----------+ 
| UserID     | Username  | 
+------------+-----------+ 
|            |           | 
+------------+-----------+ 


Activity Table - ActivityID PK/WeekID FK/LocationID FK 
+------------+-----------+------------+-----------+------------+-------------+-----------+ 
| ActivityID | UserID    | WeekID    | Day       | Minutes    | LocationID  |   Miles   | 
+------------+-----------+------------+-----------+------------+-------------+-----------+ 
|            |           |            |           |            |             |           | 
+------------+-----------+------------+-----------+------------+-------------+-----------+ 


Location Table - LocationID PK 
+------------+---------------+ 
| LocationID | Location_Name | 
+------------+---------------+ 
|            |               | 
+------------+---------------+ 


Weeks Table - Week ID PK 
+------------+-----------+ 
|WeekID    | Week_No   |    
+------------+-----------+ 
|            |           | 
+------------+-----------+ 


User_Activity Table 
+------------+---------------+ 
| UserID  | ActivityID | 
+------------+---------------+ 
|            |               | 
+------------+---------------+

來源

2010-08-11 Dave

居然沒有:)我必須建立這個應用程序，並認爲這將是最合乎邏輯和堅實的基礎。我開始想知道，通過表單移動對我來說是否實際上是有益的，或者它是否是更「最佳實踐」的數據庫設計方式，對我的需求並不特別有用（畢竟這是一個小應用程序）。如果我擁有足夠紮實的基礎，那麼很好，我很樂意聽到我在學習時的意見。 – Dave 2010-08-11 20:39:50

對給定的NF進行標準化並不是通過降低NF來完成的。這可以消除更好的高NF設計。一個使用適當的算法。此外，一個從FD（字段是其他字段的函數）和JD（一個關係是其某些投影的連接）開始。查看學術教科書/演示文稿/課程。 – philipxy 2017-07-21 21:57:04

不知道你有表User_Activity的目的，因爲你已經在你定義的兩列活動表。否則 - 這種設計已經進入第三範式。

來源

2010-08-11 20:38:42 Russ

感謝@russjudge，User_Activity的目的是作爲UserID和AcivityID之間關係的映射表，儘管也許我錯誤地理解了映射的概念。 – Dave 2010-08-11 20:45:01

如果您的Activity表以其排除userID列的方式進行定義，那麼您在User表和Activity表之間具有多對多關係，那麼User_Activity表就很有意義。但是，按照您定義活動表的方式，您建議採用一對多關係，即每個用戶可以有多個活動，但是對於每個活動，只有一個用戶。 – Russ 2010-08-12 12:33:49

除非這是一個學術活動，否則我建議你不要「移動」正常形式。該過程的正式名稱是通過分解歸一化。然而，在大多數情況下這不是很實際，通常完全沒有必要。

實際上，從已經假設標準化的模式開始（通常針對5NF或BCNF而不是3NF），然後驗證它。設計已經處於期望NF的模式的過程稱爲歸一化合成，它比分解方法更接近大多數從業者的工作方式。有幾種精確的技術可以通過合成實現標準化，但目前最常用的方法只是良好的分析，經驗和常識的組合。

來源

2010-08-11 21:44:10 sqlvogel

正如russjudge所說，我看不到User_Activity表的用途。

在規範化過程中，儘可能使用自然鍵是最佳實踐。因此，我無法看到Weeks表的要點 - 爲什麼不使用Week_No？（這裏可能出現的一個例外情況是，如果您想設置「星期」，並在其中包含不同的天數 - 在這種情況下，您可能還希望在Weeks表中包括開始日期和結束日期。沒有看到這一點。）

事實上，我會走得更遠，用一個日期字段替換Activity表上的每週和每天 - 實際上它應該是1NF的一部分（刪除派生數據）。根據需要，大多數SQL版本（包括MySQL）都可以輕鬆地將日期字段轉換爲一天或一週。

我也會試圖刪除ActivityID字段，而是使用UserID，Date和LocationID的組合作爲Activity表上的複合主鍵。但是，可能需要爲同一用戶，日期和位置記錄多行 - 在這種情況下，ActivityID字段應保留爲表的主鍵。

來源

2010-08-12 11:01:07

如果「Week_no」表示「周編號」，則將「Week_no」移動到「活動」中，並刪除表「周」。

來源

2011-01-15 11:26:13

MySQL - 從第一範式移動到第二和第三範式

回答

相關問題