» 【第61号】データセマンティクス

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

DRI通信61号「データセマンティクス」 2001.10.1
計画未達のまま今期もあっという間に半分が過ぎ、涼しくなってまいりました。
対策のないまま、予告どおり「痛み」だけがやってきて、しかも同時テロとこれ
に続く報復で、この加速が心配されます。
DOAはシステム開発プロジェクトの上流工程というより、データ標準化のため
のインフラプロジェクトとして位置づけるべきとの思いを強くするこの頃ですが、
この地味な基礎造りの上に、本当の進歩・改善があると信じて、その効果的
実現を考えていきたいと思います。皆様のご検討を祈ります。
先月は「決めるもの、決まるもの」としてDBとシステムの大きさを考察しました
が、戸田コンサルタントから、次のような支持をいただきました。
「この趣旨に全く賛成です。昔、銀行時代に「コード設計」という名称で、比較的
固定的に登場するリソースの番号体系を全システム共通で標準として決める
作業を行ないました。それらの成果物は店番号テーブルや商品コードテーブル
などの名称で、システム共通の資源として使用されるものとして管理されること
になりました。
このようなリソースに関するコードの統一を行う意味は、意図するスコープでデ
ータ流通が可能であることを担保することです。そして、このようなコードの統一
を行わずに、単に物理的にシステムを接続しても、意味論的にシステムが接続
可能となったとは言えないからです。


