Les formes normales sont différents stades de qualité qui permettent d’éviter la redondance dans les bases de données relationnelles afin d’éviter ou de limiter : les pertes de données, les incohérences au sein des données, l’effondrement des performances des traitements.
Le processus de normalisation consiste à remplacer une relation donnée par certaines projections afin que la jointure de ces projections permette de retrouver la relation initiale. En d’autres termes, le processus est réversible (i.e. sans perte d’information). Les notions de projection et de jointure seront respectivement définies dans les sections 3.4.3 et 3.4.8.
Il existe une hiérarchie dans les règles de normalisation : une relation en 5 ème forme normale est forcément en 4 ème forme normale, une relation en 4 ème forme normale est forcément en forme normale de Boyce-Codd, etc. Il existe des méthodes systématiques pour normaliser une relation dans chacune des formes normales. Ces algorithmes de décomposition, associés à chacune des formes normales, sortent du cadre de ce cours et ne seront pas abordés.
La normalisation peut être effectuée, et c’est préférable, pendant la phase de conception sur le modèle entités-associations (cf. section 2.5.4). Ce qui a été dit et les exemples qui ont été donnés dans cette section restent transposables au modèle relationnel. Dans le cas où la normalisation est faite en amont, lors de la conception, il n’est pas nécessaire de la recommencer sur le modèle relationnel. On peut tout de même vérifier que les relations obtenues par le passage du modèle entités-associations au modèle relationnel sont toujours en forme normale, mais, sauf erreur, il ne devrait pas y avoir de problème. Il en va tout autrement lorsque l’on ne connaît pas bien, ou maîtrise pas bien, l’origine d’un modèle relationnel. Dans ce cas, vérifier la normalisation des relations, et, le cas échéant, les normaliser, est une phase primordiale. C’est également le cas lorsque le modèle relationnel est le modèle de conception (i.e. on ne passe pas par un modèle entités-associations).
Contrairement à ce que nous avions fait dans la section 2.5.4 dans le cadre du modèle entités-associations, nous abordons ici la normalisation en nous appuyant sur les notions de dépendance fonctionnelle, dépendance multivaluée et dépendance de jointure. Il est important de prendre conscience que la dépendance fonctionnelle, la dépendance multivaluée et la dépendance de jointure sont des notions sémantiques. Elles tirent leurs origines dans les contraintes du monde réel. Comme ces contraintes participent à la sémantique de la situation, elles doivent avoir une manifestation dans la base de données. Les dépendances doivent donc être spécifiées dans la définition de la base de données afin que le SGBD puisse les appliquer. Les concepts de normalisation fournissent en fait un moyen indirect de déclarer ces dépendances. Autrement dit, la normalisation d’une base de données est une manifestation observable des dépendances observées dans le monde réel. La dépendance fonctionnelle permet de définir les premières formes normales jusqu’à la forme normale de Boyce-Codd (1FN, 2FN, 3FN et BCNF). La dépendance multivaluée permet de définir la quatrième forme normale (4FN) et la dépendance de jointure la cinquième forme normale (5FN).
Autrement dit, il existe une dépendance fonctionnelle entre un ensemble d’attributs X et un ensemble d’attributs Y, que l’on note X → Y, si connaissant une occurrence de X on ne peut lui associer qu’une seule occurrence de Y.
Il est essentiel de noter qu’une dépendance fonctionnelle est une assertion sur toutes les valeurs possibles et non sur les valeurs actuelles : elle caractérise une intention et non une extension de la relation.
Autrement dit, une dépendance fonctionnelle est élémentaire si la cible est un attribut unique et si la source ne comporte pas d’attributs superflus. La question sur l’élémentarité d’une dépendance fonctionnelle ne doit donc se poser que lorsque la partie gauche de la dépendance fonctionnelle comporte plusieurs attributs.
En d’autres termes, cela signifie que la dépendance entre X et A ne peut pas être obtenue par transitivité.
Par exemple, le pseudo schéma de relation Personne(num-personne, nom, prénom, rue-et-ville, prénoms-enfants) n’est pas en première forme normale. Il faut le décomposer en :
La première forme normale impose que chaque ligne d’une relation ait une seule valeur pour chaque colonne (i.e. attribut), ce qui est justement la définition d’une table. Donc, une table est nécessairement en première forme normale au sens du modèle relationnel.
Cependant, il faut noter que le modèle relationnel peut être étendu de manière à permettre des colonnes à valeur complexe. On parle alors de modèle relationnel étendu (NF2 pour Non First Normal Form en anglais).
Autrement dit, une relation est en deuxième forme normale si, et seulement si, elle est en première forme normale et si tout attribut n’appartenant pas à la clé ne dépend pas que d’une partie de la clé.
Une relation peut être en deuxième forme normale par rapport à une de ses clés candidates et ne pas l’être par rapport à une autre. Une relation avec une clé primaire réduite à un seul attribut est, par définition, forcément en deuxième forme normale.
Soit, par exemple, le schéma de relation suivant : CommandeLivre(Num-Commande, Num-Client, Titre, Auteur, Quantité, Prix). Cette relation indique qu’un client (identifié par Num-Client) a passé une commande (identifiée par Num-Commande) de livre. Elle est bien en première forme normale. Par contre, les attributs Titre, Auteur, Quantité et Prix ne dépendent que de Num-Commande, et pas de Num-Client. Cette relation n’est donc pas en deuxième forme normale. Une solution simple pour la normaliser est de la remplacer par : CommandeLivre(Num-Commande, Num-Client, Titre, Auteur, Quantité, Prix).
Autrement dit, une relation est en troisième forme normale si, et seulement si, elle est en deuxième forme normale et si tout attribut n’appartenant pas à la clef ne dépend pas d’un attribut non-clé.
Une relation peut être en troisième forme normale par rapport à une de ses clés candidates et ne pas l’être par rapport à une autre. Une relation en deuxième forme normale avec au plus un attribut qui n’appartient pas à la clé primaire est, par définition, forcément en troisième forme normale.
Soit, par exemple, le schéma de relation suivant : CommandeLivre(Num-Commande, Num-Client, Titre, Auteur, Quantité, Prix). Comme nous l’avons vu plus haut, cette relation est bien en deuxième forme normale. Par contre, les attributs Auteur et Prix dépendent de l’attribut Titre. La relation n’est donc pas en troisième forme normale. Pour la normaliser, il faut la décomposer de la manière suivante :
Soit les schémas de relation suivant :
Dans ces relations, on suppose les dépendances fonctionnelles directes suivante :
Dans la section 2.6.2, nous avons dit qu’il est souvent préférable de choisir un identifiant arbitraire de type entier. Cette pratique semble aller à l’encontre de la troisième forme normale. Par exemple, la relation Ville(num-ville, Nom, Code-Postal, Population) n’est pas en troisième forme normale si l’on suppose que les attributs Nom et Population dépendent toujours de l’attribut Code-Postal. Cependant, comme nous l’avons dit dans l’introduction, une dépendance fonctionnelle est la manifestation d’une notion sémantique, pas d’une notion formelle ou absolue. Dans le cas du code postal, nous avons déjà expliqué (cf. note page ??) qu’il n’existe pas de relation systématique entre le code postal et le code du département ou la commune. Ainsi, il n’y a pas de dépendance fonctionnelle entre les attributs Nom et Population et l’attribut Code-Postal. La relation Ville(num-ville, Nom, Code-Postal, Population) est donc bien en troisième forme normale (en France, plusieurs villes portent le même nom). La notion de dépendance fonctionnelle est donc une question d’interprétation faisant appel à la connaissance du système modélisé et au bon sens.
Il en va de même avec le schéma de relation Livre(Num-Livre, Titre, Auteur, Prix). Nous avons ici introduit un identifiant numérique arbitraire Num-Livre car l’identifiant naturel Titre, qui est une chaîne de caractères complexe, de taille non bornée et au format libre, ne constitue pas un bon identifiant dans la pratique. Pour justifier la troisième forme normale de cette relation, on peut imaginer que plusieurs livres peuvent porter le même titre.
Il faut enfin noter que la normalisation n’est pas une fin en soit et qu’elle ne doit pas nécessairement être systématiquement appliquée (nous y reviendrons section 3.2.7).
Cette forme normale permet de renforcer certaines lacunes de la troisième forme normale.
Soit, par exemple, le schéma relationnel décrivant l’enseignement d’une matière donnée à une classe par un enseignant :
Supposons, de plus, qu’une matière n’est enseignée qu’une seule fois dans une classe et que par un seul enseignant, et qu’un enseignant n’enseigne qu’une seule matière. Chacune des relations respecte bien la troisième forme normale. Cependant, dans la relation Enseignement, nous avons les dépendances fonctionnelles élémentaires suivantes :
Il existe donc des dépendances fonctionnelles élémentaires dont la source n’est pas la clé de la relation.
nom-enseignant num-classe nom-matière George 5 Physique George 6 Physique George 7 Physique George 8 Physique Michael 5 Mathématiques Michael 6 Mathématiques Michael 7 Mathématiques Michael 8 Mathématiques
Le non respect de la forme normale de BOYCE-CODD entraîne une redondance illustrée par la table 3.2 : pour chaque nom-enseignant identifiant un enseignant, il faut répéter le nom-matière identifiant la matière qu’il enseigne.
Pour normaliser la relation Enseignement, il faut la décomposer pour aboutir au schéma relationnel suivant :
Dans la pratique, la plupart des problèmes de conception peuvent être résolus en appliquant les concepts de troisième forme normale et de forme normale de BOYCE-CODD. Les quatrième et cinquième formes normales traitent encore d’autres cas de redondance, mais qui ne sont pas expliqués par des dépendances fonctionnelles.
Remarque : X ↠ Y ⇒ X ↠ Ai−(X ∪ Y).
Comme illustration, supposons une situation où un employé d’un garage est qualifié pour effectuer un certain type d’intervention sur certaines marques de voiture. Cette situation est modélisée par le schéma relationnel suivant :
Supposons maintenant qu’un employé qui effectue un ensemble de types d’interventions pour un ensemble de marques de voiture, est capable d’effectuer chacun de ces types d’interventions sur chacune de ces marques de voitures. Dans ce cas, il existe des dépendances multivaluées dans la relation Intervenir : Nom-Employé ↠ Type-Intervetion et Nom-Employé ↠ Marque.
Nom-Employé Type-Intervetion Marque Tussier Dépannage Peugeot Tussier Dépannage Citroën Martin Électricité Citroën Martin Électricité Renault Martin Mécanique Citroën Martin Mécanique Renault Piquard Carrosserie Fiat Piquard Carrosserie Ford Piquard Alarme Fiat Piquard Alarme Ford Piquard Électricité Fiat Piquard Électricité Ford
Dans la section précédente, nous avons présenté un schéma relationnel qui n’était pas en quatrième forme normale en raison du schéma de relation Intervenir. La table 3.3 propose un exemple de relation correspondant à ce schéma de relation. Cette table permet d’observer le phénomène de redondance consécutif au fait que cette table n’est pas en quatrième forme normale. Dans cette table, le nombre de lignes commençant par un nom d’employé donné doit être égale au nombre d’interventions que cet employé peut faire multiplié par le nombre de marques sur lesquelles il peut travailler. Imaginons que l’employé Piquard puisse maintenant travailler sur des voitures de la marque Citroën (on désire ajouter une information dans la base), il faudra alors ajouter trois lignes à la table : une pour chaque type d’intervention (Carrosserie, Alarme et Électricité).
Pour normaliser la relation Intervenir, il faut la décomposer pour aboutir au schéma relationnel suivant :
Jusqu’ici, nous avons pu résoudre une redondance dans une relation en la remplaçant par deux de ses projections. Il existe cependant des relations qui ne peuvent pas être décomposées sans perte d’information en deux projections, mais qui peuvent l’être en trois ou plus (ces cas sont assez rares en pratique). C’est ce que permet la normalisation en cinquième forme normale.
Les dépendances de jointures font appel à des notions (projection et jointure) qui seront définies plus loin (cf. section 3.4).
En d’autres termes, les seules décompositions qui préservent le contenu sont celles où chacune des tables de la décomposition contient une clé candidate de la table. Il est donc superflu de décomposer de ce point de vue.
Cette forme normale est finale vis-à-vis de la projection et de la jointure : elle garantie qu’une relation en cinquième forme normale ne contient aucune anomalie pouvant être supprimée en effectuant des projections (i.e. des décompositions).
Relation Fournisseur Num-Fournisseur Num-Article Num-Organisme f1 a2 o1 f1 a1 o2 f2 a1 o1 f1 a1 o1
Prenons, comme illustration2, la relation Fournisseur (table 3.4) qui décrit les fournisseurs des organismes de la fonction publique.
La fonction publique a des règles très particulières concernant les fournisseurs pour réduire le potentiel de conflit d’intérêt. Un fournisseur fournit un certain nombre d’articles (par exemple f1 fournit a1 et a2). Le même article peut être fourni par plusieurs fournisseurs (par exemple a1 est fourni par f1 et f2). Un fournisseur peut être attitré à plusieurs organismes (par exemple f1 est attitré à o1 et o2). Un organisme peut avoir plusieurs fournisseurs (par exemple o1 est servi par f1 et f2). Un organisme peut utiliser plusieurs articles (c’est-à-dire que o1 utilise a1 et a2) et un article peut être utilisé par plusieurs organismes (c’est-à-dire que a1 est utilisé par o1 et o2). La règle de la fonction publique est la suivante :
Le dernier fait est déductible des trois autres.
Cette table contient de la redondance de données parce que certains faits sont répétés. Par exemple, le fait que f1 fournit a1 est répété à deux reprises, une fois parce qu’il fournit a1 à o1 et une autre fois parce qu’il fournit a1 à o2. Le fait que f1 est attitré à o1 est aussi répété à deux reprises. Il en est de même pour o1 qui utilise a1.
La relation Fournisseur souffre d’une dépendance de jointure :
*{(Num-Fournisseur, Num-Article), (Num-Fournisseur, Num-Organisme), (Num-Article, Num-Organisme)}.
Pour résoudre le problème de redondance, il faut décomposer la relation en trois (cf. table 3.5).
Relation FournisseurArticle Relation FournisseurOrganisme Relation ArticleOrganisme Num-Fournisseur Num-Article Num-Fournisseur Num-Organisme Num-Article Num-Organisme f1 a2 f1 o1 a2 o1 f1 a1 f1 o2 a1 o2 f2 a1 f2 o1 a1 o1
Tableau 3.5: Décomposition de la relation Fournisseur (table 3.4) pour obtenir des relations en cinquième forme normale.
Il est important de se convaincre qu’aucune décomposition binaire de cette relation ne préserve le contenu de la relation initiale. Pour cela, il suffit de tenter de joindre deux tables parmi les trois précédentes. Aucune de ces jointures, ne produit la relation Fournisseur.
Il existe d’autres formes normales comme la forme normale domaine-clé (FNDC), la forme normale de restriction-union ou la sixième forme normale (6NF).
Bien que l’objectif de la normalisation soit d’amener le concepteur à obtenir des relations en forme normale finale (i.e. en cinquième forme normale), cet objectif ne doit pas être interprété comme une loi. Il peut exister, très occasionnellement, de bonnes raisons pour passer outre les principes de la normalisation. De plus, un schéma en cinquième forme normale n’est pas nécessairement un schéma pleinement satisfaisant. D’autres facteurs sont à considérer dans le processus de conception d’une base de données et l’expérience et l’intuition jouent un rôle important.