Podejście stosowe do obiektowych języków programowania baz danych

Prezentacja na temat: "Podejście stosowe do obiektowych języków programowania baz danych"— Zapis prezentacji:

1 Podejście stosowe do obiektowych języków programowania baz danych
Wykładowca: Kazimierz Subieta Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa Wykład 04 Podstawy semantyczne języków zapytań

2 Składnia, semantyka i pragmatyka języka
Każdy język komputerowy (dowolny język?) można scharakteryzować przez trzy aspekty: Składnia: jak konstruować wyrażenia języka? Semantyka: co te wyrażenia znaczą dla człowieka i dla systemu komputerowego? Pragmatyka: jak i po co używać wyrażeń języka dla zapewnienia tych celów praktycznych, dla których język został stworzony? Każdy z tych aspektów ma swoją specyfikę, która będzie omówiona.

3 Aspekt języka: składnia
syntax Składnia oznacza reguły tworzenia napisów (wyrażeń) języka z elementarnych symboli (alfabetu). Z matematycznego punktu widzenia składnia jest (zwykle nieskończonym) zbiorem ciągów symboli alfabetu. Taka definicja składni jest niekompletna i mało wartościowa z punktu widzenia definicji dalszych aspektów języka. Istotną cechą składni są reguły składniowe określające sposób budowania wyrażeń języka. Stanowią one nieodłączny element definicji języka, niezbędny do jego definicji. Może się zdarzyć, że różne zestawy reguł składniowych R1 i R2 generują taki sam zbiór ciągów symboli alfabetu, ale zestaw R1 jest poprawny z punktu widzenia definicji tego języka, podczas gdy zestaw R2 jest niepoprawny. Powodem poprawności bądź niepoprawności składni jest semantyka przypisana do reguł składniowych.

4 Aspekt języka: semantyka (1)
semantics Semantyka określa znaczenie wyrażeń języka, czyli stosunku napisów tego języka do rzeczy, które te napisy wyrażają lub oznaczają. Ogólna definicja semantyki wymaga zdefiniowania pewnej dziedziny znaczeń, pewnego uniwersum dyskusji o znaczeniach. Definicja takiej dziedziny zależy od tego, na jakim poziomie definiujemy semantykę, kto jest odbiorcą naszej definicji i jaki jest cel definicji. Przykładowo, semantyką programu w języku Java może być odpowiadający mu ciąg instrukcji maszyny abstrakcyjnej. Tego rodzaju definicje semantyki byłyby bezwartościowe dla programisty. Programistę interesuje wyłącznie to, jaka będzie zależność pomiędzy danymi wejściowymi programu oraz wynikiem programu. Semantyka języka komputerowego musi uwzględnić człowieka i maszynę. Adresatem definicji semantyki jest umysł programisty: semantyka jest tym, co programista „rozumie” poprzez napis języka. Adresatem semantyki jest również system komputerowy, który zamienia napisy języka na akcje komputera.

5 Aspekt języka: semantyka (2)
semantics Odwzorowanie napisu w jego znaczenie powinno odwoływać się do pewnych pojęć i operacji abstrakcyjnych, a nie do fizycznego kodu programu lub fizycznej organizacji danych. Jest bardzo istotne, aby nieformalne „rozumienie” napisów języka przez programistę było całkowicie zgodne z wyrażonym formalnie odwzorowaniem tych napisów na pojęcia i operacje abstrakcyjne. Niezgodność pomiędzy nieformalnym rozumieniem napisów języka, a formalnym odwzorowaniem tego napisu w akcje komputera jest określana jako semantyczna rafa. SQL jest przykładem języka obfitującego w różne semantyczne rafy, np. związane z klauzulą group by lub pojęciem wartości zerowej. Z punktu widzenia realizatorów języka, semantyką jest wszystko to, co powinni oni widzieć, aby ten język efektywnie zaimplementować. Zależy nam na opisie abstrakcyjnym, pojęciowym, a nie na formalistycznym odwzorowaniu np. w ciąg instrukcji maszyny wirtualnej Java. Tego rodzaju semantykę nazywa się często abstrakcyjną implementacją.

