Jo Lida Memoire 2

i
Page|
Epigraphe
« La complexité de données est la raison majeure de la

répartition des tâches »
Peter K.
ii
Page|
IN MEMORIAM
A mon très cher père MISIA NGAYAM Jean Bosco qui nous a
quittés avant ce jour merveilleux, pour une sincère reconnaissance
que nous avons envers lui, jamais nous ne pouvons t’oublier. Que
ton âme repose en paix.
DEDICACE
P a g e | iii
Au Dieu Très Haut, Créateur du ciel et de la terre, pour le

souffle de vie gratuit accordé à notre humble personne, ainsi que
pour l’intelligence et la sagesse dont nous avons bénéficiées tout
au long de ce parcours académique ;
A ma très chère mère NSIMBA KATUZA Jackie pour son

affection à mon égard et sa passion pour mes études ;
A toute ma famille, en commençant par mes frères et

sœurs : Reagen Misia, Fanny MISIA, Pamela MISIA, Baron MISIA
ainsi que monsieur Ledim LEMBA ;
A mes amis et connaissances : Tania VANGE, Sarah
MWABOSENGE, Sara MANDAKA, Priscille KUMBI, Deborah
BUDIE, Sharone KAYIBA, Ben BENTEKE, Lionel MBALA, Héritier
MAMONA, Moise NGANGU et Djo PINDU ;
A tous les miens : Guy MUNGWELE, FRANCOIS NGAYAM, Dosite

ASABIEL et Anathol MUANZA.
Je dédie ce travail.
REMERCIEMENTS
Je tiens à saisir cette belle opportunité pour adresser

mes sincères remerciements et ma profonde reconnaissance au
Dieu Tout Puissant : « Jésus Christ » le miséricordieux, qui m'a
iv
accordé sa grâce et m'a donné la force et l’intelligence d'accomplir

ce travail.
Mes remerciements vont à ceux qui m'ont encouragée et

qui ont témoigné de l'intérêt tout au long de ce travail. Je tiens à
remercier particulièrement le professeur MABELA MATENDO
Rostin, mon Directeur de Travail, pour sa disponibilité, sa rigueur
et sa pertinence dans sa manière de faire et c'est ce qui a été
l'objet même de notre motivation durant l'élaboration de ce
travail.
Je tiens aussi à présenter l’expression de ma

reconnaissance envers mon encadreur, monsieur OKONDA
Pierrot pour ses précieux conseils et ses orientations. Notre
reconnaissance s’adresse ensuite à tout le corps professoral, les
assistants et chefs de travaux pour leurs disponibilités et leur
formation dont nous sommes bénéficiaires.
Je voudrais associer à ces remerciements ma famille

spirituelle de la JCC (Jeunesse Chrétienne Combattante), pour
leur soutien tant moral que spirituel. Je remercie
particulièrement : Papa Chartier MAKUBA, Jonathan
KADIEBWE, Nathan ILENDA, Henock DJUNGA, Benjamin
DJUNGA, Deborah BUDIE, Dorcas MOLA et Bénie MWANDA pour
leur amour et soutien. Qu’ils trouvent ici l’expression de ma
profonde gratitude. Que tous ceux qui nous ont apporté une aide
précieuse, de quelque nature que ce soit, qu’ils ne se croient pas
oubliés. Qu'ils trouvent ici nos profonds remerciements.
Page|5
Liste des abréviations
API : Application Programming Interface

BD : Base de Données
BDD : Base de Données Distribuées
BDR : Base de Données Réparties
C/S : Client – Serveur
CNC : Centre National de Correction
CPU : Central Processing Unit
CP : Chef de poste
CE : Catégorie Essieux
CT : Court trajet
DC : Diagramme de classes
DA : Diagramme d’activités
DS : Diagramme de séquences
DU : Diagramme de cas d’utilisation
IDE : Integrated Development Environment
ISO: International Standard Organization
JDBC: Java Data Base Connectivity
JTS : Java Transaction Service
LT : Long trajet
MTS : Microsoft Transaction Server
ODBC : Open Data Base Connectivity
OPS : Opérateur de Saisie
P2P : Peer – to – Peer
PpR : Poste de péage routier
RDC : République Démocratique du Congo
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
SQL: Structured Query Language
UML: Unified Modeling Language
Liste des Figures

Page|6
Figure 1 : De centralisé vers distribué

Figure 2 : Système distribué avec un intergiciel
Figure 3 : Architecture client-serveur
Figure 4 : Architecture P2P
Figure 5 : Architecture d’une base de données répartie
Figure 6 : Conception ascendante
Figure 7 : Conception descendante
Figure 8 : Architecture d’une BDD
Figure 9 : Mise à jour synchrone
Figure 10 : Mise à jour asynchrone
Figure 11: Transaction dans une base de données cohérente
Figure 12 : Organigramme du cabinet du ministre de l’intérieur
Figure 13 : Dictionnaire des données
Source : Modélisation du nouveau système
Figure 14 : Model conceptuel des données
Figure 15 : Model logique des données
Figure 16 : Création de la publication
Figure 17 : Choix des types de publication
Figure 18 : Finalisation de la publication
Figure 19 : Interface graphique de l’authentification
Figure 20 : Interface graphique de l’identification agent
Liste des Tableaux

Tableau 1 : Montrant l'exemple d'illustration de la fragmentation horizontale
Page|7

Tableau 4 : Exemple d'illustration d'une fragmentation verticale
Tableau 5 : Exemple d'illustration d'une fragmentation verticale 1
Tableau 7 : Combinaison des techniques de la réplication
Tableau 8 : Tableau d’analyse des moyens matériels
Tableau 9 : Tableau d’analyse des moyens humains.
Tableau 10 : le dictionnaire des données
INTRODUCTION GENERALE
Page|8
De nos jours, nous constatons de plus en plus la

technologie évoluer avec une grande vitesse, elle devient
davantage une des clés nécessaires pour le développement d’une
nation. Quand on parle du développement d’une nation, on voit
surtout le développement de ses institutions, et l’informatique est
cet outil indispensable pour l’accomplissement de cette
émergence.
1. Problématique
Nous avons constaté qu’en République Démocratique du

Congo (RDC) beaucoup d’institutions publiques comme privées
sont non informatisées, certaines sont en cours d’informatisation.
Parmi les institutions en cours d’informatisation et ayant

besoin d’une amélioration considérable dans leur administration,
nous avons le Ministère de l’Intérieur, Sécurité , Décentralisation
et Affaires Coutumières. C’est l’un des ministères clés du
développement de la République Démocratique du Congo. Dans
notre investigation, nous avons épinglé trois difficultés auxquelles
il est confronté :
 Manque de contrôle d’effectifs pour une bonne politique de

suivi afin de pallier au problème de doublons des matricules
avec un même nom au sein de la ville province de Kinshasa.
 Absence d’outils et de logiciels appropriés avec accès
internet à temps réel pour l’identification des agents fictifs ;
 Perte d’informations sur les agents à cause de l’utilisation
des supports en papier.
 Absence de coordination de la gestion de toutes les entités
du ministère dans toutes les provinces.
Page|9
2. Hypothèses
Vu les difficultés mentionnées ci-haut, nous proposons au
Ministère de l’Intérieur, Sécurité, Décentralisation et Affaires
Coutumières de la RDC un système distribué des données pour
l’identification de ses agents. La distribution des données se ferait
dans chaque province dont la ville de Kinshasa serait le site
central. La réplication des données apporterait au Ministère
plusieurs avantages, à savoir : la disponibilité, la confidentialité et
l’intégrité des données en permanence sur différents sites.
Les avantages principaux du système seraient :
 L’identification exacte des agents ;
 La distribution des données dans toutes entités provinciales
du ministre et la coordination des taches ;
 L’authentification de tous les agents afin de résoudre le
problème de multiples identités.
3. Choix du sujet
En partant des constats ci-haut énumérés, nous avons choisi

comme sujet : « Mise en place d’une base de données reparties pour
l’identification des agents ; cas du Ministère de l’Intérieur,
Sécurité, Décentralisation et Affaires Coutumières ».
P a g e | 10
4. Méthodes et techniques utilisées :

Pour réaliser ce travail nous avons utilisé :
- La méthode UML : elle est un langage de représentation destiné
particulièrement à la modélisation objet. Elle dispose d’un formalisme
qui exige de « penser objet » et permet de demeurer indépendant d’un
langage de programmation proposé. UML peut être utilisé à la place du
modèle E-A (Merise) pour la modélisation dans le domaine de la base
de données.
Comme techniques utilisées nous nous sommes servis de :
- La technique de collecte des données : elle nous a aidé à récolter tous
les renseignements afin de s’en servir pour constituer la base de
données du système et son implémentation.
- la technique de conversion : certaines informations collectées sont
converties en des données dans la base de données et les autres
informations nous ont aussi permis d’implémenter l’application.
5. Subdivision du travail
Hormis l’introduction générale et la conclusion générale, notre travail
est subdivisé en quatre (4) chapitres, à savoir :
Chapitre I. Généralités sur le système Distribué et Base de
données Réparties.
Chapitre II. Réplication de données
Chapitre III. Présentation du cadre d’étude
Chapitre Iv. Modélisation et implémentation du système
P a g e | 11
CHAPITRE I. GENERALITES SUR LE SYSTEME DISTRIBUE ET

BASE DE DONNEES REPARTIES
I.0. Contexte du sujet

Un réseau informatique est une interconnexion
d’équipements informatiques, offrant aux entreprises toute une
panoplie d’avantages, parmi lesquels l’échange et le partage des
données, l’accès à des bases de données distribuées,...
Suite à l’apparition du réseau informatique, sont nés et
déployés des systèmes dits distribués. 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.
Nous allons commencer par expliquer les systèmes
distribués avant de nous plonger de manière la plus détaillée
possible sur les bases de données réparties.
I.1. Système distribué

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éparti » suppose une coopération des
tâches en vue de la répartition du travail, 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 ».
De ce 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, on a une
certaine nuance. quand on parle d’une Base de Données
Distribuée (BDD), c’est un terme tout à fait générique. une Base
de Données Répartie (BDR) n’est qu’un cas particulier de Base de
données distribuée, au même titre que les BD fédérées, le système
multi bases, etc.
P a g e | 12
I.1.1. Définition
« 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 ».
« 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 ».
« Un système informatique distribué est une collection
de processus informatiques indépendants qui communiquent
mutuellement par passage des messages ».
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 claire et globale de ce qu’est un système distribué.
Aussi, en résumé, dans un système distribué, les

