Bazy danych – relacyjny model danych

Anomalie –

problemy ze zbyt dużą liczbą danych w

pojedynczej relacji

redundacja –

dane niepotrzebnie powtarzają się w kilku

rekordach

anomalie modyfikacji –

podczas modyfikacji wartość danych

nie zostanie poprawiona we wszystkich krotkach

anomalie usunięć –

usunięcie wartości atrybutu może

spowodować utratę części danych (całej krotki)

Bazy danych – relacyjny model danych

Dekompozycja relacji –

podział atrybutów relacji R między

dwa schematy nowych relacji

Przykład

Szkoła (nazwa przedmiotu, imię, nazwisko, adres prowadzącego)
Krotka (j. Angielski, Lucyna, Nowak, ul. Cicha 8 Warszawa)

Adres składa się z kilku części

• Redundancja danych - jeden prowadzący może mieć zajęcia z kilku

przedmiotów

• Zmiana jednej z informacji o prowadzącym (np. adresu) powoduje

konieczność zmiany wszystkich krotek zawierających te dane w celu
zachowania integralności

• Nie jest możliwe wprowadzenie informacji o prowadzącym, który w danym

semestrze nie ma żadnych zajęć

• Usuniecie przedmiotu może spowodować również usuniecie wszelkich

informacji o prowadzącym.

• Utrzymanie integralności takiej bazy jest bardzo trudne.

Bazy danych – relacyjny model danych

Dekompozycja relacji –

podział atrybutów relacji R między

dwa schematy nowych relacji

Przykład

Szkoła (nazwa przedmiotu, imię, nazwisko, adres prowadzącego)
Krotka (j. Angielski, Lucyna, Nowak, ul. Cicha 8 Warszawa)

Dekompozycja relacji:

Szkoła na dwie relacje - Nauczyciel i Przedmiot

Nauczyciel (Id_prowadzącego , imię, nazwisko, kod pocztowy,

miejscowość, ulica)

Przedmiot (nazwa przedmiotu, Id_prowadzącego)

Klucz
podstawowy

Klucz obcy

Bazy danych – relacyjny model danych

Normalizacja –

proces przekształcania reprezentacji bazy

danych (nazywany również rozkładem odwracalnym),
polegający na odnajdywaniu logicznych związków między
elementami danych. W każdym etapie normalizacja bazy
strukturę danych dzieli się na coraz więcej tabel z
zachowaniem podstawowych związków między elementami
danych.

Denormalizacja –

wprowadzenie kontrolowanej

nadmiarowości do bazy danych w celu przyśpieszenia
wykonywania na niej operacji (np. obsługiwania zapytań)

Bazy danych – relacyjny model danych

Pierwsza postać normalna (1NF) –

relacja R jest w

pierwszej postaci normalnej, jeśli wartości atrybutów są
elementarne tzn. są to pojedyncze wartości określonego typu,
a nie zbiory wartości.

POWIATY

NrPowiatu

NazwaPowiatu

Miejscowości

Nowosolski

67-100 Nowa Sól, 67-120 Kożuchów, 67-160 Otyń

65-560 Zielona Góra, 65-250 Ochla

Zielonogórski

POWIATY

67-160

Kod3

Ochla

Kożuchów

65-250

67-120

Kod2

Zielona

Góra

Nowa Sól

65-560

67-100

Kod1

Otyń

Zielonogórski

Nowosolski

NazwaPowiatu

NrPowiatu

Bazy danych – relacyjny model danych

Druga postać normalna (2NF)–

atrybuty nie wchodzące w skład klucza są zależne od całego
klucza (nie tylko od jego części)

każdy atrybut, który nie wchodzi w skład żadnego klucza
potencjalnego tej relacji jest w pełni funkcjonalnie zależny od
wszystkich kluczy potencjalnych tej relacji

Relacja będąca już w 2NF nie powinna zawierać redundancji

Bazy danych – relacyjny model danych

Przykład (2NF)

• I

- numer identyfikacyjny chorego,

• Im

- imię,

• N

- nazwisko,

• W

- wiek,

• Ods

- odział, •

- sala, •

- nazwa lekarstwa, •

- dawka lekarstwa.

KLUCZ

ANOMALIE:
anomalie dołączania –

chorzy nie otrzymujący lekarstw nie są

uwzględnieni w relacji

anomalie modyfikacji –

zmiana oddziału dla chorego (I = 1) wymaga

trzykrotnej aktualizacji danych

anomalie usunięć –

chory, który przestaje brać leki, jest usuwany z

bazy

Bazy danych – relacyjny model danych

Przykład (2NF)

• I

- numer identyfikacyjny chorego,

• Im

- imię,

• N

- nazwisko,

• W

- wiek,

• Ods

- odział, •

- sala, •

- nazwa lekarstwa, •

- dawka lekarstwa.

KLUCZ

Przyczyny występowania anomalii:

niektóre atrybuty (D) są funkcyjnie zależne od całego klucza IL, inne
natomiast (Im, N, W, Ods, S) zależne są tylko od części tego klucza
(w tym przypadku od I).
W schemacie relacyjnym istnieje niepełna zależność funkcyjna
atrybutów od klucza – niespełniony warunek 2NF

Bazy danych – relacyjny model danych

Przykład (2NF)

• I

- numer identyfikacyjny chorego,

• Im

- imię,

• N

- nazwisko,

• W

- wiek,

• Ods

- odział, •

- sala, •

- nazwa lekarstwa, •

- dawka lekarstwa.

KLUCZ

2 NF

Bazy danych – relacyjny model danych

Druga postać normalna (2NF)–

• schemat jest już w 2NF, jeśli każdy jego klucz jest jednoelementowy;

• przeprowadzanie schematu relacyjnego do 2NF nie jest procesem

jednoznacznym (dla jednego schematu relacyjnego może istnieć wiele
równoważnych informacyjnie układów projekcji tego schematu w 2NF)

PRZED NORMALIZACJĄ

PO NORMALIZACJI DO 2NF

Bazy danych – relacyjny model danych

Postać normalna Boyce’a – Codda

Relacja R jest w postaci BCNF wtedy i tylko wtedy, gdy dla
każdej nietrywialnej zależności A

, A

, ...., A

->B zbiór { A

, A2,

...., A

} jest nadkluczem R.

Oznacza to, że lewa strona każdej zależności nietrywialnej musi być
nadkluczem.

Bazy danych – relacyjny model danych

Postać normalna Boyce’a – Codda

Przykład – czy przedstawiona relacja Film jest w postaci BCNF

Klucz - tytuł rok nazwiskoGwiazdy

Tytuł

Rok

Dług
ość

Typ filmu Nazwa Studia Nazwisko

Gwiazdy

Gwiezdne
wojny

1997 124 Kolor

Fox

Carrie

Fischer

Gwiezdne
wojny

1997 124 Kolor

Fox

Mark

Hamill

Gwiezdne
wojny

1997 124 Kolor

Fox

Harrison

Ford

Potężne
Kaczory

1991 104 Kolor

Disney

Emilio

Estevez

Swiat
Wayne’a

1992 95 Kolor

Paramount

Dana

Carvey

Swiat
Wayne’a

1992 95 Kolor

Paramount

Mike

Meyers

tytuł rok Æ długość typFilmu nazwaStudia

Przedstawiona zależność jest zależnością funkcyjną, ale lewa strona
nie jest nadkluczem

Bazy danych – relacyjny model danych

Postać normalna Boyce’a – Codda

Przykład – dekompozycja relacji Film

Tytuł

Rok

Dług
ość

Typ filmu Nazwa Studia

Gwiezdne
wojny

1997 124 Kolor

Fox

Potężne
Kaczory

1991 104 Kolor

Disney

Swiat
Wayne’a

1992 95 Kolor

Paramount

Zależność:
tytuł rok Æ długość typFilmu nazwaStudia zachodzi dla relacji Film1

