Chapitre 5: Programmation et Administration des

Bases de Données

3ème Année Ingénieur

Semestre: S5

Ecole Supérieure en Informatique

Département d’Informatique
 Plan
I. Introduction
II. Gestion et manipulation des index
II.1 But
II. 2 Fichier
II.3 Index
 Définition
 Différents Types d‟index
 Exemples de création d‟index
II. 4 Optimisation de Requêtes
 But
 Évaluation des requêtes
III. Gestion et manipulation des transaction
III.1 But
III.2 Notion de Transaction
III. 3 Propriétés d'une transaction (A.C.I.D.
III. 4 Transactions concurrentes
III. 5 Verrouillage
IV. Gestion de la sécurité des bases de données
IV.1 Sécurité et Intégrité
IV.2 Niveaux de Sécurité

Références :
1. George. Gardarin : Bases de Données Eyrolles , Edi. 3, 2003
2. Ramez Elmasri, Shamkant B. Navathe, Fundamentals of Databases Systems, Pearson, 7 Ed., 2016
3. Hector Garcia-Molina, Jeffrey D. Ullman, Jennifer Widom Databases Systems: The Complete Book Ed. 2 Prentice 2008
 I. Gestion et manipulation des index

 Les index, d‟une manière générale, permettent d‟améliorer parfois

considérablement les performances en lecture, mais ils peuvent légèrement
dégrader les performances en écriture car le SGBDR doit les maintenir en plus
des tables lors des modifications des données indexées.
 Sur des tables qui ont des accès en écriture très concurrents, la mise a jour des
index peut provoquer des contentions d‟accès a ceux-ci et donc des latences
d‟écriture.
 Ces indexes sont utiliser pour améliorer les performances (ie, l‟optimisation)
des bases de données.
Sous Oracle, ils peuvent être soit de type B*Tree soit de type bitmap. Leur
action est généralement assez efficace, sans pour autant que leur mise en place
nécessite beaucoup de changements au niveau de l‟application.
Le tout sera de choisir le type d‟index le plus adapté à la situation. Les index
présentent l‟avantage de pouvoir être également mis en oeuvre au sein de
logiciels réalisés par des tiers et pour lesquels vous n‟avez pas accès au code
source
Le fichier comme abstraction du support physique

 Le système et la couche physique exposent plusieurs notions de bas niveau:

Secteurs, pistes, plateau, …
Pages/blocs
Buffer de lecture/écriture
 Implémentation des moteurs d‟éxécution de requêtes (SQL), nécessite
l‟utilisation des structures de données et des algorithmes génériques.
 On abstrait les concepts de bas niveau par la notion de fichier. Un fichier est un
ensemble d'enregistrements.
 Un enregistrement contient des données structurées en champs. En pratique,
les fichiers sont paginés
Opérations sur les fichiers

La couche physique propose plusieurs opérations sur les fichiers:

Création/suppression de fichier
Insertion/supression d'enregistrement
Accès au ième enregistrement du fichier
Accès au ième champ d'un enregistrement
 Fichier simple

 La structure la plus simple pour un fichier est la structure en tas (à ne pas

confondre avec la structure de donnée du même nom).
 La couche physique du SGBD connait la liste des pages d'un fichier ainsi que
l'espace libre sur chaque page, les enregistrements sont ajoutés ou supprimé dans les
pages que le SGBD considère comme meilleures (du point de vue des E/S) sans
considération sur les données.
Rechercher un enregistrement particulier, en fonction d'un critère sur son contenu
(ex: id='5') nécessite un parcours séquentiel du fichier (scan)
INDEX
Définition
 Un index est une structure de données qui permet d'accélérer les recherches
dans une table en associant à une clé d'index (la liste des attributs indexés)
l'emplacement physique de l'enregistrement sur le disque.
 Un index est un fichier auxiliaire, structuré qui va rendre plus efficace l'accès à
certaines données, en fonction d'une clé d'index.
 Un enregistrement d'un index s'appelle une entrée d'index. L'entrée associée à la
clé k est notée k* et contient suffisamment d'information pour retrouver le ou les
enregistrements (de la table indexée) associés à k.
 Les accès effectuées sur un index peuvent donc se faire sur des structures
optimisées pour la recherche (liste triée, B-tree...) au lieu de se faire par parcours
séquentiel et intégral des enregistrements.

 On distingue trois types d'indexes:

 Index de type I : k* représente directement un enregistrement de la table
originale (la table indexée).
 Index de type II : une entrée est un couple <k,rid> où k est la clé et rid est un
pointeur vers l'enregistrement ayant cette clé.
 Index de type III : un couple <k,rid-list> où k est la clé et rid-list est une liste de
pointeurs vers les enregistrements ayant cette clé
Indexes groupants
 Un index est dit groupant si ses entrées sont triées dans le même ordre que les
enregistrement du fichier indexé. Il est dit non-groupant dans le cas contraire.
Les enregistrements de la table initiale ne sont jamais dupliqués. On ne garde
donc jamais un indexe de type I en plus de la table initiale (on supprime cette
dernière)

Un index dense
 s'il contient une clé par enregistrement et non dense sinon.

Si une table possède un index non-dense, alors le fichier de cette table est
toujours trié selon la clé d'index (sinon l'index ne sert à rien).

Autres propriétés

 Un index pour lequel la clé d'index contient la clé primaire de la relation est
