Projektowanie baz danych

• Brak duplikatów wierszy. Każdy wiersz musi być odróżnialny od pozostałych — gwarantuje to klucz podstawowy.
• Kolejność nie ma znaczenia. Ani kolejność wierszy, ani kolumn nie niesie informacji. Jeśli potrzebujesz „pierwszego" rekordu, musisz mieć kolumnę, po której da się posortować.
• Wartość w komórce jest atomowa. Jedna komórka = jedna wartość. To już jest warunek pierwszej postaci normalnej.

CREATE TABLE obsada (
  id_filmu  INT NOT NULL,
  id_aktora INT NOT NULL,
  rola      VARCHAR(80),
  PRIMARY KEY (id_filmu, id_aktora),
  FOREIGN KEY (id_filmu)  REFERENCES filmy(id_filmu),
  FOREIGN KEY (id_aktora) REFERENCES aktorzy(id_aktora)
) ENGINE = InnoDB;

  klienci                          rezyserzy
---------------------            ---------------------
PK id_klienta                    PK id_rezysera
   imie                             nazwisko
   nazwisko                         kraj
   telefon                                |
   email                                  | 1
      |                                   |
      | 1                                 | N
      |                             ---------------------
      | N                           filmy
---------------------               ---------------------
wypozyczenia                        PK id_filmu
---------------------                  tytul
PK id_wypozyczenia                     rok_produkcji
FK id_klienta                          cena_doba
   data_wypozyczenia                FK id_rezysera
   data_zwrotu                            |
   status                                 | 1
      |                                   |
      | 1                                 |
      |      pozycje_wypozyczenia         |
      |      -------------------------    |
      +-- N  PK,FK id_wypozyczenia        |
             PK,FK id_filmu          N ---+
                   liczba_dni

Zestawienie relacji:
  klienci      1 : N  wypozyczenia    -- FK id_klienta w wypozyczeniach
  rezyserzy    1 : N  filmy           -- FK id_rezysera w filmach
  wypozyczenia N : M  filmy           -- realizowane przez tabele laczaca
                                      -- pozycje_wypozyczenia: dwie relacje
                                      -- 1:N i klucz podstawowy zlozony

1. Analiza wymagań — wypisz z treści zadania rzeczowniki (kandydaci na encje) i czasowniki (kandydaci na związki).
2. Model konceptualny — diagram ER: encje, atrybuty, związki i ich liczebność. Bez typów danych.
3. Model logiczny — zamiana encji na tabele, związków na klucze obce, rozbicie N:M tabelą łączącą, normalizacja do 3NF.
4. Model fizyczny — dobór typów kolumn, więzów, indeksów i silnika (dla kluczy obcych w MySQL musi to być InnoDB, nie MyISAM).
5. Implementacja — polecenia DDL, czyli CREATE DATABASE i CREATE TABLE. Pełną składnię znajdziesz w artykule o języku zapytań SQL.

WYPOZYCZENIA  (postac nieznormalizowana)

nr | klient         | telefon     | data       | wypozyczone filmy
---+----------------+-------------+------------+---------------------------
1 | Anna Nowak     | 601-100-200 | 2026-03-04 | Matrix (Wachowscy);
 |                |             |            | Incepcja (Nolan)
2 | Piotr Kowalski | 602-300-400 | 2026-03-04 | Incepcja (Nolan)
3 | Anna Nowak     | 601-100-200 | 2026-03-09 | Dunkierka (Nolan);
 |                |             |            | Matrix (Wachowscy)

WYPOZYCZENIA_1NF        PK: (nr_wyp, id_filmu)

nr_wyp | id_filmu | tytul     | rezyser   | id_kl | klient         | telefon     | data
-------+----------+-----------+-----------+-------+----------------+-------------+-----------
 1   |    10    | Matrix    | Wachowscy |   5   | Anna Nowak     | 601-100-200 | 2026-03-04
 1   |    11    | Incepcja  | Nolan     |   5   | Anna Nowak     | 601-100-200 | 2026-03-04
 2   |    11    | Incepcja  | Nolan     |   8   | Piotr Kowalski | 602-300-400 | 2026-03-04
 3   |    12    | Dunkierka | Nolan     |   5   | Anna Nowak     | 601-100-200 | 2026-03-09
 3   |    10    | Matrix    | Wachowscy |   5   | Anna Nowak     | 601-100-200 | 2026-03-09

