Introduction aux systèmes de bases de données/Le modèle relationnel

**Le modèle relationnel**
Leçon : Introduction aux systèmes de bases de données

Chapitre n^o 2
Chap. préc. :	Introduction
Chap. suiv. :	Dépendances fonctionnelles et normalisation

En raison de limitations techniques, la typographie souhaitable du titre, « Introduction aux systèmes de bases de données : Le modèle relationnel
Introduction aux systèmes de bases de données/Le modèle relationnel », n'a pu être restituée correctement ci-dessus.

Présentation générale

Le modèle relationnel est fondé sur la théorie mathématique de l’algèbre relationnelle. Il permet de produire une représentation simple des données sous forme de tables constituées de lignes et de colonnes. Il n'y a donc pas de pointeurs qui figent la structure de la base (contrairement au modèle navigationnel présenté dans le chapitre précédent).

Cela aboutit à une représentation souple des données dont on peut extraire des informations à travers des langages non procéduraux, développés grâce à l’algèbre relationnelle.

L'utilisateur ou le programmeur indique quelles informations il veut obtenir et c’est le SGBD (Système de gestion de base de données) qui trouve la manière d'arriver au résultat. Le programme ou l'utilisateur n'a plus à naviguer dans la base pour retrouver ses données.

Ces langages permettent :

l’utilisation par des « non-informaticiens », c'est-à-dire n'ayant pas besoin de connaissance en système ou en programmation (mais l'apprentissage du langage d'extraction des données est lui indispensable) ;
l'écriture de programmes indépendants de la structure des données.

L'exemple le plus populaire d'un tel langage est SQL (Structured query language soit « langage structuré de requêtes »).

La paternité du modèle relationnel est généralement attribué à Edgar Frank Codd à travers son article « A Relational Model of Data for Large Shared Data Banks » publié en juin 1970.

