SYSTEMY BAZ DANYCH

1
SYSTEMY BAZ DANYCH
Czesc V Rozproszone i federacyjne bazy danych
Opracowanie Dr Bozena Smialkowska
2
Wprowadzenie do systemów rozproszonych
3
Co to jest system rozproszony?

• Systemem rozproszonym nazywamy taki system, w
  którym przetwarzanie informacji odbywa sie na
  wielu komputerach, czesto znacznie oddalonych
  geograficznie (od kilku metrów do dziesiatków
  tysiecy kilometrów). Przeciwienstwem jest system
  izolowany lub scentralizowany.
• Obecnie wlasciwie wszystkie systemy (poza
  domowymi komputerami) sa rozproszone. Ogromnym
  katalizatorem rozproszenia systemów jest
  Internet. Komputer z Internetem mozna juz uwazac
  za system rozproszony.
• Projektowanie i wlasnosci systemów rozproszonych
  w duzej mierze sa takie same jak systemów
  scentralizowanych, ale istnieja takze istotne
  róznice, który specjalista inzynierii
  oprogramowania musi byc swiadomy.
• Tendencja do budowy systemów rozproszonych jest
  pochodna rozbudowy tanich, szybkich,
  uniwersalnych i niezawodnych sieci komputerowych.
• Przyklady systemów rozproszonych siec
  bankomatów, system rezerwacji biletów, system
  pracy grupowej, itd.

4
Co to jest system rozproszony?
5
Cztery najwazniejsze problemy do rozwiazania w
systemach r.b.d.

• Przezroczystosc (transparency) traktowanie
  rozproszonych zasobów i uslug tak, jak gdyby byly
  one wewnatrz przestrzeni adresowej jednego
  komputera.
• Bezpieczenstwo przeciwdzialanie losowym awariom
  oraz mozliwosciom ataku z zewnetrz.
• Interoperacyjnosc (interoperability)
  umozliwienie wspólpracy heterogenicznych
  platform, aplikacji, logik biznesowych i
  organizacji danych.
• Efektywnosc uzyskanie czasów przetwarzania
  akceptowalnych dla szerokiego kregu uzytkowników
  rozproszonych aplikacji.

6
Przezroczystosc

• Redukcja zlozonosci przy pracy z rozproszonymi
  zasobami danych i uslug, polegajaca na uwolnieniu
  programisty od myslenia na temat polozenia i
  organizacji rozproszonych danych.
• Przezroczystosc ma bezposrednie skutki dla czasu
  i kosztu wytworzenia rozproszonej aplikacji, jej
  przenaszalnosci i pielegnacyjnosci.

7
Formy przezroczystosci (1)

• Przezroczystosc polozenia i dostepu Uwolnienie
  uzytkowników od koniecznosci korzystania z
  informacji o aktualnym polozeniu geograficznym
  danych i uslug.
• Przezroczystosc wspólbieznosci Umozliwienie
  wielu uzytkownikom jednoczesnego dostepu do
  danych i uslug.
• Przezroczystosc skalowania Umozliwienie
  dodawania lub usuwania serwerów, danych i uslug
  bez wplywu na dzialanie aplikacji i prace
  uzytkowników.
• Przezroczystosc fragmentacji (podzialu)
  automatyczne scalanie obiektów lub kolekcji,
  których fragmenty sa przechowywane w róznych
  miejscach.

8
Formy przezroczystosci (2)

• Przezroczystosc replikacji Umozliwienie
  tworzenia i usuwania kopii danych w innych
  miejscach geograficznych ze skutkiem dla
  efektywnosci przetwarzania.
• Przezroczystosc awarii Umozliwienie
  nieprzerwanej pracy wiekszosci uzytkowników
  rozproszonej bazy danych w sytuacji, gdy niektóre
  z jej wezlów lub linie komunikacyjne ulegly
  awarii.
• Przezroczystosc migracji Umozliwienie
  przenoszenia zasobów danych do innych miejsc bez
  wplywu na prace uzytkowników.

9
Interoperacyjnosc

• Krytyczny problem dla projektu bottom-up, czyli
  systemu integrujacego istniejace (spadkowe)
  niekompatybilne (heterogeniczne) dane i uslugi.
• Interoperacyjnosc na poziomie transportu
  (transport-level interoperability) jako podstawa
  wyzszych form interoperacyjnosci. Chodzi o
  umozliwienie fizycznej komunikacji pomiedzy
  danymi i uslugami, np. na gruncie TCP/IP, HTTP,
  wspólnej pamieci, itp.

10
Interoperacyjnosc kontra przezroczystosc

• Koniecznosc poszukiwania kompromisowych rozwiazan
  na zasadzie tzw. wspólnego rozwiazania.
• Moze byc to latwe Dla danej populacji serwerów
  istnieje prosty model kanoniczny powiazan
  inter-operacyjnych w jedna przezroczysta calosc.
• Moze to byc trudne Jezeli rozbieznosci pomiedzy
  serwerami sa duze, to informacja o zawartosci
  poszczególnych serwerów musi byc doprowadzona do
  programisty i do modelu kanonicznego. Jest to
  problem zlozony i nieprzezroczysty.

11
Zalety systemów rozproszonych cd..

• Podzial zasobów system rozproszony pozwala
  dzielic zasoby sprzetowe i programowe (pamieci
  dyskowe, drukarki, pliki, kompilatory, itd.)
  pomiedzy wielu uzytkowników pracujacych na
  róznych komputerach pracujacych w sieci.
• Otwartosc jest ona definiowana jako zdolnosc
  systemu do dolaczania nowego sprzetu,
  oprogramowania i uslug. Otwarte systemy czesto
  maja te zdolnosc równiez w stosunku do w/w
  zasobów ulokowanych na platformach sprzetowych i
  systemach operacyjnych dostarczanych przez
  róznych dostawców.
• Wspólbieznosc w systemie rozproszonym wiele
  procesów moze dzialac w tym samym czasie na
  róznych komputerach w sieci. Procesy te moga
  (jakkolwiek nie musza) komunikowac sie podczas
  swego dzialania.
• Skalowalnosc Moc i mozliwosci przetwarzania moze
  wzrastac w miare dodawania do systemu nowych
  zasobów, w szczególnosci komputerów. W praktyce
  skalowalnosc jest czesto ograniczona poprzez
  przepustowosc sieci oraz (niekiedy) poprzez np.
  specyficzne protokoly wymiany informacji.
  Niemniej skalowalnosc systemu rozproszonego jest
  nieporównywalnie lepsza w stosunku do systemu
  scentralizowanego.

12
Zalety systemów rozproszonych (2)

• Tolerancja bledów Dostepnosc wielu komputerów
  oraz umozliwienie zdublowania informacji
  (replikacje) oznacza, ze rozproszony system jest
  tolerancyjny w stosunku do pewnych bledów zarówno
  sprzetowych jak i programowych. Np. awaria wezla
  komunikacyjnego powoduje wygenerowanie innej
  trasy przeplywu informacji.
• Przezroczystosc Oznacza ukrycie przed
  uzytkownikiem szczególów rozproszenia, np. gdzie
  ulokowane sa zasoby lub jak sa one fizycznie
  zaimplementowane, pod jakim systemem pracuja,
  itd. Przezroczystosc ma zasadnicze znaczenie dla
  komfortu dzialania uzytkownika oraz dla
  niezawodnosci budowanego oprogramowania.
  Niekiedy, np. dla celów optymalizacyjnych,
  uzytkownik moze zrezygnowac z pelnej
  przezroczystosci. Przykladem przezroczystosci
  jest Internet klikajac w aktywne pole na stronie
  WWW nie interesujemy sie, gdzie znajduje sie
  odpowiadajaca mu strona, oraz jak i na czym jest
  zaimplementowana.

13
Wady systemów rozproszonych

• Zlozonosc systemy rozproszone sa trudniejsze do
  zaprogramowania i do administrowania niz systemy
  scentralizowane. Zaleza od wlasnosci sieci, np.
  jej przepustowosci i czasu transmisji, co
  utrudnia zaprojektowanie i zrealizowanie wielu
  algorytmów i procesów przetwarzania.
• Ochrona Dla systemu scentralizowanego wystarcza
  w zasadzie straznik z karabinem. System
  rozproszony nie moze byc chroniony w ten sposób,
  przez co moze byc narazony na róznorodne ataki
  (wlamania, wirusy, sabotaz, odmowa platnosci,
  itd.) z wielu stron, które trudno zidentyfikowac.
  
• Zdolnosc do zarzadzania jest ona utrudniona
  wskutek tego, ze konsekwencje róznych dzialan
  administracyjnych w systemie rozproszonym sa
  trudniejsze do zidentyfikowania. Podobnie z
  przyczynami sytuacji anormalnych, w szczególnosci
  awarii.
