Comment obtenir le schéma de ma propre base ?

Demandez-le à la personne qui administre la base ou à l'éditeur du logiciel : la liste des tables, de leurs colonnes et des liens entre elles. Beaucoup d'outils de tableaux de bord l'affichent aussi quand on les connecte à la base.

Pourquoi une commande est-elle séparée de ses lignes ?

Parce qu'une commande contient plusieurs produits. La commande garde la date et le client ; chaque ligne garde un produit, une quantité et un prix. C'est ce qui permet de compter à la fois des commandes et des produits vendus.

Que se passe-t-il si on supprime un produit déjà commandé ?

Cela dépend de la règle définie dans la base. La documentation de PostgreSQL montre deux options : refuser la suppression tant que le produit est commandé, ou supprimer automatiquement les lignes liées.

Schéma de base de données : un exemple à lire

Le schéma d'une base de données, c'est son plan : la liste des tables, des colonnes de chaque table, et des liens entre les tables. Le lire vous permet de comprendre d'où vient un chiffre, et de vérifier qu'un outil d'IA a pris la bonne table. Voici un exemple illustratif, celui d'une petite entreprise qui vend des produits à des clients, à lire comme on lit le plan d'un atelier.

L'exemple : cinq tables

clients : une ligne par client.

Colonne	Contenu
`id`	Numéro unique du client (clé primaire)
`nom`	Raison sociale ou nom
`email`	Adresse mail
`ville`	Ville de facturation
`date_creation`	Date de création de la fiche

produits : une ligne par produit.

Colonne	Contenu
`id`	Numéro unique du produit (clé primaire)
`libelle`	Nom du produit
`prix_ht`	Prix catalogue hors taxes
`actif`	Encore vendu ou non

commandes : une ligne par commande.

Colonne	Contenu
`id`	Numéro unique de la commande (clé primaire)
`client_id`	Le client qui a commandé (renvoie à `clients.id`)
`date_commande`	Date de la commande
`statut`	En cours, livrée, annulée…
`montant_ht`	Total hors taxes de la commande

lignes_commande : une ligne par produit dans une commande.

Colonne	Contenu
`id`	Numéro unique de la ligne
`commande_id`	La commande (renvoie à `commandes.id`)
`produit_id`	Le produit (renvoie à `produits.id`)
`quantite`	Quantité commandée
`prix_unitaire_ht`	Prix appliqué ce jour-là

devis : une ligne par devis, avec client_id, date_envoi, statut et montant_ht.

Les liens, en une phrase chacun

clients 1 ── n commandes 1 ── n lignes_commande n ── 1 produits
clients 1 ── n devis

Un client peut avoir plusieurs commandes ; une commande appartient à un seul client.
Une commande contient plusieurs lignes ; chaque ligne porte un seul produit.
Un client peut avoir plusieurs devis.

Deux mots à connaître : clé primaire et clé étrangère

La documentation de PostgreSQL les définit ainsi :

la clé primaire identifie chaque ligne de façon unique ; ses valeurs sont uniques et jamais vides. Ici, clients.id, commandes.id, produits.id ;
la clé étrangère oblige une colonne à contenir une valeur qui existe dans une autre table. Ici, commandes.client_id doit renvoyer à un client qui existe. PostgreSQL donne l'exemple d'une commande qui ne peut pas viser un produit inexistant.

Elle montre aussi ce qu'on peut décider quand une ligne liée est supprimée : refuser la suppression d'un produit encore commandé, ou supprimer automatiquement les lignes d'une commande supprimée. Demandez à votre prestataire quelle règle s'applique chez vous : elle dit ce qu'une suppression peut emporter avec elle.

Ce que le schéma vous apprend sur vos chiffres

Chiffre d'affaires : il se trouve à deux endroits, commandes.montant_ht et la somme des quantite × prix_unitaire_ht dans lignes_commande. Les deux devraient concorder ; s'ils divergent (remises globales, frais de port), il faut savoir lequel fait foi.
Prix : produits.prix_ht est le prix catalogue d'aujourd'hui, lignes_commande.prix_unitaire_ht le prix réellement facturé. Un calcul de chiffre d'affaires passé avec le prix catalogue est faux dès que les prix ont changé.
Clients actifs : rien dans clients ne dit qu'un client est actif. Il faut regarder ses commandes. Une question « combien de clients actifs ? » passe donc forcément par une liaison entre deux tables.
Commandes annulées : elles restent dans la table, avec un statut. Tout total doit les exclure.

Pourquoi l'outil d'IA a besoin du schéma

Un outil qui écrit du SQL (langage de requête structuré) à votre place travaille à partir de ce plan. Google le décrit pour AlloyDB : la traduction d'une question en SQL s'appuie sur une couche de contexte qui décrit tables, colonnes et relations. Metabase indique que, si votre question ne nomme pas de table, Metabot ne regarde que les 100 premières tables de la base et peut inventer des tables qui n'existent pas.

Deux conséquences pratiques :

Nommez la table dans votre question quand vous la connaissez : « dans la table des commandes ».
Rendez les noms lisibles ou décrivez-les : c'est l'objet du dictionnaire de données.

Lire le schéma de votre base

Les vraies bases sont plus grandes : des dizaines, parfois des centaines de tables. Ne cherchez pas à tout comprendre. Repérez les cinq ou six tables qui portent vos questions courantes (clients, ventes, devis, produits, factures), leurs colonnes de date et de montant, et leurs liens. Ensuite, lisez une requête réelle avec ce plan sous les yeux : comprendre une requête SQL et nos exemples annotés utilisent exactement les tables de cette page.