開発現場にいると時々、スキーマという言葉を耳にします。この言葉は覚えておいた方がいいのでしょうか？
データベースを設計する上では、必須の知識になります。職場のエンジニアとの会話が成立しなくなる恐れもあるので、絶対に理解しておいた方がいいです。
この記事で身に付くこと
- スキーマとは何かがざっくり理解できる
- データベース設計する際に、自分がどのレベルの設計をしているのか客観的に理解できる
スキーマとは何か
スキーマとは「データベースの構造や設計、関係性を定めたもの」です。言い換えれば「データベースの設計書」とも言えます。
「データベースのスキーマってどうなっているの？」と聞かれたら、「データベースの構造や設計ってどうなっているの？」と聞かれているということです。
このスキーマは、構造や設計のレベルにより大きく３つに分けて考えられています。
- 概念スキーマ
- 内部スキーマ
- 外部スキーマ
「おいおい！いきなり難しくなったよ。突き放さないでくれよ！！」と私はスキーマを学習するときに思ったので、かみ砕いて説明します。
データベースを設計するときには次の３ステップを踏みます。
- データベースの要素や関係性をどのようにしようか：概念スキーマ
- カラム名はどうしようか、インデックスは張ったほうがいいのか：内部スキーマ
- ユーザーが利用しやすい抽出データはどんな形か：外部スキーマ
まだイメージしにくいので、店でカレーを提供することに例えてみます。
- カレーにはじゃがいも、にんじん、豚肉、たまねぎ、ルーや炒める工程が必要。カレーの付け合わせに漬物も必要：概念スキーマ
- ルーは「ジャワカレー」、じゃがいもは「北海道産」、玉ねぎは30分弱火で炒める。漬物は福神漬けにしよう：内部スキーマ
- カレーと福神漬けはセットで盛り付けよう：外部スキーマ
ここでのポイントは1→3の流れでより具体的になっていることです。
いきなりカレーの具材を買って料理するのではなく、必要な具材・料理工程・盛り付けをあらかじめ考えたうえで、具体的な具材を購入して調理を始めるイメージです。
1.はカレーを提供するのに必要な要素や付け合せを食材などの制約なしに考えています。
2.は「ジャワカレーや玉ねぎを30分炒める」のように具体的な内容や制約を考えています。
3.は、カレーと福神漬けを組み合わせることで、料理の質を高めています。
このイメージを持ったまま、もう少し具体的にスキーマを見ていきます。
概念スキーマ
概念スキーマとは「データベースの関係性や内容を考えたもの」です。
社員情報を管理したい場合を考えてみます。
この時概念スキーマとは、社員情報には「氏名とメールアドレスと部署名が必要だ」「部署名は別のテーブルで管理して、社員情報とは切り分けた方がよさそうだ」と考えることです。
さきほどのカレーの例で「カレールーの種類や炒める時間や方法を決めなかった」のように、この段階では、データベースサーバーの性能やデータ型などの制約は考えません。
名前はメールアドレスにはmailというカラム名、重複してはいけないから一意性制約が必要だとは考えないわけです。
外部スキーマは、机上でデータベースの設計を考えることなので「論理設計」とも呼ばれます。
勘のいい方は気づいたかもしれませんが、ここで行う工程が、エンティティの定義や正規化、ER図の作成といわれるものになります。
内部スキーマ
内部スキーマとは「具体的なテーブル定義」です。
概念スキーマで定めたデータベースに必要な項目や関係性をもとに、具体的なテーブル定義を決めます。カラム名やデータ型を決めたり、インデックスを張るか決めたりします。
名前はメールアドレスにはmailというカラム名、重複してはいけないから一意性制約を入れよう。部署名は別のテーブルだから社員情報では外部キー制約をかけたほうがいいな。という具合です。
この工程は、先ほどの論理設計と対比して「物理設計」と言われます。データベースに実際必要な項目を決めているからです。
外部スキーマ
外部スキーマとは「データベースから必要なデータを抽出した結果」です。
ユーザーに情報を表示するときは、社員情報を表示するときは、氏名とメールアドレスだけでなく、部署も表示させた方がわかりやすいから、一緒に表示させようとするものです。
| 社員id | 名前 | メールアドレス | 部署名 |
| 1 | 山田 太郎 | tyamada@gmail.com | 総務部 |
| 2 | 佐藤 次郎 | sato@gmail.com | 営業部 |
| 3 | 田中 花子 | tanaka@gmail.com | 営業部 |
SQLの世界で、外部スキーマを「ビュー」と呼びます。MVCモデルのビューはユーザーが操作する見た目の画面ですが、SQLのビューはユーザーが見やすいようにデータベースから抽出したデータだと言えます。
概念スキーマがなぜ必要なのか
概念スキーマってそもそも必要なのか？と思った方もいるのではないでしょうか。
やはり概念スキーマは必要です。その理由は、概念スキーマがないと「変更に対する柔軟性」がなくなってしまうからです。
「変更に対する柔軟性がない」とは、ユーザーが利用する抽出データを変更したい（外部スキーマを変更したい）と思ったときに、テーブル定義（内部スキーマ）まで変更しなければならず、変更が容易にできない状態を指します。
概念スキーマを飛ばして、内部スキーマをつくってしまうと、概念スキーマでテーブル間の関係性を考える工程が抜けているため、内部スキーマで作製したテーブル構成が、そのまま外部スキーマとしても使われがちになります。
概念スキーマの段階で柔軟性を持つようにテーブル間の関係を整理しておけば、必要な抽出データを変更したいと思ったときに、テーブル定義を変更することなく、抽出方法を変えるだけで、データを取得することができるのです。
まとめ
スキーマとは「データベースの構造や設計、関係性を定めたもの」です。
その構造や設計はレベルにより大きく３つに分けて考えられています。
- 概念スキーマ：データベースの要素や関係性をどのようにしようか
- 内部スキーマ：カラム名はどうしようか、インデックスは張ったほうがいいのか
- 外部スキーマ：ユーザーが利用しやすい抽出データはどんな形か
概念スキーマが必要な理由は「変更に対する柔軟性を高めるため」でした。
ここまでざっくり、かみ砕いて説明してきました。もっと詳しく知りたい方は、今回参考にさせていただいた、「達人に学ぶDB設計 徹底指南書」をお読みいただけるとより理解が深まりますので、ぜひ読んでみてください！
コメント