|
|
chez les éditions Ellipses, sous le titre Bases de données - de la modélisation au SQL (cours et exercices) (FNAC, amazon.fr)
3.2 Normalisation
3.2.1 Introduction
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.3.3 et 3.3.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.4.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.4.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).
3.2.2 Dépendance fonctionnelle (DF)
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é.
3.2.3 Première et deuxième forme normale
Première forme normale
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 :
- Personne(num-personne, nom, prénom, rue, ville)
- Prénoms-enfants(num-personne, num-prénom)
- Prénoms(num-prénom, prénom)
Remarques sur la première forme normale
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).
Deuxième forme normale
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.
3.2.4 Troisième forme normale
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.
3.2.5 Forme normale de BOYCE-CODD
Cette forme normale permet de renforcer certaines lacunes de la troisième forme normale. 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.
3.2.6 Pour aller plus loin : quatrième et cinquième forme normale
Dépendance multivaluée (DM)
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 :
- Employé(Nom-Employé)
- Intervention(Type-Intervetion)
- Constructeur(Marque)
- Intervenir(Nom-Employé, Type-Intervetion, Marque)
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.
Quatrième forme normale
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.2 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 :
- Employé(Nom-Employé)
- Intervention(Type-Intervetion)
- Constructeur(Marque)
- Etre-capable-de(Nom-Employé, Type-Intervetion)
- Etre-capable-d'intervenir-sur(Nom-Employé, Marque)
Dépendance de jointure (DJ)
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.3).
Cinquième forme normale (5FN)
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.3) 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 :
- si un fournisseur fournit un certain article (comme f1 fournit a1),
- le fournisseur est attitré à l'organisme (comme f1 est attitré à o1), et
- l'organisme utilise un article (comme o1 utilise a1),
- alors nécessairement, le fournisseur fournit l'article à l'organisme (f1 fournit a1 à o1).
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.4).
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.4: Décomposition de la relation Fournisseur (table 3.3) 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.
3.2.7 Remarques au sujet de la normalisation
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.
chez les éditions Ellipses, sous le titre Bases de données - de la modélisation au SQL (cours et exercices) (FNAC, amazon.fr)
Copyright © 2009 Laurent AUDIBERT. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts. Cette page est déposée.
Copyright © 2000-2012 - www.developpez.com