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

Jの衝動書き日記

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

データ定義から読み取る仕様  5. 仕様が抜け落ちないようにするための工夫

全体の目次はこちら

5. 仕様が抜け落ちないようにするための工夫

 さて、4章では概要把握をするには概念モデルを見るのが手っ取り早いことを示した。また、設計を詳細に実装していくことで本来持っていた意味を失う可能性があることも示せたと思う。

 では仕様の抜け落ちをできるだけ防ぐにはどうしたらよいのだろうか。その指針をここでは示そう。

 

5.1 E-R図(概念モデル)の工夫

 E-R図は単なる図ではなく複数の情報を埋め込まれた図だ。だから図の持つ意味を正確に表現しないといけない。

必須事項

  • エンティティの独立・従属はしっかりと区別して書く
    • 長方形:独立・角丸長方形:従属である。気分で変えないように。
  • 多重度の記述は最小・最大を意識して書く
    • 0か1か・1か・1以上か。特に多重度に固定値がある場合は正確に記述すること。
  • リレーションシップにはきちんと意味を記述する
  • なるべく論理モデルとは別立てで作成する
  • 論理モデル起因の概念モデル修正はなるべく控える

しておくと便利

  • エンティティがリソース系かイベント系かを区別可能な記述(タグなど)を付けておく
  • エンティティが核・記述・連関エンティティかを区別可能な記述(タグなど)を付けておく

 

 概念モデルと論理モデルを別立てで作成するとメンテナンスが面倒かもしれない。特に論理モデルで修正が入った場合その都度修正するのは確かに億劫だ。

 だがちょっと考えて欲しい。

 概念モデルでは主キーや属性を記述しないため論理モデルの都度反映は本来不要であるはずだ。また、概念モデルは業務中心に考えたものであるため業務が増えない限りはそうそうエンティティが追加になることもない。論理モデルでエンティティが増えたとしても、システムを実装する上で必要となったエンティティの反映は不要であるはずなのだ。

 もし概念モデルに手を加えなければいけないほどの修正があったとしたら、その修正は影響がかなり大きい証拠でもある。その場合はきちんと概念モデルも反映しないといけない。

 また、E-R図を書くときのポイントだがいきなりE-R図を書こうとはしないことだ。業務フロー図や業務定義書からエンティティ候補をある程度抽出し、その関連を考えてから書くとよい。

 ……え? 業務フロー図や業務定義書がないって?

 ……正式なものではなくてもメモ程度のものはあると思う。それすらないのであれば、まずはそれらを作成すべきだ。

 

5.2 E-R図(論理モデル)の工夫

 E-R図のことなので、基本的な注意事項は5.1と同様ではあるが、一応重複する事項も含めて書いておく。

必須事項

  • エンティティの独立・従属はしっかりと区別して書く
    • 長方形:独立・角丸長方形:従属である。気分で変えないように。
  • 多重度の記述は最小・最大を意識して書く
    • 0か1か・1か・1以上か。特に多重度に固定値がある場合は正確に記述すること。
  • リレーションシップにはきちんと意味を記述する
  • 論理モデル上では複合主キーを安易に代替キーで記述しない
    • 定義する場合は、必ず候補キーも明記しておくこと(E-R図で表現する方法はないのでメモで追記する)
  • 特定の条件でのみ設定するような属性がある場合はサブタイプで表現してみる
  • エンティティの持つ属性はなるべく更新タイミングが同一となるもので構成する

しておくと便利

  • エンティティがリソース系かイベント系か区別可能な記述(タグなど)を付けておく
  • エンティティが核・記述・連関エンティティかを区別可能な記述(タグなど)を付けておく
  • 属性の記述はそのエンティティを代表するような重要なものに留める

 特に属性の記述については詳細なものは物理モデルで記述するべきである。もし論理モデル上ですべてを記述する場合はツールで重要な属性を色付けするなどほかの属性と区別しやすくするとよい。重要な属性とは主要業務に関係のある情報やそのエンティティのみにある情報である。

 また、論理モデルを元に物理モデルを作成するときに実装上の理由からエンティティを分離・結合した場合はその対応を論理モデルの方へ残しておくとよい。物理モデルで追加した属性を随時変更する必要はない。だが論理モデルと物理モデル間におけるエンティティの対応付けを怠ると論理モデルを残す意味が半減してしまう。

 

