Vous êtes sur la page 1sur 8

Master 2 C.G.A.O. - A.

Olivier

Analyse et conception d’une base de données - Cours 2 -


Organiser les données (2) - Le schéma relationnel

Revenons sur l’analyse à trois niveaux présentée dans le cours précédent :

Le niveau conceptuel : le Modèle Le modèle conceptuel des données, un outil d’aide à


Conceptuel des Données l’organisation des informations en entités et associa-
Quoi faire? tions, afin de concevoir une base de données respec-
Quelles informations? tant les objectifs et le cahier des charges.

Le niveau logique : le Schéma Rendre le MCD exploitable par le logiciel de gestion


Relationnel de bases de données ou transformer le M.C.D. en
Comment le faire? schéma relationnel.
Comment structurer les données? C’est l’objet de ce cours.

Niveau physique : Où stocker les données?


Comment faire? Quel logiciel de gestion de base de données choisir?
Quelles tables? Quels identifiants?
Quels index? Quelles relations?

1 Du modèle conceptuel des données au schéma relationnel


Le schéma relationnel va nous permettre de descendre d’un niveau, de passer du niveau conceptuel
au niveau logique.
A l’aide d’une syntaxe issue de la théorie mathématique des ensembles, le schéma relationnel traduit
le modèle conceptuel des données sous formes de Relations, c’est-à-dire de tables de données.
Il facilitera l’implantation physique de la base de données.

1.1 Un exemple
Soit le MCD présenté l̀a fin du cours 1 :

figure 1

Voici le schéma relationnel issu de ce MCD :

FOURNISSEUR (NumeroFourn, NomFourn, AdresseFourn, CPFourn, VilleFourn)


