Normalizacja

Wykład X
Normalizacja
Proces dekompozycji; odwracalny rozpoczynający się od podstawowej relacji
zmierzającej do schematu optymalnego, pozbawionego anomalii.
Anomalie
 wstawiania
 usuwania
 modyfikacji
Proces normalizacji musi odbywać się bez strat
 danych; żaden atrybut nie może zostać zgubiony
 zależności; wszystkie zależności funkcyjne muszą być reprezentowane w pojedynczych
schematach relacji
proces normalizacji spowoduje:
o „spłaszczenie” struktury danych poprzez eliminację atrybutów złożonych
o ustalenie pierwotnych i obcych kluczy relacji
o wyeliminowanie niepożądanych zależności pomiędzy kolumnami relacji poprzez
wprowadzenie nowych relacji
 aktualnie rozróżnia się pięć postaci normalnych
 proces normalizacji jest (zazwyczaj) kończony po osiągnięciu 3NF, która w większości
praktycznych zastosowań uznawana jest za wystarczającą
 przekształcanie relacji do zaawansowanych postaci normalnych dotyczy tabel, które
posiadają więcej niż 3 atrybuty i każdy z nich pełni funkcję klucza.
Postacie normalne ( zdefiniowane przez Codda )
Pierwsza postać normalna 1NF
 relacja jest w pierwszej postaci normalnej, jeśli każda wartość atrybutu w każdej krotce
tej relacji jest wartością atomową
Zależność funkcyjna – definicja:
atrybut Y relacji R pozostaje w zależności funkcyjnej od
atrybutu X relacji R wtedy i tylko wtedy, gdy z każdą wartością
atrybutu X jest zawsze skojarzona ta sama wartość atrybutu Y
X→Y
Dalsze postacie normalne 2NF , 3NF
Wykład X
 relacja jest w drugiej postaci normalnej, jeśli jest w 1NF i każdy atrybut nie należący
do żadnego klucza potencjalnego jest zależny funkcyjnie od całego klucza głównego
 relacja jest w trzeciej postaci normalnej jeśli jest w 2NF i wszystkie atrybuty nie
należące do żadnego klucza potencjalnego są wzajemnie niezależne
Przysięga normalizacji ( parafraza )
1.
2.
3.
4.
5.
Bez powtórzeń
Atrybuty zależą od klucza
Od całego klucza
I niczego innego, tylko klucza
Tak mi dopomóż Codd.
przykład:
z www.ploug.org.pl/seminarium/05_01/pliki/2.pdf
Tabela ZAMÓWIENIA
Nr_
zamówienia
Id_
dostawcy
Nazwa_
dostawcy
Adres_
dostawcy
Id_
części
Nazwa_
Części
Ilość_
Magazyn
zam_części
Adres_
magazynu
001
001
001
002
002
003
004
300
300
300
400
400
500
600
NISSAN
NISSAN
NISSAN
HONDA
HONDA
TOYOTA
HONDA
Liege
Liege
Liege
Glasgow
Glasgow
Tokio
London
53
57
59
54
32
88
59
Pompa
Filtr
Błotnik
Pompa
Koło
Silnik
Błotnik
100
50
500
500
100
15
400
Warszawa
Warszawa
Szczecin
Warszawa
Szczecin
Poznań
Szczecin
5
5
6
5
6
7
6
2
Założenia
• tabela zawiera informacje o zamówieniach części u dostawców i skierowaniu ich do
odpowiednich magazynów
• jedno zamówienie może dotyczyć wielu części dostarczanych przez tego samego dostawcę
• różne zamówienia mogą dotyczyć tego samego dostawcy i tych samych części
• ta sama część może być dostarczana przez różnych dostawców
• te same części są składowane zawsze w tym samym magazynie
• w zamówieniach jest podawany identyfikator dostawcy i nazwa dostawcy, gdyż różni
dostawcy mogą mieć tę samą nazwę ( np. Honda )
Wady ( ANOMALIE ) tabeli ZAMÓWIENIA
•
•
•
występuje dublowanie się danych; wielokrotnie jest pamiętany adres dostawcy; podobnie
magazynu
w tej tabeli nie możemy zapisać adresu dostawcy, do którego nie złożono żadnego
zamówienia
usuwając informację o zamówieniu skierowanym do danego dostawcy, możemy utracić
Wykład X
•
informacje o jego adresie
analogiczna sytuacja występuje w odniesieniu do magazynu i jego adresu
Rys. Zależności funkcyjne dla tabeli Zamówienia
proponowane tabele po normalizacji to:
Zamowienie_do_dostawcy(Nr_zamowienia, Id_dostawcy)
Czesci(Id_czesci, Nazwa_czesci)
Czesci_w_magazynie(Id_czesci, Magazyn)
Magazyny(Magazyn, Adres_magazynu)
Dostawcy(Id_dostawcy, Nazwa_dostawcy, Adres_dostawcy)
Dostawy_czesci(Nr_zamowienia, id_czesci, ilosc_zam_czesci)
Postulaty Codd'a dla relacyjnej bazy danych
(1985 )
1. Postulat informacyjny
Na poziomie logicznym dane są reprezentowane wyłącznie za pomocą tabelwartości.
2. Postulat dostępu
Każda wartość w bazie danych jest dostępna poprzez nazwę tabeli, atrybut oraz wartości kluczy
głównego
Wykład X
3. Postulat wartości NULL
Dostępna jest specjalna wartość NULL do reprezentacji wartości nieokreślonej, nieznanej
4. Postulat słownika danych
Informacje o obiektach bazy danych tworzących schemat bazy danych są na poziomie logicznym
zgrupowane w tabele i dostępne w taki sam sposób jak każde inne dane
5. Postulat pełnego języka danych
W systemie jest zaimplementowany pełny język przetwarzania danych obejmujący definiowanie
danych, perspektyw, więzów spójności, manipulację danymi (interaktywnie jak i przez program);
nadawanie uprawnień użytkownikom, obsługę transakcji i bezpieczeństwo danych.
6. Postulat modyfikowania danych przez perspektywę
Możliwe jest modyfikowanie danych za pomocą perspektyw, w przypadku gdy taka modyfikacja jest
semantycznie sensowna.
7. Postulat modyfikowania danych na wysokim poziomie abstrakcji
System umożliwia modyfikowanie danych za pomocą operacji, których argumentami są tabele
( perspektywy ) a więc w szczególności nie tylko w sposób nawigacyjny
8. Fizyczna niezależność danych
Zmiany w metodach przechowywania danych i dostępu do nich nie mają wpływu na aplikację.
9. Logiczna niezależność danych
Zmiany w tabelach zachowujących informacje i dopuszczalne semantycznie, nie mają wpływu na
aplikację.
10. Niezależność więzów spójności
Więzy spójności są definiowalne w języku bazy danych, nie muszą być wyrażone w aplikacji.
11. Niezależność dystrybucyjna
System ( i jego język ) umożliwiają używanie danych zapisanych w różnych fizycznie miejscach ( w różnych węzłach sieci ).
12. Zabezpieczenie przed operacjami na niższych poziomach abstrakcji
Jeśli system umożliwia operacje na niższych poziomach abstrakcji, nie mogą one naruszać
relacyjnego modelu danych w tym pomijać ograniczeń określonych przez więzy spójności.