はじめに
タイトルのとおり、RDBのデータモデリング・テーブル設計を行う際に参考にしている考え方と関連資料をまとめました。
P.S.
なんと本記事内でいくつか参考として挙げさせてもらっている増田さん・かとじゅんさん・奥野さん・そーだいさんからコメントいただくことができました。
本当にありがとうございます。
前提
RDBを採用するのは事実を無駄なく正しく記録するため
- 正規化、トランザクション、制約とデータ整合性
- 基本的には始めに理想として集合論・リレーショナルモデルに基づいて正規化を考え(論理設計)、パフォーマンスなどの現実問題に対して折り合いをつけていく(物理設計)
- 制約を最大限利用する
cf:
↑P91〜
↑P.29,41
↑P56〜
↑5章
↑P347～
情報とデータ
- データ：単なる事実の値→これを永続化して蓄えるものがRDB
- 情報：データから生み出される意味や目的のあるもの→RDBから情報を生成するのに適しているものがSQL
- つまりRDBの設計(データをどう正しく保存するか)とSQL(情報をどのように取得するか)は関連はあるが別の関心事である
cf:
↑P9
↑P26〜
↑まえがき
更新(UPDATE)は複雑さを生む
- そもそも集合論的に更新はない
- 更新には複雑なルールを伴うため、極力更新を避けられないか
- 更新と削除がなければ事実・データが失われることがない
- 思考の制約として更新と削除をしないと考えると見落としている概念やモデルを見つける事ができる
- という背景・考え方がある
cf:
↑6章
↑1章,7章
羽生章洋さん
佐藤正美さん
観点
典型的アンチパターンを踏んでいないか / テーブル・カラムの責務は適切か
- SQLアンチパターンやそーだい本、データベースリファクタリングに指摘されているような問題を踏んでいないか
- テーブルがファットになっていたり、1つのカラムが複数の意味を持ったり、複数のカラムを組み合わせることで初めて意味が成立するようなカラム持ったりしていないか
- 個人的にこれらは正規化と短絡的な更新を避けるようにしていればこうした問題を踏みにくいという印象を持っている
- アンチパターンとして紹介されているもの内、一部は時代的に古かったり賛否両論あるものも含まれているようなので鵜呑みには注意
cf:
↑監修者t_wadaさんのスライド
↑SQLアンチパターンの内容を紹介してくれている記事をたくさん書かれてらっしゃる方
↑そーだいさんのスライド。データベースリファクタリングやアンチパターン系のスライドで紹介されている。一見同じようなタイトルでも紹介されている中身が違ったりする。
↑P38
↑P82〜
↑7章
マスタとトランザクション
- エンティティの分類としてマスタとトランザクションは人によって定義が曖昧になるので、イベントとリソースで分類する方が良いのではという考え方がある
cf:
↑step2
↑P51〜
更新
- すべてのテーブルに更新ユーザー・日時は必要か
- テーブルを更新したい・ステータスが存在する・状態を持たせている→履歴や遷移の過程は残さなくて良いのか
- 更新日時が欲しい→イベントが隠れている
cf:
↑P15〜
↑P60〜
↑P108〜
↑P40〜
↑step3,4
削除
- 安直な削除フラグはアンチパターン
cf:
↑step4
↑P20〜
交差テーブル
- 単に2つのテーブル名を重ねているだけで概念が隠れてしまっていないか
cf:
↑step5
JOINと正規化
- flag or status & where VS Join
- 一般的にはflag or status & whereの観点の方が多い印象。
- テーブル分割とJoinによる設計を考えると今までとは違う景色が見えるかも。
- Joinは遅いとパフォーマンスの悪化を恐れて最初から正規化を避けていないか
cf:
↑P105〜
↑P98〜
↑5章
↑P319～
トリガー、ストアドプロシージャー、キャッシュ
- 安易にこれらを選択していないか(データベースリファクタリング的には終わったら消す前提でリファクタリングの過程でトリガーを用いるのはあり)
cf:
↑P53〜
↑P66〜
↑P330～
ID生成
cf:
インデックスとチューニング(主にMySQL)
cf:
そもそもRDBに保存すべきか
- パフォーマンス、データモデル構造の観点から適切な保存技術を検討する。
cf:
↑P23〜
↑P89〜
↑101〜
↑9章
その他観点
↑P223〜
↑P43〜
おわりに
こうしてまとめてみると川島さん、そーだいさん、増田さん、SQLアンチパターンあたりに強く影響を受けているなと思いました。
こうしてたくさんの資料を残してくださり、肩に乗せてくださっている巨人の皆様に改めて感謝申し上げます。
本当にありがとうございます。