appelé un index primaire. Les autres indexes sont appelés indexes secondaires.

 Deux entrées d'index possédant la même clé sont des doublons. Un index
primaire ne contient pas de doublon.
Différents Types d‟index

 Outre le fichier tas un index peut avoir les représentations internes suivantes:
 Hash-index : l'index est organisé comme une table de hashage
Tree-index : l'index est organisé comme un arbre de recherche
 Fichier trié : le fichier est trié selon une clé particulière (i.e. l'ordre des
enregistrements sur le disque coïncide avec l'ordre de la clé d'index)
 Principe du hachage
 Calcul la position d‟un enregistrement d‟après la clé
– une fonction de hachage h associe des valeurs de clés à des adresses de bloc
– recherche d‟un enregistrement implique le calcul de l‟endroit où il se trouve

 Hachage ou adressage dispersé (hashing).

 Fonction h(clé de hachage)  l'adresse d'un paquet

 Fichier = tableau de paquets (bucket)

– ~ ARRAY paquet [0..TH-1].

– TH : taille de l'espace d'adressage primaire

 Habituellement paquet = bloc(page)

 Pas d‟index à traverser : O(1) en meilleur cas

 Sélection par égalité

10
 Exemple
Bloc (page) = 4 enregistrements 60 Erable argenté 15.99

h(clé) = clé MOD 3 0

90 Pommier 25.99
81 Catalpa 25.99
clé = 10
70 Herbe à puce 10.99
40 Epinette bleue 25.99
h(10) = 10 MOD 3 = 1 1
10 Cèdre en boule 10.99

20 Sapin 12.99
50 Chêne 22.99
2
95 Génévrier 15.99
80 Poirier 26.99

11
 Arbre B
• Un arbre équilibré

• Chaque nœud est un index local

• Il se réorganise dynamiquement

• Utilisé par tous les SGBDs commerciaux

12
 Structure d'un nœud d'un arbre-B

P0 x1 a1 P1 x2 a2 P2 …… xi ai Pi …… xk ak Pk

• Pi: Pointeur interne permettant de représenter l'arbre; les feuilles ne

contiennent pas de pointeurs Pi;
• ai: Pointeur externe sur une page de données;
• xi: valeur de clé.
• (1) (x1, x2…xK) est une suite croissante de clés;
• (2) Toute clé y de K(P0) est inférieure à x1;
• (3) Toute clé y de K(P1) est comprise entre xi et xi+1;
• (4) Toute clé y de K(PK) est supérieure à xk.
 Nœud d’un arbre B

P1 Pr1 P2 Pri-1 Pi Pri Prq-1 Pq

Sous-arbre
pointé par P1 <P1, <Pr1>, P2, <Pr2>, …, <Prq-1>, Pq>
• q p
• Chaque Pi est un pointeur vers un sous-arbre
• Pri est un pointeur sur les données
• Chaque nœud a au plus p pointeurs d’arbre

14
 Exemple

6 9
<6
>9
>6 <9

1 3 7 13

15
 Requêtes
• Scénario pour les requêtes singulières
– Prédicat de sélection: SSN=8

6 9
<6
>9
>6 <9

1 3 7 13

16
 Requêtes
• Scénario pour les requêtes singulières
– Prédicat de sélection: SSN=8

6 9
<6
>9
>6 <9

1 3 7 13

17
 Requêtes
• Scénario pour les requêtes singulières
– Prédicat de sélection: SSN=8

6 9
<6
>9
>6 <9

1 3 7 13

18
 Requêtes
• Scénario pour les requêtes singulières
– Prédicat de sélection: SSN=8

6 9
<6
>9
>6 <9

1 3 7 13

19
 Requêtes
• Algorithme d’accès

6 9
<6
>9 H étapes = accès
>6 <9 disque

1 3 7 13

20
 Requêtes d’intervalle

• Exemple: 5<salaire<8
• Proximity/ nearest neighbor searches? (eg., salaire ~ 8 )

6 9
<6
>9
>6 <9

1 3 7 13

21
 Fichier trié
On illustre sur une relation ayant le schéma Emp(Nom, Age, Salaire)

Ahmed
Mourad
Mourad, 19, 20000
Kadour
Kadour, 27, 23000
Mouhand
Akka, 33, 33000
Akka
…

Mouhand, 30000
Ahmed, 37000

Remarque: index de type II, non groupant

 Recherche dans une table avec un index

• Exemple: SELECT * FROM Etudiant WHERE Age = 24;

