Hierarchial Data Retrieval

Question

Hi,
Following is the DDL and DML im Using.
create table test_connect_by (
  parent     number,
  child      number,
  constraint uq_tcb unique (child)
insert into test_connect_by values ( 5, 2);
insert into test_connect_by values ( 5, 3);
insert into test_connect_by values (18,11);
insert into test_connect_by values (18, 7);
insert into test_connect_by values (17, 9);
insert into test_connect_by values (17, 8);
insert into test_connect_by values (26,13);
insert into test_connect_by values (26, 1);
insert into test_connect_by values (26,12);
insert into test_connect_by values (15,10);
insert into test_connect_by values (15, 5);
insert into test_connect_by values (38,15);
insert into test_connect_by values (38,17);
insert into test_connect_by values (38, 6);
insert into test_connect_by values (null, 38);
insert into test_connect_by values (null, 26);
insert into test_connect_by values (null, 18);
Commit;
select lpad(' ',2*(level)) || to_char(child) s
  from test_connect_by
  start with child =10
  connect by prior parent = child;In the above query i have used connect by clause to retrive data in bottom up order.
I want this query to be rewritten using joins ,since i have netezza database which doesn't support connect by clause.
Thanks for ur help

Answer 1

Hi,
Thanks for posting the CREATE TABLE and INSERT statements; that's very helpful!
It's going to be very difficult (if not impossible) to get the exact same output that CONNECT BY provides without using CONNECT BY.
Here's one way to get the exact same results as your CONNECT BY query:
WITH     horizontal     AS
     SELECT     l1.child     || '/' ||
          l2.child     || '/' ||
          l3.child     || '/' ||
          l4.child          AS path
     FROM          test_connect_by     l1
     LEFT OUTER JOIN     test_connect_by     l2  ON     l1.parent = l2.child
     LEFT OUTER JOIN     test_connect_by     l3  ON     l2.parent = l3.child
     LEFT OUTER JOIN     test_connect_by     l4  ON     l3.parent = l4.child
     WHERE     l1.child     IN (10)     -- Corresponds to START WITH
,     cntr     AS
     SELECT     ROWNUM     AS n
     FROM     test_connect_by
     WHERE     ROWNUM     <= 4
,     vertical     AS
     SELECT       h.path
     ,       LPAD ( ' '
                 , 2 * c.n
           ||  REGEXP_SUBSTR ( h.path
                    , '[^/]+'
                    , 1
                    , c.n
                    )          AS s
     FROM          horizontal     h
     CROSS JOIN     cntr          c
SELECT       s
FROM       vertical
WHERE       LTRIM (s)     IS NOT NULL
ORDER BY  path
,       s          DESC
;This allows you to find the ancestry of multiple nodes in the same query.
As you can see, it assumes we know an upper bound to the number of levels in the hierarchy. In the first sub-query, horizontal, we hard-code that many copies of the original table in a self-join. Your sample data had (at most) four levels, so I self-joined 4 copies of the test_connect_by table. I could have done 5, or 6, or 56, but whatever number is chosen, it has to be hard-coded.
The rest of the query un-pivots the result set of horizontal into a vertical format, exactly like that produced by your original CONNECT BY query. If you could live with a different format, it could be simpler. For example, horizontal alone tells us everything about the ancestry of the given nodes. That data could easily (more easily, in fact) be presented as separate columns showing the parents, grandparents, ... of the given nodes.
I suggest not trying to mimic CONNECT BY exatly, either in the kind of output you expect, or in how the data is stored.
The Adjacency Model that you used, where every row has a pointer to an adjacent node (its parent) is just one way to model a tree in a relational database. This model works well with recursion. Does Netezza have any recursive capabilities, such as recursive WITH clause, or user-defined functions?
Another way to modeal a tree is what I call the Lineage Model , where every row contains its complete ancestry, like this
INSERT INTO lineage (child, lineage) VALUES (38, '38');
INSERT INTO lineage (child, lineage) VALUES (15, '38,15');
INSERT INTO lineage (child, lineage) VALUES (10, '38,15,10');
INSERT INTO lineage (child, lineage) VALUES ( 5, '38,15,5');
INSERT INTO lineage (child, lineage) VALUES ( 2, '38,15,5,2');
...Another way to model a tree is the Nested Sets approach, where every row has a pair of numbers that indicates which rows are its descendants:
INSERT INTO nested_sets (child, from_n, to_n) VALUES (38,  1, 20);
INSERT INTO nested_sets (child, from_n, to_n) VALUES (15,  2, 11);
INSERT INTO nested_sets (child, from_n, to_n) VALUES (10,  3,  4);
INSERT INTO nested_sets (child, from_n, to_n) VALUES ( 5,  5, 10);
INSERT INTO nested_sets (child, from_n, to_n) VALUES ( 2,  6,  7);
...If X is a descendant of Y, then X's from_n and to_n will both be between Y's from_n and to_n.
You might want to think about what kinds of operations you'll need to do on the tree, and what kinds iof output would be satifactory, and then decide on the best data model to achieve those ends.