Obiektowe jezyki zapytan

1
Obiektowe jezyki zapytan
Wykladowca Kazimierz Subieta Polsko-Japonska
Wyzsza Szkola Technik Komputerowych,
Warszawa subieta_at_pjwstk.edu.pl Instytut Podstaw
Informatyki PAN, Warszawa subieta_at_ipipan.waw.pl
Wyklad 1 Wprowadzenie do jezyków zapytan (1)
2
Plan wykladów
Cel tej serii wykladów - objasnienie formalnych
aspektów obiektowych baz danych, - objasnienie
podejscia stosowego do obiektowych jezyków
zapytan

• Generalne zalozenia podejscia stosowego
• Wprowadzenie do jezyków zapytan
• Pojecia obiektowosci w bazach danych -
  przypomnienie i dyskusja
• Podstawy semantyczne jezyków zapytan
• Modele skladu obiektów - M0, M1, M2 i M3
• Stos srodowisk i wiazanie nazw
• SBQL (Stack-Based Query Language)
• Konstrukcje imperatywne w SBQL
• Procedury, funkcje i metody w SBQL

Dalsze wyklady perspektywy w SBQL, optymalizacja
zapytan, mocna kontrola typologiczna, aspektowe,
rozproszone, federacyjne bazy danych w
przyszlym semestrze.
3
Ogólna charakterystyka jezyków zapytan (1)
query languages

• Jezyki zapytan sa przyjaznymi dla uzytkowników
  interfejsami do bazy danych, umozliwiajacymi jej
  przeszukiwanie wedlug dowolnie wybranych
  kryteriów i dowolnie okreslanego wyniku
  wyszukiwania.
• Jezyki zapytan tworza relatywnie nowa dziedzine
  informatyki, która (jak dotad) jest zwiazana z
  tematyka baz danych.
• Jezykiem zapytan dla relacyjnych baz danych jest
  SQL. SQL jest uwazany za zródlo komercyjnego
  sukcesu calej technologii relacyjnych baz danych.
  
• Pozycja SQL jako czolowego jezyka dla relacyjnych
  baz danych zostala wzmocniona przez standardy
  ANSI (American National Standard Institute) oraz
  ISO (International Standard Organization) SQL-89
  oraz SQL-92. Zakonczyly sie takze prace nad
  standardem SQL3, który uzyskal nowe oznaczenie
  SQL-99.

4
Ogólna charakterystyka jezyków zapytan (2)

• SQL stal sie podstawa lub uzupelnieniem wielu
  produktów, np. jezyków czwartej generacji (4GL),
  narzedzi RAD, jezyków programowania np. Oracle
  PL/SQL oraz róznych API, w szczególnosci ODBC i
  JDBC.
• SQL podlegal licznym rozszerzeniom, m.in. poprzez
  konstrukcje zmieniajace baze danych (update,
  insert, delete), w kierunku jezyków programowania
  (np. Oracle PL/SQL), perspektyw (views), procedur
  zapamietanych w bazie danych (stored procedures),
  oraz wyzwalaczy (triggers).
• Najbardziej znanym obiektowym jezykiem zapytan
  jest OQL zaproponowany jako fragment standardu
  ODMG.
• OQL byl omawiany w poprzednim semestrze, gdzie
  przedyskutowane byly jego zalety i (dosc liczne)
  wady.

5
Teorie jezyków zapytan

• Wraz z jezykami zapytan pojawily sie róznorodne
  teorie, takie jak algebra relacji, rachunek
  relacyjny i odmiany logiki matematycznej.
• Teorie jezyków zapytan sa istotne z kilku
  wzgledów, w szczególnosci ustalaja ich baze
  koncepcyjna, semantyczna i dydaktyczna, oraz
  zasadniczo wspomagaja opracowanie metod
  optymalizacyjnych.
• Pojawilo sie takze wiele metod empirycznych, w
  szczególnosci dotyczacych optymalizacji zapytan.
• Niestety, algebra relacji i rachunek relacyjny
  przykrywaja kilka procent konstrukcji SQL i nie
  sa z nim do konca spójne
