達人に学ぶDB設計を読み終えたので忘れないうちに学びをアウトプットしていきます。
この本は設計の本なのですが、正規化とかER図とかの教科書的な説明にはとどまりません。
具体例を交え、なぜそうするべきなのか、そうしなかった場合にどんな問題が起こるのかといったことを様々な角度から教えてくれます。
また、設計において切り離せないDBの内部的な構造についても触れていますので(オプティマイザとか統計情報、効率的なクエリの書き方など)、SQLはなんとなく書けるけど「性能を考慮する」とか「DBの裏側で何が行われているのかまではわからない」といった人にもおすすめです。
本書の帯通り、初級者から中級者にステップアップしたい方に非常におすすめできる本です。
今回はDB設計における3層スキーマの概念について見ていきます。
3層スキーマ
DBの設計上の概念として、
・外部スキーマ
・概念スキーマ
・内部スキーマ
と呼ばれる3つのスキーマが存在します。
これらを合わせて3層スキーマと呼びます。
外部スキーマ
外部スキーマとはユーザーから見たデータのことを指します。
例えば、ECサイトの注文管理画面であれば、
注文ID、注文日、顧客ID、顧客名、住所、商品、個数、値段…
などのデータが見れます。
これらは当然一つのテーブルではありません。
受注テーブル、顧客テーブル、商品テーブルなどを結合し、見せるために加工したデータになります。
このようにユーザーが最終的に使うためのデータの構造を外部スキーマと言います。
概念スキーマ
概念スキーマとは、外部スキーマをDB上で扱いやすくするために重複の排除や項目の分割などを行ったものになります。
なぜ、そのようなことを行うのでしょうか。
例えば、先ほどの例の外部スキーマを一つのテーブルとして持っていたとします。
ここで商品の名称が変わったとします。
そうした場合、たくさんのレコードの商品名を変更しないといけなくなります。
これはDBの処理として負荷が高いですし、更新漏れなども発生する可能性があります。
データをきれいに保つのに非常にコストがかかるということになります。
では、商品を別のテーブルとして持つとどうでしょうか。
そうした場合、それぞれの注文は商品テーブルを参照することになります。
参照しているのは一つの商品です。
つまり、商品の名前が変わった場合は、商品テーブルのその商品の名称だけを変更すれば済みます。
コストも低いし、更新漏れも発生しません。
このようにDBとして扱いやすいようにテーブルを分割、統合する作業を正規化と言います。
つまり、概念スキーマは外部スキーマを正規化したものということができます。
内部スキーマ
内部スキーマとは、概念スキーマで正規化したテーブルをDBの物理的なデータに置き換えたもののことを指します。
概念スキーマを内部スキーマに変換するためには、テーブルのカラムやデータ型、データ長を決めたり、どこにインデックスを張ったり、テーブルサイズを決めたりといった作業を行っていきます。