Rozproszone i federacyjne bazy danych

Rozproszone i federacyjne bazy danych
Wykładowca: Kazimierz Subieta
Polsko-Japońska Wyższa Szkoła
Technik Komputerowych, Warszawa
[email protected]
Instytut Podstaw Informatyki PAN,
Warszawa
[email protected]
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 1
marzec 2002
Plan wykładu
 Wprowadzenie do systemów rozproszonych
 Pojęcia związane z rozproszeniem
 Obiektowość w systemach rozproszonych
 Projektowanie rozproszonych baz danych
 Architektury rozproszonych baz danych
 Replikacje
 Przetwarzanie transakcji
 Niezgodności schematów i ontologii
 Federacyjne bazy danych
 Osłony i mediatory
 Perspektywy
 Przetwarzanie zapytań
 Podsumowanie
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 2
marzec 2002
Wykład 1
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 3
marzec 2002
Wprowadzenie do systemów
rozproszonych
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 4
marzec 2002
Co to jest system rozproszony?
 Systemem rozproszonym nazywamy taki system, w którym przetwarzanie
informacji odbywa się na wielu komputerach, często znacznie oddalonych
geograficznie (od kilku metrów do dziesiątków tysięcy kilometrów).
Przeciwieństwem jest system izolowany lub scentralizowany.
 Obecnie właściwie wszystkie systemy (poza domowymi komputerami) są
rozproszone. Ogromnym katalizatorem rozproszenia systemów jest Internet.
Komputer z Internetem można już uważać za system rozproszony.
 Projektowanie i własności systemów rozproszonych w dużej mierze są takie same
jak systemów scentralizowanych, ale istnieją także istotne różnice, który
specjalista inżynierii oprogramowania musi być świadomy.
 Tendencja do budowy systemów rozproszonych jest pochodną rozbudowy tanich,
szybkich, uniwersalnych i niezawodnych sieci komputerowych.
 Przykłady systemów rozproszonych: sieć bankomatów, system rezerwacji
biletów, system pracy grupowej, itd.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 5
marzec 2002
Zalety systemów rozproszonych (1)
 Podział zasobów: system rozproszony pozwala dzielić zasoby sprzętowe i
programowe (pamięci dyskowe, drukarki, pliki, kompilatory, itd.) pomiędzy wielu
użytkowników pracujących na różnych komputerach pracujących w sieci.
 Otwartość: jest ona definiowana jako zdolność systemu do dołączania nowego
sprzętu, oprogramowania i usług. Otwarte systemy często mają tę zdolność
również w stosunku do w/w zasobów ulokowanych na platformach sprzętowych i
systemach operacyjnych dostarczanych przez różnych dostawców.
 Współbieżność: w systemie rozproszonym wiele procesów może działać w tym
samym czasie na różnych komputerach w sieci. Procesy te mogą (jakkolwiek nie
muszą) komunikować się podczas swego działania.
 Skalowalność: Moc i możliwości przetwarzania może wzrastać w miarę
dodawania do systemu nowych zasobów, w szczególności komputerów. W
praktyce skalowalność jest często ograniczona poprzez przepustowość sieci oraz
(niekiedy) poprzez np. specyficzne protokoły wymiany informacji. Niemniej
skalowalność systemu rozproszonego jest nieporównywalnie lepsza w stosunku
do systemu scentralizowanego.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 6
marzec 2002
Zalety systemów rozproszonych (2)
 Tolerancja błędów: Dostępność wielu komputerów oraz umożliwienie
zdublowania informacji (replikacje) oznacza, że rozproszony system jest
tolerancyjny w stosunku do pewnych błędów zarówno sprzętowych jak i
programowych. Np. awaria węzła komunikacyjnego powoduje wygenerowanie
innej trasy przepływu informacji.
 Przezroczystość: Oznacza ukrycie przed użytkownikiem szczegółów
rozproszenia, np. gdzie ulokowane są zasoby lub jak są one fizycznie
zaimplementowane, pod jakim systemem pracują, itd. Przezroczystość ma
zasadnicze znaczenie dla komfortu działania użytkownika oraz dla niezawodności
budowanego oprogramowania. Niekiedy, np. dla celów optymalizacyjnych,
użytkownik może zrezygnować z pełnej przezroczystości. Przykładem
przezroczystości jest Internet: klikając w aktywne pole na stronie WWW nie
interesujemy się, gdzie znajduje się odpowiadająca mu strona, oraz jak i na czym
jest zaimplementowana.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 7
marzec 2002
Wady systemów rozproszonych
 Złożoność: systemy rozproszone są trudniejsze do zaprogramowania i do
administrowania niż systemy scentralizowane. Zależą od własności sieci, np. jej
przepustowości i czasu transmisji, co utrudnia zaprojektowanie i zrealizowanie
wielu algorytmów i procesów przetwarzania.
 Ochrona: Dla systemu scentralizowanego wystarcza w zasadzie strażnik z
karabinem. System rozproszony nie może być chroniony w ten sposób, przez co
może być narażony na różnorodne ataki (włamania, wirusy, sabotaż, odmowa
płatności, itd.) z wielu stron, które trudno zidentyfikować.
 Zdolność do zarządzania: jest ona utrudniona wskutek tego, że konsekwencje
różnych działań administracyjnych w systemie rozproszonym są trudniejsze do
zidentyfikowania. Podobnie z przyczynami sytuacji anormalnych, w
szczególności awarii.
 Nieprzewidywalność: system rozproszony jest nieprzewidywalny w swoim
działaniu, ponieważ zakłócenia mogą być powodowane przez wiele przyczyn:
małą przepustowość i awarię łączy, awarię komputerów, zbyt duże obciążenie
danego serwera, lokalne decyzje administracji serwera, itd.; patrz WWW.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 8
marzec 2002
Krytyczne zagadnienia projektowe dla systemów
rozproszonych
 Identyfikacja zasobów: zasoby w systemie rozproszonym są podzielone
pomiędzy wiele komputerów, w związku z czym schematy ich nazywania muszą
być zaprojektowane tak, aby użytkownicy mogli zidentyfikować interesujące ich
zasoby. Przykładem takiego schematu jest URL (Uniform Resource Locator)
znany z WWW.
 Komunikacja: może być zaprojektowana w sposób uniwersalny, na bazie np.
protokołu internetowego TCP/IP lub któregoś protokołu pochodnego (ftp, http,
itd.). Niektóre wymagania dotyczące szybkości, kosztu, niezawodności lub
bezpieczeństwa mogą prowadzić do specjalnych technik komunikacyjnych.
 Jakość obsługi: odzwierciedla wydajność systemu, jego dostępność i
niezawodność. Podlega ona wielu czynnikom, w szczególności, przypisaniu
zadań do procesorów, optymalności geograficznego podziału danych, itd.
 Architektura oprogramowania: opisuje ona w jaki sposób funkcjonalności
systemu są przypisane do logicznych i fizycznych komponentów systemu. Wybór
dobrej architektury przesądza o spełnieniu kryterium jakości obsługi.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 9
marzec 2002
Popularne architektury rozproszenia
 Klient-serwer: rozproszony system ma wyróżniony węzeł zwany serwerem, oraz
szereg podłączonych do niego węzłów zwanych klientami. Związek nie jest
symetryczny: serwer wykonuje usługi zlecane przez klientów, nie może im
odmówić i nie może im zlecić wykonanie usług.
 Klient-multi-serwer: podobnie jak dla architektury klient-serwer, ale istnieje
