6. Zapytania eliptyczne

Od samego początku dziedziny języków zapytań istniała pokusa dla ich twórców, aby skracać zapytania w różnorodny sposób w celu zminimalizowania wysiłku ponoszonego przez użytkowników przy ich formułowaniu. Przykładowo, zamiast pisać

można po prostu napisać:

organizując ewaluację zapytań w taki sposób, aby rezultat drugiego zapytania był taki sam, jak rezultat pierwszego. Takie niekompletne zapytania będziemy nazywać zapytaniami eliptycznymi (elliptic queries), zaś pominięcie pewnych elementów w zapytaniu będziemy nazywać elipsą (ellipsis). Przykładem elipsy jest zapytanie w OQL:

równoważne pełnej formie:

Innym pomysłem znanym z SQL jest użycie gwiazdki dla zastąpienia listy nazw wszystkich atrybutów przeszukiwanej relacji. Historia języków zapytań zaowocowała dziesiątkami takich pomysłów. Jakkolwiek jest to wielka pokusa dla twórców języka, aby go uatrakcyjnić poprzez skrócenie jego konstrukcji, korzyści wynikające z elips nie są jednoznaczne. Istnieje kilka zagrożeń wynikających z ich wprowadzenia. Twierdzi się, że program pisze się raz, ale czyta się 50 razy. Pełne zapytania mają walor samodokumentacji. Zapytanie eliptyczne, jakkolwiek krótsze, może nie być zrozumiałe dla przyszłych programistów, którzy będą musieli go odczytać i zrozumieć. Sumaryczna energia niezbędna do napisania i 50-krotnego odczytania zapytania (szczególnie po 10 latach od napisania) może zbilansować się zdecydowanie negatywnie. Zapytania eliptyczne mogą spowodować też znaczny wzrostu objętości i złożoności dokumentacji oraz czasu uczenia się języka.

Całkowicie bezpieczne są zapytania eliptyczne o charakterze skrótu syntaktycznego, który jednocześnie modeluje pojęciowo potrzebę, którą programista chce wyrazić. Takie elipsy dadzą się zawsze i jednoznacznie odwzorować na pełne zapytanie. Przykładowo, podane wyżej skrócone zapytanie OQL jest bez wątpienia znacznie bardziej zrozumiałe niż jego pełny odpowiednik. Tego rodzaju elipsy są możliwe dzięki temu, że schemat bazy danych oraz sam język zapytań zawierają wiele redundancji. Np. atrybut nazwisko jest przypisany tylko do obiektów Osoba, a to oznacza, że w wielu sytuacjach nazwę Osoba można pominąć. To samo dotyczy np. słów kluczowych select i from, które w istocie są syntaktycznym lukrem. Redundancja nie jest jednak sama w sobie zła, gdyż (o ile jest dobrze zastosowana) zmniejsza możliwość popełnienia błędu. Zastosowanie elips będących skrótami syntaktycznymi jest również niebezpieczne, gdyż może nie być jednoznaczne syntaktycznie. Tego błędu nie ustrzegli się twórcy języka OQL [Subi96b].

Często (najczęściej) elipsy mają charakter nowego pomysłu semantycznego, redundantnego w stosunku do już istniejących konstrukcji języka. Taki charakter ma pierwszy nasz przykład, który (w intencji) przypisuje do wyrażenia Osoba: "Kowalski" pewien szczególny sposób ewaluacji, np. polegający na tym, że atrybut nazwisko zostaje wyróżniony spośród innych atrybutów już w schemacie danych. 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 na ogół szkodliwa. W przypadku języków zapytań takie elipsy mogą być uzasadnione, szczególnie wtedy, gdy zapytanie eliptyczne ma jasną, jednoznaczną semantykę, zarówno w dziedzinie przedmiotowej, jak i w bazie danych, i/lub powoduje znaczne skrócenie czasu wykonania.

W tym wykładzie będziemy starali się unikać wszelkich elips, gdyż jej zadaniem jest objaśnienie semantyki i implementacji języka zapytań, a nie podanie gotowej składni na użytek konkretnego języka.