124 .1 RELACYJNY MODEL DANYCH
miały strukturę złożoną zbioru lub zbioru struktur. W przypadku związku należyDo, do schematu relacji Film dołączylibyśmy po jednym atrybucie dla każdej właściwości klasy Studio.
interface Film{
attribute string tytuł; atlribute intogor rok; attribute integer długość;
attribute enumeration(kolor, czarno-biały) typFilmu; rełationship Set<Gwiazda> gwiazdy
inverse Gwiazda:: występujeW; rela-.ionship Studio należyDo;
inverse Studio:: posiada;
};
RYSUNHK3.il
Polna definicja klasy Film
Przy takim podejściu pojawia się jednak kłopot polegający na tym, że obiekty studio pozostają również we własnym związku posiada, który definiuje z powrotem zależność do obiektów klasy Fi im. Do reprezentowania tego związku w każdej krotce relacji film trzeba by zawrzeć dane o wszystkich innych filmach wyprodukowanych przez jego studio. Z kolei dane o każdym z tych filmów obejmują również dane ich studia, co skłania nas do ponownego włączenia danych o filmach powiązanych ze studiem. A zatem taka technika może doprowadzić do istotnych komplikacji, jeśli uda się ją stosować w praktyce1.
Lepszą metodę uzyskamy, gdy zastanowimy się, w jaki sposób naprawdę obiekty’ są rozmieszczone w pamięci komputera. Jeśli obiekt Oj zawiera dowiązanie do innego obiektu O2, to wcale nie tworzymy nowej kopii obiektu 02 w O,. Na ogół po prostu określa się wewnątrz 0| wartość wskaźnika pokazującego na obiekt 02.
Ale model relacyjny nie zawiera pojęcia wskaźnika ani żadnego innego podobnego elementu. Zamiast tego musimy symulować efekt, uzyskiwany poprzez wskaźniki, zbiorem wartości definiujących powiązany obiekt. Trzeba nam po prostu zbioru atrybutów powiązanej klasy, które tworzą w niej klucz. Jeśli to określimy, to możemy potraktować związek tak. jakby był atrybutem lub atrybutami kluczowymi wskazywanej klasy. Tę technikę ilustruje następny przykład.
PRZYKŁAD 3.6
Załóżmy, że atrybut nazwa stanowi klucz dla klasy Studio. Definicję tej klasy przepisujemy zgodnie z rys. 2.6 :
interface Studio {
attribute string nazwa; attribute string adres; relationship Set<Film> posiada inverse Film::należyDo; ł;
Możemy zmodyfikować schemat relacji Film z rys. 3.1 lak, aby zostały do niego dołączone atrybuty określające studio właściciela. Arbitralnie nazwiemy ten atrybut nazwaStudia. Na rysunku 3.12 zostało przedstawione takie rozszerzenie o atrybut nazwaStudia oraz pewne przykładowe krotki.
tytuł |
rok |
długość |
typ Filmu |
nazwaStudia |
Gwiezdne Wojny |
1977 |
124 |
kolor |
Fox |
Potężne Kaczory |
1991 |
104 |
kolor |
Disney |
Świat Wayne'a |
1992 |
95 |
kolor |
Paramount |
RYSUNEK 3-12
Relacja Film z nowym atrybutem określającym studio właściciela
□
Związek gwiazdy z. rys. 3.11 przedstawia problem, który nic występuje w przypadku związku należyDo. Jeśli typem związku jest klasa, to mówimy, że związek jest jednowartościowy. Związek należyDo, którego typem jest klasa Studio, jest związkiem jednowartościowym. Jednak jeśli typem związku jest pewna struktura, np. kolekcja, zastosowana do klasy, to wówczas mówimy, że związek jest wieł o wartość i owy. Związek gwiazdy jest wielowarto-ściowy, ponieważ jego ty p określono jako Set<Gwiazda>. Mówiąc inaczej, każdy związek typu jeden do wiele lub wiele do wiele z klasy A do klasy B jest związkiem wielowarlościowym od A do B.
W celu reprezentowania związków wielowartościowych musimy zastosować kombinację dwóch technik:
1. Tak jak w przypadku związku jednowartościowcgo, trzeba znaleźć klucz reprezentujący powiązane obiekty'.
2. Tak jak w przypadku atrybutów ze zbiorem wartości, do reprezentowania obiektów' powiązanych trzeba tworzyć osobne krotki dla po-
O ile łańcuch filmów i studia nic wychodzi nigdy poza jedno studio, to już analogiczne postępowanie w przypadku związku gwiazdy i odwrotnego doń związku występujeW prowadziłoby od filmu do jego gwiazd, do wszystkich filmów powiązanych z gwiazdami, do wszystkich gwiazd, które tam występowały, i tak dalej, bardzo szybko doprowadzając do konieczności uwzględnienia w jednej krotce prawie wszystkich filmów i gwiazd umieszczonych w bazie danych.