Merise

Analyser un Systme dInformation droute parfois le non-initi, car traduire un environnement de travail en symboles cabalistiques nest pas trs habituel pour qui ne connat pas. Pourtant, avec une once de thorie et deux grammes de pratique, on se rend compte que le processus est trs abordable, soumis quelques rgles simples, faciles acqurir et qui sappliquent toujours de la mme manire. La mthode dcrite ici est MERISE, elle est Franaise et a plus de 20 ans. Elle consiste concevoir un Modle Conceptuel de Donne (MCD), le transposer en Modle Logique de Donnes Relationnelles (MLDR), puis gnrer le Modle Physique correspondant (MPD). Cest la plus rpandue des techniques danalyse de Base de Donne. Nous tudierons plus particulirement aujourd'hui la construction du Modle Conceptuel de Donne et de ses 5 caractristiques : Entits, Proprits, Identifiants, Associations, Cardinalits. Le Systme d'Information La premire priorit est de transformer ce que lon veut analyser en mots simples. Lcriture de cette petite rdaction permet elle seule de bien comprendre ce que lon va modliser. Il sagit ce stade d?tablir un lien entre linformaticien et les utilisateurs, il ne faut donc pas hsiter faire relire votre petit texte et poser toutes les questions qui vous viennent l?esprit afin de bien analyser lexistant. La difficult principale est darriver faire abstraction de vos habitudes de programmation : ce stade, nous sommes totalement indpendant du matriel et du logiciel. Ne pensez pas en terme de tables. Pensez en terme dentits. Prenons lexemple trs simple dun logiciel ayant pour but de grer les envois de NewsLetters aux abonns dun site ayant plusieurs rubriques. Le service marketing veut aussi savoir quelle raison a pouss labonn sinscrire en lui proposant plusieurs choix de motivations lors de son inscription. Le Systme dInformation se dcrit ainsi : "Un abonn est inscrit une ou plusieurs rubrique. Chaque rubrique envoie une NewsLetter chaque semaine aux abonns de la rubrique correspondant. Un abonn a une motivation dinscription parmi plusieurs possibles." Ces quelques phrases, si elles sont exactes et valides par le client, sont suffisantes pour modliser notre premier modle. Elles contiennent en effet toutes les informations ncessaires. Identifier les entits prsentes Lentit ABONNES reprsente lensemble des abonns. Lentit RUBRIQUES lensemble des rubriques auxquelles labonn peux sinscrire. Lentit NEWSLETTERS reprsente les newsletters envoyes, MOTIVATIONS lensemble des motivations dinscriptions des abonns. Do les 4 entits :

Gnralement, une entit est cre dans le Systme dInformation si elle possde au moins 2 occurrences. Chaque lment dune entit? est appel une occurrence de lentit. Lister les proprits des entit Un Abonn est caractris par son nom, son prnom, son ge, son sexe, sa profession, sa rue, son code postal, sa ville, son pays, son tlphone et son email. Une Newsletter est caractrise par son sujet, sa date d?envoi et son contenu. 1

Une Motivation est caractrise par son intitul. Une Rubrique est caractrise par son nom. Les 4 entits deviennent :

Afin de ne pas en avoir trop, on se limite gnralement aux proprits ncessaires au dveloppement. Chaque proprit doit avoir une seule valeur possible pour chaque occurrence, sinon il sagit d?une entit. Elle doit de plus tre lmentaire et non dcomposable. Par exemple, ladresse nest pas une proprit lmentaire : elle comporte une rue, un Code Postal et une ville qui elles, sont 3 proprits lmentaires. Identifier de manire unique chaque occurrence Imaginons que nous ayons deux abonns qui sappellent DUPOND : il est ncessaire de les distinguer sous peine de les confondre. On rajoute alors une proprit qui permettra didentifier de manire unique chaque occurrence. Cette proprit est appel lidentifiant de lentit. Cela peut tre une rfrence interne, un code, ou plus gnralement un nombre entier. Cette proprit est souligne afin de mettre en vidence son rle didentifiant. Les 4 entits sont finalement :

Etablir les relations entre les diffrentes entits Maintenant, il sagit didentifier les relations entre les entits. Gnralement, la simple transposition du texte suffit, les Sujets et Complments d'Objets tant les entits, et les Verbes les relations. Reprenons notre texte initial : "Un Abonn a une Motivation. Un Abonn sinscrit une ou plusieurs Rubriques. Chaque Rubrique envoie une NewsLetter." Les verbes sont en rouge et relient les entits. Il suffit de les intgrer au schma :

Identifier les cardinalits Il faut maintenant tablir le nombre possible dinteractions entre les entits. Il sagit dun couple dentiers de type ( a ; b) . a est la cardinalit minimum, et est gal 0 ou 1. b est la cardinalit maximum, et est gal 1 ou n, n tant plus grand que 1. Continuons notre exemple : Un Abonn a ici une et une seule Motivation dinscription, le marketing ayant impos un champ obligatoire afin davoir cette valeur. On a donc 1 minimum, et 1 maximum. Do la cardinalit (1;1). Une Motivation donne concerne 0 ou plusieurs Abonns. On a donc 0 minimum, et n en maximum. Do la cardinalit (0;n). De mme, un Abonn sinscrit une ou plusieurs Rubriques : (1;n), Et une Rubrique possde 0 ou plusieurs Abonns : (0;n). Enfin, une Rubrique envoie 0 ou plusieurs Newsletters : (0;n), Et une Newsletter appartient une et une seule Newsletter : (1;1). Il suffit maintenant de marquer ces couples sur le schma, et nous avons notre Modle Conceptuel de Donne (MCD) :

Valider le Modle avec le client

A ce stade, il est ais daller voir encore une fois les utilisateurs du logiciel final, afin de discuter le MCD avec eux. Cela vous permettra dentriner les proprits quils dsirent utiliser, dtre bien certain des cardinalits, et de valider avec eux cette partie de votre travail. Un MCD doit pouvoir s'expliquer avec des phrases simples et tre comprhensible par tout le monde. Il ne sagit ni plus ni moins que de modliser lexistant. Ainsi, vous serez certain de faire le dveloppement demand, et cela vous permettra de vous protger par la suite en cas de nouvelles demandes ou de modification du cahier des charges. Il est important de bien raliser que jusqu' ce stade, toute cette analyse sest droule totalement indpendamment de la machine ou de toute contrainte logicielle. Ces rgles fonctionnent toujours, mme si il peux y avoir parfois plusieurs solutions pour chaque modles. Le processus de modlisation, aprs quelques tentatives, est trs simple acqurir. Enfin, une fois le Modle Conceptuel de Donne tabli, vous aurez fais le plus difficile. La conception de la base qui en dcoule est mcanique, et repose sur 6 rgles strictes, ncessaires et suffisantes. Transformer un MCD en Modle Logique, puis Physique est tellement standardis que certains logiciels le font automatiquement.... Merise : 2me partie Aprs avoir conu le Modle Conceptuel de Donne (MCD), il est maintenant temps de le transposer en Modle Logique de Donnes Relationnelles (MLDR). Ce MLDR est en fait le dernier pas vers le Modle Physique de Donne (MPD), c'est dire la description de la base qui va tre cre. Et l, deux solutions s'ouvrent vous : soit vous laissez un programme le soin de transformer votre MCD, soit vous le fates vous-mme. Dans les deux cas, il est utile d'avoir un minimum de connaissance thorique sur le sujet. Aprs avoir dfinis les notions de cl primaire et de cl trangre, nous tudierons plus particulirement aujourd'hui les 6 rgles strictes, ncessaires et suffisantes pour passer d'un MCD un MLDR, et nous les appliquerons ensuite au schma de Newsletter que nous avons cris la dernire fois. Prliminaires : le Modle Logique de Donne (MLD) Il s'agit du passage entre le Modle Conceptuel de Donne et l'implmentation physique de la base. Le MLD est lui aussi indpendant du matriel et du logiciel, il ne fait que prendre en compte l'organisation des donnes. C'est d'ailleurs le point primordial de la modlisation : si l'organisation des donnes est relationnelle (si elles sont "lies" entre elles), alors le MLD est Relationnel et devient le MLDR, ou Modle Logique de Donne Relationnel. Pour la petite histoire, le MLDR a t invent par Codd en 1970, et repose sur la Thorie Ensembliste... Un peu de vocabulaire : Les donnes sont stockes dans des relations. Une relation est un ensemble de Tuple, et un T-uple est dfinis par un ou plusieurs attributs. Dans la pratique, la relation est en fait la table, un T-uple est une ligne (ou enregistrement), et les attributs sont les colonnes. Exemple de la table NEWSLETTER :

Cette table est dcrite par : NEWSLETTER (id_newsletter, Sujet, DateEnvoie, Contenu, #id_rubrique) Chaque enregistrement doit tre identifi de manire unique (voir la notion d'identifiant aborde dans l'article 4

prcdent). L'attribut qui permet d'identifier de faon unique chaque ligne est appel la Cl Primaire. Elle peut tre compose, c'est dire comprendre plusieurs attributs. Ici, il s'agit de l'attribut id_newsletter. La table Newsletter comprend un attribut provenant de la table RUBRIQUES, l'attribut id_rubrique. Cet attribut est appel Cl Etrangre. Dans le formalisme, la cl primaire est souligne, et la cl trangre est prcde du signe #. D'o l'criture dfinitive : MATABLE (Cle_Primaire, Colonne1, Colonne2, #Cle_Etrangere) Dans notre exemple : Rubrique (id_rubrique, Nom) Newsletter (id_newsletter, Sujet, DateEnvoie, Contenu, #id_rubrique) Ici, id_rubrique est la Cl Primaire de la table RUBRIQUE, et est une Cl Etrangre dans la table NEWSLETTER. Une fois assimile ces notions de cls primaires et de cls trangres, nous pouvons maintenant noncer les rgles suivantes : 1 : Une entit se transforme en une relation (table) Toute entit du MCD devient une relation du MLDR, et donc une table de la Base de Donne. Chaque proprit de l'entit devient un attribut de cette relation, et dont une colonne de la table correspondante. L'identifiant de l'entit devient la Cl Primaire de la relation (elle est donc souligne), et donc la Cl Primaire de la table correspondante.

<==>

CLIENT (id_client, Nom_Client, Tel_client)

2 : Relation binaire aux cardinalits (X,1) - (X,n), X=0 ou X=1 La Cl Primaire de la table la cardinalit (X,n) devient une Cl Etrangre dans la table la cardinalit (X,1) : Exemple de Systme d'Information (SI) : Un employ a une et une seule socit. Une socit a 1 ou n employs. Modle Conceptuel de Donne (MCD) :

Modle Logique de Donne Relationnelle (MLDR) :

EMPLOYE (id_Employe, Nom_Employe, #id_Societe) SOCIETE (id_Societe, Nom_Societe) Modle Physique de Donne (MPD), ou schma de base :

3 : Relation binaire aux cardinalits (X,n) - (X,n), X=0 ou X=1 Il y a cration d'une table supplmentaire ayant comme Cl Primaire une cl compose des identifiants des 2 entits. On dit que la Cl Primaire de la nouvelle table est la concatnation des Cls Primaires des deux autres tables. Si la relation est porteuse de donne, celles ci deviennent des attributs pour la nouvelle table. S.I. : Une commande est compose de 1 ou n produits distincts en certaine quantit. Un produit est prsent dans 0 ou n commandes en certaine quantit. MCD :

MLDR : COMMANDE (id_Commande, Date_commande) PRODUIT (id_Produit, libelle) COMPOSE (id_Commande, id_Produit, quantit) MPD :

4 : Relation n-aire (quelles que soient les cardinalits). Il y a cration d'une table supplmentaire ayant comme Cl Primaire la concatnation des identifiants des entits participant la relation. Si la relation est porteuse de donne, celles ci deviennent des attributs pour la nouvelle table. 6

S.I. : Un tudiant parle une ou plusieurs langues avec un niveau. Chaque langue est donc parle par 0 ou n tudiants avec un niveau. Pour chaque niveau, il y a 0 ou plusieurs tudiants qui parlent une langue. MCD :

MLDR : ETUDIANT (id_Etudiant, Nom_Etudiant) NIVEAU (id_Niveau, Nom_Niveau) LANGUE (id_Langue, Nom_Langue) PARLE (id_Etudiant, id_Niveau, id_Langue) MPD :

5 : Association Rflexive.

Premier cas : cardinalit (X,1) - (X,n), avec X=0 ou X=1. La Cl Primaire de l'entit se ddouble et devient une Cl Etrangre dans la relation ou nouvelle table. Exactement comme si l'entit se ddoublait et tait relie par une relation binaire (X,1) - (X,n) (Cf rgle 2). S.I. : Prenons l'exemple d'une socit organise de manire pyramidale : chaque employ a 0 ou 1 suprieur hirarchique direct. Simultanment, chaque employ est le suprieur hirarchique direct de 0 ou plusieurs employs. MCD :

MLDR : EMPLOYE (id_Employe, Nom_Employe, #id_Sup_Hierarchique) #id_Sup_Hierarchique est l'identifiant (id_Employe) du suprieur hirarchique direct de l'employ considr. MPD :

Deuxime cas : cardinalit (X,n) - (X,n), avec X=0 ou X=1.

De mme, tout se passe exactement comme si l'entit se ddoublait et tait relie par une relation binaire (X,n) - (X,n) (Cf rgle 3). Il y a donc cration d'une nouvelle table. S.I. : Prenons cette fois l'exemple d'une organisation de type familiale : chaque personne a 0 ou n descendants directs (enfants), et a aussi 0 ou n descendants directs (enfants). MCD :

MLDR : PERSONNE (id_Personne, Nom_Personne) PARENTE (#id_Parent, #id_Enfant) #id_Parent est l'identifiant (id_Personne) d'un ascendant direct de la personne. #id_Enfant est l'identifiant (id_Personne) d'un descendant direct de la personne. La table PARENTE sera en fait l'ensemble des couples (parents-enfants) prsent dans cette famille. MPD :

6 : Relation binaire aux cardinalits (0,1) - (1,1). La Cl Primaire de la table la cardinalit (0,1) devient une Cl Etrangre dans la table la cardinalit (1,1) : S.I. : Dans ce centre de vacances, Chaque animateur encadre en solo 0 ou 1 groupe, chaque groupe tant encadr par un et un seul animateur. MCD :

MLDR : ANIMATEUR (id_Animateur, Nom_Animateur) GROUPE (id_Groupe, Nom_Groupe, #id_animateur) MPD :

CONCLUSION Ces 6 rgles reprsentent TOUS les cas que vous pourrez rencontrer. Il ne faut surtout pas se laisser impressionner par le nombre de schmas, ni se laisser intimider par le cot inhabituel du processus de modlisation. Il est trs simple acqurir. En fait, au bout de quelques modlisations et d'un ou deux dveloppements, vous vous rendrez compte que finalement tout ceci est trs logique et d'une vidence rare... Et surtout, surtout, votre base de donne correspondra EXACTEMENT au systme d'information dcris dans le cahier des charges. De plus, crire le MCD, le valider avec votre client, puis en dduire le MLDR et donc le Modle Physique vous fera rentrer compltement dans le chantier. Vous irez ensuite beaucoup plus vite, avec trs peu de risque d'tre hors sujet. Aprs, la majorit du travail restant ne sera plus qu'une question de requtes, de mise en forme et d'ergonomie, avec une bonne gestion d'Entre/Sortie de l'information...

Allez, si vous tes encore avec moi, vous avez bien mrit la fin de l'analyse de notre Newsletter du mois de dcembre :

Entrane le MLDR suivant : MOTIVATIONS ( id_Motivation, Intitule) ABONNES ( id_Abonne, #id_Motivation, Nom, Prenom, Age, Sexe, Profession, Rue, CodePostal, Ville, Telephone, Email) S_INSCRIT ( id_Abonne, id_Rubrique) RUBRIQUES ( id_Rubrique, Nom_Rubrique) NEWSLETTERS ( id_Newsletters, #id_Rubrique, Sujet, DateEnvoie, Contenu)

Qui nous mne au Modle Physique de Donne (MPD) ou schma de la Base :

10

Merise: 3me partie

Modliser, c'est comprendre. Pour dvelopper le logiciel dont les utilisateurs ont besoin, l'informaticien ne doit pas correspondre aux strotypes de notre imaginaire collectif. Au contraire, il lui appartient de s'ouvrir, d'aller vers les utilisateurs de son travail, de cerner quels sont leurs besoins, de discuter avec eux et de les regarder travailler. C'est ainsi qu'il cernera au mieux leurs attentes et qu'il apprendra se mettre la porte des utilisateurs de son travail : rien de tel qu'observer un journaliste rlant devant son interface "qui veux pas faire ce que je lui dis, euh !!!" pour se rendre compte qu'il vaut mieux se mettre la place de l'utilisateur final afin qu'il soit satisfait de son programme. Car c'est de cette manire que l'on obtient la rcompense suprme : voir un client heureux d'utiliser son nouveau logiciel, et surtout le voir travailler avec durant longtemps. Attachons-nous ce noble objectif : aprs avoir comment le MPD ou Schma de Base de la Newsletter vue prcdemment et avoir regard ce qu'il reprsente vritablement, je vous proposerais un autre exemple significatif. Utiliser le Modle Physique de Donne : Une fois le systme d'information analys et modlis en Modle Conceptuel de Donne (MCD), et aprs tre pass par le Modle Logique de Donne Relationnel (MLDR), nous arrivons au Modle Physique de Donne (MPD). Il s'agit maintenant de crer la base correspondante l'tude entame. C'est ce stade seulement que la base de donne choisie intervient. Le SQL (Structured Query Language), ou Langage d'Interrogation Structur, a t reconnu en tant que norme officielle de langage de requte relationnelle par l'institut ANSI (American National Standards Institute) et par l'organisme ISO (International Standards Organization). Malgr cela, les syntaxes d'extractions des donnes et de crations des tables varient quelques peux d'une base l'autre. En particulier, si la base de donne utilise pour le dveloppement n'est pas vritablement relationnelle (cas de MySql dans sa version actuelle), il appartiendra au dveloppeur de prendre lui-mme en charge les limitations rencontres, afin de s'assurer que sa base ne puisse JAMAIS tre corrompue, c'est dire contenir des donnes aberrantes. APPLICATION SUR UN MODELE PHYSIQUE CONCRET :

11

Prenons l'exemple du schma de base (MPD) suivant :

La table MOTIVATIONS est trs simple crer : elle comporte deux champs, ID_MOTIVATIONS et INTITULE. ID_MOTIVATIONS est la Cl Primaire. ABONNES comporte les 12 champs du schma. ID_ABONNES est la cl primaire. ID_MOTIVATIONS est une cl trang7re provenant de MOTIVATIONS, c'est dire que sa valeur doit tre toujours gale une valeur de ID_MOTIVATIONS de MOTIVATIONS. L'intrt majeur des cls trangres est surtout d'viter les redondances, sources d'erreurs.
o

Pour les bases non totalement relationnelles : Il appartiendra au dveloppeur de vrifier lors de chaque insertion dans ABONNES que l'ID_MOTIVATIONS fournis fais partie des valeurs existantes de ID_MOTIVATIONS de MOTIVATIONS. De mme, lors de chaque suppression d'un enregistrement de MOTIVATIONS, il faudra vrifier qu'aucun enregistrement d'ABONNES n'utilise la valeur d'ID_MOTIVATION correspondante.

S_INSCRIT comporte deux champs, ID_ABONNES et ID_RUBRIQUE. ID_ABONNES et ID_RUBRIQUE sont cl primaire de S_INSCRIT : S_INSCRIT a comme cl primaire la concatnation de ces deux champs. C'est dire que tout couple (ID_ABONNES,ID_RUBRIQUE) de S_INSCRIT est unique. ID_ABONNES est aussi cl trangre de ABONNES dans S_INSCRIT, et ID_RUBRIQUE est cl trangre de RUBRIQUE dans S_INSCRIT. Une telle table est communment appele "Table de Lien". L'intrt d'une telle table est que pour chaque ID_ABONNES donn, il est ais de retrouver tous les ID_RUBRIQUE associs, et vice et versa.
o

Pour les bases non totalement relationnelles : Il faudra vrifier lors de chaque insertion dans S_INSCRIT que le couple (ID_ABONNES,ID_RUBRIQUE) n'existe pas dj dans la table S_INSCRIT, que ID_ABONNES existe dans ABONNES et que ID_RUBRIQUE existe dans RUBRIQUE. De mme, pour chaque suppression d'un abonn, il faudra supprimer tous les couples (ID_ABONNES,ID_RUBRIQUE) ayant l'ID_ABONNE correspondant. Pareil pour

12

toute suppression de RUBRIQUE.

RUBRIQUE est elle aussi trs simple crer : elle comporte deux champs, ID_RUBRIQUE et NOM_RUBRIQUE. ID_RUBRIQUE est la Cl Primaire. NEWSLETTERS comprend les 5 champs du schma. ID_NEWSLETTER est la cl primaire. ID_RUBRIQUE est une cl trangre provenant de RUBRIQUE.
o

Pour les bases non totalement relationnelles : Il faudra vrifier lors de chaque insertion dans NEWSLETTER que ID_RUBRIQUE existe dans RUBRIQUE. De plus, pour chaque suppression d'une rubrique, il faudra s'interroger sur le sort rserv chaque newsletter de cette rubrique : les dtruire ou les archiver.

APPLICATIONS AUX BASES RELATIONNELLES : Les vrifications dtailles prcdemment n'ont lieu que pour assurer la cohrence de la base. Il est donc logique, si celle ci le permet, de dlguer et d'automatiser ces taches au niveau ce celle-ci. Gnralement, les vrifications affrentes une cl trangre sont confies un Trigger (un Trigger est un ensemble d'instruction SQL s'effectuant avant ou aprs un vnement donn, par exemple une insertion ou une suppression). Ainsi, lors de chaque commande d'insertion sur la table dsigne au Trigger pralablement correctement programm, celui ci va vrifier AVANT l'insertion que la cl trangre est valable. Dans le cas ou elle ne le serait pas, le Trigger renvoie un message d'erreur et l'insertion ne s'effectue pas, vitant ainsi de corrompre la base. De mme, certains traitements automatiss pourront tre raliss directement l'aide de procdures stockes. Exemple : un devis valid qui entrane la cration de la facture correspondante. Et surtout, les Trigger et Procdures Stockes tant compiles directement par la Base de Donne, leur excution est beaucoup plus rapide qu'une srie d'instruction SQL envoyes par le programme attaquant la base. Une base de donne correctement pense est envisager comme un contenant d'information "vivant", forcement cohrent, aux ractions automatises. Une telle base se suffirait presque elle-mme pour grer un Systme d'Information. Le dveloppement ne consisterait alors plus qu' afficher son contenu en temps rel, et fournir les outils d'insertion appropris. Le rve... SECOND EXEMPLE : MODELISER UN DOCUMENT Il est courant, lors du dveloppement d'un site Web ou de l'informatisation d'un systme d'information, de dmarrer son analyse par un document. Captures d'crans, photocopies, sont parfois les principales pices jointes la demande de devis, accompagns du commentaire suivant : "Je veux faire a !!!". Bien. Alors, faisons a... Systme d'Information : L'entreprise "WebCash" de vente par correspondance dsire ajouter son site un systme de consultation de factures visible en ligne pour ses clients. Chaque client, aprs authentification, pourra accder toutes les factures le concernant, qu'elles soient anciennes ou en cours de traitement indiffremment. Pour tre sur de bien se faire comprendre, "WebCash" fournis une copie d'une facture type en disant : "C'est a qu'on veut sur l'cran !"

13

Voici une copie de cette facture : WebCash S.A.R.L 24, Avenue des Rves roses 75008 PARIS Nom : Prnom : Adresse : Code Postal : Ville : BIDOCH Robert 12, rue du centre 70000 Gray FACTURE N 12345

Paris, le 15/10/2000

N Article 234 568 132

Libell Stylo Plume Couteau Suisse Serviette

Prix Unitaire 12.5 F 75.00 F 30.00 F

Quantit 1 2 1

Prix 12.50 F 150 F 30.00 F

TOTAL TTC : 192.50 F Dont TVA 19.6% : 37.73 F A PAYER : 192.50 F Avec nos plus cordiaux remerciements Voil, tous les lments sont runis. Il ne reste plus qu' concevoir la Base de Donne se cachant derrire cette innocente petite facture. Cet exemple est trs conforme la ralit. Il sera trs intressant tudier, car il permettra d'expliquer un certain nombre de points, et de mettre en vidence certaines erreurs ne pas commettre. N'hsitez pas prendre le stylo et vous entraner, je vous fournirais une solution commente la prochaine fois.

Merise: 4 me partie
Dans la famille "Je cherche comprendre le Systme d'Information que je modlise", je propose les documents fournis par votre client. Car s'il sera ais de discuter avec lui de l'exactitude du MCD, comprendre son environnement de travail peut parfois tre plus ou moins vident : ses explications seront rarement compltements explicites du premier coup, et il est courant que le client lui-mme n'ai qu'une vague ide de ce qu'il veut faire. C'est l que, arme de toute notre diplomatie et de notre pdagogie, commence la partie la plus palpitante de notre travail : "Comprendre ce que veux le client, et comment a marche". Car vous n'avez pas envie de recommencer 10 fois votre travail et de modifier votre code tout le temps, n'est ce pas ? Il va donc falloir poser des questions, aller voir comment il se dbrouille actuellement, amasser un maximum de documents, et en retirer le maximum d'informations. Car tre certain de comprendre les besoins de l'utilisateur qu'il exprime avec ses mots lui, c'est l tout le but de la modlisation. MODELISER UN DOCUMENT : UNE PRATIQUE COURANTE Commenons par terminer l'exemple de la dernire fois, dont re-voici l'nonc : Systme d'Information :

14

L'entreprise "WebCash" de vente par correspondance dsire ajouter son site un systme de facturation visible en ligne pour ses clients. Chaque client, aprs authentification, pourra accder toutes les factures le concernant, qu'elles soient anciennes ou en cours de traitement indiffremment. Pour tre sur de bien se faire comprendre, "WebCash" fournis une facture type en disant : "C'est a qu'on veut sur l'cran !" Voici une copie de cette facture : WebCash S.A.R.L 24, Avenue des Rves roses 75008 PARIS Nom : Prnom : Adresse : Code Postal : Ville : BIDOCH Robert 12, rue du centre 70000 Gray FACTURE N 12345

Paris, le 15/10/2000

N Article 234 568 132

Libell Stylo Plume Couteau Suisse Serviette

Prix Unitaire 12.5 F 75.00 F 30.00 F

Quantit 1 2 1

Prix 12.50 F 150 F 30.00 F

TOTAL TTC : 192.50 F Dont TVA 19.6% : 37.73 F A PAYER : 192.50 F Avec nos plus cordiaux remerciements

APPLICATION DE LA METHODE MERISE Elle consiste construire le Modle Conceptuel de Donne (MCD), Gnrer le Modle Logique de Donnes Relationnelles (MLDR), et le transposer en Modle Physique de Donne (MPD).

Construire le Modle Conceptuel de Donne (MCD) :

La mthode est toujours la mme : Identifier les entits prsentes, Lister les proprits des entits, Identifier de manire unique chaque occurrence, Etablir les relations entre les diffrentes entits, et Identifier les cardinalits.

Identifier les entits prsentes : On relve trois entits : CLIENT, FACTURE, ARTICLE. o CLIENT est l'ensemble des clients de la socit WebCash. Une occurrence de cette entit est prsente par Robert BIDOCH, qui est le client qui cette facture est destine. o FACTURE est l'ensemble des factures mises par WebCash, dont une occurrence est prsente en "FACTURE N 12345". o ARTICLE est l'ensemble des articles vendus par WebCash, dont trois occurrences sont 15

o o

prsentes, dnomms Stylo Plume, Couteau Suisse et Serviette. Une facture tant compose de plusieurs lignes, il aurait t possible de relever l'entit LIGNE_FACTURE : elle n'est utile que si l'on dsire archiver pour chaque ligne son Numro. La base dduite aurait t sensiblement la mme, dmontrant ainsi que plusieurs solutions sont parfois possibles. La TVA est ici considre comme constante et unique. Dans le cas contraire, elle aurait reprsent l'entit TVA. La socit WebCash ne reprsente pas une occurrence d'une entit, car c'est la seule socit mttrice de facture de notre analyse.

Lister les proprits des entits : o Un CLIENT est caractris par son Nom, son Prnom, son Adresse, son CodePostal et sa Localit. Afin de pouvoir s'authentifier, il est aussi caractris par un Login et un Passwd. o Une FACTURE est caractrise par son Numro, et sa Date d'mission. o Un ARTICLE est caractris par son Numro, son libell, et son PrixUnitaire. Le prix total, de par son PrixUnitaire et sa quantit, peux tre recalcul : ce n'est donc pas une caractristique de l'ARTICLE. o Chaque proprit doit avoir une seule valeur possible pour chaque occurrence, ce qui est ici le cas. Elle doit de plus tre lmentaire et non-dcomposable, ce qui est aussi le cas. D'une manire gnrale, toute information rsultant d'un calcul n'est pas une caractristique d'une entit.

Identifier de manire unique chaque occurrence : chaque occurrence de chaque entit doit pouvoir tre identifie de manire unique : cette proprit s'appele l'identifiant. o Un CLIENT sera identifi par un Numro unique, cette caractristique de l'entit tant appel id_Client. o Une FACTURE sera identifie par son Numro qui est unique. Cette caractristique sera appele id_Facture. o Un ARTICLE sera identifi par son Numro qui est lui aussi unique. Cette caractristique sera appele id_Article.

Etablir les relations entre les diffrentes entits : Un CLIENT obtient une FACTURE qui contient des ARTICLES en certaine quantit. Identifier les cardinalits : o Un mme CLIENT obtient 1 ou plusieurs FACTURE. o Une mme FACTURE est obtenue par un seul CLIENT. o Une mme FACTURE contient 1 ou plusieurs ARTICLE. o Un ARTICLE est contenu dans 0 ou n FACTURE.

On en dduit donc le MCD suivant :

16

Comme d'habitude, il est alors temps de retourner voir le client et de discuter le Modle avec lui, afin de vrifier qu'il ne manque rien et que l'analyse correspond bien SA ralit de travail. Aprs validation, il est temps de passer l'tape suivante.

Gnrer le Modle Logique de Donnes Relationnelles (MLDR) :

Relation (X,1)-(X,n) entre FACTURE et CLIENT : CLIENT (id_Client, Nom, Prenom, Adresse, CodePostal, Localite, Login, Passwd) FACTURE(id_Facture, #id_Client, Date) Relation (X,n)-(X,n) entre FACTURE et ARTICLE : CONTIENT(#id_Facture, #id_Article, Quantite) ARTICLE(id_Article, Libelle, PrixUnitaire)

Transposer en Modle Physique de Donne (MPD) :

Voil, il ne reste plus qu' crer la base, la remplir, et dvelopper dessus. UNE BASE DE DONNEE COHERENTE Un tel modle est dit cohrent, c'est dire que pour chaque donne fournie, il permet de retrouver toutes les informations s'y rattachant. Pour chaque client donn, il sera possible d'avoir toutes ses factures, et donc tous les articles qu'il a achets et en quelle quantit. Pour chaque facture, il sera possible de retrouver le client correspondant, ainsi que la liste des articles et leurs quantits respectives. Enfin, pour chaque article, il sera ais de retrouver les quantits 17

vendues, quelle date et quels clients. La base ne contient aucune redondance, c'est dire qu'aucune information prsente ne peut tre dduite d'autres informations prsentes. Ceci vite grandement le risque de corruption, ou prsence de donne aberrante. Les prix intermdiaires, la somme totale et autres rsultats sont des traitements, c'est dire qu'ils sont calculs par rapport aux informations contenues dans la base. Ainsi, toute erreur sera forcemment une erreur de calcul, et non pas une erreur de stockage. Il est plus facile de vrifier un programme d'extraction de donne que de vrifier la cohrence du contenu d'une base. LES AVANTAGES D'UN TEL RESULTAT Le dveloppement se rduit maintenant une interface d'administration (BackOffice) ou WebCash pourra ajouter/modifier/supprimer ses ARTICLES, rentrer ses FACTURES, et consulter son fichier CLIENT. Ensuite, sur le site lui-mme (FrontOffice), il ne reste plus qu' faire le formulaire d'accrditation du CLIENT (Login/Passwd) qui permettra de retrouver son identifiant, puis lui lister les FACTURE correspondant cet identifiant, et enfin lui afficher le dtail de celle qu'il aura slectionn. Si ce dveloppement parat au final aussi simple, c'est qu'il s'appuie sur une base bien pense. Si celle-ci correspond effectivement l'environnement de travail de WebCash, il n'y aura aucune raison de la changer. Vous obtiendrez ainsi la meilleure des rfrences et des publicits : concevoir un outil simple utiliser qui marche durant longtemps sans avoir tre modifi. Et a, pour un client, c'est vraiment le top du top. Merise: 5me Partie Vous tes encore nombreux ne pas tre vraiment convaincus de la ncessit de passer par la phase d'analyse avant de commencer rellement coder. Peut-tre est-ce due cette impression qu'a souvent l'autodidacte (ou le dbutant) que ce travail n'est pas rellement rentable. De mme, un client (ou un patron) peut avoir le sentiment de jauger l'volution d'un travail au nombre de lignes crites, la rapidit ou les pages lui sont fournies, et donc ce qu'il voit. Aprs tre revenus sur ces phnomnes trs rpandus, je vous prsenterais une introduction une analyse beaucoup plus consquente, analyse qui a servie de base un logiciel grant la coupe du monde en France en 1998. Car quand les choses se compliquent un tout petit peu (et cela arrive trs trs vite, et de plus en plus couramment), il n'est plus question d'amateurisme sous peine de risquer, cette fois, le naufrage total... "Vite ! Pas Chre ! Et tout de suite." Comme tout un chacun, l'investisseur (client, directeur) raisonne trs souvent court terme et exige rapidement des preuves que l'argent qu'il investit est correctement utilis, et que le temps de travail qu'il paye est rentabilis au maximum. Lui expliquer que quelques jours ou quelques heures de rflexions sont parfois ncessaires pour l'analyse peut le plonger dans un tat suspicieux, avec parfois mme le sentiment d'tre tromp sur le temps de travail factur. Pourtant, cette phase prliminaire reprsente les fondations mme de son projet : il vaut mieux qu'il ait son site quelques jours plus tard mais que celui-ci soit correctement pens et dvelopp de manire professionnelle. Ainsi, son bon fonctionnement, son volutivit et sa maintenance rentabiliseront largement son trs lger investissement. "Analyser ? Rflchir ?? Mais pour quoi faire ???" Un autre phnomne trs rpandu est celui du "bidouilleur" : rgulirement autodidacte, et gnralement brouillon, il pense tre capable de tout faire en mettant lui-mme la main la pte. Trs souvent, il s'agit d'un commercial persuad qu'il pourra faire seul ce qui lui semble long et cher sans raison. Dans un premier temps, 18

il semblera y arriver, force de persvrances et d'interventions qui lui paratront tre de petites astuces trs intelligentes et qu'il ajoutera ici et l, trs content de lui-mme et de son rsultat immdiat. Mais cela se termine toujours de la mme manire : son code et ses fichiers se rvelent tre devenus si foullis et si incomprhensibles qu'il finira par tre incapable de faire fonctionner quoi que ce soit, et devra se rsoudre appeler au secours. Seulement, il est souvent trop tard, et la seule solution viable pour son site Web est de le redvelopper entirement et correctement. Et l, a cote beaucoup plus cher que quelques heures d'analyse ou les conseils d'un professionnel. Improviser : limination directe ? Prenons un nouvel exemple un plus complexe : en 1998, a eu lieu en France la coupe du monde de Football. De trs nombreux sites Web ont alors entam des dveloppements spcifiques, afin de prsenter un certain nombre d'informations concernant la comptition aux internautes. Leur besoin a tout d'abord t de fournir leurs journalistes des outils rdactionnels afin de leur permettre d'afficher en ligne les articles concernant la comptition. La plupart de ces sites tant dj dots d'interfaces de travail pour les autres secteurs d'actualits, cette tache s'est gnralement rvle assez simple. Mais, pour ce qui concernait le stockage et la prsentation des rsultats et des statistiques, ce fut une tout autre histoire... Extraits d'un petit briefing de l'quipe technique : "Ecoute, le webmaster, vient voir : L, il y a la coupe du monde qui commence la semaine prochaine. On va prsenter les scores des matchs, et deux trois petits classements faciles. Tu nous fais un machin hyper-simple pour qu'on puisse faire un max d'audience avec tous les footeux. Tu vois, un petit programme o l, on rentre les buts et les cartons, et quand on clique ici, sur le site, on voit tout comme il faut. Comme a, les journalistes, ils marquent dans une petite fentre que le match a eu lieu ici, avec les joueurs qui jouent, les buteurs qui marquent, les remplacs qui sortent et le type qui arbitre. Comme dans le journal, quoi.... Toi, tu leur fais gentiment une moulinette pour stocker tout a et tout afficher tranquillement sur le site quand le surfeur il le demande. OK ? Ca va ? Tu vois, un truc comme a, tranquille..." Eh ben c'tait pas gagn... Tacle en retard : carton Rouge ! Je ne sais pas si vous vous souvenez du spectacle alors offert par certains des sites Web concerns : joueurs ayant marqu 327 fois en 4 matchs, Barthez dans l'quipe du Brsil, Zidane finaliste en totalisant 23 minutes de jeux sur le terrain, rsultats farfelus, quand rsultats tout court il y eut. Car bien souvent, le dveloppement se rsuma en dernier ressort afficher en catastrophe des pages statiques avec les feuilles de match, les classements et les rsultats crits directement en dur, dans des pages HTML fixes. Il y eu mme des sites trs connus (qu'on ne citera pas) qui furent totalement incapables de prsenter le moindre rsultat avant la fin de l'preuve ! Pour ceux qui seraient interresss, j'ai concoct une petite analyse sur cette preuve. Bien videmment, selon les informations que l'on voudra stocker ou prsenter, certaines modifications peuvent tre apportes. Il ne faut pas perdre de vue que dans ce type d'analyse, il n'y a pas UNE mais bien souvent plusieurs solutions. Tout dpend de ce que l'on veut rellement faire. Nanmoins, cela devrait tout de mme ressembler cela :

19

Cliquez sur les schmas pour les agrandir :

MCD

MPD

Bien grer les individualits Un petit mot sur ce MCD et ce MPD :

On remarque tout d'abord les cardinalits (1,1) mises entre parenthses : elles dcrivent ce que l'on appelle des entits dpendantes. En effet, une Equipe est lie son Groupe, de mme qu'un But et un TirsAuBut ne peuvent exister sans le Match lors duquel ils ont t marqus. Cela s'appelle un identifiant relatif. La consquence d'un identifiant relatif est que la table gnre par l'entit a comme double cl primaire son propre identifiant ainsi que l'identifiant de l'entit dont elle dpend.

Le champ NBPOINTS de la table EQUIPE : ce renseignement pourrait tre retrouv par une requte approprie prenant en compte les rsultats des matchs jous prcdemment. Nanmoins, le nombre de points pouvant tre modifi sur tapis vert, il est judicieux de prvoir qu'il puisse ne pas correspondre aux rsultats prcdents. Il ne s'agit donc pas d'une redondance, un facteur externe pouvant intervenir et modifier sa valeur. Cela implique tout de mme que le dveloppeur devra prvoir la fois de le mettre jour lors de la saisie des rsultats (par procdures stockes ou par une fonction de son script), et une interface permettant d'y accder et d'y crire directement.

le champ CODEPROLONGATION de la table MATCH sert savoir si un match a eu ou non des prolongations, renseignements non indiqus par tous les score.

Il y a une double relation 1,1 entre les entits Equipe et Pays. Normalement, cela voudrait dire que Pays est un argument de Equipe, et ne devrait pas devenir une table. Mais ici, Pays sert aussi pour les Arbitres, et est donc une entit relie Arbitre par une relation (1,1)-(0,n). Cette lgre digression se trouve donc justifie par la liaison Pays-Arbitre.

Cela parat compliqu ? Pourtant, il n'y a que 21 tables. Certains systmes d'informations sont bien plus complexes que cela, il n'est pas rare qu'une boutique complte repose sur une base de donnes de prs de 70 tables. Mais dj, l, il n'est plus question d'improviser et de crer ses tables au hasard, sous peine de se 20

retrouver coinc et d'avoir rapidement de trs gros soucis. Avec un poil d'exprience, une telle analyse peut tre ralise en quelques jours. Comme d'habitude, si elle correspond effectivement au besoin du client, le dveloppement se rsumera ensuite une interface d'administration pour remplir correctement la base, puis un moteur d'affichage base de requtes pour en afficher le contenu. Ne pas trop exagrer Il conviendra tout de mme de ne pas tomber dans l'excs inverse : l'analyse est l pour nous faire gagner du temps, pas pour nous en faire perdre. Merise, Gare Yourdon et les autres sont des mthodes trs compltes qui peuvent nanmoins se rvler excessivement lourdes et contraignantes. Il n'est pas question ici d'utiliser au pied de la lettre ces procds dans leur intgralit. Mais les techniques du Client/Serveur sont en train d'arriver sur le Web, les sites dynamiques se compliquent et se professionnalisent. Et la mthode que je vous propose dans mes articles est simple, toujours vrai, rapide, efficace, et vous rendra donc de fiers services. Merise: 6me Partie L'actualit nous le prouve une fois encore : ce n'est pas parce que quelque chose est nouveau que les principes fondamentaux ne sont plus valables. De mme qu'une entreprise est tributaire de son chiffre d'affaire et de sa rentabilit, un dveloppement informatique se juge selon un minimum de rgles lmentaires. On pourrait dj citer : analyse, cohrence de conception, modularit, lisibilit, et utilisation cense des ressources matrielles et logicielles. Dans cette optique, construire une belle base de donne bien pense, cohrente, fonctionnelle, est dj un premier pas. L'tape suivante est de savoir comment la remplir, et surtout comment lire les donnes qu'elle contient. Car les requtes SQL pour interroger la base peuvent tre trs gourmandes en ressources systmes et temps machine. Alors autant les formuler correctement afin de ne pas surcharger le serveur et donc d'afficher les pages rapidement. Vous pensez connatre la fonction "SELECT", la plus simple et la plus utilis ? Bien, alors vrifions cela... SECTEURS NOUVEAUX ? FIASCOS IDIOTS... Aprs avoir vcu plusieurs annes euphoriques, certaines Start Up Internet sont actuellement la peine. Car mme si le march des nouvelles technologies est fabuleux, les perspectives de croissances phnomnales, les investisseurs ont perdu de vue la notions la plus fondamentale de l'conomie : une entreprise doit tre rentable. Et bizarrement, ce point tait absent de trs nombreux Business Plan, Business Plan ayant permis ne nombreuses socits de lever des sommes astronomiques. Certaines d'entre elles n'existaient et ne communiquaient que pour plaire leurs investisseurs, et n'avaient mme aucune activit commerciale. La raction des financiers est impitoyable : la majorit des investisseurs stoppent maintenant leurs investissements, et demandent leurs entreprises d'tre immdiatement rentables. Tout de suite. Et, comme nous sommes de bon montons de Panurges, les valeurs boursires baissent, des projets trs prometteurs ne trouvent plus preneurs, et les dcideurs affichent une frilosit exagre. On oublie que de nombreuses entreprises font dj d'normes bnfices, que le commerce lectronique affiche de trs bons chiffres pour l'an 2000, et que ceux ci vont tripler dans les deux ans. Que nous sommes en train de transposer tout notre modle conomique, notre faon de travailler, et d'organiser diffremment notre socit. Et surtout que c'est un sacr chantier qui va gnrer une immense activit... METIERS NOUVEAUX ? SOYONS PROS !!! L'analogie avec le dveloppement est vidente : Internet a permis tout un chacun d'ouvrir un espace chez un hbergeur, et l'aide de livres devenus trs accessibles et facilement disponibles de commencer ses propres ralisations. Intellectuellement, culturellement, ce fut une nouveaut fabuleuse. Dans le mme temps, les informaticiens traditionnels n'ont pas toujours pris au srieux ces nouvelles techniques "avec des images qui bougent", et que "tout le monde touche". C'est pour cela que nous trouvons beaucoup d'autodidactes dans les quipes techniques Web. Mme si les informaticiens issus de formations classiques sont maintenant de plus en plus prsent au sein des quipes de dveloppements Internet, il est important de professionnaliser les mthodes 21

de travail. De cesser l'amateurisme, de rapprendre l'analyse et le gnie logiciel. En bref, de devenir hyper professionnel afin de ne pas faire l'erreur de se dcrdibiliser quand viendra pour nous aussi l'heure du bilan technique du travail ralis ces dernires annes. Car nous aussi, nous serons jugs, en quelque sorte, quand nos dveloppements seront repris pour tre adapts aux nouveaux besoins de l'entreprise, ou convertis aux technologies futures : Ce n'est pas parce qu'un domaine est nouveau, que les principes fondamentaux ne sont plus valables. LANGAGE SQL : SYNTAXE D'EXTRACTION DES DONNEES Le langage SQL (Structured Query Langage, ou Langage d'Interrogation Structur) date de la fin des annes 70. Nous allons dj commencer par voir comment lire les donnes, et ce que cela signifie rellement. Appuyons-nous sur ce schma de base :

Syntaxe de la commande SELECT : SELECT [ALL | DISTINCT] liste de colonnes FROM Table_1, table_2, ... , Table_n WHERE ...... GROUP BY ...... HAVING ........ ORDER BY ....... COMPUTE ....... Exemples simples : SELECT NOM, PRENOM FROM CLIENT renvoie le contenu des colonnes NOM et PRENOM de la table CLIENT. SELECT NOM as lastname, PRENOM as firstname FROM CLIENT renverra le mme contenu, mais en renommant le nom des colonnes de sorties. SELECT LIBELLE, PRIXUNITAIRE * 0.85 as prixpromo FROM ARTICLE affichera le nom des articles et le prix diminu de 15%. Il est donc possible d'effectuer des calculs directement au niveau de la base de donne, ce qui vitera de faire appel une partie de script spcialement dveloppe pour l'occasion.

Dtail des clauses optionnelles : 22

La clause WHERE exprime les conditions de recherches. La clause GROUP BY groupe les rsultats par critres. La clause HAVING permet de restreindre les rsultats en imposant une proprit. La clause ORDER BY trie les rsultats suivant un critre de qualification. La clause COMPUTE gnre des statistiques. LANGAGE SQL : LA CLAUSE WHERE Les conditions de recherches peuvent faire rfrence des colonnes qui ne sont pas incluse dans la liste de slection. Elle est trs utilise pour dfinir ce que l'on apple des jointures : SELECT CLIENT.NOM, CLIENT.PRENOM, FACTURE.DATE FROM CLIENT, FACTURE WHERE CLIENT.ID_CLIENT=FACTURE.ID_CLIENT renverra le nom et le prnom des clients ayant des factures, ainsi que la/les date des factures correspondantes. Il est important de faire une jointure sur ID_CLIENT dans la clause Where, pour indiquer au moteur SQL que la liaison entre les deux tables s'effectue sur cette colonne 'commune'. (Nous reviendrons dans un prochain article sur le fonctionnement d'un moteur SQL). Nous avons plusieurs outils pour les types de condition : Oprateur de comparaison : = , > , < , >= , <=, <> SELECT LIBELLE, PRIXUNITAIRE FROM ARTICLE WHERE PRIXUNITAIRE <>'100' renverra les articles dont le prix est diffrent de 100. Il est important de mettre les ctes ' ' dans la clause Where, car sinon le moteur SQL interprtera 100 comme tant une colonne. Intervalles : BETWEEN, NOT BETWEEN SELECT LIBELLE, PRIXUNITAIRE FROM ARTICLE WHERE PRIXUNITAIRE BETWEEN '100' AND '200' renverra les articles dont le prix est compris entre 100 et 200. Listes : IN , NOT IN SELECT LIBELLE, PRIXUNITAIRE FROM ARTICLE WHERE PRIXUNITAIRE IN ('100','200','300) renverra les articles dont le prix est soit de 100, soit de 200, soit de 300. Correspondances de chanes : LIKE, NOT LIKE Quelques jokers :

% joker : toute chane de caractre - joker simple: un caractre, n'importe lequel [ ] un caractre de l'intervalle ou de l'ensemble spcifi [^] un caractre en dehors de l'intervalle ou de l'ensemble spcifi

23

SELECT LIBELLE, PRIXUNITAIRE FROM ARTICLE WHERE LIBELLE LIKE '%teu%' renverra les articles dont le nom contient 'teu' (pelleteuse, par exemple....) Valeurs inconnues : IS NULL, IS NOT NULL SELECT LIBELLE, PRIXUNITAIRE FROM ARTICLE WHERE PRIXUNITAIRE IS NOT NULL renverra les articles dont le prix existera, c'est dire aura une valeur correspondante dans la table. ATTENTION !!! En sql, NULL ne signifie pas 0 ,il reprsente une valeur indtermine, il signifie 'rien', comme l'ensemble vide en Mathmatique. Combinaisons : AND, OR SELECT LIBELLE, QUANTITE, DATE FROM ARTICLE, CONTIENT, FACTURE WHERE ARTICLE.ID_ARTICLE=CONTIENT.ID_ARTICLE AND CONTIENT.ID_FACTURE=FACTURE.ID_FACTURE AND PRIXUNITAIRE NOT BETWEEN '100' AND '200' OR PRIXUNITAIRE='150' renverra les articles, leur quantit par facture, et la date, et ceci pour les articles dont le prix n'est pas compris entre '100' et '200' ou est gal '150'. LANGAGE SQL : LES AGREGATS Les fonctions d'agrgats calculent des valeurs partir des donnes d'une colonne particulire. Les oprateurs d'agrgat sont : sum (somme), avg (moyenne), max (le plus grand), min (le plus petit), et count (le nombre d'enregistrements retourns). SELECT sum(PRIXUNITAIRE) FROM ARTICLE, CONTIENT WHERE ARTICLE.ID_ARTICLE=CONTIENT.ID_ARTICLE AND CONTIENT.ID_FACTURE='123456' renverra le montant total de la facture '123456' SELECT avg(PRIXUNITAIRE) FROM ARTICLE, CONTIENT WHERE ARTICLE.ID_ARTICLE=CONTIENT.ID_ARTICLE AND CONTIENT.ID_FACTURE='123456' renverra le prix moyens par article de la facture '123456' SELECT max(PRIXUNITAIRE) FROM ARTICLE, CONTIENT WHERE ARTICLE.ID_ARTICLE=CONTIENT.ID_ARTICLE AND CONTIENT.ID_FACTURE='123456' renverra le plus grand prix de la facture '123456' SELECT min(PRIXUNITAIRE) FROM ARTICLE, CONTIENT WHERE ARTICLE.ID_ARTICLE=CONTIENT.ID_ARTICLE AND CONTIENT.ID_FACTURE='123456' renverra le plus petit prix de la facture '123456' SELECT count(PRIXUNITAIRE) 24

FROM ARTICLE, CONTIENT WHERE ARTICLE.ID_ARTICLE=CONTIENT.ID_ARTICLE AND CONTIENT.ID_FACTURE='123456' renverra le nombres d'articles figurants sur la facture '123456' LANGAGE SQL : LA CLAUSE GROUP BY La clause GROUP BY, utilise dans une instruction SELECT, divise le rsultat d'une table en groupe. Il y a actuellement 16 niveaux de sous-groupes possibles. La clause GROUP BY est prsente dans les requtes qui comportent galement des fonctions d'agrgats, ces dernires produisant alors une valeur pour chaque groupe, galement appel agrgat vectoriel. SELECT NOM, avg(PRIXUNITAIRE), sum(PRIXUNITAIRE), ID_FACTURE FROM ARTICLE , CONTIENT, FACTURE, CLIENT WHERE ARTICLE.ID_ARTICLE=CONTIENT.ID_ARTICLE AND CONTIENT.ID_FACTURE=FACTURE.ID_FACTURE AND FACTURE.ID_CLIENT=CLIENT.ID_CLIENT GROUP BY ID_FACTURE renverra pour chaque facture, par nom de client, le prix moyens ainsi que la quantit des produits prsents sur chaque facture. LE LANGAGE SQL EST TRES SOUS-ESTIME. ET POURTANT... Il n'est pas possible de tout voir en un seul article. La prochaine fois, je dtaillerais les clauses HAVING, ORDER BY, et COMPUTE. Ensuite, je vous montrerais comment fonctionne un moteur de base de donne, afin de bien comprendre de quoi il s'agit, et de montrer comment optimiser ses requtes SQL. Ensuite, nous nous amuserons un peu avec quelques requtes un peu complexes, mais qui permettront surtout d'avoir l'information en un seul accs la base de donne, et de retoucher ensuite cette information le moins possible dans le script lui-mme. Autant limiter les accs la base, et rcuprer le maximum d'information en une seule requte. Car une fois que les requtes principalement utilises ont t identifies, il y a des mthodes trs simples pour acclrer les temps de rponse de la base sur ces requtes. Et surtout, cela vitera de retraiter les donnes dans de longues et lourdes routine de programmation, souvent illisibles, incomprhensibles, et trs coteuses en temps machine : il n'y a rien de pire qu'un trie de donnes effectue sous forme de pile (tableaux passs en mmoires), alors autant viter les lourdeurs inutiles. Aprs, tout est question de choix technologique et logicielle : un programme ou un site reposant sur une base complexe devra peut tre utiliser un moteur SQL consquent et plus professionnel... Merise: 7me Partie Nous voici la troisime tape du dveloppement de votre projet Web : l'architecture a t dfinie (choix matriels et technologiques), la base de donne (cohrente...), a t analyse et construites dans les rgles de l'art... Il s'agit maintenant d'utiliser au mieux tout ceci afin de construire les pages dynamiques qui afficheront aux visiteurs les informations qu'ils ont demands, ainsi que celles que votre employeur/client dsire mettre en avant. C'est ce stade que le langage SQL intervient. Or, ses possibilits sont sous-estimes, et donc ses fonctionnalits souvent sous-employes. Pourtant, c'est le fer de lance de la partie dynamique du site Web. Une des parties les plus coteuses en ressources systmes, aussi... Car insrer et extraire des donnes sollicite fortement le(s) disque(s) dur(s) (HDD), utilise de la mmoire (RAM) et du temps systme (CPU). Il importera donc non seulement d'utiliser les bonnes requtes aux bons moments, mais aussi de les rdiger le plus proprement possible afin d'viter au maximum le gaspillage des ressources du ou des serveurs abritant la base de donne. ETRE BON, C'EST SAVOIR SE PROTEGER 25

Les grands manitous du Web nous l'ont tous dit : lors de la rue vers l'or, ce sont les marchands de pelles qui se sont enrichis. A les entendre, il semble possible d'affirmer que les grands gagnants de la course folle de l'Internet soient les informaticiens. Leurs dolances sont maintenant exprimes : difficults nous recruter, salaires scandaleux, obligation de nous augmenter tous les six mois, il semblerait que nous ne nous soyons jamais aussi bien port que depuis ces dernires annes. Et visiblement, ils n'ont pas aim. Or, actuellement, certaines entreprises ferment. Il devient plus facile de recruter de la "main d'oeuvre". Et cela, par contre, l'air de beaucoup leur plaire. Pourtant, personne ne parle jamais des journes de 14 heures dans les parcs informaticiens (box), voir mme des heures de nuit ou de Week End devant son cran "pour la bonne cause". La consquence est claire : maintenant plus encore qu'hier, tout informaticien devra donc rapidement apprendre se protger, sous peine de se laisser manger par son travail et sa direction commerciale et marketing. Il devra mettre des barrires et imposer ses dlais aux dcideurs (patrons, clients, ...) qui oublient un peu vite que nous sommes pas que des outils, mais qu'en revanche nous sommes totalement indispensables la conception des jolis projets qu'ils nous demandent. Et que la fiabilit desdits projets, et donc la prennit des entreprises qui les utilisent, dpend en grande partie de la qualit de notre production. Il existe un moyen infaillible de se protger, et donc de rester performant dans son travail : tre bon, tre rellement professionnel. Afin que notre code ncessite le moins de retouches possibles, et qu'il convienne parfaitement la demande des utilisateurs. Ainsi, nous serons tous gagnants : les programmes seront performants, et les informaticiens auront moins de pression. Il faut que les utilisateurs prennent confiance en notre travail... RAPPEL : SELECT ... FROM ... WHERE ... GROUP BY ... Reprenons le modle de la coupe du monde Football de 1998 tel que nous l'avons vue dans la partie 5 : MCD MPD

SELECT NOMPAYS, count(IDBUT) FROM JOUEUR, BUT, COMPOSERDE, EQUIPE, PAYS WHERE JOUEUR.IDJOUEUR=BUT.IDJOUEUR AND JOUEUR.IDJOUEUR=COMPOSERDE.IDJOUEUR AND COMPOSERDE.IDEQUIPE=EQUIPE.IDEQUIPE AND PAYS.IDPAYS=EQUIPE.IDPAYS GROUP BY NOMPAYS renverra, pour chaque pays participant, le nombre total de buts marqu durant la comptition.

La requte concerne 5 tables, elle ncessite donc 4 jointures. Le dtail des clauses WHERE, GROUP BY et des Agrgats a t vu dans la partie 6 26

LANGAGE SQL : LA CLAUSE HAVING La clause HAVING dfinit les critres de la clause GROUP BY de la mme faon que la clause WHERE dans une instruction SELECT. L'avantage de la clause HAVING est surtout qu'elle peut comporter des agrgats, ce que ne permets pas la clause WHERE. SELECT NOMJOUEUR FROM JOUEUR, BUT WHERE JOUEUR.IDJOUEUR=BUT.IDJOUEUR HAVING count(BUT.IDJOUEUR) > '2' retournera la liste des joueurs ayant marqu plus de deux buts. Il est possible de combiner les critres avec les oprateurs AND et OR. LANGAGE SQL : LA CLAUSE ORDER BY La clause ORDER BY permet de trier les rsultats d'une requte par colonnes. Il est possible de demander un tri croissant (asc) , ou dcroissant (desc). Par dfaut, le tri est croissant (asc). Plusieurs colonnes peuvent tre indiques : dans ce cas, le tri sera effectu selon la premire colonne indique, puis la deuxime, etc... SELECT TAILLE, POIDS, NOMJOUEUR FROM JOUEUR ORDER BY TAILLE desc, POIDS desc retournera la taille, le poids et le nom des joueurs participants au tournoi, mais du plus grand au plus petit : en cas de taille quivalente, les plus lourds seront retourns en premier. Cette clause est trs importante : en effet, elle permet elle seule d'effectuer un classement des donnes, et donc d'viter de programmer un traitement supplmentaire gnralement trs lourd en ressource systme et en mmoire. Il est possible d'utiliser le numro des colonnes plutt que leur nom. SELECT POSITION, avg(TAILLE) FROM JOUEUR GROUP BY POSITION ORDER BY 2 retournera la taille moyenne des joueurs positions par positions, de la taille moyenne la plus petite la plus grande. Cela peut se rvler trs utile, notamment pour des tableaux de statistiques. Et surtout, les donnes arrivent dj trilles. LE LANGAGE SQL EST LA BASE DU DEVELOPPEMENT Ces deux articles n'ont pas la prtention de remplacer un ouvrage technique, ou la documentation officielle. Seulement, les requtes SQL sont la trame du dveloppement d'un site dynamique. Une base bien conue permettra de grer avec cohrence les donnes, et ainsi d'viter un certain nombre d'erreurs. La requte SQL permet d'extraire ces donnes, le langage de dveloppement s'occupant de la prsentation de ces donnes et de la gestion des tests souvent ncessaires, voir mme de la mise en page. De plus, il ne faut pas perdre de vue que les appels la base de donne sont de grands consommateurs de ressources systmes : il importera donc de bien doser leur utilisation, et surtout d'utiliser toutes les possibilits du SQL afin d'obtenir le maximum d'informations dans la mme requte. 27

J'en ai encore eu la confirmation lors des deux derniers vnements auxquels j'ai assist, un djeuner/dbat avec des acteurs de l'Internet Franais et Europens (entrepreneur et investisseurs), et le First Tuesday du mois d'Avril (avec le fondateur de Self Trade) : l'heure est la crise financire pour les projets Internet non-viables, mais l'avenir est surtout au sites dynamiques. Les entreprises ne se satisfont plus de sites 'plaquettes', elles veulent maintenant une plus grande dimension informatique et technique pour leur Internet. Merise: 8me Partie Il est maintenant temps de regarder comment fonctionne le moteur de la base de donne et d'optimiser les requtes SQL. En effet, il est possible de gagner considrablement en ressources machines rien que sur une optimisation du code SQL. L encore, il n'est pas question de magie, mais de bien comprendre comment cela fonctionne, et d'utiliser propos les outils choisis, en l'occurrence les bases de donne, qui sont trs coteuses en ressources systmes. Bien sur, elles nous rendent de fiers services mais leur utilisation abusive (ou maladroite) peut provoquer de forts ralentissements, voir mme crasher le serveur. Il faut donc tre trs prcautionneux de ce que l'on va demander l'outil. Comme d'habitude, il faut dfinir une architecture en adquation avec ses besoins, et l'utiliser le plus propos possible. ECONOMISER LA MACHINE, C'EST EN FAIT POUVOIR LUI EN DEMANDER PLUS Un hbergeur Franais bon march, trs populaire chez les informaticiens et proche d'un fournisseur d'accs gratuit Internet, nous l'a cruellement rappel la fin de l'anne dernire. Fournissant des hbergements mutualiss (plusieurs sites par machines), il s'est retrouv avec certains sites reposant intgralement sur des requtes SQL lourdes voir inutiles, fausses, et surtout lances tors et travers. Certains de ces sites sont devenus un peu connus, ont commenc faire de l'audience, et ont finalement faillis faire chavirer l'ensemble de la plate-forme d'hbergement. Les bases de donnes, surcharges, refusaient souvent de se lancer et de rpondre aux requtes, et renvoyaient rgulirement des messages d'erreurs tous les utilisateurs. Aux heures de pointes, les sites n'taient parfois mme plus consultables. Inutile de dire que la crdibilit d'un site Internet affichant des erreurs d'accs la base SQL est srieusement entame, et que de nombreuses personnes ont du reprendre leur dveloppement. Pour que le site Internet tienne la charge quand il commence tre frquent, il vaut mieux qu'il repose sur des fondations solides tant matrielles que logicielles. Quant cet hbergeur, il a du refondre son architecture matrielle, mais a aussi perdu une grande part de sa crdibilit et de sa clientle...

MODELISONS UN CATALOGUE : REVISIONS DE LA TECHNIQUE... Systme d'Information (SI) : Arborescence en Arbre... Un garagiste expose sur le Web ses modles, afin de prsenter ses nouveauts et surtout son stock en temps rel (disponibilit de ses modles). Il utilise ce que l'on appelle un catalogue, sans caddy ni paiement en ligne (ce sont des voitures...), mais avec navigation par catgorie/sous-catgorie, affichage de la fiche-produit de la voiture, et possibilit de recherche par marque de vhicule. Il limite sa fiche produit au nom, au prix, et la disponibilit de la voiture (on simplifie...). Ce qui donne : Un Produit possde 1 ou plusieurs Crateurs (marques, fabricants). Un Crateur fabrique 0 ou plusieurs Produits. Ces Produits appartiennent chacun une et une seule Catgorie. Chaque Catgorie contient 0 ou plusieurs Produits. Enfin, une Catgorie peut avoir 0 ou plusieurs sous-Catgories, chaque Catgorie ayant 0 ou une Catgorie parente. D'o le MCD :

28

Qui entrane le MLDR : CREATEUR (ID_CREATEUR, NOM_CREATEUR) FABRIQUE (ID_CREATEUR, ID_PRODUIT) PRODUIT (ID_PRODUIT, #ID_CATEGORIE, NOM_PRODUIT, PRIX_PRODUIT, DISPONIBLE) CATEGORIE (ID_CATEGORIE, #ID_PAR_CATEGORIE, NOM_CATEGORIE) Qui gnre le MPD :

POUR SE PROTEGER, IL FAUT BIEN COLMATER LES JOINTURES !!! Prenons une requte d'extraction toute simple, et regardons ce qu'il se passe : On recherche les modles disponibles de Vhicules de marques "Peugeot" de type "Dcapotable", et leur prix. L'identifiant ID_CREATEUR de "Peugeot" est ici "4", et l'identifiant ID_CATEGORIE de "Dcapotable" est "10". SELECT * FROM PRODUIT, FABRIQUE WHERE PRODUIT.ID_CATEGORIE='10' AND FABRIQUE.ID_CREATEUR='4' AND PRODUIT.ID_PRODUIT=FABRIQUE.ID_PRODUIT Regardons maintenant ce que fait le moteur de la base : 1) Celui interprte la requte ligne par ligne. Pour commencer, il met dans un tableaux tous les lments de 29

PRODUIT et de FABRIQUE, en faisant ce que l'on appelle un produit cartsien : c'est dire que pour chaque enregistrement de la premire table rencontre, ici PRODUIT, il mettra en face tous les enregistrements de la seconde table rencontrs un par un, et ce pour chaque ligne. Si PRODUIT contient 250 enregistrements, et FABRIQUE 110, cette table temporaire et intermdiaire comprendra 250*110=27500 lignes. PRODUIT id_produit id_categorie nom_produit prix_produit disponible 1 3 103SP 55 000 Y 1 3 103SP 55 000 Y ... ... ... ... ... ... ... ... ... ... 1 3 103SP 55 000 Y 2 10 205 Blue 83 000 Y 2 10 205 Blue 83 000 Y ... ... ... ... ... ... ... ... ... ... 2 10 205 Blue 83 000 Y etc... etc... etc... etc... etc... FABRIQUE id_createur id_produit 4 2 4 11 8 15 ... ... 33 18 4 12 4 11 8 2 ... ... 33 18 etc... etc...

2) Puis, il supprime de cette mme table temporaire les valeurs de id_catgories diffrentes de '10'. PRODUIT id_produit id_categorie nom_produit prix_produit disponible 2 10 205 Blue 83 000 Y 2 10 205 Blue 83 000 Y ... ... ... ... ... ... ... ... ... ... 2 10 205 Blue 83 000 Y etc... etc... etc... etc... etc... FABRIQUE id_createur id_produit 4 2 4 11 8 15 ... ... 33 18 etc... etc...

3) Ensuite, il supprime de cette mme table temporaire les valeurs de id_createur diffrentes de '4'. PRODUIT id_produit id_categorie nom_produit prix_produit disponible 2 10 205 Blue 83 000 Y 2 10 205 Blue 83 000 Y ... ... ... ... ... etc... etc... etc... etc... etc... 30 FABRIQUE id_createur id_produit 4 2 4 11 ... ... etc... etc...

4) Enfin, il effectue la jointure demande, et ne garde que les lignes dont PRODUIT.ID_PRODUIT=FABRIQUE.ID_PRODUIT . PRODUIT id_produit id_categorie nom_produit prix_produit disponible 2 10 205 Blue 83 000 Y etc... etc... etc... etc... etc... FABRIQUE id_createur id_produit 4 2 etc... etc...

5) Eventuellement, si il le lui avait t demand, c'est ce stade qu'il aurait interprt les commandes des instructions GROUP BY, puis HAVING et enfin ORDER BY. Toutefois, il est intressant de constater que toutes les colonnes sont prsentes dans le tableaux, et que l'on a pass en mmoire peu prs 100 fois l'intgralit de la quantit de donnes contenues dans ces seules tables. Imaginez un peu si le garagiste avait eu 100 000 Voitures rparties dans 250 Catgories, avec peu prs 970 marques diffrentes ?

"F PAS GACHER", COMME DIRAIT L'AUTRE... Reprenons la mme requte, mais formule un poil diffremment : SELECT PRODUIT.NOM_PRODUIT, PRODUIT.PRIX_PRODUIT FROM PRODUIT, FABRIQUE WHERE PRODUIT.ID_PRODUIT=FABRIQUE.ID_PRODUIT AND PRODUIT.ID_CATEGORIE='10' AND FABRIQUE.ID_CREATEUR='4' Regardons ce que fais le moteur de la base : 1) Tout d'abord, il rcupre dans un tableaux les lments de PRODUIT demands et ceux ncessaires pour la requte, fais pareil pour FABRIQUE, et la jointure tant spcifie en premier, il ne prend que les lignes dont PRODUIT.ID_PRODUIT=FABRIQUE.ID_PRODUIT . PRODUIT id_produit id_categorie nom_produit prix_produit 2 10 205 Blue 83 000 3 10 Mgane 83 000 5 15 4L ME 83 000 ... ... ... ... etc... etc... etc... etc... FABRIQUE id_createur id_produit 4 2 8 3 4 5 ... ... etc... etc...

2) Il enlve les lignes dont id_categorie n'est pas gal '10' 31

PRODUIT id_produit id_categorie nom_produit prix_produit 2 10 205 Blue 83 000 3 10 Mgane 83 000 ... ... ... ... etc... etc... etc... etc...

FABRIQUE id_createur id_produit 4 2 8 3 ... ... etc... etc...

3) Puis celles o id_createur n'est pas gal '4' PRODUIT id_produit id_categorie nom_produit prix_produit 2 10 205 Blue 83 000 ... ... ... ... etc... etc... etc... etc... FABRIQUE id_createur id_produit 4 2 ... ... etc... etc...

4) Enfin, il ne garde que les colonnes demandes dans la requte, c'est dire le nom, et le prix. 205 Blue 83 000 ... ... etc... etc...

Si j'avais su, par exprience ou connaissance du contexte, que la clause FABRIQUE.ID_CREATEUR='4' tait plus rductrice en terme d'lments que la clause PRODUIT.ID_CATEGORIE='10' , je l'aurais alors mise avant celle ci, afin de rduire le plus possible le nombre d'lments stocks en mmoire, et donc les oprations ncessaires pour les tris et traitements ultrieurs. Il est intressant de remarquer que pour un obtenir un rsultat similaire, on a beaucoup moins tir sur la machine, qui pourra donc accomplir cette requte un plus grand nombre de fois simultanment, et donc accueillir un plus grand nombre de visiteur sans souffrir... QUI VEUT ALLER LOIN, MENAGE SA MONTURE Sans tomber non plus dans l'intgrisme inutile du coupeur de cheveux en 4, il est tout de mme trs clair que la simple formulation de la requte SQL est lourde de consquence sur les ressources et le temps machine ncessaire pour sa simple excution. On peut ainsi citer quelques prcautions simples qui allgeront simplement la charge reposant sur le serveur :

Mettre les jointures en premier : Si n tables, alors (n-1) jointures.

32

Placer les comparaisons les plus restrictives le plus tt possible : cela fera toujours autant de lignes qui ne seront plus en mmoire, et que l'ordinateur n'aura plus traiter dans le reste de sa requte.

EVITER ABSOLUMENT "SELECT * FROM ..." : Ne demandez que les colonnes ncessaires, c'est toujours a de moins garder en tableaux aprs la requte, et donc cela conomise la mmoire. De plus, si un jour vous dplacez votre code, et que deux colonnes se trouvent inverses dans la nouvelle base, cela n'aura aucune consquence pour votre dveloppement.

Comparer des colonnes de mme type : Un CHAR(150) est considr du mme type qu'un VARCHAR (150), mais diffrent d'un CHAR(152) ou d'un VARCHAR(148). Cela oblige le moteur de base de donne effectuer des conversions internes.

Formuler les clauses de comparaison le plus prcisment possible : En particulier, viter de mettre des % partout dans les clauses LIKE, c'est trs lourd traiter...

Mettre les identifiants en INT, et en AUTOINCREMENT : L'avantage principal de l'autoincrement est que pour chaque cration d'enregistrement ne comprenant pas d'office son identifiant, le moteur se charge lui-mme de lui en attribuer un [du type max(id) 1], ce qui vite des manipulations supplmentaires.

Utilisez des INDEX : Mais l'explication, l, ce sera pour la prochaine fois....

33