wiele serwerów. Przykładem jest WWW.
 Koleżeńska (peer-to-peer, 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, ...
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 10
marzec 2002
Co to jest rozproszona baza danych?
distributed database
Termin ten jest powtarzany w wielu kontekstach, często bez przypisywania mu
konkretnego, technicznego znaczenia.
Czy to, że z pewnego systemu można dostać się do danych innego odległego
systemu jest wystarczającym wyróżnikiem rozproszonej bazy danych?
 Dla wielu zastosowań cecha ta jest istotna, lecz
 Rozproszona baza danych musi spełniać określone kryteria
dotyczące spójności, bezpieczeństwa, zintegrowania i wygody
użytkowników.
 Możliwość dostania się do danych innego systemu (np. poprzez
pakiety oparte o standardy ODBC, JDBC, DCOM lub CORBA)
oznacza wyłącznie ustanowienie niezbędnej bazy technicznej. Fakt
ten nie przesądza jednak o tym, czy zachodzą dostateczne warunki
dla sprawnego, efektywnego oraz niezawodnego wykorzystywania
danych.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 11
marzec 2002
Podstawowe pojęcia związane z
rozproszeniem
 Rozproszona baza danych: zbiór składający się z wielu logicznie
ze sobą powiązanych elementów bazy danych, oddalonych
geograficznie i połączonych ze sobą poprzez sieć komputerową.
 System zarządzania rozproszoną bazą danych (SZRBD):
oprogramowanie umożliwiające połączenie rozproszonych
zasobów w jedną całość, utrzymanie spójność zasobów oraz
udostępnianie ich użytkownikom przy założeniu przezroczystości
rozproszenia.
 Dane są przechowywane w wielu miejscach - węzłach sieci.
 Rozproszona baza danych jest bazą danych, a nie kolekcją plików,
które mogą być indywidualnie przechowywane w każdym węźle
sieci komputerowej.
 SZRBD posiada pełną funkcjonalność systemu zarządzania
scentralizowaną BD. Nie jest to system zarządzania rozproszonymi
plikami, ani też wyłącznie system przetwarzania transakcji.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 12
marzec 2002
Przykład rozproszonej bazy danych
Rozproszona baza danych dla linii lotniczych (biuro obsługi klienta w
Warszawie może dostać się do danych linii lotniczych w Sydney, Tokio,
Paryżu, i setkach innych miast).
Jeżeli w każdym miejscu organizacja bazy danych, środki manipulacji,
reguły dostępu, itd. byłyby inne, to praca byłaby bardzo utrudniona.
Zatem konieczne są:
 standardy w zakresie połączenia (protokoły),
 standardy w zakresie organizacji danych i dostępu do
danych,
 moduły dla odwzorowania pewnej specyficznej bazy danych
na format oczekiwany przez danego klienta,
 przezroczystość rozproszenia (a la CORBA),
 zabezpieczenia przed niepowołanym dostępem.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 13
marzec 2002
Klasyfikacja rozproszonych baz danych
Systemy wielu baz danych
(multidatabases)
Niefederacyjne rozproszone BD
Jednorodne
BD
Rozproszone BD z
globalnym schematem
Federacyjne BD
Słabo skojarzone
(loosely coupled)
Niefederacyjne BD: brak autonomii.
Słabo skojarzone FBD: brak federacyjnego schematu i
zarządzania, operacje ad hoc, w zależności od aplikacji.
Ściśle skojarzone
(tightly coupled)
Pojedyncze
federacje
(pojedynczy
schemat)
Wielokrotne
federacje
(wiele
schematów)
Ściśle skojarzone FBD: FSZBD jest odpowiedzialny za
zarządzanie całością federacji.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 14
marzec 2002
Tematy związane z rozproszonymi BD (1)
 Architektury rozproszonego przetwarzania: bazy danych oparte o
architekturę klient-serwer, bazy danych oparte o schemat globalny.
 Federacyjne bazy danych - (przezroczyste) połączenie wielu
(relewantnych części) heterogenicznych i autonomicznych baz danych w
jedną całość.
 Przetwarzanie transakcji w rozproszonych bazach danych; globalne
transakcje, lokalne transakcje, dwufazowe i trójfazowe potwierdzenie
(two-phase commit, 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).
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 15
marzec 2002
Tematy związane z rozproszonymi BD (2)
 Replikacje, czyli utrzymywanie kopii danych w wielu miejscach w
rozproszonych bazach danych.
 Rozproszone przetwarzanie zapytań; optymalizacja zapytań w sytuacji
rozproszenia zasobów.
 Systemy operacyjne dla podtrzymywania rozproszenia: OSF DCE i inne
systemy oparte o wołanie odległej procedury (Remote Procedure Call,
RPC).
 Podtrzymywanie różnych form niewidoczności rozproszenia (distribution
transparency) dla programistów i klientów baz danych.
 Standardy w zakresie rozproszenia: OMG CORBA, DCOM firmy
Microsoft, RMI i Java Beans, OpenDoc, ActiveX, SOAP/XML.
Pośrednicy (broker, ORB) wg standardu CORBA, np. Orbix, Visibroker, ...
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 16
marzec 2002
Tematy związane z rozproszonymi BD (3)
 Środki wspomagające rozproszenie bazy danych i rozproszone
przetwarzanie zrealizowane w konkretnych systemach relacyjnych
(Oracle, Sybase, Ingres, i inne), post-relacyjnych lub obiektoworelacyjnych (Informix Universal Server, 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.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 17
marzec 2002
Rozproszone BD: relacyjne czy obiektowe?
 Prace prowadzone nad rozproszonymi BD (w ciągu ostatnich 20-tu
lat), były oparte głównie o relacyjny model danych.
 Zaletami modelu relacyjnego jest prosta, ujednolicona struktura
danych oraz prosta organizacja katalogów bazy danych.
 W ostatnich latach obserwuje się odchodzenie od modelu
relacyjnego w stronę modeli obiektowych.
 Złożoność samego problemu rozproszenia danych jest
prawdopodobnie niezależna od modelu danych.
 Niektóre metody systemów relacyjnych związane z rozproszeniem
dają się przenieść na grunt systemów obiektowych.
 Problemy nowe: metamodel (ontologia), przetwarzania zapytań.
 W przeciągu najbliższych 10-ciu lat obiektowość będzie
odgrywać główną rolę w rozwijaniu koncepcji rozproszonych
baz danych, w różnych wariantach, np. XML/RDF.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 18
marzec 2002
Reguły rozproszenia
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 19
marzec 2002
Reguły rozproszonych baz danych (1)
(C.J. Date, 1987)
12 reguł: w praktyce spełnienie wszystkich jest trudne lub
niemożliwe. Jest to spekulacyjny ideał.
 Autonomia lokalnych BD: lokalne dane powinny podlegać lokalnym
regułom własności i powinny być zarządzane lokalnie. Dotyczy to funkcji
związanych z bezpieczeństwem, integralnością i reprezentacją wewnątrz
pamięci. Wyjątki dotyczą sytuacji, kiedy więzy integralności muszą
obejmować jednocześnie wiele miejsc oraz sytuacji, kiedy rozproszone
transakcje muszą być sterowane przez pewne zewnętrzne miejsce.
 Brak podporządkowania przetwarzania do konkretnego miejsca:
uniknięcie wąskich gardeł dzięki decentralizacji wszystkich funkcji
rozproszonego SZBD.
 Ciągłość funkcjonowania: Przestoje w wykonywaniu operacji nie
powinny być skutkiem dodania nowych miejsc, ich usunięcia ze
środowiska rozproszonej BD, dokonania zmian w meta-informacji lub
unowocześnienia wersji SZBD w pewnym indywidualnym miejscu.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 20
marzec 2002
Reguły rozproszonych baz danych (2)
 Niezależność od lokalizacji: Użytkownicy lub programy aplikacyjne nie
muszą wiedzieć, gdzie dane są fizycznie przechowywane.
 Niezależność od fragmentacji: Fragmenty jednego zbioru danych mogą
być przechowywane i zarządzane przez rozproszony SZBD jako jedna
całość, bez uświadamiania użytkowników lub aplikacji o sposobie ich
rozczłonkowania. Pożądaną własnością rozproszonego SZBD jest to, aby
w sposób automatyczny unikał przetwarzania nierelewantnych
fragmentów.
• Np. jeżeli grupa obiektów jest podzielona geograficznie ze względu na
atrybuty w ten sposób, że atrybuty 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.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 21
marzec 2002
Reguły rozproszonych baz danych (3)
 Niezależność od replikacji: Istnienie replik danych w wielu miejscach,
ich pojawianie się lub usuwanie 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.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 22
marzec 2002
Reguły rozproszonych baz danych (4)
 Niezależność od systemu operacyjnego: oprogramowanie rozproszonego
SZBD powinno pracować pod różnymi systemami operacyjnymi.
 Niezależność od sieci: Miejsca mogą być połączone poprzez szeroką
gamę środowisk sieciowych i komunikacyjnych. Modele warstwowe
istniejące dla współczesnych protokółów komunikacyjnych (obowiązujące
w większości obecnych systemów informacyjnych, takich jak OSI 7,
TCP/IP, warstwy SNA i DECnet) zapewniają środki do osiągnięcia tego
celu nie tylko dla rozproszonych baz danych, lecz w ogólności dla
systemów informacyjnych.
 Niezależność od SZBD: Powinno być możliwe przyłączenie do
rozproszonej bazy danych lokalnej bazy danych zarządzanej przez
dowolny lokalny SZBD.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 23
marzec 2002
Reguła: niezależność od centralnego miejsca
 Rozproszona baza danych nie może zależeć od jednego, centralnego
miejsca odpowiedzialnego za całość funkcjonowania.
• Zależność taka może "wkraść się" niepostrzeżenie, jako konsekwencja
pewnych (wydawałoby się drugorzędnych) decyzji projektowych, np.
powołanie jednego serwera nazw, lub rejestracja nowych miejsc
przyłączających się do rozproszonej bazy danych.
 Zależność taka jest niekorzystna, gdyż:
• Centralne miejsce może stać się wąskim gardłem dla operacji na danych
• Awaria centralnego miejsca powoduje awarię całej rozproszonej bazy danych.
 Dla niektórych zastosowań brak centralnego miejsca jest niekorzystny:
• z powodu nadmiernego wzrostu obciążenia sieci związanego z wymianą
metadanych;
• z powodu zbyt niskiej wydajności (indeksy w jednym miejscu)
• z powodów biznesowych: centralne miejsce jest wygodne dla kontrolowania
pozostałych miejsc.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 24
marzec 2002
Nazwy elementów danych w rozproszonych BD
 Problem nazywania i identyfikacji danych w rozproszonych BD staje
się znacznie bardziej trudny niż w scentralizowanych BD.
 Kryteria zarządzania nazwami:
• 1. Każda dana, która ma być niezależnie identyfikowana w systemie
rozproszonym, musi mieć swoją unikalną nazwę (identyfikator).
• 2. Nazwa powinna zapewniać efektywne odszukanie lokalizacji danej.
• 3. Nazwa nie powinna utrudniać zmiany lokalizacji danej.
• 4. Każde lokalne miejsce w rozproszonej BD powinno powinno mieć
możliwość autonomicznego nadawania unikalnych nazw dla danych.
 Centralny serwer nazw - nadaje wszystkie nazwy, udziela informacji o
lokalizacji nielokalnych danych na podstawie ich nazw:
• nie spełnia warunku 4,
• może powodować wąskie gardło dla transakcji,
• jest pojedynczym powodem awarii całości.
 Rozwiązanie: prefiksowanie nazwy identyfikatorem miejsca - trudności ze
zmianą lokalizacji danych (przy zachowaniu tożsamości).
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 25
marzec 2002
Pojęcia związane z rozproszeniem
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 26
marzec 2002
Główne aspekty rozproszenia baz danych (1)
Przezroczystość (transparency)
Rozproszony SZBD powinien podtrzymywać rozproszenie
danych przy założeniu odizolowania programisty/użytkownika
od większości aspektów rozproszenia.
Współdziałanie (interoperability)
Oznacza współpracę zbudowanych niezależnie od siebie
heterogenicznych systemów (heterogeneous systems).
Aspektem współdziałania jest przyłączenie do rozproszonej BD
starych systemów, tzw. spadkowych (legacy)
Przenaszalność (portability)
Własność języka programowania i jego kompilatorów/interpreterów
umożliwiająca przenoszenie programów na różne platformy.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 27
marzec 2002
Główne aspekty rozproszenia baz danych (2)
Autonomia (autonomy)
Lokalne bazy danych podlegają własnym lokalnym regułom. Tylko
określona część lokalnych zasobów i usług jest udostępniana na
zewnątrz.
Niezależność danych (data independence)
Możliwość projektowania, utrzymywania, udostępniania, zmiany nośników,
zmiany reprezentacji, itp. działań na danych niezależnie od programów,
które na nich operują.
Ontologia (ontology), często w kontekście "ontologia biznesowa"
Formalny opis wszystkich tych własności lokalnej bazy danych, które są
niezbędne do tego, aby projektant/programista mógł prawidłowo
zaprogramować nową aplikację (np. mobilnego agenta).
Niekiedy ontologia jest określana jako metadane.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 28
marzec 2002
Przezroczystość (1)
Rozproszona BD musi spełniać warunki komfortu pracy programistów,
administratorów i użytkowników, jak również niezawodności,
bezpieczeństwa danych, zwiększenie odporności na błędy
programistów. To oznacza konieczność redukcji złożoności przy pracy z
rozproszoną bazą danych, co jest określane jako „przezroczystość”.
Ma ona następujące formy:
 Przezroczystość położenia: Umożliwienie jednorodnych metod
operowania na lokalnych i odległych danych. Tego warunku nie
spełnia np. system, w którym lokalna baza danych jest
obsługiwana przez pewien język 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.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 29
marzec 2002
Przezroczystość (2)
 Przezroczystość współbieżności: Umożliwia wielu użytkownikom
jednoczesny dostęp do danych bez konieczności uzgodnień i
porozumiewania się, przy zapewnieniu pełnej spójności danych i
przetwarzania.
 Przezroczystość skalowania: Umożliwienie dodawania nowych
elementów bazy danych bez wpływu na działanie starych aplikacji i
pracę użytkowników.
 Przezroczystość replikacji: Umożliwienie tworzenia i usuwania
kopii danych w innych miejscach geograficznych z bezpośrednim
skutkiem dla efektywności przetwarzania, ale bez skutków dla
postaci programów użytkowych lub pracy użytkownika końcowego.
 Przezroczystość wydajności: Umożliwienie dodawania nowych
elementów systemu komputerowego (np. serwerów, dysków) bez
wpływu na pracę większości użytkowników rozproszonej bazy
danych.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 30
marzec 2002
Przezroczystość (3)
 Przezroczystość fragmentacji (podziału): automatyczne scalanie
obiektów, tabel lub kolekcji, których fragmenty są przechowywane
w różnych miejscach.
 Przezroczystość awarii: Umożliwienie nieprzerwanej pracy
większości użytkowników rozproszonej bazy danych w sytuacji, gdy
niektóre z jej węzłów lub linie komunikacyjne uległy awarii.
 Przezroczystość migracji: Umożliwienie przenoszenia zasobów
danych do innych miejsc bez wpływu na pracę użytkowników.
W praktyce spełnienie wszystkich wymienionych warunków jest
ideałem, który prawdopodobnie nie został zrealizowany w żadnym
ze znanych systemów.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 31
marzec 2002
Współdziałanie i heterogeniczność
interoperability, heterogeneity
 Umożliwienie współdziałania heterogenicznych systemów
baz danych jest drugim ważnym aspektem rozproszenia.
 Heterogeniczność jest nieodłączną cechą dużych sieci
komputerowych, takich jak Internet, WWW, sieci
intranetowych, rozproszonych baz danych, systemów
przepływu prac, zasobów WWW opartych na plikach HTML i
XML, itd.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 32
marzec 2002
Heterogeniczność (niejednorodność)
 Np. system Intranetowy może składać się ze sprzętu:
•
•
•
•
•
komputerów klasy mainframe
stacji roboczych UNIX
komputerów PC pracujących pod MS Windows
komputerów Apple Macintosh
central telefonicznych, robotów, zautomatyzowanych linii produkcyjnych
 ...włączać różnorodne protokoły komunikacyjne: Ethernet,
FDDI, ATM, TCP/IP, Novell Netware, protokoły oparte na RPC,...
 ...bazować na różnych systemach zarządzania bazą
danych/dokumentów: Oracle,SQL Server, DB2, Lotus Notes,....
 ...oraz wymieniać pomiędzy sobą niejednorodne dane,
podlegające różnym modelom danych, schematom, semantyce,
mechanizmom dostępu,...
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 33
marzec 2002
Przyczyny heterogeniczności
 Niezależność działania: wytwórcy systemów nie uzgadniają między sobą ich
cech. Standardy, o ile się pojawiają, są spóźnione, niekompletne i nie
przestrzegane w 100%.
 Konkurencja: wytwórcy systemów starają się wyposażyć systemy w atrakcyjne
cechy, których nie posiadają konkurujące systemy
 Różnorodność pomysłów: Nie zdarza się, aby było jedno rozwiązanie dla
złożonego problemu. Różne zespoły znajdują różne rozwiązania, bazujące często
na odmiennych celach i założeniach.
 Efektywność finansowa i kompromisy: Wytwórcy oferują produkty o różnej
cenie, funkcjonalności i jakości, zgodnie z wyczuciem potencjalnych potrzeb
klientów, dostosowaniem się do ich portfela i maksymalizacją swoich zysków.
 Systemy spadkowe (legacy): Systemy, które dawno zostały wdrożone i działają
efektywnie, nie mogą być z tego działania wyłączone. Nie jest możliwe (lub jest
bardzo kosztowne) zastąpienie ich nowymi systemami. Nowe systemy, o
podobnym przeznaczeniu, posiadają inne założenia, cechy i funkcjonalności
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 34
marzec 2002
Przenaszalność
portability
Typy przenaszalności:
• Na poziomie składni, koncepcji języka i edukacji (np. SQL-92).
• Na poziomie kodu źródłowego (np. C++ (?), JDBC).
• Na poziomie interpretowanego kodu skryptowego lub pośredniego (np. Java).
• Na poziomie kodu binarnego (? - trudno podać przykład).
 Przenaszalność wymaga precyzyjnej specyfikacji składni i semantyki
języka, oraz wyeliminowania z niego własności specyficznych dla
poszczególnych platform.
 Wiele standardów nie spełnia kryterium przenaszalności z powodu
niedospecyfikowania i/lub nie spełniania standardu przez wytwórców
systemów.
 Przenaszalność jest celem standardów SQL, CORBA oraz ODMG,
niekoniecznie celem już osiągniętym.
 Przenaszalność realizuje kod pośredni języka Java, ale dotyczy to
funkcjonalności niskiego poziomu, np. nie dotyczy API do baz danych.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 35
marzec 2002
Autonomia
autonomy
Autonomia lokalnej bazy danych w federacji baz danych oznacza, że:
 Lokalne dane podlegają lokalnym priorytetom, regułom własności, autoryzacji
dostępu, bezpieczeństwa, itd. Lokalna baza danych może odrzucić zlecenia
przychodzące z federacji, o ile naruszają one lokalne ograniczenia lub zbytnio
obciążają czas procesora lub inne lokalne zasoby.
 Lokalna baza danych może udostępniać aplikacjom działającym na federacji baz
danych tylko określoną część swoich danych i usług. Programiści tych aplikacji
nie mają jakichkolwiek środków dostępu do pozostałych danych i usług.
 Włączenie lokalnej bazy danych do federacji nie może powodować konieczności
zmiany programów aplikacyjnych działających na lokalnej BD.
 Federacja może przetwarzać lokalne zasoby tylko poprzez interfejs
programowania aplikacji (API) specyficzny dla lokalnego systemu. Inne metody
(np. bezpośredni dostęp do plików) są niedozwolone.
 Federacja nie może żądać od lokalnej bazy danych zmiany/rozszerzenia jej usług
(np. udostępnienia lokalnego dziennika transakcji).
Możliwa jest pewna skala autonomii. Pojęcie autonomii jest raczej intuicyjne.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 36
marzec 2002
Wykład 2
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 37
marzec 2002
Niezależność danych
data independence
Oznacza, że nie ma potrzeby zmiany kodu programów aplikacyjnych mimo
zmian organizacji lub schematów danych. Jest osiągana poprzez interfejsy
programistyczne umożliwiające dostęp do danych na odpowiednim poziomie
abstrakcji, gdy niewidoczne są szczegóły organizacji i implementacji danych.
 Fizyczna niezależność danych: ukrycie detali organizacji fizycznej i
technik dostępu, dzięki czemu możliwa jest ich zmiana bez wpływu na
kod aplikacji.
 Logiczna niezależność danych: umożliwienie niektórych zmian
schematu logicznego bez wpływu na kod aplikacji, np. dodanie atrybutów
do relacji, zmiana kolejności atrybutów, zmiana ich typów, utworzenie
nowych relacji, itd.
 Ewolucja schematu (schema evolution): umożliwienie daleko idących
zmian schematu danych przy jednoczesnym utworzeniu perspektyw
(views) dla starych lub nowych danych. Perspektywy mają umożliwić
minimalną pracochłonność przy zmianach aplikacji (idealistycznie).
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 38
marzec 2002
Ontologia
ontology
 W filozofii: nauka o bytach, teoria bytu, opis charakteru i struktury
rzeczywistości, specyfikacja konceptualizacji.
 W sztucznej inteligencji: formalna specyfikacja (przy użyciu logiki
matematycznej) obiektów, pojęć i innych bytów, które istnieją w pewnej
dziedzinie, oraz formalna specyfikacja związków, które pomiędzy tymi
bytami zachodzą.
• Podejście sztucznej inteligencji jest naiwne.
• Np. Giełda Papierów Wartościowych: wiele tysięcy stron aktów prawnych,
zarządzeń, regulacji, itd. Jako (dożywotnia) kara dla sztucznego (ćwierć-)
inteligenta wypisującego bzdury na temat "formalnej ontologii": niech to
zapisze przy użyciu formuł rachunku predykatów.
 W biznesie (ontologia biznesowa, business ontology): wszystko to, co
projektanci systemów informatycznych powinni wiedzieć o biznesie, aby
poprawnie napisać aplikacje wspomagające ten biznes. Wiedza ta powinna
być formalnie zapisana. "Formalnie" oznacza zwykle pewien standardowy
i uzgodniony język, np. XML/RDF.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 39
marzec 2002
Ontologia i metadane
 Głównym celem prac na biznesową ontologią jest standardyzacja
następujących elementów:
• Gramatyki opisów poszczególnych bytów,
• Nazw i znaczeń nazw obowiązujących w ramach danego biznesu (np.
co oznaczają słowa "autor", "klient", "instrument", "akcja", itd.),
• Ograniczeń związanych z opisywanymi bytami,
• Metadanych związanych z bytami (autor opisu, data stworzenia opisu,
data ostatniej aktualizacji, itd.),
• Dopuszczalnych operacji na bytach.
 W tym zakresie zapis ontologii jest pewną meta-bazą danych, w które
ustala się zarówno strukturę samej bazy danych, jak i pewne dodatkowe
informacje (meta-atrybuty) będące podstawą przetwarzania bazy danych.
 Nieco inne podejście prezentuje standard RDF opracowany przez W3C,
gdzie ontologię reprezentują wyrażenia RDF.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 40
marzec 2002
Metadane
 Metadane są kluczowe dla wielu rozproszonych aplikacji, ponieważ
umożliwiają rozpoznanie z zewnętrz własności lokalnego zasobu danych
 Ogólna definicja: są to dane o danych - co dane zawierają, jaką mają
budowę, jakie jest ich znaczenie, jakim podlegają ograniczeniom, jak są
zorganizowane, przechowywane, zabezpieczane, udostępniane, itd.
 Metadane są pewnym rozszerzeniem pojęcia schematu bazy danych,
albo też pewną implementacją tego schematu w postaci katalogów.
 Metadane przykrywają także informację niezależną od treści samych
danych, np. kiedy pewna dana została utworzona, w jakim jest formacie,
kto jest jej autorem, do kiedy jest ważna, itd.
 Opisy danych zawarte w metadanych mają dwie podstawowe zalety:
• Zawierają wspólne abstrakcje dotyczące reprezentacji danych, takie jak
format; ogólnie "wyciągają przed nawias" wszystkie wspólne informacje, co
redukuje znacznie objętość samych danych;
• Reprezentują wiedzę dziedzinową (ontologię); umożliwiają wnioskowanie o
danych, mogą być przez to użyte do redukowania dostępu do samych danych.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 41
marzec 2002
Klasyfikacja metadanych
 Metadane niezależne od treści danych: lokacja danych, data
modyfikacji, typ kamery służącej do sporządzenia zdjęcia, itd. Mimo, że
nie składają się bezpośrednio na treść danych, mogą być ważnym
kryterium wyszukiwania.
 Metadane zależne od treści danych: rozmiar dokumentu, liczba kolorów,
liczba wierszy, liczba kolumn w tabeli. Metadane zależne od treści mogą
być dalej podzielone na:
• Bezpośrednie metadane dotyczące treści, np. indeksy, klasyfikacje, itd.
• Metadane opisujące treść: adnotacje o zawartości zdjęcia, np. opis zapachu
kwiatu przedstawionego na zdjęciu.
• Metadane niezależne od dziedziny biznesowej, której dotyczy treść, np.
definicje typu dokumentu HTML/SGML
• Metadane zależne od dziedziny biznesowej, np. schemat danych lub opis
ontologii biznesowej
 Podział na dane i metadane nie jest do końca jasny i silnie zależy od
nastawienia projektanta i podziału zadań podczas redakcji treści danych.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 42
marzec 2002
Protokół wymiany informacji w rozproszonej BD
 Protokół wymiany informacji pomiędzy rozproszonymi miejscami musi
uwzględniać:
• przesyłanie danych z jednego miejsca do drugiego miejsca
• przesyłanie zleceń (np. zapytań) do odległych miejsc celem przetwarzania
danych
• zwrotne przesyłanie wyników tych zleceń do zlecającego klienta
• automatyczną dystrybucję niektórych metadanych (np. schematu BD)
pomiędzy uczestników rozproszonej bazy danych.
• przesyłanie zapytań dotyczących metadanych
• przekazywanie wyników zapytań dotyczących metadanych do pytającego
 Aktualnie, protokoły takie istnieją w bardzo uproszczonej lub silnie
wyspecjalizowanej formie
• IIOP (Internet Inter-Orb Protocol) - bardzo uproszczony
• LDAP (Lightweight Directory Access Protocol) - silnie wyspecjalizowany
 Wiele ośrodków prowadzi prace badawcze nad uniwersalnymi
protokołami, opartymi o różnorodne języki zapytań.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 43
marzec 2002
Migracje obiektów
Migracja: przemieszczanie się obiektów między węzłami sieci, przy czym
obiekty muszą być skojarzone (statycznie lub dynamicznie związane) ze
swoimi klasami i przechowywanymi w ramach tych klas metodami. Problemy:
 Określenie jednostki migracji
 Śledzenie obiektów
 Utrzymywania porządku w katalogu systemu bazy danych
 Okresowa kondensacja łańcuchów obiektów pośrednich
 Przemieszczanie obiektów złożonych
 Zapewnienie globalnej przestrzeni nazw
 Zapewnienie właściwych mechanizmów zakresu i wiązania
 Dostępność metod umożliwiających przetwarzanie obiektów
Jak dotąd, metody są najczęściej składowymi aplikacji, a nie bazy danych.
Konsekwencją jest to, że po przemieszczeniu obiektu aplikacja działająca w jego
nowym miejscu musi mieć wbudowane (powielone, skompilowane, zlinkowane)
metody do jego przetwarzania.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 44
marzec 2002
Oprogramowanie komponentowe
Komercyjny buzzword, niezrealizowane marzenie informatyków od 30 lat.
Oznacza technologie zmierzające do budowy standardów oraz
wspomagającego je oprogramowania, które pozwoliłoby na składanie
dużych aplikacji lub systemów z mniejszych standardowych części komponentów, na zasadzie podobnej do składania komputera z
podzespołów.
Inne terminy: mega-programming, programming-in-the-large.
Jako przykłady wymienia się teraz: OMG CORBA, OpenDoc firm Apple,
IBM i innych, technologia .NET/COM/DCOM, Java Beans i Enterprise Java
Beans.
Komponenty mają wiele sukcesów.
Istnieją jednak problemy utrudniające szerokie ich stosowanie
 problemy z osiągnięciem akceptowalnej wydajności,
 trudności w precyzyjnym a jednocześnie dostatecznie
abstrakcyjnym wyspecyfikowaniu interfejsów pomiędzy
komponentami,
 dynamiczny postęp w informatyce, powodujący pojawianie się
coraz to nowych wymagań na interfejsy.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 45
marzec 2002
Obiektowość w systemach rozproszonych
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 46
marzec 2002
Obiektowość w rozproszonych bazach
danych
 Obiektowość zakłada zwiększenie stopnia abstrakcji,
przystosowanie modeli realizacyjnych systemów informatycznych
do naturalnych konstrukcji i obrazów myślowych projektantów,
programistów i użytkowników.
 Główny problem - opanowanie złożoności przy wytwarzaniu
oprogramowania.
 Punktem zainteresowania twórców narzędzi informatycznych
stają się procesy myślowe zachodzące w umysłach osób
pracujących nad oprogramowaniem => modelowanie
pojęciowe.
 Obiektowość przerzuca ciężar problemu z kwestii narzędziowej (jak
mam to zrobić?) na kwestię merytoryczną (co mam zrobić i po
co?).
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 47
marzec 2002
Źródła złożoności projektu oprogramowania
Zespół projektantów
Dziedzina problemowa,
obejmująca ogromną liczbę
wzajemnie uzależnionych
aspektów i problemów.
Środki i technologie
informatyczne:
sprzęt, oprogramowanie, sieć,
języki, narzędzia, udogodnienia.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 48
Oprogramowanie:
decyzje strategiczne,
analiza,
projektowanie,
konstrukcja,
dokumentacja,
wdrożenie,
szkolenie,
eksploatacja,
pielęgnacja,
modyfikacja.
podlegający ograniczeniom
pamięci, percepcji, wyrażania
informacji i komunikacji.
Potencjalni użytkownicy:
czynniki psychologiczne,
ergonomia, ograniczenia pamięci
i percepcji, skłonność do błędów
i nadużyć, tajność, prywatność.
marzec 2002
Jak walczyć ze złożonością ?
Zasada dekompozycji:
rozdzielenie złożonego problemu na podproblemy, które można rozpatrywać i
rozwiązywać niezależnie od siebie i niezależnie od całości.
Zasada abstrakcji:
eliminacja, ukrycie lub pominięcie mniej istotnych szczegółów rozważanego
przedmiotu lub mniej istotnej informacji; wyodrębnianie cech wspólnych i
niezmiennych dla pewnego zbioru bytów i wprowadzaniu pojęć lub symboli
oznaczających takie cechy.
Zasada ponownego użycia:
wykorzystanie wcześniej wytworzonych schematów, metod,
komponentów projektu, komponentów oprogramowania, itd.
wzorców,
Zasada sprzyjania naturalnym ludzkim własnościom:
dopasowanie modeli pojęciowych i modeli realizacyjnych systemów do
wrodzonych ludzkich własności psychologicznych, instynktów oraz mentalnych
mechanizmów percepcji i rozumienia świata.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 49
marzec 2002
Modelowanie pojęciowe
Projektant i programista muszą dokładnie wyobrazić sobie problem
oraz metodę jego rozwiązania. Zasadnicze procesy tworzenia
oprogramowania zachodzą w ludzkim umyśle i nie są związane z
jakimkolwiek językiem programowania.
Pojęcia modelowania pojęciowego (conceptual modeling) oraz
modelu pojęciowego (conceptual model) odnoszą się procesów
myślowych
i
wyobrażeń
towarzyszących
pracy
nad
oprogramowaniem.
Modelowanie pojęciowe jest wspomagane przez środki
wzmacniające ludzką pamięć i wyobraźnię. Służą one do
przedstawienia rzeczywistości opisywanej przez dane, procesów
zachodzących w rzeczywistości, struktur danych oraz programów
składających się na konstrukcję systemu.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 50
marzec 2002
Perspektywy w modelowaniu pojęciowym
odwzorowanie
odwzorowanie
...
... ......
... ......
...
Percepcja
rzeczywistego
świata
Analityczny
model
rzeczywistości
... ...
... ...
...
...
... ...
... ...
Model
struktur danych
i procesów SI
Trwałą tendencją w rozwoju metod i narzędzi projektowania oraz
konstrukcji SI jest dążenie do minimalizacji luki pomiędzy
myśleniem o rzeczywistym problemie a myśleniem o danych i
procesach zachodzących na danych.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 51
marzec 2002
Przykład: pojęciowy schemat obiektowy w UML
Osoba
Nazwisko
Imię *
Adres *
Pracownik
Zawód *
0..*
PZ
1
Zatrudnienie
Wypłata *
0..*
Ocena *
FZ
Firma
Nazwa
1 Miejsce *
Nie więcej niż 10 sekund zastanawiania się, co ten diagram przedstawia
i jak jest semantyka jego elementów.
Potem można już programować np. w C++ lub Java.
Co otrzymamy po odwzorowaniu tego schematu na schemat relacyjny?
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 52
marzec 2002
Schemat relacyjny
Firma(NrF, Nazwa)
Zatrudnienie(NrF, NrP)
Lokal(NrF, Miejsce)
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).
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 53
marzec 2002
Skutki niezgodności modelu pojęciowego i
relacyjnego
Programy odwołujące się do schematu relacyjnego są dłuższe od programów
odwołujących się do schematu obiektowego (szacunkowo od 30% do 70%). Ma
to ogromne znaczenie dla tempa tworzenia oprogramowania, jego jakości,
pielęgnacyjności, itd. Programy te są też zwykle znacznie wolniejsze.
Mini przykład:
Podaj adresy pracowników pracujących w firmach zlokalizowanych w Radomiu
SBQL: (Firma where ”Radom” in Miejsce).FZ.Zatrudnienie.PZ.Pracownik.Adres
SQL:
select a.Adres
from Lokal as k, Zatrudnienie as z, Pracownik as p, Osoba as s, Adresy as a
where k.Miejsce = “Radom” and k.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.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 54
marzec 2002
Rozproszone obiektowe bazy danych
 Problemy są podobne jak w przypadku rozproszonych relacyjnych
BD.
 Nie jest jednak pewne czy do przetwarzania zapytań w tych
systemach będą się odnosić te same metody.
 Problemy, różniące przetwarzanie zapytań w rozproszonych
obiektowych BD i w rozproszonych relacyjnych BD:
• Obiekty nie zawsze są implementowane jako "płaskie" zapisy.
• Obiekty mogą mieć referencje do obiektów zlokalizowanych w innych
węzłach sieci.
• Przetwarzanie zapytań może dotyczyć kolekcji złożonych obiektów
• Zapytania mogą mieć odwołania do metod.
 Przetwarzanie zapytań w rozproszonych systemach obiektowych
jest tematem bardzo istotnym. Standard ODMG tym się nie
zajmuje.
 Jak dotąd, w zakresie przetwarzania rozproszonych zapytań nie
rozwiązano podstawowych problemów koncepcyjnych.
marzec 2002
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 55
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.
Zapytanie
Aplikacja
użytkownika
użytkownika
Oprogramowanie
klient/serwer
Oprogramowanie
serwera
Oprogramowanie
serwera
Podsystem
komunikacyjny
Oprogramowanie
klient/serwer
Zapytanie
użytkownika
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 56
Oprogramowanie
klient/serwer
Aplikacja
użytkownika
Zapytanie
użytkownika
marzec 2002
Zalety rozproszonych obiektów
 Zgodność z logiką biznesu - bezpośrednia implementacja obiektów
biznesowych.
 Umożliwienie projektantom opóźnienie decyzji - gdzie i jakie usługi powinny
być zapewnione.
 Skalowalność aplikacji: mała zależność czasu reakcji systemu od zwiększenia
ilości danych, liczby użytkowników, liczby węzłów.
 Dekompozycja aplikacji na małe elementy wykonawcze (obiekty, metody,...).
 Przyrostowe dodawanie/odejmowanie funkcjonalności (“płacę tylko za to,
czego używam”).
 Podział zasobów i zbalansowanie obciążeń.
 Współbieżność i asynchroniczne przetwarzanie.
 Elastyczność zmian w oprogramowaniu (konserwacja), w szczególności,
przenoszenie obiektów i usług do innych miejsc.
 Możliwość przyłączania aplikacji spadkowych (funkcjonujących wcześniej
jako scentralizowane).
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 57
marzec 2002
Projektowanie rozproszonych baz danych
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 58
marzec 2002
Podejścia do projektowania rozproszonych
BD: top-down i bottom-up
Od ogółu do szczegółów:
top-down
bottom-up
Odgórne zaprojektowanie całej bazy danych,
z uwzględnieniem optymalizacji
przechowywanych danych, narzuconej przez
fakt geograficznego rozproszenia
producentów i konsumentów informacji
przechowywanej w bazie danych.
Od szczegółów do ogółu:
Zintegrowanie już istniejących (spadkowych)
lub zaprojektowanych lokalnych baz danych
w jedną globalną rozproszoną bazę danych.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 59
marzec 2002
Projektowanie: podejście top-down
Analiza
Model pojęciowy
scentralizowany
Analiza systemowa: rozpoznanie
wymagań, precyzowanie
kontekstu przyszłej bazy danych.
Projektowanie schematu
pojęciowego
Projektowanie struktury
logicznej
Model logiczny
scentralizowany
Modele logiczne
dla
poszczególnych
miejsc
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 60
Kryteria
rozproszenia
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,marzec
a 2002
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 marzec 2002
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 61
Podstawowe metody fragmentacji schematu
 Fragmentacja pionowa oznacza przyporządkowanie
poszczególnych klas obiektów do poszczególnych miejsc, lub
rozbicie obiektów danej klasy na dwa lub więcej podobiektów, przy
czym takie podobiekty są przechowywane w różnych miejscach.
 Fragmentacja pionowa może oznaczać konieczność
odpowiedniego podziału informacji zawartych w klasach obiektów
oraz ustalenia środków podtrzymania jednoznacznej tożsamości
obiektów.
 Fragmentacja pozioma oznacza rozbicie populacji obiektów
danej klasy na dwa lub więcej miejsc geograficznych.
 Fragmentacja pozioma może być dokonywana na podstawie
różnych kryteriów, które często wiązane są z geograficznym
ulokowaniem obiektów rzeczywistych, lub też z geograficznym
ulokowaniem przetwarzania tych obiektów.
marzec 2002
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 62
Fragmentacja pionowa relacyjnej bazy danych
Warszawa
Kutno
DC
DOSTAWCA_DANE
DNR NAZW
D1
D2
D3
D4
D5
Abacki
Bober
Czerny
Dąbek
Erbel
DNR CNR ILOŚĆ
STATUS
20
10
30
20
30
Sieć
Gdańsk
DOSTAWCA_MIASTO
DNR
D1
D2
D3
D4
D5
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 63
MIASTO
D1
D1
D1
D1
D1
D1
D2
D2
D3
D4
D4
D4
C1
C2
C3
C4
C5
C6
C1
C2
C2
C2
C4
C5
300
200
400
200
100
100
300
400
200
200
300
400
Lublin
Poznań
Poznań
Lublin
Radom
marzec 2002
Fragmentacja pozioma relacyjnej bazy danych
DOSTAWCA
DNR NAZW
D2 Bober
D3 Czerny
Poznań
DC
DNR CNR ILOŚĆ
STATUS MIASTO
10 Poznań
30 Poznań
D2
D2
D3
C1
C2
C2
300
400
200
Lublin
DOSTAWCA
Sieć
DNR NAZW
STATUS MIASTO
D1 Abacki
D4 Dąbek
20 Lublin
20 Lublin
DC
DOSTAWCA
DNR NAZW
D5 Erbel
Radom
STATUS MIASTO
30 Radom
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 64
DNR CNR ILOŚĆ
D1
D4
D4
C6
C2
C4
100
200
300
marzec 2002
Fragmentacja pionowa obiektów Pracownik
Radom
Klasa danych
osobistych
Nowak
dane osobiste
Kowalski
dane osobiste
...
Kalisz
Sieć
Nowak
dane o ocenach
Kraków
Nowak
dane o zatrud.
Klasa danych o
ocenach
Kowalski
dane o ocenach
...
Klasa danych o
zatrudnieniu
Kowalski
dane o zatrud.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 65
...
marzec 2002
Fragmentacja pozioma obiektów Pracownik
Radom
Klasa
Pracownik
Pracownik
Nowak
Pracownik
Kowalski
Obiekty Pracownik są
przechowywane zgodnie z
geograficznym położeniem
pracodawcy.
...
Kalisz
Sieć
Pracownik
Styka
Kraków
Pracownik
Malasa
Klasa
Pracownik
Pracownik
Malina
...
Klasa
Pracownik
Pracownik
Zagórny.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 66
...
marzec 2002
Inne fragmentacje danych w rozproszonej BD
 Możliwe są inne, bardziej złożone fragmentacje danych, które łączą
fragmentacje pionowe, fragmentacje poziome oraz redundantne dane
(replikacje).
 Bardziej złożone fragmentacje rodzą trudności z:
• zarządzaniem metadanymi: gdzieś muszą być ulokowane informacje
odnośnie tego w jaki sposób podzielone dane mają być scalone w
kompletne obiekty lub kolekcje w ramach rozproszonej bazy danych.
Jest to rola metadanych oraz mechanizmu właściwej dystrybucji
metadanych pomiędzy uczestników rozproszonej bazy danych.
• przetwarzaniem zapytań: dekompozycja zapytania na pod-zapytania
adresowane do poszczególnych miejsc staje się znacznie bardziej
kłopotliwa. Przesyłanie fragmentów obiektów celem ich
zmaterializowania po stronie klienta może być zbyt kosztowne.
 Bardziej złożone fragmentacje mogą być nie do uniknięcia w rozproszonej
bazie danych integrującej istniejące bazy danych (podejście bottom-up).
Ma to konsekwencje dla zarządzania metadanymi.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 67
marzec 2002
Projektowanie: podejście bottom-up
 Podejście ad hoc: Budowa uniwersalnych lub specyficznych
dla danego zastosowania pomostów (gateways)
umożliwiających dostęp z danego systemu bazy danych do
innych baz danych. Pomost może (nie musi) zapewniać
przezroczystość rozproszenia.
 Podejście oparte o globalny schemat: Wszystkie składniki
rozproszonej BD są objęte jednym globalnym schematem,
jednakowym dla każdego miejsca i zapewniającym
przezroczystość rozproszenia. Istotną wadą podejścia
opartego na globalnym schemacie jest brak możliwości
sterowania zakresem autonomii każdego lokalnego systemu.
 Federacyjna baza danych: Każda lokalna baza danych
zachowuje swoją autonomię, udostępniając tylko część
danych dla innych miejsc w RBD. Podejście federacyjne
zakłada, że każda lokalna baza danych jest widziana poprzez
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 68
marzec 2002
Federacyjna BD tworzona metodą bottom-up
Aplikacje
globalne
Aplikacje
Aplikacjeglobalne
globalne
Schemat federacyjnej bazy danych
Perspektywa
Mediator
Osłona
Perspektywa
Mediator
Osłona
Schemat lokalny 1
Miejsce 1
Aplikacje
Aplikacje
Aplikacje
lokalne
lokalne
lokalne
Schemat lokalny 2
Miejsce 2
Baza
danych 1
Aplikacje
Aplikacje
Aplikacje
lokalne
lokalne
lokalne
Baza
danych 2
.....
Podejście federacyjne okazało się skuteczne ze względu na zapewnienie
autonomii, bezpieczeństwa i efektywności. Rodzi jednak dużo problemów, m.in.
z zapewnieniem jednolitej ontologii biznesowej, uniwersalnością aplikacji,
wydajnością, itd.
marzec 2002
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 69
Wykład 3
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 70
marzec 2002
Architektury rozproszonych baz danych
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 71
marzec 2002
Architektura klient-serwer
Całość pracy wykonywanej przez system komputerowy jest
podzielona na dwie części:
wykonywaną po stronie klienta
(zwykle związaną z interakcją z
użytkownikiem)
wykonywaną po stronie serwera
(komunikacja, dostęp do bazy danych,
zarządzanie repozytoriami pamięci,
zarządzanie globalną przestrzenią
nazw)
Określenie mechanizmu komunikacji pomiędzy
klientem a serwerem.
Podstawowe
problemy:
Podział funkcji na te, które są wykonywane po stronie
klienta i te, które są wykonywane po stronie serwera
Określenie jednostki komunikacji klient - serwer
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 72
marzec 2002
Reguły architektury klient-serwer (1)
 Zachowanie autonomii serwera. Klienci powinni zachowywać reguły
wykorzystania serwera, nie powinni powodować jego niedostępność (np.
zamykać duże ilości danych), nie powinni łamać ograniczeń integralności.
 Zachowanie autonomii klienta. Klienci nie powinni zachowywać się
różnie w zależności od tego, czy serwer jest lokalny czy odległy. Powinni
być odizolowani od kwestii fizycznego ulokowania danych.
 Wspomaganie dla aplikacji niezależnych od serwera.
 Dostęp do własności (danych, usług) serwera. Klienci mogą żądać od
serwera wykonanie przewidzianych dla niego funkcji.
 Wspomaganie dla bieżącego dostępu do danych. Dostęp ten powinien
być bezpośredni, bez pośrednictwa plików przekazywanych do/od klienta.
 Minimalny wpływ architektury K/S na wymagania dla klienta.
Oprogramowanie klienta w architekturze K/S nie powinno wykazywać
znacznego zwiększenia zapotrzebowania na RAM lub objętość dysku.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 73
marzec 2002
Reguły architektury klient-serwer (2)
 Kompletność opcji niezbędnych do połączenia. Oprogramowanie
klienta nie powinno zawierać kodu realizującego połączenie z
serwerem.Powinien to zapewniać serwer komunikacyjny.
 Możliwość budowy lokalnych prototypów. Programista powinien mieć
możliwość budowy i testowania aplikacji K/S wyłącznie na stacji klienta.
 Kompletność narzędzi użytkownika końcowego. Projektowanie
ekranów, generacja zapytań, itd. powinny być częścią środowiska.
 Kompletność środowiska budowy aplikacji. Powinno przewidywać
możliwość łączenia się w sieci, dostęp do usług globalnych w zakresie
nazw, lokacji danych, itd.
 Otwarte środowisko języka-gospodarza. Powinno zapewniać
możliwość użycia uniwersalnego języka programowania do budowy
aplikacji.
 Szczególna troska o standardy. Im bardziej będą one przestrzegane, tym
mniej będzie późniejszych kłopotów ze współdziałaniem.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 74
marzec 2002
Przykład architektury SZBD typu klient-serwer
Aplikacja generująca transakcje
Aplikacja generująca transakcje
Zarządzanie
transakcjami
Zarządzanie
transakcjami
Zarządzanie
buforami
...
Zarządzanie
buforami
Zarządzanie zasobami
Zarządzanie zasobami
Klient 1
Klient n
Zarządzanie
siecią
Interfejs serwera
Zarządzanie
zasobami
Zarządzanie
transakcjami
Zarządzanie
logiem
Zarządzanie
buforami
Zarządzanie
zamkami
Serwer
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 75
marzec 2002
Architektura klient-(multi) serwer (1)
Połączenia bezpośrednie:
k2
k3
k7
k1
s4
k4
k5
s1
k8
s3
s2
k9
k6
k10
k11
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 76
marzec 2002
Architektura klient-(multi) serwer (2)
Połączenia poprzez sieć: nie ma bezpośrednich połączeń, zarówno serwery jak i
klienci są przyłączani w jednakowy sposób do wspólnej sieci komputerowej.
k2
k1
s4
k3
k9
k4
Sieć komputerowa
s1
k8
s3
k5
k6
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 77
s2
k7
marzec 2002
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)
Interfejs
użytkownika
• serwer (serwery) bazy danych.
 Warstwy są zaprojektowane i istnieją niezależnie, co
