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

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

a

D

u

D

u

S

o

f

t

w

a

r

e

a

u

S

a

a

S

* *

S

o

f

t

w

a

D

u

S

o

f

t

w

a

r

e

a

u

S

a

a

S

* *

S

o

f

t

w

a

b

UNIVERSITE DE KINSHASA

Faculté des Sciences

Département de Mathématiques et Informatique

B.P. : 190 Kinshasa XI

Etude des Transactions Concurrentes Dans une Base de Données Répartie

Application à l’Intranet Gouvernemental de la RDC

Par


Travail réalisé et défendu en vue d’obtention

du titre de licencié en science

Groupe : Informatique

Option : Génie-Informatique

Sous la direction de :

MBUYI MUKENDI Eugène

Professeur Ordinaire

Année académique 2010-2011

i

Table de Matières

EPIGRAPHE ................................................................................................................................. IV

DEDICACE ................................................................................................................................... V

REMERCIEMENTS ......................................................................................................................... VI

LISTE DES ABREVIATIONS ............................................................................................................. VIII

LISTE DES FIGURES ........................................................................................................................X

LISTE DES TABLEAUX .................................................................................................................... XII

INTRODUCTION GENERALE ............................................................................................................. 1

CHAPITRE I ................................................................................................................................. 6

LES SYSTEMES DISTRIBUES ............................................................................................................. 7

I. 1. Les Systèmes Distribués ............................................................................................... 7

I.1.1. Définitions .............................................................................................................. 8

I.1.2. Caractéristiques et Objectifs .................................................................................. 8

I.1.3. Système Centralisé VS Système Distribué .............................................................. 9

I.1.4. Propriété d’un Système Distribué ........................................................................ 11

I.1.5. Architecture d’un Système Distribué ................................................................... 14

I.2. Les Bases de Données Réparties (Distribuées) ........................................................... 17

I.2.1. Définitions ............................................................................................................ 17

I.2.2. Buts et motivations pour une Base de Données Distribuée : BDD ...................... 19

I.2.3. Avantages et Contraintes ..................................................................................... 20

I.2.4. La Répartition de données (Les Niveaux) ............................................................. 20

I.2.5. Principe d’une Base de Données Réparties ou Distribuée ................................... 21

I.2.6. Systèmes de Gestion de Base de Données Distribuée (SGBDD) et Architectures 22

I.3. La Réplication .............................................................................................................. 24

I.3.1. Les protocoles de contrôle de réplication ............................................................ 24

I.3.2. Architectures de Réplications .............................................................................. 26

I.4. Fragmentation, Allocation et Conception ................................................................... 29

I.4.2. Allocation .............................................................................................................. 32

I.4.3. Conception ........................................................................................................... 34

CHAPITRE II .............................................................................................................................. 36

LES TRANSACTIONS DISTRIBUEES .................................................................................................. 36

II.1. DEFINITIONS D’UNE TRANSACTION ........................................................................... 36

II.2. CLASSIFICATION DES TRANSACTIONS ........................................................................ 40

II.2.1. Suivant la nature de différentes opérations ....................................................... 40

II.2.2. Suivant la durée ................................................................................................... 41

II.3. MODELES DE TRANSACTIONS ................................................................................... 41

II.3.1. Les Transactions Plates (Flat Transactions) : ....................................................... 41

ii

II.3.2. Les Transactions plates avec Points de Sauvegarde (SAVEPOINTS) : .................. 41

II.3.3. Les Transactions Chainées (Chained Transactions) :........................................... 42

II.3.4. Les Transactions Imbriquées ou Emboitées (Nested Transactions) ................... 42

II.3.5. Transactions Compensatrices ............................................................................. 45

II.3.6. Les Transactions Longues .................................................................................... 46

II.3.7. Les transactions Distribuées ................................................................................ 46

II.4. LA JOURNALISATION ET LA REPRISE DES TRANSACTIONS ......................................... 47

II.4.1. Journalisation ...................................................................................................... 47

II.4.2. Reprise ................................................................................................................. 50

II.5. TRANSACTION DISTRIBUEE ET LE MODELE OSI ......................................................... 51

II.5.1. Le Système Transactionnel .................................................................................. 51

II.5.2. Le Modèle OSI pour les Transactions Distribuées ............................................... 53

II.6. GESTION ET CONTROLE DE CONCURRENCE DE TRANSACTIONS (REPARTIE) ............ 57

II.6.1. La cohérence de données.................................................................................... 58

II.6.2. Concurrence d’accès de données........................................................................ 65

CHAPITRE III ............................................................................................................................. 79

LES APPLICATIONS ...................................................................................................................... 79

III.1. Mécanisme de Répartition sous SQL SERVER ........................................................... 79

III.1.1. SQL SERVER ........................................................................................................ 79

III.1.2. Les Bases de Données ........................................................................................ 79

III.1.3. Services et moteurs ............................................................................................ 80

III.1.3.1. SQL Server .......................................................................................................... 80

III.1.3.2. SQL Server Agent ............................................................................................... 81

III.1.4. Transactions ...................................................................................................... 81

III.1.5. Notion de répartition sous SQL SERVER ............................................................. 82

III.2. Gestion de Transactions par la programmation sous .NET (Framework 3.5) ........... 85

III.2.1. Les Transactions locales .................................................................................... 85

III.2.2. Les Niveaux d’Isolations ..................................................................................... 87

III.2.3. Les Transactions Distribuées .............................................................................. 89

III.3. Intranet Gouvernemental de la RDC (République Démocratique du Congo) .......... 91

III.3.1. Quelques définitions .......................................................................................... 91

III.3.2. Objectif du projet ............................................................................................... 92

III.3.3. Avantages pour les utilisateurs .......................................................................... 92

III.3.4. Situation actuelle de l’Intranet........................................................................... 93

III.4. Mise en place d’un Système d’Information de Traitement de Salaire des Agents de

l’Etat .................................................................................................................................. 95

III.4.1. Circonscription ................................................................................................... 95

III.4.2. Modélisation du Système d’Information avec l’UML ......................................... 96

III.4.2.1. Spécification Initiale du Système ................................................................. 96

III.4.2.2. Enoncé du problème ................................................................................... 97

III.4.2.3. Analyse du Domaine .................................................................................... 98

iii

III.4.2.3.1. Diagramme de Cas d’Utilisation ............................................................... 98

III.4.2.3.2. Diagramme de Classe ............................................................................. 100

III.4.2.3.2. Diagramme d’état ................................................................................... 102

III. 4.2.3.3. Diagrammes d’Activités ......................................................................... 103

III.4.2.4. Conception et Implémentation du Système ............................................. 105

III.4.2.4.1. Schéma Global ........................................................................................ 105

III.4.2.4.2. Fragmentations et Allocations ............................................................... 106

III.4.2.4.3. Réplication .............................................................................................. 107

III.4.2.4.4. Implémentations de l’Application .......................................................... 108

CONCLUSION........................................................................................................................... 138

REFERENCE ............................................................................................................................. 140

iv

Epigraphe

… Un Système de Bases de Données Réparties est

suffisamment complet pour décharger les utilisateurs de

tous les problèmes de concurrence, fiabilité, optimisation

de requêtes ou transactions sur des données gérées par

différents SGBDs sur plusieurs sites. [15]

v

Dédicace

A ma très chère Mère, Denise NTUMBA ;

A mon très cher Père, Denis-Robert KAYEMBA ;

Qui, des manières constantes, ont accolé leurs sacrifices pour parfaire l’œuvre que je

suis. Qu’ils en soient remerciés et trouvent par ici la gratitude de mon cœur sincère ;

A tous les miens : parents, amis et connaissance ;

Que je ne peux énumérer

Je dédie ce travail.


vi

Remerciements

A celui qui garde l’âme et protège le corps ; le Tout-Puissant Dieu qui renouvelle

les forces, nous transmettons nos tout premiers remerciements ; car après nous avoir

gardés tout au long de notre deuxième cycle en force et bonne santé, a bien voulu que

nous l’achevions avec ce présent travail qui le couronne. Merci Seigneur Jésus Christ.

S’il s’est avéré possible de réaliser ce présent travail, c’est grâce au Prof. Eugène

MBUYI MUKENDI qui nous a accepté sous sa direction et son Assistant Hercule KALONJI

KALALA qui l’a poursuivi jusqu’à sa perfection ; qu’ils trouvent à travers ces lignes

l’expression de notre profonde gratitude et de notre respect.

Nos remerciements s’adressent enfin à tout celui qui, d’une manière ou d’une autre, a

participé à la victoire de cette bataille. En voici quelques uns : Jérémie PANGU NKOYI, Théo

MASAMBOMBO MBIYA, etc.


vii

[Les Listes]

viii

Liste des Abréviations

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

ix

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

x

Liste des Figures

Figure 1 : De Centralisé vers Distribué [9] ................................................................................ 10

Figure 2: système distribué avec un middleware [1] [51] ........................................................ 14

Figure 3 : Client-Serveur ........................................................................................................... 15

Figure 4 : Architecture d’une base de données [41] ................................................................ 18

Figure 5 : Architecture d’une BDD............................................................................................ 21

Figure 6 : réplication synchrone ............................................................................................... 24

Figure 7 : réplication asynchrone ............................................................................................. 25

Figure 8 : une transaction dans une base de données cohérente .......................................... 36

Figure 9 : Transaction plates avec SAVEPOINTS [22] ............................................................... 42

Figure 10 : Arbre de Transactions et sous-Transactions ......................................................... 43

Figure 11 : Validation et Abandon de Sous-Transactions ....................................................... 45

Figure 12 : Transactions compensatrices ................................................................................ 46

Figure 13 : L’UNDO d’une mise-à-jour [30]. ............................................................................ 48

Figure 14 : Le REDO d’une mise-à-jour [30]. ........................................................................... 49

Figure 15 : Architecture du système transactionnel [31]......................................................... 51

Figure 16 : Architecture Transactionnelle [46] ........................................................................ 53

Figure 17 : Modèle de Dialogue dans OSI TP ........................................................................... 54

Figure 18 : Arbre de Transactions ............................................................................................ 55

Figure 19 : Les actions du Protocole de Validation en Deux Phases [32] ................................ 60

Figure 20 : Validation normale [15] [22] [40] ........................................................................... 61

Figure 21 : Panne d’un participant avant d’être prêt [15] [22] [40] ........................................ 62

Figure 22 : Panne d’un participant après s’être déclaré prêt [15] [22] [40] ............................ 62

Figure 23 : Panne du coordinateur [15] [40] ............................................................................ 63

Figure 24 : TIME-OUT et panne dans le protocole de validation en trois phases [32] ............ 64

Figure 25 : Exécution non contrôlée des transactions concurrentes ...................................... 65

Figure 26 : Perte d’opérations .................................................................................................. 66

Figure 27 : Ecriture inconsistante ............................................................................................. 67

Figure 28 : Lecture sale ............................................................................................................ 68

Figure 29 : Lecture non-reproductible ..................................................................................... 69

Figure 30 : Le Principe du Verrouillage à deux phases [31] ..................................................... 72

Figure 31 : Le Verrou Mortel (DeadLock) [42].......................................................................... 74

Figure 32 : Cycle dans le Graphe des Attentes ......................................................................... 75

Figure 33 : Réplication peer-to-peer avec trios et quatre nœuds [19] .................................... 83

Figure 34 : Vue de l’architecture de la Réplication transaction [19] ....................................... 83

Figure 35 : Interface de Démarrage du Service de DTC ........................................................... 89

Figure 36 : l’Intranet Gouvernemental [35] ............................................................................. 94

Figure 37 : Diagramme de Cas d’Utilisation ............................................................................. 99

xi

Figure 38 : Diagramme de Classe ........................................................................................... 101

Figure 39 : Diagramme d’état de la classe Agent ................................................................... 102

Figure 40 : Diagramme d’Activité pour l’immatriculation d’un agent ................................... 103

Figure 41 : Diagramme d’Activité pour le calcul et la paie des Agents immatriculés ............ 104

Figure 42 : Diagramme de classe avec toutes les propriétés et les classes association ........ 105

xii

Liste des Tableaux

Tableau 1: Avantages et Désavantages de la combinaison de stratégie ................................. 28

Tableau 2: Compatibilité des Verrous (modes) ........................................................................ 71

Tableau 3 : Compatibilité des Verrous (Opérations) ................................................................ 71

Tableau 4 : Projets Réseaux Gouvernemental par KOICA [35] ................................................ 93

Tableau 5 : Tableau de correspondance de numéro de sites et leurs noms ........................... 95

Tableau 6 : Fragmentations et allocations aux sites .............................................................. 106

xiii

[Introduction Générale]

1

Introduction Générale

Actuellement les besoins d’entreprises et leurs solutions doivent tabler sur

l’infrastructure qui leur est offerte, à savoir les réseaux informatiques de communication, et

aussi pour en profiter de ses avantages, surtout qu’en plus cette infrastructure

correspondrait le mieux possible à l’architecture des entreprises.

Le système d’Information aussi, qui est un apanage pour une entreprise, s’est étendu

sur cette infrastructure en sous systèmes, et par conséquent doit faire collaborer ces

derniers de manière à leur permettre soit de sous-traiter un sous système chez un autre, soit

à permettre plusieurs sous systèmes de pouvoir participer à la réalisation d’un résultat. Ce

type de systèmes s’appelle et sont dits « distribué ou réparti».

Et cette notion de système distribué même, dont la définition est la suivante, une

collection de processus informatiques indépendants qui communiquent mutuellement par

passage de message [27], s’articule sur un seul problème à savoir, la cohérence de données

qui doit être assurée de manière la plus transparente aux utilisateurs.

Dans les Bases de Données Distribuée, comme dans tout autre système distribué, y est

utilisé le concept de la transaction, qui est aussi une voie vers la gestion de la cohérence de

données, vu qu’une transaction a cette propriété d’atomicité qui lui permet d’être défaite ou

validée d’un seul coup lorsque l’ensemble d’opérations qu’elle encapsule ont échoué ou

réussi, afin de laisser les données si pas dans un état de cohérence précédent, mais de les

faire passer dans un autre état de cohérence.

La concurrence aussi, il faut le signaler, même si elle fait partir des objectifs pour

lesquels on construirait un système distribué, reste aussi une cause d’incohérence de

données dans ce dernier. De fait, elle nécessite une bonne gestion ; pour aussi garantir la

cohérence ; le concept de transaction le fait aussi bien, de par sa propriété d’Isolation. D’où,

on parle des transactions concurrentes, ce qui est même l’objet principal de ce présent

travail.

Pour mener à bonne fin notre travail qui s’articule sur l’Intranet Gouvernemental (e-

Gouvernement), nous y avons ciblé un problème très récurrent que nous formulons de la

manière suivante, Mise en place d’un Système d’Information (Automatisé) de Traitement

de Salaire des Agents de l’Etat.

2

Pour que l’Etat ou le Gouvernement salarie un agent, ce dernier doit de prime abord

être immatriculé. Sachant que c’est chaque institution de l’Etat ou l’entreprise elle-même

qui gère ses employé (ses ressources humaines), c'est-à-dire elle organise le

recrutement, mais pour la prise des fonctions, c’est la fonction publique qui attribue les

matricules. Or ces opérations, manuelles soient-elle et faisant intervenir deux sites distants,

exigent souvent beaucoup de déplacements pour acheminer les dossiers et passer toutes les

étapes pour aboutir à un agent immatriculé. Chose qui fait perdre terriblement du temps.

Après immatriculation des agents, la Fonction Publique, qui est l’entité habilitée à

gérer la ressource humaine de l’Etat, est censée connaitre l’effectif de tous les agents de

l’Etat. Or, étant donné que le processus d’immatriculation prend assez de temps, et qu’en

plus puisque c’est manuel, il peut favoriser de cas des agents fictifs ; cette tache peut donc

devenir un peu pénible et erroné.

Venons-en maintenant au problème de salaire ; si l’immatriculation dure aussi

longtemps, on risque d’avoir une situation telle que, un agent en attente de son matricule

peut commencer déjà à travailler au sein de l’entreprise mais sans salaire de la part de l’Etat.

Et aussi si savoir l’effectif des agents est aussi un problème et favorise la présence des

agents fictifs, c’est l’Etat qui va perdre. De fait, le Ministère de la Finance, l’Entité qui calcule

et paie (ou calcule la masse salariale) les agents doit avoir une liste des agents immatriculé

de sorte à ne payer que ceux-là. C’est pour ça que la Fonction Publique édite les

immatriculés et en envoie la liste à la Finance.

Pour maintenant rémunérer ces agents, leurs entreprises respectives participent aussi

dans le calcul, même si c’est la Finance qui paie (ou calcule le salaire). Et alors, calculer le

salaire d’un agent, c’est aussi une tache très délicate, qui nécessite une bonne attention, car

son calcul inclut beaucoup d’autres éléments tels que, les indemnités, la prime, le salaire de

base, les retenues, le prêt, etc., et le faire à la main peut probablement glisser des erreurs.

D’où, un besoin incessant de l’informatisation de processus, afin de pouvoir régulariser

pas mal des choses, à savoir l’immatriculation et la paie, au-delà de certains contrôles

physiques qui doivent toujours être maintenus.

Mettre une moindre transparence dans la gestion des ressources humaines de l’Etat,

chose qui est un volet non négligeable dans la gestion de la RDC, de sorte à assouplir

tant les processus d’immatriculation que ceux de la paie des agents, de sorte aussi à

permettre que les agents et l’Etat se retrouvent tous, et de sorte enfin si pas à contourner le

problème des agents fictifs, mais à l’amoindrir. L’informatique donc, s’avère un outil

incontournable, permettant ainsi d’éviter trop de temps d’attente, trop de déplacement,

trop de formulaires et donc de paperasses dans l’administration de l’Etat.

3

Donc la transparence, la souplesse, et la simplification de procédures, sont des intérêts

que poursuit ce travail.

Pour ce faire, nous allons mettre sur pied une solution informatique, sous un modèle

d’un système distribué, en exploitant plus précisément les Bases de Données Réparties

(BDR), puisque c’est le modèle qui s’accorde le plus à la situation, étant donné qu’elle fait

intervenir plusieurs sites distants et qu’en plus puisque déjà un bon nombre de sites sont

reliés dans le réseau de l’Intranet Gouvernemental.

Et dans les BDRs, nous nous nicherons sur l’utilisation des transactions, puisque ces

dernières, de par leurs propriété, offrent un bon nombre d’avantages, tels que, de gardre les

données de la base de données toujours cohérente, et si elles en venaient d’être dans une

situation de concurrence, elles s’en sortent toujours bien de par la possibilité qu’elles ont

d’être isolée, c'est-à-dire de permettre ou pas l’accès des autres transactions dans la lecture

ou l’écriture des ressources qu’elles utilisent, et bien plus que tout, grâce au journal de

transactions, qui permet d’archiver toutes les opérations effectuées sur la base. Les

transactions donnent donc cette possibilité de pouvoir retracer les opérations.

Certes, il existe nombreuses entreprises de l’Etat. Certes, il existe un bon nombre de

sites déjà relié dans le réseau de l’Intranet Gouvernemental.

Pourtant, pour des raisons de temps et de coût, de concision et de précision de

l’Application ici présentée comme solution informatique, nous n’avons pris en compte

que trois sites dont deux sont très stratégiques et indispensables à savoir, la Fonction

Publique pour l’immatriculation, et la Finance pour le calcul et la paie des agents, et un

troisième site qu’est la Primature pour illustrer le cas des entreprises ou institutions qui

participent passivement dans la rémunération des agents de l’Etat. Il faut signaler alors que

les deux sites sont aussi illustrés par le troisième site, étant donné qu’ils sont des institutions

avec des agents à gérer. Nous nous sommes aussi limités seulement aux éléments du salaire

cités ci haut.

Ainsi, grâce aux techniques de récolte de données suivantes, questionnaires (enquêtes)

et documentation, nous avons pu rassembler des informations nécessaires au montage de

notre Système d’Information.

4

Voici donc alors comment l’organisation du travail se présente :

Le travail est organisé en trois (3) chapitres :

- Le premier chapitre, intitulé Les Systèmes Distribué, donne un aperçu très

clair du domaine dont nous traitons, introduisant ainsi de manière nette, simple et

claire les concepts théoriques de base à utiliser dans la suite du travail, tels que la

réplication et les bases de données réparties.

Voici donc ses points chauds :

Les Systèmes Distribués

Les Bases de Données Répartie (BDR)

La Réplication

Conception, Fragmentation et Allocation d’une BDR

- Le deuxième chapitre, intitulé Les Transactions Distribuées, montre le bien

fondé de l’utilisation des transactions et de leur gestion, en parlant de différents

problèmes liés aux transactions concurrentes et leurs solutions.


Définitions d’une Transaction

Classification des Transactions

Modèles de Transactions

La Journalisation et la Reprise des Transactions

Transaction distribuée et le Modèle OSI

Gestion et Contrôle de Concurrence de transactions (Répartie)

Et enfin,

- Le troisième chapitre, intitulé Les Applications, c’est ici que nous nous

sommes évertués pour rattraper si pas toutes mais une grande partie de théories

avancées précédemment, dans les outils informatiques utilisés pour mettre en place

une application (répartie) informatique que nous avons nommée « SalaryManager »,

un logiciel de traitement et de calcul de salaire des agents de l’Etat au sein de

l’Intranet gouvernemental (e-Gouvernement), allant de l’immatriculation des agents

jusque et y compris le traitement de leur salaire.

5


Mécanisme de Répartition sous SQL SERVER 2008

Gestion de Transactions par la programmation sous .NET

(Framework 3.5)

Intranet Gouvernemental de la RDC (République Démocratique

du Congo)

Mise en place d’un Système d’Information (Automatisé) de

Traitement de Salaire des Agents de l’Etat (SalaryManager)

6

[Chapitre I]

7

Chapitre I

Les Systèmes Distribués

Les réseaux informatiques, qu’est une interconnexion des équipements informatiques,

offrent aux entreprises toute une panoplie des avantages, parmi lesquels ceux qui sont

beaucoup plus à l’intention de ce travail on a, l’échange et partage des données

informatiques et l’accès à des bases de données réparties ou distribuées, aussi bien qu’on le

sache que le partage est l’objectif premier de Réseaux Informatiques [48].

Et à l’apparition de ce réseau, sont nés et y sont déployés des systèmes dits distribués,

l’exploitant pour arriver à leurs propres fins. Ces derniers sont soit des bases de données

distribuées sur ce réseau soit des applications interagissant avec ces bases de données,

spécifiquement pour le cas qui nous concerne.

C’est comme ça que, nous allons commencer par esquisser sur les systèmes distribués

avant de nous plonger de manière la plus détaillée possible sur les bases de données

distribuées.

I. 1. Les Systèmes Distribués

Nous allons commencer par élucider mais, en éludant toute confusion, la différence ou

mieux la ressemblance entre le terme « distribué » et « répartie ».

Le terme « distribué » vient du terme anglais « distributed » ayant comme idée d’une

distribution des tâches réalisées par un coordinateur, pendant que « répartie » suppose une

coopération des tâches en vue de la répartition du travail, et pourtant dans la littérature

anglaise on ne reconnait pas cette différence puisque dans le terme « distributed System »

distributed signifie : « réparti dans l’espace » [10].

De fait, il n’y a donc aucune différence entre Système Distribué et Système Réparti, ou

bien, entre Distribué et Réparti dans le reste du travail.

Par contre au niveau de la Base de Données, [15] montre une certaine nuance

montrant que quand on parle d’une Base de Données Distribuée (BDD), c’est un terme tout

à fait générique et que de ce fait une Base de Données Répartie (BDR) n’est qu’un cas de

BDD, au même titre que les BDs fédérées, les sytèmes multi BD, etc. Nous en parlons dans la

partie y consacrée.

8

I.1.1. Définitions

"Un système réparti est un ensemble de machines autonomes connectées par un

réseau, et équipées d'un logiciel dédié à la coordination des activités du système ainsi qu'au

partage de ses ressources." Coulouris et al. [18].

"Un système réparti est un ensemble d’ordinateurs (ou processus) indépendants qui

apparaît à un utilisateur comme un seul système cohérent". Tanenbaum [7] [25].

"Un système informatique distribué est une collection de processus informatiques

indépendants qui communiquent mutuellement par passage des messages" [27].

Force est de constater, que ces définitions ci-haut données ne se contredisent pas

mais, bien au contraire chacune d’elle définit une idée, qui mise ensemble donne une idée

claire et globale de ce qu’est un Système Distribué.

