Forme normale (bases de données relationnelles)
Un article de Wikipédia, l'encyclopédie libre.
Dans une base de données relationnelle, une forme normale désigne un type de relation particulier entre les entités.
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 (et donc éviter 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.
En fait, la normalisation permet :
- de limiter les redondances de données
- de limiter les pertes de données
- de limiter les incohérences de données
- d'améliorer les temps de réponse.
Le non respect des formes normales entraînes des anomalies de lecture et de mise à jour. Des lectures redondante si une même information a été distribuée dans différentes entités. Des mises à jour multiples (concernant plusieurs lignes) alors qu'une seule ligne aurait dû être modifiée. Des pertes de données si le modèle ne permet pas de présenter les différentes combinaisons de valeurs. Tous ces problèmes grèvent les performances le la base : lectures multiples au lieu d'une seule, mises à jours multiples au lieu d'une seule.
La normalisation des modèles de données a été popularisée principalement par la méthode Merise.
[modifier] Les différentes formes normales
1FN - première forme normale :
Respecte la première forme normale, la relation dont :
- tout les attributs contiennent une valeur atomique
- tous les attributs sont non répétitifs
- tous les attributs sont constants dans le temps.
Le non respect de la 1FN entraîne de la redondance. Cette redondance encombre la mémoire de travail du SGBDR inutilement et rend l'accès aux données plus lent.
2FN - deuxième forme normale
Respecte la seconde forme normale, la relation respectant la première forme normale et dont :
- tous les attributs non-clés ne dépendent pas d'une partie de la clé primaire.
3FN - troisième forme normale
Respecte la troisième forme normale, la relation respectant la seconde forme normale et dont :
- tous les attributs n'appartenant pas à la clé ne dépendent pas d'un attribut non-clé
BCFN - forme normale de Boyce - Codd
Respecte la forme normale de Boyce-Codd, la relation respectant la troisième forme normale et dont :
- tous les attributs non-clé ne sont pas source de 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
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
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 5FN et 6FN entraîne de la perte de données et les informations manquent de précision.
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.
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). Elles est empruntée à l'œuvre de Shakespeare.
[modifier] Exemple de normalisation
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 :
|
|
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 :
|
|
De cette manière, une modification de l'orthographe pour un pays (par exemple : Grande-Bretagne 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.
[modifier] Exemples de violation
(les * indiquent les attributs appartenant à la clef primaire)
1FN - première forme normale :
- tout attribut contient une valeur atomique
|
L'attribut CLIENT_ID est composé de 2 attributs atomiques. |
|
L'attribut NOM est composé de 2 attributs atomiques. |
- tous les attributs sont non répétitifs
|
L'attribut FOURNISSEURS est une liste. |
- tous les attributs sont constants dans le temps.
|
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.
|
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é
|
L'attribut NOM_CLIENT dépend de CLIENT_ID. |
BCFN - 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é.
|
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 :
|
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 :
|
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 :
|
Une inéqui-jointure sera nécessaire à reconstituer la relation originale. |
