Nie SQL, a modelowanie danych - luka, o której nikt nie mówi juniorom

"Z jakiego kraju jest dostawca produktu, który najczęściej kupują klienci z Krakowa?" Jedno zdanie od szefa sprzedaży. Junior po kursie SQL siada do bazy i odkrywa, że to pytanie dotyka pięciu tabel naraz: klientów, zamówień, pozycji zamówień, produktów i dostawców. Składnię zna. Nie wie tylko, którędy te tabele się łączą. I to właśnie ta niewiedza, a nie brak SELECT-ów, zatrzymuje go na godzinę przed pustym edytorem.

Ten problem znam z naszej społeczności - także od praktyków. Analityk z kilkuletnim stażem przyznał wprost: składnia SQL okazała się prosta, schody zaczęły się przy projektowaniu struktury danych. Jak to jest poukładane, dlaczego tak, i co z czym wolno połączyć. O tej luce prawie nikt nie mówi juniorom, bo kursy i rekrutacje sprawdzają składnię. A praca sprawdza rozumienie modelu.

Dlaczego składnia SQL to za mało

Większość nauki SQL wygląda tak: dostajesz jedną tabelę i uczysz się na niej kolejnych poleceń. SELECT, WHERE, ORDER BY, GROUP BY. Wszystko działa, quizy zaliczone, pewność siebie rośnie.

Problem w tym, że prawdziwe pytania biznesowe bardzo rzadko mieszczą się w jednej tabeli. Dane o kliencie mieszkają gdzie indziej niż jego zamówienia, a zamówienia gdzie indziej niż produkty. Raport sprzedaży, analiza kompletności danych, definicja metryki "aktywny klient" - każde z tych zadań wymaga przejścia przez kilka tabel po ścieżce, którą trzeba najpierw zobaczyć.

SQL to język, którym pytasz. Model danych to teren, o który pytasz. Znajomość języka bez mapy terenu daje Ci dokładnie tyle, ile turyście znajomość zwrotu "jak dojść do..." bez wiedzy, dokąd chce dojść. Bez mapy kolejne polecenia SQL to wkuwanie składni na pamięć. Z mapą wszystko zaczyna się składać: widzisz pytanie biznesowe, widzisz ścieżkę przez tabele, a zapytanie jest już tylko zapisem tej ścieżki.

Dobra wiadomość: mapy da się nauczyć szybciej niż składni. Trzeba tylko wiedzieć, na co patrzeć.

Cztery rzeczy, które musisz widzieć w każdej bazie

Model relacyjny stoi na kilku konstrukcjach, które powtarzają się w każdym systemie: sklepie internetowym, CRM-ie, systemie rezerwacji, aplikacji bankowej. Pokażę je na przykładzie bazy sklepu, na której uczymy SQL na platformie.

Klucz główny i klucz obcy. Klucz główny (primary key, PK) to kolumna, która jednoznacznie identyfikuje wiersz - najczęściej po prostu id. Klucz obcy (foreign key, FK) to kolumna, która wskazuje na klucz główny innej tabeli, i w porządnie nazwanym schemacie rozpoznasz go po przyrostku _id: customer_id, supplier_id, category_id. Najważniejsza rzecz, która myli początkujących: klucz obcy trzyma liczbę, nie tekst. W tabeli orders zobaczysz customer_id równe 7, a nie nazwisko klienta. Baza celowo nie powiela danych klienta przy każdym zamówieniu - gdy klient zmieni nazwisko albo miasto, poprawia się jeden wiersz w customers, a wszystkie jego zamówienia automatycznie "widzą" nową wartość.

Relacja jeden-do-wielu. Jeden klient może mieć wiele zamówień, ale każde zamówienie należy dokładnie do jednego klienta. To najczęstszy wzorzec w bazach danych i spotkasz go wszędzie: jeden dostawca - wiele produktów, jedna kategoria - wiele produktów, jedno zamówienie - wiele pozycji.

Tabela łącząca. Jedno zamówienie ma wiele produktów, ale jeden produkt występuje też w wielu zamówieniach. Żeby zapisać taką relację wiele-do-wielu, potrzebna jest osobna tabela z dwoma kluczami obcymi: order_items z kolumnami order_id i product_id. Pozycja musi wiedzieć i w którym koszyku leży, i co w niej jest. Jeśli w obcej bazie widzisz tabelę z dwoma FK i niewielką liczbą własnych kolumn, to prawie na pewno właśnie to.

Tabela wskazująca sama na siebie. W tabeli pracowników kolumna manager_id wskazuje na... id w tej samej tabeli. Bo szef pracownika też jest pracownikiem, a manager_id równe NULL oznacza osobę na szczycie hierarchii. Brzmi egzotycznie, ale to zwykła strzałka wracająca do własnej tabeli - i kiedyś spotka Cię w prawdziwym systemie.

Te cztery konstrukcje to prawie wszystko, co zobaczysz na typowym schemacie. Reszta to ich kombinacje.

Ćwiczenie, które analityk robi przed napisaniem zapytania

