Cours en Devlopement Informatique

  • Merise

Merise



Merise 

Introduction

Le Modèle Conceptuel de Données ou MCD est le plus connu et le plus utilisé des éléments de la méthode Merise. Il permet une représentation claire des données et des liens entre les données du domaine étudié.

Ce document s’attache donc pour l’essentiel à présenter ce modèle de conception. Toutefois, il est intéressant de survoler les autres modèles proposés afin d’avoir une idée précise de l’ensemble de la méthode proposé.

Certains modèles, comme le modèle de communication (MCC) ou le modèle de flux conceptuel (MFC) pourront vous être d’une grande utilité dans votre démarche d’informatisation d’un domaine d’étude.

Un MCD a plusieurs buts :

  • C’est un outil de communication : communication avec le donneur d’ordre, à l’intérieur d’une équipe de développement, avec les utilisateurs, ….
  • C’est un outil de normalisation : passage de règles implicites et orales à des règles de gestion écrites, assimilation des systèmes parallèles, …

La réalisation d’un MCD peut se dérouler en trois étapes.

Nous allons aborder ces étapes au travers d’une étude de cas simple. Le domaine étudié est un service Achat.

1. Constitution du dictionnaire des données

Cette étape consiste à référencer toutes les données du domaine. Pour notre service Achat, on peut recenser un certain nombre d’éléments :

  • Nom du fournisseur
  • Date de la commande
  • Numéro de la commande
  • Quantité en stock de l’article
  • Référence de l’article
  • Prix unitaire de l’article
  • Désignation de l’article
  • Quantité commandée
  • Condition de paiement
  • Condition de livraison
  • Téléphone du fournisseur
  • Adresse du fournisseur
  • Adresse de livraison
  • Unité de l’article
  • Taux de TVA

Remarques :

Lors de l’établissement du dictionnaire, il peut s’y glisser des termes qui ne qualifient pas nécessairement des données.

Il peut s’agir de traitements de données ou des flux d’information.

Certaines expressions peuvent être polysémiques : elles recouvrent plusieurs sens, comme ici les conditions de paiement.

D’autres expressions peuvent être à contrario synonymes.

Ces problèmes peuvent être réglés dans les étapes suivantes de création du MCD. D’une manière générale, on essaiera de constituer un dictionnaire de données exhaustif.

Chaque terme du dictionnaire des données est appelé Propriété. L’étape suivant consiste à regrouper les propriétés dans des entités.

2.  Entités

Dans notre cas, trois entités semblent se dégager :

  • L’entité Fournisseur
  • L’entité Article
  • L’entité Commande

Une fois ces entités définies, on leur associe les propriétés du dictionnaire des données.

Un premier essai nous donne ceci :

Une propriété ne peut être dans plusieurs entités. Ici, par exemple, le prix d’un article est une propriété de l’entité Article. Mais dans la mesure où ce prix est négocié en fonction de la commande, il sera nécessaire de disposer de deux propriétés prix : une propriété Prix Article dans l’entité Article et une propriété Prix Commande dans l’entité Commande

Chaque fois qu’une propriété est associée à une entité on le signale dans le dictionnaire de données.

 

    • F Nom du fournisseur
    • C Date de la commande
    • C Numéro de la commande
    • Quantité en stock de l’article
    • A Référence de l’article
    • A Prix unitaire de l’article
    • A Désignation de l’article
    • Quantité commandée
    • Condition de paiement
    • Condition de livraison
    • F Téléphone du fournisseur
    • F Adresse du fournisseur
    • Adresse de livraison
    • A Unité de l’article
    • Taux de TVA

On se rend compte que certain éléments du dictionnaire de données ne figurent pas dans les entités. Ceci peut être dû à plusieurs causes :

  • Certains éléments ne sont pas des données. C’est peut être le cas des conditions de paiement. En effet, ces conditions peuvent être le résultat d’un calcul dépendant de la quantité commandée, du délai de livraison, …
  • Certains éléments ne sont pas dans le domaine étudié. C’est le cas de la quantité en stock de l’article. C’est bien une donnée mais cette donnée concerne la Gestion de stocks et non le service Achat.
  • Certains éléments sont peut être des propriétés d’entités que l’on n’a pas encore créées ou ils qualifient une relation entre entités. Par exemple la quantité commandée ne peut être une propriété de l’entité Commande que si une commande ne fait l’objet que d’un seul article, ce qui est un cas particulier. Généralement une commande comporte plusieurs articles et il faudrait créer les propriétés Quantité 1, Quantité 2, Quantité 3, … mais notre commande serait toujours limitée à un nombre N (ici 3) d'articles.

La prochaine phase est précisément la création de relation entre les entités.

Pour terminer la création des entités, il faut que chaque entité ait un identifiant. Un identifiant permet de discriminer chaque occurrence d’une entité. Tout identifiant aura donc une valeur unique.

Par exemple, pour l’entité Article, l’identifiant est la Référence d’un article car deux articles différents ne peuvent avoir la même référence.

Un occurrence de l’entité Article est : 01A12,12.45,Pince à vélo,2.

Pour distinguer les identifiants des autres propriétés, on a l’habitude de souligner la propriété constituant l’identifiant de l’entité.

3. Relations

Une relation est un lien entre différentes entités. Ces liens se réalisent en se posant la question : quelle entité interagit sur cette ou ces entités.

Par exemple, un fournisseur fournit un article et un article est fournit par un fournisseur. En effet il y a interaction entre les entités Fournisseur et Article que l’on traduit par l’action de Fournir.

De même, une commande comporte des articles et les article appartiennent à une commande. La relation entre les entités Commande et Article est l’action de Commander.

Ajouter un commentaire

Veuillez vous connecter pour ajouter un commentaire.

Pas encore de commentaires.