Advances in Databases and Information Systems 1997

The importance of use of the concept of refinement for heterogeneous multidatabase interoperation research and development is emphasized. Using this concept, the commutative data model mapping method [12] is reconsidered. The method provides for verifiable design of the data model mappings handling the models as formal objects in frame of an abstract metamodel. For such metamodel an abstract machine notation is used combining pure mathematical notation with an ability to automatically prove important properties of the data type definitions as well as the subtype property based on the refinement concept. 
 
The concept of data model refinement is introduced. Data model commutative mapping method is based on this notion. The method is specifically oriented on extensible data model mapping (such as the object data models). To preserve information and operations of types of a specific data model while mapping them into the canonical types the commutativity of two mapping diagrams (data type state and data type behavior diagrams) should be established. The required state-based and behavioral properties of the mappings lead to a proof that a source data model is a refinement of its mapping into the canonical data model. 
 
The applicability of the method is demonstrated on the mapping of the ODMG'93 constructs (the relationship type) into canonical data types. The SYNTHESIS language is used for the canonical data model


Introduction
The notion of shared, interoperable databases is inherently based on integration of multiple data model paradigms, on methodologies of data model translation (mapping) and on an approach for canonical data model (database interlingua) development.The world of DBMSs continues to be extremely diverse.Only for object data models the scale of diversity can be easily perceived from F.Manola report evaluating OODBMS developments [20] and from X3H7 Object Model Features Matrix [28] intended to be a representative sample of the design space of object models to analyze their interoperability issues.
Industrial projects aiming at the heterogeneous database interoperability continue to be developed.Recently IRO-DB, an ESPRIT III project, focused on integration of heterogeneous object-oriented DBMS and also relational DBMS [9].The common data model chosen for the project is ODMG'93 [21].
The problem of integration of multiple data models in a single, canonical paradigm remains to be an urgent problem deserving further investigation.In this paper we attempt to emphasize the importance of one of the basic software paradigms, the concept of refinement, for heterogeneous database interoperation research and development.
We assume that completeness of database specifications (up to provision of function specifications in type definitions) is a necessary prerequisite for semantic interoperation [15].With such level of specification, the subtype definitions should be carefully introduced and checked: to take into account only the relationship of function signatures of type and subtype is not enough.Functions in a subtype should algorithmically refine corresponding functions in a supertype [18].Some of the related early results published in the area of data model mapping are well known [4,5,4,2,3,29,19,23,17].

Method for Data Models Integration in the Common Paradigm
Later a commutative data model mapping approach was developed to implement the heterogeneous multidatabase management system [10,11,12] in which the strict formal basis for data model transformation and a set of well-defined architectural principles of system design were applied.
Recently a research [26] was undertaken focusing on the need for formal interpretation in which we are able to transform databases between different data models.
Since the development of the mentioned above commutative data model mapping method (oriented on structured data models) object models become dominating [20].Structured data models motivated the commutative method were not extensible.On the contrary, in the contemporary data models users can easily add their own types with their own behaviors.
Another tightly related development in the same period is the formal software development techniques leading to formation of the mature formal methods possessing the "industrial-strength" (such as B, Raise, VDM, Z) [1,8,24].Importance of these concepts for data model and type specification is well known [27,18].Here we exploit these ideas in the interests of data model integration for the database interoperability and reuse.
For this purpose we reconsider a commutative DM mapping method [12] reflecting these major changes.The basic modifications include: 1) adjusting the method itself to the requirements of extensible data models (such as object models); 2) using instead of the denotational semantics of another abstract metamodel combining pure mathematical notation with an ability to automatically prove important properties of the data type definitions (consistency and preservation of invariants by the operations) as well as the subtype property based on the concept of refinement.
The paper is planned as follows.Initially we provide a brief description of the metamodel based on the abstract machines.The metamodel facilities for specification of states and behaviors are defined.Elements of abstract machine notation and their basic modularization features and refinement conditions are introduced.Then we show that the subtyping relation can be interpreted as a refinement of abstract machines.An approach for the heterogeneous data models integration in the common, canonical paradigm is considered in the next section.This approach implies a way of commutative data model mapping construction considered further.Finally an example of constructing of commutative mapping for an ODMG'93 relationship type is presented.