5.3 テーブル定義書の工夫

 残念ながらE-R図を作成しない・もしくは作成してもリバース生成のみで留めるとした場合でもできることはある。だが、本来図で表現するようなことも定義書に書かなくてはいけないために記述量が多くなってしまうのであまりオススメはできない。

必須事項

  • 候補キーがある場合はユニーク制約を付けておく
    • 制約を付けない場合は、候補キーをテーブル定義に明記する
  • 関連があるのに外部制約を付けない場合は関連があることを明記する
  • 特定の条件にのみ成立する関連がある場合はその条件を明記する
    • サブタイプのみが持つ関連が該当する
  • 関連の多重度に下限・上限がはっきりしている場合はそれを明記する

しておくと便利

  • 設計時にエンティティを分類した場合、その分類名をテーブル定義にきちんと残しておく
    • 特にリソース系・イベント系程度は記述しておくと便利
    • 核・記述・連関エンティティも記述しておくとなお良い

 

6. おまけ

 E-R図がとても大事だということは今まで述べてきた通りである。ではそれを書くのに適したツールはなんだろうか。

 オススメしたいツールは「A5:SQL」だ(A5:SQL Mk-2 - フリーの汎用SQL開発ツール/ER図ツール)。

 これを用いればE-R図の記法に従った図をきちんと作成できる。サブタイプもふつうに表現可能だ。またIDEF1X記法とIE記法どちらも表現できる。

 表示レベルも変えられる。エンティティ名のみ・主キーのみ・属性という風にレベルを変えた表示ができる。表示するべき属性も指定できたりする。まさしく論理モデルを書くには打ってつけのツールだ。

 E-R図からのDDL自動生成やデータベーススキーマからのE-R図リバース作成もできたりする。作成したE-R図を画像イメージ化もできるし、テーブル定義書の生成もできる。

 しかもフリーで使える。使わなければ勿体無い。正直、これフリーでいいの?という出来なのである。これでドメイン定義までできたらまさしく神ツールだったのだが(ドメイン定義機能もあるにはあるのだが機能としては今ひとつである)。

 唯一の難点としては、サブタイプを表現した場合E-R図からDDLを自動生成したときにテーブルが分離されて作成されることだろうか。きちんとE-R図の物理モデルを別途作れば済む話ではあるのだが、論理モデルとの同期がとれないためその辺は手動管理していく必要がある。

 ちなみに商用ツールの場合はこのあたりの挙動はどうなのだろうか。サブタイプを含むE-R図からDDLを自動生成した場合も同じようにテーブルが分離されるかどうか残念ながらわからない。お高いので触り倒す機会がなかった。

 もう一つは「ERMaster」である(ER Master)。A5:SQLWindows用ツールなのでMacな人には使えない。その点ERMasterはJavaなのでどちらでも使える。

 A5:SQLと同様にE-R図の作成からDDLの自動生成・データベースからのE-R図リバース生成・テーブル定義書の自動生成などができる。残念ながらサブタイプの表現ができないため、どちらかと言うと物理モデル寄りのE-R図作成に適していると思われる。

 またEclipseプラグインであるためちょっと動作は重いのが難点か。

 ところで、時折ExcelでE-R図を書くような現場もあるのだが、これは絶対にやめた方がいい。E-R図の図や線の形状にはそれぞれ意味がある。そのため形状を間違うと意味まで変わってしまうのだが、Excelの場合はE-R図の意味を考えずに図を作るだけなので誤りの元である。意味の間違ったE-R図なんて存在意義がないしバグの元になる。Excelで書くのだけは絶対に辞めておこう。使うとしても下書き程度に留めるべきだ。

データ定義から読み取る仕様 4.4 4.3 + E-R図(概念モデル)

全体の目次はこちら

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図はシステムの概要を知るには打ってつけの図なのだ。活用しない手はない。

