Obiektowe języki zapytań

1. 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 2 Wprowadzenie do języków zapytań (2)

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

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

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

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

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

7. 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ólenie mogą być wyposażone w języki zapytań. • Podobne poglądy do pewnego czasu głosił J. Ullman.

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

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

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

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

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

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

14. Zależności pomiędzy pojęciami języka zapytań Meta-model Model 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 znaczenie danych Dziedzina przedmiotowa, uniwersum rozważań Schemat składu (bazy) danych Bieżący stan składu danych wiedza o strukturach danych potrzeba Zapytanie interpretacja wyniku Wynik zapytania

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

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

17. Schemat składu danych i przykładowy stan składu Osoba [0..*] nazw: string wiek: integer zarobek: integer [0..1] Schemat pracuje w [0..1] zatrudnia [0..*] Firma [0..*] nazwa: string lokacja: string [1..*] i10Osoba i20Osoba i30Firma Jeden z możliwych stanów 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

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

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

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

21. 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. Osoba[0..*] Nazwisko Imię[1..*] Adres[1..*] Firma[0..*] Nazwa Miejsce[1..*] Zatrudnienie[0..*] Wypłata[0..*] Ocena[1..*] Pracownik[0..*] Stan[1..*] FZ[0..*] ZF ZP PZ[0..*]

22. 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) 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) Adresy(NrOs, Adres) Imiona(NrOs, Imię)

23. 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): (Firmawhere ”Radom”Miejsce). FZ.Zatrudnienie.ZP.Pracownik.(Nazwisko, Stan) • SQL, model relacyjny (78 elementów leksykalnych): selects.Nazwisko, w.Stan fromFirmaasf, Lokalask, Zatrudnienieasz, Pracownikasp, Wyszkolenie as w, Osobaas s wherek.Miejsce = “Radom” andk.NrF = f.NrF andf.NrF = z.ZFandz.ZP = p.NrPandw.NrP = p.NrP andp.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.

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

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

26. Uwarstwowiona architektura klient-serwer Środowisko rozwoju oprogramowania (edytor, kompilator, itd.) Klient Przetwarzanie zapytań ad hoc i inne udogodnienia Wykonywalny kod aplikacji Interfejs sieciowy API bazujące na SQL 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 Serwer Fizyczna baza danych

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

28. Architektura klient-serwer umożliwiająca integrację języka zapytań z językiem programowania Środowisko rozwoju oprogramowania (edytor, kompilator, itd.) Przetwarzanie zapytań ad hoc i inne udogodnienia Wykonywalny kod aplikacji Klient 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 Zarządzanie transakcjami Zarządzanie nie-interpretowanymi obiektami Zarządzanie buforami w pamięci operacyjnej Przetwarzanie trwałych abstrakcji bazujących na zapytaniach Serwer Fizyczna baza danych

29. Rozproszona architektura federacyjnej bazy danych (1) Klient 1 Klient m ... Wykonywalny kod aplikacji 1 Wykonywalny kod aplikacji m Udogodnienia 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 W nowym żargonie podobną architekturę określa się jako „grid” (data-intensive grid). Przetwarzanie zapytań Przetwarzanie zapytań Osłona 1 Osłona n API 1 API n Serwer 1 Serwer n Baza Danych 1 Baza Danych n ... Lokalne aplikacje Lokalne aplikacje

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