達人に学ぶDB設計徹底指南書を読んだ感想
はじめに
今回は達人に学ぶDB設計徹底指南書を読んだ感想をまとめていきたいと思います。
DB設計未経験の自分でも理解しやすい本でした！
各章の感想
第1章 データベースを制する者はシステムを制す
この章では、システム開発の設計工程とデータベースについて学ぶことが出来ました！
DOAとPOA
DOA：データ中心アプローチ(Data Oriented Approach)
POA：プロセス中心アプローチ(Process Oriented Approach)
最近では、プログラム設計に先立ってデータ設計が優先されるDOAが中心となっている
3層スキーマ
外部スキーマ：ユーザーから見てデータベースがどのような機能とインターフェイスを持っているか定義する
概念スキーマ：データベースに保持するデータ要素及びデータ同士の関連を記述する
内部スキーマ：論理データモデルを具体的にどのようにDBMS内部に格納するかを定義する
概念スキーマの存在意義
→外部スキーマと内部スキーマ間で互いに影響し合わないよう、データの独立性を保証する
設計の工程や流れについて詳しく説明されており良いと思いました！
第2章 内部スキーマと物理設計
この章では、物理設計やバックアップについて学ぶことが出来ました！
RAID
RAID：システムの信頼性と性能を共に改善する技術
| 種類 | 内容 |
|---|---|
| RAID0(ストライピング) | データを異なるディスクに分散して保持する |
| RAID1(ミラーリング) | 2本のディスクに同じデータを保持する |
| RAID5(パリティ分散) | 最低3本で構成し、データとパリティ(誤り符号訂正符号)を分散して格納する |
| RAID10 | RAID1とRAID0を組み合わせたもの。必要になるディスク数が多くなるためコストが高くなる |
データベースのRAIDは最低限RAID5で構成する。余裕があればRAID10を選択する
バックアップ
フルバックアップ
ある時点でシステムの保持されているすべてのデータをバックアップする方式
利点
欠点
- バックアップ時間が長い
- ハードウェアリソースへの負荷が高い
- サービス停止が必要
差分バックアップ
フルバックアップからの変更分をバックアップする方式
利点
欠点
増分バックアップ
前回おこなわれたバックアップからの変更分をバックアップする方式
利点
- バックアップファイルの大きさが小さくなる
- バックアップ時間を短くできる
欠点
- リカバリ時に全ファイルが必要となる
一般的には、「フルバックアップ＋差分バックアップ」または
「フルバックアップ＋増分バックアップ」のバックアップ方式をとる
表や図を用いて説明されており、とても理解がしやすかったです！
第3章 論理設計と正規化
この章では、テーブルの構成要素やテーブルの正規化について学ぶことが出来ました！
キー
主キー(プライマリキー)：レコードを一意に識別するためのキー
外部キー：二つのテーブル間の列同士で設定するもの
正規化
第一正規形
一つのセルの中には一つの値しか含まない(スカラ値の原則)
主キーは一部であってもNULLを含んではいけない
第二正規形
テーブル内で部分関数従属を解消し、完全関数従属のみのテーブルを作る
部分関数従属；主キーの一部の列に対して従属する列があること
完全関数従属：主キーを構成するすべての列に従属性があること
第三正規形
テーブル内の推移的関数従属を解消する
推移的関数従属：テーブル内部に存在する段階的な従属関係
ボイスーコッド正規形
第三正規形をより厳密にしたもの
すべての列が主キーに完全関数従属で、他に完全関数従属関係がないもの
第四正規形
関連エンティティに含まれる関連を一つだけにする
第五正規形
関連がある場合は、対応する関連エンティティを作成する
SQLの本では出てこなかった、第四正規形や第五正規形についても説明されており
正規形についてより詳しく学ぶことが出来ました！
第4章 ER図〜複数のテーブルの関係を表現する
この章では、ER図の描き方を学びました！
ER図(Entity-Relationship Diagram)：実体関連図
IE表記法
| 図 | 内容 |
|---|---|
| ◯ | 0 |
| ー | 1 |
 |
多 |
IDEF1X表記法
| 図 | 内容 |
|---|---|
 |
0以上 |
 |
1以上 |
 |
0または1| |
 |
