© K.Subieta. Obiektowe języki zapytań 07, Folia 1 kwiecień 2004 Obiektowe języki zapytań Wykładowca: Kazimierz Subieta Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa Instytut Podstaw Informatyki PAN, Warszawa Wykład 07: Stos środowisk, rezultaty zapytań, funkcja nested

© K.Subieta. Obiektowe języki zapytań 07, Folia 2 kwiecień 2004 Stos środowisk Pojęcie stosu środowisk pojawiło się w informatyce w latach 60-tych. Od tego czasu stos ten jest elementem konstrukcji większości znanych języków, włączając Pascal, C/C++, Smalltalk, Java, itd. Idea tego stosu jest znana wszystkim konstruktorom języków oraz większości programistów programujących w w/w językach. Idea jest prosta i oczywista, ale nie jest często dostatecznie dobrze objaśniona w podręcznikach. Specjaliści z zakresu baz danych rzadko rozumieją, po co jest ten stos i jakie ma własności. Znane języki zapytań są oparte o koncepcje ograniczone i nieadekwatne, takie jako algebra relacji, algebry obiektowe, itd. Przy konstrukcji semantyki języków zapytań musimy wrócić do stosu środowisk. Prześledzić jego rolę jako mechanizmu języków programowania oraz zmodyfikować jego budowę i funkcje go w taki sposób, aby odpowiadał on potrzebom związanym z definicją semantyki języków zapytań. environment stack

© K.Subieta. Obiektowe języki zapytań 07, Folia 3 kwiecień 2004 Środowiska w językach programowania Pojęcie środowiska (environment) działania programu oznacza zestaw wszystkich bytów programistycznych czasu wykonania (zmiennych, stałych, obiektów, funkcji, procedur, typów, klas, itd.), które są dostępne dla programisty w danym punkcie sterowania programu. Środowisko wykonania nie jest płaską strukturą oraz zmienia się w trakcie działania programu. Wygodnym sposobem zarządzania zmianami środowiska jest przyjęcie założenia, że środowisko jest podzielone na pod-środowiska, które pojawiają się i znikają w miarę przesuwania się sterowania programu. S1 S2 S3 sterowanie

© K.Subieta. Obiektowe języki zapytań 07, Folia 4 kwiecień 2004 Zasady zarządzania środowiskami programu Zasady te mają wpływ na technikę i niezawodność programowania. Są one następujące: Środowisko lokalne danego bytu programistycznego ma priorytet w stosunku do środowiska bardziej globalnego. Np. programista koncentrujący się nad napisaniem pewnej procedury powinien mieć możliwość abstrahowania od wpływu globalnego środowiska na tę procedurę. Zasada lokalnego kontekstu: programista piszący pewną procedurę nie może uwzględnić w niej tych (nieznanych) elementów środowiska wykonania, które pojawią się w momencie wywołania tej procedury. Zasada dowolnego zagnieżdżania wołań procedur: programista piszący procedurę może bez ograniczeń koncepcyjnych wołać w niej inne procedury. W szczególności, dopuszczalne są dowolne rekurencyjne wołania, pośrednie lub bezpośrednie.

© K.Subieta. Obiektowe języki zapytań 07, Folia 5 kwiecień 2004 Realizacja zarządzania środowiskami Przyjęcie tych zasad prowadzi do pojęcia stosu środowisk (określanego także jako stos wołań, call stack), czyli struktury danych odpowiedzialnej za kontrolowania zmianami środowiska wykonania programów. W językach programowania cel, działanie i organizacja mechanizmu stosu środowisk jest dobrze rozpoznane. Stos ten jest odpowiedzialny za: kontrolowanie zakresów nazw zmiennych i wiązanie tych nazw; przechowywanie wartości lokalnych zmiennych funkcji, procedur lub metod; przechowywanie wartości parametrów aktualnych funkcji i procedur; przechowywanie tzw: śladu powrotu, tj. adresu instrukcji, do której ma przejść sterowanie po zakończeniu działania funkcji, procedury lub metody. Stos środowisk jest strukturą danych przechowywaną w pamięci operacyjnej (lub wirtualnej). Jest on podzielony na części, które będziemy określać jako sekcje, przy czym kolejność sekcji jest istotna.

© K.Subieta. Obiektowe języki zapytań 07, Folia 6 kwiecień 2004 Działanie stosu środowisk Stos jest zarządzany zgodnie z wołaniami procedur, funkcji, metod, itd. oraz wejściem sterowania w tzw. bloki programu. Nowa sekcja (tzw. zapis aktywacji, activation record) pojawia się na wierzchołku stosu w momencie wejścia sterowania programu w procedurę (funkcję, metodę) oraz w momencie wejścia sterowania w blok. Sekcja ta zawiera wartości lokalnych zmiennych, wartości parametrów oraz (dla procedur, funkcji i metod) ślad powrotu. Zatem nowa sekcja na stosie odpowiada każdemu wołaniu procedury, funkcji lub metody, lub wejściu sterowania w nowy blok. Sekcja ta jest usuwana z wierzchołka stosu w momencie zakończenia procedury (funkcji, metody) oraz w momencie wyjścia z bloku. Wszystkie lokalne zmienne zadeklarowane w aktualnie wykonywanej procedurze (funkcji, metodzie) oraz jej parametry są przechowywane na wierzchołku tego stosu.

© K.Subieta. Obiektowe języki zapytań 07, Folia 7 kwiecień 2004 Ilustracja działania stosu środowisk Procedura p1 wywołuje procedurę p2, która wywołuje procedurę p3 czas... Sekcja danych globalnych Sekcja lokalnych danych i parametrów procedury p1... Sekcja danych globalnych Wywołanie p1 Sekcja lokalnych danych i parametrów procedury p2 Sekcja lokalnych danych i parametrów procedury p1... Sekcja danych globalnych Wywołanie p2 Sekcja lokalnych danych i parametrów procedury p3 Sekcja lokalnych danych i parametrów procedury p2 Sekcja lokalnych danych i parametrów procedury p1... Sekcja danych globalnych Wywołanie p3 Sekcja lokalnych danych i parametrów procedury p1... Sekcja danych globalnych Wyjście z p2 Wyjście z p1... Sekcja danych globalnych Sekcja lokalnych danych i parametrów procedury p2 Sekcja lokalnych danych i parametrów procedury p1... Sekcja danych globalnych Wyjście z p3

© K.Subieta. Obiektowe języki zapytań 07, Folia 8 kwiecień 2004 Wiązanie (1) Wiązanie jest to zastępowanie nazw występujących w tekście programu na byty programistyczne czasu wykonania, np. na adresy RAM, identyfikatory obiektów, adresy startowe procedur, itd. Przykładowo, wiązanie nazwy zmiennej x oznacza zastąpienie tej nazwy przez adres RAM, gdzie przechowywana jest wartość zmiennej x. Wiązanie może być wczesne lub statyczne (early binding, static binding), czyli odbywa się w czasie kompilacji, albo późne lub dynamiczne (late binding, dynamic binding), czyli odbywa się w czasie wykonania. binding

© K.Subieta. Obiektowe języki zapytań 07, Folia 9 kwiecień 2004 Wiązanie (2) Wiązanie nazw na stosie środowiskowym odbywa się więc wg prostej zasady: poszukuje się wartości opatrzonej tą nazwą w sekcji na wierzchołku stosu; jeżeli na wierzchołku takiej nazwy nie ma, poszukuje się takiej wartości w sekcji poniżej; proces ten jest kontynuowany aż do znalezienia wartości opatrzonej tą nazwą, ale z uwzględnieniem reguł zakresu (scoping rules), które nakazują omijanie pewnych sekcji stosu; jeżeli nazwa nie jest odnaleziona na stosie, wówczas poszukiwana jest ona wśród zmiennych globalnych (ew. tzw. zmiennych statycznych), bibliotek funkcji i zmiennych/stałych środowiskowych. Można uważać, że tego rodzaju globalne własności znajdują się na dole stosu środowisk. Abstrahujemy od wiązania statycznego, zakładając, że wszelkie wiązania zachodzą podczas czasu wykonania. wiązanie statyczne traktujemy jako rodzaj optymalizacji. binding

© K.Subieta. Obiektowe języki zapytań 07, Folia 10 kwiecień 2004 Przykładowa sytuacja na stosie środowisk Zmienne e, f zadeklarowane wewnątrz bloku l Zmienne c, d i parametry z(55), t(83) procedury p2 Zmienne a, b i parametry x, y procedury p Zmienne i inne byty globalne Wierzchołek stosu Dół stosu Kolejność poszukiwania wiązania dla zmiennej g procedure p1( x, y ) { deklaracje zmiennych a, b;... call p2( 55, 83 );... } procedure p2( z, t ) { deklaracje zmiennych c,d;... { (* blok l *) deklaracje zmiennych e, f; g := 75;... };... } Wykonywany jest blok l w procedurze p2 wywołanej z p1.

