■DI対策
先々号で「現行ＤＢＭＳの欠陥」を述べましたが、今回はその
「③ＤＩ（Derivation Integrity：加工データ整合性）の抜け」に対する対策を
考察します。
分かりやすさのため、部品入庫により部品残高および買掛残高が増える事例を考えます。
すなわち、いま
［入庫＃］－（品、倉、入庫数、入庫金額、取引先、区分）
５ Ｐ Ｗ ５ ￥５０ Ｓ 買
のレコードが発生したとします。これによって次のように、部品残高および掛残高は
ｓ１からｓ２に変化します。
［品．倉］－（部品残高） ［取引先．区分］―（掛残高）
ｓ１： Ｐ Ｗ １００ Ｓ 買 ￥２００
ｓ２： Ｐ Ｗ １０５ Ｓ 買 ￥２５０
この場合、従来法ではＤＢＭＳに向けて、アプリケーションプログラム（ＡＰ）から、
次のように３つの更新トランザクション（ＴＲＸ）が発行されるものと思われます。
┌－（入庫ＴＲＸ）――┐
ＡＰ―（品残更新ＴＲＸ）＋→ＤＢＭＳ－ＤＢ
└―（掛残更新ＴＲＸ）┘
すなわち、実世界では１件のイベントが発生し、ユーザは１件の入力をしただけですが、
ＡＰは整合性を保障するために、３件のＴＲＸを発生させ、これをＤＢＭＳに依頼して
いるわけです。これではＤＢＭＳは、ただ指定された場所にデータを入れているだけで、
「ＤＢを管理するシステム」とは言えないのではないでしょうか。
■ｉＤＢＭＳの登場
そこでｉＤＢＭＳ（intelligent DBMS）が登場するわけです。すなわち、次のようにＤＩ
の整合性管理をｉＤＢＭＳが引受けます。
┌－（入庫ＴＲＸ）――┐
ＡＰ―（入庫ＴＲＸ）→ｉＤＢＭＳ―＋―（品残更新ＴＲＸ）＋→ＤＢＭＳ－DB
└―（掛残更新ＴＲＸ）┘
こうして、ｉＤＢＭＳ＋ＤＢＭＳが本来のＤＢＭＳの役割を果たすと考えるわけです。
このために、ｉＤＢＭＳは次のようなリポジトリ情報を活用し、
［加工データ．加工元データ］－（参照ＫＥＹ）
部品残高 入庫数 品．倉
掛残高 入庫金額 取引先．区分
「入庫数、入庫金額が加工元データであり、対応する加工データが［品．倉］エンティ
ティの部品残高、および［取引先．区分］の入庫金額であること」を突き止め、加工
データ対応に記述された加工ロジック（ここでは省略）を参照して、部品残高＝１００＋５、
および入庫金額＝２００＋５０を計算し、ＤＢＭＳに更新依頼することになります（注１)。
（注１）部品残高および掛残高は、生産システムや経理システムからもアクセスされる
ため、アプリ横断のＤＢ中にストアされるべきとも考えられますが、これはリポジトリ
情報から判断できますので、ｉＤＢＭＳによる対応は可能と考えます。
入力データの値や形式の制約チェックも、ｉＤＢＭＳに任せることができますから、ＡＰ
の仕事は、実世界に発生した情報を素直にコンピュータの世界で扱えるデータに変換して、
ｉＤＢＭＳに渡すだけになります。整合性にかかわる配慮は不要になりますので、ＡＰは
ユーザ・サービスに徹することができます。
従来は、ＡＰ開発担当者とＤＢ設計担当者が分業していても、ＡＰ担当者もＤＩの絡む
データ間の複雑な関係－特にサブタイプが絡むとき複雑で抜けも発生しやすい－を認識しな
ければならず、両者の認識が違っていたり、抜けが発生して、トラブルの発生する危険性が
高かったのですが、きれいに分業ができ（注２）、ドキュメントが単純化されます。データ
の設計は、ＤＩを含めて、データモデラーが実装独立に、先行して完結することができます
ので、実装工程からのやり直し依頼はなくなり、開発・保守ともに大幅に合理化されると期
待されます。
（注２）最近、ＤＢの整合性を保障すべく、ＤＢＭＳは各種ストアードプロセジャー機能を
充実させてきていますが、「データモデラーが実装独立段階に設計すべし」という設計思想
ではなく、プログラマを支援するもののように思われます。
ＤＩにおいては、①加工元データを加工データの所属するエンティティに集め、②これを演
算するわけですが、②の非定型処理ステートメント以外にはプログラム言語による記述は
（ｉＤＢＭＳが肩代わりするため）不要なので、ＡＰ側以外にはプログラミングは不要にな
ると期待されます。すなわち、オブジェクト指向言語なしで、その狙いをカバーするものに
なるのではないかと思われるのですがいかがでしょう。またＡＰ側も、一覧表型、ヘッダー
ディテール型、マトリックス型、個票型、など画面・帳票のパターンを用意することによって、
大幅にプログラミング工数を削減することができると考えます。
■課題
この場合心配は、次のようなものかと思われます。
①すべてのＤＩを受け止めるリポジトリ構造が設計できるか
②これを活用する、十分な効率を持つ、ｉＤＢＭＳが設計できるか
③データモデラーが、リポジトリに登録すべき高品質のデータを効率よく作れるか
もちろん、世の中のすべての加工データについて検証したわけではありませんが、筆者は①は、
ほぼ完成に近いものが設計できている、ただし、②における機械効率のための工夫がリポジトリ
構造にも必要と考えますので、この課題が若干残されているかと考えます。ＤＩはビジネスルール
／業務知識の中核であり、これは「プログラムで書くもの」との先入観を持っておられる方もある
ようですが、私はメタデータとしてリポジトリに記述すべきもの、これによって実装独立段階の
仕事にできる、と考えています。
②は、これから実証すべきテーマですが、１個のプログラムが対象であり、多少の試行錯誤はある
でしょうが、必ず解決できる課題と考えます（注３）。
③は、これまでＳＥをやっていた、多くの新参データモデラーにとって未経験の部分を含んでい
ますので、設計手順や教育など、まだ課題が残されているかと思われます。しかし、プログラミ
ングのような個人差が発生しませんので、さほど難題ではないと思われます。
また、当面ｉＤＢＭＳが用意できなくても、ＡＰのロジックからｉＤＢＭＳ部分を分割し、この
設計をデータモデラーの担当とすることによって、大幅な合理化が達成できると考えます。
（注３）方式としては、事前にプログラムを自動生成しこれをｉＤＢＭＳから呼び出すプログラム
ジェネレータ方式（コンパイル方式とも呼ぶ）と、実行時リポジトリを解析して動くインタープリ
ーター方式があるかと思われます。技術的には前者が易しいと思われます。
なお、科学技術計算などの加工データ－たとえば流体の流量対応のパイプ径、地震に耐える鉄骨寸法、
流体の温度・圧力での蒸気圧など－は、自動生成でなく従来どおりのプログラミングを行い、
ｉＤＢＭＳから加工ロジックとして呼び出すのが適切かと思われます。
« 【153号】 ＩＰＦチャートの設計条件【155号】 ＤＢ通信場再考 »
