• 20 heures
  • Moyenne

Ce cours est visible gratuitement en ligne.

course.header.alt.is_video

course.header.alt.is_certifying

J'ai tout compris !

Mis à jour le 29/10/2019

Optimisez votre modèle relationnel avec les formes normales

Connectez-vous ou inscrivez-vous gratuitement pour bénéficier de toutes les fonctionnalités de ce cours !

Dans les chapitres précédents, je vous ai présenté les principales notions de l'approche orientée objet et la démarche globale pour modéliser une base de données.

Je vais maintenant vous montrer comment optimiser votre modèle relationnel en utilisant les formes normales.

Les formes normales sont en quelque sorte des niveaux de qualité d'un modèle relationnel qui définissent les règles que celui-ci doit respecter. Elles permettent de vérifier la robustesse de la conception du modèle en évitant la redondance des données et les problèmes de mise à jour et de cohérence qui en découlent.

Il y a 6 niveaux de formes normales, et 2 niveaux complémentaires. Nous allons nous concentrer sur les 3 premiers niveaux qui, s'ils sont respectés, apportent déjà une bonne cohérence d'ensemble.

1FN : première forme normale

Pour être en première forme normale (1FN), il faut que chaque attribut soit atomique. En d'autres termes, aucun attribut ne doit être multivalué (liste de valeurs) ou composé (si on le décompose, on obtient des informations supplémentaires).

Voici un exemple de table personne ne respectant pas la 1FN :

id

pseudo

nom

email

1

Ed' la poignée

M. Édouard Bracame

edouard.bracame@joe-bar-team.org, ed@jbt.org

2

Joe l'arsouille

M. Jean Manchzeck

jean.manchzeck@joe-bar-team.org

Dans cette table :

  • si une personne a plusieurs adresses email, alors elles sont notées dans l'attribut email, séparées par des virgules.

  • l'attribut nom contient le nom mais aussi le prénom et la civilité de la personne.

Nous pourrions passer en 1FN en modifiant la table ainsi :

id

pseudo

civilite

prenom

nom

email

email_2

1

Ed' la poignée

M.

Édouard

Bracame

edouard.bracame@joe-bar-team.org

ed@jbt.org

2

Joe l'arsouille

M.

Jean

Manchzeck

jean.manchzeck@joe-bar-team.org

 

Cependant, que fait-on si une personne a 3, 10... 50 adresses email ?

On ne va pas créer 50 colonnes email au cas où ! Et si un jour une personne en a 51 on va être obligé de modifier le schéma de la base de données.

Nous allons donc transformer les attributs multivalués en une table séparée, liée à la table d'origine par une relation de type un à plusieurs

MPD ‒ Création d'une table listant les adresses email des personnes
MPD ‒ Création d'une table listant les adresses email des personnes
Contenu de la table « email »
Contenu de la table « email »

2FN : deuxième forme normale

La deuxième forme normale (2FN) ne concerne que les tables avec une clé primaire composite.

Pour être en deuxième forme normale (2FN), il faut déjà être en 1FN et en plus respecter la règle suivante : aucun attribut ne faisant pas partie de la clé primaire ne doit dépendre que d'une partie de la clé primaire.

Prenez la table resultat donnant une note artistique à des skaters dans leur réalisation de figures :

skater [PK]

figure [PK]

note

Richie

Ollie

8

Richie

Flip

10

Richie

Hard-Flip

9

Nyjah

Flip

7

Nyjah

Hard-Flip

8

Vous ajoutez une information donnant la difficulté de la figure :

skater [PK]

figure [PK]

difficulte

note

Richie

Ollie

2

8

Richie

Flip

5

10

Richie

Hard-Flip

10

9

Nyjah

Flip

5

7

Nyjah

Hard-Flip

10

8

La difficulté d'une figure ne dépend que de la figure et non du skater. L'attribut difficulte ne dépend que d'une partie de la clé primaire (figure) et non de la clé primaire complète (skater, figure) : vous ne respectez donc pas la 2FN.

La solution consiste donc à isoler les attributs concernés dans des tables dédiées. Je vais créer ici une table figure et déplacer la colonne difficulte dans cette nouvelle table :

nom [PK]

difficulte

Ollie

2

Flip

5

Hard-Flip

10

Dans la table resultat, la colonne figure devient clé étrangère :

skater [PK]

figure_nom [PK, FK]

note

Richie

Ollie

8

Richie

Flip

10

Richie

Hard-Flip

9

Nyjah

Flip

7

Nyjah

Hard-Flip

8

MPD ‒ Création d'une nouvelle table « figure »
MPD ‒ Création d'une nouvelle table « figure »

3FN : Troisième forme normale

La troisième forme normale (3FN) ressemble à la deuxième (2FN) mais concerne la dépendance entre attributs non clés.

Pour être en troisième forme normale (3FN), il faut déjà être en 2FN et en plus respecter la règle suivante : aucun attribut ne faisant pas partie de la clé primaire ne doit dépendre d'une partie des autres attributs ne faisant pas non plus partie de la clé primaire.

Regardez la table personne ci-dessous :

id [PK]

civilite

nom

prenom

sexe

1

Madame

Germain

Sophie

F

2

Monsieur

Hilbert

David

M

3

Madame

Noether

Emmy

F

4

Madame

Mirzakhani

Maryam

F

5

Monsieur

Poincaré

Henri

M

6

Monsieur

Villani

Cédric

M

Cette table ne respecte pas la 3FN car l'attribut sexe peut être déduit de l'attribut non clé primaire civilite.

Afin de résoudre ce problème, comme pour la 2FN, il convient de créer une nouvelle table civilite et d'y déplacer l'attribut sexe :

MPD ‒ Création d'une nouvelle table « civilite »
MPD ‒ Création d'une nouvelle table « civilite »

Et voici le nouveau contenu des tables personne et civilite :

civilite [PK]

sexe

Madame

F

Monsieur

M

id [PK]

civilite [FK]

nom

prenom

1

Madame

Germain

Sophie

2

Monsieur

Hilbert

David

3

Madame

Noether

Emmy

4

Madame

Mirzakhani

Maryam

5

Monsieur

Poincaré

Henri

6

Monsieur

Villani

Cédric

Un autre exemple de non respect de la 3FN est illustré par la table ligne_facture ci-dessous :

facture_id [PK]

article_id [PK]

quantite

prix_unitaire

total

1

1

3

10.5

31.5

1

13

10

9.15

91.50

1

42

8

4

32.0

2

3

1

19.99

19.99

Nous avons la colonne total qui peut être calculée avec une opération mathématique simple à partir des colonnes quantite et prix_unitaire (total = quantite x prix_unitaire). Sa valeur ne dépend pas de la clé primaire.

La solution consiste à simplement supprimer la colonne total.

Dénormalisez consciemment !

Le respect absolu de la 3FN n'est pas obligatoire. Pour diverses raisons, il peut être intéressant de « dénormaliser » un modèle relationnel.

MPD Gestion de commande
MPD Gestion de commande

Prenons l'exemple de notre table contenant les factures. Même s'il est possible de recalculer les montants totaux hors taxes et TTC à partir des lignes de commandes de l'expédition associée à une facture, il peut être judicieux d'ajouter les colonnes total_ht et total_ttc dans notre table facture. Cela permettrait de faire des recherches par montant total plus facilement mais aussi de pouvoir purger les tables expeditionligne_commande et commande à intervalles réguliers sans perdre l'information des montants totaux dans les factures.

Exemple de certificat de réussite
Exemple de certificat de réussite