0% found this document useful (0 votes)
37 views13 pages

Server-Analysis-Services/: Ssas Glossary

This document provides a summary of key things the author wishes they knew when starting to work with SQL Server Analysis Services (SSAS). The top three things are: 1) Learning MDX, the query language for OLAP cubes, is important for writing custom measures and calculations. 2) Excel is often the main reporting tool used to access OLAP cubes, so optimizing cube design for Excel pivot tables is important. 3) Partitioning data in the cube can greatly improve processing performance for large datasets.

Uploaded by

uma
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
Download as docx, pdf, or txt
0% found this document useful (0 votes)
37 views13 pages

Server-Analysis-Services/: Ssas Glossary

This document provides a summary of key things the author wishes they knew when starting to work with SQL Server Analysis Services (SSAS). The top three things are: 1) Learning MDX, the query language for OLAP cubes, is important for writing custom measures and calculations. 2) Excel is often the main reporting tool used to access OLAP cubes, so optimizing cube design for Excel pivot tables is important. 3) Partitioning data in the cube can greatly improve processing performance for large datasets.

Uploaded by

uma
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1/ 13

https://www.mssqltips.

com/sqlservertip/6112/what-i-wish-i-knew-when-i-started-working-with-sql-
server-analysis-services/

 Line 1 is the SELECT command.


 Lines 2 and 7 are the NON EMPTY operators which prevent the return of null values for the
measures and for the dimensions respectively.
 Lines 4 and 5 are the measures (sometimes these are called facts) that we are selecting from
the Analysis Services cube. Please note that the measures are separated by a comma just
like columns are separated by a comma in an SQL statement.
 Line 6 is where we specify to place the measures in columns.
 Lines 9 and 10 are where we specify the dimensional attributes on which to slice the
measures. Please note that the dimensional attributes are separated by an asterisk (*).
 Line 11 is where specify to place the dimensional attributes on rows.
 Lines 12 and 13 are used to specify the range of the calendar years from the Delivery Date
role-playing dimension. Please note the colon (:) is used between the low and high values of
the range.
 Line 14 is used to remove all values where the country is equal to the United States. Please
note the minus sign (-) before the curly bracket after the word SELECT.
 Line 15 is used to select where the Gender attribute of the customer dimension equals F for
Female.
 Line 16 specifies that we are selecting from the Adventure Works cube. Please note the three
