したがって、必要なのは推移閉包を実現することです。つまり、このアプリケーションテーブルが与えられた場合...
ID | PARENT_ID
------+----------
1 |
2 | 1
3 | 2
4 | 2
5 | 4
...グラフテーブルは次のようになります：
PARENT_ID | CHILD_ID
-----------+----------
1 | 2
1 | 3
1 | 4
1 | 5
2 | 3
2 | 4
2 | 5
4 | 5
Oracleでこのようなテーブルを維持することは可能ですが、独自のフレームワークをロールする必要があります。問題は、それがオーバーヘッドの価値があるかどうかです。ソーステーブルが揮発性である場合、グラフデータを最新の状態に保つと、クエリで節約するよりも多くのサイクルがかかる可能性があります。データのプロファイルを知っているのはあなただけです。
CONNECTBYクエリとカスケード外部キーを使用してこのようなグラフテーブルを維持することはできないと思います。間接的な活動が多すぎて、正しく理解するのが難しい。また、1->5をザッピングするSQLクエリを記述できないため、マテリアライズドビューが表示されます。 ID=4のソースレコードを削除するときのレコード 。
したがって、Dong、Libkin、Su、およびWongによるSQLでのグラフの推移閉包の維持という論文を読むことをお勧めします。これには多くの理論といくつかの厄介な（Oracle）SQLが含まれていますが、グラフ表を維持するために必要なPL/SQLを構築するための基礎を提供します。
「CONNECTBY/カスケードFKで維持するのが難しすぎるという部分を拡張できますか？テーブルへのアクセスを制御し、すべての挿入/更新/削除が保存されたプロシージャを介して行われる場合、これが機能しなくなるシナリオはどのようなものですか？」
>
レコード1->5について考えてみます。 これは1->2->4->5の短絡です 。前に述べたように、ID=4のソースレコードを削除するとどうなりますか。 ？外部キーをカスケードすると、2->4のエントリが削除される可能性があります および4->5 。しかし、それは1->5を残します （そして実際に2->5 ）グラフテーブルでは、グラフの有効なエッジを表していないが 。
うまくいくかもしれませんが（私はそれをしていません）、このようにソーステーブルで追加の合成キーを使用することです。
ID | PARENT_ID | NEW_KEY
------+-----------+---------
1 | | AAA
2 | 1 | BBB
3 | 2 | CCC
4 | 2 | DDD
5 | 4 | EEE
これで、グラフテーブルは次のようになります。
PARENT_ID | CHILD_ID | NEW_KEY
-----------+----------+---------
1 | 2 | BBB
1 | 3 | CCC
1 | 4 | DDD
1 | 5 | DDD
2 | 3 | CCC
2 | 4 | DDD
2 | 5 | DDD
4 | 5 | DDD
したがって、グラフテーブルには、IDにリンクするのではなく、それを生成したソーステーブルの関係を参照する外部キーがあります。次に、ID=4のレコードを削除します NEW_KEY=DDDであるグラフテーブル内のすべてのレコードの削除をカスケードします 。
これは、特定のIDが0個または1個の親IDしか持てない場合に機能します。ただし、これが発生することが許容される場合は機能しません：
ID | PARENT_ID
------+----------
5 | 2
5 | 4
言い換えれば、エッジ1->5 1->2->4->5の両方を表します および1->2->5 。したがって、何が機能するかは、データの複雑さによって異なります。