Konstrukcja systemów obiektowych i rozproszonych

Systemy rozproszone (SYR)
Wykładowca: Kazimierz Subieta
Polsko-Japońska Wyższa Szkoła
Technik Komputerowych, Warszawa
[email protected]
Wykład 3:
Projektowanie i architektury
rozproszonych baz danych
Instytut Podstaw Informatyki PAN,
Warszawa
[email protected]
© K.Subieta.Systemy rozproszone 3, Folia 1
styczeń 2005
Podejścia do projektowania rozproszonych BD:
top-down i bottom-up
 Od ogółu do szczegółów (top-down): 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 (bottom-up): Zintegrowanie już istniejących
(spadkowych) lub zaprojektowanych lokalnych baz danych w jedną
globalną rozproszoną bazę danych.
© K.Subieta.Systemy rozproszone 3, Folia 2
styczeń 2005
Projektowanie: podejście top-down
Analiza
Model pojęciowy
scentralizowany
Model logiczny
scentralizowany
Modele logiczne
dla
poszczególnych
miejsc
© K.Subieta.Systemy rozproszone 3, Folia 3
 Analiza systemowa: rozpoznanie
wymagań, precyzowanie kontekstu
przyszłej bazy danych.
 Projektowanie schematu
pojęciowego
 Projektowanie struktury logicznej
 Kryteria rozproszenia są związane z
faktem fizycznego rozproszenia
Kryteria
źródeł i odbiorców danych oraz
rozproszenia
autonomii lokalnych baz danych.
 Ustalają one decyzje, które
fragmenty projektu pojęciowego
będą przechowywane w
poszczególnych miejscach, a także
jak należy zdekomponować schemat
logiczny na poszczególne miejsca
styczeń 2005
Dalsze fazy postępowania w podejściu top-down
 Określenie danych podlegających replikacjom (lokalnych kopii) oraz
strategii replikacji.
 Zróżnicowanie logicznego schematu danych w zależności od typu SZBD
w poszczególnych miejscach.
 Określenie lokalnych schematów dla poszczególnych miejsc.
 Określenie danych autonomicznych dla poszczególnych miejsc, nie
uczestniczących w rozproszonej bazie danych; co prowadzi do określenia
schematu pojęciowego i logicznego dla danych widzianych z zewnątrz.
 Podział schematu logicznego: Wg różnych reguł związanych na ogół z
fizycznym ulokowaniem obiektów rzeczywistych (np. osób
zatrudnionych, sprzętu, co pociąga za sobą odpowiedni podział schematu
logicznego) lub też z fizycznym ulokowaniem programów
aplikacyjnych działających na tych obiektach.
© K.Subieta.Systemy rozproszone 3, Folia 4
styczeń 2005
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.
© K.Subieta.Systemy rozproszone 3, Folia 5
styczeń 2005
Fragmentacja pionowa relacyjnej bazy danych
Warszawa
Kutno
DC
DOSTAWCA_DANE
DNR NAZW
D1
D2
D3
D4
D5
DNR CNR ILOŚĆ
STATUS
Abacki
Bober
Czerny
Dąbek
Erbel
20
10
30
20
30
Sieć
Gdańsk
DOSTAWCA_MIASTO
DNR
D1
D2
D3
D4
D5
© K.Subieta.Systemy rozproszone 3, Folia 6
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
styczeń 2005
Fragmentacja pozioma relacyjnej bazy danych
DOSTAWCA
DNR NAZW
Poznań
DC
DNR CNR ILOŚĆ
STATUS MIASTO
10 Poznań
30 Poznań
D2 Bober
D3 Czerny
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
Radom
STATUS MIASTO
D5 Erbel
© K.Subieta.Systemy rozproszone 3, Folia 7
30 Radom
DNR CNR ILOŚĆ
D1
D4
D4
C6
C2
C4
100
200
300
styczeń 2005
Fragmentacja pionowa obiektów Pracownik
Radom
Klasa danych
osobistych
Nowak
dane osobiste
Kowalski
dane osobiste
...
Kalisz
Sieć
Nowak
dane o ocenach
Kraków
Klasa danych o
ocenach
Kowalski
dane o ocenach
...
Klasa danych o
zatrudnieniu
Nowak
dane o zatrud.
© K.Subieta.Systemy rozproszone 3, Folia 8
Kowalski
dane o zatrud.
...
styczeń 2005
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
© K.Subieta.Systemy rozproszone 3, Folia 9
Klasa
Pracownik
Pracownik
Malina
...
Klasa
Pracownik
Pracownik
Zagórny.
...
styczeń 2005
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.Systemy rozproszone 3, Folia 10
styczeń 2005
Projektowanie: podejście bottom-up
 Podejście ad hoc: Budowa uniwersalnych lub specyficznych dla danego