• Nieprzewidywalnosc system rozproszony jest
  nieprzewidywalny w swoim dzialaniu, poniewaz
  zaklócenia moga byc powodowane przez wiele
  przyczyn mala przepustowosc i awarie laczy,
  awarie komputerów, zbyt duze obciazenie danego
  serwera, lokalne decyzje administracji serwera,
  itd. patrz WWW.

14
Krytyczne zagadnienia projektowe dla systemów
rozproszonych

• Identyfikacja zasobów zasoby w systemie
  rozproszonym sa podzielone pomiedzy wiele
  komputerów, w zwiazku z czym schematy ich
  nazywania musza byc zaprojektowane tak, aby
  uzytkownicy mogli zidentyfikowac interesujace ich
  zasoby. Przykladem takiego schematu jest URL
  (Uniform Resource Locator) znany z WWW.
• Komunikacja moze byc zaprojektowana w sposób
  uniwersalny, na bazie np. protokolu internetowego
  TCP/IP lub któregos protokolu pochodnego (ftp,
  http, itd.). Niektóre wymagania dotyczace
  szybkosci, kosztu, niezawodnosci lub
  bezpieczenstwa moga prowadzic do specjalnych
  technik komunikacyjnych.
• Jakosc obslugi odzwierciedla wydajnosc systemu,
  jego dostepnosc i niezawodnosc. Podlega ona wielu
  czynnikom, w szczególnosci, przypisaniu zadan do
  procesorów, optymalnosci geograficznego podzialu
  danych, itd.
• Architektura oprogramowania opisuje ona w jaki
  sposób funkcjonalnosci systemu sa przypisane do
  logicznych i fizycznych komponentów systemu.
  Wybór dobrej architektury przesadza o spelnieniu
  kryterium jakosci obslugi.

15
Popularne architektury rozproszenia

• Klient-serwer rozproszony system ma wyrózniony
  wezel zwany serwerem, oraz szereg podlaczonych do
  niego wezlów zwanych klientami. Zwiazek nie jest
  symetryczny serwer wykonuje uslugi zlecane przez
  klientów, nie moze im odmówic i nie moze im
  zlecic wykonanie uslug.
• Klient-multi-serwer podobnie jak dla
  architektury klient-serwer, ale istnieje wiele
  serwerów. Przykladem jest WWW.
• Kolezenska (peer-to-peer, P2P) wiele wezlów
  swiadczy sobie wzajemne uslugi poprzez
  bezposrednie polaczenie nie ma wyraznego
  podzialu na uslugodawców i uslugobiorców.
  Przykladem jest Gnutella, NXOR, w mniejszym
  stopniu Napster ma centralne sterowanie.
  Komercyjny buzz dookola P2P.
• Architektura oparta na oprogramowaniu
  posredniczacym (middleware) nie wystepuje
  podzial na klientów i serwery. Wezly komunikuja
  sie poprzez specjalne oprogramowanie
  posredniczace, które zaklada wspólny
  (przezroczysty dla uzytkowników) protokól
  komunikacyjny. Przykladem jest CORBA (rozproszone
  obiekty), .NET/COM/DCOM, Java Beens/RMI, SOAP, ...

16
Rozproszone a scentralizowane BD
17
Co to jest rozproszona baza danych?
distributed database
Termin ten jest powtarzany w wielu kontekstach,
czesto bez przypisywania mu konkretnego,
technicznego znaczenia. Czy to, ze z pewnego
systemu mozna dostac sie do danych innego
odleglego systemu jest wystarczajacym wyróznikiem
rozproszonej bazy danych?

• Dla wielu zastosowan cecha ta jest istotna, lecz
• Rozproszona baza danych musi spelniac okreslone
  kryteria dotyczace spójnosci, bezpieczenstwa,
  zintegrowania i wygody uzytkowników.
• Mozliwosc dostania sie do danych innego systemu
  (np. poprzez pakiety oparte o standardy ODBC,
  JDBC, DCOM lub CORBA) oznacza wylacznie
  ustanowienie niezbednej bazy technicznej. Fakt
  ten nie przesadza jednak o tym, czy zachodza
  dostateczne warunki dla sprawnego, efektywnego
  oraz niezawodnego wykorzystywania danych.

18
Podstawowe pojecia zwiazane z rozproszeniem

• Rozproszona baza danych zbiór skladajacy sie z
  wielu logicznie ze soba powiazanych elementów
  bazy danych, oddalonych geograficznie i
  polaczonych ze soba poprzez siec komputerowa.
• System zarzadzania rozproszona baza danych
  (SZRBD) oprogramowanie umozliwiajace polaczenie
  rozproszonych zasobów w jedna calosc, utrzymanie
  spójnosc zasobów oraz udostepnianie ich
  uzytkownikom przy zalozeniu przezroczystosci
  rozproszenia.
• Dane sa przechowywane w wielu miejscach - wezlach
  sieci.
• Rozproszona baza danych jest baza danych, a nie
  kolekcja plików, które moga byc indywidualnie
  przechowywane w kazdym wezle sieci komputerowej.
• SZRBD posiada pelna funkcjonalnosc systemu
  zarzadzania scentralizowana BD. Nie jest to
  system zarzadzania rozproszonymi plikami, ani
  tez wylacznie system przetwarzania transakcji.

19
Przyklad rozproszonej bazy danych
Rozproszona baza danych dla linii lotniczych
(biuro obslugi klienta w Warszawie moze dostac
sie do danych linii lotniczych w Sydney, Tokio,
Paryzu, i setkach innych miast). Jezeli w kazdym
miejscu organizacja bazy danych, srodki
manipulacji, reguly dostepu, itd. bylyby inne, to
praca bylaby bardzo utrudniona. Zatem konieczne
sa

• standardy w zakresie polaczenia (protokoly),
• standardy w zakresie organizacji danych i dostepu
  do danych,
• moduly dla odwzorowania pewnej specyficznej bazy
  danych na format oczekiwany przez danego klienta,
• przezroczystosc rozproszenia (a la CORBA),
• zabezpieczenia przed niepowolanym dostepem.

20
Klasyfikacja rozproszonych baz danych
21
Klasyfikacja rozproszonych baz danych cd..
Systemy wielu baz danych (multidatabases)
Niefederacyjne rozproszone BD
Federacyjne BD
Rozproszone BD z globalnym schematem
Jednorodne BD
Slabo skojarzone (loosely coupled)
Scisle skojarzone (tightly coupled)
Pojedyncze federacje (pojedynczy schemat)
Wielokrotne federacje (wiele schematów)
Niefederacyjne BD brak autonomii. Slabo
skojarzone FBD brak federacyjnego schematu i
zarzadzania, operacje ad hoc, w zaleznosci od
aplikacji. Scisle skojarzone FBD FSZBD jest
odpowiedzialny za zarzadzanie caloscia federacji.
22
Postulaty rozproszenia BD
23
Komunikacja w rozproszonych BD
24
Wazne cechy rozproszonych BD

• Architektury rozproszonego przetwarzania bazy
  danych oparte o architekture klient-serwer, bazy
  danych oparte o schemat globalny.
• Federacyjne bazy danych - (przezroczyste)
  polaczenie wielu (relewantnych czesci)
  heterogenicznych i autonomicznych baz danych w
  jedna calosc.
• Przetwarzanie transakcji w rozproszonych bazach
  danych globalne transakcje, lokalne transakcje,
  dwufazowe i trójfazowe potwierdzenie (two-phase
  commit, 2PC).
• Dlugie transakcje, wymagajace oslabienia poziomu
  izolacji i minimalizujace ryzyku utraty juz
  wykonanej pracy.
• Wspóldzialanie heterogenicznych, autonomicznych,
  rozproszonych (Heterogeneous, Autonomous,
  Distributed, HAD) baz danych (okreslane takze
  jako wspóldzialanie multi baz danych,
  multidatabase interoperability).

25
Glówne problemy rozproszonych baz danych

• Wieloaspektowa niezgodnosc i konflikty miedzy
  lokalnymi bazami danych z powodu

• Awarii,
• Aktualizacji wielu zródel i ogniw rozproszonego
  srodowiska,
• Odniesienia danych do tej samej skali czasu

26
Tematy zwiazane z rozproszonymi BD

• Replikacje, czyli utrzymywanie kopii danych w
  wielu miejscach w rozproszonych bazach danych.
• Rozproszone przetwarzanie zapytan optymalizacja
  zapytan w sytuacji rozproszenia zasobów.
• Systemy operacyjne dla podtrzymywania
  rozproszenia OSF DCE i inne systemy oparte o
  wolanie odleglej procedury (Remote Procedure
  Call, RPC).
