Les principales

extensions au
modèle Merise
Les concepts et les modes de représentation des données de
Merise ont été "étendus" au cours du temps. Ces extensions sont
relativement peu connues; elles font peur car on pense souvent
qu'elles alourdissent les schémas de données. Or, elles ne font le
plus souvent que rendre ceux-ci plus simples et plus lisibles. Voici
quelques unes des notions de Merise étendue, présenté sur
l'exemple célèbre (et fort usité !) du village gaulois.

I Entité-forte - Entité faible

Au cours du temps, dans un célèbre village gaulois, un
certain nombre de batailles ont eu lieu contre les camps
retranchés romains des environs. Chaque bataille eut
une durée limitée. Plusieurs batailles peuvent avoir lieu
le mêmme jour.
En Merise "classique", une analyse des données
inhérentes à ces batailles aurait conduit au schéma
suivant.
Camp_romain
Bataille Date
nom du camp romain
nombre de légionnaires 0,n Durée de la bataille 0,n date de la bataille
nom du chef du camp heure

13
Ne disposant pas d'identifiant naturel pour les batailles
(le nom du camp ne suffit pas puisqu'il peut y avoir
différentes batailles successives contre les camps; la
date de bataille ne suffit pas non plus puisqu'il peut y
avoir plusieurs batailles le même jour et même contre
un seul et même camp), on ne peut pas créer d'entité
Bataille. On place donc la donnée Durée de la bataille
sur une association dénommée Bataille faisant
intervenir les entités Camp_romain et Date. Dans
l'entité Date, il faut une heure, pour identifier
parfaitement les différentes batailles d'un même jour.
Ainsi, une bataille est identifiée par un nom de camp,
ainsi qu'une date et une heure, ce qui donne un
identifiant lourd et peu pratique et ce qui diminue la
lisibilité du modèle.
En "Merise étendu", on peut considérer que Bataille est
une entité faible de l'entité forte Camp-romain. On
entend par là que l'identifiant de Bataille est composé
de l'identifiant de Camp-romain, suivi d'un numéro de
rang. Par exemple, on aura les batailles "C1 01",
"C102" etc.
Sur le schéma, ce concept est matérialisé par des
parenthèses autour de la cardinalité de l'arc d'association
qui part de l'entité faible Bataille.

14
Dans Bataille, le numéro de rang est un identifiant
relatif. Il n'a de sens qu'associé à l'identifiant de l'entité
forte Camp_romain.

Camp_romain Bataille
nom du camp romain
contre
(1,1) numéro_rang
nombre de légionnaires 0,n
durée de la bataille
nom du chef du camp date de la bataille

Si on génére le modèle relationnel, on peut vérifier que

l'identifiant de Bataille est bien composé :

Idf entité faible = Idf entité forte + ppté relative

Idf relatif

Camp_romain nom du camp romain = nom du camp romain Bataille

nom du camp romain nom du camp romain
nombre de légionnaires numéro_rang
nom du chef du camp durée de la bataille
date de la bataille

EXERCICE
Dans l’entreprise X, les factures relatives à un
chantier sont identifiés par le numéro du chantier et
par un numéro d’ordre séquentiel (1,2 , 3, …).
Exemple :
N°Chantier N°Facture
Le numéro de facture
001 1 recommence à 1 à chaque
001 2 changement de chantier.
001 3
002 1

15
003 1

On dispose de 2 extraits de MCD différents pour

modéliser les faits ci-dessus :
Solution 1 1,n 1,1
CHANTIER FACTURE
N° Chantier FIGURER N°Facture
AdrChantier DateFacture
NomChef

Solution 2
1,n 1,1
CHANTIER FACTURE
N° Chantier FIGURER N°Chantier+N°Facture
AdrChantier DateFacture
NomChef

Quelle solution vous paraît

meilleure ?
Dans la solution 1, on aboutit à des doublons (2
factures porteraient le même numéro)
La solution 2 est plus conforme car elle intègre le
numéro de chantier dans l’identifiant de l’entité
FACTURE et élimine ainsi le problème des doublons.
Problème ?: dans un MCD on ne peut pas reprendre
deux fois une même propriété. D’où la notation
apportée par Merise 2.

Avec Merise 2 la représentation est la suivante :

