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

Jの衝動書き日記

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

データ定義から読み取る仕様 4. 定義から仕様を読み取る手順

全体の目次はこちら

4. 定義から仕様を読み取る手順

 さて、今までデータ定義からどんな仕様が読み取れるのか・読み取れないのかを示してきた(つもりだ)。

 ここではどのようにしてデータ定義からシステムの概要や仕様を把握していくべきなのかという手順を示していく。

 まず結論から言うと概要モデルまで揃っていた方が一番効率早く把握できる。それを実感してもらえれば幸いだ。

 

4.1 用語について

 エンティティをいくつかの観点で分類していくことになるが、その用語について以下に整理する。

  • 従属エンティティ
    • エンティティが存在するためにはほかのエンティティの存在が必須となるようなエンティティのこと
  • 独立エンティティ
    • ほかのエンティティが存在しなくても存在可能なエンティティのこと(従属エンティティの対義語として使用)
  • 核エンティティ
    • 独立して存在できるエンティティのこと
  • 記述エンティティ
    • ほかのエンティティを説明する性質を持つエンティティのこと
    • エンティティの存在自体がほかのエンティティに依存しているエンティティのこと
  • 連関エンティティ
    •  関連自体が独立して属性を持っていた場合にそのかたまりをエンティティとして定義したエンティティのこと
    •  エンティティ間に多対多となるようなリレーションシップがある場合、それを1対多となるように表現しなおすと連関エンティティが生まれる

 

4.2 テーブル定義+E-R図(物理モデル)+データ

前提

  • テーブル定義は存在する
  • E-R図(物理モデル)は存在する。だが関連の意味を記載していないなど論理モデルレベルの記述がない
  • テーブル定義もE-R図(物理モデル)も存在しない場合はデータベースのスキーマ定義よりツールで生成しておく
  • ドキュメントとして概念モデルや論理モデルが存在しない。もしくはメンテされておらず実体からかけ離れすぎている

 

4.2.1 概要把握

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

  1. テーブルのカテゴリを確認する
  2. テーブルをリソース系とイベント系に分類する
  3. テーブルを業務上必要なものかシステム上必要なものかで分類する

 

次に各手順の目的と作業方法を示す。

1. テーブルのカテゴリを確認する

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

 

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

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

 

3. テーブルを業務上必要なものかシステム上必要なものかで分類する

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

 

4.2.2 仕様把握

前提

  • 業務系のテーブルのみ確認する

 

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

  • テーブルレコードが成立する条件の確認
  • テーブル属性が成立する条件の確認
  • テーブルに対するシステムの分類観点

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

 

4.2.2.1 テーブルレコードが成立する条件の確認

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

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

 

次に各手順の確認方法と確認できる仕様を示す。

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

  • 確認方法
    •  主キーの一部にほかのテーブルの主キーを含んでいるかテーブル定義を見て確認する。含んでいた場合は従属エンティティとする。
    •  また、従属エンティティが持つ外部キーを主キーとして持つテーブルを確認し、従属エンティティが何のテーブルに従属しているかを確認する。
  • 確認できる仕様
    • 従属エンティティとしたテーブルをAとその存在の前提となっているテーブルをBとすると以下のことを確認できる。
      • Aのレコードが存在するためには対応するBのレコードが必ず存在しなければならない
      • Bに存在しないレコードはAにも存在してはならない

 

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

  • 前提条件
    •  外部制約がデータベース上で定義されていること。もしくは物理モデル上で関連が正確に定義されていること。
    •  関連は存在するのに実装上の理由で外部制約が付けられていないと、データ定義上では本来外部キーなのかテーブル間で単に同じ値を持つのかを区別できない。
  • 確認方法
    • 核エンティティ・記述エンティティ・連関エンティティの分類方法は以下のとおりである。
    • 核エンティティ
      • 外部キーを属性として持たない、持ってもNULL可能であるテーブル
    • 記述エンティティ
      • 外部キーを属性として持ちそれがNULL不可でありかつ連関エンティティではないテーブル
    • 連関エンティティ
      • NULL不可の外部キーを二つ以上持ちその組み合わせを管理しているようなテーブル
  • 確認できる仕様
    • 分類したエンティティにより以下のことがわかる。
    • 核エンティティ
      • システムが扱う主要なテーブル。予め存在することが前提となるため、何らかのメンテナンス手段がある。
    • 記述エンティティ
      • 存在するためには核エンティティの存在が必須となる
    • 連関エンティティ
      • テーブル中に外部キー以外の属性を持つ場合その関連が持つ意味を表す。そのためその関連が本来持つ意味を推測するための材料になる。

 

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

  • 確認方法
    • 外部制約のActionを確認する。
    •  noAction/delete on cascade → 1:N
    •  set Null → 0/1:N
    • 外部制約がついていない場合は関連の多重度が1:Nか、0/1:Nかは確定できない。だが少なくとも項目がNULL可能であるならば0/1:Nとはわかる。
  • 確認できる仕様
    • テーブルAとBの多重度が0/1:N
      • Bに対応するAが存在しないことはあり得る。これはAに存在しない要素でもBでは扱うということにもなる。
    • テーブルAとBの多重度が1:N
      • Bに対応するAが必ず存在する。これはAに存在しない要素はBでも扱わないということにもなる。

 

4.2.2.2 テーブル属性が成立する条件の確認

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

  1. テーブルの主キーを確認する
  2. テーブルの候補キーを確認する

 

次に各手順の確認方法と確認できる仕様を示す。

1. テーブルの主キーを確認する

  • 確認方法は自明であるため省略する。
  • 確認できる仕様
    •  主キーの元でどの項目の値が唯一定まるのかを確認できる
    •  また、ある主キーの値を元に定まった項目の値は常に一つのみであり複数の値を同時に取れないことも確認できる。
    •  さらに、主キーが異なれば他の項目はすべて同一でも存在可能となることも確認できる。
    •  もし許さないケースがあるのであればそれが仕様となる(ユニーク制約が付いているはず)。

 

2. テーブルの候補キーを確認する

  • 確認方法
    •  ユニーク制約・ユニークインデックスが付いていて、かつNULL不可であるような項目を探す。
    •  ユニーク制約が付いていない場合は、テーブルの項目中で候補キーとなるような組み合わせを探して実データを検索し確かめる。候補キー候補でgroup byしてもすべて件数が1のみでありgroup by したグループ数とテーブルレコード総数が同じであるならばその組み合わせは候補キーである可能性が高い。
  • 確認できる仕様
    •  論理モデル上で定義されていた本来の主キーがわかる(物理モデル上では複合主キーを代理キーしていることが多い)。
    •  業務上で何を元に対象のテーブルを唯一のもととみなすのかがわかる。

 

4.2.2.3 テーブルに対するシステムの分類観点

手順の確認方法と確認できる仕様を示す。

1. インデックス定義を確認する

  • 確認方法
    •  外部キー以外で設定されているインデックスに注目する
  • 確認できる仕様
    •  インデックスが設定されているということは、その切り口でのアクセスが多いということである。そしてその切り口はシステムがそのテーブルをどういった観点で扱っているかを知るヒントにもなる。
    •  またその観点はテーブルが持つサブタイプを把握するためのヒントにもなる。これは論理モデルにおけるサブタイプを知るヒントになる。