Wykład 14

Rozproszona baza danych

 

Streszczenie

Wykład składa się z trzech części. W pierwszej przedstawione jest pojęcie rozproszonej bazy danych. Omówione zostają jej zalety i wady w porównaniu z konwencjonalną, scentralizowaną bazą danych. Przedstawione jest rozszerzenie algorytmów optymalizacji zapytań i zatwierdzania transakcji na przypadek rozproszonej bazy danych.

W drugiej części wykładu przedstawiona jest implementacja pojęć rozproszonej bazy danych w konkretnym systemie baz danych – Oracle.

W trzeciej części wykładu jest rozważony problem integracji informacji pochodzących z różnych baz danych.
 

14.1 Baza scentralizowana

W sytuacji rozproszenia użytkowników w różnych węzłach sieci internetowej są możliwe różne organizacje bazy danych. Najprostszym rozwiązaniem jest baza scentralizowana, w której dane są przechowywane w jednym węźle sieci. W takim przypadku można utrzymywać jeden centralny system kontroli danych. Przetwarzanie transakcji i odtwarzanie po awarii są objęte sprawdzonymi algorytmami i protokołami. Jeśli kierowane z węzłów sieci do bazy danych transakcje dotyczą wszystkich danych (nie zależą istotnie od samego węzła), wówczas rozwiązanie scentralizowane jest dobre. Przykładem takich systemów mogą być ogólnokrajowe rejestry: podmiotów gospodarczych, podatników, samochodów.

Wady bazy scentralizowanej:

  1. Potencjalnie długi czas oczekiwania na rezultaty z odległego węzła sieci – bardzo długi przy awarii sieci lub centralnego węzła.
  2. Brak kontroli nad danymi specyficznymi dla danego miejsca.
  3. Generowanie dużego ruchu w sieci.

14.2 Baza rozproszona

W przypadku, gdy transakcje w lokalnych węzłach dotyczą na ogół danych lokalnych i stosunkowo rzadko zachodzi potrzeba sięgnięcia do danych dotyczących węzłów odległych, lepszym rozwiązaniem może być zbiór połączonych ze sobą baz lokalnych – z danymi przechowywanymi w węzłach lokalnych.
 

Z rozproszoną bazą danych mamy do czynienia wtedy, gdy zbiór lokalnych baz stanowi całość w sensie jednego modelu danych i koordynacji wykonywanych transakcji.

W rozproszonej bazie danych występuje rozłożenie danych do węzłów sieci poprzez ich fragmentację (podział) lub replikację - do różnych konfiguracji sprzętowych i programistycznych na ogół rozmieszczonych w różnych (geograficznie) miejscach organizacji.

Rozproszona baza danych powinna reprezentować pojedynczy model danych firmy. Przypuśćmy, że tworzymy model danych odzwierciedlający zarządzanie kadrami w pewnej organizacji i projektujemy rozproszoną bazę danych:

Informacje  o strukturze firmy są replikowane i przechowywane w każdym węźle. Zakładamy, że okresowo dane dotyczące wszystkich trzech regionów są zbierane razem, dając obraz całego kraju.

Są dwa typy fragmentacji: pionowa i pozioma.

Fragment poziomy stanowi podzbiór wierszy w tabeli, np. dane z jednego rejonu kraju.

Fragment pionowy stanowi podzbiór kolumn w tabeli, np. identyfikator, data urodzenia i zarobki pracowników.

Fragmentację pionową wykonuje się przez wykonanie rzutu na podzbiór kolumn zawierający w sobie klucz główny. Odtworzenie oryginalnej tabeli polega na zastosowaniu złączenia w oparciu o wartości klucza głównego.

Fragmentację poziomą uzyskuje się przez zastosowanie operacji selekcji. Odtworzenie oryginalnej tabeli polega na zastosowaniu operacji sumy UNION.
 

Operacja  Fragmentacja pozioma Fragmentacja pionowa
rozkład selekcja rzut
złożenie suma złączenie

