話は戻りまして、GeneXusの上手な使い方です。そもそもの話は
開発経験が豊富な人、特に熟練のDB設計者はトランザクションオブジェクト=テーブルと捕らえてしまい、自分の頭の中でER図を設計しその結果をトランザクションストラクチャーとして定義してしまいがちです。
結果として、全くリレーションがないデータモデルが出来てしまったり、リレーションが張られても設計者が想定しないテーブル間でのリレーションであったりします。
でしたね。
では、どうすれば設計者が想定するようなデータモデルが出来るのでしょうか? ポイントとして3点あります。
(1)トランザクション定義においては対象業務の事実にフォーカスする
データモデルを意識してもいいですが、トランザクション定義においては一旦それは横に置いて、まずは対象となる業務処理(例えばデータエントリ処理)にフォーカスして項目・構造を考えます。これがユーザービューという考え方です。とかくエンジニアは内部構造を先回りして考えがちです。これをなんとか我慢しましょう。
(2)項目属性の名前付けは業務としての意味合いを追求する
GeneXusでは項目属性の名前付けは非常に重要です。項目属性に着けられた名前によってGeneXusが正規化処理を進めるからです。GeneXusの基礎教育(ベーシックコース)の中にも記述がありますが
・同じコンセプト(意味合い)のものは同じ名前に
・違うコンセプト(意味合い)のものは違う名前に
です。
(3)結果として出力されるデータモデルと自分が頭の中で想像するデータモデルを比較・検証する。
非常に不思議なのですがこのチェックを行う事により、アウトプットが正しくない=自分が正しいと思って定義したトランザクション(項目属性・構造)が実は業務のとらえ方として違っている。又は、自分が頭で思い描いたデータモデルは実はトリッキーなモデル(テクニックに頼ったデータの取り出し方をする)だという事に気付かされる事があります。
具体例として・・
受注トランザクションに商品情報を定義する場合「商品価格」という項目属性を定義します。しかし、「商品価格」は「商品トランザクション(商品マスタ)」にも存在します。すると、GeneXusは正規化処理を行って、「商品価格」は物理的には商品テーブルに配置し、受注テーブルには配置しません。
このモデルは正規化処理としては正しいですが、実際の業務としては正しいでしょうか?
商品情報はいわゆるマスタ情報ですが、「商品価格」は未来永劫同じ金額でしょうか? 商品価格=売価は月日の経過で変動する事もあります。先のデータモデルでは商品価格を変更すると、過去に登録した受注情報の商品価格まで変わってしまいます。既に決済が終わっている情報(特に金額に関する項目)が後から変わってしまうのは業務としては大問題になってしまいます。
商品価格が商品テーブル側にしか存在しないのが問題でしょうか? であれば、受注テーブル側にも商品価格を持つように変更すればよいでしょうか? GeneXusでは「冗長」をONにすれば、論理的に存在していないテーブル側に項目を持たせる事は可能になります。
でも、今回のケースではこの対応では間違いです。冗長とはあくまでも「同じ項目の同じ値を複数の場所で保持する」為のもので、問題のような時間が経ったら商品マスタテーブル側の価格は変更するが、受注テーブル側の価格は変更したくない。といったケースには使えません。
では、どうしたらよいでしょうか?
よくよくその項目属性に求められる「意味合い」を考えてみると、受注トランザクションに保持する商品価格は「受注時の商品価格」であって、商品トランザクションで持っている「商品価格」とは意味あいが違う事に気が付きます。
そこで、商品トランザクションは「商品価格」、受注トランザクションは「受注時商品価格」と名前付けをすると、GeneXusとしては別な項目と認識して正規化処理を進めます。
結果的に商品テーブルは「商品価格」が、受注テーブルには「受注時商品価格」がそれぞれ配置されます。
「名は体を表す」とはよく言ったものです。GeneXusでは意味合い(体)を突き詰めて考えるとそれに相応しい名前が思いつき、正しい名前が付けられればGeneXusが正しい正規化処理を行ってくれます。
業務に精通し、その業務で扱われる項目属性を正しく認識し、正しく名前付けられれば、設計のテクニック論に惑わされる事なく、正しいデータモデルを得ることができる。まさに、絵画における遠近法と同様の事をソフトウェア設計(データモデリング)でGonda氏は実現したのです。
