Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke1 Systèmes de Gestion des Bases de Données Chapitre 1 Professeur: Iluju Kiringa

Présentation au sujet: "Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke1 Systèmes de Gestion des Bases de Données Chapitre 1 Professeur: Iluju Kiringa"— Transcription de la présentation:

1 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke1 Systèmes de Gestion des Bases de Données Chapitre 1 Professeur: Iluju Kiringa kiringa@site.uottawa.ca kiringa@site.uottawa.ca http://www.site.uottawa.ca/~kiringa SITE 5072

2 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke2 Définition d’un SGBD  Les organisations font face à de larges quantités de données qui doivent être gerées efficacement.  Une base de données est une très large collection de données intégrées.  Modèle le monde réel des organisations / enterprises.  Entités (p.ex., étudiants, cours, corps professoral et salle de cours)  Relation (p.ex., Michel est enrollé dans CSI3717; Iluju enseigne CSI3717, CSI3717 a lieu dans la salle MST207)  Un système de gestion des bases de données (SGBD) est un ensemble de logiciels conçu pour stocker et gérer des bases de données.

3 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke3 Défauts des Systèmes de Fichiers  Chaque application doit déplacer de large quantités de données entre la mémoire principale et la mémoire sécondaire (doit donc s’occuper p.ex. de la gestion des mémoires tampon, de l’accès aux pages, etc.)  Chaque application doit avoir une méthode d’identification de toutes les données pour le cas où le mode d’adressage sous-jacent ne suffit pas (p.ex., un adressage 32-bits ne peut pas directement accéder à des données dépassant plus 4GB.)

4 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke4 Défauts des Systèmes de Fichiers  Besoin d’un code special pour différente requêtes.  Besoin de protection des données d’inconsistences dues aux multiples usagers simultanés qui changent ces données.  Assurer un crash recovery consistant.  Fournir plus de sécurité et un contrôle de l’accès que le méchanisme de mots de passe offert par les système d’exploitation.

5 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke5 Pourquoi Utiliser un SGBD?  Indépendance des données : une application ne voit pas les détails de la répresentation et du stockage des données.  accès efficient : utilisation de méthodes de stockage et d’accès très sophistiquées.  Temps de développement d’applications réduit : les fonctionalités d’un SGBD n’ont pas besoin d’être dédoublées.  Integrité et sécurité des données : appliquer les contraintes d’intégrité et un contrôle d’accès.  Administration uniforme de données : des utilisateurs expérimentés administrent les données utilisées par des utilisateurs inexpérimentés.  accès concurrent, recouvrement des crashs : un utilisateur acckde aux données sans tenir compte des autres utilisateurs du système.

6 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke6 Pourquoi Etudier les SGBDs?  Le volume des données et leur diversité s’acroit énormement  Bibliothèques digitales, système de video interactif, project du génome humain, project EOS ... Les besoins pour des SGBDs explosent  La gestion efficiente d’une masse si diverse de données implique de la recherche sur beaucoup de problèmes fondamentaux.  Les SGBDs comprennent la plupart des sujets de recherche en informatique  SE, langues, théorie, IA, multimedia, logique, etc. ?

7 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke7 modèles des données  Un modèle des données est une collection d’éléments de haut niveau pour la description des données.  Un schéma est une description d’une collection particulière de données utilisant un modèle des données precis.  Une instance d’un schéma est un ensemble de données organisées selon un schéma donné.  Le modèle relationel est le modèle le plus largement utilisé aujourd’hui.  Concept principal: instance relationelle (relation), i.e. une table ayant des lignes et des colomnes.  Chaque relation a un schéma relationel (schéma) qui décrit le nom et les colomnes ou attributs de la dite relation.

8 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke8 Niveaux d’Abstraction  Les schémas de données sont décrits à 3 niveaux d’abstractions: vues, schéma conceptuel (logique) et schéma physique.  Les Vues (schémas externes) décrivent comment les utilisateurs voient les données.  Un schéma conceptuel définit la struture logique.  Un schéma physique décrit les fichiers et indexs à utiliser. * Les schémas sont définis en utilisant un language de définition de données (DDL). schéma physique schéma conceptuel vue 1vue 2vue 3

