Konstrukcja systemów obiektowych i rozproszonych

Systemy rozproszone (SYR)
Wykładowca: Kazimierz Subieta
Polsko-Japońska Wyższa Szkoła
Technik Komputerowych, Warszawa
[email protected]
Wykład 4:
Replikacje, transakcje,
heterogeniczność, federacyjne
bazy danych
Instytut Podstaw Informatyki PAN,
Warszawa
[email protected]
© K.Subieta. Systemy rozproszone 4, Folia 1
styczeń 2005
Przyszłościowa architektura aplikacji
internetowych
Przeglądarka
WWW
XML
XML
Przeglądarka
WWW
Warstwa
klienta
Serwer Web
Serwer aplikacji
Aplikacja
globalna
Aplikacja
globalna
Warstwa
aplikacji
globalnych
Aplikacja
globalna
Interakcja z aplikacjami poprzez
protokoły oparte na XML
Logiczna
warstwa
pośrednia
Globalny wirtualny
skład zasobów usług i
danych
Web Services
Serwisy
lokalne
Serwisy
lokalne
Serwisy
lokalne
Serwisy
lokalne
Serwisy
lokalne
Zasoby
usług i
danych
Serwisy
lokalne
wrappery
Relacyjna
baza
danych
Obiektoworelacyjna
baza danych
© K.Subieta. Systemy rozproszone 4, Folia 2
Obiektowa
baza danych
XML-owa
baza
danych
Dokumenty
XML na
Webie
Inne dokumenty
na Webie:
HTML, Word,...
Zasoby
danych
styczeń 2005
Standardy łączenia rozproszonych danych (1)
 Open DataBase Connectivity (ODBC): standard [zdalnego] dostępu do
relacyjnych baz danych
• bazuje na Call Level Interface (CLI) opracowanym przez konsorcjum X/Open
• definiuje API oraz cechy SQL które muszą być zapewnione na różnych
poziomach zgodności.
 Java DataBase Connectivity (JDBC): analogiczny do ODBC standard
dla Java.
 OLE-DB: API podobne do ODBC, ale wspomagające źródła niebazodanowe, takie jak płaskie pliki.
• OLE-DB program może negocjować ze źródłem danych aby znaleźć
własności, które ono podtrzymuje.
• API jest podzbiorem SQL
 ADO (Active Data Objects): łatwy interfejs do funkcji OLE-DB
© K.Subieta. Systemy rozproszone 4, Folia 3
styczeń 2005
Standardy łączenia rozproszonych danych (2)
 Kilka standardów bazujących na XML dla E-commerce
• Np. RosettaNet (łańcuchy dostaw), BizTalk
• Definiują katalogi, opisy usług, faktury, zamówienia, itd.
• osłony XML są używane do eksportu informacji z relacyjnej BD do XML
 Resource Description Framework (RDF): specyfikacja ontologii dla
zasobów Web.
 Web Services i Simple Object Access Protocol (SOAP): bazujący na
