Architectures, modèles et langages de données

Transcription

1 Architectures, modèles et langages de données Ingénierie des bases de données Hypercube c,d OLAP Volume I Fascicule 1 Architecture fonctionnelle du logiciel SGBD et diagramme de classe UML André Gamache 2005

2

3 2 Architectures, Modèles et Langages de Données Volume 1 Fascicule 1 1- Introduction 1 2- Architecture fonctionnelle du SGBD Modèle conceptuel des données 79 INDEX Fascicule 2 4- Modèle relationnel : théorie et contraintes d intégrité 1 5- Algèbre relationnelle Transposition du MCD au MRD 137 INDEX Volume 2 Fascicule 3 7- Langage de données SQL 1 8- Indexation, vue relationnelle et base réactive 123 INDEX Fascicule 4 9- Langage de programmation et SQL Théorie de la normalisation relationnelle FN1 à FN Optimisation des requêtes relationnelles 117 Annexes : A- SQLoader B- Projet ALU-Nord : Script de chargement INDEX

4 3

5 4 Chapitre 1 Introduction générale à l exploitation des données Introduction Le domaine des bases de données est maintenant quasi un lieu commun pour une vaste clientèle des systèmes informatiques, allant de l utilisateur occasionnel de la micro informatique au spécialiste chargé par les organisations de concevoir, de mettre en oeuvre et de gérer les grands systèmes de gestion de données qui sont essentiels à leurs activités. Les bases de données sont désormais un élément incontournable de tout système de traitement de lʹinformation qui se doit dʹêtre performant et évolutif. La terminologie du domaine des bases de données est parfois ambiguë et polysémique, surtout si elle est prise hors contexte. Nous commencerons donc par présenter quelques concepts clés du domaine avec un certain niveau de généralité parce quʹune seule définition ne peut pas rendre compte facilement de toute la complexité et des nuances qui prévalent dans différents contextes technologiques. 1.1 Base de données Une base de données (BD) est un ensemble de structures créées à l image d un modèle de données et gérées pour stocker des informations (représentées par les données) dans le but dʹeffectuer subséquemment des recherches et des mises à jour. Cʹest en quelque sorte la représentation structurée et codée de lʹinterprétation (par le concepteur) dʹune réalité organisationnelle qui est en constante évolution dans le temps. La base de données peut être centralisée ou répartie (distributed) et elle est accessible aux concepteurs dʹapplications et à leurs utilisateurs par lʹintermédiaire dʹune gamme de moyens informatiques soit du simple terminal à la station de travail, et cela pour manipuler les objets ou les structures les plus simples jusquʹaux objets graphiques implémentés avec des structures de données beaucoup plus complexes. Logiciel de gestion de base de données (SGBD) Le logiciel SGBD est un ensemble de procédures partagées par tous les utilisateurs pour la création et la manipulation des données (1) avec une garantie de cohérence, de consistance dans les opérations et de persistance des ajouts ou des modifications transactionnelles. Les procédures du moteur SGBD coopèrent pour exploiter et gérer les structures de données complexes qui utilisent le chaînage, l adressage calculé (Hashing), le B arbre et le regroupement (clustering) des données, à la fois pour le stockage et la recherche. Conception dʹune base de données La conception dʹune base de données sʹinscrit dans l ensemble des opérations d analyse informatique concernant la définition des données, des types (structures) et des associations entre les données et la spécification des contraintes. Pour effectuer ce travail, les concepteurs utilisent une méthodologie dʹanalyse qui peut privilégier soit une approche globale de l organisation, soit une autre qui exige lʹintégration des données exploitées pas les applications existantes. Une fois la conception terminée, il faut dresser en quelque sorte les plans et les devis des traitements et des données qui sont notamment représentés sous forme de modèles

6 Chapitre 2 Architecture fonctionnelle du SGBD 2 documentés avec le diagramme de flux de données (DFD), le modèle conceptuel de données (MCD) et le modèle logique de données (MLD) qui deviendra celui de lʹimplantation. Ces documents de base sont essentiels aux concepteurs pour favoriser une bonne communication avec les utilisateurs et donner au système cible le niveau de maintenabilité exigé par tout système complexe qui doit évoluer en fonction des besoins de l organisation. Ils permettent aussi d expliciter et de délimiter le rôle et les fonctions du système de gestion des données et de conscientiser les concepteurs et les utilisateurs quant aux limites de celui ci. De nos jours, la modélisation tend à incorporer une vision plus dynamique des données en y incluant les traitements et les événements qui en sont les déclencheurs. Ces activités sont représentées par un modèle de traitement et par un autre dit transactionnel. 1.2 Rôle central du SGBD Le logiciel SGBD doit fournir un environnement riche et efficace pour stocker, retrouver et modifier les données dans une base tout en respectant leurs propriétés structurales ainsi que les contraintes de sécurité qui sʹimposent dans un contexte multiposte où le partage des données et l accès à celles ci sont des privilèges accordés aux utilisateurs dʹaprès leurs fonctions dans lʹorganisation. Le logiciel est en exécution sur une machine serveur ou sur une machine centrale et répond aux requêtes de service en provenance de clients répartis en différents endroits et reliés par lʹentremise dʹun réseau. La communication entre le client et le serveur est assurée par le logiciel qui implémente la couche transport TCP/IP de Ethernet. Utilisateur Application TCP -IP TCP -IP SGBD BD Côté Client Côté serveur Architecture client serveur Figure 1.1 En dʹautres termes, le logiciel SGBD se comporte comme un logiciel serveur sur la machine attendant des requêtes des clients sur un port particulier pour ensuite déclencher le calcul de la réponse à partir des données de la base. Les structures de données de la base sont très riches (listes, B arbres, adressage calculé, fichier Heap etc.). La structuration détaillée des données devient rapidement impossible à saisir tant la structure est complexe. Il a fallu inventer une représentation générique de ces structures de données pour masquer leur complexité, tout en offrant aux utilisateurs une vision simple leur permettant de représenter les données et leurs associations pour pouvoir par la suite les exploiter efficacement. Le rôle de l application client est de traiter localement les données obtenues selon une logique propre à chaque application et d en afficher les résultats en faisant appel à un sous système de gestion de fenêtres. Importance du volume des bases de données

