IFT2821 Base de données Chapitre 8 Fonctions avancées

Présentation au sujet: "IFT2821 Base de données Chapitre 8 Fonctions avancées"— Transcription de la présentation:

1 IFT2821 Base de données Chapitre 8 Fonctions avancées

2 Plan du cours Introduction Architecture Modèles de données
Modèle relationnel Algèbre relationnelle SQL Conception Fonctions avancées Concepts avancés PL/SQL

3 Introduction En plus d'offrir la possibilité de définir et d'interroger une base de données, un SGBD relationnel, offre également des fonctionnalités avancées Fonctions avancées Gestion de la concurrence Sécurité Intégrité Reprise après panne La concurrence peut mettre la base dans un état incohérent

4 Introduction Exemple Programme RÉSERVATION Entrée : une séance s
nombre de places souhaité NbPlaces client c Début Lire séance s Si(nombre de places libre > NbPlaces) Lire le compte du client c Débiter le compte du client c Soustraire le NbPlaces au nombre de places libres Écrire la séance s Écrire le compte du client c FinSi Fin

5 Introduction Notation - On notera lecture par : r
- On notera écriture par : w - On notera une exécution du programme de réservation par : p Une exécution du programme p : r[s] r[c] w[c] w[s] Les boucles, les test ne compte pas vraiment. Ce qui compte c ’est les opérations d ’accès (lecture, écriture)

6 Introduction Exécution concurrentes : sérialisabilité Solutions:
1- Exécution en série : concurrence zéro (pas viable) 2- Bonne imbrication des opérations (sérilisable) r1[s] r1[c1] r2[c2] w1[s] r2[s] w2[s] w1[c1] w2[c2] Exécution des programmes en série ne pose aucun problème, cependant pas viable. La bonne imbrication ne suffit pas un problème matériel ou logiciel qui entraîne l ’interruption du programme Le programme choisit lui-même d ’annuler ce qu’il a fait r1[s] r1[c1] w1[s] annuler.

7 Introduction Exécution concurrentes : sérialisabilité
Soit deux programmes p1(s,5,c1) et p2(s,10,c2) qui s’exécutent dans l’ordre ci-dessous sachant que le nombre de places libres est égale à 50 r1[s] r1[c1] r2[s] r2[c2]w2[s] w2[c2] w1[s] w1[c1] nombre de place libre est : 45 au lieu de 35 (incohérence) Problème : mauvaise imbrication des opérations Qu’en est-il de l’exécution suivante ? r1[s] r1[c1] w1[s] r2[s] r2[c2]w2[s] w1[c1] w2[c2] ?

8 Transaction Transaction Problème Solution
r1[s] r1[c1] w1[s] r2[s] r2[c2] w2[s] w1[c1] w2[c2] Solution Annuler w1[s] (jusqu’ou il faut remonter dans les annulations ?) considérer un ensemble d’opérations indivisible w1[s] w1[c1] Valider (commit): rendre les mise-à-jour permanentes Annulation (rollback): annule les mise-à-jour effectuées Panne ou annulation par le programme

9 Transaction Transaction Reconstitution (recouvrabilité)
Une transaction est l’ensemble des opérations séparant un rollback du commit ou du rollback et inversement. Reconstitution (recouvrabilité) Exécutions non reconstituables(dirty read) r1[s] r1[c1] w1[s] r2[s] r2[c2] w2[s] w2[c2] commit2 w1[c1] rollback1 nombre de sièges réservé sera plus grand que le nombre de sièges effectif de clients ayant validé leur réservations. En cas d ’annulation (quelle est la porté du rollback s ’il n ’existe en haut ni rollback ni commit, jusqu ’au premier ordre SQL) on annuler T1 il faut aussi annuler T2 alors que ce n ’est pas possible il y a eu un commit. On parle d ’exécution non recouvrable. On pourrait penser à interdire à une transaction T2 qui fait un dirty read dans une transaction T1 alors on accepterait la situation suivante.