ma duże znaczenie dla pielęgnacyjności systemu ze
względu na możliwość zmian w dowolnej warstwie
bez konieczności zmian w pozostałych warstwach.
 Często warstwy są zrealizowane na odrębnych
platformach: interfejs na MS Windows, logika
przetwarzania na serwerze aplikacji i baza danych na
serwerze bazy danych.
 Środkowa warstwa może składać się z wielu warstw,
co jest określane jako architektura wielowarstwowa.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 78
Logika przetwarzania
Serwer
bazy
danych
Serwer
bazy
danych
marzec 2002
Logiczna architektura oprogramowania
Architektura klient-serwer powinna odzwierciedlać logiczny podział
oprogramowania na części. Nie jest to tak istotne w systemie scentralizowanym.
Architektura trójwarstwowa:
cienki
klient
Warstwa prezentacyjna
(interfejs użytkownika)
gruby
klient
Warstwa przetwarzania
(logika biznesu)
Warstwa zarządzania
bazą danych
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 79
Staranne rozdzielenie tych warstw jest
bardzo istotne z punktu widzenia
tworzenia i modyfikowalności
oprogramowania. Dzięki temu
rozdzieleniu, możliwa jest np. poprawa
interfejsu użytkownika bez jakichkolwiek
interwencji w pozostałe warstwy
oprogramowania.
Zasada oddzielania aspektów
(separation of concerns principle,
E.Dijkstra)
marzec 2002
Cienki i gruby klient
Terminy cienki klient (thin client) oraz gruby klient (fat client) odnoszą się do
mocy i jakości przetwarzania po stronie klienta w architekturze klient-serwer.
Model cienkiego klienta: klient posiada niezbyt wielką moc przetwarzania,
ograniczoną do prezentacji danych na ekranie. Przykładem jest klient w postaci
przeglądarki WWW.
Model grubego klienta: klient posiada znacznie bogatsze możliwości
przetwarzania, w szczególności może zajmować się nie tylko warstwą
prezentacji, lecz także warstwą przetwarzania aplikacyjnego (logiki biznesu).
Powyższy podział posiada oczywiście pewną gradację.
Model cienkiego klienta jest najczęstszym rozwiązaniem w sytuacji, kiedy
system scentralizowany jest zamieniany na architekturę klient-serwer. Wadą jest
duże obciążenie serwera i linii komunikacyjnych.
Model grubego klienta używa większej mocy komputera klienta do
przetwarzania zarówno prezentacji jak i logiki biznesu. Serwer zajmuje się tylko
obsługą transakcji bazy danych. Popularnym przykładem grubego klienta jest
bankomat. Zarządzanie w modelu grubego klienta jest bardziej złożone.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 80
marzec 2002
Architektury dwuwarstwowe
Uproszczone architektury trójwarstwowe z cienkim lub grubym klientem.
cienki
klient
Warstwa prezentacyjna
(interfejs użytkownika)
Warstwa przetwarzania
(logika biznesu) +
Warstwa zarządzania
bazą danych
Warstwa prezentacyjna
(interfejs użytkownika)
+ Warstwa przetwarzania
(logika biznesu)
gruby
klient
Warstwa przetwarzania
(logika biznesu) +
Warstwa zarządzania
bazą danych
W tym modelu przetwarzanie
(logika biznesu) jest dzielone
pomiędzy klienta i serwera.
Zaprojektowanie jej jest trudniejsze.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 81
marzec 2002
Przykład architektury K/S - sieć bankomatów
Bankomat
Bankomat
Serwer kont klientów banku
Monitor
Baza danych kont
tele-przetwarzania klientów banku
Bankomat
Bankomat
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 82
Oprogramowanie pośredniczące
organizujące komunikację z odległymi
klientami i szeregujące transakcje klientów
celem przetwarzania ich przez bazę danych.
marzec 2002
Przykład architektury K/S - portal WWW
klient
interakcja
poprzez
HTTP
Serwer Web:
klient
klient
generacja
dynamicznych stron
HTML dla klienta
+
zlecenia do bazy
danych
zapytania
SQL
wyniki
zapytań
SQL
Serwer bazy
danych:
wykonywanie
zapytań w SQL
klient
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 83
marzec 2002
3-warstwowa architektura aplikacji Web
Serwer Web
Sieć
Internet
Serwer aplikacji
Serwer bazy danych
HTTP
Baza
danych
Baza
danych
Przeglądarka
Serwer
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 84
marzec 2002
2-warstwowa architektura aplikacji Web
Wiele warstw pośredniczących powoduje dodatkowe obciążenie.
Sieć
Internet
Serwer Web
Serwer aplikacji
Serwer bazy danych
HTTP
Baza
danych
Baza
danych
Przeglądarka
Serwer
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 85
marzec 2002
Zastosowanie różnych architektur K/S
 Dwuwarstwowa architektura K/S z cienkim klientem