9 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke9 Exemple: Base de données Universitaires  schéma conceptuel:  Students(sid: string, name: string, login: string, age: integer, gpa: real)  Courses(cid: string, cname: string, credits: integer)  Enrolled(sid: string, cid: string, grade: string)  schéma physique:  Relations stockées comme fichiers nontriés.  Index sur la première colomne de Students et Courses; index sur les deux premières colomnes de Enrolled, etc.  schéma externe (Vue):  Course_info(cid: string, enrollment: integer)

10 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke10 Indépendance des données *  Les applications sont isolées de la manière dont les données sont structurées et stockées.  Chaque niveau d’abstraction est protégé des changements dans la structure du niveau inférieur.  Indépendance logique : protection des changements dans la structure logique des données.  Indépendance physique : protection des changements dans la structure physique des données. * Un des plus importants bénéfices de l’utilisation d’un SGBD

11 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke11 Requêtes  Une requête est une question impliquant les données stockées, p. ex.  Quel est le nom du professeur qui enseigne CSI3717?  Quel est le nombre total d’étudiants enrollés dans CSI3717?  Quel est le pourcentage d’étudiants ayant eu un A+ dans CSI3717?  Un language de requêtes est language specialisé dans lequel des requêtes peuvent être posées sur une base de données.  Les données sont modifiées /requises en utilisant un language de manipulation des données (DML). Ainsi un language de requêtes est un sous-language d’un DML.  Le modèle relationel supporte 2 languages de requêtes:  Calcul relationel : language de requêtes basé sur la logique  Relational algebra : basé sur un ensemble d’opérateurs pour la manipulation des relations.

12 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke12 Contrôle d’Accès Simultanés  L’exécution simultanée des programmes d’utilisation est essentiel pour une bonne performance des SGBDs.  il est important de garder le cpu occupé en travaillant simultanément sur plusieurs programmesd’utilisateurs.  L’entrelacement des actions de différents utilisateurs peut conduire à des inconsistences: p. ex. lors d’un retrait d’argent pendant que la balance du compte est calculée.  Le SGBD garantit que des inconsistences n’arrivent pas: un utilisateur peut utiliser le système comme s’il s’agissait d’un système à usager unique.

13 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke13 Transaction  Une transaction est une séquence atomique d’actions sur la base de données (reads/writes) correspondant à l’exécution d’un programme de transaction.  Chaque transaction, exécutée complètement, doit laisser la BD dans un état consistent si la BD était consistente au début de la transaction.  Les utilisateurs peuvent spécifier de simples contraintes d’integrité sur les données et le SGBD les appliquera.  Au delà de cela, le SGBD ne comprend pas la sémantique des données. (p. ex. il ne comprend pas comment calculer la moyenne cumulée sur un compte d’étudiant).  D’où, l’utilisateur est en dernier ressort responsable du maintien de la consistence des données!

14 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke14 Scheduling de Transactions Simultannées  Un SGBD garantit que l’exécution de {T1,..., Tn} est équivalente à une exécution sérielle de T1,..., Tn.  Avant de lire/écrire un objet, une transaction réquiert un lock sur cet object et attend jusqu’à ce que le SGBD rende le lock. Tous les locks sont relachés à la fin de la transaction. (protocolle de locking 2PL strict.)  Idée: Si une action de Ti (soit writes X ) affecte Tj (qui pourrait être entrain d’exécuter un reads X ), un parmi les deux, soit Ti, veut obtenir un lock sur X d’abord et Tj est forcé d’attendre jusqu’a ce que Ti soit à la fin; ceci entraine que les transactions seront ordonnées.  Si p. ex. Tj a déjà un lock sur Y et Ti réquiert plutard un lock sur Y, il y a dans ce cas un deadlock! Ti ou Tj est annullé et redémarré!

15 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke15 Garantie d’Atomicité  Un SGBD garantit l’ atomicité (proprieté du tout-ou-rien) même si il y a un crash au milieu de la transaction.  Idée: garder un log (“history”) de toutes les actions exécutées par le SGBD lors de l’exécution d’un ensemble de transactions:  Avant que un changement ne soit fait sur une BD, l’entrée correspondante dans le log est forcément stockée à un endoit sûr. ( protocolle WAL ; les SO n’offrent souvent à ce sujet qu’un support inadéquat.)  Après un changement, les effets de la transaction partiellement exécutée sont defaits en utilisant le log. (Grâce au protocolle WAL, si une entrée dans le log n’était pas sauvée avant le crash, le changement associé à cette entrée n’a donc pas été appliqué à la base de données!)

