2.4  Règles de bonne formation d'un modèle entités-associations

La bonne formation d'un modèle entités-associations permet d'éviter une grande partie des sources d'incohérences et de redondance. Pour être bien formé, un modèle entités-associations doit respecter certaines règles et les type-entités et type-associations doivent être normalisées. Un bon principe de conception peut être formulé ainsi : « une seule place pour chaque fait ».

Bien que l'objectif des principes exposés dans cette section soit d'aider le concepteur à obtenir un diagramme entités-associations bien formé, ces principes ne doivent pas être interprété comme des lois. Qu'il s'agisse des règles de bonne formation ou des règles de normalisation, il peut exister, très occasionnellement, de bonnes raisons pour ne pas les appliquer.

2.4.1  Règles portant sur les noms

---

Figure 2.15: La présence des deux type-entités Enseignant et Etudiant est symptomatique d'une modélisation inachevée. A terme, ces deux type-entités doivent être fusionnés en un unique type-entité Personne. Référez vous à la règle 25 pour plus de précisions concernant cette erreur de modélisation.

---

---

Figure 2.16: Ici, les attributs Adresse de facturation sont redondants. Cette situation doit être évitée à tout prix car elle entraîne un gaspillage d'espace mémoire mais aussi et surtout un grand risque d'incohérence. En effet, que faire si, dans le cadre d'une occurrence du type-association Correspondre, la valeurs des deux attributs Adresse de facturation diffèrent ?

---

---

Figure 2.17: Dans cette situation, les deux attributs Adresse doivent simplement être renommés en Adresse client et Adresse fournisseur. Il en va de même pour les deux attributs Nom.

---

Lorsque des attributs portent le même nom, c'est parfois le signe d'une modélisation inachevée (figure 2.15) ou d'une redondance (figure 2.16). Sinon, il faut simplement ajouter au nom de l'attribut le nom du type-entité ou du type-association dans lequel il se trouve (figure 2.17). Il faut toutefois remarquer que le dernier cas décrit n'est pas rédhibitoire et que les SGDB Relationnel s'accommodent très bien de relations comportant des attributs de même nom. L'écriture des requêtes sera tout de même plus lisible si les attributs ont tous des noms différents.

2.4.2  Règles de normalisation des attributs

---

Figure 2.18: Remplacement des attributs multiples en un type-association et un type-entité et décomposition des attributs composites.

---

En effet, les attributs multiples posent régulièrement des problèmes d'évolutivité du modèle. Par exemple, sur le modèle de gauche de la figure 2.18, comment faire si un employé possède deux adresses secondaires ou plusieurs numéros de portable ?

Il est également intéressant de décomposer les attributs composites comme l'attribut Adresse par exemple. Il est en effet difficile d'écrire une requête portant sur la ville où habitent les employés si cette information est noyée dans un unique attribut Adresse.

---

Figure 2.19: Il faut supprimer l'attribut Montant total du type-entité Commande car on peut le calculer à partir des attributs Quantité du type association Contenir et Prix unitaire du type-entité Article.

---

En effet, les attributs dérivés induisent un risque d'incohérence entre les valeurs des attributs de base et celles des attributs dérivés. La figure 2.19 illustre le cas d'un attribut Montant total dans un type-entité Commande qui peut être calculé à partir des attributs Quantité du type association Contenir et Prix unitaire du type-entité Article. Il faut donc supprimer l'attribut Montant total dans le type-entité Commande. D'autres attributs dérivés sont également à éviter comme l'âge, que l'on peut déduire de la date de naissance et de la date courante. Il faut cependant faire attention aux pièges : par exemple, le code postal ne détermine ni le numéro de département ni la Ville³

Comme nous l'avons déjà dit (cf. règle 12), les attributs d'un type-association doivent dépendre directement des identifiants de tous les type-entités de la collection du type-association.

---

Figure 2.20: Comme la cardinalité maximale du type-association Livrer est 1 du côté du type-entité Livraison, l'attribut Nom livreur de Livrer doit être déplacé dans Livraison.

---

Par exemple, sur la figure 2.19, l'attribut Quantité du type-association Contenir dépend bien à la fois de l'identifiant N° commande et de N° article des type-entités de la collection de Contenir. Inversement, sur cette même figure, l'attribut Prix-unitaire ne dépend que de N° article du type-entité Article, il ne pourait donc pas être un attribut du type-association Contenir. Une conséquence immédiate de cette règle est qu'un type association dont la cardinalité maximale de l'une des pattes est 1 ne peut pas posséder d'attribut. Si elle en possédait, ce serait une erreur de modélisation et il faudrait les déplacer dans le type-entité connecté à la patte portant la cardinalité maximale de 1 (cf. figure 2.20).

