Ragged Hierarchy and Skip Level Hierarchy

Hi all,
I am confused with ragged and skip level hierarchy, as i read some documents related to obiee 11g.
Will you please explain with an example the difference between ragged hierarchy and skip level hierarchy and also when to use these hierarchies?
regards
chandra kanth.

Chandra Kanth,
Hope this helps you
http://blogs.simba.com/.a/6a00e3932f172e88340133f4d758b5970b-800wi
Thanks,
Saichand.v

Similar Messages

Issue with Skip Level Hierarchy in OBIEE 11g

Hi,
I have implemented Ragged and Skip Level Hierarchy as explained in the links below in OBIEE 11g RPD.
(checked the 'Ragged' and 'Skipped Levels' check boxes)
http://www.rittmanmead.com/2010/07/obiee-11gr1-support-for-ragged-skip-level-value-based-hierarchies/
http://docs.oracle.com/cd/E17904_01/bi.1111/e10540/dimensions.htm#BABFBBFG
When the Presentation Hierarchy is dragged in the OBI Answers, the leaf level beyond the skip (null) levels is not shown in the report.
When any level finds intermediate null values, OBIEE is failing to show the existing value of the leaf level (Most Granular Level) or any values after Skipped Levels.
For example, following is the values in database for different levels of department hierarchy.
A -> B -> C -> Null -> Null -> F
The OBIEE Presentation Hierarchy can only drill down till C, not beyond that. (does not show the leaf level value 'F').
Could you please suggest whether I am missing any step?
Thanks.

Hi, My problem is that in my report it is showing me that levels as -- A -> B -> C -> Null -> Null -> F, however I want to show data as A -> B -> C -> F, i.e the null valus(columns) should be skipped. Please help.
Thanks and Regards,
Deepak

OBIEE 10g - Ragged & Skip Level Hierarchy

Hi Frnds,
I'm aware of the fact that OBIEE 11g supports Ragged & Skip Level Hierarchy. But I'm looking for some heads up while implementing the same on OBIEE 10g using Oracle DB as source. I have done this before for Essbase Data Source but now waiting for my Oracle dataset for design.
Has anyone actually implemented in Real Time Project? Pls share your challenges like:
- Dimensional Hierarchies Challenges
- Drill Down Challenges
- Report Challenges
Thanks,
Deepak
Edited by: Deepak Gupta on Aug 11, 2011 5:18 AM

Deepak,
10g does not handle the idea of Skip hierarchies and the ragged hierarchies definitely has its limitations.
We've implemented several projects using Essbase and SAP BW for Oracle BI 10g. The biggest issue is that in Answers creates a new column for each drill down selection when attempting to navigate down a hierarchy. Though this is klugy it does work and provides the data the user is looking for. It is however, not aesthetically please when compared to other tools or now Oracle BI 11g which satisfies this issue with a native drill-down tree folder structure.
My opinion and advice would be to upgrade to 11g as soon as possible to enjoy these new features.

OBIEE Essbase skip-level hierarchy

Is it possible to setup OBIEE and Essbase to be able to model skip-level hierarchy? It is obvious with connection to the relational database. How the essbase should designed and populated with data to faciliate this type of hierarchy?

Refer this http://www.oracle.com/technetwork/middleware/bi-enterprise-edition/overview/obiee-essbase-modeling-guide-130897.pdf for Modeling. And for any Essbase releated question post it in Essbase forum Essbase

Profit center hierarchy and cost center hierarchy

Hi
What are the things we have to consider to create Profit center hierarchy and cost center hierarchy and what is the need to assign profit center hierarchy to profit center and cost center hierarchy to cost center. What levels does this fall into? Can some one please guide me.
Thanks.

As you would for any other infoobject
Activate the business content hierarchy datasources on R3 for cost centre and profit centre
Go into BW - replicate the metadata
Then just connect via transformations or transfer rules the datasources to yoru infosources or master data objects
Create an infopackage per hierarchy!!!!! - press the button available hirachies from OLTP - click the one you want on the left - fire it off
Then repeat new infopackages for all hierachies

Design a dimension with skip-level hierarchy and its ETL

