2 Merise

A.
U : 2022/2023
Filière : ISIC
Semestre : II
Cours de Systèmes d’Informations et Bases de

données
Chapitre 2 : Conception de système
d’informations
Préparé par : Pr. Baidada chafik
Plan
1. La modélisation avec MERISE
2. Modèle Conceptuel de données (entité information)
3. Modèle Logique de données (Modèle relationnel)
4. Modèle Physique
Modélisation
Un modèle est une représentation abstraite de la réalité qui exclut certains
détails du monde réel.
3
Modélisation
• Avantages de la modélisation:
1. anticiper d’éventuels problèmes de ressources avant même qu’ils ne se manifestent,
2. d’optimiser les échanges et la compréhension entre les différents services de

l’entreprise
3. apporte une assurance supplémentaire au niveau de la qualité, de la sécurité, et de

l’accessibilité des données subordonnées.
Réduire les couts
4
Modélisation
• Les langage de modélisation sont des langage qui définissent :
• La sémantique des concepts ;
• Une notation pour la représentation de concepts ;
• Des règles de construction et d'utilisation des concepts.
• Des langages à différents niveaux de formalisation

• Langages formels (Z,B,VDM) : le plus souvent mathématiques, au grand pouvoir
d'expression et permettant des preuves formelles sur les spécification;
• Langages semi-formels (MERISE, UML...) : le plus souvent graphiques, au pouvoir
d'expression moindre mais plus faciles d'emploi.
• Dans ce chapitre on va se concentrer sur la méthode MERISE

5
La méthode MERISE Présentation
• MERISE : Méthode d’Etude et de Réalisation Informatique pour les Systèmes

d’Entreprise
• Méthode françaises (1978-1979) crée par le ministère de l'Industrie
• Le but de cette méthode est d'arriver à concevoir un système d'information
• basée sur la séparation des données et des traitements
• Se base sur les modèle : Entité association et le modèle relationnel

La méthode MERISE
• La conception du système d'information se fait en 4 étapes
successifs:
1. Expression des besoins
- Faire l'inventaire des éléments nécessaires au système d'information
- Délimiter le système en s'informant auprès des futurs utilisateurs
2. Modèle conceptuel
- Identifier es règles de gestion en répondant à la question Quoi faire
?
3. Modèle logique ou organisationnel
- Identifier les ressources employées pour la mise en place de
l’ensemble de règles de gestion identifiées au niveau conceptuel Qui
? Où ? Quand ?
4. Modèle physique
- Identifier et les moyens utilisés (choix matériel) pour gérer les
données et pour activer les traitements
Plan
1. La modélisation avec MERISE
4. Modèle Physique
Modèle Logique des données
Modèle conceptuel de données (MCD)
 Il s’appuie sur le modèle Entité relation
 Entité relation est proposé par Chen en 1976
 Modèle sémantique pour comprendre et visualiser l’organisation des données
 Également appelé modèle EAR (Entité-Attribut-Relation)
 Objectif : concevoir un Modèle Conceptuel de Données (MCD)
Objectifs et démarche :
Modèle entité relation
Observation de la réalité
Modélisation des
informations
 Schéma entités-associations (i.e MCD)
 Entité :
 Une entité est une population d’individus (ensemble) homogènes.
 Peut être considérée comme une boite contenant plusieurs individus
 Par exemple, les produits ou les articles vendus

par une entreprise peuvent être regroupés dans une même entité
articles
11
 Formalisme :
 Une entité est représentée par un rectangle avec le nom de l’entité
en haut.
Entité
12
 Exemples:
13
 Attributs
 Un attribut est une propriété d’une entité.
 Toujours dans notre exemple le prix unitaire est un attribut de l’entité articles, le
nom de famille est un attribut de l’entité clients, etc..
14
 Attributs
 Une entité avec attributs peut être représentée par du texte comme suit :
 Clients (numéro client, nom client, prénom client, adresse client …)

 Articles (numéro article, désignation, prix unitaire…)
