exerCise 15-1. Creating a sQl VieW report
3. Click the “new folder” button at the top of the save As dialog window to create a new
4. select the ExcelReports folder and save the Excel report file as SalesReport.xlsx (figure 15-12).
now that you have created a report based on a sQl view, we will move on to creating ssAs cube-based reports, so please leave Excel open for now.
Changing Connection Properties
If Excel forced you to use a single SQL view per spreadsheet, it would be unreasonably restrictive, because each view may have only some of the data you need. Luckily, you can either add another report to the same Excel spreadsheet or reconfigure your existing report.
To add a different report to the spreadsheet, restart the wizard and select another view. You can then use the data in the view to make another report on the same or separate worksheet tab.
To change an existing pivot table report, reconfigure the connection property to point to a different view within the data warehouse.
Figure 15-12. The Excel Save As dialog window
Reconfiguring a Connection
To reconfigure the connection, your first step must be to make sure you have selected the pivot table in the Excel worksheet. Then navigate to the Data tab and click the Properties button in the Ribbon. Once you do this, a properties dialog window appears (Figure 15-13).
Tip
■ Remember that the Ribbon’s buttons change appearance depending on the screen resolution, so your Ribbon may look slightly different!
Figure 15-13. Opening the connection properties
You can access and change the command text by navigating to the Definition tab in the Connection Properties dialog window. In Figure 15-13, the existing command is pointing to the view called
vQuantitiesByTitlesDate. If we change this to point to another view, like the vAllTables (created in this chapter by the SQL script file), we can access the information from it and create a pivot table based on its data. Figure 15-14 shows this change.
If you look closely at Figure 15-14, you can see that the command type is set to Table. This setting includes both tables and views, so currently nothing needs to be changed to make this work. Changing this setting to use a SQL statement, however, allows you to get different data for your report by adding your own custom SQL code.
This means the SQL table or view used in the report will be entirely different than what was originally stored in the .odc file. A dialog box warning you of this appears after you change the SQL statement and click OK.
The message looks pretty official, but if you want to see the new data, you will have to click Yes to continue making the change. Figure 15-15 shows an example of this warning message. (It’s a very long message, so we cut some of it out.)
Figure 15-14. Changing the command text to the vAllTables view
Note
■ This will not save your query changes in the .odc file, but it will allow you to change it for the moment.
if you want to make a more permanent change, navigate to a new worksheet and start the Connection wizard again.
You can also save your changes by clicking the Export Connection file button, as shown in figure 15-14, if you think you will want to reuse this connection and statement for a later report.
Next is to design the report. Any fields that were common between the two views may still be in the pivot table report, and they can easily be removed by dragging and dropping them back from the report and into the field list. But, afterward, creating a new report is just as simple as creating the first. By dragging and dropping the fields from the field list into the Pivot Table Report area or using the designer areas below the field list, you can create a report that looks something like the one shown in Figure 15-16, which now has the additional data warehouse columns, such as TitleName, TitleType, and YearName.
Figure 15-16. A PivotTable report that uses the vAllTables view Figure 15-15. Accept the warning to make the change
Using Stored Procedures
Views are only one example of how you can interact with SQL Server. You can also make Excel reports using a stored procedure. This may not be obvious since the user interface does not show you that as an option, but by going to the connection properties once again, you can change the settings to accomplish this. First you need to change the command type from a table to a SQL statement and then change the command text from the name of a view to the name of a stored procedure (Figure 15-17). Configuring just these two settings will allow you to use a stored procedure for your report.
Figure 15-17. Changing the command type to SQL and command text to use a stored procedure
Note
■ since stored procedures often use parameters, it seems odd that the Parameters button is not available.
This button is enabled only when there are parameters defined using the Microsoft Query add-on for Excel. This add-on is, more often than not, unavailable on most computers. As such, we will not be including examples of how to use this feature. As you can see in figure 15-16, you can still provide parameter values as part of your sQl code.
Once you have clicked OK, the data in the pivot table report will change based on the results of the select statement inside the reporting stored procedure. (You created the stored procedure by running the SQL code in Exercise 15-1.) The results of this procedure included publisher, title, dates, and a number of measured values including a KPI value, filtered by only titles that start with the letter C (Figure 15-18).
Figure 15-18. Reporting from a stored procedure
Working with Excel Reports from a Cube
The stored procedure and view are common ways to generate reports from a data warehouse. The stored procedures and views can be very restricted unless all the data from all the tables in the data warehouse are queried. The second view, vAllTables, did select data from all the tables in the data warehouse, but this is impractical for most occasions. If the data warehouse gets very large with lots of tables, columns, and rows, your view will be slow and cumbersome.
One of the advantages of using a cube is that all the data from the cube is easily accessible from client software such as Excel. From Excel’s perspective, it is as though all the tables have been combined into one single object—the cube. As stated previously, you can think of a cube as a set of one or more relational tables combined.
You can really see how this analogy fits from the perspective of reporting applications.
Connecting to Your Cube
To connect to the cube, access the Data tab and select the From Other Sources button. Next, click the From Analysis Services button to connect to SSAS (Figure 15-19).
The Data Connection Wizard appears and walks you through the same process as when you were making a connection to the SQL Server data warehouse. The initial dialog window looks identical to the dialog window that connects you to SQL Server (Figure 15-20). Enter the name of your SSAS server, and use Windows Authentication to connect to it.
Tip
■ ssAs can use windows Authentication only. This is not true of the sQl server database engine, which can use both text-based and windows security logins. Because the Data Connection wizard is designed to work with both types of connections, the option, mistakenly, looks like it is available.
Figure 15-19. Starting a connection to SSAS
You will have verification that you are connecting to SSAS rather than SQL Server on the following screen.
In the dialog window shown in Figure 15-20, select the cube that you want to use rather than a view or table. Like tables, cubes are grouped into databases, so you must select the appropriate database before the cube can be displayed. Figure 15-21 shows that we are connecting to the PubsBICubes database and selecting the cube called CubePubsSales, which in this case is the only available option.
When you click Next, you will be asked where to save the .odc file once again. The default values will work fine for almost all occasions. Clicking Finish ends the Data Connection Wizard.
Figure 15-20. Making a connection to SSAS
After clicking Finish, you can create a report just like you did using a view or stored procedure in the SQL Server database engine. The difference is that items in the PivotTable Field List area are now better organized by measures, dimensions, hierarchies, levels, and attributes. This makes it much easier for report users to create the reports they want. Figure 15-22 shows an example report made from the cube.
Figure 15-21. Selecting objects from your SSAS server
Testing Your Reports
Do not expect your reports to be perfectly accurate. It is always important to validate your data. In Chapter 11, we cautioned you about the possibility of making incorrect aggregations when we reviewed the Calculations tab of the Cube Editor. The issue concerned members that were added to the cube as either derived or calculated members. It is very important to make sure your reports are correct; therefore, let’s take a moment to review the differences between these two member types.
A derived member is added by including SQL code in an SSAS data source view. When the data is pulled from SQL Server into the cube during processing, the expression that makes up the derived member is executed.
Think of it this way: a first aggregation is performed by SQL Server, and the results are stored on the hard drive as part of the cube. After that, a second aggregation is performed when a report is created using the cube.
For example, if we created a derived member that multiplies the vales for sales quantity by a title’s price, that expression would look something like this:
[FactSales].[SalesQuantity] * [DimTitles].[TitlePrice]
Imagine that we have a sales quantity value of 100 and a title’s price value of $30. The expression would evaluate to $300. And this new value would be stored in the cube as a derived member. After the cube stored the values, it would later aggregate to get totals and subtotals when the report was created. Figure 15-23 shows an example.
Figure 15-23. Aggregates with a derived member
Things are a bit different with calculated members. A calculated member never stores data in the cube.
Instead, it stores only the MDX code for the expression. The evaluation of the expression happens each time a report is made. Figure 15-24 highlights this process.
Both the derived and calculated members have their places, and both are useful tools when used under the right circumstances. In general, you can use derived members to store the aggregate values within SSAS and speed up the report generation, or you can use calculated members to decrease the amount of time it takes to process aggregates to the hard drive. And, always make your final decision about which to use depending on which one gives you the correct answer.
Tip
■ Just like in a math problem that uses both addition and multiplication, if the order of operations is not specified correctly, the answer will be incorrect. in Chapter 11, Exercise 11-3, we created both a derived measure and a calculated measure and then verified that only one was correct. You may be asking, “How will i know which one to use?” while you can take the time to examine each calculated member and manually crunch the numbers to determine which would be appropriate, the one to use is the one that, when executed, actually works. if they both give the same answer, choose derived for report performance and calculated for processing performance.