Hi gurus,
I'm trying to understand how to set up and use a skip level dimension and its corresponding mapping in OWB 11.2.
A simplified version of my hierarchy would be like Total-Brand-LOB-Product where Some Products connect directly to Brand and others connect to LOB.
My first question is about designing this kind of dimension in OWB. Is it better to create a single hierarchy with the Product level skipped to Brand level or 2 hierarchies - one Total-Brand-LOB-Product and the other Total-Brand-Product?
My second question is about creating its corresponding ETL mapping. Selecting each option above result in 2 FKs for Brand and LOB in Product level. What is the correct design to fill these 2 FKs?
Any help/guidance would be truly appreciated!
Thanks,
Iman

Hi, My problem is that in my report it is showing me that levels as -- A -> B -> C -> Null -> Null -> F, however I want to show data as A -> B -> C -> F, i.e the null valus(columns) should be skipped. Please help.
Thanks and Regards,
Deepak

Skipped and ragged level hierarchy in OBIEE11g

Hi
I tried creating aboth skipped and ragged hierarchy in OBIEE 10g
It works fine without error
SO I have doubt why they have introduced this concept in OBIEE 11g, Is there any more feture about this
Please help me

@Abdul : can you please let us know how you have implemented skip level hierarchy in 10g..
actually we need to implement it ,didn't find anything in google search ...
thanks In advance

BPC 10.0 NW - skipping in hierarchy upload

Hej Gurus
I have a question regarding automatic upload of a hierarchy from BW into BPC. We have a hierarchy with all costcenters including both active and inactive costcenters, and these costcenters are spread out through the hierarchy.
In BPC, we only need the active costcenters, but the inactive is needed in other applications, so it is not possible to change the hierarchy.
Is it possible to do a skip based on a BW attribute, when importing a hierarchy or is it possible to make it only look at costcenters in BPC?
Alternatively, is it possible to pick up the parent in the master data attribute/text from BW process chain? In this it is possible to skip based on an attribute.
Best regards,
Mikkel Kristensen

Hi Mikkel,
As suggested by Gersh, you have to consider that point.
Coming to the you problem you can crated additional hierarchy for BPC to existing info object by considering only active CCs with the help of ABAP. You can also automate this hierarchy creation.
While loading master data you can load only active CC by selecting option "Set filters by attribute AND hierarchy" and while loading hierarchy select custom hierarchy created for BPC. This approach will not affect your existing development and no need to create z object as well as no need to add in to cube.
Shrikant

Help with Skip Level dimensions in OWB 10.2 (Paris)

Hi all,
I'm trying to understand how to set up and use a skip level dimension in OWB 10.2. A simplified version of my hierarchy would be:
Plant - Equipment - Assembly - Item
Where Some Items connect directly to equipment and others connect to assemblies. How sould I define this in the Dimension wizard or editor in OWB?
Can I create a single dimension hierarchy and in the Item level put Skip Level as "Equipment"?
OR
Do I need 2 hierarchies - one Plant-Equipment-Assembly-Item and the other Plant-Equipment-Item?
There is an example in the Users guide that created 2 hierarchies -
TOTAL-GROUP-PRODUCT and TOTAL-PRODUCT
In the example, they show the PRODUCT in TOTAL-PRODUCT setting the skip level field. I don't understand why that is necessary if it is 2 seperate hierarchies.
Any help/guidance would be appreciated!
Thanks,
Mike

Hi Donna,
Perhaps JP can expand on his answer. In my case, I did go the route of seperate hierarchies. It is a bit of work defining multiple hierarchies and my example was much simplified. We actually have about 8 levels in the primary hierarchy and 6 levels in the second. It does work well with the cubes by using 2 roles for the dimension - one for each hierarchy.
I saw that truly "ragged hierarchies" or "level hierarchies" can be defined in OWB and deployed as MOLAP but MOLAP has quite a few drawbacks - no SCDs and requires analytic workspaces etc. I haven't done anything with these yet.
Our data is a classic manufacturing Bill of Material so the level hierarchy would be the easiest to manage, though I'm not sure how easy it would be to report on! I do want to shield my end-users from CONNECT-BY madness.

Skip Level Dimensions

Dear all
We have a client with an interesting problem. I was wondering if the group could offer any feedback on this design question, where we think it involves a concept called 'skip levels'. The client is using Oracle 9.0.2 with their data mart cube held as ROLAP. Our first thoughts are that what they want to do is better served by using a true OLAP tool such as Oracle Express, or Oracle 9i OLAP, which deals with skip level dimensions easier. Anyway, here's the problem :
"For our warehouse project, we need some dimensions (initially: account, company) that use a skip level hierarchy. This means that the lowest level dimensions are of the same level (G/L account or company) and they need to roll up in a structure of varying levels, before they come together again in a highest level.
Ideally, we would like to use a data structure that can be used transparently by the user and allows for rollups of amounts through the dimension. We would like to be able to populate the dimension through OWB and to query the data using both Crystal reports v9 and BI beans and possibly other tools that recognize the Oracle data warehouse concept.
The two solutions we are aware of are:
1. Insert Dummy levels:
This is not a nice solution but is will work and it is simple.
2. Insert a helper table that contains the higher level account with all the children (as per Ralph Kimball)
This seems a cumbersome solution but I am sure it would work also. The question is how the Oracle's BI beans and the CWM2 metadata would recognize this and how we can make this transparent to the user.
I am sure there are other solutions to the problem. It seems like the problem would be solved by the next release of Oracle (9.0.3?), which allows us to deal with skip level hierarchies through CWM2 (which I believe this is). The solution we choose should also allow us to easily upgrade to the new skip level hierarchy, which I would expect to be easier to use then the above."
The main thing to bear in mind here is that they want to implement a ROLAP solution, using Oracle 9i tables, dimensions and heirarchies. It also has to work with Oracle Warehouse Builder, take advantage of the CWM2 metadata (if possible) and work with the BI Beans.
Any thoughts on this? Does anyone know how Oracle are going to cater for skip-level dimensions with the next release? Is this through the improved support for the CWM2 metadata standard for ROLAP cubes, or is the customer best of going to the true OLAP 'Analytic Workspace'? If we ignore a MOLAP solution, what's the best way of dealing with this, in such a manner that it's transparent to query tools, and isn't too much of a 'hack'?
Many thanks in advance,
Mark Rittman
Mark Rittman
Consulting Manager, Plus Consultancy
[email protected]
[email protected]--------------

As part of my search i've uncovered an article by Ralph Kimball on using 'helper tables' to deal with ragged hierarchies.
http://www.dbmsmag.com/9809d05.html
This advocates using a table between the fact table and the dimension. Quoting from Mr. Kimball;
"You can solve this modeling problem by inserting a helper table between the dimension table and the fact table, as shown in Figure 3 (http://www.dbmsmag.com/9809d05.html#fig3). Amazingly enough, you don't have to make any changes to either the dimension table or the fact table; you just rip the join apart and insert the helper table.
The helper table contains one record for each separate path from each node in the organization tree to itself and to every node below it. There are, then, more records in the helper table than there are nodes in the tree. In Figure 3 we need a total of 43 records in the helper table. See if you can work this out.
Each record in the helper table contains the fields:
- Parent Customer Key
- Subsidiary Customer Key
- Depth From Parent
- Lowest Flag
- Topmost Flag.
If you are descending the tree from certain selected parents to various subsidiaries, you join the dimension table to the helper table and the helper table to the fact table with the joins as shown in Figure 3. The Depth From Parent field counts how many levels the subsidiary is below the parent. The Lowest Flag field is True only if the subsidiary has no further nodes beneath it. The Topmost Flag field is True only if the parent has no further nodes above it.
The beauty of this design is that you can place any normal dimensional constraint against the Customer dimension table and the helper table will cause all the fact table records for the directly constrained customers plus all their subsidiaries to be correctly summarized. In other words, you can use your standard relational databases and your standard query tools to analyze the hierarchical structure."
My question is - has anyone tried to implement this with OWB, or with the Oracle ROLAP data warehouse in general, reporting through Discoverer or BI Beans? Any opinions?
thanks
Mark

Ragged Hierarchies and extra joins

