» 【第18号】第二世代のDOAとして

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【第18号】第二世代のDOAとして

DRI通信 第18号 1998/03/01  ● 椿 正明 mtsubaki@drinet.co.jp
第二世代のDOAとして
さて15、16、17号とデータの品質について、書きましたが、またプログラムの問題に戻します。やはりプログラムをどう位置付けるかの違いから、いろいろなアプローチが生まれているように思われるからです。
DOAといってデータモデルを作っても、物理DBを作った後、昔と同じように属人的に機能を分割し、それ対応のプログラムを書いていることが少なくありません。これを第一世代のDOAと呼ぶならば、第二世代のDOAとは本来プログラムレスを目指すべきものではないでしょうか。誤解しないでください。プログラムが全く要らなくなると言う意味ではありません。「業務独立のプログラム」と「業務を記述したデータ定義」が取って代わるため、「業務対応に作るプログラム」が要らなくなるという意味です。


2Tierクライアントサーバーモデルで考える
簡単な事例で説明することにしましょう。ただしここでは概念レベルで可能性のみを考え効率の善し悪しは議論しないことにします。紙面の制限から一番面倒なクライアント/サーバーモデルにおけるサーバー側の更新系のロジックについてだけ述べます。3TierとかHyper-Tierとかの主張がありますが2Tierで考えます。3TierとかHyper-Tierにこだわるのは、効率が気になって概念と物理が分けられないからのように見えます。ユーザニーズへの対応と共用資源の管理に分ける2Tierが、概念レベルのクライアント/サーバーモデルの原点ではないでしょうか。
クライアントから出荷指図レコードが、サーバーに渡されサーバーはこれをDBに反映するものとします。サーバーには(一応現行の技術レベルの)DBMSがありDBへの格納を行いますが、機能が不十分なためこの上にUSMAIN(Universal server Main といった意味)があるものとします。USMAINはRepositoryを参照して、必要な処理を検出し、これを遂行するプログラムを呼び出して実行するものとします。
したがって、サーバー側のおおまかなアーキテクチャは次のように書けるでしょう。
┌───────┐    ┌─────┐
│Repository    │    │Database │
└───────┘    └─────┘
   ↓               ↑
 USMAIN ─┬──────DBMS
         ├URICHECK
         ├URGCHEC
         ├UINVUPD
         ├
         └───┐
               ├SHUK\CAL
リポジトリ内の仕様
概念DB構造(一部を成るべく簡単に示す)は次のようなものとします。
[取引先#]-(<売掛残>)  [品#]-(<在庫数>)
  ↓↓          ↓
[出荷#]-(客#,届先#,品#,数,日,単価,<出荷\>)
また加工データについては次のような仕様が定義されているものとします。
[加工データ]-(加工ロジック,タイミング)
 出荷\     SHUK\CAL   即時
 在庫数     UINVUPD   即時
 売掛残     UINVUPD   遅時
[加工データ,加工元データ]
 出荷\     数
 出荷\     単価
 在庫数    数
 売掛残    出荷\
なお加工ロジックで、先頭にUのつくものは業務独立(Universal)で、事前に用意できるものを表わすものとします。
また品#については参照整合性のチェック(URICHECKによる)が、数については0個以上100個以内の範囲チェック(URGCHECKによる)が要求さRepository内にデータ項目対応に記述されているものとします。
実行条件
そのとき出荷指図レコードは次のような情報(形式は今ここでの説明のためのものとします)から成るとしましょう。
ADD[Key出荷#=*]-(Atr客#=30,Atr届先#=32,Atr品#=P1,Atr数=10,Atr日=19980228,Atr単価=100)
ここでKey,Atrなどは、メタデータであることを明示するために付加したもの、また*はシステムによる自動発番を示すものとします。
USMAINのロジック
このときUSMAINはどんなロジックになるのでしょうか。説明したいのは業務独立なロジックとして書けるということですから、Pseudo Codeよりもっとくだけて箇条書とします。エラー時の処理などは本質的でないので省略します。もっとエレガントなプログラミングがあるでしょうが、今は気にしないことにします。
(1)送られてきたレコードをバッファーに読み込む
(2)ADD処理ルーチンに飛ぶ
(3)LOCKをかける
(4)Repositoryを参照し、Key出荷#からどのファイルへのADDかが分かるので、出荷#を発行する
(5)Repositoryを参照し、Atr品#は参照整合性チェックが要求されているので、URICHECK(Atr品#,P1)を呼ぶ
(6)Repositoryを参照し、Atr数は範囲チェックが要求されているので、URGCHECK(Atr数,10)を呼ぶ
(7)DML(SQL?)を発行してDBMSにストアを依頼する
(8)Repositoryを参照し、加工元データである、数、出荷\が生成されていることが分かるので、SHUK\CAL(出荷\,数,単価)、UINVUPD(在庫数,数)を同一トランザクション内で呼ぶ
(9)UNLOCKする
(10)UINVUPD(売掛残,出荷\)を次の別トランザクションとして呼ぶ
以上の(1)ー(10)ではSHUK\CALを除いてすべて業務独立のロジックで構成することができました。DELETE、CHANGE、 REFERENCEの場合もほぼ同様に業務独立のロジックで構成することができるはずです。クライアント側のロジックは受け入れたデータを単に送出したり表示したりするだけですからRepositoryの情報さえ入手できれば業務独立になります。
プログラムレスによるメンテナビリティの高いシステム
出荷\は固有の業務データなので、その算出ロジックSHUK\CALはあらかじめ登録しておく必要があります。これをプログラムだと言えばプログラムレスではないということになります。しかしそのボリュームは従来のプログラムの1/10以下となり、またその内容は限りなくデータ定義に近くなります。特にサブタイプ分析をきちんと行い、データ項目のサブタイプ対応の挙動を把握すると、原則としてIFの含まれない単純なデータ定義となりますので、なおさらです。これをデータ定義と考え「プログラムレス」と言ってもさほど不当ではないでしょう。
DOAではまずアウトプットと加工データの仕様がユーザによって決められます。これをデータ分析することによって概念DB構造が決まります。加工データ対応のロジックを用意しておけば、USMAINの制御によって、業務独立のロジックだけで、ユーザの要求する処理が実行できます。データ定義の追加・変更だけでビジネスニーズの変更に対応できる、きわめてメンテナビリティの高いアプリケーションができるというわけです。実際には効率の問題を解決するための妥協などが必要かと思われますが、本質にかかわるほどの問題になるとは考えられません。
「処理」はアウトプットや概念レコード、加工データと言った「成果物」を生み出します。同じ「成果物」を作る「処理」は一般にn個あり、技術進歩により新しい処理が生まれます。したがって業務アプリケーションの世界でこれをあえてカプセル化として、安定なデータと不安定なプログラムを不可分に結合することにどんなメリットがあるのか、私にはまだ理解できていません。どなたかご教示していただけませんでしょうか。
なおDRIではこのようなプログラムレス方式に関するR&Dのスポンサーを探しています。検討されるところはご連絡ください。