» 【第62号】DOAの4レベル

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

DRI通信62号「DOAの4レベル」 2001.11.1
不況の中、晩秋を迎えます。皆様お元気ですか。
現在は、明治維新、敗戦に続く第3の開国期だとのことです。
商品がグローバル最適化で生産・分配され、これを支える情報が
インターネットで飛び交いますが、データセマンティクスが調整できず、
問題が後に残されます。意味論データモデルのさらなる進展と
普及が必要かと思われます。
先月は「データセマンティクス」について考察しましたが、次の3氏から
のコメントを頂いております。紙面の都合から要約して、紹介します。
<細川さん(日本総研)>
・XML等のデータ意味に関する「ボトムアップ」分析に関して、各種
標準の前提として「定義域」を明確に定義し、共有することによって、
「トップダウン」分析・設計も成立するものと思われます。
・XMLを用いたデータ設計を、「データモデルの素人」が実施している
場合があり、個別設計や標準化においてデータの意味を見極めない
恐れが十分にあると思います。これはXMLの「データシンタクス」を
理解していれば、XMLを用いたデータ設計ができるものと勘違いされる
傾向が、背景にあると思います。
・最近、WebServicesというキーワードが注目されるようになってきました。
ebXMLやRosettaNet等もこれらの技術を標準として採用しており、
今後の普及が期待されていますが、今後は技術的な実現性だけでなく、
「データの場」間で正しい「データセマンティクス」が確立される必要性
がますます高まるものと思われます。
</細川さん>


