Cours SGBD pdf : introduction aux différents types
...
Sommaire
Une donnée est une information quelconque, comme, par exemple, « voici une personne, elle s’appelle Antoine ». C’est aussi une relation entre des informations. Par exemple : « Antoine enseigne les bases
de données ». Des relations de ce genre définissent des structures.
Une base de données est un ensemble, en général volumineux, de telles informations, avec la caractéristique essentielle que l’on cherche à les mémoriser de manière permanente.
Une base de données est un gros ensemble d’informations structurées mémorisées sur un support per- manent qui peut être partagée par plusieurs applications et qui est interrrogeable par le contenu.
L’utilisation de fichiers classiques pourrait sembler pouvoir apporter une solution à ce problème. Mais l’utilisation directe de gros fichiers soulève de gros problèmes :
Il est donc nécessaire d’avoir recours à un logiciel chargé de gérer les fichiers constituant une base de données, de prendre en charge les fonctionnalités de protection et de sécurité et de fournir les différents types d’interfaces nécessaires à l’accès aux données. Ce logiciel (le SGDB) est très complexe.
Un Système de Gestion de Bases de Données (SGBD) est un logiciel de haut niveau permettant aux utilisateurs de structurer, d’insérer, de modifier, de rechercher de manière efficace des données spécifiques, au sein d’une grande quantité d’informations, stockées sur mémoires secondaires partagée de manière transparente par plusieurs utilisateurs.
Plus précisément, les systèmes de gestion de bases de données (SGBD) sont des programmes permettant à l’utilsateur de créer et de gérer des bases de données. les SGBD sont des logiciels à usage général qui assurent les processus de définition, de construction, de manipulation et de partage des bases de données par et entre les différents utilisateurs et applications.
La déftnition d’une base de données implique une spécification des types de données, des structures et des contraintes. La construction d’une base de données consiste à enregistrer les données proprement dites sur un support de stockage contrôlé par le SGBD. La manipulation de la base consiste notamment à l’interroger afin d’en extraire des informations, à l’actualiser en fonction des modifications du microcosme considéré et à générer des rapports. Le partage d’une base de données permet à différents utilsateurs et applications d’y accéder simultanément.
Les SGBD assurent d’autres fonctions importantes, notamment la protection de la base de données et son
/em entretien à long terme. La protection implique à la fois la protection du système contre les pannes logicielles et matérielles et la protection sécuritaire conre les accès illicites ou malveillants. Une grande base de données peut être utilisées de nombreuses années. Le SGBD doit donc être capable d’entretenir et de faire évoluer ses propres structures dans la durée.
La complexité d’un SGBD tient essentiellement à la diversité des techniques mises en œuvre, à la multi- plicité des composants intervenant dans son architecture, et aux différents types d’utilisateurs (adminis-
Chapitre 1 3
trateurs, programmeurs, utilisateurs non informaticiens, ...) qui sont confrontés, à différents niveaux, au système.
Ainsi, dans ce cours, seront abordés :
Ces fonctions sont remplies par trois niveaux, théoriquement distincts, d’un SGBD :
En résumé, un SGBD est destiné à gérer un gros volume d’informations, persistantes, fiables (protection sur pannes), partageables entre plusieurs utilisateurs et/ou programmes manipulés indépendamment de leur représentation physique.
Nous avons introduit un certain nombre de termes et de sigles. Nous allons progressivement en apprendre le sens.
L’utilisation d’un SGBD suppose de comprendre et de savoir utiliser les fonctionnalités suivantes :
4 2 Quelles compétences pour utiliser un SGBD ?
En reprenant ces différents points.
Un schéma est simplement la description des données contenues dans la base. Cette description est conforme à un modèle de données qui propose des outils de description (structures, contraintes et opé- rations). Dans un SGBD, il existe plusieurs modèles plus ou moins abstraits des mêmes objets. Par exemple :
Ces différents modèles correspondent aux niveaux de l’architecture d’un SGBD. Prenons l’exemple du modèle conceptuel le plus courant : le modèle Entité/Association. C’est essentiellement une description très abstraite décrivant :
En revanche, il ne propose pas d’opérations. Or définir des structures sans disposer d’opérations pour agir sur les données stockées dans ces structures ne présente pas d’intérêt pratique pour un SGBD. D’où, à un niveau inférieur, des modèles dits « logiques » qui proposent :
Ces langages sont abstraits. le LDD est indépendant de la représentation physique des données, et le LMD est indépendant de l’implantation des opérations. On peut citer une troisième caractéristique : outre les structures et les opérations, un modèle logique doit permetre d’exprimer des contraintes d’intégrité sur les données.
Exemple
nom character 15, not null ; âge integer between 0 and 120 ; débit = crédit ;
...
Bien entendu, le SGBD doit être capable de garantir le respect de ces contraintes.
Quand on conçoit une application pour une BD, on tient compte de cette architecture en plusieurs niveaux. Typiquement : (1) on décide la structure logique, (2) on décide la structure physique, (3) on écrit les programmes d’application en utilisant la structure logique, enfin (4à le SGBD se charge de transcrire les commandes du LMD en instructions appliquées à la représentation physique.
Cette approche offre de très grands avantages. Tout d’abord elle ouvre l’utilisation des SGBD à des utilisateurs non-experts : les langages proposés par les modèles logiques sont plus simples, et donc plus accessibles, que les outils de gestion de fichiers. Ensuite, on obtient une caractéristique essentielle : l’indé- pendance physique. On peut modifier l’implantation physique sans modifier les programmes d’application. Un concept voisin est celui d’indépendance logique : on peut modifier les programmes d’application sans toucher à l’implantation.
Enfin le SGBD décharge l’utilisateur, et en grande partie l’administrateur, de la lourde tâche de contrôler la sécurité et l’intégrité des données.
Il existe 4 opérations classiques (ou requêtes :
Chapitre 1 Concepts fondamentaux 5
Ces opérations correspondent à des commandes du LMD. La plus complexe est la recherche en raison de la variété des critères.
Pour l’utilisateur, une bonne requête a les caractéristiques suivantes. Tout d’abord, elle s’exprime fa- cilement : l’idéal serait de pouvoir utiliser le langage naturel, mais celui-ci présente trop d’ambiguïtés. Ensuite, le langage ne devrait pas demander d’expertise technique (syntaxe compliquée, structure de données, implantation particulière ...). Il est également souhaitable de ne pas attendre trop longtemps (à charge pour le SGBD de fournir des performances acceptables). Enfin, et peut-être surtout, la réponse doit être fiable.
Une bonne partie du travail sur les SGBD consiste à satisfaire ces besoins. le résultat est ce que l’on appelle un langage de requêtes, et constitue à la fois un sujet majeur d’étude et une caractéristique essentielle de chaque SGBD. le langage le plus répandu à l’heure actuelle est SQL.
L’optimisation (d’une requête) s’appuie sur l’organisation physique des données. les principaux types d’organisation sont les fichiers séquentiels, les index (denses, secondaires, arbres B) et le regroupement des données par hachage.
Un module particulier du SGBD, l’optimiseur, tient compte de cette organisation et des caractéristiques de la requête pour choisir le meilleur séquencement des opérations.
Plusieurs utilisateurs doivent pouvoir accéder en même temps aux mêmes données. Le SGBD doit savoir :
Architecture en trois schémas
6 4 Le contexte
– 10 KO – 100 KO
– > 100 GO
Moteur : évolution des modèles de données, elle-même motivée par l’évolution des besoins.
Chapitre 1 Concepts fondamentaux 7
Il faut donc distinguer entre modèles conceptuels, /em a priori indépendants des SGBD, et /em modèles logiques, caractéristiques d’une génération de SGBD. Ces modèles logiques sont eux-mêmes dépendants d’organisations physiques (placement et méthodes d’accès) comme, par exemple, les graphes en arbres ou en réseaux, seules structures offertes par la première génération de SGBD, celle des modèles naviga- tionnels, hiérarchique et réseau.
Ces SGBD obligeaient à "voir" - c’est à dire à traduire - une base de données comme un ensemble d’enregistrements, reliés les uns aux autres par des ensembles de pointeurs. Cette organisation fige les relations existant entre les différents enregistrements de la base et impose un type de manipulation, la navigation, qui consiste à suivre, d’enregistrement en enregistrement, les chaînes de pointeurs. En fait, il serait préférable de parler de modèles d’accès (physiques) plutôt que de modèles de données (logiques) pour ces anciens SGBD. En effet leur organisation physique des données imposait la méthode d’accès et, au delà, la nature des langages de manipulation.
Longtemps considéré comme le seul modèle permettant aux SGBD d’atteindre les performances exigées en production, le modèle hiérarchique possède effectivement la capacité de traiter rapidement des in- formations organisées sous la forme d’une hiérarchie stricte mais, par contre, interdit tout autre type de représentation, limitant ainsi considérablement la puissance d’expression du modèle. Le SGBD le plus connu dans cette catégorie est IMS, produit ancien de IBM, très répandu dans les applications de production.
Ce modèle a été introduit en 1961 par BACHMAN. Il propose une utilisation de structures de listes afin de relier sémantiquement des entités. Il permet ainsi une meilleure représentation de la réalité que le modèle hierarchique. Un des intérêts du modèle fut l’existence d’une proposition de normalisation émise par le groupe DBTG (Data Base Task Group) du Comité CODASYL (COnference on DAta SYstem Language). On parle ainsi souvent de modèle CODASYL pour les systèmes réseaux qui suivent ces recommandations. Deux niveaux de recommandations ont été émis : l’un, en 1971, conseillait la séparation d’un niveau de schéma externe et d’un niveau de schéma interne/conceptuel ; le second, en 1978, préconisait les trois niveaux de schéma -interne, conceptuel, externe-. Seul le premier niveau de recommandations a été réellement suivi par les produits. En 1978, il était déjà tard pour voir les produits prendre en compte ces recommandations : l’heure du relationnel avait déjà sonné pour les investissements à long terme ; quasiment aucun SGBD réseau réellement nouveau n’a été conçu depuis cette date. Mais à l’heure où les SGBD relationnels sont à leur tour défiés par les nouveaux SGBD orientés objets, il est encore intéressant de comprendre ce que les SGBD réseau avaient apporté de plus novateur : l’expression des requêtes sur les données dans une logique de chemin (c.à.d. de navigation ). Parmi les SGBD construits selon ce modèle, encore largement utilisés, on peut citer IDS2 chez BULL, IDMS de CULLINET, TOTAL de CINCOM, SOCRATE.
8 5 Objectifs du cours
Mode`le abstrait des bases de donne´es
Sommaire
Ce chapitre présente le modèle Entité/Association (E/A) qui est utilisé à peu près universellement pour la conception de bases de données (relationnelles principalement). La conception d’un schéma correct est essentielle pour le développement d’une application viable. Dans la mesure où la base de données est le fondement de tout le système, une erreur pendant sa conception est difficilement récupérable par la suite. Le modèle E/A a pour caractéristiques d’être simple et suffisamment puissant pour représenter des structures relationnelles. Surtout, il repose sur une représentation graphique qui facilite considérablement sa compréhension. En revanche, il admet certaines ambiguïtés.
La présentation qui suit est délibérement axée sur l’utilité du modèle E/A dans le cadre de la conception d’une base de données. Ajoutons qu’il ne s’agit pas de concevoir un schéma E/A (voir un cours sur les systèmes d’information), mais d’être capable de le comprendre et de l’interpréter.
La réalisation d’une Base de Données implique trois grandes étapes (voir figure ??) :
10 1 Introduction : modélisation des données
Modélisation {
Implantation {
Fig. 2.1: Grandes étapes de la conception d’une base de données.
Nous allons nous intéresser ici à la deuxième étape.
Un modèle des données (« data model ») est une description formelle et structurée des données et de leurs relations dans un système d’information.
Pour obtenir un modèle des données, il faut trois grandes phases :
Nous nous concentrons dans la suite sur la deuxième phases.
La méthode de conception permet de distinguer les entités qui constituent la base de données, et les associations entre ces entités. Ces concepts permettent de donner une structure à la base, ce qui s’avère indispensable. Nous commençons par montrer les problèmes qui surviennent si on traite une base rela- tionnelle comme un simple fichier texte, sans se soucier de lui donner une structure correcte.
Les redondances (duplications) présentes dans la table faite sans précaution peut conduire à plusieurs types de problèmes :
