第四周資料庫

 8.3 分解使用函式依賴
在第1節中，我們注意到有一種正式的方法來評估應該分解關係模式。這個方法是基於
鍵和功能依賴的概念。
在討論關聯式資料庫設計的演算法時，我們需要
談論任意關係和他們的模式，而不是僅僅談論
的例子。回顧我們在第二章中介紹的關係模型，我們總結我們的符號。
•在一般情況下，我們使用希臘字母來表示屬性集（例如）。我們用小寫的羅馬字母和大寫的羅馬字母括號表示關係模式（例R（R））。我們使用符號R（R）表示模式是關於R的，R表示屬性的集合，但有時我們的符號化簡時，只使用R關係名對我們來說並不重要。
當然，關係模式是一組屬性，但不是所有屬性集是模式。當我們使用小寫的希臘字母時，我們指的是一個集合有可能不是模式的屬性。羅馬字母在我們想要指出屬性的集合絕對是一個模式。
•當一組屬性是超級鍵時，我們用K表示它。
對於一個特定的關係模式，我們使用術語"K是一個超級關鍵r(r)。”
•我們用一個小寫的名字來表示關係。在我們的示例中，這些名稱是意圖是現實的（例如，教師），而在我們的定義中演算法，我們用單字母，像r。
•一個關係，當然，在任何時候都有特定的價值;我們指的是作為一個例項使用術語“r的例項”。當我們很清楚的時候討論一個例項，我們可以簡單地使用關係名稱（例如，r)。
8.1.3.1和函式依賴關係
資料庫在現實世界中模擬一組實體和關係。有
通常在現實世界中的資料上有各種各樣的約束（規則）。例如,在大學的資料庫中，有一些約束條件是：
1.學生和教師的身份是唯一的。
2.每個學生和老師只有一個名字。
3.每位老師和學生（主要）與一個分離的人有關。
4.每個部門的預算只有一個價值，並且只有一個建築。
一個滿足所有這些現實約束的關係的例項稱為
這一關係的法律例項;資料庫的合法例項是所有的關係例項是合法的例項。
一些最常用的現實約束型別可以是正式地表示為鍵（超鍵、候選鍵和主鍵），或者作為功能性依賴關係，我們在下面定義。
在第2.3節中，我們定義了超鍵的概念作為一個或多個這些屬性集合在一起，使我們能夠在其中確定一個元組關係。我們重申這個定義如下：讓R（R）成為一個關係模式。
R的子集是R（R）的超鍵，如果在R（R）的任何合法例項中，對於所有的對在r的例子中，t1和t2，如果t1=t2，那麼t1 K=t2 K。也就是說,在任何關於關係R（R）的法律例項中沒有兩個元組可能具有相同的值。很明顯，如果r中沒有兩個元組在K上有相同的值，那麼ak值惟一地標識了r中的元組。而超級鍵是一組唯一標識整個的屬性元組，功能依賴允許我們表達唯一的約束確定某些屬性的值。考慮一個關係模式R（R），然後R和R。
•考慮到R（R）的一個例項，我們說例項滿足功能性如果在例項中對所有成對的元組t1和t2有依賴性t1=t2，也就是t1=t2。
•我們說，功能性依賴關係在模式R（R）中，如果每一個R（R）的合法例項都滿足了函式的依賴關係。
使用功能依賴符號，我們說K是R（R）的超鍵
在R（R）上的函式依賴關係。換句話說，K是一個超鍵，如果R（R）的每一個合法的例項，對於每一對元組t1和t2，例如，當t1 K=t2 K時，也就是t1 R=t2 R（也就是，t1 = t2)。
功能性依賴關係允許我們表達一些約束，這些約束是我們不能用超鍵來控制的。在第8部分中，我們考慮了模式：
inst部門（ID、姓名、工資、部門名稱、建築、預算）
在其中，功能依賴項的名稱預算保持不變部門（按部門名稱確定）有一個獨特的預算金額。
我們表示這兩個屬性（ID，dept name）形成了一個超級鍵
對inst.部門的寫作：
ID，公司名，工資，建築，預算
我們將以兩種方式使用功能性依賴：
1。測試關係的例項，看它們是否滿足給定的集合F函式依賴。
2。指定法律關係的約束條件。因此，我們只關注那些滿足給定功能集合的關係例項
依賴關係。如果我們希望約束自己在模式R（R）上的關係這滿足了函式依賴的集合F，我們說F保持在R（R）上。
讓我們考慮一下圖4的關係r的例項，看看哪個函式依賴關係感到滿意。觀察C是否滿足。有兩個元組它的值是a1。這些元組具有相同的C值，即c1。類似地，兩個元組與a2的值相同，也有相同的C值，c2。在那裡沒有其他具有相同值的獨立元組的功能。然而，依賴C A並不滿足。要知道它不是，請考慮元組t1=（a2、b3、c2、d3）和t2=（a3、b3、c2、d4）。這兩個元組是相同的C值，c2，但是它們分別有不同的值a2和a3。因此,我們找到了一對元組t1和t2，t1c=t2c，但是t1A≠t2 A。
一些功能性依賴被認為是微不足道的，因為它們是滿足的——同一標準的所有關係。例如，A對所有涉及到的關係都很滿意，從字面上理解功能依賴的定義，我們看到，對於所有的元組t1和t2，t1 A=t2 A，就是t1 A=t2 A。類似的，AB A對所有涉及屬性A的關係都很滿意。
如果，表單的功能依賴是微不足道的。重要的是要認識到關係的一個例項可以滿足一些在關係模式中不需要的func的依賴關係。在圖8的教室關係的例項，我們看到了房間號的容量
是滿意的。然而，我們相信，在現實世界中，不同建築的兩間教室可以有相同的房間號碼，但房間容量不同。
因此，在某個時候，有可能有一個課堂關係的例項房間號碼的容量不滿足。所以，我們不包括房間在模式中保留的功能依賴集的數量
教室的關係。但是，我們會期望功能依賴性
建築、房間數容量以保持課堂模式計劃投入。假設一組函式依賴於關係R（R），它可能可以推斷出某些其他的功能依賴關係也必須保持不變的關係。例如，如果有一個模式r（A，B，C），如果函式依賴關係B和C，保持r，我們可以推斷出函式依賴性是C也必須保持在r上，這是因為，給定任何一個值只能是對於B的一個對應的值，對於B的值，只有一個值C的相應值，我們稍後學習，在第8。1節中，如何製作推斷。
我們將用F+來表示集合F的結束，也就是集合
在所有的函式依賴關係中，可以根據集合F來推斷出F+。
8.2.3.2.2包含f的所有函式依賴項
我們能得到的最理想的一種正規化是Boyce，Codd正規化(BCNF)。它消除了所有可以被發現的冗餘在功能性依賴方面，如我們將在第6部分中看到的，可能有其他型別的冗餘。關係模式R在BCNF中。如果F+的所有函式依賴關係到函式依賴關係的集合F。在R和R中，至少有一個是這樣的：
•是一個微不足道的功能依賴項（也就是）。
•是模式r的超級關鍵。
資料庫設計是在BCNF中如果每個關係模式的成員設計在BCNF中。
我們已經在第8.1節中看到了關係模式的一個例子不是在BCNF:
inst部門（ID、姓名、工資、部門名稱、建築、預算）
功能性依賴項的名稱預算在inst部門中保持不變，但是在部門名稱中不是一個超鍵（因為一個部門可能有很多不同的instruc）。在第8。2節中，我們看到了inst部門的分解，而部門是一個更好的設計。教員模式在BCNF中。所有的包含的非平凡的功能依賴項，例如：
ID名，公司名，薪水
在箭頭的左邊包含ID，ID是一個超鍵（實際上，在本例中，教師的主鍵）。（換句話說，沒有非平凡的功能依賴於名稱、部門名稱和薪水的任何組合，沒有ID一面。)因此，講師在BCNF。
類似地，部門模式是在BCNF中因為所有的重要的func的依賴關係，例如：
部門名，預算
在箭頭的左邊包含dept名稱，而dept name是一個超鍵（和部門的主鍵）。因此，部門在BCNF。
現在我們宣告一個用於分解的一般規則不是在BCNF中。讓R成為一個不在BCNF中的模式。然後至少有一個非平凡的功能
依賴性，這不是R的超鍵，我們在設計中替換R
兩個模式:
•(α∪β)
•（R-(β-α）
在上面的inst部門，=部門名，=大樓，預算，和inst部門
取而代之的是
•（αUβ）=（部門名、建築、預算）
•（R-（β-α）=（ID、姓名、部門名、薪水）
在這個區
在這個例子中，結果是=。我們需要將規則表述為這樣做是為了正確處理具有屬性的功能性依賴關係在箭頭的兩邊都出現。這方面的技術原因稍後會介紹
8.5.1節。
當我們分解不在BCNF中的模式時，它可能是一個或多個產生的模式不在BCNF中。在這種情況下，進一步的分解是需要的，最終的結果是一組BCNF模式。
8.3.3 BCNF和依賴性保護
我們已經看到了幾種表達資料庫一致性約束的方法：

主鍵約束，功能依賴，檢查約束