Zla struktura tabel mnozy dane i rodzi anomalie: aktualizujesz adres firmy w jednym wierszu, a w 200 innych zostaje stary. Normalizacja to dyscyplina, ktora usuwa te pulapki JESZCZE przed napisaniem pierwszego zapytania.
Encje, atrybuty, zaleznosci funkcyjne
- **Encja** — rzecz, o ktorej trzymamy dane (Uzytkownik, Zgloszenie, Dzial).
- **Atrybut** — cecha encji (login, data_utworzenia).
- **Zaleznosc funkcyjna X -> Y** — znajac X, znasz jednoznacznie Y (numer_zgloszenia -> tytul).
- **Klucz kandydujacy** — minimalny zestaw atrybutow jednoznacznie identyfikujacy wiersz.
Relacje i kardynalnosc
| Kardynalnosc | Realizacja w schemacie | Przyklad |
|---|---|---|
| 1:1 | FK z UNIQUE po jednej stronie | Uzytkownik -> Profil |
| 1:N | FK po stronie 'wielu' | Dzial -> Uzytkownicy |
| M:N | TABELA LACZACA (junction) z dwoma FK | Uzytkownik <-> Rola |
M:N nie da sie zrobic 'wprost'. Zawsze wstawiasz tabele laczaca (np. `uzytkownik_rola` z parami user_id+rola_id). To najczestszy element, ktory juniorzy pomijaja.
Postacie normalne — po co i jak
- **1NF** — wartosci atomowe, brak grup powtarzalnych. Zaden 'telefon1, telefon2, telefon3' ani lista '111,222,333' w jednej komorce.
- **2NF** (dla kluczy zlozonych) — brak zaleznosci CZESCIOWEJ: atrybut nie moze zalezec od CZESCI klucza. Np. w (zamowienie_id, produkt_id) nazwa_produktu zalezy tylko od produktu -> wynies.
- **3NF** — brak zaleznosci PRZECHODNIEJ: atrybut niekluczowy nie zalezy od innego niekluczowego. `kod_pocztowy -> miasto` w tabeli usera => wynies do slownika.
- **BCNF** — kazdy determinant jest kluczem kandydujacym (ostrzejsza wersja 3NF dla nietypowych nakladajacych sie kluczy).
Skrot mnemoniczny 3NF: kazdy atrybut zalezy od klucza, calego klucza i niczego oprocz klucza ('the key, the whole key, and nothing but the key').
Anomalie, ktore znika po normalizacji
- **Anomalia aktualizacji** — zmiana jednej wartosci wymaga edycji wielu wierszy.
- **Anomalia wstawiania** — nie da sie dodac encji bez sztucznych danych (np. dzial bez usera).
- **Anomalia usuwania** — usuniecie wiersza gubi informacje o czyms innym.
Denormalizacja — swiadomy wyjatek
W hurtowniach danych i tam, gdzie odczyty dominuja nad zapisami, czasem CELOWO duplikujemy dane (np. przechowany COUNT, zmaterializowany widok), by uniknac kosztownych JOIN-ow. To decyzja wydajnosciowa PO normalizacji, nie zamiast niej — i zawsze z planem na spojnosc.