1,n
(1,1)
CHANTIER FACTURE
N° Chantier FIGURER N°Facture
AdrChantier DateFacture
NomChef

16
 Les parenthèses entourant les cardinalités 1,1
indiquent que N° Facture est un identifiant relatif.

L’identifiant complet de l’entité FACTURE est la

concaténation de N°Chantier et N°Facture.
Cela se traduira au niveau relationnel par le schéma
suivant :
CHANTIER( N°Chantier,AdrChantier, NomChef)
FACTURE(#N° Chantier, N°Facture, DateFacture)

II Sous- typage - généralisation/spécialisation - liens

"Père-fils"
En Merise classique, on représente le fait que certains
des habitants du village sont des guerriers et obtiennent
des décorations et participent à des batailles aucours
desquelles ils remportent des trophées (des casques) et
les autres exercent d’autres fonctions par le schéma
suivant :

17
 Habitant Fonction
nom
Exerce
Nom_fonction
nombre_de_décorations
1,1 0,n âge_mini
date_naissance âge_maxi
adresse
0,n

Camp_romain participation
nom du camp romain nombre_de_casques
nombre de légionnaires
nom du chef du camp

0,n 1,n

contre Bataille
numéro_rang
(1,1) durée de la bataille
date de la bataille

Pb : ce schéma n'indique pas que seuls les guerriers ont

des décorations et participent à aux batailles.
En "Merise étendue", on crée une pseudo-entité
"Guerrier", qui supporte les propriétés spécifiques aux
habitants-guerriers. On parle de lien "Père-Fils". Ici, le
père est constitué par l'entité Habitant et le fils est
constitué par l'entité Guerrier.

18
 Habitant Fonction
Exerce
nom Nom_fonction
date_naissance 1,1 0,n âge_mini
adresse âge_maxi

Guerrier participation
nombre_décorations 0,n nombre_de_casques

1,n

Bataille
numéro_rang
durée de la bataille
date de la bataille

L'entité Guerrier est dite spécialisée, alors que l'entité

Habitant est dite générique. On parle de
généralisation/spécialisation - ou de sous-typage - lorsque
qu'on introduit cette représentation dans un modèle.

On parle d'héritage pour indiquer que l'entité Guerrier hérite

de toutes les propriétés de l'entité Habitant : un guerrier a une
date de naissance, une adresse etc.

EXERCICE
Situation : Dans l’entreprise X, les factures font l’objet
d’un règlement par chèque bancaire ou par carte bleue.
Un règlement est caractérisé par un numéro séquentiel
(attribuée par l’ordinateur) et une date.
Pour les règlements par chèque, on souhaite mémoriser
le nom de la banque et le numéro de chèque.

19
 Pour les règlements par carte bancaire, on souhaite conserver :
le numéro de carte, le nom de la banque et la date d’expiration
de la carte.
Ici on a une entité générique : REGLEMENT et deux entités
spécialisées : CHEQUE et CARTE. On dit aussi que CARTE
et CHEQUE sont deux sous-types de l’entité REGLEMENT
car elles n’ont pas d’identifiants propres.
La généralisation/spécialisation permet
de mettre en évidence les propriétés
spécifiques de chaque sous-type
d’entités.
1) Représentation dans le MCD :
1,1
1,n REGLEMENT
FACTURE N°Reglement
N°Facture PORTER SUR
DateRèglement
DateFacture NomBanque

Attention
un sous-type
d’entités ne
comporte pas CHEQUE CARTE
d’identifiants. Les N° Chèque N°Carte
DateExpiration
sous types héritent
de l’identifiant de
l’entité générique

2) Traduction des sous-types d’entités au niveau relationnel

On peut traduire les sous-types d’entités de 3 manières

différentes, toutes équivalentes

20
 a) Une seule relation
Les propriétés des entités spécialisées sont regroupées
dans les entités spécialisées et on crée un attribut
permettant de différencier l’occurrence
Exemple :
REGLEMENT(N°Reglement, DateRèglement, NomBanque,TypeReglement N°
Chèque, N°Carte, DateExpiration) Attribut ajouté

Cette solution est utilisable lorsque les entités

spécialisées ne comportent pas beaucoup de propriétés.
b) Transformation de l’entité générique et des entités
spécialisées en relations

