Serveursdonnees

Ce document a t fabriqu par PDFmail (Copyright RTE Multimedia) http://www.pdfmail.
com
Support de cours Les serveurs de donnes
LES SERVEURS DE DONNEES
L'ARCHITECTURE DEUX TIERS
Ce document a t fabriqu par PDFmail (Copyright RTE Multimedia) http://www.pdfmail.com

Les serveurs de donnes
TABLE DES MATIERES

1. INTRODUCTION ................................ ................................ ................................ ............................ 2 2. LE MODELE CLIENT/ SERVEUR DE DONNEES ................................ ................................ ...........2 2.1. LE CONCEPT DE CLIENT /SERVEUR ................................ ................................ ................................ .....2 2.1.1. Dfinition ................................ ................................ ................................ ............................... 2 2.1.2. Le schma du Gartner Group ................................ ................................ ................................ 3 2.2. LE CLIENT /SERVEUR DE DONNEES ................................ ................................ ................................ .....6 2.2.1. Le dialogue avec les clients ................................ ................................ ................................ ...7 2.2.2. Le rle du serveur ................................ ................................ ................................ .................. 8 3. GENERALITES SUR L ES SERVEURS DE DONNE ES................................ ................................ 10 3.1. LA FONCTION SERVEUR ................................ ................................ ................................ ................. 10 3.1.1. diffrentes terminologies ................................ .............................. Erreur ! Signet non dfini. 3.1.2. dialogues session ................................ ................................ ................................ ............. 10 3.1.3. dialogues messages ................................ ................................ ................................ ......... 10 3.2. LE SERVEUR DE TRAITEMENTS ................................ ................................ ................................ ........ 10 3.2.1. Les triggers (ou dclencheurs) ................................ ................................ ............................. 11 3.2.2. Les procdures stockes ................................ ................................ ................................ .....13 4. DIALOGUE AVEC LES CL IENTS. ................................ ................................ ............................... 14 4.1. LE MIDDLEWARE ................................ ................................ ................................ ....................... 14 4.2. ODBC ................................ ................................ ................................ ................................ ........ 16 4.2.1. Principe ................................ ................................ ................................ ............................... 16 4.2.2. Concrtement ................................ ................................ ................................ ...................... 16 4.3. LA STRUCTURE DES APPLICATIONS ................................ ................................ ................................ .17 4.3.1. connexion ................................ ................................ ................................ ............................ 17 4.3.2. requtes ................................ ................................ ................................ .............................. 17 4.3.3. transactions ................................ ................................ ................................ ......................... 17 5. OPTIMISATION DES APPLICATIONS CLIENT/ SERVEUR ................................ ......................... 18 5.1. DETERMINER LA OU LES CAUSES DU PROBLEME ................................ ................................ ................ 18 5.2. LES POINTS A TESTER DES LA PHASE DE CONCEPTION ................................ ................................ ....... 19 5.3. LA PUISSANCE DU SERVEUR ................................ ................................ ................................ ........... 19 5.4. LA REPARTITION DES TRAITEMENTS ENTRE LE CLIENT ET LE SERVEUR ................................ ................. 20 5.5. LA CONCEPTION DE L APPLICATION................................ ................................ ................................ ..22 5.5.1. Exemple 1 : minimiser le nombre de requtes ................................ ................................ ...... 22 5.5.2. Exemple 2 : travailler avec les donnes en mmoire ................................ ............................ 22 5.5.3. Exemple 3 : utiliser des vues ................................ ................................ ............................... 23
Page 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 7, Microsoft Sql Server 6, Sybase, Sql Anywhere, ....
LE MODELE CLIENT/SERVEUR DE DONNEES e. Le concept de client/serveur e x . 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 t endu. 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.
Page 2

Si lon sen tient la dfinition toute machine peut tre client ou serveur ou les deux la fois ou alternativement lun puis lautre.
demande de services et envoi de rponses dans un sens ou dans lautre
connexion physique Lan ou Wan
. 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 factu re, 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...)
Page 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 coeur 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 primitive 4.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 4.2 intgrit sont assurs par un SGBD centralis. Cette architecture, de part 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. . 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).
Page 4

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 oeuvre. . Donnes et traitements distribus. Ce modle est trs puissant et tire partie 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 oeuvre.
Page 5