Rok, tytuł – samoistnie nie wyznaczają jednoznacznie pozostałych atrybutów
Jedyna nietrywialna zależność funkcyjna musi mieć z lewej strony co najmniej
tytuł i rok – lewe strony zależności muszą być nadkluczem
Relacja Film1 jest w postaci BCNF

Tytuł

Rok

Nazwisko Gwiazdy

Gwiezdne
wojny

1997 Carrie

Fischer

Gwiezdne
wojny

1997 Mark

Hamill

Gwiezdne
wojny

1997 Harrison

Ford

Potężne
Kaczory

1991 Emilio

Estevez

Swiat
Wayne’a

1992 Dana

Carvey

Swiat
Wayne’a

1992 Mike

Meyers

Bazy danych – relacyjny model danych

Dekompozycja do postaci BCNF

Powtarzany dostatecznie długo proces dekompozycji prowadzi
do zapisania każdej relacji w postaci kolekcji podzbiorów
atrybutów spełniających warunki:
- podzbiory są schematami relacji w postaci BCNF
- dane z pierwotnej relacji są wiernie reprezentowane w
relacjach powstałych w wyniku dekompozycji. Powinna być
możliwość dokładnego odtworzenia relacji pierwotnej.

Bazy danych – relacyjny model danych

Problemy z odzyskiwaniem danych po dekompozycji

Przykład

Problemy występują najczęściej wtedy, jeżeli podczas dekompozycji
nie są stosowane zależności funkcyjne

i B Æ C

A B  C
1 2  3
4 2  5

A B
1 2
4 2

B C
2 3
2 5

A B

1 2

4 2

Bazy danych – relacyjny model danych

Trzecia postać normalna

Relacja R jest w trzeciej postaci normalnej wtedy i tylko wtedy,
gdy jest spełniony warunek:
Jeśli A

, A

, ...., A

->B jest zależnością nietrywialną to albo

, A2, ...., A

} jest nadkluczem,

albo B jest elementem

pewnego klucza.

Bazy danych – relacyjny model danych

Trzecia postać normalna

Trzecia postać normalna wymaga, aby wszystkie kolumny nie
należące do klucza, zależały funkcyjnie od klucza
kandydującego.
Klucz kandydujący spełnia te same warunki co klucz główny i
charakteryzuje się tym, że:
- żadne dwa rekordy w tabeli nie mogą mieć tej samej
kombinacji wartości;
- z klucza kandydującego nie można wyodrębnić podgrupy
kolumn również zapewniających unikatowość danego rekordu.

W tej postaci normalnej nie są wymagane zależności pomiędzy
kolumnami poza kluczem

Bazy danych – relacyjny model danych

Trzecia postać normalna

Przykład
Relacja: Zamówienia(tytuł, kino, miasto)

Zależności funkcyjne:
kino Æ miasto
tytuł miasto Æ kino

Określamy klucze:
Żaden pojedynczy atrybut nie jest kluczem
(tytuł, miasto)
(kino, tytuł)
(miasto, kino)

–

nie jest kluczem, bo tytuł nie zależy funkcyjnie od miasta

i kina (np. kino z wieloma salami)

Zależność funkcyjna:
kino Æ miasto – naruszenie warunku BCNF

(kino nie jest nadkluczem)

Bazy danych – relacyjny model danych

Trzecia postać normalna

Przykład
Relacja: Zamówienia(tytuł, kino, miasto)
Próba dekompozycji do relacji (kino, miasto); (kino, tytuł)

kino miasto
Wisła Warszawa
Polonia Warszawa

kino tytuł
Wisła W

sieci

Polonia W

sieci

kino miasto

tytuł

Wisła Warszawa W

sieci

Polonia Warszawa W

sieci

Zależność tytuł miasto

kino

nie jest spełniona

Bazy danych – relacyjny model danych

Trzecia postać normalna

Relacja R jest w trzeciej postaci normalnej wtedy i tylko wtedy,
gdy jest spełniony warunek:
Jeśli A

, A

, ...., A

->B jest zależnością nietrywialną to albo

, A2, ...., A

} jest nadkluczem,

albo B jest elementem

pewnego klucza.

Zależność:

kino Æ miasto

miasto jest elementem klucza

Relacja spełnia warunki 3NF(PN)

Bazy danych – relacyjny model danych

Przykład 2 (3NF)

WYK

nazwa firmy realizującej projekt,

ADRES

adres firmy,

PROJ

nazwa projektu,

DATA

data ukończenia projektu.

KLUCZ

Atrybuty zależne od
klucza – 2NF

ANOMALIE:
anomalie dołączania –

braku możliwości wpisania projektu do tabeli

dopóki nie zostanie określony przynajmniej jeden wykonawca

anomalie modyfikacji –

zmiana terminu realizacji projektu wymaga

poprawy w wielu miejscach

anomalie usunięć –

przerwanie realizacji projektu powoduje utratę

informacji na temat firm

Bazy danych – relacyjny model danych

Przykład 2 (3NF)

WYK

nazwa firmy realizującej projekt,

ADRES

adres firmy,

PROJ

nazwa projektu,

DATA

data ukończenia projektu.

KLUCZ

Atrybuty zależne od
klucza – 2NF

PO NORMALIZACJI DO 3NF

Atrybuty w 3PN powinny
być zależne od klucza,
całego klucza i tylko od
klucza relacji

Bazy danych – relacyjny model danych

Jak rozpoznać poszczególne postaci relacji ?

•

Relacja jest w 1NF - pierwszej postaci normalnej, jeżeli jej przypadek
(tabela) spełnia założenia tabeli relacyjnej.

•

W przypadku gdy klucz relacji jest jednoelementowy i tabela jest w 1NF, to
jest ona również w drugiej postaci normalnej (nie tylko klucz
jednoelementowy zapewnia własność 2NF !!!!!).

•

Przyczyną anomalii w pierwszej postaci normalnej jest niepełna zależność
atrybutów od klucza, co oznacza, że są atrybuty, zależne od całego klucza,
ale istnieją również atrybuty zależne od jego części.

•

Zjawiska niekorzystne, które mogą wystąpić w drugiej postaci normalnej i
powodować anomalie, to zależność pomiędzy atrybutami nie wchodzącymi
w skład klucza.

•

Rozwiązaniem tych wszystkich problemów jest projektowanie tabel w
trzeciej postaci normalnej w 3NF.

Bazy danych – relacyjny model danych

Wady normalizacji

• wydłużenie czasu wyszukiwania

• „nie należy przechowywać w bazie danych wartości, które

można wyliczyć”

stawka zasadnicza * liczba lat / 100

(stawka zasadnicza + dodatek za szkodliwość) * liczba lat / 100

Bazy danych – relacyjny model danych

Zależność wielowartościowa

, A

, ...., A

->->B

...B

zachodzi w relacji R jeżeli:
dla krotek o ustalonych wartościach atrybutów typu A, zbiór
wartości atrybutów typu B nie zależy od żadnych wartości tych
atrybutów z relacji R, których nie ma ani w zbiorze atrybutów
typu A, ani w zbiorze atrybutów typu B

Zależności wielowartościowe występują wówczas, gdy

istnieją dwa takie zbiory atrybutów relacji, których

wartości występują w relacji we wszystkich możliwych

kombinacjach

Bazy danych – relacyjny model danych

nazwisko

ulica

miasto

tytuł

rok

C. Fisher

123 Maple St.

Hollywood

Gwiezdne
wojny

1977

C. Fisher

5 Locus Ln.

Malibu

Gwiezdne
wojny

1977

C. Fisher

123 Maple St.

Hollywood

Imperium
kontratakuje

1980

C. Fisher

5 Locus Ln.

Malibu

Imperium
kontratakuje

1980

C. Fisher

123 Maple St.

Hollywood

Powrót Jedi

