All,



I have a case where facts could be attached at any level of dimensions.



To handle this I have adopted this solution:



Let's take this example:



Initial dimension:



L1 L2 L3

A

B

C

D

E

F



I create a leaf member for each non leaf member:

The dimension becomes:



L1 L2 L3



A

A

A

B

B

C

D

D

E

F





Then I use the « Hide member if » property of the dimension in AS2K.



Do you know if there are any drawbacks of using this method?



Regards,

Lionel

have you try to use a parent-child dimension?
in this type of dimension, any member could have a value from the fact
table.

"lionel gomes" <lionelgomes (AT) hotmail (DOT) com> wrote

I do but I'm concerned about performance issues of using Parent - Child
dimensions.
Do Parent Child dimensions aggregate the same way as standards ?
thx

"Jéjé" <willgart (AT) BBBhotmailAAA (DOT) com> a écrit dans le message de news:
eF2Vcfd$FHA.272 (AT) tk2msftngp13 (DOT) phx.gbl...

not the same way,
parent-child aggregates only the leaf members (or members with value) and
the all level member.

but if you provide value for every members in your parent-child dimension,
there is no changes from a performance point of view.


"lionel gomes" <lionelgomes (AT) hotmail (DOT) com> wrote

My understanding is that "Parent-child dimensions have only one level
internally, therefore no
aggregations are possible." (Lot's of posts in this newsgroup on this
subject)



If so, I don't understand how I could obtain "no changes from a performance
point of view" ?



Regarding the second solution (Creating leaf members for non leaf members
using regular dimension and the « Hide member if » property for Level 2 and
Level 3 ) it results in having no uniqueness for member names and keys ?
What is the impact of this?





Initial dimension:






Resulting dimension:





Thx

Lionel



"Jéjé" <willgart (AT) BBBhotmailAAA (DOT) com> a écrit dans le message de news:
%23OBMrhl$FHA.916 (AT) TK2MSFTNGP10 (DOT) phx.gbl...

in a standard dimension with hide member if, then the dimension is optimized
like a regular dimension.

in a parent-child dimension, if you provide a value for each member
(aggregated or leaf members) then there is no performance issue, because
you'll provide the aggregated value by yourself.
in a parent-child dimension the impact for the performance is if you have a
big dimension with a lot of levels (like a complex employees hierarchy with
10 000 employees), in this case, the server aggregate the value "on the
fly", so if you ask for a member at the level 1 and if you have 10 levels
with 5 000 leaf members, the server has to aggregate the value for these
5000 members to evaluate the result of the selected member. in a standard
dimension, the targeted member is (or could be) allready aggregated and the
response time was better.


"lionel gomes" <lionelgomes (AT) hotmail (DOT) com> wrote

Based on my experience, the parent-child dimenision is suitable for small
leaf-level dimension or pre-aggregated facts on all the nodes in the
dimension.

"lionel gomes" wrote: