» 【第25号】概念DBによるコミュニケーション

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【第25号】概念DBによるコミュニケーション

DRI通信25号「概念DBによるコミュニケーション」1998.10.1
いよいよ10月秋本番を迎えます。このDRI通信も2年続き、3年目に入り
ます。特にスケジュールを立てず、そのときそのときの関心事を書いているの
でまとまりを欠きますが、後で編集する機会もあろうかと今しばらく続けるこ
とにいたします。ROMの方が多いのですが、何かコメントをいただけますと
方向付けができて助かります。
先回は、21世紀の情報システムについて「ビジネスモデルによるアウトソー
シングになりそうだ」というような予測を立てました。反応は少なかったので
すが、「大手金融機関は保守的でアウトソースしない、小さいところはアウト
ソースして酷い目に遭っている、まだきちんとアウトソースできる準備が出来
ていない」という内容のコメントをいただきました。今はそうだと思いますが、
ユーザ企業もSIもそろそろ考えてほしいですね。


■単語の違いは文化圏の違いから
さて今月は業務アプリケーション間のコミュニケーションにおける概念DBの
役割について考えて見ます。まずここで日本語[手]の意味について、次の事
例に基づいて考えて見ましょう。
 左手を怪我した Arm
 手をあわせる  Hand
 手をいれる   Repair
 人手がない   Help
 四十八手    Method
 この手の品物  Type
 手を切る    Relationship
 山の手     Direction
 手がこんでいる Work
元来は手=Handといった一つの意味しか持たなかったものが、抽象化や拡張
などにより多様な意味を持つに至ったものと思われます。その意味は文脈のな
かで解決されますが、その進展は日本語文化圏、英語文化圏で違い、複雑な対
応関係を持つに至りました。モデル的には次のように書けるでしょう。
 日本語:   ←──[あ]──→
 英語 :  ←──A───→←─B───→
([あ]はAに近いがBの意味の場合もある。[あ]の一部はAのサブタイプ
と、また一部はBのサブタイプと一致する)
同じ2本の手を持ち2本脚で歩き、朝起きて3食食べ、夜眠り一夫一婦制の家
庭を持って暮らしていても、文化圏が違うと言葉は違った風に使われるように
なります。
■リソースエンティティは単語に相当
イベント、たとえば[受注]のなかのリソースエンティティ[商品]は、文章
のなかの[手]のような単語に相当します。すなわち文章の中の[手]は
RKEYの位置付けになります。上で見た「手=HAND」と同様に、「商品=PRODUCT」の
対応づけも完全な1:1の対応がとれないのが普通です。この
関係は英語圏とでだけでなく、A社の商品とB社の商品の間にも存在します。
違いは、対象とする商品の種類、品質の表現、部品や中間品を含むか含まない
か、梱包/包装までしてあるのかしてないのか、などいろいろの局面に発生し
ます。同じ会社の中でも事業部によって、リソースエンティティの意味が違う
ことが少なくありません。情報システムごとに異なった文化圏が作られうるか
らです。
このため、たとえば受注イベントのデータ
[受注#]ー(顧客#、商品#、数量、金額、年月日、・・・)
を正しく交換するには、受注の定義ーー社内でのやりとりを含むか、赤伝や返
品も含むか、海外も含むかなどーーを確認すると同時に、顧客#、商品#など
使われているRKEYの意味を確認しなければなりません。一般にはこのRKEY
の意味確定が難題になります。
■概念DBに位置付けて意味確定
とくに規格化されていない商品では、たとえ商品#を発行して見ても、詳細な
仕様に展開してこれを規定しなければなりません。この仕様のなかに各種構成
部品、形状コード、材質コードなど、いろいろなRKEYが使われるので、この
意味確定が難題になります。
結局は対応するリソースエンティティが同じものを表わすように対応付けなけ
ればなりません。すなわちコミュニケーションする文化圏の「リソースに関す
る概念DB構造の統合作業」をすることになります。概念DBに位置付けてはじ
めて、同じ意味のものを表わしているかどうかが明瞭になるからです。
コミュニケーションの相手が1個や2個に限定されるときは、かなり限定され
たRKEYについての調整で間に合わせられるかと思われます。しかし相手が5
個以上にもなると、かなり本格的な概念DB構造の統合作業がむしろ効果的に
なるでしょう。さらにn個、不特定多数になると概念DB構造の統合作業は必須
になるはずです。
■不特定多数のコミュニケーションにはDOA
23号において「DOAでは実務の世界に発生したデータはすべて共用DBに
反映され、ユーザの欲しいデータはすべて共用DBから得られるので、業務
(入力、出力、加工)プログラム同士のメッセージのやり取りは不要である」
と述べました。この共用場による不特定多数のプログラムとのコミュニケーシ
ョンがDOAの特徴ですが、これを企業内のみならず企業外にも適用しようと
いうわけです。
かつては原材料供給、また卸販売にかかわる協力会社は系列化が主流でしたが、
これがくずれ、不特定多数の企業とのダイナミックな関係に変化しつつありま
す。CALSの動きはこれを反映するものと思われますが、「標準化のために、
まず品物に関する概念DB構造を解明しよう」というところまでは踏み切れず、
納得のいく決着を見ていないようです。
■DOAとOOAの違いの本質
ここまで書いてきたら「カプセル化し、手の内(=データ)を公開しないで
メッセージでやりとりするオブジェクト指向」は特定少数のプログラム間の
コミュニケーションを前提としたもののように見えてまいりました。すなわち
 DOA:インターネット方式
 OOA:専用線方式
のようなアナロジーです。DOAとOOAの違いの本質は、コミュニケーション
方式の違いであり、結局なんらかの棲み分けに至ると思われますが、これが一
つのヒントになるかと考えました。皆様どうですか。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
追伸
1985年10月創立ですからDRIも13歳になります。当初は素朴なWPと
OHPを武器としたPLAN-DBの教育を中心としていましたが、いまや1人1台
のPCのGUIが当り前という世の中になりました。そこでテキストやマニュアル
もこれらの武器を用いて一新し、さらにTIS殿のご協力をいただきTHモデルを
前提にしたリポジトリベースのGUIツールPCASEを開発しました。またKBS殿
と共同で、これをベースにプログラムを生成するSapiensと連結して、開発生産
性を大幅にアップする手法DOA-RAD(現PLAN-APL)を開発いたしました。
10月26日14時ー17時、アルカディア市ヶ谷にて、これらをご紹介する
New DRI98を開催いたします。ご案内はPLAN-DBユーザ等各位あて別途郵
送いたしますが、とりあえずお知らせまで。