Você está na página 1de 21

articles >> business intelligence >> SQL Server Analysis Services ( SSAS ) ...

SQL Server Analysis Services ( SSAS ) - Introduction


By : S.Srivathsani
Aug 14, 2009


Microsoft SQL Server 2005 Analysis Services (SSAS) delivers both online analytical processing
(OLAP) and data mining functionality for business intelligence applications. Analysis Services
supports OLAP by letting the user design, create, and manage multidimensional structures that
contain data aggregated from other data sources, such as relational databases. For data mining
applications, Analysis Services lets the user design, create, and visualize data mining models,
constructed from other data sources by using a variety of industry-standard data mining
algorithms.
OLAP
Online analytical processing (OLAP) allows the user to access aggregated and organized data
from business data sources, such as data warehouses, in a multidimensional structure called a
cube. Microsoft provides tools and features for OLAP that user can use to design, deploy, and
maintain cubes and other supporting objects.
Cubes in a data warehouse are stored in three different modes. A relational storage model is
called Relational Online Analytical Processing mode or ROLAP, while a Multidimensional
Online Analytical processing mode is called MOLAP. When dimensions are stored in a
combination of the two modes then it is known as Hybrid Online Analytical Processing mode or
HOLAP.

MOLAP
MOLAP (multidimensional online analytical processing) is online analytical processing (OLAP)
that indexes directly into a multidimensional database. In general, an OLAP application treats
data multidimensionally; the user is able to view different aspects or facets of data aggregates
such as sales by time, geography, and product model. If the data is stored in a relational data
base, it can be viewed multidimensionally, but only by successively accessing and processing a
table for each dimension or aspect of a data aggregate. MOLAP processes data that is already
stored in a multidimensional array in which all possible combinations of data are reflected, each
in a cell that can be accessed directly. For this reason, MOLAP is, for most uses, faster and more
user-responsive than relational online analytical processing (ROLAP), the main alternative to
MOLAP.
ROLAP
Relational online analytical processing (ROLAP) is a form of online analytical processing
(OLAP) that performs dynamic multidimensional analysis of data stored in a relational database
rather than in a multidimensional database (which is usually considered the OLAP standard).
Data processing may take place within the database system, a mid-tier server, or the client. In a
two-tiered architecture, the user submits a Structure Query Language (SQL) query to the
database and receives back the requested data. In a three-tiered architecture, the user submits a
request for multidimensional analysis and the ROLAP engine converts the request to SQL for
submission to the database. Then the operation is performed in reverse: the engine converts the
resulting data from SQL to a multidimensional format before it is returned to the client for
viewing. Since ROLAP uses a relational database, it requires more processing time and/or disk
space to perform some of the tasks that multidimensional databases are designed for. However,
ROLAP supports larger user groups and greater amounts of data and is often used when these
capacities are crucial, such as in a large and complex department of an enterprise.
HOLAP
Hybrid online analytical processing (HOLAP) is a combination of relational OLAP (ROLAP)
and multidimensional OLAP (usually referred to simply as OLAP). HOLAP was developed to
combine the greater data capacity of ROLAP with the superior processing capability of OLAP.
HOLAP can use varying combinations of ROLAP and OLAP technology. Typically it stores data
in a both a relational database (RDB) and a multidimensional database (MDDB) and uses
whichever one is best suited to the type of processing desired. The databases are used to store
data in the most functional way. For data-heavy processing, the data is more efficiently stored in
a RDB.For speculative processing, the data is more effectively stored in an MDDB.
HOLAP users can choose to store the results of queries to the MDDB to save the effort of
looking for the same data over and over which saves time. Although this technique - called
"materializing cells" - improves performance, it takes a toll on storage. The user has to strike a
balance between performance and storage demand to get the most out of HOLAP. Nevertheless,
because it offers the best features of both OLAP and ROLAP, HOLAP is increasingly preferred.
Data Mining
Data mining gives the user access to the information that is needed to make intelligent decisions
about difficult business problems. Microsoft provides tools for data mining with which user can
identify rules and patterns in the data, so that the user can determine why things happen and
predict what will happen in the future. While creating a data mining solution in Analysis
Services, user first creates a model that describes the business problem, and then user runs the
data through an algorithm that generates a mathematical model of the data.User can then either
visually explore the mining model or create prediction queries against it. Analysis Services can
use datasets from both relational and OLAP databases, and includes a variety of algorithms that
can be used to investigate that data.
Analysis Services Architecture
SSAS use server and client components to supply OLAP and data mining.
Server Architecture
The server component of SSAS is the msmdsrv.exe application, which runs as a Windows
service. SSAS supports multiple instances on the same computer, with each instance of Analysis
Services implemented as a separate instance of the Windows service. The msmdsrv.exe
application consists of security components, an XML for Analysis (XMLA) listener component,
a query processor component and numerous other internal components that perform the
following functions:
Parsing statements received from clients
Managing metadata
Handling transactions
Processing calculations
Storing dimension and cell data
Creating aggregations
Scheduling queries
Caching objects
Managing server resources
The XMLA listener component handles all XMLA communications between Analysis Services and its
clients. The Analysis Services Port configuration setting in the msmdsrv.ini file can be used to specify a
port on which an Analysis Services instance listens. A value of 0 in this file indicates that Analysis
Services listen on the default port. The default instance of Analysis Services listens on TCP/IP port 2383,
but named instances of Analysis Services do not use a default port. Each named instance listens either on
the port that an Administrator specifies, or on the port that is dynamically assigned at startup. This
variability among ports means that clients do not automatically know which port a particular named
instance of Analysis Services is using, and therefore do not automatically know where to send their
requests. To make it easy for clients to send requests to named instances of Analysis Services, SQL
Server has a service called SQL Server Browser. SQL Server Browser keeps track of the ports on which
each named instance listens. Client connection requests for a named instance that do not specify a port
number are directed to port 2382, the port on which SQL Server Browser listens. SQL Server Browser
then redirects the request to the port that the named instance uses.
Client Architecture
Client components communicate with Analysis Services using the public standard XML for Analysis
(XMLA), a SOAP-based protocol for issuing commands and receiving responses, exposed as a Web
service. Client object models are also provided over XMLA, and can be accessed either by using a
managed provider, such as ADOMD.NET, or a native OLE DB provider.
Several different providers are provided with Analysis Services to support different
programming languages. A provider communicates with an Analysis Services server by sending
and receiving XML for Analysis in SOAP packets over TCP/IP or over HTTP through Internet
Information Services (IIS). An HTTP connection uses a COM object instantiated by IIS, called a
data pump, which acts as a conduit for Analysis Services data.

