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