Rozproszone i federacyjne bazy danych Wykadowca Kazimierz Subieta

Rozproszone i federacyjne bazy danych 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 © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 1 marzec 2002

Plan wykładu ] Wprowadzenie do systemów rozproszonych ] Pojęcia związane z rozproszeniem ] Obiektowość w systemach rozproszonych ] Projektowanie rozproszonych baz danych ] Architektury rozproszonych baz danych ] Replikacje ] Przetwarzanie transakcji ] Niezgodności schematów i ontologii ] Federacyjne bazy danych ] Osłony i mediatory ] Perspektywy ] Przetwarzanie zapytań ] Podsumowanie © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 2 marzec 2002

Wykład 1 © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 3 marzec 2002

Wprowadzenie do systemów rozproszonych © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 4 marzec 2002

Co to jest system rozproszony? ] Systemem rozproszonym nazywamy taki system, w którym przetwarzanie informacji odbywa się na wielu komputerach, często znacznie oddalonych geograficznie (od kilku metrów do dziesiątków tysięcy kilometrów). Przeciwieństwem jest system izolowany lub scentralizowany. ] Obecnie właściwie wszystkie systemy (poza domowymi komputerami) są rozproszone. Ogromnym katalizatorem rozproszenia systemów jest Internet. Komputer z Internetem można już uważać za system rozproszony. ] Projektowanie i własności systemów rozproszonych w dużej mierze są takie same jak systemów scentralizowanych, ale istnieją także istotne różnice, który specjalista inżynierii oprogramowania musi być świadomy. ] Tendencja do budowy systemów rozproszonych jest pochodną rozbudowy tanich, szybkich, uniwersalnych i niezawodnych sieci komputerowych. ] Przykłady systemów rozproszonych: sieć bankomatów, system rezerwacji biletów, system pracy grupowej, itd. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 5 marzec 2002

Zalety systemów rozproszonych (1) ] Podział zasobów: system rozproszony pozwala dzielić zasoby sprzętowe i programowe (pamięci dyskowe, drukarki, pliki, kompilatory, itd. ) pomiędzy wielu użytkowników pracujących na różnych komputerach pracujących w sieci. ] Otwartość: jest ona definiowana jako zdolność systemu do dołączania nowego sprzętu, oprogramowania i usług. Otwarte systemy często mają tę zdolność również w stosunku do w/w zasobów ulokowanych na platformach sprzętowych i systemach operacyjnych dostarczanych przez różnych dostawców. ] Współbieżność: w systemie rozproszonym wiele procesów może działać w tym samym czasie na różnych komputerach w sieci. Procesy te mogą (jakkolwiek nie muszą) komunikować się podczas swego działania. ] Skalowalność: Moc i możliwości przetwarzania może wzrastać w miarę dodawania do systemu nowych zasobów, w szczególności komputerów. W praktyce skalowalność jest często ograniczona poprzez przepustowość sieci oraz (niekiedy) poprzez np. specyficzne protokoły wymiany informacji. Niemniej skalowalność systemu rozproszonego jest nieporównywalnie lepsza w stosunku do systemu scentralizowanego. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 6 marzec 2002

Zalety systemów rozproszonych (2) ] Tolerancja błędów: Dostępność wielu komputerów oraz umożliwienie zdublowania informacji (replikacje) oznacza, że rozproszony system jest tolerancyjny w stosunku do pewnych błędów zarówno sprzętowych jak i programowych. Np. awaria węzła komunikacyjnego powoduje wygenerowanie innej trasy przepływu informacji. ] Przezroczystość: Oznacza ukrycie przed użytkownikiem szczegółów rozproszenia, np. gdzie ulokowane są zasoby lub jak są one fizycznie zaimplementowane, pod jakim systemem pracują, itd. Przezroczystość ma zasadnicze znaczenie dla komfortu działania użytkownika oraz dla niezawodności budowanego oprogramowania. Niekiedy, np. dla celów optymalizacyjnych, użytkownik może zrezygnować z pełnej przezroczystości. Przykładem przezroczystości jest Internet: klikając w aktywne pole na stronie WWW nie interesujemy się, gdzie znajduje się odpowiadająca mu strona, oraz jak i na czym jest zaimplementowana. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 7 marzec 2002

Wady systemów rozproszonych ] Złożoność: systemy rozproszone są trudniejsze do zaprogramowania i do administrowania niż systemy scentralizowane. Zależą od własności sieci, np. jej przepustowości i czasu transmisji, co utrudnia zaprojektowanie i zrealizowanie wielu algorytmów i procesów przetwarzania. ] Ochrona: Dla systemu scentralizowanego wystarcza w zasadzie strażnik z karabinem. System rozproszony nie może być chroniony w ten sposób, przez co może być narażony na różnorodne ataki (włamania, wirusy, sabotaż, odmowa płatności, itd. ) z wielu stron, które trudno zidentyfikować. ] Zdolność do zarządzania: jest ona utrudniona wskutek tego, że konsekwencje różnych działań administracyjnych w systemie rozproszonym są trudniejsze do zidentyfikowania. Podobnie z przyczynami sytuacji anormalnych, w szczególności awarii. ] Nieprzewidywalność: system rozproszony jest nieprzewidywalny w swoim działaniu, ponieważ zakłócenia mogą być powodowane przez wiele przyczyn: małą przepustowość i awarię łączy, awarię komputerów, zbyt duże obciążenie danego serwera, lokalne decyzje administracji serwera, itd. ; patrz WWW. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 8 marzec 2002

Krytyczne zagadnienia projektowe dla systemów rozproszonych ] Identyfikacja zasobów: zasoby w systemie rozproszonym są podzielone pomiędzy wiele komputerów, w związku z czym schematy ich nazywania muszą być zaprojektowane tak, aby użytkownicy mogli zidentyfikować interesujące ich zasoby. Przykładem takiego schematu jest URL (Uniform Resource Locator) znany z WWW. ] Komunikacja: może być zaprojektowana w sposób uniwersalny, na bazie np. protokołu internetowego TCP/IP lub któregoś protokołu pochodnego (ftp, http, itd. ). Niektóre wymagania dotyczące szybkości, kosztu, niezawodności lub bezpieczeństwa mogą prowadzić do specjalnych technik komunikacyjnych. ] Jakość obsługi: odzwierciedla wydajność systemu, jego dostępność i niezawodność. Podlega ona wielu czynnikom, w szczególności, przypisaniu zadań do procesorów, optymalności geograficznego podziału danych, itd. ] Architektura oprogramowania: opisuje ona w jaki sposób funkcjonalności systemu są przypisane do logicznych i fizycznych komponentów systemu. Wybór dobrej architektury przesądza o spełnieniu kryterium jakości obsługi. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 9 marzec 2002

Popularne architektury rozproszenia ] Klient-serwer: rozproszony system ma wyróżniony węzeł zwany serwerem, oraz szereg podłączonych do niego węzłów zwanych klientami. Związek nie jest symetryczny: serwer wykonuje usługi zlecane przez klientów, nie może im odmówić i nie może im zlecić wykonanie usług. ] Klient-multi-serwer: podobnie jak dla architektury klient-serwer, ale istnieje wiele serwerów. Przykładem jest WWW. ] Koleżeńska (peer-to-peer, P 2 P): wiele węzłów świadczy sobie wzajemne usługi poprzez bezpośrednie połączenie; nie ma wyraźnego podziału na usługodawców i usługobiorców. Przykładem jest Gnutella, NXOR, w mniejszym stopniu Napster ma centralne sterowanie. Komercyjny buzz dookoła P 2 P. ] Architektura oparta na oprogramowaniu pośredniczącym (middleware): nie występuje podział na klientów i serwery. Węzły komunikują się poprzez specjalne oprogramowanie pośredniczące, które zakłada wspólny (przezroczysty dla użytkowników) protokół komunikacyjny. Przykładem jest CORBA (rozproszone obiekty), . NET/COM/DCOM, Java Beens/RMI, SOAP, . . . © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 10 marzec 2002

Co to jest rozproszona baza danych? distributed database Termin ten jest powtarzany w wielu kontekstach, często bez przypisywania mu konkretnego, technicznego znaczenia. Czy to, że z pewnego systemu można dostać się do danych innego odległego systemu jest wystarczającym wyróżnikiem rozproszonej bazy danych? ] Dla wielu zastosowań cecha ta jest istotna, lecz ] Rozproszona baza danych musi spełniać określone kryteria dotyczące spójności, bezpieczeństwa, zintegrowania i wygody użytkowników. ] Możliwość dostania się do danych innego systemu (np. poprzez pakiety oparte o standardy ODBC, JDBC, DCOM lub CORBA) oznacza wyłącznie ustanowienie niezbędnej bazy technicznej. Fakt ten nie przesądza jednak o tym, czy zachodzą dostateczne warunki dla sprawnego, efektywnego oraz niezawodnego wykorzystywania danych. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 11 marzec 2002

Podstawowe pojęcia związane z rozproszeniem ] Rozproszona baza danych: zbiór składający się z wielu logicznie ze sobą powiązanych elementów bazy danych, oddalonych geograficznie i połączonych ze sobą poprzez sieć komputerową. ] System zarządzania rozproszoną bazą danych (SZRBD): oprogramowanie umożliwiające połączenie rozproszonych zasobów w jedną całość, utrzymanie spójność zasobów oraz udostępnianie ich użytkownikom przy założeniu przezroczystości rozproszenia. ] Dane są przechowywane w wielu miejscach - węzłach sieci. ] Rozproszona baza danych jest bazą danych, a nie kolekcją plików, które mogą być indywidualnie przechowywane w każdym węźle sieci komputerowej. ] SZRBD posiada pełną funkcjonalność systemu zarządzania scentralizowaną BD. Nie jest to system zarządzania rozproszonymi plikami, ani też wyłącznie system przetwarzania transakcji. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 12 marzec 2002

Przykład rozproszonej bazy danych Rozproszona baza danych dla linii lotniczych (biuro obsługi klienta w Warszawie może dostać się do danych linii lotniczych w Sydney, Tokio, Paryżu, i setkach innych miast). Jeżeli w każdym miejscu organizacja bazy danych, środki manipulacji, reguły dostępu, itd. byłyby inne, to praca byłaby bardzo utrudniona. Zatem konieczne są: ] standardy w zakresie połączenia (protokoły), ] standardy w zakresie organizacji danych i dostępu do danych, ] moduły dla odwzorowania pewnej specyficznej bazy danych na format oczekiwany przez danego klienta, ] przezroczystość rozproszenia (a la CORBA), ] zabezpieczenia przed niepowołanym dostępem. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 13 marzec 2002

Klasyfikacja rozproszonych baz danych Systemy wielu baz danych (multidatabases) Niefederacyjne rozproszone BD Jednorodne BD Rozproszone BD z globalnym schematem Federacyjne BD Słabo skojarzone (loosely coupled) Niefederacyjne BD: brak autonomii. Słabo skojarzone FBD: brak federacyjnego schematu i zarządzania, operacje ad hoc, w zależności od aplikacji. Ściśle skojarzone (tightly coupled) Pojedyncze federacje (pojedynczy schemat) Wielokrotne federacje (wiele schematów) Ściśle skojarzone FBD: FSZBD jest odpowiedzialny za zarządzanie całością federacji. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 14 marzec 2002

Tematy związane z rozproszonymi BD (1) ] Architektury rozproszonego przetwarzania: bazy danych oparte o architekturę klient-serwer, bazy danych oparte o schemat globalny. ] Federacyjne bazy danych - (przezroczyste) połączenie wielu (relewantnych części) heterogenicznych i autonomicznych baz danych w jedną całość. ] Przetwarzanie transakcji w rozproszonych bazach danych; globalne transakcje, lokalne transakcje, dwufazowe i trójfazowe potwierdzenie (two -phase commit, 2 PC). ] Długie transakcje, wymagające osłabienia poziomu izolacji i minimalizujące ryzyku utraty już wykonanej pracy. ] Współdziałanie heterogenicznych, autonomicznych, rozproszonych (Heterogeneous, Autonomous, Distributed, HAD) baz danych (określane także jako współdziałanie multi baz danych, multidatabase interoperability). © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 15 marzec 2002

Tematy związane z rozproszonymi BD (2) ] Replikacje, czyli utrzymywanie kopii danych w wielu miejscach w rozproszonych bazach danych. ] Rozproszone przetwarzanie zapytań; optymalizacja zapytań w sytuacji rozproszenia zasobów. ] Systemy operacyjne dla podtrzymywania rozproszenia: OSF DCE i inne systemy oparte o wołanie odległej procedury (Remote Procedure Call, RPC). ] Podtrzymywanie różnych form niewidoczności rozproszenia (distribution transparency) dla programistów i klientów baz danych. ] Standardy w zakresie rozproszenia: OMG CORBA, DCOM firmy Microsoft, RMI i Java Beans, Open. Doc, Active. X, SOAP/XML. Pośrednicy (broker, ORB) wg standardu CORBA, np. Orbix, Visibroker, . . . © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 16 marzec 2002

Tematy związane z rozproszonymi BD (3) ] Środki wspomagające rozproszenie bazy danych i rozproszone przetwarzanie zrealizowane w konkretnych systemach relacyjnych (Oracle, Sybase, Ingres, i inne), post-relacyjnych lub obiektoworelacyjnych (Informix Universal Server, DB 2 Universal Database, Oracle 8, Uni. SQL/X, OSMOS, Open. Ingres, Sybase Adaptive Server i inne) oraz obiektowych (Gemstone, Versant, O 2, Objectivity/DB, Object. Store i inne). ] Niezawodność, spójność, bezpieczeństwo i prywatność w rozproszonych bazach danych. ] Rozproszone bazy danych w sieciach Internet oraz Intranet. ] Rozproszenie danych i przetwarzania w systemach pracy grupowej oraz systemach zarządzania przepływem pracy. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 17 marzec 2002

Rozproszone BD: relacyjne czy obiektowe? ] Prace prowadzone nad rozproszonymi BD (w ciągu ostatnich 20 -tu lat), były oparte głównie o relacyjny model danych. ] Zaletami modelu relacyjnego jest prosta, ujednolicona struktura danych oraz prosta organizacja katalogów bazy danych. ] W ostatnich latach obserwuje się odchodzenie od modelu relacyjnego w stronę modeli obiektowych. ] Złożoność samego problemu rozproszenia danych jest prawdopodobnie niezależna od modelu danych. ] Niektóre metody systemów relacyjnych związane z rozproszeniem dają się przenieść na grunt systemów obiektowych. ] Problemy nowe: metamodel (ontologia), przetwarzania zapytań. ] W przeciągu najbliższych 10 -ciu lat obiektowość będzie odgrywać główną rolę w rozwijaniu koncepcji rozproszonych baz danych, w różnych wariantach, np. XML/RDF. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 18 marzec 2002

Reguły rozproszenia © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 19 marzec 2002

Reguły rozproszonych baz danych (1) (C. J. Date, 1987) 12 reguł: w praktyce spełnienie wszystkich jest trudne lub niemożliwe. Jest to spekulacyjny ideał. ] Autonomia lokalnych BD: lokalne dane powinny podlegać lokalnym regułom własności i powinny być zarządzane lokalnie. Dotyczy to funkcji związanych z bezpieczeństwem, integralnością i reprezentacją wewnątrz pamięci. Wyjątki dotyczą sytuacji, kiedy więzy integralności muszą obejmować jednocześnie wiele miejsc oraz sytuacji, kiedy rozproszone transakcje muszą być sterowane przez pewne zewnętrzne miejsce. ] Brak podporządkowania przetwarzania do konkretnego miejsca: uniknięcie wąskich gardeł dzięki decentralizacji wszystkich funkcji rozproszonego SZBD. ] Ciągłość funkcjonowania: Przestoje w wykonywaniu operacji nie powinny być skutkiem dodania nowych miejsc, ich usunięcia ze środowiska rozproszonej BD, dokonania zmian w meta-informacji lub unowocześnienia wersji SZBD w pewnym indywidualnym miejscu. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 20 marzec 2002

Reguły rozproszonych baz danych (2) ] Niezależność od lokalizacji: Użytkownicy lub programy aplikacyjne nie muszą wiedzieć, gdzie dane są fizycznie przechowywane. ] Niezależność od fragmentacji: Fragmenty jednego zbioru danych mogą być przechowywane i zarządzane przez rozproszony SZBD jako jedna całość, bez uświadamiania użytkowników lub aplikacji o sposobie ich rozczłonkowania. Pożądaną własnością rozproszonego SZBD jest to, aby w sposób automatyczny unikał przetwarzania nierelewantnych fragmentów. • Np. jeżeli grupa obiektów jest podzielona geograficznie ze względu na atrybuty w ten sposób, że atrybuty A 1. . . Am są w miejscu X, zaś atrybuty Am+1. . . An są w miejscu Y, i konkretne zapytanie odwołuje się wyłącznie do atrybutów A 1. . . Am, należy pominąć odwołania do miejsca Y podczas realizacji tego zapytania. • Podobnie, fragmenty tej samej tabeli w różnych miejscach rozproszonej bazy danych powinny być widocznej jako jedna tabela. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 21 marzec 2002

Reguły rozproszonych baz danych (3) ] Niezależność od replikacji: Istnienie replik danych w wielu miejscach, ich pojawianie się lub usuwanie powinno wpływać na postępowanie użytkowników ani na poprawność bądź spójność aplikacji. ] Rozproszone przetwarzanie zapytań: System powinien zapewniać sprawne przetwarzanie rozproszonych zapytań umożliwiające zredukowanie zarówno czasu przetwarzania, jak i obciążenia sieci transmisji danych. ] Zarządzanie rozproszonymi transakcjami: Zasady zarządzania transakcjami oraz sterowania współbieżnością powinny obowiązywać dla operacji w rozproszonej bazie danych. Zasady te włączają: wykrywanie i usuwanie zakleszczeń (deadlocks), zarządzanie przekroczeniami dopuszczalnego czasu (timeout), rozproszone protokóły potwierdzenia (commit) i odwracania (rollback), oraz inne metody. ] Niezależność od sprzętu: oprogramowanie rozproszonego SZBD powinno pracować na różnych platformach sprzętowych. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 22 marzec 2002

Reguły rozproszonych baz danych (4) ] Niezależność od systemu operacyjnego: oprogramowanie rozproszonego SZBD powinno pracować pod różnymi systemami operacyjnymi. ] Niezależność od sieci: Miejsca mogą być połączone poprzez szeroką gamę środowisk sieciowych i komunikacyjnych. Modele warstwowe istniejące dla współczesnych protokółów komunikacyjnych (obowiązujące w większości obecnych systemów informacyjnych, takich jak OSI 7, TCP/IP, warstwy SNA i DECnet) zapewniają środki do osiągnięcia tego celu nie tylko dla rozproszonych baz danych, lecz w ogólności dla systemów informacyjnych. ] Niezależność od SZBD: Powinno być możliwe przyłączenie do rozproszonej bazy danych lokalnej bazy danych zarządzanej przez dowolny lokalny SZBD. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 23 marzec 2002

Reguła: niezależność od centralnego miejsca ] Rozproszona baza danych nie może zależeć od jednego, centralnego miejsca odpowiedzialnego za całość funkcjonowania. • Zależność taka może "wkraść się" niepostrzeżenie, jako konsekwencja pewnych (wydawałoby się drugorzędnych) decyzji projektowych, np. powołanie jednego serwera nazw, lub rejestracja nowych miejsc przyłączających się do rozproszonej bazy danych. ] Zależność taka jest niekorzystna, gdyż: • Centralne miejsce może stać się wąskim gardłem dla operacji na danych • Awaria centralnego miejsca powoduje awarię całej rozproszonej bazy danych. ] Dla niektórych zastosowań brak centralnego miejsca jest niekorzystny: • z powodu nadmiernego wzrostu obciążenia sieci związanego z wymianą metadanych; • z powodu zbyt niskiej wydajności (indeksy w jednym miejscu) • z powodów biznesowych: centralne miejsce jest wygodne dla kontrolowania pozostałych miejsc. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 24 marzec 2002

Nazwy elementów danych w rozproszonych BD ] Problem nazywania i identyfikacji danych w rozproszonych BD staje się znacznie bardziej trudny niż w scentralizowanych BD. ] Kryteria zarządzania nazwami: • 1. Każda dana, która ma być niezależnie identyfikowana w systemie rozproszonym, musi mieć swoją unikalną nazwę (identyfikator). • 2. Nazwa powinna zapewniać efektywne odszukanie lokalizacji danej. • 3. Nazwa nie powinna utrudniać zmiany lokalizacji danej. • 4. Każde lokalne miejsce w rozproszonej BD powinno mieć możliwość autonomicznego nadawania unikalnych nazw dla danych. ] Centralny serwer nazw - nadaje wszystkie nazwy, udziela informacji o lokalizacji nielokalnych danych na podstawie ich nazw: • nie spełnia warunku 4, • może powodować wąskie gardło dla transakcji, • jest pojedynczym powodem awarii całości. ] Rozwiązanie: prefiksowanie nazwy identyfikatorem miejsca - trudności ze zmianą lokalizacji danych (przy zachowaniu tożsamości). © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 25 marzec 2002

Pojęcia związane z rozproszeniem © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 26 marzec 2002

Główne aspekty rozproszenia baz danych (1) Przezroczystość (transparency) Rozproszony SZBD powinien podtrzymywać rozproszenie danych przy założeniu odizolowania programisty/użytkownika od większości aspektów rozproszenia. Współdziałanie (interoperability) Oznacza współpracę zbudowanych niezależnie od siebie heterogenicznych systemów (heterogeneous systems). Aspektem współdziałania jest przyłączenie do rozproszonej BD starych systemów, tzw. spadkowych (legacy) Przenaszalność (portability) Własność języka programowania i jego kompilatorów/interpreterów umożliwiająca przenoszenie programów na różne platformy. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 27 marzec 2002

Główne aspekty rozproszenia baz danych (2) Autonomia (autonomy) Lokalne bazy danych podlegają własnym lokalnym regułom. Tylko określona część lokalnych zasobów i usług jest udostępniana na zewnątrz. Niezależność danych (data independence) Możliwość projektowania, utrzymywania, udostępniania, zmiany nośników, zmiany reprezentacji, itp. działań na danych niezależnie od programów, które na nich operują. Ontologia (ontology), często w kontekście "ontologia biznesowa" Formalny opis wszystkich tych własności lokalnej bazy danych, które są niezbędne do tego, aby projektant/programista mógł prawidłowo zaprogramować nową aplikację (np. mobilnego agenta). Niekiedy ontologia jest określana jako metadane. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 28 marzec 2002

Przezroczystość (1) Rozproszona BD musi spełniać warunki komfortu pracy programistów, administratorów i użytkowników, jak również niezawodności, bezpieczeństwa danych, zwiększenie odporności na błędy programistów. To oznacza konieczność redukcji złożoności przy pracy z rozproszoną bazą danych, co jest określane jako „przezroczystość”. Ma ona następujące formy: ] Przezroczystość położenia: Umożliwienie jednorodnych metod operowania na lokalnych i odległych danych. Tego warunku nie spełnia np. system, w którym lokalna baza danych jest obsługiwana przez pewien język 4 GL, zaś odległa - przez specjalny zestaw procedur (API). ] Przezroczystość dostępu: Uwolnienie użytkowników od konieczności(a niekiedy również uniemożliwienie) korzystania z informacji o aktualnym położeniu danych. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 29 marzec 2002

Przezroczystość (2) ] Przezroczystość współbieżności: Umożliwia wielu użytkownikom jednoczesny dostęp do danych bez konieczności uzgodnień i porozumiewania się, przy zapewnieniu pełnej spójności danych i przetwarzania. ] Przezroczystość skalowania: Umożliwienie dodawania nowych elementów bazy danych bez wpływu na działanie starych aplikacji i pracę użytkowników. ] Przezroczystość replikacji: Umożliwienie tworzenia i usuwania kopii danych w innych miejscach geograficznych z bezpośrednim skutkiem dla efektywności przetwarzania, ale bez skutków dla postaci programów użytkowych lub pracy użytkownika końcowego. ] Przezroczystość wydajności: Umożliwienie dodawania nowych elementów systemu komputerowego (np. serwerów, dysków) bez wpływu na pracę większości użytkowników rozproszonej bazy danych. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 30 marzec 2002

Przezroczystość (3) ] Przezroczystość fragmentacji (podziału): automatyczne scalanie obiektów, tabel lub kolekcji, których fragmenty są przechowywane w różnych miejscach. ] Przezroczystość awarii: Umożliwienie nieprzerwanej pracy większości użytkowników rozproszonej bazy danych w sytuacji, gdy niektóre z jej węzłów lub linie komunikacyjne uległy awarii. ] Przezroczystość migracji: Umożliwienie przenoszenia zasobów danych do innych miejsc bez wpływu na pracę użytkowników. W praktyce spełnienie wszystkich wymienionych warunków jest ideałem, który prawdopodobnie został zrealizowany w żadnym ze znanych systemów. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 31 marzec 2002

Współdziałanie i heterogeniczność interoperability, heterogeneity ] Umożliwienie współdziałania heterogenicznych systemów baz danych jest drugim ważnym aspektem rozproszenia. ] Heterogeniczność jest nieodłączną cechą dużych sieci komputerowych, takich jak Internet, WWW, sieci intranetowych, rozproszonych baz danych, systemów przepływu prac, zasobów WWW opartych na plikach HTML i XML, itd. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 32 marzec 2002

Heterogeniczność (niejednorodność) ] Np. system Intranetowy może składać się ze sprzętu: • • • komputerów klasy mainframe stacji roboczych UNIX komputerów PC pracujących pod MS Windows komputerów Apple Macintosh central telefonicznych, robotów, zautomatyzowanych linii produkcyjnych ]. . . włączać różnorodne protokoły komunikacyjne: Ethernet, FDDI, ATM, TCP/IP, Novell Netware, protokoły oparte na RPC, . . . ]. . . bazować na różnych systemach zarządzania bazą danych/dokumentów: Oracle, SQL Server, DB 2, Lotus Notes, . . ]. . . oraz wymieniać pomiędzy sobą niejednorodne dane, podlegające różnym modelom danych, schematom, semantyce, mechanizmom dostępu, . . . © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 33 marzec 2002

Przyczyny heterogeniczności ] Niezależność działania: wytwórcy systemów nie uzgadniają między sobą ich cech. Standardy, o ile się pojawiają, są spóźnione, niekompletne i nie przestrzegane w 100%. ] Konkurencja: wytwórcy systemów starają się wyposażyć systemy w atrakcyjne cechy, których nie posiadają konkurujące systemy ] Różnorodność pomysłów: Nie zdarza się, aby było jedno rozwiązanie dla złożonego problemu. Różne zespoły znajdują różne rozwiązania, bazujące często na odmiennych celach i założeniach. ] Efektywność finansowa i kompromisy: Wytwórcy oferują produkty o różnej cenie, funkcjonalności i jakości, zgodnie z wyczuciem potencjalnych potrzeb klientów, dostosowaniem się do ich portfela i maksymalizacją swoich zysków. ] Systemy spadkowe (legacy): Systemy, które dawno zostały wdrożone i działają efektywnie, nie mogą być z tego działania wyłączone. Nie jest możliwe (lub jest bardzo kosztowne) zastąpienie ich nowymi systemami. Nowe systemy, o podobnym przeznaczeniu, posiadają inne założenia, cechy i funkcjonalności © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 34 marzec 2002

Przenaszalność portability Typy przenaszalności: • Na poziomie składni, koncepcji języka i edukacji (np. SQL-92). • Na poziomie kodu źródłowego (np. C++ (? ), JDBC). • Na poziomie interpretowanego kodu skryptowego lub pośredniego (np. Java). • Na poziomie kodu binarnego (? - trudno podać przykład). ] Przenaszalność wymaga precyzyjnej specyfikacji składni i semantyki języka, oraz wyeliminowania z niego własności specyficznych dla poszczególnych platform. ] Wiele standardów nie spełnia kryterium przenaszalności z powodu niedospecyfikowania i/lub nie spełniania standardu przez wytwórców systemów. ] Przenaszalność jest celem standardów SQL, CORBA oraz ODMG, niekoniecznie celem już osiągniętym. ] Przenaszalność realizuje kod pośredni języka Java, ale dotyczy to funkcjonalności niskiego poziomu, np. nie dotyczy API do baz danych. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 35 marzec 2002

Autonomia autonomy Autonomia lokalnej bazy danych w federacji baz danych oznacza, że: ] Lokalne dane podlegają lokalnym priorytetom, regułom własności, autoryzacji dostępu, bezpieczeństwa, itd. Lokalna baza danych może odrzucić zlecenia przychodzące z federacji, o ile naruszają one lokalne ograniczenia lub zbytnio obciążają czas procesora lub inne lokalne zasoby. ] Lokalna baza danych może udostępniać aplikacjom działającym na federacji baz danych tylko określoną część swoich danych i usług. Programiści tych aplikacji nie mają jakichkolwiek środków dostępu do pozostałych danych i usług. ] Włączenie lokalnej bazy danych do federacji nie może powodować konieczności zmiany programów aplikacyjnych działających na lokalnej BD. ] Federacja może przetwarzać lokalne zasoby tylko poprzez interfejs programowania aplikacji (API) specyficzny dla lokalnego systemu. Inne metody (np. bezpośredni dostęp do plików) są niedozwolone. ] Federacja nie może żądać od lokalnej bazy danych zmiany/rozszerzenia jej usług (np. udostępnienia lokalnego dziennika transakcji). Możliwa jest pewna skala autonomii. Pojęcie autonomii jest raczej intuicyjne. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 36 marzec 2002

Wykład 2 © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 37 marzec 2002

Niezależność danych data independence Oznacza, że nie ma potrzeby zmiany kodu programów aplikacyjnych mimo zmian organizacji lub schematów danych. Jest osiągana poprzez interfejsy programistyczne umożliwiające dostęp do danych na odpowiednim poziomie abstrakcji, gdy niewidoczne są szczegóły organizacji i implementacji danych. ] Fizyczna niezależność danych: ukrycie detali organizacji fizycznej i technik dostępu, dzięki czemu możliwa jest ich zmiana bez wpływu na kod aplikacji. ] Logiczna niezależność danych: umożliwienie niektórych zmian schematu logicznego bez wpływu na kod aplikacji, np. dodanie atrybutów do relacji, zmiana kolejności atrybutów, zmiana ich typów, utworzenie nowych relacji, itd. ] Ewolucja schematu (schema evolution): umożliwienie daleko idących zmian schematu danych przy jednoczesnym utworzeniu perspektyw (views) dla starych lub nowych danych. Perspektywy mają umożliwić minimalną pracochłonność przy zmianach aplikacji (idealistycznie). © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 38 marzec 2002

