再帰SQL part2

yuuntim さん、半年前に書いた記事「再帰SQL」のコメントありがとうございます。
最近はOOAからどんどん離れて業務屋さんになった経験も踏まえて、もう一度考えを整理してみます。

【１】再帰ＳＱＬはツリー構造の情報を検索する時に使える

あの時は再帰ＳＱＬの意味や使い道が全く分かっていなかった。しかし、今の仕事のおかげで、再帰ＳＱＬは重要であり、色んな所で使えることを経験した。
再帰ＳＱＬが使われる具体例は二つすぐに思いつく。
一つは、個人の組織情報が階層構造になっている場合、もう一つは、商品がカテゴライズされていてカテゴリ情報が階層構造になっている場合だ。
組織構造の例は、アナパタのパーティそのもので、再帰構造になっている。
どちらにせよ、組織マスタとかカテゴリマスタのテーブルに階層構造の情報がツリー構造で保持されている時に有効になる。
但し、当然のことながら階層が深いほど、再帰ＳＱＬのレスポンスは悪くなる。

【２】再帰ＳＱＬはOracleでは普通に使われている
Oracleでは、CONNECT BY 句を使えばよい。
例えば、下記の例は良く出てくる。

--job='PRESIDENT' が、親子関係の頂点で、親子関係は empno=mgr が条件である従業員を検索する
select empno,level,lpad('-', 2*(LEVEL-1),'-') || ename ename ,mgr,job from emp
connect by prior empno = mgr start with job='PRESIDENT

余談だが、connect by 句はＳＱＬ本をいくら漁ってもなかなか出てこなくて、調査に随分苦労した。ツリー構造のデータなんて、生産管理でも良く出てくるのに、何故解説がないのだろう？
実はSQL ServerやDB2では上記SQLは使えないし、再帰SQLも最近までサポートされていない。Oracleだけver8以前からもサポートされていたらしい。さすがOracle。

【3】「生産管理・原価管理システムのためのデータモデリング」再考
今頃になって読み返して、まだ理解できていない点はありますが、少しずつ腑に落ちつつある。

「部品構成のループのチェック」についてすぐに思い浮かぶのは、ツリーを深く下がって検索する時に最下層がどこまでなのかを既に把握できていれば、計算しやすくなるはずだろうということ。
だから、構成品の削除・更新があるたびにLLCを再計算しているわけだ。これは確かに重い処理だと思う。

「所要量計算（あるいは原価計算）を行う品目の順序を決定する」処理の解説、yuuntim さんありがとうございます。
親品目の所要量の総計が計算できた後に、下層の品目の計算を行うために、ＬＬＣの昇順で降りていくわけですね。なるほど。この計算はすごく重たそう。
MRP所要量計算のアクションダイアグラム（P176参照）はPL/SQLで書いたとしたら、一時変数のカーソルでループ処理するために、すごく読みにくいだろうなあと勝手に想像します。

この本はまだ奥が深いです。また読み直します。

最近はクラス図よりもER図を片手に仕事する時が多い。仕様を理解できない時、ER図からインスタンスごとのリレーションを結んで、データがどのようにつながっているかを自然に書き散らすようになった。その感覚はオブジェクト図を書いているのと同じ。
データモデリングだろうがオブジェクト指向モデリングだろうが、やっていること、考えるやり方は結局似ている気がする。