關于表的規(guī)范化和供應商調查管理制度

規(guī)范化：滿足第一范式是表的最低要求，不滿足第一范式要求的數(shù)據(jù)庫（表）就不能稱之為關系數(shù)據(jù)庫。在此基礎上滿足更高要求的稱為第二范式，簡記為2NF，其余依此類推，還有第三范式（3NF）、BC范式（BCNF）、第四范式（4NF）、第五范式（5NF）。BCNF可以看作是修正了的第三范式。把表從低范式，通過投影運算轉換成若干高一級范式的過程，叫做表的規(guī)范化。一般地說，表滿足的范式級別越高，設計的表越是規(guī)范，表的質量越高，數(shù)據(jù)的冗余度越小，共享性越高，所占的存儲空間越少，并將數(shù)據(jù)的不一致性減少到最低程度，這也是對表進行規(guī)范化的目的。但是，高范式的數(shù)據(jù)庫查詢起來比較復雜。所以，不應一味追求高范式，一般滿足第三范式或BC范式就可以了二、表的規(guī)范化1、第一范式（1NF）如前所述，第一范式要求表的每一個字段都是不可再分的最小單位。例1：學生（學號，姓名，學院，地址，選修課程成績（課程號，課程名，成績））表數(shù)據(jù)如下：學號姓名學院地址選修課程成績（課程號，課程名，成績）9901張麗管理管201C001，高等數(shù)學，909901張麗管理管201C002，英語，809901張麗管理管201C003，計算機，669902李鋒電子電101C004，法律，78表一不滿足第一范式的表顯然，這樣的表是不滿足第一范式的。因為[選修課程成績]字段還可分為3個字段即（課程號，課程名，成績）。如果不把它進行規(guī)范化，即轉換成滿足第一范式的表，將會產生很多問題，如：刪除異常，即本來只想刪除成績的，不得不把課程號和課程名也刪除了！轉換的方法就是把可以拆分的字段進行拆分，即把[選修課程成績]分解成3個字段：[課程號]，[課程名]，[成績]。變成下面滿足第一范式的表：學號姓名學院地址課程號課程名成績9901張麗管理管201C001高等數(shù)學909901張麗管理管201C002英語809901張麗管理管201C003計算機669902李鋒電子電101C004法律78表二

滿足第一范式的表2、第二范式（2NF）一個關系應滿足1NF是最起碼的條件。但是，僅滿足1NF的關系還可能存在一些問題。例2：表二中存在以下的問題：

問題1：數(shù)據(jù)冗余度大。張麗選幾門課程，都必須輸入所有幾個她的相關信息，同時，如果有幾千個人選修高等數(shù)學課，就得輸入幾千個“高等數(shù)學”。如果要修改“高等數(shù)學”這個課程名稱，對于幾千個課程名中，只要漏改一個，將造成數(shù)據(jù)的不一致性。

問題2：刪除異常。我們知道，這個表中的關鍵字為學號和課程號，它們不能為空值，而當李鋒退學時，不可能只刪除李鋒的學號和姓名，只能刪除了李鋒的整條記錄，這時相應的課程號為C004的法律也被刪除，如果這個表中只有李鋒一人選法律課，該記錄刪除后，下次將無法查詢法律課的課程號。

問題3：插入記錄異常。與刪除異常相似，如果李鋒剛入學，還沒有選修任何一門課程，無法知道他選修的課程號，而課程號為關鍵字，不能為空，因此，李鋒這個記錄也不能輸入。造成出現(xiàn)這些問題的原因是因為這個表不滿足第二范式。