6 Aspekt języka: pragmatyka
pragmatics Pragmatyka języka wyznacza jego funkcję użytkową w interakcji międzyludzkiej lub w interakcji pomiędzy człowiekiem i maszyną. Składnia i semantyka języka są służebnicami jego pragmatyki Bez pragmatyki budowanie składni i semantyki jest bez sensu. Pragmatyka opisuje w jaki sposób należy używać tego języka, w jakim celu, przy użyciu jakich reguł praktycznych. Pragmatyka oznacza dopasowanie wyrażeń języka do konkretnego problemu, który mamy do rozwiązania. Można doskonale znać składnię i semantykę danego języka programowania, natomiast być całkowicie bezradnym stając przed problemem, jak przy pomocy tego języka zrobić użyteczny program. Pragmatyka nie podlega formalizacji: można ją objaśniać przy pomocy przypadków, przykładów i analogii i nauczyć poprzez wielokrotne próby zastosowania języka do konkretnych problemów. Nie można nauczyć się prowadzenia samochodu poprzez czytanie podręcznika. Nie można nauczyć się języka bez używania tego języka.

7 Pragmatyka a semantyka
W literaturze przemysłowo-komercyjnej pragmatyka jest dość często plątana z semantyką. Semantyka jest objaśniana poprzez przykłady użycia języka dopasowane do pewnej konkretnej sytuacji lub zadania. Np. zdanie z podręcznika języka zapytań „podaj nazwiska i zarobki osób posiadających stanowisko nauczyciela” (poparte odpowiednim zapytaniem w SQL lub OQL) jest typowym użyciem pragmatyki języka do objaśnienia jego semantyki. Tę metodę stosuje m.in. ODMG. Pragmatyka nie jest jednak dobrą metodą objaśniania semantyki, gdyż nie jest w stanie oddać wiernie tego aspektu, a szczególnie nie jest w stanie oddać wzajemnego związku poszczególnych konstrukcji języka, szczególnie w sytuacji jego rekurencyjnej definicji. Z tego powodu będziemy posiłkować się pragmatyką dla objaśniania pewnych konstrukcji języka, ale to nie zmieni faktu, że podstawowym naszym celem będzie precyzyjne objaśnienie semantyki.

8 Składnia abstrakcyjna
abstract syntax Składnia wzbudza odruch lekceważenia u specjalistów, którzy ukuli termin „lukier syntaktyczny” (syntactic sugar) na oznaczenie semantycznie nieistotnych elementów zdań lub wyrażeń. w zdaniu: select Nazwisko from Osoba where Zawód = „analityk” słowa select, from i where są lukrem. Równie dobrze można byłoby je zapisać przy pomocy innego lukru, np.: search Osoba with Zawód : „analityk” then retrieve Nazwisko Dyskusja odnośnie tego, który lukier jest lepszy, jest często niepoważna. Semantyka nie zależy od lukru syntaktycznego. Składnia pozbawiona lukru syntaktycznego jest składnią abstrakcyjną. Zapis: select A from B where C w składni abstrakcyjnej może mieć postać nazwy operatora i jego argumentów, np. select(A; B; C) . Istotne jest to, aby do reguł składniowych przyporządkować reguły semantyczne. To przyporządkowanie nazywa się semantyką kierowaną składnią.

9 Semantyka kierowana składnią
syntax-driven semantics Składnia abstrakcyjna powinna być zbudowana w taki sposób, aby odzwierciedlać reguły semantyczne. Reguła semantyczna przyporządkowana do klauzuli składniowej odzwierciedla znaczenie wyrażenia. Np. mamy składnię select A from (B where C) , której przyporządkowujemy następującą regułę semantyczną: wyznacz zbiór B; z tego zbioru odrzuć elementy nie spełniające C; następnie dokonaj projekcji wyniku na A. Jeżeli dokonalibyśmy rozbioru tego zdania w inny sposób, np (select A from B) where C , wówczas nie udałoby się zbudować poprawnej semantyki. Semantyka kierowana składnią oznacza, że: język wyrażamy w postaci reguł składni abstrakcyjnej; do każdej reguły składni abstrakcyjnej przyporządkowujemy regułę semantyczną, która bierze elementy składniowe jako argumenty.

