Obiektowe języki zapytań 1..5

Obiektowe języki zapytań
Wykładowca: Kazimierz Subieta
Polsko-Japońska Wyższa Szkoła
Technik Komputerowych, Warszawa
[email protected]
Instytut Podstaw Informatyki PAN,
Warszawa
[email protected]
© K.Subieta. Obiektowe języki zapytań 02, Folia 1
Wykład 2
Wprowadzenie do
języków zapytań (2)
marzec 2004
Zasady języków zapytań (1)
 Ostatnio, zasady wypracowane przez świat akademicki są
kwestionowane przez świat przemysłowy. Wynika to z dwóch
przyczyn:
• dla firm komercyjnych jest bardzo niewygodne stwierdzenie, że jakaś
cecha ich produktu jest "niezgodna z zasadą". Kwestionuje się więc
zasadę.
• świat akademicki zbyt pochopnie wypracowuje „zasady”, które tak
naprawdę są często motywowane pewną koncepcją teoretyczną,
ideologią, formą lub steoretypem. Przykładem są „zasady” baz danych
wypracowane przez model relacyjny, które w całości można wyrzucić
do kosza, jeżeli przejdziemy na model obiektowy.
 Zadaniem świata akademickiego jest jednak wypracowanie i
obrona zasad.
 Dalej są podane podstawowe zasady obowiązujące języki zapytań
(czasami nie tylko języki zapytań).
© K.Subieta. Obiektowe języki zapytań 02, Folia 2
marzec 2004
Zasady języków zapytań (2)
 Naturalność: zgodność z naturalnym myśleniem potencjalnych
użytkowników. Niekoniecznie oznacza ona wyrażanie zapytań w języku
naturalnym (ponieważ jest on zbyt mało precyzyjny).
 Prostota: klarowność konstrukcji syntaktycznych, oczywistość
semantyki, łatwość uczenia się i nauczania, łatwość dokumentowania,
implementacji, pielęgnowania i użycia.
 Ortogonalność: każda kombinacja cech języka, która ma sens, powinna
być dozwolona. Ortogonalność pozwala na zredukowanie do minimum
definicji języka oraz znaczne podwyższenie jego mocy.
 Kompozycyjność: unikanie dużych zlepków syntaktycznych i zależności
pomiędzy odległymi kontekstowo fragmentami wyrażeń języka.
© K.Subieta. Obiektowe języki zapytań 02, Folia 3
marzec 2004
Zasady języków zapytań (3)
 Relatywizm: identyczna składnia i semantyka wyrażeń języka
odnoszących się do dowolnego poziomu zagnieżdżenia struktur danych.
Np. zapytania odnoszące się do całej bazy danych i odnoszące się do
wnętrza pojedynczego obiektu (które może zawierać podobiekty) powinny
być konstruowane na tych samych zasadach.
 Minimalność (brzytwa Occama): unikanie cech redundantnych. Dotyczy
to zarówno redundantnej składni, jak i wprowadzania takich konstrukcji
językowych, które można łatwo zastąpić przez inne konstrukcje.
 Brak anomalii: unikanie specjalnych przypadków, cech wyjątkowych,
nieregularnego traktowania, itd. Wszystkie takie cechy stają się przyczyną
błędów oraz zwiększają objętość dokumentacji języka. Szczególnie
groźne są tzw. semantyczne rafy, które powodują błędny (nieoczekiwany)
wynik bez ostrzeżeń.
© K.Subieta. Obiektowe języki zapytań 02, Folia 4
marzec 2004
Zasady języków zapytań (4)
 Uniwersalność: język powinien w maksymalnym stopniu przykrywać
dziedzinę, do której został przeznaczony. Chodzi o uniwersalność
pragmatyczną, czyli spełnienie wszystkich aktualnych (i rozsądnych)
oczekiwań użytkowników na dzisiaj i na przewidywaną przyszłość.
 Modularność (hermetyzacja): umożliwienie użytkownikowi zamykania
fragmentów języka w nazwane, hermetyzowane bryły, którymi można
dalej posługiwać się tak jak atomami. Zmiana kontekstu użycia takich brył
nie powinna prowadzić do zmiany ich znaczenia.
 Bezpieczeństwo: wzbogacenie języka o specjalne środki (takie jak
deklarowanie typów, asercje, więzy integralności, transakcje)
przeciwdziałające niepoprawnemu użyciu konstrukcji języka,
prowadzących do naruszenia integralności bazy danych lub integralności
przetwarzania.
© K.Subieta. Obiektowe języki zapytań 02, Folia 5
marzec 2004
Zasady języków zapytań (5)
 Specjalna troska o przypadki skrajne: puste zbiory, puste stringi,
