ullman250 (2)

ullman250 (2)



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

8.5.7. Identyfikatory obiektów jako wartości

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ć


Wyszukiwarka

Podobne podstrony:
42460 ullman241 (2) 488 8. ZORIENTOWANE OBIEKTOWO JĘZYKI ZAPYTAŃ Korzystamy tutaj z podzapytania po
24504 ullman238 (2) 482 S ZORIENTOWANE OBIEKTOWO JĘZYKI ZAPYTAŃ T cych klauzulę WHERE. Te nazwiska s
70029 ullman243 (2) 492 8. ZORIENTOWANE OBIEKTOWO JĘZYKI ZAPYTAŃ lect-from-whcre; przedstawiono ją n
73187 ullman254 (2) 514 s zorientowani: obiektowo języki zapytań traktowano by jako równe, jeśli wyg
82105 ullman255 (2) 516 S. ZORIENTOWANE OBIEKTOWO JEŻYKI ZAPYTAŃ 1)    B*UNCTION Adre
ullman247 (2) :>uu 8. ZORIENTOWANE OBIEKTOWO JĘZYKI ZAPYTAŃ8.5.1. Typ wiersza W języku SQL3 można
48057 ullman236 (2) 478 8 ZORIENTOWANE OBIEKTOWO JĘZYKI ZAPYTAŃ8.2.2. System typów Struktura typów w
ullman249 (2) 504 fi ZORIENTOWANE OBIEKTOWO JĘZYKI ZAPYTAŃ jako referencja. Rozpoczynamy od zdefinio

więcej podobnych podstron