Chapitre1 : Les bases de données dans un

environnement distribué

1.Introduction
Une base de données centralisée est gérée par un seul SGBD et elle est stockée dans sa
totalité à un emplacement physique unique avec une seule et même unité de traitement. En
conséquence, la gestion de ces données avec le temps s’est confrontée à divers problèmes
tels que, l’augmentation de volume de données, de traitements et de transactions. Aussi, les
débits des liaisons réseaux évoluaient rapidement.
Dans ce contexte, l’idée de base de données repartie (BDR) est venue, le principe est de
multiplier les sources de données et les faire communiquer par réseaux, afin de bénéficier de
traitements parallèles, minimisant ainsi le temps de réponse.

2.Base de données repartie

Une base de données repartie est un ensemble de bases de données coopérantes, chacune
résidant sur un site différent, vu et manipulé par l’utilisateur comme une seule base de
données.

Exemple
Soit le Schéma global d’une base de données :
Produit (NoProd, DesProd, Prix, NoFour)
Fournisseur (NoFour, NomFour, VilleFour)
Client (NoCli, NomCli, VilleCli)
Représentants (NoRep, NomRep, VilleRep)
Commande (NoProd, NoCli, Date, Qte, NoRep)

Produit
Site1 Site2 Fournisseur

Réseau

Site3 Site4

Commande Commande
Client Client
Représentant Représentant

Figure 1 : schéma des données reparties

1
3.SGBD réparti
Un système qui gère une base de données répartie en fournissant un moyen d’accès rendant
la distribution transparente à l’utilisateur.
Ensemble de logiciels systèmes constitués des gérants de données répartis, des gérants de
communication et des SGBD locaux résidant sur chaque site de la base de données répartie.

Gérant de Gérant de
Gérant de données Gérant de
données Réseau
communication communication
reparties reparties

Site1 Site2

BD1 BD2
Figure 2 : SGBD réparti

4. Conception d’une base de données répartie

La définition du schéma de répartition est la partie la plus délicate de la phase de conception
d'une BDR car il n'existe pas de méthode miracle pour trouver la solution optimale.
L'administrateur doit donc prendre des décisions en fonction de critères techniques et
organisationnels avec pour objectif de minimiser le nombre de transferts entre sites, les temps
de transfert, le volume de données transférées, les temps moyens de traitement des requêtes, le
nombre de copies de fragments, etc...

4.1. Conception descendante (top down)

Cette méthode de conception est utilisée lors de la constitution de nouvelles bases de données.
On commence par définir un schéma conceptuel global de la base de données répartie, puis on
distribue sur les différents sites en des schémas conceptuels locaux. La répartition se fait donc
en deux étapes, en première étape la fragmentation, et en deuxième étape l’allocation de ces
fragments aux sites.

BD

BD1 BD2 BD3

Figure 3 : Conception descendante

2
Cette approche est généralement guidée par l’objectif de performances à obtenir par la mise à
proximité des données aux utilisateurs potentiels.

4.2. Conception ascendante (bottom up)

La conception ascendante permet l'intégration de bases de données locales existantes dans une
base distribuée. L’approche se base sur le fait que la répartition est déjà faite, mais il faut réussir
à intégrer les différentes bases de données existantes en une seule BD globale. En d’autres
termes, les schémas conceptuels locaux existent et il faut réussir à les unifier dans un schéma
conceptuel global.

BD

BD1 BD2 BD3

Figure 4 : conception ascendante

Cette démarche est la plus difficile puisqu'en plus des problèmes techniques identiques à ceux
inhérents à une conception descendante, il faudra résoudre également des problèmes
d’hétérogénéité des systèmes ou même sémantique des informations.
Donc, Les SGBD hétérogènes ont des fonctionnalités supplémentaires telles que la conversion
des données et des requêtes depuis un modèle vers un autre, ceci est réalisé par un sous-système
appelé traducteur. Il y a deux approches :

Approche naïve : il y a un traducteur pour chaque pair de modèle. Si on a n modèle, on aura

besoin de (n-1)*n/2 traducteurs différents.

Approche pivot : on utilise un modèle Pivot dans lequel chaque modèle est converti. Pour n
modèles, on a besoin de n traducteurs.

Modèle2
Modèle1

Modèle Pivot
Modèle3 Modèle4

Figure 5 : Modèle Pivot

Le modèle pivot est généralement relationnel à cause de sa simplicité et son haut niveau
d’indépendance. Le modèle pivot décrit le schéma conceptuel global et la base de données est
manipulée grâce au langage de ce modèle. La conversion (modèle pivot/modèle locale) se fait
au niveau du schéma externe locale.

