As mentioned in Lesson One, we might want to make this a more intuitive -- or at least shorter -- name in order to keep a tidy appearance. A simple "rename" capability is not available, so we will have to be a bit creative here; a right-mouse click on our new data source allows a Copy action, which will act as a workaround for renaming the object in question.

15. Right-click the new data source.
16. Click Copy.
17. Highlight the Data Sources folder.
18. Select Paste from the popup menu.

This causes Analysis Services to indicate that a duplicate has been detected, and to prompt us for a unique name to rectify the confusion. We will respond to the new name request with MyFoodMart2, using the dialog box that appears (as shown below in Illustration 13).

Illustration 13: Changing the Name of the Newly Copied Cube as a Means of Renaming

19. Type MyFoodMart2000 into the Name box of the Duplicate Name dialog.

The Duplicate Name dialog thus again acts as our agent of change, and, once we click OK, adds the newly named data source under the data sources folder.

20. Click OK to close the Duplicate Name dialog.

All that remains is to delete the original data source, from which we cloned MyFoodMart2.

21. Right-click the original data source, and select Delete on the popup menu
22. Click the Yes button, to confirm the deletion.

Our tree should now resemble that shown in Illustration 14.

Illustration 14: MyFoodMart2 Appears in the Tree

In Lesson One we used the Cube Wizard, together with the subsidiary specialized wizards (including the Dimension Wizard), as called by the Cube Wizard, to rapidly create a simple cube to explore the various aspects and steps of the process from a relatively high level. In this lesson, the focus is the creation and manipulation of the parent-child dimension. We will, however, need a cube structure in place to house the dimension components that we intend to build. We will now create the cube in which our dimension will reside, and then move the focus solely to the handling of dimension structures for the remainder of the lesson.

We will use the Dimension Wizard, which we will access from the Cube Wizard, in creating a cube shell structure for the reasons we have mentioned, to create our first parent-child dimension hierarchy, HumanResource.

I like to avoid the "Employee" title, because I have found at the vast majority of my clients that human resources of all types, including many varying types of non-employees (such as temporary workers, consultants, and so forth) have become common. If we do not characterize a dimension as "Employee", that leaves us the option of using the term "Employee" in an unambiguous grouping later.

Once we have created the HumanResource parent-child dimension, we will return to dimension manipulation via the Dimension Editor to work with levels in our new parent-child dimension, as well as to perform other tasks related to a dimension of this type.

We now have an OLAP database in place, linked to a valid data source (the FoodMart 2000 database). Our preparation for the lesson (and for the creation of any dimension) is complete. Next, we will initialize the Cube Wizard, and set up our basic table structure. Dimensions are obviously of little immediate use if we do not have data working within them. We will select a fact table along with dimension table sources to allow us to get a feel for how the parent-child dimension, our true concern in this lesson, interacts with the data to construct OLAP cubes, and to enable OLAP reporting.

Page 5: Creating a Cube

See All Articles by Columnist William E. Pearson, III