Niveau logique : les bases de données relationnelles

Qu'est-ce que le formalisme « logique » d'une BDD ?¶

Définition : Modèle logique

Modèle formel qui spécifie la manière dont les données vont exister dans l’application (alors que le modèle conceptuel spécifie la réalité existante).

Définition : Modèle relationnel

Ensemble de concepts destinés à formaliser logiquement l’utilisation de fichiers plats indépendamment de la façon dont ils seront physiquement stockés dans la mémoire numérique.
Il existe d'autres modèles logiques que ceux « relationnels ».

Intérêt de ce modèle logique :

Indépendance entre la représentation interne des données et l’application.
Gestion des problèmes de cohérence et de redondance des données.
Utilisation de langages basés sur des théories solides.

Définitions principales¶

Définition : une Table

Ensemble de valeurs organisé sous forme de lignes et colonnes, et stocké dans un fichier unique.
Chaque ligne caractérise un et un seul objet, individu, évènement, etc., par un ensemble de valeurs : elle constitue un enregistrement.
Toutes les lignes caractérisent des objets, individus, évènements de même nature.
Chaque colonne correspond à un champ caractérisant ces objets, individus ou évènements.

Définition : un Champ

C'est une caractéristique (attribut) commune à l'ensemble des objets décrits par la table.
Elle est associée à une colonne, qui contient toutes les valeurs prises par cette caractéristique, sur l'ensemble des objets décrits.
Ses valeurs sont définies par un domaine, par exemple : les âges possibles, les noms d'arbres, les numéros INE, etc.

Définition : un Enregistrement

Ligne d'une table : c'est l'ensemble des caractéristiques d'un des objets décrits par la table.

Exemple de table décrivant des étudiants (peintres)

Etudiant

NumeroINE	Nom	Prenom	NumeroStage
140116244795612	Dali	Salvador
150086238218665	Picasso	Pablo	42

Les clés : primaires et étrangères¶

Intérêt des clés¶

Au sein d'une table, chaque enregistrement caractérise un objet unique, et chaque objet est caractérisé par un unique enregistrement.
Il arrive fréquemment que des enregistrements - en fait, leurs objets correspondants - de 2 tables différentes soient liés : pour cela, on place dans l'un des enregistrements une référence à l'autre.
Cette réference doit être absolument non-ambiguë : elle doit désigner l'unique enregistrement que l'on souhaite lier au premier.
Cette référence doit donc être un identifiant de la table : dans une BDD relationnelle, les clés sont des identifiants d'enregistrements (définis au niveau de la table).

Définitions¶

Définition : Clé primaire (et clés secondaires)

Dans une table, c'est un ensemble minimal de champs (colonnes) qui constitue un identifiant de ses enregistrements.
Ce peut être un champ simple, ou une combinaison de champs.
Dire qu'elle « constitue un identifiant » signifie que 2 objets décrits par la table ont forcément des clés primaires distinctes : ses valeurs sont uniques.
- Autrement dit, pour une clé primaire donnée, il n'existe qu'une seule ligne possible dans la table.
Si une table est munie d'une clé primaire (c'est souvent souhaitable), alors tous les enregistrements ont obligatoirement une (valeur de) clé primaire.
Quand il y a plusieurs clés primaires possibles dans une table, on en choisit une. Les autres sont appelées clés secondaires.

Exemple : clé primaire

Dans la table Etudiant précédente, c'est le champ souligné : NumeroINE.
C'est bien une clé primaire, car :
- il est impossible que 2 étudiants aient le même numéro INE,
- chaque étudiant en a obligatoirement un.

Définition : Clé étrangère

Dans une table, c'est un champ, ou une combinaison de champs, qui contient des copies de clés primaires (ou secondaires) d'une autre table.
Chaque valeur de ce champ désigne donc - sans ambiguïté - un unique enregistrement de l'autre table : il sert de référence.
Les liens ainsi établis entre enregistrements sont contrôlés lors des modifications de données : il ne peut y avoir de liens cassés.

Exemple : clé étrangère

Dans la table Etudiant précédente, il y a une seule clé étrangère : c'est le champ « fléché » : NumeroStage=>Stage. C'est une clé étrangère « vers » la table Stage.
Notez que le premier enregistrement d'étudiant n'a pas de valeur de clé étrangère : c'est simplement qu'aucun stage ne lui est (encore ?) associé.
La présence de la valeur 42 signale en revanche l'existence d'un (unique) enregistrement de la table Stage portant le numéro 42 (sa clé primaire numeroStage vaut 42).

Les contraintes d'intégrité¶

Un SGBD est capable de garantir des contraintes d'intégrité sur la base de données relationnelles, de manière à lui assurer certaines formes de cohérence. Les différentes clés représentent de telles contraintes.

Définition : contrainte d'intégrité de clé primaire

Ses valeurs sont présentes et uniques.
Ainsi, tous les enregistrements sont distincts, et il est possible de les référencer sans ambiguïté.

Définition : contrainte d'intégrité de clé étrangère

Toute valeur (définie) de clé étrangère désigne un unique enregistrement, nécessairement existant.
Autrement dit, sa valeur se trouve parmi celles de la clé primaire de la table désignée.
Cette contrainte s'appelle : contrainte référentielle.
Cela assure une cohérence du lien existant entre les 2 enregistrements : il ne peut y avoir de lien « cassé », même lors des modifications ou suppressions de données.

Détermination des clés primaires¶

On s'efforce en général de définir une clé primaire dans chaque table.
Ce n'est pas en regardant le contenu d'une table à un instant donné que l'on peut déduire sa clé primaire possible
Cela dépend en effet du contexte, de la sémantique des champs de la table.
Ainsi, « on sait » que :
- le NumeroINE est un bon candidat ;
- la combinaison (Nom, Prenom) n'est pas un bon candidat.

Détermination des clés étrangères¶

C'est toute la difficulté de la conception (logique) d'une base de données relationnelles, que de proposer des tables liées entre elles, comportant toutes les informations, avec une redondance minimale.

Une bonne modélisation conceptuelle permet en général de dériver un bon schéma relationnel.

Nous n'aborderons donc pas ce sujet ici, mais dans la partie sur la modélisation conceptuelle.

Schéma relationnel¶

Jusqu'ici nous avons fait l'amalgame. Mais désormais, on distinguera le schéma et le contenu d'une table.

Définition : Schéma d'une table

C'est sa structure logique. Soit l'ensemble de :

ses champs,
et de ses clés : clé primaire et clés étrangères.

Définition : Contenu d'une table

C'est l'ensemble des enregistrements qu'elle contient à un instant donné.

Pour représenter la structure d'une base de données relationnelle, on utilise donc les schémas des tables.

Définition : Modèle Logique de Données (MLD) = schéma relationnel d'une base

C'est une représentation des schémas des tables de la base.
Elle mentionne chaque table, avec leurs champs, et leurs clés (primaires, étrangères et secondaires) et les liens entre elles.
Un schéma relationnel est soit graphique, soit littéral, comme vu dans l'introduction.

Exemple : schéma relationnel d'une base (MLD)

Citoyen(Numero:entier, Nom:chaine, (CodepostalNaissance, NomVilleNaissance)=>Ville )
Etat(Nom:chaine, Population:entier, Superficie:entier, NumeroChefDetat=>Citoyen )
Region(Nom:chaine, Etat=>Etat, Superficie:entier )
Ville(Codepostal:CP, Nom:chaine, (NomRegion, EtatRegion)=>Region )
- où CP = « 1 ou 2 lettres – entier »