第1回では，「業務ルールを整理，分析すること」が概念データモデリングの本当の目的であること，「すでに分かっている業務ルールを概念データモデルに模式化することで整理し，模式化できないあいまいな業務ルールを発見して正しい業務ルールを分析する」作業を繰り返せば，システムが実現すべき要件を明確に定義できることを解説しました。
ところが，せっかく概念データモデルを作成したもののうまく業務ルールの整理，分析ができないことがあります。第2回では，業務ルールを整理，分析するためにどのような概念データモデルを作成すべきなのかを解説します。
ケース2
B社は，無料カタログ配布による通信販売事業を展開する会社です。受注取扱量の拡大に伴い，販売管理業務を効率化する販売管理システムの構築を進めています。
開発はX社が一括で受注し，B社の情報システム部と良好な協力体制の下でプロジェクトは進められました。要件定義工程では，画面イメージを作成してユーザー確認を実施し，概念データモデルで業務ルールの整理を行いました。設計も無事完了して現在は実装工程に進んでいます。
ところがこの段階で，ユーザーから仕様の漏れが指摘されてしまいました。その時の様子をご覧ください。
SE●仕入サブシステムの画面ができました。まずは発注画面（図1）をご覧ください。必須入力の項目は，発注製品，発注数量，仕入先の3項目です。配送業者，顧客，倉庫の入力は任意です。
 |
| 図1●B社，仕入サブシステムの発注画面 |
ユーザー●入力ミスを防止するために少し機能を追加してもらえませんか？
SE●操作性に関するご要望ですか？
ユーザー●いいえ。まず，配送業者を入力したら，顧客は必須入力に切り替えることはできませんか？ それから倉庫に入力できないようにしてください。
SE●はじめに顧客が登録された場合はどうしますか？
ユーザー●先ほどと同様です。配送業者を必須入力に切り替えて，倉庫は入力できないようにします。
SE●分かりました。入力に合わせて必須項目などの変更を行うようにします。
ユーザー●それから，逆に倉庫を入力したら，配送業者と顧客は入力できないようにしてもらえませんか？
SE●すると，配送業者と顧客を入力する場合と，倉庫を入力する場合の2パターンあるということですね。
ユーザー●できれば，発注商品を選択したら，配送業者と顧客，あるいは，倉庫だけ，のどちらかだけが必須で入力になると，もっといいですね。
SE●商品の選択で変更するのですか？ それはすぐには修正できそうになさそうです…。
――ユーザーからいろいろと要望が出ているようですね。
一つ目は，データ間の関係を制限する「制約」です。配送業者，顧客，倉庫の間に制約が必要なようです。
二つ目は，データから二次的にデータを作り出す「導出」です。商品から配送業者，顧客，倉庫のデータが必須か否かを導出する必要がありそうです。この導出について担当のSEはどのようなルールにすべきか見当がついていないようです。
