Dossier "SAM l'Informaticien" du 22/01 au 04/02 2001 par Stéphane Lambert
odéliser, c'est
comprendre. Pour développer le logiciel dont les utilisateurs
ont besoin, l'informaticien ne doit pas correspondre aux
stéréotypes 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 portée des utilisateurs de son travail : rien de tel
qu'observer un journaliste rà¢lant 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 manière que l'on obtient la récompense suprême : voir un
client heureux d'utiliser son nouveau logiciel, et surtout le
voir travailler avec durant longtemps. Attachons-nous à ce
noble objectif : après avoir commenté le MPD ou Schéma de Base
de la Newsletter vue précédemment et avoir regardé ce qu'il
représente véritablement, je vous proposerais un autre exemple
significatif.
Utiliser le Modèle
Physique de Donnée :
Une fois le
système d'information analysé et modélisé en Modèle Conceptuel
de Donnée (MCD), et après être passé par le Modèle Logique de
Donnée Relationnel (MLDR), nous arrivons au Modèle Physique de
Donnée (MPD). Il s'agit maintenant de créer la base
correspondante à l'étude entamée. C'est à ce stade seulement
que la base de donnée choisie intervient.
Le SQL
(Structured Query Language), ou Langage d'Interrogation
Structuré, a été reconnu en tant que norme officielle de
langage de requête relationnelle par l'institut ANSI (American
National Standards Institute) et par l'organisme ISO
(International Standards Organization). Malgré cela, les
syntaxes d'extractions des données et de créations des tables
varient quelques peux d'une base à l'autre. En particulier, si
la base de donnée utilisée pour le développement n'est pas
véritablement relationnelle (cas de MySql dans sa version
actuelle), il appartiendra au développeur de prendre lui-même
en charge les limitations rencontrées, afin de s'assurer que
sa base ne puisse JAMAIS être corrompue, c'est à dire contenir
des données aberrantes.
APPLICATION SUR UN MODELE PHYSIQUE CONCRET :
Prenons l'exemple du schéma de base (MPD) suivant
:
- La table
MOTIVATIONS est très
simple à créer : elle comporte deux champs, ID_MOTIVATIONS et INTITULE. ID_MOTIVATIONS est la Clé Primaire.
- ABONNES comporte les 12 champs du
schéma. 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'intérêt majeur des
clés étrangères est surtout d'éviter les redondances,
sources d'erreurs.
- Pour les bases non totalement relationnelles : Il appartiendra au développeur de vérifier lors de chaque insertion dans ABONNES que l'ID_MOTIVATIONS fournis fais partie des valeurs existantes de ID_MOTIVATIONS de MOTIVATIONS. De même, lors de chaque suppression d'un enregistrement de MOTIVATIONS, il faudra vérifier 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
concaténation de ces deux champs. C'est à dire que tout
couple (ID_ABONNES,ID_RUBRIQUE) de S_INSCRIT est unique. ID_ABONNES est aussi clé étrangère
de ABONNES dans S_INSCRIT, et ID_RUBRIQUE est clé étrangère de
RUBRIQUE dans S_INSCRIT.
Une telle table est communément appelée "Table de Lien". L'intérêt d'une telle table est que pour chaque ID_ABONNES donné, il est aisé de retrouver tous les ID_RUBRIQUE associés, et vice et versa.
- Pour les bases non totalement relationnelles : Il faudra vérifier lors de chaque insertion dans S_INSCRIT que le couple (ID_ABONNES,ID_RUBRIQUE) n'existe pas déjà dans la table S_INSCRIT, que ID_ABONNES existe dans ABONNES et que ID_RUBRIQUE existe dans RUBRIQUE. De même, pour chaque suppression d'un abonné, il faudra supprimer tous les couples (ID_ABONNES,ID_RUBRIQUE) ayant l'ID_ABONNE correspondant. Pareil pour toute suppression de RUBRIQUE.
- RUBRIQUE est elle aussi très simple
à créer : elle comporte deux champs, ID_RUBRIQUE et NOM_RUBRIQUE. ID_RUBRIQUE est la Clé Primaire.
- NEWSLETTERS comprend les 5 champs
du schéma. ID_NEWSLETTER
est la clé primaire. ID_RUBRIQUE est une clé étrangère
provenant de RUBRIQUE.
- Pour les bases non totalement relationnelles : Il faudra vérifier 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 réservé à chaque newsletter de cette rubrique : les détruire ou les archiver.
APPLICATIONS AUX BASES RELATIONNELLES :
Les vérifications détaillées précédemment n'ont
lieu que pour assurer la cohérence de la base. Il est donc
logique, si celle ci le permet, de déléguer et d'automatiser
ces taches au niveau ce celle-ci. Généralement, les
vérifications afférentes à une clé étrangère sont confiées à
un Trigger (un Trigger est un ensemble d'instruction SQL
s'effectuant avant ou après un événement donné, par exemple
une insertion ou une suppression). Ainsi, lors de chaque
commande d'insertion sur la table désignée au Trigger
préalablement correctement programmé, celui ci va vérifier
AVANT l'insertion que la clé étrangère 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 même, certains traitements automatisés
pourront être réalisés directement à l'aide de procédures
stockées. Exemple : un devis validé qui entraîne la création
de la facture correspondante. Et surtout, les Trigger et
Procédures Stockées étant compilées directement par la Base de
Donnée, leur exécution est beaucoup plus rapide qu'une série
d'instruction SQL envoyées par le programme attaquant la base.
Une base de donnée correctement pensée est à envisager
comme un contenant d'information "vivant", forcement cohérent,
aux réactions automatisées. Une telle base se suffirait
presque à elle-même pour gérer un Système d'Information. Le
développement ne consisterait alors plus qu'à afficher son
contenu en temps réel, et à fournir les outils d'insertion
appropriés. Le rêve...
SECOND EXEMPLE : MODELISER UN DOCUMENT
Il est courant, lors du développement d'un site Web ou
de l'informatisation d'un système d'information, de démarrer
son analyse par un document. Captures d'écrans, photocopies,
sont parfois les principales pièces jointes à la demande de
devis, accompagnés du commentaire suivant :
"Je veux
faire ça !!!". Bien. Alors, faisons ça...
Système d'Information :
L'entreprise
"WebCash" de vente par correspondance désire ajouter à son
site un système de consultation de factures 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 copie d'une facture type en disant :
"C'est ça qu'on
veut sur l'écran !"
Voici une copie de cette
facture :
Voilà , tous
les éléments sont réunis. Il ne reste plus qu'à concevoir la
Base de Donnée se cachant derrière cette innocente petite
facture. Cet exemple est très conforme à la réalité. Il sera
très intéressant à étudier, car il permettra d'expliquer un
certain nombre de points, et de mettre en évidence certaines
erreurs à ne pas commettre. N'hésitez pas à prendre le stylo
et à vous entraîner, je vous fournirais une solution commentée
la prochaine fois.
A
bientôt...
| << Lire la 2ème partie |
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
vediovis.fr