資料庫設計正規化 如何設計乙個資料庫結構

2021-10-07 06:28:35 字數 3012 閱讀 4157

正規化:英文名稱是 normal form,它是英國人 e.f.codd(關聯式資料庫的老祖宗)在上個世紀70年代提出關聯式資料庫模型後總結出來的,正規化是關聯式資料庫理論的基礎,也是我們在設計資料庫結構過程中所要遵循的規則和指導方法。目前有跡可尋的共有8種正規化,依次是:1nf,2nf,3nf,bcnf,4nf,5nf,dknf,6nf。通常所用到的只是前三個正規化,即:第一正規化(1nf),第二正規化(2nf),第三正規化(3nf)。

設計關聯式資料庫時,遵從不同的規範要求,設計出合理的關係型資料庫,這些不同的規範要求被稱為不同的正規化,各種正規化呈遞次規範,越高的正規化資料庫冗餘越小。

目前關聯式資料庫有六種正規化:第一正規化(1nf)、第二正規化(2nf)、第三正規化(3nf)、巴斯-科德正規化(bcnf)、第四正規化(4nf)和第五正規化(5nf,又稱完美正規化)。滿足最低要求的正規化是第一正規化(1nf)。在第一正規化的基礎上進一步滿足更多規範要求的稱為第二正規化(2nf),其餘正規化以次類推。一般說來,資料庫只需滿足第三正規化(3nf)就行了。

首先簡單介紹下前三個正規化,這也是目前設計資料庫時的正規化要求:

強調的是列的原子性,即列不能夠再分成其他幾列。

考慮這樣乙個表:【聯絡人】(姓名,性別,**)

如果在實際場景中,乙個聯絡人有家庭**和公司**,那麼這種表結構設計就沒有達到 1nf。要符合 1nf 我們只需把列(**)拆分,即:【聯絡人】(姓名,性別,家庭**,公司**)。1nf 很好辨別,但是 2nf 和 3nf 就容易搞混淆。

說明:在任何乙個關聯式資料庫中,第一正規化(1nf)是對關係模式的設計基本要求,一般設計中都必須滿足第一正規化(1nf)。不過有些關係模型中突破了1nf的限制,這種稱為非1nf的關係模型。換句話說,是否必須滿足1nf的最低要求,主要依賴於所使用的關係模型。

首先是 1nf,另外包含兩部分內容,一是表必須有乙個主鍵;二是沒有包含在主鍵中的列必須完全依賴於主鍵,而不能只依賴於主鍵的一部分。

考慮乙個訂單明細表:【orderdetail】(orderid,productid,unitprice,discount,quantity,productname)。

因為我們知道在乙個訂單中可以訂購多種產品,所以單單乙個 orderid 是不足以成為主鍵的,主鍵應該是(orderid,productid)。顯而易見 discount(折扣),quantity(數量)完全依賴(取決)於主鍵(oderid,productid),而 unitprice,productname 只依賴於 productid。所以 orderdetail 表不符合 2nf。不符合 2nf 的設計容易產生冗餘資料。

可以把【orderdetail】表拆分為【orderdetail】(orderid,productid,discount,quantity)和【product】(productid,unitprice,productname)來消除原訂單表中unitprice,productname多次重複的情況。

第二正規化(2nf)要求實體的屬性完全依賴於主關鍵字。所謂完全依賴是指不能存在僅依賴主關鍵字一部分的屬性,如果存在,那麼這個屬性和主關鍵字的這一部分應該分離出來形成乙個新的實體,新實體與原實體之間是一對多的關係。為實現區分通常需要為表加上乙個列,以儲存各個例項的唯一標識。簡而言之,第二正規化就是在第一正規化的基礎上屬性完全依賴於主鍵。

在1nf基礎上,任何非主屬性不依賴於其它非主屬性[在2nf基礎上消除傳遞依賴]。

第三正規化(3nf)是第二正規化(2nf)的乙個子集,即滿足第三正規化(3nf)必須滿足第二正規化(2nf)。