Codd a énoncé la définition d'un SGBD en 12 règles. Bien qu'aucun logiciel ne puisse actuellement prétendre toutes les respecter (bien que certains s'en rapprochent grandement), elles restent des références en matière de spécifications qu'un logiciel doit suivre pour être qualifié de SGBD.

Ces règles sont :

toutes les informations sur les données sont représentées au niveau logique et non physique (pas besoin d'informations sur la façon dont sont enregistrées physiquement les données) ;
les données sont accessibles uniquement par la combinaison du nom de la table, de la clé primaire et du nom de la colonne (pas de chemin à donner) ;
une valeur spéciale doit représenter l'absence de valeur (valeur NULL) ;
la description de la base de données doit être accessible comme les données ordinaires (un dictionnaire des données est enregistré dans la base) ;
un langage doit permettre de définir les données, définir des vues (visions particulières de la base, enregistrées comme des relations), manipuler les données, définir les contraintes d'intégrité, des autorisations et gérer des transactions ;
on peut faire des mises à jour par les vues lorsque c’est logiquement relationnel et enregistrées dans le dictionnaire des donnés ;
le langage doit comporter des ordres effectuant l'insertion, la mise à jour et la suppression de données (un seul ordre pour effectuer chacune de ces fonctions) ;
indépendance des programmes vis-à-vis de l'implantation physique des données ;
indépendance des programmes vis-à-vis de l'implantation logique des données (si les informations manipulées par les programmes n'ont pas été modifiées ou supprimées) ;
les contraintes d'intégrité doivent pouvoir être définies dans le langage relationnel et enregistrées dans le dictionnaire des donnés ;
indépendance vis-à-vis de la répartition des données sur divers sites ;
on ne peut jamais contourner les contraintes (d'intégrité ou de sécurité) imposées par le langage du SGBD en utilisant un langage de programmation de plus bas niveau.

Le modèle relationnel élaboré dans les années 1960 a fait l’objet de très nombreuses recherches qui ont débouché sur la réalisation de nombreux SGBD relationnels : c’est de loin le modèle le plus utilisé par les SGBD actuellement disponibles.

Sa popularité doit beaucoup à sa simplicité par rapport au modèle entité association tant sur le plan théorique (théorie de la normalisation, définition de langages de manipulation de données), que sur celui des réalisations.

Mais cette simplicité est aussi sa faiblesse principale: c’est un outil trop pauvre sémantiquement pour pouvoir bien représenter la complexité du monde réel. C'est la raison pour laquelle d'autres modèles de type entité association ou orientés objets ont été proposés par la suite.

Les concepts fondamentaux du modèle relationnel

La relation

Les objets et associations du monde réel sont représentés par un concept unique la relation.

Les relations sont des tableaux à deux dimensions, appelés tables.

Considérons des données modélisant la table livre, on peut dégager la relation suivante :

ISBN	Auteur	Titre	Prix
9782738108395	Samuel P. Huntington	Le choc des civilisations	25
2-213-02191-0	Nicolas Grimal	Histoire de l’Égypte ancienne	42
2-89448-084-9	Jacques Lacoursière	Histoire populaire du Québec	15

Vocabulaire d'une relation

De manière générale, le MCD se décrit comme le présente le tableau suivant.

	attributs
R = (	A₁	A₂	…	A_$n$	)	Intention
					}	Extension

N-uplet ou tuple	D₁	D₂	…	D_$n$

						↓
	Domaine (D_$i$)	→				$i$ R - Instance de R

La relation est noté R et se compose de n attributs (cellules aux fonds mauve).
L'ensemble des attributs forment l’intention (cellules entourés de pointillés bleus).
Chaque ligne de la base est un $n$ -uplet ou tuple conforme à l'intention (les cellules entourés de pointillés rouge correspondent à un tuple).
L’extension désigne la totalité des lignes que contiens la base.
Un domaine $i$ désigne la totalité des valeurs que contiens la base pour un attribut $i$ donné (par exemple les cellules aux fonds vert).
L'ensemble des domaines de toutes l'extension forment une instance de R.

On dit que La structure de la table est équivalente à $\Pi {\text{ dom}}(D_{i})$ pour une relation R.

Exemples

Étudiant
Nº Étudiant	Nom	Prénom	Date de naissance
42	Douglas	Adams	15/10/1999
136	Bombadil	Tom	07/02/2000
253	Durand	Jean	30/08/1998
294	Blaise	Pascal	24/01/1999

Cet exemple représente une relation (ou table) décrivant des étudiants.

Étudiant est le nom de la relation.

Les entêtes des colonnes, Nº Étudiant, Nom, Prénom et Date de naissance, sont les attributs de la relation.

Chaque ligne de la table correspond à une occurrence.

Par exemple: <253, Durand, Jean, 30/08/1998> constitue un n-uplet ou tuple, qui décrit une occurrence (l'étudiant Jean Durand). Il est usuel de souligner l'attribut, ou les attributs, qui constituent l'identifiant de la relation.

Cours
Nom_cours	Horaire	Prof
mathématique	Lundi 10-12	Pythagore
physique	Mardi 16-17	Einstein

Suit
Nº Étudiant	Nom_cours
294	physique
42	Mathématique

On remarque que l'identifiant de la relation Suit (qui traduit un type d'association) est composé des identifiants des deux relations précédentes. Cette relation Suit exprime le lien entre un étudiant, désigné par son numéro, et un cours, désigné par son nom. Si on avait utilisé le modèle entité association, les relations Étudiant et Cours auraient été modélisées par des types d'entité, Étudiant et Cours, alors que la relation Suit aurait été modélisée par un type d'association reliant ces types d'entité.

Domaine

Domaines

un domaine est un ensemble de valeurs D non vide, caractérisé par un nom, que peut prendre un attribut.

Par exemple :

les couleurs = { Vert; Jaune; Rouge} ;
les nombres entiers = {1; 2; 3; …} ;
les pays = {France; Italie; …} ;
les montants = {Réel} ;
un salaire = {4 000..100 000} ;
un Nom = Chaîne de caractères.

En revanche, les valeurs multivaluées sont interdites :

POINT = {(X:REEL;Y:REEL)} ;
TRIANGLE = {(P1:POINT;P2:POINT;P3:POINT)}.

Comme pour les ensembles un domaine se définit soit :

en extension : en donnant la liste des ses valeurs ;
en intention : en donnant une propriété caractéristique des valeurs du domaine.

Les domaines ENTIER, RÉEL, BOOLÉEN, CARACTÈRES fixe ou variable sont définis en intention.

Il est possible de définir en intention des domaines tels que RÉEL avec 2 chiffres après la virgule, DATE un entier sur 6 chiffres JJMMAA^[1], ou 8 chiffres JJMMSSAA, etc.

Un domaine peut être défini en extension les pays = {France, Italie, …}, etc.

Le produit cartésien

Le produit cartésien d'un ensemble de domaine $D_{1},D_{2},\dots ,D_{n}$ D1, D2, …, D_$n$ est l’ensemble des vecteurs $<V_{1},V_{2},V_{3},\dots ,V_{n}>$ où pour $i$ variant de 1 à $n$ , $V_{i}$ est une valeur de $D_{i}$ .

Exemple :

Agenda = jour × heure
Jour = {Lundi, mardi, …}
Heure = {7 h, 8 h, 9 h, …}
Agenda = {(Lundi,7 h), (Lundi,8 h), (Lundi,9 h), …, (Mardi,7 h), (Mardi,8 h), (Mardi,9 h), … }

Est composé de $T$ vecteurs tel que $n$ vecteurs de Jour × $m$ vecteurs de Heure

Le langage SQL que nous verrons plus loin se base sur le produit cartésien. Retenez donc que l’on peut toujours transcrire un produit cartésien en requête SQL^[2]. Le tableau ci-dessous montre la transcription de quelques opérations d'un formulation à l'autre.

Produit cartésien	Requête SQL équivalente
$R\times S$	SELECT R., S. FROM R, S;
$R_{1}\times R_{2}\times R_{3}\times \dots \times R_{n}[C_{1},C_{2},\dots ,C_{m}]$	SELECT C1, C2, C3, …, Cm FROM R1, R2, R3, …, Rn WHERE F

La forme d'une requête d'interrogation SQL est la suivante^[3] :

SELECT [ ALL | DISTINCT ] expression-d'attributs [ AS nom_d_affichage  [, ...]
   FROM relation [variable] [, ...] 
   [ WHERE condition ]
   [ GROUP BY liste-d'attributs [, ...] ]
   [ HAVING condition [, ...] ]
   [ ORDER BY liste-d'attributs [ ASC | DESC | USING opérateur ] [ NULLS { FIRST | LAST } ] [, ...] ]
   [ LIMIT { nombre | ALL } ];

Le principe général de l'évaluation d'une requête permet de comprendre la sémantique que SQL attribue aux requêtes. Le système analyse et exécute les requêtes dans l’ordre suivant :

évaluation de la clause from en faisant le produit cartésien de toutes les relations qui apparaissent ;
évaluation de la clause where qui réalise les restrictions et les jointures ;
évaluation de la clause group by qui constitue les partitions ;
évaluation de la clause having qui sélectionne les partitions désirées ;
évaluation de la clause select qui constitue la projection finale ;
évaluation de la clause order by qui trie les tuples du résultat final.

Relations

Une relation est définie par

son nom ;
liste de couples (nom d'attribut : domaine) ;
son (ses) identifiant(s) ;
sa définition (phrase en français).

Les trois premières informations: nom de la relation, liste des couples (attribut : Domaine) et identifiant(s) constituent le schéma de la relation.

Exemple dans le précédent schéma de la relation Étudiant : Étudiant (Nº Étudiant : Dnum, Nom : Dnom, Prénom : Dnom, Age : Dâge)

La population d'une relation est constituée de l’ensemble des tuples de la relation. C'est un ensemble ; il n'y a donc ni doubles, ni ordre (les nouveaux tuples sont rajoutés à la fin de la relation).

On appelle schéma d'une base de données relationnelle l’ensemble des schémas de ses relations. On appelle base de données relationnelle, la population de toutes ses relations.

Sous ensemble d'un produit cartésien, de ses domaines de valeurs.

Organisation logique de la base de données
Réalité		Information		Données
Entité ↓ ↓ ↓	Sous schéma		Schéma
Caractéristiques	→	Attributs ↓ ↓ ↓	→	Éléments de données ↓ ↓ ↓
		Valeur d'un attribut		Valeur d'un élément de données sur le système de rangement

Règles de modélisation

Les attributs sont tous simples et monovalués : toute valeur prise par un attribut pour un tuple est atomique (non décomposable par le SGBD) et unique.

Les notions d'attribut multivalué, complexe ou facultatif, n'existent pas dans le modèle relationnel.

Retenez bien que les attributs sont simples et monovalués (domaine de valeurs atomiques) avec une structure plate régulière.

Exemple de tuples correctement structurés
x	x	x	x	x	x	x
y	y	y	y	y	y	y
…
z	z	z	z	z	z	z

Exemple de **construction interdite**
x	x	x	x	x	x	x
y	y	y₁	y	y	y	y
		y₂
…
z	z	z	z₁	z	z	z
			z₂

Cas d'un attribut facultatif du modèle entité association

Certains SGBD relationnels gèrent une valeur spéciale, appelée valeur nulle notée « ? ». Cette valeur peut être prise par tout attribut (sauf si dans le schéma on a spécifié le contraire) ; elle signifie alors que le tuple n'a pas de valeur pour cet attribut. Par exemple, un étudiant, Marc Dumont, de numéro 123, dont on ne connaîtrait pas l'âge, serait représenté par le tuple: $<123,{\text{ Dumont}},{\text{ Marc}},?>$ .

Une telle solution implique un traitement particulier de cette valeur nulle dans les langages de manipulation des données.

À l'opposé, les attributs obligatoires sont traduits lors de la création de la table en SQL par la clause NOT NULL.

Cas d'un attribut complexe du modèle entité association

Soit par exemple, un attribut complexe en entité association, Adresse, composé des attributs: nº rue, nom rue , ville, code-postal.

Si on veut ajouter cet attribut dans la relation Étudiant, il y a deux solutions types de solutions possible :

ajouter l'attribut Adresse qui a pour domaine les chaînes de caractères. Dans ce cas, l'utilisateur ne peut pas poser de questions sur la ville, il devra lire l'adresse et chercher dans la chaîne de caractères le nom de la ville lui-même, ou par programme.
ajouter les attributs suivants : nº rue, nom-rue, ville, code-postal à la relation. Le SGBD connaît le détail de l'adresse, mais ne connaît pas la notion globale d'adresse.

La solution est choisie en fonction du type d’utilisation de l'attribut.

Cas d'un attribut multivalué du modèle entité association

Il est parfois utile de scinder un attribut. Par exemple, on veut mémoriser les différents prénoms des étudiants (et non pas uniquement leur premier prénom).

On pourrait ajouter plusieurs attributs dans la relation Étudiant : Prénom1, Prénom2, …

Mais l’on ne connaît pas à l'avance le nombre valeurs : combien mettre d'attributs Prénom ? Comment poser des questions sur cet attribut ? Il faudrait logiquement poser autant de questions que d'attributs déclarés ! C'est une mauvaise solution à ne pas utiliser.

Une bien meilleur approche consiste à garder Nº Étudiant, Nom, Age pour la relation Étudiant, et de créer une relation supplémentaire, EtudPrénoms :

La table EtudPrénoms
Nº Étudiant	Prénom	Rang
12	René	1
22	Jean	1
28	John	1
28	Ronald	2
28	Reuel	3
78	1
78	2
105	Simon	1

Identifiant d'une relation

Idendifiant

L'identifiant (aussi appelé clé) d'une relation est un ensemble minimum d'attributs de la relation, tel qu’il n'existe pas deux tuples ayant même valeur pour cet identifiant.

C'est un ensemble minimum d'attributs tel que tous les autres attributs en dépendent fonctionnellement.

Un identifiant peut-être composé d'un ou plusieurs attributs. Une relation peut avoir un ou plusieurs identifiants. Une relation étant un ensemble, elle a toujours un identifiant qui, dans le cas le plus défavorable, est composé de tous les attributs de la relation. Par convention, les attributs servant identifiant sont soulignés.

Dans Étudiant (Nº Étudiant, nom, prénom, âge), on pourra utiliser Nº Étudiant car il n'y a pas deux étudiants qui ont le même numéro.

On ne peut pas avoir de valeur inconnue (notée « ? ») pour un identifiant (on entre obligatoirement un numéro d'étudiant). Si on entrait deux tuples sans Nº Étudiant, alors il existerait deux étudiants avec la même valeur pour l'identifiant (valeur inconnue), ce qui est impossible d’après la définition de l'identifiant. On a donc la règle suivante : tous les attributs de tout identifiant doivent toujours avoir une valeur connue.

Par exemple tenter d'insérer < ?, Rochat, Jean, 19> dans Étudiant devrait aboutir sur un refus du SGBD.

Identifiant externe

Certains attributs référencent des tuples d'une autre relation (ou parfois de la même); c'est-à-dire que leur valeur est toujours égale à celle de l'identifiant d'un tuple existant dans l'autre relation. On les appelle identifiants externes (ou clés externes ou clés étrangères).

Par exemple, la relation Suit(Nom_Cours, Nº Étudiant) possède un identifiant (Nom_Cours + Nº Étudiant), et deux identifiants externes : Nom_Cours et Nº Étudiant. En effet, Nom_Cours référence un Cours, c'est-à-dire que si une valeur Nom_Cours existe dans Suit, alors il doit nécessairement exister un cours de ce nom là dans la relation Cours. De même, Nº Étudiant référence un Étudiant.

Le schéma d'une relation comprend donc, en plus de la définition du nom de la relation et de ses attributs et domaines associés, la définition de son (ses) identifiant(s), et celle de ses identifiants externes, s'il en existe.

Les identifiants externes sont déclarés de la façon suivante: Suit(Nom_Cours : Dnom, Nº Étudiant : Dnum)

Dans le cas où la relation référencée possède plusieurs identifiants il faut préciser lequel. La clause est alors: Nº Étudiant référence un Étudiant•Nº Étudiant.

Soient deux relations $R_{1}(X,Y)$ et $R_{2}(V,W)$ , où $X,Y,V,W$ , désignent des attributs ou des ensembles d'attributs, et où $X$ est un identifiant de $R1$ ,

on dit que $W$ est un identifiant externe sur $R_{1}$ (ou que $W$ référence $R1$ ) si pour tout tuple de $R2$ , la valeur prise par $W$ est nécessairement la valeur de $X$ pour un tuple existant de $R_{1}$ .

Autrement dit, à tout instant, l’ensemble des valeurs prises par $W$ est compris dans l’ensemble des valeurs prises par $X$ .

Vérification automatique assurée par le SGBD

Une fois déclaré l'identifiant externe $W$ de $R_{2}$ sur $R_{1}$ , le SGBD vérifie toutes les insertions dans $R_{2}$ (il vérifie que la valeur de $W$ existe dans $R_{1}$ );

il vérifie de la même façon les modifications de $W$ . Il vérifie toutes les suppressions de tuples de $R_{1}$ (il vérifie qu’il n'existe pas de tuple dans $R_{2}$ référençant ce tuple à supprimer).

Le SGBD assure ainsi, l'intégrité de référence (ou intégrité référentielle) de la base de données.

Prédicats

Pour une relation, il n'existe qu'un prédicat.

Cela signifie qu’il n'y a qu'une seule interprétation possibles des données.

Soit : !! Étudiant = (n, p, s, o, d) !!

Il s'agit d'un étudiant portant le nom n, le prénom p, de sexe s, d'origine o et de date de naissance d.

Un tuple de la relation tel que !! R(r1,r2, …) !! est vrai.

Etudiant = ("IRR","PAUL","M","CH","16/08/1983")

Le prédicat définit la sémantique reliant les constituant : !! R(A1,A2,…An)!!

Nous arrivons maintenant, à deux définitions importantes :

Intention

L'intention est le résultat de la description des données.

Extension

L'extension est le résultat des manipulations sur les données et représente un état de la base à un instant donné.

Une extension de la relation est aussi appelé instance de la relation.

Attention le prédicat s'énonce à partir de l'intention et non pas de l'extension.

L'extension elle doit satisfaire à la règle que décrit le prédicat à tout moment.

Conclusion

Nous avons vu qu'un schéma relationnel se compose pour chaque relation :

d'un nom (celui de la relation) ;
d'une définition ;
d'attributs et de domaines ;
d'au moins un identifiant ;
d'éventuelles identifiants externes ;
de contraintes d'intégrité associées à cette relation ;
des autres contraintes d'intégrité qui portent sur plusieurs relations.

Notes et références

Sur les autres projets Wikimedia :

↑ Avec J pour jour, M pour mois et A pour année
↑ L'inverse n’est pas forcément vrai, nous verrons plus loin pourquoi.
↑ Il s'agit là d'une présentation non exhaustive proche de la forme standard, mais les implémentations peuvent varier.

Introduction aux systèmes de bases de données

Introduction

Dépendances fonctionnelles et normalisation

[1] Avec J pour jour, M pour mois et A pour année

[2] L'inverse n’est pas forcément vrai, nous verrons plus loin pourquoi.

[3] Il s'agit là d'une présentation non exhaustive proche de la forme standard, mais les implémentations peuvent varier.

[1]

[2]

[3]