OLE DB for OLAP provides interfaces and methods for providers to expose schemas and consumers to view schemas. OLE DB for OLAP does not mandate that MDPs expose the schema objects defined in this specification; rather, it simply provides a way for schema objects to be exposed if the MDP chooses to support them.
OLE DB for OLAP provides interfaces that enable users to browse a set of metadata objects. Most providers expose a subset of all OLE DB for OLAP metadata objects.
The central metadata object recognized by OLE DB for OLAP is the cube. This is a set of related dimensions, which defines an n-dimensional manifold. The data points of interest are the points in this manifold and each such point is uniquely identified by a set of coordinates. Each coordinate is a member of one component dimension. For example, SalesData is a cube with five dimensions: Salesperson, Geography, Time, Measures, and Products.
Note OLE DB for OLAP handles the Measures dimension in the same way that it handles all other dimensions, so there is complete symmetry between dimensions and measures.
A schema is composed of a set of cubes. As in the relational case, the main purpose of a schema is to impose high-level authorization policies. A set of schemas is grouped together into a catalog. Just because there are catalogs and schemas, a provider doesn’t have to support this two-level grouping system. It may support catalogs only, schemas only, both, or neither.
A cube has a set of dimensions. Each dimension consists of a set of members. The members of a dimension can be consolidated or aggregated along a hierarchy. Some dimensions can have more than one hierarchy. This means that members can aggregate, or “roll up,” in multiple ways. Each hierarchy has levels, and each level is made up of a set of members.
For example, consider the SalesData cube mentioned previously. The Geography dimension has the following set of members (consider just two continents for simplicity):
{All, Europe, North America, Canada, Germany, UK, USA, Canada-East, Canada-West, England, Germany-North, Germany-South, Ireland, Scotland, USA-NE, USA-SE, USA-NW, USA-SW, Wales, Belfast, Berlin, Boise, Boston, Calgary, Cardiff, Cookstown, Dover, Edinburgh, Glasgow, Hamburg, Houston, LA, London, Miami, Munich, New York, Ottawa, Pembroke, Seattle, Shreveport, Stuttgart, Toronto, Vancouver}
There exists a natural hierarchy in this dimension, as below:
The World
Continents
Countries
Regions
Cities
Each of these categories is a level. Each level has a list of members associated with it as follows:
Members at the leaf level have no children, and member(s) at the root level have no parents. All other members have at least one parent and at least one child. For example, a partial traversal of the hierarchy tree in the Geography dimension yields the following parent-child relationships:
{All} (parent of) {Europe, North America}
{North America} (parent of) {Canada ,USA}
{USA} (parent of) {USA-NE, USA-NW, USA-SE, USA-SW}
{USA-NW} (parent of) {Boise, Seattle}
To see the need for multiple simultaneous hierarchies, consider the Time dimension of the SalesData cube. There are two ways to roll up to the Year level from the Days level, as follows:
Year
Quarter
Month
Day of Month
or
Year
Week
Day of the Week
This example also illustrates another characteristic: Some members of the Week level of the Year-Week hierarchy do not appear in any level of the Year-Quarter hierarchy. Thus, a hierarchy need not include all members of a dimension. However, if there is just a single hierarchy in a dimension, it is common for all members of the dimension to be included in the hierarchy.
The final concept is properties. In a Salesperson dimension, there is usually a need to store additional data about each salesperson — data such as “Address” or “Phone Number.” This additional information is called a property. Each level of a hierarchy tends to have a different set of properties, but all members in a given level have the same set of properties. For example, consider the Geography dimension. Each city can have the properties NUMBER_OF_RETAIL_OUTLETS, WAREHOUSE_NAME, and SALESREP, but these properties may not apply at the Region level. Instead, a region might have properties such as REGIONAL_MANAGER and IMPORT_POINT.