We have an ORG_DIM with a three-level logical hierarchy (LVL-All, LVL-1, LVL-2, LVL-3 -- the leaf/detail level). The primary key is LVL3_KEY; LVL2_KEY and LVL1_KEY are level keys. We have a SYS_DIM with the trival (all/detail) logical hierarchy and SYS_KEY primary key.
We have a base fact and two aggregate facts -- LVL1_FACT, LVL2_FACT and LVL3_FACT (level 3 is the base); the logical Fact - Lvls has an LTS for each of these physical fact tables. The base fact (LVL3_FACT) has LVL13_KEY and SYS_KEY as its primary key and also has columns LVL2_KEY and LVL1_KEY; the aggregate facts lose LVL3_KEY and LVL2_KEY, respectively.
ORG_DIM represents a flattened skip-level hierarchy. (There are actually more levels and more tables, but I am simplifying the problem for this description.)
We also have an ORG_STACK table (ORGNAME, ORGKEY, PARENTORGKEY, LFT, RT, STACKLVL), following a method for implementing ragged hierarchies proposed by Kurt Wolff and Joe Celko. The ORG_STACK table has three aliases -- ORG_PARENTS, ORG_CHILDREN and ORG_LEAVES. The first two are joined on (ORG_CHILDREN.PARENTORGKEY=ORG_PARENTS.ORGKEY). The latter two are joined on (ORG_CHILDREN.LFT BETWEEN ORG_LEAVES.LFT AND ORG_LEAVES.RT) -- a complex physical join. ORG_LEAVES joins to LVL3_FACT on ORG_LEAVES.ORG_KEY=LVL3_FACT.LVL3_KEY. The logical Fact - Lvls has a 4th LTS in which ORG_LEAVES and LVL3_FACT are joined.
We run a query in answers that invokes columns from logical tables Dim - OrgChildren, Dim - OrgParents and Fact - Lvls; one of the columns from Fact - Lvls is mapped only in the LTS that joines ORG_LEAVES with LVL3_FACT. This query spins for a long time without returning any result, so we end up cancelling it. We intend to have a DBA look at it.
The generated SQL includes those tables (ORG_STACK aliases and LVL3_FACT) plus ORG_DIM and SYS_DIM. We can see nothing in the query that requires ORG_DIM or SYS_DIM; how can we determine why these are included in the SQL?
Queries that used columns from Dim - Org also showed poor performance after the other Dim - OrgXXX (the stack suff) were added. Presumably this was because the LTS for Fact - Lvls that maps to LVL3_FACT also joined the (much larger) ORG_STACK table via ORG_LEAVES. Adding the 4th LTS for that (leaving the 3rd LTS mapped only to LVL3_FACT) should have resolved this. However, the interesting this is that removing the logical join between Dim - OrgChildren and Fact - Lvls resolved this problem. If the problem was ORG_LEAVES and LVL3_FACT joined in the LTS, then removing a logical join should not have affected it.

Chandra Kanth,
Hope this helps you
http://blogs.simba.com/.a/6a00e3932f172e88340133f4d758b5970b-800wi
Thanks,
Saichand.v

Value based hierarchies, Skip Level Hierarchies

Hello,
I need to create hierarchy based on column value , Please give me some details on implementing value based hierarchies and skip level hierarchies in obiee 10.1.3.
Thank you

With 10.3 i do not think we have a inbuilt solution to build value based hierarchies, you have to flatten the hierarchy and build a level based hierarchy.
OBIEE 11g has value based hierarchies feature.
refer this one for 11g.
http://sandybi.wordpress.com/2010/08/17/hierarchies-in-obiee-11g-part-1/
- Madan
Edited by: Madan Thota on Sep 14, 2010 11:15 AM

ROLAP skip level dimension support - CWM2?

Dear all
We have a client with an interesting problem. I was wondering if the group could offer any feedback on this design question, where we think it involves a concept called 'skip levels'. The client is using Oracle 9.0.2 with their data mart cube held as ROLAP. Our first thoughts are that what they want to do is better served by using a true OLAP tool such as Oracle Express, or Oracle 9i OLAP, which deals with skip level dimensions easier. Anyway, here's the problem :
"For our warehouse project, we need some dimensions (initially: account, company) that use a skip level hierarchy. This means that the lowest level dimensions are of the same level (G/L account or company) and they need to roll up in a structure of varying levels, before they come together again in a highest level.
Ideally, we would like to use a data structure that can be used transparently by the user and allows for rollups of amounts through the dimension. We would like to be able to populate the dimension through OWB and to query the data using both Crystal reports v9 and BI beans and possibly other tools that recognize the Oracle data warehouse concept.
The two solutions we are aware of are:
1.     Insert Dummy levels:
This is not a nice solution but is will work and it is simple.
2.     Insert a helper table that contains the higher level account with all the children (as per Ralph Kimball)
This seems a cumbersome solution but I am sure it would work also. The question is how the Oracle's BI beans and the CWM2 metadata would recognize this and how we can make this transparent to the user.
I am sure there are other solutions to the problem. It seems like the problem would be solved by the next release of Oracle (9.0.3?), which allows us to deal with skip level hierarchies through CWM2 (which I believe this is). The solution we choose should also allow us to easily upgrade to the new skip level hierarchy, which I would expect to be easier to use then the above."
The main thing to bear in mind here is that they want to implement a ROLAP solution, using Oracle 9i tables, dimensions and heirarchies. It also has to work with Oracle Warehouse Builder, take advantage of the CWM2 metadata (if possible) and work with the BI Beans.
Any thoughts on this? Does anyone know how Oracle are going to cater for skip-level dimensions with the next release? Is this through the improved support for the CWM2 metadata standard for ROLAP cubes, or is the customer best of going to the true OLAP 'Analytic Workspace'? If we ignore a MOLAP solution, what's the best way of dealing with this, in such a manner that it's transparent to query tools, and isn't too much of a 'hack'?
Many thanks in advance,
Mark Rittman
Mark Rittman
Consulting Manager, Plus Consultancy
[email protected]
[email protected]--------------

