SQL Server Analysis Services Succinctly by Stacia Misner

2

By
Stacia Misner
Foreword by Daniel Jebaraj










3
Copyright © 2014 by Syncfusion Inc.
2501 Aerial Center Parkway
Suite 200
Morrisville, NC 27560
USA
All rights reserved.

mportant licensing information. Please read.
This book is available for free download from www.syncfusion.com on completion of a registration form.
If you obtained this book from any other source, please register and download a free copy from
www.syncfusion.com.

This book is licensed for reading only if obtained from www.syncfusion.com.
This book is licensed strictly for personal or educational use.
Redistribution in any form is prohibited.
The authors and copyright holders provide absolutely no warranty for any information provided.
The authors and copyright holders shall not be liable for any claim, damages, or any other liability arising
from, out of, or in connection with the information in this book.
Please do not use this book if the listed terms are unacceptable.
Use shall constitute acceptance of the terms listed.
SYNCFUSION, SUCCINCTLY, DELIVER INNOVATION WITH EASE, ESSENTIAL, and .NET ESSENTIALS are the
registered trademarks of Syncfusion, Inc.



Technical Reviewer: Rui Machado
Copy Editor: Courtney Wright
Acquisitions Coordinator: Marissa Keller Outten, director of business development, Syncfusion, Inc.
Proofreader: Graham High, content producer, Syncfusion, Inc.

I


4
Table of Contents
The Story behind the Succinctly Series of Books 8
About the Author 10
Chapter 1 Introduction to SQL Server Analysis Services 11
What Is Business Intelligence? 11
Architecture Options 13
Development, Management, and Client Tools 17
Database Development Process 19

Anatomy of an Analysis Services Project 20
Chapter 2 Working with the Data Source View 21
Data Source 21
Data Source View 23
Data Source View Wizard 23
Primary Keys and Relationships 24
Properties 24
Named Calculations 25
Named Queries 26
Chapter 3 Developing Dimensions 27
Dimension Wizard 27
Dimension Designer 29
Attributes 30
Attribute Properties 31
Unknown Member 33
Design Warnings 35
User-Defined Hierarchies 37



5
Natural Hierarchies 38
Unnatural Hierarchies 38
Attribute Relationships 39
Parent-Child Hierarchy 41
Attribute Types 44
Translations 45
Chapter 4 Developing Cubes 47
Cube Wizard 47
Measures 50

Measure Properties 50
Aggregate Functions 51
Additional Measures 53
Role-playing Dimension 54
Dimension Usage 56
Partitions 57
Partitioning Strategy 58
Storage Modes 59
Partition Design 60
Partition Merge 61
Aggregations 61
Aggregation Wizard 62
Aggregation Designer 64
Usage-Based Optimization 66
Perspectives 68
Translations 70
Chapter 5 Enhancing Cubes with MDX 71
Calculated Members 71


6
Calculated Member Properties 73
Calculation Tools 74
Tuple Expressions 77
Color and Font Expressions 78
Custom Members 79
Named Sets 81
Key Performance Indicators 82
Actions 85
Standard Action 86

Drillthrough Action 87
Reporting Action 88
Writeback 89
Cell Writeback 89
Dimension Writeback 90
Chapter 6 Managing Analysis Services Databases 91
Deployment Options 91
Deploy Command 91
Deployment Wizard 93
Processing Strategies 94
Full Process 94
Process Data and Process Index 97
Process Update 97
Process Add 97
Security 98
User Security 98
Administrator Security 104
Service Account Security 105



7
Database Copies 105
Backup and Restore 106
Synchronization 107
Detach and Attach 107
Chapter 7 Using Client Tools 108
Tools in the Microsoft Business Intelligence Stack 108
Microsoft Excel 108
Microsoft SQL Server Reporting Services 111

Microsoft SharePoint Server 114
Custom Applications (ADOMD.NET) 120





