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 un magasin 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 : + Obtenir un client pour un customerId donné + Obtenir un produit pour un productId donné + Obtenir un entrepôt pour un warehouseId donné + Obtenez un inventaire de produits pour tous les entrepôts à l’aide d’un productId + Obtenir une commande pour un orderId donné + Obtenir tous les produits pour un orderId donné + Obtenir une facture pour un orderId donné + Obtenir toutes les expéditions pour un orderId donné + Obtenir toutes les commandes pour un productId donné et une plage de dates donnée + Obtenir une facture pour un invoiceId donné + Obtenir tous les paiements pour un invoiceId donné + Obtenir les détails d’une expédition pour un shipmentId donné + Obtenir toutes les expéditions pour un warehouseId donné + Obtenir l’inventaire de tous les produits pour un warehouseId donné + Obtenir toutes les factures pour un customerId donné et une plage de dates donnée + Obtenir tous les produits commandés par un customerId donné pour une plage de dates donnée ## Diagramme des relations entre entités Voici le diagramme des relations entre entités (ERD) que nous utiliserons pour modéliser DynamoDB en tant que magasin de données pour une boutique en ligne. ![\[Diagramme des relations entre entités (ERD) pour le modèle de données d’un magasin en ligne avec des entités telles que le produit, la commande, le paiement et le client.\]](http://docs.aws.amazon.com/fr_fr/amazondynamodb/latest/developerguide/images/DataModeling/OnlineShop-1-ERD.png) ## 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. 1. `getCustomerByCustomerId` 1. `getProductByProductId` 1. `getWarehouseByWarehouseId` 1. `getProductInventoryByProductId` 1. `getOrderDetailsByOrderId` 1. `getProductByOrderId` 1. `getInvoiceByOrderId` 1. `getShipmentByOrderId` 1. `getOrderByProductIdForDateRange` 1. `getInvoiceByInvoiceId` 1. `getPaymentByInvoiceId` 1. `getShipmentDetailsByShipmentId` 1. `getShipmentByWarehouseId` 1. `getProductInventoryByWarehouseId` 1. `getInvoiceByCustomerIdForDateRange` 1. `getProductsByCustomerIdForDateRange` ## Évolution de la conception du schéma En utilisant[NoSQL Workbench pour DynamoDB](workbench.md), import [AnOnlineShop\$11.json](https://github.com/aws-samples/amazon-dynamodb-design-patterns/blob/master/examples/an-online-shop/json/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\$12.json](https://github.com/aws-samples/amazon-dynamodb-design-patterns/blob/master/examples/an-online-shop/json/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 [https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_GetItem.html](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_GetItem.html) avec `PK=customerId` et `SK=customerId`. **Étape 2 : Traitement du modèle d’accès 2 (`getProductByProductId`)** Importez [AnOnlineShop\$13.json](https://github.com/aws-samples/amazon-dynamodb-design-patterns/blob/master/examples/an-online-shop/json/AnOnlineShop_3.json) pour adresser le modèle d'accès 2 (`getProductByProductId`) pour l'`product`entité. 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](data-modeling-blocks.md#data-modeling-blocks-vertical-partitioning) 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\$14.json](https://github.com/aws-samples/amazon-dynamodb-design-patterns/blob/master/examples/an-online-shop/json/AnOnlineShop_4.json) pour adresser le modèle d'accès 3 (`getWarehouseByWarehouseId`) pour l'`warehouse`entité. 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 :** ![\[Conception de tables DynamoDB avec préfixes EntityType et permettant d'obtenir les données de l'entrepôt par leur identifiant.\]](http://docs.aws.amazon.com/fr_fr/amazondynamodb/latest/developerguide/images/DataModeling/OnlineShop-2-Step3.png) **Étape 4 : Traitement du modèle d’accès 4 (`getProductInventoryByProductId`)** Importez [AnOnlineShop\$15.json](https://github.com/aws-samples/amazon-dynamodb-design-patterns/blob/master/examples/an-online-shop/json/AnOnlineShop_5.json) pour adresser le modèle d'accès 4 ()`getProductInventoryByProductId`. `warehouseItem`L'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 l'ERD, il existe une many-to-many relation entre `product` et`warehouse`. Ici, la one-to-many relation de `product` à `warehouse` est modélisée comme`warehouseItem`. 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é](Query.KeyConditionExpressions.md). **Table de base :** ![\[Conception de table pour effectuer des requêtes ProductID et warehouseId afin de suivre l’inventaire des produits dans un entrepôt donné.\]](http://docs.aws.amazon.com/fr_fr/amazondynamodb/latest/developerguide/images/DataModeling/OnlineShop-3-Step4.png) **É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\$16.json](https://github.com/aws-samples/amazon-dynamodb-design-patterns/blob/master/examples/an-online-shop/json/AnOnlineShop_6.json). `product` Ensuite, importez [AnOnlineShop\$17.json](https://github.com/aws-samples/amazon-dynamodb-design-patterns/blob/master/examples/an-online-shop/json/AnOnlineShop_7.json) pour créer une collection d'objets `order` capable de traiter les modèles d'accès 5 (`getOrderDetailsByOrderId`) et 6 (`getProductByOrderId`). Vous pouvez voir la one-to-many relation entre les entités OrderItem `order` et les `product` modéliser sous forme d'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 :** ![\[Conception de table pour effectuer une requête à l’aide de orderId pour obtenir des informations sur tous les produits commandés.\]](http://docs.aws.amazon.com/fr_fr/amazondynamodb/latest/developerguide/images/DataModeling/OnlineShop-4-Step5.png) 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 :** ![\[Conception de table pour effectuer une requête à l’aide de orderId et productId pour obtenir les produits d’une commande.\]](http://docs.aws.amazon.com/fr_fr/amazondynamodb/latest/developerguide/images/DataModeling/OnlineShop-5-Step5.png) **Étape 6 : Traitement du modèle d’accès 7 (`getInvoiceByOrderId`)** Importez [AnOnlineShop\$18.json](https://github.com/aws-samples/amazon-dynamodb-design-patterns/blob/master/examples/an-online-shop/json/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 :** ![\[Conception de tableau avec entité de facture dans la collection d’éléments de commande pour obtenir une facture par orderId.\]](http://docs.aws.amazon.com/fr_fr/amazondynamodb/latest/developerguide/images/DataModeling/OnlineShop-6-Step6.png) **Étape 7 : Traitement du modèle d’accès 8 (`getShipmentByOrderId`)** Importez [AnOnlineShop\$19.json](https://github.com/aws-samples/amazon-dynamodb-design-patterns/blob/master/examples/an-online-shop/json/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 :** ![\[Conception du tableau avec une entité d’expédition ajoutée à la collection des éléments de commande pour obtenir les envois par ID de commande.\]](http://docs.aws.amazon.com/fr_fr/amazondynamodb/latest/developerguide/images/DataModeling/OnlineShop-7-Step7.png) **É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. Pour traiter ce modèle d’accès, nous allons devoir créer un [index secondaire global (GSI)](GSI.md). Importez [AnOnlineShop\$110.json](https://github.com/aws-samples/amazon-dynamodb-design-patterns/blob/master/examples/an-online-shop/json/AnOnlineShop_10.json) pour créer une nouvelle collection d'articles à l'aide du GSI qui permet 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 qui contiennent les attributs de clé d’un GSI, de la table au GSI. Il n’est pas nécessaire d’effectuer des insertions manuelles supplémentaires dans le GSI. 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 :** ![\[Conception de table avec un GSI pour obtenir les données de commande de plusieurs collections d’éléments de commande.\]](http://docs.aws.amazon.com/fr_fr/amazondynamodb/latest/developerguide/images/DataModeling/OnlineShop-8-Step8-Base.png) **GSI1:** ![\[Conception GSI avec ProductID et Date comme partition et clés de tri pour obtenir les commandes par ID de produit et par date.\]](http://docs.aws.amazon.com/fr_fr/amazondynamodb/latest/developerguide/images/DataModeling/OnlineShop-9-Step8-GSI.png) **Étape 9 : Traitement des modèles d’accès 10 (`getInvoiceByInvoiceId`) et 11 (`getPaymentByInvoiceId`)** Importez [AnOnlineShop\$111.json](https://github.com/aws-samples/amazon-dynamodb-design-patterns/blob/master/examples/an-online-shop/json/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`. **Note** `GSI1-PK` et `GSI1-SK` sont surchargés pour stocker des informations sur différentes entités afin que plusieurs modèles d’accès puissent être utilisés à partir du même GSI. Pour plus d’informations sur la surcharge du GSI, consultez [Surcharge des index secondaires globaux dans DynamoDB](bp-gsi-overloading.md). Pour traiter le modèle d’accès 10 et 11, interrogez `GSI1` avec `GSI1-PK=invoiceId` et `GSI1-SK=invoiceId`. **GSI1:** ![\[Conception GSI avec invoiceId à la fois comme partition et clé de tri pour obtenir la facture et le paiement par ID de facture.\]](http://docs.aws.amazon.com/fr_fr/amazondynamodb/latest/developerguide/images/DataModeling/OnlineShop-10-Step9.png) **Étape 10 : Traitement des modèles d’accès 12 (`getShipmentDetailsByShipmentId`) et 13 (`getShipmentByWarehouseId`)** Importez [AnOnlineShop\$112.json](https://github.com/aws-samples/amazon-dynamodb-design-patterns/blob/master/examples/an-online-shop/json/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 :** ![\[Conception du tableau avec une entité shipmentItem dans la collection des éléments de commande pour obtenir tous les détails d’une commande.\]](http://docs.aws.amazon.com/fr_fr/amazondynamodb/latest/developerguide/images/DataModeling/OnlineShop-11-Step10.png) 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` et`shipmentItem`. Pour traiter le modèle d’accès 12 (`getShipmentDetailsByShipmentId`), interrogez `GSI1` avec `GSI1-PK=shipmentId` et `GSI1-SK=shipmentId`. **GSI1:** ![\[GSI1 conception avec ShipmentID comme partition et clé de tri pour obtenir les détails de l'expédition par numéro d'expédition.\]](http://docs.aws.amazon.com/fr_fr/amazondynamodb/latest/developerguide/images/DataModeling/OnlineShop-12-Step10-GSI.png) 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:** ![\[GSI2 conception avec WarehouseID et ShipmentID comme clés de partition et de tri pour obtenir les envois par entrepôt.\]](http://docs.aws.amazon.com/fr_fr/amazondynamodb/latest/developerguide/images/DataModeling/OnlineShop-13-Step10-GSI2.png) **Étape 11 : Traitement des modèles d’accès 14 (`getProductInventoryByWarehouseId`), 15 (`getInvoiceByCustomerIdForDateRange`) et 16 (`getProductsByCustomerIdForDateRange`)** Importez [AnOnlineShop\$113.json](https://github.com/aws-samples/amazon-dynamodb-design-patterns/blob/master/examples/an-online-shop/json/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:** ![\[GSI2 conception avec WarehouseID et ProductID comme partition et clés de tri pour adresser le modèle d'accès 14.\]](http://docs.aws.amazon.com/fr_fr/amazondynamodb/latest/developerguide/images/DataModeling/OnlineShop-14-Step11-GSI2.png) 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:** ![\[GSI2 conception avec CustomerID et plage de dates de facturation comme partition et clés de tri pour répondre au modèle d'accès 15.\]](http://docs.aws.amazon.com/fr_fr/amazondynamodb/latest/developerguide/images/DataModeling/OnlineShop-15-Step11-GSI2.png) 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:** ![\[GSI2 conception avec CustomerID et plage de dates du produit comme partition et clés de tri pour répondre au modèle d'accès 16\]](http://docs.aws.amazon.com/fr_fr/amazondynamodb/latest/developerguide/images/DataModeling/OnlineShop-16-Step11-GSI2.png) **Note** Dans [NoSQL Workbench](workbench.md), les *facettes* représentent les différents modèles d’accès aux données d’une application pour DynamoDB. Les facettes vous permettent d’afficher un sous-ensemble de données dans une table, sans avoir à voir les enregistrements qui ne répondent pas aux contraintes de la facette. Les facettes sont considérées comme un outil de modélisation de données visuelles et n’existent pas en tant que construction utilisable dans DynamoDB, car elles sont purement une aide à la modélisation des modèles d’accès. Importez [AnOnlineShop\$1facets.json](https://github.com/aws-samples/amazon-dynamodb-design-patterns/blob/master/examples/an-online-shop/json/AnOnlineShop_facets.json) pour voir les facettes de ce cas d'utilisation. 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 : | Modèle d’accès | table/GSI/LSI de base | Opération | Valeur de la clé de partition | Valeur de clé de tri | | --- | --- | --- | --- | --- | | getCustomerByCustomerId | Table de base | GetItem | PK=customerId | SK=customerId | | getProductByProductId | Table de base | GetItem | PK=productId | SK=productId | | getWarehouseByWarehouseId | Table de base | GetItem | PK=warehouseId | SK=warehouseId | | getProductInventoryByProductId | Table de base | Query | PK=productId | SK begins\$1with "w\$1" | | getOrderDetailsByOrderId | Table de base | Query | PK=orderId | | | getProductByOrderId | Table de base | Query | PK=orderId | SK begins\$1with "p\$1" | | getInvoiceByOrderId | Table de base | Query | PK=orderId | SK begins\$1with "i\$1" | | getShipmentByOrderId | Table de base | Query | PK=orderId | SK begins\$1with "sh\$1" | | getOrderByProductIdForDateRange | GSI1 | Query | PK=productId | SK between date1 and date2 | | getInvoiceByInvoiceId | GSI1 | Query | PK=invoiceId | SK=invoiceId | | getPaymentByInvoiceId | GSI1 | Query | PK=invoiceId | SK=invoiceId | | getShipmentDetailsByShipmentId | GSI1 | Query | PK=shipmentId | SK=shipmentId | | getShipmentByWarehouseId | GSI2 | Query | PK=warehouseId | SK begins\$1with "sh\$1" | | getProductInventoryByWarehouseId | GSI2 | Query | PK=warehouseId | SK begins\$1with "p\$1" | | getInvoiceByCustomerIdForDateRange | GSI2 | Query | PK=customerId | SK between i\$1date1 and i\$1date2 | | getProductsByCustomerIdForDateRange | GSI2 | Query | PK=customerId | SK between p\$1date1 and p\$1date2 | ### Schéma final pour la boutique en ligne Voici les conceptions du schéma final. Pour télécharger cette conception de schéma sous forme de fichier JSON, consultez la section Modèles de conception [DynamoDB](https://github.com/aws-samples/aws-dynamodb-examples/tree/master/schema_design/SchemaExamples) sur. GitHub **Table de base** ![\[Schéma final de la table de base pour une boutique en ligne avec des attributs tels que EntityName et le nom.\]](http://docs.aws.amazon.com/fr_fr/amazondynamodb/latest/developerguide/images/DataModeling/OnlineShop-17-Final-BaseTable.png) **GSI1** ![\[GSI1 Schéma final de la table de base d'une boutique en ligne avec des attributs, tels que EntityType.\]](http://docs.aws.amazon.com/fr_fr/amazondynamodb/latest/developerguide/images/DataModeling/OnlineShop-18-Final-GSI1.png) **GSI2** ![\[GSI2 Schéma final de la table de base d'une boutique en ligne avec des attributs, tels que EntityType.\]](http://docs.aws.amazon.com/fr_fr/amazondynamodb/latest/developerguide/images/DataModeling/OnlineShop-19-Final-GSI2.png) ## Utilisation de NoSQL Workbench avec cette conception de schéma Vous pouvez importer ce schéma final dans [NoSQL Workbench](workbench.md), un outil visuel qui fournit des fonctionnalités de modélisation des données, de visualisation des données et de développement des requêtes pour DynamoDB, afin d’explorer et de modifier davantage votre nouveau projet. Pour commencer, procédez comme suit : 1. Téléchargez NoSQL Workbench. Pour de plus amples informations, veuillez consulter [Télécharger NoSQL Workbench pour DynamoDB](workbench.settingup.md). 1. Téléchargez le fichier de schéma JSON répertorié ci-dessus, qui est déjà au format du modèle NoSQL Workbench. 1. Importez le fichier de schéma JSON dans NoSQL Workbench. Pour de plus amples informations, veuillez consulter [Importation d’un modèle de données existant](workbench.Modeler.ImportExisting.md). 1. Une fois que vous l’avez importé dans NoSQL Workbench, vous pouvez modifier le modèle de données. Pour de plus amples informations, veuillez consulter [Modification d’un modèle de données existant](workbench.Modeler.Edit.md).