© K.Subieta. Obiektowe języki zapytań 07, Folia 11 kwiecień 2004 Dlaczego przy wiązaniu omijamy niektóre sekcje? Reguła zakresu: z wnętrza procedury p2 (i bloku b) nie mogą być widoczne zmienne i parametry procedury p1. Procedury p1 i p2 mogą być pisane przez różnych programistów, w różnym czasie, zatrudnionych przez różne firmy. Programista piszący p2 nie ma pojęcia, jakie nazwy lokalnych zmiennych będą użyte podczas pisania p1. Nie może mieć jakiejkolwiek możliwości odwołania się do zmiennych procedury p1. Każde takie odwołanie wynikałoby z przypadkowej zgodności nazw, np. wskutek błędu. Zatem najlepiej "na chwilę" ukryć środowisko wewnętrzne p1. Jest to zasada określana niekiedy jako statyczna lub leksykalna kontrola zakresu (static scoping, lexical scoping). Zasada ta mówi, że programista nie może mieć możliwości odwołania się do tych bytów programistycznych, które są dla niego niewidoczne lub nieznane podczas pisania programu.

© K.Subieta. Obiektowe języki zapytań 07, Folia 12 kwiecień 2004 Zmienne zadeklarowane wewnątrz bloku b Zmienne i parametry procedury p2 Prywatne i publiczne własności modułu m2 Własności importowane przez moduł m2 Zmienne i parametry procedury p1 Prywatne i publiczne własności modułu m1 Własności importowane przez moduł m Referencje do wszystkich modułów Referencje do własności środowiska globalnego Wierzchołek stosu Dół stosu Kolejność poszukiwania zmiennej x Statyczna kontrola zakresu dla modułów p1 woła p2. Procedura p1 znajduje się wewnątrz modułu m1, zaś procedura p2 znajduje się wewnątrz modułu m2. Wykonywany jest blok b wewnątrz p2. Podobnie dla języków obiektowych (do tego tematu dojdziemy).

© K.Subieta. Obiektowe języki zapytań 07, Folia 13 kwiecień 2004 Po co jest mechanizm stosu środowiskowego? (1) Abstrakcja i hermetyzacja: wnętrze napisanej procedury (funkcji, metody) zostaje ukryte przed programistami, którzy jej użyją. Procedura jest widoczna wyłącznie poprzez jej interfejs (tzw. sygnaturę). Izolacja: programiści piszący różne procedury nie muszą o sobie wiedzieć ani nie muszą między sobą uzgadniać nazw lokalnych zmiennych. Semantyczna niezależność i ponowne użycie: procedura może być wywołana z wielu miejsc. Może być także używana w wielu aplikacjach. Wywoływanie procedur z innych procedur, włączając wołania rekurencyjne. Dzięki temu, że sekcja stosu jest przypisana do wołania procedury, nie zachodzi konflikt przy wywołaniach procedur z procedur; w szczególności, procedura może bez ograniczeń wywołać samą siebie. Przy założeniu, że pamięć przeznaczona na stos jest nieograniczona, co nie ma miejsca w typowych językach programowania. Niekiedy stos jest zorganizowany z użyciem pamięci wirtualnej, co minimalizuje problem przepełnienia stosu.

© K.Subieta. Obiektowe języki zapytań 07, Folia 14 kwiecień 2004 Po co jest mechanizm stosu środowiskowego? (2) Spójne zarządzanie nazwami użytymi w programie. Przestrzeń użytych nazw jest ściśle kontrolowana, zaś nazwy są wiązane do bytów programistycznych czasu wykonania według ścisłych reguł. Realizacja metod transmisji parametrów: wartości parametrów oraz inne ich własności są odkładane w lokalnych sekcjach stosu, dzięki czemu możliwy jest spójny dostęp i zarządzanie parametrami oraz realizacja metod transmisji parametrów, takich jak wołanie przez wartość (call-by- value) lub wołanie przez referencję (call-by-reference). Podane motywacje mają znaczenie dla języków zapytań, pozwalając zrealizować takie ich założenia jak: możliwość dowolnego zagnieżdżania zapytań, możliwość powoływania lokalnych nazw wewnątrz zapytań, możliwość używania nazw z bazy danych łącznie z nazwami zmiennych programistycznych, nazwami procedur, funkcji i metod. Nie uwzględnienie mechanizmu stosu środowiskowego w typowych podejściach do języków zapytań, takich jak algebra relacji, rachunek relacyjny, logika matematyczna, itd. z góry skazuje je na ograniczenia.

