Introduction
Aujourd’hui, l’argument le plus courant parmi les gestionnaires d’entrepôts de données est de déterminer quel schéma est le plus orienté vers la performance. Cependant, il est essentiel de savoir qu’aucune des approches de normalisation ou de dénormalisation ne peut être rayée de la carte puisqu’elles présentent toutes deux des avantages et des inconvénients.
C’est pourquoi, avant de détailler leurs différences à travers des cas d’utilisation, examinons la normalisation et la dénormalisation.
Normalisation
La normalisation est l’acte de réorganisation des données dans un entrepôt de données pour répondre à deux exigences fondamentales :
- Supprimer la redondance des données en stockant toutes les données strictement au même endroit
- Assurer la dépendance des données, c’est-à-dire.c’est-à-dire que tous les éléments de données correspondants sont stockés ensemble
La normalisation est essentielle pour plusieurs raisons, mais principalement parce qu’elle permet aux entrepôts de données d’occuper le moins d’espace disque possible. Il en résulte une amélioration des performances.
Dénormalisation
Cette stratégie d’entreposage de données est utilisée pour améliorer la fonctionnalité d’une infrastructure de base de données. La dénormalisation appelle les données redondantes vers un entrepôt de données normalisé afin de minimiser le temps d’exécution des requêtes spécifiques de la base de données qui réunissent les données de nombreuses tables en une seule.
En fait, l’interprétation de la dénormalisation dépend de la normalisation, qui se caractérise comme l’acte d’organiser une base de données en tables en supprimant les répétitions pour mettre en œuvre un cas d’utilisation donné. N’oubliez pas qu’une base de données dénormalisée ne doit jamais être confondue avec une base de données qui n’a jamais été normalisée.
Normalisation et dénormalisation – Cas d’utilisation
Amazon DynamoDB
L’option d’un schéma normalisé ou dénormalisé dans une base de données NoSQL, telle que DynamoDB, dépend de votre cas d’utilisation. Cependant, les professionnels recommandent de concevoir vos tables DynamoDB avec un schéma dénormalisé pour les deux raisons suivantes :
- DynamoDB par Amazon est sans schéma, et lorsqu’une table est créée dans cette base de données, vous êtes tenu de spécifier les attributs de clé primaire uniquement, comme la clé de tri et la clé de partition, ou juste la clé de partition. De plus, vous n’avez pas à définir d’autres attributs au préalable.
- DynamoDB n’approuve pas les opérations de jointure à travers les tables.
Néanmoins, il existe certaines situations où vous pouvez plutôt utiliser un schéma normalisé.
Un schéma normalisé peut être envisagé lorsque :
- Vous êtes tenu de stocker des éléments dont la taille est supérieure à 400 Ko. Cependant, la taille maximale des éléments autorisée dans DynamoDB est de 400 Ko. Par conséquent, les attributs plus grands peuvent être stockés dans Amazon S3 ou sur une table DynamoDB individuelle.
- Vous vous attendez à divers modèles d’accès. Par exemple, prenez une table de commande de produits, à laquelle on accède chaque fois qu’un client commande un produit. Prenez maintenant une table de disponibilité des produits, qui n’est consultée qu’occasionnellement. Les deux tables ont des prérequis de capacité de lecture & d’écriture différents.
- Vos applications effectuent plusieurs mises à jour. Dans Amazon DynamoDB, une WCU (unité de capacité d’écriture) est décrite comme une écriture/seconde, pour un élément de 1 Ko de taille. De plus, de nombreuses écritures d’éléments de données supérieurs à 1 KB influenceront le nombre de WCU épuisés par écriture. En outre, même si vous ne mettez à jour qu’un seul attribut, le calcul des WCU dépend de la taille de l’élément complet.
Un schéma dénormalisé peut être envisagé lorsque :
- Des petits éléments avec peu d’attributs doivent être stockés. De plus, la taille de l’élément ne doit pas dépasser 4 Ko en lecture. Rappelez-vous, une UCR (unité de capacité de lecture) est spécifiée comme une lecture/seconde pour un élément de moins de 4 Ko. Sinon, pour les écritures, la taille de l’élément ne devrait pas dépasser 1 KB.
Vos applications doivent lire ainsi qu’écrire des données dans un environnement à trafic riche, sans tenir compte de la synchronisation et de la cohérence des données entre les différentes tables.
Cas d’utilisation de la normalisation dans l’entreposage des données de santé
Aujourd’hui, la normalisation des données tient un rôle plus large dans un éventail de paramètres de soins de santé, car elle offre un cadre pour interpréter les données afin de faciliter plusieurs cas d’utilisation.
Pour simplifier les choses, voici un domaine commun qui emploie la normalisation des données :
Rendre les données utiles au sein de l’entrepôt de données
Un entrepôt de données typique va chercher les données des patients dans une foule de systèmes informatiques et cliniques. C’est parce que les organisations veulent centraliser leurs projets de reporting, leurs programmes de qualité, utiliser les données pour concevoir des modèles prédictifs, et utiliser les réclamations et les données cliniques pour superviser le processus de soins.
Alors, quelles sont les applications des données normalisées dans les soins de santé ?
Disons qu’un hôpital a l’intention d’établir une tendance des taux d’hémoglobine A1C pour une population de patients diabétiques. Cependant, il est courant que les systèmes de laboratoire mettent en place leurs codes de laboratoire propriétaires personnels qui ne sont pas normalisés sur LOINC. L’entrepôt de données de l’hôpital peut très bien posséder des résultats de laboratoire A codifiés comme 4321/Hgb A1c sang. Dans le même référentiel, l’hôpital peut avoir des résultats LAB B déjà normalisés sous le code 17855-8 sur LOINC.
Les deux représentent des résultats de laboratoire A1C, mais les données devraient être normalisées à une norme comme LOINC pour que le système de santé puisse interpréter et analyser correctement les deux résultats de laboratoire.
Denormalisation Use-Case
Pensez à une plateforme de blogs où vous stockeriez des posts et des utilisateurs. Les posts font référence à leurs auteurs par le biais d’un champ Author_ID. Vous stockeriez ces deux entités dans des collections distinctes. C’est parce que les posts contiendront des vues, des likes, des commentaires et d’autres statistiques, et donc, auront besoin de plus de débit d’écriture par rapport aux utilisateurs.
Maintenant, vous mettriez peut-être à plat un flux des posts les plus récents et le flux agrégera directement les auteurs dans chaque post. Dans le data warehousing, on y parvient en définissant l’Author_ID des posts comme clé étrangère, puis en interrogeant les tables users et posts avec une transformation Join pour construire le flux en temps réel.
Cependant, cette option n’est pas disponible ici ; au lieu de cela, vous devrez dénormaliser vos données en préservant le flux dans un conteneur individuel qui attend d’être interrogé. Ce conteneur transportera une copie des données stockées dans les conteneurs users et posts, avec les auteurs consolidés dans les posts.
Conclusion
Le schéma que vous choisissez pour votre entrepôt de données dépend principalement des modèles d’accès des applications et de la taille de vos éléments de données. Vous pouvez consulter nos architectes de solutions pour garantir l’utilisation de techniques d’automatisation avancées lors de la normalisation ou de la dénormalisation de votre entrepôt de données.
.