Obiektowe języki zapytań

1. Obiektowe języki zapytań Wykładowca: Kazimierz Subieta Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa subieta@pjwstk.edu.pl Instytut Podstaw Informatyki PAN, Warszawa subieta@ipipan.waw.pl Wykład 1 Wprowadzenie do języków zapytań (1)

2. Plan wykładów Cel tej serii wykładów: - objaśnienie formalnych aspektów obiektowych baz danych, - objaśnienie podejścia stosowego do obiektowych języków zapytań • Generalne założenia podejścia stosowego • Wprowadzenie do języków zapytań • Pojęcia obiektowości w bazach danych - przypomnienie i dyskusja • Podstawy semantyczne języków zapytań • Modele składu obiektów - M0, M1, M2 i M3 • Stos środowisk i wiązanie nazw • SBQL (Stack-Based Query Language) • Konstrukcje imperatywne w SBQL • Procedury, funkcje i metody w SBQL Dalsze wykłady: perspektywy w SBQL, optymalizacja zapytań, mocna kontrola typologiczna, aspektowe, rozproszone, federacyjne bazy danych – w przyszłym semestrze.

3. Ogólna charakterystyka języków zapytań (1) query languages • Języki zapytań są przyjaznymi dla użytkowników interfejsami do bazy danych, umożliwiającymi jej przeszukiwanie według dowolnie wybranych kryteriów i dowolnie określanego wyniku wyszukiwania. • Języki zapytań tworzą relatywnie nową dziedzinę informatyki, która (jak dotąd) jest związana z tematyką baz danych. • Językiem zapytań dla relacyjnych baz danych jest SQL. SQL jest uważany za źródło komercyjnego sukcesu całej technologii relacyjnych baz danych. • Pozycja SQL jako czołowego języka dla relacyjnych baz danych została wzmocniona przez standardy ANSI (American National Standard Institute) oraz ISO (International Standard Organization): SQL-89 oraz SQL-92. Zakończyły się także prace nad standardem SQL3, który uzyskał nowe oznaczenie SQL-99.

4. Ogólna charakterystyka języków zapytań (2) • SQL stał się podstawą lub uzupełnieniem wielu produktów, np. języków czwartej generacji (4GL), narzędzi RAD, języków programowania np. Oracle PL/SQL oraz różnych API, w szczególności ODBC i JDBC. • SQL podlegał licznym rozszerzeniom, m.in. poprzez konstrukcje zmieniające bazę danych (update, insert, delete), w kierunku języków programowania (np. Oracle PL/SQL), perspektyw (views), procedur zapamiętanych w bazie danych (stored procedures), oraz wyzwalaczy (triggers). • Najbardziej znanym obiektowym językiem zapytań jest OQL zaproponowany jako fragment standardu ODMG. • OQL był omawiany w poprzednim semestrze, gdzie przedyskutowane były jego zalety i (dość liczne) wady.

5. Teorie języków zapytań • Wraz z językami zapytań pojawiły się różnorodne teorie, takie jak algebra relacji, rachunek relacyjny i odmiany logiki matematycznej. • Teorie języków zapytań są istotne z kilku względów, w szczególności ustalają ich bazę koncepcyjną, semantyczną i dydaktyczną, oraz zasadniczo wspomagają opracowanie metod optymalizacyjnych. • Pojawiło się także wiele metod empirycznych, w szczególności dotyczących optymalizacji zapytań. • Niestety, algebra relacji i rachunek relacyjny przykrywają kilka procent konstrukcji SQL i nie są z nim do końca spójne • Metody optymalizacyjne są zbytnio przywiązane do relacyjnego modelu danych (którego czas minął) i do fizycznych własności systemów, mają ograniczony zakres stosowalności, oraz mają luki i niejasności koncepcyjne.

