ObiektoweJezykiZapytan 01

background image

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

background image

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

background image

© K.Subieta. Obiektowe języki zapytań, Wykład 01, Folia 3

marzec 2004

Ogólna charakterystyka języków

zapytań (1)

Języki

zapytań

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

background image

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

background image

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

background image

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

background image

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

background image

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

background image

© 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

background image

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

background image

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

background image

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

background image

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

background image

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

background image

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

background image

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

background image

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

background image

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

background image

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

background image

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

background image

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

background image

© 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.:

background image

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

background image

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

background image

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

background image

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

background image

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

background image

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

background image

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


Document Outline


Wyszukiwarka

Podobne podstrony:
4 Wykrywanie manewr¦é w obiekt¦é w 01
programowanie obiektowe 01, c c++, c#
programowanie obiektowe 01
01 09 obiekty noclegowe 2012 www
3 Obiekty na kursach równoległych 01
5 Identyfikacja obiektów niebezpiecznych 01
IDENTYF 27-01.DOC, IDENTYFIKACJA OBIEKTÓW DYNAMICZNYCH
01-PRACOWNIK OBSŁUGI OBIEKTU, Instrukcje BHP, V - CPN
MIKOSZKI 20 ZESTAWIENIE OBIEKTÓW 23,01,2018
01 Rozpoznawanie obiektów architektury krajobrazu
01 Organizowanie i wyposażanie obiektów handlowych
DzU 01 138 1554 obiekty przy ktorych inspektor
01 Organizowanie i wyposażanie obiektów handlowych
TD 01
Obiekty martyrologii polskiej

więcej podobnych podstron