FAQ Merise et modélisation de donnéesConsultez toutes les FAQ

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é.
  
  

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 : 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.

• 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.
  
  

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
  

• 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
  

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
  
  

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
  

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.

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

• 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
  

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.