Les requêtes

1
 Plan
• Requête et transaction
• Propriétés algébriques
• Optimisation des requêtes
• Protocole à deux phases

2
 Transaction
• Une transaction:
– séquence d'instructions (LMD) qui soit réussit, soit
échoue.
• Les transactions doivent posséder les
propriétés ACID :
• Atomicité : les opérations sont exécutées dans leur
totalité ou pas du tout (begin, commit, abort): une
transaction est complète ou abandonnée
complètement .
• Consistance : transformation correcte de l ’état du
système (ne violant aucune contrainte d ’intégrité):
une transaction doit transformer le système d'un
état consistant à un autre état consistant.
3
• Isolation : les changements sur les données ne
sont visibles par les autres transactions
qu ’une fois la transaction achevée: chaque
transaction est vue indépendamment des
autres.
• Durabilité : les modifications qui suivent une
validation doivent survivre à une panne du
système: les transactions validées ont des
effets permanents

4
5
 Traitement de requêtes séquentielles
• L’exécution d’une requête séquentielle passe par
plusieurs phases:
– une analyse lexicale, syntaxique et sémantique est
effectuée,
– la requête est transformée en un arbre d’exécution
logique,
– Cet arbre est optimisé par l’application des
transformations de l’algèbre relationnelle
– un plan d’exécution physique est produit en
choisissant le meilleur chemin d’accès aux données.

6
 Analyse de requête
• Vérifier la validité de la requête en consultant le
dictionnaire de données pour voir l’existence des
relations et des attributs .
• Examiner la validité grammaticale.
• Pour générer un plan d’exécution optimal, des
simplifications sémantiques sont effectuées tel
que la détection de contradiction (ex :age=12 et
age>15)

7
 Traduction algébrique
• Traduire la requête en une expression algébrique
sous forme d’arbre.
• L’arbre est composé des nœuds, des arcs, et des
feuilles.
– les feuilles représentent les tables (relations),
– les nœuds représentent les operateurs algébriques,
– les arcs représentent, les flux de données allant d’un
nœud fils vers son nœud père.

8
• Le résultat est un Plan d’Exécution Logique(PEL) qui
sera transformé en un Plan d’Exécution
Physique(PEP)
• L’exécution débute des feuilles qui manipulent les
tables, les résultats sont ensuite envoyés aux nœuds
pères et ainsi de suite jusqu’à l’obtention de résultat
final à la racine.

9
 Optimisation
• L’optimisation se déroule en deux phases :
l’optimisation logique et l’optimisation physique.
• 1 L’optimisation logique(Rewriting) :
• Le principal but est de réduire le volume de
données manipulé en appliquant les règles de
transformation de l’algèbre relationnelle ainsi
que des heuristiques pour produire de bonnes
stratégies d’exécutions.

10
 Règles de transformation de l’algèbre relationnelle

Ces règles sont utilisées pour descendre les sélections, le plus bas
possible dans l’arbre
11
12
 Restructuration algébrique
• Transformation de l'expression algébrique pour en
obtenir une autre "meilleure" équivalente
– Utilisation des règles de réécriture
• Quelles transformations choisir?
– choix heuristiques
• Exemple d'algorithme de restructuration simple
– 1. Descendre les sélections le plus bas possible dans
l'arbre (règles de commutativité et distributivité de la
sélection)
– 2. Regrouper les sélections sur une même relation
(règle de regroupement des sélections)
13
• 2 L’optimisation physique :
• Ordonner (un ordre quasi optimal) les
opérations algébriques élémentaires
(atomiques) pour que les algorithmes de
recherche, de tri, et de jointure s’exécutent
plus efficacement. Cette optimisation dépend
du schéma interne de la base de données
(index, contraintes d’intégrite) et de la taille
des tables.

14
• Un plan d’exécution physique (PEP) est le
résultat final de la phase d’optimisation, ce
plan d’exécution est sous la forme d’un arbre
dont :
• Les nœuds : des opérateurs physiques (atomiques).
• Les feuilles : ce sont des liens (chemins) physiques
aux tables (relations) et index.
• Les arcs : ils représentent le flux de données, ces flot
peuvent être séquentiels ou pipelines.
• Le résultat final est au niveau de la racine.