10 Zasada modularności semantyki
modularity, compositionality Zasada modularności lub kompozycyjności mówi, że semantyka całości wyrażenia jest funkcją semantyk wszystkich części tego wyrażenia. Niech wyrażenie w ma w abstrakcyjne składni postać: gdzie w1, w2, ..., wn są podwyrażeniami wyrażenia w. Oznaczmy przez |x| semantykę napisu x. Wówczas : Zasadę tę stosujemy rekurencyjnie, t.j. semantyki |w1|, |w2|, ..., |wn| są wyznaczane analogicznie, aż do elementów alfabetu składni abstrakcyjnej. Elementom alfabetu przyporządkowujemy funkcje semantyczne w zależności od ich kategorii leksykalnej (nazwy, stałe, operatory, itd.). Zasada ta obowiązuje wszystkie formalne języki komputerowe. Dla niektórych z nich (np. SQL) wyznaczenie funkcji semantycznych zależnych od konstrukcji składniowych może być bardzo trudne ze względu na "syntaktyczne zlepki" i odległe kontekstowo zależności. w = konstrukcja_składniowa(w1, w2, ..., wn ) |w| = funkcja_zależna_od_konstrukcji_składniowej( |w1|, |w2|, ..., |wn| )

11 Język modularny lub ortogonalny
Język jest modularny lub ortogonalny, jeżeli: Jego wyrażenia w składni abstrakcyjnej zawierają mało podwyrażeń; najlepiej jeżeli maksymalne n wynosi 2 lub 3; Składnia abstrakcyjna ma niewiele klauzul (nie więcej niż 50); Język zawiera niewielką liczbę kategorii leksykalnych (od 3-ch do 10-ciu). Funkcje semantyczne są proste i naturalne dla użytkowników; Nie występują wyjątki, dodatkowe ograniczenia syntaktyczne lub semantyczne, nieregularne zależności. Język modularny/ortogonalny jest prosty w definicji, jest łatwy do uczenia się, użycia, ma krótkie podręczniki. Język modularny/ortogonalny jest łatwy do bezpośredniej implementacji i do optymalizacji. Obecna praktyka przemysłowa nie sprzyja tworzeniu języków modularnych/ ortogonalnych. Regułą są chaotyczne syntaktyczne zlepki, monstrualny eklektyzm, niejasna semantyka, mnóstwo wyjątków i ograniczeń. Przykładem negatywnym jest SQL-99 (monstrualna, eklektyczna konstrukcja).

12 Semantyka języka zapytań z lotu ptaka
Podstawą będzie założenie, że semantyka dowolnego zapytania jest funkcją odwzorowującą zbiór wszystkich stanów (przede wszystkim bazy danych, ale nie tylko) w element zbioru rezultatów zapytań. Niech Q będzie zbiorem napisów składających się na język zapytań (wyznaczonych przez jego abstrakcyjną składnię), Stan - zbiór wszystkich możliwych stanów, Rezultat - zbiór wszystkich możliwych rezultatów zapytań. Dla dowolnego napisu q  Q semantyka jest pewną funkcją |q| odwzorowującą stan w rezultat: Jeżeli zapytanie q ma efekty uboczne, np. wywołuje metodę, która powoduje zmiany w bazie danych, wówczas semantyka takiego zapytania wyraża się poprzez funkcję: Jeżeli q jest zleceniem aktualizacyjnym (np. klauzulą update języka SQL), to: |q|: Stan  Rezultat |q|: Stan  (Rezultat  Stan) |q|: Stan  Stan

13 Wady własności domkniętości
closure property Własność ta mówi, że zarówno argumentami jak wynikiem dowolnego zapytania muszą być elementy należące do tej samej dziedziny. Np. algebra relacji: argumentami zapytania są relacje, wynikiem jest relacja. Własność domkniętości implikuje podział zapytań na zachowujące obiekty i generujące obiekty. Te ostatnie zwracają obiekty z nowym OID. Własność tę próbuje się lansować jako aksjomat języków zapytań. Przyjmiemy inny punkt widzenia: Dla obiektowych języków zapytań własność domkniętości jest nonsensem, tak samo jak podział na zapytania zachowujące i generujące. Jest ona zresztą nonsensem w ogóle, również nonsensem dla SQL. Używając oznaczeń z poprzedniego slajdu, własność ta oznacza, że: Stan = Rezultat  Rezultat  Rezultat  Rezultat  Rezultat  Rezultat  ... Nic takiego nie będziemy zakładać. Jakkolwiek zbiory Stan i Rezultat będziemy budować z tych samych cegiełek, zbiory te będą zasadniczo różne, o różnej intencji, przeznaczeniu i roli semantycznej.