16 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke16 Le Log  Les actions suivantes sont enregistrées dans le log:  Ti ecrit un object : la vielle et la nouvelle valeurs sont enregistrées. L’enregistrement du log doit aller sur le disque avant la page qui a changé!  “commits”/”aborts” : un enregistrement indiquant une telle action est inscrite dans le log.  Les enregistrements du log sont chainés sur base des numéros d’identification des transactions. De la sorte, il est facile de défaire une transaction donnée.  Le log est souvent archivé sur un stockage “stable”.  Toute activité relative au log (ainsi que toute autre activité relative au contrôle d’accès simultané telle que lock/unlock, traitement des deadlocks, etc.) est traité de manière transparente par le SGBD.

17 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke17 Personnes Impliquées dans les BDs  Utilisateur final: accède seulement à un interface d’un SGBD!  Vendeurs de SGBDs: IBM, Oracle, Informix, Microsoft, etc  Chercheurs et implémenteurs: inventent de nouvelles théories et algorithmes relatifs aux SGBDs et en ecrivent le code.  Programmeurs d’applications: écrivent des programmes C/C++/Java/… qui interagissent avec les SGBDs  P.ex. Webmasters avancés  Administrateur de base de données (DBA)  Conçoit les schémas logiques /physiques  Traite les questions de sécurité et d’authorisation  Disponibilité des données, recouvrement du crash  Adaptation de la base de données à l’evolution des besoins Les DBAs doivent comprendre le fonctionnement d’un SGBD !

18 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke18 Structure d’un SGBD  Un SGBD typique a une architecture à plusieurs couches (“layers”).  Notez que les modules d’accès simultanés et de recouvrement du crash ne sont pas montrés.  Ceci est un parmi plusieurs choix possibles d’architectures, chaque système ayant ses propres particularités. exécution et optimisation Des requêtes Operateurs relationels accès aux fichiers Gestion de tampons Gestion d’espace disque DB Ces couches doivent considérer L’accès simultané et Le recouvrement

19 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke19 Perspectives Historiques  Début des années 60: GE concoit le 1er SGBD à caractère général et basé sur le modèle réseau.  Fin des années 60s: IBM développe IMS qui est basé sur le modèle hiérarchique.  Début des années 70: E. Codd introduit le modèle relationel pour résoudre les problèmes relatifs aux modèles précédents.  Fin des années 70 et début 80: travaux sur le traitement des transactions, par Jim Gray et P. Bernstein.  Années 80: L’utilisation des BDs relationels devient courante dans les grandes entreprises, arrivée de plusieurs vendeurs de SGBDs, standardisation de SQL, le language de requêtes pour les BDs relationels, etc.

20 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke20 Perspectives Historiques (Suite)  Fin 80 et début 90s: modèles de données plus riches (orienté-object, object-relationel, etc) et des languages de requêtes plus expressifs (Datalog, relations nichées, etc) sont introduits.  Fin 90: les grands vendeurs étendent les SGBD relationel avec de nouveaux types de données (images, texte, contenu multimédia, etc) ainsi que avec les requêtes basé sur cela.  Pendant toute l’histoire du développement des BDs:  Reconnaissance scientifique: Turing Awards aux chercheurs en BDs C. Bachman, E. Codd, et J. Gray  Naissance d’une large industrie de plusieurs billions de dollars

21 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke21 Résumé  Un SGBD est utilisé pour maintenir et poser des requêtes à de larges collections de données.  Les bénéfices comprennent le recouvrement du crash, l’accès simultané, dévelopment rapide des applications, integrité des données et sécurité.  Les niveaux d’abstraction entrainent l’Indépendance des données.  Un SGBD a généralement une architecture à niveaux.  Les chercheurs en BDs, les implémenteurs et les administrateurs ont des jobs de grande responsabilité et sont bien payés!  La recherche et le dévelopment en SGBDs est un domaine large et excitant au sein de l’informatique.  Les BDs sont une industrie de plusieurs billions de $$ !