SCMやCRMなど広域のデータ流通が必要なシステムが作成されていますが、
これらのシステムが成立するための必要条件として、リソースDBの独立化・
共通化があることをもっと強調すべきと思います。システム技術が、単なる見よ
う見真似の経験的技能ではなく、きちんとした科学的・合理的裏付けのある技
術であることが極めて重要と痛感しております。」
またTIS堀越さんからも、独断で要約させていただくと
「データの単位は決まるもの、これを繋ぐプロセスの単位は予算との関係で決
めるもの」とのことでした。
さて今月は「データセマンティクス」としてデータ項目の意味について考察しま
しょう。ERP、SCM、CRM、EAI、B2Bなど3文字略語が氾濫していますが、
いずれも情報の広域流通/システムの統合にかかわるものです。小さいシス
テムでは部分最適しか実現できない。より広いスコープでの全体最適をねらっ
てシステムの拡大/情報の広域流通が要請されます。日本人が自動車をア
メリカに売り付け、ノールウエイの鯖やアフリカの蛸を食べ、中国製の洋服を着る
時代です。物が世界を駈巡るように、人も情報も世界を駈巡らざるを得ません。
情報が流通するためには、データの形式ばかりでなく意味が一致しなければな
りません。国が国境を持つように、システムはいわば「シス境」を持っています。
システム内部では形式と意味が協定されていますが、別の領域に対して別の
人が別のタイミングで構築したシステムは、別の形式や別の意味を持っています。
いわゆる「孤島システム」ができています。
「A社の顧客コードは、B社の取引先コードに対応するが、B社では業者もこれに
含めている」と言ったことがあります。「両社とも品目コードと呼んでいるが、一方
は荷姿を含め、他方は外して扱っている」かもしれません。「両社とも品種コード
と呼んでいるが、一方は50種類に、他方は500種類に分類している」ということ
があります。
同じ日本語を使っていても、データ項目の自然言語名だけを手がかりに、データ
の意味を判定することはできません。この辺の認識に欠けた「データモデルの
素人」が、CALSやXMLのタグの標準化などに関わって、混乱の元を作らない
かと心配になります。
データの意味を識別するためには、そのデータ項目が「どのようなエンティティに
おいて、どのような役割を果たしているか」を把握しなければなりません。
たとえばある受注イベント#01091412の中に、取引先コードA123とA125
があったとして、一方が発注者A123、他方が届け先A125とします。この場合、
エンティティは「受注イベント」、役割はA123が「WHO」、A125が「WHERE」
ということになります。
すなわちこのケースでの属性、役割、定義域の関係は次ぎのようになります。
属性 役割 定義域 値
発注者 WHO 取引先 A123
届け先 WHERE 取引先 A125
「データモデリングの素人」のなかには、この「属性」と「定義域」の区別の
できない人がたくさんいますので、注意が必要です。
したがってデータ項目の意味の識別は、次の順序となります。
(1)データ項目の所属するエンティティタイプを識別する
(2)データ項目のそのエンティティタイプにおける役割(WHO、WHAT、
WHERE、WHEN、IN_WHAT_CASEなど)を判定する
同じ業種のM&Aにおけるシステム統合などにおいては、同様のエンティティ
タイプを扱っているにもかかわらず、異なったデータ項目名が多々使われてい
て、これを整理する必要が発生します。このときはデータ項目の役割の判定が
鍵となります。
思ったより難しいのは、エンティティタイプの識別です。食い違いの発生する
要因は次の2つに大別できるように思われます。
(1)対象エンティティの範囲
(2)対象エンティティの粒度
(1)社員といっても、役員、アルバイト、出向者、退職者などを含めるか否か、
取引先として、子会社、協力会社、購入先、流通センターなどが含まれるのか
どうか、品目として、仕掛り品、包材、コンテナ、スペアパーツ、特許、取扱説
明書、触媒、電気・水、トラック、コンピュータ、宿泊、交通・通信、飲食など、
どこまでが含まれるのかなど、会社によって大きく異なります。
またイベントにおいても、たとえば物流を国内のみに限定して扱うか、陸送と
それ以外を別扱いするかなど、会社ごとに規定が異なっています。この規定が
違う時、同じデータ項目と見なしてしまって、果たしてデータ流通が支障なく
行われるのでしょうか。
(2)組織、作業などの集合エンティティや、品種、職種など分類を表すタイプ
リソースは識別管理する粒度(大きさ、レベル)をどう設定するかが問題になり
ます。アプリケーション間、企業間でかならずしも一致しません。データ項目名
がたとえ同じでも、同じとして流通させることができない場合があります。
以上の問題は、似ているもの、すなわち一部同じで一部違うものに発生する
問題です。したがってどこまでが同じでどこからが違うか、すなわちサブタイプ
分析を行って、これを吟味する必要があります。多くの場合、似ているものは
共有サブタイプを持っています。これが明らかになって初めてエンティティタイ
プの意味がはっきりし、そこに従属する属性の異同が分析できます。したが
って「データモデルの玄人」はエンティティタイプの自然言語名から安易にエ
ンティティタイプを識別するのでなく、概念DB構造図を描き、その上での位置
づけ、他エンティティタイプとの関係から総合的にこれを判定いたします。
このサブタイプ分析は、しかしデータモデリングでの一番の難問で時間がかか
ります。必ずしも証拠が用意できませんし、時間効率を上げるために、ユーザ
ヒアリングに依存することになりますが、一人ですべてに答えられるユーザは
いません。自分の関与する狭い業務範囲しか答えられないのが普通です。Y
ES/NOで答えられる設問を用意するには、業務を理解しなければなりません。
そのためには、「鍵となる画面・帳票を選び、その目的を把握して、そこに含ま
れるデータ項目を確認していくのが最も効率が良い」というのが、われわれが
経験的に得た結論です。
画面・帳票は狭い業務範囲をカバーしており、ユーザもなじみを持っています
ので、コミュニケーションをとるための媒体として最適です。しかしそこに表現
されているデータはその業務範囲での見方「偏見」を持っている場合が多々
あります。この偏見の調整が、データモデラーの腕の見せ所になります。
コマーシャルになりますが、弊社ではPLAN−DB手法により、ボトムアップに
帳票間、さらにアプリ間でこの腕を磨かざるを得ません。そしてこの偏見調整
のスキルを、M&A、SCM、B2Bなどでの偏見の調整に活用しています。
頭の中からエンティティを切り出すトップダウンデータモデリングでは、このよう
な偏見調整のスキルが育たないように思われますがいかがでしょうか。