1、你真的了解“范式”嗎?就關(guān)系數(shù)據(jù)庫而言，一貫認(rèn)為：從其他元素中消除數(shù)據(jù)冗余問題，去除重復(fù)往往以減少冗余，從特定的表中最小化冗余意味著擺脫不必要的數(shù)據(jù)。商業(yè)上來講，主要目標(biāo)是通常保存空間和組織的數(shù)據(jù)可用性和可管理性，而不犧牲性能。此外，要求強烈繁忙的應(yīng)用程序和最終用戶的需要往往需要以多種方式打破規(guī)則的范式，以滿足性能要求。第三范式以外的范式常常被忽視和有時甚至是第三范式本身就是多余的。范式是一個升級的過程，每個上層的模式都是建立在下一級范式之上的。消除數(shù)據(jù)冗余的影響如下：物理空間需要存儲的數(shù)據(jù)減少?？跀?shù)據(jù)變得更有組織。范式化允許修改少量的數(shù)據(jù)（即單記錄）。換言之，一個表的具體字段記錄更新時，會影

2、響其他引用他的表。首先我們對一些概念性的東西來進(jìn)行一個總結(jié)，通過對這些概念的理解，從來從根本上做到合理的數(shù)據(jù)庫設(shè)計：一異常添加異常：當(dāng)我們添加一條記錄的時候，他依賴的主表記錄還沒有記錄，而該記錄已經(jīng)插入成功。刪除異常：當(dāng)我們的主表記錄刪除，而依賴他的子表沒有清空對應(yīng)的記錄。更新異常：當(dāng)我們的主表記錄有更新草組，而已來他的子表沒有相應(yīng)的更新記錄。二依賴，決定因子函數(shù)依賴:當(dāng)Y的值由X決定的時候，我們就說Y函數(shù)依賴于X，這就類似于一個線性方程:Y=X+1;類似的ERD圖中，我們這樣表示Cntegoiy#匚:血口口iylDoNameoFic，很清楚的看到表Category，中的主鍵是Category

3、lD,他決定著其他字段的值Name和Pic,我們就說Name或者Pic函數(shù)依賴于CategoryID，他們之間就是一個函數(shù)依賴關(guān)系。決定因素:如上例中，CategorylD就是一個決定因素，他決定其他字段的值，Y=X+1中，X就決定著Y的值，雖然加了一個常量。傳遞依賴:當(dāng)X決定Y，Y決定Z的時候，我們就說Z傳遞依賴于X，從這個ERD圖中，我們看到Account帳號表中的City字段，他被AccountID所決定，而City字段的值又決定了College的值，因為大學(xué)肯定是被城市所決定，所以College就傳遞依賴于AccountID。候選鍵:候選鍵（潛在的或允許的主鍵）可以扮演主鍵的角色他可以

4、是一個表中的一個字段或組合字段-也就是一條記錄中的唯一標(biāo)識。個表，Customer表（客戶表），字段分別表示，客戶ID,客戶名，貨幣縮寫碼，貨幣，轉(zhuǎn)換匯率，地址。這個表我們沒有定義主鍵，但是我們可以推測那些可以成為主鍵，那么那些鍵就叫做候選鍵。Custumerl#CList。eeID2oCustomei2oCurrencyCode2oCurrency?oExchangeF：ate2oAddress2CustomerCustumt!rlD2Custumt!i2CurrencyCode2Currency?ExchangeRate2AddressSoCustumerlD3oCustomersCurr

5、encyCode3Currency3Exch3ngeF：3te3Adcke：sS3Customer3oCustumerlD3#CustoE曲oCurrencyCode3oCurrency3oExcharigeRateSAddresS3Customer4CuKomerlD4CustDEEi4CurrencyCodEjSCurrency4Address4我們就看到了，所有能成為主鍵的可能，表中的#就是主鍵的標(biāo)識符。完全函數(shù)依賴：當(dāng)X決定Y,但是X不被X和Z的組合所決定，換句話說，YE依賴于獨立的X，如果Y依賴于X加上一些其他的東西，那就不是完全函數(shù)依賴，本質(zhì)上，決定因TravelT玉怕丨丨D匚:口

6、iit“l(fā)DoFupulication素X不能是一個組合鍵。，我們來看到旅游表Travel，Country是旅游的國家，Populication是旅游的城市，同時TravellD和CountrylD是主鍵，可以看出來只有CountryID決定著Populcation人口，但是這里有兩個主鍵，所以Populication并沒有完全函數(shù)依賴于主鍵組合，只部分依賴于CountryID多值依賴：某個字段中的值是一個集合，或者是用某種分隔符分割開來的元素集合，我們就稱Employee#Ee口1小忙已丨DotiilanagerlC1oNameoPath為多值依賴。很經(jīng)典的，Path保存的這個遞歸表的所有上

7、司的級別,比如老大的ID是1,老2是2,Path就保存1,2,像這樣的字段，我們就稱為多值依賴。循環(huán)依賴:循環(huán)依賴就如其名,是一個個閉環(huán)的依賴系統(tǒng)。A依賴于B,B依賴于C,C依賴于A。三范式（學(xué)術(shù)定義）第一范式（1NF）：消除表中所有重復(fù)的屬性。第二范式（2NF）：所有非鍵值字段必須全部完全函數(shù)依賴于主鍵，當(dāng)一個字段完全函數(shù)依賴于任一主鍵的一部分時，是不允許的。第三范式（3NF）：消除傳遞依賴，意味著一個字段必須非間接的依賴于主鍵正規(guī)化范式（BCDF）：所有表中的決定因素必須是一個候選鍵，如果只有一個候選鍵，那么就和第三范式是一樣的。第四范式（4NF）:消除多值依賴。第五范式（5NF）:消除循

