What is Database Integrity

Database Integrity
The most general form of integrity constraint is the database constraint. Database constraints reference more than one relation: “A Customer is not allowed to have a status of ‘Preferred’ unless he or she has made a purchase in the last 12 months.” The majority of database constraints take this form.

It’s always a good idea to define integrity constraints as completely as possible, and database integrity is no exception. You must be careful, however, not to confuse a database constraint with the specification of a work process. A work process is something that is done with the database, such as adding an order, whereas an integrity constraint is a rule about the contents of the database. The rules that define the tasks that are performed using the database are work process constraints, not database constraints. Work processes can have a major impact on the data model, but they shouldn’t be made a part of it.

It isn’t always clear whether a given business rule is an integrity constraint or a work process (or something else entirely). The difference might not be desperately important. All else being equal, implement the rule where it’s most convenient to do so. If it’s a straightforward process to express a rule as a database constraint, do so. If that gets tricky (as it often can, even when the rule is clearly an integrity constraint), move it to the front-end processing, where it can be implemented procedurally.

On the other hand, if the rule is extremely volatile and subject to frequent change, it will probably be easier to maintain if it’s part of the database schema, where a single change will effect (but hopefully not break) all the systems referencing it.