6. Chaos... • Pojawienie się obiektowych i obiektowo-relacyjnych (object-relational) baz danych stworzyło w tej dziedzinie nową jakość. • Dotyczy to także technologii internetowych opartych o standard XML, który jest ostatnio postrzegany jako nowy model bazy danych. • Nowe modele danych, standardy, rozwiązania praktyczne, metody i teorie spowodowały stan, który można określić jako totalny chaos: • brak spójnych, jednorodnych podstaw teoretycznych, • przypadkowość rozwiązań praktycznych. • Dominują w tym względzie liczne rozszerzania operatorów obecnych w SQL oraz rozszerzania i modyfikacje teorii takich jak algebra relacji, rachunek relacyjny i innych. • Świadectwem chaosu są wadliwe standardy SQL-99 i ODMG OQL. • Świadectwem chaosu jest także stan języków zapytań dla XML, wśród nich XQL, XPath, XLink, XPointer, XQuery i inne. • Opakowanie składni w XML czyni je bardzo nieczytelnymi i jest bez sensu. Niezrozumiałe jest dążenie do specjalizowania tych języków (np. XPath, XLink, XPointer).

7. Czy przyszłością języków zapytań jest SQL, OQL lub XQuery? • Propozycje są kontrowersyjne. • SQL-99 jest krytykowany za eklektyzm, wszystkoizm i przypadkowość decyzji w zakresie konstrukcji językowych, co owocuje monstrualną specyfikacją (ponad 1500 stron, plus dodatki, razem ponad 5000 stron). • Jest wątpliwe, aby ktokolwiek zaimplementował ten język w całości. • OQL jest językiem znacznie mniejszym, ze specyfikacją mieszczącą się na kilkudziesięciu stronach, ale pozwala wyłącznie na wyszukiwanie danych. Brakuje konstrukcji imperatywnych, perspektyw, procedur, itd. • Co za tym idzie, programowanie w OQL wymaga zanurzenia zapytań w uniwersalny język programowania: C++, Smalltalk i Java. • Zanurzenie języka zapytań w uniwersalny język programowania ma złą sławę określaną jako „niezgodność impedancji”. • XQuery wzoruje się na OQL, ale wprowadza w sposób nieco chaotyczny dalsze cechy, np. funkcje definiowane przez użytkowników. • Wszystkie te propozycje cechuje niespójność (i w gruncie rzeczy, brak istotnej koncepcji) w zakresie semantyki. • Metody optymalizacyjne dla tych języków są w stanie embrionalnym.

8. Czy warto zabiegać o precyzyjną semantykę? • Brak precyzyjnej semantyki jest powszechny dla nowo powstających języków programowania. • W przypadku języków zapytań sytuacja jest odmienna w porównaniu do klasycznych języków programowania. • Języki zapytań są dramatycznie nieefektywne (praktycznie nieakceptowalne) w przypadku braku automatycznej optymalizacji. • Optymalizacja oznacza zamianę zapytania q1, którego czas wykonania jest dramatycznie długi (np. 500 lat), na semantycznie równoważne zapytanie q2 posiadające akceptowalny czas wykonania (np. 5 sekund). • Powoduje to konieczność ustalenia, co to znaczy „semantycznie równoważne zapytanie”. Jest to niemożliwe bez precyzyjnej formalizacji zarówno danych, na których operują zapytania, jak i semantyki operatorów występujących w zapytaniach. • Uzyskanie pełnej jasności i precyzji opisu semantyki obiektowych języków zapytań jest celem tego wykładu. • Wykład będzie opierać się o podejście stosowe do obiektowych języków zapytań.

9. Generalne założenia podejścia stosowego stack-based approach, SBA • Podejście stosowe zakłada, że języki zapytań są szczególnym przypadkiem języków programowania. • Stąd teorie języków programowania są bardziej adekwatne niż podejścia takie jak algebra relacyjna, rachunek relacyjny lub logika matematyczna. • W podejściu stosowym kluczową rolę odgrywa stos środowisk (environment stack), który jest podstawowym mechanizmem praktycznie wszystkich popularnych języków programowania. • Jego rolą jest określenie zakresów nazw (scoping), wiązanie nazw (binding) oraz wprowadzenie dyscypliny w zakresie alokowania dynamicznych bytów programistycznych, w szczególności lokalnych danych (obiektów) i parametrów procedur.

