1

Les Serveurs de Donnes - l'architecture deux 2 tiers - Gartner Group

1- INTRODUCTION

Aujourdhui, les entreprises tendent de plus en plus vouloir utiliser les postes
Dos/Windows prsents dans

les bureaux pour faire tourner les applicatifs en plus des logiciels bureautiques. La premire
tape consister installer sur les micros des mulations permettant au micro de
fonctionner comme un terminal classique de lordinateur central (gros systme, AS400, Unix
ou autre).

Le contraste entre lergonomie de Windows et des terminaux en mode texte a conduit

rechercher le moyen dexcuter sous Windows des applications utilisant les donnes du site
central. Cest ce que lon a appel larchitecture client/serveur.

Ce support de cours a pour but de dfinir prcisment ce quest une architecture

client/serveur, puis de prciser ce quest dans ce contexte un serveur de donnes, quel est
son fonctionnement et enfin comment il dialogue avec les clients.

Les concepts prsents ici sont suffisamment gnraux pour tre communs tous les
serveurs de donnes actuels du march : Oracle, Microsoft SQL Server, Sybase, SQL
Anywhere, ...

2 - LE MODLE CLIENT/SERVEUR DE DONNEES

2.1 - Le concept de client/serveur

2.1.1 Dfinition

La dfinition dune architecture client/serveur est la suivante :

Ensemble de machines pouvant communiquer entre elles, et schangeant des services :

traitement, donnes ou ressources

Concrtement, il sagit de plusieurs machines relies par un rseau local ou tendu.

Certaines de ces machines sont capables doffrir des services, tels que lexcution dune
procdure, la recherche de donnes, le partage dune ressource : ce sont des serveurs.

Dautres vont utiliser ces services : ce sont les clients.

Si lon sen tient la dfinition toute machine peut tre client ou serveur ou les deux la fois
ou alternativement lun puis lautre.
 2

2.1.2 Le schma du Gartner Group

Un groupe dtude compos dacteurs du march a dfini 6 types darchitectures

client/serveur, en considrant quune application de gestion quelle quelle soit se
dcompose en trois parties : prsentation, traitements et donnes.
Prsentation (ou interface)
Cest dire la fois la dfinition du scnario de saisie et lalgorithme permettant
dinterprter les interactions de lutilisateur, tel que lAPI Windows
Traitements
Cest dire les algorithmes propres lapplication (calcul du montant de la facture,
enchanement des traitements, etc...) et des algorithmes rutilisables par plusieurs
applications (tris, dition, calculs statistiques, etc...)
Donnes
Il faut distinguer la logique des donnes, cest dire la vue logique des donnes utilise par
lapplication et la gestion des donnes, cest dire tout le travail que fait le S.G.B.D.
(recherche des donnes, stockage, contrle des accs, etc...)
 3

Sur ce schma, le trait horizontal reprsente le rseau et les flches entre client et serveur,
le trafic rseau gnr par la conversation entre client et serveur.

Le Gartner Group distingue les types de client-serveur suivants, en fonction du type de

service dport du cur de l'application :
Prsentation distribue : Correspond l'habillage ``graphique'' de l'affichage en
mode caractres d'applications fonctionnant sur site central. Cette solution est aussi
appele revamping. La classification "client-serveur'' du revamping est souvent juge
abusive, du fait que l'intgralit des traitements originaux est conserve et que le
poste client conserve une position d'esclave par rapport au serveur.
Prsentation distante : Encore appele client-serveur de prsentation. L'ensemble
des traitements est excut par le serveur, le client ne prend en charge que
l'affichage. Ce type d'application prsentait jusqu' prsent l'inconvnient de gnrer
un fort trafic rseau et de ne permettre aucune rpartition de la charge entre client
et serveur. S'il n'tait que rarement retenu dans sa forme primitive4.1, il connat
aujourd'hui un trs fort regain d'intrt avec l'exploitation des standards Internet.
Gestion distante des donnes : Correspond au client-serveur de donnes, sans doute
le type de client-serveur le plus rpandu. L'application fonctionne dans sa totalit sur
le client, la gestion des donnes et le contrle de leur intgrit sont assurs par un
SGBD4.2 centralis. Cette architecture, de par sa souplesse, s'adapte trs bien aux
applications de type infocentre, interrogeant la base de faon ponctuelle. Il gnre
toutefois un trafic rseau assez important et ne soulage pas normment le poste
client, qui ralise encore la grande majorit des traitements.
 4

