TBDR - L3 Info Upcc

1
CHAPITRE I. L’ARCHITECTURE CLIENT – SERVEUR

I.1. INTRODUCTION
Dans un monde où la course à la
productivité conduit les technologies à évoluer de plus
en plus vite, le client-serveur s'est taillé une part de choix
depuis le début des années 1990. En effet, il faut pouvoir
disposer de systèmes d'information évolutifs permettant
une coopération fructueuse entre les différentes entités de
l'entreprise. Les systèmes des années 70 et 80 ne
répondaient pas à ces exigences.
Les réseaux occupent désormais une
place centrale dans l'entreprise. Les vitesses de calcul
des micros deviennent impressionnantes. Le graphique est
partout au niveau des interfaces. Le besoin de partage
des données est essentiel aussi bien pour l'accès
transactionnel caractérisé par des mises à jour rapides en
temps réel que pour l'accès décisionnel marqué par le
besoin de requêtes complexes sur de gros volumes de
données. Il faut développer vite, par exemple pour ne pas
rater un mailing ciblé suite à une campagne de
promotion. La concurrence entre les entreprises est
exacerbée ; la flexibilité et la productivité de l'informatique
font souvent la différence.
Toutes ces raisons expliquent le
Développement autour des réseaux d'entreprises de
serveurs départementaux ouverts offrant des interfaces
standards pour permettre la connectivité des outils micros.
Simon MPOLESHA TSHIAMALA

2
C'est aussi pour faciliter le partage et l'accès simplifié aux

données que triomphe les bases de données relationnelles
avec la possibilité de gérer des types de données étendus.
Pour améliorer la vitesse de développement et surtout la
maintenabilité des applications, on voit s'imposer des
méthodes de conception et de développement orientées
objets. Ainsi, l'architecture type d'un système moderne a
évolué vers celle représentée figure 1. Il s'agit là d'une
architecture client-serveur (en abrégé, C/S).
Figure 1 -Exemple d'architecture moderne des années 90.

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’adressant à lui par des requêtes envoyées sous forme de
messages.

3
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.
On distingue plus particulièrement le client
serveur de présentation, le client serveur de données et le
client serveur de procédures. Avec le client serveur de
présentation, le client assure seulement l’affichage et la
saisie des informations (on parlera dans ce cas d’un client
léger). Avec le client serveur de données, le serveur
accomplit la gestion des données. Dans le cas du serveur
de procédure, le serveur exécute des procédures pour le
compte de clients, des procédures pouvant accéder aux
données. Les deux derniers types client-serveur
convergent aujourd’hui vers une architecture client-
serveur, de données et procédures.
Un de composants clé de l’architecture
client-serveur est le middleware. Il s’agit simplement de
logiciels assurant la médiation entre clients et serveurs
dans le cadre d’architecture de système hétérogènes.
Mais la médiation peuvent assurer de multiple fonction
telles homogénéisation des formats de requêtes et
données l’optimisation des accès, la gestion de services
distribués, etc…
I.2. TECHNIQUES DE DIALOGUE CLIENT – SERVEUR

4
Le client serveur est avant tout une

technique de dialogue entre deux processus, l’un le client
sous-traitant à l’autre, le serveur des fonctions à réaliser.
I.2.1. Notion de base
Le modèle de communication client-serveur
est orienté vers la fourniture de service par un processus
serveur à un processus client. Un échange consiste donc
en la transmission d’une requête à un serveur, qui exécute
l’opération demandée et envoi en retour la réponse. Nous
définissons ci-dessous plus précisément les concepts de
base.
Notion 1 : Client (Client)
Est un processus demandant l’exécution
d’une opération à un autre processus par 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.
Notion 2 : un serveur (serveur)
Est 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 (réponse)
Notion 3 : Requête (Request)
Message transmis par un client à un serveur
décrivant l’opération à exécuter pour le compte du client.

5
Notion 4 : Réponse (Reply)

Message transmis par un serveur à un client
suite à l’exécution d’une opération contenant les
paramètres de retour de l’opération.
En résumé, la figure 2 illustre ces notions :
un client exécute une application et demande l’exécution
d’une opération à un serveur par le biais d’une requête, il
reçoit une réponse, lui indiquant par exemple que
l’opération a été bien exécutée. Les appels au service de
transport mis en jeu sont au nombre de quatre : Send
Request( ) permet au client d’émettre le message
décrivant la requête à une adresse correspondant à la
porte d’écoute du serveur.
Receive Reply ( ) permet au client de recevoir la réponse
en provenance du serveur ;
Receive Request( ) permet au serveur de recevoir la
requête sur sa porte d’écoute.
Send Reply( ) permet au serveur d’envoyer la réponse sur
la porte d’écoute du client.

6
Figure 2 architectures client server
Les diagrammes de classes
L’identification des clients et des serveurs

dans un réseau est un problème d’adressage réseau. Une
ou plusieurs adresses de porte sont généralement
associées à un serveur. Cette adresse peut être
dépendante du site ou indépendante, ce qui permet un
changement de localisation des serveurs sans
changement d’adresse.
I.2.2. Dialogue synchrone et asynchrone

7
Le dialogue client-serveur nécessite

l'émission d'une requête et la réception d'une réponse. Le
RPC permet de cacher ces mécanismes de bas niveau
pour l'application.
Lors de l'émission d'une requête par une
commande SendRequest(), celle-ci peut être émise
immédiatement ou mise en file d'attente pour émission
ultérieure. Dans ce dernier cas, la commande
SendRequest() n'est généralement pas bloquante, et
l'utilisateur peut effectuer une autre tâche avant de venir
attendre la réponse par une commande ReceiveRequest.
Cette dernière commande peut de même être bloquante
en attente de la réponse, ou non bloquante avec un code
retour signalant que la réponse n'est pas arrivée. Ceci
conduit à distinguer les notions de dialogue synchrone et
de dialogue asynchrone.
Notion 9 : Dialogue synchrone (Synchronous dialog)
Type de dialogue géré sans file d'attente, où
les commandes d'émission et de réception sont
bloquantes.
Typiquement, dans le cas synchrone, le
client attend le serveur pendant que celui-ci exécute une
opération pour lui.
Notion 10 : Dialogue asynchrone (Asynchronous dialog)
Type de dialogue géré avec file d'attente,
où l'une au moins des commandes d'émission ou de
réception est non bloquante.

8
Le dialogue asynchrone permet au client