Win32 client applications can connect to an Analysis Services server using OLE DB for OLAP
interfaces or the ActiveX Data Objects (ADO) object model for Component Object Model
(COM) automation languages, such as Visual Basic. Applications coded with .NET languages
can connect to an Analysis Services server using ADO MD.NET.
Query commands can be issued using the following languages:
1) SQL
2) Multidimensional Expressions (MDX), an industry standard query language for analysis
3) Data Mining Extensions (DMX), an industry standard query language for data mining.
4) Analysis Services Scripting Language (ASSL) can also be used to manage Analysis Services
database objects.
Unified Dimension Model
Analysis Services combines the best aspects of traditional OLAP-based analysis and relational-
based reporting by enabling developers to define a single data model, called a Unified
Dimensional Model (UDM) over one or more physical data sources. All end user queries from
OLAP, reporting, and custom BI applications access the data in the underlying data sources
through the UDM, which provides a single business view of this relational data. The UDM is a
central place that serves as the single version of truth for all reports, spreadsheets, OLAP
browsers, KPIs, and analytical applications.
If the user wants to retrieve information directly from a data source, faces a lot of problems. It can be
possible that the content of data sources is hard to understand. Information might be distributed across
multiple heterogeneous databases .This makes the access to data more difficult because the user has to
understand the SQL used. There are queries that support business decision-making. These queries involve
increased data volumes. The time that is required to retrieve such summary values for interactive end-user
analysis can be prohibitive. Heres where the role of UDM comes into play.UDM acts as a bridge
between the user and data sources. A UDM is constructed over one or more physical data sources. The
user issues queries against the UDM using a variety of client tools, such as Microsoft Excel.
UDM offers the following advantages:
Simpler Data model
Client is isolated from the heterogeneous backend data sources.
Provides high performance in case of queries that support interactive analysis, even over large
data volumes. This is achieved by caching.
UDM helps to capture the business rules in the model
UDM Architecture
The UDM is defined over one or mode data sources. These data sources can be of a variety of types,
including:
Relational databases;
Web Services;
Files.


SQL Server Analysis Services - Multidimensional
Data
SQL Server 2008 R2
Other Versions

