7. Typowe wady teorii języków zapytań

7.1. Własność domkniętości (closure property)

W podejściach mających swoje korzenie w modelu relacyjnym języki zapytań są budowane w oparciu o tzw. własność domkniętości (closure property). Własność ta zakłada, że w danym modelu zostaje wyróżniony (zwykle nieskończony) zbiór pewnych bytów (wartości lub struktur danych), które podlegają przetwarzaniu przez zapytanie; oznaczmy ten zbiór przez { r1, r2, ... }. W modelu relacyjnym elementy ri są relacjami; w innych modelach są to inne struktury, np. zbiory obiektów. Z semantycznego punktu widzenia każde zapytanie q jest funkcją, które bierze pewną liczbę takich elementów ri jako argument i zwraca jako wynik element rj należący do tego samego zbioru. Przykładowo, zapytanie q bierze pewną liczbę relacji, kombinuje je za pomocą pewnych operatorów lub konstrukcji językowych i jako wynik zwraca relację. W popularnych sformułowaniach teorii obiektowych języków zapytań, zapytanie jako swój argument bierze pewną liczbę zbiorów obiektów i jako wynik zwraca zbiór obiektów.

To sformułowanie wymaga drobnego uogólnienia. Mianowicie, w istocie zapytanie q może działać na wielu zestawach elementów ri i w zależności od zestawu, zwrócić inny element rj. Inaczej mówiąc, zbiór { r1, r2, ... } można podzielić na podzbiory R1, R2, .... Z semantycznego punktu widzenia zapytanie q jest funkcją odwzorowującą element produktu kartezjańskiego Ri1´Ri2´...´Rik w element pewnego zbioru Ri (gdzie Ri , Rij Î { R1, R2, ...}).

Zdaniem obrońców tej koncepcji, własność domkniętości jest warunkiem koniecznym dla zagnieżdżania zapytań. W istocie, jeżeli zapytanie q zwraca element rj należący do zbioru { r1, r2, ... }, to zapytanie to może być użyte w dowolnym miejscu innego zapytania, gdzie może być użyty element rj. Opisana wyżej własność domkniętości jest uznawana przez niektórych autorów za podstawową i niepodważalną zasadę wszystkich języków zapytań.

Wyraźnie musimy odciąć się od tej koncepcji::

Dodać należy, że wszystkie wymienione wyżej podejścia do obiektowych języków zapytań (poza podejściem stosowym) mniej lub bardziej explicite przyjmują własność domkniętości. Jest to wystarczający powód, aby były  nieadekwatne do opisu semantyki rzeczywistych języków zapytań.

Co jest złego we własności domkniętości? Można wytknąć błąd logiczny w argumentacji zwolenników tej koncepcji: własność domkniętości jest warunkiem dostatecznym zagnieżdżania zapytań, ale często argumentacja podnosi ją do warunku koniecznego. Konstruktywna odpowiedź na to pytanie wymaga jednak nieco głębszego spojrzenia na problem. Pewne symptomy nieadekwatności tej zasady są następujące:

