Concevoir un schéma de base de données normalisé
Transformez des besoins métier en schéma relationnel normalisé : entités, clés, contraintes, index, DDL et requêtes de validation. Conçu pour ChatGPT, Claude et Gemini. Il comprend 6 variables personnalisables et vous pouvez le copier gratuitement en un clic.
Avancé · Code · En attente de relecture éditoriale
Prompt
Agis comme un architecte de données expérimenté en modélisation relationnelle et en {{engine}}.
Contexte de l'application : {{application}}.
Exigences fonctionnelles (ce que le système doit stocker et permettre) : {{requirements}}.
Volume estimé : {{volume}}.
Requêtes les plus fréquentes : {{queries}}.
Livre, dans cet ordre :
1. Les entités et attributs déduits des exigences, en signalant toute ambiguïté que tu as besoin que je clarifie.
2. Un diagramme entité-relation en syntaxe Mermaid (`erDiagram`) avec les cardinalités.
3. La justification de la normalisation en 3FN (et les cas où une dénormalisation volontaire a du sens, avec la raison).
4. Le DDL complet pour {{engine}} : types de données adaptés, clés primaires (et le choix entre entiers, UUID ou ULID), clés étrangères avec un `ON DELETE` argumenté, contraintes `NOT NULL`, `UNIQUE`, `CHECK` et valeurs par défaut.
5. Les index recommandés pour les requêtes fréquentes, avec une explication pour chacun.
6. Une stratégie pour les suppressions logiques, l'audit (`created_at`, `updated_at`) et les données personnelles sensibles.
7. Trois exemples de requêtes SQL prouvant que le schéma couvre les principaux cas d'usage.
8. Les risques d'évolution du schéma et la façon de les gérer avec des migrations.
Contraintes :
- N'ajoute pas d'entités qui ne découlent pas des exigences sans me le dire.
- Utilise des noms de tables et de colonnes en {{naming_language}}, en snake_case.
- S'il manque une information critique, pose-moi la question avant d'écrire le DDL.Comment l'utiliser
- Rédigez les besoins sous forme de phrases simples : « un client peut avoir plusieurs adresses ».
- Ajoutez les requêtes que vous lancerez le plus souvent ; ce sont elles qui déterminent les index.
- Collez le diagramme Mermaid dans un afficheur compatible pour le relire.
- Exécutez le DDL sur une base de test avant d’écrire les migrations définitives.
Exemple d'utilisation
Application : gestion d’une école de langues · Besoins : élèves, cours, groupes de classe, inscriptions et paiements mensuels · Moteur : PostgreSQL 16.
Exemple de résultat
4. DDL (extrait, PostgreSQL 16)
CREATE TABLE students (
id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
full_name text NOT NULL,
email text NOT NULL UNIQUE,
created_at timestamptz NOT NULL DEFAULT now(),
deleted_at timestamptz -- suppression logique
);
CREATE TABLE enrollments (
id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
student_id bigint NOT NULL REFERENCES students (id) ON DELETE RESTRICT,
class_group_id bigint NOT NULL REFERENCES class_groups (id) ON DELETE RESTRICT,
enrolled_on date NOT NULL DEFAULT current_date,
UNIQUE (student_id, class_group_id)
);
CREATE TABLE monthly_payments (
id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
enrollment_id bigint NOT NULL REFERENCES enrollments (id) ON DELETE RESTRICT,
period date NOT NULL CHECK (extract(day FROM period) = 1),
amount_cents integer NOT NULL CHECK (amount_cents >= 0),
paid_at timestamptz,
UNIQUE (enrollment_id, period)
);
-- Index partiel pour « élèves avec des paiements en retard »
CREATE INDEX idx_payments_unpaid ON monthly_payments (period) WHERE paid_at IS NULL;
ON DELETE RESTRICT évite de perdre l'historique des paiements si quelqu'un supprime un élève : d'où la suppression logique. Les montants sont stockés en centimes pour éviter les erreurs d'arrondi.
Ambiguïtés
- Un paiement couvre-t-il une inscription ou toutes celles de l'élève sur le mois ? [À COMPLÉTER]…
Informations clés
- Catégorie
- Programmation et développement · SQL
- Type de résultat
- Code
- Niveau
- Avancé
- Conçu pour
- ChatGPT, Claude et Gemini
- Vérifié sur
- En attente de vérification éditoriale
- Variables
- Moteur de base de données, Application, Besoins, Volume estimé, Requêtes fréquentes et Langue de nommage
- Langue
- Français
- Prix
- Gratuit, sans inscription
- Mis à jour
- 07/11/2026
Questions fréquentes
Faut-il toujours normaliser jusqu’en 3FN ?
C’est un bon point de départ qui évite les doublons et les incohérences. Pour le reporting ou des tables très sollicitées en lecture, dénormaliser peut être rentable, mais ce doit être une décision consciente et documentée.
UUID ou identifiants entiers ?
Les entiers sont compacts et rapides ; les UUID ou ULID évitent de révéler le nombre d’enregistrements et peuvent être générés hors de la base. Le prompt demande à l’IA de justifier son choix.
À quoi sert ce prompt ?
Transformez des besoins métier en schéma relationnel normalisé : entités, clés, contraintes, index, DDL et requêtes de validation.
Avec quels outils d'IA fonctionne-t-il ?
Il est conçu pour ChatGPT, Claude et Gemini. Nous ne l'avons pas encore vérifié sur ces outils ; les résultats peuvent donc varier de l'un à l'autre.
Comment personnaliser le prompt ?
Cliquez sur « Personnaliser » et remplissez les variables (Moteur de base de données, Application, Besoins, Volume estimé, Requêtes fréquentes et Langue de nommage). Le texte se met à jour instantanément et vous pouvez ensuite le copier en un clic. Les valeurs sont stockées uniquement dans votre navigateur.
Faut-il de l'expérience pour l'utiliser ?
Il est de niveau avancé : il s'adresse aux personnes expérimentées dans le domaine, capables d'évaluer et d'ajuster le résultat.
Ce prompt est-il gratuit ?
Oui. Tous les prompts de HomeCasa Prompts sont gratuits, sans inscription ni abonnement. Vous pouvez aussi les utiliser dans des projets professionnels.
Puis-je me fier au résultat de l'IA ?
Considérez-le comme un brouillon de qualité : vérifiez toujours les données, les chiffres et les affirmations importantes avant de publier ou de prendre des décisions.