(1) Identifier les entités présentes
(2) 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.
(3) 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.
(4) Etablir les relations entre les différentes entités
Reprenons notre texte initial :
"Un Abonné s'inscrit à une ou plusieurs rubriques en précisant une motivation propre à chaque rubrique.
Chaque Rubrique envoie une NewsLetter."
Les verbes sont en rouge et relient les entités. Il suffit de les intégrer au schéma :
(5) Identifier les cardinalités
Un Abonné a ici une et une seule Motivation d'inscription par rubrique,
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) :
(6) 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.
Il est également conseillé de montrer des exemples de tuples (fictifs ou non) renseignés dans les différentes tables de la base de données pour illustrer qu'elle données sont attendues pour chaque propriété.