» 【155号】 DB通信場再考

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

■DB通信場
いま広域統合のためのSOA(Service Oriented Architecture)が話題になって
います。しかしサービスと言う言葉の持つ意味の広さや、各人の立場・背景からく
る、この言葉についての意味づけの違いから噛み合った議論が難しくなっています。
筆者もその一人に過ぎませんが、DOAの延長線上に位置づけたSOAを考えて
います。そのアーキテクチャを構成する主役は3階層の通信場-P2P(Program
to Program)、A2A(Application to Application)、B2B(Business to
Business)-です。「通信場」といっても、この生硬な用語の意味は、十分共有
できない心配があります。そこでまず、P2PにおけるDB通信場を手がかりにその
意味を再考したいと考えました。

DBおよびこれを制御するDBMSは1970年代に登場しました。それまではア
プリケーションプログラムはQSAMやBSAMと呼ばれるファイルに書き出し、
これを読むことによって通信を行っていました。いわゆるバケツリレーです。一般
に下流のプログラムは、上流のプログラムの決めたファイル形式にしたがってこれ
を読むことになりましたから、上流のプログラムがファイル形式を変更したときは、
下流プログラムはこれに合せた変更をしなければなりません。下流プログラムの
都合を取り入れたとしても、インターフェースについての約束事は2者間のローカ
ルマターに過ぎません。プログラムがn個あるとすると、そのインターフェースの
数は理論的には、n(n-1)/2になりますので、Peer to Peerのいわゆるスパ
ゲッティ構造となり、メンテが難しくなります。DBMSが登場しても当初は、
ヘッダー・ディテール構造や部品展開が表現でき、また論理インターフェースを活
用し、項目追加の容易な便利なアクセスメソッドとして使われるだけで、スパゲッ
ティ構造はそのまま残されました。

しかし実装独立のデータモデル論が登場し、RDBMSが実用化されて、「DBは
実務の世界の写像である」とする実装独立のDB通信場の考え方が普及してい
きました。リレーショナルモデルの提唱者E. F. Coddは「プログラムは、他のプログラ
ムとは独立に、DBにアクセスすべきだ」というデータ独立性の主張をしました。
こうしてDBを、一種の伝言板、ハブ通信場とする、Hub & Spokeのアーキテクチャ
ができていきました。実際筆者は、「DBとはストレージ機能より通信場機能が本質」
ではないかと考えます。

DBがハブ通信場として機能する条件は、構成するデータ―属性の形式と値-
の標準化です。このためには原則として関わる全メッセージを素材に、データモデ
リングを行い、標準化・整合化を行います。その結果はリポジトリ(メタデータDB)
およびリソースDBに記述されます。またプログラムは、実務の世界の変化-受注
や生産完成など-を可及的速やかに把握しこれを反映する更新系と、実務の
世界を参照し適切なアクション-発注や生産指図など-につなげるための、意思
決定元データを参照する参照系との2種類に分かれます。こうしてDB通信場が
介在するために、留守電やインターネットメールのように、プログラムPiとプログラムPj
が直接交信することがなくなりますが、同時にPiの記述した内容は、Pkも参照
できることになります。

このようにデータが通信場に「鎮座」し、これにアクセスすることによって通信が
実現すると考えるのがDOAの発想であり、逆にプロセスは「鎮座」し、データが
流れることによって通信が実現すると考えるのがPOAの発想と言えます。データ
は標準化によって1個のハブにまとめられますが、プロセスはn個のままですから、
POAでは脱スパゲッティができません。「通信においてはデータが流れる」と考
えるのは、POAや実装従属の発想から脱しきれないとろから来るもののように
思われます。

■孤島システム/SILOの出現
DBによるハブ通信場にはしかし、守備範囲が存在します。生産関係のメッセージ
から作れば生産DBが、また販売関係のメッセージから作れば販売DBが作られま
す。「これでは困る」と両者のメッセージを集めれば生産&販売DBができますが、
生産技術者と営業マンは異なった文化を持っており、お互いの用語を理解し標準
化を進めるデータ管理者は容易には見当たらず、時間も掛かります。開発の動機や
スポンサーが異なるという理由もあるわけですが、分野統合のDB構築は必ずしも
得策でないことから、これまで一部の例外を除き行われてきませんでした。その例
外はERPです。パッケージにして沢山売ればコストと時間が回収できるという計算
から行われたわけです。

こうして多くの企業で、個別アプリケーションDBが作られてきたわけですが、アプ
リケーション間のコミュニケーション不全の、いわゆる孤島システム/SILOと呼
ばれる、次の二つの大きな問題、

①アプリごとに社内外組織や製商品・部品などのリソースデータの定義が異なる
②アプリ間でやり取りするデータの所在はどこにすべきか基準がないが残されました。

