© K.Subieta. Obiektowe języki zapytań 09, Folia 1 maj 2004 Obiektowe języki zapytań Wykładowca: Kazimierz Subieta Polsko-Japońska Wyższa Szkoła Technik.

Prezentacja na temat: "© K.Subieta. Obiektowe języki zapytań 09, Folia 1 maj 2004 Obiektowe języki zapytań Wykładowca: Kazimierz Subieta Polsko-Japońska Wyższa Szkoła Technik."— Zapis prezentacji:

1 © K.Subieta. Obiektowe języki zapytań 09, Folia 1 maj 2004 Obiektowe języki zapytań Wykładowca: Kazimierz Subieta Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa subieta@pjwstk.edu.pl Instytut Podstaw Informatyki PAN, Warszawa subieta@ipipan.waw.pl Wykład 09: Język SBQL (Stack-Based Query Language) (2) Operatory niealgebraiczne, przykłady zapytań w SBQL

2 © K.Subieta. Obiektowe języki zapytań 09, Folia 2 maj 2004 Dlaczego "niealgebraiczne"? (1) Do nich należą operator where, operator kropki, kwantyfikatory, zależne złączenie join, sortowanie (order by), i inne. Wszystkie są binarne. Mimo podobieństwa do operatorów algebraicznych, semantyka operatorów niealgebraicznych nie da się prosto sprowadzić do algebry. To zdanie może wydawać się niejasne. W modelu relacyjnym operatory selekcji (operator where), projekcji (operator kropki) oraz złączenia są przecież traktowane jako operatory algebraiczne algebry relacji. Tu właśnie jest nieporozumienie. Takie traktowanie jest możliwe wyłącznie przy ograniczonej funkcjonalności, oraz po przyjęciu triku formalnego. Trik polega na tym, że część semantyki jest przenoszona na poziom metajęzykowy. Operatory te są dodatkowo kwalifikowane wyrażeniem metajęzykowym. Np. w wyrażeniu algebry relacyjnej: Zar>1000 ( Prac ) operator selekcji jest kwalifikowany wyrażeniem metajęzykowym Zar >1000. Operator selekcji nie jest pojedynczym operatorem, lecz nieskończoną rodziną zawierającą tyle operatorów, ile jest warunków selekcji.

3 © K.Subieta. Obiektowe języki zapytań 09, Folia 3 maj 2004 Dlaczego "niealgebraiczne"? (2) Powyższy trik można uważać za uzasadniony w przypadku, gdy wyrażenie metajęzykowe parametryzujące operator jest proste, a jego semantyka jest oczywista. Nie zawsze to jest prawda. Operator selekcji może mieć bardziej złożony warunek selekcji, np. ZarobekNetto( Zar + 100 ) >1000 ( Prac ) Warunek selekcji zawiera operator + oraz wywołuje pewną funkcję ZarobekNetto. Wyrażenie metajęzykowe posiada nietrywialną wewnętrzną semantykę, która jest nieformalna. Jest to po prostu nieformalny komentarz. Jeżeli jakikolwiek składnik języka nie ma formalnej semantyki, to cały język również nie ma formalnej semantyki. Mimo podobieństwa wizualnego, w powyższych wyrażeniach nazwy Prac oraz Zar są ulokowane w dwóch różnych światach. Pierwsza nazwa należy do języka algebry relacji, jest pierwszej kategorii, podlega formalnemu traktowaniu. Natomiast druga nazwa należy do metajęzyka algebry relacji, jest drugiej kategorii, nie podlega formalnemu traktowaniu.

4 © K.Subieta. Obiektowe języki zapytań 09, Folia 4 maj 2004 Dlaczego "niealgebraiczne"? (3) W ten sposób złamana została zasada relatywizmu, zgodnie z którą nazwy nie mogą posiadać fundamentalnie różnej semantyki w zależności od tego, jakiego rodzaju dane oznaczają. Ta zasada staje się szczególnie istotna dla języków obiektowych, gdyż obiekty mogą mieć strukturę hierarchiczną, zaś nazwy mogą oznaczać dane na dowolnym poziomie hierarchii obiektów. Podobny problem dotyczy operatorów. Operator selekcji jest elementem języka tej algebry, należy do pierwszej kategorii, podczas gdy operator < występuje w metajęzyku, jest drugiej kategorii. Powyższa językowo-meta-językowa schizofrenia podważa poprawność definicji semantyki. Podane argumenty są wystarczające aby twierdzić, że tzw. algebry obiektowe są pseudo-matematyczną bzdurą (włączając algebry dla XML).

5 © K.Subieta. Obiektowe języki zapytań 09, Folia 5 maj 2004 Dlaczego "niealgebraiczne"? (4) W podejściu stosowym dowolne operatory nie są indeksowane wyrażeniami meta-językowymi. Nie występuje więc semantyczna schizofrenia nazw dzieląca je na językowe i meta-językowe. Nie ma podziału na nazwy pierwszej kategorii i drugiej kategorii. Każda nazwa ma dokładnie taką samą semantykę i podlega dokładnie tym samym regułom wiązania i zakresu Podobnie z operatorami: nie występuje semantyczne zróżnicowanie operatorów: operator < występuje na tym samym poziomie semantycznym jak operator selekcji where. Koncepcja operatorów niealgebraicznych jest bardzo prosta oraz ma dobrze ugruntowane korzenie w semantyce języków programowania. Definicja operatorów niealgebraicznych będzie się nieco różniła w zależności od tego, który modelu składu (M0 - M3) będzie rozpatrywany. Wszystkie te definicje będą bazowały na podanej niżej podstawowej definicji dla modelu M0.

6 © K.Subieta. Obiektowe języki zapytań 09, Folia 6 maj 2004 Opis procedury eval dla operatora nie-algebr. Aby dokonać ewaluacji zapytania q 1 q 2 wykonaj następujące czynności: Dokonaj ewaluacji zapytania q 1. Zapytanie to zwraca wielozbiór elementów. Dla każdego elementu e należącego do wyniku q 1 wykonaj następujące czynności: Oblicz wartość funkcji nested( e ). Wynik jest zbiorem binderów. Włóż obliczony zbiór binderów jako nową sekcje na wierzchołek stosu ENVS. Dokonaj ewaluacji zapytania q 2 w tym nowym środowisku. Oblicz wynik cząstkowy dla danego elementu e poprzez połączenie e z wynikiem zwróconym przez q 2. Funkcja łącząca zależy od operatora. Usuń nowo wstawioną górną sekcję ze stosu ENVS. Zsumuj wszystkie wyniki cząstkowe w wynik końcowy. Sposób sumowania sumuj ( U ) zależy od rodzaju operatora. Stan stosu środowisk ENVS po zakończeniu ewaluacji jest taki sam, jak przez rozpoczęciem ewaluacji.

7 © K.Subieta. Obiektowe języki zapytań 09, Folia 7 maj 2004 Formalny zapis procedury eval dla oper. niealgebr. procedure eval( q : zapytanie ) begin...... case q jest rozpoznane jako q 1 q 2 : (* q 1, q 2 są zapytaniami, jest operatorem niealgebraicznym *) begin wyniki_pośr: bag of Rezultat; (* lokalna kolekcja wyników pośrednich *) wynik_pośredni: Rezultat; (* lokalna zmienna na wynik pośredni *) wynik_końcowy: Rezultat; (* lokalna zmienna na wynik końcowy *) e: Rezultat; (* lokalna zmienna na element kolekcji zwracanej przez q 1 *) wyniki_pośr := ; (* zerowanie kolekcji wyników pośrednich *) eval( q 1 ); (*q 1 zwraca kolekcję elementów; wynik q 1 na czubku stosu QRES *) for each e in top( QRES ) do (* iteracja po wszystkich elementach wyniku q 1 *) begin push( ENVS, nested( e ) ); (* nowa sekcja na stosie środowisk *) eval( q 2 ); (* wynik q 2 na czubku stosu QRES *) wynik_pośredni := połącz ( e, top( QRES ) ); (* połączenie e z wynikiem q 2 ; zależne od *) wyniki_pośr := wyniki_pośr U { wynik_pośredni }; (* akumulacja wyniku pośredniego *) pop( QRES ); (* usuniecie z QRES wyniku q 2 *) pop( ENVS ); (* usuniecie z ENVS nowej sekcji *) end; wynik_końcowy := sumuj ( wyniki_pośr ); (* zsumowanie wyników pośrednich; zależne od *) pop( QRES ); (* usuniecie z QRES wyniku q 1 *) push( QRES, wynik_końcowy ); (* włożenie na QRES końcowego wyniku *) end;....... end;

8 © K.Subieta. Obiektowe języki zapytań 09, Folia 8 maj 2004 Poglądowy obraz małej bazy danych i 1 Prac i 2 Nazwisko Nowak i 3 Zar 2500 i 4 PracujeW i 5 Prac i 6 Nazwisko Kowalski i 7 Zar 2000 i 8 PracujeW i 9 Prac i 10 Nazwisko Barski i 11 Zar 900 i 16 PracujeW i 13 Miasto Radom i 14 Ulica Wolska i 15 NrDomu 12 i 12 Adres i 17 Dział i 18 Nazwa Produkcja i 19 Lokacja Kielce i 21 Zatrudnia i 20 Lokacja Kraków i 22 Dział i 23 Nazwa Sprzedaż i 24 Lokacja Radom i 25 Zatrudnia i 26 Zatrudnia

9 © K.Subieta. Obiektowe języki zapytań 09, Folia 9 maj 2004 Operator where (selekcja) Składnia: q 1 where q 2 Ograniczenie: podzapytanie q 2 zwraca wartość prawda lub fałsz. Semantyka Dla każdego elementu e zwróconego przez q 1, ENVS jest podwyższany o nested(e) Następnie ewaluowane jest q 2 Po ewaluacji q 2 stos ENVS wraca do poprzedniego stanu e należy do ostatecznego wyniku wyłącznie wtedy, gdy q 2 zwróciło prawda. Objaśnienie funkcji eval Funkcja połącz: dla danego e należącego do wyniku q 1 zwraca jednoelementowy wielozbiór { e } w przypadku, gdy dla tego e podzapytanie q 2 zwróciło prawda, lub pusty wielozbiór { }, jeżeli podzapytanie q 2 zwróciło fałsz. Funkcja sumuj: sumuje (mnogościowo) wszystkie wyniki pośrednie. Przykład: Prac where ( Zar > 1000 )

