Obiektowe języki zapytań

30
© K.Subieta. Obiektowe języki zapytań 15, Folia 1 czerwiec 2004 Obiektowe języki zapytań Wykładowca: Kazimierz Subieta Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa [email protected] Instytut Podstaw Informatyki PAN, Warszawa [email protected] Wykład 15: Reguły zakresu Parametry procedur i metod Procedury rekurencyjne Optymalizacja poprzez modyfikację zapytań

description

Obiektowe języki zapytań. Wykład 15: Reguły zakresu Parametry procedur i metod Procedury rekurencyjne Optymalizacja poprzez modyfikację zapytań. Wykładowca : Kazimierz Subieta Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa [email protected] - PowerPoint PPT Presentation

Transcript of Obiektowe języki zapytań

Page 1: Obiektowe języki zapytań

© K.Subieta. Obiektowe języki zapytań 15, Folia 1 czerwiec 2004

Obiektowe języki zapytań

Wykładowca: Kazimierz Subieta

Polsko-Japońska Wyższa SzkołaTechnik Komputerowych, [email protected]

Instytut Podstaw Informatyki PAN, [email protected]

Wykład 15: Reguły zakresu Parametry procedur i metodProcedury rekurencyjneOptymalizacja poprzez modyfikację zapytań

Page 2: Obiektowe języki zapytań

© K.Subieta. Obiektowe języki zapytań 15, Folia 2 czerwiec 2004

Reguły zakresu

Reguły zakresu są wyznaczone przez kolejność ustawienia sekcji ENVS oraz regułami ich przesłaniania - powinny być naturalne i logiczne dla programistów.

Nie zawsze jest to oczywiste. • Np. dlaczego podczas wiązania nazwy występującej w ciele metody najpierw

jest odwiedzana sekcja z prywatnymi własnościami klasy/obiektu, a dopiero później z publicznymi? Dlaczego nie odwrotnie?

• Gdyby ta kolejność została zmieniona, własności semantyczne języka również uległyby zmianie, gdyż różne sekcje mogą posiadać bindery z tymi samymi nazwami.

W obiektowości jest kilka sytuacji, gdy nie da się uniknąć binderów z tymi samymi nazwami na stosie środowiskowy.

Istotą koncepcji stosu środowiskowego jest to, aby nie dopuszczać do wiązania, które nie jest oczekiwane przez programistę.

Regułami zakresu rządzi zdrowy rozsadek oraz dwie zasady: • zasada priorytetu lokalnego środowiska• zasada leksykalnego zakresu.

Page 3: Obiektowe języki zapytań

© K.Subieta. Obiektowe języki zapytań 15, Folia 3 czerwiec 2004

Zasady rządzące regułami zakresu

Zasada priorytetu lokalnego środowiska:

Przy wiązaniu nazw lokalne środowisko ma priorytet przed dowolnym środowiskiem bardziej globalnym.• Na mocy tej zasady na samej górze stosu ENVS znajduje się lokalne

środowisko metody, niżej jest środowisko przetwarzanego obiektu, jeszcze niżej środowisko sesji, potem środowisko bazy danych, wreszcie środowisko całego systemu komputerowego.

• Zasada ta jest podstawą zagnieżdżania operatorów nie-algebraicznych.

Zasada leksykalnego zakresu (lexical scoping):

Nazwa nie może być wiązana do bytu, którego nie mógł być świadomy programista w momencie pisania zapytania lub programu. • Dotyczy to: lokalnych środowisk innych procedur,

• wszelkich własności prywatnych (obiektów, klas, modułów),

• kodów, które pojawią się niezależnie i później niż moment pisania danego zapytania lub programu.

Page 4: Obiektowe języki zapytań

© K.Subieta. Obiektowe języki zapytań 15, Folia 4 czerwiec 2004

Przykład skutków reguł zakresu

Rozpatrzmy zapytanie q1 q2 i załóżmy, że aktualnie wykonywana jest metoda m1 występująca w q2 i przetwarzająca referencję ri . Niech powyższe zapytanie występuje wewnątrz ciała metody m2, która została wywołana z procedury p.

Sytuacja na stosie środowiskowym:

Zilustrowana jest zasada leksykalnego zakresu: programista piszący metodę m1 nie znał środowisk zaznaczonych na rysunku na czarno, wobec czego nazwy występujące w m1 nie mogą być w nich wiązane.

Kolejność wiązania nazw występujących w ciele m1

Sekcje wywołania m1 dla ri Sekcje indukowane przez q2, w którym

znajduje się wołanie metody m1

Sekcje indukowane przez dla ri

Sekcje indukowane przez wywołanie m2

Sekcje indukowane przez wywołanie p

.........

Sekcje bazowe ENVS

Page 5: Obiektowe języki zapytań

© K.Subieta. Obiektowe języki zapytań 15, Folia 5 czerwiec 2004

Parametry procedur, funkcji i metod

Na gruncie podejścia stosowego można bez trudu wyjaśnić semantykę metod transmisji parametrów do wnętrza ciała procedury.

Niżej pokażemy semantykę metod określanych jako • wołanie przez wartość (call-by-value),

• wołanie przez referencję (call-by-reference),

• ścisłe wołanie przez wartość (strict-call-by-value),

• wołanie z etykietowanymi parametrami aktualnymi.

Wybór tych metod zależy od przeznaczenia języka i preferencji jego projektanta.

Page 6: Obiektowe języki zapytań

© K.Subieta. Obiektowe języki zapytań 15, Folia 6 czerwiec 2004

Wołanie przez wartość (call-by-value) (1)

Istnieją dwa warianty tej metody, jedna znana z Pascala, druga znana z C. • W języku Pascal wewnątrz ciała procedury jej parametr jest innym bytem niż

zmienna programistyczna, w szczególności, nie wolno na niego podstawiać. • W języku C wewnątrz ciała procedury parametr ma dokładnie taką samą

semantykę jak lokalna zmienna. Obydwie metody można opisać i zaimplementować w ramach podejścia

stosowego. Przyjmijmy składnię deklaracji procedury w postaci:procedure NazwaProcedury( ...; in NazwaParam; ...){...ciało...}

oraz składnię wywołania: NazwaProcedury( ...; zapytanie; ...)

Niech powyższe zapytanie zwróci bag{ v1, v2, ... }, gdzie v1, v2, ... Rezultat.

W Pascalu po wywołaniu procedury zapis aktywacyjny będzie zawierał:..., NazwaParam( deref(v1) ), NazwaParam( deref(v2) ), ...

Dzięki temu wewnątrz ciała procedury do parametru można odwołać się poprzez NazwaParam, zaś wynikiem tego odwołania będzie bag{deref(v1), deref(v2), ... }.

Page 7: Obiektowe języki zapytań

© K.Subieta. Obiektowe języki zapytań 15, Folia 7 czerwiec 2004

Wołanie przez wartość (call-by-value) (2)

• Funkcja deref dokonuje dereferencji, jeżeli jej argumentem jest referencja, w przeciwnym przypadku zwraca swój argument (nic nie robi).

• Wewnątrz ciała nie można dokonać podstawienia na NazwaParam, gdyż wiązanie nazwy NazwaParam nie zwraca referencji. Nazwą tą jest opatrzony bezpośrednio binder znajdujący się na stosie ENVS, ale w składzie taki obiekt się nie pojawia.

Wariant C polega na utworzeniu takiego obiektu, a następnie bindera. Po wywołaniu procedury następuje utworzenie obiektów lokalnych:

<ip1, NazwaParam, deref(v1)>, < ip2, NazwaParam, deref(v2)>,...

gdzie ip1, ip2,... są identyfikatorami nowo utworzonych lokalnych obiektów. Zapis aktywacyjny procedury/metody (na wierzchołku ENVS) będzie

zawierał bindery:..., NazwaParam(ip1), NazwaParam(ip2), ...

• Dzięki temu wewnątrz ciała procedury do parametru można będzie odwołać się poprzez NazwaParam (jak poprzednio);

wynikiem będzie bag{ip1, ip2, ...}. • Wewnątrz ciała można zatem dokonać podstawienia na NazwaParam , gdyż

są to zwyczajne obiekty lokalne.

Page 8: Obiektowe języki zapytań

© K.Subieta. Obiektowe języki zapytań 15, Folia 8 czerwiec 2004

Przykład wołania przez wartość

Parametrem procedury jest kolekcja nazwisk, wynikiem jest kolekcja par, w których pierwszym elementem jest referencja do pracownika posiadającego nazwisko znajdujące się wewnątrz parametru, drugim zaś jest referencja do jego kierownika.procedure PracSzef( in Naz ) { return (Prac where (Nazwisko in Naz))

join (PracujeW.Dział.Szef.Prac)} Wywołanie procedury: PracSzef( bag( „Kowal”, „Nowak” ) ) W wariancie Pascala, po wywołaniu procedury na wierzchołku ENVS umieszczona

będzie sekcja zawierająca bindery:Naz(„Kowal”), Naz(„Nowak”)

Wiązanie nazwy Naz występującej w ciele procedury zwróci bag{„Kowal”, „Nowak” }.

W wariancie C, po wywołaniu procedury utworzone będą lokalne obiekty: < ip1, Naz, „Kowal” >, < ip2, Naz, „Nowak” >

zaś sekcja na wierzchołku ENVS będzie zawierać bindery Naz(ip1), Naz(ip2). Wiązanie nazwy Naz występującej w ciele procedury zwróci bag{ip1, ip2 }. Po zakończeniu procedury obiekty < ip1, Naz,”Kowal”>, < ip2, Naz,”Nowak”>

zostaną automatycznie usunięte.

Page 9: Obiektowe języki zapytań

© K.Subieta. Obiektowe języki zapytań 15, Folia 9 czerwiec 2004

Wołanie przez referencję

Wołanie przez referencję jest podobne do wołania przez wartość w wariancie Pascala. Występują dwie różnice.

1. Składnia: ten rodzaj wołania wymaga specjalnego słowa kluczowego; • Wybierzemy słowo inout.

• Składnia deklaracji procedury z takim parametrem będzie następująca:

procedure NazwaProcedury( ...; inout NazwaParam; ...){...ciało...}

• oraz składnia wywołania, jak poprzednio:

NazwaProcedury( ...; zapytanie; ...)

• zapytanie musi zwrócić pojedynczą referencję i lub bag referencji bag{ i1, i2, ...}.

2. Nie jest wykonywana automatyczna dereferencja. • Jeżeli powyższe zapytanie zwróci referencję i, to do zapisu aktywacyjnego wstawiany

jest binder NazwaParam( i ); jeżeli zwróci bag{i1, i2, ...}, to do zapisu aktywacyjnego wstawiane są bindery NazwaParam(i1 ), NazwaParam(i2 ), ... .

• Czyli wewnątrz procedury podstawienie na NazwaParam spowoduje podstawienie na obiekty, których referencje są zakomunikowane jako parametr.

• W ten sposób można dokonywać operacji aktualizacyjnych z wnętrza procedury na dowolnych obiektach z jej zewnętrza.

Page 10: Obiektowe języki zapytań

© K.Subieta. Obiektowe języki zapytań 15, Folia 10 czerwiec 2004

Przykład wołania przez referencję

Parametrem procedury jest kolekcja referencji do pracowników, wynikiem jest podwyższenie ich uposażenia o zadaną wielkość.

procedure Podwyżka ( inout dlaPrac; in Ile ) {

for each dlaPrac do Zar := Zar + Ile }

Wywołanie procedury:Podwyżka( Prac where Stan = „analityk”; 200 )

Jeżeli zapytanie Prac where Stan = „ analityk”

zwróci bag{i11, i13, i55},

to po wywołaniu procedury na wierzchołku ENVS będzie umieszczona sekcja z binderami:

dlaPrac(i11), dlaPrac(i13), dlaPrac(i55), Ile(202).

Page 11: Obiektowe języki zapytań

© K.Subieta. Obiektowe języki zapytań 15, Folia 11 czerwiec 2004

Ścisłe wołanie przez wartość (strict-call-by-value)

Zróżnicowanie na wołanie przez wartość i wołanie przez referencję nie zawsze jest korzystne. • Wymaga odrębnej składni oraz powoduje ograniczenia jeżeli chodzi o rodzaj

komunikowanej wartości. W języku C takie zróżnicowanie nie występuje: parametr pointerowy jest

przekazywany do ciała procedury bez zmian. W systemie Loqis zdecydowaliśmy się wprowadzić tę metodę w wariancie

Pascala, tj. bez tworzenia lokalnego obiektu.• Składnia deklaracji procedury z takim parametrem będzie następująca:

procedure NazwaProcedury( ...; NazwaParam; ...){...ciało...}• Składnia wywołania, jak poprzednio:

NazwaProcedury( ...; zapytanie; ...) Powyższe zapytanie może zwrócić dowolny rezultat r Rezultat zbudowany z

referencji, wartości, nazw i konstruktorów struktur i kolekcji. • Rezultat ten jest bez zmian przekazywany do ciała procedury w ten sposób, że do jej

zapisu aktywacyjnego wstawia się pojedynczy binder NazwaParam( r ). W ten sposób metoda ta łączy wołanie przez wartość z wołaniem przez referencję

oraz posiada dalsze możliwości, niedostępne w tych metodach.

Page 12: Obiektowe języki zapytań

© K.Subieta. Obiektowe języki zapytań 15, Folia 12 czerwiec 2004

Przykład ścisłego wołania przez wartość

Parametrem komuIle procedury ZmieńZarobek jest bag struktur struct{ komu(r), ile(w) }, gdzie r jest referencją do obiektu pracownika, w jest jego nowym zarobkiem.

Procedura przyznaje ten nowy zarobek tym pracownikom, dla których jest on większy od ich aktualnego zarobku. W razie konfliktu (jeżeli referencja danego pracownika wystąpi wielokrotnie), wybiera maksymalną z możliwych nowych wartości zarobku.

procedure ZmieńZarobek ( komuIle ) {for each distinct( komuIle.komu ) as p do p.Zar := max( bag( p.Zar, (komuIle where komu = p). ile))}

Pracownikom z Radomia udziel podwyżki w wysokości 100, pracownikom po 40-tce udziel podwyżki w wysokości 200, zaś wszystkim sekretarkom ustal zarobek na 1000 (z uwzględnieniem ew. innych kryteriów dających więcej).

ZmieńZarobek ( bag( ((Prac where ”Radom” PracujeW.Dział.Lokacja) as komu join (komu.zar + 100) as ile), ((Prac where Wiek > 40) as komu join (komu.zar + 200) as ile), ((Prac where Stan = ”sekretarka”) as komu, 1000 as ile)))

Page 13: Obiektowe języki zapytań

© K.Subieta. Obiektowe języki zapytań 15, Folia 13 czerwiec 2004

Wołanie z etykietowanymi parametrami aktualnymi (1)

Dotychczasowe metody wołania parametrów są niewygodne w sytuacji, gdy parametrów jest więcej niż 5.

W takich sytuacjach dokładne dopasowanie kolejności parametrów formalnych i aktualnych oraz ich ilości jest zwykle problemem.

Przykładowo, jeżeli deklaracja procedury ma postać:procedure Wyświetl( tekst; okno; x; y; tło; kolorLiter; font;

wys; maxroz; miganie)

to wywołanie tej procedury w postaci:Wyświetl( kom; A[i]; z+35; a+78; t; 34; f; 12; z/4; 0)

jest bardzo trudne do odczytania i zrozumienia w tekście programu, szczególnie jeżeli deklaracja tej procedury znajduje się w odległym miejscu kodu. • Czytelność mogłyby poprawić komentarze, ale są one w takich sytuacjach

rzadko stosowane przez programistów.

Page 14: Obiektowe języki zapytań

© K.Subieta. Obiektowe języki zapytań 15, Folia 14 czerwiec 2004

Wołanie z etykietowanymi parametrami aktualnymi (2)

Rozwiązaniem tego problemu jest odmiana techniki wołania parametrów, w której w wywołaniu parametr aktualny jest zawsze skojarzony z nazwą parametru formalnego. • To pozwala na podawanie parametrów w dowolnej kolejności. • Dodatkowo, technika ta pozwala programiście na pomijanie pewnych

parametrów poprzez skorzystanie z wartości domyślnych.• Metodę tę można zastosować w dowolnym wariancie, wołanie przez wartość,

przez referencję, itd. Niżej podamy odmianę tej metody dla ścisłego wołania przez wartość. Deklaracja procedury będzie mieć postać jak poprzednio, natomiast

wywołanie procedury będzie zawsze miało postać:NazwaProcedury( ...; NazwaParam: zapytanie; ...)

W wyniku, jak poprzednio, do zapisu aktywacyjnego procedury będzie wstawiony binder NazwaParam( r ), gdzie r jest rezultatem zwróconym przez zapytanie. • W ten sposób kolejność parametrów nie będzie miała znaczenia.

Page 15: Obiektowe języki zapytań

© K.Subieta. Obiektowe języki zapytań 15, Folia 15 czerwiec 2004

Pomijanie parametrów aktualnych

Aby można było pomijać niektóre parametry, konieczne są wartości domyślne (default). • Wartości domyślne mogą być umieszczone wewnątrz klasy. Dotyczy to

procedur będących metodami.• Wartości domyślne mogą być umieszczone w specjalnej klauzuli procedury

nazwanej defaults. Bindery wynikające z tej klauzuli, naśladującej dokładnie wołanie parametrów, są lokowane na ENVS poniżej zapisu aktywacyjnego.

procedure Wyświetl( tekst; okno; x; y; tło; kolorLiter; font; wys; maxroz; miganie) { defaults (x:0; y:0; tło:t; font:f; wys:12; maxroz:45;

migotanie:0); ... }

• Procedura może być wywołana w postaci: Wyświetl(okno:A[i]; tekst:”Podaj swoje nazwisko”; migotanie:1)

• Pozostałe parametry zostaną pobrane z listy parametrów domyślnych lub z wartości domyślnych umieszczonych w ramach klasy, do której należy procedura Wyświetl.

Page 16: Obiektowe języki zapytań

© K.Subieta. Obiektowe języki zapytań 15, Folia 16 czerwiec 2004

Procedury rekurencyjne

Podejście stosowe zakłada rekurencję jako własność oczywistą. Umożliwienie określania parametrów procedur w postaci zapytań oraz

zwracania wyniku procedur w postaci dowolnej wartości dziedziny Rezultat stwarza nową jakość, która dotychczas była kwalifikowana jako własność „inteligentna”, specyficzna dla dedukcyjnych baz danych.

Przy pomocy rekurencyjnych procedur można bez trudu osiągnąć efekty tranzytywnych domknięć oraz równań stało-punktowych (będą w nastepnym semestrze).

Mimo różnic składniowych i semantycznych, są to mechanizmy porównywalne pragmatycznie.

Z doświadczeń autora wynika, że procedury rekurencyjne są bardziej zrozumiałe dla powszechnego programisty, być może wskutek praktyki edukacyjnej.

Page 17: Obiektowe języki zapytań

© K.Subieta. Obiektowe języki zapytań 15, Folia 17 czerwiec 2004

Schemat struktury hierarchicznej części wyrobu

Część[0..*] nazwa rodzaj kosztDet[0..1] masaDet[0..1] kosztMont[0..1] masaMont[0..1] składnik[0..*] ilość prowadziDo

”detal”, ”agregat”

Page 18: Obiektowe języki zapytań

© K.Subieta. Obiektowe języki zapytań 15, Folia 18 czerwiec 2004

Przykład funkcji rekurencyjnej

Procedura Podczęści ma parametr mojeCzęści bedącego bagiem referencji do części. • Procedura zwraca bag z referencjami do wszystkich pod-części części

wymienionych w parametrze.

• Duplikaty w wyniku nie są usuwane.

• Przy transmisji parametrów przyjmujemy metodę ścisłego wołania przez wartość.

procedure Podczęści (mojeCzęści ) {

return if not exists( mojeCzęści ) then bag{}

else bag( mojeCzęści,

Podczęści(mojeCzęści.składnik.prowadziDo.Część))}

Podaj nazwy wszystkich części detalicznych składających się na samolot Boeing 767:

distinct( Podczęści( Część where nazwa = ”Boeing 767” )

where rodzaj = ”detal”).nazwa

Page 19: Obiektowe języki zapytań

© K.Subieta. Obiektowe języki zapytań 15, Folia 19 czerwiec 2004

Inny przykład na rekurencję

Obiekty Osoba mają atrybuty nazwisko, rokUr (rok urodzenia), żyje (z wartością boolowską), oraz są powiązane związkami rodzinnymi matka, ojciec, syn, córka, zaimplementowanymi jako obiekty pointerowe umieszczone wewnątrz obiektów Osoba.

Procedura Przodek zwraca wszystkich przodków osób zakomunikowanych jako parametr. Procedura Następca zwraca wszystkich następców osób zakomunikowanych jako parametr. procedure Przodek( mojeOsoby) { return if not exists(mojeOsoby) then bag{}

else distinct( bag(mojeOsoby, Przodek(mojeOsoby.(matka ojciec).Osoba)))}

procedure Następca( mojeOsoby) {return if not exists(mojeOsoby) then bag{} else distinct( bag(mojeOsoby, Następca (mojeOsoby.(syn córka).Osoba)))}