Traitement distribu : Correspond au client-serveur de traitements. Le dcoupage

de l'application se fait ici au plus prs de son noyau et les traitements sont distribus
entre le client et le(s) serveur(s). Le client-serveur de traitements s'appuie, soit un
mcanisme d'appel de procdure distante, soit sur la notion de procdure stocke
propose par les principaux SGBD du march. Cette architecture permet d'optimiser
la rpartition de la charge de traitement entre machines et limite le trafic rseau. Par
contre il n'offre pas la mme souplesse que le client-serveur de donnes puisque les
traitements doivent tre connus du serveur l'avance.
Bases de donnes distribues : Il s'agit d'une variante du client-serveur de donnes
dans laquelle une partie de donnes est prise en charge par le client. Ce modle est
intressant si l'application doit grer de gros volumes de donnes, si l'on souhaite
disposer de temps d'accs trs rapides sur certaines donnes ou pour rpondre de
fortes contraintes de confidentialit.
Ce modle est aussi puissant que complexe mettre en uvre.
Donnes et traitements distribus. Ce modle est trs puissant et tire parti de la
notion de composants rutilisables et distribuables pour rpartir au mieux la charge
entre client et serveur.
C'est, bien entendu, l'architecture la plus complexe mettre en uvre.

2.2 - Le client/serveur de donnes

L'ARCHITECTURE DEUX TIERS

Dans une architecture deux tiers, encore appele client-serveur de premire gnration ou
client-serveur de donnes, le poste client se contente de dlguer la gestion des donnes
un service spcialis. Le cas typique de cette architecture est l'application de gestion
fonctionnant sous Ms-Windows et exploitant un SGBD centralis.

Ce type d'application permet de tirer parti de la puissance des ordinateurs dploys en

rseau pour fournir l'utilisateur une interface riche5.1, tout en garantissant la cohrence
des donnes, qui restent gres de faon centralise.

La gestion des donnes est prise en charge par un SGBD centralis, s'excutant le plus
souvent sur un serveur ddi. Ce dernier est interrog en utilisant un langage de requte
qui, le plus souvent, est SQL...

Le dialogue entre client et serveur se rsume donc l'envoi de requtes et au retour des
donnes correspondant aux requtes. Ce dialogue ncessite l'instauration d'une
communication entre client et serveur.
 5

2.2.1 - Le dialogue avec les clients

Le principe du dialogue entre clients et serveurs peut tre schmatis ainsi :

Le client envoie une requte au serveur de donnes. Cette requte est :

traduite dans un format comprhensible par le SGBD (API)

formate en une suite de trames compatibles avec le protocole rseau (FAP)
vhicule par le rseau jusquau serveur concern

Sur le serveur lopration inverse est effectue :

Recomposition de la requte partir des trames reues (FAP)

Le SGBD interprte la requte et lexcute

Le rsultat de la requte prend ensuite le chemin inverse.

Le client provoque l'tablissement d'une conversation afin de d'obtenir des donnes ou un

rsultat de la part du serveur.

Cet change de messages transite travers le rseau reliant les deux machines. Il met en
uvre des mcanismes relativement complexes qui sont, en gnral, pris en charge par un
middleware.

2.2.2 - Le rle du serveur de donnes

