資料庫函數依賴範式-九游会j9娱乐平台

1. 函數依賴和範式是如何被逐漸認識和發展起來的

函數依賴和範式是資料庫設計中的重要概念，它們的發展歷程可以概括為以下幾個階段：

• 初始階段

在資料庫誕生的早期，數據被存儲在文件中，沒有數據模型或規范可言。隨著資料庫行旅的出現，人們開始探索如何組織數據以便於查詢和管理。此時，人們主要使用實體-關系圖（erd）和層次模型來描述資料庫中的數據結構，但是這些模型沒有提供規范的方法來消除冗餘數據或確保數據的一致性。

• 函數依賴理論的出現

20世紀60年代，資料庫研究者開始探索如何減少數據冗餘並確保數據的一致性。這個時期，e.f. codd提出了關系模型的概念，他在1970年發表的一篇論文中詳細描述了關系模檔旁凳型和關系資料庫的基本概念。codd提出了函數依賴的概念，指出在一個關系中，某些屬性的值可以通過其他屬性的值推導出來。他還提出了第一範式的概念，要求關系中的每個屬性都是原子的，啟皮即不可再分。

• 範式理論的發展

在函數依賴理論的基礎上，出現了更多的範式，包括第二範式、第三範式、bcnf範式等。這些範式描述了關系中的數據如何消除冗餘和保持一致性。它們提供了規范的方法來設計和優化資料庫模式，使得資料庫更容易維護和查詢。

• 實踐中的應用

範式理論在資料庫設計和優化中得到了廣泛應用。在實踐中，設計人員可以根據數據的特點和使用場景選擇適當的範式，以便在不同的方面取得最佳性能。例如，第三範式適用於數據具有大量重復的情況，而bcnf範式適用於多對多關系的情況。

總之，函數依賴和範式是資料庫設計中的重要概念，它們的發展歷程可以追溯到資料庫出現的早期。通過函數依賴理論和範式理論，人們可以更好地組織和優化資料庫中的數據，以便於管理和查詢。

2. 資料庫範式問題！！

資料庫中的範式問題．理論和時間要結合．
第一範式：當且僅當一個關系變數的所有的合法的值中，每一個元組的每個屬性只含有
一個值時，該關系變數屬於1 n f。
第二範式：（假定只有一個候選碼，且該候選碼是主碼）當且僅當一個關系變數屬於
1 n f，且該關系變數的每一個非碼屬性都完全函數依賴於主碼時，該關系變數屬於2 n f。
第三範式（假定關系變數只有一個候選碼，且該候選碼是主碼）：當且僅當一個關系變
量屬於2 n f且該關系變數的所有非碼屬性都不傳遞依賴於主碼時，該關系變數屬於3 n f。
注意：「不傳遞依賴」蘊涵不互相依賴，從這個意義上說，該術語的解釋和本節開始的
解釋一樣。

多值依賴： r是一個關系變數， a、b和c是r的屬性的子集。那麼我們說b多值依賴於a
—符號如下：a→→b（讀做「a多值決定b」，或簡單地稱為「 a雙箭頭b」）—當且僅當
對於每一個可能的合法r值，b值的集合對於給定的一組（ a值，c值）只依賴於a的值，而與
c的值無關。
很容易看出—參見[ 1 2 . 1 3 ]—對於給定的變數r{a,b,c}，多值依賴a→→b存在，當且
僅當多值依賴a→→c也存在。這樣m v d總是成對的一起出現。因此通常用一種語句來表示它
們：a→→b|c。例如：c o u r s e→→t e a c h e r | t e x t。
在前面我們已經提到，多值依賴是一般化的函數依賴，在這種意義上講每一個f d都是
m v d。更精確地說，一個f d就是一個只有一個依賴值（右邊的）與一個給定的決定值相符合
的m v d。因此，如果a→b，那麼一定a→→b。

第四範式：只要存在r的屬性的子集a和b，滿足非平凡的多值依賴，並且r的所有屬
性也都函數依賴於a，這樣的關系變數r滿足4 n f。
換句話說，在r中的唯一的非平凡的依賴（函數依賴或多值依賴）是k→→x形式（例如：
一個超碼k對另一個屬性x的函數依賴）。同樣，如果r是b c n f，並且r中的所有非平凡的多值
依賴事實上都是「非碼函數依賴（ fds out of key）」，則r是4 n f的。因此特別要注意的是，
4 n f包含了b c n f。

