» 【第76号】データベース通信場

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

DRI通信76号「データベース通信場」        2003.1.6
あけましておめでとうございます。
2002年は北朝鮮、イラク、不況と不穏のうちに過ぎていきましたが、今年はどんな年となるのでしょう。田中秀征元経企庁長官によると、このデフレは東西経済圏の統合から来るもので、「質実国家」を目指さなければならない、との指摘があります。となれば、情報問題も短期的な先送りでなく、問題の本質を見極めた、抜本的な対策が必須となってくることかと思われます。健康に留意して、厳しさの予想される2003年、強い情報システムを目指して、元気に立ち向かって行きましょう。
データベース(DB)は、今ではリレーショナル(RDB)が主流ですが、初めはTOTAL、IMSなどを用いた構造型DBでした。フラットファイルでは扱えない受注―受注明細や部品表(BOM)といったデータ構造が扱えるということで普及していきました。そのDBは、そのアプリケーション専属のデータの入れ物であって、複数アプリケーションによるデータの共用のためという発想は、まだほとんどありませんでした。


プログラマやプログラマ上がりのSEは、地球を中心に置く天動説派と同様、自分のプログラムを宇宙の中心に置いて考えますから、DBを使っていても他システムへのやりとりには、トランザクションファイルを作って、これを経由してやろうと考えました。マルチタスクをサポートするRDBMSが登場しても、このプログラム/プロセス中心の発想は健在でした。
DBが専用ファイルでなく、n個のアプリケーションからアクセスされる独立した存在になると、そのDBはn個のアプリケーションのコミュニケーションの場になります。電子伝言板と言ってよいでしょうか、プル型の非同期通信が可能になります。私はDBについて、データの記憶機能というよりも、この通信機能の方が重要なのではないかと思っています。1973年ころ私がデータモデリングを始めたのも、プラントエンジニアリングのデータを上流から中流、下流へと伝えるためでした。インターネットによる通信は革命的ですが、これを裏で支えているのはやはりDBであると考えられます。
アプリケーション間でやり取りされるデータは、イベントデータ、いわゆるトランザクションデータです。これをCSV形式で書くと、たとえば、
  104,S57,P25,10,20030110,20030113;
のようになります。これでは理解できませんね。「S57=キリン」、「P25=一番絞り」とコードに意味を対応させると、少し分かってきますが、まだ理解できません。イベントデータの形式をメタデータ/データ項目によって(THモデル形式ですが)
  [発注#]‐(サプライヤー#、商品c、ケース数、発注日、納期)
と規定すると、「発注#=104によって、キリンに一番絞りを、10ケース、納期2003年1月13日として2003年1月10日発注した」と自然言語化でき、すべてがはっきりしてきます(ただしここでは物理データタイプは考慮外とします)。
われわれは、コードはリソースDBに、またメタデータはリポジトリにストアするものとしておりますので、「イベントデータ+R(Repository注1)&R(Resource)によって意味が確定する」と考えます。また、リソースデータは一元化のため分離独立させるべきとすると、アプリケーションDBの内容は、イベントデータとなりますから、「アプリケーションDB+R&Rによってアプリケーションが完結する」とも言うことができます。
<注1>Repositoryはここでは実装独立の概念リポジトリを考えていますので、RDBによるRepositoryの実装は一つの選択肢に過ぎません。OOのカプセル化はメタの分散的実装形態の一つと考えます。</注1>
R&Rは、イベントデータに比べて安定していますから、通信するアプリケーションAとBは、同じR&Rを固定し、これを前提として、イベントデータだけをやり取りすることができます。これは通信を、回線を介してやろうが、DBを介してやろうが変わりません。したがって、R&Rをデータインフラと呼んで差し支えないと考えます。なおXMLを使うときはメタデータをイベントデータに混在させたように見えますが、CSVに比して物理レコードの順序に自由度を持たせただけで、メタデータの意味を、AとBとで事前に協定しておくことに変わりはありません。
別企業で、文化が違うと、R&Rが異なり、日本語と英語で話し合うように、そのままではコミュニケーションができません。変換が必要になりますが、リソースすなわちコードの変換テーブルが、和英ないし英和辞書に相当します。また、メタデータの変換テーブルは、文法の違い−「てにおは」と語順−を解決するものと言えます。なお、同じ企業でも、特に大企業では、生産と営業などで文化が異なり、R&Rの変換テーブルが必要になる場合が多々あります。
一般に一つの企業のなかに、n個のDBが存在します。かつては誰がいつスポンサーになったかによって、その大きさ・範囲が決められたこともあったかと思われますが、一般には営業、生産、経理、人事などの業務、また家電、重電、半導体など事業部/カンパニーごとにDBが作られます(注2)。またリソースDB、DWH、リポジトリ、なども独立したDBとなります。私は、これは「独立性の高い運用を実現するために、更新タイミング−常時、日次、年次−や更新ユーザの違い、といった更新特性によって分割される」ための必然と考えています。企業全体のような大きなシステムは、独立性の高いサブシステムが協調して動ける、自律・協調によるAgilityが必要と考えるからです。
<注2>ERPの場合は、ケースバイケースになるでしょう。会計だけとか人事だけといった単一機能の導入の場合は、上記と変わりません。真のビッグバンでほかに何もない場合は別途考えなければならないかと思いますが、レガシーやDWH、CRM、SCMなどが別途残る場合は、ERPをやはりひとつの大型のDBシステムとして扱うべきかと思います。</注2>
このため、同じDBにアクセスするアプリケーション間のコミュニケーションは、これを通信場とすることによって自由に行われますが、DBをまたがったコミュニケーション−たとえば営業から生産に渡される生産依頼のデータや、営業から経理に渡される売上データなど−はどうすればよいのでしょうか。多くの場合、Point-to-Pointでイベントデータを直接送り込んでいるようです。共通コードが使われ、Pointが少なく、また変更が少ないうちはよいのですが、そうでないとプログラミングのかなりの部分が、インターフェース調整のためのものとなり、無用なトラブルや保守発生の原因となってしまいます。
そこでハブによる通信を実現するEAIツールが登場してくるわけですが、大切なのはやはりDB通信場の考え方でしょう。昔と違って1本のプログラムでなく、DBを抱えた大型のシステムですが、やはりプロセス−いわばスーパープロセス−ですから、このレベルにおいても、通信は、DBという場を経由するのが、健全な姿と考えられます。Point-to-Pointの考え方は、やはり当該システムを宇宙の中心に据える天動説の世界観から来るものと考えられます。これは人間のエゴに基づく自然な世界観かと思われますが、全体最適を考えるとき、一日も早く脱却しなければならないものと思われます。
ではこのようなシステム間を繋ぐDB通信場はどのようなものでしょうか。その内容は当然、システム間をまたがるイベントデータ−メッセージデータとかHigh Level Transactionと呼んでいます−が中心です。これは一般に企業内と企業間と2レベル設定する必要があるようです。いずれにもR&Rが必要で、話題のRosettaNetは企業間のリソースDBとして位置づけられます。このメッセージDBやアーキテクチャについての詳細は、追って別の機会に考察したいと思っています。