ullman064 (2)

134 3 RELACYJNY MODEL DANYCH

Zauważmy, że powyższy związek oraz związek /. pr/.ykładu 3.10, który utworzyliśmy dla zbioru encji Filmy (przedstawiony na rys. 3.1), zawierają dokładnie te same dane, które zawiera związek z rys. 3.12, utworzony w przykładzie 3.6 dla klasy Film, jedynie z pominięciem właściwości gwiazdy.

□

PRZYKŁAD 3.13

Postępując w podobny sposób, można przekształcić związek Gwiazdy-W z rys. 3.15 do postaci relacji z atrybutami tytuł oraz rok (klucz Filmu) oraz z atrybutem nazwi skoGwiazdy, który stanowi klucz do zbioru encji Gwi az-cy. Na rysunku 3.16 pokazano przykład relacji Gwiazdy-W. Zauważmy, że ta relacja oraz rys. 3.16 zawierają te same dane co rys. 3.13, nie obejmują one tylko tych atrybutów klasy Gwiazda, które nie wchodzą w skład klucza (atrybutów długość i typFilmu), umieszczone na rys. 3.13.

tytuł	rok	nazwiskoGwiazdy
Gwiezdne Wojny	1977	Carrie Fisher
Gwiezdne Wojny	1977	Mark Hamil-1
Gwiezdne Wojny	1977	Harrison Ford
Potężne Kaczory	1991	Fmi . i o Estevez
Świat Wayne'a	1992	Dana Carvey
Świat Wayne'a	1992	Miko Meyera

RYSUNEK 3.16

Relacja związku Gwiazdy-w

Może się wydawać, że na rys. 3.16 atrybut rok jest redundancyjny. Ale wynika to tylko z faktu, żc w tym przykładzie nazwy filmów nie powtarzają się. Gdyby tam występowało kilka filmów o tym samym tytule, np. „King Kong”, to rok byłby istotny na przykład do rozstrzygnięcia, które gwiazdy występują w której wersji filmu.

□

Zobaczmy, jakie są zalety schematu bazy danych, który otrzymamy, zaczynając od modelu związków encji w porównaniu zc schematem bazy przekształconym z modelu ODL.

•    Relacje częściej występują w postaci znormalizowanej niż klasy, co oznacza, żc zawierają mniej redundancji niż przy bezpośredniej transformacji z opisu ODL.

•    Dwukierunkowy związek w modelu ODL zostaje zastąpiony pojedynczą relacją, która odzwierciedla związek w obu kierunkach.

PRZYKŁAD 3.14

Również związki wicloargumentowe można w łatwy sposób przekształcić w relacje. Rozważmy czlcroargumentowy związek Kontrakty z rys. 2.12, powtórzony na rys. 3.17, który obejmuje gwiazdę, film i dwa studia, pierwsze utrzymujące kontrakt z gwiazdą i drugie, które pozyskuje gwiazdę do udziału w konkretnym filmie. Związek ten jest reprezentowany przez relację Kontrakty, której schemat składa się z atrybutów czterech następujących kluczy dla czterech zbiorów encji:

1.    Klucz nazwiskoGwiazdy dla zbioru gwiazd.

2.    Klucz złożony z atrybutów tytuł oraz rok dla filmu.

3.    Klucz siudioGwiazdy wskazujący nazwę pierwszego studia, jak pamiętamy przyjęliśmy założenie, że nazwa studio jest kluczem zbioru encji Studio.

4.    Klucz stućioProducenta, który stanowi nazwę tego studia, które produkuje film z udziałem gwiazdy.

Od ODL do relacji

Jak już wspomnieliśmy, w wyniku przekształcenia związku z modelu związków encji do schematu relacji czasami otrzymujemy lepszy schemat relacyjny bazy danych niż w sytuacjach, gdy przekształcamy związki w ODL do postaci relacji. Jednakże nic nic stoi na przeszkodzie, aby z modeli związków encji zapożyczyć technikę wydzielania w osobną relację związków typu wiele do jeden albo wicie do wiele. Pozwoli to wyeliminować redundancję oraz mnożenie się liczby encji, co dzieje się czasami przy próbach implementowania związku wielowartościowego w języku ODL przez definiujące go klasy. Poza tym przypomnijmy ponownie, że w podrozdziale 3.7 będzie można poznać automatyczny sposób naprawienia schematu relacji, otrzymanego bezpośrednio z opisu w języku ODL.

RYSUNEK 3.17 Związek Kontrakty