Microsoft SQL Server Analysis Services
Multidimensional Data allows you to design, create, and
manage multidimensional structures that contain detail
and aggregated data from multiple data sources, such as
relational databases, in a single unified logical model
supported by built-in calculations.
Analysis ServicesMultidimensional Data provides fast,
intuitive, top-down analysis of large quantities of data
built on this unified data model, which can be delivered
to users in multiple languages and currencies.
Analysis ServicesMultidimensional Data works with
data warehouses, data marts, production databases and
operational data stores, supporting analysis of both
historical and real time data.
Browse Content by Life Cycle
Product Evaluation
Getting Started
Planning and Architecture
Development
Deployment
Operations
Security and Protection
Technical Reference



Data Source Views (Analysis Services -
Multidimensional Data)
SQL Server 2008 R2
Other Versions

A data source view contains the logical model of the schema used by Analysis Services database objects
namely cubes, dimensions, and mining structures. A data source view is the metadata definition, stored in an
XML format, of these schema elements used by the Unified Dimensional Model (UDM) and by the mining
structures. A data source view:
Contains the metadata that represents selected objects from one or more underlying data sources, or the
metadata that will be used to generate an underlying relational data store. For more information, see Designing
Multidimensional Objects without an Existing Relational Schema, and Defining Data Sources (Analysis Services).
Can be built over one or more data sources, letting you define OLAP and data mining objects that integrate
data from multiple sources.
Can contain relationships, primary keys, object names, calculated columns, and queries that are not present in
an underlying data source and which exist separate from the underlying data sources.
Is not visible to or available to be queried by client applications.
A data source view gives you flexibility in constructing objects in SQL Server Analysis Services, SQL
Server Integration Services, and SQL Server Reporting Services, in that Analysis Services database objects are
bound to the logical objects contained in the data source view, instead of being directly bound to the
underlying physical objects in the underlying data sources. Therefore, you can define logical objects, such as
calculated columns or named queries, that do not exist in an underlying data source and which you might not
have permissions to define in an underlying data source.
A data source view is a logical representation of the data that is used by Analysis Services objects. A data source
view is built from the data sources already defined in the database. A data source view contains the metadata
that is required to build the data model required by an Analysis Services object. A data source view can build
the data model from some of the data elements in one data source, or it can build the data model from
multiple elements from different data sources. A data source view can contain relationships, calculated columns,
and queries that are not present in the underlying data sources.

Data Source Views (Analysis Services -
Multidimensional Data)
SQL Server 2008 R2
Other Versions

A data source view contains the logical model of the schema used by Analysis Services database objects
namely cubes, dimensions, and mining structures. A data source view is the metadata definition, stored in an
XML format, of these schema elements used by the Unified Dimensional Model (UDM) and by the mining
structures. A data source view:
Contains the metadata that represents selected objects from one or more underlying data sources, or the
metadata that will be used to generate an underlying relational data store. For more information, see Designing
Multidimensional Objects without an Existing Relational Schema, and Defining Data Sources (Analysis Services).
Can be built over one or more data sources, letting you define OLAP and data mining objects that integrate
data from multiple sources.
Can contain relationships, primary keys, object names, calculated columns, and queries that are not present in
an underlying data source and which exist separate from the underlying data sources.
Is not visible to or available to be queried by client applications.
A data source view gives you flexibility in constructing objects in SQL Server Analysis Services, SQL
Server Integration Services, and SQL Server Reporting Services, in that Analysis Services database objects are
bound to the logical objects contained in the data source view, instead of being directly bound to the
underlying physical objects in the underlying data sources. Therefore, you can define logical objects, such as
calculated columns or named queries, that do not exist in an underlying data source and which you might not
have permissions to define in an underlying data source.
A data source view is a logical representation of the data that is used by Analysis Services objects. A data source
view is built from the data sources already defined in the database. A data source view contains the metadata
that is required to build the data model required by an Analysis Services object. A data source view can build
the data model from some of the data elements in one data source, or it can build the data model from
multiple elements from different data sources. A data source view can contain relationships, calculated columns,
and queries that are not present in the underlying data sources.

Designing Data Source Views (Analysis
Services)
SQL Server 2008 R2
Other Versions