首先是 2nf,另外非主鍵列必須直接依賴於主鍵,不能存在傳遞依賴。即不能存在:非主鍵列 a 依賴於非主鍵列 b,非主鍵列 b 依賴於主鍵的情況。考慮乙個訂單表【order】(orderid,orderdate,customerid,customername,customeraddr,customercity)主鍵是(orderid)。

其中 orderdate,customerid,customername,customeraddr,customercity 等非主鍵列都完全依賴於主鍵(orderid),所以符合 2nf。不過問題是 customername,customeraddr,customercity 直接依賴的是 customerid(非主鍵列),而不是直接依賴於主鍵,它是通過傳遞才依賴於主鍵,所以不符合 3nf。

通過拆分【order】為【order】(orderid,orderdate,customerid)和【customer】(customerid,customername,customeraddr,customercity)從而達到 3nf。

第二正規化(2nf)和第三正規化(3nf)的概念很容易混淆,區分它們的關鍵點在於,2nf:非主鍵列是否完全依賴於主鍵,還是依賴於主鍵的一部分;3nf:非主鍵列是直接依賴於主鍵,還是直接依賴於非主鍵列。

另外一些更高要求的正規化:

它構建在第三正規化的基礎上,如果關係模型r是第一正規化,且每個屬性都不傳遞依賴於r的候選鍵,那麼稱r為bcnf的模式。

假設倉庫管理關係表(倉庫號,儲存物品號,管理員號,數量),滿足乙個管理員只在乙個倉庫工作;乙個倉庫可以儲存多種物品,則存在如下關係:

(倉庫號,儲存物品號)——>(管理員號,數量)

(管理員號,儲存物品號)——>(倉庫號,數量)

所以,(倉庫號,儲存物品號)和(管理員號,儲存物品號)都是倉庫管理關係表的候選碼,表中唯一非關鍵字段為數量,它是符合第三正規化的。但是,由於存在如下決定關係:

(倉庫號)——>(管理員號)

(管理員號)——>(倉庫號)

即存在關鍵字段決定關鍵字段的情況,因此其不符合bcnf。把倉庫管理關係表分解為兩個關係表倉庫管理表(倉庫號,管理員號)和倉庫表(倉庫號,儲存物品號,數量),這樣這個資料庫表是符合bcnf的,並消除了刪除異常、插入異常和更新異常。

設r是乙個關係模型,d是r上的多值依賴集合。如果d中存在多值依賴x->y時,x必是r的超鍵,那麼稱r是第四正規化的模式。

例如,職工表(職工編號,職工孩子姓名,職工選修課程),在這個表中,同乙個職工可能會有多個職工孩子姓名,同樣,同乙個職工也可能會有多個職工選修課程,即這裡存在著多值事實,不符合第四正規化。如果要符合第四正規化,只需要將上表分為兩個表,使它們只有乙個多值事實,例如職工表一(職工編號,職工孩子姓名),職工表二(職工編號,職工選修課程),兩個表都只有乙個多值事實,所以符合第四正規化。

資料庫設計五個正規化

1nf 資料庫表中的每一列都是不可分割的基本資料項,同一列中不能有多個值,即實體中的某個屬性不能有多個值或者不能有重複的屬性。2nf 關係模型r滿足inf,消除部分依賴,每乙個非主屬性完全依賴於任何乙個候選碼。舉個例子,選課關係表 學號,課程號,分數,學分 其中 學號,課程號 是關鍵碼,但是存在學分...

資料庫設計正規化

目前關聯式資料庫有六種正規化 第一正規化 1nf 第二正規化 2nf 第三正規化 3nf 第四正規化 4nf 第五正規化 5nf 和第六正規化 6nf 滿足最低要求的正規化是第一正規化 1nf 在第一正規化的基礎上進一步滿足更多要求的稱為第二正規化 2nf 其餘正規化以次類推。一般說來,資料庫只需滿...

資料庫設計正規化

前言 為什麼要寫這篇文章呢,從去年年底開始,就和很多做技術的朋友交流過,從資料庫設計到資料庫架構各個方面的內容。有一些朋友執著於orm,執著於所謂的資料庫設計,卻忘記了一切技術是要為業務服務這個基石。當然這文章裡也有一些自己的理解,想向大家表達。正規化是什麼 正規化是符合某一種級別的關係模式的集合。...