1 - Free

S26 – Client/Serveur
Cours n°2
TSIG2
ALSI
CLIENT / SERVEUR DE DONNEES DISTRIBUEES
(BASE DE DONNEES REPARTIES)
1. INTRODUCTION
Les Modèles Organisationnels des Traitements Analytiques (MOTA) permettent de mettre en
évidence les acteurs, les sites et les postes de travail ainsi que les données manipulées.
Acteur, site, poste de travail
Un type d'acteur est une personne exerçant une fonction type définie dans l'entreprise : la
secrétaire, le représentant, etc.
Un type de site est un regroupement géographique ou fonctionnel d'acteurs : une agence, le
siège, le service comptable, etc.
Un type de poste de travail est le rapprochement entre un type de site et un type d'acteur : une
secrétaire dans une agence …
Par abus de langage, on parlera tout simplement d'acteur, de site et de poste de travail.
Opération organisationnelle
Il s'agit d'un traitement exécuté entièrement par un seul poste de travail.
Ce traitement doit être d'une seule nature : conversationnel, batch, manuel.
On décompose des opérations conceptuelles en opérations organisationnelles chacune
effectuée par un poste de travail, en une seule fois, et d’une seule manière.
Démarche (simplifiée)
Pour chaque poste de travail ou site, il va falloir prendre en compte toutes les opérations
organisationnelles concernant le poste ou site afin de lister toutes les données manipulées (au
sens large) par le poste ou au niveau du site ainsi que le type de manipulation effectuée
(consultation, ajout, modification, suppression).
Toute cette démarche n'est pas du tout au programme.
On partira donc toujours de la connaissance des besoins d'accès aux données par chaque poste
de travail ou chaque site.
Exemple : la gestion d'une bibliothèque.
L'application de gestion d'une bibliothèque est utilisée sur différents postes de travail
(l'accueil, les bibliothécaires, le comptable…) et se compose de plusieurs tables (adhérents,
livres, emprunts, règlements…).
Pour définir l'implantation de ces différentes tables, il est nécessaire de savoir que :
. Le personnel de l'accueil enregistre les nouveaux adhérents et peut visualiser les livres.
. Les bibliothécaires enregistrent les nouveaux livres et les emprunts et ont besoin de consulter
les adhérents.
. Le comptable enregistre les règlements et modifie la date de fin de l'adhésion dans la table
des adhérents.
1
S26 – Client/Serveur
Cours n°2
TSIG2
ALSI
 Pour répondre au mieux aux besoins d'accès aux données et plus généralement aux besoins
