Wykład 4 Wojciech Pieprzyca Systemy Baz Danych Wykład 4 Wojciech Pieprzyca

Bazy scentralizowane Baza scentralizowana – tradycyjne, najprostsze podejście - wszystkie dane znajdują się na jednym serwerze. Wady takiego rozwiązania: Przy dużej liczbie operacji/zapytań realizowanych przez serwer czas oczekiwania na wynik jest znaczący i może powodować widoczne dla użytkownika opóźnienia w działaniu systemu bazodanowego. Jeżeli mamy do czynienia z organizacją posiadającą oddziały w różnych regionach geograficznych to baza scentralizowana w żaden sposób nie odzwierciedla takiego rozproszenia, gdyż wszystkie dane przechowywane są w tym samym miejscu, bez względu na miejsce pochodzenia.

Bazy scentralizowane Możliwe jest także występowanie opóźnień czasowych wynikających z czasu transferu danych pomiędzy serwerem bazodanowym a odległym węzłem sieciowym (klientem oczekującym na wynik operacji). Przykładem bazy scentralizowanej może być baza przechowująca numery PESEL i informacje personale wszystkich obywateli Polski wykorzystywana np. przez urzędy i inne instytucje państwowe.

Bazy rozproszone Baza rozproszona – to zbiór lokalnych baz, umieszczonych zazwyczaj na różnych serwerach i w różnych miejscach. Taka baza musi jednak stanowić całość w sensie modelu danych i koordynacji wykonywanych transakcji. Dwie możliwości rozproszenia danych: - fragmentacja danych – w lokalnej bazie przechowywany jest podzbiór (część) wszystkich danych. Dopiero połączenie wszystkich fragmentów z lokalnych baz danych daje nam w takim przypadku obraz całej bazy danych. - replikacja danych – kopia całości lub części bazy danych przechowywana w innym miejscu niż oryginalna baza danych.

Bazy rozproszone Przykładem bazy rozproszonej może być baza dla firmy ubezpieczeniowej posiadającej oddziały w całej Polsce. Można wyobrazić sobie powstanie 4 odrębnych terytorialnie miejsc przechowywania danych np.: - Gdańsk – dane dotyczące obszaru Polski północnej, - Wrocław – dane dotyczące obszaru Polski zachodniej, - Rzeszów – dane dotyczące obszaru Polski wschodniej, - Katowice – dane dotyczące obszaru Polski południowej. Okresowo dane te mogą być zbierane razem w celu utworzenia np. statystyk dotyczących działalności firmy na terenie całej Polski.

Fragmentacja pozioma Fragmentacja pozioma – podzbiór (część) wierszy z tabeli np. dane z jednego rejonu kraju. Taki rodzaj fragmentacji uzyskuje się poprzez zastosowanie odpowiedniego polecenia selekcji danych np. dla określonego rejonu działalności firmy: (1)select * from pracownicy where wojewodztwo=”Śląskie” or województwo=”Małopolskie” (2) select * from pracownicy where wojewodztwo=”Dolnośląskie” or wojewodztwo=”Opolskie” … (N) select …

Fragmentacja pozioma Odtworzenie oryginalnej bazy będzie polegało na zsumowaniu wyników z poszczególnych fragmentów bazy np. select * from pracownicy where wojewodztwo=”Śląskie” or wojewodztwo=”Małopolskie” union select * from pracownicy where wojewodztwo=”Dolnośląskie” or wojewodztwo=”Opolskie” … select …

Fragmentacja pionowa Fragmentacja pionowa – podzbiór (część) kolumn z tabeli np. id_klienta, data_urodzenia, placa. (1)select id_pracownika, data_urodzenia, placa from pracownicy; (2)select id_pracownika, imie, nazwisko, ulica, miasto, kod, wojewodztwo from pracownicy; Odtworzenie oryginalnej bazy będzie polegało na zastosowaniu złączenia w oparciu o wartości klucza głównego (w powyższym przykładzie jest to pole id_pracownika). select id_klienta, data_urodzenia, placa, imie, nazwisko, ulica, miasto, kod, województwo from pracownicy1 p1, pracownicy2 p2 where p1.id_pracownika = p2.id_pracownika;