7 Chapitre 2 Architecture fonctionnelle du SGBD 3 La nécessité de gérer efficacement de plus grands ensembles et de nouveaux types de données s impose principalement en raison de l importance croissante des données dans les processus décisionnels. Ce volume de données exorbitant entraîne son lot de problèmes. Il y a déjà longtemps, T. Tomita (2), estimait quʹen 1960 le volume de lʹinformation publique transmise par les journaux était de 0,66 x bits et quʹil triplerait en Sa prévision faite à lʹaube de lʹère informatique nous apparaît maintenant bien en dessous de la réalité. La croissance du volume des données se fait sentir particulièrement dans les pays industrialisés où le fonctionnement et la gestion sont tributaires dʹun accès sûr et universel aux données de lʹorganisation (3). Le mot d ordre dans le fonctionnement des organisations est de fournir directement les données nécessaires aux utilisateurs afin de rapprocher la décision de l action. Cʹest dʹailleurs la base du concept de lʹentrepôt de données (data warehouse) qui constitue un immense réservoir de données cumulées dont l exploitation fine permet d extraire de nouvelles informations au moyen d outils d analyse et de synthèse (data mining). La généralisation des accès à lʹinternet et la mise en place de bibliothèques électroniques (digital library) accessibles de par le monde soustendent leur gestion à partir des supports informatiques. La capacité des disques et la vitesse de transmission des données ont atteint des niveaux que lʹon pouvait difficilement prévoir il y a dix ans. Le volume des données est devenu très important. Il suffit de songer à la taille de la base de données nécessaire pour gérer les données de type multimédia acheminées sur l inforoute de l Internet. Combien de millions dʹoctets faut il pour stocker 60 secondes de son ou une séquence vidéo de deux minutes? Quel espace faut il pour stocker un catalogue de pièces mécaniques pour l industrie de l automobile? Quelle est la valeur utilitaire de cette masse de données? Quels sont les mécanismes d accès les plus appropriés pour retrouver ces données? Comment découvrir un ensemble de pièces musicales sur la base de leur contenu? Des centaines voire des millions de mégas octets sont nécessaires pour stocker ces nouvelles informations gérées par ordinateur. Ces quelques faits révèlent lʹimportance du volume des données et laissent entrevoir le rôle des bases de données avec leur environnement technologique pour stocker ces données complexes et en permettre subséquemment le rappel et l affichage. Sans un logiciel spécialisé, des disques rapides RAID et un processeur de grande puissance, l accès à une base de données de grande taille ayant des objets de types très divers peut devenir un cauchemar pour qui en est le gestionnaire. Déjà les besoins se faisaient sentir dans les années 80 lorsque le développement écoique se profilait au développement du secteur des services et à l informatisation des moyens de production. En 1979, Williams (4) publia une courbe de croissance des bases de données textuelles, qui laissait voir un rythme qui doublait sur une période de quatre ans. A titre dʹexemple, considérons la croissance estimée du volume des données par Williams 4, Bien que la réalité des années 2000 rende ces données largement caduques, elles ont le méritent dʹillustrer la croissance des données depuis la première phase du cycle d informatisation des organisations. Description Nombre de bases de données textuelles (USA) Nombre d enregistrements (en millions) Nombre base de données (autres pays développés) Nombre d enregistrements (en millions)