15
• Select C.name from Etudiants E,
Inscription I, Cours C where
E.ssn= I.ssn and I.cid= C.cid and
E.name= ‘Mary’;

16
Plan d’exécution

17
 Requête répartie
• Les opérations précédentes (par exemple)
accèdent à des données situées sur différents
sites.
• Le SGBD gère les accès distants en répartissant
la requête
– Exécution distante de la sous requête
– Récupération de données résultat
– Assemblage local (requête en lecture)

18
 Optimisation de requête répartie
• Optimiser: choisir parmi de nombreuses possibilités,
une stratégie d'exécution de requête efficace.
• Établissement d’un plan d’évaluation optimal
• Optimisation d’une fonction de coût ou de temps de
réponse:
• coût global :
– coût(E/S)
– coût(Processeur)
– coût(Communication) (messages) …
• Ex: Si l'utilisateur soumet une requête au SGBD, le
composant Query Processor (Oracle) récrit la requête
sous une forme plus simple, et optimale.
19
• L'optimisation d'une requête intervient à deux principaux
niveaux :
– Décomposition de la requête
– Répartition de la requête
• Décomposition de la requête
– Normalisation: écrire la partie critère (contenu dans la clause
WHERE) sous forme d'une conjonction de coordination ou
disjonction de conjonction de prédicats WHERE (a et b) ou (c et d).
– Analyse: détecter et éliminer les erreurs
la présence de champs ou relations inexistants, l'incohérence des valeurs
données avec les types réels des champs, etc.
– Elimination des redondances
• NON (NON A) == A
• A ET A == A
• A OU A ==A
– Réécriture: réécrire la requête en une forme qui améliore ou
optimise le temps de traitement global. 20
• Répartition de la requête
– décomposer la requête globale en requêtes sur les
fragments
– des reconstructions sont encore faites afin d'annuler les
formules dont les conditions ne respectent pas les
restrictions des fragments auxquelles elles font référence.
– on peut remplacer certaines opérations par d'autres,
comme la jointure par la semi-jointure car moins
coûteuse.
– selon la localisation de chaque fragment et l'existence ou
non de relations répliquées, une stratégie d'exécution est
mise en place afin de minimiser les trafics réseaux et
bénéficier de rapides accès aux données et traitements
du CPU.
21
 Schéma général de l’optimisation
• Dans un système distribué, l'optimisation peut se
faire de trois manières principales :
– Une optimisation centralisée: un site central détermine la
stratégie d'exécution sur tous les autres sites.
• l'optimisation est plus facile mais souvent peu efficace car il
faudrait connaître exactement les indices de chaque site…
– Une optimisation distribuée où chaque site a sa propre
stratégie d'optimisation
– les deux première méthodes pour en faire une hybride:
• dans un premier temps, un site décide de l'optimisation globale
et ensuite chaque site optimise à son tour, à son niveau.

22
 Utilisateur Les composants d'un
réponse du système demande de l'utilisateur DBMS distribué et le
déroulement de
requêtes

gestionnaire de l'interface utilisateur schéma externe

Processor de l'utilisateur
contrôleur sémantique des données

schéma
conceptuel global

optimiseur global de requêtes

moniteur de l'exécution globale

23
• 1) Le gestionnaire de l'interface utilisateur interprète les commandes de l'utilisateur

à leur arrivée et formate les résultats pour être émis à l'utilisateur.

• 2) Le contrôleur sémantique des données utilise les contraintes d'intégrité des

données et les autorisations qui ont été définies dans le schéma conceptuel global

des données. Le contrôleur se base sur eux pour vérifier si la requête de

l'utilisateur peut être traitée.

• 3) L'optimiseur global des requêtes est aussi leur décomposeur, il détermine une

stratégie d'exécution pour minimiser la fonction coût d'exécution. Il traduit aussi la

requête globale en un ensemble de requêtes locales en utilisant le schéma

conceptuel global ainsi que les schémas conceptuels locaux et le dictionnaire

global.

• 4) Le moniteur de l'exécution globale coordonne les exécutions distribuées des

requêtes de l'utilisateur. Ce moniteur est aussi appelé le gestionnaire des

24
transactions distribuées.
 schéma conceptuel local
processeur de requête local
Processor des données

gestionnaire local de recouvrement

log système

processeur d'exécution schéma interne local

