はじめに
「データベースの3層スキーマって、要するに何？」
そう聞かれたときに、サクッと答えられるようになりたくて本記事を書きました。
3層スキーマとは？
データベースの構造を３つに分けて定義しましょうという考え方。
参考：
https://wa3.i-3-i.info/word13664.html
データベースの世界では、データの持ち方（物理的な保存方法）と、見せ方（アプリケーション側での利用方法）を切り離すことが至上命題です。これを実現するのが ANSI/SPARC モデル、通称「3層スキーマ」です。
1. 外部スキーマ (External Schema)
-
役割: 「利用者（アプリケーション）からどう見えるか」を定義するもの。
- Web 開発でいうところの View、あるいは API のレスポンス形式 に相当します。
- 特定のユーザーや画面にとって必要なデータだけを、使いやすい形（ビューなど）で切り出したものです。
- 「個別の都合」に合わせたデータの窓口です。
2. 概念スキーマ (Conceptual Schema)
-
役割: 「データの本質的な構造（真髄）」を定義するもの。
- ER図（テーブル定義） や、ORM（ActiveRecordなど）のモデル定義の基盤 となるものです。
- 「どのテーブルにどのカラムがあるか」「テーブル間のリレーションはどうなっているか」という、データベース全体の論理的な構造を記述します。
- 外部スキーマと内部スキーマを橋渡しする、データの核となる部分です。
3. 内部スキーマ (Internal Schema)
-
役割: 「物理的にどう保存するか」を定義するもの。
- インデックスの設定、パーティショニング、データファイルの配置、圧縮方法 など、ストレージ層に近い領域です。
- 「HDD や SSD のどこに書き込むか」等、物理的な設計を担当します。
まとめ：
なぜデータベースを「3層」に分けるのか？
一言でいうと、「一方を変更しても、他方に影響を与えない（＝データの独立性）」 を実現するためです。
| 独立性の種類 | 要するに？ | 具体的なメリット |
|---|---|---|
|
物理的データ独立性 （内部 ⇄ 概念） |
インフラ層を変えても、SQLは変えなくていい | ストレージをSSDに替えたり、インデックスを貼り直しても、テーブル構造やSQLの書き換えは不要。 |
|
論理的データ独立性 （概念 ⇄ 外部） |
DB構造を変えても、アプリ側は壊れない | テーブルの正規化などで論理構造が変わっても、View（外部スキーマ）を調整すればアプリのコードは変えずに済む。 |
🍌NanoBanana君による解説漫画