Data metamodel
In this research we exploit the abstract machine notation (AMN) [1] for the formal data metamodel elaborating earlier studies [12] where the pure denotational semantics were used for the same purpose.The difficulties with the proofs that we had for the latter [11] are significantly simplified for the AMN due to the existence of the B-Toolkit [1] capable to generate proof obligations and prove them.
AMN as a model-theoretic notation makes possible to integrate the specification of the state space and behavior (specified by operations on the states).Specification of the state of a machine consists in providing of state variables together with invariants -constraints that always should be satisfied.Operations are defined using an extension of Dijkstra's formalism of guarded commands.

State Specification
The state specification notation is based on a set theory and a typed first-order language with the built-in types and type (sort) constructors.The collection of complex sort constructors includes: cartesian product (), powerset ( ), set comprehension (fxjx 2 s ^Pg), relational sort constructors (s $ t), functional sort constructors (s ,! t:) Here s,t denote sets, P denotes a predicate.Predicates in the notation are defined using the first-order language.The set of all well-formed formulae (further simply "predicates") is defined using the logical connectors and quantifiers.The interpretation of a state of an abstract machine is given by the machine variable binding assigning to each variable an element in a certain domain.

Specification of Behavior
The operations of the abstract machines are based on the generalized substitutions.
Every generalized substitution S defines a predicate transformer binding with some postcondition R its weakest precondition S R that guarantees the invariance of R after an operation execution.If it is so, one says that S establishes R. "Weakest" precondition means that the "initial state" predicate associated with some given "final state" predicate should allow as many states as possible.The predicate R 0 is weaker then R iff R R 0 .The weakest precondition S R is obtained by replacing the variables in R according to the rules provided by different kinds of the generalized substitutions.In complete paper the generalized substitutions of AMN are explained.Elements of the Abstract Machine Notation and basic modularization features of AMN are introduced.
A machine N is said to refine a machine M if a user can use N instead of M without noticing it.Applying algorithmic and data refinement the refinement machine can be constructed [1].In AMN it is possible to prove formally that a machine is a refinement of another one using specialized tool.Modeling type and subtype by an abstract machine and its refinement we can formally establish the subtyping conditions.
More details on B AMN as the data metamodel will be provided in the complete paper.

An approach for heterogeneous data models integration
The basic idea of heterogeneous multidatabase management consists in the introduction of DBMS-independent generalized level of data representation and manipulation -canonical database level -and a canonical model of a multidatabase system corresponding to this level.Data models (DM) supported by DBMSs with respect to this canonical DM are internal ones.Formation of a multidatabase system becomes possible on the basis of methods of data model mapping (while speaking about mapping, the DM being mapped will be called a source DM and the DM into which the mapping is carried out -a target one).
In transition from internal DM to the to canonical one it is necessary to preserve the information and operations so that instances of any type t s defined in a source data model could be used as the instances of a target type t t mapped from t s : To reach this we require that the internal DM should refine the canonical one.If we reach this, the internal data models will be correctly integrated within the canonical one.

Definition 1.
The concept of data model refinement is introduced in the following manner.
Database states in a source and a target DM are equivalent iff they are mapped into one and the same state in the content of an abstract data metamodel.Such state mapping should be "isomorphic" -i.e. each element of a composite state in one model should correspond to an equivalent element in the other model.It is assumed that equivalent database states represent one and the same collection of facts.
A type t s bijectively data refines a type t t iff the types produce sets of database states of equal power related by bijective dependency in such a way that the states being in one-to-one correspondence are equivalent.For such refinement a data abstraction is a total bijective function relating equivalent states.
In sequel mentioning the type refinement we assume that it possesses bijective data refinement property.
A schema S srefines a schema S tiff for each type t s of S sthere is a type t t in S t( S tdoes not contain other types) such that t s is a refinement of t t : A data model M s refines a data model M t iff for each admissible schema S sof M s there exists an admissible schema S tof M t such that S sis a refinement of S t : For the heterogeneous data models integration it is sufficient to require that any source data model should be a refinement of the canonial one: the paradigms of source data models should be integrated within the canonical data model.

