Sprawdzanie poprawności załadowanych danych

Ładowanie danych z zewnętrznych źródeł to trochę jak zapraszanie ziomków na akcję. Chcesz mieć pewność, że każdy przyszedł z odpowiednim nastawieniem — albo, w naszym przypadku, w odpowiednim formacie. Nawet drobny błąd w pliku do importu może skończyć się godzinami debugowania, złymi wynikami zapytań albo po prostu rozwaleniem danych w tabeli.

Czasem do pliku mogą się wkręcić puste linie, zbędne spacje, duplikaty albo, powiedzmy, tekst tam, gdzie powinna być liczba. A jeśli jeszcze kodowanie nie podejdzie, tabela może po prostu nie przyjąć pliku.

Żeby tego uniknąć, ważne jest, żeby nauczyć się sprawdzać dane pod kątem poprawności — jeszcze przed załadowaniem albo od razu po nim. Zaraz ogarniemy, jak to zrobić.

Sprawdzanie struktury danych

1. Porównanie struktury tabeli z załadowanymi danymi

Pierwszy krok — upewnij się, że dane są załadowane zgodnie ze strukturą twojej tabeli. Na przykład, stworzyłeś tabelę students do przechowywania info o studentach:

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
);

Jeśli wrzuciłeś dane do tej tabeli, na początek po prostu zobaczmy, co tam siedzi:

SELECT * FROM students;

Zwrócone wiersze pokażą ci wszystkie rekordy w tabeli. Jeśli struktura danych w pliku CSV nie zgadza się ze strukturą tabeli, zobaczysz błędy już na etapie ładowania. Ale nawet jeśli błędów nie było, to nie znaczy, że dane są idealne.

2. Sprawdzanie typów danych

Użyj funkcji PostgreSQL, żeby sprawdzić zawartość kolumn. Na przykład:

Sprawdzanie pustych wartości (NULL):

Jeśli w twojej tabeli są pola obowiązkowe NOT NULL, musisz się upewnić, że faktycznie są wypełnione. Przykład:

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

Sprawdzanie formatów danych:

Czasem dane mogą być załadowane jako stringi, chociaż powinny być datami albo liczbami. Żeby to sprawdzić, użyj odpowiednich funkcji PostgreSQL, na przykład:

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

To zapytanie pokaże wiersze, gdzie pole birth_date nie daje się przekonwertować na typ DATE.

Sprawdzanie błędów

1. Szukaj duplikatów

Duplikaty to jeden z najczęstszych problemów. Załóżmy, że twoje dane powinny być unikalne po adresie e-mail (email). Żeby sprawdzić, czy są duplikaty, użyj takiego zapytania:

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

To zapytanie pokaże ci wszystkie powtarzające się email i ile razy się pojawiają. Jeśli twoja kolumna email jest ustawiona jako UNIQUE, to ładowanie takich danych wywali błąd.

2. Sprawdzanie niepoprawnych danych

Jeśli oczekujesz, że pole birth_date zawiera tylko daty urodzenia, musisz się upewnić, że wszystkie wartości są w dozwolonym zakresie. Przykład:

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

To zapytanie pokaże wiersze, gdzie data urodzenia jest totalnie z kosmosu.

Praca z niepoprawnymi danymi

Jak już znajdziesz problemy, trzeba je ogarnąć. Zobaczmy, jak to zrobić.

1. Usuwanie niepoprawnych danych

Jeśli okaże się, że w tabeli są wiersze z pustymi imionami, możesz je wywalić:

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

Ale z usuwaniem trzeba uważać! Może te dane są ważne, więc czasem lepiej je zaktualizować niż kasować.

2. Aktualizacja danych

Jeśli znajdziesz wiersze z brakującymi danymi, możesz je uzupełnić na podstawie innych źródeł albo zgadywać. Przykład:

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

Wizualizacja danych do analizy

1. Używanie funkcji agregujących

Czasem do sprawdzania danych przydaje się policzyć agregaty. Na przykład, żeby sprawdzić, ilu studentów urodziło się w każdym roku, zrób tak:

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

To zapytanie pokaże ci rozkład po latach i może wskazać anomalie (np. jeśli w jednym roku pojawiła się podejrzanie duża grupa studentów).

2. Sprawdzanie danych przez ograniczenia

Upewnij się, że dane spełniają ograniczenia ustawione w tabeli, na przykład tak:

Sprawdzanie unikalności:

SELECT DISTINCT email
FROM students;

Jeśli liczba unikalnych wartości jest mniejsza niż liczba wszystkich wierszy — masz duplikaty.

Sprawdzanie zakresów wartości:

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

To pomoże upewnić się, że imiona studentów nie przekraczają limitu 50 znaków.

Co zrobić, jeśli wszystko jest źle?

Czasem dane są tak słabe, że łatwiej je załadować od nowa.

1. Wywal wszystkie wiersze z tabeli:

   TRUNCATE TABLE students;
   

2. Popraw oryginalny plik CSV za pomocą Python, Excel albo innego narzędzia.

3. Załaduj dane ponownie komendą COPY.

Zastosowanie w praktyce

Umiejętność walidacji danych przyda ci się za każdym razem, gdy pracujesz z zewnętrznymi źródłami. Na rozmowie kwalifikacyjnej, na przykład, mogą cię poprosić o napisanie SQL-a do sprawdzenia jakości danych wejściowych — to normalka. W realnych projektach nie jest łatwiej: dane od klienta albo innego działu prawie zawsze przychodzą z błędami i to właśnie ty będziesz tym, kto je pierwszy zauważy i ogarnie zanim pojawią się bugi.

Regularne sprawdzanie danych pomaga trzymać bazę w porządku — i to nie jest tylko formalność, ale realna oszczędność czasu, nerwów i wysiłku całej ekipy. Więc jeśli umiesz szybko ogarnąć, czy dane są OK, — jesteś o krok bliżej do tytułu mistrza PostgreSQL.