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
| |
Webmaster
