POSC Specifications Version 2.3 |
Relational Implementation Methodology |
The rules used to create the full Epicentre model and the additional constraints on those rules arising from the application of subsetting and projection operations must be fully taken into account in order to maintain data integrity in an Epicentre data store.
It is desirable to enforce as many of Epicentre's rules as possible at the RDBMS level. Enforcing rules at this level helps ensure that direct SQL access to the model is handled correctly and takes advantage of RDBMS vendor tools for maintaining large, complex data stores.
Simple referential integrity constraints such as foreign key constraints and uniqueness constraints can and should be applied at the RDBMS level1. It is also possible to enforce certain simple model rules and projection imposed constraints through the RDBMS.
For performance reasons, it may not be desirable to apply complex model rules, like a mandatory select rule, at the RDBMS level. Projection operations such as consolidation can also create complex integrity problems that are not easily enforced through an RDBMS.
It is beyond the scope of this paper to detail all recommended methods for enforcing model rules through RDBMS technology.
All data integrity constraints imposed by the projection process are enforceable by a compatibility layer implementation.
The POSC sample implementation also enforces a few of Epicentre's logical model rules (e.g., a property must be related to an appropriate object). A robust implementation of the compatibility layer could enforce most, if not all, of the logical model rules (full or subset). This degree of enforcement may impose performance penalties, however, that are not acceptable.
Even though full enforcement of all model rules through the DAE is desirable, the state of today's technology makes this problematic. DAEF vendors distinguish their products by offering a high degree of rule enforcement in an efficient manner, but to expect that in the near future all DAEF products will enforce all model rules is probably not realistic. The degree to which rules are enforced can be captured and shared with users as part of a DAEF's profile. The DAEF profiles can be used by application developers to understand the kind of rule enforcement with which their application code will be forced to deal.
While basic data model integrity rules like uniqueness and foreign key constraints can be enforced by an RDBMS, all data integrity problems cannot automatically be guarded against by applying today's RDBMS tools.
The POSC sample implementation of the compatibility layer automatically maintains integrity relative to projection operations, but it does not enforce very many of the logical model rules that cannot be enforced through an RDBMS.
Today, to faithfully maintain data integrity in an Epicentre data store, an application must deal with self-enforcement of data integrity for all but the simplest logical model rules. This is true whether going through a compatibility layer or using direct SQL access. Direct SQL access, however, imposes the added burden on an application of dealing with integrity problems coming from projection operations.
As compatibility layer and RDBMS technology is improved and utilized to enforce more of Epicentre's rules, less burden will be placed on application developers to deal with data integrity enforcement.
If all applications and users issuing direct SQL queries follow the rules of the model and take into account the rules imposed by projection operations when adding, deleting and updating data, applications should be able to interoperate effectively. If data integrity is not properly maintained, however, interoperability between applications will be adversely affected.
If all applications and users issuing direct SQL queries follow the rules of the model and take into account the rules imposed by projection operations when adding, deleting and updating data, data should be portable from a subset to other Epicentre data stores. If data integrity is not properly maintained, however, data portability with other Epicentre data stores will be adversely affected.
1Note: POSC provides primary key and uniqueness constraints plus foreign key constraints for all simple foreign keys in its Sample Relational Implementation.
2Note: In the context of data integrity, application isolation/portability refers to the ability to isolate an application from handling self-enforcement of data integrity problems relative to the logical subset.
3Note: In the context of data integrity, application interoperability refers to the ability for different applications to logically interoperate asynchronously through the data store.
4Note: In the context of data integrity, data portability refers to the ability to logically move data between Epicentre implementations without loss of information or change in meaning.