# Simplified Integrity Checking for an Expressive Class of Denial Constraints
## 5 Denials with Negated Existential Quantifiers
#### Practical Applications
We observe that the reactive behavior of triggers is suitable for implementing integrity constraint maintenance policies, since they are able to respond with corrective reactions to potentially offending actions (such as the execution of updates that violate the constraints). Additionally, triggers are expressive enough so as to be able to include in their behavior any SQL query, possibly embedded in a procedural language, so that complex properties of the data are easily captured. Besides being expressive from the point of view of the language, triggers also offer suitable execution modes that would allow one to implement integrity maintenance both according to the usual \"corrective\" policy (first, the illegal update is executed, then the trigger reacts and checks the constraints, and finally, the update is undone) and to the \"preventive\" policy that we advocate here (first, check if the update is potentially illegal and, if so, do nothing). The corrective policy corresponds to the 'AFTER' execution mode of triggers, while the prevention policy can be obtained through 'BEFORE' triggers, available in all the main DBMSs. The main drawback regarding trigger-based integrity constraint maintenance is that the DBMSs have no built-in way to automatically derive triggers that would implement a simplified integrity check for any upcoming update, which means that the database or application designers need to manually define proper triggers. Our \(\mathsf{Simp}\) operator, instead, could be used on top of triggers, at database schema design time, to automatically produce,for each relation \(r\) in the database, the simplified checks to be executed in the face of updates to \(r\). Such simplified checks can then be translated into SQL queries installed within triggers responding to updates to \(r\). The translation from the datalog form to SQL is a straightforward process that poses no particular technical challenge. The use of triggers is but one of the ways in which the \(\mathsf{Simp}\) operator could greatly extend the capabilities of a DBMS to automatize the checking process so as to fully support in DBMSs much more expressive kinds of integrity constraints than primary and foreign key constraints. Yet, there is more than augmenting the expressiveness of the constraints: our simplification procedure also allows for expressing complex parametric update patterns that go beyond the single addition/deletion/update of a record from the database. In particular, we have shown how to deal with complex transactional patterns that may be executed in an all-or-nothing fashion and whose effect on the satisfaction of the integrity constraints might even be complex to compute by hand, while \(\mathsf{Simp}\) would make this part completely transparent. In particular, we envision a catalog of pre-designed update patterns (much in the same way as standard prepared statements in DBMSs) that users and applications can seamlessly use without having to pay any attention to integrity constraint maintenance, which could be completely taken care of by the system. We also observe that the interest in integrity constraint maintenance and detection of constraint violations is very high even outside of classical relational database. In particular, the advent of different data models has, if anything, fortified the attention to these topics. A notable example is that of the so-called graph databases, whose representation of nodes and arcs typically comes with additional properties and labels that can be queried through very recently standardized languages such as GQL [93]. While the model of graph databases is different from the relational one, their structure is also very conveniently represented through datalog-like formalisms. This representation has allowed several new research efforts to target the incremental maintenance of complex data properties of graph data [94].