SCENE 2 : Modélisation des Données - L'Architecture de l'Ombre

L'aube est grise. Sur le plan de la ville, les rues se dessinent. Chaque intersection un choix. Chaque bloc, une décision. Avant de construire, il faut penser. Avant de requêter, il faut savoir où chercher.

Concepts Fondamentaux

Les données, c'est comme les témoins.
Certains crient la vérité. D'autres mentent.
La plupart ne savent pas ce qu'ils ont vu.
La modélisation, c'est l'art de les faire parler avant même qu'ils ouvrent la bouche.

Données, Attributs, Entités, Relations

Donnée. La poussière sous l'ongle. L'empreinte sur le verre.
"Dupont". 42. "2023-10-27". "Paris".
Des faits bruts. Inoffensifs. Jusqu'à ce qu'on les relie.

Attribut. Le rôle de la donnée dans la pièce.
Le nom. L'âge. La date. La ville.
Chaque attribut a son théâtre, son domaine. Un âge ne ment pas : c'est un entier. Ou il ment autrement.

Entité. Un joueur. Une pièce sur l'échiquier.
CLIENT. PRODUIT. COMMANDE. EMPLOYÉ.
Pas l'individu, mais l'espèce. Le patronyme avant le prénom.

Occurrence. Le joueur en chair et en os.
Client n°1001 : Jean Dupont, 35 ans, Paris.
Celui qui a du sang sur les mains, ou de l'argent sur le compte.

Relation. Le fil qui les lie.
Ce qui fait qu'un Client passe une Commande.
Qu'un Employé travaille dans un Département.
Les relations, c'est là que les corps sont enterrés.

Diagramme Conceptuel (MCD) – L'Intention du Crime

Un bureau nu. Une feuille blanche. Des rectangles, des losanges. C'est ici qu'on planifie. Avant le sang, il y a l'idée.

Entités, Associations, Cardinalités

Méthode Merise. Un nom qui sent la naphtaline et le tabac froid.
Les rectangles sont les entités. En majuscules. Comme des noms sur des tombes.
Les losanges sont les associations. Les verbes. Ce qui se passe.

Mais le diable est dans les cardinalités.
Ces petits chiffres aux coins des liens.
Ils disent combien de fois. Ils disent obligation.

Exemple : CLIENT --- PASSER --- COMMANDE

Côté CLIENT : (0, n)

• 0 : Peut ne pas participer. Un fantôme. Un client qui n'a jamais commandé.
• n : Peut participer plusieurs fois. Le régulier. Celui qui laisse des traces.

Côté COMMANDE : (1, 1)

• 1 : Doit participer. Toujours. Une commande n'apparaît pas par génération spontanée.
• 1 : Un seul client. Pas de commande collective. La responsabilité est individuelle.

Lire une cardinalité, c'est lire une règle du jeu :
(0,n) – (1,1) : "Un client peut être innocent (0 commande), ou coupable n fois. Mais chaque pièce à conviction (commande) a une et une seule empreinte digitale (client)."

(1,1) – (0,n) : "Un département ne peut exister vide. Il faut au moins un employé pour que la paperasse circule. Mais un employé peut être un homme de l'ombre, sans affiliation."

(0,n) – (0,n) : La zone grise. Plusieurs-à-plusieurs.
ÉTUDIANT – SUIVRE – COURS.
Les alibis se croisent, les histoires s'entremêlent.
Pour gérer ça, il faudra une table intermédiaire. Une chambre noire.

Modèle Logique (MLD) – Le Plan d'Exécution

Le conceptuel, c'est le pourquoi. Le logique, c'est le comment.
On passe de l'intention au mode opératoire. Des rectangles aux tables.

Tables, Colonnes, Clés

Chaque entité devient une table.
CLIENT → client
COMMANDE → commande

Chaque attribut devient une colonne.
nom_client → nom
date_naissance → date_naissance

Les types arrivent. Génériques, pour l'instant.
ENTIER. REEL. CHAINE. DATE.
On est encore dans l'idée, pas dans le matériel.

Les clés. C'est là que ça se corse.

Clé Primaire (PK). L'identifiant unique.
La plaque d'immatriculation. Le numéro de dossier.
Souvent un client_id auto-incrémenté.
Pourquoi pas le nom ? Parce que les noms mentent. Les numéros, moins souvent.

Clé Étrangère (FK). Le fil qu'on laisse derrière soi.
La matérialisation d'une relation.

Traduction des associations :

• (1,1) – (0,n) : La clé étrangère va du côté du "n".
  commande a une colonne client_id qui pointe vers client.client_id.
• (n,n) : On crée une table d'association. Une chambre des témoins.
  inscription avec etudiant_id et cours_id.
  La paire forme la clé primaire. Comme un pacte.

Exemple de MLD :

