Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

SYSTEMY BAZ DANYCH Część V Rozproszone i federacyjne bazy danych Opracowanie : Dr Bożena Śmiałkowska.

Podobne prezentacje


Prezentacja na temat: "SYSTEMY BAZ DANYCH Część V Rozproszone i federacyjne bazy danych Opracowanie : Dr Bożena Śmiałkowska."— Zapis prezentacji:

1 SYSTEMY BAZ DANYCH Część V Rozproszone i federacyjne bazy danych Opracowanie : Dr Bożena Śmiałkowska

2 Wprowadzenie do systemów rozproszonych

3 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.

4 Co to jest system rozproszony?

5 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 ataku 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.

6 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.

7 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.

8 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.

9 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.

10 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.

11 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 nieporównywalnie lepsza w stosunku do systemu scentralizowanego.

12 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.

13 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, itd.; patrz WWW.

14 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 komponentów systemu. Wybór dobrej architektury przesądza o spełnieniu kryterium jakości obsługi. Krytyczne zagadnienia projektowe dla systemów rozproszonych

15 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,...

16 Rozproszone a scentralizowane BD

17 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.

18 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.

19 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.

20 Klasyfikacja rozproszonych baz danych

21 Klasyfikacja rozproszonych baz danych cd.. Systemy wielu baz danych (multidatabases) Niefederacyjne rozproszone BD Rozproszone BD z globalnym schematem Jednorodne BD Federacyjne BD Słabo skojarzone (loosely coupled) Ściśle skojarzone (tightly coupled) Pojedyncze federacje (pojedynczy schemat) Wielokrotne federacje (wiele schematów) 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.

22 Postulaty rozproszenia BD

23 Komunikacja w rozproszonych BD

24 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).

25 Główne problemy rozproszonych baz danych Awarii, Aktualizacji wielu źródeł i ogniw rozproszonego środowiska, Odniesienia danych do tej samej skali czasu Wieloaspektowa niezgodność i konflikty między lokalnymi bazami danych z powodu:

26 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,...

27 Tematy związane z rozproszonymi BD cd.. Środki wspomagające rozproszenie bazy danych i rozproszone przetwarzanie zrealizowane w konkretnych systemach relacyjnych (Oracle, Sybase, Ingres, i inne), post-relacyjnych lub obiektowo- relacyjnych (Informix Universal Server, DB2 Universal Database, Oracle8, UniSQL/X, OSMOS, OpenIngres, Sybase Adaptive Server i inne) oraz obiektowych (Gemstone, Versant, O2, Objectivity/DB, ObjectStore i inne). Niezawodność, spójność, bezpieczeństwo i prywatność w rozproszonych bazach danych. Rozproszone bazy danych w sieciach Internet oraz Intranet. Rozproszenie danych i przetwarzania w systemach pracy grupowej oraz systemach zarządzania przepływem pracy.

28 Transakcje w rozproszonych BD

29 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.

30 Reguły rozproszenia

31 Replikacja

32 Fragmentaryzacja

33 Reguły rozproszonych baz danych (1) (C.J. 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 miejscu.

34 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 A 1...A m są w miejscu X, zaś atrybuty A m+1...A n są w miejscu Y, i konkretne zapytanie odwołuje się wyłącznie do atrybutów A 1...A m, 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.

35 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 powinno pracować na różnych platformach sprzętowych.

36 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.

37 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) z powodów biznesowych: centralne miejsce jest wygodne dla kontrolowania pozostałych miejsc.

38 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 tożsamości).

39 Pojęcia związane z rozproszeniem

40 Główne aspekty rozproszenia baz danych (1) Rozproszony SZBD powinien podtrzymywać rozproszenie danych przy założeniu odizolowania programisty/użytkownika od większości aspektów rozproszenia. 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) Przezroczystość (transparency) Współdziałanie (interoperability) Własność języka programowania i jego kompilatorów/interpreterów umożliwiająca przenoszenie programów na różne platformy. Przenaszalność (portability)

41 Główne aspekty rozproszenia baz danych (2) 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. 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ą. Autonomia (autonomy) Niezależność danych (data independence) 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. Ontologia (ontology), często w kontekście "ontologia biznesowa"

42 Przezroczystość (1) 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. 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:

43 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.

44 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.

45 Współdziałanie i heterogeniczność 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. interoperability, heterogeneity

46 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, semantyce, mechanizmom dostępu,...

47 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, cechy i funkcjonalności

48 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. 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).

49 Autonomia autonomy Autonomia lokalnej bazy danych w federacji baz danych oznacza, że: Możliwa jest pewna skala autonomii. Pojęcie autonomii jest raczej intuicyjne. 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. Federacja nie może żądać od lokalnej bazy danych zmiany/rozszerzenia jej usług (np. udostępnienia lokalnego dziennika transakcji).

50 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).

51 Ontologia 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. XML/RDF. ontology

52 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.

53 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 informacje, co redukuje znacznie objętość samych danych; Reprezentują wiedzę dziedzinową (ontologię); umożliwiają wnioskowanie o danych, mogą być przez to użyte do redukowania dostępu do samych danych.

54 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 danych.

