Un Modèle Conceptuel de Données est la formalisation de la structure et de la signification des informations décrivant des objets et des associations perçus d'intérêt dans le domaine étudié, en faisant abstraction des solutions et contraintes techniques informatiques d'implantation en base de données.
Un MCD est, dans la culture francophone, exprimé en entité-relation Merise qui comporte les concepts basiques suivants :

• Entité : modélisation d'un objet d'intérêt (en terme de gestion) pour l'utilisateur,
• Relation : modélisation d'une association entre deux ou plusieurs entités
• Cardinalités : modélisation des participations mini et maxi d'une entité à une relation
• Propriétés : modélisation des informations descriptives rattachées à une entité ou une relation
• Identifiant : modélisation des propriétés contribuant à la détermination unique d'une occurrence d'un entité.

Le MCD a pour objectif de modéliser le discours – métier. Il ne doit pas anticiper sur les solutions relationnelles de mise en œuvre. C'est un contresens (ou une confusion…) que parler de MCD en termes de tables, clés primaires, clés étrangères ; il vaut mieux se situer directement au niveau MLD (si l'on y est plus à l'aise…). Cependant, plus de trente années d'expérience ont démontré l'intérêt de passer par une telle étape avant de passer à une structure logique, apportant une meilleure résilience aux bases de données ainsi construites (surtout lorsqu'elles atteignent des tailles professionnelles).

La modélisation du temps peut intervenir de trois manières.
1 - Des propriétés (ou attributs) temporelles
Il s'agit d'informations (modélisées comme des propriétés rattachées à des entités ou des relations) qui prennent leurs valeurs sur le domaine « temps ». Ces propriétés peuvent souvent se nommer date de…, ,mois de…, année de ..
Ainsi date de commande, date de naissance, date de survenance, …. sont certainement des propriétés des entités Commande, Personne, Sinistre. De telles propriétés peuvent également être affectées à des relations, au même titre et selon les mêmes règles que toute autre propriété.
2-La modélisation de phénomènes chronologiques Il s'agit alors de modéliser des situations où la dimension temps intervient explicitement, de manière régulière. Par exemple dans les planning, les emplois du temps, les suivis d'activités, les prévisions ou les statistiques. >
Par exemple, dans un suivi d'activité en gestion de projet, on s'intéresse aux nombre d'heures effectuées hebdomadairement par chaque salarié sur chaque affaire (projet, dossier ou activité nomenclaturée). >
Dans un tel cas, que l'on peut décliner à l'infini, le temps (ici chaque semaine ) est une dimension à part et va donc être modélisé comme une entité : on gère des semaines ! La modélisation la plus simple est la suivante :>

L'unité de temps modélisée comme une entité peut être un Jour, une Semaine, un Mois ou toute autre période de temps à délimiter (par son identification).
3-L'historisation Cette notion permet de modéliser, de façon concise au niveau conceptuel, le fait que l'on souhaite conserver les valeurs antérieures prises par une propriété, pour une occurrence d'une entité (ou d'une relation). Il existe ainsi, la valeur actuelle de la propriété et les valeurs antérieures.
Par exemple, pour une entité Contrat, on a une propriété bonus. Conformément aux règles de modélisation, le bonus accueille la valeur actuelle. L'historisation du bonus indique que l'on conservera également les valeurs antérieures du bonus pour tout contrat.
Cette historisation se note, au niveau conceptuel par un (H) au niveau de la propriété concernée. On peut en plus préciser :

• la datation, c'est à dire l'instant auquel la valeur a été remplacée par une valeur plus récente (heure-jour, jour, mois, année),
• le nombre de valeurs antérieures à conserver.

L'historisation peut également s'appliquer au niveau global d'une entité ou d'une relation. Des règles de transformation existe pour le passage au MLD.

