「スキーマ」という用語をご存知でしょうか。
もともと計画や図のことを指す言葉ですが、今では様々な分野で広く用いられ、それぞれで微妙に意味合いが異なっていたり、曖昧であったりして理解するのに苦しむところがある用語かもしれません。
データベースにおけるスキーマとはデータの構造、性質や他のデータとの関連、データベースを操作する時のルールや表現法などを定義したもののことです。
データベースの設計図と考えればわかりやすいかもしれません。例えば、家を建てるためにはまず設計図が必要です。データベースにおいてもそれと同じで、いきなり作り始めるのではなく、まず、必要なデータを洗い出し、そのデータをどのように格納するかを整理する必要があります。そのような作業を「スキーマを定義する」と表現します。
3層スキーマとは
3層スキーマとは、データベースのスキーマを3つの階層に分けてそれぞれ定義する方式のことです。データベースの設計は、その3つの階層を意識して進めていくことになります。
スキーマ | 説明 |
---|---|
外部スキーマ | 概念スキーマで定義された論理データから必要なデータを取り出したもの。(ビューなどに相当) |
概念スキーマ | DB上の論理データ。DBに保持するデータの要素およびデータ同士の関係を定義する。(テーブルに相当) |
内部スキーマ | 概念スキーマで定義された論理データを具体的にどのようにDBMS内部に格納するかを定義する。 |
外部スキーマはシステム利用者であるユーザー、もしくはアプリケーションから見たデータベースのデータ構造やデータの関係を定義するスキーマであり、言ってみれば「ユーザーから見たデータベース」です。データベースのビューに相当します。(ビュー以外に、実際の画面に出力するデータのことも含みます。)
概念スキーマは「開発者から見たデータベース」です。概念スキーマの設計を「論理設計」と呼び、データベース設計の中で重要な位置を占めます。
内部スキーマは「DBMSから見たデータベース」です。コンピュータ上で動く以上、データベースのデータもその実体は「ファイル」となります。そのファイルをディスク上にどのように格納するかを定義します。内部スキーマの設計を「物理設計」と呼びます。
このようにわざわざスキーマを3つの階層に分けるのは、例え、ひとつのスキーマに変更があったとしても他の2つのスキーマは影響しないようにするためです。(そのように各スキーマが独立していることをデータ独立性と言います。)
実際の開発現場では仕様変更対応の連続です。その際、ひとつの変更がデータベース設計全体に影響を受けてしまっていては、開発工数がいくらあっても足りません。
3層スキーマの思想に従って設計していれば、変更の範囲を局所化することができるでしょう。3層スキーマは、変更対応を可能な限り少ない労力でできるようにと、先人たちが編み出した知恵というわけです。