Quand faut-il dénormaliser?
Je pense que nous connaissons tous normalisation de la base de données .
Ma question est: quelles sont les directives que vous utilisez lorsque vous souhaitez dénormaliser les tables?
Dénormaliser quand c'est OLAP opérations, normaliser quand OLTP (à partir de l'article lié sous 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 les bases de données destinées au traitement analytique en ligne (OLAP). OLTP se caractérisent par un volume élevé de petites transactions telles que la mise à jour d'un enregistrement de vente à la caisse d'un 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 "lues principalement". OLAP ont tendance à extraire les données historiques qui se sont accumulées sur une longue période). les bases de données, les données redondantes ou "dénormalisées" peuvent faciliter les applications de Business Intelligence. En particulier, les tables dimensionnelles dans 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 pendant le traitement d'extraction, de transformation, de chargement (ETL) et les utilisateurs doivent ne pas être autorisé à 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 flocons de neige. Dans de nombreux cas, le besoin de dénormalisation a diminué, les ordinateurs et les logiciels SGBDR étant devenus E plus puissant, mais comme les volumes de données ont généralement augmenté avec les 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 les petits ordinateurs, comme dans les caisses enregistreuses informatisées et les appareils mobiles, car ceux-ci peuvent utiliser les données uniquement pour la 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 Swift est cruciale).
Normaliser jusqu'à ce que ça fasse mal, dénormaliser jusqu'à ce que ça marche (c'est-à-dire: les performances deviennent acceptables) :)
Une raison potentiellement judicieuse d'appliquer contrôlée la dénormalisation est qu'elle permet d'appliquer une contrainte d'intégrité aux données qui ne serait pas possible autrement. La plupart des SGBD SQL ont une prise en charge extrêmement limitée des contraintes multi-tables. En SQL, le seul moyen efficace d'implémenter certaines contraintes est parfois 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 dicterait qu'ils appartiennent à des tables distinctes.
Contrôlé la dénormalisation signifie que des mécanismes sont mis en œuvre pour garantir que des incohérences ne peuvent pas survenir en raison de données redondantes. 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 en vaut la peine.
Une autre raison courante de dénormalisation est d'autoriser certains changements dans les structures de stockage ou d'autoriser une autre optimisation physique que le SGBD ne permettrait pas autrement. Selon le principe Physical Data Independence un SGBD devrait avoir les moyens de configurer les structures de stockage interne sans altérer inutilement la représentation logique des données dans la base de données. Malheureusement, de nombreux SGBD sont très restrictifs des options d'implémentation physique disponibles pour un 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 implémentation sous-optimale du modèle logique souhaité.
Cela devrait être évident, mais il faut le dire: dans tous les cas, ce ne sont que les modifications des fonctionnalités d'implémentation physique qui peuvent dicter les performances - des 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 les performances ou l'optimisation du stockage.
Dénormalisez si vous accédez fréquemment à des données calculées, comme cela est 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 recalculer encore et encore 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 ne question récente sur ce site - Je réplique une colonne dans une autre table, afin de pouvoir 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 de contraintes CHECK pour comparer des colonnes dans différentes lignes ou dans différentes tables, sauf si vous encapsulez une telle fonctionnalité dans des FDU scalaires invoquées à partir d'une contrainte CHECK. Que se passe-t-il si vous avez réellement besoin de comparer des colonnes dans différentes lignes ou dans différentes tables pour appliquer une règle métier? Par exemple, supposez que vous connaissez les heures de travail d'un médecin et que vous voulez vous assurer que tous les rendez-vous correspondent aux heures de travail? Bien sûr, vous pouvez utiliser un déclencheur ou une procédure stockée pour implémenter cette règle métier, mais ni un déclencheur ni une procédure stockée ne peuvent vous garantir à 100% que toutes vos données sont propres - quelqu'un peut désactiver ou supprimer votre déclencheur, entrez-en données sales, et réactivez ou recréez votre déclencheur. Quelqu'un peut également modifier directement votre table en contournant les procédures stockées. Dans les deux cas, vous pouvez vous retrouver avec des données enfreignant votre règle d'entreprise sans le savoir.
Permettez-moi de montrer comment implémenter cette règle métier en utilisant uniquement les contraintes FK et CHECK - cela garantira que toutes les données satisfont à la règle métier tant que toutes les contraintes sont approuvées.
Un autre exemple encore est n moyen de faire en sorte que les périodes de temps ne comportent ni lacunes ni chevauchements .