8
The Story behind the Succinctly Series
of Books
Daniel Jebaraj, Vice President
Syncfusion, Inc.
taying on the cutting edge
As many of you may know, Syncfusion is a provider of software components for the
Microsoft platform. This puts us in the exciting but challenging position of always
being on the cutting edge.
Whenever platforms or tools are shipping out of Microsoft, which seems to be about
every other week these days, we have to educate ourselves, quickly.
Information is plentiful but harder to digest
In reality, this translates into a lot of book orders, blog searches, and Twitter scans.
While more information is becoming available on the Internet and more and more books are
being published, even on topics that are relatively new, one aspect that continues to inhibit us is
the inability to find concise technology overview books.
We are usually faced with two options: read several 500+ page books or scour the web for
relevant blog posts and other articles. Just as everyone else who has a job to do and customers
to serve, we find this quite frustrating.
The Succinctly series
This frustration translated into a deep desire to produce a series of concise technical books that
would be targeted at developers working on the Microsoft platform.
We firmly believe, given the background knowledge such developers have, that most topics can

be translated into books that are between 50 and 100 pages.
This is exactly what we resolved to accomplish with the Succinctly series. Isn’t everything
wonderful born out of a deep desire to change things for the better?
The best authors, the best content
Each author was carefully chosen from a pool of talented experts who shared our vision. The
book you now hold in your hands, and the others available in this series, are a result of the
authors’ tireless work. You will find original content that is guaranteed to get you up and running
in about the time it takes to drink a few cups of coffee.
S



9
Free forever
Syncfusion will be working to produce books on several topics. The books will always be free.
Any updates we publish will also be free.
Free? What is the catch?
There is no catch here. Syncfusion has a vested interest in this effort.
As a component vendor, our unique claim has always been that we offer deeper and broader
frameworks than anyone else on the market. Developer education greatly helps us market and
sell against competing vendors who promise to “enable AJAX support with one click,” or “turn
the moon to cheese!”
Let us know what you think
If you have any topics of interest, thoughts, or feedback, please feel free to send them to us at

We sincerely hope you enjoy reading this book and that it helps you better understand the topic
of study. Thank you for reading.

Please follow us on Twitter and “Like” us on Facebook to help us spread the
word about the Succinctly series!



10
About the Author
Stacia Misner is a Microsoft SQL Server MVP, SQL Server Analysis Services Maestro,
Microsoft Certified IT Professional-BI, and Microsoft Certified Technology Specialist-BI with a
Bachelor’s degree in Social Sciences. As a consultant, educator, author, and mentor, her career
spans more than 25 years, with a focus on improving business practices through technology.
Since 2000, Stacia has been providing consulting and education services for Microsoft’s
business intelligence technologies, and in 2006 she founded Data Inspirations. During these
years, she has authored or co-authored multiple books and articles as well as delivered classes
and presentations around the world covering different components of the Microsoft SQL Server
database and BI platform.

11
Chapter 1 Introduction to SQL Server
Analysis Services
SQL Server Analysis Services is one of several components available as part of Microsoft SQL
Server 2012 that you can use to develop a business intelligence analytic solution. In this
introduction to SQL Server Analysis Services, I explain the concept of business intelligence and
all available options for architecting a business intelligence solution. I also review the process of
developing an Analysis Services database at a high level and introduce the tools you use to
build, manage, and query Analysis Services.
What Is Business Intelligence?
Business intelligence means different things to different people. Regardless of how broadly or
narrowly the term is used, a globally accepted concept is that it supports the decision-making
process in organizations. In short, people at all levels of an organization must gather information
about the events occurring in their business before making a decision that can help that
business make or save money.
A common problem in many businesses is the inability of the operational systems gathering
details about business events to facilitate the information-gathering process and consequently
the decision-making process is impeded. When the only source of information is an operational
system, at worst people rely on gut instinct and make ill-informed decisions because they
cannot get the information they need, while at best people have tools or other people to help
them compile the needed data, but that process takes time and is tedious.
Most business applications store data in relational systems, which anyone can query if they
have the right tools, skills, and security clearance. Why then is it necessary to move the data
into a completely different type of database? To understand this requirement and why Analysis
Services is included in a business intelligence solution, it’s helpful to compare the behavior of a
relational engine like SQL Server with an Online Analytical Processing (OLAP) engine like
Analysis Services. First, let’s consider the three types of questions that are important to decision
makers as they analyze data to understand what’s happening in the business:
 Summarization. Users commonly want to summarize information for a particular range
of time, such as total sales across a specified number of years.

 Comparison. Users want to answer questions that require comparative data for multiple
groups of information or time periods. For example, they might want to see total sales by
product category. They might want to break down this data further to understand total
sales by product category or by all months in the current year.
 Consolidation. Users often also have questions that require combining data from
