指數據的精確性（Accuracy） 和可靠性（Reliability）。它是應防止數據庫中存在不符合語義規定的數據和防止因錯誤信息的輸入輸出造成無效操作或錯誤信息而提出的。數據完整性分為四類：實體完整性（Entity Integrity）、域完整
性（Domain Integrity）、參照完整性（Referential Integrity）、用戶定義的完整性（User-definedIntegrity）。
保證數據的完整性:
1. 用約束而非商務規則強制數據完整性
如果妳按照商務規則來處理需求，那麽妳應當檢查商務層次/用戶界面：如果商務規則以後發生變化，那麽只需要進行更新即可。
假如需求源於維護數據完整性的需要，那麽在數據庫層面上需要施加限制條件。
如果妳在數據層確實采用了約束，妳要保證有辦法把更新不能通過約束檢查的原因采用用戶理解的語言通知用戶界面。除非妳的字段命名很冗長，否則字段名本身還不夠。 — Lamont Adams
只要有可能，請采用數據庫系統實現數據的完整性。這不但包括通過標準化實現的完整性而且還包括數據的功能性。在寫數據的時候還可以增加觸發器來保證數據的正確性。不要依賴於商務層保證數據完整性；它不能保證表之間（外鍵）的完整性所以不能強加於其他完整性規則之上。
— Peter Ritchie
2. 分布式數據系統
對分布式系統而言，在妳決定是否在各個站點復制所有數據還是把數據保存在壹個地方之前應該估計壹下未來5 年或者10 年的數據量。當妳把數據傳送到其他站點的時候，最好在數據庫字段中設置壹些標記。在目的站點收到妳的數據之後更新妳的標記。為了進行這種數據傳輸，請寫下妳自己的批處理或者調度程序以特定時間間隔運行而不要讓用戶在每天的工作後傳輸數據。本地拷貝妳的維護數據，比如計算常數和利息率等，設置版本號保證數據在每個站點都完全壹致。
— Suhair TechRepublic
3. 強制指示完整性
沒有好辦法能在有害數據進入數據庫之後消除它，所以妳應該在它進入數據庫之前將其剔除。激活數據庫系統的指示完整性特性。這樣可以保持數據的清潔而能迫使開發人員投入更多的時間處理錯誤條件。
— kol
4. 關系
如果兩個實體之間存在多對壹關系，而且還有可能轉化為多對多關系，那麽妳最好壹開始就設置成多對多關系。從現有的多對壹關系轉變為多對多關系比壹開始就是多對多關系要難得多。
— CS Data Architect
5. 采用視圖
為了在妳的數據庫和妳的應用程序代碼之間提供另壹層抽象，妳可以為妳的應用程序建立專門的視圖而不必非要應用程序直接訪問數據表。這樣做還等於在處理數據庫變更時給妳提供了更多的自由。
— Gay Howe
6. 給數據保有和恢復制定計劃
考慮數據保有策略並包含在設計過程中，預先設計妳的數據恢復過程。采用可以發布給用戶/開發人員的數據字典實現方便的數據識別同時保證對數據源文檔化。編寫在線更新來“更新查詢”供以後萬壹數據丟失可以重新處理更新。
— kol
7. 用存儲過程讓系統做重活
解決了許多麻煩來產生壹個具有高度完整性的數據庫解決方案之後，我所在的團隊決定封裝壹些關聯表的功能組，提供壹整套常規的存儲過程來訪問各組以便加快速度和簡化客戶程序代碼的開發。在此期間，我們發現3GL 編碼器設置了所有可能的錯誤條件，比如以下所示：
SELECT Cnt = COUNT (*)
FROM [<Table>]
WHERE [<primary key column>] = <new value>
IF Cnt = 0
BEGIN
INSERT INTO [<Table>]
( [< primary key column>] )
VALUES ( <New value> )
END
ELSE
BEGIN
<indicate duplication error>
END
而壹個非3GL 編碼器是這樣做的：
INSERT INTO [<Table>]
( [< primary key column>] )
VALUES
( <New value> )
IF @@ERROR = 2627 -- Literal error code for Primary Key Constraint
BEGIN
<indicate duplication error>
END
第2 個程序簡單多了，而且事實上，利用了我們給數據庫的功能。雖然我個人不喜歡使用嵌入文字（2627）。但是那樣可以很方便地用壹點預先處理來代替。數據庫不只是壹個存放數據的地方，它也是簡化編碼之地。
— a-smith
8. 使用查找
控制數據完整性的最佳方式就是限制用戶的選擇。只要有可能都應該提供給用戶壹個清晰的價值列表供其選擇。這樣將減少鍵入代碼的錯誤和誤解同時提供數據的壹致性。某些公***數據特別適合查找：國家代碼、狀態代碼等