Rozproszone b. d.
System rozproszonej bazy danych jest t taki system b. d., w którym dane są rozłożone do różnych konfiguracji sprzętowych i programowych, na ogół rozmieszczonych w różnych geograficznie miejscach organizacji, do której została.
Zasadniczym celem rozproszonej b. d. jest, aby użytkownik widział b. d. jako scentralizowaną. Powinna ona być przeźroczysta (rodzaje przeźroczystości: geograficzna, fragmentaryzacji, replikacji.
Rozłożenie b. d. realizuje się poprzez:
· Fragmentaryzację – utrzymywanie podzbiorów wszystkich danych (fragmentów danych). Fragmentaryzacja może być realizowana poziomo (podzbiór wierszy), lub pionowo (podzbiór kolumn).,
· Replikację – utrzymywanie kopii całości lub części danych przechowywanych w b. d. Jednym z głównych celów replikacji jest zmniejszenie kosztu dostępu do bazy danych.
O rozproszeniu można też mówić w stosunku do funkcji realizowanych przez b. d. Na przykład w systemie typu klient-serwer mamy do czynienia z rozproszeniem funkcji, ale na ogół nie mamy rozproszenia danych. System klient-serwer, gdzie dane nie są rozproszone, nie jest rozproszony. Taki system to scentralizowana b. d..
Typy systemów rozproszonych baz danych:
1) jednorodna b. d. – składa się z wielu serwerów obsługujących wielu klientów, połączenia i odległości pomiędzy elementami systemu realizowane są przez odległe łącza. Zawsze opieramy się na tym samym rodzaju systemu zarządzania b. d.. Takie systemy są realizowane na tego samego rodzaju sprzęcie,
2) niejednorodna b. d. – są to takie bazy, które zrealizowane są na różnych platformach sprzętowych i programowych, np. w 1 węźle VAGS i Oracle, w 2 VAGS i Inges, a w 3 IBM i BD2. Aktualnie są realizowane przez łącza typu Gateway. Problemy z zarządzaniem są dość duże. Połączenia są realizowane na bieżąco.
3) Federacyjny system b. d.- przypominają federację w sensie politycznym, składają się z pewnej liczby autonomicznych baz danych, czasami się je scala do wykonywania jakichś funkcji. Są to funkcje trudne do przewidzenia. Podejście do tych systemów jest takie, by produkty tych systemów były jak najbardziej otwarte.
Przykłady systemów rozproszonych:
1) Systemy bankowe – w oddziałach są systemy obsługująca dany oddział, do wszystkiego ma jednak dostęp centrala. Dane są fragmentami rozmieszczone w oddziałach. Często występuje replikacja.
2) Systemy ewidencji ludności – realizowane w odrębnych miejscach, gdzie istnieją wojewódzkie systemy ewidencji ludności. Większość zadań realizowana jest w stolicach województw, czasami jest jednak realizowane zadanie dla całego kraju, np. wiąże się ono z nadaniem numeru pesel.
Mimo faktu, że rozproszona b. d. wymaga wielu dodatkowych mechanizmów takich jak np. zabezpieczanie, istnieje wiele ich zalet:
· Gdy organizacja ma charakter rozproszony, to rozproszony system b. d. jest dla nich bardziej odpowiedni niż system scentralizowany,
· Gdy organizacja jest rozproszona geograficznie to mamy większą kontrolę nad danymi w miejscu przechowywania tych danych,
· Replikacja danych zwiększa niezawodność systemu, nawet gdy jest realizowana w innym oddziale,
· Działanie systemu b. d. może być istotnie poprawione, jeżeli się dokona prawidłowego rozproszenia danych.
Odnoszą się najczęściej do lokalnych sieci komputerowych. Często mylnie są traktowane jako systemy rozproszone. Przynajmniej jeden serwer jest przeznaczony do spełniania funkcji b. d. dla pozostałych komputerów, które działają jako klienci.
Baza danych przechowywana jest na serwerze. Tu znajdują się także funkcje obsługi b. d.. Na komputerach klientów znajdują się interfejsy użytkowników oraz narzędzia do tworzenia aplikacji bazodanowej.
Serwery b. d. spełniają dwie funkcje:
A) serwer plików – zapytania są wyrażane przez klienta w jego aplikacji, są one interpretowane. Określa się dla nich na jakich plikach będą realizowane operacje do tego zapytania. Pliki te są udostępniane przez serwer plików.
B) Serwer SQL – lepsze z punktu widzenia użytkowników. Zapytania zgodne z SQL wydane z komputera klienta jest wysłane bezpośrednio do serwera SQL. Serwer je wykonuje i w odpowiedzi wysyła do aplikacji tylko wynik operacji zapytania. System oparty na serwerze SQL pozwala wytwarzać systemy otwarte.
W architekturze klient-serwer w oprogramowaniu współdziałają ze sobą dwa procesy: podrzędny i nadrzędny. Proces klienta zaczyna współdziałanie poprzez wysłanie zapotrzebowania (w SQL lub do pliku). Proces serwera na nie reaguje. Serwery SQL lub plików mogą być zaopatrzone w funkcje serwerów pocztowych lub druku.
Każda konwencjonalna aplikacja bazodanowa składa się z 4 części:
1) zarządzanie danymi – funkcje – zarządzanie transakcją, współbieżnością, bezpieczeństwem, przechowywaniem danych.
2) Zarządznie regułami – polega na realizowaniu funkcji zapewniających spójność b. d. (wewnętrzną i zewnętrzną).
3) Logika aplikacji – realizuje funkcje przekształcające dane i zgłaszające zapotrzebowanie na usługi serwera lub zapotrzebowanie na inne oprogramowanie znajdujące się w komputerze.
4) Zarządzanie i logika prezentacji – realizuje funkcje związane z przyjmowaniem i zapotrzebowaniem użytkownika oraz prezentuje użytkownikowi wyszukane dane. Przekształca dane wejściowe do postaci wymaganej przez serwer i odwrotnie – komunikaty serwera do postaci wymaganej przez użytkownika.
W części serwera i klienta musi istnieć oprogramowanie łączące. Jest ono przeźroczystym łącznikiem aplikacji klienta z danymi serwera. Oprogramowanie łączące może być standardowym pakietem lub też produktem danej firmy tworzącej dany SZBD np. oprogramowanie łączące ODBC – standardowe, zwane otwartym łączem z bazami danych. Standard opracowany przez Microsoft na zasadzie interfejsu. ODBC sprowadza się do definiowalnej biblioteki wywołań dostępu do b. d. Umożliwia programiście otworzenie połączenia aplikacji ze środowiskiem b. d. Sprowadzamy dane z b. d. do aplikacji klienta. Program sterownika ODBC odwołuje się do sterowników poszczególnych systemów zarządzania b. d. (DBMS), a te do różnych systemów ZBD.
W przypadku niestandardowym, np. Oracle, modół łączący nosi nazwę SQL*NET ( ODBC jako otwarty może być mniej korzystny przy konkretnym systemie, np. Oracle, jednak w przypadku baz niejednorodnych lepszy będzie ODBC).
Przy projektowaniu systemu Klient-serwer musimy wziąć pod uwagę:
· Na komputerze klienta umieszczać jak najwięcej logiki prezentacji i aplikacji, daje to odciążenie serwera i przyśpieszenie współpracy z użytkownikiem,
· Na komputerze klienta należy umieścić sprawdzanie niektórych reguł poprawności danych wprowadzanych przez użytkownika (odciąża to serwer),
· System musi być tak zaprojektowany, by minimalizować ruch w sieci przez minimalizację liczby i rozmiaru zgłoszeń do serwera,
· Umieszczać sprawdzanie podstawowych reguł poprawności danych, gdy te reguły dotyczące całej organizacji bazodanowej na serwerze, jeżeli są związane z fragmentem, to umieszczać je w logice prezentacji.
Każdy SZBD (nie tylko rozproszony) składa się z trzech części:
1) Jądro - samo jądro z b. d. musi utrzymywać określony model danych. W modelu relacyjnym dane widziane są przez jądro jako tabele.
2) Interfejs DBMS – jest dostosowany do narzędzi i do jądra, jest połączeniem między nimi – przekształca polecenie narzędziowe na polecenie jądra. Najczęściej mają możliwość wytwarzania poprzez kompilację aplikacji w języku jądra.
3) Zestaw narzędzi: języki 4 generacji, języki wytwarzania aplikacji bazodanowej, graficzny interfejs użytkownika, interfejsy języka naturalnego, interfejsy programowe do programowania aplikacji.
Funkcje podstawowe jądra DBMS:
a) organizacja plików – dotyczy sposobu przechowywania danych na urządzeniach zewnętrznych. Sam system przyjmuje jakiś określony model danych. Jądro przekształca ten model w fizyczną reprezentację danych na urządzeniu zewnętrznym. Dla modelu relacyjnego są to najczęściej pliki sekwencyjne o nieuporządkowanej strukturze. Nowe dane dopisywane są na końcu pliku. Bywają także pliki uporządkowane funkcją maskującą. Inne z kolei wykorzystują klastry.
b) Mechanizmy dostępu – sposób zapisu wymaga odpowiednich mechanizmów dostępu do plików. Dla relacyjnych b. d. wyróżnia się techniki oparte na prostym indeksowaniu lub na B-drzewach.
c) Zarządzanie transakcjami – kontrola współbieżności i spójności b. d.
Zarządzanie współbieżnością – ogranicza się do systemu scentralizowanego, opartego na modelu relacyjnym. Podstawowym zadaniem SZBD jest udostępnianie bazy wielu użytkownikom – jest to jedno z najbardziej skomplikowanych zadań jądra. Musimy zapobiegać straconej modyfikacji i innym problemom.
d) zarządzanie słownikami – słownik (katalog systemowy) zawiera pewne informacje ogólne o systemie bazodanowym. Zakładany jest najczęściej w momencie zakładania przez administratora b. d. lub później. Zawiera on grupy użytkowników, ich uprawnienia i hasła dostępu. Mogą być tam opisy relacji (nazwy relacji, typy kolumn), definicje i deklaracje kluczy, definicje perspektyw (podtabel), definicje uprawnień, informacje na temat indeksów i informacji o pliku. Jądro może ten słownik organizować na różny sposób (jeden dla całości przyklejany jako nagłówek do każdego pliku z danymi).
e) Zarządzanie zapytaniami,
f) Sporządzanie kopii i odtwarzanie bazy danych po awarii.
Transakcja – pojedyncze odwołanie się do b. d. To odwołanie może być wykonane z jednego określonego programu do jednego określonego klienta, może być zapytaniem w SQL lub programem skompilowanym z wbudowanym SQL. Może on być wydany z dwóch różnych klienckich stacji.
Podstawową metodą zarządzania współbieżną realizacją transakcji jest tzw. Metoda blokowania – blokując jedną transakcję inna ma dostęp do danych. Zarządzanie transakcjami wymaga więc zarządzania blokadami – jądro przydziela, wykonuje, rejestruje blokady i rozstrzyga konflikty pomiędzy transakcjami podlegającymi blokowaniu. Inne metody to metody optymistyczne. Istnieją różne metody blokowania – zapisu, współdzielone i inne.
Zakładanie blokad polega na sprawdzeniu każdej transakcji zgłaszającej się do jądra czy może być wykonana. Jeżeli tak – to jest wykonywana.
Podstawowym elementem blokowania jest określenie jednostki blokowania – plik, rekord, lub pole w rekordach (rekord najczęściej). Przy małych jednostkach może się wykonywać więcej transakcji jednocześnie.
Problemy:
· Transakcja uwięziona – T1 blokuje, T2 odrzucone(następne sprawdzenie później), w międzyczasie przychodzi T3 i wykonuje się po T1,
· Impas – T1 chce 5 i 6 a ma tylko 5, T2 chce 6 i 5 a ma tylko 6. Problem impasu rozwiązuje się przez dwufazowe blokowanie: w pierwszej fazie następuje blokowanie wszystkich jednostek, w drugiej kolejno wykonywane są operacje i dopiero po ich wykonaniu rekordy są odblokowane.
Gdy transakcja nie może się wykonać to ustawiona jest w kolejce oczekującej na blokowanie.
W jądrach SZBD występują wtedy jeszcze metody sprawdzające czy zbiór transakcji daje się wykonać w sposób poprawny.
wips1