Le SGBDR

Introduction au modèle relationnel

Sans toujours nous en douter, nous sommes cernés par les bases de données (BDD) : publicités ciblées via Internet, proposition de vidéos sur TikTok, mailings, etc.

Si les BDD structurées sont devenues omniprésentes, c’est parce qu’elles sont exploitées avec des outils efficaces. En particulier, le modèle relationnel offre un cadre d’une telle souplesse qu’il est vite devenu archi-dominant.

Historique

C’est en 1970 qu’Edgar F. Codd définit le modèle relationnel à partir de la théorie des ensembles. Celle-ci repose sur le concept de relation (relations d’appartenance, d’inclusion…).

Les systèmes de gestion de base de données relationnels (SGBDR), qui sont des logiciels basés sur ce modèle, furent commercialisés dix ans plus tard.

Aujourd’hui le modèle relationnel répond à la très grande majorité des besoins ; les autres types de modèles (réseaux, hiérarchiques, BD objets…) se rencontrent assez peu.

Quelques définitions

Une table est typiquement ce qui peut être présentée sur la feuille de calcul d’un tableur. Elle contient des éléments de même nature (par exemple une table sur les caractéristiques de clients : code client, nom, adresse...). Le terme de relation est presque un synonyme de table. L’un est une notion mathématique quand l’autre renvoie à sa représentation visuelle. L’algèbre relationnelle s’appuie sur des opérations définies sur les relations.

En colonnes figurent les caractères d’un type d’objet. Ce sont ses attributs. Dans une étude statistique, on parlerait de variables. Chacun son jargon. Un attribut est associé à un format particulier, par exemple une chaîne de caractères, un nombre avec deux décimales, un code alphanumérique à \(n\) caractères, etc. Le nombre d’attributs d’une relation est son degré.

Un domaine est l’ensemble fini ou infini des valeurs qui peuvent être prises par un attribut. Par exemple {Homme ; Femme}. Ce peut aussi être un intervalle numérique et cette notion vous rappellera sans doute celle de l’ensemble de définition d’une fonction (que l’on appelait jadis domaine de définition).

Mathématiquement, la réalisation d’une relation (c’est-à-dire le contenu d’une table) est un sous-ensemble du produit cartésien d’un certain nombre de domaines.

Chaque ligne d’une table est un enregistrement (ou tuple, ou vecteur, ou n-uplet). En statistiques, les lignes correspondent aux observations. Mais il ne faut pas confondre ces deux notions. Notamment, il ne peut y avoir deux lignes identiques dans une table (nous y reviendrons) alors que des données statistiques peuvent tout à fait comporter des observations semblables. La cardinalité d’une relation est son nombre de tuples.

L’ordre des tuples, comme celui des attributs, n’a aucune importance.

Exemple : le 5-uplet {20231228012, 0412, KL202, 2, 49.44} issu de la table Commandes (num_commande, réf_client, réf_produit, quantité, prix_unitaire). Ainsi, si l’on souhaite connaître le chiffre d’affaires annuel, on opère une sélection de tuples sur le numéro de commande (les quatre premiers caractères correspondent à l’année) puis on calcule la somme des prix multipliés par les quantités. On appelle projection le fait de retenir certains attributs, en l’occurrence quantité et prix_unitaire (les références de produit et de client ne sont pas utilisées pour calculer un chiffre d’affaires).

Une BDD relationnelle contient plusieurs tables reliées entre elles. Physiquement, les données peuvent se trouvées éparpillées en plusieurs lieux, contrairement au contenu d’une feuille de calcul qui se trouve au même endroit.

Ainsi, un bon de commande lie un ou plusieurs produits avec un client. Une commande est donc une relation issue d’autres relations. Celle-ci ne comporte que les attributs utiles à l’établissement du bon de commande.

Règles d’intégrité

Afin de respecter la cohérence des données, les mises à jour doivent respecter des règles incontournables.

• Contrainte de relation : une clé permet d’identifier à coup sûr chaque enregistrement puisqu’elle est unique, stable et jamais nulle. C’est donc un attribut un peu spécial (ou un ensemble d’attributs). Par exemple, un matricule ou un numéro de client sont uniques contrairement à un nom de famille. Un enregistrement peut en avoir plusieurs et la clé par défaut est appelée clé primaire. Une clé multiple (ou composite) est constituée de plusieurs attributs. Dans l’exemple donné plus haut, la table créée pour connaître le chiffre d’affaires aurait deux clés, le numéro de commande et la référence du produit, puisqu’une commande peut comporter plusieurs produits. Elle n’aurait pas de clé primaire.


• Contrainte de référence : une clé étrangère est un attribut d’une table qui est clé primaire dans une autre (dite table primaire). Elle fait le lien mais n’est généralement pas une clé. La table primaire ne peut pas être supprimée et sa clé primaire ne peut pas être modifiée.


• Contrainte de domaine : chaque colonne d’une relation vérifie un lien logique (appartenance à un domaine). Par exemple, un poids s’exprime par un nombre positif compris dans une certaine fourchette de valeurs.

Le schéma relationnel

Le schéma de relation modélise l’ensemble des évolutions possibles d’une relation, compte tenu des contraintes. Par extension, le schéma relationnel est l’ensemble des schémas intra et inter relations.

On peut le représenter de façon textuelle ou sous forme de diagramme. Ce dernier est le MLD-R (Modèle Logique des Données Relationnel), outil propre aux SGBDR. C’est une représentation visuelle de l’organisation des données.

SQL

Autre outil, le SQL C’est le langage le plus habituel pour manipuler et gérer la BDD. Le SQL est une codification de l’algèbre relationnelle.

Quelques SGBDR

Les SGBDR commerciaux les plus connus sont Oracle, DB2, Microsoft SQL Server… SAP IQ est le SGBDR de SAP. Access est le SGBDR inclus dans la suite Microsoft 365.

Parmi les SGBDR libres : mySQL, PostreSQL, SQLite (pour BDD relationnelle embarquée)…

Le lien suivant vous mènera à la présentation en français du SGBDR par IBM. Vous y trouverez de nombreuses informations mais aussi un lien vers le fameux article d’Edgar F. Codd fondateur du modèle relationnel (en PDF).

https://www.ibm.com/fr-fr/topics/relational-databases