Cube Redesign : how to identify the culprits in a bad dimension

Question

Hello Community,
What is the best way to identify which "combination of characteristics" is guilty for causing a large record count in the dimeension table ?
We are working to redesign an infoCube that had many unbalanced dimensions.  So far we've done quite well: all newly designed dimensions are well balanced *except for one*
Unfortunately, we don't have the luxury of just splitting it up further, since we're already using the maximum of 13 customer dimesions.
So now I must decide how to best shuffle the characteristics, without disrupting the balance of the other dimensions.
The cube was designed long before I joined the team, and I don't have a relationship diagram (nor, indeed, an intimate knowledge of the data).  Is there a way to reverse engineer to find out which are the problem characteristics ?
For example, I've already selected the record count from each SID table.  But I'm not certain what to do next.
So my question is : what is the best way to identify which "combination of characteristics" is guilty for causing a large record count in the dimeension table ?
Thanks so much for your help !
Keith

Answer 1

To give some feedback about what I've done : I decided to run selects against the ODS that was used to load this cube. (In reality there are 3 ODS, but I'm using just one to test the dimension designs).
Here is the select statement I've used to query for unique combinations of characteristics in the ODS.
select count(*) from (select distinct char_1, char_2, char_3, ..char_N from sapr3."/BIC/table_name") ;
A couple of things to keep in mind when you're setting this up :
char_1, char_2, char_3, ..char_N represents a comma separated list of the characteristics you wish to test as a plausable dimension
be certain that char_1, char_2, char_3, ..char_N are actually represented in the SQL statement as the FIELD NAMES for the table you're selecting against.  For example characteristic 'ZEXAMPLE' has a field name in the ODS of /BIC/ZEXAMPLE and characteristic 0EXAMPLE2 has a field name in the ODS of EXAMPLE2
In the select statement, fields with a slash in the field name must be qualified by double quotation marks like this: (select distinct "/BIC/ZEXAMPLE", ..)