Discussion :

[Bruno75]

J'ai une petite tendance à normaliser à mort mes tables. Quels sont les critères qui indiquent que l'on doit dénormaliser son modèle ? Il ne s'agit pas ici de la base de reporting mais de la base "transactionnelle".

[laffreuxthomas]

Tout dépend du problème.

Dans le cadre d'un Data Warehouse, on dénormalise. Ca reste gérable puisque normallement on ajoute des données, puis on les consulte. on ne les modifie jamais. C'est pas ton cas manifestement.

Tu poses ta question à propos de quoi ? Si tes collègues râlent à cause des jointures à rallonge alors n'hésite pas à continuer à les faire râler.

Si tu as des problèmes d'optimisation tu peux tenter d'ajouter des index. Des index sont au fond des redondances techniques gérés par le SGBD et dont l'intégrité est garantie par le sgbd.

Donc pourquoi cette question ?

[Bruno75]

Le reporting est un cas standard ou la dénormalisation est de mise. Dans le cas du reporting, c'est pour des raisons de performances. Existe-t-il d'autres cas typiques où l'on dénormalise ? (pour diverses raisons).

[Cotentin]

salut,

tu peux denormalises aussi lorsque tu as besoin de consulter un grand de lignes avant de trouver ton bonheur.
cela permet aussi d'eviter des calculs longs et fastidieux

[grafikm_fr]

Perso, je considere que si la normalisation en 3FN aboutit à un nombre trop elevé de tables, il convient d'en denormaliser quelques une sinon bonjour le temps de réponse...

[SQLpro]

Le principe fondamental pour décider d'un dénormalisatio est le suivant :

1) normaliser au maximum lors de la création de la base
2) mettre en exploitation et mesurer régulièrement les temps de réponse
3) laisser la base vivre quelques semaine, mois ou années suivant la montée en charge de données
4) prendre les 20% des requêtes ayant les temps de réponse les plus longs et refaire en parallèle une base dénormalisée
5) comparer les temps de réponse entre la base "normale" lorsqu'il a peu d'utilisateurs et les temps de réponse de la base dénormalisée.

Si les temps de réponse dénormalisé sont de plus de 30% inférieur passer à la dénormalisation.

Revenir sur le sujet tous les ...

L'expérience m'a montré que lorsque la bse avait été bien normalisé et à condition de n'utiliser que des clefs auto incrémentées avec des index clusterisés, aucune dénormalisation n'avait besoin d'être introduite.

En revanche, pour simplifier le modèle, créer des vues ou des SP qui renvoie des tables, notamment pour les éditions.

Le probléme de conversion en décisionnel est tout autre. Dans ce cas : modèle en étoile ou flocon + réplication

A +

[Cotentin]

salut,

dis donc sql pro, as tu vraiment tester ce que tu dis, ou alors c'est seulement de la théorie ?
Parce que dans le cas de production, où la base est sollicité
je ne vois bien leur dire, que l'on doit les arreter pour changer les bases et recompiler les programmes
je travaille dans une usine de decoupe de viande, et ce sont plutot des as du couteaux n'ayant pas du tout de patience etant donné qu'il travaille à la piece.

La dénormalisation doit etre prevue lors de l'analyse des données.
Où la charge de travail doit etre calculer et prevue à l'avance

une fois, la base créé ont a pas à revenir dessus.

[al1_24]

Il faut aussi penser à l'évolution de la base de données.

Si la dénormalisation consiste à remplacer une table détail par une série de colonnes supplémentaires (exemple : les enfants d'un foyer), on risque de se trouver soit limité (pas assez de colonnes), soit encombré(des colonnes souvent vides).

Si la dénormalisation consiste à répéter les identifiants d'une nomenclature dans la table détail (pour simplifier les regroupements ?), il faut être certain que la nomenclature en question ne changera pas, ou prévoir des mises à jours longues et risquées.

Le probléme de conversion en décisionnel est tout autre. Dans ce cas : modèle en étoile ou flocon + réplication

Dans le cadre d'un Data Warehouse, on dénormalise. ...

On peut très bien développer un DWH en 3FN, même avec des milliards de lignes et plusieurs To de données. L'important c'est d'avoir un bon moteur...

Comme l'a si bien dit laffreuxthomas

Si tes collègues râlent à cause des jointures à rallonge alors n'hésite pas à continuer à les faire râler.

[Pomalaix]

Le principe fondamental pour décider d'un dénormalisatio est le suivant :

1) normaliser au maximum lors de la création de la base
2) mettre en exploitation et mesurer régulièrement les temps de réponse
3) laisser la base vivre quelques semaine, mois ou années suivant la montée en charge de données
4) prendre les 20% des requêtes ayant les temps de réponse les plus longs et refaire en parallèle une base dénormalisée
5) comparer les temps de réponse entre la base "normale" lorsqu'il a peu d'utilisateurs et les temps de réponse de la base dénormalisée.

