Declarative and Procedural Integrity: Violation Responses

Violation Responses
When defining the database schema, you must not only determine how a given integrity constraint might most effectively be implemented, you must also decide what action the database engine should take if the constraint is violated. In most cases, of course, the database will simply reject the offending command, posting an error in whatever method is most effective. Sometimes, however, the database can take corrective action that makes the requested change acceptable. Examples of this include the provision of a default value for attributes that do not allow empty values, or performing a cascading update or cascading delete to preserve referential integrity. We’ll discuss violation responses in detail in Part 3.

Declarative and Procedural Integrity
Relational database engines provide integrity support in two ways: declarative and procedural. Declarative integrity support is explicitly defined (“declared”) as part of the database schema. Both the Jet database engine and SQL Server provide some declarative integrity support. Declarative integrity is the preferred method for implementing data integrity. You should use it wherever possible.

SQL Server implements procedural integrity support by way of trigger procedures that are executed (“triggered”) when a record is either inserted, updated, or deleted. The Jet database engine does not provide triggers or any other form of procedural integrity. When an integrity constraint cannot be implemented using declarative integrity it must be implemented in the front end.