Il est lcoute des requtes provenant des clients. Il y rpond en faisant appel aux
fonctions dun S.G.B.D. classique.
Langage de Description de Donnes (L.D.D.)
Ce langage permet de dcrire les donnes (Type, Longueur, Nature ...), les relations entre
les donnes, les rgles de gestion, les domaines de valeur, etc... En langage SQL cest par
exemple linstruction CREATE .
Langage de Manipulation de Donnes (L.M.D.)
Ce langage sert excuter les oprations dajout, suppression, modification des donnes. Il
permet galement linterrogation des donnes. Cest en gnral le langage utilis dans les
requtes. En langage SQL cest par exemple linstruction SELECT .
 6

Gestion du stockage
Le S.G.B.D organise le stockage des donnes sur disque. Cette organisation interne est
transparente pour lutilisateur et le programmeur. Il offre une vue logique des donnes.
Partage des donnes
Dans ce contexte multi-utilisateurs, cest le S.G.B.D. qui gre le partage des donnes entre
les diffrents utilisateurs (ou clients) Cest lui qui en sappuyant en gnral, sur le systme
dexploitation vite les situations de conflit et les situations dinterblocage ou treinte
fatale.
Confidentialit
Le S.G.B.D. assure la confidentialit des donnes : il contrle les droits daccs des
utilisateurs. Cest dire dans ce contexte des applications clientes lorsquelles demandent la
connexion. (Voir 3.1.2)
Scurit, fiabilit, cohrence
Le S.G.B.D. assure la scurit des donnes. Cest dire quil doit veiller ce que les donnes
restent cohrentes. Par exemple il doit faire en sorte quune commande ne puisse pas tre
cre tant que toutes les lignes de commande ne sont pas cres, ou quun client ne soit pas
supprim sans avoir au pralable supprim toutes les commandes attaches ce client.

Dans les deux cas ci -dessus (cration dune commande ou suppression dun client) il y a
plusieurs actions conscutives excuter dans la base de donnes. Pour que la base de
donnes reste cohrente, il faut que ces actions soient toutes excutes ou alors aucunes.

Lensemble de ces actions est appel transaction.

Le S.G.B.D doit rendre les transactions interruptibles.

Si une interruption intervient au cours dune transaction, le systme remet les donnes dans
ltat o elles taient avant le dbut de la transaction.
Sauvegarde et restauration
La sauvegarde et la restauration sont deux outils du S.G.B.D permettant de mmoriser puis
de retrouver une base de donnes dans un tat cohrent.
Contrle dintgrit
La plupart des S.G.B.D offrent la possibilit de dcrire les rgles de gestion du systme
informations de lentreprise. Par exemple, si un client nexiste pas, on ne peut pas lui
associer de facture.

Une fois toutes les rgles dcrites, le S.G.B.D vrifie que les mises jour effectues sur les
donnes respectent ces rgles. Ainsi, il refusera la cration de la facture tant que le client ne
sera pas cr.
 7

3 - GENERALITES SUR LES SERVEURS DE DONNEES

3.1 - La fonction serveur
Pour faire fonctionner une architecture client/serveur, il faut que le serveur soit lcoute
des requtes des clients.

Suivant les systmes dexploitation la terminologie employe diffre :

Processus en background sous Unix

Service sous Windows NT
Dans tous les cas, cest une tche de fond qui coute les requtes, cest dire en fait une
fonction qui tourne tout le temps et scrute sil y a des requtes traiter.

3.1.1 Dialogues session

Dans un type de dialogue session, le client et le serveur dialoguent de la manire
suivante :
La fonction serveur reoit la demande de connexion, le S.G.B.D. vrifie les droits et
cre le contexte
la fonction serveur reoit les requtes et les transmet au S.G.B.D.
le S.G.B.D. excute les requtes, transmet le rsultat la fonction serveur qui fait
suivre.

3.1.2 Dialogues messages

