Bases de données relationnelles et anomalies de schéma

Introduction

Une base de données relationnelle est un ensemble de relations cohérent entre elles, conçu pour stocker durablement des données nombreuses. Mais toutes les structures ne se valent pas : un schéma mal pensé condamne la base à des redondances et à des anomalies qui apparaissent au fur et à mesure que les données s'accumulent. Ce cours examine ce qu'est une bonne structure, en partant de l'exemple d'une mauvaise.

Structure et contenu

Reprenez la distinction du cours précédent : la structure d'une base est l'ensemble de ses schémas relationnels (relations, attributs, domaines, contraintes). Le contenu est la collection actuelle des n-uplets. Le même contenu peut être rangé selon des structures très différentes — et c'est ce choix qui détermine la qualité de la base.

Une bonne analogie : un article de Wikipédia. La même information factuelle (la date de naissance d'un auteur, par exemple) peut figurer sur sa propre page et sur la page de son éditeur. Si quelqu'un corrige une page sans toucher à l'autre, l'encyclopédie devient localement incohérente. Une base mal structurée souffre du même mal, en pire : la contradiction y est silencieuse et systématique.

Un schéma défectueux : la table fourre-tout

Reprenons la base scolaire du cours précédent. Imaginez qu'au lieu de trois relations bien séparées, un développeur pressé range tout dans une seule grosse table :

Le nom et la classe de Camus apparaissent deux fois. L'intitulé du cours NSI et son niveau apparaissent deux fois aussi. C'est une redondance.

Les trois anomalies classiques

Sur ce schéma fourre-tout, trois familles d'anomalies surgissent :

Anomalie d'insertion — vous ne pouvez pas enregistrer un nouvel élève tant qu'il n'est pas inscrit à un premier cours, puisque chaque ligne exige un id_cours et une date. Le schéma confond exister comme élève et être inscrit.

Anomalie de suppression — vous supprimez l'inscription d'identifiant 2. Si c'était l'unique inscription de Duras, vous perdez du même coup la seule trace de sa classe. Vous vouliez retirer un événement, vous effacez une entité entière. Comme dans un vieux carnet d'adresses papier où l'on gomme la ligne d'un contact : on supprime le rendez-vous, mais le numéro de téléphone et l'adresse partent avec.

Anomalie de mise à jour — Camus change de classe à la rentrée. Vous devez modifier toutes les lignes où sa classe apparaît. Si vous en oubliez une, la base devient incohérente : deux classes pour le même élève.

Le remède : décomposer

La règle empirique : une relation décrit un seul type d'entité. On décompose la table fourre-tout en trois relations — celles qui structuraient déjà le cours précédent :

• Eleve(id_eleve, nom, prenom, classe)
• Cours(id_cours, intitule, niveau)
• Inscription(id_eleve, id_cours, date_inscription)

Désormais Camus n'apparaît qu'une seule fois dans Eleve, le cours NSI une seule fois dans Cours, et les inscriptions ne stockent que les références vers les entités concernées. Les trois anomalies disparaissent :

• vous insérez un nouvel élève dans Eleve sans toucher à Inscription ;
• vous supprimez une inscription sans toucher à l'élève ;
• vous modifiez la classe de Camus dans une seule ligne de Eleve.

Normalisation — survol

Ce processus de décomposition s'appelle la normalisation. La théorie définit des formes normales (1FN, 2FN, 3FN…) qui formalisent la qualité d'un schéma. À votre niveau, retenez la règle pratique :

Repérer une anomalie dans un schéma proposé est une compétence du programme : prenez l'habitude, devant une grosse table, de chercher les redondances avant de l'utiliser.