• Podtrzymywanie róznych form niewidocznosci
  rozproszenia (distribution transparency) dla
  programistów i klientów baz danych.
• Standardy w zakresie rozproszenia OMG CORBA,
  DCOM firmy Microsoft, RMI i Java Beans, OpenDoc,
  ActiveX, SOAP/XML. Posrednicy (broker, ORB) wg
  standardu CORBA, np. Orbix, Visibroker, ...

27
Tematy zwiazane z rozproszonymi BD cd..

• Srodki wspomagajace rozproszenie bazy danych i
  rozproszone przetwarzanie zrealizowane w
  konkretnych systemach relacyjnych (Oracle,
  Sybase, Ingres, i inne), post-relacyjnych lub
  obiektowo-relacyjnych (Informix Universal Server,
  DB2 Universal Database, Oracle8, UniSQL/X, OSMOS,
  OpenIngres, Sybase Adaptive Server i inne) oraz
  obiektowych (Gemstone, Versant, O2,
  Objectivity/DB, ObjectStore i inne).
• Niezawodnosc, spójnosc, bezpieczenstwo i
  prywatnosc w rozproszonych bazach danych.
• Rozproszone bazy danych w sieciach Internet oraz
  Intranet.
• Rozproszenie danych i przetwarzania w systemach
  pracy grupowej oraz systemach zarzadzania
  przeplywem pracy.

28
Transakcje w rozproszonych BD
29
Rozproszone BD relacyjne czy obiektowe?

• Prace prowadzone nad rozproszonymi BD (w ciagu
  ostatnich 20-tu lat), byly oparte glównie o
  relacyjny model danych.
• Zaletami modelu relacyjnego jest prosta,
  ujednolicona struktura danych oraz prosta
  organizacja katalogów bazy danych.
• W ostatnich latach obserwuje sie odchodzenie od
  modelu relacyjnego w strone modeli obiektowych.
• Zlozonosc samego problemu rozproszenia danych
  jest prawdopodobnie niezalezna od modelu danych.
• Niektóre metody systemów relacyjnych zwiazane z
  rozproszeniem daja sie przeniesc na grunt
  systemów obiektowych.
• Problemy nowe metamodel (ontologia),
  przetwarzania zapytan.
• W przeciagu najblizszych 10-ciu lat obiektowosc
  bedzie odgrywac glówna role w rozwijaniu
  koncepcji rozproszonych baz danych, w róznych
  wariantach, np. XML/RDF.

30
Reguly rozproszenia
31
Replikacja
32
Fragmentaryzacja
33
Reguly rozproszonych baz danych (1)
(C.J. Date, 1987)
12 regul w praktyce spelnienie wszystkich jest
trudne lub niemozliwe. Jest to spekulacyjny ideal.

• Autonomia lokalnych BD lokalne dane powinny
  podlegac lokalnym regulom wlasnosci i powinny byc
  zarzadzane lokalnie. Dotyczy to funkcji
  zwiazanych z bezpieczenstwem, integralnoscia i
  reprezentacja wewnatrz pamieci. Wyjatki dotycza
  sytuacji, kiedy wiezy integralnosci musza
  obejmowac jednoczesnie wiele miejsc oraz
  sytuacji, kiedy rozproszone transakcje musza byc
  sterowane przez pewne zewnetrzne miejsce.
• Brak podporzadkowania przetwarzania do
  konkretnego miejsca unikniecie waskich gardel
  dzieki decentralizacji wszystkich funkcji
  rozproszonego SZBD.
• Ciaglosc funkcjonowania Przestoje w wykonywaniu
  operacji nie powinny byc skutkiem dodania nowych
  miejsc, ich usuniecia ze srodowiska rozproszonej
  BD, dokonania zmian w meta-informacji lub
  unowoczesnienia wersji SZBD w pewnym
  indywidualnym miejscu.

34
Reguly rozproszonych baz danych (2)

• Niezaleznosc od lokalizacji Uzytkownicy lub
  programy aplikacyjne nie musza wiedziec, gdzie
  dane sa fizycznie przechowywane.
• Niezaleznosc od fragmentacji Fragmenty jednego
  zbioru danych moga byc przechowywane i zarzadzane
  przez rozproszony SZBD jako jedna calosc, bez
  uswiadamiania uzytkowników lub aplikacji o
  sposobie ich rozczlonkowania. Pozadana wlasnoscia
  rozproszonego SZBD jest to, aby w sposób
  automatyczny unikal przetwarzania nierelewantnych
  fragmentów.
• Np. jezeli grupa obiektów jest podzielona
  geograficznie ze wzgledu na atrybuty w ten
  sposób, ze atrybuty A1...Am sa w miejscu X, zas
  atrybuty Am1...An sa w miejscu Y, i konkretne
  zapytanie odwoluje sie wylacznie do atrybutów
  A1...Am, nalezy pominac odwolania do miejsca Y
  podczas realizacji tego zapytania.
• Podobnie, fragmenty tej samej tabeli w róznych
  miejscach rozproszonej bazy danych powinny byc
  widocznej jako jedna tabela.

35
Reguly rozproszonych baz danych (3)

• Niezaleznosc od replikacji Istnienie replik
  danych w wielu miejscach, ich pojawianie sie lub
  usuwanie nie powinno wplywac na postepowanie
  uzytkowników ani na poprawnosc badz spójnosc
  aplikacji.
• Rozproszone przetwarzanie zapytan System
  powinien zapewniac sprawne przetwarzanie
  rozproszonych zapytan umozliwiajace zredukowanie
  zarówno czasu przetwarzania, jak i obciazenia
  sieci transmisji danych.
• Zarzadzanie rozproszonymi transakcjami Zasady
  zarzadzania transakcjami oraz sterowania
  wspólbieznoscia powinny obowiazywac dla operacji
  w rozproszonej bazie danych. Zasady te wlaczaja
  wykrywanie i usuwanie zakleszczen (deadlocks),
  zarzadzanie przekroczeniami dopuszczalnego czasu
  (timeout), rozproszone protokóly potwierdzenia
  (commit) i odwracania (rollback), oraz inne
  metody.
• Niezaleznosc od sprzetu oprogramowanie
  rozproszonego SZBD powinno pracowac na róznych
  platformach sprzetowych.

36
Reguly rozproszonych baz danych (4)

• Niezaleznosc od systemu operacyjnego
  oprogramowanie rozproszonego SZBD powinno
  pracowac pod róznymi systemami operacyjnymi.
• Niezaleznosc od sieci Miejsca moga byc polaczone
  poprzez szeroka game srodowisk sieciowych i
  komunikacyjnych. Modele warstwowe istniejace dla
  wspólczesnych protokólów komunikacyjnych
  (obowiazujace w wiekszosci obecnych systemów
  informacyjnych, takich jak OSI 7, TCP/IP, warstwy
  SNA i DECnet) zapewniaja srodki do osiagniecia
  tego celu nie tylko dla rozproszonych baz danych,
  lecz w ogólnosci dla systemów informacyjnych.
• Niezaleznosc od SZBD Powinno byc mozliwe
  przylaczenie do rozproszonej bazy danych lokalnej
  bazy danych zarzadzanej przez dowolny lokalny
  SZBD.

37
Regula niezaleznosc od centralnego miejsca

• Rozproszona baza danych nie moze zalezec od
  jednego, centralnego miejsca odpowiedzialnego za
  calosc funkcjonowania.
• Zaleznosc taka moze "wkrasc sie" niepostrzezenie,
  jako konsekwencja pewnych (wydawaloby sie
  drugorzednych) decyzji projektowych, np.
  powolanie jednego serwera nazw, lub rejestracja
  nowych miejsc przylaczajacych sie do rozproszonej
  bazy danych.
• Zaleznosc taka jest niekorzystna, gdyz
• Centralne miejsce moze stac sie waskim gardlem
  dla operacji na danych
• Awaria centralnego miejsca powoduje awarie calej
  rozproszonej bazy danych.
• Dla niektórych zastosowan brak centralnego
  miejsca jest niekorzystny
• z powodu nadmiernego wzrostu obciazenia sieci
  zwiazanego z wymiana metadanych
• z powodu zbyt niskiej wydajnosci (indeksy w
  jednym miejscu)
• z powodów biznesowych centralne miejsce jest
  wygodne dla kontrolowania pozostalych miejsc.

38
Nazwy elementów danych w rozproszonych BD

• Problem nazywania i identyfikacji danych w
  rozproszonych BD staje sie znacznie bardziej
  trudny niz w scentralizowanych BD.
