Schema
Aussi : Data Schema, Database Schema, Data Model Definition
Un schema est le plan formel qui définit comment les données sont structurées, nommées, typées et reliées entre elles au sein d'une base de données, d'un fichier ou d'un message.
De quoi il s'agit
Un schema est une définition formelle de l'organisation des données. Il précise les entités (tables, objets ou champs), leurs noms, leurs types de données, ainsi que les relations et contraintes qui les relient. Voyez-le comme le plan des données : il décrit la forme que les données doivent respecter avant que la moindre valeur soit stockée ou échangée.
Les schemas apparaissent dans de nombreux contextes :
- Schema de base de données : tables, colonnes, clés primaires et étrangères, index et contraintes dans un système relationnel.
- Schema d'échange de données : structures comme JSON Schema, Avro, Protobuf ou XSD qui valident les messages transmis entre systèmes.
- Schema analytique : modèles dimensionnels de type star ou snowflake utilisés dans les data warehouses.
Pourquoi c'est important
Un schema est le contrat entre les personnes et les systèmes qui produisent les données et ceux qui les consomment. Sans lui, la qualité des données et l'interopérabilité s'effondrent.
- Cohérence : chaque enregistrement suit les mêmes règles, si bien qu'un champ comme `birth_date` contient toujours une date valide.
- Validation : les données invalides ou mal formées peuvent être rejetées tôt, avant de polluer les rapports ou les modèles en aval.
- Communication : les équipes data, marketing, finance et IA peuvent s'accorder sans ambiguïté sur le sens des champs.
- Gouvernance : les schemas soutiennent la traçabilité, le contrôle des accès et la conformité réglementaire.
Dans les workflows d'IA, les schemas comptent parce que les modèles dépendent de features en entrée stables et bien typées. Un changement de schema silencieux (une colonne renommée ou un type modifié) peut dégrader un modèle sans déclencher d'erreur visible.
Comment on l'utilise en pratique
En pratique, les équipes conçoivent un schema avant de construire les pipelines, puis l'imposent avec des outils de validation. Une approche schema-on-write valide les données au moment du stockage (typique des bases relationnelles). Une approche schema-on-read applique la structure au moment de la requête (courant dans les data lakes). Les plateformes modernes utilisent souvent un schema registry pour versionner les schemas et gérer la compatibilité à mesure que les systèmes évoluent.
Exemple concret
Une table `customers` peut définir :
- `customer_id` : entier, clé primaire, non null
- `email` : chaîne, unique, non null
- `signup_date` : date
- `country` : chaîne, longueur maximale 2
Un enregistrement de commande référence `customer_id` comme clé étrangère. Le schema garantit que chaque commande est reliée à un client réel et que `email` n'est jamais vide, ce qui maintient le jeu de données fiable pour l'analytics et l'IA.
Questions fréquentes
Qu'est-ce qu'un schéma en matière de données ?
Un schéma est la définition formelle de l'organisation des données : les entités (tables, objets, champs), leurs noms, leurs types et les relations et contraintes qui les relient. Il décrit la forme que les données doivent respecter avant tout stockage ou échange. Il fait office de contrat entre les systèmes qui produisent les données et ceux qui les consomment.
Quelle différence entre un schéma de base de données et un schéma d'échange de données ?
Un schéma de base de données décrit les tables, colonnes, clés primaires et étrangères, index et contraintes d'un système relationnel. Un schéma d'échange, comme JSON Schema, Avro, Protobuf ou XSD, valide les messages transmis entre systèmes. Une troisième famille, les schémas analytiques, regroupe les modèles dimensionnels de type étoile ou flocon utilisés en data warehouse.
Pourquoi un changement de schéma casse-t-il un modèle de machine learning sans message d'erreur ?
Parce qu'un modèle dépend de features stables et correctement typées. Si une colonne est renommée ou son type modifié, le pipeline peut continuer à tourner alors que le modèle reçoit des entrées dégradées, et la qualité des prédictions chute silencieusement. D'où l'importance du versionnement et de la validation des schémas dans les workflows IA autant que dans le reporting.
Quand choisir le schema-on-write plutôt que le schema-on-read ?
Le schema-on-write valide les données au moment du stockage : c'est l'approche des bases relationnelles et de tous les cas où les enregistrements invalides doivent être rejetés avant d'atteindre les rapports en aval. Le schema-on-read applique la structure à la lecture, pratique courante dans les data lakes où l'on conserve la donnée brute pour l'interpréter plus tard. Le compromis se joue entre contrôle qualité en amont et souplesse d'ingestion.
À quoi ressemble concrètement un schéma pour une table clients ?
Une table `customers` peut définir `customer_id` en entier, clé primaire non nulle, `email` en chaîne unique non nulle, `signup_date` en date et `country` en chaîne limitée à deux caractères. Une commande référence ensuite `customer_id` comme clé étrangère. Le schéma garantit que chaque commande pointe vers un client réel et qu'aucun email n'est vide, ce qui rend le jeu de données exploitable pour l'analytics et l'IA.