ERD (Entity-Relationship Diagram) to obrazek: prostokąty to tabele, linie to klucze obce. Nie musisz umieć go rysować według notacji, żeby zacząć z niego korzystać. Musisz umieć go odczytać - czyli mając pytanie biznesowe, wskazać, którędy tabele się łączą.

Konkretne ćwiczenie. Pytanie: ktoś kupił mysz bezprzewodową, mamy tę pozycję w order_items. Do jakiego miasta trafiła? Przejdźmy to krok po kroku:

1. Zaczynamy w order_items. Ta tabela ma dwa klucze obce: order_id i product_id.
2. product_id prowadzi do products - mówi nam, co kupiono. Mysz. Ale nie mówi, kto kupił. Ślepa uliczka dla naszego pytania.
3. Idziemy drugą strzałką: order_id prowadzi do orders. Teraz wiemy, do którego zamówienia należy ta pozycja.
4. Zamówienie wie, kto je złożył: customer_id prowadzi do customers. A tam jest kolumna city. Mamy miasto.

Dwie strzałki: order_items przez orders do customers. Zanim napiszesz jakikolwiek JOIN, wskaż tę trasę palcem na schemacie. Dosłownie palcem - tak robię do dziś przy obcych bazach.

I tu jest puenta, dla której to ćwiczenie ma sens: trasa, którą właśnie przeszliśmy, to dokładnie ta sama trasa, którą później zapiszesz jako JOIN w SQL. Kto rozumie klucze obce, ten rozumie JOIN-a. Reszta to składnia. Dlatego ludzie, którzy piszą JOIN-y "na czuja" i dziwią się wynikom, nie mają problemu ze składnią - mają problem z mapą.

Model danych to pytania, które zadajesz zanim system powstanie

Do tej pory mówiliśmy o czytaniu istniejących baz. Ale rozumienie modelu danych działa też w drugą stronę - i tu robi się z tego kompetencja analityka biznesowego, a nie sama umiejętność pisania zapytań.

Kardynalności relacji to w gruncie rzeczy pytania biznesowe. Czy jedno zamówienie może mieć wiele adresów dostawy? Czy produkt może należeć do kilku kategorii naraz? Czy pracownik może mieć więcej niż jednego przełożonego? Na każde z tych pytań ktoś musi odpowiedzieć przed napisaniem kodu, bo każda odpowiedź daje inną strukturę danych. Jeśli nikt nie zapyta, deweloper przyjmie założenie sam - i dowiesz się o nim na produkcji.

Drugi przykład, mój ulubiony, bo wygląda jak błąd, a jest decyzją. W tabeli order_items jest kolumna price, mimo że cena produktu siedzi już w products. Duplikacja? Nie - cena w pozycji zamówienia to cena z chwili zakupu. Cennik się zmienia, a stare zamówienia muszą pamiętać, po ile faktycznie sprzedano. Jeśli tego nie ustalisz na etapie analizy, system przeliczy historyczne zamówienia po nowych cenach i księgowość przyjdzie do Ciebie z pretensjami.

Trzeci przykład: puste pola i statusy. W tabeli zamówień kolumna shipped_at bywa pusta - i ten NULL coś znaczy: zamówienie jeszcze nie wyjechało z magazynu. Obok siedzi kolumna status z wartościami w rodzaju "processing", "shipped", "delivered", "cancelled". Za każdą taką kolumną kryje się cykl życia obiektu i seria pytań do biznesu: jakie stany przechodzi zamówienie, co wolno zrobić w każdym z nich, czy anulowane zamówienie może mieć datę wysyłki. Analityk, który patrzy na model danych, widzi te pytania od razu. Analityk, który zna tylko składnię, zobaczy je dopiero w zgłoszeniach od użytkowników.

Takie decyzje są biznesowe, nie techniczne. I właśnie dlatego model danych należy do warsztatu analityka, a nie wyłącznie do zespołu deweloperskiego.

Gdzie ta luka wychodzi na jaw

Trzy miejsca, w których braki w rozumieniu modelu danych bolą najbardziej.

Na rozmowie rekrutacyjnej. Pytania o różnicę między INNER a LEFT JOIN albo o to, "co zwróci to zapytanie", wyglądają jak test składni, ale naprawdę sprawdzają mapę: czy wiesz, co się dzieje z wierszami, które nie mają pary po drugiej stronie złączenia. Kandydat bez mapy recytuje definicję i wykłada się na pierwszym przykładzie. Więcej takich pytań rozbieram w tekście o pytaniach rekrutacyjnych dla analityka biznesowego.

W pierwszym tygodniu nowej pracy. Dostajesz dostęp do bazy, której nie znasz, i długą listę tabel o nazwach, które nic Ci nie mówią. Umiejętność czytania schematu skraca ten etap z tygodni do dni: zamiast prosić o gotowe eksporty, sam znajdujesz ścieżki do odpowiedzi.

Na spotkaniach z zespołem deweloperskim. Gdy deweloper mówi "to jest relacja wiele-do-wielu, potrzebujemy tabeli pośredniczącej", analityk bez mapy kiwa głową i traci wątek. Analityk z mapą zadaje w tym momencie pytanie o kardynalność, które oszczędza sprintowi przeróbek.