© K.Subieta. Obiektowe języki zapytań 07, Folia 15 kwiecień 2004 Stos statyczny i dynamiczny W typowych językach nazwy występujące w programie są drugiej kategorii programistycznej: nie są dostępne podczas wykonania programu. Dla takich języków stos środowiskowy musi istnieć w dwóch postaciach: stos zarządzany podczas kompilacji (stos statyczny), oraz stos czasu wykonania (stos dynamiczny). Wiązanie nazw odbywa się początkowo na stosie statycznym i ostatecznie na dynamicznym. Podczas kompilacji stos statyczny symuluje działanie stosu dynamicznego - jest podwyższany lub skracany w miarę postępu analizy syntaktycznej. Stos statyczny przechowuje nazwy bytów programistycznych, ich sygnatury, oraz informacje o ich reprezentacji. Wiązanie nazw nie jest bezwzględne, lecz relatywne, z dokładnością do odległości (mierzonej w bajtach) położenia reprezentacji danej wartości od wierzchołka stosu dynamicznego. Dopiero podczas wykonania następuje ostateczne obliczenie adresu ulokowania danego bytu programistycznego np. poprzez odjęcie adresu relatywnego od aktualnego rozmiaru stosu.

© K.Subieta. Obiektowe języki zapytań 07, Folia 16 kwiecień 2004 Stos środowisk w SBA (1) Stos środowisk dostosujemy do wymagań semantyki języków zapytań oraz konstrukcji pochodnych, takich jak perspektywy, procedury bazy danych, itd. Stos będzie spełniać następujące założenia: Będzie zgodny z modelami składu M0 - M3. Będzie w jednorodny sposób traktował dane indywidualne i kolekcje. Maksymalny rozmiar stosu nie będzie implementacyjnie ograniczony. Stos będzie składał się z sekcji, gdzie każda sekcja będzie przechowywać informację o pewnym środowisku czasu wykonania, np. środowisku wywołania pewnej funkcji, procedury lub metody, środowisku wnętrza pewnego obiektu, środowisku wnętrza pewnej klasy, środowisku obiektów bazy danych, itd. Rozmiar sekcji nie będzie ograniczony. Na dole stosu umieszczone będą sekcje globalne, do których należą globalne zmienne aplikacji, baza danych, wspólne biblioteki procedur i funkcji, oraz zmienne środowiskowe systemu komputerowego.

© K.Subieta. Obiektowe języki zapytań 07, Folia 17 kwiecień 2004 Stos środowisk w SBA (2) Stos będzie więc przechowywał pełną informację niezbędną do wiązania dowolnej nazwy, która może wystąpić w zapytaniu, perspektywie, procedurze, trygerze lub programie aplikacyjnym. Stos będzie w jednakowy sposób traktował zarówno dane trwałe (persistent) przechowywane w bazie danych, dane chwilowe będące danymi lokalnymi wywoływanych procedur, funkcji i metod, dane chwilowe będące danymi globalnymi aplikacji, oraz aktualne parametry procedur lub metod. Stos będzie także miejscem przechowywania informacji o definicjach wprowadzanych w zapytaniach lub w programach. M.in. będzie on przechowywał informację o tzw. synonimach lub zmiennych korelacyjnych (w SQL lub OQL), zmiennych związanych kwantyfikatorami, zmiennych używanych w iteratorach for each, itd. W odróżnieniu od języków programowania, gdzie stos jest jednocześnie składem wartości zmiennych, nasz stos jest strukturą różną od składu obiektów. Powodem jest to, że w budowanej przez nas semantyce odwołania do tego samego obiektu mogą pojawić się w różnych sekcjach stosu.