Podaj nazwisko i rok urodzenia wszystkich żyjących kuzynów Kowalskiego, którzy są od niego młodsi: (((Osoba where nazwisko = ”Kowalski”) as kow)

join (Następca(Przodek( kow )) as kuzyn)where (kow.rokUr < kuzyn.rokUr and kuzyn.żyje)).(kuzyn.(nazwisko, rokUr))

Page 20: Obiektowe języki zapytań

© K.Subieta. Obiektowe języki zapytań 15, Folia 20 czerwiec 2004

Modyfikacja zapytań

Modyfikacja zapytań jest podstawową metodą optymalizacji zapytań używających perspektyw. • Jest stosowana we wszystkich systemach relacyjnych. • Ponieważ pojęcie perspektywy, tak jak jest ono wprowadzone w systemach

relacyjnych, jest równoważne procedurze funkcyjnej, w istocie metoda modyfikacji zapytań dotyczy tych ostatnich.

• Pokażemy jednak dalej, że ma ona zastosowanie również dla aktualizowalnych perspektyw (w następnym semestrze).

Metoda została sformułowana przez M.Stonebrakera w 1975 roku, ale wskutek braku ortogonalności ówczesnych języków zapytań (w szczególności QUEL i SQL) sformułowanie jest bardzo złożone i niejasne. • Wydawało się wówczas, że jest ona całkowicie oryginalnym wynalazkiem.

Okazało się, że przy założeniu pełnej ortogonalności języka (cecha SBQL) i przy przyjęciu tezy, że perspektywa jest procedurą funkcyjną, metoda ta jest wariantem metody, która była znana już w latach 60-tych i powszechnie stosowana w optymalizacji programów.

Page 21: Obiektowe języki zapytań

© K.Subieta. Obiektowe języki zapytań 15, Folia 21 czerwiec 2004

Modyfikacja zapytań = makro-substytucja

Metoda modyfikacji zapytań polega na tym, że definicję funkcji traktuje się jako makro-definicję.• Wszędzie tam, gdzie w zapytaniach występuje nazwa funkcji, zastępuje się tę

nazwę poprzez tekst będący definicją tej nazwy (pomijając nieistotne elementy leksykalne). Po tym zabiegu uzyskuje się zapytanie bez odwołań do funkcji.

• Poddaje się go następnie innym metodom optymalizacyjnych. Aby metoda ta prowadziła do semantycznie poprawnych konstrukcji i nie

zmieniała znaczenia zapytania, jej zastosowanie wymaga wprowadzenia ograniczeń na postać deklaracji funkcji:• Funkcja nie może mieć lokalnego środowiska, w szczególności, nie może

mieć parametrów. • Funkcja nie może być także rekurencyjna, pośrednio lub bezpośrednio, gdyż

prowadziłoby to do nieskończonej pętli stosowania makro-definicji. • Środowisko w którym wywoływana jest funkcja jest takie samo jak

środowisko, w którym ewaluowane jest zapytanie wewnątrz tej funkcji.• Funkcja powinna mieć postać procedure NazwaFunkcji { return zapytanie}

równoważną pojedynczemu zapytaniu.

Page 22: Obiektowe języki zapytań

© K.Subieta. Obiektowe języki zapytań 15, Folia 22 czerwiec 2004

Dlaczego w SQL jest to skomplikowane?

Brak ortogonalności, chaotyczność konstrukcji SQL powoduje powstanie w tej materii skomplikowanych algorytmów.

Jedną z przyczyn skomplikowania metody modyfikacji zapytań w systemach relacyjnych jest brak formalnej semantyki pomocniczych nazw. • Jest ona niewyrażalna w algebrze relacji, rachunku relacyjnym i stosowanych

w tym celu logikach, zatem oparcie semantyki języka zapytań na tych formalizmach powoduje poważne ograniczenia.

• Definicje perspektyw w SQL określają w nagłówku nazwy wirtualnych atrybutów, zatem wstawienie ciała definicji jako fragmentu zapytania wymaga odpowiednich operacji na tych nazwach.

PracNrPNazwiskoStanZarPracujeW

DziałNrDNazwaSzef

LokacjeNrDLokacja

AdresNrPMiastoUlicaNrDomu

Schemat relacyjny

Page 23: Obiektowe języki zapytań

© K.Subieta. Obiektowe języki zapytań 15, Folia 23 czerwiec 2004

Przykład w SQL

