3.3.

OD DIAGRAMW ZWIZKW ENCJI DO PROJEKTW RELACYJNYCH I 3 1

wiczenie 3.2.2. Naley przeksztaci opis w jzyku ODL z rys. 2.7 do relacyjnego schematu bazy danych. W
jaki sposb trzy modyfikacje wyspecyfikowane w wiczeniu 2.1.8 wpywaj na posta schematu relacyjnego?
!wiczenie 3.2.3. Na rysunku 3.14 przedstawiono w jzyku ODL definicj klasy klienci. W obiektach tej klasy
przechowuje si zbir rnych rodzajw telefonw (np. domowy, biurowy, fax) oraz zbir doczonych", w
ktrym klient otrzymuje kredyt przy pozyskaniu dla firmy nowych klientw. Naley przeksztaci t
specyfikacj z jzyka ODL do schematu relacyjnego bazy danych.

3.3. Od diagramw zwizkw encji do projektw relacyjnych

Przeksztacanie diagramw zwizkw encji na schemat bazy danych bardzo przypomina przeksztacanie
projektw w jzyku ODL do schematu bazy danych. Jednake w pewnym sensie model zwizkw encji stanowi
posta poredni midzy projektami obiektowym a relacyjnym. Oznacza to, e gdy dysponujemy modelem
zwizkw encji, to unikamy czci cikiego trudu. Dwie istotne rnice polegaj na tym, e:
W modelu zwizkw encji zwizki s wyodrbnione jako samoistne pojcie, a nie s elementem skadowym
pojcia klasy. Ta rnica pozwala unikn redundancji pewnego rodzaju, ktre omawialimy w p. 3.2.2, kiedy
zdecydowalimy, eby wczy zwizek wielowartociowy, taki jak gwiazdy, do krotek reprezentujcych
obiekty klasy Film.
2. W modelu ODL dla atrybutw mona okrela zoony typ, np. <set>. Modele zwizkw encji maj bardziej
wywaony charakter i mimo e wartoci strukturalne s w nich zasadniczo dopuszczalne, to nie s to ani
wartoci typu Set, ani inne konstruktory typu kolekcji'. Wskutek tego atrybut, ktrego wartoci maj posta
zbioru elementw, takie jak np. zbir adresw gwiazdy omawiany w przykadzie 3.4, zmusza projektanta do
tego, aby w modelu zwizkw encji zbir adresw okrela jako zbir encji oraz utworzy zwizek Mieszkaw, ktry wie gwiazd z jej adresami.
3. W modelu zwizkw encji mona okrela atrybuty zwizkw. W modelu ODL nie istnieje rwnowane
pojcie.
.lednak istniej takie definicje formalizmu zwizkw encji, w ktrych typy atrybutw traktuje siF
podobnie jak w j~zyku ODL: dopuszcza si tam i zbiory i kolekcje lub jeszcze prostsze typy.
132

3.3.1. Od zbiorw encji do relacji

3. RELACYJNY MODEL DANYCH

Na pocztku rozwamy zbiory encji, ktre nie s sabe. Modyfikacje, ktre s potrzebne do przeksztacenia
sabych zwizkw encji, wprowadzimy w p. 3.3.3. Dla kadego zbioru encji, ktry nie jest saby, utworzymy
relacj o takiej samej nazwie i z takim samym zbiorem atrybutw. W tej relacji nie bdzie adirych danych
dotyczcych zwizkw, w ktrych dany zbir uczestniczy. Zwizki zostan zdefiniowane przez osobne relacje,
omwimy to zagadnienie w p. 3.3.2.
PRZYKAD 3.1 U
Rozwamy trzy zbiory encji: Filmy, Gwiazdy oraz Studia z rys. 2.8, ktry odtwarzamy na rys. 3.15. Atrybutami
zbioru encji Filmy s: tytu, rok, dugo oraz typFilmu. Zatem relacja Filmy wyglda zupenie tak samo jak
relacja Film z rys. 3.1, ktrym rozpoczlimy podrozdzia 3.1.
tytu ) ( rok ) ~nazwiskoJ ( adres
Filmy Gwiazdy-w~ ~ Gwiazdy
dugo ~ typFilmu
nazwa
Posiada
Studia
adres
RYSUNEK 3.15
Diagram E/R bazy danych filmw
O
PRZYKAD 3.11
A teraz rozwamy zbir encji Gwiazdy z rys. 3.15. Tutaj wystpuj dwa atrybuty: nazwisko i adres. A wic
odpowiednia relacja mogaby wyglda nastpujco:
3.3. OD DIAGRAMW ZWIZKW ENCJI DO PROJEKTW RELACYJNYCH 133

nazwisko adres
Carrie Fisher 123 Maple St., Hollywood Mark Hamill 456 Oak Rd., Brentwood
Harrison Ford 789 Palm Dr, Beverly Hills
Ta relacja przypomina relacj Gwiazda z rys. 3.6, ktr utworzylimy w przykadzie 3.3. Jednak miaa ona trzy
atrybuty, dwa z nich: ulica i miasto reprezentoway struktur adresu. Rnica jest niewielka. Moglibymy

rwnie dobrze zaprojektowa nasz diagram zwizkw encji z rys. 2.8 tak, aby zbir encji Gwiazdy mia osobne
atrybuty ulica i miasto, co uczynioby relacj Gwiazdy identycznz relacjGwiazda z rys. 3.6.
0

3.3.2. Od zwizkw encji do relacji

Zwizki z diagramw encji take przyjmuj posta relacji. Relacja danego zwizku R ma nastpujce
atrybuty:
1. Dla kadego zbioru encji uczestniczcego w R umieszczamy w schemacie relacji odpowiadajcej R klucze
tych zbiorw jako atrybuty tej relacj i.
2. Jeli zwizek ma wasny klucz, to te doczamy jego atrybuty do zbioru atrybutw relacji.
Jeli zbir encji uczestniczy w zwizku wielokrotnie, to musimy przemianowa atrybuty po to, by unikn
konfliktu nazw. Podobnie, jeli zdarzy si, e te same atrybuty musz wystpi w relacji R, jako jej wasne
atrybuty oraz jako pochodzce ze zbioru uczestniczcego w zwizku, to te nie mona dopuci do powtarzania
si nazw i trzeba dokona przemianowania.
PRZYKAD 3.12
Rozwamy zwizek Posiada z rys. 3.15. Ten zwizek czy ze sob zbiory Filmy i studia. W schemacie relacji
Posiada korzystamy z klucza dla Filmw, czyli atrybutw tytu i rok, oraz z klucza do studiw, ktrym jest
nazwa. Poniej przedstawiamy schemat relacji:
tui
rok
nazwaStudia
Gwiezdne Wojny
1977
Fox
Potne Kaczory
1991
Disney
wiat Wayne'a
1992
Paramount
Atrybut nazwa z relacji studia nazwalimy tutaj nazwaStudia, aby schemat byk bardziej zrozumiay.
134 3. RELACYJNY MODEL DANYCH

Zauwamy, e powyszy zwizek oraz zwizek z przykadu 3.10, ktry utworzylimy dla zbioru encji
Filmy (przedstawiony na rys. 3.1), zawieraj dokadnie te same dane, ktre zawiera zwizek z rys. 3.12,
utworzony w przykadzie 3.6 dla klasy Film, jedynie z pominiciem waciwoci gwiazdy.
0
PRZYKAD 3.13
Postpujc w podobny sposb, mona przeksztaci zwizek Gwiazdy-w z rys. 3.15 do postaci relacji z
atrybutami tytu oraz rok (klucz Filmu) oraz z atrybutem nazwiskoGwiazdy, ktry stanowi klucz do zbioru encji
Gwiazdy. Na rysunku 3.16 pokazano przykad relacji Gwiazdy-w. Zauwamy, e ta relacja oraz rys. 3.16
zawieraj te same dane co rys. 3.13, nie obejmuj one tylko tych atrybutw klasy Gwiazda, ktre nie wchodz w
skad klucza (atrybutw dugo i typFilmu), umieszczone na rys. 3.13.
tytu I rok I nazwiskoGwiazdy
Gwiezdne Wojny Gwiezdne Wojny Gwiezdne Wojny Potne Kaczory wiat Wayne'a
wiat Wayne'a
RYSUNEK 3.16
Relacja zwizku Gwiazdy-w
1977
Carrie Fisher
1977
Mark Hamill
1977
Harrison Ford
1991
Emilio Estevez
1992
Dana Carvey
1992
Mike Meyers
Moe si wydawa, e na rys. 3.16 atrybut rok jest redundancyjny. Ale wynika to tylko z faktu, e w tym
przykadzie nazwy filmw nie powtarzaj si. Gdyby tam wystpowao kilka filmw o tym samym tytule, np.
King Kong", to rok byby istotny na przykad do rozstrzygnicia, ktre gwiazdy wystpujca ktrej wersji
filmu.
0
Zobaczmy, jakie s zalety schematu bazy danych, ktry otrzymamy, zaczynajc od modelu zwizkw encji
w porwnaniu ze schematem bazy przeksztaconym z modelu ODL.
Relacje czciej wystpuj w postaci znormalizowanej III klasy, co oznacza, e zawieraj mniej
redundancji ni przy bezporedniej transformacji z opisu ODL.
Dwukierunkowy zwizek w modelu ODL zostaje zastpiony pojedyncz relacj, ktra odzwierciedla
zwizek w obu kierunkach.
PRZYKAD 3.14

Rwnie
zwizki
wieloargumentowe
mona
w
atwy
Rozwamy'czteroargumentowy zwizek Kontrakty z rys. 2.12, po

sposb

przeksztaci

relacje.

3.3. OD DIAGRAMW ZWIZKW ENCJI DO PROJEKTW RELACYJNYCH I 3 S

wtrzony na rys. 3.17, ktry obejmuje gwiazd, film i dwa studia, pierwsze utrzymujce kontrakt z gwiazd i
drugie, ktre pozyskuje gwiazd do udziau w konkretnym filmie. Zwizek ten jest reprezentowany przez
relacj Kontrakty, ktrej schemat skada si z atrybutw czterech nastpujcych kluczy dla czterech zbiorw
encji:
1. Klucz nazwiskoGwiazdy dla zbioru gwiazd.
2. Klucz zoony z atrybutw tytu oraz rok dla filmu.
3. Klucz studioGwiazdy wskazujcy nazw pierwszego studia, jak pamitamy przyjlimy zaoenie, e nazwa
studio jest kluczem zbioru encji studio.
4. Klucz studioProducenta, ktry stanowi nazw tego studia, ktre produkuje film z udziaem gwiazdy.
RYSLIN>JK 3.17 Zwizek Kontrakty
Od ODL do relacji
Jak ju wspomnielimy, w wyniku przeksztalcenia zwizku z modelu zwizkw encji do schematu relacji
czasami otrzymujemy lepszy schemat relacyjny bazy danych ni w sytuacjach, gdy przeksztacamy zwizki w
ODL do postaci relacji. Jednake nic nie stoi na przeszkodzie, aby z modeli zwizkw encji zapoyczy
technik wydzielania w osobn relacj zwizkw typu wiele do jeden albo wiele do wiele. Pozwoli to wyeliminowa redundancj oraz mnoenie si liczby encji, co dzieje si czasami przy prbach implementowania
zwizku wielowartociowego w jzyku ODL przez definiujce go klasy. Poza tym przypomnijmy ponownie, e
w podrozdziale 3.7 bdzie mona pozna automatyczny sposb naprawienia schematu relacji, otrzymanego
bezporednio z opisu w jzyku ODL.

136
3. RELACYJNY MODEL DANYCIi

Nazwy atrybutw wprowadzonych do relacji zostay uwanie wybrane, poniewa,jeli jak dotychczas
uywalibymy okrelenia nazwa", to nie byoby jak odrni, czy chodzi o nazw studia producenta, czy o
studio gwiazdy.
0

3.3.3. Zasady postpowania ze sabymi zbiorami encj i

Jeli w diagramie zwizkw encji wystpuje saby zbir encji, to trzeba przestrzega trzech rnych zasad:
1. Relacja odpowiadajca sabemu zbiorowi encji W musi zawiera nie tylko atrybuty W, ale take te atrybuty
kluczy z innych zbiorw encji, ktre wchodz w skad zbioru W. Te wspomagajce zbiory encji s atwe do
rozpoznania, poniewa uczestnicz wraz z W w zwizkach wiele do jeden, a te zwizki z kolei w diagramie
s oznaczone podwjnym rombem.
2. Kady zwizek, ktry obejmuje saby zbir encji W, musi korzysta ze wszystkich atrybutw klucza W,
wczajc w to klucze W pochodzce z innych zbiorw encji, ktre uczestniczca Yt'.
3. Jednake, jak si przekonamy pniej, zwizki oznaczane podwjnym rombem, ktre istniej po to, aby
udostpni dla zbioru W atrybuty klucza z waciwych zbiorw encji, wcale nie musz by przeksztacone w
osobn relacj. Atrybuty tych zwizkw zawsze bd bowiem stanowi podzbir sabego zbioru encji W, a
tego typu zwizki nie dostarczaj poza tym adnych innych danych, ich jedyna funkcja polega na
odnalezieniu waciwego klucza dla W

Oczywicie, przy wprowadzaniu do sabego zbioru encji tych dodatkowych atrybutw trzeba
zachowa ostrono i nie dopuci do tego, aby jaka nazwa wystpia dwukrotnie. Jeli jest to
konieczne, to cz atrybutw, lub nawet wszystkie, trzeba przemianowa.
numer ) ( nazwa ) ( adres
Zespoy --~ednostka-~~ Studia
RYSUNEK 3.18
Zespoy jako przykad sabego zbioru encji
3.3. OD DIAGRAMW ZWIZKW ENCJI DO PROJEKTW RELACYJNYCH I 37

PRZYKAD 3.15
Rozwamy saby zbir encji Zespo~y z rys. 2.27, ktry zamiecilimy ponownie na rys. 3.18. Z tego
diagramu tworzymy trzy relacje o nastpujcych schematach:
Studia (nazwa, adr) Zespoy (numer, nazwaStudia) Jednostka-w(numer,
nazwaStudia, nazwa)
Pierwsza relacja Studia jest wynikiem najprostszego przeksztacenia ze zbioru encji o takiej samej nazwie.
Druga relacja zespoy jest odpowiednikiem sabego zbioru encji Zespoy. Atrybutami tej relacji s atrybuty
klucza zbioru Zespoly. Jeli istniayby w tym zbiorze jeszcze inne atrybuty, to trzeba by je doczy rwnie do
schematu tej relacji. Atrybut w relacji zespoy o nazwie nazwastudia stanowi odpowiednik atrybutu nazwa w
zbiorze eneji Studia.
Trzecia relacja Jednostka-w powstaje ze zwizku o takiej samej nazwie. Jak we wszystkich przypadkach,
tak i tu zwizek eneji reprezentujemy w modelu relacyjnym relacj, ktrej schemat zawiera atrybuty kluczy
wszystkich zbiorw encji objtych oryginalnym zwizkiem. W rozwaanym przypadku relacja Jednostka-w
zawiera atrybuty numer oraz nazwaStudia, ktre s kluczem sabego zbioru encji Zespoy oraz atrybut nazwa,
ktry jest kluczem zbioru encji Stadia. Zauwamy jednak, e studio o kluczu nazwastudia jest tym samym
studiem, ktrego kluczem jest nazwa, poniewa ,jednostka-w jest zwizkiem wiele do jeden.
Zamy na przykad, e Disney #3 oznacza jeden z zespow w studio Disneya. Zatem w zbiorze zwizku
Jednostka-w wystpuje para
(Disney #3, Disney)
Para ta w krotce relacji Jednostka-w bdzie reprezentowana nastpujco:
(3, Disney, Disney)
W konsekwencji moemy w relacji Jednostka-w poczy atrybuty nazwastudia i nazwa, co da prostszy
schemat:
Jednostka-w(numer, nazwa)
A teraz wida ju, e mona cakiem pomin relacj Jednostka-w, poniewa jej atrybuty spodzbiorem
atrybutw relacji zespoy.
0
PRZYKAD 3.16
Rozwamy teraz saby zbir encji kontrakty z przykadu 2.31 i rys. 2.28 z p. 2.6.1. Powtarzamy ten diagram na
rys. 3.19. Poniej zamieszczamy schemat relacji Kontrakty:
138
3. RELACYJNY MODEL DANYCH

Kontrakty(nazwaGwiazdy, nazwaStudia, tytu, rok, wynagrodzenie)

Atrybuty pochodz z waciwie przemianowanych atrybutw klucza Gwiazd, klucza Studiw, rwnie
przemianowanych, dwch atrybutw, ktre stanowi klucz Filmw oraz samotnego atrybutu wynagrodzenie
nalecego tylko do zbioru Kontrakty. Nie tworzy si relacji, ktre odpowiadayby zwizkom: Gwiazda-czego,
Film-w oraz Studio-w, bowiem kady ze schematw stanowiby podzbir relacji Kontrakty.
Warto zauway, e otrzymana relacja jest dokadnie taka sama, jak otrzymalibymy, rozpoczynajc od
diagramw zwizkw encji z rys. 2.13. Przypomnijmy tutaj, e na tamtym rysunku kontrakty zostay przedstawione jako zwizek trjargumentowy midzy gwiazdami, studiami i filmami, a take z atrybutem
wynagrodzenie, ktry naley do zwizku Kontrakty.
0
Zjawisko wynikajce z przykadw 3.15 i 3.16, polegajce na tym, e zwizki w rombach z podwjn
ramk nie maj odpowiadajcych im relacji, stanowi zasad dla sabych zbiorw encji. Schemat relacji
tworzonej dla ska

RYSUNEK 3.19
Saby zbir encji Kontrakty
33. OD DIAGRAMW ZWI~ZKW ENCJI DO PROJEKTW RELACY.INYCH 1 39

bego zbioru encji E zawiera schematy relacji skonstruowanych dla kadego zwizku R, oznaczanego
podwjnym rombem", ktry jest typu wiele do jeden i prowadzi od zbioru E do kadego ze zbiorw
uyczajcych E swoich atrybutw kluczy. Ta sytuacja wynika z faktu, e do relacji odpowiadajcej zbiorowi E
docza si wszystkie kluczowe atrybuty E, ktre z kolei obejmuj atrybuty kluczy pozostaych zbiorw
objtych zwizkiem R. A wic reguy dla sabych zwizkw encji mona sformuowa w nastpujcy sposb:
Jeli E jest skabym zbiorem encji, to relacja konstruowana dla zbioru E skada si z atrybutw klucza E,
wczajc te atrybuty, ktre stanowi cz kluczy wspomagajcych" zbiorw encji, polczonych z E
zwizkiem typu wiele do jeden.
Nie tworzy si relacji , ktre odpowiadayby zwizkom typu wiele do jeden, czcych saby zbir encji z
innymi zbiorami eneji, jeli te zwizki oznacza si podwjnymi rombami", dostarczajcych kluczy do sabych
zbiorw encji.

3.3.4. wiczenia do podrozdzia~u 3.3

*wiczenie 3.3.1. Naley przeksztaci diagram zwizkw encji z rys. 3.20 do postaci relacyjnego schematu
bazy danych.
rzad ) miejsce
Rezerwacje doKlienta ~ ~ doRejsu
Klienci i-itelefoni ~ Rejsy
NrKI )I adres (numer> I linia lotn
dzie
RYSUNEK 3.20
Diagram E/ R dla linii lotniczych
*wiczenie 3.3.2. Diagram zwizkw encji, przedstawiony na rys. 3.21, reprezentuje okrty. Okrty
nazywaj si siostrzanymi, jeli powstay z tych samych planw. Naley przeksztaci ten diagram do
postaci relacyjnego schematu bazy danych.
140
nazwal rokWodowania
Okrty
Okrt j \5iostrzany
Siostrzany w dla i
RYSUNEK 3.21
Diagram E/R dla okrtw siostrzanych

3. RELACYJNY MODEL DANYCH

*wiczenie 3.3.3. Nastpujce diagramy zwizkw encji naley przeksztaci do postaci relacyjnych
schematw baz danych.
a) Rysunek 2.28.
b) Odpowied do wiczenia 2.6.1.
c) Odpowied do wiczenia 2.6.4 (a). d) Odpowied do wiczenia 2.6.4(b).

3.4. Przeksztalcanie struktur podklas do postaci relacji

Pojcie podklas jest traktowane w modelach obiektowych inaczej ni w modelach zwizkw encji Ta
rnica powoduje, e w zalenoci od wyboru ktrego z tych modeli, w rny sposb organizuje si relacje,
ktre maj reprezentowa hierarchie klas. Przypomnijmy, e ju na wstpie s widoczne rnice, polegajce na
tym, e:
W modelu ODL obiekt naley do dokadnie jednej klasy. Obiekt dziedziczy waciwoci ze swoich wszystkich
nadklas, ale w sensie technicznym nie naley do adnej nadklasy.
W modelu zwizkw encji obiekt moe by reprezentowany przez encje z kilku zbiorw encji, powizanych
zwizkiem typu isa. Zatem te powizane encje wszystkie razem reprezentuj obiekt i okrelaj jego
waciwoci: atrybuty i zwizki.
Sprbujmy przeledzi, w jaki sposb te dwa pogldy wpywaj na dobr rnych strategii przy projektowaniu
relacyjnego schematu bazy danych. Warto uwiadomi sobie, e ani model ODL, ani model zwizkw encji nie
wymuszaj adnego okrelonego sposobu postpowania i jeli tylko chcemy, to zawsze moemy skorzysta z
jeszcze innych modeli.
3.4- PRZEKSZTACANIE STRUKTUR PODKLAS DO POSTACI RELACJI I4I

3.4.1. Relacyjne reprezentacje podklas z modelu ODL

Po pierwsze poznamy technik przeksztacania hierarchii podklas w modelu ODL do postaci schematu
relacyjnego. Bdziemy stosowa nastpujce reguy:
Kadej podklasie odpowiada osobna relacja.
W kadej, powstaej w ten sposb relacji, wystpuj wszystkie atrybuty oryginalnej podklasy wraz z
atrybutami dziedziczonymi.
PRZYKAD 3.17
Rozwamy hierarchi czterech klas, przedstawion na rys. 2.22. Przypomnijmy sobie ich charakterystyk:
1. Film jest najszersz klas. Byla ona ju omawiana w wielu przykladach w biecym rozdziale.
2. Kreskwka, podklasa klasy Film, ma jedn dodatkow waciwo: zwizek gosy, ktry jest zbiorem gwiazd.
3. Krymina, inna podklasa klasy Film, z dodatkowym atrybutem: bro.
4. Kreskwka-Krymina jest podklas Obu klas Kreskwka i Krymina, nie ma ju adnych podklas, ale
oczywicie wszystkie atrybuty dziedziczy z trzech uadklas.
Schemat dla klasy Fi lm jest taki sam jak poprzednio:
Film(tytu, rok, dugo, typFilmu, nazwaStudia, nazwiskoGwiazdy)
Pewne typowe krotki zostay przedstawione na rys. 3.13. Podklasa Kreskwka, poza szecioma atrybutami
dziedziczonymi z klasy Film, ma jeszcze wasny atrybut gosy, dziki czemu otrzymujemy siedmioatrybutowy
schemat:
Kreskwka (tytu, rok, dugo, typFilmu, nazwaStudia, nazwiskoGwiazdy,
gosy)
Nastpna relacja jest odpowiednikiem podklasy Krymina, gdzie poza szecioma atrybutami dziedziczonymi z
klasy Film wystpuje take atrybut bro. Zatem schemat dla relacji Krymina wyglda nastpujco:
Krymina (tytu, rok, dugo, typFilmu, nazwaStudia, nazwiskoGwiazdy,
bro)
W kocu schemat relacji powstalej dla klasy Kreskwka-Krymina obejmuje, poza szecioma atrybutami klasy
Film, dwa dodatkowe atrybuty: go
142 3. RELACYJNY MODEL DANYCH

sy i bro, ktre pochodz z pozostaych dwch nadklas. Schemat tej relacji zawiera zatem osiem atrybutw:
Kreskwka-Krymina
(tytu,
rok,
dugo,
typFilmu,
nazwaStudia,
nazwiskoGwiazdy, gosy, bro)
0

3.4.2. Reprezentowanie zwizkw isa w modelu relacyjnym

Hierarchie typu isa w modelach zwizkw encji s tworzone z encji potr czonych pewnym zwizkiem
isa. Dlatego naturalny sposb tworzenia schematu relacyjnego dla zwizku isa polega na utworzeniu osobnych
relacji dla poszczeglnych zbiorw encji, ktre uczestnicz w tym zwizku, i okreleniu atrybutw relacji przez

skopiowanie atrybutw oryginalnych zbiorw. Ale przecie jednoznaczna identyfikacja krotki wymaga
umieszczenia w kadej relacji kluczy zbiorw poczonych z ni przez zwizek isa. W rezultacie moe okaza
si, e dane o elementach niektrych podklas s umieszczane w rnych relacjach, ale to zjawisko wystpuje w
prawie kadym przypadku, poniewa kade przeksztacenie od postaci zwizkw encji do postaci relacyjnej
powoduje rozmieszczenie atrybutw encji i zwizkw pomidzy rne relacje.
Dla zwizku typu isa nie tworzy si osobnego zwizku. Jest on niejawnie zdefiniowany przez to, e w
powizanych encjach pojawiaj si te same wartoci klucza.
PRZYKAD 3.18
Sprbujmy rozpozna hierarchi zdefiniowan w modelu zwizkw encji, ktry zosta przedstawiony na rys.
3.22; jest to kopia rys. 2.23 i zawiera fragment diagramu zwizkw encji. Ten fragment diagramu mona
przeksztaci do nastpujcej postaci:
1. Relacja Filmy ( tytu, rok, dugo, typFilmu) . Byka ju opisana w przykadzie 3.10.
2. Relacja Kryminay (tytu, rok, bro) . Pierwsze dwa atrybuty tworz klucz dla wszystkich filmw, a ostatni
jest specyficzny dla odpowiadajcego tej relacji zbioru encji.
3. Relacja Kreskwki (tytu, rok). Ta relacja jest zbiorem kreskwek. Poza atrybutami klucza nie wystpuj w
niej adne inne atrybuty, ale pewne dane o kreskwkach szawarte w relacji Gosy.
4. Relacja Gosy (tytu, rck, nazwisko) stanowi odpowiednik zwizku Gosy, ktry obejmuje Gwiazdy i
Kreskwki. Atrybut nazwisko jest kluczem dla Gwiazd, a pierwsze dwa atrybuty s kluczem dla Kreskwek.
3.4. PRlEKSZTACANIE STRUKTUR PODKLAS DO POSTACI RELACJI I43

