Je continue avec la formation BI et le résultat n’est pas parfait. Je suis au 14ème slide au bout de 7 jours. Sachant que 4 premiers slides étaient le titre et les objectifs de la formation… Mais je suis toujours bien motivée et je lis joyeusement le titre « Normalisation (NF). Typologie de modèle de données et gestion de qualité de données ». WTF ?? Déjà le titre me pose le problème. Qu’est-ce que c’est que cette abréviation ? FN : touche de clavier « fonction » ? Front National ? Fusion Nucléaire ? Et NF alors : Norme Française ? « Neuf » ? Neurofibromatose ?
Finalement pas tout ça. NF en anglais est « Normal Form » et FN – la même chose en français, « Forme Normale ». Vous avez compris, on va parler de la normalisation des bases de données.
Normalisation de données est un processus d’organisation des données, de leur structuration. En fait, normaliser les données c’est comme organiser et ranger votre armoire de vêtements. Nous sommes d’accord, que quand les vêtements sont dans l’ordre, un t-shirt se trouve plus facilement, plus rapidement même à 6 heures du matin, même dans l’obscurité car vous savez parfaitement dans quelle pille il faudra aller chercher. Alors notre but quand nous allons normaliser la base de donnée sera d’organiser nos données de façon le plus logique possible en suivant les modèles (ou formes) et ainsi augmenter la qualité de données et diminuer le nombre des erreurs dans nos données. Youpi, j’ai compris le titre.
Quand je lis des articles sur ce sujet, des professionnelles vous promettent de rendre nos requêtes et des mises à jours plus efficaces et plus rapides, d’accélérer le processus d’extraction de données, de minimiser des erreurs de saisie ou de suppression de l’information et aussi de réduire la taille de la base de données. Bref, ça ressemble à la magie. Autant de comprendre comment ça marche.
Nous avons compris, plus notre base de données est normalisée (organisée), moins il y a de chances d’y apporter des erreurs. Car plus la table est normalisée (ie plus sa forme NF est élevée), plus son modèle pour les données est prédéfinie et rigide et, donc, moins il y a de chances pour l’utilisateur d’y rajouter des données de façon aléatoire et ainsi ajouter des erreurs.
Maintenant on va voir les 3 premières formes de normalisation mais avant il faut dire que chaque forme normale s’appuie sur la forme précédente. Ça veut dire on ne peut pas passer directement à la NF2 sans passer avant par la NF1.
De 0NF à la 1NF
On commence par deux exemples de tables avec la forme normale « zéro ».
Regardons le premier tableau avec les différentes taches d’un processus. On voit la première ligne qui s’appelle « Cleaning » mais on voit ensuite que la deuxième ligne est complètement identique. Ainsi si nous voulons, par exemple, mettre à jour la première ligne, nous ne pourrons pas le faire sans changer la deuxième ligne en même temps. Et c’est super embêtant pour nous car en fait, la première règle de la normalisation indique que la base de données ne doit pas avoir des lignes qui stockent l’information absolument identique. Qu’est-ce que nous pouvons faire pour distinguer ces deux lignes ? Par exemple on ajoute un ID pour chaque ligne. Ou bien nous pouvons laisser qu’une seule ligne et ajouter une colonne avec le nombre des opérations réalisées et y mettre la chiffre « 2 ».
Ainsi nous allons avoir pour chaque ligne l’information unique dans son ensemble dans toute la table. STOP. Ensemble de l’information unique… dans toutes les tables… ça me rappelle quelque chose… Bingo ! Nous devons mettre en place les clés primaires.
Donc, la première condition de la première forme normale est la présence de la Primary Key (clé primaire en anglais).
Passons maintenant à la deuxième table.
On voit que tous les numéros de téléphone ont été ajoutés ensemble dans une cellule de la table en forme de liste.
Si je n’utilise pas ces téléphones tous les jours, je m’en fiche. Mais si je mets en place un call center il me faudra associer à chaque numéro les commentaires (tels quels : « pro/domicile », « heure d’appelle préférable », etc.) Je fais comment? J’imprime les tables et mets un commentaire en face de chaque numéro ? Pas génial. Pour résoudre ce problème je pourrai deviser cette table en deux : la première table avec l’ID, le nom et le prénom de personne et la deuxième table avec l’ID et les numéros de téléphones. Cela nous amène à la deuxième condition de la première forme normale : une valeur par cellule et pas de liste.
De 1NF à la 2NF
Prenons l’exemple de cette table. On voit qu’elle est en 1NF car il n’y a pas de listes dans les cellules et pas de lignes identiques.
On s’est mis d’accord que la 2NF doit avoir toutes les propriétés de la 1NF. Alors, cette table doit avoir la clé primaire. Dans l’exemple avec les numéros de téléphones la clé primaire était facile à trouver – c’était l’ID de personne. J’observe cette nouvelle table avec des livres et je suis perplexe : les deux premières lignes contiennent l’info sur le même livre. Donc, le titre n’est pas la clé primaire. Ou pas encore. Ensuite je vois que chaque livre est en format différent (broché ou e-book). Et le prix, par exemple, dépend du livre ET de son format. Cela m’amène à l’idée que la clé primaire dans ce cas est composée de deux parties (champs, colonnes) et que les certains attributs de la table (prix, par exemple) dépendent de la clé primaire toute entière. Or on ne peut pas savoir le prix si nous savons uniquement le format du livre et on ne peut pas savoir le prix du livre si nous savons uniquement son titre. En revanche, l’auteur de livre ne dépend pas de la clé primaire entière. L’auteur dépend seulement du titre mais pas du format de livre. Est-ce que c’est 2NF ou pas ? Après avoir regardé des vidéos sur YouTube je réalise que non. Ce n’est pas la 2NF mais bonne nouvelle : on va revaloriser/upgrader notre table jusqu’à la deuxième forme. Pour cela on va décomposer notre table en deux sous-tables séparées.
Dans la première on va garder la clé primaire composée et tous les attributs non-clés qui dépendent de la PK (Primary Key) entière. Dans la deuxième sous-table on va déménager les attribues non-clés qui ne dépendent que de la partie de la PK et on y ajoute la colonne avec la partie de la clé primaire dont l’attribue dépend.
Ainsi, on va avoir la première table avec le titre, le format et le prix et la deuxième table avec le titre (PK) et l’auteur. Ce qui va satisfaire complétement les exigences de la 2NF à savoir « dans chaque table des attribues doivent dépendre de l’ensemble de la clé primaire et pas de sa partie ».
Qui est génial ? Moi, je suis géniale ! Pose café.
De 2NF à la 3NF
On continue de s’emboiter notre poupée russe de la normalisation et on regarde à présente la poupée NF3 contenante déjà 1NF et 2NF. Je lis dans la formation : « La base de donnée respecte la 3NF si entre les attribues il n’y a pas d’autres dépendances fonctionnelles ». Eh ?? Prenons un exemple d’une table en 2NF.
La clé primaire ici est une Région. Mais en même temps on observe la « dépendance transitive » car la colonne « continent » dépend de la colonne « région » qui dépend de la colonne « sous-région » qui est la clé primaire.
Pour normaliser cette table on va « déménager » dans une nouvelle table la colonne « Continent » qui ne dépend pas directement de la clé primaire et on va y ajouter sa propre clé primaire qui sera « région ». Fastoche !
Vous pouvez me demander pourquoi doit-on s’embêter et modifier notre table ? Quelle est le bénéfice de cette opération et en quoi la 3NF va nous servir ? Tout simplement parce que sans la troisième forme normale nous pouvons saisir les données erronées. Par exemple, ajouter à la sous-région « Ile de France » le continent « Afrique ». Avec deux tables séparées cette erreur ne sera plus possible.
Et si vous êtes survécu jusqu’à ici, j’ai un bonus pour vous. Quelques remarques « niveau avancé ». Mais vous pouvez les passer ou garder pour un autre jour.
- C’est vrai que plus le niveau de normalisation est élevé, moins d’erreurs nous pouvons y introduire, mais en même temps, ça peut ralentir la base de données. C’est par exemple vrai pour les systèmes analytiques si vous aurez besoin de créer une visualisation (une requête) car plus le niveau de normalisation est élevé, plus il y aura de tables dans la base. Et si vous aurez besoin de requête transversale qui cherchera l’information depuis plusieurs tables, plus ça va être long car le processus « join » que la base va répéter au plusieurs reprises est le processus le plus couteux en termes d’exécution. En revanche, pour des utilisateurs qui créent des catalogues ou des bases de données des clients ou pour les développeurs des logiciels qui doivent modifier des informations particulières qui apparaissent dans une seule table et pour les autres domaines informatiques, plus le niveau de normalisation sera élevé, plus la base des données sera performante.
- On parle souvent de 3 formes normales mais il n’y a pas de limites : on peut avoir les formes plus élevées. Par exemple pour satisfaire à la 4NF une table ne doit pas contenir des produits cartésiens. Autrement dit, plus les données sont normalisées (i.e. divisées), moins il y a des redondances de données à plus nous pouvons garantir la « cohérence » d’information.
- Dans les systèmes comme DataHub ou MDM ou DQM on utilise les structures fortement normalisées pour justement éviter ou détecter des erreurs évidentes. Par contre la normalisation ne garantit pas l’absence de toutes types d’erreurs. Par exemple, même dans une modèle en 3NF nous pouvons facilement avoir des doublons (des clients, des fournisseurs, des contrats, etc.).
P.S. Hier mon mari a ouvert notre dressing que j’ai considéré comme au moins 3NF et râlait pendant 5 minutes en essayant de trouver LE pull bleu tricoté… Dès aujourd’hui le dressing est disqualifié et passe au niveau 2NF. Heureusement il n’a pas essayé de le « joindre avec » le pantalon noir qui est perdu dans les barrages depuis 2 mois et qui avec ce pauvre pull bleu formaient la clé primaire composée pour la table de « tenue de soirée ».
