Database Reference
In-Depth Information
You can read a more detailed discussion of these techniques at the end of the
following article: http://tinyurl.com/attributerelationships . You should
not make changes like this at the expense of the users' requirements, but in most
cases they will not mind minor modifications such as these and will appreciate the
increased query performance.
The RelationshipType property of an attribute relationship indicates whether the
relationship between any two members on two related attributes is ever likely to
change or not. For example, you would hope that the date January 1 st 2001 would
always appear under the month January 2001 in your dimension. If it moved to the
month March 2002, something would be very wrong with your source data. In this
case, you should set the RelationshipType property of the Month - Date attribute
relationship to Rigid . On the other hand, it may be true that the relationship between
a Customer attribute and a City attribute may change over time if a customer
changes his/her residence. In that case, the RelationshipType property should be
set to Flexible . Setting RelationshipType to Rigid where possible increases the
chances that aggregations will not need to be rebuilt when a dimension undergoes
a ProcessUpdate , something that will be discussed in more detail in Chapter 10 ,
Going in Production . Our advice is never to set the RelationshipType property to
Rigid unless you are absolutely sure that no UPDATE or DELETE statement is ever run
on the underlying dimension table. If a rigid relationship does change, dimension
processing will fail.
Finally, attribute relationships also have a second function, and that is to act as
member properties. If a Month has many dates, you can think of the relationship
in reverse as a Date having a property which is its month. A better example
might be a Customer having an Address , and if the Address attribute has its
AttributeHierarchyEnabled property set to False then it may only be visible as a
property of Customer . Every attribute relationship is visible by default as a member
property in most client tools. If you want to hide the member property, you can set
the relationship's Visible property to False .
Building a simple cube
With some dimensions built, the next step is to run the cube wizard to create the
cube itself. Remember that at this stage, all we want to do is build a very simple
cube so that we can test-drive the data, so we're not going to do anything other than
run the wizard. You'll be doing a lot of work in the Cube Editor in the next stage of
development, but if you've set up the DSV in the way we recommend, then you'll
find that when you've finished running the wizard, you will have something that
you can deploy, process and browse immediately with no changes required.
 
Search WWH ::




Custom Search