Pourquoi les tables de reporting sont-elles en général dénormalisées alors que les bases transactionnelles sont normalisées ?

La normalisation optimise l'écriture et l'intégrité, donc une base transactionnelle évite de dupliquer les données et met à jour une ligne à un seul endroit. Le reporting optimise la lecture sur d'énormes balayages, où chaque jointure coûte du temps et chaque table supplémentaire coûte de la clarté à l'analyste. Un schéma en étoile dénormalisé signifie moins de jointures, des requêtes plus rapides sur du stockage colonne, et des noms de colonnes qu'un analyste comprend sans dictionnaire de données.

Elles résolvent des problèmes différents. Une base transactionnelle est faite pour beaucoup de petites écritures avec une intégrité stricte, donc normaliser fait que l'adresse d'un client existe une seule fois et que la mettre à jour est une seule écriture. Une table analytique est faite pour balayer des millions de lignes d'un coup, où chaque jointure est un coût et où une jointure sur quinze tables est à la fois lente et difficile à écrire correctement. On dénormalise donc en faits et en dimensions conformes, ce qui réduit les jointures et donne aux analystes des noms de colonnes lisibles au lieu d'un schéma et de trois tables de correspondance. Le stockage colonne rend cela peu coûteux, puisque répéter une chaîne de pays sur des millions de lignes se compresse jusqu'à presque rien. L'autre raison est opérationnelle. Lancer un gros balayage analytique sur la base de production entre en concurrence avec l'application pour les ressources, et j'ai vu une requête ad hoc mettre à terre un service de paiement. Même en ignorant complètement la modélisation, la charge analytique a sa place là où elle ne peut pas nuire aux clients.