M:N Relationships

Question

Hi,
We have a data relationship which is causing headaches so any ideas how to solve this would be greatly appreciated.
Customer Dimension
Cust Code
Cust Desc
Account Dimension
Acc Code
Acc Desc
Balance Facts
Cust Code
Acc Code
Balance
Data :
Balance Facts
record 1 : Cust Code : 1
Acc Code : 1
Balance : 100
record 2 : Cust Code : 2
Acc Code : 1
Balance : 100
Problem :-
1 account owner by 2 customers (joint account holders). When I aggregate this cube the Balance = 200 when it should be 100. I need both customers in the cube because if I drilldown to individual customers each customer must show an account balance of 100.
Any suggestions welcomed.
Cheers,
Brandon

Answer 1

Sorry for making this confusing -- even simple answers can get complicated quickly if you don't have a good model to work with.
I would therefore suggest that you take the accounts/customers and create a simple spreadsheet. If you follow the logic that formulas must be applied to all elements of a given row OR column within the "grid" that is created, you can ultimately diagram the totals for the columns and rows. The formulas would obviously not be simple sums, but they would be close to that. After you model this "roll-up" that way, you only have to translate it into member formulas and ensure the calc order is appropriate (rows then columns or columns then rows). Keep it simple, and eventually you will hit on the formula/model that works for you. Then it's just a matter of translation.
As for my suggestions, I doubt that I coudl make it much more meaningful (it is hard to translate the relatively simple pictures in my mind into simple sentences in a forum). This is the kind of thing you either did before or not, and working through it is a non-trivial task even when you have a firm grasp of the goals (but something that a clear picture makes a lot easier, nonetheless).
What a) and b) are really saying is that reporting on non-input level data can only be done for 1 of the 2 dimensions, so that selecting a non-input account implies an input level customer (and vice versa). Each accomplishes this in a slightly different way. A) does this by creating a customer relationship for each combination of customers and B) does this by entering data at the "Customer Total" level and then replicating this to the associated customers as "memo items" (non-contributory members). Using these memo items at non-input account levels would result in "wrong" values.
Essentially, approach b) uses the "Customer Total" value is the only valid roll-up for any account total. You eliminate the need for customer totals because the individual account value is stored there, and the customers have to be populated with a copy of this data for any accounts they are attached to. The totals by customer are the sum of the accounts, while the sum for the accounts is only taken by the "Customer Total" member so there is no double-counting.
Approach a) is a similar scheme but has an account total value that allows the customers to have a hierarchy (approach b denied this ability).
Approach c) is a simple allocation scheme that combines approach b) with an input member for each account which is allocated to the "Customer Total" and to the attached customers. This is a logical next step from approach b (which is more of a proof of concept then a final solution).