Creating regular dimensions
Regular dimensions represent descriptive data that provides context for data modeled in measure dimensions.
A regular dimension contains descriptive and business key information and organizes the information in a hierarchy, from the highest level of granularity to the lowest. It usually has multiple levels and each level requires a key and a caption. If you do not have a single key for your level, it is recommended that you create one in a calculation.
Model regular dimensions are based on data source or model query subjects that are already defined in the model. You must define a business key and a string type caption for each level. When you verify the model, the absence of business keys and caption information is detected. Instead of joining model regular dimensions to measure dimensions, create joins on the underlying query subjects and create a scope relationship between the regular dimension and the measure dimension.
A regular dimension is broken into groups of information called levels. In turn, the various levels can be organized into hierarchies. For example, a product dimension can contain the levels Product Line, Product Type, and Product organized in a single hierarchy called Product. Another example is a time dimension that has the levels Year, Quarter, Month, Week, and Day, organized into two hierarchies. The one hierarchy YQMD contains the levels Year, Quarter, Month, and Day, and the other hierarchy YWD contains the levels Year, Week, and Day.
The simplest definition of a level consists of a business key and a caption, each of these
referring to one query item. An instance (or row) of a level is defined as a member of that level.
It is identified by a member unique name, which contains the values of the business keys of the
current and higher levels. For example,
[gosales].[Products].[ProductsOrg].[Product]->[All Products].[1].[1].[2]
identifies a member that is on the fourth level, Product
, of the hierarchy
ProductsOrg
of the dimension [Products]
that is in the namespace
[gosales]
. The caption for this product is TrailChef Canteen, which is the name
shown in the metadata tree and on the report.
The level can be defined as unique if the business key of the level is sufficient to identify each set of data for a level. In the Great Outdoors Sales model, the members of the Product level do not require the definition of Product type because there are no product numbers assigned to many different product types. A level that is not defined as unique is similar to a determinant that uses multiple-part keys because keys from higher levels of granularity are required. See Using determinants with multiple-part keys. If members within ancestor members are not unique but the level is defined as unique, data for the non-unique members is reported as a single member. For example, if City is defined as unique and identified by name, data for London, England and London, Canada will be combined.
Procedure
Results
