Les bases de données OLAP doivent-elles être dénormalisées pour les performances de lecture?)

Question

J'ai toujours pensé que les bases de données devraient être dénormalisées pour les performances de lecture, comme cela est fait pour la conception de la base de données OLAP, et ne pas exagérer beaucoup plus 3NF pour la conception OLTP.

PerformanceDBA dans divers postes, par exemple, dans Performance de différents approches aux données temporelles défend le paradigme selon lequel la base de données devrait toujours être bien conçue par normalisation à 5NF et 6NF (forme normale).

L'ai-je bien compris (et qu'est-ce que j'avais bien compris)?

Quel est le problème avec l'approche de dénormalisation/conception de paradigme traditionnelle des bases de données OLAP (inférieure à 3NF) et l'avis que 3NF est suffisant pour la plupart des cas pratiques de bases de données OLTP?

Par exemple:

"La simple vérité ... est que 6NF, exécuté correctement, est l'entrepôt de données" (PerformanceDBA)

Je dois avouer que je n'ai jamais pu comprendre les théories selon lesquelles la dénormalisation facilite les performances de lecture. Quelqu'un peut-il me donner des références avec de bonnes explications logiques de cela et des croyances contraires?

Quelles sont les sources auxquelles je peux me référer lorsque j'essaie de convaincre mes parties prenantes que les bases de données OLAP/Data Warehousing doivent être normalisées?

Pour améliorer la visibilité, j'ai copié ici à partir des commentaires:

"Ce serait bien si les participants ajoutaient (révélaient) combien d'implémentations d'entrepôts de données de la vie réelle (aucun projet scientifique inclus) dans 6NF avaient vu ou participé. Une sorte de pool rapide. Me = 0." - Damir Sudarevic

article de Wikipedia sur l'entrepôt de données dit:

"L'approche normalisée [vs. dimensionnelle par Ralph Kimball], également appelée modèle 3NF (Troisième forme normale) dont les partisans sont appelés" Inmonites ", Croire en l'approche de Bill Inmon dans laquelle il est indiqué que l'entrepôt de données doit être modélisé en utilisant un modèle ER/modèle normalisé."

Il semble que l'approche de l'entreposage de données normalisé (par Bill Inmon) soit perçue comme ne dépassant pas 3NF (?)

Je veux juste comprendre quelle est l'origine du mythe (ou la croyance axiomatique omniprésente) selon laquelle l'entreposage de données/OLAP est synonyme de dénormalisation?

Damir Sudarevic a répondu que leur approche était bien pavée. Permettez-moi de revenir à la question: pourquoi la dénormalisation faciliterait-elle la lecture?

PerformanceDBA · Accepted Answer

Mythologie

J'ai toujours pensé que les bases de données devraient être dénormalisées pour la lecture, comme cela est fait pour la conception de base de données OLAP, et ne pas exagérer beaucoup plus 3NF pour la conception de OLTP.

Il y a un mythe à cet effet. Dans le contexte de la base de données relationnelle, j'ai réimplémenté six très grandes bases de données dites "dénormalisées"; et exécuté plus de quatre-vingts missions pour corriger les problèmes des autres, simplement en les normalisant, en appliquant des normes et des principes d'ingénierie. Je n'ai jamais vu aucune preuve du mythe. Seuls les gens répètent le mantra comme s'il s'agissait d'une sorte de prière magique.

Normalisation vs non normalisé

("Dénormalisation" est un terme frauduleux que je refuse d'utiliser.)

Il s'agit d'une industrie scientifique (au moins la partie qui fournit des logiciels qui ne cassent pas; qui mettent les gens sur la Lune; qui font fonctionner les systèmes bancaires; etc.). Il est régi par les lois de la physique et non par la magie. Les ordinateurs et les logiciels sont tous des objets physiques finis et tangibles qui sont soumis aux lois de la physique. Selon l'enseignement secondaire et supérieur que j'ai reçu:

il n'est pas possible qu'un objet plus grand, plus gros et moins organisé fonctionne mieux qu'un objet plus petit, plus fin et plus organisé.
La normalisation donne plus de tables, oui, mais chaque table est beaucoup plus petite. Et même s'il y a plus de tables, il y a en fait (a) moins de jointures et (b) les jointures sont plus rapides car les ensembles sont plus petits. Moins d'indices sont nécessaires dans l'ensemble, car chaque table plus petite nécessite moins d'indices. Les tableaux normalisés donnent également des tailles de ligne beaucoup plus courtes.
pour tout ensemble de ressources donné, tables normalisées:
- insérer plus de lignes dans la même taille de page
- donc adapter plus de lignes dans le même espace de cache, donc le débit global est augmenté)
- par conséquent, insérer plus de lignes dans le même espace disque, donc le nombre d'E/S est réduit; et lorsque des E/S sont nécessaires, chaque E/S est plus efficace.
  .
il n'est pas possible qu'un objet fortement dupliqué fonctionne mieux qu'un objet stocké comme une version unique de la vérité. Par exemple. lorsque j'ai supprimé la duplication 5 x au niveau de la table et de la colonne, toutes les transactions ont été réduites en taille; le verrouillage réduit; les anomalies de mise à jour ont disparu. Cela a considérablement réduit les conflits et donc augmenté l'utilisation simultanée.

Le résultat global était donc une performance bien plus élevée.

D'après mon expérience, qui fournit à la fois OLTP et OLAP à partir de la même base de données, il n'a jamais été nécessaire de "dénormaliser" mes structures normalisées, pour obtenir une vitesse de lecture plus élevée uniquement les requêtes (OLAP). C'est aussi un mythe.

Non, la "dénormalisation" demandée par d'autres a réduit la vitesse, et elle a été éliminée. Pas de surprise pour moi, mais encore une fois, les demandeurs ont été surpris.

