Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (TFE)

a
UNIVERSITE DE KINSHASA
Faculté des Sciences
Département de Mathématiques et Informatique
B.P. : 190 Kinshasa XI
Par
KAYEMBA KAVUALLA Sagesse
Travail réalisé et défendu en vue d’obtention
du titre de licencié en science
Groupe : Informatique
Option : Génie-Informatique
Sous la direction de :
MBUYI MUKENDI Eugène
Professeur Ordinaire
Année académique 2010-2011
Etude des Transactions Concurrentes
Dans une Base de Données Répartie
Application à l’Intranet Gouvernemental de la RDC
D
u
S
o
f
t
w
a
r
e
a
u
S
a
a
S
*
*
S
o
f
t
w
D

b
UNIVERSITE DE KINSHASA
Faculté des Sciences
Département de Mathématiques et Informatique
B.P. : 190 Kinshasa XI
Etude des Transactions Concurrentes
Dans une Base de Données Répartie
Application à l’Intranet Gouvernemental de la RDC
Par
Travail réalisé et défendu en vue d’obtention
du titre de licencié en science
Groupe : Informatique
Option : Génie-Informatique
Sous la direction de :
MBUYI MUKENDI Eugène
Professeur Ordinaire
Année académique 2010-2011

i
Table de Matières
EPIGRAPHE .................................................................................................................................IV
DEDICACE................................................................................................................................... V
REMERCIEMENTS .........................................................................................................................VI
LISTE DES ABREVIATIONS .............................................................................................................VIII
LISTE DES FIGURES ........................................................................................................................X
LISTE DES TABLEAUX....................................................................................................................XII
INTRODUCTION GENERALE.............................................................................................................1
CHAPITRE I .................................................................................................................................6
LES SYSTEMES DISTRIBUES.............................................................................................................7
I. 1. Les Systèmes Distribués...............................................................................................7
I.1.1. Définitions ..............................................................................................................8
I.1.2. Caractéristiques et Objectifs..................................................................................8
I.1.3. Système Centralisé VS Système Distribué..............................................................9
I.1.4. Propriété d’un Système Distribué ........................................................................11
I.1.5. Architecture d’un Système Distribué ...................................................................14
I.2. Les Bases de Données Réparties (Distribuées) ...........................................................17
I.2.1. Définitions ............................................................................................................17
I.2.2. Buts et motivations pour une Base de Données Distribuée : BDD ......................19
I.2.3. Avantages et Contraintes.....................................................................................20
I.2.4. La Répartition de données (Les Niveaux).............................................................20
I.2.5. Principe d’une Base de Données Réparties ou Distribuée...................................21
I.2.6. Systèmes de Gestion de Base de Données Distribuée (SGBDD) et Architectures22
I.3. La Réplication..............................................................................................................24
I.3.1. Les protocoles de contrôle de réplication............................................................24
I.3.2. Architectures de Réplications ..............................................................................26
I.4. Fragmentation, Allocation et Conception...................................................................29
I.4.2. Allocation..............................................................................................................32
I.4.3. Conception ...........................................................................................................34
CHAPITRE II ..............................................................................................................................36
LES TRANSACTIONS DISTRIBUEES..................................................................................................36
II.1. DEFINITIONS D’UNE TRANSACTION...........................................................................36
II.2. CLASSIFICATION DES TRANSACTIONS........................................................................40
II.2.1. Suivant la nature de différentes opérations .......................................................40
II.2.2. Suivant la durée...................................................................................................41
II.3. MODELES DE TRANSACTIONS ...................................................................................41
II.3.1. Les Transactions Plates (Flat Transactions) :.......................................................41

ii
II.3.2. Les Transactions plates avec Points de Sauvegarde (SAVEPOINTS) :..................41
II.3.3. Les Transactions Chainées (Chained Transactions) :...........................................42
II.3.4. Les Transactions Imbriquées ou Emboitées (Nested Transactions) ...................42
II.3.5. Transactions Compensatrices .............................................................................45
II.3.6. Les Transactions Longues....................................................................................46
II.3.7. Les transactions Distribuées................................................................................46
II.4. LA JOURNALISATION ET LA REPRISE DES TRANSACTIONS.........................................47
II.4.1. Journalisation ......................................................................................................47
II.4.2. Reprise.................................................................................................................50
II.5. TRANSACTION DISTRIBUEE ET LE MODELE OSI .........................................................51
II.5.1. Le Système Transactionnel..................................................................................51
II.5.2. Le Modèle OSI pour les Transactions Distribuées...............................................53
II.6. GESTION ET CONTROLE DE CONCURRENCE DE TRANSACTIONS (REPARTIE)............57
II.6.1. La cohérence de données....................................................................................58
II.6.2. Concurrence d’accès de données........................................................................65
CHAPITRE III .............................................................................................................................79
LES APPLICATIONS ......................................................................................................................79
III.1. Mécanisme de Répartition sous SQL SERVER...........................................................79
III.1.1. SQL SERVER ........................................................................................................79
III.1.2. Les Bases de Données ........................................................................................79
III.1.3. Services et moteurs............................................................................................80
III.1.3.1. SQL Server ..........................................................................................................80
III.1.3.2. SQL Server Agent ...............................................................................................81
III.1.4. Transactions ......................................................................................................81
III.1.5. Notion de répartition sous SQL SERVER.............................................................82
III.2. Gestion de Transactions par la programmation sous .NET (Framework 3.5)...........85
III.2.1. Les Transactions locales ....................................................................................85
III.2.2. Les Niveaux d’Isolations .....................................................................................87
III.2.3. Les Transactions Distribuées..............................................................................89
III.3. Intranet Gouvernemental de la RDC (République Démocratique du Congo) ..........91
III.3.1. Quelques définitions ..........................................................................................91
III.3.2. Objectif du projet ...............................................................................................92
III.3.3. Avantages pour les utilisateurs ..........................................................................92
III.3.4. Situation actuelle de l’Intranet...........................................................................93
III.4. Mise en place d’un Système d’Information de Traitement de Salaire des Agents de
l’Etat..................................................................................................................................95
III.4.1. Circonscription ...................................................................................................95
III.4.2. Modélisation du Système d’Information avec l’UML.........................................96
III.4.2.1. Spécification Initiale du Système.................................................................96
III.4.2.2. Enoncé du problème ...................................................................................97
III.4.2.3. Analyse du Domaine....................................................................................98

iii
III.4.2.3.1. Diagramme de Cas d’Utilisation ...............................................................98
III.4.2.3.2. Diagramme de Classe .............................................................................100
III.4.2.3.2. Diagramme d’état...................................................................................102
III. 4.2.3.3. Diagrammes d’Activités.........................................................................103
III.4.2.4. Conception et Implémentation du Système .............................................105
III.4.2.4.1. Schéma Global........................................................................................105
III.4.2.4.2. Fragmentations et Allocations ...............................................................106
III.4.2.4.3. Réplication..............................................................................................107
III.4.2.4.4. Implémentations de l’Application ..........................................................108
CONCLUSION...........................................................................................................................138
REFERENCE.............................................................................................................................140

iv
Epigraphe
… Un Système de Bases de Données Réparties est
suffisamment complet pour décharger les utilisateurs de
tous les problèmes de concurrence, fiabilité, optimisation
de requêtes ou transactions sur des données gérées par
différents SGBDs sur plusieurs sites. [15]

v
Dédicace
A ma très chère Mère, Denise NTUMBA ;
A mon très cher Père, Denis-Robert KAYEMBA ;
Qui, des manières constantes, ont accolé leurs sacrifices pour parfaire l’œuvre que je
suis. Qu’ils en soient remerciés et trouvent par ici la gratitude de mon cœur sincère ;
A tous les miens : parents, amis et connaissance ;
Que je ne peux énumérer
Je dédie ce travail.

vi
Remerciements
A celui qui garde l’âme et protège le corps ; le Tout-Puissant Dieu qui renouvelle
les forces, nous transmettons nos tout premiers remerciements ; car après nous avoir
gardés tout au long de notre deuxième cycle en force et bonne santé, a bien voulu que
nous l’achevions avec ce présent travail qui le couronne. Merci Seigneur Jésus Christ.
S’il s’est avéré possible de réaliser ce présent travail, c’est grâce au Prof. Eugène
MBUYI MUKENDI qui nous a accepté sous sa direction et son Assistant Hercule KALONJI
KALALA qui l’a poursuivi jusqu’à sa perfection ; qu’ils trouvent à travers ces lignes
l’expression de notre profonde gratitude et de notre respect.
Nos remerciements s’adressent enfin à tout celui qui, d’une manière ou d’une autre, a
participé à la victoire de cette bataille. En voici quelques uns : Jérémie PANGU NKOYI, Théo
MASAMBOMBO MBIYA, etc.

viii
Liste des Abréviations
.NET : DotNET
2-PC : Protocole de Validation en Deux Phases
3-PC : Protocole de Validation en Trois Phases
ACID : Atomicity, Consistency, Isolation et Durability,
ACSE : Association Control Service Element
ADO : Activex Data Object
APD : Aide Public au Développement
API: Application Programming Interface
BD : Base de Données
BDD : Base de Données Distribuée
BDR : Base de Données Répartie
C# : CSharp
C/S : Client-Serveur
CCR: Committment, Concurrency and Recovery
CORBA: Common Object Request Broker Architecture
CPU : Central Processing Unit
DTC : Distributed Transaction Coordinator
DTP: Distributed TP
ISO : International Standard Organisation
JDBC : Java DataBase Connectivity
JTS : Java Transaction Service
KOICA: Korea Intrnational Cooperation Agency
LDF: Log Database File
MACF : Multiple Association Control Function
MDF: Main Database File
MS DTC : Microsoft Distributed Transaction Coordinator
MTS : Microsoft Transaction Server
NDF : Next Database File
NU : Nouvelle Unité
ODBC : Open DataBase Connectivity
OLAP : On-line Analytical Processing
OLTP: On-line Transactional Processing
OSI : Open Système Interconnection
P2P : Peer-to-Peer ou Pair-à-Pair
RDC : République Démocratique du Congo
RMI: Remote Method Invocation
SAO : Single Association Objects
SBDD : Système de Bases de Données Distribuées
SGBD : Système de Gestion de Base de Données
SGBDD : Système de Gestion de Base de Données Distribué
SGBDR : Système de Gestion de Base de Données Réparti
SOAP: Simple Object Access Protocol

ix
SQL : Structured Query Language
TP: Transactions Processing
TPPM : TP Protocol
TPSU: TP Service User
TPSUI : TPSU Invocation
UML : Unified Modeling Language
VE : Vue Externe.
WW : WOUND-WAIT
XML-RPC: Extensible Markup Language-Remote Procedure Call

