Ⅰ 對資料庫模式進行規范化處理是在資料庫設計的什麼階段
邏輯設計階段。
因為開發到後面資料庫用的地方多了，資料庫動一動都是大改。
關系模式的規范化就是根據一個關系屬性間不同的依賴情況來區分其為第一，第二，第三，和第四範式，然後用直觀的描述將具有不合適性質的關系轉換為更合適的形式。
(1)資料庫非規范化處理擴展閱讀：
如果關系模式在達到1NF的基礎上，使每個非主屬性都完全依賴於每個關系鍵，則該關系模式達到2NF的要求。
如果關系模式屬於2NF，且每個非主屬性都不傳遞依賴於關系的任何鍵，這該關系模式屬於3NF的要求。
若關系符合1NF，且對於每個函數依賴X→Y，X必含有候選鍵，或者關系中的每個決定屬性集都是候選鍵，則關系達到BCNF的要求。
Ⅱ 為什麼資料庫規范化處理
通常情況下，可以從兩個方面來判斷資料庫是否設計的比較規范。一是看看是否擁有大量的窄表，二是寬表的數量是否足夠的少。若符合這兩個條件，則可以說明這個資料庫的規范化水平還是比較高的。當然這是兩個泛泛而談的指標。為了達到資料庫設計規范化的要求，一般來說，需要符合以下五個要求。
要求一：表中應該避免可為空的列。
雖然表中允許空列，但是，空欄位是一種比較特殊的數據類型。資料庫在處理的時候，需要進行特殊的處理。如此的話，就會增加資料庫處理記錄的復雜性。當表中有比較多的空欄位時，在同等條件下，資料庫處理的性能會降低許多。
所以，雖然在資料庫表設計的時候，允許表中具有空欄位，但是，我們應該盡量避免。若確實需要的話，我們可以通過一些折中的方式，來處理這些空欄位，讓其對資料庫性能的影響降低到最少。
一是通過設置默認值的形式，來避免空欄位的產生。如在一個人事管理系統中，有時候身份證號碼欄位可能允許為空。因為不是每個人都可以記住自己的身份證號碼。而在員工報到的時候，可能身份證沒有帶在身邊。所以，身份證號碼欄位往往不能及時提供。為此，身份證號碼欄位可以允許為空，以滿足這些特殊情況的需要。但是，在資料庫設計的時候，則可以做一些處理。如當用戶沒有輸入內容的時候，則把這個欄位的默認值設置為0或者為N/A。以避免空欄位的產生。
二是若一張表中，允許為空的列比較多，接近表全部列數的三分之一。而且，這些列在大部分情況下，都是可有可無的。若資料庫管理員遇到這種情況，筆者建議另外建立一張副表，以保存這些列。然後通過關鍵字把主表跟這張副表關聯起來。將數據存儲在兩個獨立的表中使得主表的設計更為簡單，同時也能夠滿足存儲空值信息的需要。
要求二：表不應該有重復的值或者列。
為了解決這個問題，有多種實現方式。但是，若設計不合理的話在，則會導致重復的值或者列。如我們也可以這么設計，把客戶信息、聯系人都放入同一張表中。為了解決多個聯系人的問題，可以設置第一聯系人、第一聯系人電話、第二聯系人、第二聯系人電話等等。若還有第三聯系人、第四聯系人等等，則往往還需要加入更多的欄位。
所以，在資料庫設計的時候要盡量避免這種重復的值或者列的產生。筆者建議，若資料庫管理員遇到這種情況，可以改變一下策略。如把客戶聯系人另外設置一張表。然後通過客戶ID把供應商信息表跟客戶聯系人信息表連接起來。也就是說，盡量將重復的值放置到一張獨立的表中進行管理。然後通過視圖或者其他手段把這些獨立的表聯系起來。
要求三：表中記錄應該有一個唯一的標識符。
在資料庫表設計的時候，資料庫管理員應該養成一個好習慣，用一個ID號來唯一的標識行記錄，而不要通過名字、編號等欄位來對紀錄進行區分。每個表都應該有一個ID列，任何兩個記錄都不可以共享同一個ID值。另外，這個ID值最好有資料庫來進行自動管理，而不要把這個任務給前台應用程序。否則的話，很容易產生ID值不統一的情況。
要求四：資料庫對象要有統一的前綴名。
一個比較復雜的應用系統，其對應的資料庫表往往以千計。若讓資料庫管理員看到對象名就了解這個資料庫對象所起的作用，恐怕會比較困難。而且在資料庫對象引用的時候，資料庫管理員也會為不能迅速找到所需要的資料庫對象而頭疼。
其次，表、視圖、函數等最好也有統一的前綴。如視圖可以用V為前綴，而函數則可以利用F為前綴。如此資料庫管理員無論是在日常管理還是對象引用的時候，都能夠在最短的時間內找到自己所需要的對象。
要求五：盡量只存儲單一實體類型的數據。
這里將的實體類型跟數據類型不是一回事，要注意區分。這里講的實體類型是指所需要描述對象的本身。筆者舉一個例子，估計大家就可以明白其中的內容了。如現在有一個圖書館里系統，有圖書基本信息、作者信息兩個實體對象。若用戶要把這兩個實體對象信息放在同一張表中也是可以的。如可以把表設計成圖書名字、圖書作者等等。可是如此設計的話，會給後續的維護帶來不少的麻煩。
遇到這種情況時，筆者建議可以把上面這張表分解成三種獨立的表，分別為圖書基本信息表、作者基本信息表、圖書與作者對應表等等。如此設計以後，以上遇到的所有問題就都引刃而解了。
以上五條是在資料庫設計時達到規范化水平的基本要求。除了這些另外還有很多細節方面的要求，如數據類型、存儲過程等等。而且，資料庫規范往往沒有技術方面的嚴格限制，主要依靠資料庫管理員日常工作經驗的累積。
Ⅲ 在資料庫原理中，非規范化的關系可能會存在哪些問題
數據冗餘，更新異常，插入異常，刪除異常。
Ⅳ 什麼是反規范化一個mysql資料庫的好方法
1、關系型資料庫：是建立在關系資料庫模型基礎上的資料庫，藉助於關系代數等概念和方法來處理資料庫中的數據，同時也是一個被組織成一組擁有正式描述性的表格，該形式的表格作用的實質是裝載著數據項的特殊收集體，這些表格中的數據能以許多不同的方式被存取或重新召集而不需要重新組織資料庫表格。
2、關系代數：
在數學中，關系代數是支持叫做逆反(converse)的對合一運算的剩餘布爾代數。激發關系代數的例子是在集合X上的所有二元關系的代數，帶有R-S被解釋為平常的二元關系復合。
Ⅳ 理解什麼是資料庫規范化
優點是降低冗餘，利於保證數據的一致性和完整性；缺點是過度的規范化，易造成查詢和統計時的效率下降，這主要是由於多表連接所造成的問題。適當的反規范化設計可以提高效率，但最好在那些數據不太發生變化的情況下使用。通常情況下，可以從兩個方面來判斷資料庫是否設計的比較規范。一是看看是否擁有大量的窄表，二是寬表的數量是否足夠的少。若符合這兩個條件，則可以說明這個資料庫的規范化水平還是比較高的。當然這是兩個泛泛而談的指標。為了達到資料庫設計規范化的要求，一般來說，需要符合以下五個要求。要求一：表中應該避免可為空的列。雖然表中允許空列，但是，空欄位是一種比較特殊的數據類型。資料庫在處理的時候，需要進行特殊的處理。如此的話，就會增加資料庫處理記錄的復雜性。當表中有比較多的空欄位時，在同等條件下，資料庫處理的性能會降低許多。所以，雖然在資料庫表設計的時候，允許表中具有空欄位，但是，我們應該盡量避免。若確實需要的話，我們可以通過一些折中的方式，來處理這些空欄位，讓其對資料庫性能的影響降低到最少。一是通過設置默認值的形式，來避免空欄位的產生。如在一個人事管理系統中，有時候身份證號碼欄位可能允許為空。因為不是每個人都可以記住自己的身份證號碼。而在員工報到的時候，可能身份證沒有帶在身邊。所以，身份證號碼欄位往往不能及時提供。為此，身份證號碼欄位可以允許為空，以滿足這些特殊情況的需要。但是，在資料庫設計的時候，則可以做一些處理。如當用戶沒有輸入內容的時候，則把這個欄位的默認值設置為0或者為N/A。以避免空欄位的產生。二是若一張表中，允許為空的列比較多，接近表全部列數的三分之一。而且，這些列在大部分情況下，都是可有可無的。若資料庫管理員遇到這種情況，筆者建議另外建立一張副表，以保存這些列。然後通過關鍵字把主表跟這張副表關聯起來。將數據存儲在兩個獨立的表中使得主表的設計更為簡單，同時也能夠滿足存儲空值信息的需要。要求二：表不應該有重復的值或者列。為了解決這個問題，有多種實現方式。但是，若設計不合理的話在，則會導致重復的值或者列。如我們也可以這么設計，把客戶信息、聯系人都放入同一張表中。為了解決多個聯系人的問題，可以設置第一聯系人、第一聯系人電話、第二聯系人、第二聯系人電話等等。若還有第三聯系人、第四聯系人等等，則往往還需要加入的欄位。所以，在資料庫設計的時候要盡量避免這種重復的值或者列的產生。筆者建議，若資料庫管理員遇到這種情況，可以改變一下策略。如把客戶聯系人另外設置一張表。然後通過客戶ID把供應商信息表跟客戶聯系人信息表連接起來。也就是說，盡量將重復的值放置到一張獨立的表中進行管理。然後通過視圖或者其他手段把這些獨立的表聯系起來。要求三：表中記錄應該有一個唯一的標識符。在資料庫表設計的時候，資料庫管理員應該養成一個好習慣，用一個ID號來唯一的標識行記錄，而不要通過名字、編號等欄位來對紀錄進行區分。每個表都應該有一個ID列，任何兩個記錄都不可以共享同一個ID值。另外，這個ID值最好有資料庫來進行自動管理，而不要把這個任務給前台應用程序。否則的話，很容易產生ID值不統一的情況。要求四：資料庫對象要有統一的前綴名。一個比較復雜的應用系統，其對應的資料庫表往往以千計。若讓資料庫管理員看到對象名就了解這個資料庫對象所起的作用，恐怕會比較困難。而且在資料庫對象引用的時候，資料庫管理員也會為不能迅速找到所需要的資料庫對象而頭疼。其次，表、視圖、函數等最好也有統一的前綴。如視圖可以用V為前綴，而函數則可以利用F為前綴。如此資料庫管理員無論是在日常管理還是對象引用的時候，都能夠在最短的時間內找到自己所需要的對象。要求五：盡量只存儲單一實體類型的數據。這里將的實體類型跟數據類型不是一回事，要注意區分。這里講的實體類型是指所需要描述對象的本身。筆者舉一個例子，估計大家就可以明白其中的內容了。如現在有一個圖書館里系統，有圖書基本信息、作者信息兩個實體對象。若用戶要把這兩個實體對象信息放在同一張表中也是可以的。如可以把表設計成圖書名字、圖書作者等等。可是如此設計的話，會給後續的維護帶來不少的麻煩。遇到這種情況時，筆者建議可以把上面這張表分解成三種獨立的表，分別為圖書基本信息表、作者基本信息表、圖書與作者對應表等等。如此設計以後，以上遇到的所有問題就都引刃而解了。以上五條是在資料庫設計時達到規范化水平的基本要求。除了這些另外還有很多細節方面的要求，如數據類型、存儲過程等等。而且，資料庫規范往往沒有技術方面的嚴格限制，主要依靠資料庫管理員日常工作經驗的累積。第一範式每個分量不可再分第一範式消除了非主屬性對鍵的部分函數依賴,就是第二範式第二範式消除了任何屬性對鍵的傳遞依賴,就是第三範式~
Ⅵ 數據倉庫有4個特徵分別是
數據倉庫的特點：
數據倉庫是面向主題的；操作型資料庫的數據組織面向事務處理任務，而數據倉庫中的數據是按照一定的主題域進行組織。主題是指用戶使用數據倉庫進行決策時所關心的重點方面，一個主題通常與多個操作型信息系統相關。
數據倉庫是集成的，數據倉庫的數據有來自於分散的操作型數據，將所需數據從原來的數據中抽取出來，進行加工與集成，統一與綜合之後才能進入數據倉庫； 數據倉庫中的數據是在對原有分散的資料庫數據抽取、清理的基礎上經過系統加工、匯總和整理得到的，必須消除源數據中的不一致性，以保證數據倉庫內的信息是關於整個企業的一致的全局信息。 數據倉庫的數據主要供企業決策分析之用，所涉及的數據操作主要是數據查詢，一旦某個數據進入數據倉庫以後，一般情況下將被長期保留，也就是數據倉庫中一般有大量的查詢操作，但修改和刪除操作很少，通常只需要定期的載入、刷新。 數據倉庫中的數據通常包含歷史信息，系統記錄了企業從過去某一時點(如開始應用數據倉庫的時點)到當前的各個階段的信息，通過這些信息，可以對企業的發展歷程和未來趨勢做出定量分析和預測。
數據倉庫是不可更新的，數據倉庫主要是為決策分析提供數據，所涉及的操作主要是數據的查詢；
數據倉庫是隨時間而變化的，傳統的關系資料庫系統比較適合處理格式化的數據，能夠較好的滿足商業商務處理的需求。穩定的數據以只讀格式保存，且不隨時間改變。
匯總的。操作性數據映射成決策可用的格式。
大容量。時間序列數據集合通常都非常大。
非規范化的。Dw數據可以是而且經常是冗餘的。
元數據。將描述數據的數據保存起來。
數據源。數據來自內部的和外部的非集成操作系統。
可以參考這篇文章：數據倉庫(1)什麼是數據倉庫 - 知乎 (hu.com)
Ⅶ 資料庫設計中什麼時候要進行適當的反規范化
1�反規范的好處
是否規范化的程度越高越好?這要根據需要來決定，因為「分離」越深，產生的關系越多，關系過多，連接操作越頻繁，而連接操作是最費時間的，特別對以查詢為主的資料庫應用來說，頻繁的連接會影響查詢速度。所以，關系有時故意保留成非規范化的，或者規范化以後又反規范了，這樣做通常是為了改進性能。
例如帳戶系統中的「帳戶」表B－TB01，它的列busi－balance(企業帳戶的總余額)就違反規范，其中的值可以通過下面的查詢獲得：
select busi－code,sum(acc－balance)
from B－TB06
group by busi－code
如果B－TB01中沒有該列，若想獲得busi－name(企業名稱)和企業帳戶的總余額，則需要做連接操作：
select busi－name,sum(acc－balance)
from B－TB01,B－TB06
where B－TB01.busi－code=B－TB06.busi－code
group by busi－code
如果經常做這種查詢，則就有必要在B－TB01中加入列busi－balance，相應的代價則是必須在表B－TB06上創建增、刪、改的觸發器來維護B－TB01表上busi－balance列的值。類似的情況在決策支持系統中經常發生。
反規范的好處是降低連接操作的需求、降低外碼和索引的數目，還可能減少表的數目，相應帶來的問題是可能出現數據的完整性問題。加快查詢速度，但會降低修改速度。因此決定做反規范時，一定要權衡利弊，仔細分析應用的數據存取需求和實際的性能特點，好的索引和其它方法經常能夠解決性能問題，而不必採用反規范這種方法。
2�常用的反規范技術
在進行反規范操作之前，要充分考慮數據的存取需求、常用表的大小、一些特殊的計算(例如合計)、數據的物理存儲位置等。常用的反規范技術有增加冗餘列、增加派生列、重新組表和分割表。
(1)增加冗餘列是指在多個表中具有相同的列，它常用來在查詢時避免連接操作。例如前面例子中，如果經常檢索一門課的任課教師姓名，則需要做class和teacher表的連接查詢：
select class－name,teacher－name
from class,teacher
where class.teacher－no=teacher.teacher－no
這樣的話就可以在class表中增加一列teacher－name就不需要連接操作了。
增加冗餘列可以在查詢時避免連接操作，但它需要更多的磁碟空間，同時增加表維護的工作量。
(2)增加派生列指增加的列來自其它表中的數據，由它們計算生成。它的作用是在查詢時減少連接操作，避免使用集函數。例如前面所講的賬戶系統中的表B－TB01的列busi－balance就是派生列。派生列也具有與冗餘列同樣的缺點。
(3)重新組表指如果許多用戶需要查看兩個表連接出來的結果數據，則把這兩個表重新組成一個表來減少連接而提高性能。例如，用戶經常需要同時查看課程號，課程名稱，任課教師號，任課教師姓名，則可把表class(class－no,class－name,teacher－no)和表teacher(teacher－no,teacher－name)合並成一個表class(class－no,class－name,teacher－no,teacher－name)。這樣可提高性能，但需要更多的磁碟空間，同時也損失了數據在概念上的獨立性。
(4)有時對表做分割可以提高性能。表分割有兩種方式：
1水平分割：根據一列或多列數據的值把數據行放到兩個獨立的表中。
水平分割通常在下面的情況下使用。
·表很大，分割後可以降低在查詢時需要讀的數據和索引的頁數，同時也降低了索引的層數，提高查詢速度。
·表中的數據本來就有獨立性，例如表中分別記錄各個地區的數據或不同時期的數據，特別是有些數據常用，而另外一些數據不常用。
·需要把數據存放到多個介質上。
例如法規表law就可以分成兩個表active－law和inactive－law。activea－authors表中的內容是正生效的法規，是經常使用的，而inactive－law表則使已經作廢的法規，不常被查詢。
水平分割會給應用增加復雜度，它通常在查詢時需要多個表名，查詢所有數據需要union操作。在許多資料庫應用中，這種復雜性會超過它帶來的優點，因為只要索引關鍵字不大，則在索引用於查詢時，表中增加兩到三倍數據量，查詢時也就增加讀一個索引層的磁碟次數。
2垂直分割：把主碼和一些列放到一個表，然後把主碼和另外的列放到另一個表中。
如果一個表中某些列常用，而另外一些列不常用，則可以採用垂直分割，另外垂直分割可以使得數據行變小，一個數據頁就能存放更多的數據，在查詢時就會減少I/O次數。其缺點是需要管理冗餘列，查詢所有數據需要join操作。
3�反規范技術需要維護數據的完整性
無論使用何種反規范技術，都需要一定的管理來維護數據的完整性，常用的方法是批處理維護、應用邏輯和觸發器。
批處理維護是指對復制列或派生列的修改積累一定的時間後，運行一批處理作業或存儲過程對復制或派生列進行修改，這只能在對實時性要求不高的情況下使用。
數據的完整性也可由應用邏輯來實現，這就要求必須在同一事務中對所有涉及的表進行增、刪、改操作。用應用邏輯來實現數據的完整性風險較大，因為同一邏輯必須在所有的應用中使用和維護，容易遺漏，特別是在需求變化時，不易於維護。
另一種方式就是使用觸發器，對數據的任何修改立即觸發對復制列或派生列的相應修改。觸發器是實時的，而且相應的處理邏輯只在一個地方出現，易於維護。一般來說，是解決這類問題的最好的辦法。
Ⅷ 學會如何應用資料庫——資料庫規范化技巧 （1）
簡介在設計資料庫時，最重要的步驟是要確保數據正確分布到資料庫的表中。使用正確的數據結構，可以極大地簡化應用程序的其他內容（查詢、窗體、報表、代碼等）。正確進行表設計的正式名稱是「資料庫規范化」。 本文簡要介紹資料庫規范化的基本概念和一些需要注意並力求避免的常見問題。 理解您的數據在設計表之前，應明確您打算如何處理數據，還要了解隨著時間的推移數據會發生什麼樣的變化。您所做的假設將會影響最終的設計。 您需要什麼樣的數據？ 設計應用程序時，關鍵要了解設計的最終結果，以便確保您准備好所有必需的數據並知道其來源。例如，報表的外觀、每個數據的來源以及所需的所有數據是否都存在。對項目損失最大的莫過於在項目後期發現重要報表缺少數據。 知道需要什麼樣的數據後，就必須確定數據的來源。數據是否從其他數據源中導入？數據是否需要清理或驗證？用戶是否需要輸入數據？ 明確所需數據的類型和來源是資料庫設計的第一步。 您打算如何處理這些數據？用戶是否需要編輯這些數據？如果需要，應如何顯示數據以便於用戶理解和編輯？有沒有驗證規則和相關的查找表？要求對編輯和刪除保留備份的數據輸入有沒有相關聯的審核問題？需要為用戶顯示哪些摘要信息？是否需要生成導出文件？了解這些信息後，就可以想像欄位之間是如何相互關聯的了。 數據之間如何相互關聯？將數據分組放入相關欄位（例如與客戶相關的信息、與發票相關的信息等），每個欄位組都代表要建立的表。然後考慮如何將這些表相互關聯。例如，哪些表具有一對多關系（例如，一個客戶可能持有多張發票）？哪些表具有一對一關系（這種情況下，通常會考慮將其組合到一個表中）？ 隨著時間的推移數據會發生什麼樣的變化？設計表之後，常常會由於沒有考慮時間的影響而導致以後出現嚴重問題。許多表設計在當時使用時效果非常好，但是，常常會因為用戶修改數據、添加數據以及隨時間的推移而崩潰。開發人員經常會發現需要重新設計表的結構來適應這些變化。表的結構發生變化時，所有相關的內容（查詢、窗體、報表、代碼等）也必須隨之更新。理解並預測數據會隨時間推移發生哪些變化，可以實現更好的設計，減少問題的發生。 學習如何使用查詢了解如何分析和管理數據同樣很重要。您應該深刻理解查詢的工作原理，理解如何使用查詢在多個表之間鏈接數據，如何使用查詢對數據進行分組和匯總，以及如何在不需要以規范化格式顯示數據時使用交叉表查詢。 好的數據設計的最終目標就是要平衡兩個需要：既要隨著時間的推移有效地存儲數據，又要輕松地檢索和分析數據。理解查詢的功能對正確設計表很有幫助。 資料庫規范化概念這部分介紹資料庫規范化所涉及的基本概念，而不是對資料庫規范化進行理論性的探討。如何在您的實際情況中應用這些概念可能會隨著應用程序需要的不同而有所變化。這部分的目的是理解這些基本概念、根據實際需要應用它們，並理解偏離這些概念將會出現哪些問題。 將唯一信息存儲在一個地方大部分資料庫開發人員都理解資料庫規范化的基本概念。理想情況下，您希望將相同的數據存儲在同一個地方，並在需要引用時使用 ID 來進行引用。因此，如果某些信息發生了變化，則可以在一個地方進行更改，而整個程序中的相應信息也會隨之更改。 例如，客戶表會存儲每個客戶的記錄，包括姓名、地址、電話號碼、電子郵件地址以及其他特徵信息。客戶表中可能包含唯一的 CustomerID 欄位（通常是 Autonumber 欄位），這個欄位即該表的主鍵欄位，其他表使用它來引用該客戶。因此，發票表可以只引用客戶的 ID 值，而不是在每張發票中存儲客戶的所有信息（因為同一個客戶可能會持有多張發票），這樣利用客戶的 ID 值即可從客戶表中查找客戶的詳細信息。使用 Access 中功能強大的窗體（使用組合框和子窗體），可以輕松地完成這項工作。如果需要修改客戶信息（例如新增電話號碼），只需在客戶表中修改，應用程序中引用該信息的任何其他部分都會隨之自動更新。 使用正確規范化的資料庫，通過簡單的編輯即可輕松處理數據隨時間推移而發生的更改。使用未正確規范化的資料庫，通常需要利用編程或查詢來更改多條記錄或多個表。這不僅會增加工作量，還會增加由於未正確執行代碼或查詢而導致數據不一致的可能性。 記錄是免費的，而新欄位非常昂貴理想的資料庫應該只需要隨著時間的推移添加新的記錄，資料庫表應該能夠保存大量記錄。但是，如果您發現需要增加更多欄位，則可能會碰到設計問題。 電子表格專家經常會遇到上述問題，因為他們習慣於按照設計電子表格的方式設計資料庫。設計經常隨時間變化的欄位（例如，年、季度、產品和銷售人員）需要在將來添加新欄位。而正確的設計應該是轉換信息並將隨時間變化的數據放在一個欄位內，這樣就可以添加更多記錄。例如，只需創建「年」欄位，然後在該欄位中輸入各記錄相應的年份值即可，無需為每年創建一個單獨的欄位。 增加額外的欄位可能會產生問題，因為表結構的變化會對應用程序的其他部分產生影響。在表中添加更多欄位時，依賴該表的對象和代碼也需要更新。例如，查詢需要獲取額外的欄位，窗體需要顯示這些欄位，而報表則需要包含這些欄位，等等。但是，如果數據已經規范化，則現有對象會自動檢索新數據，並正確計算或顯示這些數據。查詢功能尤其強大，因為它允許您按「年」欄位進行分組，以逐年顯示摘要（不管表中包含哪些年份）。 但是，數據規范化並不意味著不能顯示或使用隨時間而變化或依賴時間的欄位。需要瀏覽或顯示這類信息的開發人員通常可以使用交叉表查詢來達到這一目的。如果您不熟悉交叉表查詢，應該學習如何使用它們。雖然它們與表有所不同（尤其是用戶無法編輯交叉表查詢的結果），但它們的確可以用於在數據表中顯示信息（最多可以達到 255 個欄位）。如果要在報表中使用它們，則會更加復雜，因為報表需要包含額外的或不斷變化的欄位名。這就是為什麼大多數報表將數據作為獨立的分組（而不是獨立的列）顯示的原因。對於那些別無選擇的情況，您必須花時間去解決這個問題。希望所有人都能夠理解這種決定會隨著時間的變化對其他資源產生的影響。 這就是為什麼增加記錄是免費的（這是資料庫的巨大優勢）而增加欄位是如此昂貴的原因。
Ⅸ 什麼是資料庫中的規范化
規范化理論把關系應滿足的規范要求分為幾級，滿足最低要求的一級叫做第一範式(1NF)，在第一範式的基礎上提出了第二範式(2NF)，在第二範式的基礎上又提出了第三範式(3NF)，以後又提出了BCNF範式，4NF，5NF。範式的等級越高，應滿足的約束集條件也越嚴格。
第一範式（1NF）
在關系模式R中中，如果每個屬性值都是不可再分的原子屬性，則稱R是第一範式的關系[2]。例如：關系R（職工號，姓名，電話號碼）中一個人可能有一個辦公室電話和一個住宅電話號碼，規范成為1NF的方法一般是將電話號碼分為單位電話和住宅電話兩個屬性，即 R（職工號，姓名，辦公電話，住宅電話）。1NF是關系模式的最低要求。
第二範式（2NF）
如果關系模式R是1NF且其中的所有非主屬性都完全函數依賴於關鍵字，則稱關系R 是屬於第二範式的[2]。例：選課關系 SC（SNO，CNO，GRADE，CREDIT）其中SNO為學號， CNO為課程號，GRADEGE 為成績，CREDIT 為學分。 由以上條件，關鍵字為組合關鍵字（SNO，CNO）。在應用中使用以上關系模式有以下問題： （1）數據冗餘，假設同一門課由40個學生選修，學分就重復40次；（2）更新復雜，若調整了某課程的學分，相應元組的CREDIT值都要更新，有可能會出現同一門課學分不同；（3）插入異常，如計劃開新課，由於沒人選修，沒有學號關鍵字，只能等有人選修才能把課程和學分存入；（4）.刪除異常，若學生已經結業，從當前資料庫刪除選修記錄，而某些課程新生尚未選修，則此門課程及學分記錄無法保存。以上問題產生的原因是非主屬性CREDIT僅函數依賴於CNO，也就是CREDIT部分依賴組合關鍵字（SNO，CNO）而不是完全依賴。解決方法是將以上關系分解成兩個關系模式 SC（SNO，CNO，GRADE）和C（CNO，CREDIT）。新關系包括兩個關系模式，它們之間通過SC中的外鍵CNO相聯系，需要時再進行自然聯接，恢復原來的關系
第三範式（3NF）
如果關系模式R是2NF且其中的所有非主屬性都不傳遞依賴於碼，則稱關系R是屬於第三範式的[1]。例如關系模式S（SNO，SNAME，DNO，DNAME，LOCATION）中各屬性分別代表學號、姓名、所在系、系名稱、系地址。關鍵字SNO決定各個屬性。由於是單個關鍵字，沒有部分依賴的問題，肯定是2NF。但關系S肯定有大量的冗餘，有關學生所在系的幾個屬性DNO，DNAME，LOCATION將重復存儲，插入、刪除和修改時也將產生類似以上例的情況。原因在於關系中存在傳遞依賴，即SNO -> DNO，DNO -> LOCATION, 因此關鍵字SNO對LOCATION函數決定是通過傳遞依賴SNO -> LOCATION 實現的。也就是說，SNO不直接決定非主屬性LOCATION。解決方法是將該關系模式分解為兩個關系S（SNO，SNAME，DNO）和D（DNO，DNAME，LOCATION），兩個關系通過S中的外鍵DNO聯系。
BC範式(BCNF)
如果關系模式R的所有屬性（包括主屬性和非主屬性）都不傳遞依賴於R的任何候選關鍵字，那麼稱關系R是屬於BCNF的。或者說關系模式R中，如果每個決定因素都包含關鍵字（而不是被關鍵字所包含），則R是BCNF[3]。 通常認為BCNF是修正的第三範式，有時也稱為擴充的第三範式。
Ⅹ 關系資料庫規范化理論的基礎和內容
一個關系資料庫模式由一組關系模式組成，一個關系模式由一組屬性名組成。關系資料庫設計，就是如何把已給定的相互關聯的一組屬性名分組，並把每一組屬性名組成關系的問題。然而，屬性的分組不是唯一的，不同的分組對應著不同的資料庫應用系統，它們的效率往往相差很遠。
為了使資料庫設計合理可靠，簡單實用，長期以來，形成了關系資料庫設計的理論——規范化理論。
6.1 關系規范化的作用
規范化，就是用形式更為簡潔，結構更加規范的關系模式取代原有關系模式的過程。
如果將兩個或兩個以上實體的數據存放在一個表裡，就會出現下列三個問題：
Ø 數據冗餘度大
Ø 插入異常
Ø 刪除異常
所謂數據冗餘，就是相同數據在資料庫中多次重復存放的現象。數據冗餘不僅會浪費存儲空間，而且可能造成數據的不一致性。
插入異常是指，當在不規范的數據表中插入數據時，由於實體完整性約束要求主碼不能為空的限制，而使有用數據無法插入的情況。
刪除異常是指，當不規范的數據表中某條需要刪除的元組中包含有一部分有用數據時，就會出現刪除困難。
（以P98工資表為例）
解決上述三個問題的方法，就是將不規范的關系分解成為多個關系，使得每個關系中只包含一個實體的數據。
（講例子解）
當然，改進後的關系模式也存在另一問題，當查詢職工工資時需要將兩個關系連接後方能查詢，而關系連接的代價也是很大的。
那麼，什麼樣的關系需要分解？分解關系模式的理論依據又是什麼？分解完後能否完全消除上述三個問題？回答這些問題需要理論指導。下面，將加以討論：
6.2 函數依賴
6.2.1屬性間關系
實體間的聯系有兩類：一類是實體與實體之間聯系；另一類是實體內部各屬性間的聯系。資料庫建模一章中討論的是前一類，在這里我們將學習第二類。
和第一類一樣，實體內部各屬性間的聯系也分為1:1、1:n和m:n三類：
例：職工（職工號，姓名，身份證號碼，職稱，部門）
1、 一對一關系（1:1）
設X、Y是關系R的兩個屬性（集）。如果對於X中的任一具體值，Y中至多有一個值與之對應，反之，對於Y中的任一具體值，X中也至多有一個值與之對應，則稱X、Y兩屬性間是一對一關系。
如本例職工關系中職工號與身份證號碼之間就是一對一關系。
2、一對多關系（1:n）
設X、Y是關系R的兩個屬性（集）。如果對於X中的任一具體值，Y中可以找到多個值與之對應，而對於Y中的任一具體值，X中至多隻有一個值與之對應，則稱屬性X對Y是一對多關系。
如職工關系中職工號與職稱之間就是一對多的關系。
3、多對多關系（m:n）
設X、Y是關系R的兩個屬性（集）。如果對於X中的任一具體值，Y中有n個值與之對應，而對於Y中的任一具體值，X中也有m個值與之對應，則稱屬性X對Y是一對多（m:n）關系。
例如，職工關系中，職稱與部門之間就是多對多的關系。
上述屬性間的三種關系，實際上是屬性值之間相互依賴與相互制約的反映，因而稱之為屬性間的數據依賴。
數據依賴共有三種：
Ø 函數依賴（Functional Dependency，FD）
Ø 多值依賴（Multivalued Dependency，MVD）
Ø 連接依賴（Join Dependency，JD）
其中最重要的是函數依賴和多值依賴。
6.2.2 函數依賴
函數依賴，是屬性之間的一種聯系。在關系R中，X、Y為R的兩個屬性或屬性組，如果對於R的所有關系r 都存在：對於X的每一個具體值，Y都只有一個具體值與之對應，則稱屬性Y函數依賴於屬性X。或者說，屬性X函數決定屬性Y，記作X→Y。其中X叫作決定因素，Y叫作被決定因素。
上述定義，可簡言之：如果屬性X的值決定屬性Y的值，那麼屬性Y函數依賴於屬性X。換一種說法：如果知道X的值，就可以獲得Y的值，則可以說X決定Y。
若Y函數不依賴於X，記作：X→Y。
X Y
若X→Y，Y→X，記作：
前面學習的屬性間的三種關系，並不是每種關系中都存在著函數依賴。
u 如果X、Y間是1:1關系，則存在函數依賴 X←→Y
u 如果X、Y間是1:n關系，則存在函數依賴： X→Y或Y→X（多方為決定因素）
u 如果X、Y間是m:n關系，則不存在函數依賴。
注意，屬性間的函數依賴不是指R的某個或某些關系子集滿足上述限定條件，而是指R的一切關系子集都要滿足定義中的限定。只要有一個具體的關系r（R的一個關系子集）不滿足定義中的條件，就破壞了函數依賴，使函數依賴不成立。
這里的關系子集，指的是R的某一部分元組的集合，例如：地測學院的學生關系中只包含了地測學院學生的數據，所以它是長安大學學生關系的一個子集。
6.2.3 碼的定義
前面，我們對碼進行了直觀化的定義，下面用函數依賴的概念對碼作出較為精確的形式化的定義：
設K是關系模式R（U，F）中的屬性或屬性組，K』是K的任一子集。若K→U，而不存在K』→U，則K為R的候選碼（Candidate Key）
Ø 若候選碼多於一個，則選其中的一個為主碼（Primary Key）；
Ø 包含在任一候選碼中的屬性，叫做主屬性（Primary Attribute）；
Ø 不包含在任何碼中的屬性稱為非主屬性（Nonprime Attribute）或非碼屬性（Nonkey Attribute）
Ø 關系模式中，最簡單的情況是單個屬性是碼，稱為單碼（Single Key）；最極端的情況是整個屬性組是碼，稱為全碼（All－Key）。
前面已多次遇到單碼的情況，下面是一個全碼的例子：
簽約（演員名，製片公司，電影名）
外碼：設有兩個關系R和S，X是R的屬性或屬性組，並且X不是R的碼，但X是S的碼（或與S的碼意義相同），則稱X是R的外部碼（Foreign Key），簡稱外碼或外鍵。
如：職工（職工號，姓名，性別，職稱，部門號）
部門（部門號，部門名，電話，負責人）
其中職工關系中的「部門號」就是職工關系的一個外碼。
在此需要注意，在定義中說X不是R的碼，並不是說X不是R的主屬性，X不是碼，但可以是碼的組成屬性，或者是任一候選碼中的一個主屬性。
如：學生（學生號，姓名，性別，年齡…）
課程（課程號，課程名，任課老師…）
選課（學生號，課程號，成績）
在選課關系中，（學生號，課程號）是該關系的碼，學生號、課程號又分別是組成主碼的屬性（但單獨不是碼），它們分別是學生關系和課程關系的主碼，所以是選課關系的兩個外碼。
關系間的聯系，可以通過同時存在於兩個或多個關系中的主碼和外碼的取值來建立。如要查詢某個職工所在部門的情況，只需查詢部門表中的部門號與該職工部門號相同的記錄即可。所以，主碼和外碼提供了一個表示關系間聯系的途徑。
6.2.4 函數依賴和碼的唯一性
由上述碼的形式化定義，我們可以說：碼是由一個或多個屬性組成的，可唯一標識元組的最小屬性組。
碼在關系中總是唯一的，即一個碼函數唯一地決定一行。如果碼的值重復，則整個元組都會重復。否則，違反了實體完整性規則。而元組的重復則表示存在兩個完全相同的實體，這顯然是不可能的，所以碼是不允許重復取值的。
所以，只有當某個屬性或屬性組能夠函數決定關系中的每一個其它的屬性，且該屬性組的任何一個真子集都做不到這一點時，該屬性或屬性組才是該關系的碼。
函數依賴是一個與數據有關的事物規則的概念。如果屬性B函數依賴於屬性A，那麼若知道了A的值，則完全可以找到B的值。這並非是可以由A的值計算出B的值，而是邏輯上只能存在一個B的值。
6.3 關系模式的規范化
一、非規范化的關系
當一個表中存在還可以再分的數據項時，這個表就是非規范化的表。非規范化表存在兩種情況：
Ø 表中具有組合數據項（P102表6-4）
Ø 表中具有多值數據項（P103表6-5）
例：
職工號
姓名
工資
基本工資
職務工資
工齡工資
1002
張三
1000
800
200
職工號
姓名
職稱
系名
系辦地址
學歷
畢業年份
001
張三
教授
計算機
1305
大學
研究生
1963
1982
那麼什麼是規范化關系呢？
當一個關系中的所有分量都是不可再分的數據項時，該關系是規范化的。即當表中不存在組合數據項和多值數據項，只存在不可分的數據項時，這個表是規范化的。
二維表按其規范化程度從低到高可分為5級範式（Normal Form），分別稱為1NF、2NF、3NF（BCNF）、4NF、5NF。規范化程度較高者必是較低者的子集，即：
1NF 2NF 3NF BCNF 4NF 5NF
二、第一範式（1NF）
定義1：如果關系模式R中不包含多值屬性，則R滿足第一範式（First Normal Form），記作：
R∈1NF
1NF是對關系的最低要求，不滿足1NF的關系是非規范化的關系。
非規范化關系轉化為規范化關系1NF方法很簡單，只要上表分別從橫向、縱向展開即可。如下表：
職工號
姓名
基本工資
職務工資
工齡工資
1002
張三
1000
800
200
1005
李四
1200
900
150
職工號
姓名
職稱
系名
系辦地址
學歷
畢業年份
1002
張三
教授
計算機
1305
大學
1963
1002
張三
教授
計算機
1305
研究生
1982
1005
李四
講師
信電
2206
大學
1989
上表雖然符合1NF，但仍是有問題的關系，表中存在大量的數據冗餘和潛在的數據更新異常。原因是（職工號，學歷）是右表的碼，但姓名、職稱、系名、系辦地址卻與學歷無關，只與碼的一部分有關。所以上表還需進一步地規范化。
三、第二範式（2NF）
定義1：設X、Y是關系R的兩個不同的屬性或屬性組，且X → Y。如果存在X的某一個真子集X』，使X』 → Y成立，則稱Y部分函數依賴於X，記作：X P→ Y（Partial）。反之，則稱Y完全函數依賴於X，記作：X F→ Y （Full）
定義2：如果一個關系 R∈1NF，且它的所有非主屬性都完全函數依賴於R的任一候選碼，則R屬於第二範式，記作：R∈2NF。
說明：上述定義中所謂的候選碼也包括主碼，因為碼首先應是候選碼，才可以被指定為碼。
例如關系模式：
職工（職工號，姓名，職稱，項目號，項目名稱，項目角色）中
（職工號，項目號）是該關系的碼，而職工號→姓名、職工號→職稱、項目號→項目名稱…
所以（職工號，項目號）P→ 職稱、（職工號，項目號）P→ 項目名稱
故上述職工關系不符合第二範式要求。它存在三個問題：插入異常、刪除異常和修改異常。
其中修改異常是這樣的，當職工關系中項目名稱發生變化時，由於參與該項目的人員很多，每人一條記錄，要修改項目信息，就得對每一個參加該項目的人員信息進行修改，加大了工作量，還有可能發生遺漏，存在著數據一致性被破壞的可能。
可把上述職工關系分解成如下三個關系：
職工（職工號，姓名，職稱）
參與項目（職工號，項目號，項目角色）
項目（項目號，項目名稱）
上述三個關系都符合定義2的要求，所以都符合2NF
推論：如果關系模式R∈1NF，且它的每一個候選碼都是單碼，則R∈2NF
符合第二範式的關系模式仍可能存在數據冗餘、更新異常等問題。如關系
職工信息（職工號，姓名，職稱，系名，系辦地址）
雖然也符合2NF，但當某個系中有100名職工時，元組中的系辦地址就要重復100次，存在著較高的數據冗餘。原因是關系中，系辦地址不是直接函數依賴於職工號，而是因為職工號函數決定系名，而系名函數決定系辦地址，才使得系辦地址函數依賴於職工號，這種依賴是一個傳遞依賴的過程。
所以，上述職工信息的關系模式還需要進一步的規范化。
四、第三範式（3NF）
定義1：在關系R中，X、Y、Z是R的三個不同的屬性或屬性組，如果X→Y，Y→Z， 但Y→X，且Y不是X的子集，則稱Z傳遞函數依賴於X。
定義2：如果關系模式R∈2NF，且它的每一個非主屬性都不傳遞依賴於任何候選碼，則稱R是第三範式，記作：R∈3NF
推論1：如果關系模式R∈1NF，且它的每一個非主屬性既不部分依賴、也不傳遞依賴於任何候選碼，則R∈3NF
推論2：不存非主屬性的關系模式一定為3NF
五、改進的3NF——BCNF（Boyee－Codd Normal Form）
定義：設關系模式R（U，F）∈1NF，若F的任一函數依賴X→Y（Y X）中X都包含了R的一個碼，則稱R∈BCNF。
換言之，在關系模式R中，如果每一個函數依賴的決定因素都包含碼，則R∈BCNF
推論：如果R∈BCNF，則：
Ø R中所有非主屬性對每一個碼都是完全函數依賴；
Ø R中所有主屬性對每一個不包含它的碼，都是完全函數依賴；
Ø R中沒有任何屬性完全函數依賴於非碼的任何一組屬性。
定理：如果R∈BCNF，則R∈3NF一定成立。
證明：（結合傳遞依賴的定義，用反證法）
注意：當R∈3NF時，R未必屬於BCNF。因為3NF比BCNF放寬了一個限制，它允許決定因素不包含碼。例如：
通訊（城市名，街道名，郵政編碼）中：
F＝｛（城市名，街道名）→郵政編碼，郵政編碼→城市名｝
非主屬性郵政編碼完全函數依賴於碼，且無傳遞依賴，故屬於3NF，但郵政編碼也是一個決定因素，而且它沒有包含碼，所以該關系不屬於BCNF。
又如：
Teaching（Student，Teacher，Course） 簡記為Teaching（S，T，C）
規定：一個教師只能教一門課，每門課程可由多個教師講授；學生一旦選定某門課程，教師就相應地固定。
F＝｛T→C，（S，C）→T,(S，T) →C｝
該關系的候選碼是（S，C）和（S，T），因此，三個屬性都是主屬性，由於不存在非主屬性，該關系一定是3NF。但由於決定因素T沒包含碼，故它不是BCNF。
關系模式Teaching仍然存在著數據冗餘問題，因為存在著主屬性對碼的部分函數依賴問題。
確切地表示：F＝｛T→C，（S，C）P→T,(S，T) P→C｝
所以Teaching關系可以分解為以下兩個BCNF關系模式：
Teacher（Teacher，Course） Student（Student，Teacher）
3NF的「不徹底」性，表現在可能存在主屬性對碼的部分依賴和傳遞依賴。
一個關系模式如果達到了BCNF，那麼，在函數依賴范圍內，它就已經實現了徹底的分離，消除了數據冗餘、插入和刪除異常。
6.4 多值依賴和第四範式
一、多值依賴（Multivalued Dependency）
課程C
教員T
參考書B
物理
李勇
普通物理學
物理
李勇
光學原理
物理
李勇
物理習題集
物理
王軍
普通物理學
物理
王軍
光學原理
物理
王軍
物理習題集
數學
李勇
數學分析
數學
李勇
微分方程
數學
李勇
高等代數
數學
張平
數學分析
數學
張平
微分方程
數學
張平
高等代數
計算數學
張平
數學分析
計算數學
張平
計算數學
計算數學
周峰
數學分析
計算數學
周峰
計算數學
課程C
教員T
參考書B
物理
李勇
王軍
普通物理學
光學原理
物理習題集
數學
李勇
張平
數學分析
微分方程
高等代數
計算數學
張平
周峰
數學分析
計算數學
例：學校中某一門課程由多個教員講授，他們使用相同的一套參考書，每個教員可以講授多門課程，每種參考書可以供多門課程使用。下列是用一個非規范化的表來表示教員T，課程C和參考書B之間的關系。
把上表變換成一張規范化的二維表Teaching，如右表
關系模式Teaching（C，T，B）的碼是（C，T，B），即All－Key。因而Teaching∈BCNF。按照上述語義規定，當某門課程增加一名講課教員時，就要向Teaching表中增加與相應參考書等數目的元組。同樣，某門課程要去掉一本參考書時，則必須刪除相應數目的元組。
對數據的增、刪、改很不方便，數據的冗餘也十分明顯。如果仔細考察這類關系模式，會發現它具有一種稱之為多值依賴的數據依賴關系。
定義：設R（U）是屬性集U上的一個關系模式，X，Y，Z是U的子集，且Z＝U-X-Y。如果對R（U）的任一關系r，給定一對（x，z）值，都有一組y值與之對應，這組y值僅僅決定於x值而與z值無關。則稱Y多值依賴於X，或X多值決定Y，記作：X→→Y。――
例如，在關系模式Teaching中，對於一個（C，B）值（物理，普通物理學），有一組T值｛李勇，王軍｝，而這組值僅僅決定於課程C上的值（物理）。即對於另一個（物理，光學原理），它對應的T值仍然是｛李勇，王軍｝，所以T的值與B的值無關，僅決定於C的值，即C→→T 。
多值依賴的另一個等價的形式化定義為：
設關系模式R（U），X、Y、Z是U的子集，Z＝U-X-Y，r是R的任意一個關系，t1、t2是r的任意兩個元組。如果t1[X]=t2[X]，並在r中存在兩個元組t3、t4，使得：
t3[X]=t4[X]=t1[X]
t3[Y]=t1[Y]，t3[Z]=t2[Z]，
t4[Y]=t2[Y]，t4[Z]=t1[Z]
成立，則X→→Y。
換句話說：如果X→→Y在R（U）中成立，則只要在R的任一關系r中存在兩個元組t1、t2在X屬性上的值相等，則交換這兩個元組在Y（或Z）上的值後得到的兩個新元組t3、t4也必是關系r中的元組。
定義中如果Z＝Ф（空集），則稱X→→Y為平凡的多值依賴，否則為非平凡的多值依賴。
多值依賴具有如下性質：
1. 對稱性：若X→→Y，則X→→Z，其中Z＝U-X-Y
2. 傳遞性：若X→→Y，Y→→Z，則X→→Z-Y
3. 若X→→Y，X→→Z，則X→→YZ
4. 若X→→Y，X→→Z，則X→→Y∩Z
5. 若X→→Y，X→→Z，則X→→Y-Z，X→→Z-Y
多值依賴與函數依賴相比，具有下面兩個基本區別：
（1）多值依賴的有效性與屬性集的范圍有關
若X→→Y在U上成立，則在V（XY V U）上一定成立；反之則不然，即X→→Y在V(V U)上成立，在U上並不一定成立。這是因為多值依賴的定義中不僅涉及屬性組X、Y，而且涉及U中的其餘屬性Z（Z＝U-X-Y）。
一般地說，在R（U）上若有X→→Y在V（V U）上成立，則稱X→→Y為R（U）的嵌入型多值依賴。
而在關系模式R（U）中函數依賴X→Y的有效性，僅決定於X和Y這兩個屬性集的值。只要在R（U）的任何一個關系r中，元組在X和Y上的值使得X→Y成立，則X→Y在任何屬性集V（XY V U）上也成立。
（2）若函數依賴X→Y在R（U）上成立，則對於任何Y』 Y 均有X→Y』 成立。而多值依賴X→→Y若在R（U）上成立，卻不能斷言對於任何Y』 Y有X→→Y』 成立。
多值依賴的約束規則：在具有多值依賴的關系中，如果隨便刪去一個元組，就會破壞其對稱性，那麼，為了保持多值依賴關系中的「多值依賴」性，就必須刪去另外的相關元組以維持其對稱性。這就是多值依賴的約束規則。目前的RDBMS尚不具有維護這種約束的能力，需要程序員在編程中實現。
函數依賴可看成是多值依賴的特例，即函數依賴一定是多值依賴。而多值依賴則不一定就有函數依賴。
二、第四範式（4NF）
定義：如果關系模式R∈1NF，對於R的每個非平凡的多值依賴X→→Y（Y X），X含有碼，則稱R是第四範式，即R∈4NF
課程C
教員T
參考書B
物理
李勇
普通物理學
物理
李勇
光學原理
物理
李勇
物理習題集
物理
王軍
普通物理學
物理
王軍
光學原理
物理
王軍
物理習題集
數學
李勇
數學分析
數學
李勇
微分方程
數學
李勇
高等代數
數學
張平
數學分析
數學
張平
微分方程
數學
張平
高等代數
計算數學
張平
數學分析
計算數學
張平
計算數學
計算數學
周峰
數學分析
計算數學
周峰
計算數學
Teaching關系
關系模式R∈4NF時，R中所有的非平凡多值依賴實際上就是函數依賴。因為每一個決定因素中都含有碼，所以R一定屬於BCNF。
4NF實際上就是限制關系模式的屬性間不允許有非平凡，而且非函數依賴的多值依賴存在。反過來說，4NF所允許的非平凡多值依賴實際上是函數依賴。
例題中的Teaching關系屬於BCNF，但它不屬於4NF。因為它的碼是（C，T，B），關系中存在非平凡多值依賴C→→T ，C→→B，但C不包含碼，而只是碼的一部分。
課程C
參考書B
物理
普通物理學
物理
光學原理
物理
物理習題集
數學
數學分析
數學
微分方程
數學
高等代數
計算數學
數學分析
計算數學
計算數學
CB關系
課程C
教員T
物理
李勇
物理
王軍
數學
李勇
數學
張平
計算數學
張平
計算數學
周峰
CT關系
要使Teaching關系符合4NF，必須將其分解為CT（C，T）和CB（C，B）兩個關系模式。如右表：
從表中顯而易見，符合BCNF的關系Teaching仍然存在著數據冗餘，而分解後的關系CT和CB中只有平凡多值依賴，所以符合4NF，它們已經消除了數據冗餘。可以說：BCNF是在只有函數依賴的關系模式中，規范化程度最高的範式，而4NF是在有多值依賴的關系模式中，規范化程度最高的範式。
如果關系模式中存在連接依賴，即便它符合4NF，仍有可能遇到數據冗餘及更新異常等問題。所以對於達到4NF的關系模式，還需要消除其中可能存在的連接依賴，才可以進一步達到5NF的關系模式。
關於連接依賴和5NF的內容，已超出了本課程教學大綱的要求，在此不再介紹。