Les requêtes

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.
2
• 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

3
4
 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.
 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)
 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.
• 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.
 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.
• 1-1 Règles de transformation de l’algèbre
relationnelle :
– 1. Commutativité des jointures :

– 2. Associativité des jointures:

– 3. Regroupement des sélections:

• Ces trois dernières règles sont utilisées pour descendre les

sélections, le plus bas possible dans l’arbre.
• 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.
• 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.
Plan d’exécution

14
 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)

15
 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.
• 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.
• 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.
 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.
 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

• 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

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

• 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.
Exemples
Choix de solution
 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
• 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
 Transparence des requêtes
• Schéma de fragmentation
– définition des fragments
• Schéma d'allocation
– contient la localisation
 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 ...
 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
 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
 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.
• 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
• 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
• 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
Cas favorable
Cas défavorable
 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
Cas de panne d’un participant
 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 » 44
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 »

45
46
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 »
 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.
• 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.