iT邦幫忙

0

資料庫設計 (九) - 第一正規化實務案例 : 大學

  • 分享至 

  • xImage
  •  

設計「大學」資料表

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

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

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

  • 大學名稱(university_name)
  • 大學地址(university_address)

該組合能唯一標識一筆資料嗎?答案是「可以」。
即使存在名稱相同的大學,它們的地址也不會相同。因此,名稱與地址的組合能唯一識別一筆紀錄。
然而,這樣的主鍵組合在實務上會帶來幾個問題:
主鍵值可能變動:若大學名稱或地址發生變動,將導致主鍵變動,這在資料設計上是非常不理想的。
對使用者或業務有意義的欄位不應作為主鍵:例如名稱和地址通常具有業務意義,變更頻率可能比純編號來得高。
與其他資料表保持一致性:其他資料表(如學生、老師)都已有獨立主鍵欄位(如 student_id、teacher_id),為了統一設計風格,我們應該為大學表格也加上一個唯一的主鍵欄位。

引入主鍵欄位(Primary Key)

因此,建議新增一個自動遞增或唯一識別的欄位 university_id 作為主鍵。這樣不僅提升資料一致性,也讓設計風格一致。

拆解非原子欄位

接下來,我們發現 address 欄位本身其實是一個「複合欄位」,它可能包含以下資訊:

  • 門牌號(unit_number)
  • 街道號碼(street_number)
  • 街道名稱(street_name)
  • 城市(city)
  • 州/縣市(state/province)
  • 郵遞區號(postal_code)
  • 國家(country)

這樣的複合資料應該拆解為多個欄位,才符合 1NF 中「欄位必須是原子值」的要求。更新後的表格如下:

university_id university_name unit_number street_number street_name city state postal_code country
1 Green Valley University 5B 123 Liberty Avenue Los Angeles CA 90001 USA

總結

在優化大學(universities)資料表時,為避免使用易變動的欄位作為主鍵,將原本的名稱與地址組合作為主鍵的設計,改為新增一個穩定的 university_id 欄位作為唯一識別。原本的地址欄位也進行標準化拆分,分為街道、城市、州、省、郵遞區號等欄位,以符合第一正規化(1NF)並提升資料查詢的彈性與一致性。此外,欄位命名風格與其他資料表(如學生與老師)統一,整體設計更具可維護性與擴充性。


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

尚未有邦友留言

立即登入留言