Systemy rozproszone syr
This presentation is the property of its rightful owner.
Sponsored Links
1 / 36

Systemy rozproszone (SYR) PowerPoint PPT Presentation


  • 90 Views
  • Uploaded on
  • Presentation posted in: General

Systemy rozproszone (SYR). Wykład 3: Projektowanie i architektury rozproszonych baz danych. Wykładowca : Kazimierz Subieta Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa [email protected] Instytut Podstaw Informatyki PAN, Warszawa [email protected]

Download Presentation

Systemy rozproszone (SYR)

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Systemy rozproszone syr

Systemy rozproszone (SYR)

Wykład 3:

Projektowanie i architektury rozproszonych baz danych

Wykładowca: Kazimierz Subieta

Polsko-Japońska Wyższa Szkoła

Technik Komputerowych, Warszawa

[email protected]

Instytut Podstaw Informatyki PAN,

Warszawa

[email protected]


Podej cia do projektowania rozproszonych bd top down i bottom up

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.


Projektowanie podej cie top down

Projektowanie: podejście top-down

Analiza

  • Analiza systemowa: rozpoznanie wymagań, precyzowanie kontekstu przyszłej bazy danych.

  • Projektowanie schematu pojęciowego

  • Projektowanie struktury logicznej

  • Kryteria rozproszenia są związane z faktem fizycznego rozproszenia źródeł i odbiorców danych oraz autonomii lokalnych baz danych.

  • Ustalają one decyzje, które fragmenty projektu pojęciowego będą przechowywane w poszczególnych miejscach, a także jak należy zdekomponować schemat logiczny na poszczególne miejsca

Model pojęciowy scentralizowany

Model logiczny scentralizowany

Kryteria

rozproszenia

Modele logiczne dla poszczególnych miejsc


Dalsze fazy post powania w podej ciu top down

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.


Podstawowe metody fragmentacji schematu

Podstawowe metody fragmentacji schematu

  • Fragmentacja pionowa oznacza przyporządkowanie poszczególnych klas obiektów do poszczególnych miejsc, lub rozbicie obiektów danej klasy na dwa lub więcej podobiektów, przy czym takie podobiekty są przechowywane w różnych miejscach.

  • Fragmentacja pionowa może oznaczać konieczność odpowiedniego podziału informacji zawartych w klasach obiektów oraz ustalenia środków podtrzymania jednoznacznej tożsamości obiektów.

  • Fragmentacja pozioma oznacza rozbicie populacji obiektów danej klasy na dwa lub więcej miejsc geograficznych.

  • Fragmentacja pozioma może być dokonywana na podstawie różnych kryteriów, które często wiązane są z geograficznym ulokowaniem obiektów rzeczywistych, lub też z geograficznym ulokowaniem przetwarzania tych obiektów.


Fragmentacja pionowa relacyjnej bazy danych

Fragmentacja pionowa relacyjnej bazy danych

Warszawa

Kutno

DC

DOSTAWCA_DANE

DNR

D1

D1

D1

D1

D1

D1

D2

D2

D3

D4

D4

D4

CNR

C1

C2

C3

C4

C5

C6

C1

C2

C2

C2

C4

C5

ILOŚĆ

300

200

400

200

100

100

300

400

200

200

300

400

DNR

D1

D2

D3

D4

D5

NAZW

Abacki

Bober

Czerny

Dąbek

Erbel

STATUS

20

10

30

20

30

Sieć

Gdańsk

DOSTAWCA_MIASTO

DNR

D1

D2

D3

D4

D5

MIASTO

Lublin

Poznań

Poznań

Lublin

Radom


Fragmentacja pozioma relacyjnej bazy danych

Fragmentacja pozioma relacyjnej bazy danych

DC

DOSTAWCA

DNR

D1

D4

D4

CNR

C6

C2

C4

ILOŚĆ

100

200

300

DNR

D1

D4

NAZW

Abacki

Dąbek

STATUS

20