Dans un type de dialogue par messages toutes les demandes ainsi que les rponses sont
stockes dans une file dattente de messages.
Le systme fonctionne en temps diffr :
La fonction serveur traite les requtes de la file dattente en FIFO et envoie ses
rponses de la mme manire
Le client envoie ses requtes dans la file dattente et si besoin est se bloque en
attente de recevoir la rponse, sinon il continue et traitera la rponse le moment
venu en observant la file dattente.
3.2 - Le serveur de traitements

La plupart des SGBD actuels offrent un SQL procdural. Cest dire que lon peut faire
excuter par le serveur une partie des traitements qui taient jusque-l effectus sur le
client :
Vrification des rgles de gestion (cohrence des informations entre plusieurs tables)
Conversion (ou remplissage) automatique de certains champs avant linsertion
Transactions particulires indpendantes des applicatifs
etc...
Ces procdures et triggers sont dclenchs par les applications qui tournent sur les postes
clients, mais elles sont excutes par le processeur du serveur.

Ce dcoupage a deux buts essentiels :

assurer une meilleure rpartition des traitements entre clients et serveur

centraliser les rgles de gestion pour une meilleure cohrence de la base de donnes
Les rgles ont crites une fois pour toutes ;
 8

3.2.1 Les triggers (ou dclencheurs)

Ce sont des points dentre auxquels on peut accrocher du code SQL. Ces points dentre
sont propres chaque table et permettent dagir trois moments :
linsertion dun enregistrement
la suppression dun enregistrement
la modification dun enregistrement
Exemples dutilisation :

Ajout dinformations avant insertion

Une rgle de gestion indique que si le montant de la facture est infrieur 1000F, il faut
facturer des frais de port dune valeur de 49F. Cette rgle peut tre excute par les
applications clientes directement. Mais pour viter les erreurs et les redondances on peut
crer un trigger sur insertion dans la table facture.

Le code serait le suivant :

Sur insertion dans facture

Si montant < 1000
Alors port = 49
Sinon port = 0
FSI
Valider linsertion (commit)

Contrle de cohrence entre plusieurs tables

Une rgle de gestion dans une bibliothque tudiante indique quun tudiant ne peut pas
emprunter douvrages tant quil nest pas jour de ses rglements avec la comptabilit.

On ajoutera dans ce cas un trigger sur insertion dans la table emprunt.

Le code serait le suivant :

Sur insertion dans emprunt

Rechercher dans la table compta
Le solde de ltudiant dont le no dadhrent
Est celui pour lequel on veut faire linsertion

Si solde <> 0
Alors annuler linsertion
Sinon valider linsertion
FSI
Soit en SQL

SELECT solde from adherent, compta, emprunt

WHERE adherent.no = emprunt.noadh
AND compta.nom = adherent.nom

IF solde = 0 THEN commit ELSE rollback

 9

suppressions en cascade

On souhaite lorsque lon supprime un client supprimer toutes les informations qui lui sont
attaches (commande, facture, rglements)

On va crer un trigger sur suppression dans la table client

Le code SQL serait le suivant :

Sur suppression dans client

DELETE FROM commande
WHERE commande.nocli = nocli

Les commandes tant attaches aux lignes de commande on est oblig dajouter un autre
trigger sur la table commande

Sur suppression dans commande

DELETE FROM lignes_commande
WHERE lignes_commande.nocde = nocde

3.2.2 Les procdures stockes

Elles permettent de constituer des catalogues de procdures SQL accessibles depuis

nimporte quelle application, que ce soit en client/serveur ou sur le serveur lui-mme, ou
mme dans les triggers.

Ces procdures sont crites en SQL Procdural et sont alors excutes par le processeur du
serveur.

4 - DIALOGUE AVEC LES CLIENTS.

4.1 - Le Middleware

Dfinition

On appelle middleware, littralement ``lment du milieu'', l'ensemble des couches rseau

et services logiciel qui permettent le dialogue entre les diffrents composants d'une
application rpartie. Ce dialogue se base sur un protocole applicatif commun, dfini par
l'API du middleware.

