© 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ła Technik Komputerowych, Warszawa Instytut Podstaw Informatyki PAN, Warszawa Wykład 2 Wprowadzenie do języków zapytań (2)

© K.Subieta. Obiektowe języki zapytań 02, Folia 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 3 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 4 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 5 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 6 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 7 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 8 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 9 marzec 2004 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

© K.Subieta. Obiektowe języki zapytań 02, Folia 10 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 11 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 12 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 13 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 14 marzec 2004 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

© K.Subieta. Obiektowe języki zapytań 02, Folia 15 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 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.

© K.Subieta. Obiektowe języki zapytań 02, Folia 16 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 17 marzec 2004 Osoba [0..*] nazw: string wiek: integer zarobek: integer [0..1] Firma [0..*] nazwa: string lokacja: string [1..*] pracuje w [0..1] zatrudnia [0..*] i 10 Osoba i 11 nazw Abacki i 12 wiek 29 i 13 zarobek 1900 i 14 pracuje w i 20 Osoba i 21 nazw Nowak i 22 wiek 33 i 30 Firma i 31 nazwa Asko i 32 lokacja Radom i 33 lokacja Piła i 34 zatrudnia Schemat składu danych i przykładowy stan składu Schemat Jeden z możliwych stanów

© K.Subieta. Obiektowe języki zapytań 02, Folia 18 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 19 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 20 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 21 marzec 2004 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..*] Nazwisko Imię[1..*] Adres[1..*] ZFZFPZ[0..*]ZPZP Firma[0..*] Nazwa Miejsce[1..*] Zatrudnienie[0..*] Wypłata[0..*] Ocena[1..*] Pracownik[0..*] Stan[1..*]

© K.Subieta. Obiektowe języki zapytań 02, Folia 22 marzec 2004 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 )

© K.Subieta. Obiektowe języki zapytań 02, Folia 23 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 24 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 fizyczny (physical) Poziom pojęciowy (conceptual) wspólny dla wszystkich użytkowników Poziom zewnętrzny (external) użytkownik 1 Poziom zewnętrzny (external) użytkownik 2 Poziom zewnętrzny (external) użytkownik n......

© K.Subieta. Obiektowe języki zapytań 02, Folia 25 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 Baza danych Serwer Interfejs nasłuchowy Klient 1Klient 2Klient n Interfejsy nasłuchowe Sieć

© K.Subieta. Obiektowe języki zapytań 02, Folia 26 marzec 2004 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 udogodnienia Wykonywalny kod aplikacji Klient Serwer Interfejs sieciowy API bazujące na SQL

© K.Subieta. Obiektowe języki zapytań 02, Folia 27 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 28 marzec 2004 Architektura klient-serwer umożliwiająca integrację języka zapytań z językiem programowania Przetwarzanie zapytań ad hoc i inne udogodnienia Wykonywalny 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 abstrakcji bazujących na zapytaniach

© K.Subieta. Obiektowe języki zapytań 02, Folia 29 marzec 2004 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 Przetwarzanie zapytań Klient 1 Perspektywa federacyjna 1 Wykonywalny kod aplikacji 1 Udogodnienia Przetwarzanie zapytań Klient m Perspektywa federacyjna m Wykonywalny kod aplikacji m Udogodnienia Przetwarzanie zapytań Pośrednik bazujący na zapytaniach Kanoniczny model obiektowy oparty na języku zapytań W nowym żargonie podobną architekturę określa się jako grid (data-intensive grid).

© K.Subieta. Obiektowe języki zapytań 02, Folia 30 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.