10 © K.Subieta. Obiektowe języki zapytań 09, Folia 10 maj 2004 Operator where - ilustracja działania Prac where ( Zar > 1000 ) i1i5i9i1i5i9 Prac(i 1 ) Prac(i 5 ) Prac(i 9 ) Dział(i 17 ) Dział(i 22 ) i3i3 i7i7 i 11 i1i5i1i5 Stan stosu ENVS przed ewaluacją Rezultat zwracany przez zapytanie Prac (wiązanie Prac) Rezultat zwracany przez zapytanie Zar (wiązanie Zar) Iteracja po elementach e poprzedniego rezultatu: na ENVS wkłada się nested(e) Nazwisko(i 2 ) Zar(i 3 ) PracujeW(i 4 ) Prac(i 1 ) Prac(i 5 ) Prac(i 9 ) Dział(i 17 ) Dział(i 22 ) Nazwisko(i 6 ) Zar(i 7 ) PracujeW(i 8 ) Prac(i 1 ) Prac(i 5 ) Prac(i 9 ) Dział(i 17 ) Dział(i 22 ) Nazwisko(i 10 ) Zar(i 11 ) Adres(i 12 ) PracujeW(i 16 ) Prac(i 1 ) Prac(i 5 ) Prac(i 9 ) Dział(i 17 ) Dział(i 22 ) Rezultat dereferencji wymuszanej przez operator > 2500 2000 900 Rezultat zwracany przez zapytanie 1000 1000 prawda fałsz Rezultat zwracany przez zapytanie Zar>1000 Końcowy rezultat zapytania

11 © K.Subieta. Obiektowe języki zapytań 09, Folia 11 maj 2004 Operator kropki (projekcja, nawigacja) Składnia: q 1. q 2 Semantyka Dla każdego elementu e zwróconego przez q 1, ENVS jest podwyższany o nested(e) Następnie ewaluowane jest q 2 Po ewaluacji q 2 stos ENVS wraca do poprzedniego stanu Ostateczny wynik jest sumą mnogościową wyników q 2 Objaśnienie funkcji eval Funkcja połącz: ignoruje e; zwraca wynik podzapytania q 2. Funkcja sumuj: sumuje (mnogościowo) wszystkie wyniki pośrednie. Przykład: Prac. Zar Operator kropki przykrywa tzw. wyrażenia ścieżkowe (path expressions) w najbardziej uniwersalnej postaci, pozwalając je jednocześnie dowolnie kombinować z innymi operatorami.

12 © K.Subieta. Obiektowe języki zapytań 09, Folia 12 maj 2004 Operator kropki - ilustracja działania Prac. Zar i1i5i9i1i5i9 i3i3 i7i7 i 11 Stan stosu ENVS przed ewaluacją Rezultat zwracany przez zapytanie Prac (wiązanie Prac) Rezultat zwracany przez zapytanie Zar (wiązanie Zar) Iteracja po elementach e poprzedniego rezultatu: na ENVS wkłada się nested(e) Końcowy rezultat zapytania i 3 i 7 i 11 Prac(i 1 ) Prac(i 5 ) Prac(i 9 ) Dział(i 17 ) Dział(i 22 ) Nazwisko(i 2 ) Zar(i 3 ) PracujeW(i 4 ) Prac(i 1 ) Prac(i 5 ) Prac(i 9 ) Dział(i 17 ) Dział(i 22 ) Nazwisko(i 6 ) Zar(i 7 ) PracujeW(i 8 ) Prac(i 1 ) Prac(i 5 ) Prac(i 9 ) Dział(i 17 ) Dział(i 22 ) Nazwisko(i 10 ) Zar(i 11 ) Adres(i 12 ) PracujeW(i 16 ) Prac(i 1 ) Prac(i 5 ) Prac(i 9 ) Dział(i 17 ) Dział(i 22 )

13 © K.Subieta. Obiektowe języki zapytań 09, Folia 13 maj 2004 Operator zależnego złączenia Składnia: q 1 join q 2 Semantyka Dla każdego e zwróconego przez q 1, ENVS jest podwyższany o nested(e) Następnie ewaluowane jest q 2 Po ewaluacji q 2 stos ENVS wraca do poprzedniego stanu Ostateczny wynik jest sumą mnogościową wszystkich struktur, w których na początku jest e, zaś dalej jest element wyniku q 2 zwrócony dla tego e. Objaśnienie funkcji eval Funkcja połącz: zarówno e jak i każdy element e 2 zwracany przez q 2 traktuje jako struktury (jednoelementowe lub wieloelementowe). Dla każdego e 2 zwracanego przez q 2 tworzy strukturę poprzez połączenie e oraz e 2. Wynikiem pośrednim jest kolekcja wszystkich takich struktur. Funkcja sumuj: sumuje (mnogościowo) wszystkie wyniki pośrednie. Przykład: Prac join Zar Zależne złączenie jest zdefiniowane w ODMG OQL (klauzula from) w znacznie ograniczonej postaci w stosunku do powyższej definicji.

14 © K.Subieta. Obiektowe języki zapytań 09, Folia 14 maj 2004 Operator zależnego złączenia - ilustracja działania Prac join Zar i1i5i9i1i5i9 i3i3 i7i7 i 11 Stan stosu ENVS przed ewaluacją Rezultat zwracany przez zapytanie Prac (wiązanie Prac) Rezultat zwracany przez zapytanie Zar (wiązanie Zar) Iteracja po elementach e poprzedniego rezultatu: na ENVS wkłada się nested(e) Końcowy rezultat zapytania struct(i 1, i 3 ) struct(i 5, i 7 ) struct(i 9, i 11 ) Prac(i 1 ) Prac(i 5 ) Prac(i 9 ) Dział(i 17 ) Dział(i 22 ) Nazwisko(i 2 ) Zar(i 3 ) PracujeW(i 4 ) Prac(i 1 ) Prac(i 5 ) Prac(i 9 ) Dział(i 17 ) Dział(i 22 ) Nazwisko(i 6 ) Zar(i 7 ) PracujeW(i 8 ) Prac(i 1 ) Prac(i 5 ) Prac(i 9 ) Dział(i 17 ) Dział(i 22 ) Nazwisko(i 10 ) Zar(i 11 ) Adres(i 12 ) PracujeW(i 16 ) Prac(i 1 ) Prac(i 5 ) Prac(i 9 ) Dział(i 17 ) Dział(i 22 )

15 © K.Subieta. Obiektowe języki zapytań 09, Folia 15 maj 2004 Operator sortowania Składnia: q 1 order by q 2 Semantyka Wykonywane jest zapytanie: q 1 join dereferencja( q 2 ) Wynik (bag) jest sortowany według części struktur zwróconej przez q 2. Po posortowaniu wynik jest sekwencją. Końcowy wynik uzyskuje się poprzez projekcję tej sekwencji (bez zmiany kolejności elementów na części struktur zwrócone przez q 1. Np. Prac order by Nazwisko Prac order by ((PracujeW.Dział.Nazwa), Zarobek) Operator ten można dodatkowo wyposażyć w kwalifikatory asc (wzrastająco) i desc (malejąco) przy każdej składowej q 2. Np. Prac order by ((PracujeW.Dział.Nazwa) asc, Zarobek desc) Operator asc jest komentarzem, operator desc jest odwrotnością wartości: np. 5 desc oznacza -5, "abceg" desc oznacza "zyxvt", itd. Operator ten należy parametryzować (najlepiej konfiguracyjnie) funkcją porównania elementów ( zależną od języka: angielski, polski, niemiecki,.. ).

16 © K.Subieta. Obiektowe języki zapytań 09, Folia 16 maj 2004 Kwantyfikator egzystencjalny Składnia: q 1 ( q 2 ) lub q 1 q 2 Ograniczenie: podzapytanie q 2 zwraca wartość prawda lub fałsz. Semantyka Dla każdego e zwróconego przez q 1, ENVS jest podwyższany o nested(e) Następnie ewaluowane jest q 2 Po ewaluacji q 2 stos ENVS wraca do poprzedniego stanu Ostateczny wynik jest prawda wtedy i tylko wtedy, jeżeli dla co najmniej jednego e podzapytanie q 2 zwróciło prawda. Objaśnienie funkcji eval Funkcja połącz: ignoruje e; zwraca wynik podzapytania q 2. Funkcja sumuj: Zwraca prawda jeżeli co najmniej jeden wynik pośredni zwrócony przez q 2 jest prawda; w przeciwnym wypadku zwraca fałsz. Przykład: Prac ( Zar > 1000 )

17 © K.Subieta. Obiektowe języki zapytań 09, Folia 17 maj 2004 Kwantyfikator uniwersalny Składnia: q 1 ( q 2 ) lub q 1 q 2 Ograniczenie: podzapytanie q 2 zwraca wartość prawda lub fałsz. Semantyka Dla każdego e zwróconego przez q 1, ENVS jest podwyższany o nested(e) Następnie ewaluowane jest q 2 Po ewaluacji q 2 stos ENVS wraca do poprzedniego stanu Ostateczny wynik jest prawda wtedy i tylko wtedy, jeżeli dla wszystkich e podzapytanie q 2 zwróciło prawda. Jeżeli q 1 zwróciło pusty wielozbiór, to wynik także jest prawda. Objaśnienie funkcji eval Funkcja połącz: ignoruje e; zwraca wynik podzapytania q 2. Funkcja sumuj: Zwraca fałsz jeżeli co najmniej jeden wynik pośredni zwrócony przez q 2 jest fałsz ; w przeciwnym wypadku zwraca prawda. Przykład: Prac ( Zar > 1000 )

18 © K.Subieta. Obiektowe języki zapytań 09, Folia 18 maj 2004 Kwantyfikator uniwersalny - ilustracja działania Prac ( Zar > 1000 ) i1i5i9i1i5i9 i3i3 i7i7 i 11 Stan stosu ENVS przed ewaluacją Rezultat zwracany przez zapytanie Prac (wiązanie Prac) Rezultat zwracany przez zapytanie Zar (wiązanie Zar) Iteracja po elementach e poprzedniego rezultatu: na ENVS wkłada się nested(e) Rezultat dereferencji wymuszanej przez operator > 2500 2000 900 Rezultat zwracany przez zapytanie 1000 1000 prawda fałsz Rezultat zwracany przez zapytanie Zar>1000 Końcowy rezultat zapytania fałsz Prac(i 1 ) Prac(i 5 ) Prac(i 9 ) Dział(i 17 ) Dział(i 22 ) Nazwisko(i 2 ) Zar(i 3 ) PracujeW(i 4 ) Prac(i 1 ) Prac(i 5 ) Prac(i 9 ) Dział(i 17 ) Dział(i 22 ) Nazwisko(i 6 ) Zar(i 7 ) PracujeW(i 8 ) Prac(i 1 ) Prac(i 5 ) Prac(i 9 ) Dział(i 17 ) Dział(i 22 ) Nazwisko(i 10 ) Zar(i 11 ) Adres(i 12 ) PracujeW(i 16 ) Prac(i 1 ) Prac(i 5 ) Prac(i 9 ) Dział(i 17 ) Dział(i 22 )

19 © K.Subieta. Obiektowe języki zapytań 09, Folia 19 maj 2004 Kroki ewaluacji zapytania z pomocniczą nazwą (Prac as x) where ( ( x. Zar ) > 1000 ) i1i5i9i1i5i9 i3i3 i7i7 i 11 x(i 1 ) x(i 5 ) Rezultat zwracany przez zapytanie Prac Rezultat zwracany przez zapytanie x (wiązanie x) Iteracja po elementach e poprzedniego rezultatu: na ENVS wkłada się nested(e) Rezultat dereferencji wymuszanej przez operator > 2500 2000 900 Rezultat zwracany przez zapytanie 1000 1000 prawda fałsz Rezultat zwracany przez zapytanie Zar>1000 Końcowy rezultat zapytania Rezultat zwracany przez zapytanie Prac as x x(i 1 ) x(i 5 ) x(i 9 ) i1i1 i5i5 i9i9 Rezultat zwracany przez zapytanie Zar x(i 1 ) Prac(i 1 ) Prac(i 5 ) Prac(i 9 ) Dział(i 17 ) Dział(i 22 ) x(i 5 ) Prac(i 1 ) Prac(i 5 ) Prac(i 9 ) Dział(i 17 ) Dział(i 22 ) x(i 9 ) Prac(i 1 ) Prac(i 5 ) Prac(i 9 ) Dział(i 17 ) Dział(i 22 ) Nazwisko(i 2 ) Zar(i 3 ) PracujeW(i 4 ) x(i 1 ) Prac(i 1 ) Prac(i 5 ) Prac(i 9 ) Dział(i 17 ) Dział(i 22 ) Nazwisko(i 6 ) Zar(i 7 ) PracujeW(i 8 ) x(i 5 ) Prac(i 1 ) Prac(i 5 ) Prac(i 9 ) Dział(i 17 ) Dział(i 22 ) Nazwisko(i 10 ) Zar(i 11 ) Adres(i 12 ) PracujeW(i 16 ) x(i 9 ) Prac(i 1 ) Prac(i 5 ) Prac(i 9 ) Dział(i 17 ) Dział(i 22 ) Iteracja po elementach e poprzedniego rezultatu: na ENVS wkłada się nested(e)

20 © K.Subieta. Obiektowe języki zapytań 09, Folia 20 maj 2004 Zamiana "zmiennej" na etykietę struktury Dla zapytania (Prac as x) where (( x. Zar ) > 1000 ) końcowy wynik jest różny od wyniku zapytania Prac where Zar > 1000, mianowicie, elementy wyniku są opatrzone nazwą x. Elementy takie można uważać za proste struktury (w sensie języków C/C++), których jedynym polem jest pole o nazwie x. W standardzie ODMG są "tajemnicze" miejsca, w których zmienna dziedzinowa zmienia się w etykietę struktury. Standard tego nie wyjaśnia. Dopiero na gruncie SBA widać jasno, dlaczego tak się dzieje. Wymagało to jednak bardzo istotnych założeń odnośnie semantyki. Standard ODMG jest semantycznie nieprecyzyjny, więc nie jest w stanie tego wyjaśnić. Tego efektu nie można także wyjaśnić na gruncie algebry obiektowej, rachunku obiektowego, lub innego tradycyjnego formalizmu. Można pokazać, że zapytanie Prac where Zar > 1000 jest równoważne zapytaniu ((Prac as x) where (( x. Zar ) > 1000 )). x

21 © K.Subieta. Obiektowe języki zapytań 09, Folia 21 maj 2004 SBQL - schematy BD dla przykładów zapytań Dział [0..*] NrD Nazwa Lokacja[1..*] Schemat obiektowy (diagram klas) PracujeW Zatrudnia [1..*] Prac[0..*] NrP Nazwisko Stan Zar Adres [0..1] Miasto Ulica NrDomu Prac NrP Nazwisko Stan Zar PracujeW Dział NrD Nazwa Szef Lokacje NrD Lokacja Adres NrP Miasto Ulica NrDomu Schemat relacyjny Kieruje [0..1] Szef Asocjacje są zrealizowane jako (bliźniacze) obiekty pointerowe Strzałki modelują asocjacje; prowadzą od klucza obcego do głównego

22 © K.Subieta. Obiektowe języki zapytań 09, Folia 22 maj 2004 Podaj pełną informację o pracownikach: Prac Jest to odpowiednik zapytania SQL: select * from Prac. Wbrew popularnym opiniom, lukier select... from... będziemy uważać za szkodliwy. Różnice semantyczne: zapytanie SQL zwraca tabelę Prac, podczas gdy Prac zwraca referencje do obiektów Prac. Zapytania SBQL nigdy nie zwracają obiektów. SBQL - przykłady zapytań (1) Podaj nazwiska wszystkich pracowników: Prac. Nazwisko Zapytanie jest odpowiednikiem zapytania SQL: select Nazwisko from Prac. Zapytanie SQL zwraca jedno-kolumnową tablicę stringów będących nazwiskami, natomiast zapytanie SBQL zwraca tablicę referencji do pod-obiektów Nazwisko w obiektach Prac. Do tej tablicy można oczywiście zastosować operator dereferencji, który referencje na stringi, ale automatyczna dereferencja prowadzi do straty informacji. Referencje są bardziej uniwersalne niż stringi, gdyż. np. mogą być użyte po lewej stronie operacji podstawienia.

23 © K.Subieta. Obiektowe języki zapytań 09, Folia 23 maj 2004 SBQL - przykłady zapytań (2) Podaj pełną informację o Kowalskim: Prac where (Nazwisko = Kowalski) SQL: select * from Prac where Nazwisko = Kowalski. W odróżnieniu od SQL, zapytanie w SBQL zwróci referencję do obiektu Kowalskiego. Referencję tę można następnie skonsumować zdaniem imperatywnym; np. można usunąć obiekt Kowalskiego zdaniem delete Prac where (Nazwisko = Kowalski); W dalszych przykładach będziemy często rezygnować z nawiasów. Podaj zarobek Kowalskiego: (Prac where Nazwisko = Kowalski). Zar SQL: select Zar from Prac where Nazwisko = Kowalski. W odróżnieniu od SQL, zapytanie w SBQL zwróci referencję do zarobku Kowalskiego. Referencję tę można następnie skonsumować zdaniem imperatywnym; np. można zmienić zarobek Kowalskiego zdaniem: ((Prac where Nazwisko = Kowalski). Zar) := 5000; Odpowiada to zdaniu aktualizacyjnemu SQL: update Prac set Zar = 5000 where Nazwisko = Kowalski;

24 © K.Subieta. Obiektowe języki zapytań 09, Folia 24 maj 2004 SBQL - przykłady zapytań (3) Podaj numery i nazwiska pracowników zarabiających więcej niż 1000. (Prac where Zar > 1000). (NrP, Nazwisko) Wynikiem zapytania jest wielozbiór struktur struct{i NrP, i Nazwisko }, gdzie w każdej strukturze pierwsza referencja dotyczy atrybutu NrP, zaś druga - atrybutu Nazwisko. Przecinek oznacza operator algebraiczny konstruktora struktury. Zwróć referencję do danej pointerowej PracujeW dla pracownika Kowalskiego: (Prac where Nazwisko = Kowalski). PracujeW Zapytanie nie ma odpowiednika w SQL i OQL. Zapytanie takie ma jednak sens, gdyż może być podzapytaniem szerszego zapytania. Ma również sens z powodu operacji aktualizacyjnych. Przykładowo, jeżeli chcielibyśmy przenieść Kowalskiego do działu Sprzedaż, wówczas takie zdanie może mieć postać: (Prac where Nazwisko=Kowalski).PracujeW := &(Dział where Nazwa=Sprzedaż) Z lewej strony podstawienia obliczana jest l-wartość (l-value), czyli referencja do danej pointerowej PracujeW w obiekcie Kowalskiego. Z prawej strony podstawienia mamy r-wartość (r-value), która jest referencją do działu Sprzedaż.

25 © K.Subieta. Obiektowe języki zapytań 09, Folia 25 maj 2004 SBQL - przykłady zapytań (4) Podaj pełne dane o dziale, w którym pracuje Kowalski: ((Prac where Nazwisko = Kowalski). PracujeW ). Dział Zapytanie to zwraca referencję do obiektu działu, w którym pracuje Kowalski. OQL: select d from Prac as p, p.PracujeW as d where p.Nazwisko = Kowalski OQL unika nazwy Dział. Jest to niewłaściwe z dwóch powodów. (1) Jak pokazuje poprzedni przykład, istnieje potrzeba rozróżnienia pomiędzy referencją do pointera prowadzącego do obiektu, a referencją do samego obiektu. (2) Zapytanie w SBQL jest bardziej czytelne, gdyż explicite używa nazwy Dział, oznaczającej końcowy efekt ewaluacji. Podaj nazwę działu, w którym pracuje Kowalski: (Prac where Nazwisko = Kowalski). PracujeW. Dział. Nazwa Zapytanie to zwraca referencję do nazwy działu, w którym pracuje Kowalski. OQL: select p.PracujeW.Nazwa from Prac as p where p.Nazwisko = Kowalski Przykład ilustruje tzw. wyrażenia ścieżkowe (path expressions), czyli nawigację wzdłuż ścieżki wyznaczonej powiązaniami pointerowymi lub w dół hierarchii obiektów. W SBQL takie wyrażenia są efektem definicji kropki - wyrażenie czytamy jako (((Prac where Nazwisko = Kowalski). PracujeW). Dział). Nazwa

26 © K.Subieta. Obiektowe języki zapytań 09, Folia 26 maj 2004 SBQL - przykłady zapytań (5) Wyrażenia ścieżkowe mogą być dowolnie długie. Np. nazwisko szefa Kowalskiego: (Prac where Nazwisko = Kowalski). PracujeW. Dział. Szef. Prac. Nazwisko Nie definiujemy specjalnych wyrażeń ścieżkowych, lecz wykorzystujemy operator kropki. Uzyskujemy przez to możliwość dowolnego kombinowania wyrażeń ścieżkowych z innymi operatorami. Przykładowo, poniższe wyrażenie SBQL (Prac where budynek D (PracujeW.Dział.Lokacja)).(Nazwisko, (Adres.Miasto)) specyfikuje nazwisko i miasto pracownika pracującego w budynku D. ODMG OQL ogranicza możliwość używania wygodnych wyrażeń ścieżkowych poprzez niezbyt mądry w tym kontekście lukier select...from...where... oraz poprzez przyjęcie (również niezbyt mądrego) założenia, że operator kropki może się pojawić tylko wtedy, jeżeli wyrażenie przed kropką zwraca dokładnie jedną wartość. Obydwa te założenia są odrzucone przy definiowaniu operatorów niealgebraicznych.

27 © K.Subieta. Obiektowe języki zapytań 09, Folia 27 maj 2004 SBQL - przykłady zapytań (6) Podaj wszystkie informacje o pracownikach zarabiających więcej od Kowalskiego: Prac where Zar > ((Prac where Nazwisko = Kowalski).Zar) SQL: select * from Prac where Zar > select Zar from Prac where Nazwisko = Kowalski W zapytaniu tym występuje dwa razy nazwa Zar, ale dzięki stosowej semantyce każde z tych wystąpień jest inaczej wiązane: pierwsze Zar jest wiązane na stosie posiadającym 2 sekcje, drugie Zar na stosie posiadającym 3 sekcje. Dla każdego pracownika zwróć pełną informację o pracowniku i jego dziale. Prac join (PracujeW. Dział) Skorzystaliśmy z operatora zależnego złączenia. Wynikiem jest wielozbiór struktur struct{ i Prac, i Dział }, gdzie pierwszy składnik każdej struktury jest referencją do obiektu pracownika, zaś drugi jest referencją do obiektu jego działu. Zapytanie to ma odpowiednik w OQL: select struct(pr: p, dz: d) from Prac as p, p.PracujeW as d Nie jest to dokładny odpowiednik, ponieważ w OQL struktury muszą mieć etykiety (tutaj pr i dz), a ponadto OQL nie wprowadza referencji.

28 © K.Subieta. Obiektowe języki zapytań 09, Folia 28 maj 2004 SBQL - przykłady zapytań (7) Dla każdego pracownika zwróć pełną informację o pracowniku i jego dziale. Analogiczne zapytanie odnoszące się do struktury relacyjnej ma postać: Prac join (Dział where PracujeW = NrD) lub (z użyciem produktu kartezjańskiego) (Prac Dział ) where PracujeW = NrD To ostatnie zapytanie ma odpowiednik w SQL: select * from Prac, Dział where PracujeW = NrD Nie jest to dokładny odpowiednik, ponieważ wynikiem nie jest wielozbiór z parami referencji (jak w przypadku SBQL), lecz zbiorcza tabela zawierająca zarówno atrybuty tabeli Prac jak i tabeli Dział.

29 © K.Subieta. Obiektowe języki zapytań 09, Folia 29 maj 2004 SBQL - przykłady zapytań (8) Podaj informację o działach i średnich zarobkach pracowników w działach: Dział join avg(Zatrudnia.Prac.Zar) Wynikiem zapytania jest wielozbiór struktur struct{ i Dział, średni_zar }, gdzie pierwszy składnik każdej struktury jest referencją do obiektu Dział, zaś drugi jest liczbą będącą średnią zarobków w tym dziale. Następny slajd przedstawia stany stosu środowisk przy wiązaniu poszczególnych nazw występujących w tym zapytaniu. W OQL zapytanie to wymaga użycia opcji group by, która została wyspecyfikowana nieprecyzyjnie, toteż nie ma pewności jak jej użyć. Podobne zapytanie można sformułować przy pomocy następującego zdania SQL: select d.*, avg(p.Zar) from Dział d, Prac p where d.NrD = p.PracujeW group by d.NrD Wadą jest konieczność użycia operatora group by, który jest nieortogonalny, prowadzi do nowego jakościowo warunku (having), ma rafy semantyczne, oraz sprawia trudności z optymalizacją zapytań. W SBQL unikamy tego wątpliwego operatora, również dla struktur relacyjnych: Dział join avg((Prac where PracujeW = NrD ). Zar)

30 © K.Subieta. Obiektowe języki zapytań 09, Folia 30 maj 2004 SBQL - przykłady zapytań (9) ( Dział join avg(( Zatrudnia. Prac ). Zar ) ) Prac(..) Prac(..),... Dział(..) Dział(..)... Nrd(..), Nazwa(..) Lokacja(..) Lokacja(..)... Zatrudnia(..) Zatrudnia(..)... Szef(..) Prac(..) Prac(..),... Dział(..) Dział(..)... NrP (..) Nazwisko (..) Stan (..) Zar (..) Adres(..) PracujeW(..) Kieruje(..) Nrd(..), Nazwa(..) Lokacja(..) Lokacja(..)... Zatrudnia(..) Zatrudnia(..)... Szef(..) Prac(..) Prac(..),... Dział(..) Dział(..)... Prac(..) Nrd(..), Nazwa(..) Lokacja(..) Lokacja(..)... Zatrudnia(..) Zatrudnia(..)... Szef(..) Prac(..) Prac(..),... Dział(..) Dział(..)... Nrd(..), Nazwa(..) Lokacja(..) Lokacja(..)... Zatrudnia(..) Zatrudnia(..)... Szef(..) Prac(..) Prac(..),... Dział(..) Dział(..)... Nrd(..), Nazwa(..) Lokacja(..) Lokacja(..)... Zatrudnia(..) Zatrudnia(..)... Szef(..) Prac(..) Prac(..),... Dział(..) Dział(..)... Prac(..) Prac(..),... Dział(..) Dział(..)... Stany stosu środowisk przy wiązaniu nazw występujących w zapytaniu Dział join avg(Zatrudnia.Prac.Zar)

31 © K.Subieta. Obiektowe języki zapytań 09, Folia 31 maj 2004 SBQL - przykłady zapytań (10) Podaj średnią liczbę pracowników w działach. Dla schematu obiektowego: avg( Dział. count(Zatrudnia)) Dla schematu relacyjnego: avg( Dział. count(Prac where NrD = PracujeW)) Analogiczne zdanie w standardzie SQL-89 nie istnieje; zapytanie można wyrazić z pomocą dodatkowej perspektywy. W standardzie SQL-92 zdanie to można sformułować przy pomocy opcji group by. Opcja ta prowadzi do znanej rafy semantycznej, polegającej na tym, że jeżeli pewien dział nie będzie miał ani jednego pracownika, wówczas nie zostanie uwzględniony przy obliczaniu średniej. W SBQL ta rafa nie występuje.

32 © K.Subieta. Obiektowe języki zapytań 09, Folia 32 maj 2004 SBQL - przykłady zapytań (11) Dla pracowników zarabiających więcej niż 2000 i pracujących w budynku A podaj nazwisko, stanowisko, nazwę działu i nazwisko szefa działu. ((Prac where Zar > 2000) join (PracujeW. (Dział where "budynek A" Lokacja ))). (Nazwisko, Stan, Nazwa, (Szef.Prac.Nazwisko)) Wynikiem będzie kolekcja struktur struct{i Nazwisko1, i Stan, i Nazwa, i Nazwisko2 }, gdzie każda struktura zawiera cztery referencje. Czy w każdym dziale jest pracownik zarabiający więcej od swojego szefa? Dział ( Zatrudnia.Prac ( Zar > Szef.Prac.Zar)) Wynikiem zapytania jest wartość boolowska prawda lub fałsz. Kwantyfikatory są operatorami niealgebraicznymi, wobec czego (jak w całym SBQL), użycie nazw pomocniczych (czyli zmiennych związanych kwantyfikatorami) nie jest konieczne. Jeżeli zachodziłaby potrzeba, wówczas takie zmienne można byłoby powołać w postaci pomocniczych nazw: Dział as x ( x.Zatrudnia.Prac as y ( y.Zar > x.Szef.Prac.Zar)) Zmuszanie użytkowników do obowiązku stosowania pomocniczych nazw, jak w OQL, jest konsekwencją pseudo-matematycznych koncepcji semantyki.

33 © K.Subieta. Obiektowe języki zapytań 09, Folia 33 maj 2004 SBQL - przykłady zapytań (12) Podaj pracowników którzy na pewno mieszkają w Olsztynie. Zgodnie ze schematem, adres pracownika jest daną opcyjną i złożoną. W terminologii modelu relacyjnego, brak adresu dla pracownika oznacza, ze w tym miejscu jest zapisana wartość zerowa (null). Wartości te wymagają w SQL specjalnych opcji, które są niespójne oraz komplikują semantykę i pragmatykę języka. W naszym podejściu będziemy ich unikać. Zamiast operacji na wartościach zerowych można zastosować kwantyfikatory. Prac where Adres (Miasto = Olsztyn) Podaj pracowników którzy albo na pewno mieszkają w Olsztynie albo być może mieszkają w Olsztynie, ponieważ ich adres jest nieznany: Prac where Adres (Miasto = Olsztyn) Pamiętać: kwantyfikator działający na pustym zbiorze zwraca true.

34 © K.Subieta. Obiektowe języki zapytań 09, Folia 34 maj 2004 SBQL - przykłady zapytań (13) Podaj nazwiska i zarobki projektantów zarabiających więcej od swoich szefów: Zilustrujemy kilka stylów tworzenia zapytań, które są konsekwencją przyjętych przez nas definicji: Styl SQL (schemat relacyjny): (((Prac as x) (Dział as y) (Prac as z)) where x.Stan = projektant and x.PracujeW = y.NrD and y.Szef = z.NrP and x.Zar > z.Zar). (x.Nazwisko, x.Zar) Styl OQL (schemat obiektowy): ((Prac as x) join (x.PracujeW.Dział as y) join (y.Szef.Prac as z) where x.Stan =projektant and x.Zar > z.Zar). (x.Nazwisko, x.Zar) Wariant minimalny SBQL (schemat obiektowy ): (Prac where Stan = projektant and Zar > (PracujeW.Dział.Szef.Prac.Zar)). (Nazwisko,Zar) Styl rachunku dziedzinowego zapisanego w SBQL (schemat relacyjny): (((Prac.(Nazwisko as np, Zar as zp, Stan as sp, PracujeW as dp)) (Dział.( Nrd as nd, Szef as sd)) (Prac.(Zar as zs, NrP as ns))) where sp = projektant and dp = nd and sd = ns and zp > zs). (np, zp)

35 © K.Subieta. Obiektowe języki zapytań 09, Folia 35 maj 2004 SBQL - podsumowanie przykładów Poprzez przykłady, szczególnie z poprzedniego slajdu, pokazujemy, że debaty o wyższości formalizmu A nad formalizmem B oraz obecne spory o języki zapytań można pogodzić na gruncie podejścia stosowego. Istotne jest, jakie struktury danych dopuszczamy w systemie zarządzania bazą danych. Z chwilą precyzyjnej definicji tych struktur dla dowolnych z nich można zbudować język zapytań na gruncie podejścia stosowego. Teza M.Stonebrakera o tym, że dla modeli obiektowych nie można zbudować języka zapytań, jest nonsensem; próbą zbudowania fałszywego stereotypu. Struktury relacyjne nie mają w tym względzie jakiejkolwiek przewagi nad strukturami obiektowymi, i odwrotnie. Gorąca debata ideologów świata komercyjnego odnośnie tego, który paradygmat struktur danych i języków zapytań jest lepszy, na gruncie SBA staje się jałową demagogiczną retoryką, pustosłowiem pozbawionym merytorycznych argumentów. Szczególnie wtedy, gdy powołuje się na mocne podstawy matematyczne".