x
Liste des Figures
Figure 1 : De Centralisé vers Distribué [9]................................................................................10
Figure 2: système distribué avec un middleware [1] [51]........................................................14
Figure 3 : Client-Serveur...........................................................................................................15
Figure 4 : Architecture d’une base de données [41]................................................................18
Figure 5 : Architecture d’une BDD............................................................................................21
Figure 6 : réplication synchrone...............................................................................................24
Figure 7 : réplication asynchrone.............................................................................................25
Figure 8 : une transaction dans une base de données cohérente..........................................36
Figure 9 : Transaction plates avec SAVEPOINTS [22] ...............................................................42
Figure 10 : Arbre de Transactions et sous-Transactions .........................................................43
Figure 11 : Validation et Abandon de Sous-Transactions .......................................................45
Figure 12 : Transactions compensatrices ................................................................................46
Figure 13 : L’UNDO d’une mise-à-jour [30].............................................................................48
Figure 14 : Le REDO d’une mise-à-jour [30]............................................................................49
Figure 15 : Architecture du système transactionnel [31].........................................................51
Figure 16 : Architecture Transactionnelle [46] ........................................................................53
Figure 17 : Modèle de Dialogue dans OSI TP ...........................................................................54
Figure 18 : Arbre de Transactions ............................................................................................55
Figure 19 : Les actions du Protocole de Validation en Deux Phases [32] ................................60
Figure 20 : Validation normale [15] [22] [40]...........................................................................61
Figure 21 : Panne d’un participant avant d’être prêt [15] [22] [40] ........................................62
Figure 22 : Panne d’un participant après s’être déclaré prêt [15] [22] [40]............................62
Figure 23 : Panne du coordinateur [15] [40]............................................................................63
Figure 24 : TIME-OUT et panne dans le protocole de validation en trois phases [32]............64
Figure 25 : Exécution non contrôlée des transactions concurrentes ......................................65
Figure 26 : Perte d’opérations..................................................................................................66
Figure 27 : Ecriture inconsistante.............................................................................................67
Figure 28 : Lecture sale ............................................................................................................68
Figure 29 : Lecture non-reproductible .....................................................................................69
Figure 30 : Le Principe du Verrouillage à deux phases [31] .....................................................72
Figure 31 : Le Verrou Mortel (DeadLock) [42]..........................................................................74
Figure 32 : Cycle dans le Graphe des Attentes.........................................................................75
Figure 33 : Réplication peer-to-peer avec trios et quatre nœuds [19]....................................83
Figure 34 : Vue de l’architecture de la Réplication transaction [19] .......................................83
Figure 35 : Interface de Démarrage du Service de DTC ...........................................................89
Figure 36 : l’Intranet Gouvernemental [35].............................................................................94
Figure 37 : Diagramme de Cas d’Utilisation.............................................................................99

xi
Figure 38 : Diagramme de Classe ...........................................................................................101
Figure 39 : Diagramme d’état de la classe Agent...................................................................102
Figure 40 : Diagramme d’Activité pour l’immatriculation d’un agent...................................103
Figure 41 : Diagramme d’Activité pour le calcul et la paie des Agents immatriculés............104
Figure 42 : Diagramme de classe avec toutes les propriétés et les classes association........105

xii
Liste des Tableaux
Tableau 1: Avantages et Désavantages de la combinaison de stratégie .................................28
Tableau 2: Compatibilité des Verrous (modes)........................................................................71
Tableau 3 : Compatibilité des Verrous (Opérations)................................................................71
Tableau 4 : Projets Réseaux Gouvernemental par KOICA [35] ................................................93
Tableau 5 : Tableau de correspondance de numéro de sites et leurs noms ...........................95
Tableau 6 : Fragmentations et allocations aux sites..............................................................106

xiii
[Introduction Générale]

1
Introduction Générale
Actuellement les besoins d’entreprises et leurs solutions doivent tabler sur
l’infrastructure qui leur est offerte, à savoir les réseaux informatiques de communication, et
aussi pour en profiter de ses avantages, surtout qu’en plus cette infrastructure
correspondrait le mieux possible à l’architecture des entreprises.
Le système d’Information aussi, qui est un apanage pour une entreprise, s’est étendu
sur cette infrastructure en sous systèmes, et par conséquent doit faire collaborer ces
derniers de manière à leur permettre soit de sous-traiter un sous système chez un autre, soit
à permettre plusieurs sous systèmes de pouvoir participer à la réalisation d’un résultat. Ce
type de systèmes s’appelle et sont dits « distribué ou réparti».
Et cette notion de système distribué même, dont la définition est la suivante, une
collection de processus informatiques indépendants qui communiquent mutuellement par
passage de message [27], s’articule sur un seul problème à savoir, la cohérence de données
qui doit être assurée de manière la plus transparente aux utilisateurs.
Dans les Bases de Données Distribuée, comme dans tout autre système distribué, y est
utilisé le concept de la transaction, qui est aussi une voie vers la gestion de la cohérence de
données, vu qu’une transaction a cette propriété d’atomicité qui lui permet d’être défaite ou
validée d’un seul coup lorsque l’ensemble d’opérations qu’elle encapsule ont échoué ou
réussi, afin de laisser les données si pas dans un état de cohérence précédent, mais de les
faire passer dans un autre état de cohérence.
La concurrence aussi, il faut le signaler, même si elle fait partir des objectifs pour
lesquels on construirait un système distribué, reste aussi une cause d’incohérence de
données dans ce dernier. De fait, elle nécessite une bonne gestion ; pour aussi garantir la
cohérence ; le concept de transaction le fait aussi bien, de par sa propriété d’Isolation. D’où,
on parle des transactions concurrentes, ce qui est même l’objet principal de ce présent
travail.
Pour mener à bonne fin notre travail qui s’articule sur l’Intranet Gouvernemental (e-
Gouvernement), nous y avons ciblé un problème très récurrent que nous formulons de la
manière suivante, Mise en place d’un Système d’Information (Automatisé) de Traitement
de Salaire des Agents de l’Etat.

2
Pour que l’Etat ou le Gouvernement salarie un agent, ce dernier doit de prime abord
être immatriculé. Sachant que c’est chaque institution de l’Etat ou l’entreprise elle-même
qui gère ses employé (ses ressources humaines), c'est-à-dire elle organise le
recrutement, mais pour la prise des fonctions, c’est la fonction publique qui attribue les
matricules. Or ces opérations, manuelles soient-elle et faisant intervenir deux sites distants,
exigent souvent beaucoup de déplacements pour acheminer les dossiers et passer toutes les
étapes pour aboutir à un agent immatriculé. Chose qui fait perdre terriblement du temps.
Après immatriculation des agents, la Fonction Publique, qui est l’entité habilitée à
gérer la ressource humaine de l’Etat, est censée connaitre l’effectif de tous les agents de
l’Etat. Or, étant donné que le processus d’immatriculation prend assez de temps, et qu’en
plus puisque c’est manuel, il peut favoriser de cas des agents fictifs ; cette tache peut donc
devenir un peu pénible et erroné.
Venons-en maintenant au problème de salaire ; si l’immatriculation dure aussi
longtemps, on risque d’avoir une situation telle que, un agent en attente de son matricule
peut commencer déjà à travailler au sein de l’entreprise mais sans salaire de la part de l’Etat.
Et aussi si savoir l’effectif des agents est aussi un problème et favorise la présence des
agents fictifs, c’est l’Etat qui va perdre. De fait, le Ministère de la Finance, l’Entité qui calcule
et paie (ou calcule la masse salariale) les agents doit avoir une liste des agents immatriculé
de sorte à ne payer que ceux-là. C’est pour ça que la Fonction Publique édite les
immatriculés et en envoie la liste à la Finance.
Pour maintenant rémunérer ces agents, leurs entreprises respectives participent aussi
dans le calcul, même si c’est la Finance qui paie (ou calcule le salaire). Et alors, calculer le
salaire d’un agent, c’est aussi une tache très délicate, qui nécessite une bonne attention, car
son calcul inclut beaucoup d’autres éléments tels que, les indemnités, la prime, le salaire de
base, les retenues, le prêt, etc., et le faire à la main peut probablement glisser des erreurs.
D’où, un besoin incessant de l’informatisation de processus, afin de pouvoir régulariser
pas mal des choses, à savoir l’immatriculation et la paie, au-delà de certains contrôles
physiques qui doivent toujours être maintenus.
Mettre une moindre transparence dans la gestion des ressources humaines de l’Etat,
chose qui est un volet non négligeable dans la gestion de la RDC, de sorte à assouplir
tant les processus d’immatriculation que ceux de la paie des agents, de sorte aussi à
permettre que les agents et l’Etat se retrouvent tous, et de sorte enfin si pas à contourner le
problème des agents fictifs, mais à l’amoindrir. L’informatique donc, s’avère un outil
incontournable, permettant ainsi d’éviter trop de temps d’attente, trop de déplacement,
trop de formulaires et donc de paperasses dans l’administration de l’Etat.

3
Donc la transparence, la souplesse, et la simplification de procédures, sont des intérêts
que poursuit ce travail.
Pour ce faire, nous allons mettre sur pied une solution informatique, sous un modèle
d’un système distribué, en exploitant plus précisément les Bases de Données Réparties
(BDR), puisque c’est le modèle qui s’accorde le plus à la situation, étant donné qu’elle fait
intervenir plusieurs sites distants et qu’en plus puisque déjà un bon nombre de sites sont
reliés dans le réseau de l’Intranet Gouvernemental.
Et dans les BDRs, nous nous nicherons sur l’utilisation des transactions, puisque ces
dernières, de par leurs propriété, offrent un bon nombre d’avantages, tels que, de gardre les
données de la base de données toujours cohérente, et si elles en venaient d’être dans une
situation de concurrence, elles s’en sortent toujours bien de par la possibilité qu’elles ont
d’être isolée, c'est-à-dire de permettre ou pas l’accès des autres transactions dans la lecture
ou l’écriture des ressources qu’elles utilisent, et bien plus que tout, grâce au journal de
transactions, qui permet d’archiver toutes les opérations effectuées sur la base. Les
transactions donnent donc cette possibilité de pouvoir retracer les opérations.
Certes, il existe nombreuses entreprises de l’Etat. Certes, il existe un bon nombre de
sites déjà relié dans le réseau de l’Intranet Gouvernemental.
Pourtant, pour des raisons de temps et de coût, de concision et de précision de
l’Application ici présentée comme solution informatique, nous n’avons pris en compte
que trois sites dont deux sont très stratégiques et indispensables à savoir, la Fonction
Publique pour l’immatriculation, et la Finance pour le calcul et la paie des agents, et un
troisième site qu’est la Primature pour illustrer le cas des entreprises ou institutions qui
participent passivement dans la rémunération des agents de l’Etat. Il faut signaler alors que
les deux sites sont aussi illustrés par le troisième site, étant donné qu’ils sont des institutions
avec des agents à gérer. Nous nous sommes aussi limités seulement aux éléments du salaire
cités ci haut.
Ainsi, grâce aux techniques de récolte de données suivantes, questionnaires (enquêtes)
et documentation, nous avons pu rassembler des informations nécessaires au montage de
notre Système d’Information.