生産指図、完成、受注、出荷などのイベントを文章表現したとき、担当者、顧客、
商品などのリソースデータは用語に相当します。①はこの用語がアプリケーションごと
に異なると言うことです。また、たとえ用語が異ならなくても2重管理になりコストの
点でマイナスですし、他のアプリケーションのリソースを参照することになれば、RPC
(Remote Procedure Call)やWebサービスを多用したスパゲッティ構造を招くことに
なります。いま話題になっているMDM(Master Data Management)の問題となる
わけですが、根本は本来全社的に管理すべきものを個別アプリケーションに任せた
結果と言えます。

②は、たとえば製品残高のようなデータの問題です。これは生産システムの生産
完成でプラスされ、販売・物流システムの出荷でマイナスされるアプリ横断のデータ
ですが、どこに所在すべきかはっきりした基準を持たないため、2箇所にストアしたりし
ている企業も少なくないように見受けられます。これも全社レベルで管理すべきもの
を個別アプリケーションに任せた結果であり、スパゲッティ構造を招き、メンテを難しく
します。また、証券業務における約定残高なども、フロントとバックで共用されますが、
よく似た問題を抱えています。

■3階層ハブアーキテクチャ
そこで、EDIなどの社外への拡張をも配慮して、データに次のようなレベル付け
L1:個別アプリケーション内でだけ使われるP2Pデータ
L2:アプリケーション横断/全社レベルで使われるA2Aデータ
L3:企業横断で使われるB2Bデータ
をします。すると上述は、筆者の提案する3階層ハブアーキテクチャの原則
・独自の文化を持つ個別アプリは、迅速対応・コストなどの観点からL1のDBを
中心に作る(注1)。
・アプリ横断のデータはL2のハブ所属として管理する。
・企業横断のデータはL3のハブ所属として管理する。
のように、まとめられると考えます。

(注1)L1とL2、L3の記述が違いますが、L1の場合はハブをさらにDBと
限定しても問題がないと考えたためで、すべてハブ通信場であることに変わりはあ
りません。

この場合リソースデータは、L1は特にローカルなものに限られるので、ほとんどL2
として管理すべきと考えます。実際われわれは1980年以降のプロジェクトでは「リ
ソースは全社にひとつ」を原則としてコンサルを行ってきましたが、これを採用いただ
いた会社では、以後スムーズなシステム開発が展開でき大成功だったと考えます。
また実例はこれからかと思われますが、使用頻度の低い部品仕様などは、L3-
実データは部品メーカにストアされているが仮想化してL3で公開する-として参照
できるのが理想的だと考えます。この方式のポイントは、物理記憶ではなく、部品
仕様の形式と値の標準をL3で規定することです。

イベントデータの多くはL1となりますが、アプリ横断の在庫データ-先の製品在庫や
買掛・売掛残高など-はL2、また企業横断の在庫データ-ホテルや飛行機の座席
など-はL3として位置づけられると思います。在庫データはアプリAがプラスし、
アプリBがマイナスするわけですが、これは需要が予測できる場合のアプリ間に見られる
「在庫引当型コミュニケーション」の形式だと考えられます。需要が予測できない場合は、
発注に対して、回答、納入、検収が続くような、「要求・回答型コミュニケーション」
が行われますが、これもL2、L3レベルに見ることができます。

またイベント系の一種に、L2データとして、多部門に関わる全社計画・実績データが
あります。たとえば月次販売計画数量・金額ですと、月次製品生産計画、月次資材
購入計画との整合関係が存在するため、これは購買、生産、販売、経理に関わる部門
横断のデータとして扱われ、L2の管轄となります。

■ハイリターンの期待されるL2・L3通信場の可視化
L1を構成するデータの属性は、アプリの個性を反映して、多様かつ変化も激しいので
すが、L2やL3を構成するデータの属性は、たとえば生産アプリと販売アプリ間でやり
取りされるメッセージを考えても分かると思いますが、数も限られかつ安定しています。
現在は多くの企業や企業間において、個別アプリの観点から設計されたL1のデータ
モデルはあるとしても、L2、L3におけるデータモデリングは未着手と思われます。
このためアプリ間インターフェースはちぐはぐであり、ある変更が当該システム内で収まる
か、他に波及するかの判定にすら、多大のコストと時間を投入せざるを得なかったりします。

L1の各アプリの範囲を如何に設定すべきかは、決め事であり難題ですが、これを
決めればL2、L3のデータモデリングは、アプリ間のメッセージを収集すれば可能
であり、技術的に難しい問題はありません。L2、L3のプロセスモデル図およびデータ
モデル図は、経営とITが会話するための必須のドキュメントとなるのでないかと筆者は
予測します。これらは、日本の交通問題を、高速道路と新幹線が解決したのと同様
の役割を果たすことができるのではないかと期待されます。

以上ハブ通信場を3階層に分けるフェデレーション・アーキテクチャにより、孤島/S
ILO問題を解決する提案をいたしました。L2、L3の通信場を構成するメッセージ
は、サービスと呼べるものかと思われますので、以上はDOAの拡張「DOA的SOA」
と呼ぶことができるかと思われます。