アプリのアクセス パターンを特定する

NoSQL データベースのデータ モデルを設計する際の目的は、データに対する操作が最小限の要求数で実行されるようにすることです。 そのためには、データ間のリレーションシップと、アプリケーションによるデータへのアクセス方法を理解する必要があります。 これらのアクセス パターンが重要なのは、それとリレーションシップによって、さまざまなエンティティのプロパティがグループ化されて、Azure Cosmos DB for NoSQL のコンテナー内のドキュメントに格納される方法が決まるためです。

Azure Cosmos DB for NoSQL では、ドキュメントは項目と呼ばれ、コンテナーは同義でコレクションと呼ばれることがよくあります。

顧客エンティティのアクセス パターンを特定する

まず、eコマース データベース内の顧客エンティティから始めましょう。 次の図は、3 つのエンティティとそれらの間のリレーションシップを示しています。 3 つのエンティティは、 Customer、 CustomerAddress、 CustomerPassword です。 Customer エンティティには、CustomerAddress との 1 対多のリレーションシップがあります。 顧客 は CustomerPassword と 1 対 1 の関係を持っています。

このアプリケーションでは、顧客エンティティに対して次の 3 つの操作を実行します。

• 顧客の作成: 新しいユーザーが最初に e コマース サイトにアクセスすると、新しい顧客が作成されます。
• 顧客を更新する: 既存のユーザーがプロファイル情報を更新すると、顧客レコードが更新されます。
• 顧客を取得する: 既存のユーザーがサイトにアクセスすると、パスワードでサインインします。 同じセッション中に、新しい商品を購入するために他の顧客データ (住所など) にアクセスする必要があります。

このような操作のたびに、このすべてのデータが同時に必要になります。 それらが個別のドキュメントとしてモデル化されているとしたら、顧客データの作成、更新、取得のために、サーバーに何回もラウンドトリップする必要があります。 これは効率的ではありません。

顧客エンティティをモデリングする

Azure Cosmos DB ではデータが JSON として格納されるため、Customer と CustomerAddress の間の 1:Many リレーションシップをモデル化し、顧客アドレス データを配列として埋め込むことができます。 Customer と CustomerPassword の間の 1 対 1 の関係では、新しい単一の顧客ドキュメントにオブジェクトとして埋め込むことができます。 こうすることで、eコマース アプリケーションにより、1 回の要求で顧客データの作成、編集、または取得を実行できるようになります。

次の図は、顧客エンティティがどのようなものかを示しています。