0% ont trouvé ce document utile (0 vote)
3 vues15 pages

Cours Merise

MERISE est une méthode française de conception de systèmes d'information, structurée en trois niveaux d'abstraction : conceptuel, organisationnel/logique et physique. Elle permet de séparer les données des traitements, de faciliter la communication entre équipes et de produire une documentation claire. Le document détaille également les modèles conceptuels des données, des traitements, et les étapes de la démarche MERISE, ainsi que des exemples pratiques.

Transféré par

athurggd2
Copyright
© All Rights Reserved
Nous prenons très au sérieux les droits relatifs au contenu. Si vous pensez qu’il s’agit de votre contenu, signalez une atteinte au droit d’auteur ici.
Formats disponibles
Téléchargez aux formats PDF, TXT ou lisez en ligne sur Scribd
0% ont trouvé ce document utile (0 vote)
3 vues15 pages

Cours Merise

MERISE est une méthode française de conception de systèmes d'information, structurée en trois niveaux d'abstraction : conceptuel, organisationnel/logique et physique. Elle permet de séparer les données des traitements, de faciliter la communication entre équipes et de produire une documentation claire. Le document détaille également les modèles conceptuels des données, des traitements, et les étapes de la démarche MERISE, ainsi que des exemples pratiques.

Transféré par

athurggd2
Copyright
© All Rights Reserved
Nous prenons très au sérieux les droits relatifs au contenu. Si vous pensez qu’il s’agit de votre contenu, signalez une atteinte au droit d’auteur ici.
Formats disponibles
Téléchargez aux formats PDF, TXT ou lisez en ligne sur Scribd

Cours Approfondi sur MERISE

Méthode d’Étude et de Réalisation Informatique par Sous-


Ensembles

Introduction Générale
MERISE est une méthode française de conception et de développement de systèmes
d’information, créée dans les années 1970-1980. Elle est encore aujourd’hui très utilisée
dans les entreprises françaises et dans l’enseignement.

Pourquoi MERISE ?
Structurer la réflexion avant de coder

Séparer les données des traitements

Communiquer entre équipes techniques et métier

Produire une documentation claire et rigoureuse

Les 3 niveaux d’abstraction de MERISE

Modèles
Niveau Description
concernés

Le QUOI — ce que fait le système, sans se


Conceptuel MCD, MCT
soucier du comment

Le QUI, OÙ, QUAND — organisation humaine MOD, MOT,


Organisationnel/Logique
et logique MLD

Le COMMENT — les moyens techniques mis


Physique MPD, MPT
en œuvre

PARTIE 1 — Le Système d’Information (SI)


1.1 Définition
Un système d’information est l’ensemble des ressources (humaines, matérielles,
logicielles, données) permettant de collecter, stocker, traiter et diffuser l’information au sein
d’une organisation.

1.2 Les 4 fonctions du SI


1. Collecter : recueillir les données de l’environnement

2. Mémoriser : stocker les données de manière durable

3. Traiter : transformer les données en informations utiles

4. Diffuser : transmettre les informations aux utilisateurs

1.3 Les sous-systèmes


Système de pilotage : prend les décisions

Système opérant : réalise les activités

Système d’information : assure la communication entre les deux

PARTIE 2 — Le Modèle Conceptuel des Données (MCD)


Le MCD représente la structure des données de manière indépendante de tout choix
technique. C’est le cœur de MERISE.

2.1 Les entités


Une entité (ou objet) représente un objet du monde réel sur lequel on veut stocker des
informations.

Règles de notation :

Rectangle avec le nom de l’entité en majuscules

Liste des attributs à l’intérieur

Un attribut souligné = identifiant (clé primaire)

Exemple :

┌─────────────┐
│ CLIENT │
├─────────────┤
│ #numClient │ ← identifiant (souligné)
│ nomClient │
│ prenomClient│
│ adresse │
│ email │
└─────────────┘

À faire :

Identifier toutes les entités du domaine étudié

Chaque entité doit avoir un identifiant unique

Les attributs doivent être atomiques (non décomposables)

Ne pas mettre d’attributs calculés

2.2 Les associations


Une association représente un lien entre deux ou plusieurs entités.

Règles de notation :

Ellipse ou rectangle arrondi avec le verbe d’association

Reliée aux entités par des traits

Peut contenir des attributs propres

2.3 Les cardinalités (Point crucial)


Les cardinalités indiquent le nombre minimum et maximum de fois qu’une occurrence
d’une entité participe à une association.

Format : (min, max)

Cardinalité Signification

(0,1) Zéro ou une fois

(1,1) Exactement une fois

(0,N) Zéro ou plusieurs fois

(1,N) Au moins une fois

Comment lire les cardinalités : Pour lire la cardinalité d’une entité A dans une association
avec B :