• Systemy spadkowe (legacy), gdzie oddzielenie przetwarzania i zarządzania danymi
jest niepraktyczne.
• Aplikacje zorientowane na obliczenia, np. kompilatory, gdzie nie występuje lub jest
bardzo mała interakcja z bazą danych.
• Aplikacje zorientowane na dane (przeglądanie i zadawanie pytań) gdzie nie występuje
lub jest bardzo małe przetwarzanie.
 Dwuwarstwowa architektura K/S z grubym klientem
• Aplikacje w których przetwarzanie jest zapewnione przez wyspecjalizowane
oprogramowanie klienta, np. MS Excel.
• Aplikacje ze złożonym przetwarzaniem (np. wizualizacją danych, przetwarzaniem
multimediów).
• Aplikacje ze stabilną funkcjonalnością dla użytkownika, użyte w środowisku z dobrze
określonym zarządzaniem.
 Trzywarstwowa lub wielowarstwowa archiktektura K/S
• Aplikacje o dużej skali z setkami lub tysiącami klientów.
• Aplikacje gdzie zarówno dane jak i aplikacje są ulotne (zmienne).
• Aplikacje integrujące dane z wielu rozproszonych źródeł.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 86
marzec 2002
Architektura rozproszonych obiektów (1)
 W architekturze klient-serwer istnieje wyraźna asymetria pomiędzy klientem i
serwerem; w szczególności, nie występuje tam komunikacja bezpośrednio
pomiędzy klientami. Model taki dla wielu zastosowań jest mało elastyczny i
zapewnia zbyt małą skalowalność.
 Architektura rozproszonych obiektów znosi podział na klientów i serwery.
Każde miejsce w rozproszonym systemie jest jednocześnie klientem i serwerem.
 Konieczne jest sprowadzenie wszystkich danych i usług do jednego standardu.
 Taki standard obejmuje:
• Model (pojęciowy i logiczny) danych i usług, który jest w stanie "przykryć" wszystkie
możliwe dane i usługi, które mogą kiedykolwiek pojawić się w systemie
rozproszonym;
• Specjalne oprogramowanie zwane pośrednikiem (broker), które akceptuje wspólny
model danych i usług umożliwiając ich udostępnienie dla dowolnych miejsc w
systemie rozproszonym.
• Specjalne oprogramowanie, zwane osłoną, adapterem lub mediatorem, które
przystosowuje konkretne miejsce do modelu przyjętego przez pośrednika.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 87
marzec 2002
Architektura rozproszonych obiektów (2)
...
Aplikacja
napisana w
C++
Aplikacja na
relacyjnej
bazie danych
Aplikacja
na Lotus
Notes
Osłona 1
Osłona 2
Osłona 3
Pośrednik
Pośrednik
Pośrednik
...
Szyna oprogramowania (software bus)
Miejsce 1
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 88
Miejsce 2
Miejsce 3
marzec 2002
Struktura logiczna rozproszonych obiektów
O3
O1
O2
Obiekty
Operacje na
obiektach
O7
O5
O9
O4
K1
O8
O6
K3
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.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 89
marzec 2002
Architektura serwera stron
Aplikacja
Przedmiotem
zarządzania
są fizyczne
strony dyskowe
Interfejs
zapytaniowy
Optymalizacja
zapytań
Przeglądarka
obiektów
Interfejs
programistyczny
Zarządzanie obiektami
Zarządzanie plikami i indeksami
Zarządzanie kieszenią stron
strony
Zarządzanie zamkami
Zarządzanie składem
Zarządzanie kieszenią stron
Obiektowa
baza
danych
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 90
marzec 2002
Architektura serwera obiektów
Aplikacja
Przedmiotem
zarządzania
są obiekty
Interfejs
zapytaniowy
Przeglądarka
obiektów
Interfejs
programistyczny
Zarządzanie obiektami
obiekty
Zarządzanie obiektami
Optymalizacja zapytań
Zarządzanie zamkami
Zarządzanie składem
Zarządzanie stronami i kieszeniami
Obiektowa
baza
danych
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 91
marzec 2002
Przyszłościowa architektura aplikacji
internetowych
Przeglądarka
WWW
Narzędzia
wspomagające XML :
system autorski, itd.
Warstwa klienta
Przeglądarka
WWW
XML
XML
Serwer Web
Serwer aplikacji
Interakcja z aplikacjami poprzez
protokoły oparte na XML
Logiczna warstwa pośrednia
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
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 92
Dokumenty
Dokumenty
XML
XML
nana
Webie
Webie
Inne
Inne
dokumenty
dokumentynana
Webie:
Webie:HTML
HTML
Word,...
Word,...
Zasoby danych
pod OLE/DB
marzec 2002
Standardy łączenia rozproszonych
zasobów
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 93
marzec 2002
Standardy łączenia rozproszonych danych (1)
 Open 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 niebazodanowe, takie jak płaskie pliki.
• OLE-DB program może negocjować ze źródłem danych aby znaleźć
własności, które ono podtrzymuje.
• API jest podzbiorem SQL
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 94
marzec 2002
Standardy łączenia rozproszonych danych (2)
 ADO (Active Data Objects): łatwy interfejs do funkcji OLE-DB
 Kilka standardów bazujących na XML dla E-commerce
• Np. 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)
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 95
marzec 2002
Standardy łączenia rozproszonych danych (3)
 Object Data Management Group (ODMG) standard obiektowych baz
danych
• jest używany w projektach przyszłościowych związanych z rozproszonymi
lub federacyjnymi bazami danych, np. IRO/DB.
 OMG CORBA (Common Object Request Broker Architecture) najbardziej uniwersalny standard obejmujący ogromną liczbę aspektów.
W szczególności, notacja UML jest jego składową. Pakiety ORB (Object
Request Broker) są oprogramowaniem realizującym tę architekturą.
 .NET/DCOM (Distributed Component Object Model) - standard
Microsoftu zintegrowany z systemami operacyjnymi Microsoftu.
Znacznie ograniczony w stosunku do standardu CORBA.
 RMI (Remote Method Invocation) - oprogramowanie firmy Sun,
ograniczone w stosunku do standardu CORBA do oprogramowania
pisanego w Java. Java Beans i Enterprise Java Beans wykorzystują RMI
jako transport.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 96
marzec 2002
Replikacje
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 97
marzec 2002
Replikacje
Technologia replikacji oznacza przechowywanie dwóch lub więcej
kopii danych (replik) w oddalonych geograficznie miejscach.
Cele:
Zwiększenie dostępności danych poprzez:
- zminimalizowanie czasu i kosztów ich transmisji z odległego
miejsca
- rozłożenie obciążenia w zakresie dostępu na wiele kopii danych
Zwiększenie odporności danych na zniszczenie.
Zwiększenie bezpieczeństwa
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 98
marzec 2002
Aktualizacja replikacji
Aktualizacja dowolnej kopii danych powinna spowodować jednoczesną
aktualizację wszystkich pozostałych kopii. W idealnym przypadku powinno to
następować jednocześnie, aby zapobiec sytuacji, gdy dane przechowywane w
różnych kopiach są wzajemnie niespójne. Ten ideał nie daje się zrealizować tak
łatwo z kilku powodów:
Czas transmisji zleceń aktualizacyjnych powoduje, że kopie są chwilowo
wzajemnie niezgodne;
Zawodność łączy i węzłów sieci może spowodować czasową niemożliwość
wykonania zlecenia aktualizacyjnego;
Koszt transmisji zleceń aktualizacyjnych może być nieakceptowalny w przypadku
bardzo częstych zmian.
Można wyobrazić sobie sytuację, kiedy każda aktualizacja dowolnej kopii jest
wykonywana w ramach transakcji, która nie będzie potwierdzona aż do momentu
zaktualizowania wszystkich kopii. Takie rozwiązanie w większości przypadków
powoduje jednak znaczne zmniejszenie dostępności danych.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 99
marzec 2002
Modele replikacji
Jednoczesne aktualizacje
ze sterowaniem współbieżnościa
Transakcja aktualizująca
Propagacja aktualizacji
Transakcja aktualizująca
propagacja
aktualizacji
Replika 1
Replika 2
Replika 3
Replika 3
Replika 1
Replika 2
Planowane odświeżanie kopii dla replik tylko do czytania
Transakcja aktualizująca
planowana
aktualizacja
Transakcja czytająca
Replika 3
Replika 1
Transakcja czytająca
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 100
Replika 2
marzec 2002
Wady replikacji
 Konieczna dodatkowa przestrzeń dyskowa
 Możliwość powstania niespójności pomiędzy repliką i oryginałem
=> zagrożenie dla spójności procesów biznesowych
• Np. jeżeli dane o wysokości kont są powtórzone w wielu miejscach, wówczas
ktoś korzystając z (celowo) uszkodzonych linii transmisyjnych może dokonać
nielegalnych wypłat.
 Zwiększenie kosztów aktualizacji danych: aktualizacja oryginału
pociąga za sobą dodatkowy koszt aktualizacji replik
• reguła kciuka (bardzo uproszczona):
ilość zapytań czytających
> ilość replik
ilość zleceń aktualizujących
to warto tworzyć repliki.
W przeciwnym przypadku - nie warto.
Jeżeli
• Przy dokładnej analizie należy utworzyć bardziej złożone modele kosztów,
które ustalą opłacalność replik.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 101
marzec 2002
Przetwarzanie transakcji
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 102
marzec 2002
Przetwarzanie transakcji
Problemy z transakcjami w systemach rozproszonych:
 Faza potwierdzenia (commit) może trwać długo. Niepowodzenie
(awaria) w tej fazie może spowodować niespójność bazy danych i
przetwarzania. Stąd nowe protokoły przetwarzania transakcji w
systemie rozproszonym: 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
dostęp
zablokowanych danych.
marzec 2002
© K.Subieta.umożliwić
Rozproszone i federacyjne
bazy danych, do
Folia 103
Implementacja transakcji poprzez zamki
Zamek (lock): jedna z transakcji rezerwuje sobie dostęp do obiektu.
Spójność przetwarzania transakcji jest zachowana, jeżeli cała transakcja ma dwie fazy:
rosnącą i skracającą.
start
potwierdzenie
(commit)
zakładanie zamków
(nie ma zwalniania)
koniec
zwalnianie
zamków (nie
ma zakladania)
czas
Awaria w fazie potwierdzenia jest krytyczna, gdyż grozi utratą spójności.
 W systemach rozproszonych faza potwierdzenia może trwać minuty i włącza
zawodne zawodne elementy infrastruktury (łącza).
 Warunek atomowości oznacza, że jeżeli transakcja dzieli się na wiele
podtransakcji wykonywanych na odległych serwerach, to nie może zajść sytuacja,
gdy podtransakcja na serwerze A jest potwierdzona, zaś podtransakcja na
serwerze B jest zerwana.
 Stąd konieczność dodatkowej ochrony fazy potwierdzenia => 2PC.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 104
marzec 2002
Dwufazowe potwierdzenie (2PC)
Koordynator (program aplikacyjny klienta)
potwierdź
SZBD klienta
SZBD serwera
SZBD serwera
SZBD serwera
1. Serwery wysyłają komunikaty “gotów “ do koordynatora.
2. Po skompletowaniu wszystkich zgłoszeń koordynator wysyła komunikat
“potwierdź” do wszystkich serwerów.
Jeżeli nie nadejdą wszystkie zgłoszenia “gotów”, koordynator wysyła komunikat
“zerwij transakcję” do wszystkich serwerów.
Wada: duże straty wykonanej pracy w przypadku zerwania.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 105
marzec 2002
2PC - zarządzanie awariami
 Dość złożone postępowanie zależne od tego, czy awarii uległ serwer czy
też koordynator.
 Protokół 2PC określa:
• Czas graniczny (timeout) nadesłania sygnału "gotów" od wszystkich
serwerów do koordynatora . Jeżeli czas graniczny minął oraz nie ma
wszystkich sygnałów "gotów", to koordynator wysyła do wszystkich
serwerów sygnał "zerwij".
• Sposób rejestracji sygnałów od koordynatora w dzienniku serwera. W razie
awarii serwera, po jego ponownym postawieniu, analizowany jest dziennik
celem stwierdzenia, czy transakcja ma być potwierdzona, czy zerwana.
 Problem blokowania: w razie awarii koordynatora wszystkie transakcje na
serwerach, które zgłosiły "gotów" są przyblokowane. Serwery "nie
wiedzą", co dalej robić. Postawienie koordynatora może trwać długo.
 Bardziej złożony protokół 3PC uwzględnia awarie koordynatora .
 3PC nie znalazł jednak szerszego zastosowania ze względu na duże
narzuty na wydajność aplikacji.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 106
marzec 2002
Transakcje w federacyjnej bazie danych (1)
 Lokalne transakcje są wykonywane autonomicznie przez lokalny
SZBD. Federacja nic o nich nie wie i (z reguły) nie może się
dowiedzieć.
 Globalne transakcje są wykonywane przez aplikacje globalne.
Mogą składać się z wielu podtransakcji, wykonywanych przez
lokalne SZBD.
 Z punktu widzenia lokalnego SZBD podtransakcja globalnej
transakcji jest normalną lokalną transakcją.
 W związku z tym, zapewnienie szeregowalności globalnych
transakcji (niezbędny warunek dla utrzymania spójności
przetwarzania) w FBD jest trudne lub wręcz niemożliwe.
 Dlaczego? - następny slajd.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 107
marzec 2002
Transakcje w federacyjnej bazie danych (2)
 Lokalne bazy danych mogą stosować różnorodne algorytmy
przetwarzania transakcji. Autonomia oznacza, że federacja nie ma wpływu
na te algorytmy.
 Lokalna BD może w każdej chwili z różnych powodów (np.
zakleszczenia) zerwać dowolną transakcję, w tym podtransakcję
indukowaną przez globalną transakcję.
 Informacja o wewnętrznym stanie lokalnie przetwarzanych transakcji (np.
stan dziennika transakcji, zamki zakładane przez transakcje, itd.) nie jest
widoczna na zewnątrz.
 Stosowanie typowych algorytmów, np. 2PC (two phase commit) jest
niemożliwe, gdyż lokalna BD może nie posiadać możliwości zawieszenia
podtransakcji w stanie “gotowa” i czekać na sygnał potwierdź ze strony
globalnej transakcji.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 108
marzec 2002
Wykład 4
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 109
marzec 2002
Niezgodności schematów i ontologii
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 110
marzec 2002
Niezgodności schematów schematic discrepancies
Przy integracji niezależnie zaprojektowanych baz danych w jeden schemat należy się
liczyć z tym, że organizacja, struktura i semantyka danych będzie niezgodna.
Nie istnieje ani “jeden” ani “najlepszy” sposób odwzorowania dziedziny
przedmiotowej w struktury danych zapamiętane w bazie danych. Różni projektanci
projektują całkowicie odmienne struktury dla tego samego problemu.
Dlaczego?
 Obiekty tej samej dziedziny problemowej mogą być widziane przez różnych
projektantów całkowicie odmiennie.
 Systemy zarządzenia BD mają ograniczenia struktur danych, które wymuszają
sposób myślenia projektantów nad koncepcją struktur danych.
 Różne środki manipulacji strukturami dostarczane przez SZBD wymuszają często
różną koncepcję.
 Projektanci podejmują różnorodne decyzje co do koncepcji struktur danych w
związku z zamierzonymi własnościami użytkowymi, np. szybkością dostępu.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 111
marzec 2002
Niezgodności ontologii w rozproszonych BD
(1)
Są one poważną przeszkodą, która pojawia się podczas konstruowania
federacyjnych rozproszonych BD.
Niezgodności te dotyczą różnych aspektów organizacji i działania:
 Niezgodności pomiędzy modelami danych: relacyjna vs. obiektowa vs.
hierarchiczna XML-owa, itd.
 Niezgodności pomiędzy schematami pojęciowymi. Np. w jednej BD informacja
o dzieciach pracownika jest atrybutem jego obiektu, zaś w innej jest związkiem
łączącym obiekt pracownika z obiektami osób. W zależności od BD te same dane
mogą występować raz jako nazwy (obiektów, atrybutów), a raz jako ich wartości.
Nawet gdy zespoły stosują tę samą metodykę projektowania, to na ogół ich
projekty pojęciowe są zasadniczo różne.
 Niezgodności pomiędzy schematami logicznymi. Można oczekiwać, że w
niezależnie zbudowanych bazach danych nazwy obiektów, nazwy atrybutów oraz
ich zestaw będą inne. Mogą występować poważniejsze różnice w zakresie
organizacji logicznej; np. w pewnej lokalnej bazie danych informacja o
pracownikach może być rozbita na dwie lub więcej tablic.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 112
marzec 2002
Niezgodności ontologii w rozproszonych BD
(2)
 Niezgodności w zakresie interpretacji semantycznej danych. W jednej
bazie danych zarobek pracownika może być zarobkiem brutto, w innej netto, zaś jeszcze w innej może być rozbity na pensję, premię i dodatki.
 Niezgodności dotyczące budowy i środków dostępu do katalogów. W
relacyjnej BD katalog jest zbiorem relacji dostępnym przy pomocy SQL,
w innej bazie katalog może nie istnieć explicite, zaś informacje
katalogowe są dostępne poprzez zmienne środowiskowe oraz specjalne
procedury i funkcje.
 Niezgodności dotyczące reprezentacji danych. W jednej BD informacja
o zawodzie pracownika jest przechowywana na przykład w postaci ciągu
znaków, a w innej przy pomocy numeru zawodu i specjalności, którym
towarzyszy tabela umożliwiająca interpretację (niekoniecznie
przechowywana w BD). Mogą występować różnice w reprezentacji dat,
czasu i innych atrybutów, różnice w zakresie precyzji reprezentacji
wielkości liczbowych oraz zarezerwowanych długości obszarów dla
wartości znakowych, itp.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 113
marzec 2002
Niezgodności ontologii w rozproszonych BD
(3)
 Niezgodności dotyczące odniesienia danych do skali czasowej.
Informacje mogą być np. aktualizowane natychmiast, zaś w innej BD raz
na miesiąc.
 Niezgodności w sposobach dostępu. W jednej BD dostęp do danych
będzie realizowany na przykład przy pomocy standardowego SQL, a w
innej poprzez środki dostępu pewnego języka czwartej generacji lub API.
 Różna strukturalizacja informacji. Np. w jednej BD utworzono odrębną