4
Voici donc alors comment l’organisation du travail se présente :
Le travail est organisé en trois (3) chapitres :
- Le premier chapitre, intitulé Les Systèmes Distribué, donne un aperçu très
clair du domaine dont nous traitons, introduisant ainsi de manière nette, simple et
claire les concepts théoriques de base à utiliser dans la suite du travail, tels que la
réplication et les bases de données réparties.
Voici donc ses points chauds :
 Les Systèmes Distribués
 Les Bases de Données Répartie (BDR)
 La Réplication
 Conception, Fragmentation et Allocation d’une BDR
- Le deuxième chapitre, intitulé Les Transactions Distribuées, montre le bien
fondé de l’utilisation des transactions et de leur gestion, en parlant de différents
problèmes liés aux transactions concurrentes et leurs solutions.
 Définitions d’une Transaction
 Classification des Transactions
 Modèles de Transactions
 La Journalisation et la Reprise des Transactions
 Transaction distribuée et le Modèle OSI
 Gestion et Contrôle de Concurrence de transactions (Répartie)
Et enfin,
- Le troisième chapitre, intitulé Les Applications, c’est ici que nous nous
sommes évertués pour rattraper si pas toutes mais une grande partie de théories
avancées précédemment, dans les outils informatiques utilisés pour mettre en place
une application (répartie) informatique que nous avons nommée « SalaryManager »,
un logiciel de traitement et de calcul de salaire des agents de l’Etat au sein de
l’Intranet gouvernemental (e-Gouvernement), allant de l’immatriculation des agents
jusque et y compris le traitement de leur salaire.

5
 Mécanisme de Répartition sous SQL SERVER 2008
 Gestion de Transactions par la programmation sous .NET
(Framework 3.5)
 Intranet Gouvernemental de la RDC (République Démocratique
du Congo)
 Mise en place d’un Système d’Information (Automatisé) de
Traitement de Salaire des Agents de l’Etat (SalaryManager)

7
Chapitre I
Les Systèmes Distribués
Les réseaux informatiques, qu’est une interconnexion des équipements informatiques,
offrent aux entreprises toute une panoplie des avantages, parmi lesquels ceux qui sont
beaucoup plus à l’intention de ce travail on a, l’échange et partage des données
informatiques et l’accès à des bases de données réparties ou distribuées, aussi bien qu’on le
sache que le partage est l’objectif premier de Réseaux Informatiques [48].
Et à l’apparition de ce réseau, sont nés et y sont déployés des systèmes dits distribués,
l’exploitant pour arriver à leurs propres fins. Ces derniers sont soit des bases de données
distribuées sur ce réseau soit des applications interagissant avec ces bases de données,
spécifiquement pour le cas qui nous concerne.
C’est comme ça que, nous allons commencer par esquisser sur les systèmes distribués
avant de nous plonger de manière la plus détaillée possible sur les bases de données
distribuées.
I. 1. Les Systèmes Distribués
Nous allons commencer par élucider mais, en éludant toute confusion, la différence ou
mieux la ressemblance entre le terme « distribué » et « répartie ».
Le terme « distribué » vient du terme anglais « distributed » ayant comme idée d’une
distribution des tâches réalisées par un coordinateur, pendant que « répartie » suppose une
coopération des tâches en vue de la répartition du travail, et pourtant dans la littérature
anglaise on ne reconnait pas cette différence puisque dans le terme « distributed System »
distributed signifie : « réparti dans l’espace » [10].
De fait, il n’y a donc aucune différence entre Système Distribué et Système Réparti, ou
bien, entre Distribué et Réparti dans le reste du travail.
Par contre au niveau de la Base de Données, [15] montre une certaine nuance
montrant que quand on parle d’une Base de Données Distribuée (BDD), c’est un terme tout
à fait générique et que de ce fait une Base de Données Répartie (BDR) n’est qu’un cas de
BDD, au même titre que les BDs fédérées, les sytèmes multi BD, etc. Nous en parlons dans la
partie y consacrée.

8
I.1.1. Définitions
"Un système réparti est un ensemble de machines autonomes connectées par un
réseau, et équipées d'un logiciel dédié à la coordination des activités du système ainsi qu'au
partage de ses ressources." Coulouris et al. [18].
"Un système réparti est un ensemble d’ordinateurs (ou processus) indépendants qui
apparaît à un utilisateur comme un seul système cohérent". Tanenbaum [7] [25].
"Un système informatique distribué est une collection de processus informatiques
indépendants qui communiquent mutuellement par passage des messages" [27].
Force est de constater, que ces définitions ci-haut données ne se contredisent pas
mais, bien au contraire chacune d’elle définit une idée, qui mise ensemble donne une idée
claire et globale de ce qu’est un Système Distribué.
Aussi, nous en avons pu retenir deux concepts très importants, (i) indépendant, de par
la définition de [7], c'est-à-dire que les ordinateurs ont architecturalement cette capacité de
travailler indépendamment, (ii) le logiciel, de la première définition mais complété par la
deuxième, qui permet à cet ensemble d’ordinateurs de paraître à l’utilisateur comme un
seul.
Cette dernière notion est connue sous le nom d’Image unique du système [18] [43].
Et cette notion d’Image unique du système, fragilise un peu le système à tel enseigne
qu’il ne suffit qu’une simple panne d’un ordinateur, cela peut impacter négativement sur le
bon fonctionnement du système et voire amener à des incohérences.
Leslie Lamport l’a bien dit lorsque définissant un système distribué : "un système qui
vous empêche de travailler si une machine dont vous n’avez jamais entendu parler tombe en
panne" [27] [25].
I.1.2. Caractéristiques et Objectifs
Voici les objectifs pour lesquels on construirait un système distribué, qui font office
directement des caractéristiques de ce dernier :
 Le partage des ressources :
Toutes les ressources tant hardware (ordinateurs, organes d’entrée-sortie,
processeurs spécialisés, dispositifs de commande ou de mesure, etc.) que software
sont partagé entre les entités du système.

9
 L’ouverture :
Les composants et les logiciels utilisés au sein de ce système peuvent provenir de
différents fournisseurs et travailler sans aucun problème.
 La concurrence :
Le traitement concurrent augmente la performance du système.
 La grande échelle (ou scalability : en anglais)
C’est la capacité d’un système de ne pas dysfonctionner lorsque sa taille s’accroît, ou
lorsque des nouvelles ressources sont ajoutées.
 La tolérance à la faute :
C’est la capacité qu’un système continue de fonctionner malgré quelque défaillance
partielle des composants ou du réseau de communication.
I.1.3. Système Centralisé VS Système Distribué
Le Système Distribué, ne présenterait-il que des avantages ci-haut présentés en termes
d’objectifs ? Et pourtant, un peu ci-haut on a montré un petit problème lié à la notion
d’Image unique. Qu’on le sache, il a des problèmes ou désavantages dont nous allons parler
dans la suite. De plus, par définition, les systèmes distribués sont plus vulnérables que les
systèmes centralisés, car le nombre de points susceptibles d'être attaqués est plus
important, en plus de la faiblesse des réseaux rendus nécessaires par la répartition.
A la différence du système distribué, le système centralisé est celui qui travaille et se
base sur une seule et même machine, tout y est localisé et accessible par des programme. Ce
système est aussi bien illustré par un « mainframe », où il peut y avoir un ou plusieurs CPU
(Central Processing Unit) et les utilisateurs qui communiquent directement avec lui via des
terminaux.
Le seul vrai problème avec ce système, c’est qu’il n’est pas scalable (expansible) [43], il
y a une limitation par rapport au nombre de CPUs à tel enseigne qu’il faut le mettre à jour ou
carrément le remplacé lorsqu’il faut ajouter un CPU.
De par les avantages et objectifs du système distribué, on peut sans aucun effort voir
le pourquoi de ce passage.

10
Et pourtant ce passage amène aussi des nouveaux problèmes tels que la localisation, la
transparence, l’interopérabilité, etc. qui sont pris aux titres des défis, auxquels le système
distribué doit faire face.
 Conception d’un système distribué
La conception peut se faire de deux manières, [13], matérielle et logicielle.
Conception matérielle
Elle peut se réaliser sur :
+ Machine multiprocesseurs avec mémoire partagée
+ Cluster (grappe) d’ordinateur dédié au calcul/traitement massif parallèle
+ Ordinateurs standards connecté en réseau.
Conception logicielle
+ Le système logiciel ici, est composé de plusieurs entités disséminé dans un réseau,
s’exécutant indépendamment et parallèlement.
Appelé
Appelant
Souche
Appelant
Squelett
e
Appelé
Réseaux
Centralisé DistribuéFigure 1 : De Centralisé vers Distribué [9]

11
I.1.4. Propriété d’un Système Distribué
Les défis tantôt dits sont ici présentés comme des propriétés que doit assurer un
système distribué. Nous allons pour notre compte ne présenter que celles qui sont beaucoup
plus inhérentes à notre travail :
 La Transparence :
Contrairement à ce que laisse entendre naturellement ce vocable, elle veut plutôt ici
dire que, tous les détails techniques et organisationnels, complexes du système distribué
sont cachés à l’utilisateur.
Le but de la transparence est de permettre une manipulation des services distants plus
facilement, c'est-à-dire, comme des services locaux [27], sans avoir besoin de connaître sa
localisation ou son détail techniques des ressources [25].
Cette propriété fait alors maximiser la scalabilité et la flexibilité du système, simplifie le
développement des applications et leur maintenance évolutive et corrective.
La norme (ISO, 1995), classifie la transparence sous plusieurs niveaux [18] [25] [27]:
- Accès : il y a pas d’accès spécifique pour des ressources ; l’accès à une ressource tant
distante que locale est identique.
- Concurrence : l’utilisateur du système ne doit pas savoir que telle ou telle autre
ressource peut être partagée ou utilisée simultanément par d’autres utilisateurs.
- Extension (des ressources) : s’il faut étendre ou réduire le système, il ne faudra pas
que l’utilisateur en soit gêné (sauf la performance [18]).
- Hétérogénéité : il doit être caché à l’utilisateur les différences matérielles ou
logicielles des ressources qu’il utilise. La notion d’interopérabilité.
- Localisation : il n’est nullement besoin de savoir l’emplacement d’une ressource du
système pour y accéder. Ceci donne lieu à la transparence de migration [18].
- Migration : le déplacement d’une ressource peut se faire, mais sans qu’on ne s’en
plaigne, car rien ne sera aperçu.
- Panne : lorsqu’il y a panne (réseaux, machines, logiciels) au niveau d’un nœud du
système, l’utilisateur ne doit pas le savoir.

12
- Relocalisation ou Mobilité : une ressource peut changer d’emplacement pendant
qu’elle est utilisée, mais sans qu’on s’en rende compte.
- Réplication : l’utilisateur du système n’a pas besoin de savoir que telle ressource est
dupliquée.
De manière la plus évidente, on voit qu’on peut assurer une transparence totale, et
pourtant il est très difficile et voire impossible de masquer toutes les pannes des ressources.
 La Disponibilité
