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é.
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
Pour notre service Achat, on peut recenser un certain nombre d’éléments :
|
|
Remarque :
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-MCD : 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.
|
|
On se rend compte que certains é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.
Référence | Prix | Désignation | Unité |
01A12 | 12.45 | Pince à vélo | 2 |
01R11 | 105.00 | Pneu | 2 |
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- MCD : 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 fourni 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 articles appartiennent à une commande. La relation entre les entités Commande et Article est l’action de Commander.
Une relation peut avoir des propriétés. C’est le cas ici de la propriété Quantité qui est une propriété de la relation Commander.
De même la possibilité pour les relations d’avoir des propriétés va nous permettre de créer de nouvelles données pour lever l’ambiguïté de la propriété Prix.
En effet la propriété Prix Unitaire est associée à l’entité Article, la propriété Prix commande est associée à la relation Commander et la propriété Prix fournisseur est associée à la relation Fournir.
4- MCD : Cardinalités
Notre MCD devient :
Les valeurs (0,n) ou (1,n) sont des cardinalités. Les cardinalités expriment le nombre minimum et maximum de fois qu’une entité est concernée par la relation.
Par exemple la cardinalité (0,n) de l’entité Fournisseur pour la relation Fournir signifie qu’un fournisseur peut fournir au moins zéro articles et au plus n articles. De même la cardinalité (1,n) de l’entité Article pour la relation Fournir signifie qu’un article est fourni par au moins un fournisseur et au plus N fournisseurs.
Plus intéressant est de constater que la relation Commander résout le problème évoqué lors de la création des entités et du rattachement de la donnée Quantité à l’entité Commande.
La cardinalité (1,n) de l’entité Commande pour la relation Commander signifie qu’une commande peut avoir au moins un article et au plus N (CQFD).
Exemple complet
Si nous reprenons notre dictionnaire de données nous avons :
|
|
Il nous reste l’Adresse de livraison et le Taux de TVA. L’Adresse de livraison est une propriété de l’entité Commande. Pour le taux de TVA, il y a deux façons de résoudre le problème :
- Soit rattacher le taux à la relation Commander
- Soit créer une entité Taux de TVA :
On ne peut, dans l’état actuel de nos connaissances, définir qu’elle est la présentation la mieux adaptée au problème. Il se peut de plus que la TVA soit fonction de la nature de l’article et/ou du lieu de livraison (Export, Régime Intra/Extra Communautaire).
Un MCD ne peut être unique et varie nécessairement en fonction de règles de gestion et de choix du concepteur.
Remarques :
- Une relation peut ne pas avoir de propriété
- Une relation peut être binaire, ternaire, …
Bravo! vous avez terminer le cours sur le modèle conceptuel de données. Si vous voulez découvrir un autre modèle de la méthode merise qui est très lié au mcd , le voilà : le MLD.
Vous pouvez suivre la liste des vidéos du cours base de données (Merise + Sql + Transact sql) sur notre chaine youtube : Vidéos Bases de données.