Si les temps de réponse dénormalisé sont de plus de 30% inférieur passer à la dénormalisation.

Revenir sur le sujet tous les ...

Je me pince là !
Vous auriez pu me dire qu'on était le 1er avril !

[Admin]

Personnelement, vu le peu d'experience que j'ai sur Oracle, j'ai toujours considéré qu'une base normalisée bien faite fonctionne mieux qu'une base dénormalisée.

[siocnarf]

--> Pomalaix
Quand tu auras fini de te pincer et si tu as le temps, pourrais-tu nous dire ce que tu préconise sur la normalisation/dénormalisation ?

Merci d'avance

[grafikm_fr]

On peut très bien développer un DWH en 3FN, même avec des milliards de lignes et plusieurs To de données. L'important c'est d'avoir un bon moteur...

Deja qu'avec un bon moteur et un truc denormalisé un DW c'est la galere, alors en 3FN...

D'ailleurs dès que tu retient un modele en étoile (ce qui est le cas pour la plupart des DW), il n'est par definition pas en 3FN puisque la table contient une hierarchie complete...

Le modele flocon peut etre en 3FN mais il sera lent et difficilement gérable... Peut-etre dans l'avenir...

[SQLpro]

Mais pour du DataWaehouse il existe des SGBD (R ?) spécialisé comme celui de Sybase...

Donc pas besoin de faire du DW dans du SGBDR. Choisir le bon outil pour donner la bonne solution au problème posé !

A +

[grafikm_fr]

Je suis d'accord avec toi SQLPro, mais tout DWH basé sur une techno ROLAP (BO etc...) s'appuie sur une SGBDR (un peu modifiée certes, mais une SGBDR quand meme...) et les regles de normalisation (et surtout de dénormalisation) sont valables aussi. Non?

Bien sur, tu peux mettre une techno MOLAP qui n'a plus rien à voir avec une SGBDR mais là c'est une autre histoire... Et ROLAP c'est à 95% du relationnel, avec les memes contraintes (sauf que les regles de passage sont très legerement differentes)

[Pomalaix]

--> Pomalaix
Quand tu auras fini de te pincer et si tu as le temps, pourrais-tu nous dire ce que tu préconise sur la normalisation/dénormalisation ?

Bonjour

De manière générale, j'essaye d'être pragmatique.
La dénormalisation se justifie si ses avantages sont supérieurs à ses inconvénients, tout simplement !