15
Une occurrence
 Une occurrence d’une entité est une instance (un représentant) de l’entité
dans le monde réel .
 Exemple: - C10000
- BAIDADA
- Chafik
Clients - C10001
-numClient - EL Azizi
-nomClient - Kawtar
-prénomClient
…… - C10002
- ESSABIR
- Mohammed
16
Dépendance fonctionnelle
• Dépendances fonctionnelles : Définition
• Une dépendance fonctionnelle entre deux groupes de données A et B est une relation de telle façon que :
• Un élément du groupe A (source) permet de déterminer un élément du groupe B (cible).
Dépendances entre les éléments des deux ensembles A et B

• Exemple :
C1 A1
C2 A2
C3 A3
Pour les entités Clients et articles, on peut déduire que :

Les clients C1 et C3 ont respectivement une relation avec l’article A2 et A3
ces relations sont symbolisées sous cette forme : C1 -> A2 et C3->A3
On peut avoir des dépendances fonctionnelles au sein de la même entité :

• Un attributs dans une entité peut avoir des dépendances fonctionnelles avec d’autres attributs:
• Exemple : Code de Formation Titre de Formation Durée Prix
ID01 Introduction au développement 3 mois 2500
CCP01 C/C++ 30 jours 3000
ID02 Introduction au développement 3 mois 2700
BD001 Base de données 30 jours 2500
Dans cette exemple l’attribut code formation est en relation avec l’attribut titre de formation.
Cette dépendance peut être décrite sous la forme :
• codeForm -> titreForm.
 Association
 Une association est une liaison qui a une signification précise entre plusieurs entités
 Dans notre exemple, l’association commander est une liaison évidente entre les
entités articles et clients, tandis que l’association livrer établit le lien sémantique
entre les entités articles et fournisseurs.
20
Attributs d’association
 Une association peut avoir un des attribut.
 Exemple :
Clients articles fournisseurs

-numClient -numArticle
commander -désignatArcticle livrer -numFourni
-nomClient
prixUnitArticle -tel Fornisseur
-prénomClient date …..
…… ….
21
 Identifiant
 Chaque individu d’une entité doit être identifiable de manière unique
 C’est pourquoi toutes les entités doivent posséder un attribut sans doublon
 Il s’agit de l’identifiant que l’on souligne sur le schéma, par convention

commander -désignatArcticle livrer -numFourni
-nomClient
-prénomClient
…. …..
……
22
 Cardinalités
 La cardinalité d’un lien entre une entité et une association précise le minimum et le
maximum de fois qu’un individu de l’entité peut être concerné par l’association.
 un client a au moins commandé un article et peut commander n articles (n étant
indéterminé)
 tandis qu’un article peut avoir été commandé entre 0 et n fois. On obtient alors le
schéma entités-associations complet:
23

1,n 1,n 1,n
0,n
commander -désignatArcticle
livrer -numFourni
-nomClient
-prénomClient
…. …..
……
24
25
Exemple :
 Soit les règles de gestion suivante (simplifiées) :
 Les étudiants sont caractérisés par (NoEtudiant, nom, prénom, adresse...)
 Les enseignants sont caractérisés par (NoEnseignant, nom, prénom, adresse...)
 Les cours sont identifiés par un numéro NoCours est caractérisés par un intitulé, une
date et une heure de début, une durée,
 Les étudiants sont inscrits dans un ou pusieurs cours
 un cours est assuré par un seul enseignant.
 Un enseignant peut assurer plusieurs cours
Donner le MCD correspondant

26
1,n 1,n
1,1
1,n
27
Exercice
En analysant le schéma du MCD ci-dessus, répondre aux
questions suivantes :
1) Un patient peut-il effectuer plusieurs visites ?
2) Un médecin peut-il recevoir plusieurs patients dans la
même consultation ?
3) Peut-on prescrire plusieurs médicaments dans une même
consultation ?
4) Deux médecins différents peuvent-ils prescrire le même
médicament ?
28
 Solution