Ontologia ontology ] W filozofii: nauka o bytach, teoria bytu, opis charakteru i struktury rzeczywistości, specyfikacja konceptualizacji. ] W sztucznej inteligencji: formalna specyfikacja (przy użyciu logiki matematycznej) obiektów, pojęć i innych bytów, które istnieją w pewnej dziedzinie, oraz formalna specyfikacja związków, które pomiędzy tymi bytami zachodzą. • Podejście sztucznej inteligencji jest naiwne. • Np. Giełda Papierów Wartościowych: wiele tysięcy stron aktów prawnych, zarządzeń, regulacji, itd. Jako (dożywotnia) kara dla sztucznego (ćwierć-) inteligenta wypisującego bzdury na temat "formalnej ontologii": niech to zapisze przy użyciu formuł rachunku predykatów. ] W biznesie (ontologia biznesowa, business ontology): wszystko to, co projektanci systemów informatycznych powinni wiedzieć o biznesie, aby poprawnie napisać aplikacje wspomagające ten biznes. Wiedza ta powinna być formalnie zapisana. "Formalnie" oznacza zwykle pewien standardowy i uzgodniony język, np. XML/RDF. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 39 marzec 2002

Ontologia i metadane ] Głównym celem prac na biznesową ontologią jest standardyzacja następujących elementów: • Gramatyki opisów poszczególnych bytów, • Nazw i znaczeń nazw obowiązujących w ramach danego biznesu (np. co oznaczają słowa "autor", "klient", "instrument", "akcja", itd. ), • Ograniczeń związanych z opisywanymi bytami, • Metadanych związanych z bytami (autor opisu, data stworzenia opisu, data ostatniej aktualizacji, itd. ), • Dopuszczalnych operacji na bytach. ] W tym zakresie zapis ontologii jest pewną meta-bazą danych, w które ustala się zarówno strukturę samej bazy danych, jak i pewne dodatkowe informacje (meta-atrybuty) będące podstawą przetwarzania bazy danych. ] Nieco inne podejście prezentuje standard RDF opracowany przez W 3 C, gdzie ontologię reprezentują wyrażenia RDF. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 40 marzec 2002

Metadane ] Metadane są kluczowe dla wielu rozproszonych aplikacji, ponieważ umożliwiają rozpoznanie z zewnętrz własności lokalnego zasobu danych ] Ogólna definicja: są to dane o danych - co dane zawierają, jaką mają budowę, jakie jest ich znaczenie, jakim podlegają ograniczeniom, jak są zorganizowane, przechowywane, zabezpieczane, udostępniane, itd. ] Metadane są pewnym rozszerzeniem pojęcia schematu bazy danych, albo też pewną implementacją tego schematu w postaci katalogów. ] Metadane przykrywają także informację niezależną od treści samych danych, np. kiedy pewna dana została utworzona, w jakim jest formacie, kto jest jej autorem, do kiedy jest ważna, itd. ] Opisy danych zawarte w metadanych mają dwie podstawowe zalety: • Zawierają wspólne abstrakcje dotyczące reprezentacji danych, takie jak format; ogólnie "wyciągają przed nawias" wszystkie wspólne informacje, co redukuje znacznie objętość samych danych; • Reprezentują wiedzę dziedzinową (ontologię); umożliwiają wnioskowanie o danych, mogą być przez to użyte do redukowania dostępu do samych danych. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 41 marzec 2002

Klasyfikacja metadanych ] Metadane niezależne od treści danych: lokacja danych, data modyfikacji, typ kamery służącej do sporządzenia zdjęcia, itd. Mimo, że nie składają się bezpośrednio na treść danych, mogą być ważnym kryterium wyszukiwania. ] Metadane zależne od treści danych: rozmiar dokumentu, liczba kolorów, liczba wierszy, liczba kolumn w tabeli. Metadane zależne od treści mogą być dalej podzielone na: • Bezpośrednie metadane dotyczące treści, np. indeksy, klasyfikacje, itd. • Metadane opisujące treść: adnotacje o zawartości zdjęcia, np. opis zapachu kwiatu przedstawionego na zdjęciu. • Metadane niezależne od dziedziny biznesowej, której dotyczy treść, np. definicje typu dokumentu HTML/SGML • Metadane zależne od dziedziny biznesowej, np. schemat danych lub opis ontologii biznesowej ] Podział na dane i metadane nie jest do końca jasny i silnie zależy od nastawienia projektanta i podziału zadań podczas redakcji treści danych. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 42 marzec 2002

Protokół wymiany informacji w rozproszonej BD ] Protokół wymiany informacji pomiędzy rozproszonymi miejscami musi uwzględniać: • przesyłanie danych z jednego miejsca do drugiego miejsca • przesyłanie zleceń (np. zapytań) do odległych miejsc celem przetwarzania danych • zwrotne przesyłanie wyników tych zleceń do zlecającego klienta • automatyczną dystrybucję niektórych metadanych (np. schematu BD) pomiędzy uczestników rozproszonej bazy danych. • przesyłanie zapytań dotyczących metadanych • przekazywanie wyników zapytań dotyczących metadanych do pytającego ] Aktualnie, protokoły takie istnieją w bardzo uproszczonej lub silnie wyspecjalizowanej formie • IIOP (Internet Inter-Orb Protocol) - bardzo uproszczony • LDAP (Lightweight Directory Access Protocol) - silnie wyspecjalizowany ] Wiele ośrodków prowadzi prace badawcze nad uniwersalnymi protokołami, opartymi o różnorodne języki zapytań. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 43 marzec 2002

Migracje obiektów Migracja: przemieszczanie się obiektów między węzłami sieci, przy czym obiekty muszą być skojarzone (statycznie lub dynamicznie związane) ze swoimi klasami i przechowywanymi w ramach tych klas metodami. Problemy: ] Określenie jednostki migracji ] Śledzenie obiektów ] Utrzymywania porządku w katalogu systemu bazy danych ] Okresowa kondensacja łańcuchów obiektów pośrednich ] Przemieszczanie obiektów złożonych ] Zapewnienie globalnej przestrzeni nazw ] Zapewnienie właściwych mechanizmów zakresu i wiązania ] Dostępność metod umożliwiających przetwarzanie obiektów Jak dotąd, metody są najczęściej składowymi aplikacji, a nie bazy danych. Konsekwencją jest to, że po przemieszczeniu obiektu aplikacja działająca w jego nowym miejscu musi mieć wbudowane (powielone, skompilowane, zlinkowane) metody do jego przetwarzania. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 44 marzec 2002

Oprogramowanie komponentowe Komercyjny buzzword, niezrealizowane marzenie informatyków od 30 lat. Oznacza technologie zmierzające do budowy standardów oraz wspomagającego je oprogramowania, które pozwoliłoby na składanie dużych aplikacji lub systemów z mniejszych standardowych części komponentów, na zasadzie podobnej do składania komputera z podzespołów. Inne terminy: mega-programming, programming-in-the-large. Jako przykłady wymienia się teraz: OMG CORBA, Open. Doc firm Apple, IBM i innych, technologia. NET/COM/DCOM, Java Beans i Enterprise Java Beans. Komponenty mają wiele sukcesów. Istnieją jednak problemy utrudniające szerokie ich stosowanie ] problemy z osiągnięciem akceptowalnej wydajności, ] trudności w precyzyjnym a jednocześnie dostatecznie abstrakcyjnym wyspecyfikowaniu interfejsów pomiędzy komponentami, ] dynamiczny postęp w informatyce, powodujący pojawianie się coraz to nowych wymagań na interfejsy. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 45 marzec 2002

Obiektowość w systemach rozproszonych © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 46 marzec 2002

Obiektowość w rozproszonych bazach danych ] Obiektowość zakłada zwiększenie stopnia abstrakcji, przystosowanie modeli realizacyjnych systemów informatycznych do naturalnych konstrukcji i obrazów myślowych projektantów, programistów i użytkowników. ] Główny problem - opanowanie złożoności przy wytwarzaniu oprogramowania. ] Punktem zainteresowania twórców narzędzi informatycznych stają się procesy myślowe zachodzące w umysłach osób pracujących nad oprogramowaniem => modelowanie pojęciowe. ] Obiektowość przerzuca ciężar problemu z kwestii narzędziowej (jak mam to zrobić? ) na kwestię merytoryczną (co mam zrobić i po co? ). © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 47 marzec 2002

Źródła złożoności projektu oprogramowania Zespół projektantów Dziedzina problemowa, obejmująca ogromną liczbę wzajemnie uzależnionych aspektów i problemów. Środki i technologie informatyczne: sprzęt, oprogramowanie, sieć, języki, narzędzia, udogodnienia. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 48 Oprogramowanie: decyzje strategiczne, analiza, projektowanie, konstrukcja, dokumentacja, wdrożenie, szkolenie, eksploatacja, pielęgnacja, modyfikacja. podlegający ograniczeniom pamięci, percepcji, wyrażania informacji i komunikacji. Potencjalni użytkownicy: czynniki psychologiczne, ergonomia, ograniczenia pamięci i percepcji, skłonność do błędów i nadużyć, tajność, prywatność. marzec 2002

Jak walczyć ze złożonością ? Zasada dekompozycji: rozdzielenie złożonego problemu na podproblemy, które można rozpatrywać i rozwiązywać niezależnie od siebie i niezależnie od całości. Zasada abstrakcji: eliminacja, ukrycie lub pominięcie mniej istotnych szczegółów rozważanego przedmiotu lub mniej istotnej informacji; wyodrębnianie cech wspólnych i niezmiennych dla pewnego zbioru bytów i wprowadzaniu pojęć lub symboli oznaczających takie cechy. Zasada ponownego użycia: wykorzystanie wcześniej wytworzonych schematów, metod, komponentów projektu, komponentów oprogramowania, itd. wzorców, Zasada sprzyjania naturalnym ludzkim własnościom: dopasowanie modeli pojęciowych i modeli realizacyjnych systemów do wrodzonych ludzkich własności psychologicznych, instynktów oraz mentalnych mechanizmów percepcji i rozumienia świata. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 49 marzec 2002

Modelowanie pojęciowe Projektant i programista muszą dokładnie wyobrazić sobie problem oraz metodę jego rozwiązania. Zasadnicze procesy tworzenia oprogramowania zachodzą w ludzkim umyśle i nie są związane z jakimkolwiek językiem programowania. Pojęcia modelowania pojęciowego (conceptual modeling) oraz modelu pojęciowego (conceptual model) odnoszą się procesów myślowych i wyobrażeń towarzyszących pracy nad oprogramowaniem. Modelowanie pojęciowe jest wspomagane przez środki wzmacniające ludzką pamięć i wyobraźnię. Służą one do przedstawienia rzeczywistości opisywanej przez dane, procesów zachodzących w rzeczywistości, struktur danych oraz programów składających się na konstrukcję systemu. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 50 marzec 2002

Perspektywy w modelowaniu pojęciowym odwzorowanie . . . Percepcja rzeczywistego świata Analityczny model rzeczywistości . . . . Model struktur danych i procesów SI Trwałą tendencją w rozwoju metod i narzędzi projektowania oraz konstrukcji SI jest dążenie do minimalizacji luki pomiędzy myśleniem o rzeczywistym problemie a myśleniem o danych i procesach zachodzących na danych. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 51 marzec 2002

Przykład: pojęciowy schemat obiektowy w UML Osoba Nazwisko Imię * Adres * Pracownik Zawód * 0. . * PZ 1 Zatrudnienie Wypłata * 0. . * Ocena * FZ Firma Nazwa 1 Miejsce * Nie więcej niż 10 sekund zastanawiania się, co ten diagram przedstawia i jak jest semantyka jego elementów. Potem można już programować np. w C++ lub Java. Co otrzymamy po odwzorowaniu tego schematu na schemat relacyjny? © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 52 marzec 2002

Schemat relacyjny Firma(Nr. F, Nazwa) Zatrudnienie(Nr. F, Nr. P) Lokal(Nr. F, Miejsce) Pracownik(Nr. P, Nr. Os) Oceny(Nr. Oceny, Ocena, Nr. F, Nr. P) Dochód(Nr. Dochodu, Wypłata, Nr. F, Nr. P) Osoba(Nr. Os, Nazwisko) Wyszkolenie(Zawód, Nr. P) Imiona(Nr. Os, Imię) Adresy(Nr. Os, Adres) Jest to jedno z kilku możliwych rozwiązań. Schemat relacyjny jest trudniejszy do odczytania i zinterpretowania przez programistę. Będzie on musiał co najmniej 10 minut zastanawiać się, co ten diagram reprezentuje i jaką semantykę mają atrybuty i zaznaczone powiązania. Efektem jest zwiększona skłonność do błędów (mylnych interpretacji). © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 53 marzec 2002

Skutki niezgodności modelu pojęciowego i relacyjnego Programy odwołujące się do schematu relacyjnego są dłuższe od programów odwołujących się do schematu obiektowego (szacunkowo od 30% do 70%). Ma to ogromne znaczenie dla tempa tworzenia oprogramowania, jego jakości, pielęgnacyjności, itd. Programy te są też zwykle znacznie wolniejsze. Mini przykład: Podaj adresy pracowników pracujących w firmach zlokalizowanych w Radomiu SBQL: (Firma where ”Radom” in Miejsce). FZ. Zatrudnienie. PZ. Pracownik. Adres SQL: select a. Adres from Lokal as k, Zatrudnienie as z, Pracownik as p, Osoba as s, Adresy as a where k. Miejsce = “Radom” and k. Nr. F = z. Nr. F and z. Nr. P = p. Nr. P and p. Nr. Os = s. Nr. Os and s. Nr. Os =a. Nr. Os Zapytanie w SQL jest znacznie dłuższe wskutek tego, że w SQL konieczne są „złączeniowe” predykaty (takie jak k. Nr. F=z. Nr. F i następne) kojarzące informację semantyczną "zgubioną" w relacyjnej strukturze danych. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 54 marzec 2002

Rozproszone obiektowe bazy danych ] Problemy są podobne jak w przypadku rozproszonych relacyjnych BD. ] Nie jest jednak pewne czy do przetwarzania zapytań w tych systemach będą się odnosić te same metody. ] Problemy, różniące przetwarzanie zapytań w rozproszonych obiektowych BD i w rozproszonych relacyjnych BD: • Obiekty nie zawsze są implementowane jako "płaskie" zapisy. • Obiekty mogą mieć referencje do obiektów zlokalizowanych w innych węzłach sieci. • Przetwarzanie zapytań może dotyczyć kolekcji złożonych obiektów • Zapytania mogą mieć odwołania do metod. ] Przetwarzanie zapytań w rozproszonych systemach obiektowych jest tematem bardzo istotnym. Standard ODMG tym się nie zajmuje. ] Jak dotąd, w zakresie przetwarzania rozproszonych zapytań nie rozwiązano podstawowych problemów koncepcyjnych. ] Niektóre z problemów © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 55 mogą nie mieć ogólnego rozwiązania. marzec 2002

Rozproszona obiektowa baza danych Przedmiotem przetwarzania i wymiany informacji w obiektowej rozproszonej bazie danych są obiekty. Zarządzanie rozproszonymi obiektami ma na celu utrzymywanie spójności i przezroczystości (niewidoczności) geograficznego rozproszenia obiektów. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 56 marzec 2002

Zalety rozproszonych obiektów ] Zgodność z logiką biznesu - bezpośrednia implementacja obiektów biznesowych. ] Umożliwienie projektantom opóźnienie decyzji - gdzie i jakie usługi powinny być zapewnione. ] Skalowalność aplikacji: mała zależność czasu reakcji systemu od zwiększenia ilości danych, liczby użytkowników, liczby węzłów. ] Dekompozycja aplikacji na małe elementy wykonawcze (obiekty, metody, . . . ). ] Przyrostowe dodawanie/odejmowanie funkcjonalności (“płacę tylko za to, czego używam”). ] Podział zasobów i zbalansowanie obciążeń. ] Współbieżność i asynchroniczne przetwarzanie. ] Elastyczność zmian w oprogramowaniu (konserwacja), w szczególności, przenoszenie obiektów i usług do innych miejsc. ] Możliwość przyłączania aplikacji spadkowych (funkcjonujących wcześniej jako scentralizowane). © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 57 marzec 2002

Projektowanie rozproszonych baz danych © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 58 marzec 2002

Podejścia do projektowania rozproszonych BD: top-down i bottom-up Od ogółu do szczegółów: top-down bottom-up Odgórne zaprojektowanie całej bazy danych, z uwzględnieniem optymalizacji przechowywanych danych, narzuconej przez fakt geograficznego rozproszenia producentów i konsumentów informacji przechowywanej w bazie danych. Od szczegółów do ogółu: Zintegrowanie już istniejących (spadkowych) lub zaprojektowanych lokalnych baz danych w jedną globalną rozproszoną bazę danych. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 59 marzec 2002

Projektowanie: podejście top-down Analiza Model pojęciowy scentralizowany Analiza systemowa: rozpoznanie wymagań, precyzowanie kontekstu przyszłej bazy danych. Projektowanie schematu pojęciowego Projektowanie struktury logicznej Model logiczny scentralizowany Modele logiczne dla poszczególnych miejsc © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 60 Kryteria rozproszenia są związane z faktem fizycznego rozproszenia źródeł i odbiorców danych oraz autonomii lokalnych baz danych. Ustalają one decyzje, które fragmenty projektu pojęciowego będą przechowywane w poszczególnych miejscach, a marzec 2002 także jak należy zdekomponować

Dalsze fazy postępowania w podejściu top-down Określenie danych podlegających replikacjom (lokalnych kopii) oraz strategii replikacji. Zróżnicowanie logicznego schematu danych w zależności od typu SZBD w poszczególnych miejscach. Określenie lokalnych schematów dla poszczególnych miejsc. Określenie danych autonomicznych dla poszczególnych miejsc, nie uczestniczących w rozproszonej bazie danych; co prowadzi do określenia schematu pojęciowego i logicznego dla danych widzianych z zewnątrz. Podział schematu logicznego: Wg różnych reguł związanych na ogół z fizycznym ulokowaniem obiektów rzeczywistych (np. osób zatrudnionych, sprzętu, co pociąga za sobą odpowiedni podział schematu logicznego) lub też z fizycznym ulokowaniem programów aplikacyjnych działających na tych obiektach. marzec 2002 © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 61

Podstawowe metody fragmentacji schematu ] Fragmentacja pionowa oznacza przyporządkowanie poszczególnych klas obiektów do poszczególnych miejsc, lub rozbicie obiektów danej klasy na dwa lub więcej podobiektów, przy czym takie podobiekty są przechowywane w różnych miejscach. ] Fragmentacja pionowa może oznaczać konieczność odpowiedniego podziału informacji zawartych w klasach obiektów oraz ustalenia środków podtrzymania jednoznacznej tożsamości obiektów. ] Fragmentacja pozioma oznacza rozbicie populacji obiektów danej klasy na dwa lub więcej miejsc geograficznych. ] Fragmentacja pozioma może być dokonywana na podstawie różnych kryteriów, które często wiązane są z geograficznym ulokowaniem obiektów rzeczywistych, lub też z geograficznym ulokowaniem przetwarzania tych obiektów. marzec 2002 © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 62

Fragmentacja pionowa relacyjnej bazy danych Warszawa Kutno DC DOSTAWCA_DANE DNR CNR ILOŚĆ DNR NAZW STATUS D 1 D 2 D 3 D 4 D 5 Abacki Bober Czerny Dąbek Erbel 20 10 30 20 30 Sieć Gdańsk DOSTAWCA_MIASTO DNR D 1 D 2 D 3 D 4 D 5 © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 63 MIASTO Lublin Poznań Lublin Radom D 1 D 1 D 1 D 2 D 3 D 4 D 4 C 1 C 2 C 3 C 4 C 5 C 6 C 1 C 2 C 2 C 4 C 5 300 200 400 200 100 300 400 200 300 400 marzec 2002

Fragmentacja pozioma relacyjnej bazy danych DOSTAWCA Poznań DNR NAZW STATUS MIASTO D 2 Bober D 3 Czerny 10 Poznań 30 Poznań DC DNR CNR ILOŚĆ D 2 D 3 C 1 C 2 300 400 200 Lublin DOSTAWCA Sieć DNR NAZW STATUS MIASTO D 1 Abacki D 4 Dąbek 20 Lublin DC DOSTAWCA Radom DNR NAZW STATUS MIASTO D 5 Erbel 30 Radom © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 64 DNR CNR ILOŚĆ D 1 D 4 C 6 C 2 C 4 100 200 300 marzec 2002

Fragmentacja pionowa obiektów Pracownik Radom Klasa danych osobistych Nowak dane osobiste Kowalski dane osobiste . . . Kalisz Sieć Nowak dane o ocenach Kraków Nowak dane o zatrud. Klasa danych o ocenach Kowalski dane o ocenach . . . Klasa danych o zatrudnieniu Kowalski dane o zatrud. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 65 . . . marzec 2002

Fragmentacja pozioma obiektów Pracownik Radom Klasa Pracownik Nowak Pracownik Kowalski Obiekty Pracownik są przechowywane zgodnie z geograficznym położeniem pracodawcy. . Kalisz Sieć Pracownik Styka Kraków Pracownik Malasa Klasa Pracownik Malina . . . Klasa Pracownik Zagórny. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 66 . . . marzec 2002

Inne fragmentacje danych w rozproszonej BD ] Możliwe są inne, bardziej złożone fragmentacje danych, które łączą fragmentacje pionowe, fragmentacje poziome oraz redundantne dane (replikacje). ] Bardziej złożone fragmentacje rodzą trudności z: • zarządzaniem metadanymi: gdzieś muszą być ulokowane informacje odnośnie tego w jaki sposób podzielone dane mają być scalone w kompletne obiekty lub kolekcje w ramach rozproszonej bazy danych. Jest to rola metadanych oraz mechanizmu właściwej dystrybucji metadanych pomiędzy uczestników rozproszonej bazy danych. • przetwarzaniem zapytań: dekompozycja zapytania na pod-zapytania adresowane do poszczególnych miejsc staje się znacznie bardziej kłopotliwa. Przesyłanie fragmentów obiektów celem ich zmaterializowania po stronie klienta może być zbyt kosztowne. ] Bardziej złożone fragmentacje mogą być nie do uniknięcia w rozproszonej bazie danych integrującej istniejące bazy danych (podejście bottom-up). Ma to konsekwencje dla zarządzania metadanymi. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 67 marzec 2002

Projektowanie: podejście bottom-up ] Podejście ad hoc: Budowa uniwersalnych lub specyficznych dla danego zastosowania pomostów (gateways) umożliwiających dostęp z danego systemu bazy danych do innych baz danych. Pomost może (nie musi) zapewniać przezroczystość rozproszenia. ] Podejście oparte o globalny schemat: Wszystkie składniki rozproszonej BD są objęte jednym globalnym schematem, jednakowym dla każdego miejsca i zapewniającym przezroczystość rozproszenia. Istotną wadą podejścia opartego na globalnym schemacie jest brak możliwości sterowania zakresem autonomii każdego lokalnego systemu. ] Federacyjna baza danych: Każda lokalna baza danych zachowuje swoją autonomię, udostępniając tylko część danych dla innych miejsc w RBD. Podejście federacyjne zakłada, że każda lokalna baza danych jest widziana poprzez © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 68 marzec 2002

Federacyjna BD tworzona metodą bottom-up Aplikacje globalne Aplikacjeglobalne Schemat federacyjnej bazy danych Perspektywa Mediator Osłona Schemat lokalny 1 Miejsce 1 Aplikacje lokalne Schemat lokalny 2 Miejsce 2 Baza danych 1 Aplikacje lokalne Baza danych 2 . . . Podejście federacyjne okazało się skuteczne ze względu na zapewnienie autonomii, bezpieczeństwa i efektywności. Rodzi jednak dużo problemów, m. in. z zapewnieniem jednolitej ontologii biznesowej, uniwersalnością aplikacji, wydajnością, itd. marzec 2002 © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 69

Wykład 3 © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 70 marzec 2002

Architektury rozproszonych baz danych © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 71 marzec 2002

Architektura klient-serwer Całość pracy wykonywanej przez system komputerowy jest podzielona na dwie części: wykonywaną po stronie klienta (zwykle związaną z interakcją z użytkownikiem) wykonywaną po stronie serwera (komunikacja, dostęp do bazy danych, zarządzanie repozytoriami pamięci, zarządzanie globalną przestrzenią nazw) Określenie mechanizmu komunikacji pomiędzy klientem a serwerem. Podstawowe problemy: Podział funkcji na te, które są wykonywane po stronie klienta i te, które są wykonywane po stronie serwera Określenie jednostki komunikacji klient - serwer © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 72 marzec 2002

Reguły architektury klient-serwer (1) ] Zachowanie autonomii serwera. Klienci powinni zachowywać reguły wykorzystania serwera, nie powinni powodować jego niedostępność (np. zamykać duże ilości danych), nie powinni łamać ograniczeń integralności. ] Zachowanie autonomii klienta. Klienci nie powinni zachowywać się różnie w zależności od tego, czy serwer jest lokalny czy odległy. Powinni być odizolowani od kwestii fizycznego ulokowania danych. ] Wspomaganie dla aplikacji niezależnych od serwera. ] Dostęp do własności (danych, usług) serwera. Klienci mogą żądać od serwera wykonanie przewidzianych dla niego funkcji. ] Wspomaganie dla bieżącego dostępu do danych. Dostęp ten powinien być bezpośredni, bez pośrednictwa plików przekazywanych do/od klienta. ] Minimalny wpływ architektury K/S na wymagania dla klienta. Oprogramowanie klienta w architekturze K/S nie powinno wykazywać znacznego zwiększenia zapotrzebowania na RAM lub objętość dysku. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 73 marzec 2002

Reguły architektury klient-serwer (2) ] Kompletność opcji niezbędnych do połączenia. Oprogramowanie klienta nie powinno zawierać kodu realizującego połączenie z serwerem. Powinien to zapewniać serwer komunikacyjny. ] Możliwość budowy lokalnych prototypów. Programista powinien mieć możliwość budowy i testowania aplikacji K/S wyłącznie na stacji klienta. ] Kompletność narzędzi użytkownika końcowego. Projektowanie ekranów, generacja zapytań, itd. powinny być częścią środowiska. ] Kompletność środowiska budowy aplikacji. Powinno przewidywać możliwość łączenia się w sieci, dostęp do usług globalnych w zakresie nazw, lokacji danych, itd. ] Otwarte środowisko języka-gospodarza. Powinno zapewniać możliwość użycia uniwersalnego języka programowania do budowy aplikacji. ] Szczególna troska o standardy. Im bardziej będą one przestrzegane, tym mniej będzie późniejszych kłopotów ze współdziałaniem. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 74 marzec 2002

Przykład architektury SZBD typu klient-serwer Aplikacja generująca transakcje Zarządzanie transakcjami Zarządzanie buforami . . . Zarządzanie buforami Zarządzanie zasobami Klient 1 Klient n Zarządzanie siecią Interfejs serwera Zarządzanie zasobami Zarządzanie transakcjami Zarządzanie logiem Zarządzanie buforami Zarządzanie zamkami Serwer © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 75 marzec 2002

Architektura klient-(multi) serwer (1) Połączenia bezpośrednie: k 2 k 3 k 7 k 1 k 4 k 5 s 4 s 1 k 8 s 3 s 2 k 9 k 6 k 10 k 11 © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 76 marzec 2002

Architektura klient-(multi) serwer (2) Połączenia poprzez sieć: nie ma bezpośrednich połączeń, zarówno serwery jak i klienci są przyłączani w jednakowy sposób do wspólnej sieci komputerowej. k 2 k 3 k 1 s 4 k 9 k 4 Sieć komputerowa s 1 k 8 s 3 k 5 k 6 © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 77 s 2 k 7 marzec 2002

Architektura trzywarstwowa i wielowarstowa ] Architektura klient-serwer podzielona na trzy warstwy: • interfejs użytkownika, • logikę przetwarzania (reguły biznesu, logikę biznesu) three-tier architecture multi-tier architecture Interfejs użytkownika • serwer (serwery) bazy danych. ] Warstwy są zaprojektowane i istnieją niezależnie, co ma duże znaczenie dla pielęgnacyjności systemu ze względu na możliwość zmian w dowolnej warstwie bez konieczności zmian w pozostałych warstwach. ] Często warstwy są zrealizowane na odrębnych platformach: interfejs na MS Windows, logika przetwarzania na serwerze aplikacji i baza danych na serwerze bazy danych. ] Środkowa warstwa może składać się z wielu warstw, co jest określane jako architektura wielowarstwowa. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 78 Logika przetwarzania Serwer bazy danych marzec 2002

Logiczna architektura oprogramowania Architektura klient-serwer powinna odzwierciedlać logiczny podział oprogramowania na części. Nie jest to tak istotne w systemie scentralizowanym. Architektura trójwarstwowa: cienki klient Warstwa prezentacyjna (interfejs użytkownika) gruby klient Warstwa przetwarzania (logika biznesu) Warstwa zarządzania bazą danych © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 79 Staranne rozdzielenie tych warstw jest bardzo istotne z punktu widzenia tworzenia i modyfikowalności oprogramowania. Dzięki temu rozdzieleniu, możliwa jest np. poprawa interfejsu użytkownika bez jakichkolwiek interwencji w pozostałe warstwy oprogramowania. Zasada oddzielania aspektów (separation of concerns principle, E. Dijkstra) marzec 2002

Cienki i gruby klient Terminy cienki klient (thin client) oraz gruby klient (fat client) odnoszą się do mocy i jakości przetwarzania po stronie klienta w architekturze klient-serwer. Model cienkiego klienta: klient posiada niezbyt wielką moc przetwarzania, ograniczoną do prezentacji danych na ekranie. Przykładem jest klient w postaci przeglądarki WWW. Model grubego klienta: klient posiada znacznie bogatsze możliwości przetwarzania, w szczególności może zajmować się nie tylko warstwą prezentacji, lecz także warstwą przetwarzania aplikacyjnego (logiki biznesu). Powyższy podział posiada oczywiście pewną gradację. Model cienkiego klienta jest najczęstszym rozwiązaniem w sytuacji, kiedy system scentralizowany jest zamieniany na architekturę klient-serwer. Wadą jest duże obciążenie serwera i linii komunikacyjnych. Model grubego klienta używa większej mocy komputera klienta do przetwarzania zarówno prezentacji jak i logiki biznesu. Serwer zajmuje się tylko obsługą transakcji bazy danych. Popularnym przykładem grubego klienta jest bankomat. Zarządzanie w modelu grubego klienta jest bardziej złożone. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 80 marzec 2002

