mmx metadata framework
...the DNA of your data
MMX metadata framework is a lightweight implementation of OMG Metadata Object Facility built on relational database technology. MMX framework
is based on three general concepts:
Metamodel | MMX Metamodel provides a storage mechanism for various knowledge models. The data model underlying the metadata framework is more abstract in nature than metadata models in general. The model consists of only a few abstract entities... see more.
Access layer | Object oriented methods can be exploited using inheritance to derive the whole data access layer from a small set of primitives created in SQL. MMX Metadata Framework provides several diverse methods of data access to fulfill different requirements... see more.
Generic transformation | A large part of relationships between different objects in metadata model are too complex to be described through simple static relations. Instead, universal data transformation concept is put to use enabling definition of transformations, mappings and transitions of any complexity... see more.

Metamodel-based validation of models

December 30, 2008 13:01 by marx
When creating a metamodel instance (ie. model), the structure of the metamodel can be used to automatically validate the structure of the corresponding model. Basically every class, association and attribute value can be interpreted as a constraint (validation rule) to enforce certain properties and characteristics of the model (metadata). As metamodels are often seen as 'defining languages for model descriptions' we might consider these rules a syntax check for a model expressed in this language.  
Constraints (validation rules) can be materialized and enforced during metadata scanning/loading process, during a dedicated validation maintenence task, on demand etc. In MMX framework the rules are implemented on database level as a set of data constraints of the metadata repository and form a protective layer transaparent to a user or an application built on the framework. Only 'structural' properties of a metamodel have been implemented - 'semantic' properties (homonyms, synonyms, reflexivity, transitivity etc.) and their use as validation rules is a separate (and much more complex) topic not covered yet. The rules for model validation implemented in MMX (and how they are enforced through constraints) are as follows: 
:{M1} objects inherit their type codes from corresponding classes in {M2} metamodel(s). Only concrete classes can have corresponding objects.
object.Type *partof(objectClass.Type) & objectClass.IsAbstractClass = False
relation.Type *partof(relationClass.Type)
property.Type *partof(propertyClass.Type)
:{M2} class names are unique within a namespace, ie. {M2} metamodel and are never empty.

objectClass.Name *isunique(objectClass.Name) & objectClass.Name <> nil

:{M1} parent-child relations between objects are derived from designated associations between their superclasses in {M2} metamodel(s). 
object.parent.Type *partof(*tree(relationClass.relatedObject.Type)) & relationClass.IsTaxonomy = True

:{M1} related objects inherit their type codes from {M2} classes and/or their superclasses related through {M2} associations and/or {M2} attributes.
relation.object.Type *partof(*tree(relationClass.object.Type))
relation.relatedObject.Type *partof(*tree(relationClass.relatedObject.Type))
property.object.Type *partof(*tree(propertyClass.object.Type))
property.domain.Type *partof(*tree(propertyClass.domain.Type))

:{M1} linear properties as well as significiant elements of hierarchical properties with empty (null) value inherit the default value from the corresponding {M2} attributes.

property.Value *coalesce(property.Value, propertyClass.defaultValue)

:The number of {M1} objects participating in a relation cannot exceed or subcede the one expressed by the multiplicity property of the corresponding {M2} association on both ends.

*numberof(relation.object) *ge(relationClass.multiplicity.minValue)
*numberof(relation.relatedObject) *ge(relationClass.multiplicity.minValue)
*numberof(relation.object) *le(relationClass.multiplicity.maxValue)
*numberof(relation.relatedObject) *le(relationClass.multiplicity.maxValue)

:When the 'whole' object of a {M1} relation (descending from a {M2} association of type 'aggregation') is deleted, the relation itself is also deleted. When the 'whole' object of a {M1} relation (descending from a {M2} association of type 'composition') is deleted, both the relation and the 'parts' object are deleted.

*isdeleted(relation.object) & relationClass.Type = 'AGGR' -> relation := nil
*isdeleted(relation.object) & relationClass.Type = 'COMP' -> relation := nil
*isdeleted(relation.object) & relationClass.Type = 'COMP' -> relation.relatedObject := nil

The implementations are defined in an intuitive semi-formal notation. The operators *isunique, *partof, *tree, *isdeleted, *numberof, *ge and *le denote abstract pseudo-operations of uniqueness, being part of, tree of ancestors, deletion, count, greater-than-or-equal and less-than-or-equal.

Mapping UML class diagrams to MMX metamodel

November 21, 2008 22:23 by marx