ordinateurs ont architecturalement cette capacité de travailler
indépendamment.
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.
I.1.2. Caractéristiques et objectifs d’un système distribué

Voici les objectifs pour lesquels on construit un système
distribué, qui font office directement des caractéristiques de ce
dernier :
a) 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és entre
les entités du système.
P a g e | 13
b) 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.
c) La concurrence :
Le traitement concurrent augmente la performance du
système.
d) 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 de nouvelles ressources sont ajoutées.
e) La tolérance de panne :
C ‘est la capacité qu’un système continue de fonctionner

malgré quelques défaillances partielles des composants ou du réseau
de communication.
I.1.3. Système centralisé et système distribué
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 programmes. 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
communiquent directement avec lui via des terminaux.
Le seul vrai problème avec ce système, c’est qu’il n’est pas
scalable (évolutif), il y a une limitation par rapport au nombre de
CPU à tel enseigne qu’il faut le mettre à jour ou carrément le
remplacer lorsqu’il faut ajouter un processeur.
P a g e | 14
De par les avantages et objectifs du système distribué, on

peut, sans aucun effort, voir le pourquoi de ce passage. Ce
passage amène des nouveaux problèmes tels que la localisation, la
transparence, l’interopérabilité, etc. qui sont pris comme des défis,
auxquels le système distribué doit faire face.
Figure 1 : De centralisé vers distribué
 Conception d’un système distribué

La conception peut se faire de deux manières : matérielle et
logicielle.
Conception matérielle
Elle peut se réaliser sur :
 Machine multiprocesseurs avec mémoire partagée ;
 Cluster (grappe) d’ordinateurs dédié au calcul/traitement
massif parallèle ;
 Ordinateurs standards connectés en réseau.
Conception logicielle
 Le système logiciel ici, est composé de plusieurs entités
disséminées dans un réseau, s’exécutant indépendamment
et parallèlement.
P a g e | 15
I.1.4. Propriétés d’un système distribué
Les défis 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.
a) 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, sans avoir besoin de connaitre sa
localisation ou son détail technique des ressources.
Cette propriété fait alors maximiser 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 :
- Accès : il n’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).
- Hétérogénéité : il doit être caché à l’utilisateur les
différentes ressources matérielles ou logicielles qu’il utilise. La
notion d’interopérabilité.
P a g e | 16
- 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.
- Migration : le déplacement d’une ressource peut se faire,
mais sans qu’on ne s’en plaigne, car rien ne sera aperçu.
- Tolérance aux pannes : 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.
- 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.
b) La disponibilité
Il existe beaucoup de causes à l’origine de l’indisponibilité d’un

Système. voici celles que nous signalons ici selon :
- 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 conformément à la spécification ; mais il faut savoir
P a g e | 17
que les pannes ou toute autre tentative (citées ci-haut) va

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, nous avons choiside
ne parler que de celle qui va beaucoup plus avec notre travail :
La réplication : cette technique est utilisée pour pallier à la
première (panne) et de 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.
c) 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.
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 modification 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 logiciel tiers qui crée un réseau d'échange d'informations entre
différentes applications informatiques. Les composants logiciels
du middleware assurent la communication entre les applications
quels que soient les ordinateurs impliqués et quelles que soient
les caractéristiques matérielles et logicielles des réseaux
P a g e | 18
informatiques, des protocoles réseau, des systèmes d'exploitation

impliqués.
Les techniques les plus courantes d'échange d'informations

sont l'échange de messages, l'appel de procédures à distance et la
manipulation d'objets à distance.
Les objectifs d’un Middleware
Les trois objectifs d’un middleware sont les suivants :
 Masquer la complexité de l'infrastructure sous-jacente, donc
l’hétérogénéité des machines et systèmes ;
 Faciliter la conception, le développement et le déploiement
d’applications réparties : masquer la répartition des
traitements et des données.
 Fournir des services communs : une interface commode aux
applications (programmation + API : Application
Programming Interface).
Figure 2 : Système distribué avec un intergiciel
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]
P a g e | 19
- 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 en
jeux 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é 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 : Client-
serveur (C/S), Peer-to-Peer ou Pair-à-Pair (P2P) et Hybride ; cette
dernière est une combinaison du modèle client /serveur et du
modèle Peer-to-Peer.
1. Client-serveur (C/S)
Le concept client-serveur, c’est pour définir une

architecture. 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.
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.
P a g e | 20
Figure 3 : Architecture 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 :
 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.
Types de client serveur

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 soient 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
P a g e | 21
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 SGBD 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 Visual
Basic.Net Avec SQL Server.
 Client-serveur de traitements : Ce type est également qualifié
de traitement distribué (ou client-serveur de procédure). 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).
1. 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, 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 gigantesques.
P a g e | 22
Figure 4 : Architecture P2P
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 : « 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, 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. BASE DE DONNEES REPARTIE
I.2.1. Définition
D’une manière la plus brève possible une base de
données, c’est une collection des données structurées reliées par
des relations, interrogeable et modifiable par son contenu.
La base de données répartie est une collection de base
des
données stockées sur diverses machines d’un réseau informatique
apparaissant à l’utilisateur comme une base de données unique.
Une base de données repartie est aussi vue comme une
collection de bases de données logiquement reliées, distribuées
P a g e | 23
sur un réseau et apparaissant à l’utilisateur comme une base de

données unique.
Une base de données répartie est l’union, l’ensemble de

bases de données mémorisée sur différents sites dont la
répartition est cachée à l’utilisateur. Une base de données répartie
est un rapprochement de données vers les utilisateurs.
Cette définition met en évidence deux aspects. On peut
expliciter les termes suivants :
 La distribution : les données ne résident pas dans le même
site ;
 La corrélation logique : les données possèdent des
propriétés qui les tiennent ensemble.
Voici l’architecture d’une base de données répartie :
Figure 5 : Architecture d’une base de données répartie

P a g e | 24
I.2.2. Caractéristiques
a) Une structure de contrôle hiérarchique basée sur un
administrateur de base de données global, qui a la
responsabilité centrale sur la base de données répartie entière
et sur les administrateurs des bases de données locales, qui
ont la responsabilité de leurs bases de données locales
respectives.
b) À l’indépendance des données est ajoutée la transparence de
répartition qui signifie que les programmes peuvent être écrits
comme si les données n’étaient pas réparties.
c) La redondance des données est une caractéristique désirable
pour croître l’autonomie des applications et la disponibilité du
système (fiabilité) en cas de panne.
d) Dans une BDR, la confidentialité ou la protection des données
est assurée par les Administrateurs locaux. Les problèmes de
sécurités sont intrinsèques aux systèmes répartis.
Un système de bases de données réparties ne doit être
confondu avec un système multi base. Dans ce dernier cas,
chaque utilisateur accède à différentes bases de données en
spécifiant leur nom et adresse, et le système se comporte alors
simplement comme un serveur de BD et n'apporte aucune
fonctionnalité particulière à la répartition.
Au contraire, 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 transaction sur des données gérées par différents SGBD sur
plusieurs sites.
P a g e | 25
I.2.3. Importance d’une base de donnés répartie

Les buts poursuivis pour mettre en place une base de données
répartie sont les suivants :
 Limiter les transferts d’information (nombre et volume) ;
 Répartir les charges ;
 Augmenter la fiabilité et la disponibilité ;
 Décentralisation des organisations, critères économiques,

partage de données géographiquement réparties en vue
d’une meilleure performance ;
 Fusionner les systèmes d’information.
I.2.4. Objectifs d’une base de données répartie

Voici quelques règles pour réussir à mettre en place une
base de données répartie :
 L’autonomie locale ;
 Une transparence vis-à-vis de la localisation ;
 Une transparence vis-à-vis de la fragmentation ;
 Transparence à la duplication ;
 Fonctionnement en continu,
 Egalité des sites ;
1. L’autonomie locale
Comme le mot l’indique c’est la capacité de s’administrer
librement, l’autonomie locale doit être capable de réaliser une
administration au niveau local. L’autonomie locale implique que la
base individuelle locale soit totalement fonctionnelle même si elle ne
peut pas communiquer avec les autres sites des bases de données
réparties. Elle implique aussi que chaque site soit responsable de
l’intégrité de ses propres répartitions, de sa propre sécurité et de sa
propre gestion.
P a g e | 26
2. Transparence vis-à-vis de la localisation des

données
La transparence de la localisation des données signifie
que les utilisateurs de la base de données ne se rendent pas
compte que les bases de données soient distantes. Les utilisateurs
doivent d’être capables d’accéder aux données distantes dès que
la base de données locale est présente.
La transparence de la localisation des données repose sur la
disponibilité permanente de bases de données distantes alors
qu’elle dépend d’un réseau. La transparence de la localisation des
données veut dire que les complexités techniques doivent être
caché aux applications et aux utilisateurs ou encore, les
utilisateurs ou applications n’ont pas besoin de connaitre la
position réelle des données auxquelles ils accèdent. Les avantages
de la transparence de localisation sont de simplifier la vue
utilisateur, l’écriture des requêtes et de déplacer les données sans
qu’il ait modification au niveau des requêtes.
3. Transparence vis-à-vis de la fragmentation de données La

