「スキーマとデータベースって、何が違うの？」「テーブルとの関係はどうなっているの？」
データベースを学ぶ中で、このような疑問を持つ方は少なくありません。
スキーマ・データベース・テーブルという三つの概念は密接に関連していますが、それぞれ異なる意味と役割を持っています。
さらに、DBMSの種類によってこれらの概念の扱い方が異なるため、混乱が生じやすいのです。
本記事では、スキーマとデータベースの違い・テーブルとの関係・主要なDBMS別の概念の違いをSQLの例を交えてわかりやすく解説していきます。
スキーマとDBの違いとは？基本的な概念の整理
それではまず、スキーマとデータベースの基本的な概念の違いについて解説していきます。
スキーマとデータベースの関係を理解するためには、まず「データベース（DB）」という言葉の意味を整理することが重要です。
データベース（DB）とは、関連するデータを体系的に格納・管理するための仕組み全体を指します。
一方、スキーマとはそのデータベース内のデータ構造の定義・またはオブジェクトの名前空間を指します。
ANSI/ISOの三層スキーマモデル
データベースの標準化機関であるANSI/ISOは、データベースを三層のスキーマで定義しています。
1. 外部スキーマ（External Schema / View Level）
ユーザーやアプリケーションが見るデータの「ビュー」。各ユーザーに必要な部分だけを見せる論理的な定義。
2. 概念スキーマ（Conceptual Schema / Logical Level）
データベース全体の論理的な構造定義。テーブル・列・制約・関係性などの定義がここに含まれる。
3. 内部スキーマ（Internal Schema / Physical Level）
データの物理的な格納方法に関する定義。ファイル構造・インデックス・ストレージなどを含む。
この三層モデルでは、スキーマはデータベースの設計のレベルを示す概念であり、データベースの中に複数のスキーマ層が存在する構造になっています。
DBMSごとのスキーマとデータベースの関係
スキーマとデータベースの関係はDBMS（データベース管理システム）によって大きく異なります。
| DBMS | データベースとスキーマの関係 | 特記事項 |
|---|---|---|
| PostgreSQL | 1DBに複数スキーマが存在できる | デフォルトスキーマはpublic |
| SQL Server | 1DBに複数スキーマが存在できる | デフォルトスキーマはdbo |
| MySQL | スキーマ＝データベース（同義語） | CREATE SCHEMAとCREATE DATABASEが等価 |
| Oracle | ユーザー＝スキーマ（1対1対応） | DBは一つ、スキーマはユーザーごと |
| SQLite | ファイル＝データベース（スキーマ概念は薄い） | 組み込み用途に特化 |
MySQLでは「スキーマ」と「データベース」が同義語として使われており、CREATE SCHEMA文とCREATE DATABASE文が全く同じ意味を持ちます。
この仕様がMySQLとPostgreSQL・SQL Serverの間での概念の混乱を招くことがよくあります。
スキーマ・テーブル・データベースの階層関係
続いては、スキーマ・テーブル・データベースの階層関係について確認していきます。
PostgreSQLやSQL Serverを例に取ると、データベース・スキーマ・テーブルの関係は以下のような階層構造になっています。
PostgreSQLにおける階層構造
PostgreSQLの階層構造
データベースサーバー（クラスター）
└ データベース（例：company_db）
├ スキーマ（例：sales）
│ ├ テーブル（例：orders）
│ ├ ビュー（例：monthly_sales）
│ └ インデックス
└ スキーマ（例：hr）
├ テーブル（例：employees）
└ テーブル（例：departments）
この階層構造から、データベースはスキーマを包含し、スキーマはテーブルを包含するという関係が明確にわかります。
「データベース＞スキーマ＞テーブル」という入れ子の関係です。
スキーマを使ったSQL操作の例
PostgreSQLでスキーマを活用した操作を見てみましょう。
スキーマの作成
CREATE SCHEMA sales;
CREATE SCHEMA hr;
スキーマを指定してテーブルを作成
CREATE TABLE sales.orders (
order_id SERIAL PRIMARY KEY,
customer_name VARCHAR(100),
order_date DATE
);
スキーマを指定してテーブルを参照
SELECT * FROM sales.orders;
SELECT * FROM hr.employees;
このように「スキーマ名.テーブル名」という形式で参照することで、異なるスキーマの同名テーブルを明確に区別できます。
スキーマパスとデフォルトスキーマの概念
PostgreSQLでは「search_path」という設定で、スキーマ名を省略した際にどのスキーマを検索するかを制御できます。
デフォルトのsearch_pathは「$user, public」であり、ユーザー名と同名のスキーマを最初に検索し、次にpublicスキーマを検索します。
これにより、よく使うスキーマを省略形で参照できるようになり、SQLの記述が簡潔になります。
スキーマ設計でよくある疑問と回答
続いては、スキーマ設計に関するよくある疑問と回答を確認していきます。
実際の開発現場でよく出る疑問をQ&A形式でまとめました。
スキーマを分けるべきかどうかの判断基準
スキーマを分けるかどうかは、プロジェクトの規模・チーム構成・セキュリティ要件によって異なります。
業務領域が明確に分かれており（販売・人事・会計など）、異なるチームが担当する場合や、アクセス権限を業務ドメイン単位で管理したい場合は、スキーマを分割することで管理の効率化とセキュリティの向上が期待できます。
一方、小規模なプロジェクトや単一チームでの開発では、スキーマ分割によるオーバーヘッドが逆効果になる可能性もあります。
スキーマを跨いだJOINは可能か？
PostgreSQL・SQL Serverなどでは、同じデータベース内の異なるスキーマ間でのJOINが可能です。
異なるスキーマのテーブルをJOINする例
SELECT s.order_id, h.employee_name
FROM sales.orders s
JOIN hr.employees h ON s.sales_rep_id = h.employee_id;
スキーマを跨いだJOINは技術的には問題なく可能です。
ただし、スキーマ間の依存関係が複雑になりすぎると保守性が低下するため、必要な関係性に絞った設計が重要です。
スキーマとセキュリティの関係について特に重要なポイントがあります。
スキーマ単位での権限管理を活用することで、データベースのセキュリティを効率的に強化できます。
例えば、開発者には開発用スキーマへのフルアクセスを与えつつ、本番データを含む別スキーマへのアクセスは制限するといった運用が可能です。
このようなスキーマを活用した権限管理は、情報漏洩リスクの低減と監査対応においても非常に効果的です。
まとめ
本記事では、スキーマとデータベースの違い・テーブルとの階層関係・DBMSごとの概念の違い・実際のSQL例・設計の判断基準について解説してきました。
スキーマとデータベースの概念はDBMSによって異なるため、使用するDBMSの仕様を正確に理解した上で設計・操作を行うことが重要です。
PostgreSQLやSQL Serverでは「データベース＞スキーマ＞テーブル」という階層構造を理解し、スキーマを名前空間・アクセス制御・論理的整理のツールとして活用することで、より堅牢で管理しやすいデータベースシステムの構築が実現できるでしょう。