如何判斷一個表是否滿足第二范式呢，判斷方法是：（1）、找出表的關鍵字。（2）、如果只有一個關鍵字，若每一個非關鍵字都依賴于這個關鍵字，則表滿足第二范式，否則不是。什么是依賴（關系）呢？例：某表中有兩個字段：學號、姓名，對于每一個學號，只有一個姓名與之對應，則稱姓名依賴于學號，或稱學號唯一確定姓名，記作：學號→姓名。例3：學生（學號，姓名，學院）表是否滿足第二范式？答：滿足。因為，這個表中只有一個關鍵字即學號，而其他字段（即非關鍵字）都依賴于學號，也就是說每一個學號只有一個姓名，一個學院與之對應。例4：學生（學號，姓名，學院，成績）表是否滿足第二范式？答：不滿足。因為，一個學生可能不只選一門課程，不止一個成績，也就是說每一個學號不只有一個成績與之對應，或者說，有一個非關鍵字段（即成績）不依賴于學號。（3）、如果有兩個或兩個以上的關鍵字，那么，把這些關鍵字看成是一個組合關鍵字，若每一個非關鍵字都能完全依賴于組合關鍵字，則表滿足第二范式，否則不是。例5：成績（學號，課程，成績）表是否滿足第二范式？滿足。因為，非關鍵字（成績）完全依賴于組合關鍵字（學號+課程），即只有一個成績與（學號+課程）對應，或者說，一個學生選修一門課程，就只能有一個成績。稱為部分依賴。

定義：如果一個表滿足1NF，且每一個非關鍵字都完全依賴于關鍵字，則這個表滿足第二范式。

第一范式轉換成第二范式的方法：找出依賴關系，將能完全依賴于主鍵的字段從表中提取出來，同主鍵一起組成一個新的關系。

