SBA04

advertisement
Podejście stosowe do obiektowych języków
programowania baz danych
http://www.sbql.pl
Wykładowca: Kazimierz Subieta
Polsko-Japońska Wyższa Szkoła
Technik Komputerowych, Warszawa
[email protected]
http://www.ipipan.waw.pl/~subieta
© K.Subieta. Podejście stosowe 04, Folia 1
Wykład 04
Podstawy semantyczne
języków zapytań
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.
© K.Subieta. Podejście stosowe 04, Folia 2
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.
© K.Subieta. Podejście stosowe 04, Folia 3
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.
© K.Subieta. Podejście stosowe 04, Folia 4
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ą.
© K.Subieta. Podejście stosowe 04, Folia 5
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.
© K.Subieta. Podejście stosowe 04, Folia 6
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. Podejście stosowe 04, Folia 7
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ą.
© K.Subieta. Podejście stosowe 04, Folia 8
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. Podejście stosowe 04, Folia 9
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ć:
w = konstrukcja_składniowa(w1, w2, ..., wn )
gdzie w1, w2, ..., wn są podwyrażeniami wyrażenia w.
 Oznaczmy przez |x| semantykę napisu x. Wówczas :
|w| = funkcja_zależna_od_konstrukcji_składniowej( |w1|, |w2|, ..., |wn| )
 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.
© K.Subieta. Podejście stosowe 04, Folia 10
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. Podejście stosowe 04, Folia 11
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:
|q|: Stan  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ę:
|q|: Stan  (Rezultat  Stan)
 Jeżeli q jest zleceniem aktualizacyjnym (np. klauzulą update języka SQL),
to:
|q|: Stan  Stan
© K.Subieta. Podejście stosowe 04, Folia 12
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. Podejście stosowe 04, Folia 13
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. Podejście stosowe 04, Folia 14
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
© K.Subieta. Podejście stosowe 04, Folia 15
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.)
© K.Subieta. Podejście stosowe 04, Folia 16
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:
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’
• wymaga wykonania produktu kartezjańskiego relacji wymienionych w
klauzuli from. Przyjmując (rozsądnie) 10000 dostawców, 10000 produktów,
100000 krotek w relacji DP i 100 bajtów w każdej krotce tych relacji, produkt
kartezjański miałby 1000000000000000 bajtów = ok. 909 terabajtów.
• Jeżeli sprawdzenie warunku w klauzuli where dla pojedynczej krotki
trwałoby 1/100000 sec, to wyselekcjonowanie z produktu kartezjańskiego
właściwych krotek trwałoby 1000000000000 sec = ok. 317 lat.
© K.Subieta. Podejście stosowe 04, Folia 17
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.
© K.Subieta. Podejście stosowe 04, Folia 18
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.
© K.Subieta. Podejście stosowe 04, Folia 19
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. Podejście stosowe 04, Folia 20
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.
© K.Subieta. Podejście stosowe 04, Folia 21
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ą.
© K.Subieta. Podejście stosowe 04, Folia 22
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ą.
© K.Subieta. Podejście stosowe 04, Folia 23
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. Podejście stosowe 04, Folia 24
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. Podejście stosowe 04, Folia 25
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. Podejście stosowe 04, Folia 26
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. Podejście stosowe 04, Folia 27
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.
© K.Subieta. Podejście stosowe 04, Folia 28
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. Podejście stosowe 04, Folia 29
Operacyjna semantyka zapytań i programów (3)
 Będziemy zakładać co najmniej dwie metody transmisji parametrów: callby-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.).
© K.Subieta. Podejście stosowe 04, Folia 30
Download
Random flashcards
123

2 Cards oauth2_google_0a87d737-559d-4799-9194-d76e8d2e5390

Create flashcards