規范化過程主要為克服數據庫邏輯結構中的什么？

規范化過程主要為克服數據庫邏輯結構中的插入異常、刪除異常以及冗余度大的缺陷。數據庫規范化能夠讓數據庫設計者更好地了解組織內部當前的數據結構，最終得到一系列的數據實體。數據庫規范化通過對數據庫表的設計，可以有效降低數據庫冗余程度。

松陽網站建設公司創新互聯,松陽網站設計制作，有大型網站制作公司豐富經驗。已為松陽上千多家提供企業網站建設服務。企業網站搭建\外貿網站制作要多少錢，請找那個售后服務好的松陽做網站的公司定做！

數據庫規范化過程

關系數據庫的規范化說的通俗一些就是對表的規范化。

規范化的必要性：

根據項目的需求，我們會創建相應的數據庫表格來完成項目中的數據的存儲。這已經成為做項目的固定流程了，但是在真正的開始處理業務需求的時候，就會意識到自己的表格設置的不合理，導致數據的重復存儲，插入異常，刪除異常，更新異常等問題，這時就需要來重新的規劃表格，既浪費時間，又消耗人力財力，十分不劃算，因此規范化是十分有必要的，所以今天就在這里教給大家規范表的方法。

在教規范化數據庫方法之前，先給大家介紹知識:

關鍵知識點函數依賴

函數依賴的定義：

設R(U)是屬性集上的一個子集，X和Y是U的子集，若對于R(U)上的任意一個可能的關系r,如果r中不可能存在兩個元組，它們在X上的屬性值相等，而在Y上的屬性值不相等，則稱X函數決定于Y或Y函數依賴與X,記作X->Y。

定義可能有些難以理解，我在這里簡單的解釋一下：函數依賴描述的是兩個集合之間的一種映射關系，這種映射關系與函數是一樣的，例如 y = x^2，在這里對于x來說，一個x就對應一個y值，但是不存在，一個x對應多種y值的情況，所以就可以說y函數依賴于x,然而對于y來說，存在一個y值對應多個x值的情況，所以說x并不函數依賴于y。這就是函數依賴。

接下來我們介紹幾種特殊的函數依賴：

完全函數依賴

定義：

如果X->Y，并且對于任意一個X的真子集X’都不存在,X’->Y，那么我們就說 X->Y這種函數依賴屬于完全函數依賴。

簡單的解釋一下： 函數z = x + y，對于z來說：z函數依賴于x和y，但是z并不單獨依賴于x或單獨依賴于y，這就說明z函數依賴于x和y的這種依賴就是完全函數依賴。

部分函數依賴：

定義：

如果X->Y，但是Y不完全依賴于X，則稱這種依賴為部分完全依賴。 也就是說：函數z = x + 0y 是可以看成 ,也就是說z函數依賴于x和y，但是z又單獨依賴于x，那么這就是部分函數依賴。

傳遞函數依賴：

定義：

如果X->Y, Y -> Z ,并且不成立，Y->X也不成立。則稱Z傳遞函數依賴于X。

這個比較簡單，函數組z = x^2, x = 2y可以化簡為z = 4y ^2，很容易看出：z是函數依賴于x，x依賴于y，并且z->x不成立，這就是傳遞函數依賴。

關鍵知識點之二-----鍵

候選鍵：一個屬性（字段）或一個屬性組（多個字段）能夠完全決定于關系模式（表）中的其他屬性（字段）。也就是說其他屬性（字段）完全依賴于該屬性（字段）或屬性組（多個字段）。

主鍵：如果候選鍵多于一個，則選擇其中一個作為主鍵。被選做主鍵的屬性或屬性組在該關系模式（表）中的每一個元祖（行）中的值是不允許重復和取值為null的。

主屬性：報完在任何一個候選鍵中的屬性，稱為主屬性。如果候選鍵是由多個屬性共同組成的，那么這些屬性組中每一個屬性都是主屬性。

非主屬性：不包含在任何鍵中的屬性稱為非主屬性。

外鍵：某屬性或屬性組在當前關系模式（表）中不是主鍵，但是另一個關系模式（表）中充當主鍵的身份，則稱該屬性或屬性組為外鍵。

在介紹完了上述的基本知識點之后，我們來開始學習數據庫表的規范過程：

想要規范表，就首先需要一個標準，來衡量表是否已經規范。這個標準就是----范式。

范式一共有六種：第一范式（1NF），第二范式(2NF)，第三范式(3NF)，BC范式(BCNF)，第四范式(4NF)，第五范式(5NF)。

在上面六中范式中，在一般的情況下我們需要將表規范到BCNF就已經十分完美了，在真正的項目中其實只需要達到3NF就足夠了。

接下來重點介紹前4中范式：

第一范式：關系模式R中的所有屬性都是不可分的數據項。

簡單來說就是只要你能把表建出來，這個表就已經滿足了第一范式了。例如student表（student_id, course_id, student_name, age, sex, grade, sdept, sdept_director），在這個表中很明顯grade這一項是受student_id, course_id,共同決定的，所以應該讓這兩項聯合做為主鍵。

第二范式：在滿足第一范式的基礎上，滿足非主屬性都完全依賴于R的主鍵。

這就需要用到前面講的內容了，要判斷非主屬性是否完全依賴于主鍵。如果不滿足就重 更改表的結構。例如student表（student_id, course_id, student_name, age, sex, grade, sdept_id, sdept_director)因為student_id, course_id兩項聯合做為主鍵，但是對于其他的字段name, age, sex這些 屬性來說，它們是完全依 賴于student_id這一屬性的，所以它們對于student_id, course_id共同作為主鍵是部分 依賴的。這就不滿足第二范式的定義了，所以應該把 grade拿出來，將這一個大表拆成 兩份小表:student(student_id, name, age, sex, sdept_id, sdept_director)， student_score(student_id, course_id, grade);

第三范式：在滿足第二范式的情況下去除傳遞依賴。

例如：student表（student_id, student_name, age, sex, sdept, sdept_director）,很明顯每一個專業決定一個專業主任,所以sdept_director傳遞依賴于student_id，所以應該再拆分一個表student（student_id, student_name, age, sex）和sdept(sdept_id, sdept_name, sdept_director),這樣就滿足了第三范式。

BC范式：在滿足第三范式的情況下，再滿足一下三點：

1、所有的主屬性完全依賴于其他不包含自己的候選鍵；
2、所有的非主屬性完全依賴于每一個候選鍵；
3、沒有任何屬性完全函數依賴于任何一組非主屬性。

之前的三個范式都是對非主屬性進行各種約束，BC范式是在他們基礎上，再對主屬性進行約束，解決了主屬性之間的部分依賴的問題，以及不存在主屬性完全依賴于非主屬性的問題。 我們的student表 student（student_id, student_name, age, sex），主鍵是student_id,所以主屬性是student_id,很顯然前兩條都已經滿足，因為學生的姓名可能重復，所以student_id與student_name之間沒有函數依賴關系，所以student表滿足BC范式。