変更要約: DP-420 第1章を新規作成（ドメイン1前半: 非リレーショナルモデリング(embed vs reference/非正規化/id・パーティションキー・一意キー/既定 TTL/バージョニング)、パーティション設計(キー選定/ホットパーティション・429/クロスパーティションコスト/データ・スループット分散/合成キー/階層パーティションキー/同一論理パーティション内トランザクション)、サイジングとスケーリング(RU/s/サーバーレス vs プロビジョニング vs Free/オートスケール/データベースレベルスループット/グローバル分散コスト)）。
1.1非リレーショナルデータモデリング
Azure Cosmos DB for NoSQL の非リレーショナルモデリング＝埋め込み（embed）と参照（reference）、非正規化、同一コンテナへの複数エンティティ型、id・パーティションキー・一意キー、既定 TTL、バージョニングを理解します。
Azure Cosmos DB for NoSQL は JSON ドキュメントを格納する非リレーショナル DB です。リレーショナルの正規化とは逆に、アクセスパターン（どう読むか） を起点にモデルを設計します。「一緒に読むものは一緒に格納する」が基本思想です。
1.1.1埋め込みと参照・非正規化
埋め込み（embed） は関連エンティティを 1 つのドキュメントに入れ、1 回の読み取りで取得できる（1:1 や 1:少数・一緒に読む・更新頻度が低い場合に有利）。参照（reference） は別ドキュメントに分け id で結ぶ（1:多数・各々を独立に更新・サイズが大きい場合に有利）。非正規化（denormalize） は読み取りを速くするために重複を許してデータを複製する。Cosmos DB では「読み取りの形」に合わせ、しばしば複数のエンティティ型を同一コンテナに格納し type 等で区別する。
1.1.2id・キー・TTL・バージョニング
各項目は id と パーティションキー で一意に識別される（id はパーティション内で一意）。一意キー（unique key） はパーティション内で特定フィールドの一意性を強制する。既定 TTL（Time to Live） をコンテナに設定すると古い項目を自動削除でき、トランザクションストアのデータ寿命を管理できる（項目ごとに TTL を上書きも可能）。スキーマレスゆえ、ドキュメント/スキーマのバージョニング（version フィールドやスキーマ進化）を設計してアプリの後方互換を保つ。
決め手：「一緒に読む・更新頻度低・1:少数」＝埋め込み。「独立更新・1:多数・大サイズ」＝参照。「読み取り高速化のため複製」＝非正規化。「古い項目を自動削除」＝既定 TTL。一意性強制＝一意キー（パーティション内）。
混同に注意：
①埋め込み（速いが更新コスト/サイズ増）と参照（柔軟だが複数読み取り）はトレードオフ。
②非正規化した複製の整合は Change Feed 等で別途保つ必要がある。
③一意キーはパーティション内のみ・コンテナ作成後は変更不可。
④TTL はトランザクションストア対象で、分析ストアの保持とは別。
1.1.3この節のまとめ
- アクセスパターン起点で設計＝埋め込み(一緒に読む) vs 参照(独立更新)・非正規化で読み取り高速化
- 項目は id＋パーティションキーで一意、一意キーはパーティション内の一意性を強制
- 既定 TTL で古い項目を自動削除、スキーマレスゆえバージョニングを設計
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 注文と少数の明細を常に一緒に読み、明細の更新頻度が低い。Cosmos DB for NoSQL で最適なモデリングはどれですか？
Q2. 1 顧客に大量かつ独立に更新される注文が紐づく。最適なモデリングはどれですか？
Q3. トランザクションストアの古い項目を一定期間後に自動削除したい。最適なのはどれですか？
Q4. あるフィールドの値をパーティション内で重複させたくない。最適なのはどれですか？
Q5. 非正規化で複製したデータの整合性を保つ一般的な方法はどれですか？