API : Application Programming Interfaces, ou interface de programmation du niveau

applicatif, encore appele protocole applicatif. L'API prend en charge l'interface entre le
programme et le systme.

Le Gartner Group dfinit le middleware comme une interface de communication

universelle entre processus. Il reprsente vritablement la clef de vote de toute application
client-serveur.

L'objectif principal du middleware est d'unifier, pour les applications, l'accs et la

manipulation de l'ensemble des services disponibles sur le rseau, afin de rendre l'utilisation
de ces derniers presque transparente.
 10

Les services rendus

Un middleware est susceptible de rendre les services suivants

Conversion : Service utilis pour la communication entre machines mettant en
uvre des formats de donnes diffrents, elle est prise en charge par la FAP
Adressage : Permet d'identifier la machine serveur sur laquelle est localis le service
demand afin d'en dduire le chemin d'accs. Dans la mesure du possible, cette
fonction doit faire appel aux services d'un annuaire.
Scurit : Permet de garantir la confidentialit et la scurit des donnes l'aide de
mcanismes d'authentification et de cryptage des informations.
Communication : Permet la transmission des messages entre les deux systmes sans
altration. Ce service doit grer la connexion au serveur, la prparation de
l'excution des requtes, la rcupration des rsultats et la dconnexion de
l'utilisateur.
Le middleware masque la complexit des changes inter-applications et permet ainsi
d'lever le niveau des API utilises par les programmes. Sans ce mcanisme, la
programmation d'une application client-serveur serait extrmement complexe et rigide.

Le middleware par rapport au modle OSI (Open Systems Interc onnection)

 11

Exemples de middleware

SQL*Net : Interface propritaire permettant de faire dialoguer une application

cliente avec une base de donnes Oracle. Ce dialogue peut aussi bien tre le passage
de requtes SQL que l'appel de procdures stockes.
ODBC (Open DataBase Connectivity): Interface standardise isolant le client du
serveur de donnes. C'est l'implmentation par Microsoft du standard CLI (Call Level
Interface) dfini par le SQL Access Group. Elle se compose d'un gestionnaire de driver
standardis, d'une API s'interfaant avec l'application cliente (sous Ms Windows) et
d'un driver correspondant au SGBD utilis.
DCE (Distributed Computing Environment) : Mcanisme de RPC propos par l'OSF:
Permet l'appel des procdures distantes depuis une application.
Le choix d'un middleware est dterminant en matire d'architecture, il joue un grand rle
dans la structuration du systme d'information.
Les middleware proposs par les fournisseurs de SGBD sont trs performants et permettent
de tirer profit de l'ensemble des fonctionnalits du serveur de donnes pour lequel ils ont
t conus. Par contre, ils ne permettent pas, le plus souvent, l'accs d'autres sources de
donnes.
Pour certaines applications devant accder des services htrognes, il est parfois
ncessaire de combiner plusieurs middlewares. Dans ce cas, le poste client doit connatre et
mettre en uvre plusieurs IPC (Inter Process Communication), on en vient la notion de
client lourd.

Pour pallier ces inconvnients un standard a t dfini :

ODBC (Open DataBase Connectivity) par Microsoft alli dautres intervenants du
march
 12

4.2 - ODBC

4.2.1 Principe
Le client envoie une requte au serveur de donnes.
Cette requte concerne une source de donnes dfinie par loutil de configuration
ODBC
lAPI ODBC recherche sa dfinition dans la base ODBC (quel type de SGBD, quel
serveur, quelle database, ...) et la formate en trames compatibles avec le SGBD et la
couche transport
la requte est vhicule par le rseau jusquau serveur concern
Sur le serveur lopration inverse est effectue :
recomposition de la requte partir des trames reues (FAP)
le SGBD interprte la requte et lexcute Le rsultat de la requte prend ensuite le
chemin inverse.
4.2.2 Concrtement
ODBC est un produit de Windows qui comporte plusieurs parties :
un outil de configuration
des drivers (DLL) fournis par les S.G.B.D. cibles
une API sous forme de DLL
Par lintermdiaire de loutil de configuration, on installe les drivers des S.G.B.D. qui sont
appels pilotes.
Ensuite on dfinit des sources de donnes.
Une source de donnes dfinit laccs une base de donnes sur un serveur de donnes.
Pour cela on choisit un pilote et en fonction de celui -ci on entre les caractristiques voulues.

