Docstoc

bd_cz-5-roszfederbazydanych

Document Sample
bd_cz-5-roszfederbazydanych Powered By Docstoc
					        SYSTEMY BAZ DANYCH
                                             Część V
                                           Rozproszone i
                                      federacyjne bazy danych




Opracowanie : Dr Bożena Śmiałkowska
Wprowadzenie do systemów
     rozproszonych
         Co to jest system rozproszony?
 Systemem rozproszonym nazywamy taki system, w którym
  przetwarzanie informacji odbywa się na wielu komputerach, często
  znacznie oddalonych geograficznie (od kilku metrów do dziesiątków
  tysięcy kilometrów). Przeciwieństwem jest system izolowany lub
  scentralizowany.
 Obecnie właściwie wszystkie systemy (poza domowymi komputerami) są
  rozproszone. Ogromnym katalizatorem rozproszenia systemów jest
  Internet. Komputer z Internetem można już uważać za system
  rozproszony.
 Projektowanie i własności systemów rozproszonych w dużej mierze są
  takie same jak systemów scentralizowanych, ale istnieją także istotne
  różnice, który specjalista inżynierii oprogramowania musi być świadomy.
 Tendencja do budowy systemów rozproszonych jest pochodną rozbudowy
  tanich, szybkich, uniwersalnych i niezawodnych sieci komputerowych.
 Przykłady systemów rozproszonych: sieć bankomatów, system rezerwacji
  biletów, system pracy grupowej, itd.
Co to jest system rozproszony?
    Cztery najważniejsze problemy do
     rozwiązania w systemach r.b.d.

 Przezroczystość (transparency): traktowanie rozproszonych zasobów i usług
  tak, jak gdyby były one wewnątrz przestrzeni adresowej jednego komputera.
 Bezpieczeństwo: przeciwdziałanie losowym awariom oraz możliwościom atak
  z zewnętrz.
 Interoperacyjność (interoperability): umożliwienie współpracy
  heterogenicznych platform, aplikacji, logik biznesowych i organizacji danych.
 Efektywność: uzyskanie czasów przetwarzania akceptowalnych dla szerokiego
  kręgu użytkowników rozproszonych aplikacji.
                Przezroczystość



 Redukcja złożoności przy pracy z rozproszonymi
  zasobami danych i usług, polegająca na uwolnieniu
  programisty od myślenia na temat położenia i organizacji
  rozproszonych danych.

 Przezroczystość ma bezpośrednie skutki dla czasu i
  kosztu wytworzenia rozproszonej aplikacji, jej
  przenaszalności i pielęgnacyjności.
        Formy przezroczystości (1)



 Przezroczystość położenia i dostępu: Uwolnienie
  użytkowników od konieczności korzystania z informacji o
  aktualnym położeniu geograficznym danych i usług.
 Przezroczystość współbieżności: Umożliwienie wielu
  użytkownikom jednoczesnego dostępu do danych i usług.
 Przezroczystość skalowania: Umożliwienie dodawania
  lub usuwania serwerów, danych i usług bez wpływu na
  działanie aplikacji i pracę użytkowników.
 Przezroczystość fragmentacji (podziału): automatyczne
  scalanie obiektów lub kolekcji, których fragmenty są
  przechowywane w różnych miejscach.
         Formy przezroczystości (2)


 Przezroczystość replikacji: Umożliwienie tworzenia i
  usuwania kopii danych w innych miejscach
  geograficznych ze skutkiem dla efektywności
  przetwarzania.
 Przezroczystość awarii: Umożliwienie nieprzerwanej
  pracy większości użytkowników rozproszonej bazy
  danych w sytuacji, gdy niektóre z jej węzłów lub linie
  komunikacyjne uległy awarii.
 Przezroczystość migracji: Umożliwienie przenoszenia
  zasobów danych do innych miejsc bez wpływu na pracę
  użytkowników.
                Interoperacyjność


 Krytyczny problem dla projektu bottom-up, czyli systemu
  integrującego istniejące (spadkowe) niekompatybilne
  (heterogeniczne) dane i usługi.
 Interoperacyjność na poziomie transportu (transport-level
  interoperability) jako podstawa wyższych form
  interoperacyjności. Chodzi o umożliwienie fizycznej
  komunikacji pomiędzy danymi i usługami, np. na gruncie
  TCP/IP, HTTP, wspólnej pamięci, itp.
Interoperacyjność kontra przezroczystość


  Konieczność poszukiwania kompromisowych rozwiązań na zasadzie tzw.
   „wspólnego rozwiązania”.
  Może być to łatwe: Dla danej populacji serwerów istnieje prosty model
   kanoniczny powiązań inter-operacyjnych w jedną przezroczystą całość.
  Może to być trudne: Jeżeli rozbieżności pomiędzy serwerami są duże, to
   informacja o zawartości poszczególnych serwerów musi być
   doprowadzona do programisty i do modelu kanonicznego. Jest to
   problem złożony i nieprzezroczysty.
     Zalety systemów rozproszonych cd..
 Podział zasobów: system rozproszony pozwala dzielić zasoby sprzętowe
  i programowe (pamięci dyskowe, drukarki, pliki, kompilatory, itd.)
  pomiędzy wielu użytkowników pracujących na różnych komputerach
  pracujących w sieci.
 Otwartość: jest ona definiowana jako zdolność systemu do dołączania
  nowego sprzętu, oprogramowania i usług. Otwarte systemy często mają tę
  zdolność również w stosunku do w/w zasobów ulokowanych na
  platformach sprzętowych i systemach operacyjnych dostarczanych przez
  różnych dostawców.
 Współbieżność: w systemie rozproszonym wiele procesów może działać
  w tym samym czasie na różnych komputerach w sieci. Procesy te mogą
  (jakkolwiek nie muszą) komunikować się podczas swego działania.
 Skalowalność: Moc i możliwości przetwarzania może wzrastać w miarę
  dodawania do systemu nowych zasobów, w szczególności komputerów.
  W praktyce skalowalność jest często ograniczona poprzez przepustowość
  sieci oraz (niekiedy) poprzez np. specyficzne protokoły wymiany
  informacji. Niemniej skalowalność systemu rozproszonego jest
       Zalety systemów rozproszonych (2)
 Tolerancja błędów: Dostępność wielu komputerów oraz umożliwienie
  zdublowania informacji (replikacje) oznacza, że rozproszony system jest
  tolerancyjny w stosunku do pewnych błędów zarówno sprzętowych jak i
  programowych. Np. awaria węzła komunikacyjnego powoduje
  wygenerowanie innej trasy przepływu informacji.
 Przezroczystość: Oznacza ukrycie przed użytkownikiem szczegółów
  rozproszenia, np. gdzie ulokowane są zasoby lub jak są one fizycznie
  zaimplementowane, pod jakim systemem pracują, itd. Przezroczystość
  ma zasadnicze znaczenie dla komfortu działania użytkownika oraz dla
  niezawodności budowanego oprogramowania. Niekiedy, np. dla celów
  optymalizacyjnych, użytkownik może zrezygnować z pełnej
  przezroczystości. Przykładem przezroczystości jest Internet: klikając w
  aktywne pole na stronie WWW nie interesujemy się, gdzie znajduje się
  odpowiadająca mu strona, oraz jak i na czym jest zaimplementowana.
         Wady systemów rozproszonych
 Złożoność: systemy rozproszone są trudniejsze do zaprogramowania i do
  administrowania niż systemy scentralizowane. Zależą od własności sieci,
  np. jej przepustowości i czasu transmisji, co utrudnia zaprojektowanie i
  zrealizowanie wielu algorytmów i procesów przetwarzania.
 Ochrona: Dla systemu scentralizowanego wystarcza w zasadzie strażnik
  z karabinem. System rozproszony nie może być chroniony w ten sposób,
  przez co może być narażony na różnorodne ataki (włamania, wirusy,
  sabotaż, odmowa płatności, itd.) z wielu stron, które trudno
  zidentyfikować.
 Zdolność do zarządzania: jest ona utrudniona wskutek tego, że
  konsekwencje różnych działań administracyjnych w systemie
  rozproszonym są trudniejsze do zidentyfikowania. Podobnie z
  przyczynami sytuacji anormalnych, w szczególności awarii.
 Nieprzewidywalność: system rozproszony jest nieprzewidywalny w
  swoim działaniu, ponieważ zakłócenia mogą być powodowane przez wiele
  przyczyn: małą przepustowość i awarię łączy, awarię komputerów, zbyt
  duże obciążenie danego serwera, lokalne decyzje administracji serwera,
    Krytyczne zagadnienia projektowe dla
          systemów rozproszonych
 Identyfikacja zasobów: zasoby w systemie rozproszonym są podzielone
  pomiędzy wiele komputerów, w związku z czym schematy ich nazywania
  muszą być zaprojektowane tak, aby użytkownicy mogli zidentyfikować
  interesujące ich zasoby. Przykładem takiego schematu jest URL (Uniform
  Resource Locator) znany z WWW.
 Komunikacja: może być zaprojektowana w sposób uniwersalny, na bazie
  np. protokołu internetowego TCP/IP lub któregoś protokołu pochodnego
  (ftp, http, itd.). Niektóre wymagania dotyczące szybkości, kosztu,
  niezawodności lub bezpieczeństwa mogą prowadzić do specjalnych
  technik komunikacyjnych.
 Jakość obsługi: odzwierciedla wydajność systemu, jego dostępność i
  niezawodność. Podlega ona wielu czynnikom, w szczególności,
  przypisaniu zadań do procesorów, optymalności geograficznego podziału
  danych, itd.
 Architektura oprogramowania: opisuje ona w jaki sposób
  funkcjonalności systemu są przypisane do logicznych i fizycznych
      Popularne architektury rozproszenia
 Klient-serwer: rozproszony system ma wyróżniony węzeł zwany
  serwerem, oraz szereg podłączonych do niego węzłów zwanych klientami.
  Związek nie jest symetryczny: serwer wykonuje usługi zlecane przez
  klientów, nie może im odmówić i nie może im zlecić wykonanie usług.
 Klient-multi-serwer: podobnie jak dla architektury klient-serwer, ale
  istnieje wiele serwerów. Przykładem jest WWW.
 Koleżeńska (peer-to-peer, P2P): wiele węzłów świadczy sobie wzajemne
  usługi poprzez bezpośrednie połączenie; nie ma wyraźnego podziału na
  usługodawców i usługobiorców. Przykładem jest Gnutella, NXOR, w
  mniejszym stopniu Napster ma centralne sterowanie. Komercyjny buzz
  dookoła P2P.
 Architektura oparta na oprogramowaniu pośredniczącym
  (middleware): nie występuje podział na klientów i serwery. Węzły
  komunikują się poprzez specjalne oprogramowanie pośredniczące, które
  zakłada wspólny (przezroczysty dla użytkowników) protokół
  komunikacyjny. Przykładem jest CORBA (rozproszone obiekty),
  .NET/COM/DCOM, Java Beens/RMI, SOAP, ...
Rozproszone a scentralizowane BD
       Co to jest rozproszona baza danych?
                                                             distributed database
Termin ten jest powtarzany w wielu kontekstach, często bez przypisywania mu
konkretnego, technicznego znaczenia.
Czy to, że z pewnego systemu można dostać się do danych innego odległego
systemu jest wystarczającym wyróżnikiem rozproszonej bazy danych?

   Dla wielu zastosowań cecha ta jest istotna, lecz
   Rozproszona baza danych musi spełniać określone kryteria
    dotyczące spójności, bezpieczeństwa, zintegrowania i wygody
    użytkowników.

   Możliwość dostania się do danych innego systemu (np. poprzez
    pakiety oparte o standardy ODBC, JDBC, DCOM lub CORBA)
    oznacza wyłącznie ustanowienie niezbędnej bazy technicznej. Fakt
    ten nie przesądza jednak o tym, czy zachodzą dostateczne warunki
    dla sprawnego, efektywnego oraz niezawodnego wykorzystywania
    danych.
        Podstawowe pojęcia związane z
               rozproszeniem
 Rozproszona baza danych: zbiór składający się z wielu logicznie
  ze sobą powiązanych elementów bazy danych, oddalonych
  geograficznie i połączonych ze sobą poprzez sieć komputerową.
 System zarządzania rozproszoną bazą danych (SZRBD):
  oprogramowanie umożliwiające połączenie rozproszonych
  zasobów w jedną całość, utrzymanie spójność zasobów oraz
  udostępnianie ich użytkownikom przy założeniu przezroczystości
  rozproszenia.
 Dane są przechowywane w wielu miejscach - węzłach sieci.
 Rozproszona baza danych jest bazą danych, a nie kolekcją plików,
  które mogą być indywidualnie przechowywane w każdym węźle
  sieci komputerowej.
 SZRBD posiada pełną funkcjonalność systemu zarządzania
  scentralizowaną BD. Nie jest to system zarządzania rozproszonymi
  plikami, ani też wyłącznie system przetwarzania transakcji.
        Przykład rozproszonej bazy danych
Rozproszona baza danych dla linii lotniczych (biuro obsługi klienta w
Warszawie może dostać się do danych linii lotniczych w Sydney, Tokio,
Paryżu, i setkach innych miast).
Jeżeli w każdym miejscu organizacja bazy danych, środki manipulacji,
reguły dostępu, itd. byłyby inne, to praca byłaby bardzo utrudniona.
Zatem konieczne są:
        standardy w zakresie połączenia (protokoły),
        standardy w zakresie organizacji danych i dostępu do
         danych,
        moduły dla odwzorowania pewnej specyficznej bazy danych
         na format oczekiwany przez danego klienta,
        przezroczystość rozproszenia (a la CORBA),
        zabezpieczenia przed niepowołanym dostępem.
Klasyfikacja rozproszonych baz danych
Klasyfikacja rozproszonych baz danych cd..
                              Systemy wielu baz danych
                                   (multidatabases)



      Niefederacyjne rozproszone BD               Federacyjne BD



Jednorodne      Rozproszone BD z           Słabo skojarzone    Ściśle skojarzone
    BD        globalnym schematem          (loosely coupled)    (tightly coupled)



Niefederacyjne BD: brak autonomii.                         Pojedyncze      Wielokrotne
                                                            federacje       federacje
Słabo skojarzone FBD: brak federacyjnego schematu i        (pojedynczy        (wiele
zarządzania, operacje ad hoc, w zależności od aplikacji.     schemat)      schematów)
Ściśle skojarzone FBD: FSZBD jest odpowiedzialny za
zarządzanie całością federacji.
Postulaty rozproszenia BD
Komunikacja w rozproszonych BD
        Ważne cechy rozproszonych BD
 Architektury rozproszonego przetwarzania: bazy danych oparte o
  architekturę klient-serwer, bazy danych oparte o schemat globalny.
 Federacyjne bazy danych - (przezroczyste) połączenie wielu
  (relewantnych części) heterogenicznych i autonomicznych baz
  danych w jedną całość.
 Przetwarzanie transakcji w rozproszonych bazach danych;
  globalne transakcje, lokalne transakcje, dwufazowe i trójfazowe
  potwierdzenie (two-phase commit, 2PC).
 Długie transakcje, wymagające osłabienia poziomu izolacji i
  minimalizujące ryzyku utraty już wykonanej pracy.
 Współdziałanie heterogenicznych, autonomicznych, rozproszonych
  (Heterogeneous, Autonomous, Distributed, HAD) baz danych
  (określane także jako współdziałanie multi baz danych,
  multidatabase interoperability).
Główne problemy rozproszonych baz danych



 Wieloaspektowa niezgodność i konflikty między
 lokalnymi bazami danych z powodu:

     Awarii,
     Aktualizacji wielu źródeł i ogniw rozproszonego
      środowiska,
     Odniesienia danych do tej samej skali czasu
    Tematy związane z rozproszonymi BD
 Replikacje, czyli utrzymywanie kopii danych w wielu miejscach w
  rozproszonych bazach danych.
 Rozproszone przetwarzanie zapytań; optymalizacja zapytań w
  sytuacji rozproszenia zasobów.
 Systemy operacyjne dla podtrzymywania rozproszenia: OSF DCE i
  inne systemy oparte o wołanie odległej procedury (Remote
  Procedure Call, RPC).
 Podtrzymywanie różnych form niewidoczności 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.
  Pośrednicy (broker, ORB) wg standardu CORBA, np. Orbix,
  Visibroker, ...
 Tematy związane z rozproszonymi BD cd..
 Środki wspomagające 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).
 Niezawodność, spójność, bezpieczeństwo i prywatność w
  rozproszonych bazach danych.
 Rozproszone bazy danych w sieciach Internet oraz Intranet.
 Rozproszenie danych i przetwarzania w systemach pracy grupowej
  oraz systemach zarządzania przepływem pracy.
Transakcje w rozproszonych BD
Rozproszone BD: relacyjne czy obiektowe?
 Prace prowadzone nad rozproszonymi BD (w ciągu ostatnich 20-tu
  lat), były oparte głównie o relacyjny model danych.
 Zaletami modelu relacyjnego jest prosta, ujednolicona struktura
  danych oraz prosta organizacja katalogów bazy danych.
 W ostatnich latach obserwuje się odchodzenie od modelu
  relacyjnego w stronę modeli obiektowych.
 Złożoność samego problemu rozproszenia danych jest
  prawdopodobnie niezależna od modelu danych.
 Niektóre metody systemów relacyjnych związane z rozproszeniem
  dają się przenieść na grunt systemów obiektowych.
 Problemy nowe: metamodel (ontologia), przetwarzania zapytań.
 W przeciągu najbliższych 10-ciu lat obiektowość będzie
  odgrywać główną rolę w rozwijaniu koncepcji rozproszonych
  baz danych, w różnych wariantach, np. XML/RDF.
