# 02 – Les notions du MCD > [!info] Temps estimé : 1 h 45 > **Ce que vous saurez faire à la fin :** passer d'un texte métier à une liste de données, puis reconnaître et dessiner les éléments d'un MCD : propriétés, entités, identifiants, associations, cardinalités, identifiant relatif et gestion du temps. **Sommaire** 1. Du texte métier au dictionnaire de données 2. Propriété et occurrence 3. Entité et identifiant 4. Association 5. Cardinalités 6. Identifiant relatif 7. Modéliser le temps et l'historique --- ## 1. Du texte métier au dictionnaire de données Un MCD ne s'invente pas : il se **déduit** de ce que disent les personnes qui connaissent l'activité (les « métiers »). La première étape consiste donc à **recueillir l'information**. ### 1.1 Les règles de gestion > [!note] Définition – Règle de gestion > Une **règle de gestion** est une phrase courte, sans ambiguïté, qui décrit une donnée ou une contrainte de l'activité étudiée. On les numérote pour pouvoir y faire référence. > [!example] 🪨 Géosciences – Du texte aux règles de gestion > *Texte du bureau d'études :* « Nous intervenons sur des sites, chacun repéré par un nom et une commune. Sur chaque site, nous réalisons un ou plusieurs forages, datés, dont nous notons la profondeur maximale. Dans chaque forage, nous prélevons des échantillons, à une profondeur donnée, et nous décrivons leur lithologie. » > > | N° | Règle de gestion | > |---|---| > | RG1 | Un site est décrit par un nom et une commune. | > | RG2 | Un site comporte au moins un forage, souvent plusieurs. | > | RG3 | Un forage est réalisé sur un seul site. | > | RG4 | Un forage est décrit par sa date et sa profondeur maximale (en m). | > | RG5 | Un échantillon est prélevé dans un seul forage, à une profondeur donnée (en m) ; on note sa lithologie. | > | RG6 | Un forage peut ne contenir aucun échantillon, ou en contenir plusieurs. | Les règles de gestion servent à **tout justifier** dans le MCD : chaque donnée, chaque lien et chaque cardinalité doit pouvoir être rattaché à une règle. ### 1.2 Le dictionnaire de données > [!note] Définition – Dictionnaire de données > Le **dictionnaire de données** est la liste de **toutes les données élémentaires** nécessaires, avec pour chacune son nom, sa signification, son type et son unité. > [!example] 🪨 Géosciences – Extrait du dictionnaire de données > | Nom | Signification | Type | Unité / format | > |---|---|---|---| > | `nomSite` | Nom usuel du site | Texte | — | > | `commune` | Commune du site | Texte | — | > | `dateForage` | Date de réalisation du forage | Date | JJ/MM/AAAA | > | `profondeurMaxM` | Profondeur maximale atteinte par le forage | Nombre décimal | m | > | `profondeurPrelevementM` | Profondeur à laquelle l'échantillon est prélevé | Nombre décimal | m | > | `lithologie` | Nature de la roche observée | Texte | — | Convention de nommage utilisée dans ces ressources : **camelCase sans accent** (première lettre en minuscule, une majuscule à chaque nouveau mot), avec l'unité dans le nom quand c'est utile (`surfaceHa`, `quantiteG`). ### 1.3 Épurer le dictionnaire Le premier dictionnaire obtenu (le **dictionnaire brut**) contient presque toujours des défauts. On l'**épure** en traitant trois cas. | Cas | Ce que c'est | Exemple | Que faire ? | |---|---|---|---| | **Synonymes** | Deux noms pour **la même** information | « n° de parcelle » et « référence parcelle » | Garder **un seul** nom | | **Polysèmes** | Un seul nom pour **deux** informations différentes | « profondeur » : profondeur maximale du forage **ou** profondeur de prélèvement de l'échantillon ? | Créer **deux** propriétés avec des noms précis | | **Propriétés calculées** | Information qui se **calcule** à partir d'autres | Énergie d'une portion = somme des (quantité × énergie pour 100 g) des ingrédients ; âge d'un animal (calculé à partir de sa date de naissance) | **Ne pas la conserver** : on la recalcule quand on en a besoin | Le résultat est le **dictionnaire épuré** : c'est lui qui sert à construire le MCD. > [!warning] Pourquoi supprimer les propriétés calculées ? > Si l'on stocke l'énergie d'une recette **et** les quantités de ses ingrédients, il suffit de modifier une quantité sans recalculer l'énergie pour que les deux informations se contredisent. --- ## 2. Propriété et occurrence > [!note] Définition – Propriété > Une **propriété** (on dit aussi **attribut**) est une **information élémentaire** utile à l'activité : on ne peut pas la découper davantage sans perdre son sens. > [!note] Définition – Occurrence d'une propriété > Une **occurrence** d'une propriété est **une valeur concrète** de cette propriété. > [!example] 🪨 Géosciences – Propriétés et occurrences > | Propriété | Occurrences possibles | > |---|---| > | `lithologie` | « calcaire », « argile », « grès »… | > | `profondeurPrelevementM` | 2,5 · 7,0 · 12,8… | Trois règles pour une bonne propriété : 1. **Elle est élémentaire** : une seule valeur à la fois (pas de liste « calcaire, argile »). 2. **Son nom est précis et unique dans tout le MCD** : deux propriétés différentes ne portent jamais le même nom (`nomSite` et `nomLabo`, pas deux fois `nom`). 3. **Elle n'est pas calculée** (voir 1.3). --- ## 3. Entité et identifiant ### 3.1 L'entité > [!note] Définition – Entité > Une **entité** regroupe des « objets » **de même nature**, décrits par **les mêmes propriétés**. Ces objets peuvent être concrets (une parcelle, un animal, un échantillon) ou abstraits (une campagne agricole, une recette, une analyse). > [!note] Définition – Occurrence d'une entité > Une **occurrence** d'une entité est **un objet particulier** de cette entité : la parcelle « Les Longues Raies », la recette « Taboulé », le forage F12. > [!example] 🌾 Agrosciences – L'entité PARCELLE et trois de ses occurrences > | <u>idParcelle</u> | nomParcelle | surfaceHa | typeSol | commune | > |---|---|---|---|---| > | 1 | Les Longues Raies | 12,4 | limoneux | Beauvais | > | 2 | Le Grand Champ | 8,0 | argileux | Tillé | > | 3 | La Fosse | 3,2 | crayeux | Beauvais | > > Chaque **ligne** est une occurrence de l'entité PARCELLE. Chaque **colonne** est une propriété. Règles d'écriture : le nom d'une entité est un **nom commun au singulier**, écrit en **MAJUSCULES** (PARCELLE, pas « Parcelles »). ### 3.2 L'identifiant Pour enregistrer un traitement sur « Les Longues Raies », il faut pouvoir **désigner cette parcelle sans ambiguïté** parmi toutes les autres. C'est le rôle de l'identifiant. > [!note] Définition – Identifiant > L'**identifiant** d'une entité est une propriété (ou un groupe de propriétés) dont la valeur est **différente pour chaque occurrence**. Connaître sa valeur permet de retrouver **une seule** occurrence. Comment le choisir ? - **Identifiant naturel** : une donnée de l'activité, déjà unique. Exemples : le numéro national d'un animal (`numNational`), l'année d'une campagne (`anneeCampagne`). - **Identifiant artificiel** : un numéro créé pour l'occasion (`idParcelle`, `idRecette`). On l'utilise **dès qu'aucune donnée naturelle n'est garantie unique et stable**. Deux parcelles peuvent porter le même nom ; deux exploitants aussi. > [!tip] Le test « si je connais… » > Toutes les propriétés d'une entité doivent passer ce test : **« Si je connais l'identifiant, je connais une seule valeur de cette propriété. »** > Si je connais `idParcelle = 1`, je connais **une seule** surface (12,4 ha) → `surfaceHa` est bien une propriété de PARCELLE. > Si je connais `idParcelle = 1`, je connais **plusieurs** produits épandus → le produit n'est **pas** une propriété de PARCELLE. ### 3.3 La représentation d'une entité ![[Code et Développement/Développement d'Applications/Modèle conceptuel de Données/ressources/mcd_entite_parcelle.svg|Entité PARCELLE : rectangle avec le nom en en-tête, l'identifiant idParcelle souligné en premier, puis nomParcelle, surfaceHa, typeSol, commune]] *Un rectangle : le nom de l'entité en en-tête, puis l'identifiant **souligné et en premier**, puis les autres propriétés.* > [!abstract]- Pour aller plus loin > Le test « si je connais… » porte un nom : la **dépendance fonctionnelle**. On dit que la propriété B **dépend fonctionnellement** de A (on note A → B) si, à une valeur de A, correspond **une seule** valeur de B. Exemple : `idParcelle → surfaceHa`. Toutes les propriétés d'une entité dépendent fonctionnellement de son identifiant. --- ## 4. Association ### 4.1 Définition et représentation Une recette **contient** des ingrédients. Ce lien n'est ni une recette ni un ingrédient : c'est une **association**. > [!note] Définition – Association > Une **association** représente un **lien** entre des entités. Son nom est un **verbe à l'infinitif** (Contenir, Exploiter, Provenir). > Une **occurrence** d'association relie **une occurrence de chacune** des entités concernées : « la recette *Taboulé* contient l'ingrédient *semoule* ». ![[Code et Développement/Développement d'Applications/Modèle conceptuel de Données/ressources/mcd_association_contenir.svg|RECETTE reliée à INGREDIENT par l'association Contenir qui porte la propriété quantiteG ; cardinalités 1,n côté RECETTE et 0,n côté INGREDIENT]] *L'association est une ellipse reliée par des traits (les « pattes ») aux entités. Les chiffres sur les pattes sont les cardinalités (voir section 5).* ### 4.2 Une association peut porter des propriétés La **quantité** de semoule dans le taboulé : où la ranger ? - Dans RECETTE ? Non : une recette contient plusieurs ingrédients, donc plusieurs quantités. - Dans INGREDIENT ? Non : la semoule entre dans plusieurs recettes, avec des quantités différentes. - Il faut connaître **la recette ET l'ingrédient** pour connaître la quantité : `quantiteG` est une propriété **de l'association** Contenir. > [!tip] Règle de placement > Une propriété va dans l'association quand il faut connaître **toutes** les entités reliées pour connaître sa valeur. Si une seule entité suffit, la propriété va dans cette entité. Une occurrence d'association est identifiée par **la combinaison des identifiants** des entités qu'elle relie : (idRecette, idIngredient). Conséquence : pour une même recette et un même ingrédient, il ne peut y avoir **qu'une** quantité. ### 4.3 La dimension d'une association La **dimension** d'une association est le **nombre d'entités** qu'elle relie. #### Association binaire (2 entités) C'est le cas le plus fréquent (exemple Contenir ci-dessus). #### Association réflexive (une entité reliée à elle-même) Un ingrédient peut **en remplacer un autre** (la margarine remplace le beurre dans une recette sans lactose). L'association relie INGREDIENT… à INGREDIENT. Chaque patte reçoit un **rôle** pour savoir qui remplace qui. ![[Code et Développement/Développement d'Applications/Modèle conceptuel de Données/ressources/mcd_reflexive_remplacer.svg|Association réflexive Remplacer entre INGREDIENT et INGREDIENT, avec les rôles remplacé et substitut, cardinalités 0,n sur chaque patte, propriété conditionUsage]] #### Association ternaire (3 entités) > [!example] 🌾 Agrosciences – Le rendement > Le rendement (en t/ha) dépend de **la parcelle**, de **la culture** et de **la campagne** : le blé sur « Les Longues Raies » n'a pas le même rendement en 2025 et en 2026, et l'orge sur la même parcelle en 2026 non plus. Pour connaître `rendementTHa`, il faut connaître les **trois**. ![[Code et Développement/Développement d'Applications/Modèle conceptuel de Données/ressources/mcd_ternaire_cultiver.svg|Association ternaire Cultiver reliant PARCELLE (0,n), CULTURE (0,n) et CAMPAGNE (1,n), portant la propriété rendementTHa]] Une occurrence de Cultiver : *(parcelle 1, blé tendre, 2026) → 7,8 t/ha*. > [!warning] Une ternaire se justifie > Une association ternaire n'est correcte que si **chaque occurrence a besoin des trois entités**. Si l'une d'elles suffit à connaître une autre, il faut découper (voir [[Code et Développement/Développement d'Applications/Modèle conceptuel de Données/03_demarche_et_pieges#Piège 8 – La ternaire qui cache une dépendance|Piège 8]]). Les associations à quatre entités ou plus existent mais sont rares : elles peuvent presque toujours être découpées. --- ## 5. Cardinalités ### 5.1 Définition > [!note] Définition – Cardinalité > La **cardinalité** d'une patte est un couple **min,max** écrit **du côté de l'entité**. Elle indique combien de fois, **au minimum** et **au maximum**, **une occurrence** de l'entité participe à l'association. | Valeur | Signification | |---|---| | **min = 0** | Participation **facultative** : une occurrence peut n'avoir aucun lien | | **min = 1** | Participation **obligatoire** : chaque occurrence a au moins un lien | | **max = 1** | **Au plus un** lien | | **max = n** | **Plusieurs** liens possibles | D'où les quatre cardinalités utilisées : | Cardinalité | Se lit | Exemple | |---|---|---| | **0,1** | aucun ou un seul | Un animal a **au plus une** mère enregistrée (elle peut être inconnue) | | **1,1** | exactement un | Un forage est réalisé sur **un et un seul** site | | **0,n** | aucun, un ou plusieurs | Un ingrédient peut n'être utilisé dans **aucune** recette, ou dans plusieurs | | **1,n** | au moins un | Un site comporte **au moins un** forage | ### 5.2 Lire et écrire une cardinalité ![[Code et Développement/Développement d'Applications/Modèle conceptuel de Données/ressources/mcd_cardinalites_site_forage.svg|SITE relié à FORAGE par l'association Comporter, cardinalité 1,n côté SITE et 1,1 côté FORAGE]] On lit **chaque patte séparément**, en partant de l'entité, avec la phrase type : > « **Un(e)** [entité] [verbe] **au minimum** [min] et **au maximum** [max] [autre entité]. » - Côté SITE (**1,n**) : *un site comporte au minimum un et au maximum plusieurs forages* (RG2). - Côté FORAGE (**1,1**) : *un forage est réalisé sur au minimum un et au maximum un site*, autrement dit sur un seul (RG3). Pour **écrire** une cardinalité, posez deux questions pour chaque patte, à propos d'**une** occurrence de l'entité : 1. **Peut-elle exister sans ce lien ?** Oui → min = 0 ; non → min = 1. 2. **Peut-elle avoir ce lien plusieurs fois ?** Non → max = 1 ; oui → max = n. Les réponses viennent **des règles de gestion**, pas de l'intuition. Si aucune règle ne permet de répondre, c'est une question à poser au métier. > [!warning] Attention aux autres notations > D'autres méthodes (UML, notation « pattes de corbeau » utilisée par certains logiciels) écrivent les cardinalités **du côté opposé** ou avec des symboles. En MERISE, la cardinalité est toujours **côté entité** et se lit **à partir de cette entité**. ### 5.3 Patte en 1,1 ou 0,1 : où vont les propriétés ? Quand une patte vaut **1,1** ou **0,1** (une occurrence de l'entité participe **au plus une fois**), connaître cette occurrence suffit pour connaître le lien. Une propriété placée sur l'association dépend donc **de cette seule entité** : elle doit aller **dans l'entité**. ![[Code et Développement/Développement d'Applications/Modèle conceptuel de Données/ressources/mcd_patte_x1_proprietes.svg|À éviter : la propriété dateDebutExploitation sur l'association Exploiter dont la patte PARCELLE vaut 1,1. Correct : dateDebutExploitation est placée dans PARCELLE]] *Une parcelle n'a qu'un exploitant : la date de début d'exploitation est une information **de la parcelle**.* > [!tip] Règle > Une association dont une patte vaut **x,1** (0,1 ou 1,1) **ne porte pas de propriété**. Et seule une association **binaire** peut avoir une patte x,1. > [!abstract]- Pour aller plus loin > Une association binaire ayant une patte en 1,1 est appelée **association hiérarchique** (on parle aussi de lien « père-fils »). Avec 1,1 on parle d'association hiérarchique **forte**, avec 0,1 d'association hiérarchique **faible**. Elle traduit une **dépendance fonctionnelle entre identifiants** : `idForage → idSite` (si je connais le forage, je connais son site). --- ## 6. Identifiant relatif ### 6.1 La situation Dans le forage F12, le géologue numérote ses échantillons 1, 2, 3… Dans le forage F13, il recommence à 1, 2, 3… L'« échantillon n° 3 » ne veut donc rien dire seul : c'est l'**échantillon n° 3 du forage F12**. D'autres exemples du même type : - 🥗 l'**étape n° 2** de la recette « Taboulé » ; - 🌾 la **ligne n° 4** d'un bon de livraison de la coopérative ; - 🪨 la **passe n° 1** (tronçon de carottage) d'un forage. Dans tous ces cas, l'objet **n'existe pas sans son « parent »** et il est numéroté **à l'intérieur** de ce parent. ### 6.2 Définition et notation > [!note] Définition – Identifiant relatif > Une entité a un **identifiant relatif** quand ses occurrences sont identifiées par **leur numéro propre + l'identifiant de l'entité dont elles dépendent**. > Identifiant complet de l'échantillon : **(idForage, numEchantillon)**. ![[Code et Développement/Développement d'Applications/Modèle conceptuel de Données/ressources/mcd_identifiant_relatif.svg|FORAGE relié à ECHANTILLON par l'association Provenir ; patte FORAGE 0,n ; patte ECHANTILLON 1,1 (R) ; numEchantillon souligné ; identifiant complet idForage + numEchantillon]] Notation retenue dans ces ressources : - la patte côté entité dépendante porte **1,1 (R)** (R pour « relatif ») ; - dans l'entité dépendante, on souligne **seulement le numéro propre** (`numEchantillon`) ; l'identifiant du parent (`idForage`) n'est **pas recopié** dans l'entité : il est apporté par le lien. Lecture : *un échantillon provient d'un et un seul forage, et il est identifié relativement à ce forage* ; *un forage contient zéro, un ou plusieurs échantillons* (RG5, RG6). ### 6.3 Quand l'utiliser ? Utilisez un identifiant relatif quand **les trois conditions** sont réunies : 1. La patte côté entité dépendante vaut **1,1** : chaque occurrence a **toujours un seul** parent. 2. L'entité **n'a pas d'existence propre** : si l'on supprime le forage, ses échantillons n'ont plus de sens. 3. La numérotation est **locale** au parent (le n° 1 existe dans chaque forage). Sinon, préférez un **identifiant propre** à l'entité : une parcelle peut changer d'exploitant, elle a donc sa propre existence et son propre identifiant `idParcelle`. > [!abstract]- Pour aller plus loin > - Une entité à identifiant relatif est parfois appelée **entité faible** (ou dépendante). La notion a été formalisée dans **MERISE 2**. > - Selon les ouvrages et les logiciels, la notation varie : **(1,1)** entre parenthèses, **1,1 (R)**, ou un soulignement en pointillés de l'identifiant partiel. Le sens est toujours le même. --- ## 7. Modéliser le temps et l'historique ### 7.1 Une date est-elle une propriété ou une entité ? Cela dépend de **ce qu'elle décrit**. - Une date qui décrit **un seul objet**, une seule fois, est une **propriété de l'entité** : `dateForage` (un forage est réalisé une fois), `dateNaissance` d'un animal. - Une date qui décrit **une action qui peut se répéter** entre les mêmes objets demande plus de réflexion. ### 7.2 Le problème de l'historique > [!example] 🌾 Agrosciences – Les traitements d'une parcelle > On veut conserver **tous** les traitements : la parcelle 1 reçoit le produit Fongix le 12/04/2026, puis **de nouveau** le 20/05/2026. Première idée : mettre la date sur l'association. ![[Code et Développement/Développement d'Applications/Modèle conceptuel de Données/ressources/mcd_historique_probleme.svg|PARCELLE reliée à PRODUIT par l'association Traiter portant dateTraitement et doseLHa ; cardinalités 0,n de chaque côté]] Mais une occurrence de Traiter est identifiée par **(idParcelle, idProduit)** (voir 4.2) : | idParcelle | idProduit | dateTraitement | doseLHa | |---|---|---|---| | 1 | Fongix | 12/04/2026 | 1,0 | | 1 | Fongix | 20/05/2026 | 0,8 | Les deux lignes ont **le même identifiant (1, Fongix)**. Elles ne peuvent pas coexister : enregistrer le second traitement **écrase** le premier. **L'historique est perdu.** ### 7.3 La solution : une entité DATE On fait entrer la date **dans l'identification** du traitement en la transformant en entité. L'association devient **ternaire**. ![[Code et Développement/Développement d'Applications/Modèle conceptuel de Données/ressources/mcd_historique_date.svg|Association ternaire Traiter reliant PARCELLE (0,n), PRODUIT (0,n) et DATE (1,n), portant la propriété doseLHa ; DATE a pour identifiant dateJour]] L'identifiant d'un traitement devient **(idParcelle, idProduit, dateJour)** : (1, Fongix, 12/04/2026) et (1, Fongix, 20/05/2026) sont **deux occurrences différentes**. L'historique est conservé. - Côté DATE, la cardinalité est **1,n** : une date n'est enregistrée **que si** un traitement a eu lieu ce jour-là, et plusieurs traitements peuvent avoir lieu le même jour. - La dose reste sur l'association : il faut connaître la parcelle, le produit **et** la date pour la connaître. - Inutile de créer une entité pour une information qui n'a **qu'une valeur** par occurrence d'association (une date de fin, par exemple) : elle reste une propriété de l'association. > [!tip] La question à se poser > « **La même action peut-elle se répéter entre les mêmes objets, et faut-il en garder la trace ?** » Si oui, la date (ou le jour, le mois, l'année, selon la précision utile) doit participer à l'identification → entité DATE. > [!abstract]- Pour aller plus loin > Une autre solution, acceptée aussi, consiste à transformer l'action elle-même en entité : une entité TRAITEMENT avec son propre identifiant (`idTraitement`) et la propriété `dateTraitement`, reliée à PARCELLE et à PRODUIT par des pattes 1,1. Les deux modélisations conservent l'historique. Dans ces ressources, on utilise l'entité DATE. --- ## À retenir > [!summary] À retenir > - On part du **texte métier** → **règles de gestion** numérotées → **dictionnaire de données** épuré (sans synonymes, polysèmes ni propriétés calculées). > - **Propriété** : information élémentaire, au nom précis et unique. **Occurrence** : une valeur ou un objet concret. > - **Entité** : nom au singulier en MAJUSCULES, **identifiant souligné en premier**. Test : « si je connais l'identifiant, je connais une seule valeur ». > - **Association** : verbe à l'infinitif ; elle peut porter des propriétés qui dépendent de **toutes** les entités reliées ; elle peut être binaire, réflexive ou ternaire. > - **Cardinalité** min,max **côté entité**, justifiée par les règles de gestion. Patte **x,1** → pas de propriété sur l'association. > - **Identifiant relatif** : numéro propre + identifiant du parent, patte **1,1 (R)**. > - Pour garder l'**historique** d'une action répétée : **entité DATE** et association ternaire. ⬅️ Précédent : [[Code et Développement/Développement d'Applications/Modèle conceptuel de Données/01_pourquoi_modeliser|01 – Pourquoi modéliser]] · ➡️ Suite : [[Code et Développement/Développement d'Applications/Modèle conceptuel de Données/03_demarche_et_pieges|03 – Démarche et pièges]]