1.

Introduction

Le modèle relationnel de données a été proposé par « Codd » en 1970. A cette époque, la plupart
des systèmes de bases de données étaient fondées sur l'un des deux modèles de données plus
anciennes (le modèle hiérarchique et le modèle réseau); le modèle relationnel a révolutionné le
domaine de base de données et a largement supplanté les modèles précédents. Le prototype des
systèmes de gestion de bases de données ont été développées dans les projets de recherche d'IBM
et l’Université de Berkeley au milieu des années 70. Aujourd'hui, le modèle relationnel est de
loin le modèle de données dominant et constitue la base pour les produits SGBD, comprenant la
famille IBM DB2, Informix, Oracle, Sybase, Microsoft Access et SQL Server, FoxBase, et
Paradox. Les systèmes de bases de données relationnelles sont omniprésents sur le marché et
représentent une industrie de plusieurs milliards de dollars.
Le modèle relationnel est très simple et élégante, une base de données est une collection d'un ou
plusieurs relations, où chaque relation est une table avec des lignes et des colonnes. Cette
représentation tabulaire simple permet même aux utilisateurs novices de comprendre le contenu
d'une base de données, et il permet l'utilisation de simples langages de haut niveau pour
interroger les données. Les principaux avantages du modèle de données relationnel par rapport
aux modèles anciens résident dans sa capacité de représenter d’une manière très simple les
données et la facilité avec laquelle les requêtes complexes peuvent être exprimées.

2. Principes du modèle Relationnel

Un modèle de données définit un mode de représentation de l’information selon trois

composantes :
1. Des structures de données.
2. Des contraintes qui permettent de spécifier les règles que doit respecter une base de
données.
3. Des opérations pour manipuler les données, en interrogation et en mise à jour.
Dans le contexte des bases de données, la principale qualité d’un modèle de données est qu’il
doit être indépendant de la représentation physique. Cette indépendance permet de séparer
totalement les tâches respectives des administrateurs de la base, chargés de l’optimisation de ses
performances, et des développeurs d’application ou utilisateurs finaux qui n’ont pas à se soucier
de la manière dont le système satisfait leurs demandes.
Schéma relationnel
Dans le modèle relationnel, il n’existe qu’une seule structure, la relation. Une relation peut
simplement être représentée sous forme de table, comme sur la figure ci-dessous. Une relation a
donc un nom (Film) et se compose d’un ensemble de colonnes désignées par un nom d’attribut.
Dans chaque colonne on trouve des valeurs d’un certain domaine (chaînes de caractères,
nombres). Chaque ligne (ou tuple) correspond à une entité (ici des films).
Un schéma relationnel est constitué d’un ensemble de schémas de relations qui décrivent le
contenu d’une relation. Le schéma de la relation Film est donc :
Film (titre: string, année: number, genre : string)

1
 titre année Genre
Alien 1979 Science-Fiction
Vertigo 1958 Suspense
Volte-face 1997 Thriller
Pulp Fiction 1995 Policier

Domaines
Un domaine de valeurs est un ensemble d’instances d’un type élémentaire. Exemple : les entiers,
les réels, les chaînes de caractères, etc. La notion de ’type élémentaire’ s’oppose à celle de type
structuré : il est interdit en relationnel de manipuler des valeurs instances de graphes, de listes,
d’enregistrements, etc.
En d’autres termes le système de types est figé et fourni par le système.
Attributs
Les attributs nomment les colonnes d’une relation. Ils servent à la fois à indiquer le contenu de
cette colonne, et à la référencer quand on effectue des opérations. Un attribut est toujours associé
à un domaine.
Le nom d’un attribut peut apparaître dans plusieurs schémas de relations.
Schéma de relation
Un schéma de relation est simplement un nom suivi de la liste des attributs, chaque attribut étant
associé à son domaine. La syntaxe est donc :

R(A1 : D1 , A2 :D2 , ... , An : Dn )

Où les Ai sont les noms d’attributs et les Di les domaines. L’arité d’une relation est le nombre de
ses attributs.
On peut trouver dans un schéma de relation plusieurs fois le même domaine, mais une seule fois
un nom d’attribut. Le domaine peut être omis en phase de définition.
Instance d’une relation
Une instance d’une relation R, ou simplement relation se définit mathématiquement comme un
sous-ensemble fini du produit cartésien des domaines des attributs de R. Rappelons que le
produit cartésien D1 × … × Dn entre des domaines D1 , … , Dn est l’ensemble de tous les tuples
(v1 , … , vn) où vi  Di.

