Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Utilisation de DynamoDB comme magasin de données pour une boutique en ligne

Ce cas d'utilisation décrit l'utilisation de DynamoD comme magasin de données pour une boutique en ligne (ou boutique virtuelle).

Cas d’utilisation

Une boutique en ligne permet aux utilisateurs de parcourir différents produits et de les acheter par la suite. Sur la base de la facture générée, le client peut payer à l'aide d'un code de réduction ou d'une carte-cadeau, puis régler le montant restant par carte de crédit. Les produits achetés seront collectés dans l'un des nombreux entrepôts et seront expédiés à l'adresse indiquée. Les modèles d'accès types d’une boutique en ligne incluent :

Diagramme des relations entre entités

Il s'agit du diagramme entité-relation (ERD) que nous utiliserons pour modéliser DynamoDB en tant que magasin de données pour une boutique en ligne.

Modèles d'accès

Voici les modèles d'accès que nous allons prendre en compte lors de l’utilisation de DynamoDB comme magasin de données pour une boutique en ligne.

Évolution de la conception du schéma

En utilisantPas de SQL Workbench pour DynamoDB, import AnOnlineShop_1.json pour créer un nouveau modèle de données appelé AnOnlineShop et une nouvelle table appelée. OnlineShop Notez que nous utilisons les noms génériques PK et SK pour la clé de partition et la clé de tri. Cette méthode permet de stocker différents types d'entités dans la même table.

Étape 1 : Traitement du modèle d'accès 1 (getCustomerByCustomerId)

Importez AnOnlineShop_2.json pour gérer le modèle d'accès 1 ()getCustomerByCustomerId. Étant donné que certaines entités n'ont aucune relation avec d'autres entités, nous utiliserons la même valeur de PK et SK pour ces entités. Dans les exemples de données, notez que les clés utilisent le préfixe c# afin de distinguer customerId des autres entités qui seront ajoutées ultérieurement. Cette méthode est également répétée pour d'autres entités.

Pour traiter ce modèle d'accès, il est possible d’utiliser l’opération GetItem avec PK=customerId et SK=customerId.

Étape 2 : Traitement du modèle d'accès 2 (getProductByProductId)

Importez AnOnlineShop_3.json pour adresser le modèle d'accès 2 (getProductByProductId) pour l'productentité. Les entités de produit utilisent le préfixe p# et le même attribut de clé de tri a été utilisé pour stocker customerID et productID. Un nom générique et le partitionnement vertical nous permettent de créer ces ensembles d’éléments pour une conception de table unique efficace.

Pour traiter ce modèle d'accès, il est possible d’utiliser l’opération GetItem avec PK=productId et SK=productId.

Étape 3 : Traitement du modèle d'accès 3 (getWarehouseByWarehouseId)

Importez AnOnlineShop_4.json pour adresser le modèle d'accès 3 (getWarehouseByWarehouseId) pour l'warehouseentité. Les entités customer, product et warehouse ont actuellement été ajoutées à la même table. Ils se distinguent par l’utilisation de préfixes et de l’attribut EntityType. Un attribut de type (ou l’utilisation d’un préfixe) améliore la lisibilité du modèle. La lisibilité serait affectée si nous stockions simplement des caractères alphanumériques IDs pour différentes entités dans le même attribut. Il serait difficile de distinguer une entité d’une autre en l'absence de ces identifiants.

Pour traiter ce modèle d'accès, il est possible d’utiliser l’opération GetItem avec PK=warehouseId et SK=warehouseId.

Table de base :

Étape 4 : Traitement du modèle d'accès 4 (getProductInventoryByProductId)

Importez AnOnlineShop_5.json pour adresser le modèle d'accès 4 ()getProductInventoryByProductId. warehouseItemL'entité est utilisée pour suivre le nombre de produits dans chaque entrepôt. Cet élément est habituellement mis à jour lorsqu'un produit est ajouté ou retiré d'un entrepôt. Comme on le voit dans leERD, il existe une many-to-many relation entre product etwarehouse. Ici, la one-to-many relation de product à warehouse est modélisée commewarehouseItem. Plus tard, la one-to-many relation de warehouse à product sera également modélisée.

Le modèle d'accès 4 peut être traité à l'aide d'une requête sur PK=ProductId et SK begins_with “w#“.

Pour plus d'informations sur begins_with() et d'autres expressions pouvant être appliquées aux clés de tri, consultez Expressions de condition de clé.

Table de base :

Étape 5 : Traitement des modèles d'accès 5 (getOrderDetailsByOrderId) et 6 (getProductByOrderId)

Ajoutez quelques warehouse éléments supplémentaires customer à la table en important AnOnlineShop_6.json. product Ensuite, importez AnOnlineShop_7.json pour créer une collection d'objets order capable de répondre aux modèles d'accès 5 (getOrderDetailsByOrderId) et 6 (getProductByOrderId). Vous pouvez voir la one-to-many relation entre les entités order et les product modéliser en tant qu' orderItem entités.

Pour traiter le modèle d'accès 5 (getOrderDetailsByOrderId), interrogez la table avec PK=orderId. Cette requête fournira toutes les informations relatives à la commande, y compris le customerId et les produits commandés.

Table de base :

Pour traiter le modèle d'accès 6 (getProductByOrderId), nous devons lire les produits uniquement dans order. Pour ce faire, interrogez la table avec PK=orderId et SK begins_with “p#”.

Table de base :

Étape 6 : Traitement du modèle d'accès 7 (getInvoiceByOrderId)