• Kryteria zarzadzania nazwami
• 1. Kazda dana, która ma byc niezaleznie
  identyfikowana w systemie rozproszonym, musi miec
  swoja unikalna nazwe (identyfikator).
• 2. Nazwa powinna zapewniac efektywne odszukanie
  lokalizacji danej.
• 3. Nazwa nie powinna utrudniac zmiany lokalizacji
  danej.
• 4. Kazde lokalne miejsce w rozproszonej BD
  powinno powinno miec mozliwosc autonomicznego
  nadawania unikalnych nazw dla danych.
• Centralny serwer nazw - nadaje wszystkie nazwy,
  udziela informacji o lokalizacji nielokalnych
  danych na podstawie ich nazw
• nie spelnia warunku 4,
• moze powodowac waskie gardlo dla transakcji,
• jest pojedynczym powodem awarii calosci.
• Rozwiazanie prefiksowanie nazwy identyfikatorem
  miejsca - trudnosci ze zmiana lokalizacji danych
  (przy zachowaniu tozsamosci).

39
Pojecia zwiazane z rozproszeniem
40
Glówne aspekty rozproszenia baz danych (1)
Przezroczystosc (transparency)
Rozproszony SZBD powinien podtrzymywac
rozproszenie danych przy zalozeniu odizolowania
programisty/uzytkownika od wiekszosci aspektów
rozproszenia.
Wspóldzialanie (interoperability)
Oznacza wspólprace zbudowanych niezaleznie od
siebie heterogenicznych systemów (heterogeneous
systems). Aspektem wspóldzialania jest
przylaczenie do rozproszonej BD starych systemów,
tzw. spadkowych (legacy)
Przenaszalnosc (portability)
Wlasnosc jezyka programowania i jego
kompilatorów/interpreterów umozliwiajaca
przenoszenie programów na rózne platformy.
41
Glówne aspekty rozproszenia baz danych (2)
Autonomia (autonomy)
Lokalne bazy danych podlegaja wlasnym lokalnym
regulom. Tylko okreslona czesc lokalnych zasobów
i uslug jest udostepniana na zewnatrz.
Niezaleznosc danych (data independence)
Mozliwosc projektowania, utrzymywania,
udostepniania, zmiany nosników, zmiany
reprezentacji, itp. dzialan na danych niezaleznie
od programów, które na nich operuja.
Ontologia (ontology), czesto w kontekscie
"ontologia biznesowa"
Formalny opis wszystkich tych wlasnosci lokalnej
bazy danych, które sa niezbedne do tego, aby
projektant/programista mógl prawidlowo
zaprogramowac nowa aplikacje (np. mobilnego
agenta). Niekiedy ontologia jest okreslana jako
metadane.
42
Przezroczystosc (1)
Rozproszona BD musi spelniac warunki komfortu
pracy programistów, administratorów i
uzytkowników, jak równiez niezawodnosci,
bezpieczenstwa danych, zwiekszenie odpornosci na
bledy programistów. To oznacza koniecznosc
redukcji zlozonosci przy pracy z rozproszona baza
danych, co jest okreslane jako przezroczystosc.
Ma ona nastepujace formy

• Przezroczystosc polozenia Umozliwienie
  jednorodnych metod operowania na lokalnych i
  odleglych danych. Tego warunku nie spelnia np.
  system, w którym lokalna baza danych jest
  obslugiwana przez pewien jezyk 4GL, zas odlegla
  - przez specjalny zestaw procedur (API).
• Przezroczystosc dostepu Uwolnienie uzytkowników
  od koniecznosci(a niekiedy równiez
  uniemozliwienie) korzystania z informacji o
  aktualnym polozeniu danych.

43
Przezroczystosc (2)

• Przezroczystosc wspólbieznosci Umozliwia wielu
  uzytkownikom jednoczesny dostep do danych bez
  koniecznosci uzgodnien i porozumiewania sie, przy
  zapewnieniu pelnej spójnosci danych i
  przetwarzania.
• Przezroczystosc skalowania Umozliwienie
  dodawania nowych elementów bazy danych bez
  wplywu na dzialanie starych aplikacji i prace
  uzytkowników.
• Przezroczystosc replikacji Umozliwienie
  tworzenia i usuwania kopii danych w innych
  miejscach geograficznych z bezposrednim skutkiem
  dla efektywnosci przetwarzania, ale bez skutków
  dla postaci programów uzytkowych lub pracy
  uzytkownika koncowego.
• Przezroczystosc wydajnosci Umozliwienie
  dodawania nowych elementów systemu komputerowego
  (np. serwerów, dysków) bez wplywu na prace
  wiekszosci uzytkowników rozproszonej bazy danych.

44
Przezroczystosc (3)

• Przezroczystosc fragmentacji (podzialu)
  automatyczne scalanie obiektów, tabel lub
  kolekcji, których fragmenty sa przechowywane w
  róznych miejscach.
• Przezroczystosc awarii Umozliwienie
  nieprzerwanej pracy wiekszosci uzytkowników
  rozproszonej bazy danych w sytuacji, gdy niektóre
  z jej wezlów lub linie komunikacyjne ulegly
  awarii.
• Przezroczystosc migracji Umozliwienie
  przenoszenia zasobów danych do innych miejsc bez
  wplywu na prace uzytkowników.

W praktyce spelnienie wszystkich wymienionych
warunków jest idealem, który prawdopodobnie nie
zostal zrealizowany w zadnym ze znanych systemów.
45
Wspóldzialanie i heterogenicznosc
interoperability, heterogeneity

• Umozliwienie wspóldzialania heterogenicznych
  systemów baz danych jest drugim waznym aspektem
  rozproszenia.
• Heterogenicznosc jest nieodlaczna cecha duzych
  sieci komputerowych, takich jak Internet, WWW,
  sieci intranetowych, rozproszonych baz danych,
  systemów przeplywu prac, zasobów WWW opartych na
  plikach HTML i XML, itd.

46
Heterogenicznosc (niejednorodnosc)

• Np. system Intranetowy moze skladac sie ze
  sprzetu
• komputerów klasy mainframe
• stacji roboczych UNIX
• komputerów PC pracujacych pod MS Windows
• komputerów Apple Macintosh
• central telefonicznych, robotów,
  zautomatyzowanych linii produkcyjnych
• ...wlaczac róznorodne protokoly komunikacyjne
  Ethernet, FDDI, ATM, TCP/IP, Novell Netware,
  protokoly oparte na RPC,...
• ...bazowac na róznych systemach zarzadzania baza
  danych/dokumentów Oracle,SQL Server, DB2, Lotus
  Notes,....
• ...oraz wymieniac pomiedzy soba niejednorodne
  dane, podlegajace róznym modelom danych,
  schematom, semantyce, mechanizmom dostepu,...

47
Przyczyny heterogenicznosci

• Niezaleznosc dzialania wytwórcy systemów nie
  uzgadniaja miedzy soba ich cech. Standardy, o ile
  sie pojawiaja, sa spóznione, niekompletne i nie
  przestrzegane w 100.
• Konkurencja wytwórcy systemów staraja sie
  wyposazyc systemy w atrakcyjne cechy, których nie
  posiadaja konkurujace systemy
• Róznorodnosc pomyslów Nie zdarza sie, aby bylo
  jedno rozwiazanie dla zlozonego problemu. Rózne
  zespoly znajduja rózne rozwiazania, bazujace
  czesto na odmiennych celach i zalozeniach.
• Efektywnosc finansowa i kompromisy Wytwórcy
  oferuja produkty o róznej cenie, funkcjonalnosci
  i jakosci, zgodnie z wyczuciem potencjalnych
  potrzeb klientów, dostosowaniem sie do ich
  portfela i maksymalizacja swoich zysków.
• Systemy spadkowe (legacy) Systemy, które dawno
  zostaly wdrozone i dzialaja efektywnie, nie moga
  byc z tego dzialania wylaczone. Nie jest mozliwe
  (lub jest bardzo kosztowne) zastapienie ich
  nowymi systemami. Nowe systemy, o podobnym
  przeznaczeniu, posiadaja inne zalozenia, cechy i
  funkcjonalnosci

48
Przenaszalnosc
portability

• Typy przenaszalnosci
• Na poziomie skladni, koncepcji jezyka i edukacji
  (np. SQL-92).
• Na poziomie kodu zródlowego (np. C (?), JDBC).
• Na poziomie interpretowanego kodu skryptowego
  lub posredniego (np. Java).
• Na poziomie kodu binarnego (? - trudno podac
  przyklad).

• Przenaszalnosc wymaga precyzyjnej specyfikacji
  skladni i semantyki jezyka, oraz wyeliminowania z
  niego wlasnosci specyficznych dla poszczególnych
  platform.
