Problem

Dimensions are a very important component of an OLAP Solution/Cube in SQL Server Analysis Services. Hence it is good to have a fair amount of knowledge/understanding on the Dimensions, its properties, and its sub components like Attributes, Hierarchies etc.

Solution
In the first tip of this series, I covered some of the Questions on Basic Concepts, Data Sources, and Data Source Views in SQL Server Analysis Services. And in the second tip, I covered some of the Questions on General Dimension Concepts and Types of Dimensions. In this third tip, I will be covering some of the questions on Dimensions, its properties, and its components like Attributes, Hierarchies etc. within SQL Server Analysis Services.

What are Database Dimension and Cube Dimension? What is the difference between them?
A Database Dimension is a Dimension which exists independent of a Cube. You can see a Database Dimension as a separate entity/file in the Solution Explorer/Project Folder. An analogy, this is pretty similar to a Class in a Programming Language. A Cube Dimension is an Instance of a Database Dimension. An analogy, this is pretty similar to an Object (Instance of a Class) in a Programming Language. Here are some of the highlights/differences of Database and Cube Dimensions:

A Database Dimension is independent of a Cube, but a Cube Dimension is always a part of a Cube. One Database Dimension can be added to a Cube more than once (Role-Playing Dimension) as different instances. In this scenario, each Instance is treated as a separate Cube Dimension. A Database Dimension can be added to more than one Cube, whereas a Cube Dimension can belong to a Single Cube at any given point.

What is a Linked Dimension? In what scenarios do you use it?

A Linked Dimension is a Dimension which is based on (Linked To) another Database Dimension which might be either located on the same Analysis Services server as the Linked Dimension or on a different Analysis Services server. Linked Dimensions can be used when the exact same dimension can be used across multiple Cubes within an Organization like a Time Dimension, Geography Dimension etc. Here are some of the highlights of a Linked Dimension:

More than one Linked Dimension can be created from a Single Database Dimension. These can be used to implement the concept of Conformed Dimensions. For an end user, a Linked Dimension appears like any other Dimension.

What are the different ways to create a Time Dimension in Analysis Services?
Time Dimension is one of the most important and most common type of dimensions as pretty much every metric is analyzed over time. Analysis Services offers following different ways to create a Time Dimension:

Create Using an Existing Table: This is one of the common approaches for building a Time Dimension. In this approach, a table is created in the underlying data source and pre-populated with data and it is then used to create the Time Dimension in SSAS. Generate a Time Table in the Data Source: In this approach there will be no underlying table and at the time of creation of a Time Dimension in SSAS, Analysis Services creates a table in the underlying data source (relational database) and populates it with the required data using the date range, attributes, and calendars etc. which are specified at the time of creation of Time Dimension in

Business Intelligence Development Studio. This option requires permissions to create a table in the underlying data source. Generate a Time Table on the Server: In this approach there will be no underlying table and at the time of creation of a Time Dimension in SSAS, Analysis Services creates a table on the server and this table is used to generate the Time Dimension by the wizard. The Dimension created using this approach is called a Server Time Dimension.

What is Type property of a Dimension? What is the purpose of setting this property?
Type property of a Dimension is used to specify the type of information that the Analysis Services Dimension contains. Like a Time Dimension (Contains Years, Quarters, Months, Dates, and so on), Geography Dimension (Contains Geographical Information), and Accounts Dimension (Contains Accounts related information) etc. This property is set to Regular by default. There are basically two important uses of setting this property:

This property is used by the Business Intelligence Wizard to assign/generate standard classification/MDXexpressions. This property is used by the Analysis Services Client Applications like Excel etc. to adjust the user interface/rendering format appropriately. For example, when a dimension is added to a Pivot Table in Excel, certain types of dimensions are automatically added across the columns axis (like Time Dimension) and a few other types of dimensions are added to the rows axis (Like Product Dimension) automatically.

