読者です 読者をやめる 読者になる 読者になる

Jの衝動書き日記

さらりーまんSEの日記でございます。

データ定義から読み取る仕様 4.3 4.2 + E-R図(論理モデル)

全体の目次はこちら

4.3 4.2 + E-R図(論理モデル)

前提

  • テーブル定義に加えてE-R図(論理モデル)が存在する
  • 論理モデルはサブタイプまでが書かれているおり、実テーブルをそのままE-R図にしたもの(物理モデル)ではない
  • 概念モデルは存在しない

 

4.3.1 概要把握

流れとしては以下のようになる。

  1. エンティティのカテゴリを確認する
  2. エンティティをリソース系とイベント系に分類する
  3. エンティティを業務上必要なものかシステム上必要なものかで分類する
  4. エンティティと属性とリレーションシップを元に業務形態を簡潔に表現する

 

 次に各手順の目的と作業方法を示す。なお、手順2と3における作業の目的と作業方法は4.2と同一ではあるがそのまま記しておく。

 

1. エンティティのカテゴリを確認する

  • 作業の目的
    • システムがデータをどういった観点で分類しているのかを把握する
  • 確認方法
    • E-R図の定義を確認する。特にカテゴリ付けがない場合はスキップする。

 

2. エンティティをリソース系とイベント系に分類する

  • 作業の目的
    •  リソース系のエンティティよりシステムが扱う対象を把握する
    •  イベント系のエンティティよりシステムが扱う業務種類を把握する
    •  リソース系とイベント系の比率でシステムの傾向を把握する。イベント系が多い場合はそれだけ業務の種類が多いということだし、リソース系が多い場合はリソースの操作・メンテナンスが業務の中心だということがわかる。
  • 分類方法
    • リソース系
      • 人・組織・物・設備・顧客・金などを表すエンティティをリソース系として分類する
    • イベント系
      • 企業活動を構成するアクティビティ(活動)を表すエンティティをイベント系として分類する
      • 「いつ・どこで・だれが・なにを」を保存するためのエンティティが該当する
      • 業務定義一覧があればそれと照らし合わせつつ分類する
      • 通常、E-R図ではリソース系を上部にイベント系を下部に配置する

 

3. エンティティを業務上必要なものかシステム上必要なものかで分類する

  • 作業の目的
    • 業務上で必要なデータを把握することでシステム概要を把握する
  • 分類方法
    •  テーブル定義の説明やテーブルの属性から分類する
    •  業務をすべて人手で行った場合に必要となりそうなエンティティを業務系に分類する
    •  エンティティが明確にシステム上で必要なものとわかった場合はシステム系にする(たとえばキュー情報など)
    •  分類に迷った場合はとりあえず業務系にする

4. エンティティと属性とリレーションシップを元に業務形態を簡潔に表現する

  • 作業の目的
    • システムの主要業務を把握する
  • 確認方法
    • エンティティ=名詞・属性=形容詞または修飾子・リレーションシップ=動詞で業務形態を表せる
    • 業務系と分類したエンティティが対象でイベント系を中心にチェックする

 

4.3.2 仕様把握

前提

  • 業務系のエンティティのみ確認する

 

以下の観点で使用を把握していく

  • エンティティが成立する条件の確認
  • エンティティ属性が成立する条件の確認
  • エンティティに対するシステムの分類観点

次に観点毎の手順を示す。

 

4.3.2.1 エンティティが成立する条件の確認

流れとしては以下のようになる。

  1. エンティティが独立か従属かを確認する
  2. エンティティを核エンティティ・記述エンティティ・連関エンティティに分類する
  3. リレーションの多重度を確認する

 

 次に各手順の確認方法と確認できる仕様を示す。4.2に比べると1と3の手順はE-R図のみで判断可能なので楽である。

 