d'effectuer une autre tâche pendant que le serveur
exécute une opération pour lui. Il permet aussi, par le biais
des files d'attente, de demander plusieurs opérations au
serveur avant de recevoir les réponses.
Le dialogue asynchrone permet au client
d’effectuer une autre tâche pendant que le serveur
exécute une opération pour lui. Il permet aussi par le biais
des files d’attente, de demander plusieurs opérations au
serveur avant de recevoir les réponses.
I.3. LES DIFFERENTS TYPES DE C-S
Selon la nature des services accomplis
par le serveur pour un client, différents types de
clientserveur ont été distingués. La figure 3 illustre diverses
possibilités reconnues. Selon la répartition des fonctions de
présentation graphique (affichage et saisie de données à
partir d'icônes graphiques par exemple), de gestion de
données (accès aux fichiers ou aux bases de données),
d’exécution de code applicatif (calculs de l’application),
on distingue les types de client-serveur décrits ci-dessous.
Tout d'abord, l'architecture client-serveur
peut être mise en œuvre afin d'assurer une meilleure
qualité du dialogue homme-machine. Un processus
serveur, souvent exécuté sur une machine séparée (par
exemple un terminal intelligent) exécute les fonctions
d'entrées- sorties graphiques pour un processus client qui
exécute le code applicatif. Cette organisation est

9
appelée client-serveur de présentation. Elle peut être

utilisée pour transformer une interface hommemachine
caractères en interface graphique : on parle alors de
rhabillage.
Figure 3 -Répartition des fonctions selon le type de client-serveur.

Notion 11 : C/S de présentation (Presentation CIS)
Type de client-serveur dans lequel un
processus exécute seulement les fonctions de dialogue
avec l'utilisateur, l'autre gérant les données et exécutant
le code applicatif.
Notion 13 : C/S de données (Data CIS)
programme applicatif contrôlé par une interface de
présentation sur une machine cliente accède à des
données sur une machine serveur par des requêtes de

10
recherche et mise à jour, souvent exprimée avec le

langage SQL.
Le serveur de données gère une ou plusieurs
bases de données. La base de données est accédée par
le langage SQL (Structured Query Language). De plus en
plus souvent, elle intègre des procédures stockées,
procédures applicatives recevant des paramètres
d'entrée, accédant à la base, et retournant des
paramètres de sorties. Ainsi, le client-serveur de données
devient de plus en souvent, dans sa nouvelle génération,
un client-serveur de procédures défini comme suit.
Notion 14 : C/S de procédures (Procedure CIS)
programme applicatif contrôlé par une interface de
présentation sur une machine cliente sous-traite
l'exécution de procédures applicatives à une machine
serveur, ces procédures encapsulant souvent une base de
données.
I.4. LE C/S DE DONNEES ET PROCEDURES
La tendance est donc d'aller vers un système
d'information du type client-serveur de données et
procédures. De plus en plus souvent, ce type de
clientserveur permet de mettre en commun des
procédures communes autour de la base de données au
niveau du serveur, et donc de répartir les traitements entre
client et serveur.
Plus précisément, les composants d'une telle

11
architecture (cf. figure 5) sont les suivants :

• Les clients. Ils supportent le code de l'application
non lié directement aux données. Ce code est
réalisé grâce à un outil de développement
d'application. Il implémente les dialogues interactifs
avec les utilisateurs, les traitements spécialisés des
messages, l'affichage des résultats.
• Le serveur. Il assure le stockage, la distribution, la
gestion de la disponibilité et de la sécurité des
données. Il permet l'accès transactionnel et
décisionnel aux informations. Classiquement, il
regroupe les fonctionnalités du SGBD et sera
aujourd'hui bâti autour du modèle relationnel, qui
est simple, clair, et évolutif. Il devra aussi autoriser la
mise en commun de traitements communs, souvent
liés aux données de la base, par le moyen de
procédures stockées.
• Le réseau. Avec les protocoles réseau de transport
et d'échange de requêtes, il permet le transfert des
demandes et des résultats. Il assure la
connectabilité des outils clients au serveur ; l'outil de
connectabilité permet l'encodage des requêtes en
messages sur le client, et le décodage sur le serveur,
et vice versa pour les réponses.

12
Figure 4 - Les composants de l'architecture client-serveur de données.

Les intérêts techniques d'une architecture
client-serveur de données et procédures sont multiples.
Parmi ceux-ci nous citerons les suivants :
✓ La diminution du codage des applications.
L'application ne gère pas la sécurité et la
cohérence de l'information. Les procédures de
gestion et contrôle des données sont codées une
fois pour toute au sein du serveur. L'accès aux
informations s'effectue via SQL, langage de haut
niveau normalisé.
✓ La mise en commun des procédures réutilisables. En
effet, avec les serveurs modernes, il est possible de
13
développer des bibliothèques de procédures

accédant intensivement à la base sur le serveur. Les
données peuvent ainsi être encapsulées par les
fonctions de service. Mieux, des règles de gestion
déclenchées automatiquement lors des mises à
jour peuvent être programmées au niveau du
serveur.
✓ La diminution du trafic réseau. Celui-ci ne véhicule
plus que les données utiles (requêtes, résultats),
après sélection et transformation des données sur le
serveur. De plus, grâce aux procédures stockées, il
est possible de limiter le trafic aux seuls paramètres
nécessaires aux transactions.
✓ La gestion transactionnelle fiable des données. Le
serveur fournit à tous les clients la gestion de
transactions atomiques, cohérentes, à mises à jour
isolées, et à effets durables (ACID). Il gère des
journaux et sauvegardes pour assurer les reprises.
✓ La sécurité des accès aux données. Le serveur
permet d’authentifier les utilisateurs et de contrôler
les droits d'accès selon les autorisations allouées aux
utilisateurs ou aux groupes d'utilisateurs.
✓ L’optimisation et l’administration centralisée des
données. L’efficacité des accès disques est gérée
par le SGBD au niveau du serveur qui maintient une
gestion centralisée des chemins d'accès et une
optimisation sophistiquée des requêtes selon des

14
modèles de coûts paramétrés. Ceci permet de

concentrer le travail important d'administration des
données sur un lieu unique, au profit de tous.
I.5. Architecture client server par niveau
I.5.1. Architecture client server deux tiers (ou à deux
niveaux)
Le client demande une ressource et le

serveur la lui fournit directement. Cela signifie que le
serveur ne fait pas appel à une autre application afin de
fournir le service. Le serveur exécute les requêtes et gère
les accès aux bases de données.

15
I.5.2 Architecture Client server trois tiers (ou à trois

Niveaux)
Le client: le demandeur de ressources

Le serveur d'application (appelé aussi
middleware c'est-à-dire le médiateur): le serveur chargé
de fournir la ressource mais faisant appel à un autre
serveur.
Le serveur secondaire (généralement un

serveur de base de données), fournissant un service au
premier serveur.
I.6. LES MIDDLEWARE (intergiciel)
I.6.1. Définition
Le middleware est ce logiciel du milieu qui
assure les dialogues entre clients et serveurs souvent
hétérogènes. Le terme middleware vient de l’anglais
middle (du milieu) et software (logiciel), il désigne un
ensemble de services logiciels nécessaires servant

16
d’intermédiaire entre les logiciels pour permettre et

organiser la communication entre les applications
réparties ; ou un ensemble de services logiciels
construits au-dessus d’un protocole de transport afin de
permettre l’échange de requêtes et des réponses
associées entre client et serveur d’une application de
manière transparente.
Exemple d’un middleware

SQL*Net : Interface propriétaire permettant
de faire dialoguer une application cliente avec une base
de données Oracle. Ce dialogue peut aussi bien être le
passage de requêtes SQL que l'appel de procédures
stockées.
ODBC (Open DataBase Connectivity) :
Interface standardisée isolant le client du serveur de
données. C'est l'implémentation par Microsoft du
standard CLI (Call Level Interface) défini par le SQL Access
Group. Elle se compose d'un gestionnaire de driver
standardisé, d’une API s’interfaçant avec l’application

17
cliente (sous Ms Windows) et d'un driver correspondant au

SGBD utilisé.
DCE (Distributed Computing Environment) :
Mécanisme de RPC proposé par l'OSF.) : Permet l'appel à
des procédures distantes depuis une application.
Le choix d'un middleware est déterminant en
matière d'architecture, il joue un grand rôle dans la
structuration du système d'information.
Les middlewares proposés par les fournisseurs
de SGBD sont très performants et permettent de tirer profit
de l'ensemble des fonctionnalités du serveur de données
pour lequel ils ont été conçus. Par contre, ils ne permettent
pas, le plus souvent, l'accès à d'autres sources de
données.
I.6.2. Rôle
Le middleware offre des services de haut niveau liés au
besoin de communication des applications (temps réel,
sécurisation, sérialisation, transaction informatique, etc…)
appelé communication interprocessus (inter Process
Communication, IPC). Elle vient se situer dans le modèle
OSI au-dessus de la couche de transport.

18
I.6.3. Les fonctions d’un Middleware

Il indique la procédure d’établissement de
connexion ;
Il exécute des requêtes ;
Il récupère des résultats ;
Il initie des processus sur différents sites ;
Il organise les services des répertoires (nommage) ;
Il permet l’accès aux données à distance ;
Il gère des accès concurrents ;
Il garantit la sécurité et l’intégrité ;
Il assure la terminaison des processus ;
Les interfaces applicatives et les transporteurs

de requêtes.
Une interface applicative (Application
rogrammig Interface API) est un ensemble de fonction
standard pour accéder d’un service local ou distant.

19
I.7. Les contraintes de l'entreprise

Les entreprises sont soumises à des contraintes
de plus en plus fortes, aussi bien du monde extérieur que de
l'intérieur de l'entreprise. Les contraintes externes sont
imposées par les clients de plus en plus exigeants, la
régulation de plus en plus complexe, la compétition de plus
en plus dure qui conduit à réduire le temps de passage d'un
produit de la conception à la vente. Plus précisément, il s'agit
donc de :
Mieux satisfaire les clients, par exemple en
leur présentant des informations consolidées et claires ;
Respecter les régulations en vigueur, malgré
leur évolutivité, par exemple en étant capable de générer
rapidement de nouvelles déclarations ;
Produire mieux et plus vite les nouveaux
produits, de sorte à participer à la compétition active vers
la nouveauté, et à réduire le time ta market.
Les contraintes internes se traduisent par
des pressions sur les budgets, la difficulté à absorber les
technologies nouvelles, et un manque général de
temps et de moyens. Les budgets sont de plus en plus
serrés, car la compression des dépenses est nécessaire à
l'équilibre de l'entreprise. De ce fait, les ressources sont
limitées, et les expérimentations avec des technologies
nouvelles, souvent coûteuses du fait du poids de plus en
plus grand de l'historique, ne peuvent être menées à bien.
Les ingénieurs et techniciens au fait des technologies

20
nouvelles manquent cruellement de temps, et la

conversion des autres est difficile. Ainsi, on observe dans la
plupart des entreprises les problèmes suivants :
✓ Budgets et ressources limités réduisant les capacités
d'innovation et de reprise de l'existant ;
✓ Capacités à absorber de nouvelles technologies
limitées par les moyens humains et matériels, et par
le poids de l'existant ;
✓ Manque de temps des personnels les plus qualifiés.
CHAPITRE II. BASE DE DONNEES REPARTIES

II.1. INTRODUCTION
Le système de gestion de base de données
repartis a été inventé à la fin des années 70 afin d’intégrer
les bases de données et les réseaux.
La fédération de bases données
existantes est une nécessité pour un grand nombre
d’entreprise. En effet, il faut souvent accéder de manière
intégrée à des données disséminées sur différents
calculateurs du siège et des usines. Plus précisément, il faut
offrir un système de gestion intégrant des sources de
données hétérogènes en assurant la transparence à la
distribution et à l’hétérogénéité, ceci enfin de faciliter les
développements pour l’utilisateur. Avec les grands
réseaux internationaux tels que INTERNET, le besoin de
fédération de données hétérogènes (tables, textes,
documents audio-visuels, géométrie, cartes, etc…) est

21
immense. La recherche en bases de données réparties

dont un des aboutissements est déjà le client-serveur a
donc encore un bel avenir.
II.2. DEFINITION
Une base de données repartie est un
ensemble de bases de données gérées par de sites
différents et apparaissant à l’utilisateur comme une base
unique.
Une base de données repartie peut aussi
être vue comme une collection de bases de données
logiquement reliées, distribuées sur un réseau.
II.3. LE SGBD REPARTI
Nous précisons maintenant les composants
essentiels nécessaires pour gérer des données reparties.
Le système de gestion de bases de données reparti
(SGBDR) cache aux applications l’existence de multiples

22
bases. Il fournit aux clients SGBDR l’illusion que l’ensemble

des bases gérées par les serveurs du SGBDR et intégré en
une base unique.
II.3.1. QUELQUES DEFINITIONS DE BASE
Un SGBD reparti est un système qui gère des
collections de BD logiquement reliées, distribuées sur un
réseau, en fournissant un mécanisme d’accès qui rend la
répartition transparente aux utilisateurs.
Un client de SGBDR est une application qui
accède aux informations distribuées par les interfaces du
SGBDR.
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 de SGBDR et
de serveur, un calculateur gérant la base appelé noeud
ou site. Un site peut être à la fois client et serveur du SGBDR
: il exécute l’application et gère une partie de la base.
C’est sans doute le cas le plus fréquent.
Nœud ou site de SGBDR est un calculateur
dans le réseau participant à la gestion d’une base de
données repartie.
En résumé, un SGBDR est donc un ensemble
de logiciels systèmes gérant des données reparties sur un
ensemble de sites intégrant des modules clients et des
modules serveurs.
II.3.2. OBJECTIF DES SGBDR

23
Nous précisons les objectifs des SGBDR qui se

résument aux aspects clés suivants :
✓ Multi clients multi serveurs ;
✓ Transparence à la localisation des données ;
✓ Meilleure disponibilité des données ; ✓ Autonomie
locale des sites ; ✓ Support de l’hétérogénéité.
II.3.2.1. MULTI CLIENTS MILTI SERVEURS
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. Bien un SGBDR doit permettre
l’accès simultané de plusieurs clients aux données. 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 et le même que celui d’une exécution
séquentielle : cette propriété est appelée la sérialisabilité
des transactions.
Au-delà un SGBDR doit permettre l’exécution
de requête distribuée, mettant en jeu plusieurs serveurs.
Une transaction qui met en œuvre plusieurs serveurs et
appelée transaction distribuée. A noter qu’une
transaction distribuée peut simplement être composée de
plusieurs requêtes distantes, chacune étant exécutée par
un serveur différent. Souvent, une transaction distribuée
comportera des requêtes distribuées.

24
II.3.2.2. Transparence à la localisation des données

Un des objectifs clé de SGBDR est de
Permettre d’écrire 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.
Ces avantages de la transparence à la
localisation sont tout d’abord de simplifier la vue utilisateur
et l’écriture de requête, moins surtout d’introduire la

25
possibilité de déplacer les objets (par exemple les tables)

sans modifier les requêtes.
La transparence à la localisation présente
Cependant l’inconvénient de contraindre le SGBDR à
rechercher les sites capables de générer des éléments de
réponse à une requête pour l’exécuter.
Ceci n’est pas une fonction évidente, si bien
que l’objectif d’indépendance à la localisation a été
souvent mis en cause. Un compromis a pu être trouvé en
utilisant un hiérarchique pour les tables qui constituent
souvent l’unité de localisation. Ce nom est du type
«table»@ «base», ou «table» est un nom de table et «base»
un nom de base. Le nom de base permet de déterminer
de manière unique un nom de site. Si l’utilisateur utilise
directement un tel nom composé, il n’y a plus
indépendance à la localisation : la migration d’une table,
d’une base à une base à une autre nécessite de modifier
le programme.
II.3.2.3. MEILLEURE DISPONIBILITE
Une des justifications essentielles d’un SGBDR
est sans doute l’apport en matière de disponibilité des
données. Tout d’abord, la répartition permet de ne plus
dépendre d’un site central unique. Surtout, 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 réplicats

26
qui peuvent évoluer indépendamment pour converger

ultérieurement. Cette fonctionnalité appelée réplication.
Assurer une meilleure disponibilité des
données, c’est aussi garantir l’atomicité des transactions.
Une transaction est en effet un ensemble de requêtes,
dont certaines sont des mises à jour. Ces requêtes plus
particulièrement les mises à jour doivent être toutes
correctement exécutées ou aucune ne doit l’être. Dans le
cas contraire, la base de données repartie serait
seulement partiellement mise à jour.
II.3.2.4. AUTONOMIE LOCALE
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.

27
Chaque base conservera donc son

dictionnaire local contenant les schémas locaux. Afin de
faciliter la coopération, il est nécessaire de connaître les
schémas des objets ou tables distantes utilisés dans les
requêtes. Ceci se fera par adjonction d’une extension du
dictionnaire qui sera remplie lors du premier accès à un
objet distant par importation du schéma ou plus
explicitement lors de la création d’un lien avec une base
ou un objet distant.
L’autonomie nécessite une mise à niveau
automatique des schémas importés. Ceci peut être
effectué par un mécanisme de version ; lors de l’accès à
une table, la version du schéma importé sera contrôlée ;
dans le cas où le schéma aura été modifié sur le site gérant
la table. Il sera mis à niveau sur le site client.

28
II.3.2.5. HETEROGENEITE
Nous avons déjà vue ci-dessus le besoin des
Entreprises en matière d’accès intégré à des bases de
données hétérogènes existantes. 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.
II.4. LES PRINCIPES FONDAMENTALES D’UNE BASE DE

DONNEES REPARTIE
L ’Atomicité locale
L’Atomicité locale implique la base
individuelle locale soit totalement fonctionnel même si elle
ne peut pas communiquer avec les autres sites de la base de
données repartie.
Elle implique aussi que chaque site est
responsable de l’intégrité de ses propres données, de sa
propre sécurité et de sa propre gestion.
La transparence de la localisation des
29
données signifie que les utilisateurs de la base de données

ne réalisent pas que les bases de données sont distantes :
les utilisateurs doivent donc être capables d’accéder aux
données distantes dès que la base de données locale est
présente.
II.5. Schéma global
Comme toute base de données, une
base de données répartie possède un schéma appelé
schéma global qui permet de définir l’ensemble des types
de données de la base. Par exemple le schéma global de
la base de données répartie présentée en exemple ci-
dessus est défini figure suivante. Il s’agit d’une vision
relationnelle de la base. Une vision plus conceptuelle, en
termes d’entité et d’association. A ce titre, il est souvent
appelé schéma conceptuel.
Dans une base de données répartie, le
schéma global ou conceptuel n’est pas forcément
matérialisé. Chaque base locale implémente une partie.
Ces parties locales sont les seules matérialisées des
disques.
Figure 2 : Exemple de schéma global relationnel

30
Schéma global associé entité – association

II.6. Conception d’une base de données Reparties
Conception ascendante ou descendante
Deux approches se distinguent nettement
pour concevoir une base de données répartie. La
conception descendante est utilisée lors de la constitution
de nouvelles bases de données. Elle est illustrée figure
10.a. Un schéma conceptuel global est surtout d’abord
élaboré, puis les diverses entités de ce schéma sont
distribuées sur les sites, ce qui conduit à la définition des
schémas locaux.
Au contraire, la conception ascendante
permet l’intégration de BD locales existantes dans une
base fédérée. Elle consiste à intégrer des schémas locaux
existants afin de constituer un ou plusieurs schémas

31
globaux. Dans ce cas, la distribution des données est

préexistante.
Conception d’une base de données par approche

descendante

32
II.6.1. Techniques de fragmentation

La conception descendante d’une base de
données répartie conduit à distribuer sur différents sites des
parties appelés fragments d’une table globale. Par une
approche plus synthétique, la conception ascendante
aboutit à un résultat similaire, une table globale étant aussi
divisée en fragments.
Fragment
Sous-table obtenue par la sélection des lignes et colonnes
à partir d’une table globale localisée sur un site unique.
A partir d’une table globale, la fragmentation peut
d’une part s’effectuer par sélection de lignes, la
fragmentation horizontale correspond à ce type de
découpage, comme illustré figure 11.a.
1. Fragmentation horizontale
Découpage d’une table en sous-table par
utilisation de prédicats permettant de sélectionner les
lignes appartenant à chaque fragment.
Ce type de fragmentation est adapté à la régionalisation
ou départementalisation dans une entreprise. Chaque
région (ou département) A défini un prédicat du type
DIRECTION = A, qui par sélection définit le fragment
associé à la direction. Celui-ci est localisé sur le site de la
direction.
A partir d’une table globale, la fragmentation
peut d’autre part s’effectuer verticalement,
par projections sur des colonnes.

33
2. Fragmentation verticale
Découpage d’une table en sous-table par
Projections permettant de sélectionner les colonnes
composant chaque fragment.
La fragmentation verticale permet de
décomposer une table par projections comme illustre la
figure 11.b. Afin de ne pas perdre d’informations, la table
initiale doit pouvoir être recomposée par jointure des
fragments. Une telle fragmentation est adaptée au
découpage fonctionnel, chaque fonction Fi gérant des
attributs Ai1, Ai2, … Ain.
Figure 11 : techniques de fragmentation

Enfin, une table peut être répliquée sur différents dites.
II.6.2. SCHEMA D’ALLOCATION

Chaque fragment est placé ou répliqué sur
un site. Après la fragmentation, le problème qui se pose
est celui de la localisation du fragment. Un schéma doit
être élaboré afin de déterminer la localisation de chaque
fragment.

34
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, pour
minimiser les transferts de données entre les sites.
II.7. GESTION DES TRANSACTIONS

II.7.1. QUELQUES DEFINITIONS D’UNE TRANSACTION
Une transaction est un traitement cohérent
et fiable.
Dans le cas des bases de données, c’est une
action qui transforme la base de données 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. Une transaction a quatre types
d’opérations : un début de transaction, la lecture,
l’écriture et enfin la terminaison.

35
Une transaction désigne un ensemble de

requête (ou moins une appliqué sur la base de données et
respectant les propriétés ACID (atomicité, cohérence,
isolation, durabilité).
II.7.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 (si elle est interne le
mécanisme d’interruption se nomme abort), 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.

36
II.7.3. Formalisation du concept de la transaction

Même si le concept est intuitivement clair, il
peut être utile de le préciser de façon plus formelle :
Une transaction est un ensemble d’opération
menée sur une base de données ;
Ces opérations peuvent être la lecture ou
l’écriture ;
Une opération est atomique, elle est donc
une unité indivisible ;
Une transaction se termine soit par un
commit, soit par un abort ;
Deux opérations distinctes peuvent
s’exécuter en même temps. Une opération de lecture et
d’écriture doit s’exécuter l’une après l’autre ;
La dernière opération effectuée est la
terminaison.
II.7.4. 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.
A. Atomicité
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.
Cette propriété signifie qu’une transaction
37
est traitée comme une seule opération. Toutes les actions

d’une transaction sont donc menées à bien ou aucune
d’entre elles. C’est le tout ou rien. Après un problème, le
SGBD doit terminer la transaction commencée, soit
défaire tout ce qui a été entrepris. On peut rencontrer
deux types de problèmes durant l’exécution de la
transaction :
La transaction peut s’interrompre d’elle-
même. Par exemple, dans le cas où l’écriture dépend
d’une condition sur une lecture non remplie, la transaction
est annulée de façon interne. On parle d’abord, le SGBD
peut également lui-même décider d’interrompre la
transaction en cours (dans le cas d’un inter - blocage par
exemple). On parle alors de reprise de transaction
recorvery).
La transaction peut également être
interrompue en raison d’une panne du système ou du
réseau. On parle dans ce cas de reprise de crash.
La différence importante entre les deux types
d’interruption est qu’en cas de panne, l’information
stockée de façon volatile (typiquement la mémoire vive)
peut être perdue. On génère donc souvent un fichier «log»
qui permettra de savoir quelles modifications ont été
effectuées et si elles ont été effectuées jusqu’à leur terme.

38
B. Cohérence
La transaction doit faire passer la base de
données d’un état cohérant à un autre cohérant. En cas
d’échec, l’état cohérent initial doit être restauré. La
cohérence d’une transaction est simplement sa
correction. En d’autres termes, une transaction est un
programme correct qui amène la base de données d’un
état cohérent à un autre état cohérent. La vérification de
la cohérence des transactions est le rôle du contrôleur de
sémantique. Assurer la cohérence des transactions est
l’objectif des mécanismes de contrôle de la concurrence.
Dans un système répliqué, pour garantir la
cohérence sur chaque site et entre chaque site,
l’information doit circuler sous la même forme et dans le
même ordre que sur le site source. En claire, il faut copier
des transactions dans l’ordre d’exécution choisi sur le site
source.
C. Isolation
Les résultats d’une transaction ne doivent
être visibles aux autres transactions qu’une fois la
transaction validée. Ceci d’éviter les interférences avec
les autres transactions. L’isolation est la propriété qui
impose à chaque transaction en train de s’exécuter ne
peut donc révéler ses résultats à d’autres transactions
concurrentes (simultanées) avant d’avoir d’effectuer son
commit.

39
D. Durabilité
Dès qu’une transaction valide des
Modifications, le système doit garantir que les
modifications seront conservées en cas, de panne. La
durabilité est la propriété qui garantit lorsqu’une
transaction a effectué son commit, le résultat sera
permanent et ne pourra pas être effacé de la base de
données quelques soient les pannes du système
rencontrées.
Comme vu ci-dessus, ces propriétés doivent
être garanties dans le cadre d’un système réparti. En
particulier, il faut assurer que toutes les mises à jour d’une
transaction sont exécutées sur tous les sites ou qu’aucune
ne l’est. Le problème essentiel à résoudre est le risque
d’incohérence lié au contrôle reparti : chaque site peut
décider de valider ou d’annuler une transaction, il faut
donc coordonner les validations.
II.7.5. Contrôle de concurrence
Plusieurs utilisateurs accèdent simultanément
à la BD. L’accès concurrent permet de partager les
ressources matérielles et d’améliorer les performances
d’accès aux données.
Le contrôle de concurrence est un mécanisme du SGBD,
qui contrôle l’exécution simultanée de transactions de
manière à produire les mêmes résultats qu’une
exécution séquentielle. Cette propriété est la
sérialisabilité. Une exécution d’un ensemble de

40
transactions est dite sérialisable si elle donne pour chaque

transaction participante, le même résultat que l’exécution
en séquentiel de ces mêmes transactions.
II.8. Les mécanismes utilisables
II.8.1. Les estampille
Les estampilles permettent d’installer un
ordre total entre les actions, et ainsi de les sérialiser.
L’estampille est donc un identifiant unique des
transactions qui permet en plus de les ordonner.
Chaque transaction est repérée par un numéro d’ordre
unique dans le système. C’est le couple (valeur compteur
: horloge locale, numéro du site).
L’inconvénient majeur est la difficulté de
synchroniser des sites de différentes horloges.
II.8.2. Verrouillage
La technique la plus répandue pour sérialiser
les transactions est basée sur l’utilisation de verrous. On
impose que l’accès aux données se fasse de manière
mutuellement exclusive.
1. Inter-blocages
Toute méthode basée sur le verrouillage peut
donner des inter- blocages lorsque deux transactions
s'entre-attendent. Pour illustrer ce cas, on peut prendre un
exemple : Une transaction Ti détient un verrou en lecture
ou en écriture sur la donnée x et une autre transaction Tj

41
détient un verrou en lecture ou en écriture sur la donnée

y.
La transaction Ti attend un verrou en écriture
sur la donnée y et la transaction Tj attend un verrou en
écriture sur la donnée x. Il y a dans ce cas un interblocage.
Un outil de grande utilité dans l'analyse des
inter-blocages est le graphe des attentes. Les nœuds du
graphe des attentes sont des transactions simultanées et
les arcs orientés qui les relient représentent l'attente d'une
transaction pour une autre. Grâce à cette
représentation, il est facile de caractériser les
interblocages : ce sont les cycles sur le graphe. Dans un
environnement réparti, les inter-blocages peuvent mettre
en jeu différents sites. Le graphe des attentes local est
donc insuffisant et il faut également en maintenir un au
niveau global.
La solution est d’annuler des transactions

concurrentes jusqu’à la suppression de cycles, et de les
reprendre plus tard.

42
2. Validations en deux phases.

a) Principe
Le protocole de validation en deux phases a
été proposé afin de coordonner l’exécution des
commandes «COMMIT» par tous les sites participants à une
transaction. Le principe consiste à diviser la validation en
deux phases.
La phase 1 réalise la préparation de l’écriture
des résultats des mises à jour dans la BD et la centralisation
du contrôle. La phase 2, réalisée seulement en cas de
succès de phase 1 intègre effectivement les résultats des
mises à jour dans la BD répartie. Le contrôle du système
réparti est centralisé sous la direction d’un site appelé
coordinateur, les autres étant des participants. Nous
résumons ces concepts ci-dessous.
Notion 1. Protocole de validation en deux
Étapes (TWO STEP commit). C’est un protocole permettant
de garantir l’atomicité des transactions dans un système
reparti. Composé d’une préparation de la validation et de
centralisation du contrôle et d’une étape d’exécution.
Coordinateur de validation (commit
coordination). Nœud d’un système réparti qui dirige le
protocole en centralisant le contrôle.
Participant à la validation (commit
participant). Nœud d’un système réparti qui exécute des
mises à jour de la transaction et obéit aux commandes de
préparation, validation ou annulation du coordinateur.

