Les bases de données OLAP doivent-elles être dénormalisées pour la performance 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 bases de données OLAP, et ne pas exagérer beaucoup plus loin 3NF pour la conception OLTP.

PerformanceDBA dans différents postes, par exemple, dans Performances des différentes approches des données temporelles défend le paradigme selon lequel les bases de données doivent toujours être bien conçues par normalisation en 5NF et 6NF (forme normale).

L'ai-je bien compris (et qu'ai-je bien compris) ?

Qu'est-ce qui ne va pas avec l'approche traditionnelle de dénormalisation/paradigme de conception des bases de données OLAP (en dessous de 3NF) et le conseil 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 saisir 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 ceci et des croyances contraires ?

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

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

"Ce serait bien si les participants ajouteraient (divulgueraient) le nombre d'études de la vie réelle (pas d'études de projets scientifiques inclus) implémentations d'entrepôts de données en 6NF qu'ils ont vues ou auxquelles ils ont participé. Une sorte de pool rapide. Moi = 0." - Damir Sudarevic

Article sur les entrepôts de données de Wikipedia raconte :

"L'approche normalisée [par opposition à l'approche dimensionnelle de Ralph Kimball], également appelée la Modèle 3NF (Troisième Forme Normale) dont les partisans sont appelés " Inmonites ", croient en l'approche de Bill Inmon dans laquelle l'entrepôt de données doit être modélisé à l'aide d'un modèle E-R ou d'un modèle normalisé. modèle/normalisé".

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

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

Damir Sudarevic répond qu'il s'agit d'une approche bien pavée. Permettez-moi de revenir à la question : Pourquoi croit-on que la dénormalisation facilite la lecture ?

Answer 1

Les deux méthodologies les plus populaires pour construire un entrepôt de données (DW) semblent être celle de Bill Inmon et celle de 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 en étoile dé-normalisé.

Les deux sont bien documentés jusque dans les moindres détails et ont tous deux fait l'objet de nombreuses mises en œuvre réussies. Les deux présentent une "route large et bien pavée" vers une destination DW.

Je ne peux pas faire de commentaires sur l'approche 6NF ni sur le modèle d'ancrage car je n'ai jamais vu ni participé à un projet DW utilisant cette méthodologie. Lorsqu'il s'agit d'implémentations, j'aime emprunter des chemins éprouvés - mais, ce n'est que moi.

Donc, pour résumer, DW doit-il être normalisé ou dé-normalisé ? Cela dépend de la méthodologie que vous choisissez. Il suffit d'en choisir une et de s'y tenir, 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. Il ne s'agissait pas d'un simple rapport, mais d'une collection de 30 sous-rapports envoyés par courriel à tout le monde chaque jour.

Récemment, nous avons mis en place un DW. Avec deux serveurs de rapports et un grand nombre 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, nous en avons besoin, nous ne pouvons pas vivre sans, etc.

Le fait est que le mélange d'un script python et de SQL prenait huit heures (oui, e-i-g-h-t heures) à exécuter chaque jour. Inutile de dire que la base de données et l'application ont été construites sur des années par quelques lots de développeurs -- donc, pas exactement votre 5NF.

Il était temps de recréer le truc de l'héritage depuis le DW. Ok, pour faire court, c'est fait et il faut 3 minutes (t-h-r-e-e minutes) pour le produire, six secondes par sous-rapport. Et comme j'étais pressé de livrer, je n'ai même pas optimisé 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 sur un serveur de production. Je pense que je peux encore gagner une minute ou deux, mais pour l'instant, tout le monde s'en fiche.

À titre d'information, 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 (l'entrepôt de données) est censé être, je pense. La méthodologie utilisée (normalisée ou dé-normalisée) a-t-elle une importance ?

EDIT 2

À titre d'information, Bill Inmon a publié un article très bien écrit sur son site Web L'histoire de deux architectures .

Answer 2

Le problème avec le mot "dénormalisé" est qu'il ne précise pas dans quelle direction aller. C'est un peu comme si on essayait d'aller de Chicago à San Francisco en partant de New York.

Un schéma en étoile ou un schéma en flocon de neige n'est certainement pas normalisé. Et il est certain qu'il est plus performant qu'un schéma normalisé dans certains cas d'utilisation. Mais il existe des cas de dénormalisation où le concepteur ne suivait aucune discipline, mais composait simplement des tables par intuition. Parfois, ces efforts ne portent pas leurs fruits.

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

Answer 3

La réponse courte est ne réparez pas un problème de performance que vous n'avez pas eu !

En ce qui concerne les tableaux temporels, le principe généralement admis est d'avoir des dates de début et de fin de validité dans chaque ligne. Cela reste fondamentalement 3NF car cela ne fait que changer la sémantique de "ceci est la seule et unique version de cette entité" à "ceci est la seule et unique version de cette entité". à l'heure actuelle "

Answer 4

Simplification :

Une base de données OLTP doit être normalisée (dans la mesure où cela a du sens).

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