Aussi, nous en avons pu retenir deux concepts très importants, (i) indépendant, de par

la définition de [7], c'est-à-dire que les ordinateurs ont architecturalement cette capacité de

travailler indépendamment, (ii) le logiciel, de la première définition mais complété par la

deuxième, qui permet à cet ensemble d’ordinateurs de paraître à l’utilisateur comme un

seul.

Cette dernière notion est connue sous le nom d’Image unique du système [18] [43].

Et cette notion d’Image unique du système, fragilise un peu le système à tel enseigne

qu’il ne suffit qu’une simple panne d’un ordinateur, cela peut impacter négativement sur le

bon fonctionnement du système et voire amener à des incohérences.

Leslie Lamport l’a bien dit lorsque définissant un système distribué : "un système qui

vous empêche de travailler si une machine dont vous n’avez jamais entendu parler tombe en

panne" [27] [25].

I.1.2. Caractéristiques et Objectifs

Voici les objectifs pour lesquels on construirait un système distribué, qui font office

directement des caractéristiques de ce dernier :

Le partage des ressources :

Toutes les ressources tant hardware (ordinateurs, organes d’entrée-sortie,

processeurs spécialisés, dispositifs de commande ou de mesure, etc.) que software

sont partagé entre les entités du système.

9

L’ouverture :

Les composants et les logiciels utilisés au sein de ce système peuvent provenir de

différents fournisseurs et travailler sans aucun problème.

La concurrence :

Le traitement concurrent augmente la performance du système.

La grande échelle (ou scalability : en anglais)

C’est la capacité d’un système de ne pas dysfonctionner lorsque sa taille s’accroît, ou

lorsque des nouvelles ressources sont ajoutées.

La tolérance à la faute :

C’est la capacité qu’un système continue de fonctionner malgré quelque défaillance

partielle des composants ou du réseau de communication.

I.1.3. Système Centralisé VS Système Distribué

Le Système Distribué, ne présenterait-il que des avantages ci-haut présentés en termes

d’objectifs ? Et pourtant, un peu ci-haut on a montré un petit problème lié à la notion

d’Image unique. Qu’on le sache, il a des problèmes ou désavantages dont nous allons parler

dans la suite. De plus, par définition, les systèmes distribués sont plus vulnérables que les

systèmes centralisés, car le nombre de points susceptibles d'être attaqués est plus

important, en plus de la faiblesse des réseaux rendus nécessaires par la répartition.

A la différence du système distribué, le système centralisé est celui qui travaille et se

base sur une seule et même machine, tout y est localisé et accessible par des programme. Ce

système est aussi bien illustré par un « mainframe », où il peut y avoir un ou plusieurs CPU

(Central Processing Unit) et les utilisateurs qui communiquent directement avec lui via des

terminaux.

Le seul vrai problème avec ce système, c’est qu’il n’est pas scalable (expansible) [43], il

y a une limitation par rapport au nombre de CPUs à tel enseigne qu’il faut le mettre à jour ou

carrément le remplacé lorsqu’il faut ajouter un CPU.

De par les avantages et objectifs du système distribué, on peut sans aucun effort voir

le pourquoi de ce passage.

10

Et pourtant ce passage amène aussi des nouveaux problèmes tels que la localisation, la

transparence, l’interopérabilité, etc. qui sont pris aux titres des défis, auxquels le système

distribué doit faire face.

Conception d’un système distribué

La conception peut se faire de deux manières, [13], matérielle et logicielle.

Conception matérielle

Elle peut se réaliser sur :

+ Machine multiprocesseurs avec mémoire partagée

+ Cluster (grappe) d’ordinateur dédié au calcul/traitement massif parallèle

+ Ordinateurs standards connecté en réseau.

Conception logicielle

+ Le système logiciel ici, est composé de plusieurs entités disséminé dans un réseau,

s’exécutant indépendamment et parallèlement.

Appelé

Appelant

Souche

Appelant

Squelett

e

Appelé

Réseaux

Centralisé Distribué Figure 1 : De Centralisé vers Distribué [9]

11

I.1.4. Propriété d’un Système Distribué

Les défis tantôt dits sont ici présentés comme des propriétés que doit assurer un

système distribué. Nous allons pour notre compte ne présenter que celles qui sont beaucoup

plus inhérentes à notre travail :

La Transparence :

Contrairement à ce que laisse entendre naturellement ce vocable, elle veut plutôt ici

dire que, tous les détails techniques et organisationnels, complexes du système distribué

sont cachés à l’utilisateur.

Le but de la transparence est de permettre une manipulation des services distants plus

facilement, c'est-à-dire, comme des services locaux [27], sans avoir besoin de connaître sa

localisation ou son détail techniques des ressources [25].

Cette propriété fait alors maximiser la scalabilité et la flexibilité du système, simplifie le

développement des applications et leur maintenance évolutive et corrective.

La norme (ISO, 1995), classifie la transparence sous plusieurs niveaux [18] [25] [27]:

- Accès : il y a pas d’accès spécifique pour des ressources ; l’accès à une ressource tant

distante que locale est identique.

- Concurrence : l’utilisateur du système ne doit pas savoir que telle ou telle autre

ressource peut être partagée ou utilisée simultanément par d’autres utilisateurs.

- Extension (des ressources) : s’il faut étendre ou réduire le système, il ne faudra pas

que l’utilisateur en soit gêné (sauf la performance [18]).

- Hétérogénéité : il doit être caché à l’utilisateur les différences matérielles ou

logicielles des ressources qu’il utilise. La notion d’interopérabilité.

- Localisation : il n’est nullement besoin de savoir l’emplacement d’une ressource du

système pour y accéder. Ceci donne lieu à la transparence de migration [18].

- Migration : le déplacement d’une ressource peut se faire, mais sans qu’on ne s’en

plaigne, car rien ne sera aperçu.

- Panne : lorsqu’il y a panne (réseaux, machines, logiciels) au niveau d’un nœud du

système, l’utilisateur ne doit pas le savoir.

12

- Relocalisation ou Mobilité : une ressource peut changer d’emplacement pendant

qu’elle est utilisée, mais sans qu’on s’en rende compte.

- Réplication : l’utilisateur du système n’a pas besoin de savoir que telle ressource est

dupliquée.

De manière la plus évidente, on voit qu’on peut assurer une transparence totale, et

pourtant il est très difficile et voire impossible de masquer toutes les pannes des ressources.

La Disponibilité

Il existe beaucoup de causes à l’origine de l’indisponibilité d’un système, mais voici

celles que nous notons ici selon [25] :

- Des pannes empêchant au système ou à ses composants de fonctionner

conformément à la spécification ;

- Des surcharges dues à des sollicitations excessives d’une ressource ; la congestion et

la dégradation des performances du système s’en suivent certainement.

- Des attaques de sécurité pouvant causer des dysfonctionnements, voire l’arrêt du

système, des pertes et incohérence de données.

Pour ne citer que ça.

Mais puisque dire « disponibilité » sous-entend que le système doit toujours être à

mesure de délivrer correctement les services et ce conformément à la spécification ; mais il

faut savoir que les pannes ou toute autres tentatives (ci-haut citées) vont toujours essayer

de compromettre le bon fonctionnement du système ; pour ce, il faut le rendre capable de

rester disponible.

Parmi les solutions retenues pour y remédier [25], nous avons choisi de ne parler que

de celle qui va beaucoup plus avec notre travail :

La réplication ; cette technique est utilisé pour pallier à la première (panne) et deuxième

(surcharge) cause d’indisponibilité. Ici, les copies d’une même ressource peuvent se trouver

en même temps dans des emplacements différents. Ainsi, lorsqu’une ressource tombe en

panne, le traitement qu’elle effectuait est déplacé sur une autre ressource disponible. Pour

ce qui est de la surcharge, au lieu que des sollicitations se fassent sur une même et seule

ressource, elles se font parallèlement sur chacune de ses copies (réplique) partout ailleurs.

13

L’Autonomie

Puisque les systèmes existants ou les applications existantes sont souvent difficiles à

remplacer ou à réécrire, logiquement par ce qu’ils sont bien expérimentés et ont une

expertise ; quand on a besoin de les adapter à un autre besoin qui n’y est pas supporté.

Voici donc la bonne motivation parmi tant d’autres de l’autonomie ; un système ou un

composant est dit autonome si son fonctionnement et son intégration dans un système

existant n’exige pas de modifications ni à lui ni à ce dernier.

L’autonomie des composants d’un système favorise par conséquent l’adaptabilité,

l’extensibilité et la réutilisation de ressources de ce système.

Les Intergiciels : Middlewares

Pour compléter à l’autonomie d’un système, on peut aussi intégrer des intergiciels. Un

intergiciel (middleware, en anglais) est un assemblage des fonctionnalités, nouvelles,

formant un logiciel intermédiaire entre deux applications ou système. Il est demandé qu’un

tel logiciel ne soit pas générique mais plutôt spécifique, et cela pour éviter la surcharge qui

est un handicap pour la disponibilité.

- Les objectifs d’un Middleware

Les trois objectifs d’un middleware sont les suivants [1] [51]:

(1) masquer la complexité de l'infrastructure sous-jacente, donc l’hétérogénéité des machines

et systèmes ;

(2) Faciliter la conception, le développement et le déploiement d'applications réparties :

masquer la répartition des traitements et des données.

(3) Fournir des services communs : une interface commode aux applications (programmation

+ API : Application Programming Interface).

14

Site 1 Site 2

Applications

Middleware

Système de

communication

Interfaces

Figure 2: système distribué avec un middleware [1] [51]

Note : Le système de communication permet aux éléments des sites du système distribué

d’échanger des informations entre eux.

Exemples des Intergiciels :

- Java RMI (Remote Method Invocation), CORBA (Common Object Request Broker

Architecture), .NET [-Orienté Objet-]

- JTS (Java Transaction Service) de Sun, MTS (Microsoft Transaction Server) de

Microsoft [-Orientés Transactionnels-]

- Web Services (XML-RPC: Extensible Markup Language-Remote Procedure Call, SOAP:

Simple Object Access Protocol) [-Orientés Web-]

- ODBC (Open DataBase Connectivity), JDBC (Java DBC) de SUN [-Orientés SGBD/SQL-]

Nous n’avons parlé que de ces trois propriétés comme tantôt dit, mais puisqu’en plus

elles entrent beaucoup plus enjeu dans la suite de notre travail. Dans cette liste, se figure

aussi la grande-échelle, c'est-à-dire le passage à l’échelle, c'est-à-dire la « scalability »

(comme définit ci-haut).

I.1.5. Architecture d’un Système Distribué

Quasiment anticipé, l’architecture d’un système distribué est l’agencement ou mieux

la structure des composants constitutifs de ce dernier en termes de logiciels, matériels et

réseaux. Voici ces architectures en question [27]: Client-serveur (C/S), Peer-to-Peer ou Pair-

à-Pair (P2P) et Hybride ; ce dernière est une combinaison du modèle client/serveur et du

modèle Peer.

15

Le Client-serveur : C/S

[Définition]

Le concept client-serveur, c’est pour définir une architecture. Et donc, l’architecture

client-serveur est un modèle de fonctionnement logiciel qui peut se réaliser sur tout type

d’architecture matérielle (petite et grosse machine) pourvu que ces architectures soient

interconnectées. Et là, nous avons deux types de logiciels, le logiciel client qui formule des

requêtes à un autre, et cet autre c’est le logiciel serveur, et les deux s’exécutant

normalement sur deux machines différentes.

Les deux applications dialoguent ou communiquent entre elles, de la manière

suivante :

- Le client demande un service au serveur

- Et le serveur réalise le service, c'est-à-dire, le traitement et le renvoie au client

Client SERVEURRequête

Résultat

Dialogue

Figure 3 : Client-Serveur

C’est le client qui initie le dialogue et le pilote, pendant que le serveur y participe tout

simplement. Et pour dialoguer ou communiquer, ils ont besoin de protocole de

communication.

[Mode de Client-serveur]

- Couches dans le Client

Le modèle client-serveur possède trois couches, dont on a [11]:

+ Couche présentation : qui s’occupe du dialogue entre la machine et

l’utilisateur.

+ Couche applicative : qui réalise des tâches pour produire de résultat escompté.

+ Couche de données : qui gère les données.

16

- Modes ou types ou modèles

Et par rapport à la répartition de ces couches entre serveur et client, on distingue trois

types ou modes client-serveur :

+ Client-serveur de présentation :

Le client ne possède que la couche présentation en son sein et le serveur en

possède soit toutes soit deux restantes.

+ Client-serveur de données :

Le client effectue la gestion du dialogue, la validation des saisies, la mise en

forme des résultats et les traitements (y compris la manipulation des

données). Le serveur gère l'accès aux données et de plus en plus souvent

l'intégrité des données. Il est appelé serveur de données.

Cette mise en œuvre est très répandue car elle a été popularisée par les

SGBDs relationnels qui ont reposé dès leur origine sur le modèle

client/serveur pour ce qui est de leur fonctionnement réparti.

Exemple : Application C# Avec SQL SERVER.

+ Client-serveur de traitements :

Ce type est également qualifié de traitement distribué (ou client-serveur de

procédure [14]). Le client appelle l’exécution d’un traitement stocké sur le

serveur qui effectue les traitements et renvoie les données au client.

On peut également répartir les données sur le poste client ou d’autres serveurs

de données en utilisant un SGBD supportant cette fonctionnalité. Dans ce

cas on effectue de la gestion distribuée de données (bases de données

réparties ou répliquées).

Peer-to-Peer ou Pair-à-Pair : P2P

Cette architecture offre à un système la capacité de passage à l’échelle (scalability),

c'est-à-dire la capacité d’un système à continuer à délivrer avec un temps de réponse

constant un service même si le nombre de clients (nœuds) ou de données augmente de

manière importante [25] [36], afin de partager les ressources dans un réseau largement

distribué. L’avantage de cette architecture est celui de disposer toujours d’une puissance de

calcul, quand bien même le nombre de ressources disponibles dans le système est élevé. Et

cet avantage lui permet de traiter des taches complexes avec un coût relativement faible,

même sans avoir des serveurs gigantesque [36].

17

Dans cette architecture, un nœud peut donc jouer le rôle de client selon qu’il

consomme des ressources disponibles et serveur selon qu’il offre des ressources.

Une autre définition, qui explicite aussi les choses, c’est celle donnée par [34] [36] : «

Le terme "pair-à-pair" représente une classe de systèmes et d’applications qui utilisent des

ressources distribuées afin d’atteindre un objectif précis d’une façon décentralisée. Les

ressources incluent puissance de calcul, données (stockage et contenu), bande passante

et disponibilité (ordinateurs, être humaine ou autres ressources). L’objectif peut

être la répartition de calcul, le partage de données/contenu, la communication et la

collaboration ou le partage des services d’une plateforme. La décentralisation peut être

appliquée sur les algorithmes, les données et les métadonnées ».

I.2. Les Bases de Données Réparties (Distribuées)

Il y a des notions qui ont déjà été expliquées dans la section précédente, et quand

nous les réciterons ici nous n’aurons que la peine de rappeler qu’elles l’ont déjà été

précédemment.

I.2.1. Définitions

- Base de données : BD

Une base de données, de la manière la plus brève possible, c’est une collection des

données structurée reliées par des relations et interrogeable et modifiable par son contenu.

- Base de données répartie (distribuée):BDR ou BDD

Une base de données distribuée, c’est une collection de multiples bases de données

logiquement interconnectées distribuées ou réparties sur un réseau d’ordinateur [24], et

apparaissant à l’utilisateur comme une base de données unique [15].

18

Réseau de Communications

Site 1BD

Site 2BD

Site 3BD

Site 4BD

Site 5

BD

Figure 4 : Architecture d’une base de données [41]

- Système de Gestion de Base de Données : SGBD

Un SGBD est un logiciel informatique permettant aux utilisateurs de structurer,

d’insérer, de modifier, de rechercher de manière efficace des données spécifiques, au sein

d’une grande quantité d’informations, stockées sur mémoires secondaires partagée de

manière transparente par plusieurs utilisateurs.

- Système de Gestion de Base de Données Réparti (Distribué): SGBDR ou SGBDD

Un SGBDD est le logiciel qui gère les BDD, et fournit un mécanisme d’accès qui rend

cette distribution ou répartition transparente à l’utilisateur.

- Système de Bases de Données Distribuées : SBDD

Un SBDD est l’intégration de BDD et SGBDD, laquelle est réalisée à travers le

fusionnement de la BD et les technologies du réseau ensemble [24].

Ceci peut aussi être décrit comme un système qui coordonne une collection de

machines qui n’ont qu’une mémoire partagée (shared memory), cependant paraissant à

l’utilisateur comme une seule machine.

19

- Les concepts « distribué » et « répartie » dans les Base de Données

Le concept « distribué » est très générique et implique beaucoup d’autre [15], tels que

les BD Répartie, les BD fédérées, les Systèmes Multi bases, etc.

Les BD Réparties, par exemple, peuvent être soit hétérogène soit

homogène ;

Les BD Fédérées, ne sont par contre que des BD hétérogènes, mais dont

l’accès est via une seule vue ;

Et les Système Multi bases, sont des bases de données hétérogènes

capables d’inter opérer avec une application via un langage commun,

sans une vue commune.

I.2.2. Buts et motivations pour une Base de Données Distribuée :

BDD

Il faut dire, vu ce qui précède, que la décentralisation a eu sa bonne raison de

transcender la centralisation de par sa valeur ajoutée, mais aussi puisque cette architecture

est la plus adaptée à beaucoup d’organisations des entreprises.

Les BDDs ont donc pour motivation [6]: l’amélioration de la performance du système,

l’augmentation de la disponibilité de données, le partage, le passage à l’échelle (scalability)

et l’accès facile. Nous en parlons en détail pour quelques-uns.

On a, donc :

(1) La nature intrinsèque des certaines situations ou applications. L’exemple d’une

banque qui a une direction centrale à un lieu donné, des succursales dans différentes

autres lieux qui peuvent traiter les données des clients locaux, par rapport au lieu,

mais contrôlés par la centrale. Il est évident qu’une base de données distribué dans

différents site, est appropriée.

(2) La fiabilité et la disponibilité. La fiabilité révèle cette nature d’assurer les services

attendus continuellement ; et la disponibilité, comme dit tantôt, est un élément

important pour accroître la fiabilité.

(3) Meilleure performance : la répartition de données permet souvent la réplication de

celles-ci, or nous avons précédemment dit que cette notion de réplication

assouplissait le trafic à tel enseigne que les sollicitations sur une ressource ou une

donnée étaient parallélisées.

20

I.2.3. Avantages et Contraintes

Voici quelques avantages retenus d’une base de données répartie, on a :

(1) Le rapprochement des données selon qu’un site les demande plus, ce qui permet la

réduction de coût de communication.

(2) L’autonomie de site local ; un site n’a pas besoin d’aller chercher ailleurs les données

qu’il possède lorsqu’un utilisateur demande au site certaines données.

(3) La continuité de services.

(4) Une intégration facile dans un système existant.

Nous en retenons qu’une seule contrainte que nous jugeons de pertinente, c’est la

complexité, qui se situe dans la conception d’une base de données distribuée par rapport à

celle qui est centralisée ; à savoir que cette conception prend en compte la fragmentation

des données, l’allocation des fragments dans des sites et la réplication.

[Contraintes]

- Coût : la distribution de données entraîne des coûts supplémentaires en

terme de communication, et en gestion des communications (hardware et

software à installer pour gérer les communications et la distribution).

- Problème de concurrence. Qui est même le cas traité dans ce travail.

- Sécurité : la sécurité est un problème plus complexe dans le cas des bases de

données réparties que dans le cas des bases de données centralisées.

I.2.4. La Répartition de données (Les Niveaux)

Nous distinguons trois niveaux dans lesquels la répartition de données intervient. Nous

allons présenter l’architecture (de niveau ou de schémas) de la BDR, à l’aide de laquelle,

nous allons expliquer la répartition.

21

Figure 5 : Architecture d’une BDD

Note : VE= Vue Externe.

La répartition d'une base de donnée intervient dans les trois niveaux de son

architecture en plus de la répartition physique des données :

- Niveau externe: les vues sont distribuées sur les sites utilisateurs.

- Niveau conceptuel: le schéma conceptuel des données est associé, par

l'intermédiaire du schéma de répartition (lui-même décomposé en un schéma de

fragmentation et un schéma d'allocation), aux schémas locaux qui sont

réparties sur plusieurs sites, les sites physiques.

- Niveau interne: le schéma interne global n'a pas d'existence réelle mais fait place à

des schémas internes locaux répartis sur différents sites.

I.2.5. Principe d’une Base de Données Réparties ou Distribuée

Le principal fondamental de BDD est la transparence pour l’utilisateur [15], mais que

[41] présente, de manière la plus détaillée, sous forme de niveaux de transparence (pour la

gestion de la BDD). Et nous en avons ci-haut montré ses apports.

Dans une BDD, la transparence s’exprime sous trois niveaux : - transparence de

distribution ou de réseaux, - de réplication et - de fragmentation.

22

- Transparence de distribution ou de réseaux :

Cette transparence renferme deux autres concepts : la transparence de localisation et la

transparence de désignation (naming transparency).

+ De localisation : Le système s’occupe de trouver le site où sont hébergées

les données demandées par l’utilisateur, et pourtant ce dernier n’en sait

rien et lance sa requête comme sur une seule et unique base de données.

+ De désignation : elle implique qu’une fois qu’un objet dans le système est

nommé, il peut être accédé, sans aucune ambigüité et sans aucune autre

spécification que ce nom.

- Transparence de réplication :

Une BDD a souvent des données répliquées dans d’autres sites, et ceci pour accroître une

certaine disponibilité, la performance, et la fiabilité. Alors cette transparence va masquer

cette situation de choses à l’utilisateur.

- Transparence de fragmentation:

La fragmentation est cette technique qui permet de distribuer les données dans tout le

système. Nous allons dans la suite montrer qu’il en existe deux sortes : verticale et

horizontale. Mais la transparence de fragmentation fera que l’utilisateur ne soit au courant

ni de la fragmentation de donné, ni de l’existence de fragments. Ainsi, lorsque l’utilisateur

lance requête (globale), le système s’occupera de la transformer en plusieurs requêtes de

fragment.

I.2.6. Systèmes de Gestion de Base de Données Distribuée (SGBDD)

et Architectures

Il existe plusieurs SGBDD, qui puissent être différents les uns des autres, et eux tous

ont un point que voici en commun [41]: les données et les logiciel sont distribués sur

plusieurs sites interconnectés dans une forme de réseau de communication.

Et pourtant, nous allons présenter dans cette section un seul facteur, qui est vraiment

inhérent à notre travail, qui différencie des SGBDDs, c’est l’Homogénéité.

[Homogénéité]

Quand on parle du degré d’Homogénéité de logiciel de SGBDD, il y a deux facteurs

reliés à ce problème de degré :

23

o [-Facteur 1-]

Si tous les serveurs (ou les SGBDDs locaux individuels) utilisent un logiciel identique et

que tous les utilisateurs (clients) utilisent aussi un logiciel identique, alors le SGBDD est dit

Homogène. Sinon, il est dit Hétérogène.

o [-Facteur 2-]

Un autre facteur relatif au degré d’Homogénéité, c’est le degré d’autonomie locale.

On parle d’un degré d’autonomie si les transactions locales peuvent avoir un accès

direct au serveur. Par contre, si le site local n’a pas de provision lui permettant de

fonctionner en tant qu’un SGBDD indépendant, alors le système ne possède pas

d’autonomie locale.

[Architecture]

Les SGBDDs peuvent avoir plusieurs architectures, qui sont classées selon différentes

approches de séparation de fonctionalité sur les processus (traitements) de SGBD. Nous

allons, ici, présenter deux architectures [41]: Client-serveur et serveur collaboratif

(collaborating server).

o [-Client-serveur-]

Nous en avons déjà parlé ci-haut ; ce système a un ou plusieurs processus client et

serveur. Et un processus client peut envoyer une requête à l’un des processus serveurs. Les

clients sont chargés de l’interface utilisateur et peuvent tourner dans un PC (personal

computer) et envoyer des requêtes à un serveur, qui, lui, gère les données et exécute les

transactions.

o [-Serveur Collaboratif-]

L’idée dans ce genre de système, c’est qu’on peut avoir une collection des serveurs de

bases de données, et chacun étant capable d’exécuter les transactions sur les données

locales, mais aussi qui exécutent les transactions coopérativement sur plusieurs serveurs.

