iT邦幫忙

0

資料庫設計 (七) - 第一正規化實務案例 : 課程

  • 分享至 

  • xImage
  •  

設計「課程」資料表

本篇會繼續以第一正規化(1NF)的基本原則來設計一張課程資料表(subjects)。

初始設計:欄位與潛在問題

假設我們原本設計的學生資料表包含以下欄位:

  • 課程名稱(subject_name)
  • 課程類別(category)
  • 學生姓名(student_name)

缺乏唯一主鍵(Primary Key)

這張表中的三個欄位組合起來(subject_name, category, student_name)仍無法保證唯一性。舉例來說,同一課程與類別下,可能會出現兩位同名的學生。這代表這張表沒有一個能夠唯一識別每一筆資料的主鍵。

不穩定的業務欄位作為識別依據

  • subject_name(主題名稱):可能會因課程名稱變更(如「生物學導論」變成「生物學」)而改動,這會導致資料關聯混亂。
  • category(類別名稱):不是唯一值,無法區分每一筆資料。
  • student_name(學生名稱):同名者眾,無法唯一識別學生。

這些欄位都是「業務邏輯中的描述性資料」,而非設計上用來識別實體的穩定鍵值。因此,使用這些欄位作為主鍵或複合鍵是一種不良實踐。

引入主鍵欄位(Primary Key)

為了解決上述問題,我們應該引入「主鍵欄位」,例如 subject_id、student_id 等數值型、自動遞增的唯一鍵值。這些欄位不但可穩定識別每筆資料,也能用作其他資料表的外鍵,建立資料關聯。
以下是正規化後的資料表結構示意:

subject_id subject_name category student_id
1 Introduction to Biology Science 1001

總結

在初始設計中,subjects 表使用了 subject_name、category 和 student_name 等描述性欄位來儲存資料,卻缺乏一個穩定且唯一的主鍵。
透過導入主鍵 subject_id 與 students 資料表的主鍵 student_id 欄位使 subjects 表的結構將更具一致性、穩定性與可擴展性,也更容易與其他表格建立關聯關係。
subjects 表的案例清楚顯示了不應依賴名稱或描述性資料作為識別欄位的重要性。


圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言