• tytul i rezyser zależą wyłącznie od id_filmu — znając numer filmu, znasz tytuł, bez patrzenia na numer wypożyczenia.
• id_kl, klient, telefon i data zależą wyłącznie od nr_wyp.

FILMY   PK: id_filmu             WYPOZYCZENIA   PK: nr_wyp
-----------------------------    ------------------------------------------------------
id_filmu | tytul     | rezyser   nr_wyp | id_kl | klient         | telefon     | data
 10    | Matrix    | Wachowscy    1   |   5   | Anna Nowak     | 601-100-200 | 2026-03-04
 11    | Incepcja  | Nolan        2   |   8   | Piotr Kowalski | 602-300-400 | 2026-03-04
 12    | Dunkierka | Nolan        3   |   5   | Anna Nowak     | 601-100-200 | 2026-03-09

POZYCJE_WYPOZYCZENIA
PK: (nr_wyp, id_filmu)
FK: nr_wyp   -> WYPOZYCZENIA(nr_wyp)
FK: id_filmu -> FILMY(id_filmu)
-----------------------------
nr_wyp | id_filmu | liczba_dni
 1   |    10    |     3
 1   |    11    |     3
 2   |    11    |     7
 3   |    12    |     2
 3   |    10    |     2

• W tabeli WYPOZYCZENIA zachodzi łańcuch nr_wyp → id_kl → klient, telefon. Nazwisko i telefon nie są cechą wypożyczenia, tylko klienta.
• W tabeli FILMY nazwisko reżysera powtarza się przy każdym jego filmie. Gdybyśmy dołożyli kraj reżysera, powielałby się razem z nazwiskiem — to ten sam mechanizm.

KLIENCI   PK: id_klienta                REZYSERZY   PK: id_rezysera
------------------------------------    ---------------------------------------
id_klienta | imie  | nazwisko | telefon  id_rezysera | nazwisko  | kraj
   5     | Anna  | Nowak    | 601-100-200    1     | Wachowscy | USA
   8     | Piotr | Kowalski | 602-300-400    2     | Nolan     | Wielka Brytania

FILMY   PK: id_filmu, FK: id_rezysera    WYPOZYCZENIA  PK: nr_wyp, FK: id_klienta
-------------------------------------    ---------------------------------------------
id_filmu | tytul     | rok  | id_rez     nr_wyp | id_klienta | data_wyp   | data_zwrotu
 10    | Matrix    | 1999 |   1           1   |     5      | 2026-03-04 | 2026-03-07
 11    | Incepcja  | 2010 |   2           2   |     8      | 2026-03-04 | NULL
 12    | Dunkierka | 2017 |   2           3   |     5      | 2026-03-09 | NULL

POZYCJE_WYPOZYCZENIA   PK: (nr_wyp, id_filmu)   -- bez zmian od kroku 2

• Kiedy ma sens: baza jest czytana wielokrotnie częściej, niż zapisywana (raporty, hurtownie danych, statystyki), a zapytanie wymaga złączenia wielu dużych tabel.
• Przypadek w pełni uzasadniony: na fakturze zapisuje się cenę produktu z dnia sprzedaży. To wygląda na redundancję, ale nią nie jest — cena w cenniku się zmienia, a kwota na wystawionym dokumencie musi zostać taka, jaka była. To po prostu dwa różne fakty.
• Inny typowy przykład: kolumna liczba_wypozyczen w tabeli filmów zamiast liczenia jej za każdym razem funkcją COUNT.
• Cena: wracają anomalie aktualizacji. Nadmiarowe dane trzeba synchronizować — wyzwalaczem albo w kodzie aplikacji. Bez tego licznik zacznie kłamać.
• Zasada na egzamin: najpierw normalizujesz do 3NF, dopiero potem, mając zmierzony problem z wydajnością, rozważasz odstępstwo. Denormalizacja „na wszelki wypadek" to po prostu zły projekt.

