a
UNIVERSITE DE KINSHASA
Faculté des Sciences
Département de Mathématiques et Informatique
B.P. : 190 Kinshasa XI
Par
KAYE...
b
UNIVERSITE DE KINSHASA
Faculté des Sciences
Département de Mathématiques et Informatique
B.P. : 190 Kinshasa XI
Etude de...
i
Table de Matières
EPIGRAPHE ...............................................................................................
ii
II.3.2. Les Transactions plates avec Points de Sauvegarde (SAVEPOINTS) :..................41
II.3.3. Les Transactions C...
iii
III.4.2.3.1. Diagramme de Cas d’Utilisation ...............................................................98
III.4.2....
iv
Epigraphe
… Un Système de Bases de Données Réparties est
suffisamment complet pour décharger les utilisateurs de
tous l...
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...
vi
Remerciements
A celui qui garde l’âme et protège le corps ; le Tout-Puissant Dieu qui renouvelle
les forces, nous trans...
vii
[Les Listes]
viii
Liste des Abréviations
.NET : DotNET
2-PC : Protocole de Validation en Deux Phases
3-PC : Protocole de Validation en ...
ix
SQL : Structured Query Language
TP: Transactions Processing
TPPM : TP Protocol
TPSU: TP Service User
TPSUI : TPSU Invoc...
x
Liste des Figures
Figure 1 : De Centralisé vers Distribué [9]..............................................................
xi
Figure 38 : Diagramme de Classe ..........................................................................................
xii
Liste des Tableaux
Tableau 1: Avantages et Désavantages de la combinaison de stratégie ..................................
xiii
[Introduction Générale]
1
Introduction Générale
Actuellement les besoins d’entreprises et leurs solutions doivent tabler sur
l’infrastructure qui ...
2
Pour que l’Etat ou le Gouvernement salarie un agent, ce dernier doit de prime abord
être immatriculé. Sachant que c’est ...
3
Donc la transparence, la souplesse, et la simplification de procédures, sont des intérêts
que poursuit ce travail.
Pour ...
4
Voici donc alors comment l’organisation du travail se présente :
Le travail est organisé en trois (3) chapitres :
- Le p...
5
Voici donc ses points chauds :
 Mécanisme de Répartition sous SQL SERVER 2008
 Gestion de Transactions par la programm...
6
[Chapitre I]
7
Chapitre I
Les Systèmes Distribués
Les réseaux informatiques, qu’est une interconnexion des équipements informatiques,
o...
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 ...
9
 L’ouverture :
Les composants et les logiciels utilisés au sein de ce système peuvent provenir de
différents fournisseu...
10
Et pourtant ce passage amène aussi des nouveaux problèmes tels que la localisation, la
transparence, l’interopérabilité...
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 ...
12
- Relocalisation ou Mobilité : une ressource peut changer d’emplacement pendant
qu’elle est utilisée, mais sans qu’on s...
13
 L’Autonomie
Puisque les systèmes existants ou les applications existantes sont souvent difficiles à
remplacer ou à ré...
14
Site 1 Site 2
Applications
Middleware
Système de
communication
Interfaces
Figure 2: système distribué avec un middlewar...
15
 Le Client-serveur : C/S
[Définition]
Le concept client-serveur, c’est pour définir une architecture. Et donc, l’archi...
16
- Modes ou types ou modèles
Et par rapport à la répartition de ces couches entre serveur et client, on distingue trois
...
17
Dans cette architecture, un nœud peut donc jouer le rôle de client selon qu’il
consomme des ressources disponibles et s...
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 ...
19
- Les concepts « distribué » et « répartie » dans les Base de Données
Le concept « distribué » est très générique et im...
20
I.2.3. Avantages et Contraintes
Voici quelques avantages retenus d’une base de données répartie, on a :
(1) Le rapproch...
21
Figure 5 : Architecture d’une BDD
Note : VE= Vue Externe.
La répartition d'une base de donnée intervient dans les trois...
22
- Transparence de distribution ou de réseaux :
Cette transparence renferme deux autres concepts : la transparence de lo...
23
o [-Facteur 1-]
Si tous les serveurs (ou les SGBDDs locaux individuels) utilisent un logiciel identique et
que tous les...
24
I.3. La Réplication
Nous pouvons en retenir qu’elle augmente la performance, en diminuant la charge qui
devrait être im...
25
* Les avantages et les désavantages
+ Avantage :
 Identité de copies (pas d’incohérence)
 La lecture (locale) de la d...
26
+ Désavantage :
 Des incohérences de données
 Une lecture locale de données ne retourne pas toujours la valeur la
