66446 ullman061 (2)

128 3. RHI.ACYJNY MODEL DANYCH

PRZYKŁAD 3.9

Jeśli wprowadzimy jednoznaczne numery certyfikatów dla gwiazd i zdefiniujemy klucz gwiazdy w relacji poprzez ten numer, to relacja Film przyjmie następująca postać:

tytuł	rok	długość	typFilmu	nazwaStudio	cert#
Gwiezdne Wojny	1977	124	kolor	Fcx	123-45

Podajemy tu tylko jedną krotkę i zakładamy, że 12 345 jest numerem certyfikatu Carrie Fishcr. Do relacji Gwiazda trzeba również dołączyć atrybut określający numer certyfikatu, a także wszystkie inne dane o gwieździc, które wynikają z definicji klasy Gwiazda zapisanej w języku ODL. Na przykład:

certż	nazwisko	ulica	miasto	występuję W
12345	Carrie Fisher	123 Mapie St.	Hollywood	Gwiezdne wojny

opisuje pewien schemat relacji oraz jedną z kilku krotek odpowiadających Carrie Fisher.

□

3.2.7. Reprezentowanie relacji oraz jej odwrotności

W zasadzie przy bezpośrednim tłumaczeniu opisu w modelu ODL na model relacyjny dwukrotnie reprezentujemy relację, jeden raz w każdym kierunku. W przykładzie 3.7 przechowywaliśmy każdą gwiazdę filmu w krotce, która nosiła nazwę tego filmu. Gdy projektowaliśmy relacje dla klasy Gwiuzda, to reprezentowaliśmy związek występujeW przez utworzenie tylu krotek dla każdej gwiazdy, w ilu filmach ona występowała, z podaniem tytułu i roku każdego z filmów w osobnych krotkach (pamiętamy przecież, że tytuł i rok razem stanowią klucz filmów).

Jednak zauważmy, żc przechowywanie zarówno związku gwiazdy, jak i jego odwrotności, jest redundantne. Każdy z nich dostarcza bowiem tych samych danych co ten drugi. A zatem możemy w relacji Gwiazda całkiem pominąć związek występuj eW. Zamiast tego możemy utrzymać wszystkie dane w relacji Gwiazda, a usunąć atrybut nazw i skoGwiazdy z relacji Fi Im. W punkcie 3.3.2 opiszemy trzecią metodę, polegającą na tym. że związek i jego odwrotność są oddzielane i razem tworzą nową relację. Czasami, aczkolwiek nie zawsze, taka metoda jest najwłaściwsza. Jednak jeśli tak się zdarzy, że oddzielna relacja dla związków jest najlepszym sposobem, to proces normalizacji, który omówimy w podrozdziale 3.7, zmusi nas do utworzenia jej, nawet jeśli sami we wstępnym projekcie relacyjnym tego nie zrobimy.

Zauważmy, że w modelach ODL zarówno związek, jak i jego odwrotność są niezbędne, ponieważ zawierają wskaźniki od gwiazd do ich filmów

oraz od filmów do ich gwiazd. Nie można posługiwać się bowiem wskaźni kami odwrotnie do ich kierunku, wiec w przeciwnym razie musiałyby po wstać wskaźniki dwukierunkowe*. T.ccz zarówno w modelu relacyjnym, ja] i w modelu związków encji, związki definiuje się przez powiązane wartość (kluczy). Krotki zawierające pary powiązanych kluczy, na przykład tytuł i roJ dla filmu oraz nazwisko gwiazdy, można stosować zarówno do analizowani: związku, jak i jego odwrotności.

Reprezentowanie związków w jednym kierunku

Jeśli binarny związek zachodzi między dwoma zbiorami eneji, to można wybrać jedną z relacji, w której zostanie zapisany związek: relację definiującą którykolwiek ze zbiorów encji. Czy ma znaczenie, którą z nich wybierzemy? Jeśli związek jest typu jeden do jeden lub w iele do wiele, to najprawdopodobniej nic ma to znaczenia. Ale jeśli związek jest typu wiele do jeden, to warto wprowadzić związek po stronie wiele, tzn. do lego zbioru encji, w który m wiele encji może być powiązanych z jedną cncją drugiego zbioru encji. W ten sposób bowiem uda się nam uniknąć redundancji.

Na przykład związek Posiada między Filmami i Studiami jest lepiej umieścić w zbiorze Filmy. W ten sposób po prostu tylko rozszerza się zbiór atrybutów filmu o nazwę właściwego dla filmu studia i każda krotka rozszerza się o jedną wartość. Gdybyśmy natomiast dołączy li związek do relacji Studia, to musielibyśmy każdą krotkę w tej relacji rozszerzyć o wiele innych krotek, dodając dla każdego studia tyle krotek, ile filmów ono posiada. W wyniku takich działań powielilibyśmy wszystkie inne dane na temat studia tyle razy, ile ma ono filmów.

3.2.8. Ćwiczenia do podrozdziału 3.2

Ćwiczenie 3.2.1. Należy przekształcić projekty w języku ODL z wymieniony! poniżej ćwiczeń do postaci relacyjnego schematu bazy danych.

*a) Ćwiczenie 2.1.1.

b)    Ćwiczenie 2.1.2 (włączając wszystkie cztery modyfikacje wyspecyfikował w lamlym ćwiczeniu).

c)    Ćwiczenie 2.1.3.

d)    Ćwiczenie 2.1.4.

*e) ćwiczenie 2.1.5.

f) Ćwiczenie 2.1.6.

‘ Oczywiście nie można zakładać, ze dana implementacja ODL będzie zawierała wsk; niki o pożądanych właściwościach, ale może się zdarzyć, zc istnieje laka implementacja, ku dla pary związków odwrotnych ma pojedynczą reprezentację.