des applications, nous allons nous poser un certain nombre de questions quant à l'architecture
logicielle à mettre en place :
- Quels sont les outils à notre disposition ?
- Avec ces outils, quelles sont les solutions existantes pour implanter les données et
les traitements de l'application ?
- Où placer les tables ? Sur chaque machine ? Sur un serveur ? Sur les deux ?
- Quels sont les critères sur lesquels nous allons nous baser pour choisir le lieu
d'implantation des tables?
2.
DU PARTAGE DES INFORMATIONS A LA REPARTITION DES DONNEES
2.1.
1ère solution : Les fichiers partagés
Dans un contexte multi-utilisateurs, plusieurs personnes peuvent utiliser simultanément un
même fichier. Le fichier se trouve sur un disque partagé d'un serveur et il est accessible par
différents postes de travail simultanément.
Inconvénients :
- la consistance des données n'est pas toujours assurée.
Lors de la modification d'un enregistrement, les données sont chargées en mémoire
vive. Les modifications opérées par l'utilisateur sur cet enregistrement sont donc
effectuées dans cette mémoire et ne sont effectivement enregistrées sur disque que
lorsque l'utilisateur valide ses modifications. Si deux utilisateurs modifient le même
enregistrement au même moment, seul le dernier à enregistrer ses modifications a ses
modifications prises en compte. Il y a donc perte des données.
- le réseau est fortement sollicité.
S'il y a trop de données et surtout, trop d'accès simultanés aux données (en lecture et
en écriture), les temps de réponse ne sont pas satisfaisants.
- le " deadlock " ou verrou mortel n'est pas forcément géré.
Lorsqu'une application doit modifier un enregistrement, elle le verrouille. Seulement,
il se peut que pour effectuer les modifications sur l'enregistrement, elle doive
également accéder à un second enregistrement lui-même déjà verrouillé par une autre
application en attente du 1er enregistrement verrouillé. Ainsi, Un "deadlock" se produit
quand une première application verrouille un enregistrement pour modification et
attend la libération d'un autre enregistrement verrouillé par une deuxième application
qui, elle-même, attend la libération de l'enregistrement verrouillé par la première
application.
2
S26 – Client/Serveur
Cours n°2
TSIG2
ALSI
Application X
Verrouille
Enregistrement A
DEADLOCK
Enregistrement B
Verrouille
Application Y
2.2.
2ème solution : Les SGBDR
Les SGBDR assurent l'intégralité des fonctions relatives à la confidentialité, l'intégrité, la
sécurité des données et le partage des données.
Avec les 1ers SGBD, toutes les données étaient centralisées sur un serveur.
Le besoin de rapprocher les données de l'utilisateur afin d'éviter la saturation du réseau et le
nombre très important de requêtes à traiter par une seule machine a fait émerger le besoin de
répartir les données sur plusieurs machines
Les nouveaux SGBD (SGBD capables de gérer des données réparties) et le fait que le poste
de travail soit aujourd'hui un micro-ordinateur doté d'une puissance de stockage et de
traitement ont permis la mise en place d'architectures de type client-serveur de type 5 dans
lesquelles les données sont réparties sur le serveur et les postes de travail. On parle alors de
base de données réparties.
Dans quel cas mettre en place une base de données réparties?
. quand la quantité de données à traiter est importante ce qui nuit aux performances du SGBD
et sature le réseau,
ou / et
. quand le nombre d'utilisateurs est important ce qui rend le partage de la base centrale
inefficace.
3. LES BASES DE DONNEES REPARTIES
3.1.
Définition
Une base de données réparties est un ensemble de bases de données situées sur différents
postes et apparaissant aux applications comme une seule et même base de données. Le fait
que les bases soient implantées sur des machines différentes est transparent pour l'utilisateur.
Dans une base de données répartie, on distingue, d'une part, la base de données logique et,
d'autre part, les bases de données physiques.

La base de données vue de l'utilisateur comme une seule et même base de données est
appelée base logique.

Chaque base de données regroupée au sein d'une base logique est appelée base physique.
3
S26 – Client/Serveur
Cours n°2
TSIG2
ALSI
BASE LOGIQUE
Base
physique A
Base
physique B
Base
physique C
Un modèle logique des données réparti précise l'implantation des données permanentes sur
chacun des postes de travail d'un système. Le MLD réparti est composé de 2 à n MLD locaux.
Chaque MLD local est propre à un type de poste de travail.
3.2. Techniques de distribution des données
Les techniques de distribution (également appelées techniques de répartition) des données du
MLD réparti sont de deux types :
1 - La distribution dite intégrale :
 avec segmentation des données au niveau table :
Exemple : au niveau d'une table, la segmentation (ou fragmentation) peut être
horizontale (distribution des tuples) ou verticale (distribution d'attributs).
La segmentation horizontale est assez répandue, elle va par exemple permettre à une
entreprise installée dans plusieurs régions d'implanter dans chaque région (donc au
plus près des utilisateurs) les données (clients …) relatives à la région. Par exemple,
les clients de Paris se trouvent dans une table sur le site de Paris tandis que ceux de
Dijon se trouvent dans une table sur le site de Dijon.
La segmentation verticale est très peu répandue.
 sans segmentation au niveau table : on parle également de distribution intégrale si
on choisit de mettre les différentes tables de la base logique dans des bases physiques
différentes sans pour autant faire de la segmentation au niveau table.
2 - La distribution par réplication qui consiste à dupliquer les données à partir d'un
site d'origine par envoi de copies vers des sites de réplication.
Ces deux types de distribution peuvent être combinés, c'est le cas par exemple quand on
fragmente horizontalement une table dans plusieurs régions et qu'on souhaite avoir une
consolidation des différentes parties de la table au niveau du siège.
Quand il y a répartition de données, une requête émise par un client peut entraîner l'exécution
de requêtes sur plusieurs sites afin d'assurer la cohérence des données.
4
S26 – Client/Serveur
Cours n°2
TSIG2
ALSI
 Il peut s'agir de requêtes de consultation sur le site distant (cas 1): c'est le cas pour vérifier