Definicja perspektywy w SQL ma postać:create view PracSzef( Naz, NazD, NazSzefa) asselect p.Nazwisko, d.Nazwa, s.Nazwiskofrom Prac p, Dział d, Prac s where p.PracujeW = d.NrD and d.Szef = s.NrP

• Nowe nazwy Naz, NazD, NazSzefa są nazwami kolumn wirtualnej tabeli, które można używać w zapytaniach, np.:

• Podaj nazwiska i nazwy działów pracowników nazywających się tak samo jak ich szef):

select p.Naz, p.NazD from PracSzef r where r.Naz = r.NazSzefa Jeżeli w powyższym zapytaniu podstawilibyśmy na PracSzef tekst z

definicji perspektywy znajdujący się po as, to otrzymalibyśmy niepoprawne zapytanie.• W systemach relacyjnych podmiana ta następuje na poziomie drzew

syntaktycznych zapytania i definicji perspektywy. • Należy jeszcze dokonać odpowiedniej transformacji nazw Naz, NazD,

NazSzefa występujących w tak przekształconym zapytaniu na nazwy atrybutów z zapamiętanych tabel, a to prowadzi do złożonych i niejasnych semantycznie algorytmów.

Page 24: Obiektowe języki zapytań

© K.Subieta. Obiektowe języki zapytań 15, Folia 24 czerwiec 2004

Dlaczego w SBQL jest to banalnie proste?

Pełna ortogonalność. Pomocnicze nazwy są objęte semantyką języka.

• Ten sam przykład w SBQL:

• Jak widać, nazwy „wirtualnych kolumn” tej perspektywy są standardowymi nazwami powoływanymi przez operator as.

• Dzięki temu nie ma problemów koncepcyjnych z modyfikacją zapytań.

• Sprowadza się ona do prostej operacji zastąpienia nazwy PracSzef występującej w zapytaniu przez tekst zapytania znajdującego się po słowie return.

procedure PracSzef { return (Prac as p, Dział as d, Prac as s)

where (p.PracujeW = d.NrD and d.Szef = s.NrP). (p.Nazwisko as Naz, d.Nazwa as NazD, s.Nazwisko as NazSzefa )}

Page 25: Obiektowe języki zapytań

© K.Subieta. Obiektowe języki zapytań 15, Folia 25 czerwiec 2004

Co się dzieje z zapytaniem w SBQL?

Zapytanie równoważne podanemu poprzednio zapytaniu SQL ma w SBQL następującą postać:

Jeżeli zamiast PracSzef podstawimy tekst zapytania z ciała definicji funkcji PracSzef, to otrzymamy następujące poprawne zapytanie w SBQL:

Zapytanie to nie ma już odwołań do funkcji PracSzef. Wynik tego zapytania będzie identyczny z wynikiem oryginalnego zapytania. Zapytanie to może być następnie optymalizowane przy pomocy metod, które będą objaśnione w przyszłym semestrze (i w książce).

(PracSzef as r where r.Naz = r.NazSzefa). (r.Naz, r.NazD)

(((Prac as p, Dział as d, Prac as s) where (p.PracujeW = d.NrD and d.Szef = s.NrP).(p.Nazwisko as Naz, d.Nazwa as NazD, s.Nazwisko as NazSzefa )) as r where r.Naz = r.NazSzefa). (r.Naz, r.NazD)

Page 26: Obiektowe języki zapytań

© K.Subieta. Obiektowe języki zapytań 15, Folia 26 czerwiec 2004

Modyfikacja zapytań dla struktur obiektowych (1)

W SBQL mogą być modyfikowane zapytania odwołujące się do dowolnych obiektowych struktur danych.

Funkcja MałoZarabiający zwraca bag { struct{ N(iNazwisko), Z(iZar), D(iNazwa)}}

Dział [0..*]NrDNazwaLokacja[1..*]

Schemat obiektowy (diagram klas)

PracujeW Zatrudnia[1..*]Prac [0..*]NrPNazwiskoStanZar

Adres [0..1]MiastoUlicaNrDomu

Kieruje[0..1] Szef

procedure MałoZarabiający { return (Prac where Zar < 0.5 * avg( Prac.Zar ) ) . ( Nazwisko as N, Zar as Z, (PracujeW.Dział.Nazwa) as D) };

Page 27: Obiektowe języki zapytań

© K.Subieta. Obiektowe języki zapytań 15, Folia 27 czerwiec 2004

Modyfikacja zapytań dla struktur obiektowych (2)