© K.Subieta. Obiektowe języki zapytań 07, Folia 18 kwiecień 2004 Binder Podstawową strukturą przechowywaną na stosie środowisk jest binder. Binder jest parą, gdzie n jest zewnętrzną nazwą (nazwą zmiennej, stałej, obiektu, funkcji, perspektywy, procedury, metody, itd.), zaś x jest bytem czasu wykonania (zwykle referencją do obiektu). Parę będziemy zapisywać n( x ). Definicję tę uogólnimy. Koncepcja bindera jest bardzo prosta. Zadaniem bindera n(x) jest wiązanie, czyli zastąpienie nazwy n występującej w zapytaniu lub programie na wartość x, będącą bytem czasu wykonania. Dla dowolnej nazwy występującej w programie musi być na stosie odpowiedni binder, który zamieni tę nazwę na byt czasu wykonania. Nazwa, dla której odpowiadający jej binder nie istnieje, nie może być związana, czyli jest błędna. Przy luźnych modelach składu (tzw. półstrukturalnych, semistructured) możemy uznać, że wiązanie takiej nazwy jest puste (jest pustym zbiorem). binder

© K.Subieta. Obiektowe języki zapytań 07, Folia 19 kwiecień 2004 Rola binderów Uogólnienie: Binder jest parą n(x), gdzie n może być dowolną zewnętrzną nazwą definiowaną przez programistę, użytkownika, projektanta aplikacji, projektanta bazy danych, itp., zaś x może być dowolnym rezultatem zwracanym przez zapytanie. W podejściu stosowym do języków zapytań stos środowisk składa się z sekcji odpowiadających poszczególnym środowiskom czasu wykonania. Sekcja jest zbiorem binderów do bytów programistycznych odpowiadającego jej środowiska. W budowanej przez nas semantyce bindery będą miały także inne zastosowania, w szczególności, będą niekiedy zwracane jako rezultaty zapytań. Stos środowiskowy będziemy oznaczać ENVS (ENVironment Stack).

© K.Subieta. Obiektowe języki zapytań 07, Folia 20 kwiecień 2004 Przykładowy skład i 1 Prac i 5 Prac i 9 Prac i 17 Dział i 22 Dział Obiekty trwałe i 127 Xi 128 Y Obiekty ulotne

© K.Subieta. Obiektowe języki zapytań 07, Folia 21 kwiecień 2004 Przykładowy ENVS Sekcja chwilowa przetwarzania Sekcja chwilowa przetwarzania - własności lokalne wywołanej metody Sekcja chwilowa przetwarzania - własności wnętrza aktualnie przetwarzanego obiektu Prac Sekcje danych globalnych Prac(i 1 ) X(i 127 ) Y(i 128 ) N(5) I("Maria") Nazwisko(i 10 ) Zarobek(i 11 ) Adres(i 12 ) PracujeW(i 16 ) Bindery do obiektów/zmiennych nietrwałych aktualnej sesji użytkownika Prac(i 1 ) Prac(i 5 ) Prac(i 9 ) Dział(i 17 ) Dział(i 22 ) Bindery do globalnych funkcji bibliotecznych Bindery do zmiennych i funkcji środowiska komputerowego Sekcja bazy danych

© K.Subieta. Obiektowe języki zapytań 07, Folia 22 kwiecień 2004 Pojęcie stanu Pojedyncza referencja jest szczególnym przypadkiem rezultatu zapytania. W ten sposób, poprzez definicję składu obiektów i stosu ENVS uzyskaliśmy precyzyjną definicje pojęcia stanu. W podejściu stosowym pojęcie stanu (dziedzina Stan) jest definiowane jako stan składu obiektów plus stan stosu środowisk. Brak pojęcia stanu jest bardzo poważną wadą wielu koncepcji i modeli obiektowych, w szczególności standardów SQL-99, XQuery i ODMG. Zgodnie z wcześniejszymi definicjami, semantyka zapytania jest funkcją odwzorowującą stan, czyli skład obiektów oraz stan ENVS, w rezultat. Odwzorowaniem, które będzie podstawą dalszych definicji, jest semantyka pojedynczej nazwy występującej w zapytaniu lub w programie. Czynność ewaluacji takiej nazwy nosi nazwę wiązania. Wiązanie odbywa się na ENVS zgodnie z regułą stosu, które nakazuje przeszukiwanie stosu od jego wierzchołka w kierunku jego podstawy, z pominięciem niektórych sekcji.