Dla użytkownika rozproszona baza danych powinna wyglądać dokładnie tak samo jak jedna, scentralizowana baza danych. W związku z tym rozproszona baza danych powinna mieć trzy właściwości przezroczystości:

  1. Przezroczystość geograficzna. Użytkownicy nie muszą wiedzieć, w którym dokładnie węźle są przechowywane dane, które oglądają.

  2. Przezroczystość fragmentacji. Użytkownicy nie muszą wiedzieć, w jaki sposób dane są podzielone. W przykładzie zarządzania kadrami mamy do czynienia logicznie z jedną bazą danych, a fizycznie z trzema jej fragmentami.

  3. Przezroczystość replikacji. Użytkownicy nie muszą wiedzieć, w jaki sposób dane są replikowane i z której repliki pochodzą dane, które oglądają. W przykładowej bazie danych, w każdym z trzech biur jest przechowywana kopia informacji o strukturze firmy. Kiedy zachodzi potrzeba okresowej aktualizacji tych danych, użytkownicy nie muszą być świadomi tego, że aktualizacja dotyczy każdego z trzech miejsc.

Zalety rozproszenia (w porównaniu z systemem scentralizowanym)

  1. Odwzorowanie w bazie danych geograficznego podziału organizacji. Jeśli organizacja ma charakter narodowy lub ponadnarodowy, system musi uwzględniać podział organizacji na departamenty, oddziały itd.
  2. Większą kontrolę nad danymi można uzyskać przechowując je w miejscu, gdzie są one potrzebne. Jeśli biurowi w Gdańsku przekażemy odpowiedzialność za dane dotyczące Polski Północnej, wówczas tylko personel w Gdańsku będzie miał prawo aktualizować te dane.
  3. Utrzymywanie replikacji danych zwiększa niezawodność systemu. Przechowywanie danych w miejscach, gdzie są one potrzebne, poprawia ich dostępność. W dużych bankach bazy danych obsługujące transakcje klientów muszą działać 24 godziny przez wszystkie dni w tygodniu. Powszechnie używa się dwóch lub więcej bliźniaczych baz danych, jednej do bezpośredniego wykonywania transakcji, drugiej jako jej kopii (bazy rezerwowej lub repliki).
  4. Działanie systemu może się istotnie poprawić, jeśli dokona się prawidłowego rozproszenia danych. Jeśli większość zapytań generowanych w lokalnej bazie danych będzie wykonywana w tej lokalnej bazie danych zamiast w dużej scentralizowanej, wówczas jest duża szansa przyśpieszenia dostępu do danych przy operacjach wyszukiwania i aktualizacji.

System zarządzania rozproszoną bazą danych jest bardziej skomplikowany w porównaniu z bazą scentralizowaną.

  1. Słownik danych (katalog systemowy) rozproszonej bazy danych jest znacznie bardziej złożony. Obejmuje on na przykład informacje o położeniu fragmentów i replik tabel bazowych.

  2. Problemy związane ze współbieżnością są zwielokrotnione w systemach rozproszonych. Propagowanie aktualizacji do szeregu różnych węzłów jest skomplikowane. Gdy jest wiele kopii tego samego obiektu, trudno jest utrzymać spójność danych. Trudno jest zrealizować naturalny postulat, że każdy użytkownik, niezależnie skąd loguje się, widzi to samo. Obok dotychczasowych rodzajów awarii system rozproszony musi sobie dać radę również z awariami połączeń sieciowych.

  3. Optymalizator zapytań w prawdziwym systemie rozproszonym powinien być w stanie użyć właściwości topologiczne sieci (np. o koszcie przesłania danych między dwoma węzłami) przy decydowaniu, jak najlepiej wykonać dane zapytanie.

  4. Aby zapewnić odporność na awarie, system zarządzania rozproszoną bazą danych nie powinien być ulokowany w jednym miejscu. Zarówno oprogramowanie, jak i dane powinny zostać rozproszone po różnych miejscach w sieci.

Transakcje rozproszone

W kontekście rozproszonej bazy danych odróżnia się zapytania i transakcje odległe od rozproszonych.

Zapytanie odległe, transakcja odległa – dane do realizacji znajdują się w jednym, odległym węźle sieci.

Zapytanie rozproszone, transakcja rozproszona – dane do realizacji znajdują się w różnych węzłach sieci.

