Décomposer les règles métier en relations
Objectif : Traduire les règles de gestion de la médiathèque en entités, relations et cardinalités.
Un prêt mal représenté peut associer un adhérent au mauvais exemplaire, perdre l’historique des retours ou rendre ambigu le suivi d’un retard. Avant d’écrire les tables SQL, vous devez donc décrire ce que la médiathèque gère et les liens entre ces éléments. Vous allez transformer des règles de gestion concrètes en un modèle relationnel compréhensible.
Partir des règles métier
Une règle métier décrit une contrainte ou une action du domaine, sans imposer d’abord une structure SQL. Par exemple : « une œuvre peut avoir plusieurs exemplaires », « un exemplaire ne peut faire l’objet que d’un seul emprunt en cours » et « un emprunt concerne un adhérent et un exemplaire ». Écrivez ces règles en phrases courtes : elles constituent la référence pour vérifier ensuite que le modèle ne perd aucune information.
Une entité est un type d’élément métier sur lequel vous devez conserver des informations. Dans le projet, les entités principales sont adherents, oeuvres, exemplaires et emprunts. retards représente les retards enregistrés et associés aux emprunts ; ce n’est pas un autre nom pour l’emprunt lui-même. Distinguer une œuvre de ses exemplaires est essentiel : le catalogue décrit un titre, tandis que chaque exemplaire désigne une copie physique susceptible d’être prêtée.
Décrire les relations et leurs cardinalités
Une relation exprime le lien entre deux entités. Une cardinalité indique combien d’occurrences peuvent être liées de chaque côté. Pour les œuvres et les exemplaires, la règle usuelle est : une œuvre peut avoir zéro, un ou plusieurs exemplaires ; chaque exemplaire décrit une seule œuvre. En notation minimale/maximale, cela donne oeuvres (0,N) — exemplaires (1,1). Le minimum zéro est utile : une œuvre peut être enregistrée au catalogue avant l’arrivée de ses copies.
| Règle métier | Relation | Cardinalités |
|---|---|---|
| Une œuvre peut être disponible en plusieurs copies. | œuvres — exemplaires | œuvres (0,N) ; exemplaires (1,1) |
| Un adhérent peut effectuer plusieurs emprunts au fil du temps. | adhérents — emprunts | adhérents (0,N) ; emprunts (1,1) |
| Un exemplaire peut apparaître dans plusieurs emprunts successifs. | exemplaires — emprunts | exemplaires (0,N) ; emprunts (1,1) |
| Un retard enregistré concerne un emprunt. | emprunts — retards | emprunts (0,N) ; retards (1,1) |
La relation entre adhérents et exemplaires n’est pas simplement « un adhérent possède plusieurs exemplaires ». Elle passe par emprunts, qui conserve les événements : qui a emprunté quel exemplaire, et à quelles dates. Un même exemplaire peut donc être emprunté par différentes personnes à des moments distincts. La règle « un seul emprunt en cours à la fois pour un exemplaire » porte sur les emprunts actifs ; elle ne supprime pas les emprunts terminés de l’historique.
Repérer les dépendances entre les données
Une dépendance fonctionnelle signifie qu’une valeur permet de déterminer une autre valeur dans les règles du domaine. Par exemple, si chaque exemplaire possède un numéro d’inventaire distinct, ce numéro identifie cet exemplaire ; les informations propres à cette copie, comme son état, dépendent alors de cet exemplaire. De même, un emprunt détermine les dates qui décrivent cet événement et les entités qui y sont associées.
Un identifiant métier est une donnée déjà porteuse de sens dans l’activité, comme un numéro d’inventaire attribué par la médiathèque. Vérifiez qu’il est réellement unique et stable avant de l’utiliser pour distinguer les occurrences. Un titre d’œuvre, par exemple, ne suffit pas forcément : plusieurs œuvres peuvent partager le même titre. Le choix des clés et des contraintes qui matérialiseront ces distinctions sera traité dans une prochaine leçon.
Formaliser le modèle avant SQL
Avant de modifier sql/schema.sql, consignez les entités, les liens, les cardinalités et les règles particulières dans une fiche de conception. Voici le vocabulaire à préserver dans le projet : les adhérents effectuent des emprunts ; les emprunts portent sur des exemplaires ; les exemplaires appartiennent à des œuvres ; les retards sont rattachés aux emprunts. Ce modèle exprime les relations sans encore fixer les détails de leur traduction en colonnes et en contraintes SQL.
À retenir
- Déduisez les entités des éléments métier que vous devez décrire et conserver.
- Exprimez chaque relation dans les deux sens et précisez ses cardinalités minimale et maximale.
- Séparez l’œuvre de ses exemplaires et l’emprunt de son éventuel retard.
- Vérifiez quelles données dépendent de chaque occurrence avant de choisir leur emplacement.
- Conservez les règles de gestion comme référence avant d’écrire le schéma SQL.
La prochaine leçon transforme ce modèle en tables normalisées, en recherchant une structure qui évite la répétition sans perdre d’information.