Semantic Data Integrity Constraints
Semantic integrity constraints enforce the logical meaning of the data and its relationships. Physical integrity constraints enforce the physical integrity of the data, for example ensuring that the bit sequence 00000001 is stored as 00000001 and not 00000010.
The emphasis of this chapter is on declarative semantic constraints: constraints that are part of the definition of the database itself. It is also possible to implement procedural support for integrity using database features such as triggers and stored procedures. The principal drawbacks to procedural enforcement of database integrity are performance, the added programming requirements and, critically, the increased opportunity for errors in enforcement introduced by these methods. If a declarative constraint alternative is available, it is almost always a better choice than a trigger (which can introduce serious sequential timing issues) or stored procedure.
The least favorable method for enforcing database integrity is through application programming. Besides the increased programming burden and its likely introduction of errors into integrity enforcement, application programming introduces the additional fault of application specificity. If one application enforces database integrity and another does not, or if two programs enforce integrity in different, perhaps contradictory ways, then a still greater chance of corrupting the database results. Worse still, application‑based database integrity cannot affect ad hoc inserts, deletes, and updates to the database, and as a result place still further burdens on the DBA to find other mechanisms of preventing database corruption.
As Godfrey et al. (1998, p. 253) write, “Integrity constraints exist in practically all database applications today. Note that the integrity constraints […] are expressed declaratively, and in the same logical language with which we express facts and rules. By having integrity constraints explicitly represented, they are available to all applications alike. A declarative expression of ICs is important, because non-declarative specifications are difficult to express and maintain. Indeed, this same lesson lead to the advent of relational databases themselves: a declarative specification of facts and rules (views) is easier to express and maintain.”
The point of relational databases is to be application-neutral, thus serving all applications equally well.
These constraints, in addition to the other constraints defined for the system during the process of normalization, such as functional and multivalued dependencies, have the added advantage of facilitating query and join optimization. The richer the constraint set specified for a database, the more opportunities there are to enhance query optimization.
The principal types of declarative constraints described are as follows:
The recommendation for constraints is to specify them anywhere you can, being mindful of the performance debit their enforcement accrues. If you cannot trust your data, there is little point in maintaining the databases that contain it.
You can never declare semantic database constraints on columns defined with the XML, JSON, BLOB, or CLOB data types.
If performance issues make declarative constraints an unattractive option, then you should always implement integrity constraints by some other mechanism. The performance savings attained by implementing integrity constraints outside the database are often just transferred from the database to the application, negating any actual performance gains realized by not implementing the constraints declaratively.
The most important consideration must be that database integrity is consistently enforced.