Online analytical processing (OLAP) and data mining projects in Microsoft SQL Server are designed based on a
logical data model of related tables, views, and queries from one or more data sources. This logical data model
is called a data source view. A data source view is an object that contains the metadata from selected data
source objects, including any relationships between these objects defined in the underlying data source or
defined in the data source view. A data source view caches the metadata from the data sources that the view is
built upon. The cached metadata lets you develop an Analysis Services project without a continuous active
connection to the data source.
Data source views let you define a subset of the data that populates a large data warehouse. Additionally, they
let you define a homogenous schema based on heterogeneous data sources or subsets of data sources.
Because data source views represent an isolated schema, you can add any required annotations without
affecting the schemas of the underlying data sources
A data source view contains the following items:
A name and a description.
A definition of any subset of the schema retrieved from one or more data sources, up to and including the
whole schema, including the following:
o Table names.
o Column names.
o Data types.
o Nullability.
o Column lengths.
o Primary keys.
o Primary key - foreign key relationships.
Annotations to the schema from the underlying data sources, including the following:
o Friendly names for tables, views, and columns.
o Named queries that return columns from one or more data sources (that show as tables in the schema).
o Named calculations that return columns from a data source (that show as columns in tables or views).
o Logical primary keys (needed if a primary key is not defining in the underlying table or is not included in the
view or named query).
o Logical primary key - foreign key relationships between tables, views, and named queries.
Using Data Source Views for Different Objects

Analysis Services design tools use data source views to maintain a cache of relational metadata and to take
advantage of some of the annotations within a data source view. By describing a subset of tables and views in a
data source, a data source view makes available only the tables required by OLAP and data mining objects. A
data source view handles the layout of tables, filters, SQL expressions, relationships, and other complexities of
the schema. Therefore, a data source view enables simple bindings by Analysis Services cubes, dimensions, and
mining models to the tables and columns in the data source view.
You can build multiple data source views in an Analysis Services project or database on one or more data
sources and construct each one to satisfy the requirements for a different solution.
A single data source view supports multiple diagrams that show different subsets of the data source view.
Sometimes, you may use separate diagrams to work with sections of a data source view that pertain to a
particular object. Unlike different data source views, different diagrams reference the same schema. Therefore,
any changes made in one diagram apply to all other diagrams in the data source view.
If a data source contains fields that are of the tinyint datatype and the AutoIncrement property is set to True,
then they will be converted to integers in the data source view.
Working with Multiple Data Sources

When defining a data source view that contains tables, views, or columns from multiple data sources, the first
data source from which you add objects to the data source view is designated as the primary data source (you
cannot change the primary data source after it is defined). After defining a data source view based on objects
from a single data source, you can then add objects from other data sources. If an OLAP processing or a data
mining query requires data from multiple data sources in a single query, the primary data source must support
remote queries using OpenRowset. Typically, this will be a Microsoft SQL Server data source. For example, if you
design an OLAP dimension that contains attributes that are bound to columns from multiple data sources, then
Analysis Services will construct an OpenRowset query to populate this dimension during processing. However, if
an OLAP object can be populated or a data mining query resolved from a single data source, then an
OpenRowset query will not be constructed. In certain situations, you may be able to define attribute
relationships between attributes to eliminate the need for an OpenRowset query. For more information about
attribute relationships, see Attribute Relationships and Defining Attribute Relationships.

Speaking the language of business intelligence with a Microsoft accent
Sunday, October 9, 2005
SSRB - SSAS Report Models
Recently two of my colleagues asked me if it was possible to give users
access to SSAS cubes via Report Builder (SSRB). My answer was an
immediate no. I had always thought that report models had to be built in
BIDS (Business Intelligence Development Studio) and be based on a DSV
which we must first create. Because we're basing the model on a DSV we
then can't take advantage of all the dimensions, perspectives, KPIs etc.etc.
created through the cube designer. I have since discovered that I was
wrong, completely wrong. We can generate (and regenerate) a Report Model
based on an SSAS cube.

SSAS-based report models can be created using "Generate Model" either in
Report Manager or in Management Studio (when connected to the Report
Server). Generate Model is a function exposed on data sources which have
been deployed to the Report Server. Both relational and SSAS models can
be generated this way.

In Management Studio right-click the data source and select "Generate
Model"


... or in IE through Report Manager. Go to the properties of a data source
and you will find the Generate Model button at the bottom of the screen.











The resultant SSAS report model contains structures based on dimensional
relationships to measure groups as well as perspectives defined in the
source cube. Even KPIs (and access to their display images) are included in
the model. One thing that we do not get, however, are structures which
mimic the attribute hierarchies. Nonetheless the attributes that make up the
hierarchies are all there.













Does the newly generated model interrogate the OLAP cube on which it was
based, not just simply back to the original base DSV? A quick Profiler trace
while using the model in Report Builder proves that MDX is being generated
and sent to the Analysis Server - no relational queries.