• Niektóre zapytania, np. "Podaj liczbę wszystkich pracowników" zwracają po prostu wartości elementarne, w tym przypadku liczbę naturalną. Czy takie liczby też mamy uważać za "zbiory obiektów" (zgodnie z zasadą domkniętości)?
  
  
• Aktualizacje mają zastosowanie dla niektórych elementów zbioru {r1, r2, ...} (np. dla zapamiętanych relacji), natomiast nie mają zastosowania dla innych, np. dla wyniku zapytania: "Dla każdego działu podaj maksymalny zarobek jego pracowników.". Elementy zbioru { r1, r2, ... } różnią się więc bardzo istotną cechą. Co to za cecha, które je różni i na czym ona polega?
  
  
• Przyjmując, że dla obiektowych języków zapytań argumentem zapytania są zbiory obiektów i wynikiem zapytania jest także zbiór obiektów, powstaje pytanie, w jaki sposób przypisać identyfikatory dla obiektów zwracanych przez zapytanie. W literaturze rozważa się dwie możliwości: zapytania należą do rodzaju "zachowujących obiekty" (object preserving), czyli takie, które zwracają istniejące obiekty, lub do rodzaju "generujących obiekty" (object generating), czyli takie, które zwracają nowe obiekty, przypisując im nowe identyfikatory. Pierwszy przypadek oznacza bardzo silne ograniczenie języka zapytań, gdyż np. banalne zapytanie "Dla każdego działu podaj maksymalny zarobek jego pracowników." staje się semantycznie niepoprawne. Drugi przypadek powoduje konieczność nadania unikalnych identyfikatorów obiektów dla każdego nowego rezultatu generowanego przez zapytanie, co narusza podstawową zasadę determinizmu zapytań: za każdym razem to samo zapytanie, działające na tych samych obiektach zwraca inny wynik, ponieważ identyfikatory obiektów zwracanych przez to zapytanie za każdym razem mogą/muszą być inne.
  
  
• Ujmując rzecz nieco bardziej generalnie, własność domkniętości nie uwzględnia dwóch fundamentalnych własności struktur danych oraz języków, które operują na tych strukturach:
  
  
  • Nie uwzględnia pojęcia stanu, na którym operują zapytania i który może być zmieniony przez konstrukcje językowe bazujące na zapytaniach. Zapytania operują na stanie (np. stanie bazy danych) i zwracają wynik, który nie wchodzi w skład tego stanu.
    
    
  • Nie uwzględnia bardzo istotnej kwestii nazw, które pojawiają się w zapytaniach. W istocie, zapytanie nie jest prostym kombinowaniem elementów ze zbioru {r1, r2,...}, jak to przewiduje własność domkniętości, ponieważ w pewnym fragmencie zapytania może pojawić się definicja nazwy (np. w OQL po słowie kluczowym as), która będzie wykorzystana w innym fragmencie tego samego zapytania. Precyzyjne uwzględnienie różnych kategorii nazw, które mogą wystąpić w zapytaniach (nazw obiektów, atrybutów, metod, parametrów metod, nazw pomocniczych,itd.) oraz reguł ich wiązania i zakresu jest kluczowe dla zrozumienia semantyki języka zapytań.
    

Z powyższych powodów naszą semantykę języków zapytań będziemy budować na zupełnie innych zasadach, które bezpośrednio nawiązują do (posiadającej lepsze podstawy formalne) semantyki języków programowania.

7.2. Typowe wady koncepcji

Niżej przeliczymy niektóre wady koncepcyjne spotykane (w większym lub mniejszym stopniu) w wymienionych wyżej propozycjach.

