| Previous | Table of Contents | Next |
There are a number of fundamental differences between the MDAPI and the CWM that make direct comparisons somewhat difficult.
First of all, the MDAPI is an implementation model, rather than a metamodel. The MDAPI primarily defines interfaces that can
be used to query metadata from an OLAP metadata provider, which usually (but not necessarily) means a commercially-available
OLAP server. For example, an OLAP server can utilize both the CWM OLAP metamodel and the MDAPI in the following manner:
The server initially consumes a CWM model instance and sets up its internal, multidimensional metadata structures accordingly.
After the server has been loaded with data input values and calculations, etc., are performed, clients of the server could
then issue multidimensional queries against the server through the MDAPI. This has the benefit of providing a unified metadata
instance and data querying mechanism. For example, a user can define several metadata queries to subset Dimension Members
and then issue a data query that uses the metadata query result sets as the basis for forming and exposing a data result (essentially
a cube region or cube view). In this scenario, CWM is used to define the core OLAP metadata to a CWM-enabled provider, and
the provider exposes the MDAPI as its primary client interface for exposing both metadata instances and multidimensional data
values.
Note that, since a CWM model instance is MOF-compliant, instances of CWM metaclasses have inherent support for CORBA (or programming
language mapped) interfaces that provide access and navigation of the model itself. However, this is not necessarily sufficient
for integrated multidimensional metadata and data querying, which requires support for generating and navigating result sets,
among other things (since the CWM OLAP metamodel is a semantic model and not an implementation model, it defines neither behavioral
semantics, nor interfaces). Hence, the MDAPI and CWM can play rather complementary roles in the deployment of a multidimensional
data server.
The key to integrating the CWM and the MDAPI in the manner described above is through the alignment of the CWM OLAP metamodel
and MDAPI data model, a conceptual model that defines the semantic underpinnings of the metadata objects and interfaces. Alignment,
in this case, would generally consist of mapping the major classes of the MDAPI data model to the CWM OLAP metaclasses. The
following paragraphs do not attempt such a detailed mapping/derivation, but rather just point out some of the major areas
of correspondence between the two models:
• Cube. MDAPI, being primarily a query model, does not define the notion of Cube as a persistent, multidimensional database, but rather defines a Cube View. Cube View corresponds closely to the CWM OLAP concept of Cube Region, if the Cube Region’s formula is interpreted as the multidimensional query processed by the Cube View.
• Dimension. Both the MDAPI data model and CWM OLAP metamodel support similar concepts of Dimension and Dimension types.
• MemberSelection. Both models support the concept of a member query on a Dimension. This is called MemberSelection by CWM, and Membership by MDAPI. In both models, this member query is expression based.
• Properties. The MDAPI data model supports user-defined property types and values as a means of extending the core data model. A client of the metadata and data query objects (MemberSelection and CubeView) can specify both searches and sorts based on property types and value or ranges of values. The closest equivalent the CWM OLAP metamodel has in this regard is the general association to UML Attributes that’s inherited by any subclasses of the core UML Class. So, at least at the instance level, there is a close correspondence between both models in this regard, as well.
• Hierarchy and Level. Both models support the concepts of Hierarchy and Level and associations between them. A Dimension can have an arbitrary number of Hierarchies in either model. In the MDAPI data model, Dimension, Hierarchy, and
Level are all subclasses of Membership, and are all, therefore, expression (query) based by default. In the CWM OLAP metamodel, only Level derives from MemberSelection, but the correspondence in this regard is close enough.