1_cours base des donnees

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 donnes, banques de donnes et fichiers Base de donnes (BD) Systme de gestion de bases de donnes (SGBD) Une base de donnes (BD) reprsente l'ensemble (cohrent, intgr, partag) des informations ncessaires au fonctionnement d'une entreprise, ensemble dont la gestion est assure par un logiciel appel systme de gestion de bases de donnes (SGBD). On entend ici par entreprise toute collectivit d'individus travaillant en coordination la ralisation d'un objectif commun. Exemples de base de donnes: celle qui permet la gestion des personnels, tudiants, cours, inscriptions, ... d'une universit ou cole, celle du systme de rservation de places d'avion des compagnies d'aviation, celles qui permettent la gestion des comptes des clients des socits bancaires, ... Banque de donnes Une base de donnes est dveloppe au sein d'une entreprise, pour son propre fonctionnement. Inversement, une banque de donnes est un ensemble de donnes, propres un domaine d'application, que des "producteurs" runissent pour ensuite en commercialiser l'usage vers le public extrieur. Exemple: les banques de donnes juridiques, conomiques, mdicales, des brevets, des proprits des matriaux, ... . La constitution et l'exploitation des banques de donnes font appel des techniques spcifiques (tlmatique, par exemple), diffrentes des techniques bases de donnes, seules tudies dans ce cours. Fichier Dans une entreprise, il convient de faire appel l'approche base de donnes lorsque les donnes grer sont de natures diverses (exemple : tudiants, cours, enseignants, salles, ...) et possdent 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 donnes grer, bien que importantes en volume, sont homognes : les abonns d'une revue, le personnel d'une entreprise, les produits vendus par un magasin ... . Dans ces cas, on parlera de fichier (le fichier des abonns, ...) et l'on utilisera un systme de gestion de fichiers (SGF), moins complexe qu'un SGBD. Tout systme d'exploitation d'un ordinateur contient un SGF spcifique. Toutefois, pour les applications, on fait plutt appel des progiciels du commerce (exemple: dBase, Filemaker, ...), d'un usage plus simple et offrant des fonctionnalit plus labores.

1

Chapitre 1 : Concepts fondamentaux

Il est noter que l'implantation physique d'une base de donnes sur les mmoires secondaires se fait via la notion de fichier. Le choix de ceux-ci, toutefois, reste de la comptence du SGBD et est invisible l'utilisateur. Le cours abordera les techniques de gestion de fichiers lorsque nous traiterons des aspects internes de ralisation d'un SGBD. 2. Cycle de vie d'une base de donnes On appelle conception d'une base de donnes la phase d'analyse qui aboutit dterminer le futur contenu de la base. Lorsqu'une entreprise dcide, pour son informatisation, d'adopter une approche base de donnes, le premier problme rsoudre, peut-tre le plus difficile, est de dterminer les informations qu'il conviendra de mettre dans la base de donnes. Il faut ainsi que l'ensemble des utilisateurs actuels et futurs de cette base de donnes se mettent d'accord sur la nature et les caractristiques 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, spcifique du logiciel choisi, que l'on appelle langage de description de donnes (LDD). Une fois que le SGBD aura pris connaissance de cette description, il sera possible aux utilisateurs d'entrer les donnes, c'est--dire de constituer la premire version, initiale, de la base de donnes. On appelle implantation de la base de donnes cette phase qui consiste dcrire la base de donnes dans le langage du SGBD et construire cette premire version. Une fois l'implantation termine, peut commencer l'utilisation de la base de donnes. Celle-ci se fait au moyen d'un langage, dit langage de manipulation de donnes (LMD), qui permet d'exprimer aussi bien les requtes d'interrogation (pour obtenir des informations contenues dans la base) que des requtes de mise jour (pour ajouter de nouvelles informations, supprimer des informations primes, modifier le contenu des informations). On appelle cycle de vie d'une base de donnes la suite des phases conception, implantation, utilisation. 3. Modles de donnes et schmas Au cours des diffrentes phases de la vie d'une base de donnes, plusieurs descriptions sont successivement labores, chacune rpondant un objectif dtermin et complmentaire. Dans l'tat actuel de l'art, ces descriptions ne peuvent tre faites avec le langage naturel (en franais, par exemple): celui-ci est trop ambigu et encore trop difficile comprendre par un ordinateur. On fait donc appel un langage formel, base sur un certain nombre de concepts bien tablis. Par exemple, les concepts d'objet, de lien, de proprit. On appelle modle de donnes l'ensemble des concepts qui permettent la description de donnes d'une base et les rgles d'utilisation de ces concepts. On appelle schma d'une base de donnes l'expression de la description de la base de donnes d'une entreprise obtenue en employant un modle de donnes. Les diffrents schmas tablis pour dcrire les divers aspects d'une base de donnes sont les suivants: 1/ Lors de la phase de conception, il est ncessaire 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 donnes. Dans cette description, il n'est gure besoin de faire appel des concepts de l'informatique, dans la mesure o le problme traiter est de dterminer quelles sont les informations ncessaires la vie de l'entreprise, et ce indpendamment de la solution informatique retenue. Cette description s'appuiera donc sur un ensemble de concepts qui ne font aucune rfrence l'informatique : le modle utilis est dit "conceptuel". La description ainsi obtenue s'appelle schma conceptuel des besoins. Un modle conceptuel comporte gnralement deux parties: le modle statique, concepts permettant de dcrire la structure de donnes, et le modle dynamique, concepts permettant de dcrire les oprations sur les donnes.