Reguły rozproszenia
Replikacja
Fragmentaryzacja
      Reguły rozproszonych baz danych (1) 1987)
                                     (C.J. Date,

12 reguł: w praktyce spełnienie wszystkich jest trudne lub
niemożliwe. Jest to spekulacyjny ideał.

  Autonomia lokalnych BD: lokalne dane powinny podlegać
   lokalnym regułom własności i powinny być zarządzane lokalnie.
   Dotyczy to funkcji związanych z bezpieczeństwem, integralnością i
   reprezentacją wewnątrz pamięci. Wyjątki dotyczą sytuacji, kiedy
   więzy integralności muszą obejmować jednocześnie wiele miejsc
   oraz sytuacji, kiedy rozproszone transakcje muszą być sterowane
   przez pewne zewnętrzne miejsce.
  Brak podporządkowania przetwarzania do konkretnego
   miejsca: uniknięcie wąskich gardeł dzięki decentralizacji
   wszystkich funkcji rozproszonego SZBD.
  Ciągłość funkcjonowania: Przestoje w wykonywaniu operacji nie
   powinny być skutkiem dodania nowych miejsc, ich usunięcia ze
   środowiska rozproszonej BD, dokonania zmian w meta-informacji
   lub unowocześnienia wersji SZBD w pewnym indywidualnym
    Reguły rozproszonych baz danych (2)
 Niezależność od lokalizacji: Użytkownicy lub programy
  aplikacyjne nie muszą wiedzieć, gdzie dane są fizycznie
  przechowywane.
 Niezależność od fragmentacji: Fragmenty jednego zbioru danych
  mogą być przechowywane i zarządzane przez rozproszony SZBD
  jako jedna całość, bez uświadamiania użytkowników lub aplikacji o
  sposobie ich rozczłonkowania. Pożądaną własnością
  rozproszonego SZBD jest to, aby w sposób automatyczny unikał
  przetwarzania nierelewantnych fragmentów.
   • Np. jeżeli grupa obiektów jest podzielona geograficznie ze względu na
     atrybuty w ten sposób, że atrybuty A1...Am są w miejscu X, zaś
     atrybuty Am+1...An są w miejscu Y, i konkretne zapytanie odwołuje się
     wyłącznie do atrybutów A1...Am, należy pominąć odwołania do miejsca
     Y podczas realizacji tego zapytania.
   • Podobnie, fragmenty tej samej tabeli w różnych miejscach
     rozproszonej bazy danych powinny być widocznej jako jedna tabela.
    Reguły rozproszonych baz danych (3)
 Niezależność od replikacji: Istnienie replik danych w wielu
  miejscach, ich pojawianie się lub usuwanie nie powinno wpływać
  na postępowanie użytkowników ani na poprawność bądź spójność
  aplikacji.
 Rozproszone przetwarzanie zapytań: System powinien
  zapewniać sprawne przetwarzanie rozproszonych zapytań
  umożliwiające zredukowanie zarówno czasu przetwarzania, jak i
  obciążenia sieci transmisji danych.
 Zarządzanie rozproszonymi transakcjami: Zasady zarządzania
  transakcjami oraz sterowania współbieżnością powinny
  obowiązywać dla operacji w rozproszonej bazie danych. Zasady te
  włączają: wykrywanie i usuwanie zakleszczeń (deadlocks),
  zarządzanie przekroczeniami dopuszczalnego czasu (timeout),
  rozproszone protokóły potwierdzenia (commit) i odwracania
  (rollback), oraz inne metody.
 Niezależność od sprzętu: oprogramowanie rozproszonego SZBD
    Reguły rozproszonych baz danych (4)
 Niezależność od systemu operacyjnego: oprogramowanie
  rozproszonego SZBD powinno pracować pod różnymi systemami
  operacyjnymi.
 Niezależność od sieci: Miejsca mogą być połączone poprzez
  szeroką gamę środowisk sieciowych i komunikacyjnych. Modele
  warstwowe istniejące dla współczesnych protokółów
  komunikacyjnych (obowiązujące w większości obecnych systemów
  informacyjnych, takich jak OSI 7, TCP/IP, warstwy SNA i DECnet)
  zapewniają środki do osiągnięcia tego celu nie tylko dla
  rozproszonych baz danych, lecz w ogólności dla systemów
  informacyjnych.
 Niezależność od SZBD: Powinno być możliwe przyłączenie do
  rozproszonej bazy danych lokalnej bazy danych zarządzanej przez
  dowolny lokalny SZBD.
Reguła: niezależność od centralnego miejsca
 Rozproszona baza danych nie może zależeć od jednego,
  centralnego miejsca odpowiedzialnego za całość
  funkcjonowania.
   • Zależność taka może "wkraść się" niepostrzeżenie, jako konsekwencja
     pewnych (wydawałoby się drugorzędnych) decyzji projektowych, np.
     powołanie jednego serwera nazw, lub rejestracja nowych miejsc
     przyłączających się do rozproszonej bazy danych.
 Zależność taka jest niekorzystna, gdyż:
   • Centralne miejsce może stać się wąskim gardłem dla operacji na
     danych
   • Awaria centralnego miejsca powoduje awarię całej rozproszonej bazy
     danych.
 Dla niektórych zastosowań brak centralnego miejsca jest
  niekorzystny:
   • z powodu nadmiernego wzrostu obciążenia sieci związanego z
     wymianą metadanych;
   • z powodu zbyt niskiej wydajności (indeksy w jednym miejscu)
 Nazwy elementów danych w rozproszonych BD
 Problem nazywania i identyfikacji danych w rozproszonych BD
  staje się znacznie bardziej trudny niż w scentralizowanych BD.
 Kryteria zarządzania nazwami:
   • 1. Każda dana, która ma być niezależnie identyfikowana w systemie
     rozproszonym, musi mieć swoją unikalną nazwę (identyfikator).
   • 2. Nazwa powinna zapewniać efektywne odszukanie lokalizacji danej.
   • 3. Nazwa nie powinna utrudniać zmiany lokalizacji danej.
   • 4. Każde lokalne miejsce w rozproszonej BD powinno powinno mieć
     możliwość autonomicznego nadawania unikalnych nazw dla danych.
 Centralny serwer nazw - nadaje wszystkie nazwy, udziela
  informacji o lokalizacji nielokalnych danych na podstawie ich nazw:
   • nie spełnia warunku 4,
   • może powodować wąskie gardło dla transakcji,
   • jest pojedynczym powodem awarii całości.
 Rozwiązanie: prefiksowanie nazwy identyfikatorem miejsca -
  trudności ze zmianą lokalizacji danych (przy zachowaniu
Pojęcia związane z
  rozproszeniem
Główne aspekty rozproszenia baz danych (1)

Przezroczystość (transparency)
Rozproszony SZBD powinien podtrzymywać rozproszenie
danych przy założeniu odizolowania programisty/użytkownika
od większości aspektów rozproszenia.
Współdziałanie (interoperability)
Oznacza współpracę zbudowanych niezależnie od siebie
heterogenicznych systemów (heterogeneous systems).
Aspektem współdziałania jest przyłączenie do rozproszonej BD
starych systemów, tzw. spadkowych (legacy)
Przenaszalność (portability)
Własność języka programowania i jego kompilatorów/interpreterów
umożliwiająca przenoszenie programów na różne platformy.
Główne aspekty rozproszenia baz danych (2)
Autonomia (autonomy)

Lokalne bazy danych podlegają własnym lokalnym regułom. Tylko
określona część lokalnych zasobów i usług jest udostępniana na
zewnątrz.
Niezależność danych (data independence)

Możliwość projektowania, utrzymywania, udostępniania, zmiany nośników,
zmiany reprezentacji, itp. działań na danych niezależnie od programów,
które na nich operują.

Ontologia (ontology), często w kontekście "ontologia biznesowa"

Formalny opis wszystkich tych własności lokalnej bazy danych, które są
niezbędne do tego, aby projektant/programista mógł prawidłowo
zaprogramować nową aplikację (np. mobilnego agenta).
Niekiedy ontologia jest określana jako metadane.
                    Przezroczystość (1)
Rozproszona BD musi spełniać warunki komfortu pracy programistów,
administratorów i użytkowników, jak również niezawodności,
bezpieczeństwa danych, zwiększenie odporności na błędy
programistów. To oznacza konieczność redukcji złożoności przy pracy z
rozproszoną bazą danych, co jest określane jako „przezroczystość”.
Ma ona następujące formy:

  Przezroczystość położenia: Umożliwienie jednorodnych metod
   operowania na lokalnych i odległych danych. Tego warunku nie
   spełnia np. system, w którym lokalna baza danych jest
   obsługiwana przez pewien język 4GL, zaś odległa - przez
   specjalny zestaw procedur (API).
  Przezroczystość dostępu: Uwolnienie użytkowników od
   konieczności(a niekiedy również uniemożliwienie) korzystania z
   informacji o aktualnym położeniu danych.
                  Przezroczystość (2)
 Przezroczystość współbieżności: Umożliwia wielu użytkownikom
  jednoczesny dostęp do danych bez konieczności uzgodnień i
  porozumiewania się, przy zapewnieniu pełnej spójności danych i
  przetwarzania.
 Przezroczystość skalowania: Umożliwienie dodawania nowych
  elementów bazy danych bez wpływu na działanie starych aplikacji i
  pracę użytkowników.
 Przezroczystość replikacji: Umożliwienie tworzenia i usuwania
  kopii danych w innych miejscach geograficznych z bezpośrednim
  skutkiem dla efektywności przetwarzania, ale bez skutków dla
  postaci programów użytkowych lub pracy użytkownika końcowego.
 Przezroczystość wydajności: Umożliwienie dodawania nowych
  elementów systemu komputerowego (np. serwerów, dysków) bez
  wpływu na pracę większości użytkowników rozproszonej bazy
  danych.
                  Przezroczystość (3)

  Przezroczystość fragmentacji (podziału): automatyczne scalanie
   obiektów, tabel lub kolekcji, których fragmenty są przechowywane
   w różnych miejscach.
  Przezroczystość awarii: Umożliwienie nieprzerwanej pracy
   większości użytkowników rozproszonej bazy danych w sytuacji, gdy
   niektóre z jej węzłów lub linie komunikacyjne uległy awarii.
  Przezroczystość migracji: Umożliwienie przenoszenia zasobów
   danych do innych miejsc bez wpływu na pracę użytkowników.

W praktyce spełnienie wszystkich wymienionych warunków jest
ideałem, który prawdopodobnie nie został zrealizowany w żadnym
ze znanych systemów.
     Współdziałanie i heterogeniczność
                                      interoperability, heterogeneity




 Umożliwienie współdziałania heterogenicznych systemów
  baz danych jest drugim ważnym aspektem rozproszenia.

 Heterogeniczność jest nieodłączną cechą dużych sieci
  komputerowych, takich jak Internet, WWW, sieci
  intranetowych, rozproszonych baz danych, systemów
  przepływu prac, zasobów WWW opartych na plikach HTML i
  XML, itd.
       Heterogeniczność (niejednorodność)
 Np. system Intranetowy może składać się ze sprzętu:
   •   komputerów klasy mainframe
   •   stacji roboczych UNIX
   •   komputerów PC pracujących pod MS Windows
   •   komputerów Apple Macintosh
   •   central telefonicznych, robotów, zautomatyzowanych linii
       produkcyjnych

 ...włączać różnorodne protokoły komunikacyjne: Ethernet,
  FDDI, ATM, TCP/IP, Novell Netware, protokoły oparte na
  RPC,...
 ...bazować na różnych systemach zarządzania bazą
  danych/dokumentów: Oracle,SQL Server, DB2, Lotus
  Notes,....
 ...oraz wymieniać pomiędzy sobą niejednorodne dane,
  podlegające różnym modelom danych, schematom,
            Przyczyny heterogeniczności
 Niezależność działania: wytwórcy systemów nie uzgadniają między sobą
  ich cech. Standardy, o ile się pojawiają, są spóźnione, niekompletne i nie
  przestrzegane w 100%.

 Konkurencja: wytwórcy systemów starają się wyposażyć systemy w
  atrakcyjne cechy, których nie posiadają konkurujące systemy

 Różnorodność pomysłów: Nie zdarza się, aby było jedno rozwiązanie
  dla złożonego problemu. Różne zespoły znajdują różne rozwiązania,
  bazujące często na odmiennych celach i założeniach.

 Efektywność finansowa i kompromisy: Wytwórcy oferują produkty o
  różnej cenie, funkcjonalności i jakości, zgodnie z wyczuciem
  potencjalnych potrzeb klientów, dostosowaniem się do ich portfela i
  maksymalizacją swoich zysków.

 Systemy spadkowe (legacy): Systemy, które dawno zostały wdrożone i
  działają efektywnie, nie mogą być z tego działania wyłączone. Nie jest
  możliwe (lub jest bardzo kosztowne) zastąpienie ich nowymi systemami.
  Nowe systemy, o podobnym przeznaczeniu, posiadają inne założenia,
                       Przenaszalność                            portability

Typy przenaszalności:
• Na poziomie składni, koncepcji języka i edukacji (np. SQL-92).
• Na poziomie kodu źródłowego (np. C++ (?), JDBC).
• Na poziomie interpretowanego kodu skryptowego lub pośredniego (np. Java).
• Na poziomie kodu binarnego (? - trudno podać przykład).
 Przenaszalność wymaga precyzyjnej specyfikacji składni i
  semantyki języka, oraz wyeliminowania z niego własności
  specyficznych dla poszczególnych platform.
 Wiele standardów nie spełnia kryterium przenaszalności z powodu
  niedospecyfikowania i/lub nie spełniania standardu przez
  wytwórców systemów.
 Przenaszalność jest celem standardów SQL, CORBA oraz ODMG,
  niekoniecznie celem już osiągniętym.
 Przenaszalność realizuje kod pośredni języka Java, ale dotyczy to
  funkcjonalności niskiego poziomu, np. nie dotyczy API do baz
  danych.
                              Autonomia                               autonomy
Autonomia lokalnej bazy danych w federacji baz danych oznacza, że:
   Lokalne dane podlegają lokalnym priorytetom, regułom własności,
    autoryzacji dostępu, bezpieczeństwa, itd. Lokalna baza danych może
    odrzucić zlecenia przychodzące z federacji, o ile naruszają one lokalne
    ograniczenia lub zbytnio obciążają czas procesora lub inne lokalne
    zasoby.
   Lokalna baza danych może udostępniać aplikacjom działającym na
    federacji baz danych tylko określoną część swoich danych i usług.
    Programiści tych aplikacji nie mają jakichkolwiek środków dostępu do
    pozostałych danych i usług.
   Włączenie lokalnej bazy danych do federacji nie może powodować
    konieczności zmiany programów aplikacyjnych działających na lokalnej
    BD.
  Federacja może przetwarzać lokalne zasoby tylko poprzez interfejs
     programowania aplikacji (API) specyficzny dla lokalnego systemu. Inne
     metody (np. bezpośredni dostęp do plików) są niedozwolone.
Możliwa jest pewna skala autonomii. Pojęcie autonomii jest raczej intuicyjne.
  Federacja nie może żądać od lokalnej bazy danych zmiany/rozszerzenia
                    Niezależność danych                      data independence

Oznacza, że nie ma potrzeby zmiany kodu programów aplikacyjnych mimo
zmian organizacji lub schematów danych. Jest osiągana poprzez interfejsy
programistyczne umożliwiające dostęp do danych na odpowiednim poziomie
abstrakcji, gdy niewidoczne są szczegóły organizacji i implementacji danych.

   Fizyczna niezależność danych: ukrycie detali organizacji
    fizycznej i technik dostępu, dzięki czemu możliwa jest ich zmiana
    bez wpływu na kod aplikacji.
   Logiczna niezależność danych: umożliwienie niektórych zmian
    schematu logicznego bez wpływu na kod aplikacji, np. dodanie
    atrybutów do relacji, zmiana kolejności atrybutów, zmiana ich
    typów, utworzenie nowych relacji, itd.
   Ewolucja schematu (schema evolution): umożliwienie daleko
    idących zmian schematu danych przy jednoczesnym utworzeniu
    perspektyw (views) dla starych lub nowych danych. Perspektywy
    mają umożliwić minimalną pracochłonność przy zmianach aplikacji
    (idealistycznie).
                            Ontologia                               ontology

 W filozofii: nauka o bytach, teoria bytu, opis charakteru i struktury
  rzeczywistości, specyfikacja konceptualizacji.
 W sztucznej inteligencji: formalna specyfikacja (przy użyciu logiki
  matematycznej) obiektów, pojęć i innych bytów, które istnieją w
  pewnej dziedzinie, oraz formalna specyfikacja związków, które
  pomiędzy tymi bytami zachodzą.
   • Podejście sztucznej inteligencji jest naiwne.
   • Np. Giełda Papierów Wartościowych: wiele tysięcy stron aktów
     prawnych, zarządzeń, regulacji, itd. Jako (dożywotnia) kara dla
     sztucznego (ćwierć-) inteligenta wypisującego bzdury na temat
     "formalnej ontologii": niech to zapisze przy użyciu formuł rachunku
     predykatów.
 W biznesie (ontologia biznesowa, business ontology): wszystko to,
  co projektanci systemów informatycznych powinni wiedzieć o
  biznesie, aby poprawnie napisać aplikacje wspomagające ten
  biznes. Wiedza ta powinna być formalnie zapisana. "Formalnie"
  oznacza zwykle pewien standardowy i uzgodniony język, np.
                 Ontologia i metadane
 Głównym celem prac na biznesową ontologią jest standardyzacja
  następujących elementów:
   • Gramatyki opisów poszczególnych bytów,
   • Nazw i znaczeń nazw obowiązujących w ramach danego
     biznesu (np. co oznaczają słowa "autor", "klient", "instrument",
     "akcja", itd.),
   • Ograniczeń związanych z opisywanymi bytami,
   • Metadanych związanych z bytami (autor opisu, data stworzenia
     opisu, data ostatniej aktualizacji, itd.),
   • Dopuszczalnych operacji na bytach.
 W tym zakresie zapis ontologii jest pewną meta-bazą danych, w
  które ustala się zarówno strukturę samej bazy danych, jak i pewne
  dodatkowe informacje (meta-atrybuty) będące podstawą
  przetwarzania bazy danych.
 Nieco inne podejście prezentuje standard RDF opracowany przez
  W3C, gdzie ontologię reprezentują wyrażenia RDF.
                           Metadane
 Metadane są kluczowe dla wielu rozproszonych aplikacji, ponieważ
  umożliwiają rozpoznanie z zewnętrz własności lokalnego zasobu
  danych
 Ogólna definicja: są to dane o danych - co dane zawierają, jaką
  mają budowę, jakie jest ich znaczenie, jakim podlegają
  ograniczeniom, jak są zorganizowane, przechowywane,
  zabezpieczane, udostępniane, itd.
 Metadane są pewnym rozszerzeniem pojęcia schematu bazy
  danych, albo też pewną implementacją tego schematu w postaci
  katalogów.
 Metadane przykrywają także informację niezależną od treści
  samych danych, np. kiedy pewna dana została utworzona, w jakim
  jest formacie, kto jest jej autorem, do kiedy jest ważna, itd.
 Opisy danych zawarte w metadanych mają dwie podstawowe
  zalety:
   • Zawierają wspólne abstrakcje dotyczące reprezentacji danych, takie
     jak format; ogólnie "wyciągają przed nawias" wszystkie wspólne
              Klasyfikacja metadanych
 Metadane niezależne od treści danych: lokacja danych, data
  modyfikacji, typ kamery służącej do sporządzenia zdjęcia, itd.
  Mimo, że nie składają się bezpośrednio na treść danych, mogą być
  ważnym kryterium wyszukiwania.
 Metadane zależne od treści danych: rozmiar dokumentu, liczba
  kolorów, liczba wierszy, liczba kolumn w tabeli. Metadane zależne
  od treści mogą być dalej podzielone na:
   • Bezpośrednie metadane dotyczące treści, np. indeksy, klasyfikacje,
     itd.
   • Metadane opisujące treść: adnotacje o zawartości zdjęcia, np. opis
     zapachu kwiatu przedstawionego na zdjęciu.
   • Metadane niezależne od dziedziny biznesowej, której dotyczy treść,
     np. definicje typu dokumentu HTML/SGML
   • Metadane zależne od dziedziny biznesowej, np. schemat danych lub
     opis ontologii biznesowej
 Podział na dane i metadane nie jest do końca jasny i silnie zależy
  od nastawienia projektanta i podziału zadań podczas redakcji treści
            Protokół wymiany informacji
                 w rozproszonej BD
 Protokół wymiany informacji pomiędzy rozproszonymi miejscami
  musi uwzględniać:
   • przesyłanie danych z jednego miejsca do drugiego miejsca
   • przesyłanie zleceń (np. zapytań) do odległych miejsc celem
     przetwarzania danych
   • zwrotne przesyłanie wyników tych zleceń do zlecającego klienta
   • automatyczną dystrybucję niektórych metadanych (np. schematu BD)
     pomiędzy uczestników rozproszonej bazy danych.
   • przesyłanie zapytań dotyczących metadanych
   • przekazywanie wyników zapytań dotyczących metadanych do
     pytającego
 Aktualnie, protokoły takie istnieją w bardzo uproszczonej lub silnie
  wyspecjalizowanej formie
   • IIOP (Internet Inter-Orb Protocol) - bardzo uproszczony
   • LDAP (Lightweight Directory Access Protocol) - silnie
     wyspecjalizowany
 Wiele ośrodków prowadzi prace badawcze nad uniwersalnymi
                          Migracje obiektów
Migracja: przemieszczanie się obiektów między węzłami sieci, przy czym
obiekty muszą być skojarzone (statycznie lub dynamicznie związane) ze
swoimi klasami i przechowywanymi w ramach tych klas metodami. Problemy:
   Określenie jednostki migracji
   Śledzenie obiektów
   Utrzymywania porządku w katalogu systemu bazy danych
   Okresowa kondensacja łańcuchów obiektów pośrednich
   Przemieszczanie obiektów złożonych
   Zapewnienie globalnej przestrzeni nazw
   Zapewnienie właściwych mechanizmów zakresu i wiązania
   Dostępność metod umożliwiających przetwarzanie obiektów
Jak dotąd, metody są najczęściej składowymi aplikacji, a nie bazy danych.
Konsekwencją jest to, że po przemieszczeniu obiektu aplikacja działająca w jego
nowym miejscu musi mieć wbudowane (powielone, skompilowane, zlinkowane)
metody do jego przetwarzania.
         Oprogramowanie komponentowe
Komercyjny buzzword, niezrealizowane marzenie informatyków od 30 lat.
Oznacza technologie zmierzające do budowy standardów oraz
wspomagającego je oprogramowania, które pozwoliłoby na składanie
dużych aplikacji lub systemów z mniejszych standardowych części -
komponentów, na zasadzie podobnej do składania komputera z
podzespołów.
Inne terminy: mega-programming, programming-in-the-large.
Jako przykłady komponentowego podejścia wymienia się: OMG CORBA, OpenDoc firm
Apple, IBM i innych, technologia .NET/COM/DCOM, Java Beans i Enterprise Java Beans.
 Komponenty odnoszą wiele sukcesów. Istnieją jednak problemy
 utrudniające szerokie ich stosowanie, tj:
 problemy z osiągnięciem akceptowalnej wydajności,
 trudności w precyzyjnym a jednocześnie dostatecznie
  abstrakcyjnym wyspecyfikowaniu interfejsów pomiędzy
  komponentami,
 dynamiczny postęp w informatyce, powodujący pojawianie się
  coraz to nowych wymagań na interfejsy.
Obiektowość w systemach
     rozproszonych
   Obiektowość w rozproszonych bazach
                 danych
 Obiektowość zakłada zwiększenie stopnia abstrakcji,
  przystosowanie modeli realizacyjnych systemów informatycznych
  do naturalnych konstrukcji i obrazów myślowych projektantów,
  programistów i użytkowników.
 Główny problem - opanowanie złożoności przy wytwarzaniu
  oprogramowania.
 Punktem zainteresowania twórców narzędzi informatycznych
  stają się procesy myślowe zachodzące w umysłach osób
  pracujących nad oprogramowaniem => modelowanie
  pojęciowe.
 Obiektowość przerzuca ciężar problemu z kwestii narzędziowej (jak
  mam to zrobić?) na kwestię merytoryczną (co mam zrobić i po
  co?).
Źródła złożoności projektu oprogramowania



Dziedzina problemowa,                                      Zespół projektantów
obejmująca ogromną liczbę                                  podlegający ograniczeniom
wzajemnie uzależnionych                                    pamięci, percepcji, wyrażania
aspektów i problemów.              Oprogramowanie:         informacji i komunikacji.
                                   decyzje strategiczne,
                                         analiza,
                                     projektowanie,
                                      konstrukcja,
                                     dokumentacja,
                                       wdrożenie,
                                        szkolenie,
                                      eksploatacja,
                                       pielęgnacja,
                                      modyfikacja.
Środki i technologie                                       Potencjalni użytkownicy:
informatyczne:                                             czynniki psychologiczne,
sprzęt, oprogramowanie, sieć,                              ergonomia, ograniczenia pamięci
języki, narzędzia, udogodnienia.                           i percepcji, skłonność do błędów
                                                           i nadużyć, tajność, prywatność.
        Jak walczyć ze złożonością ?

Zasada dekompozycji:
rozdzielenie złożonego problemu na podproblemy, które można rozpatrywać i
rozwiązywać niezależnie od siebie i niezależnie od całości.

Zasada abstrakcji:
eliminacja, ukrycie lub pominięcie mniej istotnych szczegółów rozważanego
przedmiotu lub mniej istotnej informacji; wyodrębnianie cech wspólnych i
niezmiennych dla pewnego zbioru bytów i wprowadzaniu pojęć lub symboli
oznaczających takie cechy.

Zasada ponownego użycia:
wykorzystanie wcześniej wytworzonych schematów, metod,           wzorców,
komponentów projektu, komponentów oprogramowania, itd.

Zasada sprzyjania naturalnym ludzkim własnościom:
dopasowanie modeli pojęciowych i modeli realizacyjnych systemów do
wrodzonych ludzkich własności psychologicznych, instynktów oraz mentalnych
mechanizmów percepcji i rozumienia świata.
           Modelowanie pojęciowe
Projektant i programista muszą dokładnie wyobrazić sobie problem
oraz metodę jego rozwiązania. Zasadnicze procesy tworzenia
oprogramowania zachodzą w ludzkim umyśle i nie są związane z
jakimkolwiek językiem programowania.

Pojęcia modelowania pojęciowego (conceptual modeling) oraz
modelu pojęciowego (conceptual model) odnoszą się procesów
myślowych    i   wyobrażeń    towarzyszących   pracy   nad
oprogramowaniem.

Modelowanie pojęciowe jest wspomagane przez środki
wzmacniające ludzką pamięć i wyobraźnię. Służą one do
przedstawienia rzeczywistości opisywanej przez dane, procesów
zachodzących w rzeczywistości, struktur danych oraz programów
składających się na konstrukcję systemu.
   Perspektywy w modelowaniu pojęciowym
                  odwzorowanie             odwzorowanie


                                                                  ...     ... ...
                                                                 ...
                                                           ... ...      ... ...
                                                                         ...
                                                          ... ......    ...
                                                                         ... ...
                                                                ...     ... ...




    Percepcja              Analityczny                 Model
  rzeczywistego               model              struktur danych
      świata              rzeczywistości           i procesów SI

Trwałą tendencją w rozwoju metod i narzędzi projektowania oraz
konstrukcji SI jest dążenie do minimalizacji luki pomiędzy
myśleniem o rzeczywistym problemie a myśleniem o danych i
procesach zachodzących na danych.
  Przykład: pojęciowy schemat obiektowy w UML

           Osoba
           Nazwisko
           Imię *
           Adres *



                                     Zatrudnienie               Firma
           Pracownik        PZ                           FZ
                                     Wypłata *                  Nazwa
           Zawód *   0..*        1                0..*        1 Miejsce *
                                     Ocena *



Nie więcej niż 10 sekund zastanawiania się, co ten diagram przedstawia
i jak jest semantyka jego elementów.

Potem można już programować np. w C++ lub Java.

Co otrzymamy po odwzorowaniu tego schematu na schemat relacyjny?
                      Schemat relacyjny
                             Firma(NrF, Nazwa)


           Lokal(NrF, Miejsce)             Zatrudnienie(NrF, NrP)

                                                  Pracownik(NrP, NrOs)


        Oceny(NrOceny, Ocena, NrF, NrP)

               Dochód(NrDochodu, Wypłata, NrF, NrP)        Osoba(NrOs, Nazwisko)

                                 Wyszkolenie(Zawód, NrP)

                                             Imiona(NrOs, Imię)     Adresy(NrOs, Adres)


Jest to jedno z kilku możliwych rozwiązań.
Schemat relacyjny jest trudniejszy do odczytania i zinterpretowania przez
programistę. Będzie on musiał co najmniej 10 minut zastanawiać się, co ten
diagram reprezentuje i jaką semantykę mają atrybuty i zaznaczone powiązania.
Efektem jest zwiększona skłonność do błędów (mylnych interpretacji).
  Skutki niezgodności modelu pojęciowego i
                 relacyjnego
Programy odwołujące się do schematu relacyjnego są dłuższe od programów
odwołujących się do schematu obiektowego (szacunkowo od 30% do 70%). Ma
to ogromne znaczenie dla tempa tworzenia oprogramowania, jego jakości,
pielęgnacyjności, itd. Programy te są też zwykle znacznie wolniejsze.
   Mini przykład:
   Podaj adresy pracowników pracujących w firmach zlokalizowanych w Radomiu

 SBQL: (Firma where ”Radom” in Miejsce).FZ.Zatrudnienie.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 dłuższe wskutek tego, że w SQL konieczne są
 „złączeniowe” predykaty (takie jak k.NrF=z.NrF i następne) kojarzące
 informację semantyczną "zgubioną" w relacyjnej strukturze danych.
    Rozproszone obiektowe bazy danych
 Problemy są podobne jak w przypadku rozproszonych relacyjnych
  BD.
 Nie jest jednak pewne czy do przetwarzania zapytań w tych
  systemach będą się odnosić te same metody.
 Problemy, różniące przetwarzanie zapytań w rozproszonych
  obiektowych BD i w rozproszonych relacyjnych BD:
   • Obiekty nie zawsze są implementowane jako "płaskie" zapisy.
   • Obiekty mogą mieć referencje do obiektów zlokalizowanych w innych
     węzłach sieci.
   • Przetwarzanie zapytań może dotyczyć kolekcji złożonych obiektów
   • Zapytania mogą mieć odwołania do metod.
 Przetwarzanie zapytań w rozproszonych systemach obiektowych
  jest tematem bardzo istotnym. Standard ODMG tym się nie
  zajmuje.
 Jak dotąd, w zakresie przetwarzania rozproszonych zapytań nie
  rozwiązano podstawowych problemów koncepcyjnych.
      Rozproszona obiektowa baza danych
Przedmiotem przetwarzania i wymiany informacji w obiektowej
rozproszonej bazie danych są obiekty. Zarządzanie rozproszonymi
obiektami ma na celu utrzymywanie spójności i przezroczystości
(niewidoczności) geograficznego rozproszenia obiektów.
                              Zapytanie    Aplikacja
                                     użytkownika                  użytkownika



                                                 Oprogramowanie
                                                  klient/serwer

                                                                                Oprogramowanie
                                                                                    serwera

                   Oprogramowanie              Podsystem
                       serwera               komunikacyjny


                                                                          Oprogramowanie
                                Oprogramowanie                             klient/serwer
                                 klient/serwer




                Zapytanie                                     Aplikacja             Zapytanie
               użytkownika                                   użytkownika           użytkownika
          Zalety rozproszonych obiektów
 Zgodność z logiką biznesu - bezpośrednia implementacja obiektów
  biznesowych.
 Umożliwienie projektantom opóźnienie decyzji - gdzie i jakie usługi
  powinny być zapewnione.
 Skalowalność aplikacji: mała zależność czasu reakcji systemu od
  zwiększenia ilości danych, liczby użytkowników, liczby węzłów.
 Dekompozycja aplikacji na małe elementy wykonawcze (obiekty,
  metody,...).
 Przyrostowe dodawanie/odejmowanie funkcjonalności (“płacę tylko za
  to, czego używam”).
 Podział zasobów i zbalansowanie obciążeń.
 Współbieżność i asynchroniczne przetwarzanie.
 Elastyczność zmian w oprogramowaniu (konserwacja), w
  szczególności, przenoszenie obiektów i usług do innych miejsc.
 Możliwość przyłączania aplikacji spadkowych (funkcjonujących
  wcześniej jako scentralizowane).
Projektowanie rozproszonych
        baz danych
Podejścia do projektowania rozproszonych
        BD: top-down i bottom-up

              Od ogółu do szczegółów:
              Odgórne zaprojektowanie całej bazy danych,
              z uwzględnieniem optymalizacji
  top-down    przechowywanych danych, narzuconej przez
              fakt geograficznego rozproszenia
              producentów i konsumentów informacji
              przechowywanej w bazie danych.
              Od szczegółów do ogółu:
  bottom-up
              Zintegrowanie już istniejących (spadkowych)
              lub zaprojektowanych lokalnych baz danych
              w jedną globalną rozproszoną bazę danych.
         Projektowanie: podejście top-down
                  Analiza              Analiza systemowa: rozpoznanie
                                       wymagań, precyzowanie
                                       kontekstu przyszłej bazy danych.
Model pojęciowy
                                       Projektowanie schematu
scentralizowany
                                       pojęciowego

                                       Projektowanie struktury
                                       logicznej
Model logiczny          Kryteria
scentralizowany         rozproszenia   Kryteria rozproszenia są
                                       związane z faktem fizycznego
                                       rozproszenia źródeł i
                                       odbiorców danych oraz
                                       autonomii lokalnych baz
Modele logiczne                        danych. Ustalają one decyzje,
dla                                    które fragmenty projektu
poszczególnych
                                       pojęciowego będą
miejsc
                                       przechowywane w
                                       poszczególnych miejscach, a
            Dalsze fazy postępowania
             w podejściu top-down
 Określenie danych podlegających replikacjom (lokalnych kopii)
  oraz strategii replikacji.
 Zróżnicowanie logicznego schematu danych w zależności od
  typu SZBD w poszczególnych miejscach.
 Określenie lokalnych schematów dla poszczególnych miejsc.
 Określenie danych autonomicznych dla poszczególnych
  miejsc, nie uczestniczących w rozproszonej bazie danych; co
  prowadzi do określenia schematu pojęciowego i logicznego dla
  danych widzianych z zewnątrz.
 Podział schematu logicznego: Wg różnych reguł związanych
  na ogół z fizycznym ulokowaniem obiektów rzeczywistych
  (np. osób zatrudnionych, sprzętu, co pociąga za sobą
  odpowiedni podział schematu logicznego) lub też z fizycznym
  ulokowaniem programów aplikacyjnych działających na tych
  obiektach.
                    Fragmentacja

 Najpopularniejszym modelem jest fragmentacja
  pozioma, oznaczająca, że każdy serwer ma ten sam
  schemat danych, ale inną populację danych.
  • Sumowanie zbiorów danych w taki sposób, że informacja o
    serwerach jest zbędna dla programisty/użytkownika.
 Fragmentacja pionowa: podział obiektów na
  fragmenty przechowywane w różnych miejscach.
  • Musi być zapewniony sposób „sklejenia” całości obiektu z
    fragmentów (np. NIP dla obywateli RP).
 Przy integracji zasobów mogą pojawiać się
  wyrafinowane kombinacje fragmentacji poziomej,
  pionowej i replikacji (redundancji).
Podstawowe metody fragmentacji schematu
 Fragmentacja pionowa oznacza przyporządkowanie
  poszczególnych klas obiektów do poszczególnych miejsc, lub
  rozbicie obiektów danej klasy na dwa lub więcej podobiektów,
  przy czym takie podobiekty są przechowywane w różnych
  miejscach.
 Fragmentacja pionowa może oznaczać konieczność
  odpowiedniego podziału informacji zawartych w klasach
  obiektów oraz ustalenia środków podtrzymania
  jednoznacznej tożsamości obiektów.
 Fragmentacja pozioma oznacza rozbicie populacji obiektów
  danej klasy na dwa lub więcej miejsc geograficznych.
 Fragmentacja pozioma może być dokonywana na podstawie
  różnych kryteriów, które często wiązane są z geograficznym
  ulokowaniem obiektów rzeczywistych, lub też z
  geograficznym ulokowaniem przetwarzania tych obiektów.
Fragmentacja pionowa relacyjnej bazy danych
  Warszawa                                  Kutno
  DOSTAWCA_DANE                             DC
  DNR NAZW       STATUS                     DNR CNR ILOŚĆ

   D1   Abacki       20                      D1   C1   300
   D2   Bober        10
                                     Sieć    D1   C2   200
   D3   Czerny       30                      D1   C3   400
   D4   Dąbek        20                      D1   C4   200
   D5   Erbel        30                      D1   C5   100
                                             D1   C6   100
                                             D2   C1   300
                           Gdańsk            D2   C2   400
                                             D3   C2   200
                          DOSTAWCA_MIASTO
                                             D4   C2   200
                          DNR   MIASTO       D4   C4   300
                                             D4   C5   400
                           D1   Lublin
                           D2   Poznań
                           D3   Poznań
                           D4   Lublin
                           D5   Radom
Fragmentacja pozioma relacyjnej bazy danych

               Poznań         DC
 DOSTAWCA                     DNR CNR ILOŚĆ
 DNR NAZW     STATUS MIASTO
                               D2   C1   300
  D2 Bober        10 Poznań    D2   C2   400
  D3 Czerny       30 Poznań    D3   C2   200


                                                                 Lublin
                                         DOSTAWCA
                                          DNR NAZW         STATUS MIASTO
                   Sieć
                                               D1 Abacki          20 Lublin
                                               D4 Dąbek           20 Lublin

                                         DC
 DOSTAWCA        Radom                   DNR CNR ILOŚĆ
 DNR NAZW     STATUS MIASTO                D1      C6      100
                                           D4      C2      200
  D5 Erbel        30 Radom                 D4      C4      300
        Przykład fragmentacji poziomej

Radom         Klasa
            Pracownik
                                            Obiekty Pracownik są
Pracownik       Pracownik
 Nowak          Kowalski
                                ...         przechowywane zgodnie z
                                            geograficznym położeniem
                                            pracodawcy.

                                                     Kalisz       Klasa
                        Sieć                                    Pracownik

                                                    Pracownik      Pracownik
                                                      Styka          Malina
                                                                               ...

                    Klasa
   Kielce
                  Pracownik

    Pracownik       Pracownik
     Malasa          Zagórny.
                                      ...
Fragmentacja pionowa obiektów Pracownik

 Radom           Klasa danych
                  osobistych

    Nowak               Kowalski
 dane osobiste        dane osobiste
                                       ...


                                                      Kalisz        Klasa danych o
                                Sieć                                   ocenach

                                                      Nowak               Kowalski
                                                   dane o ocenach       dane o ocenach
                                                                                         ...

      Kraków          Klasa danych o
                       zatrudnieniu

        Nowak               Kowalski
     dane o zatrud.       dane o zatrud.
                                             ...
Fragmentacja danych
Inne fragmentacje danych w rozproszonej BD
 Możliwe są inne, bardziej złożone fragmentacje danych, które łączą
  fragmentacje pionowe, fragmentacje poziome oraz redundantne
  dane (replikacje).
 Bardziej złożone fragmentacje rodzą trudności z:
   • zarządzaniem metadanymi: gdzieś muszą być ulokowane
     informacje odnośnie tego w jaki sposób podzielone dane mają
     być scalone w kompletne obiekty lub kolekcje w ramach
     rozproszonej bazy danych. Jest to rola metadanych oraz
     mechanizmu właściwej dystrybucji metadanych pomiędzy
     uczestników rozproszonej bazy danych.
   • przetwarzaniem zapytań: dekompozycja zapytania na pod-
     zapytania adresowane do poszczególnych miejsc staje się
     znacznie bardziej kłopotliwa. Przesyłanie fragmentów obiektów
     celem ich zmaterializowania po stronie klienta może być zbyt
     kosztowne.
 Bardziej złożone fragmentacje mogą być nie do uniknięcia w
  rozproszonej bazie danych integrującej istniejące bazy danych
                       Replikacje


 Replikacja jest kopią danych i usług na innym serwerze.
 Replikacje mają na celu zwiększenie dostępności danych i
  usług oraz ich ochronę przed zniszczeniem.
 Przy integracji bottom-up replikacje (redundancje) są
  często cechą nieuchronną i niepożądaną.
   • Może występować redundancja danych o dowolnym stopniu
     skomplikowania.
 Replikacje i redundancje stanowią poważny problem dla
  przezroczystości i operacji aktualizacji danych.
     Projektowanie: podejście bottom-up
 Podejście ad hoc: Budowa uniwersalnych lub specyficznych dla
  danego zastosowania pomostów (gateways) umożliwiających
  dostęp z danego systemu bazy danych do innych baz danych.
  Pomost może (nie musi) zapewniać przezroczystość rozproszenia.
 Podejście oparte o globalny schemat: Wszystkie składniki
  rozproszonej BD są objęte jednym globalnym schematem,
  jednakowym dla każdego miejsca i zapewniającym
  przezroczystość rozproszenia. Istotną wadą podejścia opartego na
  globalnym schemacie jest brak możliwości sterowania zakresem
  autonomii każdego lokalnego systemu.
 Federacyjna baza danych: Każda lokalna baza danych
  zachowuje swoją autonomię, udostępniając tylko część danych dla
  innych miejsc w RBD. Podejście federacyjne zakłada, że każda
  lokalna baza danych jest widziana poprzez pewną perspektywę
  (view), ukrywającą niektóre dane dla rozproszonych aplikacji.
Replikacja
 Federacyjna BD tworzona metodą bottom-up
                                   Aplikacje globalne
                                   Aplikacje globalne
                                    Aplikacje globalne


                          Schemat federacyjnej bazy danych

                   Perspektywa                        Perspektywa
                    Mediator                           Mediator
                     Osłona                             Osłona

               Schemat lokalny 1                     Schemat lokalny 2
   Miejsce 1                             Miejsce 2
     Aplikacje
      Aplikacje
       Aplikacje
      lokalne
       lokalne
        lokalne
                         Baza
                       danych 1
                                           Aplikacje
                                            Aplikacje
                                             Aplikacje
                                            lokalne
                                             lokalne
                                              lokalne
                                                               Baza
                                                             danych 2
                                                                         .....
Podejście federacyjne okazało się skuteczne ze względu na zapewnienie
autonomii, bezpieczeństwa i efektywności. Rodzi jednak dużo problemów, m.in.
z zapewnieniem jednolitej ontologii biznesowej, uniwersalnością aplikacji,
wydajnością, itd.
Architektury rozproszonych
        baz danych
             Architektura klient - serwer


 Serwer - komputer (proces) oferujący określony rodzaj
  usługi
 Klient - komputer (proces) korzystający z usługi




                                            Klient
 Klient




          Klient      Serwer                    Klient
               Architektura klient-serwer

       Całość pracy wykonywanej przez system komputerowy jest
                      podzielona na dwie części:


 wykonywaną po stronie klienta         wykonywaną po stronie serwera
 (zwykle związaną z interakcją z     (komunikacja, dostęp do bazy danych,
         użytkownikiem)                zarządzanie repozytoriami pamięci,
                                       zarządzanie globalną przestrzenią
                                                     nazw)


                   Określenie mechanizmu komunikacji pomiędzy
                   klientem a serwerem.
Podstawowe         Podział funkcji na te, które są wykonywane po stronie
 problemy:         klienta i te, które są wykonywane po stronie serwera

                   Określenie jednostki komunikacji klient - serwer
       Heterogeniczne środowisko
       w architekturze klient-serwer



                                                           Windows 95
Windows 95        Windows NT               UNIX
                                                              or NT
  Client             Client                Client
                                                             Client




                          TCP/IP network




     Windows NT Server                           UNIX Server
     with repository on                       with repository on
         SQLserver                                 Informix
Architektury serwerów w dostępie do bazy
                 danych


            Serwer plików,
            Serwer SQL,
            Serwer obiektów,
            Serwer stron.
 Architektura z serwerem plików




    klient                                        serwer
                       Zapotrzebowanie na
                       odczyt/zapis
Aplikacja po stronie   danych w plikach
klienta odwołuje się
                                              Alokacja pamięci
     do danych
                                                  WE/WY
 umieszczonych w       Odczytane dane z
                       plików bazy danych
 pliku bazy danych                          obsługa plików z bazą
                                                   danych
                   Transfer plików


 Protokół FTP (File Transfer Protocol)
 Usługa FTP:
   • kopiowanie plików z komputerów odległych do komputera
     użytkownika
   • kopiowanie plików z komputera użytkownika do komputerów
     odległych
 Dostęp do danych (ograniczony, system weryfikacji
  użytkownika)
 Środowisko pracy:
   • tekstowe (program ftp w środowisku systemowym)
   • graficzne (dedykowane aplikacji komercyjne, przeglądarki)
      Procedura transferu plików


 Podłączenie się do serwera odległego
 Wejście użytkownika do systemu plików
 Nawigacja w strukturze katalogów
 Określenie rodzaju transferu
 Pobranie/osadzenie plików
 Zamknięcie połączenia
     Typowe instrukcje usługi FTP

 open - podłączenie się do serwera
 user - wejście użytkownika do systemu (ftp, anonymous)
 close - zamknięcie połączenia
 dir - wyświetlenie zawartości katalogu na serwerze
 cd - zmiana katalogu bieżącego na serwerze
 lcd - zmiana katalogu bieżącego na komputerze klienta
 bin - binarny rodzaj transferu
 asc - znakowy rodzaj transferu
 put - przesłanie pliku z komputera klienta do serwera
 get - pobranie pliku z serwera
 mput - przesłanie plików z komputera klienta do serwera
 mget - pobranie plików z serwera
Architektura z serwerem SQL




Aplikacja klienta   Zapytanie SQL
zadaje zapytanie
      SQL
                                    Maszyna SQL
  Zarządzanie
   kursorem           krotka

                                       serwer
      klient
            Architektura z serwerem stron

                  klient                          serwer
                 aplikacja
                                Pamięć       Menadżer Menadżer
                Menadżer       podręczna
                                           stron pamięci dziennika
                                 stron
                obiektów                    podręcznej blokowania
                 Menadżer
             plików/indeksów
             Menadżer stron
                pamięci                        Alokacja pamięci
              podręcznej                           WE/WY
                               strony



  Pamięć
podręczna
 obiektów
                  Pamięć
                 podręczna
                   stron
            Architektura serwera stron

                                      Aplikacja
                    Interfejs
                  zapytaniowy      Przeglądarka           Interfejs
Przedmiotem      Optymalizacja       obiektów         programistyczny
                    zapytań
zarządzania                   Zarządzanie obiektami
są fizyczne               Zarządzanie plikami i indeksami
                            Zarządzanie kieszenią stron
strony dyskowe
                                             strony

                               Zarządzanie zamkami
                                Zarządzanie składem
                             Zarządzanie kieszenią stron




                                     Obiektowa
                                       baza
                                      danych
Architektura z serwerem obiektów


                                serwer
  klient         Pamięć
               podręczna   Menadżer Menadżer
                obiektów
                           obiektów dziennika
                                    blokowania
  Aplikacja
                                Menadżer
                            plików/indeksów

                                Menadżer          Pamięć
                                                 podręczna
 Menadżer                     stron pamięci        stron
 obiektów                       odręcznej
              obiekty
                             Alokacja pamięci
                                 WE/WY
    Pamięć
  podręczna
   obiektów
        Architektura serwera obiektów

                                  Aplikacja
                Interfejs       Przeglądarka           Interfejs
              zapytaniowy         obiektów         programistyczny
Przedmiotem                 Zarządzanie obiektami
zarządzania
są obiekty                               obiekty

                           Zarządzanie obiektami
                           Optymalizacja zapytań
                          Zarządzanie zamkami
                            Zarządzanie składem
                     Zarządzanie stronami i kieszeniami




                                 Obiektowa
                                   baza
                                  danych
     Reguły architektury klient-serwer (1)
 Zachowanie autonomii serwera. Klienci powinni zachowywać
  reguły wykorzystania serwera, nie powinni powodować jego
  niedostępność (np. zamykać duże ilości danych), nie powinni
  łamać ograniczeń integralności.
 Zachowanie autonomii klienta. Klienci nie powinni zachowywać
  się różnie w zależności od tego, czy serwer jest lokalny czy odległy.
  Powinni być odizolowani od kwestii fizycznego ulokowania danych.
 Wspomaganie dla aplikacji niezależnych od serwera.
 Dostęp do własności (danych, usług) serwera. Klienci mogą
  żądać od serwera wykonanie przewidzianych dla niego funkcji.
 Wspomaganie dla bieżącego dostępu do danych. Dostęp ten
  powinien być bezpośredni, bez pośrednictwa plików
  przekazywanych do/od klienta.
 Minimalny wpływ architektury K/S na wymagania dla klienta.
  Oprogramowanie klienta w architekturze K/S nie powinno
  wykazywać znacznego zwiększenia zapotrzebowania na RAM lub
      Reguły architektury klient-serwer (2)
 Kompletność opcji niezbędnych do połączenia. Oprogramowanie
  klienta nie powinno zawierać kodu realizującego połączenie z
  serwerem.Powinien to zapewniać serwer komunikacyjny.
 Możliwość budowy lokalnych prototypów. Programista powinien mieć
  możliwość budowy i testowania aplikacji K/S wyłącznie na stacji klienta.
 Kompletność narzędzi użytkownika końcowego. Projektowanie
  ekranów, generacja zapytań, itd. powinny być częścią środowiska.
 Kompletność środowiska budowy aplikacji. Powinno przewidywać
  możliwość łączenia się w sieci, dostęp do usług globalnych w zakresie
  nazw, lokacji danych, itd.
 Otwarte środowisko języka-gospodarza. Powinno zapewniać
  możliwość użycia uniwersalnego języka programowania do budowy
  aplikacji.
 Szczególna troska o standardy. Im bardziej będą one przestrzegane,
  tym mniej będzie późniejszych kłopotów ze współdziałaniem.
Przykład architektury SZBD typu klient-serwer
     Aplikacja generująca transakcje                                    Aplikacja generująca transakcje

     Zarządzanie       Zarządzanie                                      Zarządzanie       Zarządzanie
     transakcjami       buforami
                                                 ...                    transakcjami       buforami

     Zarządzanie zasobami                                               Zarządzanie zasobami

     Klient 1                                                           Klient n


                                             Zarządzanie
                                                siecią


                                              Interfejs serwera

                            Zarządzanie        Zarządzanie        Zarządzanie
                             zasobami          transakcjami        buforami

                                       Zarządzanie        Zarządzanie
                                         logiem            zamkami
                          Serwer
     Architektura klient-(multi) serwer (1)
Połączenia bezpośrednie:

                            k2       k3
                                                  k7
                  k1

                                            s4
             k4                 s1                k8

                                           s3
            k5             s2                     k9


            k6                                   k10
                                     k11
      Architektura klient-(multi) serwer (2)
Połączenia poprzez sieć: nie ma bezpośrednich połączeń, zarówno serwery jak i
klienci są przyłączani w jednakowy sposób do wspólnej sieci komputerowej.


                                        k1
                              k2                     s4
                    k3
                                                               k9
              k4

         s1                   Sieć komputerowa                       k8


              k5                                                s3

                         k6            s2            k7
Architektura trzywarstwowa i wielowarstowa
                                                          three-tier architecture
                                                          multi-tier architecture
 Architektura klient-serwer podzielona na trzy
  warstwy:
    • interfejs użytkownika,                                Interfejs
    • logikę przetwarzania (reguły biznesu, logikę        użytkownika
      biznesu)
    • serwer (serwery) bazy danych.
 Warstwy są zaprojektowane i istnieją niezależnie,   Logika przetwarzania
  co ma duże znaczenie dla pielęgnacyjności
  systemu ze względu na możliwość zmian w
  dowolnej warstwie bez konieczności zmian w
  pozostałych warstwach.
 Często warstwy są zrealizowane na odrębnych
  platformach: interfejs na MS Windows, logika        Serwer          Serwer
  przetwarzania na serwerze aplikacji i baza           bazy            bazy
  danych na serwerze bazy danych.                     danych          danych

 Środkowa warstwa może składać się z wielu
  warstw, co jest określane jako architektura
     Logiczna architektura oprogramowania
         Architektura klient-serwer powinna odzwierciedlać logiczny podział
         oprogramowania na części. Nie jest to tak istotne w systemie scentralizowanym.

  Architektura trójwarstwowa:                  Staranne rozdzielenie tych warstw jest
                                               bardzo istotne z punktu widzenia
cienki      Warstwa prezentacyjna              tworzenia i modyfikowalności
klient      (interfejs użytkownika)
                                               oprogramowania. Dzięki temu
                                      gruby    rozdzieleniu, możliwa jest np. poprawa
                                      klient   interfejsu użytkownika bez jakichkolwiek
            Warstwa przetwarzania              interwencji w pozostałe warstwy
              (logika biznesu)                 oprogramowania.

                                                Zasada oddzielania aspektów
                                                (separation of concerns principle,
             Warstwa zarządzania                E.Dijkstra)
                bazą danych
                  Cienki i gruby klient
Terminy cienki klient (thin client) oraz gruby klient (fat client) odnoszą się do
mocy i jakości przetwarzania po stronie klienta w architekturze klient-serwer.
Model cienkiego klienta: klient posiada niezbyt wielką moc przetwarzania,
ograniczoną do prezentacji danych na ekranie. Przykładem jest klient w postaci
przeglądarki WWW.
Model grubego klienta: klient posiada znacznie bogatsze możliwości
przetwarzania, w szczególności może zajmować się nie tylko warstwą
prezentacji, lecz także warstwą przetwarzania aplikacyjnego (logiki biznesu).
Powyższy podział posiada oczywiście pewną gradację.
Model cienkiego klienta jest najczęstszym rozwiązaniem w sytuacji, kiedy
system scentralizowany jest zamieniany na architekturę klient-serwer. Wadą jest
duże obciążenie serwera i linii komunikacyjnych.
Model grubego klienta używa większej mocy komputera klienta do
przetwarzania zarówno prezentacji jak i logiki biznesu. Serwer zajmuje się tylko
obsługą transakcji bazy danych. Popularnym przykładem grubego klienta jest
bankomat. Zarządzanie w modelu grubego klienta jest bardziej złożone.
                Architektury dwuwarstwowe

    Uproszczone architektury trójwarstwowe z cienkim lub grubym klientem.


cienki   Warstwa prezentacyjna              Warstwa prezentacyjna
klient   (interfejs użytkownika)           (interfejs użytkownika)       gruby
                                           + Warstwa przetwarzania       klient
                                               (logika biznesu)

         Warstwa przetwarzania
           (logika biznesu) +
          Warstwa zarządzania               Warstwa przetwarzania
              bazą danych                     (logika biznesu) +
                                             Warstwa zarządzania
                                                 bazą danych

                                           W tym modelu przetwarzanie
                                           (logika biznesu) jest dzielone
                                           pomiędzy klienta i serwera.
                                           Zaprojektowanie jej jest trudniejsze.
Przykład architektury K/S - sieć bankomatów

        Bankomat



     Bankomat               Serwer kont klientów banku
                     Monitor            Baza danych kont
                     tele-przetwarzania klientów banku
       Bankomat

                    Oprogramowanie pośredniczące
                    organizujące komunikację z odległymi
        Bankomat    klientami i szeregujące transakcje klientów
                    celem przetwarzania ich przez bazę danych.
Przykład architektury K/S - portal WWW

         interakcja
          poprzez
klient     HTTP
                                           zapytania
                       Serwer Web:           SQL
klient                     generacja                   Serwer bazy
                      dynamicznych stron                 danych:
                       HTML dla klienta                 wykonywanie
klient                        +
                                            wyniki     zapytań w SQL
                       zlecenia do bazy
                                           zapytań
                            danych
                                             SQL
klient
   3-warstwowa architektura aplikacji Web



                                     Serwer Web

                        Sieć       Serwer aplikacji
                      Internet
                                 Serwer bazy danych
               HTTP
                                  Baza         Baza
                                 danych       danych
Przeglądarka

                                     Serwer
   2-warstwowa architektura aplikacji Web
  Wiele warstw pośredniczących powoduje dodatkowe obciążenie.




                                                Serwer Web
                        Sieć                  Serwer aplikacji
                      Internet
                                            Serwer bazy danych
               HTTP
                                             Baza         Baza
                                            danych       danych
Przeglądarka

                                                Serwer
   Zastosowanie różnych architektur K/S
 Dwuwarstwowa architektura K/S z cienkim klientem
  • Systemy spadkowe (legacy), gdzie oddzielenie przetwarzania i zarządzania
    danymi jest niepraktyczne.
  • Aplikacje zorientowane na obliczenia, np. kompilatory, gdzie nie występuje lub
    jest bardzo mała interakcja z bazą danych.
  • Aplikacje zorientowane na dane (przeglądanie i zadawanie pytań) gdzie nie
    występuje lub jest bardzo małe przetwarzanie.
 Dwuwarstwowa architektura K/S z grubym klientem
  • Aplikacje w których przetwarzanie jest zapewnione przez wyspecjalizowane
    oprogramowanie klienta, np. MS Excel.
  • Aplikacje ze złożonym przetwarzaniem (np. wizualizacją danych,
    przetwarzaniem multimediów).
  • Aplikacje ze stabilną funkcjonalnością dla użytkownika, użyte w środowisku z
    dobrze określonym zarządzaniem.
 Trzywarstwowa lub wielowarstwowa archiktektura K/S
  • Aplikacje o dużej skali z setkami lub tysiącami klientów.
  • Aplikacje gdzie zarówno dane jak i aplikacje są ulotne (zmienne).
  • Aplikacje integrujące dane z wielu rozproszonych źródeł.
     Architektura rozproszonych obiektów
 W architekturze klient-serwer istnieje wyraźna asymetria pomiędzy
  klientem i serwerem; w szczególności, nie występuje tam komunikacja
  bezpośrednio pomiędzy klientami. Model taki dla wielu zastosowań jest
  mało elastyczny i zapewnia zbyt małą skalowalność.
 Architektura rozproszonych obiektów znosi podział na klientów i
  serwery. Każde miejsce w rozproszonym systemie jest jednocześnie
  klientem i serwerem.
 Konieczne jest sprowadzenie wszystkich danych i usług do jednego
  standardu.
 Taki standard obejmuje:
   • Model (pojęciowy i logiczny) danych i usług, który jest w stanie "przykryć"
     wszystkie możliwe dane i usługi, które mogą kiedykolwiek pojawić się w
     systemie rozproszonym;
   • Specjalne oprogramowanie zwane pośrednikiem (broker), które akceptuje
     wspólny model danych i usług umożliwiając ich udostępnienie dla dowolnych
     miejsc w systemie rozproszonym.
   • Specjalne oprogramowanie, zwane osłoną, adapterem lub mediatorem, które
       Architektura klient-broker-serwer
 Dostęp do odległych zasobów sieci komputerowej odbywa
  się miedzy klientem (klientami) a serwerem (serwerami) nie
  odbywa się bezpośrednio lecz za pomocą pośrednika
  (brokera)
 Pośrednik zapewnia przezroczystość do odległych
  geograficznie zasobów,
 Broker przedstawia wszystkie zasoby w postaci zbioru
  obiektów, dzięki czemu możliwe jest ujednolicenie operacji
  wykonywanych na zasobach, niezależnie od ich
  implementacji i realizacji wewnętrznej,
 Fizyczna lokalizacja obiektów nie jest istotna dla
  użytkownika, gdyż położenie obiektów znane jest brokerowi,
 Pośrednik otrzymuje zadanie od klienta, lokalizuje serwer z
  potrzebnymi zasobami, przekazuje zlecenie oraz
  przekazuje zwrotnie wynik zlecenia zrealizowanego przez
  Architektura klient-broker-serwer




 Host klienta
                                     Host serwera

                      zlecenie
Wywołanie       Pośrednik (Broker)
 operacji
                     wynik,
   Klient         parametry WY
                                      Obiekt
 Architektura rozproszonych obiektów (2)

        Aplikacja            Aplikacja na               Aplikacja
       napisana w             relacyjnej                na Lotus
          C++                bazie danych                Notes



       Osłona 1                Osłona 2                 Osłona 3



...    Pośrednik               Pośrednik                Pośrednik   ...
                  Szyna oprogramowania (software bus)



      Miejsce 1               Miejsce 2                 Miejsce 3
  Struktura logiczna rozproszonych obiektów
              O1               O3          O5             O7
Obiekty                 O2                                             O9
                                      O4             O6         O8



Operacje na        K1                           K3
obiektach                    K2                                K4


                         Szyna oprogramowania (software bus)



Aplikacje          A1                 A2                    A3
Szyna oprogramowania tworzy jedną przestrzeń obiektów. Obiekty te są dostępne dla
dowolnego miejsca poprzez operacje (zgrupowane w klasach). Miejsca i sposoby
implementacji obiektów są niewidoczne. Aplikacje korzystają z całej puli obiektów.
   „Semistrukturalna” architektura aplikacji
               internetowych
                                                Narzędzia
                                          wspomagające XML :                                 Warstwa klienta
                      Przeglądarka         system autorski, itd.         Przeglądarka
                         WWW                                                WWW

                                XML                                    XML

                                                Serwer Web
                                              Serwer aplikacji                 Logiczna warstwa pośrednia

       Interakcja z aplikacjami poprzez
       protokoły oparte na XML                                                  Serwer integrujący XML,
                                            Baza danych w XML                        serwer zapytań,
                                             (strukturalizowana)                 serwer hurtowni danych
                                                                   XML
                            XML           XML       XML
                                                                   Translatory formatów
                                                                    z/do XML, pomosty
                                                                                               Zasoby danych

                                                   Dokumenty
                                                    Dokumenty                Inne
                                                                               Inne
Obiektowo-relacyjna        Obiektowa baza            XML                 dokumenty na         Zasoby danych
                                                      XML                 dokumenty na
    baza danych                danych                 na                 Webie: HTML           pod OLE/DB
                                                       na                 Webie: HTML
wspomagająca XML         wspomagająca XML            Webie
                                                      Webie                Word,...
                                                                             Word,...
  Standardy łączenia
rozproszonych zasobów
Standardy łączenia rozproszonych danych (1)
 Open DataBase Connectivity (ODBC): standard [zdalnego]
  dostępu do relacyjnych baz danych
   • bazuje na Call Level Interface (CLI) opracowanym przez konsorcjum
     X/Open
   • definiuje API oraz cechy SQL które muszą być zapewnione na różnych
     poziomach zgodności.
 Java DataBase Connectivity (JDBC): analogiczny do ODBC
  standard dla Java.
 Standardy X/Open XA: definiują zarządzanie transakcjami ze
  wspomaganiem protokołu 2PC.
 OLE-DB: API podobne do ODBC, ale wspomagające źródła nie-
  bazodanowe, takie jak płaskie pliki.
   • OLE-DB program może negocjować ze źródłem danych aby znaleźć
     własności, które ono podtrzymuje.
   • API jest podzbiorem SQL
Standardy łączenia rozproszonych danych (2)
 ADO (Active Data Objects): łatwy interfejs do funkcji OLE-DB
 Kilka standardów bazujących na XML dla E-commerce
   • Np. RosettaNet (łańcuchy dostaw), BizTalk
   • Definiują katalogi, opisy usług, faktury, zamówienia, itd.
   • osłony XML są używane do eksportu informacji z relacyjnej BD do
     XML
 Resource Description Framework (RDF): specyfikacja ontologii dla
  zasobów Web.
 Simple Object Access Protocol (SOAP): bazujący na XML standard dla
  zdalnego wołania procedur (RPC). SOAP jest mniej elastyczny i
  uniwersalny w stosunku do CORBA, ale pozostaje pytanie, czy aż taka
  elastyczność i uniwersalność jest potrzebna.
   • Używa XML do zakodowania danych, HTTP jako protokołu
     transportowego
   • Dalsze standardy są oparte na SOAP dla specyficznych aplikacji, np.
     OLAP i Data Mining (standardy Microsoft'u)
Standardy łączenia rozproszonych danych (3)
 Object Data Management Group (ODMG) standard obiektowych
  baz danych
   • jest używany w projektach przyszłościowych związanych z
     rozproszonymi lub federacyjnymi bazami danych, np. IRO/DB.
 OMG CORBA (Common Object Request Broker Architecture) -
  najbardziej uniwersalny standard obejmujący ogromną liczbę
  aspektów. W szczególności, notacja UML jest jego składową.
  Pakiety ORB (Object Request Broker) są oprogramowaniem
  realizującym tę architekturą.
 .NET/DCOM (Distributed Component Object Model) - standard
  Microsoftu zintegrowany z systemami operacyjnymi Microsoftu.
  Znacznie ograniczony w stosunku do standardu CORBA.
 RMI (Remote Method Invocation) - oprogramowanie firmy Sun,
  ograniczone w stosunku do standardu CORBA do oprogramowania
  pisanego w Java. Java Beans i Enterprise Java Beans
  wykorzystują RMI jako transport.
Replikacje
                            Replikacje

Technologia replikacji oznacza przechowywanie dwóch lub więcej
kopii danych (replik) w oddalonych geograficznie miejscach.


 Cele:
          Zwiększenie dostępności danych poprzez:
          - zminimalizowanie czasu i kosztów ich transmisji z odległego
          miejsca
          - rozłożenie obciążenia w zakresie dostępu na wiele kopii danych

          Zwiększenie odporności danych na zniszczenie.

          Zwiększenie bezpieczeństwa
                  Aktualizacja replikacji

Aktualizacja dowolnej kopii danych powinna spowodować jednoczesną
aktualizację wszystkich pozostałych kopii. W idealnym przypadku powinno to
następować jednocześnie, aby zapobiec sytuacji, gdy dane przechowywane w
różnych kopiach są wzajemnie niespójne. Ten ideał nie daje się zrealizować tak
łatwo z kilku powodów:
Czas transmisji zleceń aktualizacyjnych powoduje, że kopie są chwilowo
wzajemnie niezgodne;
Zawodność łączy i węzłów sieci może spowodować czasową niemożliwość
wykonania zlecenia aktualizacyjnego;
Koszt transmisji zleceń aktualizacyjnych może być nieakceptowalny w przypadku
bardzo częstych zmian.
Można wyobrazić sobie sytuację, kiedy każda aktualizacja dowolnej kopii jest
wykonywana w ramach transakcji, która nie będzie potwierdzona aż do momentu
zaktualizowania wszystkich kopii. Takie rozwiązanie w większości przypadków
powoduje jednak znaczne zmniejszenie dostępności danych.
                          Modele replikacji
  Jednoczesne aktualizacje                             Propagacja aktualizacji
  ze sterowaniem współbieżnościa
                                                 Transakcja aktualizująca
   Transakcja aktualizująca

                                                               propagacja
                                                               aktualizacji


                                             Replika 1                        Replika 3
Replika 1     Replika 2    Replika 3
                                                                    Replika 2
            Planowane odświeżanie kopii dla replik tylko do czytania
                          Transakcja aktualizująca

                                       planowana
                                       aktualizacja
                                                               Transakcja czytająca

              Replika 1                                Replika 3
                                                           Transakcja czytająca
                                           Replika 2
                        Wady replikacji
 Konieczna dodatkowa przestrzeń dyskowa
 Możliwość powstania niespójności pomiędzy repliką i
  oryginałem => zagrożenie dla spójności procesów
  biznesowych
   • Np. jeżeli dane o wysokości kont są powtórzone w wielu miejscach,
     wówczas ktoś korzystając z (celowo) uszkodzonych linii
     transmisyjnych może dokonać nielegalnych wypłat.
 Zwiększenie kosztów aktualizacji danych: aktualizacja
  oryginału pociąga za sobą dodatkowy koszt aktualizacji replik
   • reguła kciuka (bardzo uproszczona):
                    ilość zapytań czytających
            Jeżeli                               > ilość replik
                    ilość zleceń aktualizujących
            to warto tworzyć repliki.
            W przeciwnym przypadku - nie warto.


   • Przy dokładnej analizie należy utworzyć bardziej złożone modele
     kosztów, które ustalą opłacalność replik.
Przetwarzanie transakcji
               Przetwarzanie transakcji
Problemy z transakcjami w systemach rozproszonych:
  Faza potwierdzenia (commit) może trwać długo. Niepowodzenie
   (awaria) w tej fazie może spowodować niespójność bazy danych i
   przetwarzania. Stąd nowe protokoły przetwarzania transakcji w
   systemie rozproszonym: 2PC, 3PC.
  Zakleszczenie: wykrywanie i usuwanie jest znacznie trudniejsze,
   gdyż wymaga przesyłania w sieci informacji która transakcja czeka
   na którą.
  Ziarnistość mechanizmu transakcji: bezpośrednio związana z
   dostępnością rozproszonej bazy danych (liczbą jednocześnie
   pracujących użytkowników).
  Wydajność (performance): złożone protokoły powodują jej
   zmniejszenie; stąd 2PC i 3PC są często nieadekwatne.
  Długie transakcje: konieczność zmniejszenia poziomu izolacji aby
   umożliwić dostęp do zablokowanych danych.
      Implementacja transakcji poprzez zamki
Zamek (lock): jedna z transakcji rezerwuje sobie dostęp do obiektu.
Spójność przetwarzania transakcji jest zachowana, jeżeli cała transakcja ma dwie fazy:
rosnącą i skracającą.
                                                           potwierdzenie
                                                           (commit)              koniec
         start

                                          zakładanie zamków     zwalnianie
                                          (nie ma zwalniania)   zamków (nie
                                                                ma zakladania)
                                                                                          czas
Awaria w fazie potwierdzenia jest krytyczna, gdyż grozi utratą spójności.
   W systemach rozproszonych faza potwierdzenia może trwać minuty i
    włącza zawodne zawodne elementy infrastruktury (łącza).
   Warunek atomowości oznacza, że jeżeli transakcja dzieli się na wiele
    podtransakcji wykonywanych na odległych serwerach, to nie może zajść
    sytuacja, gdy podtransakcja na serwerze A jest potwierdzona, zaś
    podtransakcja na serwerze B jest zerwana.
   Stąd konieczność dodatkowej ochrony fazy potwierdzenia => 2PC.
           Dwufazowe potwierdzenie (2PC)
                   Koordynator (program aplikacyjny klienta)


                                 SZBD klienta




                                        potwierdź
          SZBD serwera           SZBD serwera            SZBD serwera




1. Serwery wysyłają komunikaty “gotów “ do koordynatora.
2. Po skompletowaniu wszystkich zgłoszeń koordynator wysyła komunikat
“potwierdź” do wszystkich serwerów.
Jeżeli nie nadejdą wszystkie zgłoszenia “gotów”, koordynator wysyła komunikat
“zerwij transakcję” do wszystkich serwerów.
Wada: duże straty wykonanej pracy w przypadku zerwania.
            2PC - zarządzanie awariami
 Dość złożone postępowanie zależne od tego, czy awarii uległ
  serwer czy też koordynator.
 Protokół 2PC określa:
   • Czas graniczny (timeout) nadesłania sygnału "gotów" od wszystkich
     serwerów do koordynatora . Jeżeli czas graniczny minął oraz nie ma
     wszystkich sygnałów "gotów", to koordynator wysyła do wszystkich
     serwerów sygnał "zerwij".
   • Sposób rejestracji sygnałów od koordynatora w dzienniku serwera. W
     razie awarii serwera, po jego ponownym postawieniu, analizowany jest
     dziennik celem stwierdzenia, czy transakcja ma być potwierdzona, czy
     zerwana.
 Problem blokowania: w razie awarii koordynatora wszystkie
  transakcje na serwerach, które zgłosiły "gotów" są przyblokowane.
  Serwery "nie wiedzą", co dalej robić. Postawienie koordynatora
  może trwać długo.
 Bardziej złożony protokół 3PC uwzględnia awarie koordynatora .
 3PC nie znalazł jednak szerszego zastosowania ze względu na
Transakcje w federacyjnej bazie danych (1)
 Lokalne transakcje są wykonywane autonomicznie przez
  lokalny SZBD. Federacja nic o nich nie wie i (z reguły) nie
  może się dowiedzieć.
 Globalne transakcje są wykonywane przez aplikacje
  globalne. Mogą składać się z wielu podtransakcji,
  wykonywanych przez lokalne SZBD.
 Z punktu widzenia lokalnego SZBD podtransakcja globalnej
  transakcji jest normalną lokalną transakcją.
 W związku z tym, zapewnienie szeregowalności globalnych
  transakcji (niezbędny warunek dla utrzymania spójności
  przetwarzania) w FBD jest trudne lub wręcz niemożliwe.
 Dlaczego? - następny slajd.
Transakcje w federacyjnej bazie danych (2)
 Lokalne bazy danych mogą stosować różnorodne algorytmy
  przetwarzania transakcji. Autonomia oznacza, że federacja nie ma
  wpływu na te algorytmy.
 Lokalna BD może w każdej chwili z różnych powodów (np.
  zakleszczenia) zerwać dowolną transakcję, w tym podtransakcję
  indukowaną przez globalną transakcję.
 Informacja o wewnętrznym stanie lokalnie przetwarzanych
  transakcji (np. stan dziennika transakcji, zamki zakładane przez
  transakcje, itd.) nie jest widoczna na zewnątrz.
 Stosowanie typowych algorytmów, np. 2PC (two phase commit)
  jest niemożliwe, gdyż lokalna BD może nie posiadać możliwości
  zawieszenia podtransakcji w stanie “gotowa” i czekać na sygnał
  potwierdź ze strony globalnej transakcji.
Niezgodności schematów i
        ontologii
                Niezgodności schematów
                                     schematic discrepancies
Przy integracji niezależnie zaprojektowanych baz danych w jeden schemat należy się
liczyć z tym, że organizacja, struktura i semantyka danych będzie niezgodna.
Nie istnieje ani “jeden” ani “najlepszy” sposób odwzorowania dziedziny
przedmiotowej w struktury danych zapamiętane w bazie danych. Różni projektanci
projektują całkowicie odmienne struktury dla tego samego problemu.
Dlaczego?

 Obiekty tej samej dziedziny problemowej mogą być widziane przez
  różnych projektantów całkowicie odmiennie.
 Systemy zarządzenia BD mają ograniczenia struktur danych, które
  wymuszają sposób myślenia projektantów nad koncepcją struktur danych.
 Różne środki manipulacji strukturami dostarczane przez SZBD
  wymuszają często różną koncepcję.
 Projektanci podejmują różnorodne decyzje co do koncepcji struktur
  danych w związku z zamierzonymi własnościami użytkowymi, np.
  szybkością dostępu.
 Niezgodności ontologii w rozproszonych BD
                    (1)
Są one poważną przeszkodą, która pojawia się podczas konstruowania
federacyjnych rozproszonych BD.
Niezgodności te dotyczą różnych aspektów organizacji i działania:
   Niezgodności pomiędzy modelami danych: relacyjna vs. obiektowa vs.
    hierarchiczna XML-owa, itd.
   Niezgodności pomiędzy schematami pojęciowymi. Np. w jednej BD
    informacja o dzieciach pracownika jest atrybutem jego obiektu, zaś w
    innej jest związkiem łączącym obiekt pracownika z obiektami osób. W
    zależności od BD te same dane mogą występować raz jako nazwy
    (obiektów, atrybutów), a raz jako ich wartości. Nawet gdy zespoły stosują
    tę samą metodykę projektowania, to na ogół ich projekty pojęciowe są
    zasadniczo różne.
   Niezgodności pomiędzy schematami logicznymi. Można oczekiwać,
    że w niezależnie zbudowanych bazach danych nazwy obiektów, nazwy
    atrybutów oraz ich zestaw będą inne. Mogą występować poważniejsze
    różnice w zakresie organizacji logicznej; np. w pewnej lokalnej bazie
    danych informacja o pracownikach może być rozbita na dwie lub więcej
    tablic.
Niezgodności ontologii w rozproszonych BD
                   (2)
 Niezgodności w zakresie interpretacji semantycznej danych.
  W jednej bazie danych zarobek pracownika może być zarobkiem
  brutto, w innej - netto, zaś jeszcze w innej może być rozbity na
  pensję, premię i dodatki.
 Niezgodności dotyczące budowy i środków dostępu do
  katalogów. W relacyjnej BD katalog jest zbiorem relacji dostępnym
  przy pomocy SQL, w innej bazie katalog może nie istnieć explicite,
  zaś informacje katalogowe są dostępne poprzez zmienne
  środowiskowe oraz specjalne procedury i funkcje.
 Niezgodności dotyczące reprezentacji danych. W jednej BD
  informacja o zawodzie pracownika jest przechowywana na
  przykład w postaci ciągu znaków, a w innej przy pomocy numeru
  zawodu i specjalności, którym towarzyszy tabela umożliwiająca
  interpretację (niekoniecznie przechowywana w BD). Mogą
  występować różnice w reprezentacji dat, czasu i innych atrybutów,
  różnice w zakresie precyzji reprezentacji wielkości liczbowych oraz
  zarezerwowanych długości obszarów dla wartości znakowych, itp.
Niezgodności ontologii w rozproszonych BD
                   (3)
 Niezgodności dotyczące odniesienia danych do skali
  czasowej. Informacje mogą być np. aktualizowane natychmiast,
  zaś w innej BD raz na miesiąc.
 Niezgodności w sposobach dostępu. W jednej BD dostęp do
  danych będzie realizowany na przykład przy pomocy
  standardowego SQL, a w innej poprzez środki dostępu pewnego
  języka czwartej generacji lub API.
 Różna strukturalizacja informacji. Np. w jednej BD utworzono
  odrębną tabelę PrzynależnośćDoZwiązkuZawodowego, zaś w innej
  ta przynależność jest atrybutem tabeli Pracownik; w jednej BD
  atrybut Adres jest polem tekstowym, w innej zaś strukturą z polami
  Miejscowość, Ulica, NrDomu, itd.
 Podział danych i metadane. Np. w jednej BD atrybut Zawód tabeli
  Pracownicy jest stringiem, zaś w innej utworzono odrębne tabele.
  Piekarze, Stolarze, itd. dużo. Niezależnie zbudowane lokalne bazy
   Niezgodności jest bardzo
   danych zawsze będą obciążone tego rodzaju konfliktami.
              Kanoniczny model danych
                                                           canonical data model

 Jeżeli wiele baz danych ma tworzyć jedną federacyjną bazę danych w której
 będzie obowiązywać jeden wspólny API f, wówczas potrzebny jest model
 danych w terminach którego dadzą się wyrazić wszystkie inne modele danych.
 Model powinien także uwzględniać fakt, że w federacji mogą pojawić się nowe
 bazy danych, których założeń nie rozpatrywaliśmy podczas jej tworzenia.
 Który z modeli danych mógłby być takim kanonicznym modelem danych?
 Relacyjny? Encja-związek? UML? CORBA? ODMG? Jakiś inny?
 Jeżeli nie chcemy debaty religijnej o wyższości modelu A nad B, to powstaje
 pytanie o obiektywne kryteria. Czy istnieją?

Debata nad kanonicznym modelem danych traktuje modele danych jako
obiektywne byty o ostro zarysowanych własnościach i granicach.
Nie jest to słuszne. Modele danych są tworami subiektywnymi, o niejasnych
granicach, podlegają ciągłej ewolucji, możliwe są różnorodne ich mutacje i
rozszerzenia. Istnieje potencjalnie wiele modeli relacyjnych i wiele modeli
obiektowych.
Kryteria wyboru kanonicznego modelu danych

Ekspresyjność (expressiveness): w jakim stopniu dany model jest w stanie
bezpośrednio odwzorować pojęcia z modelu pojęciowego dziedziny
aplikacyjnej oraz definiować nowe operacje, typy danych i więzy integralności.
Np. model relacyjny nie ma bezpośrednich odwzorowań złożonych obiektów,
dziedziczenia, agregacji, informacji behawioralnych, itd., wobec czego ma
niską ekspresyjność. Pod tym względem model obiektowy ma przewagę.
Relatywizm semantyczny (semantic relativism): stopień, w jakim dany model
umożliwia wiele punktów widzenia na tę samą dziedzinę aplikacyjną. Miarą
relatywizmu semantycznego danego modelu jest możliwość budowania
dowolnych schematów zewnętrznych (perspektyw) nad schematem bazy
danych. Model relacyjny posiada pewien stopień relatywizmu, dzięki jego
zdolności definiowania perspektyw (ograniczonej, szczególnie w zakresie
aktualizacji perspektyw). Definiowanie perspektyw nie jest mocną stroną
systemów obiektowych, jakkolwiek nie istnieją tu ograniczenia koncepcyjne.
Federacyjne bazy danych
 Co to jest Federacyjna Baza Danych?
                                                         Federated Database


Jest to kolekcja heterogenicznych, autonomicznych baz danych, połączonych
siecią komputerową, zarządzana specjalnym systemem określanym jako
Federacyjny System Zarządzania Bazą Danych (FSZBD). Może włączać
dziesiątki, setki, tysiące lub więcej lokalnych baz danych.
FSZBD umożliwia tworzenie aplikacji globalnych, działających na całości
federacyjnej bazy danych. Jest ona zdefiniowana schematem federacyjnym,
będącym sumą schematów eksportowych lokalnych baz danych.
FSZBD zapewnia warunki pracy twórców aplikacji globalnych określane jako
przezroczystość i niezależność danych.
FSZBD może być zainstalowany w wielu węzłach sieci (m.in. w każdym
lokalnym miejscu FBD), umożliwiając tworzenie aplikacji globalnych w wielu
miejscach geograficznych. Poszczególne FSZBD współpracują ze sobą celem
zapewnienia spójności i integralności przetwarzania.
    Architektura federacyjnej bazy danych
                     Aplikacje globalne                Aplikacje globalne


                FSZBD
                  1
                               Przestrzeń
                                robocza

                        Schemat FBD
                                             ...       FSZBD
                                                         m
                                                                 Przestrzeń
                                                                  robocza

                                                          Schemat FBD




                                          Sieć
                                       komputerowa


Schemat eksportowy 1            Schemat eksportowy 2                     Schemat eksportowy n
     Osłona 1                        Osłona 2                                 Osłona n


Lokalny
SZBD 1
       API 1


              BD 1
                               Lokalny
                               SZBD 2
                                       API 2


                                              BD 2
                                                        ...             Lokalny
                                                                        SZBD n
                                                                                API n


                                                                                      BD n



Aplikacje lokalne              Aplikacje lokalne                        Aplikacje lokalne
      Architektura dostępu do lokalnej BD matrix)
                      Global schema
                  (in an extended ODL)
                                           External sub-schemata
                                       (through an accessibility
Lokalna baza danych             Lokalny schemat            Zewnętrzne podschematy
                                  eksportowy            użytkowników (macierz dostępu)
                                                           Zewnętrzny     Zewnętrzny     Zewnętrzny
                                                          podschemat 1   podschemat 2   podschemat 3

      Obiekty A                      Interfejs IA1          Dostęp          Zakaz          Zakaz
      Obiekty A
       Obiekty A
        Dane A
                                     Interfejs IA2
                                                             Zakaz          Zakaz         Dostęp
      Obiekty A
      Obiekty A      Mediator
       Obiekty A                     Interfejs IB1
                     Osłona
        Dane B                                              Dostęp          Zakaz         Dostęp
                      API




       Obiekty A
       Dane C                        Interfejs IC1           Zakaz         Dostęp          Zakaz


     Ob.wirt. V3
     Ob.wirt. V3 V                   Perspektywa V1          Zakaz         Dostęp         Dostęp
      Dane wirt. 1

     Ob.wirt. V3                                             Dostęp         Zakaz          Zakaz
     Ob.wirt. V3 V                   Perspektywa V2
      Dane wirt. 2



                           definiuje


                                    Administrator        Użytkownik Użytkownik          Użytkownik
                                 lokalnej bazy danych         1          2                   3
Trój-warstwowa architektura federacyjnej BD
              Użytkownik 1          Użytkownik 2                Użytkownik 3
3       Schemat zewnętrzny 1    Schemat zewnętrzny 2         Schemat zewnętrzny 3


                                 Schemat federacyjny
2                                FSZBD          Przestrzeń
                                                 robocza




                                         Sieć



1   Schemat eksportowy 1       Schemat eksportowy 2
         Osłona 1


    Lokalny
    SZBD 1
           API 1


                  BD 1
                                    Osłona 2


                               Lokalny
                               SZBD 2
                                      API 2


                                             BD 2
                                                                   ...
              Przetwarzanie zapytań w FBD
 Podstawowe algorytmy przetwarzania zapytań w homogenicznych i federacyjnych
 relacyjnych BD są podobne. Różnice dotyczą cech autonomii i heterogeniczności,
 które znacznie komplikują problem. Algorytmy polegają na dekompozycji zapytania
 na pewne podzapytania kierowane do lokalnych BD, następnie na skomponowaniu
 globalnego wyniku z wyników cząstkowych zwróconych przez lokalne BD.
 Komplikacje
 • Niezgodności schematów, które wymagają mechanizmu refleksji lub nowych
   operatorów w SQL.
 • Brak algorytmicznej uniwersalności SQL.
 • Ograniczona moc mechanizmu definiowania perspektyw.


Problem został rozwiązany dla niektórych przypadków, ale nie dla generalnego.
Wygląda na to, ze w ramach obecnych paradygmatów modelu relacyjnego niewiele
więcej da się zrobić.

W obiektowych bazach danych problem jest na początku drogi. Nie są mi znane
istotne prace, które dałyby nadzieję na rozwiązanie. Przymiarki, spekulacje,...
      Rozproszone BD w standardzie CORBA
  Oprogramowanie komponentowe budowane wg standardu CORBA może być
  podstawą rozproszonych/federacyjnych baz danych.

     Host globalnej aplikacji                                 Host lokalnej BD

       Klient                                                        Obiekty
                                                                      Obiekty
                                                                       Obiekty

       Wywołanie                                           Implementacja
        operacji                                           interfejsów do
                    Pieniek                                   obiektów
                                        zlecenie
                    klienta                               (szkielety + kod)
                    Pośrednik (ORB, Object Request Broker)
                                  wynik, parametry wyj
Implementacja interfejsów do obiektów po stronie serwera powstaje ze szkieletu
automatycznie generowanego z wyrażenia IDL, który jest wypełniany kodem operacji.
Taki szkielet pełni jednocześnie funkcję osłony oraz funkcję perspektywy. ORB jest w
stanie zapewnić autonomię lokalnej BD.
   Problemy z RBD w standardzie CORBA
 CORBA nie jest nastawiona na przetwarzanie danych trwałych i
  masowych przy pomocy języków zapytań. Jest to poziom języków
  takich jak C++ i Java, znacznie niższy. Obecny stan standardyzacji
  w zakresie Query Service i Persistence Service jest uważany za
  niezadowalający.
 CORBA nie wprowadza pojęcia perspektywy. Osłony w CORBA są
  pisane w językach niskiego poziomu, są zorientowane na daną
  aplikację, nie dają konceptualizacji takiej, jaką dają perspektywy.
 Mogą być znaczne narzuty na wydajność maszynową i
  produktywność programistów globalnych aplikacji.
 CORBA nie rozwiązuje problemów związanych z przetwarzaniem
  transakcji w rozproszonych/federacyjnych bazach danych.
 Model obiektowy CORBA jest ograniczony, m.in. nie uwzględnia
  związków i zagnieżdżonych kolekcji. Te możliwości są
  uwzględniane w usługach (np. Relationship Service), które nie są
Osłony i mediatory
                            Osłona                              wrapper
           Moduł oprogramowania umożliwiający przystosowanie interfejsu
           lokalnej bazy danych do pewnego standardu obowiązującego w
           systemie rozproszonym.

Podstawowe zadanie: fizyczne połączenie różnych baz danych.
 Osłona nie zajmuje się bardziej wyrafinowanym odwzorowaniem;
  chodzi o translację danych, parametrów i wywołań funkcji
  płynących z zewnątrz lokalnego systemu (o specyficznych
  formatach i reprezentacji) na analogiczne dane, parametry i funkcje
  wyrażone w API konkretnego lokalnego systemu bazy danych.
 Dla niektórych przypadków, np. dla niektórych stron HTML,
  napisanie osłony jest bardzo trudnym zadaniem ze względu na
  nieregularności formatu (dane pół-strukturalne, semi-structured).
 Osłona jest niezbędna do tego, aby budować bardziej
  wyrafinowane środki odwzorowania schematów i aplikacji, takie jak
  mediatory i perspektywy
             Osłony w federacyjnych BD
Osłona udostępnia dane i usługi lokalnego systemu i (dostępne w pewnym API i)
dla aplikacji globalnych (wykorzystujących wspólny API f).
Osłony przystosowują lokalne      SZBD     do   interfejsu     programistycznego
obowiązującego w federacji.


                            Federacyjny
                                 SZBD


            API f                API f                                  API f
 Osłona 1             Osłona 2                               Osłona n

 Lokalny
            API 1
                      Lokalny
                                 API 2     ...               Lokalny
                                                                        API n

 SZBD 1               SZBD 2                                 SZBD n
   Osłony dla lokalnych relacyjnych SZBD
Problem pojawia się wtedy, gdy API f dla federacyjnej bazy danych nie jest
oparty o model relacyjny, lecz o model obiektowy a la CORBA lub ODMG.
Potencjalne problemy i rozwiązania:
 Konieczność silnego ograniczenia modelu obiektowego, np. brak
  złożonych obiektów, metod, związków, hermetyzacji, polimorfizmu, itd.;
 Odwzorowanie krotek tabel na złożone obiekty - wiele krotek składających
  się na jeden obiekt. Przetwarzanie np. w OQL+Java. Problemy
  koncepcyjne.
 Odwzorowanie obiektowego API, np. OQL +Java na relacyjne API, np.
  JDBC. Ogólne rozwiązanie jest bardzo trudne.
 Zredukowanie API relacyjnej BD do prymitywnych operacji (get first, get
  next,...), dzięki czemu relacyjną bazę danych można będzie potraktować
  jako prymitywną obiektową bazę danych. Następnie, zdefiniowanie
  obiektowych, wirtualnych, aktualizowalnych perspektyw.
  Problemy koncepcyjne. Problemy z wydajnością.
                                 Mediatory                            mediator
Warstwa pośrednia pomiędzy lokalną bazą danych a globalnymi aplikacjami.
Jest konieczny wtedy, gdy nie ma odwzorowania 1:1 pomiędzy ontologiami.
Np. w jednej bazie podany jest zarobek brutto z ubezpieczeniem, w innej
zarobek brutto bez ubezpieczenia. Jak to sprowadzić do wspólnego
mianownika?
Zadania mediatora:
   Rozstrzyganie rozbieżności pomiędzy schematem lokalnym a schematem
    federacyjnym.
   Wspomaganie dla wyłowienia cech formalnych z danych niesformatowanych.
   Selekcja właściwej informacji.
   Wspomaganie dla informacji sumarycznych, wyliczalnych oraz o większym
    stopniu abstrakcji.
   Wspomaganie dla wykrywania niezidentyfikowanych związków w danych
    (eksploracja danych).

Zasady konstrukcji mediatorów nie są jasne. W większości przypadków mediator musi
być zaprojektowany ad hoc, pisany techniką niskiego poziomu i przypisany do
konkretnej aplikacji (nie uniwersalny).
Perspektywy
                          Perspektywy
                                                            view, database view
Perspektywa (view) jest to odwzorowanie schematu lokalnego w inny
(zmodyfikowany) schemat. Temu odwzorowaniu towarzyszy
odwzorowanie danych rzeczywistych lokalnej bazy danych na dane
wirtualne lub dane zmaterializowane (wyliczone). Przykładem są
perspektywy w SQL. Podstawowe problemy:
  W przypadku istotnych różnic pomiędzy schematami lokalnymi baz
   danych, odwzorowanie ich w zadany schemat może być złożone lub
   niemożliwe. Środki definiowania perspektyw np. w SQL są za mało
   uniwersalne.
  Aktualizacja perspektyw (view updating): problem nie jest rozwiązany w
   stopniu zadowalającym.
  Aplikacje (np. w C++) są często przywiązane do fizycznej postaci danych.
   Odwzorowanie ich w dane wirtualne powoduje, że większość aplikacji
   przestaje działać. Ograniczenie do zapytań (np. w SQL) silnie redukuje
   rodzaj aplikacji, które mogą działać na schemacie federacyjnym.
  Wydajność (performance) aplikacji.
        Perspektywa jak schemat zewnętrzny
W szerokim znaczeniu:
Perspektywą nazywa się odwzorowanie globalnego schematu bazy danych
(określającego zapamiętane zasoby danych) na schemat “zewnętrzny”,
przystosowany do potrzeb i przyzwyczajeń konkretnego użytkownika.

  Architektura       Użytkownik 1     Użytkownik 2      Użytkownik 3
  ANSI/SPARC:

                                                                        Schematy
                                                                        “zewnętrzne”
                     Perspektywa 1    Perspektywa 2     Perspektywa 3


                                                                        Projektant BD
       W tym sensie                  Schemat globalny
                                                                        Administrator BD
   pojęcie perspektywy
funkcjonuje w literaturze z
  zakresu modeli danych,             Poziom fizyczny                    Administrator BD
 analizy i projektowania.              bazy danych
           Perspektywa jako odwzorowanie
W węższym znaczeniu:
Perspektywą określa się nazwane odwzorowanie danych zapamiętanych w
bazie danych na dane “wirtualne”, t.j. pochodne lub wyliczalne.
  Matematycznie, perspektywa jest dowolną funkcją określoną na danych.
  Ten punkt widzenia nie jest jednak dostatecznie precyzyjny, gdyż nie uwzględnia
  mechanizmów nazywania (naming), wiązania (binding) i zakresu (scoping), które są
  kluczowe, szczególnie w przypadku obiektowości z hierarchią klas, tożsamością
  obiektów, hermetyzacją i innymi pojęciami.
  Bardziej precyzyjny punkt widzenia:
  Perspektywa jest procedurą funkcyjną, która (najczęściej, ale niekoniecznie)
  zwraca wynik będący daną typu masowego (zbiór, wielozbiór, sekwencję). Taki
  wynik powinien być wyposażony w dodatkowe nazwy (np. nazwy atrybutów
  wirtualnych obiektów zwracanych przez perspektywę).
  Perspektywy znane z SQL mieszczą się w tej definicji. Są to uproszczone procedury
  funkcyjne, których ciało można sprowadzić do pojedynczego zdania:
                 return <zapytanie SQL>
                   Po co są perspektywy?
Istnieje wiele ważnych zastosowań perspektyw, które czynią z nich
bardzo gorący i aktualny temat.
   Uproszczenie modeli pojęciowych dla poszczególnych użytkowników.
   Uproszczenie zapytań poprzez “wyliczane” obiekty, atrybuty, związki.
   Dostosowanie się do punktu widzenia i terminologii dziedziny zastosowań
   Ograniczenie dostępu do obiektów, ochrona prywatności.
   Ograniczenie dostępu w systemach rozproszonych federacyjnych
    baz danych.
   Logiczna niezależność obiektów i aplikacji działający na obiektach.
   Współdziałanie systemów heterogenicznych (wspólny schemat).
   Przystosowanie systemów spadkowych (legacy) do nowszych
    technologii i wymagań.
   Hurtownie danych: analiza informacji gromadzonych z różnych źródeł.
Jak są widziane perspektywy w relacyjnych BD?

 Perspektywę wyznacza zapytanie, np. w SQL, plus drugorzędne środki
 syntaktyczne i semantyczne, takie jak zmiana nazw kolumn wirtualnych tablic.
 Po ewaluacji perspektywa zwraca tablicę, koncepcyjnie taka samą jak
 zapamiętane tablice.
 Popularną i efektywną techniką przetwarzania perspektyw jest nie ich ewaluacja
 (materializacja), lecz modyfikacja zapytań, traktująca perspektywę jako makro-
 definicję, oraz łączna optymalizacja tekstu zapytania z rozwiniętym tekstem
 definicji perspektywy.
 Aktualizacja perspektyw jest ograniczona do pionowego/poziomego obcięcia
 zapamiętanych tablic. Nie występują i nie są dyskutowane środki sterowania
 intencją aktualizacji perspektywy.
 Aktualizacja perspektyw odbywa się w tym samym języku, co ich definicja
 (SQL); nie jest rozważana (chociaż być może osiągalna) aktualizacja perspektyw
 z języków niższego poziomu (np. z C).
Perspektywy w relacyjnych bazach danych
Perspektywę określa pewne zapytanie, np. SQL.
Zdanie definiujące perspektywę określa nazwy atrybutów “wirtualnej tabeli”.
Zapamiętana tabela:
  Pracownicy( Id_pracownika, Imię, Nazwisko, Stanowisko, Kierownik,
           Data_zatrudnienia, Zarobki, Premia, Id_działu )


Definicja perspektywy:
  CREATE VIEW Urzędnicy( Id_pracownika, Imię, Nazwisko, Zarobki )
  AS
  SELECT Id_pracownika, Imię, Nazwisko, Zarobki FROM Pracownicy
  WHERE Stanowisko = „urzędnik‟;

Użycie perspektywy:      (Zarobki urzędnika o nazwisku Nowak: )

  SELECT Zarobki FROM Urzędnicy                          Perspektywy wolno użyć w
  WHERE Nazwisko = „Nowak‟                               zdaniach SQL (prawie) na
                                                         takich samych zasadach jak
                                                         zapamiętanej tabeli.
Relacyjna baza danych z perspektywami

Użytkownik lub                     SQL
program aplikacyjny




Dane wirtualne                          Perspektywa     Perspektywa
                                            V1              V2




Dane rzeczywiste
   (logiczne)         Tablica BD   Tablica BD    Tablica BD    Tablica BD
                          B1           B2            B3            B4




Dane zapamiętane
   (fizyczne)
         Przykład relacyjnej bazy danych

DOSTAWCA                                        DC
DNR NAZW       STATUS MIASTO                    DNR CNR ILOŚĆ

 D1   Abacki       20   Lublin                   D1   C1   300
 D2   Bober        10   Poznań                   D1   C2   200
 D3   Czerny       30   Poznań                   D1   C3   400
 D4   Dąbek        20   Lublin                   D1   C4   200
 D5   Erbel        30   Radom                    D1   C5   100
                                                 D1   C6   100
                                                 D2   C1   300
CZĘŚĆ                                            D2   C2   400
                                                 D3   C2   200
CNR NAZWAC        KOLOR       WAGA MIASTO        D4   C2   200
                                                 D4   C4   300
 C1   Nakrętka    Czarwony       12   Lublin     D4   C5   400
 C2   Wkręt       Zielony        17   Poznań
 C3   Podkładka   Niebieski      17   Rzeszów
 C4   Nit         Czerwony       14   Lublin
 C5   Nit         Niebieski      12   Poznań
 C6   Tulejka     Czerwony       19   Lublin
    Przykład bardziej złożonej perspektywy
Perspektywa OcenaDostawcy podaje numer dostawcy i sumę dostarczanych przez
niego części.
 CREATE VIEW OcenaDostawcy( DNR, suma ) AS
       SELECT DNR, SUM( ILOŚĆ ) FROM DC
       GROUP BY DNR;

Perspektywa DobryDostawca ustala DNR, nazwisko, status i sumę dostarczanych
części dla tych dostawców, którzy dostarczają ich ponad 600:
 CREATE VIEW DobryDostawca( DNR, nazwisko, status, suma ) AS
       SELECT V.DNR, D.NAZW, D.STATUS, V.SUMA
       FROM DOSTAWCA AS D, OcenaDostawcy AS V
       WHERE V.DNR = D.DNR AND V.SUMA > 600;

              Rezultat:                         DobryDostawca
              Wirtualna tabela o postaci:       DNR nazwisko status suma

                                                  D1 Abacki      20 1300
 DROP VIEW DobryDostawca;                         D2 Bober       10 700
                                                  D4 Dąbek       20 900
 - usunięcie perspektywy z bazy danych.
              Perspektywy wirtualne

 Perspektywa istnieje wyłącznie w postaci definicji (np.
  zapytania, procedury funkc.).
 Wyliczenie (materializacja) następuje w momencie użycia
  perspektywy.
 Wynik jest “konsumowany” i następnie kasowany (tak jak
  wynik procedury funkcyjnej) .
 Zalety: nie ma dublowania danych, problemów aktualizacji
  wyliczonych danych, problemów z przetwarzaniem transakcji.
 Wada: czas ewaluacji perspektyw+czas ewaluacji zapytań
  używających perspektyw - bez optymalizacji jest bardzo
  często nieakceptowalny.
        Perspektywy zmaterializowane
 Perspektywa jest wyliczona “na zapas”, jej wynik jest
  przechowywany w bazie danych na normalnych
  zasadach. Aktualizacja danych stanowiących podstawę
  wyliczenia pociąga za sobą aktualizację
  zmaterializowanej perspektywy (lub jej skasowanie i
  ewentualnie, ponowne wyliczenie).
 Tego rodzaju perspektywy określa się także jako “zdjęcie
  migawkowe” (snapshot).
 Zalety: szybki dostęp, łatwa implementacja.
 Wady: dodatkowe zapotrzebowanie na pamięć, dodatkowy
  koszt aktualizacji zmaterializowanych perspektyw (często
  prowadzący do problemów koncepcyjnych i realizacyjnych),
  dodatkowe wąskie gardło dla transakcji.
       Zasada przezroczystości perspektyw
                                                              view transparency
Z punkty widzenia użytkownika dowolne operacje na perspektywach nie
powinny niczym różnić się od podobnych operacji na zapamiętanych danych.
   Np. jeżeli w federacyjnej bazie danych administrator udostępnia tylko część
   danych poprzez perspektywę, wówczas programista końcowy nie powinien
   być zmuszany do modyfikacji programów działających na zapamiętanych
   danych z tego powodu, że mają one teraz działać na perspektywach.
   Warunek przezroczystości perspektyw jest trudny, gdyż:
   Dla pewnych odwzorowań danych zapamiętanych w wirtualne przyjęte
    środki definicji perspektyw (np. SQL) mogą okazać się
    niewystarczające (schematic discrepancies).
   Problem aktualizacji perspektyw pozostaje nierozwiązany.
   Pewne dane mogą być manipulowane wyłącznie przez przypisane im
    interfejsy, a nie przez języki zapytań.
   Problemy z wydajnością mogą unicestwić rozwiązania trzech
    poprzednich problemów.
                 Aktualizacja perspektyw
Najpoważniejszym, nierozwiązanym problemem jest aktualizacja perspektyw.
Aktualizacja „wirtualnych” danych jest oczywiście niemożliwa, wobec czego należy
zamienić tę aktualizację na aktualizację zapamiętanych danych.
               Aktualizacja
                                                     Dane wirtualne



                              Perspektyw
                              a

                                                     Dane zapamiętane
                              Baza danych


Na ogół odwzorowanie danych wirtualnych w dane zapamiętane nie jest
jednoznaczne. Odwzorowanie aktualizacji danych wirtualnych w aktualizacje
danych zapamiętanych można zrobić na wiele sposobów. Czasami takie
odwzorowanie odwrotne w ogóle nie istnieje.
     Przykład aktualizacji perspektyw (1)
 Dane rzeczywiste                                    Dane wirtualne

                Pracownik                            /MojeDziały
Dział zatrudnia
                Nazwisko                             Nazwa
Nazwa         *
                Zarobek                              ŚredniZarobek


 Podwyższ średni zarobek w dziale „Krasnale ogrodowe” o 500 zł:

 update MojeDziały set ŚredniZarobek = ŚredniZarobek + 500
 where Nazwa = „Krasnale ogrodowe‟;                               ?
Zlecenie jest błędne, gdyż:
Nie ma danej o nazwie ŚredniZarobek.
Nawet gdybyśmy chcieli je poprawnie wykonać na danych rzeczywistych, mamy
do wyboru nieskończenie wiele sposobów. Prawdopodobnie tylko jeden z nich
satysfakcjonowałby naszego szefa, który wydał takie polecenie.
       Przykład aktualizacji perspektyw (2)
   Dane rzeczywiste                                      Dane wirtualne

           zatrudnia Pracownik                           /MoiPracownicy
Dział               * Nazwisko
                 szef                                    Nazwisko
Nazwa
      0..1            Zarobek                            NazwiskoSzefa

 Przyjmujemy strategię implementacji perspektyw polegającą na tym, że po
 wyliczeniu perspektywy MoiPracownicy zwraca ona referencje do nazwiska
 pracownika i nazwiska jego szefa. Czy problem aktualizacji został rozwiązany?
 Pracownik Kowalski, pracujący dla Styki, ma mieć nowego szefa Nowaka.

   update MoiPracownicy set NazwiskoSzefa = „Nowak‟
   where Nazwisko = „Kowalski‟;                            ?
Tym razem aktualizację można wykonać, zaś nowym szefem Kowalskiego będzie
Nowak. Niestety, nasz system zmienił pewnemu pracownikowi nazwisko „Styka” na
nazwisko „Nowak”, a chodziło o zupełnie coś innego, mianowicie, o przeniesienie
Kowalskiego do innego działu. Intencja tego zlecenia została zniekształcona.
  Ograniczenia w aktualizacji perspektyw
System Oracle:
      W klauzuli SELECT nie ma słowa DISTINCT
      W klauzuli FROM jest tylko jedna nazwa tabeli lub tylko jedna nazwa -
      tabeli lub aktualizowalnej perspektywy
      Na liście SELECT (wynikowej) znajduja się tylko nazwy kolumn
      W klauzuli WHERE nie ma podzapytania
      W zapytaniu nie mogą występować klauzule GROUP BY i HAVING


   Ta lista powinna być uzupełniona o ważny warunek: mianowicie, wynikowa
   wirtualna tablica powinna posiadać pełny klucz główny (primary key) pewnej
   zapamiętanej tablicy. Warunek ten (Ch.Date) jest logiczną konsekwencją tego,
   że identyfikacja zapamiętanej krotki następuje wyłącznie na podstawie wartości
   klucza głównego. W istocie jednak, systemy relacyjne odeszły od filozofii
   “klucza głównego” na rzecz “wewnętrznego identyfikatora krotki”, w związku z
   czym ten warunek okazał się zbędny.
         Dodatkowe możliwości aktualizacji
                   perspektyw
 W Oracle można aktualizować perspektywy powstające w wyniku złączenia, ale
 tylko atrybuty relacji znajdujące się po stronie “klucza obcego”:

 CREATE VIEW MoiLudzie( IdPracownika, Nazwisko, IdDziału, NazwaDziału, Zarobek)
 AS
 SELECT p.Id_pracownika, p.Nazwisko, p.Id_działu, d.Nazwa, p.Zarobek
 FROM Pracownicy AS p, Działy AS d
 WHERE p.Id_działu = d.Id_działu AND p.Stanowisko = „programista‟;

Podwyższyć o 500 zarobki       UPDATE MoiLudzie
wszystkim programistom z       SET Zarobek = Zarobek + 500               OK.
działu Krasnali ogrodowych:    WHERE NazwaDziału = „Krasnale ogrodowe‟


                               UPDATE MoiLudzie
Przenieść programistę Nowaka
                               SET NazwaDziału = „Lalki Barbie‟          Źle!
do działu Lalek Barbie:
                               WHERE Nazwisko = „Nowak‟
     Perspektywy są trudnym problemem
 Perspektywy są problemem, który doczekał się efektywnych
  rozwiązań w relacyjnych bazach danych.
 Podstawowy problem - aktualizacja wirtualnych danych - nie
  został rozwiązany w stopniu zadowalającym.
 Środki definicji perspektyw w relacyjnych bazach danych są
  ograniczone.
 Implementacje perspektyw nie zakładają sterowania intencją
  aktualizacji. Powoduje to, że wszelkie zapowiedzi opanowania
  poprzez perspektywy problemów takich jak współdziałanie
  (interoperability), przenaszalność (portability), ewolucja
  schematu (schema evolution), itp., są pobożnym życzeniem.
  Dotyczy to szczególnie kolejnych prac na temat obiektowych
  perspektyw relacyjnych baz danych.
 W powszechnej opinii, problem aktualizacji wirtualnych perspektyw
  jest uważany za bardzo trudny.
 Rośnie liczba prac nt. zmaterializowanych perspektyw, gdzie
       Klasyfikacja złożoności perspektyw
 Proste perspektywy, np. definiowane poprzez operatory selekcji i projekcji
  w relacyjnych BD. Mała przydatność dla federacyjnych baz danych.
 Perspektywy bardziej złożone, np. wymagające złączeń i grupowania, ale
  wyrażalne w SQL i OQL. Problemy z aktualizacją perspektyw i
  wydajnością.
 Perspektywy umożliwiające zmianę reprezentacji danych.
 Perspektywy uwzględniające niezgodności schematów, np. zamieniające
  atrybut Zawód z wartościami “piekarz”, “stolarz” itd. na wirtualne tabele
  Piekarz, Stolarz, itd. Wymagają dostępu do metabazy i mechanizmu
  refleksji (reflection).
 Perspektywy uwzględniające niezgodności semantyczne pomiędzy
   danymi. Często nie ma możliwości odzyskania informacji, która
   pozwoliłaby usunąć te niezgodności. Konieczne jest wtedy zrezygnowanie
   z pełnej przezroczystości.
Pozostałe kryteria klasyfikacyjne: generyczność, moc, stopień uwzględnienia pojęć
 Perspektywy z (trwałym) stanem, o pełnej mocy algorytmicznej.
modelu obiektowego, perspektywy rekurencyjne, perspektywy z parametrami,
możliwości aktualizacji perspektyw, możliwości optymalizacji, itd.
  Wydajność?
       Kryteria aktualizowalności perspektyw
   Brak nadmiarowej akualizacji. Jeżeli użytkownik aktualizuje pewien element perspektywy,
    nie powinien bezwiednie powodować aktualizacji innego jej elementu.

   Brak niedostatecznej/błędnej aktualizacji - wynik aktualizacji nie powinien odbiegać od
    intencji użytkownika. Np. użytkownik aktualizuje zarobek netto o 100 zł, tymczasem okazuje
    się, ze faktyczna aktualizacja wyniosła 91,50 zł.

   Brak efektów ubocznych aktualizacji. Np. takim efektem jest zniknięcie krotki z
    perspektywy BiednyPracownik (Zarobek < 500) po zaktualizowaniu tego zarobku.

   Brak spontanicznej aktualizacji bazy danych poza jej fragmentem widocznym poprzez
    perspektywę.

   Zdeterminowany translator aktualizacji perspektywy - dla każdego stanu bazy danych
    powinien działać tak samo, mimo niejednoznaczności odwzorowania aktualizacji
    perspektywy w aktualizację zapamiętanych danych.
Podane kryteria są spekulatywnym stereotypem i dotyczą sytuacji, kiedy translacja
aktualizacji perspektyw jest dokonywana w pewien automagiczny sposób.
Przestają mieć sens, jeżeli pełna kontrola nad aktualizacją perspektyw jest w rękach
definiującego perspektywę.
        Perspektywy z opcją sprawdzania
CREATE VIEW MałoZarabiający( Nazwisko, Zarobek) AS
SELECT Nazwisko, Zarobek FROM Pracownicy
WHERE Zarobek < 500
WITH CHECK OPTION;

Końcowa klauzula oznacza brak efektów ubocznych w postaci “znikania” krotki po
aktualizacji perspektywy.


 UPDATE MałoZarabiający             Taka aktualizacja spowoduje, że Marucha
 SET Zarobek = Zarobek + 500        zostanie usuniety z perspektywy (ale
 WHERE Nazwisko = „Marucha‟         oczywiście, nie z bazy danych)


CHECK OPTION oznacza, że ta aktualizacja zostanie odrzucona.
 Aktualizacja perspektyw w relacyjnych BD
 Duża liczba artykułów, głównie teoretycznych, ale (poza opisanymi
  praktycznymi rozwiązaniami) rezultaty tego nurtu są gorzej niż
  mizerne.
   • Artykuły zakładają jakiś "automagiczny" sposób aktualizacji
     perspektyw, bez sterowania intencją aktualizacji.
   • Środki formalne modelu relacyjnego (algebra relacji i inne) są
     nieprzystosowane do operacji imperatywnych takich jak aktualizacja.
       • Model relacyjny nie zaoferował dostatecznie uniwersalnego formalizmu do
         opisu konstrukcji imperatywnych, procedur, metod, itd.
   • W ten sposób zmarnowano masę czasu, wysiłku i papieru.
       • Przede wszystkim, zmarnowano czas czytelników.
 Prosty pomysł polega na przyjęciu założenia, że sterowanie
  intencją aktualizacji perspektywy powinno być:
   • składową definicji perspektywy,
   • znajdować się w rękach definiującego perspektywę,
   • zakładać imperatywny język (programowania) jako środek określania
     tej intencji.
                     Perspektywy ze stanem
                                                  capacity augmenting views, stateful views
 Klasyczne perspektywy udostępniają (w inny sposób) informacje, która już są
 zapamiętane w bazie danych. Często takie ograniczenie jest nieakceptowalne.
         Lokalna BD zawiera atrybut “stanowisko”, którego wartością są numery 11,
Przykład 45, 77, itd., gdzie 11 oznacza projektant, 45 oznacza analityk, 77 oznacza
   1:    sprzątaczka, itd. Federacja wymaga pełnych nazw zawodów. Potrzebna jest
         dodatkowa funkcja, która zamieni numery na stringi. Definicja perspektywy
         musi więc zawierać definicję trwałej tabeli z numerami i stringami.

           Dla celów kontroli utworzona jest perspektywa w postaci tabeli
Przykład
   2:       WynikiKontroli( NrUrządzenia, NazwaUrządzenia, OcenaKontrolera )
           NrUrządzenia i NazwaUrządzenia pochodzą z lokalnej BD. Natomiast
           OcenaKontrolera jest atrybutem, którego w lokalnej BD nie ma. Jest on
           własnością globalnej aplikacji, gdzie kontroler wpisuje swoją ocenę. Jest to
           zapamiętany atrybut, wprowadzony na potrzeby tej perspektywy.
  Perspektywy ze stanem (oraz autonomia lokalnych BD) oznaczają konieczność
  wprowadzenia na poziomie federacji specjalnej BD przechowującej dane niezbędne
  do definicji perspektywy. Komplikuje to architekturę federacyjnej bazy danych.
  Przetwarzanie perspektyw w zapytaniach
Obowiązują dwie strategie:
    Materializacja. Perspektywa jest całkowicie liczona w momencie, kiedy sterowanie
    programu/zapytania osiągnie punkt, w którym wynik tej perspektywy staje się niezbędny
    dla dalszego przetwarzania. Każde odwołanie się do perspektywy powoduje jej ponowne
    wyliczenie (dla uniknięcia niespójności związanych z ewentualną aktualizacją BD). Ta
    strategia może być optymalizowana poprzez zmaterializowane perspektywy.


    Modyfikacja zapytań (query modyfication). Tekst zapytania, w którym występuje
    odwołanie do perspektywy, jest scalany z tekstem definicji perspektywy. Następnie takie
    rozwinięte zapytanie jest wspólnie optymalizowane na normalnych zasadach. W tej
    strategii definicja perspektywy jest traktowana jako makro.
    Ponieważ wcześniejszy SQL nie dopuszczał klauzuli SELECT wewnątrz klauzuli FROM,
    kwestia banalnego tekstowego zastępowania przybrała cudaczne formy, owocując w
    super-naukowe “algorytmy” :-) (Stonebraker et al). W SQL-92 tę wadę usunięto.

W różnych sytuacjach pierwsza lub druga strategia może być bardziej optymalna, ale
najczęściej strategia modyfikacji zapytań jest bardziej skuteczna. Z tego powodu jest
ona standardem we wszystkich relacyjnych SZBD.
Przykład modyfikacji i optymalizacji zapytania
                 CREATE VIEW Urzędnicy( Id_pracownika, Imię, Nazwisko, Zarobki ) AS
  Definicja
                 SELECT Id_pracownika, Imię, Nazwisko, Zarobki FROM Pracownicy
perspektywy:
                 WHERE Stanowisko = „urzędnik‟;

   Użycie        SELECT Zarobki FROM Urzędnicy
perspektywy:     WHERE Nazwisko = „Nowak‟

                 SELECT Zarobki FROM
Po tekstowej
                   (SELECT Id_pracownika, Imię, Nazwisko, Zarobki FROM Pracownicy
modyfikacji
                   WHERE Stanowisko = „urzędnik‟)
 zapytania:
                 WHERE Nazwisko = „Nowak‟

                 SELECT Zarobki FROM
  Usunięcie
                   (SELECT Nazwisko, Zarobki FROM Pracownicy
  zbędnych
                   WHERE Stanowisko = „urzędnik‟)
 astrybutów:
                 WHERE Nazwisko = „Nowak‟

 Ostateczna      SELECT Zarobki FROM Pracownicy
optymalizacja:     WHERE Stanowisko = „urzędnik‟ AND Nazwisko = „Nowak‟
  Perspektywy łączące dane zapamiętane i
                wirtualne
Dla integracji systemów spadkowych lub sfederowanych potrzebne są perspektywy,
które łączą w jedną kolekcję zarówno dane wirtualne (odwzorowanie danych ze
starszych systemów) jak i dane rzeczywiste (pochodzące z nowszych systemów).

Stary system:      StaryStudent (Id, Nazwisko, RokStudiów, ŚredniaOcena )

Nowy system:       NowyStudent (Id, Nazwisko, NrIndeksu )
                                        Pewne atrybuty zniknęły, pojawił się nowy.

Tego rodzaju sytuacje można sprowadzić do sumy dwóch perspektyw: jednej
działająca na starych danych i drugiej działającej na starych i nowych:
CREATE VIEW StaryNowyStudent( Id, Nazwisko, NrIndeksu) AS
SELECT Id, Nazwisko, NULL FROM StaryStudent                           Pozostają
                                                                   problemy spójnej
CREATE VIEW Student( Id, Nazwisko, NrIndeksu) AS                   aktualizacji oraz
SELECT * FROM StaryNowyStudent                                       wydajności.
UNION
SELECT * FROM NowyStudent
Aktualizacja zmaterializowanych perspektyw
Główny problem w aktualizacji zmaterializowanych perspektyw polega na tym, jak
uniknąć ponownego generowania całej zmaterializowanej perspektywy po
aktualizacji bazy danych. Istnieją dwie strategie:
  Określenie kryteriów do stwierdzenia, że dana aktualizacja nie wpływa na
  wyliczoną zmaterializowaną perspektywę.
  Np. najprostsze kryterium może być następujące:
  Jeżeli zlecenie aktualizacyjne używa nazw danych n1, n2,..., definicja perspektywy używa
  nazw m1, m2,... przy czym zbiory {n1, n2,...} i {m1, m2,... } są rozłączne, wówczas
  zlecenie aktualizacyjne nie wpływa na wynik materializacji perspektywy.

  Ustalenie związku pomiędzy fragmentami bazy danych i fragmentami
  zmaterializowanej perspektywy w taki sposób, aby dany fragment
  zmaterializowanej perspektywy był funkcją danego fragmentu bazy danych.
  W tym przypadku możliwa jest aktualizacja przyrostowa (incremental), tj. po aktualizacji
  bazy danych modyfikowany/przeliczany jest tylko fragment perspektywy. Metoda zależy
  od formy definicji perspektywy. Możliwe jest włączenie aktywnych reguł wyzwalających
  przeliczenie fragmentów zmaterializowanej perspektywy.
  Mało prac zajmuje się odwzorowaniem aktualizacji perspektywy na aktualizację
  oryginalnych danych, ale problem bardzo przypomina techniki replikacji.
             Perspektywy obiektowe (1)
 Wskutek “wtłoczenia” w problem perspektyw ogromnej liczby pojęć
  obiektowych i innych, przy braku spójnego i jednorodnego modelu
  formalnego, propozycje rozwiązania tego problemu są
  partykularne, nieregularne, niedostatecznie generalne, obciążone
  drugorzędnymi szczegółami, sporym bagażem syntaktycznym i
  mętnymi dywagacjami semantycznymi.

 Podstawowa metoda przetwarzania perspektyw, czyli modyfikacja
  zapytań, została zapomniana. O optymalizacji zapytań włączającej
  perspektywy w ogóle się nie wspomina.

 Nawet jeżeli są propozycje aktualizacji perspektyw, z reguły są one
  ograniczone do takich ich rodzajów, które “zwracają” zapamiętane
  obiekty w niezmienionej postaci. W tym względzie sytuacja jest
  gorsza niż w modelu relacyjnym.
             Perspektywy obiektowe (2)
 Nie występują środki sterowania intencją aktualizacji perspektywy.
  Nie występują perspektywy rekurencyjne i perspektywy z
  parametrami. Świat nie dojrzał...

 Problemem są niespójne i ograniczone podejścia do obiektowych
  języków zapytań. Funkcjonuje duża ilość fałszywych stereotypów, z
  których część pochodzi ze zbyt dosłownego przeniesienia do
  obiektowości paradygmatów modelu relacyjnego

 Brak zintegrowania obiektowych języków zapytań z konstrukcjami
  imperatywnymi, niepotrzebny nacisk (patrz ODMG), aby tego
  rodzaju konstrukcje “oddelegować” do obiektowych języków
  programowania takich jak C++, Java i Smalltalk (gdzie problem
  aktualizacji perspektyw staje się niewyrażalny).
   Refleksja nt. obiektowych perspektyw...
Problem obiektowych perspektyw dla prostego przypadku jest banalny.
 Można przyjąć, że perspektywa wyznacza podzbiór obiektów pewnej
  klasy, zaś cała semantyka rzeczywistych obiektów jest przeniesiona do
  obiektów wirtualnych. To rozwiązanie można wzmocnić ograniczeniem
  dostępu do pewnych atrybutów (patrz rozwiązanie w O2 lub COCOON)
 Podejście to można zastosować w stosunku do aktualizacji perspektyw.
  Analogią są perspektywy w SQL z wykorzystaniem wyłącznie selekcji.
 Generalny problem perspektyw jest trudny, ponieważ brakuje
  uniwersalnego modelu obejmującego wszystkie najważniejsze aspekty
  obiektowości, włączając klasy, cechy proceduralne, metody, itd.
 Rozwiązanie problemu perspektyw dla bardziej ogólnego przypadku
  jest możliwe przy zastosowaniu podejścia stosowego, które
  zapewnia niezbędną ogólność, prostotę i unifikację pojęć.
 Jak dotąd nikt nie wynalazł lepszego podejścia. Produkuje się nowe
  kulawe podejścia (np. w kontekście XML) dające złudzenie, że problem da
  się opanować przy pomocy prostszych środków.
     Podejścia do obiektowych perspektyw
Podejście Abiteboula i Bonnera, Rundensteinter et al (MultiView), Kifera, Kima i
Sagiv‟a, Scholl‟a et al (COOL/COCOON), LIVING IN A LATTICE, Eder‟a i inne.

Różnice pomiędzy tymi podejściami polegają na arbitralnym wyborze własności
perspektyw i ustaleniu dla nich konstrukcji składniowej. Konstrukcja ta obejmuje
szereg ortogonalnych cech pochodzących z dwóch wymienionych na początku
poglądów na pojęcia perspektywy oraz ich potencjalnych zastosowań (np.
ograniczenie dostępu, zintegrowanie z systemem klas, itd.)
Moje podejście jest różne od zaproponowanych. Polega na przyjęciu założenia, że:

     Perspektywa jest procedurą funkcyjną zdefiniowaną w języku zapytań,
              zwracającą kombinację referencji, nazw i wartości.

To początkowe założenie jest następnie nieco modyfikowane.
Tak rozumiana perspektywa korzysta z normalnych własności obiektowych struktur
danych, w szczególności, struktury modułów i klas, środków ograniczenia dostępu,
itd. Środki dodatkowe dla tak rozumianej perspektywy są ograniczone do minimum.
    Perspektywy jako procedury funkcyjne
Konieczne jest określenie:
 Gdzie taka procedura funkcyjna jest umieszczona w strukturze
   obiektowej? W zależności od tego, możemy mieć wirtualne obiekty,
   jeżeli procedura jest na czubku struktury obiektowej, lub wirtualne
   atrybuty, jeżeli procedura jest metodą zdefiniowaną wewnątrz klasy.
 Na jakim środowisku taka funkcja działa? Chodzi o reguły zakresu. Jak
   wynik takiej procedury ma być podłączony do istniejących lub nowych
   klas?
 Co taka procedura funkcyjna zwraca? Chodzi o ich dziedzinę
   semantyczną.
 W jaki sposób wynik takiej procedury (czyli wirtualne dane) jest
   udostępniony dla innych konstrukcji danego języka zapytań lub
   programowania?
 Czy taka procedura funkcyjna może mieć parametry? Jakie to ma
   konsekwencje?
 Czy taka procedura może być rekurencyjna? Jakie to ma konsekwencje?
 Czy taka procedura może mieć imperatywne ciało i lokalne środowisko
   danych?
Przetwarzanie zapytań
 Przetwarzanie zapytań w rozproszonych BD
Przetwarzanie zapytań powinno minimalizować zarówno obciążenie linii
transmisyjnych jak i pracochłonność przetwarzania po stronie klienta
(globalnej aplikacji) jak i po stronie serwerów.
   Przetwarzanie wyłącznie po stronie klienta (gruby klient): ogromne
    obciążenie linii transmisyjnych.
   Przetwarzanie wyłącznie po stronie serwerów (chudy klient): może
    powstać wąskie gardło wskutek tego, że jednocześnie wielu
    klientów będzie żądać usługi od jednego serwera.
   Generalna zasada: "wyślij zapytanie do danych, a nie dane do
    zapytanie" nie dla wszystkich przypadków jest słuszna i rodzi
    problemy koncepcyjne.
   Przetwarzanie zapytań odbywa się poprzez:
     • dekompozycję zapytania na operacje wysyłane do różnych
        węzłów,
     • porządkowanie tych operacji,
     • zbieranie ich rezultatów oraz ich przetwarzanie przez klienta w
Strategie optymalizacji zapytań w rozprosz.
                    BD
 Przetwarzanie wyłącznie po stronie klienta. Pobiera on wszystkie dane
  potrzebne do realizacji zapytania do swojego obszaru => duży czas i koszt
  transmisji danych, małe problemy koncepcyjne.
 "Statyczna" (jednoczesna) dekompozycja zapytania na podzapytania,
  wysłanie ich do lokalnych miejsc, przesłanie rezultatów podzapytań do
  klienta, który łączy tych rezultaty w globalny rezultat. Skuteczna dla podziału
  poziomego danych i zapytań ograniczonych do selekcji/projekcji,
  nieskuteczna dla zapytań złożonych.
 "Dynamiczna" dekompozycja: generacja podzapytania do miejsca 1 i
  przesłanie wyniku 1 do centralnego miejsca; generacja podzapytania do
  miejsca 2 i przesłanie wyniku 2 do centralnego miejsca, itd. Brak
  równoległości działania serwerów, trudności koncepcyjne.
 Hybrydowa dekompozycja - połączenie dekompozycji statycznej i
  dynamicznej.
 Hybrydowa dekompozycja z przesłaniem danych do serwera. Klient nie
  tylko dokonuje wysłania podzapytania do serwera, ale również przesyła do
  niego część danych, które otrzymał od innych serwerów (aby umożliwić
  serwerowi skuteczniejszą optymalizację podzapytania).
   Indeksowanie rozproszonych zasobów
 Szczególnie istotne w przypadku technologii P2P, ale nie
  tylko.
 Indeks centralny, adresujący całe zasoby rozproszonej sieci.
  Przykładem wykorzystania indeksów centralnych jest Napster
  oraz liczne motorki wyszukiwawcze takie jak Google lub
  AltaVista,
 Indeksy lokalne replikowane, trzymane przez klientów
  celem szybkiego zlokalizowania miejsc z interesującymi
  danymi. W tym przypadku duża część optymalizacji zapytania
  może być wykonana przez klienta zanim on wyśle zlecenia do
  odległych serwerów.
 Problem z indeksami centralnymi - zależność całości
  rozproszonej bazy danych od jednego miejsca.
 Problemy z indeksami lokalnymi replikowanymi:
   • kłopotliwa aktualizacja indeksów
Statyczny schemat przetwarzania zapytań (1)
 1. Klient realizuje zapytanie Z odwołujące się do danych na serwerach S1,
 S2,..., Sk
 2. Klient dokonuje odwzorowania zapytania Z na zapytania Z1, Z2, ... , Zk
 adresowane do serwerów S1, S2,..., Sk. Odwzorowanie wymaga
 znajomości lokalnych schematów danych.
 3. Zapytania Z1,Z2,...,Zk są konstruowane z Z w taki sposób, aby wyniki
 tych zapytań W1, W2,...,Wk uzyskane z poszczególnych serwerów dały
 możliwość utworzenia globalnego wyniku W.
 4. Zapytania Z1,Z2,...,Zk są kierowane do serwerów S1, S2,..., Sk, gdzie są
 wykonywane.
 5. Serwery zwracają do klienta wyniki W1, W2,...,Wk zapytań Z1,Z2,...,Zk
 6. Klient dokonuje scalenia wyników W1, W2,...,Wk w globalny wynik w.
 Statyczny schemat przetwarzania zapytań (2)

         Klient                                   Serwer S1
                                     Z1      W1
                                     Z2           Serwer S2
         Dekompozycja zapytania Z
                                             W2
                  Scalenie wyników                   ...
                                     Zk

             Wynik W zapytania Z                  Serwer Sk
                                             Wk

 Statyczny schemat ma przede wszystkim zastosowanie w przypadku
  poziomej fragmentacji danych, np. rozbicia obiektów Pracownik na
  wiele podzbiorów o takiej samej budowie przechowywanych na
  poszczególnych serwerach.
 W tym przypadku dekompozycja zapytania oznacza po prostu jego
  skopiowanie: Z = Z1 = Z2 = ... = Zk
 Scalenie wyników polega na sumie mnogościowej wyników
  cząstkowych.
Dynamiczny schemat przetwarzania zapytań
1. Klient realizuje zapytanie Z odwołujące się do danych na serwerach S1, S2,..., Sk
2. Klient dokonuje odwzorowania zapytania Z na podzapytanie Z1 adresowane do serwera S1
(na podstawie schematu S1). Z1jest konstruowane z Z w taki sposób, aby jego wynik W1
uzyskany z S1 wystarczył do realizacji zapytania Z.
3. Z1jest kierowane do serwera S1, gdzie jest wykonywane. Serwer S1 zwraca do klienta
wynik W1 podzapytania Z1.
4. Na podstawie znajomości W1 klient konstruuje z Z kolejne podzapytanie Z2 kierowane do
serwera S2. Może do tego serwera skierować pewien fragment W1, nazwijmy go F1;
.... proces jest powtarzany dla wszystkich serwerów, aż do uzyskania rezultatu.
         Klient         Z  Z1                      Z1
                                                    W1                 Serwer S1

                  (Z, W1)  Z2, F1               Z2, F1
                                                    W2                 Serwer S2
           (Z, W1, W2)  Z3, F2
                                                 Z3, F2

                   Scalenie wyników                       W3           Serwer S3
           Przykład: technika pół-złączeń (1)                    semijoin

Serwer 1                                      Serwer 2
DOSTAWCA                                      DC
DNR NAZW      STATUS MIASTO                   DNR CNR ILOŚĆ

  D1 Abacki       20 Lublin                     D1   C4    200
  D2 Bober        10 Poznań                     D1   C5    100
  D5 Erbel        30 Radom                      D2   C1    300
                                                D2   C2    400
                                                D3   C2    200
                                                D4   C2    200
                                                D4   C4    300
                                                D4   C5    400

   Klient ma dokonać złączenia relacji DOSTAWCA i relacji DC:

   select * from DOSTAWCA, DC
   where DOSTAWCA.DNR = DC.DNR
            Przykład: technika pół-złączeń (2)
W celu realizacji zapytania klient musi wykonać następujące czynności:
1. Sciagą dane z serwera 1 przy pomocy zapytania Z1:
   select * from DOSTAWCA
   Uzyska w ten sposób wynik W1.
       W1
        DNR NAZW        STATUS MIASTO

            D1 Abacki       20 Lublin
            D2 Bober        10 Poznań
            D5 Erbel        30 Radom
2. Tworzy pomocniczą tabelę poprzez projekcję W1 na DNR: tę tabelę nazywa F1.
       F1
       DNR
        D1
        D2
        D5
3. Wysyła tabelę F1 do serwera 2 żądając tymczasowego ulokowania jej w bazie
danych serwera 2; następnie wysyła tam zapytanie Z2:
   select * from DC, F1 where DC.DNR = F1.DNR
           Przykład: technika pół-złączeń (3)
 4. Uzyska w ten sposób wynik W2: Jest to tzw. pół-złączenie relacji DC,
                                  parametryzowane relacją DOSTAWCA.
           W2
           DNR CNR ILOŚĆ
            D1  C4    200
                                      Pół-złączenie relacji R1, parametryzowane relacją
            D1  C5    100             R2, powstaje poprzez złączenie R1 z R2, a
            D2  C1    300             następnie projekcję wyniku na atrybuty relacji R1
            D2  C2    400

 5. Przesyła wynik W2 - pół-złączenie - do klienta
 6. Klient dokonuje ostatecznego scalenia wyników - złączenia relacji W1 i W2.

           Wynik
           DNR     NAZW     STATUS   MIASTO CNR ILOŚĆ
            D1     Abacki       20   Lublin  C4    200
            D1     Abacki       20   Lublin  C5    100
            D2     Bober        10   Poznań  C1    300
            D2     Bober        10   Poznań  C2    400

W zależności od oceny kosztów przetwarzania i transmisji klient może zacząć od
ściągnięcia danych z serwera 2 i następnie dokonać pół-złączenia relacji DOSTAWCA.
Metody dostępu do baz danych
         sterowniki
                        Potrzeby ?
 Różne DBMS mogą realizować różne wersje SQL dla
  realizacji języków definicji danych (DDL) i manipulacji danymi
  (DML).
 Interfejsy bezpośredniego dostępu do tych DBMS, stworzone
  przez różnych producentów, też mogą się różnić.
 Wskutek tego konsekwentności zapytań SQL do różnych baz
  danych, różnych serwerów SQL mogą też się różnić. To
  znaczy, np., że dla bazy danych w środowisku „ORACLE”
  trzeba konstruować inne konsekwentności zapytań SQL niż
  dla tej samej bazy w środowisku „INFORMIX”.
 W celu usunięcia tej wady firma MICROSOFT w 1992r
  opracowała standard ODBC (Open Database Connectivity).
                      Co to jest ODBC ?
 Technologia ODBC wprowadza jedyny interfejs dostępu do różnych typów
  baz danych.
 Język SQL jest wykorzystywany jako główny uniwersalny dialekt
  wszystkich baz danych.
 Standard ODBC pozwala realizować technologię „Klient – Serwer”, która
  realizuje główne operacji przetwarzania danych na serwerze, a klient tylko
  otrzymuje rezultaty.
 Aplikacje nie są połączone z konkretnym interfejsem jakikolwiek DBMS, a
  realizują jedyny standard zapytań do menedżera ODBC – sterowników
  (ODBC-drivers).
 Menedżer ODBC podłącza potrzebny ODBC – sterownik, który jest
  stworzony przez producenta konkretnej DBMS.
 Dla podłączenia ODBC – sterownika trzeba stworzyć profile ODBC w
  trybie (Source ODBC…) panelu sterowania systemu operacyjnego.
 Teraz istnieją ponad 50 typów ODBC – sterowników dla różnych DBMS.
 Standard ODBS pozwala realizować zapytania SQL bezpośrednio z
  programów użytkownika. W tym celu można wykorzystywać dynamiczny
  SQL.
Architektura ODBC
  Application 1   Application 2    ...     Application N




                  The manager of
                   drivers ODBC




       Driver           Driver                  Driver
       ODBC             ODBC                    ODBC
      ACCESS           SYBASE        ...       ORACLE




Source of data    Source of data    Source of data
   ODBC              ODBC              ODBC
  ACCESS            SYBASE            ORACLE




                                   ...


                        Fig. 33
  Schemat współpracy różnych narzędzi w
architekturze „ Klient – Serwer” w sieci LAN
                                        Client
                                                            Client MS Windows
                                      application

                                     ODBC driver
Aplikacja na stancji                 manager

klienta realizuje zapytania        ODBC
                                                     text
                                                     ODBC          ODBC         Server 1
do baz danych przez ODBC         driver local
                                     data
                                                     driver
                                                    DBMS-2
                                                                   driver
                                                                  DBMS-1
Manager.                                                                         DBMS - 1
                                   File
                                                        Net Driver
Zapytania mogą być dla           System


lokalnej bazy danych lub do                                                      Net Driver

baz danych umieszczonych
na innych serwerach sieci     Local Disk
lokalnej.
                                      LocalNet                                      Server 2
Na rys. pokazano trasy
wszystkich zapytań.                                                                  DBMS - 2



                                                                                    Net Driver

                                                            Fig. 34
Główne wady technologii dostępu do baz danych
                przez ODBC
  Aplikacje są przystosowane do platformy MS Windows
  Wzrasta czas obróbki zapytań dzięki dodatkowej warstwie
   programówJest potrzebna uprzednia instalacja ODBC –
   sterownika, profile ODBC dla każdej stacji. Parametry tej
   instalacji jest statyczne i użytkownik nie może ich zmienić.
           Uniwersalne strategii dostępu
 Technologia ODBC firmy Microsoft zaopatrzy ogólny interfejs
  dostępu do baz danych, które są kompatybilne przez SQL.
 Każda baza danych mająca interfejs ODBC zawiera
  sterownik (driver) , który realizuje bezpośrednio ten interfejs.
 Interfejs zawiera bibliotekę funkcji specjalnych napisanych w
  języku C++ .
 Zastosowanie tej biblioteki może być wadą przy realizacji
  dostępu aplikacji stworzonych w innym środowisku języków
  oprogramowania.
 Żeby usuwać te wady różne producenci stwarzają specjalne
  komponenty obiektowe dostępu do baz danych.
Przykład komponentów firmy Microsoft
                            User Aplication




         DAO (RDO)                            ADO




                                       OLE DB




                     ODBC




                                 DB SQL

                                  Fig 35
Przykład komponentów firmy Microsoft – cd…
  Obiektowy model DAO (Data Access Objects) jest przeznaczony w
   środowiskach Microsoft Access oraz Visual C++. DAO zawiera obiekty
   baz danych (component DataBase), obiekty tabel(component TableDef),
   obiekty definicji kwerend (component QueryDef), obiekty rezultatów
   zapytań do bazy danych (component RecordSet) oraz inne obiekty. Model
   DAO jest przeznaczony przede wszystkim dla dostępu do baz danych
   Access. Ten model nie odpowiada wszystkim standardom oraz
   specyfikacjom SQL . Ten model teraz jest zamieniony nowym modelem
   RDO (Remote Data Obiekt). RDO wchodzi do Visual Basica, Visual
   FoxPro oraz do Microsoft SQL Servera.
  Firma Microsoft zaproponowała zbiór obiektów OLE DB( Object Linking
   and Embedding for DataBase), który pozwala aplikacjom wykorzystywać
   oraz sterować danymi w bazach danych przez swoje obiekty. Technologia
   OLE DB gwarantuje dostęp do jakikolwiek baz danych włącznie nie
   relacyjne modeli danych. Oprócz tego przez OLE DB można udostępnić
   do plikowych oraz pocztowych systemów, graficznych plików, innych
   obiektów stworzonych w różnych aplikacjach. Technologia OLE DB jest
   obiektowo - orientowana specyfikacja na podstawie C++ API.
Przykład komponentów firmy Microsoft – cd…
 
     Technologia ADO (Active Data Obiects) to jest rozwiązanie
     technologii ASP dostępu do baz danych, które jest
     realizowane we WWW serwerze IIS (Internet Information
     Server) firmy Microsoft. Technologia ADO zawiera wszystkie
     lepsze cechy technologii RDO oraz DAO i musi zamienić te
     ostanie technologii. Technologia ADO zawiera następne
     funkcje:
            Stworzenia niezależnych obiektów baz danych
            Wsparcie zapamiętanych procedur baz danych
            Stworzenia kursorów dostępu do danych
            Wsparcie mechanizmów transakcji.
  Głównymi zaletami technologii ADO są nie komplikowane
  wykorzystanie, prędkość, małe obciągi RAM oraz disku.
Przykład komponentów firmy Microsoft – cd…
  Model obiektowy ADO zawiera 6 głównych klasy obiektów:
        CONNECTION
        COMMAND
        PARAMETERS
        RECORDSET
        FIELDS
        ERRORS.
  Obiekt CONNECTION połączy związek pomiędzy aplikację oraz źródłem
   danych. Utworzenia takiego połączenia zawsze jest pierwszym etapem
   obsługi bazy. Ten obiekt pozwala także uruchomić instrukcje SQL. Dla
   zachowywania rezultatów instrukcji trzeba stworzyć obiekt klasy
   RECORDSET. Klasa CONNECTION zawiera następne metody:
  Open( ) , Close( ) – połączenie lub wyłączenia ze źródłem danych
  Execute( ) – uruchomienie instrukcji dla wyznaczonego połączenia
  BeginTrans( ), CommitTrans( ) oraz RollbackTrans( ) – sterowanie
   transakcjami dla danego połączenia.
Przykład komponentów firmy Microsoft – cd…
            Connect         Errors              Error
        Open()
        Execute( )
        BeginTrans()           Command
        CommitTrans( )
        RollbackTrans ( )   Execute ( )
                            CreateParametr ()


                               Parameters

                            Append ( )
                            Delete ( )
                            Item ()
           Recordset
                            Refresh ()
        BOF
        EOF
        RecordCount
        MoveFirst ( )           Parameter
        MoveLast ( )
        MoveNext ()
        MovePrevious ()
        Move()
        AddNew ()
                            Fields
        UpDate ()
        Delete ()
        Open()                              Fig 36
        Close()             Field
Przykład komponentów firmy Microsoft – cd…
  Obiekt COMMAND zawiera instrukcję SQL lub wywołanie
   zapamiętanej procedury. Ten obiekt może mieć kolekcję
   parametrów, które mogą być zadane przez obiekty klasy
   PARAMETER. Klasa COMMAND zawiera następne metody:
       Execute( ) – uruchomianie instrukcji dla danego połączenia
       CreateParameter( ) – tworzenie nowego parametru(obiektu klasy
        PARAMETER)
  Kolekcja PARAMETERS zawiera wszystkie parametry, które
   są wykorzystywane razem z danym obiektem COMMAND.
   Parametry te są przechowywane w obiektach klasy
   PARAMETER. Klasa PARAMETERS zawiera następne
   metody:
       Append(), Delete() – dodawanie (usuwanie) parametru dla danej
        kolekcji
       Item() – wywołanie wyznaczonego obiektu PARAMETR
       Refresh() – wywołanie informacji pro parametry właściciela
Przykład komponentów firmy Microsoft – cd…
  Obiekt RECORDSET pozwala na operowania danymi
   przechowywanymi w tabeli.
  Obiekt ten zawiera zbiór rekordów pobranych z tabeli.
   Pozwala on na odczytywanie danych przechowanych w
   tabeli, modyfikowanie ich oraz gromadzenie informacji, jakie
   mają być dodane do bazy.
  Aktualne analizowany rekord oraz jego położenie względem
   pozostałych rekordów zbioru określane przez kursor bazy
   danych.
  Kursor to jest obiekt zawierający rezultat polecenia do bazy
   danych.
  Przy stworzeniu obiektu RECORDSET wskaźnik rekordu
   bieżącego kursora odwzorowuje pierwszy rekord zbioru, a
   atrybuty BOF oraz EOF otrzymają wartości FALSE. Kiedy
   zbiór jest pusty atrybut RecordCount otrzyma wartość 0
   (zero), lecz BOF oraz EOF – wartości TRUE.
Przykład komponentów firmy Microsoft – cd…
   Klasa RECORDSET zawiera następne metody:
  MoveFirst(), MoveLast(), MoveNext(), MovePrevious() oraz Move() –
   przesuwają wskaźnik rekordu bieżącego. Obiektami RECORDSET są
   kursory, które mogą być sterowanymi tylko w jednym kierunku lub w
   dwóch kierunkach zbioru rekordów. W przypadku jednokierunkowego
   kursora można przechodzić jedynie do następnego rekordu zbioru, nie
   istnieje możliwości cofania się do poprzedniego wiersza lub
   przeskakiwania o kilka rekordów do przodu lub do tylu zbioru. Tutaj może
   być wykorzystywana tylko metoda MoveNext(). Dla wyznaczenia końca
   lub początku rekordów trzeba wykorzystać atrybuty BOF oraz EOF
   obiektu RECORDSET.
  AddNew(), Update() oraz Delete() – dodawanie nowych rekordów,
   aktualizacja oraz usuwanie istniejących rekordów, które jest związane z
   obiektem REKORDSET.
  Open(), oraz Close() – uruchomienie (Zamknięcie ) kursora, który
   reprezentuje rezultaty instrukcji, która jest poprzednio stworzona przez
   obiekt COMMAND. Metoda Open() odsyła na już stworzony obiekt
   CONNECT.
Przykład komponentów firmy Microsoft – cd…
  Każdy obiekt RECORDSET zawiera kolekcję FILDS, która są
   zbiorem obiektów klasy FIELD. Każdy obiekt FIELD
   reprezentuje jedną kolumnę tabeli danych. Na każdy obiekt
   FIELD w kolekcji FIELDS można odwalać przez nazwę lub
   liczbę numeryczną.
  Kolekcja ERRORS jest stworzona dla zachowywania
   informacji pro jakikolwiek błędy. Obiekt ERROR reprezentuje
   błąd wygenerowany przez źródło danych. Kolekcja ERRORS
   jest używana w sytuacji, gdy jedno wywołanie metody może
   wygenerować większą ilość błędów.
  Przy stworzeniu obiektu RECORDSET można wykorzystać
   dwa typy kursorów: jednokierunkowy lub dwukierunkowy.
   Podczas wywołania metody Open() obiektu RECORDSET
   domyślnie tworzony jest kursor jednokierunkowy. Kursor tego
   typu jest najbardziej efektywny, jednak oferuje ograniczone
   możliwości poszukiwania się po zbiorze rekordów .
Przykład komponentów firmy Microsoft – cd…
 Dwukierunkowe kursory zawierają następne typy:
  Statyczny. Wyniki wykonania zapytania są przechowywane
   w tabeli tymczasowej, której wierszy nie są modyfikowane w
   momencie, gdy kursor jest otwarty.
  Zbiór kluczy. Kursory tego typu zapisują w tymczasowej
   bazie danych klucze wszystkich wierszy zwróconych w
   wyniku wykonania polecenia. Dzięki przechowywaniu jedynie
   kluczy, wszelkie modyfikację rekordów wykonane w czasie
   gdy kursor jest otwarty, będą zauważane.
  Dynamiczny. W przypadku użycia kursora dynamicznego za
   każdym razem, gdy zażądamy nowego rekordu, polecenie
   określające zawartość zwracanych wyników jest ponownie
   wykonywane. Oznacza to, że wszelkie modyfikacje
   wprowadzane w tabeli bazy danych będą widoczne, a co
   więcej, dodanie nowego rekordu może mieć wpływ na
   zawartość wynikowego zbioru rekordów.
  Dostęp w Jawie przez JDBC - sterownik
 Java, jako nowoczesny język programowania, posiada m.in.
  możliwości związane z podłączeniem się i operowaniem na
  bazach danych.
 Jednak założeniem projektantów Javy było stworzenie języka,
  którego kod byłby przenośny między różnymi systemami
  operacyjnymi. Taką przenośność posiada Java w dziedzinie
  zastosowań aplikacji bazodanowych.
 Java także wykorzysta technologię ODBC. Została ona
  realizowana jako interfejs niezależny od architektury bazy
  danych i ma nazwę JDBC (ang. Java DataBase Connectivity).
 JDBC jest pomostem pomiędzy przestrzeniami bazy danych,
  mającą sterownik ODBC, i aplikacji, napisanej w języku Java.
  Interfejs ten operuje na poziomie SQL.
 Dzięki JDBC aplikacje bazodanowe napisane w Javie są
  niezależne od sprzętu oraz stosowanej bazy danych.
  Niezależność od systemu operacyjnego zapewnia sama
  Java.
                  JDBC - sterownik
 Sterownikiem JDBC, łączącym aplikację z konkretną bazą
  danych, nazywa się zestaw klas, które implementują interfejs
  ODBC. Zadaniem JDBC jest ukrycie przez programista
  wszelkich specyficznych własności bazy danych. Dzięki temu
  programista może skupić się wyłączne na swojej aplikacji, nie
  wdając się w szczegóły związane z obsługą używanej przez
  niego bazy danych.
 Aby umożliwić niezależność od platformy, JDBC udostępnia
  menedżera sterowników ODBC, który dynamiczne zarządza
  różnymi obiektami sterowników. Obiekty te będą
  wykorzystywać zapytania do bazy danych.
     JDBC - sterownik –kolejność czynności
Kolejność dostępu do bazy danych zawiera następne czyności:
1) Załadować do pamięci potrzebny sterownik JDBC. To można zdarzyć
   następnym sposobem:          Class.forName ("sun.
   jdbc.odbc.JdbcOdbcDriver")
 Argumentem metody forName() jest obiekt typu STRING. Jest on nazwą
   klasy sterownika wraz z nazwą pakietu, który trzeba załadować. Po
   załadowaniu sterownik staje się dostępnym dla aplikacji.
2) Dla połączenia z bazą danych wykorzystają konstrukcję :
                  DriverManager.getConnection(url,user,password)
 Pierwszy parametr w metodzie getConnection() to URL do bazy danych.
   Pozwala on na identyfikację bazy danych w taki sposób, że możliwe jest
   załadowanie do pamięci odpowiedniego sterownika ODBC i uzyskanie
   połączenia z bazą. Drugi i trzeci parametry oznaczają odpowiednio nazwę
   użytkownika bazy danych i hasło dostępu do niej. Jeżeli baza danych nie
   potrzebuje identyfikatora oraz hasła, drugi oraz trzeci parametry są
   nieobecne. Standartowa składnia URL–a jest następująca:
   jdbc:<subprotokół>:<subnazwa>.
 JDBC – to typ protokółu, subprotokół określa nazwę wykorzystanego
   sterownika (w tym wypadku – ODBC), subnazwa jest nazwą identyfikującą
   bazę danych, nazwa profilu ODBC. Przykład połączenia z bazą danych:
 Connection con;
 String url = "jdbc:odbc:biblio";
JDBC - sterownik –kolejność czynności cd…
3) Wykonać zapytanie SQL do bazy danych. Dla wykonania
   zapytania SQL do bazy danych, mamy do wyboru jeden z
   interfejsów: Statement, PreparedStatement lub
   CallableStatement. Wszystkie trzy służą zasadniczo
   jednemu: wykonaniu zapytania SQL-owego.
 Tworzenie obiektów z grupy Statement ma następującą
   postać:
        Statement stmt;