fragmentation se réalise lors de la conception d’une base de
donnée répartie c’est-à-dire les données du site maître sont copiés
dans différents sites selon le besoin de chaque site. La relation
principale ne peut pas dépendre de la manière dont les données
sont découpées.
4. Transparence vis-à-vis de la duplication de données
Les utilisateurs ne peuvent en aucun cas savoir si les
données auxquelles ils accèdent sont en copie disponibles. La
conséquence est que lors de la modification d’une information,
c’est le système qui préoccupe de mettre à jour toutes les copies.
P a g e | 27
5. Fonctionnement en continue
La distribution permet de résister aux fautes et pannes.
6. Egalité des sites
Un site en panne ne doit pas empêcher le fonctionnement des
autres sites.
I.2.5. Systèmes de Gestion de Base de Données (SGBD)
a) Système de Gestion de Base de Données

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.
b) 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. 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.
Note : Il existe plusieurs SGBDD, qui puissent être différents les
uns des autres, et eux tous ont un point que voici en commun :
les données et les logiciels sont distribués sur plusieurs sites
interconnectés par un 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 SGBDD, c’est
l’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é :
Facteur 1 : Si tous les serveurs (ou les SGBDD 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.
P a g e | 28
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. - 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, 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.6. Conception de base de données répartie
La conception des bases de données réparties a pour objectif
de minimiser le temps que peut prendre le traitement d’une
requête, temps de transfère ou le volume de données transférées.
Cependant nous distinguons deux types de conceptions de la
base de données répartie.
I.2.6.1. Conception ascendante
Il s’agit de construire une base de données globale à
partir des bases de données locales. En d’autres termes il existe
déjà des schémas locaux qu’il faut mettre en un seul schéma
global, signalons que cette démarche demande une attention
particulière, car il faut résoudre le problème d’hétérogénéité de
système.
P a g e | 29
BDR
BD1
BD3
BD2
Figure 6 : Conception ascendante

I.2.6.2. Conception Descendante
A partir d’un schéma conceptuel global, on construit des schémas
conceptuels locaux, puis on fragmente les données dans les
différents sites selon le besoin.
BDR
BD1 BD3
BD2
Figure 7 : Conception descendante
I.2.7. Principe d’une base de données répartie
La transparence est l’élément clé pour un système réparti c’est- à-

dire que l’utilisateur ne doit en aucun cas savoir ce qui est caché
derrière les données qu’il utilise. Ce principe est la transparence
pour l’utilisateur.
Nous distinguons quatre niveaux de transparences de
répartition qui sont :
P a g e | 30
1. Transparence de Localisation
La transparence de localisation consiste à cacher la position
physique des données c’est-à-dire que les utilisateurs n’ont pas à
savoir la provenance de données auxquelles ils accèdent, seul le
système s’occupe à chercher le site où sont stockées les données
dont l’utilisateur a besoin.
2. Transparence de Fragmentation ou Partition Lors de la

conception d’une base de données répartie, les données sont
fragmentées selon le besoin dans différents sites, la transparence
de fragmentation consiste à priver à l’utilisateur le droit de savoir
si les données ne sont partitionnées ni le nom du
partitionnement. Le système a l’obligation de transformer une
requête lancée par l’utilisateur en plusieurs requêtes de partition.
3. Transparence d’allocation
Les fragments sont des portions logiques globales qui sont
uniquement situées dans un ou plusieurs sites du réseau. La
transparence d’allocation définit le site dans lequel est situé un
fragment. La relation définit dans la transparence d’allocation
détermine si la base de données répartie est redondante ou pas.
4. Transparence Conceptuelle Locale
La transparence conceptuelle locale définit une fonction qui
associe chaque image physique aux objets qui sont manipulés par
les systèmes de gestion de base de données locale.
I.2.8. Niveaux de répartition
Le niveau de répartition intervient en trois niveaux de son
architecture en plus de la répartition physique. 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.
P a g e | 31
Figure 8 : Architecture d’une BDD Vue Externe

1. Niveau Externe
Les schémas externes (vues) sont distribués sur les sites
utilisateurs.
2. 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épartis sur plusieurs sites, les sites physiques.
3. 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.
Pour que l’on puisse parler d’une vraie base de données
répartie il faut que tous les niveaux de répartition soient respectés
sinon on aura affaire à des clients éloignés (répartition interne).
On doit aussi remarquer que la distribution de base de
données se réalise plus ou moins conformément à la répartition
logique des utilisateurs et à la répartition physique des moyens
informatiques.
P a g e | 32
I.2.9. Technique de fragmentation

I.2.9.1. Définition
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. Les règles à suivre pour fragmenter les données
:
 La complétude : toutes les données du schéma global
doivent se retrouver dans les partitions ;
 La construction : la possibilité de reconstruire toute
relation décomposée en un ensemble de fragments ;
 La disjonction : permet de contrôler la redondance au
niveau de l’allocation.
I.2.9.2. Types de fragmentation
Il existe trois types de fragmentation qui sont :
1. Fragmentation horizontale
Elle consiste à découper une relation (Table) permettant de
sélectionner les lignes d’enregistrement selon un critère donné. La
relation initiale sera obtenue par l’union de fragments. Ci -
dessous le tableau de fragmentation horizontale.
P a g e | 33
Tableau 1 : Montrant l'exemple d'illustration de la fragmentation

horizontale
CODE NOMS ADRESSE TELEPHON NIVEAU_ETUD
E E
01/201 MISIA NDJILI 089 UNIVERSITE
5 JOYCE 6689262
03/201 SAMBU BARUMBU 0824725941 HUMANITE
6 SAMBU
15/201 NONDO CITE VERTE 0826265966 UNIVERSITE
3 SERGE
18/201 REAGEN LEMBA 0829508240 UNIVERSITE
0 MISIA
11/200 MWABO PLATEAU 0815979184 UNIVERSITE
2 SARAH
Tableau 1 : Montrant l'exemple d'illustration de la
fragmentation horizontale
Source : exemple illustrant un moyen humain d’une petite entreprise
d’impression
N.B. : Fragment est une sous-table obtenue par sélection de

lignes (horizontale) et de colonne (verticale) à partir d’une table
globale, localisée sur un site unique.
Et les fragments sont obtenus par sélection, soit :
- Ingénieur travaux 1= SELECT* FROM Ingénieur travaux

WHERE NIVEAU_ETUD = ‘UNIVERSITE’ ;
- Ingénieur travaux 2= SELECT* FROM Ingénieur
travaux WHERE NIVEAU_ETUD <> ‘UNIVERSITE’
P a g e | 34
Ingénieur travaux 1 :
Tableau 2 : Illustration de la fragmentation horizontale 1
CODE NOMS ADRESSE TELEPHONE NIVEAU_ETUD
E
01/201 MISIA JOYCE NDJILI 089 6689262 UNIVERSITE
5
18/201 REAGEN MISIA LEMBA 0829508240 UNIVERSITE
0
11/200 MWABO SARAH PLATEAU 0815979184 UNIVERSITE
2
Ingénieur travaux 2 :
Tableau 3 : Illustration de la fragmentation horizontale 2
CODE NOMS ADRESSE TELEPHON NIVEAU_ETUD

E E
03/201 SAMBU BARUMBU 0824725941 HUMANITE
6 SAMBU
15/201 NONDO CITE VERTE 0826265966 UNIVERSITE
3 SERGE
La relation initiale est obtenue par union des fragments. Ceci

revient à dire que :
Ingénieur travaux = Ingénieur travaux 1 U Ingénieur
travaux 2
2. Fragmentation verticale
Elle permet de découper une table en sous table en
permettant de projeter certaines colonnes, sauf la clé primaire.
Car elle servira de lien. La relation initiale doit pouvoir être
recomposée par jointure des fragments. Ci-dessous le tableau de
fragmentation verticale.
P a g e | 35
Exemple d’illustration : Soit la relation ou table suivante :

Commande Tableau 2 : Illustration d'une fragmentation
verticale
Tableau 4 :
Num_Cmd Id_Client Id_Prod Quantite

NumC1 1 P1 500
NumC2 2 P2 1000
NumC3 3 P3 300
NumC4 4 P4 400
Tableau 4 : Exemple d'illustration d'une fragmentation verticale
Les fragments sont obtenus par projection, soient :

> Commande_1=SELECT Num_Com, Id_Client FROM
Commande ;
> Commande_2=SELECT Num_Com, Id_Prod, Quantit
FROM Commande ;
Commande_1 :
Tableau 5 :
Num_Cmd Id_Client
NumC1 1
NumC2 2
NumC3 3
NumC4 4
Commande_2 :
P a g e | 36
Tableau 6 :
Num_Cmd Id_Prod Quantite
NumC1 P1 500
NumC2 P2 1000
NumC3 P3 300
NumC4 P4 400
Commande = (SELECT* FROM Commande_1,

Commande_2 WHERE Commande_1.Num_Cmd=
Commande_2.Num_Cmd) ;
La reconstruction est obtenue à partir d’une sélection avec
un critère sur la clé primaire, qui est un lien entre les
fragments.
3. Fragmentation Mixte C’est un agencement de la

fragmentation horizontale (Sélection) et la fragmentation verticale
(Projection) sur un schéma global.
I.2.10. Schéma d’allocation

Après la fragmentation de la base de données, il se pose un
problème d’allocation. En fait, l’allocation est le placement des
fragments sur différents sites où ils sont le plus utilisées.
L’allocation peut se faire avec réplication ou sans réplication,
sachant que la réplication favorise la performance et diminue le
trafic entre les sites.
I.2.11. Avantages et Désavantages de Base de Données Répartie
Voici quelques avantages retenus d’une base de données réparties, on a :
 Le rapprochement des données selon qu’un site les demande
plus, ce qui permet la réduction de coût de communication ;
P a g e | 37
 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 ;
 La continuité de services ;
 Une intégration facile dans un système existant .
Nous ne retenons qu’une seule contrainte que nous jugeons
pertinente : c’est la complexité, qui se situe dans la conception
d’une base de données réparties par rapport à celle qui est
centralisée. Cette conception prend en compte la fragmentation
des données, l’allocation des fragments dans des sites et la
réplication.
Voici les problèmes que connaissent les bases de données
réparties :
 Coût : la distribution de données entraîne des coûts
supplémentaires en termes de communication, et en
gestion des communications (hardware et software à
installer pour gérer les communications et la distribution).
 Problème de concurrence.
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.
P a g e | 38
CHAPITRE II : REPLICATION DE DONNEES
II.0. INTRODUCTION
Aujourd’hui, les bases de données sont de plus en plus utilisées au

fur et à mesure que le monde informatique se développe et que les
flux de données augmentent sur internet.
Ainsi, il y a un plus gros besoin de transférer des données entre

bases de données. La synchronisation est une solution efficace à cette
problématique. Elle est particulièrement utile dans des situations
telles que la sauvegarde de données, synchroniser des bases de
données qui ont été modifiées sur différents serveurs ou encore
envoyer à un utilisateur seulement les données dont il a besoin.
Pour de nombreuses applications scientifiques ayant recours aux

systèmes à large échelle, les quantités de données nécessaires aux
traitements de ces applications sont très importantes. De telles
quantités de données impliqueraient de très grands délais de
transfert si seule une copie de ces données était stockée.
II.1. Définition
La réplication est un processus de duplication des informations
pour assurer la cohérence des données entre plusieurs sites de
données redondantes, enfin d’améliorer la fiabilité, la tolérance aux
pannes et la disponibilité. On parle de la réplication de données même
si les données sont déjà dupliquées sur plusieurs sites.
La réplication repose sur un ensemble de technologies qui
permettent de copier et de distribuer des données et des objets de
base de données d’une base de données vers une autre puis de
synchroniser ces bases des données afin de préserver la cohérence.
La réplication n’est pas à confondre avec la sauvegarde : les
données sauvegardées ne changent pas dans le temps tandis que les
données répliquées évoluent sans cesse à mesure que les données
sources changent.
P a g e | 39
Elle est aussi considérée comme la capacité à maintenir à jour

une base de données distribuée sur plusieurs machines (sites) reliées
en réseau, en recopiant à l’intervalle régulier des morceaux ou
l’intégrité de la base d’une machine à l’autre. Plusieurs méthodes de
réplication existent selon la configuration matérielle présentée.
La réplication assure la disponibilité des données mais doit
aussi garantir la cohérence des copies en cas de mises à jour parce
que, lorsqu’une transaction met à jour une copie, toutes les autres
copies sont également mises à jour dans la même transaction
distribuée.
Nous pouvons en retenir qu’elle augmente la performance, en
diminuant la charge qui devrait être imposée à un seul site (serveur).
La réplication de données favorise la disponibilité en cas de pannes
par exemple, elle permet donc de travailler avec les données d’un site
si une 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. 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.
IL faut donc faire le contrôle de la réplication, pour assurer la
cohérence de la base. Cette mise à jour peut s’enclencher
automatiquement ou manuellement.
II.2. Principes
Le principe de la réplication qui met en jeu au minimum deux
systèmes de gestion de base de données est assez simple et se déroule
en trois étapes
1.Lorsqu’il y a modification (INSERT, UPDATE ou

DELETE). Les données, la base source reçoit un ordre de mise à
jour.
P a g e | 40
2. Les modifications faites sur les données sont détectées

et stockées dans un fichier ou une file d’attente en vue de leur
propagation.
3. Le processus de réplication prend en charge la
propagation des modifications à faire sur une seconde base dite
esclave, Il peut bien entendu y avoir plus d’une base esclave.
II.3.Types des Mises à Jour

Nous distinguons deux types de mises à jour : la mise à jour
synchrone et la mise à jour asynchrone.
1. Mise à jour Synchrone
Lorsqu’il y a modification des données sources, la mise à jour

des copies dans d’autres sites doit se faire dans l’immédiat c’est-à-dire
que la mise à jour se fait en temps réel pour assurer la cohérence des
copies.
Site 2
Site 1 Site 3
Figure 9 : Mise à jour synchrone

 Avantages
Assure l’uniformité des copies ;
La mise à jour des copies la plus récente (dernière mise à
jour).
P a g e | 41
 Désavantages
La transaction risque de ne pas se terminer complètement si
d’autre sites qui détiennent les répliques sont tombés en
panne par exemple ;
Le nombre de messages nécessaires pour coordonner la
synchronisation des données impose une charge importante
aux réseaux d’entreprises.
2. Mise à jour Asynchrone
C’est après la validation que les modifications effectuées par la
transaction seront diffusées sur les autres sites après un certain
temps. Le temps de propagation de mise à jour des autres copies
est choisi.
Maitre
Site 4
Site 1
Site 2 Site 3
Figure 10 : Mise à jour asynchrone

P a g e | 42
 Avantages
Les transactions sont toujours locales (un bon temps de
réponse) ;
Le temps de propagation de mise à jour est choisi
 Désavantages
Les données ne sont pas les mêmes dans tous les sites
(incohérence des données), momentanément ;
Pas d’accès à la dernière version de la mise à jour en temps
réel.
II.4. Types de Réplications

Il existe des réplications qui se font dans deux directions
autrement dit symétrie c’est-à-dire que (maître vers esclave ou esclave
vers maître) et des réplications dans un seul sens ou asymétrique
(maître vers esclave).
II.4.1. Réplication symétrique
Ce modèle de réplication dont tout site est maître et tous ont
des droits égaux de modifier les données dupliquées. Ceci permet à
des sites de fonctionner en toute autonomie même lorsque les autres
sites ne sont pas disponibles. Dans ce mode de réplication la charge
est distribuée dans chacun de site.
 Avantages
La charge est distribuée dans chaque site ;
Tout site est maître et tous ont des droits égaux de modifier les
données dupliquées.
 Désavantages
Les copies ont besoin tout le temps de la synchronisation ;
II.4.2. Réplication Asymétrique
La réplication est dite asymétrique lorsqu’elle se réalise en une
seule direction ou en lecture simple c’est-à-dire que le site maître
contient les noms et les identifiants de différents sites esclaves ainsi
que la date de dernière synchronisation.
P a g e | 43
Le site maître met des données à disposition des sites esclaves.

Les sites esclaves s’abonnent aux données possédées par le site
maître, ce qui signifie qu’ils reçoivent des copies en lecture seule sur
leurs propres systèmes locaux et le site maître effectue les contrôles et
garantit l’ordonnancement correct de mises à jour.
 Avantages
Un seul site assure les modifications sur tous les autres ;
Aucune synchronisation inter site n’est nécessaire (elle se
réalise au niveau de la copie primaire (primary copy).
 Désavantages
La charge obligée au site maître peut causer des problèmes ;
La lecture locale peut risquer de ne pas rendre une valeur la
plus mise à jour.
II.5. Techniques de la Réplication
Il existe quatre techniques ou stratégies de réplication. Elles
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.
1. Réplication asymétrique synchrone
Elle utilise un site primaire qui pousse les mises à jour en
temps réel vers un ou plusieurs sites secondaires. La table répliquée
est immédiatement mise à jour pour chaque modification par
utilisation de trigger sur la table maîtresse.
Ce mode de réplication garanti la cohérence des données
puisque le site maître doit propager la mise à jour, c’est naturel que
l’exécution de la transaction soit Long.
2. Réplication asymétrique asynchrone
Elle pousse les mises à jour en temps différé via une file persistante.
Les mises à jour seront exécutées ultérieurement, à partir d’un
déclencheur externe, la mise à jour n’est pas coordonnée puisque le
P a g e | 44
temps de l’exécution de la transaction est court malgré que les

données ne sont pas conformément dans tous les sites après un
certain temps.
3. Réplication symétrique asynchrone

Toute modification sur toute table de toute base est stockée
dans une file pour être rejouée ultérieurement. 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 réalise presque manuellement.
4. Réplication symétrique synchrone
Il n’y a pas de table maîtresse ; mais chaque table possède ses
triggers déclenchés lors d’une modification. Il est alors nécessaire de
définir des priorités et de gérer les blocages des tables en attendant
qu’une modification soit entièrement propagée.
La cohérence de données 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, mais une tolérance à la panne très
élevée.
Le tableau suivant illustre ces techniques ; les avantages et les
désavantages de la combinaison des techniques.
Symétrique Asymétrique
Synchrone Réplication symétrique Réplication
Synchrone asymétrique
synchrone
P a g e | 45
Avantage : Avantages :
• Pas d’incohérence ; • Les modifications n’ont
pas besoin d’être
Egalité de site.
Désavantages : coordonnées ;
• Un temps de réponse • Pas d’incohérence.
long ; Désavantages :
• Les modifications ont • Un temps de réponse
besoin d’être plus long
coordonnées. ;
• Seulement important
avec peu de
modifications ;
• Les copies locales ne
sont que localement.
Asynchron Réplication Réplication
e symétrique asymétrique
asynchrone asynchrone
Avantages : Avantages :
• Pas de coordination • Pas de coordination
centralisée ; nécessaire ;
• Temps de réponse • Temps de réponse court.
très court.
Désavantages : Désavantage :
• Incohérence ; Les copies locales ne sont
• Les mises à jour pas mises à jour ;
peuvent être perdues. Incohérence
II.6. Avantages et inconvénients de la réplication de
base de données
La réplication présente des avantages différents selon le type de
réplication et les options, mais l’intérêt général de la réplication est la
disponibilité des données à tout moment et en tout lieu.
II.6.1. Avantages de la Réplication
 Possibilité pour plusieurs sites de conserver des copies des
mêmes données. Cela est utile lorsque plusieurs sites ont
P a g e | 46
besoin de lire les mêmes données où requièrent des serveurs

différents pour les applications de création de rapport.
 Autonomie accrue, les utilisateurs peuvent manipuler des
copies de données hors connexion, puis proposer leurs
modifications aux autres bases de données lorsqu’elles sont
connectées.
 Amélioration des performances de lecture des agrégats.
 Rapprochement des données par rapport aux utilisateurs

individuels ou groupes. Cela permet de réduire les conflits
liés aux modifications de données et requêtes impliquant
plusieurs utilisateurs. En effet, les données peuvent être
distribuées sur l’ensemble du réseau et partitionnées en
fonction des données des différents utilisateurs ou unités de
l’entreprise.
II.6.2. Désavantages de la Réplication

 Consommation élevée des ressources du serveur suivant la
position du distributeur ;
 Les modifications de schéma ne peuvent pas être prise en
compte suivant le mode de réplication ;
 Les problèmes de réplication suivant affectent la
performance de vos réseaux
II.7. Réplication sous Microsoft SQL Server
II.7.1. Entités présentes dans une réplication
En général, la réplication repose sur trois principales entités :
l’éditeur, le distributeur et l’abonné. Le distributeur représente la vue
ou le segment de la base de données à distribuer. Une fois que ces
trois entités sont réunies, la mise en place d’un système de réplication
est possible avec au préalable une connexion reliant les différents
serveurs de base de données.
P a g e | 47
1) Un éditeur
Un éditeur est un serveur correspondant à la source des
données à répliquer. L’éditeur définit un article pour chaque table ou
autre objet de base de données à utiliser comme source de réplication.
L’éditeur est en réalité le serveur qui rend disponible les données
destinées à être répliquées. Les données sont organisées en groupes
logiques appelés « publication ».
Un éditeur peut avoir plusieurs publications différentes ; les
publications constituent un moyen pratique de regrouper des données
et des objets associés que vous souhaitez répliquer ensemble.
2) Le distributeur
Un distributeur est un serveur qui effectue différentes tâches
lors du transfert des articles entre les éditeurs et les abonnés. Les
tâches effectivement réalisées varient en fonction du type de
réplication que l’on implémente.
On distingue néanmoins deux types de distributeurs :
distributeur local et distributeur distant. Un distributeur local est un
serveur qui est configuré pour être en même temps un éditeur et un
distributeur alors qu’un distributeur distant est un serveur qui est
séparé de l’éditeur et qui n’est configuré que pour distribuer les
réplications.
3) Les abonnés
Un abonné est un serveur qui reçoit les données répliquées par
l’éditeur. L’abonné définit un abonnement à une publication
particulière.
L’abonnement spécifie à quel moment l’abonné reçoit la
publication de l’éditeur, et mappe les articles aux tables et autres
objets de base dans l’abonné.
Les abonnées s’abonnent à des publications (et non à des

articles dans une publication), de plus, ils ne s’abonnent qu’aux
publications dont ils ont besoin et non à toutes les publications
présentes chez l’éditeur. En fonction du type réplication et des options
P a g e | 48
choisies, l’abonné peut propager les changements qu’il fait aux

données à l’éditeur et même les publier pour les autres abonnés.
 Un article
Un article est un objet des bases de données destinées à être répliqué.
Il s’agit d’une table entière, d’une partie de la table (filtres horizontaux
et verticaux) d’une procédure stockée d’une vue indexée d’une
fonction utilisateur.
 Une publication
Une publication est le regroupement d’un ou plusieurs articles d’une
même base de données. La possibilité de regrouper les articles en
publication facilite la conception et permet de définir un ensemble
homogène et logique de données que l’on souhaite répliquer ensemble.
 Un abonnement
Un abonnement est la demande de recevoir une publication. Il définit
quelle publication sera reçue où et quand.
II.7.2. Agent de la Réplication
Les agents de réplication SQL server s’occupent des processus
de copie et de distribution des données. Il existe l’agent SQL server,
ainsi que des agents spécifiques à chaque type de réplications.
1) Agent SQL Server
L’agent SQL server gère et organise les agents utilisés dans la

réplication, c’est le moyen le plus efficace de lancer les agents de
réplication. Il s’occupe également de différentes tâches en dehors de la
réplication.
2) Agent de Capture Instantanée
Cet agent utilise tous les types de réplication. Il prépare le
schéma, les fichiers de données et les procédures stockées devant être
répliqués. Il enregistre aussi les informations de synchronisation dans
la base de données de distribution.
P a g e | 49
3) Agent de Lecture du Journal