例7：表二(學號，姓名，學院，地址，課程號，課程名，成績）的依賴關系如下：顯然，不滿足2NF。院、地址）績）轉換的過程就是拆分的過程，也是一個消除部分依賴的過程。但是，要注意，拆分的結果應該包含原表的所有字段?。。礋o損分解）3、第三范式（3NF）通過分析，發(fā)現(xiàn)表A仍然在一定程度上存在上面提及的三個問題，要消除和減少它們，還得把它分解成滿足更高范式（即3NF）的表.

滿足第三范式的判斷方法：判斷表在滿足第二范式的基礎上是否有傳遞依賴的情況，如果有，不是第三范式，否則是。

將非第三范式規(guī)范為第三范式的方法：把產生傳遞依賴關系的非關鍵字段抽出來，同關鍵字一起建立新的表。例8：表A(學號，姓名，學院，地址)中，存在地址傳遞依賴于學號的關系，即：學號→學院，學院→地址。把地址從原表中分出來，同關鍵字一起建立新的表形成表A1（學院、地址）,原表就可消除了傳遞依賴關系。表A分解為：表A1（學院、地址）

表A2（學號、姓名、學院）

小結：表的規(guī)范化中，1NF是要滿足每個字段都是不可再分的；2NF是在1NF的基礎上消除部分依賴關系（只保留完全依賴），3NF是在2NF的基礎上進一步消除傳遞依賴關系。二：在設計和操作維護數(shù)據(jù)庫時，關鍵的步驟就是要確保數(shù)據(jù)正確地分布到數(shù)據(jù)庫的表中。使用正確的數(shù)據(jù)結構，不僅便于對數(shù)據(jù)庫進行相應的存取操作，而且可以極大地簡化應用程序的其他內容（查詢、窗體、報表、代碼等）。正確進行表設計的正式名稱就是"數(shù)據(jù)庫規(guī)范化"。數(shù)據(jù)冗余數(shù)據(jù)應該盡可能少地冗余，這意味著重復數(shù)據(jù)應該減少到最少。比如說，一個部門雇員的電話不應該被存儲在不同的表中，因為這里的電話號碼是雇員的一個屬性。如果存在過多的冗余數(shù)據(jù)，這就意味著要占用了更多的物理空間，同時也對數(shù)據(jù)的維護和一致性檢查帶來了問題，當這個員工的電話號碼變化時，冗余數(shù)據(jù)會導致對多個表的更新動作，如果有一個表不幸被忽略了，那么就可能導致數(shù)據(jù)的不一致性。規(guī)范化實例為了說明方便，我們在本文中將使用一個SAMPLE數(shù)據(jù)表，來一步一步分析規(guī)范化的過程。首先，我們先來生成一個的最初始的表。CREATETABLE"SAMPLE"( "PRJNUM"INTEGERNOTNULL, "PRJNAME"VARCHAR(200), "EMYNUM"INTEGERNOTNULL, "EMYNAME"VARCHAR(200), "SALCATEGORY"CHAR(1), "SALPACKAGE"INTEGER) IN"USERSPACE1";ALTERTABLE"SAMPLE" ADDPRIMARYKEY ("PRJNUM","EMYNUM");InsertintoSAMPLE(PRJNUM,PRJNAME,EMYNUM,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,'Johnson','A',2000),(100002,'TCT',200004,'Apple','B',3000);表1-1

考察表1-1，我們可以看到，這張表一共有六個字段，分析每個字段都有重復的值出現(xiàn)，也就是說，存在數(shù)據(jù)冗余問題。這將潛在地造成數(shù)據(jù)操作（比如刪除、更新等操作）時的異常情況，因此，需要進行規(guī)范化。第一范式參照范式的定義，考察上表，我們發(fā)現(xiàn)，這張表已經滿足了第一范式的要求。（1NF:字段具有原子性，不可再分；比如說籍貫這個字段，里面是“湖北武漢”的話，它就違反了原子性，因為湖北武漢還可以再分的更具體，分為“湖北”和“武漢”）1、因為這張表中字段都是單一屬性的，不可再分；2、而且每一行的記錄都是沒有重復的；3、存在主屬性，而且所有的屬性都是依賴于主屬性；4、所有的主屬性都已經定義事實上在當前所有的關系數(shù)據(jù)庫管理系統(tǒng)（DBMS）中，都已經在建表的時候強制滿足第一范式。因此，這張SAMPLE表已經是一張滿足第一范式要求的表。考察表1-1，我們首先要找出主鍵。可以看到，屬性對<ProjectNumber,EmployeeNumber>是主鍵，其他所有的屬性都依賴于該主鍵。從一范式轉化到二范式根據(jù)第二范式的定義，轉化為二范式就是消除部分依賴。（2NF:組合關鍵字的表，不存在組合關鍵字中的任意字段決定其它非關鍵字段（也就是說不能有兩個組合鍵組成一個主鍵））考察表1-1，我們可以發(fā)現(xiàn)，非主屬性<ProjectName>部分依賴于主鍵中的<ProjectNumber>;非主屬性<EmployeeName>，<SalaryCategory>和<Salarypackage>都部分依賴于主鍵中的<EmployeeNumber>；表1-1的形式，存在著以下潛在問題：1．數(shù)據(jù)冗余：每一個字段都有值重復；2．更新異常：比如<ProjectName>字段的值，比如對值"TPMS"了修改，那么就要一次更新該字段的多個值；3．插入異常：如果新建了一個Project，名字為TPT,但是還沒有Employee加入，那么<EmployeeNumber>將會空缺，而該字段是主鍵的一部分，因此將無法插入記錄；InsertintoSAMPLE(PRJNUM,PRJNAME,EMYNUM,EMYNAME,SALCATEGORY,SALPACKAGE)values(100003,'TPT',NULL,NULL,NULL,NULL)

4．刪除異常：如果一個員工200003,Kevin離職了，要將該員工的記錄從表中刪除，而此時相關的Salary信息C也將丟失,因為再沒有別的行紀錄下SalaryC的信息。DeletefromsamplewhereEMYNUM=200003

SelectdistinctSALCATEGORY,SALPACKAGEfromSAMPLE因此，我們需要將存在部分依賴關系的主屬性和非主屬性從滿足第一范式的表中分離出來，形成一張新的表，而新表和舊表之間是一對多的關系。由此，我們得到：CREATETABLE"PROJECT"( "PRJNUM"INTEGERNOTNULL, "PRJNAME"VARCHAR(200)) IN"USERSPACE1";ALTERTABLE"PROJECT" ADDPRIMARYKEY ("PRJNUM");InsertintoPROJECT(PRJNUM,PRJNAME)values(100001,'TPMS'),(100002,'TCT');

表1-2

表1-3EMYNUMEMYNAMESALCATEGORYSALPACKAGE200001JohnsonA2000200003KevinC4000200004AppleB3000 CREATETABLE"EMPLOYEE"( "EMYNUM"INTEGERNOTNULL, "EMYNAME"VARCHAR(200),"SALCATEGORY"CHAR(1),"SALPACKAGE"INTEGER) IN"USERSPACE1";ALTERTABLEEMPLOYEE ADDPRIMARYKEY (EMYNUM);InsertintoEMPLOYEE(EMYNUM,EMYNAME,SALCATEGORY,SALPACKAGE)values(200001,'Johnson','A',2000),(200002,'Christine','B',3000),(200003,'Kevin','C',4000),(200004,'Apple','B',3000);CREATETABLE"PRJ_EMY"( "PRJNUM"INTEGERNOTNULL, "EMYNUM"INTEGERNOTNULL) IN"USERSPACE1";ALTERTABLE"PRJ_EMY" ADDPRIMARYKEY ("PRJNUM","EMYNUM");InsertintoPRJ_EMY(PRJNUM,EMYNUM)values(100001,200001),(100001,200002),(100001,200003),(100002,200001),(100002,200004);同時，我們把表1-1的主鍵，也就是表1-2和表1-3的各自的主鍵提取出來，單獨形成一張表，來表明表1-2和表1-3之間的關聯(lián)關系：

表1-4

這時候我們仔細觀察一下表1-2,1-3,1-4,我們發(fā)現(xiàn)插入異常已經不存在了，當我們引入一個新的項目TPT的時候，我們只需要向表1-2中插入一條數(shù)據(jù)就可以了，當有新人加入項目TPT的時候，我們需要向表1-3,1-4中各插入一條數(shù)據(jù)就可以了。雖然我們解決了一個大問題，但是仔細觀察我們還是發(fā)現(xiàn)有問題存在。從二范式轉化到三范式考察表前面生成的三張表，我們發(fā)現(xiàn)，表1-3存在傳遞依賴關系，即：關鍵字段<EmployeeNumber>-->非關鍵字段<SalaryCategory>-->非關鍵字段<SalaryPackage>。而這是不滿足三范式的規(guī)則的，存在以下的不足：1、數(shù)據(jù)冗余：<SalaryCategory>和<SalaryPackage>的值有重復；2、更新異常：有重復的冗余信息，修改時需要同時修改多條記錄，否則會出現(xiàn)數(shù)據(jù)不一致的情況；3、刪除異常：同樣的，如果員工200003Kevin離開了公司，會直接導致SalaryC的信息的丟失。DeletefromEMPLOYEEwhereEMYNUM=200003

SelectdistinctSALCATEGORY,SALPACKAGEfromEMPLOYEE因此，我們需要繼續(xù)進行規(guī)范化的過程，把表1-3拆開，我們得到：

表1-5

和

表1-6

這時候如果200003Kevin離開公司，我們只需要從表1-5中刪除他就可以了，存在于表1-6中的SalaryC信息并不會丟失。但是我們要注意到除了表1-5中存在Kevin的信息之外，表1-4中也存在Kevin的信息，這很容易理解，因為Kevin參與了項目100001，TPMS，所以當然也要從中刪除。至此，我們將表1-1經過規(guī)范化步驟，得到四張表，滿足了三范式的約束要求，數(shù)據(jù)冗余、更新異常、插入異常和刪除異常。在三范式之上，還存在著更為嚴格約束的BC范式和四范式，但是這兩種形式在商業(yè)應用中很少用到，在絕大多數(shù)情況下，三范式已經滿足了數(shù)據(jù)庫表規(guī)范化的要求，有效地解決了數(shù)據(jù)冗余和維護操作的異常問題。（3NF:在2NF的基礎上，數(shù)據(jù)表中如果不存在非關鍵字段對任一候選字段的傳遞函數(shù)依賴則符合第三范式（也就是說違反了數(shù)據(jù)冗余）帳號身份證號姓名密碼1001410101001李梅100001身份證號和姓名共同決定了密碼，姓名是依賴于身份證號的，這樣就違反了第三范式）.第四范式(4NF)

(1)第四范式(4NF)的定義在4.3.5中我們曾分析了關系CTB雖然屬于BCNF，但還存在著數(shù)據(jù)冗余、插入異常和刪除異常的弊端，究其原因就是CTB中存在非平凡的的多值依賴，而決定因素不是關鍵字。因而必須將CTB繼續(xù)分解，如果分解成兩個關系模式CTB1(C，T)和CTB2(C，B)，則它們的冗余度會明顯下降。從多值依賴的定義分析CTB1和CTB2，它們的屬性間各有一個多值依賴C→→T，C→→B，都是平凡的多值依賴。因此，含有多值依賴的關系模式中，減少數(shù)據(jù)冗余和操作異常的常用方法是將關系模式分解為僅有平凡的多值依賴的關系模式。定義4.9設有一關系模式R(U)，U是其屬性全集，X、Y是U的子集，D是R上的數(shù)據(jù)依賴集。如果對于任一多值依賴X→→Y，此多值依賴是平凡的，或者X包含了R的一個候選關鍵字，則稱R是第四范式的關系模式，記為R∈4NF。由此定義可知：關系模式CTB分解后產生的CTB1(C，T)和CTB2(C，B)中，因為C→→T，C→→B均是平凡的多值依賴，所以CTB1和CTB2都是4NF。經過上面的分析可以得知：一個BCNF的關系模式不一定是4NF，而4NF的關系模式必定是BCNF的關系模式，即4NF是BCNF的推廣。(2)4NF的分解把一個關系模式分解為4NF的方法與分解為BCNF的方法類似，就是把一個關系模式利用投影的方法消去非平凡且非函數(shù)依賴的多什依賴，并具有無損連接性。[例7]設有關系模式R（A，B，C，E，F(xiàn)，G），數(shù)據(jù)依賴集D＝｛A→→BGC，B→AC，C→G｝，將分解為4NF。解：利用A→→BGC，可將R分解為的R的＝｛ABCG，AEF｝。利用B→AC分解得：R＝｛ABC，BG，AEF｝。由此得到的三個關系模式（ABC）、（BG）和（AEF）都屬于4NF，但此分解丟失了函數(shù)依賴C→G。若最后一次分解利用函數(shù)依賴C→G來做，則R＝｛ABC，CG，AEF｝，由此得到的三個關系模式（ABC），（CG）和（AEF）都是屬于4NF的關系模式，且保持了所有的數(shù)據(jù)依賴。這說明，4NF的分解結果不是惟一的，結果與選擇數(shù)據(jù)依賴的次序有關。任何一個關系模式都可無損分解成一組等價的4NF關系模式，但這種分解不一定具有依賴保持性。數(shù)據(jù)依賴和多值依賴是兩種最重要的數(shù)據(jù)依賴。如果只考慮函數(shù)依賴，則屬于BCNF的關系模式的規(guī)范化程度已經是最高的了。如果考慮多什依賴，則屬于4NF的關系模式化程度是最高的。事實上，數(shù)據(jù)依賴中除函數(shù)依賴和多什依賴之外，還有其他數(shù)據(jù)依賴。函數(shù)依賴是多值依賴的一種特殊情況，而多值依賴實際上又是連接依賴的一種特殊情況。但連接依賴不像函數(shù)依賴和多值依賴那樣可由語義直接導出，而是在關系的連接運算時才反映出來。存在連接依賴的關系模式仍可能遇到數(shù)據(jù)冗余及插入、修改、刪除異常的問題。如果消除了屬于4NF的關系模式中存在的連接依賴，則可以進一步達到5NF的關系模式

供應商調查管理制度總則1．1制定目的為了解供應商之制程能力、品管功能，確認其是否有提供符合成本、交期、品質之物料的能力，特制定本規(guī)章。1．2適用范圍對擬開發(fā)供應商之調查，及本公司合格供應商之年度復查，除另有規(guī)定外，悉依本規(guī)章辦理。1．3權責單位采購部負責本規(guī)章制定、修改、廢止之起草工作?？偨浝碡撠煴疽?guī)章制定