multiple sources. For example, they might want to compare total sales with the
forecasted sales. Typically, these types of data are managed in separate applications.


12

Note: For the purposes of this book, I use summary, comparison, and consolidation
questions to represent the business requirements for a business intelligence
solution to build. Although the scenario I discuss is extremely simple, the same
principles that I describe here also apply to real-world scenarios for which decision-
makers have many more questions that require answers that the data can answer, if
only it were structured in a better way.
Each of these types of queries can be problematic when the data is available in a relational
engine only for the following reasons:
 Queries for decision-making rely on data stored in the same database that is being used
to keep the business running. If many users are executing queries that require the
summarization of millions of rows of data, a resource contention problem can arise. A
summarized query requires lots of database resources and interferes with the normal
insert and update operations that are occurring at the same time as the business
operations.
 Data sources are often focused on the present state. Historical data is archived after a
specified period of time. Even if it is not archived completely, it might be kept at a
summarized level only.
 Calculations often cannot be stored in the relational database because the base values
must be aggregated before calculations are performed. For example, a percent margin

calculation requires the sum of sales and the sum of costs to be calculated first, total
costs to be subtracted from total sales next, and finally the result to be derived by
dividing it by the total sales. Whether the logic is relatively simple, as with a percent
margin calculation, or complex as with a weighted allocation for forecasting, that logic is
not stored in the relational engine and must be applied at query time. In that case, there
is no guarantee that separate users using different tools to gather data will construct the
calculation in identical ways.
 Relational storage of data often uses a structure called third normal form, which spreads
related data across multiple tables. As a result, the retrieval of data from these tables
requires complex queries that can be difficult to write and can contain many joins that
might cause queries to run slowly.
An OLAP engine solves these problems in the following ways:
 The use of a separate data source for querying reduces resource contention. Of course,
you can maintain a replica of a relational database that you dedicate to reporting, but
there are other reasons to prefer OLAP over relational.
 You can retain historical data in an OLAP database that might otherwise be eliminated
by overwrites or archiving the source system. Again, you can resolve this problem by
creating a relational data mart or data warehouse, but there are still other reasons to
implement OLAP.
 A more significant benefit of OLAP is the centralization of business logic to ensure all
users get the same answer to a particular query regardless of when the query is run or
the tool used to execute the query.



13
 The storage mechanism used by Analysis Services is designed for fast retrieval of data.
If you prefer to write a query rather than use a query builder tool, many times the queries
are shorter and simpler (once you learn the query syntax for Analysis Services, MDX).
 OLAP databases store data in binary format, resulting in smaller files and faster access

to the data.
 Last but not least, OLAP databases provide users with self-service access to data. For
example, a Microsoft Excel user can easily connect to an Analysis Services cube and
browse its data by using pivot charts or pivot tables.
Architecture Options
There are several different ways that you can architect Analysis Services:
 Prototype. This is the simplest architecture
to implement. In this case, you install
Analysis Services on a server, and then
create and process a database to load it
with data. Your focus is on a single data
load to use in a proof of concept and
therefore you do not implement any data
refresh processes as part of the
architecture.
 Personal or team use. If you have a single
data source with a relatively simple
structure and small volumes of data, and if
you have no need to manage historical
changes of the data (also known as slowly
changing dimensions), you can implement
Analysis Services and add a mechanism
for refreshing your Analysis Services
database on a periodic basis, such as
nightly or weekly.
 Department or enterprise use. As the
number of users requiring access to the
database grows, or the number of data
sources or complexity of the data structure
increases, you need to set up a more

formal architecture. Typically, this requires you to set up a dedicated relational source for
Analysis Services, such as a subject-specific data mart or a data warehouse that houses
multiple data marts or consolidates data from multiple sources. In this scenario, you
implement more complex extract, transform, and load (ETL) processes to keep the data
mart or data warehouse up-to-date and also to keep the Analysis Services database up-
to-date. If you need to scale out the solution, you can partition the Analysis Services
database.
Multidimensional or Tabular?
When you install Analysis Services, you have the
option to install one of the three types of
instances:
 Multidimensional
 Tabular
 PowerPivot for SharePoint