© K.Subieta. Obiektowe języki zapytań 07, Folia 23 kwiecień 2004 Reguły wiązania nazw Zasady przeszukiwania stosu i wyznaczania rezultatu wiązania są następujące: Dla wiązanej nazwy n, ENVS jest przeszukiwany aż do znalezienia sekcji, w której znajduje się binder oznaczony nazwą n. Po znalezieniu takiej sekcji wyszukiwanie jest zakończone. Wszystkie bindery z tej sekcji oznaczone nazwą n tworzą rezultat przeszukiwania. Rezultat wiązania uzyskuje się poprzez odrzucenie ze znalezionych binderów nazwy n i pozostawienie wyłącznie wartości tych binderów.

© K.Subieta. Obiektowe języki zapytań 07, Folia 24 kwiecień 2004 Prac(i 1 ) X(i 127 ) Y(i 128 ) N(5) I("Anna") Nazwisko(i 10 ) Zarobek(i 11 ) Adres(i 12 ) PracujeW(i 16 ) Prac(i 1 ) Prac(i 5 ) Prac(i 9 ) Dział(i 17 ) Dział(i 22 ) start przeszukiwania stosu Mechanizm przeszukiwania stosu - funkcja bind bind( nazwa ) - funkcja wiązania nazw: bind( Prac ) = i 1 bind( Y ) = i 128 bind( I ) = "Anna" bind( Zarobek ) = i 11 bind( Dział ) = { i 17, i 22 } Binder Prac(i 1 ) znajduje się w dwóch sekcjach stosu, ale w tym przypadku wiązanie nazwy Prac zwróci i 1, a nie {i 1, i 5, i 9 }.

© K.Subieta. Obiektowe języki zapytań 07, Folia 25 kwiecień 2004 Rezultaty zwracane przez zapytania Oprócz referencji i wartości atomowych zapytania mogą zwrócić bindery. Uogólnienie podanych założeń prowadzi do następującej rekurencyjnej definicji dziedziny Rezultat: Atomowa wartość należąca do V (np. 3, "Kowalski", TRUE, itd.) należy do dziedziny Rezultat. Rreferencja do obiektu (inaczej identyfikator obiektu) dowolnego typu należąca do I należy do dziedziny Rezultat. W szczególności, do dziedziny Rezultat należą referencje do metod, procedur, funkcji, perspektyw, itd. Jeżeli x Rezultat, zaś n N jest dowolną nazwą, wówczas para n(x) należy do dziedziny Rezultat. Taki rezultat będziemy nazywać nazwaną wartością; w innym kontekście został on już określony jako binder. Jeżeli x 1, x 2, x 3,... Rezultat, wówczas struct{ x 1, x 2, x 3,...} Rezultat. struct jest konstruktorem struktury, czyli pewnym dodatkowym atrybutem (flagą) rezultatu. Kolejność elementów w strukturze ma znaczenie. Jeżeli x 1, x 2, x 3,... Rezultat, wówczas bag{ x 1, x 2, x 3,...} Rezultat oraz sequence{ x 1, x 2, x 3,...} Rezultat.

