3層スキーマ（外部・概念・内部）

📌

3層スキーマとは

3層スキーマとは、データベースを「外部・概念・内部」の3つの階層に分けて定義する考え方です。スキーマ＝データの構造を定めた設計図のことで、それを役割ごとに3段に分けて整理します（ANSI/SPARC が提唱したモデルです）。

身近な例で考えると、1つの建物を「利用者の使い方」「設計図」「基礎工事」の3段で考えるのに似ています。利用者は部屋の使い勝手だけ気にすればよく、設計図はその上位に1つあり、基礎工事の詳細は表に出てきません。それぞれの関心事を分けることで、変更の影響を抑えられます。

上の図解では、上から外部スキーマ（青）→ 概念スキーマ（緑）→ 内部スキーマ（橙）の順に並んでいます。利用者は一番上の「見え方」だけを意識し、データが実際にどう保存されているか（一番下）を知らなくてよい仕組みになっています。

📌

各層の役割

3つの層は、それぞれ次の役割を担います。上から順に「見え方 → 全体の論理 → 物理的な保存」と抽象度が下がっていきます。
・外部スキーマ：利用者やアプリごとに必要なデータの見え方（ビュー）を定義。営業には売上だけ、人事には人事情報だけ見せる、というように複数あってよい
・概念スキーマ：データベース全体の論理構造を定義。全エンティティと関連を一元的にまとめた中心の層で、原則1つだけ
・内部スキーマ：データをディスクに実際どう保存するか（物理構造）を定義。ファイル配置・インデックス・格納形式など

ポイントは、真ん中の概念スキーマが「土台」として1つあり、その上に複数の外部スキーマ、下に内部スキーマがぶら下がる構造になっていることです。利用者は外部スキーマだけを見て作業し、概念・内部の詳細を意識せずに済みます。

📌

データ独立性

3層に分ける最大のねらいは「データ独立性」を実現することです。これは、ある層を変更しても他の層（特にアプリケーション）に影響を与えない性質のことで、2種類あります。
・論理データ独立性：概念スキーマ（全体の論理構造）を変えても、外部スキーマ＝利用者の見え方を保てる性質
・物理データ独立性：内部スキーマ（保存方法）を変えても、概念・外部スキーマやアプリに影響しない性質

たとえば、検索を速くするためにインデックス（＝索引）を追加したり、保存先のディスクを高速なものに替えたりするのは内部スキーマの変更です。物理データ独立性のおかげで、こうした変更をしてもアプリのプログラムを書き換えずに済みます。

建物に例えると、水道管（内部）を新しい素材に交換しても、蛇口をひねれば水が出る使い勝手（外部）は変わらないのと同じです。層を分けて関心事を切り離すことで、保守や性能改善を柔軟に行えるのが3層スキーマの利点です。

❓

なぜ3層に分けるのか

なぜわざわざ3層に分けるのか。それは「変更の影響を閉じ込めるため」です。1つの大きな定義にまとめてしまうと、どこかを変えたときにすべてのアプリやプログラムを書き直すことになります。3層に分けることで、変更の波及を層の中に留めることができます。

具体的にどう役立つかを見てみましょう。
・内部スキーマを変える（例：検索を速くするためにインデックス＝索引を追加する）→ 概念スキーマ・外部スキーマは変えなくてよい。アプリのプログラムも修正不要
・概念スキーマを変える（例：テーブルに新しい列を追加する）→ 内部スキーマは変えなくてよい。影響を受けるのは外部スキーマだけで限定できる

身近な例で考えると、電気のコンセントとプラグの関係に似ています。家の電気配線（内部）を新しい電線に替えても、コンセントの形（外部）は変わりません。利用者は配線の詳細を知らなくても、コンセントにプラグを差せば使えます。3層スキーマも同じで、「知らなくていいことは隠す」構造にすることで、変更に強いデータベース設計が実現します。

✏️

練習問題