Actualites  Archives
 Inscription | Plan du site | 9  visiteurs actifs  
  
     A la Une
  Actualités
  Dossiers
  Coin Technique
  Agenda des salons
  Annonces Web
  Référencement

     Diagnostic
  Popularité Site Web
  Positionnement Moteur
  WebPage Alerte
  Positionnement Google

     Archives
  Sélection
  Expérience qui parle
  Internet quotidien
  Tous les dossiers

     Services
  Hébergement
  Communiqués de Presse
  Contenu éditorial
  Webmastering

     Contact
  Nous contacter
  La protection des données personnelles

     Technique
  Merise

     Login
   
    
Inscription

Mot de passe oublié?

 Actualités > Merise



Merise
Analyser 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.
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>>

Stéphane Lambert
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



Merise : 2ème partie
Merise: 3ème partie
Merise: 4 ème partie
Merise: 5ème Partie
Merise: 6ème Partie
Merise: 7ème Partie
Merise: 8ème Partie

 
 

Sam-Mag - Un site du réseau ACORUS 1996-2007
© Copyright ACORUS All rights reserved.- Mentions légales

Ce site respecte la loi Informatique et Libertés. Pour en savoir plus sur la protection des données personnelles, cliquez

 
Webmaster