Il est utilisé pour la réplication transactionnelle. Il surveille le
journal des transactions de chaque base de données et identifie les
transactions devant être répliquées. L’agent copie ensuite les
transactions dans la base de données de distribution, elles seront
donc distribuées aux abonnés. Il est à noter que chaque base de
données possède son propre agent de lecture du journal.
4) Agent de distribution
L’agent de distribution est utilisé dans la réplication de
capture instantanée et dans la réplication transactionnelle. Son rôle
est de distribuer aux abonnés les captures instantanées et les
transactions présentes dans la base de données de distribution. Il
s’exécute au niveau du distributeur pour les abonnements envoyés et
au niveau de l’abonné pour les abonnements extraits.
5) Agent de la fusion
Utilisé dans la réplication de fusion, c’est un agent qui applique

la capture instantanée initiale à l’abonné. Ensuite, il doit propager et
fusionner les changements faits aux données (le processus de
résolution de conflit est initié par cet agent).
6) Agent lecture de file d’attente

Cet agent est utilisé avec la réplication de capture instantanée
ou transactionnelle si l’option de mise à jour en attente est active ou
si l’option de mise à jour immédiate avec mise à jour en attente en cas
de problème est activée.
Son rôle est de propager les messages de file d’attente aux
publications appropriées, c’est un agent multithread exécuté sur le
distributeur.
Contrairement aux autres agents, un seul agent de lecture de file
d’attente s’occupe de tous les éditeurs et publications d’un
distributeur donné.
P a g e | 50
II.7.3. Mode de réplication sous SQL Server

Il existe trois modes de réplications sous SQL Server 2008 :
II.7.3.1. Réplication de Capture Instantanée

La réplication de capture instantanée distribue les données
exactement telles qu’elles apparaissent à un moment précis dans le
temps (d’où le terme d’instantanée) et ne surveille pas les
changements faits sur les données répliquées car ces changements ne
sont pas répliqués aux abonnés.
Dans ce mode de réplication, c’est l’intégralité des données
répliquées qui sont redistribuées aux abonnés lors de la
synchronisation et non pas les seuls changements de façon
incrémentielle.
Comme l’ensemble de données est répliqué, le temps de
traitement peut être plus long qu’en réplication transactionnelle dont
nous allons parler dans la suite. En revanche ce type de réplication
demande moins de ressources processeur car il n’est pas nécessaire
de surveiller les changements en continu sur les serveurs sources. De
plus, les données sont en général répliquées moins souvent que dans
les autres types de réplication.
Elle est préférable à la transactionnelle lorsque les changements
faits sur les données sont conséquents mais peu fréquents. La
réplication de capture instantanée est idéale pour répliquer des
données qui ne sont que rarement modifiées, des données dont on n’a
pas besoin d’avoir les dernières valeurs ou bien encore des données
destinées à la lecture seule comme une liste de prix par exemple.
Il peut cependant être nécessaire pour les abonnés de pouvoir
modifier les données de réplication. Dans ce cas la consistance des
transactions, c’est à - dire le fait que les transactions soient validées
sur tous les serveurs ou sur aucun est assurée par un protocole de
validation.
II.7.3.2. Réplication Transactionnelle
Dans la réplication transactionnelle, la première phase consiste
en fait à faire une réplication instantanée. L’ensemble des données
destinées à la réplication est distribué aux abonnés. En revanche, la
P a g e | 51
suite du processus est différente de la réplication instantanée. Une

fois les données sont répliquées pour la première fois, chaque
transaction sera propagée de façon continue ou différée.
SQL Server surveille les instructions INSERT, DELETE et
UPDATE et d’autres changements faits sur les données et enregistre
ces données dans la base de données qui joue alors un rôle de file
d’attente. Les transactions sont ensuite propagées dans l’ordre dans
lequel elles ont été efficaces.
Ce mode de réplication est riche de possibilité, on peut choisir
de propager les transactions quand elles ont lieu (presque en temps
réel) ou à intervalle régulier. On peut en outre choisir de pouvoir faire
des modifications ou non sur les abonnés, pour propager ensuite ces
changements à l’éditeur et aux autres abonnés. Il faut faire attention
à la façon dont sont utilisées ces options.
Certaines configurations peuvent engendrer des conflits ; si on

choisit par exemple de propager les transactions de façon différée et
que l’on décide de pouvoir réaliser des modifications sur les abonnés,
il peut en résulter des conflits. Par exemple, l’abonné peut effacer des
données qu’une transaction antérieure sur le serveur source à
modifiées, mais cette transaction n’a pas encore été propagée. Quand
l’abonné la recevra, une erreur surviendra car la transaction devra
modifier des données qui n’existent plus.
II.7.3.3. Réplication de Fusion
La réplication de fusion associe les avantages des réplications
de capture instantanée et de réplication transactionnelle. Elle consiste
à répliquer les données de l’éditeur aux abonnés, puis à laisser
l’éditeur et les abonnés faire des modifications pendant qu’ils sont
connectés ou déconnectés et enfin de fusionner ces transactions entre
les différents sites quand ils sont connectés.
La réplication de fusion permet à plusieurs sites de travailler
indépendamment les uns des autres, afin de réaliser des
modifications sur les données de réplication chacun de son côté, puis
fusionner toutes ces modifications en un ensemble cohérent.
Les modifications sont propagées immédiatement à intervalle
régulier ou à la demande. Comme des copies de données peuvent être
P a g e | 52
modifiées en même temps à plusieurs endroits, des conflits peuvent

apparaître au moment de la fusion des modifications. SQL Server
permet de configurer la façon dont ces conflits seront résolus en
fonction de l’utilisation que l’on a.
II.8. Transaction Dans la Base de Données
Répartie
a. Définition d’une transaction
Une transaction désigne un ensemble d'opérations effectuées de
manière indivisible sur une base de données qui la transforme d’un
état stable cohérent à un autre état stable cohérent. Elle est soit
validée par un Commit, soit annulée par un rollback soit interrompue
par un a bort. Afin de garantir la stabilité du système, une transaction
doit valider quatre propriétés indispensables suivantes : Atomicité,
Cohérence, Isolation et Durabilité.
Figure 11 : une transaction dans une base de données cohérente
En cas d’interruption, la transaction laisse la base de données

dans son état dans lequel elle se trouvait ; d’où l’on parle de quatre
types d’opérations pour assurer la cohérence de la base de données :
Le début de transaction, la lecture, l’écriture et enfin la terminaison.
Une transaction peut ou ne pas arriver à son terme, elle peut
être interrompu pour diverses raisons. Pour assurer la cohérence de
la base de données, il y a quatre ordres de transaction :
Begin : cet ordre permet de démarrer de manière explicite une
transaction.
P a g e | 53
Commit : permet de mettre fin avec succès à une transaction,

c’est-à-dire la conservation de l’ensemble de modifications
effectuées dans la transaction.
Roll back : permet de terminer une transaction en annulant
toutes les modifications de données effectuées.
Save : permet de définir un point d’arrêt, donc donne la

possibilité d’annuler une partie de la transaction en cours. Il est
possible de définir plusieurs points d’arrêt sur une même
transaction.
II.8.1. Propriétés d’une transaction (ACID)

Une transaction doit garantir les propriétés suivantes :
Atomicité, Cohérence, Isolation et Durabilité. Ce qui est aussi connu
sous le terme d’acidité d’une transaction.
 Atomicité : Cette propriété signifie que toutes les opérations
d'une transaction sont menées de façon indivisible ; toutes
les opérations doivent être validées, si non tout est annulé
 Cohérence : une transaction doit faire passer la base de
données d’un état cohérent à un autre. Ou encore Il s’agit de
prendre les données dans un état Cohérent et les rendre
dans un état cohérent.
 Isolation : lors de la modification, une transaction, doit être
invisible pour les autres transactions.
 Durabilité : Les actions d’une transaction ne peuvent être
perdues lorsqu’une transaction est validée. C’est-à-dire tout
résultat produit par une transaction doit être permanent et
ne doit souffrir d’aucune altération, quelques soient les
pannes du système.
II.8.2. Validation en deux phases
Elle a comme principe de diviser la validation en deux
phases. Le protocole de validation en deux phases permet
P a g e | 54
simplement de coordonner l’exécution des commandes «

COMMIT » sur tous les sites participant à une transaction.
La première phase :
Elle consiste à réaliser la préparation de l’écriture des

résultats des mises à jour dans la base de données et la
centralisation du contrôle.
La deuxième phase :
Dans la deuxième phase, elle est conditionnelle et elle est
réalisée seulement en cas de succès de la première phase. Elle intègre
effectivement les résultats des mises à jour dans la base de données
réparties. Le contrôle du système réparti est centralisé sous la
direction d’un site appelé coordonnateur, les autres n’étant que des
participants.
 Coordonnateur de validation
C’est le composant système d’un site qui applique le protocole

c’est à dire il lance la transaction, la découpe en sous-transactions à
exécuter sur les différents sites, coordonne la terminaison de la
transaction. Il dirige le protocole en centralisant le contrôle.
 Participant à la validation