What is a Storage Mode? What are the different storage modes applicable to Dimensions?
A Storage Mode defines the location in which the Dimension data will be stored and the format (Relational or Multidimensional) in which the data will be stored. Following are the two Storage Modes supported by Dimensions:

ROLAP (Relational On-Line Analytical Processing): o When the Storage Mode is set to ROLAP for a Dimension, then the Dimension Data will be stored in the relational database tables. o This storage Mode offers effective memory usage by avoiding duplication of data compared to MOLAP Storage Mode. o Using this Storage Mode will result in a slowdown in the query performance compared to MOLAP Storage Mode. MOLAP (Multidimensional On-Line Analytical Processing): o When the Storage Mode is set to MOLAP for a Dimension, then the Dimension Data will be stored in a multidimensional format in the Analysis Services/OLAP Server. o This Storage Mode offers poor memory usage as it involves duplication of data (first copy is the data in the underlying dimensional tables and the second copy is the data in the Dimension in the OLAP Server). o Using this Storage Mode will result in best query performance compared to any other Storage Modes available in SSAS.

What is the difference between Attribute Hierarchy and User Defined Hierarchy?
An Attribute Hierarchy is a Hierarchy created by SQL Server Analysis Services for every Attribute in a Dimension by default. An Attribute by default contains only two levels - An "All" level and a "Detail" level which is nothing but the Dimension Members. A User Defined Hierarchy is a Hierarchy defined explicitly by the user/developer and often contains multiple levels. For example, a Calendar Hierarchy contains Year, Quarter, Month, and Date as its levels. Here are some of the highlights/differences of Attribute and User Defined Hierarchies:

Attribute Hierarchies are always Two-Level (Unless All Level is suppressed) whereas User Defined Hierarchies are often Multi-Level.

By default, Every Attribute in a Dimension has an Attribute Hierarchy whereas User Defined Hierarchies have to be explicitly defined by the user/developer. Every Dimension has at least one Attribute Hierarchy by default whereas every Dimension does not necessarily contain a User Defined Hierarchy. In essence, a Dimension can contain zero, one, or more User Defined Hierarchies. Attribute Hierarchies can be enabled or disabled. An Attribute Hierarchy for an Attribute which is part of a User Defined Hierarchy can be disabled as the Attribute will still be accessible through the User Defined Hierarchy.

What is an Attribute Relationship? What are the different types of Attribute Relationships?
An Attribute Relationship is a relationship between various attributes within a Dimension. By default, every Attribute in a Dimension is related to the Key Attribute. Quite often these default Attribute Relationships need to be modified to suit the User Defined Hierarchies and other end user requirements. There are basically two types of Attribute Relationships:

Rigid: Attribute Relationship should be set to Rigid when the relationship between those attributes is not going to change over time. For example, relationship between a Month and a Date is Rigid since a particular Date always belongs to a particular Month like 1st Feb 2012 always belongs to Feb Month of 2012. Try to set the relationship to Rigid wherever possible. Flexible: Attribute Relationship should be set to Flexible when the relationship between those attributes is going to change over time. For example, relationship between an Employee and a Manager is Flexible since a particular Employee might work under one manager during this year (time period) and under a different manager during next year (another time period).

