Merise : MCD avancé

Association ternaire

Une association peut relier plus de deux entités. Exemple : un enseignant donne un cours à une classe.

        ┌──────────────┐
        │  ENSEIGNANT  │
        └──────┬───────┘
          (0,N)│
               │
┌─────────┐ (0,N)   (0,N) ┌─────────────┐
│  COURS  │──── DONNER ───│   CLASSE    │
└─────────┘               └─────────────┘
              (propriété : volume_horaire)

La ternaire se justifie si l’information ne peut pas être décomposée en associations binaires sans perdre du sens (le triplet compte : tel enseignant, tel cours, telle classe). Une ternaire est rare ; avant de la garder, vérifier qu’elle n’est pas décomposable.

Association réflexive

Une entité reliée à elle-même.

              ┌────────────┐
   (0,N)      │  EMPLOYE   │      (0,1)
  ┌───────────│ #matricule │───────────┐
  │  DIRIGER  │ nom        │  DIRIGER  │
  └───────────┴────────────┴───────────┘
   rôle : manager       rôle : subordonné

Chaque extrémité porte un rôle (manager, subordonné). Un employé dirige 0 à N employés ; un employé est dirigé par 0 ou 1 employé (le dirigeant principal n’a pas de manager).

Autres exemples : arbre de catégories (parent, enfant), nomenclature de composants, parrainage.

Identifiant relatif (entité faible)

Une entité peut n’être identifiable que par rapport à une autre. Exemple : les lignes d’une commande sont numérotées dans la commande (ligne 1, 2, 3…).

┌────────────────┐ (1,N)        (1,1) ┌────────────────────┐
│    COMMANDE    │──── CONTENIR ──────│   LIGNE_COMMANDE   │
│ #num_commande  │      [R]           │ #(relatif) num_ligne│
└────────────────┘                    │ quantite            │
                                      └────────────────────┘

Le numéro de ligne seul n’identifie pas une ligne : c’est le couple (num_commande, num_ligne). La notation (identifiant relatif, cardinalité (1,1) marquée) indique la dépendance. Cette situation se traduit en MLD par une clé primaire composée (voir Du MCD au modèle logique).

Dépendances fonctionnelles

Une dépendance fonctionnelle A → B signifie : la valeur de A détermine une seule valeur de B.

Dépendance	Sens
`num_client → nom, email`	Un numéro de client détermine nom et e-mail
`reference → libelle, prix`	Une référence détermine libellé et prix
`(num_commande, reference) → quantite`	Une commande et un article déterminent la quantité
`code_postal → ville`	(dans un pays donné, et avec des exceptions : à manier avec prudence)

Les dépendances fonctionnelles servent à justifier les identifiants et à détecter les redondances (voir Normalisation). Un bon MCD en découle naturellement : chaque propriété dépend de l’identifiant de son entité, de l’identifiant entier, et de rien d’autre.

Contrainte d’intégrité fonctionnelle (CIF)

La CIF (association « un à plusieurs » avec (1,1)) exprime qu’une occurrence est déterminée par une autre : COMMANDE → CLIENT (chaque commande détermine son client). La cardinalité (1,1) côté COMMANDE est la CIF. Elle se traduira par une clé étrangère.

Une CIF peut aussi exister entre deux entités de plusieurs associations (contraintes d’inclusion, d’égalité, d’exclusion) ; ces contraintes sont notées à côté du MCD (par exemple [X] pour l’exclusion) ou dans un texte annexe, puis traduites par des contraintes SQL ou du code applicatif.

Généralisation et spécialisation (héritage)

Une entité générale et des entités spécialisées qui ont des propriétés supplémentaires.

                ┌────────────────┐
                │   PERSONNE     │
                │ #num_personne  │
                │ nom            │
                │ email          │
                └───────┬────────┘
                        │  XT : partition
          ┌─────────────┴─────────────┐