The first two instance types are standalone server
instances, while the third requires integration with
SharePoint.
The multidimensional server hosts databases
containing one or more cubes. It is a mature,
feature-rich product that supports complex data
structures and scales to handle high data
volumes and large numbers of concurrent users.
The tabular server supports a broader variety of
data sources for models stored in its databases,
but manages data storage and memory much
differently. For more information, see
/>us/library/hh994774.aspx.


14

Note: Although the focus of this book is the multidimensional server mode for
Analysis Services, the architecture for an environment that includes Analysis
Services in tabular server mode is similar. Whereas a multidimensional database
requires relational data sources, a tabular database can also use spreadsheets, text
data, and other sources. You can use the same client tools to query the databases.
In the prototype architecture, your complete environment can exist on a single server, although
you are not required to set it up this way. It includes a relational data source, an Analysis
Services instance, and a client tool for browsing the Analysis Services database, as shown in
Figure 1. The relational data source can be a SQL Server, DB2, Oracle, or any database that
you can access with an OLE DB driver. For prototyping purposes, you can use the Developer
Edition of Analysis Services, but if you think the prototype will evolve into a permanent solution,
you can use the Standard, Business Intelligence, or Enterprise Edition, depending on the
features you want to implement as described in Table 1. For browsing the prototype database,
Excel 2007 or higher is usually sufficient.

Figure 1: Prototype Architecture

Table 1: Feature Comparison by Edition
Feature
Standard
Edition
Business
Intelligence
Edition
Developer
and
Enterprise
Editions
Account Intelligence

Yes
Yes
Yes
Actions
Yes
Yes
Yes
Advanced Dimensions (Reference,
Many-to-Many)
Yes
Yes
Yes
Advanced Hierarchy Types (Parent-
Child, Ragged)
Yes
Yes
Yes
Aggregations
Yes
Yes
Yes
Binary and Compressed XML
Transport
Yes
Yes
Yes
Custom Assemblies
Yes
Yes
Yes

15
Feature
Standard
Edition
Business
Intelligence
Edition
Developer
and
Enterprise
Editions
Custom Rollups
Yes
Yes
Yes
Dimension and Cell Level Security
Yes
Yes
Yes
Direct Writeback
No
Yes
Yes
Drillthrough
Yes
Yes
Yes

Hierarchies
Yes
Yes
Yes
High Availability
Yes
Yes
Yes
KPIs
Yes
Yes
Yes
Linked Measures and Dimensions
No
Yes
Yes
MDX Queries and Scripts
Yes
Yes
Yes
Measure Expressions
No
Yes
Yes
MOLAP, ROLAP, and HOLAP
Storage Modes
Yes
Yes
Yes
Multiple Partitions

Up to 3
Yes
Yes
Perspectives
No
Yes
Yes
Proactive Caching
No
Yes
Yes
Programmability (AMO,
AMOMD.NET, OLEDB, XML/A,
ASSL)
Yes
Yes
Yes
Push-Mode Processing
No
Yes
Yes
Role-Based Security Model
Yes
Yes
Yes
Scalable Shared Databases
(Attach/Detach, Read Only)
No
Yes
Yes

Scalable String Storage
Yes
Yes
Yes
Semi-additive Measures
LastChild only
Yes
Yes
Time Intelligence
Yes
Yes
Yes
Translations
Yes
Yes
Yes
Writeback Cells
Yes
Yes
Yes


16
Feature
Standard
Edition
Business
Intelligence
Edition
Developer

and
Enterprise
Editions
Writeback Cube
Yes
Yes
Yes
Writeback Dimensions
No
Yes
Yes

For a personal or team solution, you introduce automation to keep data current in Analysis
Services. You use the same components described in the prototype architecture: a data source,
Analysis Services, and a browsing tool. However, as shown in Figure 2, you add Integration
Services as an additional component to the environment. Integration Services uses units called
packages to describe tasks to execute. You can then use a scheduled process to execute one
or more packages that update the data in the Analysis Services database. Excel is still a
popular choice as a browsing tool, but you might also set up Reporting Services to provide
access to standard reports that use Analysis Services as a data source.

Figure 2: Personal or Team Architecture
To set up an architecture for organizational use, as shown in Figure 3, you introduce a data
mart or data warehouse to use as a source for the data that is loaded into Analysis Services.
Integration Services updates the data in the data mart on a periodic basis and then loads data
into Analysis Services from the data mart. In addition to Excel or Reporting Services as client
tools, you can also use SharePoint business intelligence features, which include Excel Services,
SharePoint status indicators and dashboards, or PerformancePoint scorecards and dashboards.

