資料庫模式設計如果不好會導致的問題：

　　１．冗余

　　２．導致資料一致性出現問題

　　３．插入例外

　　４．更新例外

　　５．洗掉例外

函式依賴

　　函式依賴是指一個或多個屬性的取值可以確定另一個屬性的取值，具體地說，如果一個關系模式R中屬性集合X的取值能唯一地確定屬性集合Y的取值，那么我們稱屬性集合Y對于屬性集合X具有函式依賴，這被表示為X → Y，其中X稱為函式依賴的左部，Y稱為右部，

　　例如，考慮一個包含學生資訊的關系模式R，其中包含屬性集合{學生ID，姓名，年齡，所在班級，班級導師}，假設我們觀察到一個學生ID只對應一個姓名和年齡，那么我們可以說“學生ID函式依賴于姓名和年齡”，表示為{學生ID} → {姓名，年齡}，

　　函式依賴在資料庫設計中非常重要，因為它們可以幫助我們識別重復資料和設計表結構，如果我們正確地理解和應用函式依賴，就可以減少資料冗余，提高資料完整性和一致性，

資料庫的鍵

　
　　在關系型資料庫中，鍵（key）是指一種特殊的屬性或屬性集合，用于唯一標識一個關系中的元組，鍵可以幫助我們在資料庫中快速準確地定位、訪問和修改資料，

關系資料庫中的鍵可以分為以下三種型別：

1. 主鍵（Primary Key）：主鍵是一個關系中的一個或多個屬性，用于唯一標識關系中的每個元組，主鍵具有以下特點：

   • 主鍵的值在關系中必須是唯一的，
   • 主鍵的值不能為空值（NULL），
   • 一個關系只能有一個主鍵，

2. 外鍵（Foreign Key）：外鍵是一個關系中的屬性，它參考了另一個關系的主鍵，用于建立兩個關系之間的關系，外鍵具有以下特點：

   • 外鍵的值必須在另一個關系中存在，或者為空值（NULL），
   • 一個關系可以有多個外鍵，

3. 候選鍵（Candidate Key）：候選鍵是一個關系中的一個或多個屬性，它可以唯一標識關系中的每個元組，但不是主鍵，一個關系可以有多個候選鍵，而且不同候選鍵的元素個數可能不同！

4. 超鍵（super key）是指可以唯一標識一個關系中的每個元組的屬性集合，換句話說，一個超鍵的值集合可以唯一確定關系中每個元組的值，超鍵可以包含關系中的所有屬性，也可以只包含部分屬性，超鍵不一定是最小的，也就是說，可能存在多個超鍵可以唯一標識關系中的每個元組，

　　鍵在資料庫中非常重要，因為它們可以幫助我們維護資料的完整性和一致性，通過使用鍵，我們可以確保每個元組都具有唯一的識別符號，從而避免資料冗余和不一致性，

尋找資料庫的鍵

　　函式依賴集合的閉包

　　定義：在關系資料庫中，函式集合的閉包是指一個函式集合中所有可能的函式依賴組合所得到的函式依賴集合，換句話說，函式集合的閉包包含了原函式集合中所有可能的函式依賴和派生函式依賴，通過尋找函式集合的閉包，我們可以了解關系模式中所有可能的函式依賴，從而更好地設計和優化關系模式，

　　以下是尋找函式集合的閉包的方法：

1. 初始閉包：將原函式集合中的所有函式依賴加入到閉包中，

2. 遞回添加：對于閉包中的每個函式依賴，找到其右部屬性集合所能推匯出的所有函式依賴，并將其添加到閉包中，

3. 直到無法添加：重復步驟2，直到閉包中沒有新的函式依賴可以添加為止，

　　函式依賴的規則包括以下幾條：

1. 自反性規則：如果Y包含于X，則X → Y，

2. 擴展性規則：如果X → Y，那么XZ → YZ，其中Z是關系R中除X、Y之外的任意屬性集合，

3. 傳遞性規則：如果X → Y，Y → Z，那么X → Z，

　　這些規則可以用來推匯出函式依賴的閉包，通過這些規則，我們可以確定關系模式中的主鍵、候選鍵和冗余屬性，從而優化關系模式的設計和性能，
　

　　通過函式依賴的閉包求解鍵的辦法（暴力法）：

