Guest Author: Dan Clark , Senior BI Consultant, Pragmatic Works
Introduction
The goal of this blog series is to expose you to the process needed to create a BISM Tabular Model in SQL Server 2012 and deploy it to an Analysis Server where it can be exposed to client applications. Part 1 covered setting up a tabular model project and importing data into the tabular model. Part 2 looked at table relations, implementing calculations and creating measures with DAX. The third segment dealt with time based analysis, implementing semi-additive measures and securing the model. Today we conclude the series by looking at how you deploy the model and connect to the tabular model from a client application.
Deploying a Tabular Model
After you create and test a tabular model, it has to be deployed to a SSAS server running in tabular mode. Once the solution is deployed users can browse the model using a client application such as a Reporting Services report, Power View or Excel.
The project deployment options, which you can open by right-clicking on the project and selecting properties, determine where the project gets deployed and whether it should be processed (Figure 1). You set options for your test, staging, and production environments depending on your deployment rules. The processing options available are default, do not process, and full. The default setting performs the processing needed to deliver unprocessed or partially processed objects to a fully processed state. Data for empty tables and partitions is loaded. If necessary, hierarchies, calculated columns, and relationships are built. When Process Full is run for an object that has already been processed, Analysis Services drops all data in the object, and then processes the object. All related hierarchies, calculated columns, and relationships are rebuilt.
Figure 1 – Setting Deployment Options
You can also indicate whether or not you want a transactional deployment. When set to true, both the deployment and processing are completed as a single transaction. If the processing fails, the deployment gets rolled back.
Once these properties are set, you can right-click on the project node in the Solution Explorer and select Deploy. When the project is deployed, it first gets built. Building the project creates the necessary files in the bin subfolder of the project folder. The Model.asdatabase file contains the declarative definitions for all the Analysis Services objects in the project. The Model.deploymentoptions file contains deployment options, such as whether deployment is transactional and whether deployed objects should be processed after deployment. The Model.deploymenttargets file contains the name of the Analysis Services instance and database in which the objects will be created. Once these files are created they are used to deploy the project to the server. Figure 2 shows a tabular model deployed to an Analysis Server.
Figure 2 – Viewing the Tabular Model in SSAS
There are a number of other ways you can deploy a model to an Analysis Server. Among the most popular are XMLA script, the Deployment Wizard, the Synchronize Database Wizard, and Backup and Restore. (For more information on these deployment methods see “Tabular Model Solution Deployment (SSAS Tabular)”.
Connecting to a Tabular Model
The most common client applications connecting to a tabular model are Excel, SSRS 2012 Reports, Power View (Hosted in SharePoint 2010) and PerformancePoint dashboards. Although I am not going to go into great detail about these applications, I do want to show you how easy it is to connect to a tabular model.
Reporting Services uses a Microsoft SQL Server Analysis Services connection type with a connection string indicating the Analysis Server and the tabular model. This creates a Reporting Service shared data source (.rds). Figure 3 shows a connection being made to the AWSalesTabularModel.
Figure 3 – Connecting to a Tabular Model
After setting up the connection to the model, you get a query designer showing the tables (as dimensions), measures, and KPIs you have access to in the model (Figure 4). Notice the query designer currently used in SSRS is an MDX based design experience and does not support DAX based queries. Hopefully DAX query support will be added in a future version.
Figure 4 – SSRS Query Designer
Once the data query is created you can create a report based on the query. Figure 5 shows a simple report based on the AWSalesTabularModel. (For more information on creating SSRS reports refer to the series “Intro to SSRS Basic Report Writing” by Sherri McDonald at www.bidn.com)
Figure 5 – Tabular Model Based Report
To connect to the tabular model in Excel you set up an Office Data Connection as shown in Figure 6. Once the connection is made, you can explore the model using an Excel pivot tables and charts.
Figure 6 – Creating an Office Data Connection to the Tabular Model
Power View is a SSRS 2012 add-in for SharePoint 2010 providing an interactive experience for the end user. It can use a SharePoint Reporting Service shared data source (.rsds) or a BI semantic connection (.bism) hosted in SharePoint. The SharePoint Reporting Service shared data source is the same as the Reporting Service shared data source (.rds) created in Reporting Services just in a slightly different format. Setting up a BI semantic connection in SharePoint is shown in Figure 7.
Figure 7 - Setting up a BI Semantic Connection in SharePoint
Once the BI semantic connection is made, an interactive Power View can be created using the connection. Figure 8 shows the Power View design window. (For more information on Power View see the tutorial “Create a Sample Report in Power View” on the Microsoft TechNet Wiki.)
Figure 8 – The Power View Designer
Another popular client application for creating and deploying dashboards containing KPIs, Scorecards, and reports is PerformancePoint Services 2010. This is another service hosted in SharePoint 2010. By creating a data source that points to the BISM Tabular Model hosted on SSAS, you can develop dashboards based on the Tabular Model. Figure 9 shows a sample dashboard from the webinar “Zero to Dashboard – Intro to PerformancePoint” available at www.pragmaticworks.com.
Figure-9 PerformancePoint 2010 Dashboard
Summary
I hope you have enjoyed this blog series. The goal was to expose you to the process needed to create a BISM Tabular Model in SQL Server 2012. The tabular model is based on a relational table model which is more familiar to DBA’s, developers, and power users. The tabular model forms the foundation of Microsoft’s self-service BI initiative. If you are charged with providing a BI environment to business users, it is imperative that you understand how these technologies work and fit together. You should now have a better understanding of the process needed to create a BISM Tabular Model and deploy it to an Analysis Server where it can be exposed to client applications.