do Gwiazd
dugo ( tytu ~ (\ rok ~ ~ typFilmu
Filmy
Gosy
bro
Kreskwki

I(

Kreskwka -Krymina

RYSUNEK 3.22 Hierarchia filmw

Zauwamy, e na rys. 3.22 nie ma zbioru encji odpowiadajcego klasie Kreskwka-Krymina. Dlatego te
tutaj, inaczej ni miao to miejsce w projekcie relacyjnym opisanym w przykadzie 3.17, nie tworzy si specjalnej relacji dla filmw, ktre s jednoczenie i kreskwkami, i kryminaami. Wartoci atrybutw tych filmw,
ktre s jednoczenie kreskwkami i kryminaami mona otrzyma kolejno: gosy z relacji Gosy, bro z relacji
Kryminay, a wszystkie pozostae dane z relacji Filmy lub z tej relacji, ktra zostaa okrelona dla pewnego
zwizku, obejmujcego zbiory Filmy, Kreskwki lUb Kryminay.
Zauwamy ponadto, e schemat relacji Kreskwki stanowi podzbir schematu relacji Gosy. Z wielu
powodw byoby dobrze, gdyby relacje Giosy cakiem usun ze schematu bazy, zwaszcza e nie ma w niej
adnych innych danych poza tymi, ktre wystpuj rwnie w relacji Gosy. Ale przecie w naszej bazie danych
mog pojawi si rwnie kreskwki nieme, a dla takich kreskwek nie mona okreli wartoci atrybutu gosy.
Ten problem wystpuje rwnie w troch innej postaci w relacji Kreskwki z przykadu 3.17. Tam, jeli
postaciom kreskwki nie udzielono gosw, to nie jest ona klasyfikowana w bazie jako kreskwka. Mona t
usterk projektu usun w procesie normalizacji, o czym przekonamy si w podrozdziale 3.7.
0

3.4.3. Porwnanie rnych metod

Stosowanie dowolnej z metod, opisanych w punktach 3.4.1 i .3.4.2 moe powodowa kopoty. W
tuumaczeniu z jzyka ODL wszystkie waciwoci obiektu s przechowywane razem w jednej relacji.
Jednak przy takim podej
I ~l4 3. RELACYJNY MODEL DANYCH

ciu, jeli chcemy odszuka okrelony obiekt,.to trzeba przeszuka szereg relacji, zanim trafi si na waciw.
Jeeli na przykad chcemy odszuka czas trwania pewnego filmu, to korzystajc ze schematu z przykadu 3.17,
zanim znajdziemy waciwy film, musimy przeszuka cztery rne relacje, w ktrych umieszcza si filmy.
Przy przeksztacaniu diagramw encji natomiast trzeba dla danego obiektu w kadym zbiorze encji lub
zwizku, w ktrym pojawia si obiekt, powtrzy jego klucz. Takie powtrzenia s marnowaniem przestrzeni na
dysku. Ponadto ta metoda powoduje, e powstaje koniecznoci uzyskiwania danych o obiekcie z wielu relacji.
Taki przypadek pojawiby si w schemacie bazy danych z przykadu 3.18, gdybymy chcieli uzyska dane
jednoczenie o czasie trwania kryminau, jak i uytej tam broni.

3.4.4. Tworzenie relacji z wartociami pustymi

Jeszcze inny sposb reprezentowania danych o strukturze hierarchicznej polega na zastosowaniu pustych
wartoci, ktre oznacza si NULL. Jeli w jakiej krotce wystpuje pusta warto pewnego atrybutu, to oznacza
to nieformalnie, e w tej krotce warto tego atrybutu nie moe zosta okrelona. Mimo e wartoci puste nie
wystpuj w tradycyjnym ujciu modelu relacyjnego, to s bardzo wygodne i odgrywaj znaczc rol w jzyku
zapyta SQL, o czym przekonamy si w podrozdziale 5.9.
Jeli jednak dopucimy stosowanie w krotkach wartoci NULL, to hierarchie klas mona przedstawi w
jednej relacji. Relacja taka ma wszystkie atrybuty, ktre dotycz waciwoci obiektw z dowolnej klasy w
hierarchii. Dziki temu jeden obiekt jest opisywany w jednej krotce. Atrybuty, ktre s spoza podklasy danego
obiektu, przyjmuj w krotce wartoci NULL.
PKZYKAD 3.19
Gdybymy zastosowali ten sposb do rozwizania problemu z przykadu 3.17, to otrzymalibymy jednrelacj,
o nastpujcym schemacie:
Film (tytu, rok, dugo, typFilmu, nazwaStudia, nazwiskoGwiazdy, gos,
bro)
Filmy takie jak na przykad Kto zabi krlika Rogera?, ktre s zarwno kreskwkami, jak i kryminaami,
byyby tu reprezentowane jako kilka krotek, w ktrych nie pojawia si warto pusta, bowiem dla kadego gosu
musiaaby istnie osobna krotka". Natomiast taki film jak Mala Syrenka, ktry jest
" W rzeczywistoci, poniewa w filmie o Krliku Rogerze wystpuj nie tylko gosy gwiazd, lecz
rwnie same gwiazdy, wic dla kadj pary (gwiazda, gos) musiaaby w relacji pojawi si odrbna
krotka. Film, ktry jest czyst kreskwk, miaby przypisan warto pust dla atrybutu
nazwisxocwiazdy, a gosy i inne dane byyby podane.
3,4. PRZEKSZTACANIE STRUKTUR PODKLAS DO POSTACI RELACJI I ~1S

kreskwk, ale nie jest kryminaem, miaby przypisan warto NULL do atrybutu bro. Film Orient Ekspres miaby
okrelon warto NULZa dla atrybutu gosy, podczas gdy dla Przemin~o z wiatrem warto NULL pojawiaby si zarwno
w polu atrybutu gos, jak i bro.
0
Zauwamy, e w wyniku zastosowania tego podejcia, tak samo jak w przypadku metody opisanej w p. 3.4.2, w jednej
relacji wystpujwszystkie krotki z wszystkich klas tworzcych hierarchi. Ponadto, podobnie jak przy uyciu sposobu
przedstawionego w p. 3.4.1, moemy wszystkie dane o obiekcie odnale w jednej relacji.

3.4.5. wiczenia do podrozdzia~u 3.4

wiczenie 3.4.1. Naley przeksztaci diagram zwizkw encji przedstawiony na rys. 3.23 do postaci relacyjnego schematu
bazy danych.
numer ~ ~ nazwa
sala Wykady`Wykad-~~ Wydziay Knn /n
Zajcia (komputery laboratoryjne ~
RYSUNEK 3.23
Diagram EIR dla ewiczenia 3.4.1
wiczenie 3.4.2. Na rysunku 3.24 przedstawiono w jzyku ODL opis schematu, ktry przypomina diagram zwizkw encji z
wiczenia 3.4.1. Trzeba ten opis przeksztaci do postaci relacyjnego schematu bazy danych. Naley przy tym pamita, e
obiekt Wykad ma identyfikator obiektu" i mona w zwizku z tym wprowadzi wasny atrybut odpowiadajcy temu
identyfikatorowi, np. idWykadu. Nie trzeba jednak tutaj stosowa strategii przeksztalcania sabych zbiorw eneji, ktr
opisywalimy przy okazji wiczenia 3.4.1 (chyba e kto koniecznie chce).
interface Wykad(
attribute int numer; attribute string sala;
146 3. RELACYJNY MODEL DANYCH
relationship Wydzia WydziaCzego inverse Wydzia:: WykadyCzego;
interface ZajciaLab: Wykad attribute int komputery; };
interface Wydzia(
unique attribute string nazwa; attribute string katedra; relationship Set<Wykad>
WykadyCzego
inverse Wykad::WydziaCzego; };
RYSUNEK 3.24
Opis w jzyku ODL wykadw oraz zj laboratoryjnych
RYSUNEK 3.25

Diagram E /R do wiczenia 3.4.E

3.5. ZALENOCI FONKCYJNE 147

wiczenie 3.4.3. Naley utworzy relacyjne schematy bazy danych na podstawie opisw w jzyku ODL, ktre
powstay w nastpujcych wiczeniach:
*a) wiczenie 2.4.1, b) wiczenie 2.4.4.
wiczenie 3.4.4. Naley utworzy relacyjne schematy bazy danych na podstawie diagramw zwizkw encji,
ktre powstay w nastpujcych wiczeniach:
*a) wiczenie 2.4.3, b) wiczenie 2.4.4.
!wiczenie 3.4.5. Naley przeksztaci diagram zwizkw encji z rys. 3.25 do postaci relacyjnego schematu
bazy danych.
!wiczenie 3.4.6. Jak zmieniby si relacyjny schemat bazy danych z wiczenia 3.4.5, gdybymy go utworzyli
na podstawie definicji w jzyku ODL.

3.5. Zalenoci funkcyjne

Najwaniejszy rodzaj wizw, z jakim mamy do czynienia w modelu relacyjnym, dotyczy wizw
jednoznacznoci, ktre nazywa si rwnie zalenoci funkcyjn". Wiedza dotyczca tych wizw jest
nieodzowna w przypadku powtrnego definiowania schematu relacyjnego w celu wyeliminowania z niego
redundancji. Te procedury opisujemy dokadnie w podrozdziale 3.7. Poza tym istniej jeszcze inne wizy, ktre
wspomagaj opracowanie dobrego schematu bazy danych: np. zalenoci wielowartociowe, o ktrych jest
mowa w podrozdziale 3.8, oraz zalenoci istnienia i niezalenoci, ktre bd omwione w podrozdziale 4.5.

3.5.1. Definicja zalenoci funkcyjnych

Zalenocic~ funkcyjna w relacji R bdziemy nazywa zdanie nastpujcej postaci: Jeli dwie krotki
relacji R s zgodne dla atrybutw A,, AZ, ... A (tzn. obie krotki maja takie same wartoci skadowych dla
wymienionych atrybutw), to musz by rwnie zgodne w pewnym innym atrybucie B". Taki rodzaj
zalenoci zapisujemy formalnie w postaci AI Az ... An --> B, a odczytujemyten zapis jako: A,, Az, ..., An
okrelaj funkcyjnie B".
Jeli zbir atrybutw AI, Az, ..., An okrela funkcyjnie wicej ni jeden atrybut, tzn. na przykad
A,AZ...A--FBI A, AZ ... An -- Bz
AIAZ...A-->B,n
14 3. RELACYJNY MODEL DANYCH

to taki zbir zalenoci skrtowo przedstawiamy jako:

A~AZ...A~,--B,BZ...B, Na rysunku 3.26 schematycznie przedstawiono zaleno funkcyjn w relacji R

oraz jej znaczenie dla dwch krotek tej relacji: t oraz u.
-- B

t~ i

r ,

iiiiii
iiii
U i i

Jeli t i u To musz s by take zgodne tu zgodne tu RYSUNEK 3.26

Wynik zalenoci funkcyjnej dwch krotek
tytul
rok
dlugo typFilmu nazwaStudia
nazwiskoGwiazdy
Gwiezdne
1977
124
kolor
Fox
Carrie
Wojny
Fisher
Gwiezdne
1977
124
kolor
Fox
Mark
Wojny
Hamill
Gwiezdne
1977
124
kolor
Fox
Harrison
Wojny
Ford
Potne
1991
104
kolor
Disney
Emilio
Kaczory
Estevez
wiat
1992
95
kolor
Paramount
Dana
Wayne'a
Carvey
wiat
1992
95
kolor
Paramount
Mike
Wayne'a
Meyers
RYSUNEK 3.27 Relacja Film
YRZYK.AD 3.20
Rozwamy relacj Film z rys. 3.13, ktrej instancj prezentujemy na rys. 3.27. W relacji Film w atwy sposb
mona wyodrbni kilka zalenoci funkcyjnych. Na przykad mog to by nastpujce trzy zalenoci:
3.5. ZALENOCI FUNKCYJNE I X19

tytu rok - dugo tytu rok --> typFilmu tytu rok -~ nazwaStudia
Poniewa te wszystkie trzy zalenoci maj te same atrybuty po lewej stronie, zatem moemy je skrtowo
zapisa w nastpujcy sposb:
tytu rok -- dugo typFilmu nazwaStudia
Powyszy zbir zalenoci funkcyjnych mona odczyta w nieformalny sposb nastpujco: jeli dwie
krotki maj takie same wartoci skkadowej tytu, a take takie same wartoci skadowej rok, to te dwie krotki
musz mie rwnie takie same wartoci skadowej dugo, takie same waaoci skadowej typFilmu oraz takie
same wartoci skadowej nazwastudia. Takie stwierdzenie nabiera sensu, gdy przypomnimy sobie projekt
pocztkowy, z ktrego utworzylimy schemat relacji Film. Atrybuty tytu i rok tworz klucz relacji. Dlatego te
mona si spodziewa, e przy konkretnym tytule i roku musi istnie jedna okrelona dugo filmu, jeden typ
filmu oraz jedyne studio, ktre ten film wyprodukowao.
Wnioski na temat schematu na podstawie zalenaci funkcyjnych Nie zapominajmy o tym, e zalenoci
funkcyjne, tak jak kade inne wizy, dotycz schematu bazy, a nie okrelonej instancji. Patrzc na jak instancj, nigdy nie moemy twierdzi, e na pewno istniej jakie zalenoci funkcyjne, albo e ich nie ma.
Patrzc na przykad na rys. 3.27, moglibymy wysnu wniosek, e wystpuje z aleno tytu --> typFilmu,
poniewa w kadej krotee akurat tej instancji relacji Film zachodzi to, e jeli dwie krotki majten sam tytui, to
zgadza si rwnie typFilmu.
Nie moemy jednak stwierdza na tej podstawie, e jest to zaleno funkcyjna w relacji Film. Gdyby na
przykad jaka instancja zawieraa krotki opisujce obie wersje King Konga, z ktrych jedna jest czarno-biaa, a
druga kolorowa, to nasze wczeniejsze stwierdzenie zostaoby obalone.
Jednake przy bliszej obserwacji wida, e zdanie
tytu rok -- nazwiskoGwiazdy
jest faszywe, nie okrela ono bowiem zalenoci funkcyjnej. Moglimy oczekiwa, e poniewa atrybuty tytu i
rok s kluczem dla filmw, to taka zaleno musi by prawdziwa. Jednak film nie ma jednoznacznie okrelone-

go zbioru gwiazd, ze wzgldu na sposb w jaki bya zdefiniowana klasa Film. Przy przeksztacaniu opisu w
jzyku ODL do postaci modelu relacyjnego trzeba byo dla kadego filmu utworzy szereg' krotek, po jednej dla
I S O 3. RELACY.INY MODEL DANYCH

kadej gwiazdy, ktra wystpia w tym filmie. Dlatego te, mimo e wszystkie krotki s zgodne dla pozostaych
atrybutw, to nie s zgodne w przypadku nazwiska gwiazdy.
0

3 .5 .2. Klucze relacj i

Mwimy, e atrybut, lub zbir atrybutw {AI, Az , ..., A} tworzy klucz relacji, jeli:
1. Wszystkie pozostae atrybuty relacji s funkcyjnie zalene od tych atrybutw. A zatem nie moe si zdarzy,
aby dwie rne krotki relacji R byy zgodne dla wszystkich atrybutw AI, AZ, ..., A.
2. Nie istnieje taki podzbir waciwy zbioru {A,, Agi, ..., An}, od ktrego pozostale atrybuty relacji R szalene
funkcyjnie, tzn. klucz musi by minimalny.
Jeli klucz skada si tylko z jednego atrybutu A, to mwimy, e A (nie {A}) jest kluczem.
PRZYKAD 3.21
Atrybuty {tytu, rok, nazwiskoGwiazdy} tworz klucz relacje Film, ktra zostaa przedstawiona na rys. 3.27.
Przede wszystkim trzeba wykaza, e wszystkie pozostae atrybuty w relacji Film s od nich zalene funkcyjnie.
Zamy wic, e dwie krotki s zgodne dla tych trzech atrybutw: tytu, rok i nazwiskoGwiazdy. Ze wzgldu
na to, e s zgodne dla atrybutw tytu i rok, musz by rwnie zgodne dla pozostaych atrybutw: dugo,
typFilmu oraz nazwastudia; wykazano to ju w przykkadzie 3.20. A wic dwie rne krotki nie mog by
zgodne dla wszystkich atrybutw tytu, rok i nazwi s koGwia zdy, musz by w takim przypadku t sam
krotk.
Teraz trzeba wykaza, e aden z podzbiorw waciwych zbioru { tytu, rok, nazwiskoGwiazdy} nie
wyznacza pozostaych atrybutw w sposb zaleny funkcyjnie. Na pocztku zauwamy, e atrybut nazwisko Gwiazdy nie zaley funkcyjnie od atrybutw tytu i rok, poniewa przewanie w filmach wystpuje wiele
gwiazd. Zatem para {tytu, rok) nie stanowi klucza.
Para {rok, nazwiskoGwiazdy) nie moe by kluczem, poniewa w danym roku gwiazda moe wystpi w
wielu filmach. A zatem
rok nazwiskoGwiazdy -- tytu
nie jest zalenoci funkcyjn. Mona take twierdzi, e {tytu, nazwiskoGwiazdy) nie stanowi klucza,
poniewa w rnych latach mog zosta
3.5. ZALENOCI FUNKCYJNE I S I

wyprodukowane dwa rne filmy o takim sarnym tytule. Moe si take zdarzy, e w obu tych filmach wystpi
ten sam aktor, mimo e szczerze mwic nie potrafimy znale przykadu takiej sytuacji".
0
Czasami zdarza si, e w relacji mona wskaza wicej ni jeden klucz. W komercyjnych systemach baz
danych wybr klucza gwnego moe mie wpyw na implementacj, na przykad na sposb przechowywania
relacji na dysku.
Na czym polega funkcyjno zalenoci funkcyjnych? Zaleno AI, Az, ...,An --; B nazywa si
funkcyjn", poniewa w zasadzie istnieje funkcja, ktra dla danej listy wartoci atrybutw A,, A2, ..., A
wyznacza dokadnie jedn (lub nie okrela adnej) warto atrybutu B. Dla relacji R moemy na przykad
okreli funkcj, ktra napisowi Gwiezdne wojny" oraz liczbie cakowitej 1977 przypisuje dokadnie jedn
warto dugoci, w tym przypadku liczb 124, ktra wystpuje w relacji Film. Nie moemy jedvak utosamia
takich funkcji z matematycznym pojciem funkcji, poniewa tutaj nie istniej reguy przyporzdkowywania
wartoci argumentom. Nie moemy na przykad okreli cigu operacji, ktrych przetworzenie spowodowaoby
nadanie parze zoonej z napisu Gwiezdne wojny" oraz liczby 1977, waciwej dugoci. Wartoci funkcji s w
tym przypadku okrelane w wyniku przeszukiwania relacji. Poszukujemy krotki o podanych wartociach tytu i
rok i w tej krotce odczytujemy warto skadowej dugo.

3.5.3. Nadklucze
Zbir atrybutw, ktry zawiera klucz nazywa si uadkluczem, co jest skrtem od pojcia nadzbioru
klucza". A wic kady klucz jest rwnie nadkluczem. Jednake istniej nadklucze, ktre same nie s kluczami
(minimalnymi). Zauwamy, e kady nadklucz spenia pierwszy warunek bycia kluczem, wszystkie atrybuty
relacji s bowiem od niego zalene funkcyjnie. Jednake najczciej nadklucz nie spenia warunku
minimalnoci.
PRZYKAD 3.22
W relacji z przykadu 3.21 mona okreli wiele nadkluczy. Nie tylko sam klucz

' Przypomnijmy, e zalenoci funkcyjne wynikj z moliwych do przyjcia zaoe lub uzgodnie
dotyczcych danych. Nie istnieje aden autorytet zewntrzny, ktry mgby rozstrzygn z absolutn
pewnoci, czy dana zaleno funkcyjna zachodzi, czy te nie. Std te naley przyjmowa takie zaoenia,
ktre wydjsi njbardziej odpowiednie.
152
{tytu, rok, nazwiskoGwiazdy}
3. RELACYJNY MODEL DANYCI

jest nadkluczem, ale kady jego nadzbir, jak na przykad

{tytu, rok, nazwiskoGwiazdy, dugo}
take jest nadkluczem.
0

3.5.4. Wykrywanie kluczy w relacji

Jeli schemat relacji otrzymuje si z przeksztacenia projektu zapisanego w jzyku ODL lub w modelu
zwizkw encji, to klucz jest zazwyczaj atwy do przewidzenia. Obecnie rozwaymy relacje powstae na
podstawie diagramu zwizkw encji, z kolei w p. 3.5.5 omwimy te sytuacje, kiedy relacja powstaje w wyniku
przeksztacania projektu opisanego w jzyku ODL.
Jeli relacja pochodzi z projektu w jzyku ODL lub zwizkw encji, to prawie na pewno (ale nie w stu
procentach) wiadomo, e istnieje w niej tylko jeden klucz. Uyteczna konwencja nakazuje w schemacie relacji
taki jedyny klucz oznacza podkreleniem atrybutw wchodzcych w jego skad.
Pierwsza regua wyodrbniania klucza moe brzmie zatem nastpujco:
Jeli relacja pochodzi z przeksztacenia zbioru encji, to jej kluczem satrybuty kluczowe tego zbioru encji lub
klasy.
Alternatywna terminologia kluczy
W niektrych ksikach lub opracowaniach mona zetkn si z innymi terminami dotyczcymi kluczy. Mona
na przykad napotka termin klucz" uywany w znaczeniu, ktre my przypisalimy pojciu nadklu cza", tzn.
jako okrelenie kadego zbioru atrybutw, od ktrego wszystkie inne s zalene funkcyjnie, bez wymagania
minimalnoci tego zbioru. W tych rdach mona take napotka okrelenie minimalnego klucza jako klucz
kandydacki", co odpowiada pojciu klucza" w tym znaczeniu, ktre my przyjmujemy za waciwe.
PRZYKAD 3.23
W przykadach 3.10 oraz 3.11 opisalimy sposoby przeksztacenia zbiorw encji Filmy i Gwiazdy do postaci
relacji. Kluczami w tych zbiorach byy odpowiednio {tytul, rok} oraz {nazwisko}. Stay si one kluczami relacji
odpowiadajcych tym zbiorom, a schematy powstaych relacji przyjy nastpujc posta:
3.5. ZALENOCI FUNKCYJNE S3

Filmy (tytu, rok, dugo, typFilmu) Gwiazdy (nazwisko, adres)

Klucze relacji oznaczono przez podkrelenie waciwych atrybutw.
0
Druga regua dotyczy zwizkw binarnych. Jeli relacja R powstaje ze zwizku, to liczba argumentw
zwizku ma wpyw na wybr klucza R. Mona wyrni trzy przypadki:
Jeli zwizek jest typu wiele do wiele, to klucze obu zbiorw encji objtych zwizkiem tworz zbir atrybutw
klucza R.
Jeli zwizek ze zbioru encji E, do zbioru encji Ez jest typu wiele do jeden, to atrybuty klucza E, staj si
kluczem R, ale atrybuty klucza EZ nie wchodzdo klucza relacji R.
Jeli zwizek jest typu jeden do jeden, to atrybuty klucza ktregokolwiek ze zbiorw mog by kluczem R. W
tym przypadku nie ma zatem jednego tylko klucza.
PRZYKAD 3.24
W przykadzie 3.12 omwiono zwizek Posiada, ktry jest typu wiele do jeden i prowadzi ze zbioru encji Filmy
do zbioru encji Studia. Zatem, zgodnie z nasz regu, kluczem relacji Posiada s atrybuty kluczowe: tytu oraz
rok z klucza dla Filmw. Schemat relacji Posiada mona przedstawi nastpujco:
Posiada( tytu, rok, nazwaStudia)
Atrybuty klucza zostay oznaczone podkreleniem.
W przykadzie 3.13 omwiono inny zwizek Gwiazdy-w, ktry zachodzi midzy zbiorami Filmy i
Gwiazdy i jest typu wiele do wiele. Tym razem wszystkie atrybuty zwizku musza wej w skad klucza
powstajcej relacji:
Gwiazdy-w(tytu, rok, nazwiskoGwiazdy)
Jedyny praktyczny przypadek, kiedy relacja, odpowiadajca zwizkowi wiele do wiele, ma jeszcze
inne atrybuty poza atrybutami kluczowymi, wystpuje wwczas, gdy zwizek ma jakie wasne
atrybuty. Wwczas te atrybuty nie wchodz w skad klucza.

0
Rozwamy w kocu zwizki wieloargumentowe. Poniewa nie mona w tym przypadku opisa wszystkich
zalenoci strzakami wychodzcymi ze zwizku, zatem trzeba si pogodzi z tym, ze wystpi takie sytuacje,
gdy nie
1 S4 3. RELACYJNY MODEL DANYCH

bdzie oczywiste, co jest kluczem relacji bez wnikania w to, ktre zbiory encji sfunkcyjnie zalene od innych
zbiorw encji. Moemy tylko zapewni, e:
Jeli ze zwizku wieloargumentowego R wychodzi strzaka w kierunku zbioru encji E, to dla odpowiadajcej
relacji istnieje co najmniej jeden klucz, ktry eliminuje klucz E.
Inne notacje zalenoci funkcyjnych
Wyznajemy pogld, e po lewej stronie zalenoci funkcyjnej moe wystpowa wiele atrybutw, natomiast po
prawej wystpuje dokadnie jeden. Ponadto ten atrybut, ktry wystpuje po prawej stronie zalenoci nie moe
pojawia si po lewej stronie tej samej zalenoci. Jednake dopuszczamy skrtowy zapis dla kilku zalenoci,
ktre maj takie same atrybuty z lewej strony, w postaci jednej zalenoci z praw stron otrzyman z
poczenia wszystkich prawych stron zalenoci wejciowych. Czasami rwnie bywa wygodnie dopuci
zalenoci trywialne", w ktrych praw stron stanowi jeden z atrybutw lewej strony.
W innych opracowaniach jest prezentowany pogld, e zarwno prawa, jak i lewa strona zalenoci
funkcyjnej jest zbiorem atrybutw, a te same atrybuty mog wystpowa po obu stronach jednoczenie. Midzy
tymi dwoma pogldami nie ma zbyt duej rnicy, ale w naszych rozwaaniach bdziemy utrzymywa zasad,
e aden atrybut nie pojawia si jednoczenie po obu stronach zalenoci funkcyjnej, chyba e wyranie to
zostanie stwierdzone.

3.5.5. Klucze relacji powstajcych z opisw w jzyku ODL

Sytuacja komplikuje si w przypadku, gdy projekt relacyjny powstje na podstawie opisu w jzyku ODL.
Po pierwsze w klasie ODL moe by okrelonych wiele kluczy, a moe ich nie by wcale. W takim przypadku
trzeba na wasn rk wymyli w relacji atrybut zastpujcy identyfikatory obiektw klasy, wspominalimy ju
o tym problemie w p. 3.2.6.
Jednake bez wzgldu na to, czy klasa w jzyku ODL ma wasny klucz, czy te trzeba tworzy
odpowiednik dla identyfikatora obiektw, istniejtakie okolicznoci, kiedy klucz klasy nie moe stanowi
klucza relacji. Nasz sposb przeksztalcania projektu z postaci ODL do postaci relacji powoduje bowiem, e
czasami zbyt duo danych ~unieszcza si w pojedynczej relacji. Problem ten pojawia si, gdy relacja jest
czci skadow definicji klasy.
Zamy na pocztek, e w klasie C okrelono jednowartociowy zwizek R, skierowany do
klasy D. Wwczas zgodnie ze wskazwkami z p. 3.2.4 klucz D zostaje dolczony do relacji tworzonej
dla klasy C. Klucz klasy C pozostaje nadal kluczem relacji.
3.5. ZALENOCI FUNKCYJNE 1SS

Problem pojawia si wwczas, gdy zwizek R z C do klasy D jest wielowartociowy. Jeli w kierunku
odwrotnym zwizek odwrotny do R jest jednowartociowy (zwizek R jest typu jeden do wiele), to moemy
zwizek R reprezentowa wycznie przez jego odwrotno w relacji powstajcej dla klasy D; bya o tym mowa
w ramce pt. Reprezentowanie zwizkw w jednym kierunku" w p. 3.2.7. Odwrotno zwizku R nie stwarza
problemu, poniewa w klasie D jest on jednowartociowy.
Ale zamy, e zwizek R jest typu wiele do wiele, a wiec w obu kierunkach midzy klasami C a D
zwizek ten jest wielowartociowy. Wwczas moe si zdarzy, ze w relacji tworzonej dla klasy C wystpi
wiele krotek reprezentujcych pojedynczy obiekt klasy C. A zatem klucz klasy C nie bdzie mg by kluczem
w odpowiadajcej klasie C relacji. Aby otrzyma klucz relacji odpowiadajcej klasie C, trzeba bdzie poczy
klucze klas C i D.
PRZYKAD 3.25
W przykadzie 3.7, tworzc relacj odpowiadajc klasie ODL Film, do atrybutw relacji Film do-lczylimy:
1. Klucz nazwastudia z klasy studio, z ktr klasa Film jest poczona zwizkiem jednowartociowym naleyDo
oraz
2. Klucz nazwiskoGwiazdy z klasy Gwiazda (z ktr klasa Film jest objta zwizkiem wielowartociowym
gwiazdy).
Pierwszy z nich pochodzi z jednowartociowego zwizku, a zatem nie ma wpywu na klucz relacji Film.
Jednake drugi z nich, poniewa pochodzi ze zwizku wielowartociowego, musi zosta doczony do zbioru
atrybutw klucza relacji Film, ktry przyjmuje nastpujcposta:
{tytu, rok, nazwiskoGwiazdy}.

Analiza przykadu relacji Film z rys. 3.13 stanowi potwierdzenie tego, e same atrybuty tytu i rok nie stanowi
klucza relacji Film, ale doczenie do tego zbioru atrybutu nazwiskoGwiazdy ju wystarczy do okrelenia
klucza.
0
Mwic oglniej: jeli w relacji dla klasy C trzeba reprezentowa kilka zwizkw wielowartociowych z
C, to wszystkie klucze klas, uczestniczcych w tych zwizkach wraz z klas C, trzeba doczy do pierwotnego
klucza klasy C i dopiero wwczas powstaje klucz relacji C. Jeli kilka zwizkw wielowartociowych czy
klas C z tsama klasD, to w relacji C pojawiaj si rne atrybuty reprezentujce klucz klasy D w rnych
zwizkach C i D.
Czsto zdarza si, e trzeba poprawia projekt relacji, otrzymany w wyniku postpowania zgodnego z
procedur tworzenia relacji, ktr opisano w podrozdziale 3.2, poniewa klucz klasy z ODL moe paradoksalnie
nie by
J S6 3. REI,ACY.INY MODEL DANYCH

wystarczajcy dla relacji odpowiadajcej tej klasie. Sposb postpowania w takich przypadkach zostanie przedstawiony w
podrozdziale 3,7. Okae si wwczas, e zwizek typu wiele do wiele mona rozoy midzy klasy, ktre w nim
uczestnicz. Wynikowy zbir schematw relacji jest bardzo podobny do schematw, ktre uzyskujemy bezporednio z
przeksztace diagramw zwizkw encji".

3.5.6. wiczenia do podrozdziatu 3.5

wiczenie 3.5.1. Rozwamy relacj populacji w Polsce, ktra zawiera: nazwisko, PESEL, adres, miasto, wojewdztwo, kod
pocztowy, NIP oraz numer telefonu (7 cyfr). Jakie zalenoci funkcyjne mogyby tu zachodzi? Co jest kluczem takiej
relacji? Aby odpowiedzie na te pytania, naley co wiedzie o wymienionych nume rach, Czy na przykad NIP i PESEL s
powizane ze sob? Czy kod pocztowy jest zwizany z NIPem? Czy dwie osoby mog mie taki sam PESEL? Czy mog
mie taki sam adres i numer telefonu?
*wiczenie 3.5.2. Rozwamy relacj, w ktrej zawiera si opis biecego stanu czsteczek w zamknitym pojemniku.
Atrybuty tej relacji obejmuj: identyfikator cz steczki, wsprzdne x, y, z pooenia czsteczki oraz jej prdko w
ukadzie x, y, z. Jakich zalenoci funkcyjnych mona by tu oczekiwa? Jakie s klucze?
!wiczenie 3.5.3. W wiczeniu 2.3.2 ustalilimy cztery zaoenia na temat zwizku UrocLenia. Naley okreli klucze
relacji odpowiadajcych poszczeglnym przypadkom. !!wiczenie 3.5.4. Zamy, e w relacji R wystpuj atrybuty: A,,
Agi, .,., A. Okreli liczb nadkluczy R w funkcji n, jeli:
*a) Jedynym kluczem moe by A,.
b) Kluczem moe by tylko A, lub Agi.
c) Kluczem moe by albo {A,, Az}, albo {A3, A4}. d) Kluczem moe by alba {A,, AZ}, albo }A,, A3}.

3.6. Reginy dotyczce zalenoci funkcyjnych

W biecym podrozdziale nauczymy si, w jaki sposb prowadzi wnioskowanie na temat zalenoci funkcyjnych.
Zamy, e uzyskalimy infortnacje na temat zalenoci spenianych przez relacj. Czsto, nawet bez ogl
Dlatego moglibymy projekt w jzyku ODL przeksztaci do postaci zwizkw encji, a dopiero potem
tworzy schemat relacyjny. Mimo e mona by w ten sposb rozwiza cz problemw, ktre s
charakterystyczne dla podejcia opisanego w podrozdziale 3.2, jednak nie jest to jed~ma droga. Techniki
projektowania relacyjnego opisane w podrozdziale 3.7, ktrych i tak trzeba si nauczy, s co najmniej tak samo
efektywne.
3.6. REGUY DOTYCZCE ZALENOCI FUNKCYJNYCH I S%

dania przykadw krotek, mona okreli pewne warunki, ktre musz by spenione w relacji. Moliwo
okrelenia takich warunkw jest niezbdna przy projektowaniu dobrego schematu dla relacji, co zamierzamy
omwi w podrozdziale 3.7.
PRZYKAD 3.26
Jeli wiadomo, e w relacji R z atrybutami A, B i C zachodz zwizki funkcyjne A -- B 1 B -~ C, to atwo jest
wyprowadzi wniosek, e zachodzi rwnie zaleno funkcyjna A --~ C. W jaki sposb uzasadni taki
wniosek? eby udowodni, e zachodzi zaleno A -- C musimy zanalizowa dwie krotki z R, ktre s zgodne
dla A, i uzasadni, e musz by wwczas zgodne dla C.
Zamy, e nasze dwie krotki zgodne dla A maj posta (a, bl, c,) oraz (a, b2, cZ). Przyjlimy, e
porzdek atrybutw w R okrelono jako A, B, C. Poniewa speniona jest zaleno A - B, a nasze krotki s
zgodne dla A, wic musz by rwnie zgodne dla B, Oznacza to, e b~ = bz, a wic posta naszych krotek w
rzeczywistoci jest nastpujca: (a, b, c~) i (a, b, ez), gdzie b jest rwne b~ i bz. Z kolei poniewa R spenia

take zaleno B -~ C, wic jeli krotki szgodne dla B, to srwnie zgodne dla C. A zatem c~ = cz, czyli
nasze krotki s zgodne dla C. W ten sposb wykazalimy, e kade dwie krotki relacji R, ktre s zgodne dla A,
s rwnie zgodne dla C, a zatem zachodzi zaleno funkcyjna A -- C.
0
Jeli zalenoci funkcyjne mona okreli na rne sposoby i nie ma to wpywu na instancje relacji, to
takie zalenoci nazywamy rwnowahyn~i. Jeszcze oglniejsza wkaciwo polega na tym, e zbir zalenoci
funkcyjnych S wynika ze zbioru zalenoci funkcyjnych. To oznacza, e jeli z faktu, i dowolna instancja
relacji R spenia wszystkie zalenoci w T, wynika, e spenia take wszystkie zalenoci w S. Zauwamy, e
zbiory zalenoci funkcyjnych S i T s rwnowane wtedy i tylko wtedy, kiedy z S wynika T i jednoczenie z T
wynika S.
Poznamy teraz kilka uytecznych zasad dotyczcych zalenoci funkcyjnych. Zasady te, mwic
najoglniej, pozwalaj na zastpowanie zbioru zalenoci fiu~kcyjnych zbiorami rwnowanymi lub ua
doczanie do zbioru tych zalenoci, ktre wynikaj ze zbioru pocztkowego. Widzielimy ju przykad 3.26 z
regule przechodnioci (tra~rsitive rule), ktra umoliwia przejcie przez acuch zalenoci. Poznamy take
algorytm, ktry umoliwia udzielenie odpowiedzi na pytanie o to, czy jaka zaleno funkcyjna wynika z
jednej lub wicej zalenoci.

3.6.1. Zasady podziau i czenia

W punkcie 3.5.1 okrelilimy zaleno funkcyjn:
A,, Agi, ..., A -~ B1B2 ... B,
158
3. RELACYJNY MODEL DANYCH

jako skrtowy zapis zbioru zalenoci nastpujcej postaci:

A~, Az, ..., A -> B, A,, Az, ..., A --~ Bz
A,, Az, ..., An -~ Bm
a zatem moemy podzieli atrybuty z prawej strony w ten sposb, e w jednej zalenoci funkcyjnej po prawej
stronie wystpuje dokadnie jeden atrybut. W podobny sposb moemy zastpi cig zalenoci funkcyjnych o
identycznych lewych stronach przez jedn zaleno, czc atrybuty prawych stron tych zalenoci. W kadym
z tych dwch przypadkw nowy zbir zalenoci jest rwnowany poprzedniemu. Zapisana wyej
rwnowano moe by stosowana na dwa sposoby.
Zaleno funkcyjn A~Az ... A --~ B1Bz ... B, moemy zastpi zbiorem zalenoci funkcyjnych A~Az ...
A --> B;, gdzie i = 1, 2, ..., m. T zasad nazywamy reguci podzialu (spliting rule).
Zbir zalenoci funkcyjnych A~Az ... A --> B;, gdzie i = 1, 2, ..., m moemy zastpi pojedyncz
zalenoci funkcyjn A~Az ... A B~Bz ... B,. Takie przeksztacenie nazywamy regulct lczenia (combining rule).
W przykadzie 3.20 pokazalimy, e zbir zalenoci funkcyjnych:
tytu rok -~ dugo tytu rok -~ typFilmu tytu rok --> nazwaStudia
jest rwnowany pojedynczej zalenoci
tytu rok ---> dugo typFilmu nazwaStudia
Mona by sobie wyobrazi, e analogiczna regua podziau mogaby dotyczy lewych stron zalenoci.
Jednak nie jest to prawd, co wida na poniszym przykadzie.
PRZYKAD 3.27
Rozwamy jednz zalenoci okrelonych w relacji Film, na przykad:
tytu rok ~ dugo
Jeli lew stron sprbujemy podzieli, to w wyniku otrzymamy dwie nastpujce zalenoci:
3.6. REGUY DOTYCZCE ZALENOCI FUNKCYJNYCH 1 S9

tytu -~ dugo rok ~ dugo

Obie s faszywe, bowiem dugo nie jest zalena funkcyjnie od tytuu filmu, jako e mog istnie dwa rne
filmy o takim samym tytule (np. King Kong), ale o rnych dugociach. Rwnie dugo filmu nie zaley od
roku produkcji, w danym roku powstaj bowiem filmy o rnych dugociach.
0

3.6.2. Zalenoci trywialne

Mwimy, e zaleno funkcyjna A~ Az ... A - B jest trywialna, jeli B jest rwne ktremu A. Na
przykad
tytu rok --> tytu
jest zalenocitrywialn.

Kada zaleno trywialna zachodzi w kadej relacji, poniewa jej tre sprowadza si do stwierdzenia, e
,jeli dwie krotki s zgodne dla wszystkich A~, Az, ..., An, to s zgodne dla pewnego z nich". A zatem moemy
korzysta z dowolnej zalenoci trywialnej, bez potrzeby udowadniania jej w konkretnych przypadkach danych.
W pocztkowej denicji zalenoci funkcyjnej nie dopuszczalimy przypadku zalenoci trywialnych.
Jednake nie ma przeszkd, aby je wprowadzi, szczeglnie e s we wszystkich przypadkach spenione, a z
kolei czsto upraszczaj ustalenie regu.
Jeli dopucimy stosowanie zalenoci trywialnych, to take dopucimy w skrtowych zapisach
wystpowanie tych samych atrybutw po lewej i po prawej stronie. Mwimy, e zalenoA~ AZ ... A -~
B,B, ... B,jest:
Trywialna, jeli zbir zoony z atrybutw typu B jest podzbiorem zbioru atrybutw typu A.
Nietrywialna, jeli co najmniej jeden z atrybutw typu B znajduje si pord atrybutw typu A.
Calkowicie nietrywialna, jeli aden z atrybutw typu B nie znajduje si pord atrybutw typu A.
A zatem zaleno:
tytu rok --> rok dugo
jest nietrywialna, ale nie jest cakowicie nietrywialna. Po usuniciu atrybutu rok z prawej strony otrzymamy
zaleno cakowicie nietrywialn.
I6O 3. RELACYJNY MODEL DANYCi

Atrybuty, ktre wystpuj rwnoczenie z prawej i lewej strony, zawsze mona pomin po prawej stronie.
Prawdziwe jest zatem stwierdzenie nastpujce:
Zaleno funkcyjna A,Az ... A --~ B,BZ ... B, jest rwnowana zalenoci A~A~ ... A - C~CZ ...
Ck, gdzie C s tymi elementami z B, ktre nie s rwne A.
Regu t, ktra zostaa zilustrowana na rys. 3.28, nazywamy regulct zalenoci trywialnych.
i i i~ C ~ i

~~.- A i i i i i i i i i i t
iiiiiii

iiiiiiiiiiiiii
iiiiiii

Jeli t i u To musza sa by take zgodne zgodne dla A dla B

Zatem na pewno s~,zgodne dla C
RYSUNEK 3.28
Regua zalenoci trywialnej

3.6.3. Obliczanie domknicia zbioru atrybutw

Zanim przejdziemy do stosowania regu, okrelimy podstawowe prawo, z ktrego te reguy
wynikaj. Zamy, e zbir {A,, Az, ..., A} zawiera atrybuty, a zbir S zalenoci funkcyjne.
Domkniciem zbioru fA,, Agi, ..., A} nad zbiorem zalenoci ,S nazywamy taki zbir at-ybutw B, e
jeli pewna relacja R spenia wszystkie zalenoci ze zbioru S, to spenia take zaleno A,Az ... A
- B, a zatem zaleno A,A~ ... An --~ B wynika z S. Domknicie zbioru atybutw A,, Agi, ..., A
oznaczamy przez {A~, Az, ..., A} `. Dla uproszczenia omawiania tematu obliczania domkni
dopucimy zalenoci trywialne, a wic przyjmiemy, e A,, AZ, ..., A jest zawsze zawarte w fA~,
Agi, ..., A} .
3.6. REGUY DOTYCZCE ZALENOCI FUNKCYJNYCH I G I

Na rysunku 3.29 przedstawiono procedur domykania. Pocztkowy zbir atrybutw A iteracyjnie

uzupeniamy atrybutami z tych prawych stron zalenoci ze zbioru S, ktre wynikaj z A, i postpujemy w ten
sposb tak dugo, jak si da. W kocu, gdy ju nie mona rozszerzy tego nowego zbioru, to znaczy, e stanowi
on domknicie. Poniej przedstawiamy bardziej szczegowy zapis algorytmu obliczania domknicia zbioru
atrybutw {A~, AZ, ..., A} ze wzgldu na zbir zalenoci funkcyjnych.
Domknicie
Wypycha
Poczatkowy zbir
atrybutw
RYSUNEK 3.29
Obliczanie domknicia zbioru atrybutw
1. Niech X oznacza nazw zbioru domknicia. Na pocztku zbiorem X jest zbir atrybutw {A~, A2, ..., A}.
2. Teraz znajdujemy te wszystkie zalenoci funkcyjne postaci
B1BZ...B,--C

gdzie B,, Bz, ..., B, nale do zbioru X , a C nie naley. Wwczas doczamy C do zbioru X.
3. Powtarzamy krok 2 tak dugo, jak dugo nie bdzie mona doczy do X adnego nowego atrybutu.
Poniewa zbir X w ten sposb moe si tylko rozszerza, a z kolei liczba atrybutw kadej relacji jest z
zaoenia skoczona, zatem nastpi taki moment, e niczego wicej nie da si doczy do zbioru X.
4. Jeli ju adnego atrybutu nie mona doczy do zbioru X, to znaczy, e jest on wartoci {A,,
Az, ..., A}+.
162 3. RELACYJNY MODEL DANYCH

PRZYKAD 3.28
Rozwamy relacj z atrybutami: A, B, C, D, E, F. Zamy, e w tej relacji zachodz zalenoci AB --> C, BC
-> AD, D --~ E oraz CF --~ B. Co jest domkniciem zbioru {A, B}, czyli {A, B}+?
Zaczniemy od X= {A, B}. Po pierwsze zauwaamy, e wszystkie atrybuty lewej strony zalenoci
funkcyjnej AB --> C s w X, a wic do X moemy doczy atrybut C, ktry wystpuje po prawej stronie tej
zalenoci. Zatem po pierwszej iteracji kroku 2 zbir X przyjmuje posta {A, B, C}. Potem stwierdzamy, e lewa
strona zalenoci BC -> AD jest ju zawarta w X, a wic do zbioru X mona doczy atrybuty A oraz D ~. A
ju znajduje si w X, lecz D nie, wic nastpny stan X zapisujemy jako {A, B, C, D} . W tym miejscu moemy
zastosowa zaleno D --> E i w ten sposb doczy do X atrybut E. Wicej zmian w X nie mona zrobi. Nie
moemy zastosowa zalenoci CF--~ B, poniewa jej lewa strona nigdy nie znajdzie si wX. Zatem {A, B}+=
{A, B, C, D, E}.
0
Jeli potrafimy obliczy domknicie dowolnego zbioru atrybutw, to moemy
sprawdzi, czy dana zaleno funkcyjna A,Az ... A -- B wynika ze zbioru zalenoci S.
Najpierw obliczamy {A~Az ... A}+ dla zbioru zalenoci S. Jeli B naley do {A,,Az, ...,
A}+, to oznacza e
A~Az...A--B
wynika z S, jeli natomiast B nie naley do {A~, Az, ..., A}+, to znaczy, e ta zaleno
nie wynika z S. Mona testowa uoglnion zaleno, ktra po prawej stronie ma zbir
atrybutw, jeli pamita si o tym, e jest to zapis skrtowy zbioru zalenoci. Zatem
zaleno A,Az ... A -~ B,Bz ... Bm wynika ze zbioru zalenoci S wtedy i tylko wtedy,
kiedy wszystkie atrybuty B B B nale do {A A . A }+.
~, z~ ..., nt n z~ .~ > >,
PRZYKAD 3.29
Rozwamy relacje i zalenoci funkcjonalne, ktre okrelono w przykadzie 3.28. Chcemy sprawdzi, czy z
tego zbioru zalenoci wynika zaleno AB --> D. Z przykadu wynika, e zbir {A, B, C, D, E} jest
dopenieniem {A, B}+. Poniewa element D jest elementem dopenienia, wic zaleno AB --> D wynika ze
zbioru zalenoci.
A teraz rozwamy zaleno D --> A. Chcemy sprawdzi, czy ta zaleno wynika ze zbioru zalenoci. W
tym celu najpierw obliczymy {D}+. Zaczniemy od X= {D}. Na podstawie zalenoci D --; E do zbioru X mona
doczy element E. Ale to ju koniec. Nie mona ju znale adnej zaleno
Przyjmijmy, e zapis BC -- AD jest skrtem zapisu pary zalenoci BC ~ A oraz BC --~ D. Mona te
zalenoci rozpatrzy osobno.
3.6. REGUY DOTYCZCE ZALENOCI FUNKCYJNYCH 163

ci, ktra po lewej stronie miaaby ktry z elementw E lub D, a zatem {D}+= {D, E}. Poniewa atrybut A nie
jest elementem zbioru {D, E}, wic wnioskujemy, e D -~ A nie wynika ze zbioru zalenoci.
0
Algorytm domkni - dlaczego to dziala?
Algorytm obliczania domkni ma sens z bardzo prostego powodu. Stosujc indukcj ze wzgldu na liczb
krokw drugiego punktu algorytmu, wykaemy, e dla kadego atrybutu D ze zbioru X zachodzi zaleno
AIAZ ... A --~ D (gdy D jest rwne ktremu z atrybutw typu A, zaleno jest trywialna). A zatem
wykaemy, e jeli pewna relacja R spenia zalenoci ze zbioru S, to spenia rwnie zaleno A~Az ... An -->
D.
Na pocztku przyjmujemy, e liczba krokw wynosi 0. Wwczas D musi by rwne ktremu z
elementw AI, A2, ..., A, a to znaczy, e A -- D zachodzi w kadej relacji, bowiem jest to zaleno trywialna.
Zamy teraz, e element D zosta doczony do domknicia w wyniku zastosowania zalenoci BIBZ ...
B, --> D. Z zaoenia indukcyjnego wiemy, e R spenia wszystkie zalenoci postaci AIAZ ... A --~ B; dla
wszystkich i = 1, 2, ..., m. Inaczej mwic: jeli dwie krotki R s zgodne dla atrybutw AI, AZ, ..., A, to s
zgodne rwnie dla BI, B2, ..., B,. Poniewa relacja R spenia zaleno B1B~ ... Bm -~ D, wic te dwie krotki
s rwnie zgodne dla D. A zatem R spenia zaleno AIAZ ... A --; D.

Powyszy dowd wiadczy, e algorytm jest poprawny, tzn. e jeli umiecimy w wyniku jego dziaania
atrybut D w domkniciu {A,, AZ, ..., AN}+, to na pewno zaleno AIAz ... A --> D jest prawdziwa. Nie wykazalimy jedynie twierdzenia odwrotnego o kompletnoci algorytmu, tzn. e jeli zachodzi zaleno AIAZ ...
A --> D, to atrybut D na pewno znajdzie si w {A ~, A2, ..., A}+. Nasza ksika jednak nie obejmie tego
dowodu.

3.6.4. Regina przechodnioci

Regua przechodnioci umoliwia kaskadowe czenie zalenoci.
Jeli w relacji R zachodz zalenoci A,Az ... A --> BIBZ ,.. B, oraz B~Bz ... Bn, -> C~CZ ... Ck, to
w relacji R zachodzi take zaleno A,AZ ... A -- CIC~ ,.. Ck.
Jeli pewne atrybuty typu C znajduj si wrd atrybutw typu A, to moemy je wyeliminowa z prawej
strony zalenoci, stosujc regu zalenoci trywialnej.
Aby uzasadni prawdziwo reguy przechodnioci, zastosujmy test z p. 3.6.3. Obliczymy
domknicie {A,, Az, ..., A}+ i w ten sposb potwierdzimy, e speniona jest zaleno A,A~ ... An -;
C1C~ ... Ck.
164 3. RELACYJNY MODEL DANYCH

Zaleno funkcyjna A~AZ ... An -- B1B2 ... B, wiadczy o tym, e wszystkie atrybuty B~, BZ, ..., B,
nale do zbioru {A,, AZ, ..., A}+. Stosujc zaleno B~BZ ... Bm -- ClC2 ... Ck, mamy wic prawo doczy
rwnie atrybuty Cl, CZ, ..., Ck do zbioru {A~, A2, ..., A}+. Poniewa wszystkie elementy C,Cz ... Ck znalazy
si w ten sposb w zbiorze {A~, AZ, ..., A}+, wic moemy wysnu wniosek, e zaleno
A,Az ... A ~ C,CZ ... Ck
jest speniona we wszystkich relacjach, ktre speniaj jednoczenie zalenoci AiA2 ... A -~ B~BZ ...
B, oraz B~BZ ... B, -- C~CZ ... Ck.
Domknicia i klucze
Zauwamy, e zbir {A,, A2, ..., A}+zawiera wszystkie atrybuty relacji R wtedy i tylko wtedy, gdy elementy A
~, Az, ..., A s nadkluczem w R. Bowiem tylko wtedy wszystkie atrybuty s zalene funkcyjnie od zbioru A,,
AZ, ..., A. A zatem stwierdzenie, czy atrybuty A~, Az, ..., An stanowi klucz relacji, moe polega na
sprawdzeniu po pierwsze, czy wszystkie atrybuty R nale do zbioru {A1, A2, ..., A}+, a potem czy S"
otrzymane z dowolnego S, ktry tworzymy przez usunicie choby jednego elementu spord A,, Az, ..., A, nie
zawiera wszystkich atrybutw R.
PRZYKAD 3.30
Rozwamy relacj Film z rys. 3.12, ktra powstaa w p. 3.2.4 z czterech atrybutw klasy oraz zwizku
naleyDo z klas studio. Poniej przedstawiamy relacj i przykad danych:
tul
rok
du
Gwiezdne wojny
1977
124
Potne Kaczory
1991
104
wiat Wayne'a
1992
95
nazwaStudia
kolor Fox kolor Disney kolor Paramount
Przypumy, e pewne dane o studiu producenta filmu chcemy przechowywa w tej samej relacji. Dla
uproszczenia doczymy tylko nazw miasta, ktra bdzie reprezentowa adres studia. Wwczas relacja moe
wyglda nastpujco:
tul
rok
dlu o
Filmu nazwaStudia adresS'tudia
Gwiezdne wojny
1977 124
kolor
Fox
Hollywood
Potne Kaczory
1991 104
kolor
Disney
Buena Vista
wiat Wayne'a
1992 95
kolor
Paramount
Hollywood
3.6. REGUY DOTYCZCE ZALENOSCI FUNKCYJNYCH I 6S

Z tych danych w atwy sposb wynikaj dwie zalenoci:

tytu rok -> nazwaStudia nazwaStudia -~ adresStudia
Pierwsza z nich jest uzasadniona, poniewa zwizek naleyDo z klasy Film jest jednowartociowy, dany
film naley bowiem tylko do jednego studia. Drug zaleno uzasadnia fakt, e atrybut adres w klasie studio
jest jednowartociowy, jest on typu string (porwnaj rys. 2.6).
Zastosowanie reguy przechodnioci pozwala utworzy now zaleno:
tytu rok -~ adresStudia
Z tej zalenoci wynika, e adres zaley funkcyjnie od tytuu i roku (filmu), bowiem jest to adres studia
produkujcego film.
0

3.6.5. Domknicie zbioru zalenoci funkcyjnych

Z powyszych rozwaa wynika, e zbir zalenoci mona rozszerzy o nowe zalenoci zarwno
trywialne, jak i nietrywialne. W nastpnych rozdziaach chcemy rozrnia zalenoci dane, ktre wynikaj
bezporednio z definicji relacji, od zalenoci wyprowadzonych z tego oryginalnego zbioru, przez zastosowanie
jednej z opisanych powyej regu lub przez przetworzenie algorytmu domknicia zbioru atrybutw.
Czasami moe si zdarzy, e istnieje wybr zalenoci, ktrych uywa si do reprezentowania penego
zbioru zalenoci relacji. Kady zbir zalenoci relacji, z ktrego mona wyprowadzi wszystkie inne
zalenoci tej relacji, nazywa si baz tej relacji. Jeli skada si tak, e aden z podzbiorw bazy nie umoliwia
wyprowadzenia wszystkich zalenoci, to taka baza nazywa si mininaalnc~.
PRZYKAD 3.31
Rozwamy relacj R(A, B, C), w ktrej kady atrybut zaley funkcyjnie od pozostaych dwch atrybutw. Peny
zbir zalenoci zawiera zatem sze zalenoci z jednym atrybutem po lewej stronie i jednym po prawej: A -->
B, A -~ C, B - A, B --~ C, C --~ A, C --~ B. W tym zbiorze znajduj si take trzy zalenoci nietrywialne: AB
--> C, AC -~ B oraz BC --~ A. Skrty par zalenoci takie jak A --~ BC oraz trywialne zalenoci postaci A --~
A oraz nie cakiem trywialne AB - BC mona take doczy do tego zbioru (mimo e nasza cisa definicja
zalenoci funkcyjnych nie wymaga doczania zalenoci trywialnych, czciowo trywialnych ani takich z
kilkoma atrybutami po prawej stronie).
166
3. RELACYJNY MODEL DANYCH

Kompletny zbir regu wnioskowania

Algorytm obliczania domkni, opisany w p. 3.6.3, zawsze moe pomc w rozstrzygniciu, czy dana zaleno
funkcyjna wynika z innych danych zalenoci. Moe si jednak okaza interesujce to, e istnieje zbir regu,
nazywanych aksjomatami Armstronga, ktre umoliwiaj wyprowadzenie z danego zbioru zalenoci
wszystkich tych, ktre s od nich zalene funkcyjnie. A oto te aksjomaty:
1. Zwrotno (Reflexivity). Jeli {Bl, B2, ..., B,} c {A~, A2, ..., A}, to AlA2 ... A -~ B~BZ ... B,. Nazywalimy
to zalenociami trywialnymi.
2. Rozszerzenie (Augmentation). Jeli A~AZ ... A --> B~BZ ... B to A,AZ ... AC~CZ ... Ck - B,BZ ...
BmC,C2 ... Ck dla dowolnych C, CZ ... Ck.
3. Przechodnio (Transitivity). Jeli AlA2 ... A ~ B~BZ ... B, oraz B~BZ ... B, -~ C~CZ ... Ck, to
AlA2 ... A --~ C~CZ ... Ck.
W tej relacji mona wyodrbni kilka baz minimalnych. Jedna z nich ma posta:
{A-B,B-~A,B-~C,C-->B}
Inn za zapiszemy jako: {A-~B,B~C,C-~A} Mona w tej przykadowej relacji znale
jeszcze wiele baz, rwnie mi
nimalnych, ale pozostawimy to zadanie jako wiczenie. i
0

3.6.6. wiczenia do podrozdziau 3.6

*wiczenie 3.6.1. Rozwamy relacj o schemacie R(A, B, C, D) oraz zalenoci AB -C,C-DiD->A.
a) Okreli wszystkie zalenoci nietrywialne, ktre wynikaj z tych zalenoci. b) Okreli wszystkie klucze R.
c) Okreli wszystkie nadklucze w R, ktre nie s kluczami.
wiczenie 3.6.2. Powtrzy wiczenie 3.6.1 dla nastpujcych schematw i zalenoci:
i) S(A, B, C, D) z zalenociami funkcyjnymi A -> B, B -~ C oraz B -> D.
ii) T(A, B, C, D) z zalenociami funkcyjnymi AB -> C, BC -> D, CD. --> A oraz AD - B.
3.6. REGUY DOTYCZCE ZALENOCI FUNKCYJNYCH 167
iii) U(A, B, C, D) z zalenociami funkcyjnymi A --~ B, B - C, C --> D oraz D ---> A.
wiczenie 3.6.3. Korzystajc z testu domknicia, opisanego w p. 3.6.3, naley wykaza prawdziwo nastpujcych regu:
*a) Rozszerzenie lewej strony: Jeli zachodzi zaleno A,AZ ... A -~ B, a C jest dowolnym atrybutem, to zachodzi
zaleno A,AZ ... A C --~ B.
b) Rozszerzenie pelne: Jeli zachodzi zaleno A~AZ ... A --> B, a C jest dowolnym atrybutem, to zachodzi zaleno
A,AZ ... A C --~ BC. Uwaga: jeli ta regua jest prawdziwa, to std niemal bezporednio wynika aksjomat rozszerzenia
Armstronga, ktry opisano w ramce w p. 3.6.5.
c) Pseudoprzechodnio: Zamy, e zachodz zalenoci A~A2... A B1Bz ... B, oraz C,CZ ... Ck -~ D, a wszystkie
atrybuty typu B znajduj si wrd C. Wwczas zachodzi rwnie A,AZ ... AE,EZ ... E~ -~ D, gdzie E pokrywaj si z
tymi z C, ktre nie s typu B.
d) Dodawania: Zamy, e zachodz zalenoci A,AZ ... A --~ B~BZ ... B, oraz C,CZ ... Ck --> D,D2 ... D;; wwczas
rwnie zachodzi zaleno:
A,AZ ... A C1C2 ... Ck -> B,Bz ... B, D,DZ ... D

Naley usun po jednej kopii atrybutw z A i z C lub z B oraz z D.

!wiczenie 3.6.4. Naley wykaza, e adna z poniszych regu nie jest prawdziwa dla zalenoci funkcyjnych. W tym celu
naley wskaza przykady relacji, ktra spenia przesanki, ale nie spenia wniosku.
*a) Jeli A --> B, to B --> A.
b) Jeli AB --> C i A --~ C, to B --> C. c) Jeli AB -~ C, to A --~ C lub B --~ C.
!wiczenie 3.6.5. Wykaza, e jeli w relacji nie wystpuje aden atrybut, ktry zaley funkcyjnie od wszystkich innych
atrybutw, to w tej relacji nie istnieje adna zaleno nietrywialna.
!wiczenie 3.6.6. Zamy, e X i Y s zbiorami atrybutw. Naley wykaza, e jeli X c Y, to X" c Y", gdzie domknicia s
obliczane wzgldem tego samego zbioru zalenoci funkcyjnych.
!wiczenie 3.6.7. Udowodni, e (X")+=X".
!!wiczenie 3.6.8. Mwimy, e zbir atrybutw X jest domknity (ze wzgldu na dany zbir zalenoci funkcyjnych), jeli
X"=X. Trzeba rozway relacj o schemacie R(A, B, C, D) oraz nieznanym zbiorze zalenoci funkcyjnych. Jeli okrelimy,
ktry zbir atrybutw jest domknity, to odnajdziemy zbir zalenoci funkcyjnych. Jakie ste zalenoci, gdy:
*a) Wszystkie podzbiory tych czterech atrybutw s domknite.
b) Jedynymi zbiorami domknitymi s zbir pusty i cay zbir {A, B, C, D}. c) Domknite zbiory to: zbir pusty, {A, B} oraz
{A, B, C, D}.
1 C) 3. RELACYJNY MODEL DANYCH

!wiczenie 3.6.9. Naley znale minimalne bazy dla zalenoci i relacji okrelonych w przykadzie 3.31.
!!wiczenie 3.6.10. Wykaza, e jeli pewna zaleno funkcyjna F wynika z okrelonego zbioru zalenoci, to
F mona wyprowadzi z tego zbioru, korzystajc z aksjomatw Armstronga (zdefiniowano je w ramce w p.
3.6.5). Wskazwka: naley zanalizowa algorytm obliczania domknicia zbioru atrybutw i wskaza, w jaki
sposb kady krok algorytmu jest rwnowany z wyprowadzeniem zalenoci funkcyjnej przez zastosowanie
ktrego z aksjomatw Armstronga.

3.7. Projektowanie relacyjnych schematw baz danych

Ju kilka razy wspominalimy, e bezporednie przeksztacenie projektw
obiektowych zapisanych w jzyku ODL (moe w mniejszym stopniu stosuje si to do
diagramw zwizkw encji) prowadzi do kopotw z relacyjnymi schematami baz danych.
Gwny problem polega na redundancji, tzn. na tym, e pewne dane powtarzaj si w
wielu krotkach. Ustalilimy ju nawet najpowszechniejsze rdo redundancji: prby
obejmowania w jednej relacji zarwno jedno- jak i wielowartociowych waciwoci
obiektu. W p. 3.2.2 rozwaalimy przykad redundancji, ktra wynika, gdy prbowalimy
umieci dan jednowartociow o filmie (np. dugo filmu) razem z
wielowartociowymi waciwociami (np. zbiorem gwiazd filmu). Zilustrowano ten
problem na rys. 3.27 i 3.30. Podobn redundancj otrzymalimy, gdy prbowalimy dane
o dacie urodzin gwiazdy przechowywa w jednej relacji ze zbiorem adresw tej gwiazdy.
i tytul rok dlugo typFilmu r~azwaStudia nazwiskoGwiazdy i
Gwiezdne 1977 124 kolor Fox Carrie Wojny Fisher Gwiezdne
1977 124 kolor Fox Mark Wojny Hamill i
Gwiezdne 1977 124 kolor Fox Harrison Wojny Ford Potne
1991 104 kolor Disney Emilio
i Kaczory Estevez wiat 1992 95 kolor Paramount Dana Wayne'a Carvey i
j wiat 1992 95 kolor Paramount Mike Wayne'a Meyers RYSUNEK 3.30
i Anomalie w relacji Film
3.7. PROJEKTOWANIE RELACYJNYCH SCHEMATW t3AZ DANYCH 1 C)9

W biecym podrozdziale rozwiemy problem projektowania dobrego relacyjnego schematu bazy danych
i przedstawimy ten proces w podziale na nastpujce etapy:
1. Najpierw szczegowo opiszemy problemy, ktre wynikaj przy tworzeniu schematu.
2. Nastpnie przedstawimy metod dekompozycji, ktra polega na podziale schematu relacji (zbioru atrybutw)
na dwa mniejsze schematy.
3. Potem opiszemy posta normalna Boyce'a-Codda", inaczej BCNF", czyli taki warunek naoony na
schemat, dziki ktremu mona wyeliminowa jego niedoskonaoci.
4. Poczymy potem te elementy i wytumaczymy, w jaki sposb zapewni spenienie warunkw BCNF przez
dekompozycj schematw relacyjnych.

3.7.1. Anomalie
Takie problemy jak redundancja, ktre powstaj, gdy prbujemy do pojedynczej relacji wczy zbyt wiele
danych, s nazywane anomaliami. Poniej wyliczamy podstawowe rodzaje anomalii:
1. Redundancja (redudancy). Dane niepotrzebnie powtarzaj si w kilku krotkach. Jako przykad moe suy
dugo i typ filmu zdefiniowane na rys. 3.30.
2. Anomalie modyfikacji (update anomalies). Moe si zdarzy, e warto danej zostanie zmodyfikowana w
pewnej krotce, a w innej nie. Na przykad w pewnym momencie okae si , e Gwiezdne Wojny trwaj
naprawd 125 minut i beztrosko zmieniamy warto tego atrybutu w pierwszej krotce na rys. 3.30, ale druga
i trzecia krotka pozostaj bez zmian. Co prawda mona by si kci, e nikt nie powinien zachowywa si
tak beztrosko. Jednak przekonamy si, e mona takich sytuacji unikn dziki zmianom schematu relacji
Film.
3. Anomalie usun (deletion anomalies). W przypadku gdy dla pewnego atrybutu zaczyna obowizywa
warto pusta, to jako efekt uboczny moe si zdarzy utrata czci danych. Jeli na przykad ze zbioru
gwiazd filmu Potne Kaczory usuniemy nazwisko Emilio Estevez, to w bazie nie bdzie ju adnych
danych o gwiazdach tego filmu. Z relacji Film zniknie wwczas ostatnia krotka zawierajca dane o filmie
Potne KaczoYy, a wraz z ni informacje o tym, e film trwa 95 minut oraz e jest kolorowy.
170

3.7.2. Dekompozycja relacji

3. RELACYJNY MODEL DANYCH

Waciwym sposobem eliminowania wymienionych powyej anomalii jest dekompozycja relacji.

Sprowadza si on do podziau atrybutw relacji R midzy dwa schematy nowych relacji. Regua dekompozycji
obejmuje rwnie podzia krotek relacji wejciowej R midzy nowe relacje, dziki operacji rzutowania krotek
R. Sposb eliminowania anomalii przez dekompozycj opiszemy zaraz po omwieniu procesu samej
dekompozycji.
Relacj R o schemacie {At, Az, ..., A} dekomponujemy midzy dwie relacje S i T o schematach
odpowiednio {Bt, B2, ..., B,} oraz {Ct, Cz, ..., Ck} wedug nastpujcych zasad:
1. {At, Az, ..., An} _ {Bt, Bz, ..., Bn,} u Ct, Cz, ..., Ck}.
2. Krotki relacji S powstaj przez rzutowanie wszystkich krotek relacji R na zbir
atrybutw {Bt, Bz, ..., B,}. Oznacza to, e z kadej krotki t z biecej instancji
relacji R pobieramy wartoci atrybutw {Bt, Bz, ..., B,} i tworzymy w ten sposb
krotk relacji S, nalec do jej biecej instancji. Poniewa relacje s zbiorami,
wic tak sama krotk S mona uzyska z rzutowania rnych krotek relacji R. W
takich przypadkach w S umieszcza si tylko jedn kopi.
3. W podobny sposb, z rzutowania krotek biecej instancji relacji R na zbir
atrybutw {Ct, Cz, ..., Ck}, otrzymuje si krotki relacji T.
PRZYKAD 3.32
Sprbujmy dekomponowa relacj Film z rys. 3.30. Najpierw dekomponujemy schemat tej
relacji. Wybr atrybutw do poszczeglnych relacji zosta podyktowany motywami, ktre
omwimy w p. 3.7.3; przedstawia si on nastpujco:
1. Do relacji Filml doczamy wszystkie atrybuty prcz atrybutu nazwiskoGwiazdy.
2. Relacja Film2 obejmuje atrybuty tytu, rok oraz nazwiskoGwiazdy.
Proces dekompozycji instancji relacji przedstawimy na krtkim przykadzie danych z rys. 3.30. Ale
najpierw zbudujemy rzut schematu relacj i Filml:
(tytu, rok, dugo, typFilmu, nazwaStudia}
Na rysunku 3.30 pierwsze trzy krotki maj identyczne wartoci tych piciu atrybutw:
(Gwiezdne Wojny, 1977, 124, kolor, Fox)
3.7. PROJEKTOWANIE RELACYJNYCH SCHEMATW BAZ DANYCH 17I

W czwartej krotce wartoci tych piciu atrybutw s inne, a krotki pita i szsta maj jednakowe
wartoci tych piciu atrybutw. Relacj Filml przedstawiono na rys. 3.3 I .
tytul rok Gwiezdne Wojny 1977 Potne Kaczory 1991 wiat Wayne'a 1992
dugo
typFilmu
124
kolor
104
kolor
95
kolor
nazwaStudia
Fox Disney Paramount
RYSUNEK 3.31 Relacja Filml

A teraz rozwamy rzut danych z rys. 3.30 do schematu relacji Film2. Kada z szeciu krotek rni si albo
wartoci atrybutu tytu, albo atrybutu rok, albo nazwiskoGwiazdy, a zatem otrzymujemy w wyniku relacj
przedstawion na rys. 3.32.
tytul I rok I nazwiskoGwiazdy
Gwiezdne Wojny 1977 Gwiezdne Wojny 1977 Gwiezdne Wojny 1977 Potne Kaczory
1991 wiat Wayne'a 1992 wiat Wayne'a 1992
Carrie Fisher Mark Hamill Harrison Ford Emilio Estevez Dana Carvey Mike
Meyers
RYSUNEK 3.32 Relacja Film2
O

Zauwamy, e dziki dekompozycji udao si wyeliminowa anomalie, ktre omawialimy wczeniej. Po

pierwsze nie ma ju redundancji: na przykad dugo filmu w relacji Filml wystpuje tylko raz. Znika rwnie
ryzyko anomalii modyfikacji. Na przykad jeli musimy zmieni dugo filmu Gwiezdne Wojny, to nie
powstanie ju taka sytuacja, eby ten film mia w bazie dwie rne wartoci tego atrybutu.
Ryzyko wystpienia anomalii usuni rwnie znika. Jeli usuniemy wszystkie gwiazdy filmu Potne
Kaczory, to zostan w ten sposb usunite wszystkie dane o tym filmie z relacji Film2. Ale wszystkie inne dane
o nim bd nadal dostpne w relacji Fi1m1.
Pozornie moe si wydawa, e w dalszym cigu w relacji Film2 wystpuje redundancja, poniewa tytu
oraz rok produkcji filmu ukazuj si kilka razy. Trzeba jednak pamita o tym, e te dwa atrybuty stanowi
klucz dla filmu, a nie da si tu ju okreli bardziej lapidarnego sposobu identyfikacji. Pza tym w relacji Film2
nie ma adnych moliwoci wystpienia anomalii modyfikacji. Mona mniema, e gdy zmienimy rok w krotce
z Carrie Fisher,
17Z 3. RELACYJNY MODEL DANYCH

a w innych krotkach Gwiezdnych woj en - nie, wystpi anomalia modyfikacji. Ot zaoenia, dotyczce
zalenoci funkcyjnych, nie zabraniaj wystpienia filmu o takiej samej nazwie i innym roku produkcji, czyli
innych Gwiezdnych Wojen, wyprodukowanych na przykad w 1997 roku z Carrie Fisher w charakterze gwiazdy.
A zatem nie naley wprowadza mechanizmw uniemoliwiajcych tego typu modyfikacji, a dodatkowo, taka
zmiana wcale nie musi by bdem.

3.7.3. Posta normalna Boyce'a-Codda

Zadanie dekompozycji polega na zastpieniu relacji rwnowanym jej zbiorem relacji, ktrych struktura
uniemoliwia wystpienie anomalii. Okazuje si, e istnieje prosty warunek, ktrego spenienie zapewnia, e w
schemacie nie wystpuj anomalie, ktre powyej omwilimy. Warunek ten nazywa si postacie normalna
Boyce'a-Codda lub w skrcie BCNF (Boyce-Codd normal form).
Relacja R jest w postaci BCNF wtedy i tylko wtedy, gdy dla kadej nietrywialnej zalenoci A~, AZ, ..., An -~
B zbir {A~, A2, ..., An} jest nadkluczem R.
To znaczy, e lewa strona kadej zalenoci nietrywialnej musi by nadkluczem. Przypomnijmy, e nadklucz nie
musi spenia warunku minimalnoci. Mona sformuowa wic warunek rwnowany do BCNF, ktry
stwierdza, e lewa strona kadej nietrywialnej zalenoci funkcyjnej musi zawiera klucz.
Jeli odnajdzie si zaleno, ktra narusza warunek BCNF, to czasami warto odszuka wszystkie inne
zalenoci o takiej samej lewej stronie, bez wzgldu na to czy one te naruszaj ten warunek, czy nie. Poniej
przedstawiamy alternatywn definicj BCNF, w ktrej poszukuje si wszystkich zalenoci o takich samych
lewych stronach, z ktrych co najmniej jedna jest nietrywialna i narusza warunek BCNF.
Relacja R jest w postaci BCNF wtedy i tylko wtedy, gdy dla kadej nietrywialnej zalenoci A, AZ ... A -
B~Bz ... Bm zachodzcej w R, zbir {Ai, A2, ..., An} jest nadkluczem R.
Powyszy warunek jest rwnowany pierwszej definicji BCNF. Przypomnijmy, e zapis A~ AZ ... A --
B~BZ ... B, jest skrtem zapisu A~AZ ... A --> B;, dla i = 1, 2, ..., m. Poniewa musi istnie co najmniej jedno
i takie, e B; nie jest typu A (w przeciwnym przypadku zaleno A~ Az ... A -~ B~BZ ... B, byaby trywialna),
zatem A,AZ ... A -~ B; naruszaoby warunek BCNF wedug pierwotnej definicji.
3.7. PROJEKTOWANIE RELACYJNYCH SCHEMATW BAZ DANYCH I %3

PRZYKAD 3.33
Relacja Film z rys. 3.30 nie jest w postaci BCNF. Aby uzasadni to stwierdzenie, najpierw wyodrbnimy zbir
atrybutw tworzcych klucz. W przykadzie 3.21 podalimy powody tego, e zbir (tytu, rok, nazwiskoGwiazdy) stanowi klucz. A zatem kady zbir zawierajcy wymienione trzy atrybuty jest nadkluczem. Te same
argumenty, ktrych uylimy w przykadzie 3.21, mog posuy do uzasadnienie tego, e aden zbir, ktry nie
zawiera wszystkich trzech atrybutw , nie moe by nadkluczem. Std wynika wic, e atrybuty (tytu, rok,
nazwiskoGwiazdy} s jedynym kluczem relacji Film.
Ale rozwamy z kolei zaleno funkcyjn:

tytu rok ~ dugo typFilmu nazwaStudia

ktra zachodzi w relacji Film. Przypomnijmy, e wynika ona z faktu, e wprojekcie w jzyku ODL kluczem by
zbir (tytu, rok), a poza tym zawiera on atrybuty jednowartociowe dugo i typFilmu oraz jednowartociowy
zwizek naleyDo, ktry prowadzi do studia producenta.
Ale lewa strona tej zalenoci nie jest nadkluczem. Wiadomo przecie, e atrybuty tytu i rok nie
wyznaczaj jednoznacznie szstego atrybutu nazwiskoGwiazdy. A zatem ta zaleno stanowi naruszenie
warunku BCNF, a std wynika, e relacja Film nie jest w postaci BCNF. A co wicej, jeli zastosujemy
pierwotn definicj BCNF, gdzie po prawej stronie wystpuje jeden atrybut, to moemy wskaza a trzy
zalenoci takie jak np. tytu rok -~ dugo, ktre snaruszeniem warunku BCNF.
0
PRZYKAD 3.34
Relacja Filml, przedstawiona na rys. 3.31, jest w postaci BCNF. Poniewa zaleno
tytu rok --> dugo typFilmu nazwaStudia
zachodzi dla tej relacji, ale ani atrybut rok, ani atrybut tytu samoistnie nie wyznaczaj jednoznacznie
pozostaych atrybutw, wic jedynym kluczem relacji filml moe by zbir (tytu, rok}. Ponadto jedyna
nietrywialna zaleno funkcyjna musi mie z lewej strony co najmniej tytu i rok, co prowadzi do wniosku, e
jej lewe strony musz by nadkluczem. Std te wynika, e Filml jest w postaci BCNF.
0
PRZYKAD 3.35
Kada relacja binarna (o dwch atrybutach) jest w postaci BCNF. Aby uzasadni takie twierdzenie, sprawdzimy
wszystkie nietrywialne zalenoci, kt