変更要約: 初版
3.2SQLの基礎とDDL
DDL（CREATE/ALTER/DROP）によるスキーマ定義、制約（主キー・外部キー・CHECK・NOT NULL・一意制約）の設計判断、DCL（GRANT/REVOKE）による権限管理、COMMIT/ROLLBACKによるトランザクション確定を、実務のスキーマ変更・権限設計の視点とともに学びます。
SQLはDDL（Data Definition Language：スキーマ定義）・DML（Data Manipulation Language：データ操作）・DCL（Data Control Language：権限制御）の3種類に大別されます。DBスペシャリストが最も注意を払うべきはDDLの中でも制約設計です。制約は「後から気づいたデータ不整合を直す」コストと「事前に不正なデータを拒否する」コストのトレードオフであり、どこまで厳格に制約を課すかは業務要件次第です。この節ではDDL・制約・DCLの実務判断を扱います。
3.2.1DDL：CREATE・ALTER・DROP
- CREATE＝表・ビュー・インデックス等のオブジェクトを新規定義する。
CREATE TABLEでは列名・データ型に加え、後述の制約をあわせて宣言する。ALTER＝既存オブジェクトの定義を変更する（列追加ADD COLUMN・削除DROP COLUMN・制約追加等）。DROP＝オブジェクトを完全に削除する（データも失われ、原則としてロールバック不可の製品もある）。 - 本番稼働中の大規模表に
ALTER TABLEで列を追加する場合、製品によっては表全体の書き換え（ロック）が発生し長時間の排他ロックで他の処理が待たされることがある。DBAは深夜メンテナンス枠での実施や、オンラインDDL機能の有無を事前に確認する必要がある。
3.2.2制約設計
- 主キー制約（PRIMARY KEY）＝行を一意に識別する列（群）。自動的に一意性とNOT NULLを兼ねる。外部キー制約（FOREIGN KEY／参照制約）＝他表の主キー（または一意キー）を参照し、存在しない値の登録や、参照されている行の削除を防いで参照整合性を保つ。
- CHECK制約＝列の値が特定の条件（範囲・パターン等）を満たすことを保証する。一意制約（UNIQUE）＝主キー以外の列でも重複を禁止できる（例：メールアドレス列）。NOT NULL制約＝その列に未入力（NULL）を許さない。
- 外部キー制約に付与する
ON DELETE句にはCASCADE（親削除で子も連鎖削除）・RESTRICT/NO ACTION（子が存在する限り親削除を拒否）・SET NULL（子の外部キー列をNULLにする）があり、業務要件に応じてどの挙動にするかは慎重な設計判断を要する（誤ってCASCADEにすると想定外の連鎖削除で大量データ喪失につながる）。
3.2.3DCL：GRANT・REVOKEとトランザクション確定
- GRANT＝ユーザーやロールに対してオブジェクトへの操作権限（
SELECT/INSERT/UPDATE/DELETE等）を付与する。REVOKE＝付与済みの権限を取り消す。最小権限の原則に従い、業務上必要な操作のみを許可するのが安全な設計。 - DCLに分類されることもある
COMMIT（トランザクションの変更を確定）・ROLLBACK（変更を取り消し元に戻す）はトランザクション制御文（TCL）と呼ばれることも多い。DDL文（CREATE等）は製品によって暗黙的に直前のトランザクションをコミットする（自動コミット）ため、DDLとDML/TCLの混在順序には注意が必要。
「外部キーのON DELETE CASCADEは親削除で子も連鎖削除・SET NULLは子の外部キーをNULL化・RESTRICTは子が存在すれば親削除を拒否」「GRANT=権限付与、REVOKE=権限取消、最小権限の原則」が最頻出です。CHECK制約とNOT NULL制約・一意制約の役割の違いも混同しないこと。
あるDBAが受注管理システムの改修で「注文（orders）表から顧客（customers）表を参照する外部キーがあるが、顧客を退会させる際にどう扱うべきか」という相談を受けたとします。単純にON DELETE CASCADEを設定すると、顧客が退会するたびにその顧客の全注文履歴が連鎖削除され、売上集計や監査ログに必要な過去データまで失われるリスクがあります。逆にON DELETE RESTRICTにすると、注文履歴が1件でも残っている顧客は物理削除できなくなり、退会処理自体が失敗します。実務でよく採用される設計は、顧客表にis_deleted（論理削除フラグ）やretired_at（退会日時）列を追加し、物理削除は行わずに論理削除で退会を表現する方式です。この場合、外部キー制約はON DELETE RESTRICTのままで構いません（論理削除では実際にDELETE文を発行しないため、参照整合性違反は起きない）。加えて、退会済み顧客のメールアドレスを再利用可能にしたいという要件があるなら、メールアドレス列の一意制約を「退会済みでない顧客の中でのみ一意」という部分一意制約（対応する製品では部分インデックスで実現）に変更する判断も必要になります。このように、外部キーのON DELETE挙動や制約の厳格さは、削除の意味（物理削除か論理削除か）や将来のデータ再利用要件まで踏まえて設計するのがDBスペシャリストの役割です。
| 句 | 挙動 |
|---|---|
| CASCADE | 親の削除に連動して子行も削除する |
| RESTRICT / NO ACTION | 参照する子行が存在する限り親の削除を拒否する |
| SET NULL | 子行の外部キー列をNULLに設定して親を削除する |
ひっかけ： 「外部キー制約のON DELETE句を省略すると自動的にCASCADEになる」は誤りです——省略時の既定はRESTRICT/NO ACTION相当（連鎖削除は明示的にCASCADEを指定した場合のみ）が一般的です。また「GRANTで付与した権限はDROP USERしない限り取り消せない」も誤り＝REVOKE文で個別に取り消せます。
3.2.4この節のまとめ
- DDL（CREATE/ALTER/DROP）はスキーマ定義。本番大規模表への
ALTERはロック影響を事前確認する - 外部キーのON DELETE（CASCADE/RESTRICT/SET NULL）は削除の意味（物理/論理）を踏まえて選ぶ
- GRANT/REVOKEは最小権限の原則に従い、必要な操作のみを許可する
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 顧客の退会時に注文履歴を保持したまま参照整合性も維持したい。最も適切な設計はどれか。
Q2. 本番稼働中の大規模な注文表にALTER TABLEで新しい列を追加する計画がある。事前に確認すべき最も重要な観点はどれか。
Q3. 複数のアプリケーション用ユーザーに対し、業務上必要な操作のみを許可したい。この方針に最も合致する権限設計はどれか。