Modèle Conceptuel des Données (M.C.D.)

En principe, il n'y a pas de MCD modèle. D'une gestion à une autre similaire, le MCD peut changer car il reflète le mode de fonctionnement qui peut être différent d'une entreprise à une autre. Un MCD est la représentation sur papier avec une codification graphique du modèle de fonctionnement d'une gestion à effectuer. Ce MCD permettra par la suite la création des tables d'une base de données qui permettra cette gestion. Les éléments essentiels à retenir pour l'instant sont les entités (ou objets de gestion), les relation et les cardinalités.

Entités, objets

Quand on décrit une gestion on le fait avec des phrases contenant des mots et des verbes. Les mots vous orienteront vers les objets de gestion. Exemple : Dans un magasin, des clients achètent des produits livrés par des fournisseurs". Dans un premier temps on retiendra magasin, clients, produits, fournisseurs comme objets de gestion.

Les objets de gestion possèdent des caractéristiques, des propriétes. Les propriétés d'un client seraient (par exemple) ses noms, prénoms, adresse, téléphone, mail, etc... Celles d'un produit : référence, libellé, prix, TVA appliquée, etc... En fait, les propriétés de l'objet Clients dépendra de la gestion à effectuer. Le numéro de sécurité sociale, par exemple, ou la profession d'un client peuvent ne pas en faire partie. Ils ne font pas partie de 'lunivers du discours de cette gestion.

Sur le MCD, ces objets de gestion sont représentés graphiquement par une "boîte" rectangulaire avec un titre et contenant toutes les propriétés de cet objet, toutes celles qui seront retenues comme utiles et/ou nécessaires pour la gestion à effectuer.

Parmi les propriétés d'un objet, on repérera celle qui pourra l'identifier de manière unique, non ambigüe et qui servira d'identifiant. Une référence ou un code barre de produit, un numéro ISBN de livre peuvent par exemple faire office d'identifiant pour ce type d'objet. "Nom + prénom" d'un client ne peuvent pas servir d'identifiant : il peut y avoir des homonymes. "Nom + prénom + date de naissance" conviendrait mieux mais il n'est pas toujours possible (ni utile) de connaître la date de naissance. Dans le cas où aucune propriété ne peut faire office d'identifiant, on utilisera un numéro séquentiel. Ce sera le client n°1 ou n°127... Peu importe le numéro. Il ne servira qu'à désigner, qu'à identifier une seule occurence de l'objet de gestion. Sur un MCD, l'identifiant esr souligné.

Objets merise
Exemples d'objets Merise.

Chaque objet de gestion doit posséder un identifiant.
L'identifiant doit être unique.

Relations

Dans la description de la gestion les verbes vous orienteront vers les relations de gestion : Dans un magasin, des clients achètent des produits livrés par des fournisseurs". On retiendra ici, les relations, à savoir acheter, livrer. Les actions acheter et livrer n'ont pas d'existence physique et ne fournissent que la relation existant entre les objets. Sur le MCD, elles se représentent par des ovales contenant le verbe exprimant la relation. un client achète un produit, un produit est livré au magasin par un fournisseur.

Relations Merise
Exemples de relations Merise.

Propriétés portées par la relation

La plupart du temps, bien que ce ne soit pas systématique, on sera amené à enregistrer des informations lorsqu'une relation s'établit entre des objets de gestion. Par exemple, au moment d'un achat on pourrait être amené à enregistrer la date d'achat, la quantité achetée, le moyen de paiement, l'éventuelle remise appliquée. Ces informations, par exemple la quantité, ne sont spécifiques ni au client ni au produit car un produit peut être acheté en trois exemplaire par un client et en un seul par un autre ; les produits ne sont pas obligatoirement payés par carte bancaire et certains clients payent en chèque, en carte bancaire ou en espèces. Ces propriétés spécifiques à la relation ne peuvent donc pas être notées dans l'objet Clients ni dans l'objet Produits. Elles sont notées dans la relation et s'appellent des propriétés portées (par la relation). Sur un MCD, elles se notent de la façon indiquée ci-dessous.

Propriétés portées par la relation
Exemples de propriétés portées par la relation.

Cardinalités

A chaque patte d'une relation sont accolés deux nombres séparés par une virgule : les cardinalités. Il y a la cadinalité minimale (cmin) et la cardinalité maximale (cmax) sous la forme : cmin,cmax.

Les cardinalités représentent le nombre de fois qu'une occurence d'un objet participe à une relation et sont représentés par :

Exemples (les relations sont placées entre parenthèses) :

Cardinalités
Exemples de cardinalités.

Clients 0,1 cmin=0
cmax=1
Une occurrence de client peut ne pas acheter (ne participe pas à la relation "acheter")
S'il achète, il n'achète qu'une seule fois (participe à la relation "acheter")
  0,n cmin=0
cmax=n
Une occurrence de client peut ne pas acheter (ne participe pas à la relation "acheter")
S'il achète, il peut acheter plusieurs fois (participe à la relation "acheter")
  1,1 cmin=1
