维护数据完整性
1. 维护数据完整性的三种途径
⏹ 应用程序
⏹ 数据库触发器
通常只有在完整性约束不能够完全定义复杂的业务逻辑时才使用。
⏹ 定义的完整性约束
优点：
◆ 提供更高的效率
◆ 更容易定义和修改
◆ 规则管理更加集中
◆ 更灵活（disable和enable）
◆ 在数据字典中可以查完整定义
2. 完整性约束的种类
⏹ NOT NULL
⏹ UNIQUE
⏹ PRIMARY KEY
⏹ FOREIGN KEY
⏹ CHECK (用于定义表中每列或者几列必须满足的条件)
3. 约束状态
⏹ DISABLE NOVALIDATE
无论是老数据还是新数据都不遵守约束
⏹ DISABLE VALIDATE
如果置于这个状态所有关于约束的列都不允许修改（modify）。另外在这个约束上的索引被dropped，这个约束is disabled。
注释：如果这个约束is deferrable ，索引不会被dropped。
⏹ ENABLE NOVALIDATE
这种状态下，新数据如果违反了约束，不允许插入。但表中可能包含某些违反约束的数据。这种情况在OLTP系统向数据仓库加载数据比较适用。
⏹ ENABLE VALIDATE
新的违反约束的数据不允许被插入，老数据也不允许违反约束。
如果一个约束由别的状态改为ENABLE VALIDATE，数据库将花费很长的时间检查老数据，导致其他DML操作（如数据加载）等待。所以通常情况下，先改为ENABLE NOVALIDATE，然后再改为ENABLE VALIDATE。
通常ENABLE暗示了VALIDATE，DISABLE暗示了NOVALIDATE，除非特别指出。
⏹ 如果一个唯一或者主键约束由DISABLE改为ENABLE，将会自动创建唯一索引。反之，索引将被dropped。
⏹ 由NOVALIDATE改为VALIDATE，所有的数据将被检查一遍。
⏹ 将一个独立的约束改为ENABLE NOVALIDATE 改为ENABLE VALIDATE不会导致其他DDL语句的读写锁。
4. 约束检查
⏹ Nondeferred or immediate
⏹ Deferred （当整个事务全部提交时，才进行约束检查）
定义约束Immediate或者Deferred
ALTER SESSION
SET CONSTRAINT[S] =
{IMMEDIATE|DEFERRED|DEFAULT}
5. 创建表时定义约束
创建表时定义约束采用下列语法：
column datatype
[CONSTRAINT constraint]
{[NOT] NULL
|UNIQUE [USING INDEX index_clause]
|PRIMARY KEY [USING INDEX index_clause]
|REFERENCES [schema.]table [(column)]
[ON DELETE CASCADE]
|CHECK (condition)}
session数据错误是什么意思 constraint_state :==
[NOT DEFERRABLE|DEFERRABLE [INITIALLY {IMMEDIATE|DEFERRED}]]
[DISABLE|ENABLE [VALIDATE|NOVALIDATE]]
6. 定义约束时的考虑
⏹ 主键或者唯一约束
将索引放在单独的表空间
大量加载（bulk loads）频繁发生时，采用非唯一的索引
⏹ Self-reference 外键
在初始加载后再定义或者enable外键
延迟约束检查
7. 使用EXCEPTIONS表
1) 创建意外表
2) 运用EXCEPTIONS子句执行ALTER TABLE命令
SQL> ALTER ployee
ENABLE VALIDATE CONSTRAINT employee_dept_id_fk
      EXCEPTIONS ptions;
3) 从EXCEPTION表中查不合格数据
4) 纠正数据错误
5) Truncate EXCEPTION表重新激活约束。
8. 获取约束信息
从下列视图中获取约束信息：
DBA_CONTRAINTS
DBA_CONS_COLUMNS
DBA_CONTRAINTS表中字段定义如下表：
Name
Description
CONSTRAINT_TYPE
The type of constraint is P if Primary Key, U if Unique, R if foreign key, or C if Check constraint. NOT NULL constraints are stored as check constraints.
SEARCH_CONDITION
Shows the condition specified for a check constraint
R_OWNER
R_CONSTRAINT_NAME
Defines the owner and name of the referenced constraint for foreign keys
GENERATED
Indicates if the constraint name is system-generated (Valid values are USERNAME and GENERATED NAME.)
BAD
Indicates that the constraint is to be rewritten to avoid situations such as the Year 2000 problems
RELY
Is used in the optimizer, if this flag is set
LAST_CHANGE
Shows the date when the constraint was last enabled or disabled

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。