dbTalk Databases Forums  

Slow Changing Dimension (SCD) handling in Analysis Services 2005

microsoft.public.sqlserver.olap microsoft.public.sqlserver.olap


Discuss Slow Changing Dimension (SCD) handling in Analysis Services 2005 in the microsoft.public.sqlserver.olap forum.



Reply
 
Thread Tools Display Modes
  #1  
Old   
Willem de Ru
 
Posts: n/a

Default Slow Changing Dimension (SCD) handling in Analysis Services 2005 - 09-11-2006 , 06:58 AM






Slow Changing Dimensions (SCD) as pioneered by Kimball is very helpful on our
data warehouse project.

The way that we handle the SCD in Analysis Services 2005, is by creating a
hierarchy with the Business Key (natural key from the source system) on the
top level of the hierarchy and the client name on the second level. (We use
surrogate keys to link the dimensions to the fact tables.)

This SCD strategy works well for us. One can then easily see the aggregated
sales of a specific client (even if the details have changed over time), but
then drill into more detailed info of this specific client, if required. (For
example, see the sales as the client's details have changed over time, e.g.
what was sales when the client was in Region A and what was the sales when
the client was in Region B).

Are there other ways of handling the SCD in Analysis Services?

We have also set the SCD settings SCDEndDate, SCDStatus, SCDStartDate,
SCDOriginalID on the Type property of the Dimension attributes, but does this
cause the cube to work differently, or is it just meta-data that can e.g. be
used by a front-end tool?


Reply With Quote
  #2  
Old   
Jéjé
 
Posts: n/a

Default Re: Slow Changing Dimension (SCD) handling in Analysis Services 2005 - 09-11-2006 , 07:28 AM






a SCD dimension is created when you want to handle changes like yours
I mean you must have 2 surrogate keys for the same client but each surrogate
key is associated to each region.
The client appears 2 times, 1 time under region A and then under region B

All Regions
--> Region A
------> Customer 1
--> Region B
------> Customer 1

each sale is associated to the right region / customer combination.
if your customer dimension is not by region, then you don't need to have a
surrogate key
(maybe you have other attributes where you want to track the changes)
also, if you want to have all the sales of customer 1 in an hierarchy like:

All Gender
--> Male
------> Customer 1

in this case, the customer 1 level will not be the surrogate key attribute
but the business key, or the name himself attribute.

What I recommand is to create a dimension like:
Key attribute: name of the attribute=Changing Name / key column=Surrogate
key / name column=customer name / hierarchy visible=false
other attributes:
name of the attribute=Customer / key column=Business key / name
column=customer name / hierarchy visible=false
name of the attribute=Region / key column=Region key / name column=Region
name / hierarchy visible=false
name of the attribute=Gender / key column=Gender key / name column=Gender /
hierarchy visible=false
etc...
(All the attributes are associated to the key attribute)

now 2 user hierarchies:
"Customers by region" (the slow changing hierarchy)
Level 1 = Region attribute
Level 2 = Changing name attribute (renamed to Customer)

"Customers by gender" (the non-slow changing hierarchy)
Level 1 = Gender attribute
Level 2 = Customer attribute

so you have 2 times the customer name in the dimension, but 1 is changing
and the second is not changing.
there is other way to do this type of dual usage (changing and non changing
information in 1 dimension), but the key column must be the surrogate key.

I hope this answer some of your needs(?)

Jerome.


"Willem de Ru" <WillemdeRu (AT) discussions (DOT) microsoft.com> wrote

Quote:
Slow Changing Dimensions (SCD) as pioneered by Kimball is very helpful on
our
data warehouse project.

The way that we handle the SCD in Analysis Services 2005, is by creating a
hierarchy with the Business Key (natural key from the source system) on
the
top level of the hierarchy and the client name on the second level. (We
use
surrogate keys to link the dimensions to the fact tables.)

This SCD strategy works well for us. One can then easily see the
aggregated
sales of a specific client (even if the details have changed over time),
but
then drill into more detailed info of this specific client, if required.
(For
example, see the sales as the client's details have changed over time,
e.g.
what was sales when the client was in Region A and what was the sales when
the client was in Region B).

Are there other ways of handling the SCD in Analysis Services?

We have also set the SCD settings SCDEndDate, SCDStatus, SCDStartDate,
SCDOriginalID on the Type property of the Dimension attributes, but does
this
cause the cube to work differently, or is it just meta-data that can e.g.
be
used by a front-end tool?




Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.