Tutoriel de Bases de Données Relationnelles

Modèle relationnel de données

Le modèle relationnel de données a été défini en 1970 par Codd et les premiers systèmes commerciaux sont apparus au début des années 80. Le modèle relationnel est simple (3 concepts), facile à appréhender, même pour un non spécialiste et repose sur de solides bases théoriques qui permettent notamment de définir de façon formelle les langages de manipulation associés.

Le modèle relationnel représente l'information dans une collection de relations. Intuitivement, on peut voir une relation comme une table à double entrée, voire même comme un fichier. Chaque ligne de la table (appelée nuplet ou tuple) peut être vue comme un fait décrivant une entité du monde. Une colonne de la table est appelée un attribut.

Définition formelle

• un domaine D est un ensemble de valeurs atomiques. Le terme atomique signifie que ces valeurs sont considérées comme insécables au niveau du modèle.
• un schéma de relation R, dénoté par R(A1, A2, ..., An), est un ensemble d'attributs R = {A1, A2, ..., An}. A chaque attribut Ai est associé un domaine Di, Ai indiquant le rôle joué par le domaine Di dans la relation R. Un schéma de relation décrit une relation et représente l'intension de celle-ci. Le degré de la relation est le nombre d'attributs de celle-ci.

Exemple :  ETUDIANT(Nom, No-ss, adresse, age, diplôme) 

• une relation r sur le schéma de relation R(A1, A2, ..., An) est un ensemble de nuplets r= {t1, t2, ..., tn}. r est souvent appelée extension du schéma R.

 On peut également définir une relation à partir du produit cartésien des domaines de son schéma R :

 r(R) inclus-ou-egal dom(A1) X dom( A2) X ...X dom(An)

Il est important de noter qu'un schéma de relation est quasi invariant dans le temps, alors que l'extension représente les données présentes à un instant donné dans la base.

Caractéristiques des relations

• une relation est un ensemble de nuplets, il n'y a donc pas de notion d'ordre sur les nuplets,
• par contre un nuplet est un séquence ordonnée d'attributs,
• une valeur d'attribut est atomique mais peut être éventuellement nulle (valeur particulière qui indique que la valeur est manquante).

Contraintes d'intégrité

Un schéma de base de données est un ensemble de schémas de relation S = {R1, R2, ..., Rn} et un ensemble de contraintes d'intégrité CI. Une contrainte d'intégrité est une propriété du schéma, invariante dans le temps. On peut distinguer plusieurs catégories de contraintes. Les contraintes structurelles, définissent plus précisément la structure des associations entre les données (le modèle de données les supporte en partie) et les contraintes sur les valeurs donnent des relations entre les données (un chef gagne plus que ses subordonnés). La plupart des contraintes ne sont pas supportées pas le modèle de données et doivent donc être codées par les programmeurs dans des programmes d'application. 

Contrainte d'intégrité sur les clés. Par définition, tous les nuplets d'une relation sont distincts deux à deux (puisqu'il s'agit d'un ensemble). Il est également intéressant de définir des sous-ensembles du schéma qui permettent d'identifier de manière unique un nuplet (par exemple dans l'exemple de l'étudiant, l'attribut No-ss permet d'identifier un étudiant). Ces sous-ensembles du schéma s'appellent des clés. Le système doit donc garantir l'unicité des valeurs de clé (un seul nuplet étudiant peut avoir une valeur de No-ss donnée).

Il peut y avoir plusieurs clés pour une même relation (elles sont alors appelées clés candidates) et on choisit le plus souvent une clé particulière dite clé primaire qui servira d'identification privilégiée des nuplets. Cette clé sera indiquée de manière graphique en soulignant par exemple les attributs la composant.

Par exemple : ETUDIANT(Nom, No-ss, adresse, age, diplôme)

Contrainte d'intégrité sur les entités. Uune clé primaire ne peut contenir de valeur nulle.

Contrainte d'intégrité référentielle. C'est une contrainte exprimée entre deux relations. Intuitivement cela consiste à vérifier que l'information utilisée dans un nuplet pour désigner un autre nuplet est valide, notament si le nuplet désigné existe bien. Par exemple, si on considère une relation EMPLOYE(no-ss, nom, adresse, rôle, no-dept) et une relation DEPARTEMENT(no-dept, nom, no-ss-chef), un nuplet de EMPLOYE référence un nuplet de DEPARTEMENT via l'attribut no-dept (numéro de département) et un nuplet de DEPARTEMENT référence un nuplet de EMPLOYE via l'attribut no-ss-chef (numéro sécurité sociale du chef de département). Il est important de s'assurer que les nuplets référencés existent bien. On peut noter qu'un nuplet peut référencer un autre nuplet de la même relation. Dans ce cas, no-dept et no-ss-chef sont appelés des clés étrangères, puisque se sont des attributs clés d'une autre relation.

Cette contrainte implique un ordre dans la création ou la destruction des entités, puiqu'on ne peut créer un département si le nuplet correspondant au chef n'a pas été créé et on ne peut détruire un chef de département si le département existe toujours (ou bien si on n'a pas mis un autre chef).

Ces contraintes d'intégrité sont exprimées en SQL au niveau du langage de définition.

Les contraintes d'intégrité sont détaillées dans le chapitre concernant la protection des informations.