超高速開発のＢＲＭＳっていうけど・・・

　日経コンピューター２０１２年３月１５日の特集は”「超高速開発」が日本を救う”ということで、ビジネスプロセスを入力することで、画面の自動生成をするとかいうツールを使った開発が、紹介されている。

　しかし、この手の開発は、Ｅｘｃｅｌを使った仕様書によって、大手開発会社（富士通とか）は、導入済みじゃないだろうか（INTARFRMとか、そうじゃなかったっけ？）。

　そして、この手の話がうまくいかない理由も、もう判っているのではないだろうか？
　つまり、「うちの会社は特殊で・・・」
　という形で、業務フローがまとまらない。

　今話題なのは、その先の話で、業務フローを単純に纏めようとすると、まとまんないから、基本的なビジネスプロセスと、各社で変更されるようなビジネスルールを分けるという話で、こうすると、業務フローがまとまりやすいという流れが、欧米で出てきている（次のＢＡＢＯＫとか）という話が、

第６回　要求シンポジウム　その１
http://blog.goo.ne.jp/xmldtp/e/55b28377d6199b9b66063216f6fa1b3b

で書いたこと。
ファクトモデルとか、ＳＢＶＲとかの話につながっていくんだけど・・

そこまで書いてないと、「いまさら感」になってしまう。

ＲＤＢに適しているもの、ＮｏＳＱＬに適しているものを結合の観点から

まとめてみた。

【テーブルを結合しない】
　　・どちらでもよい


【自己結合してしまう】
　　　・ＮｏＳＱＬが向いている
　　　・レコードレベルで、ツリー構造になっているはず。
　　　　　　複雑になると、ＲＤＢには向かない
（自己結合：
　　看護婦と婦長のように、同じテーブルのレコード内で親子関係があるため、
　　自分のテーブルを別名をつけて結合する）



【１対Ｎの多段階構造】
　　　・ＮｏＳＱＬが向いているがＲＤＢでもよい
　　　・テーブルレベルでツリー構造になっているはず。
例：テスト→問題→選択肢のような関係で、問題を使いまわさない。


【１対Ｎが、２箇所から来ている、Ｎ対Ｎ】
　　　・ＮｏＳＱＬだと、更新時に問題が出る
　　　　　　→が、それをクリアすれば良い
　　　・ＲＤＢでＪＯＩＮする
　　　　　　→遅くなる場合がある※

例：受注明細（受注１→受注明細Ｎ　と　商品１→受注明細Ｎ　の２箇所）
　　テスト→問題→選択肢のような関係で、問題を使いまわす。


※ＲＤＢで結合が遅くなる場合：対策
・マテリアライズド・ビューを使う（Oracleのみ）
　　→自分でマテリアライズド・ビューもどきをつくる

・クエリーキャッシュを使う
　　→自分でキャッシュしてがんばる