55 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 protokołami, opartymi o różnorodne języki zapytań.

56 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: 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. 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

57 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.

58 Obiektowość w systemach rozproszonych

59 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?).

60 Źródła złożoności projektu oprogramowania Zespół projektantów podlegający ograniczeniom pamięci, percepcji, wyrażania informacji i komunikacji. Dziedzina problemowa, obejmująca ogromną liczbę wzajemnie uzależnionych aspektów i problemó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. Ś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. Potencjalni użytkownicy: czynniki psychologiczne, ergonomia, ograniczenia pamięci i percepcji, skłonność do błędów i nadużyć, tajność, prywatność. Potencjalni użytkownicy: czynniki psychologiczne, ergonomia, ograniczenia pamięci i percepcji, skłonność do błędów i nadużyć, tajność, prywatność.

61 Jak walczyć ze złożonością ? Zasada dekompozycji: rozdzielenie złożonego problemu na podproblemy, które można rozpatrywać i rozwiązywać niezależnie od siebie i niezależnie od całości. Zasada abstrakcji: eliminacja, ukrycie lub pominięcie mniej istotnych szczegółów rozważanego przedmiotu lub mniej istotnej informacji; wyodrębnianie cech wspólnych i niezmiennych dla pewnego zbioru bytów i wprowadzaniu pojęć lub symboli oznaczających takie cechy. Zasada ponownego użycia: wykorzystanie wcześniej wytworzonych schematów, metod, wzorców, komponentów projektu, komponentów oprogramowania, itd. Zasada sprzyjania naturalnym ludzkim własnościom: dopasowanie modeli pojęciowych i modeli realizacyjnych systemów do wrodzonych ludzkich własności psychologicznych, instynktów oraz mentalnych mechanizmów percepcji i rozumienia świata.

62 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.

63 Perspektywy w modelowaniu pojęciowym 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. odwzorowanie

64 Przykład: pojęciowy schemat obiektowy w UML Firma Nazwa Miejsce * Pracownik Zawód* Osoba Nazwisko Imię * Adres * Zatrudnienie Wypłata * Ocena * FZPZ 0..* 1 1 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?

65 Schemat relacyjny Firma(NrF, Nazwa) Lokal(NrF, Miejsce) Zatrudnienie(NrF, NrP) Pracownik(NrP, NrOs) Oceny(NrOceny, Ocena, NrF, NrP) Dochód ( NrDochodu, Wypłata, NrF, NrP) Osoba (NrOs, Nazwisko) Wyszkolenie (Zawód, NrP) Imiona (NrOs, Imię) Adresy (NrOs, Adres ) Jest to jedno z kilku możliwych rozwiązań. Schemat relacyjny jest trudniejszy do odczytania i zinterpretowania przez programistę. B ędzie on musiał co najmniej 10 minut zastanawiać się, co ten diagram reprezentuje i jaką semantykę mają atrybuty i zaznaczone powiązania. Efektem jest zwiększona skłonność do błędów (mylnych interpretacji).

66 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. 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

67 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. Niektóre z problemów mogą nie mieć ogólnego rozwiązania.

68 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.

69 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).

70 Projektowanie rozproszonych baz danych

71 Podejścia do projektowania rozproszonych BD: top-down i bottom-up top-down Od ogółu do szczegółów: 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. bottom-up

72 Projektowanie: podejście top-down Analiza Model pojęciowy scentralizowany Model logiczny scentralizowany Kryteria rozproszenia Modele logiczne dla poszczególnych miejsc Analiza systemowa: rozpoznanie wymagań, precyzowanie kontekstu przyszłej bazy danych. Projektowanie schematu pojęciowego Projektowanie struktury logicznej 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 także jak należy zdekomponować schemat logiczny na poszczególne miejsca

73 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.

74 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).

75 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.

76 Fragmentacja pionowa relacyjnej bazy danych DOSTAWCA_DANE DNR D1 D2 D3 D4 D5 NAZW Abacki Bober Czerny Dąbek Erbel STATUS DC DNR D1 D2 D3 D4 CNR C1 C2 C3 C4 C5 C6 C1 C2 C4 C5 ILOŚĆ Warszawa DOSTAWCA_MIASTO DNR D1 D2 D3 D4 D5 MIASTO Lublin Poznań Lublin Radom Gdańsk Kutno Sieć

77 Fragmentacja pozioma relacyjnej bazy danych DOSTAWCA DNR D2 D3 NAZW Bober Czerny STATUS MIASTO Poznań DC DNR D2 D3 CNR C1 C2 ILOŚĆ Poznań DOSTAWCA DNR D1 D4 NAZW Abacki Dąbek STATUS 20 MIASTO Lublin DC DNR D1 D4 CNR C6 C2 C4 ILOŚĆ Lublin DOSTAWCA DNR D5 NAZW Erbel STATUS 30 MIASTO Radom Sieć

78 Przykład fragmentacji poziomej Radom Klasa Pracownik Pracownik Nowak Pracownik Kowalski... Kielce Pracownik Malasa Pracownik Zagórny.... Sieć Kalisz Pracownik Styka Pracownik Malina... Klasa Pracownik Obiekty Pracownik są przechowywane zgodnie z geograficznym położeniem pracodawcy.

