1.23層スキーマとデータ独立性

DBAやアプリケーション開発者が日常的に直面するのは「このテーブルに列を追加したら、既存のアプリは壊れないか」「格納方式を変えて性能を改善したいが、アプリのSQLは書き直しが必要か」という変更の影響範囲の判断です。3層スキーマは、まさにこの判断のための設計思想であり、単なる用語の暗記ではなく、変更がどの層で止まり、どの層に波及するかを見極める枠組みとして理解する必要があります。

1.2.13層スキーマの構造

• 3層スキーマ＝ANSI/SPARCが提唱したデータベースの論理設計モデル。上から外部スキーマ（ユーザー/アプリごとの視点＝ビューや個別画面が見るデータ構造）・概念スキーマ（組織全体で共有する論理的なデータ構造＝テーブル定義や制約）・内部スキーマ（実際の格納形式＝ファイル構成・索引・格納順序）の3層で構成される。
• 各層は写像（マッピング）によって連結される＝外部スキーマは概念スキーマへの写像を通じてデータを取得し、概念スキーマは内部スキーマへの写像を通じて実際の格納データにアクセスする。この写像こそが「ある層の変更を他層に波及させない」仕組みの実体である。

1.2.2論理的データ独立性と物理的データ独立性

• 論理的データ独立性＝概念スキーマを変更しても、外部スキーマ（アプリ/ビュー）に影響を与えない性質。例えば既存テーブルに新しい列を追加しても、その列を参照しない既存のビューやSQLは変更不要で動き続ける（写像を調整すれば吸収できる）。
• 物理的データ独立性＝内部スキーマ（格納形式・索引・ファイル配置）を変更しても、概念スキーマ（テーブル定義）に影響を与えない性質。例えば性能改善のために索引を追加・変更したり、テーブルを別のディスク領域に再配置しても、SQLの記述（テーブル定義に基づく問合せ）は変更不要。

あなたは基幹システムのDBAで、性能改善のため「注文明細テーブルの検索を高速化する新しい索引を追加し、さらに格納ファイルを高速なストレージ領域に再配置したい」という提案を受けました。まず判断すべきは、この変更が内部スキーマ（格納形式・索引・ファイル配置）のみに閉じているかどうかです。索引の追加やファイルの物理的な再配置は、テーブルの論理的な定義（列名・データ型・制約）を変えるものではないため、物理的データ独立性により、アプリケーション側のSQLは一切変更不要と判断できます。次に、営業部門から「注文明細に新しい列（割引適用フラグ）を追加してほしいが、既存の請求書発行アプリのSQLは絶対に壊したくない」という要件が来たとします。これは概念スキーマ（テーブル定義）の変更であり、新しい列を参照しない既存アプリへの影響は、論理的データ独立性によって理論上は吸収可能です。ただし実務では、SELECT * を使っているアプリや、列の物理的な並び順に依存した処理が残っている場合、理論上の独立性があっても意図せず影響を受けることがあります。ここで「3層スキーマがあるから列を追加しても絶対に何も壊れない」と過信するのは危険で、独立性は写像の設計と実装の丁寧さに支えられているという前提を忘れてはいけません。

1.2.3この節のまとめ

• 3層スキーマ＝外部スキーマ（アプリ視点）・概念スキーマ（論理的な全体構造）・内部スキーマ（実際の格納形式）の3層
• 物理的データ独立性＝内部スキーマの変更（索引・格納方式）が概念スキーマに影響しない。論理的データ独立性＝概念スキーマの変更（列追加等）が外部スキーマに影響しない
• 理論上の独立性は写像の設計と実装（SELECT * の不使用等）に支えられる前提であり、無条件に何も壊れないと過信しない