“Une occurrence de A participe au minimum X fois et au maximum Y fois à


l’association”

Exemple complet :

CLIENT (1,N) ──── PASSER ──── (0,N) COMMANDE

Un client passe au moins 1 et au plus N commandes

Une commande est passée par 0 à N clients

À faire :

Toujours vérifier les cardinalités dans les deux sens

Justifier chaque cardinalité par une règle de gestion

Les cardinalités (1,1) et (0,1) indiquent souvent une clé étrangère future

2.4 Les types d’associations selon les cardinalités

Type Cardinalités Exemple

One-to-One (1:1) (1,1) — (1,1) Un client a un seul passeport

One-to-Many (1:N) (1,1) — (1,N) Un département a plusieurs employés

Many-to-Many (N:M) (1,N) — (1,N) Des étudiants suivent plusieurs cours

2.5 Les associations ternaires


Une association peut relier 3 entités ou plus. Utilisée quand la relation ne peut pas se
décomposer sans perdre de l’information.

2.6 Les associations réflexives (récursives)


Une entité peut être associée à elle-même.

EMPLOYE(#numEmp, nom) ←──── ENCADRER ────→ (même entité)

Un employé peut encadrer plusieurs employés, un employé est encadré par au plus un
employé.
2.7 Règles de construction du MCD
À faire :

1. Lister toutes les règles de gestion métier avant de commencer

2. Nommer les entités avec des noms communs au singulier

3. Nommer les associations avec des verbes à l’infinitif

4. Vérifier que chaque entité a un identifiant

5. S’assurer que les attributs sont bien placés

À ne pas faire :

Mettre des clés étrangères dans le MCD (c’est le niveau physique)

Créer des attributs composés (décomposer adresse en rue, ville, CP)

Oublier de valider avec les utilisateurs métier

PARTIE 3 — Le Modèle Logique des Données (MLD)


Le MLD est la traduction du MCD en tables relationnelles.

3.1 Règles de passage du MCD au MLD

Règle 1 — Toute entité devient une table

CLIENT(#numClient, nomClient, prenomClient, adresse, email)

Règle 2 — Association 1:N (One-to-Many)

La clé primaire du côté “1” migre vers la table du côté “N” en tant que clé étrangère.

MCD : CLIENT (1,1) ──── PASSER ──── (0,N) COMMANDE

MLD :
CLIENT(#numClient, nom, prenom)
COMMANDE(#numCommande, dateCmd, montant, numClient*)
↑ clé étrangère

Règle 3 — Association N:M (Many-to-Many)


L’association devient une table de liaison avec les clés primaires des deux entités +
attributs propres de l’association.

MCD : ETUDIANT (1,N) ──── INSCRIRE (note) ──── (1,N) COURS

MLD :
ETUDIANT(#numEtudiant, nom, prenom)
COURS(#codeCours, intitule, credits)
INSCRIRE(#numEtudiant*, #codeCours*, note)

Règle 4 — Association 1:1 (One-to-One)

La clé primaire de l’une migre vers l’autre.

PERSONNE(#numPersonne, nom, prenom)


PASSEPORT(#numPasseport, dateExpiration, numPersonne*)

Règle 5 — Association réflexive

Ajouter une clé étrangère qui référence la même table.

EMPLOYE(#numEmp, nom, numEmpSuperieur*)

3.2 Notation du MLD


Clé primaire : # ou soulignée

Clé étrangère : ***** ou en italique

PARTIE 4 — Le Modèle Physique des Données (MPD)


Le MPD est la traduction concrète du MLD dans un SGBD spécifique.

4.1 Ce qui change par rapport au MLD


Typage précis des données (VARCHAR, INT, DATE…)

Contraintes d’intégrité (NOT NULL, UNIQUE, CHECK…)

Index pour optimiser les performances

4.2 Exemple de MPD en SQL


CREATE TABLE CLIENT (
numClient INT PRIMARY KEY AUTO_INCREMENT,
nomClient VARCHAR(50) NOT NULL,
prenomClient VARCHAR(50) NOT NULL,
adresse VARCHAR(200),
email VARCHAR(100) UNIQUE
);

CREATE TABLE COMMANDE (


numCommande INT PRIMARY KEY AUTO_INCREMENT,
dateCmd DATE NOT NULL,
montant DECIMAL(10,2),
numClient INT NOT NULL,
FOREIGN KEY (numClient) REFERENCES CLIENT(numClient)
);

4.3 Les types de données courants

Type SQL Utilisation

INT / BIGINT Nombres entiers

DECIMAL(n,d) Nombres décimaux précis

VARCHAR(n) Chaînes de caractères variables

CHAR(n) Chaînes de longueur fixe

DATE Dates (YYYY-MM-DD)

DATETIME Date + heure

BOOLEAN Vrai/Faux

TEXT Textes longs

PARTIE 5 — Le Modèle Conceptuel des Traitements (MCT)


Le MCT représente ce que fait le système en réponse à des événements, sans se
soucier de qui le fait ni comment.

5.1 Les concepts du MCT


L’événement : un fait qui déclenche un traitement.

Événement entrant : vient de l’extérieur du système

Événement résultant : produit par le traitement

L’opération : un ensemble d’actions déclenchées par un ou plusieurs événements.

La synchronisation : exprime la condition de déclenchement (ET, OU).

La règle d’émission : détermine quel événement résultant est produit.

5.2 Schéma d’une opération MCT

Commande reçue Paiement reçu


│ │
└──────── ET ─────────┘

┌───────────────┐
│ TRAITER LA │
│ COMMANDE │
│ - Vérifier │
│ stock │
│ - Préparer │
│ colis │
└───────────────┘

┌──────────┴──────────┐
[OK] [Rupture]
│ │
Commande validée Commande en attente

5.3 Règles de construction du MCT


À faire :

Identifier tous les événements déclencheurs

Définir clairement les règles d’émission

Couvrir tous les cas (succès et erreurs)

Rester au niveau conceptuel (pas de technique)

PARTIE 6 — Le Modèle Organisationnel des Traitements


(MOT)
Le MOT précise QUI fait QUOI, OÙ et QUAND — il intègre la dimension humaine et
organisationnelle.

6.1 Les postes de travail


On définit les postes de travail (acteurs) qui réalisent les traitements.

6.2 Les types de tâches

Type Description

Manuelle Réalisée entièrement par un humain

Automatique Réalisée entièrement par l’ordinateur

Interactive Dialogue homme-machine

Conversationnelle Dialogue en temps réel

6.3 Représentation du MOT (tableau)

┌───────────────┬──────────────┬──────────────┬────────────────┐
│ Phase │ Client │ Commercial │ Comptable │
├───────────────┼──────────────┼──────────────┼────────────────┤
│ Commande │ Saisit cmd │ Valide cmd │ │
├───────────────┼──────────────┼──────────────┼────────────────┤
│ Livraison │ Reçoit colis │ Édite BL │ Édite facture │
├───────────────┼──────────────┼──────────────┼────────────────┤
│ Paiement │ Règle fact │ │ Enregistre pmt │
└───────────────┴──────────────┴──────────────┴────────────────┘

PARTIE 7 — Le Dictionnaire des Données


Le dictionnaire des données est un inventaire exhaustif de toutes les données du
système.

7.1 Structure du dictionnaire

Colonne Description
Nom Nom de la donnée (mnémonique)

Désignation Description lisible

Type AN (alphanumérique), N (numérique), D (date), B (booléen)

Taille Longueur maximale

Contrainte Valeurs possibles, obligatoire/optionnel

7.2 Exemple de dictionnaire

Nom Désignation Type Taille Contrainte

numClient Numéro client N 10 Obligatoire, unique

nomClient Nom du client AN 50 Obligatoire

email Adresse email AN 100 Unique, format email

montantCmd Montant commande N 10,2 >0

7.3 À faire pour le dictionnaire


Lister TOUTES les données avant de construire le MCD Éliminer les redondances
Normaliser les noms (convention de nommage cohérente) Identifier les données
calculées (ne pas les mettre dans le MCD)

PARTIE 8 — La Normalisation
La normalisation vise à éliminer les redondances et anomalies dans les tables.

8.1 Première Forme Normale (1FN)


Règle : Chaque attribut doit être atomique (indivisible) et il doit exister une clé primaire.

Pas 1FN :

CLIENT(numClient, nom, telephone1; telephone2; telephone3)

1FN :

CLIENT(numClient, nom)
TELEPHONE(numClient*, numero)

8.2 Deuxième Forme Normale (2FN)


Règle : Être en 1FN + tout attribut non-clé doit dépendre de toute la clé primaire.

Pas 2FN :

LIGNE_COMMANDE(#numCmd, #refProduit, qte, libelleProduit)


↑ dépend seulement de refProduit

2FN :

LIGNE_COMMANDE(#numCmd*, #refProduit*, qte)


PRODUIT(#refProduit, libelleProduit)

8.3 Troisième Forme Normale (3FN)


Règle : Être en 2FN + aucune dépendance transitive.

Pas 3FN :

EMPLOYE(#numEmp, nom, codeService, nomService)


↑ nomService dépend de codeService, pas de numEmp

3FN :

EMPLOYE(#numEmp, nom, codeService*)


SERVICE(#codeService, nomService)

PARTIE 9 — Démarche Complète MERISE

Étape 1 : Étude préalable


Analyser l’existant

Identifier les problèmes

Définir les objectifs

Évaluer la faisabilité
Étape 2 : Étude détaillée (niveau conceptuel)
1. Recueil des données → Dictionnaire des données

2. Identification des règles de gestion

3. Conception du MCD

4. Conception du MCT

Étape 3 : Étude technique (niveau logique/organisationnel)


1. Passage MCD → MLD

2. Conception du MOT

3. Vérification de la cohérence

Étape 4 : Réalisation (niveau physique)


1. Passage MLD → MPD (SQL)

2. Développement des traitements

3. Tests et validation

PARTIE 10 — Exemple Complet : Gestion d’une Bibliothèque

Règles de gestion
Un adhérent peut emprunter plusieurs livres

Un livre peut être emprunté par plusieurs adhérents (à des moments différents)

Un livre a un seul auteur principal

Un auteur peut avoir écrit plusieurs livres

Dictionnaire des données

Nom Type Taille

numAdherent N 8

nomAdherent AN 50
isbn AN 13

titreLivre AN 200

numAuteur N 8

nomAuteur AN 50

dateEmprunt D -

dateRetour D -

MCD

┌──────────────┐ ┌─────────────┐
│ ADHERENT │ │ LIVRE │
├──────────────┤ ├─────────────┤
│#numAdherent │ │ #isbn │
│ nomAdherent │ │ titreLivre │
│ prenomAdh. │ │ anneePubli │
│ dateInscript │ └──────┬──────┘
└──────┬───────┘ (1,1)│ECRIRE(0,N)
│ │
EMPRUNTER ┌──────────────┐
(0,N) (0,N) │ AUTEUR │
│ ├──────────────┤
dateEmprunt │ #numAuteur │
dateRetour │ nomAuteur │
└──────────────┘

MLD

ADHERENT(#numAdherent, nomAdherent, prenomAdherent, dateInscription)


AUTEUR(#numAuteur, nomAuteur, prenomAuteur)
LIVRE(#isbn, titreLivre, anneePublication, numAuteur*)
EMPRUNTER(#numAdherent*, #isbn*, #dateEmprunt, dateRetour, dateRetourPrevue)

MPD (SQL)

CREATE TABLE ADHERENT (


numAdherent INT PRIMARY KEY AUTO_INCREMENT,
nomAdherent VARCHAR(50) NOT NULL,
prenomAdherent VARCHAR(50) NOT NULL,
dateInscription DATE NOT NULL DEFAULT CURRENT_DATE
);

CREATE TABLE AUTEUR (


numAuteur INT PRIMARY KEY AUTO_INCREMENT,
nomAuteur VARCHAR(50) NOT NULL,
prenomAuteur VARCHAR(50)
);

CREATE TABLE LIVRE (


isbn CHAR(13) PRIMARY KEY,
titreLivre VARCHAR(200) NOT NULL,
anneePublication YEAR,
numAuteur INT NOT NULL,
FOREIGN KEY (numAuteur) REFERENCES AUTEUR(numAuteur)
);

CREATE TABLE EMPRUNTER (


numAdherent INT NOT NULL,
isbn CHAR(13) NOT NULL,
dateEmprunt DATE NOT NULL,
dateRetour DATE,
dateRetourPrevue DATE NOT NULL,
PRIMARY KEY (numAdherent, isbn, dateEmprunt),
FOREIGN KEY (numAdherent) REFERENCES ADHERENT(numAdherent),
FOREIGN KEY (isbn) REFERENCES LIVRE(isbn)
);

PARTIE 11 — Erreurs Fréquentes à Éviter

Erreurs dans le MCD

Erreur Correction

Oublier l’identifiant d’une entité Toujours définir une clé unique

Mettre des clés étrangères dans le MCD Les FK apparaissent seulement au MLD

Attribut non atomique Décomposer (ex: adresse → rue, CP, ville)

Cardinalités inversées Relire dans les deux sens

Erreurs dans le passage MCD → MLD


Erreur Correction

Oublier une table de liaison pour N:M Toujours créer une table intermédiaire

Mauvais sens de migration de la FK La FK va vers le côté N

Oublier les attributs de l’association Les inclure dans la table de liaison

Récapitulatif des Modèles MERISE

Modèle Niveau Objet Rôle

MCD Conceptuel Données Structure des données métier

MCT Conceptuel Traitements Opérations métier

MLD Logique Données Tables relationnelles

MOT Organisationnel Traitements Qui fait quoi, quand

MPD Physique Données SQL concret

MPT Physique Traitements Code applicatif

Ce cours couvre l’essentiel de la méthode MERISE telle qu’enseignée en BTS, DUT et


Licence professionnelle en France.

Vous aimerez peut-être aussi