» 【154号】 iDBMSの勧め

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【154号】 iDBMSの勧め

■DI対策
先々号で「現行DBMSの欠陥」を述べましたが、今回はその
「③DI(Derivation Integrity:加工データ整合性)の抜け」に対する対策を
考察します。

分かりやすさのため、部品入庫により部品残高および買掛残高が増える事例を考えます。
すなわち、いま

[入庫#]-(品、倉、入庫数、入庫金額、取引先、区分)
  5      P W  5    ¥50    S   買

のレコードが発生したとします。これによって次のように、部品残高および掛残高は
s1からs2に変化します。

[品.倉]-(部品残高)   [取引先.区分]―(掛残高)
s1: P W    100         S   買     ¥200
s2: P W    105        S   買     ¥250

この場合、従来法ではDBMSに向けて、アプリケーションプログラム(AP)から、
次のように3つの更新トランザクション(TRX)が発行されるものと思われます。

 ┌-(入庫TRX)――┐ 
AP―(品残更新TRX)+→DBMS-DB
 └―(掛残更新TRX)┘

すなわち、実世界では1件のイベントが発生し、ユーザは1件の入力をしただけですが、
APは整合性を保障するために、3件のTRXを発生させ、これをDBMSに依頼して
いるわけです。これではDBMSは、ただ指定された場所にデータを入れているだけで、
「DBを管理するシステム」とは言えないのではないでしょうか。

■iDBMSの登場
そこでiDBMS(intelligent DBMS)が登場するわけです。すなわち、次のようにDI
の整合性管理をiDBMSが引受けます。
 
                   ┌-(入庫TRX)――┐ 
AP―(入庫TRX)→iDBMS―+―(品残更新TRX)+→DBMS-DB
                   └―(掛残更新TRX)┘

こうして、iDBMS+DBMSが本来のDBMSの役割を果たすと考えるわけです。
このために、iDBMSは次のようなリポジトリ情報を活用し、

[加工データ.加工元データ]-(参照KEY)
  部品残高 入庫数      品.倉
  掛残高  入庫金額     取引先.区分

「入庫数、入庫金額が加工元データであり、対応する加工データが[品.倉]エンティ
ティの部品残高、および[取引先.区分]の入庫金額であること」を突き止め、加工
データ対応に記述された加工ロジック(ここでは省略)を参照して、部品残高=100+5、
および入庫金額=200+50を計算し、DBMSに更新依頼することになります(注1)。

(注1)部品残高および掛残高は、生産システムや経理システムからもアクセスされる
ため、アプリ横断のDB中にストアされるべきとも考えられますが、これはリポジトリ
情報から判断できますので、iDBMSによる対応は可能と考えます。

入力データの値や形式の制約チェックも、iDBMSに任せることができますから、AP
の仕事は、実世界に発生した情報を素直にコンピュータの世界で扱えるデータに変換して、
iDBMSに渡すだけになります。整合性にかかわる配慮は不要になりますので、APは
ユーザ・サービスに徹することができます。

従来は、AP開発担当者とDB設計担当者が分業していても、AP担当者もDIの絡む
データ間の複雑な関係-特にサブタイプが絡むとき複雑で抜けも発生しやすい-を認識しな
ければならず、両者の認識が違っていたり、抜けが発生して、トラブルの発生する危険性が
高かったのですが、きれいに分業ができ(注2)、ドキュメントが単純化されます。データ
の設計は、DIを含めて、データモデラーが実装独立に、先行して完結することができます
ので、実装工程からのやり直し依頼はなくなり、開発・保守ともに大幅に合理化されると期
待されます。

(注2)最近、DBの整合性を保障すべく、DBMSは各種ストアードプロセジャー機能を
充実させてきていますが、「データモデラーが実装独立段階に設計すべし」という設計思想
ではなく、プログラマを支援するもののように思われます。

DIにおいては、①加工元データを加工データの所属するエンティティに集め、②これを演
算するわけですが、②の非定型処理ステートメント以外にはプログラム言語による記述は
(iDBMSが肩代わりするため)不要なので、AP側以外にはプログラミングは不要にな
ると期待されます。すなわち、オブジェクト指向言語なしで、その狙いをカバーするものに
なるのではないかと思われるのですがいかがでしょう。またAP側も、一覧表型、ヘッダー
ディテール型、マトリックス型、個票型、など画面・帳票のパターンを用意することによって、
大幅にプログラミング工数を削減することができると考えます。

■課題
この場合心配は、次のようなものかと思われます。
①すべてのDIを受け止めるリポジトリ構造が設計できるか 
②これを活用する、十分な効率を持つ、iDBMSが設計できるか
③データモデラーが、リポジトリに登録すべき高品質のデータを効率よく作れるか

もちろん、世の中のすべての加工データについて検証したわけではありませんが、筆者は①は、
ほぼ完成に近いものが設計できている、ただし、②における機械効率のための工夫がリポジトリ
構造にも必要と考えますので、この課題が若干残されているかと考えます。DIはビジネスルール
/業務知識の中核であり、これは「プログラムで書くもの」との先入観を持っておられる方もある
ようですが、私はメタデータとしてリポジトリに記述すべきもの、これによって実装独立段階の
仕事にできる、と考えています。

②は、これから実証すべきテーマですが、1個のプログラムが対象であり、多少の試行錯誤はある
でしょうが、必ず解決できる課題と考えます(注3)。

③は、これまでSEをやっていた、多くの新参データモデラーにとって未経験の部分を含んでい
ますので、設計手順や教育など、まだ課題が残されているかと思われます。しかし、プログラミ
ングのような個人差が発生しませんので、さほど難題ではないと思われます。

また、当面iDBMSが用意できなくても、APのロジックからiDBMS部分を分割し、この
設計をデータモデラーの担当とすることによって、大幅な合理化が達成できると考えます。

(注3)方式としては、事前にプログラムを自動生成しこれをiDBMSから呼び出すプログラム
ジェネレータ方式(コンパイル方式とも呼ぶ)と、実行時リポジトリを解析して動くインタープリ
ーター方式があるかと思われます。技術的には前者が易しいと思われます。

なお、科学技術計算などの加工データ-たとえば流体の流量対応のパイプ径、地震に耐える鉄骨寸法、
流体の温度・圧力での蒸気圧など-は、自動生成でなく従来どおりのプログラミングを行い、
iDBMSから加工ロジックとして呼び出すのが適切かと思われます。