• Metody optymalizacyjne sa zbytnio przywiazane do
  relacyjnego modelu danych (którego czas minal) i
  do fizycznych wlasnosci systemów, maja
  ograniczony zakres stosowalnosci, oraz maja luki
  i niejasnosci koncepcyjne.

6
Chaos...

• Pojawienie sie obiektowych i obiektowo-relacyjnyc
  h (object-relational) baz danych stworzylo w tej
  dziedzinie nowa jakosc.
• Dotyczy to takze technologii internetowych
  opartych o standard XML, który jest ostatnio
  postrzegany jako nowy model bazy danych.
• Nowe modele danych, standardy, rozwiazania
  praktyczne, metody i teorie spowodowaly stan,
  który mozna okreslic jako totalny chaos
• brak spójnych, jednorodnych podstaw
  teoretycznych,
• przypadkowosc rozwiazan praktycznych.
• Dominuja w tym wzgledzie liczne rozszerzania
  operatorów obecnych w SQL oraz rozszerzania i
  modyfikacje teorii takich jak algebra relacji,
  rachunek relacyjny i innych.
• Swiadectwem chaosu sa wadliwe standardy SQL-99 i
  ODMG OQL.
• Swiadectwem chaosu jest takze stan jezyków
  zapytan dla XML, wsród nich XQL, XPath, XLink,
  XPointer, XQuery i inne.
• Opakowanie skladni w XML czyni je bardzo
  nieczytelnymi i jest bez sensu. Niezrozumiale
  jest dazenie do specjalizowania tych jezyków (np.
  XPath, XLink, XPointer).

7
Czy przyszloscia jezyków zapytan jest SQL, OQL
lub XQuery?

• Propozycje sa kontrowersyjne.
• SQL-99 jest krytykowany za eklektyzm, wszystkoizm
  i przypadkowosc decyzji w zakresie konstrukcji
  jezykowych, co owocuje monstrualna specyfikacja
  (ponad 1500 stron, plus dodatki, razem ponad 5000
  stron).
• Jest watpliwe, aby ktokolwiek zaimplementowal ten
  jezyk w calosci.
• OQL jest jezykiem znacznie mniejszym, ze
  specyfikacja mieszczaca sie na kilkudziesieciu
  stronach, ale pozwala wylacznie na wyszukiwanie
  danych. Brakuje konstrukcji imperatywnych,
  perspektyw, procedur, itd.
• Co za tym idzie, programowanie w OQL wymaga
  zanurzenia zapytan w uniwersalny jezyk
  programowania C, Smalltalk i Java.
• Zanurzenie jezyka zapytan w uniwersalny jezyk
  programowania ma zla slawe okreslana jako
  niezgodnosc impedancji.
• XQuery wzoruje sie na OQL, ale wprowadza w sposób
  nieco chaotyczny dalsze cechy, np. funkcje
  definiowane przez uzytkowników.
• Wszystkie te propozycje cechuje niespójnosc (i w
  gruncie rzeczy, brak istotnej koncepcji) w
  zakresie semantyki.
• Metody optymalizacyjne dla tych jezyków sa w
  stanie embrionalnym.

8
Czy warto zabiegac o precyzyjna semantyke?

• Brak precyzyjnej semantyki jest powszechny dla
  nowo powstajacych jezyków programowania.
• W przypadku jezyków zapytan sytuacja jest
  odmienna w porównaniu do klasycznych jezyków
  programowania.
• Jezyki zapytan sa dramatycznie nieefektywne
  (praktycznie nieakceptowalne) w przypadku braku
  automatycznej optymalizacji.
• Optymalizacja oznacza zamiane zapytania q1,
  którego czas wykonania jest dramatycznie dlugi
  (np. 500 lat), na semantycznie równowazne
  zapytanie q2 posiadajace akceptowalny czas
  wykonania (np. 5 sekund).
