データベース設計を学ぶ上で必ず押さえておきたい基礎理論のひとつが「3層スキーマアーキテクチャ」です。
3層スキーマとはデータベースを外部・概念・内部という三つの抽象層に分けて設計する考え方であり、データ独立性を実現するためのデータベース設計の根幹となる概念です。
本記事では、3層スキーマの定義・ANSI/SPARCモデルの背景・各層の役割と具体例・データ独立性の意義・実際のRDBMSへの適用まで詳しく解説します。
データベース設計の基礎をしっかり固めることで、より高品質なシステム設計が実現できるでしょう。
3層スキーマアーキテクチャとは何か？
それではまず、3層スキーマアーキテクチャの基本的な定義と背景について解説していきます。
3層スキーマアーキテクチャ（Three-Schema Architecture）は、1975年にANSI（米国標準化協会）のSPARCグループが提唱したデータベース設計の標準的な枠組みであり、「ANSI/SPARCアーキテクチャ」とも呼ばれます。
3層スキーマの三層構成：
①外部スキーマ（External Schema）：ユーザー・アプリケーション側から見たデータの姿（ビュー層）
②概念スキーマ（Conceptual Schema）：DBの論理的な全体構造・データの意味と関係を定義（論理層）
③内部スキーマ（Internal Schema）：データの物理的な格納方式・ファイル構造（物理層）
この三層を明確に分離することで、ある層の変更が他の層に影響を与えない「データ独立性」が実現されます。
たとえばハードウェアの変更やインデックスの追加（内部スキーマの変更）があっても、ユーザーやアプリケーションから見えるデータの姿（外部スキーマ）は変わりません。
3層スキーマが登場した背景
1970年代初頭、データベース技術が発展するにつれて「プログラムとデータの独立性をどう確保するか」という問題が浮上しました。
ファイルシステム時代は物理的なデータ格納形式がプログラムに直接依存しており、ハードウェア変更やデータ格納方式の変更のたびにプログラムを修正する必要がありました。
この問題を解決するために提唱されたのがANSI/SPARCの3層スキーマアーキテクチャであり、現代のすべてのRDBMSの設計基盤となっています。
3層スキーマの全体像
| 層 | 名称 | 内容 | 管理者 |
|---|---|---|---|
| 第1層 | 外部スキーマ | ユーザー別のビュー定義 | アプリ開発者 |
| 第2層 | 概念スキーマ | DB全体の論理構造 | DBアーキテクト |
| 第3層 | 内部スキーマ | 物理的格納方式 | DBAdministrator |
各層の詳細：外部スキーマ・概念スキーマ・内部スキーマ
続いては、3層スキーマの各層の詳細な役割と具体例を確認していきます。
外部スキーマ（ビュー層）の詳細
外部スキーマは「ユーザーやアプリケーションから見えるデータの姿」を定義する層です。
複数の異なる外部スキーマが同一の概念スキーマから定義され、各ユーザーグループに必要なデータのみを見せる「ビュー」として機能します。
外部スキーマの例（SQLビュー）：
— 営業部向けビュー（顧客名・注文金額のみ）
CREATE VIEW sales_view AS
SELECT c.name, o.amount FROM customers c
JOIN orders o ON c.id = o.customer_id;
— 人事部向けビュー（社員名・部署のみ）
CREATE VIEW hr_view AS
SELECT name, department FROM employees;
外部スキーマによって、同じDBでも部署・役割ごとに見えるデータを制限し、セキュリティとデータアクセス管理が実現されます。
概念スキーマ（論理層）の詳細
概念スキーマは「DBシステム全体の論理的な構造」を定義する中心的な層です。
エンティティ（テーブル）・属性（カラム）・関係性（リレーションシップ）・制約（一意制約・外部キー等）がすべてここで定義されます。
概念スキーマはDBの「真実の姿」であり、外部スキーマ（ユーザービュー）と内部スキーマ（物理格納）の橋渡し役を担う最も重要な層です。
内部スキーマ（物理層）の詳細
内部スキーマは「データが実際にディスク上にどのように格納されるか」という物理的な構造を定義する層です。
ファイル形式・ページサイズ・インデックスの構造（B木・ハッシュ等）・データ圧縮・パーティション分割などの物理的な格納戦略がここで管理されます。
ユーザーやアプリケーションは通常この層を意識する必要はなく、DBMSが自動的に管理します。
データ独立性と3層スキーマの意義
続いては、3層スキーマが実現する「データ独立性」の意義を確認していきます。
論理的データ独立性
論理的データ独立性とは「概念スキーマ（論理構造）を変更しても、外部スキーマ（ユーザービュー）に影響を与えない」という性質です。
テーブルの再構成・新しいカラムの追加・テーブルの分割などの概念スキーマ変更を行っても、ビューを適切に管理することでアプリケーションへの影響を最小化できます。
物理的データ独立性
物理的データ独立性とは「内部スキーマ（物理格納方式）を変更しても、概念スキーマ（論理構造）に影響を与えない」という性質です。
インデックスの追加・削除、ストレージ形式の変更、パーティション変更などをしても、論理的なテーブル構造はそのまま維持されます。
物理的データ独立性により、DBAはパフォーマンスチューニングのために内部構造を自由に変更できる柔軟性が確保されます。
現代のRDBMSへの3層スキーマの適用
現代のRDBMS（PostgreSQL・MySQL・Oracle・SQL Server等）はすべてANSI/SPARCの3層スキーマアーキテクチャに基づいて設計されています。
ユーザーはSQL（外部スキーマ層のビュー・クエリ）でデータを操作し、RDBMSが概念スキーマの論理構造を管理し、内部スキーマの物理格納はDBMSのストレージエンジンが担当するという役割分担が実現されています。
まとめ
3層スキーマアーキテクチャは1975年のANSI/SPARCグループが提唱した、外部スキーマ・概念スキーマ・内部スキーマという三層にデータベースを分離する設計理論です。
各層の変更が他層に影響しない「データ独立性（論理的独立性と物理的独立性）」を実現することが最大の目的であり、現代のすべてのRDBMSはこのアーキテクチャを基盤として構築されています。
外部スキーマはビューによるアクセス制御、概念スキーマはDB全体の論理設計、内部スキーマは物理格納の最適化を担い、三層が連携してデータベースの品質・セキュリティ・パフォーマンスを支えているといえるでしょう。