gdzie stmt = con.createStatement();
 Obiektu Statement używamy do wykonania zapytań SQL.
   Rezultaty zapytania są przechowywane w obiektu ResultSet:
 String query; // wiersz operatora SQL
 query = "SELECT …FROM…WHERE…”;
 ResultSet rs; // pole dla rezultatu zapytania SQL
 rs = stmt.executeQuery(query);
JDBC - sterownik –kolejność czynności cd…
4) Wywolać dane ze zbioru skutecznego. Obiekt ResultSet
   reprezentuje wynik zapytania SQL i zawiera zbiór rekordów z
   danymi. Stosując metodę next() tego obiektu, możemy mieć
   dostęp do wszystkich danych:
 more = rs.next();
 Zatem stosując metodę getXXX(nazwa_pola) trzeba zdarzyć
   dostęp do danych bieżącego rekordu. Na przykład:
         While (rs.next()) {
           Int x      = rs.getInt („pole1‟);
           String s =rs.getString („pole2‟);
           Float f = rs.getFloat („pole3‟);
         }
JDBC - sterownik –kolejność czynności cd…
                         Struktura JDBC

           ResultSet       ResultSet          ResultSet




           Statement   PreparedStatement   CallableStatement



                          Connection


                         DriverManager



            Oracle       JDBC-ODBC
            Driver         Driver                ...

                         ODBC Driver




              BD             BD                   BD

                              Fig 37
                     JDBC - przykłady użycia
 Podczas działania aplikacji bazodanowej mogą wystąpić różnego rodzaju
  sytuacje powodujące, że określone operacje na bazie zakończą się
  niepowodzeniem. Dlatego ważne jest, aby aplikacja potrafiła obsłużyć tego
  typu zdarzenia. Pomocny okazuje się mechanizm obsługi wyjątków. W takich
  przypadkach wykorzystujemy klasę SQLException.
 Przykład stworzenia tablicy w aplikacji JAVA
