数据库完整性一般是指满足以下条件：
请注意，根据您的业务逻辑，这里并没有真正说明数据是否有效和/或准确。此逻辑是您放入触发器、过程、验证例程等中的任何内容，您自己构建这些逻辑以尝试确保进入数据库的所有内容都正常。（应该注意，Oracle 的检查约束可以被视为一种业务逻辑形式，它像唯一或主键约束一样被强制执行）。
数据库会很乐意拒绝不符合上述标准的数据，假设它们已被定义，但也会很乐意接受不符合上述标准的无效或不准确的数据。如果我有一个包含人名的字段，则数据库无法确定“John Smith”或“Jonh Smiht”是否准确（注意错字）。因此，虽然数据库会说一切都很好，但您从目视检查中知道情况并非如此。（这个例子虽然简单，但很难做任何事情。毕竟，你怎么知道他的名字不是真的这样拼写？我仅将其用作进入系统的任何数据的示例。期望百分比的字段很容易将 5% 设为 50% —— 数据库如何判断哪个是有效的？不能没有你编写大量复杂的业务逻辑，即使那样——在某些时候，你怎么知道它不是 50%？或者它不是5％？或者它应该是 25%，打字员真的很困惑！）
使用数据库完整性机制对您有利，但不要因为没有完整性错误就认为您的数据是好的。它仍然可以很容易地变得糟糕和误导。此外，也不要假设您的业务逻辑可以确保良好的数据。是的，您可以防止明显的错误（例如，一个字段的值不应超出 0 到 100 的范围），但是一旦满足范围，在某些时候，您必须信任提供给您的用户数据。并且在某些时候，用户会错误地将其提供给您。噗，坏数据，具有完全有效的数据库完整性。
在理论层面，一个域可以用一个值表来表示。（在理论上，因为非负整数域的值的数量是无限的。）有效值来自该域。
在 SQL 数据库中，您可以使用适当数据类型和约束的某种组合来建立有效值。例如，您可以将“employee_id”声明为一个整数，并通过 a) 外键约束限制为包含 'n' 个整数的表或 b) 检查约束来限制整数范围。
准确意味着，在所有可能的有效值中，用户选择了与实体在现实世界中的状态或描述相对应的值。从这个意义上说，用户可以是人，也可以是程序。
例如，假设图书馆中的一本书可以具有以下任何一种倾向：“已签出”、“最近归还”（尚未入库）、“入库”、“正在修复”和“丢失”。如果我签出一本书，并且数据库将其状态存储为“已签出”，那么数据库就该副本的处置而言是准确的。（在我的图书馆，结帐和归还由计算机完成，而不是由人完成。）
所以数据完整性需要数据库（只允许有效值）和用户（从所有可能的值中输入正确的值）的合作。