• Powoduje to koniecznosc ustalenia, co to znaczy
  semantycznie równowazne zapytanie. Jest to
  niemozliwe bez precyzyjnej formalizacji zarówno
  danych, na których operuja zapytania, jak i
  semantyki operatorów wystepujacych w zapytaniach.
  
• Uzyskanie pelnej jasnosci i precyzji opisu
  semantyki obiektowych jezyków zapytan jest celem
  tego wykladu.
• Wyklad bedzie opierac sie o podejscie stosowe do
  obiektowych jezyków zapytan.

9
Generalne zalozenia podejscia stosowego
stack-based approach, SBA

• Podejscie stosowe zaklada, ze jezyki zapytan sa
  szczególnym przypadkiem jezyków programowania.
• Stad teorie jezyków programowania sa bardziej
  adekwatne niz podejscia takie jak algebra
  relacyjna, rachunek relacyjny lub logika
  matematyczna.
• W podejsciu stosowym kluczowa role odgrywa stos
  srodowisk (environment stack), który jest
  podstawowym mechanizmem praktycznie wszystkich
  popularnych jezyków programowania.
• Jego rola jest okreslenie zakresów nazw
  (scoping), wiazanie nazw (binding) oraz
  wprowadzenie dyscypliny w zakresie alokowania
  dynamicznych bytów programistycznych, w
  szczególnosci lokalnych danych (obiektów) i
  parametrów procedur.

10
Zalety podejscia stosowego

• Oparcie semantyki jezyków zapytan na mechanizmie
  stosu srodowisk umozliwia precyzyjne wyjasnienie
  ich semantyki.
• Inne podejscia do semantyki obiektowych jezyków
  zapytan sa wadliwe
• Podstawy teoretyczne (np. algebra relacji,
  algebry obiektowe) nie obejmuja wszystkich
  konstrukcji spotykanych w jezykach zapytan.
• Posiadaja zasadnicze wady koncepcji, sa
  semantycznie nieprecyzyjne.
• Nie daja bezposredniej mozliwosci rozszerzen
  uwzglednienia pojec obiektowosci (klasy,
  dziedziczenie, hermetyzacja), konstrukcji
  imperatywnych (update, insert, delete),
  abstrakcji BD (perspektywy, procedury BD,
  funkcje, trygery, komunikowanie parametrów).
• SBA pozwala na wlaczenie do konstruowanego jezyka
  wszystkich pojec obiektowosci oraz dowolnych
  konstrukcji i abstrakcji imperatywnych.
• Podejscie jest bezposrednio implementowalne.
  Przedstawiony bedzie SBQL (Stack-Based Query
  Language) oparty na SBA i zrealizowany w
  prototypowym systemie Loqis oraz w dalszych
  implementacjach.
• Podejscie jest optymalizowalne przy pomocy
  generalnych metod.

11
Podejscie stosowe jako efektywna teoria

• Podejscie stosowe jest konkurencja dla teorii
  znanych z modelu relacyjnego, takie jak algebra
  relacyjna, rachunek relacyjny i logika
  matematyczna.
• Podejscie stosowe jest samo-wystarczalne w
  zakresie dowolnego tematu dotyczacego obiektowych
  baz danych, wlaczajac optymalizacje zapytan nie
  potrzebuje posilkowac sie jakimikolwiek innymi
  teoriami, np. obiektowymi algebrami.
• Podejscie stosowe eksponuje braki i wady obecnych
  teorii w zakresie baz danych, pokazujac ich
  ograniczenia i nieadekwatnosc do problemu.

12
Co daje efektywna teoria?

• Brak spójnej, calosciowej i uniwersalnej teorii
  jezyków zapytan podczas tworzenia standardów ODMG
  i SQL-99 jest podstawowa przyczyna ich wad.
• W efekcie chaotycznych decyzji nie opierajacych
  sie o jakakolwiek spójna teorie, standardy te sa
  intelektualnymi i technicznymi bublami nie
  nadajacymi sie do dydaktyki i do efektywnej
  calosciowej implementacji.