closing parentheses at the end of the line match the number of FROM ( SELECT statements
in lines 12, 14 and 15.
 Line 17 is the WHERE clause. In this example, removing the WHERE clause does not affect
the results of the query.

SSAS GLOSSARY:

Following is a list of common terms when working with SQL Server Analysis Services.

Cube - Cube is a multi dimensional data structure composed of dimensions and measure groups. The
intersection of dimension and measure groups contained in a cube returns the dataset.

Calculated Measure - Each field in a measure group is known as a base measure. Measures created
using MDX expressions with/without base measures are known as calculated measures.

Data Source View - It's an insulation layer that inherits the basic schema from the data source with
the flexibility to manipulate the schema in this layer without modifying the actual schema in the data
source.
Dimension - Dimension is an OLAP structure that is basically used to contain attributes related to an
entity to categorize data on the row / column axis. A dimension almost never contains measurable
numeric data, and if at all it contains, it is used as an attribute. Typical example of dimensions are
Geography, Organization, Employee, Time etc.

Fact - Fact known as a Measure Group in a cube, is an OLAP structure that is basically used to
contain measureable numeric data, for one or more entities. In cube parlance these entities are
known as Dimensions. A dimension need not be necessarily associated directly with a fact, but a fact
is always associated directly with at least one dimension. Typical example of facts are Sales,
Performance, Tax etc.

Hierarchy - Hierarchy is collection of nested attributes associated in a parent-child fashion with a


defined cardinality. Dimension is formed of attributes, and hierarchy contained in a dimension is
formed of one or more attributes from the same dimension.

KPI - Key Performance Indicators are logical structures defined using MDX expressions. Each KPI
has a goal, status, value, trend, and indicator associated with it. Value is derived based on the
definition of KPI, all the rest of these values vary based on this derived value. KPIs are the primary
elements that makes up a scorecard in a dashboard.

MDX - Multi Dimensional Expressions is considered as the query language of multi dimensional data
structures. This can be considered as the SQL of OLAP databases, with the major difference that
MDX is mostly used for reading data only.

Named Set - Named Set is a pre-defined MDX query defined in the script of the cube. It can be
thought of synonymous to Views in a SQL Server database. Named sets can be dynamic or static and
this nature defines the time when this query gets evaluated.

OLAP - Online Analytical Processing is a term used to represent analytical data sources and analysis
systems. The fundamental perception and expectation associated with the term OLAP is that it would
contain multi dimensional data and the environment hosting the same.

Snowflake Schema - Snowflake schema is an OLAP schema, where one or more normalized
dimension tables are associated with a fact table. For example, Product Sub Category -> Product
Category -> Product can be three normalized dimension tables and Product table can be associated
with a fact table like Sales. This is a very common example of a snowflake schema.

Star Schema - Star schema is an OLAP schema, where all dimension tables are directly associated
with fact tables, and no normalized dimension tables are considered in the schema. For example,
Time, Product, Geography dimension tables would be directly associated with a fact table like Sales.
This is a very common example of star schema.

What I wish I knew when I started working with SQL Server Analysis Services

Problem

What are the topics I know now that wish I would have known when I started working with SQL Server
Analysis Services, aka SSAS?

Solution

SQL Server Analysis Services (SSAS) has roots back almost two decades. OLAP related services
were released with SQL Server 7, and then SSAS was officially included with SQL Server 2000
including MDX support. SQL Server 2005 and 2008 brought a large number of enhancements to
SSAS. Additionally, the multidimensional and more so the tabular infrastructure has become the basis
for Power Query and of course Power BI. I sometimes wonder if Power BI will eventually replace
SSAS, but not anytime soon. Of course, lots of organizations still utilize SSAS OLAP cubes, and
actually use them as the basis for Power BI Dashboards, generally in direct query mode.

Certainly, though there are several items I wish I knew when I started working with SSAS which I will
outline below.

1. Learn MDX

When dealing with any sort of custom measures or custom columns in SSAS, MDX very quickly
surfaces as the method to generate any complex values.

MDX allows for the creation of measures such Period to Date, Year to Date, or Parallel Period. It also
gives you the ability to write queries directly against an MDX cube; these queries allow you to "flatten"
the data set and simulate a SQL type of data set. MDX, though focused solely on OLAP cubes, shows
quite a few similarities to DAX. Although not exactly like MDX, you will see many DAX functions act in
a way that matches with MDX, including the syntax of the function. Just like it is easier to learn a third
language after you learn a second language (think Python and R), learning DAX and to a lesser
extent M, has been much easier because I learned and know MDX.

For instance, to create a Period to Date calculation in MDX, we use a format of measure name and
then date criteria.

WITH

SET [MonthList] AS
YTD([Date].[Calendar].[Month].[July 2013])
SELECT
{[Measures].[Internet Sales Amount]} ON ROWS
,[MonthList] ON COLUMNS
FROM [Adventure Works];

Running this query against the AdventureWorks cube results in the below results.

To create a similar period to data calculation in Power BI and DAX, we use a somewhat similar
syntax.
MTD = TOTALMTD(
SUM('Production WorkOrderRouting'[Actual Cost]),
Dim_Dates[Date]
)

This formula results in the below MTD rollup values. You can see that the basic syntax of measure
then date context in the arguments of both the MDX and DAX are very similar. Furthermore, you have
to think about the date and its related values in the same context of its placement on the date
hierarchy to achieve the desired rollup or rolling value in both DAX and MDX.

2. Excel is your Friend

OLAP cubes are generally based on financial data, and despite many other reporting tools and
access methods, Excel is still the number one client to access a cube. As we all know, financial types
say Excel is their very, very best friend, at least for most analysis and reporting. As such, just about
anyone working in accounting, finance, management, sales, or marketing departments are going to
ask for data in Excel and specifically pivot tables when connecting to an OLAP cube.

However, dealing with pivot tables connected to SSAS requires several ways to optimize your SSAS
cubes for end users. For instance, regular pivot tables allow you to drop a value onto the pivot table
multiple times. In many versions of Excel, a SSAS based pivot table does not allow a measure to be
used twice. Additionally, using Excel pivot tables creates some very "gnarly" MDX queries against
your cube (gnarly is a very technical term). Specifically, the MDX queries in some cases are not as
efficient as they could be which in turn caused performance issues. These issues were compounded
in situations where users attempted to group various dimensional values within a pivot table.
Generally, the more items that you build within the SSAS OLAP cube dimensions (as opposed to
adding grouping and calculations in Excel), generally the better the performance for end users.
As shown in the above example, using the OLAP Pivot Table Extensions Tool, the MDX query
generated for two simple dimensional values, gender and occupation, creates a CrossJoin MDX
query. As the complexity of the data requested increases along with the number of groups,
"temporary" Grouping cubes are created which can slow performance even on the simple groups. In
these cases it is best to create the groups within your dimension.

3. Partitions = Processing Performance

SSAS OLAP cubes, built on the multi-dimensional models, require a data model to be created, and
once created, the data must be loaded into the cube. Not only must the data be loaded, but it also
must be refreshed as the data changes in the original data source. When the data is refreshed,
generally the SSAS Cube becomes "unprocessed" which in turn means the end users do not have the
ability to refresh their pivot table. That means a processing schedule and downtime must be
established. Of course, most end users ask for the most uptime possible. One of the best methods to
achieve maximum uptime is through the use of partitions.

As shown below, we created a partition for the Fact Internet Sales measure group. Now, when
processing the cube with new data, only the 2019 cube needs to be processed as new data is loaded.
Partitions allow for data to be broken done into smaller parts, most often by dates. Then the individual
partitions, which has data that has changed, can be processed while those partitions that have not
changed can be left alone which in turn leads to higher uptime. Of course, smaller partitions, means
faster processing times which in turn means smaller downtime windows.

4. Model Efficiency

SSAS cube development is a very mature process; two individuals, Inmon and Kimball, created two
different theories on the best options for creating a cube. These theories are not specific to SSAS, but
they do provide an exceptional baseline for creating a new OLAP data model. I am preferential to the
Kimball model and its focus on dimensional modeling. Dimensional modeling means the model should
focus on a star schema with fact tables and dimension tables, and it should use primary keys /
surrogate keys to link data from dimension tables to fact tables. It also means using fact tables with
the smallest / skinniest width; that means for instance using integers and not character fields or using
the smallest character fields possible.

Using the AdventureWorks cube, the below illustration shows an example of star schema with the
main Sales Summary Fact table surrounded by dimensional tables centering on currency, dates,
product (and product category), sales territory, and promotions.
5. Mind your Dates

Dates continue to be a vital part of just about most any data set. As such, it is extremely important to
plan for and manage the dates within the data model. The dataset may have a fiscal calendar and
normal calendar year calendar. Alternately, a 4-4-5 calendar may be needed. All these setups are
possible in SSAS cube, and it would be beneficial to setup during the modeling stage.

To control the exact dates, it is often helpful to create your own Date Dimension which can be
customized with the exact needs within your organization. As displayed below, this example calendar
dimension from AdventureWorks utilizes regular and fiscal calendars along with translations for day of
the week. Additional items that can be added are company holidays, weekend / weekday flags, even
special event flags such as a hurricane or maybe a flu outbreak.

Additionally, it is beneficial to create all the various variations of date dimensions that are needed. Do
you need day of week or week number? Or maybe, does your organization have a specific set of busy
days. As a best practice, setting up these items within your date dimension proves to be performant
and clearer for your end users to understand.

6. Data Dictionary Self Service

End users often want to explore data and love how easy it is to do such exploration via the use of a
pivot table. However, often these same end users will have questions about what makes up a
particular field, measure, or dimension. Within SSAS, each dimension attribute and measure provides
the ability to add a description. In the below illustration, a description is added to the Color attribute
within the Product dimension.
Although this description is not exposed directly within a pivot table, a data dictionary can easily be
created using these descriptions and the SSAS DMVs as displayed below.
By keeping the descriptions within SSAS, you are able to keep the maintenance within SSAS.
Furthermore, as you make changes to dimensions and measures, the descriptions can be changed
and updated at the same time.

Conclusion

In this tip we covered some of the various SSAS tips that I wish I knew when I started working with
SSAS. SSAS provides an exceptional way to aggregate various data points especially for very large
data sets. It offers the ability to link up a pivot table to the SSAS OLAP cube and produce a flexible
end user experience within Excel.

SQL Server Reporting Services Development Best Practices

Problem
Using the Business Intelligence Development Studio, you can bang out some fairly nice, basic reports
with the Report Wizard without much effort. But making your reports sizzle with all the bells and
whistles of a professionally created report, requires some customization. There are so many options
in all the object property windows, it is difficult for beginning users to know what they all do. How does
one know where to start and which options to learn first?

Solution
Check this crib sheet of some of the most commonly used properties options in the Microsoft SQL
2005 Report Designer. This list is by no means inclusive. There are many, many reporting options to
choose from. These are just a few that might give you the most bang for the buck, while not being as
obvious as some of the others.

Report Properties

To access the Report Properties, click on the little gray square in the top left corner or in the pale
yellow section outside the report layout area.

Once selected, the following properties areas are displayed.


Report Property options:

 SnapToGrid - For finer control of object sizes, set the SnapToGrid property to False. Once
done, you can resize rows, columns, textboxes, etc. to more exact dimensions.
 InteractiveSize - To achieve one long scrollable web page, change height property (expanc
InteractiveSize) to 0. Note: With reports that are very long, this can adversely affect report
rendering times. Experiment, use judgement, and obtain feedback from users. Educate your
users as to the pros and cons of this.
 PageSize - The default is 8.5in, 11in. This is a standard portrait letter size page size. For
landscape printing, swap the width and height (to 11in, 8.5in). Coordinate these changes with
the InteractiveSize. (i.e. If you want to print landscape, but see one long scrollable page in the
web browser before printing, set the InteractiveSize to a width of 11in, and a height of 0.)
 Description - With Reporting Services (RS) in Native mode (not Sharepoint Integration
mode), text you write in this property is displayed in the Report Manager and the WSS2
Reporting Services report viewer web part. For RS in Sharepoint Integration mode the entry
has no affect. (For Sharepoint Integrated installations, you can add a field to the reporting
document library and put the description there.)

Table Properties
Click on the top left square in a table to expose the table properties windows. When your table has
the control points exposed, you can access the table properties.

Table properties:

 DataSetName - Got have one, even if you are doing something creative like displaying some
sort of header table. Almost every report I create has a dataset called ‘header'. I use this with
a table to display the report logo graphic and some identifying fields (i.e. report runtime,
username, report title, etc). This dataset is just a placeholder without any real content.
Sometimes I use select statements like "Select getdate()" or "Select 1".
 NoRows - Depending on data selection criteria and/or parameters chosen by users, your
report may yield no results (no rows). (Or your backend server might be down...yikes!) This
option allows you to display a custom message to users in the event there is no data to
display. (i.e. "The parameters you chose contains no data...please change your parameter
choices and try rerunning the report".)
 FixedHeader - Set to "True", this is the same as the "Header should remain visible while
scrolling" checkbox in the Table Properties pop up window. It's really a slick feature.
Textbox properties within a table

 BackgroundColor - Background color of the textbox


 BorderStyle - I prefer "Solid" most of the time
 Color - Means font color
 Format - Used for various number, percentage, date, text formatting. For Dates without time
use ‘d'. For integers, use ‘N0'. For fixed decimals use N and then a number. ‘N4' is a number
with 4 decimals. Use ‘P1' for a percentage with 1 decimal place. Check BOL for more
formatting codes.
 Visibility - Another favorite, but deserves it's own tip. Another day...
 CanGrow - ‘True' most of the time, but I like to use ‘False' if I don't want lines to wrap. In that
event, I add the field to the Tooltip in the properties window of the textbox.

Group Properties

In the Properties section...

RepeatOnNewPage - Does what it implies.

Visibity - Use for drill downs.

Select the entire row of the group, right-click on it and select "Edit Group" (not Properties).

Don't forget to put in an option for Sorting the group.


(This isn't really a "Property", but it's in the "Grouping and Sorting Properties" configuration screen so
I though I would mention it.)

You might also like