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

12 reguł RBD (Christopher Date) 1) Lokalna autonomia - każdy węzeł należący do rozproszonej bazy danych jest zarządzany (administrowany) niezależnie od pozostałych węzłów, - wszystkie operacje na danych w węźle są kontrolowane przez ten węzeł, - działanie węzła X nie powinno zależeć od działania innych węzłów, - na każdym węźle działa niezależny system zarządzania bazą danych.

12 reguł RBD (Christopher Date) 2) Uniezależnienie od centralnego miejsca - wszystkie węzły systemu rozproszonej bazy danych są traktowane jednakowo i nie ma wyróżnionego węzła oferującego usługi dla pozostałych węzłów, np. przetwarzania zapytań (brak możliwości wystąpienia wąskiego gardła).

12 reguł RBD (Christopher Date) 3) Działanie ciągłe - awaria jednego węzła nie wpływa na pracę innych węzłów (jest to zagwarantowane przez autonomię węzłów), - dzięki zastosowaniu mechanizmu replikowania danych do wielu węzłów, inny węzeł może udostępnić replikę oryginalnych danych w przypadku awarii węzła przechowującego dane oryginalne.

12 reguł RBD (Christopher Date) 4) Niezależność lokalizacji - sposób dostępu do danych przechowywanych w węzłach systemu powinien być jednakowy, niezależny od fizycznego umiejscowienia danych i niezależny od ich fizycznego sposobu składowania. - system powinien zapewniać tzw. przezroczystość lokalizacji (ang. location transparency), czyli ukrywać przed użytkownikiem fizyczne miejsce składowania danych.

12 reguł RBD (Christopher Date) 5) Niezależność fragmentacji - dane, np. tabelę lub indeks, można dzielić na fragmenty, - każdy fragment można niezależnie umieścić w innym węźle systemu, - użytkownik nie powinien być świadomym fizycznej lokalizacji fragmentów, - dostęp do fragmentów powinien być jednakowy, niezależny od lokalizacji.

12 reguł RBD (Christopher Date) 6) Replikacja - tworzenie kopii danych pochodzących z jednego węzła w innym węźle. Użytkownik może operować w taki sam sposób na danych oryginalnych (źródłowych), jak i na kopii danych.

12 reguł RBD (Christopher Date) 7) Niezależność sprzętowa - ten sam system zarządzania bazą danych (pochodzący od jednego producenta, w jednej wersji) może zostać zainstalowany na różnych platformach sprzętowych, z których każda stanowi osobny węzeł. SZBD działający na różnych platformach sprzętowych może wejść w skład tego samego systemu RBD.

12 reguł RBD (Christopher Date) 8) Niezależność od systemu operacyjnego - ten sam system zarządzania bazą danych (pochodzący od jednego producenta, w jednej wersji) może zostać zainstalowany w różnych systemach operacyjnych i może wejść w skład tego samego systemu RBD.

12 reguł RBD (Christopher Date) 9) Niezależność od SZBD - w skład systemu RBD mogą wchodzić bazy danych zarządzane przez różne systemy zarządzania bazami danych, np. Oracle10g, IBM DB2, MS SQLServer2005. - sposób dostępu do tych baz danych powinien być jednolity. Oznacza to, że każdy z SZBD powinien dostarczać jednolity i ustandaryzowany interfejs dostępu do bazy danych.

12 reguł RBD (Christopher Date) 10) Niezależność od sieci - system RBD powinien pracować w różnych architekturach sieciowych i z różnymi protokołami sieciowymi. - dostęp do poszczególnych węzłów powinien być jednolity i niezależny od architektury sieciowej i niezależny od wykorzystywanych protokołów sieciowych.

12 reguł RBD (Christopher Date) 11) Rozproszone zarządzanie transakcjami - w systemie RBD można realizować transakcje rozproszone. Transakcja rozproszona odwołuje się do wielu węzłów systemu. W przypadku tego typu transakcji system RBD powinien zagwarantować cztery cechy transakcji rozproszonej, tzn. jej trwałość, spójność, atomowość i izolację, podobnie jak w przypadku standardowych transakcji scentralizowanych.

