Vous êtes sur la page 1sur 40

Développement d’applications distribuées

Partie I : GENERALITE

I) Introduction

Vue l'augmentation de leurs ressources, les entreprises multi-sites doivent pouvoir compter
sur une infrastructure informatique hautes performances, à même d'assurer l'exécution
transparente de leurs processus informatiques et une communication fiable, en interne (entre
les différents sites) comme en externe (avec les partenaires et clients). Cela exige une
surveillance continue de la disponibilité des ressources et de l'utilisation de la bande passante
des réseaux localement distribués.

Les systèmes distribués proposent des solutions d'améliorer l'agilité globale du système
d'information au travers des architectures orientées services (SOA). Ces systèmes permettent
aussi de mettre en place des architectures informatiques permettant d'améliorer les
performances ainsi que la disponibilité des systèmes informatiques.

I.1) Notion Applications distribuées

I.2) RMI
I.3. Autres Définitions

Un système distribué (applications distribuées) est un système disposant d'un ensemble


d'entités communicantes, installées sur une architecture d'ordinateurs indépendants reliés
par un réseau de communication, dans le but de résoudre en coopération une fonctionnalité
applicative commune.

Autrement dit, un système distribué est défini comme étant un ensemble des ressources
physiques et logiques géographiquement dispersées et reliées par un réseau de
communication dans le but de réaliser une tâche commune. Cet ensemble donne aux
utilisateurs une vue unique des données du point de vue logique.

Un système distribué est un ensemble d'entités autonomes de calcul (ordinateurs, PDA,


processeurs, processus, processus léger etc.) interconnectées et qui peuvent communiquer.
Représentation d'un Système distribué

II) Intérêt des systèmes distribués

Les systèmes distribués ont plusieurs raisons de leur existence.


· Partage des ressources (données, programme, services) qui permet un travail collaboratif ;
· Accès distant, c'est-à-dire qu'un même service peut être utilisé par plusieurs acteurs situés à
des endroits différents ;
· Amélioration des performances : la mise en commun de plusieurs unités de calcul permet
d'effectuer des calculs parallélisables en des temps plus courts ;
· Confidentialité : les données brutes ne sont pas disponibles partout au même moment,
seules certaines vues sont exportées ;
· Disponibilité des données en raison de l'existence de plusieurs copies ;
· Maintien d'une vision unique de la base de données malgré la distribution ;
· Réalisation des systèmes à grande capacité d'évolution ;
· Augmentation de la fiabilité grâce à la duplication de machines ou de données, ce qui induit
à une réalisation des systèmes à haute disponibilité.

III) Quelques domaines d'application des systèmes distribués

Les systèmes distribués sont rencontrés dans notre vie quotidienne :

· La gestion intégrée des informations d'une entreprise (guichet de banque, agence de


voyage,..) ;
· Internet : l'internet, aujourd'hui, constitue un grand exemple d'un système distribué le plus
large au monde contenant de nombreux sous-systèmes selon le protocole considéré.
Exemple : Web (http), bittorrent (peer-to-peer). Des nombreux utilisateurs partout dans le
monde peuvent utiliser des services offerts par l'internet comme le WWW, le FTP (File
Transfert Protocol) et tant d'autres applications. On remarque ici une collection deréseaux
d'ordinateurs interconnectés. Et les programmes s'y exécutant interagissent grâce aux
échanges de messages en utilisant un moyen de communication ou un autre ;

· Le WWW représente un système distribué logique consistant en un nombre considérable de


ressources (pages web, fichiers de données et services) référencées par des URL (Uniform
Ressource Locator) ;

· Les téléphones portables ;

· Le contrôle et organisation d'activités en temps réel (télévision interactive)

IV) Difficulté de mise en œuvre

La mise en œuvre des systèmes distribués engendre un certain nombre de difficultés dont
voici quelques-unes :

· Gestion de l'hétérogénéité et Cohérence des données

Lors de la mise en place d'un système distribué, il est nécessaire que l'ensemble des
composants travaillent avec des données cohérentes. Cette cohérence des données est
d'autant plus problématique lorsque l'on commence à redonder certains composants pour
augmenter la capacité de traitement et/ou la disponibilité du système.

En effet, les données comme le cache applicatif, le contenu d'une base de données ou bien
les variables de session des utilisateurs Web doivent être synchronisées entre les différentes
instances d'un composant afin d'assurer une cohérence dans les traitements réalisés.

· Gestion des composants

Un système distribué étant composé d'un ensemble de composants logiciels répartis sur
plusieurs serveurs physiques. Il est nécessaire pour assurer la maintenance corrective et
évolutive du système de dresser une cartographie complète de ce système.

· Disponibilité et détection d'arrêts

Dans un système distribué, l'indisponibilité d'un seul composant du système (serveur, base de
données, ...) peut rendre indisponible le système complet. On mesure alors la disponibilité de
ce type de système à celle de son maillon le plus faible.

Pour couvrir ce risque, il est nécessaire de mettre en place en amont une architecture
permettant d'assurer la disponibilité cible pour tous les composants. Une fois que cette
architecture est en production, des opérateurs doivent à l'aide de logiciels s'assurer de la
détection au plus tôt d'une défaillance de l'un des composants de l'architecture.

· Gestion de la séquentialité

La mise en place d'un cluster de type actif/actif provoque la création de deux points d'entrée
au système. Dans le cas d'un système distribué d'échange de données par exemple, il est alors
possible que deux modifications successives du même objet soient dirigées vers deux nœuds
différents du cluster, ce qui dans l'absolu peut aboutir à une situation où le message le plus
récent est diffusé en premier vers l'application destinataire.

Si aucune gestion de la séquentialité des messages n'est faite, le message le plus ancien
viendra écraser dans les applications destinataires le message le plus récent.

V) Caractéristiques des systèmes distribués

La performance d'un système distribué se révèle dans ces caractéristiques. Ces


caractéristiques ci-dessous devraient être prises en compte lors de la conception d'un système
distribué.

V.1) Interopérabilité

Dans un système distribué, il se pose un vrai problème de coopération entre différents


composants du système. En effet, ce problème peut être vu au niveau de la couche matériel
(différents réseaux physiques et plateforme matérielle), de la couche système d'exploitation
(divers OS utilisés(UNIX, Windows, Mac OS, Solaris)), de la couche application (langages de
programmation différents) et de la couche middleware (.NET pour Microsoft, Corba pour le
Consortium OMG). On parle de l'hétérogénéité, un problème dans le partage des ressources
dans un système distribué.

L'interopérabilité est une caractéristique importante qui désigne la capacité à rendre


compatibles deux systèmes quelconques. A son tour, la compatibilité est la capacité qu'ont
deux systèmes à communiquer sans ambiguïté.

En effet, l'interopérabilité vise à réduire le vrai problème de l'hétérogénéité en la masquant


par l'utilisation d'un protocole unique de communication (exemple de TCP/IP pour l'Internet).
Pour les échanges des messages, il faut utiliser des standards qui cachent les différences entre
les différentes plateformes.

Actuellement, il existe deux approches principales de standardisation pour masquer


l'hétérogénéité : les middlewares et les machines virtuelles.

Concrètement, un middleware est représenté par des processus et des ressources d'un
ensemble d'ordinateurs, qui interagissent les uns avec les autres. Ils middlewares améliorent
la communication en offrant des abstractions telles que :

· Le RMI (Remote Method Invocation) qui est la possibilité, pour un objet, d'invoquer la
méthode d'un autre objet situé sur une plateforme distante ;
· La notification d'événement pour la propagation d'informations d'une plateforme vers une
autre ou plusieurs autres plateformes ou composants d'une application distribuée ;

· La communication entre groupe de processus ;

· La gestion de la duplication des données partagées ;

· La transmission de données multimédia en temps réel.

Les machines virtuelles permettent de supporter le code mobile désignant la possibilité de


transfert de code d'une machine source à une machine de destination et son exécution sur
cette machine. Au cas des différentes plateformes, le code produit sur l'une ne peut
fonctionner sur l'autre. Pour éviter ce problème, le code mobile est généré d'un langage
source pour une machine virtuelle donnée (exemple de la JVM). En effet, chaque plateforme
doit disposer d'une couche logicielle qui implémente la machine virtuelle car cette dernière
représente une généralisation des middlewares offrant les mêmes services.

Exemple d'un système distribué

V.2) Partage des ressources

