データ・モデリングでビジネスと向き合う

連載 :

2010年10月7日(木)

企業の情報システムで最も重要なものは「データ」

景気低迷もあり、昨今の企業を取り巻く環境は、ますます厳しさを増しています。企業では、これまで以上に迅速な経営判断／意思決定が求められます。その判断材料となる情報は、ますます大事な経営資源となるでしょう。情報のもとになるものが「データ」です。データは、それだけでは意味をなしません。整理／体系化されて初めて、「価値ある情報」に変化します。

データや情報は、湧水のように出てくるわけではありません。企業の日々のビジネス活動に、その源泉があります。企業がビジネス活動を展開すると、人／物／金の動きに連動して、データや情報が発生するのです。また、ビジネス活動には、連続した流れがあります。その流れに並走するように、データや情報が流れていきます。ビジネスとデータの関係、そしてこの流れを図式化したものが、Entity-Relationship Diagram（ERD、ER図）です。

例えば、ある顧客から、ある商品に関する注文を受けた場合、受注番号や受注日、顧客、受注商品などのデータが発生します。これらをER図で表したものが、図1です（この読み解き方については後で説明します）。ビジネス活動と、データや情報、そしてその順番には、密接な関係があることが分かると思います。

図1: ER図の例

データ・モデリングはビジネスをER図に映し出すこと

ビジネス活動で発生したデータや情報は、データベースに蓄積して活用するのが一般的です。ビジネスの流れとデータの流れは同期しているので、企業が運用しているデータベースの定義（構造）を見れば、行っているビジネス活動を把握できるはずです。

しかし、実際にはうまくビジネス活動を把握できないのが現状です。データベースへの参照や更新のレスポンスを考慮する、という実装上の観点から、データベース構造が手直しされているためです。運用中のデータベースとビジネスの間に隙間ができているのです。

このかけ離れている部分を詳しく分析した上で、データベース構造を再構築し、企業の活動とデータの関係を正しく同期させるのが、「データ・モデリング」です。一般的に、データ・モデリングでは、先ほど説明したER図を使って、ビジネスとデータの関係や流れをモデル化（データ・モデル化）します。

ER図とは、ビジネスとデータの関係と流れを図式化したものです。逆に言うと、ER図に書かれたデータ・モデルを読み解くことで、その企業がどのようなビジネス活動をしているのかを把握できます。

ER図の他にも、データの流れを表現するために使う図として、DFD（Data Flow Diagram: データ・フロー図）があります。DFDとER図の違いを見てみましょう。図2の左がDFD、図2の右がER図です。DFDはデータの流れ、ER図はビジネスとデータの関連、というように、それぞれ観点が異なりますが、図2では、どちらも同じ受注活動を示しています。

DFDでは、顧客ファイルや商品ファイルから注文内容のデータを受け取り、受注情報をファイルへ書き出す、という流れは分かりますが、それ以上のことは読み取れません。一方、ER図では、1回の注文で複数の商品を指定できることや、たとえ受注商品が1つでも必ず受注明細を発行すること、つまり、データの従属関係やビジネスのルールまで読み取れます。

図2: DFDとER図（クリックで拡大）

ビジネスはエンティティとリレーションシップで細かく表現できる

図3の左側は、受注から請求までのビジネス活動を時系列に表した業務フロー図です。ER図でも、ビジネス活動（イベント）や経営資源（リソース）を配置し、ビジネス上の有機的な連鎖をリレーションシップで表せば、業務フロー図と同様にビジネスの流れを表すモデルになります。

図3: 業務フロー図とER図（クリックで拡大）

ビジネス活動は、可視的であれ、不可視的であれ、エンティティとリレーションシップという2つの構成要素によって、細かく表現できます。ここでは、（a）エンティティと（b）リレーションシップについて、簡単に説明します。

（a）エンティティ

ビジネスで管理しなければならないデータを、エンティティと呼びます。 ER図では、四角いボックスで囲まれた顧客／受注／商品などが、エンティティに該当します。ビジネスで管理するエンティティは、人／物／金に関するものや行為や事象に関するものすべてが対象となります。

管理対象を漏れなく洗い出すには、どうすればよいでしょうか。手掛かりは、番号やコードにあります。企業が管理すべきデータには、必ず、社員番号、取引コード、注文IDといった識別子が存在します。このため、識別子を目印にすれば、すべて捕捉することが可能です。

また、エンティティは、データの性質から、顧客／商品といったリソース系と、計画／受注といったイベント系の2種類に分類できます。データ・モデリングを使ってビジネスを捉える場合は、まずはイベント系に着目して捕捉するとよいでしょう。その後、対象のビジネスが見えてきたら、リソース系を深掘りすることで、よりビジネスに関する感度が高まります。

（b）リレーションシップ

リレーションシップとは、エンティティとエンティティを結ぶ線のことです。この線がどう描かれているかによって、ビジネスの流れやルールが分かります。

エンティティ間のリレーションシップには、「1:1」、「1:N（複数）」、「N:N」という、数量的な関係があります。これを、カーディナリティと呼びます。

