C H A P I T R E 1
C o n c e p t s f o n d a m e n t a u x
1. Bases de données, banques de données et fichiers
Base de données (BD)
Système de gestion de bases de données (SGBD)
Une base de données (BD) représente l'ensemble (cohérent, intégré, partagé) des informations nécessaires au fonctionnement d'une entreprise, ensemble dont la gestion est assurée par un logiciel appelé système de gestion de bases de données (SGBD).
On entend ici par entreprise toute collectivité d'individus travaillant en coordination à la réalisation d'un objectif commun.
Exemples de base de données: celle qui permet la gestion des personnels, étudiants, cours, inscriptions, ...
d'une université ou école, celle du système de réservation de places d'avion des compagnies d'aviation, celles qui permettent la gestion des comptes des clients des sociétés bancaires, ...
Banque de données
Une base de données est développée au sein d'une entreprise, pour son propre fonctionnement. Inversement, une banque de données est un ensemble de données, propres à un domaine d'application, que des
"producteurs" réunissent pour ensuite en commercialiser l'usage vers le public extérieur. Exemple: les banques de données juridiques, économiques, médicales, des brevets, des propriétés des matériaux, ... . La constitution et l'exploitation des banques de données font appel à des techniques spécifiques (télématique, par exemple), différentes des techniques bases de données, seules étudiées dans ce cours.
Fichier
Dans une entreprise, il convient de faire appel à l'approche base de données lorsque les données à gérer sont de natures diverses (exemple : étudiants, cours, enseignants, salles, ...) et possèdent de nombreux liens entre elles (exemple : un étudiant suit un cours, un cours est assuré par un enseignant, ...). A contrario, il existe des cas où les données à gérer, bien que importantes en volume, sont homogènes : les abonnés d'une revue, le personnel d'une entreprise, les produits vendus par un magasin ... . Dans ces cas, on parlera de fichier (le fichier des abonnés, ...) et l'on utilisera un système de gestion de fichiers (SGF), moins complexe qu'un SGBD.
Tout système d'exploitation d'un ordinateur contient un SGF spécifique. Toutefois, pour les applications, on fait plutôt appel à des progiciels du commerce (exemple: dBase, Filemaker, ...), d'un usage plus simple et offrant des fonctionnalité plus élaborées.
Il est à noter que l'implantation physique d'une base de données sur les mémoires secondaires se fait via la notion de fichier. Le choix de ceux-ci, toutefois, reste de la compétence du SGBD et est invisible à l'utilisateur. Le cours abordera les techniques de gestion de fichiers lorsque nous traiterons des aspects internes de réalisation d'un SGBD.
2. Cycle de vie d'une base de données
On appelle conception d'une base de données la phase d'analyse qui aboutit à déterminer le futur contenu de la base.
Lorsqu'une entreprise décide, pour son informatisation, d'adopter une approche base de données, le premier problème à résoudre, peut-être le plus difficile, est de déterminer les informations qu'il conviendra de mettre dans la base de données. Il faut ainsi que l'ensemble des utilisateurs actuels et futurs de cette base de données se mettent d'accord sur la nature et les caractéristiques des informations qu'il faut garder pour assurer la gestion de l'entreprise.
Une fois que cet accord aura été établi, il faudra pouvoir transmettre son contenu au logiciel SGBD choisi par l'entreprise. Ceci sera fait au moyen d'un langage symbolique, spécifique du logiciel choisi, que l'on appelle langage de description de données (LDD). Une fois que le SGBD aura pris connaissance de cette description, il sera possible aux utilisateurs d'entrer les données, c'est-à-dire de constituer la première version, initiale, de la base de données. On appelle implantation de la base de données cette phase qui consiste à décrire la base de données dans le langage du SGBD et construire cette première version.
Une fois l'implantation terminée, peut commencer l'utilisation de la base de données. Celle-ci se fait au moyen d'un langage, dit langage de manipulation de données (LMD), qui permet d'exprimer aussi bien les requêtes d'interrogation (pour obtenir des informations contenues dans la base) que des requêtes de mise à jour (pour ajouter de nouvelles informations, supprimer des informations périmées, modifier le contenu des informations).
On appelle cycle de vie d'une base de données la suite des phases conception, implantation, utilisation.
3. Modèles de données et schémas
Au cours des différentes phases de la vie d'une base de données, plusieurs descriptions sont successivement élaborées, chacune répondant à un objectif déterminé et complémentaire. Dans l'état actuel de l'art, ces descriptions ne peuvent être faites avec le langage naturel (en français, par exemple): celui-ci est trop ambigu et encore trop difficile à comprendre par un ordinateur. On fait donc appel à un langage formel, basée sur un certain nombre de concepts bien établis. Par exemple, les concepts d'objet, de lien, de propriété.
On appelle modèle de données l'ensemble des concepts qui permettent la description de données d'une base et les règles d'utilisation de ces concepts. On appelle schéma d'une base de données l'expression de la description de la base de données d'une entreprise obtenue en employant un modèle de données.
Les différents schémas établis pour décrire les divers aspects d'une base de données sont les suivants:
1/ Lors de la phase de conception, il est nécessaire que les utilisateurs puissent discuter de leurs besoins: il faudra donc qu'ils puissent exprimer leur vision sous forme d'une description, éventuellement partielle, de la future base de données. Dans cette description, il n'est guère besoin de faire appel à des concepts de l'informatique, dans la mesure où le problème à traiter est de déterminer quelles sont les informations nécessaires à la vie de l'entreprise, et ce indépendamment de la solution informatique retenue. Cette description s'appuiera donc sur un ensemble de concepts qui ne font aucune référence à l'informatique : le modèle utilisé est dit "conceptuel".
La description ainsi obtenue s'appelle schéma conceptuel des besoins. Un modèle conceptuel comporte généralement deux parties: le modèle statique, concepts permettant de décrire la structure de données, et le modèle dynamique, concepts permettant de décrire les opérations sur les données.
Quelque soit le modèle conceptuel choisi (il en existe plusieurs), il n'est pas possible de décrire avec celui-ci toute la connaissance que l'on possède sur les données à décrire: notamment, les règles de gestion de ces données. Par exemple, l'expression de la règle "il ne doit pas y avoir plus de 20 % d'écart entre les salaires des employés d'un même service et d'une même catégorie" n'est pas possible avec les seuls concepts descriptifs d'un modèle. On introduira donc, en supplément à la description établie, la description explicite des contraintes supplémentaires, dites contraintes d'intégrité. On utilise pour cela un langage d'expression de règles, compatible avec le modèle conceptuel utilisé.
2/ Le schéma conceptuel des besoins décrit la future base, indépendamment des choix techniques d'implantation. La phase suivante, celle d'implantation, demande que la partie décrivant les données de ce schéma soit traduite dans les concepts du modèle utilisé par le SGBD choisi. On appelle modèle logique (ou modèle machinable), le modèle sur lequel est construit un SGBD actuel. Il existe aujourd'hui plusieurs modèles logiques (relationnel, CODASYL, hiérarchique, ...). Le schéma obtenu en traduisant dans un modèle logique le schéma conceptuel des besoins sera appelé ici le schéma logique de la base de données. A noter cependant que, dans la terminologie courante, ce schéma est souvent appelé le schéma conceptuel de la base de données, ce qui ne va pas sans ambiguïté avec le schéma conceptuel résultant de la phase de conception (point 1 ci-dessus).
3/ L'implantation des données elles-mêmes, c'est-à-dire le chargement de la base de données avec la version initiale, nécessite que soient fixés les choix en matière de structuration de données sur la mémoire secondaire (quels types de fichiers? quels index? ...). Ces choix, ainsi que nous l'avons dit plus haut, ne sont pas faits par les utilisateurs, mais par les administrateurs système qui, en fonction de leur analyse des traitements qui vont être effectués sur la future base de données, détermineront les paramètres effectifs pour l'implantation de la base sous forme d'un ensemble de fichiers. L'ensemble de ces choix sera consigné dans ce que l'on appelle le schéma interne de la base de données: description de comment les données de la base sont enregistrés dans les fichiers. Cette description fait donc appel à un nouveau modèle, appelé modèle interne, où les concepts seront ceux de fichier, organisation, index, chemin d'accès, clé, ...
4/ Enfin, au cours de la phase d'utilisation de la base de données, d'autres schémas sont élaborés pour répondre aux besoins spécifiques des différents groupes d'utilisateurs. Ceux-ci n'ont pas besoin de connaître l'ensemble du contenu de la base, à savoir, toutes les informations sur chaque type d'objet. Chaque utilisateur a des exigences limitées (il n'est intéressé que par certaines informations) et particulières (il peut souhaiter une représentation des informations différente de celle décrite dans le schéma conceptuel).
A chaque utilisateur (ou groupe d'utilisateurs) est donc associé un schéma, dit son schéma externe, qui définit le sous-ensemble de la base de données auquel il a accès, structuré de façon à répondre à ses besoins spécifiques.
Avantages de cette approche :
. simplicité chaque utilisateur n'a dans son schéma externe que ce qui l'intéresse
. protection il n'est pas possible que, par erreur ou par malveillance, un utilisateur accède aux données d'autres utilisateurs non décrites dans son schéma externe.
Dans les SGBD actuels, le modèle de données employé pour décrire les schémas externes est le même que celui du schéma logique, mais on pourrait proposer des modèles externes plus adaptés aux besoins spécifiques des utilisateurs.
Un SGBD gère donc trois types de schémas pour une base de données, qui sont organisés en cascade de la façon suivante:
schémas externes schéma logique schéma interne
la BD vue par les
utilisateurs la BD vue globalement la BD vue par l'informaticien
Un exemple illustrant ces trois niveaux de schémas (pour un SGBD relationnel) est le suivant.
Entreprise: un institut de formation permanente.
Schéma logique (SL)
Etudiant : nom, prénom, date de naissance, n°étudiant Enseignant : nom, prénom, statut, n°compte_bancaire Cours : nomC, cycle, nom_enseignant
Inscription : n°étudiant, nom_cours, note1, note2 Schémas externes (SE)
• Schéma externe du professeur de base de données :
Etudiant _BD : nom, prénom, note1, note2, note_finale
tel que Etudiant _BD résulte de la combinaison de Etudiant et Inscription du SL, tels qu'il existe une Inscription de cet étudiant pour le cours BD (n°étudiant dans Etudiant = n°étudiant dans Inscription et nom_cours dans Inscription = BD), et
tel que note_finale = (note1 + note2)/2
• Schéma externe du service de gestion du personnel enseignant :
Professeur : nom, prénom, n°compte_bancaire, nombre_de_cours, liste(nom_cours)
tel que Professeur résulte de la combinaison de Enseignant et Cours du SL, tels que liste(nom_cours) est la liste de nomC qui se trouvent dans Cours tel que nom_enseignant dans Cours = nom dans Enseignant, et
tel que nombre_de_cours = Cardinalité (liste(nom_cours)) Schéma interne (SI)
Etudiant : fichier FEtud,
contenu : nom, prénom, date de naissance, n°étudiant indexé sur n°étudiant,
index secondaire sur nom+prénom Enseignant
+ : fichier FEnsCours,
Cours contenu : nom, prénom, statut, n°compte_bancaire, liste(nomC, cycle) tel que nom_enseignant dans Cours = nom dans Enseignant indexé sur nom,
deux index secondaires, l'un sur nomC, l'autre sur cycle Inscription : fichier FInscrits,
contenu : n°étudiant, nom_cours, note1, note2 indexé sur n°étudiant,
index secondaire sur nom_cours
4. Architecture d'un SGBD
Au niveau d'abstraction le plus élevé, un SGBD peut être vu comme une boite noire, assurant la gestion de la BD conformément aux requêtes de ses utilisateurs:
L'interface utilisateur permet aux utilisateurs d'exprimer des requêtes: soit pour définir le contenu de la BD (avec le LDD), soit pour interroger la BD (en extraire des informations), soit enfin pour apporter des modifications à ce qui a été enregistré.
L'interface d'accès physique permet au SGBD d'accéder aux données sur les supports (disques, ...).
Un SGBD gère des problèmes très différents, avec des objectifs particuliers:
- interface utilisateur: compréhension, analyse et vérification des requêtes; objectifs: convivialité de l'interface, puissance des langages de description et de manipulation;
- interface d'accès physique: optimisation du stockage des données (en termes d'espace occupé sur les supports) et de l'accès aux données (en temps); objectif: avoir les meilleures performances.
L'articulation entre ces deux interfaces doit répondre à un objectif fondamental: assurer l'indépendance programme/données. A savoir, d'une part, la possibilité pour un utilisateur de modifier sa vue de la base et ses traitements sans avoir à se soucier des choix qui ont été opérés au niveau interne en matière de fichiers;
d'autre part, inversement, la possibilité pour un administrateur système de modifier ces choix, pour améliorer les performances, sans que cela ait un impact sur les utilisateurs (leurs requêtes d'interrogation ou de mise à jour, ou leurs programmes d'application qui utilisent la base de données).
Enfin, un SGBD étant utilisé simultanément par plusieurs utilisateurs, il a à résoudre plusieurs problèmes internes de coordination de ses actions, de cohérence et de contrôle du bon déroulement de ses activités.
Il convient donc d'avoir une vision plus fine de l'architecture d'un SGBD. Celle-ci conduit à distinguer trois couches :
. niveau externe prend en charge le problème du dialogue avec les utilisateurs, c'est-à-dire l'analyse des demandes de l'utilisateur, le contrôle des droits d'accès de l'utilisateur, la présentation des résultats
. niveau interne s'occupe du stockage des données dans les supports physiques et de la gestion des structures de mémorisation (fichiers) et d'accès (gestion des index, des clés, ...)
. niveau intermédiaire: assure les fonctions de contrôle global:
- optimisation globale des requêtes
- gestion des conflits d'accès simultanés de la part de plusieurs utilisateurs - contrôle général de la cohérence de l'ensemble
- coordination et suivi des processus en cours
- garantie du bon déroulement des actions entreprises même en cas de panne
- ...
La couche intermédiaire de contrôle est appelée niveau logique: on cherche à ne dépendre ni des exigences des utilisateurs ni des structures physiques choisies.
schéma logique schémas
externes schéma
interne couche
logique
Avec cette approche, le principe du fonctionnement d'un SGBD est le suivant.
Une requête, exprimée par l'utilisateur dans un langage accepté par le système (LMD), est d'abord analysée du point de vue syntaxique (conformité à la grammaire du langage); suit une analyse sémantique (les objets cités doivent être connus dans le schéma externe de l'utilisateur).
Après cette validation, faite dans la couche externe, la requête est traduite, pour son passage à la couche logique: les références aux objets du schéma externe sont remplacées par les références aux objets correspondants dans le schéma logique. On utilise pour cela la description des règles de correspondance entre schéma externe et schéma logique, établie, nécessairement, au moment de la définition du schéma externe.
Au niveau logique, on fait les contrôles sur la confidentialité, la concurrence, etc. Si la requête est acceptée, elle est optimisée et découpée en sous-requêtes plus élémentaires qui sont transférées au niveau interne;
sinon, elle peut être mise en attente ou refusée.
Au niveau interne, chaque sous-requête reçue est traduite en une ou plusieurs requêtes physiques correspondantes (en fonction des informations contenues dans le schéma interne), puis le SGBD réalise l'accès physique aux données (extraction ou modification). S'il s'agit d'une requête d'interrogation, les données extraites sont passées à la couche logique, puis à la couche externe. Ici elles sont réorganisées, selon le schéma externe de l'utilisateur, avant de les transmettre à l'utilisateur.
