Obiektowe języki zapytań 1..5

marzec 2004

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)

marzec 2004

Plan wykładów



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

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ń

Dalsze wykłady: perspektywy w SBQL, optymalizacja zapytań,
mocna kontrola typologiczna, aspektowe, rozproszone,
federacyjne bazy danych – w przyszłym semestrze.

marzec 2004

Ogólna charakterystyka języków

zapytań (1)



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.

query languages

marzec 2004

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.

marzec 2004

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.

marzec 2004

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).

marzec 2004

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.

marzec 2004

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 q

, którego czas

wykonania jest dramatycznie długi (np. 500 lat), na

semantycznie

równoważne

zapytanie

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ń.

marzec 2004

Generalne założenia podejścia

stosowego



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.

stack-based approach, SBA

marzec 2004

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.

marzec 2004

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.

marzec 2004

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.

marzec 2004

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.

marzec 2004

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.

marzec 2004

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.

marzec 2004

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.

marzec 2004

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 )

marzec 2004

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.

marzec 2004

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ę.

marzec 2004

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).

marzec 2004

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.

marzec 2004

Co to są "języki zapytań"?



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.

Istnieje na ten temat wiele poglądów, np.:

marzec 2004

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).

marzec 2004

Znaczenie języków zapytań



Obniżenie poziomu profesjonalizmu niezbędnego do programowania
aplikacji baz danych. W tradycyjnych językach programowania
aplikacje

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.

marzec 2004

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.

marzec 2004

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).

marzec 2004

Własności języków zapytań (1)



Wysoki

poziom

konceptualizacji

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.

marzec 2004

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ą.

marzec 2004

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.

Document Outline