tabelę PrzynależnośćDoZwiązkuZawodowego, zaś w innej ta
przynależność jest atrybutem tabeli Pracownik; w jednej BD atrybut Adres
jest polem tekstowym, w innej zaś strukturą z polami Miejscowość, Ulica,
NrDomu, itd.
 Podział danych i metadane. Np. w jednej BD atrybut Zawód tabeli
Pracownicy jest stringiem, zaś w innej utworzono odrębne tabele.
Piekarze, Stolarze, itd.
Niezgodności jest bardzo dużo. Niezależnie zbudowane lokalne bazy
danych zawsze będą obciążone tego rodzaju konfliktami.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 114
marzec 2002
Kanoniczny model danych
canonical data model
Jeżeli wiele baz danych ma tworzyć jedną federacyjną bazę danych w której
będzie obowiązywać jeden wspólny API f, wówczas potrzebny jest model
danych w terminach którego dadzą się wyrazić wszystkie inne modele danych.
Model powinien także uwzględniać fakt, że w federacji mogą pojawić się nowe
bazy danych, których założeń nie rozpatrywaliśmy podczas jej tworzenia.
Który z modeli danych mógłby być takim kanonicznym modelem danych?
Relacyjny? Encja-związek? UML? CORBA? ODMG? Jakiś inny?
Jeżeli nie chcemy debaty religijnej o wyższości modelu A nad B, to powstaje
pytanie o obiektywne kryteria. Czy istnieją?
Debata nad kanonicznym modelem danych traktuje modele danych jako
obiektywne byty o ostro zarysowanych własnościach i granicach.
Nie jest to słuszne. Modele danych są tworami subiektywnymi, o niejasnych
granicach, podlegają ciągłej ewolucji, możliwe są różnorodne ich mutacje i
rozszerzenia. Istnieje potencjalnie wiele modeli relacyjnych i wiele modeli
obiektowych.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 115
marzec 2002
Kryteria wyboru kanonicznego modelu danych
Ekspresyjność (expressiveness): w jakim stopniu dany model jest w stanie
bezpośrednio odwzorować pojęcia z modelu pojęciowego dziedziny
aplikacyjnej oraz definiować nowe operacje, typy danych i więzy integralności.
Np. model relacyjny nie ma bezpośrednich odwzorowań złożonych obiektów,
dziedziczenia, agregacji, informacji behawioralnych, itd., wobec czego ma
niską ekspresyjność. Pod tym względem model obiektowy ma przewagę.
Relatywizm semantyczny (semantic relativism): stopień, w jakim dany model
umożliwia wiele punktów widzenia na tę samą dziedzinę aplikacyjną. Miarą
relatywizmu semantycznego danego modelu jest możliwość budowania
dowolnych schematów zewnętrznych (perspektyw) nad schematem bazy
danych. Model relacyjny posiada pewien stopień relatywizmu, dzięki jego
zdolności definiowania perspektyw (ograniczonej, szczególnie w zakresie
aktualizacji perspektyw). Definiowanie perspektyw nie jest mocną stroną
systemów obiektowych, jakkolwiek nie istnieją tu ograniczenia koncepcyjne.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 116
marzec 2002
Federacyjne bazy danych
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 117
marzec 2002
Co to jest Federacyjna Baza Danych?
Federated Database
Jest to kolekcja heterogenicznych, autonomicznych baz danych, połączonych
siecią komputerową, zarządzana specjalnym systemem określanym jako
Federacyjny System Zarządzania Bazą Danych (FSZBD). Może włączać
dziesiątki, setki, tysiące lub więcej lokalnych baz danych.
FSZBD umożliwia tworzenie aplikacji globalnych, działających na całości
federacyjnej bazy danych. Jest ona zdefiniowana schematem federacyjnym,
będącym sumą schematów eksportowych lokalnych baz danych.
FSZBD zapewnia warunki pracy twórców aplikacji globalnych określane jako
przezroczystość i niezależność danych.
FSZBD może być zainstalowany w wielu węzłach sieci (m.in. w każdym
lokalnym miejscu FBD), umożliwiając tworzenie aplikacji globalnych w wielu
miejscach geograficznych. Poszczególne FSZBD współpracują ze sobą celem
zapewnienia spójności i integralności przetwarzania.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 118
marzec 2002
Architektura federacyjnej bazy danych
Aplikacje globalne
FSZBD
1
Przestrzeń
robocza
Aplikacje globalne
...
Schemat FBD
FSZBD
m
Przestrzeń
robocza
Schemat FBD
Sieć
komputerowa
Schemat eksportowy 1
Osłona 1
API 1
Lokalny
SZBD 1
BD 1
Aplikacje lokalne
Schemat eksportowy 2
Osłona 2
API 2
Lokalny
SZBD 2
BD 2
Aplikacje lokalne
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 119
...
Schemat eksportowy n
Osłona n
API n
Lokalny
SZBD n
BD n
Aplikacje lokalne
marzec 2002
Global
schema do lokalnej
External BD
sub-schemata
Architektura
dostępu
(in an extended ODL)
(through an accessibility matrix)
Lokalna baza danych
Lokalny schemat
eksportowy
Zewnętrzne podschematy
użytkowników (macierz dostępu)
Zewnętrzny
podschemat 1
Zewnętrzny
podschemat 2
Zewnętrzny
podschemat 3
Interfejs IA1
Dostęp
Zakaz
Zakaz
Interfejs IA2
Zakaz
Zakaz
Dostęp
Dostęp
Zakaz
Dostęp
Interfejs IC1
Zakaz
Dostęp
Zakaz
Ob.wirt.
VV3
Ob.wirt.
3V
Dane wirt.
1
Perspektywa V1
Zakaz
Dostęp
Dostęp
Ob.wirt.
VV3
Ob.wirt.
3V
Dane wirt.
2
Perspektywa V2
Dostęp
Zakaz
Zakaz
Obiekty A
Obiekty A
Obiekty
Dane B A
Obiekty
Dane C A
API
Osłona
Mediator
Obiekty A
Obiekty A
Obiekty
Dane A A
Interfejs IB1
definiuje
Administrator
lokalnej bazy danych
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 120
Użytkownik Użytkownik
1
2
Użytkownik
3
marzec 2002
3-warstwowa architektura federacyjnej BD
3
Użytkownik 1
Użytkownik 2
Użytkownik 3
Schemat zewnętrzny 1
Schemat zewnętrzny 2
Schemat zewnętrzny 3
Schemat federacyjny
2
FSZBD
Przestrzeń
robocza
Sieć
1
Schemat eksportowy 1
Osłona 1
API 1
Lokalny
SZBD 1
BD 1
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 121
Schemat eksportowy 2
Osłona 2
API 2
Lokalny
SZBD 2
...
BD 2
marzec 2002
Przetwarzanie zapytań w FBD
Podstawowe algorytmy przetwarzania zapytań w homogenicznych i federacyjnych
relacyjnych BD są podobne. Różnice dotyczą cech autonomii i heterogeniczności,
które znacznie komplikują problem. Algorytmy polegają na dekompozycji zapytania
na pewne podzapytania kierowane do lokalnych BD, następnie na skomponowaniu
globalnego wyniku z wyników cząstkowych zwróconych przez lokalne BD.
Komplikacje
• Niezgodności schematów, które wymagają mechanizmu refleksji lub nowych
operatorów w SQL.
• Brak algorytmicznej uniwersalności SQL.
• Ograniczona moc mechanizmu definiowania perspektyw.
Problem został rozwiązany dla niektórych przypadków, ale nie dla generalnego.
Wygląda na to, ze w ramach obecnych paradygmatów modelu relacyjnego niewiele
więcej da się zrobić.
W obiektowych bazach danych problem jest na początku drogi. Nie są mi znane
istotne prace, które dałyby nadzieję na rozwiązanie. Przymiarki, spekulacje,...
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 122
marzec 2002
Rozproszone BD w standardzie CORBA
Oprogramowanie komponentowe budowane wg standardu CORBA może być
podstawą rozproszonych/federacyjnych baz danych.
Host globalnej aplikacji
Host lokalnej BD
Obiekty
Obiekty
Obiekty
Klient
Wywołanie
operacji
Pieniek
klienta
zlecenie
Implementacja
interfejsów do
obiektów
(szkielety + kod)
Pośrednik (ORB, Object Request Broker)
wynik, parametry wyj
Implementacja interfejsów do obiektów po stronie serwera powstaje ze szkieletu
automatycznie generowanego z wyrażenia IDL, który jest wypełniany kodem operacji.
Taki szkielet pełni jednocześnie funkcję osłony oraz funkcję perspektywy. ORB jest w
stanie zapewnić autonomię lokalnej BD.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 123
marzec 2002
Problemy z RBD w standardzie CORBA
 CORBA nie jest nastawiona na przetwarzanie danych trwałych i
masowych przy pomocy języków zapytań. Jest to poziom języków takich
jak C++ i Java, znacznie niższy. Obecny stan standardyzacji w zakresie
Query Service i Persistence Service jest uważany za niezadowalający.
 CORBA nie wprowadza pojęcia perspektywy. Osłony w CORBA są
pisane w językach niskiego poziomu, są zorientowane na daną aplikację,
nie dają konceptualizacji takiej, jaką dają perspektywy.
 Mogą być znaczne narzuty na wydajność maszynową i produktywność
programistów globalnych aplikacji.
 CORBA nie rozwiązuje problemów związanych z przetwarzaniem
transakcji w rozproszonych/federacyjnych bazach danych.
 Model obiektowy CORBA jest ograniczony, m.in. nie uwzględnia
związków i zagnieżdżonych kolekcji. Te możliwości są uwzględniane w
usługach (np. Relationship Service), które nie są realizowane.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 124
marzec 2002
Osłony i mediatory
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 125
marzec 2002
Osłona
wrapper
Moduł oprogramowania umożliwiający przystosowanie
interfejsu lokalnej bazy danych do pewnego standardu
obowiązującego w systemie rozproszonym.
Podstawowe zadanie: fizyczne połączenie różnych baz danych.
 Osłona nie zajmuje się bardziej wyrafinowanym odwzorowaniem;
chodzi o translację danych, parametrów i wywołań funkcji
płynących z zewnątrz lokalnego systemu (o specyficznych
formatach i reprezentacji) na analogiczne dane, parametry i funkcje
wyrażone w API konkretnego lokalnego systemu bazy danych.
 Dla niektórych przypadków, np. dla niektórych stron HTML,
napisanie osłony jest bardzo trudnym zadaniem ze względu na
nieregularności formatu (dane pół-strukturalne, semi-structured).
 Osłona jest niezbędna do tego, aby budować bardziej
wyrafinowane środki odwzorowania schematów i aplikacji, takie jak
mediatory i perspektywy
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 126
marzec 2002
Osłony w federacyjnych BD
Osłona udostępnia dane i usługi lokalnego systemu i (dostępne w pewnym API i)
dla aplikacji globalnych (wykorzystujących wspólny API f).
Osłony przystosowują lokalne
obowiązującego w federacji.
SZBD
do
interfejsu
programistycznego
Federacyjny
SZBD
API f
API f
Osłona 1
Osłona 2
API 1
Lokalny
SZBD 1
API 2
Lokalny
SZBD 2
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 127
API f
...
Osłona n
API n
Lokalny
SZBD n
marzec 2002
Osłony dla lokalnych relacyjnych SZBD
Problem pojawia się wtedy, gdy API f dla federacyjnej bazy danych nie jest
oparty o model relacyjny, lecz o model obiektowy a la CORBA lub ODMG.
Potencjalne problemy i rozwiązania:
 Konieczność silnego ograniczenia modelu obiektowego, np. brak
złożonych obiektów, metod, związków, hermetyzacji, polimorfizmu, itd.;
 Odwzorowanie krotek tabel na złożone obiekty - wiele krotek
składających się na jeden obiekt. Przetwarzanie np. w OQL+Java.
Problemy koncepcyjne.
 Odwzorowanie obiektowego API, np. OQL +Java na relacyjne API, np.
JDBC. Ogólne rozwiązanie jest bardzo trudne.
 Zredukowanie API relacyjnej BD do prymitywnych operacji (get first, get
next,...), dzięki czemu relacyjną bazę danych można będzie potraktować
jako prymitywną obiektową bazę danych. Następnie, zdefiniowanie
obiektowych, wirtualnych, aktualizowalnych perspektyw.
Problemy koncepcyjne. Problemy z wydajnością.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 128
marzec 2002
Mediatory
mediator
Warstwa pośrednia pomiędzy lokalną bazą danych a globalnymi aplikacjami.
Jest konieczny wtedy, gdy nie ma odwzorowania 1:1 pomiędzy ontologiami.
Np. w jednej bazie podany jest zarobek brutto z ubezpieczeniem, w innej
zarobek brutto bez ubezpieczenia. Jak to sprowadzić do wspólnego
mianownika?
Zadania
mediatora:rozbieżności pomiędzy schematem lokalnym a schematem
 Rozstrzyganie
federacyjnym.
 Wspomaganie dla wyłowienia cech formalnych z danych
niesformatowanych.
 Selekcja właściwej informacji.
 Wspomaganie dla informacji sumarycznych, wyliczalnych oraz o
większym stopniu abstrakcji.
 Wspomaganie dla wykrywania niezidentyfikowanych związków w danych
(eksploracja danych).
Zasady konstrukcji mediatorów nie są jasne. W większości przypadków mediator musi
być zaprojektowany ad hoc, pisany techniką niskiego poziomu i przypisany do
konkretnej aplikacji (nie uniwersalny).
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 129
marzec 2002
Perspektywy
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 130
marzec 2002
Perspektywy
view, database view
Perspektywa (view) jest to odwzorowanie schematu lokalnego w inny
(zmodyfikowany) schemat. Temu odwzorowaniu towarzyszy
odwzorowanie danych rzeczywistych lokalnej bazy danych na dane
wirtualne lub dane zmaterializowane (wyliczone). Przykładem są
perspektywy w SQL.
Podstawowe
problemy:
 W przypadku istotnych różnic pomiędzy schematami lokalnymi baz
danych, odwzorowanie ich w zadany schemat może być złożone lub
niemożliwe. Środki definiowania perspektyw np. w SQL są za mało
uniwersalne.
 Aktualizacja perspektyw (view updating): problem nie jest rozwiązany w
stopniu zadowalającym.
 Aplikacje (np. w C++) są często przywiązane do fizycznej postaci danych.
Odwzorowanie ich w dane wirtualne powoduje, że większość aplikacji
przestaje działać. Ograniczenie do zapytań (np. w SQL) silnie redukuje
rodzaj aplikacji, które mogą działać na schemacie federacyjnym.
 Wydajność (performance) aplikacji.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 131
