KOR12
advertisement
Konstrukcja systemów obiektowych i rozproszonych Wykładowca: Kazimierz Subieta Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa [email protected] Instytut Podstaw Informatyki PAN, Warszawa [email protected] © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 12, Folia 1 Wykład 12: Architektury rozproszonych baz danych, replikacje, transakcje, heterogeniczność, federacyjne bazy danych 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 Obiektowa baza danych XML-owa baza danych © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 12, Folia 2 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. Konstrukcja systemów obiektowych i rozproszonych 12, 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. Konstrukcja systemów obiektowych i rozproszonych 12, 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. Konstrukcja systemów obiektowych i rozproszonych 12, 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. Konstrukcja systemów obiektowych i rozproszonych 12, 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. Konstrukcja systemów obiektowych i rozproszonych 12, 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. Konstrukcja systemów obiektowych i rozproszonych 12, 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. Konstrukcja systemów obiektowych i rozproszonych 12, 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. Konstrukcja systemów obiektowych i rozproszonych 12, 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. Konstrukcja systemów obiektowych i rozproszonych 12, 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. Konstrukcja systemów obiektowych i rozproszonych 12, 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. Konstrukcja systemów obiektowych i rozproszonych 12, 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. Konstrukcja systemów obiektowych i rozproszonych 12, 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. Konstrukcja systemów obiektowych i rozproszonych 12, 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. Konstrukcja systemów obiektowych i rozproszonych 12, 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. Konstrukcja systemów obiektowych i rozproszonych 12, 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. Konstrukcja systemów obiektowych i rozproszonych 12, 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. Konstrukcja systemów obiektowych i rozproszonych 12, 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. Konstrukcja systemów obiektowych i rozproszonych 12, 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. Konstrukcja systemów obiektowych i rozproszonych 12, 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. Konstrukcja systemów obiektowych i rozproszonych 12, 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. Konstrukcja systemów obiektowych i rozproszonych 12, 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 Schemat eksportowy 2 Osłona 2 API 2 Lokalny SZBD 2 BD 2 Aplikacje lokalne © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 12, Folia 24 ... 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. Konstrukcja systemów obiektowych i rozproszonych 12, 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 Schemat eksportowy 2 Osłona 2 API 2 Lokalny SZBD 2 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 12, Folia 26 ... 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. Konstrukcja systemów obiektowych i rozproszonych 12, 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. Konstrukcja systemów obiektowych i rozproszonych 12, 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. Konstrukcja systemów obiektowych i rozproszonych 12, Folia 29 styczeń 2005
