iT邦幫忙

第 12 屆 iThome 鐵人賽

DAY 25
0
AI & Data

與資料庫共舞系列 第 25

Day 25 — 建構嚴謹的資料庫 (下)

  • 分享至 

  • xImage
  •  

延續昨天正規化的討論,我們今天要先來看支配的封閉性 (Closure)。某種程度來說,封閉性就是使用昨天最後提到的支配關係衍伸的推導。我們再這邊一樣在乎的是,當我拿到一些支配關係,要怎麼樣推導讓左邊的欄位可以獨一無二判斷右邊的欄位,這樣講有一點抽象就讓我們看一個例子。

下面這個例子這邊為了讓討論過程簡化一點,我們就用 A, B, C, D, E來表示某一組資料的5個欄位

A, B --> C
A  D --> E
   B --> D
A, F --> B

這時候我就可以推出

{A, B} 的封閉性
第一步 -- A, 沒有可以直接支配的欄位 {A}
第二步 -- B, 支配 D               {A, B, D}
第三步 -- A B, 支配 C             {A, B, D, C}
第四步 -- A D, 支配 E             {A, B, D, C, E}
第五步 -- 其他都沒有
AB 無法支配 F

同理, AF 的封閉性可以推導出 {A, F, B, D, C, E},這時候我們就會把 (A, F) 視為候選鍵 (Candidate Key)。既然又了上面這個清楚的步驟,我們就可以用程式把所有的候選鍵都選出來,這時候只需要找最短的候選鍵,就可以當作我們的Key 了。

所以今天如果我給了你下面的資料

  1. Student (StudentID, Name, Class, Height)
  2. StudentID → Name, Class; Class → Height

這時候用上面的方式推導就會發現,只有 StudentID 可以當作這個資料的Key。

回到正規化

為什麼推導出這個 Key (或是Super Key) 這麼重要,那是因為我們如果要符合 BCNF 沒有重複欄位的要求,那我就必須要找到可以獨一無二代表所有欄位的鍵,資料再拆成關係表的時候也才會是正確的拆法。一樣直接看例子

Student (StudentID, Name, Age, Class, Gender, Phone)
F1: StudentID -> Name, Age, Class
F2: Class -> Gender

這個範例中,我們看到學生的關係表中有: 學生編號、姓名、年齡、班級、性別和手機號碼,我們的第一個支配關係是學生編號可以獨一無二的辨識學生的姓名、年齡、跟班級,第二個支配關係是由班級可以直接辨識出性別。於是我們就可以推導出:

StudentID -> Name, Age, Class, Gender

這首麻煩了,所有的支配關係都用完了,但是手機這個欄位卻沒有辦法被獨一無二的辨識。這時候我們就會把可以辨識的放一邊 (一個表)、不能辨識的放一邊 (一個表),不能辨識的表,直接使用有支配關係的左手邊欄位

Student (StudentID, Name, Age, Class, Gender)
Phone (StudentID, Phone)

BCNF,非常的嚴格,這時候我們發現在第一個表格中有兩個支配關係,所以我們就可以再試著把它拆解:

Student (StudentID, Name, Age, Class)
Class (Class, Gender)
Phone (StudentID, Phone)

如此一來我們就會發現這三個表格之間都不在會除了外部鍵以外不必要的重複值。你可能會想說: 真的有必要這麼麻煩嗎? 我們來看一個隨便把關係拆成兩個關聯表的例子吧:

https://ithelp.ithome.com.tw/upload/images/20200925/20129829MwBZi6ERYm.png

我們假設存在上面的那個關聯表這個表格可以把他寫成這樣子的表示 T(A, B, C)。這是我們決定把這個關聯隨意的裁成(A, B) 和 (B, C),完全不去管欄位之間的支配關係。這時候當我要把這兩個表格重新用自然鏈結 (Natural Join) 的時候會發生一個很嚴重的問題,怎麼會莫名其妙跑出兩筆新的資料呢?

https://ithelp.ithome.com.tw/upload/images/20200925/20129829gC3jJNzvbm.png

這就是為什麼,我們需要透過正規化的過程,來做表格的拆解。這樣子的拆解過程,不僅可以減少重複出現的值,也可以保證資料拆解的過程下,不會造成損失或者是錯誤。然而因為 BCNF 在拆解表格的過程非常的嚴格,所以在這個正規化的過程裡,有的時候會上喪失原本定義的支配關係,這就是為什麼有另外一種正規劃叫做 3NF。3NF 比 BCNF 少一點嚴謹度 (規則相較鬆散),在資料上會出現多一點的重複,但3NF 底下仍然會保持所有的支配關係。礙於時間和篇幅,我們在這裡就不細講3NF,但原則上,3NF 與 BCNF 的推導過程大同小異,有興趣的讀者可以在網路上找找看範例,就可以知道要怎麼樣讓資料關係符合 3NF 的條件。

接下來的三天,我們要再往資料庫核心走一點,看看資料庫的資料到底怎麼存的? 索引? B+ 樹? 哈希表?


上一篇
Day 24 — 建構嚴謹的資料庫 (上)
下一篇
Day 26 — 出來吧,索引。
系列文
與資料庫共舞30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言