Le Système d'Information
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....
Lire la 2ème partie>>
Tous droits réservés - Reproduction même
partielle interdite sans autorisation préalable
Merise : 2ème partie
Webmaster