<丸山さん(NTTコムウエア)>
DRI通信61号を興味深く読みました。書かれていることは、実感です。
以下は感想です。今、私には従来のDOAと違う考え方が生まれつつ
あります。それは、自然言語、偏見とデータモデルとの差を捕らえる
技法こそが求められているということです。データモデルは、表現を
できるだけ排除し、純粋にデータでモデル化しようとする試みです。
しかし、そこで整理したデータは、使うときには表現(偏見?)を付けて
人に接するわけです。データ分析のとき、その表現情報をどのような
形でモデル化?(資源化?)すべきか? 悩んでいます。
</丸山さん>
<戸田コンサルタント>
指摘されたポイントは、それぞれの企業やそれに属する個人が無意識
に使用しているデータ項目の相互に集合論的な同一性を保証しないと、
実は正しいデータ内容の交換は出来ないということです。
考えてみれば、しかしそれは極めて難しいことです。互いが無意識に
理解している、データ項目に含まれているもの・含まれないものの
付き合せを、コミュニケーションを行うそれぞれの相手と行う必要がある、
ことを意味するからです。しかし、難しいからといって立往生していては、
相互のデータ内容の定義に差異があるのかを見つけることすらできない
ことも事実です。
問題の核心は、「完全に標準化しないと使えない」と考えるのではなく、
「多少のエラーの発生は覚悟しつつ、このような不都合が発生した場合
は、それを調整するというやり方が取れないか」という点だと思います。
つまり、ある程度の標準化レベルで運用を開始し、動的に差異を発見
した段階で、それを調整していく方法を、どのようにすれば体系の中に
組み込めるかです。
</戸田コンサルタント>
さて今月は「DOAの4レベル」を、58号とやや重複しますが、再度
考察します。
■プロセス中心の部門システムの発達
企業は営業、設計、見積、購買、生産、出荷など部門に分かれ、分業
により業務を遂行しています。その間に情報が授受されますが、その
目的は、生産指図、出荷指図、見積依頼といった「指図」と、生産実績、
POSと言った「計画」のためのものであると言えます。
情報は電話や電子メッセージの場合もありますが、画面・帳票が代表\n的です。この画面・帳票と人が構成するビジネスの世界は、江戸時代
からありましたし今後100年経ても変わらないはずです。ただし他部門
や他社に渡すこれらの情報を、かつては人が作っていましたが、今は
コンピュータが作ります。コンピュータに作らせるためにプログラムが
要る。機械化による省力化をねらってプログラム中心・プロセス中心の
部門システムが発達してきました。
■データ中心アプローチの誕生
しかしそのシステムの成果物、すなわち他部門や他社に渡すべき情報、
を構成するデータ項目の形式や意味に関する調整は、ほとんどの場合
後回しになり、その部門独自の「偏見」を持ったものとなってしまいました。
形式の違いだけなら変換によって解決できますが、意味の違いは厄介
です(DRI通信61号参照)。
そこでプログラムを考える前に部門間に受け渡しされる情報、
インターフェースを先に固定しましょうという、データ先行・データ中心の
アプローチが生まれたわけです。インターフェースの規定さえ守るならば、
プログラム・処理方式は各部門で勝手に変更しても構わない。ビジネス
ニーズの変化、ITの変化の激しい時、このサブシステム独立性は極めて
重要です。
この場合、実用上最も重要な課題は、インターフェースに現れる社内外
組織コード(部署コードや取引先コード)、品目コードや、インターフェース
の種類を決める場合分けのコード(サブタイプコード)など、共用リソース
データの標準化です。標準化は技術の問題であると同時に人の問題、
マネジメントの問題ですから、マネジメントのレベルが問われます。
ERP導入の場合も、これらの共用データは自ら用意しなければなりません
から、逃れることはできません。ERP失敗の多くはマネジメントレベル
未達から来ているように見受けられます。
■意味を追求するDOA
DRIのDOAは、このようなサブシステムの独立性を保証する共用
リソースデータの整備を前提としたDOAです。「偏見」の調整を行うため、
データの意味を追求しますので、加工データ(導出データ)については
加工元データを識別し、その加工過程を、大部分はデータモデル図上
でトレースします。これによって重要なサブタイプが発見されます。
これによりプログラムのIF文対応のロジックが扱う管理対象が見えて
きます。こうしてプログラム設計時になって、データの不備が発見され、
差し戻しになることが防止されます。この加工データ分析は、データ
モデリングの品質保証に極めて有効なものと実感しますが、このとき、
われわれは特定のDBMSを念頭においていません。さらにSQLも
念頭においていませんから、RDBか否かも念頭になく、全く実装独立、
ユーザの世界で思考しています。
■DOAの分類
われわれは「これこそDOAだ」と考えますが、世の中にはもっと別の
DOAがあるようです。そこで初心者に説明するためにこれを分類して
みることにしました。やや独断的かもしれませんが、結局次の4レベル
に分類できると考えました(DFDは論外)。
・レベル1:特定のDBMSのレコード設計を主目的とするもの
・レベル2:レベル1+そのDBMSでのリソースデータの共用を指向
するもの
・レベル3:実装独立にリソースデータの共用を図り、データの広域
流通を指向するもの
・レベル4:不定形加工データを除きプログラムレスを実現するもの
レベル1は、90年代C/S上にRDBMSを活用して作られたアプリ
ケーションの多くに見られます。それは「偏見」の調整の必要のない、
比較的狭い分野のアプリケーションでした。GUIが実用化されCASE
ツールによりER図などが書かれましたが、リソースデータは業務の
データに混在し、共用への配慮は無視された形になっていました。
目的はリレーショナルテーブルの設計であって、プログラムは後で
別途設計すれば良いという発想でした。
レベル2は、基幹系全体を対象とした、レベル1より一回り大型の
アプリケーションでのDOAです。必然的にその中でのリソースデータ
共用が前提となっています。しかしORACLE、DB2、AS/400と
いった同質の環境を前提としたため実装独立はさほど重視されて
いなかったようです。データの流通範囲は広がりましたが、プログラム
を後で別途考える点では、レベル1とあまり変わっていないと言える
でしょう。
レベル3は、われわれが目標としてきた、ヘテロな環境を含めて
データの流通を実現するDOAです。そして加工プロセスをトレース
することによって、データモデリングの中にプログラム設計が吸収
されてしまいました。
レベル4はツールが不可欠なので、これからの課題です。リポジトリ
の仕様に関してはレベル3と同時に検討され、ほぼ決着がついて
います。そして簡単なプログラムレスのプロトタイプはすでにデモ
されていますが、資金調達の問題もあり中断されています。
■事後協調のインターDBでのDOA
なお、レベル3のデータの流通範囲は、一応1企業内あるいは事前
協調の可能な企業群内を想定しておりますが、昨今のB2Bや大企業
における事業部間においては、事後協調のDOAとならざるを得ない
でしょう。レベル3までは、事前協調・整合性管理を考慮したいわば
イントラDB問題としてDOAを適用しますが、ここでは事後協調の
インターDB問題を考えなくてはなりません。それは今XMLが対象と
している、確定したメッセージを扱えば良い世界で、出荷に基づいて
在庫更新をすると言ったOLTP的同期更新処理までは要求されない
世界です。
事後協調においては、完全なデータ流通はあきらめざるを得ないものか
と考えます。ちょうど日本語での「わび・さび」や「よろしくお願いします」
に相当する英語が見つからないようなものです。流通可能なものについて、
変換テーブル−それもなるべくならエスペラント・リポジトリに対する
もの−を作って行く。流通可能な部分を切り出すために、そこでは
サブタイプ分析が主役となるものと考えています。