• Brak jednolitego, ortogonalnego podejścia do chwilowych, trwałych indywidualnych i masowych (bulk) danych. Z reguły, podejścia zajmują się wyłącznie danymi trwałymi i masowymi. Istniejące formalizacje prawie nie zauważają faktu, że atrybuty obiektu mogą być również masowe (powtarzalne), przez co np. zdefiniowanie operacji złączenia bazującej na takim atrybucie w obiektowej algebrze jest niemożliwe lub bezsensowne.
  
  
• Brak spójnego podejścia do semantyki operacji aktualizacyjnych, takich jak podstawienie (update), wstawianie (insert), tworzenie (create) i usuwanie (delete); brak uwzględnienia faktu, że języki zapytań muszą być integrowane z konstrukcjami programistycznymi (takimi jak instrukcje sterujące i procedury). Operacje te wymagają wprowadzenia pojęcia stanu.
  
  
• Brak podejścia do reguł zakresu nazw użytych w zapytaniach. Temat ten nie jest trywialny, zważywszy na fakt, że w tych zapytaniach mogą zdarzać się bardzo różne nazwy, np. obiektów, ich atrybutów, metod, procedur, atrybutów klasowych, zmiennych lokalnych, parametrów metod i procedur, zmiennych środowiskowych itd. Kontrola zakresu nazw jest konieczna w przypadku, gdy zapytania mają być zintegrowane z konstrukcjami programistycznymi, takimi jak: (rekurencyjne) procedury, klasy, metody, moduły, bloki, parametry procedur itp. Systematyczne podejście do tego problemu wymaga wprowadzenia dyscypliny stosowej (stosu środowisk). To pojęcie nie występuje w żadnym z ww. podejść, przez co ich praktyczna nieadekwatność jest ewidentna na pierwszy rzut oka.
  
  
• Brak lub bardzo ograniczone podejście do formalizacji powiązań pomiędzy obiektami. Niekiedy (w obiektowych algebrach) ta formalizacja polega na tym, że powiązania modeluje się tak jak w modelu relacyjnym (poprzez klucze główne i obce), następnie obsługuje poprzez operację złączenia. Takie zabiegi z punktu widzenia optymalizacji zapytań są nonsensem, gdyż przejście wzdłuż powiązań (implementowanych poprzez wskaźniki) jest znacznie bardziej sprawne niż operacja złączenia optymalizowana za pomocą nawet najefektywniejszych metod.
  
  
• Brak lub ograniczone podejście do formalizacji podstawowych pojęć obiektowości, takich jak złożone obiekty, klasy, abstrakcyjne typy danych, metody, dziedziczenie, hermetyzacja, dynamiczne role, przesłanianie, polimorfizm, prototypy itd.
  
  
• Brak jasnej semantyki pomocniczych nazw występujących w zapytaniach, takich jak "zmienne krotkowe" w SQL (występujące w klauzuli from za nazwą tabeli), zmienne "związane" przez kwantyfikatory, kursory w zdaniach "for each" itd. W niektórych z wymienionych podejść tego rodzaju nazwy nie występują na poziomie formalnego modelu języka, lecz na poziomie metajęzyka (np. w podejściach opartych na logice), co uniemożliwia ich formalne traktowanie. Generalnie, zmieszanie poziomu formalnego modelu języka z poziomem metajęzyka jest podstawową wadą koncepcji wielu ww. podejść (np. obiektowych algebr, gdzie formuła parametryzująca operator złączenia pochodzi z poziomu metajęzykowego, ale jest traktowana tak, jakby była składową języka tej algebry).
  
  
• Brak podejścia do identyfikatorów (tożsamości) obiektów, co czyni niemożliwe wyrażenie semantyki tych operacji i własności, które bazują na referencjach do obiektów, np. operatorów aktualizacyjnych, metody transmisji parametrów call-by-reference itd. Z tego powodu wszystkie wymienione wyżej podejścia są "zorientowane na wartości" (value-oriented), tj. niedostatecznie precyzyjnie modelują model obiektowy, gdzie wewnętrzny unikalny identyfikator obiektu jest podstawowym wyróżnikiem.
  
  
• Brak podejścia do perspektyw baz danych budowanych na bazie języka zapytań i związanego z nimi ważnego tematu aktualizacji perspektyw.
  
  
• Brak lub mało adekwatne podejście do wartości zerowych i wariantów (unii), które mogą być cechą obiektowych struktur danych.
  
  
• Brak podejścia do operatorów innych niż klasyczne operatory "relacyjne" (selekcja, projekcja, złączenie, suma zbiorów, iloczyn kartezjański itd.); 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 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").
  
  
• Brak kompozycyjności i ortogonalności, ogromne syntaktyczne zlepki, przez co np. takie "zapytania" jak "Ile wynosi 2+2?" stają się problematyczne. Wada ta oznacza zredukowanie minimalności, ortogonalności i uniwersalności języka.
  
  
• Brak podejścia do operatora zależnego złączenia (dependent join) występującego w OQL. Operator ten jest dość "złośliwy", ponieważ (w pewnym sensie) wiąże poziom syntaktyczny i semantyczny języka. Komprehensje wprowadzają ten operator, ale jak wspomnieliśmy, jest to tylko koncepcja syntaktyczna. Rachunek monoidów formalizuje ten operator, ale w mało uniwersalny sposób. Pozostałe koncepcje formalne nie zajmują się tym operatorem.