4.Architecture générale d’un schéma de BD répartie

La répartition d'une base de données intervient généralement dans deux niveau, schéma global et
schémas locaux.

3
 Schéma externe Schéma externe Schéma externe
globale1 globale1 globale n

Schéma conceptuel globale

Schéma de placement

Site1 Site2
Site m

Schéma externe Schéma externe Schéma externe

locale1 locale2 locale m

Schéma conceptuel Schéma conceptuel Schéma conceptuel

locale1 locale2 locale m

Schéma interne Schéma interne Schéma interne

locale1 locale2 locale m

Figure 6 : Architecture générale d’un schéma de BD répartie

- Les schémas externes globaux : supportent les vues sur les sites d’utilisateurs particuliers.
- Le schéma conceptuel global : définit toutes les relations appartenant à la BD répartie.

- Le schéma de placement : précise la façon dont les relations sont placées sur les différents
sites du réseau. Il contient toutes les informations relatives à la localisation, la fragmentation
et la duplication des données. Selon l’exemple de la figure1 le schéma de placement est le
suivant :
Site2(Produit, Fournisseur)
Site3(Commande, Client, Représentant)
Site4(Commande, Client, Représentant)

- Les niveaux des schémas locaux : décrivent la BD locale. Il existe autant de schémas locaux
qu’il y a de sites dans le réseau.

- Le schéma local externe : représente les fragments tel qu’ils sont décrits dans le schéma de
placement. Il peut être considéré comme une vue de BD locale. Le schéma local externe assure
l’indépendance des SGBD, Il doit être présent dans le cas d’une BD répartie hétérogène. Il est
utile ainsi lorsque la BD répartie n’inclut qu’un sous ensemble de relations de la BD Locale.

5.Les Principales fonctionnalités d’un SGBD réparti

En plus des fonctions du SGBD local et gérant de communication, le SGBD réparti a d’autres fonctions:

- Gestion d’un dictionnaire de données global qui maintient l’information relative aux données
réparties.
- Définition et contrôle des données réparties.

4
 - Évaluation des requêtes réparties émises par les utilisateurs et invoquant la base de données
réparties.
- Gestion de transactions réparties.
- Contrôle de concurrence répartie
- Gestion des objets dupliqués (propagation des MAJ) (synchronisation).
- Transparence pour l’utilisateur
- Autonomie de chaque site
- Indépendance vis à vis du système d’exploitation, du réseau et du SGBD

6. Objectifs d’un SGBD réparti

6.1. Indépendance à la localisation
L’utilisateur ignore où se trouvent les données qu’il manipule. L’information concernant la localisation
se trouve dans le dictionnaire des données, consulté par le SGBD.

6.2. Fragmentation
Les relations peuvent être divisées en sous-relations stockées dans des sites différents. Afin
d’augmenter la performance de la base de données repartie en favorisant les accès locaux, et permet
l’équilibre de la charge entre sites.

Figure 7 : Exemple de fragmentation et d’allocation d’une relation dans une BD repartie

6.3. Duplication
Le principe est de dupliquer un fragment ou une relation sur différents sites en favorisant les accès
locaux. Ce qui permet d’augmenter la fiabilité et la disponibilité des données.

Commande2 Produit2
Site1 Site2 Fournisseur
Client2
Produit1

Réseau

Site3 Site4

Commande1
Client1
Produit1

Figure 8 : Exemple de duplication dans une base de données repartie

5
La duplication est très efficace lorsqu’un site tombe en panne. Cependant, il faut maintenir la
cohérence des copies multiples (le problème de mise à jour) : après une panne le site réparé doit
remettre à jour tous ses fragments. Par exemple après la panne du site2, il faut mettre à jour le
fragment Produit1 dupliqué dans le Site1 et le Site2.

Lorsque la duplication se fait sur des sites où les fragments sont le plus souvent utilisés, elle augmente
les performances. Mais ceci ne doit pas augmenter la complexité et le cout de maintenance des copies.

7. Dictionnaire des données

Il contient toute l’information concernant :
- la description des données globales
- le placement des données globales
- le contrôle sémantique des données.
Il est consulté pour traduire, analyser et évaluer les requêtes portant sur les bases de données
locales. Il existe trois approches d’organisation du dictionnaire :