14 Co więc należy zdefiniować?
Dla potrzeb semantyki języka zapytań należy zdefiniować: Dziedzinę syntaktyczną zapytań, oznaczony wcześniej jako Q, w postaci składni abstrakcyjnej. Zbiór wszystkich stanów, oznaczony wcześniej jako Stan. Zbiór wszystkich rezultatów zapytań, oznaczony wcześniej jako Rezultat. Dla każdej klauzuli syntaktycznej z dziedziny Q, należy zdefiniować odwzorowanie jej w znaczenie (semantykę) tej klauzuli. Najczęściej będzie to funkcja Stan → Rezultat. Niekiedy będzie to funkcja Stan → Rezultat × Stan. Musimy zadbać o modularność, czyli taką definicję, która pozwoli na budowanie semantyki dowolnie złożonych zapytań poprzez rekurencyjne złożenie semantyk jego komponentów.

15 Co to jest "stan"? state Zazwyczaj, pojęcie "stanu" jest utożsamiane ze "stanem bazy danych". Jest to uproszczenie i ograniczenie. W naszym przypadku pojęcie stanu będzie znacznie rozszerzone. Ze względu na ortogonalną trwałość interesować nas będzie nie tylko stan bazy danych, ale także stan nietrwałych zmiennych/obiektów używanych przez programy aplikacyjne, procedury, funkcje, metody, itd. Całość trwałych i nietrwałych zmiennych/obiektów będziemy nazywać składem obiektów (krótko: składem). Cecha trwałości nie będzie nas w gruncie rzeczy interesować. Skład zawiera także pewne cechy globalnego środowiska, takie jak czas bieżący, datę, login aktualnego użytkownika, itd. Interesować nas będzie także chwilowy stan przetwarzania, który jest odwzorowany w postaci stosu środowisk (environment stack). Stan = Stan składu obiektów + Stan stosu środowisk

16 Po co nam taka teoria? Zasadniczym celem teorii jest wnioskowanie o własnościach języka, w szczególności rozwijanie metod optymalizacji zapytań. Bez optymalizacji język zapytań jest nieefektywny dla użytkowników, zatem nie będzie zaakceptowany dla bardzo dużych baz danych. Ponieważ liczba wyrażeń języka i liczba stanów bazy danych są nieskończone, nie jest możliwe ogarnięcie w sposób ogólny wszystkich tych sytuacji, które mogą wymagać optymalizacji. Budowanie teorii jest więc niezbędne. Oprócz optymalizacji, teoria jest w stanie ustalić reguły, paradygmaty danej dziedziny, które mogą być nauczane i które mogą efektywnie służyć do budowy, analizy, porównania, wynalazczości i rozwoju produktów wytwarzanych w danej dziedzinie. Teoria jest więc silnym katalizatorem postępu. Brak dobrej teorii obiektowych języków zapytań zaowocował 20-letnim marazmem w tej dziedzinie i wadliwymi tworami (SQL99, OQL, itd.)

17 Problem optymalizacji zapytań (1)
Przyjmując własności języków zapytań, takie jak deklaracyjność, makroskopowość i wysoki poziom abstrakcji, jest regułą, że bezpośrednia, naiwna ewaluacja zapytań musi prowadzić do nieakceptowalnych czasów wykonania i konsumpcji pamięci. Np. proste zapytanie w SQL: wymaga wykonania produktu kartezjańskiego relacji wymienionych w klauzuli from. Przyjmując (rozsądnie) dostawców, produktów, krotek w relacji DP i 100 bajtów w każdej krotce tych relacji, produkt kartezjański miałby bajtów = ok. 909 terabajtów. Jeżeli sprawdzenie warunku w klauzuli where dla pojedynczej krotki trwałoby 1/ sec, to wyselekcjonowanie z produktu kartezjańskiego właściwych krotek trwałoby sec = ok. 317 lat. Podaj nazwiska dostawców dostarczających części o nazwie ”zawór”: select Dostawca.nazwisko from Dostawca, Produkt, DP where Dostawca.NrDost = DP.NrDost and DP.NrProd = Produkt.NrProd and Produkt.nazwa = ‘zawór’