1. 確定關系中的屬性集合：首先，確定關系中的所有屬性集合，包括主屬性和非主屬性，

2. 確定函式依賴集合：根據實際情況，確定關系中的所有可能函式依賴，一個函式依賴是指一個屬性集合能夠唯一確定另一個屬性集合，例如，如果屬性集合A能夠唯一確定屬性集合B，則稱為A → B，

3. 計算函式依賴的閉包：通過使用函式依賴的自反性、擴展性和傳遞性規則，計算關系中所有可能的函式依賴，這將給出一個包含原函式依賴和派生函式依賴的函式依賴集合，即函式依賴的閉包，

4. 確定候選鍵：對于關系中的每個屬性集合，檢查是否可以唯一確定每個元組，如果可以，則該屬性集合是一個候選鍵，如果有多個候選鍵，則需要確定一個主鍵，

5. 檢查主鍵是否在函式依賴閉包中：檢查所選的主鍵是否在函式依賴閉包中，如果主鍵不在閉包中，則需要重新選擇一個候選鍵作為主鍵，

　　啟發式演算法：

1. 不在任何函式依賴右邊出現的屬性必然是鍵的一部分，

2. 不在函式依賴左邊出現的屬性一定不是鍵的一部分

關系模式的分解

1. 無損分解（Lossless Decomposition）

   無損分解是指將一個大的關系模式拆分成多個小的關系模式，同時保持它們之間的函式依賴和資訊完整性不變，這種分解方式的優點是可以提高資料庫的性能和可維護性，同時保持資料的完整性和一致性，無損分解的目標是保證原始關系模式中的所有函式依賴都能在新的小的關系模式中得到滿足，因此無損分解的結果仍然可以保持關系模式的完整性和一致性，

2. 有損分解（Lossy Decomposition）

   有損分解是指將一個大的關系模式拆分成多個小的關系模式，但不能保持它們之間的函式依賴和資訊完整性不變，這種分解方式的優點是可以提高資料庫的性能和可維護性，同時減少資料的冗余和復雜性，有損分解的目標是在滿足一定的性能需求的前提下，盡可能地減少資料冗余和復雜性，有損分解的結果可能會導致資料的不一致性和丟失一些資訊，因此需要謹慎選擇分解方式和對資料進行適當的處理，

   需要注意的是，無損分解和有損分解都有其適用的場景和限制，具體的選擇需要根據實際需求和性能要求進行綜合考慮，在分解關系R時，我們希望分解能夠：

   • 最小化冗余

   • 避免資訊丟失

   • 保留依賴關系（即約束條件）

   • 確保查詢性能良好

如何將一個模式分解為多個模式

當我們要將一個關系模式拆分為符合第一范式的多個關系模式時，需要遵循以下規則：

1. 確定主鍵：首先需要確定關系模式的主鍵，以確保每個元組都能唯一標識，主鍵可以由單個屬性或多個屬性組成，

2. 消除重復組：如果關系模式中存在重復組，即有兩個或多個元組在所有屬性上的取值都相同，就需要將這些元組合并為一個元組，

3. 拆分多值依賴：如果關系模式中存在多值依賴，即一個屬性依賴于主鍵的某個子集而不是整個主鍵，就需要將這些屬性拆分成新的關系模式，并與原來的關系模式建立外鍵關系，

4. 拆分部分依賴：如果關系模式中存在部分依賴，即一個非主屬性依賴于主鍵的某個子集而不是整個主鍵，就需要將這些非主屬性與主鍵組成一個新的關系模式，并在新的關系模式中建立外鍵關系，

example

例如，假設我們有一個包含以下屬性的關系模式：

學生（學號，姓名，年齡，課程，成績）   

在這個關系模式中，學號是主鍵，課程和成績是非主屬性，由于一個學生可以選修多門課程，課程和成績之間存在多值依賴關系，為了消除多值依賴，我們可以將課程和成績拆分成新的關系模式，并與原來的關系模式建立外鍵關系，這樣就可以得到以下兩個關系模式：

學生（學號，姓名，年齡）

選課（學號，課程，成績）

在新的關系模式中，每個關系模式都符合第一范式的要求，因為每個屬性都是單值屬性，不存在重復組和多值依賴的問題，

關系模式的范式

