Są dwa punkty wyjściowe do konstrukcji rozproszonej bazy danych:
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. Przedstawiony jest zarys rozszerzenia 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 pokrewny problem integracji informacji pochodzących z różnych baz danych.
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.
Natomiast do wad rozwiązania zcentralizowanego należą:
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.
Fragment danych stanowi pewien podzbiór wszystkich danych całej bazy danych przechowywany w jednym węźle sieci.
Replika danych stanowi kopię całości lub jakiejś części danych przechowywanych w innym miejscu w sieci niż oryginał.
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. Obliczenie fragmentu poziomego uzyskuje się przez wykonanie operatora selekcji na podstawowej tabeli.
Fragment pionowy stanowi podzbiór kolumn w tabeli, np. identyfikator, data urodzenia i zarobki pracowników. Wymaga się aby wśród wybranych kolumn znajdowały się kolumny klucza głównego. Obliczenie fragmentu pionowego uzyskuje się z tabeli podstawowej przez wykonanie rzutu na podzbiór kolumn zawierający w sobie klucz główny.
Fragmentację poziomą uzyskuje się przez podział tabeli na zbiór fragmentów poziomych. Po zastosowaniu fragmentacji poziomej, odtworzenie oryginalnej tabeli polega na zastosowaniu operatora sumy UNION.
Fragmentację pionową uzyskuje się przez podział
tabeli na zbiór fragmentów pionowych. Po zastosowaniu fragmentacji pionowej
odtworzenie oryginalnej tabeli polega na zastosowaniu złączenia względem kolumn klucza głównego.
| Operacja | Fragmentacja pozioma | Fragmentacja pionowa |
| rozkład | selekcja | rzut |
| złożenie | suma | złączenie |
Tab. 13.1 Operacje związane z fragmentacjami tabeli
Stosując fragmentację (poziomą albo pionową) dzielimy tabelę podstawową na części przechowywane w różnych węzłach sieci. Oczywiście można też stosować bardzie złożone kryteria podziału, jeśli dziedzina aplikacyjna tego wymaga np. najpierw dokonując podziału poziomego, a w ramach każdego fragmentu poziomego dokonując odpowiedniego podziału pionowego (albo na odwrót).
Dla użytkownika rozproszona baza danych powinna wyglądać dokładnie tak samo jak jedna, scentralizowana baza danych. To znaczy, na poziomie użytkowym rozproszona baza danych powinna być identyczna z odpowiadającą jej scentralizowaną bazą danych. W związku z tym rozproszona baza danych powinna mieć trzy właściwości przezroczystości:
Przezroczystość geograficzna. Użytkownicy nie muszą wiedzieć, w którym dokładnie węźle są przechowywane dane, które oglądają.
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.
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 wszystkich trzech miejsc.
Zalety rozproszenia (w porównaniu z systemem scentralizowanym)
System zarządzania rozproszoną bazą danych jest bardziej skomplikowany w porównaniu z bazą scentralizowaną.
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.
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, problemy mogą się pojawić z utrzymaniem spójności danych. Trudno jest zrealizować naturalny dla bazy danych postulat, że każdy użytkownik, niezależnie skąd loguje się, widzi dokładnie to samo. Obok dotychczas rozpatrywanych rodzajów awarii, system rozproszony musi sobie dać radę również z awariami połączeń sieciowych.
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 a także o szybkości działania odległych SZBD) przy decydowaniu, jak najlepiej wykonać dane zapytanie.
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.
Pożądane właściwości rozproszonej bazy danych podsumujemy w postulatach Date'a.
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 właśnie ten koszt ma największy wpływ na czas wykonywania zapytania (większy niż koszt operacji We-Wy).
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;Fragmentacja pozioma: Załóżmy, że wiersze z E.Deptno < 5O są w Krakowie, natomiast z E.Deptno >= 50 w Warszawie. Aby wykonać zapytanie, obliczamy osobno w obu węzłach SUM(E.Sal) i COUNT(E.Sal). Gdyby w klauzuli WHERE był warunek, np. E.Empno>70, wtedy wykonywanie zapytania odbywałoby się tylko w jednym węźle (byłoby zapytaniem odległym).
Fragmentacja pionowa: Załóżmy, że kolumna E.Sal jest w Warszawie, E.Deptno w Krakowie, natomiast E.Empno w obu bazach.
Najprostsza metoda polega na sprowadzeniu danych potrzebnych do wykonania zapytania do jednego węzła (można wykorzystać warunki ograniczające) i zrekonstruowaniu za pomocą operacji złączenia potrzebny fragment tabeli, po czym wykonaniu obliczenia. W naszym przypadku dane z Krakowa (odpowiednia projekcja selekcji) zostałyby przesłane do Warszawy.
Inna polega na wykonaniu najpierw selekcji na E.Deptno w Krakowie, przesłaniu wyliczonych wartości E.Empno do Warszawy i tam wykonaniu obliczeń na E.Sal.
Replikacja: Załóżmy, że kopie tabeli Emp są dostępne w Warszawie i Krakowie. Wybór węzła wykonującego zapytanie jest uzależniony od lokalnego kosztu wykonania zapytania i od kosztu przesłania wyników.
Rozważymy problem rozproszonego złączenia na konkretnym 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';SELECT E.Ename, d.Dname
FROM (SELECT E.Deptno, E.Ename FROM Emp E WHERE E.Job='MANAGER')E INNER JOIN
(SELECT D.Deptno, D.Dname FROM Dept D WHERE d.Loc='Warszawa')D ON E.Deptno=D.Deptno;1. Sprowadź jedną tabelę (ewentualnie jej odpowiednią projekcję selekcji) do węzła gdzie jest druga tabela i tam dokonaj złączenia.
2. Gdy rozmiar wyniku jest duży w porównaniu z rozmiarem tabel, sprowadź tabele (a lepiej tylko ich odpowiednie projekcje selekcji) do końcowego węzła i tam je złącz.
3. Metoda półzłączeń (ang. Semijoins)
- W Warszawie, na tabeli Dept najpierw dokonaj selekcji
d.Loc='Warszawa'ograniczającej zbiór wierszy a następnie projekcji na kolumny złączenia i prześlij wynik do Krakowa.- W Krakowie, dokonaj złączenia nadesłanej tabeli z tabelą Emp. Wynik nazywa się redukcją tabeli Emp względem Dept. Prześlij redukcję tabeli Emp do Warszawy. Przy obliczaniu redukcji stosuje się dodatkowo selekcję
E.Job='MANAGER'oraz projekcję na kolumny, które są potrzebne do obliczenia wyniku całego zapytania.- W Warszawie, dokonaj ostatecznego złączenia tabeli Dept z redukcją tabeli Emp.
- Idea metody półzłączeń: koszt przesłania całej tabeli zastępujemy kosztem obliczenia i przesłania kolejno projekcji jednej tabeli i redukcji drugiej tabeli.
Rys. 13.1 Przesyłanie danych w sieci w metodzie półzłączeń
W konkretnym przypadku, optymalizator szacuje ilość danych, które trzeba przesłać siecią, przy zastosowaniu każdej z trzech metod i wybiera tę metodę, dla której ta ilość jest najmniejsza.
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 - koszty przesyłania danych siecią mają decydujące znaczenie dla wydajności wykonania zapytania rozproszonego.
Różnica 2: Trzeba podjąć decyzję, którą replikę wybrać, jeśli te same dane są dostępne w różnych węzłach.
Różnica 3: Trzeba wziąć pod uwagę specyfikę każdego węzła lokalnego (np. inny rodzaj SZBD).
Różnica 4: Trzeba wziąć pod uwagę specyficzne metody rozproszonego złączenia. W szczególności, w trakcie złączania, nie opłaca się przesyłać pojedynczego wiersza, ale od razu całą ich kolekcję.
Są dwie metody synchronizacji (odświeżania) replik:
Modyfikacje przez repliki
Repliki dzielą się na niemodyfikowalne i modyfikowalne. Do tej pory rozważane przez nas repliki są niemodyfikowalne co oznacza, że operacje INSERT, DELETE i UPDATE są wyłącznie wykonywane bezpośrednio na tabeli-oryginale.Replika modyfikowalna jest to replika przez którą można dokonywać zmian w tabeli oryginale wykonując instrukcje INSERT/DELETE/UPDATE.
Przy dokonywaniu modyfikacji przez replikę mamy dwie możliwości:
1. wykonywać zmianę danych na tabeli oryginale w ramach tej samej transakcji co zmiana danych w replice;
2. wykonywać zmianę danych najpierw tylko na replice, a dopiero potem zgodnie z określonymi procedurami przekazywać je do wykonania na tabeli oryginale (ten sposób bardziej odpowiada naturze użycia replik w rozproszonej bazie danych). W tym przypadku może się pojawić sytuacja kolizji, gdy w różnych replikach te same dane zostaną zmienione w różny sposób. Wtedy, opierając się na ustalonych z góry zasadach, trzeba wybrać jedną wersję jako główną i przekazać ją do wszystkich replik.
Dla replik możliwe jest zastosowanie modelu optymistycznych blokad. Gdy oryginał został w międzyczasie zmieniony i zmiany zostały zatwierdzone, aktualizacja na replice zostałaby wycofana.
W porównaniu z przypadkiem scentralizowanym pojawiają się nowe problemy:
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. 13.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 transakcji, ale nie koniecznie.
ROLLBACK
Realizacja polecenia ROLLBACK jest prosta. Koordynator przekazuje węzłom lokalnym polecenie abort do wykonania w lokalnym węźle. Oczywiście, wydanie polecenia abort może wynikać z obsługi wyjątku zgłoszonego do aplikacji przez lokalny węzeł. Również zgłoszenie awarii w lokalnym węźle może spowodować konieczność wykonania polecenia ROLLBACK przez aplikację bądź system.
COMMIT
W przypadku realizacji polecenia COMMIT jest stosowany następujący protokół uzgodnionego zatwierdzania transakcji rozproszonej.
Protokół dwufazowego zatwierdzania (2PC ang. Two-Phase Commit)
Komentarz na temat protokołu 2PC
Jest możliwe kilka modyfikacji zasadniczego protokołu 2PC.
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!).
Składnia tworzenia powiązania z bazą danych (powiązania bazodanowego) jest następująca:
CREATE DATABASE LINK nazwa_powiązania |
użytkownik/hasło – dotyczą konta, na które ma zostać dokonane logowanie w odległej bazie danych, jeśli ich brak – używana jest nazwa użytkownika i hasło z lokalnej bazy danych;
nazwa_usługi – nazwa usługi (aliasu bazy danych) Oracle Net np. zdefiniowanej w lokalnym pliku konfiguracyjnym TNSNAMES.ORA.
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';SELECT *
FROM Emp@baza;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;UPDATE Emp@baza
SET Salary = Salary * 1,1;Definiuje się zwykle synonimy dla obiektów w odległej bazie danych, np.
CREATE SYNONYM Klienci
FOR Klienci@Baza_szkola; Klienci, tak jakby to była to zwykła
tabela.Drugi rodzaj obiektów specyficzny dla rozproszonej bazy danych Oracle
replika jest tworzona za pomocą instrukcji:
CREATE SNAPSHOT nazwa_migawki |
przedział_czasu – określa, co jaki czas należy odświeżać migawkę,
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. Migawka jest faktycznie perspektywą zmaterializowaną, a nazwy "migawka" bądź słowa kluczowego "SNAPSHOPT" używa się aby podkreślić kontekst użycia perspektywy zmaterializowanej - do konstrukcji rozproszonej bazy danych.
Na przykład, instrukcja:
CREATE SNAPSHOT Wszyscy_prac
REFRESH NEXT Sysdate+1
AS SELECT * FROM Emp@warszawa
UNION
SELECT * FROM Emp@krakow
UNION
SELECT * FROM Emp@gdansk;SELECT *
FROM Wszyscy_prac
WHERE Job = 'MANAGER';W lokalnej bazie danych dla każdej migawki są tworzone trzy obiekty:
tabela, do której jest zapisywany wynik zapytania (stąd nazwa perspektywa zmaterializowana),
indeks dla klucza głównego,
perspektywa służąca do wyświetlania i używania zawartości 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 nazywanego dziennikiem migawki, do którego 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;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;UPDATE Rep_emp
SET Sal = Sal*1.05
WHERE Ename = 'SCOTT';
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.
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ść.
Rozwiązanie problemu integracji informacji można traktować jako pewną ograniczoną rozproszoną bazę danych zbudowaną nad zbiorem heterogenicznych źródeł danych przez dodanie jednej "centralnej" bazy danych i umożliwienie kontaktowania się jej z każdym źródłem danych z osobna.
Rys. 13.3 Rozwiązanie problemu integracji za pomocą hurtowni danych
Rys.13.4 Rozwiązanie problemu integracji za pomocą modułu mediatora
3. Federacja baz danych. Każda baza danych stanowi osobny system mający własnych użytkowników. Do realizacji pewnych specjalnych wspólnych zadań bazy danych tworzą federację w oparciu o określony mechanizm integrujący (może to być mediator z poprzedniego rozwiązania). Transakcje lokalne działają na lokalnych bazach danych. Transakcje globalne działają na federacji baz danych i zwykle składają się z kilku niezależnych lokalnych transakcji.
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.
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.
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 można 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 interfejsu 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.
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?