Architektury dwuwarstwowe Uproszczone architektury trójwarstwowe z cienkim lub grubym klientem. cienki klient Warstwa prezentacyjna (interfejs użytkownika) Warstwa przetwarzania (logika biznesu) + Warstwa zarządzania bazą danych Warstwa prezentacyjna (interfejs użytkownika) + Warstwa przetwarzania (logika biznesu) gruby klient Warstwa przetwarzania (logika biznesu) + Warstwa zarządzania bazą danych W tym modelu przetwarzanie (logika biznesu) jest dzielone pomiędzy klienta i serwera. Zaprojektowanie jej jest trudniejsze. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 81 marzec 2002

Przykład architektury K/S - sieć bankomatów Bankomat Serwer kont klientów banku Monitor Baza danych kont tele-przetwarzania klientów banku Bankomat © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 82 Oprogramowanie pośredniczące organizujące komunikację z odległymi klientami i szeregujące transakcje klientów celem przetwarzania ich przez bazę danych. marzec 2002

Przykład architektury K/S - portal WWW klient interakcja poprzez HTTP Serwer Web: generacja dynamicznych stron HTML dla klienta + zlecenia do bazy danych klient © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 83 zapytania SQL wyniki zapytań SQL Serwer bazy danych: wykonywanie zapytań w SQL marzec 2002

3 -warstwowa architektura aplikacji Web Serwer Web Sieć Internet Serwer aplikacji Serwer bazy danych HTTP Baza danych Przeglądarka Serwer © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 84 marzec 2002

2 -warstwowa architektura aplikacji Web Wiele warstw pośredniczących powoduje dodatkowe obciążenie. Sieć Internet Serwer Web Serwer aplikacji Serwer bazy danych HTTP Baza danych Przeglądarka Serwer © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 85 marzec 2002

Zastosowanie różnych architektur K/S ] Dwuwarstwowa architektura K/S z cienkim klientem • Systemy spadkowe (legacy), gdzie oddzielenie przetwarzania i zarządzania danymi jest niepraktyczne. • Aplikacje zorientowane na obliczenia, np. kompilatory, gdzie nie występuje lub jest bardzo mała interakcja z bazą danych. • Aplikacje zorientowane na dane (przeglądanie i zadawanie pytań) gdzie nie występuje lub jest bardzo małe przetwarzanie. ] Dwuwarstwowa architektura K/S z grubym klientem • Aplikacje w których przetwarzanie jest zapewnione przez wyspecjalizowane oprogramowanie klienta, np. MS Excel. • Aplikacje ze złożonym przetwarzaniem (np. wizualizacją danych, przetwarzaniem multimediów). • Aplikacje ze stabilną funkcjonalnością dla użytkownika, użyte w środowisku z dobrze określonym zarządzaniem. ] Trzywarstwowa lub wielowarstwowa archiktektura K/S • Aplikacje o dużej skali z setkami lub tysiącami klientów. • Aplikacje gdzie zarówno dane jak i aplikacje są ulotne (zmienne). • Aplikacje integrujące dane z wielu rozproszonych źródeł. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 86 marzec 2002

Architektura rozproszonych obiektów (1) ] W architekturze klient-serwer istnieje wyraźna asymetria pomiędzy klientem i serwerem; w szczególności, nie występuje tam komunikacja bezpośrednio pomiędzy klientami. Model taki dla wielu zastosowań jest mało elastyczny i zapewnia zbyt małą skalowalność. ] Architektura rozproszonych obiektów znosi podział na klientów i serwery. Każde miejsce w rozproszonym systemie jest jednocześnie klientem i serwerem. ] Konieczne jest sprowadzenie wszystkich danych i usług do jednego standardu. ] Taki standard obejmuje: • Model (pojęciowy i logiczny) danych i usług, który jest w stanie "przykryć" wszystkie możliwe dane i usługi, które mogą kiedykolwiek pojawić się w systemie rozproszonym; • Specjalne oprogramowanie zwane pośrednikiem (broker), które akceptuje wspólny model danych i usług umożliwiając ich udostępnienie dla dowolnych miejsc w systemie rozproszonym. • Specjalne oprogramowanie, zwane osłoną, adapterem lub mediatorem, które przystosowuje konkretne miejsce do modelu przyjętego przez pośrednika. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 87 marzec 2002

Architektura rozproszonych obiektów (2) . . . Aplikacja napisana w C++ Aplikacja na relacyjnej bazie danych Aplikacja na Lotus Notes Osłona 1 Osłona 2 Osłona 3 Pośrednik . . . Szyna oprogramowania (software bus) Miejsce 1 © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 88 Miejsce 2 Miejsce 3 marzec 2002

Struktura logiczna rozproszonych obiektów O 3 O 1 Obiekty Operacje na obiektach O 2 O 7 O 5 O 4 K 1 O 8 O 6 K 3 K 2 O 9 K 4 Szyna oprogramowania (software bus) Aplikacje A 1 A 2 A 3 Szyna oprogramowania tworzy jedną przestrzeń obiektów. Obiekty te są dostępne dla dowolnego miejsca poprzez operacje (zgrupowane w klasach). Miejsca i sposoby implementacji obiektów są niewidoczne. Aplikacje korzystają z całej puli obiektów. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 89 marzec 2002

Architektura serwera stron Aplikacja Przedmiotem zarządzania są fizyczne strony dyskowe Interfejs zapytaniowy Optymalizacja zapytań Przeglądarka obiektów Interfejs programistyczny Zarządzanie obiektami Zarządzanie plikami i indeksami Zarządzanie kieszenią strony Zarządzanie zamkami Zarządzanie składem Zarządzanie kieszenią stron Obiektowa baza danych © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 90 marzec 2002

Architektura serwera obiektów Aplikacja Przedmiotem zarządzania są obiekty Interfejs zapytaniowy Przeglądarka obiektów Interfejs programistyczny Zarządzanie obiektami obiekty Zarządzanie obiektami Optymalizacja zapytań Zarządzanie zamkami Zarządzanie składem Zarządzanie stronami i kieszeniami Obiektowa baza danych © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 91 marzec 2002

Przyszłościowa architektura aplikacji internetowych Przeglądarka WWW Narzędzia wspomagające XML : system autorski, itd. Warstwa klienta Przeglądarka WWW XML Serwer Web Serwer aplikacji Interakcja z aplikacjami poprzez protokoły oparte na XML Obiektowo-relacyjna baza danych wspomagająca XML Baza danych w XML (strukturalizowana) XML Obiektowa baza danych wspomagająca XML © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 92 Logiczna warstwa pośrednia XML Serwer integrujący XML, serwer zapytań, serwer hurtowni danych XML Translatory formatów z/do XML, pomosty Dokumenty XML nana Webie Inne dokumentynana Webie: HTML Word, . . . Zasoby danych pod OLE/DB marzec 2002

Standardy łączenia rozproszonych zasobów © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 93 marzec 2002

Standardy łączenia rozproszonych danych (1) ] Open Data. Base 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 Data. Base Connectivity (JDBC): analogiczny do ODBC standard dla Java. ] Standardy X/Open XA: definiują zarządzanie transakcjami ze wspomaganiem protokołu 2 PC. ] 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 © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 94 marzec 2002

Standardy łączenia rozproszonych danych (2) ] ADO (Active Data Objects): łatwy interfejs do funkcji OLE-DB ] Kilka standardów bazujących na XML dla E-commerce • Np. Rosetta. Net (łańcuchy dostaw), Biz. Talk • 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. ] Simple Object Access Protocol (SOAP): bazujący na XML standard dla zdalnego wołania procedur (RPC). SOAP jest mniej elastyczny i uniwersalny w stosunku do CORBA, ale pozostaje pytanie, czy aż taka elastyczność i uniwersalność jest potrzebna. • Używa XML do zakodowania danych, HTTP jako protokołu transportowego • Dalsze standardy są oparte na SOAP dla specyficznych aplikacji, np. OLAP i Data Mining (standardy Microsoft'u) © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 95 marzec 2002

Standardy łączenia rozproszonych danych (3) ] Object Data Management Group (ODMG) standard obiektowych baz danych • jest używany w projektach przyszłościowych związanych z rozproszonymi lub federacyjnymi bazami danych, np. IRO/DB. ] 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. Znacznie ograniczony w stosunku do standardu CORBA. ] RMI (Remote Method Invocation) - oprogramowanie firmy Sun, ograniczone w stosunku do standardu CORBA do oprogramowania pisanego w Java Beans i Enterprise Java Beans wykorzystują RMI jako transport. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 96 marzec 2002

Replikacje © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 97 marzec 2002

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. Rozproszone i federacyjne bazy danych, Folia 98 marzec 2002

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. Rozproszone i federacyjne bazy danych, Folia 99 marzec 2002

Modele replikacji Jednoczesne aktualizacje ze sterowaniem współbieżnościa Transakcja aktualizująca Propagacja aktualizacji Transakcja aktualizująca propagacja aktualizacji Replika 1 Replika 2 propa g aktua acja lizacj i Replika 1 Replika 3 Replika 2 Planowane odświeżanie kopii dla replik tylko do czytania Transakcja aktualizująca planowana aktualizacja Replika 1 Transakcja czytająca planow a aktual na izacja Replika 3 Transakcja czytająca © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 100 Replika 2 marzec 2002

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. Jeżeli • Przy dokładnej analizie należy utworzyć bardziej złożone modele kosztów, które ustalą opłacalność replik. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 101 marzec 2002

Przetwarzanie transakcji © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 102 marzec 2002

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: 2 PC, 3 PC. ] 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 2 PC i 3 PC są często nieadekwatne. ] Długie transakcje: konieczność zmniejszenia poziomu izolacji aby umożliwić dostęp zablokowanych danych. marzec 2002 © K. Subieta. Rozproszone i federacyjne bazy danych, do Folia 103

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 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 => 2 PC. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 104 marzec 2002

Dwufazowe potwierdzenie (2 PC) Koordynator (program aplikacyjny klienta) wie rdź w ó got pot SZBD serwera gotów potwierdź SZBD klienta SZBD serwera pot wie rd ź got ów 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. Rozproszone i federacyjne bazy danych, Folia 105 marzec 2002

2 PC - zarządzanie awariami ] Dość złożone postępowanie zależne od tego, czy awarii uległ serwer czy też koordynator. ] Protokół 2 PC 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ół 3 PC uwzględnia awarie koordynatora. ] 3 PC nie znalazł jednak szerszego zastosowania ze względu na duże narzuty na wydajność aplikacji. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 106 marzec 2002

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. Rozproszone i federacyjne bazy danych, Folia 107 marzec 2002

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. 2 PC (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. Rozproszone i federacyjne bazy danych, Folia 108 marzec 2002

Wykład 4 © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 109 marzec 2002

Niezgodności schematów i ontologii © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 110 marzec 2002

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. Rozproszone i federacyjne bazy danych, Folia 111 marzec 2002

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. Rozproszone i federacyjne bazy danych, Folia 112 marzec 2002

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. Rozproszone i federacyjne bazy danych, Folia 113 marzec 2002

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śćDo. Związku. Zawodowego, 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, Nr. Domu, 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. Rozproszone i federacyjne bazy danych, Folia 114 marzec 2002

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ć takim kanonicznym modelem danych? Relacyjny? Encja-związek? UML? CORBA? ODMG? Jakiś inny? 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. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 115 marzec 2002

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. Rozproszone i federacyjne bazy danych, Folia 116 marzec 2002

Federacyjne bazy danych © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 117 marzec 2002

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, 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. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 118 marzec 2002

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 Aplikacje lokalne Schemat eksportowy 2 Osłona 2 API 2 Lokalny SZBD 2 Aplikacje lokalne © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 119 . . . Schemat eksportowy n Osłona n API n Lokalny SZBD n Aplikacje lokalne marzec 2002

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 IA 1 Dostęp Zakaz Interfejs IA 2 Zakaz Dostęp Interfejs IC 1 Zakaz Dostęp Zakaz Ob. wirt. VV 3 Ob. wirt. 3 V Dane wirt. 1 Perspektywa V 1 Zakaz Dostęp Ob. wirt. VV 3 Ob. wirt. 3 V Dane wirt. 2 Perspektywa V 2 Dostęp Zakaz Obiekty A Obiekty Dane A A Obiekty Dane C A Interfejs IB 1 API Osłona Mediator Obiekty A Obiekty Dane B A definiuje a l sta u Administrator lokalnej bazy danych © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 120 Użytkownik 1 2 Użytkownik 3 marzec 2002

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 © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 121 Schemat eksportowy 2 Osłona 2 API 2 Lokalny SZBD 2 . . . BD 2 marzec 2002

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. Nie są mi znane istotne prace, które dałyby nadzieję na rozwiązanie. Przymiarki, spekulacje, . . . © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 122 marzec 2002

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 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. Rozproszone i federacyjne bazy danych, Folia 123 marzec 2002

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 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. Rozproszone i federacyjne bazy danych, Folia 124 marzec 2002

Osłony i mediatory © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 125 marzec 2002

Osłona wrapper Moduł oprogramowania umożliwiający przystosowanie interfejsu lokalnej bazy danych do pewnego standardu obowiązującego w systemie rozproszonym. Podstawowe zadanie: fizyczne połączenie różnych baz danych. ] Osłona nie zajmuje się bardziej wyrafinowanym odwzorowaniem; chodzi o translację danych, parametrów i wywołań funkcji płynących z zewnątrz lokalnego systemu (o specyficznych formatach i reprezentacji) na analogiczne dane, parametry i funkcje wyrażone w API konkretnego lokalnego systemu bazy danych. ] Dla niektórych przypadków, np. dla niektórych stron HTML, napisanie osłony jest bardzo trudnym zadaniem ze względu na nieregularności formatu (dane pół-strukturalne, semi-structured). ] Osłona jest niezbędna do tego, aby budować bardziej wyrafinowane środki odwzorowania schematów i aplikacji, takie jak mediatory i perspektywy © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 126 marzec 2002

Osłony w federacyjnych BD Osłona udostępnia dane i usługi lokalnego systemu i (dostępne w pewnym API i) dla aplikacji globalnych (wykorzystujących wspólny API f). Osłony przystosowują lokalne obowiązującego w federacji. SZBD do interfejsu programistycznego Federacyjny SZBD API f Osłona 1 Osłona 2 API 1 Lokalny SZBD 1 API 2 Lokalny SZBD 2 © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 127 . . . API f Osłona n API n Lokalny SZBD n marzec 2002

Osłony dla lokalnych relacyjnych SZBD Problem pojawia się wtedy, gdy API f dla federacyjnej bazy danych nie jest oparty o model relacyjny, lecz o model obiektowy a la CORBA lub ODMG. Potencjalne problemy i rozwiązania: ] Konieczność silnego ograniczenia modelu obiektowego, np. brak złożonych obiektów, metod, związków, hermetyzacji, polimorfizmu, itd. ; ] Odwzorowanie krotek tabel na złożone obiekty - wiele krotek składających się na jeden obiekt. Przetwarzanie np. w OQL+Java. Problemy koncepcyjne. ] Odwzorowanie obiektowego API, np. OQL +Java na relacyjne API, np. JDBC. Ogólne rozwiązanie jest bardzo trudne. ] Zredukowanie API relacyjnej BD do prymitywnych operacji (get first, get next, . . . ), dzięki czemu relacyjną bazę danych można będzie potraktować jako prymitywną obiektową bazę danych. Następnie, zdefiniowanie obiektowych, wirtualnych, aktualizowalnych perspektyw. Problemy koncepcyjne. Problemy z wydajnością. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 128 marzec 2002

Mediatory mediator Warstwa pośrednia pomiędzy lokalną bazą danych a globalnymi aplikacjami. Jest konieczny wtedy, gdy nie ma odwzorowania 1: 1 pomiędzy ontologiami. Np. w jednej bazie podany jest zarobek brutto z ubezpieczeniem, w innej zarobek brutto bez ubezpieczenia. Jak to sprowadzić do wspólnego mianownika? Zadania mediatora: rozbieżności pomiędzy schematem lokalnym a schematem ] Rozstrzyganie federacyjnym. ] Wspomaganie dla wyłowienia cech formalnych z danych niesformatowanych. ] Selekcja właściwej informacji. ] Wspomaganie dla informacji sumarycznych, wyliczalnych oraz o większym stopniu abstrakcji. ] Wspomaganie dla wykrywania niezidentyfikowanych związków w danych (eksploracja danych). Zasady konstrukcji mediatorów nie są jasne. W większości przypadków mediator musi być zaprojektowany ad hoc, pisany techniką niskiego poziomu i przypisany do konkretnej aplikacji (nie uniwersalny). © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 129 marzec 2002

Perspektywy © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 130 marzec 2002

Perspektywy view, database view Perspektywa (view) jest to odwzorowanie schematu lokalnego w inny (zmodyfikowany) schemat. Temu odwzorowaniu towarzyszy odwzorowanie danych rzeczywistych lokalnej bazy danych na dane wirtualne lub dane zmaterializowane (wyliczone). Przykładem są perspektywy w SQL. Podstawowe problemy: ] W przypadku istotnych różnic pomiędzy schematami lokalnymi baz danych, odwzorowanie ich w zadany schemat może być złożone lub niemożliwe. Środki definiowania perspektyw np. w SQL są za mało uniwersalne. ] Aktualizacja perspektyw (view updating): problem nie jest rozwiązany w stopniu zadowalającym. ] Aplikacje (np. w C++) są często przywiązane do fizycznej postaci danych. Odwzorowanie ich w dane wirtualne powoduje, że większość aplikacji przestaje działać. Ograniczenie do zapytań (np. w SQL) silnie redukuje rodzaj aplikacji, które mogą działać na schemacie federacyjnym. ] Wydajność (performance) aplikacji. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 131 marzec 2002

Perspektywa jak schemat zewnętrzny W szerokim znaczeniu: Perspektywą nazywa się odwzorowanie globalnego schematu bazy danych (określającego zapamiętane zasoby danych) na schemat “zewnętrzny”, przystosowany do potrzeb i przyzwyczajeń konkretnego użytkownika. Architektura ANSI/SPARC: Użytkownik 1 Perspektywa 1 W tym sensie pojęcie perspektywy funkcjonuje w literaturze z zakresu modeli danych, analizy i projektowania. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 132 Użytkownik 2 Perspektywa 2 Schemat globalny Poziom fizyczny bazy danych Użytkownik 3 Perspektywa 3 Schematy “zewnętrzne” Projektant BD Administrator BD marzec 2002

Perspektywa jako odwzorowanie W węższym znaczeniu: Perspektywą określa się nazwane odwzorowanie danych zapamiętanych w bazie danych na dane “wirtualne”, t. j. pochodne lub wyliczalne. Matematycznie, perspektywa jest dowolną funkcją określoną na danych. Ten punkt widzenia nie jest jednak dostatecznie precyzyjny, gdyż nie uwzględnia mechanizmów nazywania (naming), wiązania (binding) i zakresu (scoping), które są kluczowe, szczególnie w przypadku obiektowości z hierarchią klas, tożsamością obiektów, hermetyzacją i innymi pojęciami. Bardziej precyzyjny punkt widzenia: Perspektywa jest procedurą funkcyjną, która (najczęściej, ale niekoniecznie) zwraca wynik będący daną typu masowego (zbiór, wielozbiór, sekwencję). Taki wynik powinien być wyposażony w dodatkowe nazwy (np. nazwy atrybutów wirtualnych obiektów zwracanych przez perspektywę). Perspektywy znane z SQL mieszczą się w tej definicji. Są to uproszczone procedury funkcyjne, których ciało można sprowadzić do pojedynczego zdania: return <zapytanie SQL> © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 133 marzec 2002

Po co są perspektywy? Istnieje wiele ważnych zastosowań perspektyw, które czynią z nich bardzo gorący i aktualny temat. ] Uproszczenie modeli pojęciowych dla poszczególnych użytkowników. ] Uproszczenie zapytań poprzez “wyliczane” obiekty, atrybuty, związki. ] Dostosowanie się do punktu widzenia i terminologii dziedziny zastosowań ] Ograniczenie dostępu do obiektów, ochrona prywatności. ] Ograniczenie dostępu w systemach rozproszonych federacyjnych baz danych. ] Logiczna niezależność obiektów i aplikacji działający na obiektach. ] Współdziałanie systemów heterogenicznych (wspólny schemat). ] Przystosowanie systemów spadkowych (legacy) do nowszych technologii i wymagań. ] Hurtownie danych: analiza informacji gromadzonych z różnych źródeł. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 134 marzec 2002

Jak są widziane perspektywy w relacyjnych BD? Perspektywę wyznacza zapytanie, np. w SQL, plus drugorzędne środki syntaktyczne i semantyczne, takie jak zmiana nazw kolumn wirtualnych tablic. Po ewaluacji perspektywa zwraca tablicę, koncepcyjnie taka samą jak zapamiętane tablice. Popularną i efektywną techniką przetwarzania perspektyw jest nie ich ewaluacja (materializacja), lecz modyfikacja zapytań, traktująca perspektywę jako makrodefinicję, oraz łączna optymalizacja tekstu zapytania z rozwiniętym tekstem definicji perspektywy. Aktualizacja perspektyw jest ograniczona do pionowego/poziomego obcięcia zapamiętanych tablic. Nie występują i nie są dyskutowane środki sterowania intencją aktualizacji perspektywy. Aktualizacja perspektyw odbywa się w tym samym języku, co ich definicja (SQL); nie jest rozważana (chociaż być może osiągalna) aktualizacja perspektyw z języków niższego poziomu (np. z C). © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 135 marzec 2002

Perspektywy w relacyjnych bazach danych Perspektywę określa pewne zapytanie, np. SQL. Zdanie definiujące perspektywę określa nazwy atrybutów “wirtualnej tabeli”. Zapamiętana tabela: Pracownicy( Id_pracownika, Imię, Nazwisko, Stanowisko, Kierownik, Data_zatrudnienia, Zarobki, Premia, Id_działu ) Definicja perspektywy: CREATE VIEW Urzędnicy( Id_pracownika, Imię, Nazwisko, Zarobki ) AS SELECT Id_pracownika, Imię, Nazwisko, Zarobki FROM Pracownicy WHERE Stanowisko = ‘urzędnik’; Użycie perspektywy: (Zarobki urzędnika o nazwisku Nowak: ) SELECT Zarobki FROM Urzędnicy WHERE Nazwisko = ‘Nowak’ © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 136 Perspektywy wolno użyć w zdaniach SQL (prawie) na takich samych zasadach jak zapamiętanej tabeli. marzec 2002

Relacyjna baza danych z perspektywami Użytkownik lub program aplikacyjny SQL Dane wirtualne Dane rzeczywiste (logiczne) Perspektywa V 1 Tablica BD B 2 Perspektywa V 2 Tablica BD B 3 Tablica BD B 4 Dane zapamiętane (fizyczne) © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 137 marzec 2002

Przykład relacyjnej bazy danych DC DOSTAWCA DNR CNR ILOŚĆ DNR NAZW STATUS MIASTO D 1 D 2 D 3 D 4 D 5 Abacki Bober Czerny Dąbek Erbel 20 10 30 20 30 Lublin Poznań Lublin Radom CZĘŚĆ CNR NAZWAC C 1 C 2 C 3 C 4 C 5 C 6 Nakrętka Wkręt Podkładka Nit Tulejka KOLOR WAGA MIASTO Czarwony Zielony Niebieski Czerwony © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 138 12 17 17 14 12 19 Lublin Poznań Rzeszów Lublin Poznań Lublin D 1 D 1 D 1 D 2 D 3 D 4 D 4 C 1 C 2 C 3 C 4 C 5 C 6 C 1 C 2 C 2 C 4 C 5 300 200 400 200 100 300 400 200 300 400 marzec 2002

Przykład bardziej złożonej perspektywy Perspektywa Ocena. Dostawcy podaje numer dostawcy i sumę dostarczanych przez niego części. CREATE VIEW Ocena. Dostawcy( DNR, suma ) AS SELECT DNR, SUM( ILOŚĆ ) FROM DC GROUP BY DNR; Perspektywa Dobry. Dostawca ustala DNR, nazwisko, status i sumę dostarczanych części dla tych dostawców, którzy dostarczają ich ponad 600: CREATE VIEW Dobry. Dostawca( DNR, nazwisko, status, suma ) AS SELECT V. DNR, D. NAZW, D. STATUS, V. SUMA FROM DOSTAWCA AS D, Ocena. Dostawcy AS V WHERE V. DNR = D. DNR AND V. SUMA > 600; Rezultat: Wirtualna tabela o postaci: DROP VIEW Dobry. Dostawca; - usunięcie perspektywy z bazy danych. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 139 Dobry. Dostawca DNR nazwisko status suma D 1 Abacki D 2 Bober D 4 Dąbek 20 1300 10 700 20 900 marzec 2002

Perspektywy wirtualne ] Perspektywa istnieje wyłącznie w postaci definicji (np. zapytania, procedury funkc. ). ] Wyliczenie (materializacja) następuje w momencie użycia perspektywy. ] Wynik jest “konsumowany” i następnie kasowany (tak jak wynik procedury funkcyjnej). ] Zalety: nie ma dublowania danych, problemów aktualizacji wyliczonych danych, problemów z przetwarzaniem transakcji. ] Wada: czas ewaluacji perspektyw+czas ewaluacji zapytań używających perspektyw - bez optymalizacji jest bardzo często nieakceptowalny. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 140 marzec 2002

Perspektywy zmaterializowane ] Perspektywa jest wyliczona “na zapas”, jej wynik jest przechowywany w bazie danych na normalnych zasadach. Aktualizacja danych stanowiących podstawę wyliczenia pociąga za sobą aktualizację zmaterializowanej perspektywy (lub jej skasowanie i ewentualnie, ponowne wyliczenie). ] Tego rodzaju perspektywy określa się także jako “zdjęcie migawkowe” (snapshot). ] Zalety: szybki dostęp, łatwa implementacja. ] Wady: dodatkowe zapotrzebowanie na pamięć, dodatkowy koszt aktualizacji zmaterializowanych perspektyw (często prowadzący do problemów koncepcyjnych i realizacyjnych), dodatkowe wąskie gardło dla transakcji. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 141 marzec 2002

Zasada przezroczystości perspektyw view transparency Z punkty widzenia użytkownika dowolne operacje na perspektywach nie powinny niczym różnić się od podobnych operacji na zapamiętanych danych. Np. jeżeli w federacyjnej bazie danych administrator udostępnia tylko część danych poprzez perspektywę, wówczas programista końcowy nie powinien być zmuszany do modyfikacji programów działających na zapamiętanych danych z tego powodu, że mają one teraz działać na perspektywach. Warunek przezroczystości perspektyw jest trudny, gdyż: ] Dla pewnych odwzorowań danych zapamiętanych w wirtualne przyjęte środki definicji perspektyw (np. SQL) mogą okazać się niewystarczające (schematic discrepancies). ] Problem aktualizacji perspektyw pozostaje nierozwiązany. ] Pewne dane mogą być manipulowane wyłącznie przez przypisane im interfejsy, a nie przez języki zapytań. ] Problemy z wydajnością mogą unicestwić rozwiązania trzech poprzednich problemów. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 142 marzec 2002

Wykład 5 © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 143 marzec 2002

Aktualizacja perspektyw Najpoważniejszym, nierozwiązanym problemem jest aktualizacja perspektyw. Aktualizacja „wirtualnych” danych jest oczywiście niemożliwa, wobec czego należy zamienić tę aktualizację na aktualizację zapamiętanych danych. Aktualizacja Dane wirtualne Perspektyw a Baza danych Dane zapamiętane Na ogół odwzorowanie danych wirtualnych w dane zapamiętane nie jest jednoznaczne. Odwzorowanie aktualizacji danych wirtualnych w aktualizacje danych zapamiętanych można zrobić na wiele sposobów. Czasami takie odwzorowanie odwrotne w ogóle nie istnieje. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 144 marzec 2002

Przykład aktualizacji perspektyw (1) Dane rzeczywiste Dane wirtualne Pracownik Dział zatrudnia Nazwisko * Nazwa Zarobek /Moje. Działy Nazwa Średni. Zarobek Podwyższ średni zarobek w dziale „Krasnale ogrodowe” o 500 zł: update Moje. Działy set Średni. Zarobek = Średni. Zarobek + 500 where Nazwa = ‘Krasnale ogrodowe’; ? Zlecenie jest błędne, gdyż: Nie ma danej o nazwie Średni. Zarobek. Nawet gdybyśmy chcieli je poprawnie wykonać na danych rzeczywistych, mamy do wyboru nieskończenie wiele sposobów. Prawdopodobnie tylko jeden z nich satysfakcjonowałby naszego szefa, który wydał takie polecenie. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 145 marzec 2002

Przykład aktualizacji perspektyw (2) Dane rzeczywiste zatrudnia Pracownik Dział * Nazwisko szef Nazwa Zarobek 0. . 1 Dane wirtualne /Moi. Pracownicy Nazwisko. Szefa Przyjmujemy strategię implementacji perspektyw polegającą na tym, że po wyliczeniu perspektywy Moi. Pracownicy zwraca ona referencje do nazwiska pracownika i nazwiska jego szefa. Czy problem aktualizacji został rozwiązany? Pracownik Kowalski, pracujący dla Styki, ma mieć nowego szefa Nowaka. update Moi. Pracownicy set Nazwisko. Szefa = ‘Nowak’ where Nazwisko = ‘Kowalski’; ? Tym razem aktualizację można wykonać, zaś nowym szefem Kowalskiego będzie Nowak. Niestety, nasz system zmienił pewnemu pracownikowi nazwisko „Styka” na nazwisko „Nowak”, a chodziło o zupełnie coś innego, mianowicie, o przeniesienie Kowalskiego do innego działu. Intencja tego zlecenia została zniekształcona. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 146 marzec 2002