//----------------------------------------------------------------------------------
package jdbc;
import java.sql.*;
// Stworzenie tablicy w bazie danych biblio.
// Najpierw trzeba stworzyć ODBC profile
// bazy danych biblio.
// Do tej bazy aplikacja umieszczona poniżej dodaje nową tabelę SKLEP
public class JdbcCreateTable {
     public static void main(String args[]) {
              String url = "jdbc:odbc:biblio";
              Connection con;
              String createString;
              createString = "create table SKLEP " +
                                    "(SKL_NAME varchar(32), " +"SkL_ID int, " +
                                "SKL_ADDR varchar(32), " +"SKL_INV varchar(32))";
                JDBC - przykłady użycia cd..
     Statement stmt;
           try {
// Uruchomienie ODBC – sterownika (brydża Java – ODBC)
Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");
           } catch(java.lang.ClassNotFoundException e) {
                      System.err.print("ClassNotFoundException: ");
                      System.err.println(e.getMessage());
           }
           try {
// Realizujemy połączenie z bazą biblio
con = DriverManager.getConnection(url);
//tworzymy obiekt Statement dla przeniesienia SQL instrukcji
stmt = con.createStatement();
// uruchomienie instrukcji
stmt.executeUpdate(createString);
// usunięcie objektów
stmt.close();
                      con.close();
           } catch(SQLException ex) {
                      System.err.println("SQLException: " + ex.getMessage());
           }
     }
}
                   JDBC - przykłady użycia cd..
