Rozproszone i federacyjne bazy danych

Rozproszone i federacyjne bazy danych
SYSTEMY BAZ DANYCH Część V Rozproszone i federacyjne bazy danych Opracowanie : Dr Bożena Śmiałkowska

Wprowadzenie do systemów rozproszonych

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.

Co to jest system rozproszony?

Cztery najważniejsze problemy do rozwiązania w systemach r.b.d.
Przezroczystość (transparency): traktowanie rozproszonych zasobów i usług tak, jak gdyby były one wewnątrz przestrzeni adresowej jednego komputera. Bezpieczeństwo: przeciwdziałanie losowym awariom oraz możliwościom ataku z zewnętrz. Interoperacyjność (interoperability): umożliwienie współpracy heterogenicznych platform, aplikacji, logik biznesowych i organizacji danych. Efektywność: uzyskanie czasów przetwarzania akceptowalnych dla szerokiego kręgu użytkowników rozproszonych aplikacji.

Przezroczystość Redukcja złożoności przy pracy z rozproszonymi zasobami danych i usług, polegająca na uwolnieniu programisty od myślenia na temat położenia i organizacji rozproszonych danych. Przezroczystość ma bezpośrednie skutki dla czasu i kosztu wytworzenia rozproszonej aplikacji, jej przenaszalności i pielęgnacyjności.

Formy przezroczystości (1)
Przezroczystość położenia i dostępu: Uwolnienie użytkowników od konieczności korzystania z informacji o aktualnym położeniu geograficznym danych i usług. Przezroczystość współbieżności: Umożliwienie wielu użytkownikom jednoczesnego dostępu do danych i usług. Przezroczystość skalowania: Umożliwienie dodawania lub usuwania serwerów, danych i usług bez wpływu na działanie aplikacji i pracę użytkowników. Przezroczystość fragmentacji (podziału): automatyczne scalanie obiektów lub kolekcji, których fragmenty są przechowywane w różnych miejscach.

Formy przezroczystości (2)
Przezroczystość replikacji: Umożliwienie tworzenia i usuwania kopii danych w innych miejscach geograficznych ze skutkiem dla efektywności przetwarzania. 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.

Interoperacyjność Krytyczny problem dla projektu bottom-up, czyli systemu integrującego istniejące (spadkowe) niekompatybilne (heterogeniczne) dane i usługi. Interoperacyjność na poziomie transportu (transport-level interoperability) jako podstawa wyższych form interoperacyjności. Chodzi o umożliwienie fizycznej komunikacji pomiędzy danymi i usługami, np. na gruncie TCP/IP, HTTP, wspólnej pamięci, itp.

Interoperacyjność kontra przezroczystość
Konieczność poszukiwania kompromisowych rozwiązań na zasadzie tzw. „wspólnego rozwiązania”. Może być to łatwe: Dla danej populacji serwerów istnieje prosty model kanoniczny powiązań inter-operacyjnych w jedną przezroczystą całość. Może to być trudne: Jeżeli rozbieżności pomiędzy serwerami są duże, to informacja o zawartości poszczególnych serwerów musi być doprowadzona do programisty i do modelu kanonicznego. Jest to problem złożony i nieprzezroczysty.

Zalety systemów rozproszonych cd..
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.

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.

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.

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.

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, P2P): 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 P2P. 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, ...

Rozproszone a scentralizowane BD

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.

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.

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.

Klasyfikacja rozproszonych baz danych

Klasyfikacja rozproszonych baz danych cd..
Systemy wielu baz danych (multidatabases) Niefederacyjne rozproszone BD Federacyjne BD Jednorodne BD Rozproszone BD z globalnym schematem Słabo skojarzone (loosely coupled) Ściśle skojarzone (tightly 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 FBD: FSZBD jest odpowiedzialny za zarządzanie całością federacji. Pojedyncze federacje (pojedynczy schemat) Wielokrotne federacje (wiele schematów)

Postulaty rozproszenia BD

Komunikacja w rozproszonych BD

Ważne cechy rozproszonych BD
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, 2PC). 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).

Główne problemy rozproszonych baz danych
Wieloaspektowa niezgodność i konflikty między lokalnymi bazami danych z powodu: Awarii, Aktualizacji wielu źródeł i ogniw rozproszonego środowiska, Odniesienia danych do tej samej skali czasu

Tematy związane z rozproszonymi BD
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, OpenDoc, ActiveX, SOAP/XML. Pośrednicy (broker, ORB) wg standardu CORBA, np. Orbix, Visibroker, ...

Tematy związane z rozproszonymi BD cd..
Środki wspomagające rozproszenie bazy danych i rozproszone przetwarzanie zrealizowane w konkretnych systemach relacyjnych (Oracle, Sybase, Ingres, i inne), post-relacyjnych lub obiektowo-relacyjnych (Informix Universal Server, DB2 Universal Database, Oracle8, UniSQL/X, OSMOS, OpenIngres, Sybase Adaptive Server i inne) oraz obiektowych (Gemstone, Versant, O2, Objectivity/DB, ObjectStore 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.

Transakcje w rozproszonych BD

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.

Reguły rozproszenia

Replikacja

Fragmentaryzacja

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.

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

Niezależność od replikacji: Istnienie replik danych w wielu miejscach, ich pojawianie się lub usuwanie nie 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.

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.

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.

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

Pojęcia związane z rozproszeniem

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.

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.

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 4GL, 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.

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.

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 nie został zrealizowany w żadnym ze znanych systemów.

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.

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, DB2, Lotus Notes,.... ...oraz wymieniać pomiędzy sobą niejednorodne dane, podlegające różnym modelom danych, schematom, semantyce, mechanizmom dostępu,...

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

Przenaszalność Typy przenaszalności:
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.

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.

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

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.

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 W3C, gdzie ontologię reprezentują wyrażenia RDF.

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.

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.

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

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.

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 komponentowego podejścia wymienia się: OMG CORBA, OpenDoc firm Apple, IBM i innych, technologia .NET/COM/DCOM, Java Beans i Enterprise Java Beans. Komponenty odnoszą wiele sukcesów. Istnieją jednak problemy utrudniające szerokie ich stosowanie, tj: 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.

Obiektowość w systemach rozproszonych

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

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

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, wzorców, komponentów projektu, komponentów oprogramowania, itd. 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.

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.

Perspektywy w modelowaniu pojęciowym
odwzorowanie 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.

Przykład: pojęciowy schemat obiektowy w UML
Osoba Nazwisko Imi ę * Adres * Zatrudnienie Wyp ł ata * Ocena * Firma Nazwa Miejsce * Pracownik Zawód * PZ FZ 0..* 1 0..* 1 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?

Schemat relacyjny Jest to jedno z kilku możliwych rozwiązań.
Firma(NrF, Nazwa) Lokal(NrF, Miejsce) Zatrudnienie(NrF, NrP) Pracownik(NrP, NrOs) Oceny(NrOceny, Ocena, NrF, NrP) Dochód(NrDochodu, Wypłata, NrF, NrP) Osoba(NrOs, Nazwisko) Wyszkolenie(Zawód, NrP) Imiona(NrOs, Imię) Adresy(NrOs, 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).

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.NrF = z.NrF and z.NrP = p.NrP and p.NrOs = s.NrOs and s.NrOs =a.NrOs Zapytanie w SQL jest znacznie dłuższe wskutek tego, że w SQL konieczne są „złączeniowe” predykaty (takie jak k.NrF=z.NrF i następne) kojarzące informację semantyczną "zgubioną" w relacyjnej strukturze danych.

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 mogą nie mieć ogólnego rozwiązania.

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.

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

Projektowanie rozproszonych baz danych

Podejścia do projektowania rozproszonych BD: top-down i bottom-up
Od ogółu do szczegółów: 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. top-down Od szczegółów do ogółu: Zintegrowanie już istniejących (spadkowych) lub zaprojektowanych lokalnych baz danych w jedną globalną rozproszoną bazę danych. bottom-up

Projektowanie: podejście top-down
Analiza Analiza systemowa: rozpoznanie wymagań, precyzowanie kontekstu przyszłej bazy danych. Projektowanie schematu pojęciowego Projektowanie struktury logicznej 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 także jak należy zdekomponować schemat logiczny na poszczególne miejsca Model pojęciowy scentralizowany Model logiczny scentralizowany Kryteria rozproszenia Modele logiczne dla poszczególnych miejsc

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.

Fragmentacja Najpopularniejszym modelem jest fragmentacja pozioma, oznaczająca, że każdy serwer ma ten sam schemat danych, ale inną populację danych. Sumowanie zbiorów danych w taki sposób, że informacja o serwerach jest zbędna dla programisty/użytkownika. Fragmentacja pionowa: podział obiektów na fragmenty przechowywane w różnych miejscach. Musi być zapewniony sposób „sklejenia” całości obiektu z fragmentów (np. NIP dla obywateli RP). Przy integracji zasobów mogą pojawiać się wyrafinowane kombinacje fragmentacji poziomej, pionowej i replikacji (redundancji).

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.

Fragmentacja pionowa relacyjnej bazy danych
Warszawa Kutno DOSTAWCA_DANE DC DNR D1 D2 D3 D4 D5 NAZW Abacki Bober Czerny Dąbek Erbel STATUS 20 10 30 DNR D1 D2 D3 D4 CNR C1 C2 C3 C4 C5 C6 ILOŚĆ 300 200 400 100 Sieć Gdańsk DOSTAWCA_MIASTO DNR D1 D2 D3 D4 D5 MIASTO Lublin Poznań Radom

Fragmentacja pozioma relacyjnej bazy danych
Poznań DC DOSTAWCA DNR D2 D3 CNR C1 C2 ILOŚĆ 300 400 200 DNR D2 D3 NAZW Bober Czerny STATUS 10 30 MIASTO Poznań Lublin Sieć DOSTAWCA DNR D1 D4 NAZW Abacki Dąbek STATUS 20 MIASTO Lublin DC DNR D1 D4 CNR C6 C2 C4 ILOŚĆ 100 200 300 DOSTAWCA DNR D5 NAZW Erbel STATUS 30 MIASTO Radom

Przykład fragmentacji poziomej
Radom Klasa Pracownik Obiekty Pracownik są przechowywane zgodnie z geograficznym położeniem pracodawcy. Pracownik Nowak Pracownik Kowalski ... Sieć Kalisz Pracownik Styka Malina ... Klasa Pracownik Kielce Klasa Pracownik Pracownik Malasa Pracownik Zagórny. ...

Fragmentacja pionowa obiektów Pracownik
Radom Klasa danych osobistych Nowak dane osobiste Kowalski ... Sieć Kalisz Klasa danych o ocenach Nowak dane o ocenach Kowalski ... Kraków Klasa danych o zatrudnieniu Nowak dane o zatrud. Kowalski ...

Fragmentacja danych

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.

Replikacje Replikacja jest kopią danych i usług na innym serwerze.
Replikacje mają na celu zwiększenie dostępności danych i usług oraz ich ochronę przed zniszczeniem. Przy integracji bottom-up replikacje (redundancje) są często cechą nieuchronną i niepożądaną. Może występować redundancja danych o dowolnym stopniu skomplikowania. Replikacje i redundancje stanowią poważny problem dla przezroczystości i operacji aktualizacji danych.

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 pewną perspektywę (view), ukrywającą niektóre dane dla rozproszonych aplikacji.

Replikacja

Federacyjna BD tworzona metodą bottom-up
Aplikacje globalne Schemat federacyjnej bazy danych Perspektywa Mediator Osłona Perspektywa Mediator Osłona Baza danych 1 Miejsce 1 Schemat lokalny 1 Aplikacje lokalne Baza danych 2 Miejsce 2 Schemat lokalny 2 Aplikacje lokalne ..... 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.

Architektury rozproszonych
baz danych

Architektura klient - serwer
Serwer - komputer (proces) oferujący określony rodzaj usługi Klient - komputer (proces) korzystający z usługi Klient Klient Serwer Klient Klient

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) Podstawowe problemy: Określenie mechanizmu komunikacji pomiędzy klientem a serwerem. 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

Heterogeniczne środowisko w architekturze klient-serwer
Windows 95 Client Windows NT UNIX or NT TCP/IP network Windows NT Server with repository on SQLserver UNIX Server with repository on Informix

Architektury serwerów w dostępie do bazy danych
Serwer plików, Serwer SQL, Serwer obiektów, Serwer stron.

Architektura z serwerem plików
klient serwer Zapotrzebowanie na odczyt/zapis danych w plikach Aplikacja po stronie klienta odwołuje się do danych umieszczonych w pliku bazy danych Alokacja pamięci WE/WY obsługa plików z bazą danych Odczytane dane z plików bazy danych

Transfer plików Protokół FTP (File Transfer Protocol) Usługa FTP:
kopiowanie plików z komputerów odległych do komputera użytkownika kopiowanie plików z komputera użytkownika do komputerów odległych Dostęp do danych (ograniczony, system weryfikacji użytkownika) Środowisko pracy: tekstowe (program ftp w środowisku systemowym) graficzne (dedykowane aplikacji komercyjne, przeglądarki)

Procedura transferu plików
Podłączenie się do serwera odległego Wejście użytkownika do systemu plików Nawigacja w strukturze katalogów Określenie rodzaju transferu Pobranie/osadzenie plików Zamknięcie połączenia

Typowe instrukcje usługi FTP
open - podłączenie się do serwera user - wejście użytkownika do systemu (ftp, anonymous) close - zamknięcie połączenia dir - wyświetlenie zawartości katalogu na serwerze cd - zmiana katalogu bieżącego na serwerze lcd - zmiana katalogu bieżącego na komputerze klienta bin - binarny rodzaj transferu asc - znakowy rodzaj transferu put - przesłanie pliku z komputera klienta do serwera get - pobranie pliku z serwera mput - przesłanie plików z komputera klienta do serwera mget - pobranie plików z serwera

Architektura z serwerem SQL
Aplikacja klienta zadaje zapytanie SQL Zapytanie SQL Maszyna SQL Zarządzanie kursorem krotka serwer klient

Architektura z serwerem stron
klient serwer aplikacja Menadżer stron pamięci podręcznej Pamięć podręczna stron Menadżer dziennika blokowania Menadżer obiektów Menadżer plików/indeksów Menadżer stron pamięci podręcznej Alokacja pamięci WE/WY strony Pamięć podręczna obiektów Pamięć podręczna stron

Architektura serwera stron
Aplikacja Interfejs zapytaniowy Optymalizacja zapytań Przeglądarka obiektów Interfejs programistyczny Przedmiotem zarządzania są fizyczne strony dyskowe Zarządzanie obiektami Zarządzanie plikami i indeksami Zarządzanie kieszenią stron strony Zarządzanie zamkami Zarządzanie składem Zarządzanie kieszenią stron Obiektowa baza danych

Architektura z serwerem obiektów
klient Pamięć podręczna obiektów Menadżer obiektów Menadżer dziennika blokowania Aplikacja Menadżer plików/indeksów Menadżer stron pamięci odręcznej Pamięć podręczna stron Menadżer obiektów obiekty Alokacja pamięci WE/WY Pamięć podręczna obiektów

Architektura serwera obiektów
Aplikacja Przeglądarka obiektów Interfejs zapytaniowy programistyczny Zarządzanie obiektami Przedmiotem zarządzania są obiekty obiekty Zarządzanie obiektami Optymalizacja zapytań Zarządzanie zamkami Zarządzanie składem Zarządzanie stronami i kieszeniami Obiektowa baza danych

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.

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.

Przykład architektury SZBD typu klient-serwer
Aplikacja generująca transakcje Zarządzanie transakcjami buforami Zarządzanie zasobami Klient 1 Klient n . . . Zarządzanie siecią Interfejs serwera Zarządzanie transakcjami buforami zasobami Serwer logiem zamkami

Architektura klient-(multi) serwer (1)
Połączenia bezpośrednie: k2 k3 k7 k1 s4 k4 s1 k8 s3 k5 s2 k9 k6 k10 k11

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. k1 k2 s4 k3 k9 k4 s1 Sieć komputerowa k8 k5 s3 k6 s2 k7

Architektura trzywarstwowa i wielowarstowa
three-tier architecture multi-tier architecture Architektura klient-serwer podzielona na trzy warstwy: interfejs użytkownika, logikę przetwarzania (reguły biznesu, logikę biznesu) 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. Interfejs użytkownika Logika przetwarzania Serwer bazy danych

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: 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. cienki klient Warstwa prezentacyjna (interfejs użytkownika) gruby klient Warstwa przetwarzania (logika biznesu) Zasada oddzielania aspektów (separation of concerns principle, E.Dijkstra) Warstwa zarządzania bazą danych

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.

Architektury dwuwarstwowe
Uproszczone architektury trójwarstwowe z cienkim lub grubym klientem. Warstwa prezentacyjna (interfejs użytkownika) + Warstwa przetwarzania (logika biznesu) cienki klient Warstwa prezentacyjna (interfejs użytkownika) gruby klient Warstwa przetwarzania (logika biznesu) + Warstwa zarządzania bazą danych 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.

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

Przykład architektury K/S - portal WWW
interakcja poprzez HTTP klient zapytania SQL Serwer Web: generacja dynamicznych stron HTML dla klienta + zlecenia do bazy danych Serwer bazy danych: wykonywanie zapytań w SQL wyniki zapytań SQL

3-warstwowa architektura aplikacji Web
Serwer Web Sieć Internet Serwer aplikacji Serwer bazy danych HTTP Baza danych Baza danych Przeglądarka Serwer

2-warstwowa architektura aplikacji Web
Wiele warstw pośredniczących powoduje dodatkowe obciążenie. Serwer Web Serwer aplikacji Sieć Internet Serwer bazy danych HTTP Baza danych Baza danych Przeglądarka Serwer

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

Architektura rozproszonych obiektów
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.

Architektura klient-broker-serwer
Dostęp do odległych zasobów sieci komputerowej odbywa się miedzy klientem (klientami) a serwerem (serwerami) nie odbywa się bezpośrednio lecz za pomocą pośrednika (brokera) Pośrednik zapewnia przezroczystość do odległych geograficznie zasobów, Broker przedstawia wszystkie zasoby w postaci zbioru obiektów, dzięki czemu możliwe jest ujednolicenie operacji wykonywanych na zasobach, niezależnie od ich implementacji i realizacji wewnętrznej, Fizyczna lokalizacja obiektów nie jest istotna dla użytkownika, gdyż położenie obiektów znane jest brokerowi, Pośrednik otrzymuje zadanie od klienta, lokalizuje serwer z potrzebnymi zasobami, przekazuje zlecenie oraz przekazuje zwrotnie wynik zlecenia zrealizowanego przez serwer do klienta

Architektura klient-broker-serwer
Host klienta Host serwera zlecenie Wywołanie operacji Pośrednik (Broker) wynik, parametry WY Klient Obiekt

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 Pośrednik Pośrednik Szyna oprogramowania (software bus) Miejsce 1 Miejsce 2 Miejsce 3

Struktura logiczna rozproszonych obiektów
Obiekty O9 O4 O6 O8 K1 K3 Operacje na obiektach K2 K4 Szyna oprogramowania (software bus) Aplikacje A1 A2 A3 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.

„Semistrukturalna” architektura aplikacji internetowych
Narzędzia wspomagające XML : system autorski, itd. Przeglądarka WWW Warstwa klienta XML XML Serwer Web Serwer aplikacji Logiczna warstwa pośrednia Interakcja z aplikacjami poprzez protokoły oparte na XML Baza danych w XML (strukturalizowana) Serwer integrujący XML, serwer zapytań, serwer hurtowni danych XML XML XML XML Translatory formatów z/do XML, pomosty Zasoby danych Obiektowo-relacyjna baza danych wspomagająca XML Obiektowa baza danych wspomagająca XML Inne dokumenty na Webie: HTML Word,... Dokumenty XML na Webie Zasoby danych pod OLE/DB

Standardy łączenia rozproszonych zasobów

Standardy łączenia rozproszonych danych (1)
Open DataBase Connectivity (ODBC): standard [zdalnego] dostępu do relacyjnych baz danych bazuje na Call Level Interface (CLI) opracowanym przez konsorcjum X/Open definiuje API oraz cechy SQL które muszą być zapewnione na różnych poziomach zgodności. Java DataBase Connectivity (JDBC): analogiczny do ODBC standard dla Java. Standardy X/Open XA: definiują zarządzanie transakcjami ze wspomaganiem protokołu 2PC. OLE-DB: API podobne do ODBC, ale wspomagające źródła nie-bazodanowe, takie jak płaskie pliki. OLE-DB program może negocjować ze źródłem danych aby znaleźć własności, które ono podtrzymuje. API jest podzbiorem SQL

ADO (Active Data Objects): łatwy interfejs do funkcji OLE-DB Kilka standardów bazujących na XML dla E-commerce Np. RosettaNet (łańcuchy dostaw), BizTalk Definiują katalogi, opisy usług, faktury, zamówienia, itd. osłony XML są używane do eksportu informacji z relacyjnej BD do XML Resource Description Framework (RDF): specyfikacja ontologii dla zasobów Web. 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)

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. Java Beans i Enterprise Java Beans wykorzystują RMI jako transport.

Replikacje

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

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.

Modele replikacji Jednoczesne aktualizacje
ze sterowaniem współbieżnościa Propagacja aktualizacji Transakcja aktualizująca Transakcja aktualizująca propagacja aktualizacji propagacja aktualizacji Replika 3 Replika 1 Replika 1 Replika 2 Replika 3 Replika 2 Planowane odświeżanie kopii dla replik tylko do czytania Transakcja aktualizująca planowana aktualizacja Transakcja czytająca planowana aktualizacja Replika 3 Replika 1 Transakcja czytająca Replika 2

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): Przy dokładnej analizie należy utworzyć bardziej złożone modele kosztów, które ustalą opłacalność replik. ilość zapytań czytających ilość zleceń aktualizujących Jeżeli > ilość replik to warto tworzyć repliki. W przeciwnym przypadku - nie warto.

Przetwarzanie transakcji

Przetwarzanie transakcji
Problemy z transakcjami w systemach rozproszonych: Faza potwierdzenia (commit) może trwać długo. Niepowodzenie (awaria) w tej fazie może spowodować niespójność bazy danych i przetwarzania. Stąd nowe protokoły przetwarzania transakcji w systemie rozproszonym: 2PC, 3PC. Zakleszczenie: wykrywanie i usuwanie jest znacznie trudniejsze, gdyż wymaga przesyłania w sieci informacji która transakcja czeka na którą. Ziarnistość mechanizmu transakcji: bezpośrednio związana z dostępnością rozproszonej bazy danych (liczbą jednocześnie pracujących użytkowników). Wydajność (performance): złożone protokoły powodują jej zmniejszenie; stąd 2PC i 3PC są często nieadekwatne. Długie transakcje: konieczność zmniejszenia poziomu izolacji aby umożliwić dostęp do zablokowanych danych.

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ą. potwierdzenie (commit) koniec start zakładanie zamków (nie ma zwalniania) zwalnianie zamków (nie ma zakladania) czas Awaria w fazie potwierdzenia jest krytyczna, gdyż grozi utratą spójności. W systemach rozproszonych faza potwierdzenia może trwać minuty i włącza zawodne zawodne elementy infrastruktury (łącza). Warunek atomowości oznacza, że jeżeli transakcja dzieli się na wiele podtransakcji wykonywanych na odległych serwerach, to nie może zajść sytuacja, gdy podtransakcja na serwerze A jest potwierdzona, zaś podtransakcja na serwerze B jest zerwana. Stąd konieczność dodatkowej ochrony fazy potwierdzenia => 2PC.

Dwufazowe potwierdzenie (2PC)
Koordynator (program aplikacyjny klienta) SZBD klienta potwierdź potwierdź potwierdź gotów gotów 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.

2PC - zarządzanie awariami
Dość złożone postępowanie zależne od tego, czy awarii uległ serwer czy też koordynator. Protokół 2PC określa: Czas graniczny (timeout) nadesłania sygnału "gotów" od wszystkich serwerów do koordynatora . Jeżeli czas graniczny minął oraz nie ma wszystkich sygnałów "gotów", to koordynator wysyła do wszystkich serwerów sygnał "zerwij". Sposób rejestracji sygnałów od koordynatora w dzienniku serwera. W razie awarii serwera, po jego ponownym postawieniu, analizowany jest dziennik celem stwierdzenia, czy transakcja ma być potwierdzona, czy zerwana. Problem blokowania: w razie awarii koordynatora wszystkie transakcje na serwerach, które zgłosiły "gotów" są przyblokowane. Serwery "nie wiedzą", co dalej robić. Postawienie koordynatora może trwać długo. Bardziej złożony protokół 3PC uwzględnia awarie koordynatora . 3PC nie znalazł jednak szerszego zastosowania ze względu na duże narzuty na wydajność aplikacji.

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.

Transakcje w federacyjnej bazie danych (2)
Lokalne bazy danych mogą stosować różnorodne algorytmy przetwarzania transakcji. Autonomia oznacza, że federacja nie ma wpływu na te algorytmy. Lokalna BD może w każdej chwili z różnych powodów (np. zakleszczenia) zerwać dowolną transakcję, w tym podtransakcję indukowaną przez globalną transakcję. Informacja o wewnętrznym stanie lokalnie przetwarzanych transakcji (np. stan dziennika transakcji, zamki zakładane przez transakcje, itd.) nie jest widoczna na zewnątrz. Stosowanie typowych algorytmów, np. 2PC (two phase commit) jest niemożliwe, gdyż lokalna BD może nie posiadać możliwości zawieszenia podtransakcji w stanie “gotowa” i czekać na sygnał potwierdź ze strony globalnej transakcji.

Niezgodności schematów i ontologii

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.

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.

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.

Niezgodności dotyczące odniesienia danych do skali czasowej. Informacje mogą być np. aktualizowane natychmiast, zaś w innej BD raz na miesiąc. Niezgodności w sposobach dostępu. W jednej BD dostęp do danych będzie realizowany na przykład przy pomocy standardowego SQL, a w innej poprzez środki dostępu pewnego języka czwartej generacji lub API. Różna strukturalizacja informacji. Np. w jednej BD utworzono odrębną tabelę PrzynależnośćDoZwiązkuZawodowego, zaś w innej ta przynależność jest atrybutem tabeli Pracownik; w jednej BD atrybut Adres jest polem tekstowym, w innej zaś strukturą z polami Miejscowość, Ulica, NrDomu, itd. Podział danych i metadane. Np. w jednej BD atrybut Zawód tabeli Pracownicy jest stringiem, zaś w innej utworzono odrębne tabele. Piekarze, Stolarze, itd. Niezgodności jest bardzo dużo. Niezależnie zbudowane lokalne bazy danych zawsze będą obciążone tego rodzaju konfliktami.

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.

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.

Federacyjne bazy danych

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.

Architektura federacyjnej bazy danych
Aplikacje globalne Aplikacje globalne ... FSZBD 1 Przestrzeń robocza FSZBD m Przestrzeń robocza Schemat FBD Schemat FBD Sieć komputerowa Schemat eksportowy 1 Osłona 1 API 1 Schemat eksportowy 2 Osłona 2 API 2 Schemat eksportowy n Osłona n API n ... Lokalny SZBD 1 Lokalny SZBD 2 Lokalny SZBD n BD 1 BD 2 BD n Aplikacje lokalne Aplikacje lokalne Aplikacje lokalne

Architektura dostępu do lokalnej BD
Global schema (in an extended ODL) External sub-schemata (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 Obiekty A Dane A Interfejs IA1 Dostęp Zakaz Zakaz Interfejs IA2 Zakaz Zakaz Dostęp Obiekty A Dane B Interfejs IB1 Dostęp Zakaz Dostęp API Osłona Mediator Obiekty A Dane C Interfejs IC1 Zakaz Dostęp Zakaz Ob.wirt. V3 Dane wirt. V1 Perspektywa V1 Zakaz Dostęp Dostęp Ob.wirt. V3 Dane wirt. V2 Perspektywa V2 Dostęp Zakaz Zakaz ustala definiuje Administrator lokalnej bazy danych Użytkownik 1 Użytkownik 2 Użytkownik 3

Trój-warstwowa architektura federacyjnej BD
Użytkownik 1 Użytkownik 2 Użytkownik 3 3 Schemat zewnętrzny 1 Schemat zewnętrzny 2 Schemat zewnętrzny 3 2 Schemat federacyjny FSZBD Przestrzeń robocza Sieć 1 Schemat eksportowy 1 Osłona 1 API 1 Schemat eksportowy 2 Osłona 2 API 2 ... Lokalny SZBD 1 Lokalny SZBD 2 BD 1 BD 2

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

Rozproszone BD w standardzie CORBA
Oprogramowanie komponentowe budowane wg standardu CORBA może być podstawą rozproszonych/federacyjnych baz danych. Host globalnej aplikacji Host lokalnej BD Obiekty Obiekty Klient Obiekty Implementacja interfejsów do obiektów (szkielety + kod) Wywołanie operacji Pieniek klienta zlecenie 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.

Problemy z RBD w standardzie CORBA
CORBA nie jest nastawiona na przetwarzanie danych trwałych i masowych przy pomocy języków zapytań. Jest to poziom języków takich jak C++ i Java, znacznie niższy. Obecny stan standardyzacji w zakresie Query Service i Persistence Service jest uważany za niezadowalający. CORBA nie wprowadza pojęcia perspektywy. Osłony w CORBA są pisane w językach niskiego poziomu, są zorientowane na daną aplikację, nie dają konceptualizacji takiej, jaką dają perspektywy. Mogą być znaczne narzuty na wydajność maszynową i produktywność programistów globalnych aplikacji. CORBA nie rozwiązuje problemów związanych z przetwarzaniem transakcji w rozproszonych/federacyjnych bazach danych. Model obiektowy CORBA jest ograniczony, m.in. nie uwzględnia związków i zagnieżdżonych kolekcji. Te możliwości są uwzględniane w usługach (np. Relationship Service), które nie są realizowane.

Osłony i mediatory

Osłona Podstawowe zadanie: fizyczne połączenie różnych baz danych.
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

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 SZBD do interfejsu programistycznego obowiązującego w federacji. Federacyjny SZBD API f API f API f ... Osłona 1 Osłona 2 Osłona n API 1 API 2 API n Lokalny SZBD 1 Lokalny SZBD 2 Lokalny SZBD n

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

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: Rozstrzyganie rozbieżności pomiędzy schematem lokalnym a schematem 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).

Perspektywy

Perspektywy Podstawowe problemy:
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.

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 Użytkownik 2 Użytkownik 3 Schematy “zewnętrzne” Perspektywa 1 Perspektywa 2 Perspektywa 3 Projektant BD Administrator BD W tym sensie pojęcie perspektywy funkcjonuje w literaturze z zakresu modeli danych, analizy i projektowania. Schemat globalny Poziom fizyczny bazy danych Administrator BD

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>

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

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 makro-definicję, 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).

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: ) Perspektywy wolno użyć w zdaniach SQL (prawie) na takich samych zasadach jak zapamiętanej tabeli. SELECT Zarobki FROM Urzędnicy WHERE Nazwisko = ‘Nowak’

Relacyjna baza danych z perspektywami
Użytkownik lub program aplikacyjny SQL Perspektywa V1 Perspektywa V2 Dane wirtualne Tablica BD B1 Tablica BD B2 Tablica BD B3 Tablica BD B4 Dane rzeczywiste (logiczne) Dane zapamiętane (fizyczne)

Przykład relacyjnej bazy danych
DC DOSTAWCA DNR D1 D2 D3 D4 CNR C1 C2 C3 C4 C5 C6 ILOŚĆ 300 200 400 100 DNR D1 D2 D3 D4 D5 NAZW Abacki Bober Czerny Dąbek Erbel STATUS 20 10 30 MIASTO Lublin Poznań Radom CZĘŚĆ CNR C1 C2 C3 C4 C5 C6 NAZWAC Nakrętka Wkręt Podkładka Nit Tulejka KOLOR Czarwony Zielony Niebieski Czerwony WAGA 12 17 14 19 MIASTO Lublin Poznań Rzeszów

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

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.

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.

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.

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

Przykład aktualizacji perspektyw (1)
Dane rzeczywiste Dane wirtualne Pracownik Nazwisko Zarobek /MojeDziały Nazwa ŚredniZarobek Dział Nazwa zatrudnia * Podwyższ średni zarobek w dziale „Krasnale ogrodowe” o 500 zł: ? update MojeDziały set ŚredniZarobek = ŚredniZarobek + 500 where Nazwa = ‘Krasnale ogrodowe’; Zlecenie jest błędne, gdyż: Nie ma danej o nazwie ŚredniZarobek. 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.

Przykład aktualizacji perspektyw (2)
Dane rzeczywiste Dane wirtualne zatrudnia Pracownik Nazwisko Zarobek /MoiPracownicy Nazwisko NazwiskoSzefa Dział Nazwa * szef 0..1 Przyjmujemy strategię implementacji perspektyw polegającą na tym, że po wyliczeniu perspektywy MoiPracownicy 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 MoiPracownicy set NazwiskoSzefa = ‘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.