20

MIASTO

Lublin

Lublin

Radom

DOSTAWCA

DNR

D5

NAZW

Erbel

STATUS

30

MIASTO

Radom

DC

Poznań

DOSTAWCA

DNR

D2

D2

D3

CNR

C1

C2

C2

ILOŚĆ

300

400

200

DNR

D2

D3

NAZW

Bober

Czerny

STATUS

10

30

MIASTO

Poznań

Poznań

Lublin

Sieć


Fragmentacja pionowa obiekt w pracownik

Fragmentacja pionowa obiektów Pracownik

Kalisz

Klasa danych o ocenach

Nowak

dane o ocenach

Kowalski

dane o ocenach

...

Radom

Klasa danych osobistych

Nowak

dane osobiste

Kowalski

dane osobiste

...

Kraków

Klasa danych o zatrudnieniu

Nowak

dane o zatrud.

Kowalski

dane o zatrud.

...

Sieć


Fragmentacja pozioma obiekt w pracownik

Fragmentacja pozioma obiektów Pracownik

Klasa Pracownik

Kalisz

Pracownik

Styka

Pracownik

Malina

...

Radom

Klasa Pracownik

Obiekty Pracownik są przechowywane zgodnie z geograficznym położeniem pracodawcy.

Pracownik

Nowak

Pracownik

Kowalski

...

Sieć

Klasa Pracownik

Kraków

Pracownik

Malasa

Pracownik

Zagórny.

...


Inne fragmentacje danych w rozproszonej bd

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.


Projektowanie podej cie bottom up

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.


Federacyjna bd tworzona metod bottom up

Federacyjna BD tworzona metodą bottom-up

Aplikacje globalne

Aplikacje globalne

Aplikacje globalne

Perspektywa

Mediator

Osłona

Perspektywa

Mediator

Osłona

Aplikacje lokalne

Aplikacje lokalne

Aplikacje lokalne

Aplikacje lokalne

Aplikacje lokalne

Aplikacje lokalne

Schemat lokalny 2

Schemat lokalny 1

Miejsce 1

Miejsce 2

Baza danych 1

Baza danych 2

Schemat federacyjnej bazy danych

.....

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.


Architektura klient serwer

Architektura klient-serwer

Całość pracy wykonywanej przez system komputerowy jest podzielona na dwie części:

wykonywaną po stronie klienta (zwykle związaną z interakcją z użytkownikiem)

wykonywaną po stronie serwera (komunikacja, dostęp do bazy danych, zarządzanie repozytoriami pamięci, zarządzanie globalną przestrzenią nazw)

Podstawowe

problemy:

Określenie mechanizmu komunikacji pomiędzy klientem a serwerem.

Podział funkcji na te, które są wykonywane po stronie klienta i te, które są wykonywane po stronie serwera

Określenie jednostki komunikacji klient - serwer


Regu y architektury klient serwer 1

Reguły architektury klient-serwer (1)

  • Zachowanie autonomii serwera. Klienci powinni zachowywać reguły wykorzystania serwera, nie powinni powodować jego niedostępność (np. zamykać duże ilości danych), nie powinni łamać ograniczeń integralności.

  • Zachowanie autonomii klienta. Klienci nie powinni zachowywać się różnie w zależności od tego, czy serwer jest lokalny czy odległy. Powinni być odizolowani od kwestii fizycznego ulokowania danych.

  • Wspomaganie dla aplikacji niezależnych od serwera.

  • Dostęp do własności (danych, usług) serwera. Klienci mogą żądać od serwera wykonanie przewidzianych dla niego funkcji.

  • Wspomaganie dla bieżącego dostępu do danych. Dostęp ten powinien być bezpośredni, bez pośrednictwa plików przekazywanych do/od klienta.

  • Minimalny wpływ architektury K/S na wymagania dla klienta. Oprogramowanie klienta w architekturze K/S nie powinno wykazywać znacznego zwiększenia zapotrzebowania na RAM lub objętość dysku.


Regu y architektury klient serwer 2

Reguły architektury klient-serwer (2)

  • Kompletność opcji niezbędnych do połączenia. Oprogramowanie klienta nie powinno zawierać kodu realizującego połączenie z serwerem.Powinien to zapewniać serwer komunikacyjny.

  • Możliwość budowy lokalnych prototypów. Programista powinien mieć możliwość budowy i testowania aplikacji K/S wyłącznie na stacji klienta.

  • Kompletność narzędzi użytkownika końcowego. Projektowanie ekranów, generacja zapytań, itd. powinny być częścią środowiska.

  • Kompletność środowiska budowy aplikacji. Powinno przewidywać możliwość łączenia się w sieci, dostęp do usług globalnych w zakresie nazw, lokacji danych, itd.

  • Otwarte środowisko języka-gospodarza. Powinno zapewniać możliwość użycia uniwersalnego języka programowania do budowy aplikacji.

  • Szczególna troska o standardy. Im bardziej będą one przestrzegane, tym mniej będzie późniejszych kłopotów ze współdziałaniem.


Przyk ad architektury szbd typu klient serwer

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

Interfejs serwera

Zarządzanie

zasobami

Zarządzanie

transakcjami

Zarządzanie

buforami

Zarządzanie

logiem

Zarządzanie

zamkami

Serwer

. . .

Zarządzanie

siecią


Architektura klient multi serwer 1

Architektura klient-(multi) serwer (1)

Połączenia bezpośrednie:

k2

k3

k7

k1

s4

k4

k8

s1

s3

k5

s2

k9

k6

k10

k11


Architektura klient multi serwer 2

Architektura klient-(multi) serwer (2)

Połączenia poprzez sieć: nie ma bezpośrednich połączeń, zarówno serwery jak i klienci są przyłączani w jednakowy sposób do wspólnej sieci komputerowej.

k1

k2

s4

k3

k9

k4

Sieć komputerowa

s1

k8

k5

s3

k6

s2

k7


Architektura trzywarstwowa i wielowarstowa

Architektura trzywarstwowa i wielowarstowa

Logika przetwarzania

Serwer

bazy

danych

Serwer

bazy

danych

three-tier architecture

multi-tier architecture

  • Architektura klient-serwer podzielona na trzy warstwy:

    • interfejs użytkownika,

    • logikę przetwarzania (reguły biznesu, logikę biznesu)

    • serwer (serwery) bazy danych.

  • Warstwy są zaprojektowane i istnieją niezależnie, co ma duże znaczenie dla pielęgnacyjności systemu ze względu na możliwość zmian w dowolnej warstwie bez konieczności zmian w pozostałych warstwach.

  • Często warstwy są zrealizowane na odrębnych platformach: interfejs na MS Windows, logika przetwarzania na serwerze aplikacji i baza danych na serwerze bazy danych.

  • Środkowa warstwa może składać się z wielu warstw, co jest określane jako architektura wielowarstwowa.

Interfejs

użytkownika


Logiczna architektura oprogramowania

Logiczna architektura oprogramowania

Architektura klient-serwer powinna odzwierciedlać logiczny podział oprogramowania na części. Nie jest to tak istotne w systemie scentralizowanym.

Architektura trójwarstwowa:

Staranne rozdzielenie tych warstw jest bardzo istotne z punktu widzenia tworzenia i modyfikowalności oprogramowania. Dzięki temu rozdzieleniu, możliwa jest np. poprawa interfejsu użytkownika bez jakichkolwiek interwencji w pozostałe warstwy oprogramowania.

Warstwa prezentacyjna

(interfejs użytkownika)

cienki

klient

gruby

klient

Warstwa przetwarzania

(logika biznesu)

Zasada oddzielania aspektów

(separation of concerns principle, E.Dijkstra)

Warstwa zarządzania bazą danych


Cienki i gruby klient

Cienki i gruby klient

