Introduction to MSSQL Server 2000 Analysis Services: Another Approach to Local Cube Design and Creation - Page 7

June 21, 2004

With another selection in this dialog, we decide what kind of cube we want to create. Our choice here depends on several factors in our operating environment, including the amount of data our cube will contain; the type and complexity of reports we plan to create based upon our cube; and the memory, disk space and other resources on our systems (as well as those of the systems upon which the information consumers will be interacting with our cube).  Experience and planning will be our best guides to selecting the correct options, as we develop larger and more complex cubes for various organizational needs. Experience and planning will be our best guides as we develop larger and more complex cubes for various organizational needs.

The Save a cube file containing all data for the cube option creates a separate cube file on our PCs, retrieving all the data we have designated within our cube design, and storing it in this file. This selection is not appropriate in all situations, but might represent a good choice when:

• We are constructing and generating a cube for frequently changing interactive reports;
• The amount of disk space used by the file is not a limiting concern;
• We want to store the cube on a network server as a standalone source that information consumers can access to create their own reports (an alternative, but often innovative, use for a local cube. Local cubes are great to use for training sources for fledgling report writers, as well.)

A local cube file can act as an intermediate source of data from the original relational database that excludes source data to which we might want to prevent access. A local cube file can also provide a snapshot of some or all of the source database to facilitate offline access and analysis, either for a consumer community (for instance, on an isolated, separate network), or for a sole remote consumer or consumers.

As in most scenarios of variable processing and storage scenarios, resource and speed tradeoffs are a factor to consider. With the Save a cube file containing all data for the cube option, we can expect more time and resources to be necessary for the initial creation of the cube; but read operations, such as opening and modifying reports, will likely be faster (although cube size is a factor to consider in read speeds). In addition, the fact that the cubes we generate are self-contained is often a deciding factor for the selection of the Save a cube file containing all data for the cube option.

The sheer amount of the data we include in the cube, together with the number of dimensions and levels we attach to the model, are key factors in predicting ultimate cube size. Flatter hierarchies and filtered data selections are considerations in reducing cube size, as are other Cube Type options that can be selected on the Step 3 of 3 dialog. A close study of the options and prudent design of the cube, combined with testing in an appropriate development environment (and well facilitated by the ability to create and modify local cubes quickly and easily, as I have emphasized) will contribute heavily to efficient cube generation, delivery and overall operations.

For more information regarding the details of the various choices that appear on this dialog, as well as optimization techniques for cube building in general, see the Books Online that are installed with the Typical MSSQL Server 2000 / Analysis Services installation, or which can be accessed on the installation CDs or on the Microsoft MSSQL Server website.

MS Query prompts us to save the cube definition (.oqy) file, which is separate from the cube file that we create to store data. We can reuse the .oqy file in Excel for report creation or for other possible purposes later. When we chose the Save a cube file containing all data for the cube option at the last dialog, a file with a .cub extension was "scheduled" to be created, in a location to be specified. The .cub file actually contains the data for the cube, and is not created immediately when we click Finish. In our case, it is created when we save the cube definition as a file; once MS Query creates the OLAP query file, it hands off instructions to the PivotTable Service to use the newly saved definition to kick off creation of the local cube.

To modify our initial cube design, we have only to open the .oqy file to initialize the OLAP Cube Wizard once more. For more details regarding the .oqy files, see the MS Query Online Help.

The .oqy file is quickly saved, and the Creating Offline Cube dialog appears, and remains until the cube is created, confirming that the build is taking place.

We are returned to Microsoft Excel, where we are greeted by the PivotTable and PivotChart Wizard - Step 3 0f 3 dialog.

We see the standard PivotTable "map" appear, signaling that 1) we have a connection to the new cube and 2) that the cube is ready to be reported upon using standard PivotTable report procedures (see Reporting Options for Analysis Services Cubes: MS FrontPage 2002 for a step-by-step tutorial on PivotTable report navigation and use). The PivotTable report appears as shown in Illustration 16 below.

The cube is now ready for reporting, and, from the perspective of a reporting application, is in many ways identical to a server-generated cube.

Keep in mind that we can call Microsoft Query at any time to rapidly edit the initial .oqy file, so as to make modifications based upon the results obtained in reporting efforts, or as new requirements arise from the information consumers who test the new cube design in development. A quick rebuild of the cube will implant any changes, giving us the opportunity to immediately test for desired results again.

Summary ...

In this article, we continued our exploration of local cubes, using MS Office components to access the realm of OLAP data source design and creation. We created a local cube from an existing Excel PivotTable report in our previous session, and then we performed a step-by-step exploration of a more design-oriented route in this lesson, using the OLAP Cube Wizard, to accomplish cube creation in a more flexible manner.

We drilled into many practical aspects of putting the functionality to work immediately, discussing ways that local (or offline) cubes can meet the business requirements of distributed information consumers ( a topic we first introduced in the previous article, Introduction to Local Cubes), and can add value to the organization in general. Throughout our hands-on practice session of creating a local cube from a relational data source, we discussed the advantages of using our local cube design process as a flexible and portable means of rapidly prototyping enterprise OLAP data sources.

» See All Articles by Columnist William E. Pearson, III

Discuss this article in the MSSQL Server 2000 Analysis Services and MDX Topics Forum.