　フラットファイルやバイナリファイルを使って自前でデータ管理を実装してデータ管理を行う場合と異なり、データベースを利用すればデータが物理的にどのようにストレージに格納されるかを意識する必要はありません。もちろん、この連載でお話ししたデータベースの物理データの構造を知っておくことで、パフォーマンスをさらに高めることは可能です。

　リレーショナルデータベース（RDB)を利用した経験がある方はテーブル設計やスキーマ設計という言葉を聞いたことや実際に行ったことがあるかと思います。

　ところで、そもそも「スキーマ」とは、何なのでしょうか。「スキーマ」とはデータベースに蓄積するデータそのものではなく、データの意味であるメタデータ、データの構造や操作のルールなどを指します。RDBではスキーマは次の3層からなっています。この3層スキーマ構造はANSI/X3/SPARCで提案されたものです。

図1　ANSI/X3/SPARCが提案した3層スキーマ構造

　各スキーマの意味は次のとおりです。

概念スキーマ　
データを構成する属性や関係を表したもの。「論理スキーマ」とも呼ばれる。RDBでは、表の定義やリレーションの定義を指し、実世界をデータモデリングしたもの。
外部スキーマ　
利用者側（アプリケーション開発者）から見たデータ構造やデータの指定方法などを表し、内部スキーマ上に利用者の目的にあったデータベース空間を構築したもの。RDBでは用途に応じてSQL文で定義する。
内部スキーマ　
データベースをどのように物理的に記憶システムに実装したもの。「記憶スキーマ」や「物理スキーマ」とも呼ばれる。

図2　3層スキーマのイメージ

　概念スキーマ、外部スキーマ、内部スキーマをそれぞれ関係づけるために、外部スキーマ／概念スキーマ変換、概念スキーマ／内部スキーマ変換が必要となります。ただ、これらの変換はRDB内部で行われていますので、利用者は意識することはありません。

　RDBではこの3層スキーマ構造によって、内部スキーマがISAM構造だったものをB＋ツリー構造に実装し直したとしても概念スキーマには一切変更が生じることがないため、物理的データ独立を実現しています。物理的データ独立を実現しているので、データ管理を自前で実装した場合に比べ、移植性も保守性も優れてくるのです。

　一方、論理的な面ではRDBへのデータ問い合わせはすべてSQL文で行うことになるため、どのように実装されていようと概念スキーマへの影響がないため、論理的データ独立性を実現しています。この論理的データ独立性によって、アプリケーションからはRDBを利用するためのインターフェイスと問い合わせのためのSQL文が重要であって、RDBがどのように実装されているかを意識せずにすみます。

　同一のRDB製品であれば、プラットフォームが変わってもRDB利用部分のコードの変更が必要ありません。また、RDBを利用することで、RDB製品を変更してもアプリケーションのRDB呼び出しインターフェイスの変更が生じても、RDBへの問い合わせに利用するSQL文はそのまま利用できるというわけです。

　スキーマはすでにこの連載で説明したシステムテーブル（システムカタログ）で管理されます。作成したスキーマはシステムテーブルに登録され、問い合わせ時にSQL文の整合性チェックもこのシステムテーブルにて行われるというわけです。

スキーマ設計について

　次はスキーマ設計についてお話ししましょう。スキーマ設計とはその名のとおり、スキーマを設計していくこと、詳しくは取り扱うデータをデータベース空間上に定義していく処理となります。

　RDBで利用されるデータは表形式に格納されますが、スキーマ設計ではこのデータをどのように表形式にて定義していくかを考えていくことになります。スキーマ設計には作法がありますので、その作法を説明していきましょう。

　RDBのスキーマ設計ではER図という手法を使ってデータ構造を整理することが一般的です。ERとはエンティティリレーションシップ（Entity Relationship)の略で、1976年にPeter Chen氏によって提唱されたRDBで利用されるデータモデルです。このデータモデルを表記したものがER図となっており、データの関係をシンプルに表示したもので、データベースの概念設計に今日でも利用されています。ER図を書くためのツールも多数存在しています。

　スキーマ設計にER図を利用することは上の説明で分かりますが、ではエンティティとは何でしょうか。エンティティとはデータベースを利用する上で管理すべき実体のことです。上であげたデータ分類はまさにエンティティであり、これらの実際のデータ、つまり施設情報の東京タワーなどはエンティティの具体的な例であり、「インスタンス」と呼ばれます。

　スキーマ設計ではまずエンティティを洗い出し、洗い出したエンティティの関係を決めていく必要があります。エンティティの対応関係は次の4種類にまとめられます。