全体の目次はこちら
- 4章の目次
- 4. 定義から仕様を読み取る手順
4.4 4.3 + E-R図(概念モデル)
前提
- テーブル定義に加えてE-R図(論理モデル)が存在する
- 論理モデルではサブタイプまでが書かれている
- 実テーブルをそのままE-R図にしたもの(物理モデル)ではない
- 概念モデルも存在する
4.4.1 概要把握
流れとしては以下のようになる。
- エンティティのカテゴリを確認する
- エンティティをリソース系とイベント系に分類する
- エンティティとリレーションシップを元に業務形態を簡潔に表現する
- 概念モデルと論理モデルで登場するエンティティの差分を確認する
次に各手順の目的と作業方法を示す。
なお、手順1と2における作業の目的と作業方法は4.3と同一ではあるがそのまま記しておく。
1. エンティティのカテゴリを確認する
- 作業の目的
- システムがデータをどういった観点で分類しているのかを把握する
- 確認方法
- E-R図(論理モデル)の定義を確認する。特にカテゴリ付けがない場合はスキップする。
2. エンティティをリソース系とイベント系に分類する
- 作業の目的
- リソース系のエンティティよりシステムが扱う対象を把握する
- イベント系のエンティティよりシステムが扱う業務種類を把握する
- リソース系とイベント系の比率でシステムの傾向を把握する。イベント系が多い場合はそれだけ業務の種類が多いということだし、リソース系が多い場合はリソースの操作・メンテナンスが業務の中心だということがわかる。
- 分類方法
- リソース系
- 人・組織・物・設備・顧客・金などを表すエンティティをリソース系として分類する
- イベント系
- 企業活動を構成するアクティビティ(活動)を表すエンティティをイベント系として分類する
- 「いつ・どこで・だれが・なにを」を保存するためのエンティティが該当する
- 業務定義一覧があればそれと照らし合わせつつ分類する
- 通常、E-R図ではリソース系を上部にイベント系を下部に配置する
3. エンティティとリレーションシップを元に業務形態を簡潔に表現する
- 作業の目的
- システムの主要業務を把握する<
- 確認方法
- エンティティ=名詞・属性=形容詞または修飾子・リレーションシップ=動詞で業務形態を表せる
- 概念モデルと論理モデルと組み合わせ確認する
- このとき概念モデルに登場するエンティティのみ確認すること(概念モデルに登場するエンティティが重要なエンティティであるため)
4. 概念モデルと論理モデルで登場するエンティティの差分を確認する
- 作業の目的
- 概念モデルに登場する重要なエンティティが論理モデルにてどのように詳細に展開されているかを確認する。
- また概念モデルと論理モデルの差分を見ることで業務上必要なエンティティを見分ける。
4.4.2 仕様把握
前提
- 概念モデルに登場するエンティティのみ確認する。
確認観点と手順については4.3と同一であるためここでは省略する。
4.5 まとめ
概念モデルがない手順4.2と4.3だと各エンティティの定義をチェックして業務系かシステム系かを分類する必要が生じていいた。だが概念モデルがきちんとあればそれをみればいいだけとなる。
論理モデルがない手順4.2だと業務形態をデータ定義からは把握することができなかった。しかしあれば関連の意味を元に業務形態の概要を知ることができる。
このようにE-R図はシステムの概要を知るには打ってつけの図なのだ。活用しない手はない。