Ograniczenia w aktualizacji perspektyw
System Oracle: W klauzuli SELECT nie ma słowa DISTINCT W klauzuli FROM jest tylko jedna nazwa tabeli lub 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.

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 MoiLudzie( IdPracownika, Nazwisko, IdDziału, NazwaDział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 MoiLudzie SET Zarobek = Zarobek + 500 WHERE NazwaDziału = ‘Krasnale ogrodowe’ OK. UPDATE MoiLudzie SET NazwaDziału = ‘Lalki Barbie’ WHERE Nazwisko = ‘Nowak’ Przenieść programistę Nowaka do działu Lalek Barbie: Źle!

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

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.

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 BiednyPracownik (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ę.

Perspektywy z opcją sprawdzania
CREATE VIEW MałoZarabiają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łoZarabiają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.

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.

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, 45, 77, itd., gdzie 11 oznacza projektant, 45 oznacza analityk, 77 oznacza sprzątaczka, itd. Federacja wymaga pełnych nazw zawodów. Potrzebna jest dodatkowa funkcja, która zamieni numery na stringi. Definicja perspektywy musi więc zawierać definicję trwałej tabeli z numerami i stringami. Przykład 1: Dla celów kontroli utworzona jest perspektywa w postaci tabeli WynikiKontroli( NrUrządzenia, NazwaUrządzenia, OcenaKontrolera ) NrUrządzenia i NazwaUrządzenia pochodzą z lokalnej BD. Natomiast OcenaKontrolera 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. Przykład 2: 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.

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.

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

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: StaryStudent (Id, Nazwisko, RokStudiów, ŚredniaOcena ) Nowy system: NowyStudent (Id, Nazwisko, NrIndeksu ) 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 StaryNowyStudent( Id, Nazwisko, NrIndeksu) AS SELECT Id, Nazwisko, NULL FROM StaryStudent Pozostają problemy spójnej aktualizacji oraz wydajności. CREATE VIEW Student( Id, Nazwisko, NrIndeksu) AS SELECT * FROM StaryNowyStudent UNION SELECT * FROM NowyStudent

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 n1, n2,..., definicja perspektywy używa nazw m1, m2,... przy czym zbiory {n1, n2,...} i {m1, m2,... } 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.

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 ich rodzajów, które “zwracają” zapamiętane obiekty w niezmienionej postaci. W tym względzie sytuacja jest gorsza niż w modelu relacyjnym.

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

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

Podejścia do obiektowych perspektyw
Podejście Abiteboula i Bonnera, Rundensteinter et al (MultiView), 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.

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?

Przetwarzanie zapytań

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.

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 umożliwić serwerowi skuteczniejszą optymalizację podzapytania).

Indeksowanie rozproszonych zasobów
Szczególnie istotne w przypadku technologii P2P, 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 AltaVista, 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

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

Statyczny schemat przetwarzania zapytań (2)
Serwer S1 Klient Z1 W1 Z2 Serwer S2 Dekompozycja zapytania Z W2 ... Scalenie wyników Zk Wynik W zapytania Z Serwer Sk Wk 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 = Z1 = Z2 = ... = Zk Scalenie wyników polega na sumie mnogościowej wyników cząstkowych.

Dynamiczny schemat przetwarzania zapytań
1. Klient realizuje zapytanie Z odwołujące się do danych na serwerach S1, S2,..., Sk 2. Klient dokonuje odwzorowania zapytania Z na podzapytanie Z1 adresowane do serwera S1 (na podstawie schematu S1). Z1jest konstruowane z Z w taki sposób, aby jego wynik W1 uzyskany z S1 wystarczył do realizacji zapytania Z. 3. Z1jest kierowane do serwera S1, gdzie jest wykonywane. Serwer S1 zwraca do klienta wynik W1 podzapytania Z1. 4. Na podstawie znajomości W1 klient konstruuje z Z kolejne podzapytanie Z2 kierowane do serwera S2. Może do tego serwera skierować pewien fragment W1, nazwijmy go F1; .... proces jest powtarzany dla wszystkich serwerów, aż do uzyskania rezultatu. Klient Z  Z1 Z1 W1 Serwer S1 (Z, W1)  Z2, F1 Z2, F1 W2 Serwer S2 (Z, W1, W2)  Z3, F2 Z3, F2 W3 Scalenie wyników Serwer S3

Przykład: technika pół-złączeń (1)
semijoin Serwer 1 Serwer 2 DOSTAWCA DC DNR D1 D2 D5 NAZW Abacki Bober Erbel STATUS 20 10 30 MIASTO Lublin Poznań Radom DNR D1 D2 D3 D4 CNR C4 C5 C1 C2 ILOŚĆ 200 100 300 400 Klient ma dokonać złączenia relacji DOSTAWCA i relacji DC: select * from DOSTAWCA, DC where DOSTAWCA.DNR = DC.DNR

W celu realizacji zapytania klient musi wykonać następujące czynności: 1. Sciagą dane z serwera 1 przy pomocy zapytania Z1: select * from DOSTAWCA Uzyska w ten sposób wynik W1. W1 DNR D1 D2 D5 NAZW Abacki Bober Erbel STATUS 20 10 30 MIASTO Lublin Poznań Radom 2. Tworzy pomocniczą tabelę poprzez projekcję W1 na DNR: tę tabelę nazywa F1. DNR D1 D2 D5 F1 3. Wysyła tabelę F1 do serwera 2 żądając tymczasowego ulokowania jej w bazie danych serwera 2; następnie wysyła tam zapytanie Z2: select * from DC, F1 where DC.DNR = F1.DNR

4. Uzyska w ten sposób wynik W2: Jest to tzw. pół-złączenie relacji DC, parametryzowane relacją DOSTAWCA. Pół-złączenie relacji R1, parametryzowane relacją R2, powstaje poprzez złączenie R1 z R2, a następnie projekcję wyniku na atrybuty relacji R1 W2 DNR D1 D2 CNR C4 C5 C1 C2 ILOŚĆ 200 100 300 400 5. Przesyła wynik W2 - pół-złączenie - do klienta 6. Klient dokonuje ostatecznego scalenia wyników - złączenia relacji W1 i W2. CNR C4 C5 C1 C2 ILOŚĆ 200 100 300 400 DNR D1 D2 NAZW Abacki Bober STATUS 20 10 MIASTO Lublin Poznań Wynik 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.

Metody dostępu do baz danych sterowniki

Potrzeby ? Różne DBMS mogą realizować różne wersje SQL dla realizacji języków definicji danych (DDL) i manipulacji danymi (DML). Interfejsy bezpośredniego dostępu do tych DBMS, stworzone przez różnych producentów, też mogą się różnić. Wskutek tego konsekwentności zapytań SQL do różnych baz danych, różnych serwerów SQL mogą też się różnić. To znaczy, np., że dla bazy danych w środowisku „ORACLE” trzeba konstruować inne konsekwentności zapytań SQL niż dla tej samej bazy w środowisku „INFORMIX”. W celu usunięcia tej wady firma MICROSOFT w 1992r opracowała standard ODBC (Open Database Connectivity).

Co to jest ODBC ? Technologia ODBC wprowadza jedyny interfejs dostępu do różnych typów baz danych. Język SQL jest wykorzystywany jako główny uniwersalny dialekt wszystkich baz danych. Standard ODBC pozwala realizować technologię „Klient – Serwer”, która realizuje główne operacji przetwarzania danych na serwerze, a klient tylko otrzymuje rezultaty. Aplikacje nie są połączone z konkretnym interfejsem jakikolwiek DBMS, a realizują jedyny standard zapytań do menedżera ODBC – sterowników (ODBC-drivers). Menedżer ODBC podłącza potrzebny ODBC – sterownik, który jest stworzony przez producenta konkretnej DBMS. Dla podłączenia ODBC – sterownika trzeba stworzyć profile ODBC w trybie (Source ODBC…) panelu sterowania systemu operacyjnego. Teraz istnieją ponad 50 typów ODBC – sterowników dla różnych DBMS. Standard ODBS pozwala realizować zapytania SQL bezpośrednio z programów użytkownika. W tym celu można wykorzystywać dynamiczny SQL.

Architektura ODBC

Schemat współpracy różnych narzędzi w architekturze „ Klient – Serwer” w sieci LAN
Aplikacja na stancji klienta realizuje zapytania do baz danych przez ODBC Manager. Zapytania mogą być dla lokalnej bazy danych lub do baz danych umieszczonych na innych serwerach sieci lokalnej. Na rys. pokazano trasy wszystkich zapytań.

Główne wady technologii dostępu do baz danych przez ODBC
Aplikacje są przystosowane do platformy MS Windows Wzrasta czas obróbki zapytań dzięki dodatkowej warstwie programówJest potrzebna uprzednia instalacja ODBC – sterownika, profile ODBC dla każdej stacji. Parametry tej instalacji jest statyczne i użytkownik nie może ich zmienić.

Uniwersalne strategii dostępu
Technologia ODBC firmy Microsoft zaopatrzy ogólny interfejs dostępu do baz danych, które są kompatybilne przez SQL. Każda baza danych mająca interfejs ODBC zawiera sterownik (driver) , który realizuje bezpośrednio ten interfejs. Interfejs zawiera bibliotekę funkcji specjalnych napisanych w języku C++ . Zastosowanie tej biblioteki może być wadą przy realizacji dostępu aplikacji stworzonych w innym środowisku języków oprogramowania. Żeby usuwać te wady różne producenci stwarzają specjalne komponenty obiektowe dostępu do baz danych.

Przykład komponentów firmy Microsoft

Przykład komponentów firmy Microsoft – cd…
Obiektowy model DAO (Data Access Objects) jest przeznaczony w środowiskach Microsoft Access oraz Visual C++. DAO zawiera obiekty baz danych (component DataBase), obiekty tabel(component TableDef), obiekty definicji kwerend (component QueryDef), obiekty rezultatów zapytań do bazy danych (component RecordSet) oraz inne obiekty. Model DAO jest przeznaczony przede wszystkim dla dostępu do baz danych Access. Ten model nie odpowiada wszystkim standardom oraz specyfikacjom SQL . Ten model teraz jest zamieniony nowym modelem RDO (Remote Data Obiekt). RDO wchodzi do Visual Basica, Visual FoxPro oraz do Microsoft SQL Servera. Firma Microsoft zaproponowała zbiór obiektów OLE DB( Object Linking and Embedding for DataBase), który pozwala aplikacjom wykorzystywać oraz sterować danymi w bazach danych przez swoje obiekty. Technologia OLE DB gwarantuje dostęp do jakikolwiek baz danych włącznie nie relacyjne modeli danych. Oprócz tego przez OLE DB można udostępnić do plikowych oraz pocztowych systemów, graficznych plików, innych obiektów stworzonych w różnych aplikacjach. Technologia OLE DB jest obiektowo - orientowana specyfikacja na podstawie C++ API.

Technologia ADO (Active Data Obiects) to jest rozwiązanie technologii ASP dostępu do baz danych, które jest realizowane we WWW serwerze IIS (Internet Information Server) firmy Microsoft. Technologia ADO zawiera wszystkie lepsze cechy technologii RDO oraz DAO i musi zamienić te ostanie technologii. Technologia ADO zawiera następne funkcje: Stworzenia niezależnych obiektów baz danych Wsparcie zapamiętanych procedur baz danych Stworzenia kursorów dostępu do danych Wsparcie mechanizmów transakcji. Głównymi zaletami technologii ADO są nie komplikowane wykorzystanie, prędkość, małe obciągi RAM oraz disku.

Model obiektowy ADO zawiera 6 głównych klasy obiektów: CONNECTION COMMAND PARAMETERS RECORDSET FIELDS ERRORS. Obiekt CONNECTION połączy związek pomiędzy aplikację oraz źródłem danych. Utworzenia takiego połączenia zawsze jest pierwszym etapem obsługi bazy. Ten obiekt pozwala także uruchomić instrukcje SQL. Dla zachowywania rezultatów instrukcji trzeba stworzyć obiekt klasy RECORDSET. Klasa CONNECTION zawiera następne metody: Open( ) , Close( ) – połączenie lub wyłączenia ze źródłem danych Execute( ) – uruchomienie instrukcji dla wyznaczonego połączenia BeginTrans( ), CommitTrans( ) oraz RollbackTrans( ) – sterowanie transakcjami dla danego połączenia.

Obiekt COMMAND zawiera instrukcję SQL lub wywołanie zapamiętanej procedury. Ten obiekt może mieć kolekcję parametrów, które mogą być zadane przez obiekty klasy PARAMETER. Klasa COMMAND zawiera następne metody: Execute( ) – uruchomianie instrukcji dla danego połączenia CreateParameter( ) – tworzenie nowego parametru(obiektu klasy PARAMETER) Kolekcja PARAMETERS zawiera wszystkie parametry, które są wykorzystywane razem z danym obiektem COMMAND. Parametry te są przechowywane w obiektach klasy PARAMETER. Klasa PARAMETERS zawiera następne metody: Append(), Delete() – dodawanie (usuwanie) parametru dla danej kolekcji Item() – wywołanie wyznaczonego obiektu PARAMETR Refresh() – wywołanie informacji pro parametry właściciela zapamiętanej procedury.

Obiekt RECORDSET pozwala na operowania danymi przechowywanymi w tabeli. Obiekt ten zawiera zbiór rekordów pobranych z tabeli. Pozwala on na odczytywanie danych przechowanych w tabeli, modyfikowanie ich oraz gromadzenie informacji, jakie mają być dodane do bazy. Aktualne analizowany rekord oraz jego położenie względem pozostałych rekordów zbioru określane przez kursor bazy danych. Kursor to jest obiekt zawierający rezultat polecenia do bazy danych. Przy stworzeniu obiektu RECORDSET wskaźnik rekordu bieżącego kursora odwzorowuje pierwszy rekord zbioru, a atrybuty BOF oraz EOF otrzymają wartości FALSE. Kiedy zbiór jest pusty atrybut RecordCount otrzyma wartość 0 (zero), lecz BOF oraz EOF – wartości TRUE.

Klasa RECORDSET zawiera następne metody: MoveFirst(), MoveLast(), MoveNext(), MovePrevious() oraz Move() – przesuwają wskaźnik rekordu bieżącego. Obiektami RECORDSET są kursory, które mogą być sterowanymi tylko w jednym kierunku lub w dwóch kierunkach zbioru rekordów. W przypadku jednokierunkowego kursora można przechodzić jedynie do następnego rekordu zbioru, nie istnieje możliwości cofania się do poprzedniego wiersza lub przeskakiwania o kilka rekordów do przodu lub do tylu zbioru. Tutaj może być wykorzystywana tylko metoda MoveNext(). Dla wyznaczenia końca lub początku rekordów trzeba wykorzystać atrybuty BOF oraz EOF obiektu RECORDSET. AddNew(), Update() oraz Delete() – dodawanie nowych rekordów, aktualizacja oraz usuwanie istniejących rekordów, które jest związane z obiektem REKORDSET. Open(), oraz Close() – uruchomienie (Zamknięcie ) kursora, który reprezentuje rezultaty instrukcji, która jest poprzednio stworzona przez obiekt COMMAND. Metoda Open() odsyła na już stworzony obiekt CONNECT.

Każdy obiekt RECORDSET zawiera kolekcję FILDS, która są zbiorem obiektów klasy FIELD. Każdy obiekt FIELD reprezentuje jedną kolumnę tabeli danych. Na każdy obiekt FIELD w kolekcji FIELDS można odwalać przez nazwę lub liczbę numeryczną. Kolekcja ERRORS jest stworzona dla zachowywania informacji pro jakikolwiek błędy. Obiekt ERROR reprezentuje błąd wygenerowany przez źródło danych. Kolekcja ERRORS jest używana w sytuacji, gdy jedno wywołanie metody może wygenerować większą ilość błędów. Przy stworzeniu obiektu RECORDSET można wykorzystać dwa typy kursorów: jednokierunkowy lub dwukierunkowy. Podczas wywołania metody Open() obiektu RECORDSET domyślnie tworzony jest kursor jednokierunkowy. Kursor tego typu jest najbardziej efektywny, jednak oferuje ograniczone możliwości poszukiwania się po zbiorze rekordów .

Dwukierunkowe kursory zawierają następne typy: Statyczny. Wyniki wykonania zapytania są przechowywane w tabeli tymczasowej, której wierszy nie są modyfikowane w momencie, gdy kursor jest otwarty. Zbiór kluczy. Kursory tego typu zapisują w tymczasowej bazie danych klucze wszystkich wierszy zwróconych w wyniku wykonania polecenia. Dzięki przechowywaniu jedynie kluczy, wszelkie modyfikację rekordów wykonane w czasie gdy kursor jest otwarty, będą zauważane. Dynamiczny. W przypadku użycia kursora dynamicznego za każdym razem, gdy zażądamy nowego rekordu, polecenie określające zawartość zwracanych wyników jest ponownie wykonywane. Oznacza to, że wszelkie modyfikacje wprowadzane w tabeli bazy danych będą widoczne, a co więcej, dodanie nowego rekordu może mieć wpływ na zawartość wynikowego zbioru rekordów.

Dostęp w Jawie przez JDBC - sterownik
Java, jako nowoczesny język programowania, posiada m.in. możliwości związane z podłączeniem się i operowaniem na bazach danych. Jednak założeniem projektantów Javy było stworzenie języka, którego kod byłby przenośny między różnymi systemami operacyjnymi. Taką przenośność posiada Java w dziedzinie zastosowań aplikacji bazodanowych. Java także wykorzysta technologię ODBC. Została ona realizowana jako interfejs niezależny od architektury bazy danych i ma nazwę JDBC (ang. Java DataBase Connectivity). JDBC jest pomostem pomiędzy przestrzeniami bazy danych, mającą sterownik ODBC, i aplikacji, napisanej w języku Java. Interfejs ten operuje na poziomie SQL. Dzięki JDBC aplikacje bazodanowe napisane w Javie są niezależne od sprzętu oraz stosowanej bazy danych. Niezależność od systemu operacyjnego zapewnia sama Java.

JDBC - sterownik Sterownikiem JDBC, łączącym aplikację z konkretną bazą danych, nazywa się zestaw klas, które implementują interfejs ODBC. Zadaniem JDBC jest ukrycie przez programista wszelkich specyficznych własności bazy danych. Dzięki temu programista może skupić się wyłączne na swojej aplikacji, nie wdając się w szczegóły związane z obsługą używanej przez niego bazy danych. Aby umożliwić niezależność od platformy, JDBC udostępnia menedżera sterowników ODBC, który dynamiczne zarządza różnymi obiektami sterowników. Obiekty te będą wykorzystywać zapytania do bazy danych.

JDBC - sterownik –kolejność czynności
Kolejność dostępu do bazy danych zawiera następne czyności: 1) Załadować do pamięci potrzebny sterownik JDBC. To można zdarzyć następnym sposobem: Class.forName ("sun. jdbc.odbc.JdbcOdbcDriver") Argumentem metody forName() jest obiekt typu STRING. Jest on nazwą klasy sterownika wraz z nazwą pakietu, który trzeba załadować. Po załadowaniu sterownik staje się dostępnym dla aplikacji. 2) Dla połączenia z bazą danych wykorzystają konstrukcję : DriverManager.getConnection(url,user,password) Pierwszy parametr w metodzie getConnection() to URL do bazy danych. Pozwala on na identyfikację bazy danych w taki sposób, że możliwe jest załadowanie do pamięci odpowiedniego sterownika ODBC i uzyskanie połączenia z bazą. Drugi i trzeci parametry oznaczają odpowiednio nazwę użytkownika bazy danych i hasło dostępu do niej. Jeżeli baza danych nie potrzebuje identyfikatora oraz hasła, drugi oraz trzeci parametry są nieobecne. Standartowa składnia URL–a jest następująca: jdbc:<subprotokół>:<subnazwa>. JDBC – to typ protokółu, subprotokół określa nazwę wykorzystanego sterownika (w tym wypadku – ODBC), subnazwa jest nazwą identyfikującą bazę danych, nazwa profilu ODBC. Przykład połączenia z bazą danych: Connection con; String url = "jdbc:odbc:biblio"; … con = DriverManager.getConnection(url);

