第6章では、実際の業務を詳細に分析してモデリングをしてみます。
第5章までに学んだことに注意して、概念設計のアウトプットとして冗長性のない、正規形を満たしたER図を作成します。

開発チームとの連携という意味では、このフェーズは業務要件の分析を行い、詳細な仕様を詰めていく段階です。
疑問点やあやふやな点が出てきたら、自分達の思い込みで勝手に仕様を作成してしまうのではなく、必要な人、もしくはグループとの意識合わせを行ってください。
間違った仕様を元に概念設計を行うと、後での修正はたいへんな作業になってしまうことを肝に命じておいてください。

まず、第2章で学んだことを復習しておきましょう。 概念設計の詳細ER図作成で行うことは以下のとおりです。

• 業務で使用するデータ項目をすべて属性として洗い出す
• 正規形を満たしている
• 一意識別子は、この段階では人工的なキーは考えない
• エンティティ名や属性名にはわかりやすい、重複しない名前をつける
• ドメインが決まるものについて検討する

実業務の場合は、以下の観点に留意してください。

• 受注から入金までのデータのターンアラウンドを考えたとき、処理忘れを管理するために「残」が確認できるよう意識して設計します
• 導出項目や重複項目は、正規化の観点からは排除すべきです
  ただし、一度排除してしまうと、元にどのような項目があったかを再度検討することは難しいため、導出、重複、という説明書とともに残しておくことをお勧めします
• 業務に必要な属性はすべて管理する必要があります
  もし、業務で必要な属性が不足していたことが後の工程で分かった場合、データベースの設計し直し、すなわちアプリケーションの作り直しというたいへんな手戻り作業が発生します
  概念設計の詳細設計フェーズですべての業務要件を満たすデータベースを目指して設計してください

項目	業務内容または要求仕様
6.1.1 受発注エンティティの見直し	例題1　受注エンティティの正規化をする
	例題2　受注のステータス管理ができるようにする
	例題3　受発注エンティティ問にリレーションを引く
6.1.2 商品エンティティの見直し	例題4　商品に対する値引きをモデルで表す
	例題5　営業判断による値引きを可能にする
	例題6　商品の価格を分析する
6.1.3 その他の詳細な属性の見直し	例題7　受注ヘッダの膜客属性を見直す
	例題8　受注ヘッダ、受注明細の属性を見直す

表6-1 受発注に関する設問

< 前へ　｜　6.1 【設問】受発注（1/3）　｜ 次へ >