Mapping diagrams
We assume that schemas in any DM consist of definitions of types (in different models we can meet with various notions of types -such as interfaces (ODMG'93), abstract data types (SQL3), classes (ObjectStore), etc.).Taking this into account, we can decompose mapping of schemas into the mapping of type specifications.Even more, in the current analysis we intend to deflect our attention of such peculiarities of object models as inheritance, overriding, metatypes [16].We focus on a type specification statically released of the relationships in the inheritance, generalization and classification hierarchies of a particular schema.At the same time, we preserve the subtyping relationship between types as well as polymorphism and possibility of late bindings.Thus we can abstract of many peculiarities of specific object models [20] concentrating on clean type specifications and subtype relationships that we can extract of these models.
For data model M i the set of all data type schemas expressible in DDL of M i is denoted by T i : Definition 2. The data type state corresponding to a type schema t i 2 T i is a function s ti : I d t i !V i ; defining for each state variable (attribute) of the type schema denoted by identifier I 2 I d t i its value v i taken from the set of admissible values V i of the variable type.It is essential that v i in its turn can also be an analogous function.
A set of admissible states corresponding to some type schema t i 2 T i is a set of functions S ti : I d t i !V i : A space of data type states expressible in M i is a set of functions S i : I d i !V i ; which may be considered as a union of sets s ti 2 S ti for all t i 2 T i : We consider only admissible states that satisfy the invariants related to types.

Definition 3.
The data type behavior corresponding to a type schema t i 2 T i is a function b ti : O ti !S ti S t k : : : S t n !S t i defining for each operation in the type schema the related state transformation for this type.
t k ; : : : ; t n are type schemas included into the same database schema that is a type schema t i : A set of admissible behaviors corresponding to some type schema t i 2 T i is a set of functions B ti : O t i !S t i S t k : : : S t n !

S t i :
A space of data type behaviors expressible in M i is a set of functions B i : O i !S i : : : S i !S i ; which may be considered as union of sets b ti 2 B ti for all t i 2 T i : The following set of mappings constitutes the mapping f of data model M j into data model M i : data type schema of M j into data type schema of M i mapping: the data type state space of M j into the datatype state space of M i mapping: the data type behavior of M i into the datatype behavior of M j mapping:

Basic propositions
The following propositions form the basis of a heterogeneous data models integration conception.
Advances in Databases and Information Systems, 1997 Proposition 1.The data model axiomatic extension principle.Canonical data model in the multidatabase management system should be extensible while new source data models are considered.Such extension is implemented axiomatically.Axiomatic in this context means that the extension of a target DM is carried out by addition to its DDL of a system of declarative facilities (axioms) determining (in terms of a target model) logical data dependencies of the source DM.The extension should result in provision of the source DM to be a bijective data refinement of the target data model.Note, that for this step we restrict these extensions only with those DM features that determine the database states.Following axiomatic extension principle, we try to keep the same level of the specification declarativeness in the canonical data model extension as in the source data model.
Construction of a target DM axiomatic extension is considered as a new language design on the basis of the target DM (the canonical DM kernel).
Proposition 2. The data model commutative mapping principle.In the process of mapping the DM of a specific DBMS into a canonical one it is necessary to preserve information and operations.This requirement is satisfied if DM mapping is commutative.Mapping f = ; ; of data model M j into extension M ij of data model M i is commutative iff the following conditions hold: -data type state diagram is commutative: mapping is an algorithmic refinement.
Here ij denotes a set of axiom schemas expressing the data dependencies of M j in terms of M i .
Proposition 3. The unifying canonical data model synthesis principle.Canonical data model synthesis is a process of 1) construction of the canonical data model kernel extensions such that data models of DBMSs embraced by the multidatabase system refine these extensions and 2) merging such extensions in a canonical data model.In such way a unifying canonical data model is formed in which data models of various DBMSs have homogeneous representations (by the subsets of a unifying data model).

Commutative data model mapping characterization
Axioms a ij 2 ij by which inherent consistency rules fixed in data model M j and defined in terms of M i are expressed will be referred to as the data base invariants.
Advances in Databases and Information Systems, 1997 For axiomatic extensions of M i we take the complete sets of invariants which define for data types of M ij all consistency rules inherent for M j : A data model M i is included into a data model M j if all axiom schemas ri of an extension M ri of a reference data model M r such that M i is its (M ri ) refinement are included (possibly not strictly) into the set of axiom schemas rj of an extension M rj of the reference data model M r such that M j is its (M rj ) refinement.The properties of commutative data model mappings defined above influence greatly the methods of commutative DM mapping design.In particular, from proposition of existence it follows that the process of design of canonical data model kernel axiomatic extensions and the process of design of behavior of types in the extended target data model refined by means of the source one can be separated.Thus, it is allowed to separate and treat independently the process of canonical unifying data model synthesis from the process of definition of the types behavior.