Le partage des ressources est le facteur principal de motivation pour construire les systèmes
répartis. Des ressources telles que des imprimantes, des dossiers, des pages Web ou des
disques de base de données sont contrôlées par des serveurs du type approprié. Par exemple,
les serveurs Web contrôlent des pages Web et d'autres ressources d'enchaînement. Des
ressources sont consultées par des clients - par exemple, les clients du web des serveurs
s'appellent généralement les browsers (navigateurs) ;

V.3) Ouverture

Cette caractéristique fait mention de l'extensibilité dans la mesure où des composants


peuvent être ajoutés, remplacés ou supprimés dans un système distribué sans en affecter les
autres. Et lorsque nous parlons des composants, nous voyons les matériels (les périphériques,
mémoires, interfaces, etc.) et les logiciels (protocoles, pilote, etc.). L'ouverture nécessite que
les interfaces logicielles soient documentées et accessibles aux développeurs d'applications.

Il se pose un vrai problème avec l'ouverture au sens que les composants d'un système
distribué sont hétérogènes. Alors, cette qualité d'ouverture est accordée aux systèmes
supportant sans ambages :

a) L'ajout de l'ordinateur au niveau de la couche matérielle ;

b) L'ajout de nouveaux services au niveau application, middleware et système d'exploitation ;

c) La réimplantation des services anciens.

V.4) Expansible

Nous disons qu'un système distribué est expansible lorsque les modifications du système et
des applications ne sont pas nécessaires quant à l'augmentation de la taille de ce système.

V.5) Performance

Dans ce cas, le système doit s'adapter à bien fonctionner même quand le nombre d'utilisateurs
ou de ressources augmentent.

V.6) Transparence

« To the user, a distributed system should look exactly like a nondistributed system. »
La transparence cache aux utilisateurs l'architecture, la distribution des ressources, le
fonctionnement de l'application ou du système distribué pour apparaître comme une
application unique cohérente.

La norme ISO (1995) définit différents niveaux de transparences telle que la transparence
d'accès, de localisation, de concurrence, de réplication, de mobilité, de panne, de
performance, d'échelle).

 Transparence d'accès :il s'agit d'utiliser les mêmes opérations pour l'accès aux
ressources distantes que pour les celles locales ;
 Transparence à la localisation : l'accès aux ressources indépendamment de leur
emplacement doit être inconnue à l'utilisateur ;
 Transparence à la concurrence : il s'agit de cacherà l'utilisateur l'exécution possible de
plusieurs processus en parallèle avec l'utilisation des ressources partagées en évitant
des interférences ;
 Transparence à la réplication : la possibilité de dupliquer certains éléments/ressources
(fichiers de base de données) pour augmenter la fiabilité et améliorer les
performances doit être cachée à l'utilisateur ;
 Transparence de mobilité : il s'agit de permettre la migration des ressources et des
clients à l'intérieur d'un système sans influencer le déroulement des applications ;
 Transparence de panne : il s'agit de permettre aux applications des utilisateurs
d'achever leurs exécutions malgré les pannes qui peuvent affecter les composants
d'un système (composants physiques ou logiques) ;
 Transparence à la modification de l'échelle : il s'agit de la possibilité d'une extension
importante d'un système sans influence notable sur les performances des
applications.
 Transparence à la reconfiguration: il s'agit de cacher à l'utilisateur la possibilité de
reconfigurer le système pour en augmenter les performances en fonction de la
charge ;

En effet, la transparence n'est pas toujours possible dans certains cas. Notons le cas de la
duplication d'une imprimante des caractéristiques différentes pour besoin des performances
dans le système. Cependant, l'utilisateur doit toutefois avoir la possibilité de spécifier
concrètement sur quelle imprimante il souhaite imprimer ses documents.

V.7) Sécurité

Le problème de sécurité se pose dans tout système informatique. Dans un système distribué,
les ressources doivent être protégées contre des utilisations abusives et malveillantes. En
particulier, le problème de piratage des données sur le réseau de communication. En ces
raisons, il est préférable d'utiliser des périphériques ou logiciels licenciés. Outre, les
connexions doivent être sécurisées par authentification avec les éléments distants ainsi que
les messages circulant sur ce réseau doivent être cryptés en vue d'éviter des conséquences
graves.

Le concept de sécurité des systèmes d'information recouvre un ensemble de méthodes,


techniques et outils chargés de protéger les ressources d'un système d'information afin
d'assurer :

· la disponibilité des services : les services (ordinateurs, réseaux, périphériques, applications...)


et les informations (données, fichiers...) doivent être accessibles aux personnes autorisées
quand elles en ont besoin ;

· la confidentialité des informations : les informations n'appartiennent pas à tout le monde ;


seuls peuvent y accéder ceux qui en ont le droit ;

· l'intégrité des systèmes : les services et les informations (fichiers, messages...) ne peuvent
être modifiés que par les personnes autorisées (administrateurs, propriétaires...).

V.8) Concurrence

Le problème de la concurrence permet l'accès simultané à des ressources par plusieurs


processus. Ce problème se pose pour les systèmes distribués comme pour les systèmes
centralisés. En effet, il y a bien d'autres ressources dont l'accès simultané n'est pas possible.
Dans ce cas, leur manipulation ne peut se faire que par un processus à la fois. Le cas des
ressources physiques telles que l'imprimante mais aussi des ressources logiques telles que les
fichiers, les tables des bases de données, etc. Dans ce cas, les applications distribuées
(reparties) actuelles autorisent l'exécution de plusieurs services en concurrence (cas de l'accès
à une base de données). Chaque demande est prise en compte par un processus simple appelé
thread ; et la gestion de la concurrence fait appel aux mécanismes de synchronisation
classiques.

V.9) Tolérance aux pannes

Une panne peut être comprise comme une faille au sein du système pouvant conduire à des
résultats erronés comme aussi engendrer l'arrêt de toute ou partie d'un système distribué.Les
pannes peuvent résulter des différentes couches et se propager éventuellement aux autres.
Peut-être, c'est une raison matérielle ou logique liée à la conception des applications, des
middlewares et des systèmes d'exploitation.

Ainsi, un système distribué doit être conçu pour masquer ce genre des pannes aux utilisateurs.
La panne de certains serveurs (ou leur réintégration dans le système après la réparation) ne
doit pas perturber l'utilisation du système en terme de fonctionnalité.

V.10) Disponibilité

Dans un système distribué, l'indisponibilité d'un seul composant du système (serveur, base de
données, ...) peut rendre indisponible le système complet alors qu'il doit rendre en
permanence des services et d'une façon correcte. On mesure alors la disponibilité de ce type
de système à celle de son maillon le plus faible.

Ces risques d'indisponibilité du système peuvent être dus :

· aux pannes empêchant le système ou à ses composants de fonctionner correctement ;


· aux surcharges dues à des sollicitations excessives d'une ressource ;
· aux attaques de sécurité pouvant causer, d'une façon ou d'une autre, des
dysfonctionnements, les incohérences et pertes de données et même l'arrêt du
système.

Pour couvrir ce risque, plusieurs solutions peuvent être envisageables :


· ·mettre en place en amont une architecture permettant d'assurer la disponibilité cible
pour tous les composants. Une fois que cette architecture est en production, des
opérateurs doivent à l'aide de logiciels s'assurer de la détection au plus tôt d'une
défaillance de l'un des composants de l'architecture.
· ·veiller à la réplication des données au sein de ce système (c'est la solution que nous
avons choisi dans le cadre de notre travail).