4.3 - La structure des applications

4.3.1 connexion

Pour accder une base de donnes distante, lapplication doit se connecter. Il faut songer
que pour le SGBD cible, lopration de connexion est coteuse en ressource mmoire
(cration dun contexte, vrification des droits)

Par consquent, sauf ca s particuliers il ne faut maintenir la connexion que le temps

ncessaire.

4.3.2 Requtes

Chaque requte sur les donnes est envoye au serveur, donc elle transite par le rseau. Par
consquent elle est coteuse, il faudra donc essayer den minimiser le nombre et la
frquence.

4.3.3 Transactions

La notion de transaction en client/serveur est la mme que sur un SGBD classique.

Elle revt ici beaucoup plus dimportance car les incidents sont plus frquents (incident du
serveur, du rseau, du poste client, de Windows, de lapplication, ...)

5 - OPTIMISATION DES APPLICATIONS CLIENT/SERVEUR

 13

Pour amliorer les performances dune application client/serveur, il faut considrer

successivement tous les lments qui entrent en jeu dans le temps de rponse de
lapplication :

la puissance du poste client (mmoire, OS, vitesse du processeur, ...)

la vitesse du rseau
lactivit du rseau
le middleware utilis
la puissance du serveur (mmoire, activit, puissance de la machine, du SGBDR,...)
la rpartition des traitements entre le c lient et le serveur
la conception de lapplication
le code mme de lapplication (criture des requtes)

Il faut toutefois tre conscient que le temps de rponse varie dun instant lautre, que lon
ne peut pas toujours amliorer significativement les choses, que lamlioration des
performances ne doit pas se faire au dtriment de la maintenabilit, quil suffit parfois de
changer la conception de linterface graphique pour que lutilisateur ait limpression que les
choses vont mieux, bref que la tche nest pas simple !

5.1 - Dterminer la ou les causes du problme

Les mauvaises performances dune application se ressentent essentiellement au niveau du

poste client. En gnral, on constate les dgradations de performance sur un ou deux
formulaires particuliers. On fera donc les tests en isolant ce formulaire dans une petite
application de test.
La cause peut en tre le poste lui-mme. Pour le vrifier, le plus simple si on le peut,
est de tester lapplication sur un poste plus puissant : si le rsultat est meilleur cest
quune partie du problme vient de l.
On peut galement essayer de dvelopper la mme application en utilisant des
donnes locales (sous Access par exemple). Si le temps de rponse devient bon, on
peut de suite dduire que le problme vient du serveur ou du rseau. Sil est toujours
mauvais on ne peut directement conclure, car on ne sait pas si la cause est le poste,
loutil de dveloppement, ou le SGBD local.
On peut reproduire les mmes fonctionnalits avec un outil de dveloppement
diffrent, si le rsultat est bien meilleur on en dduira soit que loutil utilis nest pas
performant soit que lapplication a t mal programme.
On fera des essais lorsque le serveur est inactif (sa seule tche sera de rpondre
mon application) et lorsque le serveur est trs actif (lancer diffrentes tches sur le
serveur, lancer lapplicatif concurremment sur plusieurs postes clients). Si les
rsultats sont sensiblement gaux on pourra en dduire que limpact de la puissance
du serveur sur le temps de rponse est ngligeable.
De mme on fera des essais lorsque le rseau est inactif (le seul poste connect est
mon poste client) et lorsque le serveur est trs actif (il y a beaucoup de postes
connects, lancer lapplicatif concurremment sur plusieurs postes clients). Si les
rsultats sont sensiblement gaux on pourra en dduire que limpact de la vitesse et
de lactivit du rseau sur le temps de rponse est ngligeable.
5.2 - Les points tester ds la phase de conception
 14