79 Fragmentacja pionowa obiektów Pracownik Radom Klasa danych osobistych Nowak dane osobiste Kowalski dane osobiste... Kalisz Klasa danych o ocenach Nowak dane o ocenach Kowalski dane o ocenach... Kraków Klasa danych o zatrudnieniu Nowak dane o zatrud. Kowalski dane o zatrud.... Sieć

80 Fragmentacja danych

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

82 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.

83 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.

84 Replikacja

85 Baza danych 1 Miejsce 1 Schemat lokalny 1 Aplikacje lokalne Baza danych 2 Miejsce 2 Schemat lokalny 2 Aplikacje lokalne Federacyjna BD tworzona metodą bottom-up Schemat federacyjnej bazy danych 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. Perspektywa Mediator Osłona Perspektywa Mediator Osłona Aplikacje globalne.....

86 Architektury rozproszonych baz danych

87 Architektura klient - serwer Serwer - komputer (proces) oferujący określony rodzaj usługi Klient - komputer (proces) korzystający z usługi Serwer Klient

88 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) 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. Określenie jednostki komunikacji klient - serwer Podział funkcji na te, które są wykonywane po stronie klienta i te, które są wykonywane po stronie serwera Podstawowe problemy:

89 Heterogeniczne środowisko w architekturze klient-serwer TCP/IP network Windows 95 Client Windows NT Client UNIX Client Windows 95 or NT Client Windows NT Server with repository on SQLserver UNIX Server with repository on Informix

90 Architektury serwerów w dostępie do bazy danych Serwer plików, Serwer SQL, Serwer obiektów, Serwer stron.

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

92 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)

93 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

94 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

95 Architektura z serwerem SQL Aplikacja klienta zadaje zapytanie SQL serwer Zapytanie SQL krotka Zarządzanie kursorem klient Maszyna SQL

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

97 Architektura serwera stron strony Zarządzanie zamkami Zarządzanie składem Zarządzanie kieszenią stron Obiektowa baza danych Aplikacja Przeglądarka obiektów Interfejs zapytaniowy Optymalizacja zapytań Interfejs programistyczny Zarządzanie obiektami Zarządzanie plikami i indeksami Zarządzanie kieszenią stron Przedmiotem zarządzania są fizyczne strony dyskowe

98 Architektura z serwerem obiektów Menadżer obiektów Aplikacja klient Pamięć podręczna obiektów Menadżer obiektów Menadżer dziennika blokowania Menadżer plików/indeksów Menadżer stron pamięci odręcznej Alokacja pamięci WE/WY Pamięć podręczna stron serwer obiekty

99 Architektura serwera obiektów obiekty Zarządzanie obiektami Optymalizacja zapytań Zarządzanie zamkami Zarządzanie składem Zarządzanie stronami i kieszeniami Obiektowa baza danych Aplikacja Przeglądarka obiektów Interfejs zapytaniowy Interfejs programistyczny Zarządzanie obiektami Przedmiotem zarządzania są obiekty

100 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 objętość dysku.

101 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.

102 Przykład architektury SZBD typu klient-serwer Aplikacja generująca transakcje Zarządzanie transakcjami Zarządzanie buforami Zarządzanie zasobami Klient 1 Aplikacja generująca transakcje Zarządzanie transakcjami Zarządzanie buforami Zarządzanie zasobami Klient n Zarządzanie siecią... Interfejs serwera Zarządzanie transakcjami Zarządzanie buforami Zarządzanie zasobami Serwer Zarządzanie logiem Zarządzanie zamkami

103 Architektura klient-(multi) serwer (1) s1 s2 s3 s4 k6 k5 k4 k3 k2 k1 k10 k9 k8 k7 k11 Połączenia bezpośrednie:

104 Architektura klient-(multi) serwer (2) s1 s2 s3 s4 k6 k5 k4 k3 k2 k1 k9 k8 k7 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. Sieć komputerowa

105 Architektura trzywarstwowa i wielowarstowa three-tier architecture Interfejs użytkownika Serwer bazy danych Serwer bazy danych multi-tier architecture Logika przetwarzania Architektura klient-serwer podzielona na trzy warstwy: interfejs użytkownika, logikę przetwarzania (reguły biznesu, logikę biznesu) 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 wielowarstwowa.

106 Logiczna architektura oprogramowania Architektura klient-serwer powinna odzwierciedlać logiczny podział oprogramowania na części. Nie jest to tak istotne w systemie scentralizowanym. Warstwa prezentacyjna (interfejs użytkownika) Warstwa prezentacyjna (interfejs użytkownika) Warstwa zarządzania bazą danych Architektura trójwarstwowa: Warstwa przetwarzania (logika biznesu) Warstwa przetwarzania (logika biznesu) 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 klient gruby klient

107 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.

