Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 12, Folia 1 styczeń 2005 Konstrukcja systemów obiektowych i rozproszonych Wykładowca: Kazimierz.

Podobne prezentacje


Prezentacja na temat: "© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 12, Folia 1 styczeń 2005 Konstrukcja systemów obiektowych i rozproszonych Wykładowca: Kazimierz."— Zapis prezentacji:

1 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 12, Folia 1 styczeń 2005 Konstrukcja systemów obiektowych i rozproszonych Wykładowca: Kazimierz Subieta Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa Instytut Podstaw Informatyki PAN, Warszawa Wykład 12: Architektury rozproszonych baz danych, replikacje, transakcje, heterogeniczność, federacyjne bazy danych

2 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 12, Folia 2 styczeń 2005 Przyszłościowa architektura aplikacji internetowych Logiczna warstwa pośrednia Zasoby danych Warstwa klienta XML Przeglądarka WWW Przeglądarka WWW Serwer Web Serwer aplikacji Globalny wirtualny skład zasobów usług i danych Interakcja z aplikacjami poprzez protokoły oparte na XML Obiektowo- relacyjna baza danych Obiektowa baza danych Inne dokumenty na Webie: HTML, Word,... Dokumenty XML na Webie Relacyjna baza danych XML-owa baza danych Serwisy lokalne Zasoby usług i danych wrappery Web Services Aplikacja globalna Warstwa aplikacji globalnych

3 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 12, Folia 3 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 nie- bazodanowe, 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

4 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 12, Folia 4 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)

5 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 12, Folia 5 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.

6 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 12, Folia 6 styczeń 2005 Replikacje Technologia replikacji oznacza przechowywanie dwóch lub więcej kopii danych (replik) w oddalonych geograficznie miejscach. 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 Cele:

7 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 12, Folia 7 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.

8 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 12, Folia 8 styczeń 2005 Modele replikacji Jednoczesne aktualizacje ze sterowaniem współbieżnościa Propagacja aktualizacji Planowane odświeżanie kopii dla replik tylko do czytania Transakcja aktualizująca Replika 1Replika 2Replika 3 Replika 1 Replika 2 Replika 3 Replika 1 Replika 2 Replika 3 propagacja aktualizacji planowana aktualizacja Transakcja czytająca

9 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 12, Folia 9 styczeń 2005 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): Przy dokładnej analizie należy utworzyć bardziej złożone modele kosztów, które ustalą opłacalność replik. Wady replikacji Jeżeli ilość zapytań czytających ilość zleceń aktualizujących > ilość replik to warto tworzyć repliki. W przeciwnym przypadku - nie warto.

10 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 12, Folia 10 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.

11 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 12, Folia 11 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) koniec czas zakładanie zamków (nie ma zwalniania) zwalnianie zamków (nie ma zakladania) 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.

12 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 12, Folia 12 styczeń 2005 Dwufazowe potwierdzenie (2PC) Koordynator (program aplikacyjny klienta) SZBD klienta 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. SZBD serwera gotów potwierdź

13 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 12, Folia 13 styczeń PC - 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.

14 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 12, Folia 14 styczeń 2005 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. Transakcje w federacyjnej bazie danych (1)

15 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 12, Folia 15 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.

16 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 12, Folia 16 styczeń 2005 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? Niezgodności schematów 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. schematic discrepancies

17 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 12, Folia 17 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.

18 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 12, Folia 18 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.

19 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 12, Folia 19 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.

20 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 12, Folia 20 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?

21 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 12, Folia 21 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

22 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 12, Folia 22 styczeń 2005 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. Kryteria wyboru kanonicznego modelu danych

23 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 12, Folia 23 styczeń 2005 Co to jest Federacyjna Baza Danych? 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. Federated Database

24 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 12, Folia 24 styczeń Sieć komputerowa Architektura federacyjnej bazy danych Lokalny SZBD 1 Schemat eksportowy 1 Osłona 1 API 1 BD 1 Aplikacje lokalne FSZBD 1 Przestrzeń robocza Aplikacje globalne Schemat FBD Lokalny SZBD 2 Schemat eksportowy 2 Osłona 2 API 2 BD 2 Aplikacje lokalne Lokalny SZBD n Schemat eksportowy n Osłona n API n BD n Aplikacje lokalne FSZBD m Przestrzeń robocza Aplikacje globalne Schemat FBD...

25 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 12, Folia 25 styczeń 2005 Mediator OsłonaAPI Zewnętrzny podschemat 1 Zewnętrzny podschemat 3 Zewnętrzny podschemat 2 Interfejs IA 1 Interfejs IA 2 Interfejs IB 1 Perspektywa V 1 Perspektywa V 2 Obiekty A Dane A Interfejs IC 1 Ob.wirt. V 3 Dane wirt. V 2 Global schema (in an extended ODL) External sub-schemata (through an accessibility matrix) Dostęp Zakaz Użytkownik 1 Administrator lokalnej bazy danych Użytkownik 3 Użytkownik 2 Architektura dostępu do lokalnej BD Lokalna baza danychLokalny schemat eksportowy Zewnętrzne podschematy użytkowników (macierz dostępu) Obiekty A Dane B Obiekty A Dane C Ob.wirt. V 3 Dane wirt. V 1 ustala definiuje Zakaz

26 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 12, Folia 26 styczeń warstwowa architektura federacyjnej BD Użytkownik 1 Schemat zewnętrzny 1 Użytkownik 2 Schemat zewnętrzny 2 Użytkownik 3 Schemat zewnętrzny 3 FSZBD Przestrzeń robocza Schemat federacyjny Sieć Lokalny SZBD 1 Schemat eksportowy 1 Osłona 1 API 1 BD 1 Lokalny SZBD 2 Schemat eksportowy 2 Osłona 2 API 2 BD

27 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 12, Folia 27 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.

28 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 12, Folia 28 styczeń 2005 Rozproszone BD w standardzie CORBA Oprogramowanie komponentowe budowane wg standardu CORBA może być podstawą rozproszonych/federacyjnych baz danych. Host globalnej aplikacji Klient Wywołanie operacji Host lokalnej BD Pośrednik (ORB, Object Request Broker) 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. Pieniek klienta Implementacja interfejsów do obiektów (szkielety + kod) zlecenie wynik, parametry wyj Obiekty

29 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 12, Folia 29 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.


Pobierz ppt "© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 12, Folia 1 styczeń 2005 Konstrukcja systemów obiektowych i rozproszonych Wykładowca: Kazimierz."

Podobne prezentacje


Reklamy Google