Metasafe - Logical Architecture

Metasafe provides a direct connection between the conceptual model and the physical implementation thereby avoiding the "impedance mismatch", i.e. the gap between the information model (the blueprint) and the physical implementation. The user and developer deal directly with the conceptual model and the access language erSQL relates directly to the conceptual model. The application developer has full access to the services of the database via an elaborate set of methods provided by the API.

Making Conceptual Models real

A few years ago it seemed that the relational model is the end of the database development and we had to accept the gap between concepts describing the real world and the physical implementation in tables. The NOSQL-Approach (Not Only SQL), the specialized DMBSs for extremely large populations (Google, Amazon, Ebay, Facebook), new storage structures (column based storage) and special graphics databases have changed this view. The development of ORMs and especially the Microsoft "Entity Framework" prove that one more step forward from physical implementation towards application and user view is desirable and feasible.

The Layer Structure of Metasafe

Metasafe is organized in 4 logical layers and spans seamlessly from a generic high level description to the practical (physical) implementation. Each layer is described by the next layer above and describes the next layer below. This corresponds conceptually to the meta-modeling architecture published by OMG.

M3 – the Metameta Model Layer

describes the metataypes entities, relationships and attributes of the core of the system. It is implemented as by an XML-file with about 2000 elements.

M2 – the Meta Model Layer

contains the dictionary and the master model.  The dictionary describes all element-types (users, schemas, entities, relationships, attributes, catalogs, variants) and their (meta)-attributes. The master model describes the relationships between these types.

M1 – the Application Model Layer

describes specific user views as subsets of the master model. The user models (submodels) are assigned to usergroups to grant tailored access rights to a subset of the data.

M0 – the Instance Data Layer

contains instances of the data, organized in catalogs. Entities can exist in multiple manifestations – i.e. revisions and versions. Relationships are maintained between two fully qualified manifestations of entities.