Mon cours merise v2017

Conception et modélisation d’un système d’information
1 Proposé par A BENDAOUD
OFPPT/DRPS/ISGI LAAYOUNE
MODULE : Conception et modélisation
d'un système d'information
FILIERE : TECHNIQUES DE
DEVELOPPEMENT INFORMATIQUE
Proposé par : FORMATEUR A BENDAOUD

Sommaire
La conception d’un système d’information............................................................................................. 4
Plan...................................................................................................................................................... 4
Histoire ................................................................................................................................................ 4
Causes d’échec .................................................................................................................................... 4
Introduction......................................................................................................................................... 5
Merise???............................................................................................................................................ 5
Notion de système d’information de l’entreprise............................................................................... 5
Architecture et fonctionnement d’un système d’information............................................................ 6
Fonctionnement d’un système d’information .................................................................................... 6
Système d’information et système informatique ............................................................................... 6
Les trois cycles de Merise.................................................................................................................... 7
Cycle de vie en cascade................................................................................................................... 7
Étude préalable par domaine :........................................................................................................ 8
Étude détaillée par projet :................................................................................................................ 8
Cycle de vie en spirale ..................................................................................................................... 9
Courbe du soleil............................................................................................................................... 9
Les systèmes informatiques ............................................................................................................. 10
Résumé.......................................................................................................................................... 10
Cycles d’abstraction de conception des S.I ....................................................................................... 11
Modèle conceptuel des données .......................................................................................................... 12
Introduction au Modèle Conceptuel des Données ........................................................................... 12
La séparation des données et des traitements................................................................................. 12
1. Les données (ou informations)...................................................................................................... 12
a. L’interview ................................................................................................................................. 12
b. L’étude des documents internes............................................................................................... 13
c. L’étude des documents externes............................................................................................... 13
Les différents types d’informations .................................................................................................. 13
a.Les informations élémentaires et mémorisables....................................................................... 13
b. Les informations calculées ........................................................................................................ 13
c. Les traitements .......................................................................................................................... 13
Propriété (ou attribut)....................................................................................................................... 14

Constitution du dictionnaire des données............................................................................................ 15
Les entités.......................................................................................................................................... 16
Identifiant d’une entite ..................................................................................................................... 19
Relations ou Association ................................................................................................................... 20
Relation réflexive........................................................................................................................... 22
Cardinalités........................................................................................................................................ 22
L’identifiant d’une association .......................................................................................................... 25
Relation ternaire................................................................................................................................ 26
Transformation d’une relation en une entité ................................................................................... 27
Notion de Dépendance Fonctionnelle................................................................................................... 29
Dépendance fonctionnelle élémentaire............................................................................................ 29
Dépendance fonctionnelle élémentaire directe............................................................................. 30
Graphe de Dépendances Fonctionnelles........................................................................................... 30
PERSONNALISATION D’ASSOCIATIONS ............................................................................................. 31
Dépendances Fonctionnelles particulières et Représentations MERISE 2....................................... 33
Les formes normales ............................................................................................................................. 34
Introduction....................................................................................................................................... 34
Definition....................................................................................................................................... 34
Avantages et inconvénients .......................................................................................................... 35
La première forme normale : ........................................................................................................ 36
La deuxième forme normale ......................................................................................................... 36
La troisième forme normale.............................................................................................................. 38
Le Modèle logique de données ............................................................................................................. 39
Introduction....................................................................................................................................... 39
Problématique :................................................................................................................................. 39
Transformation d’un individu ou entité type.................................................................................... 39
Transformation d’une relation binaire (0,n)-(1,1) ou (1,n)-(1,1)....................................................... 40
Transformation d’une relation binaire (0,n)-(0,1) ou (1,n)-(0,1)....................................................... 42
Transformation d’une relation binaire (0,1)-(1,1)............................................................................. 43
Transformation d’une relation binaire (0,1)-(0,1)............................................................................. 44
Transformation d’une relation binaire (*,n)-(*,n)............................................................................. 45
Transformation d’une relation ternaire et supérieure quelles que soit les cardinalités .................. 46
Application des règles de passage sur une relation réflexive ........................................................... 50
Application des règles de passage sur une entité faible................................................................... 51

La conception d’un système d’information
PLAN
 Introduction
 Merise??
 Notion de système d’information de l’entreprise
 Architecture et fonctionnement d’un système d’information
 Système d’information et système informatique
 Les trois cycles de Merise
HISTOIRE
Il y ’a maintenant cinq siècles, Cristoforo Colombo, aventurier d’origine génoise, persuadé de la
rotondité de notre planète, élabora le projet déconcertant d’atteindre les Indes par voie maritime, en
se dirigeant vers l ’Ouest..
L ’Histoire nous enseigne qu’il n ’atteignit jamais cet objectif, mais découvrit à la place les Amériques,
la terre nouvelle!!!§
CAUSES D’ÉCHEC
1. Méconnaissance quasiment totale du sujet sur ces principaux aspects, les Indes et l ’Océan.
2. Incapacité à estimer la durée et les charges de la traversée (Conséquence directe de 1)
3. Inadaptation flagrante du système de contrôle.
4. Incapacité à maintenir la cohésion de l’équipage
5. C’est de croire qu’il n’y a que 4 causes d'échec d’un projet

INTRODUCTION
 La conception d’un système d’information n’est pas chose aisée puisqu’il faut réfléchir à
l’ensemble de l’organisation qui doit être mise en place. Pour y arriver, il est nécessaire de
concevoir des méthodes pour l’élaboration d’un modèle du S.I. On parle ainsi de
modélisation ou de représentation virtuelle de la réalité. Ce type de méthodes est appelé
Analyse. Il existe plusieurs méthodes d’analyse, une des plus connues est la méthode
MERISE.
MERISE???
 MERISE est une méthode qui permet l’élaboration d’un système d’information. Cette
méthode est basée sur un concept fondamental : la séparation des données et des
traitements, cela est motivé par le fait que les données ne sont changées que rarement, par
contre, les traitements le sont plus souvent (contrairement à des pratiques plus récentes de
modélisation orientée objet où l’on ne sépare plus les données et les traitements).
 La méthode MERISE a vu le jour en 1978, et elle a été mise au point par 2 sociétés
françaises : le CTI (Centre Technique d’Informatique) et le CETE (Centre d’Études Techniques
de l’Équipement).
NOTION DE SYSTÈME D’INFORMATION DE L’ENTREPRISE
 L’entreprise est un système complexe dans lequel transitent de nombreux flux
d’informations. L’objectif de la mise en place d’un S.I est de maîtriser ces flux par la collecte,
la mémorisation, la distribution de l’information (avec un temps de réponse rapide). Ce S.I
assurera le lien entre 2 autres systèmes de l’entreprise : le système opérant et le système de
pilotage.
Système de Pilotage
Système opérant
Système D’information

