Voici quelques définitions en usage dans l'univers des SGBDR et du SQL

À quel moment faut-il passer d'un SGBD micro de type serveur de fichier comme dBase, Paradox, FoxPro ou Access, à un poids lourd du client/serveur comme Oracle, Sybase, SQL Server, Informix ou DB2 ?

Nous supposons que le lecteur du présent article maîtrise un tantinet le monde des bases de données. Nous supposons qu'il sait ce qu'est une requête (même s'il n'en a jamais écrit), ce qu'est un accès concurrentiel aux données (deux utilisateurs voulant modifier la même donnée par exemple), et qu'il est familiarisé avec la notion de table, colonne (champ) et enregistrement. De plus, nous exigeons qu'il sache le minimum au sujet des systèmes d'exploitation, à savoir ce qu'est un fichier, un octet, un poste client, un serveur et un réseau…

Posons alors la question suivante :
Quelle différence y a-t-il entre un SGBD à base de fichiers et un SGBD en C/S ?

En fait, il existe deux différences fondamentales entre les deux systèmes. L'ensemble des techniques du C/S est dédié à minimiser le trafic des données sur un réseau et assurer une plus grande intégrité lors du traitement des données…

Pour y parvenir, le C/S utilise plusieurs techniques particulières, l'une concerne le mode de verrouillage lors des concurrences d'accès, d'autres les modes de traitement des données. Nous allons analyser l'ensemble de ces techniques et prendre quelques exemples concrets afin de rendre tangibles nos propos.

Notons d'ores et déjà une différence fondamentale : alors que dans un système à base de fichiers, c'est chaque poste de travail qui traite localement les données, dans un SGBD C/S, tous les traitements sont, en principe, effectués sur le serveur par le biais de requêtes.

Le mode de verrouillage est une fonction essentielle de la base de données. À ce jour, il n'existe que deux modes distincts : le verrouillage « optimiste » et le verrouillage « pessimiste ».

Dans la vie courante il est possible que plusieurs personnes lisent, regardent, écoutent, la même chose en même temps (journaux, radio, télévision…) mais il est impossible que plusieurs personnes créent la même information simultanément. Par exemple il est impossible à deux écrivains de tenir le même stylo afin d'écrire le même roman, comme il est impossible à deux speakers de parler en même temps des mêmes choses sans que cela ne devienne cacophonique.
Bref, l'écriture de l'information est un acte solitaire, mais sa lecture peut être accomplie par de nombreuses personnes simultanément.

Dans l'univers des bases de données, le problème est le même.
Il s'agit donc de prévoir un mécanisme capable de gérer un accès simultané en lecture à tous les utilisateurs, et d'empêcher plusieurs utilisateurs de créer, de modifier ou de supprimer la même donnée.

Pour résoudre ce problème, les chercheurs en algorithmique ont inventé les modes de verrouillage pessimiste et optimiste que nous allons maintenant détailler…

2-1. Verrouillage pessimiste▲

2-2. Verrouillage optimiste▲

2-3. Discussion sur ces différents modes de verrouillage▲

Il n'y a aucune différence entre un SQL disponible pour un SGBD de type fichier et un SGBD de type C/S : les ordres SQL sont aussi pauvres ou aussi riches en fonction de la qualité de l'éditeur du SGBD… En revanche il existe deux différences fondamentales en matière d'exécution des ordres SQL et de contrôle des transactions…

3-1. Exécution du SQL▲

SELECT * FROM CLIENT WHERE (CLI_NAME like ‘%CLINTON%')

3-2. Le transactionnel▲

BEGIN TRANSACTION
INSERT INTO CENTRAL_CLIENT (NO_CLI, NOM_CLI, ADRESSE_CLI)
   SELECT PC.NO_CLI, PC.NOM_CLI, PC.ADRESSE_CLI
   FROM PORTABLE_CLIENT PC
INSERT INTO CENTRAL_COMMANDE (NO_CLI, NO_COM, MONTANT_COM)
   SELECT PC.NO_CLI, PC.NO_COM, PC.MONTANT_COM
   FROM PORTABLE_COMMANDE PC
IF ERROR
THEN
   ROLLBACK
ELSE
   COMMIT
ENDIF

Tout le monde connaît maintenant la programmation événementielle. Son principe est simple : faire correspondre à un événement (l'ouverture d'un fichier, l'appui sur un bouton, l'arrivée d'une valeur dans un champ), le déclenchement d'une séquence de code.

Les triggers sont à la base de données ce qu'est la programmation événementielle à un environnement graphique : ils font correspondre aux événements d'un SGBD du code que tout développeur est capable d'écrire.

Prenons un exemple afin de décrire plus en avant nos propos. Supposons que nous avons une table CLIENT (parent) liée à 3 tables filles (FACT, LIGNFACT, BONLIV) et que nous voudrions l'effacement des données dans les tables filles lorsque l'utilisateur demande la suppression d'un enregistrement dans la table CLIENT.
Bien entendu, il est possible d'écrire un tel traitement dans la plupart des langages de développement possédant des outils d'accès aux bases de données, mais dans ce cas, le code s'exécute sur le poste client, et il ne faut pas oublier de l'appeler dans tous les éléments de code qui effectuent la suppression dans la table mère…

Dans une base de données C/S, avec un trigger, le traitement s'effectue directement sur le serveur et il ne nécessite aucun appel à aucune fonction d'aucune sorte. C'est en effet la base elle-même qui va se rendre compte que l'événement de suppression de la table client nécessite un traitement et va l'exécuter.

Dans un tel exemple, le code pourrait être le suivant :

CREATE TRIGGER DELETE_CASCADE_CLIENT (CLI_ID_CLI INTEGER) BOOLEAN
BEFORE DELETE
DELETE FROM FACT WHERE (ID_CLI = CLI_ID_CLI)
DELETE FROM LIGNFACT WHERE (ID_CLI = CLI_ID_CLI)
DELETE FROM BONLIV WHERE (ID_CLI = CLI_ID_CLI)
IF ERROR
THEN
   RETURN FALSE
ENDIF
RETURN TRUE

Ce trigger comportant différentes commandes SQL devra être appelé au sein d'une transaction plus globale incluant la suppression de l'enregistrement dans la table mère. Les commandes SQL de ce trigger réclament la suppression dans les tables FACT, LIGNFACT et BONLIV de tous les enregistrements faisant référence à l'identifiant du client transmis en paramètre. Si au moins, une des requêtes échoue, le trigger renvoie False à la procédure l'ayant appelée et l'ensemble des requêtes sera annulé. Sinon, si tout va bien, le trigger renvoie True et l'ensemble des modifications sera rendu effectif par une validation (COMMIT).

Ce trigger est stocké au sein même de la définition de la base de données et s'exécute, sur le serveur, à chaque fois qu'un ordre de suppression arrive dans la table CLIENT. Il n'y a donc aucun trafic sur le réseau pour effectuer ce traitement…

En complément aux triggers, les procédures stockées permettent de stocker un traitement (opérant en général uniquement sur les données de la base) au sein même de la base de données, qui s'exécutera, par appel de la procédure au moment voulu, sur le serveur.

Exemple : une application réclame un traitement de modification des prix de vente des produits en fonction de la variation d'un certain nombre d'indices boursiers. Cette opération ne peut être déclenchée que manuellement par le responsable du service commercial…
Le code pourrait en être le suivant :

CREATE PROCEDURE AUGMENTATION_PRIX
VAR
   INDICE REAL
ENDVAR
; calcul du nouvel indice d'augmentation
; moyenne de la différence entre les anciens et les nouveaux indices
SELECT AVG(DERNIER_INDICE - INDICE_PRECEDENT) AS :INDICE
   FROM INDICE_BOURSE
; teste s'il s'agit bien d'une augmentation et non d'une diminution
; autrement dit un indice positif et non négatif
IF INDICE < 0
THEN
   RETURN
ENDIF
; effectue l'augmentation
UPDATE PRODUITS
   SET PRIX_VENTE_HT = (PRIX_VENTE_HT * (1 + (:INDICE)))
IF ERROR
THEN
   RETURN FALSE
ENDIF
RETURN TRUE

Dès lors cette procédure peut être appelée n'importe quand, par n'importe quel poste client… Elle s'exécutera sur le serveur et ne nécessitera pratiquement aucun trafic réseau.
On peut aussi imaginer qu'elle soit couplée avec un trigger ou encore exécutée à une heure différée, par exemple la nuit afin de ne pas ralentir les accès aux données plus fréquents en général dans la journée…

En plus des triggers et des procédures stockées, la plupart des SGBD C/S proposent d'historiser la « vie » des données, dans ce que l'on appelle un journal des transactions.
Celui-ci conserve une trace temporelle de toutes les insertions, suppressions, modifications intervenues dans la base de données depuis son origine.
Ce journal permet de revenir en arrière de manière partielle sur les données. L'intérêt essentiel réside dans le fait de pouvoir, en cas de crash, revenir à un état des données satisfaisant.

Reprenons l'exemple de transaction vu au paragraphe 2.2.
Pour assurer correctement la transaction constituée des 2 requêtes de mise à jour, le SGBD effectue en séquence les opérations suivantes :

1. Écrit dans le journal une étiquette permettant de repérer le début de la transaction (point de synchronisation) ;
2. Requêtes 1 : copie les données des enregistrements avant modification dans le journal ;
3. Requêtes 1 : copie les données des enregistrements après modification dans le journal ;
4. Requêtes 2 : copie les données des enregistrements avant modification dans le journal ;
5. Requêtes 2 : copie les données des enregistrements après modification dans le journal ;
6. Écrit dans le journal une étiquette indiquant que la transaction a été un succès ou un échec ;
7. Répercute les modifications des données dans les tables ;
8. Écrit dans le journal une étiquette indiquant la fin de la transaction.

De cette manière le système est capable en cas de panne survenant au cours d'une transaction de revenir dans un état stable et cohérent des données, afin d'assurer l'intégrité et donc l'atomicité de la transaction.
Pour revenir à cet état stable, le système lit le journal en débutant par la fin, et reprend toutes les transactions qui ont été un succès, sans que la mise à jour physique des données ait été effectuée. (2)(3)

Peut-on accéder aux données d'une base en s'affranchissant des requêtes ?

Un des points négatifs des systèmes C/S est que tous les traitements portant sur les données de la base doivent être, à un moment ou un autre, effectués par des requêtes. En revanche dans les systèmes à base de fichiers il est souvent possible d'accéder directement aux données en s'affranchissant des requêtes, et de procéder à un traitement en utilisant par exemple une lecture séquentielle des enregistrements d'une table.
En général les SGBD de type fichiers proposent des outils (L4G, composants…) permettant de réaliser ce genre de traitement en n'ayant à aucun moment recours aux requêtes. Dans ce cas il est souhaitable de bien connaître le format interne de la base et ses particularités .
Ce type d'accès s'avère intéressant et très souple dans le cas de bases de données de faible volume. En revanche il ne permet pas la mise à jour en une seule requête ou transaction de plusieurs tables… Autre avantage : il est indépendant de la qualité du SQL fourni. Dans le cas de « middleware » comme le moteur BDE d'Inprise (ex Borland) il permet d'unifier les traitements quelles que soient la base de données sous-jacente et sa plate-forme. On peut ainsi, théoriquement, changer de SGBD sans avoir à réécrire une seule ligne de code de l'application…
Dans le cas des SGBD C/S il est quand même possible d'effectuer des traitements locaux dans le langage de programmation en utilisant la technique des « cursor » (curseur) : le curseur est un ordre SQL qui permet de tamponner les données d'une table en mémoire et d'accéder aux données par le biais de variables pour y effectuer un traitement.

Est-il possible de contourner le mode de verrouillage optimiste, afin de le rendre pessimiste ?

Bien entendu oui. Mais le faire systématiquement serait une hérésie, notamment dans le cas d'une base de données dont le volume des transactions et le taux de mise à jour des données serait très important : des blocages intempestifs s'y produiraient fréquemment et pourraient même conduire à la paralysie du système tout entier.
Cependant réaliser un verrouillage pessimiste est d'une grande simplicité : il suffit de créer au sein de la base de données une table de sémaphore contenant le nom de l'utilisateur, le nom de la table, les références à l'enregistrement à verrouiller (par exemple son ‘ROW_ID' si le serveur est capable de le fournir). Avant toute mise à jour ou suppression il suffit de consulter la table de sémaphore, et si l'enregistrement n'y est pas référencé de l'y insérer, de procéder à la modification, puis de le supprimer de la table de sémaphore. Néanmoins il faut se prémunir de plusieurs petits problèmes sous-jacents : par exemple comment supprimer les verrous devenus obsolètes ? Cela peut arriver, notamment lorsqu'un utilisateur a commencé une modification et que son poste client a été victime d'une panne matérielle le coupant du réseau…

Le SQL est-il un langage normalisé ?

Oui, bien entendu. Il existe une norme de définition du langage SQL (SQL 2 : ISO / ANSI 92). Mais chaque éditeur est libre de se reposer ou non sur la norme. Il en résulte une forte incompatibilité entre les différents éditeurs de SGBD, que l'on peut éventuellement contourner soit en se reposant uniquement sur les éléments communs aux principaux éditeurs (très limité), soit en utilisant un middleware normatif qui dans ce cas permettra d'écrire toutes les requêtes à l'aide du SQL local et assurera sa traduction dans le SQL spécifique au SGBD.
Un des autres avantages de certains middlewares est de proposer d'effectuer des requêtes hétérogènes, c'est-à-dire entre différentes bases de données, de différents SGBD, pouvant même tourner sous différentes plates-formes système. C'est en particulier le cas du moteur BDE d'Inprise (ex Borland).

Quel langage est utilisé pour écrire des procédures stockées et des triggers ?

Malheureusement il n'existe aucun langage commun entre les différents éditeurs. De plus l'évolution des SGBDR vers les technologies de l'objet et du web font évoluer de manière importante les structures des langages des différents éditeurs d'une version à l'autre.
Par exemple Oracle porte désormais son fameux langage PL/SQL dans le monde de l'objet et le dote de modules spécialisés (bibliothèques de fonctions) permettant par exemple d'accéder aux techniques du web ou de faire du pilotage SIG (Systèmes d'Informations Géographiques).
La norme SQL 3 tente de résoudre un certain nombre de ces problèmes.

Quel type de machine est nécessaire pour faire fonctionner un SGBDR C/S ?

Il est nécessaire de se munir d'un serveur puissant, avec un processeur plutôt spécialisé dans le traitement des données de base (texte et nombre) que le graphique ou le son…
La quantité de mémoire nécessaire est évidemment bien plus importante que dans le cadre d'un SGBD fichier (par exemple sous système d'exploitation NT, un SGBDR en C/S nécessite au minimum 128 Mo de RAM même avec un nombre très restreint d'utilisateurs). Dans les deux cas, il faut avoir des disques à accès très rapide (SCSI UW par exemple) et ne pas hésiter à investir dans un contrôleur RAID éventuellement en « hot plug ».

Voici un tableau qui pourra vous aider dans votre choix de passage de l'un à l'autre :