//----------------------------------------------------------------------------------
Przykład konstruowania zapytań do bazy danych w aplikacji Java
//----------------------------------------------------------------------------------
import java.sql.*;
// Wykorzystanie pakietu Jdbc w bazie danych biblio
// Najpierw trzeba stworzyć ODBC profile
//bazy danych biblio
 public class JdbcExample {
       // Deklaruje się obiekt połączenia z bazą danych
static Connection dbcon;
/* Podprogram główny*/
public static void main(String args[]) throws Exception {
// Uruchomienie ODBC – sterownika (brydża Java – ODBC)
Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");
// otworzenie bazy danych
open ();
// Odwzorowanie wszystkich wierszy w bazie
select ("And Authors.Au_ID < 20 )");
// Uaktualnienie rekordów oraz formowanie rezultatu
update ();
// zamknięcie bazy danych
close();
}
              JDBC - przykłady użycia cd..
// Odwzorowanie wszystkich wierszy w bazie
select ("And Authors.Au_ID < 20 )");
// Uaktualnienie rekordów oraz formowanie rezultatu
update ();
// zamknięcie bazy danych
close();
}
/* otworzyć połączenie z bazą danych */
static void open() throws SQLException {
/* Zadać imię źródła ODBC, nazwiska użytkownika i hasła
 String dsn = "jdbc:odbc:biblio";
     String user = "";
     String password = "";
/* Uruchomienie menedżera sterownika dla połączenia
dbcon = DriverManager.getConnection(dsn,user,password);
/* Domyślnie fiksacja transakcji jest dokonywana automatycznie, dla tego
funkcja AutoCommit() jest odłączona */
dbcon.setAutoCommit(false);
 }