Un serveur qui reçoit une requête accédant sur plus d’un serveur, il en produit des

sous-requêtes pour chaque serveur et à la fin rassemble les résultats à la requête du début.

Ce découpage (décomposition) de requêtes en sous-requêtes se fait par optimisation [15].

24

I.3. La Réplication

Nous pouvons en retenir qu’elle augmente la performance, en diminuant la charge qui

devrait être imposée à un seul site (serveur) par la duplication de données, de favoriser la

disponibilité en cas de pannes par exemple, toujours par la duplication de données dans

différents sites, cette dernière permet donc de travailler avec les données d’un site si un

autre tombe en panne ou dans le souci de diminuer le temps de réponse des transactions.

Mais, il faut tout de suite le signaler qu’elle n’a pas que les bons côtés ; pour ce qui est

de ses inconvénients, c’est le problème de mise-à-jour. Les données dupliquées doivent

donc être uniforme ; de fait, une mise-à-jour sur un fragment de données ne doit pas laisser

les autres indifférents et différents, et pourtant cette mise-à-jours et sa synchronisation ne

sont pas immédiates. On peut donc constater que malgré tout, l’utilisation de la réplication

exige de nous une certaine vigilance par rapport à la cohérence de la base. Car, En effet,

permettre aux transactions de manipuler plusieurs copies d’une même donnée peut générer

des incohérences [5].

Il faut donc faire le contrôle de la réplication, pour assurer la cohérence de la base.

I.3.1. Les protocoles de contrôle de réplication

On distingue deux principaux modèles pour ces protocoles (techniques) [5] :

- Le modèle de réplication synchrone :

Une transaction doit se synchroniser avec toutes les copies qu’elle modifie avant

validation.

C'est-à-dire qu’une modification d’une donnée dans un site entraîne celles de ses

copies dans d’autres. C’est la mise à jour temps réel de données.

Figure 6 : réplication synchrone

La technologie appliquée ici, c’est celle de la validation à deux phases. Avec son

avantage de rassurer la convergence de tous les sites au COMMIT ou ABORT. Et Ceci,

rappelons-le, rassurera autant la cohérence de la base.

25

* Les avantages et les désavantages

+ Avantage :

Identité de copies (pas d’incohérence)

La lecture (locale) de la dernière copie la plus mise à jour

Les modifications sont atomiques, c'est-à-dire, soit ils ont lieu eux-

toutes à la fois, soit rien.

+ Désavantage :

Une exécution très longue de la transaction, vue que celle doit faire

les mises à jour de tous les sites, et ceci crée souvent de TIMEOUT

(voir dans le chapitre suivant)

- Le modèle de réplication asynchrone :

Les modifications introduites par une transaction sont propagées aux autres sites

seulement après validation de la transaction.

C'est-à-dire, d’abord un site connait des changements et les valide, puis après ce

dernier peut les propager aux autres sites.

Figure 7 : réplication asynchrone

Les technologies utilisées sont : les Triggers (déclencheurs), les journaux d’images

(après), etc.


+ Avantage :

Les transactions sont toujours locales (un bon temps de réponse)

26

+ Désavantage :

Des incohérences de données

Une lecture locale de données ne retourne pas toujours la valeur la

plus mise à jour.

Les modifications à tous les sites ne sont garanties

De fait, la réplication n’est pas transparente.

I.3.2. Architectures de Réplications

De ce qui précède, il est évident que l’emplacement de l’exécution d’une transaction

est un point capital, et d’ailleurs [5] montre qu’il existe deux architectures qui déterminent

cet emplacement même, on a : primary copy et update everywhere.

- Primary Copy :

Aussi appelé réplication asymétrique [23].

Ici, chaque copie possède une copie primaire dans un site spécifique (serveur), appelée

aussi « publisher ». Les transactions sont seulement exécutées sur les serveurs des données

qu’elles manipulent, ou mieux elles ne mettent à jour que cette copie, et les mises à jour sont

envoyées aux autres copies (secondaires) sur les autres sites.


+ Avantage :

Aucune synchronisation inter-site n’est nécessaire (elle se réalise au

niveau de la copie primaire (primary copy)

Il y a toujours un seul site qui a toutes les modifications

+ Désavantage :

La charge imposée uniquement sur la copie primaire peut devenir

assez grande

La lecture locale peut risquer de ne pas rendre une valeur la plus

mise à jour.

27

- Update everywhere :

Aussi appelé réplication symétrique [23]

Le principal à retenir ici, c’est que, aucune copie n’est privilégiée, par rapport au

précédent. Chaque copie dans n’importe quel site peut être mise à jour à n’importe quel

instant et ainsi le système assure la diffusion ultérieure de ces mises à jour à tous les autres

copies.


+ Avantage :

De n’importe quel site peut s’exécuter une transaction

La charge est équitablement distribuée

+ Désavantage :

Les copies auront tout le temps besoin de la synchronisation

Toutes les quatre techniques ou stratégie ci-haut, peuvent être combinées en vue d’obtenir

une bonne performance et une bonne cohérence ou consistance de données, ainsi on a :

Réplication asymétrique synchrone

Réplication asymétrique asynchrone

Réplication symétrique synchrone

Réplication symétrique asynchrone

28

* Les avantages et les désavantages de la combinaison de stratégie

Symétrique Asymétrique

Synchrone Réplication symétrique synchrone Réplication asymétrique synchrone

+ Avantage :

Pas d’incohérences

La symétrie des sites + Désavantage :

Un temps de réponse long

Les modifications ont besoin d’être coordonnées

+ Avantage :

Les modifications n’ont pas besoin d’être coordonnées

Pas d’incohérence + Désavantage :

Un temps de réponse plus long

Seulement important avec peu des modifications

Les copies locales ne sont lues que localement

Asynchrone Réplication symétrique asynchrone Réplication asymétrique asynchrone

+ Avantage :

Pas de coordination centralisée

Temps de réponses très court

+ Désavantage :

Incohérence

Les mises à jour peuvent être perdues.

+ Avantage :

Pas de coordination nécessaire

Temps de réponses court + Désavantage :

Les copies locales ne sont pas mise à jour

Incohérence

Tableau 1: Avantages et Désavantages de la combinaison de stratégie

Il se suit de ce tableau ci-haut que,

- Réplication symétrie synchrone :

La cohérence de donnée est garantie. La performance peut sérieusement être

dérangée avec cette stratégie. Le système peut avoir un problème de passage à

l’échelle (verrou mortel : verrouillage à deux phases : voir dans le chapitre suivant) ;

dans ce sens que si le nombre de nœuds augmente, cela favorise le verrou mortel à

tout temps. Mais une tolérance à la panne très élevée.

29

- Réplication asymétrie synchrone :

A part l’absence de verrou mortel, cette stratégie est similaire au précédent. Mais ici,

le problème c’est le goulot d’étranglement qu’est la copie primaire.

- Réplication asymétrie asynchrone :

La performance est bonne (presque comme s’il n’y avait de réplication). Ainsi les

incohérences surgissent (de par le fait que chaque site a sa propre valeur de données).

- Réplication symétrie asynchrone :

La performance est excellente (presque comme s’il n’y a pas de réplication). Tolérance

à la panne élevée. Incohérence de la base. Et la reprise de mises à jour perdues est

dur à résoudre, on la fait presque manuellement.

I.4. Fragmentation, Allocation et Conception

Nous l’avons montré ci-haut que, la fragmentation et l’allocation des fragments dans

les sites du système étaient le vrai problème même dans les bases de données distribuée. Ce

problème set très critique qu’il demande d’énormes efforts lors de la conception d’une base

de données distribuée. L’allocation ou la fragmentation, [6], a un plus grand impact dans la

qualité sur la solution finale et par conséquent sur l’efficacité opérationnelle du système.

D’où, la performance de la base de données distribuée y dépend totalement.

La conception d’une base de données distribuée est un problème d’optimisation, qui

peut se subdiviser en deux problèmes [6], ou en trois [47] pour le cas d’une BDD répliquée:

- La conception de fragmentation des relations (tables) globale

- La conception de l’allocation de ces fragments à travers les sites du

réseau de communication

- Et/ou la réplication de ces fragments

I.4.1. Fragmentation

La fragmentation ou le partitionnement est une technique de conception qui consiste

à diviser une relation (unique) d’une base de données en deux ou plusieurs partitions telles

que leur combinaison reproduise la base de données originale sans aucune perte de

données [47].

Nous distinguons en gros deux types de fragmentation : horizontale et verticale, et un

troisième : hybride ou mixte.

30

- Fragmentation horizontale :

Elle permet de partitionner une relation (table) en tuples (ligne d’enregistrement)

disjoint, par sélection selon un critère donné.

L’exemple suivant servira d’illustration :

Soit la relation ou table suivante : Employé (de l’université de Kinshasa : UNIKIN)

Employé :

Matricule Noms Postnom Direction

06/30351 MASIDI LANDU COMMERCIALE

06/30352 MAPULUNGU ADELINE ETUDES

06/30353 MBWEBWE ROBERT COMMERCIALE

O6/30354 NTUMBA DENISE COMMERCIALE

06/30355 MUTOMBO TSHILEMEBE ETUDES

06/30356 PANGU NKOYI COMMERCIALE

Et les fragments sont obtenu par sélection, soit :

Employé_1=SELECT * FROM Employé WHERE Direction = ‘COMMERCIALE’

Employé_2=SELECT * FROM Employé WHERE Direction <> ‘COMMERCIALE’

Employé_1 :


06/30351 MASIDI LANDU COMMERCIALE

06/30353 MBWEBWE ROBERT COMMERCIALE

06/30356 NTUMBA DENISE COMMERCIALE

06/30356 PANGU NKOYI COMMERCIALE

Employé_2 :


06/30352 MAPULUNGU ADELINE ETUDES

06/30355 MUTOMBO TSHILEMBE ETUDES

La reconstruction:

Employé = Employé_1 U Employé_2

31

- Fragmentation verticale :

Elle permet de partitionner une relation ou table en une collection de colonne ou

attribut, à l’exception de la clé primaire [47]. Chacune de collections possèdera la clé

primaire, ce qui est normale, car cette servira de liens. Elle est basée sur la projection.

L’exemple suivant servira d’illustration :

Soit la relation ou table suivante : Commande

Commande :

NCde NClient Produit Quantité

C1 CLI1 P1 20

C2 CLI1 P2 22

C3 CLI2 P3 43

C4 CLI2 P4 100

Et les fragments sont obtenus par projection, soient :

Commande_1=SELECT Code_Commande, Code_Client FROM Commande

Commande_2=SELECT Code_Commande, Produit, Quantité FROM Commande

Commande_1 :

NCde NClient

C1 CLI1

C2 CLI1

C3 CLI2

C4 CLI2

Commande_2 :

NCde Produit Quantité

C1 P1 20

C2 P2 22

C3 P3 43

C4 P4 100

32

La reconstruction:

Pour cela, on fait la sélection avec un critère sur la clé primaire, qui est un lien entre les

fragments :

Commande = (SELECTION * FROM Commande_1, Commande_2 WHERE Commande_1.NCde

= Command_2.NCde)

- Fragmentation mixte ou hybride :

Dans cette sorte de fragmentation, on combine les deux précédentes, et ce de

manière tout à fait arbitraire, c'est-à-dire soit on commence par l’horizontale et puis

la verticale, vice-versa selon le besoin.

Exemples : (Sur la relation Commande ci-haut)

- Commande=SELECTION Code_Commande, Code_Client FROM Commande WHERE

Quantité >= 50

- Commande=SELECTION Code_Commande, Code_Client FROM Commande WHERE

Quantité > 50

Note : il existe un problème qui entache cette notion de fragmentation, c’est qu’elle est liée

à l’existence préalable de données [47], ce qui n’est pas toujours le cas quand on est au

début de la conception de la BDD. Mais, une bonne et efficace connaissance sur l’emploi ou

le besoin sur la BDD (d’une organisation) pourra permettre de savoir au préalable l’ensemble

de requêtes immédiates [16], et ceci facilitera évidemment la fragmentation dite statique.

Mais, dans le futur de l’organisation, d’autre besoins pourront naître d’où d’autres requêtes

et ceci pourra générer d’autres fragments ou déplacer ceux qui existaient, fragmentation

dynamique.

I.4.2. Allocation

Et à présent, après avoir fragmenté la base de données, c’est l’allocation qui s’en suit.

L’allocation, c’est cette étape où l’on affecte chaque fragment à un site du réseau. Les

données ou fragments assignés, peuvent être soit répliqués dans d’autres sites soit gardés

en un seul fragment dans un seul site. Ainsi on parle respectivement redondante et non-

redondante [6].

33

Son but, c’est de stocker les fragments de données plus proche, où ils peuvent être

fréquemment utilisés afin d’accroître la performance, et par conséquent de diminuer la

communication entre les sites. De fait, [6] montre que dans une base de données distribuée

bien conçue, nonante pourcent (90%) de données devraient être trouvées dans le site local

et dix pourcent (10%) seulement devraient être accédées dans un site distant.

Allocation dynamique

Les requêtes à l’origine de chaque site et grâce auxquelles sont affectée les premières

données (fragments) dans chaque site, ont été fixées ou réalisées sur base des besoins

initiaux ou de la connaissance du domaine, et pourtant comme dit tantôt d’autres besoins

peuvent surgir après et ainsi d’autres requêtes peuvent se réaliser, c’est sera alors la

fragmentation dynamique.

D’où comme la première fragmentation avait permis la première affectation de

fragments (allocation) et constituer donc le schéma d’allocation, la fragmentation

dynamique qui entraîne une nouvelle allocation, entrainera de même la modification du

schéma d’allocation : l’allocation dynamique, c'est-à-dire, les fragments peuvent se déplacer

d’un site à un autre d’où il est appelé.

[15] montre que la technique de l’allocation dynamique est une alternative à la

duplication (réplication) et s’avère la plus efficace dans le cas de multiples modifications.

Cliché (Snapshot)

Le cliché, c’est la technique de copie figée d’un fragment [15]. C'est-à-dire, ici, on

utilise une copie (image) d’un fragment d’un temps donné et qu’on ne va pas mettre à jour,

cette copie devient inutile au fil du temps. Ceci évite ce lourd travail de mettre à jour toutes

copies (fragments) correspondants dans les sites. On n’utilise cette technique pour les

données qui ne changent à chaque petit écart de temps, mais dont l’ancienneté de ses

valeurs n’entamera pas la réalité de choses.

34

I.4.3. Conception

Nous distinguons deux types de conception d’une base de données distribuée :

ascendante et descendante.

Conception ascendante

C’est de cette conception qui s’agit lorsqu’il est question de créer une nouvelle base de

données distribuée. On commence par définir un schéma conceptuel global de la BDD, puis

on distribue sur les différents sites en des schémas conceptuels locaux, par la technique de

fragmentation (cf. ci-haut).

Conception descendante

L’approche se base sur le fait que la répartition est déjà faite, mais il faut

réussir à intégrer les différentes BDs existantes en une seule BD globale. En d’autres termes,

les schémas conceptuels locaux existent et il faut réussir à les unifier dans un schéma

conceptuel global [15] [45].

35

[Chapitre II]

36

Chapitre II

Les Transactions Distribuées

Le SQL (Structured Querry Language) est un langage par excellence pour l’interrogation

d’une base de données ou mieux d’un serveur de base de données, et pourtant si vous

effectuez une série de requêtes, il y a beaucoup de risques que l’une d’entre elles échoue et

une autre réussisse, et sur ce, les informations dans la base de données courent le risque

d’incohérence. D’où il existe un concept : « transaction », qui lui permet d’encapsuler un

ensemble d’opérations sur la base de données pour former un seul tout ; cette manière de

faire qu’est la transaction a un effet très positive sur les données à tel enseigne qu’elle

garantit la stabilité et l’intégrité des informations, c.-à.- d lorsqu’ une transaction (qui est un

bloc ou ensemble) est exécutée, la validation ou l’annulation se fait d’un bloc et soit laisse la

base de donnée comme avant (stable) ou elle l’amène dans un autre état de stabilité.

Une transaction peut être locale, lorsqu’il s’agit d’une transaction en une phase et

aussi gérée directement par la base de données ou très simplement lorsqu’elle effectue des

opérations sur une seule ressource (une base de données, etc.), et distribuée lorsqu’elle

utilise de nombreuses ressources, [21], [37].

II.1. DEFINITIONS D’UNE TRANSACTION

Une transaction, c’est un ensemble de requêtes regroupés en une seule unité logique

de travail, qui pourra ensuite être, soit validée, soit annulée;

C’est une collection d’actions [28] qui transforment une base de données (ou un

fichier), depuis un état cohérent en un autre état cohérent [3]; il faut dire que la cohérence

de la base de données est assurée par le système et celle de la transaction par le

programmeur.

Figure 8 : une transaction dans une base de données cohérente

37

Modélisation d’une transaction

On peut modéliser une transaction comme une suite finie d’actions sur des objets

donnés [31] ;

Soit une transaction T, on a :

T = {Oi.Aj, | i = 1..n ; j = 1..p}

Où :

• i désigne un site visité par T

• Oi désigne un objet du site i

• Oi.Aj désigne une action j exécutée au sein de l'objet Oi

Les actions inhérentes à une transaction :

- Début_transaction : initialisation de la séquence transactionnelle

- Valider_transaction : terminaison de la séquence transactionnelle

- Annuler_transaction : arrêt de la transaction

- Lire (objet) : chargement d'une image de l'objet dans l'espace de travail

- Ecrire (objet) : sauvegarde d'une image de l'objet en mémoire secondaire

Note :

Transaction centralisée ou locale : les objets sont sur un seul site.

Transaction répartie ou distribuée : les objets (et les actions) sont sur plusieurs sites.

38

Exemple :

Réduire la commande (cde) N° 10 de 5 unités et les reporter à la cde 12

Transaction Report-qté

begin

exec sql UPDATE cde

SET qte = qté - 5

WHERE ncde = 10;

exec sql UPDATECde

SET qté = qté + 5

WHERE ncde = 12;

exec sql COMMIT WORK;

end.

Ce mécanisme d’encapsuler un ensemble de requêtes ou une collection d’actions ou

opérations en une seule entité qu’est donc la transaction garantit alors la cohérence des

données grâce à l’atomicité de la dite entité (transaction), c'est-à-dire s’il y a validation c’est

pour tout et de même pour l’annulation ; c’est « tout » ou « rien ».

Les opérations dans la transaction peuvent être soit de lecture soit d’écriture soit les

deux à la fois, et pourtant chaque transaction est marquée par un début (Begin Of

Transaction : BOT), et une fin (End Of Transaction : EOT) [45] et vérifie un ensemble de

propriétés représentées par l’acronyme ACID tiré de termes anglais suivants Atomicity,

Consistency, Isolation et Durability, dont elle bénéficie de la cohérence et de la fiabilité [45]

.

Voici comment se traduisent les termes ci-haut :

Atomicity : Atomaticité ;

Consistency : Cohérence ou Consistence

Isolation : Isolement [17] ou Isolation

Durabity : Durabilité

39

Voici ce que veut dire chacun de termes :

Atomicité : La séquence d’instructions est indivisible, c'est-à-dire toutes les requêtes exécutées dans le cadre de cette transaction sont validées en même temps ou aucune ne l’est (principe du tout ou rien). L’ensemble des opérations réalisées sont vues de l’extérieur comme une seule et même opération.

C’est le mécanisme de validation [31].

Il faut garantir qu'en cas de défaillance (processus avorté avant sa terminaison) :

- ou bien l'exécution est totale : l'ensemble des actions correspondant à la transaction est complètement effectué et amène la base jusqu'à un nouvel état.

- ou bien l'exécution n'a aucun effet sur les objets car l'exécution est impossible : toutes les modifications partielles engagées sont complètement annulées et l'on reste à l'ancienne version

Cohérence : la transaction ne viole pas les invariants du système, quand elle est validée, elle génère un nouvel état stable du système, ou si un problème survient, le système retourne dans l’état qui était considéré comme stable avant qu’elle n’ait commencé.

Une transaction correcte est celle qui est constante avec la sémantique de cohérence de l'ensemble des objets.

Isolement [17]: Une transaction, tant qu’elle n’a pas été validée reste isolée des autres transactions. Les autres transactions n’ont pas accès aux modifications effectuées par cette transaction ; plus clairement le résultat des actions intermédiaires (état temporairement incohérent) est masqué aux autres transactions.

C’est le mécanisme de contrôle d'accès concurrents.

L'isolation ou l’Isolement est cette propriété qui permet à un ensemble de transactions s'exécutant simultanément (concurremment dans le même environnement) d'apparaître comme s'exécutant de façon indépendante les unes des autres (sérialisabilité).

C'est le travail de contrôle de concurrence proprement dit.

40

Durabilité : Les données validées sont enregistrées telles quelles, même si un problème survient ou que le système redémarre. Les données sont disponibles dans un état correct et sont désormais permanents.

C’est le mécanisme de reprise après panne (recovery).

Les effets des opérations décidées (validées) définitivement doivent être durables (persistants) même en cas de défaillance (de processeurs ou de communication)

La fin d'une transaction est un point de non-retour.

C’est aussi le mécanisme de reprise après panne [31].

Lorsqu’une transaction a débuté, il y a lieu de constater trois cas : la validation,

l’annulation et l’interruption :

- Validation : appelée COMMIT ; la transaction a bien aboutit jusqu’à la fin et la base

de données enregistre les modifications;

- Annulation : appelée ROLLBACK, le mécanisme chargé de défaire les modifications

effectuées par la transaction ;

- Interruption : appelée ABORT

II.2. CLASSIFICATION DES TRANSACTIONS

On peut classer les transactions suivant plusieurs critères tels que la nature de

différentes opérations qui la composent, la durée qu’elle peut prendre [25] :

II.2.1. Suivant la nature de différentes opérations

Transaction de Lecture, Transaction d’Ecriture

Si une transaction contient au moins une opération qui effectue des modifications sur

les données de la base, la transaction est dite transaction d’écriture ou de mise à jour. Si

toutes les opérations ne font que des lectures sur les données de la base, la

transaction est dite transaction de lecture.

41

II.2.2. Suivant la durée

On-Line :OLTP, Batch : OLAP

Une transaction peut être classée on-line ou batch. Les transactions on-line,

communément appelées transactions courtes, sont caractérisées par un temps de

réponse relativement court (quelques secondes) et accèdent à une faible portion des

données. Les applications qui utilisent ce modèle de transaction sont dénommées

applications OLTP (On-line Transactional Processing) parmi lesquelles, nous avons les

applications bancaires, de réservation de billets, de gestion de stocks, etc. Les

transactions batch, appelées transactions longues, peuvent prendre plus de temps pour

s’exécuter (minutes, heures, jours) et manipulent une très grande quantité des

données. Les applications utilisant ce type de transactions sont les applications

décisionnelles ou OLAP (On-line Analytical Processing), de conception, de 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].

42

Les SAVEPOINTS ont chacun un nom unique, garantissant que si jamais il y a

une interruption, les modifications déjà effectué et ayant déjà été marquée par un

SAVEPOINT persisteront [28].

II.3.3. Les Transactions Chainées (Chained Transactions) :

Ce sont une variante de SAVEPOINTS. Toutefois, plutôt que de marquer simplement un

point de cohérence d’où peut retourner une transaction, la commande de travail de la

chaine valide en fait le travail jusqu’à là. Il n’y a donc pas lieu de faire le ROLLBACK sur le

travail précédent. Toutefois, la transaction elle-même va survivre. Au cas où il y a un verrou

posé par la transaction, il va continuer ainsi jusqu’à la fin du travail. Le verrou sera relâché

seulement si toute la transaction a été validée.

II.3.4. Les Transactions Imbriquées ou Emboitées (Nested

Transactions)

[Définitions]

> Une transaction imbriquée est composée d’une hiérarchie de sous-transactions

ou un arbre de transaction [28].

Début de la nouvelle

Transaction

Fin Transaction

précédente

ROLLBACK

COMMIT

DATABASE

INSERT UPDATE DELETE

SAVEPOINT N1 SAVEPOINT N2

Début

Transaction

Fin

Transaction

Figure 9 : Transaction plates avec SAVEPOINTS [22]

43

Figure 10 : Arbre de Transactions et sous-Transactions

L’arbre de Transactions ; une transaction peut avoir n’importe quel nombre de sous-

transactions, lesquelles peuvent aussi être composées de n’importe quel nombre de sous-

transactions, ainsi se résulte une transaction imbriquée.

La transaction racine est appelée Top-Level Transaction (le niveau le plus supérieur)

