3.1  Introduction au modèle relationnel

3.1.1  Présentation

Le modèle relationnel a déjà été introduit dans la section 1.1.2.

Dans ce modèle, les données sont représentées par des tables, sans préjuger de la façon dont les informations sont stockées dans la machine. Les tables constituent donc la structure logique¹ du modèle relationnel. Au niveau physique, le système est libre d'utiliser n'importe quelle technique de stockage (fichiers séquentiels, indexage, adressage dispersé, séries de pointeurs, compression, ) dès lors qu'il est possible de relier ces structures à des tables au niveau logique. Les tables ne représentent donc qu'une abstraction de l'enregistrement physique des données en mémoire.

Le succès du modèle relationnel auprès des chercheurs, concepteurs et utilisateurs est dû à la puissance et à la simplicité de ses concepts. En outre, contrairement à certains autres modèles, il repose sur des bases théoriques solides, notamment la théorie des ensembles et la logique des prédicats du premier ordre.

Les objectifs du modèle relationnel sont :

• proposer des schémas de données faciles à utiliser ;
• améliorer l'indépendance logique et physique (cf. section 1.2.2) ;
• mettre à la disposition des utilisateurs des langages de haut niveau ;
• optimiser les accès à la base de données ;
• améliorer l'intégrité et la confidentialité ;
• fournir une approche méthodologique dans la construction des schémas.

De façon informelle, on peut définir le modèle relationnel de la manière suivante :

• les données sont organisées sous forme de tables à deux dimensions, encore appelées relations, dont les lignes sont appelées n-uplet ou tuple en anglais ;
• les données sont manipulées par des opérateurs de l'algèbre relationnelle ;
• l'état cohérent de la base est défini par un ensemble de contraintes d'intégrité.

Au modèle relationnel est associée a la théorie de la normalisation des relations qui permet de se débarrasser des incohérences au moment de la conception d'une base de données relationnelle.

3.1.2  Éléments du modèle relationnel

Exemples d'attribut : l'âge d'une personne, le nom d'une personne, le numéro de sécurité sociale.

Par exemple, l'attribut numéro de sécurité sociale a pour domaine l'ensemble des combinaisons de quinze chiffres et nom a pour domaine l'ensemble des combinaisons de lettres (une combinaison comme cette dernière est généralement appelée chaîne de caractères ou, plus simplement, chaîne).

Une relation est représentée sous la forme d'un tableau à deux dimensions dans lequel les n attributs correspondent aux titres des n colonnes.

Le tableau 3.1 montre un exemple de relation et précise son schéma.

---

N° Sécu	Nom	Prénom
354338532195874	Durand	Caroline
345353545435811	Dubois	Jacques
173354684513546	Dupont	Lisa
973564213535435	Dubois	Rose-Marie

Tableau 3.1: Exemple de relation de schéma Personne(N° sécu : Entier, Nom : Chaîne, Prénom : Chaîne)

---

La valeur d'une clé candidate est donc distincte pour toutes les tuples de la relation. La notion de clé candidate est essentielle dans le modèle relationnel.

Ainsi, il ne peut jamais y avoir deux tuples identiques au sein d'une relation. Les clés candidates d'une relation n'ont pas forcément le même nombre d'attributs. Une clé candidate peut être formée d'un attribut arbitraire, utilisé à cette seule fin.

3.1.3  Passage du modèle entités-associations au modèle relationnel

Règles de passage

Pour traduire un schéma du modèle entités-associations vers le modèle relationnel, on peut appliquer les règles suivantes :