wartości zerowe, niezainicjowane zmienne, itd. są bardzo często nie objęte
definicją semantyki języka, co powoduje rezultaty nie oczekiwane przez
użytkowników.
 Koncepcyjna kontynuacja: mała zmiana celu, dla którego budowane jest
wyrażenie języka, nie powinno wywoływać dramatycznej zmiany w
myśleniu użytkownika i w formie tego wyrażenia.
 Jednorodne podejście do konstrukcji programistycznych bazujących
na języku zapytań (zdania imperatywne, perspektywy, procedury, metody,
parametry procedur i metod, itd.).
 Nie zaniedbywanie jakiegokolwiek problemu semantycznego.
• Każdy, nawet najmniejszy problem semantyczny jest dużym
problemem.
 Wysoki potencjał dla optymalizacji zapytań.
© K.Subieta. Obiektowe języki zapytań 02, Folia 6
marzec 2004
Obiektowość a języki zapytań (1)
 Stosunek obiektowości do języków zapytań nadal nie jest do końca jasny.
Wynika to z dwóch przyczyn:
 1. Obiektowość jest ideologią informatyczną o luźno zarysowanych
założeniach, pojęciach i granicach.
• Natomiast języki zapytań są tworami formalnymi, których semantyka musi
być określona precyzyjnie, gdyż muszą być automatycznie optymalizowane.
• Luźne założenia i granice modeli obiektowych, ich ograniczenia (np. brak
kolekcji) powodują, że specyfikacje języków zapytań są intuicyjne.
 2. Poglądy i (fałszywe) stereotypy dotyczące języków zapytań,
wypracowane podczas rozwoju modelu relacyjnego.
• Np. twierdzenia, że jedynie model relacyjny wraz z jego podstawami
matematycznymi może być podstawą definicji języków zapytań.
• M. Stonebraker w często cytowanych publikacjach twierdzi, że obiektowe
bazy danych w ogóle nie mogą być wyposażone w języki zapytań.
• Podobne poglądy do pewnego czasu głosił J. Ullman.
© K.Subieta. Obiektowe języki zapytań 02, Folia 7
marzec 2004
Obiektowość a języki zapytań (2)
 Powstały próby i spekulacje dotyczące tego jak dopasować paradygmaty
relacyjnych języków zapytań do obiektowych struktur danych.
• Np. jak zmodyfikować algebrę relacji, jak przystosować SQL, itp.
• Konkluzje bywają zaskakujące.
 Przez pewien czas dominował pogląd, że idea języków zapytań jest
sprzeczna z koncepcją hermetyzacji (encapsulation).
• Zdaniem niektórych autorów, hermetyzacja polega na tym, że obiekt może
być przetwarzany wyłącznie przez metody zdefiniowane w jego klasie.
• Języki zapytań muszą mieć bezpośredni dostęp do atrybutów.
• Ergo: języki zapytań są sprzeczne z hermetyzacją.
• Jest to nonsens wynikający ze złego rozumienia pojęć obiektowości.
 Inną konsekwencją jest bezpośrednie uogólnianie metod formalnych
relacyjnych języków zapytań na obiektowe języki zapytań.
• Efektem jest mnogość tzw. obiektowych algebr, obiektowych rachunków, itd.
• Są to twory koncepcyjnie, matematycznie i pragmatycznie wadliwe.
© K.Subieta. Obiektowe języki zapytań 02, Folia 8
marzec 2004
Niezgodność impedancji (1)
impedance mismatch
 Wykształcone w latach 70-tych koncepcje dotyczące języków
zapytań z definicji zakładały brak algorytmicznej uniwersalności.
 Ponieważ taka uniwersalność jest niezbędna do tworzenia aplikacji
opartych na bazie danych, przyjęto, że języki zapytań będą „podjęzykami” w środowisku wytwórczym oprogramowania
 Co za tym idzie, to środowisko powinno być oparte na popularnym