Do kosztu wykonywania zapytania dochodzi koszt przesłań danych między węzłami w sieci - i ten koszt ma największy wpływ na czas wykonywania zapytania.

Zapytania rozproszone

Załóżmy, że dane do poniższego zapytania znajdują się w różnych węzłach sieci.

SELECT AVG(E.Sal)
 FROM Emp E
 WHERE E.Deptno > 30 AND E.Deptno < 70

Rozproszone złączenia

Jest kilka metod wykonywania rozproszonego złączenia. Rozważymy je na przykładzie. Załóżmy, że tabela Dept jest dostępna w Warszawie a  Emp jest dostępna w Krakowie.

 SELECT E.Ename, d.Dname
 FROM Emp E INNER JOIN Dept D ON E.Deptno=D.Deptno
 WHERE E.Job='MANAGER' AND d.Loc='Warszawa'

Oto te metody.
 

1. Zastosuj metodę Nested Loops Join.

2. Sprowadź jedną tabelę (ewentualnie jej odpowiednią projekcję selekcji) do węzła gdzie jest druga tabela i tam wykonaj zapytanie.

3. Gdy rozmiar wyniku jest duży w porównaniu z rozmiarem tabel, sprowadź tabele do końcowego węzła i tam je złącz.

4. Metoda półzłączeń

  1. W Warszawie, dokonaj projekcji tabeli Dept na kolumny złączenia i prześlij wynik do Krakowa. Można skorzystać z selekcji d.Loc='Warszawa' ograniczającej zbiór wierszy.
  2. W Krakowie, dokonaj złączenia projekcji tabeli Dept z tabelą Emp. Wynik nazywa się redukcją tabeli Emp względem Dept. Prześlij redukcję tabeli Emp do Warszawy. Można skorzystać z selekcji E.Job='MANAGER' ograniczającej zbiór wierszy.
  3. W Warszawie, dokonaj ostatecznego złączenia tabeli Dept z redukcją tabeli Emp.

 

Rys. 14.1 Przesyłanie danych w sieci w metodzie półzłączeń
 

Optymalizacja rozproszonego zapytania

Rozważ wszystkie plany, wybierz najtańszy; podobnie jak w scentralizowanym przypadku. Oto różnice w porównaniu z przypadkiem scentralizowanym.

Różnica 1: Trzeba uwzględnić koszty komunikacji między węzłami; trzeba podejmować decyzję, którą replikę wybrać.

Różnica 2: Trzeba wziąć pod uwagę specyfikę każdego węzła lokalnego (np. inny rodzaj SZBD).

Różnica 3: Trzeba wziąć pod uwagę specyficzne metody rozproszonego złączenia.
 

Odświeżanie replik

Są dwie metody synchronizacji (odświeżania) replik:

Modyfikacje przez repliki

Na ogół repliki stanowią kopie tabeli nadrzędnej, na której wyłącznie są wykonywane wszystkie operacje INSERT, DELETE i UPDATE.

Replika modyfikowalna to replika przez którą można dokonywać zmian w taleli oryginale wykonując instrukcje INSERT/DELETE/UPDATE. Możliwe jest zastosowanie zarówno blokowania pesymistycznego jak i optymistycznego. 

W przypadku zastosowania blokowania optymistycznego, problemem jest, co robić w przypadku konfliktu, np. gdy w dwóch różnych węzłach dokonano różnych modyfikacji tego samego wiersza - szczególnie wtedy kiedy obie modyfikujące transakcje zakończyły się już zatwierdzeniem. Możliwe metody rozwiązywania kolizji są następujące:

  1. nie pozwolić jednej z transakcji na zatwierdzenie i po stwierdzeniu zaistnienia konfliktu, wycofać ją - zgodnie ze standardowymi regułami,
  2. ustalić ogólne reguły np. oparte na priorytetach,
  3. pozostawić konflikty do rozstrzygnięcia administratorowi bazy danych.

Ustalenie zasad ograniczających możliwości modyfikacji przez repliki ma prowadzić do zachowania aksjomatu trwałości wykonywania transakcji (czwarty aksjomat ACID) - albo przy najmniej tylko do kontrolowanego jego naruszania.

 

