Role Playing Dimensions

What is the proper way to include the date dimension table into your DSV if you plan on using multiple role-playing dimensions? It seems if you can use this dimension as a role playing dimension, and assign the "join" using the Dimension Usage tab, then it doesn't need to be joined to the fact table in the DSV... is that correct? Or should you add the Date Dim table to the DSV and join it to every date-specific fact foreign keys? I see three possibilities for the DSV:

1) Include the Date Dim table but not join to any other table in the DSV

2) Include the Date Dim table and join to at least one fact foreign key

3) Include the Date Dim table and join to all fact foreign keys for dates in the DSV

Which method would be the most appropriate (or what are the consequences of each method)?

Also, if you use a role-playing dimension, is there anyway of manipulating the levels to display the type of date. For example, of the user picks the Order Date dimension, the year level says "Order Year" but if they use the Shipped Date dimension, the year level would say "Shipped Year"... etc.?

Thanks

Kory

Hi KoryS. Check the Adventure Works sample BI project that clearly shows that no 3 is the correct way of doing it. It is a very simple concept, instead of using three tables of views for time you join one table to the different time keys in the fact table. There have been some concerns regarding using role playing dimensions like here(http://mgarner.wordpress.com/2006/06/27/role-playing-dimensions-not-materialized/) but now it is OK regarding performance.

Regards

/Thomas Ivarsson

|||

Thanks- I'll follow the example from the Adventureworks db.

Do you know if I can rename some of the levels in my role-playing dimensions (see second half of my original thread)?

-Kory

|||

I think you will have to use the same names but you name each dimension like DueDate, OrderDate, ShipDate and so on. You can see this is in the Adventure Works AS2005 project.

Regards

/Thomas

sql