スキーマ

キーワード

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

予備知識

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

データモデル

データモデルは、データ構造を抽象化という観点からデータベースを構築するまでの手順です。概念データモデル→論理データモデル→物理データモデル　の順でデータベースを構築します。

概念データモデル
ＥＲモデルの概要を作成する段階です。実務で用いられるデータとデータ間の関連をまとめます。
論理データモデル
概念データモデルを、さらに詳細化しながら、階層モデル、関係モデル、オブジェクト指向モデルなどのどれが適切かを決定します。そして、関係モデルにするならば正規化、詳細なクラス図作成などデータベースの設計をします。
物理データモデル
データの型、データ量、アクセス頻度などを考慮して、具体的なＤＢ製品を決定し、実装の方法を決定します。

メタデータ

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

ＤＤ／Ｄ（Data Dictionary / Directory）とリポジトリ

メタデータを登録・保管・検索をするシステム、および、それにより作られたメタデータのデータベースです。
　システムとしてのＤＤ／Ｄは、ＤＢＭＳではＳＱＬのＤＤＬ（Data Definition Language、データ定義言語）－CREATE文など－がそれに相当します。
　メタデータのデータベースには、データディクショナリとディレクトリがあります。これを総称してリポジトリといいます（リポジトリの定義はあいまいで人により異なり、データディクショナリを指すこともあります）。ＤＢＭＳでのスキーマがそれに相当します。

データディクショナリ（データ辞書）
人間を対象にした辞書で、データ名、データ形式（タイプ）、意味、発生源、使用法、アクセス権限などを記述したものです。
スキーマもそれと同様なのですが、効率向上のために、意味や使用法など処理に直接関係しないものはもたないのが通常です。そのため、データベースシステムでもデータディクショナリは使われます。
ディレクトリ（登録簿）
コンピュータを対象にした辞書です。データの格納場所、データの容量、アクセス方法などが入っています。パソコンんさどのＯＳでは、ファイルを特定するのに、aaa/bbb/index.htmlのように「ディレクトリ名/ファイル名」で記述しますが、そのディレクトリです。

ＩＲＤＳ（Information Resource Dictionary System：情報資源辞書システム）

データ辞書を発展させたもので、情報資源全体を管理するシステムです。個々のシステムでデータ辞書を作成するのではなく、全社的に、データ辞書を一元管理することにより、重複の防止、共有化などを図るものです。

情報資源管理（Information Resource Management：ＩＲＭ）
紙などコンピュータ化されないものまでも共有資源とみなして管理の対象とする。
データ資源管理（Data Resource Management：ＤＲＭ）
コンピュータ化されたデータのみを共有情報とみなした管理を行う。

スキーマ

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

スキーマの３階層

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

外部スキーマ: 「ユーザまたはプログラムからみたデータベースの記述」です。典型的なものが「ビュー」です。
　ビューとは、実際のテーブルではなく，利用者の視点による仮想的なテーブルのことです。
ＳＱＬではＤＤＬ（データベース定義言語）のCREATE VIEW文によって定義します。
データベースを用いたアプリケーションを作成したり、データベースから情報を取り出すには、外部スキーマを知るだけでよいのです。
　それで、利用者はＳＱＬのＳＥＬＥＣＴ文で、
　　　　SELECT 商品名, 数量　FROM 売上テーブル;
とするだけで結果が得られるのです。
概念スキーマ: 「内部スキーマと外部スキーマの中間に位置し、エンティティやデータ項目相互の関係に関する情報を持つ」ものです。典型的なものがＥＲ図やクラス図です。
概念スキーマは、ＤＢＭＳが管理しているデータ群の実体（エンティティ）と実体間の関連（リレーションシップ）でデータの構造を示し、実世界を抽象化したものになります。
ＳＱＬでは、CREATE SCHEMA文やCREATE TABLE文によって概念テーブルを定義します。
内部スキーマ: 「概念スキーマをコンピュータ上に具体的に実現させるための記述」です。
　具体的には、記憶装置名やファイル編成方式、アクセス方法、ファイルサイズ、レコード長、データの表現形式などを記述しまます。ＤＢＭＳは、これにより物理的にテーブルを実装します。
　外部スキーマと概念スキーマはハードウェアやＯＳから独立していますが、内部スキーマはそれらに依存しています。

他の観点からのスキーマ

ビュー

