© K.Subieta. Obiektowe języki zapytań, Wykład 01, Folia 1
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)
© K.Subieta. Obiektowe języki zapytań, Wykład 01, Folia 2
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.
© K.Subieta. Obiektowe języki zapytań, Wykład 01, Folia 3
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
© K.Subieta. Obiektowe języki zapytań, Wykład 01, Folia 4
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.
© K.Subieta. Obiektowe języki zapytań, Wykład 01, Folia 5
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.
© K.Subieta. Obiektowe języki zapytań, Wykład 01, Folia 6
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).
© K.Subieta. Obiektowe języki zapytań, Wykład 01, Folia 7
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.
© K.Subieta. Obiektowe języki zapytań, Wykład 01, Folia 8
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
1
, którego czas
wykonania jest dramatycznie długi (np. 500 lat), na
semantycznie
równoważne
zapytanie
q
2
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ń.
© K.Subieta. Obiektowe języki zapytań, Wykład 01, Folia 9
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
© K.Subieta. Obiektowe języki zapytań, Wykład 01, Folia 10
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.
© K.Subieta. Obiektowe języki zapytań, Wykład 01, Folia 11
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.
© K.Subieta. Obiektowe języki zapytań, Wykład 01, Folia 12
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.
© K.Subieta. Obiektowe języki zapytań, Wykład 01, Folia 13
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.
© K.Subieta. Obiektowe języki zapytań, Wykład 01, Folia 14
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.
© K.Subieta. Obiektowe języki zapytań, Wykład 01, Folia 15
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.
© K.Subieta. Obiektowe języki zapytań, Wykład 01, Folia 16
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.
© K.Subieta. Obiektowe języki zapytań, Wykład 01, Folia 17
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 )
© K.Subieta. Obiektowe języki zapytań, Wykład 01, Folia 18
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.
© K.Subieta. Obiektowe języki zapytań, Wykład 01, Folia 19
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ę.
© K.Subieta. Obiektowe języki zapytań, Wykład 01, Folia 20
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).
© K.Subieta. Obiektowe języki zapytań, Wykład 01, Folia 21
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.
© K.Subieta. Obiektowe języki zapytań, Wykład 01, Folia 22
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.:
© K.Subieta. Obiektowe języki zapytań, Wykład 01, Folia 23
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).
© K.Subieta. Obiektowe języki zapytań, Wykład 01, Folia 24
marzec 2004
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.
© K.Subieta. Obiektowe języki zapytań, Wykład 01, Folia 25
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.
© K.Subieta. Obiektowe języki zapytań, Wykład 01, Folia 26
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).
© K.Subieta. Obiektowe języki zapytań, Wykład 01, Folia 27
marzec 2004
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.
© K.Subieta. Obiektowe języki zapytań, Wykład 01, Folia 28
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ą.
© K.Subieta. Obiektowe języki zapytań, Wykład 01, Folia 29
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.