Commutative data model mapping construction
The main reason for formal definition of data models is to obtain their compact and precise description, making possible manipulation by different data models as by mathematical objects.We use AMN as the formal data metamodel that is general (i.e. , independent of particular data models concepts), allowing precise expression of semantics properties of different data models, of their similarity or difference on the basis of one and the same language.
Formal definition of data models makes possible the development of a common data model mapping discipline, according to which the construction of data model mapping and of the proof of it's correctness can be done simultaneously.
Constructing the data model mapping, it is natural to use results obtained in the domain of programming languages semantics description.Generally, the definition of programming language L semantics is a mechanism M which relates the syntactical constructions or programs of the language to their content (or denotation -an object corresponding to its own name).In other words M : P !D, where P is syntactical domain of M (the set of all syntactically correct programs in L), D -semantical domain of M (the set of the program denotations).
Properties of AMN suggest application of compiler-based semantics in which D is the set of target language abstract representation of the syntax of the language (e. g. in the form of a parse tree).It is quite natural to put abstract machines into direct correspondence to data types instead of using another semantics (axiomatic, operational or denotational ones).

Method of commutative data model mapping construction is oriented towards definition of canonical DM
kernel extensions that should be refined by the internal data models.Applying compiler-based semantics, we should construct 1)M j into an extension of M i mapping; 2) AMN semantics of M j ; 3) AMN semantics of the extended M i : After that we can apply AMN technology to prove a) the state-based properties of the mapping (commutativity of the data type state diagrams); b) the behavioral properties of the mapping for all type models defined for a particular internal data model.This leads to a proof that M j is a refinement of the extension of M i : The mapping obtained can be used in process of definition of new, application specific types to get their particular mappings and the respected proofs.Such approach justifes the choice of compiler-based semantics and resembles an idea of computer-assisted application of formal methods for the software design.
Method of unifying canonical data model (UCDM) synthesis.UCDM contains arbitrary data models of different DBMSs reduced to homogeneous refinement-based representations.Process of UCDM synthesis consists of the following stages : 1. source data models set selection: W = fM 1 ; M 2 ; :::; M n g ; 2. setting of partial order on the W set by relation of inclusion of one data model into another ; 3. UCDM kernel M c selection."Minimal" data model M i , i = 1 ; 2 ; :::; n is selected so that 8j 1jn M ri M rj Here M ri ( or M rj ) denotes mapping of M i (or M j ) data models into the fixed reference data model; 4. construction of extensions M cj of the kernel M c refined by a source model M j ; 5. UCDM construction as a union of all M cj :

Mapping of the ODMG'93 data types into the canonical data types
As an example we consider the mapping of the ODMG'93 relationship type into the SYNTHESIS association metatype.

