Forme normale (bases de données relationnelles)

Un article de Wikipédia, l'encyclopédie libre.
Aller à : navigation, rechercher
Page d'aide sur l'homonymie Pour les articles homonymes, voir Forme normale.

Dans une base de données relationnelle, une forme normale désigne un type de relation particulier entre les entités.

Le but essentiel de la normalisation est d'éviter les anomalies transactionnelles pouvant découler d'une mauvaise modélisation des données et ainsi éviter un certain nombre de problèmes potentiels tels que les anomalies de lecture, les anomalies d'écriture, la redondance des données et la contre-performance.

La normalisation des modèles de données permet de vérifier la robustesse de leur conception pour améliorer la modélisation (et donc obtenir une meilleure représentation) et faciliter la mémorisation des données en évitant la redondance et les problèmes sous-jacents de mise à jour ou de cohérence. La normalisation s’applique à toutes les entités et aux relations porteuses de propriétés.

Les formes normales s'emboitent les unes dans les autres, tant et si bien que le respect d'une forme normale de niveau supérieur implique le respect des formes normales des niveaux inférieurs. Dans le modèle relationnel de type OLTP, il existe huit formes normales, les trois premières étant les plus connues et utilisées :

  1. la première forme normale notée 1FN (1NF en anglais)
  2. la deuxième forme normale notée 2FN (2NF en anglais)
  3. la troisième forme normale notée 3FN (3NF en anglais)
  4. la forme normale de Boyce Codd notée FNBC (BCNF en anglais)
  5. la quatrième forme normale notée 4FN (4NF en anglais)
  6. la cinquième forme normale notée 5FN (5NF en anglais)
  7. la forme normale domaine clef notée FNDC (DKNF en anglais)
  8. la sixième forme normale notée 6FN (6NF en anglais) rarement présentée

La forme normale vient après la simple validité d'un modèle relationnel, c'est-à-dire que les valeurs des différents attributs soient bien en dépendance fonctionnelle avec la clé primaire (complètement déterminés par la clé primaire).

Avantages et inconvénients[modifier | modifier le code]

En pratique, la première et la deuxième forme normale sont nécessaires pour avoir un modèle relationnel juste. Les formes normales supplémentaires ont leurs avantages et leurs inconvénients.

Les avantages sont :

  • de limiter les redondances de données (multiples écritures)
  • donc de limiter l'espace disque nécessaire
  • de limiter les incohérences de données qui pourraient les rendre inutilisables (multiples écritures)
  • d'éviter les processus de mise à jour (réécritures)

Les inconvénients sont :

  • des temps d'accès potentiellement plus longs si les requêtes sont trop complexes (lectures plus lentes), cela dit, avec des index, notamment sur les clefs primaires, on peut généralement obtenir des résultats satisfaisants
  • une plus grande fragilité des données étant donné la non redondance (lecture impossible)
  • la difficulté de réorganiser la structure (dans le cas où l'on ne sait pas à l'avance le lien entre les entités, ce qui est à éviter si possible)

Pour des petites bases de données, se limiter à la troisième forme normale est généralement une des meilleures solutions d'un point de vue architecture de base de données, mais pour des bases de données plus importantes, cela n'est pas toujours le cas. Il s'agit de faire l'équilibre entre deux options :

  • la génération dynamique des données via les jointures entre tables
  • l'utilisation statiques de données correctement mises à jour

En d'autres mots, il ressort de ces avantages et inconvénients qu'un arbitrage devra être effectué sur le niveau de normalisation selon que les tables de la base de données sont plus sollicitées en lecture ou plus en écriture. Si une table (base de donnée) est plus intensivement écrite que lue il sera préférable de normaliser le plus possible. À contrario, si une table (base de donnée) est plus intensivement lue qu'écrite il pourra être judicieux d'être moins strict sur le respect de la normalisation pour permettre d'améliorer les performances d'accès aux données.

On peut comparer une base intensivement lue à la distribution d'une circulaire. Elle sera photocopiée et distribuée, et les gens n'auront pas à aller à la source pour vérifier son contenu. Au contraire, s'il s'agit d'un document en modification constante, on préfèrera que tout le monde se réfère au même morceau de papier et fasse le déplacement pour vérifier son contenu.