Terminy cienki klient (thin client) oraz gruby klient (fat client) odnoszą się do mocy i jakości przetwarzania po stronie klienta w architekturze klient-serwer.

Model cienkiego klienta: klient posiada niezbyt wielką moc przetwarzania, ograniczoną do prezentacji danych na ekranie. Przykładem jest klient w postaci przeglądarki WWW.

Model grubego klienta: klient posiada znacznie bogatsze możliwości przetwarzania, w szczególności może zajmować się nie tylko warstwą prezentacji, lecz także warstwą przetwarzania aplikacyjnego (logiki biznesu).

Powyższy podział posiada oczywiście pewną gradację.

Model cienkiego klienta jest najczęstszym rozwiązaniem w sytuacji, kiedy system scentralizowany jest zamieniany na architekturę klient-serwer. Wadą jest duże obciążenie serwera i linii komunikacyjnych.

Model grubego klienta używa większej mocy komputera klienta do przetwarzania zarówno prezentacji jak i logiki biznesu. Serwer zajmuje się tylko obsługą transakcji bazy danych. Popularnym przykładem grubego klienta jest bankomat. Zarządzanie w modelu grubego klienta jest bardziej złożone.


Architektury dwuwarstwowe

Architektury dwuwarstwowe

Uproszczone architektury trójwarstwowe z cienkim lub grubym klientem.

Warstwa prezentacyjna

(interfejs użytkownika)

+ Warstwa przetwarzania

(logika biznesu)

Warstwa prezentacyjna

(interfejs użytkownika)

cienki

klient

gruby

klient

Warstwa przetwarzania

(logika biznesu) + Warstwa zarządzania bazą danych

Warstwa przetwarzania

(logika biznesu) + Warstwa zarządzania bazą danych

W tym modelu przetwarzanie (logika biznesu) jest dzielone pomiędzy klienta i serwera. Zaprojektowanie jej jest trudniejsze.


Przyk ad architektury k s sie bankomat w

Przykład architektury K/S - sieć bankomatów

Serwer kont klientów banku

Monitor

tele-przetwarzania

Baza danych kont klientów banku

Bankomat

Bankomat

Bankomat

Oprogramowanie pośredniczące organizujące komunikację z odległymi klientami i szeregujące transakcje klientów celem przetwarzania ich przez bazę danych.

Bankomat


Przyk ad architektury k s portal www

Przykład architektury K/S - portal WWW

klient

klient

klient

klient

interakcja poprzez HTTP

zapytania

SQL

Serwer Web:

generacja dynamicznych stron HTML dla klienta

+

zlecenia do bazy danych

Serwer bazy danych:

wykonywanie zapytań w SQL

wyniki

zapytań

SQL


3 warstwowa architektura aplikacji web

3-warstwowa architektura aplikacji Web

Serwer Web

Sieć

Internet

Serwer aplikacji

Serwer bazy danych

HTTP

Baza danych

Baza danych

Przeglądarka

Serwer


2 warstwowa architektura aplikacji web

2-warstwowa architektura aplikacji Web

Wiele warstw pośredniczących powoduje dodatkowe obciążenie.

Serwer Web

Serwer aplikacji

Sieć

Internet

Serwer bazy danych

HTTP

Baza danych

Baza danych

Przeglądarka

Serwer


Zastosowanie r nych architektur k s