Ograniczenia w aktualizacji perspektyw System Oracle: W klauzuli SELECT nie ma słowa DISTINCT W klauzuli FROM jest tylko jedna nazwa tabeli lub aktualizowalnej perspektywy Na liście SELECT (wynikowej) znajduja się tylko nazwy kolumn W klauzuli WHERE nie ma podzapytania W zapytaniu nie mogą występować klauzule GROUP BY i HAVING Ta lista powinna być uzupełniona o ważny warunek: mianowicie, wynikowa wirtualna tablica powinna posiadać pełny klucz główny (primary key) pewnej zapamiętanej tablicy. Warunek ten (Ch. Date) jest logiczną konsekwencją tego, że identyfikacja zapamiętanej krotki następuje wyłącznie na podstawie wartości klucza głównego. W istocie jednak, systemy relacyjne odeszły od filozofii “klucza głównego” na rzecz “wewnętrznego identyfikatora krotki”, w związku z czym ten warunek okazał się zbędny. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 147 marzec 2002

Dodatkowe możliwości aktualizacji perspektyw W Oracle można aktualizować perspektywy powstające w wyniku złączenia, ale tylko atrybuty relacji znajdujące się po stronie “klucza obcego”: CREATE VIEW Moi. Ludzie( Id. Pracownika, Nazwisko, Id. Działu, Nazwa. Działu, Zarobek) AS SELECT p. Id_pracownika, p. Nazwisko, p. Id_działu, d. Nazwa, p. Zarobek FROM Pracownicy AS p, Działy AS d WHERE p. Id_działu = d. Id_działu AND p. Stanowisko = ‘programista’; Podwyższyć o 500 zarobki wszystkim programistom z działu Krasnali ogrodowych: UPDATE Moi. Ludzie SET Zarobek = Zarobek + 500 WHERE Nazwa. Działu = ‘Krasnale ogrodowe’ UPDATE Moi. Ludzie Przenieść programistę Nowaka do SET Nazwa. Działu = ‘Lalki Barbie’ działu Lalek Barbie: WHERE Nazwisko = ‘Nowak’ © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 148 OK. Źle! marzec 2002

Perspektywy są trudnym problemem ] Perspektywy są problemem, który doczekał się efektywnych rozwiązań w relacyjnych bazach danych. ] Podstawowy problem - aktualizacja wirtualnych danych - nie został rozwiązany w stopniu zadowalającym. ] Środki definicji perspektyw w relacyjnych bazach danych są ograniczone. ] Implementacje perspektyw nie zakładają sterowania intencją aktualizacji. Powoduje to, że wszelkie zapowiedzi opanowania poprzez perspektywy problemów takich jak współdziałanie (interoperability), przenaszalność (portability), ewolucja schematu (schema evolution), itp. , są pobożnym życzeniem. Dotyczy to szczególnie kolejnych prac na temat obiektowych perspektyw relacyjnych baz danych. ] W powszechnej opinii, problem aktualizacji wirtualnych perspektyw jest uważany za bardzo trudny. ] Rośnie liczba prac nt. zmaterializowanych perspektyw, gdzie problem jest koncepcyjnie prostszy. Tych dwóch tematów nie należy mylić. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 149 marzec 2002

Klasyfikacja złożoności perspektyw ] Proste perspektywy, np. definiowane poprzez operatory selekcji i projekcji w relacyjnych BD. Mała przydatność dla federacyjnych baz danych. ] Perspektywy bardziej złożone, np. wymagające złączeń i grupowania, ale wyrażalne w SQL i OQL. Problemy z aktualizacją perspektyw i wydajnością. ] Perspektywy umożliwiające zmianę reprezentacji danych. ] Perspektywy uwzględniające niezgodności schematów, np. zamieniające atrybut Zawód z wartościami “piekarz”, “stolarz” itd. na wirtualne tabele Piekarz, Stolarz, itd. Wymagają dostępu do metabazy i mechanizmu refleksji (reflection). ] Perspektywy uwzględniające niezgodności semantyczne pomiędzy danymi. Często nie ma możliwości odzyskania informacji, która pozwoliłaby usunąć te niezgodności. Konieczne jest wtedy zrezygnowanie z pełnej przezroczystości. ] Perspektywy z (trwałym) stanem, o pełnej mocy algorytmicznej. Wydajność? Pozostałe kryteria klasyfikacyjne: generyczność, moc, stopień uwzględnienia pojęć modelu obiektowego, perspektywy rekurencyjne, perspektywy z parametrami, możliwości aktualizacji perspektyw, możliwości optymalizacji, itd. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 150 marzec 2002

Kryteria aktualizowalności perspektyw ] Brak nadmiarowej akualizacji. Jeżeli użytkownik aktualizuje pewien element perspektywy, nie powinien bezwiednie powodować aktualizacji innego jej elementu. ] Brak niedostatecznej/błędnej aktualizacji - wynik aktualizacji nie powinien odbiegać od intencji użytkownika. Np. użytkownik aktualizuje zarobek netto o 100 zł, tymczasem okazuje się, ze faktyczna aktualizacja wyniosła 91, 50 zł. ] Brak efektów ubocznych aktualizacji. Np. takim efektem jest zniknięcie krotki z perspektywy Biedny. Pracownik (Zarobek < 500) po zaktualizowaniu tego zarobku. ] Brak spontanicznej aktualizacji bazy danych poza jej fragmentem widocznym poprzez perspektywę. ] Zdeterminowany translator aktualizacji perspektywy - dla każdego stanu bazy danych powinien działać tak samo, mimo niejednoznaczności odwzorowania aktualizacji perspektywy w aktualizację zapamiętanych danych. Podane kryteria są spekulatywnym stereotypem i dotyczą sytuacji, kiedy translacja aktualizacji perspektyw jest dokonywana w pewien automagiczny sposób. Przestają mieć sens, jeżeli pełna kontrola nad aktualizacją perspektyw jest w rękach definiującego perspektywę. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 151 marzec 2002

Perspektywy z opcją sprawdzania CREATE VIEW Mało. Zarabiający( Nazwisko, Zarobek) AS SELECT Nazwisko, Zarobek FROM Pracownicy WHERE Zarobek < 500 WITH CHECK OPTION; Końcowa klauzula oznacza brak efektów ubocznych w postaci “znikania” krotki po aktualizacji perspektywy. UPDATE Mało. Zarabiający SET Zarobek = Zarobek + 500 WHERE Nazwisko = ‘Marucha’ Taka aktualizacja spowoduje, że Marucha zostanie usuniety z perspektywy (ale oczywiście, nie z bazy danych) CHECK OPTION oznacza, że ta aktualizacja zostanie odrzucona. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 152 marzec 2002

Aktualizacja perspektyw w relacyjnych BD ] Duża liczba artykułów, głównie teoretycznych, ale (poza opisanymi praktycznymi rozwiązaniami) rezultaty tego nurtu są gorzej niż mizerne. • Artykuły zakładają jakiś "automagiczny" sposób aktualizacji perspektyw, bez sterowania intencją aktualizacji. • Środki formalne modelu relacyjnego (algebra relacji i inne) są nieprzystosowane do operacji imperatywnych takich jak aktualizacja. • Model relacyjny nie zaoferował dostatecznie uniwersalnego formalizmu do opisu konstrukcji imperatywnych, procedur, metod, itd. • W ten sposób zmarnowano masę czasu, wysiłku i papieru. • Przede wszystkim, zmarnowano czas czytelników. ] Prosty pomysł polega na przyjęciu założenia, że sterowanie intencją aktualizacji perspektywy powinno być: • składową definicji perspektywy, • znajdować się w rękach definiującego perspektywę, • zakładać imperatywny język (programowania) jako środek określania tej intencji. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 153 marzec 2002

Perspektywy ze stanem capacity augmenting views, stateful views Klasyczne perspektywy udostępniają (w inny sposób) informacje, która już są zapamiętane w bazie danych. Często takie ograniczenie jest nieakceptowalne. Lokalna BD zawiera atrybut “stanowisko”, którego wartością są numery 11, Przykład 45, 77, itd. , gdzie 11 oznacza projektant, 45 oznacza analityk, 77 oznacza sprzątaczka, itd. Federacja wymaga pełnych nazw zawodów. Potrzebna jest 1: dodatkowa funkcja, która zamieni numery na stringi. Definicja perspektywy musi więc zawierać definicję trwałej tabeli z numerami i stringami. Przykład 2: Dla celów kontroli utworzona jest perspektywa w postaci tabeli Wyniki. Kontroli( Nr. Urządzenia, Nazwa. Urządzenia, Ocena. Kontrolera ) Nr. Urządzenia i Nazwa. Urządzenia pochodzą z lokalnej BD. Natomiast Ocena. Kontrolera jest atrybutem, którego w lokalnej BD nie ma. Jest on własnością globalnej aplikacji, gdzie kontroler wpisuje swoją ocenę. Jest to zapamiętany atrybut, wprowadzony na potrzeby tej perspektywy. Perspektywy ze stanem (oraz autonomia lokalnych BD) oznaczają konieczność wprowadzenia na poziomie federacji specjalnej BD przechowującej dane niezbędne do definicji perspektywy. Komplikuje to architekturę federacyjnej bazy danych. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 154 marzec 2002

Przetwarzanie perspektyw w zapytaniach Obowiązują dwie strategie: Materializacja. Perspektywa jest całkowicie liczona w momencie, kiedy sterowanie programu/zapytania osiągnie punkt, w którym wynik tej perspektywy staje się niezbędny dla dalszego przetwarzania. Każde odwołanie się do perspektywy powoduje jej ponowne wyliczenie (dla uniknięcia niespójności związanych z ewentualną aktualizacją BD). Ta strategia może być optymalizowana poprzez zmaterializowane perspektywy. Modyfikacja zapytań (query modyfication). Tekst zapytania, w którym występuje odwołanie do perspektywy, jest scalany z tekstem definicji perspektywy. Następnie takie rozwinięte zapytanie jest wspólnie optymalizowane na normalnych zasadach. W tej strategii definicja perspektywy jest traktowana jako makro. Ponieważ wcześniejszy SQL nie dopuszczał klauzuli SELECT wewnątrz klauzuli FROM, kwestia banalnego tekstowego zastępowania przybrała cudaczne formy, owocując w super -naukowe “algorytmy” : -) (Stonebraker et al). W SQL-92 tę wadę usunięto. W różnych sytuacjach pierwsza lub druga strategia może być bardziej optymalna, ale najczęściej strategia modyfikacji zapytań jest bardziej skuteczna. Z tego powodu jest ona standardem we wszystkich relacyjnych SZBD. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 155 marzec 2002

Przykład modyfikacji i optymalizacji zapytania Definicja perspektywy: CREATE VIEW Urzędnicy( Id_pracownika, Imię, Nazwisko, Zarobki ) AS SELECT Id_pracownika, Imię, Nazwisko, Zarobki FROM Pracownicy WHERE Stanowisko = ‘urzędnik’; Użycie perspektywy: SELECT Zarobki FROM Urzędnicy WHERE Nazwisko = ‘Nowak’ Po tekstowej modyfikacji zapytania: SELECT Zarobki FROM (SELECT Id_pracownika, Imię, Nazwisko, Zarobki FROM Pracownicy WHERE Stanowisko = ‘urzędnik’) WHERE Nazwisko = ‘Nowak’ Usunięcie zbędnych astrybutów: SELECT Zarobki FROM (SELECT Nazwisko, Zarobki FROM Pracownicy WHERE Stanowisko = ‘urzędnik’) WHERE Nazwisko = ‘Nowak’ Ostateczna optymalizacja: SELECT Zarobki FROM Pracownicy WHERE Stanowisko = ‘urzędnik’ AND Nazwisko = ‘Nowak’ © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 156 marzec 2002

Perspektywy łączące dane zapamiętane i wirtualne Dla integracji systemów spadkowych lub sfederowanych potrzebne są perspektywy, które łączą w jedną kolekcję zarówno dane wirtualne (odwzorowanie danych ze starszych systemów) jak i dane rzeczywiste (pochodzące z nowszych systemów). Stary system: Stary. Student (Id, Nazwisko, Rok. Studiów, Średnia. Ocena ) Nowy system: Nowy. Student (Id, Nazwisko, Nr. Indeksu ) Pewne atrybuty zniknęły, pojawił się nowy. Tego rodzaju sytuacje można sprowadzić do sumy dwóch perspektyw: jednej działająca na starych danych i drugiej działającej na starych i nowych: CREATE VIEW Stary. Nowy. Student( Id, Nazwisko, Nr. Indeksu) AS SELECT Id, Nazwisko, NULL FROM Stary. Student CREATE VIEW Student( Id, Nazwisko, Nr. Indeksu) AS SELECT * FROM Stary. Nowy. Student UNION SELECT * FROM Nowy. Student © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 157 Pozostają problemy spójnej aktualizacji oraz wydajności. marzec 2002

Aktualizacja zmaterializowanych perspektyw Główny problem w aktualizacji zmaterializowanych perspektyw polega na tym, jak uniknąć ponownego generowania całej zmaterializowanej perspektywy po aktualizacji bazy danych. Istnieją dwie strategie: Określenie kryteriów do stwierdzenia, że dana aktualizacja nie wpływa na wyliczoną zmaterializowaną perspektywę. Np. najprostsze kryterium może być następujące: Jeżeli zlecenie aktualizacyjne używa nazw danych n 1, n 2, . . . , definicja perspektywy używa nazw m 1, m 2, . . . przy czym zbiory {n 1, n 2, . . . } i {m 1, m 2, . . . } są rozłączne, wówczas zlecenie aktualizacyjne nie wpływa na wynik materializacji perspektywy. Ustalenie związku pomiędzy fragmentami bazy danych i fragmentami zmaterializowanej perspektywy w taki sposób, aby dany fragment zmaterializowanej perspektywy był funkcją danego fragmentu bazy danych. W tym przypadku możliwa jest aktualizacja przyrostowa (incremental), tj. po aktualizacji bazy danych modyfikowany/przeliczany jest tylko fragment perspektywy. Metoda zależy od formy definicji perspektywy. Możliwe jest włączenie aktywnych reguł wyzwalających przeliczenie fragmentów zmaterializowanej perspektywy. Mało prac zajmuje się odwzorowaniem aktualizacji perspektywy na aktualizację oryginalnych danych, ale problem bardzo przypomina techniki replikacji. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 158 marzec 2002

Perspektywy obiektowe (1) ] Wskutek “wtłoczenia” w problem perspektyw ogromnej liczby pojęć obiektowych i innych, przy braku spójnego i jednorodnego modelu formalnego, propozycje rozwiązania tego problemu są partykularne, nieregularne, niedostatecznie generalne, obciążone drugorzędnymi szczegółami, sporym bagażem syntaktycznym i mętnymi dywagacjami semantycznymi. ] Podstawowa metoda przetwarzania perspektyw, czyli modyfikacja zapytań, została zapomniana. O optymalizacji zapytań włączającej perspektywy w ogóle się nie wspomina. ] Nawet jeżeli są propozycje aktualizacji perspektyw, z reguły są one ograniczone do takich rodzajów, które “zwracają” zapamiętane obiekty w niezmienionej postaci. W tym względzie sytuacja jest gorsza niż w modelu relacyjnym. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 159 marzec 2002