Il convient d'être prudent lorsqu'on renonce à la forme normale. Il n'est pas garanti qu'une forme dénormalisée améliore les temps d'accès. En effet, la redondance peut entraîner une explosion des volumes de données qui peuvent écrouler les performances ou saturer les disques durs. Si l'on reprend l'exemple de la circulaire, si elle est modifiée tout le temps, on finit par passer son temps à la photocopieuse et à courir pour prévenir qu'elle a été modifiée.

La normalisation des modèles de données a été popularisée principalement par la méthode Merise. La principale limite de la normalisation est que les données doivent se trouver dans une même base de données (dans un seul schéma).

Les différentes formes normales[modifier | modifier le code]

Les formes normales sont construites selon le principe des dépendances fonctionnelles. On dit qu'un (ensemble d') attribut détermine un autre (ensemble) si : pour deux tuples distincts toute projection des deux tuples sur le premier attribut donnant les mêmes valeurs induit obligatoirement que les valeurs projetées sur les tuples pour le deuxième attribut soient identiques. Soient deux tuples t1 et t2, soient deux ensembles d'attributs X, Y (à intersection vide) si la projection de t1 sur X est égale à la projection de t2 sur X alors la projection de t1 sur Y doit être égale à la projection de t2 sur Y. Dans ce cas X détermine Y ou Y dépend fonctionnellement de X (X → Y)

1FN – Première forme normale[modifier | modifier le code]

Relation dont tous les attributs :

  • toutes les informations sont atomiques
  • contiennent une valeur scalaire (les valeurs ne peuvent pas être divisées en plusieurs sous-valeurs dépendant également individuellement de la clé primaire)
  • contiennent des valeurs non répétitives (le cas contraire consiste à mettre une liste dans un seul attribut).
  • sont constants dans le temps (utiliser par exemple la date de naissance plutôt que l'âge).

Le non-respect des deux premières conditions de la 1FN rend la recherche parmi les données plus lente parce qu'il faut analyser le contenu des attributs. La troisième condition quant à elle évite qu'on doive régulièrement mettre à jour les données.

2FN – Deuxième forme normale[modifier | modifier le code]

Respecte la deuxième forme normale, la relation respectant la première forme normale et respectant le principe suivant :

Les attributs d'une relation sont divisés en deux groupes : le premier groupe est composé de la clé (un ou plusieurs attributs). Le deuxième groupe est composé des autres attributs (éventuellement vide). La deuxième forme normale stipule que tout attribut du deuxième groupe ne peut pas dépendre d'un sous-ensemble (strict) d'attribut(s) du premier groupe. En d'autres termes : « Un attribut non clé ne dépend pas d'une partie de la clé ».

Le non-respect de la 2FN entraîne une redondance des données qui encombrent alors inutilement la mémoire et l'espace disque.

3FN – Troisième forme normale[modifier | modifier le code]

Respecte la troisième forme normale, la relation respectant la seconde forme normale et respectant le principe suivant :

Les attributs d'une relation sont divisés en deux groupes : le premier groupe est composé de la clé (un ou plusieurs attributs). Le deuxième groupe est composé des autres attributs (éventuellement vide). La troisième forme normale stipule que tout attribut du deuxième groupe ne peut pas dépendre que d'un sous-ensemble (strict) d'attribut(s) du deuxième groupe. En d'autres termes : « Un attribut non clé ne dépend pas d'un ou plusieurs attributs ne participant pas à la clé ».

Le respect de la 3FN ne garantit pas une absence de redondance des données d'où la FNBC.

FNBC – Forme normale de Boyce-Codd[modifier | modifier le code]

Respecte la forme normale de Boyce (en)-Codd, la relation respectant la troisième forme normale et dont :

  • tous les attributs non-clé ne sont pas source de dépendance fonctionnelle (DF) vers une partie de la clé

Le non-respect de la 2FN, 3FN et la FNBC entraîne de la redondance. Une même information étant répétée un nombre considérable de fois.

4FN - quatrième forme normale[modifier | modifier le code]

Pour toute relation de dimension n en forme normale de Boyce-Codd, les relations de dimension n-1 construites sur sa collection doivent avoir un sens. Il ne doit pas être possible de reconstituer les occurrences de la relation de dimension n par jointure de deux relations de dimension n-1. Cette normalisation conduit parfois à décomposer une relation complexe en deux relations plus simples.

5FN - cinquième forme normale[modifier | modifier le code]

Pour toute relation de dimension n (avec n supérieur à 2) en quatrième forme normale, il ne doit pas être possible de retrouver l’ensemble de ses occurrences par jointure sur les occurrences des relations partielles prises deux à deux. Cette normalisation conduit parfois à décomposer une relation complexe en plusieurs relations plus simples.

Le non-respect de la 4FN et 5FN entraîne de la perte de données et les informations manquent de précision.

FNDC - forme normale domaine clef[modifier | modifier le code]

Une relation est en FNDC si et seulement si toutes les contraintes sont la conséquence logique des contraintes de domaines et des contraintes de clefs qui s'appliquent à la relation.

Pour se souvenir de l'ordre et des caractéristiques des trois premières formes normales, il suffit de se rappeler le serment que tous les témoins doivent prêter devant la justice : Je jure de dire la vérité, toute la vérité, rien d'autre que la vérité.

Ce qui donne : 1FN = La clé. 2FN = Toute la clé. 3FN = Rien que la clé.

La phrase originale étant : « The key, the whole key, nothing but the key » (Chris Date). Elle est empruntée à l'œuvre de Shakespeare.

Exemple de normalisation[modifier | modifier le code]

Selon les trois principaux types de formes normales :

  • la première forme normale, où chaque attribut des entités contient une valeur atomique (non composée) ;

exemple :

Produit Fournisseur
téléviseur VIDEO SA, HITEK LTD

Dans ce cas les valeurs du fournisseur sont multivaluées et ne sont pas atomiques. Pour que cette relation soit en première forme normale, il faut décomposer les attributs de la colonne fournisseur comme suit :

solution:

Produit Fournisseur
téléviseur VIDEO SA
téléviseur HITEK LTD
  • la deuxième forme normale est une relation en première forme normale où chaque attribut qui n'appartient pas à la clé (l'ensemble des attributs permettant d'identifier de manière unique un tuple de l'entité) ne dépend pas uniquement d'une partie de la clé ;