car elle n’a pas un autre nœud de transaction auquel elle est liée ; les transactions ayant des

sous-transactions sont appelées des parents (des mères) et les sous-transactions des enfants

(des filles), les filles d’une même mère sont des sœurs. On parle ainsi des descendants (en

partant de la racine vers les enfants) et des ancêtres (inversement). Et les transactions et les

sous-transactions, elles sont toutes des transactions.

On appelle filles ou feuilles des transactions qui n’ont plus d’autres sous-transactions

et ces dernières sont des transactions plates.

> Une sous-transaction est une unité de reprise.

- L'abandon d'une sous-transaction implique l'abandon de ses descendants

mais pas de ses ancêtres.

> Une sous-transaction est une unité d'exécution indépendante

- Isolation des sous-transactions s'exécutant en parallèle

- Les sous-transactions peuvent s'exécuter sur le même site ou sur des sites

différents

> Les transactions sont ACID alors que les sous-transactions sont AI

(Atomicity, Isolation)

> Les feuilles de l’arbre de transaction sont des transactions plates (flat

transactions) [28].

44

(*) Une transaction parent peut passer son verrou à une transaction enfant. Une sous-

transaction peut être validée (COMMIT) ou être interrompue n’importe quand, et dans ce

cas tout verrou possédé par une sous-transaction passe au parent. Tous les verrous sont

relâchés seulement quand la transaction racine a été validée.

[Objectifs]

> Obtenir un mécanisme de reprise multi-niveaux

> Permettre de reprendre des parties logiques de transactions

> Faciliter l'exécution parallèle de sous-transactions

[Règles d’Isolation]

Quelque notions déjà énoncée précédemment au (*)

> (R1) Seules les transactions feuilles accèdent aux ressources partagées (ex:

base de données)

> (R2) Quand une sous-transaction valide, ses ressources sont héritées par sa

mère

> (R3) Quand une sous-transaction abandonne, ses ressources sont relâchées

> (R4) Une sous-transaction ne peut accéder une ressource que si elle est libre

ou détenue par un ancêtre

[Atomicité et Durabilité]

Comme aussi dit tant tôt ;

> (R1) Quand une sous-transaction valide, ses effets sont hérités par sa

mère

> (R2) Quand une sous-transaction abandonne, ses effets sont abandonnés

> (R3) Quand la transaction racine valide, ses effets sont installés dans la

base

45

Illustration

Figure 11 : Validation et Abandon de Sous-Transactions

Veuillons donc voir les règles de [Atomicité et Durabilité] dans cette illustration.

Ici, nous avons la transaction T1 qui a deux sous-transactions T11 et T12

- A l’état initial, X=0 ;

- Et après T11 le modifie, X :=X+1, d’où X=1 ;

- Alors, T11 valide ses modifications selon (R1), mais comme tous les traitements de

l’arbre de transactions ne sont pas finis alors, X=0;

- Et au tour de T12 de faire les modifications, X=X+1, d’où X=2, mais X=0 ;

- Mais T12 vient à abandonner ses modifications selon (R2) ;

- Et en fin quand T1 valide, selon (R3), X=1 conformément à tout ce qui précède.

II.3.5. Transactions Compensatrices

Les Transactions Compensatrices sont des transactions qui sont à la fin des

Transactions proprement dite et qui s’exécutent en cas de panne de paire de

transactions qu’elles doivent compenser.

46

Figure 12 : Transactions compensatrices

II.3.6. Les Transactions Longues

Comme montré au point (2), les transactions Batch sont un exemple de transactions

longues qui peuvent contenir un millier de mises-à-jour et durent beaucoup d’heures. Cela

peut devenir une situation intolérable.

Une solution existe, c’est celle de découper le travail du batch en mini-batch travaillant

sur les données avec un même attribut, tel qu’une collection de clés [28].

Malgré cette solution, elle n’est pas la parfaite du fait que l’atomicité de toute la

transaction ne peut pas être maintenue.

II.3.7. Les transactions Distribuées

Nous l’avons aussi déjà dit tant tôt, les transactions distribuées sont celles qui doivent

s’exécuter à travers un réseau de bases de données. Elles sont similaires aux transactions

imbriquées. Toutefois, l’arbre de transaction pour une transaction imbriquée dépend de

l’application, pendant que l’arbre pour une transaction distribuée dépend de données. Les

transactions distribuées sont essentiellement des transactions plates (flat transactions).

Toutefois, si les données sont hébergées dans une base de données distante doivent être

mises à jour, alors une sous-transaction débute sur cette base de données. Le bloc de sous-

transaction est l’ensemble d’opérations sur la base de données. Au moment du COMMIT, la

transaction parent (mère) interroge toutes ses sous-transactions pour s’assurer qu’elles sont

toutes prêtes pour les COMMITS avant d’entamer la commande d’un COMMIT. Si une ou

plus d’une transaction peut ne pas faire le COMMIT, alors la transaction connait un ABORT

Nous en parlons encore en abondance et en vif dans la suite avec le modèle OSI à

l’appui.

47

II.4. LA JOURNALISATION ET LA REPRISE DES

TRANSACTIONS

II.4.1. Journalisation

C’est la technique appliquée pour prévenir les pannes, toutes les modifications

apportées à la Base de Données sont écrites dans un fichier journal appelé Log.

Chaque fois qu’il y a écriture au niveau de la base de données, il y a aussi une autre y

correspondant dans un support sûr (log) ;

Le journal de transaction est le pilier de la reprise consistante [28] et la terminaison

d’une action atomique interrompue par une panne.

On distingue donc [30]:

- Le Journal des images avant

- Le Journal des images après

Pour chaque donnée dans la base.

Le journal de transaction peut grossir et se remplir avec le temps, mais c’est le

Gestionnaire de Journaux (Log Manager) qui permet de :

- L’archivage de journaux

- D’apprêter (vider) le journal pour une prochaine utilisation après qu’il soit remplit

- Et il fournit au Gestionnaire de Transactions et de Données une interface publique au

journal, et ce pour la reprise, vu que ce dernier fournit des informations nécessaires

pour restaurer une base de données endommagée à son dernier état cohérent [28].

(a) Le Journal des images avant

Il contient les débuts de transactions, les valeurs d'enregistrement avant mises à

jour, les fins de transactions (COMMIT ou ABORT)

Il permet donc de défaire (UNDO) les mises à jour effectuées par une transaction

48

Figure 13 : L’UNDO d’une mise-à-jour [30].

Toute mise à jour doit être précédée d'une écriture dans le journal des images avant

Avant tout, signalons que ce journal est utilisé pour défaire les actions d’une

transaction lorsqu’un site participant (cfr Protocole à Deux Phases, un peu plus loin) tome en

panne avant la validation (globale) de celle-ci.

Chaque fois quand une transaction démarre, il y a deux pages qui se lancent aussi :

page lue et page modifié (en mémoire cache).

- Page lue, contient l’ancienne valeur ou mieux pointe son adresse dans le journal

- Page modifiée, contient la valeur modifiée. Et c’est elle modifie vraiment la base de

donnée.

Alors, pour défaire, la base de données lire (READ) dans la page lue (1), et celle-ci

récupère l’ancienne value du journal (2), et apporte une modification la page modifiée avec

cette valeur (3) et enfin la page modifiée écrit dans la base de données (4) et cette dernière

revient à son état initial.

(b) Le Journal des images après

Il contient les débuts de transactions, les valeurs d'enregistrement après mises à

jour, les fins de transactions (COMMIT ou ABORT)

Il permet également de refaire (REDO) les mises à jour effectuées par une

transaction

49

Figure 14 : Le REDO d’une mise-à-jour [30].

Toute validation de transaction doit être précédée de l'écriture de son journal

d'images après sur un disque différent de celui contenant la base de données.

Pareillement avec la méthode de page ombre [52], lorsqu’il y a validation la page

modifié devient la page lue ;

Alors, pour défaire, la base de données lire (READ) dans la page lue (1), et celle-ci

rapporte une modification la page modifiée avec les dernières valeurs de la transaction (2),

et la page modifiée prend toutes informations de la transaction (validation, etc.) du journal

(3) et enfin la page modifiée écrit dans la base de données (4) et ainsi les mêmes mises-à-

jour sont de nouveau apportées à la base de données.

Note :

[30] et [28] montrent qu’il existe deux autres type de journaux, à savoir Logique et physique

• Journal physique:

* On enregistre la valeur avant et après modification

* La structure peut être : IdTrans, NumPageDisk, Adresse, Valeur

* Pour défaire, on écrase la valeur actuelle avec les valeurs avant

* Pour refaire, on écrase la valeur actuelle avec les valeurs après

50

• Journal Logique

+ On enregistre l’action logique qui a entraîné la modification

+ La structure peut être : IdTrans, IdObjet, IdActions, Arguments

+ Exemple: Ajouter 500 au tuple xxx

+ pour refaire, on ré-applique l’action logique

II.4.2. Reprise

On a vu que lorsqu’une transaction se déroulait, elle pouvait subir une interruption

(ABORT), et cela est dû principalement à une panne ou défaillance.

A la reprise (après une défaillance), le système transactionnel parcourt le journal pour

analyser l'état des transactions interrompues au moment de l'incident.

(a) Différent types de pannes (défaillances)

> Abandon d’une Transaction

Dû souvent à un problème d’accès concurrent [44].

> Panne Système

Dû à un arrêt brutal des travaux, d’où une perte de contenu de la RAM ou une

défaillance matérielle ou logicielle d'un système local ou du système de

communication

> Panne du support de reprise

(b) Traitement de reprise

Respectivement pour les deux dernier cas de pannes, on y remédie avec une reprise à

chaud et une reprise à froid.

> Reprise à chaud

+ Défaire les actions des transactions interrompues sur les sites en

fonctionnement

+ Redémarrer le site interrompu (ou reconnexion en cas de panne réseau)

+ Défaire les actions des transactions sur le site reconnecté

+ Ré-exécuter les transactions

> Reprise à froid

+ Restaurer la mémoire secondaire dans un état cohérent à l'aide d'une image

sauvegardée antérieurement (grâce au CHECKPOINT)

+ Refaire les actions des transactions perdues à cause de la défaillance

Toutes ces reprises se font grâce aux points de reprise (CHECKPOINTS) créés bien avant.

51

(c) Le Point de Reprise (CHECKPOINT)

Ce point se réalise après un état cohérent de la base de données provoqué par une

mise-à-jour et aussi après une sauvegarde ; il permet ainsi de situer une transaction

effectuée et ses actions soit pour un UNDO ou un REDO après une défaillance.

II.5. TRANSACTION DISTRIBUEE ET LE MODELE OSI

Avant d’entrer dans le vif de ce point, nous aimerions lui faire un préambule axé sur le

système transactionnel, qui est le système dans lequel ou mieux entre lesquels les

transactions se déroulent.

II.5.1. Le Système Transactionnel

L’objectif principal de ce système, c’est le traitement transactionnel soit OLTP à savoir

On-Line Transaction Processing, qui est un mode d’organisation d’une application

informatique qui permet à un grand nombre d’utilisateurs de soumettre, via leurs

terminaux, des transactions à un système qui doit les traiter le plus vite possible et

répercuter les effets sur une grande base de données [1].

En voici l’architecture :

Poste Client

Machine Serveur

Figure 15 : Architecture du système transactionnel [31]

52

Termes inhérents au système transactionnel :

+ Programme d’Application :

Celui-ci définit les limites de transactions et spécifie les actions que constitue une

transaction.

+ Gestionnaire de transactions :

C’est lui qui est chargé de fournir les informations nécessaires pour une reprise

donnée ;

Il reçoit d’une application donnée les commandes de BEGIN, COMMIT et ABORT et le

transmet au Gestionnaire de données approprié.

C’est lui donc qui garantie la propriété ACID d’une transaction.

Enfin s’appuyant sur le journal de transactions, le Gestionnaire de Transactions a

plusieurs autres tâches telles que : le ROLLBACK des transactions, le redémarrage du

Gestionnaire de données et du système global (de tous les gestionnaires de données), etc.

[28].

+ Gestionnaire de données :

Le Gestionnaire permet ainsi les mises-à-jour et les lectures des données ; il est chargé

d’écrire dans le journal d’image avant et après de données à toute modification.

Note : Le Système Global (les deux gestionnaires) permet donc d’assurer l’intégrité

transactionnelle de données modifiées [1].

+ Moniteur Transactionnel :

Il permet la communication et la mise en relation de processus client et serveur et

cette communication reste transparente (pour le processus et pour les medias).

Il permet aussi de gérer les transactions (du point de vue respect de la propriété ACID),

dans un contexte, éventuellement distribué, mettant en jeu plusieurs Gestionnaire de

données.

Il faut donc dire que le SGBD et le moniteur reste indissociable pour un système OLTP

[1], car ce dernier offre une interface programmatique et des outils de supervision qui

facilite le rôle des développeurs des applications et des administrateurs.

53

II.5.2. Le Modèle OSI pour les Transactions Distribuées

L’organisation de Standardisation Internationale (ISO : International Standard

Organisation) a mise en place une norme OSI TP (Open System Interconnect Transactions

Processing) dont le standard axe sur les trois points principaux suivant le modèle, le service

et le protocole de spécification pour les transactions distribuées.

Tous ces concepts sont mieux explicités dans les documents du standard dont les

références sont [26] ; Nous n’allons pourtant juste que présenter ici les notions

nécessaires.

(a) Modèle

C’est aussi appelé OSI DTP Reference Model (DTP : Distributed TP).

(1) Association

Lorsque deux systèmes ouverts doivent prendre part dans un même traitement distribué, ils ont besoin d’être mise en connexion ; et c’est cette dernière qu’on appelle Association ; c’est l’ACSE (Association Control Service Element ; Partie de la couche 7 OSI - application permettant de faire communiquer deux entités [2]) qui est chargé de l’établir.

(2) Architecture, Dialogue et Arbre

[-Architecture transactionnelle-]

La figure ci-dessous illustre l’architecture transactionnelle de trois nœuds X, Y et Z

S

A

O

S

A

O

MACFO

TPPM

S

A

O

TPPM

TPSU TPSU

S

A

O

TPPM

TPSU

NŒUD_X NŒUD_Y NŒUD_Z

Figure 16 : Architecture Transactionnelle [46]

54

TPPM (TP Protocol Machine) : c’est un système ouvert [26] ; il fournit le service OSI TP et en

outre est un représentant local de l’application répartie appelé TPSU (TP Service User).

SAO (Single Association Objects) : c’est un ensemble de modules que constitue aussi une

entité de TPPM. Il a pour but la gestion de la communication sur une association avec un

nœud voisin.

MACF (Multiple Association Control Function) : mis à part le SAO, le MACF est aussi une

entité qui constitue un TPPM. il a pour but la coordination entre tous les SAOs.

[-Dialogue-]

On appelle Dialogue, une relation peer-to-peer entre deux TP Service Users qui

communiquent après des invocations (appels) entre eux ou carrément entre deux TPSUIs

(TPSU Invocation). Lorsqu’il y a établissement de dialogue, alors les deux participants

peuvent communiquer pour se transférer des données, notifier des erreurs, initier ou

achever une transaction, terminer un dialogue, ou synchroniser les activités.

Et comme l’illustre aussi la figure juste ci-dessus, voici un exemple de dialogue entre

TPSUI A et B :

Il faut dire que chaque fois qu’il y a dialogue, il y a immanquablement un initiateur et

un répondant, dont respectivement l’un est un supérieur et l’autre un subordonné. Et même

si le dialogue fait intervenir plus d’une association de TP (TP Association), il reste un concept

logique et en même temps en est indépendant.

TPSUI A

TPPM

TPSUI B

TPPM

Figure 17 : Modèle de Dialogue dans OSI TP

55

[-Arbre de Dialogue et de Transaction -]

De par des invocations des différents TP Service Users, nous avons déjà un Arbre de

dialogue dont les nœuds sont ces dernières et les arcs les dialogues. Cet arbre de dialogue

représente une topologie de la communication des systèmes ouverts participants dans le

traitement distribué.

Et comme une transaction distribuée (répartie) est celle qui enjambe beaucoup de

ressources (dans différents nœuds ou sites) ; une partie d’elle est exécuté par un couple de

TP Service Users comme ils sont en dialogue. Chaque partie est une branche de la dite

transaction distribuée.

Un arbre de Transactions est tout similaire à celui de Dialogue, sauf qu’ici les arcs sont

les branches de transactions ; ce qui est logique.

On distingue dans cet arbre trois types de nœuds : la racine, les intermédiaires et les

feuilles ; la racine est l’invocation du TPSU qui n’a pas un nœud supérieur et les feuilles sont

ceux qui n’ont aucun nœud subordonné. Un nœud un sous-arbre de transactions qui

respecte les même règles énoncées juste ci-haut. (Cette notion d’arbre de transaction est

aussi vue un peu ci-haut avec les transactions imbriquées).

Racine

Intermédiaire Feuille

Feuille

Intermédiaire

Figure 18 : Arbre de Transactions

56

(b) Services et Protocole

Pour établir et libérer les associations, le TPPM ou la machine protocolaire utilise l’ASE

(Application Service Element [2] [1]) de l’ACSE.

Le TPPM joue ce rôle de fournir les services pour assurer la propriété ACID, alors pour

ce fait lorsqu’une TPSUI veut établir un dialogue, il doit le spécifier.

Les services sont regroupés en unité fonctionnelles [1], dont nous avons :

+ Le noyau :

C’est l’unité fonctionnelle chargée de dialogues entres les TPSUIs, elle

comprend donc les services pour ouvrir, terminer, interrompre, refuser

l’ouverture d’un dialogue et de traiter les erreurs.

+ Le contrôle partagé :

C’est l’unité fonctionnelle qui permet les TPSUIs et leur assure un contrôle de

leurs dialogues de façon cohérente.

+ Le contrôle polarisé :

Pareille que l’unité précédente, sauf qu’ici, à un instant donné une seule

TPSUI possède le contrôle.

+ La synchronisation :

C’est l’unité fonctionnelle qui permet aux TPSUIs de synchroniser leur

traitement, c'est-à-dire avoir la possibilité de vérifier qu’ils ont atteint un

point de traitement convenu.

+ Le Commit :

C’est l’unité fonctionnelle qui rend possible la validation (COMMIT) fiable ou

le retour (ROLLBACK) des transactions.

Le commit ou la coordination, assure la phase terminale de la transaction

pour la validation à deux phase.

Note [20] [1]:

* L’unité fonctionnelle de Contrôle partagé et polarisé sont mutuellement exclusive

pour un dialogue.

* La validation à deux phases, dont nous allons parler prochainement mais en long et

en large, comprend donc l’arbre de transaction, la journalisation, la gestion de

données liées et le pilotage de CCR (Committment, Concurrency and Recovery :

protocole de validation et de reprise de transactions [26]) ; nous l’allons montrer

dans la suite.

57

II.6. GESTION ET CONTROLE DE CONCURRENCE DE

TRANSACTIONS (REPARTIE)

La mise au point de l’utilisation de transactions, comme dit tant tôt, avait pour but,

aussi palliatif soit-il, de garantir la cohérence ou la consistance de données. L’intégrité de

données. Et une transaction atomique et cohérence ne met en cause aucunement l’intégrité

des données. Ce sont d’ailleurs les deux propriétés qui distinguent les transactions de

n'importe quelle séquence d'actions - éventuellement réduite à une seule - sur la BD.

Tout tourne autour de la terminaison de la transaction, afin que celle respectant la

propriété d’ACID, arrive aussi à maintenir la base de données cohérente. D’où la gestion de

transactions est capitale, et reprend celle de ce deux point :

* La cohérence ou la consistance de données (contrôle de cohérence de données) :

La définition de la cohérence résulte de la sémantique de l’application, c’est l’ensemble

de techniques mises en œuvre pour assurer la validité du système informatique par

rapport au monde réel qu’il modélise.

Mais, le contrôle de cohérence nécessite deux mécanismes de contrôle [46]:

+ Un contrôle de concurrence :

Pour l’accès à des données locales communes à des processus d’applications

réparties différentes.

+ Un contrôle de synchronisation

Dans les modifications effectuées, à la fin de chaque étape, par différents

processus d’une application répartie.

* La concurrence de données (contrôle de concurrence de données) :

La concurrence, c’est cette possibilité que donne un SGBDR (Système Gestion de Base

de Données Réparti) multiutilisateur de permettre un accès simultané de transactions dans

une base de données ; c’est d’ailleurs une qualité pour un SGBDR. La concurrence a pour but

d’améliorer le système et le temps de réponse, permettre différentes transactions d’accéder

dans différentes parties de la base de données. Et pourtant si elle n’est pas contrôlée elle

provoque une incohérence ou inconsistance de données.

58

II.6.1. La cohérence de données

Pour terminer une transaction, il faut décider de son issue : la validation (COMMIT) ou

l’annulation (ROLLBACK) [50] ; La validation rend les modifications définitives ; l’annulation

ramène les processus à leur état avant transaction (propriété d’atomicité). Et comme les

transactions distribuées, ce dont même nous parlons dans notre travail, concernent

plusieurs ressources, sa validation (COMMIT) est assurée par des protocoles de validation

qui sont des algorithmes pour assurer l’atomicité d’une transaction distribué et ils sont

utilisés dans un SGBDR (Système de Gestion de Base de Données Réparti) pour montrer un

comportement bien-défini de chacun de sites, particulièrement pour le COMMIT et le

ROLLBACK des transactions [32].

Nous en citons deux, que nous allons développer dans ce travail :

> Validation en deux phases : dite bloquante, car une transaction peut rester bloqué

suite à la panne du coordinateur (l’initiateur du dialogue, la racine [26]).

> Validation en trois phases : dite non-bloquante.

(a) Règles générales d’un protocole de validation

> Le coordinateur valide la transaction, si inévitablement tous les sites participants

valident ;

> Sinon il annule ;

> Tout site en bon état, coordinateur ou participant, peut éventuellement décider de

valider ou d’annuler ;

> Il ne suffit qu’un site, alors n’importe le quel, décide de valider ou annuler, alors plus

un autre ne décidera autrement.

(b) Point de validation : COMMIT POINT

Chaque fois quand une transaction doit s’exécuter, le SGBD désigne un site afin

qu’il soit le point de commit avec un rôle aussi précis que de lancer le COMMIT ou

ROLLBACK selon que lui ordonne le coordinateur global.

Le critère de sélection d’un site en tant que point de commit est le suivant :

> Le site ne doit pas être en lecture, c.-a.-d. il doit pouvoir modifier ses données

locales pendant une transaction

En cas de plus d’un site correspondant au critère, le coordinateur fait un choix au

hasard ; car tous les sites ont la même chance de sélection.

59

En cas d’échec de la phase de préparation par le coordinateur, aucun point n’est

désigné et le coordinateur lance un ROLLBACK.

Le point de commit est un site distingué des autres, on a :

+ Il n’entre jamais en phase de préparation ;

+ Il stocke des données importantes, qui restent jamais incertaines même quand il

y a panne (fiabilité);

+ Il stocke les informations sur le statut de la transaction

(c) Protocole de Validation en Deux Phases : 2-PC

Nous avons deux types de nœuds ou sites dans une validation en Deux phases, le

Coordinateur et le Participant. Le coordinateur est celui qui a pour but de lancer, découper

en sous transaction les transactions qui seront exécutées sur les sites restant [22] [15] et

coordonner la terminaison de ces transactions. C’est donc un serveur auquel les autres sites

dits clients se connecte lorsqu’ ils veulent effectuer une transaction.

Voici ci-dessous, deux automates à états finis non déterministes (AEFND) (aussi bien

défini dans [39]) modélisant les actions du coordinateur et du participant :

[Etats]

- q1, q2 : des états initiaux

- a1, a2, c1, c2 : des étaux finaux, respectivement « a » pour ABORT et « c » pour

COMMIT

- w1 : état intermédiaire, w pour WAIT (Lorsque le coordinateur attend les réponses

des participant)

- p2 : état intermédiaire, p pour PRE-COMMIT (du participant)

[Transitions]

Exemple : 𝑋𝑎𝑐𝑡−𝑟𝑒𝑞𝑢𝑒𝑠𝑡

𝑆𝑡𝑎𝑟𝑡_𝑋𝑎𝑐𝑡 ;

Le message au dessus de la ligne, c’est celui qui est reçu et en dessous est celui qui est

envoyé entre le coordinateur et les participants.

60

Figure 19 : Les actions du Protocole de Validation en Deux Phases [32]

Le principe du protocole de validation en deux phases [46] [32] [20] est le suivant :