zastosowania pomostów (gateways) umożliwiających dostęp z danego
systemu bazy danych do innych baz danych. Pomost może (nie musi)
zapewniać przezroczystość rozproszenia.
 Podejście oparte o globalny schemat: Wszystkie składniki rozproszonej
BD są objęte jednym globalnym schematem, jednakowym dla każdego
miejsca i zapewniającym przezroczystość rozproszenia. Istotną wadą
podejścia opartego na globalnym schemacie jest brak możliwości
sterowania zakresem autonomii każdego lokalnego systemu.
 Federacyjna baza danych: Każda lokalna baza danych zachowuje swoją
autonomię, udostępniając tylko część danych dla innych miejsc w RBD.
Podejście federacyjne zakłada, że każda lokalna baza danych jest widziana
poprzez pewną perspektywę (view), ukrywającą niektóre dane dla
rozproszonych aplikacji.
© K.Subieta.Systemy rozproszone 3, Folia 11
styczeń 2005
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.
© K.Subieta.Systemy rozproszone 3, Folia 12
styczeń 2005
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.Systemy rozproszone 3, Folia 13
styczeń 2005
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.Systemy rozproszone 3, Folia 14
styczeń 2005
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.Systemy rozproszone 3, Folia 15
styczeń 2005
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.Systemy rozproszone 3, Folia 16
styczeń 2005
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.Systemy rozproszone 3, Folia 17
styczeń 2005
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.Systemy rozproszone 3, Folia 18
s2
k7
styczeń 2005
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.Systemy rozproszone 3, Folia 19
Logika przetwarzania
Serwer
bazy
danych
Serwer
bazy
danych
styczeń 2005
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.Systemy rozproszone 3, Folia 20
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)
styczeń 2005
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.Systemy rozproszone 3, Folia 21
styczeń 2005
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.Systemy rozproszone 3, Folia 22
styczeń 2005
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.Systemy rozproszone 3, Folia 23
Oprogramowanie pośredniczące
organizujące komunikację z odległymi
klientami i szeregujące transakcje klientów
celem przetwarzania ich przez bazę danych.
styczeń 2005
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.Systemy rozproszone 3, Folia 24
styczeń 2005
3-warstwowa architektura aplikacji Web
Serwer Web
Sieć
Internet
Serwer aplikacji
Serwer bazy danych
HTTP
Baza
danych
Baza
danych
Przeglądarka
Serwer
© K.Subieta.Systemy rozproszone 3, Folia 25
styczeń 2005
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.Systemy rozproszone 3, Folia 26
styczeń 2005
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.Systemy rozproszone 3, Folia 27
styczeń 2005
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.Systemy rozproszone 3, Folia 28
styczeń 2005
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.Systemy rozproszone 3, Folia 29
Miejsce 2
Miejsce 3
styczeń 2005
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.Systemy rozproszone 3, Folia 30
styczeń 2005
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.Systemy rozproszone 3, Folia 31
styczeń 2005
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.Systemy rozproszone 3, Folia 32
styczeń 2005
Przyszłościowa architektura aplikacji
internetowych
Przeglądarka
WWW
XML
XML
Przeglądarka
WWW
Warstwa
klienta
Serwer Web
Serwer aplikacji
Aplikacja
globalna
Aplikacja
globalna
Warstwa
aplikacji
globalnych
Aplikacja
globalna
Interakcja z aplikacjami poprzez
protokoły oparte na XML
Logiczna
warstwa
pośrednia
Globalny wirtualny
skład zasobów usług i
danych
Web Services
Serwisy
lokalne
Serwisy
lokalne
Serwisy
lokalne
Serwisy
lokalne
Serwisy
lokalne
Zasoby
usług i
danych
Serwisy
lokalne
wrappery
Relacyjna
baza
danych
Obiektoworelacyjna
baza danych
© K.Subieta.Systemy rozproszone 3, Folia 33
Obiektowa
baza danych
XML-owa
baza
danych
Dokumenty
XML na
Webie
Inne dokumenty
na Webie:
HTML, Word,...
Zasoby
danych
styczeń 2005
Standardy łączenia rozproszonych danych (1)
 Open DataBase Connectivity (ODBC): standard [zdalnego] dostępu do