14.3 Rozproszone zatwierdzanie i odtwarzanie

W porównaniu z przypadkiem scentralizowanym pojawiają się nowe problemy:

  1. Dodatkowe rodzaje awarii, np. związane z połączeniami sieciowymi i odległymi węzłami.
  2. Gdy "pod-transakcje" całej transakcji są wykonywane w różnych węzłach, wszystkie razem  wykonują COMMIT albo żadna z nich. Potrzebny jest specjalny protokół zatwierdzania.
  3. W każdym węźle jest utrzymywany odrębny dziennik (log) wykonywanych akcji, tak jak w scentralizowanej bazie danych. W tym dzienniku są odnotowywane akcje protokołu zatwierdzania.

Transakcja rozproszona jest realizowana przez zbiór węzłów w sieci. Jest jeden wyróżniony węzeł, który inicjuje i koordynuje transakcję – jest nazywany koordynatorem transakcji.

Rys. 14.2 Model wykonywania transakcji rozproszonej
 

Strzałki oznaczają przepływ sterowania, nie koniecznie przepływ danych. Baza danych użytkownika może być jedną z baz danych biorących udział w transkcji, ale nie koniecznie.

Podstawą realizacji transakcji rozproszonej jest następujący protokół.

Protokół dwufazowego zatwierdzania (2PC ang. Two-Phase Commit)

  1. Koordynator wysyła do wszystkich węzłów komunikat prepare.
  2. Węzły podejmują lokalnie decyzję o gotowości do zatwierdzenia prepare lub konieczności wycofania transakcji abort i zapisują w swoim dzienniku odpowiednio albo rekord prepare albo rekord abort i następnie wysyłają do koordynatora odpowiednio komunikat albo yes albo no.
  3. Gdy koordynator uzyska jednomyślną odpowiedź yes, zapisuje do swojego dziennika rekord commit i wysyła do wszystkich węzłów komunikat commit. W przeciwnym przypadku zapisuje do swojego dziennika rekord abort i wysyła do wszystkich węzłów komunikat abort.
  4. Węzły zapisują w swoim dzienniku odpowiednio rekord abort/commit albo end, kończą transakcję usuwając informację o niej z bufora bazy danych w pamięci RAM. a następnie wysyłają do koordynatora komunikat ack.
  5. Po otrzymaniu wszystkich potwierdzeń ack koordynator zapisuje do swojego dziennika rekord end i kończy transakcję usuwając informację o niej z buforu bazy danych w pamięci RAM.

Komentarz na temat protokołu 2PC

  1. Dwufazowość - dwie rundy komunikacji: pierwsza - głosowanie; druga - kończenie. Obie są inicjowane przez koordynatora.
  2. Koordynator w fazie głosowania, gdy nie ma odpowiedzi z jednego z węzłów, może zadecydować o wycofaniu (abort) całej transakcji - jest zwykle określone ograniczenie czasowe oczekiwania na odpowiedź.
  3. Każdy węzeł przed lub w czasie fazy głosowania może zadecydować o wycofaniu (abort) transakcji - również wtedy gdy nie może się połączyć z koordynatorem.
  4. Każdy komunikat odzwierciedla decyzję nadawcy; aby mieć pewność odporności na awarie, decyzja jest najpierw zapisywana do dziennika transakcji (logu).
  5. Dwu-fazowe zatwierdzanie (2PC) z domyślnym wycofaniem: w przypadku podjęcia decyzji o wycofaniu zarówno koordynator jak i węzeł lokalny od razu dokonują wycofania transakcji. Brak transakcji w pamięci RAM oznacza, że została ona wycofana.

 

14.4 Implementacja rozproszonych baz danych w Oracle

Przede wszystkim Oracle dostarcza oprogramowanie sieciowe Oracle Net umożliwiające komunikację między bazami danych Oracle oraz obsługę transakcji rozproszonych działających na więcej niż jednej bazie danych – w tym zatwierdzanie takich transakcji i ich wycofywanie.

