Transcript Rozproszone i federacyjne bazy danych

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
Jednorodne
BD
Rozproszone BD z
globalnym schematem
Federacyjne BD
Słabo skojarzone
(loosely coupled)
Niefederacyjne BD: brak autonomii.
Słabo skojarzone FBD: brak federacyjnego schematu i
zarządzania, operacje ad hoc, w zależności od aplikacji.
Ściśle skojarzone FBD: FSZBD jest odpowiedzialny za
zarządzanie całością federacji.
Ściśle skojarzone
(tightly coupled)
Pojedyncze
federacje
(pojedynczy
schemat)
Wielokrotne
federacje
(wiele
schematów)
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 obiektoworelacyjnych (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(C.J.(1)
Date, 1987)
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
autonomii.
autonomii
jest raczej
intuicyjne.
 Federacja
nieskala
może
żądać odPojęcie
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
Zespół projektantów
Dziedzina problemowa,
obejmująca ogromną liczbę
wzajemnie uzależnionych
aspektów i problemów.
Środki i technologie
informatyczne:
sprzęt, oprogramowanie, sieć,
języki, narzędzia, udogodnienia.
Oprogramowanie:
decyzje strategiczne,
analiza,
projektowanie,
konstrukcja,
dokumentacja,
wdrożenie,
szkolenie,
eksploatacja,
pielęgnacja,
modyfikacja.
podlegający ograniczeniom
pamięci, percepcji, wyrażania
informacji i komunikacji.
Potencjalni użytkownicy:
czynniki psychologiczne,
ergonomia, ograniczenia pamięci
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,
komponentów projektu, komponentów oprogramowania, itd.
wzorców,
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
rzeczywistego
świata
Analityczny
model
rzeczywistości
... ...
... ...
...
...
... ...
... ...
Model
struktur danych
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 *
Pracownik
Zawód *
0..*
PZ
1
Zatrudnienie
Wypłata *
0..*
Ocena *
FZ
Firma
Nazwa
1 Miejsce *
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)
Zatrudnienie(NrF, NrP)
Lokal(NrF, Miejsce)
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
serwera
Podsystem
komunikacyjny
Oprogramowanie
klient/serwer
Zapytanie
użytkownika
Oprogramowanie
klient/serwer
Aplikacja
użytkownika
Zapytanie
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:
top-down
bottom-up
Odgórne zaprojektowanie całej bazy danych,
z uwzględnieniem optymalizacji
przechowywanych danych, narzuconej przez
fakt geograficznego rozproszenia
producentów i konsumentów informacji
przechowywanej w bazie danych.
Od szczegółów do ogółu:
Zintegrowanie już istniejących (spadkowych)
lub zaprojektowanych lokalnych baz danych
w jedną globalną rozproszoną bazę danych.
Projektowanie: podejście top-down
Analiza
Model pojęciowy
scentralizowany
Analiza systemowa: rozpoznanie
wymagań, precyzowanie
kontekstu przyszłej bazy danych.
Projektowanie schematu
pojęciowego
Projektowanie struktury
logicznej
Model logiczny
scentralizowany
Modele logiczne
dla
poszczególnych
miejsc
Kryteria
rozproszenia
Kryteria rozproszenia są
związane z faktem fizycznego
rozproszenia źródeł i
odbiorców danych oraz
autonomii lokalnych baz
danych. Ustalają one decyzje,
które fragmenty projektu
pojęciowego będą
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
DC
DOSTAWCA_DANE
DNR NAZW
D1
D2
D3
D4
D5
Abacki
Bober
Czerny
Dąbek
Erbel
DNR CNR ILOŚĆ
STATUS
20
10
30
20
30
Sieć
Gdańsk
DOSTAWCA_MIASTO
DNR
D1
D2
D3
D4
D5
MIASTO
Lublin
Poznań
Poznań
Lublin
Radom
D1
D1
D1
D1
D1
D1
D2
D2
D3
D4
D4
D4
C1
C2
C3
C4
C5
C6
C1
C2
C2
C2
C4
C5
300
200
400
200
100
100
300
400
200
200
300
400
Fragmentacja pozioma relacyjnej bazy danych
DOSTAWCA
DNR NAZW
D2 Bober
D3 Czerny
Poznań
DC
DNR CNR ILOŚĆ
STATUS MIASTO
10 Poznań
30 Poznań
D2
D2
D3
C1
C2
C2
300
400
200
Lublin
DOSTAWCA
Sieć
DNR NAZW
STATUS MIASTO
D1 Abacki
D4 Dąbek
20 Lublin
20 Lublin
DC
DOSTAWCA
DNR NAZW
D5 Erbel
Radom
STATUS MIASTO
30 Radom
DNR CNR ILOŚĆ
D1
D4
D4
C6
C2
C4
100
200
300
Przykład fragmentacji poziomej
Radom
Klasa
Pracownik
Pracownik
Nowak
Pracownik
Kowalski
Obiekty Pracownik są
przechowywane zgodnie z
geograficznym położeniem
pracodawcy.
...
Kalisz
Sieć
Pracownik
Styka
Kielce
Pracownik
Malasa
Klasa
Pracownik
Pracownik
Zagórny.
...
Klasa
Pracownik
Pracownik
Malina
...
Fragmentacja pionowa obiektów Pracownik
Radom
Klasa danych
osobistych
Nowak
dane osobiste
Kowalski
dane osobiste
...
Kalisz
Sieć
Nowak
dane o ocenach
Kraków
Nowak
dane o zatrud.
Klasa danych o
zatrudnieniu
Kowalski
dane o zatrud.
...
Klasa danych o
ocenach
Kowalski
dane o ocenach
...
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 podzapytania 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
Aplikacjeglobalne
globalne
Schemat federacyjnej bazy danych
Perspektywa
Mediator
Osłona
Perspektywa
Mediator
Osłona
Schemat lokalny 1
Miejsce 1
Aplikacje
Aplikacje
Aplikacje
lokalne
lokalne
lokalne
Schemat lokalny 2
Miejsce 2
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
(zwykle związaną z interakcją z
użytkownikiem)
Podstawowe
problemy:
wykonywaną po stronie serwera
(komunikacja, dostęp do bazy danych,
zarządzanie repozytoriami pamięci,
zarządzanie globalną przestrzenią
nazw)
Określenie mechanizmu komunikacji pomiędzy
klientem a serwerem.
Podział funkcji na te, które są wykonywane po stronie
klienta i te, które są wykonywane po stronie serwera
Określenie jednostki komunikacji klient - serwer
Heterogeniczne środowisko
w architekturze klient-serwer
Windows 95
Client
Windows NT
Client
UNIX
Client
Windows 95
or NT
Client
TCP/IP network
Windows NT Server
with repository on
SQLserver
UNIX Server
with repository on
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
Aplikacja po stronie
klienta odwołuje się
do danych
umieszczonych w
pliku bazy danych
Zapotrzebowanie na
odczyt/zapis
danych w plikach
Odczytane dane z
plików bazy danych
serwer
Alokacja pamięci
WE/WY
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
zadaje zapytanie
SQL
Zarządzanie
kursorem
klient
Zapytanie SQL
Maszyna SQL
krotka
serwer
Architektura z serwerem stron
klient
aplikacja
Menadżer
obiektów
serwer
Pamięć
podręczna
stron
Menadżer
plików/indeksów
Menadżer stron
pamięci
podręcznej
Alokacja pamięci
WE/WY
strony
Pamięć
podręczna
obiektów
Pamięć
podręczna
stron
Menadżer Menadżer
stron pamięci dziennika
podręcznej blokowania
Architektura serwera stron
Aplikacja
Przedmiotem
zarządzania
są fizyczne
strony dyskowe
Interfejs
zapytaniowy
Optymalizacja
zapytań
Przeglądarka
obiektów
Interfejs
programistyczny
Zarządzanie obiektami
Zarządzanie plikami i indeksami
Zarządzanie kieszenią stron
strony
Zarządzanie zamkami
Zarządzanie składem
Zarządzanie kieszenią stron
Obiektowa
baza
danych
Architektura z serwerem obiektów
klient
serwer
Pamięć
podręczna
obiektów
Aplikacja
Menadżer
plików/indeksów
Menadżer
stron pamięci
odręcznej
Menadżer
obiektów
obiekty
Pamięć
podręczna
obiektów
Menadżer Menadżer
obiektów dziennika
blokowania
Alokacja pamięci
WE/WY
Pamięć
podręczna
stron
Architektura serwera obiektów
Aplikacja
Przedmiotem
zarządzania
są obiekty
Interfejs
zapytaniowy
Przeglądarka
obiektów
Interfejs
programistyczny
Zarządzanie obiektami
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
transakcjami
Zarządzanie
transakcjami
Zarządzanie
buforami
...
Zarządzanie
buforami
Zarządzanie zasobami
Zarządzanie zasobami
Klient 1
Klient n
Zarządzanie
siecią
Interfejs serwera
Zarządzanie
zasobami
Zarządzanie
transakcjami
Zarządzanie
logiem
Serwer
Zarządzanie
buforami
Zarządzanie
zamkami
Architektura klient-(multi) serwer (1)
Połączenia bezpośrednie:
k2
k3
k7
k1
s4
k4
k5
s1
k8
s3
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.
k2
k1
s4
k3
k9
k4
Sieć komputerowa
s1
k8
s3
k5
k6
s2
k7
Architektura trzywarstwowa i wielowarstowa
three-tier architecture
multi-tier architecture
 Architektura klient-serwer podzielona na trzy