Il existe beaucoup de causes à l’origine de l’indisponibilité d’un système, mais voici
celles que nous notons ici selon [25] :
- Des pannes empêchant au système ou à ses composants de fonctionner
conformément à la spécification ;
- Des surcharges dues à des sollicitations excessives d’une ressource ; la congestion et
la dégradation des performances du système s’en suivent certainement.
- Des attaques de sécurité pouvant causer des dysfonctionnements, voire l’arrêt du
système, des pertes et incohérence de données.
Pour ne citer que ça.
Mais puisque dire « disponibilité » sous-entend que le système doit toujours être à
mesure de délivrer correctement les services et ce conformément à la spécification ; mais il
faut savoir que les pannes ou toute autres tentatives (ci-haut citées) vont toujours essayer
de compromettre le bon fonctionnement du système ; pour ce, il faut le rendre capable de
rester disponible.
Parmi les solutions retenues pour y remédier [25], nous avons choisi de ne parler que
de celle qui va beaucoup plus avec notre travail :
La réplication ; cette technique est utilisé pour pallier à la première (panne) et deuxième
(surcharge) cause d’indisponibilité. Ici, les copies d’une même ressource peuvent se trouver
en même temps dans des emplacements différents. Ainsi, lorsqu’une ressource tombe en
panne, le traitement qu’elle effectuait est déplacé sur une autre ressource disponible. Pour
ce qui est de la surcharge, au lieu que des sollicitations se fassent sur une même et seule
ressource, elles se font parallèlement sur chacune de ses copies (réplique) partout ailleurs.

13
 L’Autonomie
Puisque les systèmes existants ou les applications existantes sont souvent difficiles à
remplacer ou à réécrire, logiquement par ce qu’ils sont bien expérimentés et ont une
expertise ; quand on a besoin de les adapter à un autre besoin qui n’y est pas supporté.
Voici donc la bonne motivation parmi tant d’autres de l’autonomie ; un système ou un
composant est dit autonome si son fonctionnement et son intégration dans un système
existant n’exige pas de modifications ni à lui ni à ce dernier.
L’autonomie des composants d’un système favorise par conséquent l’adaptabilité,
l’extensibilité et la réutilisation de ressources de ce système.
Les Intergiciels : Middlewares
Pour compléter à l’autonomie d’un système, on peut aussi intégrer des intergiciels. Un
intergiciel (middleware, en anglais) est un assemblage des fonctionnalités, nouvelles,
formant un logiciel intermédiaire entre deux applications ou système. Il est demandé qu’un
tel logiciel ne soit pas générique mais plutôt spécifique, et cela pour éviter la surcharge qui
est un handicap pour la disponibilité.
- Les objectifs d’un Middleware
Les trois objectifs d’un middleware sont les suivants [1] [51]:
(1) masquer la complexité de l'infrastructure sous-jacente, donc l’hétérogénéité des machines
et systèmes ;
(2) Faciliter la conception, le développement et le déploiement d'applications réparties :
masquer la répartition des traitements et des données.
(3) Fournir des services communs : une interface commode aux applications (programmation
+ API : Application Programming Interface).

14
Site 1 Site 2
Applications
Middleware
Système de
communication
Interfaces
Figure 2: système distribué avec un middleware [1] [51]
Note : Le système de communication permet aux éléments des sites du système distribué
d’échanger des informations entre eux.
Exemples des Intergiciels :
- Java RMI (Remote Method Invocation), CORBA (Common Object Request Broker
Architecture), .NET [-Orienté Objet-]
- JTS (Java Transaction Service) de Sun, MTS (Microsoft Transaction Server) de
Microsoft [-Orientés Transactionnels-]
- Web Services (XML-RPC: Extensible Markup Language-Remote Procedure Call, SOAP:
Simple Object Access Protocol) [-Orientés Web-]
- ODBC (Open DataBase Connectivity), JDBC (Java DBC) de SUN [-Orientés SGBD/SQL-]
Nous n’avons parlé que de ces trois propriétés comme tantôt dit, mais puisqu’en plus
elles entrent beaucoup plus enjeu dans la suite de notre travail. Dans cette liste, se figure
aussi la grande-échelle, c'est-à-dire le passage à l’échelle, c'est-à-dire la « scalability »
(comme définit ci-haut).
I.1.5. Architecture d’un Système Distribué
Quasiment anticipé, l’architecture d’un système distribué est l’agencement ou mieux
la structure des composants constitutifs de ce dernier en termes de logiciels, matériels et
réseaux. Voici ces architectures en question [27]: Client-serveur (C/S), Peer-to-Peer ou Pair-
à-Pair (P2P) et Hybride ; ce dernière est une combinaison du modèle client/serveur et du
modèle Peer.

15
 Le Client-serveur : C/S
[Définition]
Le concept client-serveur, c’est pour définir une architecture. Et donc, l’architecture
client-serveur est un modèle de fonctionnement logiciel qui peut se réaliser sur tout type
d’architecture matérielle (petite et grosse machine) pourvu que ces architectures soient
interconnectées. Et là, nous avons deux types de logiciels, le logiciel client qui formule des
requêtes à un autre, et cet autre c’est le logiciel serveur, et les deux s’exécutant
normalement sur deux machines différentes.
Les deux applications dialoguent ou communiquent entre elles, de la manière
suivante :
- Le client demande un service au serveur
- Et le serveur réalise le service, c'est-à-dire, le traitement et le renvoie au client
Client SERVEUR
Requête
Résultat
Dialogue
Figure 3 : Client-Serveur
C’est le client qui initie le dialogue et le pilote, pendant que le serveur y participe tout
simplement. Et pour dialoguer ou communiquer, ils ont besoin de protocole de
communication.
[Mode de Client-serveur]
- Couches dans le Client
Le modèle client-serveur possède trois couches, dont on a [11]:
+ Couche présentation : qui s’occupe du dialogue entre la machine et
l’utilisateur.
+ Couche applicative : qui réalise des tâches pour produire de résultat escompté.
+ Couche de données : qui gère les données.

16
- Modes ou types ou modèles
Et par rapport à la répartition de ces couches entre serveur et client, on distingue trois
types ou modes client-serveur :
+ Client-serveur de présentation :
Le client ne possède que la couche présentation en son sein et le serveur en
possède soit toutes soit deux restantes.
+ Client-serveur de données :
Le client effectue la gestion du dialogue, la validation des saisies, la mise en
forme des résultats et les traitements (y compris la manipulation des
données). Le serveur gère l'accès aux données et de plus en plus souvent
l'intégrité des données. Il est appelé serveur de données.
Cette mise en œuvre est très répandue car elle a été popularisée par les
SGBDs relationnels qui ont reposé dès leur origine sur le modèle
client/serveur pour ce qui est de leur fonctionnement réparti.
Exemple : Application C# Avec SQL SERVER.
+ Client-serveur de traitements :
Ce type est également qualifié de traitement distribué (ou client-serveur de
procédure [14]). Le client appelle l’exécution d’un traitement stocké sur le
serveur qui effectue les traitements et renvoie les données au client.
On peut également répartir les données sur le poste client ou d’autres serveurs
de données en utilisant un SGBD supportant cette fonctionnalité. Dans ce
cas on effectue de la gestion distribuée de données (bases de données
réparties ou répliquées).
 Peer-to-Peer ou Pair-à-Pair : P2P
Cette architecture offre à un système la capacité de passage à l’échelle (scalability),
c'est-à-dire la capacité d’un système à continuer à délivrer avec un temps de réponse
constant un service même si le nombre de clients (nœuds) ou de données augmente de
manière importante [25] [36], afin de partager les ressources dans un réseau largement
distribué. L’avantage de cette architecture est celui de disposer toujours d’une puissance de
calcul, quand bien même le nombre de ressources disponibles dans le système est élevé. Et
cet avantage lui permet de traiter des taches complexes avec un coût relativement faible,
même sans avoir des serveurs gigantesque [36].

17
Dans cette architecture, un nœud peut donc jouer le rôle de client selon qu’il
consomme des ressources disponibles et serveur selon qu’il offre des ressources.
Une autre définition, qui explicite aussi les choses, c’est celle donnée par [34] [36] : «
Le terme "pair-à-pair" représente une classe de systèmes et d’applications qui utilisent des
ressources distribuées afin d’atteindre un objectif précis d’une façon décentralisée. Les
ressources incluent puissance de calcul, données (stockage et contenu), bande passante
et disponibilité (ordinateurs, être humaine ou autres ressources). L’objectif peut
être la répartition de calcul, le partage de données/contenu, la communication et la
collaboration ou le partage des services d’une plateforme. La décentralisation peut être
appliquée sur les algorithmes, les données et les métadonnées ».
I.2. Les Bases de Données Réparties (Distribuées)
Il y a des notions qui ont déjà été expliquées dans la section précédente, et quand
nous les réciterons ici nous n’aurons que la peine de rappeler qu’elles l’ont déjà été
précédemment.
I.2.1. Définitions
- Base de données : BD
Une base de données, de la manière la plus brève possible, c’est une collection des
données structurée reliées par des relations et interrogeable et modifiable par son contenu.
- Base de données répartie (distribuée):BDR ou BDD
Une base de données distribuée, c’est une collection de multiples bases de données
logiquement interconnectées distribuées ou réparties sur un réseau d’ordinateur [24], et
apparaissant à l’utilisateur comme une base de données unique [15].

18
Réseau de Communications
Site 1BD
Site 2BD
Site 3 BD
Site 4 BD
Site 5
BD
Figure 4 : Architecture d’une base de données [41]
- Système de Gestion de Base de Données : SGBD
Un SGBD est un logiciel informatique permettant aux utilisateurs de structurer,
d’insérer, de modifier, de rechercher de manière efficace des données spécifiques, au sein
d’une grande quantité d’informations, stockées sur mémoires secondaires partagée de
manière transparente par plusieurs utilisateurs.
- Système de Gestion de Base de Données Réparti (Distribué): SGBDR ou SGBDD
Un SGBDD est le logiciel qui gère les BDD, et fournit un mécanisme d’accès qui rend
cette distribution ou répartition transparente à l’utilisateur.
- Système de Bases de Données Distribuées : SBDD
Un SBDD est l’intégration de BDD et SGBDD, laquelle est réalisée à travers le
fusionnement de la BD et les technologies du réseau ensemble [24].
Ceci peut aussi être décrit comme un système qui coordonne une collection de
machines qui n’ont qu’une mémoire partagée (shared memory), cependant paraissant à
l’utilisateur comme une seule machine.

19
- Les concepts « distribué » et « répartie » dans les Base de Données
Le concept « distribué » est très générique et implique beaucoup d’autre [15], tels que
les BD Répartie, les BD fédérées, les Systèmes Multi bases, etc.
 Les BD Réparties, par exemple, peuvent être soit hétérogène soit
homogène ;
 Les BD Fédérées, ne sont par contre que des BD hétérogènes, mais dont
l’accès est via une seule vue ;
 Et les Système Multi bases, sont des bases de données hétérogènes