データ定義から読み取る仕様 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可能項目となる。その項目の設定条件はサブタイプとしての性質を満たすときであり、すなわちそれが把握するべき仕様となる。

 

データ定義から読み取る仕様 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. インデックス定義を確認する

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

データ定義から読み取る仕様 3. 設計書が欠けると落ちていく仕様

全体の目次はこちら

3.設計書が欠けると落ちていく仕様

 理想は、すべてのレベルのE-R図(概念モデル・論理モデル・物理モデル)が揃っていることである。ではこれらが欠けているとどうなるのだろうか。

 

3.1 テーブル定義はあるがE-R図(物理モデル)がない・自動生成のみの場合

以下のような不都合が生じる。

  • 候補キーを確認できない
  • 関連を失う
  • 関連の意味がわからない
  • サブタイプを失う
  • 正確な多重度がわからない

次にこれらの原因と問題点を示す。

 

候補キーを確認できない

  • 原因)
    • 本来の主キー(複合主キー)は代理キーとなることが多く、本来の主キーにユニーク制約を付けていないとそれが主キーだとわからない
  • 問題点)
    • エンティティが本来何のキーを元に唯一となるのかがわからなくなる
    • 各項目に関して本来重複があり得ないのか・あり得ないのかがわからなくなる

 

関連を失う

  • 原因)
    • 性能面の考慮や実装上の理由により外部キー制約をつけないことがある
  • 問題点)
    • 本来存在する関連を確認できない
    • データの整合性をプログラムで保つ必要があるが、どう保っているのかをテーブル定義やE-R図からは読み取れない

 

関連の意味がわからない

  • 原因)
    • DDLでは関連の名称を定義できない。そのため自動生成では抽出不可能となる
  • 問題点)
    • 業務形態を示せなくなる

 

サブタイプを失う

  • 原因)
    • 一般的なデータベースではサブタイプ自体を定義できない
  • 問題点)
    • スーパタイプ・サブタイプを統合して作成したテーブルの場合NULL可能項目がどんな条件のときに設定されるのかがわからない*1
    • 条件付き関連(サブタイプのみが持つ関連)の定義ができないため本来の関連が持つ意味を失い誤解の元となる

 

正確な多重度がわからない

  • 原因)
    • 多重度の個数がデータベース上では定義できな
  • 問題点)
    • 多重度に明確に上限個数が存在しても、それがわからない
    • 1:NのN>=0なのかN>=1なのかを区別できない。そのため必ずあるのか・無いこともあり得るのかがわからない

 

3.2 E-R図(物理モデル)はあるがE-R図(論理モデル)がない場合

以下のような不都合が生じる。

  • サブタイプを失う
  • サブタイプが持つ関連を失う
  • 本来の主キーを失う

次にこれらの原因と問題点を示す。

 

サブタイプを失う

  • 原因)
    • サブタイプを実際のテーブルに展開した場合サブタイプを直接表現する方法がない
    • サブタイプを含むエンティティは通常スーパタイプと統合されたテーブルとして実装される
  • 問題点)
    • 統合したエンティティに特定のエンティティのみに必要な属性が含まれることになる
    • エンティティに本来必要な属性・不必要な属性が混在して区別がつかない
    • サブタイプ固有の属性はNULL可の項目となるが設定条件はモデルからはわからない

 

サブタイプが持つ関連を失う

  • 原因)
    • サブタイプとスーパタイプを統合したときサブタイプのみが持つ関連を失う
  • 問題点)
    • 統合テーブルでも関連は設定可能だが、本来の意味は失ってしまう

 

本来の主キーを失う

  • 原因)
    • 複合主キーは通常代理キーを設定する
    • 候補キーとして本来の主キーを定義しなかったときに失う
  • 問題点)
    • 本来の主キーの項目で複数値がありえるのかありえないのかが区別できなくなる
    • 代理キーさえ異なれば後の項目はまったく同一であるようなレコードが生成可能となってしまうが、モデル上からはそれがあり得るのか・あり得ないのかが判断できない

 