C’est le nœud du système réparti qui exécute des mises à jour

de la transaction et obéit aux commandes de préparation, de
validation ou d’annulation du coordonnateur. Il participe dans
l’exécution de la transaction.
II.8.3. Classification des transactions
La transaction se classifie de la manière suivante en générale :
P a g e | 55
 La requête distante
Une application envoie une requête sur un site distant sous forme
d’une instruction SQL pour qu’elle s’y exécute. La requête est
totalement exécutée sur le site distant et a tous les loisirs de faire
référence aux données situées sur ce seul site.
 La requête distribuée
Une application à un site local envoie une partie ou toutes les

instructions SQL d’une transaction à un ou plusieurs sites distants
en vue de leur exécution. Ici, une instruction SQL peut
éventuellement accéder à des données de plus d’un site.
 L’unité de travail distante
A ce niveau l’application se trouve sur un site local, il envoi

toutes ses instructions SQL sous forme d’une unité de travail
(transaction) à un site distant pour qu’elles s’y exécutent. Toutes les
instructions SQL sont entièrement situées dans ce site. C’est
toutefois le site local qui décide si la transaction doit être validée ou
annulée.
 L’unité de travail distribuée
Une application sur un site local envoie certaines ou toutes les

instructions SQL d’une transaction à un ou plusieurs sites distants
en vue de leur exécution sur ceux-ci. Chaque instruction SQL
s’exécute en totalité sur le site distant et ne peut faire référence à des
données que de ce seul site.
Cependant, différentes instructions SQL peuvent s’exécuter sur des
sites distincts. Ici aussi, le site local décide de la validation ou de
l’annulation de la transaction.
P a g e | 56
CHAP 3. PRESENTATION DU CADRE D’ETUDE ET

ANALYSE PREALABLE
3.1 Présentation de l’entreprise
Le Ministère de l’Intérieur, Sécurité, Décentralisation
et Affaires Coutumières est un établissement public à
caractère technique, social et sécuritaire, doté de la
personnalité juridique, ci-après dénommé « Ministre de
l’Intérieur »
3.1.1 Historique
Le Ministère de l’Intérieur, Sécurité, Décentralisation
et Affaires Coutumières du Congo (RDC) est un ministère
congolais chargé de la politique de l’administration du
territoire. Le ministère dont fait l’objet de cette étude fut créé
par un décret en 11 septembre 1996 N°025 portant la
création du conseil de protection civil, en abrégé CPC soit
(Ministère de l’Intérieur )
3.1.2 Missions du ministère
Le Ministère de l’Intérieur, Sécurité, Décentralisation et
Affaires Coutumières a pour missions principales La
P a g e | 57
surveillance des frontières et la police des étrangers en

République Démocratique du Congo, tout en mettant de
l’ordre dans toutes les étendues de la RDC. Parmi ces
missions, nous avons pu relever certaines qui sont
primordiales :
 La Coordination des rapports entre les membres du

Gouvernement Central et des Gouverneurs de Province ;
 L'Organisation, le fonctionnement et l'agrément des partis et
regroupements Politiques ;
 L'Identification, l'encadrement et le recensement administratif
des populations ;
 Le suivi et la surveillance des mouvements des populations à
l’intérieur du pays ;
 Le Statut des réfugiés ;
 La Collaboration avec la Commission Electorale Nationale
Indépendante dans la préparation des élections ;
 La Coordination de la gestion des catastrophes naturelles en
collaboration avec les Ministères concernés;
 La Protection des personnes déplacées internes ;
 La Politique de la sûreté nationale intérieure et extérieure ;
 Le Maintien de l’ordre public, de la sécurité publique et la
protection des personnes et de leurs biens ;
 Le Pouvoir hiérarchique sur la Police Nationale et les services de
sécurité ;
 La Politique de lutte contre le terrorisme ;
 La surveillance des frontières et la police des étrangers en
République Démocratique du Congo ;
 La Gestion des matières relatives aux maisons de gardiennage ;
 L'Elaboration des rapports périodiques sur l’état de la Nation et
 L’Application de la législation sur les armes à feu.
3.1.3 Organigramme et Description des tâches

Partant de la direction provinciale de Kinshasa qui est le
siège par Excellence du ministère, nous pouvons voir
l’acheminement des agents ainsi que les tâches de la haute
direction de subalternes qui exécutent des ordres. Notre
ministère est organisé de la manière suivante :
P a g e | 58
Le Ministère de l'Intérieur, Sécurité, Décentralisation et

Affaires Coutumières de la République Démocratique du
Congo compte un effectif total de 237.016 personnels répartis
comme suit :
 Le ministre qui avec son cabinet joue un rôle qui est non
seulement primordial et du premier en vergue qui à toute la
mission du Ministère de l’Intérieur, Sécurité, Décentralisation et
Affaires Coutumières.
 Le secrétaire général, haut fonctionnaire, assiste le ministre de

l’intérieur pour l’administration du ministère. A cette fin, il
coordonne l’action et l’évaluation de l’ensemble des services.
Il propose au ministre la répartition entre eux des moyens. Il est

le responsable de la fonction financière ministérielle.
 L’Office National de Tourisme qui comprend :

o La Direction Générale de Migration (7.921 Agents) ;
o L’Agence Nationale des Renseignements (12.544 Agents) ;
o L’inspectorat Général de la Territoriale (844 Agents) ;
o L'Ecole Nationale de Formation Territoriale ;
o Le Conseil de la Protection Civile.
 La Gendarmerie Nationale comprend :
o Le Comité de suivi de la Réforme de la Police ;

o Le Commissariat Général de la Police Nationale Congolaise
(192.653 Agents) ;
o L'inspection Général de la Police Nationale Congolaise ;
o La Commission Nationale du Désarmement et de la Sécurité
Internationale ;
o La Commission Nationale de Contrôle des Armes Légères et
de Petits Calibres ;
o La Commission Nationale pour les Réfugiés ;
o Le Centre Congolais Anti-mines (74 Agents) ;
3.1.3.1 Organigramme de l’Office

P a g e | 59
Figure 12 : Organigramme Général du Ministère
3.1.3.2 Description des Tâches

Les structures organiques de l’office sont :
- Le cabinet du ministre ;
- Le secrétariat général ;
- Les structures sous tutelle.
3.2 Etude d’Opportunité
Nous nous sommes focalisés sur la gestion de tous les agents
selon leur niveau d’étude et leur sexe et la gestion des
matériels informatiques avec les logiciels.
Nous aurons comme étude à réaliser :
3.2.1 Etude des Moyens Matériels
Nous verrons tous les matériels et leurs descriptions. Nous
allons illustrer cette présente étude à l’aide d’un tableau ci-
dessous :
P a g e | 60
3.2.2 Etude des Moyens Humains

Nous allons illustrer cette étude à l’aide du tableau ci-
dessous :
P a g e | 61
3.3 Gestion Actuelle d’Identification des Agents

La gestion actuelle des agents se fait manuellement, d’où les
agents remplissent une fiche d’enregistrement tout en
insérant des documents qui présentent le niveau d’études
(Diplôme, Attestation de réussite, à qui de droit, etc…) et le
gestionnaire se charge de l’enregistrer afin qu’il puisse être
traités par la suite.
Une fois le traitement du dossier de l’agent traité, une carte
de service lui est délivrée afin qu’il soit identifié dans la
banque des données.
3.4 Critique de l’existant
Du point de vue critique de l’existant nous avons deux points
qui sont :
3.4.1 Les Points Positifs
Le stockage des informations avec l’outil Excel permet de
disposer d’une banque des données au niveau du siège
P a g e | 62
provincial du Ministère de l’Intérieur, Sécurité,

Décentralisation et Affaires Coutumières Nationale.
Grâce au stockage des informations des agents avec l’outil
Excel, cela permet d’effectuer une analyse statistique pour
l’obtention d’un effectif fixe au niveau de la ville province de
Kinshasa.
3.4.2 Les points négatifs
Au niveau du siège provincial du ministère, il y a un manque
de matériels informatiques et de logiciels pour un traitement
rapide des informations venant de différentes cellules à des
communes distinctes.
3.5 Proposition de la Solution
Nous avons proposé de mettre en place une base des données
reparties en utilisant les réplications des données afin de
pallier aux points négatifs que suscite le ministère. Cette fois-
ci tout deviendra automatique.
CHAPITRE 4. MODÉLISATION ET IMPLEMENTATION DU

SYSTÈME
Donc ce chapitre, nous verrons la conception et la réalisation
de notre application.
4.1 Modélisation
La modélisation est une phase de conception,
permettant d’élaborer un ou plusieurs modèles qui nous
P a g e | 63
permet d’avoir l’aperçu réel du système et comprendre son

but et son fonctionnement ; on a décidé d’utiliser Le langage
UML.
4.1.1 Modélisation du Système
4.1.1.1 Spécification initiale du Système
Compte tenu de ce que nous avons présenté dans
les précédents chapitres, nous arrivons au stade ou tout doit
être implémenté en suivant les attentes de notre sujet : d’où
la première étape, est d’avoir une idée sur l’implémentation
du système qui nous permettra enfin d’élaborer des différents
concepts du système à mettre place. Pour y arriver, les points
évoques ci-dessous, nous sont d’une grande importance pour
arriver à la concrétisation de notre première étape du projet.
4.1.1.2 Idée du projet
Dans le souci de faciliter l’identification, le payement
des agents et pour permettre au service d’améliorer leur
travail et le suivi des agents en temps opportun ainsi que le
stockage efficace des informations, nous sommes tenu de
développer une application qui permettra au gestionnaire
d’enregistrer toutes les informations sur l’identification des
agents, d’interroger la base de données quand il s’agit d’une
recherche et de disponibilité des informations provenant des
différents sites.
4.1.1.3 Imagination d’un Concept du Projet

La plupart des idées de nouveaux systèmes
informatiques sont souvent basés sur les extensions d’idées
existants malgré cette astuce, ils arrivent au final d’apporter
d’autres nouvelles fonctionnalités. D’où pour arriver à faire
surgir ces nouvelles fonctionnalités, nous faisons appel aux
concepts suivants :
P a g e | 64
- Nouvelles fonctionnalités
Le Ministère de l’Intérieur, Sécurité, Décentralisation et
Affaires Coutumières Nationale aura une base des données
reparties pour le stockage des informations de son personnel
et d’une application pour l’identification de ses agents.
- Restructuration
Le Ministère de l’Intérieur, sécurité, Décentralisation et
Affaires Coutumières Nationale va se munir d’un logiciel
pour la gestion d’identification de ses agents .
- Facilité
Le système va faciliter la communication entre le Secrétariat
Général du Ministère et le Cabinet du Ministre.
- Automatisation
Le point à automatiser est celui de l’identification de son
personnel.
4.1.1.4 Elaboration du Concept
- A qui l’application est-elle destinée ?
Cette application est destinée au personnel du
ministère de l’intérieur et sécurité nationale dans le but
d’identifier ses agents de la ville de Kinshasa dans n’importe
quel lieu.
- Quels problèmes l’application résoudra-t-elle ?