Figure 3: Organizational Architecture

17
Development, Management, and Client Tools
If you are responsible for creating or maintaining an Analysis Services database, you use the
following tools:
 SQL Server Data Tools (SSDT)
 SQL Server Management Studio (SSMS)
 A variety of client tools

SSDT is the environment you use to develop an Analysis Services database. Using this tool,
you work with a solution that contains one or more projects, just like you would when developing
applications in Visual Studio.
You can use SSMS to configure server properties that determine how the server uses system
resources. You can also use Object Explorer to see the databases deployed to the server and
explore the objects contained within each database. Not only can you view an object’s
properties, but in some cases you can also make changes to those properties. Furthermore, you
can create scripts of an object’s definition to reproduce it in another database or on another
server.
SSMS also gives you a way to quickly check data either in the cube itself or in individual
dimensions. You can use the MDX query window to write and execute queries that retrieve data
from the cube. A graphical interface is also available for browsing these objects without the
need to write a query.
Another feature in SSMS is the XML for Analysis (XMLA) query window in which you write and
execute scripts. You can use XMLA scripts to create, alter, or drop database objects and also to
process objects, which is the way that data is loaded into an Analysis Services database. You
can then put these scripts into Integration Services packages to automate their execution or you
can put them into SQL Server Agent jobs. However, you are not required to use scripts for
processing. You can instead manually process objects in SSMS whenever necessary or create

Integration Services packages to automate processing.
As part of the development process, you should use the client tools that your user community
is likely to use to ensure the browsing experience works as intended. In this chapter, I explain
the choice of client tools available from Microsoft, but there are also several third-party options
to consider, and of course you can always create a custom application if you want users to have
specific functionality available. The Microsoft business intelligence stack includes the following
tools:
 Excel. This is a very common choice for browsing a cube since users are often already
using Excel for other reasons and likely have some experience with pivot tables. Excel
provides an easy-to-use interface to select dimensions for browsing, as shown in Figure
4, and also offers advanced functionality for filtering, sorting, and performing what-if
analysis.


18

Figure 4: Cube Browsing with Excel
 Reporting Services. This is an option when users need to review information but are
doing less exploration of the data. These users access the data by using pre-built static
reports, as shown in Figure 5.


Figure 5: Report with Analysis Services Data Source
 SharePoint. You can use Analysis Services as a data source for dashboard filters, as
shown in Figure 6.


Figure 6: Dashboard Filter with Analysis Services Data Source
 PerformancePoint Services. You can create scorecards, as shown in Figure 7, and
dashboards using Analysis Services as a data source.

19

Figure 7: Analysis Services Key Performance Indicators in a Scorecard
Database Development Process
Before diving into the details of Analysis Services database development, let’s take a look at the
general process:
1. Design a dimension model.
2. Develop dimension objects.
3. Develop cubes for the database.
4. Add calculations to the cube.
5. Deploy the database to the server.

First, you start by designing a dimensional model. You use either an existing dimensional
model that you already have in a data mart or data warehouse, or you define the tables or views
that you want to use as sources, set up logical primary keys, and define relationships to produce
a structure that’s very similar to a dimensional model that you would instantiate in the relational
database. I describe this step in more detail in Chapter 2, “Designing the dimensional model.”
Once the dimensional model is in place, you then work through the development of the
dimension objects. When browsing a cube, you use dimensions to “slice and dice” the data.
You will learn more about this step in the process in Chapter 3, “Developing dimensions.”
The next step is to develop one or more cubes for the database. This is often an iterative
process where you might go back and add more dimensions to the database and then return to
do more development work on a cube. I will explain more about this in Chapter 4, “Developing
cubes.”

20
Eventually you add calculations to the cube to store the business logic in the cube for data
that’s not available in the raw data. There are specialized types of calculations to produce sets
of dimension members and key performance indicators. You will learn how to work with all these
types of calculations in Chapter 5, “Enhancing cubes with MDX.”
During and after the development work, you deploy the database to the server and process
objects to load them with data. It’s not necessary to wait until you’ve completed each step in the
development process to deploy. It’s very common to develop a dimension, deploy it so that you
can see the results, go back and modify the dimension, and then deploy again. You continue
this cycle until you are satisfied with the dimension, and then you are ready to move on to the
development of the next dimension.
Anatomy of an Analysis Services Project
To start the multidimensional database development process in SSDT, you create a new project
in SSDT. Here you can choose from one of the following project types:
 Analysis Services Multidimensional and Data Mining Project. You use this project