/* określenie wszystkich czekających na zakończenie transakcji oraz zamknięcie bazy
     danych */
static void close() throws SQLException {
     dbcon.commit();
     dbcon.close(); }
               JDBC - przykłady użycia cd..
// Odwzorowanie wszystkich wierszy w bazie
/* określenie wszystkich czekających na zakończenie transakcji oraz zamknięcie bazy danych */
static void close() throws SQLException {
     dbcon.commit();
     dbcon.close();
   }
/* Otrzymanie zapytań SQL z klauzulą WHERE*/
static void select(String whereClause) throws SQLException {
     Statement stmt; //Obiekt operatora SQL
     String query; // wiersz operatora SQL
     ResultSet rs; // pole dla rezultatu zapytania SQL
     String pr;
     boolean more; // przełącznik "wiersze dodatkowe są obecne”
/* Przygotowanie zapytania SQL , konstruowanie operatora SQL, wypełnienie zapytania
     SQL */
//query = "SELECT Authors.Author FROM Authors WHERE (Au_ID < 20 // );";
            query = "SELECT Authors.Author, Titles.Title, Publishers.`Company Name` ";
            query = query + "FROM Authors, `Title Author`, Titles, Publishers ";
            query = query + "WHERE (Authors.Au_ID = `Title Author`.Au_ID AND ";
query = query + "`Title Author`.ISBN = Titles.ISBN AND ";
            query = query + "Titles.PubID = Publishers.PubID " + whereClause;
             stmt = dbcon.createStatement();
            rs = stmt.executeQuery(query);
              JDBC - przykłady użycia cd..
/* sprawdzenie obecności wierszy, które będą zwrócone */
     more = rs.next();
           if (!more) { System.out.println("No rows found"); return; }
/* Cykl dla obróbki wierzy, które są wybrane */
while (more) {
        pr = rs.getString("Author");
        System.out.println("Autor: " + pr);
        pr = rs.getString("Title");
        System.out.println("Title: " + pr);
        pr = rs.getString("Company Name");
        System.out.println("Publishers: " + pr);
        System.out.println("");
        more = rs.next();       }
      rs.close();
      stmt.close();
   }