• Dwóch zdolnych studentów znajacych podejscie
  stosowe potrafi zaprojektowac i zaimplementowac w
  ciagu roku lepszy i mocniejszy jezyk zapytan niz
  duze konsorcja specjalistów z renomowanych firm
  zachodnich. Ten eksperyment zostal juz 5-krotnie
  powtórzony w PJWSTK.

13
Konstrukcje bazujace na zapytaniach

• Zapytania sa takze podstawa abstrakcji
  programistycznych takich jak procedury, metody,
  funkcje (procedury funkcyjne) i perspektywy.
• Znane z SQL perspektywy (views) sa procedurami
  funkcyjnymi, których cialo sklada sie z
  pojedynczego zapytania, w zwiazku z czym ich
  uniwersalnosc jest ograniczona.
• Podejscie stosowe nie zmusza do tego rodzaju
  ograniczen dowolne procedury i perspektywy moga
  miec pelna moc algorytmiczna.
• Dzieki mechanizmowi stosu srodowiskowego
  wszystkie procedury, metody i funkcje/perspektywy
  moga byc rekurencyjne oraz moga miec parametry
  bedace zapytaniami.
• W podejsciu stosowym mozna bez trudu wyjasnic
  mechanizmy komunikacji parametrów, znane jako
  call-by-value, call-by-reference i inne, w
  odniesieniu do parametrów bedacych zapytaniami.

14
Perspektywy i ich problemy

• Perspektywy sa definiowane poprzez jezyk zapytan
  i moga byc uzywane (wywolywane) w zapytaniach.
  Umozliwiaja one przystosowanie schematu bazy
  danych do konkretnych wymagan uzytkownika,
  ograniczaja dostep do danych oraz moga stanowic
  podstawe integracji rozproszonych,
  heterogenicznych baz danych. Problemy zwiazane z
  perspektywami
• Koncepcyjna uniwersalnosc jezyk perspektyw
  powinien dawac mozliwosc dowolnego odwzorowania
  zapamietanych danych w dane wirtualne.
• Aktualizacja wirtualnych danych widzianych
  poprzez perspektywe. Istotne jest zapewnienie
  przezroczystosci aktualizacji wirtualnych danych
  polegajacej na tym, ze z punktu widzenia
  uzytkownika lub programisty nie wystepuja
  jakiekolwiek róznice w operowaniu na
  zapamietanych i wirtualnych danych. Problem
  aktualizacji danych wirtualnych jest znany od
  1974 roku, ale dotychczas nie doczekal sie
  uniwersalnego rozwiazania.
• Optymalizacja efektywna realizacja zapytan
  odwolujacych sie do perspektyw. Bezposrednia
  implementacja, poprzez zmaterializowanie wyniku
  perspektywy dla konkretnego zapytania, prowadzi
  do nieakceptowalnych czasów wykonania, zatem
  konieczne sa mocne metody optymalizacyjne.

15
Optymalizacja zapytan

• Bezposrednia implementacja semantyki, w sytuacji
  gdy bazy danych zawieraja miliony danych,
  prowadzi do nieakceptowalnego czasu odpowiedzi na
  zapytanie.
• Radykalne skrócenie tego czasu, zwane
  optymalizacja, staje sie wiec koniecznoscia, zas
  jezyk zapytan, który nie jest wspomagany przez
  optymalizacje, nie ma szans na akceptacje ze
  strony klientów baz danych.
• Metody optymalizacyjne znane z systemów
  relacyjnych z trudem przenosi sie na modele
  obiektowe, ze wzgledu na przywiazanie tych metod
  do cech modelu relacyjnego oraz do fizycznej
  reprezentacji danych.
• Optymalizacja zapytan jest katalizatorem rozwoju
  teorii jezyków zapytan. Optymalizacja najczesciej
  polega na tym, ze zapytanie q1 jest automatycznie
  zamieniane na semantycznie równowazne zapytanie
  q2, które rokuje znacznie lepszy czas wykonania.
• Teoria jest niezbedna do tego, aby odpowiedziec
  na pytanie co to znaczy semantycznie
  równowazne?
