» 【145号】 データモデルの要件

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

■情報の発生と共有
「子供が生まれた」、「商品が売れた」、「お金を下ろした」など、情報はイ
ベントで発生します。人間はこれをデータ化し、共有−昔の自分と今の自分と
の共有を含めて−します。初めは発生順に記録するだけかもしれませんが、情
報の形式対応に分類して記録するようになります。データには構造があり、こ
れに沿って記録するのが得策だと悟るからです。

初めは物理データ構造の同じものを一括するリレーショナルモデルが登場しま
したが、実装独立の指向から、よりユーザ視点に立ったエンティティベースの
モデルがこれに置き換わっていきました。
これがデータモデリングの出発点だと考えられます。
いまや多くの人が手がけるデータモデリングですが、使用するツールや、誰に
手ほどきを受けたかによって、さまざまな考え方、やり方が行われているよう
に思われます。データモデリングにおいて、何が必須か、また好ましいか、以
下整理してみたいと思います。

■実装独立での整合性
データモデリングとRDB設計が未分化のころは、RDBに実装されないデー
タはデータモデリングの対象外とされていました。生年月日と当日日付から計
算できる年齢や、数量と単価から計算できる金額は勿論、月次出荷数量なども
冗長データ−正規化の敵−として対象外とされる場合が多かったようです。さ
すがに在庫数量まで冗長とはしなかったようですが、RDB設計指向のデータ
モデルでは、加工データに対する正当な扱いが遅れたようです。
われわれは、ビジネス視線でユーザの意識するデータはすべて俎上に載せ、参
照制約と同時に加工データ制約を明らかにして、実装独立の世界で整合性を保
証すべきと考えます。加工データ制約分析のため、われわれはSPF(Schema
Process Flow)操作を考案しました。これにより、整合性の高い基本4ドキ
ュメント−概念DB構造図、データ定義書、業務フロー図(IPFチャート)、
IO定義書―ができ、これを基に試行錯誤なしに実装設計が進められよう配慮
しました。

■セマンティックスの表現
イベントは出来事の記録ですが、一般に、5W2H、Who Whom What Where
When How HowMuch、の形式をとります。HowMuchを除いては、名詞が対応しま
す。この名詞は出来事を記述するための用語ですが、おおむね、社員、顧客、
商品、支店など経営資源を表しており、これらをわれわれはリソースと呼んで
います。したがって、「イベントの意味は、5W2Hの役割を果たすリソース
データから成る用語によって示される」と言うことができます。用語が違うと
意味が通じませんから、これを全社統一しようと言うのが、今話題のMDM
(Master Data Management)です。
リソースには、社員−部署−職種、顧客−営業所−倉庫−工場−業種、商品−
部品−製品−製品分類など、主に分類にかかわる種々のエンティティタイプ間
の関係があります。またイベント間には、受注→出荷→納品→請求→入金と言っ
た前後関係のほか、異なったエンティティタイプに属する、在庫数量と入庫数
量・出庫数量の間や月次出荷数量と(イベント)個別出荷数量の間には加工・
加工元の関係があります。これらの異なったエンティティタイプ間の(注1)、
関係の意味を個人差なく分かりやすく表現するニーズも、効率よく高品質を維
持するために重要です。われわれはこれをデータモデル図のレイアウト規則と
矢線によって表現していますが、欧米系のデータモデルにはレイアウト規則を
持つものを見たことがありません。
(注1)正確には「異なったエンティティタイプに属する属性間の」となります。

■フェデレーション・アーキテクチャ
1990年以降C/SのDBMSを用いたアプリケーションが続々登場しまし
た。システム部門のガバナンスが低下したこともあって、多くは孤島システム、
いわゆるSiloです。アプリごとにリソースデータを定義して、方言がたくさん
できて、データが流通できなくなったわけです。これを解消するために全社を
1個のシステムとして統合するERPが登場しました。
しかし全社をERPでカバーしてうまく行く企業は限られています。レガシー
やその他パッケージを組合せるとき、多くの難題を抱えることになりました。
やはり各アプリはそれぞれの文化を持っており、これを活かしながら、その文
化をハイレベルで連携するフェデレーション・アーキテクチャが無理のないも
ののように思われます。
われわれは当初より、リソース一元化は絶対条件としてきました。このため1
個のアプリケーション開発でも、リソースDBは独立させるものとしました。
こうしてSiloを未然に防ぐことができましたが、もう一つ条件を追加すべきこ
とに、数年前に気づきました。それはアプリケーション横断のイベント(トラ
ンザクション)の通信場を用意すべきことです。これをわれわれはEDH
(Enterprise Data Hub)と呼んでいます。これはリポジトリ、リソースDB
に次ぐ、第3のインフラDBと言うことになります。SOAベンダーのESB
ツールは、完全仮想化を前提にした、EDH実装方式の一つと考えられます。
フェデレーション・アーキテクチャにおける、アプリ間の通信場EDHの構造
は、業種ごとにテンプレートが用意できるほど安定したものになると思われま
す。したがって、初めにこれをしっかり設計しておけば、以後のメンテナンス
はほとんどアプリ内で解決でき、迅速対応、保守コストダウンにつながるもの
と期待されます。

■ボトムアップ実証主義
われわれはユーザニーズを表すIOを集めれば、個人差なく概念DB構造は決
まると考えます。現状のIOからは現状の概念DBが、新規のIOからは新期
の概念DBが決まると考えます。したがって「決める」べきはユーザ要件を表す
IO、これを分析してDBは「決まる」ものと考えます。すなわち「物理DBは設計
対象であるが、概念DBは設計対象ではない」と考えるわけです。
世の中には「DBのトップダウン設計」と言う話題があります。おそらく新規D
Bなのでしょうが、これは新規IOが分かっている神様にだけできる技かと思
われます。
一般にDB設計を含むプロジェクトは、設計技術習得やビジネス理解のための、
貴重なチャンスです。現状IOを分析することによって、データモデリング技
術が習得され、現状や問題点の共有が進みます。そこで新規IO設計を行うこ
とによって、より良いToBeが共有されます。人材育成とシステム開発が同
時に達成でき、「無駄はなかった」という実感を持っています。テンプレート
などの活用によるスピードアップは、この枠組みの中で行います。一見効率の
良いトップダウンDB設計は、習得やノウハウ継承が難しく、思い込みモデル
で、実装段階に手戻りの発生しやすい危険なやり方になる恐れがあり、要注意
です。
(注2)いま話題のサービスは、更新系のIOとは1対1、参照系のIOとは
N対Mの関係になるようです。これが正しければ、上記記述のIOをサービスに
置き換えることができる−したがって、一連のサービスによって、概念DB構造が
決まる−ように思われます。