In this tip I will cover SSAS Interview Questions on Basic Concepts, Data Sources, and Data

Source Views.
What is SQL Server Analysis Services (SSAS)?

SQL Server Analysis Services (SSAS) is the On-Line Analytical Processing (OLAP)
Component of SQL Server. SSAS allows you to build multidimensional structures
called Cubes to pre-calculate and store complex aggregations, and also to build
mining models to perform data analysis to identify valuable information like trends,
patterns, relationships etc. within the data using Data Mining capabilities of SSAS,
which otherwise could be really difficult to determine without Data Mining
capabilities.

SSAS comes bundled with SQL Server and you get to choose whether or not to install
this component as part of the SQL Server Installation.

What is OLAP? How is it different from OLTP?

OLAP stands for On-Line Analytical Processing. It is a capability or a set of tools

which enables the end users to easily and effectively access the data warehouse data
using a wide range of tools like Microsoft Excel, Reporting Services, and many other
3rd party business intelligence tools.

OLAP is used for analysis purposes to support day-to-day business decisions and is
characterized by less frequent data updates and contains historical data. Whereas,
OLTP (On-Line Transactional Processing) is used to support day-to-day business
operations and is characterized by frequent data updates and contains the most
recent data along with limited historical data based on the retention policy driven by
business needs.

What is a Data Source? What are the different data sources supported by SSAS?

A Data Source contains the connection information used by SSAS to connect to the
underlying database to load the data into SSAS during processing. A Data Source
primarily contains the following information (apart from various other properties like
Query timeout, Isolation etc.):
o

Provider

Server Name

Database Name

Impersonation Information

SSAS Supports both .Net and OLE DB Providers. Following are some of the major
sources supported by SSAS: SQL Server, MS Access, Oracle, Teradata, IBM DB2, and
other relational databases with the appropriate OLE DB provider.

What is Impersonation? What are the different impersonation options available in

SSAS?

Impersonation allows SSAS to assume the identity/security context of the client

application which is used by SSAS to perform the server side data operations like
data access, processing etc. As part of impersonation, the following options are
available in SSAS:
o

Use a specific Windows user name and password: This option lets you to
specify Windows account credentials which will be used by SSAS to perform
operations like source data access, processing etc.

Use the service account: When this option is selected, SSAS uses the
credentials of the service account under which the Analysis Services service is
configured/running for source data access, processing etc.

Use the credentials of the current user: When this option is set, SSAS uses
the credentials of the current user for performing operations like DMX Open
Queries, Local cubes etc. This option cannot be used for performing server
side operations like source data access, processing etc.

Inherit: This option let's the SSAS server decide which impersonation mode is
suitable for each type of operation. When this option is set, by default SSAS
will use the service account for operations like processing and the credentials
of the current user for operations like Local cubes, querying the data mining
models, etc...

What is a Data Source View?

A Data Source View (DSV) is a logical view of the underlying database schema and
offers a layer of abstraction for the underlying database schema. This layer acts as a
source for SSAS and captures the schema related information from the underlying
database. The schematic information present in DSV includes the following:
o

Underlying database Table(s)/View(s) metadata

Primary Key & Foreign Key relationships between the underlying database
Table(s)

Additional columns in the form of Named Calculations

Complex logic on the underlying Table(s)/View(s) in the form of Named

Queries

SSAS can only see the schematic information present in the DSV and it cannot see
the schematic information from the underlying database.

What is a Named Calculation? In what scenarios do you use it?

A Named Calculation is a new column added to a Table in DSV and is based on an

expression. This capability allows you to add an extra column into your DSV which is
based on one or more columns from underlying data source Table(s)/View(s)
combined using an expression without requiring the addition of a physical column in
the underlying database Table(s)/View(s).

The expression used in the Named Calculation should conform to the underlying data
source dialect. For example, if the underlying data source is SQL Server, then it
should conform to T-SQL, If is it Oracle, then it should conform to PL/SQL, etc...

Named Calculations can be used in many scenarios, following are some of the
common scenarios:
o

For creating Derived Columns. Say you have First Name and Last Name in the
underlying data source Table/View and you want to get the Full Name as "First
Name + space + Last Name". Such things can be added as a Named
Calculation.