Z punktu widzenia projektanta rozproszonej bazy danych najważniejsze są dwa nowe rodzaje obiektów tworzonych w lokalnej bazie danych, za pomocą których uzyskuje się dostęp do obiektów w odległych bazach danych. W ten sposób ze zbioru lokalnych baz danych można utworzyć jedną rozproszoną bazę danych. Obiekty te to:

1. Powiązanie z bazą danych (ang. database link) – jest to zapisana w bazie danych ścieżka sieciowa do odległej bazy danych.

2. Migawka, perspektywa zmaterializowana (ang. snapshot, materialized view) – lokalna kopia (replika) danych znajdujących się w jednej lub więcej odległych bazach danych. Migawka ma charakter perspektywy odświeżanej co określony przedział czasu (może więc nie zawierać danych w pełni aktualnych!).

Powiązanie z bazą danych

Składnia tworzenia powiązania z bazą danych jest następująca:
 
CREATE DATABASE LINK nazwa_powiązania
 CONNECT TO użytkownik IDENTIFIED BY hasło
 USING ’nazwa_usługi’;
gdzie:

Po utworzeniu powiązania z bazą danych można korzystać z tabel i perspektyw w tej odległej bazie danych, tak jakby znajdowały się one w lokalnej bazie danych – dołączając do nazwy tabeli lub perspektywy napis @nazwa_powiązania. Na przykład, instrukcja:

CREATE DATABASE LINK baza
CONNECT TO scott IDENTIFIED BY tiger
USING 'elektron';
tworzy powiązanie bazodanowe o nazwie baza z odległą bazą danych określoną przez sieciową usługę Oracle o nazwie elektron. Przy wykonywaniu instrukcji
SELECT *
FROM Emp@baza;
lokalny serwer Oracle łączy się, używając oprogramowania Oracle Net, z odległą bazą danych elektron. Oprogramowanie Oracle Net znajdujące się na docelowym komputerze przechwytuje zgłoszenie i dokonuje logowania w bazie danych elektron na konto scott/tiger. Serwer wykonuje przesłaną instrukcję SELECT i przesyła przez sieć z powrotem wyniki zapytania, jednocześnie wylogowując użytkownika scott/tiger.

System Oracle potrafi wykonywać dowolne instrukcje SQL, tak jakby tabele i perspektywy z odległych baz danych znajdowały się w lokalnej bazie danych np.

SELECT * FROM Emp@warszawa
UNION
SELECT * FROM Emp@gdansk
UNION
SELECT * FROM Emp@katowice;
czy
UPDATE Emp@baza
SET Salary = Salary * 1,1;

Synonimy

Definiuje się zwykle synonimy dla obiektów w odległej bazie danych, np.

CREATE SYNONYM Klienci
FOR Klienci@Baza_szkola;
Następnie używamy nazwy Klienci, tak jakby to była to zwykła tabela.

Migawki (repliki)

Drugi rodzaj obiektów specyficzny dla rozproszonej bazy danych replika (migawka, perspektywa zmaterializowana) jest tworzona za pomocą instrukcji:
 
CREATE SNAPSHOT nazwa_migawki
REFRESH NEXT przedział_czasu
AS zapytanie;
gdzie:

  1. przedział_czasu – określa, co jaki czas należy odświeżać migawkę,

  2. zapytanie – określa zapytanie, które tworzy zawartość migawki i które jest ponawiane przy każdym odświeżaniu migawki.

Zamiast słowa kluczowego SNAPSHOT można też używać słowo kluczowe MATERIALIZED VIEW.

Instrukcja:

CREATE SNAPSHOT Wszyscy_prac
REFRESH NEXT Sysdate+1
AS SELECT * FROM Emp@warszawa
   UNION
   SELECT * FROM Emp@krakow
   UNION
   SELECT * FROM Emp@gdansk;
tworzy migawkę złożoną z danych o pracownikach pochodzących z trzech oddziałów firmy w Warszawie, Krakowie i Gdańsku. Zawartość migawki ma być odświeżana raz na dzień. Po zdefiniowaniu migawki Wszyscy_prac można jej używać w zapytaniach, tak jakby to była zwykła tabela lub perspektywa. Na przykład:
SELECT *
FROM Wszyscy_prac
WHERE Job = 'MANAGER';
wypisuje informacje o wszystkich osobach pracujących w firmie na stanowisku MANAGER.