capables d’inter opérer avec une application via un langage commun,
sans une vue commune.
I.2.2. Buts et motivations pour une Base de Données Distribuée :
BDD
Il faut dire, vu ce qui précède, que la décentralisation a eu sa bonne raison de
transcender la centralisation de par sa valeur ajoutée, mais aussi puisque cette architecture
est la plus adaptée à beaucoup d’organisations des entreprises.
Les BDDs ont donc pour motivation [6]: l’amélioration de la performance du système,
l’augmentation de la disponibilité de données, le partage, le passage à l’échelle (scalability)
et l’accès facile. Nous en parlons en détail pour quelques-uns.
On a, donc :
(1) La nature intrinsèque des certaines situations ou applications. L’exemple d’une
banque qui a une direction centrale à un lieu donné, des succursales dans différentes
autres lieux qui peuvent traiter les données des clients locaux, par rapport au lieu,
mais contrôlés par la centrale. Il est évident qu’une base de données distribué dans
différents site, est appropriée.
(2) La fiabilité et la disponibilité. La fiabilité révèle cette nature d’assurer les services
attendus continuellement ; et la disponibilité, comme dit tantôt, est un élément
important pour accroître la fiabilité.
(3) Meilleure performance : la répartition de données permet souvent la réplication de
celles-ci, or nous avons précédemment dit que cette notion de réplication
assouplissait le trafic à tel enseigne que les sollicitations sur une ressource ou une
donnée étaient parallélisées.

20
I.2.3. Avantages et Contraintes
Voici quelques avantages retenus d’une base de données répartie, on a :
(1) Le rapprochement des données selon qu’un site les demande plus, ce qui permet la
réduction de coût de communication.
(2) L’autonomie de site local ; un site n’a pas besoin d’aller chercher ailleurs les données
qu’il possède lorsqu’un utilisateur demande au site certaines données.
(3) La continuité de services.
(4) Une intégration facile dans un système existant.
Nous en retenons qu’une seule contrainte que nous jugeons de pertinente, c’est la
complexité, qui se situe dans la conception d’une base de données distribuée par rapport à
celle qui est centralisée ; à savoir que cette conception prend en compte la fragmentation
des données, l’allocation des fragments dans des sites et la réplication.
[Contraintes]
- Coût : la distribution de données entraîne des coûts supplémentaires en
terme de communication, et en gestion des communications (hardware et
software à installer pour gérer les communications et la distribution).
- Problème de concurrence. Qui est même le cas traité dans ce travail.
- Sécurité : la sécurité est un problème plus complexe dans le cas des bases de
données réparties que dans le cas des bases de données centralisées.
I.2.4. La Répartition de données (Les Niveaux)
Nous distinguons trois niveaux dans lesquels la répartition de données intervient. Nous
allons présenter l’architecture (de niveau ou de schémas) de la BDR, à l’aide de laquelle,
nous allons expliquer la répartition.

21
Figure 5 : Architecture d’une BDD
Note : VE= Vue Externe.
La répartition d'une base de donnée intervient dans les trois niveaux de son
architecture en plus de la répartition physique des données :
- Niveau externe: les vues sont distribuées sur les sites utilisateurs.
- Niveau conceptuel: le schéma conceptuel des données est associé, par
l'intermédiaire du schéma de répartition (lui-même décomposé en un schéma de
fragmentation et un schéma d'allocation), aux schémas locaux qui sont
réparties sur plusieurs sites, les sites physiques.
- Niveau interne: le schéma interne global n'a pas d'existence réelle mais fait place à
des schémas internes locaux répartis sur différents sites.
I.2.5. Principe d’une Base de Données Réparties ou Distribuée
Le principal fondamental de BDD est la transparence pour l’utilisateur [15], mais que
[41] présente, de manière la plus détaillée, sous forme de niveaux de transparence (pour la
gestion de la BDD). Et nous en avons ci-haut montré ses apports.
Dans une BDD, la transparence s’exprime sous trois niveaux : - transparence de
distribution ou de réseaux, - de réplication et - de fragmentation.

22
- Transparence de distribution ou de réseaux :
Cette transparence renferme deux autres concepts : la transparence de localisation et la
transparence de désignation (naming transparency).
+ De localisation : Le système s’occupe de trouver le site où sont hébergées
les données demandées par l’utilisateur, et pourtant ce dernier n’en sait
rien et lance sa requête comme sur une seule et unique base de données.
+ De désignation : elle implique qu’une fois qu’un objet dans le système est
nommé, il peut être accédé, sans aucune ambigüité et sans aucune autre
spécification que ce nom.
- Transparence de réplication :
Une BDD a souvent des données répliquées dans d’autres sites, et ceci pour accroître une
certaine disponibilité, la performance, et la fiabilité. Alors cette transparence va masquer
cette situation de choses à l’utilisateur.
- Transparence de fragmentation:
La fragmentation est cette technique qui permet de distribuer les données dans tout le
système. Nous allons dans la suite montrer qu’il en existe deux sortes : verticale et
horizontale. Mais la transparence de fragmentation fera que l’utilisateur ne soit au courant
ni de la fragmentation de donné, ni de l’existence de fragments. Ainsi, lorsque l’utilisateur
lance requête (globale), le système s’occupera de la transformer en plusieurs requêtes de
fragment.
I.2.6. Systèmes de Gestion de Base de Données Distribuée (SGBDD)
et Architectures
Il existe plusieurs SGBDD, qui puissent être différents les uns des autres, et eux tous
ont un point que voici en commun [41]: les données et les logiciel sont distribués sur
plusieurs sites interconnectés dans une forme de réseau de communication.
Et pourtant, nous allons présenter dans cette section un seul facteur, qui est vraiment
inhérent à notre travail, qui différencie des SGBDDs, c’est l’Homogénéité.
[Homogénéité]
Quand on parle du degré d’Homogénéité de logiciel de SGBDD, il y a deux facteurs
reliés à ce problème de degré :

23
o [-Facteur 1-]
Si tous les serveurs (ou les SGBDDs locaux individuels) utilisent un logiciel identique et
que tous les utilisateurs (clients) utilisent aussi un logiciel identique, alors le SGBDD est dit
Homogène. Sinon, il est dit Hétérogène.
o [-Facteur 2-]
Un autre facteur relatif au degré d’Homogénéité, c’est le degré d’autonomie locale.
On parle d’un degré d’autonomie si les transactions locales peuvent avoir un accès
direct au serveur. Par contre, si le site local n’a pas de provision lui permettant de
fonctionner en tant qu’un SGBDD indépendant, alors le système ne possède pas
d’autonomie locale.
[Architecture]
Les SGBDDs peuvent avoir plusieurs architectures, qui sont classées selon différentes
approches de séparation de fonctionalité sur les processus (traitements) de SGBD. Nous
allons, ici, présenter deux architectures [41]: Client-serveur et serveur collaboratif
(collaborating server).
o [-Client-serveur-]
Nous en avons déjà parlé ci-haut ; ce système a un ou plusieurs processus client et
serveur. Et un processus client peut envoyer une requête à l’un des processus serveurs. Les
clients sont chargés de l’interface utilisateur et peuvent tourner dans un PC (personal
computer) et envoyer des requêtes à un serveur, qui, lui, gère les données et exécute les
transactions.
o [-Serveur Collaboratif-]
L’idée dans ce genre de système, c’est qu’on peut avoir une collection des serveurs de
bases de données, et chacun étant capable d’exécuter les transactions sur les données
locales, mais aussi qui exécutent les transactions coopérativement sur plusieurs serveurs.
Un serveur qui reçoit une requête accédant sur plus d’un serveur, il en produit des
sous-requêtes pour chaque serveur et à la fin rassemble les résultats à la requête du début.
Ce découpage (décomposition) de requêtes en sous-requêtes se fait par optimisation [15].

24
I.3. La Réplication
Nous pouvons en retenir qu’elle augmente la performance, en diminuant la charge qui
devrait être imposée à un seul site (serveur) par la duplication de données, de favoriser la
disponibilité en cas de pannes par exemple, toujours par la duplication de données dans
différents sites, cette dernière permet donc de travailler avec les données d’un site si un
autre tombe en panne ou dans le souci de diminuer le temps de réponse des transactions.
Mais, il faut tout de suite le signaler qu’elle n’a pas que les bons côtés ; pour ce qui est
de ses inconvénients, c’est le problème de mise-à-jour. Les données dupliquées doivent
donc être uniforme ; de fait, une mise-à-jour sur un fragment de données ne doit pas laisser
les autres indifférents et différents, et pourtant cette mise-à-jours et sa synchronisation ne
sont pas immédiates. On peut donc constater que malgré tout, l’utilisation de la réplication
exige de nous une certaine vigilance par rapport à la cohérence de la base. Car, En effet,
permettre aux transactions de manipuler plusieurs copies d’une même donnée peut générer
des incohérences [5].
Il faut donc faire le contrôle de la réplication, pour assurer la cohérence de la base.
I.3.1. Les protocoles de contrôle de réplication
On distingue deux principaux modèles pour ces protocoles (techniques) [5] :
- Le modèle de réplication synchrone :
Une transaction doit se synchroniser avec toutes les copies qu’elle modifie avant
validation.
C'est-à-dire qu’une modification d’une donnée dans un site entraîne celles de ses
copies dans d’autres. C’est la mise à jour temps réel de données.
Figure 6 : réplication synchrone
La technologie appliquée ici, c’est celle de la validation à deux phases. Avec son
avantage de rassurer la convergence de tous les sites au COMMIT ou ABORT. Et Ceci,
rappelons-le, rassurera autant la cohérence de la base.

25
* Les avantages et les désavantages
+ Avantage :
 Identité de copies (pas d’incohérence)
 La lecture (locale) de la dernière copie la plus mise à jour
 Les modifications sont atomiques, c'est-à-dire, soit ils ont lieu eux-
toutes à la fois, soit rien.
+ Désavantage :
 Une exécution très longue de la transaction, vue que celle doit faire
les mises à jour de tous les sites, et ceci crée souvent de TIMEOUT
(voir dans le chapitre suivant)
- Le modèle de réplication asynchrone :
Les modifications introduites par une transaction sont propagées aux autres sites
seulement après validation de la transaction.
C'est-à-dire, d’abord un site connait des changements et les valide, puis après ce
dernier peut les propager aux autres sites.
Figure 7 : réplication asynchrone
Les technologies utilisées sont : les Triggers (déclencheurs), les journaux d’images
(après), etc.
+ Avantage :
 Les transactions sont toujours locales (un bon temps de réponse)

26
+ Désavantage :
 Des incohérences de données
 Une lecture locale de données ne retourne pas toujours la valeur la
plus mise à jour.
 Les modifications à tous les sites ne sont garanties
 De fait, la réplication n’est pas transparente.