Ds la phase de conception il est judicieux de prvoir la puissance des postes clients, du

rseau et du serveur adquats pour faire tourner lapplication.

Pour cela, ds la conception on peut isoler les formulaires qui risquent a priori dtre
coteux en temps de rponse et faire les tests cits plus haut.

On pourra galement avant de faire un choix tester les performances respectives des outils
de dveloppement et du middleware sur un mme exemple.

En particulier, le choix dODBC qui est plus lent ne se justifie pas si lapplication accde un
seul serveur et quil nest pas prvu de la porter dans un autre environnement.

5.3 - La puissance du serveur

Lorsque lon a constat que le problme vient de la puissance du serveur, il faut encore
dterminer plus prcisment au niveau du serveur do vie nt ce problme.

Le problme peut provenir du systme dexploitation : trop de tches en cours par rapport
ce quil est capable de grer. La solution consiste en gnral soit agrandir lespace de
swapping (mmoire virtuelle) et/ou rajouter de la mmoire vive. Certains systmes
permettent de configurer la machine de manire ce quelle privilgie le multitche par
rapport ses autres activits.

Ce peut tre le SGBDR qui est en cause. Est-il configur au mieux ? La base de donnes
laquelle mon application accde est-elle optimise ? La rpartition des donnes sur disque
est-elle satisfaisante (disque morcel ou trop plein) ? Les ressources systmes ncessaires au
SGBDR sontelles disponibles (recommandations de lditeur du SGBDR) ? Ny a-t-il pas des
tches inutiles en cours ?

Se souvenir quune connexion dune application cliente au serveur peut, suivant les
systmes, consommer beaucoup de ressources au niveau du systme dexploitation.

5.4 - La rpartition des traitements entre le client et le serveur

Si on a conclu que la puissance du serveur nest pas en cause on essaiera de dcharger

lapplication cliente en programmant le serveur.
Pour ce faire, on doit dfinir des triggers et/ou crire des procdures stockes.

Lavantage est que dans les deux ca s, le code SQL correspondant est dj compil.

Le traitement dune requte sur le serveur se droule suivant les tapes :

 15

Exemple1 :

On veut, dans une application, mettre jour le champ CA (chiffre daffaire) dans la table
client chaque fois quune commande est ajoute pour ce client.

1er cas : lapplication cliente envoie 2 requtes

requte 1 : INSERT INTO commande VALUES (123, 2, 01/01/96 , 1240.00)

requte 2 : UPDATE client SET CA = CA + 1240.00 WHERE nocli = 2

Cela conduit :
requtes sur le rseau
pour chacune : analyse syntaxique, compilation, vrification des droits, excution

2me cas : on lance lUPDATE par un trigger

Le client nenvoie quune requte (la requte 1)

Cela conduit :

rception de la requte du rseau

analyse syntaxique
compilation
vrification des droits
excution
excution du trigger sur INSERT de commande
3me cas : on crit une procdure stocke qui fait les 2 oprations

Le client nenvoie quune requte (le lancement de la procdure)

Cela conduit :

rception de la requte du rseau

vrification des droits et de lexistence de la procdure
excution

On peut donc penser que la meilleure solution est la 3me. Cependant il faut considrer que
dans ce cas, les oprations envisages ont pour but de maintenir la cohrence dans la base
de donnes.
 16

Donc pour des raisons de maintenance, on choisira plutt loption 2

En effet, il faut comprendre que la mise jour du CA doit tre galement effectue lors de la
suppression ou de la modification du montant dune commande.

Si le montant de la commande partir des lignes de commandes est calcul par un trigger,
loption 3 conduirait crire 3 procdures.