- La phase 1 :

C’est la phase de préparation ou de consensus entre tous les sites participant à la

validation des effets de la transaction, alors ces derniers peuvent voter oui ou non (yes ou

no), comme le montre la figure juste ci-dessus.

Une fois le consensus établi, c'est-à-dire tous les sites participants ont voté « yes »

(PRE-COMMIT) et le renvoie au coordinateur, alors il lance la deuxième phase pour le

COMMIT.

Si, par contre, même un seul site vote « no », il n’y a donc pas consensus et le

coordinateur ordonne alors à tous les sites pour le ROLLBACK.

- La phase 2 :

Ici, tous les sites participant à la transaction valident ou annulent simultanément selon

qu’ils ont reçu le message de COMMIT ou ROLLBACK

Explication de la figure ci-dessus

Le coordinateur reçoit (de l’application) Xact_request en « q1 » c'est-à-dire une

requête de transaction et l’envoie (Start_Xact) aux participant en « q2 », et de là le

participant peut soit l’exécuter et renvoyer « yes » pour passer en état « p2 » : PRE-COMMIT

(près pour le COMMIT) ou soit carrément renvoyer « no » et passer en « a2 » : ABORT. Et

c’était donc la première phase. Et la deuxième phase débute en « w1 » d’où le coordinateur

attendait les réponses des participants ; s’il reçoit « yes », alors de manière non-

déterministe, il renvoie « commit » ou « abort » aux participants pour valider ou annuler

simultanément et ils le reçoivent en « p2 » et peuvent ainsi achever cette action finales.

61

Note :

- Yes = Oui = Prêt

- No = Non = Abandon

Cas favorable de la validation (normale) à Deux Phases (Illustration)

Figure 20 : Validation normale [15] [22] [40]

Ici, tous les participants ont voté prêt ou oui et ainsi ensemble avec le coordinateur, ils

font une validation globale simultanément.

Validation en deux phases face aux pannes

L’efficacité de ce protocole réside dans l’utilisation des journaux [46], qui ne perdent

pas d’information. Lorsqu’il y a une panne, probablement de sites qui sont silencieux ou de

communication (plus de ligne de transmission), le mécanisme de reprise sera fait sur base

des informations des journaux de transaction.

Par exemple, dans le cas d’une panne de communication, le participant qui est prêt

reste bloqué puisqu’il ne peut pas communiquer avec son coordinateur et par conséquent

ne peut savoir sa dernière décision. On dit qu’il est dans un état incertain ou de doute.

Que faire en cas de doute ?

Le participant doit émettre des requêtes [46] auprès des autres pour savoir la décision

finale. Ou forcer la transaction locale à l’état ABORT ou COMMIT et puis l’ignorer.

62

> Quelques cas de panne : cas défavorable (Illustration)

Panne d’un participant avant d’être prêt

Figure 21 : Panne d’un participant avant d’être prêt [15] [22] [40]

Dans ce cas, le participant P2 tombe en panne avant de voter yes ou no pendant que

P1 vote yes et le renvoie au coordinateur ; et à cause de ça il y a un timeout (temps de

réponse imparti expiré) et le coordinateur commande, selon le principe de la validation à

deux phases, d’abandonner (annuler).

Panne d’un participant après s’être déclaré prêt

Figure 22 : Panne d’un participant après s’être déclaré prêt [15] [22] [40]

63

Ici, tout se passe bien jusqu’au consentement des participant (prêt), mais juste après le

participant P2 tombe en panne et quand le coordinateur envoie la commande de valider,

elle le trouve ainsi. L’autre la reçoit et l’exécute et c’en est fini avec lui ; mais lui attendra

que qu’il y ait reprise et alors il va valider.

Panne du Coordinateur

Figure 23 : Panne du coordinateur [15] [40]

Bien que garantissant la convergence des acteurs vers un même état (COMMIT ou

ABORT), Et il est plausiblement clair que le défaut le plus notoire de ce protocole, c’est le

blocage. Pour cela, il ne suffit que le coordinateur tombe en panne après émission du

message PREPARE (Xact_start), tout participant ayant voté prêt (yes) est alors bloqué

(TIME-OUT).

D’où le protocole de validation en trois phases.

En outre, ce protocole menace aussi l’inconsistance d’états [32] et pour Dale Skeen et

Michael Stonebraker [12], un état est dit inconsistant lorsque son vecteur d’état global

contient à la fois les états COMMIT et ABORT. Un exemple pour le participant qui est déjà à

l’état de PRE-COMMIT « p2 ».

Proposition OSI pour le protocole de validation en deux phases

Pour le cas de ce protocole, OSI TP [26] veut qu’il soit modélisé dans une structure

hiérarchique. C'est-à-dire la racine, c’est le coordinateur ou l’initiateur de la transaction.

Chaque site ou nœud a cette possibilité de signaler ses voisins l’annulation de son

processus : annulation unilatérale ou le « Presumed Rollback » [46], en cas des opérations

anormales.

64

(d) Protocole de Validation en Trois Phases : 3-PC

A la différence du précédent, celui-ci est non bloquant où on a :

+ Préparation ou consensus

+ Préparation pour la validation (PREPARE TO COMMIT)

+ Global COMMIT

+ Global ABORT

Et plus clairement [12] montre qu’un état PRE-COMMIT « p1 » est ajouté au

coordinateur ne pouvant être atteint que si tous les participants ont voté pour le COMMIT :

« yes ». Mais lorsqu’il y a panne d’un participant après que le coordinateur ait atteint le PRE-

COMMIT « p1 », le coordinateur n’a qu’une seule option c’est annuler (ABORT) : TIME-OUT ;

sinon la transaction aboutit alors et les participant renvoient un acquittement (ACK).

Figure 24 : TIME-OUT et panne dans le protocole de validation en trois phases [32]

Ce protocole assure toujours un COMMIT global même lorsque le coordinateur étant

déjà au PRE-COMMIT (« p2 ») tombe en panne et il y a lieu d’une élection d’un nouveau

coordinateur.

Ce protocole aurait résolu le problème de blocage et pourtant ne reste pas parfait à

tout égard ; son seul problème c’est quand il y a plusieurs pannes de sites.

65

II.6.2. Concurrence d’accès de données

Une exécution concurrente non-contrôlée des plusieurs transactions peut amener des

incohérences ; par exemple lorsque des données liées par une contrainte d’intégrité sont

mises à jour par deux transactions dans des ordres différents de sorte à violer la contrainte.

La figure ci-dessous l’illustre très bien :

Figure 25 : Exécution non contrôlée des transactions concurrentes

De cette figure, se révèle un problème, c’est celui d’interférence ; [45] montre que ce

problème se résume en deux cas :

+ Interférences entre écrivains, Transactions d’écriture

+ Interférences entre lecteurs et écrivains, Transactions de lecture et d’écriture

66

(a) Interférences entre écrivains

Perte d’opérations (Lost Update)

Ici, la mise à jour faite par une première Transaction est perdue

Exemple :

TEMPS

READ A

t1

X = A + 1

WRITE A = X

t3

TRANSACTION_1

t2 READ A

Y = A * 7

t4 WRITE A = Y

TRANSACTION_2

Figure 26 : Perte d’opérations

67

Ecriture inconsistante ou sale (Dirty Write)

Une Transaction T1 lit une valeur V et la modifie, et la Transaction T2 lit l’actuelle

valeur V et la modifie à partir de là ; mais après ça la Transaction T1 vient à s’annuler

(ROLLBACK) et voilà que la dernière valeur modifiée par T2 n’a plus de sens.

L’écriture inconsistante ou sale, c’est tout simplement celle à partir d’une valeur

temporaire des données.

Exemple :

Initialement, C le crédit d’un compte est < 500. Une première transaction modifie le

crédit C d'un compte. Une deuxième lit C dans ce nouvel état, puis, constatant que la

provision est suffisante, modifie le débit D du compte. Après annulation de la 1ére

transaction, la contrainte d'intégrité D ≤ C n’est plus vérifiée.

TEMPS

READ C

C = C + 1000

WRITE C

t1

TRANSACTION_1

t2

READ A

t3 IF C > 500 THEN

D = D + 500

WRITE D

TRANSACTION_2

Figure 27 : Ecriture inconsistante

68

(b) Interférence entre Lecteur et Ecrivain

Lecture Inconsistante ou sale (Dirty Read)

Une transaction T2 lit une valeur V donnée par une transaction T1. Ensuite la

transaction T1 annule son affectation (ROLLBACK) et valeur lue par T2 est donc fausse.

La Lecture inconsistante ou sale, c’est tout simplement celle d’une valeur temporaire

des données, et non persistante.

Exemple :

La première transaction a pour but de faire un virement entre deux comptes A et B, qui

satisfait la contrainte d'intégrité "somme A+B invariante". La deuxième transaction lit A

et B juste après que la 1ére transaction ait déduit 1000 de A. Elle trouve A+B diminué.

TEMPS

READ A

A = A - 1000

WRITE A

t1

READ B

B = B + 1000

WRITE B

t3

COMMIT t4

TRANSACTION_1

t2

READ A

READ B

TRANSACTION_2

Figure 28 : Lecture sale

69

Lecture non-reproductible (Non-Repeatable Read)

Une transaction lit 2 fois une même valeur et ne trouve pas la même valeur 2

fois puisqu’elle est modifiée par une autre transaction entre les lectures.

Exemple :

Une première transaction consulte les places libres dans un avion et laisse un temps de

réflexion à l'utilisateur. Entre temps, une deuxième transaction, qui voit les mêmes

places libres, valide deux réservations. La 1ère demande à nouveau les places libres: la liste

est diminuée alors qu'elle n'a pas encore choisi ses réservations!

TEMPS

READ P

t1

READ P

t3

READ P

TRANSACTION_1

t2 READ P

P = P-2

WRITE P

T4 COMMIT

TRANSACTION_2

Figure 29 : Lecture non-reproductible

70

Lecture Fantôme (Phantom Read)

C’est presqu’identique au cas précédent, une transaction ajoute des données sans que

les autres s’en aperçoivent ; Il n'y a pas alors de conflit à proprement parler mais seulement

interrogation sur la validité de ces "apparitions fantômes".

Tous ces cas d’interférence ci-haut cités violent la propriété d’Isolation (Isolement [17])

d’une transaction, car c’est elle qui maintient le contrôle de la concurrence.

L’Isolation (Isolement [17]) d’une transaction est appelée sous plusieurs noms tels que

la consistance, le contrôle de concurrence (le problème), la sérialisabilité (la théorie), et le

verrouillage (la solution) [28].

(c) Contrôle de concurrence

Le contrôle de concurrence est la solution appropriée à cette dernière, il se réalise par

l’entremise des algorithmes dont selon [4] la plupart revient parmi ces trois classes

fondamentales : Verrouillage, Estampillage et la certification (ou les algorithmes

optimistes).

Mais en gros, nous avons deux classes de bases : Verrouillage et Estampillage, dont

nous allons parler dans cette section, car la certification n’utilise rien d’autre que

l’estampillage [4].

Le contrôle de concurrence, c’est tout simplement la sérialisabilité, cette propriété

que possède les SGBDs de contrôler l’exécution simultanée des transactions afin qu’elles

produisent les mêmes résultats qu’une exécution séquentielle. Et d’ailleurs, tous ses

algorithmes vont dans ce sens.

(1) Le Verrouillage

C’est la voie la plus utilisé pour implémenter la sérialisation des transactions. Il

consiste à mettre de verrou sur des données où accède la transaction jusqu’à la fin de celle.

Le verrouillage peut être fait en deux modes principaux, le mode Optimiste et le mode

Pessimiste, selon le but pour lequel la transaction accède aux données, soit pour les modifier

ou pas.

• Mode Pessimiste :

La première transaction accédant à la donnée, la verrouille de sorte que les autres

puissent seulement la lire et non la modifier jusqu’à la fin de la première.

La garantie de ce mode réside dans le fait qu’une transaction premièrement accédé dans

la donnée sache toujours lui appliquer des modifications.

71

• Mode Optimiste :

La première transaction accédant à la donnée ne la verrouille aucunement pas. Et

pendant qu’elle progresse, une autre peut toujours modifier la donnée. Si maintenant elle

décide la modifier mais qu’elle découvre les modifications de l’autre, elle doit les signifier

à l’initiateur.

Ici, accéder à la donnée la première n’est pas une garantie pour la modifier.

La classification de verrou, nous donne les modes suivants de verrou :

• Partagé :

Dans ce cas la transaction peut lire l’objet, et les transactions concurrentes ont

également l’accès en lecture à l’objet.

• Exclusif :

Dans ce cas la transaction peut lire et écrire l’objet, et aucune transaction concurrente

n’a accès à l’objet.

Le mode partagé est compatible avec lui-même, et incompatible avec le mode exclusif.

Le mode exclusif est incompatible avec lui-même.

Compatibilité des Verrou selon le mode partagé ou exclusif [33] :

Pas de Verrou Verrou partagé Verrou exclusif

Pas de Verrou Oui Oui Oui

Verrou partagé Oui Oui Non

Verrou exclusif Oui Non Non

Tableau 2: Compatibilité des Verrous (modes)

Compatibilité des opérations de Verrou selon la lecture ou l’écriture :

Lecture Ecriture

Lecture Oui Non

Ecriture Non Non

Tableau 3 : Compatibilité des Verrous (Opérations)

72

Cas d’algorithme de Verrou

Nous allons prendre un exemple d’algorithme utilisation le verrouillage :

> Le Verrouillage à Deux Phases

Dans cet algorithme, les transactions accédant aux données mettent des verrous de

lecture et les convertissent en des verrous d’écriture sur d’autres au moment de la

modification [4] [42].

Pour lire une donnée, il faut :

- Mettre un verrou de lecture sur toutes copies de la donnée, afin que la copie locale

soit aussi verrouillée.

Pour modifier une donnée, il faut que :

- Les verrous d’écriture soient mis sur toutes les copies.

Avant la lecture ou l’écriture de données, la transaction a besoin d’y en avoir respectivement

un verrou de lecture ou d’écriture, mais pour question d’éviter le conflit d’opérations (cfr la

matrice de compatibilité des opérations). Mais la possession du verrou [42] est régie par les

deux règles suivantes :

(R1) Diverses transactions ne peuvent pas posséder simultanément des verrous

conflictuels ou incompatibles

(R2) Une fois qu’une transaction lâche le verrou, il ne pourra en obtenir d’autre.

Le Principe du Verrouillage à Deux Phases

Verrou

Acquisitions Restitutions

Point de Verrouillage

Phase 1 Phase2

Temps

Figure 30 : Le Principe du Verrouillage à deux phases [31]

73

• Première phase : l'acquisition

Du début jusqu'au point de verrouillage, la transaction acquiert des verrous.

• Deuxième phase : le relâchement

Du point de verrouillage jusqu'à la fin, la transaction réalise des écritures dans la base et

relâche les verrous.

Problème de Verrou Mortel ou Inter-Blocage

Il y a un cas d’un verrou mortel lorsque les transactions s’attendent indéfiniment les

une les autres pour accéder aux ressources quand ces dernières vont les lâcher. Il peut

concerner deux ou trois transactions.

Par exemple, une transaction T1 détenant le verrou d’écriture sur l’objet X souhaite en

obtenir un autre sur Y et qu’une autre transaction T2 détenant le verrou d’écriture sur

l’objet Y souhaite en obtenir sur X. Elles sont donc toutes deux inter-bloqués

74

Illustration [42]:

Transactions

T1: BEGIN;

READ (X); WRITE (Y);

END

T2: BEGIN;

READ (Y); WRITE (Z);

END

T3: BEGIN;

READ (Z); WRITE (X);

END

Et maintenant supposons que ces transactions s’exécutent simultanément, chacune s’engageant à son READ avant le END des autres.

Représentons cette exécution partielle par les journaux suivants :

DM A: r1 [x1] ; DM B: r2 [y2] ; DM C: r3 [z3]

Note: ri[x] dénote l’opération dm-read(x) lancé par Ti; DM: Data Manager (Gestionnaire de Ressource ou Données)

A ce point, T1 a le verrou de lecture sur x1, T2 le verrou de lecture sur y2, T3 le verrou de lecture sur z3

Avant de poursuivre, toutes les transactions doivent obtenir des verrous d’écriture. T1 demande des verrous d’écriture sur Y1 et Y2 ; T2 demande des verrous d’écriture sur z2 et z3 T3 demande des verrous d’écriture sur X1

Mais, T1 ne peut pas avoir de verrous d’écriture sur y2, jusqu’à ce que T2 lâche le verrou de lecture. T2 ne peut pas avoir de verrous d’écriture sur z3, jusqu’à ce que T3 lâche le verrou de lecture. T3 ne peut pas avoir de verrous d’écriture sur x1, jusqu’à ce que T1 lâche le verrou de lecture.

Ça c’est un VERROU MORTEL (DEADLOCK)

Bases de Données

X1

Y1 A

X2

Z2 B

Z3 C

Figure 31 : Le Verrou Mortel (DeadLock) [42]

75

Détection, Guérison et Prévention

Pour détecter le verrou mortel, on se serre du graphe des attentes. Ce graphe se

construit au fur et à mesure qu’une transaction demande un verrou sur un objet qui est déjà

verrouillé.

Rappelons qu’une transaction distribuée a une représentation hiérarchique (Arbre :

qui est un graphe [29]), d’où on a :

- Les nœuds sont les transactions

- Les arêtes sont l’attente entre T1 et T2, c'est-à-dire si T1 attend un verrou détenu par

T2

Et il y a verrou mortel ou inter-blocage lorsque ce graphe des attentes contient un

cycle ([29] parle amplement de la notion de graphe).

Figure 32 : Cycle dans le Graphe des Attentes

Pour résoudre ce problème, l’algorithme du Verrouillage à Deux Phases procède

comme suit :

- Il cherche l’inter-blocage local et global. Après avoir détecté, les transactions prises

dans le cycle sont relancées [4] et mais avant cela toutes leurs modifications sont

défaites.

Pour prévenir ce problème,

- [42] montre comment la prévention de l’inter-blocage est implémentée dans le

Verrouillage à Deux Phases. Et là, cette prévention est un plan prudent dans lequel

une transaction est du coup relancée dès que le système a « peur » qu’inter-blocage

peut survenir.

- Une approche dit qu’il faut limiter la profondeur d’attente de transactions bloquées à

un [8] et ceci pour minimiser le traitement dû au fait des redémarrages (relancer) des

transactions.

Les inter-blocages peuvent être carrément évités en répondant toutes les demandes de

verrous à la fois avant qu’une transaction fasse la validation ou simplement à son début.

76

Un autre algorithme utilisant aussi le verrouillage, c’est le WOUND-WAIT (WW).

> WOUND-WAIT (WW)

Ce dernier est similaire au précédent ; mais la simple différence est au niveau du

traitement du problème de Verrou Mortel ou inter-blocage.

Cet algorithme utilise l’estampillage pour gérer ou prévenir le problème d’inter-

blocage :

- A chaque transaction est accordé un numéro à son premier lancement,

- Et les transactions les plus récentes sont empêchées de faire attendre les plus

anciennes. Ainsi la possibilité d’un inter-blocage est éliminée.

- Dans le cas où une ancienne transaction demande un verrou et que celle-ci pourrait

lui mener à attendre une plus récente, cette dernière est « blessé » (WOUND) c'est-à-

dire elle sera relancée sauf si elle est déjà dans sa deuxième phase de son protocole

de validation (dans lequel cas la plaie « WOUND » n’est pas fatale, et sera

simplement ignorée)

(2) L’Estampillage

Un cas d’utilisation des estampilles est montré dans l’algorithme précédent. Mais nous

allons donner un algorithme où les estampilles sont utilisées pour le contrôle de

concurrence.

> Ordonnancement par estampillage

Pareillement et pourtant différemment que le WOUND-WAIT qui lui utilise le verrou,

celui-ci associe plutôt les estampilles avec toutes les données récemment accédées. Il y a un

ainsi ordre d’estampille selon lequel les transactions problématiques (celles qui participent

dans les accès conflictuel de données) doivent suivre lors de leurs exécutions. Sinon la

transaction est relancée (annulée et relancée).

Une demande de lecture de données sera permise si l’estampille du demandeur est

supérieure à celle de l’écriture. Vice versa. Dans le cas contraire, c'est-à-dire, si l’estampille

est inférieure, la règle d’écriture de Thomas [4] dit que les mises-à-jour vont simplement

être ignorées.

Et nous allons clôture ce chapitre avec la notion de niveau d’isolation.

77

(d) Les Niveaux d’Isolation

Les niveaux d’Isolation permettent donc une exécution parallèle des transactions en

donnant ces dernières une certaine possibilité de manipulation des données, et ce à travers

les propriétés d’isolation.

Chaque propriété définit un niveau d’accès aux données en cours de modification

par d’autres transactions en cours. Les données qui sont en cours de modification sont

dites données volatiles [21].

Il faut dire que les Niveaux d’Isolation entre en ligne de compte pour la résolution de

problème de contrôle de concurrence.

+ READCOMITTED : les données volatiles ne peuvent pas être lues pendant la

transaction, mais peuvent être modifiées.

+ READUNCOMMITTED : les données volatiles peuvent être lues et modifiées

pendant la transaction.

+ REPEATABLEREAD : les données volatiles peuvent être lues mais pas modifiées

pendant la transaction. De nouvelles données peuvent être ajoutées.

+ SERIALIZABLE : niveau d’isolation par défaut. Les données volatiles peuvent être lue

mais pas modifiées. De même aucune nouvelle donnée ne peut être ajoutée pendant

la transaction.

Le choix de niveaux est capital, et dépend souvent de la nature d’une application.

78

[Chapitre III]

79

Chapitre III

Les applications

Dans ce chapitre où nous avons consacré nos efforts pour essayer tant soit peu de

rattraper la pratique. Voici les outils utilisés pour arriver à bon bout :

- Le SQL SERVER (version 2008) de Microsoft :

- La plateforme .NET (Framework 3.5, version 2008 : Full Team), précisément le

langage C# de Microsoft :

- UML (Unified Modeling Language) :

En outre, on aura à présenter l’intranet gouvernemental de la République sur lequel

nous avons pu concevoir une application (distribuée) et afin cette application. Mais avant

tout, commençons par présenter les outils.

III.1. Mécanisme de Répartition sous SQL SERVER

Nous présentons ici des notions essentiales et inhérentes à ce que traite ce travail, une

grande source nous vient de [53], [19], [38].

III.1.1. SQL SERVER

Microsoft SQL Server est un système de gestion de base de données (abrégé en SGBD

ou SGBDR pour « Système de gestion de base de données relationnelles ») développé et

commercialisé par la société Microsoft.

III.1.2. Les Bases de Données

Les bases de données sont contenues physiquement dans des fichiers. Les fichiers portent généralement les extensions :

MDF (Main Database File) pour le premier fichier de données NDF (Next Database File) pour les autres fichiers de données LDF (Log Database File) pour les fichiers du journal de transaction

http://fr.wikipedia.org/wiki/Syst%C3%A8me_de_gestion_de_base_de_donn%C3%A9es

http://fr.wikipedia.org/wiki/Base_de_donn%C3%A9es_relationnelle

http://fr.wikipedia.org/wiki/Microsoft

80

Les fichiers sont divisés en blocs de 8196 octets appelés pages et organisées par blocs de 8 pages appelées extensions. Jusqu'à la version 2000, les lignes étaient limitées à une taille maximale de 8060 octets (les colonnes de type LOBs (image, text, ntext) n'étant pas comptabilisées dans cette limite). Depuis la version 2005 il est possible de dépasser largement cette limite et d'aller jusqu'à 2 milliards d'octets. En revanche la taille utile de la page est de 8096 octets.

Les bases de données ne peuvent fonctionner que lorsque tous les fichiers sont présents.

Les fichiers de données sont regroupés logiquement dans la base de données dans des groupes de fichiers. Ces fichiers et groupes de fichiers peuvent être sauvegardés de façon indépendante à condition qu'il n'existe aucune interdépendance logique entre les objets d'un fichier et d'un autre (intégrité référentielle en particulier).

III.1.3. Services et moteurs

III.1.3.1. SQL Server

Il s'agit du moteur de bases de données. À chaque instance de SQL Server correspond un service Windows Sql Server. Ce service peut être repéré dans les services Windows sous les noms MSSQL$Nom_instance pour les instances nommées et MSSQLServer pour l'instance par défaut.

Chaque instance créée possède au départ 4 à 6 bases de données systèmes. Le moteur SQL Server s'appuie sur la base de données système master qui contient la définition des autres bases de données.