8 Chapitre 2 Architecture fonctionnelle du SGBD 4 Figure 1.2 Ces repères de plusieurs années permettent dʹapprécier les volumes importants de données à stocker et ultérieurement à recouvrer, ce qui ne peut pas se faire sans une augmentation de la puissance des machines, de la capacité de stockage des systèmes et de la puissance des logiciels de gestion des bases de données. Pour terminer, plusieurs auteurs soulignent que seulement 10% des informations sont gérées par des systèmes informatiques et que inévitablement les volumes de données vont augmenter avec la généralisation de la saisie des données à la source! La charge qui sera soumise aux bases de données s annonce colossale. Plus récemment, Lyman et Varian ( 5 ) de l Université de Californie à Berkeley estimait que l augmentation du volume d information avait augmenté de 30% depuis 1999 pour atteindre en 2002 un sommet de 5,4 pecaoctets (10 18 octets). Très approximativement, 40% de cette nouvelle information serait produite par les USA dont la moitié serait enregistrée sur un support permettant une lecture digitale. Pour ne pas sombrer dans la pollution ou hégémonie informationnelle aigue, de bons outils de stockage et de recherche pointue voire discriminante seront nécessaires pour répondre aux besoins du marché. Dans une enquête centrée sur les bases de données réalisée par lʹinternational Oracle User Week (IOUW) (6) auprès des DBA (Database Administrator) participant aux conférences annuelles de 1993 et 1994, il appert que la taille la plus fréquente de la base opérationnelle soit de 2,2 Go et que la moyenne se situe autour de 14 Go. En 1994, la taille moyenne est passée à 17 Go, tandis que la taille médiane de la base a augmenté de 38 % par rapport à celle de Le bre moyen dʹutilisateurs de bases de données va aussi quadrupler dans cette seule année, pour atteindre près de 210 utilisateurs par base Oracle. Au Québec, la Régie de lʹassurance Maladie (RAMQ) gère en ligne les trois dernières années de prestations médicales. Par exemple, pour 1993 à 1996, cela représente une base de plus de deux milliards dʹenregistrements. Le volume est tel quʹune réorganisation impliquant un rechargement est une opération lourde puisquʹil faut près de deux mois pour le réaliser et cela, avec des ordinateurs puissants dotés d une technologie de pointe. Lʹimagination est mise au défi lorsquʹil sʹagit dʹestimer les volumes de données qui seront générés par le commerce électronique dont les spécialistes prédisent une généralisation progressive peu après lʹentrée dans le troisième millénaire! Lʹévolution des bases de données est donc marquée par lʹaugmentation prévisible des volumes de données caractérisés par une plus grande diversité des types de données, notamment pour y inclure les images et le son. Pour mieux illustrer lʹévolution des bases de données, nous les classerons en cinq groupes distincts sur la base de leur volume. Chaque catégorie a ses caractéristiques et ses logiciels de gestion. Il est aussi à prévoir que les grandes bases seront pour les prochaines années une préoccupation majeure pour les grandes organisations tant les investissements en personnel, en matériel et en logiciel seront importants. 1.3 Typologie des bases de données

9 Chapitre 2 Architecture fonctionnelle du SGBD 5 Le classement des bases de données par leur volume donne les catégories relatives suivantes qui mettent en perspective leur importance relative dans le fonctionnement des organisations : La base de données individuelle renferme des données personnelles avec quelques milliers de données utilisant quelques centaines d octets pour leur stockage. Tout va pour le mieux! Son exploitation est souvent locale et l accès aux données réalisé avec une bonne performance. Il existe de bons outils sur des ordinateurs de bureau, disponibles à des prix intéressants ou à titre de logiciel libre (Open Source) et qui permettent de gérer ces ensembles de données personnelles relativement importants. Dans les années à venir, certaines de ces bases pourront être davantage individualisées et acquérir le statut de portable sur une carte à puce dotée d un ordinateur embarqué (smart card avec flash memory) ou stockées dans des ordinateurs portables (laptop, palm computer). Ces bases portables deviendront accessibles à des agents intelligents mandatés pour propager ou collecter des données à partir de bornes Internet de données. La base de données dʹavant 1985: Une base type comprend moins de données essentiellement numériques et nécessite près de 2 Mo de mémoire de stockage. Avec cette base, il y a des problèmes de partage de données assorti de performance que le DBA doit surveiller et résoudre. Comme ces données sont souvent jugées essentielles au fonctionnement d une organisation, il faut un accès relativement rapide avec des outils puissants qui nécessitent un investissement moyen pour le logiciel et le matériel. Ces bases sont souvent associées à des fonctions spécialisées et vitales dʹune organisation comme par exemple lʹinventaire dʹune entreprise manufacturière, le système des ventes ou le système de facturation. La base de données après les années 1995 : La mega base de données (x10 6 ) peut comporter autour de données, ce qui suppose quelques dizaines de gigas octets de stockage. À ce niveau, le volume des données, leur complexité, les problèmes de gestion des structures de stockage, de performance et d accès apparaissent avec plus dʹacuité. Les logiciels dʹexploitation sont maintenant de type multiposte, plus coûteux et exigeants en termes de ressources informatiques: matériel, logiciel et ressources humaines spécialisées. Les problèmes d archivage deviennent encore plus évidents et les solutions plus complexes et coûteuses. Le stockage des données multimédias apparaît comme un nouvelle exigence pour les systèmes ce qui accentue le problème de vitesse dʹaccès et dʹespace disque. Lʹinfrastructure de réseau est heureusement en place et les disques rapides de type RAID sont maintenant un atout. Le poste budgétaire de l informatique est devenu très important pour un grand bre d organisations. La base de données des années 2000 : La giga (x10 9 ) voire même la térabase de données (x ), plus de données disponibles en ligne qui occupent un espace de plus de 1 To. Les problèmes critiques sont ceux du stockage, de la performance, de lʹaffichage, de lʹarchivage et de la vitesse du réseau. Les logiciels sont encore plus coûteux et souvent spécialisés. Les disques RAID sont nécessaires, sous tendant souvent lʹutilisation des architectures multiprocesseurs pour avoir une performance appréciable. Les données acquièrent de plus en plus leur lettre de noblesse pour nourrir l intelligence écoique mise à jour par les logiciels de data mining. Une entreprise peut alors mieux connaître ses concurrents et d anticiper les besoins de ses marchés. C est le début de l ère de l entrepôt de données.