I.3.2. Architectures de Réplications
De ce qui précède, il est évident que l’emplacement de l’exécution d’une transaction
est un point capital, et d’ailleurs [5] montre qu’il existe deux architectures qui déterminent
cet emplacement même, on a : primary copy et update everywhere.
- Primary Copy :
Aussi appelé réplication asymétrique [23].
Ici, chaque copie possède une copie primaire dans un site spécifique (serveur), appelée
aussi « publisher ». Les transactions sont seulement exécutées sur les serveurs des données
qu’elles manipulent, ou mieux elles ne mettent à jour que cette copie, et les mises à jour sont
envoyées aux autres copies (secondaires) sur les autres sites.
+ Avantage :
 Aucune synchronisation inter-site n’est nécessaire (elle se réalise au
niveau de la copie primaire (primary copy)
 Il y a toujours un seul site qui a toutes les modifications
+ Désavantage :
 La charge imposée uniquement sur la copie primaire peut devenir
assez grande
 La lecture locale peut risquer de ne pas rendre une valeur la plus
mise à jour.

27
- Update everywhere :
Aussi appelé réplication symétrique [23]
Le principal à retenir ici, c’est que, aucune copie n’est privilégiée, par rapport au
précédent. Chaque copie dans n’importe quel site peut être mise à jour à n’importe quel
instant et ainsi le système assure la diffusion ultérieure de ces mises à jour à tous les autres
copies.
+ Avantage :
 De n’importe quel site peut s’exécuter une transaction
 La charge est équitablement distribuée
+ Désavantage :
 Les copies auront tout le temps besoin de la synchronisation
Toutes les quatre techniques ou stratégie ci-haut, peuvent être combinées en vue d’obtenir
une bonne performance et une bonne cohérence ou consistance de données, ainsi on a :
Réplication asymétrique synchrone
Réplication asymétrique asynchrone
Réplication symétrique synchrone
Réplication symétrique asynchrone

28
* Les avantages et les désavantages de la combinaison de stratégie
Symétrique Asymétrique
Synchrone Réplication symétrique synchrone Réplication asymétrique synchrone
+ Avantage :
 Pas d’incohérences
 La symétrie des sites
+ Désavantage :
 Un temps de réponse long
 Les modifications ont besoin
d’être coordonnées
+ Avantage :
 Les modifications n’ont
pas besoin d’être
coordonnées
 Pas d’incohérence
+ Désavantage :
 Un temps de réponse plus
long
 Seulement important avec
peu des modifications
 Les copies locales ne sont
lues que localement
Asynchrone Réplication symétrique asynchrone Réplication asymétrique asynchrone
+ Avantage :
 Pas de coordination
centralisée
 Temps de réponses très
court
+ Désavantage :
 Incohérence
 Les mises à jour peuvent
être perdues.
+ Avantage :
 Pas de coordination
nécessaire
 Temps de réponses court
+ Désavantage :
 Les copies locales ne sont
pas mise à jour
 Incohérence
Tableau 1: Avantages et Désavantages de la combinaison de stratégie
Il se suit de ce tableau ci-haut que,
- Réplication symétrie synchrone :
La cohérence de donnée est garantie. La performance peut sérieusement être
dérangée avec cette stratégie. Le système peut avoir un problème de passage à
l’échelle (verrou mortel : verrouillage à deux phases : voir dans le chapitre suivant) ;
dans ce sens que si le nombre de nœuds augmente, cela favorise le verrou mortel à
tout temps. Mais une tolérance à la panne très élevée.

29
- Réplication asymétrie synchrone :
A part l’absence de verrou mortel, cette stratégie est similaire au précédent. Mais ici,
le problème c’est le goulot d’étranglement qu’est la copie primaire.
- Réplication asymétrie asynchrone :
La performance est bonne (presque comme s’il n’y avait de réplication). Ainsi les
incohérences surgissent (de par le fait que chaque site a sa propre valeur de données).
- Réplication symétrie asynchrone :
La performance est excellente (presque comme s’il n’y a pas de réplication). Tolérance
à la panne élevée. Incohérence de la base. Et la reprise de mises à jour perdues est
dur à résoudre, on la fait presque manuellement.
I.4. Fragmentation, Allocation et Conception
Nous l’avons montré ci-haut que, la fragmentation et l’allocation des fragments dans
les sites du système étaient le vrai problème même dans les bases de données distribuée. Ce
problème set très critique qu’il demande d’énormes efforts lors de la conception d’une base
de données distribuée. L’allocation ou la fragmentation, [6], a un plus grand impact dans la
qualité sur la solution finale et par conséquent sur l’efficacité opérationnelle du système.
D’où, la performance de la base de données distribuée y dépend totalement.
La conception d’une base de données distribuée est un problème d’optimisation, qui
peut se subdiviser en deux problèmes [6], ou en trois [47] pour le cas d’une BDD répliquée:
- La conception de fragmentation des relations (tables) globale
- La conception de l’allocation de ces fragments à travers les sites du
réseau de communication
- Et/ou la réplication de ces fragments
I.4.1. Fragmentation
La fragmentation ou le partitionnement est une technique de conception qui consiste
à diviser une relation (unique) d’une base de données en deux ou plusieurs partitions telles
que leur combinaison reproduise la base de données originale sans aucune perte de
données [47].
Nous distinguons en gros deux types de fragmentation : horizontale et verticale, et un
troisième : hybride ou mixte.

30
- Fragmentation horizontale :
Elle permet de partitionner une relation (table) en tuples (ligne d’enregistrement)
disjoint, par sélection selon un critère donné.
L’exemple suivant servira d’illustration :
Soit la relation ou table suivante : Employé (de l’université de Kinshasa : UNIKIN)
Employé :
Matricule Noms Postnom Direction
06/30351 MASIDI LANDU COMMERCIALE
06/30352 MAPULUNGU ADELINE ETUDES
06/30353 MBWEBWE ROBERT COMMERCIALE
O6/30354 NTUMBA DENISE COMMERCIALE
06/30355 MUTOMBO TSHILEMEBE ETUDES
06/30356 PANGU NKOYI COMMERCIALE
Et les fragments sont obtenu par sélection, soit :
 Employé_1=SELECT * FROM Employé WHERE Direction = ‘COMMERCIALE’
 Employé_2=SELECT * FROM Employé WHERE Direction <> ‘COMMERCIALE’
Employé_1 :
06/30351 MASIDI LANDU COMMERCIALE
06/30353 MBWEBWE ROBERT COMMERCIALE
06/30356 NTUMBA DENISE COMMERCIALE
06/30356 PANGU NKOYI COMMERCIALE
Employé_2 :
06/30352 MAPULUNGU ADELINE ETUDES
06/30355 MUTOMBO TSHILEMBE ETUDES
La reconstruction:
Employé = Employé_1 U Employé_2

31
- Fragmentation verticale :
Elle permet de partitionner une relation ou table en une collection de colonne ou
attribut, à l’exception de la clé primaire [47]. Chacune de collections possèdera la clé
primaire, ce qui est normale, car cette servira de liens. Elle est basée sur la projection.
L’exemple suivant servira d’illustration :
Soit la relation ou table suivante : Commande
Commande :
NCde NClient Produit Quantité
C1 CLI1 P1 20
C2 CLI1 P2 22
C3 CLI2 P3 43
C4 CLI2 P4 100
Et les fragments sont obtenus par projection, soient :
 Commande_1=SELECT Code_Commande, Code_Client FROM Commande
 Commande_2=SELECT Code_Commande, Produit, Quantité FROM Commande
Commande_1 :
NCde NClient
C1 CLI1
C2 CLI1
C3 CLI2
C4 CLI2
Commande_2 :
NCde Produit Quantité
C1 P1 20
C2 P2 22
C3 P3 43
C4 P4 100

32
La reconstruction:
Pour cela, on fait la sélection avec un critère sur la clé primaire, qui est un lien entre les
fragments :
Commande = (SELECTION * FROM Commande_1, Commande_2 WHERE Commande_1.NCde
= Command_2.NCde)
- Fragmentation mixte ou hybride :
Dans cette sorte de fragmentation, on combine les deux précédentes, et ce de
manière tout à fait arbitraire, c'est-à-dire soit on commence par l’horizontale et puis
la verticale, vice-versa selon le besoin.
Exemples : (Sur la relation Commande ci-haut)
- Commande=SELECTION Code_Commande, Code_Client FROM Commande WHERE
Quantité >= 50
- Commande=SELECTION Code_Commande, Code_Client FROM Commande WHERE
Quantité > 50
Note : il existe un problème qui entache cette notion de fragmentation, c’est qu’elle est liée
à l’existence préalable de données [47], ce qui n’est pas toujours le cas quand on est au
début de la conception de la BDD. Mais, une bonne et efficace connaissance sur l’emploi ou
le besoin sur la BDD (d’une organisation) pourra permettre de savoir au préalable l’ensemble
de requêtes immédiates [16], et ceci facilitera évidemment la fragmentation dite statique.
Mais, dans le futur de l’organisation, d’autre besoins pourront naître d’où d’autres requêtes
et ceci pourra générer d’autres fragments ou déplacer ceux qui existaient, fragmentation
dynamique.
I.4.2. Allocation
Et à présent, après avoir fragmenté la base de données, c’est l’allocation qui s’en suit.
L’allocation, c’est cette étape où l’on affecte chaque fragment à un site du réseau. Les
données ou fragments assignés, peuvent être soit répliqués dans d’autres sites soit gardés
en un seul fragment dans un seul site. Ainsi on parle respectivement redondante et non-
redondante [6].

33
Son but, c’est de stocker les fragments de données plus proche, où ils peuvent être
fréquemment utilisés afin d’accroître la performance, et par conséquent de diminuer la
communication entre les sites. De fait, [6] montre que dans une base de données distribuée
bien conçue, nonante pourcent (90%) de données devraient être trouvées dans le site local
et dix pourcent (10%) seulement devraient être accédées dans un site distant.
 Allocation dynamique
Les requêtes à l’origine de chaque site et grâce auxquelles sont affectée les premières
données (fragments) dans chaque site, ont été fixées ou réalisées sur base des besoins
initiaux ou de la connaissance du domaine, et pourtant comme dit tantôt d’autres besoins
peuvent surgir après et ainsi d’autres requêtes peuvent se réaliser, c’est sera alors la
fragmentation dynamique.
D’où comme la première fragmentation avait permis la première affectation de
fragments (allocation) et constituer donc le schéma d’allocation, la fragmentation
dynamique qui entraîne une nouvelle allocation, entrainera de même la modification du
schéma d’allocation : l’allocation dynamique, c'est-à-dire, les fragments peuvent se déplacer
d’un site à un autre d’où il est appelé.
[15] montre que la technique de l’allocation dynamique est une alternative à la
duplication (réplication) et s’avère la plus efficace dans le cas de multiples modifications.
 Cliché (Snapshot)
Le cliché, c’est la technique de copie figée d’un fragment [15]. C'est-à-dire, ici, on
utilise une copie (image) d’un fragment d’un temps donné et qu’on ne va pas mettre à jour,
cette copie devient inutile au fil du temps. Ceci évite ce lourd travail de mettre à jour toutes
copies (fragments) correspondants dans les sites. On n’utilise cette technique pour les
données qui ne changent à chaque petit écart de temps, mais dont l’ancienneté de ses
valeurs n’entamera pas la réalité de choses.

34
I.4.3. Conception
Nous distinguons deux types de conception d’une base de données distribuée :
ascendante et descendante.
 Conception ascendante
C’est de cette conception qui s’agit lorsqu’il est question de créer une nouvelle base de
données distribuée. On commence par définir un schéma conceptuel global de la BDD, puis
on distribue sur les différents sites en des schémas conceptuels locaux, par la technique de
fragmentation (cf. ci-haut).
 Conception descendante
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 BDs 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 [15] [45].

36
Chapitre II
Les Transactions Distribuées
Le SQL (Structured Querry Language) est un langage par excellence pour l’interrogation
d’une base de données ou mieux d’un serveur de base de données, et pourtant si vous
effectuez une série de requêtes, il y a beaucoup de risques que l’une d’entre elles échoue et
une autre réussisse, et sur ce, les informations dans la base de données courent le risque
d’incohérence. D’où il existe un concept : « transaction », qui lui permet d’encapsuler un
ensemble d’opérations sur la base de données pour former un seul tout ; cette manière de
faire qu’est la transaction a un effet très positive sur les données à tel enseigne qu’elle
garantit la stabilité et l’intégrité des informations, c.-à.- d lorsqu’ une transaction (qui est un
bloc ou ensemble) est exécutée, la validation ou l’annulation se fait d’un bloc et soit laisse la
base de donnée comme avant (stable) ou elle l’amène dans un autre état de stabilité.
Une transaction peut être locale, lorsqu’il s’agit d’une transaction en une phase et
aussi gérée directement par la base de données ou très simplement lorsqu’elle effectue des
opérations sur une seule ressource (une base de données, etc.), et distribuée lorsqu’elle
utilise de nombreuses ressources, [21], [37].
II.1. DEFINITIONS D’UNE TRANSACTION
Une transaction, c’est un ensemble de requêtes regroupés en une seule unité logique
de travail, qui pourra ensuite être, soit validée, soit annulée;
C’est une collection d’actions [28] qui transforment une base de données (ou un
fichier), depuis un état cohérent en un autre état cohérent [3]; il faut dire que la cohérence
de la base de données est assurée par le système et celle de la transaction par le
programmeur.
Figure 8 : une transaction dans une base de données cohérente

37
 Modélisation d’une transaction
On peut modéliser une transaction comme une suite finie d’actions sur des objets
donnés [31] ;
Soit une transaction T, on a :
T = {Oi.Aj, | i = 1..n ; j = 1..p}
Où :
• i désigne un site visité par T
• Oi désigne un objet du site i
• Oi.Aj désigne une action j exécutée au sein de l'objet Oi
Les actions inhérentes à une transaction :
- Début_transaction : initialisation de la séquence transactionnelle
- Valider_transaction : terminaison de la séquence transactionnelle
- Annuler_transaction : arrêt de la transaction
- Lire (objet) : chargement d'une image de l'objet dans l'espace de travail
- Ecrire (objet) : sauvegarde d'une image de l'objet en mémoire secondaire
Note :
Transaction centralisée ou locale : les objets sont sur un seul site.
Transaction répartie ou distribuée : les objets (et les actions) sont sur plusieurs sites.

38
Exemple :
Réduire la commande (cde) N° 10 de 5 unités et les reporter à la cde 12
Transaction Report-qté
begin
exec sql UPDATE cde
SET qte = qté - 5
WHERE ncde = 10;
exec sql UPDATECde
SET qté = qté + 5
WHERE ncde = 12;
exec sql COMMIT WORK;
end.
Ce mécanisme d’encapsuler un ensemble de requêtes ou une collection d’actions ou
opérations en une seule entité qu’est donc la transaction garantit alors la cohérence des
données grâce à l’atomicité de la dite entité (transaction), c'est-à-dire s’il y a validation c’est
pour tout et de même pour l’annulation ; c’est « tout » ou « rien ».
Les opérations dans la transaction peuvent être soit de lecture soit d’écriture soit les
deux à la fois, et pourtant chaque transaction est marquée par un début (Begin Of
Transaction : BOT), et une fin (End Of Transaction : EOT) [45] et vérifie un ensemble de
propriétés représentées par l’acronyme ACID tiré de termes anglais suivants Atomicity,
Consistency, Isolation et Durability, dont elle bénéficie de la cohérence et de la fiabilité [45]
.
Voici comment se traduisent les termes ci-haut :
Atomicity : Atomaticité ;
Consistency : Cohérence ou Consistence
Isolation : Isolement [17] ou Isolation
Durabity : Durabilité

39
Voici ce que veut dire chacun de termes :
 Atomicité : La séquence d’instructions est indivisible, c'est-à-dire toutes les requêtes
exécutées dans le cadre de cette transaction sont validées en même temps ou
aucune ne l’est (principe du tout ou rien). L’ensemble des opérations réalisées sont
vues de l’extérieur comme une seule et même opération.
C’est le mécanisme de validation [31].
Il faut garantir qu'en cas de défaillance (processus avorté avant sa terminaison) :
- ou bien l'exécution est totale : l'ensemble des actions correspondant à la
transaction est complètement effectué et amène la base jusqu'à un nouvel état.
- ou bien l'exécution n'a aucun effet sur les objets car l'exécution est impossible :
toutes les modifications partielles engagées sont complètement annulées et l'on
reste à l'ancienne version
 Cohérence : la transaction ne viole pas les invariants du système, quand elle est
validée, elle génère un nouvel état stable du système, ou si un problème survient, le
système retourne dans l’état qui était considéré comme stable avant qu’elle n’ait
commencé.
Une transaction correcte est celle qui est constante avec la sémantique de cohérence
de l'ensemble des objets.
 Isolement [17]: Une transaction, tant qu’elle n’a pas été validée reste isolée des
autres transactions. Les autres transactions n’ont pas accès aux modifications
effectuées par cette transaction ; plus clairement le résultat des actions
intermédiaires (état temporairement incohérent) est masqué aux autres
transactions.
C’est le mécanisme de contrôle d'accès concurrents.
L'isolation ou l’Isolement est cette propriété qui permet à un ensemble de
transactions s'exécutant simultanément (concurremment dans le même
environnement) d'apparaître comme s'exécutant de façon indépendante les unes des
autres (sérialisabilité).
C'est le travail de contrôle de concurrence proprement dit.

