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

Jの衝動書き日記

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

データ定義から読み取る仕様 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可能項目は、項目の設定は任意・ある特定の条件の場合は設定されるが条件に一致しないときは決して設定されない・ 設定されるタイミングが異なるというように満たす条件が異なるため区別がつきにくい