Synopsis: Learn how the appropriate use of attribute member Value can support the selection and delivery of enterprise data in a more focused and consumer-friendly manner. Join BI Architect Bill Pearson in a hands-on examination of the attribute member Value property and its underlying settings in Analysis Services.
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:
- the presentation of relevant and accurate information representing business operations and events;
- the rapid and accurate return of query results;
- “slice and dice” query creation and modification;
- an environment wherein information consumers can pose questions quickly and easily, and achieve rapid results datasets.
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, are acted upon by, 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 earlier 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 learn in other articles of this series, two types of hierarchies exist within Analysis Services: attribute hierarchies and user (sometimes called “multi-level”) hierarchies. For purposes of this article, the term “attribute” means the same thing as “attribute hierarchy”. (We examine user hierarchies, to which we will simply refer as “hierarchies,” in other articles specifically devoted to that topic.)
To extend the metaphor we used earlier in describing dimensions as nouns and measures as verbs, we might 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.
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 other articles of this subseries (as well as within other of my articles), multiple hierarchies of this sort are common in real-world dimensions.
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.
Having covered the general characteristics and purposes of attributes in Dimensional Attributes: Introduction and Overview Parts I through V, we then fixed our focus upon the properties underlying them, based upon the examination of a representative attribute within our sample cube. We then continued our extended examination of attributes to yet another important component we had touched upon earlier, the attribute member Key, with which we gained some hands-on exposure in practice sessions that followed our coverage of the concepts. In Attribute Member Keys – Pt I: Introduction and Simple Keys and Attribute Member Keys – Pt II: Composite Keys, we introduced attribute member Keys in detail, continuing our recent group of articles focusing upon dimensional model components, with an objective of discussing the associated concepts, and of providing hands-on exposure to the properties supporting them.
As a part of our exploration of attribute member Keys, we first discussed the three attribute usage types that we can define within a containing dimension. We then narrowed our focus to the Key attribute usage type (a focus that we developed, as we have noted, throughout Attribute Member Keys – Pt I: Introduction and Simple Keys and Attribute Member Keys – Pt II: Composite Keys), discussing its role in meeting our business intelligence needs. We next followed with a discussion of the nature and uses of the attribute Key from a technical perspective, including its purpose within a containing dimension within Analysis Services.
In Attribute Member Keys – Pt I: Introduction and Simple Keys and Attribute Member Keys – Pt II: Composite Keys, we introduced the concepts of simple and composite keys, narrowing our exploration in Part I to the former, where we reviewed the Properties associated with a simple key, based upon the examination of a representative dimension attribute, Geography, within our sample UDM. In Part II, we revisited the differences between simple and composite keys, and explained in more detail why composite keys are sometimes required to uniquely identify attribute members. We then reviewed the properties associated with a composite key, based upon the examination of a representative dimension attribute, Date, also within our sample UDM.
In Attribute Member Names, we examined the attribute member Name property, which we had briefly introduced in Dimensional Attributes: Introduction and Overview Part V. We examined the details of the attribute member Name, and shed some light on how they might most appropriately be used without degrading system performance or creating other unexpected or undesirable results.
In this article, we will examine the “sister” attribute member Value property, which we introduced along with attribute member Name in Dimensional Attributes: Introduction and Overview Part V. Similar to our examination of attribute member Name, we will examine the details of Value. Our focus will also similarly be upon its appropriate use in providing support for the selection and delivery of enterprise data in a more focused and consumer-friendly manner, without the unwanted effects of system performance degradation, and other unexpected or undesirable results, that can accompany the uninformed use of the property.
Our examination will include:
- A review of the nature of the attribute member Value property, and its possible roles in helping to meet the primary objectives of business intelligence.
- A review of the nature and uses of the attribute member Value from a technical perspective, including its purpose within its containing dimension within Analysis Services.
- A discussion surrounding some of the differences between attribute Value and Key properties.
- A review of the settings associated with the Value property, based upon the examination of a representative dimension attribute within our sample UDM.
Attribute Member Values
As we have learned, attributes serve as the foundation for our dimensions and cubes. To review, we discovered in Attribute Member Keys – Pt I: Introduction and Simple Keys that each attribute, typically based (via the Data Source View) upon a single column (or a named calculation) within the associated, underlying dimension table, falls into one of three possible usage roles, Regular, Parent, and Key. We then focused upon the attribute member Key, examining our subject from the perspective of both a simple key and a composite key. As we noted there, the attribute member Key is critical to the identification of unique attribute members within Analysis Services. The Key, we learned, is specified within the KeyColumns setting, within the Source group of a dimension’s Attribute properties. (We overviewed the Source properties in my Database Journal article Dimension Attributes: Introduction and Overview, Part V.)
Just as attribute members are assigned a Key (be it simple or composite) to uniquely identify them, members can be assigned a Value, just as they can a Name, as we noted in Attribute Member Names. And just as a descriptive Name is often more consumer – friendly (and not necessarily a mere luxury), yet another alternative value for an attribute can offer even more support for the selection and delivery of enterprise data in a more focused and consumer-friendly manner. We can even use attribute member Values as an alternative sort criterion (which is most often determined by the Key).
We do not have to assign a Value. If we do not, Analysis Services assigns, as the attribute member Value, whatever is assigned as the default attribute member Name (NameColumn setting). If an attribute member Name is not assigned, and therefore has a default of the attribute member Key value, then the default for the attribute Value becomes the Key value (KeyColumns setting) for the same attribute member.
An arrangement where only Name and Key values are present might be quite appropriate for some business scenarios. For that matter, having only Key values specified in the attribute member property settings might be perfectly adequate when, say, information consumers would be certain to recognize part or serial numbers, or other designations, and do not need “English” names. But as we noted in Attribute Member Names, a Name comes in handy for both analysis and reporting. A third, alternate value can be just as useful. Moreover, and, even in cases where everyone does not need either, or both, of the Name or Value alternatives, each (or both) can certainly be suppressed (as in a report), etc., except for scenarios within which benefit is obtained from its (their) presence. (I have written reports where the consumer could make the choice at runtime to hide or display the Value, Name, Key or combination of any of these, or even to select Value, Name, Key or combination of any of these to populate the associated parameter picklist each time the report is executed, among other options).
NOTE: I introduce and examine the intrinsic MEMBER_KEY, MEMBER_NAME and MEMBER_VALUE properties (which are derived from the KeyColumns, NameColumn and ValueColumn property settings, respectively) from the perspective of their use within MDX queries, in my articles Intrinsic Member Properties: The MEMBER_KEY Property, Intrinsic Member Properties: The MEMBER_NAME Property, and Intrinsic Member Properties: The MEMBER_VALUE Property, respectively. Both articles are members of my MDX Essentials series at Database Journal.
In our use of the attribute member Value property (which references the underlying ValueColumn property) to support the return of yet another value for the attribute member with which it is associated, we can provide our employers and clients an alternate value that can be useful in a host of different applications, and can be leveraged in activities that range from generating simple lists to supporting sophisticated presentations. The attribute member Value can, for example, be a particularly effective component, as we have seen to be the case with the attribute member Name, when we need to provide parameter picklist support and the like.
We will gain hands - on exposure to attribute member Value in the practice session that follows. 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 Analysis Services database 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 continued with our examination of attributes within the same practice environment, which we will now access (as we did within Dimensional Model Components: Dimensions Part I and Dimensional Attributes: Introduction and Overview Parts I through V) by taking the following steps within the SQL Server Business Intelligence Development Studio.
NOTE: Please access the Analysis Services database which we prepared in Dimensional Model Components: Dimensions Part I (and have used in subsequent articles) before proceeding with this article. If you have not completed the preparation to which I refer, or if you cannot locate / access the Analysis Services database with which we worked in the referenced previous articles, 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 shown in Illustration 1.
Illustration 1: Opening the Analysis Services Database ...
The Connect to Database dialog appears.
6. Ensuring that the Connect to existing database radio button atop the dialog is selected, type the Analysis Server name into the Server input box (also near the top of the dialog).
7. Using the selector just beneath, labeled Database, select ANSYS065_Basic AS DB, as depicted in Illustration 2.
Illustration 2: Selecting the Basic Analysis Services Database ...
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 the properties of dimension attributes in previous articles, we will continue to get some hands-on exposure to the Value property for an example dimension attribute member, from within our practice UDM.
Procedure: Examine Attribute Value Property Settings in Analysis Services 2005
In the practice procedures that follow, we will select and examine a representative dimension attribute within the sample cube, and then focus upon the Value property settings that define and support the selected attribute. We will perform our practice sessions within the SQL Server Business Intelligence Development Studio, from which we will examine the dimension attribute Value property within our Analysis Services database, ANSYS065_Basic AS DB.
In Dimensional Model Components: Dimensions Part I and II, and Dimensional Attributes: Introduction and Overview Parts I through V, respectively, we overviewed the properties underpinning Database and Cube dimensions, and then examined the properties supporting dimension attributes. In Attribute Member Keys – Pt I: Introduction and Simple Keys, and in Attribute Member Keys – Pt II: Composite Keys we focused upon those properties for a simple attribute Key and a composite attribute Key, respectively. Finally, in Attribute Member Names, we concentrated upon the underlying properties for the settings underlying the attribute member Name. Just as we did in those articles, we will examine the detailed settings for a representative attribute member here, concentrating on those settings within the context of the member Value. To access these settings for the attribute member within a representative dimension, we will need to open that dimension within the Dimension Designer first.
1. Within the Solution Explorer, right-click the Time dimension (expand the Dimensions folder as necessary).
2. Click Open on the context menu that appears, as shown in Illustration 3.
Illustration 3: Opening the Dimension via the Dimension Designer ...
The tabs of the Dimension Designer open.
3. Click the Dimension Structure tab, if we have not already arrived there by default.
The attributes belonging to the Time dimension appear as depicted in Illustration 4.
Illustration 4: The Member Attributes, Time Dimension
We note that eight attributes appear within the Attributes pane. Let's get some exposure to the Value property settings associated with attribute members by examining a representative member among the attributes we see here.
Review Attribute Value Property Settings
In Dimensional Attributes: Introduction and Overview Part V, and as a part of our more detailed exploration in Attribute Member Keys – Pt I: Introduction and Simple Keys, and in Attribute Member Keys – Pt II: Composite Keys we discovered that, within the Source properties of every attribute member lays the Value property. Let’s examine the property and the underlying ValueColumn settings for the Month Name attribute, which is supported by a composite key within the sample Analysis Services database, by taking the following steps.
1. Within the Attributes pane of the Dimension Structure tab, right-click the Month Name attribute.
2. Click Properties on the context menu that appears, as shown in Illustration 5.
Illustration 5: Select Properties from the Context Menu ...
The Properties pane appears for the Month Name attribute. (The Properties pane likely appeared when we selected the Month Name attribute within the Attributes pane, by default, below the Solution Explorer. It also may have been hidden, set up to “float” within the Studio, or to be anchored elsewhere.) The design environment can, of course, be customized in many ways to accommodate your local environment and development needs.)
3. Expand the Source group, at the bottom of the Properties pane, by clicking the “+” sign that appears to the immediate left of its label, if necessary, as depicted in Illustration 6.
Illustration 6: Expand the Source Group in the Properties Pane
The expanded Source properties group of the Properties pane for the Month Name dimension attribute appears as shown in Illustration 7.
Illustration 7: The Source Properties for the Month Name Dimension Attribute
Let's take a look at the Value property (and its “subproperties”), as relevant to the Month Name attribute, discussing the purpose of the property, and examining possible settings with which we can come into contact.
Source Property: ValueColumn
Much like the KeyColumns property, which we examined in Attribute Member Keys – Pt I: Introduction and Simple Keys, and Attribute Member Keys – Pt II: Composite Keys, the value we select for the ValueColumn property specifies a column within the underlying data source. The ValueColumn property specifies the column containing the attribute member Value.
1. Click the box to the immediate right of the ValueColumn label, just beneath the NameColumn label, within the expanded Source properties group of the Properties pane.
We note that the setting box currently contains “(none)”, indicating that the setting is not pointed to any column within the dimension table at present.
2. Click the selector (the downward pointing arrow) button that appears on the right edge of the ValueColumn property box.
3. Click “(new)”, as depicted in Illustration 8.
Illustration 8: Click the Selector Button, then Select “(new)” ...
The Object Binding dialog appears, with highlighted Column binding defaulted to the top column in the Source column list.
As we have noted in other articles of this series, the Object Binding dialog is used throughout the Business Intelligence Development Studio to edit / add the column binding of data items associated with properties of various Analysis Services objects. The Object Binding dialog is typically made available for single column selection options, where selection is made by simply clicking the appropriate column within the Source column list.
Because the ValueColumn setting of our example dimension attribute (along with the ValueColumn settings in the other attributes of our sample environment) has been left at default of “(none)”, we will assign a table / column combination to enable the underlying settings for the property, so as to permit our further review of each.
4. Click the MonthNumberofYear selection within the Source column list to highlight it, as shown in Illustration 9.
Illustration 9: The Object Binding Dialog Appears
5. Click OK to accept our addition, and to dismiss the Object Binding dialog.
We see that the ValueColumn setting, along the bottom of the Properties pane, is now populated with “DimTime.MonthNumberOfYear (UnsignedTinyInt)”. Unlike the attribute member Name (NameColumn setting), which is converted to a string in Analysis Services, the attribute member Value (ValueColumn setting) retains the data type of the underlying data column. Moreover, we note that the underlying settings for the property have now become enabled (a “+” sign has appeared alongside the ValueColumn label).
6. Expand the ValueColumn property (by clicking the “+” sign to the immediate left of the ValueColumn label).
7. Expand the Source properties group in the Properties pane, atop the list that appears under the ValueColumn group that we expanded in our last step, by clicking the “+” sign that appears to the immediate left of the Source label.
The TableID and ColumnID settings appear, as depicted in Illustration 10.
Illustration 10: The Expanded Source Properties Appear
As we can see, the first of the displayed DimTime.CalendarYear DataItem properties, Source, expands to make available the TableID and the ColumnID boxes, where we can also specify the location of the Value within the underlying database. If we click on the Source label, or on the box to its right, an ellipses (...) button becomes enabled. This affords us another access point to the Object Binding dialog we saw earlier, where we can, once again, select the Table and Column that we want.
8. Click the box to the immediate right of the TableID label, just beneath the expanded Source group label, to enable the downward-pointing selector button.
9. Click the downward arrow selector button, to expose the tables for selection, as partially shown in Illustration 11.
Illustration 11: Source - TableID Property Value Selection Options (Partial View)
Once we have selected the TableID, we can select from a context-sensitive list of columns via the ColumnID selector, immediately underneath the TableID selector, as partially depicted in Illustration 12.
Illustration 12: Source - ColumnID Property Value Selection Options (Partial View)
10. Leaving both Source “subproperties” at their previously established settings, click the box to the immediate right of the DataType label, just beneath the expanded Source – ColumnID property, once again to enable the downward-pointing selector button.
11. Click the downward arrow selector button, to expose the types for selection, as partially shown in Illustration 13.
Illustration 13: DataType Property Value Selection Options (Partial View)
We have mentioned in several other articles of this series that the data type options within Analysis Services 2005 have been expanded over those of previous versions. The DataType property allows us to convert the data types from those applicable to the data within the underlying relational database to different data types that we might require for the corresponding member data within Analysis Services. As we observed for the attribute Key in Attribute Member Keys – Pt I: Introduction and Simple Keys, and Attribute Member Keys – Pt II: Composite Keys, and unlike the situation we noted, in Attribute Member Names, for the attribute member Name (which can be assigned only data types that can then be converted to the text-only data type that Name allows), the attribute member Value can accept a wide range of data types. We are therefore still afforded a degree of versatility between these two layers of the integrated business intelligence solution.
12. Leaving the DataType property at its previously established setting, click the DataSize label, just beneath the DataType property label, simply to rest it there.
The DataSize property allows us to specify (for either binary or text data) a size (in bytes and characters, respectively). The setting we see in our example is “0.” (The default is 255 characters anytime we do not specify size.)
13. Leaving the Data Size property at its previously established setting, click the box to the immediate right of the NullProcessing label, just beneath the DataSize property, once again to enable the associated downward-pointing selector button.
14. Click the selector button, to expose the five options for NullProcessing selection, as depicted in Illustration 14.
Illustration 14: NullProcessing Selection Options
Here we can select a value to dictate the manner in which Analysis Services processes null attribute member data. These values are explained in detail in Table 1.
Table 1: Options for NullProcessing Rule Selection
Analysis Services preserves the null value.
NOTE: This selection dictates the expenditure of additional resources in the storage and processing of null data.
The Analysis Server displays an error message, because the null value is disallowed.
The Analysis Server associates the null value with an unknown member (which dictates that the value is to be treated in accordance with established unknown member rules).
Analysis Services converts the null value to a blank (when the data type is a string) or to a zero (when the data type is other than a string).
The Analysis Server selects the value based upon its determination of context.
15. Leaving the NullProcessing property at its previously established setting, click the box to the immediate right of the Collation label, just beneath the NullProcessing property, this time to enable the ellipses (...) button to its right.
16. Click the ellipses (...) button, to expose the Define Collation dialog, which appears as shown in Illustration 15.
Illustration 15: The Define Collation Dialog
The Collation property affords us a way to specify the rules we wish to invoke for text data string comparisons. While collation in general has multiple purposes, it is often used to support the determination of whether the members of a given pair of strings are alike or different. Several Sort Order options are also available, with the Designator and Sort Order selections defaulting to server settings (in effect here, where the Collation property appears empty within the Properties pane.
As we noted in Attribute Member Names, because Collation can have an impact upon the uniqueness of attribute member Names, the setting becomes particularly significant when we are specifying Names. Examples given in various books and other documentation surrounding this consideration often cite the fact that treatment of capitalized and non-capitalized letters (some Collation settings ignore capitalization entirely, whereas others treat capitalized letters, etc., as different characters than the same, non-capitalized letters) can differ among settings. Collation also impacts sorting, so when information consumers dictate, say, in a report they create in Reporting Services, that they wish to retrieve a group of attribute members in order of their respective Values (versus in order of the attribute member Key), results might not match expectations if the Collation property setting is not taken into consideration .
NOTE: We always have the option of using another, related attribute entirely as a basis for our sort orders, if Key, Name, or even Value is somehow unsatisfactory. For more information on this versatile option, see my article Alternatively Sorting Attribute Members in Analysis Services 2005.
17. Click the downward arrow selector button to the right of the box labeled Collation designator, to expose the collations available for selection, as partially depicted in Illustration 16.
Illustration 16: Available Collation Options (Partial View)
18. Leaving the settings in the Collation Designator dialog at their previously established values, click the Cancel button to dismiss the dialog.
19. Click the Format label, just beneath the Collation property label, simply to rest it there.
We have noted in other articles of this series that the Format property purports (via the Books Online and other documentation) to allow us to specify - using Visual Basic (Format function) format types - the conventions used in transforming numeric data to text, if such a transformation is required. The reality is that the only member formatting supported within the Unified Dimension Model (UDM) is the Trimming setting that we discuss below. (We can, of course, employ named calculations or column calculations (at the data source view level) within the cube to achieve our formatting ends, as alternative approaches.
20. Leaving the Format property blank, click the box to the immediate right of the InvalidXmlCharacters label, just beneath the Format property, once again to enable the downward-pointing selector button.
21. Click the downward arrow selector button, to expose the three selection options for InvalidXmlCharacters, as shown in Illustration 17.
Illustration 17: Selection Options for InvalidXmlCharacters
The InvalidXmlCharacters property is applicable in cases where we expect data to be received in the XML format, and where we wish to dictate the handling of such data, if, and when, invalid characters appear. The values are explained in Table 2.
Table 2: Options for InvalidXmlCharacters Selection
Analysis Services preserves (e.g., does not change) invalid characters.
Analysis Services removes invalid characters.
Analysis Services replaces invalid characters with a question mark (“?”)
22. Leaving the InvalidXmlCharacters property at its previously established setting, click the MimeType label, just beneath the InvalidXmlCharacters property label, simply to rest it there.
The MimeType property allows us to specify the binary data type, where necessary to meet our needs.
23. Leaving the MimeType property blank, click the box to the immediate right of the Trimming label, just beneath the MimeType property, as before, to enable the downward-pointing selector button.
24. Click the selector button, to expose the four options for Trimming selection, as depicted in Illustration 18.
Illustration 18: Trimming Property Value Selection Options
The Trimming property allows us to specify the desired treatment of trailing spaces at the beginning / end of a string. As we see in Illustration 18 above, the options are self-explanatory.
25. Leave the Trimming setting as it currently exists.
NOTE: Please consider saving the project we have created to this point for use in subsequent related articles of this subseries, so as to avoid the need to repeat the preparation process we have undertaken initially, to provide a practice environment.
26. Select File -> Save All to save our work, up to this point, within the originally chosen location, where it can be easily accessed for our activities within other articles of this subseries.
27. Select File -> Exit to leave the design environment, when ready, and to close the Business Intelligence Development Studio.
In this article, we examined the attribute member Value property, which we briefly touched upon in Dimensional Attributes: Introduction and Overview Part V. We examined the details of this property, and shed some light on how it might be used to support the selection and delivery of enterprise data in a more focused and consumer-friendly manner, without generating unexpected or undesirable results.
We focused, throughout our examination of attribute member Value, on the general nature of the property, and its possible roles in helping to meet the primary objectives of business intelligence. We reviewed its roles from a technical perspective, including its purpose within its containing dimension within Analysis Services.
In gaining hands-on exposure to attribute member Values, we discussed, at appropriate points, some of the differences between attribute Value, and each of the Name and Key, properties. Moreover, we gave some examples of uses for attribute member Value, as an alternative to Key or Name. Finally, we performed a detailed review of the settings associated with the attribute member Value property, based upon the examination of a representative dimension attribute within our sample UDM.
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.
» See All Articles by Columnist William E. Pearson, III
Discuss this article in the MSSQL Server 2000 Analysis Services and MDX Topics Forum.