Re: ER Model - different answers for different join paths

Gayathri Raman wrote:
> -- Hi, we had the same problem in our warehouse. There is a purchase
> order fact table and it relates to item and planner dimension in
> addition to other dimensions. The business scenario is that evey item
> would be assigned a default planner but the purchase order can be placed
> by any planner. We want to answer both questions. So we had the planner
> code as an attribute in the item table and also have a separate planner
> dimension. Maybe we shouldn't do this according to strict dimensional
> modelling concepts, but we had the requirement. Any other good
> suggestions out there ?

If the end-user is interested in both the regular and actual planner (or sales rep in my example), you could do as you suggest, or you could make two planner dimensions in the fact table (eg, item_planner and order_planner). My thought would be that if you want to be able to roll-up on attributes of the item_planner, it should be its own dimension.
If you don't need any attributes of planner for the item_planner, or you are willing to use a snowflake schema, then the item_planner can be an attribute of the item dimension.

I'm interested in what others think about this (both about the modeling of
this problem, and about DM vs ER).

--Kevin Received on Thu Aug 07 1997 - 00:00:00 CDT