C’est application qui sera reçue à la fois par les
dirigeants du ministère de l’intérieur et sécurité nationale et
au service de gestion du personnel, permettra de gagner
beaucoup plus de temps lors qu’il s’agit de rechercher une
information concernant l’identité de l’agent, de disposer en
temps réel toutes les informations sur les agents ayant été
enregistrés au sein du ministère de l’intérieur et sécurité
P a g e | 65
nationale, cela permettra à l’administration de décider sur

l’effectif général des agents de la ville en temps opportun.
- Ou l’application sera-t-elle utilisée ?
Cette application peut être utilisée par n’importe
quelle entreprise souhaitant gagner du temps et sécuriser ses
informations. Dans le cas précis, elle est conçue pour être
utilisé au ministère de l’intérieur et sécurité nationale pour
l’identification de son personnel.
- Quand l’Application est-elle-attendue ?
Nous tenons à signaler ici que cette application est
réalisée dans le cadre d’un travail de fin d’étude. Nous
n’avons donc aucune contrainte de la part des autorités du
ministère de l’intérieur et sécurité nationale sur sa mise en
œuvre. Et si tel était le cas, cela ferait l’objet d’un contrat
entre nous et le ministère de l’intérieur et sécurité nationale,
ce contrat pourra se servir du cadrage du projet. En bref, il
n’y a donc pas une date pour la livraison du produit.
- Comment l’Application Fonctionnera-t-elle ?

Notre application est basée sur une architecture à trois
niveaux : l’interface utilisateur, la programmation et la base
de données.
4.1.1.5 Analyse du Domaine

L’analyse du domaine a pour objectif un modèle
précis, concis, compréhensible et correct du monde réel.
Avant de construire quoi que ce soit de complexe, celui qui le
construit doit comprendre les besoins. Lors de l’analyse, nous
construisons des modèles et nous commençons à
comprendre plus clairement les exigences.
- Le Dictionnaire des Données
P a g e | 66
Le dictionnaire des données permet de structurer les entités

et leurs propriétés qui sont utilisées à la suite de notre
modélisation :
Tableau 10 : le dictionnaire des données
Au vu tout ce qui précède c’est-à-dire l’énoncé, nous allons

présenter des modèles du langage UML Nous permettant de
comprendre le fonctionnement statique et dynamique de
notre système :
- Le Diagramme de Classe
Ce modèle de diagramme illustre la représentation statique
de notre système.
P a g e | 67
Figure 11 : diagramme de classe
- Le Diagramme de Cas d’Utilisation

Ce modèle de diagramme illustre la représentation
dynamique de notre système.
A. Phase d’enrôlement
P a g e | 68
Figure 12 : diagramme de cas d’utilisation A

B. Phase d’identification
Figure 13 : diagramme de cas d’utilisation B

4.2 IMPLEMENTATION DE L’APPLICATION
4.2.1 Outils utilisés
Nous avons utilisé :
- Java standard 8
P a g e | 69
Qui est un langage de programmation orienté objet, nous a

permis de mettre en place notre application dans
l’environnement Netbeans 7.
- Sybase
Qui est un logiciel de modélisation open source, nous a
permis de dessiner nos modèles lors de la conception de
notre système.
- SQL Server 2008 R2
Qui est un système de gestion des bases de données
reparties, nous a permis de mettre en place notre base de
données reparties et d’effectuer les réplications.
4.2.2 Scripts de création de la base des données
USE [master]
GO
CREATE DATABASE [AGENT MIS] ON PRIMARY

( NAME = N'CHOMEURS', FILENAME = N'C:\Program Files\
Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\
DATA\ AGENT MIS.mdf' , SIZE = 3072KB , MAXSIZE =
UNLIMITED, FILEGROWTH = 1024KB )
LOG ON
( NAME = N' AGENT MIS _log', FILENAME = N'C:\Program
Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\
MSSQL\DATA\ AGENT MIS _log.ldf' , SIZE = 1024KB ,
MAXSIZE = 2048GB , FILEGROWTH = 10%)
GO
ALTER DATABASE [AGENT MIS] SET

COMPATIBILITY_LEVEL = 100
GO
IF (1 = FULLTEXTSERVICEPROPERTY('IsFullTextInstalled'))
begin
EXEC [AGENT MIS].[dbo].[sp_fulltext_database] @action =
'enable'
end
GO
P a g e | 70
ALTER DATABASE [AGENT MIS] SET ANSI_NULL_DEFAULT

OFF
GO
ALTER DATABASE [AGENT MIS] SET ANSI_NULLS OFF

GO
ALTER DATABASE [AGENT MIS] SET ANSI_PADDING OFF

GO
ALTER DATABASE [AGENT MIS] SET ANSI_WARNINGS OFF

GO
ALTER DATABASE [AGENT MIS] SET ARITHABORT OFF

GO
ALTER DATABASE [AGENT MIS] SET AUTO_CLOSE OFF

GO
ALTER DATABASE [AGENT MIS SET

AUTO_CREATE_STATISTICS ON
GO
ALTER DATABASE [AGENT MIS] SET AUTO_SHRINK OFF

GO

AUTO_UPDATE_STATISTICS ON
GO
ALTER DATABASE [AGENT MIS SET

CURSOR_CLOSE_ON_COMMIT OFF
GO
ALTER DATABASE [AGENT MIS] SET CURSOR_DEFAULT

GLOBAL
GO

CONCAT_NULL_YIELDS_NULL OFF
GO
P a g e | 71

NUMERIC_ROUNDABORT OFF
GO
ALTER DATABASE [AGENT MIS] SET QUOTED_IDENTIFIER

OFF
GO

RECURSIVE_TRIGGERS OFF
GO
ALTER DATABASE [AGENT MIS] SET DISABLE_BROKER

GO

AUTO_UPDATE_STATISTICS_ASYNC OFF
GO

DATE_CORRELATION_OPTIMIZATION OFF
GO
ALTER DATABASE [AGENT MIS] SET TRUSTWORTHY OFF

GO

ALLOW_SNAPSHOT_ISOLATION OFF
GO
ALTER DATABASE [AGENT MIS] SET PARAMETERIZATION

SIMPLE
GO

READ_COMMITTED_SNAPSHOT OFF
GO

HONOR_BROKER_PRIORITY OFF
GO
P a g e | 72
ALTER DATABASE [AGENT MIS] SET READ_WRITE

GO
ALTER DATABASE [AGENT MIS] SET RECOVERY FULL

GO
ALTER DATABASE [AGENT MIS] SET MULTI_USER

GO
ALTER DATABASE [AGENT MIS] SET PAGE_VERIFY

CHECKSUM
GO
ALTER DATABASE [AGENT MIS] SET DB_CHAINING OFF

GO
4.2.3 Les Publications

Pour se faire, nous avons parmi les quatre types de
publication présents dans SQL Server 2008 R2, choisi le
mode de publication de fusion pour lequel 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 le cliché instantané initial des données à publier.
P a g e | 73
Figure 16 : Création de la publication

P a g e | 74
Figure 17 : Choix des Types de Publication
Figure 18 : Finalisation de la Publication
4.2.4 Les Interfaces Graphiques
Cette première interface permet à l’administrateur de

s’authentifier avant d’accéder à son interface de travail.
P a g e | 75
Figure 19 : interface graphique de l’authentification

admin.
 Interface graphique de l’dentification agent

P a g e | 76
Cette interface permet d’identifier tous les agents du

ministère
Figure 20 : Interface graphique de l’identification agent

- Extrait des codes sources pour les interfaces
Package login ;
Import main.Acceuil;
import javax.swing.JFrame;
public class Login extends javax.swing.JFrame
{
public Login () {
initComponents ();
}
@SuppressWarnings("unchecked")
// <editor-fold defaultstate="collapsed" desc="Generated
Code">
P a g e | 77
private void initComponents () {
jFormattedTextField1 = new
javax.swing.JFormattedTextField();
jPanel1 = new javax.swing.JPanel();
jLabel2 = new javax.swing.JLabel();
jTextField1 = new javax.swing.JTextField();
jFormattedTextField2 = new
javax.swing.JFormattedTextField();
jButton1 = new javax.swing.JButton();
jFormattedTextField1.setText("jFormattedTextField1");
setDefaultCloseOperation(javax.
swing.WindowConstants.EXIT_ON_CLOSE);
set Background (new java.awt.Color(255, 255, 255));
jPanel1.setBackground(new java.awt.Color(255, 255,

255));
jPanel1.setLayout(new
org.netbeans.lib.awtextra.AbsoluteLayout());
jLabel2.setIcon(new
javax.swing.ImageIcon(getClass().getResource("/images/sans-
titre__.png"))); // NOI18N
P a g e | 78
jPanel1.add(jLabel2, new
org.netbeans.lib.awtextra.AbsoluteConstraints(20, 40, 270,
270));
jTextField1.addActionListener(new
java.awt.event.ActionListener() {
public void
actionPerformed(java.awt.event.ActionEvent evt) {
jTextField1ActionPerformed(evt);
}
});
jPanel1.add(jTextField1, new
30));
jPanel1.add(jFormattedTextField2, new
30));
jButton1.setBackground(new java.awt.Color(0, 0, 0));

jButton1.setForeground(new java.awt.Color(255, 255,
255));
jButton1.setText("LOGIN");
jPanel1.add(jButton1, new
-1));
jLabel1.setFont(new java.awt.Font("Maiandra GD", 1,

12)); // NOI18N
jLabel1.setText("USER");
P a g e | 79
org.netbeans.lib.awtextra.AbsoluteConstraints(300, 110, -1, -
1));
14)); // NOI18N
jLabel3.setText("MOT DE PASSE");
org.netbeans.lib.awtextra.AbsoluteConstraints(270, 180, -1, -
1));
24)); // NOI18N
jLabel4.setText("AUTHENTIFICATION");
}
P a g e | 80
CONCLUSION GENERALE
Nous voici au terme de notre travail de fin d’études qui a
porté sur « LA MISE EN PLACE D’UNE BASE DE DONNEES
REPARTIES POUR L’IDENTIFICATION DES AGENTS ET CADRES
DU MINISTERE DE L’INTERIEUR, SECURITE,
DECENTRALISATION ET AFFAIRES COUTUMIERES DE LA
RDC ».
Après une recherche et une étude sérieuse, nous avons
pu proposer ce système distribué d’identification des agents et
cadres du Ministère de l’Intérieur, Sécurité, Décentralisation et
Affaires Coutumières de la République Démocratique du Congo.
Un meilleur moyen moderne d’indentification des agents dans
une institution tant privé que publique. Cette solution pourra
aussi être utile dans plusieurs autres domaines tels que : la
Publication de la délibération des étudiants, l’identification de
chaque citoyen de la nation selon sa commune et sa province
respectives, …
Sachant que l’œuvre humaine notamment scientifique ne
manque généralement pas d’imperfections, nous restons très
ouverts face à toutes remarques et suggestions afin de la rendre
encore meilleure.
P a g e | 81
LES REFERENCES BIBLIOGRAPHIQUES

