Web教材一覧データベース

スキーマ

キーワード

メタデータ、データディクショナリ、スキーマ、外部スキーマ、ビュー、概念スキーマ、内部スキーマ


予備知識

通常のファイルもデータベースもその中身は数値や文字列の羅列です。どれが商品名なのか、数量なのかを認識するには、辞書に相当するものが必要です。スキーマの説明に入る前に、この辞書に関する説明をします。

メタデータ

メタデータとは、データの定義をしたデータです。あるデータに関するデータの形式、意味内容、格納場所などの情報のことです。
 データベースを管理するシステムをDBMS(Database Management System、データベース管理システム)といいますが、DBMSではデータそのもののデータベース(テーブル=表)とメタデータのデータベース(スキーマ)をもっています。

DD/D(Data Dictionary / Directory)とリポジトリ

メタデータを登録・保管・検索をするシステム、および、それにより作られたメタデータのデータベースです。
 システムとしてのDD/Dは、DBMSではSQLのDDL(Data Definition Language、データ定義言語)-CREATE文など-がそれに相当します。
 メタデータのデータベースには、データディクショナリとディレクトリがあります。これを総称してリポジトリといいます(リポジトリの定義はあいまいで人により異なり、データディクショナリを指すこともあります)。DBMSでのスキーマがそれに相当します。

スキーマ

スキーマ(schema)とは、データベースの構造やデータの格納形式などのメタデータを定義したものです。DBMS管理下にスキーマデータベースとして保管されます。データベースを定義するということは,すなわちスキーマを定義することです。
 例えば、利用者はSQLのSELECT文で、
    SELECT 商品名, 数量 FROM 売上テーブル;
とするだけで結果が得られます。
 売上テーブルがどこに保管してあるのか、商品名や数量が売上テーブル内のどこに、どのような形式で記録されているかは、スキーマに登録してあり、DBMSがスキーマの内容をSQLに教えるからです。

スキーマの3階層

スキーマとは、DBMSの管理下にあるテーブル群についてメタデータ(項目名や主キー名、アクセス権限、格納場所などの情報)を抽象化したものだともいえます。その抽象化のレベルに応じて、外部スキーマ、概念スキーマ、内部スキーマの3層になります。
 このような階層化により、運用保守の管理が容易になります。例えば、データの物理的な格納構造(内部スキーマ)を変更しても,既存プログラム(外部スキーマ)は、表や属性の名称だけで記述しているのですから、(少なくともソースプログラムレベルでの)プログラム変更の必要がありません。システム運用者は、既存プログラムを考慮せずに、サーバの容量や負荷の観点から、サーバの変更や分散ができます。また、あるデータベースの表に新規の属性を追加する(概念スキーマの変更)場合でも、他の属性に影響を与えないならば、既存のプログラムの変更は不要です。

外部スキーマ
「ユーザまたはプログラムからみたデータベースの記述」です。典型的なものが「ビュー」です。
 ビューとは、実際のテーブルではなく,利用者の視点による仮想的なテーブルのことです。
SQLではDDL(データベース定義言語)のCREATE VIEW文によって定義します。
データベースを用いたアプリケーションを作成したり、データベースから情報を取り出すには、外部スキーマを知るだけでよいのです。
 それで、利用者はSQLのSELECT文で、
    SELECT 商品名, 数量 FROM 売上テーブル;
とするだけで結果が得られるのです。
(注)ビュー
実際のテーブルをそのまま利用者に示すのではなく、仮想的なビューを示すほうが適切な場合があります。
売上テーブルを例にします。売上テーブルの利用の多くは、商品名や得意先名を用いますが、正規化した売上テーブルには、商品コードや得意先コードがあるだけで、商品マスタや得意先マスタと照合しないと得られません。
設計段階では、厳密に正規化したテーブルでは利用者が理解しにくいので、あえて正規化を崩して売上テーブルの中に商品名や得意先名があるかのようなビューを示し、決定した段階で、正規化したテーブルとして実装することもあります。
運用段階では、利用者がいちいち照合の命令を与えるのは煩雑だとの理由から、照合をした状態でのビューを設定するほうが、利用者にとって便利でしょう。また、売上テーブルには全支店のレコードが入っていますが、東京支店の担当者には他支店のレコードは見せないという場合は、東京支店のレコードだけを選択した「東京支店売上テーブル」というビューを示すことができます。
 それぞれのビューを実際のテーブルにすると処理効率は良くなりますが、「データの冗長性回避」「データ管理の容易化」などデータベースの利点が失われます。そのバランスを考えることが重要です。
(注)ストアドプロシージャ
ストアドプロシージャ(Stored Procedure)とは、よく利用される一連の処理をまとめた手続き(Procedure)にして、あらかじめDBMS(サーバ)に保存(Stored)しておくことです。イメージ的にいえば、ビューが原始プログラムなのに対して、ストアドプロシージャは実行プログラムに相当します。
 通常のSQL処理では、SQLコマンドを一つずつ送り、サーバで解析やコンパイルを行い処理します。それに対して、ストアドプロシージャは解析もコンパイルも行って保存されているので、クライアントから呼び出し命令を送信するだけで処理が実行できます。パラメタを設定することにより、柔軟性を持たせることもできます。
 ストアドプロシージャにより、サーバの処理効率の向上、クライアントとサーバ間の通信量削減ができます。
 なお、戻り値を返すストアドプロシージャのことを、関数だとして、ストアドファンクションということもあります。
概念スキーマ
「内部スキーマと外部スキーマの中間に位置し、エンティティやデータ項目相互の関係に関する情報を持つ」ものです。典型的なものがER図クラス図です。
概念スキーマは、DBMSが管理しているデータ群の実体(エンティティ)と実体間の関連(リレーションシップ)でデータの構造を示し、実世界を抽象化したものになります。
SQLでは、CREATE SCHEMA文やCREATE TABLE文によって概念テーブルを定義します。
内部スキーマ
「概念スキーマをコンピュータ上に具体的に実現させるための記述」です。
 具体的には、記憶装置名やファイル編成方式、アクセス方法、ファイルサイズ、レコード長、データの表現形式などを記述しまます。DBMSは、これにより物理的にテーブルを実装します。
 外部スキーマと概念スキーマはハードウェアやOSから独立していますが、内部スキーマはそれらに依存しています。

(補足)スキーマとリポジトリの関係

外部スキーマとデータディクショナリの関係

どちらもデータ名、データ形式(タイプ)、アクセス権限などのメタデータを記録したものです。同義語だともいえますが、実務的にはやや異なります。

このように、データディクショナリは外部スキーマの元資源的・補完的な存在であるといえます。

内部スキーマとディレクトリの関係

スキーマのイメージを理解しましょう。DBMSのスキーマは、OSのディレクトリ(フォルダ)と似ています。そのとき、テーブル(表)はファイルに相当します。

スキーマとディレクトリの大きな違いは、スキーマが階層化できないことです。ディレクトリは、その下にサブディレクトリを作って階層化できますが、スキーマは、その下にサブスキーマのようなものを作ることはできません。

このように、内部スキーマとディレクトリはほぼ同義語ですので、内部スキーマを作るのであれば、ディレクトリを作る必要はありません。


本シリーズの目次へ