Les autres bases systèmes sont :

msdb : utilisée par l'agent SQL Server, la réplication, Data Transformation Services, Integration Services...

model : utilisée comme modèle pour créer de nouvelles bases de données. Toute nouvelle base de données est une copie de celle-ci.

tempdb : Base de données temporaire, elle sert à stocker les données temporaires créées par des utilisateurs ou générées par des curseurs, des créations d'index, lors d'un tri volumineux. Sous SQL Server 2005, elle contient aussi les versions d'enregistrement générées par les niveaux d'isolation SNAPSHOT, le contenu des pseudo tables inserted et deleted utilisées dans les triggers et celles générées par les opérations d'index en ligne. Cette base de données système est systématiquement vidée au démarrage du service SQL Server.

distribution : N'est présente que dans le cadre d'une réplication si votre serveur joue le rôle du distributeur.

mssqlsystemresource : Présente uniquement à partir de SQL Server 2005. Elle n'est pas accessible directement, et elle contient tous les objets systèmes (hors tables).

http://fr.wikipedia.org/wiki/Octets



http://fr.wikipedia.org/wiki/R%C3%A9plication

81

III.1.3.2. SQL Server Agent

Il s'agit de l'agent de maintenance de l'instance de SQL Server. À chaque instance de SQL Server correspond un service Windows Sql Server Agent. Ce service peut être repéré dans les services Windows sous les noms SQLAgent$Nom_instance pour les instances nommées et SQLAgent pour l'instance par défaut. Le moteur SQL Server Agent s'appuie sur la base msdb. Ce moteur permet de gérer les sauvegardes, les plans de maintenance, les travaux planifiés, la surveillance de la base, les alertes administratives...

L'Agent a aussi comme rôle la surveillance du service de SQL Server et le déclenchement automatique du redémarrage de celui-ci en cas d'arrêt inattendu.

III.1.4. Transactions

SQL Server est un SGBD transactionnel. Il est capable de préparer des modifications sur les données d'une base et de les valider ou de les annuler d'un bloc. Cela garantit l'intégrité des informations stockées dans la base.

Lors d'une transaction, les blocs de données contenant les lignes de données modifiées par cette transaction sont verrouillées. Les autres utilisateurs, en fonction du niveau d'isolation choisi, doivent attendre ou non la fin de la transaction pour pouvoir les modifier à nouveau.

Les verrouillages s'effectuent au niveau des lignes, pages, extensions, tables ou base de données. SQL Server ne verrouille que les ressources dont il a besoin (par défaut les enregistrements) et en fonction des besoins peut verrouiller à un niveau plus élevé (pages ou objet). Cela évite aux utilisateurs d'attendre la fin d'une transaction pour mettre à jour des lignes de données qui n'ont pas été touchées par une modification et permet de diminuer la quantité de ressources consommées

Les transactions sont enregistrées dans le journal de transaction et les modifications des données sont intégrées à la base de données lors de points de contrôle (check point). Il est possible de forcer un point de contrôle grâce à l'instruction CHECKPOINT

Le journal des transactions peut être conservé de trois manières différentes :

Mode simple : toutes les modifications sont enregistrées dans le journal sauf pour les instructions de chargements en bloc (BULK INSERT, CREATE INDEX, reconstruction d'index et SELECT INTO) qui sont enregistrées de manière plus simple. Les transactions terminées sont supprimées du journal de transaction à chaque point de contrôle.

Mode journalisé en bloc : journalise de façon minimale les opérations en bloc. Ce mode est utilisé pour effectuer d'importantes opérations de masse.

http://fr.wikipedia.org/wiki/Syst%C3%A8me_de_gestion_de_base_de_donn%C3%A9es

82

Mode complet : toutes les modifications sont enregistrées dans le journal. Les transactions terminées dont les données sont écrites sur le disque sont supprimées du journal de transaction à chaque sauvegarde de celui-ci.

Dans les 2 derniers modes, il est possible de sauvegarder la base de données et de la restaurer telle qu'elle était à n'importe quel point du temps à la seconde près et à la transaction près (avec cependant des limites pour le mode journalisé en bloc). Ce mode permet aussi la sauvegarde de fichiers ou de groupes de fichiers.

III.1.4.1. Distributed Transaction Coordinator

Connu aussi sous le nom de MS DTC, sert a gérer les transactions distribuées. C’est-à-dire les transactions entre plusieurs serveurs de transactions SQL Server, entre un serveur SQL Server et des serveurs de base de données autres, entre plusieurs sources de données différentes, qu'ils soient des moteurs de base de données ou de simples composants.

III.1.4.2. Gestion de Transaction sous SQL SERVER

On a vu que le grand problème de transaction, c’était la concurrence et pour le gérer, SQL SERVER implémente le niveau d’isolation pour pallier aux anomalies transactionnelle que peuvent causer cette concurrence.

III.1.5. Notion de répartition sous SQL SERVER

Après avoir conçu une Base de Donné Répliquée, il faudrait les fragmenter et puis l’allocation de ces fragments dans différents sites, ceci peut s’accompagner de la réplication. Pour faire la fragmentation du schéma global et puis l’allocation des fragments, le SQL SERVER dispose d’une technologie : transactional replication [19].

La “Transactional réplication”: la réplication transactionnelle, c’est un mécanisme

utilisé par le SQL SERVER pour permettre de publier de donnée incrémentale et les

changements de schéma aux abonnés (souscripteurs). Les changements sont publiés (le flux

de réplication) dans l’ordre dans le quel ils ont été effectués, et effectivement il y a un temps

de latence entre les changements dans le Publisher et l’abonnés [19].

Les architectures étudiées dans le chapitre 1 d’un système distribute sont aussi

appliquées, à savoir le peer-to-peer et le client-serveur.

La réplication transactionnelle peer-to-peer, par exemple, en SQL SERVER simplifie

l’implémentation la topologie de la réplication transactionnelle bidirectionnelle, où le flux de

données va dans les deux sens.

83

Figure 33 : Réplication peer-to-peer avec trios et quatre nœuds [19]

III.1.5.1. Technologies

La réplication transactionnelle et la réplication peer-to-peer utilise la même architecture pour transférer entre les servers dans une topologie de réplication. L’illustration suivante est une vue sur les composants participant dans la réplication transactionnelle.

Figure 34 : Vue de l’architecture de la Réplication transaction [19]

84

Voici les trois roles minimum d’un serveur requis pour la réplication transactionnelle :

• Publisher, pour la base de données de la publication

• Distributor, pour la base de données de la distribution

• Subscriber, pour la base de données de la subscription

Les différents agents sur lesquels la réplication transactionnelle se repose, pour

effectuer les taches associées au transfert des modifications (changements) et à la

distribution des données. On a [38]:

• Snapshot Agent, qui tourne au niveau du Distributor (Distributeur). Il prépare les

fichiers de schéma et de données initiales des tables et objets publiés, enregistre les

fichiers du snapshop et les informations sur la synchronisation dans la base de

données de la distribution.

• Log Reader Agent, qui tourne au niveau du distributor (distributeur). Il connecte au

Publisher et lui transfère les transactions marquées pour la réplication à partir du log

(journal) de transaction de base de données de la publication à la base de données

de la distribution.

• Distribution Agent, qui tourne au niveau du Distributor pour pousser les

souscriptions et au niveau du Subscriber pour tirer les souscriptions. Il appique le

snapshop initial au Subscriber (souscripteur) et transfère les transactions tenues

dans la base de données aux souscripteurs.

• Queue Reader Agent, qui tourne au niveau du Distributor. Il est seulement utilisé

pour la réplication transactionnelle avec des souscriptions modifiables et renvoie les

modifications effectuées sur les Subscriber au Publisher.

III.1.5.2. Réaliser une Publication et un abonnement sous SQL SERVER

Nous allons à la fois montrer ceci dans la section dédiée à l’application proprement dite et montrer comment faire une fragmentation horizontale, verticale et hybride pour une allocation donnée de données.

85

III.2. Gestion de Transactions par la programmation

sous .NET (Framework 3.5)

.NET est une plateforme de programmation, un produit de MICROSOFT, depuis sa version la plus antérieure (2005) que celle-ci (2008) et jusqu’à l’actuelle (2010), on pouvait déjà et on peut donc arriver utiliser les transactions à la place de requêtes SQL, on en a vu l’avantage, et aussi arriver à gérer ces transactions, ses anomalies découlant de la concurrence par bien sûr les mécanismes de niveau d’isolation.

Il va de soi de comprendre que nous n’avons eu qu’à utilisé la version de .NET à notre disposition étant donné que l’implémentation de base de classes manipulant les transactions est restée la même. Par conséquent, nous avons utilisé la version .NET 2008, avec le langage C# ;

C’est donc cette voix de solution que nous avons choisie pour pouvoir aisément les transactions, et même les transactions concurrentes.

III.2.1. Les Transactions locales

Dans l’ADO (Activex Data Object), l’API (Application Programming Interface) de Microsoft pour l’accès de données, pour créer une transaction, on a en premier la classe « DbTransaction » se trouvant dans l’espace de nom « System.Data.Common » du composant System.data.dll du Framework .NET [21]. Toutes les autres classes des transactions en dérivent.

Cette classe possède des méthodes «BeginTransaction, Commit et Rollback », essentielles dans la mise en œuvre des transactions.

Voici les espaces de noms, où se trouvent les classes selon qu’il s’agit de fournisseur aux bases de données :

- System.Data.Odbc.OdbcTransaction

- System.Data.OleDb.OleDbTransaction

- System.Data.OracleClient.OracleTransaction

- System.Data.SqlClient.SqlTransaction

Nous allons donc utiliser le dernier, pour le cas qui est le nôtre.

86

Voici les méthodes principales :

- BeginTransaction (): méthode qui permet de débuter la transaction. - Commit() : méthode qui permet de valider les modifications effectuées par les

requêtes exécutées au sein de la transaction. - Rollback() : méthode qui permet d’annuler ces modifications.

Illustration

Soit un Serveur nommé PRIMATURE_SERVER, où on a une base de données nommée GestPers, et précisément la table agent ;

// C# import System.Data.SqlClient.SqlTransaction; import System.Data; string connectionString = "Data Source=.\PRIMATURE_RESVER;Initial Catalog=GestPers;Integrated Security=true"; using (SqlConnection connection = new SqlConnection(connectionString)) { connection.Open(); SqlTransaction transaction = connection.BeginTransaction(); SqlCommand commande = connection.CreateCommand(); commande.Transaction = transaction; try { //commande 1 commande.CommandText = "INSERT agent (id, nom, prenom, adresse, telephone, mail, information) VALUES (1, 'Tshabola', 'Joseph', '0', '0', '0', '0')"; commande.ExecuteNonQuery(); //commande 2 commande.CommandText = "INSERT agent (id, nom, prenom, adresse, telephone, mail, information) VALUES (2, 'Kalenda', 'Isaac', '0', '0', '0', '0')"; commande.ExecuteNonQuery(); transaction.Commit(); MessageBox.Show("Transaction validée"); } catch (Exception Ex) { transaction.Rollback(); MessageBox.Show(Ex.Message); } finally { connection.Close(); } }

87

III.2.2. Les Niveaux d’Isolations

Pour arriver à gérer des nombreuses transactions concurrentes, on dispose ici de

l’Enumération « IsolationLevel » associée à l’objet Transaction, dont voici les propriétés :

- Chaos : les données en attente de transactions très isolées ne peuvent être écrasées.

- ReadComitted : les données volatiles ne peuvent pas être lues pendant la

transaction, mais peuvent être modifiées.

- ReadUncommitted : les données volatiles peuvent être lues et modifiées

pendant la transaction.

- RepeatableRead : les données volatiles peuvent être lues mais pas modifiées

pendant la transaction. De nouvelles données peuvent être ajoutées.

- Serializable : niveau d’isolation par défaut. Les données volatiles peuvent être lue

mais pas modifiées. De même aucune nouvelle donnée ne peut être ajoutée pendant

la transaction.

- Snapshot : les données volatiles peuvent être lues. La transaction vérifie que les

données initiales n’ont pas changées avant de valider la transaction. Cela

permet de régler les problèmes liés à l’accès concurrentiels aux données.

- Unspecified : aucun niveau ne peut être déterminé.

Chaque propriété définie un niveau d’accès aux données en cours de modification

par d’autres transactions en cours. Les données qui sont en cours de modification sont

dites données volatiles [21].

Illustration

// C#

//…

SqlConnection oConnexion;

SqlTransaction oTransaction = null;

SqlCommand oCommande;

IsolationLevel oNiveauIsolationDonnees;

try

{

// Création de la connexion.

oConnexion = new SqlConnection(@"Data Source=.\PRIMATURE_RESVER;Initial Catalog=GestPers;Integrated Security=true") ;");

// Ouverture de la connexion.

oConnexion.Open();

if (ChkUtiliserTransaction.Checked)

{ // Création de la transaction.

oTransaction =

88

oConnexion.BeginTransaction(oNiveauIsolationDonnees);

}

// Création de la commande.

oCommande = new SqlCommand("SELECT * FROM agent", oConnexion,

oTransaction);

// Création et paramétrage du DataDapter.

oDataAdapter = new SqlDataAdapter(oCommande);

SqlCommandBuilder oCommandBuilder = new

SqlCommandBuilder(oDataAdapter);

// Création de la table de données.

oTable = new DataTable("agent");

// Exécution de la requête et remplissage de la table de données.

oDataAdapter.Fill(oTable);

// Affichage des données.

LstAgent.DataSource = oTable;

}

catch (Exception aEx)

{

MessageBox.Show(aEx.Message);

}

// …

89

III.2.3. Les Transactions Distribuées

Une transaction distribuée est ainsi dite suite au fait qu’il fait appelle à plusieurs ressources. D’où le Gestionnaire de ressources, géré par le gestionnaire de transaction.

Le gestionnaire de Transaction, c’est le DTC (Distributed Transaction Coordinator), qui est démarré manuellement (Invite de commande : > Services.msc), faute de quoi il y a erreur.

Figure 35 : Interface de Démarrage du Service de DTC

Lorsqu’une transaction est amorcée dans une application, une requête de validation est envoyée au gestionnaire de transaction. Ce dernier enverra une commande de préparation à tous les gestionnaires de ressources de la transaction. Après traitement de la commande les gestionnaires de ressources enverront à leur tour un message d’échec ou de succès de préparation au gestionnaire de transaction.

90

Illustration

string connectionString1 = = "Data Source=.\PRIMATURE_RESVER;Initial

Catalog=GestPers;Integrated Security=true";

string connectionString2 = = "Data Source=.\FINANCE_RESVER;Initial

Catalog=GestPers;Integrated Security=true";

using (TransactionScope Transaction = new TransactionScope()) {

using (SqlConnection connection1 = new SqlConnection(connectionString1)) {

try {

SqlCommand commande = connection1.CreateCommand();

commande.CommandText = "DELETE FROM agent WHERE matricule = 'K88s';";

connection1.Open();

commande.ExecuteNonQuery();

connection1.Close();

using (SqlConnection connection2 = new SqlConnection(connectionString2)) {

try {

SqlCommand commande2 = connection2.CreateCommand();

commande.CommandText = "DELETE FROM salaire WHERE matricule = 'K88s';";

connection1.Open();


connection2.Close();

} catch (Exception ex) {

MessageBox.Show(ex.Message);

}

} catch (Exception ex) {

MessageBox.Show(ex.Message);

}

}

Transaction.Complete();

}

Ainsi, nous venons de voir qu’il était possible de gérer les transactions sous la

plateforme .NET

91

III.3. Intranet Gouvernemental de la RDC

(République Démocratique du Congo)

La mise au point de l’intranet gouvernemental est un projet sous le nom de « e-

Gouvernement » mené par la KOICA (Korea Intrnational Cooperation Agency), grâce à son

programme APD (Aide Public au Développement), conformément à l’ordonnance définie

07/. 018 du 16 mai 2007 fixant les attributions des Ministères. Le titre du projet est

« L’infrastructure des TIC pour le projet d’E-Gouvernement de la République Démocratique

du Congo ».

III.3.1. Quelques définitions

III.3.1.1. Intranet :

Un Intranet est l'utilisation de tout ou partie des technologies et des infrastructures de l'Internet pour les besoins de transport et de traitement des flux d'informations internes d'un groupe d'utilisateurs identifiés.

Il peut être constitué de nombreuses applications et services :

forums de discussion entre des équipes projets au sein d'une entreprise

interconnexion sécurisée des réseaux locaux de l'entreprise et ses filiales en utilisant les infrastructures publiques de l'Internet

la création de serveurs Web interne

la création d'un serveur Web, accessible depuis l'entreprise et depuis l'Internet par une communauté fermée d'utilisateurs, les clients ou les partenaires de l'entreprise par exemple

la mise en place d'une messagerie

l'interconnexion des différents systèmes d'information de l'entreprise et de ses fournisseurs en utilisant le protocole TCP/IP

Donc en se basant sur le protocole TCP/IP (Transmission Control Protocole/Internet Protocole) qui est un protocole de l’Internet, il arrive à fournir pas mal d’applications et services autant que le ferait l’internet.

Pourtant, reste des différences entre Intranet et Internet :

- Internet = des infrastructures publiques de transmissions de données (payées par les opérateurs Internet.

- Intranet = des infrastructures privées de transmission de données (les réseaux locaux)

- une plus grande maîtrise des infrastructures réseaux et du débit possible. Il est plus facile sur Intranet d'envisager des applications qui restent difficiles à exploiter sur l'Internet telle que la visioconférence.

92

III.3.1.2. E-Gouvernement :

L’E-Gouvernement est l’utilisation des technologies de l’information et de la communication pour améliorer l’accès et la prestation des services publics au bénéfice de la population.

III.3.2. Objectif du projet

Crée l’e-Gouvernement (electonic-Gouvernement), impliquerait une utilisation des

technologies de l’information et de la communication (TIC) par les Institutions publiques et

le gouvernement de la RDC pour rendre les services de l’Etat plus accessible à leurs

utilisateurs et améliorer leurs propres opérations internes.

Les principaux objectifs du projet sont les suivants (quelques):

- renforcer la participation de citoyens au processus décisionnel du gouvernement.

- Améliorer la transparence et l’efficacité de dans l’administration publique.

Pour ne citer ces deux.

III.3.3. Avantages pour les utilisateurs

Nous citerons des avantages parmi tant évoqué dans [35], mais les plus éloquents, par

rapport à notre travail :

- Améliorer la facilité d’usage (moins de files d’attente, plus d’information, plus

d’informations, pas besoin de se déplacer).

- Offrir des nouveaux services personnalisés aux citoyens et aux entreprises (par

exemple, le calcul d’impôt en ligne, le suivi des procédures administratives, la

consultation du dossier personnel, l’emploi, l’envoi des informations sur l’intranet/

internet).

- Simplifier les procédures notamment en réduisant les formulaires, les imprimés et les

certificats de valeur.

Pour ne citer ceux-ci.

93

III.3.4. Situation actuelle de l’Intranet

La situation actuelle peut être présentée dans le tableau qui suit :

III.3.4.1. Tableau des Projets

Item 1er Projet (2007-2008)

2ème Projet (2008-2009)

3ème Projet (2009-2010)

Nom du projet Projet d’Etablissement du

Réseau Gouvernemental en

RDC

Projet d’Etablissement du

Réseau Gouvernemental de 6 Ministères en RDC

Etablissement Intranet entre le

Ministère des Mines et ses trois

organismes majeurs

Agence d’exécution Ministère des affaires étrangères

Ministère des affaires étrangères

Ministère des Mines

Sites ciblés Présidence, Ministère des

affaires étrangères, Primature, Ministère

de la Fonction Publique

Ministère des Postes, Téléphones et

Télécommunications, Ministère des

Finances, Ministère du Budget et

Ministère d’Infrastructure,

Travaux Publics et Reconstruction

Ministère des Mines, CTCPM, SAESSCAM,

CAMI

Nombre de Sites 4 6 4

Tableau 4 : Projets Réseaux Gouvernemental par KOICA [35]

Ce qui fait qu’actuellement l’Intranet compterait 14 sites dont trois sous réseaux

interconnectés.

94

III.3.4.1. Présentation topologique de l’Intranet

Site 6

Site 10

Site 9

Site 5

Site 7

Site 8

Site 1

Site 2 Site 3 Site 4

Site 11

Site 12 Site 13 Site 14

Projet 1 Projet 2

Projet 3

Figure 36 : l’Intranet Gouvernemental [35]

95

Tableau de correspondance de sites et leurs noms

Site Noms

1 Ministère des Affaires Etrangères

2 Présidence

3 Primature

4 Fonction Publique

5 Justice

6 Ministère des Postes, Téléphones et Télécommunications

7 Ministère du Budget

8 Ministère du Plan

9 Ministère d’Infrastructure, Travaux Publics et Reconstruction

10 Ministère de Finance

11 Ministère de Mines

12 CTCPM

13 SAESSCAM

14 CAMI

Tableau 5 : Tableau de correspondance de numéro de sites et leurs noms

III.4. Mise en place d’un Système d’Information de

Traitement de Salaire des Agents de l’Etat

C’est à cette section que sont dédiées toutes les précédentes, elles ont balisé la route,

préparé les outils pour son abordage aisé, ou disons le autrement, c’est ici qu’on essaie de

concrétiser toutes les notions avancées précédemment.

III.4.1. Circonscription

Ce problème de traitement de salaire ou bien de gestion de paie des agents couvrent

normalement toutes les institutions étatiques. Et pourtant pour insérer dans ce projet

d’intranet gouvernemental, selon même ses objectifs, notre participation plus

concrètement, nous nous nicherons sur des sites contextuellement les plus stratégiques.

96

On a donc :

- Fonction publique : qui immatricule tous les agents de l’Etat,

- Finance : qui salarie ces agents sur bases de la liste agents immatriculés en

provenance de la Fonction publique.

Ces sont les deux sites principaux, pour notre cas ; mais il faut dire que ces sites à part

leurs taches administratives, sont aussi des institutions publiques avec des agents. On juge

les autres sites de normaux

III.4.2. Modélisation du Système d’Information avec l’UML

UML, Unified Modeling Language : langage de modélisation, ici, pour des systèmes

d’Information. Elle dispose de plus d’une dizaine de diagramme pour la modélisation, mais

nous allons nous service de quelques un qui nous permettent d’étayer le processus de la

création de notre application.

Cette modélisation débouchera sur une Application Informatique, un logiciel que nous

allons nommer « SalaryManager » : Gestionnaire de Salaire, en Français.

III.4.2.1. Spécification Initiale du Système

En vue d’une amélioration du présent système de paiement des agents, cette batterie

d’étapes va nous permettre d’automatiser des processus manuels, d’où une application

informatique est attendue à l’issue de cette étude.

Cette application informatique est conçue à l’idée de pouvoir :

- Aider l’entité habilitée (Ministère de Finance) de payer les agents de l’Etat, à calculer

la masse salariale (périodique aussi) correspondante à toutes les institutions, et à

réellement payer les vrais agents sur base des listes des agents immatriculés.

- Aider l’entité habilitée (Ministère de Fonction Publique) d’immatriculer les agents, à

savoir l’effectif des agents, et ce par institution.

- Aider les institutions de pouvoir enregistrer de nouvelles unités (NU), de les envoyer

(sans se déplacer) à la Fonction Publique en vue d’immatriculation et de calculer

localement le salaire de chaque agent selon tous les éléments de salaire (indemnité,

prime, etc.) et de les envoyer à la Finance en vue de la paie.

Cette application sera par conséquent répartie.

97

o A qui l’application, est-elle destinée ?

Comme dit tantôt, à l’entité du Ministère de la Fonction Publique chargée

d’immatriculation, à gestionnaire de paie de la cellule de paie du Ministère de la

Finance, et aux gestionnaires de paies de chaque institution.

o Quels problèmes l’application, résoudra-t-elle ?

Permettre une immatriculation aisée, connaître l’effectif des agents, calcul de la

masse salariale des institutions étatique et individuelles des agents. Conséquence

logique, ne payer que les vrais agents immatriculés.

o Comment l’application fonctionnera-t-elle ?

Cette application en est naturellement une dont les taches sont répartie entre aux

moins trois sites, elle travaille :

- En client-serveur : architecture 3-tiers (interface ou présentation, logique de

programmation, et donnée), précisément client-serveur de donnée, entre

l’application (en C#) et SQL SERVER(les Serveurs) ;

- Et en peer-to-peer, pour ce qui des serveurs de base de données entre eux.

III.4.2.2. Enoncé du problème

En vue d’une automatisation de processus de paiement des agents et d’ailleurs

conformément au projet e-Gouvernement, il est question ici de faire une gestion

informatisée des ressources humaines de l’Etat qui est un volet non négligeable dans la

gestion de la RDC, celle-ci est l’apanage de la FONCTION PUBLIQUE qui est l’un de site

compté dans l’Intranet Gouvernemental.

La fonction publique est l’entité sur circuit prend en charge l’élaboration des

matricules des employés de l’Etat, un employé appartient à une entreprise publique, il

possède un matricule que lui procure la fonction publique de la manière suivante :

- L’employé arrive comme une nouvelle unité dans le service lui attribué par ses

supérieurs,

- Après approbation de ses qualités, une liste des personnes devant être affectées est

envoyé au ministère de travail pour la signature du ministre qui est significative d’un

engagement totale, ce matricule confère un grade à l’employé en fonction de ses

aptitudes et du temps passé dans la société ;

- L’employé exerce une fonction spécifique dans la société son affectation,

- La Fonction publique peut à tout moment selon l’ordre ou un arrêté transférer un

employé une institution à une autre

98

- Chaque entreprise elle-même 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, elle participe aussi le calcul de salaire de chaque

agent, puis le transfère à la finance pour la paie selon le listing des immatriculés en

provenance de la Fonction Publique.

L’entité finance du présent projet a pour mission d’enregistrer la masse monétaire

(volume de paiement) à remettre aux agents de l’Etat répertoriés par la fonction publique,

les finances reçoit la liste de chaque entreprise selon le barème de paiement prévu.

III.4.2.3. Analyse du Domaine

De ce qui précède c'est-à-dire l’énoncé, nous allons présenter des modèles d’analyse

qui résultent aussi bien de recherche, du bons sens que de l’expérience du monde réel. D’où,

on a :

- Les modèles d’interactions : qui montre les objets du système coopère pour obtenir

un résultat [49], on ne va présenter ici que le Diagramme de Cas d’Utilisation et le

Diagramme d’Activités.

- Les modèles de classes : décrit la structure statique des objets d’un système et leurs

relations [49], on a seulement le Diagramme de classe.

- Les modèles d’états : décrit les états successifs d’un objet au cours du temps. On n’a

que le Diagramme d’état.

III.4.2.3.1. Diagramme de Cas d’Utilisation

Voici les acteurs du système :

- Ministère de la fonction publique

- Ministère de la Finance

- Autres sites : regroupe tous les autres sites qui n’ont pas de taches spécifiques

comme les deux premiers, mais y compris ces deux premiers.

99

Système de Traitement et paies de Salaires

Enregistrement des Agents

(NU)

Calcul des salaires des

agents

Authentification

« Inclut »

Immatriculation des

agents

« Etend »

Autres Sites

« Inclut »

« Etend »

Ministère de la

Fonction Publique

Calcul d’effectifs des

agents

« Etend »

Calcul du volume salarial et

paie des agents

« Etend »

« Etend »

« Inclut »

Ministère de la

Finance

Figure 37 : Diagramme de Cas d’Utilisation

- Résumé de quelques cas d’utilisation :

a) Enregistrement des Agents (NU) : par « Autres sites », mais précédé d’une

authentification, qui donne lieu (b) et (c).

b) Calcul de salaire des agents

c) Immatriculation des agents : qui permet de calculer le vrai effectif des agents

d) Calcul du volume salarial et paie des agents : qui étend de (b) et (c).