Par exemple, sur la figure 2.21, l'attribut Type caractérise le type d'une émission et peut prendre des valeurs comme : actualité, culturelle, reportage, divertissement, etc. Remplacer cet attribut par un type-entité permet, d'une part, d'augmenter la cohérence (en s'affranchissant, par exemple, des variations du genre culturelle, culture, Culture, ) et d'autre part, si les cardinalités le permettent, de pouvoir affecter plusieurs types à une même entité (ex : actualité et culturelle)

---

Figure 2.21: Un attribut correspondant à un type énuméré est généralement avantageusement remplacé par un type-entité..

---

2.4.3  Règles de fusion/suppression d'entités/associations

La spécialisation du type-entité obtenu peut se traduire par l'introduction d'un attribut supplémentaire dont l'ensemble des valeurs possibles est l'ensemble des noms des type-entités factorisés (figure 2.22).

---

Figure 2.22: Il faut factoriser les type-entités quand c'est possible, éventuellement en introduisant un nouvel attribut.

---

Mais l'introduction d'un attribut supplémentaire n'est pas forcément nécessaire ou souhaitable. Par exemple, sur le modèle entités-associations final de la figure 2.23, on peut distinguer les entités qui correspondent à des écrivains ou des abonnés en fonction du type de l'association, Ecrire ou Emprunter, que l'entité en question entretient avec une entité du type Livre. Ne pas introduire d'attribut permet en outre de permettre à une personne d'être à la fois un Abonné et un Écrivain.

---

Figure 2.23: Il faut factoriser les type-entités quand c'est possible, mais l'introduction d'un attribut supplémentaire n'est pas toujours nécessaire. Remarque : ce diagramme est intentionnellement simplifié à outrance.

---

Cette règles est le pendant pour les type-associations de la règle 25 qui concerne les type-entités. La spécialisation du type-association obtenu peut se traduire par l'introduction d'un attribut supplémentaire dont l'ensemble des valeurs possibles est l'ensemble des noms des type-associations factorisés.

---

Figure 2.24: Un seul type-association suffit pour remplacer les quatre type-associations Jouer en tant que

---

La figure 2.24 montre un exemple de multiplication inutile de type-associations.

Par exemple, le type-entité Projection de la figure 2.11 page ?? doit être remplacé par le type-association ternaire Projeter pour aboutir au schéma de la figure 2.10 page ??.

Il faut aussi se poser la question de l'intérêt du type-association quand les cardinalités maximale sont toutes de 1.

---

Figure 2.25: Lorsque les cardinalités d'un type-association sont toutes 1,1 c'est qu'il s'agit d'un type-association fantôme.

---

Lorsque les cardinalités d'un type-association sont toutes 1,1, le type-association doit généralement être supprimé et les type-entités correspondant fusionnés comme l'illustre la figure 2.25. Néanmoins, même si toutes ses cardinalités maximale sont de 1, il est parfois préférable de ne pas supprimer le type-association, comme dans l'exemple de la figure 2.26.

---

Figure 2.26: Même si toutes les cardinalités maximale sont de 1, il vaut mieux conserver le type-association Etre.

---

---

Figure 2.27: Si un client ne peut pas régler la facture d'un autre client, alors le type-association Payer est inutile.

---

---

Figure 2.28: Solution au problème de la redondance du type-association de la figure 2.27.

---

---

Figure 2.29: Dans le modèle de la figure 2.27, si un client peut régler la facture d'un autre client, il faut remplacer le type-entité Règlement par un type-association Régler.

---

Par exemple, dans le modèle représenté sur la figure 2.27, si un client ne peut pas régler la facture d'un autre client, alors le type-association Payer est redondant et doit purement et simplement être supprimé du modèle (cf. figure 2.28). On pourra toujours retrouver le client qui a effectué un règlement en passant par la facture correspondante.

Par contre, si un client peut régler la facture d'un autre client, alors c'est la règle 27 qu'il faut appliquer : on remplace le type-entité Règlement par un type-association Régler (cf. figure 2.29).

2.4.4  Normalisation des type-entités et type-associations

Introduction

Les formes normales sont différent stades de qualité qui permettent d'éviter la redondance, source d'anomalies. La normalisation peut être aussi bien effectuée sur un modèle entités-associations, où elle s'applique sur les type-entités et type-associations, que sur un modèle relationnel.

Il existe 5 formes normales principales et deux extensions. Plus le niveau de normalisation est élevé, plus le modèle est exempte de redondances. Un type-entité ou un type-association en forme normale de niveau n est automatiquement en forme normale de niveau n1. Une modélisation rigoureuse permet généralement d'aboutir directement à des type-entités et type-associations en forme normale de Boyce-Codd.

Nous avons décidé de présenter deux fois cette théorie de la normalisation :

• Une première fois, dans le cadre du modèle entités-associations (la présente section 2.4.4), en privilégiant une approche plus intuitive qui n'introduit pas explicitement la notion de dépendance fonctionnelle (et encore moins les notions de dépendance multivaluée et de jointure). Nous nous arrêterons, dans cette section, à la forme normale de Boyce-Codd.
• Puis une seconde fois, dans le cadre de modèle relationnel (section 3.2), en privilégiant une approche plus formelle s'appuyant sur la définition des dépendances fonctionnelle, multivaluée et de jointure. Nous irons alors jusqu'à la cinquième forme normale.

Première forme normale (1FN)

---

Figure 2.30: Exemple de normalisation en première forme normale.

---

Un attribut composite doit être décomposés en attributs élémentaires (comme l'attribut Adresse sur la figure 2.30) ou faire l'objet d'une entité supplémentaire (comme l'attribut Occupants sur la figure 2.30.

L'élémentarité d'un attribut est toutefois fonction des choix de gestion. Par exemple, la propriété Adresse peut être considérée comme élémentaire si la gestion de ces adresses est globale. Par contre, s'il faut pouvoir considérer les codes postaux, les noms de rues, , il convient d'éclater la propriété Adresse en Adresse (au sens numéro d'appartement, numéro et nom de rue, ), Code postal et Ville. En cas de doute, il est préférable (car plus général) d'éclater une propriété que d'effectuer un regroupement.

Deuxième forme normale (2FN)

---

Figure 2.31: Exemple de normalisation en deuxième forme normale. On suppose qu'un même fournisseur peut fournir plusieurs produits et qu'un même produit peut être fourni par différents fournisseurs.

---

Autrement dit, les attributs doivent dépendre de l'ensemble des attributs participant à la clé. Ainsi, si la clé est réduite à un seul attribut, ou si elle contient tous les attributs, le type-entité ou le type-association est, par définition, forcément en deuxième forme normale.

La figure 2.31 montre un type-entité Article décrivant des produits provenant de différents fournisseurs. On suppose qu'un même fournisseur peut fournir plusieurs produits et qu'un même produit peut être fourni par différents fournisseurs. Dans ce cas, les attributs Produit ou Fournisseur ne peuvent constituer un identifiant du type-entité Article. Par contre, le couple Produit/Fournisseur constitue bien un identifiant du type-entité Article. Cependant, l'attribut Adresse fournisseur ne dépend maintenant que d'une partie de la clé (Fournisseur). Opter pour une nouvelle clé arbitraire réduite à un seul attribut N° article permet d'obtenir un type-entité Article en deuxième forme normale. On va voir dans ce qui suit que cette solution n'a fait que déplacer le problème.

Troisième forme normale (3FN)

---

Figure 2.32: Exemple de normalisation en troisième forme normale. Dans cet exemple, l'attribut Adresse fournisseur dépend de l'attribut Fournisseur.

---

Cette normalisation peut amener à désimbriquer des type-entités cachées comme le montre la figure 2.32.

Un type-entité ou un type-association en deuxième forme normale avec au plus un attribut qui n'appartient pas à la clé est, par définition, forcément en troisième forme normale.

Forme normale de Boyce-Codd (BCNF)

---

Figure 2.33: Exemple de normalisation en forme normale de Boyce-Codd.

---

Intéressons-nous, par exemple (cf. figure 2.33), à un type-entité Diplômé modélisant des personnes (Nom et Prénom) possédant un diplôme (Diplôme) d'une institution (Institution). On suppose qu'il n'y a pas d'homonyme, qu'une même personne ne possède pas deux fois le même diplôme mais qu'elle peut posséder plusieurs diplômes différents. Une institution ne délivre qu'un type de diplôme, mais un même diplôme peut être délivré par plusieurs institutions (par exemple, plusieurs écoles d'ingénieurs délivrent des diplômes d'ingénieur). Une clé possible pour le type-entité Diplômé est donc Nom, Prénom, Diplôme. Le type-entité obtenu est en troisième forme normale, mais une redondance subsiste car l'attribut Institution détermine l'attribut Diplôme. Le type-entité Diplômé n'est donc pas en forme normale de Boyce-Codd.

Un modèle en forme normale de Boyce-Codd est considéré comme étant de qualité suffisante pour une implantation.

Autres formes normales

Il existe d'autres formes normales. La quatrième et la cinquième forme normale sont présentées dans la section 3.2 dans le cadre du modèle relationnel.

3

Le code postal en France identifie le bureau distributeur qui achemine le courrier dans une commune. En conséquence et d'après cette définition, il n'existe pas de relation entre le code postal et le code du département de la commune. Par exemple, la commune La Feuillade, dont le code postal est 19600, est située dans le département de la Dordogne (24). Dans cette non correspondance entre code postal et département, il y a toute la Corse ! Il n'y a pas non plus de correspondance biunivoque entre le code postal et une ville. Une commune peut avoir plusieurs codes postaux, un code postal peut recouvrir plusieurs communes.

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.