18 Problem optymalizacji zapytań (2)
Naiwna ewaluacja zapytań prowadzi do nieakceptowalnych czasów wykonania i nieakceptowalnego zużycia pamięci. Język z nieakceptowalnymi własnościami jest bezużyteczny Konieczne jest zoptymalizowanie wyrażeń w taki sposób, aby czasy były akceptowalne, np. 5 sec, a obciążenie pamięci minimalne. Aby to zrobić, zapytanie należy przekształcić na inną postać (program) którego semantyka nie ulegnie zmianie w stosunku do oryginału. Ponieważ semantyka zapytania jest odwzorowaniem Stan → Rezultat, natomiast zbiory Stan i Rezultat są nieskończone, konieczne jest precyzyjne zdefiniowanie zarówno tych zbiorów jak i odwzorowania. Inżynierskie metody zwykle są nieskuteczne w konfrontacji z nieskończonością zbiorów Q, Stan i Rezultat. Konieczna jest precyzyjna definicja semantyki i efektywne metody wnioskowania w ramach tej semantyki.

19 Metody optymalizacji zapytań
Metody oparte na przepisywaniu. W metodach tych dokonuje się semantycznie równoważnego przekształcenia zapytania na taką postać, która daje lepszy czas wykonania. Wprowadzenie specjalnych struktur danych lub specjalnej organizacji danych, np. różnego rodzaju indeksy. Unikanie obliczania martwych fragmentów zapytań tj. takich fragmentów zapytania, które nie mają wpływu na jego końcowy wynik. Zapamiętywanie wyników poprzednio obliczonych zapytań (caching). Jednoczesna optymalizacja wielu zapytań. Gdy zapytania ewaluuje jeden serwer obsługujący wiele jednoczesnych zleceń od klientów, jest możliwa grupowa ewaluacja zapytań, co może dać zyski czasowe. Wybór planu ewaluacji zapytania. Temat ten pojawia się wtedy, gdy istnieje wiele równoważnych sposobów ewaluacji zapytania.

20 Wady innych teorii języków zapytań (1)
Brak jednolitego podejścia do chwilowych, trwałych, indywidualnych i masowych danych. Brak podejścia do dowolnie złożonych, zagnieżdżonych obiektów. Brak spójnego podejścia do semantyki operacji aktualizacyjnych. Brak podejścia do reguł zakresu dla nazw. Ograniczone podejście do formalizacji powiązań pomiędzy obiektami. Brak lub ograniczone podejście do formalizacji podstawowych pojęć obiektowości, takich jak złożone obiekty, klasy, metody, dziedziczenie, hermetyzacja, dynamiczne role, przesłanianie, polimorfizm, itd. Brak jasnej semantyki pomocniczych nazw występujących w zapytaniach, takich jak „zmienne krotkowe” w SQL. Nie uwzględnianie identyfikatorów obiektów, co czyni niemożliwe wyrażenie semantyki operacji na referencjach do obiektów. Brak podejścia do (aktualizowalnych) perspektyw baz danych budowanych na bazie języka zapytań.

21 Wady innych teorii języków zapytań (2)
Brak lub mało adekwatne podejście do wartości zerowych i wariantów (unii). Trudności z formalizacją tak banalnych operatorów jak operacje arytmetyczne i stringowe, funkcje zagregowane, standardowe funkcje arytmetyczne, porównania identyfikatorów obiektów, funkcje zmiany typu wartości, dereferencji, itd., Brak kompozycyjności i ortogonalności, ogromne syntaktyczne zlepki. Brak podejścia do operatora zależnego złączenia występującego np. w OQL. Brak podejścia do operacji uporządkowania i operatorów bazujących na operatorze uporządkowania (patrz np. zapytanie „Wyszukaj 50-ciu najlepiej opłacanych pracowników”). Pomijanie ważnych operatorów, takich jak np. tranzytywne domknięcia. itd. Celem podejścia stosowego jest usunięcie wszystkich tych wad.

22 Teorie matematyczne Poprzednie rozważania pozornie prowadzą nas do konieczności budowania teorii matematycznych w dziedzinie obiektowych języków zapytań i programowania. Niestety, budowa takich teorii jest obciążona poważnymi wadami: Złożoność: ze względu na wymaganą formalną precyzję teorie matematyczne są wielokrotnie bardziej złożone w stosunku do tworów, które opisują. Jakiekolwiek wnioskowanie przy tak złożonych teoriach staje się praktycznie niemożliwe. Mogą być też błędne. Bezwładność: teorie matematyczne obciążają rozwój języka, zmiany w jego konstrukcji oraz wynalazki mające na celu nowe cechy języka. Nawet mała zmiana języka powoduje konieczność przebudowania teorii i oraz rewizji wniosków uzyskanych przy pomocy poprzedniej teorii. Brak komunikatywności: teorie matematyczne nie dają szansy na budowę pomostu komunikacyjnego pomiędzy deweloperami języka a jego realizatorami. Programiści z reguły nie rozumieją i nie akceptują zaawansowanej matematyki. Wykształcenie innego typu programistów jest utopią.

