A model is a representation of a set of information constructs. A familiar model is the relational model, which defines tables composed of columns and containing records of data. Another familiar model is the XML model, which defines hierarchical data sets.

In MetaMatrix, models are used to define the entities, and relationships between those entities, required to fully define the integration of information sets so that they may be accessed in a uniform manner, using a single API and access protocol.

The fundamental models in MetaMatrix define the structural and data characteristics of the information contained in data sources. These are referred to as source models. MetaMatrix uses the information in source models to federate the information in multiple sources, so that from a user's viewpoint these all appear to be in a single source.

In addition to source models, MetaMatrix provides the ability to define a variety of view models. These can be used to define a layer of abstraction above the physical layer, so that information can be presented to end users and consuming applications in business terms rather than as it is physically stored. These business views can be in a variety of forms: relational, XML, or Web services. Views are defined using transformations between models.

Models are defined differently depending on the MetaMatrix product you are using.

If you are using MetaMatrix Query, models are defined automatically when you add a new source using the ADD command, and when you populate that source with metadata using the IMPORT command. In other words, models are not exposed directly in the MetaMatrix Query product. However, the models created and stored in a VDB can be used in the MetaMatrix Dimension and Enterprise products, which do expose the models.

If you are using MetaMatrix Dimension or MetaMatrix Enterprise, you will define and maintain models using MetaMatrix Designer, an Eclipse-based GUI.

MetaMatrix Designer can be used to model a variety of classes of models. Each of these represent a conceptually different classification of models.

• Relational, which model data that can be represented in table – columns and records – form. Relational models can represent structures found in relational databases, spreadsheets, text files, or simple Web services.
• XML, which model the basic structures of XML documents. These can be “backed” by XML Schemas. XML models represent nested structures, including recursive hierarchies.
• XML Schema, the W3C standard for formally defining the structure and constraints of XML documents, as well as the datatypes defining permissible values in XML documents.
• Web Services, which define Web service interfaces, operations, and operation input and output parameters (in the form of XML Schemas).
• Model Extensions, for defining property name/value extensions to other model classes.

VDBs contain two primary varieties of model types - source and view. Source models represent the structure and characteristics of physical data sources, whereas view models represent the structure and characteristics of abstract structures you want to expose to your applications.

Models used for data integration are packaged into a virtual database (VDB). The models must be in a complete and consistent state when used for data integration. That is, the VDB must contain all the models and all resources they depend upon.

Models contained within a VDB can be imported into the MetaMatrix Designer. In this way, VDBs can be used as a way to exchange a set of related models.

Source models must all have connector bindings associated with them once a VDB is tested in Designer or deployed for data access. A connector binding provides the connectivity to the source for the query engine when it is executing queries to that source.

It is possible that multiple models may use the same binding, but each model must have a binding.

You can define connector bindings in the MetaMatrix Designer if you are using MetaMatrix Dimension or MetaMatrix Enterprise. Alternatively, if you are using MetaMatrix Query, bindings are automatically created "under the hood" when you add a source of a specific supported data source.

Models must be in a valid state in order to be used for data access. Validation of a single model means that it must be in a self-consistent and complete state, meaning that there are no "missing pieces" and no references to non-existent entities. Validation of multiple models checks that all inter-model dependencies are present and resolvable.

Models must always be validated when they are deployed in a VDB for data access purposes.

Models can be tested in MetaMatrix Designer by issuing SQL queries in the VDB Execution perspective. In this way, you can iterate between defining your integration models and testing them out to see if they are yielding the expected results.

All the source models in your VDB must have connector bindings associated with them in order for the VDB to be executable. You can define the bindings for each source model in the Designer.

Models are stored in XML format, using the XMI syntax defined by the OMG.

Model files should never be modified "by hand". While it is possible to do so, there is the possibility that you may corrupt the file such that it cannot be used within the MetaMatrix system.