|
|
| 図5●DOAにおけるデータモデリングの流れ 抽象度の異なる3つのモデルを作成する |
次に，ER図を使ったデータ・モデリングの流れを説明しよう。一般にDOAのデータ・モデリングでは，「概念データ・モデル」，「論理データ・モデル」，「物理データ・モデル」という，抽象度の異なる3種類のモデルをER図で作成する（図5）。マーチンのIEでも，概念，論理，物理の3種類のデータ・モデルを，すべてER図を使って記述する。
概念データ・モデル＊6とは，ユーザーの要件に基づいて，開発するシステムに求められる大まかなエンティティとリレーションシップをまとめたモデルである。システム開発プロジェクトの最初に作成するモデルであり，プロジェクト全体の鳥瞰図となる。
論理データ・モデルは概念データ・モデルに，画面や帳票の設計結果を参照してシステムで必要とする属性をすべて付与したモデルだ。個別の実装技術には依存しない。
最も抽象度の低いモデル，すなわち実装を意識したモデルが物理データ・モデルだ。RDBのテーブルと1対1に対応し，データ型やインデックスまで定義する。テーブルのスキーマ＊7の生成が可能なモデルである。
ヒアリングでエンティティ抽出
「日用品製造業の仕入れ業務」を例に挙げて，最も重要で難しい概念データ・モデルから論理データ・モデルの作成までを詳しく説明しよう。
|
|
| 図6●ヒアリングに基づくエンティティの抽出例 日用品製造業の仕入れ業務の例を示した。青色部分がイベント系エンティティ，斜体部分がリソース系エンティティの候補である |
まず，現状の業務調査やキーパーソンへのヒアリングなどを通じて，全体の業務フローやシステム化の対象範囲，ユーザーのニーズなどを把握する。この現状分析結果を基に，まずエンティティの候補を抽出する（図6）。何をエンティティとして抽出すればよいかを判断するには，実務の中で経験を積むしかないが，目安としては，「～する」と言い換えられる単語がイベント系エンティティ（図6の青色部分），マスター・データに当たる単語がリソース系エンティティ（同，斜体部分）の候補となる。
エンティティを抽出したら，エンティティ同士にリレーションシップを付ける。これが概念データ・モデルだ。図7に，図6のヒアリング結果を基に作成した概念データ・モデルの例を示した。
|
|
| 図7●図6のヒアリング結果に基づいて作成した概念データ・モデルの例 |
リレーションシップを付ける際は，最初にイベント系エンティティがどのリソース系エンティティを参照するのかを調べて，イベント系とリソース系を関連付ける。納品時に「発注先」から「品目」が納品されるので，図7では「納品」というイベント系エンティティを「発注先」と「品目」という2つのリソース系エンティティに関連付けている。また，納品時は1つの発注先から複数の部材が納品されるので，「発注先」と「納品」間の多重性は「1対多」。1つの品目は何度も納品され，1度に複数の品目が納品されることもあるので，「品目」と「納品」間の多重性は「多対多」となる。
イベント系とリソース系を関連付けたら，次にイベント系同士を関連付ける。「納品」に対して「請求」が行われるので，図7では「納品」エンティティと「請求」エンティティの間に，1対1のリレーションシップを設定している。この際，未請求の納品も存在し得るので，「請求」側には○印を記入している。
対照表で多対多を整理
図7では，多対多の関係にある「品目」エンティティと「納品」エンティティの間に，「納品品目」というエンティティを挿入している。このエンティティが，先に述べた「対照表」である。これにより「多対多」のリレーションシップを，「品目」と「納品品目」，そして「納品品目」と「納品」という，2つの「1対多」のリレーションシップに置き換えている。
なぜわざわざ，こんな作業が必要になるのか。それはRDBのテーブルでは多対多の関係を効率的に表現できないため，1対多の関係に置き換える必要があるからだ。
仮に納品と品目が多対多の関係にあることをRDBのテーブルで表現しようとすると，「納品テーブル」には1度に納品される品目の数だけ列を用意しなければならない（同様に品目テーブルにも納品の数だけ列を用意する必要がある）。品目の数は納品ごとに異なるため，納品テーブルには品目の最大数の列を用意する必要があるが，これは容量の無駄である。さらに，品目が増えるたびに列の数を増やしてテーブル構造を変更しなければならないため，極めて保守性の悪いデータベースになってしまう。
この問題をモデリングの段階で解決するのが対照表である。図7の場合，「納品品目」エンティティの識別子は「品目番号」（品目エンティティの識別子）と「納品書番号」（納品エンティティの識別子）の組み合わせとなる。さらに，品目番号と納品書番号がそれぞれFKとなり，これらを介して品目エンティティおよび納品エンティティと関連付けられる。
納品品目エンティティをRDBのテーブルに実装した場合，列としては同エンティティの属性である「品目番号」と「納品書番号」の2つがあればよいことになり，この2つのFKを介して，品目テーブルおよび納品テーブルと関連付けられる。新しい品目が増えた場合は，品目テーブルの行を追加するとともに，納品品目テーブルに新たな組み合わせを行として追加するだけでよい。
画面や帳票を基に詳細化
上で述べた概念データ・モデルの作成作業は，ヒアリングに基づいてエンティティやリレーションシップを定義する，いわゆるトップダウンのモデリングである。
これに対して，論理データ・モデルは，現行システムの画面や帳票，現行データベースのテーブル，並行して設計している新システムの画面などを基に，具体的な属性を付与したりリレーションシップを修正したりして概念モデルを詳細化したもの＊8。いわばボトムアップのモデリングによって作成する。
図8は，図7の概念データ・モデルを詳細化した論理データ・モデルの例である。図7と見比べると分かる通り，エンティティに必要な属性（データ項目）を追加したり，新たなエンティティを追加したりしている。
|
|
| 図8●論理データ・モデルの例 |
例えば，「品目」と「発注先」の間には，「品目発注先」という対照表を新たに追加している。これは開発中の画面から「発注先ごとに発注できる複数の品目が決まっており，ある品目は複数の発注先に発注できる」こと，つまり「品目」と「発注先」に多対多の関係があることが分かったためだ。
現場レベルの視点からのモデリング，すなわちボトムアップのモデリングによって，見落としていたポイントに気づくことは多い。その意味で，画面や帳票からのデータ項目洗い出しは，極めて重要である。
物理モデルの実装へつなげる
論理モデルを作成したら，RDBに実装できるよう，物理モデルに変換する。具体的には，属性のデータ型を定義したり，リレーションシップを基に属性の値に制約を設定したりする。例えば，条件付きのリレーションシップを設定しているFKの制約＊9は，「Allow Null（値が設定されないことを許容する）」となる。
以上，駆け足でDOA登場の歴史的背景とデータ・モデリングの基礎を解説した。DOAは単なるデータの整理やデータベーススキーマの表現手段ではない。ビジネスの分析手段，あるいは最適な業務プロセスを見いだす思考の手段としても極めて有効だ。本記事がDOAの習得を目指すITエンジニアの一助になれば幸いである。
|