23 Czy zatem budowa teorii jest skazana na porażkę?
Czy możemy mówić o formalnej teorii, która nie jest matematyczna? Matematycy starają się przekonać, że „teoria” => „matematyczna”. Na szczęście jest to fałszywy stereotyp. Nieuzasadniony w innych gałęziach technicznych. Np. projektu budynku jest wyspecyfikowany precyzyjnie poprzez rysunki, schematy, diagramy, tabele, itd. Specyfikacja jest precyzyjna i pozwala wnioskować o własnościach budynku. Podobne analogie dla elektroniki, samochodów, chemii lub innego przemysłu. Komputery nie są wyjątkiem w tym zakresie. Tu również pole dla matematyki wyrażonej eksplicite jest silnie zawężone. Nauki komputerowe są jednak znacznie młodsze od innych, stąd obecność matematycznych złudzeń i urojeń. Istotą teorii jest umożliwienie efektywnego wnioskowania o własnościach opisywanego tworu, a do tego celu matematyka nie jest niezbędna. A często jest zawalidrogą.

24 Czym powinna być teoria?
W informatyce, tak jak w innych dziedzinach, istnieje wiele autentycznych teorii, które powstały w wyniku syntezy praktycznych metod, rozwiązań i produktów. Matematyka jest o tyle ważna, o ile jest pragmatycznie skuteczna. Istotne jest, czy dana teoria prowadzi nowicjuszy do wiedzy w danej dziedzinie, umożliwiając im efektywną pracę i rozwój. Konieczna jest praktyczna weryfikacja teorii, czyli obiektywne świadectwo, że teoria jest efektywna w praktycznych sytuacjach. W naukach inżynierskich, do których należy informatyka, teorie mają charakter normujący, a nie opisowy. Teoria nie ogranicza się do opisu faktów z rzeczywistości, lecz zajmuje się oceną samych faktów, wartościowaniem ich jakości. Produkty działalności ludzkiej, w tym produkty informatyki, nie stanowią rzeczywistości obiektywnej, niezależnej od ich woli. Podlegają więc ocenom i kształtowaniu. Podejście stosowe jest efektywną teorią w zakresie języków zapytań.

25 Założenia semantyczne podejścia stosowego
W konstrukcji języka opartego o podejście stosowe będziemy przyjmować punkt widzenia, że zapytania są wyrażeniami języka programowania. Posiadają one wszystkie cechy wyrażeń takich języków (stałe, zmienne, operatory +, -, *, /, <, =, itd.) Posiadają też operatory umożliwiające „hermetyzację” tych iteracji w języku programowaniu, których celem jest obsługa kolekcji. Do nich należą: selekcja, projekcja, nawigacja, złączenie, kwantyfikatory, unia i przecięcie zbiorów, iloczyn kartezjański, itd. Z punktu widzenia konstrukcji języka zapytań jest kwestią drugorzędną, czy kolekcje są trwałe (są w bazie danych) czy też są ulotne (są lokalnymi danymi). Podejście stosowe jest relewantne dla bardzo ogólnego modelu obiektowego oraz dla wszystkich modeli, które są jego szczególnymi przypadkami, w szczególności dla modelu relacyjnego i XML-owego. Na gruncie tego podejścia można wyjaśnić precyzyjnie semantykę pewnych idealizacji SQL i OQL.

26 Nazwy, zakresy i wiązanie (1)
Konstrukcję semantyki języka będziemy opierać na pojęciach nazywania, zakresu i wiązania (naming, scoping, binding) znanych z języków programowania i realizowanych poprzez stos środowisk. Każda nazwa występująca w zapytaniu będzie wiązana do bytu programistycznego czasu wykonania (trwałych danych i obiektów, atrybutów obiektów, procedur, metod, parametrów procedur i metod, lokalnych danych procedur, itd.) zgodnie z zakresem właściwym dla tej nazwy. Reguły zakresu dla wiązania nazw będą ustalone poprzez znany stos środowisk, inaczej stos wołań (environment stack, call stack) występujący w nieomal wszystkich językach programowania. W odróżnieniu od języków programowania, gdzie stos środowisk przechowuje również wartości zmiennych/obiektów, dla języków zapytań konieczne okazało się oddzielenie stosu środowisk (ustalającego zakresy nazw) od składu obiektów.

