Transaction conflicts

The chapter is focused an avoiding physical and conceptual consistency problems. It also considers deadlock problems and rollback conflicts.

D2.1: Physical consistence are rules defined by the particular DBMS and which are verified by the DBMS, i.e. the application cannot violate physical consistency rules.

Typical consistency rules are maintaining indexes, i.e. keeping redundant information stored in key values consistent with the key attribute data in the index instances. Another complex area is referential integrity, which guarantees the existence or referenced instances. This, also included, e.g. maintaining unique constraints or maintaining foreign keys when updating key component attributes in the referenced instance (RDBMS). OODBMS usually do not have this problem, since instances are referenced by identities (database wide unique numbers), which never do change. Part of physical consistency in OODBMS is maintenance of inverse relationships, which is not a problem for RDBMS, which use intermediate tables in order to store M:N relationships. Some OODBMS support set relations, which are considered also as physical consistence rules, when being supported. Cardinality for collections (maximum number of instances), delete dependency between instances and many other features might be supported by a DBMS as physical consistency rules. Otherwise, those rules have to be implemented as conceptual consistency rules within the database application.

D2.1: Conceptual consistency is defined by a set of database rules within a database application, that describe conceptual correlations between instances and/or collections.

As conceptual consistency rules only those rules are considered, which apply under all circumstances and which do not depend on a specific application, only, running on the database. The number of conceptual consistency rules depends on the particular DBMS used for implementing a database application.

While physical consistence is verified by the DBMS, conceptual consistency has to be maintained by the application. Typically, consistency rules are implements as trigger functions or event handlers reacting on specific database events. Thus, changing a single attribute in a database instance may cause a number of side effects, on the physical level as well as on the conceptual.