Base de données relationnelle
Un article de Wikipédia, l'encyclopédie libre.
|
Système de gestion de Base de données |
|
Une base de données relationnelle est une base de données structurée suivant les principes de l’algèbre relationnelle. La théorie des bases de données relationnelles est due à Edgar Frank Codd.
Remarque : l'adjectif relationnel ne fait pas référence ici aux relations entre les tables mais aux tables elles-mêmes.
Elle est mise en œuvre au moyen d’un Système de Gestion de Bases de Données Relationnelles (SGBDR).
Sommaire |
[modifier] Principe
Le concept permet de stocker et d’organiser une grande quantité d’informations. Les SGBD (Système de Gestion de Base de Données) permettent de naviguer dans ces données et d’extraire (ou de mettre à jour) les informations voulues au moyen d'une requête.
Les données apparaissent comme stockées dans des tables qu'on peut mettre en relation. Une table elle-même est une relation, mais entre les différents champs qui la composent.
Ce système se démarque donc totalement en termes d’interface des bases de données de type hiérarchique, même si au plan de l'implémentation et, en fonction des statistiques d’accès à la base, un modèle hiérarchique sera utilisé, qui n’aura jamais besoin d’être pris en compte par l’utilisateur. De plus les données d'une table sont souvent subordonnées à un des champs (une clé).
Ce modèle relationnel conduit à :
- Une grande simplicité d’usage
- Une transparence pour l’utilisateur de toute réorganisation technique de la base (la seule différence pour l’utilisateur se situera, si l’opération est réussie, dans les temps de réponse).
- Une facilité de combinaison du contenu de plusieurs tables (opération join ou jointure).
Les tables possèdent un certain nombre de colonnes ou champs permettant de décrire des n-uplets (lignes ou enregistrements). La non-duplication (absence de redondance) des n-uplets est théoriquement assurée par le SGBDR.
Dans les relations, il est possible de définir deux types de clés :
- clé primaire
- permet d’identifier un et un seul n-uplet (par exemple le numéro de sécurité sociale).
- clé externe
- c’est un attribut d’une relation qui est clé primaire dans une autre relation. Elle permet donc de lier deux tables entre elles.
Pour accéder aux données, on utilise différents opérateurs logiques, notamment la sélection (ou projection), mais aussi les jointures (dont il existe différents types).
Les opérations sont communiquées sous forme de requêtes aux SGBDR (Système de Gestion de Base de Données Relationnelle). Le SGBDR convertit les requêts SQL en expressions relationnelles pour pouvoir effectuer les opérations sur les tables La plupart utilisent le langage normalisé SQL ou le TCL pour les SGBDR Multivalué.
Dans une base de données relationnelle, le but est de séparer les informations au maximum pour éviter les doublons et la redondance, et d'empêcher la perte de qualité d’information (par exemple, l'adresse d'un fournisseur n'est mise à jour qu'une et une seule fois : la modification sera alors prise en compte sur l'ensemble des courriers).
[modifier] Détails techniques
Dans la table PERSONNE ci-dessous, l’ensemble {PersID, nom, prénom, date_naiss, ville_naiss} est un ensemble d'attributs. Chaque attribut définit une information élémentaire à l’intérieur d’une ligne (aussi appelée tuple) de la table. Il ne peut exister deux fois le même tuple dans une relation. Les attributs sont parfois aussi appelés colonnes.
On peut définir des clés, qui sont des contraintes d’intégrité portant sur une relation. Elles consistent à imposer qu’il ne puisse exister deux tuples ayant même valeur pour un sous-groupe d’attributs (la clé) de la relation. Si on reprend l’exemple de la table PERSONNE, la clé pourrait être PersID, donc deux tuples différents ne pourraient pas avoir une même valeur pour l’attribut PersID (mais les valeurs des autres attributs peuvent être identiques).
Certaines clés sont dites clés étrangères ; ce sont des contraintes d’intégrité portant sur une relation R1, consistant à imposer que la valeur d’un groupe d’attributs apparaisse comme valeur de clé dans une autre relation R2. Si l’on reprend l’exemple des deux tables PERSONNE et VILLE, la clé étrangère de la table PERSONNE pourrait être ville_naiss, qui pointe sur la table VILLE. Il est impératif que le nombre d’attributs formant la clé étrangère de la table R1 corresponde au nombre d’attributs formant la clé primaire de la table R2.
Ces clés étrangères sont issues du processus de normalisation du modèle des données.
Lors de l’implémentation d’une base de données, il faut penser à certains aspects :
- Personne ne doit pouvoir mettre à jour des données dans une table pendant qu’une autre personne les modifie déjà, car cela pourrait aboutir à des incohérences. Un système comme Paradox l’autorise cependant grâce à un mécanisme ingénieux mettant à jour automatiquement tous les affichages en cours au même instant.
- Les transactions sont atomiques, c’est-à-dire qu’en cas de panne majeure du système informatique au milieu d’une modification, un mécanisme doit permettre d’annuler les transactions en cours si elle n’ont pas pu être exécutées totalement (mécanisme dit du COMMIT).
- Des vérifications d’intégrité doivent assurer que chaque valeur inscrite dans un tuple soit une valeur permise (par exemple, on peut interdire de mettre une valeur supérieure à 12 dans un attribut « mois »).
Exemple :
|
On a une table « personne » contenant le nom, le prénom, la date de naissance et la ville de naissance pour chaque personne. Une ligne de la table contiendra donc les informations relatives à une personne. |
note : ici ville_naiss est une clé étrangère (table VILLE) |
||||||||||||||||||||||||||
|
De même, on a une table « ville » contenant la population et la superficie de chaque ville. |
note : ici region est une clé étrangère (table REGION) |
||||||||||||||||||||||||||
Si on veut pouvoir connaître, pour chaque personne, la population et la superficie de sa ville de naissance, il est utile, au lieu de stocker le nom de la ville de naissance dans la table « personne », de stocker un identifiant (clé étrangère) se référant à un numéro unique pour chaque ville (clé primaire). Ainsi, les informations concernant chaque ville sont stockées unitairement.
Un des langages utilisés pour construire des requêtes permettant d’interroger et de manipuler les données des bases de données relationnelles est le langage SQL. Pour reprendre notre exemple, SQL sert à formaliser des questions (requêtes) du type : « Quelles sont toutes les personnes nées dans la ville X » ou « Dans quelle ville est né Dupont ».
[modifier] Améliorations
- SQL n’étant pas exactement proche de la formulation intuitive d’une requête contrairement au TCL (voir système d'exploitation Pick), deux approches sont utilisées pour s’en affranchir :
- création de langages frontaux traduisant en SQL des phrases simples du genre : « Lister par région le chiffre d’affaires moyen de chaque produit »
- création de requêtes en remplissant un formulaire avec les conditions qu’on souhaite voir vérifiées et en laissant vierges les autres champs (Query by example)
SQL n'est cependant pas incontournable à ce jour pour effectuer des requêtes générales très complexes. Plusieurs systèmes affichent dans un premier temps en réponse à une requête complexe son coût prévisible (en temps ou en ressources d’accès), en demandant à l’utilisateur confirmation ou invalidation préalablement à toute exécution. On peut imaginer en effet sur des bases courantes des requêtes SQL dont l’exécution demanderait des centaines d’heures ou des milliers d’euros. Une réécriture simple suffit souvent à obtenir le même résultat, ou un analogue fonctionnel, de façon bien plus économique. Malgré le succès du langage SQL qui a suivi, Edgar F. Codd dénoncera cet outil qu'il considère comme une interprétation incorrecte de ses théories.
[modifier] Accéder aux données d'un SGBDR
Les SGBDR sont livrés avec des APIs propriétaire (c’est-à-dire propres à chaque SGBDR) pour communiquer avec eux.
Pour permettre d'utiliser une ou plusieurs bases de données avec un logiciel sans devoir récrire le code source, des APIs standardisées pour accéder au SGBDR ont été crées :
Comme il existe une différence conceptuelle entre le monde objet (C++, Java, .Net, etc.) et la représentation relationnelle, il est apparu plusieurs solutions pour les réconcilier. Une solution est le mapping objet relationnel dont le framework open source Hibernate est un des meilleurs exemples pour l'univers Java.[réf. nécessaire]
Ainsi, dans l'univers Java, de nouveaux standards pour l'accès aux SGBDR sont apparus :
[modifier] Historique
- Voici une généalogie des SGBDR.
Les bases de données relationnelles étaient pressenties dans les années 1970 comme remplaçants des fichiers classiques dans les systèmes d’exploitation (voir projet FS). Cela fut implémenté dans les ordinateurs du type IBM Système 38 ou AS/400, ainsi que dans un système d’exploitation nommé Pick, mais sans se généraliser. Les brevets de cette époque étant maintenant dans le domaine public, l’idée redevient d’actualité dans les années 2000 avec le système WinFS (voir Microsoft Windows).