10 Transaction Reconstitution
solution (annulation en cascade) r1[s] r1[c1] w1[s] r2[s] r2[c2] w2[s] w2[c2] w1[c1] rollback1 annuler la transaction 2 sans la transaction n ’ait validé. pas viable (pour la transaction 2). Il faut interdire les dirty read Exécution non stricte (dirty write) r1[s] r1[c1] r2[s] w1[s] w1[c1] r2[c2] w2[s] commit1 w2[c2] rollback2 transaction 1 a validé après que transaction 2 ait écris dans s lorsque transaction 2 est annulé le système doit annuler les mise-à-jour de transaction 1(en ce qui concerne les données de transaction 1)

11 Transaction Résumé Recouvrabilté: on ne doit pas avoir à annuler une transaction déjà validé Annulation en cascade : un rollback sur une transaction ne doit entraîner l ’annulation d’autres transactions Recouvrabilité stricte : deux transaction ne peuvent accéder simultanément en écriture à la même donnée.

12 Transaction Propriétés Atomicité Tout ou rien Cohérence
mises-à-jours entre deux états cohérents Isolation Les effets (lectures et écritures ) d'une transaction ne sont visible par les autres transaction qu'à sa fin Durabilité Un fois terminée, ses effets sont durables. Ne peut être annulée

13 Gestion de la concurrence
Contrôle de la concurrence (1) Consiste à ordonner les exécutions des programmes de manière à éviter les anomalies présentées précédemment. Contrôle continu : vérifie au fur et à mesure de l’exécution que le critère de la sérialisabilté est respecté(approche pessimiste). Contrôle par certification : vérifie le critère de la sérialisabilité quant la transaction s’achève (approche optimiste).

14 Gestion de la concurrence
Contrôle de la concurrence (2) Mécanisme de verrouillage : on bloque l’accès à une donnée lu ou écrite par une transaction («pose de verrou») et on libère cet accès quant cette transaction termine par Commit ou Rollback. Le blocage systématique est contraignant r1[s] r1[c1] w1[s] r2[s] r2[c2]w2[s] w1[c1] w2[c2] bloquage inutile de la transaction 2. Solution plus souple Granularité du verrouillage : uplet, table, page Degré des restriction : Verrou partagé (en lecture) Verrou exclusif (en écriture)

15 Gestion de la concurrence
Contrôle de la concurrence (3) 1. Verrouillage à deux phases: rl ou wl: verrou en lecture ou écriture(read lock, write lock) ru ou wu: relâchement de verrou en lecture ou écriture (read unlock, write unlock) rli[x] : la transaction i pose un verrou en lecture sur la ressource x pli[x] : la transaction i pose un verrou en lecture ou en écriture sur la ressource x Définition : deux verroux pli[x] et qlk[y] sont en conflit si x=y et i  k et pl ou ql est un verrou en lecture ou écriture.

16 Gestion de la concurrence
Contrôle de la concurrence (4) Algorithme(Scheduler): 1. Le scheduler reçoit pi[x] et consulte le verrou déjà posé su x, qlk[x] ,s ’il existe. si pli[x] est en conflit avec ql k[x], pi[x] est retardée et la transcation Ti est mise en attente. sinon, Ti obtient le verrou pli[x ] et l’opération pi[x] est exécutée. 2. Un verrou pi[x] n’est jamais relâché avant la confirmation de l’exécution par un autre module, le gestionnaire des données. 3. Dès que Ti relâche un verrou, elle ne peut plus obtenir un autre.

17 Gestion de la concurrence
Contrôle de la concurrence (3) 2. Contrôle par estampillage : consiste à fixer ,à priori, l’ordre de sérialisabilité des transactions soumises au scheduler. À chaque transaction on affecte une estampille. Les estampilles sont uniques et croissant (i.e., ordre totale des transaction). Quand un conflit survient on vérifie si l’ordre des transaction résout le conflit(i.e., si i < k alors opérationi s ’exécute avant opérationk). Sinon on rejette la transaction responsable conflit. Exemple : r1[s] w2[x] r3[x] r2[x] w1[x]. On rejette T1 au moment de l’exécution de w1(x).