108 Architektury dwuwarstwowe Uproszczone architektury trójwarstwowe z cienkim lub grubym klientem. Warstwa prezentacyjna (interfejs użytkownika) Warstwa prezentacyjna (interfejs użytkownika) Warstwa przetwarzania (logika biznesu) + Warstwa zarządzania bazą danych Warstwa przetwarzania (logika biznesu) + Warstwa zarządzania bazą danych cienki klient Warstwa prezentacyjna (interfejs użytkownika) + Warstwa przetwarzania (logika biznesu) Warstwa prezentacyjna (interfejs użytkownika) + Warstwa przetwarzania (logika biznesu) gruby klient Warstwa przetwarzania (logika biznesu) + Warstwa zarządzania bazą danych 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.

109 Bankomat Serwer kont klientów banku Monitor tele-przetwarzania Baza danych kont klientów banku 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 - sieć bankomatów

110 klient Serwer Web: generacja dynamicznych stron HTML dla klienta + zlecenia do bazy danych Serwer Web: generacja dynamicznych stron HTML dla klienta + zlecenia do bazy danych Serwer bazy danych: wykonywanie zapytań w SQL Serwer bazy danych: wykonywanie zapytań w SQL zapytania SQL wyniki zapytań SQL interakcja poprzez HTTP Przykład architektury K/S - portal WWW

111 3-warstwowa architektura aplikacji Web Przeglądarka Sieć Internet Baza danych Serwer bazy danych Serwer Web Serwer aplikacji Serwer HTTP

112 2-warstwowa architektura aplikacji Web Przeglądarka Sieć Internet Baza danych Serwer bazy danych Serwer Web Serwer aplikacji Serwer HTTP Wiele warstw pośredniczących powoduje dodatkowe obciążenie.

113 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ł.

114 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 przystosowuje konkretne miejsce do modelu przyjętego przez pośrednika.

115 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 serwer do klienta

116 Architektura klient-broker-serwer Host klienta Klient Wywołanie operacji Host serwera Obiekt Pośrednik (Broker) zlecenie wynik, parametry WY

117 Pośrednik... Szyna oprogramowania (software bus) Miejsce 1Miejsce 2Miejsce 3 Osłona 1 Osłona 2Osłona 3 Aplikacja napisana w C++ Aplikacja na relacyjnej bazie danych Aplikacja na Lotus Notes Architektura rozproszonych obiektów (2)

118 Operacje na obiektach Struktura logiczna rozproszonych obiektów O6 O5 O3 O2 O1 O4 O7 O8 O9 K1 K2 K3 K4 Obiekty 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. Szyna oprogramowania (software bus) A1A2A3 Aplikacje

119 Semistrukturalna architektura aplikacji internetowych Logiczna warstwa pośrednia Zasoby danych Warstwa klienta XML Przeglądarka WWW Przeglądarka WWW Narzędzia wspomagające XML : system autorski, itd. Serwer Web Serwer aplikacji Baza danych w XML (strukturalizowana) Interakcja z aplikacjami poprzez protokoły oparte na XML Obiektowo-relacyjna baza danych wspomagająca XML Obiektowa baza danych wspomagająca XML Zasoby danych pod OLE/DB Inne dokumenty na Webie: HTML Word,... Inne dokumenty na Webie: HTML Word,... Dokumenty XML na Webie Dokumenty XML na Webie Serwer integrujący XML, serwer zapytań, serwer hurtowni danych Translatory formatów z/do XML, pomosty XML

120 Standardy łączenia rozproszonych zasobów

121 Standardy łączenia rozproszonych danych (1) Open DataBase Connectivity (ODBC): standard [zdalnego] dostępu do relacyjnych baz danych bazuje na Call Level Interface (CLI) opracowanym przez konsorcjum X/Open definiuje API oraz cechy SQL które muszą być zapewnione na różnych poziomach zgodności. Java DataBase Connectivity (JDBC): analogiczny do ODBC standard dla Java. Standardy X/Open XA: definiują zarządzanie transakcjami ze wspomaganiem protokołu 2PC. OLE-DB: API podobne do ODBC, ale wspomagające źródła nie- bazodanowe, takie jak płaskie pliki. OLE-DB program może negocjować ze źródłem danych aby znaleźć własności, które ono podtrzymuje. API jest podzbiorem SQL

122 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)

123 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.

124 Replikacje

125 Technologia replikacji oznacza przechowywanie dwóch lub więcej kopii danych (replik) w oddalonych geograficznie miejscach. 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 Cele:

126 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.

127 Modele replikacji Jednoczesne aktualizacje ze sterowaniem współbieżnościa Propagacja aktualizacji Planowane odświeżanie kopii dla replik tylko do czytania Transakcja aktualizująca Replika 1Replika 2Replika 3 Replika 1 Replika 2 Replika 3 Replika 1 Replika 2 Replika 3 propagacja aktualizacji planowana aktualizacja Transakcja czytająca

128 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): Przy dokładnej analizie należy utworzyć bardziej złożone modele kosztów, które ustalą opłacalność replik. Wady replikacji Jeżeli ilość zapytań czytających ilość zleceń aktualizujących > ilość replik to warto tworzyć repliki. W przeciwnym przypadku - nie warto.

129 Przetwarzanie transakcji

130 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.

131 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) koniec czas zakładanie zamków (nie ma zwalniania) zwalnianie zamków (nie ma zakladania) 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.