2


Quelque soit le modle conceptuel choisi (il en existe plusieurs), il n'est pas possible de dcrire avec celui-ci toute la connaissance que l'on possde sur les donnes dcrire: notamment, les rgles de gestion de ces donnes. Par exemple, l'expression de la rgle "il ne doit pas y avoir plus de 20 % d'cart entre les salaires des employs d'un mme service et d'une mme catgorie" n'est pas possible avec les seuls concepts descriptifs d'un modle. On introduira donc, en supplment la description tablie, la description explicite des contraintes supplmentaires, dites contraintes d'intgrit. On utilise pour cela un langage d'expression de rgles, compatible avec le modle conceptuel utilis. 2/ Le schma conceptuel des besoins dcrit la future base, indpendamment des choix techniques d'implantation. La phase suivante, celle d'implantation, demande que la partie dcrivant les donnes de ce schma soit traduite dans les concepts du modle utilis par le SGBD choisi. On appelle modle logique (ou modle machinable), le modle sur lequel est construit un SGBD actuel. Il existe aujourd'hui plusieurs modles logiques (relationnel, CODASYL, hirarchique, ...). Le schma obtenu en traduisant dans un modle logique le schma conceptuel des besoins sera appel ici le schma logique de la base de donnes. A noter cependant que, dans la terminologie courante, ce schma est souvent appel le schma conceptuel de la base de donnes, ce qui ne va pas sans ambigut avec le schma conceptuel rsultant de la phase de conception (point 1 ci-dessus). 3/ L'implantation des donnes elles-mmes, c'est--dire le chargement de la base de donnes avec la version initiale, ncessite que soient fixs les choix en matire de structuration de donnes sur la mmoire 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 systme qui, en fonction de leur analyse des traitements qui vont tre effectus sur la future base de donnes, dtermineront les paramtres 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 schma interne de la base de donnes: description de comment les donnes de la base sont enregistrs dans les fichiers. Cette description fait donc appel un nouveau modle, appel modle interne, o les concepts seront ceux de fichier, organisation, index, chemin d'accs, cl, ... 4/ Enfin, au cours de la phase d'utilisation de la base de donnes, d'autres schmas sont labors pour rpondre aux besoins spcifiques des diffrents groupes d'utilisateurs. Ceux-ci n'ont pas besoin de connatre l'ensemble du contenu de la base, savoir, toutes les informations sur chaque type d'objet. Chaque utilisateur a des exigences limites (il n'est intress que par certaines informations) et particulires (il peut souhaiter une reprsentation des informations diffrente de celle dcrite dans le schma conceptuel). A chaque utilisateur (ou groupe d'utilisateurs) est donc associ un schma, dit son schma externe, qui dfinit le sous-ensemble de la base de donnes auquel il a accs, structur de faon rpondre ses besoins spcifiques. Avantages de cette approche : . simplicit chaque utilisateur n'a dans son schma externe que ce qui l'intresse

. protection il n'est pas possible que, par erreur ou par malveillance, un utilisateur accde aux donnes d'autres utilisateurs non dcrites dans son schma externe.

Dans les SGBD actuels, le modle de donnes employ pour dcrire les schmas externes est le mme que celui du schma logique, mais on pourrait proposer des modles externes plus adapts aux besoins spcifiques des utilisateurs. Un SGBD gre donc trois types de schmas pour une base de donnes, qui sont organiss en cascade de la faon suivante:

3


schmas externes schma logique schma internela BD vue par les utilisateurs la BD vue globalement

la BD vue par l'informaticien

Un exemple illustrant ces trois niveaux de schmas (pour un SGBD relationnel) est le suivant. Entreprise: un institut de formation permanente. Schma logique (SL) Etudiant : nom, prnom, date de naissance, ntudiant Enseignant : nom, prnom, statut, ncompte_bancaire Cours : nomC, cycle, nom_enseignant Inscription : ntudiant, nom_cours, note1, note2 Schmas externes (SE) Schma externe du professeur de base de donnes : Etudiant _BD : nom, prnom, note1, note2, note_finale

