Rozproszona baza danych to baza danych istniejąca fizycznie na dwóch lub większej liczbie koputerów, traktowana jednak jak jedna logiczna całość dzięki czemu zmiany w zawatrości bazy w jednym komputerze sa uwzględniane również w innych maszynach. Rozproszone bazy danych są stosowane ze względu na zwiększoną wydajność przetwarzania na wielu komputerach jednocześnie.

System rozproszonej bazy danych składa się z zestawu miejsc lub węzłów połączonych za pomocą sieci łączności, takich że:

1. w każdym węźle jest ulokowany samodzielny system bazy danych, ale

2. systemy te pracują razem, więc uzytkownik w dowolnych miejscu sieci może mieć dostęp do danych dokładnie taki jakny wszystkie dane były przechowywane w jego własnym węźle

Zakłada się, że węzły wchodzące w skład systemu zarzadzania bazą danych są fizycznie rozproszone. Mogą to być miejsca geograficznie odległe, ale w rzeczywistości wystarczy, aby było one odseparowane logicznie. Dwa „miejsca” nawet mogą fizycznie się znajdować na tym samym komputerze.

Zalety

Przedsiębiorstwa są rozproszone . Firmy są podzielone lobicznie (na wydzieły, oddziały, zespoły, grupy robocze) bądź (na fabryki, zakłady, laboratoria). Wynika z tego, że dane są równiez rozproszone, ponieważ każda jednostka administracyjna musi utrzymywać dane do jej działania. Tak więc system rozproszony umożliwia odzwierciedlenie struktury przedsiębiorstwa w systemie bazy danych. Dane lokalne mozna przechowywać lokalnie, tam gdzie logicznie należą, a w tym samym czasie, w razie potrzeby, można mieć dostęp do zdalnych danych. Układ rozproszony łączy wydajność przetwarzania ze zwiększoną dostępnością.

Przykładem może być system bankowy.Weźmy pod uwagę dwa miejsca Los Ageles i San Francisco. Dane na temat rachunków bankowych otwartych w Los Angeles są przechowywane w Los Angeles, tych zaś z San Francisco - w San Francisco. Ale można mieć dostęp poprzez sieć do konta w Los Angeles, będąc w San Francisco i odwrotnie.

Wady

Złożność jest pod względem technicznym jest największą wadą rozproszonych systemów baz danych.

Przykładowe systemy

prototypy:

SDD-1 (zbudowany w dziale badań Computer Corporation of America w późnych latach siedemdziesiątych

R* (R star, rozpowszechniona wersja prototypu R, zbudowana przez IBM Research we wczesnych latach osiemdziesiątych

Distributed INGRES (rozpowszechniona wersja prototypu INGRES, zbudowana we wczesnych latach osiemdziesiątych na Univeristy of California at Berkley

Większość współczesnych systemów relacyjnych oferuje jakieś wsparcie dla rozproszonych baz banych

INGRES/STAR - produkt The ASK Group INC. Ingres Division

opcja rozproszonenej bazy danych w ORACLE 7

narzędzie do danych rozproszonych DB2 firmy IBM

Podstawowa zasada

Dla uzytkownika system rozproszony powienien wyklądać dokładnie tak samo jak zwykły system.

Innymi słowy, uzytkownicy systemu rozproszonego powinni zachowywać się dokładnie tak samo, jakby system nie był rozproszony. Wszystkie problemy związane z rozproszeniem są lub powinny być problemami na poziomie wewnętrznym lub implementacji, a nie na poziomie zewnętrznym lub użytkownika (osoba operująca danymi)

Cele tworzenia rozproszonej bazy danych:

1. Lokalna autonomia

2. Brak uzależnienia od centralnego miejsca

3. Działanie ciągłe

4. Niezależność od lokalizacji

5. Niezależność od fragmentacji

6. Niezależność od replikacji

7. Rozproszone przetwarzanie zapytania

8. Rozproszone zarządzanie transakcjami

9. Niezależność sprzętowa

10. Niezależność od systemu operacyjnego

11. Niezależność od sieci

12. Niezależność od DBMS

1. Wszystkie operacje dokonywane w danym miejscu są kontrolowane z tego miejsca. Pomyślne działanie jakiegoś węzła X nie powinno zależeć od jakiegoś innego węzłą Y. Dane lokalne są zarządzane lokalnie, ich właścieciel jest lokalny i lokalnie może je przetwarzać. Wszystkie dane „naprawdę” należą do pewnej lokalnej bazy danych, nawet jeżeli jest ona dostępna z innych, odległych miejsc. Sprawy takie jak bezpieczeństwo, integralność oraz reprezentacja w pamięci trwałej danych lokalnych pozostają pod kontrolą lokalnego węzła.
   

2. Wszystke miejsca musza być traktowane równo. Nie może być zatem żadnego uzależnienia od centralnego „głównego” miejsca, realizującego centralne usługi.

Uzależnienie od centralnego węzła byłoby nieporządane z prznajmniej dwóch względów:

• centralne miejsce mogłoby stanowić wąskie gardło całej bazy

• system byłby osłabiony - gdyby centralne miejsce uległo awarii, wówczas cały system by przestał działać
  
  

3. Systemy rozproszone dają zwiększona niezawodność i zwiększona dostępność.

- niezawodność: systemy mogą działać nawet jesli jakiś pojedyńczy składnik ulegnie awarii

- dostępność: istnieje możliwośc replikacji danych

4. Użytkownicy nie powinni wiedzieć, gdzie dane sa przechowywane fizycznie, natomiast powinni móc zachowywac sie tak jakby wszystkie dane były przechowywane na ich lokalym stanowisku. Niezależność od lokalizajcji jest pożądana, ponieważ upraszcza ona czynności programów użytkownika i prace z terminalem. W szczególności umożliwia migrację danych z miejsca na miejsce nie naruszając tych programów ani czynności terminalowych.
   
   

5. System umozliwia fragmentacje danych, jeżeli można podzielić daną relację pamiętną na kawałki czy „fragmenty” w celu przechowywania w pamięci fizycznej. Fragmentacja jest wskazana ze względu na wydaność. Można przechowywać dane w tych miejscach, w których są one najczęściej używane. Dzięki temu większość operacji będzie lokalnych, a ruch w sieci spadnie. Uzytkownicy powinni miec możliwośc takiej pracy jakby dane wcale nie były fragmentowane, otrzymują oni obraz danych, w których fragmenty sa logicznie ze sobą połączone za pomoca odpowiednich złączeń i sum.
   
   

6. System umożliwia replikację danych, jeżeli dana zapamiętana relacja - lub fragment ogólnej - może być reprezentowana w wielu różnych kopiach (replikach) przechowywanych w wielu różnych miejscach.

Replikacja jest wskazana z przynajmniej dwóch powodów:

- lepsza wydajność - aplikacje mogą operować na lokalnych kopiach zamiast sięgać do odległych miejsc

- lepsza dostęoność - dany powielony obiek jest dostępny tak długo, jak pozostaje dostępna chociaż jedna kopia, przynajmniej do celów wyszukiwania danych

Użytkownicy powinni móc tak działać, jakby dane wcale nie były wcale powielone. Niezależność od replikacji upraszcza programy użytkownika i pracę przy terinalu.

7. Systemy relacyjne mają nawet o rzędy wielkości lepszą wydajność niż nierelacyjne.

Pokażmy to na przykładzie rozważając zapytanie: „Znajdź dostawców mających siedzibę w Londynie i dostarczających czerwone części”. Warunki te spełnia n dostawców. Użytkownik znajduje się w Nowym Jorku, a dane sa przechowywane w Londynie. W systemie relacyjnym zapytanie spowoduje przesłanie dwóch komunikatów:

- wysłanie zapytania z Nowego Jorku do Londynu

- przekazanie zbioru wynikowego n krotek z Londynu do Nowego Jorku

Gdyby system nie był relacyjny wówczas zapytanie wymagało by przesłannia 2n komunikatów:

- n razy z Nowego Jorku do Londynu żądających następnego dostawcy

- n komunikatów z Londynu do Nowego Jorku zwracających tych dostawców

W systemach rozproszonych optymaizacja jest jeszcze ważniejsza niż w scentralizowanych. Główna sprawa wiąże się z ruchem w sieci. W zapytaniu takim jak powyższe, może być wiele wariantów przesyłania danych zmierzających do realizacji żądania, zatem bardzon ważne jest znalezienie właściwej strategii. Może to zmienić czas ospowiedzi z szeciu godzin do jednej dziesiatej sekundy. Dlatego właśnie systemy rozproszone są zawsze relacyjne - żądania sformułowane na poziomie zbiorów można zawsze optymalizować, a na poziomie rekordów nie można.

8. Zarzadzanie transakcjami ma dwa ważne aspekty:

- kontrolę odtwarzania

- kontrolę współbierzności

Kazdy z nich wymaga specjalnego podejścia w środowisku rozproszonym.

Aby to wyjaśnic musimy wprowadzić pojęcie „agent”

W systemie rozproszonym pojedyńcza transakcja może obejmować wykonywanie programu i aktualizacje w wielu miejscach jednocześnie. Mówimy, że transakcja składa się z wielu agentów, gdzie agentem jest proces prowadzony w ramach danej transakcji w określonym miejscu. System musi wiedzieć, czy dwa takie procesy są częścią tej samej transakcji. Nie można na przykład pozwolić, aby dwóch agentów z tej samej transakcji założyło na siebie wzajemną blokadę.

Kontrola odtwarzania

Chcąc zagwarantować, aby dana transakcja w systemie rozproszonym była atomowa, system musi sprawdzić, żeby wszystkie pojedyńcze procesy związane z tą transakcją jednocześnie wykonywały alno jej zatwierdzanie, albo wycofanie. Można to osiagnąć, stosując protokół dwufazowego zatwierdzania.

Kontrola współnierzności

Jest oparta w większości systemów rozproszonych na blokowaniu, podobnie jak to było w przypadku zwykłych systemów.

9. W zasadzie niewiele można dodać ponad to, co mówi tutuł tego punktu. Pożądana jest mozliwość korzystania z tego samego DBMS na różnych platformach sprzętowych i zmuszenia ich do partnerskiej współpracy w jednym systemie rozproszonym. Nie jest tutaj ważne na jakim sprzęcie się pracuje.

10. Ten cel jest częściowo wnioskiem z poprzedniego i także nie wymaga szrszej dyskusji. Stosuje sie ten sam DBMS e środowiskach rozmaitych systemów operacyjnych. Dotyczy to również różych systemów operacyjnych na tym samym sprzęcie.
    
    

11. Jeżeli system ma wspieraćróżnorodne węzły, z różnorodnym sprzętem i rozmaitymi systemami operacyjnymi to oczywiste jest to, że powinien móc współdziałać z różnymi sieciami komputerowymi.

12. Potrzebujemy tego jedynie po to alby instalacje DBMS w różnych miejscach umożliwiły korzystanie z tego samego interfejsu. Nie musza być one kopiami trgo samego oprogramowania. Np. Jeśli zarówno INGRES i ORACLE wspierają oficjalny standard języka SQL, to łatwo można sobie wyobrazić, że miejsce z INGRESEM komunikuje się z miejscem z bazą ORACLE w środowisku rozproszonym. System rozproszony może byc więc do pewnego stopnia heterogeniczny.

Problemy związane z systemami rozproszonymi

Głownym problemem jest siec komunikacyjna. Podstawowym zadaniem w systemach rozproszonych jest zwykłe minimalne wykorzystanie sieci. Zadanie to pociąga za soba inne problemy, takie jak np:

• przetwarzanie zapytań

• zarządzanie katalogami

• przekazywanie aktualizacji

• kontrola odtwarzania

• kontrola współbieżności

Przetwarzanie zapytań

Optymalizacja wykorzystania sieci wymaga, aby sam proces optymalizacji był rozproszony, podobnie jak proces realizacji zapytania. Proces ten składa się przeważnie z dwóch części - optymalizacji globalnej oraz zachodzacej po niej optymalizacji lokalnej. Optymalizacje lokalną przeprowadza się na każdym stanowisku zaangażowanym w realizację zapytania.

• Istnieje kilka strategii przetwarzania zapytania. Każda z nich jest rozwiązaniem problemu, jednak rozpiętość całkowitych czasów przesyłania danych jest ogromna. Najwolniejsza technika jest dwa miiliony razy wolniejsza niż najszybsza.

• W wyborze odpowiedniej strategii są ważne zarówno szybkość transmisji jak i czas dostępu.

• Czasy obliczeń i operacji we-wy będą w przypadku złych strategii bardzo małe w porównaniu z czasami transmisjii. ( w przypadku lepszych strategii może być różnie)

Zarządzanie katalogiem

W systemach rozproszonych katalog systemowy obejmuje nie tylko zwykły katalog danych dotyczący realizacji bazowych, perpektyw, indeksów, użytkowników itd., ale także kompletną informacje kontrolną, umożliwiająca systemowi uzyskanie wymaganej niezależności od lokalizacji, fragmentacji i replikacji.Pojawia się pytanie: Grzie i jak powinien być przechowywany sam katalog? Jest kilka możliwości.

Miejsca i sposoby przechowywania katalogu.

1. Centralnie. Cały katalog jest przechowywany w dokładnie jednym, centralnym miejscu.

2. Pełna replikacja. Kompletny katalog jest przechowywany w całości w każdym więźle.

3. Podział. W każdym więźle znajduje się część katalogu związana z obiekatami tam przechowywanymi. Kompletny katalog jest sumą tych wszytskich rozłączonych katalogów lokalnych.

4. Kombinacja wariantu 1 i 3. W każdym miejscu utrzymuje sie lokalny katalog, tak jak w wariancie 3. Dodatkowo jedno centralne miejsce przechowywuje ujednoliconą kopię wszytskich lokalnych katalogów, tak jak w wariancie 1.

W każdym wariantem wiążą się prblemy. Podejscie pierwsze narusza cel „brak uzaleznienia od centralnego węzła”. W drugim wariancie autonomia jest poważnie naruszona, ponieważ każda aktualizacja katalogu musi byc rozsyłana do wszytskich miejsc. W podejciu 3 aktualizacje lokalne będą bardzo kosztowne, ponieważ znalezienie obiektu w winnym więźle będzie ywmagało dostępu średnio do połowy miejsc. Podejście 4 jest bardziej wydajne niż 3 (znalezienie obiektu na innym miejscu wymaga tylko jednego zdalnego dostępu do katalogu), jednak narusza znów „brak uzależnienia od centralnego węzła”

Przekazywanie aktualizacji

Zasadniczy problem z replikacja danych polega na tym, że trzeba przekazywać aktualizację dowolnego obiektu do wszystkich jego przechowywanych kopii. Pojawia się natychmiast trudność z tym, że któreś z miejsc przechowywania kopii obiektu może być niedostępne w czasie aktualizacji (np. Z powodu awarii sieci lub komputera). Nie można zastosować oczywistej strategii natychmiastowego przekazywania aktualizacji, ponieważ znaczyłoby to, że transakcja zakończy się niepomyslnie za każdym razem, gdy choćby jedna kopia nie będzie dotępna.

Zwykły sposób postępowania: schemat z kopią pierwotna.

• Jedna z kopii powielonego obiektu oznacza sie jako kopię pierwotną. Pozostałe kopie to kopie wtórne.

• Kopie pierwotne różnych obiektów sa przechowywane w różnych miejscach ( jest to zatem schemat rozproszony)

• Uważa się, że operacja jest zakończona z logicznego punktu widzenia, jeżeli sie zakończyła aktualizacja kopii pierwotnej. Miejsce przecgowujące tę kopię odpowiada za późniejsze przekazywanie aktualizacji do kopii wrórnych.

Oczywiści sam ten schemat rodzi dalsze problemy. Zauważmy, że schemat taki narusza wymaganie lokalnej autonomii, ponieważ transakcja może się nie udać, kiedy niedostępna jest odległą kopia jakiegoś obiektu, nawet jesli lokalna kopia jest do dyspozycji.

Kontrola odtwarzania

Przeważnie opiera się na protokole dwufazowego zatwierdzenia. Dwufazowe zatwierdzanie jest konieczne w każdym środowisku, w którum pojedyńcza transakcja może oddziaływać z kilkoma autonomicznymi menadżerami zasobów.

• Proces dwufazowego zatwierdzenia wymaga aby koordynator komunikował się z każdym miejscem uczestniczącym. Oznacza to więcej przesyłania danych i większe obciążenie dodatkowe.

• Cel sformułowany jako „brak uzależnienia od centralnego miejsca” sprawia, że nie można przypisywać funkcji koordynatora do jednego więzła w sieci. Musi byc ona realizowana dla dla różnych transakcji przez różne więzły. Zwykle pełni ją to miejsce, gdzie dana transakcja sie rozpoczęła. Każde miejsce powinno więc działać jako miejesce koordynatora do jednych transakcji, jako zaś uczestnik dla innych.

Kontrola współbieżności

Kontrola współbieżności w wiekszości systemów rozproszonych opiera sie na blokowaniu , tak jak w zwykłych systemach. W systemach rozproszonych jednak wszelkie żądanie sprawdzania, ustawiania i zwalniania blokad stają się komunikatami. (zakładając, że rozważany obiekt znajduje się w odległym miejscu) Przesyłanie komunikatów oznacza dodatkowe obciążenie systemu. Innym problem z blokowaniem w systemach rozproszonych polega na tym, że może ono prowadzić do pełnego zakleszczenia. Wykrywanie pełnych zeszkleń prowadzi do dalszego zwiększenia wymagań co do komunikatów.

Systemy klient-serwer

Systemy klient serwer można uważać za prosty przypadek szczególny systemów rozproszonych. System klient-serwer jest systemem rozproszonym, w którym:

1. pewne miejsca są miejscami klientów, a inne miejscami serwerów

2. wszystkie dane znajdują się w miejsach serwerów

3. wszystkie aplikacje są wykonywane w miejsach klientów

4. widać połączenia (czyli nie ma pełnej niezależności od lokalizacji)

Przypomnijmy, że określenie „klient-serwer” odnosi sę przede wszystkim do architektury lub logicznego podziału obowizków.

Klient jest to aplikacja, serwer jest to zas DBMS.

Cały system da się ładnie podzielić na dwie części, pojawia się możliwośc posadowienia go na róznych komputerach. Jest to tak atrakcyjna okazja, że termin „klient-serwer” stosuje sie prawie wyłącznie do przypadku, kiedy klient i serwer rzeczywiście sa umieszczeni na różnych maszynach.

Możliwe warianty systemu „klient-serwer”

1. Kilku klientów korzysta z tego samego serwera. (jest to zwykły przyadek)

2. Pojedyńczy klient ma dostęp do kilku serwerów. Są tu swie możliwości.

- Klient może mieć dostęp tylko do jednego serwera jednocześnie - każde zapytanie skierowane do bazy musi iśc do tylko jednego serwera. Nie można, za pomocą jednego zapytania, zebrać danych z dwóch lub więcej serwerów. Ponadto, uzytkownik musi wiedzieć, który serwer przechowuje takie dane.

- Klient może mieć jednoczesny dostęp do wielu serwerów. Pojedyńcze zapytanie może zbierac dane z kilku serwerów. Srwery, z punktu widzenia uzytkownika, zachowują się jak jeden serwer. Użytkownik nie musi wiedzieć, który serwer przechowuje jakie dane.

Ostatni przypadek oznacza praktycznie prawdziwy system rozproszonej bazy danych gdzie połączenia są ukryte. Nie jest to sytuacja powszechnie uważana za układ klient-serwer.

---