100

III.4.2.3.2. Diagramme de Classe

On a donc :

- Identification de classes pertinentes : agent, grade, fonction, service, indemnité,

prime, prêt, institution, salaire, retenue ;

- Identification des associations pertinentes : prendre, avoir, appartenir, concerner,

immatriculation, toucher, tirer sur.

- Identification des attributs des objets :

o Agent (codeagent, nom, postnom, prenom, sexe, date_naissance, etat_civil, nombre_enfant, telephone, avenue, numero, quartier, commune, niveau_etude, date_embauche) ;

o Fonction (idfonction) ; o Grade (idgrade, salaire_base); o Indemnite (nomIndemnite, info) ; o Prêt (numpret, libelle, montant, date_pret) ; o Prime (nomPrime, info) ; o Retenue (nomRetenue, montant) ; o Salaire (numSalaire, trace_operation, net_a_payer, date_paiement,

mois_paiement) ; o Service (idservice, info) ; o Institution (nomInstitution, adresse).

101

Agent

Grade

Fonction

Service

Indemnité

Prime

Retenue

Salaire

Institution

Prêt

ConcernerIndemnité

ConcernerPrime

Immatriculation

Toucher*

1

Ap

pa

rte

nir

*

1

* *

*

*

Avo

irFon

ction *

Avo

irG

rad

e

*

1

1

Pre

nd

re

*

1

Tire

r su

r

*

*

Montant

Montant

*

*

Figure 38 : Diagramme de Classe

Les méthodes ou opérations des classes

Voici les méthodes génériques et immanquables des toutes ces classes, y compris des classes associations :

- Insérer(…) - Modifier(…) - Suppression (…) - Charger_Information() - Etc.

102

III.4.2.3.2. Diagramme d’état

- Identifications des classes du domaine ayant des états Trouver des états et les événements (sont dans les parenthèses) :

o Agent : Nouvelle Unité – NU (événement : enregistrement), Immatriculé (événement : immatriculation)

Selon la limitation du système, on peut se limité à ces deux états de la classe

Nouvelle Unité (NU)

Immatriculé Récrutement

Immatriculation

Agent

Figure 39 : Diagramme d’état de la classe Agent

103

III. 4.2.3.3. Diagrammes d’Activités

- Pour l’immatriculation d’un nouvel agent

Autres Sites Fonction Publique Finance

Enregistrement de NU

Vérifier la NU

Immatriculer NU

Mise à jours de la Base de Données

Pour nouveaux immatriculés

Immatriculation

Mise à jours de la Base de Données

Pour nouveaux immatriculés pour

La paie

Figure 40 : Diagramme d’Activité pour l’immatriculation d’un agent

104

- Pour le calcul et la paie des agents immatriculés


Calcul des salaires des agents

locaux

Listing des agents

immatriculés

Calcul de volume

salarial des Agents

immatriculés

Envoi de la masse

Salariale aux

Institutions

Paiement

Figure 41 : Diagramme d’Activité pour le calcul et la paie des Agents immatriculés

105

III.4.2.4. Conception et Implémentation du Système

A cette phase, il est plausible de pouvoir décider du stockage des données. Force est de constater que les informations qui circulent entre les entités sont des informations fréquemment utilisées, d’où l’idéal c’est l’utilisation de Base de donnée.

Et pour le cas qui est le notre, vu la nature intrinsèquement distribué du Système

d’Information, nous allons utiliser les bases de données distribuée ou mieux répartie (BDR), pour profiter de ses avantages.

Dans ce cas, nous allons premièrement présenter le schéma global de notre base de données répartie à partie de notre diagramme de classes.

Et signalons que la conception de notre BDR sera descendante, vu que nous sommes

entrain de la créer nouvellement.

III.4.2.4.1. Schéma Global

Toutes les classes et classes association deviendront des tables, et spécialement ces

dernières bénéficieront des identifiants de ses participants, et on aura donc un modèle comme ci-dessous :

Agent

CodeagentnomPostnomPrenomSexedate_naissanceetat_civilnombre_enfantTelephoneAvenueNumeroQuartierCommuneniveau_etudeidserviceidgradeIdfonctiondate_embauche

Fonction

idfonction

Prêt

numpretlibellemontant date_pretCodeagent

Service

Idserviceinfo

Grade

idgradesalaire_base

Retenue

nomRetenuemontant

Indemnite

nomIndemniteinfo

Prime

nomPrimeinfo

ConcernerPrime

idgradenomPrime

montant

Institution

nomInstitutionadresse

Salaire

numSalairetrace_operationnet_a_payerdate_paiementmois_paiementCodeagent

ConcernerIndemnite

idgradenomIndemnitemontant

immatticulation

CodeagentnomInstitution

matricule

Tirer_sur

numsalairenomRetenue

Figure 42 : Diagramme de classe avec toutes les propriétés et les classes association

106

III.4.2.4.2. Fragmentations et Allocations

Le tableau ci-dessous, nous permettra de montrer comment les fragments seront

placés ou alloués aux sites.


Nous trouverons toutes les tables, sauf « Institution » et « Immatriculation »

Ici, nous aurons 3 tables Et ici, 3 tables

Agent Fonction Grade Indemnite Prêt Prime Retenue Salaire Service ConcernerPrime ConcernerIndemnite Tirer_sur Immatriculation

Agent Institution Immatriculation

Agent Salaire Immatriculation

Tableau 6 : Fragmentations et allocations aux sites

Note : Rappelons que les Sites Fonction Publique et Finance sont aussi représentées par « Autres Sites », de par le fait elles ont aussi des agents à gérer localement.

Fragmentations et types de fragmentation utilisés

- De « Autres Sites » vers « Fonction Publique » : la fragmentation verticale de la table Agent, on a : Select codeagent, nom, postnom, prenom from Agent;

Ceci dans le but de permettre à la Fonction Publique de pourvoir immatriculer

les agents (NU) dans la table Immatriculation

107

- De « Fonction Publique » vers « Autres Sites » : la fragmentation hybride de la

table Immatriculation, on a :

Select codeagent, matricule from Immatriculation where institution =

‘primature’

Ceci dans le but de permettre aux autres de pouvoir savoir ceux qui sont

immatriculé

- De « Fonction Publique » vers « Finance » : ici on prend le plus grand

fragment, à savoir la table elle, Immatriculation, on a :

Select * from Immatriculation

Ceci dans le but de permettre à la Finance de pouvoir savoir ceux qui sont

immatriculé et les payer, de sorte à ne payer qu’eux.

- De « Autres Sites » vers « Finance » : la fragmentation verticale de la table Agent et toute la table Salaire, on a : Select codeagent, nom, postnom, prenom from Agent; Select * from Salaire; Ceci dans le but de permettre à la Finance de pourvoir payer les agents, mais

alors les agents immatricules.

- Etc.

Allocations de Fragments

L’allocation d’un grand nombre de fragments s’est réalisée par la connaissance de

l’emploi de la Base de Données, c'est-à-dire où les besoins s’avéraient les plus importants. Et s’est senti le besoin d’évolutivité de données au niveau de certains fragments dans un site, mais dont est principalement dans un autre site ; ainsi, nous avons utilisé l’allocation par cliché (Snapshop), vu qu’en plus dans notre cas la contrainte temps n’est pas trop de rigueur. Exemple pour le cas d’immatriculation. III.4.2.4.3. Réplication

Eu égards au type d’allocation utilisée, il s’en suit que la réplication utilisée entre les

sites est : Asynchrone Asymétrique.

Ainsi l’application pourra profiter des avantages d’une bonne conception, d’une bonne politique de fragmentation, allocation et réplication.

108

III.4.2.4.4. Implémentations de l’Application

Implémentation de la Base de Données : sous SQL SERVER (Version 2008)

On ne va, ici, présenter que pour deux cites : « Autres Sites » et « Fonction Publique »

Notes : pour « Autres Site », nous considérerons le cas de la Primature. Les Etapes :

- Lancement

109

- Scripts de la création de quelques tables

(1) Nom de la Première BD dans le site de la Primature : Primature_BD_Salaire

Table Agent et toutes ses contraintes : USE [Primature_BD_Salaire]

GO

CREATE TABLE [dbo].[PRI_T_Agent](

[codeagent] [nchar](20) NOT NULL,

[nom] [nvarchar](max) NULL,

[postnom] [nvarchar](max) NULL,

[prenom] [nvarchar](max) NULL,

[sexe] [nvarchar](max) NULL,

[date_naissance] [date] NULL,

[etat_civil] [nvarchar](max) NULL,

[nombre_enfant] [int] NULL,

[telephone] [nvarchar](max) NULL,

[avenue] [nvarchar](max) NULL,

[numero] [nvarchar](max) NULL,

[quartier] [nvarchar](max) NULL,

[commune] [nvarchar](max) NULL,

[niveau_etude] [nvarchar](max) NULL,

[idservice] [nchar](30) NULL,

[idgrade] [nchar](30) NULL,

[idfonction] [nchar](30) NULL,

[date_embauche] [date] NULL,

CONSTRAINT [PK_PRI_T_Agent] PRIMARY KEY CLUSTERED

(

[codeagent] ASC

)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF,

ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]

) ON [PRIMARY]

110

Table Grade : USE [Primature_BD_Salaire]

GO

CREATE TABLE [dbo].[PRI_T_Grade](

[idgrade] [nchar](30) NOT NULL,

[salaire_base] [money] NULL,

CONSTRAINT [PK_PRI_T_Grade] PRIMARY KEY CLUSTERED

(

[idgrade] ASC

)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY =

OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]

) ON [PRIMARY]

GO

Table Indemnité :

USE [Primature_BD_Salaire]

GO

SET QUOTED_IDENTIFIER ON

GO

