August 27, 2009 at 5:34 am
Hi everyone,
hope you can help. We're building a cube in SSAS, and are having a discussion about attributes and best practice.
We are defining within the user defined hirearchy an attribute with the same name under multiple levels, however the name of these attributes under the tree list is unique, we are just renaming them in the levels. I've added an image to show you.
What i would like to know is this safe to do, would we run into any issues that you could think of??
thanks
Jon
August 27, 2009 at 6:49 am
would you like to explain why there are
weekdesc1,
weekdesc2,
....
weekdesc7
and the different year columns as this may help me understand what you want from this dimension?
I think a single row from the data set would be good too.
Thanks.
Mark.
:w00t:
August 27, 2009 at 10:43 am
Hi Ells,
WeekDesc1 etc are just versions of how we describe the week. WK1, P1 WK1, 1, W1 etc.
Its the FullYear MemberCode that has been renamed as MemberCode in the other hirearchies does that help?
thanks
Jon
August 27, 2009 at 12:47 pm
If it was down to me and not drive by some real business need I would go for
week numbers:
Create a unique id for the week. This id will be something like 5423 where it does not contain any other information. In past lives I have used week numbers such as 20090812 (2009 being the year, 08 being the month, and 12 being the week) this then is useless when someone changes the calendar and moves the week into a different month or financial year.
Week descriptions surely one is enough unless. If your 7 versions are
Week1, Period1Week1, P1Wk1, Year4Period1Wk1 ... then your users will see 7 hierarchies. Maybe you are going to control that through security. I really would push for one standard version.
Ells.
August 27, 2009 at 2:03 pm
Maybe off topic, or obvious to others, it *looks* like additional descriptions are effectively member properties, so depending on the client they won't show up in any list of attributes but will be 'roll over' or right click accessed, so the inclusion of these is probably superfluous to the original question.
As far as adding the attribute as a level, and then renaming it, if SSAS allows you to do it, then I wouldn't be too concerned with adverse impacts as it's likely to be simply changing a user displayed name (versus the actual id under the covers). A quick way to check this would be to script the DB (or just the dim) and see what's happening (as far as names and internal names are concerned).
HTH,
Steve.
August 28, 2009 at 1:46 am
Maybe consider what you want to see as the end result. Create a test cube with just two version of week and see what you think and what the send users think? Should have asked up front what tool you are using to retrieve data from the cubes?
As Steve said member properties could be a very clean way to do this but some tools do not support this. I used to use them a lot in 2000 but not as much in 2005.
Mark.
:w00t:
August 28, 2009 at 4:57 am
Looks to me like you are misunderstanding the concept of what a user hierarchy is. What you present is certainly a non-standard way of structuring a dimension and hierarchies. What are you trying to achieve? Are you designing this for a specific reporting tool? Or is this a cube that the users will never see and is consumed by a custom application?
To answer your original question, no, there should be no issue with exposing different attribute hiearchies with the same level names under different user hierarchies.
Out of interest, rather than creating these strange user hierarchies, why not just let the users use the attribute hierarchies? You don't seem to be gaining anything from generating these user hierarchies.
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply