【読書感想ブログ】 達人に学ぶDB設計徹底指南書
はじめに
自分はデータベースとは無縁の仕事をしてるんだけど、WEB開発に興味があって、WEB開発するにはデータベースを勉強しないとな、ということで勉強している。
今までに購入したデータベース本(SQL本)は以下の3冊、読んだかどうかすでによく覚えていない。もしかしたらそのうち再読するかも？
そういう状態なので、今回読んだ以下の本は新鮮な気持ちで読めたので良かった。内容もSQLに依らずデータベース全体の話（論理設計に主眼が置かれている話）だったし、作者の説明が丁寧でスラスラ読めた。
どういう人が読む本か
データベースの論理設計を学びたい人が読む本かと。SQLのことはあまり出てこないのでSQLの文法とかそういうのを知りたい人は別の本を読んだほうがいいかもしれない。論理設計だけではなく、物理設計のことにも言及しているのでデータベースの下回りのことも知れる本なので、そういうことが知りたい人も読むとよいかもしれない。
個人的に気になった点
3層スキーマ
データベースを設計するときに、「外部スキーマ」「概念スキーマ」「内部スキーマ」の3層に分けて設計する方法があるということを初めて知った。
という切り分けらしい。
何故「概念スキーマ」があるのか、「外部スキーマ」と「内部スキーマ」のみの2層スキーマではないのかというと、何かデータベースを変更したいとなった場合に、変更に対する柔軟性がない というのが理由らしい。 2層だと「外部スキーマ」を変更した場合「内部スキーマ」も変更をする必要がある場合が多々あり、その逆もまた然りということになるので「概念スキーマ」を導入して 緩衝材として使用する ことで変更に柔軟に対応できるようにしているということらしい。プログラミングにも「ビュー」と「ロジック」を分けるときに「MVC」モデルだったり「MVVM」モデルだったりを使うけど、その場合も「M」と「V」の間に「C」だったり「VM」だったりを挟んで緩衝材を作るのと似ている気がする。
バックアップ設計
バックアップの手法には「フルバックアップ」「差分バックアップ」「増分バックアップ」があるとのことで、「フルバックアップ」はわかったんだけど「差分バックアップ」は認識が間違っていて、僕が認識していた「差分バックアップ」が「増分バックアップ」であるという気づきがあった。
- 「フルバックアップ」は常にデータベース全体をバックアップするというタイプ
- 「差分バックアップ」はフルバックアップからの変更分をバックアップするタイプ。例えば、毎日の終わりに差分バックアップが実行されるようなシステムの場合は、月曜日にフルバックアップが行われて、火曜日移行は月曜日のフルバックアップからの差分がバックアップされるようになる。なので変更がどんどん累積されてバックアップされるようになる。
- 「増分バックアップ」はその日の変更分のみをバックアップするタイプ。先の例のシステムだと、月曜日にフルバックアップが行われた後は、その日の変更のみがバックアップされる。
一般的には「フルバックアップ＋差分バックアップ」か「フルバックアップ＋増分バックアップ」の組み合わせでバックアップされるらしい。
リストア・リカバリ・ロールフォワード
- バックアップファイルを戻すことを リストア
- 差分(または増分)バックアップをしていたトランザクションログを適用して変更分を反映する作業を リカバリ
- データベース内部に残っているトランザクションログを適用する作業を ロールフォワード
と言うそうです。違いがあるとは知らなかった。
正規化
第一正規形
第一正規形の定義は「一つのセルには一つの値しか含まない」らしいです。当たり前ですが、大事なことですよね。
第二正規形
第二正規形の定義は「テーブル内で部分関数従属を解消し完全関数従属のみのテーブルを作ること」らしいです。
部分関数従属というのがいまいちわかってないですが、主キーの一部をその列で置き換えても成り立ってしまう、要は意味的に重複している列が存在しているということなのかな？と思っています。
第三正規形
第三正規形は「テーブル内の推移的関数従属が解消されたテーブル」ということらしいです。
主キー以外の列で意味的に重複している列が存在しないように作成するのがミソのようです。
正規化とパフォーマンス
正規化を行うとテーブルが分かれてしまうわけなので、もともとのテーブルを作成しようとしたらテーブルの結合が必要になりその文パフォーマンスが低下する場合があるらしいです。ただ、作者の方はパフォーマンスを犠牲にしても享受できるメリットのほうが大きいとして、正規化はできるだけやったほうがいいと言われています。また、正規化を行ったうえでパフォーマンスに影響しない工夫についても言及されていました。
パーティション
論理設計のバッドノウハウの章で紹介されていた 水平分割を回避するテクニックとして DBMSが持っている昨日の一つ「パーティション」を利用するというもがあるようです。このような機能があることを知らなかったので勉強になりました。
まとめ
ミックさん著の『達人に学ぶDB設計徹底指南書』を読んだ感想を書いてみました。上記の気になった部分以外にも「バッドノウハウ」「グレーノウハウ」「木構造をデータベースで表現するには」という章は「ほ～」「へぇ～」の嵐でした。一読の価値ありです。全部紹介していると書面まるまる引用することになりそうなので、ぜひご自身で読んでみて「なるほど～」と思っていただければと思います。