une contrainte d'intégrité référentielle.
 Il peut également s'agir de requêtes de mise à jour (au sens large) sur le(ou les) site(s)
distant(s) (cas 2) : c'est le cas quand il y a duplication des données, il faut assurer la
propagation des mises à jour. Deux types de MAJ peuvent être utilisées :
- soit la MAJ synchrone (méthode PUSH) : la mise à jour des copies est assurée en
temps réel
Avantage : données toujours à jour et intègres.
Inconvénient : nécessaire disponibilité du réseau.
-
soit la MAJ asynchrone (méthode PULL) où les modifications sont propagées à
intervalles réguliers dans les copies ou bien à la demande d'un site répliquat (site sur
lequel figure une copie).
Avantage : les sites peuvent être indisponibles (sans que cela empêche les MAJ).
Inconvénient : il faut travailler avec des données moins "fraîches".
Remarques :
. La réplication peut être manuelle. Dans ce cas, c'est l'administrateur qui la demande
explicitement.
. Il est possible d'autoriser la réplication symétrique (le site ou le poste devient
alternativement copie ou référence).
4.
MISE EN ŒUVRE DE LA REPARTITION DES DONNEES SOUS ORACLE 8
L'accès à des données distantes s'effectue au moyen de liens base de données (DATABASE
LINK).
4.1.
Cas de distribution sans réplication
Il faut écrire des triggers pour vérifier les contraintes d'intégrité référentielle car il est
impossible de poser une contrainte déclarative de clé étrangère (FOREIGN KEY) faisant
référence à une clé primaire distante.
Les triggers sont vulnérables aux pannes de réseau. En cas d'erreur dans l'exécution du trigger,
l'ordre ne pourra être effectué.
4.2.
Cas de distribution avec réplication
Sous Oracle, on parle de cliché uniquement dans le cas de la réplication asynchrone sinon on
parle de copie.
4.2.1. Réplication synchrone
Elle est réalisée au moyen de triggers.
CREATE TRIGGER maj_employes
BEFORE DELETE OR INSERT OR UPDATE ON employes
FOR EACH ROW
5
S26 – Client/Serveur
Cours n°2
TSIG2
ALSI
DECLARE
...
BEGIN
IF INSERTING OR UPDATING
THEN ...
END IF;
IF DELETING
THEN ...
END IF ;
END ;
La table maître doit avoir des triggers associés.
Avec le trigger majemployes, les ordres du langage de manipulation de données (Insert,
Update, Delete) sont instantanément envoyées à la copie.
En cas d'erreur dans l'exécution du trigger, les ordres de mise à jour (au sens large) des tables
sont invalidés sur tous les sites.
4.2.2. Réplication asynchrone
Elle est réalisée au moyen de clichés (SNAPSHOTS).
Un cliché contient une copie partielle ou complète de la table maître.
Caractéristiques
 Les clichés sont moins vulnérables que les triggers.
 Les intervalles de rafraîchissement sont définis par le créateur de cliché. Le
mécanisme de rafraîchissement peut être activé automatiquement ou
manuellement.
 Les clichés simples peuvent être mis à jour avec uniquement les lignes mises à
jour depuis le dernier rafraîchissement (ils nécessitent dans ce cas un journal).
 La création des clichés doit être faite sur tous les sites où la réplication est
exigée.
 Chaque cliché doit avoir un nom différent des autres objets du schéma.
 Des index peuvent être créés sur la table créée par le cliché.
 Il ne doit pas y avoir de contraintes ou de triggers sur un cliché.