40
 Durabilité : Les données validées sont enregistrées telles quelles, même si un
problème survient ou que le système redémarre. Les données sont disponibles dans
un état correct et sont désormais permanents.
C’est le mécanisme de reprise après panne (recovery).
Les effets des opérations décidées (validées) définitivement doivent être durables
(persistants) même en cas de défaillance (de processeurs ou de communication)
La fin d'une transaction est un point de non-retour.
C’est aussi le mécanisme de reprise après panne [31].
Lorsqu’une transaction a débuté, il y a lieu de constater trois cas : la validation,
l’annulation et l’interruption :
- Validation : appelée COMMIT ; la transaction a bien aboutit jusqu’à la fin et la base
de données enregistre les modifications;
- Annulation : appelée ROLLBACK, le mécanisme chargé de défaire les modifications
effectuées par la transaction ;
- Interruption : appelée ABORT
II.2. CLASSIFICATION DES TRANSACTIONS
On peut classer les transactions suivant plusieurs critères tels que la nature de
différentes opérations qui la composent, la durée qu’elle peut prendre [25] :
II.2.1. Suivant la nature de différentes opérations
 Transaction de Lecture, Transaction d’Ecriture
Si une transaction contient au moins une opération qui effectue des modifications sur
les données de la base, la transaction est dite transaction d’écriture ou de mise à jour. Si
toutes les opérations ne font que des lectures sur les données de la base, la
transaction est dite transaction de lecture.

41
II.2.2. Suivant la durée
 On-Line :OLTP, Batch : OLAP
Une transaction peut être classée on-line ou batch. Les transactions on-line,
communément appelées transactions courtes, sont caractérisées par un temps de
réponse relativement court (quelques secondes) et accèdent à une faible portion des
données. Les applications qui utilisent ce modèle de transaction sont dénommées
applications OLTP (On-line Transactional Processing) parmi lesquelles, nous avons les
applications bancaires, de réservation de billets, de gestion de stocks, etc. Les
transactions batch, appelées transactions longues, peuvent prendre plus de temps pour
s’exécuter (minutes, heures, jours) et manipulent une très grande quantité des
données. Les applications utilisant ce type de transactions sont les applications
décisionnelles ou OLAP (On-line Analytical Processing), de conception, de workﬂow, de
traitement d’image, etc.
II.3. MODELES DE TRANSACTIONS
Il en existe plusieurs, et en voici quelques uns selon [28]
II.3.1. Les Transactions Plates (Flat Transactions) :
C’est la plus simple de transactions, celle définie un peu plus haut. Une transaction
peut être soit interrompue par le programme l’exécutant (une Base de Données, par
exemple) soit à cause d’une défaillance externe, telle que le crash d’un système.
II.3.2. Les Transactions plates avec Points de Sauvegarde
(SAVEPOINTS) :
Une transaction peut donc être découpée en étapes, et après chaque étape on peut
insérer un point de sauvegarde (SAVEPOINT) donnant toujours cette possibilité de valider
(COMMIT) ou annuler (ROLLBACK) en partie ou en entièreté les modifications apportée par
la transaction à la fin de celle-ci [15] [22] [28].

42
Les SAVEPOINTS ont chacun un nom unique, garantissant que si jamais il y a
une interruption, les modifications déjà effectué et ayant déjà été marquée par un
SAVEPOINT persisteront [28].
II.3.3. Les Transactions Chainées (Chained Transactions) :
Ce sont une variante de SAVEPOINTS. Toutefois, plutôt que de marquer simplement un
point de cohérence d’où peut retourner une transaction, la commande de travail de la
chaine valide en fait le travail jusqu’à là. Il n’y a donc pas lieu de faire le ROLLBACK sur le
travail précédent. Toutefois, la transaction elle-même va survivre. Au cas où il y a un verrou
posé par la transaction, il va continuer ainsi jusqu’à la fin du travail. Le verrou sera relâché
seulement si toute la transaction a été validée.
II.3.4. Les Transactions Imbriquées ou Emboitées (Nested
Transactions)
[Définitions]
> Une transaction imbriquée est composée d’une hiérarchie de sous-transactions
ou un arbre de transaction [28].
Début de la nouvelle
Transaction
Fin Transaction
précédente
ROLLBACK
COMMIT
DATABASE
INSERT UPDATE DELETE
SAVEPOINT N1 SAVEPOINT N2
Début
Transaction
Fin
Transaction
Figure 9 : Transaction plates avec SAVEPOINTS [22]

43
Figure 10 : Arbre de Transactions et sous-Transactions
L’arbre de Transactions ; une transaction peut avoir n’importe quel nombre de sous-
transactions, lesquelles peuvent aussi être composées de n’importe quel nombre de sous-
transactions, ainsi se résulte une transaction imbriquée.
La transaction racine est appelée Top-Level Transaction (le niveau le plus supérieur)
car elle n’a pas un autre nœud de transaction auquel elle est liée ; les transactions ayant des
sous-transactions sont appelées des parents (des mères) et les sous-transactions des enfants
(des filles), les filles d’une même mère sont des sœurs. On parle ainsi des descendants (en
partant de la racine vers les enfants) et des ancêtres (inversement). Et les transactions et les
sous-transactions, elles sont toutes des transactions.
On appelle filles ou feuilles des transactions qui n’ont plus d’autres sous-transactions
et ces dernières sont des transactions plates.
> Une sous-transaction est une unité de reprise.
- L'abandon d'une sous-transaction implique l'abandon de ses descendants
mais pas de ses ancêtres.
> Une sous-transaction est une unité d'exécution indépendante
- Isolation des sous-transactions s'exécutant en parallèle
- Les sous-transactions peuvent s'exécuter sur le même site ou sur des sites
différents
> Les transactions sont ACID alors que les sous-transactions sont AI
(Atomicity, Isolation)
> Les feuilles de l’arbre de transaction sont des transactions plates (flat
transactions) [28].

