Tutoriel de Bases de Données Relationnelles

Introduction aux BD relationnelles

Définitions

• une base de données est une collection de données inter-reliées. C'est une entité cohérente logiquement et véhiculant une certaine sémantique,
• un Système de Gestion de Bases de Données (SGBD) est un ensemble de programmes qui permettent à des utilisateurs de créer et maintenir une base de données. Les activités supportées sont la définition d'une base de données (spécification des types de données à stocker), la construction d'une base de données (stockage des données proprement dites) et la manipulation des données (principalement ajouter, supprimer, retrouver des données). Les SGBD commerciaux les plus connus sont Oracle, MySQL, Sybase, Ingres, Informix et DB2,
• un SGBD sépare la partie description des données, des données elles mêmes. Cette description est stockée dans un dictionnaire de données (également géré dans le SGBD) et peut être consultée par les utilisateurs,
• un modèle de données est un ensemble de concepts permettant de décrire la structure d'une base de données. La plupart des modèles de données incluent des opérations permettant de mettre à jour et questionner la base. Le modèle de données le plus utilisé est le modèle relationnel,
• un schéma de base de données (ou compréhension ou intension) est la description des données à gérer. Il est conçu dans la phase de spécification et est peu évolutif (pratiquement statique),
• une extension d'une base de données correspond aux données de la base à un instant donné. Par définition cet état est dynamique.

Fonctionnalités

Nous donnons ici les caractéristiques souhaitables des SGBD qui ne sont pas forcément prises en compte par les SGBD commerciaux.

1. Contrôler la redondance d'informations. La redondance d'informations pose différents problèmes (coût en temps, coût en volume et risque d'incohérence entre les différentes copies). Un des objectifs des bases de données est de contrôler cette redondance, voire de la supprimer, en offrant une gestion unifiée des informations complétée par différentes vues pour des classes d'utilisateurs différents.
2. Partage des données. Une base de données doit permettre d'accéder la même information par plusieurs utilisateurs en même temps. Le SGBD doit inclure un mécanisme de contrôle de la concurrence basé sur des techniques de verrouillage des données (pour éviter par exemple qu'on puisse lire une information qu'on est en train de mettre à jour). Le partage des données se fait également par la notion de vue utilisateur, qui permet de définir pour chaque classe d'utilisateurs la portion de la base de données qui l'intéresse (et dans la forme qui l'intéresse).
3. Gérer les autorisations d'accès. Une base de données étant multi-utilisateurs, se pose le problème de la confidentialité des données. Des droits doivent être gérés sur les données, droits de lecture, mise à jour, création, ... qui permettent d'affiner la notion de vue utilisateur.
4. Offrir des interfaces d'accès multiples. Un SGBD doit offrir plusieurs interfaces d'accès, correspondant aux différents types d'utilisateurs pouvant s'adresser à lui. On trouve des interfaces orientées utilisateur final (langages de requêtes déclaratifs comme SQL avec mise en oeuvre graphique, interface de type formulaire, ...) ou bien orientées programmeurs d'applications (interface avec des langages de programmation classiques comme par exemple l'approche SQL immergé ou "embedded SQL").
5. Représenter des relations complexes entre les données. Un SGBD doit permettre de représenter des données inter-reliées de manière complexe. Cette facilité s'exprime à travers le modèle de données sous-jacent au SGBD. Chaque modèle de données offre ses propres concepts pour représenter les relations. On peut citer les modèles hiérarchique, réseau (première génération de modèles), relationnel (génération actuelle), sémantiques (ou orientés vers la conception tel que Entité-Association, Z, ...) ou orienté-objet (la génération future ?).
6. Vérifier les contraintes d'intégrité.,Un schéma de base de données se compose d'une description des données et de leurs relations ainsi que d'un ensemble de contraintes d'intégrité. Une contrainte d'intégrité est une propriété de l'application à modéliser qui renforce la connaissance que l'on en a. On peut classifier les contraintes d'intégrité, en contraintes structurelles (un employé a un chef et un seul par exemple) et contraintes dynamiques (un salaire ne peut diminuer). Les SGBD commerciaux supportent automatiquement un certain nombre de contraintes structurelles, mais ne prennent pas en compte les contraintes dynamiques (elles doivent être codées dans les programmes d'application).
7. Assurer la sécurité et la reprise après panne. Une base de données est souvent vitale dans le fonctionnement d'une organisation, et il n'est pas tolérable qu'une panne puisse remettre en cause son fonctionnement de manière durable. Les SGBD fournissent des mécanismes pour assurer cette sécurité. Le premier mécanisme est celui de transaction qui permet d'assurer un comportement atomique à une séquence d'actions (elle s'effectue complètement avec succès ou elle est annulée). Une transaction est une séquence d'opérations qui fait passer la base de données d'un état cohérent à un nouvel état cohérent. L'exemple typique est celui du débit-crédit pour la gestion d'une carte bancaire. Ce mécanisme permet de s'affranchir des petites pannes (style coupure de courant). En ce qui concerne les risques liés aux pannes disques, les SGBD s'appuie sur un mécanisme de journalisation qui permet de regénérer une base de données automatiquement à partir d'une version de sauvegarde et du journal des mouvements.

Architecture logique d'un SGBD

La plupart des SGBD suivent l'architecture standard Ansi/Sparc qui permet d'isoler les différents niveaux d'abstraction nécessaires pour un SGBD.

Architecture Ansi/Sparc

Elle est définie sur trois niveaux :

• niveau interne ou physique : décrit le modèle de stockage des données et les fonctions d'accès
• modèle conceptuel ou logique : décrit la structure de la base de données globalement à tous les utilisateurs (limite la redondance). Le schéma conceptuel est produit par une analyse de l'application à modéliser et par intégration des différentes vues utilisateurs. Ce schéma décrit la structure de la base indépendament de son implantation
• niveau externe : correspond aux différentes vues des utilisateurs. Chaque schéma externe donne une vue sur le schéma conceptuel à une classe d'utilisateurs.

Le SGBD doit être capable de faire des transformations entre chaque niveau, de manière à transformer une requête exprimée en terme du niveau externe en requête du niveau conceptuel puis du niveau physique.

La plupart des SGBD ne séparent pas complètement ces trois niveaux, mais respectent néanmoins ces principes de séparation.

Indépendance données - programmes

L'architecture à trois niveaux permet de supporter le concept d'indépendance données - programmes, c'est à dire la capacité de modifier le schéma de la base de données à un niveau donné, sans remettre en cause le schéma aux niveaux supérieurs :

• indépendance logique : on peut changer le niveau conceptuel sans remettre en cause les schémas externes ou les programmes d'application. L'ajout ou le retrait de nouveaux concepts ne doit pas modifier des éléments qui n'y font pas explicitement référence,
• indépendance physique : on peut changer le schéma physique sans remettre en cause le schéma conceptuel (et les schémas externes). On peut modifier l'organisation physique des fichiers, rajouter ou supprimer des méthodes d'accès.

Le modèle relationnel, contrairement à ces prédécesseurs, permet un certain niveau d'indépendance sans aller jusqu'à une indépendance complète.