The mapping to RDBMS schemata should follow the OO-paradigm for databases which originally has been layed out for the relational data-model by E.F. Codd with his "Relational Model/Tasmania" (RM/T). In this set of definitions subtables would store only that data which pertained to its attributes, the RDBMS would automatically distribute on an INSERT-statement the appropriate attribute-values to the appropriate tables. SELECT-statements on upper-level tables would retrieve all attributes of those tables and all of its supertables up to and including the root. If a subtable did not carry attributes on its own it would be still important to store the fact that an instance of that subtable was created, which is possible with a set of RM/T relations and the important concept of "surrogate", which is system-supplied and can neither change its value nor can it be ever re-used.
Taking these basic ideas from RM/T and studying the basic concepts of the ODMG-specifications ("Object Database Management Group") which fit good enough with the ideas layed out in RM/T it should become possible to devise specifications which represent those ideas.
In order to do this it becomes necessary in any case that one employs the idea of surrogates, which allow for marking tuples in different tables with the same values and by this means allowing for determining which tuples from which tables represent the same object. Then, every table-definition should closely follow the definitions of the EIA/CDIF meta-meta-entities they represent, i.e. only carry those attributes which correspond to the meta-meta-attributes. Subtables should become existence dependent via their surrogate from the root-table, which represents the meta-meta-object "MetaObject". The reference must occur with the surrogate attribute in order to guarantee that the integrity remains intact in any case (like erroneous definitions of EIA/CDIF compliant meta-models by using duplicates in CDIFMetaIdentifier-values).
In addition to representing the meta-meta-entities in form of tables it becomes necessary to explicitly represent Meta-meta-relationships in form of tables. The referencing (linking) mechanism via foreign keys must occur via the surrogate values. Of course instances of meta-meta-relationships are uniquely identified by the surrogate.
Filling these relational tables should occur under program control (in this case the implementation of it occured with Object Rexx and the RDBMS was ORACLE, but could have been any other RDBMS). User driven deletions of tuples must occur such that the integrity of the tuples being federated over different tables remains intact.
In addition users should not need to be aware of the disperse parts of the tuples, i.e. which tables he needs to combine in order to get all of the relevant information for a MetaAttribute-definition. As the tables representing the EIA/CDIF meta-meta-entities themselves just carry their appropriate meta-meta-attributes one needs to define views with the VIEW-SQL-statement which combines the different parts of an object by joining the tuples over the surrogate.
As a result meta-model-definitions stored in these relational tables, one is able to employ SQL in order to analyze or check the definitions themselves. The following SQL-statement serves as a very simple example for a quality assurance check (it checks to see whether there are multiple different tuples carrying the same value for the meta-meta-attribute CDIFMetaIdentifier and if so how many times the appropriate surrogate value was used throughout all of the Meta-models stored in the RDBMS):
| SELECT |
CDIFMetaIdentifier, COUNT( * )
|
|
FROM
|
MO_
|
|
GROUP BY
|
CDIFMetaIdentifier
|
|
HAVING
|
COUNT( * )
> 1 ;
| |
( "MO_" is the name of the table representing the meta-meta-object "MetaObject".)
The presentation will talk in more detail about the mapping
and discusses implementational issues.
It is up to the audience to drive the talk by asking questions.
Rony G. Flatscher
Wirtschaftsuniversität Wien/Vienna University of Economics and Business Administration
Abt. f. Wirtschaftsinformatik/MIS Department
Wien/Vienna, Austria/Europe