3.3 概念モデルがない

 表記レベル上は概念モデルよりも論理モデルの方が上なので抜け落ちる仕様はないように思われる。

 だが概念モデルがない場合「モデルの概要」が抜け落ちる。システムで扱う本質的なエンティティとそれ以外のエンティティとの区別が付かなくなるため全体を手早く把握する術がなくなってしまう。

 ただし概念モデルがあればいいというものでもない。概念モデルと論理モデルの対応付けがされていないとむしろ把握が困難になるからだ。

 

3.4 まとめ

 E-R図がないために様々な仕様が落ちていくことを上記で示してきた。もちろん抜け落ちた仕様は何らかのドキュメントで残っているはずではある(最終的にはソースという形で)。 だがそれらの記述は分散していることだろう。故にメンテナンスも大変になる。

 一方E-R図があればそれだけを見ればいいし修正も集中的に行える。さてE-R図があるのとないのとではどちらの状況がバグを生みやすいのだろうか。

*1:NULL可能項目は、項目の設定は任意・ある特定の条件の場合は設定されるが条件に一致しないときは決して設定されない・ 設定されるタイミングが異なるというように満たす条件が異なるため区別がつきにくい

データ定義から読み取る仕様 2. 設計書から読み取れる仕様とは

全体の目次はこちら

2. 設計書から読み取れる仕様とは

 さて、本ドキュメントの題名は「データ定義から読み取る仕様」としている。そのため扱う設計書はテーブル定義書とE-R図になる。これらの設計書からどのようなことを読み取るべきなのだろうか?

 

2.1 テーブル定義書とデータ

 テーブル定義書のフォーマットは色々あるが、たいてい以下の項目が記述されているはずである。

  • テーブルの定義 : 名前とその説明
  • テーブル属性の定義 : 名前・型・NULL可否・デフォルト値・説明など
  • 主キーの定義
  • 制約の定義 : 外部制約やユニーク制約など
  • インデックスの定義


これらの情報を元に以下のような仕様を読み取っていく。

  1. システムが扱うデータの分類方法
  2. システムが扱うデータの範囲
  3. システムがデータを一意のものと見なすための項目
  4. システムがデータを一意のものと見なすための項目で主キーではない項目(テーブルの候補キー)
  5. テーブル同士の関連
  6. テーブル同士の関連多重度
  7. データの形式や値域
  8. テーブル中の業務上必要な項目とシステム上必要な項目の区別
  9. 主キーの元で唯一定まる従属属性の確認
  10. システム上重複がありえる項目の確認
  11. データに対するシステムの主要アクセスパターン

 

上記は以下のようにして読み取る。

1) システムが扱うデータの分類方法に関してはテーブル名一覧で確認する。一覧が単なる羅列であるならば残念ながら分類方法を読み取ることはできない。

2) システムが扱うデータの範囲に関しては各テーブルの定義で確認する。テーブル定義にない事項はシステム管理外の情報ということになる。

3) システムがデータを一意のものと見なすための項目に関しては主キー定義で確認する。

4) システムがデータを一意のものと見なすための項目で主キーではない項目(テーブルの候補キー)に関してはユニーク制約とNULL可否(不可であること)で確認する。主キーはシステム的な理由(複合キーを避けるなど)でシーケンス番号を代替キーとしていることが多い。そのため候補キーを把握するのは大切なことだ。理由は三章で述べる。

5) テーブル同士の関連に関しては外部制約で確認する。関連がある・ないはE-R図を見た方が手っ取り早い。だがどの項目が外部キーとなっているのかはテーブル定義で確認する必要がある。

6) テーブル同士の関連多重度は外部制約のActionで確認する。Action定義自体はテーブル定義書にはないかもしれない。その場合はDDLで確認する。多重度は以下のようにして確認する。

  1.  ActionをnoAction/delete on cascadeとしている場合の多重度は1:Nである
  2.  Actionをset NULLとしている場合の多重度は0/1:Nである

7) データの形式や値域に関してはテーブル属性定義やテーブル属性説明で確認する。値域に関してはドメイン定義書が別途あると把握が楽で便利だ。

8) テーブル中の業務上必要な項目とシステム上必要な項目の区別に関しては属性のNULL可否とテーブル属性定義説明で確認する。業務上必要となる項目は本来NULLにはならないはずである。

