Obiektowe języki zapytań

© K.Subieta. Obiektowe języki zapytań 02, Folia 1 marzec 2004

Obiektowe języki zapytań

Wykładowca: Kazimierz Subieta

Polsko-Japońska Wyższa SzkołaTechnik Komputerowych, [email protected]

Instytut Podstaw Informatyki PAN, [email protected]

Wykład 2Wprowadzenie do języków zapytań (2)


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



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.



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



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.



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


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.


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.


Niezgodność impedancji (1)

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ą „pod-ję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.

impedance mismatch



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



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



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


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.


Zależności pomiędzy pojęciami języka zapytań

Dziedzina przedmiotowa,

uniwersum rozważań

Model danych Meta-model

Schemat składu (bazy) danych

Bieżący stan składu danych

Zapytanie

wiedza o strukturach danych

Wynik zapytania

znaczenie danych

potrzeba

interpretacja wyniku

Możliwy stan składu danych





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 meta-

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


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.


Osoba [0..*]nazw: stringwiek: integerzarobek: integer [0..1]

Firma [0..*]nazwa: stringlokacja: string [1..*]

pracuje w [0..1]

zatrudnia [0..*]

i10 Osoba

i11 nazw ”Abacki”

i12 wiek 29

i13 zarobek 1900

i14 pracuje w

i20 Osoba

i21 nazw ”Nowak”

i22 wiek 33

i30 Firma

i31 nazwa ”Asko”

i32 lokacja ”Radom”

i33 lokacja „Piła”

i34 zatrudnia

Schemat składu danych i przykładowy stan składu

Schemat

Jeden z możliwych stanów


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.


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


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.


Przykład: schemat prostej obiektowej bazy danych

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.

FZ[0..*]

Osoba[0..*]NazwiskoImię[1..*]Adres[1..*]

ZF PZ[0..*]ZPFirma[0..*]NazwaMiejsce[1..*]

Zatrudnienie[0..*]Wypłata[0..*]Ocena[1..*]

Pracownik[0..*]Stan[1..*]


Przykład: schemat podobnej relacyjnej bazy danych

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.

Firma(NrF, Nazwa)

Lokal(NrF, Miejsce)

Zatrudnienie(NrF, NrP)

Pracownik(NrP, NrOs)

Oceny(NrOceny, Ocena, NrF, NrP)

Dochód(NrDochodu, Wypłata, NrF, NrP)Osoba(NrOs, Nazwisko)

Wyszkolenie(Stan, NrP)

Imiona(NrOs, Imię) Adresy(NrOs, Adres)


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.


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 fizyczny(physical)

Poziom pojęciowy (conceptual)wspólny dla wszystkich użytkowników

Poziom zewnętrzny(external)

użytkownik 1


użytkownik 2


użytkownik n......


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

Baza danych

Serwer

......

Interfejs nasłuchowy

Klient 1 Klient 2 Klient n

Interfejsy nasłuchowe

Sieć


Uwarstwowiona architektura klient-serwer

Fizyczna baza danych

Interfejs sieciowy

Zarządzanie sesjami i prawami dostępu

Optymalizacja zapytań

Interpreter zapytań/programów

Zarzadząnie interpretowanymi obiektami

Zarządzanie transakcjami

Zarządzanie nie-interpretowanymi obiektami

Zarządzanie buforami w pamieci operacyjnej

Środowisko rozwoju oprogramowania

(edytor, kompilator, itd.)

Przetwarzanie zapytań ad hoc i

inne udogodnieniaWykonywalny kod

aplikacji

Klient

Serwer

Interfejs sieciowy

API bazujące na SQL


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.


Architektura klient-serwer umożliwiająca integrację języka zapytań z językiem programowania

Przetwarzanie zapytań ad hoc i

inne udogodnieniaWykonywalny kod

aplikacji

Optymalizacja zapytań

Interpreter zapytań/programów

Interfejs sieciowy

Fizyczna baza danych

Interfejs sieciowy

Zarządzanie sesjami i prawami dostępu

Zarządzanie interpretowanymi obiektami

Zarządzanie transakcjami

Zarządzanie nie-interpretowanymi obiektami

Zarządzanie buforami w pamięci operacyjnej

Środowisko rozwoju oprogramowania

(edytor, kompilator, itd.)

Klient

Serwer

API zleceń do interpretowanych obiektów

Przetwarzanie trwałych abstrakcjibazujących na zapytaniach


Rozproszona architektura federacyjnej bazy danych (1)

...

...

Baza Danych 1

Lokalne aplikacje

API 1

Osłona 1

Serwer 1

Perspektywa 1

Przetwarzanie zapytań

Baza Danych n

Lokalne aplikacje

API n

Osłona n

Serwer n

Perspektywa n


Klient 1

Perspektywa federacyjna 1

Wykonywalny kod aplikacji 1 Udogodnienia


Klient m

Perspektywa federacyjna m

Wykonywalny kod aplikacji m Udogodnienia


Pośrednik bazujący na zapytaniach

Kanoniczny model obiektowy oparty na języku zapytań

W nowym żargonieW nowym żargoniepodobną architekturę podobną architekturę określa się jako „grid” określa się jako „grid” ((data-intensive griddata-intensive grid).).


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.

Obiektowe języki zapytań

Documents

Transcript of Obiektowe języki zapytań