• Wiele standardów nie spelnia kryterium
  przenaszalnosci z powodu niedospecyfikowania
  i/lub nie spelniania standardu przez wytwórców
  systemów.
• Przenaszalnosc jest celem standardów SQL, CORBA
  oraz ODMG, niekoniecznie celem juz osiagnietym.
• Przenaszalnosc realizuje kod posredni jezyka
  Java, ale dotyczy to funkcjonalnosci niskiego
  poziomu, np. nie dotyczy API do baz danych.

49
Autonomia
autonomy
Autonomia lokalnej bazy danych w federacji baz
danych oznacza, ze

• Lokalne dane podlegaja lokalnym priorytetom,
  regulom wlasnosci, autoryzacji dostepu,
  bezpieczenstwa, itd. Lokalna baza danych moze
  odrzucic zlecenia przychodzace z federacji, o ile
  naruszaja one lokalne ograniczenia lub zbytnio
  obciazaja czas procesora lub inne lokalne zasoby.
• Lokalna baza danych moze udostepniac aplikacjom
  dzialajacym na federacji baz danych tylko
  okreslona czesc swoich danych i uslug.
  Programisci tych aplikacji nie maja jakichkolwiek
  srodków dostepu do pozostalych danych i uslug.
• Wlaczenie lokalnej bazy danych do federacji nie
  moze powodowac koniecznosci zmiany programów
  aplikacyjnych dzialajacych na lokalnej BD.
• Federacja moze przetwarzac lokalne zasoby tylko
  poprzez interfejs programowania aplikacji (API)
  specyficzny dla lokalnego systemu. Inne metody
  (np. bezposredni dostep do plików) sa
  niedozwolone.
• Federacja nie moze zadac od lokalnej bazy danych
  zmiany/rozszerzenia jej uslug (np. udostepnienia
  lokalnego dziennika transakcji).

Mozliwa jest pewna skala autonomii. Pojecie
autonomii jest raczej intuicyjne.
50
Niezaleznosc danych
data independence
Oznacza, ze nie ma potrzeby zmiany kodu programów
aplikacyjnych mimo zmian organizacji lub
schematów danych. Jest osiagana poprzez
interfejsy programistyczne umozliwiajace dostep
do danych na odpowiednim poziomie abstrakcji, gdy
niewidoczne sa szczególy organizacji i
implementacji danych.

• Fizyczna niezaleznosc danych ukrycie detali
  organizacji fizycznej i technik dostepu, dzieki
  czemu mozliwa jest ich zmiana bez wplywu na kod
  aplikacji.
• Logiczna niezaleznosc danych umozliwienie
  niektórych zmian schematu logicznego bez wplywu
  na kod aplikacji, np. dodanie atrybutów do
  relacji, zmiana kolejnosci atrybutów, zmiana ich
  typów, utworzenie nowych relacji, itd.
• Ewolucja schematu (schema evolution)
  umozliwienie daleko idacych zmian schematu danych
  przy jednoczesnym utworzeniu perspektyw (views)
  dla starych lub nowych danych. Perspektywy maja
  umozliwic minimalna pracochlonnosc przy zmianach
  aplikacji (idealistycznie).

51
Ontologia
ontology

• W filozofii nauka o bytach, teoria bytu, opis
  charakteru i struktury rzeczywistosci,
  specyfikacja konceptualizacji.
• W sztucznej inteligencji formalna specyfikacja
  (przy uzyciu logiki matematycznej) obiektów,
  pojec i innych bytów, które istnieja w pewnej
  dziedzinie, oraz formalna specyfikacja zwiazków,
  które pomiedzy tymi bytami zachodza.
• Podejscie sztucznej inteligencji jest naiwne.
• Np. Gielda Papierów Wartosciowych wiele tysiecy
  stron aktów prawnych, zarzadzen, regulacji, itd.
  Jako (dozywotnia) kara dla sztucznego (cwierc-)
  inteligenta wypisujacego bzdury na temat
  "formalnej ontologii" niech to zapisze przy
  uzyciu formul rachunku predykatów.
• W biznesie (ontologia biznesowa, business
  ontology) wszystko to, co projektanci systemów
  informatycznych powinni wiedziec o biznesie, aby
  poprawnie napisac aplikacje wspomagajace ten
  biznes. Wiedza ta powinna byc formalnie zapisana.
  "Formalnie" oznacza zwykle pewien standardowy i
  uzgodniony jezyk, np. XML/RDF.

52
Ontologia i metadane

• Glównym celem prac na biznesowa ontologia jest
  standardyzacja nastepujacych elementów
• Gramatyki opisów poszczególnych bytów,
• Nazw i znaczen nazw obowiazujacych w ramach
  danego biznesu (np. co oznaczaja slowa "autor",
  "klient", "instrument", "akcja", itd.),
• Ograniczen zwiazanych z opisywanymi bytami,
• Metadanych zwiazanych z bytami (autor opisu, data
  stworzenia opisu, data ostatniej aktualizacji,
  itd.),
• Dopuszczalnych operacji na bytach.
• W tym zakresie zapis ontologii jest pewna
  meta-baza danych, w które ustala sie zarówno
  strukture samej bazy danych, jak i pewne
  dodatkowe informacje (meta-atrybuty) bedace
  podstawa przetwarzania bazy danych.
• Nieco inne podejscie prezentuje standard RDF
  opracowany przez W3C, gdzie ontologie
  reprezentuja wyrazenia RDF.

53
Metadane

• Metadane sa kluczowe dla wielu rozproszonych
  aplikacji, poniewaz umozliwiaja rozpoznanie z
  zewnetrz wlasnosci lokalnego zasobu danych
• Ogólna definicja sa to dane o danych - co dane
  zawieraja, jaka maja budowe, jakie jest ich
  znaczenie, jakim podlegaja ograniczeniom, jak sa
  zorganizowane, przechowywane, zabezpieczane,
  udostepniane, itd.
• Metadane sa pewnym rozszerzeniem pojecia schematu
  bazy danych, albo tez pewna implementacja tego
  schematu w postaci katalogów.
• Metadane przykrywaja takze informacje niezalezna
  od tresci samych danych, np. kiedy pewna dana
  zostala utworzona, w jakim jest formacie, kto
  jest jej autorem, do kiedy jest wazna, itd.
• Opisy danych zawarte w metadanych maja dwie
  podstawowe zalety
• Zawieraja wspólne abstrakcje dotyczace
  reprezentacji danych, takie jak format ogólnie
  "wyciagaja przed nawias" wszystkie wspólne
  informacje, co redukuje znacznie objetosc samych
  danych
• Reprezentuja wiedze dziedzinowa (ontologie)
  umozliwiaja wnioskowanie o danych, moga byc przez
  to uzyte do redukowania dostepu do samych danych.

54
Klasyfikacja metadanych

• Metadane niezalezne od tresci danych lokacja
  danych, data modyfikacji, typ kamery sluzacej do
  sporzadzenia zdjecia, itd. Mimo, ze nie skladaja
  sie bezposrednio na tresc danych, moga byc waznym
  kryterium wyszukiwania.
• Metadane zalezne od tresci danych rozmiar
  dokumentu, liczba kolorów, liczba wierszy, liczba
  kolumn w tabeli. Metadane zalezne od tresci moga
  byc dalej podzielone na
• Bezposrednie metadane dotyczace tresci, np.
  indeksy, klasyfikacje, itd.
• Metadane opisujace tresc adnotacje o zawartosci
  zdjecia, np. opis zapachu kwiatu przedstawionego
  na zdjeciu.
• Metadane niezalezne od dziedziny biznesowej,
  której dotyczy tresc, np. definicje typu
  dokumentu HTML/SGML
• Metadane zalezne od dziedziny biznesowej, np.
  schemat danych lub opis ontologii biznesowej
• Podzial na dane i metadane nie jest do konca
  jasny i silnie zalezy od nastawienia projektanta
  i podzialu zadan podczas redakcji tresci danych.

55
Protokól wymiany informacji w rozproszonej BD

• Protokól wymiany informacji pomiedzy
  rozproszonymi miejscami musi uwzgledniac
• przesylanie danych z jednego miejsca do drugiego
  miejsca
• przesylanie zlecen (np. zapytan) do odleglych
  miejsc celem przetwarzania danych
• zwrotne przesylanie wyników tych zlecen do
  zlecajacego klienta
• automatyczna dystrybucje niektórych metadanych
  (np. schematu BD) pomiedzy uczestników
  rozproszonej bazy danych.
• przesylanie zapytan dotyczacych metadanych
• przekazywanie wyników zapytan dotyczacych
  metadanych do pytajacego
• Aktualnie, protokoly takie istnieja w bardzo
  uproszczonej lub silnie wyspecjalizowanej formie