Funkcja ta może być użyta w następującym zapytaniu:(MałoZarabiający where N = „Bilski”).Z

• Załóżmy, że w bazie danych dostęp poprzez atrybut Nazwisko jest wspomagany indeksem IndeksPracNazwisko( nazw ), który zwraca referencję do obiektów Prac dla stringowego parametru nazw będącego nazwiskiem.

Zauważmy następujące okoliczności:• Zmaterializowanie wyniku procedury będzie czasochłonne.

• Indeks IndeksPracNazwisko, zapewniający szybki dostęp do obiektów wg nazwisk, w powyższym zapytaniu nie może być wykorzystany.

• Zwracanie przez funkcję nazwy działu jest niepotrzebne, bo tej danej zapytanie nie wykorzystuje.

Modyfikacja zapytań usuwa te problemy. • Dzięki niej nie trzeba będzie liczyć wszystkich elementów tej perspektywy, w

szczególności jej niepotrzebnych członów.

• Można będzie również wykorzystać indeks.

• Prześledźmy to na kolejnych krokach.

Page 28: Obiektowe języki zapytań

© K.Subieta. Obiektowe języki zapytań 15, Folia 28 czerwiec 2004

Po makro-substytucji:(( (Prac where Zar < 0.5 * avg( Prac.Zar )).

(Nazwisko as N, Zar as Z, (PracujeW.Dział.Nazwa) as D) )

where N = „Bilski”) . Z

Pod-zapytanie (PracujeW.Dział.Nazwa) as D nie jest używane (jest „martwe”); może być więc usunięte.

(( (Prac where Zar < 0.5 * avg( Prac.Zar ) ).

(Nazwisko as N, Zar as Z) )

where N = „Bilski”).Z

Rezultat pod-zapytania 0.5 * avg( Prac.Zar ) jest identyczny dla wszystkich pracowników; pod-zapytanie to może być zatem wyciągnięte przed pętlę implikowaną przez pierwszy operator where:

(((0.5 * avg(Prac.Zar )) group as x) . (Prac where Zar < x ).

(Nazwisko as N, Zar as Z)

where N = „Bilski”) . Z

Kroki modyfikacji i optymalizacji (1)

Page 29: Obiektowe języki zapytań

© K.Subieta. Obiektowe języki zapytań 15, Folia 29 czerwiec 2004

Kroki modyfikacji i optymalizacji (2)

Definicje pomocniczych nazw N i Z stają się zbędne; można je usunąć, zastępując oryginalnymi nazwami Nazwisko i Zar:

(((0.5 * avg(Prac.Zar )) group as x).

(Prac where Zar < x ) where Nazwisko = „Bilski”) . Zar

Warunki w dwóch następujące po sobie operatorach where łączymy w jeden warunek połączony operatorem and:

((0.5 * avg(Prac.Zar )) group as x).(Prac where Zar < x

and Nazwisko = „Bilski”) . Zar W tej chwili można wykorzystać indeks IndeksPracNazwisko, którego

wywołanie zastępuje zapytanie Prac where Nazwisko = ”Bilski” :

((0.5 * avg(Prac.Zar )) group as x).

(IndeksPracNazwisko( „Bilski” ) where Zar < x ). Zar

Zapytanie jest ostatecznie zoptymalizowane. Optymalizacja odbywała się na podstawie reguł, które można sformalizować i zaimplementować.

Page 30: Obiektowe języki zapytań

© K.Subieta. Obiektowe języki zapytań 15, Folia 30 czerwiec 2004

Na zakończenie ...

Podstawowe tematy związane z obiektowymi językami zapytań zostały omówione, ale pozostały jeszcze inne. Wiele z nich stanowi pole działalności badawczej, m.in. następujące tematy:• Języki schematu dla obiektowych baz danych (a la ODMG ODL),

metamodele dla obiektowych baz danych.

• Mocna kontrola typów dla języków zapytań i języków programowania opartych na językach zapytań.

• Tranzytywne domknięcia i równania stało-punktowe w językach zapytań.

• Aktualizacja wirtualnych perspektyw z uwzględnieniem możliwości sterowania przez definiującego intencją tej aktualizacji.

• Programowanie generyczne z refleksją.

• Przetwarzanie zapytań w rozproszonych obiektowych bazach danych.

• Metody optymalizacji obiektowych zapytań.

Wiele z tych tematów będzie w przyszłym semestrze.