Cube Viewer - Designing Your Cube

In the last Cube Viewer article we outlined a generic process for building a cube, but the first step on this process is to actually design the data we want to analyze in the cube. A common misconception with Cube Viewer is that you can take an query and convert it into a cube for analysis. This is not exactly true as Cube Viewer is really designed for particular types of analysis and should be used for those types of analysis to take full advantage of the capability.

The easiest way of deciding what type of analysis are optimal for the Cube Viewer is to visualize your end result. This is not a new technique as most designers work from what they want to determine the best approach. The easiest way I tend to visualize the Cube Viewer is to actually visualize the data in a more analytical view. If you are familiar with the "Pivot" functionality that is popular in spreadsheet programs then that is the idea. The pivot allows for different columns in a list to be combined in such a way to provide more analytical information. A very simple example is shown below:

The above example we have three columns, two are considered dimensions (how we "cut" the data) and one the value we want to analyze. The pivot relationship in the above example is between Column A and Column B.

In Cube Viewer there are three concepts:

• Dimensions. These are the columns used in the analysis. Typically dimensions represent the different ways you want to view the data in relation to other dimensions.
• Filters. These act on the master record set (the data you want to use in the analysis) to refine the subset to focus upon. For example, you might want to limit your analysis to specific date ranges. By their nature, Filters can also become dimensions in a cube.
• Values. These are the numeric values (including any functions) that need to analyzed.

Note: Filters and Values can be considered dimensions as well due to the interactivity allows in the Cube Viewer.

When designing your cube consider the following guidelines:

• Dimensions (including filters) define the data to analyze. The dimensions and filters are used to define the data to focus upon. The SQL will be designed around all the concepts.
• Interactively means analysis is fluid. Whilst dimensions, filters and values are defined in the cube definition, their roles can be altered at runtime through the interaction by the user of the cube. The user has interaction (within limits) to interactively define how the data is represented.
• Dimensions can be derived. It is possible to add ad-hoc dimensions that may or may not be even data in the database directly. The ConfigTools capability allows for additional columns to be added during the configuration that are not present directly in the SQL. For example, it is possible to pull in value from a related object not in the SQL but in the ConfigTools objects.

Note: For large amounts of data to include or process as part of the cube it is highly recommended to build that logic into the cube query itself to improve performance.

• Values need to be numeric. The value to be analyzed should be numeric to provide the ability to be analyzed correctly.

In he next series of articles we will explore actually building the SQL statement and then translating that into the ConfigTools objects to complete the Cube.