Chapitre 2 Base de Données
Chapitre 2 Base de Données
Chapitre 2 Base de Données
2-1. Introduction
2-1-1. Pourquoi une modélisation préalable ?
Il est difficile de modéliser un domaine sous une forme directement utilisable par un SGBD. Une ou
plusieurs modélisations intermédiaires sont donc utiles, le modèle entités-associations constitue l'une des
premières et des plus courantes. Ce modèle, présenté par [7], permet une description naturelle du monde
réel à partir des concepts d'entité et d’association (3). Basé sur la théorie des ensembles et des relations, ce
modèle se veut universel et répond à l'objectif d'indépendance données-programmes. Ce modèle, utilisé
pour la phase de conception, s'inscrit notamment dans le cadre d'une méthode plus générale et très répandue
: Merise.
2-1-2. Merise
MERISE (Méthode d'Étude et de Réalisation Informatique pour les Systèmes d'Entreprise) est
certainement le langage de spécification le plus répandu dans la communauté de l'informatique des
systèmes d'information, et plus particulièrement dans le domaine des bases de données. Une représentation
Merise permet de valider des choix par rapport aux objectifs, de quantifier les solutions retenues, de mettre
en œuvre des techniques d'optimisation et enfin de guider jusqu'à l'implémentation. Reconnu comme
standard, Merise devient un outil de communication. En effet, Merise réussit le compromis difficile entre le
souci d'une modélisation précise et formelle, et la capacité d'offrir un outil et un moyen de communication
accessible aux non-informaticiens.
Un des concepts clés de la méthode Merise est la séparation des données et des traitements. Cette méthode
est donc parfaitement adaptée à la modélisation des problèmes abordés d'un point de vue fonctionnel (4).
Les données représentent la statique du système d'information et les traitements sa dynamique. L'expression
conceptuelle des données conduit à une modélisation des données en entités et en associations. Dans ce
cours, nous écartons volontairement la modélisation des traitements puisque nous ne nous intéressons à la
méthode Merise que dans la perspective de la modélisation de bases de données.
Merise propose une démarche, dite par niveaux, dans laquelle il s'agit de hiérarchiser les préoccupations de
modélisation qui sont de trois ordres : la conception, l'organisation et la technique. En effet, pour aborder la
modélisation d'un système, il convient de l'analyser en premier lieu de façon globale et de se concentrer sur
sa fonction : c'est-à-dire de s'interroger sur ce qu'il fait avant de définir comment il le fait. Ces niveaux de
modélisation sont organisés dans une double approche données/traitements. Les trois niveaux de
représentation des données, puisque ce sont eux qui nous intéressent, sont détaillés ci-dessous.
Niveau conceptuel :
Le modèle conceptuel des données (MCD) décrit les entités du monde réel, en termes d'objets, de
propriétés et de relations, indépendamment de toute technique d'organisation et d'implantation des
données. Ce modèle se concrétise par un schéma entités-associations représentant la structure du
système d'information, du point de vue des données.
Niveau logique :
Le modèle logique des données (MLD) précise le modèle conceptuel par des choix organisationnels. Il
s'agit d'une transcription (également appelée dérivation) du MCD dans un formalisme adapté à une
implémentation ultérieure, au niveau physique, sous forme de base de données relationnelle ou réseau,
ou autres (cf. section). Les choix techniques d'implémentation (choix d'un SGBD) ne seront effectués
qu'au niveau suivant.
Niveau physique :
Le modèle physique des données (MPD) permet d'établir la manière concrète dont le système sera mis
en place (SGBD retenu).
Définition 1
Entité- Une entité est un objet, une chose concrète ou abstraite qui peut être reconnue distinctement et qui
est caractérisée par son unicité.
Exemples d'entité : Jean Dupont, Pierre Bertrand, le livre que je tiens entre les mains, la Ferrari qui se
trouve dans mon garage, etc.
NB : Les entités ne sont généralement pas représentées graphiquement.
Définition 2
Type entité- Un type entité désigne un ensemble d'entités qui possèdent une sémantique et des propriétés
communes.
Les personnes, les livres et les voitures sont des exemples de type entité. En effet, dans le cas d'une
personne par exemple, les informations associées (i.e. les propriétés), comme le nom et le prénom, ne
changent pas de nature.
Une entité est souvent nommée occurrence ou instance de son type entité.
La figure 2.1 montre la représentation graphique d'un exemple de type entité (Personne) sans ses propriétés
associées.
Les types entité Personne, caractérisée par un nom et un prénom, et Voiture, caractérisée par un nom et une
puissance fiscale, ne peuvent pas être regroupées, car ils ne partagent pas leurs propriétés (le prénom est une
chaîne de caractères et la puissance fiscale un nombre). Les types entité Personne, caractérisés par un nom
et un prénom, et Livre, caractérisé un titre et un auteur, possèdent tous les deux attributs du type chaîne de
caractères. Pourtant, ces deux type entité ne peuvent pas être regroupés, car ils ne partagent pas une même
sémantique : le nom d'une personne n'a rien à voir avec le titre d'un livre, le prénom d'une personne n'a rien
à voir avec un auteur.
Par abus de langage, on utilise souvent le mot entité en lieu et place du mot type entité, il faut cependant
prendre garde à ne pas confondre les deux concepts.
2-2-2. Attribut ou propriété, valeur
Définition 4
Valeur- Au niveau du type entité ou du type association, chaque attribut possède un domaine qui définit
l'ensemble des valeurs possibles qui peuvent être choisies pour lui (entier, chaîne de caractères, booléen…).
Au niveau de l'entité, chaque attribut possède une valeur compatible avec son domaine.
La figure 2.2 montre la représentation graphique d'un exemple de type entité (Personne) avec trois attributs.
Règle 5 Un attribut ne peut en aucun cas être partagé par plusieurs type entité ou type association.
Règle 6 Un attribut est une donnée élémentaire, ce qui exclut des données calculées ou dérivées.
Règle 7 Un type entité et ses attributs doivent être cohérents entre eux (i.e. ne traiter que d'un seul sujet).
Par exemple, si le modèle doit comporter des informations relatives à des articles et à leur fournisseur, ces
informations ne doivent pas coexister au sein d'un même type entité. Il est préférable de mettre les
informations relatives aux articles dans un type entité Article et les informations relatives aux fournisseurs
dans un type entité Fournisseur. Ces deux type entité seront probablement ensuite reliés par un type
association.
Définition 8
Identifiant, clé- Un identifiant (ou clé) d'un type entité ou d'un type association est constitué par un ou
plusieurs de ses attributs qui doivent avoir une valeur unique pour chaque entité ou association de ce type.
Il est donc impossible que les attributs constituant l'identifiant d'un type entité (respectivement type
association) prennent la même valeur pour deux entités (respectivement deux associations) distinctes.
Exemples d'identifiant : le numéro de sécurité sociale pour une personne, le numéro d'immatriculation pour
une voiture, le code ISBN d'un livre pour un livre (mais pas pour un exemplaire).
Règle 9 Chaque type entité possède au moins un identifiant, éventuellement formé de plusieurs attributs.
Ainsi, chaque type entité possède au moins un attribut qui, s'il est seul, est donc forcément l'identifiant.
Dans la représentation graphique, les attributs qui constituent l'identifiant sont soulignés et placés en tête
(cf. figure 2.3).
Définition 10 -association- Une association (ou une relation) est un lien entre plusieurs entités.
Exemples d'association : l'emprunt par l'étudiant Tanidute du 3e exemplaire du livre « Maîtrisez SQL ».
Les associations ne sont généralement pas représentées graphiquement.
Définition 11 -type association- Un type association (ou un type relation) désigne un ensemble de relations
qui possèdent les mêmes caractéristiques. Le type association décrit un lien entre plusieurs type entité. Les
associations de ce type association lient des entités de ces type entité.
Comme les types entité, les types association sont définis à l'aide d'attributs qui prennent leur valeur dans
les associations.
Règle 12 Un attribut peut être placé dans un type association uniquement lorsqu'il dépend de toutes les
entités liées par le type association.
Un type association peut ne pas posséder d'attribut explicite et cela est relativement fréquent, mais on verra
qu'il possède au moins des attributs implicites.
Exemples de type association : l'emprunt d'un livre à la bibliothèque.
Une association est souvent nommée occurrence ou instance de son type association.
La figure 2.4 montre la représentation graphique d'un exemple de type association.
Par abus de langage, on utilise souvent le mot association en lieu et place du mot type association, il faut
cependant prendre garde à ne pas confondre les deux concepts.
Définition 13
Participant : les types entité intervenant dans un type association sont appelés les participants de ce type
association.
Définition 14 -collection- L'ensemble des participants d'un type association est appelé la collection de ce
type association.
Cette collection comporte au moins un type entité (cf. section), mais elle peut en contenir plus, on parle
alors de type association n-aire (quand n=2 on parle de type association binaire, quand n=3 de type
association ternaire…).
Définition 15
Dimension ou arité d'un type association- La dimension, ou l'arité d'un type association est le nombre de
type entité contenu dans la collection.
Comme un type entité, un type association possède forcément un identifiant, qu'il soit explicite ou non.
Règle 16 La concaténation des identifiants des types entité liés à un type association constitue un identifiant
de ce type association et cet identifiant n'est pas mentionné sur le modèle (il est implicite).
Cette règle implique que deux instances d'un même type association ne peuvent lier un même ensemble
d'entités.
Souvent, un sous-ensemble de la concaténation des identifiants des types entité liés suffit à identifier le type
association.
On admet également un identifiant plus naturel et explicite, à condition qu'il ne soit qu'un moyen d'exprimer
plus simplement cette concaténation.
2-2-5. Cardinalité
Définition 17
Cardinalité : La cardinalité d'une patte reliant un type association et un type entité précise le nombre de
fois minimal et maximal d'interventions d'une entité du type entité dans une association du type association.
La cardinalité minimale doit être inférieure ou égale à la cardinalité maximale.
Exemple de cardinalité : une personne peut être l'auteur de 0 à n livre, mais un livre ne peut être écrit que
par une personne (cf. figure 2.5).
Règle 18 L'expression de la cardinalité est obligatoire pour chaque patte d'un type association.
Une cardinalité minimale est toujours 0 ou 1 et une cardinalité maximale est toujours 1 ou n.
Ainsi, si une cardinalité maximale est connue et vaut 2, 3 ou plus, alors nous considérons qu'elle est
indéterminée et vaut n. En effet, si nous connaissons n au moment de la conception, il se peut que cette
valeur évolue au cours du temps. Il vaut donc mieux considérer n comme inconnue dès le départ. De la
même manière, on ne modélise pas des cardinalités minimales qui valent plus de 1, car ces valeurs sont
également susceptibles d'évoluer. Enfin, une cardinalité maximale de 0 n'a pas de sens, car elle rendrait le
type association inutile.
Les seules cardinalités admises sont donc :
0,1 : une occurrence du type entité peut exister tout en n'étant impliquée dans aucune association et peut être
impliquée dans au maximum une association.
0,n : c'est la cardinalité la plus ouverte ; une occurrence du type entité peut exister tout en n'étant impliquée
dans aucune association et peut être impliquée, sans limitation, dans plusieurs associations.
1,1 : une occurrence du type entité ne peut exister que si elle est impliquée dans exactement (au moins et au
plus) une association.
1,n : une occurrence du type entité ne peut exister que si elle est impliquée dans au moins une association.
Une cardinalité minimale de 1 doit se justifier par le fait que les entités du type entité en question ont besoin
de l'association pour exister. Dans tous les autres cas, la cardinalité minimale vaut 0. Ceci dit, la discussion
autour d'une cardinalité minimale de 0 ou de 1 n'est intéressante que lorsque la cardinalité maximale est 1.
En effet, nous verrons que, lors de la traduction vers un schéma relationnel (cf. section), lorsque la
cardinalité maximale est n, nous ne ferons pas la différence entre une cardinalité minimale de 0 ou de 1.
La seule difficulté pour établir correctement les cardinalités est de se poser les questions dans le bon sens.
Pour augmenter le risque d'erreurs, il faut noter que, pour les habitués, ou les futurs habitués, du modèle
UML, les cardinalités d'un type association sont « à l'envers » (par référence à UML) pour les types
association binaires et « à l'endroit » pour les n-aires avec n>2.
La notion de cardinalité n'est pas définie de la même manière dans le modèle américain et dans le modèle
européen (Merise). Dans le premier n'existe que la notion de cardinalité maximale.
Avec un SGBD relationnel, nous pourrons contraindre des cardinalités à des valeurs comme 2, 3 ou plus en
utilisant des déclencheurs (trigger).
Sur ce schéma, un type association permet de modéliser que des personnes écrivent des livres et un autre
que des personnes critiquent (au sens de critique littéraire) des livres.
Deux mêmes entités peuvent être plusieurs fois en association (c'est le cas sur la figure 2)
Définition 20
Type association réflexif- Un type association est qualifié de réflexif quand il matérialise une relation entre
un type entité et lui-même (cf. figure 2.7).
Une occurrence de ce type association (i.e. une association) associe généralement une occurrence du type
association (i.e. une entité) à une autre entité du même type. Cette relation peut être symétrique, c'est le cas
du type association Être frère sur la figure 2.7, ou ne pas l'être, comme le type association Être parent sur
cette même figure. Dans le cas où la relation n'est pas symétrique, on peut préciser les rôles sur les pattes du
type association comme pour la relation Être parent de la figure 2.7. L'ambiguïté posée par la non-symétrie
d'un type association réflexif sera levée lors du passage au modèle relationnel (cf. section).
Le type association ternaire Contient associant les types entité Facture, Produit et Client représenté sur la
figure 2.8 est inapproprié puisqu'une facture donnée est toujours adressée au même client. En effet, cette
modélisation implique pour les associations (instances du type association) Contient une répétition du
numéro de client pour chaque produit d'une même facture.
La solution consiste à éclater le type association ternaire Contient en deux type association binaires comme
représenté sur la figure 2.9.
La figure 2.10 nous montre un exemple de type association ternaire entre les types entité Créneau horaire,
Salle et Film. Il est toujours possible de s'affranchir d'un type association n-aire (n>2) en se ramenant à des
types association binaires de la manière suivante :
• On remplace le type association n-aire par un type entité et on lui attribue un identifiant.
• On crée des types association binaire entre le nouveau type entité et tous les types entité de la
collection de l'ancien type association n-aire.
• La cardinalité de chacun des types association binaires créés est 1,1 du côté du type entité créé
(celui qui remplace le type association n-aire), et 0,n ou 1,n du côté des types entité de la
collection de l'ancien type association n-aire entité Créneau horaire, Salle et Film.
Figure 2.11 :
Transformation du type
association ternaire de la
figure 2.10 en un type
entité et trois type
association binaires.
La figure 2.11 illustre le résultat de cette transformation sur le schéma de la figure 2.10.
L'avantage du schéma de la figure 2.11 est de rendre plus intelligible la lecture des cardinalités. Il ne faut
surtout pas le voir comme un aboutissement, mais comme une étape intermédiaire avant d'aboutir au
schéma de la figure 2.10 (cf. règle 27). Ainsi, le mécanisme, que nous venons de détailler ci-dessus, de
passage d'un type association n-aire (n>2) à un type entité et n type association binaires est tout à fait
réversible à condition que :
• Toutes les pattes des types association binaires autour du type entité central ont une cardinalité
maximale de 1 au centre et de n à l'extérieur ;
• Les attributs du type entité central satisfont la règle de bonne formation des attributs de type
association (cf. section).
2-3-3-c. Détection d'une erreur de modélisation par décomposition d'une association n-aire
Figure 2.13 :
Transformation du type
association ternaire de la
figure 2.12 en un type
entité et trois type Figure
2.14 : Modèle de la
figure 2.13 corrigé au
niveau des
cardinalités.
association binaires.
Passer par cette étape intermédiaire ne comportant pas de type association n-aire (n>2) peut, dans certains
cas, éviter d'introduire un type association n-aire inapproprié. Imaginons par exemple un type association
ternaire Vol liant trois type entité Avion, Trajet et Pilote comme représenté sur la figure 2.12.
La transformation consistant à supprimer le type association ternaire du modèle de la figure 2.12 produit le
modèle de la figure 2.13. Ce modèle fait immédiatement apparaître une erreur de conception qui était
jusque-là difficile à diagnostiquer : généralement, à un vol donné sont affectés plusieurs pilotes (par
exemple le commandant de bord et un copilote) et non pas un seul.
Le modèle correct modélisant cette situation est celui de la figure 2.14 où le type entité Vol ne peut être
transformé en un type association ternaire Vol comme sur la figure 2.12.
Figure 2.15 : La présence des deux type entité Enseignant et Étudiant est symptomatique d'une modélisation
inachevée. À terme, ces deux type entité 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, les 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.
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.
Règle 23 Il ne faut jamais ajouter un attribut dérivé d'autres attributs, que ces autres attributs se trouvent
dans le même type entité ou pas
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.
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 types entité 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 pourrait
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).
Un attribut correspondant à un type énuméré est généralement avantageusement remplacé par un type
entité.
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
Règle 25 Il faut factoriser les types entité quand c'est possible.
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 types entité factorisés (figure 2.22).
Figure 2.22 : Il faut factoriser les types entité 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, Écrire 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 types entité 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.
Il faut factoriser les types association quand c'est possible.
Cette règle est le pendant pour les types association de la règle 25 qui concerne les types entité. 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 types association factorisés.
Figure 2.24 : Un seul type association suffit pour remplacer les quatre type association Jouer en tant que
La figure 2.24 montre un exemple de multiplication inutile de type association.
Règle 27 Un type entité remplaçable par un type association doit être remplacé.
Par exemple, le type entité Projection de la figure 2.11 doit être remplacé par le type association ternaire
Projeter pour aboutir au schéma de la figure 2.10.
Règle 28 Lorsque les cardinalités d'un type association sont toutes 1,1 c'est que le type association n'a pas
lieu d'être.
Il faut aussi se poser la question de l'intérêt du type association quand les cardinalités maximales 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 types entité correspondants fusionnés comme l'illustre la figure 2.25. Néanmoins, même si
toutes ses cardinalités maximales 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 maximales sont de 1, il vaut mieux conserver le type
association Être.
Il faut veiller à éviter les types association redondants. En effet, s'il existe deux chemins pour se rendre d'un
type entité à un autre, alors ces deux chemins doivent avoir deux significations ou deux durées de vie
distinctes. Dans le cas contraire, il faut supprimer le chemin le plus court puisqu'il est déductible des autres
chemins.
Figure 2.27 : Si un client ne peut pas régler la facture d'un autre client, alors le type association Payer est
inutile.
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 types entité et type association
2-4-4-a. Introduction
Les formes normales sont différents 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 types entité et type association, 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 exempt de redondances. Un type entité ou un type association en forme normale de niveau n est
automatiquement en forme normale de niveau n−1. Une modélisation rigoureuse permet généralement
d'aboutir directement à des types entité et types association en forme normale de Boyce-Codd.
Définition 30
Première forme normale (1FN) - Un type entité ou un type association est en première forme normale si
tous ses attributs sont élémentaires, c'est-à-dire non décomposables.
Un attribut composite doit être décomposé 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.
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.
Définition 31
Deuxième forme normale (2FN) - Un type entité ou un type association est en deuxième forme normale si,
et seulement si, il est en première forme normale et si tout attribut n'appartenant pas à la clé dépend de la
totalité de cette clé.
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.
Figure 2.32 : Exemple de normalisation en troisième forme normale. Dans cet exemple, l'attribut Adresse
fournisseur dépend de l'attribut Fournisseur.
Définition 32
Troisième forme normale (3FN) - Un type entité ou un type association est en troisième forme normale si,
et seulement si, il est en deuxième forme normale et si tous ses attributs dépendent directement de sa clé et
pas d'autres attributs.
Cette normalisation peut amener à désimbriquer des types entité cachés 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.
2-4-4-e. Forme normale de Boyce-Codd (BCNF)
Définition 33
Forme normale de Boyce-Codd (BCNF)- Un type entité ou un type association est en forme normale de
Boyce-Codd si, et seulement si, il est en troisième forme normale et si aucun attribut faisant partie de la clé
dépend d'un attribut ne faisant pas partie de la clé.
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.