ITBlog

1. czym jest druga postać normalna (2NF)?

Osiągnięcie Pierwszej Postaci Normalnej (1NF) uporządkowało strukturę tabeli, eliminując grupy powtarzalne. Jednak tabela w 1NF wciąż może zawierać znaczną redundancję, jeśli jej klucz główny jest kluczem złożonym (składającym się z więcej niż jednego atrybutu). Druga Postać Normalna (2NF) koncentruje się właśnie na tym problemie.

Definicja 2NF: Relacja jest w Drugiej Postaci Normalnej (2NF) wtedy i tylko wtedy, gdy:

1. Jest w Pierwszej Postaci Normalnej (1NF).
2. Każdy atrybut niekluczowy jest w pełni funkcyjnie zależny od całego klucza głównego.

Mówiąc prościej, w tabeli 2NF nie mogą istnieć zależności częściowe. Oznacza to, że żaden atrybut, który nie jest częścią klucza głównego, nie może zależeć tylko od części klucza złożonego. Jeśli tabela ma prosty klucz główny (składający się z jednego atrybutu), to automatycznie spełnia warunki 2NF, o ile jest w 1NF.

2. identyfikacja zależności częściowych – studium przypadku

Rozważmy tabelę Zapisy_Na_Kursy, która przechowuje informacje o tym, jacy studenci zapisali się na jakie kursy i jaką otrzymali ocenę.

Krok 1: Ustalenie klucza głównego. Ani ID_Studenta, ani ID_Kursu samodzielnie nie identyfikują unikalnie wiersza. Student może być zapisany na wiele kursów, a na kurs może być zapisanych wielu studentów. Dlatego kluczem głównym musi być klucz złożony: {ID_Studenta, ID_Kursu}.

Krok 2: Analiza zależności atrybutów niekluczowych. Atrybuty niekluczowe to: Nazwisko_Studenta, Nazwa_Kursu, Ocena.

• Nazwisko_Studenta: Czy zależy od całego klucza {ID_Studenta, ID_Kursu}? Nie. Nazwisko zależy tylko od ID_Studenta. Mamy tu zależność częściową.
  Zależność: {ID_Studenta} → {Nazwisko_Studenta}
• Nazwa_Kursu: Czy zależy od całego klucza? Nie. Nazwa kursu zależy tylko od ID_Kursu. To również jest zależność częściowa.
  Zależność: {ID_Kursu} → {Nazwa_Kursu}
• Ocena: Czy zależy od całego klucza? Tak. Ocena zależy od tego, który student i na którym kursie ją otrzymał. Jest to pełna zależność funkcyjna.
  Zależność: {ID_Studenta, ID_Kursu} → {Ocena}

Ponieważ znaleźliśmy zależności częściowe, nasza tabela nie jest w 2NF. Redundancja jest widoczna gołym okiem: nazwisko „Kowalski” i nazwa kursu „Bazy Danych” są powtórzone.

3. proces dekompozycji do 2NF

Aby osiągnąć 2NF, musimy rozbić (dokonać dekompozycji) oryginalną tabelę na mniejsze, tak aby wyeliminować zależności częściowe. Proces ten przebiega następująco:

1. Tworzymy nową tabelę dla każdej części klucza, która powoduje zależność częściową. Ta część klucza staje się kluczem głównym nowej tabeli.
2. Przenosimy do nowych tabel wszystkie atrybuty, które są od nich częściowo zależne.
3. W oryginalnej tabeli pozostawiamy tylko te atrybuty, które są w pełni zależne od całego klucza złożonego.

Krok 1: wydzielenie danych o studentach

Tworzymy tabelę Studenci, gdzie kluczem głównym jest ID_Studenta, i przenosimy tam Nazwisko_Studenta.

Krok 2: wydzielenie danych o kursach

Tworzymy tabelę Kursy, gdzie kluczem głównym jest ID_Kursu, i przenosimy tam Nazwa_Kursu.

Krok 3: modyfikacja oryginalnej tabeli

W oryginalnej tabeli, którą teraz możemy nazwać Oceny, pozostaje klucz złożony {ID_Studenta, ID_Kursu} oraz atrybut Ocena, który jest od niego w pełni zależny. Kolumny ID_Studenta i ID_Kursu stają się teraz kluczami obcymi, wskazującymi na nowe tabele.

4. korzyści z osiągnięcia 2NF

Po dekompozycji nasza baza danych jest w Drugiej Postaci Normalnej. Co zyskaliśmy?

• Eliminacja redundancji: Nazwisko każdego studenta i nazwa każdego kursu są teraz przechowywane tylko w jednym miejscu.
• Rozwiązanie anomalii modyfikacji: Jeśli nazwa kursu K01 zmieni się na „Zaawansowane Bazy Danych”, wystarczy zaktualizować jeden rekord w tabeli Kursy.
• Rozwiązanie anomalii wstawiania: Możemy dodać nowego studenta do tabeli Studenci, nawet jeśli nie jest jeszcze zapisany na żaden kurs.
• Rozwiązanie anomalii usuwania: Jeśli usuniemy zapis studenta 102 na kurs K01, nie utracimy informacji o istnieniu tego studenta ani tego kursu.

Osiągnięcie 2NF jest kluczowym krokiem w kierunku stworzenia solidnej i spójnej struktury bazy danych. Jednak, jak zobaczymy w kolejnym etapie, nawet tabele w 2NF mogą wciąż zawierać pewien rodzaj redundancji, wynikający z zależności przechodnich, którymi zajmuje się Trzecia Postać Normalna (3NF).