| Oracle® OLAP Developer's Guide to the OLAP API 10g Release 1 (10.1) Part Number B10335-02 |
|
|
View PDF |
| Oracle® OLAP Developer's Guide to the OLAP API 10g Release 1 (10.1) Part Number B10335-02 |
|
|
View PDF |
This chapter describes the metadata objects that the OLAP API provides, and explains how these objects relate to the OLAP metadata objects that a database administrator specifies in the OLAP Catalog or that you create with the methods of an MdmCustomObjectFactory or an MtmPartitionedCube.
This chapter includes the following topics:
For the complete code of the examples in this chapter, see the example programs available from the Overview of the Oracle OLAP Java API Reference.
The OLAP API provides a Java application with access to a multidimensional view of data in an Oracle database. The OLAP API design includes objects that are consistent with that view and are familiar to data warehousing and OLAP developers. For example, it has objects for measures, dimensions, hierarchies, levels, and attributes. The OLAP API design incorporates an object-oriented model called MDM (multidimensional metadata).
The data in an Oracle database must be prepared by a database administrator in order to support the MDM model. An administrator must map the relational data to OLAP metadata by adding objects and characteristics to the OLAP Catalog.
A database administrator starts with a data warehouse that is organized according to certain specifications. For example, it might conform to a star schema. The requirements are described in the Oracle OLAP Application Developer's Guide.
The administrator adds OLAP metadata to the OLAP Catalog. The OLAP metadata objects, which are created in this step, supply the metadata required for Oracle OLAP to access the data. These OLAP metadata objects map to MDM metadata objects in the OLAP API.
An application developer can discover the mapping of the MDM metadata objects to the relational tables and views, or create some custom MDM metadata objects, by using MTM (metadata mapping) objects. See Chapter 5, " Working with Metadata Mapping Objects", for more information on MTM objects.
The topic "OLAP Metadata Objects" briefly describes the OLAP metadata objects that a database administrator prepares for use with Oracle OLAP.
A database administrator adds OLAP metadata to the OLAP Catalog for a data warehouse. The end result is the creation of one or more measure folders that contain one or more measures. The measures have dimensions and the dimensions have hierarchies, levels, and attributes. Each of these OLAP metadata objects maps directly to an MDM object in the OLAP API. For detailed information about OLAP metadata and about adding metadata to the OLAP Catalog, see the Oracle OLAP Application Developer's Guide.
An application developer can create transient custom metadata objects with instances of an MdmCustomObjectFactory or an MtmPartitionedCube class. The developer uses methods of MTM objects to map the MDM objects to data in the columns in relational tables. The transient objects exist only in the context of an MdmMetadataProvider during a connection to the database.
Note that the OLAP metadata includes a cube object, which does not map directly to any MDM object. Database administrators create cubes in the OLAP Catalog to specify the dimensions of each measure. Once the dimensions are specified, they are firmly associated with their measures in the metadata, so this type of cube object is not needed in the MDM model.
The rest of this topic briefly describes the OLAP metadata objects that map directly to MDM objects in the OLAP API.
The following are some of the characteristics that a database administrator can specify for dimensions:
General characteristics, such as the name of the dimension and the database schema from which its data is drawn.
Hierarchies, which organize the elements of the dimension into parent-child relationships. A hierarchy can be level-based or value-based. In a level-based hierarchy, the parent and child elements are in different levels. In a value-based hierarchy, the database administrator has defined the parent and child relationships by values rather than levels. A simple, nonhierarchical list of elements is represented by a hierarchy that has only one level and that has no parent-child relationships defined for the elements.
Levels, which organize the elements of a hierarchy into the levels defined for the dimension.
Attributes, which record characteristics of the elements for the dimension. For example, attributes record the level of each element of a level-based hierarchy and the depth of that level in the hierarchy.
Typically, a database administrator specifies one or more columns in a database table to serve as the basis for each OLAP level, hierarchy, and attribute.
A database administrator creates cubes after creating dimensions. A cube is a set of dimensions that provide organizational structure for measures.
In the OLAP Catalog, a database administrator specifies that a given measure belongs to a given cube. Because a cube is a set of dimensions that provide organizational structure for measures, specifying that a given measure belongs to a given cube specifies the dimensions of that measure. This is essential information for the OLAP API, where the dimensionality of a measure is one of its most important features.
To identify the data for a measure, the database administrator typically specifies a column in a fact table where the data for the measure resides. As an alternative, the database administrator can specify a calculation or transformation that produces the data.
Once a database administrator has created measures (after first creating dimensions and cubes), the next step is to create one or more groups of measures called measure folders. Typically, the measures in a given folder are related by subject matter. That is, they all pertain to the same business area. For example, there might be separate folders for financials, sales, and human resources data.
The measures in a given measure folder can belong to different cubes and they can be from more than one schema.
The database administrator must create at least one measure folder because the scope of the data that an OLAP API application can access is defined in terms of measure folders. That is, an OLAP API MdmMetadataProvider gives access only to the measures that are contained in measure folders. Of course, the dimensions of each measure are included, along with their hierarchies, levels, and attributes.
In this context, it is important to understand that measure folders can be nested. This means that a given measure folder can have subfolders that have their own measures, and even their own subfolders. Thus, a database administrator can arrange measures in a hierarchy of folders, and an OLAP API MdmMetadataProvider can give access to all of the measure folders and their subfolders.
The OLAP API implementation of the MDM model is represented by classes in the oracle.olapi.metadata.mdm package. Most of the classes in this package implement metadata objects, such as dimensions and measures. The following diagram introduces the subclasses of the MdmObject class.
An application gains access to metadata objects by creating an OLAP API MdmMetadataProvider and using it to discover the available metadata objects in the data store.
The metadata objects that a database administrator specifies in the OLAP Catalog map directly to MDM metadata objects that are accessible through the MdmMetadataProvider. The following table presents a typical mapping.
| OLAP Catalog Metadata Objects | MDM Metadata Objects |
|---|---|
| Dimension | MdmPrimaryDimension |
| Hierarchy | MdmLevelHierarchy or MdmValueHierarchy |
| Level | MdmLevel |
| Measure | MdmMeasure |
| Attribute | MdmAttribute |
| Measure folder | MdmSchema |
This chapter describes the MDM metadata objects. For information about how an application discovers the available MDM metadata objects in the data store, see Chapter 4, " Discovering the Available Metadata". MTM objects record the mapping of MDM objects to relational tables. For information on MTM objects, see Chapter 5, " Working with Metadata Mapping Objects".
MdmSchema and MdmSource are the two subclasses of MdmObject.
An MdmSchema represents a set of data that is used for navigational purposes. An MdmSchema is a container for MdmMeasure, MdmPrimaryDimension, and other MdmSchema objects. An MdmSchema is equivalent to a folder or directory that contains associated items. It does not correspond to a relational schema in the Oracle database. Instead, it corresponds to a measure folder, which can include data from several relational schemas and which was created in the OLAP Catalog by a database administrator or by the createSchema method of an MdmCustomObjectFactory.
Data that is accessible through the OLAP API is arranged under a top-level MdmSchema, which is referred to as the root MdmSchema. Under the root, there are one or more subschemas. To begin navigating the metadata, an application calls the getRootSchema method of the MdmMetadataProvider, as explained in Chapter 4, " Discovering the Available Metadata".
The root MdmSchema contains all of the MdmDimension objects that are in the data store. Most MdmPrimaryDimension objects are contained in subschemas under the root MdmSchema. However, a data store can contain a dimension that is not included in a subschema. The root MdmSchema contains dimension objects that are in subschemas as well as dimension objects that are not.
The root MdmSchema contains MdmMeasure objects only if they are not contained in a subschema. Because most MdmMeasure objects belong to a subschema, the root MdmSchema typically has no MdmMeasure objects. Therefore, the getMeasures method of the root MdmSchema typically returns an empty List object.
An MdmSchema has methods for getting all of the MdmMeasure, MdmPrimaryDimension, and MdmSchema objects that it contains. The root MdmSchema also has a method for getting the MdmMeasureDimension, whose elements are all of the MdmMeasure objects in the data store regardless of whether they belong to a subschema.
An MdmSource represents a measure, dimension, or other set of data (such as an attribute) that is used for analysis. MdmSource objects represent data, but they do not provide the ability to create queries on that data. Their function is informational, recording the existence, structure, and characteristics of the data. They do not give access to the data values.
To gain access to the data values for a given MdmSource, an application calls the getSource method of the MdmSource. This method returns a Source through which an application can create queries on the data represented by the MdmSource. The following line of code creates a Source from an MdmStandardDimension called mdmProductDim.
Source productDim = mdmProductDim.getSource();
A Source that is the result of the getSource method of an MdmSource is called a primary Source. An application derives new Source objects from this primary Source as it selects, calculates, and otherwise manipulates the data. Each new Source specifies a new query.
For more information about working with Source objects, see Chapter 6, " Understanding Source Objects". The rest of this chapter describes the subclasses of MdmSource.
MdmDimension is an subclass of MdmSource. The abstract MdmDimension class represents the general concept of a list of elements that can organize a set of data. For example, if you have a set of figures that are the prices of product items during month time periods, then the unit price data is represented by an MdmMeasure that is dimensioned by dimensions for time and product values. The time dimension includes the month values and the product dimension includes item values. The month and item values act as indexes for identifying each particular value in the set of unit price data.
An MdmDimension can have one or more MdmAttribute objects. An MdmAttribute maps the value of each element of the MdmDimension to a value representing some characteristic of the element value. To obtain the MdmAttribute objects for an MdmDimension, call its getAttributes method.
MdmDimension has the abstract subclasses MdmPrimaryDimension and MdmSubDimension.
MdmPrimaryDimension is an abstract subclass of MdmDimension. An MdmPrimaryDimension represents the dimensions defined by the database administrator in the OLAP Catalog. The concrete subclasses of the abstract MdmPrimaryDimension class represent different types of data. The concrete subclasses of MdmPrimaryDimension are the following:
MdmMeasureDimension, which has all of the MdmMeasure objects in the data store as the values of its elements. A data store has only one MdmMeasureDimension. You can obtain the MdmMeasureDimension by calling the getMeasureDimension method of the root MdmSchema and casting the result to an MdmMeasureDimension. You can get the measures of the data store by calling the getMeasures method of the MdmMeasureDimension.
MdmStandardDimension, which has no special characteristics, and which typically represent dimensions of products, customers, distribution channels, and so on.
MdmTimeDimension, which has time periods as the values of its elements. Each time period has an end date and a time span. An MdmTimeDimension has methods for getting the attributes that record that information.
An MdmPrimaryDimension has one or more component MdmHierarchy objects, which represent the hierarchies of the dimension. An MdmPrimaryDimension has all of the elements of its component MdmHierarchy objects, while each of its MdmHierarchy objects has only the elements in that hierarchy.
An MdmPrimaryDimension that represents a nonhierarchical list of elements has only one MdmLevelHierarchy, which has all of its elements at one level with no hierarchical relationships defined for them. For example, the MdmMeasureDimension represents a dimension that is simple list of the MdmMeasure objects in the data store. The MdmMeasureDimension has one MdmLevelHierarchy, which has one MdmLevel. The MdmMeasureDimension, its MdmLevelHierarchy, and its MdmLevel all have the same dimension elements, the values of which are the MdmMeasure objects.
MdmHierarchy is an abstract subclass of MdmSubDimension, which is an abstract subclass of MdmDimension. An MdmHierarchy represents an organization of the elements of an MdmPrimaryDimension, which can have more than one hierarchy defined for it. For example, an MdmTimeDimension dimension might have two hierarchies, one organized by calendar year time periods and the other organized by fiscal year time periods. The elements of both hierarchies are drawn from the elements of the MdmTimeDimension, but the number of elements in each hierarchy and the parent-child relationships of the values of the elements can be different.
The parent-child relationships of an MdmHierarchy are recorded in a parent MdmAttribute, which you can get by calling the getParentAttribute method of the MdmHierarchy. The ancestor-descendent relationships are specified in an ancestors MdmAttribute, which you can get by calling the getAncestorsAttribute method.
MdmLevelHierarchy is a concrete subclass of MdmHierarchy. An MdmLevelHierarchy has its parent-child relationships defined between the values of the elements at different levels. The different levels of an MdmLevelHierarchy are represented by MdmLevel objects. An MdmLevelHierarchy has a tree-like structure. The elements at the lowest level of the hierarchy are the leaves, and the elements at higher levels are nodes. Nodes have children; leaves do not.
The MdmLevelHierarchy has all of the elements of the hierarchy, and each of its component MdmLevel objects has only the elements at the level it represents. Each element, except those at the highest level, can have a parent, and each element, except those at the lowest level, can have one or more children. The parent and children of an element of an MdmLevel are in other MdmLevel objects. An MdmLevelHierarchy can also represent a nonhierarchical list of elements, in which case the MdmLevelHierarchy has one MdmLevel, and both objects have the same elements. You get the levels of an MdmLevelHierarchy by calling its getLevels method.
MdmValueHierarchy is the other concrete subclass of MdmHierarchy. An MdmValueHierarchy has parent-child relationships defined between the values of the dimension elements, and does not have the parent and child elements at different levels. An example of a value hierarchy is the employee reporting structure of a company, which can be represented with parent-child relationships but without levels. A database administrator defines a dimension as a value hierarchy in the OLAP Catalog. An application developer can define a value hierarchy with the createValueHierarchy method of an MdmCustomObjectFactory.
MdmLevel is a subclass of MdmSubDimension. An MdmLevel represents a list of elements that supply one level of the hierarchical structure of an MdmLevelHierarchy.
An MdmLevel represents a level that was specified by a database administrator in the OLAP Catalog. Typically, a database administrator specifies a column in a relational database table to provide the values of the level. The values of the elements of an MdmLevel must be unique. If the column in the database has values that are not unique, then the database administrator can define the elements of a level using two or more columns of the table, thus ensuring that the elements of the MdmLevel have unique values. For example, if a dimension of geographical locations has a level for cities and more than one city has the same name, then a database administrator can specify as the value of the city level both the city column and the state column in the relational database. The values of the elements in the MdmLevel for cities are then combinations of the two column values, such as IL:Springfield for Springfield, Illinois and MA:Springfield for Springfield, Massachusetts.
An MdmLevelHierarchy has one MdmLevel for each level of elements in the hierarchy of dimension elements that it represents. Each element of an MdmLevel, except the highest level, can have a parent, and each element, except those of the lowest level, can have one or more children. The parent and children of elements of one MdmLevel are elements from other MdmLevel objects.
Even though the elements of an MdmLevel have parent-child relationships, an MdmLevel is represented as a simple list. The parent-child relationships among the elements are recorded in the parent and ancestors attributes, which you can obtain by calling the getParentAttribute and getAncestorsAttribute methods of the MdmLevelHierarchy of which the MdmLevel is a component. You can get the MdmLevelHierarchy for the MdmLevel by calling the getLevelHierarchy method of the MdmLevel.
MdmMeasure is a subclass of MdmDimensionedObject, which is an abstract subclass of MdmSource.
An MdmMeasure represents a set of data that is organized by one or more MdmDimension objects. The structure of the data is similar to that of a multidimensional array. Like the dimensions of an array, which provide the indexes for identifying a specific cell in the array, the MdmDimension objects that organize an MdmMeasure provide the indexes for identifying a specific value of an element of the MdmMeasure.
For example, suppose you have an MdmMeasure for product units sold data, and the data is organized by dimensions for products, times, customers, and channels (with channel representing the sales avenue, such as catalog or internet.). You can think of the data as occupying a four-dimensional array with the products, times, customers, and channels dimensions providing the organizational structure. The values of these four dimensions are indexes for identifying each particular cell in the array, which contains a single units sold data value. You must specify a value for each dimension in order to identify a value in the array. In relational terms, the MdmDimension objects constitute a compound (that is, composite) primary key for the MdmMeasure.
The values of an MdmMeasure are usually numeric, but this is not necessary.
An MdmMeasure is based on an OLAP measure that was created by a database administrator in the OLAP Catalog or is created by an application developer using a method of an MdmCustomObjectFactory. In most cases, the MdmMeasure maps to a column in a fact table or to an expression that specifies a mathematical calculation or a data transformation. In many but not all cases, the MdmMeasure also maps to at least one hierarchy for each OLAP dimension of the measure, as well as an aggregation method. Oracle OLAP uses all of this information to identify the number of elements in the MdmMeasure and the value of each element.
The set of elements that are in an MdmMeasure is determined by the structure of its MdmDimension objects. That is, each element of an MdmMeasure is identified by a unique combination of elements from its MdmDimension objects.
The MdmDimension objects of an MdmMeasure are MdmStandardDimension or MdmTimeDimension objects. They usually have at least one hierarchical structure. Those MdmPrimaryDimension objects include all of the elements of their component MdmHierarchy objects. Because of this structure, the values of the elements of an MdmMeasure are of two kinds.
Values from the fact table column (or fact-table calculation) on which the MdmMeasure is based, as specified in the OLAP Catalog or the custom object. These values belong to MdmMeasure elements that are identified by a combination of values from the elements at the leaf level of an MdmHierarchy.
Aggregated values that Oracle OLAP has provided. These values belong to MdmMeasure elements that are identified by the value of at least one element from a node level of an MdmHierarchy.
As an example, imagine an MdmMeasure called mdmUnitCost that is dimensioned by an MdmTimeDimension called mdmTimeDim and an MdmStandardDimension of products called mdmProdDim. Each of the mdmTimeDim and the mdmProdDim objects has all of the leaf elements and node elements of the dimension it represents.
A unique combination of two elements, one from mdmTimeDim and one from mdmProdDim, identifies each mdmUnitCost element, and every possible combination is used to specify the entire mdmUnitCost element set.
Some mdmUnitCost elements are identified by a combination of leaf elements (for example, a particular product item and a particular month). Other mdmUnitCost elements are identified by a combination of node elements (for example, a particular product family and a particular quarter). Still other mdmUnitCost elements are identified by a mixture of leaf and node elements. The values of the mdmUnitCost elements that are identified only by leaf elements come directly from the column in the database fact table (or fact table calculation). They represent the lowest level of data. However, for the elements that are identified by at least one node element, Oracle OLAP provides the values. These higher-level values represent aggregated, or rolled-up, data.
Thus, the data represented by an MdmMeasure is a mixture of fact table data from the data store and aggregated data that Oracle OLAP makes available for analytical manipulation.
MdmAttribute is a subclass of MdmDimensionedObject, which is an abstract subclass of MdmSource.
An MdmAttribute represents a particular characteristic of the elements of an MdmDimension. An MdmAttribute maps one element of the MdmDimension to a particular value.
For example, mdmCustDim is an MdmPrimaryDimension for the CUSTOMER dimension, which represents a dimension of customers and is based on the columns of the GLOBAL.CUSTOMER_DIM table of a relational database. The MdmPrimaryDimension has a hierarchy that has levels that are based on shipment origination and destination values. One column in the customer table records a short value description for the customer identification value. The MdmAttribute returned by the getShortValueDescriptionAttribute method of mdmCustDim relates a short description to each the element of the dimension. The elements of the MdmAttribute have String values such as Computer Services Tokyo, Italy, and North America.
The values of an MdmAttribute might be String values (such as Italy), numeric values (such as 45), or objects (such as MdmLevel objects).
Like an MdmMeasure, an MdmAttribute has elements that are organized by its MdmDimension. Sometimes an MdmAttribute does not have a value for every element of its MdmDimension. For example, an MdmAttribute that records the name of a contact person might have values only for the SHIP_TO and WAREHOUSE levels of the SHIPMENTS_ROLLUP hierarchy of the CUSTOMER dimension, because contact information does not apply to the higher REGION and ALL_CUSTOMERS levels. If an MdmAttribute does not apply to an element of an MdmDimension, then the MdmAttribute element value for that element is null.
Some MdmAttribute objects provide a mapping that is one-to-many, rather than one-to-one. Therefore, a given element in an MdmDimension might map to a whole set of MdmAttribute elements. For example, the MdmAttribute that serves as the ancestors attribute for an MdmHierarchy maps each MdmHierarchy element to its set of ancestor MdmHierarchy elements.
Some attributes apply generally to the all of elements of an MdmPrimaryDimension. You can get the MdmAttribute objects for those attributes with the getAttributes method of the MdmPrimaryDimension. Other attributes relate only to an MdmHierarchy, such as the parent attribute, or an MdmLevelHierarchy, such as the level depth attribute. You get the MdmAttribute objects for those attributes with the getParentAttribute method of the MdmHierarchy or the getLevelDepthAttribute method of the MdmLevelHierarchy.
An MdmAttribute is based on an attribute that was specified for a dimension, hierarchy, or level by a database administrator in the OLAP Catalog or that was specified by an MtmValueExpression for a custom MdmAttribute created by an application.
The following table lists the values of elements of a Source object that represents the elements of a hierarchy of an MdmPrimaryDimension of products. The table also lists the values of the Source objects for two MdmAttribute objects that are dimensioned by the MdmPrimaryDimension. One attribute is the short description attribute for the dimension. Each element of the dimension has a related short description. The other is a custom attribute that relates a color to the values of elements at the ITEM level, which is the lowest level of the hierarchy. The values of the color MdmAttribute are null for the aggregate TOTAL_PRODUCT, CLASS, and FAMILY levels. In the table, null values appear as NA.
| Product Values | Related Short Descriptions | Related Colors |
|---|---|---|
PRODUCT_ROLLUP::TOTAL_PRODUCT::1 |
Total Product |
NA |
PRODUCT_ROLLUP::CLASS::2 |
Hardware |
NA |
PRODUCT_ROLLUP::FAMILY::4 |
Portable PCs |
NA |
PRODUCT_ROLLUP::ITEM::13 |
Envoy Standard |
Black |
PRODUCT_ROLLUP::ITEM::14 |
Envoy Executive |
Black |
PRODUCT_ROLLUP::ITEM::15 |
Envoy Ambassador |
Black |
PRODUCT_ROLLUP::FAMILY::5 |
Desktop PCs |
NA |
PRODUCT_ROLLUP::ITEM::16 |
Sentinel Standard |
Beige |
PRODUCT_ROLLUP::ITEM::17 |
Sentinel Financial |
Beige |
PRODUCT_ROLLUP::ITEM::18 |
Sentinel Multimedia |
Beige |
| ... | ... | ... |
All MdmSource objects have the following two basic characteristics:
Data type
Type
The concept of data type is a familiar one in computer languages and database technology. It is common to categorize data into types such as integer, Boolean, and String.
The OLAP API implements the concept of data type through the FundamentalMetadataObject and FundamentalMetadataProvider classes. Every data type recognized by the OLAP API is represented by a FundamentalMetadataObject, and you obtain this object by calling a method of a FundamentalMetadataProvider.
The following table lists the most familiar OLAP API data types. For each data type, the table presents a description of the FundamentalMetadataObject that represents the data type and the name of the method of FundamentalMetadataProvider that returns the object. The OLAP API data types appear in regular typeface, instead of monospace typeface, to distinguish them from java.lang data type classes.
In addition to these familiar data types, the OLAP API includes two generalized data types (which represent groups of the familiar data types) and two data types that represent the absence of values. The following table lists these additional data types.
When an MDM metadata object, such as an MdmMeasure, has a given data type, this means that each of its elements conforms to that data type. If the data type is numeric, then the elements also conform to the generalized Number data type, as well as to the specific data type (Double, Float, Integer, or Short). The elements of any MDM metadata object conform to the Value data type, as well as to their more specific data type, such as Integer or String.
If the elements of an object represent a mixture of several numeric and non-numeric data types, then the data type is only Value. The object has no data type that is more specific than that.
The MDM metadata objects for which data type is relevant are MdmSource objects, such as MdmMeasure, MdmLevelHierarchy, and MdmLevel. The typical data type of an MdmMeasure is one of the numeric data types; the typical data type of an MdmLevelHierarchy or MdmLevel is String.
If you have obtained an MdmSource from the data store, and you want to find the data type of its elements, then you call its getDataType method. This method returns a FundamentalMetadataObject.
To find the OLAP API data type that is represented by the returned FundamentalMetadataObject, you compare it to the FundamentalMetadataObject for each OLAP API data type. That is, you compare it to the return value of each of the data type methods in FundamentalMetadataProvider.
The following sample method returns a String that indicates the data type of the MdmSource that is passed in as a parameter. Note that this code creates a FundamentalMetadataProvider by calling a method of a DataProvider. Getting a DataProvider is described in Chapter 4, " Discovering the Available Metadata". The dp object is the DataProvider.
Example 2-1 Getting the Data Type of an MdmSource
public String getDataType(DataProvider dp, MdmSource metaSource)
{
String theDataType = null;
FundamentalMetadataProvider fmp =
dp.getFundamentalMetadataProvider();
if (fmp.getBooleanDataType() == metaSource.getDataType())
theDataType = "Boolean";
else if (fmp.getDateDataType() == metaSource.getDataType())
theDataType = "Date";
else if (fmp.getDoubleDataType() == metaSource.getDataType())
theDataType = "Double";
else if (fmp.getFloatDataType() == metaSource.getDataType())
theDataType = "Float";
else if (fmp.getIntegerDataType() == metaSource.getDataType())
theDataType = "Integer";
else if (fmp.getShortDataType() == metaSource.getDataType())
theDataType = "Short";
else if (fmp.getStringDataType() == metaSource.getDataType())
theDataType = "String";
else if (fmp.getNumberDataType() == metaSource.getDataType())
theDataType = "Number";
else if (fmp.getValueDataType() == metaSource.getDataType())
theDataType = "Value";
return theDataType;
}
An MDM metadata object, such as an MdmSource, is a collection of elements. Its type (as opposed to its data type) is another metadata object from which the metadata object draws its elements. In other words, the elements of a metadata object correspond to a subset of the elements in its type. There can be no element in the metadata object that does not match an element of its type.
Consider the following example of a MdmPrimaryDimension called mdmCustDim, which has the OLAP API data type of String. The mdmCustDim dimension has a hierarchy, which is an MdmLevelHierarchy object called mdmShipmentsRollup), which in turn has levels, which are MdmLevel objects. The MdmLevelHierarchy and the MdmLevel objects represent subsets of the elements of the MdmPrimaryDimension. In the following list, the hierarchy and the levels are indented under the MdmPrimaryDimension to which they belong.
mdmCustDim
mdmShipmentsRollup
mdmTotalCust
mdmRegion
mdmWarehouse
mdmShipTo
Because of the hierarchical structure, mdmWarehouse (for example) draws its elements from the elements of mdmShipmentsRollup. That is, the set of elements for mdmWarehouse corresponds to a subset of elements from mdmShipmentsRollup, and mdmShipmentsRollup is the type of mdmWarehouse.
Similarly, mdmShipmentsRollup is a component hierarchy of mdmCustDim. Therefore, mdmShipmentsRollup draws its elements from mdmCustDim, which is its type.
However, mdmCustDim is not a component of any other object. It represents the entire dimension. The pool of elements from which mdmCustDim draws its elements is the entire set of possible String values. Therefore, the type of mdmCustDim is the FundamentalMetadataObject that represents the OLAP API String data type. In the case of mdmCustDim, the type and the data type are the same.
The following list presents the types that are typical for the most common MdmSource objects:
The type of an MdmLevel is the MdmLevelHierarchy to which it belongs.
The type of a MdmHierarchy is the MdmPrimaryDimension to which it belongs.
The type of an MdmPrimaryDimension is the FundamentalMetadataObject that represents its OLAP API data type. Typically, this is the String data type.
The type of an MdmMeasure is the FundamentalMetadataObject that represents its OLAP API data type. Typically, this is one of the OLAP API numeric data types.
If you have obtained an MdmSource from the data store, and you want to find out its type, you call its getType method. This method returns the object that is the type of the MdmSource object.
For example, the following Java statement obtains the type of the MdmLevel named mdmWarehouse.
|
 Copyright © 2000, 2003 Oracle Corporation All Rights Reserved. |
|