アプリのアクセス パターンを特定する
NoSQL データベースのデータ モデルを設計する際の目的は、データに対する操作が最小限の要求数で実行されるようにすることです。 そのためには、データ間のリレーションシップと、アプリケーションによるデータへのアクセス方法を理解する必要があります。 これらのアクセス パターンが重要なのは、それとリレーションシップによって、さまざまなエンティティのプロパティがグループ化されて、Azure Cosmos DB for NoSQL のコンテナー内のドキュメントに格納される方法が決まるためです。
Azure Cosmos DB for NoSQL では、ドキュメントは項目と呼ばれ、コンテナーは同義でコレクションと呼ばれることがよくあります。
顧客エンティティのアクセス パターンを特定する
まず、eコマース データベース内の顧客エンティティから始めましょう。 次の図は、3 つのエンティティとそれらの間のリレーションシップを示しています。 その 3 つのエンティティとは、Customer、CustomerAddress、CustomerPassword です。 Customer エンティティと CustomerAddress には 1 対多のリレーションシップがあります。 Customer と CustomerPassword には 1 対 1 のリレーションシップがあります。
このアプリケーションでは、顧客エンティティに対して次の 3 つの操作を実行します。
- 顧客を作成する: 新しいユーザーが eコマース サイトに初めてアクセスしたときに、新しい顧客が作成されます。
- 顧客を更新する: 既存のユーザーが自分のプロフィール情報を更新すると、顧客レコードが更新されます。
- 顧客を取得する: 既存のユーザーがサイトにアクセスするときは、パスワードを使用してサインインします。 同じセッション中に、新しい商品を購入するために他の顧客データ (住所など) にアクセスする必要があります。
このような操作のたびに、このすべてのデータが同時に必要になります。 それらが個別のドキュメントとしてモデル化されているとしたら、顧客データの作成、更新、取得のために、サーバーに何回もラウンドトリップする必要があります。 これは効率的ではありません。
顧客エンティティをモデリングする
Azure Cosmos DB により、データは JSON として格納されるので、Customer と CustomerAddress 間の 1 対多のリレーションシップをモデリングし、顧客住所データを配列として埋め込むことができます。 また、Customer と CustomerPassword 間の 1 対 1 のリレーションシップについては、オブジェクトとして新しい 1 つの顧客ドキュメントに埋め込むことができます。 こうすることで、eコマース アプリケーションにより、1 回の要求で顧客データの作成、編集、または取得を実行できるようになります。
次の図は、顧客エンティティがどのようなものかを示しています。
