正確的數據庫設計確保了數據完整性

2024-07-21 02:35:46

字體：大中小

來源：轉載

供稿：網友

　　發者在設計階段要考慮許多因素——如何正規化數據、如何創建易于使用的界面等等。但無疑地，開發者最重要的一個目標就是保證數據的準確性。本文討論了如何通過“引用完整性”來防止數據庫產生不正確的數據，以及如何防止丟失數據。
　　
　　誰需要它？
　　
　　
　　
　　解決了正規化、主鍵和關系問題后，一些人可能會忽視引用完整性。假定你負責維護一個重要數據庫，其中存儲著產品和訂單數據。同時，假定你為主鍵使用了自然數據，并在某天更新了一位特定用戶的主鍵值。不久，客戶氣沖沖地打來電話，因為發票出錯，或是因為承諾的時間并沒有發貨。另外，也可能是因為客戶獲得了訂單，但一直沒有拿到發票。錯誤可能要等到系統審計時才會發現——而且即便在審計時，也有可能檢測不到任何錯誤。
　　
　　到底發生了什么？當你更改客戶的主鍵值時，你實際忽略了為那個客戶的相關記錄更新外鍵值。換言之，你創建了“孤兒”——也就是不和主鍵值匹配的外鍵記錄。在這種情況下，系統沒辦法將訂單的細節與客戶對應起來。
　　
　　沒有引用完整性的保障，就可能輸入不匹配的外鍵值。關系模型不答應這些“孤兒”記錄。盡管你的數據庫系統可能答應創建“孤兒”，但開發者必須主動地防止它們。要防止“孤兒”，最簡單的辦法就是實現引用完整性。
　　
　　
　　
　　什么是引用完整性？
　　
　　關系模型強制引用完整性。你必須啟用系統的引用完整性特性來滿足關系規則。雖然在表和表之間啟用引用完整性是一個簡單的操作，但你必須理解這樣做（和不這樣做）的后果。從技術上說，完整性規則負責維護關系（也因此維護著數據）。有3種類型的完整性：
　　
　　Entity（實體）——必須不重復地標識每一條記錄。
　　Referential（引用）——每個外鍵值都必須在相關的表中有一個匹配的主鍵值（或者為Null）。
　　Business（業務）——這些規則是業務特有的，與關系數據庫理論無關。
　　假如禁用引用完整性，你在任何時候都可輸入數據，只要數據不會違反其他表或字段屬性的要求，例如驗證規則和數據類型等。相反，引用完整性會強制規則，限制你在什么時候能修改、添加或刪除數據。啟用引用完整性后，除非在相關的表中存在一個匹配的主鍵值，否則不能輸入一個新的外鍵值。假如相關的表中有一個匹配的外鍵值，就不能更改主鍵值。另外，假如在相關的表中有匹配的外鍵值，就不能刪除一個主鍵值。在這種情況下刪除主鍵記錄會造成“孤兒”。
　　決定何時啟用引用完整性
　　
　　
　　
　　除非你有非常非凡的理由，否則在每個數據庫中都應啟用引用完整性。但在啟用引用完整性之前，必須滿足幾方面的條件：
　　
　　要強制引用完整性的關系必須基于一個主鍵或者一個惟一性的索引。
　　不可在不同數據庫的表之間強制引用完整性。所有表都必須在同一個數據庫內。
　　關系必須基于數據類型相同的字段（有的系統答應在自動編號字段和一個編號字段之間建立關系）。
　　一個例子
　　
　　只有親身體驗，才能完全把握引用完整性。以一個書籍數據庫為基礎，使用你的系統在Books和Publishers表之間啟用引用完整性。圖A展示了Microsoft access中的對話框和Relationships窗口（請查閱文檔，了解如何在自己系統中啟用引用完整性）。
　　
　　圖A
　　　正確的數據庫設計確保了數據完整性（圖一）

　　在Books和Publisher表之間啟用引用完整性
　　
　　在兩個表之間啟用了引用完整性之后，數據輸入將受到更多的限制：
　　
　　不可在Books.PublisherFK中輸入新的外鍵值，除非首先在Publishers.Publisher中將新值作為主鍵值輸入。
　　假如Books.PublisherFK中存在一個匹配的值（外鍵），那么不能在Publishers.Publisher中更改一個值（主鍵）。
　　Books.PublisherFK中存在一個匹配的值（外鍵），那么不能從Publishers.Publisher中刪除一個值（主鍵）。
　　
　　輸入、刪除和更改數據時，假如違反了引用完整性，會發生什么呢？下面以Microsoft Access為例來實際體驗一下。首先打開Books表，然后輸入Nee Nee's TrUCk的記錄，如圖B所示。保存記錄時會產生一個錯誤，因為RabbitPRess在Publishers表中不是一個主鍵值。必須先在Publishers表中為RabbitPress輸入一條記錄，否則引用完整性不認為RabbitPress是一個外鍵值。
　　
　　圖B
　　　正確的數據庫設計確保了數據完整性（圖二）

