1-X75-LDB

Exercice 1 : Cinéma – Films et Acteurs

graph TD
  FILM["FILM"]
  ACTEUR["ACTEUR"]
  
  JOUE_DANS(("JOUE_DANS"))
  
  FILM --- |"0,N"| JOUE_DANS
  JOUE_DANS --- |"0,N"| ACTEUR

Cardinalités :

Penser “base de données”

Quand on dit “un film peut avoir zéro ou plusieurs acteurs”, on ne parle pas de tous les films en général, mais d’un film précis dans la base.

Exemple concret :

De l’autre côté, l’acteur “Leonardo DiCaprio” (un enregistrement) a joué dans 25 films enregistrés dans la base.

Les cardinalités décrivent combien d’enregistrements peuvent être liés, pas des généralités sur la table entière.

Exercice 2 : Librairie – Livres et Auteurs

graph TD
  LIVRE["LIVRE"]
  AUTEUR["AUTEUR"]
  
  ECRIT_PAR(("ECRIT_PAR"))
  
  LIVRE --- |"1,N"| ECRIT_PAR
  ECRIT_PAR --- |"0,N"| AUTEUR

Cardinalités :

Penser “base de données”

“Un livre est écrit par un ou plusieurs auteurs” signifie : chaque ligne de la table LIVRE doit être liée à au moins une ligne de la table AUTEUR.

Exemple concret :

Du côté auteur, l’auteur “Marie Dupont” (un enregistrement) peut avoir écrit 0 livres si elle vient d’être ajoutée, ou 50 livres si elle est prolifique.

Pourquoi (1,N) et pas (0,N) ? Dans une librairie, on n’enregistre pas de livres sans connaître l’auteur. C’est une règle métier : tout livre doit avoir au moins un auteur.

Exercice 3 : Blog – Articles et Éditeurs

graph TD
  ARTICLE["ARTICLE"]
  EDITEUR["EDITEUR"]
  
  PUBLIE(("PUBLIE"))
  
  ARTICLE --- |"1,N"| PUBLIE
  PUBLIE --- |"0,N"| EDITEUR

Cardinalités :

Penser “base de données”

Chaque article (une ligne spécifique) doit être lié à au moins un éditeur qui l’a publié ou modifié.

Exemple concret :

L’éditeur “Jean Martin” (un enregistrement) peut avoir publié 0 article s’il vient d’être embauché, ou 300 articles s’il travaille là depuis des années.

La règle métier : Un article ne peut pas exister dans le système sans qu’un éditeur l’ait créé. C’est pour ça que le minimum est 1, pas 0.

Exercice 4 : Transport – Pays et Villes

graph TD
  PAYS["PAYS"]
  VILLE["VILLE"]
  
  CONTIENT(("CONTIENT"))
  
  PAYS --- |"0,N"| CONTIENT
  CONTIENT --- |"1,1"| VILLE

Cardinalités :

Penser “base de données”

Attention au piège ! “Un pays contient zéro ou plusieurs villes” ne veut pas dire qu’un pays réel n’a pas de villes. Cela signifie : dans notre base de données, un pays (un enregistrement) peut être présent sans qu’on ait encore enregistré ses villes.

Exemple concret :

De l’autre côté, la ville “Paris” (un enregistrement) appartient à exactement 1 pays : la France. Elle ne peut pas appartenir à 0 pays (elle doit être quelque part) ni à 2 pays (une ville n’est que dans un seul pays).

Pourquoi (0,N) pour le pays ? Parce qu’on veut pouvoir enregistrer un pays dans le système avant d’avoir référencé toutes ses villes. Sinon, il faudrait tout saisir d’un coup, ce qui n’est pas pratique.

Exercice 5 : Langues du monde

graph TD
  LANGUE["LANGUE"]
  REGION["REGION"]
  
  PARLEE_DANS(("PARLEE_DANS"))
  
  LANGUE --- |"0,N"| PARLEE_DANS
  PARLEE_DANS --- |"0,N"| REGION

Cardinalités :

Penser “base de données”

Ici, les deux côtés ont (0,N), ce qui signifie qu’on peut enregistrer des langues et des régions indépendamment avant de les lier.

Exemple concret :

De l’autre côté :

Pourquoi (0,N) des deux côtés ? Parce qu’on veut un catalogue complet de langues (même mortes) et de régions (même non documentées). On les relie ensuite progressivement.

Exercice 6 : E-commerce – Clients et Produits

graph TD
  CLIENT["CLIENT"]
  COMMANDE["COMMANDE"]
  PRODUIT["PRODUIT"]
  
  PASSE(("PASSE"))
  CONTIENT(("CONTIENT"))
  
  CLIENT --- |"0,N"| PASSE
  PASSE --- |"1,1"| COMMANDE
  
  COMMANDE --- |"1,N"| CONTIENT
  CONTIENT --- |"0,N"| PRODUIT

Cardinalités :

Penser “base de données”

Ce modèle montre 3 tables liées par 2 relations.

Exemple concret pour CLIENT → COMMANDE :

Pourquoi (0,N) pour le client ? On veut pouvoir créer un compte client avant qu’il n’achète quoi que ce soit.

Exemple concret pour COMMANDE → PRODUIT :

Pourquoi (1,N) pour la commande ? Une commande vide n’a aucun sens. Si elle existe, c’est qu’elle contient au moins un produit.

Pourquoi (0,N) pour le produit ? Un produit peut exister dans le catalogue avant d’avoir été commandé.

Exercice 7 : Hôpital – Médecins et Patients

graph TD
  MEDECIN["MEDECIN"]
  PATIENT["PATIENT"]
  CONSULTATION["CONSULTATION"]
  
  REALISE(("REALISE"))
  CONCERNE(("CONCERNE"))
  
  MEDECIN --- |"0,N"| REALISE
  REALISE --- |"1,1"| CONSULTATION
  
  PATIENT --- |"0,N"| CONCERNE
  CONCERNE --- |"1,1"| CONSULTATION

Cardinalités :

Penser “base de données”

Ici, CONSULTATION est une entité centrale qui lie médecins et patients. Chaque consultation est un événement précis.

Exemple concret côté MEDECIN :

Exemple concret côté PATIENT :

Pourquoi (1,1) des deux côtés pour CONSULTATION ? Une consultation ne peut pas exister sans médecin ET sans patient. C’est l’événement qui les relie. On ne peut pas avoir :

Exercice 8 : École – Étudiants et Cours

graph TD
  ETUDIANT["ETUDIANT"]
  COURS["COURS"]
  
  SUIT(("SUIT"))
  
  ETUDIANT --- |"0,N"| SUIT
  SUIT --- |"0,N"| COURS

Cardinalités :

Penser “base de données”

Les deux côtés sont (0,N), ce qui donne beaucoup de flexibilité au système.

Exemple concret côté ETUDIANT :

Exemple concret côté COURS :

Pourquoi (0,N) des deux côtés ?

Cette flexibilité permet de gérer les périodes d’inscription, les cours annulés faute d’étudiants, les étudiants en pause, etc.