理解數據庫範式
系統是短暫的
數據是永恆的
數 據庫範式是數據庫設計中必不可少的知識,沒有對範式的理解,就無法設計出高效率、優雅的數據庫。甚至設計出錯誤的數據庫。而想要理解並掌握範式卻並不是那 麼容易。教科書中一般以關係代數的方法來解釋數據庫範式。這樣做雖然能夠十分準確的表達數據庫範式,但比較抽象,不太直觀,不便於理解,更難以記憶。
本 文用較爲直白的語言介紹範式,旨在便於理解和記憶,這樣做可能會出現一些不精確的表述。但對於初學者應該是個不錯的入門。我寫下這些的目的主要是爲了加強 記憶,其實我也比較菜,我希望當我對一些概念生疏的時候,回過頭來看看自己寫的筆記,可以快速地進入狀態。如果你發現其中用錯誤,請指正。
下面開始進入正題:
一、基礎概念
要理解範式,首先必須對知道什麼是關係數據庫,如果你不知道,我可以簡單的不能再簡單的說一下:關係數據庫就是用二維表來保存數據。表和表之間可以……(省略10W字)。
然後你應該理解以下概念:
實體:現實世界中客觀存在並可以被區別的事物。比如“一個學生”、“一本書”、“一門課”等等。值得強調的是這裏所說的“事物”不僅僅是看得見摸得着的“東西”,它也可以是虛擬的,不如說“老師與學校的關係”。
屬性:教科書上解釋爲:“實體所具有的某一特性”,由此可見,屬性一開始是個邏輯概念,比如說,“性別”是“人”的一個屬性。在關係數據庫中,屬性又是個物理概念,屬性可以看作是“表的一列”。
元組:表中的一行就是一個元組。
分量:元組的某個屬性值。在一個關係數據庫中,它是一個操作原子,即關係數據庫在做任何操作的時候,屬性是“不可分的”。否則就不是關係數據庫了。
碼:表中可以唯一確定一個元組的某個屬性(或者屬性組),如果這樣的碼有不止一個,那麼大家都叫候選碼,我們從候選碼中挑一個出來做老大,它就叫主碼。
全碼:如果一個碼包含了所有的屬性,這個碼就是全碼。
主屬性:一個屬性只要在任何一個候選碼中出現過,這個屬性就是主屬性。
非主屬性:與上面相反,沒有在任何候選碼中出現過,這個屬性就是非主屬性。
外碼:一個屬性(或屬性組),它不是碼,但是它別的表的碼,它就是外碼。
二、6個範式
好了,上面已經介紹了我們掌握範式所需要的全部基礎概念,下面我們就來講範式。首先要明白,範式的包含關係。一個數據庫設計如果符合第二範式,一定也符合第一範式。如果符合第三範式,一定也符合第二範式…
第一範式(1NF):屬性不可分。
在前面我們已經介紹了屬性值的概念,我們說,它是“不可分的”。而第一範式要求屬性也不可分。那麼它和屬性值不可分有什麼區別呢?給一個例子:
name |
tel |
age |
|
大寶 |
13612345678 |
22 |
|
小明 |
13988776655 |
010-1234567 |
21 |
Ps:這個表中,屬性值“分”了。
name |
tel |
age |
|
手機 |
座機 |
||
大寶 |
13612345678 |
021-9876543 |
22 |
小明 |
13988776655 |
010-1234567 |
21 |
Ps:這個表中,屬性 “分”了。
這兩種情況都不滿足第一範式。不滿足第一範式的數據庫,不是關係數據庫!所以,我們在任何關係數據庫管理系統中,做不出這樣的“表”來。
第二範式(2NF):符合1NF,並且,非主屬性完全依賴於碼。
聽起來好像很神祕,其實真的沒什麼。
一 個候選碼中的主屬性也可能是好幾個。如果一個主屬性,它不能單獨做爲一個候選碼,那麼它也不能確定任何一個非主屬性。給一個反例:我們考慮一個小學的教務 管理系統,學生上課指定一個老師,一本教材,一個教室,一個時間,大家都上課去吧,沒有問題。那麼數據庫怎麼設計?(學生上課表)
學生 |
課程 |
老師 |
老師職稱 |
教材 |
教室 |
上課時間 |
小明 |
一年級語文(上) |
大寶 |
副教授 |
《小學語文1》 |
101 |
14:30 |
一個學生上一門課,一定在特定某個教室。所以有(學生,課程)->教室
一個學生上一門課,一定是特定某個老師教。所以有(學生,課程)->老師
一個學生上一門課,他老師的職稱可以確定。所以有(學生,課程)->老師職稱
一個學生上一門課,一定是特定某個教材。所以有(學生,課程)->教材
一個學生上一門課,一定在特定時間。所以有(學生,課程)->上課時間
因此(學生,課程)是一個碼。
然而,一個課程,一定指定了某個教材,一年級語文肯定用的是《小學語文1》,那麼就有課程->教材。(學生,課程)是個碼,課程卻決定了教材,這就叫做不完全依賴,或者說部分依賴。出現這樣的情況,就不滿足第二範式!
有什麼不好嗎?你可以想想:
1、 校長要新增加一門課程叫“微積分”,教材是《大學數學》,怎麼辦?學生還沒選課,而學生又是主屬性,主屬性不能空,課程怎麼記錄呢,教材記到哪呢? ……鬱悶了吧?(插入異常)
2、 下學期沒學生學一年級語文(上)了,學一年級語文(下)去了,那麼表中將不存在一年級語文(上),也就沒了《小學語文1》。這時候,校長問:一年級語文(上)用的什麼教材啊?……鬱悶了吧?(刪除異常)
3、 校長說:一年級語文(上)換教材,換成《大學語文》。有10000個學生選了這麼課,改動好大啊!改累死了……鬱悶了吧?(修改異常)
那應該怎麼解決呢?投影分解,將一個表分解成兩個或若干個表
學生 |
課程 |
老師 |
老師職稱 |
教室 |
上課時間 |
小明 |
一年級語文(上) |
大寶 |
副教授 |
101 |
14:30 |
學生上課表新
課程 |
教材 |
一年級語文(上) |
《小學語文1》 |
課程的表
第三範式(3NF):符合2NF,並且,消除傳遞依賴
上面的“學生上課表新”符合2NF,可以這樣驗證:兩個主屬性單獨使用,不用確定其它四個非主屬性的任何一個。但是它有傳遞依賴!
在哪呢?問題就出在“老師”和“老師職稱”這裏。一個老師一定能確定一個老師職稱。
有什麼問題嗎?想想:
1、 老師升級了,變教授了,要改數據庫,表中有N條,改了N次……(修改異常)
2、 沒人選這個老師的課了,老師的職稱也沒了記錄……(刪除異常)
3、 新來一個老師,還沒分配教什麼課,他的職稱記到哪?……(插入異常)
那應該怎麼解決呢?和上面一樣,投影分解:
學生 |
課程 |
老師 |
教室 |
上課時間 |
小明 |
一年級語文(上) |
大寶 |
101 |
14:30 |
老師 |
老師職稱 |
大寶 |
副教授 |
BC範式(BCNF):符合3NF,並且,主屬性不依賴於主屬性
若關係模式屬於第一範式,且每個屬性都不傳遞依賴於鍵碼,則R屬於BC範式。
通常BC範式的條件有多種等價的表述:每個非平凡依賴的左邊必須包含鍵碼;每個決定因素必須包含鍵碼。
BC範式既檢查非主屬性,又檢查主屬性。當只檢查非主屬性時,就成了第三範式。滿足BC範式的關係都必然滿足第三範式。
還可以這麼說:若一個關係達到了第三範式,並且它只有一個候選碼,或者它的每個候選碼都是單屬性,則該關係自然達到BC範式。
一般,一個數據庫設計符合3NF或BCNF就可以了。在BC範式以上還有第四範式、第五範式。
第四範式:要求把同一表內的多對多關係刪除。
第五範式:從最終結構重新建立原始結構。
但在絕大多數應用中不需要設計到這種程度。並且,某些情況下,過於範式化甚至會對數據庫的邏輯可讀性和使用效率起到阻礙。數據庫中一定程度的冗餘並不一定是壞事情。如果你對第四範式、第五範式感興趣可以看一看專業教材,從頭學起,並且忘記我說的一切,以免對你產生誤導。