43
b) Début et fin d’une transaction

La fin d’une transaction est définie par l’un
des ordres ci-dessous : COMMIT ou ROLLBACK.
Une transaction commence à l’ouverture
de la session ou à la fin de la précédente transaction,
il est donc claire de voir que la première transaction
débute au lancement du programme, il n’existe pas
donc d’ordre implicite pour le début de la transaction.
COMMIT : termine une transaction par la
validation des données. A ce niveau, les modifications sont
définitives, sauvegardé dans une base de données et
peuvent être accessibles par d’autres utilisateurs (tous).
(FIGURE1)
ROLLBACK : termine une transaction en
annulant toutes les modifications de données effectuées.
(FIGURE 1)
c) Structure d’une transaction
Il est possible de subdiviser en plusieurs
44
étapes une transaction en sauvegardant les

modifications à la fin de chaque étape, tout en gardant la
possibilité de valider ou d’annuler une partie ou toutes les
mises à jour à la fin de la transaction.
II.9. REPLICATION DES DONNEES

II.9.1. Définition
La réplication est un processus qui consiste à
copier et à mettre à jour les objets (tables, information,
index,…) entre différents sites qui peuvent être éloigné
géographiquement. Cette mise à jour peut s’enclencher
automatiquement ou manuellement.
Les techniques de réplication permettent la
gestion de copies multiples pouvant diverger c’est à dire
présenter des valeurs différentes à un instant donné, mais
convergeant vers les mêmes valeurs à termes.
Nous examinons ci – dessous les différentes