Dear all
We have a client with an interesting problem. I was wondering if the group could offer any feedback on this design question, where we think it involves a concept called 'skip levels'. The client is using Oracle 9.0.2 with their data mart cube held as ROLAP. Our first thoughts are that what they want to do is better served by using a true OLAP tool such as Oracle Express, or Oracle 9i OLAP, which deals with skip level dimensions easier. Anyway, here's the problem :
"For our warehouse project, we need some dimensions (initially: account, company) that use a skip level hierarchy. This means that the lowest level dimensions are of the same level (G/L account or company) and they need to roll up in a structure of varying levels, before they come together again in a highest level.
Ideally, we would like to use a data structure that can be used transparently by the user and allows for rollups of amounts through the dimension. We would like to be able to populate the dimension through OWB and to query the data using both Crystal reports v9 and BI beans and possibly other tools that recognize the Oracle data warehouse concept.
The two solutions we are aware of are:
1.     Insert Dummy levels:
This is not a nice solution but is will work and it is simple.
2.     Insert a helper table that contains the higher level account with all the children (as per Ralph Kimball)
This seems a cumbersome solution but I am sure it would work also. The question is how the Oracle's BI beans and the CWM2 metadata would recognize this and how we can make this transparent to the user.
I am sure there are other solutions to the problem. It seems like the problem would be solved by the next release of Oracle (9.0.3?), which allows us to deal with skip level hierarchies through CWM2 (which I believe this is). The solution we choose should also allow us to easily upgrade to the new skip level hierarchy, which I would expect to be easier to use then the above."
The main thing to bear in mind here is that they want to implement a ROLAP solution, using Oracle 9i tables, dimensions and heirarchies. It also has to work with Oracle Warehouse Builder, take advantage of the CWM2 metadata (if possible) and work with the BI Beans.
Any thoughts on this? Does anyone know how Oracle are going to cater for skip-level dimensions with the next release? Is this through the improved support for the CWM2 metadata standard for ROLAP cubes, or is the customer best of going to the true OLAP 'Analytic Workspace'? If we ignore a MOLAP solution, what's the best way of dealing with this, in such a manner that it's transparent to query tools, and isn't too much of a 'hack'?
Many thanks in advance,
Mark Rittman
Mark Rittman
Consulting Manager, Plus Consultancy
[email protected]
[email protected]--------------

Poor performance when using skip-level hierarchies