Implementacja migawki

W lokalnej bazie danych dla każdej migawki są tworzone trzy obiekty:

  1. tabela, do której jest zapisywany wynik zapytania (stąd nazwa perspektywa zmaterializowana),

  2. indeks dla klucza głównego,

  3. perspektywa służąca do wyświetlania i używania zawartości migawki.

Odświeżanie migawki

Rozróżniamy dwa typy migawek względem instrukcji SELECT występującej w jej definicji: proste i złożone. W przypadku migawki złożonej nie ma żadnych ograniczeń. Jeśli w instrukcji SELECT nie występują ani klauzule GROUP BY, CONNECT BY, DISTINCT ani funkcje sumaryczne, ani operatory zbiorowe, ani złączenia tabel, to taka migawka jest prosta.

Dla migawki prostej jest możliwe szybkie odświeżanie (opcja REFRESH FAST) pod warunkiem utworzenia w węźle, w którym znajduje się tabela-oryginał tej migawki, specjalnego dziennika. Dziennik migawki jest tabelą, do której są wpisywane zmiany dokonywane na tabeli-oryginale. Następnie, przy odświeżaniu migawki zamiast przesyłać całą zawartość tabeli-oryginału, jest przesyłana tylko zawartość dziennika migawki. Oto przykład instrukcji zakładającej dziennik migawki na tabeli Emp:

CREATE SNAPSHOT LOG ON Emp
TABLESPACE users;
Ze względu na spójność referencyjną - łączy się migawki w grupy i dokonuje się ich jednoczesnego odświeżania.

Modyfikowanie danych przez migawkę

Jeśli w definicji migawki prostej użyjemy klauzuli FOR UPDATE, utworzymy migawkę modyfikowalną:

CREATE SNAPSHOT Rep_emp
REFRESH FAST NEXT Sysdate+1
FOR UPDATE
AS SELECT * FROM Emp@warszawa;
Można wówczas dokonywać zmian w taleli oryginale wykonując operacje INSERT/DELETE/UPDATE na migawce, np.
UPDATE Rep_emp
SET Sal = Sal*1.05
WHERE Ename = 'SCOTT';
 

14.5 Problem integracji informacji

W zastosowaniach baz danych coraz częściej pojawia się problem integracji danych pochodzących z różnych źródeł danych - w szczególności z baz danych.

  1. Powiązane dane istnieją w różnych miejscach i może zaistnieć potrzeba jednoczesnego ich użycia przez jedną aplikację.
  2. Bazy danych mogą się różnić:
    • modelem (np. relacyjny, obiektowo-relacyjny, hierarchiczny, XML, pliki MS Excel),
    • schematem (np. znormalizowany, nieznormalizowany),
    • terminologią (np. czy konsultanci firmy są pracownikami, czy emerytowani pracownicy są pracownikami),
    • konwencjami (np. stopnie Celsjusza lub Fahrenheita; mile lub kilometry).

Przykład

Dwie szkoły wyższe chcą się połączyć. Każda z nich ma swoją osobną bazę danych. Władze nowej szkoły wyższej chcą mieć zintegrowany widok na całość.

Dwa podejścia do integracji

  1. Hurtownia danych. Skopiuj dane źródłowe do centralnej bazy danych dokonując ich transformacji do wspólnego schematu. Hurtownie danych są tematem osobnego wykładu.
    • Sprowadzanie danych i ich transformacja jest dokonywane raz na pewien czas – np. raz na dzień.

    Rys. 14.3 Rozwiązanie problemu integracji za pomocą hurtowni danych

  2. Mediator. Utwórz perspektywę wszystkich źródeł danych, tak jakby były zintegrowane.
    • Wyznaczaj wynik zapytania do perspektywy przez jego tłumaczenie do źródeł danych a następnie tam wykonuj zapytanie.

    Rys.14.4 Rozwiązanie problemu integracji za pomocą modułu mediatora

Moduł osłony (wrapper) i rola języka XML

