Hi,
I'm just trying to dig a little bit deeper into attribute relationships... The documentation of Project Real is a quite interesting read... So if you have a look at http://www.microsoft.com/technet/prodtechnol/sql/2005/realastd.mspx (the technical drilldown for Analysis Services) or even better http://www.microsoft.com/technet/images/prodtechnol/sql/2005/Images/realastd02_big.gif you find an example how to construct attribute relationships.
But here's my problem: do I have a problem in understanding attribute relationships or doesn't also Microsoft know how to deal with them? Why are Fiscal Year/Qtr/Period listed as attribute relationships for Day? This doesn't make sense to me...
Thomas,
If you know the value of Day (the date) then - by defintion - you will also know the value of Fiscal Year/Qtr/Period, since any given date can only belong to one of these. For instance, with a fiscal year starting july 1 and ending june 30, november 11, 2005 will belong to
Fiscal Year: 2005
Fiscal Quarter: 2
Fiscal Period: 5
Also notice that all the attributes in any dimension will always (directly or indirectly) be related to the key attribute in the dimension (and in this case the key attribute is Day)...
|||Michael,
I aggree 100%... My question is: Why did Microsoft define i.e. the Fiscal Quarter as a direkt attribute relationship to the day? This should be an indirect relationship through Period as with the calendar dimension (through month)... This would make aggregations on the fiscal hirarchy impossible...
Thanks,
|||You are right Thomas... The Fiscal Qtr and Fiscal Year attributes are actually redundantly related to the Day attribute. I do not think it means anything though, since the relationships between Fiscal Year, Fiscal Qtr, Fiscal Period have been specified (Fiscal Year is related to Fiscal Qtr is related to Fiscal Period is related to Day).
Now I wonder, however, how Fiscal Period can be related to Fiscal Week, since knowing a week doesn't automatically mean that you know a month (I am assuming that Fiscal Period is actually just a month).
|||Well, that was something I was wondering about, too! In the document they state that with confidence... However I don't understand that, too! A week can belong to two months, everything else doesn't make much sense... I only could think about something like "week of 01-February", so this week belongs to "February", regardless of January, 31 is part of that week or not...|||Sorry. I left them that way to demonstrate how NOT to specify attribute relationships. The way that the Calendar attributes are setup is the correct way. The guiding best practice that I use is that if an attributes are both directly and indirectly related, then you should drop the direct relationships. Thus for the Fiscal attributes, day should be directly related to period, which is directly related to qtr which is direct related to year. The direct relationships between (day and qtr) and (day and year) should be dropped -- like they are with Calendar.
Hope that helps.
_-_-_ Dave
|||
Dave,
that makes sense... Any comments on the weeks, too?
Thanks,
|||You have to have a direct relationship to weeks because it is the bottom of the natural hierarchy (immeditately above the key attribute).
_-_-_ Dave
|||Well... I disagree. A week can span two months, which is why I think a relationship cannot be defined between Fiscal Period (Month) and Fiscal Week.
|||Doesn't that depend on how an orgination's fiscal month is defined - in some cases, the number of weeks per fiscal month is varied (like 4-4-5) in order to prevent weeks from spanning fiscal month boundaries?|||Deepak is right. If you look at the dimension, B&N has a very unique way of defining fiscal weeks. It isn't the same as calendar weeks.
_-_-_ Dave
No comments:
Post a Comment