What are KeyColumns and NameColumn properties of an Attribute? What is the different between them?
KeyColumns is a property of an SSAS Dimension Attribute and it forms the Key (Unique) for the attribute. It can be bound to one or more columns in the underlying database table. When User Defined Hierarchies are created in the dimension (Attribute Relationships defined), setting this property becomes very critical and often requires setting this to a combination of more than one column from the Data Source View. For Example, say you have a Date Dimension and a hierarchy called Calendar Hierarchy (Year -> Quarter -> Month). Now what happens is that, Month gets repeated across different quarters and quarters get repeated across different years making the attribute as non-unique (like January can belong to Q1 of any year and similar Q1 can belong to any year). So to make the attribute unique, KeyColumns for Month should be set to something like Year and Month and similarly for Quarter should be set to Year and Quarter. A NameColumn is a property of an SSAS Dimension Attribute and it is used to identify the column from the underlying Data Source View which provides the name of the attribute which is displayed to the end user by making it more user friendly instead of displaying the Key Column value. For Example, you might have ProductCategoryKey as 1, 2, 3, & 4, and ProductCategoryName as Bikes, Components, Clothing, & Accessories respectively. Now, NameColumn will be set to ProductCategoryName so that user sees them as Bikes, Components etc. even though the data in the background is processed/retrieved using the Key Column values as 1, 2 etc. Here are some of the highlights/differences of KeyColumns and NameColumn properties:

KeyColumns property is defaulted to the Attribute itself, and the NameColumn property is defaulted to Key Column (when the KeyColumns is set to only one column). Column(s) provided in the KeyColumns should be able to uniquely identify all the values of the respective attribute, whereas NameColumn need not be unique. KeyColumns can contain one or more columns whereas NameColumn can contain only one column.

What is an Unknown Member? What is its significance?

An Unknown Member is a built-in member provided by SQL Server Analysis Services. It represents a Missing or Null value. Basically when a Dimension is Processed, Analysis Services populates each of the attributes with distinct values from the underlying data source and in this process, if it encounters Null value then it converts them appropriately (to 0 in case of numeric columns and to empty string in case of string columns) and marks them as Unknown Member for easy interpretation by the end user.

One of the important uses of an Unknown Member is to handle Early Arriving Facts. This is a scenario, in which the transactional record (Fact) would have come into the system but the corresponding Dimension/Contextual data is yet to come in which could be due to various reasons like Improperly Designed Data Load Process, Failure in the ETL Process, and a Technical Glitch in the transactional system causing delay in pushing the Dimension Data. Unknown Member can be enabled or disabled (set to None) or set to Visible or Hidden based on the end user requirements.

What are Dimension Translations? In what scenarios do you use them?

Translation in SSAS is a mechanism to support Localization, in which the labels, names, and captions associated with any SSAS Object (pretty much every SSAS Object supports Translations) are translated from one language to another language based on the country/language of the user accessing the data. A Dimension Translation is same as Translation in SSAS, but in this case the labels, names, and captions associated with Dimensions, Attributes, Hierarchies, and/or Dimension Members are translated from one language to another language. Translations are very useful in achieving higher level of adoption of the BI/Analytics system (SSAS). This will eliminate the language barriers among users from different locations/languages and presents the same information in different languages making single version of truth available to users across different geographical locations. Here are some of the highlights of Dimension Translations:

There can be multiple Translations associated with a single Dimension, Attribute, Hierarchy, and Dimension Member etc. The collation and language settings/information from the client application/computer is used to determine and provide the analysis services metadata/data to the client application.

Problem
Data Warehousing (DW) and OLAP are very vast areas and are very essential areas when it comes to supporting critical business decisions. It is important to have a good understanding of the subject before attending an interview in the DW/OLAP space. Hence it is essential to understand all the major components with each one in as much detail as possible. Dimensions being one of the major aspects of OLAP/SSAS, it is good to understand some basic Dimension Concepts and Types of Dimensions, which we will outline in this tip.

Solution
In the previous tip, I have covered some of the questions on Basic Concepts, Data Sources, and Data Source Views in SQL Server Analysis Services. In this tip, I will be covering some of the basic Dimension Concepts and will discuss some of the most common types of dimensions.

What is a SQL Server Analysis Services Dimension?