第五範式：一個關系變數r是第五範式—也稱為投影-連接範式（ p j / n f）—當且僅當
r的每一個非平凡的連接依賴都被r的候選碼所蘊涵。
注意：下面解釋一下對於一個j d「被候選碼所蘊涵」的含義。
關系變數s p j並不是5 n f；它滿足一個特定的連接依賴，即3 d約束。這顯然沒有被其唯一
的候選碼（這個候選碼是其所有的屬性值的組合）所蘊涵。可以表示其區別如下：關系變數
s p j並不是5 n f，因為（ a）它是可以被3分解的；（b）可3分解性並沒有為其{ s #，p #，j # }是
一個候選碼的事實所蘊涵。相反， 3分解後，由於三個投影s p、p j和j s根本不包括任何（非平
凡的）連接依賴，因此它們都是5 n f。

3. 請大夥給我解釋一下資料庫設計的基本原則！

資料庫設計的三範式所謂範式，是關系型資料庫關系模式規范化的標准，從規范化的寬松到嚴格，分別為不同的範式，通常使用的有第一範式、第二範式、第三範式及bc範式等。範式是建立在函數依賴基礎上的。

函數依賴

定義：設有關系模式r(u)，x和y是屬性集u的子集，函數依賴是形為x→y的一個命題，對任意r中兩個元組t和s，都有t[x]=s[x]蘊涵t[y]=s[y]，那麼fd x→y在關系模式r(u)中成立。x→y讀作『x函數決定y』，或『y函數依賴於x』。通俗的講，如果一個表中某一個欄位y的值是由另外一個欄位或一組欄位x的值來確定的，就稱為y函數依賴於x。函數依賴應該是通過理解數據項和企業的規則來決定的，根據表的內容得出的函數依賴可能是不正確的。

第一範式（1nf）

定義：如果關系模式r的每個關系r的屬性都是不可分的數據項，那麼就稱r是第一範式的模式。
簡單的說，每一個屬性都是原子項，不可分割。1nf是關系模式應具備的最起碼的條件，如果資料庫設計不能滿足第一範式，就不稱為關系型資料庫。關系資料庫設計研究的關系規范化是在1nf之上進行的。

第二範式（2nf）

定義：如果關系模式r是1nf，且每個非主屬性完全函數依賴於候選鍵，那麼就稱r是第二範式。
簡單的說，第二範式要滿足以下的條件：首先要滿足第一範式，其次每個非主屬性要完全函數依賴與候選鍵，或者是主鍵。也就是說，每個非主屬性是由整個主鍵函數決定的，而不能由主鍵的一部分來決定。舉個例子：
有股票日行情表的主鍵是股 票代碼和交易日期組成。非主屬性中有收盤價和成交量等，都是由主鍵，即股票代碼和交易日期函數決定的，單獨的股票代碼或者交易日期都不能函數決定這些非主 屬性。如果這個表中有非主屬性股票簡稱，則股票簡稱是可以由股票代碼來函數決定的，這樣股票簡稱這個非主屬性就不是完全函數依賴於候選鍵，這樣的設計就不 滿足第二範式。

第三範式（3nf）
定義：如果關系模式r是2nf，且關系模式r（u，f）中的所有非主屬性對任何候選關鍵字都不存在傳遞依賴，則稱關系r是屬於第三範式。
簡單的說，第三範式要滿足以下的條件：首先要滿足第二範式，其次非主屬性之間不存在函數依賴。由於滿足了第二範式，表示每個非主屬性都函數依賴於主鍵。如果非主屬性之間存在了函數依賴，就會存在傳遞依賴，這樣就不滿足第三範式。
舉 個例子：在股票基本情況表中，主鍵是股票代碼，有非主屬性所屬一級行業和所屬二級行業。根據業務規則，所屬二級行業能夠函數決定所屬一級行業，這就表示存 在這樣一種關系：股票代碼函數決定所屬二級行業，所屬二級行業函數決定所屬一級行業，這就形成了傳遞依賴，這樣的設計就不符合第三範式。不過在實際運用 中，為查詢和使用的方便，有時也會違反第三範式。如上例，如果沒有所屬一級行業的屬性，需要查詢所屬一級行業的相關股票，需要查詢時使用函數來從二級行業 中函數生成所屬一級行業，使用性能上會受影響。所以通常會加上所屬一級行業的屬性。

bc範式（bcnf）

bc範式是第三範式的增強版，不過也有人說是直接從1nf發展過來的，即每個屬性，包括主屬性或非主屬性，都完全依賴於候選鍵，並且不存在傳遞依賴情況。