warstwy:
• interfejs użytkownika,
• logikę przetwarzania (reguły biznesu, logikę
biznesu)
Interfejs
użytkownika
• serwer (serwery) bazy danych.
 Warstwy są zaprojektowane i istnieją niezależnie,
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
przetwarzania na serwerze aplikacji i baza
danych na serwerze bazy danych.
 Środkowa warstwa może składać się z wielu
warstw, co jest określane jako architektura
Logika przetwarzania
Serwer
bazy
danych
Serwer
bazy
danych
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:
cienki
klient
Warstwa prezentacyjna
(interfejs użytkownika)
gruby
klient
Warstwa przetwarzania
(logika biznesu)
Warstwa zarządzania
bazą danych
Staranne rozdzielenie tych warstw jest
bardzo istotne z punktu widzenia
tworzenia i modyfikowalności
oprogramowania. Dzięki temu
rozdzieleniu, możliwa jest np. poprawa
interfejsu użytkownika bez jakichkolwiek
interwencji w pozostałe warstwy
oprogramowania.
Zasada oddzielania aspektów
(separation of concerns principle,
E.Dijkstra)
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
klient
Warstwa prezentacyjna
(interfejs użytkownika)
Warstwa przetwarzania
(logika biznesu) +
Warstwa zarządzania
bazą danych
Warstwa prezentacyjna
(interfejs użytkownika)
+ Warstwa przetwarzania
(logika biznesu)
gruby
klient
Warstwa przetwarzania
(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
Bankomat
Oprogramowanie pośredniczące
organizujące komunikację z odległymi
klientami i szeregujące transakcje klientów
celem przetwarzania ich przez bazę danych.
Przykład architektury K/S - portal WWW
klient
interakcja
poprzez
HTTP
Serwer Web:
klient
klient
klient
generacja
dynamicznych stron
HTML dla klienta
+
zlecenia do bazy
danych
zapytania
SQL
wyniki
zapytań
SQL
Serwer bazy
danych:
wykonywanie
zapytań w SQL
3-warstwowa architektura aplikacji Web
Serwer Web
Sieć
Internet
Serwer aplikacji
Serwer bazy danych
HTTP
Baza
danych
Przeglądarka
Serwer
Baza
danych
2-warstwowa architektura aplikacji Web
Wiele warstw pośredniczących powoduje dodatkowe obciążenie.
Sieć
Internet
Serwer Web
Serwer aplikacji
Serwer bazy danych
HTTP
Baza
danych
Przeglądarka
Serwer
Baza
danych
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
operacji
Klient
Pośrednik (Broker)
wynik,
parametry WY
Obiekt
Architektura rozproszonych obiektów (2)
...
Aplikacja
napisana w
C++
Aplikacja na
relacyjnej
bazie danych
Aplikacja
na Lotus
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
O3
O1
O2
Obiekty
Operacje na
obiektach
O7
O5
O9
O4
K1
O8
O6
K3
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
Przeglądarka
WWW
Narzędzia
wspomagające XML :
system autorski, itd.
Warstwa klienta
Przeglądarka
WWW
XML
XML
Serwer Web
Serwer aplikacji
Interakcja z aplikacjami poprzez
protokoły oparte na XML
Logiczna warstwa pośrednia
Baza danych w XML
(strukturalizowana)
Serwer integrujący XML,
serwer zapytań,
serwer hurtowni danych
XML
XML
XML
XML
Translatory formatów
z/do XML, pomosty
Zasoby danych
Obiektowo-relacyjna
baza danych
wspomagająca XML
Obiektowa baza
danych
wspomagająca XML
Dokumenty
Dokumenty
XML
XML
nana
Webie
Webie
Inne
Inne
dokumenty
dokumentynana
Webie:
Webie:HTML
HTML
Word,...
Word,...
Zasoby danych
pod OLE/DB
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 niebazodanowe, 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
ze sterowaniem współbieżnościa
Transakcja aktualizująca
Propagacja aktualizacji
Transakcja aktualizująca
propagacja
aktualizacji
Replika 1
Replika 2
Replika 3
Replika 3
Replika 1
Replika 2
Planowane odświeżanie kopii dla replik tylko do czytania
Transakcja aktualizująca
planowana
aktualizacja
Transakcja czytająca
Replika 3
Replika 1
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
> ilość replik
Jeżeli
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ą.
start
potwierdzenie
(commit)
zakładanie zamków
(nie ma zwalniania)
koniec
zwalnianie
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)
potwierdź
SZBD klienta
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
FSZBD
1
Przestrzeń
robocza
Aplikacje globalne
...
Schemat FBD
FSZBD
m
Przestrzeń
robocza
Schemat FBD
Sieć
komputerowa
Schemat eksportowy 1
Osłona 1
API 1
Lokalny
SZBD 1
BD 1
Aplikacje lokalne
Schemat eksportowy 2
Osłona 2
API 2
Lokalny
SZBD 2
BD 2
Aplikacje lokalne
...
Schemat eksportowy n
Osłona n
API n
Lokalny
SZBD n
BD n
Aplikacje lokalne
Global schema
External sub-schemata
Architektura(indostępu
do
lokalnej
BD
an extended ODL)
(through an accessibility matrix)
Lokalna baza danych
Lokalny schemat
eksportowy
Zewnętrzne podschematy
użytkowników (macierz dostępu)
Zewnętrzny
podschemat 1
Zewnętrzny
podschemat 2
Zewnętrzny
podschemat 3
Interfejs IA1
Dostęp
Zakaz
Zakaz
Interfejs IA2
Zakaz
Zakaz
Dostęp
Dostęp
Zakaz
Dostęp
Interfejs IC1
Zakaz
Dostęp
Zakaz
Ob.wirt.
VV3
Ob.wirt.
3V
Dane wirt.
1
Perspektywa V1
Zakaz
Dostęp
Dostęp
Ob.wirt.
VV3
Ob.wirt.
3V
Dane wirt.
2
Perspektywa V2
Dostęp
Zakaz
Zakaz
Obiekty A
Obiekty A
Obiekty
Dane B A
Obiekty
Dane C A
API
Osłona
Mediator
Obiekty A
Obiekty A
Obiekty
Dane A A
Interfejs IB1
definiuje
Administrator
lokalnej bazy danych
Użytkownik Użytkownik
1
2
Użytkownik
3
Trój-warstwowa architektura federacyjnej BD
3
Użytkownik 1
Użytkownik 2
Użytkownik 3
Schemat zewnętrzny 1
Schemat zewnętrzny 2
Schemat zewnętrzny 3
Schemat federacyjny
2
FSZBD
Przestrzeń
robocza
Sieć
1
Schemat eksportowy 1
Osłona 1
API 1
Lokalny
SZBD 1
BD 1
Schemat eksportowy 2
Osłona 2
API 2
Lokalny
SZBD 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
Obiekty
Obiekty
Obiekty
Klient
Wywołanie
operacji
Pieniek
klienta
zlecenie
Implementacja
interfejsów do
obiektów
(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
obowiązującego w federacji.
SZBD
do
interfejsu
programistycznego
Federacyjny
SZBD
API f
API f
Osłona 1
Osłona 2
API 1
Lokalny
SZBD 1
API 2
Lokalny
SZBD 2
API f
...
Osłona n
API n
Lokalny
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
ANSI/SPARC:
Użytkownik 1
Użytkownik 2
Użytkownik 3
Schematy
“zewnętrzne”
Perspektywa 1
W tym sensie
pojęcie perspektywy
funkcjonuje w literaturze z
zakresu modeli danych,
analizy i projektowania.
Perspektywa 2
Schemat globalny
Poziom fizyczny
bazy danych
Perspektywa 3
Projektant BD
Administrator BD
Administrator BD
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 makrodefinicję, 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
WHERE Nazwisko = ‘Nowak’
Perspektywy wolno użyć w
zdaniach SQL (prawie) na
takich samych zasadach jak
zapamiętanej tabeli.
Relacyjna baza danych z perspektywami
Użytkownik lub
program aplikacyjny
SQL
Dane wirtualne
Dane rzeczywiste
(logiczne)
Dane zapamiętane
(fizyczne)
Perspektywa
V1
Tablica BD
B1
Tablica BD
B2
Perspektywa
V2
Tablica BD
B3
Tablica BD
B4
Przykład relacyjnej bazy danych
DC
DOSTAWCA
DNR NAZW
D1
D2
D3
D4
D5
DNR CNR ILOŚĆ
STATUS MIASTO
Abacki
Bober
Czerny
Dąbek
Erbel
20
10
30
20
30
Lublin
Poznań
Poznań
Lublin
Radom
CZĘŚĆ
CNR NAZWAC
C1
C2
C3
C4
C5
C6
Nakrętka
Wkręt
Podkładka
Nit
Nit
Tulejka
KOLOR
Czarwony
Zielony
Niebieski
Czerwony
Niebieski
Czerwony
WAGA MIASTO
12
17
17
14
12
19
Lublin
Poznań
Rzeszów
Lublin
Poznań
Lublin
D1
D1
D1
D1
D1
D1
D2
D2
D3
D4
D4
D4
C1
C2
C3
C4
C5
C6
C1
C2
C2
C2
C4
C5
300
200
400
200
100
100
300
400
200
200
300
400
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:
Wirtualna tabela o postaci:
DROP VIEW DobryDostawca;
- usunięcie perspektywy z bazy danych.
DobryDostawca
DNR nazwisko status suma
D1 Abacki
D2 Bober
D4 Dąbek
20 1300
10 700
20 900
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
Baza danych
Dane zapamiętane
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
Dział zatrudnia
Nazwisko
*
Nazwa
Zarobek
/MojeDziały
Nazwa
Ś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
zatrudnia Pracownik
Dział
* Nazwisko
szef
Nazwa
Zarobek
0..1
Dane wirtualne
/MoiPracownicy
Nazwisko
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
wszystkim programistom z
działu Krasnali ogrodowych:
UPDATE MoiLudzie
SET Zarobek = Zarobek + 500
WHERE NazwaDziału = ‘Krasnale ogrodowe’
OK.
Przenieść programistę Nowaka
do działu Lalek Barbie:
UPDATE MoiLudzie
SET NazwaDziału = ‘Lalki Barbie’
WHERE Nazwisko = ‘Nowak’
Źle!
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ęć
modelu
obiektowego,
perspektywy
rekurencyjne,
perspektywy
z parametrami,

Perspektywy
z (trwałym)
stanem,
o pełnej mocy
algorytmicznej.
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
SET Zarobek = Zarobek + 500
WHERE Nazwisko = ‘Marucha’
Taka aktualizacja spowoduje, że Marucha
zostanie usuniety z perspektywy (ale
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
sprzątaczka, itd. Federacja wymaga pełnych nazw zawodów. Potrzebna jest
1:
dodatkowa funkcja, która zamieni numery na stringi. Definicja perspektywy
musi więc zawierać definicję trwałej tabeli z numerami i stringami.
Przykład
2:
Dla celów kontroli utworzona jest perspektywa w postaci tabeli
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
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:
SELECT Zarobki FROM Urzędnicy
WHERE Nazwisko = ‘Nowak’
Po tekstowej
modyfikacji
zapytania:
SELECT Zarobki FROM
(SELECT Id_pracownika, Imię, Nazwisko, Zarobki FROM Pracownicy
WHERE Stanowisko = ‘urzędnik’)
WHERE Nazwisko = ‘Nowak’
Usunięcie
zbędnych
astrybutów:
SELECT Zarobki FROM
(SELECT Nazwisko, Zarobki FROM Pracownicy
WHERE Stanowisko = ‘urzędnik’)
WHERE Nazwisko = ‘Nowak’
Ostateczna
optymalizacja:
SELECT Zarobki FROM Pracownicy
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
CREATE VIEW Student( Id, Nazwisko, NrIndeksu) AS
SELECT * FROM StaryNowyStudent
UNION
SELECT * FROM NowyStudent
Pozostają
problemy spójnej
aktualizacji oraz
wydajności.
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
Z1
Z2
Dekompozycja zapytania Z
Scalenie wyników
W1
Serwer S1
Serwer S2
W2
...
Zk
Wynik W zapytania Z
Wk
Serwer Sk
 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
(Z, W1)  Z2, F1
(Z, W1, W2)  Z3, F2
Scalenie wyników
Z1
W1
Serwer S1
Z2, F1
W2
Serwer S2
Z3, F2
W3
Serwer S3
Przykład: technika pół-złączeń (1)
Serwer 1
Serwer 2
DOSTAWCA
DC
DNR NAZW
D1 Abacki
D2 Bober
D5 Erbel
STATUS MIASTO
20 Lublin
10 Poznań
30 Radom
DNR CNR ILOŚĆ
D1
D1
D2
D2
D3
D4
D4
D4
C4
C5
C1
C2
C2
C2
C4
C5
200
100
300
400
200
200
300
400
Klient ma dokonać złączenia relacji DOSTAWCA i relacji DC:
select * from DOSTAWCA, DC
where DOSTAWCA.DNR = DC.DNR
semijoin
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
D1 Abacki
D2 Bober
D5 Erbel
STATUS MIASTO
20 Lublin
10 Poznań
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
D1
C5
100
D2
C1
300
D2
C2
400
Pół-złączenie relacji R1, parametryzowane relacją
R2, powstaje poprzez złączenie R1 z R2, a
następnie projekcję wyniku na atrybuty relacji R1
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
D1
D1
D2
D2
NAZW
Abacki
Abacki
Bober
Bober
STATUS
20
20
10
10
MIASTO CNR ILOŚĆ
C4
200
Lublin
C5
100
Lublin
C1
300
Poznań
C2
400
Poznań
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
ODBC
ACCESS
Source of data
ODBC
ACCESS
Driver
ODBC
SYBASE
Source of data
ODBC
SYBASE
...
Source of data
ODBC
ORACLE
...
Fig. 33
Driver
ODBC
ORACLE
Schemat współpracy różnych narzędzi w
architekturze „ Klient – Serwer” w sieci LAN
Client
application
Aplikacja na stancji
klienta realizuje zapytania
do baz danych przez ODBC
Manager.
Zapytania mogą być dla
lokalnej bazy danych lub do
baz danych umieszczonych
na innych serwerach sieci
lokalnej.
Na rys. pokazano trasy
wszystkich zapytań.
Client MS Windows
ODBC driver
manager
ODBC
driver local
data
text
ODBC
driver
DBMS-2
ODBC
driver
DBMS-1
Server 1
DBMS - 1
File
System
Net Driver
Net Driver
Local Disk
LocalNet
Server 2
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
Open()
Execute( )
BeginTrans()
CommitTrans( )
RollbackTrans ( )
Errors
Error
Command
Execute ( )
CreateParametr ()
Parameters
Recordset
BOF
EOF
RecordCount
MoveFirst ( )
MoveLast ( )
MoveNext ()
MovePrevious ()
Move()
AddNew ()
UpDate ()
Delete ()
Open()
Close()
Append ( )
Delete ( )
Item ()
Refresh ()
Parameter
Fields
Fig 36
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
Driver
JDBC-ODBC
Driver
...
ODBC Driver
BD
BD
Fig 37
BD
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
Linux
Windows
KLIENT
Połączenie
POSTMASTER
Połączenie
KLIENT
KLIENT
Wielu klientów
POSTMASTER
ODBC
UNIX
Dostęp
POSTMASTER
Wiele operacji dostępu jednocześnie
BAZA
DANYCH
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:[email protected])
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
2
Klient
1
Zapytanie
o stronę HTML
4 Odpowiedź –
strona HTML
Strona
HTML
3
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
Skrypt
ASP
Klient
1 Zapytanie o
stronę ASP
3
ASP.DLL
5
Odpowiedź –
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
dla Oracle
Oracle
Dostawca .NET
dla SQL Server
Dostawca .NET
dla OLE DB
Dostawca .NET
dla ODBC
OLE DB
ODBC
SQL
Server
Baza
danych
Baza
danych
Architektura ADO.NET
.NET Framework Data Provider
Connection
Transaction
DataAdapter
SelectCommand
DataSet
DataTableCollection
DataTable
InsertCommand
DataRowCollection
Parameters
UpdateCommand
DataColumnCollection
DataReader
DeleteCommand
ConstraintCollection
Command
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
Kod natywny
Kompilator
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)
Strony
Architektura platformy .NET
ASP.NET
Formularze Windows
Aplikacje ASP.NET
ADO.NET i XML
Biblioteka podstawowa (BCL)
Środowisko uruchomieniowe (CLR)
System operacyjny Windows
Visual Studio .NET (lub inne IDE)
Web
services
Ś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
Wbudowane typy
wartości
Typy wskaźnikowe
Typy wartości
użytkownika
Typy wyliczeniowe
Typy użytkownika
Typy referencyjne
Typy samoopisujące się
Typy interfejsów
Typy klas
Typy tablic
Typy spakowanych
wartości
Delegaty
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
Witaj
MojFormularz
Witaj
Imię:
Imię:
Hasło:
Hasło:
OK
Te dwa pliki tworzą razem formularz internetowy
OK
Struktura ASP.NET web forms
Projektowanie
Wykonanie
System.Web.UI.Page
Dziedziczenie
WebForm1.cs
Kompilacja
Dziedziczenie
Projekt.dll
Klasa WebForm1
WebForm1.aspx
temporary.dll
Wynik do przeglądarki lub
urządzenia
Strona
HTML
Cykl życia formularza ASP.NET
Przeglądarka internetowa
Serwer
(Koszyk.aspx)
(Koszyk.aspx.cs)
Koszyk
Dodaj
Mąka
Dodaj
Cukier
Dodaj
Sól
Przycisk „Dodaj”
wysyła żądanie na
serwer…
ObsluzStrone();
PobierzWybProdukt();
DodajDoKoszyka();
StworzNowaStrone();
Odswiez();
Serwer wykonuje
żądanie…
Koszyk
Dodaj
Mąka
Dodaj
Cukier
Dodaj
Sól
…w wyniku którego
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
.NET Framework
System operacyjny
IIS
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
Cienki
klient
Warstwa prezentacji
(interfejs użytkownika)
Warstwa prezentacji
(interfejs użytkownika)
+
Warstwa przetwarzania
(logika biznesowa)
Warstwa przetwarzania
(logika biznesowa)
+
Warstwa zarządzania danymi
Warstwa zarządzania danymi
Gruby
klient
Przykładowa architektura systemu z ADO.NET
warstwa
prezentacji
Formularze
ASP.NET
warstwa logiki
biznesowej
Komponenty logiki
biznesowej
korzystające
z ADO.NET przy
dostępie do bazy
danych
warstwa
danych
SQL Server 2000
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.