exemple:

Produit Fournisseur Adresse fournisseur
téléviseur VIDEO SA 13 rue du cherche-midi
écran plat VIDEO SA 13 rue du cherche-midi
téléviseur HITEK LTD 25 Bond Street

Admettons que la clé de cette table soit une clé composite (produit - fournisseur). Dans le cas d'un changement d'adresse d'un fournisseur, il faudra faire preuve de beaucoup d'attention pour n'oublier aucun endroit où l'adresse est mentionnée. En effet, on constate que le champ adresse ne dépend que d'une partie de la clé : le champ fournisseur, ce qui induit la possibilité d'une redondance au sein de la table. Il convient donc de scinder la table en deux:

solution en seconde forme normale :

Produit Fournisseur
téléviseur VIDEO SA
téléviseur HITEK LTD
écran plat VIDEO SA
 
Fournisseur Adresse fournisseur
VIDEO SA 13 rue du cherche-midi
HITEK LTD 25 Bond Street

De cette manière, un changement d'adresse ne donne lieu qu'à une seule modification dans la table des fournisseurs.

  • la troisième forme normale est une relation en deuxième forme normale où les attributs qui ne font pas partie de la clé ne dépendent pas d'attributs ne faisant pas non plus partie de la clé (les attributs sont donc complètement indépendants les uns des autres).

exemple:

Fournisseur Adresse fournisseur Ville Pays
VIDEO SA 13 rue du cherche-midi PARIS FRANCE
HITEK LTD 25 Bond Street LONDON ENGLAND

Le pays de l'adresse n'est pas dépendant de la clé de la table, à savoir le nom du fournisseur, mais est fonction de la ville de l'adresse. De nouveau, il est préférable de scinder la table en deux:

solution normalisée :

Fournisseur Adresse fournisseur Ville
VIDEO SA 13 rue du cherche-midi PARIS
HITEK LTD 25 Bond Street LONDON
 
Ville Pays
PARIS FRANCE
LONDON ENGLAND

De cette manière, une modification de l'orthographe pour un pays (par exemple : ENGLAND en GREAT BRITAIN) ne donnera lieu qu'à une seule modification.

