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