25
• 1) Le processeur de requêtes locale ou l'optimiseur des
requêtes locales, qui détermine le schéma d'exécution optimal
• 2) Le gestionnaire local de recouvrement assure la
consistance des bases de données locales même si une
requête échoue.
• 3) Le processeur d'exécution accède réellement à la base de
données en exécutant des requêtes et ce conformément aux
étapes spécifiées par l'optimiseur de requêtes. Ce composant
correspond à l'interface avec le système d'exploitation, et
contient le buffeur de la base ou encore le gestionnaire du
cache qui facilite les accès.
26
Exemples

27
28
29
30
Choix de solution

31
 Coût de la solution
• Supposons
– taille (Cde1) = taille (Cde2) = 10 000
– taille (Client1) = taille (Client2) = 2 000
– coût de transfert de 1n-uplet = 1
– Qt>10 ~1%
• Stratégie 1
– transfert de Cde1 + Cde2 = 20 000
– transfert de Client1 + Client2 = 4000
• Stratégie 2
– transfert de C1 + C2 = 200
– transfert de C3 + C4 = 200
32
• Importance de la fragmentation horizontale
pour augmenter le parallélisme inter- et
intra-requête
• Utiliser la fragmentation verticale si forte
affinité d'attributs et beaucoup d'attributs
• L'optimisation reposant sur un modèle de
coût, est critique s'il y a beaucoup de sites

33
 Transparence des requêtes
• Schéma de fragmentation
– définition des fragments
• Schéma d'allocation
– contient la localisation

34
35
 Transactions réparties
• OBJECTIF
– Garantir que toutes les mises à jour d'une transaction
sont exécutées sur tous les sites ou qu'aucune ne l'est.
• EXEMPLE
– Transfert de la somme X du compte A vers le compte B
– DEBUT
site 1: A = A – X
site 2: B = B + X PANNE --> INCOHERENCE DONNEES
- FIN
• PROBLEME
– Le contrôle est réparti : chaque site peut décider de
valider ou d’annuler ...

36
 Transactions réparties
• PROBLEME
– 1 transaction globale T
– => N transactions locales Ti
– nécessité d'une coordination entre les sites
locaux Si
• SOLUTION
– un site coordinateur C
– un protocole de validation en 2 étapes

37
 Commit en deux phases
• Principe
– Diviser la commande COMMIT en deux phases
– Phase 1 :
• Préparer à écrire les résultats des mises à jour dans la BD
• Centralisation du contrôle
– Phase 2 :
• Écrire ces résultats dans la BD
• Coordinateur :
– Le composant système d'un site qui applique le protocole
• Participant :
– Le composant système d'un autre site qui participe dans
l'exécution de la transaction
38
 Protocole C/S
• PREPARER
– Le coordinateur C demande aux autres sites Si s’ils sont prêts à
commettre leurs mises à jour.
• 2a. SUCCES : COMMETTRE
– Tous les participants effectuent leur validation sur ordre du
coordinateur.
• 2b. ECHEC : ABORT
– Si un participant n’est pas prêt, le coordinateur demande à tous
les autres sites de défaire la transaction.
• REMARQUE
– Le protocole nécessite la journalisation des mises à jour
préparées et des états des transactions dans un journal local à
chaque participant.
39
• PHASE 1
• -> Le site C ajoute <T préparée> dans son
journal
• -> Le site C envoie "prêt à commettre T" à tous
les sites Si
• -> Chaque site Si prend une décision :
– s'il valide Ti , alors :
• Le site Si écrit <T prête à commettre> dans son journal
• Le site Si envoie "T prête" au site C
– s'il ne valide pas Ti , alors :
• Le site Si écrit <non T> dans son journal
• Le site Si envoie "abort T" au site C
40
• PHASE 2
• -> A partir des messages reçus des sites Si et
au terme d'un laps de temps déterminé, le
site C prend une décision :
– il valide T s'il a reçu "T prête" de tous les sites Si :
• il ajoute <T validée> à son journal
• il envoie "valider T" à tous les sites
– il avorte T s'il a reçu au moins un message "abort
T" d'un site Si (ou au bout du laps de temps
spécifié) :
• il ajoute <T abortée> à son journal
• il envoie <abort T> à tous les sites Si