9) 主キーの元で唯一定まる従属属性の確認に関してはテーブル属性定義で確認する。主キー以外の属性が従属属性である。なぜこのことを確認するのかというと、その主キーのもとでは従属属性は一つ以外の値を取れないという制約も確認できるからだ。

 例で示す。

例)  社員テーブル 主キー:社員番号 従属属性:所属部署 とシステム上で定義されているとする
     社員が所属する部署はこの場合一つのみとなる。
          もし社員が複数の部署に所属する場合このシステム上では複数の社員番号をその社員は持つことになる。

10) システム上重複がありえる項目の確認に関してはユニーク制約の有無で確認する。項目が主キーである場合は当然ユニーク制約が有である。

 これも例で示す。

例) 社員テーブルがあるとする。
   a) 主キーを名前としている場合そのシステム上では同姓同名を許さないということになる。
   b) 主キーを社員番号としている場合そのシステム上では同姓同名も許容するということになる。なぜならば社員番号が異なっていればよいからだ。

11) データに対するシステムの主要アクセスパターンに関してはインデックス定義で確認する。インデックスがあるということはその組み合わせのアクセスが多い証拠でもある。テーブル定義書内にインデックス定義がない場合はDDLなどデータベース定義で直接確認する。

 

 このようにテーブル定義書からはシステムの概要から詳細まで実に多くの仕様を読み取れる。だが、その分記載されている情報も膨大になる。ゆえにテーブル定義書から概要を把握するのは難しい。

 

2.2 E-R図

 E-R図には以下の情報が記載されている。

  • エンティティ名
  • エンティティの性質(依存か非依存か)
  • エンティティ間の関連
  • 関連の多重度
  • 主キー
  • 外部キー
  • 代理キー
  • エンティティの属性
  • スーパタイプとサブタイプ

 少し補足する。

 エンティティの依存・非依存に関しては、ほかのエンティティが無いと存在できないエンティティを依存エンティティと呼び、ほかのエンティティが無くても存在できるエンティティを非依存エンティティと呼ぶ。

 代理キーに関しては、本来存在する主キーの代わりに実装上の都合から追加したキーをそう呼ぶ。たとえば複合主キーの変わりに主キーとして定義したシーケンス番号が代理キーである。

 スーパタイプとサブタイプのことだがいわゆる親子関係のことである。親はエンティティの共通的な性質を持ち、子がその親の性質を受け継ぐ。スーパタイプが親であり、サブタイプが子である。

 なお、サブタイプの種類としては

  1. 排他的(OR): 常に一つのサブタイプのみに属する
  2. 包括的(AND): 複数のサブタイプに属する

 というものがある。

 排他的の例)「契約」は「書面」か「オンライン」のどちらかである
 包括的の例)「社員」は「運用者担当者」でもあり「サポート担当者」でもある
 ※E-R図の記法であるIDEF1X記法には他にも確定的・未確定的というサブタイプの種類があるがここでは割愛する。

 実際にテーブルを定義するときにはスーパタイプとサブタイプを統合して一つのテーブルとすることが多い。 統合したテーブルはある項目が特定の値を取る時のみ設定されるような項目を持つ(要するにNULL可の項目となる)。

 

 また、E-R図には表現のレベルがあり、それぞれ概念モデル・論理モデル・物理モデルがある。

 概念モデルは名前のとおりシステムが持つ本質的なエンティティの関係を記載したモデルである。

 論理モデルは概念モデルを詳細化したもので、物理モデルは論理モデルを実際のテーブルへ展開するために作成するものである。

 テーブルを定義するRDBMSに論理モデルは依存しないが物理モデルは依存する。このため、論理モデルから物理モデルを作成するときに実装上の都合で変更したりする。代理キーの作成やスーパタイプとサブタイプの統合がその作業に相当する。

 上記にE-R図に記載される情報を示したが、モデル毎に記載される範囲は異なる。

 概念モデルでは、エンティティ名・エンティティの性質・エンティティ間の関連・関連の多重度を記載する。

 論理モデルでは、エンティティ名からスーパタイプ・サブタイプまですべてを記載する。

 物理モデルでは、スーパタイプ・サブタイプ以外のすべてを記載する。

 これらの記載情報を元に以下のようなシステムの仕様を読み取っていく。

  1. 業務上重要なデータ群
  2. 本来の主キー
  3. エンティティの性質を表す重要な属性
  4. システム系テーブルの区別
  5. データが成立するための事前条件
  6. データ間に存在する依存関係の条件
  7. データ間に存在する依存関係の意味
  8. エンティティが持つ種類
  9. 特定の条件にのみ成立する関連
  10. エンティティ内の制約条件

 