45
formes de réplication possibles et les techniques de

gestion de la cohérence des copies associées.
La réplication utilise la technologie de base
de données distribuée pour partager les données entre
multiples sites mais une base de données répliquée et une
base de distribuée sont différentes. Pour les bases de
données distribuées, les données sont disponibles à
plusieurs endroits mais une table particulière réside à un
seul site. La réplication signifie que les mêmes données
sont disponibles à multiples endroits.
II.9.2. Avantage de la réplication
La réplication améliore les performances et
augmente la disponibilité des données. Grâce à la
réplication, les lectures sont exécutées sur le site disposant
de la copie la plus proche du client ce qui peut éviter des
transferts inutiles, par exemple si le client dispose d’une
copie. Aussi bien pour les lectures que pour les écritures, la
réplication permet d’éviter le goulot d’étranglement que
constitue le serveur unique en partageant la charge.
La réplication favorise aussi d’une part les lectures qui sont
alors locales, et d’autres par la résistance à la panne.
Du point de vu disponibilité, lors d’une panne
d’un serveur, on peut se replié sur un autre disposant d’une
copie des données.
II.9.3. Inconvénient de la réplication
Si la réplication présente de nombreux

46
avantages, les problèmes soulevés sont multiples. Tout

d’abord, il faut assurer la convergence des copies. Si les
copies peuvent être différentes à un instant donné, elles
doivent converger vers le même état cohérent où toutes
les mises à jour sont exécutées partout dans le même
ordre. Ensuite, il faut offrir la transparence de gestion aux
utilisateurs. Les clients doivent croire à l’existence d’une
seule copie : en conséquence, le SGBD doit assurer la
diffusion des mises à jour aux copies et le choix de la
meilleure copie lors des accès.
Exemple d’application de la réplication
En suivant ce principe, une entreprise
disposant de plusieurs bureaux régionaux pourra ainsi
conserver les données du siège national. Les utilisateurs
mobiles équipés de pocket PC pourront travailler toute la
journée, en étant déconnecté et réaliser le soir une
réplication dans le but de fusionner leur enregistrement
avec ceux de la base de données principale.
II.10. TECHNIQUES DE DIFFUSION DES MISES A 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 celle 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

