---
term: 'Schéma de Base de Données'
seoTitle: "Qu'est-ce qu'un schéma de base de données ? Guide complet"
headline: "Qu'est-ce qu'un schéma de base de données ?"
slug: schema-de-base-de-donnees
category: database
shortDefinition: 'Un schéma de base de données est un plan qui définit comment les données sont organisées : classes, colonnes, types et relations, mais pas les données.'
relatedTerms:
- data-modeling
- visual-database-management
- class-level-permissions-clp
- database-queries
contrastsWith:
- data-modeling
faq:
- question: "Qu'est-ce qu'un schéma de base de données, en termes simples ?"
answer: "Le plan d'une base de données : quelles tables ou classes existent, quelles colonnes elles portent, le type de chaque colonne, les clés et les contraintes, et comment les enregistrements se relient. Ce sont des métadonnées — la structure, pas les données stockées. Changez le schéma et vous changez la forme que les données peuvent prendre ; les données elles-mêmes vivent à l'intérieur de cette forme."
- question: 'Quelle est la différence entre un schéma, une base de données et une instance ?'
answer: "Trois niveaux de zoom. La base de données est le système entier — le moteur plus les données stockées. Le schéma en est la structure formelle, qui change rarement et délibérément. Une instance, ce sont les données réelles à un instant donné, qui changent à chaque écriture. Un schéma, une base de données, une infinité d'instances au fil du temps."
- question: 'Quelle est la différence entre un schéma logique et un schéma physique ?'
answer: "Le schéma logique est la conception indépendante du moteur : entités, attributs, relations, contraintes — ce que dessine un diagramme entité-association. Le schéma physique, c'est la façon dont cette conception atterrit dans un moteur précis : organisation du stockage, index, partitions. Une troisième couche, le schéma de vue (ou externe), définit ce que chaque consommateur voit. Même conception, trois altitudes."
- question: 'Que contient réellement un schéma ?'
answer: "Les objets du schéma : tables ou classes, colonnes avec leurs types de données, clés primaires et étrangères, contraintes comme NOT NULL, UNIQUE et CHECK, index et vues. Dans certains moteurs, \"schema\" a en plus un second sens — un namespace nommé qui regroupe ces objets et porte des permissions d'accès, ce que crée précisément CREATE SCHEMA."
- question: 'Les bases de données NoSQL ont-elles un schéma ?'
answer: "\"Schemaless\" est un abus de langage — le schéma existe toujours ; la question est de savoir qui l'impose, et quand. Les moteurs relationnels sont schema-on-write : la structure est validée avant que les données n'atterrissent. Les bases documentaires font par défaut du schema-on-read : la structure vit dans les attentes de l'application et n'est vérifiée qu'à l'usage. La plupart des plateformes documentaires prennent aussi en charge la validation aujourd'hui, ce qui fait de la rigueur un curseur plutôt qu'une dichotomie."
- question: "Qu'est-ce qu'une migration de schéma ?"
answer: "Un changement de schéma versionné et scripté — ajouter une colonne, resserrer une contrainte — appliqué de façon incrémentale et dans l'ordre sur tous les environnements. Les migrations sont la façon dont les schémas évoluent sans chaos : chaque changement est relisible, rejouable et réversible, et la version du schéma voyage avec le code qui l'attend."
- question: 'Que sont les schémas en étoile et en flocon ?'
answer: "Des formes de schéma propres à l'analytique. Un schéma en étoile (star) place une table de faits centrale (événements, ventes) au milieu de tables de dimensions dénormalisées — peu de jointures, agrégation rapide. Un schéma en flocon (snowflake) normalise ces dimensions en sous-tables — moins de redondance, plus de jointures. Ils optimisent les charges de reporting et sont les cousins, pas les concurrents, des schémas transactionnels utilisés par les backends applicatifs."
- question: 'Comment définit-on un schéma sur un Backend as a Service ?'
answer: "De deux façons complémentaires : visuellement — des classes et des colonnes typées créées dans un dashboard — et par inférence, où l'enregistrement du premier objet crée la classe et les colonnes typées automatiquement, avec des champs par défaut comme objectId, createdAt, updatedAt et une ACL ajoutés par la plateforme. Le durcissement de production le fige ensuite : changements de schéma pilotés par le client désactivés, évolution ultérieure par le dashboard, délibérément."
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
- name: 'Database schema (Wikipedia)'
url: 'https://en.wikipedia.org/wiki/Database_schema'
- name: 'PostgreSQL — Data Definition documentation'
url: 'https://www.postgresql.org/docs/current/ddl.html'
- name: 'Introduction to database schemas — Prisma Data Guide'
url: 'https://www.prisma.io/dataguide/intro/intro-to-schemas'
- name: 'Back4app database hub documentation'
url: 'https://www.back4app.com/docs'
cta:
title: 'Un schéma que vous pouvez voir'
text: "Sur Back4app, le schéma est une surface vivante : créez classes et colonnes typées dans le dashboard ou laissez le premier enregistrement les inférer, parcourez et faites évoluer le tout visuellement, puis verrouillez-le avec des permissions au niveau des classes au moment de la mise en production."
linkText: 'Commencez gratuitement'
linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-09-10'
translationKey: database-schema
---
**Un schéma de base de données est un plan qui définit comment les données sont organisées : classes, colonnes, types et relations, mais pas les données.** La trinité en une ligne qui mérite d'être retenue : le *schéma* est le plan, une *instance* est l'état des données à un instant donné, et la *base de données* est le bâtiment entier. Les plans changent rarement et délibérément ; les pièces, elles, se remplissent en permanence.
## Points clés
| Question | Réponse |
| --- | --- |
| Ce que c'est | La structure comme métadonnées : tables/classes, colonnes typées, clés, contraintes |
| Ce que ce n'est pas | Les données — c'est l'instance, qui change à chaque écriture |
| Les trois altitudes | Logique (conception) · physique (stockage) · vue (ce que voit chaque consommateur) |
| "Schemaless" ? | Un abus de langage — le schema-on-read ne fait que déplacer la validation au moment de la requête |
| Comment il évolue | Les migrations : des changements versionnés, scriptés, relisibles |
## Le plan, mis par écrit
Un schéma dans sa langue natale — deux tables, des clés, une contrainte, un index et une vue, soit l'essentiel du vocabulaire :
```sql
CREATE TABLE users (
id bigserial PRIMARY KEY,
email text NOT NULL UNIQUE, -- contrainte : pas de doublons
role text NOT NULL DEFAULT 'member'
);
CREATE TABLE orders (
id bigserial PRIMARY KEY,
user_id bigint NOT NULL REFERENCES users(id), -- relation
total numeric(10,2) CHECK (total >= 0), -- règle que les données doivent respecter
placed timestamptz NOT NULL DEFAULT now()
);
CREATE INDEX orders_by_user ON orders (user_id, placed); -- couche physique
CREATE VIEW recent_orders AS -- couche des vues
SELECT * FROM orders WHERE placed > now() - interval '30 days';
```
Le même plan sur une plateforme à schéma flexible pousse à partir de ce que vous enregistrez — des colonnes typées inférées à la première écriture, visibles immédiatement dans un dashboard :
**JavaScript:**
```javascript
// JavaScript / Node.js — Back4app JS SDK
// The schema grows typed columns from what you save
const event = new Parse.Object('Event');
event.set('name', 'Launch day'); // String
event.set('seats', 120); // Number
event.set('startsAt', new Date('2026-09-01T18:00:00Z')); // Date
event.set('venue', new Parse.GeoPoint(38.72, -9.14)); // GeoPoint
await event.save(); // columns exist, typed, visible in the dashboard
```
**Flutter:**
```dart
// Flutter / Dart — Back4app Flutter SDK
// The schema grows typed columns from what you save
final event = ParseObject('Event')
..set('name', 'Launch day') // String
..set('seats', 120) // Number
..set('startsAt', DateTime.parse('2026-09-01T18:00:00Z')) // Date
..set('venue', ParseGeoPoint(latitude: 38.72, longitude: -9.14));
await event.save(); // columns exist, typed, visible in the dashboard
```
**Swift:**
```swift
// iOS / Swift — Back4app Swift SDK
// The schema is a typed struct — columns mirror the model
struct Event: ParseObject {
var objectId: String?; var createdAt: Date?
var updatedAt: Date?; var ACL: ParseACL?; var originalData: Data?
var name: String? // String column
var seats: Int? // Number column
var startsAt: Date? // Date column
var venue: ParseGeoPoint? // GeoPoint column
}
var event = Event(); event.name = "Launch day"; event.seats = 120
event.save { _ in } // columns exist, typed, visible in the dashboard
```
**Kotlin:**
```kotlin
// Android / Kotlin — Back4app Android SDK
// The schema grows typed columns from what you save
val event = ParseObject("Event").apply {
put("name", "Launch day") // String
put("seats", 120) // Number
put("startsAt", Date()) // Date
put("venue", ParseGeoPoint(38.72, -9.14)) // GeoPoint
}
event.saveInBackground() // columns exist, typed, visible in the dashboard
```
## Logique vs. physique vs. vue
```mermaid
flowchart LR
accTitle: Les trois couches du schéma
accDescr: Le schéma logique porte la conception indépendante du moteur, avec les entités et les relations ; le schéma physique la projette sur le stockage avec index et partitions ; les schémas de vue exposent à chaque consommateur une tranche taillée pour lui.
L["Schéma logique
entités · relations · contraintes
(le diagramme entité-association)"]
P["Schéma physique
stockage · index · partitions
(la réalité d'un moteur)"]
V["Schémas de vue
des tranches sur mesure par consommateur"]
L --> P --> V
```
| Distinction | Ceci | vs. cela |
| --- | --- | --- |
| Schéma vs. instance | Le plan, change rarement | L'instantané des données, change en permanence |
| Logique vs. physique | Conception indépendante du moteur | Décisions de stockage propres à un moteur |
| Plan vs. namespace | "Le schéma" de votre application | `CREATE SCHEMA` — un conteneur nommé d'objets, avec des permissions |
| Schema-on-write vs. on-read | Validé avant que les données n'atterrissent (relationnel) | Imposé au moment de l'usage (défaut documentaire) |
| Transactionnel vs. analytique | Schémas applicatifs normalisés | Formes en étoile/flocon bâties pour l'agrégation |
La troisième ligne désamorce une ambiguïté réelle que la plupart des explications esquivent : dans certains moteurs, le mot désigne aussi un *namespace* — un conteneur de tables muni de permissions — de sorte que "le schéma" peut désigner le plan de votre application ou un dossier à l'intérieur de la base de données, et c'est le contexte qui tranche.
## Schema-on-write vs. schema-on-read
Les bases de données "schemaless" ont bien un schéma — elles le facturent simplement autrement. Le **schema-on-write** valide la structure avant que les données n'atterrissent : mauvais type, champ manquant, référence cassée — rejetés à la porte. Le **schema-on-read** accepte les écritures avec souplesse et n'impose les attentes qu'à l'usage — itération plus rapide, et chaque lecteur devient un validateur. La position moderne est un curseur, pas une guerre : les plateformes documentaires ajoutent de la validation, les moteurs relationnels ajoutent des colonnes JSON, et les backends gérés coupent la poire en deux — types inférés et imposés par colonne, tandis que de nouvelles colonnes apparaissent sans cérémonie de migration. La question de la rigueur est en réalité une question de responsabilité : *qui* trouve l'enregistrement malformé, la base de données au moment de l'écriture ou votre code à 2 h du matin ?
## Comment les schémas évoluent
Le plan survit à son premier jet, et les **migrations** sont la façon dont il change sans chaos : chaque changement de schéma est un script versionné — ajouter la colonne, la remplir rétroactivement, resserrer la contrainte — appliqué dans l'ordre, sur chaque environnement, relu comme le code qui en dépend. Deux disciplines portent l'essentiel de la valeur : rendre les changements *rétrocompatibles* pendant la fenêtre où ancien et nouveau code cohabitent (ajouter, puis migrer, puis supprimer — jamais renommer sur place), et garder la version du schéma dans le dépôt pour que code et structure voyagent ensemble. Sur les plateformes pilotées par dashboard, la même discipline s'applique avec un outillage différent — faites évoluer visuellement, mais délibérément, avec les changements de schéma pilotés par le client désactivés en production.
## Cas d'usage courants
- **Concevoir un nouveau backend.** Le schéma est la sortie de la [modélisation de données](/glossary/fr/modelisation-de-donnees/) : entités et arêtes deviennent classes, colonnes et clés.
- **Imposer l'intégrité.** Les contraintes comme règles exécutables — totaux non négatifs, e-mails uniques — attrapées par le moteur, pas par des rapports de bug.
- **Contrat d'équipe.** Le schéma est le vocabulaire partagé entre backend, frontend et analytique ; un diagramme entité-association est une documentation qui ne peut pas dériver.
- **Fondations de performance.** Les index et l'organisation physique — l'étage du dessous du schéma — décident quelles requêtes restent rapides à l'échelle.
- **Surface de sécurité.** Les permissions au niveau du schéma contrôlent qui peut faire quoi par classe — structure et contrôle d'accès au même endroit.
## Quelle rigueur pour votre schéma ? Matrice de décision
| Préférez strict (schema-on-write) quand… | Préférez flexible (inférer + valider) quand… |
| --- | --- |
| Les erreurs de données coûtent cher (argent, stock) | Vous itérez sur le produit toutes les semaines |
| Beaucoup d'écrivains, un seul contrat | Une seule équipe possède le code et les données |
| L'analytique dépend de colonnes stables | Les champs varient réellement d'un enregistrement à l'autre |
| Les contraintes encodent des règles métier | Les règles vivent de toute façon dans la validation côté serveur |
| Les migrations sont une routine pour l'équipe | La cérémonie de migration freinerait la découverte |
Le choix par défaut pragmatique pour un backend applicatif : flexible pendant que vous apprenez, durci au moment de livrer — inférez le schéma en développement, puis figez-le (aucun changement de schéma depuis le client, ajout de champ désactivé) le jour où les vrais utilisateurs arrivent.
## Limites et trade-offs
- **Le schéma fige des hypothèses.** Chaque décision de type de colonne et de cardinalité est gratuite aujourd'hui et une migration demain — concevez pour la taille au-dessus.
- **La rigueur taxe l'itération.** Chaque expérimentation paie le péage de la migration ; c'est le prix des garanties, pas un défaut.
- **La souplesse taxe les lecteurs.** Le schema-on-read déplace la validation chez chaque consommateur ; sans discipline, "flexible" devient "cinq formes du même enregistrement".
- **La couche physique est invisible jusqu'à ce qu'elle ne le soit plus.** Index et organisation ne changent pas l'exactitude des résultats — seulement la survie des requêtes à la croissance.
- **Les permissions de namespace ne sont pas de la conception.** `CREATE SCHEMA` organise et protège des objets ; il ne rend pas le plan bon pour autant.
## Le schéma sur Back4app
Back4app est une plateforme open-source de Backend as a Service (BaaS) qui combine une base de données gérée, des API REST et GraphQL générées automatiquement, l'authentification, le stockage de fichiers et des fonctions serverless avec Cloud Code. Le schéma y est une surface visible et de première classe : définissez classes et colonnes typées dans le dashboard, ou laissez le premier enregistrement les inférer — les onglets de code ci-dessus créent de vraies colonnes typées, avec `objectId`, `createdAt`, `updatedAt` et une ACL ajoutés par défaut à chaque classe. Tout ce que le schéma déclare se reflète instantanément dans les [API générées automatiquement](/glossary/fr/apis-generees-automatiquement/), est gardé par les [permissions au niveau des classes](/glossary/fr/permissions-de-classe-clp/) et se parcourt dans le [dashboard visuel](/glossary/fr/gestion-visuelle-de-base-de-donnees/) — le plan, son application et la documentation en un seul artefact.