Kiedy gadamy o analizie bazy danych pod kątem normalnych form, chodzi o sprawdzenie struktury tabel, ich powiązań i zależności między atrybutami. Główny cel tej analizy — znaleźć naruszenia normalizacji i ocenić, jak wpływają na wydajność, integralność i wygodę pracy z danymi.
Mówiąc prościej, to trochę jak audyt księgowości: sprawdzasz, żeby kasa nie leżała byle gdzie, tylko była porządnie rozdzielona na odpowiednie kategorie wydatków.
Praktyczne podejście do analizy bazy danych
W każdej bazie danych zaczynamy od zadania trzech kluczowych pytań, które odpowiadają trzem normalnym formom.
Załóżmy, że mamy bazę magazynu z tabelą o takiej strukturze:
| product_id | product_name | supplier_name | supplier_phone | stock_quantity |
|---|---|---|---|---|
| 1 | Gwoździe | BuildKit | +12301112233 | 150 |
| 2 | Wkręty | FastenerPro | +12306667788 | 200 |
| 3 | Nakrętki | BuildKit | +12301112233 | 100 |
Jak sprawdzić tę tabelę pod kątem normalnych form?
Przypomnę, tabela jest w 1NF, jeśli:
- Każda komórka zawiera jedną wartość.
- W tabeli nie ma powtarzających się kolumn dla tego samego typu danych.
W naszym przykładzie nie ma naruszenia 1NF: każda komórka to wartość atomowa. To znaczy, że tabela jest już w 1NF. Super! Lecimy dalej.
Tabela jest w 2NF, jeśli:
- Jest w 1NF.
- Wszystkie niekluczowe atrybuty zależą tylko od całego klucza głównego (a nie od jego części).
W tej tabeli widać, że supplier_name i supplier_phone zależą tylko od product_id — klucza głównego. Ale tu pojawia się duplikacja danych: dla tego samego dostawcy trzymamy jego nazwę i telefon w kilku wierszach.
Żeby doprowadzić tabelę do 2NF, możemy ją rozbić na dwie tabele:
Tabela Products:
| product_id | product_name | supplier_id | stock_quantity |
|---|---|---|---|
| 1 | Gwoździe | 1 | 150 |
| 2 | Wkręty | 2 | 200 |
| 3 | Nakrętki | 1 | 100 |
Tabela Suppliers:
| supplier_id | supplier_name | supplier_phone |
|---|---|---|
| 1 | BuildKit | +78901112233 |
| 2 | FastenerPro | +78906667788 |
Teraz każdy dostawca jest tylko raz, a powiązanie między tabelami jest przez foreign key supplier_id.
Tabela jest w 3NF, jeśli:
- Jest w 2NF.
- Wszystkie niekluczowe atrybuty zależą tylko od klucza głównego, a nie od innych niekluczowych atrybutów.
W przypadku znormalizowanych tabel Products i Suppliers nie widać żadnych zależności przechodnich. To znaczy, że tabele są już w 3NF.
Zadanie praktyczne
Załóżmy, że mamy oryginalną tabelę "Uniwersytet"
| student_id | student_name | course_name | professor_name | professor_email |
|---|---|---|---|---|
| 101 | Otto Lin | Matematyka | Peter Pen | pen@university.com |
| 102 | Anna Song | Fizyka | Alex Sid | sid@university.com |
| 103 | Otto Lin | Fizyka | Alex Sid | sid@university.com |
- Sprawdź tabelę pod kątem normalnych form.
- Doprowadź ją do 1NF, 2NF i 3NF, jeśli trzeba.
Rozwiązanie
KROK 1: Sprawdzenie 1NF
Tabela już jest w 1NF: każda komórka to jedna wartość.
KROK 2: Sprawdzenie 2NF
Tabela łamie 2NF: info o profesorach (imię i email) się powtarza. Możemy to przenieść do osobnej tabeli:
Tabela Students:
| student_id | student_name |
|---|---|
| 101 | Otto Lin |
| 102 | Anna Song |
Tabela Courses:
| course_id | course_name | professor_id |
|---|---|---|
| 1 | Matematyka | 1 |
| 2 | Fizyka | 2 |
Tabela Professors:
| professor_id | professor_name | professor_email |
|---|---|---|
| 1 | Peter Pen | pen@university.com |
| 2 | Alex Sid | sid@university.com |
Tabela Enrollments:
| enrollment_id | student_id | course_id |
|---|---|---|
| 1 | 101 | 1 |
| 2 | 102 | 2 |
| 3 | 103 | 2 |
KROK 3: Sprawdzenie 3NF
W nowej strukturze nie ma zależności przechodnich. Tabele są zgodne z 3NF.
Praktyczne wskazówki
- Nie dąż do ideału bez potrzeby. Czasem zbyt mocna normalizacja utrudnia zapytania.
- Podchodź do analizy jak detektyw. Szukaj duplikatów, zbędnych zależności i innych "anomalii".
- Nie zapominaj o wydajności. Normalizacja to balans między czystością danych a szybkością ich przetwarzania.
Teraz, kiedy umiesz znajdować problemy w bazie i rozwiązywać je, spokojnie przeprowadzisz "rewizję" bazy dowolnej wielkości. Pamiętaj: dobra baza danych to nie tylko funkcjonalny, ale też ładny (czyli znormalizowany) projekt.
GO TO FULL VERSION