3.1.1　關系數據庫設計缺陷

如何建立一個好的關系數據庫模型呢？在解決如何建立一個好的關系數據庫模型之前，我們先通過一個例子來看看某些不恰當的關系模型可能導致的問題。

設有一個“員工信息表”關系如下：

員工信息表[員工姓名，性別，政治面貌，籍貫……社會關系（與本人關系，姓名，工作單位），本人學習簡歷（起始至終止年月，所在單位，證明人）]

表3.1是上述“員工”關系的一個實例（只給出部分數據）。

表3.1“員工”關系的一個實例

從表3.1中可以看出：“社會關系”和“本人學習簡歷”兩個數據元素又各自分別包含3個數據元素。這樣使得同一員工的姓名、性別、政治面貌和籍貫等數據元素的值在關系中的多個記錄中重復存儲，產生了大量的數據冗余。同時，數據的重復存儲會給更新帶來麻煩。例如，如果某個員工的政治面貌發生改變，則關系中所有有關該員工的記錄都要更改，如有一個不改就會導致數據的不一致。除此之外，設計不好的關系還會帶來其他一些異常情況（如插入、刪除異常等）。

如有另外一個關系“員工-項目”如下：

員工-項目（工號，姓名，職務，職稱，項目編號，參與項目名稱，項目負責人，承擔任務，客戶評價）

在這個關系中，只有根據員工的工號和參與的項目編號才能確定某員工在某個項目中承擔的任務。這樣，如果新承接了一個項目，而尚未確定參與的員工，則主關鍵字屬性“工號”取值為空，但關鍵字是不允許出現空值的。如此，該項目諸如項目負責人之類的信息就無法存入數據庫，同時暫時未參與任何項目的員工信息也無法存入數據庫，即存在插入異常。

另外，一個項目完成后，刪除該項目記錄，則參與該項目的員工相關信息也被刪掉了，即存在刪除異常。

這些異常的產生主要是因為關系模式的結構，即關系中的屬性之間存在過多的數據依賴關系。也就是說，關系中除了所有屬性對主關鍵字屬性的數據依賴以外，還存在著別的依賴關系。

在現實世界中，任何一個實體或實體的屬性之間都存在一定的聯系。如“員工信息表”中假設沒有重名現象，則員工姓名“張楠”決定了他的性別、政治面貌等屬性值；員工姓名“張楠”和與本人關系“父親”值決定了張楠父親的姓名、工作單位；員工姓名“張楠”和“1988/09—1992/07”值決定了張楠的所在單位及證明人。這些數據元素之間的依賴關系表示如下：

員工姓名→性別；員工姓名→政治面貌；員工姓名→政治面貌；員工姓名+與本人關系→姓名；員工姓名+與本人關系→工作單位；員工姓名+起始至終止年月→所在單位；員工姓名+起始至終止年月→證明人

將表3-1中的關系模式分解成3個新的關系模式：

（1）員工（姓名，性別，政治面貌，籍貫）；

（2）員工社會關系（員工姓名，與本人關系，工作單位）；

（3）員工學習簡歷（員工姓名，起始至終止年月，所在單位，證明人）。

可見，新的關系模式使上述的存儲異常等問題都不存在了。這樣的分解將更加符合現實世界的客觀情況。所以，為了避免出現數據冗余、更新異常、插入異常和刪除異常等情況，就要對關系模型進行合理分解，即進行關系模型的規范化。

結合以上內容，規范化的目的可以概括為以下四點：

（1）把關系中的每一個數據項都轉換成一個不能再分的基本項；

（2）消除冗余，并使關系的檢索簡化；

（3）消除數據在進行插入、修改和刪除時的異常情況；

（4）關系模型靈活，易于使用非過程化的高級查詢語言進行查詢。