10. Zalety podejścia stosowego • Oparcie semantyki języków zapytań na mechanizmie stosu środowisk umożliwia precyzyjne wyjaśnienie ich semantyki. • Inne podejścia do semantyki obiektowych języków zapytań są wadliwe: • Podstawy teoretyczne (np. algebra relacji, algebry obiektowe) nie obejmują wszystkich konstrukcji spotykanych w językach zapytań. • Posiadają zasadnicze wady koncepcji, są semantycznie nieprecyzyjne. • Nie dają bezpośredniej możliwości rozszerzeń: uwzględnienia pojęć obiektowości (klasy, dziedziczenie, hermetyzacja), konstrukcji imperatywnych (update, insert, delete), abstrakcji BD (perspektywy, procedury BD, funkcje, trygery, komunikowanie parametrów). • SBA pozwala na włączenie do konstruowanego języka wszystkich pojęć obiektowości oraz dowolnych konstrukcji i abstrakcji imperatywnych. • Podejście jest bezpośrednio implementowalne. Przedstawiony będzie SBQL (Stack-Based Query Language) oparty na SBA i zrealizowany w prototypowym systemie Loqis oraz w dalszych implementacjach. • Podejście jest optymalizowalne przy pomocy generalnych metod.

11. Podejście stosowe jako efektywna teoria • Podejście stosowe jest konkurencją dla teorii znanych z modelu relacyjnego, takie jak algebra relacyjna, rachunek relacyjny i logika matematyczna. • Podejście stosowe jest samo-wystarczalne – w zakresie dowolnego tematu dotyczącego obiektowych baz danych, włączając optymalizację zapytań nie potrzebuje posiłkować się jakimikolwiek innymi teoriami, np. obiektowymi algebrami. • Podejście stosowe eksponuje braki i wady obecnych teorii w zakresie baz danych, pokazując ich ograniczenia i nieadekwatność do problemu.

12. Co daje efektywna teoria? • Brak spójnej, całościowej i uniwersalnej teorii języków zapytań podczas tworzenia standardów ODMG i SQL-99 jest podstawową przyczyną ich wad. • W efekcie chaotycznych decyzji nie opierających się o jakąkolwiek spójną teorię, standardy te są intelektualnymi i technicznymi bublami nie nadającymi się do dydaktyki i do efektywnej całościowej implementacji. • Dwóch zdolnych studentów znających podejście stosowe potrafi zaprojektować i zaimplementować w ciągu roku lepszy i mocniejszy język zapytań niż duże konsorcja specjalistów z renomowanych firm zachodnich. Ten eksperyment został już 5-krotnie powtórzony w PJWSTK.

13. Konstrukcje bazujące na zapytaniach • Zapytania są także podstawą abstrakcji programistycznych takich jak procedury, metody, funkcje (procedury funkcyjne) i perspektywy. • Znane z SQL perspektywy (views) są procedurami funkcyjnymi, których ciało składa się z pojedynczego zapytania, w związku z czym ich uniwersalność jest ograniczona. • Podejście stosowe nie zmusza do tego rodzaju ograniczeń: dowolne procedury i perspektywy mogą mieć pełną moc algorytmiczną. • Dzięki mechanizmowi stosu środowiskowego wszystkie procedury, metody i funkcje/perspektywy mogą być rekurencyjne oraz mogą mieć parametry będące zapytaniami. • W podejściu stosowym można bez trudu wyjaśnić mechanizmy komunikacji parametrów, znane jako call-by-value, call-by-reference i inne, w odniesieniu do parametrów będących zapytaniami.

14. Perspektywy i ich problemy • Perspektywy są definiowane poprzez język zapytań i mogą być używane (wywoływane) w zapytaniach. Umożliwiają one przystosowanie schematu bazy danych do konkretnych wymagań użytkownika, ograniczają dostęp do danych oraz mogą stanowić podstawę integracji rozproszonych, heterogenicznych baz danych. Problemy związane z perspektywami: • Koncepcyjna uniwersalność: język perspektyw powinien dawać możliwość dowolnego odwzorowania zapamiętanych danych w dane wirtualne. • Aktualizacja wirtualnych danych widzianych poprzez perspektywę. Istotne jest zapewnienie przezroczystości aktualizacji wirtualnych danych polegającej na tym, że z punktu widzenia użytkownika lub programisty nie występują jakiekolwiek różnice w operowaniu na zapamiętanych i wirtualnych danych. Problem aktualizacji danych wirtualnych jest znany od 1974 roku, ale dotychczas nie doczekał się uniwersalnego rozwiązania. • Optymalizacja: efektywna realizacja zapytań odwołujących się do perspektyw. Bezpośrednia implementacja, poprzez zmaterializowanie wyniku perspektywy dla konkretnego zapytania, prowadzi do nieakceptowalnych czasów wykonania, zatem konieczne są mocne metody optymalizacyjne.

15. Optymalizacja zapytań • Bezpośrednia implementacja semantyki, w sytuacji gdy bazy danych zawierają miliony danych, prowadzi do nieakceptowalnego czasu odpowiedzi na zapytanie. • Radykalne skrócenie tego czasu, zwane optymalizacją, staje się więc koniecznością, zaś język zapytań, który nie jest wspomagany przez optymalizację, nie ma szans na akceptację ze strony klientów baz danych. • Metody optymalizacyjne znane z systemów relacyjnych z trudem przenosi się na modele obiektowe, ze względu na przywiązanie tych metod do cech modelu relacyjnego oraz do fizycznej reprezentacji danych. • Optymalizacja zapytań jest katalizatorem rozwoju teorii języków zapytań. Optymalizacja najczęściej polega na tym, że zapytanie q1 jest automatycznie zamieniane na semantycznie równoważne zapytanie q2, które rokuje znacznie lepszy czas wykonania. • Teoria jest niezbędna do tego, aby odpowiedzieć na pytanie: co to znaczy „semantycznie równoważne”? • Odpowiedź na to pytanie wymaga założenia, że każdy najdrobniejszy problem semantyczny jest ogromnym problemem.

16. SBQL • Podczas wykładu zostaną wyjaśnione założenia i semantyka języka zapytań SBQL (Stack Based Query Language) opartego na podejściu stosowym. • SBQL jest pewną idealizacją opartą na abstrakcyjnej składni, pokazującą istotę semantyki operatorów wprowadzonych w większości języków zapytań. • SBQL pełni on tę samą rolę, którą w relacyjnych językach zapytań pełni algebra relacji i rachunek relacyjny. • Zasadniczą nowością wprowadzoną w SBQL są operatory nie-algebraiczne, takie jak operatory selekcji, projekcji/nawigacji, złączenia, kwantyfikatory, operator tranzytywnego domknięcia i operator porządkowania. • Semantyka tych operatorów nie może być wyrażona w terminach algebry podobnej do algebry relacji. Jak się okazało, ich semantykę można w prosty sposób wyrazić poprzez operacje na stosie środowiskowym, przy czym pewnym zaskoczeniem jest to, że semantyka tych wydawałoby się bardzo różnych operatorów jest oparta o ten sam prosty mechanizm.

17. Dlaczego operatory są nie-algebraiczne? • Twórcy i kontynuatorzy koncepcji modelu relacyjnego przez lata przyzwyczaili nas, że operatory selekcji, projekcji i złączenia są zwyczajnymi „operatorami algebraicznymi” w algebrze relacji. • Nie potrzeba wielkiej wnikliwości matematycznej, aby pokazać, że ich „algebraizacja” odbyła się kosztem niezbyt rzetelnej sztuczki formalnej, w której część semantyki została przesunięta do nieformalnego meta-języka tej algebry. • Dotyczy to nazw atrybutów, operacji, funkcji i innych elementów występujących w indeksach operatorów algebry relacji. • Np. selekcja nie jest pojedynczym operatorem: jest to nieskończona rodzina operatorów, gdzie konkretny egzemplarz jest wyznaczony poprzez indeks tego operatora należący do meta-języka tej algebry. • Indeksy nie należą do formalnej semantyki, są po prostu komentarzem. Zar>1000( Prac )