Importez AnOnlineShop_8.json pour ajouter une invoice entité à la collection d'articles de commande afin de gérer le modèle d'accès 7 ()getInvoiceByOrderId. Pour traiter ce modèle d'accès, il est possible d’utiliser une opération query avec PK=orderId et SK begins_with “i#”.

Table de base :

Étape 7 : Traitement du modèle d'accès 8 (getShipmentByOrderId)

Importez AnOnlineShop_9.json pour ajouter shipment des entités à la collection d'articles de commande afin de répondre au modèle d'accès 8 ()getShipmentByOrderId. Nous développons le même modèle partitionné verticalement en ajoutant d'autres types d'entités dans la conception de table unique. Vous pouvez remarquer que l’ensemble d’éléments order contient les différentes relations d’une entité order avec les entités shipment, orderItem et invoice.

Pour obtenir les expéditions par orderId, vous pouvez effectuer une opération query avec PK=orderId et SK begins_with “sh#”.

Table de base :

Étape 8 : Traitement du modèle d'accès 9 (getOrderByProductIdForDateRange)

Nous avons créé un ensemble d’éléments order à l'étape précédente. Ce modèle d'accès comporte de nouvelles dimensions de recherche (ProductID et Date) qui vous obligent à analyser l'ensemble de la table et à filtrer les enregistrements pertinents pour extraire les éléments ciblés. Afin de remédier à ce modèle d'accès, nous devons créer un index secondaire global (GSI). Importez AnOnlineShop_10.json pour créer une nouvelle collection d'articles à l'aide de GSI laquelle il est possible de récupérer les orderItem données de plusieurs collections d'articles de commande. Les données comportent désormais GSI1-PK et GSI1-SK, qui seront la clé de partition et la clé de tri de GSI1, respectivement.

DynamoDB renseigne automatiquement les éléments contenant les attributs clés de GSI a depuis le tableau vers le. GSI Il n'est pas nécessaire de faire manuellement des insertions supplémentaires dans leGSI.

Pour traiter le modèle d'accès 9, exécutez une requête sur GSI1 avec GSI1-PK=productId et GSI1SK between (date1, date2).

Table de base :

GSI1:

Étape 9 : Traitement des modèles d'accès 10 (getInvoiceByInvoiceId) et 11 (getPaymentByInvoiceId)

Importez AnOnlineShop_11.json pour traiter les modèles d'accès 10 (getInvoiceByInvoiceId) et 11 (getPaymentByInvoiceId), qui sont tous deux liés à. invoice Même s'il s'agit de deux modèles d'accès différents, ils sont réalisés en utilisant la même condition de clé. Payments est défini sous la forme d'un attribut avec le type de données de carte sur l’entité invoice.

Pour traiter le modèle d'accès 10 et 11, interrogez GSI1 avec GSI1-PK=invoiceId et GSI1-SK=invoiceId.

GSI1:

Étape 10 : Traitement des modèles d'accès 12 (getShipmentDetailsByShipmentId) et 13 (getShipmentByWarehouseId)

Importez AnOnlineShop_12.json pour traiter les modèles d'accès 12 (getShipmentDetailsByShipmentId) et 13 (getShipmentByWarehouseId).

Vous pouvez remarquer que les entités shipmentItem sont ajoutées à l’ensemble d’éléments order sur la table de base afin de pouvoir récupérer tous les détails d'une commande en une seule opération query.

Table de base :

Les clés de GSI1 partition et de tri ont déjà été utilisées pour modéliser une one-to-many relation entre shipment etshipmentItem. Pour traiter le modèle d'accès 12 (getShipmentDetailsByShipmentId), interrogez GSI1 avec GSI1-PK=shipmentId et GSI1-SK=shipmentId.

GSI1:

Nous devrons créer un autre GSI (GSI2) pour modéliser la nouvelle one-to-many relation entre warehouse et shipment pour le modèle d'accès 13 (getShipmentByWarehouseId). Pour traiter ce modèle d'accès, interrogez GSI2 avec GSI2-PK=warehouseId et GSI2-SK begins_with “sh#”.

GSI2:

Étape 11 : Traitement des modèles d'accès 14 (getProductInventoryByWarehouseId), 15 (getInvoiceByCustomerIdForDateRange) et 16 (getProductsByCustomerIdForDateRange)

Importez AnOnlineShop_13.json pour ajouter des données relatives au prochain ensemble de modèles d'accès. Pour traiter le modèle d'accès 14 (getProductInventoryByWarehouseId), interrogez GSI2 avec GSI2-PK=warehouseId et GSI2-SK begins_with “p#”.

GSI2:

Pour traiter le modèle d'accès 15 (getInvoiceByCustomerIdForDateRange), interrogez GSI2 avec GSI2-PK=customerId et GSI2-SK between (i#date1, i#date2).

GSI2:

Pour traiter le modèle d'accès 16 (getProductsByCustomerIdForDateRange), interrogez GSI2 avec GSI2-PK=customerId et GSI2-SK between (p#date1, p#date2).

GSI2:

Tous les modèles d'accès et la façon dont ils sont traités par la conception du schéma sont résumés dans le tableau ci-dessous :

Schéma final de la boutique en ligne

Voici les conceptions du schéma final. Pour télécharger cette conception de schéma sous forme de JSON fichier, consultez la section Modèles de conception DynamoDB sur. GitHub

Table de base

GSI1

GSI2

Utilisation de No SQL Workbench avec cette conception de schéma

Vous pouvez importer ce schéma final dans No SQL Workbench, un outil visuel qui fournit des fonctionnalités de modélisation des données, de visualisation des données et de développement de requêtes pour DynamoDB, afin d'explorer et de modifier davantage votre nouveau projet. Pour commencer, procédez comme suit :