データベース設計について、フェーズ毎に先人達のURLをまとめたり、要約してみたり、個人見解してみたりしてみた。
URLがリンク切れになっている場合は、ドライブに保存してあるpdfを参照すること
論理設計(概念スキーマ)
エンティティの抽出〜エンティティの定義
参考
URL
- イベント系先行パターン
- リソース系先行パターン
書籍
要約
エンティティの抽出
・エンティティの抽出とは、どういうエンティティ(テーブル)が必要か決めるフェーズのこと。この時点では、細かいカラムまで決めなくてもOK。
・エンティティの抽出方法は、「トップダウン」と「ボトムアップ」がある
・リソース系(物理的なもの)を先に抽出するべきか、それとも、イベント系(概念的なもの)を先に抽出するべきかは人によって違う
エンティティの定義
・エンティティの定義とは、エンティ(テーブル)がどのようなカラムを保持すべきかを決めるフェーズのこと。
・実務では導出項目排除を考えながら作業するよりも、全部の項目を抽出してから導出項目を排除する方が安全である。
個人的見解
エンティティの抽出方法は、個人的には、粒度の大きいイベント系(概念的なもの)なものから先に抽出する方法がやりやすいと感じた。
正規化
参考
URL
- 数学的正規化
- 業務的正規化(非正規化)
書籍
要約
正規化には、「数学的正規化」と「業務的正規化(非正規化)」がある。
非正規化が有効と考えれるケース
・繰り返し列の場合でも明らかに多くの列数を要しない場合
・更新頻度の低い演算結果を記録する場合
・過去のデータを上書きせずに残す場合
ER図作成
「IE」「IDEF1X」記法がある
物理設計(内部スキーマ)
テーブル定義
いわゆるテーブル定義書やDDL、LaravelでいうMigrationクラスにあたるものを定義する
インデックス定義
参考
URL
書籍
要約
インデックスをどの列に作れば良いか
・大規模なテーブルに対して作成する
環境要因にもよるが、目安としては、レコード数が1万以下の場合は、インデックスの効果はない
・カーディナリティの高い列に作成する
全体のレコード数の5％程度(5～15％)に絞れるかどうか
・SQL文でWHERE句の選択条件、または結合条件に使用されている列に作成する
インデックスが効かない場合
・LIKE述語の中間一致、後方一致
・インデックス列で演算を行っている
・インデックス列に対してSQL関数を使っている
・IS NULLを使っている
・ORを使っている
・否定形を使っている
・暗黙的な型変換を行っている
ハードウェアのサイジング
no text
ストレージの冗長構成決定
no text
ファイルの物理配置決定
最近は意識しなくても良くなっているとのこと
その他参考
参考
コメント