• Un index sur Age permet d‟obtenir rapidement les RIDs des tuples des
employés de 24 ans.
• Requêtes conjonctives
SELECT * FROM Etudiant WHERE Salaire = 2000 AND Ville = `Poitiers ‟;
– Supposons l‟existence de deux index; un sur Salaire et l‟autre sur Ville.
– Le premier index fournit les RIDs satisfaisant la 1ère condition qui seront
regroupés dans une table temporaire T1. Idem pour le deuxième index
~ T2
– Enfin l‟intersection de T1 et T2 donne la réponse

23
 Requêtes conjonctives ~ Index

• Attention:
– Cette solution pourrait être inefficace si les facteurs de sélectivité des
prédicats sont inférieurs à 0.6
• Dans un tel cas, le SGBD pourrait préférer faire un balayage séquentiel de la
table

24
 Index bitmap
• Problème:
– Comment indexer une table sur un attribut qui ne prend qu‟un
petit nombre de valeurs?

25
 Principe de l’index bitmap
• Soit un attribut A, prenant n valeurs possibles [v1, …,vn] (domaine)

• Création d‟un index bitmap sur l‟attribut A:

– On crée n tableaux de bit, un pour chaque valeur vi

– Le tableau contient un bit pour chaque tuple t

– Le bit d‟un tuple t est à 1 si: t.A = vi, à 0 sinon

26
 Exemple
ROWID(RID) Soudeur Fraiseur Sableur Tourneur

00055 :000 :0023 0 1 0 0

00234 :020 :8922 1 0 0 0

19000 :328 :6200 0 0 0 1

21088 :120 :1002 0 0 1 0

Ouvrier(NSS, Nom, Salaire, Spécialité, N°U)

avec le domaine de l’attribut Spécialité est: {Soudeur, Fraiseur, Sableur, Tourneur}

SQL: CREATE INDEX BITMAP ON Ouvrier(Specialite) TABLESPACE spec_espace

27
 Intérêt de Bitmap: Recherche
• Soit la requête suivante:
SELECT * FROM Ouvrier WHERE Spec = „‟Soudeur‟‟
– On prend le tableau pour la valeur Soudeur
– On garde toutes les cellules à 1
– On accède aux enregistrement par l‟adresse
 Très efficace si le nombre de valeurs (n) est petit

28
 Autre exemple
SQL: CREATE INDEX BITMAP ON Ouvrier(Salaire) TABLESPACE Sal_espace
ROWID(RID) 20000 30000 40000
00055 :000 :0023 1 0 0

00234 :020 :8922 0 1 0

19000 :328 :6200 0 0 0
21088 :120 :1002 0 0 1

Requête: Quels sont les employés soudeurs qui gagnent 30 000

Réponse: RID: 00234:020:8922

Quelle est la procédure?

29
 Exemple avec count()
• Requêtes type OLAP (data warehouse)
SELECT COUNT(*) FROM Ouvrier WHERE Spec in (‘Soudeur’, ‘Tourneur’)

• On compte le nombre 1 dans la colonne Soudeur

• On compte le nombre 1 dans la colonne Tourneur
• On fait la somme et c’est terminé

30
 Exemples de création d’index
• Le nom d‟un index est choisi par le DBA et peut être normalisé en le préfixant
par idx_ suivi du nom de l‟attribut indexé et terminé par le nom de la table
• Exemple:
CREATE UNIQUE INDEX idx_NSS_Ouvrier ON Ouvrier(NSS);
CREATE UNIQUE INDEX idx_NSS_Salaire_Ouvrier ON Ouvrier(NSS, Salaire);
CREATE INDEX BITMAP ON Ouvrier(Specialite) TABLESPACE spec_espace
• Suppression d‟un index
DROP INDEX <Nom de l ‟index>;
DROP INDEX idx_NSS_Ouvrier;

31
 Guide d’utilisation des index en cours
d’exploitation d’une BD
 Les index utiles sont ceux nécessaires à l‟exploitation courante des
données
 Supprimer les index lorsqu‟il s‟agit de traiter un flux important de
transactions de type mise à jour sur une table. Ils sont d‟abord
supprimés, puis recréés au besoin après les mises à jour
 Une accélération de la jointure est possible par la création des index:
indexer les attributs de jointure permettra un accès plus rapide

32
 Guide d’utilisation des index en cours
d’exploitation d’une BD (suite)
 Tous les attributs d‟un index composé doivent être présents dans la
clause WHERE, peu importe leur ordre dans la clause, pour que
l‟optimiseur en tire profit
 Si le premier attribut de l‟index composé est présent dans le WHERE,
l‟index composé est utilisé. Sinon, il devient inutile
 La négation dans une condition bloque l‟usage des index composés:
les valeurs hors domaine ne sont pas indexées
 Quand faut-créer un index composé?
- Lorsque certains attributs sont fréquemment utilisés ensemble, il
peut être avantageux de définir quelques index composés

33
 Surveillance de l’utilisation des index
• Oracle (à partir du 9i) permet de surveiller les index afin de
déterminer s‟ils sont utilisés ou non.
• SQL :
ALTER INDEX nom_index MONITORING USAGE |
NOMONITORING USAGE
– permet d‟activer ou de désactiver la surveillance

• ALTER INDEX idx_NSS_Ouvrier MONITORING USAGE;

34
 Mise en pratique
SELECT *
FROM V$OBJECT_USAGE % une vue permettant la surveillance des index (6 attributs)
WHERE index_name = ‘idx_NSS_Ouvrier ’;

INDEX_NAME TABLE_NAME MONITORING USED START_MONITORING END_MONITORING

idx_NSS_Ouvrier Ouvrier YES YES 08/1/2016 6:15:00

 Cet index est utilisé au moins une fois

INDEX_NAME TABLE_NAME MONITORING USED START_MONITORING END_MONITORING

idx_NSS_Ouvrier Ouvrier YES NO 08/1/2016 6:15:00

 DROP INDEX idx_NSS_Ouvrier;

35
 II.4 Introduction à l‟Optimisation de Requêtes
1. BUT
 Classiquement, un optimiseur transforme une requête exprimée dans un langage source
(SQL) en un plan d‟exécution composé d‟une séquence d‟opérations de bas niveau réalisant
efficacement l‟accès aux données.
 Le langage cible est donc constitué d‟opérateurs de bas niveau (Opérateurs Algébrique )
complété par des informations de niveau physique, permettant de déterminer l‟algorithme
choisi pour exécuter les opérateurs [Selinger79].
Ces informations associées à chaque opérateur, appelées annotations, dépendent bien sûr
du schéma interne de la base (par exemple, de l‟existence d‟un index) et de la taille des tables.
 Elles complètent utilement l‟algèbre pour choisir les meilleurs chemins d‟accès aux données
recherchées.
 L‟optimisation de requêtes est souvent divisée en deux phases :
 l‟optimisation logique, qui permet de réécrire la requête sous une forme canonique
simplifiée et logiquement optimisée, (ie., sans prendre en compte les coûts d‟accès aux
données).
et l‟optimisation physique, qui effectue le choix des meilleurs algorithmes pour les
opérateurs de bas niveau compte tenu de la taille des données et des chemins d‟accès
disponibles.
 L‟optimisation logique reste au niveau de l‟algèbre relationnelle, alors que l‟optimisation
physique permet en particulier d‟élaborer les annotations.
2. Évaluation des requêtes
ARCHITECTURE TYPE SGBD

SYNTAXE
ANALYSEUR SEMANTIQUE
SCHEMA

VUES
CONTROLE INTEGRITE
AUTORISATIONS

ORDONNANCEMENT
META-BASE OPTIMISEUR ELABORATION
D'UN PLAN

EXECUTABLE EXECUTION
METHODES D'ACCES
Traitement d’une requête SQL

Analyse de la
requête Analyse sémantique
à l’aide de dictionnaire
Analyse syntaxique
de données

Erreur de type1 Erreur de type2

Optimisation de l’arbre
algébrique

Exécution du plan
choisi
38
2. Évaluation des requêtes (1)

L‟évaluation d'une requête se fait en 3 Étapes :

1. Analyse
 Syntaxique
 Sémantique
Vérifier correction
Simplification du critère de recherche

2. Ordonnancement
 Décomposer la requête en séquences d'opérations élémentaires
(Algèbre relationnelle).
 Déterminer un ordre +- optimal.
 Génération d'un plan d'exécution
3. Exécution
 Exécution en parallèle ou en séquences des opérations élémentaires selon
le plan d'exécution défini en 2

Rôle des SGBD Relationnels

Avant de s'intéresser à l'évaluation complète d'une requête, on étudie
l'évaluation des opérateurs et leur coût respectifs

Considérons :
SELECT *
FROM Pilote, Certification
WHERE Pilote.IdP = Certification.IdP;
Opération fondamentale utilisée par toutes les applications BD.
L'Algèbre Relationnelle nous dit que R ⨝ S = σ=(R x S), mais c'est très inefficace,
on veut optimiser ce cas!
On suppose dans la suite M pages dans R, PR enregistrements/page, N pages
dans S, PS enregistrements/page.
On pose pour les exemples: M=1000, N=500, PR=120, PS=100

Le coût est toujours le nombre d'E/S (en ignorant l'écriture du résultat)

 Jointure itérative simple

On effectue une double boucle imbriquée:

for each record r ∈ R do
for each record s ∈ S do
if r.IdP = s.IdP then res += r ⨝ s /** jointure élémentaire dec2 enregistrements
done
Done

Pour chaque enregistrement de la relation externe (R) on scanne entièrement la

relation interne (S)

Coût: M + PR * M * N

Exemple: 1000 + 120*1000*500 = 60 001 000 E/S!

 Jointure itérative page à page

On effectue une double boucle imbriquée:

for each page P ∈ R do

for each page Q ∈ S do
res += P ⨝ Q /** jointure entre 2 pages peut être faite de manière simple
Done
Done

Pour chaque page de la relation externe (R) on scanne entièrement la relation

interne (S)
Coût: M + M * N

Exemple: 1000 + 1000*500 = 501 000 E/S!

Optimisation: mettre la relation la plus petite à l'extérieur:
500 + 500*1000 = 500 500
 Jointure itérative avec index

On effectue une double boucle imbriquée:

for each record r ∈ R do
for each record s ∈ S where r.a = s.a do
/** l'index doit permettre un accès rapide à la colonne IdP
res += r ⨝ s
done
Done

On exploite l'existence d'un index sur l'une des relation pour en faire la relation
interne.
Coût: M + PR * M * (coût d'accès index + coût index ↦ données)
Plusieurs variantes: B+-tree/Hash-index, groupant/non-groupant,…
Ordonnancement par restructurations algébriques

 Arbre algébrique --> Plan d'exécution (feuille -> racine):

 Exécution en // .....
 Optimisation des temps de réponse :
o Optimiser le nombre de E/S
o Le parallélisme entre E/S
o La taille des tampons nécessaires à l'exécution
o Le temps de CPU nécessaire.
 Optimisation par ordonnancement optimal des opérations

A1 (arbre initial) plan d'execution 1

règles de transformation
+ heuristiques

Aopt (arbre optimal) plan d'execution n

A1 <=> Aopt
Règles de transformation
Heurist iques d'Optimisat ion [ULLMAN]

1. Séparer les restrictions comportant plusieurs prédicats à l'aide de la règle 3

2. Descendre les restrictions aussi bas que possible à l'aide des règles 4, 5 et 6.
(Exécution d'abord dans opérations unaires)
3. Regrouper les restrictions successives portant sur une même relation
4. Descendre les projections aussi bas que possible à l'aide des règles 7 et 8
5. Regrouper les projections successives en conservant les attributs restants et
éliminer d'éventuelles projections inutiles qui auraient pu apparaître.
Afin d'éviter plusieurs passes sur une même relation, sont exécutées simultanément:
une restriction suivie par une projection
une jointure suivie par une projection.
Optimisation logique d‟une BD relationnelle : dénormalisation
Rappel

 La normalisation est le processus qui permet d'optimiser un modèle logique afin

de le rendre non redondant. Ce processus conduit à la fragmentation des
données dans plusieurs tables.

Définition : Dénormalisation

 Processus consistant à regrouper plusieurs tables liées par des références, en

une seule table, en réalisant statiquement les opérations de jointure adéquates.
 L'objectif de la dénormalisation est d'améliorer les performances de la BDD en
recherche sur les tables considérées, en implémentant les jointures plutôt qu'en les
calculant.

Problématique de la dénormalisation :
• Regroupement de tables
• Création de redondances d'attribut non clé
• Ajout de clé étrangère redondante
• Création de transitivité
•Création de tables de jointure
La dénormalisation :
• ensemble de règles d'optimisation structurelles du modèle logique relationnel
• ces règles garantissent le respect des spécifications initiales :
• tout autre type de modification, sous couvert d'optimisation, peut entraîner une
altération de la sémantique du modèle conceptuel de données
• pour chacune de ces règles il faut estimer les gains espérés et les pertes générées,
ainsi que les conséquences secondaires

Les optimisations structurelles obtenues par dénormalisation :

• devront être conduites avec prudence, car elles ont des conséquences qui doivent
être estimées
• l'efficacité de ces différentes optimisations dépend du SGBD utilisé : certaines
même ne seront pas toujours possibles sur tel ou tel système.
• le concepteur optimise son modèle par modifications successives de la structure,
en évaluant le bien fondé de son choix en estimant le "gain" total par rapport aux
critères économiques définis.
 Exercice1 d‟Application

Soit le schéma relationnel suivant :

Etudiants(Enumero, Enom, EAnNaissance, Einfo)

Exams(NomCours, Enumero, Note, Info)

1. Ecrire, sans utiliser l‟operateur logique AND, une requête SQL pour savoir
les noms des étudiants qui ont soutenu l‟exam de Base de Données.
2. Optimiser la requête SQL (cette fois en utilisant l‟operateur logique AND).
3. Donner l‟arbre algébrique de la requête.
1. Pour écrire la requête sans utiliser AND il faut utiliser l‟operateur IN et
écrire :
 III. Gestion et manipulation des transaction
III.1 But

 En bases de données, le concept de transaction a été introduit depuis près d‟un

demi siècle [Bjork L.A. et al.« The Semantics of the Preservation and Recovery of
Integrity in a Data System », Technical Report TR-02.540, IBM, Dec. 1972].
 Le concept de transaction est fondamental pour maintenir la cohérence des
données. Une transaction est une unité de mise à jour composée de plusieurs
opérations successives qui doivent être toutes exécutées ou pas du tout.
 Le SGBD doit garantir les fameuses propriétés ACID des transactions. Outre
l‟atomicité mentionnée, les transactions effectuent des accès concurrents aux
données qui doivent être contrôlés afin d‟éviter les conflits entre lecteurs et
écrivains.
 En conséquence, la gestion de transactions mélange intimement les problèmes
de fiabilité et de reprise après panne avec les problèmes de concurrence d‟accès.
 Les problèmes de sécurité qui recouvrent la confidentialité sont aussi connexes.
 III.2 Notion de Transaction

 Un modèle simplifié de SGBD se compose de programmes utilisateurs, d‟un

système et de mémoires secondaires. Les programmes accèdent aux données au
moyen d‟opérations du SGBD (Select, Insert, Update, Delete).
 Ces opérations déclenchent des actions de lecture et écriture sur disques (Read,
Write), qui sont exécutées par le système, et qui conduisent à des entrées-sorties
sur les mémoires secondaires.
 Afin de pouvoir déterminer les parties de programmes correctement exécutées,
le concept de transaction a été proposé depuis longtemps.
 III.2 Notion de Transaction (1)

Un exemple typique de transaction est fourni au travers une base de données

bancaire.

La base se compose des tables Agences, Comptes, Caissiers et Historique

Le code de la transaction apparaît (figure ). Il réalise le crédit ou le débit d‟un

compte d‟un montant Delta et répercute cette mise à jour dans les autres tables.
 III.2 Notion de Transaction(2)
 Une transaction est construite à l'aide de 3 primitives offertes par le SGBD :
 Ouverture d'une transaction : begin-transaction
 Clôture avec confirmation : COMMIT
 Clôture avec annulation : ROLLBACK

 Principe :
 Le SGBD garantit les propriétés ACID lorsqu'il exécute une primitive;
 Si le programmeur désire que cette propriété s'applique à une séquence
d'instructions, il doit en faire une transaction :

begin-transaction
acquisition des données
modification des données
si erreur ROLLBACK et sortie
COMMIT
suite du traitement
 III.2 Notion de Transaction (4)

Annulation d‟une Transaction

Evénements survenant lors de l'exécution d'une transaction :

• Arrêt interne (géré par le programmeur)
Lors de l'exécution d'une transaction, une condition peut être détectée, rendant la
poursuite de la transaction impossible.
Exemple : violation d'une contrainte d'intégrité
Action du SGBD : effacer toute trace de la transaction annulée.

• Arrêt externe (panne - géré par le SGBD)

Au cours de l'exécution des primitives, un événement extérieur peut arrêter
définitivement l'exécution de la transaction

Exemple : panne
Action du SGBD : effacer toute trace de la transaction annulée après la reprise
(reprise après panne)
 III. 3 Propriétés d'une transaction :

 Une transaction vérifie, relativement à la base de données, les 4 propriétés „A.C.I.D. „ :

Atomicité, Cohérence, Isolation et Durabilité.
1. Atomicity (atomicité) : l'ensemble des instructions de la section sont exécutées
complètement (en cas de succès), ou pas du tout (en cas d'incident), mais jamais
partiellement;
 Une transaction doit être traitée comme une seule opération, c-a-d que le SGBD
doit assurer que toutes les actions de la transaction sont exécutées ou bien
qu'aucune.
Exemple :
begin-transaction;
INSERT ... ;
DELETE ... ; Actions exécutées
Panne
INSERT ... ;
DELETE ..; Actions suspendues
COMMIT;
 Si l'exécution d'une transaction est interrompue à cause d'une panne
quelconque, le SGBD doit être capable de décider des actions à entreprendre
après la reprise après la panne :
 Soit compléter la transaction en exécutant les actions restantes.
 Soit défaire les actions qui avaient déjà été exécutées avant la panne.
2. Consistency (cohérence) : si la BD est cohérente avant la transaction, elle le sera
à la sortie de celle-ci (respect des contraintes d'intégrité);
 Base de données dans un état cohérent :
si les données de la base vérifient toutes les contraintes dʼintégrité définies sur la
base de données

 Problème :
Des contraintes ne sont satisfaites que suite à une séquence de plusieurs primitives !
Ceci génère des états intermédiaires incohérents

Example :
Après la suppression d'une commande (contrainte: toute ligne de commande doit
être associée à une commande), la BD peut être incohérente.

begin-transaction; Etat cohérent

delete from COMMANDE where num_cde = 1 ; Etat incohérent !
delete from LIGNE where num_cde = 1 ; Etat cohérent
COMMIT;
3. Isolation (indépendance) : les interactions entre la transaction et la base de
données s'effectuent comme si la transaction était seule à travailler sur la BD (pas
d'interférences nuisibles avec les autres transactions);
=> propriété à assurer pour des transactions concurrentes

4. Durability (permanence) : si la transaction s'est terminée correctement, les

modifications faites dans la BD sont garanties permanentes (sauf modifications via
d'autres transactions), quels que soient les incidents ultérieurs.

 Propriété qui assure que lorsqu'une transaction a été confirmée (COMMIT), ses
effets deviennent permanents.

 Importance: après un arrêt externe (panne) le SGBD doit sʼassurer que :

 les effets d'une transaction validée apparaissent dans la base de données
après la reprise
 les effets d'une transaction annulée n'apparaissent pas dans la base de
données après la reprise
 III. 4 Transactions concurrentes

 Deux transactions sont concurrentes si elles accèdent en même temps

aux mêmes données.

 Problème possibles :

lorsque certaines transactions font des mises jour sur la Base de Données :
• Perte de mise à jour
• Lecture impropre
• Lecture non reproductible
 III. 4 Transactions concurrentes (1)

Perte de mise à jour

T1 et T2 transactions concurrentes:
• T1 : lire (x) ; x := x + 15 ; écrire (x)
• T2 : lire (x) ; x := x + 11; écrire (x)
• Au départ x = 18

T1 T2
lire (x); (dans BD x=18);
x := x + 15;
lire (x); ( dans x= 18)
écrire (x) (Dans BD x=33)
x := x + 11;
écrire (x); (dans BD x=44)

Remarque : la mise à jour effectuée par T1 a été écrasée par celle faite par T2
 III. 4 Transactions concurrentes (2)

• Lecture impropre

T1 T2
UPDATE comptes
SET solde = 11 000
WHERE num_compte = ʻ11ʼ ;
SELECT solde
FROM comptes
WHERE num_compte = ʻ11ʼ ;
ROLLBACK

Remarque :

• Propriété d'atomicité : la mise à jour ne devrait pas être prise en compte

• Dès lors, la valeur lue par T2 est incorrecte.
• Cette valeur est dite impropre (T2 lit des données non confirmées)
 • Lecture impropre (1)
• T1 et T2 transactions concurrentes
• T1 transfère 1000 DA du compte ʻ11ʼ vers le
compte ʻ22ʼ
• T2 affiche le solde total des 2 comptes

T1 T2
UPDATE Comptes
SET solde = solde - 1000
WHERE num_compte = ʻ11ʼ ;
SELECT SUM (solde)
FROM Comptes
WHERE num_compte in (ʻ11ʼ,
ʻ22ʼ) ;
UPDATE Comptes
SET solde = solde +1000
WHERE num_compte = ʻ22ʼ
COMMIT

Remarque
• la somme des comptes affichée par T2 est incorrecte puisque le solde du compte „22'
n'a pas encore été mis à jour
• Etat intermédiaire incohérent de la base de données
 • Lecture non reproductible

• T1 et T2 transactions concurrentes
• T1 effectue plusieurs fois la lecture du même objet

T1 T2
SELECT points FROM Resultats
WHERE num_cours = 22 AND
num_eleve = 33 ;
UPDATE Resultats
SET points = points * 1.1
WHERE num_cours = 22
AND nom_eleve = 33 ;
SELECT points FROM Resultats
WHERE num_cours = 22 AND
num_eleve = 33 ;
COMMIT

Remarque :
•En principe, T1 doit obtenir à chaque lecture la même valeur
• Mais, si entre 2 lectures de l'objet, celui-ci est modifié par T2, T1 n'obtient plus le
même valeur : lecture non reproductible !
 III. 4 Verrouillage

 Diverses techniques selon les SGBD, consistant toutes à réaliser un verrouillage

temporaire de la BD :
 d'une partie plus ou moins grande de la BD (BD, sous-ensemble de la BD,
table, page, tuple,....),
pendant un temps plus ou moins long (le temps d'une transaction,....),
tenir compte du fait que les opérations effectuées par les utilisateurs sur la
base peuvent être soit en consultation soit en mise à jour:
 Deux types de verrous :
verrou exclusif (write lock): ! installé pour une opération de MAJ, il interdit
à d'autres utilisateurs d'effectuer simultanément d'autres MAJ ou
consultations sur une même partie de la BD
verrou partagé (read lock): ! installé pour une opération de consultation, il
permet à d'autres utilisateurs d'effectuer simultanément d'autres
consultations sur une même partie de la BD, et interdit toute mise à jour.

 Verrouillage à "2 phases" :

 phase de croissance d'acquisition de verrous (SEIZE BLOCK)
phase de décroissance de libération de verrous
 IV. Gestion de la sécurité des bases de données
IV. 1 Sécurité et Intégrité

 Pour assurer la sécurité des bases de données , les données doivent être
protégées contre :

 Les accès non autorisés ( la malveillance ).

 Les modifications erronées.
 Les inconsistances accidentelles.
Le piratage.

 Nous avons introduit le concept de vue en tant que personnalisation de la BD vis

à vis de l'utilisateur.

 Ainsi, une vue cache les données que l'utilisateur n'a pas besoin de voir.

 Cette fonction sert aussi bien à simplifier l'usage de la BD qu'à renforcer la

sécurité.
 IV. Gestion de la sécurité des bases de données (1)

 Spécifier les autorisations, c‟est à dire les règles qui permettent de définir qui a le
droit d‟effectuer un tel type d‟opération sur telles données.

 Les systèmes de bases de données relationnelles assurent leur sécurité à deux

niveaux :

 Au niveau des relations, un utilisateur peut être autorisé ou non à accéder à

une relation donnée.

 Au niveau des vues, un utilisateur peut être autorisé ou non à accéder aux
données qui font partie d'une vue donnée.
Causes de violation de la sécurité

 Crashes pendant le traitement des transactions (les interruptions système ou

bien matériels).
Anomalies dues à la répartition des données sur plusieurs sites (ce problème
apparaît dans l‟approche BD repartie).
Erreurs logiques contradictoires avec l‟hypothèse de conservation de la
consistance de la base par des transactions qui s‟y déroulent lors de l‟échange des
données entre plusieurs utilisateurs. C‟est à dire la perte de consistance lors de
l‟échange des données entre différents utilisateurs ou transactions.
La malveillance des utilisateurs c‟est à dire la mauvaise utilisation des données
d‟une façon intentionnelle (modification, destruction,…).
 IV. 2 Niveaux de Sécurité

Pour protéger une BD, des mesures de sécurité doivent être prises sur plusieurs
niveaux:
 Physique: Les sites qui hébergent les données et les SGBDs doivent être
physiquement armés contre les intrusions en force.
 Humain: Les autorisations doivent être accordées d‟une façon sélective afin
qu‟un utilisateur ne cède ses autorisations à une personne malveillante.
 Système: Quelle que soit la sûreté de la BD, des faiblesses éventuelles dans la
sécurité de systèmes de gestion de base de données peuvent être mises à
profit pour pénétrer la base. Donc, la sécurité du logiciel système est aussi
importante que la sécurité physique de la base.
 Base de donné : Le système doit s‟assurer que les restrictions des accès ne
sont pas violées.
 Les systèmes de gestion de bases de données assurent leur sécurité en deux
niveaux:
 Niveau des relations: Un utilisateur peut être autorisé ou non à une relation
donnée.
 Niveau des vues: Un utilisateur peut être autorisé ou non à accéder aux
données qui font partie d‟une vue donnée.

 Une vue cache les données qu‟un utilisateur n‟a pas besoin de les voir, donc,
elle facilite l‟accès à la base et renforce sa sécurité.
 Les raisons d‟utiliser la vue comme une approche de protection sont les
suivantes :
 Elle est mieux adaptée pour restreindre l‟accès à la base de donnée.
 Sa définition est statique mais les données aux quelles on accède à travers
la vue sont dynamiques.
 Elle est adaptée pour implémenter les niveaux dans une multibase de
données.
 Autorisations pour les vues et les relations

 Un utilisateur peut bénéficier de plusieurs habilitations lors de son accès à la

base:
 l‟autorisation de lecture ,sans avoir le droit de modifier des données
(READ).
 L‟autorisation d‟insertion (INSERT).
 L‟autorisation de mise à jour (UPDATE).
 L‟autorisation d‟effacement des données (DELETE). Ces autorisations font
partie de langage de manipulation des données.

 Il y a aussi celles qui font partie de langage de définition des données:

 L‟autorisation d‟accès aux index (pour création et effacement des index).
 L‟autorisation d‟accès aux relations ,pour créer des nouvelles relations
(RESOURCE).
 L‟autorisation d‟altération des relations, par ajout ou élimination des
attributs (ALTERATION).
 L‟autorisation d‟abandon, pour effacer des relations (DROP).
 Contraintes d‟intégrité:

Les contraintes d‟intégrité sont des règles par rapport à elles se fait le contrôle de
validité sur les opérations effectuées.
Ils existent plusieurs types de contraintes d‟intégrité (temporelles, référentielles ,etc.).
Les contraintes d‟intégrité protègent la base contre une perte de consistance lors des
modifications effectuées par les utilisateurs autorisés.
 Privilèges d'accès

 Un utilisateur, en fonction de son titre, peut avoir plusieurs types de privilèges :

Lecture;
Insertion;
Mise à jour;
Effacement;
Accès aux index;
Accès aux relations (création, modification, abandon).

 Pour gérer les droits d'accès à la BD, on peut à l'aide de SQL accorder des
privilèges par l'instruction GRANT.

Grant “liste de privilèges” on “relation ou vue” to “liste d'utilisateurs”

La liste de privilèges permet d'en attribuer plusieurs à la fois sous une
même instruction : select, insert, delete, update, ...
Privilèges d'accès (1)

 Pour retirer des privilèges à un utilisateur, on utilise la commande revoke.

REVOKE {liste_privilèges | ALL [PRIVILEGES]} ON objet FROM {liste_utilisateurs | PUBLIC}]

Exemples:

GRANT ALL PRIVILEGES ON EMPLOYE TO Tarek

GRANT SELECT, UPDATE (SALAIRE) ON EMPLOYE TO Fatima
REVOKE UPDATE ON EMPLOYE TO Fatima
Permet de
personnaliser la
base en fonction des
utilisateurs et de
leurs permissions
d'accès et à la
modifications des
données.

Restriction sur les

colonnes de la
BD en fonction
du code d’accès
de l’utilisateur
 Cette figure montre l'utilisation d'une vue pour restreindre l'accès à des tuples
précis de la BD en fonction du code d'accès de l'utilisateur.

Restriction d‟accès
sur les tuples
 Cryptage des données

 Les précautions très diverses que l'on peut prendre pour protéger une BD
peuvent ne pas être suffisantes pour des données très importantes.

 Dans de tel cas, celles-ci doivent être cryptées. Il n'est pas possible de lire de telles
données à moins de connaître le code qui permet le décryptage.

 Exemple:

Mohamed Ali devient C^;^->N;^ @^>Y>

Un intrus avisé qui consulte un grand nombre de données peut briser le code
utilisé.

Un exemple de mauvais cryptage :

Mohamed Ali devient Spcfsu Mfgfcwsf
 Cryptage des données

Un bon système de cryptage des données possède les propriétés suivantes :

il doit être simple pour l'utilisateur de crypter et de décrypter les données

qu'il manipule,
le processus de cryptage ne dépend pas de la confidentialité de
l'algorithme mais d'une clé de cryptage,
la clé de cryptage doit être excessivement difficile à identifier pour un intrus.
 Exercice 2 d ‟Application
Soit la base STATION thermale contenant les relations suivantes :
– hôtel (noms, nomh, catégorie, adresse, tel,nb_chambres) (5 catégories différentes,1000 pages,
chaque page contient 10 tuples).
– station (noms, Lieu) (100 pages, chaque page contient 10 tuples).
– soin (type_Soin, noms) (100 pages, chaque page contient 10 tuples).
On suppose de plus l‟existence des index suivants (arbres B+) :
– Index sur le couple (noms, nomh) de la relation hotel (26 pages).
– Index sur l‟attribut categorie de hotel (33 pages).
Hypothèses :
– Chaque catégorie comprend un nombre égal d‟hôtels.
– Chaque station comprend un nombre égal d‟hôtels.
– Le nombre d‟E/S lors du parcours de l‟arborescence des index est négligeable.

Requête : adresse, numéro de téléphone et nombre de chambres des hôtels de catégorie 3‟

dans la station de nom ‟Bouhanifia‟ .
SELECT adresse, tel, nb_chambres
FROM hotel
WHERE noms=‟pesey‟ AND categorie=3;
Calculer le nombre d‟E/S effectuées lors de l‟évaluation de cette requête de sélection par un
parcours séquentiel de la relation hôtel.
Calculer le nombre d‟E/S effectuées lors de l‟évaluation de cette requête en utilisant l‟index sur
categorie.
Calculer le nombre d‟E/S effectuées lors de l‟évaluation de cette requête en utilisant l‟index sur
noms,nomh.
Conclure
Exercice 2 : Solution :

(1) Balayage séquentiel On évalue séquentiellement la condition sur tous les tuples
de la relation, ceux-ci étant chargés page par page. Le nombre d‟E/S est donc le
nombre de pages nécessaires pour stocker la relation hotel soit 1000 : NE/S = 1000.

(2) Index sur categorie