par Stéphane Lambert
nalyser
un Système d’Information déroute parfois le non-initié, car traduire
un environnement de travail en symboles cabalistiques n’est pas très
habituel pour qui ne connaît pas. Pourtant, avec une once de théorie
et deux grammes de pratique, on se rend compte que le processus est
très abordable, soumis à quelques règles simples, faciles à acquérir
et qui s’appliquent toujours de la même manière. La méthode décrite
ici est MERISE, elle est Française et a plus de 20 ans. Elle
consiste à concevoir un Modèle Conceptuel de Donnée (MCD), le
transposer en Modèle Logique de Données Relationnelles (MLDR), puis
à générer le Modèle Physique correspondant (MPD). C’est la plus
répandue des techniques d’analyse de Base de Donnée. Nous étudierons
plus particulièrement aujourd'hui la construction du Modèle
Conceptuel de Donnée et de ses 5 caractéristiques : Entités,
Propriétés, Identifiants, Associations,
Cardinalités.
La première priorité est de transformer ce que l’on veut analyser en mots simples. L’écriture de cette petite rédaction permet à elle seule de bien comprendre ce que l’on va modéliser. Il s’agit à ce stade d’établir un lien entre l’informaticien et les utilisateurs, il ne faut donc pas hésiter à faire relire votre petit texte et à poser toutes les questions qui vous viennent à l’esprit afin de bien analyser l’existant. La difficulté principale est d’arriver à faire abstraction de vos habitudes de programmation : à ce stade, nous sommes totalement indépendant du matériel et du logiciel. Ne pensez pas en terme de tables. Pensez en terme d’entités.
Prenons l’exemple très simple d’un logiciel ayant pour but de gérer les envois de NewsLetters aux abonnés d’un site ayant plusieurs rubriques. Le service marketing veut aussi savoir quelle raison a poussé l’abonné à s’inscrire en lui proposant plusieurs choix de motivations lors de son inscription.
Le Système d’Information se décrit ainsi :
"Un abonné est inscrit à une ou plusieurs rubrique. Chaque rubrique envoie une NewsLetter chaque semaine aux abonnés de la rubrique correspondant. Un abonné a une motivation d’inscription parmi plusieurs possibles."
Ces quelques phrases, si elles sont exactes et validées par le client, sont suffisantes pour modéliser notre premier modèle. Elles contiennent en effet toutes les informations nécessaires.
Identifier les entités présentes
L’entité ABONNES représente l’ensemble des abonnés. L’entité RUBRIQUES l’ensemble des rubriques auquelles l’abonné peux s’inscrire. L’entité NEWSLETTERS représente les newsletters envoyées, MOTIVATIONS l’ensemble des motivations d’inscriptions des abonnés.
D’où les 4 entités :
Généralement, une entité est crée dans le Système d’Information si elle possède au moins 2 occurrences. Chaque ‘élément d’une entité’ est appelé une occurrence de l’entité.
Lister les propriétés des entité
Un Abonné est caractérisé par son nom, son prénom, son à¢ge, son sexe, sa profession, sa rue, son code postal, sa ville, son pays, son téléphone et son email.
Une Newsletter est caractérisée par son sujet, sa date d’envoi et son contenu.
Une Motivation est caractérisée par son intitulé.
Une Rubrique est caractérisée par son nom.
Les 4 entités deviennent :
Afin de ne pas en avoir trop, on se limite généralement aux propriétés nécessaires au développement. Chaque propriété doit avoir une seule valeur possible pour chaque occurrence, sinon il s’agit d’une entité. Elle doit de plus être élémentaire et non-décomposable. Par exemple, l’adresse n’est pas une propriété élémentaire : elle comporte une rue, un Code Postal et une ville qui elles, sont 3 propriétés élémentaires.
Identifier de manière unique chaque occurrence
Imaginons que nous ayons deux abonnés qui s’appellent ‘DUPOND : il est nécessaire de les distinguer sous peine de les confondre. On rajoute alors une propriété qui permettra d’identifier de manière unique chaque occurrence. Cette propriété est appelé l’identifiant de l’entité. Cela peut être une référence interne, un code, ou plus généralement un nombre entier. Cette propriété est soulignée afin de mettre en évidence son rôle d’identifiant.
Les 4 entités sont finalement :
Etablir les relations entre les différentes entités
Maintenant, il s’agit d’identifier les relations entre les entités. Généralement, la simple transposition du texte suffit, les Sujets et Compléments d'Objets étants les entités, et les Verbes les relations.
Reprenons notre texte initial :
"Un Abonné a une Motivation. Un Abonné s’inscrit à une ou plusieurs Rubriques. Chaque Rubrique envoie une NewsLetter."
Les verbes sont en rouge et relient les entités. Il suffit de les intégrer au schéma :
Identifier les cardinalités
Il faut maintenant établir le nombre possible d’interactions entre les entités.
Il s’agit d’un couple d’entiers 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 d’inscription, le marketing ayant imposé un champ obligatoire afin d’avoir cette valeur. On a donc 1 minimum, et 1 maximum. D’où la cardinalité (1;1).
Une Motivation donnée concerne 0 ou plusieurs Abonnés. On a donc 0 minimum, et n en maximum. D’où la cardinalité (0;n).
De même, un Abonné s’inscrit à une ou plusieurs Rubriques : (1;n),
Et une Rubrique possède 0 ou plusieurs Abonnés : (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 schéma, et nous avons notre Modèle Conceptuel de Donnée (MCD) :
Valider le Modèle avec le
client
A
ce stade, il est aisé d’aller voir encore une fois les utilisateurs
du logiciel final, afin de discuter le MCD avec eux. Cela vous
permettra d’entériner les propriétés qu’ils désirent utiliser,
d’être bien certain des cardinalités, et de valider avec eux cette
partie de votre travail. Un MCD doit pouvoir s'expliquer avec des
phrases simples et être compréhensible par tout le monde. Il ne
s’agit ni plus ni moins que de modéliser l’existant. Ainsi, vous
serez certain de faire le développement demandé, et cela vous
permettra de vous protéger par la suite en cas de nouvelles demandes
ou de modification du cahier des charges.
Il est important
de bien réaliser que jusqu'à ce stade, toute cette analyse s’est
déroulée totalement indépendamment de la machine ou de toute
contrainte logicielle.
Ces règles fonctionnent toujours,
même si il peux y avoir parfois plusieurs solutions pour chaque
modèles. Le processus de modélisation, après quelques tentatives,
est très simple à acquérir. Enfin, une fois le Modèle Conceptuel de
Donnée établi, vous aurez fais le plus difficile. La conception de
la base qui en découle est mécanique, et repose sur 6 règles
strictes, nécessaires et suffisantes. Transformer un MCD en Modèle
Logique, puis Physique est tellement standardisé que certains
logiciels le font automatiquement....
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.
vediovis.fr