Dimension design problem - star/snowflake?



Let's say you have a dimension that rolls up as a nice hierarchy, like
Company -> Department -> Office. I know you can model this all in one
table (star) or as three separate tables (snowflake).

Now, let's say you have two different fact tables. The first one,
FactExpense, is at the granularity of the Office - it tracks expenses,
and each expense is tied back to a particular office. The second one,
FactBudget, is actually at the granularity level of the Department -
budgets are done only down to the department level and office never
comes into it.

My thought is that in this scenario, you couldn't roll all levels of
the hierarchy into one table, because that would mean your dimension
is intersecting with at least one of the fact tables at the wrong
grain - it would intersect FactBudget at the office level even though
that fact table is the grain of the department. So you would need at
least two different dimensions, like DimCompanyDepartment and
DimOffice, snowflaked off each other so they could intersect the two
fact tables at the right grain.

The competing thought on my design team is that you could have all
three things in one dimension table, DimCompanyDepartmentOffice, and
for the FactBudget table you would just arbitrarily pick one of the
Offices (say, always the first office for a department) as the
intersection point for the fact and dimension. So, if DepartmentA had
two offices, Office1 and Office2, and you're recording that
DepartmentA had a 2007 budget of 400K, you would make an entry in the
BudgetFact table with the amount and the dimensional key from
DimCompanyDepartmentOffice that represents Office1.

That solution, while it might technically work, seems wrong to me
because the fact and dimensions are at different grains. Am I correct
in looking at it this way?
.



Relevant Pages

  • Re: Dimension design problem - star/snowflake?
    ... You're artificially extending the grain of the budget down to the ... The other concern is a maintenance one - if the dimension changes ... snowflaked off each other so they could intersect the two ...
    (microsoft.public.sqlserver.olap)
  • Re: Time Dimension with Minutes as Key and a 15 Minutes Level
    ... your Time dimension has an attribute for the 15-minute level, ... For example, sales data for reseller ... grain, there is an easier way with Microsoft SQL Server 2005 Analysis ...
    (microsoft.public.sqlserver.olap)
  • Dimension design problem - star/snowflake?
    ... Let's say you have a dimension that rolls up as a nice hierarchy, ... table or as three separate tables (snowflake). ... that fact table is the grain of the department. ... snowflaked off each other so they could intersect the two ...
    (microsoft.public.sqlserver.olap)
  • Many to many dimensional modeling
    ... I'm building a data warehouse and are using SQL server 2000 and Analysis ... I have a situation with a many-to-many relation between one dimension table ... problem but I have not found anyone that is specific for Analysis Services. ... An other solution is to lower the grain of the fact table to the grain of ...
    (microsoft.public.sqlserver.server)
  • Dimension Design, Attribute Relationships, and MDX question (All-in-One)!
    ... Dimension Design and Calculated Member MDx Issue ... organization hierarchy exist for the report as well as pivot table. ... Store -> District ...
    (microsoft.public.sqlserver.olap)

Loading