Conception Et Adapation BD Merise2

BTS Services informatiques aux organisations – 2e année
Spécialité Solutions logicielles et applications métiers
CONCEPTION ET ADAPTATION
D’UNE BASE DE DONNÉES
COURS
BTS Services informatiques aux organisations – 2e année
José Gil – Élisabeth Martins Da Silva
CONCEPTION
ET ADAPTATION
D’UNE BASE DE DONNÉES
COURS
Retrouvez la liste de nos formations sur www.cned.fr
Pour plus d’informations, appelez le 05 49 49 94 94
Du lundi au vendredi, 8 h 30-18 h.
Coût d’une communication ordinaire.
*82955TGPA0013* www.cned.fr
CONNECTÉ À VOTRE AVENIR
Les cours du CNED sont strictement réservés à l’usage privé de leurs destinataires et ne sont pas destinés à une utilisation collective.
Les personnes qui s’en serviraient pour d’autres usages, qui en feraient une reproduction intégrale ou partielle, une traduction sans
le consentement du CNED, s’exposeraient à des poursuites judiciaires et aux sanctions pénales prévues par le Code de la propriété
intellectuelle. Les reproductions par reprographie de livres et de périodiques protégés contenues dans cet ouvrage sont effectuées
par le CNED avec l’autorisation du Centre français d’exploitation du droit de copie (20, rue des Grands Augustins, 75006 Paris).
© CNED 2013
Sommaire
Conseils généraux 5
Séquence 1 : Le modèle relationnel 7
Séquence 2 : Le modèle conceptuel de données 15
Séquence 3 : Extensions sous Merise/2 71
Séquence 4 : MCD ou Diagramme de classe ? 111
Séquence 5 : La programmation du SGBDR 139
Séquence 6 : Autocorrection 171
8 2955 TG PA 00
Conseils généraux
Présentation générale du module
Ce module intervient tout au long de la deuxième année, dans le cadre du cours
2955 "Conception et adaptation d'une base de données". Le référentiel lui réserve en
moyenne 6 heures de cours/TP par semaine sur 12 semaines, ce qui représente un vo-
lume total de 72 heures.
Le référentiel est en partie basé sur la répétition, la consolidation des notions et l'ap-
prentissage "en escalier". Ne soyez donc pas surpris si vous retrouvez des notions déjà
abordées : c'est l'occasion pour vous soit de les consolider, soit de mieux les comprendre
si vous éprouvez des fragilités.
Dans des modules précédents, vous avez eu l'occasion d'apprendre à interpréter un
schéma conceptuel de données et à le faire évoluer suivant les besoins du cahier des
charges. Ce module va plus loin et a pour finalité de vous apprendre à construire de
bout en bout un schéma conceptuel de données complet. Vous allez aussi découvrir de
nouvelles notions à travers l'insertion de contraintes et les possibilités de les program-
mer directement dans un SGBDR.
Ce module concerne uniquement l'option SLAM. À l'examen, il va intervenir à différents
niveaux sur l'ensemble des épreuves informatiques. À l'épreuve écrite, vous devrez
entre autres travailler sur un modèle de données, voire en créer un, et lors des épreuves
pratiques vous aurez à présenter une application qui exploite une base de données.
L'utilisation d'un logiciel de conception est aussi incontournable.
Connaissances nécessaires pour aborder ce module