języku programowania. To oznacza konieczność połączenia języka
zapytań z językiem programowania, w taki sposób, aby:
• zapytania mogły być używane wewnątrz programów;
• zapytania mogły być parametryzowane (dynamicznie, w praktycznie
dowolny sposób) przez wartości zmiennych języka programowania;
• wyniki zapytań mogły być przetwarzane przez programy.
 Różnice w koncepcji języków spowodowały znaczne trudności techniczne
w realizacji tego rodzaju połączenia  niezgodność impedancji.
© K.Subieta. Obiektowe języki zapytań 02, Folia 9
marzec 2004
Niezgodność impedancji (2)
 Terminem tym określa się niekorzystne cechy formalnego połączeniu
języka zapytań (np. SQL) z językiem programowania takim jak np. C lub
Java. Objawia się niezgodnościami w zakresie:
• Składni. Programista musi w jednym tekście programu używać dwóch stylów
językowych i przestrzegać reguł dwóch różnych gramatyk.
• Systemu typów. Język zapytań operuje na typach zdefiniowanych w
schemacie bazy danych, m.in. relacjach, natomiast język programowania
posiada zwykle odmienny system typów, w którym nie występuje typ relacja.
Większość języków programowania ma wbudowaną statyczną kontrolę
typów, podczas gdy SQL takiej kontroli nie przewiduje.
• Semantyki i paradygmatów języków. Koncepcja semantyki języków jest
zasadniczo różna. Język zapytań bazuje na stylu deklaracyjnym (co
wyszukać, a nie jak) podczas gdy języki programowania bazują na stylu
imperatywnym (jak wyszukać, skąd pośrednio wynika co).
© K.Subieta. Obiektowe języki zapytań 02, Folia 10
marzec 2004
Niezgodność impedancji (3)
• Poziomu abstrakcji. Język zapytań uwalnia programistę od wielu
szczegółów organizacji i implementacji danych (np. organizacji zbiorów,
obecności lub nieobecności indeksów, itd.), podczas gdy w języku
programowania te szczegóły muszą być oprogramowane explicite.
• Faz i mechanizmów wiązania. Języki zapytań są oparte o późne wiązanie (są
interpretowane) podczas gdy języki programowania zakładają wczesne
wiązanie (podczas kompilacji i konsolidacji). Stwarza to problemy m.in. dla
mocnej kontroli typów, obrazu przestrzeni nazw, itd.
• Przestrzeni nazw i reguł zakresu. Język zapytań i język programowania
posiadają własne przestrzenie nazw, które mogą zawierać identyczne nazwy o
różnych znaczeniach. Odwzorowania pomiędzy przestrzeniami nazw
wymagają dodatkowych środków syntaktycznych i semantycznych.
• Traktowania wartości zerowych. Bazy danych i języki zapytań posiadają
wyspecjalizowane środki dla przechowywania i przetwarzania wartości
zerowych. Środki te nie występują w językach programowania.
© K.Subieta. Obiektowe języki zapytań 02, Folia 11
marzec 2004
Niezgodność impedancji (4)
• Schematów iteracyjnych. W języku zapytań iteracje są wtopione w
semantykę operatorów takich jak selekcja, projekcja i złączenie. W języku
programowania iteracje muszą być organizowane explicite przy pomocy pętli
for, while, repeat lub innych.
• Traktowania cechy trwałości danych. Języki zapytań przetwarzają
wyłącznie trwałe dane (znajdujące się na dysku), podczas gdy języki
programowania przetwarzają wyłącznie dane nietrwałe znajdujące się w
pamięci operacyjnej. Połączenie obu cech wymaga wprowadzenia
specjalnych środków językowych.
• Środków programowania ogólnego (generic). Środki te w języku zapytań są
oparte o refleksję (np. dynamiczny SQL). Użycie podobnego środka w języku
programowania jest trudne z powodu wczesnego wiązania.
 Niezgodność impedancji powoduje konieczność istnienia dodatkowej
warstwy oprogramowania pośredniczącego pomiędzy językiem zapytań i
językiem programowania. Ta warstwa zwiększa długość kodu aplikacji,
może być źródłem błędów, zwiększa czas uczenia się narzędzia, zwiększa
czas wykonania, oraz zmniejsza pielęgnacyjność oprogramowania.
© K.Subieta. Obiektowe języki zapytań 02, Folia 12
marzec 2004
Schemat i organizacja danych
 Są to nieodłączne cechy języka zapytań.
 Użytkownik języka musi być w pełni świadomy celów formułowania
zapytania, związków zapytania zarówno z jego celem (biznesowym), jak i
strukturą danych.
 Musi być świadomy technicznych i biznesowych własności struktur
danych oraz technicznych i biznesowych własności zwracanego przez
zapytanie wyniku.
 Warunkiem koniecznym umożliwiającym formułowanie zapytań jest
informacja co zawiera baza danych i jak jest zorganizowana.
• Ta informacja musi mieć algorytmiczną precyzję.
• Determinizm programów komputerowych (w tym zapytań) oznacza, że
użytkownik lub programista posiada wiedzę o logicznej organizacji danych.
• Terminem „logiczna” określa się organizację danych wyrażoną w terminach
precyzyjnego „zewnętrznego” modelu danych, abstrahującą od fizycznej
reprezentacji danych.
© K.Subieta. Obiektowe języki zapytań 02, Folia 13
marzec 2004
Zależności pomiędzy pojęciami języka zapytań
Meta-model
Model danych
znaczenie
danych
Dziedzina
przedmiotowa,
uniwersum rozważań
potrzeba
Schemat składu
(bazy) danych
wiedza o
strukturach
danych
Możliwy stan składu
danych
Możliwy stan składu
danych
Możliwy stan składu
danych
Możliwy stan składu
danych
Bieżący stan składu
danych
Zapytanie
interpretacja
wyniku
Wynik
zapytania
© K.Subieta. Obiektowe języki zapytań 02, Folia 14
marzec 2004
Pojęcia języka zapytań (1)
 Model danych wyznacza reguły budowy oraz ograniczenia struktur
danych,
• pośrednio określa składnię i semantykę języka schematu danych oraz metamodelu ustalającego organizację danych.
 Schemat składu (lub bazy) danych powstaje w wyniku analizy dziedziny
przedmiotowej (biznesu), zakresu aplikacji, które mają go wspomagać
oraz projektu struktury (bazy) danych niezbędnej do działania tych
aplikacji.
 Skład lub baza danych zawiera konkretne dane zgodne z modelem
danych, kontrolowane przez meta-model i schemat składu danych.
• Bieżący stan składu danych zmienia się i zwykle jest nieznany dla
użytkownika w momencie pisania zapytania.
• Z tego względu zapytanie jest formułowane w odniesieniu do (zwykle
nieskończonego) zbioru możliwych stanów składu.
• Zbiór ten jest określony semantyką schematu.
© K.Subieta. Obiektowe języki zapytań 02, Folia 15
marzec 2004
Pojęcia języka zapytań (2)
 Stan składu danych może być przedstawiony na poziomie logicznym z
algorytmiczna precyzją.
• Użytkownik jest w pełni świadomy potencjalnego zbioru możliwych struktur
danych na których działa jego zapytanie, mimo że nie zna konkretnego stanu
tych struktur.
 Zapytanie jest formułowane przez użytkownika na podstawie rozpoznanej
potrzeby w dziedzinie przedmiotowej oraz na podstawie wiedzy o
strukturach danych.
• Wiedza ta jest wyznaczona schematem oraz związkiem schematu z dziedzina
przedmiotową.
 Wynik zapytania powstaje jak skutek zapytania oraz bieżącego stanu
składu danych.
• Wynik jest interpretowany przez użytkownika w dziedzinie przedmiotowej,
• Może on go poprawnie przetwarzać przy pomocy innych własności systemu.
© K.Subieta. Obiektowe języki zapytań 02, Folia 16
marzec 2004
Schemat składu danych i przykładowy stan składu
Osoba [0..*]
nazw: string
wiek: integer
zarobek: integer [0..1]
pracuje w [0..1]
Schemat
zatrudnia [0..*]
Firma [0..*]
nazwa: string
lokacja: string [1..*]
i10 Osoba
Jeden z
możliwych
stanów
© K.Subieta. Obiektowe języki zapytań 02, Folia 17
i20 Osoba
i30 Firma
i11 nazw ”Abacki”
i21 nazw ”Nowak”
i31 nazwa ”Asko”
i12 wiek 29
i22 wiek 33
i32 lokacja ”Radom”
i13 zarobek 1900
i33 lokacja „Piła”
i14 pracuje w
i34 zatrudnia
marzec 2004
Co użytkownik musi wiedzieć?
 Poprzedni slajd przedstawia przykład schematu danych, z którego