VI) Architecture distribuée

L'architecture d'un environnement informatique ou d'un réseau est distribuée lorsque toutes
les ressources ne se trouvent pas au même endroit ou sur la même machine. Ce concept
s'oppose à celui d'architecture centralisée dont une version est l'architecture client-serveur
que nous allons aussi voir dans cette partie.

En effet, la programmation orientée objet a permis le développement des architectures


distribuées en fournissant des bibliothèques de haut-niveau pour faire dialoguer des objets
répartis sur des machines différentes entre eux. Les objets distribués sur le réseau
communiquent par messages en s'appuyant sur l'une des technologies telles que CORBA, RMI,
les services web XML, .Net Remoting, Windows Communication Foundatation, etc.

Les architectures distribuées reposent sur la possibilité d'utiliser des objets qui s'exécutent sur
des machines réparties sur le réseau et communiquent par messages au travers du réseau.

VI.1) Avantages des architectures distribuées

· Augmentation des ressources : la distribution des traitements sur les ordinateurs d'un réseau
augmente les ressources disponibles;

· Répartition des données et des services : (cas de l'architecture 3-tiers à la base de la plupart
des applications distribuées de commerce électronique permettant d'interroger et de mettre
à jour des sources de données réparties) ;

VI.2) Types d'architecture distribuée

 Architecture client-serveur

Le client server est avant tout un mode de dialogue entre deux processus. Le premier appelé
client, demande l'exécution de services au second appelé serveur. Le serveur accomplit les
services et envoi en retour des réponses. En général, un serveur est capable de traiter les
requêtes de plusieurs clients. Un serveur permet donc de partager des ressources entre
plusieurs clients qui s'adressent à lui par des requêtes envoyées sous forme de messages.

Par extension, le client désigne également l'ordinateur sur lequel est exécuté le logiciel client,
et le serveur, l'ordinateur sur lequel est exécuté le logiciel serveur.
Le client serveur étant un mode de dialogue, il peut être utilisé pour réaliser de multiples
fonctions.

Mode client-serveur

Parlant de l'architecture client-serveur, nous distinguons trois types d'acteurs principaux:

1) Client

Un client est un processus demandant l'exécution d'une opération à un autre processus


(fournisseur des services) par l'envoi d'un message contenant le descriptif de l'opération à
exécuter et attendant la réponse à cette opération par un message en retour.

Caractéristiques d'un client :

· Il est actif le premier (ou maître) ;

· Il envoie des requêtes au serveur ;

· Il attend et reçoit les réponses du serveur.

Parlant aussi de client, nous en distinguons trois types :

 Client léger : est une application accessible via une interface web consultable à l'aide
d'un navigateur web.
 Client lourd : est une application cliente graphique exécuté sur le système
d'exploitation de l'utilisateur possédant les capacités de traitement évoluées.
 Client riche : est une combinaison du client léger et client lourd dans lequel l'interface
graphique est décrite avec une grammaire basée sur la syntaxe XML.

2) Serveur

On appelle serveur un processus accomplissant une opération sur demande d'un client et lui
transmettant le résultat. Il est la partie de l'application qui offre un service, il reste à l'écoute
des requêtes du client et répond au service demandé par lui.

En effet, un serveur est généralement capable de servir plusieurs clients simultanément.


Caractéristiques d'un serveur :

· Il est initialement passif (ou esclave, en attente d'une requête) ;

· Il est à l'écoute, prêt à répondre aux requêtes envoyées par des clients ;

· Dès qu'une requête lui parvient, il la traite et envoie une réponse.

Nous distinguons plusieurs types de serveur en fonction des services rendus : Serveur
d'application, serveur de base de données, serveur des fichiers, etc.

3) Middleware

Le middleware est l'ensemble des services logiciels qui assurent l'intermédiaire entre les
applications et le transport de données dans le réseau afin de permettre les échanges des
requêtes et des réponses entre client et serveur de manière transparente.

Le client serveur étant un mode de dialogue, il peut être utilisé pour réaliser de multiples
fonctions. Il existe donc différents types de client-serveur qui ont été définis : le client serveur
de présentation, le client serveur de données et le client serveur de procédures.

VI.3) Architecture pair-à-pair (peer-to-peer ou P2P)

Le pair-à-pair est un modèle de réseau informatique proche du modèle client-serveur mais où


chaque ordinateur connecté au réseau est susceptible de jouer tour à tour le rôle de client et
celui de serveur.

P2P est une architecture pouvant être centralisée (les connexions passant par un serveur
central intermédiaire) ou décentralisée (les connexions se faisant directement). Le pair-à-pair
peut servir au partage de fichiers en pair à pair, au calcul distribué ou à la communication
entre noeuds ayant la même responsabilité dans le système.

La particularité des architectures pair-à-pair réside dans le fait que les données peuvent être
transférées directement entre deux postes connectés au réseau, sans transiter par un serveur
central. Cela permet ainsi à chaque ordinateur d'être à la fois serveur de données et client des
autres. On appelle souvent noeud les postes connectés par un protocole réseau pair-à-pair.

Outre, les systèmes de partage de fichiers pair-à-pair permettent de rendre les ressources
d'autant disponibles qu'elles sont populaires, et donc répliquées sur un grand nombre de
noeuds. Cela permet alors de diminuer la charge (en nombre de requêtes) imposée aux
noeuds partageant les fichiers dans le réseau. C'est ce qu'on appelle le passage à l'échelle.
Cette architecture permet donc de faciliter le partage des ressources. Elle rend aussi la censure
ou les attaques légales ou pirates plus difficiles.
architecture pair-à-pair
PARTIE II LES BASE DE DONNEES DISTRIBUEE

I) Présentation

L'évolution technologique actuelle depuis quelques décennies permet d'adapter les outils
informatiques à l'ensemble d'activités au sein des entreprises du point de vue organisationnel.

La puissance des micro-ordinateurs et la croissance des stations de travail, la fiabilité et la


souplesse des systèmes informatiques répartis et de leurs architectures, les performances des
réseaux permettent d'envisager une répartition des ressources informatiques tout en
préservant l'intégrité et la cohérence des bases de données.

En effet, les bases de données restent totalement indispensables dans notre vie courante du
fait qu'elles sont un des moteurs fondamentaux du progrès économique des entreprises
actuelles. Aujourd'hui même, l'information stockée dans une base de données de l'entreprise
peut l'aider à une prise de décision en vue de veiller sur les objectifs.

Une base de données distribuée est un ensemble des différentes bases de données stockées
sur des sites (géographiquement distants), reliés par un réseau. La réunion de ces différentes
bases forme la base de données repartie.

II) Caractéristiques

Une base de données répartie doit répondre aux caractéristiques suivantes :

 La distribution de données : les données n'appartiennent pas à un seul processus ;


 La corrélation logique des données: les données possèdent les propriétés qui les
tiennent ensemble ;
 Une structure de contrôle hiérarchique basée sur un administrateur des bases de
données globales qui est le responsable central sur les bases de données réparties
entières et sur les administrateurs des bases de données locales, qui ont la
responsabilité de leur base de données respective ;
 L'indépendance des données et la transparence de répartition.
 La redondance des données, une grande caractéristique permettant l'accroissement
de l'autonomie des applications et la disponibilité des informations en cas de panne
d'un site ;
 Un plan d'accès réparti écrit soit par le programmeur ou produit automatiquement par
un optimiseur ;

III) Types de bases de données réparties

Des bases de données réparties peuvent être largement classifiées dans les environnements
homogènes et hétérogènes de base de données répartie, chacun avec d'autres subdivisions,
comme montré dans l'illustration suivante.

Types de base de données répartie

III.1. Base de données répartie homogène