JDBC - sterownik –kolejność czynności cd…
3) Wykonać zapytanie SQL do bazy danych. Dla wykonania zapytania SQL do bazy danych, mamy do wyboru jeden z interfejsów: Statement, PreparedStatement lub CallableStatement. Wszystkie trzy służą zasadniczo jednemu: wykonaniu zapytania SQL-owego. Tworzenie obiektów z grupy Statement ma następującą postać: Statement stmt; gdzie stmt = con.createStatement(); Obiektu Statement używamy do wykonania zapytań SQL. Rezultaty zapytania są przechowywane w obiektu ResultSet: String query; // wiersz operatora SQL query = "SELECT …FROM…WHERE…”; ResultSet rs; // pole dla rezultatu zapytania SQL rs = stmt.executeQuery(query);

4) Wywolać dane ze zbioru skutecznego. Obiekt ResultSet reprezentuje wynik zapytania SQL i zawiera zbiór rekordów z danymi. Stosując metodę next() tego obiektu, możemy mieć dostęp do wszystkich danych: more = rs.next(); Zatem stosując metodę getXXX(nazwa_pola) trzeba zdarzyć dostęp do danych bieżącego rekordu. Na przykład: While (rs.next()) { Int x = rs.getInt (‘pole1’); String s =rs.getString (‘pole2’); Float f = rs.getFloat (‘pole3’); }

JDBC - przykłady użycia
Podczas działania aplikacji bazodanowej mogą wystąpić różnego rodzaju sytuacje powodujące, że określone operacje na bazie zakończą się niepowodzeniem. Dlatego ważne jest, aby aplikacja potrafiła obsłużyć tego typu zdarzenia. Pomocny okazuje się mechanizm obsługi wyjątków. W takich przypadkach wykorzystujemy klasę SQLException. Przykład stworzenia tablicy w aplikacji JAVA // package jdbc; import java.sql.*; // Stworzenie tablicy w bazie danych biblio. // Najpierw trzeba stworzyć ODBC profile // bazy danych biblio. // Do tej bazy aplikacja umieszczona poniżej dodaje nową tabelę SKLEP public class JdbcCreateTable { public static void main(String args[]) { String url = "jdbc:odbc:biblio"; Connection con; String createString; createString = "create table SKLEP " + "(SKL_NAME varchar(32), " +"SkL_ID int, " + "SKL_ADDR varchar(32), " +"SKL_INV varchar(32))";