relacyjnych baz danych
• bazuje na Call Level Interface (CLI) opracowanym przez konsorcjum X/Open
• definiuje API oraz cechy SQL które muszą być zapewnione na różnych
poziomach zgodności.
 Java DataBase Connectivity (JDBC): analogiczny do ODBC standard
dla Java.
 OLE-DB: API podobne do ODBC, ale wspomagające źródła niebazodanowe, takie jak płaskie pliki.
• OLE-DB program może negocjować ze źródłem danych aby znaleźć
własności, które ono podtrzymuje.
• API jest podzbiorem SQL
 ADO (Active Data Objects): łatwy interfejs do funkcji OLE-DB
© K.Subieta.Systemy rozproszone 3, Folia 34
styczeń 2005
Standardy łączenia rozproszonych danych (2)
 Kilka standardów bazujących na XML dla E-commerce
• Np. RosettaNet (łańcuchy dostaw), BizTalk
• Definiują katalogi, opisy usług, faktury, zamówienia, itd.
• osłony XML są używane do eksportu informacji z relacyjnej BD do XML
 Resource Description Framework (RDF): specyfikacja ontologii dla
zasobów Web.
 Web Services i Simple Object Access Protocol (SOAP): bazujący na
XML standard dla zdalnego wołania usług. SOAP jest mniej elastyczny i
uniwersalny w stosunku do CORBA.
• Używa XML do zakodowania danych, HTTP jako protokołu transportowego
• Kilka dalszych standardów: WSDL (opis danych i usług), UDDI (rejestry
usług), itd.
• Dalsze standardy są oparte na SOAP dla specyficznych aplikacji, np. OLAP i
Data Mining (standardy Microsoft'u)
© K.Subieta.Systemy rozproszone 3, Folia 35
styczeń 2005
Standardy łączenia rozproszonych danych (3)
 Object Data Management Group (ODMG) standard obiektowych baz
danych
• jest raczej używany hasłowo, nie jest znana całościowa implementacja.
 OMG CORBA (Common Object Request Broker Architecture) najbardziej uniwersalny standard obejmujący ogromną liczbę aspektów.
W szczególności, notacja UML jest jego składową. Pakiety ORB (Object
Request Broker) są oprogramowaniem realizującym tę architekturą.
 .NET/DCOM (Distributed Component Object Model) - standard
Microsoftu zintegrowany z systemami operacyjnymi Microsoftu.
Ograniczony w stosunku do standardu CORBA.
 RMI (Remote Method Invocation) - oprogramowanie firmy Sun,
ograniczone w stosunku do standardu CORBA do oprogramowania
pisanego w Java. Java Beans i Enterprise Java Beans wykorzystują RMI
jako transport.
© K.Subieta.Systemy rozproszone 3, Folia 36
styczeń 2005