type to build a project from scratch. The project will initially be empty, and then you build
out each object individually, usually using wizards to get started quickly.
 Import from Server (Multidimensional and Data Mining). If an Analysis Services
database is already deployed to the server, you can import the database objects and
have SSDT reverse engineer the design and create all the objects in the project.
Whether you start with an empty Analysis Services project or import objects from an existing
Analysis Services database, there are several different types of project items that you have in
an Analysis Services project:
 Data Source. This item type defines how to connect to an OLE DB source that you want
to use. If you need to change a server or database name, then you have only one place
to make the change in SSDT.
 Data Source View (DSV). The data source view represents the dimensional model.
Everything you build into the Analysis Services database relies on the definitions of the
data structures that you create in the data source view.
 Cube. An Analysis Services project has at least one cube file in it. You can create as

many as you need.
 Dimension. Your project must have at least one dimension, although most cubes have
multiple dimensions.
 Role. You use roles to configure user access permissions. I explain how to do this in
Chapter 6, “Managing Analysis Services databases.” It’s not necessary to create a role
in SSDT, however. You can add a role later in SSMS instead.





21
Chapter 2 Working with the Data Source
View
An Analysis Services multidimensional model requires you to use one or more relational data
sources. Ideally, the data source is structured as a star schema, such as you typically find in a
data warehouse or data mart. If not, you can make adjustments to a logical view of the data
source to simulate a star schema. This logical view is known as a Data Source View (DSV)
object in an Analysis Services database. In this chapter, I explain how to create a DSV and how
to make adjustments to it in preparation for developing dimensions and cubes.
Data Source
A DSV requires at least one data source, a file type in your Analysis Services project that
defines the location of the data to load into the cube, the dimension objects in the database, and
the information required to connect successfully to that data. You use a wizard to step through
the process of creating this file. To launch the wizard, right-click the Data Sources folder in
Solution Explorer. If you have an existing connection defined, you can select it in the list.
Otherwise, click New to use the Connection Manager interface, shown in Figure 8, to select a
provider, server, and database.

Figure 8: Connection Manager for a New Data Source

22
The provider you select can be a managed .NET provider, such as the SQL native client, when
you’re using SQL Server as the data source. You can also choose from several native OLE DB
providers for other relational sources. Regardless, your data must be in a relational database.
Analysis Services does not know how to retrieve data from Excel, applications like SAS, or flat
files. You must first import data from those types of files into a database, and then you can use
the data in Analysis Services.
After you select a provider, you then specify the server and database where the data is stored
and also whether to use the Windows user or a database login for authentication whenever
Analysis Services needs to connect to the data source. This process is similar to creating data
sources in Integration Services or Reporting Services or other applications that require
connections to data.
On the second page of the Data Source Wizard, you must define impersonation information.
The purpose of the connection information in the Data Source file is to tell Analysis Services
where to find data for the cubes and dimensions during processing. However, because
processing is usually done on a scheduled basis, Analysis Services does not execute
processing within the security context of a current user and requires impersonation information
to supply a security context. There are four options:
 Specific Windows user name and password. You can hard-code a specific user name
and password with this option.
 Service account. This is the account running the Analysis Services service, which is
either a built-in account or a Windows account set up exclusively for the service. This
might not be a good option if your data sources are on a remote server and you’re using
the Local Service or Local System accounts because those built-in accounts are
restricted to the local server.
 Current user’s credentials. You can select the option to use the credentials of the
current user, but that’s only useful when processing the database manually. Processing
will fail if you set up a scheduled job through SQL Server Agent or an Integration

Services task.
 Inherit. This option uses the database-level impersonation information (visible under
Management Studio in the Database Properties dialog box). If the database-level
impersonation is set to Default, Analysis Services uses the service account to make the
connection. Otherwise, it uses the specified credentials.

Note: Regardless of the option you choose for impersonation, be sure the account
has Read permissions on the data source. Otherwise, processing will fail.



