關係型資料庫設計正規化

2021-10-04 21:44:47 字數 3172 閱讀 1551

首先要明白」正規化(nf)」是什麼意思。按照教材中的定義,正規化是「符合某一種級別的關係模式的集合,表示乙個關係內部各屬性之間的聯絡的合理化程度」。很晦澀吧?實際上你可以把它粗略地理解為一張資料表的表結構所符合的某種設計標準的級別。就像家裡裝修買建材,最環保的是e0級,其次是e1級,還有e2級等等。資料庫正規化也分為1nf,2nf,3nf,bcnf,4nf,5nf。一般在我們設計關係型資料庫的時候,最多考慮到bcnf就夠。符合高一級正規化的設計,必定符合低一級正規化,例如符合2nf的關係模式,必定符合1nf。

接下來就對每一級正規化進行一下解釋,首先是第一正規化(1nf)。

符合1nf的關係(你可以理解為資料表。「關係模式」和「關係」的區別,類似於物件導向程式設計中」類「與」物件「的區別。」關係「是」關係模式「的乙個例項,你可以把」關係」理解為一張帶資料的表,而「關係模式」是這張資料表的表結構。1nf的定義為:符合1nf的關係中的每個屬性都不可再分。表1所示的情況,就不符合1nf的要求。

表2但是僅僅符合1nf的設計,仍然會存在資料冗餘過大,插入異常,刪除異常,修改異常的問題,例如對於表3中的設計:

圖1例如:

部分函式依賴

假如 y 函式依賴於 x,但同時 y 並不完全函式依賴於 x,那麼我們就稱 y 部分函式依賴於 x,記作 x p→ y,如圖2

圖3

設 k 為某錶中的乙個屬性或屬性組,若除 k 之外的所有屬性都完全函式依賴於 k(這個「完全」不要漏了),那麼我們稱 k 為候選碼,簡稱為。在實際中我們通常可以理解為:假如當 k 確定的情況下,該錶除 k 之外的所有屬性的值也就隨之確定,那麼 k 就是碼。一張表中可以有超過乙個碼。(實際應用中為了方便,通常選擇其中的乙個碼作為主碼

例如:對於表3,(學號、課名)這個屬性組就是碼。該表中有且僅有這乙個碼。(假設所有課沒有重名的情況)

非主屬性

包含在任何乙個碼中的屬性成為主屬性。

例如:對於表3,主屬性就有兩個,學號課名

終於可以回過來看2nf了。首先,我們需要判斷,表3是否符合2nf的要求?根據2nf的定義,判斷的依據實際上就是看資料表中是否存在非主屬性對於碼的部分函式依賴。若存在,則資料表最高只符合1nf的要求,若不存在,則符合2nf的要求。判斷的方法是:

第一步:找出資料表中所有的

第二步:根據第一步所得到的碼,找出所有的主屬性

第三步:資料表中,除去所有的主屬性,剩下的就都是非主屬性了。

第四步:檢視是否存在非主屬性對碼的部分函式依賴

對於表3,根據前面所說的四步,我們可以這麼做:

第一步:

檢視所有每一單個屬性,當它的值確定了,是否剩下的所有屬性值都能確定。

檢視所有包含有兩個屬性的屬性組,當它的值確定了,是否剩下的所有屬性值都能確定。

……檢視所有包含了六個屬性,也就是所有屬性的屬性組,當它的值確定了,是否剩下的所有屬性值都能確定。

看起來很麻煩是吧,但是這裡有乙個訣竅,就是假如a是碼,那麼所有包含了a的屬性組,如(a,b)、(a,c)、(a,b,c)等等,都不是碼了(因為作為碼的要求裡有乙個「完全函式依賴」)。

圖4表示了表中所有的函式依賴關係:

圖5表4表示了模式分解以後新的資料

圖6新的資料表如表5

好,既然此關係模式已經屬於了 3nf,那麼這個關係模式是否存在問題呢?我們來看以下幾種操作:

先新增加乙個倉庫,但尚未存放任何物品,是否可以為該倉庫指派管理員?——不可以,因為物品名也是主屬性,根據實體完整性的要求,主屬性不能為空。

某倉庫被清空後,需要刪除所有與這個倉庫相關的物品存放記錄,會帶來什麼問題?——倉庫本身與管理員的資訊也被隨之刪除了。

如果某倉庫更換了管理員,會帶來什麼問題?——這個倉庫有幾條物品存放記錄,就要修改多少次管理員資訊。

從這裡我們可以得出結論,在某些特殊情況下,即使關係模式符合 3nf 的要求,仍然存在著插入異常,修改異常與刪除異常的問題,仍然不是 」好「 的設計。

造成此問題的原因:存在著主屬性對於碼的部分函式依賴與傳遞函式依賴。(在此例中就是存在主屬性【倉庫名】對於碼【(管理員,物品名)】的部分函式依賴。

解決辦法就是要在 3nf 的基礎上消除主屬性對於碼的部分與傳遞函式依賴。

倉庫(倉庫名,管理員)

庫存(倉庫名,物品名,數量)

這樣,之前的插入異常,修改異常與刪除異常的問題就被解決了。

以上就是關於 bcnf 的解釋。

最近身體不太舒服,寫不動了。有空再放幾個典型習題及其解答吧。

******************************=

問題1:

李德竹 :老師您好,我看了您關於資料庫正規化的回答,有一點不太理解,就是關於碼的定義,如果除k之外的所有屬性都完全函式依賴於k時才能稱k為碼,那麼在判斷2nf時又怎麼會存在非主屬性對碼的部分函式依賴這種情況?希望老師有時間能指點一下,謝謝

我 :在「碼」的定義中,除 k 之外的所有屬性應該看成是乙個集合 u(也就是乙個整體),也就是說,只有 k 能夠完全函式決定 u 中的每乙個屬性,那麼 k 才是碼。如果 k 只是能夠完全函式決定 u 中的一部分屬性,而不能完全函式決定另外一部分屬性,那麼 k 不是碼。

比如有關係模式 r (sno, sname, cno, cname, sdept, sloc, grade),其中函式依賴集為 f=

那麼 r 中的碼只能是 (sno, cno),sno 或 cno 並不能完全函式決定除 sno / cno 之外的所有其他屬性(其實就是不能決定 grade ),所以單獨的 sno 與 cno 並不能作為碼。

所以可得到主屬性:sno, cno

非主屬性:sname, cname, sdept, sloc, grade

r 中存在非主屬性 cname 對於碼 (sno, cno) 的部分函式依賴 (cno → cname) 。(還有很多別的例子就不一一枚舉了)。所以 r 不符合 2nf 的要求。

花了好幾天斷斷續續寫了這個答案,累死我了。看有不少人對此有疑問,乾脆寫乙個詳細點的,希望成為這個知識點的權威回答……如果有一些細節方面的問題,比如表達上,還會進行修改,大的方面,肯定是沒錯的。

編輯於 2017-10-26

​贊同 7590​

​分享

​收藏​喜歡收起​

關係型資料庫設計正規化

理解三大正規化 學後知變通 什麼是正規化 資料庫設計對資料的儲存效能和開發人員對資料的操作都有關係。所以建立科學的 規範的資料庫需要滿足一些規範。在關係型資料庫中這些規範就可以稱為正規化。三大正規化概念 第一正規化 當關係模式r的所有屬性都不能分解為更基本的資料單位時,稱r是滿足第一正規化的,簡記為...

關係型資料庫設計正規化

為了建立冗餘較小 結構合理的關聯式資料庫,設計關聯式資料庫時必須遵循一定的規則,即關聯式資料庫的設計正規化。關係型資料庫的第一正規化要求 舉例來說,客戶資料表中包含客戶名和位址,位址由城市和街道組成。應用經常需要分別訪問城市或街道字段。資料表customers name,city,street 是符...

關係型資料庫正規化

設計關聯式資料庫時,遵從不同的規範要求,設計出合理的關係型資料庫,這些不同的規範要求被稱為不同的正規化,各種正規化呈遞次規範,越高的正規化資料庫冗餘越小。目前關聯式資料庫有六種正規化 第一正規化 1nf 第二正規化 2nf 第三正規化 3nf 巴斯 科德正規化 bcnf 第四正規化 4nf 和第五正...