10 Chapitre 2 Architecture fonctionnelle du SGBD 6 La base de données du futur: La térabase (x10 12 ) ou l exabase (x10 18 ) base s impose graduellement comme une réalité; avec autant de données, tout est ou devient problème! Quelques grandes organisations privées ou gouvernementales commencent à ressentir ces difficultés associées aux volumes de cette importance, particulièrement depuis l avènement des documents multimédias dans les bases de données et la généralisation planétaire du courrier électronique et des documents digitaux. Pour stocker des images animées couleurs et muettes, il faudra stocker 15 Mo à la seconde! La tendance à fusionner tous les types de données entraîne alors des problèmes d espace, de vitesse de communication sur réseau (100 Mbps) Les interfaces complexes et robustes pour stocker et surtout rechercher rapidement les données historiques des organisations (data warehouse). A ce niveau de volume, la centralisation des données n est plus un préalable ; la répartition et l hétérogénéité des données deviennent des alliés et non des faux amis! catégorie volume de données (approx.) taille Débutant Plus de 250 Ko Avant Mo 1995 et Mo Années Go (10 9 ) BD du futur To (10 12 ) Figure 1.3 Cette plus grande disponibilité des données sʹaccompagne aussi dʹune croissance importante des coûts dʹexploitation et des investissements dans la mise en oeuvre des infrastructures. La figure 1.3 présente les différentes bases de données et leurs volumes repères. Ces chiffres sont des approximations pour illustrer lʹévolution de la taille des bases de données. La réalité risque dʹêtre plus exigeante en matière dʹespace de stockage, ainsi quʹen puissance de traitement et de vitesse des réseaux. Il est évident que les bases de données sont en pleine croissance et cela, en bre et en volume. Les espaces de stockage et les moteurs SGBD devront être adaptés à ces nouveaux défis en offrant des disques de plus de 500 Go/disque gérés par des contrôleurs multidisques et des systèmes multiprocesseurs dotés de mémoires communes. Les systèmes dʹexploitation sont déjà prévus pour gérer ces types dʹordinateurs et intégrer davantage les fonctionnalités des réseaux. En résumé, lʹévolution rapide des besoins en matière de stockage et de traitement des données a créé des attentes qui imposent de nouvelles fonctionnalités aux SGBD et des conditions dʹexploitation beaucoup plus exigeantes : a) La transparence des données transmises aux applications : formats différents variant du type primitif au type abstrait, cette dernière structure étant nécessaire pour les documents graphiques et sonores, etc. b) La confidentialité des données : gestion de la visibilité des données, des droits d accès et du suivi de l usage des données pour les usagers distants utilisant une vue partielle de la base. Le chiffrement par les algorithmes spécialisés bien connus DES, RSA ou Telepass et compaction

11 Chapitre 2 Architecture fonctionnelle du SGBD 7 des données multimédias sont maintenant des exigences courantes de la gestion des données et de leur exploitation dans les systèmes de commerce électronique. c) Le renforcement des contraintes de cohérence plus complexes définies dans le modèle de données. Par exemple, une contrainte peut être formulée ainsi : un employé ne peut pas avoir un salaire annuel supérieur à celui de la moyenne des salaires consentis aux cadres de niveau 2, ou encore un solde d inventaire ne peut pas franchir la barre inférieure de 20 articles lorsque le carnet de commandes est rempli aux deux tiers de sa capacité. Ces contraintes seront implémentées par le SGBD et non par les applications et ce, pour garantir l uniformité de leur implémentation. Elles sont vérifiées automatiquement par des déclencheurs ou des procédures internes à la BD afin de mieux garantir lʹintégrité des données et cela au regard des règles qui prévalent dans le fonctionnement de l organisation. d) Lʹaccès multiposte et concurrent aux données s impose de plus en plus avec un grand volume de transactions peu importe si l approche est centralisée ou client serveur. Les grands systèmes transactionnels doivent maintenant pouvoir traiter des volumes de transactions qui dépassent le cap des 1000 transactions à la minute. L horizon des débits de transactions de l ordre de 2000 à la seconde est déjà perceptible! La puissance des processeurs utilisée par les serveurs et la rapidité des disques permettent de répondre à ces exigences d exploitation. Les organisations doivent cependant y investir des sommes importantes. 1.4 Évolution des logiciels pour la gestion de données Les logiciels SGBD multitâches et parallèles présentement en service sont l aboutissement d une évolution technologique des logiciels pour la gestion des données dont les premières versions exploitaient essentiellement le gestionnaire de fichiers du système dʹexploitation hôte (OS SGF) comme par exemple, RMS (Record Management Storage) de l ancienne société Digital Equipment Corporation et VSAM (Virtual Storage Access Method) de la société IBM. Par la suite, les logiciels SGBD ont évolué vers une plus grande autoie par rapport au système dʹexploitation en prenant à leur charge la lecture et lʹécriture des records et des pages sur les disques, en plus de gérer les transactions et de leur recouvrement en cas de panne. Fonctionnalités courantes du logiciel SGBD Ce logiciel spécialisé et complexe intègre donc les services de base offerts par les systèmes de gestion de fichiers et offre en sus une gamme étendue de fonctionnalités nouvelles. Parmi celles ci, mentionnons les suivantes : a) La description des données (appelée couramment les métadonnées) est ajoutée au dictionnaire et devient incontournable pour accéder au contenu de la base. b) Lʹindépendance des données et des applications est renforcée en reconnaissant plusieurs niveaux de métadonnées. Cette vision multiniveau permet de séparer les aspects logiques et physiques des structures de données. Ainsi, les changements de structure de la base de données nʹont plus dʹimpacts majeurs sur les applications et inversement. c) Lʹusage d un outil de gestion de l abstraction des données (l usage d un modèle de représentation générique des données et de leurs associations) permet de visualiser plus facilement la complexité des structures de données et de les spécifier par un langage de description compatible avec le logiciel SGBD. Les structures logique et physique des données