An obvious choice for a tool for designing metamodels for MMX M2 level (MMX/M2) is UML class diagram. Class diagram is a mixture of elements concerned with both data structures and behaviour, and we are only interested in data structures aspect. The important elements that we need to consider while mapping an UML class diagram to MMX/M2 are: classes, interfaces, objects, attributes, annotations, associations, generalizations, enumerations and data types. Here's how those elements are mapped to the constructs of MMX Metamodel:

classes An UML class is implemented as an instance of MD_OBJECT_TYPE. A mandatory name column contains the name of the class and there's an indicator column to denote whether the class is an abstract or a concrete one.
interfaces An interface is implemented in exactly the same way as an abstract class.
objects An UML object is an instance of a class. Objects are implemented as instances of MD_OBJECT that get their object types supplied by MD_OBJECT_TYPE. The relationships between MD_OBJECT and MD_OBJECT_TYPE are essential for consistency of MMX model and are enforced by the facilities of referential integrity provided by the underlying database.
attributes An UML class attribute is implemented as an instance of MD_PROPERTY_TYPE. Each row in this table is related to the owner class of the attribute, and to the domain class of the attribute (a data type or an enumeration). In case a default value is provided it is stored in the default value column.
packages Package element is currently not mapped to MMX metadata model as it provides no additional benefits in this context. A metamodel is always assumed to belong to a single package with a single namespace.
annotations Comments and notes are stored as a text column of a class diagram element instance that it belongs to.
associations An UML association between two classes is implemented as an instance of MD_RELATION_TYPE. Each row in this table has two relations with MD_OBJECT_TYPE, one for each end of the association, and a name made up of both role names (all mandatory columns). An association type column indicates whether the row denotes an association, an aggregation or a composition, with null value denoting an association. Note that relationships in MMX metamodel are directional by design. 
aggregations An aggregation relationship is implemented exactly as an association, with the association type of aggregation ('A').
compositions A composition relationship is implemented exactly as an association, with the association type of composition ('C').
multiplicity Multiplicity of an association is stored in multiplicity type column of MD_RELATION_TYPE and takes a value from the predefined set of multiplicity types. The following notation is used:
0..1 (optional, zero or one) 'Z'
1 (one, or an exact number n) '1' ('n')
0..* or * (zero, one or more) '*'
1..* (at least one)  'P'
generalization Generalization has a very special role in MMX metadata model architecture as the mechanism for maintaining class hierarchies. Inheritance is implemented as parent-child relationship of MD_OBJECT_TYPE realizing superclass and subclass relations between classes. Note that MD_PROPERTY_TYPE and MD_RELATION_TYPE also have this relationship and can therefore constitute hierarchies of their own. Multiple inheritance is not permitted due to the single-parent nature of the parent-child relationship.  
enumerations Enumerations are implemented as instances of MD_OBJECT_TYPE inherited from an abstract domain class. Enumeration literals are stored as instances of MD_OBJECT related to one particular MD_OBJECT_TYPE.
data types Like enumerations, UML data types are instances of MD_OBJECT_TYPE inherited from an abstract data type class. Unlike enumerations, data types do not have an implicit set of possible values.
constraints UML constraints are technically just informal annotations to the model that have to be taken care of during system implementation. MMX Metamodel does not support constraints in any formal way so they are left for an application to handle. 


Not all UML class diagram elements and features (eg. those designed for code generation) are relevant in the scope of metamodeling and are therefore not considered here. As an example, visibility property of class attributes is of no concern in metamodel context. Similarily, not all MMX/M2 features are required for mapping UML class diagrams.  

Relational Database Metamodel

November 2, 2008 12:50 by marx
Probably the best and most comprehensive metamodel covering all of the aspects and details of a relational database instance is the one found in the Eclipse Project docs. The model is based on SQL-92, is MOF2 compliant and is “capable of representing all non-syntactic aspects of SQL92 Data Definition Language (at the ‘intermediate’ conformance level)”. The model is submitted by IBM as part of forthcoming OMG IMM specification. IMM (Information Management Metamodel) is the new moniker for CWM (Commaon Warehouse Metamodel) as the ‘Warehouse’ word was not digestable for some and replaces the long due CWM 2.0.

MMX Framework provides full implementation of the model as defined in OMG specs. It includes 80 classes (both abstract and concrete). One open issue is the form of a URI reference used to link back to a relational database object. There is no common agreement on this; actually a W3C incubator group W3C RDB2RDF XG is just about to release a recommendation that should cover this topic as well.