Apart from integrity rules which check for the violation of constraints, a second concept exists to ensure referential integrity: triggers. Referential triggers are used to invoke operations when a data record is inserted, updated, or deleted. For example, when a record representing a purchase order is deleted, it is also necessary to delete the records containing the individual order lines. This can be achieved with triggers.
For XML documents, however, the concept of triggers to guarantee referential integrity is not as essential as it is for SQL. The reason is that a complex business document such as a purchase order is not – like in the relational world – fragmented into flat records but is instead stored as a single structured document. When such a purchase order is deleted, the order lines vanish, too, because they are contained in the same document.
However, there are scenarios where we might want to execute additional operations when documents are inserted, updated, or deleted:
As we have mentioned before, it is sometimes necessary to segment a large document into several smaller documents. In this case we must make sure that all sub-parts are deleted when the main document is deleted – the classical case of a relational trigger.
For performance reasons our model may contain redundant data. As
discussed before, jazzMusician documents may contain an element
numberOfAlbums with the number of all albums to which the
respective musician has contributed. If we add a new album
document to the database, we must update all correlated
jazzMusician documents (and similarly when we delete an
album).
Usually we convert XML documents into HTML using an XSLT stylesheet when we want to display them on the Web. However, this can be a bottleneck if we do this on the fly (i.e. every time when a document is requested). A common technique is to pre-generate HTML pages from the XML documents and satisfy incoming requests directly from the HTML pages. When an XML document changes, we have to re-generate the corresponding HTML page; otherwise, users would get outdated content. This re-generation could be initiated via a trigger.
The operations that are possible in the context of insert, update, or delete operations by far exceed the scope of traditional referential triggers. In particular, they can modify data outside the database, data that resides somewhere else.
Similar to integrity rules, the best place for the implementation of such general operations is the application or some appropriate middleware.