A Dimension represents a set of contextual data about the transactional data that is stored in the fact table(s). It basically forms the story line around the data by providing context and thereby helping the users to understand and make sense out of the data. Example: Let us say that there is a retail chain and the CFO of the chain announces that the "Total Sales is $10,00,000". In this case, $10,00,000 is merely a number and does not provide any valuable information and does not make any sense to the user. Now let us say that the CFO of the chain makes a slight change in the above announcement and says "Total Sales for FY 2012 is $10,00,000". This makes some sense and provides some amount of context which in this case is sales amount mentioned is for Financial Year 2012 (FY2012). FY2012 represents a date (time) component and hence it represents a Date (Time) Dimension. Similarly, we can go on and add additional Dimensions to this data (Fact Table/Cube) to provide more context about the data (in this scenario $10,00,000 is the data we are talking about). Say we change the above statement to something like "Total Sales of Facial Tissues for FY 2012 in California is $10,00,000". This gives

much better context compared to the previous two statements. In this statement, Facial Tissues represents a Product which introduces us to Product Dimension and California represents a Geographical Location which introduces us to Geography Dimension. In this manner, we can add as many dimensions as we want, to give better context to the data, so that end users can analyze the data from different dimensions and take more effective decisions. Here are some highlights of Dimension(s):

It represents contextual information which adds context/meaning to the data being analyzed. Helps in viewing/analyzing the data from different dimensions/angles to get a better understanding of the data. A dimension is organized in the form of Attributes and Hierarchies. Here are some examples of a Dimension: o Time Dimension o Product Dimension o Geography Dimension o Customer Dimension o Employee Dimension Here are some examples of a Dimension Attribute o Year, Quarter, Month etc. in case of a Time Dimension o Color, Size etc. in case of a Product Dimension

What are Natural Key and Surrogate Key in SQL Server Analysis Services?
A Natural Key is a type of key in a table which uniquely identifies each record and has a business meaning attached to it. Example: Incident/Ticket Number, SSN, Employee Email Alias, etc. Here are some highlights of a Natural Key:

This can be numeric, string, a combination of both etc. depending on the type of data you are dealing with. In case of non-numeric data, JOINs are slower and occupies more space than an integer. History cannot be maintained if used as a Primary Key. Merging data from different source systems can be difficult when there is a conflict in the type of value coming from each source system.

A Surrogate Key is a type of key in a table which uniquely identifies each record, but has no business meaning attached to it. It is merely a value used to uniquely identify a record in a table. Example: Identity Columns, GUID (Unique identifier), etc. Here are some highlights of a Surrogate Key:

Most of the times this is a numeric value (like INT, BIGINT, etc.) and hence the JOINs are faster and occupies less space than character based data. Allows for maintenance of history data (SCD Type 2) when used as a Primary Key. Data coming from multiple source systems can be easily integrated (especially in the scenarios like Mergers, Acquisitions etc. in the industry).

What is a Hierarchy in SQL Server Analysis Services? What are the different types of Hierarchies? Explain each one of them.
A Hierarchy is a collection of one or more related Attributes which are organized in a Parent-Child fashion. An Attribute at a higher level is a parent of an Attribute at the next level and so on. They provide a very convenient way to perform roll up/drill down analysis and helps in rolling up and drilling down the numeric data in a very effective manner. In analogy, it is like your Bing maps. If you want to locate a particular place and if you want to do it manually (without doing a text search) then you usually first locate the Country, then locate the State within the Country, after that locate the City within the State, and finally locate the place you are looking for within the City.

Example: A Calendar Hierarchy might contain Attributes like Year, Quarter, Month, and Day which are organized as a Hierarchy with Year as a parent of Quarter, Quarter as a parent of Month, and Month as a parent of Day. Here are the common types of Hierarchies:

Natural Hierarchy: A Natural Hierarchy is a Hierarchy in which Every Child has a Single Parent. Example: A Calendar Hierarchy. Balanced Hierarchy: A Balanced Hierarchy is a Hierarchy in which no matter through what path we traverse the Hierarchy, there is a Member at every level and every path has the same number of Levels. Example: A Calendar Hierarchy. Unbalanced Hierarchy: An Unbalanced Hierarchy is a Hierarchy in which number of members and number of Levels varies across different branches of the Hierarchy. In this type of a Hierarchy, Leaf Level Members might belong to different Levels. Example: An Employee/Organization Hierarchy where in say 1 manager (Manager 1) has 2 or more people reporting to him and who belong to different Levels say L1 & L2. On the other hand say there is another manager (at the same level as Manager 1) who has 2 or more people reporting to him and all of them belonging to the same Level say L1. Ragged Hierarchy: A Ragged Hierarchy is a Hierarchy in which irrespective of the path you use to traverse, every path has the same number of Levels but not every level is guaranteed to have members except for the Top most Level and Bottom most Level (Leaf Level). Example: A Geography Hierarchy.

What is a Slowly Changing Dimension in SQL Server Analysis Services? What are the different types of Slowly Changing Dimensions?
The Slowly Changing Dimension (SCD) concept is basically about how the data modifications are absorbed and maintained in a Dimension Table. In an SCD the contents/members change over a period of time. Apart from the existing members which are modified, new records are added to the dimension similar to any other dimension. Here are the major 3 types of Slowly Changing Dimensions:

Type 1: In this type of SCD, modifications to the dimension members are absorbed by overwriting the existing member data present in the Dimension Table. Example: Say you have an Address Dimension which contains addresses of all the employees in an organization. When the address of an employee changes, then the old data (address) in the Dimension is overwritten with the new data (address) and there is no way to get the old address from the table. Type 2: In this type of SCD, modifications to the dimension members are absorbed by adding it as a new record into the Dimension Table. Meaning, the history of all the changes happening to the dimension members is maintained by creating a new record each time a dimension member is modified. The new (modified) record and the old record(s) are identified using some kind of a flag like say IsActive, IsDeleted etc. or using Start and End Date fields to indicate the validity of the record. New dimension members are inserted into the Dimension Table with appropriate flag value which indicates that this is the active/current record. Unlimited amount of history can be maintained in this type of SCD. Example: Considering the above example of an Address Dimension. When the address of an employee changes, then the old data (address) in the Dimension Table is retained as it is and the flag is updated to indicate that this is a historical record. The modified data (record) is inserted as a new record into the table and the flag is updated to indicate that this is the current record. Type 3: In this type of SCD, modifications to the dimension members are absorbed with the help of additional columns in the Dimension Table. In this SCD type, the amount of history data (number of modifications) that can be maintained is limited by the number of columns (fixed) in the Dimension Table, which are used for tracking the history details. This is decided at the time of designing the Data Mart. Example: Considering the above example of an Address Dimension. When the address of an employee changes, then the old data (address) in the Dimension is retained as it is and the new address is updated in a separate column to indicate that this is the latest address.

Apart from the above listed 3 types of SCDs, there are other types like Type 0, Type 4, Type 5, & Type 6 etc. which are used rarely.

What is a Parent-Child Dimension in SQL Server Analysis Services? Explain with an example.
A Parent-Child Dimension is a Dimension in which two attributes in the same dimension are related to each other and they together define the linear relationship among the dimension members. The first attribute which

uniquely identifies each dimension member is called the Member Key Attribute and the second attribute which identifies the parent of a dimension member is called a Parent Key Attribute. Example: Consider an Employee Dimension which has EmployeeID as a Primary/Unique Key which uniquely identifies each Employee in the organization. The same Employee Dimension contains another attribute as ManagerID which identifies the Manager of an Employee and ManagerID contains one of the values present in the EmployeeID since Manager is also an Employee, hence he/she also has a record for self in the Employee Table. In this scenario, EmployeeID is the Member Key Column and ManagerID is the Parent Key Column. Here are some highlights of a Parent-Child Dimension:

Both the Parent and the Child members exist in the same dimension. There is a Parent-Child relationship between different members (rows) of the same dimension. Parent Key Column in the dimension table is a Foreign Key Column (Can be physical or logical) which refers to the Member Key Column which is a Primary/Unique Key Column in the same dimension table.