CREATE TABLE [dbo].[PRI_T_Indemnite](

[nomIndemnite] [nchar](30) NOT NULL,

[info] [nvarchar](max) NULL,

CONSTRAINT [PK_PRI_T_Indemnite] PRIMARY KEY CLUSTERED

(

[nomIndemnite] ASC



) ON [PRIMARY]

GO

Table Prêt avec toutes contraintes :


GO

CREATE TABLE [dbo].[PRI_T_Indemnite](

[nomIndemnite] [nchar](30) NOT NULL,


CONSTRAINT [PK_PRI_T_Indemnite] PRIMARY KEY CLUSTERED

(

[nomIndemnite] ASC



) ON [PRIMARY]

GO

Table Prime :

111


GO

CREATE TABLE [dbo].[PRI_T_Prime](

[nomPrime] [nchar](30) NOT NULL,


CONSTRAINT [PK_PRI_T_Prime] PRIMARY KEY CLUSTERED

(

[nomPrime] ASC



) ON [PRIMARY]

GO

Table Retenue


GO

SET QUOTED_IDENTIFIER ON

GO

CREATE TABLE [dbo].[PRI_T_Retenue](

[nomRetenue] [nchar](30) NOT NULL,

[montant] [money] NULL,

CONSTRAINT [PK_PRI_T_Retenue] PRIMARY KEY CLUSTERED

(

[nomRetenue] ASC



) ON [PRIMARY]

GO

112

Table Salaire avec toutes ses contraintes : USE [Primature_BD_Salaire]

GO

CREATE TABLE [dbo].[PRI_T_Salaire](

[numSalaire] [int] IDENTITY(1,1) NOT NULL,

[trace_operation] [nvarchar](max) NULL,

[net_a_payer] [money] NULL,

[date_paiement] [date] NULL,

[mois_paiement] [nvarchar](max) NULL,

[codeagent] [nchar](20) NULL,

CONSTRAINT [PK_PRI_T_Salaire] PRIMARY KEY CLUSTERED

(

[numSalaire] ASC



) ON [PRIMARY]

GO

ALTER TABLE [dbo].[PRI_T_Salaire] WITH CHECK ADD CONSTRAINT

[FK_PRI_T_Salaire_PRI_T_Agent] FOREIGN KEY([codeagent])

REFERENCES [dbo].[PRI_T_Agent] ([codeagent])

ON UPDATE CASCADE

GO

ALTER TABLE [dbo].[PRI_T_Salaire] CHECK CONSTRAINT

[FK_PRI_T_Salaire_PRI_T_Agent]

GO

- Présentation de la BD implémentée

113

(2) Nom de la Deuxième BD dans le Site de la Fonction : FONC_BD_IMMATRICULATION

Table Institution : USE [FONC_BD_IMMATRICULATION]

GO

CREATE TABLE [dbo].[FONC_IMM_T_Institution](

[nomInstitution] [nchar](50) NOT NULL,

[adresse] [nvarchar](max) NULL,

CONSTRAINT [PK_FONC_IMM_T_Institution] PRIMARY KEY CLUSTERED

(

[nomInstitution] ASC



) ON [PRIMARY]

GO

114

Tableau Immatriculation USE [FONC_BD_IMMATRICULATION]

GO

CREATE TABLE [dbo].[FONC_IMM_T_Immatriculation](

[matricule] [nchar](20) NOT NULL,

[codeagent] [nchar](20) NULL,

[nomInstitution] [nchar](50) NULL,

CONSTRAINT [PK_FONC_IMM_T_Immatriculation] PRIMARY KEY CLUSTERED

(

[matricule] ASC



) ON [PRIMARY]

GO

- Présentation de la BD implémentée

115

Configuration de la Réplication : sous SQL SERVER (Version 2008) (1) Création de la Publication

- Pour configurer la réplication d’une Base de Données, on fait ce qui suit dans le

module « Réplication » de l’SQL SERVER.

- Choisir la BD à répliquer

116

- Choisir le type de Publication, en d’autre terme, quelle type de réplication

Nous avons donc choisi, la capture instantanée, le snapshop. Publication de capture instantanée :

Le serveur de publication envoie une capture instantanée des données publiées aux Abonnés, à des intervalles planifiés.

Publication transactionnelle :

Le serveur de publication diffuse les transactions aux Abonnés une fois qu'ils ont reçu une capture instantanée initiale des données publiées.

Publication transactionnelle avec abonnements pouvant être mis à jour :

Le serveur de publication diffuse les transactions aux Abonnés SQL Server une fois qu'ils ont reçu une capture instantanée initiale des données publiées. Les transactions en provenance des Abonnés sont appliquées sur le serveur de publication. Publication de fusion :

Le serveur de publication et les Abonnés peuvent mettre à jour les données publiées de manière indépendante, une fois que les Abonnés ont reçu une capture instantanée initiale des données publiées. Les modifications sont fusionnées périodiquement. Microsoft SQL Server Compact Edition ne peut s'abonner qu'aux publications de fusion.

117

- A ce niveau, c’est déjà la fragmentation, soit verticale comme notre cas, soit horizontale, dans lequel cas on doit simplement filtre les la requête à l’aide de la fenêtre suivante.

- Fixation du délai de la mise à jour de la capture

A lieu tous les jours toutes les 1 heure(s) entre 00:00:00 et 23:59:59. La planification sera utilisée en commençant le 19/02/2012.

118

- On nomme la publication

- Et on termine. Succès !

(2) Création d’Abonnement de la publication (Précédente)

- Choisir la publication dans un serveur donné (dans un autre poste ou en local)

119

- Choisir la BD où s’appliquera la réplication

- On fait « suivant » et on termine. Succès !

Et bien voila, pour la publication et l’abonnement, le résultat.

120

III.4.2.4.5. Présentation de l’Application

Dans les « Autres Sites » : « Primature » :

- Enregistrement d’une nouvelle unité

(1) Accueil de l’Application « SalaryManager »

- 1 : on s’authentification d’abord - 2 : puis on choisit une rubrique, comme pour notre cas, c’est la rubrique

« Information sur l’Agent ».

2

1

121

(2) Enregistrement d’une Nouvelle Unité

On vient d’enregistrer l’agent NU dont le code est : « pri/ag/5 », et maintenant il en reste pour l’immatriculation.

pri/ag/5

122

Dans le Site de la Fonction Publique :

- Immatriculation de la nouvelle unité : pri/ag/5

(3) Accueil de l’Application « SalaryManager »

123

(4) Retrouver les NU et Immatriculer : (pri/ag/5)

-

- 1 : choisir, l’institution ; - 2 : valider, et on a la liste, avec la NU dont le code « pri/ag/5 » ; - 3 : puis enregistrement du matricule - 4 : validation avec succès.

Allons maintenant voir la répercussion dans l’autre base de données.

pri/ag/5 1

2

3

4

124

De retour dans les « Autres Sites » : « Primature » :

- Affichage des immatriculés

(5) Visualisation de la NU immatriculé

KIN/12/0003

Immatriculé avec succès

125

Calcul de Salaire dans les « Autres Sites » : « Primature » :

- Dans la Rubrique : « Rémunération »

(6) Retrouver l’agent « pri/ag/5 » pour calculer son volume salarial du mois de janvier.

L’Agent « pri/ag/5 » dont le nom est Kayemba Mbwebwe Denis touchera 755$ pour le mois de Janvier.

Pri/ag/5

126

Voici les éléments à base de ce montant : le salaire de base, l’indemnité, les primes, le retenue et le prêt.

Salaire Net = Salaire de Base + Prime + Indemnité – Retenue - Prêt

Une fois que le calcul est fait, la Finance reçoit la situation de tous les agents de toutes les entreprises, avec tous les détails prouvant la somme du salaire et ainsi la Finance et rapport avec le Listing des agents reconnus par L’Etat Congolais c'est-à-dire immatricule, se rend compte de tout et paie ces derniers.

Présentation de Code source en C# :

Comme l’analyse a débouché sur l’utilisation de la BD, alors toutes les classes sont devenues des tables de la BD pour faire la couche Donnée sous SQL SERVER ; la couche Présentation ou Interface (Homme-Machine), c’est celle présentées juste un peu ci-haut et pour la couche métier ou applicative, on a : Couche applicative, on a :

3 fichiers de classes : - TransactionLecture.cs : pour exécuter des transactions de lecture, c’est

aussi ici que nous faisons la gestion de la concurrence par le biais de niveau d’isolation.

- TransactionEcriture.cs : pour exécuter des transactions d’écriture à savoir, d’insertion, de mise à jour et de suppression. La gestion de la concurrence y est implémentée.

- AutresOperations.cs : qui rassemble les autres opérations essentielles pour chaque formulaire.

Et en plus, on a des modules derrière chaque formulaire.

127

(1) TransactionLecture.cs using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

using System.Data;

using System.Data.SqlClient;

using System.Windows.Forms;

namespace Salary

{

class TransactionLecture

{

static string site = "Primature_";

static string _table = "PRI_T_";

SqlConnection connexion = null;

SqlCommand commande = null;

string chaineConnexion = "Data Source=." +

@"\LASOURCESERVER2;Initial Catalog="+site+"BD_Salaire;Integrated

Security=true;";

IsolationLevel niveau_iso = IsolationLevel.Serializable;

SqlTransaction transaction = null;

public TransactionLecture()

{

try

{

connexion = new SqlConnection(chaineConnexion);

}

catch (Exception ex)

{

MessageBox.Show("Une Erreur est survenue! La voici :: \n" +

ex.Message,

"ATTENTION!", MessageBoxButtons.OK,

MessageBoxIcon.Error);

}

}

public SqlDataReader ExecuterTransaction(string requete)

{

try

{

connexion.Open();

transaction = connexion.BeginTransaction(niveau_iso);

commande = connexion.CreateCommand();

commande.Transaction = transaction;

commande.CommandText = requete;

return (SqlDataReader)commande.ExecuteReader();

}


{


ex.Message,



}

return null;

}

public void FermerConnexion()

128

{

try

{

connexion.Close();

}


{


ex.Message,



}

}

public static string Table

{

get

{

return _table;

}

}

}

}

(2) TransactionEcriture.cs using System;


using System.Linq;

using System.Text;

using System.Data;



namespace Salary

{

class TransactionsEcriture

{

static string site = "Primature_";

static string _table = "PRI_T_";

protected SqlConnection connexion = null;

protected SqlCommand commande = null;

protected string chaineConnexion = "Data Source=." +

@"\LASOURCESERVER2;Initial Catalog=" + site + "BD_Salaire;Integrated

Security=true;";

IsolationLevel niveau_iso = IsolationLevel.Serializable;

public TransactionsEcriture(string requete)

{

try

{

connexion = new SqlConnection(chaineConnexion);

}


{


ex.Message,

129



}

using (SqlConnection connection = new

SqlConnection(chaineConnexion))

{

connection.Open();

SqlTransaction transaction =

connection.BeginTransaction(niveau_iso);

SqlCommand commande = connection.CreateCommand();

commande.Transaction = transaction;

try

{

commande.CommandText = requete;


//

transaction.Commit();

MessageBox.Show("Transaction validée");

}


{

transaction.Rollback();

MessageBox.Show("Une Erreur est survenue! La voici ::

\n" + ex.Message,



}

finally

{

connection.Close();

}

}

}

public string Table

{

get

{

return _table;

}

}

}

}

130

(3) Formulaire de Rémunération : Form4 using System;


using System.ComponentModel;

using System.Data;

using System.Drawing;

using System.Linq;

using System.Text;



namespace Salary

{

public partial class Form4 : Form

{

string table = "";

string traceOperation = "";

public Form4()

{

InitializeComponent();

}

public void RemplirRetenueListe()...

public void RemplirAgentsListe()...

public void RemplirIndemniteGradeListe(string grade)...

public void RemplirPrimeGradeListe(string grade)...

public void RemplirPretListe(string codeagent, DateTime dat)...

public void RemplirAgentsListe(string requete)...

public string Trace()...

public void AfficherInfoSalaire(string codeagent, string

numsalaire)...

public void AfficherTraceSalaire(string numsal)...

public void RemplirSalaireListe(string requete)

{

try

{

TransactionLecture transSalaire = new TransactionLecture();

SqlDataReader Lect =

transSalaire.ExecuterTransaction(requete);

dgvListeSalaire.Rows.Clear();

int i = 0;

decimal totalMontant = 0;

while (Lect.Read())

{

dgvListeSalaire.Rows.Add(Lect.GetValue(5).ToString().Trim(),

new

AutreOperations().RetournerCodeNom(Lect.GetValue(5).ToString().Trim()),

131

new

AutreOperations().TraiteStringArgent(Lect.GetValue(2).ToString().Trim())

, Lect.GetValue(4).ToString().Trim(),

new

AutreOperations().RetournerDateValide(Lect.GetValue(3).ToString().Trim()));

dgvListeSalaire.Rows[i].HeaderCell.Value =

Lect.GetValue(0).ToString().Trim();

totalMontant += decimal.Parse(new

AutreOperations().TraiteStringArgent

(Lect.GetValue(2).ToString().Trim()));

i++;

}

dgvListeSalaire.Rows.Add("TOTAL", "", totalMontant, "","");

dgvListeSalaire.Rows[i].HeaderCell.Value = "#";

transSalaire.FermerConnexion();

}


{


ex.Message,



}

}

public void InsererInfoSalaire(string codeag, string grade, string

nom, string mois)

{

try

{

if (codeag == string.Empty || nom == string.Empty || grade

== string.Empty

|| mois == "...")

{

MessageBox.Show("Des Champs sont Vides!", "Attention

!",

MessageBoxButtons.OK, MessageBoxIcon.Warning);

}

else

{

string datePaiement =

dtdatePaiement.Value.Date.ToShortDateString();

string moisPayer =

dtmoisPayer.Text.Split(char.Parse("/"))[1] + "/" +

dtmoisPayer.Text.Split(char.Parse("/"))[2];

string mont;

bool existe = new

AutreOperations().ExisteAgentSalaire(codeag.Trim(), moisPayer.Trim(),out

mont);

if (existe == true)

{

MessageBox.Show("L'Agent :: ["+codeag+"]-[" + new

AutreOperations().RetournerCodeNom(codeag) +

"] a reçu son salaire de [" + mont + " $]; Pour le

mois de [" + moisPayer + "] ::", "Attention !",


}

else

{

string trace = Trace();

string salaireNet = rbsalaireNet.Text;

132

decimal salaire = decimal.Parse(salaireNet.Trim());

salaireNet = new


(salaire.ToString().Trim());

string requete = "insert into " + table +

"Salaire(trace_operation, net_a_payer,

date_paiement," +

" mois_paiement, codeagent) values ('" +

trace.Trim() + "','" +

salaireNet.Trim() + "','" + datePaiement.Trim()

+ "','" +

moisPayer.Trim() + "','" + codeag.Trim() +

"')";

TransactionsEcriture transSalaire = new

TransactionsEcriture(requete);

RemplirSalaireListe("select * from " + table +

"Salaire order by date_paiement");

}

}

}


{


ex.Message,



}

}

public void MiseAJourInfoSalaire(string cle, string codeag, string

grade, string nom, string mois)

{

try

{

if (cle == "..." || codeag == string.Empty || nom ==

string.Empty || grade == string.Empty

|| mois == "...")

{


!",


}

else

{

if (DialogResult.Yes == MessageBox.Show("Etes-Vous sure

? \n\nVous êtes en train de " +

" supprimer l'information sur la table Salaires " +

@" """ + cle + @""" !" + "\n\nEt La Répercusion

sera dans toute la Base de Données!",

"Confirmation !", MessageBoxButtons.YesNo,

MessageBoxIcon.Question))

{

string requete = "delete from " + table + "Salaire

where numSalaire = '" + cle + "'";

TransactionsEcriture transRetenue = new

TransactionsEcriture(requete);

RemplirSalaireListe("select * from " + table +

"Salaire order by date_paiement");

133

}

}

}


{


ex.Message,



}

}

public void NettoyerSalaire()...

public void NettoyerSalaire_Rec()...

public void RemplirSalaireListeParMois(string mois, string code)

{

try

{

string requete = "";

if (code == "")

{

requete = "select * from " + table + "Salaire order by

date_paiement";

}

else

{

requete = "select * from " + table + "Salaire where

codeagent = '" +

code + "' order by date_paiement";

}

TransactionLecture transSalaire = new TransactionLecture();

SqlDataReader Lect =

transSalaire.ExecuterTransaction(requete);

dgvListeSalaire.Rows.Clear();

int i = 0;

decimal totalMontant = 0;

while (Lect.Read())

{

string ladate = new

AutreOperations().RetournerDateValide(Lect.GetValue(3).ToString().Trim());

if (ladate.EndsWith(mois))

{

dgvListeSalaire.Rows.Add(Lect.GetValue(5).ToString().Trim(),

new

AutreOperations().RetournerCodeNom(Lect.GetValue(5).ToString().Trim()),

new

AutreOperations().TraiteStringArgent(Lect.GetValue(2).ToString().Trim())

, Lect.GetValue(4).ToString().Trim(),

new

AutreOperations().RetournerDateValide(Lect.GetValue(3).ToString().Trim()));

dgvListeSalaire.Rows[i].HeaderCell.Value =

Lect.GetValue(0).ToString().Trim();

totalMontant += decimal.Parse(new


(Lect.GetValue(2).ToString().Trim()));

i++;

}

}

134

dgvListeSalaire.Rows.Add("TOTAL", "", totalMontant, "",

"");

dgvListeSalaire.Rows[i].HeaderCell.Value = "#";

transSalaire.FermerConnexion();

}


{


ex.Message,



}

}

public void RechercheSalaire(string codeAg, string mois, string

dat)

{

try

{

RemplirSalaireListe("select * from " + table + "Salaire

order by date_paiement");

string requete = "";

mois = mois.Trim().Split(char.Parse("/"))[1] + "/" +

mois.Trim().Split(char.Parse("/"))[2];

if (chkdatePaie.CheckState == CheckState.Checked)

{


date_paiement = '" +

dat + "' order by codeagent";

RemplirSalaireListe(requete);

}

if (chkparAgent.CheckState == CheckState.Checked)

{


codeagent = '" +

codeAg + "' order by date_paiement";


}

if (chkparDate.CheckState == CheckState.Checked)

{


mois_paiement = '" +

mois + "' order by date_paiement";


}

if ((chkparAgent.CheckState == CheckState.Checked) &&

(chkparDate.CheckState == CheckState.Checked))

{


codeagent = '" +

codeAg + "' and mois_paiement = '" + mois + "'

order by date_paiement";


}

if ((chkparAgent.CheckState == CheckState.Checked) &&

(chkdatePaie.CheckState == CheckState.Checked))

{


codeagent = '" +

codeAg + "' and date_paiement = '" + dat + "'

order by codeagent";

135


}

}


{


ex.Message,



}

}

private void Form4_Load(object sender, EventArgs e)...

private void cbbagentMatricule_SelectedIndexChanged(object sender,

EventArgs e)...

private void tbgrade_TextChanged(object sender, EventArgs e)...

private void tbnomAgent_rec_TextChanged(object sender, EventArgs

e)...

private void btnAjouterPret_Click(object sender, EventArgs e)...

private void btnCalculSalaire_Click(object sender, EventArgs e)...

private void dgvListeSalaire_CellMouseClick(object sender,

DataGridViewCellMouseEventArgs e)...

private void btnActualiser_Click(object sender, EventArgs e)...

private void btnVisualiser_Click(object sender, EventArgs e)...

private void btnNettoyerPret_Click(object sender, EventArgs e)...

private void btnSupprimerPret_Click(object sender, EventArgs e)...

private void btnRecherchePret_Click(object sender, EventArgs e)

{

RechercheSalaire(cbbagent_rec.Text, dtdateSalaire_rec.Text,

dtdatesal_rec.Text);

}

private void btnValiderConv_Click(object sender, EventArgs e)

{

try

{

if (tbtauxFranc.Text == string.Empty || tbsomme1.Text ==

string.Empty)

{


!",


}

else

{

decimal tauxf = decimal.Parse(tbtauxFranc.Text.Trim());

decimal som1 = decimal.Parse(tbtauxFranc.Text.Trim());

tbsomme2.Text = (som1 * tauxf).ToString();

}

136

}


{


ex.Message,



}

}

private void chkmodifier_CheckedChanged(object sender, EventArgs

e)...

private void button2_Click(object sender, EventArgs e)...

private void elémentsDuSalaireToolStripMenuItem1_Click(object

sender, EventArgs e)...

private void elémentsDuSalaireToolStripMenuItem_Click(object


private void informationSurLAgentToolStripMenuItem_Click(object


private void Form4_FormClosing(object sender, FormClosingEventArgs

e)...

private void accueilToolStripMenuItem_Click(object sender,

EventArgs e)...

}

}

Rappels

Ce chapitre si long, qu’on ne perd de vue malgré ça, nous a permis à présenter notre

contribution en mettant au point un Logiciel de Traitement de salaire « SalaryManager »

tablé sur les notions présentées ci précédemment à savoir, depuis les notions introductives

des systèmes distribués à celle de transactions et de la gestion de transactions concurrentes.

Nous avons donc eu ce temps de montrer comment ces notions pouvaient être

d’application tant dans la conception de la BDR que dans les outils utilisés pour la mise en

place de l’application, ce chapitre en témoigne de soi.

137

[Conclusion]

138

Conclusion

La concurrence, voire la concurrence de transactions est pourtant loin d’être une

poursuite pour les Bases de Données Réparties, c’est plutôt une contrainte que ces dernières

sont censées gérer, car en tant qu’un système distribué, elles doivent censément gérer des

traitements concurrents. A travers les théories si bellement et méticuleusement exposées,

on a vu que la concurrence, qui est aussi une sollicitation simultanée, pouvaient causer, à

part l’incohérence de données, de la surcharge qui entache la disponibilité du Système, et on

a vu que qu’une bonne réplication pouvait amoindrir le taux d’une sollicitation excessive

d’une ressource. Cette notion de réplication est aussi d’application dans les Bases de

Données Réparties.

Conformément à ce que reprend [6], que nonante pourcent (90%) de données doivent

être trouvé dans le site local, et seulement dix (10%) dans un site distant, et puisque

l’emplacement d’exécution d’une transaction est un point très capital [5], il va de soi à dire

que réellement la réplication est aussi une voie pour contourner le méfait de la concurrence,

même si elle est exigeante du coté mise à jour et synchronisation de fragments.

Aux points positifs ci-dessus, on peut maintenant ajouter une bonne gestion de

transactions concurrentes par le biais des algorithmes de contrôle de concurrence qui sont

implémentés par exemples dans SQL SERVER par le niveau d’isolation qu’on attribue à

chaque transaction lorsqu’elle s’exécute de sorte à pouvoir contrôler tant son accès aux

données que celui des autres transactions qui lui sont concurrente. Chaque niveau

détermine donc un comportement donné dans l’accès de données tant pour la lecture que

pour l’écriture, d’où son choix est très important.

Toute cette logique de gestion de concurrence de transactions réunie ensemble et

mise en pratique dument, permet donc de mettre sur pied des systèmes distribués, dont

bien sûr la Base de Données répartie reste disponible et cohérente.

Ceci, nous avons l’audace de le croire, est le cas pour notre application informatique,

qui est passée par cette logique, et qui censure en même temps notre étude par sa

concrétisation.

A cette étape, nous pouvons déjà faire le bilan de notre solution informatique et voir si

la problématique posée tout au début, a rencontré la solution la plus appropriée.

Bien sûr qu’à présent, grâce à la solution informatique qui s’articule sur le logiciel

nommé SalaryManager monté par l’entremise des technique et technologie avancée ci haut,

l’immatriculation des agents est désormais très aisée, et grâce à la réplication, il ne suffit

qu’une entreprise enregistre une nouvelle unité (NU) , la Fonction Publique sera alors dans

139

un bref délai tenu informé dans sa base de donnée et pourra alors et simplement

l’immatriculer, et inversement une fois que la NU est immatriculée, l’information répercute

ou mieux se réplique à la source. Ceci a un avantage de gain en temps et de souplesse dans

les tâches et évites aussi trop de paperasses. Et par conséquent, il y a une facilité de

connaître l’effectif des tous les agents de l’Etat.

Et aussi mêmement, quand la NU est immatriculée, la Fonction Publique réplique cette

information ou mieux toutes les informations sur les agents immatriculés à la Finance.

De cette manière, chaque entreprise déjà connectée dans l’e-Gouvernement et

possédant ce logiciel a cette possibilité à son niveau local de calculer le salaire des agents, et

ainsi d’un coup et dans un bref délai les informations de calcul vont se synchroniser aussi au

niveau du ministère de Finance, et comme ça ce dernier pour payer ces agents aussi en

fonction des agents déjà immatriculés en provenance de la Fonction Publique.

Ce présent travail, ainsi que sa solution toute complète est un projet très vaste

et très coûteux depuis son étude jusqu’à sa réalisation ; et la solution apportée peut

encore comporter d’autres paramètres tels que : le calcul détaillé de élément constituant

le salaire de base, depuis la prestation jusqu’aux heures supplémentaires, le suivi en temps

réel des opérations de mutation et de transfert des agents de l’Etat, etc. pour avoir un

Logiciel très complet du personnel de l’Etat.

140

Référence

[1] A. Eftekari, Systèmes Transactionnels Répartis, Laboratoire Gracimp (ICTT) de l’INSA.

[2] Achraf Cherti, Jargon Informatique, Logiciel, Version 1.3.6, Avril 2006

[3] Anne Doucet, Transactions réparties, Module BDR Master d’Informatique (SAR) ; Cours.

[4] Arun Kumar Yadav et Ajay Agarwal, An Approach for Concurrency Control in

Distributed Database System, International Journal of Computer Science & Communication Vol. 1, No. 1, January-June 2010

[5] Anis Haj Said, Laurent Amanton, Bruno Sadeg, Contrôle de la réplication

dans les SGBD temps réel distribués, Laboratoire d’Informatique, de Traitement de l’Information et des Systèmes (LITIS) – Université du Havre, [email protected]

[6] Arjan SINGH and K.S. KAHLON, Non-replicated Dynamic Data Allocation in Distributed Database Systems, IJCSNS International Journal of Computer Science and Network Security, VOL.9 No.9, September 2009.

[7] A. S. Tanenbaum and M. VAN STEEN. Distributed Systems : Principles and Paradigms. Prentice Hall, 1999.

[8] Alexander Thomasian (Senior Member, IEEE), Distributed Optimistic Concurrency Control Methods for High-Performance Transaction Processing, IEEE TRANSACTIONS ON KNOWLEDGE AND DATA ENGINEERING, VOL. 10, NO. 1 , JANUARY/FEBRUARY 1998

[9] Aurélien Esnard, Systèmes Répartis, ENSEIRB PG306-IT343, [email protected],

http://www.labri.fr/~esnard

[10] Bertrand DUCOURTHIAL, Introduction aux systèmes répartis (chapitre 1), [email protected], 2007 v0.9-POLY.

[11] Darius KUGEL, Client-serveur : Introduction aux modèles client-serveur, Cours, [email protected]

[12] D. Skeen and M. Stonebraker, “A formal model of crash recovery in a distributed system,” IEEE Trans. Software Eng., vol. 9, no. 3, pp. 219–228, 1983.

mailto:[email protected]



http://www.labri.fr/~esnard



141

[13] Eric Cariou, Introduction aux Systèmes Distribués, Licence Informatique 3ème année, Université de Pau et des Pays de l'Adour - Département Informatique, [email protected]

[14] Eric Leclercq & Marinette Savonnet, Chapitre I : Protocoles client serveur et architectures distribuées, Département IEM / UB, [email protected], Février 2008, Page 3.

[15] Eugene MBUYI, Système d’Information et Base de Données (Deuxième partie), Université de Kinshasa – Fac Sciences- Dpt Math-Info - L1-L2 Génie Informatique – 2010-2011

[16] Eltayeb Salih Abuelyaman, An Optimized Scheme for Vertical Partitioning of a

Distributed Database, CCIS, Prince Sultan University, Riyadh 11586, Saudi Arabia

[17] Articles sur les transactions dans le FireBirdsql, http://www.firebirdsql.org

[18] Frank SINGHOFF, Introduction aux systèmes à objets et services répartis, Bureau C-203, Université de Brest, France, LISyC/EA 3883, [email protected]

[19] Gopal Ashok (Microsoft Corporation) et Paul S. Randal (SQLskills.com), SQL Server Replication: Providing High Availability using Database Mirroring

[20] GRAHAM CHEN, distributed transaction processing standards and their applications, Tiré de “ the Computer Standards and Interfaces 17 (1995) pp 363-373”

[21] Harold CUNICO, ADO .NET : utilisation des transactions Version 1.0, Association

DotNet France, www.dotnetfrance.com

[22] Hercule KALONJI KALALA, Transactions reparties (Systèmes d’objets répartis), Université de Kinshasa – Fac Sciences- Dpt Math-Info – Licence - Génie Informatique – 2009-2010

[23] Hercule KALONJI KALALA, réplication des données (Systèmes d’objets répartis :

Chapitre VII), Université de Kinshasa – Fac Sciences- Dpt Math-Info - Licence - Génie Informatique – 2009-2010

[24] Haroun RABABAAH, DISTRIBUTED DATABASES FUNDAMENTALS AND RESEARCH,

Advanced Database – B561. Spring 2005. Dr. H. Hakimzadeh, Department of Computer and Information Sciences, Indiana University South Bend.

[25] Idriss SARR, Routage de Transaction dans les Bases de Données à Large Echelle, Thèse – O7-Octobre-2010, Université Pierre et Marie Curie (Parie VI)

[26] ISO/IEC 10026-1, Information technology-Open Systems Interconnection-Distributed



http://www.firebirdsql.org/

http://www.dotnetfrance.com/

142

Transaction : Part 1 OSI TP Model, Part 2 OSI TP Service Definition, Part 3 OSI TP Protocol Specification, - 1993

[27] Joël LILONGA BOKELETUMBA, Langage Pour Système, Université de Kinshasa – Fac Sciences- Dpt Math-Info – L1 Génie Informatique – 2010-2011

[28] Jim Gray, Transaction Processing: Concepts and Techniques, April 2007,© 2007

Sombers Associates, Inc., and W. H. Highleyman, www.availabilitydigest.com

[29] KAYEMBA KAVUALLA Sagesse, Recherche d’un chemin minimal facilitant le Service Anti-incendie d’atteindre le lieu de sinistre, Travail de fin de cycle, Université de Kinshasa – Fac Sciences- Dpt Math-Info – G3 Informatique – 2008 – 2009

[30] Luc Bouganim, Bases de données : Architecture et Systèmes ; Cours 2 : Transactions ;

PRiSM Versailles - INRIA, Rocquencourt

[31] Laurence Duchien, Le Transactionnel Réparti, Transactions et environnements CORBA, CNAM- Laboratoire CEDRIC ; 292, rue St Martin, 75141 Paris, Cedex 03, email : [email protected]

[32] Muhammad Atif, Analysis and Verification of Two-Phase Commit & Three-Phase

Commit Protocols, Department of Mathematics and Computer Science, Technische Universiteit Eindhoven, P.O. Box 513, 5600 MB Eindhoven, The Netherlands, Email: [email protected]

[33] Matthieu Exbrayat, Gestion de Transactions dans les Systèmes Distribués, ULP

Strasbourg – Décembre 2007

[34] D. S. Milojicic, V. Kalogeraki, R. Lukose, K. Nagaraja, J. Pruyne, B. Richard, S. Rollins and Z. Xu, “Peer-to-Peer Computing”. Tech. Report: HPL-2002-57, available on line at: http://www.hpl.hp.com/techreports/2002/HPL-2002-57.pdf

[35] Ministère des Postes, Téléphones et Télécommunications (MPTT), Rapport de l’étude de faisabilité, L’infrastructure des TIC pour le projet d’E-Gouvernement de la République Démocratique du Congo, Mai 2007

[36] M. Raddad AL KING, Localisation de sources de données et optimisation de requêtes réparties en environnement pair-à-pair, Université Toulouse III – Paul Sabatier, Discipline : Informatique, Mai 2010

[37] MSDN, Microsoft Developper Network, msdn.microsoft.com – 02 Décembre 2011 (Date de visitation du site)

[38] http://msdn.microsoft.com/en-us/library/ms151198(SQL.100).aspx, for SQL Server

2008

[39] Nathanael KASORO, Langage Formel et Compilation, Cours, Université de Kinshasa –

Fac Sciences- Dpt Math-Info – Licence, 2010-2011

http://www.availabilitydigest.com/



http://www.hpl.hp.com/techreports/2002/HPL-2002-57.pdf

http://msdn.microsoft.com/en-us/library/ms151198(SQL.100).aspx

143

[40] Nicolas LUMINEAU, Interopérabilité et Intégration des systèmes d’information : TIW3,

Université de Claude Bernard – Lyon 1, [email protected], 2008, Page 5-6

[41] Olabode OLATUBOSUN et Solanke OLAKUNLE, Framework for Client-Server Distributed Database System for Licensing and Registration of Automobiles in Nigeria, E-mail: [email protected].

[42] PHILIP A. BERNSTEIN AND NATHAN GOODMAN, Concurrency Control in Distributed Database Systems, Computer Corporation of America, Cambridge, Massachusetts 02139, February 1981

[43] Paul Krzyzanowski, Lectures on distributed systems: A taxonomy of distributed

systems, Rutgers University – CS 417, 2000-2003

[44] Roland BALTER, Gestion répartie des transactions, Projet INRIA Sirac ; 655, av de l’Europe ; 38330 Montbonnot ; Août 1993 ;

[45] Rim MOUSSA, Systèmes de Gestion de Bases de Données Réparties & Mécanismes de Répartition avec Oracle, Novembre 2006,

Ecole Supérieure de Technologie et d’Informatique à Carthage, 2005-2006, [email protected], http://ceria.dauphine.fr//Rim/SupportBDR.pdf

[46] Ricardo R. JACINTO MONTES, Protocoles de validation à deux phases dans les

systèmes transactionnels répartis : Spécification Modélisation et vérification, LABORATOIRE D’ ANALYSE ET D’ARCHITECTURE DES SYSTEMES DU CNRS, Toulouse-France, Thèse – O6-Janvier – 1995

[47] Shahidul Islam Khan et Dr. A. S. M. Latiful Hoque, A New Technique for Database

Fragmentation in Distributed Systems, International Journal of Computer Applications (0975 – 8887) Volume 5– No.9, August 2010

[48] Saint-Jean DJUNGU, Réseaux Informatiques, Université de Kinshasa – Fac Sciences- Dpt Math-Info - L2 Gestion Informatique – 2010-2011

[49] Saint-Jean DJUNGU, Génie logiciel et construction des programmes, Université de

Kinshasa – Fac Sciences- Dpt Math-Info - L2 Gestion Informatique – Mai 2009

[50] Sacha Krakowiak, Validation atomique, Université Joseph Fourier, Projet Sardes (INRIA et IMAG-LSR), http://sardes.inrialpes.fr/people/krakowia, Ecole Doctorale de Grenoble, Master 2 Recherche “Systèmes et Logiciel”

[51] Sacha Krakowiak, Introduction aux systèmes et applications répartis, Université

Joseph Fourier, Projet Sardes (INRIA et IMAG-LSR), http://sardes.inrialpes.fr/krakowia




http://ceria.dauphine.fr/Rim/SupportBDR.pdf

http://sardes.inrialpes.fr/people/krakowia

http://sardes.inrialpes.fr/krakowia

144

[52] Sylvain Lecomte, Cartes Orientées Services Transactionnels et Systèmes Transactionnels Intégrant des Cartes : COST-STIC, Thèse de Doctorat, Université des Sciences et Technologies de Lille, Page 32-33

[53] www.Wikipedia.com

http://www.wikipedia.com/

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

Engineering

Transcript of Etude des Transactions Concurrentes Dans une Base de Données Répartie. Application à l’Intranet...