12 reguł RBD (Christopher Date) 12) Rozproszone przetwarzanie zapytań - możliwość wykonania zapytania, które adresuje jednocześnie wiele węzłów systemu RBD. W takim przypadku, system powinien zagwarantować optymalny sposób wykonania takiego zapytania, zgodnie z przyjętym kryterium kosztu wykonania.

RBD w Oracle Rozproszone bazy danych w SZBD Oracle Oracle dostarcza specjalnego oprogramowania Oracle Net, które umożliwia komunikację sieciową pomiędzy bazami danych Oracle oraz zarządzanie rozproszonymi transakcjami dotyczącymi wielu różnych baz danych. Oprogramowanie Oracle Net wykorzystuje dwa rodzaje obiektów: powiązania z bazą danych (database link) – jest to ścieżka sieciowa do odległej bazy danych, migawki, perspektywy zmaterializowane (snapshot, materialized view) – lokalna kopia (replika) danych znajdujących się z jednej lub kilku odległych bazach danych. Taka migawka jest perspektywą odświeżaną co określony interwał czasu, dlatego dane w niej mogą nie być w pełni aktualne.

RBD w Oracle Tworzenie powiązań z bazą danych Składnia polecenia: CREATE DATABASE LINK name CONNECT TO user IDENTIFIED BY password USING ‘alias’; Powiązanie umożliwia dostęp do odległej bazy na prawach określonego użytkownika. Alias to nazwa bazy danych do której chcemy uzyskać połączenie. Przykład: CREATE DATABASE LINK krakow CONNECT TO wojtek IDENTIFIED BY tajnehaslo123 USING ‘bazakrakow’;

RBD w Oracle Po utworzeniu połączenia można korzystać z tabel w odległym węźle tak jak ze zwyczajnych, lokalnych tabel. Jedyna różnica polega na dołączeniu do nazwy tabeli ciągu @name np. osoby@krakow. select * from osoby@krakow; Aby nie trzeba było stosować specjalnych nazwa dla tabel z odległych węzłów można stworzyć odpowiednie synonimy np. CREATE SYNONYM osoby FOR osoby@krakow; select * from osoby;

RBD w Oracle Tworzenie migawek CREATE SNAPSHOT name REFRESH NEXT interval AS query; interval – określa co jaki czas migawka będzie odświeżana query – określa zapytanie, które będzie tworzyło zawartość migawki i które jest wywoływane przy każdym odświeżeniu migawki

RBD w Oracle Przykład: CREATE SNAPSHOT wszyscy_pracownicy REFRESH NEXT Sysdate+1 AS SELECT * FROM pracownicy@krakow UNION SELECT * FROM pracownicy@warszawa SELECT * FROM pracownicy@wroclaw Powyższe zapytanie tworzy migawkę o pracownikach z 3 oddziałów firm – Kraków, Warszawa oraz Wrocław. Migawka ta odświeżana jest raz na dzień (Sysdate+1). Do migawki można odwołać się poprzez polecenie select np. select imie,nazwisko from wszyscy_pracownicy;

RBD w Oracle Implementacja migawki w lokalnej bazie danych Dla każdej migawki w lokalnej bazie danych powstają 3 obiekty: tabela do której zapisywany jest wynik otrzymanego zapytania z migawki, indeks dla klucza głównego wcześniej utworzonej tabeli, perspektywa służąca do wyświetlania i używania zawartości migawki.

RBD w Oracle Migawka modyfikowalna Aby można było dokonywać modyfikacji (polecenia insert,update,delete) na danych z migawki należy dodać do polecenia tworzącego migawkę klauzulę FOR UPDATE np. CREATE SNAPSHOT wszyscy_pracownicy REFRESH NEXT Sysdate+1 FOR UPDATE AS SELECT * FROM pracownicy@krakow UNION SELECT * FROM pracownicy@warszawa SELECT * FROM pracownicy@wroclaw update wszyscy_pracownicy set nazwisko=’Kowalski’ where id_pracownika=10013