Les relations « spécialisées » héritent de la clé primaire de la relation

« générique »
REGLEMENT(N°Reglement, DateRèglement, NomBanque)
CHEQUE(N°Reglement, N°Cheque)
CARTE(N°Reglement, N°Carte, DateExpiration)

Cette solution est à privilégier lorsque chaque entité

comporte beaucoup de propriétés.

c) Transformation des entités spécialisées en relation

Dans cette situation, on ne traduit pas l’entité
générique en relation Ce qui donne :
CHEQUE(N°Reglement, DateRèglement, NomBanque , N°Cheque)
CARTE(N°Reglement, DateRèglement, NomBanque ,N°Carte,
DateExpiration)

21
 Cette solution permet de faire
l’économie d’une relation. En
revanche, elle entraîne
redondance car les propriétés de
l’entité générique sont reprises
V/ Généralisation/spécialisation des associations

Comme pour les entités, on peut avoir une association

générique et des associations spécialisées (sous-type)

Situation :
Une entreprise fabrique des objets artisanaux qui peuvent
être standard ou personnalisé. Chaque produit est identifié
par un numéro et un prix d’achat. Les produits
personnalisés comportent par ailleurs un taux horaire
variable correspondant au travail de personnalisation.
Une commande est caractérisé par un N° de commande et
une date.
Les quantités de produit commandés concernent les deux
types de produits. Pour les produits personnalisés, il faut
également facturer la durée d’internvention.
Complétez le MCD suivant :
PRODUIT
CodeProduit
LibelléProduit
PrixUnitaire

22
 PRODUIT_STANDARD PRODUIT_PERSONNALISE

Taux_horaire

1,n 1,n

FACTURER_PP
FACTURER_PS
Duree

Concerner
QtesComm

1,n

COMMANDE

N°Commande
DateCommande

Complétez le schéma relationnel découlant de ce MCD :

Les sous-types d’association se traduisent de la même manière que les sous-

