データ定義から読み取る仕様（中編）

前編はこちら
後編はこちら

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

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 の表現が親側と子側で異なる
　
　IE記法 親側・子側ともに同じ表現 下限-上限で表現する
　
確認できる仕様
　エンティティ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　エンティティ属性が成立する条件の確認

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

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

以下の観点で確認する。
1.　サブタイプを確認する
確認方法
　E-R図にてサブタイプを確認する。
　IDEF1X記法
　
　IE記法
　

　さらにテーブル定義書を確認し、サブタイプを次のどちらの方法で定義しているのかを確認する。
　　a) スーパタイプとサブタイプを統合している
　　b) スーパタイプとサブタイプを分離している
確認できる仕様
　サブタイプがそのエンティティの分類観点となるためそれがシステムとして重要な分類観点だとわかる。
　また、スーパタイプとサブタイプを統合して一つのテーブルとしている場合にはサブタイプのみに存在する属性はNULL可能項目となる。その項目の設定条件はサブタイプとしての性質を満たすときであり、すなわちそれが把握するべき仕様となる。

4.4 　4.3 + E-R図(概念モデル)

前提

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

4.4.1 概要把握

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

1.エンティティのカテゴリを確認する
2.エンティティをリソース系とイベント系に分類する
3.エンティティとリレーションシップを元に業務形態を簡潔に表現する
4.概念モデルと論理モデルで登場するエンティティの差分を確認する

次に各手順の目的と作業方法を示す。
なお、手順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図はシステムの概要を知るには打ってつけの図なのだ。活用しない手はない。