あまブログ

ドキドキ......ドキドキ2択クイ〜〜〜〜〜〜〜ズ!!

【書籍まとめ】楽々ERDレッスン

楽々ERDレッスン (CodeZine BOOKS)

こちらの書籍は第3部の演習問題を解くことがとても重要です。

(1問目2問目は無料で公開されています。)

DB設計の基本

  • データベース設計の要点は「One Fact in One Place」=「1つの事実は1つの場所にのみ存在する」
  • データベース設計は「データ構造の部品化」

  • 正規化のポイント

    • IDの導入
      • 顧客コードや顧客名には意図があり、その意図が変更されると値も変更される。
      • そこで意図とは関係なく、「レコードが存在している」ということだけを表現する識別子であるID(Identifier:アイデンティファイア)を定義する。
      • そうすることでレコード間の関連付けにおいて洗い替えなどの問題が起こらなくなる。
    • 業務の視点からの正規化
      • 値も見る

DB設計のポイント

  1. 箱(エンティティ)の見出し方
  2. キーの設定
  3. 重複の排除(正規化)

1. 箱(エンティティ)の見出し方

エンティティとは

  • 何かの集合 = 箱をイメージ
  • エンティティ = 教室
    • それぞれのクラスには生徒がたくさんいて、どこにいても同じクラスの人同士であることは変わらない。
    • いつも広い校庭でバラバラになっていると見分けがつかないので、普段は教室に入る。この教室がエンティティ。

エンティティの分類

  • リソース系エンティティ
    • 「モノ」に関する記録
    • 誰に(Whom)・誰が(Who)・何を(What)・どこ(Where)
  • イベント系エンティティ
    • 「出来事」に関する記録
    • どのように(How)

ビジネスの流れとデータモデル

  • エンティティ名を並べていくと、ビジネスの流れとデータモデルが合致しているか、漏れ・不足はないかがわかる。

    • 「顧客に・商品を・販売する」で意味が通るか確認する
  • 積極的に業務要件を拾い、分類に困るものはまずは一番似合いそうなエンティティに放り込む(とりあえずエンティティを洗いだす)

    • 「必要な項目が存在しない」ことに気づくのは難しいため

2. キーの設定

キーとは

  • あるデータを特定する・あるデータに到達するための手がかり

  • 主なキーの種類

    • 主キー
      • 候補キーの中から何らかの意味的に選択された、インスタンスを特定可能な識別子
      • 物理的にはPRIMARY KEY制約
      • 実体はNOT NULLのユニークインデックス
    • ユニークキー
      • エンティティ内のインスタンスをそれぞれに特定可能な識別子
      • 実装上はユニークインデックス。対象のカラムにNOT NULL制約がなければNULLは許可される
    • 候補キー
      • エンティティ内のインスタンスをそれぞれに特定可能な識別子の「全て」
      • 実装上はインデックス
    • 外部キー
      • エンティティをまたがってのインスタンス同士の関係(参照整合性制約)

コードとキーの違い

  • コード = 「あだ名」、キーにはIDを使う
  • コード
    • 特定のインスタンスにたどり着くためのアクセスパス
  • ID
    • 別のレコードであることを見分けるための識別子
    • インスタンスを一意に特定する座標の役割
    • 外部キーとして参照すべきはID
  • IDという形でインスタンスごとの座標を明確にすることと、アクセスパスとしてのコード体系を分けて考える
  • 正規化のポイントである関数従属は、「キー」に対しての関数従属
    • 「ビジネス上の都合によるコード体系」に対して従属するのではない

3. 重複の排除(正規化)

  • どういうアウトプットが必要なのかがわからないと、本当の意味での正規化はできない
  • 重複とは「事実の記録が重複している」こと
    • 教科書的に重複しているように見えても、ビジネス上「別の事実」であればそれは重複ではない
  • 複雑なビジネスルールはそれなりに複雑なデータ構造になる
    • DB設計を簡単にすれば、プログラム設計が複雑になるだけ
  • まずは正規化する対象を洗いだし、そこから正規化をする
    • 正規化した結果、エンティティ数が膨大になっても、それが現在のビジネスルールの実態なのだと認識する

DB設計の手順

設計工程の中で手戻りが出るのは大前提

  1. イベントを見出す
  2. リソースを抜き出す
  3. 項目を入れていく
  4. リレーションシップを設定する

1. イベントを見出す

  • メインとなるテーブル名を出す
  • 「~する」という言い方ができるイベント系のエンティティを見出す

2. リソース抜き出す

  • 「誰が」「何を」を考える
  • リソース系のエンティティを見出す
    • イベント系→リソース系の順番で考える(リソース系は複雑なデータ構造を持つことが多いため)

3. 項目を入れていく

  • 各テーブルのカラムを入れる
  • この時点で表現できていない情報があれば、テーブルになるか、カラムに追加するか考える

4. リレーションシップを設定する

  • 主キーを決める(IDを導入)
    • Railsの場合、自動でidが主キーとして生成される
  • 外部キー制約をつける
    • Railsの場合、<テーブル名>_id
  • 多対多の時は中間テーブルを作る

【参考】