a g.
Le client/serveur de donnes L'ARCHITECTURE DEUX TIERS
Rseau local disque dur
client Serveur
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 partie de la pui ssance des ordinateurs dploys en rseau pour fournir l'utilisateur une interface riche 5.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.
Page 6

age . Le dialogue avec les clients

Le principe du dialogue entre clients et serveurs peut tre schmatis ainsi :
traitements propres lapplication interface li au SGBD cible couche de conversion propre au protocole de transport du rseau matriel et logiciel implmentant les couches 1 4 sur le client
*
Application
API FAP rseau
SGBD FAP rseau matriel et logiciel implmentant les couches 1 4 sur le serveur
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 rse au (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 oeuvre des mcanismes relativement complexes qui sont, en gnral, pris en charge par un middleware.
*
A.P.I. : Application Programme Interface F.A.P. : Format And Protocol
Page 7

age . Le rle du serveur de donnes

Il est lcoute des requtes provenant des clien ts. 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 donn es. Cest en gnral le langage utilis dans les requtes. En langage SQL cest par exemple linstruction SELECT . gestion du stockage Le S.G.B.D organise le stockage des donnes sur disque. Cette organisation interne est transparente pour lutilisate ur 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 f aire 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
Page 8

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 ininterruptibles. 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 g estion du systme dinformations 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.
Page 9

GENERALITES SUR LES SERVEURS DE DONNEES 0 g. 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.
0ge . 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 dro its 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.
uivr . dialogues messages

Dans un type de dialogue par messages toutes le s 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.
u. i
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 remplissag e) 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 proce sseur du serveur.
FIFO : First In First Out
Page 10

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 to utes;
tes; . 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
Page 11

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, em prunt WHERE adherent.no = emprunt.noadh AND compta.nom = adherent.nom IF solde = 0 THEN commit ELSE rollback
Page 12

suppressions en cascade On souhaite lorsque lon supprime un client supprimer toutes les informations qui lui sont attaches (commande, factu re, 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 comm ande on est oblig dajouter un autre trigger sur la table commande Sur suppression dans commande DELETE FROM lignes_commande WHERE lignes_commande.nocde = nocde 3ge . Les procdures stockes Elles permettent de constituer des catalogues de proc dures 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.
Page 13

DIALOGUE AVEC LES CLIENTS. 4 g. e. 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 dial ogue 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.
# .
Les services rendus
Un middleware est susceptible de rendre les services suivants
Conversion : Service utilis pour la communication entre machines mettant en oeuvre 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.
Page 14

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, l a prparation de l'excution des requtes, la rcupration des rsultats et la d-connexion 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)
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.
Page 15

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 oeuvre 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
D B.
ODBC D C . Principe B
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.
ur l . Concrtement
ODBC est un produit de Windows q ui 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.
Page 16

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.
7 g.
La structure des applications 7ge . 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.
xion. 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.
o b . transactions mr
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, ...)
Page 17

OPTIMISATION DES APPLICATIONS CLIENT/SERVEUR

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 c hoses, 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 !
.. .
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 particulie rs. 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 lorsqu e 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 r ponse est ngligeable.
Page 18

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.
s.
Les points tester ds la phase de conception
Ds la phase de conception il est judici eux 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 des 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.
e s.
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 mmo ire 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 appl ication accde est -elle optimise ? La rpartition des donnes sur disque est-elle satisfaisante (disque morcel ou trop plein) ? Les ressources systmes ncessaires au SGBDR sont -elles 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.
Page 19

0 g.
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 :
LAN Rception de la requte Analyse syntaxique Compilation Vrification des droits Excution S.G.B.D.R. fonction serveur
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 requ te du rseau analyse syntaxique compilation vrification des droits excution excution du trigger sur INSERT de commande
le trigger sur INSERT dans la table commande lance lUpdate de la table client
Page 20

3me cas : on crit une procdure stocke qui fait les 2 oprations Le client nenvoie quune requte (le lancement de la procdur e) 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 o nt pour but de maintenir la cohrence dans la base de donnes. 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 modifica tion 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 lanc e 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 lappl ication 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.
Page 21