De nombreux livres ont été écrits par des gens, vendant le mythe. Il faut reconnaître qu'il s'agit de personnes non techniques; puisqu'ils vendent de la magie, la magie qu'ils vendent n'a aucune base scientifique, et ils évitent commodément les lois de la physique dans leur argumentaire de vente.

(Pour toute personne qui souhaite contester la science physique ci-dessus, la simple répétition du mantra n'aura aucun effet, veuillez fournir des preuves spécifiques à l'appui du mantra.)

Pourquoi le mythe est-il répandu?

Eh bien, tout d'abord, il n'est pas répandu parmi les types scientifiques, qui ne cherchent pas à surmonter les lois de la physique.

D'après mon expérience, j'ai identifié trois raisons principales de la prévalence:

Pour les personnes qui ne peuvent pas normaliser leurs données, c'est une justification pratique pour ne pas le faire. Ils peuvent se référer au livre magique et sans aucune preuve de la magie, ils peuvent dire avec révérence "voir un écrivain célèbre valide ce que j'ai fait". Pas fait, plus précisément.
De nombreux codeurs SQL ne peuvent écrire que du SQL simple et à un seul niveau. Les structures normalisées nécessitent un peu de capacité SQL. S'ils n'en ont pas; s'ils ne peuvent pas produire de SELECT sans utiliser de tables temporaires; s'ils ne peuvent pas écrire de sous-requêtes, ils seront psychologiquement collés à la hanche dans des fichiers plats (ce que sont les structures "dénormalisées") qu'ils peuvent traiter.
Les gens aiment lire des livres et discuter des théories. Sans expérience. Surtout la magie. C'est un tonique, un substitut à l'expérience réelle. Quiconque a réellement normalisé une base de données correctement n'a jamais déclaré que "la dénormalisation est plus rapide que la normalisation". À quiconque énonce le mantra, je dis simplement "montrez-moi les preuves", et ils n'en ont jamais produit. Donc, la réalité est que les gens répètent la mythologie pour ces raisons sans aucune expérience de normalisation . Nous sommes des animaux de troupeau et l'inconnu est l'une de nos plus grandes craintes.

C'est pourquoi j'inclus toujours du SQL "avancé" et du mentorat sur n'importe quel projet.

Ma réponse

Cette réponse va être ridiculement longue si je réponds à toutes les parties de votre question ou si je réponds aux éléments incorrects dans certaines des autres réponses. Par exemple. ce qui précède a répondu à un seul élément. Par conséquent, je vais répondre à votre question dans son ensemble sans aborder les composants spécifiques et adopter une approche différente. Je ne traiterai que de la science liée à votre question, pour laquelle je suis qualifié et très expérimenté.

Permettez-moi de vous présenter la science en segments gérables. Typical First Generation "databases"
Le modèle typique des six missions d'implémentation complète à grande échelle.

Il s'agit des "bases de données" fermées que l'on trouve couramment dans les petites entreprises, et les organisations sont de grandes banques
très sympa pour une mentalité de première génération, qui fonctionne bien, mais un échec complet en termes de performances, d'intégrité et de qualité
ils ont été conçus pour chaque application, séparément
le signalement n'était pas possible, ils ne pouvaient le signaler que par application
puisque "dénormalisé" est un mythe, la définition technique exacte est, ils étaient non normalisés
- Pour "dénormaliser", il faut d'abord normaliser; puis inversez un peu le processus dans chaque cas où les gens me montraient leurs modèles de données "dé-normalisés", le fait était qu'ils n'avaient pas du tout normalisé; la "dénormalisation" n'était donc pas possible; c'était simplement non normalisé
comme ils n'avaient pas beaucoup de technologie relationnelle, ni les structures et le contrôle des bases de données, mais ils étaient considérés comme des "bases de données", j'ai placé ces mots entre guillemets
comme cela est scientifiquement garanti pour les structures non normalisées, ils ont subi plusieurs versions de la vérité (duplication des données) et donc une forte contention et une faible concurrence, au sein de chacune d'entre elles
ils avaient un problème supplémentaire de duplication des données à travers les "bases de données"
l'organisation essayait de garder tous ces doublons synchronisés, alors ils ont implémenté la réplication; ce qui bien sûr signifiait un serveur supplémentaire; ETL et scripts de synchronisation à développer; et maintenu; etc
inutile de dire que la synchronisation n'a jamais été tout à fait suffisante et qu'ils l'ont toujours changé
avec toute cette controverse et ce faible débit, il n'y avait aucun problème à justifier un serveur séparé pour chaque "base de données". Cela n'a pas beaucoup aidé.

Nous avons donc contemplé les lois de la physique et appliqué un peu de science. 5NF Corporate Database
Nous avons mis en œuvre le concept standard selon lequel les données appartiennent à la société (et non aux ministères) et la société voulait une version de la vérité. La base de données était purement relationnelle, normalisée à 5NF. Pure Open Architecture, pour que toute application ou outil de rapport puisse y accéder. Toutes les transactions dans des proc stockés (par opposition aux chaînes SQL non contrôlées sur tout le réseau). Les mêmes développeurs pour chaque application ont codé les nouvelles applications, après notre formation "avancée".

Évidemment, la science a fonctionné. Eh bien, ce n'était pas ma science ou ma magie privée, c'était l'ingénierie ordinaire et les lois de la physique. Tout cela a fonctionné sur une seule plateforme de serveur de base de données; deux paires (production & DR) de serveurs ont été mises hors service et confiées à un autre service. Les 5 "bases de données" totalisant 720 Go ont été normalisées en une base de données totalisant 450 Go. Environ 700 tables (de nombreux doublons et colonnes dupliquées) ont été normalisées en 500 tables non dupliquées. Il fonctionnait beaucoup plus rapidement, comme dans 10 fois plus vite dans l'ensemble, et plus de 100 fois plus rapide dans certaines fonctions. Cela ne m'a pas surpris, car c'était mon intention, et la science l'a prédit, mais cela a surpris les gens avec le mantra.

Plus de normalisation

Eh bien, après avoir réussi la normalisation dans chaque projet et avoir confiance en la science impliquée, il a été naturel de normaliser plus , pas moins. Autrefois, le 3NF était assez bon, et les NF ultérieurs n'étaient pas encore identifiés. Au cours des 20 dernières années, je n'ai livré que des bases de données qui n'avaient aucune anomalie de mise à jour, donc il s'avère que, selon les définitions actuelles des NF, j'ai toujours livré 5NF.

De même, 5NF est génial mais il a ses limites. Par exemple. Le pivotement de grandes tables (pas de petits ensembles de résultats selon l'extension MS PIVOT) était lent. J'ai donc (et d'autres) développé un moyen de fournir des tableaux normalisés de telle sorte que le pivot était (a) facile et (b) très rapide. Il s'avère, maintenant que 6NF a été défini, que ces tables sont 6NF.

Depuis que je fournis OLAP et OLTP à partir de la même base de données, j'ai constaté que, conformément à la science, plus les structures sont normalisées:

plus ils effectuent vite
et ils peuvent être utilisés de plusieurs façons (par exemple, les pivots)

Alors oui, j'ai une expérience cohérente et constante, qui non seulement est normalisée beaucoup, beaucoup plus rapidement que non normalisée ou "dénormalisée"; plus normalisé est encore plus rapide que moins normalisé.

Un signe de succès est la croissance de la fonctionnalité (le signe de l'échec est la croissance de la taille sans croissance de la fonctionnalité). Ce qui signifie qu'ils nous ont immédiatement demandé plus de fonctionnalités de reporting, ce qui signifie que nous avons normalisé encore plus , et fourni plus de ces tables spécialisées (qui se sont révélées être des années plus tard 6NF).

Progresser sur ce thème. J'ai toujours été un spécialiste de la base de données, pas un spécialiste de l'entrepôt de données, donc mes premiers projets avec des entrepôts n'étaient pas des implémentations complètes, mais plutôt des tâches de réglage des performances substantielles. Ils étaient dans mon domaine, sur des produits dans lesquels je me suis spécialisé. Typical Data Warehouse
Ne nous inquiétons pas du niveau exact de normalisation, etc., car nous examinons le cas typique. Nous pouvons considérer que la base de données OLTP était raisonnablement normalisée, mais pas capable d'OLAP, et que l'organisation avait acheté une plate-forme OLAP complètement séparée, du matériel; investi dans le développement et le maintien de masses de code ETL; etc. Et après la mise en œuvre, ils ont passé la moitié de leur vie à gérer les doublons qu'ils avaient créés. Ici, les auteurs et les fournisseurs de livres doivent être blâmés pour le gaspillage massif de matériel et licences logicielles de plate-forme distinctes qu'ils obligent les organisations à acheter.

Si vous ne l'avez pas encore observé, je vous demanderais de noter les similitudes entre la "base de données" type de première génération et le entrepôt de données type

Pendant ce temps, de retour à la ferme (les bases de données 5NF ci-dessus), nous avons continué à ajouter de plus en plus de fonctionnalités OLAP. Bien sûr, la fonctionnalité de l'application a augmenté, mais c'était peu, l'entreprise n'avait pas changé. Ils demanderaient plus de 6NF et c'était facile à fournir (5NF à 6NF est une petite étape; 0NF à n'importe quoi, encore moins 5NF, est une grande étape; une architecture organisée est facile à étendre).

Une différence majeure entre OLTP et OLAP, la justification de base du logiciel de plateforme séparé OLAP, est que le OLTP est orienté sur les lignes, il a besoin de lignes sécurisées sur le plan des transactions et rapide; et le OLAP ne se soucie pas des problèmes transactionnels, il a besoin de colonnes, et rapide. C'est la raison pour laquelle toutes les plateformes BI ou OLAP haut de gamme sont orientées colonnes, et c'est pourquoi les OLAP les modèles (Schéma en étoile, Dimension-Fact) sont orientés colonne.

Mais avec les tables 6NF:

il n'y a pas de lignes, seulement des colonnes; nous servons des lignes et des colonnes à la même vitesse aveuglante
les tables (c'est-à-dire la vue 5NF des structures 6NF) sont déjà organisées en Dimension-Facts. En fait, ils sont organisés en plus de dimensions que n'importe quel modèle OLAP ne pourrait jamais identifier, car ce sont toutes dimensions.
Faire pivoter des tables entières avec agrégation à la volée (par opposition au PIVOT d'un petit nombre de colonnes dérivées) est (a) un code simple et sans effort et (b) très rapide

Ce que nous fournissons depuis de nombreuses années, par définition, ce sont des bases de données relationnelles avec au moins 5NF pour OLTP utilisation, et 6NF pour OLAP exigences.

Notez que c'est la même science que nous avons utilisée depuis le début; pour passer de "bases de données" non normalisées typiques à 5NF Corporate Database . Nous appliquons simplement plus de la science éprouvée et obtenons des niveaux plus élevés de fonctionnalités et de performances.
Remarquez la similitude entre 5NF Corporate Database et 6NF Corporate Database
Le coût total du matériel OLAP, du logiciel de plate-forme, de l'ETL, de l'administration, de la maintenance, est entièrement éliminé.
Il n'y a qu'une seule version des données, aucune anomalie de mise à jour ou maintenance de celles-ci; les mêmes données servies pour OLTP comme lignes et pour OLAP comme colonnes

La seule chose que nous n'avons pas faite, c'est de démarrer sur un nouveau projet, et de déclarer 6NF pur dès le départ. C'est ce que j'ai aligné ensuite.

Qu'est-ce que la sixième forme normale?

En supposant que vous maîtrisiez la normalisation (je ne vais pas la définir ici), les définitions non académiques pertinentes pour ce fil sont les suivantes. Notez qu'il s'applique au niveau de la table, vous pouvez donc avoir un mélange de tables 5NF et 6NF dans la même base de données:

Cinquième forme normale : toutes les dépendances fonctionnelles résolues dans la base de données
- en plus de 4NF/BCNF
- chaque colonne non PK est 1 :: 1 avec son PK
- et à aucun autre PK
- Aucune anomalie de mise à jour
  .
Sixième forme normale : est le NF irréductible, le point auquel les données ne peuvent plus être réduites ou normalisées (il n'y aura pas de 7NF)
- en plus de 5NF
- la ligne se compose d'une clé primaire et au plus d'une colonne non clé
- élimine le problème nul

À quoi ressemble 6NF?

Les modèles de données appartiennent aux clients et notre propriété intellectuelle n'est pas disponible pour publication gratuite. Mais j'assiste à ce site Web et je donne des réponses précises aux questions. Vous avez besoin d'un exemple réel, donc je publierai le modèle de données pour l'un de nos utilitaires internes.

Celui-ci est destiné à la collecte de données de surveillance de serveur (serveur de base de données de classe entreprise et système d'exploitation) pour n'importe quel client, pour n'importe quelle période. Nous l'utilisons pour analyser les problèmes de performances à distance et pour vérifier tout réglage des performances que nous faisons. La structure n'a pas changé depuis plus de dix ans (ajoutée, sans changement aux structures existantes), il est typique du 5NF spécialisé que de nombreuses années plus tard a été identifié comme 6NF. Permet un pivotement complet; n'importe quel tableau ou graphique à dessiner, sur n'importe quelle dimension (22 pivots sont fournis mais ce n'est pas une limite); émincer; mélanger et assortir. Notez que ce sont toutes dimensions.

Les données de surveillance ou les métriques ou les vecteurs peuvent changer (changements de version du serveur; nous voulons ramasser quelque chose de plus) sans affecter le modèle (vous vous souviendrez peut-être dans un autre post que j'ai déclaré que EAV est le fils bâtard de 6NF; eh bien c'est plein 6NF, le père non dilué, et fournit donc toutes les fonctionnalités de l'EAV, sans sacrifier les normes, l'intégrité ou la puissance relationnelle); vous ajoutez simplement des lignes.

▶ Surveiller le modèle de données statistiques ◀ . (trop grand pour inline; certains navigateurs ne peuvent pas charger inline; cliquez sur le lien)

Cela me permet de produire ces ▶ graphiques comme celui-ci ◀ , six frappes après avoir reçu un fichier de statistiques de surveillance brut du client. Remarquez le mix-and-match; OS et serveur sur le même graphique; une variété de pivots. (Utilisé avec permission.)

Les lecteurs qui ne sont pas familiers avec la norme de modélisation des bases de données relationnelles peuvent trouver la ▶ Notation IDEF1X ◀ utile.

Entrepôt de données 6NF

Cela a été récemment validé par Anchor Modeling , dans la mesure où ils présentent maintenant 6NF comme le modèle OLAP de "nouvelle génération" pour les entrepôts de données. (Ils ne fournissent pas les OLTP et OLAP à partir de la version unique des données, qui est la nôtre uniquement).

Expérience de l'entrepôt de données (uniquement)

Mon expérience avec les entrepôts de données uniquement (pas les bases de données 6NF OLTP-OLAP ci-dessus), a été plusieurs missions majeures, par opposition à des projets de mise en œuvre complète. Les résultats ont été, sans surprise:

conformément à la science, les structures normalisées fonctionnent beaucoup plus rapidement; sont plus faciles à entretenir; et nécessitent moins de synchronisation de données. Inmon, pas Kimball.
cohérent avec la magie, après avoir normalisé un tas de tableaux, et livré des performances sensiblement améliorées via l'application des lois de la physique, les seules personnes surprises sont les magiciens avec leurs mantras.

Les gens à l'esprit scientifique ne font pas cela; ils ne croient pas aux balles d'argent et à la magie, ni ne s'y fient; ils utilisent la science et le travail acharné pour résoudre leurs problèmes.

Justification valide de l'entrepôt de données

C'est pourquoi j'ai déclaré dans d'autres articles, la seule justification valable pour une plate-forme Data Warehouse distincte, le matériel, l'ETL, la maintenance, etc., est là où il existe de nombreuses bases de données ou "bases de données" ", tous étant fusionnés dans un entrepôt central, pour le reporting et OLAP.

Kimball

Un mot sur Kimball est nécessaire, car il est le principal partisan de la "dénormalisation des performances" dans les entrepôts de données. Selon mes définitions ci-dessus, il est l'une de ces personnes qui n'ont évidemment jamais normalisé dans leur vie; son point de départ n'était pas normalisé (camouflé comme "dénormalisé") et il l'a simplement implémenté dans un modèle Dimension-Fact.

Bien sûr, pour obtenir des performances, il a dû "dénormaliser" encore plus, créer de nouveaux doublons et justifier tout cela.
- Il est donc vrai, d'une manière schizophrénique, que la "dénormalisation" des structures non normalisées, en faisant des copies plus spécialisées, "améliore les performances de lecture". Ce n'est pas vrai quand le tout tient compte; ce n'est vrai qu'à l'intérieur de ce petit asile, pas à l'extérieur.
- De même, il est vrai, de cette façon folle, que là où toutes les "tables" sont des monstres, que les "jointures coûtent cher" et quelque chose à éviter. Ils n'ont jamais eu l'expérience de joindre des tables et des ensembles plus petits, ils ne peuvent donc pas croire au fait scientifique que de plus petites tables sont plus rapides.
- ils ont l'expérience que créer des "tables" en double est plus rapide, donc ils ne peuvent pas croire que éliminer les doublons est encore plus rapide que cela.
ses Dimensions sont ajoutées aux données non normalisées. Eh bien, les données ne sont pas normalisées, donc aucune dimension n'est exposée. Alors que dans un modèle normalisé, les dimensions sont déjà exposées, en tant que partie intégrante des données, aucun ajout n'est requis.
ce chemin bien pavé de Kimball mène à la falaise, où plus de lemmings tombent à leur mort, plus rapidement. Les lemmings sont des animaux de troupeau, tant qu'ils marchent ensemble sur le chemin et qu'ils meurent ensemble, ils meurent heureux. Les lemmings ne recherchent pas d'autres voies.

Toutes des histoires, des parties d'une mythologie qui se côtoient et se soutiennent mutuellement.

Votre mission

Si vous choisissez de l'accepter. Je vous demande de penser par vous-même et de cesser de nourrir toute pensée qui contredit la science et les lois de la physique. Peu importe à quel point ils sont communs, mystiques ou mythologiques. Cherchez des preuves pour quoi que ce soit avant de lui faire confiance. Soyez scientifique, vérifiez par vous-même les nouvelles croyances. Répéter le mantra "dénormalisé pour les performances" ne rendra pas votre base de données plus rapide, il vous fera simplement vous sentir mieux. Comme le gros gosse assis sur la touche en se disant qu'il peut courir plus vite que tous les enfants de la course.

sur cette base, même le concept "normaliser pour OLTP" mais faire le contraire, "dénormaliser pour OLAP" est une contradiction. Comment les lois de la physique peuvent-elles fonctionner comme indiqué sur un ordinateur, mais fonctionner à l'envers sur un autre ordinateur? L'esprit s'embrouille. Ce n'est tout simplement pas possible, le travail de la même manière sur chaque ordinateur.

Des questions ?

Ronnis · Answer

La dénormalisation et l'agrégation sont les deux principales stratégies utilisées pour obtenir des performances dans un entrepôt de données. Il est juste stupide de suggérer que cela n'améliore pas les performances de lecture! Je dois sûrement avoir mal compris quelque chose ici?

Agrégation: Considérons un tableau contenant 1 milliard d'achats. Comparez-le avec un tableau contenant une ligne avec la somme des achats. Maintenant, qui est plus rapide? Sélectionnez une somme (montant) dans le tableau à un milliard de lignes ou un montant sélectionné dans le tableau à une ligne? C'est un exemple stupide bien sûr, mais il illustre assez clairement le principe d'agrégation. Pourquoi est-ce plus rapide? Parce que quel que soit le modèle magique/matériel/logiciel/religion que nous utilisons, la lecture de 100 octets est plus rapide que la lecture de 100 gigaoctets. Aussi simple que cela.

dénormalisation: Une dimension de produit typique dans un entrepôt de données de vente au détail comporte des charges de colonnes. Certaines colonnes sont des trucs faciles comme "Nom" ou "Couleur", mais il y a aussi des trucs compliqués, comme des hiérarchies. Hiérarchies multiples (la gamme de produits (5 niveaux), l'acheteur prévu (3 niveaux), les matières premières (8 niveaux), le mode de production (8 niveaux) ainsi que plusieurs nombres calculés tels que le délai moyen (depuis le début de l'année) , poids/mesures d'emballage etcetera etcetera. J'ai maintenu un tableau des dimensions du produit avec plus de 200 colonnes qui a été construit à partir de ~ 70 tableaux provenant de 5 systèmes sources différents.

select product_id from table1 join table2 on(keys) join (select average(..) from one_billion_row_table where lastyear = ...) on(keys) join ...table70 where function_with_fuzzy_matching(table1.cola, table37.colb) > 0.7 and exists(select ... from ) and not exists(select ...) and table20.version_id = (select max(v_id from product_ver where ...) and average_price between 10 and 20 and product_range = 'High-Profile'

... est plus rapide que la requête équivalente sur le modèle dénormalisé:

select product_id from product_denormalized where average_price between 10 and 20 and product_range = 'High-Profile';

Pourquoi? En partie pour la même raison que le scénario agrégé. Mais aussi parce que les requêtes sont juste "compliquées". Ils sont tellement horriblement compliqués que l'optimiseur (et maintenant je vais les spécificités d'Oracle) est confus et fout les plans d'exécution. Les plans d'exécution sous-optimaux peuvent ne pas être si importants si la requête concerne de petites quantités de données. Mais dès que nous commençons à rejoindre les Big Tables, c'est crucial que la base de données obtient le bon plan d'exécution. Après avoir dénormalisé les données dans une table avec une seule clé de syntaxe (diable, pourquoi ne pas ajouter plus de carburant à ce feu en cours), les filtres deviennent de simples filtres de plage/égalité sur des colonnes précuites. La duplication des données dans de nouvelles colonnes nous permet de collecter des statistiques sur les colonnes qui aideront l'optimiseur à estimer les sélectivités et ainsi à nous fournir un plan d'exécution correct (enfin, ...).

De toute évidence, l'utilisation de la dénormalisation et de l'agrégation rend plus difficile la prise en compte des modifications de schéma, ce qui est une mauvaise chose. En revanche, ils fournissent des performances de lecture, ce qui est une bonne chose.

Alors, devez-vous dénormaliser votre base de données afin d'obtenir des performances de lecture? Sûrement pas! Il ajoute tellement de complexités à votre système qu'il n'y a pas de limite au nombre de façons dont il vous vissera avant que vous n'ayez livré. Est-ce que ça vaut le coup? Oui, parfois vous devez le faire pour répondre à une exigence de performance spécifique.

mise à jour 1

PerformanceDBA: 1 ligne serait mise à jour un milliard de fois par jour

Cela impliquerait une exigence (presque) en temps réel (qui à son tour générerait un ensemble complètement différent d'exigences techniques). De nombreux (sinon la plupart) entrepôts de données n'ont pas cette exigence. J'ai choisi un exemple d'agrégation irréaliste juste pour montrer clairement pourquoi l'agrégation fonctionne. Je ne voulais pas non plus avoir à expliquer les stratégies de cumul :)

En outre, il faut comparer les besoins de l'utilisateur typique d'un entrepôt de données et de l'utilisateur typique du système sous-jacent OLTP système. Un utilisateur cherchant à comprendre quels facteurs entraînent les coûts de transport, s'en foutait moins si 50% des données d'aujourd'hui sont manquantes ou si 10 camions ont explosé et tué les conducteurs. Effectuer l'analyse sur une valeur de 2 ans reviendrait toujours à la même conclusion même s'il avait des informations à jour de la seconde à sa disposition.

Comparez cela aux besoins des conducteurs de ce camion (ceux qui ont survécu). Ils ne peuvent pas attendre 5 heures à un point de transit simplement parce qu'un processus d'agrégation stupide doit finir. Le fait d'avoir deux copies distinctes des données résout les deux besoins.

Un autre obstacle majeur au partage du même ensemble de données pour les systèmes opérationnels et les systèmes de rapports est que les cycles de publication, les questions-réponses, le déploiement, SLA et ce que vous avez, sont très différents. Encore une fois, avoir deux les copies facilitent la gestion.

nvogel · Answer

Par "OLAP", je comprends que vous entendez une base de données relationnelle/SQL orientée sujet utilisée pour l'aide à la décision - AKA un entrepôt de données.

La forme normale (généralement la 5e/6e forme normale) est généralement le meilleur modèle pour un entrepôt de données. Les raisons de normaliser un entrepôt de données sont exactement les mêmes que toute autre base de données: cela réduit la redondance et évite les anomalies de mise à jour potentielles; il évite les biais intégrés et est donc le moyen le plus simple de prendre en charge le changement de schéma et les nouvelles exigences. L'utilisation de Normal Form dans un entrepôt de données permet également de maintenir le processus de chargement des données simple et cohérent.

Il n'y a pas d'approche de dénormalisation "traditionnelle". De bons entrepôts de données ont toujours été normalisés.

Thilo · Answer

Une base de données ne doit-elle pas être dénormalisée pour les performances de lecture?

D'accord, voici une réponse totale "Votre kilométrage peut varier", "Cela dépend", "Utilisez l'outil approprié pour chaque travail", "Une seule taille ne convient pas à tous", avec un peu de "Ne pas le réparer s'il le fait" Ain't Broken "ajouté:

La dénormalisation est un moyen d'améliorer les performances des requêtes dans certaines situations. Dans d'autres situations, cela peut en fait réduire les performances (en raison de l'utilisation accrue du disque). Cela rend certainement les mises à jour plus difficiles.

Il ne doit être pris en compte que lorsque vous rencontrez un problème de performances (car vous bénéficiez des avantages de la normalisation et introduisez de la complexité).

Les inconvénients de la dénormalisation sont moins problématiques avec les données qui ne sont jamais mises à jour, ou uniquement mises à jour dans les travaux par lots, c'est-à-dire pas les données OLTP.

Si la dénormalisation résout un problème de performances que vous devez résoudre et que les techniques moins invasives (comme les index ou les caches ou l'achat d'un plus gros serveur) ne résolvent pas, alors oui, vous devriez le faire.

Unreason · Answer

D'abord mes opinions, puis quelques analyses

Avis
La dénormalisation est perçue comme facilitant la lecture des données car l'utilisation courante de la dénormalisation Word inclut souvent non seulement la rupture des formes normales, mais également l'introduction de toute dépendance d'insertion, de mise à jour et de suppression dans le système.

Ceci, à proprement parler, est faux , voir ceci question/réponse , la dénormalisation au sens strict signifie briser tout ce qui est normal les formulaires de 1NF-6NF, les autres dépendances d'insertion, de mise à jour et de suppression sont traités avec Principe of Orthogonal Design .

Donc, ce qui se passe, c'est que les gens prennent le principe de compromis espace vs temps et se souviennent du terme redondance (associé à la dénormalisation, toujours pas égal à lui) et concluent que vous devriez avoir des avantages. C'est une implication erronée, mais de fausses implications ne vous permettent pas de conclure l'inverse.

Rompre les formes normales mai en effet accélérer certains récupération des données (détails dans l'analyse ci-dessous), mais en règle générale, cela se fera également en même temps:

favoriser uniquement un type spécifique de requêtes et ralentir tous les autres chemins d'accès
augmenter la complexité du système (ce qui influence non seulement la maintenance de la base de données elle-même, mais augmente également la complexité des applications qui consomment les données)
obscurcir et affaiblir la clarté sémantique de la base de données
point principal des systèmes de base de données, car les données centrales représentant l'espace problématique doivent être impartiales dans l'enregistrement des faits, de sorte que lorsque les exigences changent, vous n'avez pas à repenser les parties du système (données et applications) qui sont en réalité indépendantes. pour être en mesure de le faire, les dépendances artificielles doivent être réduites au minimum - l'exigence "critique" actuelle d'accélérer une requête ne devient souvent qu'une importance marginale.

Analyse

J'ai donc affirmé que parfois briser formes normales peut aider à la récupération. Il est temps de donner quelques arguments

1) Briser 1NF

Supposons que vous ayez des dossiers financiers dans 6NF. À partir d'une telle base de données, vous pouvez sûrement obtenir un rapport sur ce qu'est un solde pour chaque compte pour chaque mois.

En supposant qu'une requête qui aurait à calculer un tel rapport devrait passer par n enregistrements, vous pourriez créer un tableau

account_balances(month, report)

qui détiendrait des soldes structurés XML pour chaque compte. Cela casse 1NF (voir les notes plus loin), mais permet à une requête spécifique de s'exécuter avec E/S minimum.

Dans le même temps, en supposant qu'il est possible de mettre à jour n'importe quel mois avec des insertions, des mises à jour ou des suppressions de dossiers financiers, les performances des requêtes de mise à jour sur le système peuvent être ralenties par le temps proportionnellement à une fonction de n pour chaque mise à jour. (le cas ci-dessus illustre un principe, en réalité, vous auriez de meilleures options et l'avantage d'obtenir un minimum d'E/S entraînerait des pénalités telles que pour un système réaliste qui met à jour les données souvent, vous obtiendriez de mauvaises performances même pour votre requête ciblée en fonction de la type de charge de travail réelle; peut expliquer cela plus en détail si vous le souhaitez)

Remarque: Ceci est en fait un exemple trivial et il y a un problème avec cela - la définition de 1NF. L'hypothèse selon laquelle le modèle ci-dessus casse 1NF est conforme à l'exigence que les valeurs d'un attribut ' contiennent exactement une valeur du domaine applicable'.

Cela vous permet de dire que le domaine du rapport d'attributs est un ensemble de tous les rapports possibles et que de chacun d'eux il y a exactement une valeur et de prétendre que 1NF n'est pas rompu (similaire à l'argument selon lequel le stockage des mots ne rompt pas 1NF même si vous pourriez avoir une relation letters quelque part dans votre modèle).

D'un autre côté, il existe de bien meilleures façons de modéliser ce tableau, qui seraient plus utiles pour un éventail plus large de requêtes (comme pour récupérer des soldes pour un compte unique pour tous les mois d'une année). Dans ce cas, vous justifieriez cette amélioration en disant que ce champ n'est pas en 1NF.

Quoi qu'il en soit, cela explique pourquoi les gens affirment que la rupture des NF pourrait améliorer les performances.

2) Briser 3NF

Supposons des tables en 3NF

CREATE TABLE `t` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `member_id` int(10) unsigned NOT NULL, `status` tinyint(3) unsigned NOT NULL, `amount` decimal(10,2) NOT NULL, `opening` decimal(10,2) DEFAULT NULL, PRIMARY KEY (`id`), KEY `member_id` (`member_id`), CONSTRAINT `t_ibfk_1` FOREIGN KEY (`member_id`) REFERENCES `m` (`id`) ON DELETE CASCADE ON UPDATE CASCADE ) ENGINE=InnoDB CREATE TABLE `m` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `name` varchar(255) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB

avec des échantillons de données (1M lignes en t, 100k en m)

Supposons une requête commune que vous souhaitez améliorer

mysql> select sql_no_cache m.name, count(*) from t join m on t.member_id = m.id where t.id between 100000 and 500000 group by m.name; +-------+----------+ | name | count(*) | +-------+----------+ | omega | 11 | | test | 8 | | test3 | 399982 | +-------+----------+ 3 rows in set (1.08 sec)

vous pouvez trouver des suggestions pour déplacer l'attribut name dans la table m qui casse 3NF (il a un FD: member_id -> name et member_id n'est pas une clé de t)

après

alter table t add column varchar(255); update t inner join m on t.member_id = t.id set t.name = m.name;

fonctionnement

mysql> select sql_no_cache name, count(*) from t where id between 100000 and 500000 group by name; +-------+----------+ | name | count(*) | +-------+----------+ | omega | 11 | | test | 8 | | test3 | 399982 | +-------+----------+ 3 rows in set (0.41 sec)

notes: Le temps d'exécution de la requête ci-dessus est réduit de moitié , mais

la table n'était pas en 5NF/6NF pour commencer
le test a été fait avec no_sql_cache donc la plupart des mécanismes de cache ont été évités (et dans des situations réelles, ils jouent un rôle dans les performances du système)
la consommation d'espace est augmentée d'environ 9 fois la taille du nom de la colonne x 100 000 lignes
il devrait y avoir des déclencheurs sur t pour maintenir l'intégrité des données, ce qui ralentirait considérablement toutes les mises à jour du nom et ajouterait des vérifications supplémentaires que les insertions dans t devraient effectuer
de meilleurs résultats pourraient probablement être obtenus en supprimant les clés de substitution et en passant aux clés naturelles et/ou à l'indexation, ou à la refonte vers des NF plus élevées

La normalisation est la bonne façon à long terme. Mais vous n'avez pas toujours la possibilité de reconcevoir la société ERP (qui n'est par exemple déjà majoritairement que 3NF) - parfois vous devez accomplir certaines tâches avec des ressources données. Bien sûr, cela n'est que court terme "solution".

Conclusion

Je pense que la réponse la plus pertinente à votre question est que vous trouverez l'industrie et l'éducation en utilisant le terme "dénormalisation" dans

au sens strict, pour briser les NF
vaguement, pour introduire des dépendances d'insertion, de mise à jour et de suppression (citation originale de Codd commentaires sur la normalisation en disant: ' indésirables (!) dépendances d'insertion, de mise à jour et de suppression ', voir quelques détails ici )

Ainsi, selon une définition stricte, l'agrégation (tableaux récapitulatifs) n'est pas considérée comme une dénormalisation et elle peut beaucoup aider en termes de performances (comme tout cache, qui n'est pas perçu comme une dénormalisation).

L'utilisation lâche englobe à la fois la rupture des formes normales et le principe de conception orthogonale , comme dit précédemment.

Une autre chose qui pourrait nous éclairer est qu'il existe une différence très importante entre le modèle logique et le modèle physique.

Par exemple, les index stockent des données redondantes, mais personne ne les considère comme une dénormalisation, pas même les personnes qui utilisent le terme de manière lâche et il y a deux raisons (liées) à cela

ils ne font pas partie du modèle logique
ils sont transparents et garantissent de ne pas briser l'intégrité de votre modèle

Si vous ne modélisez pas correctement votre modèle logique, vous vous retrouverez avec une base de données incohérente - mauvais types de relations entre vos entités (incapacité à représenter l'espace problématique), des faits contradictoires (capacité à perdre des informations) et vous devez utiliser toutes les méthodes que vous pouvez pour obtenir un modèle logique correct, il est le fondement de toutes les applications qui seront construites par-dessus.

La normalisation, la sémantique orthogonale et claire de vos prédicats, des attributs bien définis, des dépendances fonctionnelles correctement identifiées jouent tous un rôle pour éviter les pièges.

En ce qui concerne l'implémentation physique, les choses deviennent plus détendues dans le sens où une colonne calculée matérialisée correcte qui dépend de la non clé peut casser 3NF, mais s'il existe des mécanismes qui garantissent la cohérence, elle est autorisée dans le modèle physique de la même manière que les index. sont autorisés, mais vous devez très soigneusement le justifier car généralement la normalisation apportera des améliorations identiques ou meilleures à tous les niveaux et n'aura pas ou moins d'impact négatif et gardera la conception claire (ce qui réduit la les coûts de développement et de maintenance des applications), ce qui permet de réaliser des économies que vous pouvez facilement consacrer à la mise à niveau du matériel pour améliorer encore plus la vitesse que celle obtenue avec la rupture des NF.

Damir Sudarevic · Answer

Les deux méthodologies les plus populaires pour la construction d'un entrepôt de données (DW) semblent être celles de Bill Inmon et Ralph Kimball.

La méthodologie d'Inmon utilise une approche normalisée, tandis que celle de Kimball utilise une modélisation dimensionnelle - un schéma d'étoiles dénormalisé.

Les deux sont bien documentés jusque dans les moindres détails et les deux ont de nombreuses implémentations réussies. Les deux présentent une "route large et bien pavée" vers une destination DW.

Je ne peux pas commenter l'approche 6NF ni la modélisation d'ancrage car je n'ai jamais vu ni participé à un projet DW utilisant cette méthodologie. En ce qui concerne les implémentations, j'aime emprunter des voies bien testées - mais ce n'est que moi.

Donc, pour résumer, DW devrait-il être normalisé ou dénormalisé? Cela dépend de la méthodologie que vous choisissez - choisissez-en simplement une et respectez-la, au moins jusqu'à la fin du projet.

EDIT - Un exemple

À l'endroit où je travaille actuellement, nous avions un rapport hérité qui fonctionne depuis toujours sur le serveur de production. Pas un simple rapport, mais une collection de 30 sous-rapports envoyés chaque jour à tout le monde et à sa fourmi.

Récemment, nous avons implémenté un DW. Avec deux serveurs de rapports et un tas de rapports en place, j'espérais que nous pourrions oublier l'héritage. Mais non, l'héritage est l'héritage, nous l'avons toujours eu, donc nous le voulons, en avons besoin, ne pouvons pas vivre sans, etc.

Le fait est que le désordre d'un script python et SQL a pris huit heures (oui, huit heures) pour s'exécuter tous les jours. Inutile de dire que la base de données et l'application ont été reconstruites années par quelques lots de développeurs - donc, pas exactement votre 5NF.

Il était temps de recréer l'héritage à partir du DW. Ok, pour faire court, c'est fait et cela prend 3 minutes (t-h-r-e-e minutes) pour le produire, six secondes par sous-rapport. Et j'étais pressé de livrer, donc je n'optimisais même pas toutes les requêtes. C'est un facteur de 8 * 60/3 = 160 fois plus rapide - sans parler des avantages de la suppression d'un travail de huit heures d'un serveur de production. Je pense que je peux encore me raser d'une minute ou deux, mais pour l'instant personne ne s'en soucie.

Comme point d'intérêt, j'ai utilisé la méthode de Kimball (modélisation dimensionnelle) pour le DW et tout ce qui est utilisé dans cette histoire est open-source.

C'est ce que tout cela (entrepôt de données) est censé être, je pense. La méthodologie (normalisée ou dénormalisée) a-t-elle même été utilisée?

EDIT 2

Comme point d'intérêt, Bill Inmon a un article bien écrit sur son site Web - A Tale of Two Architectures .

Walter Mitty · Answer

Le problème avec le mot "dénormalisé" est qu'il ne spécifie pas dans quelle direction aller. C'est comme essayer de se rendre à San Francisco depuis Chicago en s'éloignant de New York.

Un schéma en étoile ou un schéma en flocon de neige n'est certainement pas normalisé. Et il fonctionne certainement mieux qu'un schéma normalisé dans certains modèles d'utilisation. Mais il y a des cas de dénormalisation où le concepteur ne suivait aucune discipline, mais composait simplement des tables par intuition. Parfois, ces efforts échouent.

En bref, ne dénormalisez pas seulement. Suivez une discipline de conception différente si vous êtes sûr de ses avantages, et même si elle n'est pas d'accord avec une conception normalisée. Mais n'utilisez pas la dénormalisation comme excuse pour une conception aléatoire.

James Anderson · Answer

La réponse courte est ne corrigez pas un problème de performances que vous n'avez pas!

Comme pour les tables basées sur le temps, le pardigme généralement accepté est d'avoir des dates valid_from et valid_to dans chaque ligne. Il s'agit toujours essentiellement de 3NF car cela ne fait que changer la sémantique de "c'est la seule et unique version de cette entité" à "c'est la seule et unique version de cette entité pour le moment"

Mitch Wheat · Answer

Simplification:

Une base de données OLTP doit être normalisée (pour autant que cela ait du sens).

Un OLAP entrepôt de données doit être dénormalisé en tables de faits et de dimensions (pour minimiser les jointures).