12 Chapitre 2 Architecture fonctionnelle du SGBD 8 peuvent être alors obtenues à partir dʹun modèle de haut niveau dit conceptuel qui ne tient pas compte des particularités tributaires de l implémentation de chaque SGBD. d) Le partage contrôlé et sécurisé des données est généralisé pour toutes les applications développées par une organisation centralisée ou répartie. 1.5 Abstraction des données La notion dʹabstraction des données concerne la représentation générique des données (souvent par un modèle graphique) et des associations qui leur donnent un sens plus riche. De plus, les traitements essentiels sur le modèle sont pris en compte dès l étape de la spécification du modèle. Plusieurs genres de modèles sont proposés, tous caractérisés par leur indépendance au regard du logiciel SGBD. Ces modèles dits conceptuels sont de plus en plus riches sur le plan de la représentation et visent à décrire les données et leurs traitements pour coller le plus possible à la réalité opérationnelle des organisations. Le processus d abstraction des données permet essentiellement de spécifier les structures des données à plusieurs niveaux et dʹesquisser la logique de traitement par les applications. Le produit de cette abstraction est le modèle conceptuel de données (MCD). Niveaux de représentation des données Il y a trois niveaux d abstraction reconnus dans la modélisation des données lesquels correspondent respectivement aux besoins des utilisateurs, des développeurs et à ceux du DBA : a) Le niveau conceptuel : Cʹest le niveau supérieur où les structures physiques et les fichiers sont ignorés pour accentuer la description sémantique des données vue par rapport à la réalité d une organisation. On tente de décrire les données de lʹorganisation en conservant le plus possible les liens entre elles. On met aussi lʹaccent sur l homogénéité et le partage du des éléments de données et de leur type ou structure logique. Le modèle conceptuel est stocké dans le catalogue (dictionnaire) du logiciel SGBD. Exemple : Le fait contraignant quʹun employé travaille obligatoirement dans une ou plusieurs usines et cet autre fait que dans une usine travaillent obligatoirement de un à plusieurs employés doivent être représentés le plus fidèlement possible par le modèle conceptuel. Application-1 (vue-1) Application-2 (vue-2) Application-3 (vue-3) Modèle conceptuel des données Mapping: Externe-Conceptuel Détails croissants Modèle logique Mapping: Conceptuel-Interne Modèle physique

13 Chapitre 2 Architecture fonctionnelle du SGBD 9 Figure 1.4 b) Le niveau physique : Cʹest la description physique des données faite par le DBA (Database Administrator). Cʹest à ce niveau quʹil faut spécifier lʹorganisation physique, les structures de stockage et les modes d accès possibles. Ces métadonnées de niveau 2 sont essentielles pour que le SGBD réalise lʹaccès physique aux données. c) Le niveau externe : C'est la vue de la base de données sous l'angle d une application particulière. Les données doivent être dans un format compatibles avec celui du langage de programmation, sinon le SGBD devrait en assurer la conversion. Les divers niveaux de description seront formalisés par un Langage de Définition des Données (le LDD ou en anglais le DDL) propre à chaque logiciel SGBD. Ce langage doté d une syntaxe relativement simple permet de définir les données visibles et accessibles à chaque application. Vues logiques de la structure de la base de données Chaque application utilise un sous ensemble de données, c est à dire une vue particulière de la base selon les besoins de la logique de son traitement (figure 1.5). La vue est bien sûr définie différemment selon les modèles de données, mais son rôle demeure le même soit de contraindre une application à exploiter que certaines données, soit en mode mise à jour, soit en mode lecture. Elle est aussi dynamique dans le sens quʹelle donne une vision des données qui reflète toujours le dernier état de la base de données. Elle peut être illustrée approximativement par les parties tramées encadrées par une ligne pointillée. Vue ClientIndustriel Produit Matériau Les parties encadrées sont des vues. Modèle conceptuel et les vues Figure 1.5 Par exemple, une application mé ClientIndustriel est autorisée à exploiter qu une partie des données Client et une autre partie des données Matériau. Les autres attributs lui sont alos interdits d accès via le modèle externe.