użytkownik:
•
•
•
•
•
widzi z jakimi obiektami biznesowymi ma do czynienia (Osoba i Firma),
rozumie ich znaczenie w dziedzinie biznesowej,
wie jakie mają atrybuty (wraz z typami),
wie jak są ze sobą powiązane (powiązania pracuje w/zatrudnia),
zna też liczności wszystkich elementów w dowolnym stanie składu, np. wie,
że obiektów Osoba może być od zera do dowolnej liczby, atrybut zarobek
może nie wystąpić, zaś firma może być zlokalizowana w jednym lub więcej
miejsc.
 Slajd przedstawia też przykładowy stan składu danych odpowiadający
temu schematowi.
• prawdziwego stanu użytkownik zwykle nie zna,
• na podstawie pewnych wyobrażeń odnośnie własności logicznych struktur
danych może poprawnie zbudować zapytanie.
© K.Subieta. Obiektowe języki zapytań 02, Folia 18
marzec 2004
Język schematu
 Użytkownik formułujący zapytanie powinien posiadać i rozumieć opis
danych zawartych w składzie (bazie) danych.
 Powinien to być schemat danych zapisany w odpowiednim precyzyjnym
języku.
 Wzorcem takiego języka może być IDL standardu CORBA, ODL
standardu ODMG, lub DTD (lub XML Schema) dla repozytoriów XML.
 Schemat danych jest opisem (nieskończonego) zbioru stanów składu
danych rozumianych na poziomie logicznym, z algorytmiczną precyzją.
 Brak precyzyjnego modelu składu danych uniemożliwia zdefiniowanie
semantyki języka zapytań.
• Przykładowo, diagram klas UML przypomina schemat składu (bazy) danych.
• Ten schemat nie definiuje jednak pojęcia stanu składu danych.
• Stąd precyzyjne zdefiniowanie języka zapytań dla UML jest niemożliwe.
 Podobnie do rozumienia stanów składu danych, użytkownik musi
rozumieć wynik zapytania, na poziomie logicznym, z algorytmiczna
precyzją.
© K.Subieta. Obiektowe języki zapytań 02, Folia 19
marzec 2004
Złożoność modelu danych a złożoność zapytań
 Im więcej informacji semantycznej znajduje się w strukturach
danych, tym mniej złożone i krótsze są zapytania.
• Jeżeli model danych nie daje możliwości zapisu pewnych informacji
semantycznych, wówczas schemat danych niezbędny do rozumienia
biznesowej roli danych jest prosty formalnie, ale złożony koncepcyjnie.
• Jest mniej czytelny dla programisty, co wydłuża czas formułowania zapytań.
• Programista formułujący zapytanie musi te zależności uwzględnić w
zapytaniu, przez co jest ono bardziej złożone.
 Zbyt prosty model danych powoduje dalsze straty:
• zwiększony rozmiar programów aplikacyjnych,
• zwiększony koszt ich tworzenia i pielęgnacji,
• zwiększony koszt/czas ewaluacji bardziej złożonych zapytań.
• Optymalizacji zapytań w relacyjnych SZBD zajmuje się częściowo reperowaniem
tego, co zostało zepsute poprzez zgubienie informacji semantycznej.
 Zbyt złożony model danych jest też niekorzystny – trudniej dopasować
sytuacje w dziedzinie biznesowej do decyzji w zakresie struktur danych.
© K.Subieta. Obiektowe języki zapytań 02, Folia 20
marzec 2004
Przykład: schemat prostej obiektowej bazy danych
Osoba[0..*]
Nazwisko
Imię[1..*]
Adres[1..*]
Firma[0..*]
FZ[0..*]
Nazwa
Miejsce[1..*]
Zatrudnienie[0..*]
ZF Wypłata[0..*]
Ocena[1..*]
ZP
Pracownik[0..*]
PZ[0..*] Stan[1..*]
 Programista po 2-3 minutach wyjaśnień jest w stanie zorientować się w
zawartości bazy danych.
 Zawiera ona cztery klasy obiektów, związki asocjacji z rolami, liczności