PRODUIT (CodeProd, NomProd)
CATALOGUE (#NumeroFourn, #CodeProd, PrixProd)
Organiser les données - Le schéma relationnel - Master 2 C.G.A.O. - A. Olivier 2

Ce schéma contient 3 ensembles :


– un pour Fournisseur, contenant l’identifiant (souligné) et les autres attributs de l’entité Fournisseur ;
– un pour Produit, avec l’identifiant (souligné) et l’attribut autre de l’entité Produit ;
– et un troisième pour Catalogue qui, bien que n’étant pas une entité mais une association, donne
lieu à un ensemble distinct dans le schéma relationnel.
Catalogue est doté d’un double identifiant, comme nous l’avons vu dans le cours 1, et d’un attribut
propre (PrixProd).
Le double identifiant NumeroFourn - CodeProd qui n’apparaissait pas dans le MCD, est visible
dans le schéma relationnel.
Les termes soulignés signalent les clés des entités/associations.
Le symbole # indique qu’il s’agit de clés externes.

1.2 Le vocabulaire du Schéma relationnel


Le schéma relationnel regroupe des données en ensembles homogènes issus du MCD.
Ces ensembles d’attributs sont de deux types :
– certains sont issus des entités définies par le MCD,
– d’autres des associations créées dans le MCD.
Chacun de ces ensembles est appelé une relation.
Une relation est définie par :
1. Un nom, généralement en majuscules, qui est également le nom de l’entité/association dans le MCD.
2. Des attributs.
A chaque attribut, on peut adjoindre un domaine de chaque attribut (Un domaine est un ensemble
de valeurs que peut prendre un attribut).
3. Une (ou des) clé(s), c’est-à-dire un (ou des) attribut(s) constituant son (ses) identifiant(s). ,
Ces attributs sont soulignés.
le symbole # indique qu’il s’agit de clés doubles (pour les associations) .
On utilisera également ce symbole # pour indiquer les clés étrangères., c’est-à-dire les attributs
permettant de lier deux relations.
L’ensemble de ces éléments constituent ce que l’on appelle le schéma de la relation .

Exemple :
ETUDIANT (Numero, Nom, Prenom, Age)
A chaque attribut on peut associer un domaine de valeurs.
Exemple de domaines :
– Pour le numéro étudiant : Dnumero = entier compris entre 1 et 99999
– Pour le nom : Dnom = chaı̂ne de caractères de longueur maximale 20
– Pour l’age : Dage=entier compris entre 15 et 65.

Si l’on ajoute les domaines au schéma de la relation, on aura :

ETUDIANT (Numero : Dnumero, Nom : Dnom, Prenom : DPrenom, Age : Dage)

On utilisera cependant peu dans la suite du cours cette syntaxe assez lourde. Pour les domaines de
valeurs on se réfèrera au dictionnaire des données (voir cours 1).
Organiser les données - Le schéma relationnel - Master 2 C.G.A.O. - A. Olivier 3

1.3 Règles de passage du MCD au schéma relationnel


Règle 1 - Chaque entité du MCD est exprimée sous la forme d’une relation (qui sera plus tard la table
de la base de données).
Règle 2 - Chaque attribut d’une entité du MCD est traduit en attribut de la relation (correspondant
ultérieur de la colonne de la table).
Règle 3 - Chaque identifiant d’une entité devient clé primaire de la relation correspondante.
Règle 4 - Les associations hiérarchiques (1,1 -1,n) disparaissent.
Elles ne donnent naissance à aucune relation (et donc à aucune table dans la base de données).
Mais la clé de l’entité côté n est insérée dans l’entité côté 1.
Cette clé devient une clé étrangère de la relation correspondante.
Exemple :

figure 2

CLIENT (NumClient, Nom, Prenom)


TABLEAU (Référence, Peintre, #NumClient)

Ici, c’est NumClient qui devient clé étrangère dans la relation Tableau. Son nom apparaı̂t à la
FIN de la liste d’attributs.
La clé étrangère est précédée du symbole # (clé externe).
Elle n’est PAS soulignée (ce n’est pas un identifiant).
A chaque tableau sera donc associé un numéro de client.

Si l’on “ne sais plus” de quel côté insérer la clé étrangère, il suffit de raisonner sur le sens de la
relation ainsi créée et sur les occurences qui apparaı̂tront dans cette relation.
Dans notre exemple, si nous insérons la clé Référence dans la relation Clients,

CLIENT (NumClient, Nom, Prenom, #Référence)

cela signifie qu’une référence de tableau figurera sur chaque ligne Numéro client. Ce qui signifie
qu’il ne pourra y avoir qu’un seul tableau par client. Ce qui n’est pas compatible avec les
cardinalites.
C’est donc bien NumClient qui doit être inséré dans Tableau et non l’inverse.
Règle 5 - Les associations non hiérarchiques (1,n - 1,n) donnent naissance à une relation (et donc
à une table dans la base) dont l’identifiant est une clé double constituée des deux clés primaires
des entités associées, comme nous l’avons vu dans l’exemple de la figure 1.
Exemple :

figure 3
Organiser les données - Le schéma relationnel - Master 2 C.G.A.O. - A. Olivier 4

CLIENT (NumClient, Nom, Prenom)


PRODUIT (Code)
ACHETE (#NumClient, #Code)

Les deux premières relations correspondent aux entités du MCD, avec les mêmes clés.
La troisième remplace l’association non hiérarchique, avec une clé double (celle de l’entitéClient
et celle de l’entité Produit).
Ces deux clés sont précédées du symbole # (clés externes).
Elles sont soulignées (ce sont des identifiants).
Cette relation n’a pas d’attribut propre.
Remarque :
Les MCD des figures 2 et 3, bien que présentant des points communs (base de données achats
impliquant des clients et un “produit”), sont traités de manière tout-à-fait différente en terme
de schéma relationnel :
– dans le premier cas, les produits sont “unique” (cardinalité 1,1 et association hiérarchique) ;
– dans le second MCD, les produits sont nombreux et indifférenciés (cardinalité 1,n et as-
sociation non hiérarchique).

2 Modèle conceptuel des données et schéma relationnel : les cas


particuliers

2.1 Entités dépendantes


Une entité est dite dépendante (ou faible) si elle n’existe que par l’intermédiaire d’une autre
entité. Une entité principale (ou forte) est, à l’inverse, une entité qui n’a pas besoin d’une
autre entité pour exister.

Exemple :
Le MCD suivant est celui de la base de données d’une société d’immeubles.
Chaque immeuble est référencé par un code (A,B,C,D...) et possède plusieurs appartements, eux-
mêmes référencés par un nombre correspondant à l’étage (101, 102, 103 pour le premier étage, 201, 202,
203 pour le deuxième étage, etc.)

figure 4

La particularité de ce MCD réside dans l’idendifiant de l’entité Appartement.


En effet, le numéro d’appartement ne suffit pas à identifier un appartement de façon unique car ce
numéro ne permet pas de situer le bâtiment dans lequel est situé cet appartement. Il existe, par exemple,
un appartement 203 dans chaque bâtiment.
La clé NumBatiment est indispensable à l’identification d’un appartement.
Le schéma relationnel :
La relation issue d’une entité forte ne présente aucune particularité.
Organiser les données - Le schéma relationnel - Master 2 C.G.A.O. - A. Olivier 5

En revanche, la clé d’une entité faible est composée de deux éléments :


– La clé primaire de l’entité forte dont elle dépend (précédée du symbole #),
– La clé primaire propre à cette entité faible.

BATIMENT (NumBatiment, NombrAppart, DateConstr)


APPARTEMENT (#NumBatiment, NumAppart, Surface, Etage)

La relation Appartement possède donc deux clés :


– d’abord l’attribut NumBatiment indispensable pour identifier l’appartement (il s’agit d’une clé
externe : elle est précédée du symbole #),
– et la clé primaire NumAppart.
Les deux élements sont situés au début de la relation.
Ils sont soulignés (ce sont des identifiants).

2.2 Associations réflexives


Une association est dite réflexive lorsque qu’elle permet de modéliser une relation entre une
identité et elle-même.

Voyons comment cette particularité se traduit d’abord en termes de MCD, puis dans le schéma rela-
tionnel, pour les associations hiérarchiques d’une part et pour les associations non hiérarchiques d’autre
part.

2.2.1 Les associations réflexives hiérarchiques


Rappelons que dans une association hérarchique, une des cardinalités maximales est égale à 1 (cardi-
nalités 1,1 et 1,n ou bien 0,1 et 0,n).
Exemple :
Soit un extrait de base de données “Salariés” d’un service de Ressources Humaines.
L’entité Salarié contient tous les attributs relatifs aux salariés de cette entreprise. Tout supérieur
hiérarchique ou subalterne est également un salarié. Il n’y a donc pas lieu, pour définir l’association
Encadrer, de créer une autre entité.
L’association Encadrer relie donc l’entité à elle-même, en précisant, sur les “connecteurs”, outre la
cardinalité de la relation, la signification de cette relation, c’est-à-dire le rôle attribué à chaque branche
de l’association (figure 5).

figure 5

L’hypothèse de travail est celle d’une organisation hiérarchique classique :


– Un salarié peut avoir plusieurs subalternes (cardinalité maximale n) ; Il peut également ne pas en
avoir (cardinalité minimale égale à 0).
– Un salarié n’a qu’un seul supérieur (cardinalité maximale 1). Il peut également n’en avoir aucun
(cardinalité minimale égale à 0).
Organiser les données - Le schéma relationnel - Master 2 C.G.A.O. - A. Olivier 6

Le schéma relationnel :
Nous sommes dans le cas d’une association hiérarchique. Il n’y aura donc pas de création de relation
pour cette association mais la clé de l’entité côté n est insérée dans l’entité côté 1 (voir règle 4).
Dans notre cas, ces deux entités sont confondues et la clé est unique.
Avec l’ajout de la clé externe, deux attributs NumSalarié vont apparaı̂tre dans la relation :
– le premier comme clé primaire,
– et le second comme clé externe.
La clé “externe” devra donc porter un nom différent, tout en se référant au même attribut.
Le schéma relationnel sera le suivant :

SALARIE (NumSalarié, Nom, Prénom, Fonction, ... , #NumChef)

A chaque salarié sera attaché un attribut NumChef qui sera en fait le numéro de salarié de son
supérieur hiérarchique. Il s’agit d’une clé externe qui n’est pas un identifiant et qui sera donc :
– placée en dernier dans la liste des attributs,
– précédée du symbole #,
– et non soulignée.

2.2.2 Les associations réflexives non hiérarchiques


Rappelons que dans une association non hérarchique, les deux cardinalités maximales sont égales à n.
Exemple :
Un exemple classique d’association réflexive non hiérarchique est celui de la relation composant-
composé permettant de définir les pièces/références/composants entrant dans la fabrication d’autres
pièces/références/composants d’une chaı̂ne de fabrication.
Voici le MCD correspondant :

figure 6

L’association Composition relie l’entité Pièce à elle-même et les “connecteurs” précisent la signification
de chaque branche.
Remarquez les cardinalités :
– un élément peut entrer dans la composition de plusieurs autres élements (cardinalité maximale =
n), sauf s’il s’agit d’un produit fini, auquel cas il n’entrera dans la composition d’aucun (cardinalité
minimale = 0).
– un élément peut être composé de plusieurs sous-éléments (cardinalité maximale = n), sauf s’il s’agit
d’un composant élémentaire, c’est-à-dire non décomposable (cardinalité minimale = 0).
Remarquez également que l’association Composition possède un attribut propre, l’attribut Nombre :
plusieurs composants de même type (c’est-à-dire non différenciables et ayant même référence : des boulons
ou des écrous par exemple) peuvent entrer dans la fabrication d’un élément.
Organiser les données - Le schéma relationnel - Master 2 C.G.A.O. - A. Olivier 7

Le schéma relationnel :
Il s’agit bien d’une association non hiérarchique.
L’association doit donc donner lieu à la création d’une relation dont l’identifiant est constitué des
deux clés des entités associées, et pouvant contenir des attributs propres (règle 5).
Cependant, deux attributs ne pouvant porter le même nom, on sera amenés à renommer l’une de ces
clés. Ici, nous choisissons de renommer les deux (RéférenceComposé et RéférenceComposant), étant bien
entendu que ces deux clés font référence au même attribut.
Ces deux clés externes sont des identifiants et sont donc :
– placées au début de la liste des attributs,
– précédées du symbole #,
– et soulignées.
Le schéma relationnel s’écrit comme suit :

PIECE (Référence, Libellé, ...)


COMPOSITION (#RéférenceComposé, #RéférenceComposant, Nombre)

2.3 Association avec une cardinalité 0,1


Jusqu’à maintenant nous avons traité la cardinalité 0,1 comme la cardinalité 1,1, et la cardinalité 0,n
comme la cardinalité 1,n. Pour la cardinalité 0,n (c’est-à-dire pour les associations non hiérarchiques),
cela ne pose pas de problème. Pour la cardinalité 0,1 (associations hiérarchiques), c’est autre chose.
Le schéma relationnel issu de la figure 5, par exemple,

SALARIE (NumSalarié, Nom, Prénom,


Fonction, ... , #NumChef)

serait identique si la cardinalité était 1,1 au lieu de 0,1.


Mais pour que ce schéma relationnel soit adapté au logiciel de gestion de bases de données, il faut
que ce logiciel accepte les valeurs nulles. En effet, pour au moins un salarié (celui situé en haut de la
hiérarchie), il peut ne pas y avoir de NumChef. Si cette valeur nulle n’est pas autorisée par le logiciel de
gestion de base de données (propriété Null interdit sous Access par exemple), un dysfonctionnement se
produira.
Exemple :
Reprenons l’exemple de la figure 2 en modifiant quelque peu les données de l’énoncé.
Supposons maintenant qu’un tableau puisse ne pas trouver acquéreur.
La cardinalité à droite est donc 0,1 et non 1,1 :

figure 7
Organiser les données - Le schéma relationnel - Master 2 C.G.A.O. - A. Olivier 8

Le schéma relationnel :

Cas 1 - Valeurs nulles acceptées. Nous retrouvons le schéma relationnel de la page 3 :

CLIENT (NumClient, Nom, Prenom)


TABLEAU (Référence, Peintre, #NumClient)

Pour les tableaux n’ayant pas trouvé acquéreur, la valeur de #NumClient sera nulle. Mais ce
n’est pas un problème.
Cas 2 - Valeurs nulles non acceptées.
Dans ce cas, une association hiérarchique ayant une cardinalité 0,1 sur un côté donnera naissance
à une nouvelle relation, et sera traitée comme une association non hiérarchique.

CLIENT(NumClient, Nom, Prénom)


TABLEAU(Référence, Peintre)
ACHETE(#NumClient, #Référence)

La relation Achète ne contient que les Références de tableaux ayant trouvé acquéreur et les
NumClient correspondants. Elle est donc compatible avec un système de gestion de base de
données n’acceptant pas les valeurs nulles.

Vous aimerez peut-être aussi