Zasady drugiej postaci normalnej (2NF)

Tablica jest w drugiej postaci normalnej, jeśli:

1. Jest już w pierwszej postaci normalnej (1NF).
2. Każda niekluczowa kolumna zależy od całego klucza głównego, a nie tylko od jego części.

Jeśli klucz główny składa się z kilku pól (klucz złożony), to żaden z niekluczowych atrybutów (kolumn) nie powinien zależeć tylko od jednej części tego klucza. Innymi słowy, 2NF eliminuje częściowe zależności.

Przykład naruszenia 2NF

Załóżmy, że mamy tabelę student_courses (Studenci i Kursy), która przechowuje info o studentach, ich kursach i prowadzących:

• student_id i course_id razem tworzą klucz główny złożony.
• Ale zwróć uwagę na kolumny course_name i instructor_name. One zależą tylko od course_id, a nie od całej pary (student_id, course_id).

I tu właśnie mamy częściową zależność! course_name i instructor_name zależą tylko od części klucza złożonego (course_id). To narusza zasady 2NF.

Sprowadzenie tabeli do 2NF

Naszym zadaniem jest wyeliminować częściową zależność, dzieląc tabelę na dwie. Dzięki temu pozbędziemy się nadmiarowości i poprawimy spójność danych.

Wydzielmy info o kursach do osobnej tabeli courses:

Główną tabelę sprowadzamy do takiej postaci:

Teraz każda kolumna zależy od całego klucza głównego. Podzieliliśmy dane tak, żeby wszystko było logicznie powiązane i usunęliśmy naruszenie 2NF.

Magia eliminacji nadmiarowości

Zwróć uwagę na tabelę przed normalizacją. W kolumnie instructor_name powtarza się imię "Lin". A ile takich powtórzeń może być w prawdziwej bazie z tysiącami rekordów? Dzięki podziałowi tabel pozbyliśmy się nadmiarowości i zmniejszyliśmy ryzyko błędów, np. literówek ("Lin" vs "Ling").

Przykład z życia

Wyobraź sobie, że prowadzisz ewidencję zamówień na produkty. Masz taką tabelę order_items (zamówienia i produkty), gdzie order_id i item_id tworzą klucz główny:

Jak widzisz, ceny i nazwy produktów się powtarzają. To znak naruszenia 2NF, bo item_name i price zależą tylko od item_id.

Żeby sprowadzić tabelę do 2NF, tworzymy tabelę items:

I zmieniamy tabelę order_items, zostawiając tylko identyfikatory zamówienia i produktu:

Teraz dane są czyste jak kod po code review — żadnej nadmiarowości.

Zadanie praktyczne: spróbuj sam!

Załóżmy, że masz tabelę employee_projects, która zawiera info o pracownikach, ich projektach i menedżerach projektów:

Spróbuj:

1. Znajdź zależności, które łamią wymagania 2NF.
2. Podziel tabelę na dwie, eliminując naruszenie.

Dlaczego warto trzymać się 2NF?

Po co w ogóle trzymać się drugiej postaci normalnej (2NF)? Proste: żeby dane się nie powielały i nie robiły bałaganu. Kiedy usuwasz częściowe zależności, tabele są czystsze — bez powtarzających się informacji, jak to samo imię prowadzącego w każdej linii. To oszczędza miejsce i eliminuje ryzyko niespójności: zmieniasz imię w jednym miejscu — i wszędzie jest aktualne.

Poza tym, zapytania do takiej bazy pisze się łatwiej: jak struktura jest logiczna i dane nie są rozrzucone po tysiącu wierszy, filtrowanie i grupowanie działa szybciej i pewniej. Jasne, za to płacisz trochę bardziej złożonymi zapytaniami SQL z JOIN-ami, bo tabel jest więcej. Ale lepiej jeden JOIN niż sto wierszy z tymi samymi nazwiskami. W większości przypadków normalizacja się opłaca.

Integracja z prawdziwymi projektami

Znajomość 2NF przyda ci się:

• Przy projektowaniu bazy danych: żeby uniknąć chaosu w tabelach.
• Na rozmowie kwalifikacyjnej: często proszą, żeby wyjaśnić albo sprowadzić tabele do postaci normalnej.
• W prawdziwej pracy: kiedy dostaniesz zadanie optymalizacji istniejącej bazy, dzieląc "monolityczne" tabele na znormalizowane.

Druga postać normalna (2NF) pomaga wyeliminować częściowe zależności w tabeli, gdzie klucz główny jest złożony. Dzielimy tabele na logiczne bloki, żeby każda kolumna zależała tylko od całego klucza, a nie od jego części. To poprawia jakość bazy, eliminuje nadmiarowość i zwiększa jej elastyczność. Gotowy na trzecią postać normalną? Lecimy dalej!

2

Zadanie

SQL SELF, poziom 25, lekcja 2

Niedostępne

Sprowadzenie tabeli do 2NF

Sprowadzenie tabeli do 2NF

Otwórz