27 Nazwy, zakresy i wiązanie (2)
Wynika to m.in. stąd, że odwołania do pewnego obiektu mogą jednocześnie pojawić się w kilku sekcjach stosu. Ponadto, zakresy dla pewnych nazw mogą dotyczyć bazy danych, natomiast stos jest strukturą ulotną, istniejącą tylko na czas działania danej aplikacji. Stos nie będzie więc przechowywał obiektów, a jedynie ich identyfikatory (oraz wraz z nimi inne elementy). Ze względu na makroskopowy charakter języków zapytań, wiązanie danej nazwy (poprzez stos) może być wielowartościowe, tj. jednej nazwie może być przypisana jednocześnie pewna kolekcja bytów czasu wykonania.

28 Operacyjna semantyka zapytań i programów (1)
Operacyjna semantyka wszystkich operatorów występujących w zapytaniach będzie zdefiniowana w terminach operacji na dwóch stosach: stosie środowisk i stosie rezultatów zapytań. Równoważny denotacyjny model semantyki jest znacznie mniej intuicyjny, przez co trudniejszy do objaśnienia, użycia i rozwoju. Zapytania, jako uogólnione wyrażenia języka programowania, mogą być zastosowane w różnych kontekstach: jako składowe zdań imperatywnych w wariancie makroskopowym (takich jak update, insert, delete języka SQL), jako parametry aktualne procedur i metod, jako środek określenia wyniku procedury lub metody funkcyjnej, itd. Zapytania mogą odwoływać się do dowolnych bytów czasu wykonania, w szczególności do trwałych obiektów, ich atrybutów, danych ulotnych, danych lokalnych procedur i metod, parametrów procedur i metod, itd. Przyjmując zasadę ortogonalnej trwałości (orthogonal persistence) - nie będą występować jakiekolwiek różnice w sposobie formułowania zapytań do trwałych i nietrwałych danych.

29 Operacyjna semantyka zapytań i programów (2)
Zapytania (oraz procedury i metody funkcyjne) nie będą zwracać obiektów, lecz referencje do obiektów (czyli ich identyfikatory) lub bardziej złożone struktury składające się z referencji, wartości elementarnych i nazw. To założenie eliminuje problemy z własnością domkniętości, zmuszającą do rozpatrywania zapytań zachowujących obiekty i generujących obiekty. Definiowany przez nas język zapytań będzie rozszerzony o możliwość definiowania procedur, perspektyw (views), procedur funkcyjnych, oraz metod. Wynik procedur i metod funkcyjnych będzie należał do tej samej kategorii semantycznej, co rezultaty zapytań. Oznacza to, że procedury i metody funkcyjne można będzie wywoływać wewnątrz zapytań. Procedury (perspektywy, metody) mogą być rekurencyjne (z założenia - nie przewidujemy specjalnej składni). Mogą także posiadać parametry.

30 Operacyjna semantyka zapytań i programów (3)
Będziemy zakładać co najmniej dwie metody transmisji parametrów: call-by-value oraz call-by-reference. Ponieważ parametrami będą zapytania (które mogą zwrócić jednocześnie wiele wartości), więc obie metody zostaną uogólnione tak, aby wykorzystać makroskopowy charakter zapytań. Wynik procedury lub metody funkcyjnej (perspektywy) będzie mógł być dodatkowo wyposażony w „wirtualne nazwy”, podobnie jak to ma miejsce w perspektywach języka SQL. Reguły wiązania i zakresu dla nazw występujących w zapytaniach zostaną ustalone w taki sposób, aby uwzględnić pojęcia obiektowości, takie jak klasy, dziedziczenie, hermetyzacja, metody, atrybuty klasowe, przesłanianie i polimorfizm, i inne. Zapytania będą bazowały na zasadzie relatywizmu obiektów, tj. składnia, semantyka i pragmatyka użycia zapytań będzie identyczna dla dowolnego poziomu hierarchii danych (w szczególności, dla poziomu całej bazy danych, dla poziomu wnętrza pojedynczego obiektu, itd.).