kolekcji obiektów, asocjacji i atrybutów oraz związek dziedziczenia.
• Ze schematu wynika np. że każdy pracownik jest osobą, ma jedno nazwisko,
lecz może mieć wiele imion i adresów, może pracować wielu firmach,
posiadać wiele wypłat i ocen w każdej z nich, itd.
• Po tych wyjaśnieniach bez trudu sformułuje zapytania np. w SBQL.
© K.Subieta. Obiektowe języki zapytań 02, Folia 21
marzec 2004
Przykład: schemat podobnej relacyjnej bazy danych
Firma(NrF, Nazwa)
Zatrudnienie(NrF, NrP)
Pracownik(NrP, NrOs)
Lokal(NrF, Miejsce)
Oceny(NrOceny, Ocena, NrF, NrP)
Dochód(NrDochodu, Wypłata, NrF, NrP)
Osoba(NrOs, Nazwisko)
Wyszkolenie(Stan, NrP)
Imiona(NrOs, Imię)
Adresy(NrOs, Adres)
 Część informacji semantycznej została utracona, np. informacja o
licznościach atrybutów i związków.
 Programista spędzi kilkanaście minut nad zrozumieniem zależności.
© K.Subieta. Obiektowe języki zapytań 02, Folia 22
marzec 2004
Straty na formułowaniu zapytań
 Oprócz zwiększenia złożoności schematu relacyjnego (wskutek fałszywego
dążenia do „prostoty” modelu danych) skutki ograniczonej informacji
semantycznej odbijają się na zapytaniach:
Podaj nazwiska i stanowiska pracowników pracujących w firmach zlokalizowanych w Radomiu:
 SBQL, model obiektowy (21 elementów leksykalnych):
(Firma where ”Radom” Miejsce).
FZ.Zatrudnienie.ZP.Pracownik.(Nazwisko, Stan)
 SQL, model relacyjny (78 elementów leksykalnych):
select s.Nazwisko, w.Stan
from Firma as f, Lokal as k, Zatrudnienie as z,
Pracownik as p, Wyszkolenie as w, Osoba as s
where k.Miejsce = “Radom” and k.NrF = f.NrF
and f.NrF = z.ZF and z.ZP = p.NrP and w.NrP = p.NrP
and p.NrOs = s.NrOs
 Zapytanie w SQL jest dłuższe od zapytania w SBQL głównie wskutek tego, że w
SQL konieczne są predykaty (np. k.NrF = f.NrF) kojarzące informację
semantyczną, która została zgubiona w relacyjnej strukturze danych.
© K.Subieta. Obiektowe języki zapytań 02, Folia 23
marzec 2004
Architektura SZBD dla przetwarzania zapytań
 Historycznie, najbardziej znaną ramową architekturą baz danych jest
propozycja komitetu ANSI SPARC.
 Posiada ona trzy poziomy:
• poziom fizyczny bazy danych,
• poziom pojęciowy wspólny dla wszystkich użytkowników,
• poziom zewnętrzny:
Poziom zewnętrzny
(external)
użytkownik 1
Poziom zewnętrzny
(external)
użytkownik 2
......
Poziom zewnętrzny
(external)
użytkownik n
Poziom pojęciowy (conceptual)
wspólny dla wszystkich użytkowników
Poziom fizyczny
(physical)
© K.Subieta. Obiektowe języki zapytań 02, Folia 24
marzec 2004
Architektura klient-serwer
 Architektura ANSI SPARC została w naturalny sposób rozwinięta w
architekturę klient-serwer.
• Poziom pojęciowy i poziom fizyczny zostały zastąpione przez element
architektoniczny zwany serwerem.
• Z serwerem komunikują się klienci, przy czym każdy z nich ma swój schemat
danych ustalony przez prawa dostępu i perspektywy
Klient 1
Klient 2
Klient n
......
Interfejsy
nasłuchowe
Sieć
Interfejs nasłuchowy
Serwer
Baza danych
© K.Subieta. Obiektowe języki zapytań 02, Folia 25
marzec 2004
Uwarstwowiona architektura klient-serwer
Środowisko rozwoju
oprogramowania
(edytor, kompilator, itd.)
Klient
Wykonywalny kod
aplikacji
Przetwarzanie
zapytań ad hoc i
inne udogodnienia
Interfejs sieciowy
API bazujące na SQL
Interfejs sieciowy
Zarządzanie sesjami i prawami dostępu
Optymalizacja zapytań
Interpreter zapytań/programów
Serwer
Zarzadząnie interpretowanymi obiektami
Zarządzanie transakcjami
Zarządzanie nie-interpretowanymi obiektami
Zarządzanie buforami w pamieci operacyjnej
© K.Subieta. Obiektowe języki zapytań 02, Folia 26
Fizyczna baza danych
marzec 2004
Wady klasycznej architektury C/S
 Zbytnie obciążenie serwera powoduje wąskie gardła. Konieczne jest