n(特定の定数) |
多対多エンティティの関係にならないよう、関連実体を用いる
第5章 論理設計とパフォーマンス〜正規化の欠点と非正規化
この章では、正規化とパフォーマンスの関係について学ぶことが出来ました！
正規化の功罪
正規化と検索SQLのパフォーマンスはトレードオフの関係にある
正規化→データの不整合が起きにくいが、パフォーマンスが落ちる
非正規化→データの不整合が起きやすいが、パフォーマンスは上がる
非正規化とパフォーマンス
サマリデータや選択条件を保持すると、正規形に違反する形となるが、検索を高速化可能
→ただし、リアルタイム性という面では問題となる
正規形とパフォーマンスのバランスを判断するのが難しいと感じました！
第6章 データベースとパフォーマンス
この章では、データベースのインデックスと統計情報について学ぶことが出来ました！
インデックス設計
インデックスはパフォーマンス改善にポピュラーな手段。理由は以下の3点。
- アプリケーションのコードへ影響を与えない(アプリケーション透過的)
- テーブルのデータに影響を与えない(データ透過的)
- 性能改善効果が大きい
B-treeインデックスの設計指針
設計指針
- 大規模(レコード数が1万件以上)のテーブルに対して作成
- カーディナリティ(種類の多さ)の高い列に対して作成
- SQL文のWHERE句や結合条件に使用されている列に対して作成
統計情報の設計指針
設計指針
- データが大きく更新された後、なるべく早く更新する
- 統計情報の収集は、使用者の少ない夜間帯に実施する
第7章 論理設計のバッドノウハウ
この章では、やってはいけないデータベース設計について学ぶことが出来ました！
配列型による非スカラ値
- アプリケーションやミドルウェアも配列型に対応しなければならないためハードルが高い
- 第一正規形を優先する
ダブルネーミング
- 列は変数でないため、一度意味を決めると変更が不可
単一参照テーブル
- コード体系によって列長が違うため、余裕を見た大きめの可変長文字列型にする必要がある
- レコード数が多くなり、検索パフォーマンスが悪化する
- コードタイプやコード値を間違えて指定してもエラーにならずバグに気づきにくい
→テーブルにポリモーフィズムは不要
テーブル分割
- 分割する理由がない
- 拡張性に乏しい
- 他の代替手段がある(パーティション等)
不適切なキー
- 可変長文字列は普遍性がないためキーには向かない
- キーには固定長文字列のコード列が望ましい
ダブルマスタ
ダブルマスタ：同じ役割を果たすはずのマスタテーブルが2つ存在すること
2つのマスタテーブルを結合する必要があるため、パフォーマンスが落ちる
バッドノウハウを学ぶことで、どのような設計をすべきかをより理解することができたと感じました！
第8章 論理設計のグレーノウハウ
この章では、データベース設計におけるグレーノウハウについて学ぶことが出来ました！
オートナンバリング
主キーを一意に決められない場合に、オートナンバリングをキーとして扱う場合には注意が必要
- シーケンスとID列では、シーケンスの方が柔軟で拡張性に富む
- アプリケーション側でオートナンバリングを実装すると、排他制御等の考慮が必要となるので複雑となる
列持ちテーブル
利点
- シンプルな設計
- 入出力のフォーマットと合わせやすい
欠点
- 列の増減が難しい
- 無用のNULLを使用しなければならない
多段ビュー
- ビューはビュー定義のSELECT文を実行してオリジナルのテーブルにアクセスしている
- 多段になるとパフォーマンスが落ち、また仕様が複雑となり管理が困難になる
第9章 一歩進んだ論理設計〜SQLで木構造を扱う
この章では、木構造の論理設計手段について学ぶことが出来ました！
隣接リストモデル
ノードのレコードに親ノードの情報を持たせるモデル
特徴
- 木構造を表現する最も古くポピュラーな方法
- 更新や検索のクエリが複雑となり、パフォーマンスが悪い
入れ子集合モデル
ノードを円とみなし、ノード感の階層関係を円の包含関係によって表す
特徴
- 「左端」と「右端」の列によって階層関係を表す
- 親は自分の腹の中に子を抱え込む格好になる
- 更新処理はパフォーマンスが問題となる
入れ子区間モデル
円の左端と右端の座標値として取れる範囲を十数まで広げた集合モデル
特徴
- 理論上無限に追加可能
- 追加ノードの左端座標：
(plft * 2 + prgt) / 3 - 追加ノードの右端座標：
(plft + prgt * 2) / 3
経路列挙モデル
ノードをディレクトリとみなし、各ノードまでの経路を記述する
特徴
- ノード地震に親子関係が含まれているため、経路探索が簡単
- ユニークインデックスによる高速検索が可能
- 経路に主キーを使うと、文字列が長大となる恐れがある
- 経路に主キーを使うと、同階層内のノード同士の順序が把握できない
- パスに番号を使うと、ノードの削除、追加等の更新が複雑になる
全体の感想
- 具体例を用いて説明されており、とても理解がしやすかった
- アンチパターンも説明されているので、やらない方がいい設計への知見が得られ勉強になった
- パフォーマンス等の現実的な問題にも触れられており、より実務に生かしやすいと感じた