14 Chapitre 2 Architecture fonctionnelle du SGBD 10 Description des entités (instances) de la classe Client Considérons une base de données très simple avec quelques classes (connues sous l appellation Entités ou Entity Type) dont une mée Client. Celle-ci est définie par son schéma, c'est-à-dire par sa structure spécifiée par un langage de description qui est particulier à chaque système SGBD. Ce langage (DDL pour Data Definition Language) permet de décrire la structure logique de la classe et le type de chaque élément qui la compose sans cependant faire mention des implémentations et des traitements possibles. Le schéma de la base de données comportera donc autant de définitions qu'il y a de classes. Par exemple, la structure de la classe Client est spécifiée différemment selon le niveau de représentation : a) Au niveau conceptuel, la structure logique du dossier Client pourrait être la suivante : Client = record, patronyme: string 30, adresse: string 20, ville: string 15, nocompte: integer; Les libellés et les types de données peuvent être ceux implémentés et rendus disponibles par le logiciel SGBD. Ils sont utilisés pour la description de la classe Client. En principe, une application peut accéder à la classe Client à travers une vue particulière définie avec des types qui correspondent plus précisément aux données dont elle a besoin pour ses traitements et qui de préférence devraient être ceux du langage utilisé pour le traitement. Dans le cas contraire, il y aura une conversion (casting) des données à la charge de l application ou du logiciel SGBD selon le cas. La structure qui est visible par la vue est dite externe. b) Au niveau externe, la structure exploitée par lʹapplication est généralement légèrement différente en termes de libellés, de types et dʹattributs. Ainsi, la partie du Client visible à une application mée ClientRegion a une structure définie ainsi : ClientRegion = record based on Client : string 20, null, /*attribut adresse n'est pas utile à l'application*/ municipalite: string 15, comptebancaire: string 5 ; Les éléments de la vue externe peuvent être différents en bre, en déination et en type au regard de ceux utilisés par le modèle conceptuel. Dans lʹexemple ci dessus, la vue ClientRegion représente les clients de Québec. Les applications qui utilisent cette vue nʹexploitent pas lʹélément adresse de sorte que celui ci nʹest pas spécifié dans la vue et son gommage virtuel est signalé à l interne par un indicateur d absence appelé le null. c) Le niveau physique Au niveau 3, le physique, les éléments de la structure de Client sont définis par rapport aux caractéristiques des structures de stockage disponibles et mises en oeuvre. Voici un exemple hypothétique du schéma physique :

15 Chapitre 2 Architecture fonctionnelle du SGBD 11 Elément rang position type longueur volume patronyme rd40 adresse rd40 ville rd40 pointeur de suite rd40 Figure 1.6 Le passage (mapping) d un niveau de représentation à l autre est assuré par le SGBD, notamment par des procédures internes qui permettent la consultation et l utilisation des métadonnées du dictionnaire du SGBD. Ce dernier est stocké dans la base elle même en utilisant les même structures que celles des données. Comme il s agit de données qui décrivent les données de la base, elles sont libellées métadonnées. Application DD SGBD BD Système de fichiers Figure 1.7 Dictionnaire de données Le dictionnaire de données (DD) est donc souvent une métabase qui contient les informations pour réaliser les diverses transpositions de schémas, pour exploiter au plus bas niveau d implémentation les structures des fichiers et pour vérifier les droits dʹaccès, les formats et les contraintes imposées aux données. Le dictionnaire de données est donc un dépôt d informations essentielles à lʹexploitation de la base. Tout ordre DML de manipulation des données exige un accès au dictionnaire par le noyau du SGBD et cela, afin de trouver le interne des éléments de données du schéma et les adresses nécessaires pour accéder aux structures de données sur disque. En cours de traitement, les métadonnées sont généralement chargées à demeure dans la RAM, et cela afin de minimiser les accès aux disques qui ralentissent le temps de réponse aux requêtes des applications. Opérations de mise en oeuvre de la base de données La mise en oeuvre dʹune base de données comporte de breuses activités qui appartiennent à des phases différentes dʹun projet, et qui sont réalisées lors de lʹanalyse informatique : a) Conception: Mise au point du modèle conceptuel, définition des tables, des domaines, des types de données et des contraintes. C est la création des métadonnées et leur stockage dans le dictionnaire. b) Création : Allocation des espaces physiques et chargement des données de la base.

16 Chapitre 2 Architecture fonctionnelle du SGBD 12 c) Exploitation: Insertion, suppression, modification et indexation des données en toute sécurité tout en garantissant intégralement la cohérence de la base. d) Gestion de la BD : Définition des droits dʹaccès, de la stratégie de reprise après une panne, gestion des copies de sûreté et indexation des données. Le SGBD fournit un langage de manipulation des données (appelé LMD ou DML pour Data Manipulation Language) composé de clauses dont la syntaxe est relativement simple. Ces clauses DML permettent de spécifier ce qui doit être recherché, mis à jour, supprimé ou ajouté dans la base. Les ordres DML types sont le SELECT, INSERT, le UPDATE et le DELETE. Souvent, la clause SELECT est considérée à part, comme une requête qui est de loin la clause la plus complexe. Depuis quelques années, le langage SQL et le DML proposés par le comité de normalisation ISO sont de plus en plus adoptés par les grands éditeurs de SGBD. Il y a essentiellement trois modes d implémentation du SQL et du DML : a Langage de requête autoe Le langage autoe peut être utilisé directement pour manipuler la base de données sans avoir nécessairement besoin de lʹenvironnement dʹun langage hôte. Il permet essentiellement la mise au point des clauses de requête, mais ne permet pas le traitement des données obtenues dans la réponse, sauf s il est intégré dans un langage de programmation de troisième (L3G) ou de quatrième génération. Voici, par exemple, une question simple à traiter par le système : «Lister éditeur et le titre du livre répertorié avec le ISBN 4578» Cette requête traduite en pseudo langage DML serait alors la suivante : LIST editeur, titre FROM Livre WHERE ISBN = 4578 ; Pour exécuter cette requête et afficher la réponse, l interpréteur du DML devra lancer une procédure interne LIST dont les paramètres sont le de lʹentité (Livre) et le prédicat de recherche (Where). b DML intégré dans une application 3 ème génération (L3G) Les ordres DML sont placés dans un programme L3G (Pascal, PL/1, ADA, C, C++, Java) et chaque ordre est exécuté séparément. Il y a deux façons de traiter les ordres DML imbriqués : a) Par traduction : le précompilateur reconnaît les ordres DML identifiés par un délimiteur particulier comme le # ou le EXEC SQL, et les transforme en appel de procédure du langage hôte pour ensuite passer à la phase compilation. Par exemple: Le système VAX/DBMS utilise le délimiteur # pour annoncer un ordre DML : # FIND FIRST editeur FROM Livre USING ISBN = 4578; # FIND FIRST titre FROM CollectionDeLivre USING ISBN = 4578;