18. Pojęcia formalne i nieformalne • W ten sposób uniwersum semantycznych rozważań zostało podzielone na dwa światy: • świat formalny pojęć „pierwszej kategorii”, włączający nazwy relacji i operatory takie jak selekcja, projekcja i złączenie, • świat nieformalny pojęć „drugiej kategorii” występujący w nieformalnych komentarzach, w tym w indeksach. • Ten podział semantyki jest frustrujący, nieakceptowalny i niepotrzebny. • Matematyka jest neutralna w stosunku do ideologicznych założeń i radzi sobie nie tylko z relacjami i z algebrą relacji, lecz również z teoriami o innych założeniach, w których opisana anomalia nie występuje. • Podejście stosowe nie korzysta więc z teorii wypracowanych przez społeczność baz danych. • Wprowadza operatory nie-algebraiczne w taki sposób, aby wyeliminować podział na w/w dwa światy. • Podejście stosowe znacznie precyzyjniej formułuje te właśnie pojęcia, które dotąd są przypisywane algebrze relacji, rachunkowi relacyjnemu lub logice matematycznej.

19. Zapytania = wyrażenia • W naszym podejściu zapytania będą pełnić rolę wyrażeń znanych z języków programowania. • Przyjęta przez nas zasada ortogonalnej trwałości nie różnicuje sposobów dostępu do trwałych i nietrwałych danych. • Wobec tego nasze zapytania będą również stosowane do nietrwałych danych. • Inaczej mówiąc przyjęliśmy, że w naszym hipotetycznym języku programowania nie będzie innych wyrażeń niż zapytania. • Zapytaniami będą więc także klasyczne wyrażenia takie jak 2+2, sin(x), A[i+1], itd. • To założenie jest pewną rewolucją w odniesieniu do języków zapytań. • Tradycyjnie, np. w języku SQL zapytania (zagnieżdżone w język programowania) mogły odwoływać się do zmiennych języka programowania poprzez specjalną składnię.

20. Konstrukcje i abstrakcje programistyczne • Podejście stosowe nie stwarza jakiejkolwiek granicy pomiędzy językiem zapytań i językiem programowania. • Jeżeli zaimplementowane są mechanizmy języka zapytań, wówczas przystosowanie ich do konstrukcji imperatywnych i abstrakcji takich jak moduły, klasy, procedury, funkcje, metody i perspektywy jest zadaniem dość oczywistym. • Podejście stosowe prowadzi również do prostych mechanizmów przekazywania parametrów do procedur (funkcji, metod), w szczególności mechanizmów znanych jako wołanie przez wartość (call-by-value) i wołanie przez referencję (call-by-reference). • Z natury rzeczy, definiowane w podejściu stosowym mechanizmy umożliwiają dowolne wołania rekurencyjne procedur (funkcji, metod, perspektyw).

21. Kontrola typologiczna • Przy rozpatrywaniu języków zapytań, szczególnie języków zintegrowanych z językami programowania, nie można pominąć kwestii mocnej kontroli typologicznej. • Mechanizm mocnej kontroli typów chroni programistów przed ich własnymi błędami i w związku z tym jest kluczowym czynnikiem podwyższenia niezawodności oprogramowania. • Istnieją szacunki pokazujące, że system kontroli typologicznej jest w stanie wykryć 80% błędów semantycznych i koncepcyjnych. • Bezpieczeństwo typologiczne (typing safety) jako podstawowa zasada języków programowania. • System typów ma również ogromne znaczenie dla modelowania pojęciowego, gdyż odpowiednio dobrane nazwy typów pełnia rolę semantycznych kwalifikatorów bytów programistycznych w dziedzinie przedmiotowej. • Języki bez typów i bez mocnej kontroli typów są uważane za niebezpieczne, prowadzące do niskiej jakości oprogramowania.