　　系統拒絕RabbitPress成為一個外鍵
　　接著試驗一下修改主鍵值。請打開Publishers表，選擇Apress記錄（或者Que及Sybex），然后試著刪除記錄。這樣也會出錯，如圖C所示。系統不答應你刪除記錄，因為Books表包含匹配的外鍵值。但可以刪除O'Reilly的記錄，因為Books表中沒有任何記錄將O'Reilly作為外鍵使用。

　　
　　圖C
　　　正確的數據庫設計確保了數據完整性（圖三）

　　不能刪除Apress記錄
　　
　　假如將Apress修改成RabbitPress，會再次出現上述錯誤。記住，只要在相關的表中存在匹配的外鍵值，那么主鍵也是不能修改的。相反，O'Reilly就能修改成RabbitPress。
　　啟用級聯選項
　　
　　強制了引用完整性后，假如必須更改或刪除一個主鍵值，就可能碰到麻煩。為此，你可以在更改時暫時禁用引用完整性，或者啟用一個級聯選項（并非所有系統都支持級聯選項，請查閱文檔以確認）。
　　
　　
　　
　　級聯更新
　　
　　啟用一個級聯更新選項后，就可在存在相匹配的外鍵值的前提下更改一個主鍵值。系統會相應地更新所有匹配的外鍵值。下面來看看Microsoft Access中的一個例子。如圖D所示，打開Books和Publishers表之間的級聯選項（參閱系統文檔了解如何啟用該選項）。
　　圖D
　　　正確的數據庫設計確保了數據完整性（圖四）

　　啟用級聯更新選項
　　接著打開Publishers表，試驗將Apress變成RabbitPress。這一次，系統將接受更改，而不是像圖C那樣報錯。但是，幕后會發生很多事情。打開Books表并檢查PublisherFK值。如圖E所示，系統在接受RabbitPress后，將所有匹配的外鍵值從Apress變成了RabbitPress。這樣一來，更改主鍵值時就不會產生“孤兒”。
　　
　　圖E
　　　正確的數據庫設計確保了數據完整性（圖五）

　　級聯更新選項更改了所有匹配的外鍵值
　　假如系統不答應編輯“自動編號”數據類型，但一個主鍵要基于這樣的一個字段，那么級聯更新是沒有用的。當然，由于不能更改主鍵值，所以也不會產生沖突。
　　級聯刪除
　　
　　在相關的表中存在相匹配的外鍵值時，你可以刪除一個主鍵。啟用級聯刪除選項后，就能成功刪除主鍵值。這時，系統會自動刪除外鍵記錄，以避免產生“孤兒”。
　　
　　在下一個例子中，你必須啟用級聯刪除選項（如圖D所示）。接著，打開Publishers表并試著刪除第一條記錄（Apress）。系統可能顯示如圖F所示的一條警告消息。
　　
　　圖F
　　　正確的數據庫設計確保了數據完整性（圖六）

　　刪除主鍵值時顯示警告消息
　　最后打開Books表，查看從Publishers表刪除Apress后的結果。匹配的外鍵（整條記錄，而非僅僅是外鍵值）都被刪除了，如圖G所示。仔細觀察，你會發現SQL: Access to SQL Server記錄已經消失了。
　　
　　圖G
　　正確的數據庫設計確保了數據完整性（圖七）

　　級聯刪除選項會刪除匹配的外鍵記錄
　　
　　警告！
　　級聯選項（尤其是級聯刪除選項）假如使用不當，可能產生破壞性的后果。為了保護數據，不要永久性地啟用這兩個選項。相反，只有在真正需要時，而且有十足的把握時，才暫時啟用它們。用畢后則將其關閉。
　　
　　結束語
　　
　　關系數據庫理論使許多人頭痛，但只要理解了基本規則（尤其是在有了一些經驗之后），就會發現它們其實很輕易實現。最后，提醒你注重一個好設計的重要性。正確設計的關系數據庫經得起時間和成長的考驗。相反，設計欠佳的數據庫很難使用和修改，甚至可能產生不正確的數據。不要隨心所欲地設計，要一步一步地遵照設計過程進行操作。

上一篇：國人的一些錯誤觀念

下一篇：實現Mandrake開機時自動掛載ISO文件