Un des fondements du modèle relationnel est la théorie des ensembles et la notion de relation
dans le modèle correspond strictement au concept mathématique dans cette théorie.
Une relation se représente sous forme de table, et on emploie le plus souvent ces deux termes
comme des synonymes.
La définition d’une relation comme un ensemble (au sens mathématique) a quelques
conséquences importantes :
1. l’ordre des lignes n’a pas d’importance car il n’y a pas d’ordre dans un ensemble ;
2. on ne peut pas trouver deux fois la même ligne car il n’y a pas de doublons dans un
ensemble ;
3. il n’y a pas de « case vide » dans la table, donc toutes les valeurs de tous les attributs
sont toujours connues ;

2
Clé d’une relation
La clé d’une relation est le plus petit sous-ensemble des attributs qui permet d’identifier chaque
ligne de manière unique. Comme on a vu que deux lignes sont toujours différentes, l’ensemble
de tous les attributs est lui-même une clé mais on peut pratiquement toujours trouver un sous-
ensemble qui satisfait la condition. Pour distinguer la clé, nous mettrons le (ou les) attribut(s) en
gras.
Film (titre, année, genre)
Le choix de la clé est très important pour la qualité du schéma.

Tuples
Un tuple est une liste de n valeurs (v1 , … , vn) où chaque valeur vi est la valeur d’un attribut Ai de
domaine Di : vi  Di. Exemple :
(’Cyrano’, 1992, ’Rappeneau’)
Un tuple est donc simplement une ligne dans la représentation d’une relation sous forme de
table. En théorie, on connaît les valeurs de tous les attributs du tuple.
Base de données
Une (instance de) base de données est un ensemble fini (d’instances) de relations. Le schéma de
la base est l’ensemble des schémas des relations de cette base.
La création d’un schéma de base de données est simple une fois que l’on a déterminé toutes les
relations qui constituent la base. En revanche le choix de ces relations est un problème difficile
car il détermine en grande partie les caractéristiques, qualités de la base : performances,
exactitude, exhaustivité, disponibilité des informations, etc. Un des aspects importants de la
théorie des bases de données relationnelles consiste précisément à définir ce qu’est un « bon »
schéma et propose des outils formels pour y parvenir.
En pratique, on procède d’une manière moins rigoureuse mais plus accessible, en concevant le
schéma à l’aide d’un modèle de données « conceptuel », puis en transcrivant le schéma
conceptuel obtenu en schéma relationnel. La technique la plus répandue consiste à partir d’un
schéma Entité/Association. La section suivante donne les règles du processus de transformation.

3. Passage d’un schéma E/A à un schéma relationnel

On passe donc d’un modèle disposant de deux structures (entités et associations) à un modèle
disposant d’une seule structure (relations). Logiquement, entités et associations seront donc
toutes deux transformées en relations. La subtilité réside en fait dans la nécessité de préserver les
liens existant explicitement dans un schéma E/A et qui semblent manquer dans le modèle
relationnel. Dans ce dernier cas on utilise en fait un mécanisme de référence par valeur basé sur
les clés des relations.

3
Règles générales
Nous allons considérer dans un premier temps que la clé est définie, pour chaque type d’entité E,
par un identifiant abstrait, idE.
➢ Règles de passage : entités
Pour chaque entité du schéma E/A :
1. On crée une relation de même nom que l’entité.
2. Chaque propriété de l’entité, y compris l’identifiant, devient un attribut de la relation.
3. Les attributs de l’identifiant constituent la clé de la relation.
Exemple 1 A partir du schéma E/A Officiel des spectacles suscité, on obtient les relations
suivantes :
– Film (idFilm, titre, année, genre, résumé)
– Artiste (idArtiste, nom, prénom, annéeNaissance)
– Internaute (email, nom, prénom, région)
– Pays (code, nom, langue)
On peut remarquer que l’on a perdu pour l’instant tout lien entre les relations.
➢ Règles de passage : associations de un à plusieurs
Soit une association de un à plusieurs entre A et B. Le passage au modèle logique suit les règles
suivantes :
1. On crée les relations RA et RB correspondant respectivement aux entités A et B.
2. L’identifiant de B devient un attribut de RA.
L’idée est qu’une occurrence de A « référence » l’occurrence de B qui lui est associée à l’aide
d’une clé étrangère. Cette référence se fait de manière unique et suffisante à l’aide de
l’identifiant.
Exemple 2 :
Voici le schéma obtenu pour représenter l’association entre les types d’entité Film, Artiste et
Pays. Les clés étrangères sont en italiques.