przesunięcie przetwarzania na stronę klienta.
 Architektura ta nie pasuje do języka zapytań w pełni zintegrowanego z
językiem programowania.
• W tym przypadku trudno powiedzieć, gdzie kończy się zapytanie, a zaczyna
program aplikacyjny.
• Zapytanie może włączać złożone zmienne lokalne, odwoływać się do
lokalnych klas, wywoływać lokalne metody, procedury, funkcje i
perspektywy, itd.
• Przyjmując, że jednostką komunikacji pomiędzy klientem a serwerem jest
zapytanie i jego wynik, oddzielenie części zapytania wykonywanej na
serwerze i części wykonywanej na kliencie przypomina kwadraturę koła.
 Bardziej odpowiednia architektura dla języka zapytań przesuwa
przetwarzania zapytań na stronę klienta.
 Dla pewnych celów, np. przetwarzania perspektyw (views) przetwarzanie
zapytań powinno także odbywać się na serwerze, ale raczej sporadycznie.
© K.Subieta. Obiektowe języki zapytań 02, Folia 27
marzec 2004
Architektura klient-serwer umożliwiająca integrację
języka zapytań z językiem programowania
Środowisko rozwoju
oprogramowania
(edytor, kompilator, itd.)
Klient
Wykonywalny kod
aplikacji
Przetwarzanie
zapytań ad hoc i
inne udogodnienia
Optymalizacja zapytań
Interpreter zapytań/programów
Interfejs sieciowy
API zleceń do interpretowanych obiektów
Interfejs sieciowy
Zarządzanie sesjami i prawami dostępu
Zarządzanie interpretowanymi obiektami
Serwer
Zarządzanie transakcjami
Przetwarzanie
trwałych
abstrakcji
bazujących na
zapytaniach
Zarządzanie nie-interpretowanymi obiektami
Zarządzanie buforami w pamięci operacyjnej
© K.Subieta. Obiektowe języki zapytań 02, Folia 28
Fizyczna baza danych
marzec 2004
Rozproszona architektura federacyjnej bazy danych (1)
Klient 1
Wykonywalny
kod aplikacji 1
Klient m
...
Udogodnienia
Wykonywalny
kod aplikacji m
Udogodnienia
Przetwarzanie zapytań
Przetwarzanie zapytań
Perspektywa federacyjna 1
Perspektywa federacyjna m
Kanoniczny model
obiektowy oparty
na języku zapytań
Pośrednik bazujący na zapytaniach
Perspektywa 1
Perspektywa n
Przetwarzanie
zapytań
Przetwarzanie
zapytań
Osłona 1
Osłona n
Serwer 1
API 1
Baza Danych 1
Lokalne aplikacje
© K.Subieta. Obiektowe języki zapytań 02, Folia 29
Serwer n
...
API n
W nowym żargonie
podobną architekturę
określa się jako „grid”
(data-intensive grid).
Baza Danych n
Lokalne aplikacje
marzec 2004
Rozproszona architektura federacyjnej bazy danych (2)
 Zasoby wielu serwerów są dostępne dla klienta poprzez mechanizm
składający się z osłony, modułu przetwarzania zapytań oraz perspektywy.
 Osłona przystosowuje lokalne API danego serwera do modelu
kanonicznego i wspólnego języka zapytań.
 Heterogeniczne dane znajdujące się na różnych serwerach są
przystosowane do przetwarzania przy pomocy języka zapytań.
 Perspektywa na danym serwerze przystosowuje obiekty danego serwera
do schematu federacyjnej bazy danych.
 Lokalne aplikacje działające na lokalnym serwerze pozostają bez zmian.
 Po stronie klienta mamy perspektywę, której głównym zadaniem jest
scalenie fragmentów rozproszonych zbiorów (np. obiektów Pracownik
trzymanych na różnych serwerach) w jedną całość.
 Pośrednik w wymianie zleceń i ich rezultatów jest przedstawiony jako
szyna a la CORBA, łącząca klientów i serwery.
 Jest on instalowany na każdej z tych jednostek, a poszczególne kopie tego
pośrednika komunikują się ze sobą za pomocą odpowiedniego protokołu.
© K.Subieta. Obiektowe języki zapytań 02, Folia 30
marzec 2004