plu...
27
- Update everywhere :
Aussi appelé réplication symétrique [23]
Le principal à retenir ici, c’est que, aucune copie n’es...
28
* Les avantages et les désavantages de la combinaison de stratégie
Symétrique Asymétrique
Synchrone Réplication symétri...
29
- Réplication asymétrie synchrone :
A part l’absence de verrou mortel, cette stratégie est similaire au précédent. Mais...
30
- Fragmentation horizontale :
Elle permet de partitionner une relation (table) en tuples (ligne d’enregistrement)
disjo...
31
- Fragmentation verticale :
Elle permet de partitionner une relation ou table en une collection de colonne ou
attribut,...
32
La reconstruction:
Pour cela, on fait la sélection avec un critère sur la clé primaire, qui est un lien entre les
fragm...
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ît...
34
I.4.3. Conception
Nous distinguons deux types de conception d’une base de données distribuée :
ascendante et descendant...
35
[Chapitre II]
36
Chapitre II
Les Transactions Distribuées
Le SQL (Structured Querry Language) est un langage par excellence pour l’inter...
37
 Modélisation d’une transaction
On peut modéliser une transaction comme une suite finie d’actions sur des objets
donné...
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...
39
Voici ce que veut dire chacun de termes :
 Atomicité : La séquence d’instructions est indivisible, c'est-à-dire toutes...
40
 Durabilité : Les données validées sont enregistrées telles quelles, même si un
problème survient ou que le système re...
41
II.2.2. Suivant la durée
 On-Line :OLTP, Batch : OLAP
Une transaction peut être classée on-line ou batch. Les transact...
42
Les SAVEPOINTS ont chacun un nom unique, garantissant que si jamais il y a
une interruption, les modifications déjà eff...
43
Figure 10 : Arbre de Transactions et sous-Transactions
L’arbre de Transactions ; une transaction peut avoir n’importe q...
44
(*) Une transaction parent peut passer son verrou à une transaction enfant. Une sous-
transaction peut être validée (CO...
45
Illustration
Figure 11 : Validation et Abandon de Sous-Transactions
Veuillons donc voir les règles de [Atomicité et Dur...
46
Figure 12 : Transactions compensatrices
II.3.6. Les Transactions Longues
Comme montré au point (2), les transactions Ba...
47
II.4. LA JOURNALISATION ET LA REPRISE DES
TRANSACTIONS
II.4.1. Journalisation
C’est la technique appliquée pour préveni...
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 imag...
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 jou...
50
• Journal Logique
+ On enregistre l’action logique qui a entraîné la modification
+ La structure peut être : IdTrans, I...
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
...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet Gouvernemental de la RDC (...
Prochain SlideShare
Chargement dans…5
×

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

1 087 vues

Publié le

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

Ceci est un travail de fin d'études, réalisé comme une étude et sanctionné par une application logicielle à la fin.

Publié dans : Ingénierie
0 commentaire
1 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
1 087
Sur SlideShare
0
Issues des intégrations
0
Intégrations
240
Actions
Partages
0
Téléchargements
38
Commentaires
0
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

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

  1. 1. 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
  2. 2. 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 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
  3. 3. 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
  4. 4. 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
  5. 5. 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
  6. 6. 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]
  7. 7. 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. KAYEMBA KAVUALLA Sagesse
  8. 8. 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. KAYEMBA KAVUALLA Sagesse
  9. 9. vii [Les Listes]
  10. 10. 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
  11. 11. 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
  12. 12. 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
  13. 13. 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
  14. 14. 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
  15. 15. xiii [Introduction Générale]
  16. 16. 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.
  17. 17. 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.
  18. 18. 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.
  19. 19. 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. Voici donc ses points chauds :  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.
  20. 20. 5 Voici donc ses points chauds :  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)
  21. 21. 6 [Chapitre I]
  22. 22. 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.
  23. 23. 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.
  24. 24. 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.
  25. 25. 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]
  26. 26. 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.
  27. 27. 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.
  28. 28. 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).
  29. 29. 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.
  30. 30. 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.
  31. 31. 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].
  32. 32. 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].
  33. 33. 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.
  34. 34. 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.
  35. 35. 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.
  36. 36. 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.
  37. 37. 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é :
  38. 38. 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].
  39. 39. 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.
  40. 40. 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. * Les avantages et les désavantages + Avantage :  Les transactions sont toujours locales (un bon temps de réponse)
  41. 41. 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. * Les avantages et les désavantages + 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.
  42. 42. 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. * Les avantages et les désavantages + 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
  43. 43. 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.
  44. 44. 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.
  45. 45. 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 : Matricule Noms Postnom Direction 06/30351 MASIDI LANDU COMMERCIALE 06/30353 MBWEBWE ROBERT COMMERCIALE 06/30356 NTUMBA DENISE COMMERCIALE 06/30356 PANGU NKOYI COMMERCIALE Employé_2 : Matricule Noms Postnom Direction 06/30352 MAPULUNGU ADELINE ETUDES 06/30355 MUTOMBO TSHILEMBE ETUDES La reconstruction: Employé = Employé_1 U Employé_2
  46. 46. 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
  47. 47. 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].
  48. 48. 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.
  49. 49. 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].
  50. 50. 35 [Chapitre II]
  51. 51. 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
  52. 52. 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.
  53. 53. 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é
  54. 54. 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.
  55. 55. 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.
  56. 56. 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 workflow, 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].
  57. 57. 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]
  58. 58. 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].
  59. 59. 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
  60. 60. 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.
  61. 61. 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.
  62. 62. 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
  63. 63. 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
  64. 64. 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
  65. 65. 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.
  66. 66. 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]

×