47
nécessiter un ordonnancement identique des mises à jour

sur tous les sites afin d’éviter les pertes de mises à jour.
Mise à jour synchrone et asynchrone
a.1. Mise à jour synchrone (Synchronous update)
Mode de distribution dans lequel toutes les
sous opérations locales effectuées suite à une mise à jour
globale sont accomplis pour le compte de la même
transaction.
a.1.1 Force du mode de distribution synchrone
Dans le contexte des copies, ce mode de
distribution est très utile lorsque les mises à jour effectuées
sur un site doivent être prises en compte immédiatement
sur les autres sites.
Elle garantit l’absence des conflits entre les
différents sites, en effet pas de moment dont les données
sont différents entre les sites.
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.
a.1.2 Faiblesse du mode de distribution synchrone
Les inconvénients sont cependant multiples,
ce qui conduit beaucoup d’application à éviter la gestion
des copies synchrones. Ce sont d’une part la nécessité de
gérer les transactions multi listes coûteuses en ressources ;
demande plus de ressources réseaux et matérielles, et

48
d’autres parts la complexité des algorithmes de gestion de

concurrence et de panne d’un site c’est pour cela que
l’on préfère souvent le mode de mise à jour asynchrone
(encore appelé mise à jour différé)
b.2 Mise à jour asynchrone (Asynchronous update)
Mode de distribution dans lequel 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é : les transactions de report peuvent
être lancées dès que possible où à des instants fixés, par
exemple le soir ou à la fin de la semaine.
b.2.1 Force du mode de distribution asynchrone

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 la réplication synchrone, ce qui implique une
meilleure disponibilité et une meilleure performance.
b.2.1 Faiblesse du mode de distribution asynchrone
Les inconvénients sont bien sûr que l’accès à
la dernière version n’est pas garanti, ce qui limite les
possibilités de mise à jour.
Possibilité d’avoir des conflits avec les
données, dont voici les trois types :

49
• Conflit de mise à jour : deux ou plusieurs sites

réalisent de transaction de modification sur la
même ligne pratiquement en même temps.
• 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é.
• 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 mise à jour ou supprimer.
Réplication asymétrique (Asymétrie replication)
La technique de gestion de copie basée sur
un site primaire seul autorisé à mettre à jour et chargé de
diffuser les mises à jour aux autres copies dites secondaire.
Réplication symétrique (Symetric replication)
Technique de gestion de copies où chaque
copie peut être mise à jour à tous instant et assure la
diffusion des mises à jour aux autres copies.
REPLICATION ASYMETRIQUE
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

50
asymétrique rompt la symétrie entre les copies en

distinguant un site chargé de centraliser les mises à jour.
C’est une technique de gestion de
copies basée sur un site primaire seul autorisé à mettre
à jour et charger, de diffuser les mises à jour aux autres
copies dites secondaires.
Le site primaire effectue les contrôles et
garantit l’ordonnancement correct de mises à jour. Ce
mode de réplication convient bien aux applications à
responsabilité centralisée. Il permet la distribution de
l’information centralisée, par exemple la diffusion des
catalogues, des listes de prix, etc. Il permet aussi la
diffusion de données vers des entrepôts pour l’aide au
décisionnel et l’historisation.
Le choix d’une technique asymétrique est
orthogonal au choix d’un mode de diffusion synchrone ou
asynchrone des mises à jour : on peut donc distinguer
l’asymétrique synchrone et l’asymétrique asynchrone.
La première technique (l’asymétrique
synchrone) :
Toute mise à jour est d’abord appliquée à la
copie primaire (site primaire), puis diffusée en temps réel
vers les sites secondaires.

51
La deuxième (l’asymétrique asynchrone)

Toute mise à jour est d’abord appliquée à la
copie primaire (site primaire), puis diffusée en temps différé
vers les sites secondaires. Dans les deux cas, des problèmes
surviennent lorsque le site primaire tombe en panne.
Figure 6 : Mises à jour de copies asymétrie asynchrones

52
Un problème de la gestion de copie

asymétrique est donc la panne du primaire Dans ce cas,
il faut choisi un remplaçant si l’on veut continuer les mises
à jour.
Celui-ci peut être fixé par l’administrateur
ou élu par un protocole spécifique de vote majoritaire.
On aboutit alors à une technique
asymétrique mobile dans laquelle le site primaire change
dynamiquement selon des critères qui peuvent être liés à
l’application. Le droit de mise à jour se déplace de site en
site, par exemple au fur et en mesure de l’évolution des
données.
REPLICATION SYMETRIQUE
Technique de gestion de copies où chaque
copie peut être mise à jour à tout instant et assure la
diffusion des mises à jour aux autres copies.
A l’opposé de la réplication asymétrique,
la réplication symétrique ne privilégie aucune copie. Elle
permet les mises à jour simultanées de toutes les copies par
les transactions différentes.

53
Convergence de copies symétriques

La convergence de copies asymétriques est

54
assurée par le site maître. Celui–ci règle les problèmes de

concurrence et envoie les mises à jour dans l’ordre où ils
les appliquent aux sites secondaires. Encore faut–il que ces
derniers appliquent les mises à jour dans le bon ordre, ce
qui peut présenter quelques difficultés facilement solubles.
Dans le cas de copies symétriques, la
convergence est plus difficile à assurer. En effet, les mises
à jour simultanées risquent d’être accomplies dans un
ordre différent sur une même donnée. On obtient alors
deux états différents : les copies divergent. La sérialisabilité
de l’exécution globale des transactions n’est pas
respectée, d’où la divergence.
Des techniques applicables dans le cas de
mise à jour synchrones découlent des mécanismes de
contrôle de concurrence étudiés ci – dessus. Ce sont :
La prévention des conflits par verrouillage
des copies. Le mécanisme consiste à demander à toute
transaction mettant à jour, d’obtenir un verrou en écriture
sur chacune des copies. Les risques de verrous mortels sont
alors importants si plusieurs transactions mettent à jour
simultanément. Les verrous mortels peuvent être prévenus
en ordonnant l’ordre de visite des sites.
La détection des conflits par
ordonnancement des mises à jour.
L’ordonnancement s’effectue par un
mécanisme d’estampillage ou de certification comme vu
ci – dessus. Le système doit alors utiliser des estampillages

55
synchronisés pour ne pas favoriser un site plutôt qu’un

autre.
Les risques de reprises multiples de
transactions sont importants.
Les deux mécanismes ci – dessus sont
consommateurs en ressources et seulement utilisables en
synchrone.
En asynchrone, il est impossible de défaire
des transactions validées.
Les approches proposées se contentent
alors de détecter les conflits et de reporter ceux – ci vers
l’utilisateur qui doit alors mettre en œuvre une technique
de résolutions de conflits.
PROBLEMES DE FIABILITE ET REPRISE
Afin d’améliorer la disponibilité des données
comme indiqué en objectifs, le système doit continuer à
fonctionner malgré les pannes de sites. Le problème est
qu’un site en panne ne reçoit plus les mises à jour. Lors de
la reprise, il doit se resynchroniser en demandant ou en
recevant les mises à jour qu’il a manquées. Le réseau peut
aussi se partitionner suite à des pannes de nœuds ou de
moyens de communication. Le risque est que plusieurs sites
ou groupes de sites divergents après des pannes.
Comment garantir la non divergence en
présence de panne ? Pour cela, il faut être sûr de
l’existence d’une copie à jour recevant toutes les mises à
jour.

56
Dans le contexte de copies symétriques à

mises à jour synchrone, ceci est difficile. Une solution a été
proposée basée sur le vote majoritaire. L’idée du vote
majoritaire est d’accepter la validation d’une transaction
lorsqu’une majorité de site a répondu positivement au pré
– commettre, et par suite a exécuté correctement les
mises à jour demandées. Bien sûr, un site ne peut accepter
des mises à jour et répondre positivement au pré –
commettre que s’il est en phase avec la majorité des sites.
Deux majorités ayant toujours un élément commun, ceci
garantit qu’au moins une copie a reçu toutes les mises à
jour de toutes les transactions à chaque vote accepté.
Ainsi, le réseau ne peut se diviser en partitions divergentes.
Par exemple, avec trois sites, une
transaction peut commettre dès que deux des sites ont
exécuté correctement les mises à jour de cette
transaction.
II.11. SQL SERVER

SQL Server peut gérer deux types de système

57
de données différents :
Les bases OLTP (OnLine
Transactional Processing) qui correspondent à des bases
dans lesquelles les informations sont stockées de façon
directe afin de réutiliser plus tard ces informations telles
qu’elles ont été stockées.
Les bases OLAP (OnLine Analytical
Processing) qui contiennent des informations
statistiques afin d’être capable d’extraire les informations
sous forme de cube multidimensionnel dans un but d’aide
à la décision par exemple. Les statistiques contenues dans
des bases OLAP s’appuient sur des informations contenues
dans une base OLTP.
SQL Server est une collection de
composants avec un moteur de base de données et le
client composants.

58
Le développement d’applications clientes

pour visualiser les données contenues dans le serveur peut
s’appuyer sur différentes technologies.
SQL Native Client sera adopté comme

modèle d’accès aux données dans les nouveaux
programmes écrits en VB.Net ou C# qui souhaitent

59
travailler avec SQL Server mais aussi dans les programmes

existants lorsque ces derniers souhaitent travailler avec des
éléments spécifiques à SQL Server, comme le type XML,
par exemple.
Première partie : Système Transactionnel
(OLTP)
Création d’une base de données
Lancement de SQL Server
Démarrer/SQL Server 2008/SQL
Server Management Studio.
Préciser le mode d’accès à votre server
(Authentification windows ou Authentification sql server).
Le nom de votre serveur
Pour l’authentification sql server vous devez
préciser la connexion (par exemple sa si on accède au
serveur comme administrateur) et votre mot de passe.
Voir la figure suivante :
Cliquer sur le bouton se conn

60
On obtient ensuite la figure suivante :
Création d’une nouvelle base de données

61
Se positionner le nœud racine de l’arbre. C'est-à-dire sur le

nœud base de données
Clic droit sur ce nœud base de données
Clic sur nouvelle base de données
Donner un nom à votre base de données
Clic sur le bouton ok
Voir l’acheminement de ces étapes sur les figures
suivantes :

62
Notre base de données est nommée UPCCMBM

Clic sur le bouton ok
Pour la création des tables on procède de la manière
suivante :
Cliquer sur le symbole + à côté du nœud base de données
pour voir tous ses nœuds fils,
Se positionner sur la base de données UPCCMBM
Cliquer sur le symbole + à côté UPCCMBM
Clic droit sur le nœud table
Clic sur nouvelle table
Voir les figures suivantes :

63

64
Au contraire, dans un SGBD professionnel (de

type SQL Server, Oracle, DB2 d’IBM et bien d’autres) le
schéma est fondamentalement différent : les données
sont fournies par plusieurs utilisateurs (parfois des milliers) à
travers de multiples petites transactions SQL. Ces données
sont stockées dans une ou plusieurs bases de production
continuellement remises à jour par ces transactions.

65
IIème Partie : CONFIGURER LA DISTRIBUTION

Le serveur de distribution contient la base de
données de distribution, laquelle stocke les métadonnées,
les données d'historique pour tous les types de réplication
et les transactions pour la réplication transactionnelle. Pour
définir la réplication, vous devez configurer un serveur de
distribution. Chaque serveur de publication ne peut être
affecté qu'à une seule instance de serveur de distribution
mais plusieurs serveurs de publication peuvent partager un
serveur de distribution. Le serveur de distribution utilise les
66
ressources supplémentaires suivantes sur le serveur sur

lequel il se trouve :
• Espace disque supplémentaire si les fichiers
d'instantanés de la publication sont stockés sur le
serveur de distribution, ce qui est généralement le
cas
• Espace disque supplémentaire pour stocker la base
de données de distribution
• Augmentation de l'utilisation du processeur par les
agents de réplication pour les abonnements par
envoi de données (push) exécutés sur le serveur de
distribution.
Le serveur sélectionné comme serveur de

distribution doit avoir suffisamment d'espace disque et un
processeur assez puissant pour prendre en charge la
réplication et toutes les autres activités effectuées sur ce
serveur. Lorsque vous configurez le serveur de distribution,
spécifiez les éléments suivants :
✓ Dossier d'instantanés, utilisé par défaut par tous les
serveurs de publication qui utilisent ce serveur de
distribution. Assurez-vous que ce dossier est déjà
partagé et possède les autorisations adéquates.
✓ Nom et emplacement des fichiers de la base de
données de distribution. La base de données de
distribution ne peut plus être renommée après sa
création. Pour utiliser un autre nom de base de

67
données, vous devez désactiver la distribution et la

reconfigurer.
✓ Tous les serveurs de publication autorisés à utiliser le
serveur de distribution. Si vous spécifiez des serveurs
de publication autres que l'instance sur laquelle le
serveur de distribution s'exécute, vous devez
également indiquer un mot de passe pour les
connexions des serveurs de publication au serveur
de distribution distant.
Pour la réplication transactionnelle, après
avoir configuré la distribution, il est recommandé
d'effectuer les opérations suivantes :
✓ Dimensionnez correctement la base de données
de distribution. Testez la réplication avec une
charge normale pour votre système afin de
déterminer l'espace nécessaire au stockage des
commandes. Assurez-vous que la base de données
est suffisamment volumineuse pour stocker les
commandes sans avoir fréquemment recours à
l'extension automatique. La modification de la taille
d'une base de données, est effective à l’aide de la
commande ALTER DATABASE
(Transact-SQL).
✓ Activez l'option sync with backup sur la base de
données de distribution.
SERVEURS DE DISTRIBUTION LOCAUX ET DISTANTS
Si, par défaut, le serveur de distribution est le

68
même que le serveur de publication (un serveur de

distribution local), il peut également être différent (un
serveur de distribution distant). En règle générale, vous
opterez pour un serveur de distribution distant si vous
souhaitez :
Transférer une partie du traitement vers un autre
ordinateur pour que la réplication ait une incidence
mineure sur le serveur de publication (par exemple,
s'il s'agit d'un serveur OLTP) ;
Configurer un serveur de distribution centralisé pour
plusieurs serveurs de publication.
Les serveurs de distribution distants sont plus utilisés
pour la réplication transactionnelle que pour la
réplication de fusion et ce, pour deux raisons :
Le serveur de distribution joue un rôle plus important
dans la réplication transactionnelle car toutes les
transactions répliquées sont lues et écrites dans la
base de données de distribution.
Les topologies de réplication de fusion utilisent
généralement des abonnements extraits de sorte
que les Agents s'exécutent sur chaque Abonné,
plutôt qu'ils s'exécutent tous sur le serveur de
distribution. Pour plus d'informations, consultez
S'abonner à des publications. Dans la plupart des
cas, vous devez utiliser un serveur de distribution
local pour la réplication de fusion.

69
CONFIGURATION DE LA PUBLICATION
Cette rubrique, on explique comment
configurer la publication et la distribution dans SQL Server.
Cette publication est possible à l'aide de :
➢ SQL Server Management Studio
➢ Transact-SQL ou d'objets
➢ RMO (Replication Management Objects).
➢ Utilisation de SQL Server Management Studio
➢ Configurez la distribution à l'aide de l'Assistant
Nouvelle publication ou de l'Assistant Configuration
de la distribution. Après avoir configuré le serveur de
distribution, affichez et modifiez des propriétés dans
la boîte de dialogue Propriétés du serveur de
distribution - <serveur de distribution>. Utilisez
l'Assistant Configuration de la distribution si vous
voulez configurer un serveur de distribution de telle
sorte que les membres des rôles de base de
données fixes db_owner puissent créer des
publications, ou parce que vous voulez configurer
un serveur distant de distribution qui ne soit pas
serveur de publication.
Pour configurer la distribution

70
Dans Microsoft SQL Server Management

Studio, connectez-vous au serveur qui sera le serveur de
distribution (souvent, le serveur de publication et le serveur
de distribution sont le même serveur), puis développez le
nœud du serveur.
Cliquez avec le bouton droit sur le dossier
Réplication, puis cliquez sur Nouvelle publication.
L'Assistant Configuration de la distribution

s’affiche

71
Choisissez une base de données de publication.

72
Sélectionnez un type de publication.

73
Spécifiez les données et les objets de base

de données à publier ; en option, filtrez les colonnes des
articles des tables, et définissez des propriétés d'articles.

74
En option, filtrez les lignes des articles des

tables. Pour plus d'informations, consultez Filtrer des
données publiées.

75
Définissez la planification de l'Agent d'instantané.

76
Spécifiez les informations de connexion sous

lesquelles les Agents de réplication suivants s'exécuteront
et se connecteront :
- Agent d'instantané pour toutes les publications.
- Agent de lecture du journal pour toutes les
publications transactionnelles.
- Agent de lecture de la file d'attente pour les
publications transactionnelles acceptant les
abonnements mis à jour.

77
Spécifiez le nom de la publication puis

cliquer sur terminer.

78
S'ABONNER A DES PUBLICATIONS

Un abonnement est une demande de copie
de données et d'objets de base de données d'une
publication. Il définit la publication qui sera reçue, où et
quand elle sera reçue. Lorsque vous planifiez des
abonnements, pensez à l'endroit où vous voulez qu'ait lieu
79
le traitement de l'agent. Le type d'abonnement choisi

détermine l'emplacement d'exécution de l'agent. Avec
un abonnement par envoi de données (push), l'Agent de
fusion ou l'Agent de distribution s'exécute sur le serveur de
distribution tandis qu'avec un abonnement par extraction
de données (pull), les agents s'exécutent sur les Abonnés.
Il n'est plus possible de modifier le type d'un abonnement
une fois celui-ci créé.
Abonnement Caractéristiques Cas d'utilisation

80
Abonnement Avec un Les données sont

envoyé abonnement par censées être
envoi de données, le synchronisées de façon
serveur de permanente ou à
publication propage intervalles fréquents et
les modifications à un périodiques.
Abonné sans que ce La publication
dernier en ait fait la nécessite un transfert
demande. Les en temps réel (ou
modifications presque) des données.
peuvent être L'augmentation de la
envoyées à des charge imposée au
Abonnés à la processeur d'un serveur
demande, en continu de distribution
ou selon un horaire n'affecte pas les
planifié. L'Agent de performances.
distribution ou l'Agent
Le plus souvent utilisé
de fusion s'exécute sur
avec la réplication
le serveur de
d'instantané et la
distribution.
réplication
transactionnelle.

81
Abonnement Dans le cas d'un Avec ce type

extrait abonnement par d'abonnement, les
extraction, l'Abonné données sont en
demande à recevoir général synchronisées
les modifications à la demande ou selon
apportées sur le un horaire planifié
serveur de plutôt qu'en continu.
publication. Ce type La publication compte
d'abonnement un grand nombre
permet à l'utilisateur d'Abonnés et
sur l'Abonné de l'exécution de tous les
déterminer le agents sur un seul site
moment où les ou sur le serveur de
modifications sont distribution entraînerait
synchronisées. une consommation
L'Agent de distribution excessive des
ou l'Agent de fusion ressources.
s'exécute sur Les abonnés sont
l'Abonné. autonomes, non
connectés et/ou
mobiles. Ils
déterminent à quel
moment ils se

82
connectent et
synchronisent les
modifications.
Le plus souvent utilisé
avec la réplication de
fusion.
Types d'abonnements de réplication de fusion

Tous les types de réplication permettent des
abonnements par envoi ou extraction de données. La
réplication de fusion fait la distinction entre deux types
d'abonnement : les abonnements client et les
abonnements serveur. Ces deux types d'abonnement sont
utilisables avec les abonnements par envoi ou extraction
de données. Les abonnements client sont adaptés à la
plupart des Abonnés, tandis que les abonnements serveur
sont généralement utilisés pour les Abonnés qui republient
des données vers d'autres Abonnés. Le choix de
l'abonnement a également une incidence sur la résolution
des conflits.
Abonnés non SQL Server

Oracle et IBM DB2 peuvent s'abonner à des

83
publications transactionnelles et des publications

d'instantané à l'aide des abonnements par envoi de
données.
Création d'abonnements
Pour créer un abonnement, fournissez les
informations suivantes :
✓ Nom de la publication.
✓ Le nom de l'Abonné et de la base de données
d'abonnement ;
✓ Si l'Agent de distribution ou l'Agent de fusion
s'exécute sur le serveur de distribution ou sur
l'Abonné ;
✓ Si l'Agent de distribution ou l'Agent de fusion
s'exécute en continu, selon un horaire planifié ou à
la demande seulement ;
✓ Si l'Agent d'instantané doit créer un instantané initial
pour l'abonnement et si l'Agent de distribution ou
l'Agent de fusion doit appliquer cet instantané sur
l'abonné ;
✓ Les comptes sous lesquels l'Agent de distribution ou
l'Agent de fusion s'exécute;
Pour la réplication de fusion, le type
d'abonnement : serveur ou client.
Pour configurer la distribution
Dans Microsoft SQL Server Management Studio,
connectez-vous au serveur qui sera le serveur de
publication, puis développez le nœud du serveur.

84
Cliquez avec le bouton droit sur le dossier

Abonnement Locaux, puis cliquez sur
Nouveaux Abonnements.

85
L'Assistant Configuration de l’abonnement s’affiche

86
Choisissez la publication

87
Sélection de l’emplacement d’exécution

88
Choisissez les abonnements tout en spécifiant leurs bases

de données respectives

89
Ici on spécifie les informations de sécurité pour tous les

abonnés en cliquant le bouton avec (…)

90
Spécification de la connexion

91
Ici on planifie la synchronisation de l’agent

92

93
Ici on indique le type d’abonnement et on

définit la priorité pour la résolution des conflits.

94
Cliquer sur suivant puis Terminer pour

terminer l’abonnement.

95
RESULTAT
Ce résultat montre deux serveurs distants
MCBEN-PC\H1 et JOHN_RACHEL-PC\SQL_RACHEL.
JOHN_RACHEL-PC\SQL_RACHEL est le

96
serveur de publication qui contient la base de données

publiée, et ce même serveur s’est abonné à sa propre
publication. MCBEN-PC\H1 est le second serveur à
s’abonner à cette même publication. Les deux serveurs
reçoivent une copie de la même base de données
(miroring). A chaque mise à jour sur un de ces serveurs, la
réplication est faite dans tous les serveurs.

97
L’abonnement
BDABONH1
SERVER H1
Serveur
L’abonnement
SQL_RACHEL
BDABONJR
Transact SQL
A) Commentaire
Pour insérer un commentaire, la syntaxe est la suivante :
98
/* commentaire */
B) Variables
Les principaux types disponibles sont :
INT entier
DECIMAL(9,2) montant à 9 chiffres (décimaux) dont 2
après la virgule
REAL réel flottant codé sur 24 bits
CHAR(64) chaine de caractère de longueur fixe 64
VARCHAR(64) chaine de caractère de longueur variable
mais inférieure ou égale à 64
DATETIME date et/ou heure avec une précision de 3.33 ms
FLOAT réel à simple précision
Lorsque l’on définit une variable, on adopte la convention
de faire commencer son nom par @.
Exemple de déclaration d’une variable :
Declare @ numero int
Ecrire une commande transact sql qui donne le prix moyen
des article : Declare @moy float
Select @moy = AVG(prix) From article
Select @moy
Exemple 2
DECLARE @tva DECIMAL(3,3) SET @tva = 0.186
PRINT @tva
Exemple 3

99
WHILE
C’est la structure de contrôle répétitive qui
permet d’exécuter une série d’instructions tant qu’une
condition est vraie. WHILE condition
{instruction|bloc}
Exemple avec while
Transaction sous SQL SERVER

On dit qu’une transaction est ACID :
• Atomique, au sens où on ne peut pas la diviser en
une partie qui échoue et une partie qui réussit ;
• Consistante, au sens ou une fois la transaction
terminée, la base est de nouveau dans un état
cohérent ;
100
• Isolée, au sens où une transaction considère que,

pendant son exécution, les données qu’elle
manipule ne sont pas modifiées par une autre
transaction ;
• Durable, au sens où les modifications opérées par la
transaction sont enregistrées de façon permanente
(et recouvrables en cas de reconstruction de la
base).
La syntaxe pour délimiter une transaction est
la suivante :
BEGIN TRAN........................
une suite d’instructions
COMMIT TRAN
Exemples des transactions
Exemple 1
BEGIN TRAN UPDATE articles
SET art_prix = art_prix / 6.55957
COMMIT TRAN
Exemple 2
DECLARE @taux REAL SET @taux = 1.0 / 6.55957
BEGIN TRAN UPDATE articles
SET art_prix = art_prix * taux
COMMIT TRAN
Exemple 3
BEGIN TRAN
INSERT into client(clt_nom, clt_num)

101
VALUES (’Fricotin’, 18)

COMMIT TRAN
Exemple 4
BEGIN TRAN DELETE FROM client
WHERE ville = ‘Mbuji mayi’
COMMIT TRAN
Procédures stockées
En pratique, les programmes qui utilisent les
données d’une base ne font pas directement appel aux
transactions, mais plutôt à des procédures auxquelles ils
peuvent passer des arguments.
Syntaxe
Le langage Transact-SQL permet de
programmer ces procédures selon la syntaxe suivante :
CREATE PROC ... le nom de la procédure
(...) les paramètres d’entrée et de sortie séparés par des
virgules
AS
DECLARE ... les variables locales
BEGIN
... les instructions, les transactions
END
Exemple 1
CREATE PROC InfoDuClient
(@numero INT) AS

102
SELECT * FROM clients

WHERE clt_num = @numero
Nota pour executer une procedure stockée,
on utilise la commande Exec
Par exemple pour executer la procédure ci-
haut, on écrira : Exec infoDuClient 12
Exemple 2
CREATE PROC NbClients (@resultat INT OUTPUT) AS
SET @resultat = (SELECT COUNT(*) FROM clients)
CHAPITRE III LE COMMERCE ELECTRONIQUE