marzec 2002
Perspektywa jak schemat zewnętrzny
W szerokim znaczeniu:
Perspektywą nazywa się odwzorowanie globalnego schematu bazy danych
(określającego zapamiętane zasoby danych) na schemat “zewnętrzny”,
przystosowany do potrzeb i przyzwyczajeń konkretnego użytkownika.
Architektura
ANSI/SPARC:
Użytkownik 1
Użytkownik 2
Użytkownik 3
Schematy
“zewnętrzne”
Perspektywa 1
W tym sensie
pojęcie perspektywy
funkcjonuje w literaturze z
zakresu modeli danych,
analizy i projektowania.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 132
Perspektywa 2
Schemat globalny
Poziom fizyczny
bazy danych
Perspektywa 3
Projektant BD
Administrator BD
Administrator BD
marzec 2002
Perspektywa jako odwzorowanie
W węższym znaczeniu:
Perspektywą określa się nazwane odwzorowanie danych zapamiętanych w
bazie danych na dane “wirtualne”, t.j. pochodne lub wyliczalne.
Matematycznie, perspektywa jest dowolną funkcją określoną na danych.
Ten punkt widzenia nie jest jednak dostatecznie precyzyjny, gdyż nie uwzględnia
mechanizmów nazywania (naming), wiązania (binding) i zakresu (scoping), które są
kluczowe, szczególnie w przypadku obiektowości z hierarchią klas, tożsamością
obiektów, hermetyzacją i innymi pojęciami.
Bardziej precyzyjny punkt widzenia:
Perspektywa jest procedurą funkcyjną, która (najczęściej, ale niekoniecznie)
zwraca wynik będący daną typu masowego (zbiór, wielozbiór, sekwencję). Taki
wynik powinien być wyposażony w dodatkowe nazwy (np. nazwy atrybutów
wirtualnych obiektów zwracanych przez perspektywę).
Perspektywy znane z SQL mieszczą się w tej definicji. Są to uproszczone procedury
funkcyjne, których ciało można sprowadzić do pojedynczego zdania:
return <zapytanie SQL>
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 133
marzec 2002
Po co są perspektywy?
Istnieje wiele ważnych zastosowań perspektyw, które czynią z nich
bardzo gorący i aktualny temat.
 Uproszczenie modeli pojęciowych dla poszczególnych użytkowników.
 Uproszczenie zapytań poprzez “wyliczane” obiekty, atrybuty, związki.
 Dostosowanie się do punktu widzenia i terminologii dziedziny zastosowań
 Ograniczenie dostępu do obiektów, ochrona prywatności.
 Ograniczenie dostępu w systemach rozproszonych federacyjnych baz
danych.
 Logiczna niezależność obiektów i aplikacji działający na obiektach.
 Współdziałanie systemów heterogenicznych (wspólny schemat).
 Przystosowanie systemów spadkowych (legacy) do nowszych
technologii i wymagań.
 Hurtownie danych: analiza informacji gromadzonych z różnych źródeł.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 134
marzec 2002
Jak są widziane perspektywy w relacyjnych BD?
Perspektywę wyznacza zapytanie, np. w SQL, plus drugorzędne środki
syntaktyczne i semantyczne, takie jak zmiana nazw kolumn wirtualnych tablic.
Po ewaluacji perspektywa zwraca tablicę, koncepcyjnie taka samą jak
zapamiętane tablice.
Popularną i efektywną techniką przetwarzania perspektyw jest nie ich ewaluacja
(materializacja), lecz modyfikacja zapytań, traktująca perspektywę jako makrodefinicję, oraz łączna optymalizacja tekstu zapytania z rozwiniętym tekstem
definicji perspektywy.
Aktualizacja perspektyw jest ograniczona do pionowego/poziomego obcięcia
zapamiętanych tablic. Nie występują i nie są dyskutowane środki sterowania
intencją aktualizacji perspektywy.
Aktualizacja perspektyw odbywa się w tym samym języku, co ich definicja
(SQL); nie jest rozważana (chociaż być może osiągalna) aktualizacja perspektyw
z języków niższego poziomu (np. z C).
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 135
marzec 2002
Perspektywy w relacyjnych bazach danych
Perspektywę określa pewne zapytanie, np. SQL.
Zdanie definiujące perspektywę określa nazwy atrybutów “wirtualnej tabeli”.
Zapamiętana tabela:
Pracownicy( Id_pracownika, Imię, Nazwisko, Stanowisko, Kierownik,
Data_zatrudnienia, Zarobki, Premia, Id_działu )
Definicja perspektywy:
CREATE VIEW Urzędnicy( Id_pracownika, Imię, Nazwisko, Zarobki )
AS
SELECT Id_pracownika, Imię, Nazwisko, Zarobki FROM Pracownicy
WHERE Stanowisko = ‘urzędnik’;
Użycie perspektywy:
(Zarobki urzędnika o nazwisku Nowak: )
SELECT Zarobki FROM Urzędnicy
WHERE Nazwisko = ‘Nowak’
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 136
Perspektywy wolno użyć w
zdaniach SQL (prawie) na
takich samych zasadach jak
zapamiętanej tabeli.
marzec 2002
Relacyjna baza danych z perspektywami
Użytkownik lub
program aplikacyjny
SQL
Dane wirtualne
Dane rzeczywiste
(logiczne)
Perspektywa
V1
Tablica BD
B1
Tablica BD
B2
Perspektywa
V2
Tablica BD
B3
Tablica BD
B4
Dane zapamiętane
(fizyczne)
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 137
marzec 2002
Przykład relacyjnej bazy danych
DC
DOSTAWCA
DNR NAZW
D1
D2
D3
D4
D5
DNR CNR ILOŚĆ
STATUS MIASTO
Abacki
Bober
Czerny
Dąbek
Erbel
20
10
30
20
30
Lublin
Poznań
Poznań
Lublin
Radom
CZĘŚĆ
CNR NAZWAC
C1
C2
C3
C4
C5
C6
Nakrętka
Wkręt
Podkładka
Nit
Nit
Tulejka
KOLOR
WAGA MIASTO
Czarwony
Zielony
Niebieski
Czerwony
Niebieski
Czerwony
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 138
12
17
17
14
12
19
Lublin
Poznań
Rzeszów
Lublin
Poznań
Lublin
D1
D1
D1
D1
D1
D1
D2
D2
D3
D4
D4
D4
C1
C2
C3
C4
C5
C6
C1
C2
C2
C2
C4
C5
300
200
400
200
100
100
300
400
200
200
300
400
marzec 2002
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:
DROP VIEW DobryDostawca;
- usunięcie perspektywy z bazy danych.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 139
DobryDostawca
DNR nazwisko status suma
D1 Abacki
D2 Bober
D4 Dąbek
20 1300
10 700
20 900
marzec 2002
Perspektywy wirtualne
 Perspektywa istnieje wyłącznie w postaci definicji (np.
zapytania, procedury funkc.).
 Wyliczenie (materializacja) następuje w momencie użycia
perspektywy.
 Wynik jest “konsumowany” i następnie kasowany (tak jak wynik
procedury funkcyjnej) .
 Zalety: nie ma dublowania danych, problemów aktualizacji
wyliczonych danych, problemów z przetwarzaniem transakcji.
 Wada: czas ewaluacji perspektyw+czas ewaluacji zapytań
używających perspektyw - bez optymalizacji jest bardzo często
nieakceptowalny.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 140
marzec 2002
Perspektywy zmaterializowane
 Perspektywa jest wyliczona “na zapas”, jej wynik jest
przechowywany w bazie danych na normalnych zasadach.
Aktualizacja danych stanowiących podstawę wyliczenia pociąga
za sobą aktualizację zmaterializowanej perspektywy (lub jej
skasowanie i ewentualnie, ponowne wyliczenie).
 Tego rodzaju perspektywy określa się także jako “zdjęcie
migawkowe” (snapshot).
 Zalety: szybki dostęp, łatwa implementacja.
 Wady: dodatkowe zapotrzebowanie na pamięć, dodatkowy koszt
aktualizacji zmaterializowanych perspektyw (często prowadzący do
problemów koncepcyjnych i realizacyjnych), dodatkowe wąskie
gardło dla transakcji.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 141
marzec 2002
Zasada przezroczystości perspektyw
view transparency
Z punkty widzenia użytkownika dowolne operacje na perspektywach nie
powinny niczym różnić się od podobnych operacji na zapamiętanych danych.
Np. jeżeli w federacyjnej bazie danych administrator udostępnia tylko część
danych poprzez perspektywę, wówczas programista końcowy nie powinien
być zmuszany do modyfikacji programów działających na zapamiętanych
danych z tego powodu, że mają one teraz działać na perspektywach.
Warunek przezroczystości perspektyw jest trudny, gdyż:
 Dla pewnych odwzorowań danych zapamiętanych w wirtualne przyjęte środki
definicji perspektyw (np. SQL) mogą okazać się niewystarczające (schematic
discrepancies).
 Problem aktualizacji perspektyw pozostaje nierozwiązany.
 Pewne dane mogą być manipulowane wyłącznie przez przypisane im
interfejsy, a nie przez języki zapytań.
 Problemy z wydajnością mogą unicestwić rozwiązania trzech poprzednich
problemów.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 142
marzec 2002
Wykład 5
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 143
marzec 2002
Aktualizacja perspektyw
Najpoważniejszym, nierozwiązanym problemem jest aktualizacja perspektyw.
Aktualizacja „wirtualnych” danych jest oczywiście niemożliwa, wobec czego należy
zamienić tę aktualizację na aktualizację zapamiętanych danych.
Aktualizacja
Dane wirtualne
Perspektyw
a
Baza danych
Dane zapamiętane
Na ogół odwzorowanie danych wirtualnych w dane zapamiętane nie jest
jednoznaczne. Odwzorowanie aktualizacji danych wirtualnych w aktualizacje
danych zapamiętanych można zrobić na wiele sposobów. Czasami takie
odwzorowanie odwrotne w ogóle nie istnieje.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 144
marzec 2002
Przykład aktualizacji perspektyw (1)
Dane rzeczywiste
Dane wirtualne
Pracownik
Dział zatrudnia
Nazwisko
*
Nazwa
Zarobek
/MojeDziały
Nazwa
ŚredniZarobek
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.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 145
marzec 2002
Przykład aktualizacji perspektyw (2)
Dane rzeczywiste
zatrudnia Pracownik
Dział
* Nazwisko
szef
Nazwa
Zarobek
0..1
Dane wirtualne
/MoiPracownicy
Nazwisko
NazwiskoSzefa
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.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 146
marzec 2002
Ograniczenia w aktualizacji perspektyw
System Oracle:
W klauzuli SELECT nie ma słowa DISTINCT
W klauzuli FROM jest tylko jedna nazwa tabeli lub tylko jedna nazwa tabeli lub aktualizowalnej perspektywy
Na liście SELECT (wynikowej) znajduja się tylko nazwy kolumn
W klauzuli WHERE nie ma podzapytania
W zapytaniu nie mogą występować klauzule GROUP BY i HAVING
Ta lista powinna być uzupełniona o ważny warunek: mianowicie, wynikowa
wirtualna tablica powinna posiadać pełny klucz główny (primary key) pewnej
zapamiętanej tablicy. Warunek ten (Ch.Date) jest logiczną konsekwencją tego,
że identyfikacja zapamiętanej krotki następuje wyłącznie na podstawie wartości
klucza głównego. W istocie jednak, systemy relacyjne odeszły od filozofii
“klucza głównego” na rzecz “wewnętrznego identyfikatora krotki”, w związku z
czym ten warunek okazał się zbędny.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 147
marzec 2002
Dodatkowe możliwości aktualizacji perspektyw
W Oracle można aktualizować perspektywy powstające w wyniku złączenia, ale
tylko atrybuty relacji znajdujące się po stronie “klucza obcego”:
CREATE VIEW 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.
Przenieść programistę Nowaka
do działu Lalek Barbie:
UPDATE MoiLudzie
SET NazwaDziału = ‘Lalki Barbie’
WHERE Nazwisko = ‘Nowak’
Źle!
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 148
marzec 2002
Perspektywy są trudnym problemem
 Perspektywy są problemem, który doczekał się efektywnych
rozwiązań w relacyjnych bazach danych.
 Podstawowy problem - aktualizacja wirtualnych danych - nie został
rozwiązany w stopniu zadowalającym.
 Środki definicji perspektyw w relacyjnych bazach danych są ograniczone.
 Implementacje perspektyw nie zakładają sterowania intencją aktualizacji.
Powoduje to, że wszelkie zapowiedzi opanowania poprzez perspektywy
problemów takich jak współdziałanie (interoperability), przenaszalność
(portability), ewolucja schematu (schema evolution), itp., są pobożnym
życzeniem. Dotyczy to szczególnie kolejnych prac na temat obiektowych
perspektyw relacyjnych baz danych.
 W powszechnej opinii, problem aktualizacji wirtualnych perspektyw jest
uważany za bardzo trudny.
 Rośnie liczba prac nt. zmaterializowanych perspektyw, gdzie problem jest
koncepcyjnie prostszy. Tych dwóch tematów nie należy mylić.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 149
marzec 2002
Klasyfikacja złożoności perspektyw
 Proste perspektywy, np. definiowane poprzez operatory selekcji i projekcji w
relacyjnych BD. Mała przydatność dla federacyjnych baz danych.
 Perspektywy bardziej złożone, np. wymagające złączeń i grupowania, ale
wyrażalne w SQL i OQL. Problemy z aktualizacją perspektyw i wydajnością.
 Perspektywy umożliwiające zmianę reprezentacji danych.
 Perspektywy uwzględniające niezgodności schematów, np. zamieniające atrybut
Zawód z wartościami “piekarz”, “stolarz” itd. na wirtualne tabele Piekarz,
Stolarz, itd. Wymagają dostępu do metabazy i mechanizmu refleksji (reflection).
 Perspektywy uwzględniające niezgodności semantyczne pomiędzy danymi.
Często nie ma możliwości odzyskania informacji, która pozwoliłaby usunąć te
niezgodności. Konieczne jest wtedy zrezygnowanie z pełnej przezroczystości.
 Perspektywy z (trwałym) stanem, o pełnej mocy algorytmicznej. Wydajność?
Pozostałe kryteria klasyfikacyjne: generyczność, moc, stopień uwzględnienia pojęć
modelu obiektowego, perspektywy rekurencyjne, perspektywy z parametrami,
możliwości aktualizacji perspektyw, możliwości optymalizacji, itd.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 150
marzec 2002
Kryteria aktualizowalności perspektyw
 Brak nadmiarowej akualizacji. Jeżeli użytkownik aktualizuje pewien element
perspektywy, nie powinien bezwiednie powodować aktualizacji innego jej elementu.
 Brak niedostatecznej/błędnej aktualizacji - wynik aktualizacji nie powinien
odbiegać od intencji użytkownika. Np. użytkownik aktualizuje zarobek netto o 100 zł,
tymczasem okazuje się, ze faktyczna aktualizacja wyniosła 91,50 zł.
 Brak efektów ubocznych aktualizacji. Np. takim efektem jest zniknięcie krotki z
perspektywy 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ę.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 151
marzec 2002
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.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 152
marzec 2002
Aktualizacja perspektyw w relacyjnych BD
 Duża liczba artykułów, głównie teoretycznych, ale (poza opisanymi
praktycznymi rozwiązaniami) rezultaty tego nurtu są gorzej niż mizerne.
• Artykuły zakładają jakiś "automagiczny" sposób aktualizacji perspektyw, bez
sterowania intencją aktualizacji.
• Środki formalne modelu relacyjnego (algebra relacji i inne) są
nieprzystosowane do operacji imperatywnych takich jak aktualizacja.
• Model relacyjny nie zaoferował dostatecznie uniwersalnego formalizmu do opisu
konstrukcji imperatywnych, procedur, metod, itd.
• W ten sposób zmarnowano masę czasu, wysiłku i papieru.
• Przede wszystkim, zmarnowano czas czytelników.
 Prosty pomysł polega na przyjęciu założenia, że sterowanie intencją