在關系型資料庫中，范式（Normalization）是一種通過分解關系模式來減少資料冗余、提高資料一致性和資料可維護性的技術，范式分為不同的級別，從第一范式（1NF）到第五范式（5NF），每個級別都有其特定的規則和限制，以下是各個范式的詳細說明：

1. 第一范式（1NF）

   第一范式要求一個關系模式中的每個屬性都是原子的，即不能再分解成更小的資料項，例如，如果一個學生的電話號碼是“123-456-7890”，則應將其分解成三個不同的屬性：國家代碼、區號和電話號碼，

2. 第二范式（2NF）

   第二范式要求一個關系模式中的每個非主屬性都完全依賴于候選碼，而不是部分依賴于候選碼，例如，如果一個關系模式中包含“訂單號”、“商品編號”和“商品數量”這三個屬性，其中“商品數量”只依賴于“訂單號”，而不依賴于“商品編號”，則應將其拆分為兩個關系模式，以確保每個非主屬性完全依賴于主鍵，

3. 第三范式（3NF）

   第三范式要求一個關系模式中的每個非主屬性都不依賴于其他非主屬性，即不存在傳遞依賴關系，例如，如果一個關系模式中包含“訂單號”、“商品編號”、“商品名稱”和“供應商名稱”這四個屬性，其中“供應商名稱”依賴于“商品編號”，而“商品名稱”和“供應商名稱”存在函式依賴關系，則應將其拆分為兩個關系模式，以確保不存在傳遞依賴關系，

   一個模式違反第三范式:是A->B當且僅當A不是超鍵且B不是主屬性

4. 巴斯-科德范式（BCNF）

   巴斯-科德范式是第三范式的擴展，要求一個關系模式中的每個屬性都完全依賴于主鍵，而不是僅依賴于部分主鍵，這種范式適用于復雜的關系模式，其中存在多個主鍵，

5. 第四范式（4NF）

   第四范式要求一個關系模式中的每個多值依賴都被分解成獨立的關系模式，例如，如果一個關系模式中包含“學生編號”、“課程編號”和“成績”這三個屬性，其中每個學生可能有多個課程的成績，而每個課程可能由多個學生選修，則應將其拆分為三個關系模式，以確保每個多值依賴都被分解成獨立的關系模式，

6. 第五范式（5NF）

   第五范式是指一個關系模式中的每個依賴關系都是基于超鍵而不是基于主鍵的，超鍵是指能夠唯一標識一個關系模式中所有元組的一個或多個屬性組合，第五范式適用于多維關系資料庫和資料倉庫，其中存在復雜的多重關系和多個維度，

   需要注意的是，雖然范式可以提高資料庫的性能和可維護性，但過度范式化也可能會導致查詢性能下降和資料更新的困難，因此，在實際應用中，需要根據實際需求和性能要求來選擇適當的范式級別，以實作資料的高效管理和使用，

與范式結合的分解

已知關系模式和函式依賴集合保持FD和無損連接3NF模式分解的演算法如下：

1. 求極小函式依賴集Sm和關系模式的所有鍵(keys)，

2. 在Smin中按函式依賴左部相同原則進行分組，每個組中的所有屬性形成分解后的子關系模式R1, R2, ..., Rn，

3. 如果某個關系模式Ri的所有屬性被另一個關系模式Rj所包含，洗掉關系模式Ri，

4. 判斷是否有某個key出現在其中的一個關系模式中，如果出現則結束；如果沒有出現，將任意一個key也作為子關系模式R加入到分解后的模式中，

最小函式依賴集

如果函式依賴集合F滿足如下條件，則稱F為一個極小函式依賴集，也稱為最小依賴集或最小覆寫：

1. F中的任意函式依賴的右部僅含有一個屬性，

2. F中不存在這樣的函式依賴X→A使得F與F-X→A等價，

3. F中不存在這樣的函式依賴X→A，X有真子集Z使得(F-X→A)∪(Z→A)與F等價，

如果G+ = F+，就稱F與G等價，G = F的充分必要條件是F ? G+ 且 G+ ? F，

我們在求最小函式依賴集合時，事實上是將所有右邊僅有一個屬性的函式依賴的冗余消除掉，包括但不限于具有將具有傳遞性的幾個函式依賴消除掉，最本質仍然是消除冗余，

