データベースを設計・運用する上で「スキーマ」の概念は欠かせない知識です。
データベーススキーマとはDB全体の論理的な構造設計図であり、テーブル・カラム・データ型・制約・リレーションなどをすべて含む定義体系です。
本記事では、データベーススキーマの基本概念から、Oracle・MySQL・PostgreSQLなど主要RDBMSでのスキーマの扱い、SQL設計の実践的な手法まで詳しく解説します。
データベース初学者からスキーマ設計を深めたい中級者まで、幅広くお役立ていただける内容となっています。
データベーススキーマとは何か？基本概念と役割
それではまず、データベーススキーマの基本概念と役割について解説していきます。
データベーススキーマとは、データベースの全体的な構造・設計を定義した論理的な仕様書のことです。
データベーススキーマに含まれる要素：
・テーブル（表）の名前と構造
・カラム（列）の名前・データ型・NULL制約
・主キー・外部キー・一意制約などの制約
・インデックスの定義
・ビュー・ストアドプロシージャ・トリガーの定義
・テーブル間のリレーション（関係）
スキーマはデータベースの「設計図」であり、実際のデータ（レコード）とは区別されます。
「データは変わっても、スキーマは（変更なければ）一定」というのがデータベース設計の基本的な考え方です。
スキーマの三層構造（ANSI/SPARCモデル）
1975年にANSI（米国標準化協会）が提唱したANSI/SPARCモデルは、データベーススキーマを3層に分けて定義しています。
| 層 | 名称 | 説明 |
|---|---|---|
| 外部スキーマ | ユーザービュー層 | 各ユーザー・アプリから見たデータの姿 |
| 概念スキーマ | 論理層 | DB全体の論理的な構造（通常「スキーマ」と呼ぶ） |
| 内部スキーマ | 物理層 | データの物理的な格納方式・ファイル構造 |
この3層分離によって、物理的なデータ格納方式が変わっても論理的なスキーマ（ユーザーから見えるデータ構造）は影響を受けない「データ独立性」が実現されます。
スキーマとデータベースの関係
RDBMSによって「スキーマ」と「データベース」の関係は異なります。
MySQLでは「データベース」と「スキーマ」はほぼ同義語として扱われますが、OracleやPostgreSQLでは「データベースの中に複数のスキーマが存在する」という階層構造です。
Oracleでは「スキーマ = ユーザー」という対応関係があり、ユーザーごとに固有のスキーマ（オブジェクトの集合）が割り当てられます。
主要RDBMSでのスキーマの扱い
続いては、MySQL・PostgreSQL・Oracleなど主要なRDBMSにおけるスキーマの扱いを確認していきます。
MySQLでのスキーマ操作
MySQLでは「CREATE DATABASE」と「CREATE SCHEMA」は同義で、どちらもデータベース（スキーマ）を作成します。
MySQLでのスキーマ操作：
— スキーマ（データベース）の作成
CREATE SCHEMA myapp_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
— スキーマ一覧の表示
SHOW DATABASES;
— スキーマの選択
USE myapp_db;
PostgreSQLでのスキーマ操作
PostgreSQLでは一つのデータベースの中に複数のスキーマを作成でき、オブジェクト（テーブル等）はスキーマに属します。
PostgreSQLでのスキーマ操作：
— スキーマの作成
CREATE SCHEMA sales;
— スキーマを指定したテーブル作成
CREATE TABLE sales.orders (id SERIAL PRIMARY KEY, amount NUMERIC);
— スキーマ一覧の確認
SELECT schema_name FROM information_schema.schemata;
PostgreSQLのデフォルトスキーマは「public」であり、スキーマを明示しない場合はpublicスキーマにオブジェクトが作成されます。
Oracleでのスキーマの概念
OracleではDBユーザーを作成すると同時に同名のスキーマが自動的に作成されます。
スキーマはそのユーザーが所有するすべてのデータベースオブジェクト（テーブル・ビュー・シーケンス・プロシージャなど）の集合として定義されます。
Oracleのマルチテナント構成（CDB/PDB）では、さらに階層的なスキーマ管理が可能になっています。
スキーマ設計の実践的手法
続いては、実際のシステム開発で使われるスキーマ設計の実践的な手法を確認していきます。
ER図によるスキーマ設計
スキーマ設計では、まずER図（Entity-Relationship Diagram）を使ってエンティティ（テーブル）とリレーション（関係）を視覚的に整理します。
ER図で定義した構造をSQLのCREATE TABLE文として実装することで、論理設計から物理設計への移行が行われます。
正規化によるスキーマ最適化
正規化とは、データの冗長性を排除してデータの整合性を保つためのスキーマ設計手法です。
第1正規形・第2正規形・第3正規形・ボイスコッド正規形という段階があり、一般的なシステムでは第3正規形まで正規化することが基本とされています。
パフォーマンス向上のために意図的に冗長性を持たせる「非正規化」も状況によっては有効な設計選択です。
スキーマバージョン管理とマイグレーション
システム開発においてスキーマはアプリケーションの成長とともに変化します。
FlywayやLiquibaseといったDBマイグレーションツールを使うことで、スキーマの変更履歴をバージョン管理し、チーム開発での整合性を保つことができます。
スキーマのバージョン管理はコードのバージョン管理（Git等）と並ぶ現代的なDB開発の必須プラクティスといえるでしょう。
まとめ
データベーススキーマはDB全体の論理的な構造定義であり、テーブル・カラム・制約・リレーション・インデックスなどを包括した設計図です。
ANSI/SPARCモデルによる3層（外部・概念・内部）の分類によりデータ独立性が保証されます。
MySQL・PostgreSQL・Oracleではスキーマの扱いに違いがあり、それぞれの仕様を理解した上で設計することが重要です。
ER図・正規化・マイグレーション管理を組み合わせたスキーマ設計の実践がシステムの品質と保守性を長期的に支えることになるでしょう。