On aboutirait :

- 1 trigger sur insert, delete, update de lignes de commande. Il lance lupdate du montant de
la commande et du CA du client

- 1 procdure pour insrer la commande, une procdure pour supprimer la commande, 1

procdure pour modifier la commande. Chacune mettant jour le CA du client.

De plus, dans ce cas le code de lapplication cliente risque dy perdre en lisibilit, et on ne

peut assurer quun programmeur utilise lINSERT directement au lieu de la procdure.

Exemple2 :

On suppose quune entreprise souhaite faire une remise de 5% tous les clients dont les
commandes en cours ont un retard de livraison de plus de 2 jours.
Dans ce cas, on peut soit :
lancer une requte qui recherche les commandes ayant un retard de livraison et
calculer la remise et lancer la mise jour dans lapplication cliente
crire une procdure stocke pour faire ce travail
La meilleure solution sera alors la procdure.

Conclusion :

Il ny a pas a priori de bonne ou de mauvaise solution. Chaque problme pos doit tre
tudi avec prcision

5.5 - La conception de lapplication

La faon dont sont conus les formulaires et en particulier les contrles de saisie influe
galement sur le temps de rponse de lapplication.

5.5.1 Exemple 1 : minimiser le nombre de requtes

On considre un formulaire de saisie des commandes, o il faudra saisir les coordonnes du

client.
1er cas : on vrifie le code client saisi par lutilisateur par une recherche dans la table.
Sil existe on affiche ses coordonnes, sinon on ouvre un formulaire de saisie des
nouveaux clients
2me cas : on remplit une liste droulante dans laquelle lutilisateur est oblig de
choisir, si le client nexiste pas il appuie sur un bouton qui ouvre le formulaire de
saisie des nouveaux clients
 17

Dans le 1er cas, la requte (SELECT * from CLIENT) est excute chaque cration de
commande avec une recherche sur cl primaire.

Dans le 2me cas, la requte (SELECT * from CLIENT) est excute une seule fois
louverture du formulaire (et chaque nouveau client) mais elle renvoit plus de donnes.

On prfrera la 2me solution car elle sollicite moins le rseau et le serveur.

5.5.2 Exemple 2 : travailler avec les donnes en mmoire

On considre un formulaire de consultation des commandes. Dans ce formulaire, il faudra

afficher les infos des tables client, commande, lignes de commandes et articles. Un double
clic sur le nom du client, permet douvrir un formulaire visualisant le dtail du client.
1er cas : sur double clic on ouvre le formulaire, sur ouverture du formulaire on fait un
recherche dans la table client, on affiche le rsultat.
2me cas : sur double clic on ouvre le formulaire et on y affiche les donnes du client
que lon a rcupr lors de la jointure effectue pour afficher la commande
Dans le 1er cas, on lance la requte (SELECT * from CLIENT WHERE nomcli= xxxx).

Dans le 2me cas, la requte (SELECT * from CLIENT, commande, lignes_cde,produit) est
excute une seule fois louverture du formulaire de saisie des commandes mais elle
renvoit plus de donnes que dans le 1er cas.

On prfrera la 2me solution car elle sollicite moins le rseau et le serveur, condition que
le poste client ne soit pas trop juste en mmoire.

5.5.1 Exemple 3 : utiliser des vues

On considre un formulaire de consultation des commandes, dans ce formulaire, il faudra

afficher les infos des tables client, commande, lignes de commandes et articles.

1er cas : on crit la jointure dans lapplication cliente

2me cas : on dfinit une vue INFOCDE sur le serveur et on crit dans lapplication
SELECT * FROM INFOCDE
Dans le 2me cas, on gagne le temps danalyse syntaxique et doptimisation de la requte.

Conclusion

On pourrait multiplier les exemples, lobjectif de ce chapitre est de comprendre que la tche
doptimisation dune application client/serveur est complexe car il y a beaucoup de
paramtres prendre en compte.