types d’entités (selon 3 possibilités voir III/ A/ - 2)
Dans cet exemple nous traduirons chaque association en relation
COMMANDE(N°Commande, DateCommande)
PRODUIT(CodeProduit, LibelleProduit,PrixUnitaire)
PRODUIT_STANDARD(CodeProduit)
PRODUIT_PERSONNALISE(CodeProduit, TauxHoraire)
CONCERNER(#N°Commande, #CodeProduit, QtesCom)
Les sous-types d’association
FACTURER_PS(#N°Commande,#CodeProduit) ont la même clé primaire
FACTURER_PP(#N°Commande, #CodeProduit, Duree) que l’association générique

IV Associations d'associations

23
 E1 R E2
E1 R E2 1
1

E1 E1
R E3 R
E3
2 R
2
E2 1
E2

Prenons le cas suivant. Les pêcheurs du village sont autorisés à

pêcher différentes espèces de poissons dans différentes zones de
pêche, en mer ou en rivière. Mais un pecheur n’est autorisé à
pecher qu’1 espece dans une zone donnée.

Zones
code_zone

0,n

Espèces_poisson
nom_espèce est-autorisé_à_pécher
0,n
prix_au_kilo
mer_ou_riviere

1,n
Pêcheur
numéro_bateau

24
PB : Ce schéma n'exprime pas la règle de gestion qui dit que
dans une zone, il n'y a qu'un seul pêcheur autorisé à pêcher une
espèce donnée.
Normalement un pecheur est autorisé a pêcher (une espéce dans
une zone)
Merise étendue autorise les "associations d'associations", dont voici
un exemple de formalisme parmi ceux qui existent.
Zones
Pécher
Espèces_poisson code_zone
nom_espèce 0,n 0,n
prix_au_kilo
0,1
mer_ou_riviere
Est_autorisé

1,n

Pêcheur
numéro_bateau

Cette représentation exprime clairement qu'un couple Espèce

de poisson / Zone de pêche détermine LE pêcheur autorisé.
On parle aussi d’agrégation ou de pseudo entité
Exercice :
Situation : Dans l’entreprise X, les représentants vendent des
produits dans différentes régions. Mais un produit pour une
région donnée n’est vendu que par un seul représentant.

Le MCD suivant a été établi :

REPRESENTANT
N° Rep
NomRep

1,n 1,n 1,n PRODUIT

VENDRE N° Produit
LibelleProduit
PrixProduit

25
 REGION
N° Region
LibRegion

Extrait du MLD relationnel :

VENDRE(#N°Rep, #N°Région, #N°Produit)
Extrait de la table Vendre :
N°REP N°Regio N°Produi
n t
1 5 1
1 3 2
2 5 2
2 3 3
3 3 1
3 5 3

Questions :
2) D’après les règles de gestion de l’énoncé, est-il possible
que le représentant 3 vende le produit 2 ds la région 5 ?

NON car un produit pour une région donnée ne peut être

vendu que par un seul représentant, or le couple
region/Produit (5,2) est assuré par le représentant 2
2) D’après le MCD, le représentant 3 vende le produit 2
dans la région 5 ?
Rien ne s’y oppose conceptuellement parlant étant donné
car l’identifiant de l’association vendre (N°Rep, N°Region,
N° produit) est égal à 3 5 2, ce qui est différent de 2 5 2

CONCLUSION :
Le MCD actuel ne traduit pas correctement la réalité, il faut recourir à la structure
« agrégation » qui permet d’associer une entité à un couple d’entités:

26
 REPRESENTANT
N° Rep
NomRep

1,n

VENDRE
1,1

1,n 1,n PRODUIT L’association

REGION N° Produit Couvrir est agrégée
N° Region COUVRIR et constitue une
LibelleProduit
LibRegion PrixProduit pseudo-entité

MLD relationnel :
REPRESENTANT(N°Rep, NomRep)
REGION(N°Region, LibRegion)
PRODUIT(N°Produit, LibelleProduit, PrixProduit)
COUVRIR(#N°Region,#N°Produit, #N°Rep)

L’association qui relie REPRESENTANT à la pseudo entité est de type hiérarchique

(cardinalité 1,1). Il est tout à fait possible que l’association soit non hiérarchique.
Exemple : On considère cette fois ci qu’un produit pour une région donnée, s’il est vendu,
peut l’être vendu par plusieurs représentants :

Le MCD devient alors

REPRESENTANT
N° Rep
NomRep

1,n

VENDRE

0,n

1,n 1,n PRODUIT

REGION N° Produit
N° Region COUVRIR
LibelleProduit
LibRegion PrixProduit

Complétez le schéma relationnel :

REPRESENTANT(N°Rep, NomRep)
REGION(N°Region, LibRegion)
PRODUIT(N°Produit, LibelleProduit, PrixProduit)
Ajout d’une
relation

27
 COUVRIR(#N°Region,#N°Produit)
VENDRE(#N°Rep, #N°Region,#N°Produit)

Exercices Contraintes inter-relations

En "Merise classique", on dispose de très peu d'outils pour

représenter certaines contraintes d'intégrité, notamment entre les
associations. Soit l’exemple suivant qui illustre le taillement et
l'achat de produits( menhirs)(N°, carriére, hauteur, poids) par les
habitants. Ceux qui achetent ne taillent pas.

Menhir
numéro_menhir
carrière_menhir
hauteur_menhir
1,1 poids_menhir
0,1

taillé par acheté par

0,n 0,n
Habitant
nom
date_naissance
adresse

Sur ce schéma, rien n'indique par exemple que ceux qui achètent des
menhirs ne sont pas ceux qui les taillent.

En Merise étendu, on dispose d'une palette d'outils pour représenter

ces liens d'exclusion ou d'inclusion entre les associations. Ci-dessous,
on voit apparaître une contrainte d'exclusion entre les association

28
taillé_par et acheté_par, exprimant la règle de gestion qui dit que les
tailleur de menhirs ne peuvent en être les acquéreurs. Il existe
d'autres types de représentation de contraintes entre les associations,
dont notamment les contraintes d'inclusion ou d'égalité.
Menhir
numéro_menhir
carrière_menhir
hauteur_menhir
1,1 poids_menhir
0,1

taillé par acheté par

X

0,n 0,n
Habitant
nom
date_naissance
adresse

Note : dans AMC Designor ces contraintes n'apparaissent pas à la génération du modèle
physique, bien qu'elles puissent être exprimées dans certains SGBD, sous la forme de
"triggers", ordres SQL spécifiques spécifiant des liens particuliers entre les données.

29
30
1-Comment modéliser les notions de temps (date, heure)
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.
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, 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 :

31
  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.

2- Comment indiquer qu’une entité participe

conditionnellement à plusieurs relations ? exemples

 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 occurrences 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.

Les types de contraintes recensées et les plus communément 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

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.

3- Qu'est-ce qu'une contrainte de stabilité ?

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

4- Comment exprimer une relation réflexive ?

33
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 « réflexive » 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:

4- 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. MCD ?

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

5- Comment exprimer que des caractéristiques ne

puissent être pertinentes que pour certaines
occurrences d'une entité ?
Dans un modèle où l'on souhaiterait désigner sous une même entité un
ensemble d'occurrences, on peut se retrouver bloqué face au fait que certaines
caractéristiques (nécessaires à certaines occurrences) ne puissent pas être
renseignées pour toutes les occurrences.
Exemple, si l'on considère la gestion d'un parc informatique : les
caractéristiques d'un écran (diagonale, nbHz) ne correspondent pas aux
caracté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 occurrences
de l'entité.
Dans l’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

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

6- 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,

36
- 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).

MCD :

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

7- Quels sont les différents héritages possibles ?

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

37
son projet.

1/ XT (exclusion et totalité) = 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 exclusion :
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 (PK_EMPLOYE) dans l'entité

employé sachant qu'un employé travaille dans un et un seul service.

Toute méthode, à l’instar des êtres vivants, évolue. Elle est soumise à une double influence,
exogène (celle des autres méthodes) et endogène (celle de ses propres utilisateurs). Merise
n’échappe pas à cette règle :

38
Etendre pour étendre, ça n’a pas de sens. L’extension coûte. Il faut changer les logiciels,
changer les dossiers, changer les habitudes...
Toute extension doit donc apporter un plus aux utilisateurs de la méthode (les maîtres
d’œuvre), les utilisateurs du logiciel (les maîtres d’ouvrage) y retrouvant leur compte en
récupérant des spécifications plus précises, des erreurs évitées … donc un outil mieux fini.
Il y a eu plusieurs extensions à Merise 0, certaines majeures, d’autres mineures. Toutes ne
sont pas utilisées partout. Il convient donc de s’assurer du public à qui sont destinés les
schémas avant de les employer.
expression des contraintes
héritage et agrégation
personnalisation d’associations
association d’associations,
Les schémas de données, pour bien construits qu’ils soient, ont un défaut majeur : ils
autorisent l’entrée de données aberrantes, erronées, ou, plus exactement, ils n’attirent pas
l’attention du concepteur sur un certain nombre de contrôles à effectuer lors de la mise à jour
de ces données.
Certes, on peut définir ces contrôles dans le dossier. Il est cependant préférable de les faire
figurer directement
La seconde catégorie de contraintes que l’on doit exprimer sur un schéma regroupe ce que
l’on appelle des contraintes procédurales. Il s’agit de noter l’existence de procédures vérifiées
par plusieurs occurrences et/ou par des valeurs prises par des occurrences les unes par rapport
aux autres.
ex : la somme des achats simultanés d’une personne ne peut être inférieure à 50 euros.
Ensembles de valeurs d’occurrences
COMPLEMENTS : QQ PARTICULARITES SUR
LE PASSAGE AU MODÈLE RELATIONNEL1

I – REGLES DE BASE
Pour obtenir un modèle relationnel à partir du MEA, il faut appliquer les règles suivantes :

 les pseudo-entités (attribut spatio-temporel), n'apparaissent plus dans le modèle relationnel (DATE par
exemple)

 les entités deviennent des relations dont la clef primaire de la relation est l'identifiant de l'entité.

 les associations deviennent des relations dont la clef primaire est la concaténation des n identifiants des
entités concourant à la définition de l'association

 une CIF (lien1,1 entre 2 entités) se traduit par la migration en clef étrangère dans la relation source de
l'identifiant cible du lien d'appartenance

 un lien de type (0,1) et (1,n) se traduit par une association entre les entités impliquées.
1
APIEP janvier 99(D’après Ch. Gaubert-Macon, MC. Moreau et D. Weinling )

39
Dans la plupart des ateliers de génies logiciels (AMC,
Windesign ) le type de lien 0,1 est traduit par une
migration de clef avec une clef étrangère pouvant avoir
une valeur nulle.

Les clefs primaires et étrangères de chaque relation

composant le modèle logique doivent être mises en
évidence (par exemple souligner les clefs primaires et
ajouter après les clefs étrangères le symbole #). La
légende choisie doit être exposée.

II – ENTITE FORTE – ENTITE FAIBLE

SECTEUR REGION
Rel_1
N°secteur (R) 1,1 1,n N°région

Dans le cas d'une entité ayant un identifiant relatif, celle-ci devient une relation dont la clef primaire est
composée de l'identifiant de l'entité but du lien d’appartenance et de l'identifiant relatif

SECTEUR REGION
PK_SECTEUR PK_REGION
N°RÉGION N°RÉGION
Rel_1
N°SECTEUR

Soient les tables

REGION (N°Région,….)
SECTEUR (N°Region#, N°secteur, …)

III- TRADUCTION DE LA SPECIALISATION/GENERALISATIO

D’ENTITE
3.1- Rappels
Rappel sur la spécialisation d’entité :
La spécialisation d’entité consiste à décomposer une entité dite générique en entités spécialisées pour
prendre en compte des caractéristiques particulières à certaines occurrences d’entités :
 Propriétés spécifiques

40
 Liens vers des associations spécifiques.

Rappel sur la généralisation d’entités :

La généralisation permet de regrouper au sein d’une entité générique des entités qui présentent des
propriétés communes.

Rappel sur les contraintes entre entités spécialisées :

Deux contraintes de base (la couverture et la disjonction) sont combinées pour exprimer trois types de
contraintes sémantiques qui seront représentées graphiquement :
 Exclusion
 Totalité
 Partition

Dans le cas des entités spécialisées, il existe 4 cas

possibles de génération de modèle relationnel que
nous allons détailler en prenant l’exemple de
spécialisation ci-dessous.
PERSONNE
N°Personne
nom
datenaiss

Etudiant Enseignant
niveau grade

3.2- Modèle relationnel

Le passage au modèle relationnel va se faire en

cherchant à appliquer des règles qui génèrent le moins
de relations et le moins de contraintes possibles.

On va chercher à représenter sous forme de relations

les objets du MEA ayant le plus de propriétés

41
spécifiques, et sous forme de vues les objets du MEA
n’ayant pas ou peu de propriétés spécifiques.

Une vue est le résultat d’une requête sur une ou

plusieurs relations. Une vue ne contient pas
d’informations, c’est une photographie permettant de
sélectionner les tuples correspondant à un (ou
plusieurs) critères de sélection.
Ces règles vont dépendre du type de contrainte exprimée entre les entités spécialisées.

3.2.1- Traduction de chaque entité par une relation.

Chaque entité est traduite par une relation. Toutes les relations ont la même clef primaire
qui correspond à l’identifiant de l’entité générique.
Ceci permet de traduire correctement le modèle de données mais ce mode de traduction entraîne la
multiplication des tables qui induit des contraintes de mise à jour, notamment lors de l’ajout de n-uplets.

L’emploi de ce type de traduction est adapté pour un schéma avec une contrainte d’exclusion entre sous-
types.

L’héritage des propriétés du sur-type peut être implanté de deux façons :

1) En réalisant dynamiquement une jointure sur la clef primaire.
2) En répétant dans les relations de sous-type les attributs de l’entité générique

1ère solution :En réalisant dynamiquement une jointure sur la clef primaire.

Les tables correspondant au sur-type et aux sous-types sont générées, chacune ayant pour
origine l'identifiant du sur type en tant que clé primaire.

42
 PERSONNE
PK_PERSONNE
N°PERSONNE
NOM
DATENAISS

Her_1 Her_1
ETUDIANT ENSEIGNANT
PK_ETUDIANT PK_ENSEIGNANT
N°PERSONNE N°PERSONNE
NIVEAU GRADE

Ainsi pour obtenir le nom d’un étudiant, il faudra réaliser une jointure sur le N°personne entre les
tables étudiant et personne.

Remarque : Pour les tables ayant pour origine les sous types, la clé primaire est composée de la clé
étrangère ayant pour référence la table ayant pour origine le sur-type.

43
2ème solution : En répétant dans les relations de sous-type les attributs de l’entité générique

Dans ce cas toutes les propriétés du sur-type sont dupliquées complètement dans chaque sous-type. Cette
option aura pour effet de dupliquer tous les attributs de la table mère dans les tables filles.

PERSONNE
PK_PERSONNE
N°PERSONNE
NOM
DATENAISS

Her_1 Her_1
ETUDIANT ENSEIGNANT
PK_ETUDIANT PK_ENSEIGNANT
N°PERSONNE N°PERSONNE
NIVEAU GRADE
NOM NOM
DATENAISS DATENAISS

3.2.2- Traduction uniquement des entités spécialisées

Seules les entités spécialisées sont traduites sous forme de tables qui héritent des propriétés de l’entité
générique.

La table générique sera obtenue par une vue.

Ceci a l’avantage de générer moins de relations et donc d’obtenir moins de contraintes lors des mises à
jour.

En revanche ce type de représentation n’est valable que si il y a une contrainte de partition ou totalité entre
les entités spécialisées.

L’exclusion permettant que certaines entités génériques ne soient pas représentées par les sous types
n’admet pas cette possibilité.

44
 3.2.3- Traduction de l’entité générique seulement
L’entité générique devient une relation porteuse des attributs génériques et de l’ensemble des attributs de
spécialisation.

Pour certains n-uplets, des attributs auront un sens, pour d’autres pas, et ce en fonction du sous-types
d’appartenance : c’est le phénomène d’expropriation de propriété, qui oblige au niveau de la table
générique d’autoriser la valeur nulle pour certains attributs.

L’intérêt de ce mode de traduction est la diminution du nombre de tables. Mais il y a un inconvénient

majeur qui est la perte sémantique. Seule l’application de vues permet d’obtenir les tuples correspondant à
une entité spécialisée.

PERSONNE
Ex : select nom,datenaiss,niveau
PK_PERSONNE From personne
N°PERSONNE Where niveau <> 0 ;
NOM
DATENAISS
permet d’obtenir les étudiants.
NIVEAU
GRADE

IV -TRADUCTION DES CONTRAINTES ENTRE ENTITÉS

SPÉCIALISÉES
La plupart de ces contraintes se traduisent au niveau du modèle physique par l’implantation de triggers.

Un trigger ou déclencheur est un programme défini par le programmeur qui s’exécute lors
d’un événement survenant sur une table d’une base de données. Un trigger est associé à
une seule table.
L’événement est lié à une demande de mise à jour sur la table (ajout d’un n-uplet, modification ou
suppression).

45
 CLIENTS
N°CLIENT
nom
adresse

XT

CLIENT_PROSPECT
CLIENT_PORTEFEUILLE
code prospection

Supposons que le modèle relationnel représentant ce MEA soit déduit des règles : on ne garde que les
entités spécialisées.

CLIENT_PROSPECT(code client, nom client, adresse client, code prospection)

CLIENT_PORTEFEUILLE(code client, nom client, adresse client)

Exemple de triggers attaché à l’opération d’ajout d’un tuple dans la table

CLIENT_PROSPECT (SGBD Oracle 7) permettant de vérifier la disjonction entre sous-types :

CREATE TRIGGER client_prospect_INSERT

AFTER INSERT ON client_prospect
FOR EACH ROW
DECLARE
check_val integer;
BEGIN
-- Disjonction
SELECT COUNT(*) INTO check_val FROM client_portefeuille
WHERE
client_portefeuille.code_client = :new.code_client;
IF check_val != 0
THEN
Erreur

RETURN;
END IF;
END;
/

Ce trigger permet de vérifier que l’insertion d’un

nouveau CLIENT_PROSPECT est cohérente.

46
En effet la représentation du modèle entité association
indique une partition entre les sous-type
CLIENT_PROSPECT et CLIENT_PORTEFEUILLE
un client ne peut donc appartenir aux deux sous-types.

On va regarder qu’il n’existe pas de tuple dans la

relation CLIENT_PORTEFEUILLE portant ce
numéro avant d’insérer le tuple dans la relation
CLIENT_PROSPECT.

Si il existe un tuple, une erreur sera générée et l’ajout

ne sera pas possible.

47
48