132 Dwufazowe potwierdzenie (2PC) Koordynator (program aplikacyjny klienta) SZBD klienta 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. SZBD serwera gotów potwierdź

133 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 duże narzuty na wydajność aplikacji.

134 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 (1)

135 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.

136 Niezgodności schematów i ontologii

137 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? Niezgodności schematów 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. schematic discrepancies

138 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.

139 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.

140 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. Niezgodności jest bardzo dużo. Niezależnie zbudowane lokalne bazy danych zawsze będą obciążone tego rodzaju konfliktami.

141 Kanoniczny model danych 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ą? canonical data model 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.

142 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.

143 Federacyjne bazy danych

144 Co to jest Federacyjna Baza Danych? 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. Federated Database

145 ... Sieć komputerowa Architektura federacyjnej bazy danych Lokalny SZBD 1 Schemat eksportowy 1 Osłona 1 API 1 BD 1 Aplikacje lokalne FSZBD 1 Przestrzeń robocza Aplikacje globalne Schemat FBD Lokalny SZBD 2 Schemat eksportowy 2 Osłona 2 API 2 BD 2 Aplikacje lokalne Lokalny SZBD n Schemat eksportowy n Osłona n API n BD n Aplikacje lokalne FSZBD m Przestrzeń robocza Aplikacje globalne Schemat FBD...

146 Mediator OsłonaAPI Zewnętrzny podschemat 1 Zewnętrzny podschemat 3 Zewnętrzny podschemat 2 Interfejs IA 1 Interfejs IA 2 Interfejs IB 1 Perspektywa V 1 Perspektywa V 2 Obiekty A Dane A Interfejs IC 1 Ob.wirt. V 3 Dane wirt. V 2 Global schema (in an extended ODL) External sub-schemata (through an accessibility matrix) Dostęp Zakaz Użytkownik 1 Administrator lokalnej bazy danych Użytkownik 3 Użytkownik 2 Architektura dostępu do lokalnej BD Lokalna baza danychLokalny schemat eksportowy Zewnętrzne podschematy użytkowników (macierz dostępu) Obiekty A Dane B Obiekty A Dane C Ob.wirt. V 3 Dane wirt. V 1 ustala definiuje Zakaz

147 Trój-warstwowa architektura federacyjnej BD Użytkownik 1 Schemat zewnętrzny 1 Użytkownik 2 Schemat zewnętrzny 2 Użytkownik 3 Schemat zewnętrzny 3 FSZBD Przestrzeń robocza Schemat federacyjny Sieć Lokalny SZBD 1 Schemat eksportowy 1 Osłona 1 API 1 BD 1 Lokalny SZBD 2 Schemat eksportowy 2 Osłona 2 API 2 BD

148 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,...

149 Rozproszone BD w standardzie CORBA Oprogramowanie komponentowe budowane wg standardu CORBA może być podstawą rozproszonych/federacyjnych baz danych. Host globalnej aplikacji Klient Wywołanie operacji Host lokalnej BD Pośrednik (ORB, Object Request Broker) 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. Pieniek klienta Implementacja interfejsów do obiektów (szkielety + kod) zlecenie wynik, parametry wyj Obiekty

150 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ą realizowane.

151 Osłony i mediatory

152 Osłona 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 wrapper

153 Osłona udostępnia dane i usługi lokalnego systemu i (dostępne w pewnym API i) dla aplikacji globalnych (wykorzystujących wspólny API f). Osłony przystosowują lokalne SZBD do interfejsu programistycznego obowiązującego w federacji. Osłony w federacyjnych BD Federacyjny SZBD Lokalny SZBD 2 Osłona 2 API 2 Lokalny SZBD n Osłona n API nAPI 1 Lokalny SZBD 1 Osłona 1 API f...

154 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: Osłony dla lokalnych relacyjnych SZBD 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ą.

155 Mediatory 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: 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). mediator 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).

156 Perspektywy

157 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. Perspektywy 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. view, database view Podstawowe problemy:

158 Perspektywa jak schemat zewnętrzny Administrator BD Projektant BD Administrator BD Użytkownik 1Użytkownik 2Użytkownik 3 Schematy zewnętrzne 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. Schemat globalny Poziom fizyczny bazy danych Perspektywa 1Perspektywa 2Perspektywa 3 W tym sensie pojęcie perspektywy funkcjonuje w literaturze z zakresu modeli danych, analizy i projektowania. Architektura ANSI/SPARC:

159 Perspektywa jako odwzorowanie 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 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:

160 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ł.

161 Jak są widziane perspektywy w relacyjnych BD? Perspektywę wyznacza zapytanie, np. w SQL, plus drugorzędne środki syntaktyczne i semantyczne, takie jak zmiana nazw kolumn wirtualnych tablic. Po ewaluacji perspektywa zwraca tablicę, koncepcyjnie taka samą jak zapamiętane tablice. Popularną i efektywną techniką przetwarzania perspektyw jest nie ich ewaluacja (materializacja), lecz modyfikacja zapytań, traktująca perspektywę jako makro- definicję, oraz łączna optymalizacja tekstu zapytania z rozwiniętym tekstem definicji perspektywy. Aktualizacja perspektyw jest ograniczona do pionowego/poziomego obcięcia zapamiętanych tablic. Nie występują i nie są dyskutowane środki sterowania intencją aktualizacji perspektywy. Aktualizacja perspektyw odbywa się w tym samym języku, co ich definicja (SQL); nie jest rozważana (chociaż być może osiągalna) aktualizacja perspektyw z języków niższego poziomu (np. z C).

