506 8 ZORIENTOWANE OBIEKTOWO JEŻYKI ZAPYTAŃ
która relacja jest relacją R? W rozpatry wanym przykładzie atrybut gwiazda w krotkach GwiazdyW ma określoną wartość, która wskazuje pewną krotkę, a ta 2 kolei występuje w relacji typu TypGwiazda. Istnieje tylko jedna taka relacja, Gwi a zda Filmowa, a więc można oczekiwać, że jest to nasza poszukiwana relacja.
Ale mogą być zadeklarowane także inne relacje, których typ zostanie określony jako TypGwiazda, a jeśli tak się stanie, to wówczas trzeba przeszukiwać indeksy każdej z nich po to, by znaleźć nazwisko ‘Mel Gibson’. Takie przeszukiwanie może być również czasochłonne, jeśli z powodów znanych projektantowi schematu wszystkie referencje doprowadzałyby w końcu do jednej relacji, co zdarza się najczęściej. Dlatego w języku SQL3 udostępnia się mechanizm, który umożliwia wyspecyfikowanie relacji, do której odwołuje się atry but. Do relacji, której atrybut jest referencją, można dołączyć następującą klauzulę:
SCOPE FOR <atrybut> is <rclacja>
Ta instrukcja oznacza, że nazwany atrybut, który jest referencją, wskazuje zawsze krotki relacji wymienionej w tej instrukcji.
PRZYKŁAD 8.28
Aby udzielić gwarancji, że gwiazda w relacji GwiazdyW zawsze jest referencją pewnej krotki w relacji Gwiazda Filmowa, a film referencją pewnej krotki relacji Film można deklarację relacji GwiazdyW zapisać tak, jak to przedstawiono na rys. 8.14.
□
CREATE ROW TYPE TypGwiazdyW( gwiazda REF(TypGwiazda), film REF(TypFiim)
CREATE TA.BLE GwiazdyW OF TYPE TypGwiazdyW SCCPE FOR gwiazda 1S GwiazdaFilmowa,
SCOPE FOR film IS Film;
RYSUNEK 8.14
Deklarowanie zakresu atrybutów referencji
W językach zorientowanych obiektowo obowiązuje zasada, ż.e ID obiektów są wewnętrznymi elementami systemu, do których nic ma dostępu z poziomu języka zapytań. W języku OQL na przykład ta reguła jest przestrzegana. Ale tak naprawdę to zupełnie nie widać powodu, dlaczego tak się dzieje, że nie ma bezpośredniego dostępu do identyfikatorów obiektów i dlatego w SQL3 otwarto taką możliwość. Deklarując relację lub jej typ wiersza, można określić atrybut, którego wartością jest referencja krotki definiowanego typu. Jeśli do deklaracji typu wiersza lub tabeli dołączymy następującą klauzulę:
VALUES FOR <atr>'but> ARE SYSTEM GENERATF.D
to wartością wymienionego atrybutu będzie referencja do krotki, która ją zawiera. W ten sposób taki atry but może pełnić funkcje klucza i jednocześnie być identyfikatorem obiektu krotki.
PRZYKŁAD 8.29
Przekształćmy rys. 8.13 w ten sposób, że zarówno Gwiazda Filmowa, jak i Film zostaną wyposażone w dodatkowe atrybuty oznaczające ID ich obiektów; nazwiemy te atrybuty odpowiednio gwiazda id oraz Zmodyfikowany schemat został przedstawiony na rys. 8.15. Poniżej przedstawiamy opis zmian, które trzeba było zrobić:
1. Do typu wiersza TypFilm został dołączony atrybut f ilm_id.
2. Do typu wiersza TypGwiazda został dołączony atrybut gwiazda_id.
3. Do deklaracji tabeli Film została dołączona klauzula informująca o tym, że wartość atrybutu f ilm_id jest generowana przez system.
4. Do deklaracji tabeli GwiazdaFilinowa została dołączona klauzula informująca o tym, że wartość atrybutu gwiazdaid jest generowana przez system.
5. Powtórzono deklarację SCOPE z przykładu 8.28.
Teraz już dysponujemy bardziej konwencjonalnym sposobem utworzenia zapytania omawianego w przykładzie 8.27, które powoduje wyszukanie filmów z udziałem Mela Gibsona. Można bowiem w klauzuli WHERE przyrównać odniesienie z relacji GwiazdyW do atrybutu wskazującego ID obiektów w relacjach GwiazdaFilmowa oraz Film, które są referencjami własnych krotek. Zapylanie ma następującą postać:
SELECT Film.tytuł
EROM GwiazdyW, GwiazdaFilmowa, Film
WHERE GwiazdyW.gwiazda - GwiazdaFilmowa.gwiazda_id AND GwiazdyW.film = Fi Im.iilm_ić AND GwiazdaFilmowa.nazwisko = 'Mel Gibson';
Na podstawie klauzuli FROM w iadomo, żc będą tworzone trójki z kolejnych krotek relacji: GwiazdyW, GwiazdaFi lmowa i Film. Pierwszy warunek klauzuli WHERE zapewnia, że krotka z relacji GwiazdyW musi odpowiadać