Dimension Attributes: Introduction and Overview, Part V
July 7, 2008
About the Series ...
This article is a member of the series Introduction to MSSQL Server Analysis Services. The series is designed to provide hands-on application of the fundamentals of MS SQL Server Analysis Services (Analysis Services), with each installment progressively presenting features and techniques designed to meet specific real-world needs. For more information on the series, please see my initial article, Creating Our First Cube. For the software components, samples and tools needed to complete the hands-on portions of this article, see Usage-Based Optimization in Analysis Services 2005, another article within this series.
In Dimensional Model Components: Dimensions Parts I and II, we introduced the dimensional model in general, noting its wide acceptance as the preferred structure for presenting quantitative and other organizational data to information consumers. We then began our examination of dimensions, the analytical perspectives upon which the dimensional model relies in meeting the primary objectives of business intelligence, including its capacity to support:
Having covered the general characteristics and purposes of attributes, we fixed our focus upon the properties underlying them, based upon the examination of a representative attribute within our sample cube. We discussed the Advanced group of properties in Dimension Attributes: Introduction and Overview, Part I, and continued with an examination of the Basic, Misc and Parent-Child properties in Part II, Part III, and Part IV, respectively, looking forward to each subsequent part of our introduction and overview of dimension attributes, where we explored the remaining attribute properties. In this part of our overview of attributes, our examination will include:
Dimensions in Analysis Services: Attributes (continued ...)
We learned, in Dimensional Model Components: Dimensions Parts I and II, that dimensions form the foundation of the dimensional model. They represent the perspectives of a business or other operation, and reflect the intuitive ways that information consumers need to query and view data. We noted that we might consider dimensions as nouns that take part in, or are otherwise associated with, the verbs (or actions / transactions undertaken by the business) that are represented by the facts or measures contained within our business intelligence systems.
We discovered in these two articles that, within the Analysis Services model, database dimensions underlie all other dimensions, whose added properties distinguish them from the database dimensions they reference, within the model. Each dimension within our model contains one or more hierarchies. As we will learn in later articles of this subseries, two types of hierarchies exist within Analysis Services: attribute hierarchies and user (sometimes called multi-level) hierarchies. For purposes of most of our articles, the term attribute means the same thing as attribute hierarchy. (We will examine user hierarchies, to which we will simply refer as hierarchies, in subsequent articles.)
As we noted in Dimension Attributes: Introduction and Overview, Part II, we might summarize our introduction in earlier articles of this subseries by extending the metaphor we have used in describing dimensions as nouns and measures as verbs, and consider attributes as somewhat similar to adjectives. That is, attributes help us to define with specificity what dimensions cannot define by themselves. Dimensions alone are like lines in geometry: they don't define area within multidimensional space, nor do they themselves even define the hierarchies that they contain. A database dimension is a collection of related objects called attributes, which we use to specify the coordinates required to define cube space.
As we discussed in Part I, within the table underlying a given dimension (assuming a more-or-less typical star schema database) are individual rows supporting each of the members of the associated dimension. Each row contains the set of attributes that identify, describe, and otherwise define and classify the member upon whose row they reside. For instance, a member of the Patient dimension, within the Analysis Services implementation for a healthcare provider, might contain information such as patient name, patient ID, gender, age group, race, and other attributes. Some of these attributes might relate to each other hierarchically, and, as we shall see in subsequent articles of this subseries (as well as within other of my articles), multiple conceptual hierarchies of this sort are common in real-world dimensions.
As we further discussed in Part I, Dimensions and dimension attributes should support the way that management and information consumers of a given organization describe the events and results of its business operations. Because we maintain dimension and related attribute information within the database underlying our Analysis Services implementation, we can support business intelligence for our clients and employers even when these details are not captured within the system where transaction processing takes place. Within the analysis and reporting capabilities we supply in this manner, dimensions and attributes are useful for aggregation, filtering, labeling, and other purposes.
In looking forward to each of our practice sessions in Parts I, II, III and IV, we stated that, in addition to a few key values, several properties (each of which has, in its own right, multiple possible values) are associated with each attribute residing in a given model. We got some hands-on exposure to some of these key values and properties in the practice session focusing upon the Advanced properties group of attribute properties (including what they define and support, and how we can manage them). We examined the Basic, Misc, and Parent-Child groups of attribute properties in Parts II, III, and IV, in like manner. We will examine the Source group of attribute properties in the practice section of this article, where we conclude our introduction and overview of dimension attributes.
Before we get started working within a sample cube clone, we will need to prepare the local environment for the practice session. We will take steps to accomplish this within the section that follows.
Preparation: Locate and Open the Sample Basic UDM Created Earlier
In Dimensional Model Components: Dimensions Part I, we created a sample basic UDM within which to perform the steps of the practice sessions we set out to undertake in the various articles of this subseries. Once we had ascertained that the new practice database appeared to be in place, and once we had renamed it to ANSYS065_Basic AS DB, we began our examination of dimension properties. We will continue our examination of attributes within the same practice environment, which we will access taking the following steps within the SQL Server Business Intelligence Development Studio, as we did within Dimensional Model Components: Dimensions Parts I, II, III, and IV.
NOTE: Please access the UDM which we prepared in Dimensional Model Components: Dimensions Part I before proceeding with this article. If you have not completed the preparation to which I refer in the previous article, or if you cannot locate / access the Analysis Services database with which we worked there, please consider taking the preparation steps provided in Dimensional Model Components: Dimensions Part I before continuing, and prospectively saving the objects with which you work, so as to avoid the need to repeat the preparation process we have already undertaken for subsequent related articles within this subseries.
1. Click Start.
2. Navigate to, and click, the SQL Server Business Intelligence Development Studio, as appropriate.
We briefly see a splash page that lists the components installed on the PC, and then Visual Studio .NET 2005 opens at the Start page.
3. Close the Start page, if desired.
4. Select File -> Open from the main menu.
5. Click Analysis Services Database ... from the cascading menu, as depicted in Illustration 1.
The Connect to Database dialog appears.
6. Ensuring that the Connect to existing database radio button is selected, type the Analysis Server name into the Server input box atop the dialog.
7. Using the selector just beneath, labeled Database, select ANSYS065_Basic AS DB, as shown in Illustration 2.
8. Leaving other settings on the dialog at default, click OK.
SQL Server Business Intelligence Development Studio briefly reads the database from the Analysis Server, and then we see the Solution Explorer populated with the database objects. Having overviewed dimension attributes in previous articles, we will continue to get some hands-on exposure to properties for an example attribute, from within our sample UDM.