Documentation technique

B02 - Modélisation Merise et UML

4 min de lecture

B02 - Modéliser une base : Merise (MCD/MLD) et UML

Objectif

Passer d’un énoncé (règles de gestion) à un schéma conceptuel (MCD Merise ou diagramme de classes UML), puis au modèle logique (tables, clés) prêt à coder en SQL. Exercices de référence : Révision Merise - UML (Art-2-Rue), Exo Zoo, Exercice Héritage - Produits et Véhicules.

1. La démarche

flowchart LR
  E["📄 Énoncé<br/>règles de gestion"] --> D["Dictionnaire<br/>des données"]
  D --> MCD["MCD (Merise)<br/>ou diagramme de<br/>classes (UML)"]
  MCD --> MLD["MLD<br/>tables, PK, FK"]
  MLD --> MPD["MPD / script SQL<br/>CREATE TABLE…"]
NiveauQuestionLivrable
Conceptuel (MCD)Quoi ? Quelles données, quels liens, indépendamment du SGBDEntités, associations, cardinalités
Logique (MLD)Comment en tables relationnelles ?Tables, clés primaires/étrangères
Physique (MPD)Pour ce SGBD précisTypes SQL, index, script CREATE TABLE

2. Lire un énoncé : repérer les éléments

Dans le texteDevient
Un nom important qui a des caractéristiques (« un artiste a un pseudonyme… »)Entité / classe
Une caractéristique (« son pseudonyme », « sa date »)Attribut
« unique », « identifié par »Identifiant (clé)
Un verbe qui relie deux noms (« réalise », « se trouve dans »)Association
« un seul », « au moins un », « plusieurs », « facultatif »Cardinalités
« obligatoire », « ne doit pas être supérieure à »Contraintes NOT NULL / CHECK

3. Les cardinalités

Merise (min,max)UML (multiplicité)Lecture
0,10..1Zéro ou un (facultatif)
1,11Exactement un (obligatoire)
0,n0..* ou *Zéro ou plusieurs
1,n1..*Au moins un

Merise et UML placent les cardinalités du côté opposé !

  • Merise : la cardinalité est notée à côté de l’entité dont on parle (« un artiste réalise 0,n œuvres » → 0,n près d’Artiste).
  • UML : la multiplicité est notée à l’autre bout (« un artiste réalise 0..* œuvres » → 0..* près d’Œuvre).

4. Exemple complet : Art-2-Rue

Diagramme de classes UML

classDiagram
    direction LR
    class Artiste {
        +String pseudonyme_unique
        +String nomReel
        +String bio
        +String nationalite
    }
    class Oeuvre {
        +String titre
        +Date dateCreation
        +String description
        +bool estDetruite
    }
    class Lieu {
        +String nom
        +String adresse
        +String quartier
        +Decimal latitude
        +Decimal longitude
    }
    class Technique {
        +String nom
    }
    class Benevole {
        +String nom
        +String prenom
        +String email
    }
    class Photo {
        +DateTime datePriseVue
        +String nomFichier
        +String etatOeuvre
    }

    Artiste "0..*" -- "0..*" Oeuvre : réalise
    Oeuvre "*" --> "1" Lieu : se situe dans
    Oeuvre "*" -- "1..*" Technique : utilise
    Photo "*" --> "1" Oeuvre : concerne
    Photo "*" --> "1" Benevole : est prise par
    Oeuvre "0..1" --> "0..1" Oeuvre : recouvre

Modèle relationnel (ERD Mermaid)

erDiagram
    LIEUX ||--o{ OEUVRES : "abrite"
    OEUVRES ||--o{ OEUVRE_ARTISTE : "réalisée par"
    ARTISTES ||--o{ OEUVRE_ARTISTE : "réalise"
    OEUVRES ||--o{ OEUVRE_TECHNIQUE : "utilise"
    TECHNIQUES ||--o{ OEUVRE_TECHNIQUE : "employée dans"
    OEUVRES ||--o{ PHOTOS : "documentée par"
    BENEVOLES ||--o{ PHOTOS : "prend"
    OEUVRES |o--o| OEUVRES : "recouvre"

MLD textuel (souligné = PK, # = FK)

  • ARTISTE (id_artiste, pseudonyme UNIQUE, nom_reel, bio, nationalite)
  • LIEU (id_lieu, nom, adresse, quartier, latitude, longitude)
  • OEUVRE (id_oeuvre, titre, date_creation, description, est_detruite, id_lieu NOT NULL, id_oeuvre_recouverte)
  • TECHNIQUE (id_technique, nom UNIQUE)
  • OEUVRE_ARTISTE (id_oeuvre, id_artiste)
  • OEUVRE_TECHNIQUE (id_oeuvre, id_technique)
  • BENEVOLE (id_benevole, nom, prenom, email UNIQUE)
  • PHOTO (id_cliche, date_prise_vue, nom_fichier, etat_oeuvre, id_oeuvre, id_benevole)

Script SQL complet de création + les 4 requêtes corrigées : scripts/bdd/art2rue_creation_et_requetes.sql (voir B05 - SQL - interroger et modifier les données).

5. Règles de passage MCD → MLD

flowchart TD
  A{"Type d'association ?"} -->|"1 — n<br/>(un lieu ⟷ plusieurs œuvres)"| B["La clé du côté « 1 » migre<br/>comme FK du côté « n »<br/>→ Oeuvres.id_lieu"]
  A -->|"n — n<br/>(œuvres ⟷ artistes)"| C["Nouvelle TABLE d'association<br/>PK composée des 2 FK<br/>(+ attributs de l'association)"]
  A -->|"1 — 1 / 0,1 — 0,1"| D["FK d'un côté au choix<br/>avec contrainte UNIQUE<br/>→ id_oeuvre_recouverte UNIQUE"]
  A -->|"Association réflexive"| E["FK qui pointe vers<br/>sa propre table"]
  A -->|"Héritage"| F["TPH / TPT / TPC<br/>→ fiche B03"]
Cardinalité côté « plusieurs »Contrainte sur la FK
1,1 (obligatoire)FK NOT NULL
0,1 (facultatif)FK NULL autorisée

Une association porteuse d’attributs (ex. est_principal dans « soigne » de l’exercice Zoo, quantite dans la composition d’un kit) devient toujours une table, même si elle est 1-n en apparence.

6. Notation « patte d’oie » de Mermaid (rappel du cours)

SymboleCardinalité
||exactement 1
|o / o|0 ou 1
}| / |{1 ou plusieurs
}o / o{0 ou plusieurs

Lien : ENTITE_A ||--o{ ENTITE_B : "libellé" = un A pour 0..n B. Trait -- = relation identifiante, .. = non identifiante.

7. Outils de modélisation

OutilType
Mermaid dans ObsidianTexte → diagramme (ce que tu utilises)
LoopingGratuit, spécial Merise (MCD → MLD → SQL), Windows
draw.io / diagrams.netDiagrammes génériques (appli Linux disponible)
dbdiagram.ioERD en texte, export SQL
SSMS → Diagrammes de base de donnéesÀ partir d’une base existante

Voir aussi

Vue Graphique

Liens retour