22. Co to są "języki zapytań"? Istnieje na ten temat wiele poglądów, np.: • Proste, przyjacielskie i naturalne interfejsy dla powszechnego użytkownika do interakcyjnego formułowania zleceń wyszukiwania w bazie danych lub jej aktualizacji przez mało doświadczonego użytkownika. W tej roli znacznie lepsze od SQL są interfejsy graficzne oparte o okienka, menu, formularze, tabele, przeglądanie, itp. • Syntaktyczne warianty języków pewnych sławnych matematycznych teorii, np. logiki. Ten punkt widzenia był lansowany przez teoretyków baz danych. Obecne języki zapytań zaprzeczają tego rodzaju poglądom. • Pod-języki bardzo wysokiego poziomu (API) zanurzane w typowe języki programowania do wyszukiwania i aktualizacji bazy danych. W tej roli najczęściej występuje SQL. Liczne wady tego podejścia. • Wyrażenia programistyczne bardzo wysokiego poziomu zintegrowane z językiem programowania. Tworzą kompletny interfejs do programowania aplikacji. Przykładem jest PL/SQL systemu Oracle.

23. Języki zapytań jako wyrażenia programistyczne • Ostatni punkt widzenia zakłada nowy rodzaj języka programowania, w którym występują specyficzne wyrażenia (podobne do klasycznych wyrażeń języka oprogramowania) zwane „zapytaniami”. • Istotą tych nowych wyrażeń jest obsługa kolekcji. • W tej roli języki zapytań są wyższym szczeblem abstrakcji nad konstrukcjami organizującymi pętle (while, repeat, goto, for, loop, itp.), iteratorami, kursorami i innymi tego rodzaju udogodnieniami. • Zapytania koncepcyjnie „hermetyzują” pętle iteracyjne w języku programowania przy pomocy operatorów takich jak selekcja (where), projekcja, złączenie, unia, kwantyfikatory, grupowanie, sortowanie, itp. • Słowo „koncepcyjnie” jest tu istotne, gdyż chodzi o taką hermetyzację, która jest naturalna, zrozumiała i czytelna dla programisty; wspomagająca procesy modelowania pojęciowego przy tworzeniu aplikacji. • W tej koncepcji języki zapytań są tworami całkowicie ortogonalnymi w stosunku do cechy trwałości danych (czyli bazy danych).

24. Znaczenie języków zapytań • Obniżenie poziomu profesjonalizmu niezbędnego do programowania aplikacji baz danych. W tradycyjnych językach programowania aplikacje te wymagają profesjonalnych, wysoko opłacanych programistów. • Podwyższenie wydajności programistów poprzez dostarczenie do ich dyspozycji pojęciowych, makroskopowych operacji, pozwalających zapisać złożone przetwarzanie w zwartej, czytelnej i zrozumiałej formie. • Jedno zdanie w SQL może zastąpić kilka stron programu napisanego w językach takich jak Cobol, C lub Pascal. • Ma to skutki dla tempa tworzenia oprogramowania, jego kosztu, pielęgnacyjności i modyfikowalności. • Podwyższenie niezawodności produktów programistycznych poprzez zwartość zapisu programu i konceptualizację myślenia programisty. • Zwolnienie projektanta i programisty z myślenia o mniej istotnych sprawach implementacyjnych, umożliwienie skupienia się na tym co ma być zrobione, a nie jak; myślenie w kategoriach problemu i dziedziny zastosowań, a nie w w kategoriach detali i sztuczek implementacyjnych.

25. Zastosowania języków zapytań (1) • Narzędzie dla powszechnego użytkownika umożliwiające interakcyjne zapytania i aktualizacje (tzw. ad hoc), z generacją odpowiedzi lub raportów w pewnych z góry zadanych formatach. • Konstrukcje języka programowania umożliwiające programowanie na bardzo wysokim poziomie abstrakcji i konceptualizację programów. • Definiowanie ograniczeń integralnościowych (integrity constraints), inaczej więzów integralności, zapobiegających niedopuszczalnym operacjom na bazie danych lub wykrywających błędy w danych. • Definiowanie podschematów, ograniczeń dostępu i innych środków autoryzacji lub bezpieczeństwa danych. • Definiowanie wirtualnych perspektyw (views), zmaterializowanych perspektyw (materialized views), danych pochodnych (derived), replikacji danych, procedur zapamiętanych w bazie danych (stored procedures, database procedures), i innych abstrakcji lub udogodnień w danych.