1983

C. Fisher

5 Locus Ln.

Malibu

Powrót Jedi

1983

klucz relacji Film

Zależność wielowartościowa:

nazwisko Æ Æ ulica miasto

Bazy danych – relacyjny model danych

Reguła zależności trywialnych

jeżeli w relacji zachodzi zależność: A

, A

, ...., A

->->B

...B

to jeżeli C

...C

są wszystkimi atrybutami typu B,oraz część

z nich jest typu A zachodzi również:

, A

, ...., A

->->C

...C

Bazy danych – relacyjny model danych

Reguła przechodniości

jeżeli w relacji zachodzą zależności:

, A

, ...., A

->->B

...B

->->C

...C

to zachodzi również zależność

, A

, ...., A

->->C

...C

Bazy danych – relacyjny model danych

Reguły podziału i łączenia

nazwisko Æ Æ ulica miasto

nazwisko Æ Æ ulica ????

nazwisko

ulica

miasto

tytuł

rok

C. Fisher

123 Maple St.

Hollywood

Gwiezdne
wojny

1977

C. Fisher

5 Locus Ln.

Malibu

Gwiezdne
wojny

1977

Zależności wielowartościowe nie spełniają reguły podziału

i reguły łączenia

!!!!!!!!!

Bazy danych – relacyjny model danych

Reguła dopełnienia

jeżeli w relacji R zachodzą zależności:

, A

, ...., A

->->B

...B

to w relacji R zachodzi również

, A

, ...., A

->->C

...C

gdzie atrybuty typu C nie są atrybutami typu A ani typu B

Przykład

nazwisko Æ Æ ulica miasto

w wyniku reguły dopełnienia:

nazwisko Æ Æ tytuł rok

Bazy danych – relacyjny model danych

Czwarta postać normalna

Relacja R jest w czwartej postaci normalnej wtedy i tylko

wtedy, jeżeli

, A

, ...., A

->->B

...B

jest nietrywialną zależnością wielowartościową; {A

, A

, ...., A

}

jest nadkluczem relacji R

Bazy danych – relacyjny model danych

Czwarta postać normalna

nazwisko

ulica

miasto

tytuł

rok

C. Fisher

123 Maple St.

Hollywood

Gwiezdne
wojny

1977

C. Fisher

5 Locus Ln.

Malibu

Gwiezdne
wojny

1977

C. Fisher

123 Maple St.

Hollywood

Imperium
kontratakuje

1980

C. Fisher

5 Locus Ln.

Malibu

Imperium
kontratakuje

1980

C. Fisher

123 Maple St.

Hollywood

Powrót Jedi

1983

C. Fisher

5 Locus Ln.

Malibu

Powrót Jedi

1983

Zależność wielowartościowa:

nazwisko Æ Æ ulica miasto

jest nietrywialna, jednak nazwisko nie stanowi nadklucza

(jedynym kluczem tej relacji są wszystkie atrybuty)

relacja nie jest w 4NF (4PN)

Bazy danych – relacyjny model danych

Dekompozycja do czwartej postaci normalnej

1. Znajdujemy zależność, która nie spełnia warunków 4NF
np.

, A

, ...., A

->->B

...B

gdzie {A

, A

, ...., A

} nie jest nadkluczem

2. Schemat relacji R, który nie spełnia warunku 4NF dzielimy
na dwa schematy:
- pierwszy schemat zawiera atrybuty typu A i typu B
- drugi schemat zawiera wszystkie atrybuty typu A oraz te
wszystkie atrybuty z relacji R, które nie są ani typu A,
ani typu B

Bazy danych – relacyjny model danych

Dekompozycja do czwartej postaci normalnej - przykład

naruszenie warunku 4NF powoduje zależność:

nazwisko Æ Æ ulica miasto

schemat relacji

{nazwisko, ulica, miasto, tytuł, rok}

zastępujemy schematami:

{nazwisko, ulica, miasto}
{nazwisko, tytuł, rok}

Document Outline