Lycée > Terminale > NSI > Repérer des anomalies dans une base de données relationnelle

Repérer des anomalies dans une base de données relationnelle

Fiche de cours
Quiz
Profs en ligne
Videos
Application mobile

Objectif

Dans une base de données relationnelle, repérer les anomalies dans le schéma d’une relation.

Points clés

Les données d’une base de données doivent respecter certaines règles, sous peine de générer des anomalies.
On peut repérer les anomalies d’une base de données en étudiant le schéma d’une relation de cette base de données.
Les anomalies peuvent être des redondances de données ou des anomalies d’insertion, de suppression, de mise à jour de ces données.

Pour bien comprendre

Base de données et schéma relationnel
L’algèbre relationnel

1. Anomalies d’une base de données et schéma d’une relation

a. Le principe d'une base de données (rappels)

Une base de données est une collection de données qui vont être partagées entre plusieurs services, serveurs, utilisateurs.

Les données d’une base de données relationnelle sont rangées dans des tables nommées relations, qui contiennent différents enregistrements (lignes) qui doivent tous être différents.

Chaque colonne de la table est appelée un attribut de la relation, et chaque attribut doit prendre une seule valeur pour chaque enregistrement.

b. Les anomalies d’une base de données relationnelle

Les données d’une base de données doivent respecter certaines règles, sous peine de générer des anomalies.

On peut repérer les anomalies d’une base de données en étudiant le schéma d’une relation de cette base de données, ou le schéma relationnel de cette base de données.

Rappels

Le schéma d’une relation définit cette relation. Il est constitué du nom de la relation, du nom de ses attributs, de la clé primaire et des clés étrangères.
Le schéma relationnel correspond à l'ensemble des relations présentes dans une base de données, qui sont associées entre elles.

Parmi les anomalies les plus courantes dans une base de données, il peut y avoir une redondance des données, ou encore un problème pour modifier, supprimer ou insérer des données.

Remarque
Derrière ces notions d’anomalies se cachent des notions de dépendances fonctionnelles et de normalisation des relations, mais cela est hors programme.

2. L’anomalie de redondance

Dans une base de données, on évite la redondance des données.

Si des enregistrements sont redondants dans une ou plusieurs relations (tables), on peut en effet oublier de modifier l’un de ces enregistrements lors d’une mise à jour ; on aurait alors par exemple deux produits totalement identiques mais avec un prix différent, cela crée une incohérence qui risque de faire bugger le programme.

Dans une base de données, on doit avoir des valeurs d'attributs différents pour chaque enregistrement, afin de conserver l'unicité des enregistrements.

Pour repérer une anomalie de redondance dans le schéma d’une relation, il faut rechercher des valeurs identiques pour un même attribut.

Exemple
On étudie le schéma de la relation CLIENTS, où on repère les répétitions de données par des fonds de couleurs.

CLIENTS
id	nom	ville	num_livre	cours	note
101	ABC	Toulon	2345	NSI	15
234	DEF	Paris	2345	NSI	16
101	ABC	Toulon	45	Maths	15
342	RET	Paris	67	SVT	16

Il y a 8 redondances dans cette relation.

3. L’anomalie de modification

Lorsqu’il y a une redondance des données, une modification sur un enregistrement peut engendrer la modification d’autres enregistrements qui comportent des données en commun. On parle alors d’anomalie de modification.

Pour éviter une anomalie de modification, il faut rechercher colonne par colonne les cellules identiques dans le schéma d’une relation.

Exemple
On étudie le schéma de la relation CLIENTS.

CLIENTS
id	nom	ville	num_livre	cours	note
101	ABC	Toulon	2345	NSI	15
234	DEF	Paris	2345	NSI	16
101	ABC	Toulon	45	Maths	15
342	RET	Paris	67	SVT	16

On souhaite modifier le premier enregistrement (première ligne), en changeant la ville associée à ABC.

Cela va nécessiter la modification du troisième enregistrement. Du coup on multiplie les actions, les risques d’erreurs et on risque aussi d’en oublier, notamment si les relations comportent plusieurs dizaines de milliers d’enregistrements.

4. L’anomalie de suppression

Lorsque des informations dépendent de l’existence d’autres informations, on ne peut pas supprimer ces informations sans perdre définitivement d’autres informations. On parle d’anomalie de suppression.

Pour éviter une anomalie de suppression, il faut réfléchir à ce qu’entraine la suppression d’un enregistrement dans le schéma d’une relation.

Exemple
On étudie le schéma de la relation CLIENTS.

CLIENTS
id	nom	ville	num_livre	cours	note
101	ABC	Toulon	2345	NSI	15
234	DEF	Paris	2345	NSI	16
101	ABC	Toulon	45	Maths	15
342	RET	Paris	67	SVT	16

Si on supprime le dernier enregistrement, on perd le cours de SVT et les informations associées.

CLIENTS
id	nom	ville	num_livre	cours	note
101	ABC	Toulon	2345	NSI	15
234	DEF	Paris	2345	NSI	16
101	ABC	Toulon	45	Maths	15

On a ainsi perdu l’information que le numéro de livre 67, qui correspond à un cours de SVT, avait une note de 16. On ne pourra pas retrouver cette information.

5. L’anomalie d’insertion

Pour insérer un autre enregistrement (une autre ligne), il faut impérativement connaitre les valeurs de l’ensemble des attributs obligatoires de la relation, et il faut que chaque valeur respecte le domaine (type des données) de son attribut, sinon on ne peut ajouter ce nouvel enregistrement. On parle d’anomalie d’insertion.

Pour éviter une anomalie d’insertion, il faut étudier le schéma d’une relation pour identifier les différentes valeurs nécessaires et en particulier le typage de chaque attribut pour utiliser le bon format.

Remarques

Un attribut ne doit pas forcément comporter une valeur. Lors de la création de la relation et de ses attributs, on peut indiquer que certains attributs doivent être remplis obligatoirement en ajoutant NOT NULL.
Attention, l’attribut qui correspond à la clé primaire doit toujours contenir une valeur. Si on considère que toutes les cases doivent être remplies, cela peut compliquer l’ajout d’un nouvel enregistrement.

Exemple
On considère le schéma de la relation CLIENTS, où on considère que toutes les cases doivent être remplies.

CLIENTS
id	nom	ville	num_livre	cours	note
101	ABC	Toulon	2345	NSI	15
234	DEF	Paris	2345	NSI	16
101	ABC	Toulon	45	Maths	15
342	RET	Paris	67	SVT	16

Chaque enregistrement correspond à un client, avec ses différents attributs. Pour insérer un autre client, il faut obligatoirement connaitre l’id, le nom, la ville, le num_livre, le cours et la note de ce client.