この記事は
データベースが外部アプリケーションに対して、また内部物理ファイルに対してどのようにデータを持っているのか、改めて復習したかったのでそのメモである。
自分の解釈が間違っていたらゴメンナサイ。
そもそもスキーマとは何か
データ構造、形式、関連、整合性制約を記述したものである。
RDBで言えばリレーション/アソシエーション設計にあたる。
単一のリレーション内における型定義や制約定義はもちろんのこと、データベース全体を通して各リレーションをどう管理していくかという設計まで含まれる。
外部レベル・概念レベル・内部レベルの3階層による概念モデルはANSI/SPARCによって提案されたもので、一般的にANSI/SPARCモデルと呼ばれる。
この3階層モデルには色々と派生があるようだが、今回自分があたったソースに則ると下記のように定義される。
- 外部スキーマ
概念スキーマで定義された論理データから必要なデータを取り出したもの。RDBで言えばビューに相当する。
- 概念スキーマ
DB上の論理データ。DBに保持するデータの要素およびデータ同士の関係を定義する。RDBで言えばリレーションに相当する。
- 内部スキーマ
概念スキーマで定義された論理データをどのようにDBMS内部に格納するかを定義する。RDBで言えば「BTreeを用いる」とか「インターナルIDのハンドリング」とか「実際に吐き出すデータ形式」とかに（多分）相当する。
データの独立性
3階層モデルによって何がうれしいかというと、各レベル間でのデータ独立性を担保できることである。
外部スキーマ/概念スキーマの分離は「論理データ独立性」を担保してくれる。
外部スキーマはアプリケーションから見るとインターフェースにあたるので、その実装はカプセル化できる。インターフェースに則ることで、実世界の変化による概念スキーマの変更を自由に行うことができる。これが「論理データ独立性」である。
「論理データ独立性」によって、インデキシングによるパフォーマンスチューニングやリレーションの再定義が可能になったりする。
概念スキーマ/内部スキーマ分離は「物理データ独立性」を担保してくれる。
概念スキーマに変更加えなければ、具体的にデータベース内部で行われる物理ファイル編成やデータアクセスの方式は自由に変更することができる。これが「物理データ独立性」である。
「物理データ独立性」によって、（あまりいい例が思いつかないが）オンプレで持っていたデータストアをクラウド化するといった変更も可能となる。吐き出すデータ形式とかも変更できたりする気がする。データベース自体のバージョンアップなどが可能となるためには、不可欠な独立性である。
まとめ
内部スキーマに関しての理解が浅いことがわかったので、そっちを掘っていかんと。