17 Chapitre 2 Architecture fonctionnelle du SGBD 13 b) Par compilation avec un compilateur étendu : le compilateur reconnaît les ordres DML identifiés par un marqueur spécial et les traduit directement en code du langage de 3 e génération (par exemple en C ou en COBOL). Exemple : { int no_isbn;... gets (no_isbn); editeur_v = dbmslist ('editeur','publication', 'ISBN = no_isbn'); titre_v = dbmslist ('titre','collectiondelivre', 'ISBN= no_isbn'); printf('editeur = %s titre = %s \n',&editeur_v,&titre_v); } Figure 1.8 La fonction dbmslist() permet de transmettre les arguments au processus SGBD avec une adresse de retour utilisée pour récupérer les données de la réponse. c Langage de quatrième génération (L4G) Le langage de 4 e génération est de type autoe auquel on a ajouté les structures de contrôle pour lʹitération et lʹalternative. Lʹenvironnement dʹun L4G inclut généralement une interface graphique pour faciliter la composition des modules et des panoramas : NOMAD, FOCUS, PROC, Developer/Forms (Oracle), PowerHouse, etc. Un programme complet peut alors être élaboré et inclure les ordres DML et cela, avant sa traduction par un compilateur spécialisé. d Interface d application (API) Une API est une bibliothèque de fonctions utilisées par les applications pour communiquer directement avec un SGBD. Ces fonctions dotées généralement de plusieurs paramètres réfèrent aux procédures des DML développées par chaque SGBD, dont l une gère la communication par les sockets. Une telle bibliothèque peut être normalisée afin de fournir une interface commune pour lʹaccès aux données, peu importe le SGBD et cela, par lʹentremise dʹun pilote (driver) particulier. Cela renforce l indépendance de l application à lʹégard du SGBD. Les interfaces ODBC (Open Data Base Connectivity) et SAG (SQL Access Group) sont des propositions pour une API normalisée. Ces efforts de normalisation visent à pérenniser les applications en les rendant encore plus indépendantes du SGBD. 1.6 Administrateur de la base de données L administrateur de la base (DBA) est devenu un acteur incontournable dans la gestion des données corporatives. Sa fonction est de gérer la création et le fonctionnement général de la base de données en surveillant particulièrement le placement des données, la performance des accès et les autorisations consenties aux utilisateurs. Il est aussi souvent responsable du fonctionnement du réseau, de la prise des copies de sûreté et du fonctionnement des ordinateurs serveurs. Voici quelques tâches qui incombent généralement au DBA :

18 Chapitre 2 Architecture fonctionnelle du SGBD 14 a) Le contrôle du logiciel et des métadonnées. b) La gestion de la base : localisation, indexation, allocation des espaces sur disque, stratégie de reprise et de sauvegarde (Backup). c) La coordination du développement modèle conceptuel : arbitrage et médiation entre les concepteurs de systèmes et les usagers. d) Lʹautorisation des vues et des droits d accès. e) Le contrôle de l évolution du MCD ainsi que de la réorganisation de la BD qui en découle. f) La surveillance de la performance du SGBD et la réalisation des mises au point (fine tuning). g) Le choix du matériel au regard des exigences du SGBD et des traitements escomptés. h) La définition des déclencheurs (triggers) et des procédures internes (packages) stockés dans le dictionnaire de la base de données. Ces dernières permettent dʹimplémenter les règles dʹintégrité et de validité. La diversité et la spécialisation des tâches exigent une vaste connaissance de la part du BDA. Typologie des utilisateurs De breux utilisateurs participent à l exploitation des données et en utilisent les résultats pour les fins de gestion organisationnelle. Dans certaines organisations, ils participent activement à la conception de la base de données. Il est possible de regrouper approximativement les utilisateurs en trois catégories : a) Les utilisateurs occasionnels : Ils privilégient le langage de requête en mode interrogation pour obtenir des réponses courtes du genre factuel ou agrégé. Souvent, les requêtes sont de type décisionnel. Pour les cadres moyens et supérieurs, les requêtes ont un caractère de synthèse soutendant l agrégation des données : tableau de bord, applications avec menus, OLAP... Ces utilisateurs ont besoin d un langage de requête performant imbriqué dans une interface très conviviale. b) Les utilisateurs réguliers de niveau opérationnel : Ils utilisent des programmes spécialisés et encapsulés dont les fonctionnalités sont fixées à l avance pour offrir une gamme limitée de services. Ils génèrent des requêtes transactionnelles. c) Les utilisateurs spécialistes : les concepteurs sont les artisans des applications au des utilisateurs. Leur travail est caractérisé par les facettes suivantes : Usage de L3G, L4G, DML et API. Traitements complexes pour implémenter une logique d application et mettre en œuvre des types complexes. Intervention critique dans les processus d affaires d une organisation. Bonne connaissance du SGBD et des autres environnements. Implémentation du mode transactionnel et la gestion des données multimédias. Impacts du logiciel SGBD pour les organisations L intégration du logiciel SGBD dans le système dʹinformation dʹune organisation a des effets positifs et parfois négatifs sur l organisation du travail des concepteurs. Voici quelques uns des effets positifs :