44
(*) Une transaction parent peut passer son verrou à une transaction enfant. Une sous-
transaction peut être validée (COMMIT) ou être interrompue n’importe quand, et dans ce
cas tout verrou possédé par une sous-transaction passe au parent. Tous les verrous sont
relâchés seulement quand la transaction racine a été validée.
[Objectifs]
> Obtenir un mécanisme de reprise multi-niveaux
> Permettre de reprendre des parties logiques de transactions
> Faciliter l'exécution parallèle de sous-transactions
[Règles d’Isolation]
Quelque notions déjà énoncée précédemment au (*)
> (R1) Seules les transactions feuilles accèdent aux ressources partagées (ex:
base de données)
> (R2) Quand une sous-transaction valide, ses ressources sont héritées par sa
mère
> (R3) Quand une sous-transaction abandonne, ses ressources sont relâchées
> (R4) Une sous-transaction ne peut accéder une ressource que si elle est libre
ou détenue par un ancêtre
[Atomicité et Durabilité]
Comme aussi dit tant tôt ;
> (R1) Quand une sous-transaction valide, ses effets sont hérités par sa
mère
> (R2) Quand une sous-transaction abandonne, ses effets sont abandonnés
> (R3) Quand la transaction racine valide, ses effets sont installés dans la
base

45
Illustration
Figure 11 : Validation et Abandon de Sous-Transactions
Veuillons donc voir les règles de [Atomicité et Durabilité] dans cette illustration.
Ici, nous avons la transaction T1 qui a deux sous-transactions T11 et T12
- A l’état initial, X=0 ;
- Et après T11 le modifie, X :=X+1, d’où X=1 ;
- Alors, T11 valide ses modifications selon (R1), mais comme tous les traitements de
l’arbre de transactions ne sont pas finis alors, X=0;
- Et au tour de T12 de faire les modifications, X=X+1, d’où X=2, mais X=0 ;
- Mais T12 vient à abandonner ses modifications selon (R2) ;
- Et en fin quand T1 valide, selon (R3), X=1 conformément à tout ce qui précède.
II.3.5. Transactions Compensatrices
Les Transactions Compensatrices sont des transactions qui sont à la fin des
Transactions proprement dite et qui s’exécutent en cas de panne de paire de
transactions qu’elles doivent compenser.

46
Figure 12 : Transactions compensatrices
II.3.6. Les Transactions Longues
Comme montré au point (2), les transactions Batch sont un exemple de transactions
longues qui peuvent contenir un millier de mises-à-jour et durent beaucoup d’heures. Cela
peut devenir une situation intolérable.
Une solution existe, c’est celle de découper le travail du batch en mini-batch travaillant
sur les données avec un même attribut, tel qu’une collection de clés [28].
Malgré cette solution, elle n’est pas la parfaite du fait que l’atomicité de toute la
transaction ne peut pas être maintenue.
II.3.7. Les transactions Distribuées
Nous l’avons aussi déjà dit tant tôt, les transactions distribuées sont celles qui doivent
s’exécuter à travers un réseau de bases de données. Elles sont similaires aux transactions
imbriquées. Toutefois, l’arbre de transaction pour une transaction imbriquée dépend de
l’application, pendant que l’arbre pour une transaction distribuée dépend de données. Les
transactions distribuées sont essentiellement des transactions plates (flat transactions).
Toutefois, si les données sont hébergées dans une base de données distante doivent être
mises à jour, alors une sous-transaction débute sur cette base de données. Le bloc de sous-
transaction est l’ensemble d’opérations sur la base de données. Au moment du COMMIT, la
transaction parent (mère) interroge toutes ses sous-transactions pour s’assurer qu’elles sont
toutes prêtes pour les COMMITS avant d’entamer la commande d’un COMMIT. Si une ou
plus d’une transaction peut ne pas faire le COMMIT, alors la transaction connait un ABORT
Nous en parlons encore en abondance et en vif dans la suite avec le modèle OSI à
l’appui.

47
II.4. LA JOURNALISATION ET LA REPRISE DES
TRANSACTIONS
II.4.1. Journalisation
C’est la technique appliquée pour prévenir les pannes, toutes les modifications
apportées à la Base de Données sont écrites dans un fichier journal appelé Log.
Chaque fois qu’il y a écriture au niveau de la base de données, il y a aussi une autre y
correspondant dans un support sûr (log) ;
Le journal de transaction est le pilier de la reprise consistante [28] et la terminaison
d’une action atomique interrompue par une panne.
On distingue donc [30]:
- Le Journal des images avant
- Le Journal des images après
Pour chaque donnée dans la base.
Le journal de transaction peut grossir et se remplir avec le temps, mais c’est le
Gestionnaire de Journaux (Log Manager) qui permet de :
- L’archivage de journaux
- D’apprêter (vider) le journal pour une prochaine utilisation après qu’il soit remplit
- Et il fournit au Gestionnaire de Transactions et de Données une interface publique au
journal, et ce pour la reprise, vu que ce dernier fournit des informations nécessaires
pour restaurer une base de données endommagée à son dernier état cohérent [28].
(a) Le Journal des images avant
Il contient les débuts de transactions, les valeurs d'enregistrement avant mises à
jour, les fins de transactions (COMMIT ou ABORT)
Il permet donc de défaire (UNDO) les mises à jour effectuées par une transaction

48
Figure 13 : L’UNDO d’une mise-à-jour [30].
Toute mise à jour doit être précédée d'une écriture dans le journal des images avant
Avant tout, signalons que ce journal est utilisé pour défaire les actions d’une
transaction lorsqu’un site participant (cfr Protocole à Deux Phases, un peu plus loin) tome en
panne avant la validation (globale) de celle-ci.
Chaque fois quand une transaction démarre, il y a deux pages qui se lancent aussi :
page lue et page modifié (en mémoire cache).
- Page lue, contient l’ancienne valeur ou mieux pointe son adresse dans le journal
- Page modifiée, contient la valeur modifiée. Et c’est elle modifie vraiment la base de
donnée.
Alors, pour défaire, la base de données lire (READ) dans la page lue (1), et celle-ci
récupère l’ancienne value du journal (2), et apporte une modification la page modifiée avec
cette valeur (3) et enfin la page modifiée écrit dans la base de données (4) et cette dernière
revient à son état initial.
(b) Le Journal des images après
Il contient les débuts de transactions, les valeurs d'enregistrement après mises à
jour, les fins de transactions (COMMIT ou ABORT)
Il permet également de refaire (REDO) les mises à jour effectuées par une
transaction

49
Figure 14 : Le REDO d’une mise-à-jour [30].
Toute validation de transaction doit être précédée de l'écriture de son journal
d'images après sur un disque différent de celui contenant la base de données.
Pareillement avec la méthode de page ombre [52], lorsqu’il y a validation la page
modifié devient la page lue ;
Alors, pour défaire, la base de données lire (READ) dans la page lue (1), et celle-ci
rapporte une modification la page modifiée avec les dernières valeurs de la transaction (2),
et la page modifiée prend toutes informations de la transaction (validation, etc.) du journal
(3) et enfin la page modifiée écrit dans la base de données (4) et ainsi les mêmes mises-à-
jour sont de nouveau apportées à la base de données.
Note :
[30] et [28] montrent qu’il existe deux autres type de journaux, à savoir Logique et physique
• Journal physique:
* On enregistre la valeur avant et après modification
* La structure peut être : IdTrans, NumPageDisk, Adresse, Valeur
* Pour défaire, on écrase la valeur actuelle avec les valeurs avant
* Pour refaire, on écrase la valeur actuelle avec les valeurs après

50
• Journal Logique
+ On enregistre l’action logique qui a entraîné la modification
+ La structure peut être : IdTrans, IdObjet, IdActions, Arguments
+ Exemple: Ajouter 500 au tuple xxx
+ pour refaire, on ré-applique l’action logique
II.4.2. Reprise
On a vu que lorsqu’une transaction se déroulait, elle pouvait subir une interruption
(ABORT), et cela est dû principalement à une panne ou défaillance.
A la reprise (après une défaillance), le système transactionnel parcourt le journal pour
analyser l'état des transactions interrompues au moment de l'incident.
(a) Différent types de pannes (défaillances)
> Abandon d’une Transaction
Dû souvent à un problème d’accès concurrent [44].
> Panne Système
Dû à un arrêt brutal des travaux, d’où une perte de contenu de la RAM ou une
défaillance matérielle ou logicielle d'un système local ou du système de
communication
> Panne du support de reprise
(b) Traitement de reprise
Respectivement pour les deux dernier cas de pannes, on y remédie avec une reprise à
chaud et une reprise à froid.
> Reprise à chaud
+ Défaire les actions des transactions interrompues sur les sites en
fonctionnement
+ Redémarrer le site interrompu (ou reconnexion en cas de panne réseau)
+ Défaire les actions des transactions sur le site reconnecté
+ Ré-exécuter les transactions
> Reprise à froid
+ Restaurer la mémoire secondaire dans un état cohérent à l'aide d'une image
sauvegardée antérieurement (grâce au CHECKPOINT)
+ Refaire les actions des transactions perdues à cause de la défaillance
Toutes ces reprises se font grâce aux points de reprise (CHECKPOINTS) créés bien avant.

51
(c) Le Point de Reprise (CHECKPOINT)
Ce point se réalise après un état cohérent de la base de données provoqué par une
mise-à-jour et aussi après une sauvegarde ; il permet ainsi de situer une transaction
effectuée et ses actions soit pour un UNDO ou un REDO après une défaillance.
II.5. TRANSACTION DISTRIBUEE ET LE MODELE OSI
Avant d’entrer dans le vif de ce point, nous aimerions lui faire un préambule axé sur le
système transactionnel, qui est le système dans lequel ou mieux entre lesquels les
transactions se déroulent.
II.5.1. Le Système Transactionnel
L’objectif principal de ce système, c’est le traitement transactionnel soit OLTP à savoir
On-Line Transaction Processing, qui est un mode d’organisation d’une application
informatique qui permet à un grand nombre d’utilisateurs de soumettre, via leurs
terminaux, des transactions à un système qui doit les traiter le plus vite possible et
répercuter les effets sur une grande base de données [1].
En voici l’architecture :
Poste Client
Machine Serveur
Figure 15 : Architecture du système transactionnel [31]

Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (TFE)

Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (TFE)

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (TFE)

Semelhante a Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (TFE) (20)

Último

Último (20)

Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (TFE)