• Odpowiedz na to pytanie wymaga zalozenia, ze
  kazdy najdrobniejszy problem semantyczny jest
  ogromnym problemem.

16
SBQL

• Podczas wykladu zostana wyjasnione zalozenia i
  semantyka jezyka zapytan SBQL (Stack Based Query
  Language) opartego na podejsciu stosowym.
• SBQL jest pewna idealizacja oparta na
  abstrakcyjnej skladni, pokazujaca istote
  semantyki operatorów wprowadzonych w wiekszosci
  jezyków zapytan.
• SBQL pelni on te sama role, która w relacyjnych
  jezykach zapytan pelni algebra relacji i rachunek
  relacyjny.
• Zasadnicza nowoscia wprowadzona w SBQL sa
  operatory nie-algebraiczne, takie jak operatory
  selekcji, projekcji/nawigacji, zlaczenia,
  kwantyfikatory, operator tranzytywnego domkniecia
  i operator porzadkowania.
• Semantyka tych operatorów nie moze byc wyrazona w
  terminach algebry podobnej do algebry relacji.
  Jak sie okazalo, ich semantyke mozna w prosty
  sposób wyrazic poprzez operacje na stosie
  srodowiskowym, przy czym pewnym zaskoczeniem jest
  to, ze semantyka tych wydawaloby sie bardzo
  róznych operatorów jest oparta o ten sam prosty
  mechanizm.

17
Dlaczego operatory sa nie-algebraiczne?

• Twórcy i kontynuatorzy koncepcji modelu
  relacyjnego przez lata przyzwyczaili nas, ze
  operatory selekcji, projekcji i zlaczenia sa
  zwyczajnymi operatorami algebraicznymi w
  algebrze relacji.
• Nie potrzeba wielkiej wnikliwosci matematycznej,
  aby pokazac, ze ich algebraizacja odbyla sie
  kosztem niezbyt rzetelnej sztuczki formalnej, w
  której czesc semantyki zostala przesunieta do
  nieformalnego meta-jezyka tej algebry.
• Dotyczy to nazw atrybutów, operacji, funkcji i
  innych elementów wystepujacych w indeksach
  operatorów algebry relacji.
• Np. selekcja nie jest pojedynczym operatorem
  jest to nieskonczona rodzina operatorów, gdzie
  konkretny egzemplarz jest wyznaczony poprzez
  indeks tego operatora nalezacy do meta-jezyka tej
  algebry.
• Indeksy nie naleza do formalnej semantyki, sa po
  prostu komentarzem.

?Zargt1000( Prac )
18
Pojecia formalne i nieformalne

• W ten sposób uniwersum semantycznych rozwazan
  zostalo podzielone na dwa swiaty
• swiat formalny pojec pierwszej kategorii,
  wlaczajacy nazwy relacji i operatory takie jak
  selekcja, projekcja i zlaczenie,
• swiat nieformalny pojec drugiej kategorii
  wystepujacy w nieformalnych komentarzach, w tym w
  indeksach.
• Ten podzial semantyki jest frustrujacy,
  nieakceptowalny i niepotrzebny.
• Matematyka jest neutralna w stosunku do
  ideologicznych zalozen i radzi sobie nie tylko z
  relacjami i z algebra relacji, lecz równiez z
  teoriami o innych zalozeniach, w których opisana
  anomalia nie wystepuje.
• Podejscie stosowe nie korzysta wiec z teorii
  wypracowanych przez spolecznosc baz danych.
• Wprowadza operatory nie-algebraiczne w taki
  sposób, aby wyeliminowac podzial na w/w dwa
  swiaty.
• Podejscie stosowe znacznie precyzyjniej formuluje
  te wlasnie pojecia, które dotad sa przypisywane
  algebrze relacji, rachunkowi relacyjnemu lub
  logice matematycznej.

19
Zapytania wyrazenia

• W naszym podejsciu zapytania beda pelnic role
  wyrazen znanych z jezyków programowania.
• Przyjeta przez nas zasada ortogonalnej trwalosci
  nie róznicuje sposobów dostepu do trwalych i
  nietrwalych danych.
• Wobec tego nasze zapytania beda równiez stosowane
  do nietrwalych danych.
• Inaczej mówiac przyjelismy, ze w naszym
  hipotetycznym jezyku programowania nie bedzie
  innych wyrazen niz zapytania.
• Zapytaniami beda wiec takze klasyczne wyrazenia
  takie jak 22, sin(x), Ai1, itd.
• To zalozenie jest pewna rewolucja w odniesieniu
  do jezyków zapytan.
• Tradycyjnie, np. w jezyku SQL zapytania
  (zagniezdzone w jezyk programowania) mogly
  odwolywac sie do zmiennych jezyka programowania
  poprzez specjalna skladnie.

20
Konstrukcje i abstrakcje programistyczne

• Podejscie stosowe nie stwarza jakiejkolwiek
  granicy pomiedzy jezykiem zapytan i jezykiem
  programowania.
• Jezeli zaimplementowane sa mechanizmy jezyka
  zapytan, wówczas przystosowanie ich do
  konstrukcji imperatywnych i abstrakcji takich jak
  moduly, klasy, procedury, funkcje, metody i
  perspektywy jest zadaniem dosc oczywistym.
• Podejscie stosowe prowadzi równiez do prostych
  mechanizmów przekazywania parametrów do procedur
  (funkcji, metod), w szczególnosci mechanizmów
  znanych jako wolanie przez wartosc
  (call-by-value) i wolanie przez referencje
  (call-by-reference).
• Z natury rzeczy, definiowane w podejsciu stosowym
  mechanizmy umozliwiaja dowolne wolania
  rekurencyjne procedur (funkcji, metod,
  perspektyw).

21
Kontrola typologiczna

• Przy rozpatrywaniu jezyków zapytan, szczególnie
  jezyków zintegrowanych z jezykami programowania,
  nie mozna pominac kwestii mocnej kontroli
  typologicznej.
• Mechanizm mocnej kontroli typów chroni
  programistów przed ich wlasnymi bledami i w
  zwiazku z tym jest kluczowym czynnikiem
  podwyzszenia niezawodnosci oprogramowania.
• Istnieja szacunki pokazujace, ze system kontroli
  typologicznej jest w stanie wykryc 80 bledów
  semantycznych i koncepcyjnych.
• Bezpieczenstwo typologiczne (typing safety) jako
  podstawowa zasada jezyków programowania.
• System typów ma równiez ogromne znaczenie dla
  modelowania pojeciowego, gdyz odpowiednio dobrane
  nazwy typów pelnia role semantycznych
  kwalifikatorów bytów programistycznych w
  dziedzinie przedmiotowej.
• Jezyki bez typów i bez mocnej kontroli typów sa
  uwazane za niebezpieczne, prowadzace do niskiej
  jakosci oprogramowania.

22
Co to sa "jezyki zapytan"?
Istnieje na ten temat wiele pogladów, np.

• Proste, przyjacielskie i naturalne interfejsy dla
  powszechnego uzytkownika do interakcyjnego
  formulowania zlecen wyszukiwania w bazie danych
  lub jej aktualizacji przez malo doswiadczonego
  uzytkownika. W tej roli znacznie lepsze od SQL sa
  interfejsy graficzne oparte o okienka, menu,
  formularze, tabele, przegladanie, itp.
• Syntaktyczne warianty jezyków pewnych slawnych
  matematycznych teorii, np. logiki. Ten punkt
  widzenia byl lansowany przez teoretyków baz
  danych. Obecne jezyki zapytan zaprzeczaja tego
  rodzaju pogladom.
• Pod-jezyki bardzo wysokiego poziomu (API)
  zanurzane w typowe jezyki programowania do
  wyszukiwania i aktualizacji bazy danych. W
  tej roli najczesciej wystepuje SQL. Liczne wady
  tego podejscia.