162 Perspektywy w relacyjnych bazach danych Perspektywę określa pewne zapytanie, np. SQL. Zdanie definiujące perspektywę określa nazwy atrybutów wirtualnej tabeli. CREATE VIEW Urzędnicy( Id_pracownika, Imię, Nazwisko, Zarobki ) AS SELECT Id_pracownika, Imię, Nazwisko, Zarobki FROM Pracownicy WHERE Stanowisko = urzędnik; Zapamiętana tabela: Pracownicy( Id_pracownika, Imię, Nazwisko, Stanowisko, Kierownik, Data_zatrudnienia, Zarobki, Premia, Id_działu ) Definicja perspektywy: 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.

163 Relacyjna baza danych z perspektywami SQL Użytkownik lub program aplikacyjny Dane zapamiętane (fizyczne) Tablica BD B1 Tablica BD B2 Tablica BD B3 Tablica BD B4 Dane rzeczywiste (logiczne) Dane wirtualne Perspektywa V1 Perspektywa V2

164 Przykład relacyjnej bazy danych DOSTAWCA CZĘŚĆ DNR D1 D2 D3 D4 D5 NAZW Abacki Bober Czerny Dąbek Erbel STATUS MIASTO Lublin Poznań Lublin Radom CNR C1 C2 C3 C4 C5 C6 MIASTO Lublin Poznań Rzeszów Lublin Poznań Lublin DC DNR D1 D2 D3 D4 CNR C1 C2 C3 C4 C5 C6 C1 C2 C4 C5 ILOŚĆ KOLOR Czarwony Zielony Niebieski Czerwony Niebieski Czerwony NAZWAC Nakrętka Wkręt Podkładka Nit Tulejka WAGA

165 Przykład bardziej złożonej perspektywy CREATE VIEW OcenaDostawcy( DNR, suma ) AS SELECT DNR, SUM( ILOŚĆ ) FROM DC GROUP BY DNR; Perspektywa OcenaDostawcy podaje numer dostawcy i sumę dostarczanych przez niego części. 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; DobryDostawca DNR D1 D2 D4 nazwisko Abacki Bober Dąbek status suma Rezultat: Wirtualna tabela o postaci: DROP VIEW DobryDostawca; - usunięcie perspektywy z bazy danych.

166 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.

167 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.

168 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. 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ż:

169 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. Baza danych Dane zapamiętane Perspektyw a Dane wirtualne Aktualizacja 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.

170 Przykład aktualizacji perspektyw (1) Dział Nazwa Pracownik Nazwisko Zarobek /MojeDziały Nazwa ŚredniZarobek Dane rzeczywisteDane wirtualne Podwyższ średni zarobek w dziale Krasnale ogrodowe o 500 zł: update MojeDziały set ŚredniZarobek = ŚredniZarobek 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. zatrudnia *

171 Przykład aktualizacji perspektyw (2) Dział Nazwa Pracownik Nazwisko Zarobek /MoiPracownicy Nazwisko NazwiskoSzefa Dane rzeczywisteDane wirtualne zatrudnia szef 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. * 0..1

172 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.

173 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; UPDATE MoiLudzie SET Zarobek = Zarobek WHERE NazwaDziału = Krasnale ogrodowe Podwyższyć o 500 zarobki wszystkim programistom z działu Krasnali ogrodowych: UPDATE MoiLudzie SET NazwaDziału = Lalki Barbie WHERE Nazwisko = Nowak Przenieść programistę Nowaka do działu Lalek Barbie: OK. Źle!

174 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 problem jest koncepcyjnie prostszy. Tych dwóch tematów nie należy mylić.

175 Klasyfikacja złożoności perspektyw Pozostałe kryteria klasyfikacyjne: generyczność, moc, stopień uwzględnienia pojęć modelu obiektowego, perspektywy rekurencyjne, perspektywy z parametrami, możliwości aktualizacji perspektyw, możliwości optymalizacji, itd. 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. Perspektywy z (trwałym) stanem, o pełnej mocy algorytmicznej. Wydajność?

176 Kryteria aktualizowalności perspektyw 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ę. 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.

177 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 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.

178 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. Aktualizacja perspektyw w relacyjnych BD

179 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, 45, 77, itd., gdzie 11 oznacza projektant, 45 oznacza analityk, 77 oznacza sprzątaczka, itd. Federacja wymaga pełnych nazw zawodów. Potrzebna jest dodatkowa funkcja, która zamieni numery na stringi. Definicja perspektywy musi więc zawierać definicję trwałej tabeli z numerami i stringami. Przykład 1: 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. Przykład 2: 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.

180 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.