実際のテーブルをそのまま利用者に示すのではなく、仮想的なビューを示すほうが適切な場合があります。
売上テーブルを例にします。売上テーブルの利用の多くは、商品名や得意先名を用いますが、正規化した売上テーブルには、商品コードや得意先コードがあるだけで、商品マスタや得意先マスタと照合しないと得られません。
設計段階では、厳密に正規化したテーブルでは利用者が理解しにくいので、あえて正規化を崩して売上テーブルの中に商品名や得意先名があるかのようなビューを示し、決定した段階で、正規化したテーブルとして実装することもあります。
運用段階では、利用者がいちいち照合の命令を与えるのは煩雑だとの理由から、照合をした状態でのビューを設定するほうが、利用者にとって便利でしょう。また、売上テーブルには全支店のレコードが入っていますが、東京支店の担当者には他支店のレコードは見せないという場合は、東京支店のレコードだけを選択した「東京支店売上テーブル」というビューを示すことができます。
　それぞれのビューを実際のテーブルにすると処理効率は良くなりますが、「データの冗長性回避」「データ管理の容易化」などデータベースの利点が失われます。そのバランスを考えることが重要です。

記憶スキーマ

内部スキーマのうち、特にデータベースで用いられる記憶装置について、種類や記憶容量といった物理的な構成を定義したスキーマのことです。記憶スキーマを内部スキーマと同義語として用いることもあります。

副スキーマ

外部スキーマがテーブルを対象としているのに対して、ビューなどを対象にしたスキーマです。多くの場合、副スキーマも含めて外部スキーマとしています。
逆に、内部スキーマを記憶スキーマというのに対して、外部・概念スキーマのように利用者を対象にしたスキーマを副スキーマということもあります。

データモデルとスキーマの関係

両者は混同されやいのですが、全然違う概念です。関係データベースを例にその概要を示します。

　　　　　　データモデル　　　　スキーマ
目的　　　　ＤＢの作成　　　　　ＤＢ構造の表示
３区分　　　概念：ＥＲモデル　　外部；ビュー、テーブル
　　　　　　論理；正規化など　　概念：テーブル
　　　　　　物理；実装設計　　　内部：実装
区分意味　　順序を示す　　　　　見せる人による区分

データモデルはＤＢを構築するまでのプロセスで、概念→論理→物理の準で行います。
物理データモデルにより、データベースが実装されますが、それを維持や利用の面から記述したのが内部スキーマです。
スキーマは　運用者：内部－概念－外部：利用者（プログラマ）の立場です。

スキーマとリポジトリの関係

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

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

記述メタデータの種類
データディクショナリは利用者にデータ辞書としての役割を重視しています。それには、「商品」の定義、「商品コード」の体系、発生源、利用にあたっての留意事項なども重要な内容項目になります（それらをここでは「付帯項目」とします）。データディクショナリに付帯項目そのものは入れなくてもリンク先などは入れるべきでしょう。
それに対して外部スキーマは、ＳＱＬなどでデータベースをアクセスするたびに参照されることが大きな用途です。処理に必要な項目だけにして、付帯項目はもたないほうが処理効率が向上します。また、データ定義言語では、標準的な入力項目が決まっており、その他の項目を入力するには面倒なこともあります。
スキーマ作成過程の中間物としてのデータディクショナリ
データベースを構築するには、ＥＲ図やクラス図を作成しますが、それ以前に、「商品」「得意先」「受注」などのエンティティを特定します。そのときに「商品」表には「商品名」「商品コード」など多くの項目（属性）が必要になりますが、当初からすべての項目を列挙するのは困難で、検討を重ねながら追加していきます。また、「商品名」の長さや「商品コード」の桁数なども検討によって変更されるでしょう。
　これらの改訂の過程に用いるものがデータディクショナリであり、完成した時点でスキーマに変換するのが適切だと理解することもできます。

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

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

スキーマのイメージを理解しましょう。ＤＢＭＳのスキーマは、ＯＳのディレクトリ（フォルダ）と似ています。そのとき、テーブル（表）はファイルに相当します。

ＯＳでは「ディレクトリ名/ファイル名」のように記述します。ＳＱＬでは「スキーマ名.テーブル名」と記述します。
このとき、ディレクトリやスキーマが状況により固定しているならば、「ディレクトリ名/」や「スキーマ名.」は省略可能です。
ＤＢＭＳの管理下にあるデータベースは、いずれかのスキーマに所属します。
一つのスキーマには同一名のテーブルは存在できません。他のスキーマに属するテーブルとは同一名であったもかまいません。
スキーマには所有者、読み出しや書き込みの権限を設定できます。

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

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

データベースの管理

データベースの管理者には、データ管理者（Data Administrator：ＤＡ）とデータベース管理者（DataBase Administrator：ＤＢＡ）があります。

データ管理者: 業務で用いられるデータの概念設計をして、論理データモデルを設計する任務です。外部スキーマ・概念スキーマの分野になります。個別システムだけでなく、全社的な観点から設計し管理することが求められます。
データベース管理者: 論理データモデルから物理データモデルへと変換、すなわち内部スキーマを設計、データベースとして実装する分野を担当します。また、運用工程でのデータベースの維持管理、バックアップやリカバリなども担当します。個別システムレベルでそれぞれのデータベース管理者を設置するのが通常です。

本シリーズの目次へ