Le système de pilotage décide des actions à conduire sur le système opérant en fonction des objectifs
et des politiques de l’entreprise.
Le système opérant comprend toutes les fonctions liées à l’activité propre de l’entreprise : facturer
les clients, payer les salariés, gérer les stocks…
ARCHITECTURE ET FONCTIONNEMENT D’UN SYSTÈME D’INFORMATION
 Le S.I doit décrire (ou représenter) le plus fidèlement possible le fonctionnement du système
opérant. Pour cela, il doit intégrer une base d’information dans laquelle sont mémorisées : la
description des objets, des règles et contraintes du système opérant.
 Cette base doit évoluer, c’est pourquoi le S.I contient « le processeur d’information » ayant
pour but de piloter et contrôler les changements de la base.
FONCTIONNEMENT D’UN SYSTÈME D’INFORMATION
 Voici le schéma de l’architecture d’un S.I :
SYSTÈME D’INFORMATION ET SYSTÈME INFORMATIQUE
 Pour assurer un traitement automatisé de l’information du S.I à l’aide d’outils informatiques,
la méthode Merise propose la démarche d’informatisation suivante :
 Schéma directeur : représente la définition, de manière globale, de la politique
d’organisation et d’automatisation du S.I. Lors de cette étape, le S.I est découpé en sous-
ensembles (ou domaines) homogènes et indépendants, par exemple, les domaines achat,
vente…
Base
d’information
Processeur d’information
Faits et
événements
Faits de la base
d’information

LES TROIS CYCLES DE MERISE
MERISE propose une démarche de réalisation d'un système d’information (SI) qui consiste à traiter
un projet informatique en s'appuyant sur trois notions fondamentales:
 Vie du projet
 Suivi du projet, décision
 Formalisation du projet (différents niveaux d’abstraction)
Le système d'information est composé des moyens (humains et techniques) nécessaires au stockage
et au traitement de l'information d'une organisation.
Cycle de vie en cascade
Etude préalable
ou de faisabilité
Etude détaillée
Recette test en
chaîne
Mise en
exploitation
Réalisation
programmation
test unitaire
Maintenance

Faire une présentation générale du futur système de gestion (matérialisé par les
modèles des données et des traitements) et ce qu’il apporte comme améliorations par rapport au
système existant. Cette étude doit être réalisée en 4 étapes :
 Étape de recueil : analyser l’existant pour détecter les dysfonctionnements du système
actuel.
 Étape de conception : formalisé les nouvelles orientations permettant de modéliser le futur
S.I sur la base, d’une part, des critiques formulées sur le système actuel et d’autre part, des
orientations de la direction de l’entreprise.
 Étape d’organisation : définir le système futur au niveau organisationnel, c.-à-d. qui fait
quoi ?
 Étape d’appréciation : établir les coûts et délais de réalisation des solutions préconisées.
Au regard de cette ébauche du système futur, proposer divers scénarios. Chaque scénario doit
mentionner les éléments
Suivants :
 Matériels nécessaires.
 Logiciels nécessaires.
 Grands ensembles d'informations et principaux traitements retenus pour l'automatisation
(MCT et éventuellement ébauche du MCD).
Les problèmes éventuels ne sont perçus qu’à la mise en exploitation, d’où la préférence donnée au
cycle de vie en spirale
ÉTUDE DÉTAILLÉE PAR PROJET :
 D’une part, détailler les solutions préconisées par l’étude préalable, et d’autre part, rédiger
le dossier des spécifications (maquettes, algorithmes associés aux règles de gestion…)
permettant de définir le cahier des charges de l’utilisateur qui constitue la base de
l’engagement du concepteur vis-à-vis de l’utilisateur.
 Réalisation : Obtenir des programmes qui tournent sur un jeu d’essai défini par l’utilisateur.
 Mise en œuvre : Transmettre, d’une part, la recette définitive de l’application à l’utilisateur,
et d’autre part, former l’utilisateur.
 Maintenance : Faire évoluer l’application en fonction des besoins de l’utilisateur et des
avancées technologiques.
Étude préalable par domaine :

Cycle de vie en spirale
Courbe du soleil
Analyse
conception
Merise
Prototype
V1
Test Mise
au point
Conception
Prototype
V2
Test Mise
au point
Critique
(focus point)
Conception
Version
stabilisée
Critique
(focus point)
Prototype
V3
Critique
Modéles :
Données
Traitements
Flux
Interviews
Recueil
d’information
Conceptuel
Organisationnel
Opérationnel
Nouveau
modèle
Nouveau
système
d’information
Analyse de l’existant Critique Conception réalisation
Temps
Abstraction

LES SYSTÈMES INFORMATIQUES
 Ils comprennent, outre les S.I, les technologies de l’information, les ordinateurs, les
applications informatiques, les réseaux et autres systèmes permettant l’accès, l’analyse, la
création, l’échange,… de l’information.
 En définitive, la méthode Merise est considérée comme une méthode de conception des S.I
et non des systèmes informatiques, même si les S.I sont actuellement largement gérés par
des applications informatiques, les modèles Merise doivent être utilisées pour faciliter le
développement de ces applications en s’appuyant sur les technologies logicielles de B.D
relationnelles ou client/serveur.
 En guise de conclusion de cette introduction, on dira que l’on traitera au niveau de ce cours
les concepts Merise utiles aux descriptions statique et « dynamique » du S.I à automatiser
sur 3 niveaux d’abstraction :
Le niveau conceptuel
Le niveau conceptuel consiste à concevoir le SI en faisant abstraction de toutes les contraintes
techniques ou organisationnelles et cela tant au niveau des données que des traitements.
Le niveau conceptuel répond à la question Quoi ? (le quoi faire, avec quelles données).
Le formalisme Merise employé sera :
Le Modèle Conceptuel des Données (MCD).
Le Modèle Conceptuel des Traitements (MCT).
Niveau organisationnel :
Le niveau organisationnel a comme mission d’intégrer dans l’analyse les critères liés à l’organisation
étudiée. Le niveau organisationnel fera préciser les notions de temporalité, de chronologie des
opérations, d’unité de lieu, définira les postes de travail, l’accès aux bases de données…
Les questions posées, au niveau des traitements, sont :
Qui ?
Où ?
Quand ?
Le formalisme Merise employé sera :
Le Modèle Organisationnel des Données (MOD).
Le Modèle Organisationnel des Traitements (MOT).
Le niveau logique
Le niveau logique est indépendant du matériel informatique, des langages de programmation ou de
gestion des données. C’est la réponse à la question Avec quoi ?
Le formalisme sera :
 Le Modèle Logique des Données (MLD).
 Le Modèle Logique des Traitements (MLT).
Résumé

Le niveau physique
 Le niveau physique permet de définir l’organisation réelle (physique) des données. Il apporte
