CodeGym /Cours /SQL SELF /Vérification de la validité des données importées

Vérification de la validité des données importées

SQL SELF
Niveau 24 , Leçon 2
Disponible

Importer des données depuis l'extérieur, c'est un peu comme inviter des potes à un hackathon : tu veux être sûr que tout le monde arrive avec le bon mindset — ou, ici, dans le bon format. Même une petite erreur dans le fichier importé peut te faire perdre des heures en debug, donner des résultats bizarres dans tes requêtes, ou carrément pourrir les données de ta table.

Parfois, tu peux te retrouver avec des lignes vides, des espaces en trop, des doublons ou, genre, du texte là où tu t'attendais à un chiffre. Et si jamais l'encodage n'est pas bon, la table peut juste refuser d'avaler le fichier.

Pour éviter ça, c'est super important d'apprendre à checker la validité des données — avant même de les charger, ou juste après. On va voir comment faire ça ensemble.

Vérification de la structure des données

  1. Comparer la structure de la table avec les données importées

La toute première étape, c'est de vérifier que les données sont bien importées selon la structure de ta table. Par exemple, tu as créé une table students pour stocker les infos sur les étudiants :

CREATE TABLE students (
    student_id SERIAL PRIMARY KEY,
    first_name VARCHAR(50) NOT NULL,
    last_name VARCHAR(50) NOT NULL,
    birth_date DATE,
    email VARCHAR(100) UNIQUE
);

Si tu as importé des données dans cette table, commence par jeter un œil à ce qu'il y a dedans :

SELECT * FROM students;

Les lignes retournées vont te montrer tout ce qu'il y a dans la table. Si la structure des données dans ton fichier CSV ne colle pas à la structure de la table, tu verras des erreurs dès l'import. Mais même si tu n'as pas d'erreur, ça veut pas dire que tout est nickel.

  1. Vérification des types de données

Utilise les fonctions PostgreSQL pour checker le contenu des colonnes. Par exemple :

Vérification des valeurs vides (NULL) :

Si ta table a des champs obligatoires NOT NULL, faut s'assurer qu'ils sont bien remplis. Genre :

SELECT * FROM students WHERE first_name IS NULL OR last_name IS NULL;

Vérification des formats de données :

Parfois, les données arrivent en tant que chaînes alors qu'elles devraient être des dates ou des nombres. Pour checker ça, utilise les fonctions PostgreSQL adaptées, genre :

SELECT * FROM students WHERE birth_date::DATE IS NULL;

Cette requête va te montrer les lignes où le champ birth_date ne peut pas être converti en DATE.

Recherche d'erreurs

  1. Recherche de doublons

Les doublons, c'est un des problèmes les plus courants. Imaginons que tes données doivent être uniques par adresse email (email). Pour checker les doublons, utilise cette requête :

SELECT email, COUNT(*)
FROM students
GROUP BY email
HAVING COUNT(*) > 1;

Cette requête va te montrer tous les email qui se répètent, avec le nombre d'occurrences. Si ta colonne email est en UNIQUE, importer ce genre de données va planter.

  1. Vérification des données incorrectes

Si tu t'attends à ce que le champ birth_date contienne seulement des dates de naissance, faut vérifier que toutes les valeurs sont dans une plage correcte. Par exemple :

SELECT * FROM students
WHERE birth_date < '1900-01-01' OR birth_date > CURRENT_DATE;

Cette requête va te sortir les lignes où la date de naissance est vraiment chelou.

Gérer les données incorrectes

Une fois que t'as trouvé les soucis, faut les corriger. Voyons comment faire ça.

  1. Suppression des données incorrectes

Si tu découvres des lignes avec des prénoms vides, tu peux les supprimer :

DELETE FROM students
WHERE first_name IS NULL OR last_name IS NULL;

Mais fais gaffe avant de supprimer ! Ces données peuvent être importantes, donc parfois il vaut mieux les mettre à jour que les virer.

  1. Mise à jour des données

Si tu trouves des lignes avec des infos manquantes, tu peux les compléter à partir d'autres sources ou faire une supposition. Exemple :

UPDATE students
SET email = 'unknown@example.com'
WHERE email IS NULL;

Visualisation des données pour l'analyse

  1. Utilisation des fonctions d'agrégation

Parfois, pour checker les données, c'est utile de faire des agrégats. Par exemple, pour savoir combien d'étudiants sont nés chaque année, fais :

SELECT EXTRACT(YEAR FROM birth_date) AS year, COUNT(*)
FROM students
GROUP BY year
ORDER BY year;

Cette requête va te montrer la répartition par année et peut te signaler des anomalies (genre une grosse vague d'étudiants la même année).

  1. Vérification des données avec les contraintes

Assure-toi que les données respectent bien les contraintes définies dans la table, par exemple comme ça :

Vérification de l'unicité :

SELECT DISTINCT email
FROM students;

Si le nombre de valeurs uniques est inférieur au nombre total de lignes, t'as des doublons.

Vérification des plages de valeurs :

SELECT * FROM students
WHERE LENGTH(first_name) > 50 OR LENGTH(last_name) > 50;

Ça t'aide à vérifier que les prénoms et noms ne dépassent pas la limite de 50 caractères.

Que faire si tout est cassé ?

Parfois, les données sont tellement pourries qu'il vaut mieux tout réimporter.

  1. Vire toutes les lignes de la table :

    TRUNCATE TABLE students;
    
  2. Corrige le fichier CSV d'origine avec Python, Excel ou n'importe quel autre outil.

  3. Recharge les données avec la commande COPY.

Application pratique

Les skills de validation de données te serviront à chaque fois que tu bosses avec des sources externes. En entretien, par exemple, on peut te demander d'écrire une requête SQL pour checker la qualité des données entrantes — c'est super classique. Dans les vrais projets, c'est pas plus simple : les données du client ou d'un autre service arrivent presque toujours avec des bugs, et c'est toi qui vas les repérer en premier et tout corriger avant que ça parte en bug en prod.

Checker régulièrement les données, ça aide à garder la base clean — et c'est pas juste pour faire joli, ça fait vraiment gagner du temps, des nerfs et de l'énergie à toute l'équipe. Donc si tu sais checker vite fait si les données sont clean, t'es déjà à un pas du titre de boss PostgreSQL.

Commentaires
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION