スキーマとは — 3 つの意味を整理する

DB 設計の話に「スキーマ (schema)」という単語がよく登場しますが、文脈によって指しているものが違います。初学者が混乱しやすいポイントなので、最初に 3 つの意味を整理しておきましょう。

本サイトの「設計ガイド」で「スキーマ」と書くときは、基本的に ① の構造定義の意味で使っています。②③ は RDBMS の管理単位の話で、設計論とは別軸です。

最も広い意味で、その DB にどんなテーブルがあり、どんな列・制約・関係で構成されているかの全体像を指します。CREATE TABLE / CREATE INDEX / ALTER TABLE などの DDL を全部集めたもの、と言い換えても通じます。

この意味でのスキーマには、次のようなものがすべて含まれます。

• テーブルと列、型、NULL 許容、デフォルト値
• 主キー・外部キー・UNIQUE・CHECK 制約
• インデックス、ビュー、関数、トリガ
• これらの変更履歴（マイグレーション）

チームが「スキーマレビュー」「スキーマ変更」と言うときは、ほぼこの意味です。データモデル設計 = データの持ち方のルール設計。正規化や ER 図はすべてこの層の話題です。なお「スキーマ設計」という呼称は、下記の通り意味②・意味③と衝突するため、本サイトでは以降「データモデル設計」で統一します。

PostgreSQL・SQL Server・Oracle では、1 つの database の中に複数の schema（名前空間）を作れます。オブジェクトの完全修飾名は database.schema.table の 3 段階になります。

-- PostgreSQL: sales スキーマを作って、その中にテーブルを置く
CREATE SCHEMA sales;
CREATE TABLE sales.orders (id BIGSERIAL PRIMARY KEY, ...);

-- 参照
SELECT * FROM sales.orders;

主な使い道:

• 業務ドメインの分離 — sales / billing / audit のように関心事で分ける
• マルチテナント — テナントごとに別スキーマ（ただし大量テナントには不向き）
• 権限の境界 — ロールに対して「この schema のみ SELECT 可」と制御

PostgreSQL の既定スキーマは public で、スキーマを明示しないとここに作られます。search_path に複数の schema を並べておくと、修飾なしで検索できます。

※ MySQL には「名前空間としての schema」はありません（意味 ③ に吸収されています）。

MySQL / MariaDB では SCHEMA と DATABASE は完全に同じものです。CREATE SCHEMA と CREATE DATABASE は同じ操作、SHOW SCHEMAS と SHOW DATABASES も同じ結果を返します。

-- MySQL: どちらも同じ
CREATE DATABASE app_db;
CREATE SCHEMA   app_db;   -- ↑ と同じ意味

SHOW DATABASES;
SHOW SCHEMAS;              -- 同じ結果

そのため MySQL 系で「スキーマを作って…」と言われたら、それはデータベースを作るという意味です。名前空間としての中間層は MySQL には存在せず、完全修飾は database.table の 2 段階になります。

PostgreSQL 経験者が MySQL に来て混乱する最大の点がここです。「じゃあ PG の schema 相当は？」と言われたら、MySQL では別 database を作る、あるいはテーブル名にプレフィックス（sales_orders 等）を付ける、という運用になります。

議論が噛み合わなくなりそうなときは、「スキーマ」を言い換えるのが一番早い解決策です。

• 構造の話をしている ➜ 「テーブル構造」「DDL」「データモデル」
• 名前空間の話をしている ➜ 「PostgreSQL の schema」「名前空間」
• MySQL の話をしている ➜ 「データベース」

設計レビューで「スキーマ変更が必要」と言われたら、まず「構造の話？ 名前空間の話？」と聞くと齟齬が減ります。本サイトでは意味が複数ある語を避け、意味 ①（構造設計）は「データモデル設計」という呼称で統一します（サイドバーのカテゴリも「データモデル設計ガイド」）。