Avantages Inconvénient
Centralisé : le dictionnaire est Maj des schémas simple et -Trop d’accès au site centrale
géré dans un seul site central. efficace
-la panne du site central
implique la panne de la BD.
Dupliqué : il existe une copie Évite les inconvénients de MAJ du dictionnaire doit être
du dictionnaire dans chaque l’approche centralisée répercutée dans tous les sites.
site.
Fragmenté : il est fragmenté Manipulation des données Manipulation des données
en dictionnaires locaux locales simple et efficace. distantes plus complexe
contenant les informations (nécessite la recherche du site
pertinentes aux données du où se trouve l’information du
site où il est stocké dictionnaire)

Figure 9 : Les trois approches d’organisation du dictionnaire de données

8. les Types de fragmentation

La fragmentation est le processus de décomposition d'une base de données en un ensemble de petites
bases de données dites base de données locales. Cette décomposition doit être sans perte
d'information (il existe une opération de reconstruction pour toute relation décomposée), de plus les
différents fragments doivent être de préférence exclusifs (pas de redondance). Il existe plusieurs types
de fragmentations :

8.1. Fragmentation par répartition des relations

Ce type de fragmentation consiste à distribuer les relations sur différents sites. La reconstruction du
schéma globale est basé sur la réunion de différents schémas locaux.

6
Exemple
En appliquant ce type de fragmentation sur un schéma global contenant deux relations Etudiant et
Groupe. On obtient les schémas locaux suivants :

Site1 : Fragment1= Etudiant

Site2 : Fragment2= Groupe
8.2. Fragmentation horizontale
La fragmentation horizontale est un découpage d'une table en sous-tables par utilisation de prédicats
permettant de sélectionner les lignes appartenant à chaque fragment. La relation initiale sera obtenue
par union des fragments :

- L'opérateur de partitionnement est la sélection (σ)

- L'opérateur de recomposition est l'union ()

Exemple
La relation Client(NoCli, NomCli, VilleCli) peut être fragmentée en deux fragment selon l’attribut
Ville :

Client1 : Select Client where Ville=’Oran’ (σ(Ville=’Oran’) Client )

Client2 : Select Client where Ville<>’Oran’ (σ(Ville<>’Oran’) Client)

Client
NoCli NomCli VilleCli
C1 Ali Oran
C2 Farida Alger
C3 Ahmed Mostaganem
C4 Karim Oran

Client1 Client2
NoCli NomCli VilleCli NoCli NomCli VilleCli
C1 Ali Oran C2 Farida Alger
C4 Karim Oran C3 Ahmed Mostaganem
Figure 10 : Exemple de fragmentation horizontale

La reconstruction de la relation Client est réalisée par : Clien1  Client2

8.3. Fragmentation Verticale

La fragmentation verticale est le découpage d'une table en sous-tables par des projections permettant
de sélectionner les colonnes qui composent chaque fragment. Afin de ne pas perdre d'informations,
la clé est dupliquée sur chaque fragment :

- L'opérateur de partitionnement est la projection 

- L'opérateur de recomposition est la jointure ⋈

Exemple
Soit la fragmentation de la relation Produit (NoPRo, DesPro, Prix, NoFour) en deux relations :

Produit1 : Select NoPRo, DesPro, Prix From Produit ((NoPro, DesPro, Prix) Produit)
Produit2 : Select NoPRo, NoFour From Produit ((NoPro, NoFour) Produit)

7
 Produit1
Produit NoPro DesPro Prix
NoPro DesPro Prix NoFour P1 Bureau 30000
P1 Bureau 30000 F2 P2 Chaise 9000
P2 Chaise 9000 F1 P3 Table 25000
P3 Table 25000 F3 P4 Armoire 42000
P4 Armoire 42000 F1 Produit2
NoPro NoFour
P1 F2
P2 F1
P3 F3
P4 F1

Figure 11 : Exemple de fragmentation verticale

La reconstruction de la relation Produit est réalisée par : Produit1 ⋈ Produit2

8.4. Fragmentation mixte

La fragmentation mixte est la combinaison des deux fragmentations, horizontale et verticale sur une
relation globale. Les lignes et les colonnes peuvent donc être repartis dans des partitions différentes:

- L'opération de partitionnement est une combinaison de projections et de sélection.

- L'opération de recomposition est une combinaison de jointures et d'unions.

Exemple
Soit la fragmentation de la relation précédente Produit en quatre relations :

Produit1
NoPro DesPro Prix
P2 Chaise 9000
P3 Table 25000

NoPro DesPro Prix NoFour Produit2