Perspektywy obiektowe (2) ] Nie występują środki sterowania intencją aktualizacji perspektywy. Nie występują perspektywy rekurencyjne i perspektywy z parametrami. Świat nie dojrzał. . . ] Problemem są niespójne i ograniczone podejścia do obiektowych języków zapytań. Funkcjonuje duża ilość fałszywych stereotypów, z których część pochodzi ze zbyt dosłownego przeniesienia do obiektowości paradygmatów modelu relacyjnego ] Brak zintegrowania obiektowych języków zapytań z konstrukcjami imperatywnymi, niepotrzebny nacisk (patrz ODMG), aby tego rodzaju konstrukcje “oddelegować” do obiektowych języków programowania takich jak C++, Java i Smalltalk (gdzie problem aktualizacji perspektyw staje się niewyrażalny). © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 160 marzec 2002

Refleksja nt. obiektowych perspektyw. . . Problem obiektowych perspektyw dla prostego przypadku jest banalny. ] Można przyjąć, że perspektywa wyznacza podzbiór obiektów pewnej klasy, zaś cała semantyka rzeczywistych obiektów jest przeniesiona do obiektów wirtualnych. To rozwiązanie można wzmocnić ograniczeniem dostępu do pewnych atrybutów (patrz rozwiązanie w O 2 lub COCOON) ] Podejście to można zastosować w stosunku do aktualizacji perspektyw. Analogią są perspektywy w SQL z wykorzystaniem wyłącznie selekcji. ] Generalny problem perspektyw jest trudny, ponieważ brakuje uniwersalnego modelu obejmującego wszystkie najważniejsze aspekty obiektowości, włączając klasy, cechy proceduralne, metody, itd. ] Rozwiązanie problemu perspektyw dla bardziej ogólnego przypadku jest możliwe przy zastosowaniu podejścia stosowego, które zapewnia niezbędną ogólność, prostotę i unifikację pojęć. ] Jak dotąd nikt nie wynalazł lepszego podejścia. Produkuje się nowe kulawe podejścia (np. w kontekście XML) dające złudzenie, że problem da się opanować przy pomocy prostszych środków. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 161 marzec 2002

Podejścia do obiektowych perspektyw Podejście Abiteboula i Bonnera, Rundensteinter et al (Multi. View), Kifera, Kima i Sagiv’a, Scholl’a et al (COOL/COCOON), LIVING IN A LATTICE, Eder’a i inne. Różnice pomiędzy tymi podejściami polegają na arbitralnym wyborze własności perspektyw i ustaleniu dla nich konstrukcji składniowej. Konstrukcja ta obejmuje szereg ortogonalnych cech pochodzących z dwóch wymienionych na początku poglądów na pojęcia perspektywy oraz ich potencjalnych zastosowań (np. ograniczenie dostępu, zintegrowanie z systemem klas, itd. ) Moje podejście jest różne od zaproponowanych. Polega na przyjęciu założenia, że: Perspektywa jest procedurą funkcyjną zdefiniowaną w języku zapytań, zwracającą kombinację referencji, nazw i wartości. To początkowe założenie jest następnie nieco modyfikowane. Tak rozumiana perspektywa korzysta z normalnych własności obiektowych struktur danych, w szczególności, struktury modułów i klas, środków ograniczenia dostępu, itd. Środki dodatkowe dla tak rozumianej perspektywy są ograniczone do minimum. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 162 marzec 2002

Perspektywy jako procedury funkcyjne Konieczne jest określenie: ] Gdzie taka procedura funkcyjna jest umieszczona w strukturze obiektowej? W zależności od tego, możemy mieć wirtualne obiekty, jeżeli procedura jest na czubku struktury obiektowej, lub wirtualne atrybuty, jeżeli procedura jest metodą zdefiniowaną wewnątrz klasy. ] Na jakim środowisku taka funkcja działa? Chodzi o reguły zakresu. Jak wynik takiej procedury ma być podłączony do istniejących lub nowych klas? ] Co taka procedura funkcyjna zwraca? Chodzi o ich dziedzinę semantyczną. ] W jaki sposób wynik takiej procedury (czyli wirtualne dane) jest udostępniony dla innych konstrukcji danego języka zapytań lub programowania? ] Czy taka procedura funkcyjna może mieć parametry? Jakie to ma konsekwencje? ] Czy taka procedura może być rekurencyjna? Jakie to ma konsekwencje? ] Czy taka procedura może mieć imperatywne ciało i lokalne środowisko danych? ] Jaki jest stosunek takich procedur do standardowych mechanizmów ograniczenia dostępu do danych? © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 163 marzec 2002

Przetwarzanie zapytań © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 164 marzec 2002

Przetwarzanie zapytań w rozproszonych BD Przetwarzanie zapytań powinno minimalizować zarówno obciążenie linii transmisyjnych jak i pracochłonność przetwarzania po stronie klienta (globalnej aplikacji) jak i po stronie serwerów. ] Przetwarzanie wyłącznie po stronie klienta (gruby klient): ogromne obciążenie linii transmisyjnych. ] Przetwarzanie wyłącznie po stronie serwerów (chudy klient): może powstać wąskie gardło wskutek tego, że jednocześnie wielu klientów będzie żądać usługi od jednego serwera. ] Generalna zasada: "wyślij zapytanie do danych, a nie dane do zapytanie" nie dla wszystkich przypadków jest słuszna i rodzi problemy koncepcyjne. ] Przetwarzanie zapytań odbywa się poprzez: • dekompozycję zapytania na operacje wysyłane do różnych węzłów, • porządkowanie tych operacji, • zbieranie ich rezultatów oraz ich przetwarzanie przez klienta w celu skonstruowania ostatecznego wyniku zapytania. marzec 2002 © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 165

Strategie optymalizacji zapytań w rozprosz. BD ] Przetwarzanie wyłącznie po stronie klienta. Pobiera on wszystkie dane potrzebne do realizacji zapytania do swojego obszaru => duży czas i koszt transmisji danych, małe problemy koncepcyjne. ] "Statyczna" (jednoczesna) dekompozycja zapytania na podzapytania, wysłanie ich do lokalnych miejsc, przesłanie rezultatów podzapytań do klienta, który łączy tych rezultaty w globalny rezultat. Skuteczna dla podziału poziomego danych i zapytań ograniczonych do selekcji/projekcji, nieskuteczna dla zapytań złożonych. ] "Dynamiczna" dekompozycja: generacja podzapytania do miejsca 1 i przesłanie wyniku 1 do centralnego miejsca; generacja podzapytania do miejsca 2 i przesłanie wyniku 2 do centralnego miejsca, itd. Brak równoległości działania serwerów, trudności koncepcyjne. ] Hybrydowa dekompozycja - połączenie dekompozycji statycznej i dynamicznej. ] Hybrydowa dekompozycja z przesłaniem danych do serwera. Klient nie tylko dokonuje wysłania podzapytania do serwera, ale również przesyła do niego część danych, które otrzymał od innych serwerów (aby marzec 2002 © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 166

Indeksowanie rozproszonych zasobów ] Szczególnie istotne w przypadku technologii P 2 P, ale nie tylko. ] Indeks centralny, adresujący całe zasoby rozproszonej sieci. Przykładem wykorzystania indeksów centralnych jest Napster oraz liczne motorki wyszukiwawcze takie jak Google lub Alta. Vista, ] Indeksy lokalne replikowane, trzymane przez klientów celem szybkiego zlokalizowania miejsc z interesującymi danymi. W tym przypadku duża część optymalizacji zapytania może być wykonana przez klienta zanim on wyśle zlecenia do odległych serwerów. ] Problem z indeksami centralnymi - zależność całości rozproszonej bazy danych od jednego miejsca. ] Problemy z indeksami lokalnymi replikowanymi: • kłopotliwa aktualizacja indeksów • możliwość powstawania niespójności wskutek opóźnień lub braku możliwości aktualizacji indeksów • straty przestrzeni dyskowej © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 167 marzec 2002

Statyczny schemat przetwarzania zapytań (1) 1. Klient realizuje zapytanie Z odwołujące się do danych na serwerach S 1, S 2, . . . , Sk 2. Klient dokonuje odwzorowania zapytania Z na zapytania Z 1, Z 2, . . . , Zk adresowane do serwerów S 1, S 2, . . . , Sk. Odwzorowanie wymaga znajomości lokalnych schematów danych. 3. Zapytania Z 1, Z 2, . . . , Zk są konstruowane z Z w taki sposób, aby wyniki tych zapytań W 1, W 2, . . . , Wk uzyskane z poszczególnych serwerów dały możliwość utworzenia globalnego wyniku W. 4. Zapytania Z 1, Z 2, . . . , Zk są kierowane do serwerów S 1, S 2, . . . , Sk, gdzie są wykonywane. 5. Serwery zwracają do klienta wyniki W 1, W 2, . . . , Wk zapytań Z 1, Z 2, . . . , Zk 6. Klient dokonuje scalenia wyników W 1, W 2, . . . , Wk w globalny wynik w. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 168 marzec 2002

Statyczny schemat przetwarzania zapytań (2) Klient Dekompozycja zapytania Z Scalenie wyników Wynik W zapytania Z Z 1 Z 2 W 1 Serwer S 2 W 2 Zk Wk . . . Serwer Sk ] Statyczny schemat ma przede wszystkim zastosowanie w przypadku poziomej fragmentacji danych, np. rozbicia obiektów Pracownik na wiele podzbiorów o takiej samej budowie przechowywanych na poszczególnych serwerach. ] W tym przypadku dekompozycja zapytania oznacza po prostu jego skopiowanie: Z = Z 1 = Z 2 =. . . = Zk ] Scalenie wyników polega na sumie mnogościowej wyników cząstkowych. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 169 marzec 2002

Dynamiczny schemat przetwarzania zapytań 1. Klient realizuje zapytanie Z odwołujące się do danych na serwerach S 1, S 2, . . . , Sk 2. Klient dokonuje odwzorowania zapytania Z na podzapytanie Z 1 adresowane do serwera S 1 (na podstawie schematu S 1). Z 1 jest konstruowane z Z w taki sposób, aby jego wynik W 1 uzyskany z S 1 wystarczył do realizacji zapytania Z. 3. Z 1 jest kierowane do serwera S 1, gdzie jest wykonywane. Serwer S 1 zwraca do klienta wynik W 1 podzapytania Z 1. 4. Na podstawie znajomości W 1 klient konstruuje z Z kolejne podzapytanie Z 2 kierowane do serwera S 2. Może do tego serwera skierować pewien fragment W 1, nazwijmy go F 1; . . proces jest powtarzany dla wszystkich serwerów, aż do uzyskania rezultatu. Klient Z Z 1 (Z, W 1) Z 2, F 1 (Z, W 1, W 2) Z 3, F 2 Scalenie wyników © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 170 Z 1 W 1 Serwer S 1 Z 2, F 1 W 2 Serwer S 2 Z 3, F 2 W 3 Serwer S 3 marzec 2002

Przykład: technika pół-złączeń (1) Serwer 1 Serwer 2 DOSTAWCA DC DNR NAZW STATUS MIASTO DNR CNR ILOŚĆ D 1 Abacki D 2 Bober D 5 Erbel 20 Lublin 10 Poznań 30 Radom D 1 D 2 D 3 D 4 D 4 C 5 C 1 C 2 C 2 C 4 C 5 semijoin 200 100 300 400 200 300 400 Klient ma dokonać złączenia relacji DOSTAWCA i relacji DC: select * from DOSTAWCA, DC where DOSTAWCA. DNR = DC. DNR © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 171 marzec 2002

Przykład: technika pół-złączeń (2) W celu realizacji zapytania klient musi wykonać następujące czynności: 1. Sciagą dane z serwera 1 przy pomocy zapytania Z 1: select * from DOSTAWCA Uzyska w ten sposób wynik W 1 DNR NAZW STATUS MIASTO D 1 Abacki D 2 Bober D 5 Erbel 20 Lublin 10 Poznań 30 Radom 2. Tworzy pomocniczą tabelę poprzez projekcję W 1 na DNR: tę tabelę nazywa F 1 DNR D 1 D 2 D 5 3. Wysyła tabelę F 1 do serwera 2 żądając tymczasowego ulokowania jej w bazie danych serwera 2; następnie wysyła tam zapytanie Z 2: select * from DC, F 1 where DC. DNR = F 1. DNR © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 172 marzec 2002

Przykład: technika pół-złączeń (3) 4. Uzyska w ten sposób wynik W 2: Jest to tzw. pół-złączenie relacji DC, parametryzowane relacją DOSTAWCA. W 2 DNR CNR ILOŚĆ D 1 C 4 200 D 1 C 5 100 D 2 C 1 300 D 2 C 2 400 Pół-złączenie relacji R 1, parametryzowane relacją R 2, powstaje poprzez złączenie R 1 z R 2, a następnie projekcję wyniku na atrybuty relacji R 1 5. Przesyła wynik W 2 - pół-złączenie - do klienta 6. Klient dokonuje ostatecznego scalenia wyników - złączenia relacji W 1 i W 2. Wynik DNR D 1 D 2 NAZW STATUS MIASTO CNR ILOŚĆ C 4 200 Abacki 20 Lublin C 5 100 Abacki 20 Lublin C 1 300 Bober 10 Poznań C 2 400 Bober 10 Poznań W zależności od oceny kosztów przetwarzania i transmisji klient może zacząć od ściągnięcia danych z serwera 2 i następnie dokonać pół-złączenia relacji DOSTAWCA. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 173 marzec 2002

Podsumowanie © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 174 marzec 2002

Podsumowanie (1) ] Globalizacja przestrzeni informacyjnej powoduje nacisk na tworzenie rozproszonych i federacyjnych baz danych, które umożliwiłyby tworzenie aplikacji globalnych, działających na zestawie dziesiątków, tysięcy lub milionów lokalnych BD. ] Połączenie tych lokalnych baz danych siecią komputerową stwarza niezbędną infrastrukturę techniczną, ale nie rozwiązuje ogromnej ilości problemów koncepcyjnych, których część została omówiona na tym wykładzie. ] Pewna część problemów jest rozwiązana dla rozproszonych relacyjnych baz danych. Rozproszone obiektowe bazy danych znajdują się na początku drogi. ] Niektóre problemy, takie jak: przetwarzanie globalnych transakcji, aktualizowalne perspektywy, rozstrzyganie niezgodności schematów, akceptowalna wydajność globalnych aplikacji, itd. , prawdopodobnie mają ogólnego rozwiązania. Pozostają nadzieje na rozwiązania cząstkowe. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 175 marzec 2002

Podsumowanie (2) ] Problemy rozproszenia są skutkiem “spadku” pozostawionego nam przez naszych poprzedników. Znaczna część problemów może rozwiązać się sama poprzez rezygnację ze spadku, tj. poprzez wymarcie kłopotliwych SZBD i powstanie nowych SZBD, lepiej przystosowanych do tworzenia rozproszonych federacji. ] Konieczna jest standardyzacja: • w zakresie modeli danych • w zakresie ontologii biznesowej i metamodeli • w zakresie wymiany danych • w zakresie API realizującego dostęp do do danych, w szczególności języków zapytań ] Konieczne są dalsze prace badawcze i wdrożeniowe w zakresie przetwarzania i optymalizacji rozproszonych obiektowych zapytań, protokołów dostępu, obiektowych perspektyw, ontologii, metamodeli, formatów wymiany danych, rozproszonych transakcji, itd. © K. Subieta. Rozproszone i federacyjne bazy danych, Folia 176 marzec 2002