2 g.
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. 2ge . 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 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. 2ge . 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.
Page 22

3ge . 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 doptimi sation de la requte.
a. t
Conclusion
On pourrait multiplier les exmples, 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.
Page 23

Serveursdonnees

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

Serveursdonnees

Transféré par

Droits d'auteur :

Formats disponibles

Ce document a t fabriqu par PDFmail (Copyright RTE Multimedia) http://www.pdfmail.

LES SERVEURS DE DONNEES

L'ARCHITECTURE DEUX TIERS

Ce document a t fabriqu par PDFmail (Copyright RTE Multimedia) http://www.pdfmail.com

TABLE DES MATIERES

Ce document a t fabriqu par PDFmail (Copyright RTE Multimedia) http://www.pdfmail.com

LE MODELE CLIENT/SERVEUR DE DONNEES e. Le concept de client/serveur e x . Dfinition

Ce document a t fabriqu par PDFmail (Copyright RTE Multimedia) http://www.pdfmail.com

demande de services et envoi de rponses dans un sens ou dans lautre

connexion physique Lan ou Wan

. Le schma du Gartner Group

Ce document a t fabriqu par PDFmail (Copyright RTE Multimedia) http://www.pdfmail.com

Ce document a t fabriqu par PDFmail (Copyright RTE Multimedia) http://www.pdfmail.com

Ce document a t fabriqu par PDFmail (Copyright RTE Multimedia) http://www.pdfmail.com

Le client/serveur de donnes L'ARCHITECTURE DEUX TIERS

Rseau local disque dur

Ce document a t fabriqu par PDFmail (Copyright RTE Multimedia) http://www.pdfmail.com

age . Le dialogue avec les clients

API FAP rseau

A.P.I. : Application Programme Interface F.A.P. : Format And Protocol

Ce document a t fabriqu par PDFmail (Copyright RTE Multimedia) http://www.pdfmail.com

age . Le rle du serveur de donnes

Ce document a t fabriqu par PDFmail (Copyright RTE Multimedia) http://www.pdfmail.com

Ce document a t fabriqu par PDFmail (Copyright RTE Multimedia) http://www.pdfmail.com

GENERALITES SUR LES SERVEURS DE DONNEES 0 g. La fonction serveur

0ge . dialogues session

uivr . dialogues messages

FIFO : First In First Out

Ce document a t fabriqu par PDFmail (Copyright RTE Multimedia) http://www.pdfmail.com

tes; . Les triggers (ou dclencheurs)

Ce document a t fabriqu par PDFmail (Copyright RTE Multimedia) http://www.pdfmail.com

Ce document a t fabriqu par PDFmail (Copyright RTE Multimedia) http://www.pdfmail.com

Ce document a t fabriqu par PDFmail (Copyright RTE Multimedia) http://www.pdfmail.com

DIALOGUE AVEC LES CLIENTS. 4 g. e. Le Middleware Dfinition

Les services rendus

Un middleware est susceptible de rendre les services suivants

Ce document a t fabriqu par PDFmail (Copyright RTE Multimedia) http://www.pdfmail.com

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

Ce document a t fabriqu par PDFmail (Copyright RTE Multimedia) http://www.pdfmail.com

Ce document a t fabriqu par PDFmail (Copyright RTE Multimedia) http://www.pdfmail.com

La structure des applications 7ge . connexion

Ce document a t fabriqu par PDFmail (Copyright RTE Multimedia) http://www.pdfmail.com

OPTIMISATION DES APPLICATIONS CLIENT/SERVEUR

Dterminer la ou les causes du problme

Ce document a t fabriqu par PDFmail (Copyright RTE Multimedia) http://www.pdfmail.com

Les points tester ds la phase de conception

Ce document a t fabriqu par PDFmail (Copyright RTE Multimedia) http://www.pdfmail.com

La rpartition des traitements entre le client et le serveur

Ce document a t fabriqu par PDFmail (Copyright RTE Multimedia) http://www.pdfmail.com

Ce document a t fabriqu par PDFmail (Copyright RTE Multimedia) http://www.pdfmail.com

Ce document a t fabriqu par PDFmail (Copyright RTE Multimedia) http://www.pdfmail.com

Vous aimerez peut-être aussi