さて、前回の「C 構造で吸収する」です。
ちなみに最近は「構造で解決する」と称しています。
これは、今までの開発方式だと、いろいろなデータストアやオブジェクトから必要なデータを
抽出し、ビジネスロジックを使って集計や照合を行いましょう、としていたところ、データの
配置と関連性でその大部分を賄ってしまおう、という発想です。
つまり、従来「開発者の利便性」のためだけに蔑ろにされがちだったRDBMSの参照整合性を
最大活用するのです。
一見、GXの一般的なプレゼンとセットで出てくる「データ中心設計」（DOA）のことかと思う
方もいるかもしれませんが、さにあらず。
GXは「データ中心設計」ではなく、「ユーザービュー中心設計」なのです。
ここで「ユーザービュー」というキーワードが出てきましたが、私見ではGX開発においては
一番基本となる概念のはずですが、そもそもキーワード自体がほとんど知られていない
という怖い状態になっています。
難しい説明を一切端折ると、GXプレゼンでよくつかわれる「WHATを入力すると、HOWは
自動で類推される」の「WHAT」に当たります。
それもG#流の解釈では、「WHO」(WHAT NAME)「WHEN」(WHAT TIMING)「WHERE」
(WHAT SEGMENT)を含んだWHATです。
つまり、誰がいつどこで何をしたいか、がわかればそこで使用されるデータならぬ
アトリビュートが判明し、おのずとデータ同士の関連性が決まる、ということです。
少し具体化すると、パートのおばちゃんが日々の実績Aを登録するのと、課の管理者が
月末に集計されたAを照会するのでは全くユーザービューが異なるわけですが、従来の
開発ではしばしば同じ画面が使われるのです。
確かに、DOAベースで正規化するとテーブルは一つになるから、ロジック側で集計するか
しないか、項目を表示するかしないか制御するということになりますが、GX及び作らない
開発ベースで考えるとこれは逆なのです。
「パートユーザービュー」と「管理者ユーザービュー」でそれぞれ必要なアトリビュートは
何かと考えた時に、「管理者ユーザービュー」では集計キーとなる課と月は必須となる
でしょう。
昔えらい人が言っていました、「キーを付けたっていうことはそのキーで集計したいんでしょ」
GXを知る前に聞いた言葉ですが、その時は強引だなあと思ったものですが、今では
非常に活用しています。その逆として…
「集計したいならそれをキーとして持っておくのは当然でしょ」
かくして、「パートユーザービュー」では、日々実績登録しかしないわけですが、日報月報
というように月を外部キーとして持っておくのが望ましいのです。
これで、「課」と「月」をキーとして持ったトランザクションではほぼ何も作らずに集計値を
表示する「管理者ユーザービュー」が完成するのです。
これを、DOAを齧った人は日（年月日）と月(年月）が重複するとしてひどく避ける傾向に
ありますが、このように「構造で解決」したほうが、画面とテーブルが直結し余計な
ロジックが入らなくなることによりレスポンスがほとんど減衰しないようになりますし、
コードを記述しないのでメンテナンス性も向上、条件分岐が最低限になるのでテスト
工数のスリム化も期待できます。
GXはDOAではない、これが「GXはデータ設計が不要」と言われる真の所以です。
何も設計しないのではありません。