JDBC - przykłady użycia cd..
Statement stmt; try { // Uruchomienie ODBC – sterownika (brydża Java – ODBC) Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); } catch(java.lang.ClassNotFoundException e) { System.err.print("ClassNotFoundException: "); System.err.println(e.getMessage()); } // Realizujemy połączenie z bazą biblio con = DriverManager.getConnection(url); //tworzymy obiekt Statement dla przeniesienia SQL instrukcji stmt = con.createStatement(); // uruchomienie instrukcji stmt.executeUpdate(createString); // usunięcie objektów stmt.close(); con.close(); } catch(SQLException ex) { System.err.println("SQLException: " + ex.getMessage());

// Przykład konstruowania zapytań do bazy danych w aplikacji Java import java.sql.*; // Wykorzystanie pakietu Jdbc w bazie danych biblio // Najpierw trzeba stworzyć ODBC profile //bazy danych biblio public class JdbcExample { // Deklaruje się obiekt połączenia z bazą danych static Connection dbcon; /* Podprogram główny*/ public static void main(String args[]) throws Exception { // Uruchomienie ODBC – sterownika (brydża Java – ODBC) Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); // otworzenie bazy danych open (); // Odwzorowanie wszystkich wierszy w bazie select ("And Authors.Au_ID < 20 )"); // Uaktualnienie rekordów oraz formowanie rezultatu update (); // zamknięcie bazy danych close(); }

// Odwzorowanie wszystkich wierszy w bazie select ("And Authors.Au_ID < 20 )"); // Uaktualnienie rekordów oraz formowanie rezultatu update (); // zamknięcie bazy danych close(); } /* otworzyć połączenie z bazą danych */ static void open() throws SQLException { /* Zadać imię źródła ODBC, nazwiska użytkownika i hasła String dsn = "jdbc:odbc:biblio"; String user = ""; String password = ""; /* Uruchomienie menedżera sterownika dla połączenia dbcon = DriverManager.getConnection(dsn,user,password); /* Domyślnie fiksacja transakcji jest dokonywana automatycznie, dla tego funkcja AutoCommit() jest odłączona */ dbcon.setAutoCommit(false); /* określenie wszystkich czekających na zakończenie transakcji oraz zamknięcie bazy danych */ static void close() throws SQLException { dbcon.commit(); dbcon.close(); }

// Odwzorowanie wszystkich wierszy w bazie /* określenie wszystkich czekających na zakończenie transakcji oraz zamknięcie bazy danych */ static void close() throws SQLException { dbcon.commit(); dbcon.close(); } /* Otrzymanie zapytań SQL z klauzulą WHERE*/ static void select(String whereClause) throws SQLException { Statement stmt; //Obiekt operatora SQL String query; // wiersz operatora SQL ResultSet rs; // pole dla rezultatu zapytania SQL String pr; boolean more; // przełącznik "wiersze dodatkowe są obecne” /* Przygotowanie zapytania SQL , konstruowanie operatora SQL, wypełnienie zapytania SQL */ //query = "SELECT Authors.Author FROM Authors WHERE (Au_ID < 20 // );"; query = "SELECT Authors.Author, Titles.Title, Publishers.`Company Name` "; query = query + "FROM Authors, `Title Author`, Titles, Publishers "; query = query + "WHERE (Authors.Au_ID = `Title Author`.Au_ID AND "; query = query + "`Title Author`.ISBN = Titles.ISBN AND "; query = query + "Titles.PubID = Publishers.PubID " + whereClause; stmt = dbcon.createStatement(); rs = stmt.executeQuery(query);

/* sprawdzenie obecności wierszy, które będą zwrócone */ more = rs.next(); if (!more) { System.out.println("No rows found"); return; } /* Cykl dla obróbki wierzy, które są wybrane */ while (more) { pr = rs.getString("Author"); System.out.println("Autor: " + pr); pr = rs.getString("Title"); System.out.println("Title: " + pr); pr = rs.getString("Company Name"); System.out.println("Publishers: " + pr); System.out.println(""); more = rs.next(); } rs.close(); stmt.close(); } /* Otrzymanie zapytań SQL bez klauzuli WHERE*/ static void select() throws SQLException { select(""); } }

Rozproszone bazy danych a technologie dostępu

Przykładowa architektura klient – serwer w PostgreSQL
POSTMASTER BAZA DANYCH UNIX Połączenie KLIENT Połączenie POSTMASTER Linux KLIENT ODBC Dostęp POSTMASTER Windows Wielu klientów Wiele operacji dostępu jednocześnie

Konieczność dostępu do bd z www
Protokół HTTP (Hypertext Transfer Protocol) Dostęp do informacji w postaci stron WWW Informacja prezentowana w sposób nieliniowy (hipertekst) Prezentacja różnych typów informacji (tekst, grafika, wykres, wideo) Znajomość adresu serwera lub strony jako warunek konieczny pozyskania informacji Przeglądarka - sposób dostępu do informacji

Identyfikacja źródeł danych
URL (Uniform Resource Locator) - uniwersalny sposób lokalizacji zasobów Struktura URL: usługa://adres_serwera ( usługa://adres_serwera/katalog (ftp://ftp.wspa.lublin.pl) usługa://adres _serwera/katalog/dokument ( Wykorzystanie: odnośniki do innych stron WWW (linki) odnośniki do innych usług sieciowych

Identyfikacja źródeł danych a bd w internecie
Dostęp bezpośredni do źródła: znajomość adresu serwera WWW nawigacja między stronami WWW w obrębie danego serwera Dostęp pośredni: polskie portale (Onet, Wirtualna Polska, Interia, ...) wyszukiwarki sieciowe (Altavista, Yahoo, Infoseek, Lycos, ...) Zalety dostępu staytycznego: prosty sposób wyszukiwania duży wybór różnych informacji Wady: długi czas poszukiwania informacji dostęp tylko do wybranych źródeł informacji

Metody dynamicznego dostępu do baz danych z poziomu WWW
Technologie dynamicznego generowania witryn: CGI (ang. Common Gateway Interface) SSI (ang. Server Side Includes) ISAPI (ang. Internet Server API) PHP (ang. PHP Hypertext Preprocessor) ASP klasyczne (ang. Classic ASP) CFML (ang. ColdFusion Markup Language) Roxen CMS (ang. Roxen Content Management Solution) Serwlety (ang. servlets) oraz JSP (ang. Java Server Pages) ASP.NET (ang. Active Server Pages .NET)

Statyczny witryny internetowe w dostępie do źródeł danych
Klient Serwer Strona HTML Zapytanie o stronę HTML Odpowiedź – strona HTML Serwer przetwarza żądanie 1 2 3 4 Wykorzystanie dojrzałych protokołów TCP/IP Opracowanie podstawowych protokołów i standardów stron WWW (HTTP, URL, HTML/XHTML…) Brak większej interakcji pomiędzy serwerem WWW, a klientem Statyczna zawartość witryn

Różne metody generacji
Niskopoziomowe API serwera aplikacji (np. CGI, ISAPI). Ogólna zasada polega na wywoływaniu zewnętrznych programów, które zwracają następnie wyniki swojego działania do serwera aplikacji WWW w postaci kodu HTML Interpretowane skrypty (np. PHP, ASP klasyczne). Bezpośrednio w kodzie strony, zanurzany jest skrypt, który po wykonaniu się na serwerze, wyświetlany jest na maszynie klienta Kompilowane programy (JSP – serwlety i ASP.NET). Strony blisko kooperują z kompilowanym kodem (np. kod zakulisowy w ASP.NET oraz komponenty logiki biznesowej). Strony również podlegają kompilacji. Raz skompilowany element aplikacji rezyduje na serwerze, generując zawartość stron przy każdym żądaniu.

ASP klasyczne – schemat działania
Serwer 2 Skrypt ASP Klient Zapytanie o stronę ASP 1 3 ASP.DLL Odpowiedź – strona HTML 5 Strona HTML 4

Programowe interfejsy baz danych
Potrzeba programowego interfejsu baz danych Wielość różnych rozwiązań. Przykłady: ODBC (ang. Open Database Connectivity) DAO (ang. Data Access Objects) RDO (ang. Remote Data Objects) OLE DB (ang. Object Linking and Embedding Database) ADO (ang. ActiveX Data Objects) ADO.NET (ang. ActiveX Data Objects .NET) JDBC (ang. Java Database Connectivity)

Technologia ADO.NET Integralny element platformy .NET
Może być wykorzystana jako rodzaj wysokopoziomej nakładki ODBC lub OLE DB Bezpołączeniowa architektura Przejrzysta struktura obiektowa Ścisła współpraca ze standardem XML Efektywne wywoływanie procedur składowanych Obsługa ODBC, OLE DB oraz bezpośrednich interfejsów bazodanowych, wybranych systemów (SQL Server, Oracle) ADO.NET jest wykorzystywane przez ASP.NET

ADO.NET – warstwy dostępu do danych
Kod aplikacji Dostawca .NET dla SQL Server Obiekt DataAdapter lub Command Obiekt Connection OLE DB Dostawca .NET dla OLE DB SQL Server Baza danych ODBC Dostawca .NET dla ODBC Baza danych Dostawca .NET dla Oracle Oracle

.NET Framework Data Provider
Architektura ADO.NET .NET Framework Data Provider Connection DataReader Command Transaction Parameters DataAdapter SelectCommand InsertCommand UpdateCommand DeleteCommand DataSet DataTableCollection DataTable DataRowCollection DataColumnCollection ConstraintCollection DataRelationCollection Baza danych XML

Architektura aplikacji baz danych

Wnioski Nierozłączna współpraca technologii dynamicznego
generowania witryn z interfejsami baz danych Najpopularniejsze, niekomercyjne rozwiązanie: PHP + MySQL lub PostgreSQL + Apache + Linux Technologie stosowane tam gdzie najważniejszym priorytetem jest bezpieczeństwo, wydajność i przejrzystość rozwijanego projektu: JSP oraz ASP.NET Inne popularne rozwiązania: ASP klasyczne, CFML

Platforma.NET Najważniejsze założenia:
Zintegrowanie technologii programistycznych w postaci jednej platformy Współpraca wielu języków programowania Współpraca wielu różnych architektur, zarówno sprzętowych jak i systemowych (na razie ograniczona) Próba ustanowienia standardu przemysłowego (najważniejsze elementy są standardami ECMA)

Platforma.NET – najważniejsze pojęcia
CLR (ang. Common Language Runtime) BCL (ang. Base Class Library) MSIL (ang. Microsoft Intermediate Language) CLS (ang. Common Language Specification) CTS (ang. Common Type System) Podzespół (ang. assembly) Kompilator JIT (ang. Just-In-Time compiler)