What is a Role-Playing Dimension in SQL Server Analysis Services? Explain with an example.
A Role-Playing Dimension is a Dimension which is connected to the same Fact Table multiple times using different Foreign Keys. This helps the users to visualize the same cube data in different contexts/angles to get a better understanding and make better decisions. Example: Consider a Time Dimension which is joined to the same Fact Table (Say FactSales) multiple times, each time using a different Foreign Key in the Fact Table like Order Date, Due Date, Ship Date, Delivery Date, etc. Essentially there is only one single physical dimension called Date Dimension. However, it is joined multiple times to the Fact Table to help the users to visualize the cube data in the context of different dates. Here are some highlights of a Role-Playing Dimension:

It is a single physical Dimension Table. Same Dimension Table connects to the same Fact Table multiple times using different Foreign Keys from the Fact Table. When a Role-Playing Dimension is added to the cube, it appears as a different dimension (one instance for each Foreign Key to which it is joined) to the end users and hence playing multiple roles.

What is a Conformed Dimension in SQL Server Analysis Services? Explain with an example.
A Conformed Dimension is a Dimension which connects to multiple Fact Tables across one or more Data Marts (cubes). A Confirmed Dimension is physically implemented across multiple Data Marts with exactly the same structure, attributes, values (dimension members), meaning and definition. Each instance means exactly the same thing providing the exact same context irrespective of the Fact Table to which it is connected or the Data Mart to which it belongs. Example: A Date Dimension has exactly the same set of attributes, same members and same meaning irrespective of which Fact Table it is connected to or to which Data Mart it belongs to as long as it belongs to the same organization. For instance, a Fiscal Calendar is exactly the same with same start and end dates across all the departments within an organization. Here are some highlights of Conformed Dimensions:

Same Dimension joins to multiple Fact Tables or is used across multiple Data Marts. It is a master dimension and is used across multiple dimensional models. Each instance of Conformed Dimensions are exactly the same in every aspect including the attribute names, definitions, etc.

What is a Degenerate Dimension in SQL Server Analysis Services? In what scenarios do you use it?

A Degenerate Dimension is a Dimension which is derived out of a Fact Table and it appears to the end user as a separate/distinct Dimension, its data is actually stored in the Fact Table. It's a Dimension table which does not have an underlying physical table of its own. Degenerate Dimensions are commonly used when the Fact Table contains/represents Transactional data like Order Details, etc. and each Order has an Order Number associated with it, which forms the unique value in the Degenerate Dimension. Example: Degenerate Dimensions having unique Order Numbers can be used to identify the various items sold as part of a particular order. Here are some highlights of Degenerate Dimension:

It is derived from the Fact Table and does not have an underlying physical Dimension Table of its own. It is also called as a Fact Dimension. Since these dimensions are built on top of Fact Table, these are usually very large dimensions. The attribute of a Degenerate Dimension is not a Foreign Key in the Fact Table.

What is a Junk Dimension in SQL Server Analysis Services? In what scenarios do you use it?
A Junk Dimension is often a collection of Unrelated Attributes like indicators, flags, codes, etc. This Dimension usually contains data which cannot be created as a separate Dimension as they tend to be too small (often) and are not worth having a separate Dimension. These Dimensions can be used in various scenarios, but one of the common scenarios is when a Fact Table contains a lot of Attributes which are like indicators, flags, etc. Using Junk Dimensions, such Attributes can be removed/cleaned up from a Fact Table. Example: It contains values like Yes/No, Pending/In Progress/Completed, Open/Resolved/Closed, etc. Here are some highlights of a Junk Dimension:

It is also called as a Garbage Dimension. Junk Dimensions are usually small in size. It is a convenient way to consolidate many Smaller Dimensions which are not really worth having as a separate Dimension.