2011-10-31 10 views
1
Master Table 
=========== 
ID NAME 
1 A 
2 B 
3 C 
4 D 
5 E 

階層テーブルが複数の親階層recusion

Relations Table 
================ 
ChildID ParentID 
    3  1 
    3  2 
    4  3 
    4  2 
    5  4 

階層は以下のようになった(いずれも値を重複するため、プライマリ列にすることはできないことに注意してください)(それは、このリニアは、常にではないかもしれません):

1   2 
    |   | 
    3   3 
    |   | 
    4   4 
    |   | 
    5   5 

質問:私は、再帰的な階層形式のデータを必要とする目的を報告するための

ので、私はそれを掘ることができる。私は既存のデータ自体からフィーチャーをドリルダウンすることはできません(重複した値によって再帰的な親子関係を作成できないようです)

いずれかのアイデアはありますか? 私の目標は、SSASのディメンションとしてこの構造を最終的に使用して、テーブルに自己主キーと子キーの関係がある場合に自動的にドリルダウンすることです。

答えて

4

あなたの例のデータを使用して、私は実際には別のツリーを取得...

Relations Table   Tree 
================   ======= 
ChildID ParentID   1 2 
    3  1    \ /| 
    3  2    3 | 
    4  3     \| 
    4  2     4 
    5  4     | 
           5 

あなたは実際には二つの独立した木がしたいですか?その場合は、あなたが情報のいくつかの余分な部分がないと...このようなツリーIDとして

Relations Table    Tree1  Tree2 
=======================  =====  ===== 
TreeID ParentID ChildID   
    1  NULL  1   1   2 
    1  1  3   |   | 
    1  3  4   3   3 
    1  4  5   |   | 
    2  NULL  2   4   4 
    2  2  3   |   | 
    2  3  4   5   5 
    2  4  5 

を追加フィールドを導入でき、あなたは常に非常によく形成されてセットすることなく、枝の分割やマージの問題があるでしょうの制約。たとえば、あなたは1-3-4-5と2-3-4-6の2本の線形木を望んでいた場合、あなたの現在のモデルがこれを持っているでしょう...

Relations Table   Tree 
================   ======= 
ParentID ChildID   1 2 
    1  3    \/
    2  3    3 
    3  4    | 
    4  5    4 
    4  6    /\ 
          5 6 

あなたが今持っているけれども問題であり、 4つのリニアパスがあること...
- 1-3-4-5
- 1-3-4-6
- 2-3-4-5
- 2-3-4-6

実際の状況を正確に記述し、必要なものを正確に記述し、必要としないものを正確に記述することが必要な場合があります。


私の典型的な経験では、レポート作成のため、ツリー内の任意のノードが一つだけの親を持つべきである、ということですが、多くの子供を持つことができます。これは、ツリーを登るときには1つのルートしか持たず、ツリーを登るときにはデータがサブノードに分割されることを意味します。

多くの親と多くの子供がいると、ツリーではなくウェブが作成されます。あなたが複数のルートを持っている場合、ツリーをどの方向にトラバースしても問題ありません。