┌─────────┴───────┐          ┌────────┴────────┐
│     CLIENT      │          │    EMPLOYE      │
│ adresse_facture │          │ poste           │
│ points_fidelite │          │ date_embauche   │
└─────────────────┘          └─────────────────┘

Contrainte	Sens
X (exclusion)	Une occurrence de PERSONNE est d’au plus un sous-type (pas client et employé)
T (totalité)	Toute occurrence de PERSONNE appartient à au moins un sous-type
XT (partition)	Exclusion et totalité : exactement un sous-type
Aucune	Une occurrence peut n’appartenir à aucun sous-type, ou à plusieurs

Les notations varient selon les ouvrages : indiquer clairement la signification des symboles utilisés sur le schéma.

La traduction en tables propose trois stratégies (voir Du MCD au modèle logique).

Historisation

Garder l’historique d’une information qui change dans le temps (prix d’un article, adresse d’un client).

┌──────────────┐ (0,N)               (1,1) ┌────────────────────┐
│   ARTICLE    │──── AVOIR_PRIX ───────────│   PRIX_ARTICLE     │
│ #reference   │                           │ #(relatif) date_debut │
│ libelle      │                           │ montant            │
└──────────────┘                           └────────────────────┘

Au lieu d’une propriété prix qui est écrasée, une entité PRIX_ARTICLE garde chaque prix avec sa date de début (la date de fin se déduit du prix suivant). Une commande peut ainsi retrouver le prix applicable à sa date, ou recopier le prix payé dans la ligne de commande (prix_unitaire).

Autres techniques : tables d’historique alimentées par déclencheur, colonnes valide_de et valide_a, suppression logique (colonne supprime_le) plutôt que DELETE.

Données temporelles et suppression logique

Besoin	Technique
Savoir quand une donnée a été créée ou modifiée	Propriétés `cree_le`, `modifie_le` (dans le MPD, souvent ajoutées sans figurer au MCD)
Conserver une donnée supprimée	`supprime_le` (nullable) : une ligne « supprimée » reste en base
Historique complet des valeurs	Entité d’historique avec date de début
Audit des actions	Table de journal (qui, quoi, quand)

La suppression logique complique les requêtes (WHERE supprime_le IS NULL) et les contraintes d’unicité : à choisir selon un vrai besoin.

Types énumérés et tables de référence

Un statut de commande (nouvelle, payee, expediee) peut être :

Représentation	Avantages	Inconvénients
Propriété texte avec contrainte (`CHECK`)	Simple	Ajouter un statut modifie la contrainte
`ENUM` du SGBD	Compact	Dépendant du SGBD, modification lourde
Entité STATUT (table de référence)	Évolutif, libellés, ordre	Une jointure de plus

Une table de référence (STATUT, PAYS, TYPE_ARTICLE) est une entité avec identifiant et libellé : la meilleure option quand la liste évolue ou porte d’autres propriétés (libellé affiché, ordre, actif).

Quand une propriété devient une entité

Signal	Action
La propriété a ses propres propriétés (adresse : rue, ville, code postal)	Entité
Elle est partagée entre plusieurs occurrences	Entité
Elle est multi-valuée (plusieurs numéros de téléphone)	Entité
Elle a une liste de valeurs qui évolue	Entité de référence
Elle ne sert qu’à décrire une seule entité, sans structure	Propriété

Dépannage

Symptôme	Piste
Une association ternaire hésitante	Tenter de la décomposer en binaires ; si l’information est perdue, la garder
Association réflexive sans rôles	Ajouter les rôles aux extrémités pour la rendre lisible
Identifiant composé difficile à manipuler	Introduire un identifiant technique (clé de substitution) au niveau physique
Hésitation sur l’héritage	Étudier les trois traductions (voir Du MCD au modèle logique) ; éviter l’héritage si les sous-types diffèrent peu
Historique qui explose	Limiter les propriétés historisées à celles qui ont une valeur métier
Statut stocké en texte libre	Table de référence ou contrainte `CHECK`

Ubuntu 24.04 et 26.04 : différences à connaître

Aucune.