Jak nadrobić lukę w dobrej kolejności

Większość ludzi próbuje w kolejności odwrotnej: najpierw kurs składni, potem JOIN-y na pamięć, a projektowanie "kiedyś". Sensowna kolejność wygląda tak:

1. Naucz się czytać ERD, zanim zaczniesz cokolwiek rysować. Weź schemat dowolnego systemu i przejdź go tabelami: gdzie są klucze obce, dokąd prowadzą strzałki, które relacje są jeden-do-wielu, gdzie siedzi tabela łącząca. Lista relacji w głowie to cały ERD, jakiego potrzebujesz na start.
2. Przećwicz ścieżki po kluczach obcych ręcznie. Dwa zapytania zamiast jednego JOIN-a: najpierw odczytaj wartość FK z jednej tabeli, potem znajdź ją w drugiej. To wolne i niewygodne - i o to chodzi, bo buduje odruch, którego JOIN jest tylko automatyzacją.
3. Dopiero teraz JOIN-y. Po ćwiczeniu z punktu 2 składnia INNER i LEFT JOIN wygląda podejrzanie prosto, a Ty wiesz, dlaczego wynik ma tyle wierszy, ile ma. Jak potrzebujesz szerszego kontekstu, po co Ci w ogóle ten język, zajrzyj do tekstu o SQL dla analityka biznesowego.
4. Projektowanie i normalizacja na końcu. Encje, atrybuty, notacja Crow's Foot, postacie normalne - to warstwa, którą dokładasz, gdy czytanie schematów masz już w palcach. Mam o tym osobny, praktyczny tekst: ERD i modelowanie danych - poradnik dla analityka.

Realistycznie: punkty 1-3 to tygodnie, nie miesiące. To znacznie mniej nauki niż opanowanie samej składni, a różnica w codziennej pracy jest większa.

Po czym poznasz, że ta luka dotyczy właśnie Ciebie

Szybka autodiagnoza. Jeśli odhaczysz dwa lub więcej punktów, wiesz, co ćwiczyć:

• Przed napisaniem JOIN-a zgadujesz warunek złączenia po podobieństwie nazw kolumn.
• Wyniki JOIN-ów Cię zaskakują: raz za dużo wierszy, raz za mało, i nie wiesz dlaczego.
• Nie umiesz z marszu powiedzieć, czy relacja między dwiema tabelami jest jeden-do-wielu czy wiele-do-wielu.
• Baza z kilkudziesięcioma tabelami budzi w Tobie odruch "poproszę IT o eksport".
• Widzisz kolumnę z ceną w dwóch tabelach i uznajesz to za bałagan, nie za decyzję.
• Rysujesz "model danych" jako listę ekranów i pól formularza, nie encji i relacji.

Żaden z tych punktów nie świadczy o braku talentu. Świadczą o tym, że ktoś nauczył Cię języka, ale nie pokazał mapy.

Najszybciej zasypiesz tę lukę na żywej bazie, nie na slajdach. Kurs SQL na platformie Analify zaczyna się dokładnie od tego: model relacyjny, klucze, czytanie ERD sklepu z ośmioma tabelami - a pierwszą lekcję każdego kursu przejdziesz na darmowym koncie. Załóż darmowe konto i zacznij od schematu, nie od składni.

Najczęstsze pytania

Czy analityk biznesowy musi umieć projektować bazy danych?

Projektować nie musi, czytać musi. Wystarczy umiejętność wskazania na schemacie trasy od pytania biznesowego do odpowiedzi i nazwania kardynalności każdej relacji po drodze. Projektowanie i normalizacja przydają się dopiero wtedy, gdy współtworzysz model nowego systemu, a nie korzystasz z istniejącego.

Czym model danych różni się od diagramu ERD?

Model danych to decyzje o tym, jakie byty istnieją, jak się łączą i co wolno z nimi zrobić. ERD to obrazek, który te decyzje pokazuje: prostokąty jako tabele, linie jako powiązania. Można mieć poprawny diagram i zły model, jeśli nikt nie zapytał biznesu o kardynalności i o cykl życia obiektu.

Od czego zacząć: od SQL czy od modelu danych?

Kolejność, która działa, ma trzy kroki: najpierw czytanie schematu i wypisanie relacji, potem sprawdzanie tras prostymi odczytami pojedynczych tabel, a złączenia dopiero na końcu. Nauka składni przed mapą kończy się zapytaniami pisanymi na wyczucie i wynikami, których nie umiesz wyjaśnić. Odwrotna kolejność zajmuje tygodnie, nie miesiące.

Po czym rozpoznać klucz obcy w nieznanej bazie?

Najpewniejszym źródłem są więzy zdefiniowane w bazie: ich lista mówi wprost, która kolumna wskazuje na którą tabelę. Gdy więzów nie ma, zostają poszlaki - nazwa z przyrostkiem w rodzaju customer_id, zgodność typu z kluczem głównym innej tabeli i to, czy wartości faktycznie się w niej mieszczą. Nazewnictwo bywa mylące, więc poszlakę potwierdź na danych albo u osoby, która ten schemat utrzymuje.