Produit P2 Chaise 9000 F1 NoPro NoFour
NoPro DesPro Prix NoFour P3 Table 25000 F3 P2 F1
P1 Bureau 30000 F2 P3 F3
P2 Chaise 9000 F1
P3 Table 25000 F3 Produit3
P4 Armoire 42000 F1 NoPro DesPro Prix
NoPro DesPro Prix NoFour P1 Bureau 30000
P1 Bureau 30000 F2 P4 Armoire 42000
P4 Armoire 42000 F1
Produit4
NoPro NoFour
P1 F2
P4 F1
Figure 12 : Exemple de fragmentation mixte

8
Produit 1 : Select NoPRo, DesPro, Prix From Produit where Prix<=25000
((NoPro, DesPro, Prix) (σ(Prix<=25000) Produit))
Produit 2 : Select NoPRo, NoFour From Produit where Prix<=25000
((NoPro, NoFour) (σ(Prix<=25000) Produit))

Produit 3 : Select NoPRo, DesPro, Prix From Produit where Prix>25000

((NoPro, DesPro, Prix) (σ(Prix>25000) Produit))

Produit 4 : Select NoPRo, NoFour From Produit where Prix>25000

((NoPro, NoFour) (σ(Prix>25000) Produit))

La reconstruction de la relation Produit est réalisée par:(Produit1 ⋈ Produit2)(Produi3 ⋈ Produit4)

8.5. Fragmentation horizontale dérivée

La fragmentation horizontale dérivée consiste à utiliser les fragments d’une table pour la
fragmentation d’une autre table, dont les fragments sont définis par une semi jointure.

Exemple
On peut fragmenter la table Commande par la jointure avec les deux fragments Client1 et Client2
(exemple de la fragmentation horizontale). On obtient alors deux tables Commande, la première est
relative aux clients Oranais, et la deuxième est relative aux clients non oranais.
Commande1 : Commande ⋈ Client1
Commande2 : Commande ⋈ Client2

Commande1
Commande
NoPro NoCli Date Qte
NoPro NoCli Date Qte P4 C1 20/06/2020 2
P1 C3 12/09/2020 6
P4 C1 20/06/2020 2
P2 C3 12/09/2020 6
P3 C2 10/03/2020 10 Commande2
NoPro NoCli Date Qte
P1 C3 12/09/2020 6
P2 C3 12/09/2020 6
P3 C2 10/03/2020 10
Figure 13 : exemple de fragmentation horizontale dérivée

La reconstruction de la relation Commande est réalisée par : Commande1  Commande2

9. Définition des fragments

Le choix de la fragmentation d’une relation est un problème très difficile car il dépend des besoins
d’accès des applications. Le principe général est de baser la fragmentation sur l’ensemble des requêtes
d’interrogation et de mise à jour. Pour cela, il faut extraire de ces requêtes toutes les conditions de
sélections, les attributs projetés et les jointures.

Les opérations de sélection sont à la base des fragmentations horizontales, les opérations de
projection sont à la base des fragmentations verticales et les jointures sont à la base des
fragmentations dérivées.

9
Pour éviter le risque d'émietter la base de données, on peut restreindre le nombre de requêtes prises
en considération. On ne s'intéresse alors qu'aux requêtes les plus fréquentes ou les plus sensibles
(celles pour lesquelles le temps de réponse maximum est borné).

9.1. Définition des fragments horizontaux d’une relation

Soient C1, C2 ….Cn les conditions extraites des requêtes prédéfinies. On définit l ’ensemble des 2n
conjonctions de conditions :

CC ={ ⋀𝑖=1,𝑛 𝐶𝑖∗ où Ci* est soit Ci soit ¬ Ci }

On supprime de cet ensemble les conditions qui sont toujours fausses et on simplifie les autres.
Les conjonctions de condition qui restent déterminent les fragments.

Exemple
On peut fragmenter la relation Compte (NoClient, Agence, TypeCompte, Somme) en se basant sur les
requêtes suivantes :

R1 = (NoClient, Agence) (σ(TypeCompte = 'courant' ∧ Somme > 100 000) Compte)

R2 = σ(Agence = 'Oran') Compte

R3 = π(NoClient, Somme) (σ(Agence = 'Alger' ∧ TypeCompte = 'courant') Compte)

Les conditions extraites :

C1 =TypeCompte = 'courant' ∧ Somme > 100 000

C2 = Agence = 'Oran'

C3 = Agence = 'Alger' ∧ TypeCompte = 'courant'

Donc l’ensemble CC = {C1 C2  C3, ¬C1 C2  C3, C1 ¬C2  C3, C1 C2  ¬C3, ¬C1 ¬C2  C3, ¬C1 C2 
¬C3, C1 ¬C2  ¬C3, ¬C1 ¬C2  ¬C3}

Certaines conjonctions de CC sont fausses et d’autres peuvent être réduites en déterminant les
fragments.

9.2. Définition des fragments verticaux d’une relation

Les fragments verticaux sont exclusifs, sauf en ce qui concerne le (ou les) attribut(s) de jointure qui
sont communs à tous les fragments, et ce pour que la décomposition soit sans perte d'information.
Le principe est le suivant :

1. Extraire toutes les expressions Pj de projections concernées par les requêtes

2. Ajouter à chacune d'elles la clé si elle ne les possède pas.
3. Générer le complément de chaque expression (c'est à dire les autres attributs) en ajoutant la
clé.
4. Produire l’ensemble IP des 2n intersections de projections :
IP = {⋀𝑗=1,𝑛 𝑃𝑗∗ où Pj* est soit Pj soit 𝑃
̅𝑗 }
Chaque IPi définit un fragment.

Dans le cas où la relation à fragmenter est un fragment horizontal (Fragmentation mixte), il faut
rechercher à partir des conditions de ce fragment toutes les requêtes concernées et prendre en
considération que les expressions de projection de ces requêtes.

10
Exemple
En se basant sur les mêmes requêtes précédentes pour fragmenter la relation Compte, on obtient :

(1) et (2) Les projections extraites en ajoutant la clé (si elle ne figure pas) :
P1 = NoClient, Agence
P2 = NoClient, Agence, TypeCompte, Somme
P3 = NoClient, Somme

(3) le complément de chaque expression :

̅̅̅
𝑃1 = NoClient, TypeCompte, Somme
̅̅̅
𝑃2 = Ø
̅̅̅
𝑃3 = NoClient, Agence, TypeCompte

(4) On ne prend pas en considération les projections avec un ensemble vide, donc :
IP= {P1P3, ̅̅̅
𝑃1  P3, P1 ̅̅̅ 𝑃1  ̅̅̅
𝑃3 , ̅̅̅ 𝑃3 }

10. Evaluation de requête répartie

Dans les bases de données réparties, une requête passe par quatre étapes pour être traitée :

Décomposition

Schéma de
Requêtes portant sur placement
Des relations du schéma global

Localisation Choisir les copies des

fragments à accéder

Requêtes sur les fragments

Algorithme
Optimisation
d’accès repartis

Exécution

Figure 14 : Evaluation d’une requête dans une base de données repartie

10.1. La décomposition
La décomposition de la requête est traitée de la même façon que dans un système centralisé.
Également, la requête globale est décomposée en sous-requêtes.

Exemple
Soit la Base de données globale :
Produit (np, désignation, pu, nf)
Client ( ncl, nomC, ville)
Commande (np, ncl, date, qte)

11
Fournisseur (nf, nomF, ville, statut)
Et Soit la requête globale suivante : Quels sont les numéros et les désignations des produits
commandés par des Oranais avec une quantité supérieure à 100.

np, désignation np, désignation

ncl
Ville= ‘Oran’

np, désignation, ncl ncl

Qte>100

Ville= ‘Oran’

np
ncl Client

Client np, ncl

np, désignation
np
Qte>100

Produit Commande

Produit Commande

Figure 15 : Exemple de décomposition d’une requête repartie

10.2. La localisation
Les informations nécessaires à la localisation et à la fragmentation sont stockées dans le schéma de
placement (dictionnaire). La localisation d’une requête passe par 2 étapes :

1. Génération d‘une requête canonique équivalente :

La requête canonique exprimée sur les fragments est obtenue en remplaçant chaque relation de la
requête répartie par la requête de reconstruction (opération relationnelle qui spécifie la règle de
reconstruction d’une relation à partir de ses fragments).
Exemple
Considérons la requête de l’exemple précèdent, et supposant que les relations sont fragmentées de
la façon suivante :
Client1 : σ ville = ‘Oran’ (Client)
Client2 : σ ville <> ‘Oran’ (Client)
Commande1 : semi-join Commande with Client1 over ncl
Commande2 : semi-join Commande with Client2 over ncl
Produit1 : πnp, désignation, Pu (Produit )
Produit2 : πnp, nf (Produit )

12
 np, désignation

ncl

Requête globale
ncl

np

Ville= ‘Oran’

np, désignation
np, ncl

Qte>100


np

Requête de reconstruction
Client1 Client2
Produit1 Produit2

Commande1 Commande1

Figure 16 : Exemple d’une requête repartie exprimée sur les fragments

2. Simplification
La simplification d’une requête canonique consiste à restructurer les sous arbres syntaxiques afin de
rapprocher les opérateurs unaires aux fragments puis à appliquer les règles de simplification. Cette
étape permet de déterminer les opérations inutiles dans une requête canonique. Sachant que les
opérations inutiles sont celles qui produisent un résultat vide, ou identique à l’opérande. Parmi ces
règles :
Règle 1 : une sélection sur un fragment horizontal dont le prédicat est contraire au prédicat de
fragmentation donne un résulta vide → (suppression de la branche).

Règle 2 : une sélection sur un fragment horizontal dont le prédicat est le même que celui de la
fragmentation donne un résultat identique → (suppression de la sélection)

Règle 3 : la projection sur des attributs n’appartenant pas au fragment vertical (sauf attribut de
reconstruction) donne un résultat vide → (suppression de la branche).

Exemple
- En rapproche les opérateurs unaires, on obtient :

13
 np, désignation

ncl

ncl

np


Règle 1
Règle 2
np, désignation
np, ncl Ville= ‘Oran’ Ville= ‘Oran’

Client2
 Client1
Règle 3
np Qte>100
Qte>100
np, désignation np
Commande1 Commande2
Produit1 Produit2

Figure 17 : Exemple de simplification d’une requête repartie

- On applique les règles de simplification et on obtient l’arbre final :

np, désignation

ncl

ncl
np

np, ncl
np, désignation


Qte>100 Qte>100
Client1
Produit1 Commande1 Commande2

Figure 18 : requête repartie après décomposition et localisation

10.3. Optimisation
Après avoir généré un arbre de requête et traduire les sous-arbres en opérations, la stratégie adoptée
pour l'exécution est ascendante. On part donc des feuilles, en exécutant les opérations unaires de
restriction et projection le plus tôt possible car elles réduisent respectivement le degré et la cardinalité
d’une relation. Ensuite, remonter au niveau supérieur (prétraitement et jointure des relations) et
prendre une décision sur le site d'affectation de l'opérateur. Et ainsi de suite pour les niveaux
supérieurs jusqu'à la racine.

14
Exemple
Supposant que la requête a été émise au site1 (Site globale), et que les fragments sont placés dans les
sites suivants :
Site1 : Fournisseur, Produit1
Site2 : Client2, Produit2, Commande1
Site3 : Commande2, Clien1
O9

O8

O6
O7

O5
Client1
O1 O4 Site3

Produit1 O2 O3
Site1

Commande1 Commande2
Site2 Site3

Figure 19 : Exemple d’optimisation d’une requête repartie

Le rôle de cette étape d’optimisation est de déterminer une stratégie d’exécution de la requête qui :
- Minimise une fonction de coût (temps de traitement et le temps de transfert des données
entre les différents sites).
- Prend en considération les traitements exécutés en parallèles.

La requête obtenue après localisation peut être exécutée par une stratégie simple selon l’algorithme
suivant :
1) Opérateur unaire (α) : Exécuter les opérations unaires sur des fragments comme des
requêtes locales et transférer ensuite les résultats vers un site unique (généralement le
site où a été adressée la requête globale) : site(α) = site de l’opérande.
2) Opérateur binaire (op1 β op2) : lorsque tous les opérandes d'une même opération
algébrique sont situés sur le même site, la solution la moins coûteuse pour exécuter cette
opération est le plus souvent de l'exécuter sur ce site. Si non l’opération est exécutée sur
le site demandeur (globale) :

Site(β) = Si site(op1) = site(op2) alors site(op1)

Sinon site global (le site d’où a été envoyée la requête)

Plusieurs plans d’exécution peuvent être générés, l’optimiseur choisit alors le moins coûteux en
fonction du temps de traitement et de transfert des données.

En appliquant cette stratégie d’optimisation, on obtient le plan d’exécution suivant :

T1 : exécuter O1→ site1

T2 : exécuter O2→ site2
T3 : exécuter O3→ site3
T4 : envoyer T2 → site1

15
T5 : envoyer T3 → site1
T6 : exécuter O4 → site1
T7 : exécuter O5 → site1
T8 : exécuter O6 → site1
T9 : exécuter O7 → site3
T10 : envoyer T9 → site1
T11 : exécuter O8 → site1
T12 : exécuter O9 → site1

16