181 Przykład modyfikacji i optymalizacji zapytania CREATE VIEW Urzędnicy( Id_pracownika, Imię, Nazwisko, Zarobki ) AS SELECT Id_pracownika, Imię, Nazwisko, Zarobki FROM Pracownicy WHERE Stanowisko = urzędnik; Definicja perspektywy: 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

182 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.

183 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.

184 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.

185 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).

186 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.

187 Podejścia do obiektowych perspektyw Podejście Abiteboula i Bonnera, Rundensteinter et al (MultiView), Kifera, Kima i Sagiva, Scholla et al (COOL/COCOON), LIVING IN A LATTICE, Edera 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.

188 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? Jaki jest stosunek takich procedur do standardowych mechanizmów ograniczenia dostępu do danych?

189 Przetwarzanie zapytań

190 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 celu skonstruowania ostatecznego wyniku zapytania.

191 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).

192 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 możliwość powstawania niespójności wskutek opóźnień lub braku możliwości aktualizacji indeksów straty przestrzeni dyskowej

193 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.

194 Statyczny schemat przetwarzania zapytań (2) Dekompozycja zapytania Z Serwer S1 Serwer S2 Serwer Sk Scalenie wyników... Klient Wynik W zapytania Z Z1 Z2 Zk W1 W2 Wk Statyczny schemat ma przede wszystkim zastosowanie w przypadku poziomej fragmentacji danych, np. rozbicia obiektów Pracownik na wiele podzbiorów o takiej samej budowie przechowywanych na poszczególnych serwerach. W tym przypadku dekompozycja zapytania oznacza po prostu jego skopiowanie: Z = Z1 = Z2 =... = Zk Scalenie wyników polega na sumie mnogościowej wyników cząstkowych.

195 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. Z Z1 Serwer S1 Serwer S2 Serwer S3 Scalenie wyników Klient Z1 Z2, F1 W1 W2 W3 (Z, W1) Z2, F1 (Z, W1, W2) Z3, F2 Z3, F2

196 Przykład: technika pół-złączeń (1) DOSTAWCA DNR D1 D2 D5 NAZW Abacki Bober Erbel STATUS MIASTO Lublin Poznań Radom DC DNR D1 D2 D3 D4 CNR C4 C5 C1 C2 C4 C5 ILOŚĆ Serwer 1Serwer 2 semijoin Klient ma dokonać złączenia relacji DOSTAWCA i relacji DC: select * from DOSTAWCA, DC where DOSTAWCA.DNR = DC.DNR

197 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. 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 DNR D1 D2 D5 F1 2. Tworzy pomocniczą tabelę poprzez projekcję W1 na DNR: tę tabelę nazywa F1. W1 DNR D1 D2 D5 NAZW Abacki Bober Erbel STATUS MIASTO Lublin Poznań Radom

198 Przykład: technika pół-złączeń (3) 4. Uzyska w ten sposób wynik W2: 5. Przesyła wynik W2 - pół-złączenie - do klienta 6. Klient dokonuje ostatecznego scalenia wyników - złączenia relacji W1 i W2. 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. CNR C4 C5 C1 C2 ILOŚĆ DNR D1 D2 NAZW Abacki Bober STATUS MIASTO Lublin Poznań Wynik DNR D1 D2 Jest to tzw. pół-złączenie relacji DC, parametryzowane relacją DOSTAWCA. Pół-złączenie relacji R1, parametryzowane relacją R2, powstaje poprzez złączenie R1 z R2, a następnie projekcję wyniku na atrybuty relacji R1 W2 CNR C4 C5 C1 C2 ILOŚĆ

199 Metody dostępu do baz danych sterowniki

200 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).

201 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.

202 Architektura ODBC

203 Schemat współpracy różnych narzędzi w architekturze Klient – Serwer w sieci LAN 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ń.

204 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ć.

205 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.

206 Przykład komponentów firmy Microsoft

207 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.

208 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…

209 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…

210

211 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 zapamiętanej procedury. Przykład komponentów firmy Microsoft – cd…

212 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…

213 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…

214 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…

215 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. Przykład komponentów firmy Microsoft – cd…

216 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. Dostęp w Jawie przez JDBC - sterownik

217 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

218 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: :. 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"; … con = DriverManager.getConnection(url); JDBC - sterownik –kolejność czynności

219 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…

220 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); }

221 JDBC - sterownik –kolejność czynności cd…

222 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))";

223 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..

224 // 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(); }

225 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(); }

226 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);

227 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(""); } }

228 Rozproszone bazy danych a technologie dostępu

229 Przykładowa architektura klient – serwer w PostgreSQL BAZA DANYCH KLIENT ODBC KLIENT POSTMASTER Połączenie Dostęp Linux UNIX KLIENT Połączenie Windows SERWER Wiele operacji dostępu jednocześnieWielu klientów

230 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

231 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://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

232 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

233 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)

234 Statyczny witryny internetowe w dostępie do źródeł danych Klient Serwer Strona HTML Zapytanie o stronę HTML Odpowiedź – strona HTML Serwer przetwarza żądanie Wykorzystanie dojrzałych protokołów TCP/IP Opracowanie podstawowych protokołów i standardów stron WWW (HTTP, URL, HTML/XHTML…) Brak większej interakcji pomiędzy serwerem WWW, a klientem Statyczna zawartość witryn