les solutions
 techniques, par exemple sur les méthodes de stockage et d’accès à l’information. C’est la
réponse au Comment ?
 Le formalisme employé sera :
 Le Modèle Physique des Données (MPD).
 Le Modèle Opérationnel et physique des Traitements (MOpT).
Tableau récapitulatif
Niveaux Données Traitements
Conceptuel Modèle Conceptuel des Données Modèle Conceptuel des
Traitements
Organisationnel Modèle Organisationnel des
Données
Modèle Organisationnel des
Traitements
Logique Modèle Logique des Données Modèle Logique des traitements
Physique Modèle Physique des Données Modèle Opérationnel et Physique
des
Traitements
- 2
CYCLES D’ABSTRACTION DE CONCEPTION DES S.I
Système d’information actuel
Modèle logique
Expression des Besoins
Modèle conceptuel
Modèle physique
Système d’information Automatisé

Modèle conceptuel des données
Les concepts de base
Modèle conceptuel des données
INTRODUCTION AU MODÈLE CONCEPTUEL DES DONNÉES
Une description détaillée d’un système d’information suppose, implicitement, une description
détaillée de l’ensemble d’objets, d’événements ou de concepts concernés par les traitements.
Le modèle conceptuel de données (MCD) décrit les objets, les événements, les concepts d’une
manière abstraite, sans réfléchir, à ce stade, aux possibilités de traitement par l’ordinateur. Dans
la suite, nous étudierons le modèle basé sur le couple entité - association.
Le Modèle Conceptuel des Données introduit la notion d’entités, de relations et de propriétés.
Nous allons commencer par voir certains aspects « théoriques » avant de plonger dans la
pratique. Il décrit de façon formelle les données utilisées par le système d’information. La
représentation graphique, simple et accessible, permet à un non informaticien de participer à
son élaboration. Les éléments de base constituant un modèle conceptuel des données sont :
 les propriétés ;
 les entités ;
 les relations.
LA SÉPARATION DES DONNÉES ET DES TRAITEMENTS
1. LES DONNÉES (OU INFORMATIONS)
L’information est l’émission ou la réception de signaux oraux ou écrits, sonores, visuels ou multimédias
dont le but est de déclencher les processus alimentant l’échange, base naturelle et indispensable de
l’animation de l’organisation.
Les informations se recueillent à l’intérieur du domaine à étudier. La liste d’informations est constituée de
plusieurs façons :
 l’interview ;
 l’étude des documents internes ;
 l’étude des documents externes.
Une des phases du recueil d’information est un entretien avec les différents acteurs de l’organisation. Cet
entretien permet de définir le périmètre de l’applicatif futur. Les informations orales sont classées et
a. L’interview

regroupées en parties distinctes. Ainsi, les informations concernant l’enregistrement des données de
l’organisation seront regroupées.
Les documents internes (factures, bons de livraison, ordres de fabrication) recèlent des informations qui
sont souvent omises lors des entretiens. Ces oublis sont dus au caractère automatique et récurrent de
ces informations.
Les personnes qui les manipulent au quotidien oublient souvent de les citer tant elles leur paraissent
évidentes.
L’étude des documents externes (factures des fournisseurs, bons de livraison fournisseurs...) tout
comme l’étude des documents internes permet de découvrir des informations oubliées lors des interviews
et de découvrir aussi quelques règles de gestion.
Pour ce recueil d’informations, il est nécessaire de respecter certaines règles pour éviter des erreurs
futures.
Avant d’ajouter une information, il est impératif de s’assurer qu’elle n’est pas déjà présente. Par
exemple, un numéro client peut apparaître sur un bon de livraison et sur une facture. Ce n’est pas la
peine de le répertorier deux fois.
De même, une information peut être synonyme d’une autre. Par exemple sur le bon de livraison il
apparaît « Codeclient » et sur la facture « Numéro Client ». Il est impératif de ne garder qu’une seule des
deux informations.
LES DIFFÉRENTS TYPES D’INFORMATIONS
Les informations élémentaires sont des informations dont les valeurs ne peuvent pas être inventées, elles
ne sont pas déductibles d’autres informations.
La propriété est une information élémentaire (par rapport au domaine étudié), c-à-d qu’elle ne peut
pas être déduite à partir d’autres informations.
Par exemple, un nom de client ou sa raison sociale ne peuvent pas être inventés.
Une quantité commandée ne peut pas non plus être inventée.
Une information doit être atomique, c’est à dire non décomposable. Par exemple si l’information Adresse
doit contenir « 36, rue de la paix 75000 Paris » celle-ci peut être décomposée en plusieurs informations
élémentaires :
Adresse ;
Code postal ;
Ville.
Chaque valeur prise par une information est appelée une occurrence. Par exemple, l’information Nom
peut avoir les occurrences suivantes : lBRAHIMI ;MOURAD.FAHMI
Les informations calculées sont déductibles des informations élémentaires.
Par exemple, le total d’une ligne de commande est le résultat de la multiplication du prix de vente hors
taxe et de la quantité commandée.
Ils sont collectés comme les informations via un processus d’interview et d’étude des documents.
b. L’étude des documents internes
c. L’étude des documents externes
a.Les informations élémentaires et mémorisables
b. Les informations calculées
c. Les traitements

Ils peuvent être de deux sortes :
 Automatiques ;
 Manuels.
Ils sont déclenchés par l’arrivée d’évènements.
La gestion des traitements sert à identifier les fonctionnalités selon une approche qui va du général au
particulier et qui définit leur découpage et leur enchaînement.
PROPRIÉTÉ (OU ATTRIBUT)
La propriété est une information élémentaire (par rapport au domaine étudié), c-à-d qu’elle
ne peut pas être déduite à partir d’autres informations.
Par exemple, si on considère le domaine de « la gestion des ventes d’une société
commerciale », les données :
 Référence article » ; « Désignation article »
 Prix unitaire HT ; Taux TVA
Sont des propriétés « pertinentes » pour ce domaine. En revanche, la donnée
« Prix unitaire TTC » n’est pas une propriété, car elle peut être déduite du PU-HT et du T-TVA.
Total n’est pas une propriété car il est calculé en fonction de la somme des PU*Qtt
Chaque valeur prise par une propriété est appelée occurrence. Par exemple, des occurrences
de « désignation article » sont : « ordinateur », « clavier », « souris »…
« «brahim », »ahmed », »ali », » fatima» se sont des occurrences de la propriété nom
 Une propriété est dite simple (ou atomique) si chacune des valeurs qu’elle regroupe n’est
pas décomposable.
 Par exemple, la propriété « Adresse », dont un exemple d’occurrences est donné ci-dessous,
n’est pas élémentaire car elle peut être décomposée en 3 propriétés : la rue, le code postale
et la ville :
 125, Boulevard Abdelmoumen 20000 Casablanca.