• NOT NULL — kolumna nie może pozostać pusta. Pilnuje, żeby wypożyczenie zawsze miało klienta i datę.
• UNIQUE — wartości w kolumnie nie mogą się powtarzać, ale może wystąpić NULL (w MySQL nawet wielokrotnie). To główna różnica wobec klucza podstawowego, obok tego, że więzów UNIQUE może być w tabeli wiele.
• DEFAULT — wartość wpisywana, gdy polecenie INSERT pominie kolumnę, np. status DEFAULT 'aktywne'.
• CHECK — warunek, który musi być spełniony, np. CHECK (cena_doba >= 0). W MySQL jest egzekwowany od wersji 8.0.16; we wcześniejszych składnia była przyjmowana, ale ignorowana.
• AUTO_INCREMENT — automatyczne nadawanie kolejnego numeru. Tylko dla kolumny liczbowej będącej kluczem lub indeksem. Usunięcie rekordu nie zwalnia numeru: po skasowaniu wiersza 5 następny dostanie 6, w numeracji zostanie dziura i jest to zachowanie prawidłowe.
• PRIMARY KEY — połączenie UNIQUE i NOT NULL, jedno na tabelę.
• FOREIGN KEY — więz referencyjny między tabelami. W MySQL wymaga silnika InnoDB oraz zgodnych typów kolumn po obu stronach.

CREATE DATABASE wypozyczalnia
  DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_polish_ci;

USE wypozyczalnia;

CREATE TABLE klienci (
  id_klienta INT AUTO_INCREMENT PRIMARY KEY,
  imie       VARCHAR(30)  NOT NULL,
  nazwisko   VARCHAR(50)  NOT NULL,
  telefon    VARCHAR(15),
  email      VARCHAR(100) UNIQUE,
  data_rej   DATE         NOT NULL
) ENGINE = InnoDB;

CREATE TABLE rezyserzy (
  id_rezysera INT AUTO_INCREMENT PRIMARY KEY,
  nazwisko    VARCHAR(60) NOT NULL,
  kraj        VARCHAR(40)
) ENGINE = InnoDB;

CREATE TABLE filmy (
  id_filmu      INT AUTO_INCREMENT PRIMARY KEY,
  tytul         VARCHAR(120) NOT NULL,
  rok_produkcji SMALLINT,
  cena_doba     DECIMAL(6,2) NOT NULL DEFAULT 5.00,
  opis          TEXT,
  id_rezysera   INT,
  CHECK (cena_doba >= 0),
  FOREIGN KEY (id_rezysera) REFERENCES rezyserzy(id_rezysera)
      ON DELETE SET NULL
      ON UPDATE CASCADE
) ENGINE = InnoDB;

CREATE TABLE wypozyczenia (
  id_wypozyczenia   INT AUTO_INCREMENT PRIMARY KEY,
  id_klienta        INT  NOT NULL,
  data_wypozyczenia DATE NOT NULL,
  data_zwrotu       DATE,
  status ENUM('aktywne','zwrocone','zalegle') NOT NULL DEFAULT 'aktywne',
  FOREIGN KEY (id_klienta) REFERENCES klienci(id_klienta)
      ON DELETE RESTRICT
      ON UPDATE CASCADE
) ENGINE = InnoDB;

CREATE TABLE pozycje_wypozyczenia (
  id_wypozyczenia INT NOT NULL,
  id_filmu        INT NOT NULL,
  liczba_dni      TINYINT UNSIGNED NOT NULL DEFAULT 3,
  PRIMARY KEY (id_wypozyczenia, id_filmu),
  FOREIGN KEY (id_wypozyczenia) REFERENCES wypozyczenia(id_wypozyczenia)
      ON DELETE CASCADE,
  FOREIGN KEY (id_filmu) REFERENCES filmy(id_filmu)
      ON DELETE RESTRICT
) ENGINE = InnoDB;

START TRANSACTION;
  INSERT INTO wypozyczenia (id_klienta, data_wypozyczenia)
  VALUES (5, '2026-03-04');

  INSERT INTO pozycje_wypozyczenia (id_wypozyczenia, id_filmu, liczba_dni)
  VALUES (LAST_INSERT_ID(), 10, 3);
COMMIT;      -- zatwierdza obie zmiany na trwale
-- ROLLBACK; -- wycofalby obie, gdyby druga operacja sie nie powiodla

• A — Atomicity (atomowość): wykonuje się całość albo nic. Nie ma stanu „w połowie".
• C — Consistency (spójność): baza przed transakcją i po niej spełnia wszystkie więzy integralności.
• I — Isolation (izolacja): równolegle wykonywane transakcje nie widzą swoich niezatwierdzonych zmian i nie psują sobie wyników.
• D — Durability (trwałość): po COMMIT dane przetrwają awarię zasilania — są już zapisane na nośniku, a nie tylko w pamięci.