|PREV PACKAGE NEXT PACKAGE||FRAMES NO FRAMES|
|CodedLevel||CodedLevel is a subclass of Level that assigns a unique encoding, or label, to each of its Dimension members.|
|ContentMap||ContentMap is a subclass of TransformationMap that maps CubeRegion attributes to their physical data sources.|
|Cube||A Cube is a collection of analytic values (i.e., measures) that share the same dimensionality.|
|CubeDeployment||CubeDeployment represents a particular implementation strategy for the data portions of an OLAP model.|
|CubeDeploymentOwnsContentMaps||A CubeDeployment owns any number of ContentMaps.|
|CubeDimensionAssociation||CubeDimensionAssociation relates a Cube to the Dimensions that define it.|
|CubeDimensionAssociationsReferenceCalcHierarchy||A CubeDimensionAssociation may designate a default Hierarchy for calculation purposes.|
|CubeDimensionAssociationsReferenceDimension||Each CubeDimenjsionAssociation references a single Dimension.|
|CubeOwnsCubeDimensionAssociations||The dimensionality of a Cube is defined by a collection of unique Dimensions.|
|CubeOwnsCubeRegions||A Cube may own any number of CubeRegions.|
|CubeRegion||CubeRegion models a sub-unit of a Cube of the same dimensionality as the Cube itself, with each Dimension optionally subsetted in its list of members.|
|CubeRegionOwnsCubeDeployments||A CubeRegion may own any number of CubeDeployments.|
|CubeRegionOwnsMemberSelectionGroups||A CubeRegion may own any number of MemberSelectionGroups.|
|DeploymentGroup||DeploymentGroup represents a logical grouping of model elements defining a single, complete deployment of an instance of Olap Schema (i.e., CubeDeployments and DimensionDeployments).|
|DeploymentGroupReferencesCubeDeployments||A DeploymentGroup may reference any number of CubeDeployments.|
|DeploymentGroupReferencesDimensionDeployments||A DeploymentGroup may reference any number of DimensionDeployments.|
|Dimension||A Dimension is an ordinate within a multidimensional structure, and consists of an ordered list of values (i.e., members) that share a common semantic meaning within the domain being modeled.|
|DimensionDeployment||DimensionDeployment represents a particular implementation strategy for the dimensional/hierarchical portions of an OLAP model.|
|DimensionDeploymentHasImmediateParent||An instance of DimensionDeployment may reference zero or one StructureMaps as its "immediate parent" StructureMap.|
|DimensionDeploymentHasListOfValues||An instance of DimensionDeployment may reference zero or one StructureMaps as its "list of values" StructureMap.|
|DimensionDeploymentOwnsStructureMaps||An instance of DimensionDeployment may own zero or more StructureMaps.|
|DimensionHasDefaultHierarchy||A Dimension may designate a default Hierarchy for display purposes.|
|DimensionOwnsHierarchies||A Dimension may own several Hierarchies.|
|DimensionOwnsMemberSelections||A Dimension may own any number of MemberSelections.|
|Hierarchy||A Hierarchy is an organizational structure that imposes a parent/child ordering on the members of the Dimension, usually to define either a navigational or consolidation/computational paths through the Dimension (i.e., a value associated with a child member is aggregated into one or more parents).|
|HierarchyLevelAssociation||HierarchyLevelAssociation is a class that orders Levels within a LevelBasedHierarchy, and provides a means of mapping Level/Hierarchy-oriented Dimension attributes to one or more physical deployments.|
|HierarchyLevelAssociationOwnsDimensionDeployments||A HierarchyLevelAssociation may own any number of DimensionDeployments.|
|HierarchyLevelAssocsReferenceLevel||Each HierarchyLevelAssoc references precisely one Level as its current level.|
|Level||Level is a subclass of MemberSelection that assigns each member of a Dimension to a specific hierarchical level within the Dimension.|
|LevelBasedHierarchy||A LevelBasedHierarchy is a hierarchy that describes relationships between specific levels of a Dimension.|
|LevelBasedHierarchyOwnsHierarchyLevelAssociations||A LevelBasedHierarchy generally owns one or more HierarchyLevelAssociations.|
|Measure||Measure is a subclass of Attribute representing Dimension Measures (e.g., Sales, Quantity, Weight).|
|MemberSelection||MemberSelection represents an arbitrary subset of the members of a Dimension.|
|MemberSelectionGroup||MemberSelectionGroup enables the grouping together of semantically-related MemberSelections.|
|MemberSelectionGroupReferencesMemberSelections||A MemberSelectionGroup references at least one unique MemberSelection.|
|Schema||Schema contains all elements comprising an OLAP model.|
|SchemaOwnsCubes||A Schema may own any number of Cubes.|
|SchemaOwnsDeploymentGroups||A Schema may own any number of DeploymentGroups.|
|SchemaOwnsDimensions||A Schema may own any number of Dimensions.|
|StructureMap||StructureMap is a subclass of TransformationMap that maps Dimension attributes to their physical data sources.|
|ValueBasedHierarchy||ValueBasedHierarchy is a subclass of Hierarchy that ranks Dimension members according to their relative distance from the root.|
|ValueBasedHierarchyOwnsDimensionDeployments||A ValueBasedHierarchy may own any number of DimensionDeployments.|
Online Analytical Processing (OLAP) is a class of analytic application software that exposes business data in a multidimensional format. This multidimensional format usually includes the consolidation of data drawn from multiple and diverse information sources. Unlike more traditionally structured representations (e.g., the tabular format of a relational database), the multidimensional orientation is a more natural expression of the way business enterprises view their strategic data. For example, an analyst might use an OLAP application to examine total sales revenue by product and geographic region over time, or, perhaps, compare sales margins for the same fiscal periods of two consecutive years. The ultimate objective of OLAP is the efficient construction of analytical models that transform raw business data into strategic business insight.
There are many ways to implement OLAP. Most OLAP systems are constructed using OLAP server tools that enable logical OLAP structures to be built on top of a variety of physical database systems, such as relational or native multidimensional databases. The following features are generally found in most OLAP systems:
OLAP applications integrate well into the data warehousing environment, because a data warehouse provides relatively clean and stable data stores to drive the OLAP application. These data stores are usually maintained in relational tables that can be read directly by OLAP tools or loaded into OLAP servers. These relational tables are often structured in a manner that reveals the inherent dimensionality of the data (such as the ubiquitous Star and Snowflake schemas). Also, the data transformation and mapping services provided by a data warehouse can be used to supply OLAP systems with both metadata and data. Transformation-related metadata can be used to track the lineage of consolidated OLAP data back to its various sources.
The primary objectives of the CWM OLAP package are:
The OLAP package depends on the following packages:
The major classes and associations of the OLAP metamodel are shown in Figure 14-1.
Schema is the logical container of all elements comprising an OLAP model. It is the root element of the model hierarchy and marks the entry point for navigating OLAP models.
A Schema contains Dimensions and Cubes. A Dimension is an ordinate within a multidimensional structure and consists of a list of unique values (i.e., members) that share a common semantic meaning within the domain being modeled. Each member designates a unique position along its ordinate.
A Cube is a collection of analytic values (i.e., measures) that share the same dimensionality. This dimensionality is specified by a set of unique Dimensions from the Schema. Each unique combination of members in the Cartesian product of the Cube's Dimensions identifies precisely one data cell within a multidimensional structure.
CubeDimensionAssociation relates a Cube to its defining Dimensions. Features relevant to Cube-Dimension relationships (e.g., calcHierarchy) are exposed by this class.
A Dimension has zero or more Hierarchies. A Hierarchy is an organizational structure that describes a traversal pattern through a Dimension, based on parent/child relationships between members of a Dimension. Hierarchies are used to define both navigational and consolidation/computational paths through the Dimension (i.e., a value associated with a child member is aggregated by one or more parents). For example, a Time Dimension with a base periodicity of days might have a Hierarchy specifying the consolidation of days into weeks, weeks into months, months into quarters, and quarters into years.
A specific Hierarchy may be designated as the default Hierarchy for display purposes (e.g., a user interface that displays the Dimension as a hierarchical tree of members). CubeDimensionAssociation can also identify a particular Hierarchy as the default Hierarchy for consolidation calculations performed on the Cube.
Dimensions and Hierarchies are described further in Section 13.3.3.
MemberSelection models mechanisms capable of partitioning a Dimension's collection of members. For example, consider a Geography Dimension with members representing cities, states, and regions. An OLAP client interested specifically in cities might define an instance of MemberSelection that extracts the city members.
CubeRegion models a sub-unit of a Cube that is of the same dimensionality as the Cube itself. Each "dimension" of a CubeRegion is represented by a MemberSelection of the corresponding Dimension of the Cube. Each MemberSelection may define some subset of its Dimension's members.
CubeRegions are used to implement Cubes. A Cube may be realized by a set of CubeRegions that map portions of the logical Cube to physical data sources. The MemberSelections defining CubeRegions can also be grouped together via MemberSelectionGroups, enabling the definition of CubeRegions with specific semantics. For example, one can specify a CubeRegion containing only the "input level" data cells of a Cube.
A CubeRegion may own any number of CubeDeployments. CubeDeployment is a metaclass that represents an implementation strategy for a multidimensional structure. The ordering of the CubeDeployment classes may optionally be given some implementation-specific meaning (e.g., desired order of selection of several possible deployment strategies, based on optimization considerations).
Figure 14-2 shows Dimension and Hierarchy, along with several other classes that model hierarchical structuring and deployment mappings:
The OLAP metamodel defines two special types of Dimension: Time and Measure.
A Time Dimension provides a means of representing time-series data within a multidimensional structure. The members of a Time Dimension usually define some base periodicity (e.g., days of the week). The implementation of a Time Dimension might provide support for advanced "time-intelligent" functionality, such as the ability to automatically convert between different periodicities and calendars.
The members of a Measure Dimension describe the meaning of the analytic values stored in each data cell of a multidimensional structure. For example, an OLAP application may define Sales, Quantity and Weight as its measures. In this case, each data cell within the Cube stores three values, with each value corresponding to one of the three measures. A measure may have an associated data type. For example, Sales might be of a monetary type, Quantity an integer, and Weight a real number.
The OLAP metamodel specifies two subclasses of Hierarchy: LevelBasedHierarchy and ValueBasedHierarchy.
LevelBasedHierarchy describes hierarchical relationships between specific levels of a Dimension. LevelBasedHierarchy is used to model both "pure level" hierarchies (e.g., dimension-level tables) and "mixed" hierarchies (i.e., levels plus linked nodes). Dimensional levels are modeled by the Level class, a subclass of MemberSelection that partitions a Dimension's members into disjoint subsets, each representing a distinct level.
For example, the Geography Dimension cited earlier contains members representing cities, states, and regions, such as "Stamford", "Connecticut", and "NorthEast". It might also contain a single member called "USA" representing all regions of the United States. Therefore, the Geography Dimension could have four Levels named "City", "State", "Region", and "ALL", respectively. Each Level specifies the subset of members belonging to it: All cities belong to the "City"; Level, all states belong to the "State" Level, all regions belong to the "Region" Level, and the single "USA" member belongs to the "ALL" Level.
When used in the definition of a consolidation path, the meaning of "level" is quite clear: Members occupying a given Level consolidate into the next higher Level (e.g., City rolls up into State, State into Region, and Region into ALL).
LevelBasedHierarchy contains an ordered collection of HierarchyLevelAssocations that defines the natural hierarchy of the Dimension. The ordering defines the hierarchical structure in top-down fashion (i.e., the "first" HierarchyLevelAssociation in the ordered collection represents the upper-most level of the dimensional hierarchy). A HierarchyLevelAssociation may own any number of DimensionDeployments. DimensionDeployment is a metaclass that represents an implementation strategy for hierarchical Dimensions. The ordering of the DimensionDeployment classes may optionally be given an implementation-specific meaning (e.g., desired order of selection of several possible deployment strategies, based on optimization considerations).
A ValueBasedHierarchy defines a hierarchical ordering of members in which the concept of level has little or no significance. Instead, the topological structure of the hierarchy conveys meaning. ValueBasedHierarchies are often used to model situations where members are classified or ranked according to their distance from a common root member (e.g., an organizational chart of a corporation). In this case, each member of the hierarchy has some specific "metric" or "value" associated it with it.
ValueBasedHierarchy can be used to model pure "linked node" hierarchies (e.g., asymmetric hierarchical graphs or parent-child tables).
As with LevelBasedHierarchy, ValueBasedHierarchy also has an ordered collection of DimensionDeployments, where the ordering semantics are left to implementations to define.
Figure 14-3 illustrates how classes of the OLAP metamodel inherit from the CWM Object Model. Two classes requiring further explanation are:
For additional information, see the CWM specification at http://www.cwmforum.org.
|PREV PACKAGE NEXT PACKAGE||FRAMES NO FRAMES|