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.
Premiers pas pour la modélisation des données relationnelles dans DynamoDB
Note
Pour concevoir un système NoSQL, il faut un autre état d’esprit que pour un SGBDR. Pour un SGBDR, vous pouvez créer un modèle de données normalisé sans réfléchir aux modèles d’accès. Vous pouvez l’étendre ultérieurement, pour répondre à de nouvelles questions et de nouveaux besoins d’interrogation. En revanche, dans Amazon DynamoDB, vous ne devez pas commencer à concevoir votre schéma tant que vous ne savez pas à quelle problématique celui-ci doit répondre. Il est absolument essentiel d’identifier au préalable les problèmes métier et les cas d’utilisation de l’application.
Pour commencer à concevoir une table DynamoDB qui pourra être efficacement mise à l’échelle, vous devez d’abord effectuer plusieurs étapes pour identifier les modèles d’accès qui sont requis par les systèmes de support d’exploitation et de support d’activités (OSS/BSS) que celle-ci doit prendre en charge :
Pour les nouvelles applications, consultez des témoignages d’utilisateurs sur les activités et les objectifs. Documentez les différents cas d’utilisation que vous identifiez et analysez les modèles d’accès dont ceux-ci ont besoin.
Pour des applications existantes, analysez les journaux de requêtes pour découvrir comment le système est actuellement utilisé et identifier les principaux modèles d’accès.
Après avoir terminé ce processus, vous devriez obtenir une liste ressemblant à ce qui suit :
| Motif # | Description du modèle d'accès |
|---|---|
| 1 | Rechercher les détails des employés par ID d’employé |
| 2 | Interroger les détails des employés par nom d’employé |
| 3 | Trouver le (s) numéro (s) de téléphone d'un employé |
| 4 | Trouver le (s) numéro (s) de téléphone d'un client |
| 5 | Obtenez des commandes pour les clients dans un intervalle de dates |
| 6 | Afficher toutes les commandes ouvertes dans un intervalle de dates |
| 7 | Voir tous les employés embauchés récemment |
| 8 | Trouvez tous les employés de Warehouse |
| 9 | Obtenez tous les articles en commande pour le produit |
| 10 | Obtenez des stocks de produits dans tous les entrepôts |
| 11 | Attirez des clients par le biais d'un représentant commercial |
| 12 | Recevez les commandes par le représentant du compte |
| 13 | Trouvez des employés avec le titre du poste |
| 14 | Obtenez l'inventaire par produit et par entrepôt |
| 15 | Obtenez l'inventaire total des produits |
Dans une application réelle, votre liste peut être beaucoup plus longue. Mais cette collection représente toute la complexité d’un modèle de requête que vous pourriez trouver dans un environnement de production.
Une approche moderne de la conception de schémas DynamoDB utilise des principes orientés agrégats, regroupant les données en fonction de modèles d'accès plutôt que de limites d'entités rigides. Cette approche prend en compte plusieurs modèles de conception :
Conception de table unique : utilisation de clés de tri composites, d'index secondaires globaux surchargés et de modèles de listes de contiguïté pour stocker plusieurs types d'entités dans une seule table
Conception multi-tables - Utilisation de tables séparées pour les entités présentant des caractéristiques opérationnelles indépendantes et une faible corrélation d'accès, avec une stratégie GSIs pour les requêtes entre entités
Conception agrégée - Intégrer les données associées lorsqu'elles sont toujours accessibles ensemble (Commande + OrderItems) ou utilisation de collections d'articles pour identifier les relations (Produit + Inventaire)
Le choix entre ces approches dépend de vos modèles d'accès spécifiques, des caractéristiques des données et des exigences opérationnelles. Vous pouvez utiliser ces éléments pour structurer les données afin qu’une application puisse récupérer ce dont elle a besoin pour un modèle d’accès donné à l’aide d’une requête unique sur une table ou un index.
Note
Le choix entre une conception à table unique ou à tables multiples dépend de vos besoins spécifiques. La conception à table unique fonctionne bien lorsque les entités présentent une forte corrélation d'accès et des caractéristiques opérationnelles similaires. La conception à plusieurs tables est préférable lorsque les entités ont des exigences opérationnelles indépendantes, des modèles d'accès différents ou lorsque vous avez besoin de limites opérationnelles claires. L'exemple présenté dans ce guide illustre une approche multi-tables avec agrégation et dénormalisation stratégiques.
Pour utiliser NoSQL Workbench pour DynamoDB afin de mieux visualiser votre conception de clé de partition, consultez Création de modèles de données avec NoSQL Workbench.
