Moduł 1 · Wprowadzenie do baz danych i PostgreSQL
Czym są relacyjne bazy danych
Po tej lekcji będziesz wiedzieć, czym jest relacyjna baza danych, i rozpoznasz w niej tabele, wiersze, kolumny oraz klucze, które łączą tabele w jedną całość. Poznasz też bazę ćwiczeniową, na której pracujesz przez cały kurs.
Tabela, wiersz i kolumna
Relacyjna baza danych przechowuje dane w tabelach. Dokumentacja PostgreSQL opisuje to tak: tabela to nazwany zbiór wierszy, a każdy wiersz ma ten sam zestaw nazwanych kolumn. Każda kolumna ma określony typ danych — liczba, tekst, data. Słowo „relacja” pochodzi z matematyki i oznacza właśnie tabelę; model relacyjny opisał Edgar F. Codd w 1970 r. w artykule „A Relational Model of Data for Large Shared Data Banks”.
Przez cały kurs pracujesz na danych fikcyjnej firmy Kreska sp. z o.o. — hurtowni artykułów biurowych z Poznania, która sprzedaje papier, tonery, segregatory i meble biurowe firmom oraz klientom indywidualnym. Tak wygląda fragment tabeli klienci:
| id | nazwa | typ | nip | miasto |
|---|---|---|---|---|
| 1 | Biuro Rachunkowe Saldo | firma | 0002605983 | Kraków |
| 2 | Kancelaria Radców Prawnych Lex-Nowak | firma | 0005846724 | Katowice |
| 41 | Anna Kowalska | osoba | (pusto) | Gdańsk |
Jeden wiersz to jeden klient. Kolumna nip u osoby prywatnej jest pusta — w SQL taki brak wartości nazywa się NULL i poświęcimy mu osobną lekcję w module 2. NIP-y w bazie są zmyślone: zaczynają się od 000, a takiego prefiksu nie ma żaden urząd skarbowy.
Ważna różnica wobec arkusza Excela: wiersze w tabeli nie mają ustalonej kolejności. Dokumentacja PostgreSQL wprost zaznacza, że SQL nie gwarantuje porządku wierszy, dopóki sam go nie zażądasz (ORDER BY, moduł 2). Druga różnica: w kolumnie nie wpiszesz czegokolwiek. Jeśli kolumna ma typ date, baza odrzuci tekst „wczoraj”.
Klucz główny i klucz obcy
Każdy wiersz musi dać się jednoznacznie wskazać. Służy do tego klucz główny (PRIMARY KEY) — kolumna albo zestaw kolumn, których wartości są unikalne i nigdy nie są puste. W bazie Kreski kluczem głównym prawie wszędzie jest kolumna id.
Tabele łączy klucz obcy (FOREIGN KEY, w SQL zapisywany jako REFERENCES). Kolumna klient_id w tabeli zamowienia zawiera numer klienta z tabeli klienci:
| id | numer | klient_id | data_zamowienia | status |
|---|---|---|---|---|
| 2 | ZAM/2025/0002 | 30 | 2025-01-09 08:53:41 | dostarczone |
| 4 | ZAM/2025/0004 | 2 | 2025-01-15 07:23:16 | dostarczone |
Zamówienie ZAM/2025/0004 złożyła kancelaria z Katowic (klient o id = 2). Dane klienta zapisujesz raz, a zamówienia tylko na niego wskazują. Gdy kancelaria zmieni adres e-mail, poprawiasz jeden wiersz, a nie kilkadziesiąt zamówień.
Klucz obcy pilnuje integralności referencyjnej: baza nie przyjmie zamówienia dla klienta, którego nie ma. Tak reaguje PostgreSQL na próbę dodania zamówienia dla klienta nr 999:
-- Ten kod kończy się błędem: klienta 999 nie ma w tabeli klienci
INSERT INTO zamowienia (numer, klient_id, data_zamowienia, status)
VALUES ('ZAM/2026/9999', 999, '2026-10-01 10:00', 'nowe');ERROR: insert or update on table "zamowienia" violates foreign key constraint "zamowienia_klient_id_fkey"
DETAIL: Key (klient_id)=(999) is not present in table "klienci".Klucz główny może się też składać z kilku kolumn. W tabeli pozycje_zamowien jest nim para (zamowienie_id, nr_pozycji): zamówienie nr 2 ma pozycje 1, 2 i 3, a zamówienie nr 4 też może mieć swoją pozycję nr 1.
Jak zbudowana jest baza hurtowni
Baza ćwiczeniowa ma siedem tabel. Diagram pokazuje, co z czym się łączy — strzałki w Twojej głowie biegną zawsze od klucza obcego do klucza głównego.
Baza ćwiczeniowa kursu, plik hurtownia.sql (firma fikcyjna).
Zwróć uwagę na pozycje_zamowien. Jedno zamówienie ma wiele pozycji, a jeden produkt występuje w wielu zamówieniach. Taką relację „wiele do wielu” zawsze rozbija się na dodatkową tabelę z dwoma kluczami obcymi. Pozycja przechowuje też własną cenę netto i rabat — bo cena w katalogu się zmienia (papier podrożał 1 marca 2026 r.), a zamówienie musi pamiętać cenę z dnia sprzedaży.
SQL i systemy baz danych
SQL (Structured Query Language) to język, którym rozmawiasz z bazą. Jest deklaratywny: opisujesz, jaki wynik chcesz dostać („klienci z Poznania, posortowani po nazwie”), a nie, jak go szukać. Sposób wykonania wybiera sama baza — w module 7 zajrzysz do jej planu.
Języka SQL używają systemy PostgreSQL, MySQL, MariaDB, Microsoft SQL Server, Oracle Database i SQLite. Podstawy — SELECT, JOIN, GROUP BY, INSERT, UPDATE — wyglądają w nich tak samo, różnią się szczegóły, np. funkcje dat czy sposób numerowania wierszy. Ten kurs używa PostgreSQL 18: jest bezpłatny (licencja PostgreSQL), działa na Windowsie, macOS i Linuksie i trzyma się standardu SQL. Gdy jakaś składnia jest typowa tylko dla PostgreSQL, zaznaczę to w lekcji.
Relacyjna baza sprawdza się tam, gdzie dane mają stałą strukturę i muszą się zgadzać co do grosza: zamówienia, faktury, magazyn, kadry. Słabiej pasuje do danych bez stałej struktury, np. dokumentów o zupełnie różnych polach — choć PostgreSQL ma też typ jsonb do takich zastosowań.
Najważniejsze w 3 punktach
- Relacyjna baza to tabele z kolumnami o ustalonych typach; wiersze nie mają kolejności, dopóki jej nie zażądasz.
- Klucz główny jednoznacznie wskazuje wiersz, klucz obcy łączy tabele i nie pozwala wskazać nieistniejącego wiersza.
- Relację „wiele do wielu” (zamówienia–produkty) rozbija się na tabelę pośrednią, tu
pozycje_zamowien.
Źródła
- PostgreSQL 18 Documentation, „2.2. Concepts” — postgresql.org/docs/18/tutorial-concepts.html
- PostgreSQL 18 Documentation, „5.5. Constraints” (klucz główny, klucz obcy) — postgresql.org/docs/18/ddl-constraints.html
- E. F. Codd, „A Relational Model of Data for Large Shared Data Banks”, Communications of the ACM, 1970 — doi.org/10.1145/362384.362685
- PostgreSQL, „License” — postgresql.org/about/licence