a. La création de cliché
Un cliché est dérivé d'une requête Select.
Un cliché peut contenir des données de plusieurs tables ou des sous-ensembles.
Utilisation possible du Group by, Or, And, etc...
Utiliser les mêmes options de stockage que pour la table maître en cas de copie complète.
CREATE SNAPSHOT [nomutilisateur.]nomcliche
[PCTFREE entier] [PCTUSED entier]
[INITRANS entier] [MAXTRANS entier]
[STORAGE clause de stockage]
[TABLESPACE nomtablespace]
[REFRESH
FAST | COMPLETE | FORCE
START WITH date NEXT date]
AS requête_sql;
6
TSIG2
ALSI
S26 – Client/Serveur
Cours n°2
Le rafraîchissement est défini par un intervalle qui correspond à la différence entre la date de
départ (start) et la date du prochain (next) rafraîchissement.
Dans la plupart des cas, on utilise START WITH sysdate et NEXT sysdate + n (n est un
nombre de jours).
Exemple : si n = 3, le rafraîchissement s'effectue tous les 3 jours.
n = x/24
 x heures
n = x/1440
 x minutes
n = x /(1440 * 60)  x secondes
Les privilèges nécessaires sont la création de tables (attribuer le rôle système RESOURCE qui
inclut le droit de créer des tables) et le privilège Create Any Snapshot.
Il faudra donc passer la requête grant resource, create any snapshot to nomutilisateur;
Il faut également que l'utilisateur ait le droit de faire un Select sur la table maître.
Lors de la création d'un cliché, Oracle crée :
 Une vue qui porte le nom du cliché
 Une table SNAP$_nomcliché où sont stockées les lignes définies par le cliché
 Une vue basée sur la table maître.
b. Le cliché simple
Un cliché simple contient des données issues d'une seule table.
Un index de nom PK_nomtable est créé sur la table SNAP$_nomcliché.
Exemple
CREATE SNAPSHOT emp_dept_10
REFRESH FAST
START WITH sysdate
NEXT sysdate + 7
AS
Select * from scott.emp@lien_oracle
Where deptno=10;
c. Le cliché complexe
Un cliché complexe est un cliché issu de plusieurs tables ou dont la requête utilise des
jointures, des sous-requêtes ou des Group By.
Exemple
CREATE SNAPSHOT employes
REFRESH COMPLETE
START WITH sysdate
NEXT sysdate + 1/144
AS
Select * from scott.emp@lient_oracle e, dept d
Where e.deptno=d.deptno;
7
TSIG2
ALSI
S26 – Client/Serveur
Cours n°2
d. Les méthodes de rafraîchissement
 Si on ne précise pas REFRESH …, il faudra effectuer des rafraîchissements manuels de la
façon suivante :
EXECUTE DBMS_SNAPSHOT.REFRESH('[nomutilisateur.]nomcliché','mode')
nomschéma.nomcliché est le nom du cliché à rafraîchir
le mode détermine la méthode de rafraîchissement
F : FAST
C : COMPLETE
?: option de rafraîchissement spécifiée lors de la création du cliché
 Sinon, le rafraîchissement est automatique. Il y a 3 modes de rafraîchissement
automatique :
FAST : rapide
Utilisé pour des clichés simples, il y a uniquement réplication des mises à jour (au sens large)
effectuées depuis le dernier rafraîchissement.
Utilise le journal du cliché situé sur le site maître.
COMPLETE : complet
Utilisé pour des clichés complexes et peut être utilisé pour des clichés simples en l'absence de
journal sur le site maître.
FORCE
Essaie un rafraîchissement rapide si le cliché est simple et si le journal existe sur le site
maître. Sinon exécute un rafraîchissement complet.
Cette option est la valeur par défaut, qu'il faut privilégier.
 Si Oracle rencontre une erreur lors du rafraîchissement d'un cliché, de nouvelles tentatives