Dans la pratique, l'identification soignée de tous les objets élémentaires de l'application concernée (pays, ville, client, fournisseur, produit, commande, facture, etc) est la première étape avant de leur créer chacun leur table. Chaque table peut alors être soumise au test de respect/non de telle ou telle forme normale. En général, toute valeur de données agrégées et toute répétition d'une valeur de donnée, dans une colonne peuplée, sont potentiellement des violations de forme normale.

Exemples de violation[modifier | modifier le code]

(les * indiquent les attributs appartenant à la clé primaire)

1FN - première forme normale :

  • tout attribut contient une valeur atomique
CLIENT_ID*
Dupont Paris
Durand Marseille

L'attribut CLIENT_ID est composé de 2 attributs atomiques.

CLIENT_ID* NOM
1 Gérard Dupont
2 Léon Durand

L'attribut NOM est composé de 2 attributs atomiques.

  • tous les attributs sont non répétitifs
PRODUIT_ID* DESCRIPTION FOURNISSEURS
1 Téléviseur Sony, Sharp, LG

L'attribut FOURNISSEURS est une liste.

  • tous les attributs sont constants dans le temps.
CLIENT_ID* NOM PRENOM AGE
1 Dupont Gérard 35

L'attribut AGE n'est pas constant dans le temps.

2FN - deuxième forme normale

  • tous les attributs non-clés sont totalement dépendants fonctionnellement de la totalité de la clé primaire.
COMMANDE_ID* ARTICLE_ID* DESCRIPTION_ARTICLE
1 15 TV haute définition avec amplificateur dolby 5.1

L'attribut DESCRIPTION_ARTICLE ne dépend que d'une partie de la clef primaire.

3FN - troisième forme normale

  • tout attribut n'appartenant pas à une clé ne dépend pas d'un attribut non clé
COMMANDE_ID* CLIENT_ID NOM_CLIENT
1 1 Durand

L'attribut NOM_CLIENT dépend de CLIENT_ID.

FNBC - forme normale de Boyce - Codd

  • Si une entité ou une relation en troisième forme normale a une clé composée, aucune des propriétés élémentaires de cette clé ne doit être en dépendance fonctionnelle d’une autre propriété.
ENSEIGNANT_ID* MATIERE_ID* SALLE_ID*
DURAND MATHS 3A
DUPONT ANGLAIS 6A

Si Durand arrête d'enseigner les Mathématiques, on supprime la ligne et l'on perd la relation Matière-Salle.

FNDC - forme normale domaine clef

  • Une relation est en FNDC si et seulement si toutes les contraintes sont la conséquence logique des contraintes de domaines et des contraintes de clefs qui s'appliquent à la relation.

Soit la relation VEHICULE, avec les attributs suivants :

CONSTRUCTEUR* MODELE* TYPE PTAC (KG)
Renault Estafette VL 2500
Iveco Eurostar 440 PL 19000
Berliet GDM 1934 PL 15000
VolksWagen 2 900 combi VL 2 900

On remarque que le type VL (véhicule léger) ou PL (poids lourd) est déterminé par la valeur du PTAC. Ainsi, au-dessus de 3,5 tonnes le véhicule est un PL. En dessous c'est un VL… Il y a redondance de l'information de type qui peut être déduite de la lecture de la valeur du PTAC. En cas de changement de la réglementation (barre des 3,5 tonnes qui pourrait être amenée à changer) alors il faut mettre à jour plusieurs n-uplets ! - Pour résoudre cette anomalie de mise à jour, il faut décomposer la relation en deux comme suit :

1° VEHICULE, avec les attributs suivants :

CONSTRUCTEUR* MODELE* PTAC (KG)
Renault Estafette 2500
Iveco Eurostar 440 19000
Berliet GDM 1934 15000
VolksWagen 2 900 combi 2 900

Le type de véhicule ne figure plus. Il sera déduit de la valeur du PTAC : au-dessus de 3,5 tonnes le véhicule est un PL. En dessous c'est un VL.

2° TYPE VEHICULE, avec les attributs suivants :

TYPE* PTAC (KG)
VL 0
PL 3500

Une inéqui-jointure sera nécessaire à reconstituer la relation originale.

Liens externes[modifier | modifier le code]