FBD 1CS Cours03
FBD 1CS Cours03
FBD 1CS Cours03
1. Les concepts
Conçu par E.F. Codd au début des années 70, le modèle relationnel allie la simplicité de
représentation des données au moyen de tables à une définition rigoureuse des concepts
fondée sur la théorie mathématique des relations (l'algèbre relationnelle).
Le modèle relationnel s’appuie sur 3 concepts fondamentaux : le domaine, la relation ou table,
et l’attribut.
Un domaine est un ensemble fini ou infini de valeurs possibles. Le domaine des entiers, le
domaine des booléens, le domaine des couleurs primaire (rouge, bleu, jaune) etc...
Un domaine peut être simple ou composé. Il est dit simple si tous ses éléments sont atomiques
ou encore indécomposables. C’est le cas des exemples précédents. Un domaine est dit
composé si ses éléments peuvent être décomposés. Par exemple, les dates sont composées
d’un mois, un jour et une année. Cependant, on peut toujours considérer qu’un domaine n’est
pas décomposable. Ainsi, la date peut aussi être considérée comme un domaine simple.
Chaque colonne, appelée aussi attribut, contient un sous-ensemble des valeurs d’un domaine.
Un attribut est donc un nom de colonne correspondant à une relation et qui prend ses valeurs
dans un domaine. Deux attributs ne peuvent porter le même nom, même s’ils partagent le
même domaine.
Chaque ligne représente un n_uplet ou t_uple, plus fréquemment appelé tuple, formé d’un
ensemble de n valeurs prises dans les n domaines considérés. Le degré de la relation est le
nombre de colonnes ou de domaines considéré.
On appelle schéma d’une relation le nom de la relation suivi de la liste des attributs et la
définition de leurs domaines. Par exemple, la table Salarié est caractérisée par le schéma
relationnel suivant :
SALARIÉ (matricule : entier,
Nom : chaîne de caractères,
Grade : {employé, agent de maîtrise, cadre},
Salaire :[250,1500])
Parfois les domaines sont omis pour ne donner que :
SALARIÉ (matricule, nom, Grade, Salaire)
On appelle schéma relationnel l’ensemble des relations d’une base de données.
1
Il existe plusieurs types de contraintes d’intégrité (définition de domaine, contrainte de clé, la
contrainte obligatoire1, contrainte d’intégrité référentielle, etc.).
On peut ainsi définir de façon complète le schéma d’une relation comme le nom de la relation
suivi de la liste des attributs, de la définition de leurs domaines et de l’ensemble des
contraintes d’intégrité associées à cette table.
2. La démarche
Décrivons maintenant les règles principales de transformation d’un schéma conceptuel entité-
relation en un schéma relationnel :
Règle 1. Toute entité est traduite en une table relationnelle dont les caractéristiques sont les
suivantes :
le nom de la table est le nom de l’entité ;
la clé de la table est l’identifiant de l’entité ;
les autres attributs de l’entité forment les autres colonnes de la table.
Règle 2. Toute relation binaire M-N est traduite en une table relationnelle dont les
caractéristiques sont les suivantes :
le nom de la table est le nom de la relation ;
la clé de la table est formée par la concaténation des identifiants des entités participant
à la relation ;
les attributs spécifiques de la relation forment les autres colonnes de la table.
Une contrainte d’intégrité référentielle est générée entre chaque colonne clé de la nouvelle
table et la table d’origine de cette clé.
Les attributs spécifiques de cette relation sont ajoutés à la table résultant de la fusion
(choix 1), reportés avec la clé (choix 2), ou insérés dans la table spécifique (choix 3). Dans le
cas de la fusion (choix 1) comme dans celui de la table spécifique (choix 3), les 2 clés des
entités participant à la relation sont toutes deux clés candidates pour la table résultante. De
plus, deux contraintes d’intégrité référentielle sont générées.
Comme dans la règle précédente, le choix du mode de traduction dépend des cardinalités
minimales. Trois cas sont alors possibles :
les deux cardinalités minimales sont égales à 1 : la relation forme une bijection entre les
2 ensembles d’entités. Alors, la meilleure traduction est la fusion (choix 1) ;
l’une des deux est égale à 0, l’autre est 1 : l’une des 2 entités a toujours une entité
correspondante dans l’autre ensemble. Alors, la meilleure traduction est le report de clé
de l’entité dont la participation minimale est 0 dans la table représentant l’autre entité ;
les 2 cardinalités minimales sont égales à 0. Il est recommandé d’examiner la proportion
d’entités participant effectivement à la relation. Si cette proportion est importante pour
les 2 entités, on optera pour la fusion (choix 1). En revanche, si cette proportion est
importante pour l’une des entités, mais secondaire pour l’autre, il est préférable d’opter
pour un report de clé (choix 2). Enfin, si cette proportion est faible pour les deux entités,
la table spécifique est la traduction la plus appropriée (choix 3).
Règle 5. Toute relation ternaire ou plus est traduite par une table spécifique. Sauf cas
particulier, la clé de cette table est constituée par la concaténation des identifiants des
entités de cette table. Pour chaque identifiant, une contrainte d’intégrité référentielle est
générée.
Règle 6. Toute généralisation de E de n entités E1, E2,… En peut être traduite au choix par
l’une des trois solutions suivantes :
la création d’une seule table représentant l’entité générique E et intégrant tous les
attributs des entités spécifiques. Les relations éventuelles impliquant ces entités sont
alors considérés comme impliquant l’entité E avec une cardinalité minimale nulle. La
spécialisation est traduite par l’introduction d’un attribut supplémentaire dont
l’ensemble des valeurs possibles sera l’ensemble des noms des entités spécifiques ;
la création de n tables représentant les entités E1, E2, …En qui héritent de l’ensemble
des attributs et des relations de l’entité générique E ;
la création conjointe des tables E, E1, E2,… En. On peut considérer que l’entité
générique et ses spécifiques sont reliées par des relations 1-1. On est alors ramené à la
règle 4 pour les différentes traductions de ces relations.
Le choix entre ces trois solutions est dicté par la nature des traitements les plus courants. Si
ces derniers portent essentiellement sur les attributs spécifiques indépendamment des attributs
de l’entité générique, on préférera alors la solution 2. Si, au contraire, la plupart des
traitements opèrent conjointement sur tous les attributs, qu’ils soient au niveau générique ou
au niveau spécifique, la solution 1 est préférable. La solution 3 est la seule qui préserve toute
la sémantique. Cependant, elle est, la plupart du temps, trop complexe pour être
recommandée.
3
Règle 7. Toute relation réflexive est considérée comme une relation binaire. Sa traduction
dépend donc du type de cette relation binaire (1-1, 1-N ou M-N) et obéit à l’une des règles 2,3
ou 4.
Si, à la fin du processus de traduction de l’ensemble du schéma ER, on obtient des tables ne
comportant qu’une seule colonne, on ne représentera pas ces tables qui ne sont pas porteuses
d’information spécifique.
3. Exemple d’une base de données relationnelle
A titre d'exemple, considérons le cas d'un MCD rudimentaire, utilisant 2 entités Fournisseurs
et Produits et une association Commandes.
Fournisseurs Produits
numFrs numProd
nom 1-n Commandes 1-n design
adresse numCde, qté prix
ville poids
couleur
MCD Fournisseurs-Produits-Commandes
L'association commandes est un lien maillé porteur d'une propriété. Il y a donc création d'une
table commandes avec report des clés des entités liées, ce qui nous donne bien un MLD,
utilisant 3 tables représentant les commandes de produits à des fournisseurs.
Le schéma de cette base2 est donc :
produits(numProd, design, prix, poids, couleur)
fournisseurs(numFrs, nom, ville)
commandes(numCde, numFrs, numProd, qté)
2
Cet exemple sera utilisé par la suite pour illustrer l'écriture de requêtes.
4