26. Zastosowania języków zapytań (2) • Składowe konstrukcji językowych skryptów (scripts) w językach czwartej generacji (4GL) i narzędziach do prototypowania (RAD). • Definiowanie aktywnych reguł, dedukcyjnych reguł, aktywnych agentów i innych „inteligentnych" elementów w bazie danych. • Określanie danych do transmisji w rozproszonych bazach danych; umożliwienie współpracy pomiędzy heterogenicznymi i/lub odległymi bazami danych (np. interfejsy w stylu ODBC lub JDBC). • Określanie danych do transmisji pomiędzy różnymi rodzajami pamięci, np. pomiędzy pamięcią optyczną typu jukebox a pamięcią dyskową. • Narzędzia do wyszukiwania informacji w danych pół-strukturalnych (semi-structured), np. w plikach XML lub RDF; definiowanie perspektyw nad danymi pół-strukturalnymi. • Narzędzia do eksploracja danych (data mining), hurtowni danych i analitycznego przetwarzania (OLAP).

27. Własności języków zapytań (1) • Wysoki poziom konceptualizacji i abstrakcji; niezależność danych (data independence) wyrażająca się w braku odwołań do elementów fizycznej organizacji danych (takich jak np. indeksy). Użytkownik formułuje zapytanie znając wyłącznie logiczny schemat bazy danych. • Nieproceduralność lub deklaracyjność, wyrażająca się w zorientowaniu języka na formułowanie bezpośrednio celu wyszukiwania, a nie środków prowadzących do tego celu. • Makroskopowość, czyli jednoczesne działanie (z punktu widzenia użytkownika) na wielu elementach kolekcji o nieznanych rozmiarach. • Naturalność, czyli wspomaganie naturalnych schematów myślenia użytkownika, wspomaganie modelowania pojęciowego, łatwość uczenia się i użycia.

28. Własności języków zapytań (2) • Efektywność, czyli akceptowalne czasy wykonania zapytań. Oznacza to konieczność stosowania automatycznych metod optymalizacyjnych. • To zaś oznacza konieczność określenia jednorodnej koncepcji i zdefiniowania precyzyjnej semantyki języka, bez pomijania jakichkolwiek detali. • Dla złożonego problemu automatyczna optymalizacja zapytań jest bardziej skuteczna od manualnego zakodowania tego samego zadania w języku niskiego poziomu, np. w C. • Uniwersalność, czyli zdolność języka zapytań do definiowania dowolnych operacji wyszukiwania i kojarzenia danych. • Ta własność jest słabą stroną SQL. • Kryteria dla określenia stopnia uniwersalności języków zapytań są ułomne. Tzw. „relacyjna kompletność” (relational completeness) jest przypadkowym, nie umotywowanym punktem na skali uniwersalności. Tzw. "kompletność Turinga" (Turing completeness) jest oparta na pseudo-argumentach. • Uniwersalność jest kategorią pragmatyczną, a nie matematyczną.

29. Własności języków zapytań (3) • Niezależność od dziedziny zastosowań, czyli brak przypisania do jednej dziedziny aplikacyjnej, umożliwienie realizacji wszystkich potencjalnych zastosowań danego systemu zarządzania bazą danych. • Wykonywanie zapytań w trybie interpretacyjnym, późne (dynamiczne) wiązanie, brak fazy kompilacji i konsolidacji zapytań z całością aplikacji. Umożliwia to zapytania ad hoc, dynamiczne tworzenie i usuwanie perspektyw, zapamiętywanie procedur i reguł w bazie danych, dynamiczne tworzenie i usuwanie indeksów, itd.