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: