MODELISER UN DOCUMENT : UNE PRATIQUE COURANTE
Commençons par terminer l'exemple de la dernière fois, dont re-voici
l'énoncé :
Système d'Information :
L'entreprise "WebCash" de vente par correspondance désire ajouter
à son site un système de facturation visible en ligne pour ses clients.
Chaque client, après authentification, pourra accéder à toutes les
factures le concernant, qu'elles soient anciennes ou en cours de traitement
indifféremment. 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 Rêves roses
75008 PARIS |
FACTURE N° 12345 |
Paris, le 15/10/2000 |
Nom : |
BIDOCH |
Prénom : |
Robert |
Adresse : |
12, rue du centre |
Code Postal : |
70000 |
Ville : |
Gray |
|
N° Article |
Libellé |
Prix Unitaire |
Quantité |
Prix |
234 |
Stylo Plume |
12.5 F |
1 |
12.50 F |
568 |
Couteau Suisse |
75.00 F |
2 |
150 F |
132 |
Serviette |
30.00 F |
1 |
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 Modèle Conceptuel de Donnée (MCD), Générer
le Modèle Logique de Données Relationnelles (MLDR), et le transposer
en Modèle Physique de Donnée (MPD).
- Construire le Modèle Conceptuel de Donnée (MCD) :
La méthode est toujours la même : Identifier les entités présentes,
Lister les propriétés des entités, Identifier de manière unique
chaque occurrence, Etablir les relations entre les différentes
entités, et Identifier les cardinalités.
- Identifier les entités présentes :
On relève trois entités : CLIENT, FACTURE, ARTICLE.
- CLIENT est l'ensemble des clients de la société WebCash.
Une occurrence de cette entité est présentée par Robert BIDOCH,
qui est le client à qui cette facture est destinée.
- FACTURE est l'ensemble des factures émises par WebCash,
dont une occurrence est présente en "FACTURE N° 12345".
- ARTICLE est l'ensemble des articles vendus par WebCash,
dont trois occurrences sont présentes, dénommés Stylo Plume, Couteau
Suisse et Serviette.
- Une facture étant composée de plusieurs lignes, il aurait été
possible de relever l'entité LIGNE_FACTURE : elle n'est utile que
si l'on désire archiver pour chaque ligne son Numéro. La base déduite
aurait été sensiblement la même, démontrant ainsi que plusieurs
solutions sont parfois possibles.
- La TVA est ici considérée comme constante et unique. Dans le
cas contraire, elle aurait représenté l'entité TVA.
- La société WebCash ne représente pas une occurrence d'une entité,
car c'est la seule société éméttrice de facture de notre analyse.
- Lister les propriétés des entités :
- Un CLIENT est caractérisé par son Nom, son Prénom, son
Adresse, son CodePostal et sa Localité. Afin de pouvoir s'authentifier,
il est aussi caractérisé par un Login et un Passwd.
- Une FACTURE est caractérisée par son Numéro, et sa Date
d'émission.
- Un ARTICLE est caractérisé par son Numéro, son libellé,
et son PrixUnitaire. Le prix total, de par son PrixUnitaire et sa
quantité, peux être recalculé : ce n'est donc pas une caractéristique
de l'ARTICLE.
- Chaque propriété doit avoir une seule valeur possible pour chaque
occurrence, ce qui est ici le cas. Elle doit de plus être élémentaire
et non-décomposable, ce qui est aussi le cas. D'une manière générale,
toute information résultant d'un calcul n'est pas une caractéristique
d'une entité.
- Identifier de manière unique chaque occurrence :
chaque occurrence de chaque entité doit pouvoir être identifiée de
manière unique : cette propriété s'appele l'identifiant.
- Un CLIENT sera identifié par un Numéro unique, cette caractéristique
de l'entité étant appelé id_Client.
- Une FACTURE sera identifiée par son Numéro qui est unique.
Cette caractéristique sera appelée id_Facture.
- Un ARTICLE sera identifié par son Numéro qui est lui aussi
unique. Cette caractéristique sera appelée id_Article.
- Etablir les relations entre les différentes entités :
Un CLIENT obtient une FACTURE qui contient des ARTICLES
en certaine quantité.
- Identifier les cardinalités :
- Un même CLIENT obtient 1 ou plusieurs FACTURE.
- Une même FACTURE est obtenue par un seul CLIENT.
- Une même FACTURE contient 1 ou plusieurs ARTICLE.
- Un ARTICLE est contenu dans 0 ou n FACTURE.
On en déduit donc le MCD suivant :
Comme d'habitude, il est alors temps de retourner voir le
client et de discuter le Modèle avec lui, afin de vérifier
qu'il ne manque rien et que l'analyse correspond bien à SA
réalité de travail. Après validation, il est temps de passer
à l'étape suivante.
- Générer le Modèle Logique de Données 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 Modèle Physique de Donnée (MPD) :
Voilà, il ne reste plus qu'à créer la base, à la remplir,
et à développer dessus.
UNE BASE DE DONNEE COHERENTE
Un tel modèle est dit cohérent, c'est à dire que pour chaque
donnée 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 achetés et en quelle quantité. Pour
chaque facture, il sera possible de retrouver le client correspondant,
ainsi que la liste des articles et leurs quantités respectives. Enfin,
pour chaque article, il sera aisé de retrouver les quantités vendues,
à quelle date et à quels clients.
La base ne contient aucune redondance, c'est à dire qu'aucune
information présente ne peut être déduite d'autres informations présentes.
Ceci évite grandement le risque de corruption, ou présence de
donnée aberrante.
Les prix intermédiaires, la somme totale et autres résultats sont des
traitements, c'est à dire qu'ils sont calculés 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 vérifier un programme d'extraction de donnée que de vérifier
la cohérence du contenu d'une base.
LES AVANTAGES D'UN TEL RESULTAT
Le développement se réduit 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-même (FrontOffice), il ne reste plus qu'à
faire le formulaire d'accréditation du CLIENT (Login/Passwd)
qui permettra de retrouver son identifiant, puis à lui lister les FACTURE
correspondant à cet identifiant, et enfin lui afficher le détail de
celle qu'il aura sélectionné.
Si ce développement paraît au final aussi simple, c'est qu'il s'appuie
sur une base bien pensée. 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 références et des publicités
: 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.
A bientôt...
Stéphane
Lambert
http://www.vediovis.fr/
Spécialisé dans le développement Web, Stéphane LAMBERT
a fondé VEDIOVIS PRODUCTIONS en Mai 2000.
Son expérience couvre essentiellement les sites à fortes audiences,
institutionnels ou audiovisuels.
Tous droits réservés - Reproduction même partielle interdite
sans autorisation préalable
| |