Przeźroczystość Finalny użytkownik nie powinien odczuwać różnicy czy pracuje na bazie scentralizowanej czy też bazie rozproszonej. Oznacza to, że muszą być spełnione 3 właściwości przeźroczystości: przeźroczystość geograficzna – użytkownicy nie muszą wiedzieć, na którym serwerze (w jakim miejscu) znajdują się przechowywane dane, które przeglądają lub modyfikują. przeźroczystość fragmentacji – użytkownicy nie muszą wiedzieć, w jaki sposób dane są podzielone. Powinna istnieć możliwość operowania na bazie jako jednej całości. przeźroczystość replikacji – użytkownicy nie muszą wiedzieć, w jaki sposób dane są replikowane i z której repliki pochodzą dane, które przeglądają lub modyfikują.

Zalety rozproszonych BD Zalety rozproszonych baz danych: zwiększona niezawodność systemu poprzez replikację danych w różnych miejscach, odwzorowanie geograficznego podziału organizacji, dostęp do danych może być determinowany poprzez miejsce dostępu np. możliwość modyfikacji danych dla obszaru Polski południowej tylko poprzez pracowników jednostki Katowice, itp. zwiększenie szybkości działania systemu, jeżeli zapytania w lokalnym oddziale będą dotyczyć bazy znajdującej się najbliżej (lokalnej).

System zarządzania RBD System zarządzania rozproszoną bazą danych Katalog tabel systemowych jest bardziej skomplikowany, konieczne jest przechowywanie informacji np. o położeniu fragmentów i replik tabel. Zwiększają się problemy związane ze współbieżnym dostępem do danych np. aktualizacja danych pociąga za sobą konieczność dokonania zmian w kilku różnych miejscach. Trudno jest spełnić warunek, aby wszyscy użytkownicy w jednym czasie (obojętnie skąd się logują) widzieli te same dane.

System zarządzania RBD System zarządzania rozproszoną bazą danych Optymalizator zapytań w procesie optymalizacji dla bazy rozproszonej musi brać pod uwagę także topograficzne położenie danych i koszt czasowy przesyłu danych z danego węzła sieci. Nie tylko dane mogą być rozproszone, ale również sam system zarządzania bazą danych może znajdować się w różnych miejscach np. w celu podniesienia odporności na awarie głównego serwera.

Zapytania do RBD select avg(pensja) from pracownicy pr, pensje pe where pr.id_pracownika = pe.id_pracownika and nr_dzialu > 5 and nr_dzialu < 10 and data_wypl=’2007-02-01’ 1) W przypadku wystąpienia fragmentacji poziomej: załóżmy, że dane dotyczące działów 1-7 umieszczone są w Krakowie, a dane dotyczące działów 8-14 znajdują się w Warszawie. W celu wykonania powyższego zapytania SZBD będzie musiał obliczyć w każdym z węzłów osobno sumę wartości pensji SUM(pensja) oraz ich liczbę COUNT(pensja), i dopiero na tej podstawie stworzy informacje o średniej pensji.

Zapytania do RBD SUM(pensja) COUNT(pensja) Kraków 134500 50 Warszawa 233100 60 AVG(pensja) = (134500+233100)/(50+60) = 3341,81 2) W przypadku wystąpienia fragmentacji pionowej: Załóżmy, że tabela pracownicy znajdują się w Krakowie, a tabela pensje w Warszawie. Wykonanie powyższego zapytania wymagało będzie sprowadzenia danych z obu tabel do jednego węzła i wykonania zapytania na tak stworzonych danych tymczasowych. KRAKÓW (pracownicy) WARSZAWA (pensje) WARSZAWA (pracownicy, pensje=>tmp)–złączenie tabel

Zapytania do RBD 3) W przypadku wystąpienia replikacji Jeżeli wszystkie dane są zreplikowane w dwóch oddziałach np. Warszawa i Kraków, to wybór tego skąd zostaną one fizycznie pobrane będzie uzależniony od optymalizatora zapytań, który zbada, z której replikacji dane mogą zostać szybciej pobrane.

Synchronizacja replik Metody synchronizacji replik: synchroniczna replikacja – transakcja modyfikująca dane nie jest zatwierdzana do momentu propagacji zmian we wszystkich węzłach w których znajdują się repliki. Dzięki temu wynik odczytu z tabel różnych replik jest zawsze taki sam. asynchroniczna replikacja – transakcja jest zatwierdzana natychmiast po modyfikacji danych w danej replice, a pozostałe repliki są aktualizowane tylko okresowo. Jest to metoda szybsza, która zażywa mniej zasobów, jednak powoduje, że okresowo dane w tabelach różnych replik mogą się różnić.