8、環(huán)依賴。我們從一個比較容易的位置來理解范式，通過上述的理解，加上實際的操作范式，讓我們對數(shù)據(jù)庫的設(shè)計有一個比較深的認(rèn)識，以決定什么情況下用范式。1、第一范式（1NF）:通過創(chuàng)建一個新表來移除重復(fù)的元素，使他們成為一個主從關(guān)系或者是onetomany的關(guān)系，類似下圖：2、第二范式（2NF）:建立在1NF的基礎(chǔ)上，就是移除重復(fù)的列到一個新表中去，新表有唯一的主鍵，而主表有一個對新表的外鍵的引用，排除存在的部分依賴。如下圖：Bookid是book表的主鍵，而author是authorl的主鍵，在book表中建立author,主表有一個對子表的外鍵引用，而不是把author也定義為主鍵，那樣就存在部分

9、函數(shù)依賴，因為bookid就已經(jīng)確定了title，page，isbn等等信息。3、第三范式（3NF）：消除傳遞依賴，如下圖：我們把多對多的關(guān)系變化成上圖的關(guān)系。這是一種簡單的形式，下面展示一個另外一種情況：這里的表分別是客戶（客戶名，貨幣號，貨幣，貨幣，匯率，地址），提供商（客戶名，貨幣號，貨幣，匯率，地址）。首先他們的地址決定了他們的貨幣情況，而地址又是由客戶或者提供商決定的，所以他們之間存在一個傳遞依賴關(guān)系，而且最好是把相同的存在于不同地Account#.凸.ccountlDoCityoCollege方的數(shù)據(jù)移植到一個新表中去。前面我們提到了這個關(guān)系，也是一個不滿足第三范式的表，City和

10、College以及主鍵存在傳遞關(guān)系，所以可以把College移植到一個新表中去，還有一些存在訂單的表中，有類似（qty（數(shù)量），price（單價），total（總價）的結(jié)構(gòu)，qty和price決定了total，而訂單號決定了qty和，price，所以也存在一種依賴關(guān)系，我們要刪除total字段，但是不是都遵循范式的表都是好的結(jié)構(gòu)，我們還是要根據(jù)實際情況，比如在一個數(shù)據(jù)倉庫的設(shè)計中，匯總字段就是必須的。4、超三范式（Beyond3NF）中的onetoone關(guān)系，這個主要用戶當(dāng)我們表中一些字段經(jīng)常存在空值的時候，我們將存在的NULL字段移到一個新表中去，然后建立1對1的關(guān)系。5、BCNF范式：BC

11、NF劃分成多個表的表格，以確保沒有一個單一的表有更多不止一個潛在的主鍵。這是我的理解BCNF。在我看來，是BCNF用于商業(yè)環(huán)境是“過度設(shè)計“的。從本質(zhì)上講，從數(shù)學(xué)的角度上它的漂亮，但在商業(yè)環(huán)境中它不是很酷。下面的例子是一個BCNF轉(zhuǎn)換：Employee#EE口1OeIDoWanagerlDoNameoPath5、第四范式：消除多值依賴，很經(jīng)典的一個環(huán)境就是，我們的遞歸表問題,一個Manager有多個Employee，然后每條記錄都有一個Path來表示這種關(guān)系，所以path和Employeeld就存在一個多對多的關(guān)系。我們就應(yīng)該重新建立一個新表，用來消除Path字段,新表中就保留一個Employ

12、eeld作為外鍵，另外一個Employeeld用來表示他的下屬。6、第五范式（5NF）：消除循環(huán)依賴，如下圖:在這個實例中Solution表中的鍵都是主鍵，他們存在這樣的關(guān)系，每兩個組合的主鍵決定另外一個主鍵。比方項目1和經(jīng)理1就決定了有哪些下屬屬于項目1和經(jīng)理1關(guān)系，而一個經(jīng)理1和他的下屬員工又決定了他們參與了那些項目。所以他們之間其實是一個循環(huán)的依賴。7、反范式:這種類型的應(yīng)用在商業(yè)正?；h(huán)境將導(dǎo)致業(yè)績不佳,更精確的數(shù)學(xué)的必要性比商業(yè)要低的多。因此：Developers#D臼.佗1。口eDeveIoper#D佗Id口已oSkillsoCertificationEntit：1._38oDev

13、eIoperoCertification同樣的，對于第4范式，我們很多時候都沒有必要去消除他們里面多值的依賴，那樣對性能來說簡直是個噩夢。所以很多情況下，我們都是用類似的處理：=：killoDeveIoperoSkillsCSDN上的，顯示自己的技術(shù)就是這樣的反范式化轉(zhuǎn)換。在商業(yè)環(huán)境中，絕大多數(shù)超越第3范式的設(shè)計都是不切實際的。因為應(yīng)用程序在3NF級別就能變現(xiàn)的相當(dāng)出色。我們上述的很多例子，將指向箭頭反過來就是反范式化。所以我們要對整體的結(jié)構(gòu)有個比較深的認(rèn)識，才確定我們是否范式化或者反范式化，范式化越深的東西越導(dǎo)致表的增多，也就意味著查詢的join開銷?？偨Y(jié)一下反范式化的一些準(zhǔn)則：分離活動和靜態(tài)的數(shù)據(jù)，數(shù)據(jù)可分為獨立的物理表，即/活動和靜態(tài)表。那些累計的歷史數(shù)據(jù)導(dǎo)致我們占據(jù)了絕大多數(shù)的空間。這是影響性能的最經(jīng)常的數(shù)據(jù)，在數(shù)據(jù)倉庫設(shè)計中，我們經(jīng)常將無效的靜態(tài)的數(shù)據(jù)移植到數(shù)據(jù)倉庫中，由于OLAP和數(shù)據(jù)挖掘。/在表之間