Cela met en oeuvre la notion de contrainte inter-relations.
De la même façon que la notion de cardinalité exprime une contrainte de participation mini et maxi d'une occurrence quelconque d'une entité aux occurrence d'une relation, la contrainte inter- relations exprime une contrainte de participation à des occurrences de plusieurs relations.
Ces contraintes ont été mises au point dans la deuxième génération de Merise (90's).
Leur représentation graphique est la suivante:

• un rond qui accueille la notation du type de contrainte
• un trait pointillé qui relie le rond à l'entité (ou aux entités) concernées
• un trait plein qui relie le rond aux relations concernées

Les types de contraintes recensées et les plus communéments utilisés sont :

• l'exclusivité, notée X: la participation aux relations impliquées est mutuellement exclusive
• la totalité, notée T: la participation à au moins une des relations impliquées est obligatoire
• la partition, notée XT; combinaison des 2 précédentes
• la simultanéité, notée S: la participation aux relations impliquées est simultanée
• l'inclusion, noté I et orientée: si R2 est inclue dans R1, la participation d'une occurrence de l'entité à R2 doit auparavant participer à R1

Au-delà de ces types standards, on peut associer à toute contrainte inter-relation, une règle qui explicite la modalité spécifique de la contrainte.

Exemple :

l'entité M est liée dans un premier cas à l'entité A (si la valeur de l'attribut x est 1), sinon à B (si la valeur de x est 2) .
Alors on choisira une contrainte en X car les valeurs 1 et 2 sont (a priori) mutuellement exclusives, ou XT s'il n'y a que ces deux valeurs possibles. Préciser ensuite l'affectation à l'une ou l'autre par une règle.
Par ailleurs, dans ce cas, les cardinalités mini des "pattes" des relations concernées devraient être à 0; peu importe les maxis.

Depuis les débuts de la modélisation Entité-Relation de Merise, une relation binaire de cardinalité *,n - 1,1 ne doit pas être porteuse de propriétés. C'est considéré comme une "anomalie" et certains outils le diagnostiquent. Ces éventuelles propriétés doivent être définies du côté de l'entité de cardinalité 1,1 (c'est ce qui se passera de toute façon lors de la transformation). Mais attention, ce n'est plus vrai si la cardinalité est 0,1 !
Toutefois, on peut tolérer qu'une association 1,1 – 0,n soit porteuse de propriétés dans les premières phases d'élaboration du modèle (brouillon) ; mais cela devra être rectifié avant la finalisation du modèle.

Les contraintes de stabilité indiquent des limitations sur les possibilités d'évolution du système modélisé.
Elles portent sur:
- les valeurs des propriétés (propriété stable)
- le rattachement d'occurrences d'entité aux occurrences de relations (patte définitive, patte verrouillée)


Ces contraintes de stabilité s'apprécient par rapport au fonctionnement normal du système (par rapport au métier) et ne prennent pas en compte les éventuelles corrections d'erreurs.


Propriété stable: Les valeurs de cette propriété n'évoluent pas dans le temps; on peut dire qu'elles ne sont pas modifiables (sauf correction d'erreur). Sur les diagrammes, elle est notée (S) sur la propriété. Par définition, tout identifiant est stable. Il n'existe pas (lacune?) de notation indiquant que l'ensemble des propriétés de l'entité est stable.
Dans l'exemple, on considère que nom de Client et date de commande sont stables.


Patte définitive ou rattachement définitif : Une fois l'occurrence de l'entité impliquée dans une occurrence d'une relation, elle ne peut plus se détacher de cette occurrence de relation pour se rattacher à une autre occurrence. Sur les diagrammes, la patte définitive est notée (D). Dans l'exemple, une commande n'est rattachée qu'à un et un seul client(cardinalité 1,1), et cela définitivement; une commande ne peut pas changer de client !


Patte verrouillée ou rattachement verrouillé : Cette notion ne concerne que les pattes de relation à cardinalité maxi n. Elle signifie que les n occurrences de la relations rattachées à l'occurrence d'une entité ont été créées en même temps. On ne peut, dans le temps, ni rajouter (n+1) ni supprimer (n-1) d'occurrences de la relation à l'occurrence de l'entité; cette patte est verrouillée. Dans l'exemple, on ne peut ni rajouter ni retirer une ligne de commande à une commande existante (ce comportement est assez classique avec les lignes d'écritures comptables !)


Quand à la prise en compte au niveau logique, elle reste assez délicate. En effet, vu de la base de données, il est difficile de distinguer une modification due à une évolution "naturelle" du système et une modification due à une "correction d'erreur". On devra cependant tenir compte de cette notion de stabilité dans la conception des interfaces utilisateurs en ne permettant pas la modification des valeurs des propriétés concernées dans des transactions "normales" et en réservant des transactions particulières aux corrections des erreurs.

La notion de relation dite « réflexive » intervient lorsqu'une même entité est impliquée plusieurs fois dans une relation (plusieurs « pattes » sur la même entité).
Dans une relation binaire, la relation semble boucler sur elle-même, d'où le nom de réflexive ; mais on peut rencontrer cette situation dans les relations ternaires et plus.
Une relation binaire « reflexive » exprime par exemple :

• un Contrat est l'avenant d'un Contrat précédent
• un Projet est la suite d'un autre Projet
• un Article de décompose en Articles
• à partir d'un Diplôme, on peut obtenir d'autres Diplômes

Les cardinalités maxi peuvent être 1 ou n, selon le cas.
Les cardinalités mini sont obligatoirement 0 (sinon on crée une « boucle » sans fin…).
Pour distinguer chaque « patte », on lui affecte un rôle.
Exemple:

L'identification peut être obtenue de plusieurs façons :
a) de manière absolue, où toutes les propriétés contribuant à l'identification appartiennent à l'entité, soit :

• une propriété spécifiquement inventée à cette fin (code, référence, n°) qui n'est pas obligatoirement numérique
• une propriété (ou une composition de propriétés) naturelle(s) intrinsèques à l'entité; par exemple nom + prénom + date et lieu de naissance d'une personne

b) de manière relative, où l'identification nécessite la présence d'identifiant(s) appartenant à une (ou plusieurs autres) entité(s) reliée(s) à l'entité à identifier
- l'entité comporte une propriété intrinsèque, participant à l'identification relative (cas classique du n° de ligne de commande par rapport à la commande)

Ici, la Ligne de commande est identifiée par n° commande + n° ligne
- l'entité est identifiée relativement à plusieurs autres entités et ne comporte pas de propriété intrinsèque ; on qualifie alors cette entité d'entité faible.
(cas d'un Dossier identifié par la Personne concernée et le Service gestionnaire, sans aucun n° spécifique de dossier ; dans chaque Service, le Dossier est identifié par le nom/prénom/date de naissance de la Personne, chaque Service ayant son Dossier (évidemment différent) sur chaque Personne)

Ici, le Dossier est identifié par sigle service + nom + prénom + date de naissance.
Dossier n'a pas d'identifiant « propre » et pourtant ce n'est pas une relation !
L'entité Dossier participera naturellement à des relations, comme toute autre entité.
Bien sûr, on trouvera toujours un informaticien pour imposer un n° de dossier ignoré de tous, confondant ainsi le niveau conceptuel et le niveau logique.
Attention : Il s'agit de la modélisation conceptuelle qui sera ensuite traduite en logique relationnel avec la redondance due aux clés étrangères.

Dans un modèle où l'on souhaiterait désigner sous une même entité un ensemble d'occurences, on peut se retrouver bloqué face au fait que certaines caractéristiques (nécessaires à certaines occurences) ne puissent pas être renseignées pour toutes les occurences. Par exemple, si l'on considère la gestion d'un parc informatique : les caractéristiques d'un écran (diagonale, nbHz) ne correspondent pas aux caratéristiques d'un lecteur de CD. Pourtant ce sont tout deux des matériels informatiques.
Ce problème est connu sous le nom de "liste variable de propriétés". Il exprime que certaines propriétés n'ont de pertinence que pour certaines occurences de l'entité.
Dans notre exemple, voici trois types de solutions (résumées ici), chacune ayant des conditions de mise en oeuvre ainsi que des avantages et inconvénients.

• 1/ Accepter que ces propriétés n'aient pas de pertinence pour certaines occurrences de l'entité
• 2/ Expliciter les sous-populations correspondantes par une modélisation en termes de sous-types

• 3/ Recourir à la métamodélisation, c'est à dire modéliser les propriétés en tant qu'occurences d'entités-types

Il existe des règles de transformation d'un MCD Merise en un modèle de classe UML.
Ces règles ont été élaborées dès l'apparation d'OMT (il y a environ un dizaine d'années) et publiées dans de nombreux ouvrages (Exemple : De UML à SQL de C.Soutou, Eurolles).
Elles sont d'ailleurs mises en oeuvre dans les outils qui disposent de ces deux modélisations (Win'Design et Power AMC).


Illustration et explication sur un cas :
Le MCD :

Le diagramme de classe correspondant :

> toute entité est transfomée en classe
Ses propriétés deviennent des attributs. Son identifiant devient un attribut identifiant ou clé.

> toute relation est transformée en association Attention bien qu'UML propose des relations n-aires, nombre d'outils se limitent aux relations binaires. Les cardinalités des "pattes" de relation deviennent des multiplicités des terminaisons des associations. Attention, en UML, les multiplicités sont notées sur la terminaison opposée (çà marche bien sur les associations binaires, plus problématique avec les n-aires...) :
=> 0,1 -> 0..1
=>1,1 -> 1
=>0,n -> 0..*
=>1,n -> 1..*


> une relation porteuse de propriétés est en plus transformée en une classe-association, reliée à l'association représentant la relation et accueillant les attributs correspondant aux propriétés

> les relations "réflexives" suivent la règle ci-dessus

> l'héritage est transformé en généralisation
Attention: UML perd le fait qu'il y avait éventuellement plusieurs héritages sémantiquement distincts dans le MCD
> une relation "identifiante" (participant à une identification relative) se transforme en une association avec une agrégation

> les contraintes inter-relation se transforment en contraintes (éventuellement stéréotypées)

Ces règles couvrent la majorité des cas ( ce qui veut dire que l'on pourrait sans doute en identifier d'autres).

1/ Dépendance fonctionnnelle et CIF
Dans Merise, ces deux termes recouvrent globalement la même notion. Le terme dépendance fonctionnelle fait référence à une notion mathématique entre ensembles.
On dit que, entre deux ensembles A et B, il existe une dépendance fonctionnelle si à un élément (a) de A ne correspond qu'un élément (b) de B. On note cette dépendance A ---> B . On appelle A l'origine, et B la cible de la dépendance fonctionnelle. Il existe également des dépendances plus complexes lorsque l'ensemble d'origine est composé de "n-uples" d'éléments A x B ---> C

Dans Merise cette notion s'applique explicitement aux relations; elle ne se modélise pas indépendamment des relations; elle ne prend son sens que dans le cadre d'une relation citée. On dit alors que cette relation est porteuse d'une dépendance fonctionnelle ou d'une CIF (contrainte d'intégrité fonctionnelle).


La mise en oeuvre de la notion dépend de la dimension de la relation.
a/ Dans une relation binaire, une cardinalité maxi à 1 (0,1 ou 1,1) sur l'une des pattes induit obligatoirement une dépendance fonctionnelle.
Dans l'exemple suivant, on dit usuellement que la relation "est située dans" est (porteuse d') une dépendance fonctionnelle. Il est inutile d'utiliser un symbole explicite.

b/ Dans une relation de dimension > 2 (ternaire ou plus), la notion de dépendance fonctionnelle peut impliquer tout ou partie des entités de la relation et n'est pas sytématiquement liée aux cardinalités. Elle a donc une modélisation explicite et prend alors le nom de contrainte d'intégrité fonctionnelle, représentée par un rond noté CIF, relié à la relation porteuse (trait pointillé) et aux entités concernées (trait plein) dont l'un est porteur d'une flèche (la cible de la CIF).
Si la dimension de la CIF (nombre d'entités impliquées) est inférieure à celle de la relation porteuse, alors on doit envisager une décomposition de la relation en plusieurs relations, avec généralement intégration de la CIF comme simple dépendance fonctionnelle d'une relation issue de la décomposition (cf. tout bon ouvrage sur Merise...).
Sinon, la CIF reste explicitement modélisée car elle a des conséquences sur la transformation en relationnel. Dans la pratique, seules des relations ternaires ou plus peuvent conserver une CIF (qui implique alors la totalité des entités de la relation concernée). Pour les cardinalités, si l'une des pattes de la relation est dotée d'une cardinalité maxi à 1, alors il y a alors autant de CIF vers les autres entités, et décomposition de la relation initiale.

En conséquence, les seules CIF "persistantes" explicitement et obligatoirement modélisées portent sur des relations ternaires (ou plus) avec toutes les cardinalités maxi à (n).

Dans l'exemple ci-dessous, qui évoque une organisation d'un examen multi sites, : - un Candidat est affecté à un Site ,
- un Site comporte des Salles ,
- l'examen comporte des Matières,
- un Candidat compose une Matière dans une Salle ,
- pour une Matière, un Candidat ne compose que dans une Salle (CIF)
Pourtant une Matière peut être composée par plusieurs Candidats et dans plusieurs Salles (1,n)
une Salle peut être le lieu de composition de plusieurs Candidats et plusieurs Matières (1,n)
un Candidat peut composer dans plusieurs Matières et plusieurs Salles (1,n)

Attention, ce sont les pattes de la relation qui portent les cardinalités et non celles de CIF. De plus la CIF doit être relié à la relation à laquelle la CIF s'applique.

Le code postal en France identifie le bureau distributeur qui achemine le courrier dans une commune. En conséquence et d'après cette définition, il n'EXISTE pas de relation entre le code postal et le code du département de la commune (relisez la définition si vous n'êtes pas convaincu !). Prenons l'exemple d'une commune limitrophe d'un département, « La FEUILLADE », dont le code postal est 19600, est située dans le département « 24 (Dordogne) ».
Le code postal n'identifie que le bureau distributeur; et il assez rare qu'une application gère explicitement les bureaux distributeurs (sauf les spécialistes du routage...). Il n'y a pas de correspondance biunivoque entre le code postal et une ville. Une commune peut avoir plusieurs codes postaux, un code postal peut recouvrir plusieurs communes !
D'ailleurs, la norme Poste de codage des adresses distingue bien Ville, Code postal, Bureau distributeur .
Dans cette non correspondance entre code postal et département, il y a toute la Corse ! Les codes postaux (restés numériques) sont tous 20xxx 20000 Ajaccio (Corde du Sud) , 20200 Bastia (Haute-Corse).
Attention donc dans vos modèles!

Soit l'exemple suivant : Une personne est soit un contact soit un utilisateur. L'entité "mère" est PERSONNE. Les entités CONTACT et UTILISATEUR héritent de PERSONNE.
Ils existent trois types d'héritages possibles à choisir selon les contraintes de son projet.

1/ XT (exclusion et totalité sous Win Design) = héritage avec partition :
Une personne est soit un contact, soit un utilisateur (mais pas les deux). L'union des contacts et des utilisateurs constitue l'ensemble des personnes.
2/ X = héritage avec exlusion :
Pour les cas où l'union des contacts et des utilisateurs ne constitue pas l'ensemble des personnes : une personne n'est ni un contact ni un utilisateur. C'est pour utiliser l'héritage comme pourvoyeur de propriétés identiques plus que dans un contexte sémantique semble-t-il.
3/ T= héritage avec totalité :
Pour représenter qu'il existe des personnes à la fois contact et client.

On ne crée pas de clé étrangère dans un MCD!! La clé étrangère sera générée automatiquement lors de la génération du MLD avec l'outil.
Soit le MCD suivant :

Le MLD généré est :

On remarque la création d'une clé étrangère (NUMSERVICE) dans l'entité employé sachant qu'un employé travaille dans un et un seul service.