Wstęp

Języki zapytań (query languages) tworzą relatywnie nową dziedzinę informatyki, która jak dotąd jest związana z tematyką baz danych. W ostatnich latach dziedzina ta coraz intensywniej jest obecna na terenie technologii internetowych opartych na standardzie XML. Najdobitniejszym przykładem języka zapytań dla relacyjnych baz danych jest SQL. Wielu specjalistów uważa, że właśnie SQL jest źródłem ogromnego komercyjnego sukcesu całej technologii relacyjnych baz danych. Pozycja SQL jako czołowego (i praktycznie jedynego) języka dla relacyjnych baz danych została wzmocniona przez kolejne standardy przyjęte przez ANSI (American National Standard Institute) oraz ISO (International Standard Organization); noszą one oznaczenia SQL-86, SQL-89, SQL-92 (SQL2) i SQL-99 (SQL3).

SQL-99 jest przeznaczony dla obiektowo-relacyjnych baz danych, czyli w założeniu ma być kompatybilny z SQL-92, ale jego autorzy wprowadzają wiele nowych własności (w tym obiektowych), które czynią z niego pełny język programowania umożliwiający dowolne manipulacje w obiektowo-relacyjnych bazach danych. SQL (w różnorodnych mutacjach) stał się także podstawą lub uzupełnieniem wielu języków i narzędzi, np. języków czwartej generacji (4GL), narzędzi do szybkiej budowy prototypów (RAD), języków programowania wysokiego poziomu (np. Oracle PL/SQL) oraz interfejsów przeznaczonych do łączenia heterogenicznych baz danych lub zdalnego dostępu do relacyjnych baz danych, w szczególności ODBC (Open Data Base Connectivity) i JDBC (Java Data Base Connectivity).

Należy zwrócić uwagę, że SQL-89 i SQL-92 obsługują relacyjne struktury danych i nie zawierają żadnych konstrukcji umożliwiających operowanie na obiektowych strukturach danych lub na strukturach implikowanych przez standard XML (jest to niekiedy przedmiotem nieporozumień ze względu na mnóstwo rozszerzeń SQL niezgodnych ze standardami). Komercyjny sukces SQL i związane z tym nagłośnienie tematu języków zapytań jako wygodnego środka programowania aplikacji z bazą danych spowodowało ogromne zainteresowanie tego rodzaju językiem dla obiektowych baz danych. Jak dotąd, na tym polu konkurują dwa języki: SQL-99 oraz język OQL opracowany przez konsorcjum ODMG (opisany w [ODMG00]).

W ostatnich latach języki zapytań na dobre zagościły w obszarze technologii Internetu. Standard XML - nadzieja na standaryzację i odśmiecenie przeogromnych zasobów Webu - jest postrzegany nie tylko jako metaformat wymiany informacji, lecz (ostatnio przede wszystkim) jako nowy model danych. Do pewnego stopnia takie podejście jest kontrowersyjne z tego powodu, że XML dotyczy plików tekstowych o składni określonej specjalnymi konstrukcjami (tagami) i jest pomyślany głównie jako środek służący do budowy standardów wymiany danych pomiędzy użytkownikami Webu. Idea definiowania języka zapytań dla XML bierze się stąd, że plik XML jest również postrzegany jako hierarchiczna struktura danych, w której XML-owe tagi pełnią rolę nazw danych. Powstały w związku z tym repozytoria przechowujące pliki XML w strukturalnej formie, tj. w postaci obiektów o budowie hierarchicznej. Został także wypracowany standard DOM (Document Object Model), który precyzuje interfejs programistyczny (API) do takiej właśnie hierarchicznej bazy danych. Firmy programistyczne prześcigają się w oferowaniu coraz to nowych systemów baz danych, zwanych "repozytoriami XML" (XML repository) lub "natywnymi bazami danych dla XML" (native XML database). Z tego powodu praktycznie cała tematyka baz danych znajduje obecnie swoje odbicie w technologiach Internetu, włączając takie inicjatywy jak Web Services, Semantic Web, RDF (Resource Description Framework) i inne. Dodać należy, że w ramach tego internetowego nurtu dość często propozycje są mało dojrzałe w stosunku do stanu sztuki w bazach danych. Dotyczy to szczególnie języków zapytań dla XML takich jak XQL, XPath, XLink oraz XQuery (propozycji standardowego języka dla XML zgłoszonej przez W3C). Dość naiwne są specjalne "zasady" budowy języków dla XML, zaś propozycje teorii formalnych ("algebry" dla XML), które mają opisywać semantykę tej klasy języków są niespójne, niekompletne i koniunkturalne. W istocie, XML nie wnosi do tematu języków zapytań nic nowego: repozytoria XML są (ograniczonymi) hierarchicznymi bazami danych, dla których języki zapytań istniały już w latach 70-tych. Niemniej XML, RDF i inne propozycje w zakresie technologii Internetu stanowią w tej chwili jeden z głównych czynników napędzających rozwój języków zapytań.

