Zasady trzeciej postaci normalnej (3NF)

Trzecia postać normalna (3NF) to krok w stronę jeszcze większego porządku w naszych danych. W skrócie, tabela jest w 3NF, jeśli:

1. Jest już w drugiej postaci normalnej (2NF).
2. Wszystkie atrybuty niebędące kluczami zależą tylko od klucza głównego i od niczego innego (żadnych zależności przechodnich!).

Innymi słowy, 3NF wymaga, żeby wszystkie dane w tabeli były bezpośrednio powiązane z jej kluczem głównym i nie zależały od innych niekluczowych atrybutów.

Zależność przechodnia pojawia się, jeśli atrybut A zależy od atrybutu B, a atrybut B zależy od atrybutu C, co tworzy łańcuch zależności A → B → C. Na przykład, „Pracownik” zależy od „Działu”, a „Dział” zależy od „Lokalizacji”. Wychodzi na to, że „Pracownik” przechodnio zależy od „Lokalizacji”.

Przykład naruszenia 3NF

Załóżmy, że mamy tabelę employees, która przechowuje dane o pracownikach:

Tutaj:

• employee_id — klucz główny.
• department i department_manager — atrybuty niebędące kluczami.

Na pierwszy rzut oka wszystko wygląda spoko, ale jak się przyjrzymy, to widać problem: department_manager zależy nie od employee_id, tylko od department. W ten sposób powstaje zależność przechodnia: employee_id → department → department_manager.

Problemy, które mogą się pojawić

Jeśli zmienimy imię szefa działu („Finanse”), będziemy musieli zaktualizować wszystkie wiersze, gdzie ten dział jest wpisany. Jeśli przypadkiem zapomnimy o którymś wierszu, dane staną się niespójne. To ból głowy, którego można uniknąć.

Sprowadzenie tabeli do 3NF

Żeby pozbyć się zależności przechodnich, rozdzielimy tabelę na dwie: jedna będzie przechowywać dane o pracownikach, a druga — o działach.

Tablica employees

Tablica departments

Teraz wszystko jest poukładane i każda tabela robi swoje:

1. Tablica employees przechowuje dane o pracownikach.
2. Tablica departments przechowuje dane o działach i ich menedżerach.

Jeśli menedżer działu się zmieni, wystarczy zaktualizować tylko jeden wiersz w tabeli departments, a nie wszystkie rekordy pracowników.

Jak rozpoznać, że tabela łamie 3NF?

Żeby sprawdzić, czy tabela łamie 3NF, zobacz:

1. Czy są w tabeli zależności przechodnie? Na przykład, atrybut A zależy od atrybutu B, który zależy od atrybutu C.
2. Czy wszystkie atrybuty niebędące kluczami zależą bezpośrednio od klucza głównego? Jeśli coś zależy od innego niekluczowego atrybutu, to tabela nie jest w 3NF.

Praktyczny przykład: sklep

Spójrzmy na tabelę sales, która zawiera dane o sprzedaży:

Tu wyraźnie widać nadmiarowość: informacja o cenie produktu powtarza się przy każdej sprzedaży. Jeśli cena się zmieni, dane od razu tracą spójność.

Żeby naprawić naruszenie 3NF, rozdzielimy tabelę na dwie:

1. Tablica sales będzie przechowywać informacje o sprzedaży.
2. Tablica products — dane o produktach i ich cenach.

Tablica sales

Tablica products

Teraz, jeśli cena produktu się zmieni, wystarczy zaktualizować jeden wiersz w tabeli products i dane pozostają spójne.

Zadanie praktyczne

Masz zadanko: masz tabelę students_courses w takim układzie:

Podziel tabelę tak, żeby była zgodna z 3NF. Podpowiedź: musisz stworzyć trzy tabele (students, courses, teachers) i dobrze je połączyć.

Dlaczego warto trzymać się 3NF?

Po co w ogóle bawić się w trzecią postać normalną (3NF)? Bo to serio ułatwia życie. Jak tabele są w 3NF, dane są schludniejsze — żadnych zbędnych duplikatów, więc mniejsze ryzyko, że coś przypadkiem popsujesz. Aktualizacje są szybsze i prostsze, bo wszystko trzymasz w jednym miejscu, a nie kopiujesz po wszystkich wierszach.

Do tego struktura bazy jest bardziej elastyczna. Chcesz dodać nowe pole albo zmienić stare — nie musisz przebudowywać całego systemu.

Ale, jak to w życiu, jest haczyk: zbyt gorliwa normalizacja może skończyć się masą małych tabel i skomplikowanymi zapytaniami z mnóstwem JOIN-ów. Czasem to naprawdę może spowalniać. Więc najważniejsze to mieć wyczucie. Tam, gdzie trzeba — normalizuj, a gdzie lepiej zostawić trochę nadmiarowości — nie bój się.

Dalej będziemy wchodzić głębiej: nauczymy się dobrze budować relacje między tabelami i tworzyć bazy, które są i wygodne, i niezawodne. Do dzieła, po świetny design bazy danych!