III.1. DEFINITIONS.
L’expression « commerce électronique », en
abrégé CE (ou e-commerce) décrit de nombreux usages
de la technologie moderne des télécommunications et
de l’information. Une définition exhaustive engloberait
toute forme d’activités commerciales faisant appel à un
média électronique. Les transactions non commerciales
par voie électronique n’entrent pas dans la définitions du
CE.
Réduit à sa plus simple expression, le CE

103
consiste en un échange d’informations qui aboutira à un

échange de monnaie, de biens ou de services par voies
électroniques. Lorsqu’on dit les mots « commerce
électronique », l’idée de ventes par Internet vient
immédiatement à l’esprit des gens.
De façon générale, c'est la livraison de
renseignements, de produits, de services ou de paiements
par téléphone, ordinateur ou autre moyen automatisé.
Plus précisément, il s'agit de transactions d'une entreprise
vers le consommateur et d'une entreprise vers une
autre entreprise effectuées par des réseaux informatiques
publics, tel Internet.
III.2. Analogie entre commerce électronique et
commerce traditionnel
De nos jours, l’Internet devient de plus en
plus l’espace de libre échange pour les entreprises du
monde et un supermarché cybernétique destiné aux
particuliers.
Du point de vue commercial, Internet se présente comme
le successeur logique de l’évolution du marché. Le
commerce n’a cessé de s’étendre. De la société de
production locale (exploitation directe) à une société de
service, du petit marché local, aux commerces du centre-
ville, puis aux grands magasins, puis à la surface
commerciale en dehors des zones habitables, et enfin à
l’achat par correspondance. Et quand la situation
géopolitique l’a permis, la mondialisation et la

104
globalisation du marché ont confirmé Internet comme le

mode marchand de l’avenir. Du point de vue du
consommateur, rien n’est plus simple qu’acheter depuis
chez soi, n’importe où dans le monde. Du point de vue du
vendeur, les intérêts sont multiples :
✓ Vaste clientèle potentielle non limitée
géographiquement ;
✓ Coût de diffusion des informations réduit ;
✓ Frais d’exploitation réduits, concentration des lieux
de stockage dans des zones décentralisées
;
✓ Suppression éventuelle des intermédiaires entre
producteur et consommateur.
III.3. Forme de commerce électronique
Le commerce électronique ou e-
commerce désigne l'échange de biens et de services
entre deux entités sur les réseaux, notamment Internet.
Il y a trois sortes de transactions
électroniques :
a) Le Business to Business (B2B)
Cette forme de CE implique des
transactions entre deux entreprises (on dit aussi B2B pour
business to business). Ce type de commerce électronique
est moins médiatisé. Cisco Systems, qui crée une grande
partie de l'infrastructure physique d'Internet permettant
aux entreprises de communiquer est une entreprise "B2B".

105
b) Le consumer to consumer (C2C)

Celle-ci est une forme de commerce
électronique qui a connu un succès important ces
dernières années est celle qui implique un rapport direct
entre consommateurs finaux (ou C2C, pour consumer to
consumer). Les exemples les plus connus de ce type
d'entreprise sont eBay aux Etats-Unis ou iBazar en France.
eBay et iBazar permettent à leurs clients de vendre des
objets par des enchères publiques et prélèvent une
commission pour chaque objet vendu.
c) Le Business to consumer (B2C)
Celle-ci concerne toutes transactions ayant
lieu entre une entreprise et un client (on appelle ce type
de commerce électronique B2C pour business to
consumer) ; c'est ce genre de transaction qui vient en
premier a l’esprit lorsqu'on pense au commerce
électronique. Amazon est par exemple une entreprise
"B2C". Amazon permet aux particuliers de trouver et
d'acheter tout ce qui les intéresse en matière de livres, de
CD, d'électronique et de vidéo. Le "B2C" peut s'appliquer
à des services aussi bien qu’à des produits.
Principe de fonctionnement
L’exemple ci-dessous illustre une commande d’un
ordinateur via le réseau Internet (commande en ligne).

106
1. Recherche du produit : Quels sont les modèles de

PC disponibles ? Quelles sont les caractéristiques
du premier modèle présenté ?etc.
;
2. Réception d’informations (à chaque recherche, il y
a réception) ;
3. Commande de l’ordinateur choisi et transmission du
numéro de carte de crédit ;
4. Vérification de l’identité du client auprès de
l’organisme d’authentification ;
5. Vérification de la solvabilité du client auprès de
l’organisme bancaire ;
6. Confirmation de la commande au client
Les étapes 4 et 5 sont transparentes pour

107
le client mais font bien partie de sa transaction

électronique.
L’architecture de paiement électronique
- Cardholder : consommateur : personne autorisée à

disposer d’une carte de paiement (MC, Visa,
...) fournie par un fournisseur (issuer)
- Merchant : marchand : personne qui vend des biens
ou des services au consommateur via un site Web
ou un mail électronique. Un marchand qui accepte
les cartes de paiement doit être en relation avec un
acquéreur (acquirer)
- Issuer : fournisseur (banque de l’acheteur) :
institution financière qui a fourni la carte au

108
consommateur. Typiquement les comptes sont

ouverts par mail ou par la personne
directement. C’est le fournisseur qui est
responsable du paiement de la dette du
consommateur
- Acquirer : acquéreur (banque du marchand) :
institution financière qui établit un compte avec un
marchand, fournit les autorisations de paiement et
gère les paiements. Le marchand accepte
généralement plusieurs marques de carte de crédits
mais préfère ne pas fonctionner avec de multiples
associations de banque ou de consommateurs
individuels. L’acquéreur fournit les autorisations au
marchand lorsqu’une certaine carte est active et
que la demande ne dépasse par la limite de crédit
qui lui est autorisée.
- Payment gateway (passerelle de paiement) : il
s’agit d’une fonction opérée par l’acquéreur ou un
tiers désigné qui transmet les messages de paiement
du marchand. Il s’agit d’une interface entre SET et le
réseau existant de paiement par carte. Le
marchand échange des messages SET avec ce
gateway à travers internet, tandis que le gateway a
une connexion directe vers l’acquéreur financier
manipulant le système.

109
- Certification authority : autorité qui fournit les

certificats pour les propriétaires de carte, les
marchands et les gateways de paiement.

TBDR - L3 Info Upcc

Transféré par

Droits d'auteur :

Formats disponibles

TBDR - L3 Info Upcc

Transféré par

Informations du document

Titre original

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

TBDR - L3 Info Upcc

Transféré par

Droits d'auteur :

Formats disponibles

1

CHAPITRE I. L’ARCHITECTURE CLIENT – SERVEUR

Simon MPOLESHA TSHIAMALA

C'est aussi pour faciliter le partage et l'accès simplifié aux

Figure 1 -Exemple d'architecture moderne des années 90.

Simon MPOLESHA TSHIAMALA

Le client serveur étant un mode de

I.2. TECHNIQUES DE DIALOGUE CLIENT – SERVEUR

Simon MPOLESHA TSHIAMALA

Le client serveur est avant tout une

Simon MPOLESHA TSHIAMALA

Notion 4 : Réponse (Reply)

Simon MPOLESHA TSHIAMALA

Figure 2 architectures client server

Les diagrammes de classes

L’identification des clients et des serveurs

Simon MPOLESHA TSHIAMALA

Le dialogue client-serveur nécessite

Simon MPOLESHA TSHIAMALA

Le dialogue asynchrone permet au client

Simon MPOLESHA TSHIAMALA

appelée client-serveur de présentation. Elle peut être

Figure 3 -Répartition des fonctions selon le type de client-serveur.

Simon MPOLESHA TSHIAMALA

recherche et mise à jour, souvent exprimée avec le

Simon MPOLESHA TSHIAMALA

architecture (cf. figure 5) sont les suivants :

Simon MPOLESHA TSHIAMALA

Figure 4 - Les composants de l'architecture client-serveur de données.

développer des bibliothèques de procédures

Simon MPOLESHA TSHIAMALA

modèles de coûts paramétrés. Ceci permet de

Le client demande une ressource et le

Simon MPOLESHA TSHIAMALA

I.5.2 Architecture Client server trois tiers (ou à trois

Le client: le demandeur de ressources

Le serveur secondaire (généralement un

Simon MPOLESHA TSHIAMALA

d’intermédiaire entre les logiciels pour permettre et

Exemple d’un middleware

Simon MPOLESHA TSHIAMALA

cliente (sous Ms Windows) et d'un driver correspondant au

Simon MPOLESHA TSHIAMALA

I.6.3. Les fonctions d’un Middleware

Les interfaces applicatives et les transporteurs

Simon MPOLESHA TSHIAMALA

I.7. Les contraintes de l'entreprise

Simon MPOLESHA TSHIAMALA

nouvelles manquent cruellement de temps, et la

CHAPITRE II. BASE DE DONNEES REPARTIES

Simon MPOLESHA TSHIAMALA

immense. La recherche en bases de données réparties

Simon MPOLESHA TSHIAMALA

bases. Il fournit aux clients SGBDR l’illusion que l’ensemble

Simon MPOLESHA TSHIAMALA

Nous précisons les objectifs des SGBDR qui se

Simon MPOLESHA TSHIAMALA

II.3.2.2. Transparence à la localisation des données

Simon MPOLESHA TSHIAMALA