正規化を行う意義

• 更新時に1行で済む
  もし正規化されていなければWHEREを利用した該当レコードについて全行更新が必要になる。
• データの整合性
  正規化されていると更新時に親子テーブルでデータの整合性がとれるので、データ構造が壊れない設計になる
• データの可読性
  ER図で可視化できる、わかりやすくなる

 

注意

• 正規化は可逆的なもの
  正規化されたテーブルは、非正規化されたテーブルに復元できるようにする。

テーブルをわけて正規化する時は、結合によって戻せるかどうかをきちんと試すこと。戻せなければその正規化は間違っている。

 

ワンポイント

• 意味は出来るだけ分割して登録する
  yuu@example.net →ユーザ：yuu, ドメイン：example.netに分離してカラムに登録する
  山田太郎 → 姓：山田, 名：太郎
• 履歴データはそのままで
  履歴データは正規化しないことが正規化、
  また履歴データはRDBに向いていないのでElastisearchなど他ミドルウェアに入れても良い。

 

 

正規化のデメリット

• 正規化を行うことでJOINが増えるので、SELECT時の検索性能とのトレードオフが発生する

 

 

 

対策(グレイパターンでデメリットがある)

• キャッシュ
  劇薬である。
• サマリテーブル(データマート)
  １日に一回集計を行うデータなどで対応
• 水平分割
  ID単位、年、月単位で分割する
  →RDBMSのパーティショニング機能で対応する
  デメリットとしてパーティショニングを管理しなくてはいけなくなる。
• 垂直分割
  SELECTが行われるものを垂直に切ったテーブルを用意する、
  またはテーブル単位でDBを分割する
  →シャーディングで対応

 

分割のデメリット

• 分割されたDB同士でJOINが出来ない。
  →マスターデータは全DBで持つなどする

 

 

 

第1正規系

 

• セルに１つだけ値が入っている状態
• 重複がない

 

これの反対に１セルに複数値が入っているパターンをジェイウォーク(信号無視)

 

第2正規系

 

• 主キーに対する関数住従属性が１つだけの状態
• 推移的関数従属性があっても良い

 

 

第3正規系

 

• 第２正規系かつ、推移的関数従属もない状態

 

 

ボイスコッド正規系

第３正規系を強化したもの。第３正規系まで行いボイスコッド正規系まで行う。

※間違ったテーブルの分け方をすると元のテーブル(第3正規系)に戻せない