4
– Film (idFilm, titre, année, genre, résumé, idArtiste, codePays)
– Artiste (idArtiste, nom, prénom, annéeNaissance)
– Pays (code, nom, langue)
Le rôle précis tenu par l’artiste dans l’association disparaît. L’artiste dans Film a un rôle de
metteur en scène, mais il pourrait tout aussi bien s’agir du décorateur ou de l’accessoiriste. Rien
n’empêche cependant de donner un nom plus explicite à l’attribut. Il n’est pas du tout obligatoire
en fait que les attributs constituant une clé étrangère aient le même nom que ceux de la clé
primaire auxquels ils se réfèrent. Voici le schéma de la table Film, dans lequel la clé étrangère
pour le metteur en scène est nommée idMES.
Film (idFilm, titre, année, genre, résumé, idMES)
Les tables ci-dessous montrent un exemple de la représentation des associations entre Film et
Artiste d’une part, Film et Pays d’autre part. Noter que rien n’empêche un artiste dont idArtiste
= 2 par exemple de figurer plusieurs fois dans la colonne idMES de la table Film. On a donc bien
l’équivalent de l’association un à plusieurs élaborée dans le schéma E/A.
➢ Règles de passage : associations binaires de plusieurs à plusieurs
Soit une association binaire n-m entre A et B.
1. On crée les relations RA et RB correspondant respectivement aux entités A et B.
2. On crée une relation RA-B pour l’association.
3. La clé de RA et la clé de RB deviennent des attributs de RA-B.
4. La clé de cette relation est la concaténation des clés des relations RA et RB
5. Les propriétés de l’association deviennent des attributs de RA-B.

Exemple 4 Toujours à partir du schéma Officiel des spectacles, on obtient la table Rôle
représentant l’association entre les films et les acteurs.
– Film (idFilm, titre, année, genre, résumé, idMES, codePays)
– Artiste (idArtiste, nom, prénom, annéeNaissance)
– Role (idFilm, idActeur, nomRôle)
De même, on obtient une table Notation pour représenter l’association entre un internaute et les
films qu’il a notés.
– Film (idFilm, titre, année, genre, résumé, idMES, codePays)
– Internaute (email, nom, prénom, région)
– Notation (email, idFilm, note)
Les tables suivantes montrent un exemple de représentation de Rôle. On peut constater le
mécanisme de référence unique obtenu grâce aux clés des relations. Chaque rôle correspond à un
unique acteur et à un unique film. De plus on ne peut pas trouver deux fois la même paire
(idFilm, idActeur) dans cette table, ce qui n’aurait pas de sens. En revanche un même
acteur peut figurer plusieurs fois (mais pas associé au même film), ainsi qu’un même film (mais
pas associé au même acteur).

5
On peut remarquer finalement que chaque partie de la clé de la table Rôle est elle-même une clé
étrangère qui fait référence à une ligne dans une autre table :
1. l’attribut idFilm fait référence à une ligne de la table Film (un film) ;
2. l’attribut idActeur fait référence à une ligne de la table Artiste (un acteur) ;

➢ Associations ternaires
Dans le cas d’associations impliquant plus de deux entités (voir figure), on atteint une des limites
du modèle Entité/Association en matière de spécification de contraintes.

En première approche, on peut appliquer la règle énoncée précédemment pour les associations
binaires et la généraliser. On obtiendrait alors, pour l’association Séance :

6
 − Cinéma (nomCinéma, numéro, rue, ville)
− Salle (nomCinéma, no, capacité)
− Film (idFilm, titre, année, genre, résumé, idMES, codePays)
− Horaire (idHoraire, heureDébut, heureFin)
− Séance (idFilm, nomCinéma, noSalle, idHoraire, tarif)
La représentation d’une association ternaire, dans ce cas « Séance » est comme suit :