上記は以下のようにして読み取る。
1) 業務上重要なデータ群に関しては概念モデルのエンティティ定義で確認する。概念モデルで登場するエンティティは業務上必要なものだからである。

2) 本来の主キーに関しては論理モデルのエンティティ定義で確認する。2.1のテーブル定義では主キーは代替キーとなっていることが多いと述べた。一方論理モデル上では代替キーとなっていないのでそれで確認できる。

3) エンティティの性質を表す重要な属性に関しては論理モデルのエンティティ定義で確認する。E-R図上に属性すべてを記述するのは現実的ではないためある程度絞っている。逆にいえば記載されているのはそのエンティティの主要な属性ということになる。

4) システム系テーブルの区別に関しては概念モデルと論理モデルの差分で確認する。概念モデルにあるエンティティが業務上必要なものである。そのため論理モデルで増えたエンティティを見ればシステム系テーブルかどうかは調べやすい。

5) データが成立するための事前条件に関してはエンティティにおける依存・非依存の性質で確認する。

  1. ◯◯はXXがない場合は存在しない(◯◯がXXに依存する場合)
  2. △△はXXがなくても存在する(△△がXXに依存しない場合)

ということが依存・非依存の関係からわかる。

6) データ間に存在する依存関係の条件に関しては関連の多重度で確認する。

 あるエンティティAとB間に存在する関連の多重度をm:nとする。

 m=1:nである場合AとBの条件は以下のようになる。

  1. Aの条件)
    1. Bのレコードに対応するAのレコードが必ず一意に定まる
  2. Bの条件)
    1. B中にはAに対応しないレコードが存在しない。ということはAがないとBは作れないことになる。
    2. N>=1である場合、Aに存在するレコードに対応するレコードがB中には必ず存在する
    3. N>=0である場合、Aに存在するレコードに対応するレコードがB中には存在しないこともあり得る。

 一方m=0 or 1:nである場合AとBの条件は以下のようになる。

  1. Aの条件)
    1. Bのレコードに対応するAのレコードが一意に定まる。だが対応するAのレコードが存在しないこともあり得る。
  2. Bの条件)
    1. B中にはAに対応しないレコードが存在することもある(NULLなど) 。ということはAがなくてもBは作れることになる。
    2. N>=1の場合とN>=0である場合との条件は1:nの時と同様である 

 m:nとなる場合、お互いのレコードに対応するレコードがそれぞれ複数存在することになる。なお物理モデルでは最終的にこれが無くなるようにモデルを作成していく。

7) データ間に存在する依存関係の意味に関しては関連に付けられた名称で判断する。なお、エンティティ=名詞・属性=形容詞・修飾子・関連=動詞とすることで文章を組み立てるとシステムが扱う業務形態を表せる。

 例)社員(社員番号、名前)、部署(部署名、フロア名) 社員-関連:所属する-部署 多重度はN:N
{社員番号xxxで名前がyyyyである}社員は{部署名:zzzで所属フロアがyyyである}部署に所属する

8) エンティティが持つ種類に関してはサブタイプの種類で確認する。

9) 特定の条件にのみ成立する関連に関してはサブタイプが関連を持つかどうかを確認する。ビジネス上の制限となる関連なので重要だ。

10) エンティティ内の制約条件に関してはE-R図上のエンティティ定義で主キーと従属属性を確認する。エンティティ内の制約条件とは主キーの元に従属属性が成立する値は一つだけということである。また主キー以外の項目は重複があり得ることも確認できる。
これはE-R図を見なくてもテーブル定義書で確認できる。だがE-R図上では主キーは本来のものなのでE-R図で確認した方が誤解をしづらい。

 