Dans une base de données répartie homogène, tous les sites utilisent le système de gestion
de bases de données identique et les systèmes d'exploitation .Ses propriétés sont :

· Les sites utilisent les mêmes logiciels ;

· Les sites utilisent le même SGBD;

· Chaque site se rend compte de tous autres et coopère entre eux pour traiter des requêtes
d'utilisateur ;
· L'accès à la base de données se fait par une interface simple comme si c'est une seule base
de données.

Types de base de données répartie homogène

Il y a deux types de ces bases de données

a) Autonome : chaque base de données est indépendante que des fonctions. Elles sont
intégrées par une application de contrôle et utilisent le message passant pour le partage des
mises à jour de données.

b) Non autonome : des données sont distribuées à travers les noeuds homogènes et un
système de gestion de bases de données central ou maître coordonne des mises à jour de
données à travers les sites.

III.2. Base de données hétérogène

Dans une base de données répartie hétérogène, les différents sites ont différents systèmes
d'exploitation, différents systèmes de gestion de bases de données et différents modèles de
données.Ses propriétés sont :

a) Les différents sites utilisent les schémas et le logiciel différents ;

b) Le système peut se composer de variété de SGBD répartis, relationnel, réseau, hiérarchique


ou orienté objet ;

c) Le traitement de requêtes est complexe dû aux schémas différents ;

d) Le traitement transactionnel est complexe dû au logiciel différent ;

e) Une coopération limitée dans le traitement de requêtes de clients due aux transparences
des sites.

Types de base de données répartie hétérogène

· Fédérée : Les systèmes de base de données hétérogène sont indépendants en nature et sont
intégrés ensemble de sorte qu'ils fonctionnent comme système simple de base de données.

· Non fédérée : Les systèmes de base de données utilisent un module central coordonné par
lequel les bases de données sont consultées.

IV) Conception d'une base de données

Une base de données répartie doit être gérée par plusieurs processeurs ou SGBD. Elle est aussi
donc stockée sur différents ordinateurs situés dans un même endroit ou étant dispersées sur
un réseau d'ordinateurs interconnectés. Chaque ordinateur de ce réseau constitue un noeud.
La question importante consiste à savoir comment ces noeuds vont interagir et communiquer
entre eux.
En effet, la mise en place d'une base de données répartie se résume par la conception du
schéma global, la conception de la base de données physique locale dans chaque site, la
conception de la fragmentation ainsi que la conception de l'allocation des fragments.

IV.1. Conception du schéma global

Le schéma global se subdivise en trois schémas dont :

 Schéma Interne

Ce schéma décrit l'accès physique aux occurrences des relations, il est constitué de l'ensemble
des descriptions des fichiers et/ou par un ensemble des schémas de relations internes.

 Schéma conceptuel

C'est l'ensemble des schémas des relations de base et l'ensemble des contraintes d'intégrités,
c'est la vue globale de la base de données. Le schéma conceptuel est composé de relations
fragmentées ou d'une relation composée d'une ou de plusieurs sous-relations, la distinction
de deux approches dans sa mise en oeuvre.

 Schéma externe

Le schéma conceptuel est un sous-ensemble du schéma conceptuel composé de l'ensemble


des schémas de relations abstraites définies sur la relation de base du schéma conceptuel.

IV.2. Conception de la base de données physique locale dans chaque site

Nous distinguons deux façons de concevoir une base de données répartie dont la conception
ascendante et la conception descendante.

IV.2.1. Conception ascendante (bottom up design)

L'approche se base sur le fait que la répartition est déjà faite, mais il faut réussir à intégrer les
différentes bases des données locales existantes en un seul schéma global. En d'autres termes,
les schémas conceptuels locaux existent et il faut réussir à les unifier dans un schéma
conceptuel global.
Représentation de la conception ascendante

Cette démarche s'avère la plus difficile puisqu'en plus des problèmes techniques identiques à
ceux inhérent à une conception descendante, il faudra résoudre des problèmes
d'hétérogénéité du système ou même de la sémantique de l'information.

IV.2.2. Conception descendante (top down design)

La conception descendante se fait par la définition d'un schéma conceptuel global de la base
de données répartie. Ensuite, on distribue sur les différents sites en des schémas conceptuels
locaux.

L'approche top down est intéressante parce que l'on part du néant en définissant un schéma
global qu'on subdivisera en différentes bases locales. Si les bases des données existent déjà la
méthode bottom up design est utilisée.
Représentation de la conception descendante

Outre, il faut ensuite définir la répartition des données qui s'effectue en trois étapes dont la
partition ou la fragmentation, la réplication et l'hybride.

La répartition se fait donc en deux étapes : la première étant la fragmentation, et la deuxième,


l'allocation de ces fragments aux sites.

IV.3. Conception de la fragmentation

IV.3.1. Fragmentation

La fragmentation est la tâche de diviser une table en ensemble de plus petites tables. Cette
division doit se faire sans perte d'informations. Les sous-ensembles de la table s'appellent les
fragments.La fragmentation peut être de trois types :horizontal, vertical, et hybride
(combinaison d'horizontal et de vertical).

 Avantages de la fragmentation

· Puisque des données sont stockées près du site de l'utilisation, l'efficacité du système de
base de données est augmentée ;

· Les techniques locales d'optimisation de requêtes sont suffisantes pour la plupart des
requêtes puisque les données sont localement disponibles ;

· Puisque les données non pertinentes ne sont pas disponibles aux sites, la sécurité et l'intimité
du système de base de données peuvent être maintenues.

 Limites de la fragmentation

· Lorsque l'on a besoindes données de différents fragments, les vitesses d'accès peuvent être
très hautes ;

· En cas de fragmentations récursifs, le travail de la reconstruction aura besoin de techniques


chères ;

· Le manque de copies de secours des données dans différents emplacements peut rendre la
base de données inefficace en cas d'échec d'un emplacement.

 Types de fragmentation

a) Fragmentation Horizontale (Répartition des occurrences)

Elle consiste à partitionner ou à découper une table en sous tables par l'utilisation des
prédicats permettant de sélectionner les lignes appartenant à chaque fragment selonun ou
plusieurscritères de sélection suivant les valeurs d'un ou plusieurs champs.La fragmentation
se fait par sélection, et la reconstitution de la table (relation) initiale se fait grâce à l'union de
sous tables.
Ce type de fragmentation est adapté à la régionalisation ou départementalisation dans une
entreprise. Par exemple, considérons qu'une base de données du casier judiciaire contient
tous les enregistrements des individus condamnés dans une table individu ayant le schéma
suivant.

Id Nom Prenom Genre Mention Province Crime


1 TSHIAMUA Juslin M Avec antécédent judiciaire Kinshasa Viol
2 LUKETA Christian M Avec antécédent judiciaire Kinshasa Vol
3 MULANGA Goshen F Avec antécédent judiciaire Congo central xxx
4 LIKOTELO Camile M Avec antécédent judiciaire Congo central yyy
5 NTUMBA Aaron M Avec antécédent judiciaire Kasaï central zzz

Illustration de la fragmentation

Au cas où le détail de tous les individus de la province de Congo central doit être envoyé dans
la province du Kasaï central, alors le concepteur réduira horizontalement la base de données
comme suit :

CREATE TABLE IND_CONGO_CENTRALAS SELECT * FROM INDIVIDU WHERE PROVINCE


IN(«CONGO CENTRAL»);

Résultat:

Id Nom Prenom Genre Mention Province Crime


3 MULANGA Goshen F Avec antécédent judiciaire Congo central xxx
4 LIKOTELO Camile M Avec antécédent judiciaire Congo central yyy

Exemple d'une fragmentation horizontale

b) Fragmentation Verticale (Répartition des attributs)

Elle se fait non au niveau des données mais de la structure même de la base où certains
champs sont envoyés dans un fragment et d'autres ailleurs.

La fragmentation verticale consiste à partitionner une relation en groupes d'attributs et une


