DATABASE / METADATA / SYSTEM CATALOG

データディクショナリとは？DBの「設計図」をSQLで調べる仕組み

ネットショップの「顧客一覧」を保存しているデータベース。では、顧客IDが数字か文字列か、メールアドレスが必須か、誰がその表を閲覧できるかという決まりは、どこで管理されているのでしょうか。ここからデータディクショナリを理解します。

最初に結論

データディクショナリとは、DBMSが管理する「データについてのデータ（メタデータ）」を集めたもの。

商品・注文・顧客そのものではなく、表や列の定義、制約、インデックス、ユーザーや権限などの情報を扱います。製品ごとにシステムカタログなどの呼び方もあります。

1. 身近な例：ネットショップの顧客データ

ECサイトの会員登録で「山田さん、メールアドレス、登録日」を保存したとします。管理する情報には、種類が異なる2つのものがあります。

業務データ（中身）

customers 表

customer_id	email
101	a@example.test
102	b@example.test

実際に登録された顧客の値。

メタデータ（決まり）

データディクショナリ

customers はテーブル

customer_id は INTEGER / 主キー

email は VARCHAR / NULL不可

データの構造や利用条件を定義する情報。

本棚でたとえると「本の本文」が業務データ、「目録に書かれたタイトル・分類・貸出条件」がメタデータです。**データディクショナリはDBMSの目録**と考えると分かりやすくなります。

2. どんな情報が入っている？

テーブル・ビュー

どんな表やビューが存在するか。例：customers、orders。

列とデータ型

customer_id は整数、email は文字列、created_at は日時。

制約

主キー、外部キー、NOT NULL、UNIQUE、CHECKなどの規則。

インデックス

検索高速化のためにどの列へ索引を作ったか。

利用者・権限

どのユーザーやロールがSELECT・INSERTなどを実行できるか。

スキーマなどの構造

テーブルの所属やデータベースオブジェクト間の関係。

ただし、どの情報がどのビューから見えるか、権限情報がどこに格納されるかはDBMSによって異なります。パスワードの平文そのものを誰でも読めるという意味ではありません。

3. DBMSはいつ使っているのか

開発者が SELECT email FROM customers; を実行すると、DBMSは列名が存在するか、型やアクセス権は適切かなどを確認して処理します。そこでデータディクショナリの情報が利用されます。

アプリから SQL を実行

↓

DBMS：表と列は存在する？権限はある？

↓ 定義を参照

データディクショナリ（メタデータ）

↓ 許可されれば処理

業務データから結果を取得

これは概念図です。実際のDBMSはメタデータをメモリへキャッシュするなど、処理を高速化する工夫も行います。

4. SQLで確認する：information_schema

PostgreSQLなどでは、標準的なメタデータ参照インターフェースとして information_schema が使えます。たとえばテーブルの列定義を調べるなら、次のSQLです。

SELECT column_name, data_type, is_nullable
FROM information_schema.columns
WHERE table_schema = 'public'
  AND table_name = 'customers'
ORDER BY ordinal_position;

結果のイメージは「customer_id / integer / NO」「email / character varying / NO」のようになります。値そのものではなく、**列の名前・型・NULL可否**が返る点がポイントです。表示される情報はDBMSと権限に依存します。

information_schema とシステムカタログは同じ？

どちらもメタデータを参照するための仕組みですが、正確には違います。information_schema はSQL標準に基づくビュー群、PostgreSQLの pg_catalog などは製品固有の内部管理用カタログです。前者は移植性、後者は製品固有の詳細情報の確認に向きます。

-- PostgreSQL固有の例：テーブル一覧
SELECT schemaname, tablename
FROM pg_catalog.pg_tables
WHERE schemaname = 'public';

5. データディクショナリではないもの

名前が似た「DBMSが使うファイル」と役割を混同しないことが大切です。

種類	何を持つ？	何のため？
データディクショナリ	表の定義・列の型・権限など	DB構造と管理情報の把握
一時領域	ソートや中間計算のデータ	SQL処理中の作業
バックアップ	ある時点のDBデータなどの複製	障害時の復旧
ログ（WAL等）	更新履歴など（方式による）	復旧・整合性維持など

たとえば、顧客データを昨日の状態へ戻したいならバックアップやログが関わります。一方、「顧客テーブルにはどんな列があるか」を知りたいならデータディクショナリです。

6. 操作ラボ：テーブル定義を変えて目録を見よう

ネットショップの customers テーブルに列を追加したり、NULLを禁止したり、閲覧権限を変えたりしてみましょう。業務データとデータディクショナリに現れる内容がどう違うかを確認できます。

INTERACTIVE LAB

ネットショップのテーブル設計を操作

左の変更を選ぶと右の「目録」が変化します。実際のDBには接続せず、ブラウザ内で表示を切り替えます。

① DB管理者の操作

操作を選ぶと、管理情報に反映されます。

② 表示対象を選ぶ

information_schema.columns のイメージ

column_name	data_type	is_nullable
customer_id	integer	NO
name	character varying	NO
email	character varying	NO

制約の例：customer_id=PRIMARY KEY / email=UNIQUE

覚え方：「顧客の氏名が変わる」なら業務データの更新。「email列を必須にする」「SELECT権限を付ける」ならメタデータが変わる。

学習用シミュレーション。SQLの実行やDBへの接続・変更は行いません。実際のメタデータ可視性・権限管理はDBMSに依存します。

7. 実務で役立つ場面

障害調査

SQLで「列が存在しない」と出たら、現在のテーブル定義を確認する。

改修時の影響調査

どの表にどんな列・制約があるか、変更前に確認する。

権限監査

個人情報のテーブルにアクセスできるロールを点検する。

ドキュメント整備

手書きの設計書とDBの現状にズレがないか確認する。

参考資料：PostgreSQL公式マニュアル「System Catalogs」「The Information Schema」、MySQL公式マニュアル「INFORMATION_SCHEMA Tables」。このラボは学習用の模擬表示であり、実際のDBやユーザー権限を変更しません。