Obecne propozycje informatyki przemysłowej w zakresie języków zapytań są kontrowersyjne. Charakterystyczny jest rozrost objętości kolejnych standardów SQL: SQL-86 - ok. 100 stron, SQL-89 - ok.120 stron, SQL-92 - ok. 600 stron i SQL-99 - ok. 2200 stron. SQL-92 nie jest zaimplementowany w wielu relacyjnych SZBD, zaś w innych implementacja nie obejmuje wszystkich przewidzianych w standardzie opcji. Żadna firma nie zaimplementowała SQL-92 w całości. Jak dotąd, nie jest znana pełna implementacja SQL-99. Niektóre firmy chwalą się, że już go zaimplementowały, ale jak się okazuje,. dotyczy to niewielkiego podzbioru tego standardu. SQL-99 jest krytykowany za eklektyzm, wszystkoizm i przypadkowość decyzji w zakresie poszczególnych konstrukcji językowych, co owocuje nieprawdopodobnym wprost rozrostem specyfikacji (wspomniane ok. 2200 stron, plus dodatki tak "drobne", jak np. 300-stronicowy słownik pojęć SQL-99 zapisany w HTML). Wobec nagromadzenia różnorodnych, często redundantnych opcji i konstrukcji, oraz wobec braku jakichkolwiek podstaw teoretycznych, optymalizacja zapytań w SQL-99 będzie najprawdopodobniej zadaniem nierealnym: zbyt obszernym, aby jakakolwiek firma była  w stanie je wykonać w zadowalającym stopniu. Standard na ten temat zresztą w ogóle się nie wypowiada, zaś brak istotnej teorii wspierającej standard pozwala wątpić w skuteczność takich działań. Implementacje i optymalizacje będą więc fragmentaryczne, partykularne dla poszczególnych firm, co podważa techniczny sens tego standardu. ODMG OQL jest językiem znacznie mniejszym, dość eleganckim, ze specyfikacją mieszczącą się na kilkudziesięciu stronach, ale pozwala wyłącznie na wyszukiwanie danych, przy czym uniwersalność środków wyszukiwawczych jest wątpliwa i nieustalona. Co za tym idzie, programowanie w OQL wymaga zanurzenia zapytań w uniwersalny język programowania. Zanurzenie to (tzw. wiązanie) zostało zdefiniowane dla języków C++, Smalltalk i Java. Niestety, zanurzenie języka zapytań w uniwersalny język programowania ma złą sławę; określa się je jako "niezgodność impedancji".

Naszym zdaniem, propozycje standardów ODMG OQL i SQL-99 są niespójne, manifestujące brak koncepcji w zakresie semantyki. Obiektowe struktury danych, które muszą być obsługiwane przez języki zapytań, cechuje spora złożoność. Precyzyjna semantyka języka zapytań wymaga precyzyjnego modelu danych, na których operują wyrażenia języka oraz precyzyjnego modelu formalnego wszystkich operatorów i pozostałych konstrukcji językowych. Autorzy obu wymienionych propozycji nie udowodnili, że mają istotny pomysł na tego rodzaju precyzyjny model. Raczej odwrotnie, konstrukcje języków roją się od większych i mniejszych błędów i niespójności (patrz np. [Alag97, Subi96b, Subi97]), włączając zasadnicze błędy koncepcji, które w zasadzie uniemożliwiają efektywną, zgodną i kompletną implementację.

