1、規范化數據庫設計原則關系數據庫設計的核心問題是關系模型的設計。本文將結合具體的實例，介紹數據庫設計規范化的流程。摘要關系型數據庫是當前廣泛應用的數據庫類型，關系數據庫設計是對數據進行組織化和結構化的過程，核心問題是關系模型的設計。對于數據庫規模較小的情況，我們可以比較輕松的處理數據庫中的表結構。然而，隨著項目規模的不斷增長，相應的數據庫也變得更加復雜，關系模型表結構更為龐雜，這時我們往往會發現我們寫出來的SQL語句的是很笨拙并且效率低下的。更糟糕的是，由于表結構定義的不合理，會導致在更新數據時造成數據的不完整。因此，就有必要學習和掌握數據庫的規范化流程，以指導我們更好的設計數據庫的表結構，減少

2、冗余的數據，借此可以提高數據庫的存儲效率，數據完整性和可擴展性。本文將結合具體的實例，介紹數據庫規范化的流程。序言本文的目的就是通過詳細的實例來闡述規范化的數據庫設計原則。在DB2中，簡潔、結構明晰的表結構對數據庫的設計是相當重要的。規范化的表結構設計，在以后的數據維護中，不會發生插入（insert）、刪除（delete）和更新（update）時的異常。反之，數據庫表結構設計不合理，不僅會給數據庫的使用和維護帶來各種各樣的問題，而且可能存儲了大量不需要的冗余信息，浪費系統資源。要設計規范化的數據庫，就要求我們根據數據庫設計范式也就是數據庫設計的規范原則來做。但是一些相關材料上提到的范式設計，往

3、往是給出一大堆的公式，這給設計者的理解和運用造成了一定的困難。因此，本文將結合具體形象的例子，盡可能通俗化地描述三個范式，以及如何在實際工程中加以優化應用。規范化在設計和操作維護數據庫時，關鍵的步驟就是要確保數據正確地分布到數據庫的表中。使用正確的數據結構，不僅便于對數據庫進行相應的存取操作，而且可以極大地簡化應用程序的其他內容（查詢、窗體、報表、代碼等）。正確進行表設計的正式名稱就是"數據庫規范化"。后面我們將通過實例來說明具體的規范化的工程。關于什么是范式的定義，請參考附錄文章 1.數據冗余數據應該盡可能少地冗余，這意味著重復數據應該減少到最少。比如說，一個部門雇員的電

