第4回まで，正しく概念データモデリングをするためにはどのようにすればよいのか，その方法を解説してきました。しかし，正しい手順で概念データモデルを行えば，必ず正しい概念データモデルができるとは限りません。概念データモデリングをするのは人間である以上，人間の判断や想像力が大きく品質に影響します。最終回となる今回は，より良いモデルを作成するために有効なノウハウをご紹介したいと思います。
ケース5
E社は，プリンタや複合機と消耗品の販売や保守を扱う事務機器販売会社です。顧客の増加に伴い取扱量が急速に拡大しているため，販売や保守業務などを管理する情報システムの導入を進めています。業務システム開発の要件定義における概念データモデリングの必要性を重要と考えています。そこで，社内各部門から専任のメンバーを選出し，情報システム部との合同で概念データモデリングを進めています。
営業部からの選任メンバーが作成した業務モデルが図1です。業務モデルに合わせて次のようにプロセス説明を作成しました。
 |
| 図1●E社の業務モデル [画像のクリックで拡大表示] |
| 業務（データ発生源） | 帳票 | 処理内容 |
|---|---|---|
|
注文の受け付け （引合） |
注文メモ | 営業は，電話等で顧客から注文を受けたら注文内容を注文メモに記入する |
| 在庫の確認（現在庫） | 商品台帳 | 営業は，引き合いのあった商品の在庫を確認する |
| 入荷予定日の確認（発注） | 発注台帳 | 営業は，在庫がない場合，在庫管理による仕入れのための発注がないかを確認する |
| 納品可能日の通知と発注意思の確認（発注意思確認） | 発注確認メモ | 営業は，在庫がある場合は配送日数をもとに，在庫がなく発注済みの場合は入荷予定日をもとに，在庫がなく発注済みでもない場合は商品の仕入リードタイム（日数）をもとに，顧客への納品可能日を決定する。顧客へ納品可能日を通知し，発注するかどうかを確認する |
| 注文の記録（受注） | 受注台帳 | 営業は，顧客からの発注決定の通知を受けたら，受注を記録する |
これら業務モデルとプロセス説明をもとに帳票を分析して作成した概念データモデルが図2です。
 |
| 図2●E社の概念データモデル [画像のクリックで拡大表示] |
図2を見ると，正しい手順に沿ってモデリングしているように思えますが，残念ながら良いモデルとは言えません。例えば，「在庫確認」エンティティ，「入荷予定確認」エンティティ，「発注意思確認」エンティティなどと，確認したことを記録するエンティティをたくさん記述しています。これらは，業務モデルにおける「在庫の確認」などの確認作業を表すプロセスとそのデータ発生源によって記述されたのでしょう。
しかし，本当にこれらのデータを記録する必要があるのでしょうか。記録されたデータは，後のプロセスで利用されるはずです。在庫の個数自体をあらわす「現在庫」エンティティの「個数」は，在庫数の確認で利用されるので必要だと考えられます。しかし，「個数」を参照した事実を記録している「在庫確認」エンティティは，その後の利用がなさそうです。
つまり，E社の概念データモデルは，不要なエンティティが多く記述されすぎているのです。正しい手順で概念データモデリングを行ったのにもかかわらず，どうしてこのようなことになってしまったのでしょうか。