ont lieu.
Après 16 tentatives, Oracle indique que le cliché ne peut pas être rafraîchi.
e. La modification de cliché
Il est possible de modifier le mode de rafraîchissement ainsi que les paramètres de stockage
d'un cliché avec la commande Alter snapshot.
ALTER SNAPSHOT [nomschema.]nomcliche
[PCTFREE entier] [PCTUSED entier]
[INITRANS entier] [MAXTRANS entier]
[STORAGE clause de stockage]
[REFRESH
FAST | COMPLETE | FORCE
START WITH date NEXT date];
8
S26 – Client/Serveur
Cours n°2
TSIG2
ALSI
f. Le journal de cliché (snapshot log)
Un journal de cliché (snapshot log) contient tous les changements d'une table maître survenus
depuis le dernier rafraîchissement d'un cliché simple. Il est utilisé pour les rafraîchissements
rapides des clichés simples. Il est à créer sur le site de référence.
CREATE SNAPSHOT LOG ON [nomschema.]nomtable
[PCTFREE entier] [PCTUSED entier]
[INITRANS entier] [MAXTRANS entier]
[STORAGE clause de stockage]
[TABLESPACE nomtablespace];
Exemple
CREATE SNAPSHOT LOG ON emp;
g. Le groupe de clichés (snapshot group)
Il est possible de mettre à jour un ensemble de clichés en créant un groupe de rafraîchissement
de clichés.
L'utilisation d'un groupe permet en plaçant la (ou les) table(s) maître(s) et les clichés dans le
même groupe de produire les réplications nécessaires.
5. REGLES ET RECOMMANDATIONS POUR CHOISIR LE LIEU D'IMPLANTATION
DES TABLES.
Les données peuvent être implantées sur les différents sites selon le critère de volume ou bien
selon des critères liés à leur utilisation.
5.1. Critères à prendre en compte
5.1.1. Volume
- données volumineuses : sur le serveur,
- données peu volumineuses : sur le serveur ou sur poste.
5.1.2. Critères liés à l'utilisation des données
Les principaux sont :
- le type d'utilisation :
données privées : données consultées et mises à jour par le site qui les accueille et
inaccessibles aux autres,
données partagées : données consultées et mises à jour par plusieurs sites,
données protégées : données mises à jour par le site qui les accueille et consultables
par les autres,
données consultables : données uniquement consultables par le site qui les accueille
(c'est par exemple le cas des historiques).
9
S26 – Client/Serveur
Cours n°2
TSIG2
ALSI
Remarque : ce qui vient d'être énoncé au niveau du type de site est également valable
au niveau du type de poste avec en plus la possibilité d'avoir des données résidant sur la
machine mais inaccessibles à certains types de postes (cas des données confidentielles).
- le mode et la fréquence d'utilisation :
données en consultation : fréquente, peu fréquente,
données en mise à jour (au sens large) : fréquente, peu fréquente. Parfois, il est
important d'aller jusqu'au niveau plus fin du type de mise à jour (modification, ajout,
suppression).
- le niveau de confidentialité (les données très confidentielles seront plutôt stockées sur le
poste de travail habilité à les manipuler).
5.2. Recommandations dans un cas simple d'architecture client-serveur
- implantation sur le poste de travail des données :
privées,
protégées,
copies de données partagées en consultation, à faible taux de mise à jour. Ces
dernières sont destinées par exemple à permettre de faire des contrôles locaux, donc à réduire
certains temps de réponse ou à permettre d'offrir des consultations ou des sélections locales
dans des listes déroulantes.
- implantation sur le serveur des données partagées en mise à jour à fort taux de mise à jour.
6. EXEMPLE DE SYNTHESE
L'illustration porte sur une banque qui dispose d'agences. On fera l'étude au niveau type de
site.
MLD global très simplifié de la gestion des comptes bancaires :
agence (numagence, nomagence, adragence, telagence)
client (numclient, nomclient, adrclient, telclient, #numagence)
compte (numcompte, soldecompte, typecompte, #numclient)
tarif (typeopération, prix)
/* Exemple : virement */
operation (numcompte, mois, an, numopération, montant, …, #typeopération)
Les clients, les comptes et les agences sont mis à jour en agence. Une agence se charge
uniquement de ses clients et de ses comptes et du tuple d'agence la concernant. Le siège
consulte les clients, les comptes et les agences.
Les tarifs sont gérés par le siège et peu mis à jour. Ils sont consultés fréquemment en agence.
Les opérations bancaires sont volumineuses, elles sont souvent créées au niveau du siège,
rarement en agence.
MLD local agence
agence (numagence, nomagence, adragence, telagence)
client (numclient, nomclient, adrclient, telclient, #numagence)
compte (numcompte, soldecompte, typecompte, #numclient)
tarif (typeopération, prix)
/* Exemple : virement */
/* on peut la nommer agence_n */
/* on peut la nommer client_n */
/* on peut la nommer compte_n */
10
S26 – Client/Serveur
Cours n°2
TSIG2
ALSI
MLD local siège
agence (numagence, nomagence, adragence, telagence)
/* consolidation */
client (numclient, nomclient, adrclient, telclient, #numagence)
/* consolidation */
compte (numcompte, soldecompte, typecompte, #numclient)
/* consolidation */
tarif (typeopération, prix)
/* Exemple : virement */
operation (numcompte, mois, an, numopération, montant, …, #typeopération)
Relation
agence
client
compte
tarif
operation bancaire
Machine type Agence
Référence pour le tuple la
concernant (fragmentation sur
numéro d'agence).
Référence pour les clients gérés
par l'agence (fragmentation sur
numéro d'agence).
Dossier (référence + copie) pour
les comptes gérés par l'agence
(fragmentation sur numéro
d'agence).
L'agence devient copie lors du
relevé (le siège met alors le solde
à jour). La maj est effectuée de
façon asynchrone le soir.
Copie avec maj synchrone
Machine type Siège
Copie avec MAJ périodique (tous
les soirs par exemple).
Non présent mais accessible en
maj
Référence
Copie avec MAJ périodique (tous
les soirs par exemple).
Dossier.
Le siège est site copie avec MAJ
périodique (tous les soirs par
exemple) sauf lors du relevé (le
le siège devient référence pour la
maj du solde).
Référence
5. REGLES DE FONCTIONNEMENT A RESPECTER POUR UNE BASE DE DONNEES REPARTIES
Chris Date a énoncé 12 règles pour un système réparti :
1 - Autonomie locale : chaque base physique appartenant à une base logique est administrée
localement.
2 - Indépendance vis-à-vis d'un site central : dans une base de données réparties, il n'y a pas
de site central. Chaque site possède son propre schéma relationnel, ses propres requêtes…
3 - Fonctionnement en continu : enlever ou ajouter des sites dans la base logique ou modifier
le schéma relationnel ou le SGBD sur un site ne doivent pas avoir d'impact sur le
fonctionnement de la base de données réparties.
4 - Indépendance de la localisation : la localisation physique des données doit être
transparente pour les utilisateurs. L'utilisateur peut travailler dans une même requête sur des
tables appartenant à des bases physiques différentes .
5 - Indépendance du partitionnement : les données d'une table doivent pouvoir être réparties
sur plusieurs sites pour favoriser la localité de référence (stocker les données sur le site où
elles sont le plus utilisées). Ce partitionnement doit être transparent pour les utilisateurs.
11
TSIG2
ALSI
S26 – Client/Serveur
Cours n°2
6 - Indépendance de la duplication : les données d'une table doivent pouvoir être dupliquées
pour favoriser l'accessibilité et la fiabilité du système en cas de panne. Cette duplication doit
être transparente pour les utilisateurs.
7 -Traitement réparti des requêtes : les utilisateurs peuvent accéder à des données qui résident
sur différents postes. Les requêtes sont exécutées sur le poste où résident les données. Le
poste maître de la requête est celui à partir duquel la requête est émise.
8 - Gestion des transactions réparties : un mécanisme automatique doit assurer l'intégrité des
données (Mécanisme de "Terminaison à deux phases" aussi appelé" Commit à deux phases").
Les accès concurrents aux données sont garantis par les mécanismes de verrouillage.
9 - Indépendance matérielle : les logiciels de la base de données réparties doivent pouvoir
s'exécuter sur plusieurs plates-formes matérielles.
10 - Indépendance du système d'exploitation : les logiciels de la base de données réparties
doivent pouvoir s'exécuter sur plusieurs systèmes d'exploitation. Les bases physiques peuvent
être implantées sur des systèmes d'exploitation différents.
11 - Indépendance du réseau : les sites de la base de données réparties doivent pouvoir être
reliées par différents types de réseaux. Les différentes bases physiques peuvent fonctionner
sur des machines reliées par des protocoles de réseaux différents.
12 - Indépendance du SGBD : les SGBD relationnels ou non doivent pouvoir participer à la
gestion de la base de données réparties.
12