/* Otrzymanie zapytań SQL bez klauzuli WHERE*/
   static void select() throws SQLException {
       select(""); } }
Rozproszone bazy danych a
   technologie dostępu
Przykładowa architektura klient – serwer w
              PostgreSQL

                                              SERWER

 UNIX                      Połączenie       POSTMASTER
           KLIENT

                           Połączenie
 Linux
           KLIENT                           POSTMASTER
                                                                         BAZA
                                                                        DANYCH

                                  Dostęp
                           ODBC




Windows    KLIENT                           POSTMASTER




          Wielu klientów          Wiele operacji dostępu jednocześnie
        Konieczność dostępu do bd z www
 Protokół HTTP (Hypertext Transfer Protocol)
 Dostęp do informacji w postaci stron WWW
 Informacja prezentowana w sposób nieliniowy (hipertekst)
 Prezentacja różnych typów informacji (tekst, grafika, wykres,
  wideo)
 Znajomość adresu serwera lub strony jako warunek
  konieczny pozyskania informacji
 Przeglądarka - sposób dostępu do informacji
                 Identyfikacja źródeł danych
 URL (Uniform Resource Locator) - uniwersalny sposób lokalizacji
  zasobów
 Struktura URL:
   •   usługa://adres_serwera (http://pluton.pol.lublin.pl)
   •   usługa:użytkownik@adres_serwera (mailto:piotrm@pluton.pol.lublin.pl)
   •   usługa://adres_serwera/katalog (ftp://ftp.wspa.lublin.pl)
   •   usługa://adres _serwera/katalog/dokument (http://pluton.pol.lublin.pl/wti.htm)
 Wykorzystanie:
   • odnośniki do innych stron WWW (linki)
   • odnośniki do innych usług sieciowych
