Quand faut-il dénormaliser?

Je pense que nous sommes tous familiers avec la normalisation des bases de données .

Ma question est la suivante: quelles sont les directives que vous utilisez lorsque vous souhaitez dénormaliser les tables?

Dénormaliser lorsqu'il s'agit d'opérations OLAP, normaliser lorsque OLTP (extrait de l'article lié dans la section Dénormalisation)

Les bases de données destinées au traitement des transactions en ligne (OLTP) sont généralement plus normalisées que celles qui sont destinées au traitement analytique en ligne (OLAP). Les applications OLTP se caractérisent par un volume élevé de petites transactions, telles que la mise à jour d'un enregistrement des ventes à une caisse de supermarché. On s'attend à ce que chaque transaction laisse la base de données dans un état cohérent. En revanche, les bases de données destinées aux opérations OLAP sont principalement des bases de données "principalement lues". Les applications OLAP ont tendance à extraire les données historiques accumulées sur une longue période. Pour ces bases de données, des données redondantes ou "dénormalisées" peuvent faciliter les applications de business intelligence. Plus précisément, les tables dimensionnelles d'un schéma en étoile contiennent souvent des données dénormalisées. Les données dénormalisées ou redondantes doivent être soigneusement contrôlées lors du traitement de l'extraction, de la transformation, du chargement (ETL), et les utilisateurs ne doivent pas être autorisés à voir les données tant qu'elles ne sont pas dans un état cohérent. L'alternative normalisée au schéma en étoile est le schéma en flocon de neige. Dans de nombreux cas, le besoin de dénormalisation a diminué à mesure que les ordinateurs et les logiciels de SGBDR devenaient plus puissants, mais comme les volumes de données ont généralement augmenté parallèlement aux performances matérielles et logicielles, les bases de données OLAP utilisent encore souvent des schémas dénormalisés.

La dénormalisation est également utilisée pour améliorer les performances sur des ordinateurs plus petits, comme dans les caisses enregistreuses informatisées et les appareils mobiles, car ceux-ci peuvent utiliser les données uniquement à des fins de recherche (par exemple, les recherches de prix). La dénormalisation peut également être utilisée lorsqu'il n'existe aucun SGBDR pour une plate-forme (telle que Palm), ou qu'aucune modification ne doit être apportée aux données et qu'une réponse rapide est cruciale.

Normalisez jusqu'à ce que vous ayez mal, dénormalisez jusqu'à ce que ça fonctionne (c.-à-d. Que les performances deviennent acceptables) :)

Une raison potentiellement judicieuse d'appliquer une dénormalisation contrôlée est si cela vous permet d'appliquer une contrainte d'intégrité aux données qui ne serait autrement pas possible. La plupart des SGBD SQL ont un support extrêmement limité pour les contraintes multi-tables. En SQL, parfois, le seul moyen efficace d'implémenter certaines contraintes est de s'assurer que les attributs impliqués dans la contrainte sont tous présents dans la même table, même lorsque la normalisation voudrait qu'ils appartiennent à des tables séparées.

La dénormalisation contrôlée signifie que des mécanismes sont mis en œuvre pour éviter les incohérences dues à la redondance des données. Le coût de ces contrôles supplémentaires et le risque de données incohérentes doivent être pris en compte pour décider si la dénormalisation vaut la peine.

Une autre raison courante de dénormalisation est de permettre certaines modifications des structures de stockage ou une autre optimisation physique que le SGBD ne permettrait pas autrement. Selon le principe de l' indépendance physique des données, un SGBD doit avoir le moyen de configurer des structures de stockage internes sans modifier inutilement la représentation logique des données dans la base de données. Malheureusement, de nombreux SGBD limitent considérablement les options d'implémentation physique disponibles pour tout schéma de base de données donné. Ils ont tendance à compromettre l'indépendance de la base de données physique en ne prenant en charge qu'une mise en œuvre sous-optimale du modèle logique souhaité.

Cela devrait être évident, mais il reste à dire: dans tous les cas, seuls les changements apportés aux fonctionnalités d’implémentation physique peuvent influer sur les performances: fonctionnalités telles que les structures de données internes, les fichiers, l’indexation, le matériel, etc. La normalisation et la dénormalisation n'ont rien à voir avec l'optimisation des performances ou du stockage.

Dénormaliser si vous accédez fréquemment aux données calculées, comme suggéré dans les réponses à cette question . Le coût de stockage et de maintenance des données calculées sera souvent inférieur au coût de re-calcul à maintes reprises si votre profil de charge est lourd en lecture.

Je dénormalise régulièrement afin de pouvoir appliquer l'intégrité des données avec des contraintes. Un exemple est une question récente sur ce site - Je réplique une colonne dans une autre table, de sorte que je puisse utiliser une contrainte CHECK pour la comparer à une autre colonne. Un autre exemple de cette technique est mon article de blog .

Vous ne pouvez pas utiliser les contraintes CHECK pour comparer des colonnes de différentes lignes ou de différentes tables, sauf si vous encapsulez de telles fonctionnalités dans des fonctions UDF scalaires appelées sous la forme d'une contrainte CHECK. Que faire si vous avez réellement besoin de comparer des colonnes de différentes lignes ou de différentes tables pour appliquer une règle de gestion? Par exemple, supposons que vous connaissiez les heures de travail d'un médecin et que vous souhaitiez vous assurer que tous les rendez-vous tiennent dans les heures de travail? Bien sûr, vous pouvez utiliser un déclencheur ou une procédure stockée pour mettre en œuvre cette règle de gestion, mais ni un déclencheur ni une procédure stockée ne peuvent vous garantir à 100% que toutes vos données sont neutres - quelqu'un peut désactiver ou supprimer votre déclencheur, saisissez données sales, et réactivez ou recréez votre déclencheur. En outre, quelqu'un peut modifier directement votre table en contournant les procédures stockées.

Laissez-moi vous montrer comment implémenter cette règle de gestion en utilisant uniquement les contraintes FK et CHECK, ce qui garantira que toutes les données satisfont à la règle de gestion tant que toutes les contraintes sont approuvées.

Encore un autre exemple est un moyen de faire en sorte que les périodes de temps ne comportent ni lacunes ni chevauchements .