一個性質：任意一個資料庫的關系模式都可以保持函式依賴和無損鏈接到分解到第三范式！

第四范式

第四范式（4NF）是關系資料庫中的一種規范化形式，它要求關系模式中的每個非平凡多值依賴都要被分解，以達到消除冗余和保證資料一致性的目的，

具體來說，第四范式的要求如下：

1. 關系模式中的每個非主屬性必須與主鍵存在非平凡多值依賴，即非主屬性不能完全依賴于主鍵中的任意一個屬性，

2. 關系模式中的每個非主屬性必須是一個資料項的集合，即不能包含重復值，

滿足第四范式的關系模式可以消除非平凡多值依賴，避免資料冗余和更新例外，并且可以保證資料一致性，但是，第四范式的實作可能會導致關系模式的分解過于復雜，查詢性能下降等問題，因此在實際應用中需要根據具體情況綜合考慮，

多值依賴

多值依賴（Multivalued Dependency，MVD）是指一個關系模式中的某些屬性集合對另一個屬性集合存在依賴關系，但是這種依賴關系并不是函式依賴，在一個滿足MVD的關系模式中，一個屬性集合的取值可以對應多個其他屬性集合的取值，

例如，假設我們有一個包含以下屬性的關系模式：

學生（學號，姓名，選修課程，成績）

在這個關系模式中，選修課程和成績之間存在MVD，因為每個學生可以選修多門課程，每門課程的成績都可能不同，因此，選修課程的取值可以對應多個成績的取值，而不是像函式依賴那樣只對應一個成績的取值，

MVD是關系資料庫理論中一個重要的概念，可以幫助我們理解資料庫設計和優化的一些問題，在實際應用中，如果一個關系模式中存在MVD，我們可以考慮將其拆分為符合第三范式或BCNF的多個關系模式，以提高資料庫的性能和可維護性，

下面將對于多值依賴舉一個例子：

假設有一個關系模式R，包含屬性A、B和C，其中屬性A為主鍵，現在，我們發現存在這樣的依賴關系：對于任意的兩個元組r1和r2，如果它們在A屬性上的值相等，那么在B屬性和C屬性上的值都是多值依賴的，這就是一個MVD，可以表示為A →→ B,C，

舉個例子，假設關系模式R中有如下資料：

我們可以看到，在A屬性上有兩個不同的值a1和a2，對于每個值，B和C屬性上的值都是多值依賴的，即b1和b2、c1和c2，以及b3和b4、c3和c4，這就是一個MVD的例子，

需要注意的是，MVD不同于函式依賴，它是對于關系模式中的一組屬性來說的，并且MVD的右側可以包含多個屬性，表示這些屬性的組合是多值依賴的，MVD的出現可能導致資料冗余和更新例外，需要進行適當的規范化處理，

函式依賴和多值依賴的關系

結論：每個函式依賴都可以看作是一個多值依賴，具體來說，如果一個屬性集合X決定了另一個屬性集合Y，那么對于所有在屬性集合X上取值相同的元組，它們在屬性集合Y上的取值也必須相同，換句話說，如果我們交換在屬性集合Y上的兩個值，那么這些元組仍然是合法的，因此，可以將X和Y看作是一個MVD，

具體來說，它指出，如果一個FD X -> Y成立，那么對于在屬性集合X上取值相同的任意兩個元組，它們在屬性集合Y上的取值必須相同，因此，交換在屬性集合Y上的兩個值不會改變這些元組的合法性，因此，我們可以將FD X -> Y視為MVD X - Y，

補集原理：如果一個屬性集合X決定了另一個屬性集合Y，那么對于屬性集合Y的補集（即所有不在Y中的屬性集合Z），X和Z之間必須存在MVD，這個原理是很有用的，因為它可以幫助我們從一個給定的函式依賴集合中推匯出所有的MVD，具體來說，對于每個函式依賴X -> Y，我們可以通過補集原理推匯出所有的MVD X - Z，其中Z是Y的補集，

important：對于多值依賴，如果AB->->C，那么我們無法推出A->->C且B->->C！對于A->->BC，也無法推出A->->B和A->->C！

標籤：其他

上一篇：Hive執行計劃之只有map階段SQL性能分析和解讀

下一篇：返回列表