235 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.

236 ASP klasyczne – schemat działania Klient Serwer Skrypt ASP Zapytanie o stronę ASP Odpowiedź – strona HTML Strona HTML ASP.DLL 3

237 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 )

238 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

239 ADO.NET – warstwy dostępu do danych Kod aplikacji Dostawca.NET dla SQL Server Obiekt DataAdapter lub Command Obiekt Connection OLE DB Dostawca.NET dla OLE DB SQL Server Baza danych ODBC Dostawca.NET dla ODBC Baza danych Dostawca.NET dla Oracle Oracle

240 Architektura ADO.NET.NET Framework Data Provider Connection DataReader Command Transaction Parameters DataAdapter SelectCommand InsertCommand UpdateCommand DeleteCommand DataSet DataTableCollection DataTable DataRowCollection DataColumnCollection ConstraintCollection DataRelationCollection Baza danych XML

241 Architektura aplikacji baz danych

242 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

243 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)

244 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)

245 Kod źródłowy Kompilator Kod pośredni IL + metadane Kompilator kodu pośredniego CLR Kod natywny System operacyjny Kompilacja Wykonanie Komponent niezarządzany Model wykonawczy platformy.NET

246 C# VB C++ Python J# itd. Wspólna specyfikacja języków (CLS) Visual Studio.NET (lub inne IDE) Język pośredni (MSIL) Web services Strony ASP.NET Aplikacje ASP.NET Formularze Windows ADO.NET i XML Biblioteka podstawowa (BCL) Środowisko uruchomieniowe (CLR) System operacyjny Windows Architektura platformy.NET

247 Ś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)

248 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

249 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

250 Klasyfikacja typów.NET Typ Typy wartości Wbudowane typy wartości Typy wartości użytkownika Typy wyliczeniowe Typy referencyjne Typy wskaźnikowe Typy samoopisujące się Typy klas Typy użytkownika Typy spakowanych wartości Delegaty Typy tablic Typy interfejsów

251 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…)

252 . 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ść

253 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

254 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

255 Witaj Imię: Hasło: OK Class MojFormularz MojFormularz.aspx MojFormularz.aspx.cs MojFormularz Witaj Imię: Hasło: OK Te dwa pliki tworzą razem formularz internetowy Kod zakulisowy – web forms

256 Struktura ASP.NET web forms System.Web.UI.Page WebForm1.cs Klasa WebForm1 Projekt.dll WebForm1.aspx temporary.dll Strona HTML Projektowanie Wykonanie Dziedziczenie Kompilacja Dziedziczenie Wynik do przeglądarki lub urządzenia

257 Serwer wykonuje żądanie… Dodaj Mąka Cukier Sól Koszyk (Koszyk.aspx) Przeglądarka internetowa Dodaj Mąka Cukier Sól Koszyk (Koszyk.aspx.cs) Serwer ObsluzStrone(); PobierzWybProdukt(); DodajDoKoszyka(); StworzNowaStrone(); Odswiez(); Przycisk Dodaj wysyła żądanie na serwer… …w wyniku którego do przeglądarki wracana jest nowa strona Cykl życia formularza ASP.NET

258 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

259 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

260 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

261 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

262 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

263 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

264 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

265 Bezpieczeństwo aplikacji ASP.NET (c.d) Klient Aplikacja ASP.NET.NET Framework IIS System operacyjny Architektura ASP.NET

266 Optymalizacja ASP.NET Cztery podstawowe czynniki wydajnościowe: Czas wykonania (ang. execution time) Czas odpowiedzi (ang. response time) Skalowalność (ang. scalability) Przepustowość (ang. throughput)

267 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ść

268 Architektura systemu (c.d.) Warstwa prezentacji Warstwa przetwarzania Warstwa zarządzania danymi Warstwy programu użytkowego

269 Cienki klient Gruby klient Warstwa przetwarzania (logika biznesowa) + Warstwa zarządzania danymi Warstwa przetwarzania (logika biznesowa) + Warstwa zarządzania danymi Warstwa prezentacji (interfejs użytkownika) Warstwa prezentacji (interfejs użytkownika) Warstwa zarządzania danymi Warstwa prezentacji (interfejs użytkownika) + Warstwa przetwarzania (logika biznesowa) Warstwa prezentacji (interfejs użytkownika) + Warstwa przetwarzania (logika biznesowa) Architektura systemu (c.d.) Model klienta cienkiego i klienta grubego

270 Przykładowa architektura systemu z ADO.NET Formularze ASP.NET Formularze ASP.NET Komponenty logiki biznesowej korzystające z ADO.NET przy dostępie do bazy danych Komponenty logiki biznesowej korzystające z ADO.NET przy dostępie do bazy danych SQL Server 2000 warstwa prezentacji warstwa logiki biznesowej warstwa danych

271 Podsumowanie

272 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.

273 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.


Pobierz ppt "SYSTEMY BAZ DANYCH Część V Rozproszone i federacyjne bazy danych Opracowanie : Dr Bożena Śmiałkowska."

Podobne prezentacje


Reklamy Google