The OLAP Procedure

Understanding Shared Dimensions

Overview

Shared dimensions are dimensions that are used by multiple cubes. They are advantageous because they enable you to define the dimension once, rather than redefine the dimension for every cube that uses it. A shared dimension can be updated once, and all affected cubes can be made aware of the change. This saves both processing time to build the dimension and disk space that is used to store the member information.

Here are some of the features of using a shared dimension:

Shared dimensions can be defined once and then referenced by multiple cubes.
Identifying which cubes reference a given dimension is easy.
A shared dimension can be updated in one place, and all cubes that reference it are made aware of the change.
Cubes can include both shared and private dimensions.
Cubes referencing shared dimensions can remain online as new members are added to the dimension.
You can query the shared dimension for its member structure without having it be part of a cube.

Using shared dimensions enables an enterprise to have a common definition for a dimension that all cubes in the enterprise can use. This provides consistency across the enterprise with a level of transparency that maximizes efficiency.

Shared dimensions do not support multiple languages.

Functionality

A shared dimension is defined in PROC OLAP or in SAS OLAP Cube Studio. The definition includes all hierarchies, all levels, and all member properties known to the dimension. The data source for a shared dimension is a single dimension table (or a view of multiple physical tables).

Use of shared dimensions is governed by the following functionality rules:

A shared dimension can be referenced only in a star schema or in a hybrid star schema load.
Shared dimensions are grouped together in an OLAP schema, just as cubes are. However, a cube can reference a shared dimension in a different OLAP schema.
When a shared dimension is defined, all hierarchy member trees, caption files, and property files are built. Cubes that use the shared dimension reference these files directly, both to build the cube and during query processing. It is also possible to define the metadata and build the physical files later.

Effective use of shared dimensions relies on the ability to take advantage of OLAP features such as dimension updates, dimension deletions, multiple language services, and security and authorization rules. The following table describes each of these features with respect to shared dimensions.

OLAP Feature	Shared Dimension Description
Dimension Update	Updates to a shared dimension include the following: new members within the existing structure changes to the existing structure additional hierarchies and levels reorganization of member ordinals The level of change required in existing cubes referencing the dimension depends on what type of update is made. For example, new members in the dimension without new data in a fact table do not require updates to the cube aggregations. Changes to the existing structure and additional hierarchies and levels not included in the cube's definition require that the entire cube be rebuilt, as is currently the case for such updates in SAS OLAP Cube Studio. Level reorganization requires that the cube aggregations be rebuilt.
Dimension Deletion	When a cube is deleted, the files associated with any shared dimensions are not deleted. The metadata definition for the dimension is updated to indicate that the cube is no longer using the dimension. PROC OLAP syntax and windows in SAS OLAP Cube Studio enable dimension deletion. If existing cubes are still referencing the shared dimension, the dimension deletion is not permitted. The referencing cubes must be deleted first (the procedure displays the names of all affected cubes). To remove the physical files for a shared dimension (that is, DELETE_PHYSICAL), the physical files for all cubes referencing that shared dimension must also be removed. It is not necessary that the cubes be completely deleted, but a DELETE_PHYSICAL must be run against those cubes before it can be run against the shared dimension.
Security and Authorization	Because there is only one metadata registration for shared dimensions and because permissions are added to the metadata, then permissions applied to a shared dimension apply to all cubes using that dimension. Permissions on a shared dimension are inherited from its folder. Changes to the permissions are applied to all cubes using that dimension as well. This reduces the burden on the administrator when applying security for a site. For example, if a particular set of users is not allowed to see data for the members in a particular geographic area such as Canada, it would make sense that those users should see a consistent view (no Canadian data) across all cubes to which they have access. The administrator would still be able to deny access to an entire cube, which would override any permissions set on a shared dimension for that cube. Authorizations on a shared dimension are set in either SAS Management Console or SAS OLAP Cube Studio.