6. Les systèmes de bases de données post-relationnelles
185
bases de données locaux selon le mécanisme suivant : dans la
première phase, toutes les tâches participantes signalent au
programme de coordination que leurs transactions locales sont
terminées. Le programme de coordination leur répond en envoyant un
«PREPARE FOR COMMIT» pour préparer la conclusion normale de la
transaction. Suite à cette invitation, tous les programmes participants
appliquent les mises à jour définitives aux bases de données locales.
Chaque participant communique le résultat de cette opération au
programme de coordination centrale en émettant un «OK» ou «NOT
OK». Dans la deuxième phase, le programme de coordination envoie
un «COMMIT» s'il a reçu des «OK» de tous les participants. En
revanche, si au moins un des participants a signalé l'échec de
l'opération par un «NOT OK» dans la phase 1, le programme de
coordination émet un «NOT OK» dans la phase 2. Dans ce cas, les
participants ayant terminé avec succès leur mise à jour auparavant
doivent maintenant défaire leurs transactions. Le protocole de
validation en deux phases présente l'avantage suivant : soit toutes les
tâches participantes se terminent avec succès et la base de données est
mise à jour correctement, soit aucune modification n'est intervenue
dans la base de données en cas d'échec.
Traitement optimal
des requêtes
réparties
La stratégie de traitement interne des requêtes de bases de
données réparties joue un rôle important. Considérons l'exemple dans
la figure 6-2 où nous désirons extraire une liste des noms d'employés
et des descriptions de leurs départements. La requête d'interrogation
est une commande SQL sous sa forme usuelle sans aucune référence
aux fragments. Il incombe au système de bases de données de définir
maintenant sa stratégie d'exécution optimale de notre requête
décentralisée. Les tables EMPLOYÉ et DÉPARTEMENT sont toutes
deux partitionnées en fragments stockés à Bulle et à Genève. C'est
pourquoi certaines opérations doivent s'exécuter localement et en
parallèle. Chaque site opère de manière autonome la jointure d'un
fragment de la table EMPLOYÉ et d'un fragment de la table
DÉPARTEMENT. À la fin des opérations locales, l'union des résultats
partiels produit la liste désirée.
Un exemple de
requête répartie
Pour optimiser l'arbre d'interrogation, chaque site effectue
d'abord des projections sur les attributs Nom et Description, qui
185
bases de données locaux selon le mécanisme suivant : dans la
première phase, toutes les tâches participantes signalent au
programme de coordination que leurs transactions locales sont
terminées. Le programme de coordination leur répond en envoyant un
«PREPARE FOR COMMIT» pour préparer la conclusion normale de la
transaction. Suite à cette invitation, tous les programmes participants
appliquent les mises à jour définitives aux bases de données locales.
Chaque participant communique le résultat de cette opération au
programme de coordination centrale en émettant un «OK» ou «NOT
OK». Dans la deuxième phase, le programme de coordination envoie
un «COMMIT» s'il a reçu des «OK» de tous les participants. En
revanche, si au moins un des participants a signalé l'échec de
l'opération par un «NOT OK» dans la phase 1, le programme de
coordination émet un «NOT OK» dans la phase 2. Dans ce cas, les
participants ayant terminé avec succès leur mise à jour auparavant
doivent maintenant défaire leurs transactions. Le protocole de
validation en deux phases présente l'avantage suivant : soit toutes les
tâches participantes se terminent avec succès et la base de données est
mise à jour correctement, soit aucune modification n'est intervenue
dans la base de données en cas d'échec.
Traitement optimal
des requêtes
réparties
La stratégie de traitement interne des requêtes de bases de
données réparties joue un rôle important. Considérons l'exemple dans
la figure 6-2 où nous désirons extraire une liste des noms d'employés
et des descriptions de leurs départements. La requête d'interrogation
est une commande SQL sous sa forme usuelle sans aucune référence
aux fragments. Il incombe au système de bases de données de définir
maintenant sa stratégie d'exécution optimale de notre requête
décentralisée. Les tables EMPLOYÉ et DÉPARTEMENT sont toutes
deux partitionnées en fragments stockés à Bulle et à Genève. C'est
pourquoi certaines opérations doivent s'exécuter localement et en
parallèle. Chaque site opère de manière autonome la jointure d'un
fragment de la table EMPLOYÉ et d'un fragment de la table
DÉPARTEMENT. À la fin des opérations locales, l'union des résultats
partiels produit la liste désirée.
Un exemple de
requête répartie
Pour optimiser l'arbre d'interrogation, chaque site effectue
d'abord des projections sur les attributs Nom et Description, qui