3秒でわかる
テーブルや列、型、制約といったデータの入れ物の定義。どんな形のデータなら受け入れるかを先に決め、壊れたデータの混入を防ぐために書きます。
もう少し詳しく
どういうものか
スキーマはデータの構造を定めた設計図です。リレーショナルデータベースでは、どんなテーブルがあり、各テーブルにどの列が何型で並び、どこに主キーや外部キー、NOT NULL や UNIQUE といった制約が付くのかをまとめたものを指します。PostgreSQL のように、名前空間としての schema(テーブルをまとめる入れ物)を別の意味で持つ製品もあるため、文脈でどちらを指しているかを見分ける必要があります。
データベース以外でも、JSON Schema、GraphQL のスキーマ、Avro のスキーマのように、「受け入れるデータの形の定義」を広くこう呼びます。
なぜ必要か
スキーマは、間違ったデータが入る前に弾くための関門です。メールアドレス列に NULL を許さない、注文行の商品 ID は必ず商品テーブルに存在する、といった条件をスキーマ側に書いておけば、アプリケーションのどこかで検証を書き忘れても、データベースが最後の砦になります。逆にスキーマが緩いと、後から「この列は空文字なのか NULL なのか」という調査に時間を取られます。
具体例
CREATE TABLE members (
id BIGINT AUTO_INCREMENT PRIMARY KEY,
email VARCHAR(255) NOT NULL UNIQUE,
name VARCHAR(100) NOT NULL,
status ENUM('active','suspended') NOT NULL DEFAULT 'active',
created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP
);
CREATE TABLE orders (
id BIGINT AUTO_INCREMENT PRIMARY KEY,
member_id BIGINT NOT NULL,
total INT NOT NULL,
FOREIGN KEY (member_id) REFERENCES members(id)
);orders.member_id に外部キーを付けたので、存在しない会員の注文は登録できません。この一行が、後の集計で行方不明の注文が出る事故を防ぎます。
似た用語との違い
| 語 | 指すもの |
|---|---|
| スキーマ | データの構造と制約の定義 |
| インスタンス | その構造に実際に入っている中身 |
| ER図 | スキーマを図で表した設計成果物 |
| マイグレーション | スキーマを変更する手順を記録したファイル |
つまずきやすいところ
本番のスキーマを手作業の ALTER TABLE で変えていくと、開発環境との差がじわじわ広がり、どこかの環境だけ動かないという事故につながります。変更はマイグレーションファイルとしてコードに残し、全環境で同じ順に適用するのが基本です。もう一つは、後で困らないようにと全列を VARCHAR にして NULL 許容にしてしまう設計で、制約が無いぶん検証はすべてアプリ側の責任になり、書き忘れがそのままデータ汚染になります。