ODMG'93 relationship type
ODMG-93 [21] introduces in ODL the concept of binary one-to-one, one-to-many and many-to-many relationships defined between mutable object types.We focus on the one-to-many relationships here.The relationships rediscover CODASYL sets that were well studied in 70ies and 80ies [7].Semantics of CODASYL sets is dependent on the kind of set membership declared (such as OPTIONAL MANUAL, MANDATORY AUTO-MATIC, etc.).Set membership influences the semantics of set member (owner) creation, deletion, modification operations to preserve the referential integrity constraints imposed by the kind of the set membership declared.Partial order can also be imposed on the set type.
The BNF for the ODL relationship specification follows: relationship spec ::= relationship target of path traversal path name inverse inverse traversal path order by attribute list traversal path name ::= string target of path ::= collection type target type target type ::= type name inverse traversal path ::= target type :: traversal path name Use of the collection type option indicates cardinality greater than one on the target side.If this option is omitted, the cardinality on the target side is one.An ordering criterion is specified with the order by clause.Each attribute used in the ordering criterion must be defined in the property list of the target type definition.Inverse traversal path may be given in both source and target traversal path descriptions.
The operations defined on a one-to-many relationship type are the following: create (o1 We assume that a specific one-to-many relationship R supports rather weak constraint, namely, a partial function R : T S; where T is a set of objects of the target type and S is a set of objects of the source type.
The semantics of creation, deletion and modification of objects belonging to T and S should preserve such integrity constraint.

The related SYNTHESIS language constructs
The SYNTHESIS language [13] provides the common interoperation platform for the project2 .SYNTHESIS is a multipurpose language.The language should provide for equivalent homogeneous description of various heterogeneous information resources, complete description of the application domains, information system design intended for reuse of the preexisting information resources, application problem definition and solving in HIRE.
The SYNTHESIS object model is defined uniformly with a functional object semantics.The model is functional in the sense that all manipulations of objects are based on the application of functions to objects.Here we focus only on an association metatype of the SYNTHESIS language.
In the languge the attribute specifications of objects may be treated in their turn also as types of association objects establishing a correspondence between a set of objects in an association domain and a set of objects in an association range.Thus a specification of an attribute may be considered as a specification of an association type.
Obvious attributes of an association are its domain and range.
Treating an object attribute as an association type motivates an introduction of association metatypes establishing properties of association types.It is said that an object attribute (as an association type) belongs to a particular attribute category that is explicitely introduced by an association metatype.Association metatypes have several predefined attributes.A specification of an association metatype is defined as follows: association metatype ::= f association metatype identi er ; in : association; metatype; params : f formal parameter list g; supertype : supertype list ; inverse : association metatype identi er ; attribute speci cation list ; instance section : f association type : f bounds ; bounds g; domain : domain ; range : range ; attribute speci cation list g; g bounds ::= f lower bound ; upper bound g lower bound ::= arithmetic expression jinf upper bound ::= arithmetic expression jinf Association metatype names (for direct and inverse associations) are used for category names of type attributes.An association type is defined in an instance section of the association metatype.
An association type is assumed to be a subtype of a set type with elements of a product type defined on an association domain and range types.An association type constraint (defining a kind of binary relation) is set by an attribute association type.If the association R is defined on a domain C 1 and a range C 2 then the bounds define the following.The first bound gives for any object c 1 of C 1 an admissible range (minimal and maximal value) of a number of different objects of c 2 in C 2 such that c 1 ; c 2 belongs to R. The second bound for any c 2 of C 2 gives a minimal and maximal value of a number of objects c 1 of C 1 such that c 2 ; c 1 belongs to an association inverse to R. inf is a constant denoting an arbitrary positive integer.
By means of an instance section another attributes of an association type may be defined as usual, thus "attributes of attributes" can be introduced (e.g., for an attribute price attributes of this type can be provided, such as price status and currency).
In the SYNTHESIS language type specifications are syntactically represented by frames, their attributesby slots of the frames.Additional information related to attributes can be included into metaslots.Syntactically frames are included into figure brackets f and g, slots are represented as pairs slot name : slot value (a frame can be used as a slot value), slots in a frame are separated by semi-colons.Metaslots (that are represented by frames) are written immediatelly after the slots to which they are related.If for a particular object type attribute a metaslot is declared and it is defined that the attribute belongs to a certain attribute category (categories) then a union of the corresponding specifications given in the metaslot and in an instance sections of the corresponding association metatypes is formed.
In the language there exists a possibility of indication that an attribute of a type is an inverse association of another type.

Mapping of the ODL relationship type into the SYNTHESIS data model
We shall map the relationship type into the SYNTHESIS association metatype.This case shows how carefully the canonical model kernel should be designed to be extensible.The SYNTHESIS association metatype is a loose, unconstrained type that can be easily extended by associating to it new attributes -state, assertional and functional.Thus specific properties of the association types introduced by attribute specifications of ordinary SYNTHESIS types can be established.
The ODL relationship type is a concrete, built-in type that might be interpreted as the C++ class for which the specific relationships defined in types may be treated as instances.
Mapping the relationship type into the association metatype, first, we should provide mapping of the type schemas leading to the bijective data refinement of the data type state diagram.To reach that we should provide an appropriate extension of the association metatype introducing adequate axioms.
After that we should provide the appropriate mapping of operations leading to the algorithmic refinement of the data type behavior diagram.
Axiomatic extension of the SYNTHESIS association metatype definition providing the ODL relationship to be its data refinement includes two axioms: 1.The axiom of partial functional dependency of the association range on the association domain that we express by fixing the association type in the metatype definition as follows: fassociation type : ff0; inf g; f0; 1 gg and making this metatype attribute obligatory; 2. The axiom of order that is provided by the assertion extending the canonical kernel: ordered by : f attribute list g

Method for Data Models Integration in the Common Paradigm
The latter is optional axiom making association metatype definition to be parameterized with attribute list .The attribute list is represented as an instance of the sequence of string type.The empty attribute list means that no ordering is implied.
Mapping of operations is provided by specification of the relationship operations create, delete, add one to one, remove one to one and traverse in the attribute specification list of the metatype.The odl relationship type below is an association metatype being the result of the relationship type mapping.Only three operations are shown./* ordf is assumed to be a function that returns a set of objects given by the second parameter ordered by values of ordering attributes given by the first parameter.this means class of associations given by the instance section.
Each frame may be declared to belong to some class.Such class membership is given by a slot in: class name list : The meaning of a function parameter sort symbol is: + denotes an input parameter; -denotes an output parameter; empty denotes input -output parameter.*/ gg 5.4 Using the AMN metamodel to justify the correctness of the mapping

Abstract interpretation of the ODL relationship type in AMN
We introduce two sets -V1 and V2 interpreting sets of admissible values of two related object types.We consider here only one-to-many relationships and a case when for a collection type in a relationship a set type is used.Abstract machines included into this paper have been developed and proved with the assistance of I.A.Chaban.To interprete relationship we introduce two variables establishing direct and inverse traversal paths in a relationship: dpath 2 V1 7 ,! seq( V2 ) ^ipath 2 V2 7 ,! V1 Here 7 ,! denotes a partial function and seq(S) is a set of finite sequences of elements from S. Each sequence over a set S is a partial function whose domain is an interval 1::n for some natural number n. dpath is considered to be a natural representation of a CODASYL set type that we use here to interprete the relationship.dpath establishes set instances and an order imposed on each of them.
ipath expresses a constraint that we assume to be imposed by an ODMG relationship corresponding to CODASYL sets having OPTIONAL MANUAL membership.The following invariants interrelates dpath and ipath: Here dom and ran are a domain and a range of a binary relation, r ,1 is an inverse of a relation formed by interchanging the elements of each ordered pair constituting the relationship.To interprete ordered relationships we introduce the type fsort 2 ( ATTR LIST ) 1 ( VV ) ,! seq

END
= PRE P THEN S END is the AMN equivalent for the pre-conditioned substitution P j S: = END Complete definition of an abstract machine interpreting the ODMG relationship type as a refinement of the corresponding canonical type is given in a separate subsection below.

Abstract interpretation of the extended SYNTHESIS association metatype in AMN
As a loose, unconstrained type the SYNTHESIS association metatype is naturally interpreted in AMN by a very general form of binary relation of AMN: rr 2 V1 $ V2 equivalent to powerset (V1 V2).Now we shall impose additional constraints corresponding to two axioms extending an association metatype to make the ODMG relationship type its bijective data refinement.To the first axiom fassociation type : ff0; inf g; f0; 1 gg the following invariant of AMN corresponds: Here rr[s] is an image of set s under rr.To interprete an axiom of order we impose an ordering constraint similarly to the ODMG type: The complete AM corresponding to the association metatype looks as follows.For brevity we include only three operations of the machine: add one to one, remove one to one and traverse.

The refinement machine
To define the AM corresponding to the ODMG relationship type as a refinement of the association metatype machine we establish the following abstraction bijective relation: Now we can introduce the definition of the AM being a refinement of the extended association metatype in SYNTHESIS by the ODMG relationship type: AMN specifications above were used for generation of the refinement proof obligations and formal proofs justifying correctness of the mapping constructed.During this process several errors in specifications were corrected.The errors usually were related to some border conditions in the abstract machine and the refinement that were not defined consistently.

An example of the relationship type mapping
We illustrate here mapping of two interfaces defined in ODL into the SYNTHESIS types emphasizing the relationship type mapping.The definitions of the Professor and Section interfaces in ODL looks as follows (an abridged example is taken from [21] The paper contributes to the creation of a methodological basis for solving the problem of data model heterogeneity in multidatabase interoperable environment.Using the concept of data model refinement, the commutative data model mapping method [11,12] is reconsidered.The method provides for verifiable design of the data model mappings handling the models as formal objects in frame of an abstract metamodel.For such Advances in Databases and Information Systems, 1997

-
mapping is a bijective abstraction function of a data refinement;

Proposition 4 .
Proposition of existence.If the data type state mapping diagram of M j to M ij commutes, then the behavioral data type mapping diagram can be constructed.Proposition 5. Proposition of refinement.Data model M j refines M i iff there exists commutative mapping of M j to M i .