I.
Wprowadzenie do  języków zapytań (1)
II.
Wprowadzenie do  języków zapytań (2)
III.
Pojęcia obiektowości w bazach danych (1)
IV.
Pojęcia obiektowości w bazach danych (2)
V.
Podstawy semantyczne języków zapytań
VI.
Modele składu obiektów
  Wstęp
  1. Założenia składniowe języka SBQL
  2. Abstrakcyjny model składu obiektów
  3. Modele M0, M1, M2 i M3 składu obiektów
  Podsumowanie
  Zadania
VII.
Stos środowisk, rezultaty zapytań, funkcja nested
VIII.
Język SBQL (Stack-Based Query Language) (1)
IX.
X.
Dalsze własności SBQL
XI.
Operatory order by i group by
XII.
Przetwarzanie struktur nieregularnych
XIII.
Rozszerzenie języków zapytań o konstrukcje imperatywne
XIV.
Procedury, procedury funkcyjne, metody, reguły zakresu
XV.
Parametry procedur i metod, procedury rekurencyjne, optymalizacja poprzez modyfikację zapytań

 

2. Abstrakcyjny model składu obiektów

Istniejące modele obiektowe są bardzo złożone. W szczególności, model obiektowy standardu ODMG włącza dużą liczbę pojęć takich jak: obiekty, literały, typy, podtypy, interfejsy, dziedziczenie, przesłanianie, polimorfizm, kolekcje, struktury, związki, operacje, wyjątki i inne. Jeszcze bardziej złożony jest model danych SQL-99, ponieważ do wymienionych pojęć dokłada (co najmniej) relacje i abstrakcyjne typy danych (ADT). Zasadniczy udział w tej złożoności mają cechy drugorzędne i brak dążenia do upraszczania i redukcji pojęć, eliminacji pojęć drugorzędnych i zastępowanie bardziej specyficznych pojęć przez pojęcia bardziej ogólne. Przykładowo, ADT jest szczególnym przypadkiem klasy, wobec czego to pojęcie jest zbędne, jeżeli są klasy, zbiór można potraktować jako szczególny przypadek bagu (i zrezygnować z pojęcia zbioru), atrybut jest szczególnym przypadkiem obiektu (czyli można zrezygnować z pojęcia atrybutu) itd.

Dla opisu semantyki języków zapytań złożoność modelu obiektowego jest czynnikiem negatywnym. Konsekwencją jest złożoność języka zapytań, w szczególności jego semantyki, ponieważ (zgodnie z zasadą korespondencji) każda cecha modelu obiektowego musi mieć swoje odbicie w składni, semantyce i/lub w pragmatyce użycia języka bazującego na tym modelu. Precyzyjna semantyka języka oznacza konieczność zdefiniowania zbioru wszystkich stanów (zbioru Stan). Złożoność modelu obiektowego powoduje złożoność definicji tego zbioru i w konsekwencji złożoność definicji języka. Oznacza to zwiększenie trudności przy formalnej analizie semantyki, czyli utrata kontroli nad uniwersalnością języka oraz znaczne zmniejszenie potencjału dla optymalizacji zapytań.

Obecny świat informatyki przemysłowo-komercyjnej przy konstrukcji języków zapytań ignoruje lub lekceważy problem ich semantyki oraz problem optymalizacji zapytań. Twierdzenia, że np. dla SQL-99 lub OQL można łatwo zbudować modele formalne, nie mają jakichkolwiek podstaw. Języki są tworzone bez cienia dbałości o minimalność, spójność poszczególnych części oraz formalną semantykę. Propozycje standardów komercyjnych są niedospecyfikowane w zakresie semantyki (co spowoduje niekompatybilne implementacje) lub nieimplementowalne w całości z powodu nadmiernego skomplikowania zarówno modelu obiektowego, jak i języka. Te okoliczności, wraz z rozszerzeniami ad hoc wprowadzanymi przez wytwórców oprogramowania, podważają sens tych standardów.

Z tego powodu konieczne staje się uproszczenie modeli obiektowych lub taka abstrakcja nad tymi modelami, która byłaby formalnie prosta i jednocześnie dostatecznie wiernie odwzorowywałaby modele tworzone przez praktyków. Właśnie prostota formalna modelu relacyjnego stała się źródłem jego sukcesu, gdyż umożliwiła wyciągnięcie daleko idących wniosków zarówno na drodze intuicyjnej, jak i formalnej.

W odróżnieniu od modelu relacyjnego, modele obiektowe wprowadzają znacznie więcej pojęć. Występuje także różne rozumienie tych samych pojęć, np. pojęcia klasy. Trudno jest więc zbudować pojedynczy model, który byłby prosty i jednocześnie pasujący do wszelkich sytuacji, które zdarzyły się lub mogą się zdarzyć w praktyce. Z tego powodu nie będziemy opierali się na jednym modelu składu obiektów, lecz na ich pewnej rodzinie. Jeden z tych modeli (M1) został zaimplementowany w prototypowym systemie Loqis. Wszystkie modele będą opierały się na tej samej bazie pojęciowej. Wprowadzimy następujące modele:

  • M0: obejmuje on dowolnie powiązane hierarchiczne struktury danych; nie obejmuje pojęć klasy, dziedziczenia, interfejsu i hermetyzacji. Model M0 pozwala wyjaśnić semantykę relacyjnych języków zapytań (szczególnie SQL), przykrywa koncepcję zagnieżdżonych relacji, przykrywa struktury danych implikowane przez XML i generalnie dane określane jako półstrukturalne.

  • M1: uzupełnia M0 o pojęcia klasy, dziedziczenia i wielodziedziczenia w najczęściej spotykanym rozumieniu; nie obejmuje hermetyzacji i interfejsu.

  • M2: uzupełnia model M1 (oraz nieco go modyfikuje) wprowadzając dziedziczenie pomiędzy obiektami oraz dynamiczne role.

  • M3: uzupełnia model M1 lub M2 o pojęcie hermetyzacji (podział własności klas i obiektów na publiczneprywatne).


Podana rodzina modeli nie zamyka tematu. Pojęcia spotykane w praktyce obiektowości mogą prowadzić do koncepcji,  które nie są objęte powyższymi modelami. Powyższa rodzina modeli pozwala jednak wyjaśnić zasady semantyczne obiektowych języków zapytań dość dokładnie, w związku z tym jest nadzieja, że ewentualne rozszerzenia lub modyfikacje nie stworzą nowej jakości.

Inne podejścia do języków zapytań nie różnicują modelu składu, w związku z czym ograniczają się do jednego modelu (którego zwykle nie specyfikują explicite). Ta filozofia z góry skazana jest  na ograniczenia, gdyż różne koncepcje obiektowości owocują w różne modele składu, które nie muszą być kompatybilne z modelem składu założonym w danym podejściu do języków zapytań. Podejście stosowe jest pierwszym podejściem do języków zapytań, które można łatwo przystosować do praktycznie dowolnego modelu składu. Na dodatek, większość innych podejść do języków zapytań (w szczególności, podejścia oparte na zagnieżdżonych relacjach, obiektowych algebrach, obiektowych logikach, podejściach funkcjonalnych itd.) nie różnicuje dziedzin StanRezultat, czyli model składu jest jednocześnie wykorzystywany jako model rezultatów zapytań. Takie założenie wprowadza nieuzasadnione ograniczenia semantyczne, które owocują w wiele niedogodności formalnych oraz niemożliwości precyzyjnej specyfikacji wielu rozwiązań praktycznych.

Copyrights © 2006 PJWSTK
Materiały zostały opracowane w PJWSTK w projekcie współfinansowanym ze środków EFS.