41
• Chaque site Si :
– inscrit dans son journal le message envoyé par le
site C
( <T validée> ou <T abortée> )
– envoie un accusé de réception au site C
• Quand le site C a reçu tous les accusés des
sites Si , il ajoute :
<T finie> à son journal

42
Cas favorable

43
Cas défavorable

44
 Panne d’un participant
• Un site participant Si tombe en panne
==> REPRISE A FROID DE Si
• Analyse du journal du site Si :
– <T validée> => refaire T
– <T abortée> => défaire T
– <T prête à commettre>
=> consulter le site C pour avoir l'état de T :
C répond => Si a connaissance de l'état de T
C ne répond pas => Si envoie une demande de l'état de T à
tous les sites
– Rien concernant T => Si sait que C a aborté T
45
Cas de panne d’un participant

46
 Exemple
• Exemple - Définition de la base de données :
• B : buveurs (N°B, nom, prénom, ville)
• V : vins (N°V, cru, millésime, degré)
• C : commandes (N°V,N°B, date, quantité)
• Exemple de requête, de sa traduction et de son
optimisation en l’absence de répartition :
• SELECT nom, prénom FROM buveurs (B), vins (V),
commandes (C)
WHERE V.cru = « Volnay » AND V.degré > 12 AND
C.quantité > 100
AND C.N°V = V.N°V AND C.date >1/1/2000 AND B.N°B =
C.N°B AND B.ville = « Paris » 47
SELECT nom, prénom FROM buveurs (B), vins (V), commandes (C)
WHERE V.cru = « Volnay » AND V.degré > 12 AND C.quantité > 100
AND C.N°V = V.N°V AND C.date >1/1/2000 AND B.N°B = C.N°B AND
B.ville = « Paris »

48
49
SELECT nom, prénom FROM
buveurs (B), vins (V),
commandes (C)
WHERE V.cru = « Volnay »
AND V.degré > 12 AND
C.quantité > 100
AND C.N°V = V.N°V AND
C.date >1/1/2000 AND B.N°B
= C.N°B
AND B.ville = « Paris »

50
Exemple

51
52
53
 Recommandations de C.J Date (12)
• L'AUTONOMIE LOCALE
– Chaque site doit fonctionner indépendamment des autres même s’il y a des pannes.
Donc chaque site est responsable de l'intégrité, la sécurité et la gestion de sa base de
données.
• NE PAS SE REPOSER SUR UN SITE UNIQUE
– Viser à éviter des arrêts de production lorsqu'un site tombe en panne. On peut soit
penser à ce que Oracle appelle la réplication avancée ou les données sont
entièrement répliquées d'un site à l'autre.
• OPERATION EN CONTINU
– Assurer le fonctionnement continu du système réparti par des mises à jour et
maintenances effectuées.
• TRANSPARENCE VIS A VIS DE LA LOCALISATION
– Rendre l'accès aux données transparentes sur tout le réseau (les liens de base de
données et les synonymes)
• INDEPENDANCE VIS A VIS DE LA FRAGMENTATION
– La fragmentation doit être réelle et respectée sur chaque site, indépendamment.
• INDEPENDANCE VIS A VIS DE LA REPLICATION
– Chaque site doit bien gérer ses réplications.

54
• TRAITEMENT DES REQUETES DISTRIBUEES
– Chaque site doit avoir des outils et stratégies d'optimisation.
• GESTION REPARTIE DES TRANSACTIONS
– Généralement les SGBD utilisent des protocoles de validation à 2 phases.
• UNE INDEPENDANCE VIS A VIS DU MATERIEL
– Le SGBD ne doit pas dépendre du matériel
• UNE INDEPENDANCE VIS A VIS DU SYSTEME D'EXPLOITATION
– Il est important que les SGBD utilisés soient utilisables sur plusieurs
systèmes d'Exploitation.
• UNE INDEPENDANCE VIS A VIS DU RES EAU
– L'idéal serait que chaque SGBD réparti ait son propre protocole réseau
comme Oracle, pour faire communiquer les différentes instances.
• UNE INDEPENDANCE VIS A VIS DU TYPE DE LA BASE DE DONNEES
RELATIONNELLE
– De plus en plus, il est possible d'interconnecter des SGBD de types
différents, au moyen des standards tels que ODBC, JDBC et des
middlewares fournis par les constructeurs eux-mêmes.

55
 Ref
• http://sys.bdpedia.fr/optim.html

56