Hello,
My question:
When is it better to create a dimension rather than a hierarchy within a dimension?
What are the trade-offs?
Will concatenating codes values make it difficult to drill-down to relational data in the source system?
Should the depth of the hierarchy be one of the deciding factors? By depth I mean the number of child elements owned by
a parent. If the majority of the parent accounts only one child then then the hierarchy is not useful.
An example of concatenating code values:
We have 5 segments in our Oracle Financials application.
Entity
Dept
Major Account
Performance code
InterCompany code
3 dimesniosn were created from these 6 code values:
Dim1 : Entity
Dim2 : Dept
Dim3: GLACCT [Major Account] - [Performance code] - [InterCompany code]
The three code values are contatenated to create one element in the GLACCT dimesion.
Major:
Major - Performance Code
Major - Performance Code - Intercompany code
008001 - Cash
008001-0000000 - Cash : Default
008001-0000000-000 - Cash : Default : Default
There is little value in this hierachy, since each parent only contains one child record. If the majority of the accounts are set up this way, would it be better to have three dimesnions rather than the hieratchy?
Thanks,
Walt
Separate Dimension or Hierarchy
-
- Site Admin
- Posts: 1454
- Joined: Wed May 28, 2008 9:09 am
Re: Separate Dimension or Hierarchy
Who recommended combining 3 Oracle segments in a single dimension? It's rarely a good idea.
-
- MVP
- Posts: 2832
- Joined: Tue Feb 16, 2010 2:39 pm
- OLAP Product: TM1, Palo
- Version: Beginning of time thru 10.2
- Excel Version: 2003-2007-2010-2013
- Location: Atlanta, GA
- Contact:
Re: Separate Dimension or Hierarchy
Well.....it depends on what you are concatenating. In this example, speaking from my accounting background, I see very little to be gained by separating an Oracle Financials account code into it's three separate elements. It mostly depends on how granular the data is behind these different codes. I would make the decision based on the amount of detail the users want to see. For the Account dimension I would more than likely make it a single dimension with a hierarchy. If you are talking about the Entity and Department then I would more than likely keep them as separate dimensions. It all depends on the reporting needs.David Usherwood wrote:Who recommended combining 3 Oracle segments in a single dimension? It's rarely a good idea.
-
- Posts: 49
- Joined: Thu May 21, 2009 1:16 pm
- OLAP Product: TM1
- Version: 10.1
- Excel Version: 2007
Re: Separate Dimension or Hierarchy
My view is its possibly best to split them out, you don't really loose that much and its much more flexible.
I would expect Entity & Dept should be dimensions but also the other segments as well, then make the Accounts dimension into a nice hierarchy with weightings as needed.
I was once asked to hold 15 segments in a GL cube .... Oracle COA that would have made the GL cube 22 dimensions (Budgeting and Planning model), it was unusual as 5 segments were undefined ! and another 5 were very specific to sections of the accounts. The data was held in this detail but the needs were not reporting but adhoc analysis so I recommended separate cubes for that detail and keep the GL tight !
Also bear in mind that requirements change and your approach should allow for flexibility if possible....
I would expect Entity & Dept should be dimensions but also the other segments as well, then make the Accounts dimension into a nice hierarchy with weightings as needed.
I was once asked to hold 15 segments in a GL cube .... Oracle COA that would have made the GL cube 22 dimensions (Budgeting and Planning model), it was unusual as 5 segments were undefined ! and another 5 were very specific to sections of the accounts. The data was held in this detail but the needs were not reporting but adhoc analysis so I recommended separate cubes for that detail and keep the GL tight !
Also bear in mind that requirements change and your approach should allow for flexibility if possible....