Remarque
Dans le MCD, on doit faire apparaître toutes les propriétés identifiées par leurs noms qui
doivent être explicites. De plus, il doit y avoir une parfaite correspondance (bijection) entre
l’ensemble des noms et l’ensemble des propriétés, cela donne les règles suivantes :
 Il faut exclure les synonymes : 2 noms différents pour identifier la même propriété.
 Il faut exclure les polysémes : 2 propriétés différentes ayant le même nom.
 Principe de non-redondance : chaque propriété doit apparaître une fois et une seule dans le
modèle.

Constitution du dictionnaire des données
Le dictionnaire des données est un document qui permet de recenser, de classer et de trier toutes les
informations (les données) collectées lors des entretiens ou de l’étude des documents. Le dictionnaire
peut être plus ou moins élaboré selon le niveau de granularité souhaité. En voici un exemple :
Cette étape consiste à référencer toutes les données du domaine. Pour notre service Achat, on peut
recenser un certain nombre d’éléments :
Nom de la donnée
Cette cellule recevra une donnée par exemple : Nom client.
Format
Ici sera indiqué le format de la donnée, par exemple : alphabétique.
Longueur
La longueur approximative ou exacte de la donnée sera indiquée, par exemple : 30.
Type
Une croix sera inscrite dans la colonne pour indiquer si la donnée est élémentaire ou calculée.
Règle de calcul
Ici sera indiquée de manière claire la formule ou le calcul nécessaire à appliquer pour obtenir la donnée.
Règle de gestion
Dans cette zone sera indiquée, si nécessaire, la règle de gestion inhérente à la donnée.
Document
La rubrique document permet de saisir le document dans lequel a été trouvée la donnée.
Voici ce que pourrait être le dictionnaire :

 Nom du fournisseur
 Date de la commande
 Numéro de la commande
 Quantité en stock de l’article
 Référence de l’article
 Prix unitaire de l’article
 Désignation de l’article
 Quantité commandée
 Condition de paiement
 Condition de livraison
 Téléphone du fournisseur
 Adresse du fournisseur
 Adresse de livraison
 Unité de l’article
 Taux de TVA
Chaque terme du dictionnaire des données est appelé Propriété. L’étape suivant consiste à
regrouper les propriétés dans des entités.
LES ENTITÉS
L’entité est la représentation d’un élément ayant un rôle dans le système. Une entité possède des
propriétés qui la décrivent. Un ensemble d’entités de même type s’appelle une classe d’entités.
Chaque entité est unique et est décrite par un ensemble de propriétés encore appelées attributs .
Une des propriétés de l'entité est l'identifiant. Cette propriété doit posséder des occurrences uniques
et doit être source des dépendances fonctionnelles avec toutes les autres propriétés de l'entité. Bien
souvent, on utilise une donnée de type entier qui s'incrémente pour chaque occurrence, ou encore
un code unique spécifique du contexte.
Le formalisme d'une entité est le suivant :

Ainsi, si on reprend notre dictionnaire de données précédent, on schématise par exemple une entité
«Auteur» comme ceci :
À partir de cette entité, on peut retrouver la règle de gestion suivante : un auteur est identifié par un
numéro unique (id_a) et est caractérisé par un nom, un prénom et une date de naissance.
Une entité peut avoir une ou plusieurs occurrences. Pour illustrer ce terme d'«occurrence» qui a déjà
été utilisé plusieurs fois, voici un exemple de table d'occurrences de l'entité Auteur :
id_a nom_a prenom_a date_naissance_a
1 Hugo Victor 1802-02-26
2 Rimbaud Arthur 1854-10-20
3 de Maupassant Guy 1850-08-05
Cette table est composée de trois occurrences de l'entité Auteur.
Remarques :
 Les occurrences sont parfois appelés tuples. Par ailleurs, la table d'occurrence peut être