Identyfikacja źródeł danych a bd w internecie
 Dostęp bezpośredni do źródła:
    • znajomość adresu serwera WWW
    • nawigacja między stronami WWW w obrębie danego serwera
 Dostęp pośredni:
    • polskie portale (Onet, Wirtualna Polska, Interia, ...)
    • wyszukiwarki sieciowe (Altavista, Yahoo, Infoseek, Lycos, ...)
 Zalety dostępu staytycznego:
    • prosty sposób wyszukiwania
    • duży wybór różnych informacji
 Wady:
    • długi czas poszukiwania informacji
    • dostęp tylko do wybranych źródeł informacji
    Metody dynamicznego dostępu do baz
          danych z poziomu WWW
Technologie dynamicznego generowania witryn:
 CGI (ang. Common Gateway Interface)
 SSI (ang. Server Side Includes)
 ISAPI (ang. Internet Server API)
 PHP (ang. PHP Hypertext Preprocessor)
 ASP klasyczne (ang. Classic ASP)
 CFML (ang. ColdFusion Markup Language)
 Roxen CMS (ang. Roxen Content Management Solution)
 Serwlety (ang. servlets) oraz JSP (ang. Java Server Pages)
 ASP.NET (ang. Active Server Pages .NET)
Statyczny witryny internetowe w dostępie do
               źródeł danych

                                                     Serwer


                Klient                       2
                                                 Strona
                                                 HTML
                                Zapytanie
                         1
                             o stronę HTML



                         4 Odpowiedź –
                                                          3
                           strona HTML
                                                           Serwer przetwarza
                                                               żądanie




   Wykorzystanie dojrzałych protokołów TCP/IP
   Opracowanie podstawowych protokołów i standardów stron WWW
    (HTTP, URL, HTML/XHTML…)
   Brak większej interakcji pomiędzy serwerem WWW, a klientem
   Statyczna zawartość witryn
         Różne metody generacji

Niskopoziomowe API serwera aplikacji (np. CGI, ISAPI).
 Ogólna zasada polega na wywoływaniu zewnętrznych
 programów, które zwracają następnie wyniki swojego
 działania do serwera aplikacji WWW w postaci kodu HTML
Interpretowane skrypty (np. PHP, ASP klasyczne).
 Bezpośrednio w kodzie strony, zanurzany jest skrypt, który
 po wykonaniu się na serwerze, wyświetlany jest na
 maszynie klienta
Kompilowane programy (JSP – serwlety i ASP.NET).
 Strony blisko kooperują z kompilowanym kodem (np. kod
 zakulisowy w ASP.NET oraz komponenty logiki
 biznesowej). Strony również podlegają kompilacji. Raz
 skompilowany element aplikacji rezyduje na serwerze,
 generując zawartość stron przy każdym żądaniu.
ASP klasyczne – schemat działania



                                        Serwer


                                 2
      Klient                         Skrypt
                                      ASP

               1 Zapytanie o                     3
                 stronę ASP
                                                 ASP.DLL
                   Odpowiedź –
               5
                   strona HTML   4
                                     Strona
                                     HTML
 Programowe interfejsy baz danych


Potrzeba programowego interfejsu baz danych
Wielość różnych rozwiązań. Przykłady:
                 ODBC (ang. Open Database
                Connectivity)
                 DAO (ang. Data Access Objects)
                 RDO (ang. Remote Data Objects)
                 OLE DB (ang. Object Linking and
                Embedding Database)
                 ADO (ang. ActiveX Data Objects)
                 ADO.NET (ang. ActiveX Data Objects
                .NET)
                 JDBC (ang. Java Database Connectivity)
          Technologia ADO.NET


 Integralny element platformy .NET
 Może być wykorzystana jako rodzaj wysokopoziomej nakładki
  ODBC lub OLE DB
 Bezpołączeniowa architektura
 Przejrzysta struktura obiektowa
 Ścisła współpraca ze standardem XML
 Efektywne wywoływanie procedur składowanych
 Obsługa ODBC, OLE DB oraz bezpośrednich interfejsów
  bazodanowych, wybranych systemów (SQL Server, Oracle)
 ADO.NET jest wykorzystywane przez ASP.NET
ADO.NET – warstwy dostępu do danych

                                Kod aplikacji



                    Obiekt DataAdapter lub Command



                           Obiekt Connection


   Dostawca .NET   Dostawca .NET            Dostawca .NET   Dostawca .NET
     dla Oracle    dla SQL Server            dla OLE DB       dla ODBC


                                                OLE DB         ODBC
       Oracle           SQL
                       Server


                                                 Baza          Baza
                                                danych        danych
         Architektura ADO.NET



          .NET Framework Data Provider   DataSet

Connection             DataAdapter       DataTableCollection
 Transaction            SelectCommand     DataTable

Command                 InsertCommand      DataRowCollection

 Parameters             UpdateCommand      DataColumnCollection

DataReader              DeleteCommand      ConstraintCollection


                                         DataRelationCollection




                     Baza
                    danych                            XML
Architektura aplikacji baz danych
                       Wnioski


 Nierozłączna współpraca technologii dynamicznego
  generowania witryn z interfejsami baz danych
 Najpopularniejsze, niekomercyjne rozwiązanie: PHP + MySQL
  lub PostgreSQL + Apache + Linux
 Technologie stosowane tam gdzie najważniejszym
   priorytetem jest bezpieczeństwo, wydajność i przejrzystość
   rozwijanego projektu: JSP oraz ASP.NET
 Inne popularne rozwiązania: ASP klasyczne, CFML
                  Platforma.NET



Najważniejsze założenia:
    Zintegrowanie technologii programistycznych w postaci
     jednej platformy
    Współpraca wielu języków programowania
    Współpraca wielu różnych architektur, zarówno
   sprzętowych
      jak i systemowych (na razie ograniczona)
    Próba ustanowienia standardu przemysłowego
     (najważniejsze elementy są standardami ECMA)
Platforma.NET – najważniejsze pojęcia


 CLR (ang. Common Language Runtime)
 BCL (ang. Base Class Library)
 MSIL (ang. Microsoft Intermediate Language)
 CLS (ang. Common Language Specification)
 CTS (ang. Common Type System)
 Podzespół (ang. assembly)
 Kompilator JIT (ang. Just-In-Time compiler)
Model wykonawczy platformy .NET


                                                               Kompilacja
          Kod źródłowy
                                            Komponent niezarządzany

           Kompilator                            Kod natywny



    Kod pośredni IL + metadane



                                                               Wykonanie
               CLR

         Kompilator kodu
           pośredniego




           Kod natywny



                             System operacyjny
     Architektura platformy .NET

C#         VB            C++           Python           J#            itd.


                 Wspólna specyfikacja języków (CLS)


                         Język pośredni (MSIL)




                                                                             Visual Studio .NET (lub inne IDE)
  Web               Strony
services           Architektura platformy .NET
                   ASP.NET
                                                 Formularze Windows

     Aplikacje ASP.NET


                          ADO.NET i XML


                    Biblioteka podstawowa (BCL)


                  Środowisko uruchomieniowe (CLR)


                     System operacyjny Windows
          Środowisko uruchomieniowe
CLR jest agentem odpowiedzialnym za:
 Zarządzanie kodem podczas jego wykonywania
 Zarządzanie pamięcią (mechanizm GC)
 Zarządzanie wątkami
 Wymuszenie zgodności typów pomiędzy różnymi językami
  programowania
 Kompilacja
 Niedopuszczenie do użycia potencjalnie niebezpiecznego
  kodu (np. wskaźników zmiennych)
                     Podzespół
 Podstawowa jednostka wdrożeniowa .NET
 Zawiera kod pośredni MSIL, niezależny od procesora (może
  być zależny od OS)
 Jest to komponent samoopisujący się (metadane)
 Nie wymaga rejestracji w systemie (instalacja xcopy)
 Może być dzielony (podobnie jak standardowe DLL) przez
  wiele aplikacji
         Wspólny System Typów (CTS)
 Umożliwia integrację wielu języków programowania
 Dwa podstawowe rodzaje typów:
   • Typy wartości
   • Typy referencyjne
 Opakowywanie zmiennej (ang. boxing)
 Brak wskaźników (zmiennych i funkcji)
 Delegaty
                    Klasyfikacja typów .NET



                                                    Typ


                 Typy wartości                              Typy referencyjne


Wbudowane typy
                             Typy wskaźnikowe             Typy samoopisujące się   Typy interfejsów
   wartości

 Typy wartości                                                  Typy klas            Typy tablic
  użytkownika

                                                            Typy spakowanych
Typy wyliczeniowe                Typy użytkownika                                     Delegaty
                                                                 wartości
        Współpraca wielu języków – CLI
 Wspólna Infrastruktura Językowa CLI (ang. Common
  Language Infrastructure) – składa się z CLR i CLS. Jest
  publicznie dostępna; każdy może opracować kompilator JIT
  dla dowolnego języka tak by był zgodny z platformą .NET
 Faworyzacja języków podobnych do C#
 Języki programowania .NET w efekcie różnią się pomiędzy
  sobą tylko notacją (dialekty języków oryginalnych). Przykład:
  język Smalltalk, z dynamicznym typowniem
 Standard ECMA (wraz z językiem C#)
 Dostępnych ponad dwadzieścia języków programowania na
  platformie .NET (np. C++, C#, J#, Visual Basic, Smalltalk,
  Python, Perl, Pascal, Eiffel, Fortran…)
                 .NET vs J2EE


 Trudno wskazać jednoznacznie lepszą platformę
 J2EE bardziej dojrzała (zaprezentowana w 1999 roku) i
  szerzej akceptowana w przemyśle
 .NET posiada bardziej przejrzystą architekturę
 J2EE współpracuje z najważniejszymi systemami
  operacyjnymi, .NET głównie MS Windows
 .NET umożliwia współpracę wielu języków, J2EE
  ogranicza się praktycznie tylko do języka Java
 .NET oferuje lepszą produktywność
                 Technologia ASP.NET
 Ważny element architektury .NET
 Kompilowany kod – wydajność
 Separacja kodu prezentacji od kodu obsługi strony (kod zakulisowy);
  komponenty biznesowe
 Rozbudowane mechanizmy buforowania stron i danych
 Wielość stosowanych języków programowania
 Obsługa elektronicznych urządzeń przenośnych (telefony komórkowe,
  PDA)
 Wysoka produktywność
 Duży poziom bezpieczeństwa
 Naturalna współpraca z bazami danych i XML
   Formularze ASP.NET (ang. Web forms)

 Podstawowy element budulcowy aplikacji ASP.NET
 Separacja kodu interfejsu od jego obsługi
 Obiektowy model projektowania
 Możliwość wykorzystania kodu client-side do walidacji danych
  użytkownika
       Kod zakulisowy – web forms


                MojFormularz.aspx.cs
                         Class MojFormularz
MojFormularz.aspx                                      MojFormularz

               Witaj                                                  Witaj
                                                               Imię:
       Imię:
                                                               Hasło:
       Hasło:


                 OK                                                     OK

     Te dwa pliki tworzą razem formularz internetowy
Struktura ASP.NET web forms

 Projektowanie            Wykonanie


System.Web.UI.Page
          Dziedziczenie


  WebForm1.cs
                          Dziedziczenie
          Kompilacja


    Projekt.dll

Klasa WebForm1
                          WebForm1.aspx



                                                       Strona
                           temporary.dll
                                                       HTML


                           Wynik do przeglądarki lub
                                  urządzenia
       Cykl życia formularza ASP.NET

Przeglądarka internetowa                                             Serwer
        (Koszyk.aspx)                                              (Koszyk.aspx.cs)

              Koszyk                                        ObsluzStrone();
                                                            PobierzWybProdukt();
      Dodaj            Mąka     Przycisk „Dodaj”            DodajDoKoszyka();
                                wysyła żądanie na           StworzNowaStrone();
      Dodaj            Cukier   serwer…                     Odswiez();


      Dodaj             Sól



                                                                                 Serwer wykonuje
                                                                                 żądanie…
                                        Koszyk

                                Dodaj            Mąka

                                Dodaj            Cukier
                                                          …w wyniku którego
                                Dodaj             Sól     do przeglądarki
                                                          wracana jest nowa
                                                          strona
                Zarządzanie stanem
 Potrzeba zarządzania stanem; HTTP jako tzw. stateless
  protocol
 Dwie generalne metody zarządzania stanem:
   • Po stronie klienta (np. cookies, query strings)
   • Po stronie serwera (np. wsparcie serwera aplikacji oraz
     baz danych)
 Każde podejście ma swoje wady i zalety; strategię należy
  dobierać ściśle do konkretnych wymagań
 Aspekt bezpieczeństwa
           Zarządzanie stanem (c.d.)
Przykłady metod zarządzania stanem:
 Widok stanu
 Ukryte pola formularzy HTML
 Ciasteczka (ang. cookies)
 Ciągi zapytań (ang. query strings)
 Stan aplikacji
 Utrzymanie stanu z użyciem baz danych
               Kontrolki serwerowe
 Analogiczne do kontrolek aplikacji desk-top
 Sześć grup kontrolek serwerowych ASP.NET:
   • Serwerowe kontrolki HTML
   • Serwerowe kontrolki internetowe
   • Kontrolki walidacyjne
   • Kontrolki użytkownika
   • Dostosowane kontrolki internetowe
   • Mobilne kontrolki ASP.NET
        Dostęp do danych w ASP.NET
 Wykorzystanie technologii ADO.NET jako interfejsu
  bazodanowego programisty
 Bezpołączeniowy model klient-serwer; potrzeba cyklu
  podróży w obie strony (ang. round trip)
 Częstsze odczytywanie danych aniżeli ich zapis
 Minimalizowanie konsumpcji zasobów serwera
 Dostęp do danych z użyciem rozproszonego przetwarzania
 Zapewnienie odpowiedniego poziomu bezpieczeństwa
  danych
 Znaczenie procedur składowanych po stronie serwera bazy
  danych w aplikacjach internetowych
            Mechanizmy buforowania
 Znaczenie buforowania
 Dwa zasadnicze podjeścia:
   • Buforowanie wyjścia (ang. output caching)
   • Buforowanie danych aplikacji (ang. application data
     caching)
 Buforowanie fragmentów strony
      Konfiguracja środowiska ASP.NET
 Pliki konfiguracyjne w standardzie XML
 Możliwość współistnienia wielu plików konfiguracyjnych
  Web.config w ramach jednej aplikacji
 Znaczenie pliku Machine.config
 Dziedziczenie ustawień w hierarchii katalogów wirtualnych
  serwera aplikacji internetowej
 Możliwość zmiany konfiguracji w działającej aplikacji, bez
  potrzeby restartu serwera
 Rozszerzalność plików konfiguracyjnych jako plików XML
 Ochrona przed niepowołanym dostępem do plików
  konfiguracyjnych z zewnątrz
      Bezpieczeństwo aplikacji ASP.NET
 Aspekt bezpieczeństwa w aplikacjach internetowych
 Dwa fundamentalne procesy:
   • Uwierzytelnianie (ang. authentication) – sprawdzenie
     tożsamości danego użytkownika w systemie
   • Autoryzacja (ang. authorization) – określenie do jakich
     danych może mieć dostęp uwierzytelniony użytkownik
 Uwierzytelnianie może następować poprzez:
   • System Windows
   • Formularze ASP.NET
   • Usługę Passport
  Bezpieczeństwo aplikacji ASP.NET (c.d)
 Architektura ASP.NET




                                      Klient



                  Aplikacja ASP.NET                IIS




                   .NET Framework




                               System operacyjny
             Optymalizacja ASP.NET
Cztery podstawowe czynniki wydajnościowe:
 Czas wykonania (ang. execution time)
 Czas odpowiedzi (ang. response time)
 Skalowalność (ang. scalability)
 Przepustowość (ang. throughput)
         Przyszłość technologii ASP.NET
 Przykłady wykorzystania we współczesnym biznesie (np.
  DELL, London Stock Exchange, NASDAQ, Microsoft)
 Następca obecnej wersji ASP.NET v1.1 – ASP.NET v2.0
  „Whidbey”. Nie zapowiedziano jeszcze terminu prezentacji
  finalnej wersji.
 Główny punkty rozwoju:
   • Produktywność
   • Administracja i zarządzanie
   • Wydajność
           Architektura systemu (c.d.)
 Warstwy programu użytkowego




                      Warstwa prezentacji




                     Warstwa przetwarzania




                   Warstwa zarządzania danymi
              Architektura systemu (c.d.)
 Model klienta cienkiego i klienta grubego




                                               Warstwa prezentacji
     Cienki                                  (interfejs użytkownika)    Gruby
     klient       Warstwa prezentacji
                                                         +              klient
                (interfejs użytkownika)
                                             Warstwa przetwarzania
                                                (logika biznesowa)




               Warstwa przetwarzania
                  (logika biznesowa)
                                           Warstwa zarządzania danymi
                           +
              Warstwa zarządzania danymi
Przykładowa architektura systemu z ADO.NET




                       warstwa logiki
                        biznesowej          warstwa
        warstwa                             danych
       prezentacji

                     Komponenty logiki
                        biznesowej
      Formularze        korzystające
                                         SQL Server 2000
       ASP.NET       z ADO.NET przy
                      dostępie do bazy
                           danych
Podsumowanie
                   Podsumowanie (1)
 Globalizacja przestrzeni informacyjnej powoduje nacisk na
  tworzenie rozproszonych i federacyjnych baz danych, które
  umożliwiłyby tworzenie aplikacji globalnych, działających na
  zestawie dziesiątków, tysięcy lub milionów lokalnych BD.
 Połączenie tych lokalnych baz danych siecią komputerową stwarza
  niezbędną infrastrukturę techniczną, ale nie rozwiązuje ogromnej
  ilości problemów koncepcyjnych, których część została omówiona
  na tym wykładzie.
 Pewna część problemów jest rozwiązana dla rozproszonych
  relacyjnych baz danych. Rozproszone obiektowe bazy danych
  znajdują się na początku drogi.
 Niektóre problemy, takie jak: przetwarzanie globalnych transakcji,
  aktualizowalne perspektywy, rozstrzyganie niezgodności
  schematów, akceptowalna wydajność globalnych aplikacji, itd.,
  prawdopodobnie nie mają ogólnego rozwiązania. Pozostają
  nadzieje na rozwiązania cząstkowe.
                    Podsumowanie (2)
 Problemy rozproszenia są skutkiem “spadku” pozostawionego nam
  przez naszych poprzedników. Znaczna część problemów może
  rozwiązać się sama poprzez rezygnację ze spadku, tj. poprzez
  wymarcie kłopotliwych SZBD i powstanie nowych SZBD, lepiej
  przystosowanych do tworzenia rozproszonych federacji.
 Konieczna jest standardyzacja:
   • w zakresie modeli danych
   • w zakresie ontologii biznesowej i metamodeli
   • w zakresie wymiany danych
   • w zakresie API realizującego dostęp do do danych, w szczególności
     języków zapytań
 Konieczne są dalsze prace badawcze i wdrożeniowe w zakresie
  przetwarzania i optymalizacji rozproszonych obiektowych zapytań,
  protokołów dostępu, obiektowych perspektyw, ontologii,
  metamodeli, formatów wymiany danych, rozproszonych transakcji,
  itd.

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:158
posted:4/15/2010
language:Polish
pages:273