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