メタデータとは ― データディクショナリの役割

メタデータとは、データの意味・形式・作成者・格納場所などを説明するデータです。データベースでは、表や列の定義がメタデータに当たり、それを集めて管理するものをデータディクショナリと呼びます。

売上表の金額の列に12000と入っていても、それが税込か税抜か、単位が円かドルかは、値だけを見ても分かりません。引き継いだ表を読むときや、部署の違う表をつないで集計するときに、この説明が無いと困ります。

値の意味を分かるようにするには、値とは別に説明を書き残しておく必要があります。この説明にあたるデータが、メタデータです。

メタデータは、データベースの外にもあります。スマートフォンで撮った写真には、写った画像のほかに、撮影日時や機種などが記録されます。写真で使う代表的な記録形式に、Exifがあります。

• 写真：撮影日時・機種、設定によっては撮影場所。画像そのものがデータで、これらは画像を説明するメタデータです。
• 文書のファイル：作成者・作成日・更新日。本文がデータで、これらは文書を説明する情報です。
• Webページ：ページの題名と説明文。HTMLのtitle要素や、meta要素のdescriptionに書き、検索結果の表示に使われることがあります。

どの例でも、メタデータは中身そのものではなく、中身を探したり整理したりするための情報です。たとえば撮影日時が記録されているから、写真を日付順に並べられます。データとメタデータをまとめて置く仕組みは、オブジェクトストレージの記事にあります。

データベースでは、表の中の値がデータで、表の形を説明する情報がメタデータです。列の名前・データ型・制約は、CREATE TABLE文で決めるメタデータです。列の意味や単位、どの部署が管理するかも、データを正しく使うためのメタデータです。

メタデータは、データの属性・意味内容・格納場所など、データを管理するための情報です。図の辞書の行は、この3つをそろえた例です。データ型と単位が属性、税抜の売上金額が意味内容、売上表が格納場所に当たります。

データディクショナリとは、データベースにあるデータのメタデータを、1か所に集めて管理するものです。データ辞書とも呼びます。どの表のどの列が何を意味するかを、データディクショナリを引けば確かめられます。

DBMSは、表の定義をシステムカタログに記録する

DBMSも、自分の中にデータディクショナリを持っています。CREATE TABLE文を実行すると、DBMSは表の名前や列の定義を、システム用の表に書き込みます。この表の集まりを、PostgreSQLではシステムカタログと呼び、Oracle Databaseではデータディクショナリと呼びます。

PostgreSQLの文書は、システムカタログを、表や列の情報といったスキーマのメタデータを置く場所と説明しています。表はpg_class、列はpg_attributeというカタログに、1つずつ行として入ります。Oracle Databaseの文書も、DDLの文を実行するたびにデータディクショナリが書き換わると説明しています。

INFORMATION_SCHEMAは、SQLの標準で決まった見え方

システムカタログの表の名前や形は、製品ごとに違います。そこでSQLの標準は、表や列の定義を問い合わせるためのビューの集まりを定めています。このビューの集まりを、INFORMATION_SCHEMAと呼びます。対応している製品なら、製品が違っても同じ名前で問い合わせられます。

SELECT table_name, column_name, data_type, is_nullable
FROM information_schema.columns
WHERE table_schema = 'public';

この文は、自分で作った表の列を、データ型やNULLを許すかどうかと一緒に一覧にします。データを問い合わせるのと同じSELECT文で、メタデータも問い合わせられます。カタログはDBMSがSQL文に合わせて書き換えるもので、利用者が手で書き換えるものではありません。

次の図では、顧客表と売上表を作り、列を足して、最後にデータを1行入れます。SQL文を選ぶと、その文まで実行した時点のデータディクショナリが表示され、増えた行が光ります。

一覧の中身は、PostgreSQLで実際に実行して取り出した結果です。ただし、一覧に出しているのは表・列・説明の3つだけです。実際のカタログでは、主キーなどの制約や索引の行も一緒に増えます。

CREATE TABLE 顧客 (
  顧客コード CHAR(5) PRIMARY KEY,
  顧客名     VARCHAR(40) NOT NULL
);

CREATE TABLE 売上 (
  売上番号   INTEGER PRIMARY KEY,
  顧客コード CHAR(5) REFERENCES 顧客 (顧客コード),
  金額       INTEGER CHECK (金額 >= 0)
);

ALTER TABLE 売上 ADD COLUMN 売上日 DATE;

COMMENT ON COLUMN 売上.金額 IS '税抜の金額。単位は円';

INSERT INTO 顧客 VALUES ('C0001', '北山商店');

表の定義を変える文では行が増え、データを入れるINSERT文では増えません。データディクショナリが記録しているのは、データの中身ではなく、データの形と意味だからです。列の説明はCOMMENT文で付けられ、PostgreSQLではpg_descriptionというカタログに入ります。

部署ごとに表を作ると、同じものに違う名前が付いたり、同じ名前で違うものを指したりします。このずれがあると、2つの表をつないで集計したときに、数字が合わなくなります。データディクショナリで名前と意味をそろえる作業を、データ項目の標準化と呼びます。

標準の名前と意味を辞書に決めておけば、新しい表を作る人もその名前を使います。同じデータを別々の名前で二重に持つことも減ります。データを集めて分析するときにも、この標準化の考え方を使います。

リポジトリは、ソフトウェアの開発と保守に関わる様々な情報を、一元的に管理するものです。データディクショナリがデータの説明を集めるのに対し、リポジトリは開発の情報まで含めて集めます。データディクショナリもリポジトリも、データ資源管理で扱う仕組みです。

IRDSは、Information Resource Dictionary Systemの略です。日本語では情報資源辞書システムといい、データディクショナリと同じく、データ資源管理で扱う用語です。

表の形に収まるデータを、構造化データと呼びます。JSONのように項目名は付くが形の決まりが緩いデータは半構造化データで、画像や音声、文章は非構造化データです。構造化データは、表の定義そのものがメタデータになります。

データレイクは、形式の違うデータを構造を決めずに置く場所です。詳しくはデータウェアハウスの記事で説明しています。データレイクには表の定義が無いので、何がどこにあるかを別に記録しないと、置いたデータを探しにくくなります。AWSの解説も、データを使えるようにするには、カタログを作る仕組みが必要だと説明しています。

• PostgreSQL 18 文書「System Catalogs」（システムカタログとpg_class・pg_attribute・pg_description）
• PostgreSQL 18 文書「The Information Schema」（SQLの標準で定められた情報スキーマ）
• PostgreSQL 18 文書「columns」（information_schema.columnsの列）
• Oracle Database Concepts「Data Dictionary and Dynamic Performance Views」（データディクショナリとDDL）
• AWS「データレイクとは」（データレイクのカタログ）