© K.Subieta. Obiektowe języki zapytań 05, Folia 1 marzec 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 05 Podstawy semantyczne języków zapytań

© K.Subieta. Obiektowe języki zapytań 05, Folia 2 marzec 2004 Podstawy semantyczne języków zapytań

© K.Subieta. Obiektowe języki zapytań 05, Folia 3 marzec 2004 Aspekt języka: składnia 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. syntax

© K.Subieta. Obiektowe języki zapytań 05, Folia 4 marzec 2004 Aspekt języka: semantyka (1) 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. semantics

© K.Subieta. Obiektowe języki zapytań 05, Folia 5 marzec 2004 Aspekt języka: semantyka (2) 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ą. semantics

© K.Subieta. Obiektowe języki zapytań 05, Folia 6 marzec 2004 Aspekt języka: pragmatyka 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. pragmatics

© K.Subieta. Obiektowe języki zapytań 05, Folia 7 marzec 2004 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.

© K.Subieta. Obiektowe języki zapytań 05, Folia 8 marzec 2004 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ą. Składnia abstrakcyjna abstract syntax

© K.Subieta. Obiektowe języki zapytań 05, Folia 9 marzec 2004 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.

© K.Subieta. Obiektowe języki zapytań 05, Folia 10 marzec 2004 Zasada modularności semantyki 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 w 1, w 2,..., w n są podwyrażeniami wyrażenia w. Oznaczmy przez |x| semantykę napisu x. Wówczas : Zasadę tę stosujemy rekurencyjnie, t.j. semantyki |w 1 |, |w 2 |,..., |w n | 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(w 1, w 2,..., w n ) |w| = funkcja_zależna_od_konstrukcji_składniowej( |w 1 |, |w 2 |,..., |w n | ) modularity, compositionality

© K.Subieta. Obiektowe języki zapytań 05, Folia 11 marzec 2004 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).

© K.Subieta. Obiektowe języki zapytań 05, Folia 12 marzec 2004 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

© K.Subieta. Obiektowe języki zapytań 05, Folia 13 marzec 2004 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.

© K.Subieta. Obiektowe języki zapytań 05, Folia 14 marzec 2004 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.

© K.Subieta. Obiektowe języki zapytań 05, Folia 15 marzec 2004 Co to jest "stan"? 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 state

© K.Subieta. Obiektowe języki zapytań 05, Folia 16 marzec 2004 Problem optymalizacji zapytań (1) Opracowanie sprawnych metod optymalizacji jest fundamentalnym problemem w konstrukcji dowolnego języka zapytań. 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

© K.Subieta. Obiektowe języki zapytań 05, Folia 17 marzec 2004 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 – jego pragmatyka nie istnieje. Jeżeli język nie ma pragmatyki, to jest technicznym nonsensem. 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 Stan i Rezultat. Konieczna jest precyzyjna definicja (ale niekoniecznie matematyczna).

© K.Subieta. Obiektowe języki zapytań 05, Folia 18 marzec 2004 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. Optymalizacja zapytań będzie w przyszłym semestrze.

© K.Subieta. Obiektowe języki zapytań 05, Folia 19 marzec 2004 Zapytania eliptyczne (1) Istnieje pokusa dla twórców języków zapytań, aby skracać zapytania w różnorodny sposób celem zminimalizowania wysiłku ponoszonego przez użytkowników przy ich formułowaniu. Przykładowo, zamiast pisać: można zapisać: organizując ewaluację zapytań w taki sposób, aby rezultat drugiego zapytania był semantycznie zawsze taki sam, jak rezultat pierwszego. Takie niekompletne zapytania będziemy nazywać zapytaniami eliptycznymi, zaś pominięcie pewnych elementów w zapytaniu będziemy nazywać elipsą (ellipsis). Historia języków zapytań zaowocowała dziesiątkami takich pomysłów. Np. znak gwiazdki w SQL zastępujący listę atrybutów. Np. w OQL zapytanie Osoba.nazwisko jest skrótem dla select x.nazwisko from Osoba as x select * from Osoba where nazwisko = Kowalski Osoba: Kowalski elliptic queries

© K.Subieta. Obiektowe języki zapytań 05, Folia 20 marzec 2004 Zapytania eliptyczne (2) Istnieją zagrożenia wynikające z wprowadzenia elips. Twierdzi się, że program pisze się raz, ale czyta się 100 razy. Elipsy mogą utrudniać odczytanie znaczenia zapytania (szczególnie jeżeli pomijają nazwy danych). Sumaryczna energia niezbędna do napisania i 100-krotnego odczytania zapytania może zbilansować się negatywnie. Zastosowanie elips może prowadzić do niejednoznaczności rozbioru syntaktycznego (do tej samego wyrażenia można przypisać dwie lub więcej reguł semantycznych). Często elipsy mają charakter nowego pomysłu semantycznego, redundantnego w stosunku do już istniejących konstrukcji języka. Takie elipsy w gruncie rzeczy nie są w ogóle elipsami, gdyż oznaczają zmianę w interpreterze zapytań i/lub w modelu składu danych. W klasycznych językach programowania przyjmowano niegdyś zasadę, że tego rodzaju redundancja jest szkodliwa. Będziemy starali się unikać wszelkich elips przy objaśnianiu semantyki

© K.Subieta. Obiektowe języki zapytań 05, Folia 21 marzec 2004 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ń.

© K.Subieta. Obiektowe języki zapytań 05, Folia 22 marzec 2004 Wady innych teorii języków zapytań (1) 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.

© K.Subieta. Obiektowe języki zapytań 05, Folia 23 marzec 2004 Czy teorie są potrzebne? Budowanie teorii jest niezbędne. 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 i rozwoju produktów wytwarzanych w danej dziedzinie. Sama znajomość produktów informatyki jest niewystarczająca, gdyż w krótkim czasie wiedza o nich przejdzie do historii. Potrzebne jest wyodrębnienie z tych produktów pojęciowych niezmienników, abstrakcji,wniosków, klasyfikacji, które będą trwałe w długim czasie. Niestety, pojecie teorii jest wypaczone przez matematyków działających w obszarze informatyki. Występuje nieuzasadnione zawłaszczenie terminu teoria wyłącznie dla tworów intelektualnych używających zaawansowanej matematyki. Biorąc ich stosunek dla praktyki, większość z nich nie jest teorią. Teorie matematyczne w informatyce najczęściej do niczego nie służą oprócz naukowych karier ich twórców. To spowodowało, że świat prawdziwej informatyki z obrzydzeniem reaguje na słowo teoria.

© K.Subieta. Obiektowe języki zapytań 05, Folia 24 marzec 2004 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ń.

© K.Subieta. Obiektowe języki zapytań 05, Folia 25 marzec 2004 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.

© K.Subieta. Obiektowe języki zapytań 05, Folia 26 marzec 2004 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.

© K.Subieta. Obiektowe języki zapytań 05, Folia 27 marzec 2004 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.

© K.Subieta. Obiektowe języki zapytań 05, Folia 28 marzec 2004 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 pozwoliłby wprawdzie na eliminację stosu rezultatów, ale 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.

© K.Subieta. Obiektowe języki zapytań 05, Folia 29 marzec 2004 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.

© K.Subieta. Obiektowe języki zapytań 05, Folia 30 marzec 2004 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.).