For performing Lookup Operations. Say you have an Employee table which
has AddressID and an Address table in which AddressID is the Primary Key.
Now, to get the address information (say Country) into the Employee table in
DSV, a Named Calculation can be added to the Employee table with the
following expression:

SELECT Country
FROM Address
WHERE AddressID = Employee.AddressID

)
What is a Named Query? In what scenarios do you use it?

A Named Query is a SQL query/expression in your DSV which acts as a Table. It is

used to combine data from one or more Table(s)/View(s) from the underlying data
source without requiring any schematic changes to the underlying data source
Table(s)/View(s).

The SQL Query used in the Named Query should conform to the underlying data
source dialect. For example, if the underlying data source is SQL Server, then it
should conform to T-SQL, If is it Oracle, then it should conform to PL/SQL, etc...

Named Queries are used in various scenarios, following are some of the common
scenarios:
o

Combining data from multiple Tables/Views from the underlying data source
by using either simple or complex join operations.

Adding filter conditions for filtering out unwanted data or selecting the
required data (limiting the data).

Pretty much everything that can be done using a Named Calculation can also be
done using a Named Query.

What are the pros and cons of using Tables and Named Queries in DSV?

Following are some of the pros and cons of using Tables and Named Queries in DSV.
Tables in the below comparison refers to the Table in DSV which references a single
Table or a View in the underlying source database.

Tables

Named Queries

Named Calculations can be added to Tables in Named Calculations cannot be added to

DSV.
Named Queries in DSV.
Keys and Relationships are automatically set
(by the wizard) based on the Keys and
Relationships in the underlying database
schema.

Keys and Relationships have to be set

explicitly in the DSV.

More than one Table/View from the

Only one Table/View from the underlying data underlying data source can be
source can be referenced in DSV.
referenced using a SQL Expression in
the DSV.
Any filter/limiting conditions cannot be
applied on a table in DSV.

Filter/limiting conditions can be applied

as part of the SQL expression in the
Named Query in the DSV.

Although Named Calculations and Named Queries can be used to extend the
functionality of SSAS to address the evolving business needs, it is always a good
practice to first build a good Dimensional Model in the beginning of a Data
Warehousing/SSAS project.

What is the purpose of setting Logical Keys and Relationships in DSV?

Many of the user interfaces/designers/wizards in BIDS which are part of a SSAS

project depend on the Primary Key and Relationships between Fact and Dimension
tables. Hence it is important to define the Primary Key and Relationships in DSV.

By default, the Data Source View Wizard detects the Physical Primary Keys and
Relationships between the tables in the underlying source database and applies the
same Keys and Relationships in DSV layer. However, Logical Keys and Relationships
need to be defined explicitly in the following scenarios:
o

If the DSV table is referring to an underlying database View.

If the DSV table is created as a Named Query.

If any additional relationships need to be defined in the DSV layer apart from
the ones that are physically defined in the underlying source database.

Is it possible to combine data from multiple data sources in SSAS? If yes, how do
you accomplish it?

SSAS allows combining data from multiple underlying data sources into a single DSV.
To be able to add Table(s)/View(s) from multiple data sources, first you need to
create a DSV using your first source and this source acts as the primary data source.
Now after the initial DSV is created, you can add one or more data sources into DSV
which will act as secondary data sources and you can choose additional
Table(s)/View(s) from the secondary data sources which you want to include in your
DSV.

The key thing while combining data from multiple data sources is that the Primary
Data Source must support OPENROWSET queries. Hence in most cases, SQL Server
is used as the Primary Data Source

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:

Time Dimension

Product Dimension

Geography Dimension

Customer Dimension

Employee Dimension

Here are some examples of a Dimension Attribute

o

Year, Quarter, Month etc. in case of a Time Dimension

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 ParentChild 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.

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.

Conformed Dimensions.

These can be used to implement the concept of

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

classification/MDX expressions.

Intelligence Wizard to assign/generate standard

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.

This storage Mode offers effective memory usage by avoiding duplication of

data compared to MOLAP Storage Mode.

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.

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).

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.