まとめ

• ドメインの設計は、現実世界とリレーショナルモデルの世界とをつなぐ架け橋となる作業

• 恣意的

  • 絶対的な正解はない
  • 最も難しい

• データの本質を理解することが重要

  • 本質的でないデータをDBに持ち込まない

    • 表示上の都合など

• リレーショナルモデルについての理解が不可欠

  • 例: IDに意味をもたせると1NFですらなくなる

ドメイン

1. アプリケーションにはどのようなリレーションが必要か？

2. リレーションにはどのような属性が必要か？

   • 決めなければならないことは2つ

     • 名前
     • ドメイン(データ型)

ドメインとは

• リレーショナルモデルにおけるデータ型

  • 属性が取りうる値の集合
  • 述語論理における「論理領域」に相当する

集合の要素

• 明確な値を持っていること

• 該当しないもの

  • NULL
  • ポインタ
• ドメインに含まれる可能性のある値をすべて列挙するのは無謀
• ドメインは集合なので、1:1対応する述語が存在する
• それがどのような意味を持つかを想定しておけば十分

ドメインの設計戦略の概要

• 「設計」

  • ノウハウや経験に基づく
  • 論理的に導出される絶対的な正解や筋道がない
  • 戦略や哲学が必要とされる

すべては恣意的な選択

• ドメインを定めるのは設計者の主観

  • 宇宙の摂理ではない

• 最終的にはSQL上で表現する

  • カラムの値がドメインの要素と対応するようカラムを設計

アプリケーションの要求から生まれる

• アプリケーションが必要とするデータを洗い出さないとドメインの設計はできない

  • DB全体の設計にもいえること
  • DBについていくら勉強しても身につくものではない

• 適切なDB設計は、アプリケーションに対する理解なくしては有り得ない

  • のでアプリケーション開発者が少なくとも関与できるべき

• アプリケーション設計手法を身につけておくべき

  • DDDとか

• DBリファクタリング

  • アプリケーションは何度もリファクタリングする

  • DBもリファクタリングが当然必要

    • DBもアプリケーションの一部

データの本質を見極める

• 数値に文字列カラムを割り当てる過ち

  • 学籍番号など、本質は数値であるもの

  • 表示上の都合でCHAR(8)とかにするな

    • 本質的なデータと表示は分けて設計すべき
    • DBが引き受けるべきは前者のみ

属性(カラム)の名前

• 名が体を表せ

  • DBに限らない

• アプリケーション内で対応するクラスや変数と同じ名前をつけるべき

  • アプリケーション側でクラス名や変数名をリファクタリングしたら、DB側も同期せよ