• IIOP (Internet Inter-Orb Protocol) - bardzo
  uproszczony
• LDAP (Lightweight Directory Access Protocol) -
  silnie wyspecjalizowany
• Wiele osrodków prowadzi prace badawcze nad
  uniwersalnymi protokolami, opartymi o róznorodne
  jezyki zapytan.

56
Migracje obiektów
Migracja przemieszczanie sie obiektów miedzy
wezlami sieci, przy czym obiekty musza byc
skojarzone (statycznie lub dynamicznie zwiazane)
ze swoimi klasami i przechowywanymi w ramach tych
klas metodami. Problemy

• Okreslenie jednostki migracji
• Sledzenie obiektów
• Utrzymywania porzadku w katalogu systemu bazy
  danych
• Okresowa kondensacja lancuchów obiektów
  posrednich
• Przemieszczanie obiektów zlozonych
• Zapewnienie globalnej przestrzeni nazw
• Zapewnienie wlasciwych mechanizmów zakresu i
  wiazania
• Dostepnosc metod umozliwiajacych przetwarzanie
  obiektów

Jak dotad, metody sa najczesciej skladowymi
aplikacji, a nie bazy danych. Konsekwencja jest
to, ze po przemieszczeniu obiektu aplikacja
dzialajaca w jego nowym miejscu musi miec
wbudowane (powielone, skompilowane, zlinkowane)
metody do jego przetwarzania.
57
Oprogramowanie komponentowe
Komercyjny buzzword, niezrealizowane marzenie
informatyków od 30 lat. Oznacza technologie
zmierzajace do budowy standardów oraz
wspomagajacego je oprogramowania, które
pozwoliloby na skladanie duzych aplikacji lub
systemów z mniejszych standardowych czesci -
komponentów, na zasadzie podobnej do skladania
komputera z podzespolów. Inne terminy
mega-programming, programming-in-the-large.
Jako przyklady komponentowego podejscia wymienia
sie OMG CORBA, OpenDoc firm Apple, IBM i innych,
technologia .NET/COM/DCOM, Java Beans i
Enterprise Java Beans.
Komponenty odnosza wiele sukcesów. Istnieja
jednak problemy utrudniajace szerokie ich
stosowanie, tj

• problemy z osiagnieciem akceptowalnej wydajnosci,
  
• trudnosci w precyzyjnym a jednoczesnie
  dostatecznie abstrakcyjnym wyspecyfikowaniu
  interfejsów pomiedzy komponentami,
• dynamiczny postep w informatyce, powodujacy
  pojawianie sie coraz to nowych wymagan na
  interfejsy.

58
Obiektowosc w systemach rozproszonych
59
Obiektowosc w rozproszonych bazach danych

• Obiektowosc zaklada zwiekszenie stopnia
  abstrakcji, przystosowanie modeli realizacyjnych
  systemów informatycznych do naturalnych
  konstrukcji i obrazów myslowych projektantów,
  programistów i uzytkowników.
• Glówny problem - opanowanie zlozonosci przy
  wytwarzaniu oprogramowania.
• Punktem zainteresowania twórców narzedzi
  informatycznych staja sie procesy myslowe
  zachodzace w umyslach osób pracujacych nad
  oprogramowaniem gt modelowanie pojeciowe.
• Obiektowosc przerzuca ciezar problemu z kwestii
  narzedziowej (jak mam to zrobic?) na kwestie
  merytoryczna (co mam zrobic i po co?).

60
Zródla zlozonosci projektu oprogramowania
Zespól projektantów podlegajacy ograniczeniom
pamieci, percepcji, wyrazania informacji i
komunikacji.
Dziedzina problemowa, obejmujaca ogromna liczbe
wzajemnie uzaleznionych aspektów i problemów.
Oprogramowanie decyzje strategiczne, analiza,
projektowanie, konstrukcja, dokumentacja, wdrozen
ie, szkolenie, eksploatacja, pielegnacja, modyfika
cja.
Potencjalni uzytkownicy czynniki
psychologiczne, ergonomia, ograniczenia pamieci i
percepcji, sklonnosc do bledów i naduzyc,
tajnosc, prywatnosc.
Srodki i technologie informatyczne sprzet,
oprogramowanie, siec, jezyki, narzedzia,
udogodnienia.
61
Jak walczyc ze zlozonoscia ?
Zasada dekompozycji rozdzielenie zlozonego
problemu na podproblemy, które mozna rozpatrywac
i rozwiazywac niezaleznie od siebie i niezaleznie
od calosci. Zasada abstrakcji eliminacja,
ukrycie lub pominiecie mniej istotnych szczególów
rozwazanego przedmiotu lub mniej istotnej
informacji wyodrebnianie cech wspólnych i
niezmiennych dla pewnego zbioru bytów i
wprowadzaniu pojec lub symboli oznaczajacych
takie cechy. Zasada ponownego uzycia
wykorzystanie wczesniej wytworzonych schematów,
metod, wzorców, komponentów projektu, komponentów
oprogramowania, itd. Zasada sprzyjania naturalnym
ludzkim wlasnosciom dopasowanie modeli
pojeciowych i modeli realizacyjnych systemów do
wrodzonych ludzkich wlasnosci psychologicznych,
instynktów oraz mentalnych mechanizmów percepcji
i rozumienia swiata.
62
Modelowanie pojeciowe
Projektant i programista musza dokladnie
wyobrazic sobie problem oraz metode jego
rozwiazania. Zasadnicze procesy tworzenia
oprogramowania zachodza w ludzkim umysle i nie sa
zwiazane z jakimkolwiek jezykiem programowania.
Pojecia modelowania pojeciowego (conceptual
modeling) oraz modelu pojeciowego (conceptual
model) odnosza sie procesów myslowych i wyobrazen
towarzyszacych pracy nad oprogramowaniem.
Modelowanie pojeciowe jest wspomagane przez
srodki wzmacniajace ludzka pamiec i wyobraznie.
Sluza one do przedstawienia rzeczywistosci
opisywanej przez dane, procesów zachodzacych w
rzeczywistosci, struktur danych oraz programów
skladajacych sie na konstrukcje systemu.
63
Perspektywy w modelowaniu pojeciowym
odwzorowanie
odwzorowanie
Percepcja rzeczywistego swiata
Analityczny model rzeczywistosci
Model struktur danych i procesów SI
Trwala tendencja w rozwoju metod i narzedzi
projektowania oraz konstrukcji SI jest dazenie do
minimalizacji luki pomiedzy mysleniem o
rzeczywistym problemie a mysleniem o danych i
procesach zachodzacych na danych.
64
Przyklad pojeciowy schemat obiektowy w UML
FZ
PZ
0..
0..
1
1
Nie wiecej niz 10 sekund zastanawiania sie, co
ten diagram przedstawia i jak jest semantyka jego
elementów. Potem mozna juz programowac np. w C
lub Java. Co otrzymamy po odwzorowaniu tego
schematu na schemat relacyjny?
65
Schemat relacyjny
Firma(NrF, Nazwa)
Zatrudnienie(NrF, NrP)
Lokal(NrF, Miejsce)
Pracownik(NrP, NrOs)
Oceny(NrOceny, Ocena, NrF, NrP)
Dochód(NrDochodu, Wyplata, NrF, NrP)
Osoba(NrOs, Nazwisko)
Wyszkolenie(Zawód, NrP)
Adresy(NrOs, Adres)
Imiona(NrOs, Imie)
Jest to jedno z kilku mozliwych
rozwiazan. Schemat relacyjny jest trudniejszy do
odczytania i zinterpretowania przez programiste.
Bedzie on musial co najmniej 10 minut zastanawiac
sie, co ten diagram reprezentuje i jaka semantyke
maja atrybuty i zaznaczone powiazania. Efektem
jest zwiekszona sklonnosc do bledów (mylnych
interpretacji).
66
Skutki niezgodnosci modelu pojeciowego i
relacyjnego
Programy odwolujace sie do schematu relacyjnego
sa dluzsze od programów odwolujacych sie do
schematu obiektowego (szacunkowo od 30 do 70).
Ma to ogromne znaczenie dla tempa tworzenia
oprogramowania, jego jakosci, pielegnacyjnosci,
itd. Programy te sa tez zwykle znacznie
wolniejsze.
Mini przyklad Podaj adresy pracowników
pracujacych w firmach zlokalizowanych w Radomiu
SBQL (Firma where Radom in Miejsce).FZ.Zatrudn
ienie.PZ.Pracownik.Adres SQL select a.Adres
from Lokal as k, Zatrudnienie as z,
Pracownik as p, Osoba as s, Adresy as a
where k.Miejsce Radom and k.NrF z.NrF
and z.NrP p.NrP and p.NrOs
s.NrOs and s.NrOs a.NrOs Zapytanie w SQL jest
znacznie dluzsze wskutek tego, ze w SQL konieczne
sa zlaczeniowe predykaty (takie jak k.NrFz.NrF
i nastepne) kojarzace informacje semantyczna
"zgubiona" w relacyjnej strukturze danych.
67
Rozproszone obiektowe bazy danych