clé doit apparaitre dans tous les groupes. Toutes les valeurs des occurrences pour un même
attribut se trouvent dans le même fragment.
Une fragmentation verticale est utile pour distribuer les parties des données sur le site où
chacune de ces parties est utilisée. Elle se fait par projection et la reconstruction de la relation
initiale se fait grâce à des jointures en vue d'éviter les pertes d'informations.

Par exemple, dans le schéma individu, on veut juste savoir le crime de chaque individu, le
concepteur réduira la base comme suit :

CREATE TABLE IND_MENTION AS SELECT ID, CONCAT(NOM,' ',PRENOM) AS NOMS, CRIME


FROM INDIVIDU;

Résultat :

Id Noms Crime
1 Juslin TSHIAMUA Viol
2 Christian LUKETA Vol
3 Goshen MULANGA Xxx
4 Camile LIKOTELO Yyy
5 Aaron NTUMBA Zzz

Exemple d'une fragmentation verticale

c) Fragmentation hybride (Répartition des valeurs)

C'est la combinaison des deux techniques de fragmentation précédentes, horizontale et


verticale. Les occurrences et les attributs peuvent donc être répartis dans des partitions
différentes.C'est la technique de fragmentation la plus flexible puisqu'elle produit des
fragments avec l'information étrangère minimale.Cependant, la reconstruction de la table
originale est souvent une tâche ardue.

La fragmentation hybride peut être faite de deux manières alternatives :

· Au début, produire d'un ensemble de fragments horizontaux ; produire alors des fragments
verticaux d'un ou plusieurs des fragments horizontaux.

· Au début, produire d'un ensemble de fragments verticaux ;produire alors des fragments
horizontaux d'un ou plusieurs des fragments verticaux.

L'opération de partitionnement est une combinaison de projections et de sélections et celle