カーディナリティは、エンティティを結ぶ線の先端の記号（「－」や「鳥の脚」）によって表現します。該当データが1件だけか、もしくは存在しない（1か0）といった微妙な関係（任意のカーディナリティ＝オプショナリティ）も、すべて記号で表現できます。

ER図からビジネスの流れを読み解く

エンティティとリレーションシップの2つの要素が、どのように描かれているかによって、ビジネスを詳細に読み解くことができます。実際に、「顧客」と「注文」のリレーションシップを例に、ER図からビジネスを読み解いてみましょう。

図3の例では、「受注」側の記号が「鳥の脚」になっています。1人の「顧客」に対して、1つ以上の「受注」が対応することを表しています。別の言い方をすれば、対応するインスタンスの数の関係が「1:多」であるとも言えます。ビジネス的な表現をすると、「1人の顧客が複数回の注文をする場合もある」、つまり、「同じ顧客からリピート・オーダーがある」ということになります。

さらに、リレーションの双方の記号が「｜」なのか「○」なのかを見ます。「｜」は「必ず存在する」という意味で、「○」は「存在しないこともある」という意味です。図3の例では、「○」になっているため、すべての「顧客」に対して「受注」が存在するとは限らないことを表しています。ビジネス的に言い換えると、「いまだにオーダーのない顧客もいる」となります。

このように、ER図は、複雑なビジネス・ルールであっても、簡単に表現できます。また、RDBMS（リレーショナル・データベース管理システム）における「関係モデル」との親和性も高いため、データの分析から設計まで、幅広く活用されています。

図4: ER図で複雑なビジネス・ルールを表現する（クリックで拡大）

データ・モデリングをいつ実施するのか

データ・モデリングは、システム開発工程における、どの段階で実施するべきでしょうか。開発工程と照らし合わせながら、見ていきましょう。

システム構築には、大きく分けて、企画、開発、実装、運用という4つのフェーズがあります。データ・モデリングは、このうち、データベースへの実装／運用フェーズよりも前段階である、企画／開発フェーズで行います。

まず、企画フェーズにおいて、ビジネスで利用するデータを、漏れなく洗い出します。こうして、データとビジネスの間の、流れと関係を、ざっくりとモデル化しておきます（概念データ・モデリング）。

次に、開発フェーズの前半、基本設計／詳細設計の段階で、ビジネスのルールに合わせてデータを整理／統合したモデルを作成します（論理データ・モデリング）。さらに、論理データ・モデルをベースに、実装しても問題が発生しないように調整し直します（物理データ・モデリング）。

データベースの実装に関わっている方には馴染みが深い、テーブル、インデックス、テーブル・スペースといった物理的な格納構造の設計は、いわゆる「物理データ・モデリング」です。この青写真である「論理データ・モデリング」を、その前段階で行わなければなりません。

図5: 開発工程とデータ・モデリング（クリックで拡大）

データ・モデリングは「どう作るのか」ではなく「何を作るのか」が大事

3つのデータ・モデリング、すなわち、（1）概念データ・モデリング、（2）論理データ・モデリング、（3）物理データ・モデリングについて補足します。

（1）概念データ・モデリング

システム開発では、システムの企画段階で、「システム化の対象範囲」を決めます。しかし、業務の流れを可視化する「業務フロー」を見ても、データの流れまでは分かりません。ここで、概念データ・モデリングを使います。

概念データ・モデリングでは、システムの企画段階で、システム化の対象範囲にあるデータの発生から行き先までを図式化します。業務とデータの流れなど、業務フローでは把握できない情報を、全体的に俯瞰（ふかん）できるようになります。

（2）論理データ・モデリング

論理データ・モデリングでは、概念モデリングで作成した概念データ・モデルをベースに、システム化の対象範囲にあるデータを、細かく整理します。

具体的には、データを整理し（正規化）、重複を排除し（最適化）、誰でも使えるように項目を直し（一般化）、さらに、将来的なビジネスの変化に迅速に対応できるように「安定化検証」を行います。

論理データ・モデリングで重要なことは、概念データ・モデリングと同様に、ビジネスの視点でデータを整理することです。ビジネスがどう転んでも対応できるように、シンプルなデータ構造にすることも重要です。

（3）物理データ・モデリング

物理データ・モデリングでは、「きれいにデータを構造化しても、結局動かないのではしょうがない」という"システムの視点"に立って、処理効率などを考慮し、データ・モデルを調節します。

いずれにしても、設計／開発の段階で、データ・モデリングを活用し、揺るぐことのない、将来の変更にも柔軟に対応できるデータ構造を作っておくことが重要です。こうすることで、システム開発時の生産性だけでなく、保守時の生産性が劇的に高まります。これは、システムの価値が向上するということに他なりません。

今回は、データ・モデリングの概要を、ざっと説明しました。次回は、論理データ・モデリングの中でも一番重要な、データ整理フェーズである「正規化」に焦点を当てます。一般的な正規化技法を紹介するとともに、誰がやっても同じ品質のデータ・モデルを短時間で作れる技法として、アシストが提唱するモデリング技法「正規化簡便法^*1」を紹介します。