1) Oui : car la cardinalité (1,n) existant entre l’entité « PATIENT » et l’entité « Assiste » exprime le fait qu’une occurrence
d’un patient peut participer plusieurs fois à l’association « Assiste ».
2) Non : car une consultation est donnée par un et un seul médecin (cardinalité (1,1) entre l’entité « CONSULTATION » et
l’association « Donne ») et de même seul un patient assiste à une consultation (cardinalité (1,1) entre l’entité
«ONSULTATION » et l’association « Assiste »).
3) Oui : ceci est exprimé par la cardinalité (0,n) entre l’entité « CONSULTATION » et l’association « Prescrit » qui signifie
qu’une occurrence de consultation peut ne pas participer du tout dans la relation « Prescrit » (c’est le cas où le médecin ne
prescrit pas de médicaments au patient) comme elle peut participer plusieurs fois, ce qui correspond aux différents
médicaments donnés pour un malade.
4) Oui : rien n’empêche que deux médecins prescrivent le même médicament pour deux consultations différentes. Ceci est
bien exprimé par la cardinalité (0,n) entre l’entité « MEDICAMENT » et la relation « Prescrit » qui signifie qu’une occurrence
d’un médicament peut participer plusieurs fois à l’association comme elle peut ne pas participer du tout (c’est le cas où un
médicament n’est jamais prescrit
29
 Associations plurielles, réflexives et n-aires
 Associations plurielles
 La figure ci-dessous montre un exemple d’associations plurielles entre un type-entité Personne et un
type-entité Livre.
30
 Associations réflexives
 Un type-association est réflexif s’il définit une relation entre un type-entité et lui-
même.
31
 La dimension :
 La dimension d’une association représente le nombre d’entité qu'elle relie:
 les associations binaires : ce sont les associations qui relient deux entités ( dimension=2).
 les associations réflexives : ce sont les associations qui relient une seule entité ( dimension=1).
32
 Associations n-aires
 le terme d'association n-aire pour qualifier une association de dimension supérieure ou égale à trois,
bien que ce terme puisse également désigner de manière générale une association binaire (2-aire) ou
réflexive (1-aire).
Cette relation peut être lue par :

• Un professeur enseigne 1 ou plusieurs matières pour
1 ou plusieurs classes.
• Une matière est enseignée par 1 ou plusieurs profs
pour 1 ou plusieurs classe
• Une classe est enseignée 1 ou plusieurs matières
par 1 ou plusieurs profs
Remarques:
• les cardinalités maximales valent tous n (obligatoire)
33
Exercice 2
Les règles de gestion pour une entreprise sont:
1. L’entreprise est constituée de plusieurs services
2. Un employé peut occuper plusieurs emploi dans plusieurs services différents
Solution EX2
1,n 0,n
0,n
34
Normalisation des données
Forme normale:
 Les formes normales permettent la décomposition des entités en des relations, sans perdre
d'informations, en se basant sur les de dépendances fonctionnelles, dans le but de construire
un schéma conceptuel représentant de manière correcte les associations canoniques du
monde réel.
 Au niveau de la base de données, ce travail permet d’éviter les redondances et facilite la
maintenance des données
 Il existe différents niveaux de formes normales :
 Première forme normale (1FN ou 1NF)
 Deuxième forme normale (2FN ou 2NF)
 Troisième forme normale (3FN ou 3NF)
 Quatrième forme normale (4FN – NF4)
 Forme normale de Boyce-Codd (FNBC ou BCNF)
35
Les formes normales
 Première forme normale (1FN):
 Une relation (une entité) est en 1FN si et seulement si tout attribut contient une
valeur atomique.
 Tous les attributs sont élémentaires (ou atomiques). C’est-à-dire qu’un attribut
contient une seule information.
 Elle ne contienne pas de structures répétitives.
36
Les formes normales
 Première forme normale :
• Exemple:
37
 2FN - Deuxième forme normale
 Une relation est en 2FN si :
 Elle respecte la 1FN.
 Il existe un groupe d’attributs constituant la clé (et un groupe
d’attributs non clé).
 Tout attribut non clé est en dépendance fonctionnelle directe avec
l’ensemble du groupe définissant la clé.
38
 2FN - Deuxième forme normale
Exemple :
Prêt
Num_etudiant
NumLivre
Nom_etud
Prenom_etud
NomLivre
Auteurs
date_emprunt
n’est pas en 2ème FN car « Nom_etud » ne dépend que de Num_etudiant, et de même

« NomLivre », et « Auteurs » ne dépend que de NumLivre
39
• Troisième forme normale (3FN)
 Une relation est en 3FN si :
 Elle respecte la 2FN
 Tout attribut n’appartenant pas à la clé n’est pas en dépendance

fonctionnelle directe avec un ensemble d’attributs non clé (un ensemble
d’attributs qui ne constitue pas une clé candidate pour la relation).
 C’est-à-dire que tout attribut non clé ne dépend pas d’un ou plusieurs
attributs ne participant pas à la clé
40
 3FN – Troisième forme normale
Exemple :
Employé
Num_Som
Nom
Prenom
Service
Adresse_service
Adresse_service dépend de service, la relation n’est pas en 3eme FN
41
Le Modèle logique de données(MLD)
42
Exercice 1
Diplômé(N_Diplomé, prénom, diplôme, institution )
Pavillon(N_Pavillon, Adresse, Occupants)
Questions : Mettre les deux relations suivantes en 1NF :

Solution
• Commençons par la première entité Diplômé. On remarque que l’attribut institution est un attribut composé :
chaque institut à un nom un type une adresse un téléphone .... Donc il faut créer une nouvelle entité appelée
institution et la relier à l’entité Diplômé.
• Pour la deuxième entité Pavillon, on remarque aussi que l’attribut Occupants est un attribut composé, ce qui
ne pousse à scinder l’entité Pavillon en créant une nouvelle entité Occupant avec les attributs nom, prénom
numéro
42
43
Exercice 2
En quelle forme normale est la relation suivante qui concerne les employés d’une société
implantée sur plusieurs bâtiments ?
EMPLOYES (NumE, Nom, Salaire, Département, Bâtiment)
Questions :
Sachant qu’un employé travaille dans un département donné, et qu’aucun département
possède des locaux dans plusieurs bâtiments. Mettre en 3NF le cas échéant
Solution :
• EMPLOYES(NumE, Nom, Salaire, N_Département)
• DEPARTEMENT (N_Département, Nom_Déprt, Nbre_Emp, N_Bâtiment )
• BATIMENT (N_Bâtiment , Nbre_Déprt, Adresse_Bâti,Surface_Bâti)
43
44
Exercice 3
 Les règles de gestion :
 Un club vidéo propose des cassettes et des DVD en location à ses membres.
Pour chaque membre, on enregistre le nom, l’adresse, le numéro de téléphone.
On lui donne un numéro d’inscription qui l’identifie. Chaque support est
caractérisé par son type (cassette ou DVD), un code identifiant et la date
d’achat. Pour le film du support, on enregistre le titre (identifiant), son
réalisateur, l’acteur vedette et le genre. Plusieurs supports peuvent être
disponibles pour un même film, alors que pour certains films, il n’existe pas
encore de supports proposés à la location. A tout instant, un support peut être
loué par un membre du club.
44
 Correction :
46
Exercice 3 ( suite)
 Chaque support est en outre caractérisé par le nombre d’emprunts, le titre du film, son
réalisateur, ses principaux acteurs (nom et prénom, tous deux identifiants, ainsi que la date
de naissance), la date de sortie du film. Pour chaque location, on connaît le support, la date
d’emprunt, la date normale de restitution, la date de restitution effective et l’emprunteur.
Une location dure un nombre entier de jours (au moins un). On conserve l’historique des
locations.
Suggestion. On représentera les emprunts en cours et les emprunts clôturés par un même
entité.
46
 Correction :
Plan
1. La modélisation
2. La méthode MERISE
5. Modèle Physique
Modèle Logique des données
 Après avoir conçu le Modèle Conceptuel de Donnée (MCD), l’étape suivante est de le
transposer en Modèle Logique de Données (MLD)
 MLD est en fait le dernier pas vers le Modèle Physique de donnée (MPD)
 Le MLD se base sur le modèle Relationnelle
 Dans ce qui suit, on va définir les notions relatives aux modèles relationnels, et nous
appliquons les règles nécessaires et suffisantes pour passer d'un MCD à un MLD
relationnel.
50
Le Modèle logique de données(relation)
• Une relation (table) est ensemble d’agrégats de valeurs, chacune

appartenant à un domaine.
• Exemples : relations
• PERSONNE ( D_Num_securite_sociale x D_Nom x D_Prenom x D_Code_postal x D_Telephone)
• (
STAGE D_Num_securite_sociale x D_type_stage x D_Titre x D_date_deb)
PERSONNE Num_securite_sociale Nom Prenom Code_postal Telephone
1 76 02 99 167 098 Baidada Chafik 4150006 08 78 65 88
2 76 04 95 165 008 Boudaa Tarik 3190002 99 167 098
1 78 12 38 122 4332 Fahim Mohammed 3870004 38 56 45 32

Le Modèle logique de données ()
• Un enregistrement (ligne ou n-uplet) est un élément d’une relation (

table).
Exemples : 2 relations
• PERSONNE  D_Num_securite_sociale x D_Nom x D_Prenom x D_Code_postal x D_Telephone
• STAGE  D_Num_securite_sociale x D_type_stage x D_Titre x D_date-deb

n-uplet1 1 76 02 99 167 098 Dupont Marcel 41500 06 08 78 65 88
n-uplet2 2 76 04 95 165 008 Durand Elisabeth 31900 02 99 167 098
n-uplet3 1 78 12 38 122 4332 Faure Bertrand 38700 04 38 56 45 32
n-uplet4 1 68 02 99 5649 876 Dumontier Michel 75016 01 55 45 34 87
STAGE Num_securite_sociale D_type_stageTitre Date-debut

n-uplet1 1 76 02 99 167 098 Inge_Adjoint Définition d'une politique Qualité 01/02/2006
n-uplet2 2 76 04 95 165 008 Inge_Adjoint Mise en place d'un SI pour la maintenance 02/02/2006
n-uplet3 1 68 02 99 5649 876 EDT Reconfiguration des achats 15/03/2005
n-uplet5 1 76 02 99 167 098 PFE Mise en place d'un ERP 15/03/2005
Le Modèle logique de données (attribut)
• Un attribut (colonne) est un composant de même rang d’une relation ( table).
Exemples :

n-uplet1 1 76 02 99 167 098 Dupont Marcel 41500 06 08 78 65 88
n-uplet2 2 76 04 95 165 008 Durand Elisabeth 31900 02 99 167 098
n-uplet3 1 78 12 38 122 4332 Faure Bertrand 38700 04 38 56 45 32
n-uplet4 1 68 02 99 5649 876 Dumontier Michel 75016 01 55 45 34 87
STAGE Num_securite_sociale D_type_stageTitre Date-debut

n-uplet1 1 76 02 99 167 098 Inge_Adjoint Définition d'une politique Qualité 01/02/2006
n-uplet2 2 76 04 95 165 008 Inge_Adjoint Mise en place d'un SI pour la maintenance 02/02/2006
n-uplet5 1 76 02 99 167 098 PFE Mise en place d'un ERP 15/03/2005
Le Modèle logique de données (clé)
• Toute relation ou table doit comporter parmi l’ensemble de ses constituants un sous
ensemble qui identifie sans ambiguïté chaque n-uplet : ce sous ensemble est appelé
« clé » de la relation.
• Les constituants de ce sous ensemble sont présentés soulignés.
Exemples : clé d’une relation
• PERSONNE (Num_securite_sociale, Nom , Prénom , Code_postal, Téléphone)

• STAGE ( Num_securite_sociale , type_stage , Titre, Date-début )
Le Modèle logique de données
Lorsque une clé primaire d’une table est utilisée comme référence dans une autre table. On la nomme
« clé étrangère » de la seconde table.
ARTICLE (Code_article : entier long,
CLIENT (Num_client : entier long , Désignation : chaine de 50 caractères,
Nom : chaine de 30 caractères, prix : monétaire )
Prenom : chaine de 20 caractères, LIGNECOMMANDE (code_article : entier long ,
Code_postal : chaine de 5 chiffres , Num_commande : entier long ,
Telephone : chaine de 10 chiffres ) quantité : entier)
COMMANDE (Num_commande : entier long ,
date : date,
montant : monétaire
num_client : entier long )
MCD  MLD
L'étape de transformation du MCD en MLD est assez simple et

passe par trois étapes :
1. Transformation des entités en tables,

2. Transformation des relations du MCD,
3. Suppression des tables inutiles.
56
MCD  MLD
 Construction des tables
 La première étape consiste à transformer toutes les entités du MCD en
tables du MLD.
 Cette transformation est directe : il suffit de recopier les entités. Il s'agit
essentiellement d'un changement de vocabulaire :
• une entité devient une table,
• une propriété devient un champ,
• un identifiant devient une clé primaire.
 A noter toutefois qu'il est essentiel qu'il n'y ait pas deux tables qui aient le
même nom.
57
MCD  MLD
 Exemple:
 la première partie de la construction du MLD du libraire est
directe. Il suffit de recopier les entités.
58
MCD  MLD
 Transformation des relations en liens
 Pour les associations. Dépend des cardinalités. Deux grand cas

possibles :
 Relation K:1 K:N
avec K={1,0}
 Relation K:n K:n
avec K={1,0}
59
MCD  MLD
Relation binaire aux cardinalités (K,1) - (K,n), K= {0 ou 1}
 Dans le cas de cette relation où l'une des branches a une cardinalité de 1:1
ou 0:1, la transformation de la relation se fait de la manière suivante :
 On ramène dans la table correspondant à l'entité "du côté du 1:1" (ou du 0:1) la clé
primaire de l'autre table ainsi que toutes les éventuelles propriétés de la relations.
 On lie la clé primaire ainsi importée avec la clé primaire de la deuxième table.
 Si la relation contenait des propriétés, celle-ci se retrouve également importée du

côté du 1:1
60
MCD  MLD
K,1 K,N
Se transforme en:
A noter que la clé importée (ici IdB qui se retrouve dans table A) ne devient pas
une clé de la table : c'est une propriété comme une autre. Notons aussi que le lien se
fait entre champs (on relie IdA à IdB) et non pas, comme dans le MCD, entre les
tables.
61
62
MCD  MLD
EntitéB
EntitéA
K:n relation K:1
IdA IdB
propriétéR
PropriétéA1 propriétéB1
devient
TableA
TableB
PK_IdA PK_IdB
Champ A1 Ch_propriété B1
FK IdA
Ch_proriété R
62
MCD  MLD
 Le MLD correspondant:
Client (Nclient, Société, Contact, Fonction, Ville)

Commande (NCommande, DateCommande, #Nclient)
63
MCD  MLD
Relation binaire aux cardinalités (K,N) - (K,n), X= {0 ou 1}
 Il y a création d'une table supplémentaire ayant comme Clé Primaire une clé composée
des identifiants des 2 entités. On dit que la Clé Primaire de la nouvelle table est la
concaténation des Clés Primaires des deux autres tables.
 Cette table contient toutes les éventuelles propriétés de la relation.
 On relie les clés primaires des tables avec les clés importées dans la nouvelle table.
 On choisit enfin la ou les clés primaires de la nouvelle table. L'idée générale est que
chaque occurrence de cette entité doit pouvoir être identifiée de manière unique par ses
clés primaires. 64
MCD  MLD
 Cela revient en général à choisir comme clés primaires l'ensemble de clés
importées des autres tables.
 Se transforme en:
65
MCD  MLD
 Exemple: soit le MCD suivant
66
MCD  MLD
• Le MLD correspondant :
COMMANDE (NCommande, DateCommande)

PRODUIT (Nproduit, ComProduit)
DétailCom (#NCommande, #Nproduit, quantité, PrixUnitaire)
67
MCD  MLD
Cas particuliers
 Quelques cas particuliers peuvent apparaitre.
 Si la relation est de type 1:1 - 1:1, on fusionne les deux entités en une.
Ce type de relation rare est souvent dû à un problème dans la
conception du MCD.
 Si la relation est de type 0:1 - 1:1, on traite la relation comme une

relation de type 1:1 ?:?(en ramenant la clé primaire du côté du 1:1)
68
MCD  MLD
Cas particuliers
 Les relations réflexives (entre une entité et elle-même) se traitent comme
les autres relations.
 les relations ternaires (entre trois entités, ou plus), se traitent comme

d'habitude.
Si l'une des branches a une cardinalité de type 1:1, on ramène les clés primaires des
autres entités et les propriétés de la relation dans l'entité "du côté du 1:1".
Si ce n'est pas le cas, la relation se transforme en table.
69
MCD  MLD
 Suppression des tables inutiles
 La dernière étape consiste simplement à supprimer les tables inutiles.

 En général (mais pas toujours), une table qui ne contient qu'un seul
champ (sa clé) est inutile : elle ne nous apporte aucune information.
 L'exemple le plus classique est une entité de type "date".
70
MCD  MLD: A retenir
La méthode de transformation MCD-MLD :

1. les entités sont transformées en tables (sans modification)
2. les relations sont transformées en fonction de leurs cardinalités

a. pour une relation de type 1:1 - ?:? entre une entité A et une entité B se traduit par
une importation de la clé primaire de l'entité B dans la table de A, et on ajoute un
lien entre les deux clés,
b. une relation autre (sans 1:1 - ?:?) se transforme en table dans laquelle on retrouve
les clés primaires de A et B.
3. les tables inutiles sont supprimées : il s'agit essentiellement des tables à un seul
champ (leur clé).
71
MCD MLD: Quelques cas particuliers
Relation binaire (0,1)-(1,1):

• On duplique la clé de la table basée sur l'objet à cardinalité (0,1) dans la table basée sur l'objet à
cardinalité (1,1).
72
MCD MLD: Quelques cas particuliers
Plusieurs relations entre 2 objets
• Les règles générales s'appliquent.
73
MCD  MLD: Quelques cas particuliers
Relation binaire (0,1)-(0,1):

 On duplique la clé d'une des tables dans l'autre lorsque la relation contient elle-même
des propriétés, celles-ci deviennent également attributs de la table dans laquelle a été
ajoutée la clé étrangère.
74
MCD  MLD: Exercices
Exercice «Gestion d'école»
• Transformez le MCD suivant, qui représente «la gestion d'une école» en un MLD en respectant toutes
les règles du passage MCD à MLD.
75
MCD>>MLD: Exercices
 Correction:
76
MCD>>MLD: Exercices
 Transformez le MCD suivant en un MLD :
77
MCD>>MLD: Exercices
 Correction:
78
MCD>>MLD: Exercices
79
 Transformez le MCD
suivant En un MLD :
MCD>>MLD: Exercices
 Correction:•
80
Plan
1. La modélisation
2. La méthode MERISE
5. Modèle Physique
Modèle Physique
Modèle Physique
 Constitué de tables relationnelles, constituées d'attributs typés, parmi

lesquels :
 une clé primaire identifiant de manière unique chaque occurrence de la table.

 éventuellement une ou plusieurs clés étrangères : clés primaires dans une autre table
 Les types de données peuvent varier selon les systèmes de gestion de bases
de données.
83
Modèle Physique
84
Modèle Physique
85
Modèle Physique
86
Modèle Physique
• Exemple :
87
Merci !!!

2 Merise

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

2 Merise

Transféré par

Droits d'auteur :

Formats disponibles

A.

Cours de Systèmes d’Informations et Bases de

1. La modélisation avec MERISE

2. Modèle Conceptuel de données (entité information)

3. Modèle Logique de données (Modèle relationnel)

1. anticiper d’éventuels problèmes de ressources avant même qu’ils ne se manifestent,

2. d’optimiser les échanges et la compréhension entre les différents services de

3. apporte une assurance supplémentaire au niveau de la qualité, de la sécurité, et de

Réduire les couts

• Des langages à différents niveaux de formalisation

• Dans ce chapitre on va se concentrer sur la méthode MERISE

• MERISE : Méthode d’Etude et de Réalisation Informatique pour les Systèmes

• Méthode françaises (1978-1979) crée par le ministère de l'Industrie

• Le but de cette méthode est d'arriver à concevoir un système d'information

• basée sur la séparation des données et des traitements

• Se base sur les modèle : Entité association et le modèle relationnel

1. La modélisation avec MERISE

2. Modèle Conceptuel de données (entité information)

3. Modèle Logique de données (Modèle relationnel)

Modèle entité relation

 Peut être considérée comme une boite contenant plusieurs individus

 Par exemple, les produits ou les articles vendus

 Clients (numéro client, nom client, prénom client, adresse client …)

Dépendances entre les éléments des deux ensembles A et B

Pour les entités Clients et articles, on peut déduire que :

On peut avoir des dépendances fonctionnelles au sein de la même entité :

• Exemple : Code de Formation Titre de Formation Durée Prix

ID01 Introduction au développement 3 mois 2500

CCP01 C/C++ 30 jours 3000

ID02 Introduction au développement 3 mois 2700

BD001 Base de données 30 jours 2500

Clients articles fournisseurs

Clients articles fournisseurs

Clients articles fournisseurs

Donner le MCD correspondant

Cette relation peut être lue par :

 Elle ne contienne pas de structures répétitives.

n’est pas en 2ème FN car « Nom_etud » ne dépend que de Num_etudiant, et de même

 Tout attribut n’appartenant pas à la clé n’est pas en dépendance

Adresse_service dépend de service, la relation n’est pas en 3eme FN

Questions : Mettre les deux relations suivantes en 1NF :

3. Modèle Conceptuel de données (entité information)

4. Modèle Logique de données (Modèle relationnel)

 Le MLD se base sur le modèle Relationnelle

• Une relation (table) est ensemble d’agrégats de valeurs, chacune

PERSONNE Num_securite_sociale Nom Prenom Code_postal Telephone

1 76 02 99 167 098 Baidada Chafik 4150006 08 78 65 88

2 76 04 95 165 008 Boudaa Tarik 3190002 99 167 098

1 78 12 38 122 4332 Fahim Mohammed 3870004 38 56 45 32

• Un enregistrement (ligne ou n-uplet) est un élément d’une relation (

PERSONNE Num_securite_sociale Nom Prenom Code_postal Telephone

STAGE Num_securite_sociale D_type_stageTitre Date-debut

PERSONNE Num_securite_sociale Nom Prenom Code_postal Telephone

STAGE Num_securite_sociale D_type_stageTitre Date-debut

Exemples : clé d’une relation

• PERSONNE (Num_securite_sociale, Nom , Prénom , Code_postal, Téléphone)

L'étape de transformation du MCD en MLD est assez simple et

1. Transformation des entités en tables,

 Pour les associations. Dépend des cardinalités. Deux grand cas

 Relation K:n K:n

 Si la relation contenait des propriétés, celle-ci se retrouve également importée du

Client (Nclient, Société, Contact, Fonction, Ville)

 Cette table contient toutes les éventuelles propriétés de la relation.