TABLE Client
    client_id (ENTIER, PK)  -- L'empreinte
    nom (CHAINE)
    prenom (CHAINE)
    email (CHAINE, UNIQUE)  -- Une adresse, un homme
    date_inscription (DATE) -- Le jour où il est entré dans le système

TABLE Commande
    commande_id (ENTIER, PK)
    reference (CHAINE, UNIQUE) -- Le code sur le reçu
    date_commande (DATE)
    client_id (ENTIER, FK vers Client) -- Le lien. La corde.

Modèle Physique (MPD) – L'Arme et l'Empreinte

Le logique dit "un couteau". Le physique dit "un Opinel n°9, lame carbone, affûté à 20 degrés".
C'est l'adaptation au terrain. Au SGBD.

Types Spécifiques et Contraintes

PostgreSQL :

• ENTIER → BIGSERIAL (l'auto-incrément qui a de la gueule)
• REEL → NUMERIC(10,2) (pour l'argent, on veut être précis)
• CHAINE → TEXT (la confession peut être longue)
• DATE → TIMESTAMPTZ (l'heure, c'est important. Et le fuseau aussi.)

MySQL :

• ENTIER → INT UNSIGNED (on est positif, ou on fait semblant)
• REEL → DECIMAL(10,2)
• CHAINE → VARCHAR(255) (la taille standard. Comme un cercueil.)

Contraintes d'Intégrité – Les Lois Non Écrites

1. NOT NULL : L'obligation de témoigner.
   nom VARCHAR(50) NOT NULL. Un inconnu, c'est suspect.

2. UNIQUE : L'exclusivité.
   email VARCHAR(100) UNIQUE. Deux hommes, une même adresse ? L'un ment.

3. PRIMARY KEY : Le sceau. L'unique.

4. FOREIGN KEY avec ON DELETE : La règle du silence.

   • RESTRICT : Empêche de supprimer un parent qui a des enfants. La sécurité.
   • CASCADE : Supprime les enfants avec le parent. Un règlement de comptes.
   • SET NULL : Laisse les enfants orphelins. Une mise au placard.

5. CHECK : La vraisemblance.
   age INT CHECK (age >= 18). Un mineur ne peut pas être dans cette histoire.

Le Script Final – La Mise en Scène

-- Pour PostgreSQL. La ville est humide, le SGBD est rigoureux.

CREATE TABLE client (
    client_id BIGSERIAL PRIMARY KEY, -- Un numéro qui ne se répète pas
    nom TEXT NOT NULL, -- Pas le droit d'être anonyme
    prenom TEXT NOT NULL,
    email TEXT UNIQUE NOT NULL, -- Une identité, une adresse
    date_inscription DATE NOT NULL DEFAULT CURRENT_DATE -- Le jour où il a croisé notre route
    -- Pas de téléphone. Les appels ne laissent pas de traces.
);

CREATE TABLE commande (
    commande_id BIGSERIAL PRIMARY KEY,
    reference VARCHAR(20) UNIQUE NOT NULL, -- Le code sur la facture
    date_commande TIMESTAMPTZ NOT NULL DEFAULT NOW(), -- L'heure, pile
    client_id BIGINT NOT NULL, -- Le lien. La preuve.
    CONSTRAINT fk_client
        FOREIGN KEY (client_id)
        REFERENCES client(client_id)
        ON DELETE RESTRICT -- On ne fait pas disparaître un client qui a des commandes
        ON UPDATE CASCADE -- Si son id change, on suit. Mais ça n'arrive pas.
);

CREATE TABLE ligne_de_commande (
    commande_id BIGINT NOT NULL,
    produit_id BIGINT NOT NULL, -- L'objet du délit
    quantite INT NOT NULL CHECK (quantite > 0), -- On ne commande pas zéro
    prix_unitaire NUMERIC(10,2) NOT NULL CHECK (prix_unitaire >= 0), -- Tout a un prix
    PRIMARY KEY (commande_id, produit_id), -- La combinaison est unique
    CONSTRAINT fk_commande
        FOREIGN KEY (commande_id)
        REFERENCES commande(commande_id)
        ON DELETE CASCADE, -- Si la commande disparaît, les lignes aussi. Nettoyage.
    CONSTRAINT fk_produit
        FOREIGN KEY (produit_id)
        REFERENCES produit(produit_id)
        ON DELETE RESTRICT -- On ne supprime pas un produit qui a été commandé
);

Conclusion du Module

La modélisation, c'est l'heure du crime.
Conceptuel : Pourquoi ?
Logique : Comment ?
Physique : Avec quoi ?

Un bon modèle, c'est comme un bon alibi :
Il tient la route. Il résiste à l'interrogatoire.
Il ne se contredit pas.

Prendre le temps ici, c'est éviter les cadavres dans le placard plus tard.
Les données orphelines. Les références brisées.
Les requêtes qui rampent comme des agonisants.

La ville attend. Les tables sont prêtes.
Maintenant, on peut commencer à chercher les corps.