1. La normalisation devrait toujours être effectuée avant le passage au modèle relationnel (cf. section 2.4.4). Dans les faits, elle est parfois faite a posteriori (section 3.2), ce qui impose toujours une surcharge de travail importante.
2. Chaque type-entité donne naissance à une relation. Chaque attribut de ce type-entité devient un attribut de la relation. L'identifiant est conservé en tant que clé de la relation.
3. Chaque type-association dont aucune patte n'a pour cardinalité maximale 1 donne naissance à une relation. Chaque attribut de ce type-association devient un attribut de la relation. L'identifiant, s'il est précisé, est conservé en tant que clé de la relation, sinon cette clé est formée par la concaténation des identifiants des type-entités qui interviennent dans le type-association.
4. Un type-association dont au moins une patte a une cardinalité maximale à 1 (ce type-association devrait être binaire et n'a généralement pas d'attribut) ne devient pas une relation. Il décrit en effet une dépendance fonctionnelle (cf. section 3.2). La relation correspondant au type-entité dont la patte vers le type-association a une cardinalité maximale valant 1, se voit simplement ajouter comme attribut (et donc comme clé étrangère) l'identifiant de l'autre type-entité.

Cas particulier d'un type-assocuation du type 1 vers 1

---

Figure 3.1: Reprise de l'exemple de la figure 2.26 d'un type-association Etre où toutes les cardinalités maximales sont de 1.

---

Dans l'exemple de la figure 3.1 toutes les cardinalités maximales du type-association Etre sont de 1. L'application des règles de passage du modèle entités-associations au modèle relationnel énoncées ci-dessus nous donnerait :

• Citoyen(Num-Citoyen, Num-Candidat, Nom, Prénom, Adresse)
• Candidat(Num-Candidat), Num-Citoyen, Parti)

L'attribut Num-Candidat dans la relation Citoyen est une clé étrangère de la relation Candidat. L'attribut Num-Citoyen dans la relation Candidat est une clé étrangère de la relation Citoyen.

Le type-association Etre étant du type 1 vers 1, il est entièrement matérialisé dans la relation Candidat par l'attribut Num-Citoyen. Il est donc inutile de la rematérialiser dans la relation Citoyen. L'attribut Num-Candidat dans la relation Citoyen doit donc être supprimé. D'autre part, dans la relation Candidat, l'attribut Num-Citoyen, en plus d'être une clé étrangère, constitue une clé candidate. On peut donc se passer de la clé Num-Candidat.

Le schéma relationnel adéquat correspondant au modèle entités-associations de la figure 3.1 devient donc :

• Citoyen(Num-Citoyen, Nom, Prénom, Adresse)
• Candidat(Num-Citoyen, Parti)

où Num-Citoyen, en plus d'être la clé de la relation Candidat, est une clé étrangère de la relation Citoyen.

Cas particulier d'un type-entité sans attribut autre que sa clé

Lorsqu'un type-entité ne possède pas d'attribut en dehors de sa clé, il ne faut pas nécessairement en faire une relation.

---

Figure 3.2: Ici, le type-entité Date ne doit pas se matérialiser par une relation.

---

Par exemple, le type-entité Date de la figure 3.2 ne doit pas se traduire par une relation. Le schéma relationnel adéquat correspondant au modèle entités-associations de la figure 3.2 est donc :

• Exemplaire(Num-Exemplaire, date-achat)
• Personne(Num-Personne, nom, prénom, adresse)
• Emprunter(Num-Exemplaire, Num-Personne, Date, date-retour)

Exemple complet

---

Figure 3.3: Exemple très simplifié de modélisation entités-associations

---

Comme exemple d'application, voici les relations déduites du schéma entités-associations de la figure 3.3 :

• Patient(Num-Patient, Nom-Patient, Num-Mutuelle)
• Mutuelle(Num-Mutuelle, Nom-Mutuelle)
• Médecin(Num-Médecin, Nom-Médecin, Prénom-Médecin)
• Affection(Num-Affection, Nom-Affection)
• Hospitaliser(Num-Patient, Num-Affection, Num-Médecin, Date-Entrée, Chambre, Durée-Hospitalisation)

1

Le terme structure logique englobe ici le niveau conceptuel et les niveaux externes d'ANSI/SPARC (cf. section 1.2.3) et correspond approximativement au niveau logique de Merise (cf. section 2.1.2).

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.