RDB, SEノウハウ, システム設計

RDB 正規化

 

正規化を行う意義

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

 

注意

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

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

 

ワンポイント

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

 

 

正規化のデメリット

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

 

 

 

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

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

 

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

 

 

 

 

第1正規系

 

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

 

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

 

第2正規系

 

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

 

 

第3正規系

 

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

 

 

ボイスコッド正規系

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

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

 

 

 

Amazonおすすめ

iPad 9世代 2021年最新作

iPad 9世代出たから買い替え。安いぞ!🐱 初めてならiPad。Kindleを外で見るならiPad mini。ほとんどの人には通常のiPadをおすすめします><

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)