1. エンティティが独立か従属かを確認する

  • 確認方法
    • エンティティと関連の形状で判別が可能である
    • エンティティの形状が長方形である場合は独立を表し角丸長方形である場合は従属を表す
    • 関連の形状が実線である場合は依存を表し点線である場合は非依存を表す
  • 確認できる仕様
    • 従属エンティティとしたエンティティをAとその存在の前提となっているエンティティをBとすると以下のことを確認できる
      • Aのレコードが存在するためには対応するBのレコードは必ず存在しなければならない
      • Bに存在しないレコードはAにも存在してはならない

 

2. エンティティを核エンティティ・記述エンティティ・連関エンティティに分類する

  • 確認方法
    • 核エンティティ・記述エンティティ・連関エンティティの分類方法は以下のとおりである。
    • 核エンティティ
      •  外部キーを属性に持たない、持っていてもその多重度がN=0もあり得るようなエンティティ。独立エンティティが候補となる。
    • 記述エンティティ
      •  独立エンティティのうち核エンティティでも連関エンティティでもないエンティティ。従属エンティティのうち、連関エンティティではないものが候補となる。
    • 連関エンティティ
      •  記述エンティティ候補としたもののうち二つのエンティティを繋いでいるようなエンティティ。当該エンティティを削除してもそのエンティティの持っていた関連が多対多で成立する場合は連関エンティティである。
  • 確認できる仕様
    • 核エンティティ
      • システムが扱う主要なエンティティ。予め存在することが前提となるため、何らかのメンテナンス手段がある。
    • 記述エンティティ
      • 存在するためには核エンティティの存在が必須となる。
    • 連関エンティティ
      • エンティティ中に外部キー以外の属性を持つ場合その関連が持つ意味を表す。その関連が成立するときに発生する情報があるということでもある。

 

3. リレーションの多重度を確認する

  • 確認方法
    • E-R図で確認可能
      • IDEF1X記法 0 or 1 の表現が親側と子側で異なる
      • f:id:newWell:20170117103824p:plain
      • IE記法 親側・子側ともに同じ表現 下限-上限で表現する
      • f:id:newWell:20170117104002p:plain
  • 確認できる仕様
    • エンティティAとBの多重度が0/1:N
      • Bに対応するが存在しないことはあり得る。これはAに存在しない要素でもBでは扱うということになる。
    • エンティティAとBの多重度が1:N
      • Bに対応するAが必ず存在する。これはAに存在しない要素はBでも扱わないということになる。
    • エンティティAとBの多重度が1:3
      • Aに対応するBが3つ存在する。この多重度の個数が仕様となる。

 

4.3.2.2 エンティティ属性が成立する条件の確認

以下の観点で確認する。

エンティティの主キーを確認する

  • 確認方法
    • 論理モデルでは主キーを代理キーで定義していないはずなのでモデル上にて確認可能
  • 確認できる仕様
    •  主キーの元でどの項目の値が唯一定まるのかを確認できる
    •  また、ある主キーの値を元に定まった項目の値は常に一つのみであり複数の値を同時に取れないことも確認できる。
    •  さらに、主キーが異なれば他の項目はすべて同一でも存在可能となることも確認できる。

 

4.3.2.3 エンティティに対するシステムの分類観点の確認

以下の観点で確認する。

サブタイプを確認する

  • 確認方法
    • E-R図にてサブタイプを確認する。
    • IDEF1X記法
    • f:id:newWell:20170117104831p:plain
    • IE記法
    • f:id:newWell:20170117104843p:plain
    • さらにテーブル定義書を確認し、サブタイプを次のどちらの方法で定義しているのかを確認する。
      1. スーパタイプとサブタイプを統合している
      2. スーパタイプとサブタイプを分離している
  • 確認できる仕様
    •  サブタイプがそのエンティティの分類観点となるためそれがシステムとして重要な分類観点だとわかる。
    •  また、スーパタイプとサブタイプを統合して一つのテーブルとしている場合にはサブタイプのみに存在する属性はNULL可能項目となる。その項目の設定条件はサブタイプとしての性質を満たすときであり、すなわちそれが把握するべき仕様となる。