# DynamoDB でリレーショナルデータをモデル化するための最初のステップ **注記** NoSQL 設計では、RDBMS 設計とは異なる考え方が必要です。RDBMS の場合は、アクセスパターンを考慮せずに正規化されたデータモデルを作成できます。その後、新しい課題とクエリの要件が発生したら、そのデータモデルを拡張することができます。対照的に、Amazon DynamoDB の場合は答えが必要な質問が分かるまで、スキーマの設計を開始しないでください。ビジネス上の問題とアプリケーションのユースケースを理解することが極めて重要です。 効率的に拡張する DynamoDB テーブルの設計を開始するには、サポートする必要のあるオペレーションおよびビジネスサポートシステム (OSS/BSS) で必要とされるアクセスパターンを特定するために、まずいくつかの手順を実行する必要があります。 + 新しいアプリケーションの場合は、アクティビティや目的に関するユーザーストーリーを確認します。特定するさまざまなユースケースを文書化し、必要なアクセスパターンを分析します。 + 既存のアプリケーションでは、クエリログを分析して、ユーザーが現在どのようにシステムを使用しているか、主要なアクセスパターンを調べます。 このプロセスが完了したら、次のようなリストが表示されます。 **注文入力アプリケーションのアクセスパターン** | パターン \$1 | アクセスパターンの説明 | | --- | --- | | 1 | 従業員 ID で従業員の詳細を検索する | | 2 | 従業員名で従業員の詳細をクエリする | | 3 | 従業員の電話番号を検索する (複数可) | | 4 | 顧客の電話番号を検索する (複数可) | | 5 | 日付範囲内の顧客の注文を取得する | | 6 | 日付範囲内のすべての OPEN の注文を表示する | | 7 | 最近雇用したすべての従業員を確認する | | 8 | 倉庫のすべての従業員を検索する | | 9 | 製品の注文中のすべての項目を取得する | | 10 | すべての倉庫の製品在庫を取得する | | 11 | アカウント担当者別に顧客を取得する | | 12 | アカウント担当者別に注文を取得する | | 13 | 役職を持つ従業員を取得する | | 14 | 商品および倉庫別に在庫を取得する | | 15 | 商品在庫総数を取得する | 実際のアプリケーションでは、リストはさらに長くなる場合があります。しかし、このコレクションは、本番環境で見つかる可能性のあるクエリパターンの複雑さの範囲を表します。 DynamoDB スキーマ設計の最新のアプローチでは、集約指向の原則を使用し、厳格なエンティティの境界ではなくアクセスパターンに基づいてデータをグループ化します。このアプローチでは、複数の設計パターンを考慮します。 + *単一テーブル設計* - 複合ソートキー、オーバーロードされたグローバルセカンダリインデックス、隣接リストパターンを使用して、複数のエンティティタイプを 1 つのテーブルに保存します + *マルチテーブル設計* - 独立した運用特性を持ち、アクセス相関が低いエンティティに個別のテーブルを使用し、エンティティ間のクエリには戦略的な GSI を使用します + *集約設計* - 常に一緒にアクセスされる場合に関連するデータを埋め込む (Order \$1 OrderItems)、または関係を識別するために項目コレクションを使用します (Product \$1 Inventory) これらのアプローチの選択は、特定のアクセスパターン、データ特性、運用要件によって異なります。これらの要素を使用してデータを構造化することで、アプリケーションは、テーブルまたはインデックスの単一のクエリを使用して、特定のアクセスパターンに必要なものを取得できます。 **注記** 単一テーブル設計とマルチテーブル設計の選択は、特定の要件によって異なります。単一テーブル設計は、エンティティのアクセス相関性が高く、運用特性が類似している場合に適しています。エンティティに独立した運用要件や異なるアクセスパターンがある場合、または明確な運用上の境界が必要な場合は、マルチテーブル設計が推奨されます。このガイドの例では、戦略的集約と非正規化によるマルチテーブルアプローチを示しています。 NoSQL Workbench for DynamoDB を使用してパーティションキー設計を視覚化する方法については、「[NoSQL Workbench を使用したデータモデルの構築](workbench.Modeler.md)」を参照してください。