XML standard dla zdalnego wołania usług. SOAP jest mniej elastyczny i
uniwersalny w stosunku do CORBA.
• Używa XML do zakodowania danych, HTTP jako protokołu transportowego
• Kilka dalszych standardów: WSDL (opis danych i usług), UDDI (rejestry
usług), itd.
• Dalsze standardy są oparte na SOAP dla specyficznych aplikacji, np. OLAP i
Data Mining (standardy Microsoft'u)
© K.Subieta. Systemy rozproszone 4, Folia 4
styczeń 2005
Standardy łączenia rozproszonych danych (3)
 Object Data Management Group (ODMG) standard obiektowych baz
danych
• jest raczej używany hasłowo, nie jest znana całościowa implementacja.
 OMG CORBA (Common Object Request Broker Architecture) najbardziej uniwersalny standard obejmujący ogromną liczbę aspektów.
W szczególności, notacja UML jest jego składową. Pakiety ORB (Object
Request Broker) są oprogramowaniem realizującym tę architekturą.
 .NET/DCOM (Distributed Component Object Model) - standard
Microsoftu zintegrowany z systemami operacyjnymi Microsoftu.
Ograniczony w stosunku do standardu CORBA.
 RMI (Remote Method Invocation) - oprogramowanie firmy Sun,
ograniczone w stosunku do standardu CORBA do oprogramowania
pisanego w Java. Java Beans i Enterprise Java Beans wykorzystują RMI
jako transport.
© K.Subieta. Systemy rozproszone 4, Folia 5
styczeń 2005
Replikacje
Technologia replikacji oznacza przechowywanie dwóch lub więcej kopii
danych (replik) w oddalonych geograficznie miejscach.
Cele:
Zwiększenie dostępności danych poprzez:
- zminimalizowanie czasu i kosztów ich transmisji z odległego miejsca
- rozłożenie obciążenia w zakresie dostępu na wiele kopii danych
Zwiększenie odporności danych na zniszczenie.
Zwiększenie bezpieczeństwa
© K.Subieta. Systemy rozproszone 4, Folia 6
styczeń 2005
Aktualizacja replikacji
Aktualizacja dowolnej kopii danych powinna spowodować jednoczesną
aktualizację wszystkich pozostałych kopii. W idealnym przypadku powinno to
następować jednocześnie, aby zapobiec sytuacji, gdy dane przechowywane w
różnych kopiach są wzajemnie niespójne. Ten ideał nie daje się zrealizować tak
łatwo z kilku powodów:
Czas transmisji zleceń aktualizacyjnych powoduje, że kopie są chwilowo
wzajemnie niezgodne;
Zawodność łączy i węzłów sieci może spowodować czasową niemożliwość
wykonania zlecenia aktualizacyjnego;
Koszt transmisji zleceń aktualizacyjnych może być nieakceptowalny w przypadku
bardzo częstych zmian.
Można wyobrazić sobie sytuację, kiedy każda aktualizacja dowolnej kopii jest
wykonywana w ramach transakcji, która nie będzie potwierdzona aż do momentu
zaktualizowania wszystkich kopii. Takie rozwiązanie w większości przypadków
powoduje jednak znaczne zmniejszenie dostępności danych.
© K.Subieta. Systemy rozproszone 4, Folia 7
styczeń 2005
Modele replikacji
Jednoczesne aktualizacje
ze sterowaniem współbieżnościa
Transakcja aktualizująca
Propagacja aktualizacji
Transakcja aktualizująca
propagacja
aktualizacji
Replika 1
Replika 2
Replika 3
Replika 3
Replika 1
Replika 2
Planowane odświeżanie kopii dla replik tylko do czytania
Transakcja aktualizująca
planowana
aktualizacja
Transakcja czytająca
Replika 3
Replika 1
Transakcja czytająca
© K.Subieta. Systemy rozproszone 4, Folia 8
Replika 2
styczeń 2005
Wady replikacji
 Konieczna dodatkowa przestrzeń dyskowa
 Możliwość powstania niespójności pomiędzy repliką i oryginałem =>
zagrożenie dla spójności procesów biznesowych
• Np. jeżeli dane o wysokości kont są powtórzone w wielu miejscach, wówczas
ktoś korzystając z (celowo) uszkodzonych linii transmisyjnych może dokonać
nielegalnych wypłat.
 Zwiększenie kosztów aktualizacji danych: aktualizacja oryginału pociąga
za sobą dodatkowy koszt aktualizacji replik
• reguła kciuka (bardzo uproszczona):
ilość zapytań czytających
> ilość replik
ilość zleceń aktualizujących
to warto tworzyć repliki.
W przeciwnym przypadku - nie warto.
• Przy dokładnej analizie należy utworzyć bardziej złożone modele kosztów,
które ustalą opłacalność replik.
Jeżeli
© K.Subieta. Systemy rozproszone 4, Folia 9
styczeń 2005
Przetwarzanie transakcji
Problemy z transakcjami w systemach rozproszonych:
 Faza potwierdzenia (commit) może trwać długo. Niepowodzenie
(awaria) w tej fazie może spowodować niespójność bazy danych i
przetwarzania. Stąd nowe protokoły przetwarzania transakcji w systemie
rozproszonym: 2PC, 3PC.
 Zakleszczenie: wykrywanie i usuwanie jest znacznie trudniejsze, gdyż
wymaga przesyłania w sieci informacji która transakcja czeka na którą.
 Ziarnistość mechanizmu transakcji: bezpośrednio związana z
dostępnością rozproszonej bazy danych (liczbą jednocześnie pracujących
użytkowników).
 Wydajność (performance): złożone protokoły powodują jej zmniejszenie;
stąd 2PC i 3PC są często nieadekwatne.
 Długie transakcje: konieczność zmniejszenia poziomu izolacji aby
umożliwić dostęp do zablokowanych danych.
© K.Subieta. Systemy rozproszone 4, Folia 10
styczeń 2005
Implementacja transakcji poprzez zamki
Zamek (lock): jedna z transakcji rezerwuje sobie dostęp do obiektu.
Spójność przetwarzania transakcji jest zachowana, jeżeli cała transakcja ma dwie fazy:
rosnącą i skracającą.
start
potwierdzenie
(commit)
zakładanie zamków
(nie ma zwalniania)
koniec
zwalnianie
zamków (nie
ma zakladania)
czas
Awaria w fazie potwierdzenia jest krytyczna, gdyż grozi utratą spójności.
 W systemach rozproszonych faza potwierdzenia może trwać minuty i włącza
zawodne zawodne elementy infrastruktury (łącza).
 Warunek atomowości oznacza, że jeżeli transakcja dzieli się na wiele
podtransakcji wykonywanych na odległych serwerach, to nie może zajść sytuacja,
gdy podtransakcja na serwerze A jest potwierdzona, zaś podtransakcja na
serwerze B jest zerwana.
 Stąd konieczność dodatkowej ochrony fazy potwierdzenia => 2PC.
© K.Subieta. Systemy rozproszone 4, Folia 11
styczeń 2005
Dwufazowe potwierdzenie (2PC)
Koordynator (program aplikacyjny klienta)
potwierdź
SZBD klienta
SZBD serwera
SZBD serwera
SZBD serwera
1. Serwery wysyłają komunikaty “gotów “ do koordynatora.
2. Po skompletowaniu wszystkich zgłoszeń koordynator wysyła komunikat
“potwierdź” do wszystkich serwerów.
Jeżeli nie nadejdą wszystkie zgłoszenia “gotów”, koordynator wysyła komunikat
“zerwij transakcję” do wszystkich serwerów.
Wada: duże straty wykonanej pracy w przypadku zerwania.
© K.Subieta. Systemy rozproszone 4, Folia 12
styczeń 2005
2PC - zarządzanie awariami
 Dość złożone postępowanie zależne od tego, czy awarii uległ serwer czy
też koordynator.
 Protokół 2PC określa:
• Czas graniczny (timeout) nadesłania sygnału "gotów" od wszystkich
serwerów do koordynatora . Jeżeli czas graniczny minął oraz nie ma
wszystkich sygnałów "gotów", to koordynator wysyła do wszystkich
serwerów sygnał "zerwij".
• Sposób rejestracji sygnałów od koordynatora w dzienniku serwera. W razie
awarii serwera, po jego ponownym postawieniu, analizowany jest dziennik
celem stwierdzenia, czy transakcja ma być potwierdzona, czy zerwana.
 Problem blokowania: w razie awarii koordynatora wszystkie transakcje na
serwerach, które zgłosiły "gotów" są przyblokowane. Serwery "nie
wiedzą", co dalej robić. Postawienie koordynatora może trwać długo.
 Bardziej złożony protokół 3PC uwzględnia awarie koordynatora .
 3PC nie znalazł jednak szerszego zastosowania ze względu na duże
narzuty na wydajność aplikacji.
© K.Subieta. Systemy rozproszone 4, Folia 13
styczeń 2005
Transakcje w federacyjnej bazie danych (1)
 Lokalne transakcje są wykonywane autonomicznie przez lokalny SZBD.
Federacja nic o nich nie wie i (z reguły) nie może się dowiedzieć.
 Globalne transakcje są wykonywane przez aplikacje globalne. Mogą
składać się z wielu podtransakcji, wykonywanych przez lokalne SZBD.
 Z punktu widzenia lokalnego SZBD podtransakcja globalnej transakcji
jest normalną lokalną transakcją.
 W związku z tym, zapewnienie szeregowalności globalnych transakcji
(niezbędny warunek dla utrzymania spójności przetwarzania) w FBD jest
trudne lub wręcz niemożliwe.
 Dlaczego? - następny slajd.
© K.Subieta. Systemy rozproszone 4, Folia 14
styczeń 2005
Transakcje w federacyjnej bazie danych (2)
 Lokalne bazy danych mogą stosować różnorodne algorytmy
przetwarzania transakcji. Autonomia oznacza, że federacja nie ma wpływu
na te algorytmy.
 Lokalna BD może w każdej chwili z różnych powodów (np.
zakleszczenia) zerwać dowolną transakcję, w tym podtransakcję
indukowaną przez globalną transakcję.
 Informacja o wewnętrznym stanie lokalnie przetwarzanych transakcji (np.
stan dziennika transakcji, zamki zakładane przez transakcje, itd.) nie jest
widoczna na zewnątrz.
 Stosowanie typowych algorytmów, np. 2PC (two phase commit) jest
niemożliwe, gdyż lokalna BD może nie posiadać możliwości zawieszenia
podtransakcji w stanie “gotowa” i czekać na sygnał potwierdź ze strony
globalnej transakcji.
© K.Subieta. Systemy rozproszone 4, Folia 15
styczeń 2005
Niezgodności schematów schematic discrepancies
Przy integracji niezależnie zaprojektowanych baz danych w jeden schemat należy się
liczyć z tym, że organizacja, struktura i semantyka danych będzie niezgodna.
Nie istnieje ani “jeden” ani “najlepszy” sposób odwzorowania dziedziny
przedmiotowej w struktury danych zapamiętane w bazie danych. Różni projektanci
projektują całkowicie odmienne struktury dla tego samego problemu.
Dlaczego?
 Obiekty tej samej dziedziny problemowej mogą być widziane przez różnych
projektantów całkowicie odmiennie.
 Systemy zarządzenia BD mają ograniczenia struktur danych, które wymuszają
sposób myślenia projektantów nad koncepcją struktur danych.
 Różne środki manipulacji strukturami dostarczane przez SZBD wymuszają często
różną koncepcję.
 Projektanci podejmują różnorodne decyzje co do koncepcji struktur danych w
związku z zamierzonymi własnościami użytkowymi, np. szybkością dostępu.
© K.Subieta. Systemy rozproszone 4, Folia 16
styczeń 2005
Niezgodności ontologii w rozproszonych BD (1)
Są one poważną przeszkodą, która pojawia się podczas konstruowania
federacyjnych rozproszonych BD.
Niezgodności te dotyczą różnych aspektów organizacji i działania:
 Niezgodności pomiędzy modelami danych: relacyjna vs. obiektowa vs.
hierarchiczna XML-owa, itd.
 Niezgodności pomiędzy schematami pojęciowymi. Np. w jednej BD informacja
o dzieciach pracownika jest atrybutem jego obiektu, zaś w innej jest związkiem
łączącym obiekt pracownika z obiektami osób. W zależności od BD te same dane
mogą występować raz jako nazwy (obiektów, atrybutów), a raz jako ich wartości.
Nawet gdy zespoły stosują tę samą metodykę projektowania, to na ogół ich
projekty pojęciowe są zasadniczo różne.
 Niezgodności pomiędzy schematami logicznymi. Można oczekiwać, że w
niezależnie zbudowanych bazach danych nazwy obiektów, nazwy atrybutów oraz
ich zestaw będą inne. Mogą występować poważniejsze różnice w zakresie
organizacji logicznej; np. w pewnej lokalnej bazie danych informacja o
pracownikach może być rozbita na dwie lub więcej tablic.
© K.Subieta. Systemy rozproszone 4, Folia 17
styczeń 2005
Niezgodności ontologii w rozproszonych BD (2)
 Niezgodności w zakresie interpretacji semantycznej danych. W jednej
bazie danych zarobek pracownika może być zarobkiem brutto, w innej netto, zaś jeszcze w innej może być rozbity na pensję, premię i dodatki.
 Niezgodności dotyczące budowy i środków dostępu do katalogów. W
relacyjnej BD katalog jest zbiorem relacji dostępnym przy pomocy SQL,
w innej bazie katalog może nie istnieć explicite, zaś informacje
katalogowe są dostępne poprzez zmienne środowiskowe oraz specjalne
procedury i funkcje.
 Niezgodności dotyczące reprezentacji danych. W jednej BD informacja
o zawodzie pracownika jest przechowywana na przykład w postaci ciągu
znaków, a w innej przy pomocy numeru zawodu i specjalności, którym
towarzyszy tabela umożliwiająca interpretację (niekoniecznie
przechowywana w BD). Mogą występować różnice w reprezentacji dat,
czasu i innych atrybutów, różnice w zakresie precyzji reprezentacji
wielkości liczbowych oraz zarezerwowanych długości obszarów dla
wartości znakowych, itp.
© K.Subieta. Systemy rozproszone 4, Folia 18
styczeń 2005
Niezgodności ontologii w rozproszonych BD (3)
 Niezgodności dotyczące odniesienia danych do skali czasowej.
Informacje mogą być np. aktualizowane natychmiast, zaś w innej BD raz
na miesiąc.
 Niezgodności w sposobach dostępu. W jednej BD dostęp do danych
będzie realizowany na przykład przy pomocy standardowego SQL, a w
innej poprzez środki dostępu pewnego języka czwartej generacji lub API.
 Różna strukturalizacja informacji. Np. w jednej BD utworzono odrębną
tabelę PrzynależnośćDoZwiązkuZawodowego, zaś w innej ta
przynależność jest atrybutem tabeli Pracownik; w jednej BD atrybut Adres
jest polem tekstowym, w innej zaś strukturą z polami Miejscowość, Ulica,
NrDomu, itd.
 Podział danych i metadane. Np. w jednej BD atrybut Zawód tabeli
Pracownicy jest stringiem, zaś w innej utworzono odrębne tabele.
Piekarze, Stolarze, itd.
Niezgodności jest bardzo dużo. Niezależnie zbudowane lokalne bazy
danych zawsze będą obciążone tego rodzaju konfliktami.
© K.Subieta. Systemy rozproszone 4, Folia 19
styczeń 2005
Kanoniczny model danych
canonical data model
 Jeżeli wiele baz danych ma tworzyć jedną federacyjną bazę danych w
której będzie obowiązywać jeden wspólny API f, wówczas potrzebny jest
model danych w terminach którego dadzą się wyrazić wszystkie inne
modele danych. Model powinien także uwzględniać fakt, że w federacji
mogą pojawić się nowe bazy danych, których założeń nie
rozpatrywaliśmy podczas jej tworzenia.
 Który z modeli danych mógłby być podstawą takiego kanonicznego
modelu danych?
•
•
•
•
•
•
Relacyjny?
Encja-związek?
UML?
CORBA?
ODMG?
Jakiś inny?
© K.Subieta. Systemy rozproszone 4, Folia 20
styczeń 2005
Wybór kanonicznego modelu danych
 Jeżeli nie chcemy debaty religijnej o wyższości modelu A nad B, to
powstaje pytanie o obiektywne kryteria. Czy istnieją?
 Debata nad kanonicznym modelem danych traktuje modele danych jako
obiektywne byty o ostro zarysowanych własnościach i granicach.
 Nie jest to słuszne. Modele danych są tworami subiektywnymi, o
niejasnych granicach, podlegają ciągłej ewolucji, możliwe są różnorodne
ich mutacje i rozszerzenia. Istnieje potencjalnie wiele modeli relacyjnych i
wiele modeli obiektowych.
 Niektóre modele danych są bardzo rozbudowane:
• język zapytań jako składowa modelu
• ograniczenia integralnościowe
• cechy obiektowości określane jak behaviour
 Niektóre są bardzo proste, a reszta jest swobodnie kształtowana:
• np. XML, w istocie ograniczony do prymitywnej konwencji składniowej
© K.Subieta. Systemy rozproszone 4, Folia 21
styczeń 2005
Kryteria wyboru kanonicznego modelu danych
 Ekspresyjność (expressiveness): w jakim stopniu dany model jest w
stanie bezpośrednio odwzorować pojęcia z modelu pojęciowego dziedziny
aplikacyjnej oraz definiować nowe operacje, typy danych i więzy
integralności. Np. model relacyjny nie ma bezpośrednich odwzorowań
złożonych obiektów, dziedziczenia, agregacji, informacji behawioralnych,
itd., wobec czego ma niską ekspresyjność. Pod tym względem model
obiektowy ma przewagę.
 Relatywizm semantyczny (semantic relativism): stopień, w jakim dany
model umożliwia wiele punktów widzenia na tę samą dziedzinę
aplikacyjną. Miarą relatywizmu semantycznego danego modelu jest
możliwość budowania dowolnych schematów zewnętrznych (perspektyw)
nad schematem bazy danych. Model relacyjny posiada pewien stopień
relatywizmu, dzięki jego zdolności definiowania perspektyw
(ograniczonej, szczególnie w zakresie aktualizacji perspektyw).
Definiowanie perspektyw nie jest mocną stroną systemów obiektowych,
jakkolwiek nie istnieją tu ograniczenia koncepcyjne.
© K.Subieta. Systemy rozproszone 4, Folia 22
styczeń 2005
Co to jest Federacyjna Baza Danych?
Federated Database
 Jest to kolekcja heterogenicznych, autonomicznych baz danych,
połączonych siecią komputerową, zarządzana specjalnym systemem
określanym jako Federacyjny System Zarządzania Bazą Danych
(FSZBD).
• Może włączać dziesiątki, setki, tysiące lub więcej lokalnych baz danych.
 FSZBD umożliwia tworzenie aplikacji globalnych, działających na
całości federacyjnej bazy danych. Jest ona zdefiniowana schematem
federacyjnym (schematem kanonicznym) będącym sumą schematów
eksportowych lokalnych baz danych.
 FSZBD zapewnia warunki pracy twórców aplikacji globalnych określane
jako przezroczystość i niezależność danych.
 FSZBD może być zainstalowany w wielu węzłach sieci (m.in. w każdym
lokalnym miejscu FBD), umożliwiając tworzenie aplikacji globalnych w
wielu miejscach geograficznych. Poszczególne FSZBD współpracują ze
sobą celem zapewnienia spójności i integralności przetwarzania.
 Obecnie zamiast terminu FSZBD używa się grid, lub data-intensive grid.
© K.Subieta. Systemy rozproszone 4, Folia 23
styczeń 2005
Architektura federacyjnej bazy danych
Aplikacje globalne
FSZBD
1
Przestrzeń
robocza
Aplikacje globalne
...
Schemat FBD
FSZBD
m
Przestrzeń
robocza
Schemat FBD
Sieć
komputerowa
Schemat eksportowy 1
Osłona 1
API 1
Lokalny
SZBD 1
BD 1
Aplikacje lokalne
© K.Subieta. Systemy rozproszone 4, Folia 24
Schemat eksportowy 2
Osłona 2
API 2
Lokalny
SZBD 2
BD 2
Aplikacje lokalne
...
Schemat eksportowy n
Osłona n
API n
Lokalny
SZBD n
BD n
Aplikacje lokalne
styczeń 2005
Global
schema do lokalnej
External BD
sub-schemata
Architektura
dostępu
(in an extended ODL)
(through an accessibility matrix)
Lokalna baza danych
Lokalny schemat
eksportowy
Zewnętrzne podschematy
użytkowników (macierz dostępu)
Zewnętrzny
podschemat 1
Zewnętrzny
podschemat 2
Zewnętrzny
podschemat 3
Interfejs IA1
Dostęp
Zakaz
Zakaz
Interfejs IA2
Zakaz
Zakaz
Dostęp
Dostęp
Zakaz
Dostęp
Interfejs IC1
Zakaz
Dostęp
Zakaz
Ob.wirt.
VV3
Ob.wirt.
3V
Dane wirt.
1
Perspektywa V1
Zakaz
Dostęp
Dostęp
Ob.wirt.
VV3
Ob.wirt.
3V
Dane wirt.
2
Perspektywa V2
Dostęp
Zakaz
Zakaz
Obiekty A
Obiekty A
Obiekty
Dane B A
Obiekty
Dane C A
API
Osłona
Mediator
Obiekty A
Obiekty A
Obiekty
Dane A A
Interfejs IB1
definiuje
Administrator
lokalnej bazy danych
© K.Subieta. Systemy rozproszone 4, Folia 25
Użytkownik Użytkownik
1
2
Użytkownik
3
styczeń 2005
3-warstwowa architektura federacyjnej BD
3
Użytkownik 1
Użytkownik 2
Użytkownik 3
Schemat zewnętrzny 1
Schemat zewnętrzny 2
Schemat zewnętrzny 3
Schemat federacyjny
2
FSZBD
Przestrzeń
robocza
Sieć
1
Schemat eksportowy 1
Osłona 1
API 1
Lokalny
SZBD 1
BD 1
© K.Subieta. Systemy rozproszone 4, Folia 26
Schemat eksportowy 2
Osłona 2
API 2
Lokalny
SZBD 2
...
BD 2
styczeń 2005
Przetwarzanie zapytań w FBD
 Podstawowe algorytmy przetwarzania zapytań w homogenicznych i
federacyjnych relacyjnych BD są podobne. Różnice dotyczą cech
autonomii i heterogeniczności, które znacznie komplikują problem.
Algorytmy polegają na dekompozycji zapytania na pewne podzapytania
kierowane do lokalnych BD, następnie na skomponowaniu globalnego
wyniku z wyników cząstkowych zwróconych przez lokalne BD.
 Komplikacje
• Niezgodności schematów, które wymagają mechanizmu refleksji lub nowych
operatorów w SQL.
• Brak algorytmicznej uniwersalności SQL.
• Ograniczona moc mechanizmu definiowania perspektyw.
 Problem został rozwiązany dla niektórych przypadków, ale nie dla
generalnego.
• Wygląda na to, ze w ramach obecnych paradygmatów modelu relacyjnego
niewiele więcej da się zrobić.
• W obiektowych bazach danych problem jest na początku drogi.
© K.Subieta. Systemy rozproszone 4, Folia 27
styczeń 2005
Rozproszone BD w standardzie CORBA
Oprogramowanie komponentowe budowane wg standardu CORBA może być
podstawą rozproszonych/federacyjnych baz danych.
Host globalnej aplikacji
Host lokalnej BD
Obiekty
Obiekty
Obiekty
Klient
Wywołanie
operacji
Pieniek
klienta
zlecenie
Implementacja
interfejsów do
obiektów
(szkielety + kod)
Pośrednik (ORB, Object Request Broker)
wynik, parametry wyj
Implementacja interfejsów do obiektów po stronie serwera powstaje ze szkieletu
automatycznie generowanego z wyrażenia IDL, który jest wypełniany kodem operacji.
Taki szkielet pełni jednocześnie funkcję osłony oraz funkcję perspektywy. ORB jest w
stanie zapewnić autonomię lokalnej BD.
© K.Subieta. Systemy rozproszone 4, Folia 28
styczeń 2005
Problemy z RBD w standardzie CORBA
 CORBA nie jest nastawiona na przetwarzanie danych trwałych i
masowych przy pomocy języków zapytań. Jest to poziom języków takich
jak C++ i Java, znacznie niższy. Obecny stan standardyzacji w zakresie
Query Service i Persistence Service jest uważany za niezadowalający.
 CORBA nie wprowadza pojęcia perspektywy. Osłony w CORBA są
pisane w językach niskiego poziomu, są zorientowane na daną aplikację,
nie dają konceptualizacji takiej, jaką dają perspektywy.
 Mogą być znaczne narzuty na wydajność maszynową i produktywność
programistów globalnych aplikacji.
 CORBA nie rozwiązuje problemów związanych z przetwarzaniem
transakcji w rozproszonych/federacyjnych bazach danych.
 Model obiektowy CORBA jest ograniczony, m.in. nie uwzględnia
związków i zagnieżdżonych kolekcji. Te możliwości są uwzględniane w
usługach (np. Relationship Service), które nie są realizowane.
© K.Subieta. Systemy rozproszone 4, Folia 29
styczeń 2005