4、話不應該被存儲在不同的表中， 因為這里的電話號碼是雇員的一個屬性。如果存在過多的冗余數據，這就意味著要占用了更多的物理空間，同時也對數據的維護和一致性檢查帶來了問題，當這個員工的電話號碼變化時，冗余數據會導致對多個表的更新動作，如果有一個表不幸被忽略了，那么就可能導致數據的不一致性。規范化實例為了說明方便，我們在本文中將使用一個SAMPLE數據表，來一步一步分析規范化的過程。首先，我們先來生成一個的最初始的表。CREATE TABLE "SAMPLE" ( "PRJNUM" INTEGER NOT NULL, "PRJNAME" VA

5、RCHAR(200), "EMYNUM" INTEGER NOT NULL, "EMYNAME" VARCHAR(200), "SALCATEGORY" CHAR(1), "SALPACKAGE" INTEGER) IN "USERSPACE1"ALTER TABLE "SAMPLE" ADD PRIMARY KEY("PRJNUM", "EMYNUM");Insert into SAMPLE(PRJNUM, PRJNAME, EMYN

6、UM, EMYNAME, SALCATEGORY, SALPACKAGE)values(100001, 'TPMS', 200001, 'Johnson', 'A', 2000), (100001, 'TPMS', 200002,'Christine', 'B', 3000), (100001, 'TPMS', 200003, 'Kevin', 'C', 4000), (100002,'TCT', 200001, 'Johnso

7、n', 'A', 2000), (100002, 'TCT', 200004, 'Apple', 'B',3000);表1-1考察表1-1，我們可以看到，這張表一共有六個字段，分析每個字段都有重復的值出現，也就是說，存在數據冗余問題。這將潛在地造成數據操作（比如刪除、更新等操作）時的異常情況，因此，需要進行規范化。第一范式參照范式的定義，考察上表，我們發現，這張表已經滿足了第一范式的要求。1、因為這張表中字段都是單一屬性的，不可再分；2、而且每一行的記錄都是沒有重復的；3、存在主屬性，而且所有的屬性都是依賴于主屬性；4、所

8、有的主屬性都已經定義事實上在當前所有的關系數據庫管理系統（DBMS）中，都已經在建表的時候強制滿足第一范式。因此，這張SAMPLE表已經是一張滿足第一范式要求的表。考察表1-1，我們首先要找出主鍵。可以看到，屬性對<Project Number, Employee Number>是主鍵，其他所有的屬性都依賴于該主鍵。從一范式轉化到二范式根據第二范式的定義，轉化為二范式就是消除部分依賴。考察表1-1，我們可以發現，非主屬性<Project Name>部分依賴于主鍵中的<Project Number> 非主屬性<Employee Name>，<

9、Salary Category>和<Salary package>都部分依賴于主鍵中的<Employee Number>；表1-1的形式，存在著以下潛在問題：1 數據冗余：每一個字段都有值重復；2 更新異常：比如<Project Name>字段的值，比如對值"TPMS"了修改，那么就要一次更新該字段的多個值；3 插入異常：如果新建了一個Project，名字為TPT, 但是還沒有Employee加入，那么<Employee Number>將會空缺，而該字段是主鍵的一部分，因此將無法插入記錄；Insert into SAMP

10、LE(PRJNUM, PRJNAME, EMYNUM, EMYNAME, SALCATEGORY, SALPACKAGE) values(100003, 'TPT', NULL, NULL, NULL, NULL)4 刪除異常：如果一個員工 200003, Kevin 離職了，要將該員工的記錄從表中刪除，而此時相關的Salary信息 C 也將丟失, 因為再沒有別的行紀錄下 Salary C的信息。Delete from sample where EMYNUM = 200003Select distinct SALCATEGORY, SALPACKAGE from SAMPLE因

11、此，我們需要將存在部分依賴關系的主屬性和非主屬性從滿足第一范式的表中分離出來，形成一張新的表，而新表和舊表之間是一對多的關系。由此，我們得到：CREATE TABLE "PROJECT" ( "PRJNUM" INTEGER NOT NULL, "PRJNAME" VARCHAR(200) IN "USERSPACE1"ALTER TABLE "PROJECT" ADD PRIMARY KEY("PRJNUM");Insert into PROJECT(PRJNUM, PRJ

12、NAME) values(100001, 'TPMS'), (100002, 'TCT');表1-2表 1-3CREATE TABLE "EMPLOYEE" ( "EMYNUM" INTEGER NOT NULL, "EMYNAME" VARCHAR(200), "SALCATEGORY" CHAR(1), "SALPACKAGE" INTEGER) IN "USERSPACE1"ALTER TABLE "EMPLOYEE"

13、 ADD PRIMARY KEY("EMYNUM");Insert into EMPLOYEE(EMYNUM, EMYNAME, SALCATEGORY, SALPACKAGE) values(200001,'Johnson', 'A', 2000), (200002, 'Christine', 'B', 3000), (200003, 'Kevin', 'C',4000), (200004, 'Apple', 'B', 3000);Employe

14、e NumberEmployee NameSalary CategorySalary Package200001JohnsonA2000200002ChristineB3000200003KevinC4000200004AppleB3000CREATE TABLE "PRJ_EMY" ( "PRJNUM" INTEGER NOT NULL, "EMYNUM" INTEGER NOT NULL) IN "USERSPACE1"ALTER TABLE "PRJ_EMY" ADD PRIMARY KE

15、Y("PRJNUM", "EMYNUM");Insert into PRJ_EMY(PRJNUM, EMYNUM) values(100001, 200001), (100001, 200002),(100001, 200003), (100002, 200001), (100002, 200004);同時，我們把表1-1的主鍵，也就是表1-2和表1-3的各自的主鍵提取出來，單獨形成一張表，來表明表1-2和表1-3之間的關聯關系：表 1-4這時候我們仔細觀察一下表1-2, 1-3, 1-4, 我們發現插入異常已經不存在了，當我們引入一個新的項目 TPT

16、的時候，我們只需要向表1-2 中插入一條數據就可以了， 當有新人加入項目 TPT 的時候，我們需要向表1-3, 1-4 中各插入一條數據就可以了。雖然我們解決了一個大問題，但是仔細觀察我們還是發現有問題存在。從二范式轉化到三范式考察表前面生成的三張表，我們發現，表1-3存在傳遞依賴關系，即：關鍵字段< Employee Number > -> 非關鍵字段< Salary Category > ->非關鍵字段< Salary Package >。而這是不滿足三范式的規則的，存在以下的不足：1、 數據冗余：<Salary Category>

17、;和<Salary Package>的值有重復；2、 更新異常：有重復的冗余信息，修改時需要同時修改多條記錄，否則會出現數據不一致的情況；3、 刪除異常：同樣的，如果員工 200003 Kevin 離開了公司，會直接導致 Salary C 的信息的丟失。Delete from EMPLOYEE where EMYNUM = 200003Select distinct SALCATEGORY, SALPACKAGE from EMPLOYEE因此，我們需要繼續進行規范化的過程，把表1-3拆開，我們得到：表 1-5和表 1-6這時候如果 200003 Kevin 離開公司，我們只需要從表 1-5 中刪除他就可以了， 存在于表1-6中的Salary C信息并不會丟失。但是我們要注意到除了表 1-5 中存在 Kevin 的信息之外， 表1-4中也存在 Kevin 的信息， 這很容易理解， 因為 Kevin 參與了項目 100001， TPMS，