aktualizacji perspektywy powinno być:
• składową definicji perspektywy,
• znajdować się w rękach definiującego perspektywę,
• zakładać imperatywny język (programowania) jako środek określania tej
intencji.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 153
marzec 2002
Perspektywy ze stanem
capacity augmenting views, stateful views
Klasyczne perspektywy udostępniają (w inny sposób) informacje, która już są
zapamiętane w bazie danych. Często takie ograniczenie jest nieakceptowalne.
Lokalna BD zawiera atrybut “stanowisko”, którego wartością są numery 11,
Przykład 45, 77, itd., gdzie 11 oznacza projektant, 45 oznacza analityk, 77 oznacza
sprzątaczka, itd. Federacja wymaga pełnych nazw zawodów. Potrzebna jest
1:
dodatkowa funkcja, która zamieni numery na stringi. Definicja perspektywy
musi więc zawierać definicję trwałej tabeli z numerami i stringami.
Przykład
2:
Dla celów kontroli utworzona jest perspektywa w postaci tabeli
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.
Perspektywy ze stanem (oraz autonomia lokalnych BD) oznaczają konieczność
wprowadzenia na poziomie federacji specjalnej BD przechowującej dane niezbędne
do definicji perspektywy. Komplikuje to architekturę federacyjnej bazy danych.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 154
marzec 2002
Przetwarzanie perspektyw w zapytaniach
Obowiązują dwie strategie:
Materializacja. Perspektywa jest całkowicie liczona w momencie, kiedy sterowanie
programu/zapytania osiągnie punkt, w którym wynik tej perspektywy staje się niezbędny
dla dalszego przetwarzania. Każde odwołanie się do perspektywy powoduje jej ponowne
wyliczenie (dla uniknięcia niespójności związanych z ewentualną aktualizacją BD). Ta
strategia może być optymalizowana poprzez zmaterializowane perspektywy.
Modyfikacja zapytań (query modyfication). Tekst zapytania, w którym występuje
odwołanie do perspektywy, jest scalany z tekstem definicji perspektywy. Następnie takie
rozwinięte zapytanie jest wspólnie optymalizowane na normalnych zasadach. W tej
strategii definicja perspektywy jest traktowana jako makro.
Ponieważ wcześniejszy SQL nie dopuszczał klauzuli SELECT wewnątrz klauzuli FROM,
kwestia banalnego tekstowego zastępowania przybrała cudaczne formy, owocując w
super-naukowe “algorytmy” :-) (Stonebraker et al). W SQL-92 tę wadę usunięto.
W różnych sytuacjach pierwsza lub druga strategia może być bardziej optymalna, ale
najczęściej strategia modyfikacji zapytań jest bardziej skuteczna. Z tego powodu jest
ona standardem we wszystkich relacyjnych SZBD.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 155
marzec 2002
Przykład modyfikacji i optymalizacji zapytania
Definicja
perspektywy:
CREATE VIEW Urzędnicy( Id_pracownika, Imię, Nazwisko, Zarobki ) AS
SELECT Id_pracownika, Imię, Nazwisko, Zarobki FROM Pracownicy
WHERE Stanowisko = ‘urzędnik’;
Użycie
perspektywy:
SELECT Zarobki FROM Urzędnicy
WHERE Nazwisko = ‘Nowak’
Po tekstowej
modyfikacji
zapytania:
SELECT Zarobki FROM
(SELECT Id_pracownika, Imię, Nazwisko, Zarobki FROM Pracownicy
WHERE Stanowisko = ‘urzędnik’)
WHERE Nazwisko = ‘Nowak’
Usunięcie
zbędnych
astrybutów:
SELECT Zarobki FROM
(SELECT Nazwisko, Zarobki FROM Pracownicy
WHERE Stanowisko = ‘urzędnik’)
WHERE Nazwisko = ‘Nowak’
Ostateczna
optymalizacja:
SELECT Zarobki FROM Pracownicy
WHERE Stanowisko = ‘urzędnik’ AND Nazwisko = ‘Nowak’
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 156
marzec 2002
Perspektywy łączące dane zapamiętane i wirtualne
Dla integracji systemów spadkowych lub sfederowanych potrzebne są perspektywy,
które łączą w jedną kolekcję zarówno dane wirtualne (odwzorowanie danych ze
starszych systemów) jak i dane rzeczywiste (pochodzące z nowszych systemów).
Stary system:
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
CREATE VIEW Student( Id, Nazwisko, NrIndeksu) AS
SELECT * FROM StaryNowyStudent
UNION
SELECT * FROM NowyStudent
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 157
Pozostają
problemy spójnej
aktualizacji oraz
wydajności.
marzec 2002
Aktualizacja zmaterializowanych perspektyw
Główny problem w aktualizacji zmaterializowanych perspektyw polega na tym, jak
uniknąć ponownego generowania całej zmaterializowanej perspektywy po
aktualizacji bazy danych. Istnieją dwie strategie:
Określenie kryteriów do stwierdzenia, że dana aktualizacja nie wpływa na
wyliczoną zmaterializowaną perspektywę.
Np. najprostsze kryterium może być następujące:
Jeżeli zlecenie aktualizacyjne używa nazw danych 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.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 158
marzec 2002
Perspektywy obiektowe (1)
 Wskutek “wtłoczenia” w problem perspektyw ogromnej liczby pojęć
obiektowych i innych, przy braku spójnego i jednorodnego modelu
formalnego, propozycje rozwiązania tego problemu są partykularne,
nieregularne, niedostatecznie generalne, obciążone drugorzędnymi
szczegółami, sporym bagażem syntaktycznym i mętnymi dywagacjami
semantycznymi.
 Podstawowa metoda przetwarzania perspektyw, czyli modyfikacja
zapytań, została zapomniana. O optymalizacji zapytań włączającej
perspektywy w ogóle się nie wspomina.
 Nawet jeżeli są propozycje aktualizacji perspektyw, z reguły są one
ograniczone do takich ich rodzajów, które “zwracają” zapamiętane
obiekty w niezmienionej postaci. W tym względzie sytuacja jest gorsza
niż w modelu relacyjnym.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 159
marzec 2002
Perspektywy obiektowe (2)
 Nie występują środki sterowania intencją aktualizacji perspektywy.
Nie występują perspektywy rekurencyjne i perspektywy z parametrami.
Świat nie dojrzał...
 Problemem są niespójne i ograniczone podejścia do obiektowych języków
zapytań. Funkcjonuje duża ilość fałszywych stereotypów, z których część
pochodzi ze zbyt dosłownego przeniesienia do obiektowości
paradygmatów modelu relacyjnego
 Brak zintegrowania obiektowych języków zapytań z konstrukcjami
imperatywnymi, niepotrzebny nacisk (patrz ODMG), aby tego rodzaju
konstrukcje “oddelegować” do obiektowych języków programowania
takich jak C++, Java i Smalltalk (gdzie problem aktualizacji perspektyw
staje się niewyrażalny).
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 160
marzec 2002
Refleksja nt. obiektowych perspektyw...
Problem obiektowych perspektyw dla prostego przypadku jest banalny.
 Można przyjąć, że perspektywa wyznacza podzbiór obiektów pewnej klasy, zaś
cała semantyka rzeczywistych obiektów jest przeniesiona do obiektów
wirtualnych. To rozwiązanie można wzmocnić ograniczeniem dostępu do
pewnych atrybutów (patrz rozwiązanie w 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.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 161
marzec 2002
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.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 162
marzec 2002
Perspektywy jako procedury funkcyjne
Konieczne jest określenie:
 Gdzie taka procedura funkcyjna jest umieszczona w strukturze obiektowej? W
zależności od tego, możemy mieć wirtualne obiekty, jeżeli procedura jest na
czubku struktury obiektowej, lub wirtualne atrybuty, jeżeli procedura jest
metodą zdefiniowaną wewnątrz klasy.
 Na jakim środowisku taka funkcja działa? Chodzi o reguły zakresu. Jak wynik
takiej procedury ma być podłączony do istniejących lub nowych klas?
 Co taka procedura funkcyjna zwraca? Chodzi o ich dziedzinę semantyczną.
 W jaki sposób wynik takiej procedury (czyli wirtualne dane) jest udostępniony
dla innych konstrukcji danego języka zapytań lub programowania?
 Czy taka procedura funkcyjna może mieć parametry? Jakie to ma konsekwencje?
 Czy taka procedura może być rekurencyjna? Jakie to ma konsekwencje?
 Czy taka procedura może mieć imperatywne ciało i lokalne środowisko danych?
 Jaki jest stosunek takich procedur do standardowych mechanizmów ograniczenia
dostępu do danych?
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 163
marzec 2002
Przetwarzanie zapytań
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 164
marzec 2002
Przetwarzanie zapytań w rozproszonych BD
Przetwarzanie zapytań powinno minimalizować zarówno obciążenie linii
transmisyjnych jak i pracochłonność przetwarzania po stronie klienta
(globalnej aplikacji) jak i po stronie serwerów.
 Przetwarzanie wyłącznie po stronie klienta (gruby klient): ogromne
obciążenie linii transmisyjnych.
 Przetwarzanie wyłącznie po stronie serwerów (chudy klient): może
powstać wąskie gardło wskutek tego, że jednocześnie wielu klientów
będzie żądać usługi od jednego serwera.
 Generalna zasada: "wyślij zapytanie do danych, a nie dane do zapytanie"
nie dla wszystkich przypadków jest słuszna i rodzi problemy koncepcyjne.
 Przetwarzanie zapytań odbywa się poprzez:
• dekompozycję zapytania na operacje wysyłane do różnych
węzłów,
• porządkowanie tych operacji,
• zbieranie ich rezultatów oraz ich przetwarzanie przez klienta w
celu skonstruowania ostatecznego wyniku zapytania.
marzec 2002
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 165
Strategie optymalizacji zapytań w rozprosz.
BD
 Przetwarzanie wyłącznie po stronie klienta. Pobiera on wszystkie dane
potrzebne do realizacji zapytania do swojego obszaru => duży czas i
koszt transmisji danych, małe problemy koncepcyjne.
 "Statyczna" (jednoczesna) dekompozycja zapytania na podzapytania,
wysłanie ich do lokalnych miejsc, przesłanie rezultatów podzapytań do
klienta, który łączy tych rezultaty w globalny rezultat. Skuteczna dla
podziału poziomego danych i zapytań ograniczonych do selekcji/projekcji,
nieskuteczna dla zapytań złożonych.
 "Dynamiczna" dekompozycja: generacja podzapytania do miejsca 1 i
przesłanie wyniku 1 do centralnego miejsca; generacja podzapytania do
miejsca 2 i przesłanie wyniku 2 do centralnego miejsca, itd. Brak
równoległości działania serwerów, trudności koncepcyjne.
 Hybrydowa dekompozycja - połączenie dekompozycji statycznej i
dynamicznej.
 Hybrydowa dekompozycja z przesłaniem danych do serwera. Klient
nie tylko dokonuje wysłania podzapytania do serwera, ale również
przesyła do niego część danych, które otrzymał od innych serwerów
(aby
marzec 2002
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 166
Indeksowanie rozproszonych zasobów
 Szczególnie istotne w przypadku technologii 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
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 167
marzec 2002
Statyczny schemat przetwarzania zapytań (1)
1. Klient realizuje zapytanie Z odwołujące się do danych na serwerach 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.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 168
marzec 2002
Statyczny schemat przetwarzania zapytań (2)
Klient
Z1
Z2
Dekompozycja zapytania Z
Scalenie wyników
W1
Serwer S1
Serwer S2
W2
...
Zk
Wynik W zapytania Z
Wk
Serwer Sk
 Statyczny schemat ma przede wszystkim zastosowanie w przypadku
poziomej fragmentacji danych, np. rozbicia obiektów Pracownik na wiele
podzbiorów o takiej samej budowie przechowywanych na poszczególnych
serwerach.
 W tym przypadku dekompozycja zapytania oznacza po prostu jego
skopiowanie: Z = Z1 = Z2 = ... = Zk
 Scalenie wyników polega na sumie mnogościowej wyników cząstkowych.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 169
marzec 2002
Dynamiczny schemat przetwarzania zapytań
1. Klient realizuje zapytanie Z odwołujące się do danych na serwerach 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
(Z, W1)  Z2, F1
(Z, W1, W2)  Z3, F2
Scalenie wyników
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 170
Z1
W1
Serwer S1
Z2, F1
W2
Serwer S2
Z3, F2
W3
Serwer S3
marzec 2002
Przykład: technika pół-złączeń (1)
Serwer 1
Serwer 2
DOSTAWCA
DC
DNR NAZW
D1 Abacki
D2 Bober
D5 Erbel
STATUS MIASTO
20 Lublin
10 Poznań
30 Radom
semijoin
DNR CNR ILOŚĆ
D1
D1
D2
D2
D3
D4
D4
D4
C4
C5
C1
C2
C2
C2
C4
C5
200
100
300
400
200
200
300
400
Klient ma dokonać złączenia relacji DOSTAWCA i relacji DC:
select * from DOSTAWCA, DC
where DOSTAWCA.DNR = DC.DNR
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 171
marzec 2002
Przykład: technika pół-złączeń (2)
W celu realizacji zapytania klient musi wykonać następujące czynności:
1. Sciagą dane z serwera 1 przy pomocy zapytania Z1:
select * from DOSTAWCA
Uzyska w ten sposób wynik W1.
W1
DNR NAZW
D1 Abacki
D2 Bober
D5 Erbel
STATUS MIASTO
20 Lublin
10 Poznań
30 Radom
2. Tworzy pomocniczą tabelę poprzez projekcję W1 na DNR: tę tabelę nazywa F1.
F1
DNR
D1
D2
D5
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
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 172
marzec 2002
Przykład: technika pół-złączeń (3)
4. Uzyska w ten sposób wynik W2: Jest to tzw. pół-złączenie relacji DC,
parametryzowane relacją DOSTAWCA.
W2
DNR CNR ILOŚĆ
D1
C4
200
D1
C5
100
D2
C1
300
D2
C2
400
Pół-złączenie relacji R1, parametryzowane relacją
R2, powstaje poprzez złączenie R1 z R2, a
następnie projekcję wyniku na atrybuty relacji R1
5. Przesyła wynik W2 - pół-złączenie - do klienta
6. Klient dokonuje ostatecznego scalenia wyników - złączenia relacji W1 i W2.
Wynik
DNR
D1
D1
D2
D2
NAZW
Abacki
Abacki
Bober
Bober
STATUS
20
20
10
10
MIASTO CNR ILOŚĆ
C4
200
Lublin
C5
100
Lublin
C1
300
Poznań
C2
400
Poznań
W zależności od oceny kosztów przetwarzania i transmisji klient może zacząć od
ściągnięcia danych z serwera 2 i następnie dokonać pół-złączenia relacji DOSTAWCA.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 173
marzec 2002
Podsumowanie
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 174
marzec 2002
Podsumowanie (1)
 Globalizacja przestrzeni informacyjnej powoduje nacisk na tworzenie
rozproszonych i federacyjnych baz danych, które umożliwiłyby tworzenie
aplikacji globalnych, działających na zestawie dziesiątków, tysięcy lub
milionów lokalnych BD.
 Połączenie tych lokalnych baz danych siecią komputerową stwarza
niezbędną infrastrukturę techniczną, ale nie rozwiązuje ogromnej ilości
problemów koncepcyjnych, których część została omówiona na tym
wykładzie.
 Pewna część problemów jest rozwiązana dla rozproszonych relacyjnych
baz danych. Rozproszone obiektowe bazy danych znajdują się na
początku drogi.
 Niektóre problemy, takie jak: przetwarzanie globalnych transakcji,
aktualizowalne perspektywy, rozstrzyganie niezgodności schematów,
akceptowalna wydajność globalnych aplikacji, itd., prawdopodobnie nie
mają ogólnego rozwiązania. Pozostają nadzieje na rozwiązania cząstkowe.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 175
marzec 2002
Podsumowanie (2)
 Problemy rozproszenia są skutkiem “spadku” pozostawionego nam przez
naszych poprzedników. Znaczna część problemów może rozwiązać się
sama poprzez rezygnację ze spadku, tj. poprzez wymarcie kłopotliwych
SZBD i powstanie nowych SZBD, lepiej przystosowanych do tworzenia
rozproszonych federacji.
 Konieczna jest standardyzacja:
• w zakresie modeli danych
• w zakresie ontologii biznesowej i metamodeli
• w zakresie wymiany danych
• w zakresie API realizującego dostęp do do danych, w szczególności języków
zapytań
 Konieczne są dalsze prace badawcze i wdrożeniowe w zakresie
przetwarzania i optymalizacji rozproszonych obiektowych zapytań,
protokołów dostępu, obiektowych perspektyw, ontologii, metamodeli,
formatów wymiany danych, rozproszonych transakcji, itd.
© K.Subieta. Rozproszone i federacyjne bazy danych, Folia 176
marzec 2002