Donc, la relation Séance a pour clé la concaténation des identifiants de chacune des entités
composantes, ce qui donne une clé d’une taille assez importante. On autorise alors une base
comme celle de la figure précédente. On ne peut pas trouver deux fois le même triplet constituant
la clé.
Maintenant on s’aperçoit que la même salle présente deux films différents au même horaire. Si
on souhaite éviter cette situation, la clé devient (nomCinéma, noSalle, idHoraire), et on ne
respecte plus la règle de passage du schéma E/A vers le schéma relationnel.
En d’autres termes, en cas d’association entre plus de 2 entités, la clé de la table représentant
l’association est un sous-ensemble de la concaténation des clés. Il faut se poser soigneusement la
question de la (ou des) clé(s) au moment de la création de la table car elle(s) ne peu(ven)t plus
être déduite(s) du schéma E/A. On parle parfois de clé candidate.

7
4. Choix des identifiants

Il est préférable en général de choisir un identifiant « neutre » qui ne soit pas une propriété de
l’entité. En effet :
1. Chaque valeur de l’identifiant doit caractériser de manière unique une occurrence.
Exemple : titre pour la relation Film ou nom pour la relation Acteur ne sont clairement
pas des bons choix.
2. Si on utilise un ensemble de propriétés comme identifiant, la référence à une occurrence
est très lourde. Exemple : la clé de Cinéma pourrait être (nom, rue, ville).
3. L’identifiant sert de référence externe et ne doit donc jamais être modifiable (il faudrait
répercuter les mises à jour).
L’inconvénient de l’identifiant « neutre » est qu’il ne donne pas d’indication sur l’occurrence
qu’il réfère. Par exemple, quand on consulte la table Séance, on ne sait pas dire de quel film il
s’agit sans aller rechercher la ligne de la table Film correspondant à l’identifiant du film.
En admettant – pour un instant – que le titre identifie de manière unique un film, le schéma de la
table Film devient :
Film (titre, année, genre, résumé, idMES, codePays)
La relation Séance a alors pour schéma :
Séance (titreFilm, nomCinéma, noSalle, idHoraire, tarif)
Ce qui permet d’obtenir le titre du film directement, comme le montre l’instance ci-dessous.

Un problème du schéma ci-dessus est que la référence à une ligne de la table Séance devient
compliquée, et donc peu performante. Il faut veiller à limiter le nombre de champs constituant
une clé car l’expression des requêtes est plus lourde, et leur exécution peut être ralentie par la
taille des index.

8
5. Théorie de la normalisation

La normalisation permet de définir une méthode de conception de "bonnes" tables, c'est-à-dire

sans redondances et sans perte d'information. Ainsi, La normalisation est préconisée pour :
− éliminer les redondances ;
− mieux comprendre les relations sémantiques entre les données ;
− éviter les incohérences de mise à jour ;
− éviter, autant que possible, les valeurs nulles.

5.1 Dépendances fonctionnelles (DF)