1. OUVRAGES
[1] GABILLAUD J. « SQL Server 2008, Administration d’une
base des données avec SQL Server Management studio » ;
[2] GARDARIN O. et GEORGES « Bases des
données-Objet/relationnel », Edition Eyrolles, Paris 1999 ;
[3] MATTHIEU Exbrayat., (2008-2009). « Bases de données
Réparties présentation générale » ;
[4] EDDY MEYLAN, Réplication de données. Bachelot of
science en informatique de gestion, Haute Ecole de Gestion
ARC Neuchâtel, 2005 ;
2. NOTES DE COURS
[8] MBUYI MUKENDI Eugène, Base de données, G3
informatique Université de Kinshasa ;
[9] MBUYI MUKENDI Eugène, Base de données reparties,
L1 informatique, université de Kinshasa ;
[10] NTUMBA BADIBANGA Siméon, Système d’objets
reparties, L1 génie-informatique, université de Kinshasa ;
[11] KASORO Nathanaël, Programmation orienté objet, G3
informatique Université de Kinshasa ;
[12] KASENGEDIA MOTUMBE Pierre, Réseaux des
télécommunications, L2 génie-informatique Université de
Kinshasa ;
3. MEMOIRES
[13] CHRISTELLE PIERKOT, « Gestion de la mise à jour de
données géographiquement répliquées », Université de
Touloise ;
[14] ALEX MULUMBA KANDE, « Implémentation de SOA dans
un système urbanisé en vue d’améliorer le système de
communication d’une plateforme éducationnelle » Université de
Kinshasa 2017 ;
P a g e | 82
[15] OLINE ADUBO GEMENA, « mise en place d’une base de

données reparties pour la gestion des mariages civils un
module de la publication web » Université de Kinshasa
2019-2020 ;
4. ARTICLES SCIENTIFIQUES
[16] A. LUNA-ALMEIDA, JP. BRIOT, J. MAL ENFANT, S.
AKNINE, « Méthode de réplication basée sur les plans pour la
to systèmes multi-agents », Edition Université de Paris 8 ;
[17] LAMBERT SONNA MOMO, « Réplication et durabilité
dans les systèmes reparties », Edition, Février 2001 ;
5.SITES INTERNET
[18] .https.interieur.gouv.cd/, consulté le 17 Janvier 2022.
P a g e | 83
TABLE DES MATIERES
I.0. Présentations............................................................................. 12
I.1. Système distribué......................................................................12
I.1.1. Définition................................................................................ 13
I.1.2. Caractéristiques et objectifs....................................................13
 La grande échelle (ou scalability : en anglais)..................................14
I.1.3. Système centralisé vers système distribué...............................14
 Conception d’un système distribué................................................15
I.1.4. Propriétés d’un système distribué............................................16
a) La transparence................................................................16
b) La disponibilité............................................................................17
c) L’autonomie.................................................................................18
 Les Intergiciels : Middlewares........................................................19
- Couches dans le Client.................................................................22
Types de client serveur................................................................22
I.2. BASE DE DONNEES REPARTIE.................................................24
I.2.1. Définition................................................................................ 24
I.2.2. Caractéristiques......................................................................26
I.2.3. Importance d’une base de donnés répartie...............................27
I.2.4. Objectif d’une base de données répartie...................................27
1. L’autonomie locale........................................................................27
2. Transparence vis-à-vis de la localisation des données....................28
4. Transparence vis-à-vis de la duplication de données......................28
6. Egalité des sites...........................................................................29
I.2.5. Systèmes de Gestion de Base de Données (SGBD)...................29
a) Système de Gestion de Base de Données......................................29
P a g e | 84
SGBDR ou SGBDD..........................................................................29
I.2.6. Conception de base de données répartie..................................30
I.2.6.1. Conception ascendante........................................................30
I.2.6.2. Conception Descendante......................................................31
I.2.7. Principe d’une base de données répartie..................................31
1. Transparence de Localisation........................................................32
3. Transparence d’allocation.............................................................32
4. Transparence Conceptuelle Locale.................................................32
I.2.9. Technique de fragmentation................................................34
I.2.9.1. Définition............................................................................. 34
I.2.9.2. Types de fragmentation........................................................34
Commande Tableau 2 : Exemple d'illustration d'une fragmentation
verticale........................................................................................... 37
I.2.10. Schéma d’allocation..............................................................38
II.0. INTRODUCTION.......................................................................40
II.1. Définition.................................................................................40
II.2. Principes..................................................................................42
II.3. Types des Mises à Jour.............................................................42
1. Mise à jour Synchrone...............................................................42
 Avantages.....................................................................................43
 Désavantages................................................................................43
 Avantages.....................................................................................44
 Désavantages................................................................................44
II.4. Types de Réplications................................................................44
II.4.1. Réplication symétrique...........................................................44
 Avantages.....................................................................................44
 Désavantages................................................................................44
P a g e | 85
 Avantages.....................................................................................45
 Désavantages................................................................................45
II.5. Techniques de la Réplication.....................................................45
1. Réplication asymétrique synchrone..............................................45
2. Réplication asymétrique asynchrone............................................45
3. Réplication symétrique asynchrone..............................................46
4. Réplication symétrique synchrone................................................46
II.6. Avantages et inconvénients de la réplication de base de données
....................................................................................................... 47
II.7. Réplication sous Microsoft SQL Server......................................48
II.7.1. Entités présentes dans une réplication...................................48
1) Un éditeur.................................................................................... 49
2) Le distributeur.............................................................................. 49
3) Les abonnés................................................................................. 49
 Un article....................................................................................50
 Une publication...........................................................................50
II.7.3. Mode de réplication sous SQL Server......................................52
II.7.3.1. Réplication de Capture Instantanée.....................................52
II.7.3.2. Réplication Transactionnelle...............................................53
II.7.3.3. Réplication de Fusion..........................................................53
II.8. Transaction Dans la Base de Données Répartie.........................54
a. Définition d’une transaction.........................................................54
II.8.1. Propriétés d’une transaction (ACID)........................................55
II.8.2. Validation en deux phases.....................................................56
II.8.3. Classification des transactions...............................................57

Jo Lida Memoire 2

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Jo Lida Memoire 2

Transféré par

Droits d'auteur :

Formats disponibles

i

« La complexité de données est la raison majeure de la

Au Dieu Très Haut, Créateur du ciel et de la terre, pour le

A ma très chère mère NSIMBA KATUZA Jackie pour son

A toute ma famille, en commençant par mes frères et

A tous les miens : Guy MUNGWELE, FRANCOIS NGAYAM, Dosite

Je tiens à saisir cette belle opportunité pour adresser

accordé sa grâce et m'a donné la force et l’intelligence d'accomplir

Mes remerciements vont à ceux qui m'ont encouragée et

Je tiens aussi à présenter l’expression de ma

Je voudrais associer à ces remerciements ma famille

Liste des abréviations

API : Application Programming Interface

Liste des Figures

Figure 1 : De centralisé vers distribué

Liste des Tableaux

Tableau 3 : Montrant l'exemple d'illustration de la fragmentation horizontale

De nos jours, nous constatons de plus en plus la

Nous avons constaté qu’en République Démocratique du

Parmi les institutions en cours d’informatisation et ayant

 Manque de contrôle d’effectifs pour une bonne politique de

En partant des constats ci-haut énumérés, nous avons choisi

4. Méthodes et techniques utilisées :

CHAPITRE I. GENERALITES SUR LE SYSTEME DISTRIBUE ET

I.0. Contexte du sujet

I.1. Système distribué

De ce fait, il n’y a donc aucune différence entre système

« Un système réparti est un ensemble d’ordinateurs (ou

Aussi, en résumé, dans un système distribué, les

Cette notion d’image unique du système, fragilise un peu

I.1.2. Caractéristiques et objectifs d’un système distribué

Toutes les ressources tant hardware (ordinateurs,

C ‘est la capacité qu’un système continue de fonctionner

I.1.3. Système centralisé et système distribué

Les systèmes distribués sont plus vulnérables que les

De par les avantages et objectifs du système distribué, on

Figure 1 : De centralisé vers distribué

 Conception d’un système distribué

Elle peut se réaliser sur :

 Machine multiprocesseurs avec mémoire partagée ;

 Cluster (grappe) d’ordinateurs dédié au calcul/traitement

 Ordinateurs standards connectés en réseau.

I.1.4. Propriétés d’un système distribué

Les défis sont ici présentés comme des propriétés que

- Accès : il n’y a pas d’accès spécifique pour des ressources ;

- Concurrence : l’utilisateur du système ne doit pas savoir

- Extension (des ressources) : s’il faut étendre ou réduire le

- Localisation : il n’est nullement besoin de savoir

- Tolérance aux pannes : lorsqu’il y a panne (réseaux,

- Réplication : l’utilisateur du système n’a pas besoin de

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

Il existe beaucoup de causes à l’origine de l’indisponibilité d’un

- Des surcharges dues à des sollicitations excessives d’une

que les pannes ou toute autre tentative (citées ci-haut) va

Voici donc la bonne motivation parmi tant d’autres de

L’autonomie des composants d’un système favorise par

Pour compléter à l’autonomie d’un système, on peut aussi

informatiques, des protocoles réseau, des systèmes d'exploitation

Les techniques les plus courantes d'échange d'informations

Figure 2 : Système distribué avec un intergiciel

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

- Web Services (XML-RPC: Extensible Markup Language

Le concept client-serveur, c’est pour définir une

Figure 3 : Architecture client-serveur