設有關系模式R<U,F>，其中U = {A,B,C,D,E},F={A→D,CE→D,BC→D,DC→A},試求:

1.求出R的所有候選關鍵字

一、從關系模式到函數依賴到現實模型

數學可以看作是現實世界的高度抽象，所以當我們初次看到CE→D這樣的依賴時，可能會無法理解，但如果我們把它轉化為現實世界中的關系模型又會如何呢，比如這樣:

（學生，課程）→老師

（學生，老師）→課程

我們很容易就可以看出這個模型的意義，學生和課程可以確認一位老師，而學生和老師又可以確認一門課程，那麽什麽是候選鍵呢，我之前還只會一些淺顯的SQL語句時，把它同主鍵等同起來，當然，這導致我以後在做關系模式的題時，屢屢出錯，而弄清這些模型必要的概念，更是搞懂範式的意義的關鍵。

回到現實背景來，關系模式(學生,老師,課程) 其中每一個老師只教一門課，每門課有若幹老師，某一學生選一門課就對應一個老師。這樣的又如何與抽象的數學符號組成的關系模式來對比學習呢?不如我們先假設我們現在要根據這個模式開發一個table，那麽學生老師課程中，誰做主鍵比較合適呢，沒錯，你很快就會發現問題，這三個屬性似乎只能以組合的形式才能唯一確定所有屬性，比如你並不能以學生作為主屬性，而唯一確定老師和課程，而通過(學生，老師)或(學生，課程)卻能把這三個關系牢牢的聯系在一起，所以說這就是候選碼的意義，以候選碼為圓心使所有屬性聯系在一起，而所謂主屬性正是候選碼裏的屬性值，是屬於關系。那麽第1題也就有了答案，以哪個或那幾個抽象數學符號可以通過函數依賴關系聯系起來U中所有元素?顯然，答案是BCE。

2.試將R分解為BCNF,並具有無損連接性

二、由關系模式分解到合理設計E-R圖到大型項目中的數據庫關系啟發

事實上，合理設計，或者設計合理的數據庫是很難的，比如你要開發一個管理系統，期間糾纏的各種屬性單純用腦子理好像是那麽回事，但當把它實現出來時，你會發現一團亂麻，範式的意義就在這，把你從幾十上百個屬性中理清正確的關系，才能做後續的開發，我甚至私認為，一個項目最最重要的，就是數據庫的合理設計，這是現在常說的模塊化開發的前提，MVC開發的基本思想就是模塊化，甚至微服務都是模塊化，而什麽決定了模塊化?正是範式。

比如這一問，讓你從這些復雜的依賴中，分解出BCNF範式，就如同讓你從管理系統各種各樣的似是而非的對應屬性之間理出清楚的模塊去開發一樣，那麽，什麽是BCNF?如那個學生老師例子，可以明顯看出它是符合3NF的(事實上，所有元素都是主屬性的關系確實都可以達到3NF)既然，已經到了3NF這一較好的範式水準，為何還要繼續嘗試，這得談談BCNF優於3NF的地方，BCNF意味著在關系模式中每一個決定因素都包含候選鍵，也就是說，只要屬性或屬性組A能夠決定任何一個屬性B，則A的子集中必須有候選鍵。BCNF範式排除了任何屬性(不光是非主屬性，2NF和3NF所限制的都是非主屬性)對候選鍵的傳遞依賴與部分依賴。假設倉庫管理關系表為StorehouseManage(倉庫ID, 存儲物品ID, 管理員ID, 數量)，且有一個管理員只在一個倉庫工作；一個倉庫可以存儲多種物品。這個數據庫表中存在如下決定關系：

(倉庫ID, 存儲物品ID) →(管理員ID, 數量)

(管理員ID, 存儲物品ID) → (倉庫ID, 數量)