• Problemy sa podobne jak w przypadku rozproszonych
  relacyjnych BD.
• Nie jest jednak pewne czy do przetwarzania
  zapytan w tych systemach beda sie odnosic te same
  metody.
• Problemy, rózniace przetwarzanie zapytan w
  rozproszonych obiektowych BD i w rozproszonych
  relacyjnych BD
• Obiekty nie zawsze sa implementowane jako
  "plaskie" zapisy.
• Obiekty moga miec referencje do obiektów
  zlokalizowanych w innych wezlach sieci.
• Przetwarzanie zapytan moze dotyczyc kolekcji
  zlozonych obiektów
• Zapytania moga miec odwolania do metod.
• Przetwarzanie zapytan w rozproszonych systemach
  obiektowych jest tematem bardzo istotnym.
  Standard ODMG tym sie nie zajmuje.
• Jak dotad, w zakresie przetwarzania rozproszonych
  zapytan nie rozwiazano podstawowych problemów
  koncepcyjnych.
• Niektóre z problemów moga nie miec ogólnego
  rozwiazania.

68
Rozproszona obiektowa baza danych
Przedmiotem przetwarzania i wymiany informacji w
obiektowej rozproszonej bazie danych sa obiekty.
Zarzadzanie rozproszonymi obiektami ma na celu
utrzymywanie spójnosci i przezroczystosci
(niewidocznosci) geograficznego rozproszenia
obiektów.
69
Zalety rozproszonych obiektów

• Zgodnosc z logika biznesu - bezposrednia
  implementacja obiektów biznesowych.
• Umozliwienie projektantom opóznienie decyzji -
  gdzie i jakie uslugi powinny byc zapewnione.
• Skalowalnosc aplikacji mala zaleznosc czasu
  reakcji systemu od zwiekszenia ilosci danych,
  liczby uzytkowników, liczby wezlów.
• Dekompozycja aplikacji na male elementy
  wykonawcze (obiekty, metody,...).
• Przyrostowe dodawanie/odejmowanie funkcjonalnosci
  (place tylko za to, czego uzywam).
• Podzial zasobów i zbalansowanie obciazen.
• Wspólbieznosc i asynchroniczne przetwarzanie.
• Elastycznosc zmian w oprogramowaniu
  (konserwacja), w szczególnosci, przenoszenie
  obiektów i uslug do innych miejsc.
• Mozliwosc przylaczania aplikacji spadkowych
  (funkcjonujacych wczesniej jako scentralizowane).

70
Projektowanie rozproszonych baz danych
71
Podejscia do projektowania rozproszonych BD
top-down i bottom-up
Od ogólu do szczególów Odgórne zaprojektowanie
calej bazy danych, z uwzglednieniem optymalizacji
przechowywanych danych, narzuconej przez fakt
geograficznego rozproszenia producentów i
konsumentów informacji przechowywanej w bazie
danych.
top-down
Od szczególów do ogólu Zintegrowanie juz
istniejacych (spadkowych) lub zaprojektowanych
lokalnych baz danych w jedna globalna rozproszona
baze danych.
bottom-up
72
Projektowanie podejscie top-down
Analiza systemowa rozpoznanie wymagan,
precyzowanie kontekstu przyszlej bazy
danych. Projektowanie schematu pojeciowego Projekt
owanie struktury logicznej Kryteria rozproszenia
sa zwiazane z faktem fizycznego rozproszenia
zródel i odbiorców danych oraz autonomii
lokalnych baz danych. Ustalaja one decyzje, które
fragmenty projektu pojeciowego beda przechowywane
w poszczególnych miejscach, a takze jak nalezy
zdekomponowac schemat logiczny na poszczególne
miejsca
Analiza
Model pojeciowy scentralizowany
Model logiczny scentralizowany
Kryteria rozproszenia
Modele logiczne dla poszczególnych miejsc
73
Dalsze fazy postepowania w podejsciu top-down

• Okreslenie danych podlegajacych replikacjom
  (lokalnych kopii) oraz strategii replikacji.
• Zróznicowanie logicznego schematu danych w
  zaleznosci od typu SZBD w poszczególnych
  miejscach.
• Okreslenie lokalnych schematów dla poszczególnych
  miejsc.
• Okreslenie danych autonomicznych dla
  poszczególnych miejsc, nie uczestniczacych w
  rozproszonej bazie danych co prowadzi do
  okreslenia schematu pojeciowego i logicznego dla
  danych widzianych z zewnatrz.
• Podzial schematu logicznego Wg róznych regul
  zwiazanych na ogól z fizycznym ulokowaniem
  obiektów rzeczywistych (np. osób zatrudnionych,
  sprzetu, co pociaga za soba odpowiedni podzial
  schematu logicznego) lub tez z fizycznym
  ulokowaniem programów aplikacyjnych dzialajacych
  na tych obiektach.

74
Fragmentacja

• Najpopularniejszym modelem jest fragmentacja
  pozioma, oznaczajaca, ze kazdy serwer ma ten sam
  schemat danych, ale inna populacje danych.
• Sumowanie zbiorów danych w taki sposób, ze
  informacja o serwerach jest zbedna dla
  programisty/uzytkownika.
• Fragmentacja pionowa podzial obiektów na
  fragmenty przechowywane w róznych miejscach.
• Musi byc zapewniony sposób sklejenia calosci
  obiektu z fragmentów (np. NIP dla obywateli RP).
• Przy integracji zasobów moga pojawiac sie
  wyrafinowane kombinacje fragmentacji poziomej,
  pionowej i replikacji (redundancji).

75
Podstawowe metody fragmentacji schematu

• Fragmentacja pionowa oznacza przyporzadkowanie
  poszczególnych klas obiektów do poszczególnych
  miejsc, lub rozbicie obiektów danej klasy na dwa
  lub wiecej podobiektów, przy czym takie
  podobiekty sa przechowywane w róznych miejscach.
• Fragmentacja pionowa moze oznaczac koniecznosc
  odpowiedniego podzialu informacji zawartych w
  klasach obiektów oraz ustalenia srodków
  podtrzymania jednoznacznej tozsamosci obiektów.
• Fragmentacja pozioma oznacza rozbicie populacji
  obiektów danej klasy na dwa lub wiecej miejsc
  geograficznych.
• Fragmentacja pozioma moze byc dokonywana na
  podstawie róznych kryteriów, które czesto wiazane
  sa z geograficznym ulokowaniem obiektów
  rzeczywistych, lub tez z geograficznym
  ulokowaniem przetwarzania tych obiektów.

76
Fragmentacja pionowa relacyjnej bazy danych
Warszawa
Kutno
DC
DOSTAWCA_DANE
DNR D1 D1 D1 D1 D1 D1 D2 D2 D3 D4 D4 D4
CNR C1 C2 C3 C4 C5 C6 C1 C2 C2 C2 C4 C5
ILOSC 300 200 400 200 100 100 300 400 200 200 300
400
DNR D1 D2 D3 D4 D5
NAZW Abacki Bober Czerny Dabek Erbel
STATUS 20 10 30 20 30
Siec
Gdansk
DOSTAWCA_MIASTO
DNR D1 D2 D3 D4 D5
MIASTO Lublin Poznan Poznan Lublin Radom
77
Fragmentacja pozioma relacyjnej bazy danych
DC
Poznan
DOSTAWCA
DNR D2 D2 D3
CNR C1 C2 C2
ILOSC 300 400 200
DNR D2 D3
NAZW Bober Czerny
STATUS 10 30
MIASTO Poznan Poznan
Lublin
Siec
78
Przyklad fragmentacji poziomej
Radom
Klasa Pracownik
Obiekty Pracownik sa przechowywane zgodnie z
geograficznym polozeniem pracodawcy.
Pracownik Nowak
Pracownik Kowalski
...
Siec
Klasa Pracownik
Kielce
Pracownik Malasa
Pracownik Zagórny.
...
79
Fragmentacja pionowa obiektów Pracownik
Siec
80
Fragmentacja danych
81
Inne fragmentacje danych w rozproszonej BD

• Mozliwe sa inne, bardziej zlozone fragmentacje
  danych, które lacza fragmentacje pionowe,
  fragmentacje poziome oraz redundantne dane
  (replikacje).