If the cube structure ever changes on the server just hit the "Regenerate
Model" button on the properties page of the model in Report Manager or
"Update Model" in Management Studio. This will bring the model back into
synch.
Posted by Nick Barclay at 1:25 AM
Labels: Report Builder, SSAS


wall
Forums
Articles
Blogs
Events

Files



manage space
Reporting on an SSAS Cube with SSRS 2008
Comments (4)
Forward to a friend
article

Print
Rating: 5/5 2 Votes
change text size: A A A
Published 5/7/2010 11:23:53 PM by DustinRyan
If you're like me, you're not exactly what someone would call a "Jedi Master" of MDX. So if
someone asked you to report on an Analysis Services Cube, you might feel a little intimidated.
Well have no fear. Reporting from a cube is easier than you may think. In this article, I'm going
to cover the basics of building a report on a cube using SSRS 2008 and the MDX Query
Designer.
You could be wondering why someone would want to report on a cube with SSRS 2008. After
all, building a static report kind of eliminates the cool factor of being able to drag and drop
different measures and dimensions enabling adhoc reporting. So why report on a cube?
The data is pre-aggregated! Reporting on the cube allows you to easily display aggregations
across multiple groups in your reports.
Results of multi-dimensional queries are returned very quickly. This means that if you are trying
to show many different measures with their aggregations across several different groups with a
time parameter, your query will probably run much quicker in MDX executed against the cube
as opposed to using some heinous T-SQL query.
Lastly, a cube is designed to answer analytical questions about your data, which is what many
end users are looking for.
Let's get started on building our report on a cube. In this demonstration, I'm using the Adventure
Works cube. The first thing we need to do is create a report project.
1. Open BIDS, go to File, click New, and select Project. Then click Report Server Project and
click OK.

2. Next, we need to create a Shared Data Source to the Adventure Works cube. To do this, right-
click Shared Data Source and click Add New Data Source. Give your Data Source a Name and
in the drop down list under type, select Microsoft SQL Server Analysis Services. Click Edit, type
in your Server name and select the correct database. Click OK twice.
3. Now that we have created the Shared Data Source, its time to start building our report. In the
Solution Explorer, right-click the Reports folder, (and because I don't like to use the wizard)
select Add, then click New Item. Select Report, name your report in the Name text box, and click
Add.
4. Then in the Report Data window, create a new data source. Name your data source something
pertinent, like AWCube, and click the shared data source reference and select the Shared Data
Source you just created.

5. Then right-click your newly created data source and select Add Dataset. Then click Query
Designer. This is where you will build your MDX query. The Query Designer will allow you to
graphically build your MDX query without requiring any knowledge of MDX.

6. To build the query, you can expand the folders containing your dimensions and measure and
drag them into the design area. As you drag the members and measure into the design area, the
Query Designer will attempt to execute the query to give you a preview of what the flattened
data will look like. For this example, I dragged in Reseller, Department, Title, and Employee for
the dimensions. The measures I used were Reseller Order Quantity and Reseller Sales Amount.
7. I also wanted to add a date range parameter. At the top of the Query Designer in the
Dimension column, select Date as the dimension. In the Hierarchy column, select a date
hierarchy. For the Operator, select Range (Inclusive). And for the filter expression, select " : ".
Then in the Parameters column, check both check boxes. I also wanted to added a Parameter so
the end users can filter the reports by Reseller. So I selected the Reseller as the dimension and
hierarchy. For the Operator, I specified it as Equal and I left the Filter column blank. Lastly, I
checked the check box in the Parameters column. This is what it should look like:

8. You can also filter your MDX query. For my query, I only wanted to see Resellers with a
Reseller Type of Specialty Bike Shop. Under dimension I selected Reseller, under Hierarchy I
selected Business Type, for the Operator I selected Equal and under Filter Expression I selected
{Specialty Bike Shop}. But this time do not check the check box under Parameters since this is
not a parameter, just a filter.
9. If you wanted to create a Calculated Members, right click in the Calculated Members and
select New Calculated Members. This will open the Calculated Member Builder. You can drag
in different measures and dimensions to build your Calculated Member. Here is an example of a
simple calculated member that adds Internet Standard Product Cost to Internet Tax Amount to
get Total Cost:

10. To view the MDX generated by the Query Designer, click the icon at the top of the Query
Designer. J ust a note: I f you make any changes to the MDX while viewing it, you cannot go
back to the MDX Query Designer. Once you are done building your query, click OK. You can
now use the fields specified within your report. After dragging the fields into my tablix and
adding a few groups, here is the finished results of my report:

Here are few other links to some articles I've written involving MDX and reporting:

Você também pode gostar