The basic idea behind the consistency checks is to maintain the flexibility of the Data Modeler by not requiring all models, entity types, and so on to be consistent in each work step.
In the Dictionary, on the other hand, an attempt is made to ensure complete consistency each time an object is created or changed. This is important because the Dictionary objects form the basis for the programs that are executed and for database accesses. However, from the point of view of the modeler, it would be annoying to have to ensure that the complete model has a consistent status at all times. For this reason, only a few checks are made when a model is being created.
The modeler should first create the objects and then check for inconsistencies in a separate check procedure. This is the purpose of the consistency checks. Once the checks have been made, the errors can be corrected.
It is also possible that referenced objects are forgotten when data models, entity types, and so on are transported. Inconsistencies may arise in the target system, even though the models are consistent in the source system. Here too, the inconsistencies can be located using the consistency checks and an appropriate supplementary transport can be organized.
The following important checks currently exist:
Checking data models for completeness
A check is made to find relationships and specializations whose source entity types do not belong to the data model. Inconsistencies of this type indicate that not all assignments have been made. This check is not normally appropriate for application data models.
Let data model DM1 comprise the entity types E1, E2, and E3. If, for example, there is a relationship from an entity type E4 to E2 or a generalization E5 for the specialization E3, then the check criterion 'completeness' has been violated twice (inconsistent relationship: E4 to E2, specialization/generalization to be checked: E5 to E3).
Checking data models for the existence of predecessors
A check is made to find the relationships and specializations whose source entity types do not exist. The most likely cause of such inconsistencies is a transport error.
Let the data model DM1 comprise the entity types E1, E2, and E3. If, for example, entity type E2 does not exist, the check criterion has been violated.
Checking data models for connectivity
A check is made to ensure that the entity types of a data model are connective. That is, a check is made to see whether there is a path connecting each entity type of the data model to each other entity type of the model. These paths are either relationships or specializations.
If the data model is not connective, the set of entity types making up the data model disintegrates into several unconnected subsets. Each of these subsets, however, is in itself connective. Inconsistencies of this type indicate that relationships are missing.
Let data model DM1 contain the entity types E1, E2, E3, E4, and E5. If a relationship exists between E1 and E2 and between E3 and E4, the data model is not connective. It is divided into three subsets (E1, E2), (E3, E4) and (E5).
Checking hierarchies for the existence of hierarchy objects
A check is made here to find data models and entity types that are included in the hierarchy, but that do not exist. Inconsistencies of this type are generally caused by a transport error.
Let data model DM1 include entity types E1, E2 and E3 and submodels DM2 and DM3. If data model DM3 and entity type E2 do not exist, the check criterion is violated twice.