変更要約: AZ-305 第2章を深掘り（比較表・シナリオ・FAQ・ひっかけ・深掘り段落を各節に追加、図を日本語版に対応）
2.1リレーショナルデータベースの設計
リレーショナルデータの選択——Azure SQL Database／SQL Managed Instance／SQL on VM、サービスレベル、Azure Database for PostgreSQL/MySQL——を理解します。要件に合うマネージド DB を選びます。
リレーショナルデータは管理負荷と互換性のトレードオフで選びます。フルマネージドの Azure SQL Database が基本です。
2.1.1リレーショナルの選択肢
- Azure SQL Database：フルマネージドな PaaS。サービスレベル（GP/BC/Hyperscale）やサーバーレスを選択。
- SQL Managed Instance：オンプレ SQL Server との高い互換性（インスタンス機能/SQL Agent 等）。
- SQL on VM：OS/SQL を完全制御（IaaS）。最も管理負荷が大きい。
- PostgreSQL/MySQL：オープンソース向けのマネージド DB。
「フルマネージドの既定＝Azure SQL Database」「オンプレ SQL Server の機能互換が必要＝SQL Managed Instance」「OS/SQL を完全制御＝SQL on VM」「超大規模/高速スケール＝Hyperscale」 は AZ-305 で頻出です。可能な限り管理負荷の低い PaaS を選びます。
AZ-305 のデータ設計は「互換性・規模・可用性・コストの要件から、どの SQL 系サービスとどの構成を選ぶか」を問います。Azure SQL Database は単一データベースとエラスティックプール（複数 DB で DTU/vCore を共有しコスト最適化）を選べ、購入モデルは vCore（柔軟・Hybrid Benefit でライセンス持ち込み）と DTU（簡易バンドル）があります。サービスレベルは General Purpose（バランス）・Business Critical（低遅延ローカル SSD＋読み取りレプリカ＋ゾーン冗長で高可用性）・Hyperscale（最大 100TB 級・高速バックアップ/復元・読み取りスケールアウト）。需要が断続的ならサーバーレス（自動一時停止）が有効です。SQL Managed Instance はインスタンススコープの機能（SQL Agent、クロス DB クエリ、CLR、リンクサーバー）やほぼ完全な T-SQL 互換が要る移行に向き、VNet 内に配置されます。SQL on VM は OS とパッチを自分で管理する代わりに完全制御が得られます。PostgreSQL/MySQL はフレキシブルサーバーで AZ 冗長や柔軟なメンテナンスが可能です。可用性はゾーン冗長やフェイルオーバーグループ（geo）で、移行は Azure Database Migration Service と互換性評価で設計します。設計の要は、まず最もマネージドな選択肢から検討し、互換性や制御の要件がある場合だけ Managed Instance / VM に降りることです。
| 要件 | 選択 | 要点 |
|---|---|---|
| 管理負荷最小の新規開発 | Azure SQL Database | PaaS・サーバーレス/エラスティックプール |
| オンプレ SQL の機能互換移行 | SQL Managed Instance | SQL Agent/クロス DB・VNet 内 |
| OS/SQL の完全制御 | SQL on VM | IaaS・最大の管理負荷 |
| 超大容量/高速スケール | Hyperscale 層 | 〜100TB・読み取りスケールアウト |
シナリオ：オンプレの SQL Server を移行するが、SQL Server Agent ジョブやクロスデータベースクエリ、リンクサーバーに依存している。最小の改修で移したい。→ これらはインスタンススコープ機能のため SQL Managed Instance を選択（Azure SQL Database 単一 DB では一部非対応）。VNet 内に配置し、Azure Database Migration Service でほぼ無停止移行。可用性が要ればゾーン冗長やフェイルオーバーグループを併用します。
FAQ：General Purpose と Business Critical はどう選ぶ？ コストとバランス重視なら General Purpose（リモートストレージ）。低遅延（ローカル SSD）・組み込みの読み取りレプリカ・より高い可用性（ゾーン冗長）が要るミッションクリティカルなら Business Critical。超大容量や高速復元が要るなら Hyperscale を別途検討します。
ひっかけ：「管理負荷を下げたい」要件で安易に SQL on VM を選ぶのは誤り——IaaS は OS/パッチ/バックアップを自分で管理するため最も負荷が高いです。まず Azure SQL Database、機能互換が要るなら Managed Instance、完全制御がどうしても要る場合のみ VM、の順で検討します。
2.1.2この節のまとめ
- 既定＝Azure SQL Database（PaaS）／互換性＝Managed Instance
- 完全制御＝SQL on VM／OSS＝PostgreSQL/MySQL
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 管理負荷を最小化しつつリレーショナル DB を使いたい。既定で選ぶべき Azure のサービスはどれですか?
Q2. オンプレの SQL Server を、インスタンス機能や SQL Agent の互換性を保ったまま移行したい。何を使いますか?
Q3. OS と SQL Server の構成を完全に制御する必要がある。どの選択肢ですか?