19 Chapitre 2 Architecture fonctionnelle du SGBD Les applications nʹont plus à gérer la redondance de données, celle ci est contrôlée par le SGBD. 2. Chaque application est, par définition, en concurrence pour le partage des données. La concurrence des accès est prise en charge par le SGBD quelle que soit l architecture de l environnement : centralisée, répartie, client-serveur ou web. 3. Lʹaccès aux données par une application est validé afin de renforcer la sécurité. 4. Lʹapplication client dispose de plusieurs interfaces spécialisées qui sont adaptées aux usagers (technologie GUI ou générateur dʹinterfaces). Il en découle une réduction du temps de développement des applications (estimé à 30 %) et une plus grande réutilisation des procédures développées avec ou sans un langage L4G. 5. Le renforcement des contraintes d intégrité est assuré par le logiciel SGBD. Cela simplifie les applications et garantit la vérification uniforme des règles d intégrité. Il y a donc au départ une incitation pour établir des standards dans la gestion et le traitement des données dʹune organisation. 6. En cas de panne, le recouvrement est pris en charge par le SGBD grâce à des utilitaires de reprise et de sauvegarde. 7. Le rôle de DBA est exigeant à plusieurs égards. Son titulaire doit manifester à la fois une maîtrise des techniques et avoir des qualités du chef de projet. Effets négatifs découlant de l exploitation du SGBD Le logiciel SGBD est parfois vu comme un super mécanisme d accès aux données. Les ressources mises en oeuvre dans ce logiciel sont importantes et, de ce fait, un SGBD demeure un outil particulier quʹil faut utiliser seulement lorsque lʹimportance des besoins de traitement lʹimpose. Malgré lʹusage répandue des SGBD, le concepteur doit être averti de certaines limites inhérentes à lʹintégration du SGBD dans un environnement dʹexploitation de données : a) Les frais dʹacquisition et dʹexploitation (matériel, logiciel, sécurité, personnel) sont relativement élevés et récurrents. Ils peuvent être bas pour un monoposte, mais ils augmentent rapidement avec le bre de stations autorisées à accéder aux données. b) Les applications en temps réel sont difficiles à réaliser avec un logiciel SGBD. En effet, un temps de réponse inférieur à 0,5 seconde avec un volume élevé de transactions est difficile à respecter, sauf si le SGBD est conçu pour un environnement temps réel. c) Le temps de réponse est souvent inacceptable pour un bre de requêtes (transactions) supérieurs à 1000 Transactions Par Seconde (TPS). Le traitement est cependant excellent pour un TPS qui se situe autour de 400. Toutefois, des machines dotées d architectures particulières permettent de briser cette barrière et traiter des charges de plus de 1500 TPS. d) En mode monoposte, l accès aux données qui sont peu structurées ne nécessite pas obligatoirement un SGBD : un gestionnaire de fichiers suffirait largement. L exploitation d une SGBD pour un tel besoin n est pas appropriée.

20 Chapitre 2 Architecture fonctionnelle du SGBD 16 e) La gestion des données multimédias (son, couleur, animation) est encore difficile, mais devient possible. Le stockage et le repérage posent problème pour ce qui est des structures de données, leur gestion, leur mise à jour et la gestion des versions. À ces difficultés, il faut ajouter des temps de réponse encore trop lents en raison de la vitesse (largeur de bande) encore insuffisante des réseaux. f) Le potentiel de déduction logique à partir des données de la base est encore une fonctionnalité théorique peu ou pas implémentée dans les systèmes commerciaux courants. Toutefois, la tendance est telle qu il est maintenant difficile de stocker des données sans avoir recours à un SGBD. En effet, le service de fichiers est de plus en plus absent dans les systèmes qui se limitent souvent à offrir un fichier séquentiel élémentaire. Tout autre accès plus complexe tel le direct ou le séquentiel indexé doit être mise en oeuvre par le client. 1.7 Architecture générale du système de gestion de bases de données (SGBD) Lorsqu une requête parvient au SGBD, par lʹentremise du logiciel de communication ou du réseau, l enchaînement des opérations pour calculer la réponse sʹappuie sur un ensemble de modules fonctionnels du noyau du SGBD qui sont regroupés sous les appellations fonctionnelles suivantes : EXECUTEUR et ACCESSEUR. Voici le rôle général de chaque module d un SGBD : Analyseur Analyse syntaxique Analyse sémantique Métabase Traduction Génération du plan d'exécution Contrôle d'intégrité Contrôle des autorisations Sous-système d'affichage Optimisation Calcul Modification du plan d'exécution selon les coûts et les règles Contrôle de la concurrence Atomicité de la transaction Exécution des opérateurs Base de données Accesseur Figure 1.9