3層スキーマとは ― 外部・概念・内部スキーマ

ビューを作る、表に列を足す、索引を付ける。どれも、データベースの構造の定義を変える作業です。3層スキーマは、この定義を外部スキーマ・概念スキーマ・内部スキーマの3段に分けて持つ考え方です。分けておけば、1つの段を変えても、影響をその段の近くで止められます。

スキーマとは、データベースに入るデータの構造を定義したものです。例には、RDBの表とSQLを使います。

3つの段は、データを見る立場で分かれます。外部スキーマはアプリから見た形を決めます。概念スキーマはデータベース全体の論理的な構造を、内部スキーマは記憶装置への置き方を決めます。

この3段の枠組みは、米国規格協会（ANSI）の研究グループが1975年にまとめた中間報告がもとになっているとされます。そのため、ANSI/SPARCの3層スキーマとも呼ばれます。名前の似た3層クライアントサーバシステムは、処理をどのコンピュータに載せるかの構成で、3層スキーマとは別のものです。

例として、社員表に社員ID・氏名・部署ID・給与・内線の5つの列があるとします。営業アプリが使うのは氏名と内線だけで、給与は見せたくありません。そこで、営業アプリには必要な列だけを並べた形を見せます。

このように、利用者やプログラムごとに見せるデータの形を決めたものが外部スキーマです。関係データベースでは、ビューが外部スキーマに当たります。

CREATE VIEW 社員連絡先 AS
SELECT 社員ID, 氏名, 内線
FROM 社員;

営業アプリは、社員表ではなくこのビューに問い合わせます。営業アプリの利用者にGRANT文でこのビューにだけ権限を与えれば、社員表の給与は読めません。外部スキーマは副スキーマとも呼び、使う側の数だけ作れます。

どんな表があり、それぞれの表にどんな列とデータ型があるかを決めたものが概念スキーマです。主キーや外部キーなどの制約も、ここに含まれます。外部スキーマと違い、概念スキーマはデータベース全体で1つです。

関係データベースでは、表の定義が概念スキーマに当たります。表の定義は、次のようなSQL文で書きます。書き方はCREATE TABLEの記事で説明しています。

CREATE TABLE 社員 (
  社員ID  INTEGER PRIMARY KEY,
  氏名    VARCHAR(40) NOT NULL,
  部署ID  INTEGER,
  給与    INTEGER,
  内線    VARCHAR(10)
);

DBMSは、こうして定義した表と列を、データディクショナリに記録して管理します。

どの表に分けるかは、E-R図でデータの関連を整理してから決めます。重複のない表に分ける手順は、正規化の記事で説明しています。概念スキーマは、特定のアプリの都合にも、記憶装置の都合にも左右されない形で決めます。名前の似た概念設計は設計の段階を指す言葉で、概念スキーマとは分け方が違います。

概念スキーマで決めた表を、実際のディスクにどう記録するかを決めたものが内部スキーマです。記憶スキーマとも呼びます。どのファイルや場所に格納するか、どの列に索引を付けるかなどを含みます。

関係データベースでは、インデックスの作成が内部スキーマの変更の代表例です。インデックスは検索を速くするための索引です。索引を作っても、表の列やビューの定義は変わりません。

CREATE INDEX 社員_部署ID
  ON 社員 (部署ID);

3つの層と、関係データベースでそれぞれに当たるものを表にまとめます。

3層に分ける目的は、データの独立性を高めることです。データの独立性とは、データベースの構造を変えても、それを使うアプリを変えずに済む性質です。どの層の境目の話かによって、物理的データ独立性と論理的データ独立性の2つに分かれます。

物理的データ独立性は、内部スキーマの変更を概念スキーマで止める

内部スキーマを変えても、概念スキーマと外部スキーマを変えずに済む性質を物理的データ独立性と呼びます。索引の追加がこの例です。索引を作った後も、営業アプリは同じSQL文で同じ行を受け取ります。

論理的データ独立性は、概念スキーマの変更を外部スキーマで止める

概念スキーマを変えても、外部スキーマとアプリを変えずに済む性質を論理的データ独立性と呼びます。直すのは、外部スキーマと概念スキーマの対応付けだけです。例として、社員表の内線の列を、新しく作った内線表に移すとします。

このときビューの名前と列はそのままにして、中身のSELECT文だけを、2つの表を結合する形に書き直します。ビューが見せる形が外部スキーマに、中身のSELECT文が概念スキーマとの対応付けに当たります。

CREATE VIEW 社員連絡先 AS
SELECT 社員.社員ID, 社員.氏名,
       内線表.内線
FROM 社員 JOIN 内線表
  ON 社員.社員ID = 内線表.社員ID;

営業アプリが実行する SELECT 氏名, 内線 FROM 社員連絡先 は、書き換えなくても同じ行を返します。表の構造が変わっても、その違いはビューの中で吸収されます。ただし、結合したビューを通した更新には、製品によって制限があります。その条件はビューの記事で説明しています。

次の図でデータベースに加える変更を選ぶと、どの層を変え、どの層で影響が止まるかが色で示されます。例は、ここまでの社員表と、社員連絡先ビューを使う営業アプリです。

索引の追加や格納場所の変更は内部スキーマで止まり、アプリから見えません。列名の変更や表の分割は概念スキーマを変えるので、外部スキーマとの対応付けを直して止めます。列の追加は、ビューがその列を使わないので、対応付けも直さずに済みます。

• ANSI/X3/SPARC Study Group on Data Base Management Systems「Interim Report」。1975年に、ACM SIGMODの会報FDT Bulletin第7巻第2号に載りました。原文は読めていないため、各層の中身は下の教科書のスライドと二次資料で確かめています。
• Elmasri・Navathe「Fundamentals of Database Systems」第2章のスライド（Purdue大学が公開。各層の中身、外部スキーマが利用者ごとのビューであること、2つの独立性の定義）
• Wikipedia「ANSI-SPARC Architecture」（外部・概念・内部の各層の説明。二次資料）