© K.Subieta. Obiektowe języki zapytań 07, Folia 26 kwiecień 2004 Przykłady zbioru Rezultat Atomowe: 25, "Kowalski", i 11, i 18 Złożone: struct{i 1, i 56 } sequence{ i 1, i 6, i 11 } bag{ struct{i 1, i 56 }, struct{i 6, i 72 }, struct{i 11, i 72 }} bag{struct{n("Kowalski"), Zarobek(2500), d(i 56 )}} bag{struct{ Dział(i 56 ), Prac( bag{ struct{ n("Nowak"), s(i 9 ) }, struct{ n("Stec" ), s(i 14 ) }})} Przy pomocy podanych konstruktorów można tworzyć struktury przypominające obiekty. Nie są one jednak obiektami, ponieważ nie można im przypisać własnych identyfikatorów i nie można ich związać z istniejącą lub nową klasą. Używając terminologii ODMG, rezultaty zapytań są literalami. Takiej terminologii nie będziemy stosować.

© K.Subieta. Obiektowe języki zapytań 07, Folia 27 kwiecień 2004 Rezultaty zapytań zapisane jako tablice sequence{ i 1, i 6, i 11 } i 1 i 6 i 11 bag{ struct{i 1, i 56 }, struct{i 6, i 72 }, struct{i 11, i 72 }} i 1 i 6 i 11 i 56 i 72 bag{ struct{ n("Nowak"), s(i 9 )}, struct{ n("Stec"), s(i 14 )}, struct{ n("Mikuła" ), s(i 18 )}} n "Nowak" "Stec" "Mikuła" s i 9 i 14 i 18

© K.Subieta. Obiektowe języki zapytań 07, Folia 28 kwiecień 2004 Otwieranie nowego zakresu na stosie środowisk W klasycznych językach programowania otwieranie nowego zakresu na wierzchołku ENVS następuje w momencie wywołania procedury (funkcji, metody) lub w momencie wejścia sterowania w nowy blok. Skasowanie tej sekcji następuje w momencie zakończenia działania procedury (funkcji, metody) lub w momencie wyjścia sterowania z bloku. Do klasycznych sytuacji otwierania nowego zakresu na ENVS dołączymy nową. Stanowi ona istotę podejścia stosowego do języków zapytań. Pewne operatory występujące w zapytaniach (zwane niealgebraicznymi) działają na stosie podobnie do wywołań bloków programów. Np. w zapytaniu języka SBQL: Prac where (Nazwisko = Kowalski and Zarobek > 1000) część (Nazwisko = Kowalski and Zarobek > 1000) jest blokiem, który jest ewaluowany w nowym środowisku określonym przez wnętrze obiektu Prac aktualnie testowanego przez operator where. Na stos ENVS jest wkładana nowa sekcja zawierająca bindery do wszystkich wewnętrznych własności (atrybutów, metod, itd.) tego obiektu Prac.

© K.Subieta. Obiektowe języki zapytań 07, Folia 29 kwiecień 2004 Ilustracja otwierania nowego zakresu PRAC (i 1 ) PRAC (i 5 ) PRAC(i 9 ) DZIAŁ (i 17 ) DZIAŁ (i 22 ) Nazwisko(i 10 ) Zarobek(i 11 ) Adres(i 12 ) PracujeW(i 16 ) PRAC (i 1 ) PRAC (i 5 ) PRAC(i 9 ) DZIAŁ (i 17 ) DZIAŁ (i 22 ) Stos w momencie ewaluacji zapytania PRAC. Ewaluacja (wiązanie) nazwy PRAC zwraca {i 1, i 5, i 9 } PRAC where (Nazwisko = Kowalski and Zarobek > 1000) Stos w momencie ewaluacji pod-zapytania (Nazwisko = Kowalski and Zarobek > 1000) dla trzeciego obiektu PRAC. Ewaluacja (wiązanie) nazwy Nazwisko zwraca i 10. Ewaluacja (wiązanie) nazwy Zarobek zwraca i 11. Operator where iteruje po rezultacie zapytania PRAC. W każdej iteracji wkłada (i po ewaluacji zdejmuje) sekcję stosu zawierającą bindery do wnętrza kolejnego obiektu PRAC. wiązanie

© K.Subieta. Obiektowe języki zapytań 07, Folia 30 kwiecień 2004 Funkcja nested Intencją jest zdefiniowanie funkcji, której argumentem jest referencja do obiektu, zaś wynikiem jest wewnętrzne środowisko tego obiektu, które ma być umieszczone na ENVS. Takie środowisko jest zbiorem binderów. Funkcję nazwaliśmy nested. nested(i 9 ) = { Nazwisko (i 10 ), Zarobek (i 11 ), Adres (i 12 ), PracujeW (i 16 ) } i 9 Prac i 10 Nazwisko Barski i 11 Zarobek 2000 i 16 PracujeW i 13 Miasto Radom i 14 Ulica Wolska i 15 NrDomu 12 i 12 Adres

© K.Subieta. Obiektowe języki zapytań 07, Folia 31 kwiecień 2004 Uogólnienie funkcji nested Dla dowolnej wartości atomowej v V nested( v ) = (zbiór pusty). Dla identyfikatora i obiektu atomowego (nie posiadającego podobiektów) nested( i ) =. Dla obiektu złożonego,,..., }> nested( i ) = { n 1 (i 1 ), n 2 (i 2 ),..., n k (i k ) }. Dla identyfikatora i obiektu pointerowego dla którego istnieje w składzie obiekt nested( i ) = { n 1 (i 1 ) }. Dla dowolnego bindera n(x) nested( n(x) ) = { n(x) }. Jeżeli argumentem funkcji nested jest struktura elementów, wówczas wynik jest sumą teorio-mnogościową rezultatów funkcji nested dla pojedynczych elementów tej struktury nested( struct{ x 1, x 2, x 3,...}) = nested( x 1 ) nested( x 2 ) nested( x 3 )...