Jakkolwiek jest to stan normalny w nowo powstających językach (wiele popularnych języków programowania nie posiada precyzyjnej semantyki), sytuacja jest nieco odmienna w porównaniu do klasycznych języków programowania. Języki zapytań są dramatycznie nieefektywne (praktycznie nieakceptowalne) w przypadku braku automatycznej optymalizacji. Z grubsza, optymalizacja oznacza zamianę zapytania q1, którego czas wykonania jest dramatycznie długi (np. rzędu setek lat), na semantycznie równoważne zapytanie q2 posiadające akceptowalny czas wykonania (np. rzędu kilku sekund). Powoduje to konieczność ustalenia, co to znaczy "semantycznie równoważne zapytanie". To ustalenie jest niemożliwe bez precyzyjnej formalizacji zarówno danych, na których operują zapytania, jak i semantyki wszystkich operatorów występujących w zapytaniach.

Używając terminu "precyzyjna formalizacja" niekoniecznie mamy na myśli formalizację matematyczną. Zastosowanie matematyki do formalizacji jest obciążone kilkoma wadami, w szczególności zapis matematyczny jest bardzo słabo czytelny dla inżynierów, jest trudny do odwzorowania na konkretne decyzje techniczne oraz jest zbyt "bezwładny", tj. coś, co jest zapisane przy pomocy matematyki, obciąża swobodę inżyniera w zakresie modyfikacji koncepcji w związku z pewnym nowym wymaganiem lub pomysłem. W istocie, potrzebny jest nie matematycznie precyzyjny opis języka, lecz bardzo klarowny pogląd na organizację struktury danych oraz jasne wyobrażenie odnośnie do wszelkich akcji wykonywanych przez poszczególne operatory języka zapytań we wszystkich możliwych kontekstach i interakcjach z innymi operatorami.

Uzyskanie tego rodzaju jasności i precyzji opisu obiektowych języków zapytań jest podstawowym celem podejścia stosowego. Celowo użyliśmy liczby mnogiej ("języków zapytań"), gdyż naszym zdaniem, precyzyjna formalizacja dowolnego języka zapytań (w tym SQL-99, ODMG OQL i XQuery) nie może obejść się bez elementów tego podejścia. Podejście stosowe można sformalizować w sensie matematycznym, i to pokazuje np. praca [Subi85]. Natomiast jesteśmy zdania, że jest to pozbawione sensu z tego powodu, że każda mniejsza lub większa mutacja modelu składu danych, składni lub semantyki operatorów wymagałaby w zasadzie nowego zestawu definicji formalnych (i ewentualnie wynikających z nich wniosków). Jak pokażemy w tym wykładzie, zakres tych mutacji jest nieograniczony, a każda formalizacja matematyczna musiałaby ustalić sztywno jedną z nich. Podejście stosowe jest więc rodzajem informatycznej ideologii lub abstrakcji nie narzucającej konkretnych decyzji w zakresie modelu danych oraz składni i semantyki języka. Daje ono ogromną możliwość wyborów w tych aspektach, ale stosując jego dyscyplinę można zbudować dla praktycznie dowolnych założeń odnośnie funkcji języka i obsługiwanych przez niego struktur danych bardzo mocny język zapytań i zastosować do niego pewne uniwersalne metody optymalizacyjne (takie jak przepisywanie lub indeksy). Podejście stosowe nie ogranicza się do zapytań: znosi granicę pomiędzy językiem zapytań a językiem programowania, przy czym wszystkie pojęcia związane z tymi językami uzyskują niezbędną jasność i precyzję.