Il est préférable d'avoir réalisé tous les modules prévus pour le premier et second se-
mestre de la première année avant d'aborder celui-ci. Cependant les prérequis incon- Page 5
tournables sont :
–– le module 2943 "Exploitation des données" ;
–– le module 2949 "Exploitation d'un schéma de données".
Organisation du module
Ce module se présente en trois fascicules. Le fascicule de "cours", le fascicule de "tra-
vaux pratiques" et enfin le fascicule de "devoirs".
Le fascicule de cours contient toutes les notions fondamentales exigées pour l'examen.
Vous devez donc l'étudier en détail et contrôler, par les exercices, que les connaissances
sont bien acquises.
Le fascicule de travaux pratiques comporte deux TP :
–– le premier TP porte sur l’évolution d'une base de données en fonction d'un
cahier des charges précis. C'est aussi l'occasion de manipuler WinDesign. Ce TP
est à réaliser à l'is-sue de la séquence 4 ;
–– le second TP porte sur la prise en compte de contraintes métiers et la concep-
tion de programmes dans un environnement de bases de données. Ce TP est
l’occasion de mettre en pratique les connaissances acquises en programmation
du SGBD. Ce TP est à réaliser à l’issue de la séquence 5.
Vous avez 2 devoirs à renvoyer :
–– le premier devoir est à réaliser à l'issue de la séquence 4 : il porte sur l'élaboration
de schémas conceptuels de données en vue de la création d'une base de données ;
8 2955 TG PA 00
–– le second devoir est à réaliser à l’issue de la séquence 5 : il porte sur la pro-
grammation du SGBD.
Organisation du fascicule
Ce fascicule s'articule en 6 séquences :
Séquence 1 : Le modèle relationnel
Vous allez mieux comprendre les règles de création et de validation d'un schéma con-
ceptuel de données.
Séquence 2 : Le modèle conceptuel de données
Cette séquence est une reprise des notions abordées dans le module 2949 "Exploitation
d'un schéma de données" mais de façon nettement plus formelle et plus approfondie.
C'est donc l'occasion de consolider des connaissances tout en allant plus loin. Dans cette
séquence et la suivante, vous connaissez déjà certains exercices mais traités de façon
différente.
Séquence 3 : Extensions sous Merise/2
Vous allez aborder les extensions de Merise/2 qui vous sont pour la plupart inconnues et
qui sont fondamentales dans ce cours.
Séquence 4 : MCD ou Diagramme de Classes ?
Cette séquence montre que le diagramme de classes peut aussi être utilisé pour modéli-
ser les données en vue de la création d'une base de données.
Séquence 5 : La programmation du SGBDR
Dans cette dernière séquence vous allez découvrir comment écrire des programmes du
Conseils généraux côté du serveur de gestion de base de données.
Séquence 6 : Autocorrection
Page 6
Vous trouverez ici la correction des exercices de ce fascicule.
Logiciels utilisés
Dans ce cours et dans le fascicule de TP qui est associé à ce cours, vous allez manipuler
essentiellement un SGBDR et un outil de conception que vous connaissez déjà. La confi-
guration et l'installation de ces logiciels ne seront plus expliquées car elles sont déjà pré-
sentées en détail dans des modules précédents.
WinDesign
WinDesign est un logiciel de modélisation. Si ce n'est déjà fait, le logiciel doit être récu-
péré à l'adresse suivante : http://www.win-design.com/fr/NEW_dl_WD.htm
Vous récupèrerez la version la plus récente et vous l'installerez en prenant les options par
défaut. Ce cours a été fait avec la version 10.04 mais une version plus récente ne doit pas
poser de problèmes. Vous avez reçu individuellement par mail le code d'enregistrement
pour que vous puissiez utiliser le logiciel dans le cadre de l'enseignement, durant l'année
scolaire. Ce code ne devra pas être diffusé.
PostgreSQL
SGBDR est gratuit et téléchargeable sur le site officiel (http://www.postgresql.fr/accueil).
Ce cours a utilisé la version 9.1 mais vous pouvez a priori récupérer la version la plus
récente. Ce SGBDR est l'un des plus connus et appréciés dans le monde gratuit : il est très
puissant et multiplateforme.
Bon courage !
8 2955 TG PA 00
Séquence 1
Le modèle relationnel
Cette première séquence présente le modèle relationnel qui définit les
règles pour organiser et optimiser les données. Le modèle conceptuel de
données est basé sur les règles du modèle relationnel.
u Prérequis
Cette séquence pourrait être abordée sans connaissance préalable, mais il est préférable
d'avoir étudié le module 2943 "Exploitation des données" et le module 2949 "Exploita-
tion d'un schéma de données" pour mieux comprendre son intérêt.
u Capacités attendues en fin de séquence

Avoir compris les règles du modèle relationnel qui sont fondamentales dans la construc-
tion du modèle conceptuel de données.
u Contenu
1. Dépendance fonctionnelle ................................................................................... 8
2. Attribut .................................................................................................................... 9
3. Relation ................................................................................................................... 9
4. Comment obtenir le modèle relationnel ? ....................................................... 12 Page 7
Synthèse ................................................................................ 13
8 2955 TG PA 00
Le modèle relationnel permet d'organiser et de représenter les données de façon indé-
pendante des traitements.
Il est basé sur le concept des dépendances fonctionnelles (notion qui va être détaillée
juste après). Il obéit à un ensemble de règles bien précises.
1. Dépendance fonctionnelle
Avant de présenter une définition formelle, il faut bien comprendre qu'une dépendance
fonctionnelle représente un lien entre 2 attributs. Elle permet de mettre en relief le fait
qu'un attribut dépend d'un autre. Du coup, en repérant les différentes dépendances
fonctionnelles qui existent entre l'ensemble des attributs à modéliser, il est possible de
mieux gérer leur organisation. Cette notion est donc fondamentale.
Définition
Soient 2 attributs A et B, on dit que B dépend fonctionnellement de A (noté A à B) si, à
chaque valeur de A ne correspond qu’une seule valeur de B.
n°insee à nom
car il n’y a pas 2 personnes ayant le même n°insee (à chaque n°insee correspond un
seul nom)
par contre :
nom à n°insee
Séquence 1 car il peut y avoir des homonymes
Le modèle Par habitude, dépendance fonctionnelle est aussi notée DF.

relationnel
DF élémentaire
Page 8 Soient 2 attributs A et B, la DF (A à B) est élémentaire s’il n’existe pas C contenu dans
A tel que (C à B).
idCommande, idArticle à nomArticle non élémentaire
avec les 2 premières informations, on obtient la dernière

mais on n’a pas besoin des 2 informations. L'idArticle suffit pour obtenir le nomAr-
ticle :
idArticle à nomArticle élémentaire
par contre, dans l’exemple suivant, les 2 sont nécessaires :

idCommande, idArticle à qteCommandée élémentaire
Donc une DF élémentaire ne suppose pas forcément un seul attribut à gauche.
DF directe
Soient 2 attributs A et B, la DF (A à B) est directe s’il n’existe pas C tel que (A à C) et (C à B).
nous possédons, entre autres, les attributs suivants :
idClient, nomClient, idCommande
que penser de la DF suivante ?
idCommande à nomClient non directe
la première information donne bien la seconde,
mais un intermédiaire paraît logique :
idCommande à idClient
directes
idClient à nomClient
8 2955 TG PA 00
Exercice 1
Voici les attributs disponibles :
idClient, nomClient, adrClient, idArticle, nomArticle, prixArticle,
idCommande, dateCommande, qteCommandée
Pour les propositions suivantes, précisez s'il y a une DF, si elle est élémentaire, si elle
est directe (mettez une croix dans les cases concernées).
DF élém. directe
nomClient à adrClient
idClient à adrClient
idCommande, idClient à qteCommandée
idCommande, idArticle à prixArticle
idCommande, idArticle à qteCommandée
idCommande à dateCommande
idCommande à nomClient
idCommande à nomArticle
2. Attribut
Séquence 1
L'attribut est le plus petit élément d'information qui a un sens indépendamment des
autres. Le modèle
relationnel
Exemples d'attributs :
idCommande Page 9
dateCommande
idClient
nomClient
...
Un attribut est nommé, il contient une information élémentaire, qui est typée (entier,
réel, texte, booléen, date…) et qui peut se voir attribuer une longueur.
3. Relation
Une relation est très officiellement un sous-ensemble du produit cartésien d'une liste
d'attributs.
Avant tout cela signifie qu'une relation peut contenir 1 à plusieurs attributs. Nous ver-
rons par la suite comment regrouper ces attributs en relations. Ensuite, puisque chaque
attribut peut avoir plusieurs contenus possibles, il existe un grand nombre de combinai-
sons possibles (produit cartésien) en utilisant toutes les valeurs des attributs. La relation
ne représente pas toutes les possibilités de combinaisons mais juste un sous-ensemble.
Imaginons les attributs suivants avec plusieurs valeurs possibles :
nomClient : Dupont, Bernard, Durand
villeClient : Nice, Marseille
En réunissant ces 2 attributs, on obtient la liste de combinaisons suivante :
Dupont – Nice
Dupont – Marseille
Bernard – Nice

8 2955 TG PA 00
Bernard – Marseille
Durand – Nice
Durand – Marseille
En revanche, seules les informations en couleur sont vraies et ce sont celles qui se-
ront mémorisées dans la relation.
L'exemple a présenté les valeurs que l'on peut retrouver dans une relation. Cependant,
l'écriture d'une relation présente dans un premier temps la liste des attributs qui la com-
pose. Une relation possède aussi un nom. Voici quelques exemples de relations :
Client (idClient, nomClient, adrClient)
Commande (idCommande, dateCommande, idClient)
Article (idArticle, nomArticle)
LigneCommande (idCommande, idArticle, qteCommandée)
Vous commencez à voir que ces relations regroupent les attributs qui ont un lien entre
eux. Peut-être que la notion de dépendance fonctionnelle va bientôt resservir…
Représentation
Une relation peut être représentée de 2 façons.
Représentation en compréhension
Cette représentation permet de voir juste la liste des attributs.
Client (idClient, nomClient, ville)
Séquence 1
Représentation en extension
Le modèle Cette représentation permet de voir aussi le contenu des attributs.
relationnel
idClient nomClient ville
TUPLE (ligne) :
Page 10 45 DUPONT Nice une occurrence
62 BERNARD Marseille donc un client
78 DURAND Marseille
... ... ...
ATTRIBUT (colonne)
Degré et cardinalité
Le degré d'une relation représente son nombre d'attributs.
Degré = 3
Le degré de cette relation est 3 (3 attributs)
La cardinalité d'une relation représente son nombre de tuples.
Cardinalité = 20
Si la relation Client contient 20 tuples, donc 20 clients, sa cardinalité est de 20.
Clé primaire
La clé d'une relation est l'attribut ou l'ensemble d'attributs qui permet de distinguer
entre eux tous les tuples de la relation.
Pour la relation :
Les clés candidates sont :
idClient
idClient, nomClient
8 2955 TG PA 00
idClient, ville
idClient, nomClient, ville
En effet, toutes ces combinaisons permettent d'obtenir un client unique.
La clé primaire d'une relation est la clé candidate possédant le moins d'attributs possible.
Dans l'exemple précédent, la clé primaire est :
idClient
En effet, l'idClient est suffisant pour identifier de façon unique un client.
La clé primaire est soit soulignée dans une relation (très ancienne notation, mais à connaître)
soit précisée sous la relation (notation officielle). Vous devez connaître les 2 notations.
Ancienne notation :
Nouvelle notation officielle :
idClient : clé primaire
Clé étrangère
Une clé étrangère est un attribut d'une relation qui a un rôle de clé primaire unique dans
une autre relation. Du coup, la clé étrangère permet de faire le lien entre les relations et
ainsi de récupérer facilement des informations d'une relation à une autre.
Il existe aussi 2 notations pour la clé étrangère (avec un # dans l'ancienne notation, ou
précisé sous la relation dans la notation officielle) :
Ancienne notation :
Client (idClient, nomClient, ville) Séquence 1
Commande (idCommande, dateCommande, idClient#)
Le modèle
Nouvelle notation officielle : relationnel
idClient : clé primaire Page 11
Commande (idCommande, dateCommande, idClient)
idCommande : clé primaire
idClient : clé étrangère en référence à idClient de Client
Formes normales
Il est temps de reparler de dépendance fonctionnelle.
La construction des relations ne doit pas se faire "au hasard", vous vous en doutez. Le
but est de trouver l'organisation la plus optimale possible. Pour cela, il suffit de respec-
ter certaines règles.
Voici la règle (ou plutôt le groupe de règles) à respecter :
Une relation doit posséder une clé primaire et des attributs qui doivent être
en DF élémentaire et directe avec la clé primaire.
La forme obtenue en suivant ces règles s'appelle la 3e forme normale. On dit que les
relations sont en 3NF (l'inversion vient de l'anglais…).
S'il y a une 3e forme normale, c'est que peut-être il existe les 2 premières formes. C'est le
cas. Alors pour le plaisir, voyons les 3 définitions officielles des formes normales.
Première forme normale (1NF) :
La relation possède une clé primaire.
Commande(idCommande, idArticle, qteCommandée, date, idClient, nomClient)
8 2955 TG PA 00
Il y a bien une clé primaire (mais date n'est pas en DF élémentaire avec la clé car idCom-
mande est suffisant pour donner la date de la commande, et nomClient n'est pas en DF
directe avec la clé car il y a un intermédiaire : idClient)
Deuxième forme normale (2NF) :
La relation est en 1NF et les attributs sont en DF élémentaires avec la clé.
Commande (idCommande, date, idClient, nomClient)
Il y a bien une clé primaire et les DF sont élémentaires (mais nomClient n'est pas en DF
directe avec la clé car il y a un intermédiaire : idClient)
Troisième forme normale (3NF) :
La relation est en 2NF et les attributs sont en DF directes avec la clé.
Commande (idCommande, date, idClient#)
Il y a bien une clé primaire et les DF sont élémentaires et directes.
Le but est maintenant de faire en sorte que toutes les relations qui seront construites
soient en 3NF.
Exercice 2
Écrire les relations en 3NF qui vous paraissent logiques à partir de la liste d'attributs
suivante :
Séquence 1
idEtudiant, nomEtudiant, idClasse, idMatière, nomClasse, nomMatière,
Le modèle coefMatière, annéeInscription.
relationnel
Vous connaissez aussi les règles de gestion suivantes :
Page 12 –– chaque matière peut avoir un coefficient différent suivant les classes ;
–– d'une année sur l'autre, un étudiant peut s'inscrire dans des classes dif-
férentes, éventuellement dans la même classe mais jamais dans plusieurs
classes à la fois : l'année d'inscription est mémorisée.
Avez-vous souffert pour faire cet exercice ? Alors imaginez si vous aviez à organiser une
cinquantaine d'attributs…
4. Comment obtenir le modèle relationnel ?

Lorsqu'un ensemble de données est à traiter, le but est donc d'organiser ces données
en relations normalisées (en 3NF). Ces relations pourront alors permettre de créer par
exemple une base de données relationnelle, exploitée par un programme.
Vous avez compris que, suivant la complexité du sujet, trouver directement les relations
risque de rapidement tourner au casse-tête.
Il est donc préférable de passer par la construction d'un schéma suivant un modèle pré-
cis. L'aspect visuel du schéma permettra de simplifier la construction des relations cor-
respondantes.
Vous allez donc apprendre, dans la séquence suivante, à élaborer des schémas basés sur
le modèle conceptuel des données de la méthode Merise. Ce modèle est aussi appelé
Modèle Entités Associations. Si vous avez étudié les modules précédents, vous savez déjà
pourquoi.
8 2955 TG PA 00
Synthèse
Dépendance Fonctionnelle :
Soient 2 attributs A et B, on dit que B dépend fonctionnellement de A (A à B) si, à
chaque valeur de A ne correspond qu’une seule valeur de B.
DF élémentaire :
Soient 2 attributs A et B, la DF (A à B) est élémentaire s’il n’existe pas C contenu
dans A tel que (C à B).
DF directe :
Soient 2 attributs A et B, la DF (A à B) est directe s’il n’existe pas C tel que (A à C)
et (C à B).
Attribut :
L'attribut est le plus petit élément d'information qui a un sens indépendamment
des autres.
Relation :
Une relation est un sous-ensemble du produit cartésien d'une liste d'attributs.
Représentation en compréhension d'une relation : nomRelation (liste des attributs) Séquence 1
Représentation en extension d'une relation : cette représentation est sous forme de Le modèle
tableau (avec la liste des valeurs). relationnel
Clé d'une relation :

Page 13
La clé d'une relation est l'attribut ou l'ensemble d'attributs qui permet de distin-
guer entre eux tous les tuples de la relation.
Clé primaire d'une relation :
La clé primaire d'une relation est la clé candidate possédant le moins d'attributs
possible.
Notation : soulignée (ancienne notation) ou en le mentionnant explicitement après
la relation (notation officielle).
Clé étrangère :
Une clé étrangère est un attribut d'une relation qui a un rôle de clé primaire unique
dans une autre relation.
Notation : avec # (ancienne notation) ou en le mentionnant explicitement après la
relation (notation officielle).
Exemple :
Ancienne notation :
CLIENT (idClient, nom, adresse, tel)
FACTURE (idFacture, dateFacture, total, idClient#)
8 2955 TG PA 00
Nouvelle notation officielle :
FACTURE (idFacture, dateFacture, total, idClient)
idFacture : clé primaire
idClient : clé étrangère en référence à idClient de CLIENT
3e forme normale :
Une relation doit posséder une clé primaire et des attributs qui doivent être en DF
élémentaire et directe avec la clé primaire.
Séquence 1
Le modèle
relationnel
Page 14
8 2955 TG PA 00
Séquence 2
Le modèle conceptuel
de données
Cette séquence reprend toutes les notions fondamentales d’un modèle
conceptuel de données, mais cette fois avec le but de savoir construire un
schéma de bout en bout. Vous retrouverez toutes les notions déjà étudiées
dans le module 2949 "Exploitation d’un schéma de données", à travers
une présentation plus formelle et plus complète. Attention, même si vous
pensez maîtriser les notions abordées, ne faites pas l’impasse sur cette sé-
quence qui va vous apporter les connaissances nécessaires pour modéliser
correctement les données.
u Prérequis
Avoir acquis les connaissances de la séquence 1 pour mieux comprendre le principe.

Savoir construire intégralement un schéma conceptuel de données d’une certaine com-
plexité.
u Contenu Page 15
1. Introduction .......................................................................................................... 16
2. Outils du MCD ...................................................................................................... 16
3. Noms des entités et associations ...................................................................... 18
4. DF entre entités .................................................................................................... 19
5. Cardinalités ........................................................................................................... 19
6. Héritage ................................................................................................................. 19
7. Intégrité fonctionnelle ........................................................................................ 24
8. Lien identifiant ..................................................................................................... 24
9. Agrégation ............................................................................................................ 29
10. Petit mémento du MCD....................................................................................... 31
11. Exercices récapitulatifs de premier niveau ...................................................... 52
12. Exercices récapitulatifs de second niveau ........................................................ 60
Synthèse ................................................................................ 70
8 2955 TG PA 00 8 2955 TP PA 00
1. Introduction
Qu’est-ce que le MCD ?

Le MCD (Modèle Conceptuel de Données) est un des modèles de la méthode Merise, qui
fixe un ensemble de règles pour organiser les données de façon visuelle.
Le MCD permet de schématiser les dépendances fonctionnelles. Il respecte les règles du
modèle relationnel en ajoutant des règles de représentation graphique.
Qu’est-ce que le SCD ?

En suivant les règles de ce modèle, vous allez apprendre à construire des SCD (Schémas
Conceptuels de Données) qui répondent aux attentes de contextes précis.
Attention, par abus de langage, on utilise souvent le terme MCD pour parler de SCD.
C’est-à-dire que vous verrez parfois "dessinez le MCD correspondant au domaine présen-
té" alors que ce n’est pas le MCD que vous devez dessiner mais le SCD : ce n’est pas vous
qui avez inventé le Modèle mais vous êtes un simple utilisateur qui dessine des Schémas
basés sur le Modèle ! Cependant cette erreur est courante : ce n’est pas très grave et il
faudra vous y habituer. Mais il est important que vous ayez bien compris la différence.
Intérêt du MCD
Le MCD permet de réaliser des schémas qui sont beaucoup plus faciles à construire que
l’écriture directe de relations. Ces schémas sont aussi beaucoup plus faciles à lire.
Séquence 2
Une fois le SCD construit, la traduction en relations est directe.
Le modèle
conceptuel de Vocabulaire du MCD
données
Le vocabulaire est normalement le même que pour le modèle relationnel, avec bien sûr
Page 16 des termes spécifiques au MCD qui vont venir s’ajouter.
Apprenez à utiliser aussi le terme identifiant pour parler de clé primaire. Quelle est
la nuance ? Normalement aucune : le terme "clé primaire" est la traduction directe du
terme anglais "primary key" et le terme "identifiant" est purement français. Certains
ont cependant inséré une nuance entre les 2 termes et les positionnent à des niveaux
différents : "identifiant" au niveau conceptuel et "clé primaire" au niveau de la base de
données. Tout ceci est assez secondaire : il faut juste connaître les 2 termes.
2. Outils du MCD
Le MCD n’utilise en fait que 2 outils graphiques : les entités et les associations. Tous les
autres éléments du MCD sont des dérivés de ces 2 éléments.
Entité
Elle est la représentation graphique d’une relation en 3NF dont la clé primaire n’est
composée que d’un seul attribut élémentaire.
représentation : exemple :
! NOM ENTITE ARTICLE
idArticle
attribut1 nomArticle
… prix
attributN

8 2955 TG PA 00
Une entité possède un nom placé dans sa partie haute. Ce nom sera celui de la relation
qui en découle.
Une entité possède des attributs placés dans sa partie basse au rythme d’un attribut par
ligne.
Dans une entité, l’identifiant est unique : il est souligné et placé en tête de la liste des
attributs.
Une entité contient obligatoirement un identifiant suivi de 0 à plusieurs attributs
simples. On dit qu’une entité est "vide" quand elle ne possède que l’identifiant.
Les éventuelles clés étrangères ne sont pas écrites directement dans l’entité. Nous
verrons plus loin comment elles sont symbolisées (pour visualiser le lien qu’elles repré-
sentent avec d’autres entités).
Association
Elle est la représentation graphique d’une relation en 3NF dont la clé primaire est com-
posée d’au moins 2 attributs élémentaires.
représentation :
NOM ASSOCIATION
NOM ENTITE NOM ENTITE
attribut1
… … …
attributN
Séquence 2
exemple :
Le modèle
ARTICLE conceptuel de
COMMANDE LIGNE_COMMANDE données
idArticle
idCommande qteCommandée nomArticle
date Page 17
prix
Une association possède un nom placé dans sa partie haute. Ce nom sera celui de la
relation qui en découle.
Une association possède éventuellement des attributs placés dans sa partie basse au
rythme d’un attribut par ligne.
Dans une association, l’identifiant (composé forcément de plusieurs attributs) n’est pas
explicitement marqué : les liens directs qui entourent l’association permettent d’aller
récupérer les identifiants des entités concernées. L’ensemble de ces identifiants repré-
sente l’identifiant de l’association. Il y en a au moins 2.
De la remarque précédente, il découle qu’une association possède au moins 2 liens
directs qui l’entourent.
Une association contient 0 à plusieurs attributs simples. Une association "vide" est une
association qui ne contient aucun attribut : on l’appelle aussi CIM (Contrainte d’intégrité
multivaluée).
Les éventuelles clés étrangères ne sont pas écrites directement dans l’association. Nous
verrons plus loin comment elles sont symbolisées (pour visualiser le lien qu’elles repré-
sentent avec d’autres entités, mais qui ne sera pas symbolisé par un lien direct).
8 2955 TG PA 00
3. Noms des entités et associations
Noms des entités

Une entité est classiquement la représentation du réel : personne, lieu, chose… Du coup
le nom d’une entité paraît naturel : il suffit de donner le nom qui correspond à l’objet
décrit ("objet" dans le sens : représentation du réel).
Exemples : facture, client, article…
Noms des associations

À ce niveau là c’est un peu plus complexe et il existe plusieurs approches.
L’approche la plus courante depuis quelques années et que vous trouverez dans la plu-
part des sujets, c’est l’utilisation d’un verbe : le verbe symbolise le lien entre 2 entités.
Voici un exemple :
ARTICLE
COMMANDE CONTIENT
idArticle
date prix
En nommant l’association "CONTIENT", on constitue une phrase entre les 2 entités :

"une commande CONTIENT des articles"
Séquence 2 Là, vous pouvez vous poser la question : que se passe-t-il si la lecture se fait dans l’autre
sens ? On peut imaginer qu’il suffit de prendre la forme passive :
Le modèle
conceptuel de "un article EST CONTENU dans des commandes"
données
Cependant, il arrive que la forme passive ne marche pas. En fait, au début de la création
de la méthode, 2 verbes (appelés "rôles") devaient être placés : un par branche.
Page 18
ARTICLE
COMMANDE LIGNE_COMMANDE
contient est contenu idArticle
date
prix
Cette écriture a été rapidement abandonnée et remplacée par un seul verbe comme nom
d’association. Sous Win’Design, il est toujours possible d’ajouter ces rôles.
Personnellement, cette solution me gène car n’oublions pas que l’association va ensuite
se traduire en une relation dans le modèle relationnel, puis une table dans une base de
données. Et là, on peut se poser la question du côté "parlant" du nom de la table corres-
pondante. Que pensez-vous d’une table nommée "CONTIENT" par rapport à une table
nommée "LIGNE_COMMANDE" ?
Ceci dit, ayez l’esprit large et acceptez toutes les approches. L’important est que vous
soyez capable de vous adapter à n’importe quelle variante dans les formalismes utilisés.
Cependant, quand vous aurez la possibilité de choisir une solution plutôt qu’une autre,
faites le choix qui vous convient le mieux, et de préférence suivez toujours la même
méthode pour traiter l’ensemble d’un sujet.
8 2955 TG PA 00
4. DF entre entités
Vous avez vu dans le modèle relationnel qu’une clé étrangère est un attribut d’une
relation, qui a le rôle de clé primaire dans une autre relation. Deux relations sont alors
liées par une dépendance fonctionnelle entre les 2 identifiants. Puisqu’il y a un lien, ça
donne envie de le symboliser par une association dans le MCD. Partons d’un exemple :
une commande ne correspond qu’à un seul client.
CLIENT
COMMANDE CORRESPOND
idClient
idCommande nomClient
date adresse
Cette fois, que vous mettiez un verbe ou un nom parlant, cela ne change pas grand-
chose : dans le cas d’une dépendance fonctionnelle entre 2 entités, l’association ne sera
pas traduite en relation mais en clé étrangère dans la relation Commande.
Du coup, pour que la représentation de la dépendance fonctionnelle entre les 2 entités
soit plus visuelle, une autre représentation est admise (et me semble être nettement la
meilleure) :
CLIENT
COMMANDE
idClient
idCommande
nomClient
date Séquence 2
adresse
Le modèle
Cette représentation évite de donner un nom à l’association (puisque de toute façon conceptuel de
ce nom ne sert à rien) et montre visuellement le lien et le sens du lien (cependant, la données
flèche n’est pas obligatoire : soit elle représente pour vous une aide et dans ce cas il
faut la mettre, soit vous avez du mal avec sa position et dans ce cas je vous conseille de Page 19
l’oublier). Win’Design permet cette représentation en précisant qu’il y a une dépendance
fonctionnelle entre les entités (le rond et la flèche apparaissent).
Encore une fois, le but est de savoir lire et manipuler les 2 représentations, cependant
je ne saurais trop vous conseiller d’utiliser la seconde notation qui vous aidera à mieux
visualiser les dépendances fonctionnelles entre entités.
Pour ajouter des couches dans les nuances que vous pouvez trouver dans les schémas, il
existe 2 variantes dans la seconde notation : certains ajoutent "DF" dans le petit cercle
(pour une raison évidente : c’est une Dépendance Fonctionnelle), d’autres ajoutent "CIF"
dans le petit cercle : CIF signifie Contrainte d’Intégrité Fonctionnelle. Cela repré-
sente un lien très fort entre les 2 entités puisque l’on parle carrément de "contrainte
d’intégrité". En quelque sorte, il y a une perte "d’intégrité" si la première entité ne
donne pas la seconde. La nuance entre DF et CIF est assez légère, cependant on y revien-
dra de façon plus précise juste après, en abordant la notion de cardinalités.
5. Cardinalités
Les cardinalités permettent d’exprimer le nombre minimum et maximum d’occurrences
d’une entité par rapport à une autre (liées par une association).
8 2955 TG PA 00
Une commande contient Un article peut se
au moins un article, mais retrouver dans 0 à
peut en contenir plusieurs. plusieurs commandes.
ARTICLE
1,n 0,n idArticle
date prix
1,1 Un commande ne
concerne qu'un client
CLIENT (minimum et maximum.)
1,n
idClient
nomClient
adresse
Si l'enregistrement d'un client se fait au moment où il

passe sa première commande, alors un client a passé au
minimum une commande, cependant il peut ensuite en
avoir passé plusieurs.
Séquence 2
Le modèle
Comment se lit une cardinalité ?
conceptuel de L’exemple précédent explique bien la signification des différentes cardinalités. De façon
données
plus formelle, voici comment se lit une cardinalité :
Page 20 ! ENTITE1 ENTITE2

n,m ASSOCIATION
… …
…
"à une occurrence de l’entité1 correspond minimum n, maximum m occurrences de

l’entité2"
Donc la lecture part de l’entité qui se trouve du côté de la cardinalité.
Quelles sont les cardinalités possibles ?

minimum : 0 ou 1 ou plus rarement une autre valeur précise, mais jamais n.
maximum : 1 ou n ou plus rarement une autre valeur précise, mais jamais 0.
Exercice 1
Voici un ensemble de relations : dessinez le SCD correspondant.
CORPS_CELESTE (idCorps, nom, distance, idSysteme#)
SYSTEME (idSysteme, nom)
MATIERE (idMatiere, nom)
COMPOSITION_CORPS (idCorps#, idMatiere#, quantité)
8 2955 TG PA 00
6. Héritage
Il arrive que certaines entités comportent des attributs qui ne seront remplis que sous
certaines conditions. En fait, l’entité comporte des "sous-types" qui ont chacun leurs
propres caractéristiques.
Voyons un exemple pour que ce soit plus clair :
Il faut gérer le personnel qui travaille dans un établissement scolaire. Pour l’ensemble du
personnel, il faut mémoriser nom, prénom, adresse, téléphone, email.
Pour les enseignants, il faut mémoriser le nombre d’heures d’enseignement par semaine et les
matières enseignées. Pour les administratifs, il faut mémoriser le service de rattachement et
la date d’affectation à ce service.
On pourrait imaginer le schéma suivant :
0 minimum car un
administratif n'a
PERSONNEL pas de matière.
idPersonnel
nom MATIERE
prenom 0,n MATIERE_PROF 0,n
idMatiere
adresse
nom
tel
email
nbHeures
0 minimum car un professeur n'a pas Séquence 2
dateAffectation de service : cela donnera une clé
nbHeures et 0,1 étrangère qui sera parfois vide. Le modèle
conceptuel de
dateAffectation ne données
seront pas toujours SERVICE
remplis. 0,n idService Page 21
nom
Pour éviter ces attributs et clés étrangères parfois vides, on pourrait imaginer une autre
solution qui sépare totalement les administratifs des enseignants :
! ADMINISTRATIF PROFESSEUR
idAdministratif idProfesseur MATIERE
nom nom 1,n MATIERE_PROF 0,n
idMatiere
prenom prenom
nom
adresse adresse
tel tel
email email Il n'y a plus d'attributs qui
dateAffectation nbHeures peuvent rester vides, mais certains
attributs sont identiques. DeDepplus,
lus,
1,1
SERVICE si on a envie de faire
faireddes
es
0,n recherches sur tout le personnel, il
idService faut passer par les 22eentités.
ntités.
nom
Finalement, les 2 solutions proposées ne sont pas satisfaisantes. Le but serait de pouvoir
gérer le personnel dans son intégralité, mais éviter les attributs qui peuvent rester vides.
8 2955 TG PA 00
La solution : garder l’entité PERSONNEL qui contiendra tout ce qui est commun à tout le
personnel, et créer 2 sous-types spécifiques à chaque type de personnel. Voici la repré-
sentation graphique :
PERSONNEL
idPersonnel
nom Ces flèches, sans cardinalité,
prenom symbolisent l'héritage :
adresse ADMINISTRATIF et PROFESSEUR sont
tel des entités qui héritent de PERSONNEL .
email
ADMINISTRATIF PROFESSEUR MATIERE

1,n MATIERE_PROF 0,n
dateAffectation nbHeures idMatiere
nom
1,1
SERVICE
0,n
idService
nom
Séquence 2
Voyons ce que cela donne au niveau relationnel :
Le modèle PERSONNEL (idPersonnel, nom, prenom, adresse, tel, email)
conceptuel de ADMINISTRATIF (idPersonnel#, dateAffectation, idService#)
données
PROFESSEUR (idPersonnel#, nbHeures)
SERVICE (idService, nom)
Page 22 MATIERE (idMatiere, nom)
MATIERE_PROF (idPersonnel#, idMatiere#)
Remarquez que dans ADMINISTRATIF et dans PROFESSEUR, la clé primaire est identique
à celle de PERSONNEL excepté qu’elle est aussi étrangère. En effet, un ADMINISTRATIF
est aussi un PERSONNEL et va donc récupérer certaines de ses informations directement
dans PERSONNEL. Donc, si Alain DUPOND est un administratif et que son id vaut 4, on
retrouvera cet id 4 aussi bien dans PERSONNEL que dans ADMINISTRATIF : les informa-
tions concernant Alain DUPOND seront récupérées dans PERSONNEL avec l’id 4, et les
informations concernant DUPOND mais spécifiques au fait qu’il est personnel adminis-
tratif, seront récupérées dans ADMINISTRATIF avec aussi l’id 4.
L’ancienne notation des relations ne fait pas assez bien ressortir le sens des liens. En
effet, la clé primaire et étrangère idPersonnel dans MATIERE_PROF ne met pas en évi-
dence le fait que le lien se fait uniquement avec l’entité PROFESSEUR et non avec l’entité
PERSONNEL.
Voici les mêmes relations avec la nouvelle notation officielle. Vous allez comprendre la
différence.
PERSONNEL (idPersonnel, nom, prenom, adresse, tel, email)
idPersonnel : clé primaire
ADMINISTRATIF (idPersonnel, dateAffectation, idService)
idPersonnel : clé étrangère en réf. à idPersonnel de PERSONNEL
idService : clé étrangère en réf. à idService de SERVICE
8 2955 TG PA 00
PROFESSEUR (idPersonnel, nbHeures)
idPersonnel : clé étrangère en réf. à idPersonnel de PERSONNEL
SERVICE (idService, nom)
idService : clé primaire On voit bien que l'idPerson-
MATIERE (idMatiere, nom) nel est issu de PROFESSEUR.
idMatiere : clé primaire
MATIERE_PROF (idPersonnel, idMatiere)
idPersonnel, idMatiere : clé primaire
idPersonnel: clé étrangère en réf. à idPersonnel de PROFESSEUR
idMatiere : clé étrangère en réf. à idMatiere de MATIERE
Quand faut-il utiliser l’héritage ?

Logiquement, comme vous l’avez vu, l’héritage semble être nécessaire lorsque des sous-
types apparaissent, donc quand des attributs sont génériques (communs à tous les types)
et d’autres sont spécifiques à chaque type.
Dans la réalité, l’héritage a tout de même un inconvénient : il génère par la suite des
tables supplémentaires qui peuvent alourdir la base de données.
Du coup, il faut faire des choix stratégiques au moment du passage à la base de données.
Attention, ces choix ne se font pas au niveau conceptuel, mais uniquement au moment
du passage au niveau relationnel. Pour faire ces choix, soit le modèle présenté est gardé
en l’état, soit d’autres solutions sont prises, suivant la situation.
Migration vers l’entité mère
Si les entités filles contiennent peu d’informations et ne possèdent aucun lien (associations Séquence 2
reliées à elles), alors il est préférable de les supprimer et de migrer leurs attributs vers
Le modèle
l’entité mère. Certains attributs resteront parfois vides mais il n’y aura qu’une table à gérer. conceptuel de
données
Migration vers les entités filles
Si au contraire l’entité mère possède peu d’attributs et aucun lien (associations reliées Page 23
à elle) et si les entités filles ont une activité plus importante (des attributs spécifiques
et/ou des liens), alors il est préférable de migrer les attributs de l’entité mère vers les
entités filles. Attention, cette solution ne peut être choisie que dans le cas où il n’est pas
nécessaire de réaliser de traitements qui regroupent les entités filles.
Un peu de vocabulaire
Pour finir cette partie sur l’héritage, voyons un peu de vocabulaire. Le but n’est pas de
l’apprendre par cœur mais de s’y habituer. C’est une première présentation d’un vocabu-
laire que de toute façon vous allez souvent rencontrer dans les sujets.
PERSONNEL Entité mère

Sur-type
idPersonnel
Entité générique
nom
prenom
adresse
Héritage
tel
Dérivation
email
Hiérarchie
Sous-typage
Entité fille
ADMINISTRATIF PROFESSEUR Sous-type
dateAffectation nbHeures Entité spécifique
8 2955 TG PA 00
Exercice 2
Voici un ensemble de relations : dessinez le SCD correspondant.
MESSAGE (idMessage, titre, contenu, date, idExpediteur)
idMessage : clé primaire
idExpediteur : clé étrangère en réf. à idPersonne de PERSONNE
MESSAGE_UNIQUE (idMessage, date_reponse, idDestinataire)
idMessage : clé étrangère en réf. à idMessage de MESSAGE
idDestinataire : clé étrangère en réf. à idPersonne de PERSONNE
DIFFUSION (idMessage)
idMessage : clé étrangère en réf. à idMessage de MESSAGE
PERSONNE (idPersonne, nom)
idPersonne : clé primaire
DESTINATAIRE (idDiffusion, idDestinataire, date_reponse)
idDiffusion, idDestinataire : clé primaire
idDiffusion : clé étrangère en réf. à idMessage de DIFFUSION
idDestinataire : clé étrangère en réf. à idPersonne de PERSONNE
7. Intégrité fonctionnelle
Une intégrité fonctionnelle traduit une dépendance forte entre des objets. Les SGBDR
Séquence 2
gèrent généralement les intégrités fonctionnelles automatiquement dès qu’il y a des clés
Le modèle étrangères qui sont définies.
conceptuel de
Reprenons l’exemple suivant :
données
Un article ne peut pas être
Page 24 supprimé s'il est rattaché à
des commandes .
ARTICLE
1,n 0,n idArticle
date prix
1,1
Il est possible de demander au

CLIENT SGBDR, lors de la suppression d'une
Une commande ne 1,n
idClient commande, que tous les tuples
peut pas être créée si correspondants dans
nomClient
elle n'est pas LIGNE_COMMANDE soient
adresse
rattachée à un client. automatiquement supprimés .
8. Lien identifiant
Vous allez étudier une notion qui n’existe normalement que depuis Merise/2 (étudié
dans la séquence suivante) mais qui apporte une simplification intéressante au niveau de
la construction des schémas. Voilà pourquoi cette notion est présentée dès maintenant.
8 2955 TG PA 00
Il arrive que des entités temporelles ou de type "numéro" soient nécessaires pour gérer
correctement certaines situations. Voyons tout cela à travers 2 exemples.
1er cas : le lien identifiant pour supprimer les entités numéros
es hôtels possèdent des chambres. Un numéro de chambre peut se retrouver dans plusieurs
L
hôtels. Pour chaque chambre, il est nécessaire de connaître le type (simple ou double).
La première solution serait de créer une entité CHAMBRE dont l’id ne correspond pas au
numéro réel de la chambre (car l’id doit être unique et un numéro de chambre ne l’est
pas, d’un hôtel à un autre) :
! CHAMBRE HOTEL
1,1 1,n
idChambre idHotel
numChambre nom
type adresse
Au niveau des tables, cela donnerait ceci :

HOTEL
idHotel nom adresse
1 Beausoleil Marseille
Séquence 2
2 Le Rivage Nice
… … … Le modèle
conceptuel de
données
CHAMBRE
Page 25
idChambre numChambre type idHotel
1 1 Simple 1
2 2 Double 1
3 3 Double 1
4 4 Simple 1
5 1 Simple 2
6 2 Simple 2
7 3 Double 2 La chambre d’id 6
est la chambre qui
8 4 Simple 2 porte le numéro
9 5 Double 2 2 de l’hôtel "Le
10 6 Double 2 Rivage".
… … … …
Pourquoi l’id ne correspond pas au numéro réel de la chambre ? Vous voyez bien ici
que la chambre de numéro 2 existe dans l’hôtel "Le Rivage" mais aussi dans l’hôtel
"Beausoleil". Un identifiant devant être unique, on est obligé de gérer un id qui soit
différent du numéro réel de la chambre.
Donc idChambre sera un numéro interne automatiquement créé et incrémenté, alors
que numChambre sera une information réelle de la chambre (son numéro dans l’hôtel)
au même titre que le type de la chambre.
8 2955 TG PA 00
Cette solution marche mais a pour inconvénient d’utiliser un id supplémentaire alors
qu’il serait tout à fait possible de s’en passer. Comment ?
La seconde solution consiste à utiliser le numéro réel de chambre associé à l’identifiant
de l’hôtel pour repérer une chambre précise. Cela pousse à créer une entité "vide" (ne
contenant qu’un identifiant) juste pour obtenir un numéro.
HOTEL
NUMCHAMBRE CHAMBRE
1,n 0,n idHotel
numChambre type nom
adresse
L’entité NUMCHAMBRE n’a de raison d’être que pour générer un numéro qui sert à la
construction de l’association CHAMBRE.
Au niveau relationnel l’entité NUMCHAMBRE disparaît et il ne reste plus que :
HOTEL (idHotel, nom, adresse)

idHotel : clé primaire
CHAMBRE (idHotel, numChambre, type)
idHotel, numChambre : clé primaire
idHotel : clé étrangère en réf. à idHotel de HOTEL
Cette solution est meilleure que la précédente car le repérage d’une chambre est plus
concret : il se fait en fonction de l’hôtel et du numéro réel de la chambre.
Séquence 2
Au niveau des tables, cela donnerait ceci :
Le modèle HOTEL
conceptuel de
données idHotel nom adresse
1 Beausoleil Marseille
Page 26 2 Le Rivage Nice
… … …
CHAMBRE
idHotel numChambre type
1 1 Simple
1 2 Double
1 3 Double
1 4 Simple
2 1 Simple
2 2 Simple
2 3 Double La chambre portant
le numéro 2 de
2 4 Simple l'hôtel "Le Rivage"
2 5 Double est une chambre
2 6 Double "simple".
… … …
Cette fois, la chambre est repérée (identifiée) par la combinaison de 2 informations :
l’idHotel + le numChambre qui est le numéro réel de la chambre dans l’hôtel. On n’a
plus besoin d’ajouter un id.
8 2955 TG PA 00
Cette solution permet d’avoir une colonne en moins et en plus d’avoir un identifiant
"parlant" (représentant le réel).
Mais peut-être que faire de CHAMBRE une association vous gène un peu et la présence
de cette entité NUMCHAMBRE qui disparaît ensuite vous gène aussi. Cette représenta-
tion un peu "lourde" a aussi gêné les concepteurs de la méthode qui du coup ont mis en
place une représentation plus légère et plus visuelle :
idChambre a disparu. CHAMBRE HOTEL
numChambre (le numéro (1,1) 1,n
réel de la chambre) est en numChambre idHotel
identifiant. type nom
adresse
Les parenthèses autour du 1,1 signale que la clé étrangère sera aussi
une clé primaire (donc fera partie de l'identifiant de CHAMBRE) .
Qu’est ce que cela change au niveau relationnel par rapport à la représentation précé-
dente ? Rien. Cette représentation n’est là que pour alléger l’aspect visuel du SCD. Au
niveau relationnel, on retrouve les 2 relations avec, pour CHAMBRE, 2 attributs en clé
primaire.
Cette représentation, qui existe uniquement depuis la version 2 de Merise (appelée
Merise/2 ou extensions Merise) permet tout simplement d’éliminer toutes les entités de
type numéro qui existaient dans l’ancienne version.
Vocabulaire Séquence 2
Cette notion s’appelle le lien identifiant. Voyons le vocabulaire plus en détail : Le modèle
conceptuel de
Entité faible données
Entité dépendante
CHAMBRE HOTEL Page 27
(1,1) 1,n
numChambre idHotel
type nom
adresse
CHAMBRE est une "entité faible" (ou "dépendante") car elle n’a pas de vie toute seule :
elle dépend directement de l’entité HOTEL puisque son identifiant est, entre autres,
constitué de l’identifiant de l’entité HOTEL.
numChambre est un "identifiant relatif" car il n’est pas seul à identifier CHAMBRE.
Le lien qui relie CHAMBRE à HOTEL est un "lien identifiant" car il permet de complé-
ter l’identification de CHAMBRE. Comme il y a une contrainte forte entre CHAMBRE et
HOTEL, on l’appelle aussi "contrainte d’identification".
Autres notations
La représentation sous forme de CIF est conseillée car plus visuelle, mais pas du tout
obligatoire. Si vous avez choisi de représenter les CIF sous forme d’associations normales,
vous pouvez le faire aussi pour les liens identifiants.
La représentation sous forme de (1,1) donc avec les parenthèses, n’est pas unique. Il
existe 2 autres représentations qu’il faut aussi connaître :
8 2955 TG PA 00
Cette représentation est
CHAMBRE HOTEL
relativement proche de 1,1(R) 1,n
la précédente. numChambre idHotel
type nom
adresse
Cette représentation est

CHAMBRE HOTEL
censée être plus "claire" 1,1 1,n
car la seconde clé appa- numChambre idHotel
raît directement dans #idHotel# nom
l'entité. Elle est cepen- type adresse
dant plus "lourde".
Encore une fois, à vous de prendre la notation que vous préférez. Mais vous devez savoir
toutes les lire.
2e cas : le lien identifiant pour supprimer les entités temporelles

De la même façon que le lien identifiant permet de supprimer les entités numéros, les
entités temporelles peuvent aussi, dans la plupart des cas, être éliminées.
Les locations de films doivent être mémorisées. Une location concerne un film à une date
précise : il faut aussi enregistrer la date de retour.
Séquence 2
Un film + une date de location permet de déterminer précisément une location : location
Le modèle
conceptuel de
doit donc naturellement être gérée sous forme d’association entre FILM et DATE.
données
FILM
LOCATION DATE
Page 28 idFilm 0,n 0,n
titre dateRetour dateLocation
Cependant, l’entité DATE n’est là que pour la création de l’association LOCATION et dis-
paraît au niveau du modèle relationnel (car il n’y a aucune raison de garder une relation
DATE qui mémoriserait toutes les dates du calendrier !).
FILM (idFilm, titre)
idFilm : clé primaire
LOCATION (idFilm, dateLocation, dateRetour)
idFilm, dateLocation : clé primaire
idFilm : clé étrangère en réf. à idFilm de FILM
Ici encore, le lien identifiant va permettre de simplifier la représentation sans rien chan-
ger au sens : les relations qui en découleront seront les mêmes que les relations précisées
juste au-dessus.
FILM 1,n LOCATION

(1,1)
idFilm dateLocation
titre dateRetour
Liens identifiants en cascade

Vous aurez parfois à gérer des liens identifiants vers des entités qui possèdent déjà un
lien identifiant. C’est tout à fait possible.
8 2955 TG PA 00
PLANETE SYSTEME GALAXIE
(1,1) 1,n (1,1) 1,n
idPlanete idSysteme idGalaxie
nom nom nom
Ce schéma modélise les planètes, chaque planète se trouvant dans un système précis, lui
même se trouvant dans une galaxie précise (par exemple la planète terre se trouve dans
le système solaire qui se trouve dans la voie lactée).
Ce qui est intéressant, c’est de voir ce qui se passe au niveau relationnel. Vous remarque-
rez que pour PLANETE, la clé étrangère est double pour bien faire le lien avec SYSTEME
(qui possède une clé primaire double).
GALAXIE(idGalaxie, nom)
idGalaxie : clé primaire
SYSTEME(idGalaxie, idSysteme, nom)
idGalaxie, idSysteme : clé primaire
idGalaxie : clé étrangère en réf. à idGalaxie de GALAXIE
PLANETE(idGalaxie, idSysteme, idPlanete, nom)
idGalaxie, idSysteme, idPlanete : clé primaire
idGalaxie, idSysteme : clé étrangère en réf. à
(idGalaxie, idSysteme) de SYSTEME
Liens identifiants multiples

En suivant la même logique, on peut imaginer des liens identifiants multiples, donc plu-
sieurs liens identifiants partant de la même entité afin de récupérer plusieurs clés. Séquence 2
Certains vont même encore plus loin et suppriment certaines associations en ne mettant
Le modèle
aucune clé primaire dans l’entité faible et en ne gérant que des liens identifiants : cette conceptuel de
solution n’est syntaxiquement pas fausse mais je ne la trouve pas du tout visuelle. données
Les liens identifiants sont très intéressants lorsqu’ils sont correctement utilisés. Cependant,
ne cherchez pas à en mettre partout. Page 29
9. Agrégation
Comme le lien identifiant, l’agrégation est une notion introduite depuis Merise/2 (étudié
dans la séquence suivante). Cependant, elle apporte une simplification dans la construc-
tion des schémas : voilà pourquoi elle est abordée dès maintenant.
Il arrive parfois que pour créer une association, il soit nécessaire de récupérer les iden-
tifiants d’une autre association. Dit autrement, il existe des associations qui servent à
associer non pas 2 entités (ou +) mais une entité et une association. Dans la représen-
tation classique, la nouvelle association devait reprendre les liens directs de l’ancienne
association, en ajoutant le lien vers la nouvelle entité. Voyons un exemple :
Des vêtements sont vendus dans des tailles différentes avec un prix qui varie suivant la
taille. Une facture peut concerner plusieurs vêtements : il faut bien sûr connaître à chaque
fois la taille.
Dans un premier temps, pour mémoriser le prix d’un vêtement, 2 informations sont
nécessaires : le vêtement et sa taille.
8 2955 TG PA 00
VETEMENT VETEMENT_TAILLE TAILLE
0,n 0,n
idVetement prix idTaille
description libellé
Maintenant, pour gérer la facture, il faut mémoriser les vêtements achetés sans oublier
de préciser à chaque fois la taille. Une ligne de facture est cette fois une association entre
FACTURE et VETEMENT_TAILLE.
Dans Merise, il est normalement interdit de faire une association sur une autre associa-
tion, du coup il faut reprendre tous les liens de l’ancienne association :

0,n 0,n
0,n 0,n
LIGNE_FACTURE
FACTURE 0,n
quantité
idFacture
date
Les relations qui ne concernent que la partie facture sont les suivantes :
Séquence 2
FACTURE (idFacture, date)
Le modèle LIGNE_FACTURE (idFacture, idVetement, idTaille, quantité)
conceptuel de idFacture, idVetement, idTaille : clé primaire
données idFacture : clé étrangère en réf. à idFacture de FACTURE
idVetement : clé étrangère en réf. à idVetement de VETEMENT
idTaille : clé étrangère en réf. à idTaille de TAILLE
Page 30
Avec les nouvelles règles de Merise/2, une association qui porte sur une autre association
est acceptée. Ce lien entre 2 associations est appelé une agrégation.
Voici la représentation la plus officielle :

0,n 0,n
0,n
FACTURE LIGNE_FACTURE
0,n
idFacture quantité
date
Cette représentation montre que l’association LIGNE_FACTURE est entre FACTURE et le

groupe formé par VETEMENT, TAILLE et VETEMENT_TAILLE. Il est donc bien question
d’une association entre FACTURE et l’association VETEMENT_TAILLE.
8 2955 TG PA 00
Cette fois, les relations qui en découlent sont un peu différentes et font ressortir ce lien
qui n’apparaissait pas dans l’ancienne représentation :
LIGNE_FACTURE (idFacture, idVetement, idTaille, quantité)
idFacture, idVetement, idTaille : clé primaire
idFacture : clé étrangère en réf. à idFacture de FACTURE
idVetement, idTaille : clé étrangère en réf. à (idVetement, idTaille)
de VETEMENT_TAILLE
Jusque là, Merise ne symbolisait pas les liens sur les clés étrangères multiples. Avec l’agré-
gation, ce point est résolu.
Pour représenter l’agrégation, suivant les sites et les livres, plusieurs variantes sont pré-
sentées. L’une d’elles me paraît moins lourde que la représentation officielle. C’est celle
que j’ai tendance à utiliser. À vous de choisir la représentation que vous préférez mais
encore une fois, vous devez savoir tout lire.

0,n 0,n
0,n
0,n Séquence 2
idFacture quantité
date Le modèle
conceptuel de
données
Certains pensent qu’il y a ambigüité sur le sens (qui récupère les clés de qui) : je n’en vois
pas. C’est forcément l’association qui a le moins de liens directs qui récupère les clés de Page 31
l’autre association.
10. Petit mémento du MCD

Vous avez vu les outils du MCD. Il vous reste maintenant à apprendre à les manipuler cor-
rectement. Voici un ensemble de conseils et de cas de figures classiques. Prenez le temps
de bien assimiler chaque point abordé, illustré à chaque fois par un exemple (repéré par
le petit bonhomme). Cette partie est la plus importante du cours.
Comment reconnaître une entité ?

Une entité est la représentation du réel : personne, lieu, objet…
Pour repérer une entité, il faut se demander si l’on a affaire à un ensemble d’informa-
tions liées par un sens commun et clairement identifiable par un seul attribut. Rappelez-
vous aussi que les attributs doivent être en dépendance fonctionnelle élémentaire et
directe avec l’identifiant de l’entité.
Pour chaque film, il sera possible de connaître l’ensemble des informations importantes :
titre du film, résumé succinct, durée, année de sortie.
8 2955 TG PA 00
Les attributs donnés dans le sujet sont : titre, résumé, durée et année.
FILM
Ces attributs décrivent tous un film, d’où la création de l’entité FILM
idFilm
pour les contenir.
titre
Il reste à trouver l’identifiant : aucun des attributs ne peut jouer le rôle résumé
d’identifiant (même le titre car 2 films peuvent avoir le même titre), durée
d’où l’ajout d’un idFilm qui contiendra un numéro séquentiel généré année
automatiquement.
FILM (idFilm, titre, résumé, durée, année)

Comment trouver l’identifiant d’une entité ?

Il arrive que plusieurs attributs puissent jouer le rôle d’identifiant pour une entité. Vous
avez alors a priori le choix. Cependant, évitez de prendre un attribut existant comme
identifiant. Il est conseillé d’ajouter un attribut de type numéro séquentiel qui sera auto-
matiquement géré et incrémenté par le système. Cela évite tout problème.
Une personne possède un nom, une adresse, un téléphone et un numéro de Sécurité sociale.
Quels sont les attributs qui peuvent servir d’identifiants ?

telephone : un téléphone identifie de façon unique une personne, mais c’est une infor-
Séquence 2
mation non stable (la personne peut changer de numéro) donc non PERSONNE
Le modèle fiable. idPersonne
conceptuel de
numSS : un numSS est unique et stable, mais on n’est pas à l’abri d’une nom
données
erreur de saisie ou de traitement, de plus c’est un numéro volumineux adresse
Page 32 (les identifiants doivent être les plus légers possible car ils peuvent être telephone
repris en particulier dans les associations). numSS
La meilleure solution est donc d’ajouter un attribut idPersonne de type
numéro séquentiel. Cela n’empêchera pas le fait de pouvoir accéder aux personnes par
leur numSS ou leur téléphone.
Comment reconnaître une association ?

Il existe 3 cas possibles d’associations.
1er cas : l’association "normale"
Si un ou plusieurs attributs nécessitent plusieurs informations élémentaires pour y accé-
der, il faut créer une association pour contenir ces attributs.
Dans une commande, pour chaque article commandé, il faut connaître la quantité.
La quantité dépend de la commande mais aussi de l’article. Il faut donc créer une asso-
ciation entre COMMANDE et ARTICLE pour accéder à la quantité commandée.
ARTICLE
1,n 0,n idArticle
idCommande qteCommandée
nomArticle
date prix
8 2955 TG PA 00
COMMANDE (idCommande, date)
idCommande : clé primaire
ARTICLE (idArticle, nomArticle, prix)
idArticle : clé primaire
LIGNE_COMMANDE (idCommande, idArticle, qteCommandée)
idCommande, idArticle : clé primaire
idCommande : clé étrangère en réf. à idCommande de COMMANDE
idArticle : clé étrangère en réf. à idArticle de ARTICLE
2e cas : l’association "vide" ("non porteuse")

Un lien entre entités peut parfois être nécessaire non pas pour accéder à une nouvelle
information mais pour permettre des traitements qui nécessitent ce lien.
n livre peut être écrit par plusieurs auteurs : il est nécessaire de pouvoir éditer la liste des
U
livres d’un auteur précis.
LIVRE AUTEUR
1,n AUTEUR_LIVRE 0,n
idLivre idAuteur
titre nom
Cette fois l’association ne contient rien, cependant elle est nécessaire pour pouvoir faire
le lien entre LIVRE et AUTEUR.
Séquence 2
LIVRE (idLivre, titre)
idLivre : clé primaire Le modèle
AUTEUR (idAuteur, nom) conceptuel de
idAuteur : clé primaire données
AUTEUR_LIVRE (idLivre, idAuteur)
idLivre, idAuteur : clé primaire Page 33
idLivre : clé étrangère en réf. à idLivre de LIVRE
idAuteur : clé étrangère en réf. à idAuteur de AUTEUR
3e cas : la CIF
Lorsqu’il existe une dépendance fonctionnelle entre 2 identifiants, celle-ci va se traduire
par une association particulière : la CIF
Un livre est classé dans un thème précis.
LIVRE THEME
1,1 0,n
idLivre idTheme
titre libellé
Les thèmes sont recensés dans une entité, donc il suffit de créer un lien entre LIVRE et
THEME pour récupérer le thème du livre. Ce lien se traduit ensuite par une clé étrangère.
LIVRE (idLivre, titre, idTheme)

idLivre : clé primaire
idTheme : clé étrangère en réf. à idTheme de THEME
THEME (idTheme, libellé)
idTheme : clé primaire
8 2955 TG PA 00
Comment transformer une association en entité ?
Avant de voir dans quel cas il est conseillé de transformer une association en entité,
voyons techniquement comment cela peut se faire.
Voici un extrait de schéma :
HOTEL DATE
idHotel dateDebutLoc
nom 0,n
adresse 0,n
FACTURE
dateFinLoc
0,n 1,1
0,n CLIENT
NUMCHAMBRE
idClient
numChambre 0,n nom
Avant de donner les règles de transformation, il est nécessaire d’expliquer un peu ce

schéma. Ici, la facture est repérée par 3 informations : l’hôtel concerné, le numéro de
chambre (sachant qu’un même numéro de chambre peut se retrouver dans plusieurs
hôtels) et la date de début de location de la chambre. Ces 3 informations étant suffi-
Séquence 2 santes pour repérer une facture précise, il suffit ensuite de mettre dans l’association
les informations restantes (dateFinLoc et le client, auquel on accède par clé étrangère).
Le modèle
conceptuel de Remarquez aussi NUMCHAMBRE qui est lié à autre chose dans le schéma… (vous l’avez
données compris, ce schéma n’est pas en Merise/2)
Une association FACTURE n’étant pas une bonne idée, transformons-la en entité.
Page 34
Voici les règles précises de transformation d’une association en entité :
• l’identifiant de la nouvelle entité est un nouvel identifiant ;
• les attributs simples de l’association restent des attributs simples dans la nouvelle
entité ;
• les CIF partant de l’association restent des CIF partant de la nouvelle entité ;
• les liens directs qui entourent l’association se transforment en CIF partant de la nou-
velle entité (sauf en cas de lien direct vers une entité "vide" non utilisée dans le reste
du schéma : dans ce cas l’entité disparaît et son identifiant se transforme en attribut
simple dans la nouvelle entité).
HOTEL
FACTURE
idHotel
nom 0,n 1,1 idFacture
adresse dateDebutLoc
dateFinLoc
1,1
0,n 1,1
CLIENT
NUMCHAMBRE 0,n
idClient
numChambre 0,n nom
8 2955 TG PA 00
Quand transformer une association en entité ?
La transformation d’une association en entité est normalement à éviter car l’identi-
fiant d’une association représente une information parlante puisque c’est un ensemble
d’identifiants provenant d’entités existantes.
Cependant, pour éviter les erreurs, donc quand vous n’êtes pas sûrs de vous, prenez
l’option de transformer une association en entité :
• si vous remarquez que votre association possède trop de liens directs et que vous
n’arrivez pas à les minimiser (à partir de 4 liens, posez-vous de sérieuses questions) ;
• si vous pensez qu’il faut une association mais que vous n’arrivez pas à déterminer
les liens directs
n trajet de bus est identifié par un chauffeur, un bus, un horaire (identique pour chaque
U
jour), un jour et une ligne de bus.
CHAUFFEUR BUS
idChauffeur idBus
0,n 0,n
nom dateAchat
TRAJET
0,n 0,n Séquence 2

HORAIRE 0,n LIGNE
Le modèle
heureDeb DATE idLigne
conceptuel de
libellé données
date
Page 35
L’erreur classique consiste à réaliser le schéma précédent.
Face à un tel cas, soit vous trouvez un nombre minimum de liens, soit vous transformez
TRAJET en entité.
1re solution : minimiser les liens
Comment déterminer un trajet précis ?
• date+ligne : ce n’est pas suffisant car une ligne effectue plusieurs trajets par jour.
• date+ligne+horaire : là, sans ambiguïté, pour une même ligne, un jour précis et pour
un horaire précis, il ne peut pas y avoir plusieurs bus ni plusieurs chauffeurs.
Autres associations de clés possibles dans ce cas :
• date+horaire+bus : pour un jour et un horaire précis, un bus ne peut pas se partager
pour gérer plusieurs trajets, donc ça marche.
• date+horaire+chauffeur : pour un jour et un horaire précis, un chauffeur ne peut pas
se partager pour gérer plusieurs trajets, donc ça marche aussi.
Cependant je préfère la première proposition (date+ligne+horaire). Pourquoi ? Parce
que c’est la plus stable : on peut être amené à changer de bus au dernier moment
(panne) ou à changer de chauffeur (malade) mais pas changer de ligne.
8 2955 TG PA 00
CHAUFFEUR BUS
0,n
idChauffeur 0,n idBus
nom 1,1 1,1 dateAchat
TRAJET
0,n 0,n
HORAIRE 0,n LIGNE
libellé
date
2e solution : transformer l’association en entité

CHAUFFEUR BUS
idChauffeur 0,n 0,n idBus
nom TRAJET 1,1 dateAchat
1,1
idTrajet
date
heureDeb
1,1
LIGNE
Séquence 2 0,n
idLigne
Le modèle libellé
conceptuel de
données
Là bien sûr, il n’y a plus de problème ! Cependant cette solution doit être choisie seule-
ment quand vous avez peur de faire une erreur.
Page 36
Vous avez sans doute aussi compris qu’en utilisant les liens identifiants, ce genre de cas
se posera nettement moins souvent.
Comment vérifier la syntaxe du schéma conceptuel de données ?

La syntaxe respecte les règles du modèle relationnel et les règles graphiques du MCD. Il
suffit donc de contrôler que tout est conforme. Dans un premier temps, contrôlez que
les attributs sont bien en dépendance fonctionnelle élémentaire et directe avec leur
identifiant respectif.
Ensuite, voici quelques conseils à suivre. Ces points sont visuellement faciles à contrôler :
O Pd’informations
as de CIF vers une entité temporelle : une CIF est là pour aller chercher plus
dans une autre entité, ce qui ne peut être le cas dans une entité
temporelle qui est vide (excepté la clé) et qui va disparaître au niveau des relations.
FACTURE DATE
1,1 0,n
idFacture date
total
8 2955 TG PA 00
O 2Pasattributs
d’association avec un seul lien direct : une association possède au moins
en identifiant, donc au moins 2 liens directs.
LIVRE
1,n AUTEUR_LIVRE
idLivre auteur
titre
O Ptotalement
as de lien direct entre 2 entités : (sauf dans le cas d’un héritage, ce qui est
différent) 2 entités ne peuvent être liées que par une association (quel
que soit le type d’association : une CIF par exemple). Cette erreur, pour une raison
obscure, est assez classique.
LIVRE THEME
1,n
idLivre idTheme
titre libellé
Comment vérifier la sémantique d’un schéma conceptuel

de données ?
Je n’ai aucune recette de cuisine à vous proposer excepté utiliser vos neurones. Le mieux Séquence 2
est de relire attentivement le sujet pour contrôler étape par étape si votre schéma
Le modèle
répond aux attentes. conceptuel de
données
Comment déduire les relations à partir du schéma ?
Vous commencez à connaître le principe de traduction du schéma conceptuel de don- Page 37
nées en relations normalisées. Voici un résumé de toutes les règles à connaître.
• Les entités temporelles et numéro (appelées entités "vides") disparaissent.
• Les entités normales (possédant des attributs ou dont l’identifiant, s’il est seul, com-
porte une information qui ne peut être générée automatiquement) se transforment
en relation : l’identifiant devient la clé primaire de la relation.
• Toutes les associations (excepté les CIF) se traduisent en relation dont les clés pri-
maires sont récupérées avec les liens directs de l’association (ces clés primaires sont
aussi étrangères lorsqu’elles sont clés primaires dans une autre relation).
• Les CIF (cardinalité 1,1 et éventuellement 0,1) disparaissent et se traduisent par une
clé étrangère dans la relation qui est du côté de la cardinalité 1,1 (éventuellement
0,1).
• Les attributs simples (des entités ou des associations) sont recopiés dans les relations.
• Les entités filles (sous-types) récupèrent la clé primaire de l’entité mère, cette clé
étant aussi étrangère.
8 2955 TG PA 00
Exercice 3
Écrivez séparément les relations issues de ces 2 schémas (en nouvelle notation).
CHAUFFEUR BUS
0,n
idChauffeur 0,n idBus
nom dateAchat
1,1 1,1
TRAJET
0,n 0,n
HORAIRE 0,n LIGNE
libellé
date
HOTEL DATE
idHotel dateDebutLoc
Séquence 2
nom 0,n
Le modèle 0,n adresse 0,n
conceptuel de
données
FACTURE
CHAMBRE
Page 38 dateFinLoc
1,1
0,n CLIENT
NUMCHAMBRE
0,n idClient
numChambre 0,n nom
Quelques cas de figure courants des schémas conceptuels de données

La première partie du mémento vous a présenté les bases pour construire correctement
un schéma conceptuel de données. Vous allez maintenant aborder plusieurs cas de
figures classiques, pour vous habituer à ces types de problèmes. Chaque cas est illustré
par un exemple. Vous trouverez plusieurs exercices en fin de séquence : n’hésitez pas à
régulièrement revenir sur ce mémento pour vous aider.
Choix de l’identifiant
Vous avez vu que pour les entités, il faut favoriser les identifiants internes automatique-
ment gérés par le système. Pour les associations, le problème se pose plutôt au niveau du
choix des liens directs. Reprenons toutes ces notions à travers un exemple :
n enfant (n°insee, nom) parle plusieurs langues (libellé). Il faut connaître l’ordre des lan-
U
gues pour chaque enfant.
8 2955 TG PA 00
Vous pourriez prendre comme identifiant d’enfant son n°insee mais c’est une mauvaise
idée : même si ce numéro est stable, il est trop long (n’oubliez pas qu’un identifiant peut
être utilisé ensuite comme clé étrangère) et dès qu’il y a intervention humaine (saisie
de ce numéro), il peut y avoir des erreurs. C’est le même problème pour le libellé de la
langue qui est forcément unique mais il est préférable d’identifier la langue avec un
numéro automatique.
Voici une première solution de schéma, sans utiliser les identifiants internes :
ENFANT LANGUE PARLEE LANGUE

0,n 0,n
n°insee ordre libellé
nom
Voici le résultat en extension :

ENFANT LANGUE
n°insee nom libellé
2990506080010 DUPONT Anglais
1010283090040 BERNARD Allemand
1001213092040 DURAND Espagnol
… … …
Séquence 2
LANGUE PARLEE
Le modèle
n°insee libelle ordre conceptuel de
2990506080010 Anglais 1 données
2990506080010 Allemand 2
Page 39
2990506080010 Espagnol 3
1010283090040 Allemand 1
1001213092040 Anglais 1
1001213092040 Espagnol 2
… …
Remarquez bien que dans LANGUE_PARLEE, la reprise des identifiants de ENFANT et
LANGUE force à recopier les n°insee et les libellés des langues. Au niveau place ce n’est
pas optimisé.
Voici la solution avec des numéros internes :
ENFANT LANGUE PARLEE LANGUE

0,n 0,n
idEnfant ordre idLangue
n°insee libellé
nom
8 2955 TG PA 00
La représentation en extension donne ceci, pour le même exemple :
ENFANT LANGUE
idEnfant n°insee nom idLangue libellé
1 2990506080010 DUPONT 1 Anglais
2 1010283090040 BERNARD 2 Allemand
3 1001213092040 DURAND 3 Espagnol
… … …
LANGUE PARLEE
idEnfant idLangue ordre
1 1 1
1 2 2
1 3 3
2 2 1
3 1 1
3 3 2
… …
Et là vous vous dites : "le tableau précédent était peut-être plus lourd mais plus facile à
Séquence 2
comprendre". Mais là vous ne raisonnez pas en informaticien : le but est de stocker des
Le modèle données pour ensuite les traiter avec un programme. Par programme, on sait facilement
conceptuel de trouver le nom ou le numéro d’insee de l’enfant dont l’identifiant est 1. Idem pour la
données langue. Donc cette seconde solution est nettement plus légère et efficace.
Voici les relations qui en découlent :
Page 40
ENFANT (idEnfant, n°insee, nom)
idEnfant : clé primaire
LANGUE (idLangue, libellé)
idLangue : clé primaire
LANGUE_PARLEE (idEnfant, idLangue, ordre)
idEnfant, idLangue : clé primaire
idEnfant : clé étrangère en réf. à idEnfant de ENFANT
idLangue : clé étrangère en réf. à idLangue de LANGUE
Une autre solution est possible : décider de mettre l’ordre de la langue au niveau de la
clé primaire. Voici le résultat en utilisant un lien identifiant :
ENFANT LANGUE_PARLEE
0,n (1,1)
idEnfant ordre
n°insee
nom
1,1
LANGUE
0,n
idLangue
libellé
Cette fois, les langues parlées sont directement numérotées par enfant. Voici le résultat
au niveau des relations :
8 2955 TG PA 00
ENFANT (idEnfant, n°insee, nom)
idEnfant : clé primaire
LANGUE (idLangue, libellé)
idLangue : clé primaire
LANGUE_PARLEE (idEnfant, ordre, idLangue)
idEnfant, ordre : clé primaire
idEnfant : clé étrangère en réf. à idEnfant de ENFANT
idLangue : clé étrangère en réf. à idLangue de LANGUE
Quelle est la meilleure solution finalement ? Dans ce cas, il n’y en a pas une meilleure
que l’autre. Les 2 ont un avantage et un inconvénient.
La première solution évite d’attribuer 2 fois la même langue à un même enfant (puisque
la clé primaire de LANGUE_PARLEE doit être unique) mais, si ce n’est pas correctement
géré par programme, on peut par erreur attribuer 2 fois le même numéro d’ordre à un
même enfant, ce qui serait faux.
La seconde solution inverse le problème : elle évite d’avoir 2 fois le même numéro d’ordre
pour un même enfant mais, si ce n’est pas correctement géré par programme, on peut
par erreur attribuer 2 fois la même langue à un même enfant, ce qui serait aussi faux.
Donc dans ce cas, a priori il n’y a pas de solution idéale. Cependant il arrive souvent
qu’une solution soit meilleure que l’autre : il faudra savoir faire les bons choix.
CIF "porteuse" ou "non porteuse" ?
Vous avez vu qu’une façon de symboliser les CIF est l’utilisation d’un petit rond (c’est la
méthode que j’utilise de préférence). Cette représentation a le double avantage de vous
Séquence 2
permettre de repérer facilement les CIF et aussi d’éviter l’erreur qui consiste à mettre
un attribut dans la CIF (là, vous n’avez pas la place, donc la question ne se pose pas). En Le modèle
effet, puisque la CIF ne se traduit pas par une relation, il n’est a priori pas logique de conceptuel de
données
mettre un attribut dedans.
En réalité, les choses sont nettement plus nuancées. Essayons de le comprendre à travers Page 41
un exemple :
Un étudiant doit choisir obligatoirement une option et il faut mémoriser à quelle date il l’a choisie.
Voici le schéma qui parait logique :
ETUDIANT OPTION
idEtudiant 1,1 0,n idOption
nom libellé
dateChoixOpt
Puisqu’il n’y a qu’une option possible, la date de choix de l’option peut être directement
mise dans l’entité ETUDIANT :
ETUDIANT (idEtudiant, nom, dateChoixOpt, idOption)
idEtudiant : clé primaire
idOption : clé étrangère en réf. à idOption de OPTION
OPTION (idOption, libellé)
idOption : clé primaire
Mais certains puristes diront : "la date du choix de l’option n’a de raison d’exister que
par rapport au choix de l’option donc elle doit être portée par l’association". Du coup on
représente la CIF sous forme d’une association classique, ce qui donne :
8 2955 TG PA 00
ETUDIANT OPTION
CHOIX_OPTION
nom dateChoixOpt libellé
Tout ça pour pas grand-chose puisqu’au niveau des relations, la cardinalité 1,1 se tradui-
sant de toute façon par une clé étrangère, CHOIX_OPTION disparaît et son contenu est
naturellement transféré dans ETUDIANT.
Voyons ce qui se passe pour le cas d’une cardinalité 0,1 :
n étudiant peut choisir au maximum une option et, s’il en choisit une, il faut mémoriser
U
à quelle date il l’a choisie.
On obtient normalement le schéma suivant :
ETUDIANT OPTION
nom libellé
dateChoixOpt
Il est identique au précédent excepté la cardinalité 0,1 car un étudiant peut ne pas
Séquence 2
choisir d’option. Dans ce cas, l’attribut dateChoixOpt va rester vide. Les attributs vides
n’étant généralement pas très bien vus, on pourrait préférer la représentation suivante :
Le modèle
conceptuel de ETUDIANT OPTION
données CHOIX_OPTION
nom dateChoixOpt libellé
Page 42
Mais que faire au niveau relationnel ? Traduire le 0,1 par une clé étrangère et migrer
dateChoixOpt dans la relation ETUDIANT, ou créer une relation CHOIX_OPTION puisque
dateChoixOpt ne sera rempli que lorsqu’une option est choisie.
Il faut bien avoir conscience que les 2 solutions sont possibles. Dans ce cas, la première
me paraît la meilleure : c’est un peu lourd de créer une relation supplémentaire juste
pour éviter un simple attribut vide. On peut parfois être confronté à des cas plus difficiles
à trancher.
En conclusion, pour limiter au maximum les erreurs, je vous conseille de ne jamais placer
d’attributs dans les associations qui portent une cardinalité 1,1 ou 0,1 et, pour éviter
cette erreur, le mieux est encore de toujours représenter ce type d’associations avec le
petit rond. Cependant, n’oubliez pas que vous devez être capable d’interpréter toutes
les représentations.
8 2955 TG PA 00
Notion d’historique
Gérer un historique suppose que l’on désire garder des informations dans le temps. Il
impose l’intervention d’une entité temporelle (ou d’un attribut temporel en identifiant,
dans le cas d’une solution utilisant un lien identifiant).
e but est de mémoriser les locations des films avec, à chaque fois, la date de location et la
L
date de retour. Il faut aussi savoir qui a loué le film.
Ce cas a déjà été vu. Il y a juste le client à ajouter.
FILM
LOCATION DATE
idFilm 0,n 0,n
dateRetour dateLocation
titre
1,1
CLIENT
0,n
idClient
nom
Attention, quand vous utilisez une entité temporelle, c’est forcément pour créer une
association et cette entité ne peut pas contenir autre chose qu’un identifiant de type
temporel (il ne peut pas y avoir d’attribut simple dedans). Voici l’erreur classique que
l’on retrouve parfois : Séquence 2
FILM Le modèle
LOCATION DATE conceptuel de
idFilm 0,n 0,n données
dateLocation
titre
dateRetour Page 43
1,1
CLIENT
0,n
idClient
nom
Ceci est une énormité. Pourquoi ? Vous faites une entité DATE qui comporte comme
identifiant une dateLocation et comme attribut simple une dateRetour. Cela signifie que,
quelle que soit la location, une dateLocation donne toujours la MEME dateRetour. Donc
tous les clients qui font un emprunt
le 12/02 doivent ramener le film FILM (1,1) LOCATION
0,n
emprunté le 14/02… idFilm dateLocation
Il faut bien comprendre le rôle titre dateRetour
d’une entité temporelle : elle
apporte juste un identifiant tem-
porel mais n’a pas de vie propre 1,1
puisqu’elle est vouée à disparaître CLIENT
dans le schéma relationnel. 0,n
idClient
Du coup la représentation avec un nom
lien identifiant facilite les choses
et limite les erreurs :
8 2955 TG PA 00
Au niveau relationnel, le résultat est le même que la solution précédente (celle qui était
juste, bien sûr).
FILM (idFilm, titre)

CLIENT (idClient, nom)
LOCATION (idFilm, dateLocation, dateRetour, idClient)
idFilm, dateLocation : clé primaire
idFilm : clé étrangère en réf. à idFilm de FILM
idClient : clé étrangère en réf. à idClient de CLIENT
"Sortir" ou non des informations d’une entité

Vous allez parfois vous poser la question "dois-je laisser cette information sous forme
d’attribut ou dois-je la sortir et créer une entité ?".
Les informations doivent être sorties dans 2 cas :
• si elles risquent de se répéter et/ou que des recherches peuvent porter dessus ;
• si elles sont issues d’une liste déterminée.
n livre comporte les renseignements suivants : titre, résumé, nombre de pages, auteur et
U
thème (il existe une liste de thèmes déterminée).
Qu’est-ce qui va rester comme attribut simple et qu’est-ce qui va sortir de l’entité LIVRE ?
Séquence 2 Titre, résumé et nombre de pages : ces informations sont simples et ne concernent que
ce livre. Il n’y a aucun intérêt de les sortir en créant une autre entité.
Le modèle
conceptuel de Thème : pas d’ambiguïté puisqu’il est question d’une liste déterminée de thèmes. Donc
données une entité THEME doit être créée.
Auteur : ce n’est pas faux de mettre
Page 44 AUTEUR LIVRE
auteur en attribut simple de LIVRE et 0,n 1,1
suivant les traitements qu’il faudra idAuteur idLivre
faire, ce sera peut-être la solution la nom titre
plus simple. Mais il y a de grandes résumé
chances que cette information se nbPages
répète (plusieurs livres d’un même
auteur) et ce ne serait pas étonnant
1,1
que des traitements portent sur THEME
l’auteur (recherche des livres d’un 0,n
idTheme
auteur) donc il paraît plus judicieux
libellé
de sortir cette information.
Voici donc la solution adoptée.
Voici les relations correspondantes :
AUTEUR (idAuteur, nom)
idAuteur : clé primaire
THEME (idTheme, libellé)
idTheme : clé primaire
LIVRE (idLivre, titre, résumé, nbPages, idAuteur, idTheme)
idLivre : clé primaire
idAuteur : clé étrangère en réf. à idAuteur de AUTEUR
idTheme : clé étrangère en réf. à idTheme de THEME
8 2955 TG PA 00
Double CIF
La double CIF représente la nécessité d’obtenir 2 informations provenant d’une même
entité. Dans ce cas, pour une meilleure lisibilité, si la CIF est représentée sous forme d’un
rond, son rôle est tout de même marqué dedans ou à côté.
Un voyage comporte une date, un nombre de jours, une ville de départ et une ville d’arrivée.
Voici l’erreur classique à ne pas faire :
VILLE DEPART
0,n idVilleDépart
VOYAGE 1,1 nom
idVoyage
date 1,1
nbJours 0,n VILLE ARRIVEE
idVilleArrivée
nom
Cette représentation supposerait que certaines villes sont toujours des villes de départ,
et d’autres toujours des villes d’arrivées. Ou alors, toutes les villes sont en double, dans Séquence 2
départ et arrivée, ce qui n’est pas plus malin.
Le modèle
Il est évident qu’il ne faut faire qu’une entité VILLE. Ce sont les CIF qui vont permettre conceptuel de
de choisir la ville de départ et la ville d’arrivée. données
départ
1,1 0,n Page 45
VOYAGE VILLE
idVoyage arrivée idVille
date 1,1 0,n nom
nbJours
Voici les relations correspondantes (où les noms donnés aux clés étrangères doivent être
parlants) :
VILLE (idVille, nom)
idVille : clé primaire
VOYAGE (idVoyage, date, nbJours, idVilleDepart, idVilleArrivee)
idVoyage : clé primaire
idVilleDepart : clé étrangère en réf. à idVille de VILLE
idVilleArrivee : clé étrangère en réf. à idVille de VILLE
Association réflexive
L’association réflexive est nécessaire lorsqu’on a besoin de lier une information avec elle-
même. Ce lien peut être nécessaire pour accéder à une nouvelle information, ou juste
pour obtenir des "couples" nécessaires pour les traitements. Là encore, il ne faut surtout
pas séparer l’entité en 2.
8 2955 TG PA 00
Il faut enregistrer les distances entre les villes.
Voici l’erreur à ne pas faire :
VILLE DEPART 0,n

idVilleDépart
nom
DISTANCE
distance
VILLE ARRIVEE
0,n
idVilleArrivée
nom
Pour les mêmes raisons que tout à l’heure (dans la partie "double CIF"), c’est une grave
erreur de séparer les villes en 2 entités.
Voici la solution :
0,n
Séquence 2
VILLE DISTANCE
Le modèle idVille distance
conceptuel de
données nom
0,n
Page 46
Lorsque cela paraît nécessaire, il est possible de mettre des noms de rôle sur chaque lien
direct. Ici, le nom de l’association est suffisamment explicite.
Voici le résultat au niveau relationnel (où cette fois, ce sont les clés primaires qui doivent
être renommées pour être plus explicites et de toute façon pour éviter d’avoir 2 attributs
avec le même nom, ce qui n’est pas possible) :
VILLE (idVille, nom)
idVille : clé primaire
DISTANCE (idVilleDepart, idVilleArrivee, distance)
idVilleDepart, idVilleArrivee : clé primaire
idVilleDepart : clé étrangère en réf. à idVille de VILLE
idVilleArrivee : clé étrangère en réf. à idVille de VILLE
CIF réflexive
Le cas de la CIF réflexive est nettement plus rare et, dans tous les cas, ne peut pas porter
une cardinalité minimum à 1 (sinon la réflexivité n’aurait pas de fin) donc les cardinalités
seront 0,1 d’un côté et 0,n (ou 0, une valeur déterminée) de l’autre.
Contrôlez bien que vous n’êtes pas en présence d’une association réflexive (la confu-
sion est classique). Les CIF réflexives traduisent des structures en forme d’arbre (où l’on
retrouve un antécédent mais plusieurs successeurs).
8 2955 TG PA 00
n composant ne rentre dans la fabrication que d’un seul autre composant, mais il peut être
U
fabriqué avec plusieurs composants.
0,n
COMPOSANT
idComposant
nom
0,1
Voici la relation correspondante :

COMPOSANT (idComposant, nom, idCompPere)
idComposant : clé primaire
idCompPere : clé étrangère en réf. à idComposant de COMPOSANT
CIF et association entre 2 entités

Il est tout à fait possible d’avoir une CIF et une association entre 2 mêmes entités.
Chacune (la CIF et l’association) joue son rôle. Dans ce cas, la CIF décrit généralement
(mais pas toujours) un cas particulier de l’association. Elle pourrait donc éventuellement
se traduire par un attribut booléen dans l’association. Mais cette dernière solution, tout
en étant juste, est plus lourde et moins visuelle que la précédente. Comme dans le cas
de la double CIF, il est souvent conseillé de nommer la CIF pour que le schéma soit plus Séquence 2
parlant.
Le modèle
conceptuel de
données
ne formation peut être animée par plusieurs formateurs dont l’un d’eux est responsable de
U
la formation. Page 47
Voici la première solution, avec un booléen :
FORMATION ANIMATEUR FORMATEUR

1,n 0,n
idFormation responsable idFormateur
titre nom
date
Cette solution a un inconvénient : pour chaque couple "formation/formateur" dans ani-

mateur, il faut préciser si c’est le responsable ou non, alors qu’il n’y a qu’un responsable.
La solution suivante est plus visuelle et évite ce problème :
responsable
1,1 0,n
FORMATION FORMATEUR
idFormation idFormateur
titre 0,n ANIMATEUR 0,n nom
date
8 2955 TG PA 00
FORMATEUR (idFormateur, nom)
idFormateur : clé primaire
FORMATION (idFormation, titre, date, idResp)
idFormation : clé primaire
idResp : clé étrangère en réf. à idFormateur de FORMATEUR
ANIMATEUR (idFormation, idFormateur)
idFormation, idFormateur : clé primaire
idFormation : clé étrangère en réf. à idFormation de FORMATION
idFormateur : clé étrangère en réf. à idFormateur de FORMATEUR
CIF partant d’une association

Vous avez vu ces CIF partant d’associations à travers plusieurs exemples précédents.
Pourquoi en parler maintenant ? Qu’ont-elles de particulier ?
En fait, rappelons qu’une CIF est une association (même si elle est un peu particulière).
Avant l’ajout de la notion d’agrégation avec Merise/2 (c’est-à-dire le fait de permettre de
relier une association directement à une autre), la plupart des utilisateurs de la méthode
Merise partaient du principe que, la CIF étant une association, il n’était pas permis de la
faire partir directement d’une autre association. Cette règle m’a toujours gênée car une
CIF se traduit par une clé étrangère et je ne vois pas pourquoi une relation issue d’une
association n’aurait pas le droit d’avoir une clé étrangère.
De toute façon, maintenant la question ne se pose plus puisque, depuis Merise/2, cette
interdiction est levée. Attention, cependant, vous pouvez très bien trouver dans des
Séquence 2 sujets une représentation sous forme d’agrégation pour symboliser une CIF (lorsque
celle-ci est symbolisée par une association classique).
Le modèle
conceptuel de 1re représentation (qui me semble être la plus visuelle) :
données
FILM
LOCATION DATE
Page 48 idFilm 0,n 0,n
1,1
CLIENT
0,n
idClient
nom
2e représentation (que vous devez savoir au moins lire) :
FILM
LOCATION DATE
idFilm 0,n 0,n
1,1
CLIENT
0,n LOUE
idClient
nom
8 2955 TG PA 00
Facturation classique
La facturation est un des cas les plus classiques rencontrés dans les sujets de gestion.
Bien sûr il existe plusieurs variantes suivant les contextes, cependant, il existe 2 grandes
catégories de facturation.
1re catégorie de facturation : chaque article n’apparaît qu’une fois
C’est le cas le plus classique de facturation. Un article peut être acheté en plusieurs
exemplaires, mais n’apparaît que sur une seule ligne de la facture. Voici le schéma cor-
respondant :
ARTICLE
1,n 0,n idArticle
idFacture qteCommandée nomArticle
date prix

LIGNE_FACTURE (idFacture, idArticle, qteCommandee)
idFacture, idArticle : clé primaire
Séquence 2
2e catégorie de facturation : chaque article peut apparaître plusieurs fois
C’est par exemple le cas de la facturation dans un restaurant : sur le ticket, les articles Le modèle
conceptuel de
sont dans l’ordre de la commande, donc il peut y avoir une boisson en début de repas, données
qui est ensuite recommandée en cours de repas. Un même article peut non seulement
être commandé plusieurs fois, mais peut aussi apparaître sur des lignes différentes de Page 49
la facture. Le schéma précédent ne marche plus car LIGNE_FACTURE a pour identifiant
idFacture+idArticle. L’identifiant devant être unique, on ne pourra pas avoir plusieurs
fois le même article sur des lignes différentes de la facture. Du coup, il faut utiliser les
numéros de lignes de la facture.
Voici la solution :
FACTURE LIGNE_FACTURE NUMLIGNE

1,n 0,n
idFacture qteCommandée numLigne
date
1,1
ARTICLE
0,n
idArticle
nomArticle
prix
8 2955 TG PA 00
La version avec lien identifiant est plus légère :
0,n (1,1)
idFacture numLigne
date qteCommandée
1,1
ARTICLE
0,n
idArticle
nomArticle
prix

LIGNE_FACTURE (idFacture, numLigne, qteCommandee, idArticle)
idFacture, numLigne : clé primaire
Gestion des âges
Séquence 2 Le but est d’utiliser les attributs qui nécessitent le moins de mises à jour possible. Par
exemple, dans le cas de l’âge (ou de l’ancienneté dans une entreprise), il ne faut bien
Le modèle évidemment pas utiliser cette donnée comme attribut mais la remplacer par la date de
conceptuel de
données
naissance. La date de naissance est une donnée fixe et l’âge pourra être récupéré par
simple calcul.
Page 50 Ceci est donc valable pour toutes les données qui peuvent être obtenues par un calcul
sur une autre donnée plus stable.
Gestion d’une liste
La liste d’informations peut être gérée de 2 façons suivant les besoins :
– elle est traduite par un simple attribut lorsque le contenu de cette liste n’est pas homo-
gène et ne fera l’objet d’aucun traitement sur une partie des informations, mais toujours
sur la liste complète ;
– elle est traduite par une association pour récupérer l’ensemble des informations de la
liste dans une autre entité.

Pour chaque film, on désire connaître le titre, la durée, la liste des intervenants composant le
générique du film (scénaristes, animateurs 3D, spécialistes du son…) et la liste des acteurs.
Il doit être possible de faire des recherches par acteur.
Très nettement, la liste des acteurs doit être gérée sous forme d’association. En revanche,
la liste des intervenants, donc le générique, semble une information non homogène et
ne subissant qu’un traitement dans sa globalité.
FILM
ACTEUR
idFilm 0,n ACTEUR_FILM 0,n
titre idActeur
durée nom
générique
8 2955 TG PA 00
La transitivité
Dans certains cas, il existe plusieurs chemins pour accéder à la même information. Il
y a alors une transitivité et le chemin le plus court doit normalement être supprimé.
Attention, suivant l’ordre des traitements, certaines transitivités se justifient.
ne formation est animée par un formateur et ne concerne qu’une spécialité. Un formateur

U
n’est spécialisé que dans une spécialité.
FORMATEUR FORMATION
0,n 1,1
idFormateur idFormation
nom titre
1,1 1,1
SPECIALITE
0,n 0,n
idSpécialité
libellé
Le lien entre FORMATION et SPECIALITE est en trop puisqu’on peut obtenir la spécialité
de la formation en passant par le formateur.
Mais attention, cet exemple a été choisi pour son ambiguïté. En effet, si le choix du for-
mateur se fait après avoir créé la formation et donc en fonction de la spécialité atten- Séquence 2
due pour la formation, alors il est nécessaire de mémoriser la spécialité de la formation Le modèle
indépendamment du formateur. conceptuel de
données
Donc, quand vous tombez sur un cas de transitivité, avant de spontanément supprimer
le lien qui semble "en trop", posez-vous la question de son utilité.
Page 51
Les paramètres et entités indépendantes
Pour finir, voici un cas que vous rencontrerez très rarement dans les sujets traditionnels,
mais que vous serez amené à gérer dans les cas réels de gestion de projets. Les schémas
semblent relier toutes les entités d’une façon ou d’une autre. Si vous avez des entités
"isolées", vous avez toutes les raisons de vous poser des questions. Cependant, il existe
2 cas où les entités peuvent effectivement être isolées.
1er cas : les entités indépendantes
Elles sont très rares mais elles existent. On les retrouve en particulier dans certains cas de
gestion d’intervalles.
our des achats entre 50 et 100 €, 15 % de remise, de 101 à 130 €, 18 %, etc. Il faut
P
connaître la remise accordée pour chaque facture.
Cette entité ne peut être reliée à rien. Tout se fera par calcul. Par rapport REMISE
au montant de la facture, une recherche sera effectuée dans REMISE
pour trouver dans quelle plage de valeurs se trouve le montant. Une fois valeurDebut
la plage trouvée, il suffira de récupérer le pourcentage de remise pour valeurFin
l’appliquer au montant. remise
8 2955 TG PA 00
2e cas : les paramètres
Ce sont des données utiles au développement de l’application mais indépendantes
du schéma conceptuel de données. Les paramètres sont normalement tous regroupés
dans une même "entité", sans clé primaire et comportant une valeur par attribut (donc
un seul tuple). Ils représentent généralement des informations sur l’entreprise qui est
concernée par l’informatisation.
ans l’application, il sera nécessaire d’utiliser le nom et l’adresse de l’entreprise, ainsi que
D
son numéro SIRET.
Les informations peuvent être stockées dans un fichier texte, XML ou PARAMETRE
être mémorisées dans une table ne contenant qu’une seule ligne, sans
clé primaire. Chaque attribut contient une information unique. nomE
adresseE
siret
11. Exercices récapitulatifs de premier niveau

Maintenant, il faut faire des exercices. Surtout ne faites pas l’erreur de vous limiter à
juste quelques exercices ou de simplement survoler la correction. Il est indispensable de
tous les aborder et de passer du temps à chercher. Jusqu’à maintenant vous avez appris
à interpréter et compléter des schémas existants : là vous allez devoir construire des
schémas, ce qui est nettement plus complexe.
Séquence 2
Cependant, les exercices sont progressifs, donc faites-les dans l’ordre et prenez le temps
de bien lire, dans la correction, toutes les explications. Les premiers exercices n’abordent
Le modèle pas directement la construction complète de schémas, mais vont vous permettre d’être
conceptuel de confrontés à plusieurs cas classiques. Attention, malgré le titre, certains exercices ne sont
données
pas si faciles.
Page 52
Exercice 4
Voici les relations qui permettent de gérer la fabrication de jouets du père noël :
JOUET(idJouet, nom, idCatégorie#)
CATEGORIE(idCatégorie, libellé)
ENFANT(idEnfant, nom, age, adresse)
COMMANDE(idEnfant#, idJouet#)
Dessiner le SCD à l'origine de ces relations (sans oublier les cardinalités).

Réécrire les relations en suivant les nouvelles normes.
Préciser toutes les règles de gestion qui découlent de ces relations (dit autrement :
justifier chaque cardinalité).
L'auteur de ces relations hésitait entre l'attribut "age" et l'attribut "dateDe-Naiss-
sance" dans l'entité "ENFANT". Dire s'il a fait le bon choix, en justifiant la réponse.
Compléter d'une autre couleur le MCD en tenant compte des remarques suivantes :
• il existe plusieurs ateliers où sont fabriqués les jouets ;
• un jouet n'est fabriqué que dans un atelier ;
• des lutins fabriquent les jouets : un lutin n'est affecté qu'à un atelier.
Finalement on modifie certaines règles de gestion :
• un jouet peut être de plusieurs catégories différentes ;
• un enfant peut commander plusieurs exemplaires du même jouet ;
• un enfant doit préciser l'ordre d'importance des jouets qu'il commande.
Refaire le SCD en repartant des relations du début du sujet et en tenant compte de
ces nouvelles règles.
8 2955 TG PA 00
Exercice 5
Voici un ensemble de relations :
DOSSIER (idDossier, dateOuverture, idClient)
idDossier : clé primaire
FICHE_DOSSIER (idDossier, numFiche, dateFiche, description)
idDossier, numFiche : clé primaire
idDossier : clé étrangère en réf. à idDossier de DOSSIER
a) Dessiner le SCD à l'origine de ces relations (en version Merise/2).

b) Comment appelle-t-on le lien qui unit FICHE_DOSSIER à DOSSIER ?
c) Pourquoi numFiche n'est pas aussi en clé étrangère dans la relation FICHE_DOSSIER ?
d) Dire si les affirmations suivantes sont vraies :
1. une fiche n'appartient qu'à un seul dossier ;
2. un dossier peut comporter plusieurs fiches ;
3. une fiche peut concerner plusieurs clients ;
4. un client peut posséder plusieurs fiches.
Exercice 6
Séquence 2
Voici un ensemble de relations :
Le modèle
MEDECIN(idMedecin, nom) conceptuel de
idMedecin : clé primaire données
PATIENT(idPatient, nom, adresse, tel)
idPatient : clé primaire Page 53
MUTUELLE(idMutuelle, nom, adresse)
idMutuelle : clé primaire
MUTUELLE_PATIENT(idPatient, idMutuelle)
idPatient, idMutuelle : clé primaire
idPatient : clé étrangère en réf. à idPatient de PATIENT
idMutuelle : clé étrangère en réf. à idMutuelle de MUTUELLE
RV(idPatient, date, heure_deb, heure_fin, idMedecin)
idPatient, date : clé primaire
idPatient : clé étrangère en réf. à idPatient de PATIENT
idMedecin : clé étrangère en réf. à idMedecin de MEDECIN
OPERATION(idPatient, date, numOperation, détail)
idPatient, date, numOperation : clé primaire
idPatient, date : clé étrangère en réf. à (idPatient, date) de RV
Exemples d'opérations : soin de la dent n°14, pose d'une couronne sur la dent n°3,
détartrage… Les opérations ont donc lieu lors d'un rendez-vous. Attention, chaque
opération ne concerne qu'un rendez-vous et donc un patient précis.
a) C
onstruire le schéma conceptuel des données à l'origine de ces relations (vous
trouverez dans la correction la version classique et la version Merise/2).
b) épondre aux questions suivantes en justifiant chaque réponse :
R
• Un patient peut-il consulter plusieurs médecins ?
• Plusieurs opérations peuvent-elles se faire durant un seul rendez-vous ?
• Un rendez-vous peut-il concerner plusieurs médecins ?
• Un patient peut-il prendre plusieurs rendez-vous le même jour ?
8 2955 TG PA 00
c) S i le cabinet ne comportait qu'un seul médecin, quelle modification faudrait-il
apporter au schéma ? (Expliquer la réponse en clair, sans modifier le schéma)
d) O
n vous donne de nouvelles règles de gestion. Modifier le schéma, dans une autre
couleur, pour tenir compte de ces règles :
• tous les patients ont une (et une seule) mutuelle ;
• il faut mémoriser les dates de congés des médecins (plusieurs congés par médecin).
Exercice 7
On veut gérer une bibliothèque et ses prêts de livres.
Beaucoup de livres de la bibliothèque existent en plusieurs exemplaires. Certains
exemplaires peuvent être prêtés, d'autres ne sont qu'en consultation sur place (auto-
risation en sortie = O ou N). Il est possible de faire des recherches de livres sur le titre,
mais aussi sur les thèmes du livre (un livre peut être classé dans plusieurs thèmes),
sur l'auteur (sachant qu'un livre n'a qu'un auteur…). On connaît l'état de chaque
exemplaire.
La bibliothèque propose aussi ses livres à la vente. Le prix varie d'un livre à l'autre,
mais reste fixe pour un même livre.
On connaît le nom, l'adresse et le n° de téléphone des clients.
Séquence 2
L'historique des prêts doit être mémorisé, avec la date de prêt et la date de retour
Le modèle ainsi que le client qui est responsable de la location.
conceptuel de Si un livre n'est pas disponible, une personne peut le réserver : elle sera prévenue par
données
téléphone dès qu'un exemplaire est disponible.
Page 54 Un livre ne peut pas être prêté plusieurs fois le même jour.
a) D'après les explications suivantes, corriger le schéma (4 erreurs) :
8 2955 TG PA 00
b) L'association PRET n'est pas satisfaisante : elle est constituée de trop de liens
directs. Un des liens pourrait être transformé en CIF : lequel et pourquoi ?
c) L e schéma n'exploite pas les possibilités de Merise/2. Refaire le schéma en tenant
compte de ces règles (et de la remarque issue du b) ).
d) Écrire les relations issues du dernier schéma.
Exercice 8
Un magasin de micro-ordinateurs possède un catalogue qui recense tous ses articles
(nom, prix de vente, catégorie). Le catalogue est classé par catégorie. Pour chaque
article, il connaît plusieurs fournisseurs (nom, adresse, tel). Chaque fournisseur pro-
pose l'article en question à un prix particulier.
Dessiner le SCD et écrire les relations correspondantes.
Exercice 9
Un patient (nom, adresse, téléphone) possède un dossier qui lui est propre et qui le
suit lors de tous ses passages à l'hôpital. À chaque passage du patient, on note la
date d'entrée, le motif du passage et la date de sortie (sachant qu'il ne peut pas y Séquence 2
avoir plusieurs "entrées" le même jour pour un même patient).
Le modèle
Dessiner le SCD et écrire les relations correspondantes. conceptuel de
données
Page 55
Exercice 10
Une agence organise des séjours linguistiques. Un séjour comporte les informations
suivantes : la langue concernée (parmi la liste des langues proposées par l'agence),
la date de départ et la date de retour, la ville de départ et la ville d'arrivée. Les tarifs
sont établis, entre autres, en fonction des distances entre les villes : il ne faut donc
pas mémoriser les tarifs mais les distances.
Exercice 11
Le but est de mémoriser les informations sur les clients d'une société : raison sociale
et n° Siret pour les entreprises, nom et prénom pour les particuliers, adresse, n° de
téléphone pour tous. Le fax est plus répandu en entreprise mais certains particuliers
en ont aussi. Les entreprises sont classées par catégorie.
8 2955 TG PA 00
Exercice 12
Les droïdes de Géonosis
Vous travaillez pour le vice-roi Nute Gunray qui s'est réfugié sur la planète Géonosis
pour suivre de près la fabrication d'une armée de droïdes. Vous allez devoir vous
occuper d'une partie de l'informatisation de la gestion des droïdes (fabrication et
utilisation).
Votre prédécesseur n'ayant pas donné satisfaction, il a "disparu". Il avait commencé
une étude de besoins qui l'avait conduit à écrire quelques relations dans le but de
créer une base de données. Vous avez retrouvé une partie de ses travaux. Voici les
relations retrouvées (écrites suivant les anciennes règles d'écritures) :
DROIDE (n°droide, nom, date_fabrication, date_mise_en_service,
n°typedroide#)
TYPEDROIDE (n°typedroide, libellé)
ARME (n°arme, nom, puissance, portée)
ARME_DROIDE (n°droide#, n°arme#)
Question 1 : Dessinez le schéma conceptuel des données correspondant à ces relations.
Nute Gunray avait donné, avant l'écriture de ces relations, un ensemble de règles
que vous trouverez en annexe 1.
Séquence 2 Question 2 : Vous devez préciser pour chaque règle, si elle a été effectivement res-
pectée avec les relations précédentes.
Le modèle
conceptuel de
données Les droïdes devant être utilisés pour des batailles, Nute Gunray avait donné aussi
quelques règles qui ont été traduites par un SCD que vous trouverez en annexe 2.
Page 56
Question 3 : Écrivez les relations normalisées (en respectant les nouvelles règles
d'écriture) qui découlent de ce schéma conceptuel de données.
Ce SCD (de l'annexe 2) est incomplet, plusieurs règles n'ont pas été traduites :
a) Q
uand une bataille se terminera, il faudra mémoriser la date (date fin) et l'issue
(qui est le gagnant : les séparatistes ou la république ?)
b) Il est nécessaire de connaître la liste des lieux recensés sur chaque planète (chaque
lieu possède un nom, une description, une longitude et une latitude).
c) L es batailles sont classées par type (un seul type par bataille). Exemple : attaque
au sol, bombardement aérien…
Question 4 : Apportez les modifications sur le SCD pour respecter ces règles.
8 2955 TG PA 00
Annexe 1
Pour chaque règle, cochez VRAI si les relations du début du sujet respectent cette
règle, cochez FAUX dans le cas contraire.
VRAI FAUX
a) U
n droïde possède une date de fabrication et une date
de mise en service ¨ ¨
b) U
n droïde n'appartient qu'à un seul type (droïdekas,
droïde de combat, droïde de soutien, droïde médical
tripode, astro-droïde…) ¨ ¨
c) Un type de droïde possède une durée de vie ¨ ¨
d) C
haque droïde fabriqué est numéroté par rapport
à son type (1er droïde de combat, 2e droïde de combat…
1er droïdekas, 2e droïdekas, 3e droïdekas…) ¨ ¨
e) P
our chaque arme, il faut connaître son nom, sa puissance
et sa portée ¨ ¨
f) C
haque type de droïde peut manipuler certaines armes,
il faut savoir lesquelles ¨ ¨
g) P
our chaque arme, la quantité de munitions stockable varie
suivant le type de droïde ¨ ¨
h) Il faut connaître la quantité fabriquée de chaque arme ¨ ¨ Séquence 2
i) U
n droïde a un nom qui lui est propre et qui le qualifie en
Le modèle
plus de son type et de son numéro (ex : R2D2, R4G9 sont conceptuel de
les noms de 2 astro-droïdes) ¨ ¨ données
j) Il faut mémoriser la date de désactivation d'un droïde ¨ ¨