23
Data Source View
The purpose of the DSV is to provide an abstraction layer between our physical sources in the
relational database and the logical schema in SSAS. You can use it to combine multiple data
sources that you might not be able to join together relationally, or to simulate structural changes
that you wouldn’t be allowed to make in the underlying source. Or you can use it to simplify a
source that has a lot of tables so you can focus on only the tables needed to build the Analysis
Services database. By having the metadata of the schema stored within the project, you can
work on the Analysis Services database design when disconnected from the data source.
Connectivity is required only when you’re ready to load data into Analysis Services.
Data Source View Wizard
The most common approach to building a DSV to is use existing tables in a data mart or data
warehouse. These tables should already be populated with data. To start the Data Source View
Wizard, right-click the Data Source Views folder in Solution Explorer and then select a data
source. Select the tables or views that you want to use to develop dimensions and cubes. When
you complete the wizard, your selections appear in diagram form in the center of the workspace
and in tabular form on the left side of the workspace, as shown in Figure 9.

Figure 9: Data Source View

24
Primary Keys and Relationships
The tables in the DSV inherit the primary keys and foreign key relationships defined in the data
source. You should see foreign key relationships between a fact table and related dimension
tables, or between child levels in a snowflake dimension. Figure 9 includes examples of both
types of relationships. The FactResellerSales table has foreign key relationships with two
dimension tables, DimProduct and DimDate. In addition, foreign key relationships exist between
levels in the product dimension. Specifically, these relationships appear between
DimProductSubcategory and DimProductCategory, and between DimProduct and
DimProductSubcategory.
One of the rules for dimension tables is that they must have a primary key. If for some reason
your table doesn’t have one, you can manufacture a logical primary key. Usually this situation
arises during prototyping when you don’t have a real data mart or data warehouse to use as a
source. However, sometimes data warehouse developers leave off the primary key definition as
a performance optimization for loading tables. To add a primary key, right-click the column
containing values that uniquely identify each record in the table and select Set Logical Primary
Key on the submenu. Your change does not update the physical schema in the database, but
merely updates metadata about the table in the DSV.
Similarly, you should make sure that the proper relationships exist between fact and dimension
tables. Sometimes these relationships are not created in the data source for performance
reasons, or perhaps you are using tables from different data sources. Whatever the reason for
the missing relationships, you can create logical relationships by dragging the foreign key
column in one table to the primary key column in the other table. Take care to define the proper
direction of a relationship. For example, the direction of the arrow needs to point away from the
fact table and toward the dimension table, or away from a child level in a snowflake dimension
and toward a parent level.
Properties

When you select a particular table or a column in a table, whether in the diagram or list of
tables, you can view the related properties in the Properties window, which is displayed to the
right of the diagram by default. You can change the names of tables or columns here if for some
reason you don’t have the necessary permissions to modify the names directly in the data
source and want to provide friendlier names than might exist in the source. As you work with
wizards during the development process, many objects inherit their names from the DSV.
Therefore, the more work you do here to update the FriendlyName property, the easier your
work will be during the later development tasks. For example, in a simple DSV in which I have
the DimDate, DimProduct, DimSalesTerritory, and FactResellerSales tables, I change the
FriendlyName property to Date, Product, Territory, and ResellerSales for each table,
respectively.



25
Named Calculations
A named calculation is simply an SQL expression that adds a column to a table in the DSV. You
might do this when you have read-only access to a data source and need to adjust the data in
some way. For example, you might want to concatenate two columns to produce a better report
label for dimension items (known as members).
Like the other changes I’ve discussed in this chapter, the addition of a named calculation
doesn’t update the data source, but modifies the DSV only. The expression passes through
directly to the underlying source, so we use the language that’s applicable. For example, if SQL
Server is your data source, you create a named calculation by using Transact-SQL syntax.
There is no validation of our expression or expression builder in the dialog box. You must test
the results elsewhere.
To add a named calculation, right-click the table and click New Named Calculation in the
submenu. Then type an expression, as shown in Figure 10.

Figure 10: Named Calculation

After you add the expression as a named calculation, a new column is displayed in the DSV
with a calculator icon. To test whether the expression is valid, right-click the table and select
Explore Data. The expression is evaluated, allowing you to determine if you set up the
expression correctly.