cmax=1
Une occurrence de client doit acheter une fois (pas de clients potentiels, participe à la relation "acheter")
Il achète au plus une seule fois (participe à la relation "acheter")
  1,n cmin=1
cmax=n
Une occurrence de client doit acheter une fois (pas de clients potentiels, participe à la relation "acheter")
Mais peut acheter plusieurs fois (participe à la relation "acheter")
Produits 0,1 cmin=0
cmax=1
Une occurrence de produit peut ne pas être achetée par les clients (ne participe pas à la relation "acheter")
S'il est acheté, il ne peut l'être qu'une seule fois (exemplaire unique. participe à la relation "acheter")
  0,n cmin=0
cmax=n
Une occurrence de produit peut ne pas être achetée par les clients (ne participe pas à la relation "acheter")
S'il est acheté, il peut l'être plusieurs fois (participe à la relation "acheter")
  1,1 cmin=1
cmax=1
Une occurrence de produit est obligatoirement achetée au moins une fois (participe à la relation "acheter")
Et il n'est acheté qu'une seule fois (exemplaire unique vendu sur commande, participe à la relation "acheter")
  1,n cmin=1
cmax=n
Une occurrence de produit est obligatoirement achetée au moins une fois (participe à la relation "acheter")
Et il peut être acheté plusieurs fois (participe à la relation "acheter")

L'identifiant d'une relation est obtenu par la concaténation des identifiants des objets participant à la relation.
Dans l'exemple ci-dessus, l'identifiant de la relation "acheter" serait "ID client – référence"
L'identifiant doit être unique.

Sortir certaines propriétés

Aussi bien dans les objets que dans les relations, les identifiants doivent être uniques. Le schéma de l'exemple ci-dessus est le suivant :
– Clients (idcli, nom, pren, voie, cpost, ville, tel, mail, etc.)
– Produits (idprod, libel, prix, unite, etc.)
– Acheter (idcli,idprod, date, quantite, remise, paiement)

Soit le client n°15 qui achète le produit n° 49. L'identifiant de la relation "Acheter" sera donc "15 – 49" et en tant qu'identifiant, il ne pourra apparaître qu'une seule fois. En clair, ce client ne pourra pas racheter une seconde fois le même produit. Il faudra un élément distinctif qui permettra de rendre l'identifiant unique, la date par exemple et l'identifiant de la relation "acheter" deviendra "15 – 49 – 10/02/2022", ce qui lui permettra de racheter le même produit le lendemain... mais pas le même jour ! A la place de la date, il aurait mieux valu mettre la date-heure pour avoir "15 – 49 – 10/02/2022 10:48:27" (la date et l'heure, c'est d'ailleurs ce qu'on trouve sur les tickets de caisse). Dans ce cas, la propriété "date" portée par la relation doit être sortie de la relation pour devenir un objet afin de faire comprendre que la concaténation des identifiants des trois objets formeront l'identifiant de la relation. Exemple ci-dessous :

Relation à trois pattes
Exemples de modélisation rectifiée.

Cardinalités dates : 0,n. Il est possible qu'une date-heure ne participe pas à la relation "acheter" (cmin=0, dimanche ou jour férié) ; mais il est possible qu'une date-heure apparaisse plusieurs fois (cmax=n) car rien n'empêche que l'enregistrement d'une vente intervienne au même moment mais dans ce cas, ce ne serait pas à la même caisse, donc pas le même client (et probablement pas le même produit) et les identifiants de la relation seraient différents : "15 – 49 – 10/02/2022 10:48:27" est différent de "104 – 32 – 10/02/2022 10:48:27". Il pourrait être nécessaire de rajouter un objet "Caisse" participant à la relation. Cela dépend de la gestion à effectuer.

Dans la pratique, lors de la phase MLD (Modèle Logique des Données) Il n'y aura pas de table Dates correspondant à l'objet Dates. Si cet objet ne contient qu'une seule propriété (faisant office d'dentifiant) et que celle-ci est fournie à la relation (comme l'identifant de Clients et de Produits), il ne sert à rien de la mentionner et dans la table et dans la relation. Une seule fois suffit. Mais il est nécessaire de mentionner l'objet Dates sur le MCD pour faire savoir qu'il ne faut pas oublier de concaténer cet identifiant aux autres. Le schéma du modèle serait le suivant :
– Clients (idcli, nom, pren, voie, cpost, ville, tel, mail, etc.)
– Produits (idprod, libel, prix, unit", etc.)
– Acheter (idcli,idprod, horodate, quantite, remise, paiement)
Dates (horodate)

Types de relations

Qu'elle soit à deux, à trois, à quatre "pattes" ou plus, lorsque toutes les cmax de la relation sont à n on dit que la relation est n-aire. Lorsqu'au moins une cmax est à 1 on dit que la relation est une-aire. C'est le type de relation (n-aire ou une-aire) qui va déterminer par la suite (MLD) la création des tables dans la base de données.

 

 

Mise à jour le 10/02/2022 à 08:53:55