tel que Etudiant _BD rsulte de la combinaison de Etudiant et Inscription du SL, tels qu'il existe une Inscription de cet tudiant pour le cours BD (ntudiant dans Etudiant = ntudiant dans Inscription et nom_cours dans Inscription = BD), et

tel que note_finale = (note1 + note2)/2 Schma externe du service de gestion du personnel enseignant : Professeur : nom, prnom, ncompte_bancaire, nombre_de_cours, liste(nom_cours)

tel que Professeur rsulte 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)) Schma interne (SI) Etudiant : fichier FEtud, contenu : nom, prnom, date de naissance, ntudiant index sur ntudiant, index secondaire sur nom+prnom Enseignant + : fichier FEnsCours, Cours contenu : nom, prnom, statut, ncompte_bancaire, liste(nomC, cycle) tel que nom_enseignant dans Cours = nom dans Enseignant index sur nom,

4


deux index secondaires, l'un sur nomC, l'autre sur cycle Inscription : fichier FInscrits, contenu : ntudiant, nom_cours, note1, note2 index sur ntudiant, 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 conformment aux requtes de ses utilisateurs:

L'interface utilisateur permet aux utilisateurs d'exprimer des requtes: soit pour dfinir 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'accs physique permet au SGBD d'accder aux donnes sur les supports (disques, ...). Un SGBD gre des problmes trs diffrents, avec des objectifs particuliers: - interface utilisateur: comprhension, analyse et vrification des requtes; objectifs: convivialit de l'interface, puissance des langages de description et de manipulation; - interface d'accs physique: optimisation du stockage des donnes (en termes d'espace occup sur les supports) et de l'accs aux donnes (en temps); objectif: avoir les meilleures performances. L'articulation entre ces deux interfaces doit rpondre un objectif fondamental: assurer l'indpendance programme/donnes. 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 oprs au niveau interne en matire de fichiers; d'autre part, inversement, la possibilit pour un administrateur systme de modifier ces choix, pour amliorer les performances, sans que cela ait un impact sur les utilisateurs (leurs requtes d'interrogation ou de mise jour, ou leurs programmes d'application qui utilisent la base de donnes). Enfin, un SGBD tant utilis simultanment par plusieurs utilisateurs, il a rsoudre plusieurs problmes internes de coordination de ses actions, de cohrence et de contrle du bon droulement de ses activits. 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 problme du dialogue avec les utilisateurs, c'est--dire l'analyse

des demandes de l'utilisateur, le contrle des droits d'accs de l'utilisateur, la prsentation des rsultats

. niveau interne s'occupe du stockage des donnes dans les supports physiques et de la gestion des

structures de mmorisation (fichiers) et d'accs (gestion des index, des cls, ...)

5


. niveau intermdiaire: assure les fonctions de contrle global: - optimisation globale des requtes - gestion des conflits d'accs simultans de la part de plusieurs utilisateurs - contrle gnral de la cohrence de l'ensemble - coordination et suivi des processus en cours - garantie du bon droulement des actions entreprises mme en cas de panne - ... La couche intermdiaire de contrle est appele niveau logique: on cherche ne dpendre ni des exigences des utilisateurs ni des structures physiques choisies.

schma logique

schmas externes schma interne

couche logique

Avec cette approche, le principe du fonctionnement d'un SGBD est le suivant. Une requte, exprime par l'utilisateur dans un langage accept par le systme (LMD), est d'abord analyse du point de vue syntaxique (conformit la grammaire du langage); suit une analyse smantique (les objets cits doivent tre connus dans le schma externe de l'utilisateur). Aprs cette validation, faite dans la couche externe, la requte est traduite, pour son passage la couche logique: les rfrences aux objets du schma externe sont remplaces par les rfrences aux objets correspondants dans le schma logique. On utilise pour cela la description des rgles de correspondance entre schma externe et schma logique, tablie, ncessairement, au moment de la dfinition du schma externe. Au niveau logique, on fait les contrles sur la confidentialit, la concurrence, etc. Si la requte est accepte, elle est optimise et dcoupe en sous-requtes plus lmentaires qui sont transfres au niveau interne; sinon, elle peut tre mise en attente ou refuse. Au niveau interne, chaque sous-requte reue est traduite en une ou plusieurs requtes physiques correspondantes (en fonction des informations contenues dans le schma interne), puis le SGBD ralise l'accs physique aux donnes (extraction ou modification). S'il s'agit d'une requte d'interrogation, les donnes extraites sont passes la couche logique, puis la couche externe. Ici elles sont rorganises, selon le schma externe de l'utilisateur, avant de les transmettre l'utilisateur.

6

1_cours base des donnees

Documents