Zastosowanie różnych architektur K/S

  • Dwuwarstwowa architektura K/S z cienkim klientem

    • Systemy spadkowe (legacy), gdzie oddzielenie przetwarzania i zarządzania danymi jest niepraktyczne.

    • Aplikacje zorientowane na obliczenia, np. kompilatory, gdzie nie występuje lub jest bardzo mała interakcja z bazą danych.

    • Aplikacje zorientowane na dane (przeglądanie i zadawanie pytań) gdzie nie występuje lub jest bardzo małe przetwarzanie.

  • Dwuwarstwowa architektura K/S z grubym klientem

    • Aplikacje w których przetwarzanie jest zapewnione przez wyspecjalizowane oprogramowanie klienta, np. MS Excel.

    • Aplikacje ze złożonym przetwarzaniem (np. wizualizacją danych, przetwarzaniem multimediów).

    • Aplikacje ze stabilną funkcjonalnością dla użytkownika, użyte w środowisku z dobrze określonym zarządzaniem.

  • Trzywarstwowa lub wielowarstwowa archiktektura K/S

    • Aplikacje o dużej skali z setkami lub tysiącami klientów.

    • Aplikacje gdzie zarówno dane jak i aplikacje są ulotne (zmienne).

    • Aplikacje integrujące dane z wielu rozproszonych źródeł.


Architektura rozproszonych obiekt w 1

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.


Architektura rozproszonych obiekt w 2

Architektura rozproszonych obiektów (2)

Aplikacja napisana w C++

Aplikacja na relacyjnej

bazie danych

Aplikacja

na Lotus Notes

Osłona 1

Osłona 2

Osłona 3

...

...

Pośrednik

Pośrednik

Pośrednik

Szyna oprogramowania (software bus)

Miejsce 1

Miejsce 2

Miejsce 3


Struktura logiczna rozproszonych obiekt w

Struktura logiczna rozproszonych obiektów

O7

O3

O5

O1

O2

O9

Obiekty

O4

O8

O6

K1

K3

Operacje na

obiektach

K4

K2

Szyna oprogramowania (software bus)

A1

A2

A3

Aplikacje

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.


Architektura serwera stron

Architektura serwera stron

Interfejs

Przeglądarka

Interfejs

zapytaniowy

obiektów

programistyczny

Optymalizacja

zapytań

Zarządzanie obiektami

Zarządzanie plikami i indeksami

Zarządzanie kieszenią stron

Zarządzanie zamkami

Zarządzanie składem

Zarządzanie kieszenią stron

Obiektowa

baza

danych

Aplikacja

Przedmiotem zarządzania

są fizyczne strony dyskowe

strony


Architektura serwera obiekt w

Architektura serwera obiektów

Aplikacja

Interfejs

Przeglądarka

Interfejs

zapytaniowy

obiektów

programistyczny

Zarządzanie obiektami

Zarządzanie obiektami

Optymalizacja zapytań

Zarządzanie zamkami

Zarządzanie składem

Zarządzanie stronami i kieszeniami

Obiektowa

baza

danych

Przedmiotem zarządzania

są obiekty

obiekty


Przysz o ciowa architektura aplikacji internetowych

Przyszłościowa architektura aplikacji internetowych

Przeglądarka

WWW

Przeglądarka

WWW

Warstwa klienta

XML

XML

Serwer Web

Serwer aplikacji

Warstwa aplikacji globalnych

Aplikacja globalna

Aplikacja globalna

Aplikacja globalna

Interakcja z aplikacjami poprzez

protokoły oparte na XML

Globalny wirtualny skład zasobów usług i danych

Logiczna warstwa pośrednia

Web Services

Zasoby usług i danych

Serwisy lokalne

Serwisy lokalne

Serwisy lokalne

Serwisy lokalne

Serwisy lokalne

Serwisy lokalne

wrappery

Relacyjna baza danych

Obiektowo-relacyjna baza danych

Obiektowa baza danych

XML-owa baza danych

Dokumenty XML na

Webie

Inne dokumenty na Webie: HTML, Word,...

Zasoby danych


Standardy czenia rozproszonych danych 1

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 nie-bazodanowe, takie jak płaskie pliki.

    • OLE-DB program może negocjować ze źródłem danych aby znaleźć własności, które ono podtrzymuje.

    • API jest podzbiorem SQL

  • ADO (Active Data Objects): łatwy interfejs do funkcji OLE-DB


Standardy czenia rozproszonych danych 2

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)


Standardy czenia rozproszonych danych 3

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.


  • Login