- Base de données relationnelles
-
Base de données relationnelle
Système de gestion de Base de données
Modèles:- Base de données relationnelle
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 est due à Edgar Frank Codd. Elle est mise en œuvre au moyen d’un Système de gestion de base de données relationnelles (SGBDR).
L'adjectif « relationnel » ne fait pas référence ici aux relations entre les tables mais aux tables elles-mêmes. La relation étant un objet mathématique conteneur de données et l'algèbre relationnelle une collection d'opérateurs appliqué aux relations.
Sommaire
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 de requêtes.
Dans les bases de données relationnelles les données sont structurées logiquement dans des tables qui s'éloignent légèrement de la pure notion mathématique de l'objet relation :
- dans la ligne d'une table certaines informations peuvent être absente (marqueur NULL) alors qu'une relation doit avoir chaque n-uplet (ou tuple) valué;
- la table n'a pas l'obligation de comporter une clef (ce qui signifie en pratique la possibilité de doublons, c'est-à-dire de lignes portant strictement les mêmes informations) alors que la relation doit être sans doublon.
En fait la relation est l'objet mathématique dans la théorie relationnelle, tandis que la table est l'objet logique dans l'univers des SGBDR. Dans la relation on trouve la notion d'attribut et dans la table, la notion de colonne, toutes deux constituant la plus petite unité porteuse d'une donnée atomique, c'est-à-dire non décomposable.
Les données apparaissent comme stockées dans des tables et ces données peuvent être manipulées entre les diverses tables par des opérations de l'algèbre relationnelle, comme l'opération de jointure. Une table elle-même est une relation, mais entre les différents colonnes 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 peuvent être subordonnées à une clef (composée de une ou plusieurs colonnes).
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 permettant de décrire des n-uplets (lignes). La non-duplication (absence de redondance) des n-uplets est assurée par le SGBDR à l'aide de la notion de contrainte : clef primaire ou clef subrogées (c'est-à-dire contrainte d'unicité).
La notion de clef est prépondérante pour les relations. Une relation se doit d'avoir au moins une clef, c'est-à-dire un sous ensemble de un à plusieurs attributs dont les valeurs permettent de définir au plus une et une seule ligne de la relation. Au pire, comme il n'existe pas de doublon dans une relation, la clef est composée de tous les attributs. Mais le plus souvent on se sert d'un ou plusieurs attributs afin de définir la ou les clefs de la relation. Au niveau table Lorsque plusieurs sous ensemble de colonne permettent de former différentes clef, on doit choisir une unique clef primaire, toutes les autres devenant des clefs subrogées (ou alternative), c'est-à-dire pouvant jouer le rôle de clef en lieu et place de la clef primaire. Une fois choisie, les composantes de la clef primaire se doivent d'être toujours systématiquement valuées. Les colonnes coucourrant ne peuvent en aucun cas être NULL. En revanche cette obligation de non nullité n'est pas requise pour les clef subrogées dont la seule particularité est d'être unique pour toutes les valeurs exprimées (contrainte d'unicité). Enfin, pour assurer la correspondance entre les diverses tables d'une base, il est d'usage de rajouter une contrainte de clef étrangère afin d'assurer l'intégrité référentielle. Cette contrainte découle de la modélisation des données et permet de lier une clef (primaire ou subrogée) d'une table mère aux colonnes correspondantes dans la table fille.
Pour accéder aux données, on utilise les différents opérateurs relationnels définis par Codd : projection, restriction, jointure, union, intersection, différence, produit cartésien, division. Chaque opération de l'algèbre relationnelle produisant une nouvelle relation.
Les opérations sont exprimées sous forme de requêtes aux SGBDR (Système de Gestion de Base de Données Relationnelle). Le SGBDR convertit les requêtes SQL en expressions relationnelles pour pouvoir effectuer les opérations sur les tables. La plupart utilisent le langage normalisé SQL.
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).
Détails techniques
Dans la table PERSONNE ci-dessous, l’ensemble {PersID, nom, prénom, date_naiss, ville_naiss} est un ensemble de colonnes. Chaque attribut définit une information élémentaire à l’intérieur d’une ligne de la table. Il ne peut exister deux fois la même ligne constituées des mêmes valeurs.
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 lignes différentes ne pourraient avoir la colonne PersID dotée de la même (mais les valeurs des autres colonnes peuvent être identiques).
Les clés étrangères sont des contraintes d’intégrité portant sur une table T1, consistant à imposer que la valeur d’un ensemble de colonnes apparaisse comme valeur de clé dans une autre table T2. 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 les colonnes attributs formant la clé étrangère de la table T1 corresponde en tous points (nombre, position et type) aux colonnes formant la clé primaire de la table T2.
Ces clés étrangères sont issues du processus de modélisation des données et liées au respects des normalisation.Lors de l’implémentation d’une base de données, le SGBDR assure des mécanismes de haut niveau tels que :
- Empêcher de nouveaux utilisateurs de mettre à jour des données d'une table pendant que cette table est en cours de modification;
- Assurer qu'un traitement composé de multiples mises à jour portant sur différentes tables s'effectue de manière atomique.
C'est le but de la notion de transactions, assuré notamment par un mécanisme de journalisation permettant la reprise du traitement en cas de panne et son achevement dans un état de cohérence des données.
Enfin, diverses contraintes portant sur les données peuvent être mise en place afin d'assurer la qualité des données. Par exemple une contrainte de domaine permet de s'assurer que les valeurs d'une colonne ou d'un ensemble de colonnes respectent les limites de la sémantique de l'atttribut que l'on a modélisé. Une contrainte de validité permet de restreindre la valeur d'une donnée à diverses condition portant notamment sur la valeurs d'autres colonnes.
Exemples :
- dans une table modélisant un calendrier, restreindre les valeurs d'une colonne "mois" à la plage d'entier de 1 à 12
- dans une table modélisant les transfusions sanguines, interdire qu'un donneur de groupe A fournisse son sang à un receveur de groupe B ou O.
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.
PERSONNE PersID nom prénom date_naiss ville_naiss 1 Dupont bob 01-01-1950 1 2 yyyy merise 29-04-1999 2 3 zzzz codd 26-12-2000 1 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.
VILLE VilleID nom population superficie region 1 Paris 123456 123456 12 2 Lyon 12345 12345 22 3 Grenoble 1234 1234 22 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.
Le principal langage utilisés pour l'élaboration 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 ».
Améliorations
SQL n’étant pas proche de la formulation intuitive d’une requête, il existe plusieurs approches pour s’en affranchir comme par exemple :
- 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 pas incontournable à ce jour pour effectuer des requêtes générales très complexes.
Accéder aux données d'un SGBDR
Les SGBDR sont souvent livrés avec des API propriétaires (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 :
Vérifier qu'un produit est bien un SGBD relationnel
Dans les années 1980, excédés par les dérives de certains éditeurs proposant des pseudo-systèmes de gestion de bases de données relationnelles, Edgar Frank Codd, auteur de la théorie des bases de données relationnelles, écrivit deux articles de vulgarisation dictant 13 règles permettant de vérifier si un SGBDR en est bien un. Elle est connue sous le nom de « 12 règles de Codd » (elles sont numérotées de 0 à 12, et c'est également un clin d'oeil envers la douzaine du boulanger).
Annexes
Articles connexes
Liens externes
Catégorie : Base de données
Wikimedia Foundation. 2010.