所以，(倉庫ID, 存儲物品ID)和(管理員ID, 存儲物品ID)都是StorehouseManage的候選關鍵字，表中的唯一非關鍵字段為數量，它是符合第三範式的。但是，由於存在如下決定關系：

(倉庫ID) → (管理員ID)

(管理員ID) → (倉庫ID)

倉庫I是決定因素，但倉庫ID不包含候選鍵(candidate key,也就是候選碼，簡稱碼)。

同樣的，管理員ID也是決定因素，但不包含候選鍵。

所以該表不滿足BCNF。

我們可以得出3NF的缺點為

"存在主屬性對候選關鍵字的傳遞依賴，同樣也會帶來麻煩。"

這裏也有一個很好的例子，是從別人的博客裏看來的

配件管理關系模式 WPE（WNO，PNO，ENO，QNT）分別表倉庫號，配件號，職工號，數量。有以下條件

a.一個倉庫有多個職工。

b.一個職工僅在一個倉庫工作。

c.每個倉庫裏一種型號的配件由專人負責，但一個人可以管理幾種配件。

d.同一種型號的配件可以分放在幾個倉庫中。

分析：由以上得 PNO 不能確定QNT，由組合屬性（WNO，PNO）來決定，存在函數依賴（WNO，PNO） -> ENO。由於每個倉庫裏的一種配件由專人負責，而一個人可以管理幾種配件，所以有組合屬性（WNO，PNO）才能確定負責人，有（WNO，PNO）-> ENO。因為 一個職工僅在一個倉庫工作，有ENO -> WNO。由於每個倉庫裏的一種配件由專人負責，而一個職工僅在一個倉庫工作，有 （ENO，PNO）-> QNT。

找一下候選關鍵字，因為（WNO，PNO） -> QNT，（WNO，PNO）-> ENO ，因此 （WNO，PNO）可以決定整個元組，是一個候選關鍵字。根據ENO->WNO，（ENO，PNO）->QNT，故（ENO，PNO）也能決定整個元組，為另一個候選關鍵字。屬性ENO，WNO，PNO 均為主屬性，只有一個非主屬性QNT。它對任何一個候選關鍵字都是完全函數依賴的，並且是直接依賴，所以該關系模式是3NF。

分析一下主屬性。因為ENO->WNO，主屬性ENO是WNO的決定因素，但是它本身不是關鍵字，只是組合關鍵字的一部分。這就造成主屬性WNO對另外一個候選關鍵字（ENO，PNO）的部 分依賴，因為（ENO，PNO）-> ENO但反過來不成立，而P->WNO，故（ENO，PNO）-> WNO 也是傳遞依賴。

雖然沒有非主屬性對候選關鍵遼的傳遞依賴，但存在主屬性對候選關鍵字的傳遞依賴，同樣也會帶來麻煩。如一個新職工分配到倉庫工作，但暫時處於實習階段，沒有獨立負責對某些配件的管理任務。由於缺少關鍵字的一部分PNO而無法插入到該關系中去。又如某個人改成不管配件了去負責安全，則在刪除配件的同時該職工也會被刪除。

解決辦法：分成管理EP（ENO，PNO，QNT），關鍵字是（ENO，PNO）工作EW（ENO，WNO）其關鍵字是ENO

缺點：分解後函數依賴的保持性較差。如此例中，由於分解,函數依賴（WNO，PNO）-> ENO 丟失了, 因而對原來的語義有所破壞。沒有體現出每個倉庫裏一種部件由專人負責。有可能出現 一部件由兩個人或兩個以上的人來同時管理。因此，分解之後的關系模式降低了部分完整性約束。

那麽看了這麽多例子，即分解為BCNF的首要即是不對原關系(語意)進行破壞的情況下，消除主屬性對候選鍵的依賴，所以可以得出分解後為{ABCDE}→{ACD,BCDE}→{ACD,CED,BCE}。

個人認為，這對於我以後將要進行的項目實踐，非常有意義。

基於數據庫範式的一點點想法