Page 57
Annexe 2
8 2955 TG PA 00
Exercice 13
Vous travaillez au FBI avec Mulder sur les affaires non classées. Pour faciliter la ges-
tion des dossiers, une informatisation est préconisée.
Suite à une analyse du fonctionnement du service de Mulder, un premier informa-
ticien a commencé à construire un schéma relationnel (présenté ici suivant les an-
ciennes normes d'écriture) :
Affaire (n°affaire, date_debut, date_cloture, lieu, description)
Personne (n°personne, nom, adresse, informations)
PersonneAffaire (n°affaire#, n°personne#)
LienAffaire (n°affaire1#, n°affaire2#, n°raison#)
Raison (n°raison, libellé)
Remarque : n°affaire1 et n°affaire2 sont des attributs qui contiennent des valeurs
correspondant à n°affaire dans la relation Affaire. LienAffaire permet de savoir pour-
quoi 2 affaires sont éventuellement liées.
A) Construire le schéma conceptuel de données issu de ces relations.
Mulder vous a demandé d'informatiser le suivi détaillé des investigations sur les
affaires non classées. Pour cela il vous a donné un ensemble de règles (annexe 1) que
vous avez tenté de traduire dans un SCD (annexe 2).
B) É
crire l'extrait de schéma relationnel portant sur les objets INVESTIGATION,
INTERVENANT, AGENT et AFFAIRE issus du schéma conceptuel de données de l'an-
Séquence 2
nexe 2 (vous devez obligatoirement respecter les nouvelles normes d'écriture).
Le modèle C) P
our chaque affirmation de l'annexe 1, préciser si elle est respectée ou non dans
conceptuel de le SCD de l'annexe 2.
données
D) L e SCD de l'annexe 2 ne respectant pas correctement toutes les règles de l'annexe
Page 58 1, il vous est demandé de refaire complètement le SCD en respectant toutes les
règles de l'annexe 1 (et uniquement ces règles là).
Annexe 1 : les affirmations
VRAI FAUX
a) Les
investigations sont identifiées par l'affaire concernée et la date
de l'investigation (il ne peut donc pas y avoir plusieurs investigations
le même jour pour la même affaire, cependant il peut y avoir
plusieurs investigations le même jour pour des affaires différentes). ¨ ¨
b) Une investigation est affectée à un ou deux agents. ¨ ¨
c) P
our chaque investigation, il faut mémoriser la durée, le lieu,
un commentaire précis de la raison de l'investigation, ainsi que
le résultat. ¨ ¨
d) P
our chaque investigation, il faut connaître le ou les éventuels
transports utilisés (il existe une liste précise de transports possibles). ¨ ¨
e) P
our chaque investigation, il faut connaître le ou les éventuel(s)
hôtel(s) utilisé(s) (il existe une liste d'hôtels avec leur nom, adresse,
téléphone). ¨ ¨
8 2955 TG PA 00
f) U
ne investigation donne éventuellement lieu à des frais de
remboursement (s'il y a eu déplacements et/ou nuits d'hôtel).
Ces remboursements sont réalisés en fonction des frais réels donc
des factures fournies : le montant total, qu'il faut mémoriser, est
ensuite divisé par le nombre d'agents. La date de remboursement
n'est pas forcément la même pour chaque agent. ¨ ¨
g) U
ne affaire est numérotée et comporte une date d'ouverture,
de clôture, un commentaire, un résultat et un agent qui sera
responsable du suivi de l'affaire. ¨ ¨
h) Il faut pouvoir joindre facilement chaque agent : on mémorise
donc, en plus de leur nom, leur n° de portable et leur adresse email. ¨ ¨
i) M
ême si une investigation est rattachée à une affaire, elle concerne
parfois secondairement plusieurs autres affaires : il faut savoir
lesquelles. ¨ ¨
j) P
our chaque transport utilisé pour une investigation, il faut
mémoriser le kilométrage, et pour chaque hôtel utilisé pour une
investigation, il faut mémoriser le nombre de nuits. ¨ ¨
Séquence 2
Annexe 2 : le SCD
Le modèle
conceptuel de
données
Page 59
8 2955 TG PA 00
12. Exercices récapitulatifs de second niveau
Ces exercices sont des sujets où vous devez réaliser des SCD complets et assez consé-
quents. Certains exercices sont issus de sujets officiels.
Faites-les aussi avec beaucoup d’attention et en y passant le temps nécessaire. Aucun
exercice ne doit être mis de côté car chacun permet de consolider des notions particu-
lières.
Exercice 14
Vous devez informatiser une salle de musculation.
Chaque personne doit s'inscrire pour accéder à la salle. Les renseignements suivants
sont nécessaires pour gérer les adhérents : nom, adresse, téléphone, poids initial,
taille, sports pratiqués. Pour chaque sport on désire connaître le nom du sport et le
niveau de l'adhérent (débutant, confirmé, professionnel). La date d'inscription doit
aussi être enregistrée (pour le paiement annuel de la cotisation). On veut ensuite
pouvoir suivre l'évolution d'un adhérent. Chacune de ses visites doit être numéro-
tée (1re visite de M. Dupont, 2e visite de...) et doit comporter les renseignements
suivants : date et heure de la visite, durée et, pour chaque appareil utilisé, nombre
de séries et valeur des poids utilisés.
Pour chaque appareil, il doit être possible d'obtenir le poids minimum, le poids maxi-
Séquence 2
mum et la liste des muscles qui travaillent.
Le modèle Il sera, entre autres, possible d'effectuer les traitements suivants :
conceptuel de
données – liste des appareils qui font travailler un muscle donné ;
– liste des adhérents classés par sport pratiqué.
Page 60 Dessiner le SCD.
Une petite précision est apportée : attention, le poids utilisé est le même au cours
d'une série mais peut varier d'une série à une autre (pendant une visite).
Apporter la modification nécessaire sur le schéma précédent et écrire les
relations correspondantes.
Exercice 15
Un restaurant décide de développer un système de livraison de pizzas à domicile.
Vous êtes chargé de l’informatisation de cette activité en répondant aux deux ob-
jectifs principaux :
– obtenir des livraisons les plus rapides possible ;
– garder le plus d’informations possibles sur les clients pour les fidéliser.
Les commandes se font par téléphone. Un client appelle et demande une ou plusieurs
pizzas. Soit il précise les noms exacts qu’il aura pris sur le prospectus du restaurant,
soit il précise vaguement ce qu’il désire et l’opératrice devra le conseiller. Un client
peut, bien sûr, commander plusieurs pizzas identiques ou différentes. Chaque pizza
est caractérisée par son nom, la description de ses ingrédients principaux (simplement
le nom des ingrédients, comme jambon, fromage, sans les quantités...). Chaque pizza
est proposée avec 3 tailles différentes (mini, normale ou maxi). Le client doit donc aussi
préciser la taille de chacune des pizzas commandées. Le prix d’une pizza dépend bien
sûr de la pizza choisie et de sa taille. En fait, le prix de la mini est toujours 20 % moins
élevé que la normale, et le prix de la maxi 20 % plus élevé.
8 2955 TG PA 00
Pour chaque commande, l’opératrice doit noter le nom du client, son adresse précise
et son numéro de téléphone. Une fois la commande passée, les pizzas sont aussitôt
fabriquées puis livrées dans les délais les plus brefs. Plusieurs livreurs s’occupent de
ce travail. Pour chaque commande, il faut mémoriser le livreur qui s'en est occupé
(en cas de réclamation).
Afin de personnaliser l’accueil téléphonique des clients et de les fidéliser au maxi-
mum, on désire garder le détail de toutes leurs précédentes commandes dans le but
d’afficher rapidement ces informations. L’opératrice pourra donc tout de suite pro-
poser au client ses anciens choix (pour donner l’impression qu’elle se souvient de lui)
ainsi que ses coordonnées. Si c’est un nouveau client, elle le saura donc tout de suite
et pourra éventuellement le conseiller.
La fidélisation des clients se fait aussi à travers des réductions. Celles-ci fonctionnent
très simplement : sur l’ensemble des commandes, la 10e pizza est gratuite. Le paiement
de la commande peut se faire soit directement au téléphone (carte bleue), soit à la
livraison (chèque ou liquide). Il faut aussi mémoriser si la commande a été payée.
Faire le SCD et écrire les relations correspondantes.
Exercice 16
Ce sujet est plus long et contient des annexes : lisez bien tout l'ensemble avant de
démarrer et récupérez bien toutes les informations qui permettront d'obtenir les Séquence 2
annexes.
Le modèle
L'étude proposée concerne la gestion des passagers et de leurs bagages voyageant conceptuel de
données
sur la compagnie aérienne TRANSAIR. Cette compagnie dessert uniquement des
villes de France métropolitaine.
Page 61
L'enregistrement
Un passager désirant faire appel à la compagnie pour son voyage doit se munir d'un
billet (annexe 1).
Avec ce billet, le passager se présente au comptoir d'enregistrement de l'aéroport de
départ deux heures avant le décollage. L'agent de la compagnie lui remet contre l'un
des volets du billet une carte d'embarquement mentionnant son numéro d'enregis-
trement pour le vol. Cette carte lui permettra l'accès à bord de l'appareil. Le passager
conserve la souche du billet. S'il possède des bagages, chacun de ceux-ci est pesé, éti-
queté et conduit dans la soute de l'avion. Pour chaque bagage enregistré, un talon
d'étiquette est collé sur la souche du billet.
À l'issue des opérations d'enregistrement, le passager est donc en possession de
sa carte d'embarquement et de la souche de son billet, éventuellement complétée
d'autant de talons d'étiquette qu'il y a de bagages enregistrés. Le passager peut
alors embarquer.
Des exemples de ces différents documents sont présentés en annexe (carte d'embarque-
ment : annexe 2, étiquette bagage : annexe 3, talon d'étiquette bagage : annexe 4).
Le voyage
Un billet correspond à un voyage entre deux villes de France métropolitaine. Pour se
rendre à sa destination finale, un passager peut emprunter successivement plusieurs
vols (Lille-Orly, Orly-Toulouse par exemple). Cela signifie qu'un ou plusieurs change-
ments d'avion peuvent être nécessaires. Dans ce cas, le passager n'a qu'un seul billet
et enregistre ses éventuels bagages une seule fois, à l'aéroport de départ. Ceux-ci
l'accompagnent tout au long du voyage.
8 2955 TG PA 00
Par contre, à chaque changement d'appareil, le passager doit se présenter au comp-
toir d'enregistrement muni de la souche de son billet pour recevoir une nouvelle
carte d'embarquement.
Les vols
Un vol est une liaison directe entre deux aéroports, toujours les mêmes. Un aéroport
possède un code et un nom (annexe 5).
Chaque vol est identifié par un numéro. Un vol a lieu à certaines dates, une seule fois
par jour, et possède toujours le même horaire. La liaison entre deux aéroports peut
être assurée plusieurs fois par jour par des vols différents. Un exemple de liste des
vols assurés par TRANSAIR à une date donnée est présenté en annexe 6.
Séquence 2
Le modèle
conceptuel de
données
Page 62
8 2955 TG PA 00
Séquence 2
Le modèle
conceptuel de
données
Page 63
Exercice 17
Gestion des terrasses (extrait du sujet officiel 2006)
Annexe à utiliser : Tarif des terrasses année 2005
Le service emplacements de la mairie de P. est responsable de la gestion de l’occu-

pation du domaine public par les établissements et les commerces de la ville. Cette
occupation du domaine public concerne notamment l'installation de terrasses de
bars ou restaurants.
En fin d’année, le service emplacements émet les avis des sommes à payer à desti-
nation des établissements (restaurants ou bars) exploitant des terrasses. L’élaboration
de ces documents est basée sur les éléments suivants :
8 2955 TG PA 00
– Les terrasses déclarées, pour l’année en cours, par les établissements. Une
terrasse est caractérisée par un type (terrasse permanente, terrasse semi-perma-
nente, terrasse d’été) et une surface. Une terrasse dépend d’un seul établissement.
À titre d’exemple, le tableau qui suit présente les terrasses dont l’occupation est
déclarée par l’établissement "Machicoulis" (dont le code est 52) au cours de l’année
2005.
Code terrasse Type Surface en m2 Date installation
521 Terrasse permanente 4 01/01/2005
522 Terrasse d’été 4 15/05/2005
– Les tarifs en vigueur, votés par le conseil municipal en début d’année, sont con-
signés dans un arrêté fourni en annexe. Le tarif appliqué pour une terrasse dépend
de son type et de la zone de tarification de l’établissement. Le territoire de la ville
est partagé en zones qui déterminent la tarification applicable en fonction de la
localisation de l’établissement. Ainsi, le coût d’une terrasse pour un bar éloigné du
centre ville est très inférieur à celui d’une terrasse d’un bar situé dans un quartier
piétonnier.
Au titre de l’année 2005, le "Machicoulis" (qui se trouve en zone A) devra acquitter
la somme de (126,50 * 4) + (42,97 * 4) soit 677,88 €.
Dans le cas de l’installation d’une terrasse en cours de période tarifaire, la somme à
payer sera calculée au prorata du temps restant jusqu’à la fin de cette période.
Séquence 2
– Les établissements occupant une terrasse située sur le domaine public.
Le modèle Chaque établissement est identifié par un code. Il est décrit par une appellation com-
conceptuel de merciale et une adresse. Il est rattaché à une seule zone de tarification.
données
– Les personnes physiques ou morales exploitant les établissements et rede-
Page 64
vables des sommes à payer. Il n’est pas rare qu’un exploitant ait la responsabilité de
plusieurs établissements. Pour chaque exploitant, le service emplacements connaît
son nom (ou raison sociale), son adresse et son téléphone.
Dans le cas où un établissement change d’exploitant en cours d’année, la somme

à payer est répartie entre l’ancien et le nouvel exploitant au prorata des temps
d’occupation. Il est possible qu’un exploitant cède un établissement puis en reprenne
l’exploitation sur une autre période.
Le "Machicoulis" a été exploité en 2004 par Pierre Jucas de janvier à mars, puis par la
société Govry d’avril à juin puis de nouveau par Pierre Jucas jusqu’à la fin de l’année.
Pierre Jucas va donc être facturé de l’occupation de la terrasse permanente pour 274
jours et la société Govry pour 91 jours. La société Govry va être facturée de l’occupa-
tion de la terrasse d’été pour 46 jours (du 15 mai à fin juin) et Pierre Jucas pour 77
jours (de début juillet au 15 septembre).
Dans la perspective du développement d’une application spécifique, cette étude de
l’existant est complétée par le recensement des fonctionnalités que devra offrir le
futur logiciel. Le résultat de cette étape fait apparaître les quatre besoins suivants :
– tenir à jour la liste des établissements et notamment pouvoir retrouver tous les
exploitants successifs d’un établissement. Cette exigence est nécessaire pour calcu-
ler les sommes à payer par chaque exploitant ayant eu la responsabilité d’un éta-
blissement au cours de l’année ;
8 2955 TG PA 00
– t enir à jour la liste des terrasses. Seules les terrasses de l’année en cours devront être
gérées par l’application ;
–e
nregistrer en début d’année les nouveaux tarifs. L’historique de la base tarifaire
n’est pas souhaité ;
– éditer les avis des sommes à payer.
Travail à faire
Concevoir le schéma entité-association représentant les besoins informationnels de la
gestion des terrasses.
Annexe : Tarif des terrasses année 2005

Mairie de P. - Service Emplacements - Cellule 118 - Mél : emplacements@ville-p.fr
T
OCCUPATION COMMERCIALE DU DOMAINE PUBLIC
e

TARIFS 2005
r
> Terrasse permanente (du 1er janvier au 31 décembre - 365 jours) r
a
Zone Tarif (en € / m2) Séquence 2
s
A 126,50 Le modèle
conceptuel de
B 106,36 données
s
C 74,74
Page 65
e
> Terrasse semi-permanente (du 1er avril au 31 octobre - 214 jours)
Zone Tarif (en € / m2)
A
B
74,16
62,36 s
C 43,82
> Terrasse d'été (du 15 mai au 15 septembre - 123 jours)

2
0
Zone Tarif (en € / m2)
A 42,97
C
B 36,14
25,39 0
5
8 2955 TG PA 00
Exercice 18
Cas triathlète (sujet officiel 2000)
Le CDTVL souhaite disposer d’un logiciel de gestion des triathlons qu’il organise. Les
informations à prendre en compte sont décrites ci-dessous.
Les triathlètes
Chaque triathlète possède une licence délivrée par la Fédération française de tria-
thlon. Le numéro de licence identifie un sportif et reste identique d’une année à
l’autre.
Il existe deux types de licence : licence "club" et licence "individuelle". En effet,
un triathlète n’est pas obligatoirement membre d’un club. Un sportif qui n’est pas
membre d’un club s’inscrit aux compétitions de manière individuelle.
Les deux modèles de licence se présentent ainsi :
Licence Club Licence individuelle

Séquence 2
Le modèle
conceptuel de
données
Page 66
Remarques :
– L a date de 1re licence est la date à laquelle le triathlète a été licencié pour la pre-
mière fois.
– Si un triathlète change de statut (membre d’un club devenant individuel par
exemple), son numéro de licence reste inchangé.
8 2955 TG PA 00
Tout triathlète appartient à une catégorie d’âge (benjamin, minime, cadet, junior,
senior, vétéran). Chaque catégorie est identifiée par un code. Chaque catégorie est
caractérisée par l’âge auquel elle débute et l’âge auquel elle se termine.
Tous les clubs ayant des triathlètes inscrits à des compétitions organisées par le CDTVL
sont répertoriés. Un club est identifié par un numéro et possède un nom, une adresse
et un numéro de téléphone. Il est également nécessaire de connaître le nom des
entraîneurs du club : ces entraîneurs sont toujours des triathlètes membres du club
qu’ils entraînent.
Les triathlons
Un triathlon est une compétition ouverte à toutes les catégories d’âge.
Il existe plusieurs types de triathlon, chaque type de triathlon se distingue des autres
par les distances à parcourir dans les trois sports de base (natation, cyclisme et course
à pied). Chaque type de triathlon est identifié par un code et possède une désigna-
tion. À titre d’exemple, le code TROP correspond à un triathlon olympique.
Chaque triathlon possède un numéro, un nom, un type et se déroule en un lieu précis
à une date donnée. Par exemple, le triathlon numéro 12, nommé "Course folle", se
déroule à Orléans le 26 juin 2000 ; il s’agit d’une compétition de type TROP.
Le déroulement de la compétition
Dès que l’organisation d’un triathlon a été publiée par le CDTVL, les triathlètes
peuvent s’y inscrire. À l’inscription, un numéro de dossard est attribué au triathlète
pour la compétition et sa date d’inscription est mémorisée. Une inscription est iden- Séquence 2
tifiée par le numéro du triathlon concerné suivi du numéro de dossard attribué au
Le modèle
triathlète. Les inscriptions sont closes 15 jours avant la date de la compétition. conceptuel de
Le jour du triathlon, le CDTVL recense les participants à la course. Il arrive qu’un données
sportif inscrit ne se présente pas, il est alors déclaré forfait.
Page 67
Après le déroulement de la course, les résultats obtenus par chaque participant sont
relevés :
– classement du concurrent dans la catégorie (premier, second…) ;
– temps réalisé dans les différentes épreuves (natation, course cycliste, course à pied).
Le cas des abandons en cours d’épreuve sort du cadre de cette étude et n’est donc
pas à prendre en compte.
Les contrôles anti-dopage
Dans le cadre de la lutte anti-dopage, la fédération nationale expérimente de nou-
veaux contrôles à l’issue d’une compétition de triathlon.
Un contrôle consiste à vérifier l’absence de produits dopants dans le sang.
Un produit dopant est identifié par un code, possède un libellé et un taux maximum
autorisé par millilitre de sang.
Lors d’un triathlon, certains triathlètes, identifiés par leur numéro de dossard, sont
contrôlés. On effectue donc des prélèvements sanguins et un laboratoire indépen-
dant analyse ces prélèvements. Dès qu’elles sont connues, on enregistre les mesures
établies par le laboratoire pour chacun des produits dopants recherchés.
Travail à faire
Présenter le schéma entité-association permettant de prendre en compte l'ensemble
des règles de gestion relatives à la gestion des triathlètes, l'organisation des triath-
lons et les contrôles anti-dopage.
8 2955 TG PA 00
Exercice 19
Cas Thali (sujet officiel 2008)
THALI est un centre de thalassothérapie situé au bord de l’Océan Atlantique. Il ac-
cueille des clients en cure toute l’année et dispose d’un hôtel pour l’hébergement des
curistes qui le souhaitent.
THALI a choisi de fermer ses portes pendant trois mois pour rénover entièrement ses
locaux, acquérir de nouveaux équipements et refondre son système d’information.
Annexes à utiliser : 1A et 1B
Les prestations
THALI offre à ses clients deux types de prestation : des cures sur six jours et des week-
ends de soin. Son catalogue s’est enrichi au fil des années permettant aujourd’hui de
proposer :
– les cures bien-être, remise en forme, santé, amincissement, postnatale, anti-âge,
santé du dos et santé des jambes ;
– les week-ends détente et beauté-fraîcheur.
Toutes les prestations sont caractérisées par une description qui met en évidence leurs
vertus. Chaque prestation est identifiée par un code.
Ces prestations se composent d’un certain nombre de soins tels le massage tonique, le
massage anti-stress, le drainage lymphatique corps, le drainage lymphatique visage,
Séquence 2 le bain hydromassant, la douche abdominale, l’enveloppement de boues d’algues
marines, etc. Chacun d’eux est identifié par un code et se caractérise par une durée
Le modèle estimée.
conceptuel de
données Seules les cures sont caractérisées par un certain nombre d’objectifs qui sont codifiés ;
certains objectifs sont communs à plusieurs cures.
Page 68 L’annexe 1A présente la cure bien-être avec sa description, ses objectifs et les soins
prodigués. Les tarifs des prestations sont également présentés pour l’année 2008 ;
l’ensemble des tarifs est conservé au minimum sur deux années.
Pour certaines cures, une visite médicale est imposée.
Il est également possible qu’une cure donne lieu à remboursement lorsqu’elle fait
l’objet d’une prescription médicale.
Des critères spécifiques ont été définis afin d’évaluer les bienfaits de chaque cure. Par
exemple, pour la cure amincissement, codifiée AM55, les critères suivants ont été éta-
blis pour les bilans : tour de taille (AM551), tour de hanche (AM552) et tour de cuisse
(AM553).
L’hébergement
Un hébergement en pension complète est proposé aux clients et aux personnes les
accompagnants pendant les cures ou les week-ends. Comme pour les prestations de
thalassothérapie, les prix varient en fonction de la saison et de l’année. Ils sont con-
servés au minimum sur deux années.
Le tableau des tarifs pour 2008 est présenté dans l’annexe 1B.
Travail à faire
À partir des informations fournies dans ce dossier et de l’annexe 1, construire le sché-
ma entité-association relatif aux services proposés par le centre de thalassothérapie et
leur tarification.
8 2955 TG PA 00
Annexe 1A : Cure "bien-être"
Description
Destiné à toute personne recherchant forme, vitalité et bien-être, ce programme va
contribuer à un ressourcement général. Après une période d'activité intense, qu'elle
soit d'ordre psychique, physique ou intellectuelle, le corps a besoin de retrouver son
énergie. Dans cette cure, les soins à base d'eau de mer et d'algues seront privilégiés afin
de vous faire profiter au maximum des oligo-éléments et vitamines qu'ils contiennent.
Massages et relaxation seront également au programme pour vous apporter cette
détente indispensable à une remise en condition optimale.
Soins
3 massages normaux, 3 massages relaxants, 3 douches à affusion, 3 bains bouillon-
nants algués, 1 soin hydratant du visage, 3 enveloppements d’algues, 3 douches sous-
marines, 3 bains hydromassants, 1 manucure et 1 soin des pieds.
Objectifs
• Ressourcement général.
• Entretien d'un bon état de santé.
Tarifs en euros de la cure “Bien-être” pour 2008 :
Séquence 2
Le modèle
conceptuel de
données
Page 69
Annexe 1B : Tarifs journaliers en euros de l'hébergement en pension complète

pour 2008
Les tarifs diffèrent notamment selon la situation de la chambre (vue sur la mer, le jar-
din ou la rue).
8 2955 TG PA 00
Synthèse
O Cseette synthèse rappelle les termes utilisés dans cette séquence mais ne peut
substituer à l'étude attentive de la séquence, en particulier de tous les cas
exposés dans le mémento du MCD.
MCD (Modèle Conceptuel de Données) : c'est un des modèles de la méthode

Merise. Il permet une représentation graphique du modèle relationnel.
Entité : représentation graphique d'une relation en 3NF dont la clé primaire n'est
composée que d'un seul attribut élémentaire. L'entité est une représentation du
réel (personne, chose, lieu…).
Association : représentation graphique d'une relation en 3NF dont la clé primaire
est composée d'au moins 2 attributs élémentaires. L'association permet de créer un
lien entre plusieurs entités.
CIF (Contrainte d'Intégrité Fonctionnelle) : elle traduit une dépendance fonction-
nelle entre 2 clés primaires. C'est une association particulière qui se traduit par une
clé étrangère dans le modèle relationnel.
Séquence 2
Cardinalités : elles permettent d'exprimer le nombre minimum et maximum d'oc-
Le modèle currences d'une entité par rapport à une autre (liées par une association).
conceptuel de Héritage : il permet de représenter des sous-types d'entités afin de tenir compte
données
de cas particuliers.
Page 70 Intégrité fonctionnelle : elle traduit une dépendance forte entre des objets. Les
SGBDR gèrent généralement les intégrités fonctionnelles automatiquement dès
que des clés étrangères sont définies, et limitent ainsi les erreurs de manipulations.
Lien identifiant : il traduit une dépendance forte entre 2 entités, l'identifiant de
l'entité faible est alors constitué de son propre identifiant + celui de l'entité forte.
Il permet d'éliminer les entités "numéro" et la plupart des entités temporelles.
Agrégation : elle offre une représentation visuelle d'une association sur une autre
(elle reprend donc les identifiants d'une autre association).
8 2955 TG PA 00
Séquence 3
Extensions sous Merise/2
Cette séquence aborde l’ensemble des extensions apportées à la méthode
Merise. Vous en connaissez certaines et vous allez en découvrir d’autres.
Ces extensions sont couramment utilisées et vont vous servir pour aborder
la programmation directement intégrée dans un SGBDR.
u Prérequis
Avoir totalement acquis les connaissances abordées dans la séquence 2 : savoir construire
un schéma conceptuel de données d’une certaine complexité.

Savoir construire un schéma conceptuel de données complexe en intégrant les exten-
sions de Merise/2 et plus particulièrement les contraintes.
u Contenu
1. Qu’est-ce que Merise/2 ....................................................................................... 72
2. Les sous-types sur association ........................................................................... 73
3. Les contraintes ..................................................................................................... 75
4. Exercices récapitulatifs ........................................................................................ 87
Page 71
Synthèse .............................................................................. 107
8 2955 TG PA 00 8 2955 TG PA 00
1. Qu’est-ce que Merise/2 ?
Vous avez pu apprécier l’intérêt d’utiliser une méthode d’analyse, en particulier la
méthode Merise qui a été précédemment étudiée. Cette méthode vous a apporté, au
niveau des données, les outils nécessaires pour optimiser l’organisation des informations
qui sont ensuite enregistrées dans une base de données et exploitées dans une appli-
cation. Tout en étant d’une grande efficacité, la méthode Merise s’avère incomplète
ou inefficace dans certains domaines. Ces problèmes ont été résolus en apportant des
compléments à la méthode d’origine. Ces compléments s’appellent des "extensions" et
la nouvelle méthode s’appelle Merise/2.
Vous avez déjà abordé certaines de ces extensions dans la séquence précédente et dans
le cours 2949 "Exploitation d’un schéma de données", cependant elles sont toutes réex-
pliquées dans cette séquence.
Cette séquence va donc vous présenter l’essentiel des extensions apportées au MCD.
Intérêt des extensions

Les extensions ont différentes utilités :
• Certaines apportent une solution à des problèmes non résolus (les sous-types sur
association). Pour le moment, il est possible de gérer des attributs spécifiques dans
une entité, mais pas dans une association.
• Certaines permettent de simplifier les formalismes un peu lourds (les agrégations
et les liens identifiants). Comment relier directement 2 associations. Comment
Séquence 3 éliminer certaines entités spatio-temporelles...
Extensions sous • Certaines permettent de visualiser des contraintes jusque là ignorées au niveau des
Merise/2 données ou à peine mentionnées par des commentaires accompagnant le schéma
(les contraintes). Par exemple : "Un salarié ne peut être à la fois animateur et par-
Page 72 ticipant à un même stage."
Vous avez déjà étudié en détail les liens identifiants et les agrégations. Ces deux notions
ne seront donc pas revues. Pourquoi les avoir étudiées à l’avance ? Parce que ces
2 notions sont plutôt simples et surtout apportent une aide réelle à la construction d’un
schéma plus lisible. Dans la suite de cette séquence, seuls les sous-types sur association et
surtout les contraintes seront étudiées : deux notions totalement nouvelles pour vous.
Cependant, dans la partie synthèse de la séquence, les liens identifiants et les agréga-
tions sont rappelés car ils font partie de Merise/2. Voici tout de même deux exercices qui
portent sur les liens identifiants et les agrégations, en guise de révision.
Exercice 1
Une agence de voyages organise des séjours à thème. Un séjour est repéré par une
destination principale et une date (il ne peut pas y avoir 2 séjours différents pour
une même destination et une même date). Les destinations possibles sont des villes,
situées dans des pays. Pour chaque séjour, il faut mémoriser la durée en nombre de
jours, le tarif, le type de séjour (historique, scientifique, sportif, festif, reposant...)
ainsi que la liste des activités prévues pour le séjour. Chaque activité est numérotée
par séjour (première activité du séjour, seconde activité du séjour...). Il faut mémo-
riser le nom de l’activité ainsi que son tarif (les activités sont souvent payantes). Il
arrive que certaines activités soient découpées en sous-activités : il faut alors mémo-
riser l’ordre des sous-activités et leur nom. Suivant les séjours, certaines options sont
proposées (chambre individuelle, pension complète...). Ces options peuvent être
sélectionnées pour différents séjours.
Construire le SCD correspondant. Écrire les relations qui en découlent.
8 2955 TG PA 00
Exercice 2
Une pizzeria veut créer un site pour informatiser ses commandes. Une personne
pourra passer commande en précisant les pizzas désirées. Les pizzas sont présen-
tées sur le site avec un nom, une liste d’ingrédients et un prix qui varie suivant la
taille (petite, moyenne, grande). Pour chaque pizza commandée il faudra préciser
la taille (sachant qu’on peut commander plusieurs fois la même pizza à des tailles
différentes), la quantité et la liste des suppléments éventuels (qui sont en fait des
ingrédients). Si plusieurs pizzas de même type et de même taille sont commandées,
les suppléments sont les mêmes. Pour pouvoir passer commande, une personne doit
créer un compte, en laissant son nom, prénom, adresse, téléphone et adresse mail.
Le paiement se fait en ligne ou à la livraison : il faut juste mémoriser si la commande
est payée ou non. Pour chaque commande, il faut aussi mémoriser la date et l’heure
de la commande ainsi qu’un booléen pour savoir si la commande est livrée ou non.
Incidences de ces extensions

Les sous-types sur association ont une incidence similaire aux sous-types sur entité : ils
modifient la structure des données, donc la base de données.
Les agrégations et les liens identifiants optimisent les liens entre les données : ils ont
donc une incidence sur la gestion des clés étrangères.
Les contraintes ont une incidence au niveau des traitements : elles se traduiront soit
Séquence 3
directement dans le code de l’application, soit plus classiquement dans le code de la base
de données, sous forme de triggers ou de procédures stockées (abordés plus loin dans Extensions sous
ce cours). Merise/2
Voici de façon plus détaillée les 4 extensions : les liens identifiants, les agrégations, les
Page 73
sous-types sur associations et surtout les contraintes.
2. Les sous-types sur association

Rappelez-vous que le principe du sous-type (ou héritage) est d’éviter les attributs qui
peuvent rester vides dans certains cas.
Les sous-types sur association respectent les mêmes règles.
Voyons un exemple. Vous voulez mémoriser le planning de réservation d’un gymnase. A
priori, vous devriez obtenir dans un premier temps, ceci :
GYMNASE HORAIRE
1,n PLANNING 0,n
idGymnase date_heure
durée
nom
adresse
Petite remarque : l’identifiant de HORAIRE est volontairement date_heure, ce qui ne

signifie pas qu’il y a plusieurs attributs mais un seul qui donne la date et aussi l’heure
précise. Dans les SGBDR, vous avez toujours un type DateTime qui permet d’avoir en une
fois la date et l’heure.
Maintenant, compliquons le sujet : le gymnase peut être réservé soit pour des manifesta-
tions sportives (il faut alors connaître le titre de la manifestation et l’organisateur), soit
pour des entraînements (il faut alors juste connaître le sport pour préparer le matériel
nécessaire).
8 2955 TG PA 00
Sans sous-type, on serait obligé de faire comme ceci :
GYMNASE HORAIRE
1,n PLANNING 0,n
durée
nom
titre
adresse
ORGANISATEUR 0,1 0,1 SPORT

0,n 0,n
idOrganisateur idSport
nom nom
adresse
Avec cette représentation, l’attribut titre restera vide dans certains cas. Même problème
pour les clés étrangères (d’où les cardinalités 0,1). Pour éviter ces attributs vides, il est
possible de gérer des sous-types sur association :
GYMNASE HORAIRE
1,n PLANNING 0,n
nom durée
adresse
Séquence 3 MANIFESTATION ENTRAINEMENT
Extensions sous titre

Merise/2
Page 74 ORGANISATEUR 1,1 1,1 SPORT

idOrganisateur 0,n 0,n idSport
nom nom
adresse
Les sous-types sur association restent exceptionnels car, très souvent, l’association d’ori-
gine peut se transformer en entité. Par exemple, ici, il est possible d’éliminer HORAIRE
par un lien identifiant.
Exercice 3
Dans un magasin spécialisé dans la vente d’ordinateurs, les clients peuvent passer
commande pour plusieurs produits. La date de la commande doit être mémorisée.
Pour chaque produit vendu dans une commande, il faut mémoriser la durée de
garantie prise par le client. Compte tenu de la spécificité des produits, il n’y a pas de
quantité à enregistrer (le produit est à chaque fois vendu en un seul exemplaire). Le
client peut décider, pour certains produits, de prendre un contrat supplémentaire.
Il existe plusieurs types de contrats (installation à domicile, pack formation, pack
dépannage...). Donc, dans le cas où le client prend un produit avec un contrat, il faut
mémoriser le type de contrat, la date d’effet, la durée, le montant (qui souvent est
négocié).
8 2955 TG PA 00
3. Les contraintes
Les contraintes représentent l’ajout le plus important dans les extensions Merise. Vous
ne les avez pas du tout abordées dans le cours précédent.
Introduction
Les contraintes permettent d’apporter des informations complémentaires sur les liens et
dépendances entre les objets. Jusque là, elles étaient occultées ou, au mieux, précisées
textuellement, à côté du MCD. Merise/2 permet maintenant de les intégrer de façon
symbolique directement dans le schéma. Ces contraintes n’ont aucune incidence sur le
modèle relationnel. C’est au niveau de la programmation qu’elles interviennent : soit
directement dans le code, soit sous forme de triggers dans la base de données. La notion
de trigger est abordée plus loin dans ce cours.
Couverture/disjonction
Plusieurs contraintes sont basées sur la combinaison de 2 notions fondamentales : la
couverture et la disjonction.
Couverture : chaque tuple se trouve dans au moins un objet.
objet 1
objet 2 Séquence 3
Extensions sous
Merise/2
Page 75
Exemple : il existe des stages qui portent sur une matière, d’autres stages qui sont spéci-
fiques à la préparation d’un examen, et enfin des stages qui ont les 2 vocations, mais il
n’existe pas d’autres catégories de stage.
Il y a aussi couverture même si aucun tuple n’est en commun. L’important est que tous
les tuples soient dans les objets, aucun à l’extérieur.
C’est donc la partie blanche du dessin ci-dessus qui est formellement interdite.
Disjonction : chaque tuple se trouve dans au plus un objet.
objet 1
objet 2
8 2955 TG PA 00
Exemple : Un personnel peut être enseignant ou administratif, pas les 2 à la fois mais
éventuellement il peut être d’une autre catégorie (par exemple personnel d’entretien).
Il y a aussi exclusion quand tous les tuples sont dans les objets. L’important est qu’il n’y
ait aucun tuple en commun entre les objets.
C’est donc encore une fois la partie blanche du dessin ci-dessus qui est formellement
interdite.
Exclusion
La contrainte d’exclusion respecte la règle suivante :
Chaque identifiant se trouve dans au plus un objet (disjonction) et certains
tuples ne font partie d’aucun objet (non couverture).
exclusion = non(couverture) + disjonction
Exclusion sur héritage

L’exclusion peut se faire entre plusieurs sous-types.
Reprenons l’exemple précédent sur les sous-types des personnels.
Le personnel se décompose en plusieurs catégories : les professeurs (dont on veut mémoriser le
nombre d’heures et les matières enseignées), les administratifs (dont on veut mémoriser la date
d’affectation et le service concerné). Il existe d’autres catégories de personnels pour lesquelles il n’y
a pas d’informations spécifiques (juste les informations basiques : nom, prénom, adresse, téléphone
et email).
Séquence 3
PERSONNEL
Extensions sous idPersonnel
Merise/2
nom
prenom
Page 76 adresse
tel
email
x
ADMINISTRATIF PROFESSEUR MATIERE
1,n MATIERE_PROF 0,n
dateAffectation nbHeures idMatiere
nom
1,1
SERVICE
0,n
idService
nom
La contrainte d’exclusion est représentée par une croix ("X") dans un losange (ou
dans un rond) avec des branches pour s’accrocher aux liens d’héritage. Il y a autant de
branches que de liens d’héritage concernés.
8 2955 TG PA 00
O Isous-type.
l ne peut pas y avoir de contrainte sur un héritage si l’héritage ne comporte qu’un
En revanche, à partir de 2 sous-types, la contrainte devient obligatoire
(sauf si aucune contrainte ne correspond, ce qui est très rare).
Exclusion sur association
Il est possible aussi de trouver une contrainte d’exclusion entre 2 associations.
n enseignant peut participer à des stages. Il peut aussi être formateur de certains stages.
U
Mais pour un même stage, il ne peut pas être à la fois stagiaire et formateur. Certains ensei-
gnants ne sont ni stagiaire, ni formateur pour certains stages.
FORMATEUR
0,n 0,n
ENSEIGNANT STAGE
idEnseignant idStage
x
nom titre
tel 0,n durée
0,n
STAGIAIRE
La contrainte se traduit ainsi :

"Un couple idEnseignant+idStage ne peut pas être à la fois présent dans STAGIAIRE et Séquence 3
dans FORMATEUR. Il peut aussi n’être présent dans aucun des 2."
Extensions sous
Merise/2
Exercice 4
Un restaurant propose sur sa carte différents produits : des boissons, des plats et des Page 77
menus. Tous les produits ont un nom et un prix. Les plats possèdent une liste d’ingré-
dients précisés sur la carte et sont classés dans une catégorie (entrée, plat, dessert).
Les menus précisent une liste de plats proposés. Certains menus sont réservés au
repas du midi : il n’est donc pas possible de les commander le soir.
Pivot
À cette notion de contrainte sur association, se rajoute une notion supplémentaire appe-
lée "pivot".
Un pivot permet de dire quel identifiant est concerné par la contrainte.
Pour mieux comprendre, reprenons la traduction donnée pour la contrainte précédente :
"Un couple idEnseignant/idStage ne peut pas être à la fois présent dans STAGIAIRE et
dans FORMATEUR. Il peut aussi n’être présent dans aucun des 2."
Il est clairement dit que les identifiants concernés sont idEnseignant et idStage. Pour
représenter cette implication des 2 identifiants, on la symbolise par des pointillés qui
représentent donc les pivots de la contrainte :
8 2955 TG PA 00
FORMATEUR
0,n 0,n
ENSEIGNANT STAGE
nom
x titre
tel 0,n 0,n durée
STAGIAIRE
Voici la phrase type pour lire une contrainte avec pivot :

Il y a <contrainte> entre <les associations> sur <le pivot>.
Dans l’exemple précédent, cela donne :
Il y a exclusion entre FORMATEUR et STAGIAIRE sur idEnseignant+idStage.
O Ltions
orsque les pivots concernent toutes les entités sur lesquelles portent les associa-
de la contrainte, alors ils sont optionnels. Donc la représentation précédente
est équivalente à la représentation sans pointillés.
Pour mieux comprendre l’importance des pivots, voyons justement d’autres possibilités
sur le même exemple.
Voici une première possibilité :
Séquence 3
FORMATEUR
Extensions sous
Merise/2 0,n 0,n
ENSEIGNANT STAGE
Page 78
nom
x titre
tel 0,n 0,n durée
STAGIAIRE
Que signifie cette version ? En appliquant la règle vue précédemment sur le pivot, cela
donne :
Il y a exclusion entre FORMATEUR et STAGIAIRE sur idStage.
Donc, si un idStage est présent dans FORMATEUR, il ne peut pas être présent dans
STAGIAIRE, et vice versa.
Donc, si un idEnseignant est présent dans FORMATEUR, il ne peut pas être présent dans
En français, cela donne : "Si un enseignant est formateur une fois, il ne pourra plus
jamais être stagiaire, et vice versa.". Bien sûr, là encore ce n’est pas logique, mais si le
pivot était ainsi positionné, cela se traduirait par cette contrainte.
8 2955 TG PA 00
Voici une seconde possibilité :
FORMATEUR
0,n 0,n
ENSEIGNANT STAGE
x
nom titre
tel 0,n 0,n durée
STAGIAIRE
Que signifie cette version ?

Il y a exclusion entre FORMATEUR et STAGIAIRE sur idEnseignant.
Donc, si un idEnseignant est présent dans FORMATEUR, il ne peut pas être présent dans
En français, cela donne : "Si un enseignant est formateur une fois, il ne pourra plus ja-
mais être stagiaire, et vice versa.". Bien sûr, là encore ce n'est pas logique, mais si le pivot
était ainsi positionné, cela se traduirait par cette contrainte.
Vous comprenez donc l’importance du pivot qui change complètement le sens de la
contrainte. Avec l’exemple précédent, vous vous dites peut-être que, comme ça n’a pas
de sens de mettre un seul pivot, autant les mettre tous (ou aucun). Attention, ce n’est pas Séquence 3
parce que, dans cet exemple, un seul pivot n’est pas logique, que ça ne peut pas l’être
dans d’autres cas. Extensions sous
Merise/2
Voici un exemple :
Une facture peut générer des avoirs qui seront alors reportés sur d’autres factures. Une Page 79
facture qui génère un avoir ne peut en même temps comptabiliser des avoirs.
0,n 1,1
FACTURE AVOIR
idFacture x idAvoir
date montant
0,n 0,n
AFFECTATION
Cet exemple est aussi là pour rappeler qu’une CIF est une association, donc elle peut
aussi porter une contrainte.
O Qpartie
uels que soient les pivots sélectionnés, faites attention qu’ils fassent FORCÉMENT
des identifiants des deux associations concernées par la contrainte.
8 2955 TG PA 00
Exercice 5
Suivant le type de pathologie, certains médicaments sont conseillés, d’autres sont
totalement proscrits. Pour chaque médicament conseillé, il faudra mémoriser la
posologie.
Partition
La contrainte de partition respecte la règle suivante :
Chaque identifiant se trouve dans au plus un objet (disjonction) et aussi au
moins un objet (couverture).
partition = couverture + disjonction
Partition sur héritage
La partition peut se faire entre plusieurs sous-types.
Exemple :
Un message est soit urgent, soit normal, il ne peut bien sûr pas être les 2 et il ne peut
pas être autre chose. Un nombre de rappels automatiques est programmé pour les mes-
sages urgents. Les messages normaux sont classés dans des catégories (rv, information,
technique...).
MESSAGE
Séquence 3
idMessage
Extensions sous date
Merise/2 heure
titre
Page 80 contenu
+
URGENT NORMAL CATEGORIE
1,1 0,n
nb_rappels idCategorie
nom
La contrainte de partition est représentée par un "+" ou par "XT" (qui signifie exclusion
et totalité à la fois : vous verrez la contrainte de totalité juste après celle-ci).
Partition sur association
Il est possible aussi de trouver une contrainte de partition entre 2 associations :
"Des analyses sont régulièrement faites sur les eaux directement récupérées en rivière
(captage) et les eaux stockées dans des réservoirs. Une analyse porte soit sur un captage,
soit sur un réservoir et obligatoirement sur l’un des deux."
8 2955 TG PA 00
CAPTAGE
0,n
0,1 idCaptage
ANALYSE débit
idAnalyse
date +
résultat 0,1
RESERVOIR
idReservoir
0,n capacité

"idAnalyse ne peut pas être à la fois présent dans l’une et l’autre CIF. Il est forcément
présent dans l’une des 2."
Comme ce sont des CIF, elles se traduisent par des clés étrangères dans ANALYSE : il y
aura donc 2 clés étrangères : une en relation avec CAPTAGE et l’autre en relation avec
RESERVOIR. Cette contrainte traduit donc le fait qu’il y aura, pour chaque analyse, for-
cément une des 2 clés étrangères remplie (couverture) mais certainement pas les 2 à la
fois (disjonction).
Dans cet exemple, il n’y a pas d’ambiguïté possible sur le pivot : le seul pivot possible
(commun aux 2 associations) est forcément idAnalyse. Il est donc inutile de le représen-
ter : c’est le pivot par défaut. Cependant, ce n’est pas faux de le représenter :
CAPTAGE Séquence 3
0,n
0,1 idCaptage Extensions sous
ANALYSE débit Merise/2
idAnalyse
date + Page 81
résultat 0,1 RESERVOIR

0,n idReservoir
capacité
Remarque
Ce cas de figure aurait très bien pu être géré par un héritage : deux entités filles, analyse
sur captage et analyse sur réservoir. Du coup, on aurait alors géré de simples CIF (avec
cardinalités 1,1) partant de chacune des filles.
La solution sans héritage est, dans ce cas, moins lourde car elle évite la création de
2 tables supplémentaires. Chaque type d’analyse ne portant pas d’informations spéci-
fiques, excepté les 2 CIF, cela aurait été dommage de créer des tables supplémentaires.
De manière plus générale, face à un héritage, il faut se poser la question de la solution
la plus adaptée. Parfois les 2 solutions sont tout à fait défendables.
Exercice 6
Une agence de location de véhicules propose 3 types de véhicules : les véhicules
légers, les utilitaires, les camions. Pour les véhicules légers, le modèle et la marque
sont renseignés, ainsi que le nombre de CV. Pour les utilitaires, la capacité en mètres
cubes est précisée. Enfin, pour les camions, le tonnage et la hauteur sont donnés.
Pour chaque type de véhicule, une photo est proposée.
8 2955 TG PA 00
Totalité
La contrainte de totalité respecte la règle suivante :
Chaque identifiant se trouve dans au moins un objet (couverture) et certains
tuples peuvent faire partie de plusieurs objets à la fois (non disjonction).
totalité = couverture + non(disjonction)
Totalité sur héritage
La totalité peut se faire entre plusieurs sous-types.
Exemple :
Certains stages sont spécifiques à la préparation d’un examen. Certains stages portent
sur une matière précise. Un stage peut aussi avoir les 2 rôles. Il n’y a pas d’autres types
de stages.
STAGE
idStage
EXAMEN titre MATIERE
date
idExamen nbPlaces idMatiere
nom nom
T
0,n 0,n
Séquence 3
STAGE EXAM STAGE MATIERE
1,1 1,1
Extensions sous
Merise/2
La contrainte de totalité est représentée par un "T".
Page 82
Totalité sur association
Il est possible aussi de trouver une contrainte de totalité entre 2 associations :
n article est acheté auprès de fournisseurs ou fabriqué en ateliers. Il peut aussi être acheté
U
auprès de fournisseurs puis être transformé en ateliers. Il n’y a pas d’autres possibilités.
ACHAT FOURNISSEUR
0,n
0,n idFournisseur
ARTICLE nom
adresse
idArticle
nom T
prixVente 0,n ATELIER
FABRICATION 0,n idAtelier
nom
spécialité

"idArticle est forcément présent soit dans ACHAT, soit dans FABRICATION, soit dans les 2."
Encore une fois, dans cet exemple, il n’y a pas d’ambiguïté sur le pivot : le seul pivot
possible (commun aux 2 associations) est forcément idArticle. Sa représentation est donc
optionnelle.
8 2955 TG PA 00
Exercice 7
Une grande entreprise organise des séminaires. Chaque séminaire se fait à une date
précise. Il faut connaître aussi la durée (en nombre de jours) et le lieu. Un séminaire
peut être composé de séances de travaux pratiques et aussi de conférences. Une
conférence possède un titre. Il faut aussi connaître les conférenciers. Les travaux pra-
tiques comportent un objectif détaillé, une durée et un formateur. Les conférences
et les séances de travaux pratiques peuvent être intégrées dans plusieurs séminaires.
Cependant les intervenants ne changent pas. On mémorise le nom et le téléphone
de chaque intervenant. Un intervenant peut très bien intervenir au niveau des TP
ou des conférences, ou même les deux. On enregistre les intervenants qu’à partir du
moment où ils sont intervenus au moins une fois.
À partir de maintenant, nous allons voir des contraintes qui n’utilisent plus les notions
de couverture et de disjonction. Ces contraintes ne peuvent pas non plus être utilisées
sur des héritages : elles ne portent que sur des associations.
Égalité ou simultanéité
La contrainte d’égalité (ou de simultanéité) respecte la règle suivante :
Si un identifiant (correspondant au pivot) est présent dans un objet, il est for-
cément présent dans l’autre, et vice versa. Séquence 3
Exemple :
Extensions sous
Une personne qui pratique un sport fait partie d’une équipe, et vice versa. Merise/2
SPORT PERSONNE SPORT Page 83

0,n
0,n idSport
PERSONNE nom
idPersonne
=
nom
adresse 0,n EQUIPE
EQUIPE PESONNE 0,n idEquipe
nom
La contrainte d’égalité (ou simultanéité) est représentée par un "=" (ou un "S").
"Si idPersonne est présent dans SPORT_PERSONNE, il est forcément présent dans
EQUIPE_PERSONNE, et vice versa."
Exercice 8
Dans une université, un professeur est responsable d’au moins un cours dès qu’il
a participé à au moins une publication. Plusieurs professeurs peuvent être respon-
sables du même cours. Un cours a un nom et un niveau requis. Il faut mémoriser le
titre et la date de chaque publication. Pour chaque professeur, il faut mémoriser son
nom, son téléphone, son adresse email et savoir si c’est un chercheur.
8 2955 TG PA 00
Inclusion
La contrainte d’inclusion respecte la règle suivante :
Si un identifiant (correspondant au pivot) est présent dans un objet, il est for-
cément présent dans l’autre, mais pas forcément réciproquement.
Cette fois, contrairement à l’égalité, il n’y a pas de réciprocité. Cette contrainte est très
courante. Pour montrer le sens de la contrainte, et donc de l’inclusion, il faut ajouter
une flèche.
Exemple :
Une personne inscrite à un stage a dù en faire la demande préalable. Toutes les
demandes de stage ne sont pas forcément satisfaites.
DEMANDE
PERSONNE 0,n 0,n STAGE

idPersonne idStage
nom
I titre
tel 0,n 0,n durée
INSCRIPTION
présence
Séquence 3
O Attention à la flèche qui est obligatoire !
Extensions sous La contrainte d’inclusion est représentée par un "I".
Merise/2 La contrainte se traduit ainsi :
"Si le couple idPersonne+idStage est présent dans INSCRIPTION, il est forcément présent
Page 84
dans DEMANDE."
Exercice 9
Le rédacteur en chef d’un journal s’occupe de récupérer un ensemble d’articles
candidats à la publication dans chaque rubrique du journal. Ce sont les auteurs des
articles qui proposent leurs articles en précisant la ou les rubriques concernées. Donc
un même article peut être candidat dans plusieurs rubriques. Le rédacteur en chef
réunit alors un comité qui s’occupe de faire un tri et de choisir les articles qui leur
paraissent les plus adaptés pour être publiés. Le comité donne aussi un classement
de préférence pour les articles choisis par rubrique. Un même article peut être choisi
dans plusieurs rubriques différentes. Au final, c’est le rédacteur en chef qui décide
des articles publiés, parmi les articles choisis, sachant qu’un même article ne peut
être publié que dans une rubrique. Pour chaque article, on mémorisera le titre, la
date, le contenu et l’auteur.
Inclusion à portée multiple

L’inclusion à portée multiple met en jeu au moins 3 associations. L’inclusion ne se fait
toujours que dans une seule association. Cela traduit juste le fait que les pivots doivent
parfois être récupérés dans des entités qui ne sont pas directement liées à l’association
de départ.
8 2955 TG PA 00
Un exemple va certainement permettre de mieux comprendre le principe :
Une personne peut conduire un véhicule que si elle possède le bon permis.
CONDUIT VEHICULE
0,n
0,n idVehicule
immatriculation
PERSONNE 1,1
idPersonne I
nom
0,n
adresse
0,n PERMIS
PERMIS PERSONNE
0,n idPermis
description

"Le couple idPersonne+idPermis formé en passant par CONDUIT et la CIF entre VEHICULE
ET PERMIS, doit être présent dans PERMIS_PERSONNE."
O Iaux
l faut que les liens directs qui forment la base de l’inclusion permettent d’accéder
pivots. La flèche reste unique.
Séquence 3
Cette contrainte est assez courante : vous aurez l’occasion de la pratiquer dans plusieurs Extensions sous
exercices issus des sujets d’examen. Merise/2
Exercice 10 Page 85
Un stage porte sur un ensemble de compétences. Un formateur possède un ensemble

de compétences. Plusieurs formateurs peuvent intervenir sur un même stage, à
condition bien sûr qu’ils aient toutes les compétences requises.
Unicité
La contrainte d’unicité est en fait une autre représentation de la CIF partant d’une asso-
ciation. Vous devez donc connaître les 2 représentations. Personnellement je préfère
la CIF qui traduit à chaque fois une clé étrangère. La contrainte d’unicité est la seule
contrainte qui a du coup une influence sur le modèle relationnel puisqu’elle se traduit,
comme la CIF, par une clé étrangère.
Exemple :
Plusieurs personnels peuvent intervenir en qualité de formateur sur un stage. Pour
chaque intervention, il faut connaître la durée en nombre d’heures et le type d’interven-
tion (cours magistral, travaux dirigés, travaux pratiques ...).
8 2955 TG PA 00
Voici la représentation avec le CIF sur association :
FORMATEUR STAGE
0,n
0,n durée idStage
titre
1,1 date
PERSONNEL
idPersonnel 0,n TYPE INTERVENTION
nom idIntervention
tel libellé
Voici la représentation avec la contrainte d’unicité :
FORMATEUR STAGE
0,n
0,n durée idStage
0,n titre
date
1
PERSONNEL
idPersonnel TYPE INTERVENTION
nom
tel idIntervention
Séquence 3 libellé
Extensions sous
Merise/2
Attention, au niveau relationnel, FORMATEUR n’est pas une ternaire (association à 3
liens directs) : elle ne contient en réalité que 2 attributs en clé primaire et la contrainte
Page 86
d’unicité permet de récupérer la troisième clé en clé étrangère uniquement.
Certains font même une représentation avec 2 associations. Cette représentation est
encore plus lourde visuellement, sans compter le fait que la ternaire ne sera bien sûr pas
du tout traduite par une relation :
FORMATEUR STAGE
0,n
0,n durée idStage
titre
date
PERSONNEL 1
0,n
idPersonnel 0,n INTERV_FORMATEUR
nom
tel
0,n TYPE INTERVENTION
idIntervention
libellé
8 2955 TG PA 00
Ces 3 représentations sont totalement équivalentes.
Il existe encore d’autres variantes : certains mettent les branches de la contrainte direc-
tement sur les branches de l’association... L’idée est que vous soyez capable de vous
adapter à plusieurs lectures.
Exercice 11
Dans chaque classe, chaque cours est enseigné par un seul professeur. Pour chaque
classe, il faut connaître le volume horaire réservé pour chaque cours.
4. Exercices récapitulatifs
Tous ces exercices sont issus de sujets officiels. Les schémas sont plus ou moins importants
suivant les années, cependant ils contiennent forcément des notions de Merise/2. Le plus
difficile est généralement de bien comprendre le sujet.
Autre point primordial : vous avez, à travers cette séquence et la précédente, utilisé
une méthode précise en ayant un rapide aperçu des variantes existantes. Le but était
avant tout de vous apprendre à raisonner sur des sujets d’analyse. À travers ces sujets
d’examen, vous allez être confronté à plusieurs variantes : vous avez normalement
acquis le recul nécessaire pour vous adapter. Donc ne soyez pas surpris si vous voyez des
cif présentées sous forme d’association avec un verbe à l’intérieur : seule la cardinalité
vous permettra de repérer la cif. Quelle que soit la méthode présentée dans le sujet (qui Séquence 3
apparaît parfois dans des extraits de MCD donnés dans le sujet), rappelez-vous que vous Extensions sous
avez tout à fait le droit d’utiliser la variante de présentation de votre choix. Celle qui est Merise/2
la plus pratique pour vous et qui vous convient le mieux.
Dans ce type de sujet, vous êtes souvent confronté à des annexes : pensez à les lire en Page 87
détail ainsi que le sujet lui-même. Souvent les annexes contiennent des informations
primordiales, par exemple vous pouvez découvrir à travers un tableau exemple que la
numérotation est relative, donc qu’il faut faire un lien identifiant.
Dernière remarque avant de commencer : il arrive très souvent que les sujets officiels
comportent des erreurs. Rares sont les fois où ces erreurs sont signalées en cours de
composition (même si les professeurs voient l’erreur en lisant rapidement le sujet, il faut
avoir l’autorisation de Paris pour avertir les étudiants). Du coup, vous devez être capable
de vous en sortir tout seul. Mais ne vous inquiétez pas : faites simplement au mieux.
Quand une erreur est repérée, la correction est alors forcément très généreuse.
8 2955 TG PA 00
Exercice 12
Extrait du Cas NOIXCOOP (métropole 2010)
NOIXCOOP est une coopérative agricole spécialisée dans la collecte, la transforma-
tion et le conditionnement de la noix qualifiée "noix de Grenoble". Les membres
de la coopérative sont des producteurs situés dans la vallée de l’Isère (affluent du
Rhône).
Documents à utiliser : annexes 1A et 1B.
NOIXCOOP est engagée dans une démarche qualité et souhaite améliorer la tra-
çabilité de ses produits. Elle envisage donc de réorganiser la partie de son système
d’information relative à la gestion des approvisionnements et des ventes.
Les producteurs
Les membres de la coopérative sont des producteurs de noix, appelés nuticulteurs.
Chaque année, la coopérative accepte, dans une certaine proportion, la production
de producteurs non adhérents.
Les producteurs qui sont engagés dans la lutte pour le respect de l’environnement
obtiennent des certifications garantissant leur engagement dans ce domaine (par
exemple les labels Agriculture Biologique et GLOBALGAP). Pour les producteurs
adhérents, on conserve une trace des différentes certifications qu’ils possèdent (cer-
tification et date d’obtention).
La coopérative souhaite conserver dans son système d’information certaines carac-
Séquence 3 téristiques des producteurs avec lesquels elle travaille : nom et adresse de la société,
nom et prénom du responsable de production. Pour les producteurs adhérents, il
Extensions sous
Merise/2
faut également conserver la date de leur adhésion.
Les vergers
Page 88 Un producteur peut exploiter plusieurs vergers. Parmi les caractéristiques d’un ver-
ger, on trouve la variété de la noix, la superficie plantée et le nombre d’arbres à
l’hectare.
Certains vergers permettent au producteur d’obtenir les labels AOC (appellation
d’origine contrôlée), avec l’appui du Comité Interprofessionnel de la Noix de
Grenoble.
Pour avoir droit à l’appellation d’origine contrôlée (AOC), les productions de noix
doivent remplir deux conditions :
–– provenir de vergers situés dans les communes référencées par la réglemen-
tation. Ces communes sont toutes situées le long de la vallée de l’Isère ;
–– correspondre aux variétés de noix Franquette, Mayette ou Parisienne.
La production
Chaque année la coopérative réceptionne les récoltes de ses producteurs. Cette acti-
vité de l’entreprise, comme toutes les autres, doit être inscrite dans une démarche
qualité assurant la traçabilité des produits finis.
Afin d’assurer cette traçabilité, la coopérative identifie chaque livraison de noix réa-
lisée par un producteur. Une livraison est caractérisée par le verger dont proviennent
les noix, sa date, le type de produit (entière fraîche ou entière sèche) et la quantité
livrée.
8 2955 TG PA 00
Après réception, les noix sont triées en fonction de leur taille (voir annexe 1A). La coo-
pérative utilise pour cela une calibreuse destinée à répartir la livraison en différents
lots de production. Un lot de production est donc constitué de l’ensemble des noix
d’une livraison conformes à un calibre particulier. L’annexe 1B présente un exemple de
livraison répartie en différents lots de production.
Les campagnes de ventes
Les noix sont vendues à des clients qui sont pour l’essentiel des grossistes, des entre-
prises de la grande distribution ou des professionnels des métiers de la bouche (pâtis-
siers, restaurateurs).
Une commande est caractérisée par un numéro de commande, une date de commande
et un client. Chaque commande porte sur un seul lot de production déterminé en fonc-
tion de la demande du client (variété de noix, type de produit et calibre), ce qui permet
d’assurer la traçabilité des produits vendus.
Les informations concernant le client (nom, adresse, nom du responsable des achats)
doivent être enregistrées.
Pou

Langue

Conception Et Adapation BD Merise2

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Conception Et Adapation BD Merise2

Transféré par

Droits d'auteur :

Formats disponibles

BTS Services informatiques aux organisations – 2e année

Spécialité Solutions logicielles et applications métiers

BTS Services informatiques aux organisations – 2e année

José Gil – Élisabeth Martins Da Silva

Connaissances nécessaires pour aborder ce module

u Capacités attendues en fin de séquence

Le modèle Par habitude, dépendance fonctionnelle est aussi notée DF.

avec les 2 premières informations, on obtient la dernière

par contre, dans l’exemple suivant, les 2 sont nécessaires :

Donc une DF élémentaire ne suppose pas forcément un seul attribut à gauche.

Il y a bien une clé primaire et les DF sont élémentaires et directes.

4. Comment obtenir le modèle relationnel ?

Clé d'une relation :

u Capacités attendues en fin de séquence

Qu’est-ce que le MCD ?

Qu’est-ce que le SCD ?

Noms des entités

Noms des associations

En nommant l’association "CONTIENT", on constitue une phrase entre les 2 entités :

Si l'enregistrement d'un client se fait au moment où il

Page 20 ! ENTITE1 ENTITE2

"à une occurrence de l’entité1 correspond minimum n, maximum m occurrences de

Quelles sont les cardinalités possibles ?

ADMINISTRATIF PROFESSEUR MATIERE

Quand faut-il utiliser l’héritage ?

PERSONNEL Entité mère

Il est possible de demander au

1er cas : le lien identifiant pour supprimer les entités numéros

Au niveau des tables, cela donnerait ceci :

HOTEL (idHotel, nom, adresse)

Cette représentation est

2e cas : le lien identifiant pour supprimer les entités temporelles

FILM 1,n LOCATION

Liens identifiants en cascade

Liens identifiants multiples

VETEMENT VETEMENT_TAILLE TAILLE

Voici la représentation la plus officielle :

VETEMENT VETEMENT_TAILLE TAILLE

Cette représentation montre que l’association LIGNE_FACTURE est entre FACTURE et le

VETEMENT VETEMENT_TAILLE TAILLE

10. Petit mémento du MCD

Comment reconnaître une entité ?

FILM (idFilm, titre, résumé, durée, année)

Comment trouver l’identifiant d’une entité ?

Quels sont les attributs qui peuvent servir d’identifiants ?

Comment reconnaître une association ?

2e cas : l’association "vide" ("non porteuse")

Un livre est classé dans un thème précis.

LIVRE (idLivre, titre, idTheme)

Avant de donner les règles de transformation, il est nécessaire d’expliquer un peu ce

0,n 0,n Séquence 2

2e solution : transformer l’association en entité

Comment vérifier la syntaxe du schéma conceptuel de données ?

Comment vérifier la sémantique d’un schéma conceptuel

Quelques cas de figure courants des schémas conceptuels de données

ENFANT LANGUE PARLEE LANGUE

Voici le résultat en extension :

ENFANT LANGUE PARLEE LANGUE

Voici le schéma qui parait logique :

FILM (idFilm, titre)

"Sortir" ou non des informations d’une entité

VILLE DEPART 0,n

ne formation est animée par un formateur et ne concerne qu’une spécialité. Un formateur