Hi there,
currently we have big performance issues when drilling in a skip-level hierarchy (each drill takes around 10 seconds).
OBIEE is producing 4 physical SQL statements when drilling f.e. into the 4th level (for each level one SQL statement). The statements runs in parallel and are pretty fast (the database doesn't need more than 0,5 seconds to produce the result), but ... and here we have probably somewhere a problem ... putting all the 4 results together in OBIEE takes another 8 seconds.
This are not big datasets the database is returning - around 5-20 records for each select statement.
The question is: why does it take so long to put the data together on the server? Do we have to reconfigure some parameters to make it faster?
Please guide.
Regards,
Rafael

If you really and exclusively want to have "OBIEE can handle such queries" - i.e. not touch the database, then you had best put a clever caching strategy in place.
First angle of attack should be the database itself though. Best sit down with a data architect and/or your DBA to find the best setup possible physically and then when you've optimized that (with regard to the kind of queries emitted against it) you can move up to the OBIS. Always try t fix the issue as close to the source as possible.

Parent-child hierarchy and fragmentation content

Hello,
I've tried to build simple model with OBIEE 11 using Oracle 11r2 as a data source. BMM has fragmentation content for fact table and few dimensions with different hierarchy types. It works fine with all hierarchy types except for parent child.
When I build an answer with parent child hierarchy it terminates with error "Target data source does not support the operation".
Does OBIEE 11 not support parent child with fragmentation content? Or am I missing something?
Greetings
Marcin

I'm seeing the same issue. I've created a parent-child hierarchy along with two normal level-based hierarchies (one "normal", one skipped-level). The two level-based hierarchies work just fine in Answers. I can include them in the criteria, and data is displayed with the correct drilldowns.
If I include the parent-child hierarchy, I get the same results as noted in the original post: "The layout of this view combined with the data, selections, or drills, or prompt values chosen, resulted in no data." I'm trying to look at the table view, with no filters.
Interestingly, I can explicitly include that dimension's Parent column and Member column in the criteria, and data is displayed just fine.
Here is the XML for the set of criteria that includes the separate Parent and Member columns (the one that works):
SELECT s_0, s_1, s_2, s_3, s_4, s_5, s_6, s_7, s_8, s_9, s_10, s_11 FROM (
SELECT
0 s_0,
"Retro_Biz"."Channels"."MEMBER" s_1,
"Retro_Biz"."Channels"."PARENT" s_2,
"Retro_Biz"."Products"."TOTAL_PRODUCT" s_3,
"Retro_Biz"."Times"."YEAR" s_4,
SPACE(1) s_5,
SPACE(1) s_6,
SPACE(1) s_7,
IDOF("Retro_Biz"."Products"."Product"."Total Product") s_8,
IDOF("Retro_Biz"."Times"."Time"."Year") s_9,
"Retro_Biz"."Facts"."SALES" s_10,
CAST(NULL AS DOUBLE) s_11
FROM "Retro_Biz"
UNION ALL
SELECT
1 s_0,
"Retro_Biz"."Channels"."MEMBER" s_1,
"Retro_Biz"."Channels"."PARENT" s_2,
SPACE(1) s_3,
SPACE(1) s_4,
SPACE(1) s_5,
SPACE(1) s_6,
SPACE(1) s_7,
SPACE(1) s_8,
SPACE(1) s_9,
CAST(NULL AS DOUBLE) s_10,
REPORT_SUM("Retro_Biz"."Facts"."SALES" BY ) s_11
FROM "Retro_Biz"
) djm ORDER BY 1, 5 ASC NULLS FIRST, 4 ASC NULLS FIRST
Here is the XML that includes the Parent-Child hierarchy (the one that fails):
SELECT s_0, s_1, s_2, s_3, s_4, s_5, s_6, s_7, s_8, s_9, s_10, s_11, s_12 FROM (
SELECT
0 s_0,
"Retro_Biz"."Channels"."MEMBER" s_1,
"Retro_Biz"."Products"."TOTAL_PRODUCT" s_2,
"Retro_Biz"."Times"."YEAR" s_3,
CASE WHEN ISLEAF("Retro_Biz"."Channels"."Channel") THEN 1 ELSE 0 END s_4,
IDOF("Retro_Biz"."Channels"."Channel") s_5,
SPACE(1) s_6,
SPACE(1) s_7,
SPACE(1) s_8,
IDOF("Retro_Biz"."Products"."Product"."Total Product") s_9,
IDOF("Retro_Biz"."Times"."Time"."Year") s_10,
PARENT("Retro_Biz"."Channels"."Channel") s_11,
"Retro_Biz"."Facts"."SALES" s_12
FROM "Retro_Biz"
WHERE
ISROOT("Retro_Biz"."Channels"."Channel")
UNION ALL
SELECT
1 s_0,
SPACE(1) s_1,
SPACE(1) s_2,
SPACE(1) s_3,
CAST(NULL AS INTEGER) s_4,
SPACE(1) s_5,
SPACE(1) s_6,
SPACE(1) s_7,
SPACE(1) s_8,
SPACE(1) s_9,
SPACE(1) s_10,
SPACE(1) s_11,
"Retro_Biz"."Facts"."SALES" s_12
FROM "Retro_Biz"
WHERE
ISROOT("Retro_Biz"."Channels"."Channel")
) djm ORDER BY 1, 4 ASC NULLS FIRST, 3 ASC NULLS FIRST

Ragged Hierarchy and Skip Level Hierarchy

Similar Messages

Maybe you are looking for