Model wykonawczy platformy .NET
Kod źródłowy Kompilator Kod pośredni IL + metadane Kompilator kodu pośredniego CLR Kod natywny System operacyjny Kompilacja Wykonanie Komponent niezarządzany

Architektura platformy .NET
VB C++ Python J# itd. Wspólna specyfikacja języków (CLS) Visual Studio .NET (lub inne IDE) Język pośredni (MSIL) Web services Strony ASP.NET Aplikacje ASP.NET Formularze Windows ADO.NET i XML Biblioteka podstawowa (BCL) Środowisko uruchomieniowe (CLR) System operacyjny Windows Architektura platformy .NET

Środowisko uruchomieniowe
CLR jest agentem odpowiedzialnym za: Zarządzanie kodem podczas jego wykonywania Zarządzanie pamięcią (mechanizm GC) Zarządzanie wątkami Wymuszenie zgodności typów pomiędzy różnymi językami programowania Kompilacja Niedopuszczenie do użycia potencjalnie niebezpiecznego kodu (np. wskaźników zmiennych)

Podzespół Podstawowa jednostka wdrożeniowa .NET
Zawiera kod pośredni MSIL, niezależny od procesora (może być zależny od OS) Jest to komponent samoopisujący się (metadane) Nie wymaga rejestracji w systemie (instalacja xcopy) Może być dzielony (podobnie jak standardowe DLL) przez wiele aplikacji

Wspólny System Typów (CTS)
Umożliwia integrację wielu języków programowania Dwa podstawowe rodzaje typów: Typy wartości Typy referencyjne Opakowywanie zmiennej (ang. boxing) Brak wskaźników (zmiennych i funkcji) Delegaty

Klasyfikacja typów .NET

Współpraca wielu języków – CLI
Wspólna Infrastruktura Językowa CLI (ang. Common Language Infrastructure) – składa się z CLR i CLS. Jest publicznie dostępna; każdy może opracować kompilator JIT dla dowolnego języka tak by był zgodny z platformą .NET Faworyzacja języków podobnych do C# Języki programowania .NET w efekcie różnią się pomiędzy sobą tylko notacją (dialekty języków oryginalnych). Przykład: język Smalltalk, z dynamicznym typowniem Standard ECMA (wraz z językiem C#) Dostępnych ponad dwadzieścia języków programowania na platformie .NET (np. C++, C#, J#, Visual Basic, Smalltalk, Python, Perl, Pascal, Eiffel, Fortran…)

.NET vs J2EE Trudno wskazać jednoznacznie lepszą platformę
J2EE bardziej dojrzała (zaprezentowana w 1999 roku) i szerzej akceptowana w przemyśle .NET posiada bardziej przejrzystą architekturę J2EE współpracuje z najważniejszymi systemami operacyjnymi, .NET głównie MS Windows .NET umożliwia współpracę wielu języków, J2EE ogranicza się praktycznie tylko do języka Java .NET oferuje lepszą produktywność

Technologia ASP.NET Ważny element architektury .NET
Kompilowany kod – wydajność Separacja kodu prezentacji od kodu obsługi strony (kod zakulisowy); komponenty biznesowe Rozbudowane mechanizmy buforowania stron i danych Wielość stosowanych języków programowania Obsługa elektronicznych urządzeń przenośnych (telefony komórkowe, PDA) Wysoka produktywność Duży poziom bezpieczeństwa Naturalna współpraca z bazami danych i XML

Formularze ASP.NET (ang. Web forms)
Podstawowy element budulcowy aplikacji ASP.NET Separacja kodu interfejsu od jego obsługi Obiektowy model projektowania Możliwość wykorzystania kodu client-side do walidacji danych użytkownika

Kod zakulisowy – web forms
Witaj Imię: Hasło: OK Class MojFormularz MojFormularz.aspx MojFormularz.aspx.cs MojFormularz Te dwa pliki tworzą razem formularz internetowy

Struktura ASP.NET web forms
System.Web.UI.Page WebForm1.cs Klasa WebForm1 Projekt.dll WebForm1.aspx temporary.dll Strona HTML Projektowanie Wykonanie Dziedziczenie Kompilacja Wynik do przeglądarki lub urządzenia

Cykl życia formularza ASP.NET
Dodaj Mąka Cukier Sól Koszyk (Koszyk.aspx) Przeglądarka internetowa (Koszyk.aspx.cs) Serwer ObsluzStrone(); PobierzWybProdukt(); DodajDoKoszyka(); StworzNowaStrone(); Odswiez(); Przycisk „Dodaj” wysyła żądanie na serwer… …w wyniku którego do przeglądarki wracana jest nowa strona Serwer wykonuje żądanie…

Zarządzanie stanem Potrzeba zarządzania stanem; HTTP jako tzw. stateless protocol Dwie generalne metody zarządzania stanem: Po stronie klienta (np. cookies, query strings) Po stronie serwera (np. wsparcie serwera aplikacji oraz baz danych) Każde podejście ma swoje wady i zalety; strategię należy dobierać ściśle do konkretnych wymagań Aspekt bezpieczeństwa

Zarządzanie stanem (c.d.)
Przykłady metod zarządzania stanem: Widok stanu Ukryte pola formularzy HTML Ciasteczka (ang. cookies) Ciągi zapytań (ang. query strings) Stan aplikacji Utrzymanie stanu z użyciem baz danych

Kontrolki serwerowe Analogiczne do kontrolek aplikacji desk-top
Sześć grup kontrolek serwerowych ASP.NET: Serwerowe kontrolki HTML Serwerowe kontrolki internetowe Kontrolki walidacyjne Kontrolki użytkownika Dostosowane kontrolki internetowe Mobilne kontrolki ASP.NET

Dostęp do danych w ASP.NET
Wykorzystanie technologii ADO.NET jako interfejsu bazodanowego programisty Bezpołączeniowy model klient-serwer; potrzeba cyklu podróży w obie strony (ang. round trip) Częstsze odczytywanie danych aniżeli ich zapis Minimalizowanie konsumpcji zasobów serwera Dostęp do danych z użyciem rozproszonego przetwarzania Zapewnienie odpowiedniego poziomu bezpieczeństwa danych Znaczenie procedur składowanych po stronie serwera bazy danych w aplikacjach internetowych

Mechanizmy buforowania
Znaczenie buforowania Dwa zasadnicze podjeścia: Buforowanie wyjścia (ang. output caching) Buforowanie danych aplikacji (ang. application data caching) Buforowanie fragmentów strony

Konfiguracja środowiska ASP.NET
Pliki konfiguracyjne w standardzie XML Możliwość współistnienia wielu plików konfiguracyjnych Web.config w ramach jednej aplikacji Znaczenie pliku Machine.config Dziedziczenie ustawień w hierarchii katalogów wirtualnych serwera aplikacji internetowej Możliwość zmiany konfiguracji w działającej aplikacji, bez potrzeby restartu serwera Rozszerzalność plików konfiguracyjnych jako plików XML Ochrona przed niepowołanym dostępem do plików konfiguracyjnych z zewnątrz

Bezpieczeństwo aplikacji ASP.NET
Aspekt bezpieczeństwa w aplikacjach internetowych Dwa fundamentalne procesy: Uwierzytelnianie (ang. authentication) – sprawdzenie tożsamości danego użytkownika w systemie Autoryzacja (ang. authorization) – określenie do jakich danych może mieć dostęp uwierzytelniony użytkownik Uwierzytelnianie może następować poprzez: System Windows Formularze ASP.NET Usługę Passport

Bezpieczeństwo aplikacji ASP.NET (c.d)
Architektura ASP.NET Klient Aplikacja ASP.NET .NET Framework IIS System operacyjny

Optymalizacja ASP.NET Cztery podstawowe czynniki wydajnościowe:
Czas wykonania (ang. execution time) Czas odpowiedzi (ang. response time) Skalowalność (ang. scalability) Przepustowość (ang. throughput)

Przyszłość technologii ASP.NET
Przykłady wykorzystania we współczesnym biznesie (np. DELL, London Stock Exchange, NASDAQ, Microsoft) Następca obecnej wersji ASP.NET v1.1 – ASP.NET v2.0 „Whidbey”. Nie zapowiedziano jeszcze terminu prezentacji finalnej wersji. Główny punkty rozwoju: Produktywność Administracja i zarządzanie Wydajność

Architektura systemu (c.d.)
Warstwy programu użytkowego Warstwa prezentacji Warstwa przetwarzania Warstwa zarządzania danymi

Architektura systemu (c.d.)
Model klienta cienkiego i klienta grubego Cienki klient Gruby klient Warstwa przetwarzania (logika biznesowa) + Warstwa zarządzania danymi Warstwa prezentacji (interfejs użytkownika)

Przykładowa architektura systemu z ADO.NET
Formularze ASP.NET Komponenty logiki biznesowej korzystające z ADO.NET przy dostępie do bazy danych SQL Server 2000 warstwa prezentacji warstwa logiki warstwa danych

Podsumowanie

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 nie mają ogólnego rozwiązania. Pozostają nadzieje na rozwiązania cząstkowe.

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.

Rozproszone i federacyjne bazy danych

Podobne prezentacje

Prezentacja na temat: "Rozproszone i federacyjne bazy danych"— Zapis prezentacji:

Podobne prezentacje

О projekcie

Zwrotny adres

Wejść

Zaloguj się poprzez sieć społeczną:

Rozproszone i federacyjne bazy danych

Podobne prezentacje

Prezentacja na temat: "Rozproszone i federacyjne bazy danych"— Zapis prezentacji:

Podobne prezentacje

О projekcie

Zwrotny adres