Pourquoi normaliser, au fait ? Principalement :
1) par souci d'économie d'espace, pour éviter de dupliquer une même donnée N fois, ou de laisser des zones vides
2) par souci de cohérence, pour éviter que des données qui devraient être identiques ne le soient pas (en raison d'erreurs de saisie par exemple)

En bon normatolâtre, on devrait par exemple créer une table TITRE (contenant M., Mme et Mle) dès lors qu'on gère des clients ou des personnes.
Mais qu'est-ce qui s'oppose à ce qu'on stocke le titre directement dans la table client ?
Concernant l'espace disque, il n'est pas plus avantageux de stocker une clé étrangère qu'une valeur de 3 caractères.
Concernant la cohérence, une contrainte de validation permet de s'assurer simplement que les seules valeurs acceptées sont bien M. Mme ou Mle et rien d'autre.
En revanche, si l'on veut connaître les différents titres de civilité des clients, on est obligés de faire un DISTINCT sur la colonne TITRE de la table CLIENT (plusieurs milliers de lignes), alors qu'il suffisait dans la situation de précédente de consulter une table minuscule.
Si ce dernier point pose problème, parce qu'on a très fréquemment besoin de la liste des différents titres, alors la normalisation est sans doute préférable. Dans le cas contraire, fonçons ! On voit que la réponse n'est pas uniquement technique, elle demande une bonne connaissance des besoins fonctionnels.

Une question courante de dénormalisation concerne les valeurs agrégées.
Par exemple, on peut juger plus efficace d'ajouter une colonne PLACES_LIBRES dans une table VOL_AERIEN, plutôt que d'aller interroger à chaque fois la table des réservations pour le vol concerné, en exécutant une somme ou un décompte. Ce report peut se faire de manière simple et transparente par un déclencheur, à chaque réservation.

La complexité de la structure et le nombre de jointures ne sont pas sans importance non plus.
En effet, même si des jointures impliquant 10 ou 12 tables correctements indexées restent généralement efficaces, il est certain qu'il est plus économique en entrées/sorties d'aller lire dans une seule table que dans 2 pour faire une jointure.
(A ce sujet, les clusters de tables supportés par certains SGBD permettent de stocker physiquement côte à côte des données de tables différentes mais fréquemment en jointure, ce qui limite donc les entrées sorties)

Par ailleurs, même si les vues permettent de masquer la complexité sous-jacente des tables, il faut penser aux cas où les utilisateurs font des requêtes libres avec un outil de restitution quelconque, type BO ou autre. Dans ce cas, sauf utilisateur très averti, un informaticien reste souvent indispensable pour aider l'utilisateur à s'y retrouver dans une structure ultra-normalisée, avec des jointures externes, etc.
Dénormaliser quelque peu (en toute sécurité grâce aux mécanismes d'intégrité fournis par les contraintes ou les déclencheurs) peut alors être judicieux si on reste conscient des éventuels inconvénients générés en contrepartie.

[Alexandre T]

Le logiciel sur lequel je travaille possède une base de données totalement dénormalisée pour simplifier les éditions que les clients peuvent souhaiter faire avec leurs outils de reporting.

Résultat redondance mal traitée et temps de réponse trop lent.

J'ai tout normalisé, j'ai "concaténé" la base de sept de nos plus gros client, j'ai démontré qu'infomaker faisait graphiquement et automatiquement les jointures sans la moindre erreur.

Les temps de réponses sont dans mon prototype (qui contient bien plus de données que les bases de prod) plus rapide de 45% aux temps de réponses sur la base des clients. (J'ai bien fait mes mesures aux heures creuses évidemment). Pourtant ma solution a été refusée car la direction ne comprends pas la normalisation.

Résultat : temps de développement : 5x supérieur à la normale. Temps d'accès 50% plus lents que la normale, mais tout va bien Madame la comtesse.

[SQLpro]

Pomalaix disait :

le jour où un théoricien va découvrir la 6NF, devra-t-on en déduire que toutes les bases existantes sont à jeter ??

Non seulement la 6NF existe bien (et depuis 2005) mais elle est très intéressante pour les problématiques de données temporelles.

A noter aussi la DKNF qui se situe après la 5NF.

Quelques liens sur le sujet :
les formes normales :
http://en.wikipedia.org/wiki/Database_normalization
http://experts.about.com/e/d/da/data...malization.htm

Discussion sur ces formes normales particulières
par Chris Date :
http://www.dbdebunk.com/page/page/621935.htm


A +

[Thes32]

Salut
y a rien de plus intelligents que de normailiser une table. une table denormaliser manque de cohérence.
normalise jusqu'au BCFN ça ira mieux

[StringBuilder]

Bonjour,

Je viens ajouter un petit grain de sable à l'édifice.

Je travaille sur un ERP, qui s'appelle Generix.

Et cet outils m'a ouvert les yeux sur une nouvelle façon de modéliser les bases de données.

En effet, outre normaliser/dénormaliser, il y a une étape d'abstraction à prendre en compte.

En effet, cet ERP par du principe que, dans une entreprise, j'ai par exemple un nombre infini de tiers :
Client, Fournisseur, Prospects, Dépôts, Magasins, Centrales d'achat, Vendeurs, etc.

Idem pour les "évènements" : habituellement, on a les flux suivants en Gescom, mais il peut y en avoir d'autres :
devis, commande, livraison, facture ; avoir ; retour ; que ce soit en achat ou en vente.

La normalisation préconise de faire une table par type de tiers (donc une table client, une table magasin, une table vendeur, etc.)

Idem avec les évènements.

Et c'est vite le bordel :
1/ On a 500 tables avec des structures communes
2/ Le jour où on a besoin d'une nouvelle fonctionnalité (je introduire une notion de carriste dans ma base pour tracer qui a mis quoi où et quand dans mon dépôt), je dois recréer des tables pour gérer mon carriste, et des tables pour gérer la mise en rayon dans mon dépôt.

L'abstraction joue alors son rôle ici :
- Ben mon carriste, c'est un tiers comme un client ou un magasin
- Ben le fait de placer un produit en rayon, c'est exactement comme une livraison ou un avoir fournisseur

Et donc après avoir créé 500 entités dans le MCD, on mutualise les tables, en ajoutant des colonnes dans la clé primaire.

Dans Generix par exemple, dans la table tiers, la clé est composé de 3 colonnes :

CODSOC : Code société (ceci permet à plusieurs entités juridiques d'utiliser la même base de données, avec notions de hiérarchie dans les tables de référentiel)
TYPTIE : Type de tiers (CLI = Client, REP = Vendeur, DEP = Dépôt, etc.)
SIGTIE : Identifiant du tiers

Et pour les événements :

CODSOC
ACHVTE : Indicateur Achat ou Vente
TYPEVE : Type d'évènement (CDE = Commande, FAC = Facture, LIV = livraison, etc.)
NUMEVE : Numéro de la commande/livraison/...

L'ensemble des éléments venant s'ajouter à la clé composite tels que TYPTIE, ACHVTE, TYPEVE sont gérés dynamiquement dans des tables de correspondances, ce qui permet d'étendre le modèle des données sans créer de nouvelles tables.

Et même plus loin : un table permet d'étendre les colonnes d'une table pour une clé donnée, et ainsi d'avoir virtuellement autant d'attributs spécifiques dans chaque table

Et une table "fourre tout" permet de stocker dans une structure commune l'ensemble des tables de référence de la base (la liste des ACHVTE/TYPEVE/NUMEVE, mais aussi la description de ce qu'est ma zone 824 sur mon événement de type LIV, et même la liste de valeurs autorisés dans cette zone).

En gros, là où normalement, on aurait besoin de plus de 100 tables pour gérer un flux GESCOM standard, Generix n'a besoin en tout et pour tout que... d'une dizaine de tables à tout casser.

Ceci a plusieurs avantages :
1/ Simplicité du modèle : un nombre restrein de tables à utiliser
2/ Généricité des requêtes et des binaires : le binaire qui gère un client ou un dépôt par exemple est identique et utilise les mêmes requêtes : seul la valeur du TYPTIE diffère dans les requêtes
3/ Fluidité de la lecture des tables : malgré des alias à la mord-moi-le-noeud, un TYPTIE ou un TYPEVE collé dans une requête permet d'identifier dans la seconde sur quelle "table" on travaille

Niveau performances, je n'ai jamais trop comparé, mais je doute très fortement que cela impacte quoi que ce soit, et même au contraire.

Donc avant de dénormaliser comme un porc, je pense qu'il est intéressant de faire cette passe d'abstraction du modèle, afin de le simplifier.

[fsmrel]

La normalisation préconise de faire une table par type de tiers (donc une table client, une table magasin, une table vendeur, etc.)

Vous confondez normalisation et modélisation. La normalisation n’a rien à voir dans votre histoire : elle recommande seulement d’appliquer le théorème de Heath quand une table viole la BCNF, le 1er théorème de Fagin en cas de viol de la 4NF, etc.

Votre problème relève de la modélisation : au niveau conceptuel, il est évident qu’en présence de 36 types de tiers, tout concepteur normalement constitué mettra en œuvre une entité-type (ou une classe) TIERS en relation avec une entité-type (ou une classe) TYPE_DE_TIERS. Au niveau tabulaire, ces deux entités-types feront chacune l’objet d’une table.

Dans Generix par exemple, dans la table tiers, la clé est composé de 3 colonnes :
CODSOC : Code société (ceci permet à plusieurs entités juridiques d'utiliser la même base de données, avec notions de hiérarchie dans les tables de référentiel) :
TYPTIE : Type de tiers (CLI = Client, REP = Vendeur, DEP = Dépôt, etc.)
SIGTIE : Identifiant du tiers

Si d’aventure l’identifiant de deux tiers distincts ne peut pas prendre la même valeur, alors votre triplet de colonnes ne peut pas représenter une clé mais seulement une surclé.

Je viens ajouter un petit grain de sable à l'édifice [...] Avant de dénormaliser comme un porc [...]

Evitez surtout à l’avenir de commettre des erreurs de casting. Vous pouvez donc tranquillement remettre votre grain de sable dans votre seau et réfléchir à ce que l'on entend par modéliser proprement.