de recomposition est une combinaison de jointures et d'unions.
CREATE TABLEIND_MENTIONASSELECT ID, CONCAT(NOM,' ',PRENOM) AS NOMS, CRIME
FROM INDIVIDU WHERE PROVINCE IN(`KINSHASA');

Résultat :

Id Noms Crime
1 Juslin TSHIAMUA Viol
2 Christian LUKETA Vol

: Exemple de fragmentation hybride

 Règles de fragmentation

La fragmentation doit tenir aux trois règles suivantes :

a) La complétude : pour toute donnée d'une relation R, il existe un fragment Ri de la relation


R qui possède cette donnée.

b) La reconstruction : pour toute relation R décomposée en un ensemble de fragments Ri, il


existe une opération inverse de reconstruction : la jointure pour les fragmentations verticales
et l'union pour celles horizontales.

a) La disjonction : aucune donnée ne doit se trouver dans plus d'un fragment sauf dans le cas
d'une fragmentation verticale où la clé primaire doit être présente dans l'ensemble des
fragments issus d'une relation.

IV.3.4. Conception de l'allocation des fragments

Ayant mis en oeuvre la fragmentation de la base, le problème réside sur la localisation du


fragment. En effet, un schéma d'allocation doit être élaboré afin de déterminer la localisation
de chaque fragment et sa position dans le schéma global : c'est l'allocation.

II.4.4.1. Schéma d'allocation

L'affectation des fragments sur le site est décidée en fonction de l'origine prévue des requêtes
qui ont servi à la fragmentation. Le but est de placer les fragments sur les sites où ils sont le
plus utilisés, dans le but de minimiser les transferts de données entre différents sites.

II.4.4.2. Techniques de répartition avancée

D'une part, la méthode classique d'allocation des fragments est appliquée et d'autre part, si
cette méthode ne s'avère pas satisfaisante, des techniques plus puissantes mais aussi
complexes à mettre en oeuvre doivent être envisagées :
 Allocation avec duplication

Au travers cette technique, certains fragments sont dupliqués sur un site ou sur l'ensemble de
sites selon les besoins. Une technique très importante car elle offre une amélioration
considérable des performances du système en termes de temps d'exécution des requêtes
étant donné que l'accès aux données est local grâce aux fragments qui sont un peu partout
dupliqués.

Cependant, la difficulté des mises à jour de tous les fragments dupliqués reste un inconvénient
majeur pour cette technique.

 . Allocation dynamique

Avec cette technique, l'allocation d'un fragment peut changer en cours d'utilisation d'une base
de données répartie. Ce qui fait qu'un fragment se trouvant sur un site A à l'instant T, peut
être retrouvé sur un autre site B à l'instant T+1. Néanmoins, elle reste une technique très
efficace lorsqu'il y a le maintien et la mise à jour du schéma d'allocation ainsi que des schémas
locaux.

 Fragmentation dynamique

Cette technique consiste au changement d'allocation dynamique des fragments ; ce qui peut
rendre possible deux fragments complémentaires (verticalement ou horizontalement) de se
retrouver sur un même site. C'est alors qu'intervient la fusion de ces fragments.

A l'inverse, si une partie est appelée sur un autre site, il peut être intéressant de décomposer
ces fragments et de ne faire migrer que la partie concernée. Ces modifications du schéma de
fragmentation se répercutent sur le schéma d'allocation et sur les schémas locaux.

 clichés (snapshots)

Un cliché est une copie figée d'un fragment. Il représente l'état du fragment à un instant donné
et n'est jamais mis à jour contrairement aux vues et aux copies qui répercutent toutes les
modifications qui ont lieu sur le fragment original.

L'intérêt d'un cliché diminue donc au fur et à mesure que le temps passe car toutefois,
l'information contenue dans la base de données peut ne pas rester figée (cas d'un changement
d'adresse non signalé, par exemple). Dans ce cas, l'utilisation des clichés est intéressante
lorsque l'on juge que la gestion des copies multiples se révélerait trop lourde pour la base de
données considérée alors que des copies même peu anciennes et non à jours seraient
largement suffisantes.

Néanmoins, les deux critères qui sont à prendre en compte pour définir l'intérêt d'un cliché
sont d'une part l'ancienneté du cliché, et d'autre part le temps d'attente qui serait nécessaire
avant d'obtenir l'information originale (à jour).

V) Réplication des données


Toute application de base de données repose sur un modèle client-serveur. Suivant ce
modèle, le client se connecte au SGBD pour passer des ordres. Ces ordres sont de deux natures
: lecture (on parle alors de requêtes) ou mise à jour (on parle alors de transactions).

Pour les transactions il y a une modification des données sur le serveur, mais cela reste des
ordres de courte durée. A l'inverse, dans le cas d'une lecture, il n'y a pas de modification des
données mais les traitements peuvent être longs et porter sur une grande masse de données ;
ce qui se passe dans le cadre d'une application web par exemple, où un nombre important de
requêtes peut surcharger partiellement (ou complètement) le serveur.

De ce fait, il existe plusieurs solutions pour palier à ce genre de problèmes et, la réplication en
est une.

V.1. Définition

La réplication est un processus qui consiste à copier l'ensemble d'une base de données (la
structure et les données) sur chaque noeud. Elle implique aussi la redondance des informations
dans différents sites.

V.2. Objectifs la réplication

L'objectif principal de la réplication est d'assurer la fiabilité du système et de faciliter l'accès


aux données en augmentant la disponibilité. Ceci soit parce que les données sont copiées sur
différents sites permettant de répartir les requêtes, soit parce qu'un site peut prendre la
relève lorsque le serveur principal s'écroule.

Une autre application tout aussi importante est la synchronisation des systèmes embarqués
non connectés en permanence. Ce qui permet d'éviter les transferts de données et d'assurer
la croissance de la résistance aux pannes.

Grâce à la réplication, les utilisateurs ne s'en aperçoivent pas lorsqu'un site est
momentanément inaccessible car un autre peut correctement le remplacer.

V.3. Technique de la réplication

La technique de la réplication, qui met en jeu au minimum deux SGBD, est assez simple et se
déroule en trois étapes :

· La base maître reçoit un ordre de mise à jour (INSERT, UPDATE ou DELETE).

· 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.

· 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.

Bien entendu, il est tout à fait possible d'appliquer la réplication dans les deux sens (de
l'esclave vers le maître et inversement). On parlera dans ce cas-là de réplication
bidirectionnelle ou symétrique. Dans le cas contraire où elle se fait du maitre vers l'esclave,
on parle d'une réplication unidirectionnelle ou en lecture seule ou encore asymétrique. Outre
ceci, la réplication peut être faite de manière synchrone ou asynchrone.

V.4. Avantages de la réplication

L'intérêt majeur de la réplication réside dans l'amélioration des performances et


l'augmentation de la disponibilité des données. Les avantages sont les suivants :

· Fiabilité: en cas d'échec de n'importe quel site, le système de base de données continue à
fonctionner puisqu'une copie est disponible à un autre site ;

· Réduction de charge de réseau : puisque les copies locales des données sont disponibles, le
traitement de requêtes peut être fait avec l'utilisation réduite de réseau, en particulier
pendant des heures de grand travail.La mise à jour de données peut être faite aux heures non-
principales ;

· Une réponse plus rapide : la disponibilité des copies locales des données assure le traitement
rapide de la requête et par conséquent le temps de réponse rapide ;

· Des transactions plus simples :les transactions exigent moins de nombre de jointures des
tables situées à différents sites et à coordination minimale à travers le réseau.Ainsi, elles
deviennent plus simples en nature.

V.5. Limites de réplication

Si la réplication présente de nombreux avantages, les problèmes soulevés sont multiples. Tout
d'abord, il faut assurer la convergence des copies.

· Conditions de stockage accrues : Le maintien des copies multiples des données est associé
aux coûts accrus de stockage. L'espace mémoire exigé est dans les multiples du stockage exigé
pour un système centralisé ;

· Plus grands coût et complexité des données mises à jour : Chaque fois qu'une donnée
élémentaire est mise à jour, la mise à jour doit être reflétée dans toutes les copies des données
aux différents emplacements.Ceci exige des techniques et des protocoles complexes de
synchronisation.

· Application indésirable - accouplement de base de données :Si des mécanismes complexes


de mise à jour ne sont pas employés, le déplacement des données d'inconsistance exige la
coordination complexe au niveau d'application. Ceci a comme conséquence l'application
indésirable - accouplement de base de données.

V.6. Techniques de diffusion des mises à jour

La diffusion automatique des mises à jour appliquée à une copie aux autres copies doit être
assurée par le SGBD réparti. Plusieurs techniques de diffusion sont possibles parmi lesquelles,
on distinguera celles basées sur la diffusion de l'opération de mise à jour, de celles basées sur
la diffusion du résultat de l'opération.

Diffuser le résultat présente l'avantage de ne pas devoir réexécuter l'opération sur le site de
la copie, mais l'inconvénient de nécessiter un ordonnancement identique des mises à jour en
tous les sites afin d'éviter les pertes de mises à jour.

Ces mises à jour peuvent de faire d'une manière synchrone ou asynchrone.

V.6.1. Mise à jour synchrone (synchronous update)

C'est un mode de distribution dans lequel toutes les sous opérations locales effectuées suite
à une mise à jour globale sont accomplies pour le compte de la même Transaction.

Lors de l'exécution d'une requête en lecture, la base de données répartie va décomposer la


requête globale en sous requêtes locales à l'aide des métadonnées de distribution.

a) Avantages

L'avantage essentiel de la mise à jour synchrone est de garder toutes les données au dernier
niveau de mise à jour. Le système peut alors garantir la fourniture de la dernière version des
données quel que soit la copie accédée.

De ce fait, ce mode de distribution est très utile, lors des copies, lorsque les mises à jour
effectuées sur un site doivent être prises en compte immédiatement sur les autres sites ; ce
qui garantit l'absence des conflits entre les différents sites en permettant le maintien de
toutes les copies en cohérence.

b) Limites

Ce mode de distribution présente des multiples limites. Ceci conduit beaucoup d'application
à éviter la gestion des copies synchrones.

En effet, ces limites sont d'une part la nécessité de gérer les transactions multi listes coûteuses
en ressources ; ce qui demande plus de ressources réseaux et matérielles, et d'autres parts la
complexité des algorithmes de gestion de concurrence et de panne d'un site. Raison pour
laquelle l'on préfère souvent le mode de mise à jour asynchrone (encore appelé mise à jour
différée). On notera aussi la perte des performances du fait de la mise en oeuvre de la
validation en deux phases (préparation de l'écriture des résultats de mises à jour et la
validation).

V.6.2. Mise à jour asynchrone (asynchronous update)

Mode de distribution dans le quel certaines sous opérations locales effectuées suite à une
mise à jour globale sont accomplies dans des transactions indépendantes en temps différé.
Le temps de mise à jour des copies peut être plus ou moins différé ; c'est-à-dire que les
transactions de report peuvent être lancées dès que possible où à des instants fixés, par
exemple le soir ou en fin de semaine.

a) Avantages

Les avantages sont la possibilité de mettre à jour en temps choisi des données, tout en
autorisant l'accès aux versions anciennes avant la mise à niveau. Il demande moins de
ressources réseau et matériel que le mode synchrone, ce qui implique une meilleure
disponibilité et une meilleure performance.

b) Limites

L'accès à la dernière version n'est pas garanti, ce qui limite les possibilités de mise à jour à
cause de certains conflits avec les données.

En effet, il y a possibilité d'avoir des conflits avec les données, dont voici les trois types :

1. conflit de mise à jour : deux ou plusieurs sites réalisent de transaction de modification sur
la même ligne pratiquement en même temps.

2. conflit d'unicité : Il provient d'une transaction d'insertion réalisée par deux ou plusieurs sites
différents tentant d'insérer dans une table une donnée comportant la clé primaire. Autrement
dit quand la réplication d'une ligne tente de violer l'intégrité d'une entité.

3. conflit de suppression : lorsqu'une transaction tente de modifier ou de supprimer une ligne


qui n'existe plus du fait de sa suppression par un autre site quelque temps plutôt. Cette ligne
ne peut donc être modifiée ou supprimer.

V.6.3. Types de réplication

 Réplication asymétrique

Au-delà des techniques de diffusion des mises à jour se pose le problème du choix de la copie
sur laquelle appliquer les mises à jour. La réplication asymétrique rompt la symétrie entre les
copies en distinguant un site maître appelé site primaire, chargé de centraliser les mises à
jour. Il est le seul autorisé à mettre à jour les données, et chargé de diffuser les mises à jour
aux copies dites secondaires.

Le grand défi dans cette gestion asymétrique est la panne du site primaire. Dans ce cas, il
importe à l'administrateur de choisir un remplaçant si l'on veut continuer les mises à jour, ce
qui nous amène alors à une technique asymétrique mobile dans laquelle le site primaire
change dynamiquement.

On peut donc distinguer l'asymétrique synchrone et l'asymétrique asynchrone :

a) Réplication asymétrique synchrone


Représentation 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 dite maître.

b) Réplication asymétrique asynchrone

Dans ce cas, le site primaire 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, l'horloge
par exemple.

Représentation asymétrique asynchrone


V.6.3 Réplication symétrique

A l'opposé de la réplication asymétrique, la réplication symétrique ne privilégie aucune copie ;


c'est-à-dire chaque copie peut être mise à jour à tout instant et assure la diffusion des mises
à jour aux autres copies. C'est une technique de gestion de copies permettant les mises à jour
simultanées de toutes les copies par les transactions différées.

En effet, cette technique pose un problème de la concurrence d'accès risquant de faire


diverger les copies. Sur ce, une technique globale de résolution de conflits doit être mise en
oeuvre (exemple : mise à jour d'une copie maitre qui est ensuite propagée).

On distingue pour ce cas, la réplication symétrique synchrone et la réplication symétrique


asynchrone.

a) Réplication symétrique synchrone

Lors de la réplication symétrique synchrone, les mises à jour s'effectuent à partir de n'importe
quel site maitre et sont diffusées en temps réel.

Représentation symétriques synchrone

b) Réplication symétrique asynchrone

Lors de cette réplication, les mises à jour sur des tables répliquées sont effectuées par
n'importe quel site en différées. Cette technique risque de provoquer des incohérences de
données car il est tout à fait impossible de défaire une transaction validée.
Représentation symétriques asynchrone

VII. Gestion des transactions réparties

VII.1. Définitions d'une transaction

Une transaction est un ensemble des opérations menées sur une BD, la transformant d'un état
stable cohérent en un autre état stable cohérent. En cas d'interruption pour une raison
quelconque, la transaction garantit de laisser la base de données dans l'état dans lequel elle
l'avait trouvée.

Représentation d'une transaction

Une transaction est soit validée par un commit, soit annulée par un rollback, soit interrompue
par un abort. Elle a une marque de début (Begin Of Transaction BOT) ainsi qu'une marque de
fin (End Of Transaction EOT).
Autrement, Une transaction est un traitement cohérent et fiable. La cohérence et la fiabilité
d'une transaction sont garanties par 4 propriétés : l'Atomicité, la Cohérence, l'Isolation, la
Durabilité qui font l'ACID d'une transaction.

Parlant d'opérations d'une transaction, nous en comptons quatre types dont : le début de la
transaction, la lecture, l'écriture et la terminaison.

VII.2. Condition de terminaison

Une transaction n'échoue pas, elle est interrompue pour diverses raisons, ou arrive à son
terme prévu. Pour assurer la cohérence de la base de données, en cas d'interruption de la
transaction, un mécanisme se charge de défaire toutes les actions qui ont déjà été effectuées,
c'est le rollback. Si la transaction n'est pas interrompue, elle se définit correctement et la base
de données peut prendre en compte les changements. On appelle généralement ce signal que
donne la transaction : commit ou validation.

VII.3. Propriétés des transactions

Une transaction est composée d'une suite de requêtes dépendantes de la base qui doivent
vérifier les propriétés d'atomicité, de cohérence, d'isolation et de durabilité, résumées par le
vocable ACID.

· Atomicité : cette propriété signifie qu'une transaction est traitée comme une seule opération.
Toutes les actions sont toutes menées à bien ou aucune d'entre elles. C'est-à-dire qu'une
transaction doit effectuer toutes ses mises à jour ou ne rien faire du tout. En cas d'échec, une
transaction doit annuler toutes les modifications qu'elle a engagées.

· Cohérence : une transaction est un programme qui amène la BD d'un état cohérent à un autre
état cohérent, tel que toutes les contraintes d'intégrité restent vérifiées. En cas d'échec, l'état
cohérent initial doit être restauré.

· Isolation : c'est la propriété qui impose à chaque transaction de voir la BD cohérente. Une
transaction en exécution ne peut révéler ses résultats à d'autres transactions concurrentes
(simultanées) avant d'effectuer le commit.

· Durabilité: c'est la propriété qui garantit lorsqu'une transaction a effectué son commit, le
résultat en permanence, et ne pourra être effacé de la BD quelques soient les pannes du
système rencontrées.

VIII. Système de Gestion de Bases de Données Réparties

VIII.1. Définitions

Un système de gestion de bases de données réparties (SGBDR) est une application centrale qui
administre une base de données répartie comme si toutes les données étaient stockées sur le
même ordinateur.
Il est donc un ensemble des logiciels qui gère des collections de bases des données logiquement
reliées et distribuées sur un réseau, en fournissant un mécanisme d'accès qui rend la répartition
transparente aux utilisateurs. Il cache de ce fait aux applications l'existence de multiples bases.
C'est à dire, il contrôle la base de données répartie de sorte qu'il apparaisse en tant qu'une
base de données simple aux utilisateurs.

Ce système synchronise toutes les données à des moments donnés et lorsque plusieurs
utilisateurs souhaitent accéder à la même donnée, il s'assure que les mises à jour, les
modifications et suppressions opérées sur la donnée à un endroit, sont automatiquement
répliquées aux autres endroits de stockage.

A la différence, un SGBD est dit centralisé lorsque le logiciel contrôle l'accès à une base de
données placée sur un ordinateur unique. Il est dit distribué lorsqu'il contrôle l'accès à des
données qui sont dispersées entre plusieurs ordinateurs.

Dans cette construction, un logiciel est placé sur chacun de différents sites, et ces sites
utilisent des moyens de communication pour coordonner les opérations. Le fait que les
informations sont dispersées est caché à l'utilisateur, et celles-ci sont présentées comme si
elles se trouvaient à une seule place.

En effet, une base de données centralisée est gérée par un seul SGBD et est stockée dans sa
totalité à un emplacement physique unique. Ses divers traitements sont confiés à une seule
et même unité de traitement. Par opposition, une base de données distribuée est gérée par
plusieurs processeurs, sites ou SGBD.

Le SGBD réparti doit offrir une gestion des priorités, verrous, concurrence de la même façon
qu'un SGBD centralisé. Pour ce faire, il doit disposer de :

· Dictionnaire des données reparties ;

· Communication des données inter site ;

· Gestion de la cohérence et de la sécurité ;

· Traitement des requêtes reparties ;

· Gestion des transactions reparties ;

Un SGBDR est composé en plusieurs couches :

· Le SGBD externe (user interface handler) : sa tâche est d'interpréter les commandes
utilisateurs ;

· Le système de gestion des fichiers (run-time support processor) : il gère le stockage physique
de l'information. Il est dépendant du matériel utilisé.
· Le contrôleur sémantique des données (semantec data controler) : il utilise les différentes
contraintes définies sur la base de données afin de vérifier qu'une requête d'un utilisateur
peut être effectuée.

· Le gestionnaire de reprise (recovery manager) : il s'occupe d'assurer la cohérence des


données lorsque des pannes surviennent.

· Le processeur de requêtes (query processor) : il détermine une stratégie afin de minimiser le


temps d'exécution d'une requête.

VIII.2. Les caractéristiques d'un SGBD réparti

Ces caractéristiquesd'un SGBD réparti sont reprises comme suit :

· Un SGBD réparti est utilisé pour créer, rechercher, mettre à jour et supprimer les bases de
données réparties ;

· Il synchronise la base de données périodiquement et fournit des mécanismes d'accès par la


vertu de laquelle la distribution devient transparente aux utilisateurs ;

· Il s'assure que les données modifiées à n'importe quel emplacement sont universellement
mises à jour ;

· Il est utilisé dans des domaines d'application où des grands volumes de données sont traités
et consultés par de nombreux utilisateurs simultanément ;

· Il est conçu pour les plateformes ou environnements hétérogènes de base de données ;

· Il maintient la confidentialité et l'intégrité des données des bases de données.

VIII.3. Intérêt d'un SGBD réparti

Les facteurs suivants encouragent la migration vers un SGBD réparti :

 Nature distribuée des unités d'organisation :

La plupart des organismes dans les temps courants sont subdivisés en unités multiples qui
sont physiquement réparties sur le globe. Chaque unité exige son propre ensemble de
données locales. Ainsi, la base de données globale de l'organisation devient distribuée.

 . Besoin de partage des données :

Les unités d'organisation multiples doivent souvent communiquer entre eux et partager leurs
données et ressources.Ceci exige les bases de données communes ou les bases de données
repliées qui devraient être employées d'une façon synchronisée.

 Support d'OLTP et d'OLAP :


Traitement transactionnel en ligne (OLTP) et le traitement analytique en ligne (OLAP)
travaillent sur les systèmes diversifiés qui peuvent avoir des données communes.Les systèmes
de base de données répartie facilitent ces deux traitements en fournissant des données
synchronisées.

 Rétablissement de Base de données :

Une des techniques communes utilisées dans un SGBD réparti est la réplication des données
à travers différents sites. Cette technique aide automatiquement dans le rétablissement de
données si la base de données dans n'importe quel site est endommagée.Les utilisateurs
peuvent accéder à des données d'autres sites tandis que le site endommagé est
reconstruit.Ainsi, l'échec de base de données peut devenir presque inaperçu aux utilisateurs.

 Support de multiple logiciel d'application :

La plupart des organismes emploient une variété de logiciel d'application chacune avec son
appui spécifique de base de données.Le SGBD réparti fournit une fonctionnalité uniforme
pour l'usage des mêmes données parmi différentes plateformes.

VIII.4 Architecture d'un SGBD réparti

Des architectures des SGBD répartis sont généralement développées selon trois paramètres :

· Distribution : elle énonce la distribution physique des données à travers les différents sites.

· Autonomie : elle indique la distribution de contrôle du système de base de données et du


degré auquel chaque composant du système de gestion de bases de données peut fonctionner
indépendamment.

· Hétérogénéité : elle se rapporte à l'uniformité ou à la dissimilitude des modèles de données,


des composants de système et des bases de données.

VIII.5 Modèles d'architecture des SGBD répartis

Certains des modèles architecturaux communs sont :

 . Architecture peer-to-peer

Dans ces systèmes, chaque pair agit à la fois comme un client et un serveur pour donner des
services de base de données.Les pairs partagent leur ressource avec d'autres pairs et
coordonnent leurs activités.

Cette architecture a généralement quatre niveaux des schémas :

§ Schéma Conceptuel Global : Dépeint la vue des données logique globale.

§ Schéma Conceptuel Local :Dépeint l'organisation logique de données à chaque


emplacement.
§ Schéma Interne Local :Dépeint l'organisation physique de données à chaque emplacement.

§ Schéma Externe :Dépeint la vue d'utilisateur des données.

Architecture peer-to-peer

 . Architecture Client server

C'est une architecture à deux niveaux où la fonctionnalité est divisée en serveurs et clients.Les
fonctions de serveur entourent principalement la gestion des données, de traitement de
requête, d'optimisation et de transaction. Les fonctions de client incluent principalement
l'interface utilisateur. Cependant, elles ont certaines fonctions comme la vérification de
l'uniformité et la gestion de transaction.
Architecture client-serveur de SGBD Réparti

Un client de SGBDR est une application qui accède aux informations distribuées par les
interfaces du SGBDR tandis qu'un serveur de SGBDR est un SGBD gérant une base de données
locale intégrée dans une base de données répartie.

Au-delà des notions de client et de serveur SGBDR, on a un calculateur dans le réseau gérant
la base appelé noeud ou site.

VIII.6. SGBDR homogène

Toutes les BD suivent un même schéma et utilisent la même technologie (ex: Oracle). L'accès
aux données ainsi quela gestion des transactions réparties sont souvent faits de manière
centralisée. En plus, cette architecture présente une plus grande fiabilité et performance dû à
un meilleur couplage entre les sites.
Architecture répartie avec SGBD répartis homogènes

VIII.7. Multi-SGBD réparti

Dans cette architecture, chaque site est autonome et peut avoir un SGBD de type différent.
Ce qui conduit à l'utilisation des interfaces (ex: schéma conceptuel) différentes et cela peut
devenir très complexe à gérer.

Le Multi-Système de gestion de bases de données peut être exprimé par six niveaux des
schémas :

 Niveau De Vue Multi-base de données : Dépeint des vues multiples d'utilisateur


comportant des sous-ensembles de la base de données répartie intégrée.
 Niveau Conceptuel Multi-base de données :Dépeint la multi-base de données
intégrée qui comporte des définitions logiques globales de structure de multi-base
de données.
 Niveau Interne Multi-base de données :Dépeint la distribution de données à travers
différents emplacements et la multi-base de données aux données locales traçant.
 Niveau local de vue de base de données :Dépeint la vue publique des données
locales.
 Niveau conceptuel de base de données locale :Dépeint l'organisation locale de
données à chaque emplacement.
 Niveau interne de base de données locale :Dépeint l'organisation physique de
données à chaque emplacement.

Architecture répartie avec multi-SGBD

II.7.4.4. SGBD Fédérés

L'architecture fédérée intègre plusieurs SGBD autonomes et potentiellement hétérogènes en


une seule BD virtuelle dont l'interface d'accès commun doit être implémentée pour masquer
l'hétérogénéité des BD et la répartition des données.

L'inconvénient de cette architecture reste l'intégration du schéma, la réécriture des requêtes


complexes ainsi que les performances limitées.
Architecture répartie avec SGBD fédérés

IX) Objectifs du SGBDR

Les objectifs d'un SGBDR se résument en ces aspects suivants :

 Multi client-serveur

Dans le contexte du client serveur, un client peut demander l'exécution d'une requête à un
serveur. La requête, appelée requête distante peut par exemple être exprimée en SQL. Pour
assurer l'objectif multi clients, le SGBDR doit fournir des mécanismes de contrôle de
concurrence adapté, garantissant que l'effet de l'exécution simultanée des transactions est le
même que celui d'une exécution séquentielle : cette propriété est appelée la sérialisabilité des
transactions.

 Transparence à la localisation des données

Un des objectifs clés de SGBDR est de permettre l'écriture des programmes d'application sans
connaître la localisation physique des données. Dans ce but, les noms des objets (par exemple
le nom des tables) doivent être indépendants de leurs localisations. Les requêtes seront en
général exprimées en SQL de manière similaire aux requêtes locales. Elles référenceront des
vues de la base repartie ; ces vues porteront un nom ne concernant pas la localisation des
données.

La transparence à la localisation simplifie la vue utilisateur et l'écriture de requête, moins


surtout d'introduire la possibilité de déplacer les objets (par exemple les tables) sans modifier
les requêtes.

 Meilleure disponibilité des données

L'apport en matière de disponibilité des données reste sans doute une des justifications
essentielles d'un SGBDR. Tout d'abord, la répartition permet de ne plus dépendre d'un site
central unique et en suite, elle permet de gérer des copies, de se replier sur une copie
lorsqu'une autre est indisponible (site en panne), et même mettre à jour de manière
indépendante les copies.
Les copies deviennent alors des reliquats qui peuvent évoluer indépendamment pour
converger ultérieurement. Cette fonctionnalité appelée réplication.

Notons aussi que : assurer une meilleure disponibilité des données, c'est aussi garantir
l'atomicité des transactions.

 Autonomie locale des sites

Un autre objectif des SGBDR est d'éviter la nécessité d'une administration centralisée des
bases. L'autonomie locale vise à garder une administration locale séparée et indépendante
pour chaque serveur participant à la BD répartie.

Ainsi, les reprises après panne doivent être accomplies localement et ne pas impacter les
autres sites. Les mises à niveau de logiciel sur un site doivent être possible sans impacter les
autres les autres sites. Bien que chaque base puisse travailler avec les autres, les gestions de
schéma doivent rester indépendantes.

 Support d'hétérogénéité

Un SGBDR hétérogène doit être capable d'unifier modèles et langage comme représenté
Figure suivante. Ceci afin de gérer des bases fédérées. L'unification s'effectue en général par
un langage pivot afin de limiter le nombre de conversion de modèle à réaliser.

Nous avons vu tout au long de ce chapitre, ce qu'on appelle SGBDR, ses avantages et ses
limites, ses caractéristiques, ses objectifset ses différentes sortes existantes. Dans le chapitre
que nous allons aborder ici-bas, nous parlons de l'authentification par mesure biométrique
en utilisant la technique d'empreinte digitale.

Vous aimerez peut-être aussi