• Wyrazenia programistyczne bardzo wysokiego
  poziomu zintegrowane z jezykiem programowania.
  Tworza kompletny interfejs do programowania
  aplikacji. Przykladem jest PL/SQL systemu Oracle.

23
Jezyki zapytan jako wyrazenia programistyczne

• Ostatni punkt widzenia zaklada nowy rodzaj jezyka
  programowania, w którym wystepuja specyficzne
  wyrazenia (podobne do klasycznych wyrazen jezyka
  oprogramowania) zwane zapytaniami.
• Istota tych nowych wyrazen jest obsluga kolekcji.
  
• W tej roli jezyki zapytan sa wyzszym szczeblem
  abstrakcji nad konstrukcjami organizujacymi petle
  (while, repeat, goto, for, loop, itp.),
  iteratorami, kursorami i innymi tego rodzaju
  udogodnieniami.
• Zapytania koncepcyjnie hermetyzuja petle
  iteracyjne w jezyku programowania przy pomocy
  operatorów takich jak selekcja (where),
  projekcja, zlaczenie, unia, kwantyfikatory,
  grupowanie, sortowanie, itp.
• Slowo koncepcyjnie jest tu istotne, gdyz chodzi
  o taka hermetyzacje, która jest naturalna,
  zrozumiala i czytelna dla programisty
  wspomagajaca procesy modelowania pojeciowego przy
  tworzeniu aplikacji.
• W tej koncepcji jezyki zapytan sa tworami
  calkowicie ortogonalnymi w stosunku do cechy
  trwalosci danych (czyli bazy danych).

24
Znaczenie jezyków zapytan

• Obnizenie poziomu profesjonalizmu niezbednego do
  programowania aplikacji baz danych. W
  tradycyjnych jezykach programowania aplikacje te
  wymagaja profesjonalnych, wysoko oplacanych
  programistów.
• Podwyzszenie wydajnosci programistów poprzez
  dostarczenie do ich dyspozycji pojeciowych,
  makroskopowych operacji, pozwalajacych zapisac
  zlozone przetwarzanie w zwartej, czytelnej i
  zrozumialej formie.
• Jedno zdanie w SQL moze zastapic kilka stron
  programu napisanego w jezykach takich jak Cobol,
  C lub Pascal.
• Ma to skutki dla tempa tworzenia oprogramowania,
  jego kosztu, pielegnacyjnosci i modyfikowalnosci.
• Podwyzszenie niezawodnosci produktów
  programistycznych poprzez zwartosc zapisu
  programu i konceptualizacje myslenia programisty.
• Zwolnienie projektanta i programisty z myslenia o
  mniej istotnych sprawach implementacyjnych,
  umozliwienie skupienia sie na tym co ma byc
  zrobione, a nie jak myslenie w kategoriach
  problemu i dziedziny zastosowan, a nie w w
  kategoriach detali i sztuczek implementacyjnych.

25
Zastosowania jezyków zapytan (1)

• Narzedzie dla powszechnego uzytkownika
  umozliwiajace interakcyjne zapytania i
  aktualizacje (tzw. ad hoc), z generacja
  odpowiedzi lub raportów w pewnych z góry zadanych
  formatach.
• Konstrukcje jezyka programowania umozliwiajace
  programowanie na bardzo wysokim poziomie
  abstrakcji i konceptualizacje programów.
• Definiowanie ograniczen integralnosciowych
  (integrity constraints), inaczej wiezów
  integralnosci, zapobiegajacych niedopuszczalnym
  operacjom na bazie danych lub wykrywajacych bledy
  w danych.
• Definiowanie podschematów, ograniczen dostepu i
  innych srodków autoryzacji lub bezpieczenstwa
  danych.
• Definiowanie wirtualnych perspektyw (views),
  zmaterializowanych perspektyw (materialized
  views), danych pochodnych (derived), replikacji
  danych, procedur zapamietanych w bazie danych
  (stored procedures, database procedures), i
  innych abstrakcji lub udogodnien w danych.

26
Zastosowania jezyków zapytan (2)

