基本介紹
- 中文名：資料庫完整性
- 外文名：Database integrity
- 分類：資料庫概念
- 所屬學科：計算機
原理,關係模型,實體,域完整性,參照完整性,用戶定義完整性,設計階段,需求分析,概念設計,邏輯設計,設計原則,
原理
資料庫完整性對於資料庫套用系統非常關鍵，其作用主要體現在以下幾個方面：
1．資料庫完整性約束能夠防止合法用戶使用資料庫時向資料庫中添加不合語義的數據。
2．利用基於DBMS的完整性控制機制來實現業務規則，易於定義，容易理解，而且可以降低應用程式的複雜性，提高應用程式的運行效率。同時，基於DBMS的完整性控制機制是集中管理的，因此比應用程式更容易實現資料庫的完整性。
3．合理的資料庫完整性設計，能夠同時兼顧資料庫的完整性和系統的效能。比如裝載大量數據時，只要在裝載之前臨時使基於DBMS的資料庫完整性約束失效，此後再使其生效，就能保證既不影響數據裝載的效率又能保證資料庫的完整性。
4．在套用軟體的功能測試中，完善的資料庫完整性有助於儘早發現套用軟體的錯誤。
資料庫完整性約束可分為6類：列級靜態約束、元組級靜態約束、關係級靜態約束、列級動態約束、元組級動態約束、關係級動態約束。動態約束通常由套用軟體來實現。不同DBMS支持的資料庫完整性基本相同。
關係模型
關係完整性的用於保證資料庫中數據的正確性。系統在進行更新、插入或刪除等操作時都要檢查數據的完整性，核實其約束條件，即關係模型的完整性規則。在關係模型中有四類完整性約束：實體完整性、域完整性、參照完整性和用戶定義的完整性，其中實體完整性和參照完整性約束條件,稱為關係的兩個不變性。
實體
關係資料庫的完整性規則是資料庫設計的重要內容。絕大部分關係型資料庫管理系統RDBMS都可自動支持關係完整性規則，只要用戶在定義（建立）表的結構時，注意選定主鍵、外鍵及其參照表，RDBMS可自動實現其完整性約束條件。
（1）實體完整性（Entity Integrity）。實體完整性指表中行的完整性。主要用於保證操作的數據（記錄）非空、唯一且不重複。即實體完整性要求每個關係（表）有且僅有一個主鍵，每一個主鍵值必須唯一，而且不允許為“空”（NULL）或重複。
（2）實體完整性規則要求。若屬性A是基本關係R的主屬性，則屬性A不能取空值，即主屬性不可為空值。其中的空值(NULL)不是0，也不是空隔或空字元串，而是沒有值。實際上，空值是指暫時“沒有存放的值”、“不知道”或“無意義”的值。由於主鍵是實體數據（記錄）的惟一標識，若主屬性取空值，關係中就會存在不可標識（區分）的實體數據（記錄），這與實體的定義矛盾，而對於非主屬性可以取空值(NULL)，因此，將此規則稱為實體完整性規則。如學籍關係（表）中主屬性“學號”（列）中不能有空值，否則無法操作調用學籍表中的數據（記錄）。
域完整性
域完整性（Domain Integrity）是指資料庫表中的列必須滿足某種特定的數據類型或約束。其中約束又包括取值範圍、精度等規定。表中的CHECK、FOREIGN KEY 約束和DEFAULT、 NOT NULL定義都屬於域完整性的範疇。
參照完整性
參照完整性（Referential Integrity）屬於表間規則。對於永久關係的相關表，在更新、插入或刪除記錄時，如果只改其一，就會影響數據的完整性。如刪除父表的某記錄後，子表的相應記錄未刪除，致使這些記錄稱為孤立記錄。對於更新、插入或刪除表間數據的完整性，統稱為參照完整性。通常，在客觀現實中的實體之間存在一定聯繫，在關係模型中實體及實體間的聯繫都是以關係進行描述，因此，操作時就可能存在著關係與關係間的關聯和引用。
在關係資料庫中，關係之間的聯繫是通過公共屬性實現的。這個公共屬性經常是一個表的主鍵，同時是另一個表的外鍵。參照完整性體現在兩個方面：實現了表與表之間的聯繫，外鍵的取值必須是另一個表的主鍵的有效值，或是“空”值。
參照完整性規則（Referential Integrity）要求：若屬性組F是關係模式R1的主鍵，同時F也是關係模式R2的外鍵，則在R2的關係中，F的取值只允許兩種可能：空值或等於R1關係中某個主鍵值。
R1稱為“被參照關係”模式，R2稱為“參照關係”模式。
注意：在實際套用中，外鍵不一定與對應的主鍵同名。外鍵常用下劃曲線標出。
用戶定義完整性
用戶定義完整性（User-defined Integrity）是對數據表中欄位屬性的約束，用戶定義完整性規則（User-defined integrity）也稱域完整性規則。包括欄位的值域、欄位的類型和欄位的有效規則（如小數位數）等約束，是由確定關係結構時所定義的欄位的屬性決定的。如，百分製成績的取值範圍在0~100之間等。
設計階段
一個好的資料庫完整性設計首先需要在需求分析階段確定要通過資料庫完整性約束實現的業務規則，然後在充分了解特定DBMS提供的完整性控制機制的基礎上，依據整個系統的體系結構和性能要求，遵照資料庫設計方法和套用軟體設計方法，合理選擇每個業務規則的實現方式；最後，認真測試，排除隱含的約束衝突和性能問題。基於DBMS的資料庫完整性設計大體分為以下幾個階段：
需求分析
在完成尋找業務規則的工作之後，確定要作為資料庫完整性的業務規則，並對業務規則進行分類。其中作為資料庫模式一部分的完整性設計按下面的過程進行。而由套用軟體來實現的資料庫完整性設計將按照軟體工程的方法進行。
概念設計
概念結構設計階段是將依據需求分析的結果轉換成一個獨立於具體DBMS的概念模型，即實體關係圖（ERD）。在概念結構設計階段就要開始資料庫完整性設計的實質階段，因為此階段的實體關係將在邏輯結構設計階段轉化為實體完整性約束和參照完整性約束，到邏輯結構設計階段將完成設計的主要工作。
邏輯設計
此階段就是將概念結構轉換為某個DBMS所支持的數據模型，並對其進行最佳化，包括對關係模型的規範化。此時，依據DBMS提供的完整性約束機制，對尚未加入邏輯結構中的完整性約束列表，逐條選擇合適的方式加以實現。
在邏輯結構設計階段結束時，作為資料庫模式一部分的完整性設計也就基本完成了。每種業務規則都可能有好幾種實現方式，應該選擇對資料庫性能影響最小的一種，有時需通過實際測試來決定。
設計原則
在實施資料庫完整性設計的時候，有一些基本的原則需要把握：
1．根據資料庫完整性約束的類型確定其實現的系統層次和方式，並提前考慮對系統性能的影響。一般情況下，靜態約束應儘量包含在資料庫模式中，而動態約束由應用程式實現。
2．實體完整性約束、參照完整性約束是關係資料庫最重要的完整性約束，在不影響系統關鍵性能的前提下需儘量套用。用一定的時間和空間來換取系統的易用性是值得的。
3．另一方面，觸發器的多級觸發不好控制，容易發生錯誤，非用不可時，最好使用Before型語句級觸發器。
4．在需求分析階段就必須制定完整性約束的命名規範，儘量使用有意義的英文單詞、縮寫詞、表名、列名及下劃線等組合，使其易於識別和記憶，如：CKC_EMP_REAL_INCOME_EMPLOYEE、PK_EMPLOYEE、CKT_EMPLOYEE。如果使用CASE工具，一般有預設的規則，可在此基礎上修改使用。
5．要根據業務規則對資料庫完整性進行細緻的測試，以儘早排除隱含的完整性約束間的衝突和對性能的影響。
6．要有專職的資料庫設計小組，自始至終負責資料庫的分析、設計、測試、實施及早期維護。資料庫設計人員不僅負責基於DBMS的資料庫完整性約束的設計實現，還要負責對套用軟體實現的資料庫完整性約束進行審核。
7．應採用合適的CASE工具來降低資料庫設計各階段的工作量。好的CASE工具能夠支持整個資料庫的生命周期，這將使資料庫設計人員的工作效率得到很大提高，同時也容易與用戶溝通。