18 Gestion de la concurrence
Blocage Situation où deux ou plusieurs transactions sont mutuellement bloquées en attente d'un verrou Solutions Technique de l'examen du graphe d'attente Technique du mécanisme de délai Variantes Rejouer la transaction Signaler à l'application

19 Reprise après panne Journal (log)
Fichier disque (ou bande) dans lequel sont écrites les modifications de la BD (valeurs concernées avant et après chaque requête élémentaire) Utiliser pour défaire une transaction Problème: Comment garantir la cohérence de la BD à l'intérieur d'une requête élémentaire ?

20 Reprise après panne Point de commit (syncpoint)
Point du programme dans lequel la BD est dans un état cohérent Début du programme et à la fin de chaque transaction Implications Toutes les mises à jour sont rendues permanentes Toutes les variables de positionnement sont détruites et tous les verrous sur les n-uplets effacés (cette implication s'applique également au ROLLBACK)

21 Reprise après panne Défaillance système (soft crash)
Affecte toutes les transactions courantes sans endommager la BD physiquement Si la mémoire centrale est effacé, lors du redémarrage, Les transactions courantes sont annulées (ROLLBACK) Certaines transactions terminées doivent être rejouées (mémoires tampons non transférées sur disque) Comment le système sait quelles transactions annuler et quelles transactions rejouer ?

22 Reprise après panne Défaillance système (soft crash) Point de contrôle
A intervalle régulière, le système transfert le contenu des mémoires tampons dans la bases de données (physique) et produit un compte rendu dans le journal (physique) Temps tc tf T1 T2 T3 T4 T5 Point de contrôle Défaillance du système

23 Reprise après panne Défaillance des supports (hard crash)
Destruction physique d'une partie de la base de données. Reprise après panne se fait en deux étapes : Restaurer la dernière sauvegarde de la base Rejouer toutes les transactions terminées avec succès depuis cette dernière sauvegarde

24 Reprise après panne (Résumé)
DB État 1 DB État 2 DB État 3 DB État 4 Transaction 1 Transaction 2 Transaction 3 DB backup Procédures de Mise à jour DB État 2

25 Reprise après panne Utilisateur Serveur Bases de données
Log des transactions Enregistrement retrouvé Opérer les mises à jours Obtenir enregistrement Utilisateur 1: une transaction de Mise à jour 8: message de notification 3: obtenir enregistrement 2 4 5 6: Ecrire les mises à jours 7 9: backup périodique Log image avant de l ’enregistrement Log image après de Procédures de recouvrement

26 Sécurité Attribution des privilèges privilèges objets
GRANT {liste_privilèges | ALL [PRIVILEGES]} [ liste_attribut ] ON objet TO {liste_utilisateurs | PUBLIC}] [WITH GRANT OPTION] privilèges ALTER, DELETE, INSERT,SELECT, UPDATE, ... objets table, vue, ... WITH GRANT OPTION Permet à "l'autorisé" d'autoriser

27 Sécurité Retrait des privilèges Exemples
REVOKE {liste_privilèges | ALL [PRIVILEGES]} ON objet FROM {liste_utilisateurs | PUBLIC}] [CASCADE CONSTRAINTS] Exemples GRANT ALL PRIVILEGES ON EMPLOYE TO ALICE GRANT UPDATE (SALAIRE) ON EMPLOYE TO TOD, NANCY GRANT SELECT ON DEPARTMENT TO PUBLIC GRANT SELECT,UPDATE , DELETE, INSERT ON PROJECT TO ALICE GRANT ALL PRIVILEGES ON EMPLOYE TO NED WITH GRANT OPTION REVOKE UPDATE ON PROJECT TO ALICE (CASCADE???)