Un attribut (ou un groupe d'attributs) Y dépend fonctionnellement d'un attribut (ou groupe
d'attributs) X si : étant donné une valeur de X, il lui correspond une valeur unique de Y (∀
l'instant considéré)
X→Y : Y dépend fonctionnellement de X ou X détermine Y

➢ Propriétés des dépendances fonctionnelles

− Réflexivité : Tout ensemble d'attributs détermine lui-même ou une partie de lui-même.
YX  X→Y
− Augmentation : Si X détermine Y, les deux ensembles d'attributs peuvent être enrichis
par un troisième.
X →Y  X, Z → Y, Z
Z  W et X →Y  X, W → Y, Z

− Transitivité : Le composé de deux fonctions dont l'image de l'une est le domaine de

l'autre, est une fonction.
X → Y et Y → Z  X → Z
− L’union : X → Y et X →Z  X→Y, Z
− Pseudo-transitivité : X → Y et Y, W → Z  X, W → Z
− Décomposition : X → Y et Z  Y X → Z (parce que Z  Y Y→Z)

5.2 Normalisation de relation

On part de deux ensembles : une relation universelle (relation unique qui contient tous les
attributs de l’application), et l’ensemble F des DF sous forme minimale.
On décompose la relation universelle en utilisant F pour obtenir un ensemble de relations pour
une certaine forme normale (FN) choisie à l'avance : 1ère, 2ème, 3ème, forme normale de Boyce
Codd, 4ème et 5ème.
Les trois premières FN ont été définies par Codd (1972).
• 1FN : la plus simple, évite les domaines composés de plusieurs valeurs.
• 2FN : beaucoup de redondances → coût élevé de MAJ.
• 3FN : peu de redondances → coût faible de MAJ, mais beaucoup de jointures.

9
1ère forme normale (1FN)
Justifiée par la simplicité et l'esthétique, la 1FN consiste à éviter les domaines constitués de
plusieurs valeurs.
On dit qu'une relation est en 1FN si tous ses attributs sont de type élémentaire : char, string, int,
float.
Les attributs de type structure, ensemble et liste sont interdits. Si on a besoin d'une structure, soit
on la met à plat, soit on crée une nouvelle relation.
2ère forme normale (2FN)
La 2FN permet d'éliminer certaines redondances en assurant qu'aucun attribut n'est déterminé par
une partie seulement de la clé.
Une relation est en 2FN si et seulement si :
✓ elle est en 1FN
✓ les attributs qui ne sont pas clé sont pleinement dépendants de chaque clé (dépendent de
la clé entière).
Exemple :

La clé est le couple X, Y. Donc X, Y →Z, W. Or Y détermine à lui seul W : Y →W. Donc W
dépend d'une partie de la clé. Il faut donc décomposer R en : R1 <X, Y, Z> et R2 <Y, W>.

3ère forme normale (3FN)

La 3FN permet d'assurer l'élimination des redondances dues aux dépendances transitives.
Une relation est en 3FN si et seulement si :
✓ Elle est en 2FN.
✓ Tout attribut n'appartenant pas à une clé ne dépend pas d'un autre attribut non clé.
Autrement dit, tous les attributs n'appartenant à aucune clé sont directement et non
transitivement dépendants d'une clé.
Exemple :

La clé de la relation est X. Donc X → Y, Z, W. Or Y détermine à lui seul W : Y → W. Donc W

dépend d'un attribut non clé. Il faut donc décomposer R en : R1 <X, Y, Z> et R2 <Y, W>.

10
Forme normale de « Boyce Codd » (FNBC)
La 2FN élimine les anomalies créées par des DF entre parties de clé et attribut non clé.
La 3FN élimine les anomalies créées par des DF entre les attributs non clés.
Et les DF de parties de clés entre elles ou d'attributs non clé vers une partie de clé ?
 3FN insuffisante  FNBC.
Une relation est en FNBC si et seulement si les seules DF élémentaires sont celles dans
lesquelles une clé entière détermine un attribut.
En clair, pas de DF autres que K → A, K étant la clé et A un attribut non clé.
Exemple :

La clé est le couple X, Y. Donc X, Y → Z, W. Or W détermine X : W → Y. Donc une partie de

la clé dépend d'un attribut non clé. Il faut donc décomposer R en : R1 <X, Y, Z> et R2 <W, Y>.
Dépendances multi-ensembles (multivaluées) et 4ère forme normale (4FN)
Certaines relations sont en forme normale de Boyce Codd et contiennent cependant des
redondances d'informations qui créent des problèmes lors de leurs mises à jour. Un exemple
d'une telle relation, est la relation CatalogueBC (N°Article , Taille , Couleur), qui décrit la
section habillement du catalogue d'un grand magasin de vente par correspondance. On suppose
que Taille et Couleur sont indépendants.

N°Article Taille Couleur

Pull 38 Bleu
Pull 40 Bleu
Pull 42 Bleu
Pull 44 Bleu
Pull 38 Vert
Pull 40 Vert
Pull 42 Vert
Pull 44 Vert

Cette relation n'a pas de DF. L'identifiant est (N°Article + Taille + Couleur).
On est en Boyce Codd puisqu'il n'y a pas de DF (la proposition "toute source de DF est un
identifiant entier" est vraie). Par contre, il y a un autre type de dépendance : chaque article existe
pour chaque taille dans toutes les couleurs, et réciproquement chaque article existe pour chaque
couleur dans toutes les tailles. De telles dépendances sont appelées dépendances multi-
ensembles (ou dépendances multivaluées).
Définition : Soit une relation R(X, Y, Z), il y a dépendance multi-ensemble (DM) X→→Y si à toute
valeur de X correspond un ensemble de valeurs de Y qui est totalement indépendant de Z.
Formellement, si t1 et t2 sont deux tuples de R, tels que t1[X] = t2[X], alors il existe deux tuples v1 et v2
de R tels que :

11
 v1[X] = v2[X] = t1[X]
v1[Y] = t1[Y] , v1[Z] = t2[Z]
v2[Y] = t2[Y] , v2[Z] = t1[Z]
On remarque que les DF sont des cas particuliers de DM.

Si dans une relation R (X, Y, Z), on a la dépendance multi-ensemble X→→Y, alors on a aussi la
dépendance multi-ensemble X→→Z.

4ère forme normale (4FN)

Comme les DF, les DM qui ne sont pas exprimées par une relation, créent des redondances et
donc des problèmes lors des mises à jour. Par exemple, la création d'un nouvel article dans la
relation CatalogueBC nécessite d'insérer n×m tuples, « n » étant le nombre de tailles et « m »
celui des couleurs. La solution, comme avec les DF, est de décomposer, si possible, la relation
sans perte d'information ni de dépendance.
La relation CatalogueBC qui contient deux DM :
N°Article →→ Taille et N°Article →→ Couleur, est donc décomposée de la façon suivante :
création d'une relation par DM (ce qui revient en terminologie entité association à créer une
relation par attribut multivalué).
− ArticleCouleur (N°Article, Couleur)
− ArticleTaille (N°Article, Taille)
Ces deux relations ne posent plus de problème lors des mises à jour.
Le théorème de « Heath » sur les décompositions sans perte d'information est généralisé au cas
des dépendances multi-ensembles.
Théorème :
Toute relation R (X, Y, Z) est décomposable sans perte d'information en π[X,Y]R et π[X,Z]R, s'il
y a une dépendance multi-ensemble de X vers Y (X→→ Y).
Un inconvénient des DM, que n'ont pas les DF, est que leur existence dépend des valeurs prises
par les autres attributs de la relation. Ainsi, lors des décompositions d'une relation, il faut, dans
chaque relation décomposée, vérifier quelles sont les DM, car de nouvelles DM peuvent
apparaître.
Définition :
Une relation R est en quatrième forme normale si elle est en première forme normale, et si
toute dépendance fonctionnelle ou multi-ensemble de R (X→Y ou X→→Y) -telle qu'il existe
dans R d'autres attributs en plus de X et Y- a pour source un identifiant entier de R.
Cette définition de quatrième forme normale implique celle de Boyce Codd.
La relation CatalogueBC n'est pas en quatrième forme normale. Mais les deux relations issues de
la décomposition de CatalogueBC, ArticleTaille et ArticleCouleur, le sont.

5ère forme normale (5FN)

Une dépendance de jointure (DJ) est une généralisation de dépendances multivaluées. Une
dépendance de jointure ⋈ {𝑅1 , … , 𝑅𝑛 } sur la relation R si R1,…,Rn est une décomposition sans perte de
jointure de R.
Autrement dit :

12
 R (A1, A2, …An)
X1, X2, …, Xm sous-ensembles de {A1, A2, …, An}
Il existe une dépendance de jointure *{X1, X2, …, Xm} si R = ∏X1 (R) ∏X2 (R) … ∏Xm (R)
Un schéma de relation R est dit sous cinquième forme normale (5NF) si pour tout DJ ⋈
{𝑅1 , … , 𝑅𝑛 } sur R, l'un des énoncés suivants est vrai :
− Ri = R pour certains i, ou
− La DJ est incluse dans l'ensemble des DFs sur R dont le côté gauche est une clé
pour R (toutes les DJ sont impliquées par les clés)
Elle consiste à l’utilisation des dépendances de jointure (DJ), pour supprimer certaines
redondances.
Exemple : Base « Jus »

Consommateur Jus Producteur

Ali orange Rouiba
Ali orange Hammoud
Ali Cocktail Hammoud
Mohamed orange Hammoud

N’est pas en 4FN parce qu'il n'existe pas de DM (par exemple Consommateur →→ Jus est faux
parce qu’il n’existe pas le tuple (Ali, Cocktail, Rouiba)).
Il reste encore des redondances : on apprend deux fois que « Ali » boit du jus d’orange et que
« Hammoud » produit de jus d’orange.
Mais il est impossible de décomposer de deux relations.
Les DM permettent de décomposer une relation en deux, les DJ permettent de décomposer une
relation en N relations.
On obtient alors le schéma (en 5NF) :

Consommateur Jus Consommateur Producteur Jus Producteur

Ali Orange Ali Rouiba orange Rouiba
Ali Cocktail Ali Hammoud orange Hammoud
Mohamed Orange Mohamed Hammoud Cocktail Hammoud

13