» 【第26号】DOAにおける処理の扱い

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【第26号】DOAにおける処理の扱い

DRI通信26号 「DOAにおける処理の扱い」   1998.11.1
変調の秋、重苦しい景気ですが、皆様いかがですか。10月10、11日と南
アルプス、北沢峠方面に出かけましたがまるで夏、天気は絶好でしたが、さえ
ない紅葉が仙水峠付近で見られただけでした。山小屋も予約なしでは泊めない
といわれて早川尾根小屋にのがれ、アサヨ峰(2799m)に登り、帰りは中
央道53キロの渋滞に耐え帰宅しました。山も変わったなと思いましたが、前
回からは40年も経っていました。
前号では「概念DBによるコミュニケーション」を書きましたが、運用を専門
にするコンサルタントの方から「データ管理の杜撰さには驚くばかり、・・・
日本発の世界的ソフトを出すには今までのシステム担当者向けのリポジトリで
なく、ユーザ向けの業務リテラシーに基づく業務リポジトリを検討すべき」と
いうコメントを頂きました。


■I、P、Oを分ける
さて今月は、18号でも触れておりますので、ややくどいかもしれませんが、
DOAにおける処理の扱いについてもう一度考えて見ることにします。23号で
述べたように、われわれの指向するDOAにおいては、共用DBを介して入力処理
(I)、出力処理(O)、加工処理(P)が、次のように別の機能として分かれま
す。
I :実務の世界で発生した意味のあるデータ(原料)をDBに反映する
O:DBのデータを編集してビジネスニーズをみたす情報(製品)を作る
P:DB内のデータを加工して加工データ(中間原料)を作る
トリガと担当もそれぞれ異なります。I はデータの発生がトリガになっており、
品質を確保するために一般に専任者が当ります。Oはニーズがトリガになって
いて、一般に情報レベルのユーザは「出荷係」など特定できる場合もあります
が、データレベルではそのユーザは意思決定者が含まれますので特定できない
という特徴を持っています。Pを実行するトリガは、「加工元データが揃った」
、「加工データを要求された」、「月末など所定のとき」などの3種に分かれ
ます。Pはリポジトリの規定に従い、サーバーが加工データ・加工元データの
整合性管理として行います。したがって基本的にPOAのようにIPOを同時に
扱う姿勢はありません。
■処理も概念レベルで
またユーザは概念ファイルのみを意識し、物理ファイルは意識しませんから、
その処理仕様規定においても処理効率を考えません。処理効率は概念物理変換
においてオプティマイザーが解決すべきものと考えます。
DOAではまずI、O、Pで作る対象(成果物)を次のように特定します。
I :入力する1単位の概念(エンティティ)レコードまたはその一部
O:出力する1単位の主概念レコード
P:加工する1個の加工データ
分かりやすさのため、O、P、Iの順に説明します。
■O
出力においては、画面定義をすればプログラムを書く必要がないことは、多く
のツールによって実証されています。主概念レコードとはいま第一正規型のレ
コードと考えておいてください。ここでは加工データもすでに用意されている
(物理ファイルにあらかじめストアされていなくても加工処理プログラムを起
動しあらかじめストアされていたかのように見せかける)ので、単純な出力画
面・帳票定義が実質的に出力処理定義となります。
プログラムジェネレータ方式でオブジェクトプログラムが作られるか、レポー
トライタ方式で何もつくられないかの差はいま問題にしないことにします。ま
た実際にはこだわりのユーザのために手作りのCOBOLプログラムが必要にな
るかもしれませんが、その割合は数%に過ぎないでしょう。
■P
「受注金額=受注数量*受注単価」の記述はプログラムでしょうか、データ定
義でしょうか。われわれはこれを受注金額のデータ定義と考えることにします。
受注単価が品番ファイル[品番]ー(単価)から受注品番経由JOINされたもの
であるときは、「受注単価=JOIN(単価;受注品番)」のように書くものとし
ます(ここに;はJOINに用いるRKEYが続くことをしめす)。この記述はプロ
グラムでしょうか、データ定義でしょうか。これもデータ定義と考えられそう
です。では先の式に代入した「受注金額=受注数量*JOIN(単価;受注品番)」
はいかがでしょうか。ちょっとプログラムっぽくなります。
また「受注合計金額=TOTAL(受注金額;受注番号)」として受注明細の受注
金額を足し上げることができます。
はじめの「受注金額=受注数量*受注単価」については、この算式を解析する
汎用プログラムを用意するか、JUCHKNGKのような受注金額固有のロジック
を用意する必要があります。JOIN、TOTALのような処理は汎用プログラムで
対応することができます。
したがって、このような記述が、分かりやすさ、また機械処理しやすさの点で
得策かどうかは別として、(受注金額固有のロジックを用意するときを除けば)
理論的に加工処理Pをデータ定義で済ませ、アプリごとにプログラムを作らな
くてよいことが分かります。また受注単価のような適切な中間加工データを選
べば十分実用になりそうな期待も持てます。
■I
入力処理を概念レベルで考えるときはちょっと注意が必要です。顧客と受注を
同一画面で登録したり、受注品番とこれに冗長な品名が同時に登録されている
かに見える画面を見慣れているからです。顧客のようなリソースは事前に登録
されていてはじめて受注のようなイベントの登録が行われるものとします。す
なわちリソースとイベントは分けて扱います。受注品番はユーザが意識して入
力するデータですが、品名はDBAが効率を考えて物理ファイルに冗長に持たせ
るものでユーザ要件ではありません。
入力は原則として、1個の概念レコードごとに同じタイミングに発生したデー
タをまとめて処理するものと考えます(変更や削除は同様に考えられるので省
略)。これで入力の目的は達成できますが、入力にはメニュウ支援やデコード
表示、エラーチェックなど入力担当者への便宜の提供、さらに出荷に基づく在
庫更新、在庫引当、自動発注、メッセージ出力のような整合性のための連動処
理があり複雑です。
しかし入力担当者への便宜の提供には、これをいくつかのパターンに整理し、
入力データごとに指定する方式をとれば、事前に汎用プログラムを用意す
ることによって都度のプログラムを作らずにすませることができます。また連
動処理は汎用プログラムが加工・加工元データの関連に関する記述を解析する
ことによって対処できます。
■業務知識の完全なデータ化
以上がわれわれのDOAにおける処理の扱い、処理仕様のデータ記述化の骨子
です。いまの業務アプリケーションプログラムは、DOAといっても第一世代で
RDBを前提にするという程度、まだかなり業務知識を抱え込み、これと手順を
渾然一体として扱っているのが普通です。サブタイプを正確に扱うことにより
業務知識を完全にデータとしてリポジトリに記述することができます。これに
よるプログラムレス−−THeEngineの開発−−が今後の課題と考えます。
これが実現できれば、ERPも第一世代のプログラムプレハブから、第二世代の
データプレハブ(ERP2)に進化し、自由なカスタマイズが可能になるでしょ
う。そのとき業務アプリケーションとしてのプログラムは無くなりますので、
OOA適用の場は、これを支えるプラットフォームの汎用プログラムになるもの
と思われますがいかがでしょうか。