Bases de données Avancées M1-SEM Dr. A. TACHOUCHE VI. Protection des SGBD 1. In
Bases de données Avancées M1-SEM Dr. A. TACHOUCHE VI. Protection des SGBD 1. Introduction Les SGBD “courent” certains dangers que nous pouvons répertorier en : - accidents logiciels - utilisation pernicieuse - pannes matérielles Les SGBD doivent faire face et assurer d’une part l’intégrité des données, d’autre part la sécurité et le contrôle des accès. Tout d'abord il faut assurer la cohérence des informations stockées. Il s'agit de contraintes d'intégrité que doivent respecter les données. Si plusieurs utilisateurs sont autorisés à manipuler la même base de données, il faut s'assurer que les actions des uns ne seront pas préjudiciables aux autres. Ce problème est connu sous le nom de contrôle de concurrence. Le contrôle de concurrence dans un SGBD doit rendre le partage des données complètement transparent aux utilisateurs et doit donc contrôler l'exécution simultanée de transactions de sorte à produire les mêmes résultats qu'une exécution séquentielle. Un SGBD peut fonctionner sur plusieurs machines, or une machine peut tomber en panne entraînant une altération des données de la base. Il faut donc que le SGBD assure le fait que la base restera dans un état cohérent même après une panne : on parle de sûreté de fonctionnement et du mécanisme de reprise (sur panne). Enfin si plusieurs usagers utilisent la base il s'agit de vérifier que chaque utilisation est autorisée : problèmes des droits. 2. Intégrité des données Dans une base de données un des problèmes essentiels est d’assurer la cohérence des données (les données doivent rester conformes à la réalité qu'elles représentent). Une Contrainte d'Intégrité par définition est un Prédicat toujours vrai sur une partie ou sur la totalité des données de la base (invariant). Un schéma de Base de Données est soumis à un ensemble de Contraintes d’Intégrité. Une instance de ce schéma respectant les Contraintes d'Intégrité est dite Base de Données cohérente. Il existe plusieurs types de Contraintes d'Intégrité que nous pouvons séparer en deux grandes classes : les contraintes statiques et les contraintes dynamiques. 2.1 Contraintes staques. - NOT NULL Bases de données Avancées M1-SEM Dr. A. TACHOUCHE - PRIMARY KEY - UNIQUE - CHECK - DEFAULT - FOREIGN KEY o ON DELETE CASCADE o ON DELETE RESTRICT o ON DELETE SET NULL o ON UPDATE CASCADE 2.2 Contraintes dynamiques Il s'agit de contraintes que l'on peut souhaiter imposer lors d'un passage d'un état de la base à un autre. Par exemple les n-uplets du nouvel état dépendent des n-uplets de l'état précédent. Un autre aspect des contraintes dynamiques est celui qui consiste à définir des actions spontanées (triggers) qui seront déclenchées automatiquement par le SGBD lorsque certaines opérations se produisent. La base de données passe par des états transitoires durant lesquels certaines CI ne sont plus préservées Afin d’isoler des unités de traitement respectant la cohérence de la base on introduit la notion de transaction. Le contrôle des CI se fera en fin de transaction et peut alors nécessiter une remise en cause de l'exécution de la transaction. 3. Concept de Transaction. 3.1 Définions L'usager manipule la base de données soit au travers du langage de requête, soit au travers de programmes qui font appel au SGBD. L'exécution d'une requête ou d'un programme fait naître au niveau du SGBD une occurrence de transaction. Une transaction est une unité de traitement séquentiel (séquence d'actions cohérente), exécutée pour le compte d'un usager, qui appliquée à une base de données cohérente restitue une base de données cohérente. (Une transaction peut être simplement l'exécution d'une requête SQL, ou bien celle d'un programme en langage hôte dans lequel on a des appels au langage de requête) Les Contraintes d'Intégrité sont donc toujours des invariants pour les transactions ce qui signifie qu'une transaction respecte les Contraintes d'Intégrité à la fin pourvu que celles-ci soient respectées au début. Le respect des contraintes est à la charge du programmeur de transaction. Bases de données Avancées M1-SEM Dr. A. TACHOUCHE Les SGBD modernes ne permettent que des transactions. Le mécanisme de gestion des transactions doit assurer : - que lors d'une exécution d'une transaction toutes ses actions sont exécutées ou bien aucune ne l'est (atomicité). De plus les effets d'une transaction qui s'est exécutée correctement doivent survivre à une panne (permanence), - que chaque transaction soit isolée, de manière à éviter des incohérences lors d'exécutions concurrentes. 3.2 Isolaon d'une transacon et concurrence. Même si les transactions sont cohérentes, leur entrelacement peut conduire à des incohérences globales. Exemple 1 : T1 et T2 exécutent la suite d'acCons ci-dessous. La variable X à la fin des deux transactions ala valeur 300 alors que sa valeur serait 400 si les deux transacCons T1 et T2 s'étaient succédées. Exemple 2 : La base est soumise à la contrainte d'intégrité Y=2X (X=5 et Y=10 avant), les deux transacCons T1 et T2 s'exécutent, la base est alors dans un état incohérent la CI n'étant plus vérifiée. (X=30, Y=20) Bases de données Avancées M1-SEM Dr. A. TACHOUCHE Exemple 3 : CI : Y=2X (X=5 et Y=10 avant) La base est cohérente après les deux transacCons, maisT1 a lu des valeurs incohérentes (X=5 et Y=60) Il est donc nécessaire d'une part d’isoler les divers éléments d’une transaction et d’autre part de s’assurer de la cohérence de la base après exécution d’un ensemble des transactions concurrentes. La base de données est découpée en éléments appelés granules (c’est en général l’administrateur en accord avec le concepteur qui fixe le niveau de granularité : n-uplet, page, table). L’isolation d’un élément dans une transaction est obtenu par le mécanisme des verrous (lock). Ces verrous sont définis par deux opérations : • verrouiller(A) Cette opération oblige toute transaction T à attendre le déverrouillage de l'élément A si elle a besoin de cet élément. • déverrouiller(A) La transaction effectuant cette opération libère le verrou qu’elle avait obtenu sur A et permet à une autre transaction candidate en attente d’obtenir le sien. L’utilisation de verrou entraîne éventuellement la mise en attente de transaction. Ceci a pour conséquence deux grands types de problèmes : • la famine Lorsqu’un verrou est relâché sur un élément A, le système choisit parmi les transactions candidates en attente, si les transactions sont liées au niveau de priorité de l’utilisateur certaines transactions attendront longtemps ... La solution pour pallier à ce genre de situation est d’instaurer une file d’attente et de gérer les demandes de verrou en respectant l’ordre d’entrée dans la file. • L’interblocage (deadlock) Cette situation se présente lorsqu’un ensemble de transactions attendent mutuellement le déverrouillage d’éléments actuellement verrouillés par des transactions de cet ensemble. Exemple : Si T1 obCent un verrou sur A, puis T2 obCent un verrou sur B, et qu’enfin T1 demandant un verrou sur B soit mise en aNente, la demande ultérieure par T2 d’un verrou sur A entraîne l’interblocage des deux transactions. Les solutions consistent la plupart du temps à faire intervenir le système qui “tue” les transactions. Le mécanisme de verrouillage permet donc d’isoler un élément pour une transaction, cependant il faut encore que cette utilisation soit faite à bon escient. Pour que l’exécution d’un ensemble de transactions concurrentes transforme la base depuis un état cohérent jusqu’à un autre état cohérent, on impose, en général, une contrainte forte aux transactions : leur exécution doit être sérialisable. Bases de données Avancées M1-SEM Dr. A. TACHOUCHE Définition Une exécution d'un ensemble de transactions est sérialisablessi elle est équivalente à une exécution séquentielle (ou série) de transactions. Quand les transactions sont arbitraires, la sérialisabilité est la seule propriété qui assure le bon "entrelacement". Réalisation La sérialisabilité peut être obtenue en imposant aux transactions que tous les verrouillages précèdent tous les déverrouillages. Les transactions sont alors dites à deux phases : une phase d'acquisition des verrous puis une phase de libération. 3.3 Atomicité d'une transaction La gestion de transaction nécessite la propriété d'atomicité d'une transaction c'est à dire d'assurer que les opérations mêmes les plus complexes englobées au sein d'une transaction ne soient perçues que comme uneopération unique. De plus il faut que soit toutes les modifications liées à cette opération soient effectuées, soit aucune ne l’est. C'est le "système" qui est à même d'assurer l'atomicité des transactions. Le modèle général de transaction sera le suivant : BEGIN TRANSACTION ; ---- REQUETES INSTRUCTIONS ----- COMMIT ; ou bien ROLLBACK ; Comme une transaction peut ne pas se terminer normalement (soit à cause de pannes diverses, soit par intervention du système lors d'un interblocage) on raffine les définitions : - avant un point de validation, une panne entraîne la perte (totale, à cause de l'atomicité) de la transaction. - après, la transaction sera visible (au bout d'un certain temps) par les autres : permanence (si panne refaire) Cette méthode s'appelle la validation à deux phases. Elle suppose souvent l'existence d'une mémoire stable, dans laquelle, au point de validation, les nouvelle valeurs devront être enregistrées. Une transaction ayant atteint son point de validation sera dite validée ( elle ne peut plus être remise en cause). Une transaction n'ayant pas encore atteint son point de validation sera dite vivante. 3.4 Permanence Le problème de uploads/Finance/ cour-6.pdf
Documents similaires
-
16
-
0
-
0
Licence et utilisation
Gratuit pour un usage personnel Attribution requise- Détails
- Publié le Jan 16, 2021
- Catégorie Business / Finance
- Langue French
- Taille du fichier 0.1344MB