• Skladowe konstrukcji jezykowych skryptów
  (scripts) w jezykach czwartej generacji (4GL) i
  narzedziach do prototypowania (RAD).
• Definiowanie aktywnych regul, dedukcyjnych regul,
  aktywnych agentów i innych inteligentnych"
  elementów w bazie danych.
• Okreslanie danych do transmisji w rozproszonych
  bazach danych umozliwienie wspólpracy pomiedzy
  heterogenicznymi i/lub odleglymi bazami danych
  (np. interfejsy w stylu ODBC lub JDBC).
• Okreslanie danych do transmisji pomiedzy róznymi
  rodzajami pamieci, np. pomiedzy pamiecia optyczna
  typu jukebox a pamiecia dyskowa.
• Narzedzia do wyszukiwania informacji w danych
  pól-strukturalnych (semi-structured), np. w
  plikach XML lub RDF definiowanie perspektyw nad
  danymi pól-strukturalnymi.
• Narzedzia do eksploracja danych (data mining),
  hurtowni danych i analitycznego przetwarzania
  (OLAP).

27
Wlasnosci jezyków zapytan (1)

• Wysoki poziom konceptualizacji i abstrakcji
  niezaleznosc danych (data independence)
  wyrazajaca sie w braku odwolan do elementów
  fizycznej organizacji danych (takich jak np.
  indeksy). Uzytkownik formuluje zapytanie znajac
  wylacznie logiczny schemat bazy danych.
• Nieproceduralnosc lub deklaracyjnosc, wyrazajaca
  sie w zorientowaniu jezyka na formulowanie
  bezposrednio celu wyszukiwania, a nie srodków
  prowadzacych do tego celu.
• Makroskopowosc, czyli jednoczesne dzialanie (z
  punktu widzenia uzytkownika) na wielu elementach
  kolekcji o nieznanych rozmiarach.
• Naturalnosc, czyli wspomaganie naturalnych
  schematów myslenia uzytkownika, wspomaganie
  modelowania pojeciowego, latwosc uczenia sie i
  uzycia.

28
Wlasnosci jezyków zapytan (2)

• Efektywnosc, czyli akceptowalne czasy wykonania
  zapytan. Oznacza to koniecznosc stosowania
  automatycznych metod optymalizacyjnych.
• To zas oznacza koniecznosc okreslenia jednorodnej
  koncepcji i zdefiniowania precyzyjnej semantyki
  jezyka, bez pomijania jakichkolwiek detali.
• Dla zlozonego problemu automatyczna optymalizacja
  zapytan jest bardziej skuteczna od manualnego
  zakodowania tego samego zadania w jezyku niskiego
  poziomu, np. w C.
• Uniwersalnosc, czyli zdolnosc jezyka zapytan do
  definiowania dowolnych operacji wyszukiwania i
  kojarzenia danych.
• Ta wlasnosc jest slaba strona SQL.
• Kryteria dla okreslenia stopnia uniwersalnosci
  jezyków zapytan sa ulomne. Tzw. relacyjna
  kompletnosc (relational completeness) jest
  przypadkowym, nie umotywowanym punktem na skali
  uniwersalnosci. Tzw. "kompletnosc Turinga"
  (Turing completeness) jest oparta na
  pseudo-argumentach.
• Uniwersalnosc jest kategoria pragmatyczna, a nie
  matematyczna.

29
Wlasnosci jezyków zapytan (3)

• Niezaleznosc od dziedziny zastosowan, czyli brak
  przypisania do jednej dziedziny aplikacyjnej,
  umozliwienie realizacji wszystkich potencjalnych
  zastosowan danego systemu zarzadzania baza
  danych.
• Wykonywanie zapytan w trybie interpretacyjnym,
  pózne (dynamiczne) wiazanie, brak fazy kompilacji
  i konsolidacji zapytan z caloscia aplikacji.
  Umozliwia to zapytania ad hoc, dynamiczne
  tworzenie i usuwanie perspektyw, zapamietywanie
  procedur i regul w bazie danych, dynamiczne
  tworzenie i usuwanie indeksów, itd.