Models 101
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 (represented by
). 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(represented by
). These can be used to define a layer of abstraction above the physical (or source) 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 using MetaMatrix Dimension Designer in various ways:
- Creation via importing source data characteristics. (see
- Manual creation
- Transforming or copying from one model into another
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. (See description of a Virtual Database)
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.
In MetaMatrix Designer, bindings are automatically created "under the hood" when you import from a specific supported data source. You can also create and maintain your own custom bindings. (see Connector Bindings)
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.
Dimension Designer will automatically validate your models whenever the user Saves ( Note: the "Models > Validate Automatically" option must be checked). When editing models, the editor tabs will display a "*" to indicate that the model has unsaved changes. In addition, the Web Service Advisor panel's VDB name will also show a "*" whenever there are unsaved changes.
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. (see Connector Bindings)
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.
Related Topics
(c) Copyright © 2000-2006 MetaMatrix, Inc. All rights reserved.
Visit http://www.metamatrix.com