2.3 実データ

 実データからも以下のような仕様は読み取れる。

  • システムが扱うデータの種類
  • 特定ロジックの判断基準

 システムが扱うデータの種類に関しては

  1. データの定義がある → 扱う対象である
  2. データの定義がない → 扱わない

 というようにして読み取る。

 特定ロジックの判断基準に関しては

  1. このテーブルレコードの組み合わせは有効と判断する → 許容リストなど
  2. このテーブルレコードの組み合わせは無効と判断する → NGリストなど

 として読み取る。

 ただしデータなので環境毎に差異があるかもしれない。あくまでも仕様の補足事項として確認する内容ではある。

 

2.4 まとめ

 テーブル定義書やE-R図は機能設計書に比べると文章は少なく定義の羅列が多いため読んでいて退屈でありわかりづらいかもしれない。だがこれらのドキュメントから読み取れる内容は上記で示したように膨大なものである。特にE-R図の内容をすべて文章化したらそれだけで分厚い設計書と化すことだろう。

 データはシステムの根幹をなすべきものである。故に概要を把握するためにはまずはデータのことを把握するべきなのだ。そして膨大な仕様を簡潔に記した図であるE-R図を見るのが最適なのである。

データ定義から読み取る仕様 1. はじめに

目次はこちら

1. はじめに

 プログラマとしてお仕事をする場合何らかのプロジェクトへ途中参加することが多いだろう。特に雇われの身ともなればプロジェクトに最初から参加することなんて稀だと思う。
 さて、プロジェクトに参加したときに最初にやることは対象のシステムがどんなものなのかという概要を知ることだろう。ただ、ふつうのプロジェクトならば最初に概要を説明してくれると思うが、システムの大まかな役割とシステムを構成するモジュールの役割を説明する程度で後はドキュメントを読んでおいてね で終わることも多いのではなかろうか。
 だが概要の説明は大雑把すぎるし、かといってドキュメントは無数にありどれを読んだものか迷ってしまう。え? 読むドキュメントがないって? その場合はソースファイルというドキュメントがあるじゃないか! ……それこそ膨大な量になるには違いないが。
 ドキュメントの数も膨大だが、その中身もまた膨大だ。テーブル定義を見てもテーブルは無数にあり、テーブルが持つ属性もまた無数にある。どのテーブルが重要なのか見当もつかない。とりあえず読んでは見るもののそのテーブルが使われてないとか一時保存用だったとかよくあることだ。
 そのため自分の担当する機能に関係がありそうなドキュメントから読んでいくことになる。あちこちドキュメントを見てソースを見て担当機能の概要を把握していく。そうして三ヶ月もすれば自分が担当する機能とそれに関連するモジュールに関しては概要をつかめているはずだ。おめでとう。ドキュメントをあちこち見た成果だ。だが全体としてはどうだろうか。未だ怪しい。そんな状況だったりしないだろうか?
 機能毎に詳細を把握してから全体の概要を把握していく。よくあるシステムの把握方法ではある。だがシステムを知る手段としては逆なのではないだろうか? 全体の概要を知ってから機能毎の詳細を知った方が理解も早くなる。
 ではシステム全体の概要を手っ取り早く知る方法はないだろうか? そんなことを考えて作ってみたのが本ドキュメントである。

さて、この文章の趣旨は以下のとおりである。

  • システムの概要を知るには概念モデルを見るのが最適だ
  • E-R図はシステムの仕様を簡潔に表現できるすごい図なのだ
  • E-R図もきちんとメンテナンスしようね!


そして以下のような方を読者層として想定している。

  • ER図? そんなもんデータベースからツールで自動生成すればいいじゃないか!と思っている人
  • テーブル定義の説明があれば図なんていらんでしょ 線を引くのも面倒いし と思っている人


 ちなみにER図? 何それ? と思ったからはまずはこちら「ER図」を見てみるとよいですよ。ER図における記号の意味を忘れたという方も同様にどうぞ。