• Bardziej zlozone fragmentacje rodza trudnosci z
• zarzadzaniem metadanymi gdzies musza byc
  ulokowane informacje odnosnie tego w jaki sposób
  podzielone dane maja byc scalone w kompletne
  obiekty lub kolekcje w ramach rozproszonej bazy
  danych. Jest to rola metadanych oraz mechanizmu
  wlasciwej dystrybucji metadanych pomiedzy
  uczestników rozproszonej bazy danych.
• przetwarzaniem zapytan dekompozycja zapytania na
  pod-zapytania adresowane do poszczególnych miejsc
  staje sie znacznie bardziej klopotliwa.
  Przesylanie fragmentów obiektów celem ich
  zmaterializowania po stronie klienta moze byc
  zbyt kosztowne.
• Bardziej zlozone fragmentacje moga byc nie do
  unikniecia w rozproszonej bazie danych
  integrujacej istniejace bazy danych (podejscie
  bottom-up). Ma to konsekwencje dla zarzadzania
  metadanymi.

82
Replikacje

• Replikacja jest kopia danych i uslug na innym
  serwerze.
• Replikacje maja na celu zwiekszenie dostepnosci
  danych i uslug oraz ich ochrone przed
  zniszczeniem.
• Przy integracji bottom-up replikacje
  (redundancje) sa czesto cecha nieuchronna i
  niepozadana.
• Moze wystepowac redundancja danych o dowolnym
  stopniu skomplikowania.
• Replikacje i redundancje stanowia powazny problem
  dla przezroczystosci i operacji aktualizacji
  danych.

83
Projektowanie podejscie bottom-up

• Podejscie ad hoc Budowa uniwersalnych lub
  specyficznych dla danego zastosowania pomostów
  (gateways) umozliwiajacych dostep z danego
  systemu bazy danych do innych baz danych. Pomost
  moze (nie musi) zapewniac przezroczystosc
  rozproszenia.
• Podejscie oparte o globalny schemat Wszystkie
  skladniki rozproszonej BD sa objete jednym
  globalnym schematem, jednakowym dla kazdego
  miejsca i zapewniajacym przezroczystosc
  rozproszenia. Istotna wada podejscia opartego na
  globalnym schemacie jest brak mozliwosci
  sterowania zakresem autonomii kazdego lokalnego
  systemu.
• Federacyjna baza danych Kazda lokalna baza
  danych zachowuje swoja autonomie, udostepniajac
  tylko czesc danych dla innych miejsc w RBD.
  Podejscie federacyjne zaklada, ze kazda lokalna
  baza danych jest widziana poprzez pewna
  perspektywe (view), ukrywajaca niektóre dane dla
  rozproszonych aplikacji.

84
Replikacja
85
Federacyjna BD tworzona metoda bottom-up
Schemat federacyjnej bazy danych
.....
Podejscie federacyjne okazalo sie skuteczne ze
wzgledu na zapewnienie autonomii, bezpieczenstwa
i efektywnosci. Rodzi jednak duzo problemów,
m.in. z zapewnieniem jednolitej ontologii
biznesowej, uniwersalnoscia aplikacji,
wydajnoscia, itd.
86
Architektury rozproszonych baz danych
87
Architektura klient - serwer

• Serwer - komputer (proces) oferujacy okreslony
  rodzaj uslugi
• Klient - komputer (proces) korzystajacy z uslugi

88
Architektura klient-serwer
Calosc pracy wykonywanej przez system komputerowy
jest podzielona na dwie czesci
wykonywana po stronie klienta (zwykle zwiazana z
interakcja z uzytkownikiem)
wykonywana po stronie serwera (komunikacja,
dostep do bazy danych, zarzadzanie repozytoriami
pamieci, zarzadzanie globalna przestrzenia nazw)
Podstawowe problemy
Okreslenie mechanizmu komunikacji pomiedzy
klientem a serwerem.
Podzial funkcji na te, które sa wykonywane po
stronie klienta i te, które sa wykonywane po
stronie serwera
Okreslenie jednostki komunikacji klient - serwer
89
Heterogeniczne srodowisko w architekturze
klient-serwer
TCP/IP network
Windows NT Server with repository on SQLserver
UNIX Server with repository on Informix
90
Architektury serwerów w dostepie do bazy danych

• Serwer plików,
• Serwer SQL,
• Serwer obiektów,
• Serwer stron.

91
Architektura z serwerem plików
serwer
klient
Zapotrzebowanie na odczyt/zapis danych w plikach
Aplikacja po stronie klienta odwoluje sie do
danych umieszczonych w pliku bazy danych
Alokacja pamieci WE/WY obsluga plików z baza
danych
Odczytane dane z plików bazy danych
92
Transfer plików

• Protokól FTP (File Transfer Protocol)
• Usluga FTP
• kopiowanie plików z komputerów odleglych do
  komputera uzytkownika
• kopiowanie plików z komputera uzytkownika do
  komputerów odleglych
• Dostep do danych (ograniczony, system weryfikacji
  uzytkownika)
• Srodowisko pracy
• tekstowe (program ftp w srodowisku systemowym)
• graficzne (dedykowane aplikacji komercyjne,
  przegladarki)

93
Procedura transferu plików

• Podlaczenie sie do serwera odleglego
• Wejscie uzytkownika do systemu plików
• Nawigacja w strukturze katalogów
• Okreslenie rodzaju transferu
• Pobranie/osadzenie plików
• Zamkniecie polaczenia

94
Typowe instrukcje uslugi FTP

• open - podlaczenie sie do serwera
• user - wejscie uzytkownika do systemu (ftp,
  anonymous)
• close - zamkniecie polaczenia
• dir - wyswietlenie zawartosci katalogu na
  serwerze
• cd - zmiana katalogu biezacego na serwerze
• lcd - zmiana katalogu biezacego na komputerze
  klienta
• bin - binarny rodzaj transferu
• asc - znakowy rodzaj transferu
• put - przeslanie pliku z komputera klienta do
  serwera
• get - pobranie pliku z serwera
• mput - przeslanie plików z komputera klienta do
  serwera
• mget - pobranie plików z serwera

95
Architektura z serwerem SQL
Aplikacja klienta zadaje zapytanie SQL
Zapytanie SQL
Maszyna SQL
Zarzadzanie kursorem
krotka
serwer
klient
96
Architektura z serwerem stron
klient
serwer
aplikacja
Menadzer stron pamieci podrecznej
Pamiec podreczna stron
Menadzer dziennika blokowania
Menadzer obiektów
Menadzer plików/indeksów
Menadzer stron pamieci podrecznej
Alokacja pamieci WE/WY
strony
Pamiec podreczna obiektów
Pamiec podreczna stron
97
Architektura serwera stron
Aplikacja
Przedmiotem zarzadzania sa fizyczne strony dyskowe
strony
98
Architektura z serwerem obiektów
serwer
klient
Pamiec podreczna obiektów
Menadzer obiektów
Menadzer dziennika blokowania
Aplikacja
Menadzer plików/indeksów
Menadzer stron pamieci odrecznej
Pamiec podreczna stron
Menadzer obiektów
obiekty
Alokacja pamieci WE/WY
Pamiec podreczna obiektów
99
Architektura serwera obiektów
Przedmiotem zarzadzania sa obiekty
obiekty
100
Reguly architektury klient-serwer (1)

• Zachowanie autonomii serwera. Klienci powinni
  zachowywac reguly wykorzystania serwera, nie
  powinni powodowac jego niedostepnosc (np. zamykac
  duze ilosci danych), nie powinni lamac ograniczen
  integralnosci.
• Zachowanie autonomii klienta. Klienci nie powinni
  zachowywac sie róznie w zaleznosci od tego, czy
  serwer jest lokalny czy odlegly. Powinni byc
  odizolowani od kwestii fizycznego ulokowania
  danych.
• Wspomaganie dla aplikacji niezaleznych od
  serwera.
• Dostep do wlasnosci (danych, uslug) serwera.
  Klienci moga zadac od serwera wykonanie
  przewidzianych dla niego funkcji.
• Wspomaganie dla biezacego dostepu do danych.
  Dostep ten powinien byc bezposredni, bez
  posrednictwa plików przekazywanych do/od klienta.
• Minimalny wplyw architektury K/S na wymagania dla
  klienta. Oprogramowanie klienta w architekturze
  K/S nie powinno wykazywac znacznego zwiekszenia
  zapotrzebowania na RAM lub objetosc dysku.

101
Reguly architektury klient-serwer (2)

• Kompletnosc opcji niezbednych do polaczenia.
  Oprogramowanie klienta nie powinno zawierac kodu
  realizujacego polaczenie z serwerem.Powinien to
  zapewniac serwer