// vous lisez...

Caractéristiques

Caractéristique de la BI : “Dénormalisons les données”

En décisionnel vous devez oublier tout ce que vous avez appris concernant les modélisation de données : oubliez formes normales, clé étrangères et autres principes compliqués. Place à la dénormalisation !

Quelques explications s’imposent. Tout d’abord pourquoi dans les systèmes opérationnels les formes normales sont privilégiés, puis à l’inverse, pourquoi le système décisionnel exige des données dénormalisées.

Bref retour en arrière donc. A l’époque des pères de l’informatique (situez donc ça dans les année 70-80), les capacités de traitement étaient limitées : coût important du stockage et faibles capacités de traitements. Dans cette optique des grandes théories ont été développées autour des bases de données afin de les rendre plus performantes : la normalisation. 1FN, 2FN … 6FN ! La normalisation à l’extrême permet d’établir des tables de références, et, grâce à des identifiants de faire des liens entre les données; l’objectif final étant qu’une donnée ne soit présente qu’une seule fois dans le système. Prenons un exemple : un client sera identifié par son nom, son adresse, son activité et sa ville. Dans le système : on aura alors une table client, un table type d’activité, une table ville voir même une table rue ! Si bien qu’un client sera la combinaison d’un nombre important d’identifiants pointants vers les différentes tables. De cette organisation résulte une mise à jour facilité et une cohérence importante dans les données. Les formes normales permettent aussi un gain de place important.Ainsi dans le cadre d’un système transactionnel où on fait des insertions et mises à jour de données, la forme normale est à l’heure actuelle la plus souvent utilisée.

Placez vous maintenant dans l’optique de consultation de données importante : vous devez mener une analyse portant par exemple sur les deux années précédentes afin de remonter les montants de commandes des clients de la ville de Nantes. Cette requête, si elle s’appuie sur une base de données normalisée, nécessitera de faire des jointures entre les différentes tables afin de remonter des informations en nombre très important. Votre système n’est alors clairement pas optimisé.

Pour faciliter la rapidité d’accès aux données lors de la consultation on dénormalise les tables. Dénormaliser ? Comprenez dupliquer l’information, la répéter, autant de fois que nécessaire afin de faire « descendre » les attributs au plus près des données : de cette façon on simplifie les relations et on optimise l’accès aux données. Si nous reprenons l’exemple de la modélisation du client, il n’existera alors plus qu’une seule table client contenant toutes les informations. On introduit de la redondance. L’intérêt ? Pas ou peu de jointure, et donc accès plus rapide. Revert de la médaille, l’information dupliquée prend beaucoup plus de place.

Alors que des systèmes dénormalisés étaient innimaginables il y a 10ans, la réduction importante des coût permet aujourd’hui des les utiliser dans le décisionnel… mais pas seulement : dès que l’on souhaite consulter des données il me paraît opportun de remettre en cause la normalisation à l’extrême des données.

Discussion

3 commentaires pour “Caractéristique de la BI : “Dénormalisons les données””

  1. Pour la consultation de données il est évident qu’il est plus simple de construire un rapport sur des données dénormalisées. Mais pour les performances, on repassera!

    Et l’espace disque, bien qu’il coûte moins cher qu’il y a trente ans, reste une denrée rare car on stocke beaucoup plus d’information qu’il y a trente ans.

    Donc la normalisation a toujours sa place. Et imaginez donc l’anarchie sans table de référence pour les villes… Les fautes d’ortographes, les données décomposables…

    La normalisation extrême par contre est un mal qui sévit encore trop souvent.

    Mais la dénormalisation extrême est tout autant nuisible à cause de l’absence totale de standards.

    Posté par Pascal Bellerose | janvier 28, 2010, 22:39
  2. Bonjour Pascal et merci pour votre commentaire.

    Pourquoi pensez-vous que les performances seront moins bonnes pour la consultation des données ? Au contraire ! Grâce à un schéma dénormalisé vous économisez en jointures; pour parler en terme technique il est moins gourmand en temps de traitement de faire un « SELECT * FROM ma_table_dénormalisée » qu’un « SELECT * FROM table1, table2, table3, table n WHERE jointures » … essayez donc sur un gros volume de données (quelques millions de lignes), vous verrez la différence !

    Concernant l’espace disque je suis d’accord : il faut encore faire attention d’autant qu’un giga de données utile en décisionnel va plutôt en représenter 3 voir 5 côté technique. Il faut penser aux index, aux réplications de bases qui sont très coûteux ! Il faut donc faire la part des choses.

    Pour la table de référence des villes, je considère que c’est à l’application en amont du système décisionnel de la maintenir pour garantir la cohérence des saisies utilisateur. Si elle ne le fait pas, on envisagera des étapes de nettoyage des données lors de leur acquisition dans le système de référence.

    N’hésitez pas à poursuivre cette discussion et à nous apporter votre point de vue et expérience !

    Posté par Brice Davoleau | février 6, 2010, 10:30
  3. []un schéma dénormalisé vous économisez en jointures; pour parler en terme technique il est moins gourmand en temps de traitement de faire un « SELECT * FROM ma_table_dénormalisée » qu’un « SELECT * FROM table1, table2, table3, table n WHERE jointures » []

    … Sauf que si les critères du WHERE sont aussi dans la table dénormalisée, vous serez obligés de faire une autojointure ou une sous requête sur cette même table dénormalisée dont la taille sera plus importante que table1, table 2… et donc perte de performances. C’est pour ce genre de cas que le modèle normalisé est plus flexible et plus performant.

    Posté par David | mars 4, 2010, 14:04

Poster un commentaire