Moduł stojący między źródłową bazą danych a hurtownią danych bądź mediatorem nazywa się osłoną (ang. wrapper).

Filtruje on dane ze źródłowej bazy danych na zewnątrz (zgodnie ze specyfikacją). Najwygodniejszym uniwersalnym językiem wynikowym jest XML (do komunikacji, co najmniej, między mediatorem a osłoną).

Zapytanie do źródłowej bazy danych (przygotowywane przez mediatora) też może być sformułowane przy użyciu XML. Tłumaczenia na język źródłowej bazy danych dokonuje konkretny moduł osłony związany z konkretną bazą danych.

 

14.6 Podsumowanie

Zostało przedstawione pojęcie rozproszonej bazy danych i omówione jej zalety i wady w porównaniu z konwencjonalną, scentralizowaną bazą danych.

Przedstawiona została implementacja rozproszonej bazy danych w konkretnym systemie baz danych – Oracle.

Rozważony też został problem integracji informacji pochodzących z różnych heterogenicznych baz danych.

 

14.7 Słownik pojęć

fragment danych - podzbiór wszystkich danych całej bazy danych przechowywany w jednym węźle sieci.

replika danych - kopia całości lub jakiejś części danych przechowywanych w innym węźle sieci niż oryginał.

replikacja synchroniczna - zanim modyfikująca transakcja zostanie zatwierdzona dokonuje się aktualizacji (odświeżenia) wszystkich replik (obejmuje zakładanie blokad, wymianę komunikatów w sieci).

replikacja asynchroniczna - kopie zmodyfikowanej tabeli są tylko okresowo aktualizowane (odświeżane) – metoda znacznie tańsza; ale chwilowo różne kopie mogą nie być ze sobą zsynchronizowane.

zapytanie odległe – zapytanie, w którym dane do realizacji znajdują się w jednym odległym węźle sieci.

transakcja odległa – transakcja, której dane do realizacji znajdują się w jednym odległym węźle sieci.

zapytanie rozproszone – zapytanie, w którym dane do realizacji znajdują się w różnych, odległych węzłach sieci.

transakcja rozproszona – transakcja, której dane do realizacji znajdują się w różnych odległych węzłach sieci.

protokół dwufazowego zatwierdzania (2PC) - protokół zatwierdzania transakcji rozproszonej obowiązujący węzły w sieci biorące udział w realizacji transakcji rozproszonej. Składa się z dwóch faz komunikacji między węzłami: pierwsza - głosowanie czy zatwierdzić transakcję; druga - kończenie transakcji po podjęciu decyzji. Obie fazy są inicjowane przez jeden wyznaczony do tego węzeł nazywany koordynatorem transakcji.

powiązanie bazodanowe (z bazą danych) - zapisana, jako obiekt bazy danych Oracle,  ścieżka sieciowa do odległej bazy danych.

integracja informacji - problem zbudowania jednolitego intefejsu do zbioru heterogenicznych baz danych. Dwa stosowane podejścia to albo kopiowanie danych do jednej bazy danych nazywanej hurtownią danych albo zbudowanie modułu mediatora między bazami danych. Jako język do komunikacji jest używany język XML.
 

14.8 Zadania

1. Międzynarodowa sieć supermarketów potrzebuje bazy danych do zarządzania działalnością sieci. Jakiego rodzaju zapytania będą kierowane do bazy danych z lokalnych oddziałów a jakie z centrali? Zaplanuj, które dane powinny znajdować się w lokalnych bazach danych, a które w bazie centrali; które dane powinny być replikowane, a które nie muszą. Czy modyfikowalność przez repliki jest istotna?

2. Kilka funkcjonujących sklepów chce utworzyć spółkę. Każdy ze sklepów ma swoją niezależnie zbudowaną i funkcjonującą bazę danych. Kierownictwo firmy chce mieć pełny wgląd w całość spółki. Jakie rozwiązanie zaproponowałbyś, np. utworzyć od początku nową bazę danych i dokonać do niej migracji danych, zbudować moduł mediatora, zbudować hurtownię danych?

Strona przygotowana przez Lecha Banachowskiego - 03/21/05 .