comparée à l'instance d'une relation (implantation relationnelle d'une entité ou association)
à un moment donné. Nous reviendrons sur cette notion de relation dans la partie III.
 Au niveau conceptuel, on devrait plutôt parler d'entités-types , les entités étant en fait des instances
d'entités-types. Par soucis de simplicité, on gardera les termes d'entités et associations tout au long du
cours.
Dans notre cas, trois entités semblent se dégager :
 L’entité Fournisseur
 L’entité Article
 L’entité Commande

Une fois ces entités définies, on leur associe les propriétés du dictionnaire des données.
Un premier essai nous donne ceci :
Remarque
 Une propriété ne peut être dans plusieurs entités. Ici, par exemple, le prix d’un article est
une propriété de l’entité Article. Mais dans la mesure où ce prix est négocié en fonction de la
commande, il sera nécessaire de disposer de deux propriétés prix : une propriété Prix Article
dans l’entité Article et une propriété Prix Commande dans l’entité Commande.
Chaque fois qu’une propriété est associée à une entité on le signale dans le dictionnaire de
données.
 F Nom du fournisseur
 C Date de la commande
 C Numéro de la commande
 Quantité en stock de l’article
 A Référence de l’article
 A Prix unitaire de l’article
 A Désignation de l’article
 Quantité commandée
 Condition de paiement
 Condition de livraison

 F Téléphone du fournisseur
 F Adresse du fournisseur
 Adresse de livraison
 A Unité de l’article
 Taux de TVA
On se rend compte que certain éléments du dictionnaire de données ne figurent pas dans les
entités. Ceci peut être dû à plusieurs causes :
 Certains éléments ne sont pas des données. C’est peut être le cas des conditions de
paiement. En effet, ces conditions peuvent être le résultat d’un calcul dépendant de la
quantité commandée, du délai de livraison, …
 Certains éléments ne sont pas dans le domaine étudié. C’est le cas de la quantité en stock de
l’article. C’est bien une donnée mais cette donnée concerne la Gestion de stocks et non le
service Achat.
 Certains éléments sont peut-être des propriétés d’entités que l’on n’a pas encore créées ou
ils qualifient une relation entre entités. Par exemple la quantité commandée ne peut être
une propriété de l’entité Commande que si une commande ne fait l’objet que d’un seul
article, ce qui est un cas particulier.
IDENTIFIANT D’UNE ENTITE
Une entité est caractérisée par ses propriétés. Parmi ces propriétés il peut y avoir une,
plusieurs ou aucune permettant d’identifier une occurrence unique d’une entité. Si une telle
propriété existe, elle identifie l’entité. On la nomme identifiant.
L’identifiant sert à désigner, sans ambiguïté une occurrence de l’entité. Toute entité doit
avoir un identifiant.
La méthode Merise propose des représentations graphiques pour la plupart de notions
qu’elle utilise. Une entité est représentée par un rectangle dans lequel apparaissent son
nom et ses propriétés. Afin de faciliter la lecture des propriétés, le nom de l’identifiant est
souligné.
Exemple
 L’entité client a comme identifiant le numéro client.
 L’entité voiture ayant les propriétés : Numéro d’immatriculation, Couleur voiture, Marque a
comme identifiant la propriété Numéro d’immatriculation.

RELATIONS OU ASSOCIATION
Une association définit un lien sémantique entre une ou plusieurs entités. En effet, la définition de
liens entre entités permet de traduire une partie des règles de gestion qui n'ont pas été satisfaites
par la simple définition des entités.
Le formalisme d'une association est le suivant :
Généralement le nom de l'association est un verbe définissant le lien entre les entités qui sont reliées
par cette dernière. Par exemple :
Ici l'association «être né» traduit les deux règles de gestion suivantes :
 Un auteur est né dans un et un seul pays,
 Dans un pays, sont nés aucun, un ou plusieurs auteurs.
Vous remarquerez, que cette association est caractérisée par ces annotations 1,1 et 0,N
qui nous ont permis de définir les règles de gestions précédentes. Ces annotations sont appelées
les cardinalités.

Une relation ou association est un lien entre différentes entités. Ces liens se réalisent en se posant la
question : quelle entité interagit sur cette ou ces entités.
 Par exemple, un fournisseur fournit un article et un article est fourni par un fournisseur. En
effet il y a interaction entre les entités Fournisseur et Article que l’on traduit par l’action de
Fournir.
le prix peut être négocié faire les modifications nécessaires puis ajouter les cardinalités a cette
association :
 De même, une commande comporte des articles et les articles appartiennent à une
commande. La relation entre les entités Commande et Article est l’action de Commander
 Une relation peut avoir des propriétés. C’est le cas ici de la propriété Quantité qui est une
propriété de la relation Commander.
Fournisseur
Nom
Adresse
Téléphone
Article
Référence
Prix
Désignation
Unité
Fournir
Fournisseur
Nom
Adresse
Téléphone Article
Référence
Prix
Désignation
Unité
Fournir
Commande
Date
Numéro
Commander
Fournisseur
Nom
Adresse
Téléphone Article
Référence
Prix Unitaire
Désignation
Unité
Fournir
Commande
Date
Numéro
Commander
Quantité
Prix cde.
Prix fnr.
0,n
0,n
1,n
1,n

 pour lever l’ambiguïté de la propriété Prix , la propriété Prix Unitaire est associée à l’entité
Article, la propriété Prix commande est associée à la relation Commander et la propriété Prix
fournisseur est associée à la relation Fournir.
C’est une relation qui liée une entité a elle-même :
Soit l’exemple suivant :
Ici l’entité employé joue deux rôles : rôle d’employé subordonné et rôle d’employé chef, on peut le
supposer comme si on a deux entité Employé superposées.
La patte de l’association du cardinalité 0,N part d’Employé qui a pour rôle Employé Chef
La patte de l’association du cardinalité 1,1 part d’Employé qui a pour rôle Employé subordonné
CARDINALITÉS
Relation réflexive
Employe
ID_Emp
nom
prenom
A pour chef
1,1
0,N
est chef de

Exemple :
Les valeurs 0,n 1,n 1,1 sont des cardinalités.
 La cardinalité 1,n de l’entité Commande pour la relation Commander signifie qu’une
commande peut avoir au moins un article et au plus N .
 La cardinalité 0,N de l’entité Article pour la relation Commander signifie qu’un Article peut ne
pas être commandé ou commandé plusieurs fois.
 La cardinalité 1,1 de l’entité commande pour la relation Passer signifie qu’une commande est
passée par un est un seul client minimum un client et maximum un client
 La cardinalité 1,N de l’entité client pour la relation Passer signifie qu’un client passe un ou
plusieurs commande
Il nous reste l’Adresse de livraison et le Taux de TVA.
 L’Adresse de livraison est une propriété de l’entité Commande.
Les cardinalités expriment le nombre minimum et maximum de fois qu’une entité est concernée
par la relation.
Fournisseur
Nom
Adresse
Téléphone Article
Référence
Prix Unitaire
Désignation
Unité
Fournir
Commande
Date
Numéro
Commander
Quantité
Prix cde.
Prix fnr.
0,n
0,n
1,n
1,n
Client
Code
nom
prénom
Passer
1,N
1,1

 Pour le taux de TVA, il y a deux façons de résoudre le problème :
 Soit rattacher le taux à la relation Commander
Soit créer une entité Taux de TVA
Remarque
 On ne peut, dans l’état actuel de nos connaissance, définir qu’elle est la présentation la
mieux adaptée au problème. Il se peut de plus que la TVA soit fonction de la nature de
l’article et/ou du lieu de livraison (Export, Régime Intra/Extra Communautaire) .
 Un MCD ne peut être unique et varie nécessairement en fonction de règles de gestion et de
choix du concepteur.
Fournisseur
Nom
Adresse
Téléphone Article
Référence
Prix moyen
Désignation
Unité
Fournir
Commande
Date
Numéro
Commander
Quantité
Prix comm.
Taux TVA
Prix four.
0,n
0,n
1,n
1,n
Fournisseur
Nom
Adresse
Téléphone Article
Référence
Prix moyen
Désignation
Unité
Fournir
Commande
Date
Numéro
Commander
Quantité
Prix comm.
Prix four.
0,n
0,n
1,n
1,n
Taux TVA
Code TVA
Taux TVA
0,n

 Une relation peut ne pas avoir de propriété
 Une relation peut être binaire, ternaire, …
L’IDENTIFIANT D’UNE ASSOCIATION
L'identifiant d'une association ayant des cardinalités 0,N/1,N de part et d'autre, est obtenu par la
concaténation des entités qui participent à l'association. Imaginons l'association suivante :
Ici un auteur rédige au moins un ou plusieurs livres et pour chaque livre, on connaît le nombre de
chapitres rédigés par l'auteur (on connaît aussi le nombre total de chapitres pour chaque livre).
L'association «rédiger» peut donc être identifiée par la concaténation des propriétés id_a et id_l.
Ainsi, le couple id_a, id_l doit être unique pour chaque occurrence de l'association. On peut
également définir la dépendance fonctionnelle suivante :
id_a, id_l → nb_chapitres
On dit que nb_chapitres (nombre de chapitres rédigés par un auteur, pour un livre) est une donnée
portée par l'association «rédiger». Cette association est donc une association porteuse de données.
Pour une association ayant au moins une cardinalité de type 0,1 ou 1,1 considérons dans un premier
temps que cette dernière ne peut être porteuse de données et qu'elle est identifiée par l'identifiant
de l'entité porteuse de la cardinalité 0,1 ou 1,1.
Nous reviendrons plus en détail sur la notion d'identification d'une association lors du passage au
modèle logique.

RELATION TERNAIRE
Une relation binaire est une relation qui lie deux entités
Une relation térnaire est une relation qui lie trois entités
On peut avoir des relations d’ordre N se sont des relations qui lient N entités
Exercice de réflexion :
Dans un cabinet médical les patients sont consultés par les médecins,un patient choisit le medecin
avec qui il va faire la consultation
Le premier modèle conceptuel relatif est :
Les informations concernant la relation « consulter » peuvent être représenté comme si on a une
entité qui a pour identifiant la concaténation des identifiants qui participent à la relation
« consulter » ;
Les entités qui participent à la relation sont médecin et patient d’où l’identifiant de la relation est
(codeM,codeP)
Toutefois les valeurs d’un identifiant sont unique c à d on ne peut pas avoir deux valeurs identiques
(a,b)<>(a’,b’)a<>a’ ou b<>b’
(a,b)=(a’,b’)a=a’ et b=b’
Medecin
codeM
nomM
telephoneM
Patient
codeP
nomP
telephoneP
consulter
dateConsultation
0,N
1,N
Fournir Commander
Quantité
Prix comm.
Prix four.
Relation binaire Relation ternaire

Cette premiére modélisation ne permet pas à un patient de faire plusieurs consultations par un
même médecin qui n’est pas logique.
M1 fait la consultation de p1 le 03/04/17 mais
M1 ne peut pas fait la consultation de p1 le 10/04/17 puisque l’identifiant de l’association est
(codeM,codeP).
Le triplet (M1,P1,03/04/17) est diffèrent du triplet(M1,P1,10/04/17),donc si on ajoute la date de
Consultation a l’identifiant de l’association consulter, le modèle peut supporter le cas « un patient
peut être consulté par plusieurs médecins a des dates différentes
D’où on aura le MCD suivant :
L’identifiant de l’association Visiter devient (codeM,codeP,dateVisite)
TRANSFORMATION D’UNE RELATION EN UNE ENTITÉ
En réalité dans une cabiné médicale quand un patient effectue une consultation, une fiche de
consultation va être remplit par les informations du patient et le numéro du médecin qui a fait la
consultation, puis le rapport des pathologies du patient.
D’où la relation consultation peut être remplacer par une entité « consultation » qui possède un
identifiant codec,et comme ça on se retrouve avec une modélisation qui représente fidèlement la
réalité
Medecin
codeM
nomM
telephoneM
Patient
codeP
nomP
telephoneP
consulter
dateConsulta
tion
0,N
1,N
date
datevisite
0,N

Medecin
codeM
nomM
telephoneM
Patient
codeP
nomP
telephoneP
passer
0,N 1,N
effectuer
consultation
codeC
dateC
1,1 1,1

Dépendance fonctionnelle
Notion de Dépendance Fonctionnelle
Formalisme :
A B : 1 source, 1 but
( A, B, …) X : plusieurs sources, 1 but
A ( X, Y, …) : 1 source , plusieurs buts
Exemples
N° Client Nom Client
Nom Client N° Client ( pas de DF)
Prénom Client N° Client ( pas de DF )
( Réf-prod , N° Commande ) Qté prod. commandée
Réf-prod ( Libellé prod. , Prix unit. Prod. )
DÉPENDANCE FONCTIONNELLE ÉLÉMENTAIRE
Définition : 2 propriétés A et B sont en DF si la connaissance d’une valeur de A détermine une et
une seule valeur de B . On dit que A détermine fonctionnellement B .
Une dépendance fonctionnelle A → B est élémentaire s’il n’existe pas une donnée C, sous
ensemble de A, décrivant une dépendance fonctionnelle de type C → B

Par exemple :
1- RéférenceProduit → Désignation
2- NuméroCommande, RéférenceProduit → Quantité
3- NuméroCommande, RéférenceProduit → Désignation
La première dépendance fonctionnelle est correcte car ayant une rubriques elle est élémentaire.
La deuxième dépendance fonctionnelle est correcte également car la connaissance d’un numéro de
commande et d’une référence produit nous permet de connaître la quantité commandé du produit.
Elle est aussi élémentaire car c’est la connaissance du couple (NuméroCommande, RéférenceProduit)
et pas seulement d’un des éléments qui permet la connaissance de la quantité.
La troisième dépendance fonctionnelle n’est pas élémentaire car il existe à l’intérieur d’elle
RéférenceProduit → Désignation
DÉPENDANCE FONCTIONNELLE ÉLÉMENTAIRE DIRECTE
Exemple :
NumClasse → NumElève
NumEleve → NomElève
NumClasse → NomElève
La troisième dépendance fonctionnelle n’est pas directe car nous pourrions écrire :
NumClasse → NumElève → NomElève
GRAPHE DE DÉPENDANCES FONCTIONNELLES
GDF = Représentation graphique de l’ensemble des DFs unissant les propriétés dans un domaine
d’activité du système d’information. Ces propriétés sont obtenues à partir du dictionnaire de
données du domaine.
Exemple : GDF du domaine « Gestion commerciale » dans une entreprise
On dit que la dépendance fonctionnelle A → B est directe s’il n’existe aucun attribut C tel que l’on
puisse avoir A → C et C → B. En d’autres termes, cela signifie que la dépendance fonctionnelle
entre A et B ne peut pas être obtenue par transitivité.

PERSONNALISATION D’ASSOCIATIONS
BUT : Transformer une association en entité lorsqu’il y a une perte sémantique dans le MCD par
rapport aux règles de gestion du S.I
0,N
Client
N client
Nom Client
Adresse Client
Voiture
Matricule
marque
chevaux
ASSUREURE
N Assureur
Nom Assureur
Adresse Assureur
Assurer
dateSignature
date echeance
montant
prime
1,N
0,N

Selon le modèle, le client ne peut signer qu’un seul contrat d’assurance pour un véhicule donné avec
le même assureur d’après la structure de l’identifiant de l’association.
Solution : Personnaliser l’association « Assurer » en entité
D’où maintenant
Un client peut signer plusieurs contrats d’assurance relatifs au même véhicule chez le même
assureur.
1 ,1
ASSUREURE
N Assureur
Nom Assureur
Adresse Assureur
Client
N client
Nom Client
Adresse Client
Voiture
Matricule
marque
chevauxCONTRAT
N Contrat
Date signature
Date écheance
Montant
Prime
CIF
CIF
CIF
1,N
1,N
1,N
1,11,1
1,1

DÉPENDANCES FONCTIONNELLES PARTICULIÈRES ET REPRÉSENTATIONS MERISE 2

Les formes normales
INTRODUCTION
Nous allons aborder dans ce document les principes de normalisation des données. Nous parlerons
de modèles de données conforment à la 1ère
, 2ème
ou 3ème
forme normale.
Dans une base de données relationnelle, une forme normale désigne un type de relation particulier
entre les entités. Comme son nom l’indique, normale décrit la norme.
La normalisation s’applique à toutes les entités et aux relations porteuses de propriétés.
On dira d’un modèle qu’il est en première, deuxième ou troisième forme normale. Il s’agit là des
règles de normalisation les plus importantes, d’autres règles pouvant être appliquées mais de
manière non systématique.
La forme normale vient après la simple validité d'un modèle relationnel, c'est-à-dire que les valeurs
des différents attributs soient bien en dépendance fonctionnelle avec la clé primaire (complètement
déterminés par la clé primaire).
En pratique, la première et la deuxième forme normale sont nécessaires pour avoir un modèle
relationnel juste. Les formes normales supplémentaires ont leurs avantages et leurs inconvénients.
Definition
La normalisation des modèles de données permettra donc de s’assurer de la robustesse de la
conception de la base pour améliorer la modélisation (et donc obtenir une meilleure
représentation) et optimiser la mémorisation des données en évitant la redondance et les
problèmes sous-jacents de mise à jour ou de cohérence.

Les avantages sont :
 de limiter les redondances de données
 de limiter les incohérences de données qui pourraient les rendre inutilisables
 d'éviter les processus de mise à jour récurrents
Les inconvénients sont :
 des temps d'accès qui peuvent être plus longs si les requêtes sont trop complexes
 un manque de flexibilité au niveau de l'utilisation de l'espace de stockage
La troisième forme normale reste généralement une des meilleures solutions d'un point de vue
architecture de base de données, mais pour des bases de données plus importantes, cela n'est pas
toujours le cas. Il s'agit de choisir l'équilibre entre deux options :
 la génération dynamique des données via les jointures entre tables
 l'utilisation statiques de données correctement mises à jour
 La normalisation des modèles de données a été popularisée principalement par la méthode
Merise. La principale limite de la normalisation est que les données doivent se trouver dans
une même base de données (dans un seul schéma).
Avantages et inconvénients

Exemple
 client (code Cl, nom&prenom, age)
n’est pas en 1FN car nom&prenom n’est pas atomique on eclate la propriété nom&prenom
client (code Cl, nom,prenom, age)
client n’est en 1FN car âge n’est pas constant dans le temps
client (code Cl, nom,prenom,dateNaissance)
 Article(ref,designation,codeCategorie) n’est pas en 1FN car codeCategorie est répétitive
d’où on crée une entité categorie
 Notée 2FN - deuxième forme normale
La première forme normale :
Notée 1FN - première forme normale : Respecte la première forme normale, la relation dont tous
les attributs :
1- contiennent une valeur atomique. Ainsi, le nom et le prénom d’une personne doivent être dans
des propriétés distinctes.
2-contiennent des valeurs non répétitives (le cas contraire consiste à mettre une liste dans un seul
attribut). On pourrait citer pour exemple une catégorie d’articles qui doit être définie dans une
entité spécifique et non répétée dans l’entité article.
3-sont constants dans le temps (utiliser par exemple la date de naissance plutôt que l'âge).
La deuxième forme normale
Respecte la seconde forme normale, la relation respectant la première forme normale et dont :
Tous les attributs non-clés ne dépendent pas d'une partie de la clé primaire mais bien de la totalité
de la clé primaire.
Article
Ref
designation
Categorie
codeCategorie
nomCategorie
Appartient
1,1 0,N

 Le non-respect de la 2FN entraine une redondance des données qui encombrent alors
inutilement la mémoire et l'espace disque.
Autrement dit et exemple!!
 Une relation est dite en deuxième forme normale si elle est en première forme normale, et
si tout attribut n'appartenant pas à la clé primaire ne dépend pas d'une partie de cette clé.
EXEMPLE

LA TROISIÈME FORME NORMALE
 Notée 3FN - troisième forme normale
Autrement dit et exemple!!
 Une relation est dite en troisième forme normale si elle est en deuxième forme normale, et
si toutes les dépendances fonctionnelles issues de la clé primaire sont directes.
Exemple1
 R-MATERIEL (code matériel, libellé matériel, code marque, libellé marque)
 La dépendance entre "code matériel" et "libellé marque" n'est pas directe, "libellé marque"
est en dépendance fonctionnelle directe avec le "code marque".
code matériel code marque libellé marque
 La relation doit être éclatée en deux, pour être exprimée en troisième forme normale :
Respecte la troisième forme normale, la relation respectant la seconde forme normale et doit avoir
tous les attributs n'appartenant pas à la clé ne dépendent pas d'un attribut non-clé. En d'autre
terme, la dépendance fonctionnelle est directe.

Le Modèle logique de données
INTRODUCTION
Le MCD est une représentation du réel tel qu’il est perçu par l’utilisateur. Ce modèle, en tant
que formalisme (définir les entités, les associations et les propriétés et leur enchaînement
chronologique et fonctionnel) est commandé par l’utilisateur et donc, n’est pas remis en
cause par un changement de matériel ou de logiciel ou par des changements issus des
contraintes organisationnelles.
 De ce point de vue, le MCD constitue, dans l’ensemble des modèles proposés par la méthode
Merise, le modèle le plus stable.
PROBLÉMATIQUE :
 Toutefois le MCD reste un modèle abstrait. Les concepts (leurs définitions et leurs
comportements) ne sont pas représentés d’une manière qui pourrait conduire à un
traitement informatique facile et rapide.
 D’où la nécessité d’une étape intermédiaire - modèle logique des données (MLD) - proposant
une représentation de données en vue de leur traitement par ordinateur.
TRANSFORMATION D’UN INDIVIDU OU ENTITÉ TYPE
 Toute entité devient une table. Ses propriétés deviennent des attributs de la table (colonne).
 L’identifiant devient la clé primaire unique de la table.
R-MATERIEL
codemateriel
libellé materiel
R-marque
codemarque
libellé marque
Appartient
1,1 0,N

TRANSFORMATION D’UNE RELATION BINAIRE (0,N)-(1,1) OU (1,N)-(1,1)
 On duplique la clé issue de l’identifiant de l’individu porteur de la cardinalité (0,n) ou (1,n)
dans la table issue de l’individu à cardinalité (1,1).Celle-ci devient alors une clé étrangère.
 L’entité B est une entité source (ou entité père). L’entité A est une entité cible (ou entité
fils). La transformation se fait selon le principe : le père donne son nom à son fils.
Le fils attire le père
 Donc, l’entité père (l’entité B) donne son identifiant à l’entité fils (l’entité A).
Exemple :
Un Employé utilise un est un seul Ordinateur
un ordinateur est utilisé par plusieurs Employés
MAISON
IdMaison
Date Construction
Surface
MAISON
IdMaison
DateConstruction
Surface
entité table
1 ,1

SOLUTION
MCD
MLD
Personne
Code
Nom
prenom
Maison
IdMaison
DateConstruction
Surface
Possede
DateP
0,n
1,1
Personne
Code
Nom
prenom
Maison
IdMaison
DateConstruction
Surface
#Code
DateP
ORDINATEUR
Num
type
Modele
Employe
Code
nom
prenom
1,N
1,1

TRANSFORMATION D’UNE RELATION BINAIRE (0,N)-(0,1) OU (1,N)-(0,1)
Deux solutions :
 Création d’une table avec comme clé primaire l’identifiant de l’individu porteur de la
cardinalité (0,1) et comme clé étrangère l’identifiant de l’individu porteur de la cardinalité
(*, n).
 Duplication de l’identifiant de l’individu porteur de la cardinalité (*, n) dans la table issue de
l’individu porteur de la cardinalité (0,1) qui devient alors une clé étrangère. Il faut pour cette
deuxième solution que le SGBD cible accepte des valeurs nulles pour la clé étrangère.
Le fils attire le père
Exemple :
Remarque l’association Possède contient la propriété DateP
Solution 1
0,n
0,1
Personne
Code
Nom
prenom
Maison
IdMaison
DateConstruction
Surface
Possede
DateP

Solution 2 :
TRANSFORMATION D’UNE RELATION BINAIRE (0,1)-(1,1)
La clé issue de l’identifiant de l’entité porteuse de la cardinalité (0,1) est dupliquée dans la
table issue de l’entité porteuse de la cardinalité (1,1) et devient une clé étrangère.
L’association Parrain est une association porteuse car elle contient la propriétés DateP
Personne
Code
Nom
prenom
Maison
IdMaison
DateConstruction
Surface
Possede
IdMaison
Code
DateP
Personne
Code
Nom
prenom
Maison
IdMaison
DateConstruction
Surface
#Code
DateP
Contact
IdContact
Nom
prenom
Stagiaire
IdStagiaire
DateNaissance
#IdContact
DateP
0 ,1 1,1Parrain
dateP
Contact
IdContact
Nom
prenom
Stagiaire
IdStagiaire
DateNaissance

TRANSFORMATION D’UNE RELATION BINAIRE (0,1)-(0,1)
 C’est une particularisation des cas précédemment traités. 2 types de solutions sont possibles
Les solutions
Type de solution : Créer une table avec comme attributs les identifiants des individus en relation et
comme clé primaire l’un des identifiants d’une des deux tables. Les deux attributs sont des clés
étrangères.
1,1
Correspond
0,1
ENTREPRISE
IDEntreprise
Raison Sociale
…
TIERS
IdTiers
…
0,1

Exemple de schémas relationnels :
 Table ENTREPRISE(IDEntreprise, RaisonSociale,…)
 Table TIERS (IdTiers,…)
 Table CORRESPOND (Idtiers, IDEntreprise) ou table CORRESPOND(IdTiers, IDEntreprise)
2 type de solution : Duplication de la clé d’une des deux tables issues des entités types dans l’autre
table.
 Table ENTREPRISE (IDEntreprise,RaisonSociale,…,IDtiers)
 Table TIERS (IdTiers,…)
OU
 Table ENTREPRISE (IDEntreprise,RaisonSociale,…)
 Table TIERS (IdTiers,…,IDEntreprise)
TRANSFORMATION D’UNE RELATION BINAIRE (*,N)-(*,N)
 La table LOUER aura comme schéma relationnel LOUER (Code, IDMaison, DateEntree)
l’association Louer est une association porteuse car elle contient la propriétés DateEntree
solution :
La solution consiste à créer une table dont la clé sera une clé composée des identifiants des deux
entités en relation. Les propriétés éventuelles de la relation seront des attributs de la table.
Personne
Code
Nom
Prenom
Maison
IDmaison
Numero
rue
codePostal
Louer
dateEntree
0,n 0,n

TRANSFORMATION D’UNE RELATION TERNAIRE ET SUPÉRIEURE QUELLES QUE SOIT LES
CARDINALITÉS
 La relation donne lieu à la création d’une table qui aura comme clé primaire une clé
composée des identifiants des individus sur lesquels portent la relation.
MAISON
IdMaison
DateConstruction
Surface
ENTREPRISE
IdEntreprise
Raison Sociale
…
TYPE TRAVAUX
IdTypeTravail
Désignation Travail
…
Réaliser
Date Réalisation
*,n *,n
*,n

 La table REALISER aura comme schéma relationnel
 REALISER (IdEntreprise, IDMaison, IdTypeTravail, DateRealisation)
Application
 Trouvez le modèle logique de données
Solution :

Application 2
Solution :

Application 3
Solution :

Application 4
APPLICATION DES RÈGLES DE PASSAGE SUR UNE RELATION RÉFLEXIVE
Soit l’exemple suivant
Le Modèle logique équivalent est :
Avion
numV
marque
nbplaces
vol
numVo
DateVo
ville
numV
nomV
Utilise
Escale
Départ
Arrivé
1,N 1,1
1,1
1,1
0,N
0,N
0,N
0,N
Employe
ID_Emp
nom
prenom
Est chef de A pour chef
1,1
0,N
Employe
ID_Emp
nom
prenom
#ID_EmpChef

Exemple 2
Le Modèle logique équivalent est :
APPLICATION DES RÈGLES DE PASSAGE SUR UNE ENTITÉ FAIBLE
Exemple1 :
On a un hôtel qui est constitué de plusieurs étages, les chambres sont numérotées de 1 à 10 sur
chaque étage.
Etage4 1 2 3 4 5 6 7 8 9 10
Etage 3 1 2 3 4 5 6 7 8 9 10
Etage2 1 2 3 4 5 6 7 8 9 10
Etage1 1 2 3 4 5 6 7 8 9 10
Ici l’entité chambre est une entité faible car NumCh tout seul ne peut pas definir une chambre, une
chambre est bien défini si on spécifie l’etage, d’où NumEt,NumCh une chambre,une entité faible
est représenté par (1,1)
D’où le modèle logique équivalent est :
Article
Ref
Designation
Prix
Composition
Qtite
0,N
0,N
Article
Ref
Designation
Prix
Composition
Ref
Ref Composant
Qtite
Hotel
NumHo
Adresse
Etage
NumEt
Chambre
NumChAppartient
Appartient
1,N
1,1
1,N
(1,1)

Remarque : NumEt est dupliqué sur la table Chambre autant que clé étrangère et clé primaire car
chambre est une entité faible.
Exemple 2
D’où le modèle logique équivalent est :
Hotel
NumHo
Adresse
Etage
NumEt
#NumHo
Chambre
NumCh
#NumEt
jour
NumJ
NomJ
semaine
NumS
Annee
Annee
Appartient
(1,1) 1,N
Appartient
(1,1) 1,N
jour
NumJ
NumS
Annee
NomJ
semaine
NumS
Annee
Annee
Annee

Mon cours merise v2017

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Mon cours merise v2017

Similaire à Mon cours merise v2017 (20)

Dernier

Dernier (20)

Mon cours merise v2017