Rozproszone i federacyjne bazy danych

Rozproszone i federacyjne bazy danych

SYSTEMY BAZ DANYCH Cz V Rozproszone i federacyjne bazy danych Opracowanie : Dr Boena miakowska Wprowadzenie do systemw rozproszonych Co to jest system rozproszony? Systemem rozproszonym nazywamy taki system, w ktrym przetwarzanie informacji odbywa si na wielu komputerach, czsto znacznie oddalonych geograficznie (od kilku metrw do dziesitkw tysicy kilometrw). Przeciwiestwem jest system izolowany lub scentralizowany. Obecnie waciwie wszystkie systemy (poza domowymi komputerami) s rozproszone. Ogromnym katalizatorem rozproszenia systemw jest Internet. Komputer z Internetem mona ju uwaa za system rozproszony. Projektowanie i wasnoci systemw rozproszonych w duej mierze s takie same jak systemw scentralizowanych, ale istniej take istotne rnice, ktry specjalista inynierii oprogramowania musi by wiadomy. Tendencja do budowy systemw rozproszonych jest pochodn rozbudowy

tanich, szybkich, uniwersalnych i niezawodnych sieci komputerowych. Przykady systemw rozproszonych: sie bankomatw, system rezerwacji biletw, system pracy grupowej, itd. Co to jest system rozproszony? Cztery najwaniejsze problemy do rozwizania w systemach r.b.d. Przezroczysto (transparency): traktowanie rozproszonych zasobw i usug tak, jak gdyby byy one wewntrz przestrzeni adresowej jednego komputera. Bezpieczestwo: przeciwdziaanie losowym awariom oraz moliwociom atak z zewntrz. Interoperacyjno (interoperability): umoliwienie wsppracy heterogenicznych platform, aplikacji, logik biznesowych i organizacji danych. Efektywno: uzyskanie czasw przetwarzania akceptowalnych dla szerokiego krgu uytkownikw rozproszonych aplikacji. Przezroczysto Redukcja zoonoci przy pracy z rozproszonymi zasobami danych i usug, polegajca na uwolnieniu

programisty od mylenia na temat pooenia i organizacji rozproszonych danych. Przezroczysto ma bezporednie skutki dla czasu i kosztu wytworzenia rozproszonej aplikacji, jej przenaszalnoci i pielgnacyjnoci. Formy przezroczystoci (1) Przezroczysto pooenia i dostpu: Uwolnienie uytkownikw od koniecznoci korzystania z informacji o aktualnym pooeniu geograficznym danych i usug. Przezroczysto wspbienoci: Umoliwienie wielu uytkownikom jednoczesnego dostpu do danych i usug. Przezroczysto skalowania: Umoliwienie dodawania lub usuwania serwerw, danych i usug bez wpywu na dziaanie aplikacji i prac uytkownikw. Przezroczysto fragmentacji (podziau): automatyczne scalanie obiektw lub kolekcji, ktrych fragmenty s przechowywane w rnych miejscach. Formy przezroczystoci (2)

Przezroczysto replikacji: Umoliwienie tworzenia i usuwania kopii danych w innych miejscach geograficznych ze skutkiem dla efektywnoci przetwarzania. Przezroczysto awarii: Umoliwienie nieprzerwanej pracy wikszoci uytkownikw rozproszonej bazy danych w sytuacji, gdy niektre z jej wzw lub linie komunikacyjne ulegy awarii. Przezroczysto migracji: Umoliwienie przenoszenia zasobw danych do innych miejsc bez wpywu na prac uytkownikw. Interoperacyjno Krytyczny problem dla projektu bottom-up, czyli systemu integrujcego istniejce (spadkowe) niekompatybilne (heterogeniczne) dane i usugi. Interoperacyjno na poziomie transportu (transport-level interoperability) jako podstawa wyszych form interoperacyjnoci. Chodzi o umoliwienie fizycznej komunikacji pomidzy danymi i usugami, np. na gruncie TCP/IP, HTTP, wsplnej pamici, itp.

Interoperacyjno kontra przezroczysto Konieczno poszukiwania kompromisowych rozwiza na zasadzie tzw. wsplnego rozwizania. Moe by to atwe: Dla danej populacji serwerw istnieje prosty model kanoniczny powiza inter-operacyjnych w jedn przezroczyst cao. Moe to by trudne: Jeeli rozbienoci pomidzy serwerami s due, to informacja o zawartoci poszczeglnych serwerw musi by doprowadzona do programisty i do modelu kanonicznego. Jest to problem zoony i nieprzezroczysty. Zalety systemw rozproszonych cd.. Podzia zasobw: system rozproszony pozwala dzieli zasoby sprztowe i programowe (pamici dyskowe, drukarki, pliki, kompilatory, itd.) pomidzy wielu uytkownikw pracujcych na rnych komputerach pracujcych w sieci. Otwarto: jest ona definiowana jako zdolno systemu do doczania nowego sprztu, oprogramowania i usug. Otwarte systemy czsto maj t zdolno rwnie w stosunku do w/w zasobw ulokowanych na platformach sprztowych i systemach operacyjnych dostarczanych przez rnych dostawcw. Wspbieno: w systemie rozproszonym wiele procesw moe dziaa w tym samym czasie na rnych komputerach w sieci. Procesy te mog (jakkolwiek nie musz) komunikowa si podczas swego dziaania.

Skalowalno: Moc i moliwoci przetwarzania moe wzrasta w miar dodawania do systemu nowych zasobw, w szczeglnoci komputerw. W praktyce skalowalno jest czsto ograniczona poprzez przepustowo sieci oraz (niekiedy) poprzez np. specyficzne protokoy wymiany informacji. Niemniej skalowalno systemu rozproszonego jest nieporwnywalnie lepsza w stosunku do systemu scentralizowanego. Zalety systemw rozproszonych (2) Tolerancja bdw: Dostpno wielu komputerw oraz umoliwienie zdublowania informacji (replikacje) oznacza, e rozproszony system jest tolerancyjny w stosunku do pewnych bdw zarwno sprztowych jak i programowych. Np. awaria wza komunikacyjnego powoduje wygenerowanie innej trasy przepywu informacji. Przezroczysto: Oznacza ukrycie przed uytkownikiem szczegw rozproszenia, np. gdzie ulokowane s zasoby lub jak s one fizycznie zaimplementowane, pod jakim systemem pracuj, itd. Przezroczysto ma zasadnicze znaczenie dla komfortu dziaania uytkownika oraz dla niezawodnoci budowanego oprogramowania. Niekiedy, np. dla celw optymalizacyjnych, uytkownik moe zrezygnowa z penej przezroczystoci. Przykadem przezroczystoci jest Internet: klikajc w aktywne pole na stronie WWW nie interesujemy si, gdzie znajduje si odpowiadajca mu strona, oraz jak i na czym jest zaimplementowana.

Wady systemw rozproszonych Zoono: systemy rozproszone s trudniejsze do zaprogramowania i do administrowania ni systemy scentralizowane. Zale od wasnoci sieci, np. jej przepustowoci i czasu transmisji, co utrudnia zaprojektowanie i zrealizowanie wielu algorytmw i procesw przetwarzania. Ochrona: Dla systemu scentralizowanego wystarcza w zasadzie stranik z karabinem. System rozproszony nie moe by chroniony w ten sposb, przez co moe by naraony na rnorodne ataki (wamania, wirusy, sabota, odmowa patnoci, itd.) z wielu stron, ktre trudno zidentyfikowa. Zdolno do zarzdzania: jest ona utrudniona wskutek tego, e konsekwencje rnych dziaa administracyjnych w systemie rozproszonym s trudniejsze do zidentyfikowania. Podobnie z przyczynami sytuacji anormalnych, w szczeglnoci awarii. Nieprzewidywalno: system rozproszony jest nieprzewidywalny w swoim dziaaniu, poniewa zakcenia mog by powodowane przez wiele przyczyn: ma przepustowo i awari czy, awari komputerw, zbyt due obcienie danego serwera, lokalne decyzje administracji serwera, itd.; patrz WWW. Krytyczne zagadnienia projektowe dla systemw rozproszonych

Identyfikacja zasobw: zasoby w systemie rozproszonym s podzielone pomidzy wiele komputerw, w zwizku z czym schematy ich nazywania musz by zaprojektowane tak, aby uytkownicy mogli zidentyfikowa interesujce ich zasoby. Przykadem takiego schematu jest URL (Uniform Resource Locator) znany z WWW. Komunikacja: moe by zaprojektowana w sposb uniwersalny, na bazie np. protokou internetowego TCP/IP lub ktrego protokou pochodnego (ftp, http, itd.). Niektre wymagania dotyczce szybkoci, kosztu, niezawodnoci lub bezpieczestwa mog prowadzi do specjalnych technik komunikacyjnych. Jako obsugi: odzwierciedla wydajno systemu, jego dostpno i niezawodno. Podlega ona wielu czynnikom, w szczeglnoci, przypisaniu zada do procesorw, optymalnoci geograficznego podziau danych, itd. Architektura oprogramowania: opisuje ona w jaki sposb funkcjonalnoci systemu s przypisane do logicznych i fizycznych komponentw systemu. Wybr dobrej architektury przesdza o spenieniu kryterium jakoci obsugi. Popularne architektury rozproszenia Klient-serwer: rozproszony system ma wyrniony wze zwany serwerem, oraz szereg podczonych do niego wzw zwanych klientami. Zwizek nie jest symetryczny: serwer wykonuje usugi zlecane przez klientw, nie moe im odmwi i nie moe im zleci wykonanie usug.

Klient-multi-serwer: podobnie jak dla architektury klient-serwer, ale istnieje wiele serwerw. Przykadem jest WWW. Koleeska (peer-to-peer, P2P): wiele wzw wiadczy sobie wzajemne usugi poprzez bezporednie poczenie; nie ma wyranego podziau na usugodawcw i usugobiorcw. Przykadem jest Gnutella, NXOR, w mniejszym stopniu Napster ma centralne sterowanie. Komercyjny buzz dookoa P2P. Architektura oparta na oprogramowaniu poredniczcym (middleware): nie wystpuje podzia na klientw i serwery. Wzy komunikuj si poprzez specjalne oprogramowanie poredniczce, ktre zakada wsplny (przezroczysty dla uytkownikw) protok komunikacyjny. Przykadem jest CORBA (rozproszone obiekty), .NET/COM/DCOM, Java Beens/RMI, SOAP, ... Rozproszone a scentralizowane BD Co to jest rozproszona baza danych? distributed database Termin ten jest powtarzany w wielu kontekstach, czsto bez przypisywania mu konkretnego, technicznego znaczenia.

Czy to, e z pewnego systemu mona dosta si do danych innego odlegego systemu jest wystarczajcym wyrnikiem rozproszonej bazy danych? Dla wielu zastosowa cecha ta jest istotna, lecz Rozproszona baza danych musi spenia okrelone kryteria dotyczce spjnoci, bezpieczestwa, zintegrowania i wygody uytkownikw. Moliwo dostania si do danych innego systemu (np. poprzez pakiety oparte o standardy ODBC, JDBC, DCOM lub CORBA) oznacza wycznie ustanowienie niezbdnej bazy technicznej. Fakt ten nie przesdza jednak o tym, czy zachodz dostateczne warunki dla sprawnego, efektywnego oraz niezawodnego wykorzystywania danych. Podstawowe pojcia zwizane z rozproszeniem Rozproszona baza danych: zbir skadajcy si z wielu logicznie ze sob powizanych elementw bazy danych, oddalonych geograficznie i poczonych ze sob poprzez sie komputerow. System zarzdzania rozproszon baz danych (SZRBD): oprogramowanie umoliwiajce poczenie rozproszonych zasobw w jedn cao, utrzymanie spjno zasobw oraz udostpnianie ich uytkownikom przy zaoeniu przezroczystoci

rozproszenia. Dane s przechowywane w wielu miejscach - wzach sieci. Rozproszona baza danych jest baz danych, a nie kolekcj plikw, ktre mog by indywidualnie przechowywane w kadym wle sieci komputerowej. SZRBD posiada pen funkcjonalno systemu zarzdzania scentralizowan BD. Nie jest to system zarzdzania rozproszonymi plikami, ani te wycznie system przetwarzania transakcji. Przykad rozproszonej bazy danych Rozproszona baza danych dla linii lotniczych (biuro obsugi klienta w Warszawie moe dosta si do danych linii lotniczych w Sydney, Tokio, Paryu, i setkach innych miast). Jeeli w kadym miejscu organizacja bazy danych, rodki manipulacji, reguy dostpu, itd. byyby inne, to praca byaby bardzo utrudniona. Zatem konieczne standardys: w zakresie poczenia (protokoy), standardy w zakresie organizacji danych i dostpu do danych, moduy dla odwzorowania pewnej specyficznej bazy danych

na format oczekiwany przez danego klienta, przezroczysto rozproszenia (a la CORBA), zabezpieczenia przed niepowoanym dostpem. Klasyfikacja rozproszonych baz danych Klasyfikacja rozproszonych baz danych cd.. Systemy wielu baz danych (multidatabases) Niefederacyjne rozproszone BD Jednorodne BD Rozproszone BD z globalnym schematem Federacyjne BD Sabo skojarzone (loosely coupled)

cile skojarzone (tightly coupled) Pojedyncze federacje Sabo skojarzone FBD: brak federacyjnego schematu i (pojedynczy zarzdzania, operacje ad hoc, w zalenoci od aplikacji. schemat) Niefederacyjne BD: brak autonomii. cile skojarzone FBD: FSZBD jest odpowiedzialny za zarzdzanie caoci federacji. Wielokrotne federacje (wiele schematw) Postulaty rozproszenia BD Komunikacja w rozproszonych BD

Wane cechy rozproszonych BD Architektury rozproszonego przetwarzania: bazy danych oparte o architektur klient-serwer, bazy danych oparte o schemat globalny. Federacyjne bazy danych - (przezroczyste) poczenie wielu (relewantnych czci) heterogenicznych i autonomicznych baz danych w jedn cao. Przetwarzanie transakcji w rozproszonych bazach danych; globalne transakcje, lokalne transakcje, dwufazowe i trjfazowe potwierdzenie (two-phase commit, 2PC). Dugie transakcje, wymagajce osabienia poziomu izolacji i minimalizujce ryzyku utraty ju wykonanej pracy. Wspdziaanie heterogenicznych, autonomicznych, rozproszonych (Heterogeneous, Autonomous, Distributed, HAD) baz danych (okrelane take jako wspdziaanie multi baz danych, multidatabase interoperability). Gwne problemy rozproszonych baz danych Wieloaspektowa niezgodno i konflikty midzy lokalnymi bazami danych z powodu:

Awarii, Aktualizacji wielu rde i ogniw rozproszonego rodowiska, Odniesienia danych do tej samej skali czasu Tematy zwizane z rozproszonymi BD Replikacje, czyli utrzymywanie kopii danych w wielu miejscach w rozproszonych bazach danych. Rozproszone przetwarzanie zapyta; optymalizacja zapyta w sytuacji rozproszenia zasobw. Systemy operacyjne dla podtrzymywania rozproszenia: OSF DCE i inne systemy oparte o woanie odlegej procedury (Remote Procedure Call, RPC). Podtrzymywanie rnych form niewidocznoci rozproszenia (distribution transparency) dla programistw i klientw baz danych. Standardy w zakresie rozproszenia: OMG CORBA, DCOM firmy Microsoft, RMI i Java Beans, OpenDoc, ActiveX, SOAP/XML. Porednicy (broker, ORB) wg standardu CORBA, np. Orbix, Visibroker, ... Tematy zwizane z rozproszonymi BD cd.. rodki wspomagajce rozproszenie bazy danych i rozproszone

przetwarzanie zrealizowane w konkretnych systemach relacyjnych (Oracle, Sybase, Ingres, i inne), post-relacyjnych lub obiektoworelacyjnych (Informix Universal Server, DB2 Universal Database, Oracle8, UniSQL/X, OSMOS, OpenIngres, Sybase Adaptive Server i inne) oraz obiektowych (Gemstone, Versant, O2, Objectivity/DB, ObjectStore i inne). Niezawodno, spjno, bezpieczestwo i prywatno w rozproszonych bazach danych. Rozproszone bazy danych w sieciach Internet oraz Intranet. Rozproszenie danych i przetwarzania w systemach pracy grupowej oraz systemach zarzdzania przepywem pracy. Transakcje w rozproszonych BD Rozproszone BD: relacyjne czy obiektowe? Prace prowadzone nad rozproszonymi BD (w cigu ostatnich 20-tu lat), byy oparte gwnie o relacyjny model danych. Zaletami modelu relacyjnego jest prosta, ujednolicona struktura danych oraz prosta organizacja katalogw bazy danych. W ostatnich latach obserwuje si odchodzenie od modelu relacyjnego w stron modeli obiektowych. Zoono samego problemu rozproszenia danych jest prawdopodobnie niezalena od modelu danych.

Niektre metody systemw relacyjnych zwizane z rozproszeniem daj si przenie na grunt systemw obiektowych. Problemy nowe: metamodel (ontologia), przetwarzania zapyta. W przecigu najbliszych 10-ciu lat obiektowo bdzie odgrywa gwn rol w rozwijaniu koncepcji rozproszonych baz danych, w rnych wariantach, np. XML/RDF. Reguy rozproszenia Replikacja Fragmentaryzacja Reguy rozproszonych baz danych(C.J.(1) Date, 1987) 12 regu: w praktyce spenienie wszystkich jest trudne lub niemoliwe. Jest to spekulacyjny idea. Autonomia lokalnych BD: lokalne dane powinny podlega lokalnym reguom wasnoci i powinny by zarzdzane lokalnie. Dotyczy to funkcji zwizanych z bezpieczestwem, integralnoci i reprezentacj wewntrz pamici. Wyjtki dotycz sytuacji, kiedy wizy integralnoci musz obejmowa jednoczenie wiele miejsc oraz sytuacji, kiedy rozproszone

transakcje musz by sterowane przez pewne zewntrzne miejsce. Brak podporzdkowania przetwarzania do konkretnego miejsca: uniknicie wskich garde dziki decentralizacji wszystkich funkcji rozproszonego SZBD. Cigo funkcjonowania: Przestoje w wykonywaniu operacji nie powinny by skutkiem dodania nowych miejsc, ich usunicia ze rodowiska rozproszonej BD, dokonania zmian w meta-informacji lub unowoczenienia wersji SZBD w pewnym indywidualnym miejscu. Reguy rozproszonych baz danych (2) Niezaleno od lokalizacji: Uytkownicy lub programy aplikacyjne nie musz wiedzie, gdzie dane s fizycznie przechowywane. Niezaleno od fragmentacji: Fragmenty jednego zbioru danych mog by przechowywane i zarzdzane przez rozproszony SZBD jako jedna cao, bez uwiadamiania uytkownikw lub aplikacji o sposobie ich rozczonkowania. Podan wasnoci rozproszonego SZBD jest to, aby w sposb automatyczny unika przetwarzania nierelewantnych fragmentw. Np. jeeli grupa obiektw jest podzielona geograficznie ze wzgldu na atrybuty w ten sposb, e atrybuty A1...Am s w miejscu X, za atrybuty Am+1...An s w miejscu Y, i konkretne zapytanie odwouje si

wycznie do atrybutw A1...Am, naley pomin odwoania do miejsca Y podczas realizacji tego zapytania. Podobnie, fragmenty tej samej tabeli w rnych miejscach rozproszonej bazy danych powinny by widocznej jako jedna tabela. Reguy rozproszonych baz danych (3) Niezaleno od replikacji: Istnienie replik danych w wielu miejscach, ich pojawianie si lub usuwanie nie powinno wpywa na postpowanie uytkownikw ani na poprawno bd spjno aplikacji. Rozproszone przetwarzanie zapyta: System powinien zapewnia sprawne przetwarzanie rozproszonych zapyta umoliwiajce zredukowanie zarwno czasu przetwarzania, jak i obcienia sieci transmisji danych. Zarzdzanie rozproszonymi transakcjami: Zasady zarzdzania transakcjami oraz sterowania wspbienoci powinny obowizywa dla operacji w rozproszonej bazie danych. Zasady te wczaj: wykrywanie i usuwanie zakleszcze (deadlocks), zarzdzanie przekroczeniami dopuszczalnego czasu (timeout), rozproszone protoky potwierdzenia (commit) i odwracania (rollback), oraz inne metody. Niezaleno od sprztu: oprogramowanie rozproszonego SZBD powinno pracowa na rnych platformach sprztowych.

Reguy rozproszonych baz danych (4) Niezaleno od systemu operacyjnego: oprogramowanie rozproszonego SZBD powinno pracowa pod rnymi systemami operacyjnymi. Niezaleno od sieci: Miejsca mog by poczone poprzez szerok gam rodowisk sieciowych i komunikacyjnych. Modele warstwowe istniejce dla wspczesnych protokw komunikacyjnych (obowizujce w wikszoci obecnych systemw informacyjnych, takich jak OSI 7, TCP/IP, warstwy SNA i DECnet) zapewniaj rodki do osignicia tego celu nie tylko dla rozproszonych baz danych, lecz w oglnoci dla systemw informacyjnych. Niezaleno od SZBD: Powinno by moliwe przyczenie do rozproszonej bazy danych lokalnej bazy danych zarzdzanej przez dowolny lokalny SZBD. Regua: niezaleno od centralnego miejsca Rozproszona baza danych nie moe zalee od jednego, centralnego miejsca odpowiedzialnego za cao funkcjonowania. Zaleno taka moe "wkra si" niepostrzeenie, jako konsekwencja pewnych (wydawaoby si drugorzdnych) decyzji projektowych, np.

powoanie jednego serwera nazw, lub rejestracja nowych miejsc przyczajcych si do rozproszonej bazy danych. Zaleno taka jest niekorzystna, gdy: Centralne miejsce moe sta si wskim gardem dla operacji na danych Awaria centralnego miejsca powoduje awari caej rozproszonej bazy danych. Dla niektrych zastosowa brak centralnego miejsca jest niekorzystny: z powodu nadmiernego wzrostu obcienia sieci zwizanego z wymian metadanych; z powodu zbyt niskiej wydajnoci (indeksy w jednym miejscu) z powodw biznesowych: centralne miejsce jest wygodne dla kontrolowania pozostaych miejsc. Nazwy elementw danych w rozproszonych BD Problem nazywania i identyfikacji danych w rozproszonych BD staje si znacznie bardziej trudny ni w scentralizowanych BD. Kryteria zarzdzania nazwami: 1. Kada dana, ktra ma by niezalenie 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. Kade lokalne miejsce w rozproszonej BD powinno powinno mie moliwo autonomicznego nadawania unikalnych nazw dla danych. Centralny serwer nazw - nadaje wszystkie nazwy, udziela informacji o lokalizacji nielokalnych danych na podstawie ich nazw: nie spenia warunku 4, moe powodowa wskie gardo dla transakcji, jest pojedynczym powodem awarii caoci. Rozwizanie: prefiksowanie nazwy identyfikatorem miejsca - trudnoci ze zmian lokalizacji danych (przy zachowaniu tosamoci). Pojcia zwizane z rozproszeniem Gwne aspekty rozproszenia baz danych (1) rzezroczysto (transparency) Rozproszony

SZBD powinien podtrzymywa rozproszenie danych przy zaoeniu odizolowania programisty/uytkownika od wikszoci aspektw rozproszenia. Wspdziaanie (interoperability) Oznacza wspprac zbudowanych niezalenie od siebie heterogenicznych systemw (heterogeneous systems). Aspektem wspdziaania jest przyczenie do rozproszonej BD starych systemw, tzw. spadkowych (legacy) rzenaszalno (portability) Wasno jzyka programowania i jego kompilatorw/interpreterw

umoliwiajca przenoszenie programw na rne platformy. Gwne aspekty rozproszenia baz danych (2) Autonomia (autonomy) Lokalne bazy danych podlegaj wasnym lokalnym reguom. Tylko okrelona cz lokalnych zasobw i usug jest udostpniana na zewntrz. ezaleno danych (data independence) Moliwo projektowania, utrzymywania, udostpniania, zmiany nonikw, zmiany reprezentacji, itp. dziaa na danych niezalenie od programw, ktre na nich operuj. ologia (ontology), czsto w kontekcie "ontologia biznesowa" Formalny opis wszystkich tych wasnoci lokalnej bazy danych, ktre s niezbdne do tego, aby projektant/programista mg prawidowo zaprogramowa now aplikacj (np. mobilnego agenta). Niekiedy ontologia jest okrelana jako metadane. Przezroczysto (1) Rozproszona BD musi spenia warunki komfortu pracy

programistw, administratorw i uytkownikw, jak rwnie niezawodnoci, bezpieczestwa danych, zwikszenie odpornoci na bdy programistw. To oznacza konieczno redukcji zoonoci przy pracy z rozproszon baz danych, co jest okrelane jako przezroczysto. Ma ona nastpujce formy: Przezroczysto pooenia: Umoliwienie jednorodnych metod operowania na lokalnych i odlegych danych. Tego warunku nie spenia np. system, w ktrym lokalna baza danych jest obsugiwana przez pewien jzyk 4GL, za odlega - przez specjalny zestaw procedur (API). Przezroczysto dostpu: Uwolnienie uytkownikw od koniecznoci(a niekiedy rwnie uniemoliwienie) korzystania z informacji o aktualnym pooeniu danych. Przezroczysto (2) Przezroczysto wspbienoci: Umoliwia wielu uytkownikom jednoczesny dostp do danych bez koniecznoci uzgodnie i porozumiewania si, przy zapewnieniu penej spjnoci danych i przetwarzania. Przezroczysto skalowania: Umoliwienie dodawania nowych elementw bazy danych bez wpywu na dziaanie starych aplikacji i

prac uytkownikw. Przezroczysto replikacji: Umoliwienie tworzenia i usuwania kopii danych w innych miejscach geograficznych z bezporednim skutkiem dla efektywnoci przetwarzania, ale bez skutkw dla postaci programw uytkowych lub pracy uytkownika kocowego. Przezroczysto wydajnoci: Umoliwienie dodawania nowych elementw systemu komputerowego (np. serwerw, dyskw) bez wpywu na prac wikszoci uytkownikw rozproszonej bazy danych. Przezroczysto (3) Przezroczysto fragmentacji (podziau): automatyczne scalanie obiektw, tabel lub kolekcji, ktrych fragmenty s przechowywane w rnych miejscach. Przezroczysto awarii: Umoliwienie nieprzerwanej pracy wikszoci uytkownikw rozproszonej bazy danych w sytuacji, gdy niektre z jej wzw lub linie komunikacyjne ulegy awarii. Przezroczysto migracji: Umoliwienie przenoszenia zasobw danych do innych miejsc bez wpywu na prac uytkownikw. W praktyce spenienie wszystkich wymienionych warunkw jest ideaem, ktry prawdopodobnie nie zosta

zrealizowany w adnym ze znanych systemw. Wspdziaanie i heterogeniczno interoperability, heterogeneity Umoliwienie wspdziaania heterogenicznych systemw baz danych jest drugim wanym aspektem rozproszenia. Heterogeniczno jest nieodczn cech duych sieci komputerowych, takich jak Internet, WWW, sieci intranetowych, rozproszonych baz danych, systemw przepywu prac, zasobw WWW opartych na plikach HTML i XML, itd. Heterogeniczno (niejednorodno) Np. system Intranetowy moe skada si ze sprztu:

komputerw klasy mainframe stacji roboczych UNIX komputerw PC pracujcych pod MS Windows komputerw Apple Macintosh central telefonicznych, robotw, zautomatyzowanych linii produkcyjnych ...wcza rnorodne protokoy komunikacyjne: Ethernet, FDDI, ATM, TCP/IP, Novell Netware, protokoy oparte na RPC,... ...bazowa na rnych systemach zarzdzania baz danych/ dokumentw: Oracle,SQL Server, DB2, Lotus Notes,.... ...oraz wymienia pomidzy sob niejednorodne dane, podlegajce rnym modelom danych, schematom, semantyce, mechanizmom dostpu,... Przyczyny heterogenicznoci Niezaleno dziaania: wytwrcy systemw nie uzgadniaj midzy sob ich cech. Standardy, o ile si pojawiaj, s spnione, niekompletne i nie przestrzegane w 100%. Konkurencja: wytwrcy systemw staraj si wyposay systemy w atrakcyjne cechy, ktrych nie posiadaj konkurujce systemy Rnorodno pomysw: Nie zdarza si, aby byo jedno rozwizanie dla zoonego problemu. Rne zespoy znajduj rne rozwizania, bazujce

czsto na odmiennych celach i zaoeniach. Efektywno finansowa i kompromisy: Wytwrcy oferuj produkty o rnej cenie, funkcjonalnoci i jakoci, zgodnie z wyczuciem potencjalnych potrzeb klientw, dostosowaniem si do ich portfela i maksymalizacj swoich zyskw. Systemy spadkowe (legacy): Systemy, ktre dawno zostay wdroone i dziaaj efektywnie, nie mog by z tego dziaania wyczone. Nie jest moliwe (lub jest bardzo kosztowne) zastpienie ich nowymi systemami. Nowe systemy, o podobnym przeznaczeniu, posiadaj inne zaoenia, cechy i funkcjonalnoci Przenaszalno portability Typy przenaszalnoci: Na poziomie skadni, koncepcji jzyka i edukacji (np. SQL-92). Na poziomie kodu rdowego (np. C++ (?), JDBC). Na poziomie interpretowanego kodu skryptowego lub poredniego (np. Java). Na poziomie kodu binarnego (? - trudno poda przykad). Przenaszalno wymaga precyzyjnej specyfikacji skadni i semantyki jzyka, oraz wyeliminowania z niego wasnoci specyficznych dla poszczeglnych platform.

Wiele standardw nie spenia kryterium przenaszalnoci z powodu niedospecyfikowania i/lub nie speniania standardu przez wytwrcw systemw. Przenaszalno jest celem standardw SQL, CORBA oraz ODMG, niekoniecznie celem ju osignitym. Przenaszalno realizuje kod poredni jzyka Java, ale dotyczy to funkcjonalnoci niskiego poziomu, np. nie dotyczy API do baz danych. Autonomia autonomy Autonomia lokalnej bazy danych w federacji baz danych oznacza, e: Lokalne dane podlegaj lokalnym priorytetom, reguom wasnoci, autoryzacji dostpu, bezpieczestwa, itd. Lokalna baza danych moe odrzuci zlecenia przychodzce z federacji, o ile naruszaj one lokalne ograniczenia lub zbytnio obciaj czas procesora lub inne lokalne zasoby. Lokalna baza danych moe udostpnia aplikacjom dziaajcym na federacji baz danych tylko okrelon cz swoich danych i usug. Programici tych aplikacji nie maj jakichkolwiek rodkw dostpu do pozostaych danych i usug. Wczenie lokalnej bazy danych do federacji nie moe powodowa

koniecznoci zmiany programw aplikacyjnych dziaajcych na lokalnej BD. Federacja moe przetwarza lokalne zasoby tylko poprzez interfejs programowania aplikacji (API) specyficzny dla lokalnego systemu. Inne metody (np. bezporedni dostp do plikw) s niedozwolone. Federacja nie moe da od lokalnej bazy danych zmiany/rozszerzenia jej usug (np. udostpnienia lokalnego dziennika transakcji). Moliwa jest pewna skala autonomii. Pojcie autonomii jest raczej intuicyjne. Niezaleno danych data independence Oznacza, e nie ma potrzeby zmiany kodu programw aplikacyjnych mimo zmian organizacji lub schematw danych. Jest osigana poprzez interfejsy programistyczne umoliwiajce dostp do danych na odpowiednim poziomie abstrakcji, gdy niewidoczne s szczegy organizacji i implementacji danych. Fizyczna niezaleno danych: ukrycie detali organizacji fizycznej i technik dostpu, dziki czemu moliwa jest ich zmiana bez wpywu na kod aplikacji. Logiczna niezaleno danych: umoliwienie niektrych zmian schematu logicznego bez wpywu na kod aplikacji, np. dodanie atrybutw do relacji, zmiana kolejnoci atrybutw, zmiana ich typw,

utworzenie nowych relacji, itd. Ewolucja schematu (schema evolution): umoliwienie daleko idcych zmian schematu danych przy jednoczesnym utworzeniu perspektyw (views) dla starych lub nowych danych. Perspektywy maj umoliwi minimaln pracochonno przy zmianach aplikacji (idealistycznie). Ontologia ontology W filozofii: nauka o bytach, teoria bytu, opis charakteru i struktury rzeczywistoci, specyfikacja konceptualizacji. W sztucznej inteligencji: formalna specyfikacja (przy uyciu logiki matematycznej) obiektw, poj i innych bytw, ktre istniej w pewnej dziedzinie, oraz formalna specyfikacja zwizkw, ktre pomidzy tymi bytami zachodz. Podejcie sztucznej inteligencji jest naiwne. Np. Gieda Papierw Wartociowych: wiele tysicy stron aktw prawnych, zarzdze, regulacji, itd. Jako (doywotnia) kara dla sztucznego (wier-) inteligenta wypisujcego bzdury na temat "formalnej ontologii": niech to zapisze przy uyciu formu rachunku predykatw.

W biznesie (ontologia biznesowa, business ontology): wszystko to, co projektanci systemw informatycznych powinni wiedzie o biznesie, aby poprawnie napisa aplikacje wspomagajce ten biznes. Wiedza ta powinna by formalnie zapisana. "Formalnie" oznacza zwykle pewien standardowy i uzgodniony jzyk, np. XML/RDF. Ontologia i metadane Gwnym celem prac na biznesow ontologi jest standardyzacja nastpujcych elementw: Gramatyki opisw poszczeglnych bytw, Nazw i znacze nazw obowizujcych w ramach danego biznesu (np. co oznaczaj sowa "autor", "klient", "instrument", "akcja", itd.), Ogranicze zwizanych z opisywanymi bytami, Metadanych zwizanych 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 ktre ustala si zarwno struktur samej bazy danych, jak i pewne dodatkowe informacje (meta-atrybuty) bdce podstaw przetwarzania bazy danych. Nieco inne podejcie prezentuje standard RDF opracowany przez W3C, gdzie ontologi reprezentuj wyraenia RDF.

Metadane Metadane s kluczowe dla wielu rozproszonych aplikacji, poniewa umoliwiaj rozpoznanie z zewntrz wasnoci lokalnego zasobu danych Oglna definicja: s to dane o danych - co dane zawieraj, jak maj budow, jakie jest ich znaczenie, jakim podlegaj ograniczeniom, jak s zorganizowane, przechowywane, zabezpieczane, udostpniane, itd. Metadane s pewnym rozszerzeniem pojcia schematu bazy danych, albo te pewn implementacj tego schematu w postaci katalogw. Metadane przykrywaj take informacj niezalen od treci samych danych, np. kiedy pewna dana zostaa utworzona, w jakim jest formacie, kto jest jej autorem, do kiedy jest wana, itd. Opisy danych zawarte w metadanych maj dwie podstawowe zalety: Zawieraj wsplne abstrakcje dotyczce reprezentacji danych, takie jak format; oglnie "wycigaj przed nawias" wszystkie wsplne informacje, co redukuje znacznie objto samych danych; Reprezentuj wiedz dziedzinow (ontologi); umoliwiaj wnioskowanie o danych, mog by przez to uyte do redukowania dostpu do samych danych. Klasyfikacja metadanych Metadane niezalene od treci danych: lokacja danych, data

modyfikacji, typ kamery sucej do sporzdzenia zdjcia, itd. Mimo, e nie skadaj si bezporednio na tre danych, mog by wanym kryterium wyszukiwania. Metadane zalene od treci danych: rozmiar dokumentu, liczba kolorw, liczba wierszy, liczba kolumn w tabeli. Metadane zalene od treci mog by dalej podzielone na: Bezporednie metadane dotyczce treci, np. indeksy, klasyfikacje, itd. Metadane opisujce tre: adnotacje o zawartoci zdjcia, np. opis zapachu kwiatu przedstawionego na zdjciu. Metadane niezalene od dziedziny biznesowej, ktrej dotyczy tre, np. definicje typu dokumentu HTML/SGML Metadane zalene od dziedziny biznesowej, np. schemat danych lub opis ontologii biznesowej Podzia na dane i metadane nie jest do koca jasny i silnie zaley od nastawienia projektanta i podziau zada podczas redakcji treci danych. Protok wymiany informacji w rozproszonej BD Protok wymiany informacji pomidzy rozproszonymi miejscami musi uwzgldnia:

przesyanie danych z jednego miejsca do drugiego miejsca przesyanie zlece (np. zapyta) do odlegych miejsc celem przetwarzania danych zwrotne przesyanie wynikw tych zlece do zlecajcego klienta automatyczn dystrybucj niektrych metadanych (np. schematu BD) pomidzy uczestnikw rozproszonej bazy danych. przesyanie zapyta dotyczcych metadanych przekazywanie wynikw zapyta dotyczcych metadanych do pytajcego Aktualnie, protokoy takie istniej w bardzo uproszczonej lub silnie wyspecjalizowanej formie IIOP (Internet Inter-Orb Protocol) - bardzo uproszczony LDAP (Lightweight Directory Access Protocol) - silnie wyspecjalizowany Wiele orodkw prowadzi prace badawcze nad uniwersalnymi protokoami, opartymi o rnorodne jzyki zapyta. Migracje obiektw Migracja: przemieszczanie si obiektw midzy wzami sieci, przy czym obiekty musz by skojarzone (statycznie lub dynamicznie zwizane) ze swoimi klasami i przechowywanymi w ramach tych klas metodami. Problemy:

Okrelenie jednostki migracji ledzenie obiektw Utrzymywania porzdku w katalogu systemu bazy danych Okresowa kondensacja acuchw obiektw porednich Przemieszczanie obiektw zoonych Zapewnienie globalnej przestrzeni nazw Zapewnienie waciwych mechanizmw zakresu i wizania Dostpno metod umoliwiajcych przetwarzanie obiektw Jak dotd, metody s najczciej skadowymi aplikacji, a nie bazy danych. Konsekwencj jest to, e po przemieszczeniu obiektu aplikacja dziaajca w jego nowym miejscu musi mie wbudowane (powielone, skompilowane, zlinkowane) metody do jego przetwarzania. Oprogramowanie komponentowe Komercyjny buzzword, niezrealizowane marzenie informatykw od 30 lat. Oznacza technologie zmierzajce do budowy standardw oraz wspomagajcego je oprogramowania, ktre pozwolioby na skadanie duych aplikacji lub systemw z mniejszych standardowych czci - komponentw, na zasadzie podobnej do skadania komputera z podzespow.

Inneprzykady terminy: mega-programming, programming-in-the-large. Jako komponentowego podejcia wymienia si: OMG CORBA, OpenDoc firm Apple, IBM i innych, technologia .NET/COM/DCOM, Java Beans i Enterprise Java Beans. Komponenty odnosz wiele sukcesw. Istniej jednak problemy utrudniajce szerokie ich stosowanie, tj: problemy z osigniciem akceptowalnej wydajnoci, trudnoci w precyzyjnym a jednoczenie dostatecznie abstrakcyjnym wyspecyfikowaniu interfejsw pomidzy komponentami, dynamiczny postp w informatyce, powodujcy pojawianie si coraz to nowych wymaga na interfejsy. Obiektowo w systemach rozproszonych

Obiektowo w rozproszonych bazach danych Obiektowo zakada zwikszenie stopnia abstrakcji, przystosowanie modeli realizacyjnych systemw informatycznych do naturalnych konstrukcji i obrazw mylowych projektantw, programistw i uytkownikw. Gwny problem - opanowanie zoonoci przy wytwarzaniu oprogramowania. Punktem zainteresowania twrcw narzdzi informatycznych staj si procesy mylowe zachodzce w umysach osb pracujcych nad oprogramowaniem => modelowanie pojciowe. Obiektowo przerzuca ciar problemu z kwestii narzdziowej (jak mam to zrobi?) na kwesti merytoryczn (co mam zrobi i po co?). rda zoonoci projektu oprogramowania Zesp Zespprojektantw projektantw

Dziedzina Dziedzinaproblemowa, problemowa, obejmujca obejmujcaogromn ogromnliczb liczb wzajemnie wzajemnieuzalenionych uzalenionych aspektw aspektwi iproblemw. problemw. rodki rodkii itechnologie technologie informatyczne: informatyczne: sprzt,

sprzt,oprogramowanie, oprogramowanie,sie, sie, jzyki, narzdzia, udogodnienia. jzyki, narzdzia, udogodnienia. Oprogramowanie: decyzje strategiczne, analiza, projektowanie, konstrukcja, dokumentacja, wdroenie, szkolenie, eksploatacja, pielgnacja, modyfikacja. podlegajcy podlegajcyograniczeniom

ograniczeniom pamici, pamici,percepcji, percepcji,wyraania wyraania informacji informacjii ikomunikacji. komunikacji. Potencjalni Potencjalniuytkownicy: uytkownicy: czynniki czynnikipsychologiczne, psychologiczne, ergonomia, ergonomia,ograniczenia ograniczeniapamici pamici i ipercepcji, percepcji,skonno

skonnodo do bdw bdw i inaduy, tajno, prywatno. naduy, tajno, prywatno. Jak walczy ze zoonoci ? Zasada dekompozycji: rozdzielenie zoonego problemu na podproblemy, ktre mona rozpatrywa i rozwizywa niezalenie od siebie i niezalenie od caoci. Zasada abstrakcji: eliminacja, ukrycie lub pominicie mniej istotnych szczegw rozwaanego przedmiotu lub mniej istotnej informacji; wyodrbnianie cech wsplnych i niezmiennych dla pewnego zbioru bytw i wprowadzaniu poj lub symboli oznaczajcych takie cechy. Zasada ponownego uycia: wykorzystanie wczeniej wytworzonych schematw, metod, komponentw projektu, komponentw oprogramowania, itd.

wzorcw, Zasada sprzyjania naturalnym ludzkim wasnociom: dopasowanie modeli pojciowych i modeli realizacyjnych systemw do wrodzonych ludzkich wasnoci psychologicznych, instynktw oraz mentalnych mechanizmw percepcji i rozumienia wiata. Modelowanie pojciowe Projektant i programista musz dokadnie wyobrazi sobie problem oraz metod jego rozwizania. Zasadnicze procesy tworzenia oprogramowania zachodz w ludzkim umyle i nie s zwizane z jakimkolwiek jzykiem programowania. Pojcia modelowania pojciowego (conceptual modeling) oraz modelu pojciowego (conceptual model) odnosz si procesw mylowych i wyobrae towarzyszcych pracy nad oprogramowaniem.

Modelowanie pojciowe jest wspomagane przez rodki wzmacniajce ludzk pami i wyobrani. Su one do przedstawienia rzeczywistoci opisywanej przez dane, procesw zachodzcych w rzeczywistoci, struktur danych oraz programw skadajcych si na konstrukcj systemu. Perspektywy w modelowaniu pojciowym odwzorowanie odwzorowanie ... ... ...... ... ...... ... Percepcja rzeczywistego wiata Analityczny model

rzeczywistoci ... ... ... ... ... ... ... ... ... ... Model struktur danych i procesw SI Trwa tendencj w rozwoju metod i narzdzi projektowania oraz konstrukcji SI jest denie do minimalizacji luki pomidzy myleniem o rzeczywistym problemie a myleniem o danych i procesach zachodzcych na danych. Przykad: pojciowy schemat obiektowy w UML Osoba Nazwisko Imi *

Adres * Pracownik Zawd * 0..* PZ 1 Zatrudnienie Wypata * 0..* Ocena * FZ Firma Nazwa 1 Miejsce * Nie wicej ni 10 sekund zastanawiania si, co ten diagram przedstawia i jak jest semantyka jego elementw.

Potem mona ju programowa np. w C++ lub Java. Co otrzymamy po odwzorowaniu tego schematu na schemat relacyjny? Schemat relacyjny Firma(NrF, Nazwa) Zatrudnienie(NrF, NrP) Lokal(NrF, Miejsce) Pracownik(NrP, NrOs) Oceny(NrOceny, Ocena, NrF, NrP) Dochd(NrDochodu, Wypata, NrF, NrP) Osoba(NrOs, Nazwisko) Wyszkolenie(Zawd, NrP) Imiona(NrOs, Imi) Adresy(NrOs, Adres) Jest to jedno z kilku moliwych rozwiza.

Schemat relacyjny jest trudniejszy do odczytania i zinterpretowania przez programist. Bdzie on musia co najmniej 10 minut zastanawia si, co ten diagram reprezentuje i jak semantyk maj atrybuty i zaznaczone powizania. Efektem jest zwikszona skonno do bdw (mylnych interpretacji). Skutki niezgodnoci modelu pojciowego i relacyjnego Programy odwoujce si do schematu relacyjnego s dusze od programw odwoujcych si do schematu obiektowego (szacunkowo od 30% do 70%). Ma to ogromne znaczenie dla tempa tworzenia oprogramowania, jego jakoci, pielgnacyjnoci, itd. Programy te s te zwykle znacznie wolniejsze. Mini przykad: Podaj adresy pracownikw pracujcych w firmach zlokalizowanych w Radomiu SBQL: (Firma where Radom in Miejsce).FZ.Zatrudnienie.PZ.Pracownik.Adres SQL: select a.Adres from Lokal as k, Zatrudnienie as z, Pracownik as p, Osoba as s, Adresy as a where k.Miejsce = Radom and k.NrF = z.NrF and z.NrP = p.NrP and p.NrOs = s.NrOs and s.NrOs =a.NrOs Zapytanie w SQL jest znacznie dusze wskutek tego, e w SQL konieczne s

zczeniowe predykaty (takie jak k.NrF=z.NrF i nastpne) kojarzce informacj semantyczn "zgubion" w relacyjnej strukturze danych. Rozproszone obiektowe bazy danych Problemy s podobne jak w przypadku rozproszonych relacyjnych BD. Nie jest jednak pewne czy do przetwarzania zapyta w tych systemach bd si odnosi te same metody. Problemy, rnice przetwarzanie zapyta w rozproszonych obiektowych BD i w rozproszonych relacyjnych BD: Obiekty nie zawsze s implementowane jako "paskie" zapisy. Obiekty mog mie referencje do obiektw zlokalizowanych w innych wzach sieci. Przetwarzanie zapyta moe dotyczy kolekcji zoonych obiektw Zapytania mog mie odwoania do metod. Przetwarzanie zapyta w rozproszonych systemach obiektowych jest tematem bardzo istotnym. Standard ODMG tym si nie zajmuje. Jak dotd, w zakresie przetwarzania rozproszonych zapyta nie rozwizano podstawowych problemw koncepcyjnych. Niektre z problemw mog nie mie oglnego rozwizania. Rozproszona obiektowa baza danych

Przedmiotem przetwarzania i wymiany informacji w obiektowej rozproszonej bazie danych s obiekty. Zarzdzanie rozproszonymi obiektami ma na celu utrzymywanie spjnoci i przezroczystoci (niewidocznoci) geograficznego rozproszenia Zapytanie Aplikacja uytkownika uytkownika obiektw. Oprogramowanie klient/serwer Oprogramowanie serwera Oprogramowanie serwera

Podsystem komunikacyjny Oprogramowanie klient/serwer Zapytanie uytkownika Oprogramowanie klient/serwer Aplikacja uytkownika Zapytanie uytkownika Zalety rozproszonych obiektw Zgodno z logik biznesu - bezporednia implementacja obiektw biznesowych. Umoliwienie projektantom opnienie decyzji - gdzie i jakie usugi

powinny by zapewnione. Skalowalno aplikacji: maa zaleno czasu reakcji systemu od zwikszenia iloci danych, liczby uytkownikw, liczby wzw. Dekompozycja aplikacji na mae elementy wykonawcze (obiekty, metody,...). Przyrostowe dodawanie/odejmowanie funkcjonalnoci (pac tylko za to, czego uywam). Podzia zasobw i zbalansowanie obcie. Wspbieno i asynchroniczne przetwarzanie. Elastyczno zmian w oprogramowaniu (konserwacja), w szczeglnoci, przenoszenie obiektw i usug do innych miejsc. Moliwo przyczania aplikacji spadkowych (funkcjonujcych wczeniej jako scentralizowane). Projektowanie rozproszonych baz danych Podejcia do projektowania rozproszonych BD: top-down i bottom-up Od ogu do szczegw: top-down

bottom-up Odgrne zaprojektowanie caej bazy danych, z uwzgldnieniem optymalizacji przechowywanych danych, narzuconej przez fakt geograficznego rozproszenia producentw i konsumentw informacji przechowywanej w bazie danych. Od szczegw do ogu: Zintegrowanie ju istniejcych (spadkowych) lub zaprojektowanych lokalnych baz danych w jedn globaln rozproszon baz danych. Projektowanie: podejcie top-down Analiza Model pojciowy scentralizowany Model logiczny scentralizowany

Modele logiczne dla poszczeglnych miejsc Analiza systemowa: rozpoznanie wymaga, precyzowanie kontekstu przyszej bazy danych. Projektowanie schematu pojciowego Kryteria rozproszenia Projektowanie struktury logicznej Kryteria rozproszenia s zwizane z faktem fizycznego rozproszenia rde i odbiorcw danych oraz autonomii lokalnych baz

danych. Ustalaj one decyzje, ktre fragmenty projektu pojciowego bd Dalsze fazy postpowania w podejciu top-down Okrelenie danych podlegajcych replikacjom (lokalnych kopii) oraz strategii replikacji. Zrnicowanie logicznego schematu danych w zalenoci od typu SZBD w poszczeglnych miejscach. Okrelenie lokalnych schematw dla poszczeglnych miejsc. Okrelenie danych autonomicznych dla poszczeglnych miejsc, nie uczestniczcych w rozproszonej bazie danych; co prowadzi do okrelenia schematu pojciowego i logicznego dla danych widzianych z zewntrz. Podzia schematu logicznego: Wg rnych regu zwizanych na og z fizycznym ulokowaniem obiektw rzeczywistych (np. osb zatrudnionych, sprztu, co pociga za sob odpowiedni podzia schematu logicznego) lub te z fizycznym ulokowaniem programw aplikacyjnych dziaajcych na tych obiektach.

Fragmentacja Najpopularniejszym modelem jest fragmentacja pozioma, oznaczajca, e kady serwer ma ten sam schemat danych, ale inn populacj danych. Sumowanie zbiorw danych w taki sposb, e informacja o serwerach jest zbdna dla programisty/uytkownika. Fragmentacja pionowa: podzia obiektw na fragmenty przechowywane w rnych miejscach. Musi by zapewniony sposb sklejenia caoci obiektu z fragmentw (np. NIP dla obywateli RP). Przy integracji zasobw mog pojawia si wyrafinowane kombinacje fragmentacji poziomej, pionowej i replikacji (redundancji). Podstawowe metody fragmentacji schematu Fragmentacja pionowa oznacza przyporzdkowanie poszczeglnych klas obiektw do poszczeglnych miejsc, lub rozbicie obiektw danej klasy na dwa lub wicej podobiektw, przy czym takie podobiekty s przechowywane w rnych miejscach.

Fragmentacja pionowa moe oznacza konieczno odpowiedniego podziau informacji zawartych w klasach obiektw oraz ustalenia rodkw podtrzymania jednoznacznej tosamoci obiektw. Fragmentacja pozioma oznacza rozbicie populacji obiektw danej klasy na dwa lub wicej miejsc geograficznych. Fragmentacja pozioma moe by dokonywana na podstawie rnych kryteriw, ktre czsto wizane s z geograficznym ulokowaniem obiektw rzeczywistych, lub te z geograficznym ulokowaniem przetwarzania tych obiektw. Fragmentacja pionowa relacyjnej bazy danych Warszawa Kutno DC DOSTAWCA_DANE DNR CNR ILO DNR NAZW STATUS

D1 D2 D3 D4 D5 Abacki Bober Czerny Dbek Erbel 20 10 30 20 30 Sie Gdask DOSTAWCA_MIASTO

DNR D1 D2 D3 D4 D5 MIASTO Lublin Pozna Pozna Lublin Radom D1 D1 D1 D1 D1 D1 D2 D2

D3 D4 D4 D4 C1 C2 C3 C4 C5 C6 C1 C2 C2 C2 C4 C5 300 200 400 200

100 100 300 400 200 200 300 400 Fragmentacja pozioma relacyjnej bazy danych DOSTAWCA Pozna DNR NAZW STATUS MIASTO D2 Bober D3 Czerny 10 Pozna 30 Pozna DC

DNR CNR ILO D2 D2 D3 C1 C2 C2 300 400 200 Lublin DOSTAWCA Sie DNR NAZW STATUS MIASTO D1 Abacki D4 Dbek

20 Lublin 20 Lublin DC DOSTAWCA Radom DNR NAZW STATUS MIASTO D5 Erbel 30 Radom DNR CNR ILO D1 D4 D4 C6 C2 C4

100 200 300 Przykad fragmentacji poziomej Radom Klasa Pracownik Pracownik Nowak Pracownik Kowalski Obiekty Pracownik s przechowywane zgodnie z geograficznym pooeniem pracodawcy.

... Kalisz Sie Pracownik Styka Kielce Pracownik Malasa Klasa Pracownik Pracownik Zagrny. ... Klasa Pracownik

Pracownik Malina ... Fragmentacja pionowa obiektw Pracownik Radom Klasa danych osobistych Nowak dane osobiste Kowalski dane osobiste ... Kalisz Sie

Nowak dane o ocenach Krakw Nowak dane o zatrud. Klasa danych o zatrudnieniu Kowalski dane o zatrud. ... Klasa danych o ocenach Kowalski dane o ocenach ...

Fragmentacja danych Inne fragmentacje danych w rozproszonej BD Moliwe s inne, bardziej zoone fragmentacje danych, ktre cz fragmentacje pionowe, fragmentacje poziome oraz redundantne dane (replikacje). Bardziej zoone fragmentacje rodz trudnoci z: zarzdzaniem metadanymi: gdzie musz by ulokowane informacje odnonie tego w jaki sposb podzielone dane maj by scalone w kompletne obiekty lub kolekcje w ramach rozproszonej bazy danych. Jest to rola metadanych oraz mechanizmu waciwej dystrybucji metadanych pomidzy uczestnikw rozproszonej bazy danych. przetwarzaniem zapyta: dekompozycja zapytania na pod-zapytania adresowane do poszczeglnych miejsc staje si znacznie bardziej kopotliwa. Przesyanie fragmentw obiektw celem ich zmaterializowania po stronie klienta moe by zbyt kosztowne. Bardziej zoone fragmentacje mog by nie do uniknicia w rozproszonej bazie danych integrujcej istniejce bazy danych (podejcie bottom-up). Ma to konsekwencje dla zarzdzania metadanymi. Replikacje

Replikacja jest kopi danych i usug na innym serwerze. Replikacje maj na celu zwikszenie dostpnoci danych i usug oraz ich ochron przed zniszczeniem. Przy integracji bottom-up replikacje (redundancje) s czsto cech nieuchronn i niepodan. Moe wystpowa redundancja danych o dowolnym stopniu skomplikowania. Replikacje i redundancje stanowi powany problem dla przezroczystoci i operacji aktualizacji danych. Projektowanie: podejcie bottom-up Podejcie ad hoc: Budowa uniwersalnych lub specyficznych dla danego zastosowania pomostw (gateways) umoliwiajcych dostp z danego systemu bazy danych do innych baz danych. Pomost moe (nie musi) zapewnia przezroczysto rozproszenia. Podejcie oparte o globalny schemat: Wszystkie skadniki rozproszonej BD s objte jednym globalnym schematem, jednakowym dla kadego miejsca i zapewniajcym przezroczysto rozproszenia. Istotn wad podejcia opartego na globalnym schemacie jest brak moliwoci sterowania zakresem autonomii kadego lokalnego systemu.

Federacyjna baza danych: Kada lokalna baza danych zachowuje swoj autonomi, udostpniajc tylko cz danych dla innych miejsc w RBD. Podejcie federacyjne zakada, e kada lokalna baza danych jest widziana poprzez pewn perspektyw (view), ukrywajc niektre dane dla rozproszonych aplikacji. Replikacja Federacyjna BD tworzona metod bottom-up Aplikacje globalne Aplikacje Aplikacjeglobalne globalne Schemat federacyjnej bazy danych Perspektywa Mediator Osona Perspektywa Mediator Osona

Schemat lokalny 1 Miejsce 1 Aplikacje Aplikacje Aplikacje lokalne lokalne lokalne Schemat lokalny 2 Miejsce 2 Baza danych 1 Aplikacje Aplikacje Aplikacje lokalne lokalne lokalne

Baza danych 2 ..... Podejcie federacyjne okazao si skuteczne ze wzgldu na zapewnienie autonomii, bezpieczestwa i efektywnoci. Rodzi jednak duo problemw, m.in. z zapewnieniem jednolitej ontologii biznesowej, uniwersalnoci aplikacji, wydajnoci, itd. Architektury rozproszonych baz danych Architektura klient - serwer Serwer - komputer (proces) oferujcy okrelony rodzaj usugi Klient - komputer (proces) korzystajcy z usugi Klient

Klient Klient Serwer Klient Architektura klient-serwer Cao pracy wykonywanej przez system komputerowy jest podzielona na dwie czci: wykonywan po stronie klienta (zwykle zwizan z interakcj z uytkownikiem) Podstawowe problemy: wykonywan po stronie serwera (komunikacja, dostp do bazy danych, zarzdzanie repozytoriami pamici, zarzdzanie globaln przestrzeni

nazw) Okrelenie mechanizmu komunikacji pomidzy klientem a serwerem. Podzia funkcji na te, ktre s wykonywane po stronie klienta i te, ktre s wykonywane po stronie serwera Okrelenie jednostki komunikacji klient - serwer Heterogeniczne rodowisko w architekturze klient-serwer Windows 95 Client Windows NT Client UNIX Client Windows 95 or NT

Client TCP/IP network Windows NT Server with repository on SQLserver UNIX Server with repository on Informix Architektury serwerw w dostpie do bazy danych Serwer plikw, Serwer SQL, Serwer obiektw, Serwer stron. Architektura z serwerem plikw

klient Aplikacja po stronie klienta odwouje si do danych umieszczonych w pliku bazy danych Zapotrzebowanie na odczyt/zapis danych w plikach Odczytane dane z plikw bazy danych serwer Alokacja pamici WE/ WY obsuga plikw z baz danych Transfer plikw

Protok FTP (File Transfer Protocol) Usuga FTP: kopiowanie plikw z komputerw odlegych do komputera uytkownika kopiowanie plikw z komputera uytkownika do komputerw odlegych Dostp do danych (ograniczony, system weryfikacji uytkownika) rodowisko pracy: tekstowe (program ftp w rodowisku systemowym) graficzne (dedykowane aplikacji komercyjne, przegldarki) Procedura transferu plikw Podczenie si do serwera odlegego Wejcie uytkownika do systemu plikw Nawigacja w strukturze katalogw Okrelenie rodzaju transferu Pobranie/osadzenie plikw Zamknicie poczenia

Typowe instrukcje usugi FTP open - podczenie si do serwera user - wejcie uytkownika do systemu (ftp, anonymous) close - zamknicie poczenia dir - wywietlenie zawartoci katalogu na serwerze cd - zmiana katalogu biecego na serwerze lcd - zmiana katalogu biecego na komputerze klienta bin - binarny rodzaj transferu asc - znakowy rodzaj transferu put - przesanie pliku z komputera klienta do serwera get - pobranie pliku z serwera mput - przesanie plikw z komputera klienta do serwera mget - pobranie plikw z serwera Architektura z serwerem SQL Aplikacja klienta zadaje zapytanie SQL Zarzdzanie kursorem

klient Zapytanie SQL Maszyna SQL krotka serwer Architektura z serwerem stron klient aplikacja Menader obiektw serwer Pami podrczna stron Menader plikw/indeksw

Menader stron pamici podrcznej Alokacja pamici WE/WY strony Pami podrczna obiektw Pami podrczna stron Menader Menader stron pamici dziennika podrcznej blokowania Architektura serwera stron Aplikacja

Przedmiotem zarzdzania s fizyczne strony dyskowe Interfejs zapytaniowy Optymalizacja zapyta Przegldarka obiektw Interfejs programistyczny Zarzdzanie obiektami Zarzdzanie plikami i indeksami Zarzdzanie kieszeni stron strony Zarzdzanie zamkami Zarzdzanie skadem

Zarzdzanie kieszeni stron Obiektowa baza danych Architektura z serwerem obiektw klient serwer Pami podrczna obiektw Aplikacja Menader plikw/indeksw Menader obiektw

obiekty Pami podrczna obiektw Menader Menader obiektw dziennika blokowania Menader stron pamici odrcznej Alokacja pamici WE/WY Pami podrczna stron Architektura serwera obiektw Aplikacja

Przedmiotem zarzdzania s obiekty Interfejs zapytaniowy Przegldarka obiektw Interfejs programistyczny Zarzdzanie obiektami obiekty Zarzdzanie obiektami Optymalizacja zapyta Zarzdzanie zamkami Zarzdzanie skadem Zarzdzanie stronami i kieszeniami

Obiektowa baza danych Reguy architektury klient-serwer (1) Zachowanie autonomii serwera. Klienci powinni zachowywa reguy wykorzystania serwera, nie powinni powodowa jego niedostpno (np. zamyka due iloci danych), nie powinni ama ogranicze integralnoci. Zachowanie autonomii klienta. Klienci nie powinni zachowywa si rnie w zalenoci od tego, czy serwer jest lokalny czy odlegy. Powinni by odizolowani od kwestii fizycznego ulokowania danych. Wspomaganie dla aplikacji niezalenych od serwera. Dostp do wasnoci (danych, usug) serwera. Klienci mog da od serwera wykonanie przewidzianych dla niego funkcji. Wspomaganie dla biecego dostpu do danych. Dostp ten powinien by bezporedni, bez porednictwa plikw przekazywanych do/ od klienta. Minimalny wpyw architektury K/S na wymagania dla klienta. Oprogramowanie klienta w architekturze K/S nie powinno wykazywa znacznego zwikszenia zapotrzebowania na RAM lub objto dysku.

Reguy architektury klient-serwer (2) Kompletno opcji niezbdnych do poczenia. Oprogramowanie klienta nie powinno zawiera kodu realizujcego poczenie z serwerem.Powinien to zapewnia serwer komunikacyjny. Moliwo budowy lokalnych prototypw. Programista powinien mie moliwo budowy i testowania aplikacji K/S wycznie na stacji klienta. Kompletno narzdzi uytkownika kocowego. Projektowanie ekranw, generacja zapyta, itd. powinny by czci rodowiska. Kompletno rodowiska budowy aplikacji. Powinno przewidywa moliwo czenia si w sieci, dostp do usug globalnych w zakresie nazw, lokacji danych, itd. Otwarte rodowisko jzyka-gospodarza. Powinno zapewnia moliwo uycia uniwersalnego jzyka programowania do budowy aplikacji. Szczeglna troska o standardy. Im bardziej bd one przestrzegane, tym mniej bdzie pniejszych kopotw ze wspdziaaniem. Przykad architektury SZBD typu klient-serwer Aplikacja generujca transakcje Aplikacja generujca transakcje

Zarzdzanie transakcjami Zarzdzanie transakcjami Zarzdzanie buforami ... Zarzdzanie buforami Zarzdzanie zasobami Zarzdzanie zasobami Klient 1 Klient n

Zarzdzanie sieci Interfejs serwera Zarzdzanie zasobami Zarzdzanie transakcjami Zarzdzanie logiem Serwer Zarzdzanie buforami Zarzdzanie zamkami

Architektura klient-(multi) serwer (1) Poczenia bezporednie: k2 k2 k3 k3 k7 k7 k1 k1 k4 k4 k5 k5 k6 k6

s4 s4 s1 s1 k8 k8 s3 s3 s2 s2 k9 k9 k11 k11 k10

k10 Architektura klient-(multi) serwer (2) Poczenia poprzez sie: nie ma bezporednich pocze, zarwno serwery jak i klienci s przyczani w jednakowy sposb do wsplnej sieci komputerowej. k3 k3 k2 k2 k1 k1 s4 s4 k9 k9 k4 k4

Sie komputerowa s1 s1 k8 k8 s3 s3 k5 k5 k6 k6 s2 s2 k7 k7 Architektura trzywarstwowa i wielowarstowa

three-tier architecture multi-tier architecture Architektura klient-serwer podzielona na trzy warstwy: interfejs uytkownika, logik przetwarzania (reguy biznesu, logik biznesu) Interfejs uytkownika serwer (serwery) bazy danych. Warstwy s zaprojektowane i istniej niezalenie, co ma due znaczenie dla pielgnacyjnoci systemu ze wzgldu na moliwo zmian w dowolnej warstwie bez koniecznoci zmian w pozostaych warstwach. Czsto warstwy s zrealizowane na odrbnych platformach: interfejs na MS Windows, logika przetwarzania na serwerze aplikacji i baza danych na serwerze bazy danych.

rodkowa warstwa moe skada si z wielu warstw, co jest okrelane jako architektura wielowarstwowa. Logika przetwarzania Serwer bazy danych Serwer bazy danych Logiczna architektura oprogramowania Architektura klient-serwer powinna odzwierciedla logiczny podzia oprogramowania na czci. Nie jest to tak istotne w systemie scentralizowanym. Architektura trjwarstwowa: cienki klient

Warstwa Warstwaprezentacyjna prezentacyjna (interfejs (interfejsuytkownika) uytkownika) gruby klient Warstwa Warstwaprzetwarzania przetwarzania (logika (logikabiznesu) biznesu) Warstwa Warstwazarzdzania zarzdzania baz bazdanych danych

Staranne rozdzielenie tych warstw jest bardzo istotne z punktu widzenia tworzenia i modyfikowalnoci oprogramowania. Dziki temu rozdzieleniu, moliwa jest np. poprawa interfejsu uytkownika bez jakichkolwiek interwencji w pozostae warstwy oprogramowania. Zasada oddzielania aspektw (separation of concerns principle, E.Dijkstra) Cienki i gruby klient Terminy cienki klient (thin client) oraz gruby klient (fat client) odnosz si do mocy i jakoci przetwarzania po stronie klienta w architekturze klient-serwer. Model cienkiego klienta: klient posiada niezbyt wielk moc przetwarzania, ograniczon do prezentacji danych na ekranie. Przykadem jest klient w postaci przegldarki WWW. Model grubego klienta: klient posiada znacznie bogatsze moliwoci przetwarzania, w szczeglnoci moe zajmowa si nie tylko warstw prezentacji, lecz take warstw przetwarzania aplikacyjnego (logiki biznesu). Powyszy podzia posiada oczywicie pewn gradacj.

Model cienkiego klienta jest najczstszym rozwizaniem w sytuacji, kiedy system scentralizowany jest zamieniany na architektur klient-serwer. Wad jest due obcienie serwera i linii komunikacyjnych. Model grubego klienta uywa wikszej mocy komputera klienta do przetwarzania zarwno prezentacji jak i logiki biznesu. Serwer zajmuje si tylko obsug transakcji bazy danych. Popularnym przykadem grubego klienta jest bankomat. Zarzdzanie w modelu grubego klienta jest bardziej zoone. Architektury dwuwarstwowe Uproszczone architektury trjwarstwowe z cienkim lub grubym klientem. cienki klient Warstwa Warstwaprezentacyjna prezentacyjna (interfejs (interfejsuytkownika) uytkownika) Warstwa Warstwaprzetwarzania

przetwarzania (logika (logikabiznesu) biznesu)++ Warstwa Warstwazarzdzania zarzdzania baz bazdanych danych Warstwa Warstwaprezentacyjna prezentacyjna (interfejs uytkownika) (interfejs uytkownika) ++Warstwa Warstwaprzetwarzania przetwarzania (logika (logikabiznesu)

biznesu) gruby klient Warstwa Warstwaprzetwarzania przetwarzania (logika (logikabiznesu) biznesu)++ Warstwa Warstwazarzdzania zarzdzania baz bazdanych danych W tym modelu przetwarzanie (logika biznesu) jest dzielone pomidzy klienta i serwera. Zaprojektowanie jej jest trudniejsze.

Przykad architektury K/S - sie bankomatw Bankomat Bankomat Bankomat Bankomat Serwer kont klientw banku Monitor Baza danych kont tele-przetwarzania klientw banku Bankomat Bankomat Bankomat Bankomat Oprogramowanie poredniczce organizujce komunikacj z odlegymi klientami i szeregujce transakcje klientw

celem przetwarzania ich przez baz danych. Przykad architektury K/S - portal WWW klient klient klient klient klient klient klient klient interakcja poprzez HTTP Serwer SerwerWeb: Web:

generacja generacja dynamicznych dynamicznychstron stron HTML HTMLdla dlaklienta klienta ++ zlecenia zleceniado dobazy bazy danych danych zapytania SQL wyniki zapyta

SQL Serwer Serwerbazy bazy danych: danych: wykonywanie wykonywanie zapyta zapytawwSQL SQL 3-warstwowa architektura aplikacji Web Serwer Web Sie Internet Serwer aplikacji Serwer bazy danych

HTTP Baza danych Przegldarka Serwer Baza danych 2-warstwowa architektura aplikacji Web Wiele warstw poredniczcych powoduje dodatkowe obcienie. Sie Internet Serwer Web Serwer aplikacji Serwer bazy danych HTTP Baza danych

Przegldarka Serwer Baza danych Zastosowanie rnych architektur K/S Dwuwarstwowa architektura K/S z cienkim klientem Systemy spadkowe (legacy), gdzie oddzielenie przetwarzania i zarzdzania danymi jest niepraktyczne. Aplikacje zorientowane na obliczenia, np. kompilatory, gdzie nie wystpuje lub jest bardzo maa interakcja z baz danych. Aplikacje zorientowane na dane (przegldanie i zadawanie pyta) gdzie nie wystpuje lub jest bardzo mae przetwarzanie. Dwuwarstwowa architektura K/S z grubym klientem Aplikacje w ktrych przetwarzanie jest zapewnione przez wyspecjalizowane oprogramowanie klienta, np. MS Excel. Aplikacje ze zoonym przetwarzaniem (np. wizualizacj danych, przetwarzaniem multimediw). Aplikacje ze stabiln funkcjonalnoci dla uytkownika, uyte w rodowisku z dobrze okrelonym zarzdzaniem.

Trzywarstwowa lub wielowarstwowa archiktektura K/S Aplikacje o duej skali z setkami lub tysicami klientw. Aplikacje gdzie zarwno dane jak i aplikacje s ulotne (zmienne). Aplikacje integrujce dane z wielu rozproszonych rde. Architektura rozproszonych obiektw W architekturze klient-serwer istnieje wyrana asymetria pomidzy klientem i serwerem; w szczeglnoci, nie wystpuje tam komunikacja bezporednio pomidzy klientami. Model taki dla wielu zastosowa jest mao elastyczny i zapewnia zbyt ma skalowalno. Architektura rozproszonych obiektw znosi podzia na klientw i serwery. Kade miejsce w rozproszonym systemie jest jednoczenie klientem i serwerem. Konieczne jest sprowadzenie wszystkich danych i usug do jednego standardu. Taki standard obejmuje: Model (pojciowy i logiczny) danych i usug, ktry jest w stanie "przykry" wszystkie moliwe dane i usugi, ktre mog kiedykolwiek pojawi si w systemie rozproszonym; Specjalne oprogramowanie zwane porednikiem (broker), ktre akceptuje wsplny model danych i usug umoliwiajc ich udostpnienie dla dowolnych miejsc w systemie rozproszonym.

Specjalne oprogramowanie, zwane oson, adapterem lub mediatorem, ktre przystosowuje konkretne miejsce do modelu przyjtego przez porednika. Architektura klient-broker-serwer Dostp do odlegych zasobw sieci komputerowej odbywa si miedzy klientem (klientami) a serwerem (serwerami) nie odbywa si bezporednio lecz za pomoc porednika (brokera) Porednik zapewnia przezroczysto do odlegych geograficznie zasobw, Broker przedstawia wszystkie zasoby w postaci zbioru obiektw, dziki czemu moliwe jest ujednolicenie operacji wykonywanych na zasobach, niezalenie od ich implementacji i realizacji wewntrznej, Fizyczna lokalizacja obiektw nie jest istotna dla uytkownika, gdy pooenie obiektw znane jest brokerowi, Porednik otrzymuje zadanie od klienta, lokalizuje serwer z potrzebnymi zasobami, przekazuje zlecenie oraz przekazuje zwrotnie wynik zlecenia zrealizowanego przez serwer do klienta Architektura klient-broker-serwer

Host klienta Host serwera zlecenie Wywoanie operacji Klient Klient Porednik (Broker) wynik, parametry WY Obiekt Obiekt Architektura rozproszonych obiektw (2) ... Aplikacja napisana w

C++ Aplikacja na relacyjnej bazie danych Aplikacja na Lotus Notes Osona 1 Osona 2 Osona 3 Porednik Porednik Porednik

Szyna oprogramowania (software bus) Miejsce 1 Miejsce 2 Miejsce 3 ... Struktura logiczna rozproszonych obiektw Obiekty Operacje na obiektach O3 O3 O1 O1 O2

O2 O7 O7 O5 O5 O4 O4 K1 O8 O8 O6 O6 K3 K2

O9 O9 K4 Szyna oprogramowania (software bus) Aplikacje A1 A2 A3 Szyna oprogramowania tworzy jedn przestrze obiektw. Obiekty te s dostpne dla dowolnego miejsca poprzez operacje (zgrupowane w klasach). Miejsca i sposoby implementacji obiektw s niewidoczne. Aplikacje korzystaj z caej puli obiektw. Semistrukturalna architektura aplikacji internetowych Przegldarka

WWW Narzdzia wspomagajce XML : system autorski, itd. Warstwa klienta Przegldarka WWW XML XML Serwer Web Serwer aplikacji Interakcja z aplikacjami poprzez protokoy oparte na XML XML Obiektowo-relacyjna

baza danych wspomagajca XML Logiczna warstwa porednia Baza danych w XML (strukturalizowana) XML Obiektowa baza danych wspomagajca XML XML Serwer integrujcy XML, serwer zapyta, serwer hurtowni danych XML Translatory formatw z/do XML, pomosty

Dokumenty Dokumenty XML XML nana Webie Webie Inne Inne dokumenty dokumentynana Webie: Webie:HTML HTML Word,... Word,... Zasoby danych Zasoby danych pod OLE/DB

Standardy czenia rozproszonych zasobw Standardy czenia rozproszonych danych (1) Open DataBase Connectivity (ODBC): standard [zdalnego] dostpu do relacyjnych baz danych bazuje na Call Level Interface (CLI) opracowanym przez konsorcjum X/Open definiuje API oraz cechy SQL ktre musz by zapewnione na rnych poziomach zgodnoci. Java DataBase Connectivity (JDBC): analogiczny do ODBC standard dla Java. Standardy X/Open XA: definiuj zarzdzanie transakcjami ze wspomaganiem protokou 2PC. OLE-DB: API podobne do ODBC, ale wspomagajce rda niebazodanowe, takie jak paskie pliki. OLE-DB program moe negocjowa ze rdem danych aby znale wasnoci, ktre ono podtrzymuje. API jest podzbiorem SQL Standardy czenia rozproszonych danych (2)

ADO (Active Data Objects): atwy interfejs do funkcji OLE-DB Kilka standardw bazujcych na XML dla E-commerce Np. RosettaNet (acuchy dostaw), BizTalk Definiuj katalogi, opisy usug, faktury, zamwienia, itd. osony XML s uywane do eksportu informacji z relacyjnej BD do XML Resource Description Framework (RDF): specyfikacja ontologii dla zasobw Web. Simple Object Access Protocol (SOAP): bazujcy na XML standard dla zdalnego woania procedur (RPC). SOAP jest mniej elastyczny i uniwersalny w stosunku do CORBA, ale pozostaje pytanie, czy a taka elastyczno i uniwersalno jest potrzebna. Uywa XML do zakodowania danych, HTTP jako protokou transportowego Dalsze standardy s oparte na SOAP dla specyficznych aplikacji, np. OLAP i Data Mining (standardy Microsoft'u) Standardy czenia rozproszonych danych (3) Object Data Management Group (ODMG) standard obiektowych baz danych jest uywany w projektach przyszociowych zwizanych z rozproszonymi lub federacyjnymi bazami danych, np. IRO/DB.

OMG CORBA (Common Object Request Broker Architecture) najbardziej uniwersalny standard obejmujcy ogromn liczb aspektw. W szczeglnoci, notacja UML jest jego skadow. Pakiety ORB (Object Request Broker) s oprogramowaniem realizujcym t architektur. .NET/DCOM (Distributed Component Object Model) - standard Microsoftu zintegrowany z systemami operacyjnymi Microsoftu. Znacznie ograniczony w stosunku do standardu CORBA. RMI (Remote Method Invocation) - oprogramowanie firmy Sun, ograniczone w stosunku do standardu CORBA do oprogramowania pisanego w Java. Java Beans i Enterprise Java Beans wykorzystuj RMI jako transport. Replikacje Replikacje Technologia replikacji oznacza przechowywanie dwch lub wicej kopii danych (replik) w oddalonych geograficznie miejscach. Cele: Zwikszenie dostpnoci danych poprzez: - zminimalizowanie czasu i kosztw ich transmisji z odlegego miejsca

- rozoenie obcienia w zakresie dostpu na wiele kopii danych Zwikszenie odpornoci danych na zniszczenie. Zwikszenie bezpieczestwa Aktualizacja replikacji Aktualizacja dowolnej kopii danych powinna spowodowa jednoczesn aktualizacj wszystkich pozostaych kopii. W idealnym przypadku powinno to nastpowa jednoczenie, aby zapobiec sytuacji, gdy dane przechowywane w rnych kopiach s wzajemnie niespjne. Ten idea nie daje si zrealizowa tak atwo z kilku powodw: Czas transmisji zlece aktualizacyjnych powoduje, e kopie s chwilowo wzajemnie niezgodne; Zawodno czy i wzw sieci moe spowodowa czasow niemoliwo wykonania zlecenia aktualizacyjnego; Koszt transmisji zlece aktualizacyjnych moe by nieakceptowalny w przypadku bardzo czstych zmian. Mona wyobrazi sobie sytuacj, kiedy kada aktualizacja dowolnej kopii jest wykonywana w ramach transakcji, ktra nie bdzie potwierdzona a do momentu zaktualizowania wszystkich kopii. Takie rozwizanie w wikszoci przypadkw powoduje jednak znaczne zmniejszenie dostpnoci danych. Modele replikacji

Jednoczesne aktualizacje ze sterowaniem wspbienocia Transakcja aktualizujca Propagacja aktualizacji Transakcja aktualizujca propagacja aktualizacji Replika 1 Replika 2 propa g a k tu a a c j a l iz a c ji Replika 1 Replika 3

Replika 3 Replika 2 Planowane odwieanie kopii dla replik tylko do czytania Transakcja aktualizujca planowana aktualizacja Replika 1 Transakcja czytajca plano w aktua ana lizacj a Replika 3 Transakcja czytajca Replika 2

Wady replikacji Konieczna dodatkowa przestrze dyskowa Moliwo powstania niespjnoci pomidzy replik i oryginaem => zagroenie dla spjnoci procesw biznesowych Np. jeeli dane o wysokoci kont s powtrzone w wielu miejscach, wwczas kto korzystajc z (celowo) uszkodzonych linii transmisyjnych moe dokona nielegalnych wypat. Zwikszenie kosztw aktualizacji danych: aktualizacja oryginau pociga za sob dodatkowy koszt aktualizacji replik regua kciuka (bardzo uproszczona): Przy dokadnej analizie naley utworzy bardziej zoone modele kosztw, ktre ustal opacalno replik. ilo zapyta czytajcych > ilo replik Jeeli ilo zlece aktualizujcych to warto tworzy repliki. W przeciwnym przypadku - nie warto. Przetwarzanie transakcji

Przetwarzanie transakcji Problemy z transakcjami w systemach rozproszonych: Faza potwierdzenia (commit) moe trwa dugo. Niepowodzenie (awaria) w tej fazie moe spowodowa niespjno bazy danych i przetwarzania. Std nowe protokoy przetwarzania transakcji w systemie rozproszonym: 2PC, 3PC. Zakleszczenie: wykrywanie i usuwanie jest znacznie trudniejsze, gdy wymaga przesyania w sieci informacji ktra transakcja czeka na ktr. Ziarnisto mechanizmu transakcji: bezporednio zwizana z dostpnoci rozproszonej bazy danych (liczb jednoczenie pracujcych uytkownikw). Wydajno (performance): zoone protokoy powoduj jej zmniejszenie; std 2PC i 3PC s czsto nieadekwatne. Dugie transakcje: konieczno zmniejszenia poziomu izolacji aby umoliwi dostp do zablokowanych danych. Implementacja transakcji poprzez zamki Zamek (lock): jedna z transakcji rezerwuje sobie dostp do obiektu. Spjno przetwarzania transakcji jest zachowana, jeeli caa transakcja ma dwie fazy: rosnc i skracajc. start

potwierdzenie (commit) zakadanie zamkw (nie ma zwalniania) koniec zwalnianie zamkw (nie ma zakladania) czas Awaria w fazie potwierdzenia jest krytyczna, gdy grozi utrat spjnoci. W systemach rozproszonych faza potwierdzenia moe trwa minuty i wcza zawodne zawodne elementy infrastruktury (cza). Warunek atomowoci oznacza, e jeeli transakcja dzieli si na wiele podtransakcji wykonywanych na odlegych serwerach, to nie moe zaj sytuacja, gdy podtransakcja na serwerze A jest potwierdzona, za podtransakcja na serwerze B jest zerwana.

Std konieczno dodatkowej ochrony fazy potwierdzenia => 2PC. Dwufazowe potwierdzenie (2PC) Koordynator (program aplikacyjny klienta) w got SZBD serwera w pot ierd gotw potwierd SZBD klienta SZBD serwera

pot wie rd got w SZBD serwera 1. Serwery wysyaj komunikaty gotw do koordynatora. 2. Po skompletowaniu wszystkich zgosze koordynator wysya komunikat potwierd do wszystkich serwerw. Jeeli nie nadejd wszystkie zgoszenia gotw, koordynator wysya komunikat zerwij transakcj do wszystkich serwerw. Wada: due straty wykonanej pracy w przypadku zerwania. 2PC - zarzdzanie awariami Do zoone postpowanie zalene od tego, czy awarii uleg serwer czy te koordynator.

Protok 2PC okrela: Czas graniczny (timeout) nadesania sygnau "gotw" od wszystkich serwerw do koordynatora . Jeeli czas graniczny min oraz nie ma wszystkich sygnaw "gotw", to koordynator wysya do wszystkich serwerw sygna "zerwij". Sposb rejestracji sygnaw 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, ktre zgosiy "gotw" s przyblokowane. Serwery "nie wiedz", co dalej robi. Postawienie koordynatora moe trwa dugo. Bardziej zoony protok 3PC uwzgldnia awarie koordynatora . 3PC nie znalaz jednak szerszego zastosowania ze wzgldu na due narzuty na wydajno aplikacji. Transakcje w federacyjnej bazie danych (1) Lokalne transakcje s wykonywane autonomicznie przez lokalny SZBD. Federacja nic o nich nie wie i (z reguy) nie moe si dowiedzie. Globalne transakcje s wykonywane przez aplikacje

globalne. Mog skada si z wielu podtransakcji, wykonywanych przez lokalne SZBD. Z punktu widzenia lokalnego SZBD podtransakcja globalnej transakcji jest normaln lokaln transakcj. W zwizku z tym, zapewnienie szeregowalnoci globalnych transakcji (niezbdny warunek dla utrzymania spjnoci przetwarzania) w FBD jest trudne lub wrcz niemoliwe. Dlaczego? - nastpny slajd. Transakcje w federacyjnej bazie danych (2) Lokalne bazy danych mog stosowa rnorodne algorytmy przetwarzania transakcji. Autonomia oznacza, e federacja nie ma wpywu na te algorytmy. Lokalna BD moe w kadej chwili z rnych powodw (np. zakleszczenia) zerwa dowoln transakcj, w tym podtransakcj indukowan przez globaln transakcj. Informacja o wewntrznym stanie lokalnie przetwarzanych transakcji (np. stan dziennika transakcji, zamki zakadane przez transakcje, itd.) nie jest widoczna na zewntrz. Stosowanie typowych algorytmw, np. 2PC (two phase commit) jest niemoliwe, gdy lokalna BD moe nie posiada moliwoci zawieszenia podtransakcji w stanie gotowa i czeka na sygna

potwierd ze strony globalnej transakcji. Niezgodnoci schematw i ontologii Niezgodnoci schematw schematic discrepancies Przy integracji niezalenie zaprojektowanych baz danych w jeden schemat naley si liczy z tym, e organizacja, struktura i semantyka danych bdzie niezgodna. Nie istnieje ani jeden ani najlepszy sposb odwzorowania dziedziny przedmiotowej w struktury danych zapamitane w bazie danych. Rni projektanci projektuj cakowicie odmienne struktury dla tego samego problemu. Dlaczego? Obiekty tej samej dziedziny problemowej mog by widziane przez rnych projektantw cakowicie odmiennie. Systemy zarzdzenia BD maj ograniczenia struktur danych, ktre wymuszaj sposb mylenia projektantw nad koncepcj struktur danych. Rne rodki manipulacji strukturami dostarczane przez SZBD wymuszaj czsto rn koncepcj. Projektanci podejmuj rnorodne decyzje co do koncepcji struktur danych w zwizku z zamierzonymi wasnociami uytkowymi, np. szybkoci dostpu.

Niezgodnoci ontologii w rozproszonych BD (1) S one powan przeszkod, ktra pojawia si podczas konstruowania federacyjnych rozproszonych BD. Niezgodnoci te dotycz rnych aspektw organizacji i dziaania: Niezgodnoci pomidzy modelami danych: relacyjna vs. obiektowa vs. hierarchiczna XML-owa, itd. Niezgodnoci pomidzy schematami pojciowymi. Np. w jednej BD informacja o dzieciach pracownika jest atrybutem jego obiektu, za w innej jest zwizkiem czcym obiekt pracownika z obiektami osb. W zalenoci od BD te same dane mog wystpowa raz jako nazwy (obiektw, atrybutw), a raz jako ich wartoci. Nawet gdy zespoy stosuj t sam metodyk projektowania, to na og ich projekty pojciowe s zasadniczo rne. Niezgodnoci pomidzy schematami logicznymi. Mona oczekiwa, e w niezalenie zbudowanych bazach danych nazwy obiektw, nazwy atrybutw oraz ich zestaw bd inne. Mog wystpowa powaniejsze rnice w zakresie organizacji logicznej; np. w pewnej lokalnej bazie danych informacja o pracownikach moe by rozbita na dwie lub wicej tablic.

Niezgodnoci ontologii w rozproszonych BD (2) Niezgodnoci w zakresie interpretacji semantycznej danych. W jednej bazie danych zarobek pracownika moe by zarobkiem brutto, w innej - netto, za jeszcze w innej moe by rozbity na pensj, premi i dodatki. Niezgodnoci dotyczce budowy i rodkw dostpu do katalogw. W relacyjnej BD katalog jest zbiorem relacji dostpnym przy pomocy SQL, w innej bazie katalog moe nie istnie explicite, za informacje katalogowe s dostpne poprzez zmienne rodowiskowe oraz specjalne procedury i funkcje. Niezgodnoci dotyczce reprezentacji danych. W jednej BD informacja o zawodzie pracownika jest przechowywana na przykad w postaci cigu znakw, a w innej przy pomocy numeru zawodu i specjalnoci, ktrym towarzyszy tabela umoliwiajca interpretacj (niekoniecznie przechowywana w BD). Mog wystpowa rnice w reprezentacji dat, czasu i innych atrybutw, rnice w zakresie precyzji reprezentacji wielkoci liczbowych oraz zarezerwowanych dugoci obszarw dla wartoci znakowych, itp. Niezgodnoci ontologii w rozproszonych BD (3)

Niezgodnoci dotyczce odniesienia danych do skali czasowej. Informacje mog by np. aktualizowane natychmiast, za w innej BD raz na miesic. Niezgodnoci w sposobach dostpu. W jednej BD dostp do danych bdzie realizowany na przykad przy pomocy standardowego SQL, a w innej poprzez rodki dostpu pewnego jzyka czwartej generacji lub API. Rna strukturalizacja informacji. Np. w jednej BD utworzono odrbn tabel PrzynalenoDoZwizkuZawodowego, za w innej ta przynaleno 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 Zawd tabeli Pracownicy jest stringiem, za w innej utworzono odrbne tabele. Piekarze, Stolarze, itd. Niezgodnoci jest bardzo duo. Niezalenie zbudowane lokalne bazy danych zawsze bd obcione tego rodzaju konfliktami. Kanoniczny model danychcanonical data model Jeeli wiele baz danych ma tworzy jedn federacyjn baz danych w ktrej bdzie obowizywa jeden wsplny API f, wwczas potrzebny jest model danych w terminach ktrego dadz si wyrazi wszystkie inne modele danych. Model powinien take uwzgldnia fakt, e w federacji mog pojawi si nowe

bazy danych, ktrych zaoe nie rozpatrywalimy podczas jej tworzenia. Ktry z modeli danych mgby by takim kanonicznym modelem danych? Relacyjny? Encja-zwizek? UML? CORBA? ODMG? Jaki inny? Jeeli nie chcemy debaty religijnej o wyszoci modelu A nad B, to powstaje pytanie o obiektywne kryteria. Czy istniej? Debata nad kanonicznym modelem danych traktuje modele danych jako obiektywne byty o ostro zarysowanych wasnociach i granicach. Nie jest to suszne. Modele danych s tworami subiektywnymi, o niejasnych granicach, podlegaj cigej ewolucji, moliwe s rnorodne ich mutacje i rozszerzenia. Istnieje potencjalnie wiele modeli relacyjnych i wiele modeli obiektowych. Kryteria wyboru kanonicznego modelu danych Ekspresyjno (expressiveness): w jakim stopniu dany model jest w stanie bezporednio odwzorowa pojcia z modelu pojciowego dziedziny aplikacyjnej oraz definiowa nowe operacje, typy danych i wizy integralnoci. Np. model relacyjny nie ma bezporednich odwzorowa zoonych obiektw, dziedziczenia, agregacji, informacji behawioralnych, itd., wobec czego ma nisk ekspresyjno. Pod tym wzgldem model obiektowy ma przewag. Relatywizm semantyczny (semantic relativism): stopie, w jakim dany model umoliwia wiele punktw widzenia na t sam dziedzin aplikacyjn. Miar

relatywizmu semantycznego danego modelu jest moliwo budowania dowolnych schematw zewntrznych (perspektyw) nad schematem bazy danych. Model relacyjny posiada pewien stopie relatywizmu, dziki jego zdolnoci definiowania perspektyw (ograniczonej, szczeglnie w zakresie aktualizacji perspektyw). Definiowanie perspektyw nie jest mocn stron systemw obiektowych, jakkolwiek nie istniej tu ograniczenia koncepcyjne. Federacyjne bazy danych Co to jest Federacyjna Baza Danych? Federated Database Jest to kolekcja heterogenicznych, autonomicznych baz danych, poczonych sieci komputerow, zarzdzana specjalnym systemem okrelanym jako Federacyjny System Zarzdzania Baz Danych (FSZBD). Moe wcza dziesitki, setki, tysice lub wicej lokalnych baz danych. FSZBD umoliwia tworzenie aplikacji globalnych, dziaajcych na caoci federacyjnej bazy danych. Jest ona zdefiniowana schematem federacyjnym, bdcym sum schematw eksportowych lokalnych baz danych. FSZBD zapewnia warunki pracy twrcw aplikacji globalnych okrelane jako przezroczysto i niezaleno danych.

FSZBD moe by zainstalowany w wielu wzach sieci (m.in. w kadym lokalnym miejscu FBD), umoliwiajc tworzenie aplikacji globalnych w wielu miejscach geograficznych. Poszczeglne FSZBD wsppracuj ze sob celem zapewnienia spjnoci i integralnoci przetwarzania. Architektura federacyjnej bazy danych Aplikacje globalne FSZBD 1 Przestrze robocza Aplikacje globalne ... Schemat FBD FSZBD m

Przestrze robocza Schemat FBD Sie komputerowa Schemat eksportowy 1 Osona 1 API 1 Lokalny SZBD 1 BD 1 Aplikacje lokalne Schemat eksportowy 2 Osona 2 API 2

Lokalny SZBD 2 BD 2 Aplikacje lokalne ... Schemat eksportowy n Osona n API n Lokalny SZBD n BD n Aplikacje lokalne Global schema

External sub-schemata Architektura(indostpu do lokalnej BD an extended ODL) (through an accessibility matrix) Lokalna baza danych Lokalny schemat eksportowy Zewntrzne podschematy uytkownikw (macierz dostpu) Zewntrzny podschemat 1 Zewntrzny podschemat 2 Zewntrzny

podschemat 3 Interfejs IA1 Dostp Zakaz Zakaz Interfejs IA2 Zakaz Zakaz Dostp Dostp Zakaz

Dostp Interfejs IC1 Zakaz Dostp Zakaz Ob.wirt. VV3 Ob.wirt. 3V Dane wirt. 1 Perspektywa V1 Zakaz Dostp

Dostp Ob.wirt. VV3 Ob.wirt. 3V Dane wirt. 2 Perspektywa V2 Dostp Zakaz Zakaz Obiekty A Obiekty A Obiekty Dane B A

Obiekty Dane C A API Osona Mediator Obiekty A Obiekty A Obiekty Dane A A Interfejs IB1 definiuje u la a t s

Administrator lokalnej bazy danych Uytkownik Uytkownik 1 2 Uytkownik 3 Trj-warstwowa architektura federacyjnej BD 3 Uytkownik 1 Uytkownik 2 Uytkownik 3 Schemat zewntrzny 1

Schemat zewntrzny 2 Schemat zewntrzny 3 Schemat federacyjny 2 FSZBD Przestrze robocza Sie 1 Schemat eksportowy 1 Osona 1 API 1

Lokalny SZBD 1 BD 1 Schemat eksportowy 2 Osona 2 API 2 Lokalny SZBD 2 BD 2 ... Przetwarzanie zapyta w FBD Podstawowe algorytmy przetwarzania zapyta w homogenicznych i federacyjnych relacyjnych BD s podobne. Rnice dotycz cech autonomii i heterogenicznoci, ktre znacznie komplikuj problem. Algorytmy polegaj na dekompozycji zapytania na pewne podzapytania kierowane do lokalnych BD, nastpnie na skomponowaniu globalnego wyniku z wynikw czstkowych zwrconych przez lokalne BD.

Komplikacje Niezgodnoci schematw, ktre wymagaj mechanizmu refleksji lub nowych operatorw w SQL. Brak algorytmicznej uniwersalnoci SQL. Ograniczona moc mechanizmu definiowania perspektyw. Problem zosta rozwizany dla niektrych przypadkw, ale nie dla generalnego. Wyglda na to, ze w ramach obecnych paradygmatw modelu relacyjnego niewiele wicej da si zrobi. W obiektowych bazach danych problem jest na pocztku drogi. Nie s mi znane istotne prace, ktre dayby nadziej na rozwizanie. Przymiarki, spekulacje,... Rozproszone BD w standardzie CORBA Oprogramowanie komponentowe budowane wg standardu CORBA moe by podstaw rozproszonych/federacyjnych baz danych. Host globalnej aplikacji Host lokalnej BD Klient Klient Wywoanie operacji

Obiekty Obiekty Obiekty Pieniek klienta zlecenie Implementacja interfejsw do obiektw (szkielety + kod) Porednik (ORB, Object Request Broker) wynik, parametry wyj Implementacja interfejsw do obiektw po stronie serwera powstaje ze szkieletu automatycznie generowanego z wyraenia IDL, ktry jest wypeniany kodem operacji. Taki szkielet peni jednoczenie funkcj osony oraz funkcj perspektywy. ORB jest w stanie zapewni autonomi lokalnej BD.

Problemy z RBD w standardzie CORBA CORBA nie jest nastawiona na przetwarzanie danych trwaych i masowych przy pomocy jzykw zapyta. Jest to poziom jzykw takich jak C++ i Java, znacznie niszy. Obecny stan standardyzacji w zakresie Query Service i Persistence Service jest uwaany za niezadowalajcy. CORBA nie wprowadza pojcia perspektywy. Osony w CORBA s pisane w jzykach niskiego poziomu, s zorientowane na dan aplikacj, nie daj konceptualizacji takiej, jak daj perspektywy. Mog by znaczne narzuty na wydajno maszynow i produktywno programistw globalnych aplikacji. CORBA nie rozwizuje problemw zwizanych z przetwarzaniem transakcji w rozproszonych/federacyjnych bazach danych. Model obiektowy CORBA jest ograniczony, m.in. nie uwzgldnia zwizkw i zagniedonych kolekcji. Te moliwoci s uwzgldniane w usugach (np. Relationship Service), ktre nie s realizowane. Osony i mediatory Osona wrapper

Modu oprogramowania umoliwiajcy przystosowanie interfejsu lokalnej bazy danych do pewnego standardu obowizujcego w systemie rozproszonym. Podstawowe zadanie: fizyczne poczenie rnych baz danych. Osona nie zajmuje si bardziej wyrafinowanym odwzorowaniem; chodzi o translacj danych, parametrw i wywoa funkcji pyncych z zewntrz lokalnego systemu (o specyficznych formatach i reprezentacji) na analogiczne dane, parametry i funkcje wyraone w API konkretnego lokalnego systemu bazy danych. Dla niektrych przypadkw, np. dla niektrych stron HTML, napisanie osony jest bardzo trudnym zadaniem ze wzgldu na nieregularnoci formatu (dane p-strukturalne, semi-structured). Osona jest niezbdna do tego, aby budowa bardziej wyrafinowane rodki odwzorowania schematw i aplikacji, takie jak mediatory i perspektywy Osony w federacyjnych BD Osona udostpnia dane i usugi lokalnego systemu i (dostpne w pewnym API i) dla aplikacji globalnych (wykorzystujcych wsplny API f). Osony przystosowuj lokalne

obowizujcego w federacji. SZBD do interfejsu programistycznego Federacyjny SZBD API f API f Osona 1 Osona 2 API 1 Lokalny

SZBD 1 API 2 Lokalny SZBD 2 ... API f Osona n API n Lokalny SZBD n Osony dla lokalnych relacyjnych SZBD Problem pojawia si wtedy, gdy API f dla federacyjnej bazy danych nie jest oparty o model relacyjny, lecz o model obiektowy a la CORBA lub ODMG. Potencjalne problemy i rozwizania: Konieczno silnego ograniczenia modelu obiektowego, np. brak zoonych obiektw, metod, zwizkw, hermetyzacji, polimorfizmu, itd.; Odwzorowanie krotek tabel na zoone obiekty - wiele krotek skadajcych si na jeden obiekt. Przetwarzanie np. w OQL+Java. Problemy

koncepcyjne. Odwzorowanie obiektowego API, np. OQL +Java na relacyjne API, np. JDBC. Oglne rozwizanie jest bardzo trudne. Zredukowanie API relacyjnej BD do prymitywnych operacji (get first, get next,...), dziki czemu relacyjn baz danych mona bdzie potraktowa jako prymitywn obiektow baz danych. Nastpnie, zdefiniowanie obiektowych, wirtualnych, aktualizowalnych perspektyw. Problemy koncepcyjne. Problemy z wydajnoci. Mediatory mediator Warstwa porednia pomidzy lokaln baz danych a globalnymi aplikacjami. Jest konieczny wtedy, gdy nie ma odwzorowania 1:1 pomidzy ontologiami. Np. w jednej bazie podany jest zarobek brutto z ubezpieczeniem, w innej zarobek brutto bez ubezpieczenia. Jak to sprowadzi do wsplnego mianownika? Zadania mediatora: Rozstrzyganie rozbienoci pomidzy schematem lokalnym a schematem federacyjnym. Wspomaganie dla wyowienia cech formalnych z danych niesformatowanych. Selekcja waciwej informacji.

Wspomaganie dla informacji sumarycznych, wyliczalnych oraz o wikszym stopniu abstrakcji. Wspomaganie dla wykrywania niezidentyfikowanych zwizkw w danych (eksploracja danych). Zasady konstrukcji mediatorw nie s jasne. W wikszoci przypadkw mediator musi by zaprojektowany ad hoc, pisany technik niskiego poziomu i przypisany do konkretnej aplikacji (nie uniwersalny). Perspektywy Perspektywy view, database view Perspektywa (view) jest to odwzorowanie schematu lokalnego w inny (zmodyfikowany) schemat. Temu odwzorowaniu towarzyszy odwzorowanie danych rzeczywistych lokalnej bazy danych na dane wirtualne lub dane zmaterializowane (wyliczone). Przykadem s perspektywy w SQL. Podstawowe problemy: W przypadku istotnych rnic pomidzy schematami lokalnymi baz danych, odwzorowanie ich w zadany schemat moe by zoone lub niemoliwe.

rodki definiowania perspektyw np. w SQL s za mao uniwersalne. Aktualizacja perspektyw (view updating): problem nie jest rozwizany w stopniu zadowalajcym. Aplikacje (np. w C++) s czsto przywizane do fizycznej postaci danych. Odwzorowanie ich w dane wirtualne powoduje, e wikszo aplikacji przestaje dziaa. Ograniczenie do zapyta (np. w SQL) silnie redukuje rodzaj aplikacji, ktre mog dziaa na schemacie federacyjnym. Wydajno (performance) aplikacji. Perspektywa jak schemat zewntrzny W szerokim znaczeniu: Perspektyw nazywa si odwzorowanie globalnego schematu bazy danych (okrelajcego zapamitane zasoby danych) na schemat zewntrzny, przystosowany do potrzeb i przyzwyczaje konkretnego uytkownika. Architektura ANSI/SPARC: Uytkownik 1 Perspektywa 1 W tym sensie

pojcie perspektywy funkcjonuje w literaturze z zakresu modeli danych, analizy i projektowania. Uytkownik 2 Perspektywa 2 Schemat globalny Poziom fizyczny bazy danych Uytkownik 3 Perspektywa 3 Schematy zewntrzne Projektant BD

Administrator BD Administrator BD Perspektywa jako odwzorowanie W wszym znaczeniu: Perspektyw okrela si nazwane odwzorowanie danych zapamitanych w bazie danych na dane wirtualne, t.j. pochodne lub wyliczalne. Matematycznie, perspektywa jest dowoln funkcj okrelon na danych. Ten punkt widzenia nie jest jednak dostatecznie precyzyjny, gdy nie uwzgldnia mechanizmw nazywania (naming), wizania (binding) i zakresu (scoping), ktre s kluczowe, szczeglnie w przypadku obiektowoci z hierarchi klas, tosamoci obiektw, hermetyzacj i innymi pojciami. Bardziej precyzyjny punkt widzenia: Perspektywa jest procedur funkcyjn, ktra (najczciej, ale niekoniecznie) zwraca wynik bdcy dan typu masowego (zbir, wielozbir, sekwencj). Taki wynik powinien by wyposaony w dodatkowe nazwy (np. nazwy atrybutw wirtualnych obiektw zwracanych przez perspektyw). Perspektywy znane z SQL mieszcz si w tej definicji. S to uproszczone procedury funkcyjne, ktrych ciao mona sprowadzi do pojedynczego zdania: return Po co s perspektywy?

Istnieje wiele wanych zastosowa perspektyw, ktre czyni z nich bardzo gorcy i aktualny temat. Uproszczenie modeli pojciowych dla poszczeglnych uytkownikw. Uproszczenie zapyta poprzez wyliczane obiekty, atrybuty, zwizki. Dostosowanie si do punktu widzenia i terminologii dziedziny zastosowa Ograniczenie dostpu do obiektw, ochrona prywatnoci. Ograniczenie dostpu w systemach rozproszonych federacyjnych baz danych. Logiczna niezaleno obiektw i aplikacji dziaajcy na obiektach. Wspdziaanie systemw heterogenicznych (wsplny schemat). Przystosowanie systemw spadkowych (legacy) do nowszych technologii i wymaga. Hurtownie danych: analiza informacji gromadzonych z rnych rde. Jak s widziane perspektywy w relacyjnych BD? Perspektyw wyznacza zapytanie, np. w SQL, plus drugorzdne rodki syntaktyczne i semantyczne, takie jak zmiana nazw kolumn wirtualnych tablic. Po ewaluacji perspektywa zwraca tablic, koncepcyjnie taka sam jak zapamitane tablice. Popularn i efektywn technik przetwarzania perspektyw jest nie ich ewaluacja (materializacja), lecz modyfikacja zapyta, traktujca perspektyw jako makrodefinicj, oraz czna optymalizacja tekstu zapytania z rozwinitym tekstem definicji perspektywy.

Aktualizacja perspektyw jest ograniczona do pionowego/poziomego obcicia zapamitanych tablic. Nie wystpuj i nie s dyskutowane rodki sterowania intencj aktualizacji perspektywy. Aktualizacja perspektyw odbywa si w tym samym jzyku, co ich definicja (SQL); nie jest rozwaana (chocia by moe osigalna) aktualizacja perspektyw z jzykw niszego poziomu (np. z C). Perspektywy w relacyjnych bazach danych Perspektyw okrela pewne zapytanie, np. SQL. Zdanie definiujce perspektyw okrela nazwy atrybutw wirtualnej tabeli. Zapamitana tabela: Pracownicy( Id_pracownika, Imi, Nazwisko, Stanowisko, Kierownik, Data_zatrudnienia, Zarobki, Premia, Id_dziau ) Definicja perspektywy: CREATE VIEW Urzdnicy( Id_pracownika, Imi, Nazwisko, Zarobki ) AS SELECT Id_pracownika, Imi, Nazwisko, Zarobki FROM Pracownicy WHERE Stanowisko = urzdnik; Uycie perspektywy:

(Zarobki urzdnika o nazwisku Nowak: ) SELECT Zarobki FROM Urzdnicy WHERE Nazwisko = Nowak Perspektywy wolno uy w zdaniach SQL (prawie) na takich samych zasadach jak zapamitanej tabeli. Relacyjna baza danych z perspektywami Uytkownik lub program aplikacyjny SQL Dane wirtualne Dane rzeczywiste (logiczne) Dane zapamitane

(fizyczne) Perspektywa V1 Tablica BD B1 Tablica BD B2 Perspektywa V2 Tablica BD B3 Tablica BD B4 Przykad relacyjnej bazy danych DC

DOSTAWCA DNR CNR ILO DNR NAZW STATUS MIASTO D1 D2 D3 D4 D5 Abacki Bober Czerny Dbek Erbel 20 10 30 20

30 Lublin Pozna Pozna Lublin Radom CZ CNR NAZWAC C1 C2 C3 C4 C5 C6 Nakrtka Wkrt Podkadka Nit Nit

Tulejka KOLOR Czarwony Zielony Niebieski Czerwony Niebieski Czerwony WAGA MIASTO 12 17 17 14 12 19 Lublin Pozna Rzeszw Lublin

Pozna Lublin D1 D1 D1 D1 D1 D1 D2 D2 D3 D4 D4 D4 C1 C2 C3 C4 C5 C6

C1 C2 C2 C2 C4 C5 300 200 400 200 100 100 300 400 200 200 300 400 Przykad bardziej zoonej perspektywy Perspektywa OcenaDostawcy podaje numer dostawcy i sum dostarczanych przez

niego czci. CREATE VIEW OcenaDostawcy( DNR, suma ) AS SELECT DNR, SUM( ILO ) FROM DC GROUP BY DNR; Perspektywa DobryDostawca ustala DNR, nazwisko, status i sum dostarczanych czci dla tych dostawcw, ktrzy dostarczaj ich ponad 600: CREATE VIEW DobryDostawca( DNR, nazwisko, status, suma ) AS SELECT V.DNR, D.NAZW, D.STATUS, V.SUMA FROM DOSTAWCA AS D, OcenaDostawcy AS V WHERE V.DNR = D.DNR AND V.SUMA > 600; Rezultat: Wirtualna tabela o postaci: DROP VIEW DobryDostawca; - usunicie perspektywy z bazy danych. DobryDostawca DNR nazwisko status suma D1 Abacki D2 Bober

D4 Dbek 20 1300 10 700 20 900 Perspektywy wirtualne Perspektywa istnieje wycznie w postaci definicji (np. zapytania, procedury funkc.). Wyliczenie (materializacja) nastpuje w momencie uycia perspektywy. Wynik jest konsumowany i nastpnie kasowany (tak jak wynik procedury funkcyjnej) . Zalety: nie ma dublowania danych, problemw aktualizacji wyliczonych danych, problemw z przetwarzaniem transakcji. Wada: czas ewaluacji perspektyw+czas ewaluacji zapyta uywajcych perspektyw - bez optymalizacji jest bardzo czsto nieakceptowalny. Perspektywy zmaterializowane Perspektywa jest wyliczona na zapas, jej wynik jest przechowywany w bazie danych na normalnych

zasadach. Aktualizacja danych stanowicych podstaw wyliczenia pociga za sob aktualizacj zmaterializowanej perspektywy (lub jej skasowanie i ewentualnie, ponowne wyliczenie). Tego rodzaju perspektywy okrela si take jako zdjcie migawkowe (snapshot). Zalety: szybki dostp, atwa implementacja. Wady: dodatkowe zapotrzebowanie na pami, dodatkowy koszt aktualizacji zmaterializowanych perspektyw (czsto prowadzcy do problemw koncepcyjnych i realizacyjnych), dodatkowe wskie gardo dla transakcji. Zasada przezroczystoci perspektyw view transparency Z punkty widzenia uytkownika dowolne operacje na perspektywach nie powinny niczym rni si od podobnych operacji na zapamitanych danych. Np. jeeli w federacyjnej bazie danych administrator udostpnia tylko cz danych poprzez perspektyw, wwczas programista kocowy nie powinien by zmuszany do modyfikacji programw dziaajcych na zapamitanych

danych z tego powodu, e maj one teraz dziaa na perspektywach. Warunek przezroczystoci perspektyw jest trudny, gdy: Dla pewnych odwzorowa danych zapamitanych w wirtualne przyjte rodki definicji perspektyw (np. SQL) mog okaza si niewystarczajce (schematic discrepancies). Problem aktualizacji perspektyw pozostaje nierozwizany. Pewne dane mog by manipulowane wycznie przez przypisane im interfejsy, a nie przez jzyki zapyta. Problemy z wydajnoci mog unicestwi rozwizania trzech poprzednich problemw. Aktualizacja perspektyw Najpowaniejszym, nierozwizanym problemem jest aktualizacja perspektyw. Aktualizacja wirtualnych danych jest oczywicie niemoliwa, wobec czego naley zamieni t aktualizacj na aktualizacj zapamitanych danych. Aktualizacja Dane wirtualne Perspektyw a Baza danych

Dane zapamitane Na og odwzorowanie danych wirtualnych w dane zapamitane nie jest jednoznaczne. Odwzorowanie aktualizacji danych wirtualnych w aktualizacje danych zapamitanych mona zrobi na wiele sposobw. Czasami takie odwzorowanie odwrotne w ogle nie istnieje. Przykad aktualizacji perspektyw (1) Dane rzeczywiste Dane wirtualne Pracownik Dzia zatrudnia Nazwisko * Nazwa Zarobek /MojeDziay Nazwa redniZarobek

Podwysz redni zarobek w dziale Krasnale ogrodowe o 500 z: update MojeDziay set redniZarobek = redniZarobek + 500 where Nazwa = Krasnale ogrodowe; ? Zlecenie jest bdne, gdy: Nie ma danej o nazwie redniZarobek. Nawet gdybymy chcieli je poprawnie wykona na danych rzeczywistych, mamy do wyboru nieskoczenie wiele sposobw. Prawdopodobnie tylko jeden z nich satysfakcjonowaby naszego szefa, ktry wyda takie polecenie. Przykad aktualizacji perspektyw (2) Dane rzeczywiste zatrudnia Pracownik Dzia * Nazwisko szef Nazwa Zarobek 0..1

Dane wirtualne /MoiPracownicy Nazwisko NazwiskoSzefa Przyjmujemy strategi implementacji perspektyw polegajc na tym, e po wyliczeniu perspektywy MoiPracownicy zwraca ona referencje do nazwiska pracownika i nazwiska jego szefa. Czy problem aktualizacji zosta rozwizany? Pracownik Kowalski, pracujcy dla Styki, ma mie nowego szefa Nowaka. update MoiPracownicy set NazwiskoSzefa = Nowak where Nazwisko = Kowalski; ? Tym razem aktualizacj mona wykona, za nowym szefem Kowalskiego bdzie Nowak. Niestety, nasz system zmieni pewnemu pracownikowi nazwisko Styka na nazwisko Nowak, a chodzio o zupenie co innego, mianowicie, o przeniesienie Kowalskiego do innego dziau. Intencja tego zlecenia zostaa znieksztacona. Ograniczenia w aktualizacji perspektyw System Oracle:

W klauzuli SELECT nie ma sowa DISTINCT W klauzuli FROM jest tylko jedna nazwa tabeli lub tylko jedna nazwa tabeli lub aktualizowalnej perspektywy Na licie SELECT (wynikowej) znajduja si tylko nazwy kolumn W klauzuli WHERE nie ma podzapytania W zapytaniu nie mog wystpowa klauzule GROUP BY i HAVING Ta lista powinna by uzupeniona o wany warunek: mianowicie, wynikowa wirtualna tablica powinna posiada peny klucz gwny (primary key) pewnej zapamitanej tablicy. Warunek ten (Ch.Date) jest logiczn konsekwencj tego, e identyfikacja zapamitanej krotki nastpuje wycznie na podstawie wartoci klucza gwnego. W istocie jednak, systemy relacyjne odeszy od filozofii klucza gwnego na rzecz wewntrznego identyfikatora krotki, w zwizku z czym ten warunek okaza si zbdny. Dodatkowe moliwoci aktualizacji perspektyw W Oracle mona aktualizowa perspektywy powstajce w wyniku zczenia, ale tylko atrybuty relacji znajdujce si po stronie klucza obcego: CREATE VIEW MoiLudzie( IdPracownika, Nazwisko, IdDziau, NazwaDziau, Zarobek) AS SELECT p.Id_pracownika, p.Nazwisko, p.Id_dziau, d.Nazwa, p.Zarobek FROM Pracownicy AS p, Dziay AS d WHERE p.Id_dziau = d.Id_dziau AND p.Stanowisko = programista;

Podwyszy o 500 zarobki wszystkim programistom z dziau Krasnali ogrodowych: UPDATE MoiLudzie SET Zarobek = Zarobek + 500 WHERE NazwaDziau = Krasnale ogrodowe OK. Przenie programist Nowaka do dziau Lalek Barbie: UPDATE MoiLudzie SET NazwaDziau = Lalki Barbie WHERE Nazwisko = Nowak le! Perspektywy s trudnym problemem Perspektywy s problemem, ktry doczeka si efektywnych rozwiza w relacyjnych bazach danych.

Podstawowy problem - aktualizacja wirtualnych danych - nie zosta rozwizany w stopniu zadowalajcym. rodki definicji perspektyw w relacyjnych bazach danych s ograniczone. Implementacje perspektyw nie zakadaj sterowania intencj aktualizacji. Powoduje to, e wszelkie zapowiedzi opanowania poprzez perspektywy problemw takich jak wspdziaanie (interoperability), przenaszalno (portability), ewolucja schematu (schema evolution), itp., s pobonym yczeniem. Dotyczy to szczeglnie kolejnych prac na temat obiektowych perspektyw relacyjnych baz danych. W powszechnej opinii, problem aktualizacji wirtualnych perspektyw jest uwaany za bardzo trudny. Ronie liczba prac nt. zmaterializowanych perspektyw, gdzie problem jest koncepcyjnie prostszy. Tych dwch tematw nie naley myli. Klasyfikacja zoonoci perspektyw Proste perspektywy, np. definiowane poprzez operatory selekcji i projekcji w relacyjnych BD. Maa przydatno dla federacyjnych baz danych. Perspektywy bardziej zoone, np. wymagajce zcze i grupowania, ale wyraalne w SQL i OQL. Problemy z aktualizacj perspektyw i wydajnoci. Perspektywy umoliwiajce zmian reprezentacji danych.

Perspektywy uwzgldniajce niezgodnoci schematw, np. zamieniajce atrybut Zawd z wartociami piekarz, stolarz itd. na wirtualne tabele Piekarz, Stolarz, itd. Wymagaj dostpu do metabazy i mechanizmu refleksji (reflection). Perspektywy uwzgldniajce niezgodnoci semantyczne pomidzy danymi. Czsto nie ma moliwoci odzyskania informacji, ktra pozwoliaby usun te niezgodnoci. Konieczne jest wtedy zrezygnowanie z penej przezroczystoci. Pozostae kryteria klasyfikacyjne: generyczno, moc, stopie uwzgldnienia poj modelu obiektowego, rekurencyjne, perspektywy z Perspektywy z (trwaym)perspektywy stanem, o penej mocy algorytmicznej. parametrami, Wydajno?moliwoci aktualizacji perspektyw, moliwoci optymalizacji, itd.

Kryteria aktualizowalnoci perspektyw Brak nadmiarowej akualizacji. Jeeli uytkownik aktualizuje pewien element perspektywy, nie powinien bezwiednie powodowa aktualizacji innego jej elementu. Brak niedostatecznej/bdnej aktualizacji - wynik aktualizacji nie powinien odbiega od intencji uytkownika. Np. uytkownik aktualizuje zarobek netto o 100 z, tymczasem okazuje si, ze faktyczna aktualizacja wyniosa 91,50 z. Brak efektw ubocznych aktualizacji. Np. takim efektem jest zniknicie 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 kadego stanu bazy danych powinien dziaa tak samo, mimo niejednoznacznoci odwzorowania aktualizacji perspektywy w aktualizacj zapamitanych danych. Podane kryteria s spekulatywnym stereotypem i dotycz sytuacji, kiedy translacja aktualizacji perspektyw jest dokonywana w pewien automagiczny sposb. Przestaj mie sens, jeeli pena kontrola nad aktualizacj perspektyw jest w rkach definiujcego perspektyw. Perspektywy z opcj sprawdzania CREATE VIEW MaoZarabiajcy( Nazwisko, Zarobek) AS SELECT Nazwisko, Zarobek FROM Pracownicy

WHERE Zarobek < 500 WITH CHECK OPTION; Kocowa klauzula oznacza brak efektw ubocznych w postaci znikania krotki po aktualizacji perspektywy. UPDATE MaoZarabiajcy SET Zarobek = Zarobek + 500 WHERE Nazwisko = Marucha Taka aktualizacja spowoduje, e Marucha zostanie usuniety z perspektywy (ale oczywicie, nie z bazy danych) CHECK OPTION oznacza, e ta aktualizacja zostanie odrzucona. Aktualizacja perspektyw w relacyjnych BD Dua liczba artykuw, gwnie teoretycznych, ale (poza opisanymi praktycznymi rozwizaniami) rezultaty tego nurtu s gorzej ni mizerne. Artykuy zakadaj jaki "automagiczny" sposb 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 sposb zmarnowano mas czasu, wysiku i papieru. Przede wszystkim, zmarnowano czas czytelnikw. Prosty pomys polega na przyjciu zaoenia, e sterowanie intencj aktualizacji perspektywy powinno by: skadow definicji perspektywy, znajdowa si w rkach definiujcego perspektyw, zakada imperatywny jzyk (programowania) jako rodek okrelania tej intencji. Perspektywy ze stanem capacity augmenting views, stateful views Klasyczne perspektywy udostpniaj (w inny sposb) informacje, ktra ju s zapamitane w bazie danych. Czsto takie ograniczenie jest nieakceptowalne. Lokalna BD zawiera atrybut stanowisko, ktrego wartoci s numery 11, Przykad 45, 77, itd., gdzie 11 oznacza projektant, 45 oznacza analityk, 77 oznacza sprztaczka, itd. Federacja wymaga penych nazw zawodw. Potrzebna jest

1: dodatkowa funkcja, ktra zamieni numery na stringi. Definicja perspektywy musi wic zawiera definicj trwaej tabeli z numerami i stringami. Przykad 2: Dla celw kontroli utworzona jest perspektywa w postaci tabeli WynikiKontroli( NrUrzdzenia, NazwaUrzdzenia, OcenaKontrolera ) NrUrzdzenia i NazwaUrzdzenia pochodz z lokalnej BD. Natomiast OcenaKontrolera jest atrybutem, ktrego w lokalnej BD nie ma. Jest on wasnoci globalnej aplikacji, gdzie kontroler wpisuje swoj ocen. Jest to zapamitany atrybut, wprowadzony na potrzeby tej perspektywy. Perspektywy ze stanem (oraz autonomia lokalnych BD) oznaczaj konieczno wprowadzenia na poziomie federacji specjalnej BD przechowujcej dane niezbdne do definicji perspektywy. Komplikuje to architektur federacyjnej bazy danych. Przetwarzanie perspektyw w zapytaniach Obowizuj dwie strategie: Materializacja. Perspektywa jest cakowicie liczona w momencie, kiedy sterowanie programu/zapytania osignie punkt, w ktrym wynik tej perspektywy staje si niezbdny dla dalszego przetwarzania. Kade odwoanie si do perspektywy powoduje jej ponowne

wyliczenie (dla uniknicia niespjnoci zwizanych z ewentualn aktualizacj BD). Ta strategia moe by optymalizowana poprzez zmaterializowane perspektywy. Modyfikacja zapyta (query modyfication). Tekst zapytania, w ktrym wystpuje odwoanie do perspektywy, jest scalany z tekstem definicji perspektywy. Nastpnie takie rozwinite zapytanie jest wsplnie optymalizowane na normalnych zasadach. W tej strategii definicja perspektywy jest traktowana jako makro. Poniewa wczeniejszy SQL nie dopuszcza klauzuli SELECT wewntrz klauzuli FROM, kwestia banalnego tekstowego zastpowania przybraa cudaczne formy, owocujc w super-naukowe algorytmy :-) (Stonebraker et al). W SQL-92 t wad usunito. W rnych sytuacjach pierwsza lub druga strategia moe by bardziej optymalna, ale najczciej strategia modyfikacji zapyta jest bardziej skuteczna. Z tego powodu jest ona standardem we wszystkich relacyjnych SZBD. Przykad modyfikacji i optymalizacji zapytania Definicja perspektywy: CREATE VIEW Urzdnicy( Id_pracownika, Imi, Nazwisko, Zarobki ) AS SELECT Id_pracownika, Imi, Nazwisko, Zarobki FROM Pracownicy WHERE Stanowisko = urzdnik;

Uycie perspektywy: SELECT Zarobki FROM Urzdnicy WHERE Nazwisko = Nowak Po tekstowej modyfikacji zapytania: SELECT Zarobki FROM (SELECT Id_pracownika, Imi, Nazwisko, Zarobki FROM Pracownicy WHERE Stanowisko = urzdnik) WHERE Nazwisko = Nowak Usunicie zbdnych astrybutw: Ostateczna optymalizacja:

SELECT Zarobki FROM (SELECT Nazwisko, Zarobki FROM Pracownicy WHERE Stanowisko = urzdnik) WHERE Nazwisko = Nowak SELECT Zarobki FROM Pracownicy WHERE Stanowisko = urzdnik AND Nazwisko = Nowak Perspektywy czce dane zapamitane i wirtualne Dla integracji systemw spadkowych lub sfederowanych potrzebne s perspektywy, ktre cz w jedn kolekcj zarwno dane wirtualne (odwzorowanie danych ze starszych systemw) jak i dane rzeczywiste (pochodzce z nowszych systemw). Stary system: StaryStudent (Id, Nazwisko, RokStudiw, redniaOcena ) Nowy system: NowyStudent (Id, Nazwisko, NrIndeksu ) Pewne atrybuty znikny, pojawi si nowy. Tego rodzaju sytuacje mona sprowadzi do sumy dwch perspektyw: jednej

dziaajca na starych danych i drugiej dziaajcej 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 spjnej aktualizacji oraz wydajnoci. Aktualizacja zmaterializowanych perspektyw Gwny problem w aktualizacji zmaterializowanych perspektyw polega na tym, jak unikn ponownego generowania caej zmaterializowanej perspektywy po aktualizacji bazy danych. Istniej dwie strategie: Okrelenie kryteriw do stwierdzenia, e dana aktualizacja nie wpywa na wyliczon zmaterializowan perspektyw. Np. najprostsze kryterium moe by nastpujce: Jeeli zlecenie aktualizacyjne uywa nazw danych n1, n2,..., definicja perspektywy uywa nazw m1, m2,... przy czym zbiory {n1, n2,...} i {m1, m2,... } s rozczne, wwczas

zlecenie aktualizacyjne nie wpywa na wynik materializacji perspektywy. Ustalenie zwizku pomidzy fragmentami bazy danych i fragmentami zmaterializowanej perspektywy w taki sposb, aby dany fragment zmaterializowanej perspektywy by funkcj danego fragmentu bazy danych. W tym przypadku moliwa jest aktualizacja przyrostowa (incremental), tj. po aktualizacji bazy danych modyfikowany/przeliczany jest tylko fragment perspektywy. Metoda zaley od formy definicji perspektywy. Moliwe jest wczenie aktywnych regu wyzwalajcych przeliczenie fragmentw zmaterializowanej perspektywy. Mao prac zajmuje si odwzorowaniem aktualizacji perspektywy na aktualizacj oryginalnych danych, ale problem bardzo przypomina techniki replikacji. Perspektywy obiektowe (1) Wskutek wtoczenia w problem perspektyw ogromnej liczby poj obiektowych i innych, przy braku spjnego i jednorodnego modelu formalnego, propozycje rozwizania tego problemu s partykularne, nieregularne, niedostatecznie generalne, obcione drugorzdnymi szczegami, sporym bagaem syntaktycznym i mtnymi dywagacjami semantycznymi. Podstawowa metoda przetwarzania perspektyw, czyli modyfikacja zapyta, zostaa zapomniana. O optymalizacji zapyta wczajcej

perspektywy w ogle si nie wspomina. Nawet jeeli s propozycje aktualizacji perspektyw, z reguy s one ograniczone do takich ich rodzajw, ktre zwracaj zapamitane obiekty w niezmienionej postaci. W tym wzgldzie sytuacja jest gorsza ni w modelu relacyjnym. Perspektywy obiektowe (2) Nie wystpuj rodki sterowania intencj aktualizacji perspektywy. Nie wystpuj perspektywy rekurencyjne i perspektywy z parametrami. wiat nie dojrza... Problemem s niespjne i ograniczone podejcia do obiektowych jzykw zapyta. Funkcjonuje dua ilo faszywych stereotypw, z ktrych cz pochodzi ze zbyt dosownego przeniesienia do obiektowoci paradygmatw modelu relacyjnego Brak zintegrowania obiektowych jzykw zapyta z konstrukcjami imperatywnymi, niepotrzebny nacisk (patrz ODMG), aby tego rodzaju konstrukcje oddelegowa do obiektowych jzykw programowania takich jak C++, Java i Smalltalk (gdzie problem aktualizacji perspektyw staje si niewyraalny). Refleksja nt. obiektowych perspektyw... Problem obiektowych perspektyw dla prostego przypadku jest banalny.

Mona przyj, e perspektywa wyznacza podzbir obiektw pewnej klasy, za caa semantyka rzeczywistych obiektw jest przeniesiona do obiektw wirtualnych. To rozwizanie mona wzmocni ograniczeniem dostpu do pewnych atrybutw (patrz rozwizanie w O2 lub COCOON) Podejcie to mona zastosowa w stosunku do aktualizacji perspektyw. Analogi s perspektywy w SQL z wykorzystaniem wycznie selekcji. Generalny problem perspektyw jest trudny, poniewa brakuje uniwersalnego modelu obejmujcego wszystkie najwaniejsze aspekty obiektowoci, wczajc klasy, cechy proceduralne, metody, itd. Rozwizanie problemu perspektyw dla bardziej oglnego przypadku jest moliwe przy zastosowaniu podejcia stosowego, ktre zapewnia niezbdn oglno, prostot i unifikacj poj. Jak dotd nikt nie wynalaz lepszego podejcia. Produkuje si nowe kulawe podejcia (np. w kontekcie XML) dajce zudzenie, e problem da si opanowa przy pomocy prostszych rodkw. Podejcia do obiektowych perspektyw Podejcie Abiteboula i Bonnera, Rundensteinter et al (MultiView), Kifera, Kima i Sagiva, Scholla et al (COOL/COCOON), LIVING IN A LATTICE, Edera i inne. Rnice pomidzy tymi podejciami polegaj na arbitralnym wyborze wasnoci perspektyw i ustaleniu dla nich konstrukcji skadniowej. Konstrukcja ta obejmuje szereg ortogonalnych cech pochodzcych z dwch wymienionych na pocztku

pogldw na pojcia perspektywy oraz ich potencjalnych zastosowa (np. ograniczenie dostpu, zintegrowanie z systemem klas, itd.) Moje podejcie jest rne od zaproponowanych. Polega na przyjciu zaoenia, e: Perspektywa jest procedur funkcyjn zdefiniowan w jzyku zapyta, zwracajc kombinacj referencji, nazw i wartoci. To pocztkowe zaoenie jest nastpnie nieco modyfikowane. Tak rozumiana perspektywa korzysta z normalnych wasnoci obiektowych struktur danych, w szczeglnoci, struktury moduw i klas, rodkw ograniczenia dostpu, itd. rodki dodatkowe dla tak rozumianej perspektywy s ograniczone do minimum. Perspektywy jako procedury funkcyjne Konieczne jest okrelenie: Gdzie taka procedura funkcyjna jest umieszczona w strukturze obiektowej? W zalenoci od tego, moemy mie wirtualne obiekty, jeeli procedura jest na czubku struktury obiektowej, lub wirtualne atrybuty, jeeli procedura jest metod zdefiniowan wewntrz klasy. Na jakim rodowisku taka funkcja dziaa? Chodzi o reguy zakresu. Jak wynik takiej procedury ma by podczony do istniejcych lub nowych klas? Co taka procedura funkcyjna zwraca? Chodzi o ich dziedzin semantyczn. W jaki sposb wynik takiej procedury (czyli wirtualne dane) jest udostpniony dla innych konstrukcji danego jzyka zapyta lub programowania? Czy taka procedura funkcyjna moe mie parametry? Jakie to ma konsekwencje?

Czy taka procedura moe by rekurencyjna? Jakie to ma konsekwencje? Czy taka procedura moe mie imperatywne ciao i lokalne rodowisko danych? Jaki jest stosunek takich procedur do standardowych mechanizmw ograniczenia dostpu do danych? Przetwarzanie zapyta Przetwarzanie zapyta w rozproszonych BD Przetwarzanie zapyta powinno minimalizowa zarwno obcienie linii transmisyjnych jak i pracochonno przetwarzania po stronie klienta (globalnej aplikacji) jak i po stronie serwerw. Przetwarzanie wycznie po stronie klienta (gruby klient): ogromne obcienie linii transmisyjnych. Przetwarzanie wycznie po stronie serwerw (chudy klient): moe powsta wskie gardo wskutek tego, e jednoczenie wielu klientw bdzie da usugi od jednego serwera. Generalna zasada: "wylij zapytanie do danych, a nie dane do zapytanie" nie dla wszystkich przypadkw jest suszna i rodzi problemy koncepcyjne. Przetwarzanie zapyta odbywa si poprzez: dekompozycj zapytania na operacje wysyane do rnych wzw, porzdkowanie tych operacji,

zbieranie ich rezultatw oraz ich przetwarzanie przez klienta w celu skonstruowania ostatecznego wyniku zapytania. Strategie optymalizacji zapyta w rozprosz. BD Przetwarzanie wycznie po stronie klienta. Pobiera on wszystkie dane potrzebne do realizacji zapytania do swojego obszaru => duy czas i koszt transmisji danych, mae problemy koncepcyjne. "Statyczna" (jednoczesna) dekompozycja zapytania na podzapytania, wysanie ich do lokalnych miejsc, przesanie rezultatw podzapyta do klienta, ktry czy tych rezultaty w globalny rezultat. Skuteczna dla podziau poziomego danych i zapyta ograniczonych do selekcji/projekcji, nieskuteczna dla zapyta zoonych. "Dynamiczna" dekompozycja: generacja podzapytania do miejsca 1 i przesanie wyniku 1 do centralnego miejsca; generacja podzapytania do miejsca 2 i przesanie wyniku 2 do centralnego miejsca, itd. Brak rwnolegoci dziaania serwerw, trudnoci koncepcyjne. Hybrydowa dekompozycja - poczenie dekompozycji statycznej i dynamicznej. Hybrydowa dekompozycja z przesaniem danych do serwera. Klient nie tylko dokonuje wysania podzapytania do serwera, ale rwnie przesya do niego cz danych, ktre otrzyma od innych serwerw (aby umoliwi serwerowi skuteczniejsz optymalizacj podzapytania).

Indeksowanie rozproszonych zasobw Szczeglnie istotne w przypadku technologii P2P, ale nie tylko. Indeks centralny, adresujcy cae zasoby rozproszonej sieci. Przykadem wykorzystania indeksw centralnych jest Napster oraz liczne motorki wyszukiwawcze takie jak Google lub AltaVista, Indeksy lokalne replikowane, trzymane przez klientw celem szybkiego zlokalizowania miejsc z interesujcymi danymi. W tym przypadku dua cz optymalizacji zapytania moe by wykonana przez klienta zanim on wyle zlecenia do odlegych serwerw. Problem z indeksami centralnymi - zaleno caoci rozproszonej bazy danych od jednego miejsca. Problemy z indeksami lokalnymi replikowanymi: kopotliwa aktualizacja indeksw moliwo powstawania niespjnoci wskutek opnie lub braku moliwoci aktualizacji indeksw straty przestrzeni dyskowej Statyczny schemat przetwarzania zapyta (1) 1. Klient realizuje zapytanie Z odwoujce si do danych na serwerach S1, S2,..., Sk 2. Klient dokonuje odwzorowania zapytania Z na zapytania Z1, Z2, ... , Zk adresowane do serwerw S1, S2,..., Sk. Odwzorowanie wymaga

znajomoci lokalnych schematw danych. 3. Zapytania Z1,Z2,...,Zk s konstruowane z Z w taki sposb, aby wyniki tych zapyta W1, W2,...,Wk uzyskane z poszczeglnych serwerw day moliwo utworzenia globalnego wyniku W. 4. Zapytania Z1,Z2,...,Zk s kierowane do serwerw S1, S2,..., Sk, gdzie s wykonywane. 5. Serwery zwracaj do klienta wyniki W1, W2,...,Wk zapyta Z1,Z2,...,Zk 6. Klient dokonuje scalenia wynikw W1, W2,...,Wk w globalny wynik w. Statyczny schemat przetwarzania zapyta (2) Klient Dekompozycja zapytania Z Scalenie wynikw Wynik W zapytania Z Z1 Z2 W1 Serwer S1 Serwer S2

W2 Zk Wk ... Serwer Sk Statyczny schemat ma przede wszystkim zastosowanie w przypadku poziomej fragmentacji danych, np. rozbicia obiektw Pracownik na wiele podzbiorw o takiej samej budowie przechowywanych na poszczeglnych serwerach. W tym przypadku dekompozycja zapytania oznacza po prostu jego skopiowanie: Z = Z1 = Z2 = ... = Zk Scalenie wynikw polega na sumie mnogociowej wynikw czstkowych. Dynamiczny schemat przetwarzania zapyta 1. Klient realizuje zapytanie Z odwoujce 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 sposb, 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 znajomoci W1 klient konstruuje z Z kolejne podzapytanie Z2 kierowane do serwera S2. Moe do tego serwera skierowa pewien fragment W1, nazwijmy go F1; .... proces jest powtarzany dla wszystkich serwerw, a do uzyskania rezultatu. Klient Z Z1 (Z, W1) Z2, F1 (Z, W1, W2) Z3, F2 Scalenie wynikw Z1 W1 Serwer S1 Z2, F1 W2 Serwer S2

Z3, F2 W3 Serwer S3 Przykad: technika p-zcze (1) Serwer 1 Serwer 2 DOSTAWCA DC DNR NAZW STATUS MIASTO DNR CNR ILO D1 Abacki D2 Bober D5 Erbel

20 Lublin 10 Pozna 30 Radom D1 D1 D2 D2 D3 D4 D4 D4 C4 C5 C1 C2 C2 C2 C4 C5

200 100 300 400 200 200 300 400 Klient ma dokona zczenia relacji DOSTAWCA i relacji DC: select * from DOSTAWCA, DC where DOSTAWCA.DNR = DC.DNR semijoin Przykad: technika p-zcze (2) W celu realizacji zapytania klient musi wykona nastpujce czynnoci: 1. Sciag dane z serwera 1 przy pomocy zapytania Z1: select * from DOSTAWCA Uzyska w ten sposb wynik W1. W1

DNR NAZW STATUS MIASTO D1 Abacki D2 Bober D5 Erbel 20 Lublin 10 Pozna 30 Radom 2. Tworzy pomocnicz tabel poprzez projekcj W1 na DNR: t tabel nazywa F1. F1 DNR D1 D2 D5 3. Wysya tabel F1 do serwera 2 dajc tymczasowego ulokowania jej w bazie danych serwera 2; nastpnie wysya tam zapytanie Z2: select * from DC, F1 where DC.DNR = F1.DNR Przykad: technika p-zcze (3) 4. Uzyska w ten sposb wynik W2: Jest to tzw. p-zczenie relacji DC,

parametryzowane relacj DOSTAWCA. W2 DNR CNR ILO D1 C4 200 D1 C5 100 D2 C1 300 D2 C2 400 P-zczenie relacji R1, parametryzowane relacj R2, powstaje poprzez zczenie R1 z R2, a nastpnie projekcj wyniku na atrybuty relacji R1 5. Przesya wynik W2 - p-zczenie - do klienta

6. Klient dokonuje ostatecznego scalenia wynikw - zczenia relacji W1 i W2. Wynik DNR D1 D1 D2 D2 NAZW STATUS MIASTO CNR ILO C4 200 Abacki 20 Lublin C5 100 Abacki 20 Lublin C1 300 Bober 10 Pozna C2

400 Bober 10 Pozna W zalenoci od oceny kosztw przetwarzania i transmisji klient moe zacz od cignicia danych z serwera 2 i nastpnie dokona p-zczenia relacji DOSTAWCA. Metody dostpu do baz danych sterowniki Potrzeby ? Rne DBMS mog realizowa rne wersje SQL dla realizacji jzykw definicji danych (DDL) i manipulacji danymi (DML). Interfejsy bezporedniego dostpu do tych DBMS, stworzone przez rnych producentw, te mog si rni. Wskutek tego konsekwentnoci zapyta SQL do rnych baz danych, rnych serwerw SQL mog te si rni. To znaczy, np., e dla bazy danych w rodowisku ORACLE trzeba konstruowa inne konsekwentnoci zapyta SQL ni dla tej samej bazy w rodowisku INFORMIX. W celu usunicia tej wady firma MICROSOFT w 1992r

opracowaa standard ODBC (Open Database Connectivity). Co to jest ODBC ? Technologia ODBC wprowadza jedyny interfejs dostpu do rnych typw baz danych. Jzyk SQL jest wykorzystywany jako gwny uniwersalny dialekt wszystkich baz danych. Standard ODBC pozwala realizowa technologi Klient Serwer, ktra realizuje gwne operacji przetwarzania danych na serwerze, a klient tylko otrzymuje rezultaty. Aplikacje nie s poczone z konkretnym interfejsem jakikolwiek DBMS, a realizuj jedyny standard zapyta do menedera ODBC sterownikw (ODBC-drivers). Meneder ODBC podcza potrzebny ODBC sterownik, ktry jest stworzony przez producenta konkretnej DBMS. Dla podczenia ODBC sterownika trzeba stworzy profile ODBC w trybie (Source ODBC) panelu sterowania systemu operacyjnego. Teraz istniej ponad 50 typw ODBC sterownikw dla rnych DBMS. Standard ODBS pozwala realizowa zapytania SQL bezporednio z programw uytkownika. W tym celu mona wykorzystywa dynamiczny SQL.

Architektura ODBC A p p lic a tio n 1 A p p lic a tio n 2 ... A p p lic a tio n N The m anager of d r iv e r s O D B C D r iv e r O DBC ACCESS S o u r c e o f d a ta O DBC ACCESS D r iv e r O DBC

SYBASE S o u r c e o f d a ta O DBC SYBASE ... S o u r c e o f d a ta O DBC ORACLE ... F ig . 3 3 D r iv e r O DBC ORACLE Schemat wsppracy rnych narzdzi w architekturze Klient Serwer w sieci LAN

C lie n t a p p lic a tio n 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. C lie n t M S W in d o w s O D B C d r iv e r m anager O D BC d r iv e r lo c a l d a ta

te x t O DBC d r iv e r D B M S -2 F ile S y s te m O D BC d r iv e r D B M S -1 S e rv e r 1 DBM S - 1 N e t D r iv e r N e t D r iv e r L o c a l D is k L o c a lN e t

S e rv e r 2 DBM S - 2 N e t D r iv e r F ig . 3 4 Gwne wady technologii dostpu do baz danych przez ODBC Aplikacje s przystosowane do platformy MS Windows Wzrasta czas obrbki zapyta dziki dodatkowej warstwie programwJest potrzebna uprzednia instalacja ODBC sterownika, profile ODBC dla kadej stacji. Parametry tej instalacji jest statyczne i uytkownik nie moe ich zmieni. Uniwersalne strategii dostpu Technologia ODBC firmy Microsoft zaopatrzy oglny interfejs dostpu do baz danych, ktre s kompatybilne przez SQL. Kada baza danych majca interfejs ODBC zawiera sterownik (driver) , ktry realizuje bezporednio ten interfejs. Interfejs zawiera bibliotek funkcji specjalnych napisanych w

jzyku C++ . Zastosowanie tej biblioteki moe by wad przy realizacji dostpu aplikacji stworzonych w innym rodowisku jzykw oprogramowania. eby usuwa te wady rne producenci stwarzaj specjalne komponenty obiektowe dostpu do baz danych. Przykad komponentw firmy Microsoft U s e r A p lic a tio n D A O (R D O ) ADO O LE DB O DBC DB SQ L F ig 3 5 Przykad komponentw 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 rezultatw zapyta do bazy danych (component RecordSet) oraz inne obiekty. Model DAO jest przeznaczony przede wszystkim dla dostpu 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 zaproponowaa zbir obiektw OLE DB( Object Linking and Embedding for DataBase), ktry pozwala aplikacjom wykorzystywa oraz sterowa danymi w bazach danych przez swoje obiekty. Technologia OLE DB gwarantuje dostp do jakikolwiek baz danych wcznie nie relacyjne modeli danych. Oprcz tego przez OLE DB mona udostpni do plikowych oraz pocztowych systemw, graficznych plikw, innych obiektw stworzonych w rnych aplikacjach. Technologia OLE DB jest obiektowo - orientowana specyfikacja na podstawie C++ API. Przykad komponentw firmy Microsoft cd Technologia ADO (Active Data Obiects) to jest rozwizanie

technologii ASP dostpu do baz danych, ktre 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 nastpne funkcje: Stworzenia niezalenych obiektw baz danych Wsparcie zapamitanych procedur baz danych Stworzenia kursorw dostpu do danych Wsparcie mechanizmw transakcji. Gwnymi zaletami technologii ADO s nie komplikowane wykorzystanie, prdko, mae obcigi RAM oraz disku. Przykad komponentw firmy Microsoft cd Model obiektowy ADO zawiera 6 gwnych klasy obiektw: CONNECTION COMMAND PARAMETERS RECORDSET FIELDS ERRORS.

Obiekt CONNECTION poczy zwizek pomidzy aplikacj oraz rdem danych. Utworzenia takiego poczenia zawsze jest pierwszym etapem obsugi bazy. Ten obiekt pozwala take uruchomi instrukcje SQL. Dla zachowywania rezultatw instrukcji trzeba stworzy obiekt klasy RECORDSET. Klasa CONNECTION zawiera nastpne metody: Open( ) , Close( ) poczenie lub wyczenia ze rdem danych Execute( ) uruchomienie instrukcji dla wyznaczonego poczenia BeginTrans( ), CommitTrans( ) oraz RollbackTrans( ) sterowanie transakcjami dla danego poczenia. Przykad komponentw firmy Microsoft cd C onnect O E B C R p e n () x e c u te ( ) e g in T r a n s () o m m itT r a n s ( )

o llb a c k T r a n s ( ) E rro rs E rro r C om m and E x e c u te ( ) C re a te P a ra m e tr () P a ra m e te rs R e c o rd s e t B O F E O F R e c o rd C o u n t M M M M M A

U D O C o v e F ir s t ( ) oveLast ( ) o v e N e x t () o v e P r e v io u s () o v e () d d N e w () p D a te () e le te () p e n () lo s e () A ppend ( ) D e le te ( ) Ite m () R e fre s h () P a ra m e te r

F ie ld s F ig 3 6 F ie ld Przykad komponentw firmy Microsoft cd Obiekt COMMAND zawiera instrukcj SQL lub wywoanie zapamitanej procedury. Ten obiekt moe mie kolekcj parametrw, ktre mog by zadane przez obiekty klasy PARAMETER. Klasa COMMAND zawiera nastpne metody: Execute( ) uruchomianie instrukcji dla danego poczenia CreateParameter( ) tworzenie nowego parametru(obiektu klasy PARAMETER) Kolekcja PARAMETERS zawiera wszystkie parametry, ktre s wykorzystywane razem z danym obiektem COMMAND. Parametry te s przechowywane w obiektach klasy PARAMETER. Klasa PARAMETERS zawiera nastpne metody: Append(), Delete() dodawanie (usuwanie) parametru dla danej kolekcji Item() wywoanie wyznaczonego obiektu PARAMETR Refresh() wywoanie informacji pro parametry waciciela

zapamitanej procedury. Przykad komponentw firmy Microsoft cd Obiekt RECORDSET pozwala na operowania danymi przechowywanymi w tabeli. Obiekt ten zawiera zbir rekordw 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 pooenie wzgldem pozostaych rekordw zbioru okrelane przez kursor bazy danych. Kursor to jest obiekt zawierajcy rezultat polecenia do bazy danych. Przy stworzeniu obiektu RECORDSET wskanik rekordu biecego kursora odwzorowuje pierwszy rekord zbioru, a atrybuty BOF oraz EOF otrzymaj wartoci FALSE. Kiedy zbir jest pusty atrybut RecordCount otrzyma warto 0 (zero), lecz BOF oraz EOF wartoci TRUE. Przykad komponentw firmy Microsoft cd Klasa RECORDSET zawiera nastpne metody : MoveFirst(), MoveLast(), MoveNext(), MovePrevious() oraz Move()

przesuwaj wskanik rekordu biecego. Obiektami RECORDSET s kursory, ktre mog by sterowanymi tylko w jednym kierunku lub w dwch kierunkach zbioru rekordw. W przypadku jednokierunkowego kursora mona przechodzi jedynie do nastpnego rekordu zbioru, nie istnieje moliwoci cofania si do poprzedniego wiersza lub przeskakiwania o kilka rekordw do przodu lub do tylu zbioru. Tutaj moe by wykorzystywana tylko metoda MoveNext(). Dla wyznaczenia koca lub pocztku rekordw trzeba wykorzysta atrybuty BOF oraz EOF obiektu RECORDSET. AddNew(), Update() oraz Delete() dodawanie nowych rekordw, aktualizacja oraz usuwanie istniejcych rekordw, ktre jest zwizane z obiektem REKORDSET. Open(), oraz Close() uruchomienie (Zamknicie ) kursora, ktry reprezentuje rezultaty instrukcji, ktra jest poprzednio stworzona przez obiekt COMMAND. Metoda Open() odsya na ju stworzony obiekt CONNECT. Przykad komponentw firmy Microsoft cd Kady obiekt RECORDSET zawiera kolekcj FILDS, ktra s zbiorem obiektw klasy FIELD. Kady obiekt FIELD reprezentuje jedn kolumn tabeli danych. Na kady obiekt FIELD w kolekcji FIELDS mona odwala przez nazw lub liczb numeryczn.

Kolekcja ERRORS jest stworzona dla zachowywania informacji pro jakikolwiek bdy. Obiekt ERROR reprezentuje bd wygenerowany przez rdo danych. Kolekcja ERRORS jest uywana w sytuacji, gdy jedno wywoanie metody moe wygenerowa wiksz ilo bdw. Przy stworzeniu obiektu RECORDSET mona wykorzysta dwa typy kursorw: jednokierunkowy lub dwukierunkowy. Podczas wywoania metody Open() obiektu RECORDSET domylnie tworzony jest kursor jednokierunkowy. Kursor tego typu jest najbardziej efektywny, jednak oferuje ograniczone moliwoci poszukiwania si po zbiorze rekordw . Przykad komponentw firmy Microsoft cd Dwukierunkowe kursory zawieraj nastpne typy: Statyczny. Wyniki wykonania zapytania s przechowywane w tabeli tymczasowej, ktrej wierszy nie s modyfikowane w momencie, gdy kursor jest otwarty. Zbir kluczy. Kursory tego typu zapisuj w tymczasowej bazie danych klucze wszystkich wierszy zwrconych w wyniku wykonania polecenia. Dziki przechowywaniu jedynie kluczy, wszelkie modyfikacj rekordw wykonane w czasie gdy kursor jest otwarty, bd zauwaane.

Dynamiczny. W przypadku uycia kursora dynamicznego za kadym razem, gdy zadamy nowego rekordu, polecenie okrelajce zawarto zwracanych wynikw jest ponownie wykonywane. Oznacza to, e wszelkie modyfikacje wprowadzane w tabeli bazy danych bd widoczne, a co wicej, dodanie nowego rekordu moe mie wpyw na zawarto wynikowego zbioru rekordw. Dostp w Jawie przez JDBC - sterownik Java, jako nowoczesny jzyk programowania, posiada m.in. moliwoci zwizane z podczeniem si i operowaniem na bazach danych. Jednak zaoeniem projektantw Javy byo stworzenie jzyka, ktrego kod byby przenony midzy rnymi systemami operacyjnymi. Tak przenono posiada Java w dziedzinie zastosowa aplikacji bazodanowych. Java take wykorzysta technologi ODBC. Zostaa ona realizowana jako interfejs niezaleny od architektury bazy danych i ma nazw JDBC (ang. Java DataBase Connectivity). JDBC jest pomostem pomidzy przestrzeniami bazy danych, majc sterownik ODBC, i aplikacji, napisanej w jzyku Java. Interfejs ten operuje na poziomie SQL.

Dziki JDBC aplikacje bazodanowe napisane w Javie s niezalene od sprztu oraz stosowanej bazy danych. Niezaleno od systemu operacyjnego zapewnia sama Java. JDBC - sterownik Sterownikiem JDBC, czcym aplikacj z konkretn baz danych, nazywa si zestaw klas, ktre implementuj interfejs ODBC. Zadaniem JDBC jest ukrycie przez programista wszelkich specyficznych wasnoci bazy danych. Dziki temu programista moe skupi si wyczne na swojej aplikacji, nie wdajc si w szczegy zwizane z obsug uywanej przez niego bazy danych. Aby umoliwi niezaleno od platformy, JDBC udostpnia menedera sterownikw ODBC, ktry dynamiczne zarzdza rnymi obiektami sterownikw. Obiekty te bd wykorzystywa zapytania do bazy danych. JDBC - sterownik kolejno czynnoci Kolejno dostpu do bazy danych zawiera nastpne czynoci: 1) Zaadowa do pamici potrzebny sterownik JDBC. To mona zdarzy nastpnym sposobem: Class.forName ("sun. jdbc.odbc.JdbcOdbcDriver")

Argumentem metody forName() jest obiekt typu STRING. Jest on nazw klasy sterownika wraz z nazw pakietu, ktry trzeba zaadowa. Po zaadowaniu sterownik staje si dostpnym dla aplikacji. 2) Dla poczenia 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 sposb, e moliwe jest zaadowanie do pamici odpowiedniego sterownika ODBC i uzyskanie poczenia z baz. Drugi i trzeci parametry oznaczaj odpowiednio nazw uytkownika bazy danych i haso dostpu do niej. Jeeli baza danych nie potrzebuje identyfikatora oraz hasa, drugi oraz trzeci parametry s nieobecne. Standartowa skadnia URLa jest nastpujca: jdbc::. JDBC to typ protoku, subprotok okrela nazw wykorzystanego sterownika (w tym wypadku ODBC), subnazwa jest nazw identyfikujc baz danych, nazwa profilu ODBC. Przykad poczenia z baz danych: Connection con; String url = "jdbc:odbc:biblio"; con = DriverManager.getConnection(url); JDBC - sterownik kolejno czynnoci cd 3) Wykona zapytanie SQL do bazy danych. Dla wykonania

zapytania SQL do bazy danych, mamy do wyboru jeden z interfejsw: Statement, PreparedStatement lub CallableStatement. Wszystkie trzy su zasadniczo jednemu: wykonaniu zapytania SQL-owego. Tworzenie obiektw z grupy Statement ma nastpujc posta: Statement stmt; gdzie stmt = con.createStatement(); Obiektu Statement uywamy do wykonania zapyta SQL. Rezultaty zapytania s przechowywane w obiektu ResultSet: String query; // wiersz operatora SQL query = "SELECT FROMWHERE; ResultSet rs; // pole dla rezultatu zapytania SQL rs = stmt.executeQuery(query); JDBC - sterownik kolejno czynnoci cd 4) Wywola dane ze zbioru skutecznego. Obiekt ResultSet reprezentuje wynik zapytania SQL i zawiera zbir rekordw z danymi. Stosujc metod next() tego obiektu, moemy mie dostp do wszystkich danych: more = rs.next(); Zatem stosujc metod getXXX(nazwa_pola) trzeba zdarzy

dostp do danych biecego rekordu. Na przykad: While (rs.next()) { Int x = rs.getInt (pole1); String s =rs.getString (pole2); Float f = rs.getFloat (pole3); } JDBC - sterownik kolejno czynnoci cd S tru k tu ra J D B C R e s u ltS e t R e s u ltS e t R e s u ltS e t S ta te m e n t P re p a re d S ta te m e n t C a lla b le S ta te m e n t

C o n n e c tio n D r iv e r M a n a g e r O r a c le D r iv e r J D B C -O D B C D r iv e r ... O D B C D r iv e r BD BD F ig 3 7 BD JDBC - przykady uycia

Podczas dziaania aplikacji bazodanowej mog wystpi rnego rodzaju sytuacje powodujce, e okrelone operacje na bazie zakocz si niepowodzeniem. Dlatego wane jest, aby aplikacja potrafia obsuy tego typu zdarzenia. Pomocny okazuje si mechanizm obsugi wyjtkw. W takich przypadkach wykorzystujemy klas SQLException. Przykad 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 poniej dodaje now tabel SKLEP public class JdbcCreateTable { public static void main(String args[]) { String url = "jdbc:odbc:biblio"; Connection con; String createString; createString = "create table SKLEP " + "(SKL_NAME varchar(32), " +"SkL_ID int, " + "SKL_ADDR varchar(32), " +"SKL_INV varchar(32))"; JDBC - przykady uycia cd..

Statement stmt; try { // Uruchomienie ODBC sterownika (bryda Java ODBC) Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); } catch(java.lang.ClassNotFoundException e) { System.err.print("ClassNotFoundException: "); System.err.println(e.getMessage()); } try { // Realizujemy poczenie z baz biblio con = DriverManager.getConnection(url); //tworzymy obiekt Statement dla przeniesienia SQL instrukcji stmt = con.createStatement(); // uruchomienie instrukcji stmt.executeUpdate(createString); // usunicie objektw stmt.close(); con.close(); } catch(SQLException ex) { System.err.println("SQLException: " + ex.getMessage()); } }

} JDBC - przykady uycia cd.. //---------------------------------------------------------------------------------Przykad 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 poczenia z baz danych static Connection dbcon; /* Podprogram gwny*/ public static void main(String args[]) throws Exception { // Uruchomienie ODBC sterownika (bryda Java ODBC) Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); // otworzenie bazy danych open (); // Odwzorowanie wszystkich wierszy w bazie select ("And Authors.Au_ID < 20 )"); // Uaktualnienie rekordw oraz formowanie rezultatu update (); // zamknicie bazy danych

close(); } JDBC - przykady uycia cd.. // Odwzorowanie wszystkich wierszy w bazie select ("And Authors.Au_ID < 20 )"); // Uaktualnienie rekordw oraz formowanie rezultatu update (); // zamknicie bazy danych close(); } /* otworzy poczenie z baz danych */ static void open() throws SQLException { /* Zada imi rda ODBC, nazwiska uytkownika i hasa String dsn = "jdbc:odbc:biblio"; String user = ""; String password = ""; /* Uruchomienie menedera sterownika dla poczenia dbcon = DriverManager.getConnection(dsn,user,password); /* Domylnie fiksacja transakcji jest dokonywana automatycznie, dla tego funkcja AutoCommit() jest odczona */ dbcon.setAutoCommit(false);

} /* okrelenie wszystkich czekajcych na zakoczenie transakcji oraz zamknicie bazy danych */ static void close() throws SQLException { dbcon.commit(); dbcon.close(); } JDBC - przykady uycia cd.. // Odwzorowanie wszystkich wierszy w bazie /* okrelenie wszystkich czekajcych na zakoczenie transakcji oraz zamknicie 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; // przecznik "wiersze dodatkowe s obecne /* Przygotowanie zapytania SQL , konstruowanie operatora SQL, wypenienie zapytania

SQL */ //query = "SELECT Authors.Author FROM Authors WHERE (Au_ID < 20 // );"; query = "SELECT Authors.Author, Titles.Title, Publishers.`Company Name` "; query = query + "FROM Authors, `Title Author`, Titles, Publishers "; query = query + "WHERE (Authors.Au_ID = `Title Author`.Au_ID AND "; query = query + "`Title Author`.ISBN = Titles.ISBN AND "; query = query + "Titles.PubID = Publishers.PubID " + whereClause; stmt = dbcon.createStatement(); rs = stmt.executeQuery(query); JDBC - przykady uycia cd.. /* sprawdzenie obecnoci wierszy, ktre bd zwrcone */ more = rs.next(); if (!more) { System.out.println("No rows found"); return; } /* Cykl dla obrbki wierzy, ktre s wybrane */ while (more) { pr = rs.getString("Author"); System.out.println("Autor: " + pr); pr = rs.getString("Title"); System.out.println("Title: " + pr); pr = rs.getString("Company Name"); System.out.println("Publishers: " + pr);

System.out.println(""); more = rs.next(); } rs.close(); stmt.close(); } /* Otrzymanie zapyta SQL bez klauzuli WHERE*/ static void select() throws SQLException { select(""); } } Rozproszone bazy danych a technologie dostpu Przykadowa architektura klient serwer w PostgreSQL SERWER Linux Windows KLIENT

KLIENT KLIENT Wielu klientw Poczenie Poczenie ODBC UNIX Dostp POSTMASTER POSTMASTER POSTMASTER Wiele operacji dostpu

BAZA DANYCH Konieczno dostpu do bd z www Protok HTTP (Hypertext Transfer Protocol) Dostp do informacji w postaci stron WWW Informacja prezentowana w sposb nieliniowy (hipertekst) Prezentacja rnych typw informacji (tekst, grafika, wykres, wideo) Znajomo adresu serwera lub strony jako warunek konieczny pozyskania informacji Przegldarka - sposb dostpu do informacji Identyfikacja rde danych URL (Uniform Resource Locator) - uniwersalny sposb lokalizacji zasobw Struktura URL:

usuga://adres_serwera (http://pluton.pol.lublin.pl) usuga:[email protected]_serwera (mailto:[email protected]) usuga://adres_serwera/katalog (ftp://ftp.wspa.lublin.pl) usuga://adres _serwera/katalog/dokument (http://pluton.pol.lublin.pl/wti.htm) Wykorzystanie: odnoniki do innych stron WWW (linki) odnoniki do innych usug sieciowych Identyfikacja rde danych a bd w internecie Dostp bezporedni do rda: znajomo adresu serwera WWW nawigacja midzy stronami WWW w obrbie danego serwera Dostp poredni: polskie portale (Onet, Wirtualna Polska, Interia, ...) wyszukiwarki sieciowe (Altavista, Yahoo, Infoseek, Lycos, ...) Zalety dostpu staytycznego: prosty sposb wyszukiwania

duy wybr rnych informacji Wady: dugi czas poszukiwania informacji dostp tylko do wybranych rde informacji Metody dynamicznego dostpu do baz danych z poziomu WWW Technologie dynamicznego generowania witryn: CGI (ang. Common Gateway Interface) SSI (ang. Server Side Includes) ISAPI (ang. Internet Server API) PHP (ang. PHP Hypertext Preprocessor) ASP klasyczne (ang. Classic ASP) CFML (ang. ColdFusion Markup Language) Roxen CMS (ang. Roxen Content Management Solution) Serwlety (ang. servlets) oraz JSP (ang. Java Server Pages) ASP.NET (ang. Active Server Pages .NET) Statyczny witryny internetowe w dostpie do rde danych Serwer

Klient 1 Zapytanie o stron HTML 4 Odpowied strona HTML 2 Strona HTML 3 Serwer przetwarza danie Wykorzystanie dojrzaych protokow TCP/IP Opracowanie podstawowych protokow i standardw stron WWW (HTTP, URL, HTML/XHTML) Brak wikszej interakcji pomidzy serwerem WWW, a klientem

Statyczna zawarto witryn Rne metody generacji Niskopoziomowe API serwera aplikacji (np. CGI, ISAPI). Oglna zasada polega na wywoywaniu zewntrznych programw, ktre zwracaj nastpnie wyniki swojego dziaania do serwera aplikacji WWW w postaci kodu HTML Interpretowane skrypty (np. PHP, ASP klasyczne). Bezporednio w kodzie strony, zanurzany jest skrypt, ktry po wykonaniu si na serwerze, wywietlany 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 rwnie podlegaj kompilacji. Raz skompilowany element aplikacji rezyduje na serwerze, generujc zawarto stron przy kadym daniu. ASP klasyczne schemat dziaania Serwer 2

Skrypt ASP Klient 1Zapytanie o stron ASP 3 ASP.DLL Odpowied 5 strona HTML 4 Strona HTML Programowe interfejsy baz danych Potrzeba programowego interfejsu baz danych Wielo rnych rozwiza. Przykady: ODBC (ang. Open Database

Connectivity) DAO (ang. Data Access Objects) RDO (ang. Remote Data Objects) OLE DB (ang. Object Linking and Embedding Database) ADO (ang. ActiveX Data Objects) ADO.NET (ang. ActiveX Data Objects .NET) JDBC (ang. Java Database Connectivity) Technologia ADO.NET Integralny element platformy .NET Moe by wykorzystana jako rodzaj wysokopoziomej nakadki ODBC lub OLE DB Bezpoczeniowa architektura Przejrzysta struktura obiektowa cisa wsppraca ze standardem XML Efektywne wywoywanie procedur skadowanych Obsuga ODBC, OLE DB oraz bezporednich interfejsw bazodanowych, wybranych systemw (SQL Server, Oracle) ADO.NET jest wykorzystywane przez ASP.NET

ADO.NET warstwy dostpu do danych Kod aplikacji Kod aplikacji ObiektDataAdapter DataAdapterlub lubCommand Command Obiekt ObiektConnection Connection Obiekt Dostawca.NET .NET Dostawca dla Oracle dla Oracle Oracle

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

ODBC ODBC SQL Server Baza danych Baza danych Architektura ADO.NET .NET Framework Data Provider Connection Transaction Command Parameters DataReader DataAdapter

SelectCommand DataSet DataTableCollection DataTable InsertCommand DataRowCollection UpdateComman d DeleteCommand DataColumnCollection ConstraintCollection DataRelationCollectio n Baza danych

XML Architektura aplikacji baz danych Wnioski Nierozczna wsppraca technologii dynamicznego generowania witryn z interfejsami baz danych Najpopularniejsze, niekomercyjne rozwizanie: PHP + MySQL lub PostgreSQL + Apache + Linux Technologie stosowane tam gdzie najwaniejszym priorytetem jest bezpieczestwo, wydajno i przejrzysto rozwijanego projektu: JSP oraz ASP.NET Inne popularne rozwizania: ASP klasyczne, CFML Platforma.NET Najwaniejsze zaoenia: Zintegrowanie technologii programistycznych w postaci jednej platformy Wsppraca wielu jzykw programowania Wsppraca wielu rnych architektur, zarwno

sprztowych jak i systemowych (na razie ograniczona) Prba ustanowienia standardu przemysowego (najwaniejsze elementy s standardami ECMA) Platforma.NET najwaniejsze pojcia CLR (ang. Common Language Runtime) BCL (ang. Base Class Library) MSIL (ang. Microsoft Intermediate Language) CLS (ang. Common Language Specification) CTS (ang. Common Type System) Podzesp (ang. assembly) Kompilator JIT (ang. Just-In-Time compiler) Model wykonawczy platformy .NET Kompilacja Kodrdowy rdowy Kod

Komponent niezarzdzany Kodnatywny natywny Kod Kompilator Kompilator Kodporedni poredniIL IL++metadane metadane Kod Wykonanie CLR Kompilator kodu poredniego Kodnatywny natywny

Kod Systemoperacyjny operacyjny System Architektura platformy .NET C# C# VB VB C++ C++ Python Python J# J#

itd. itd. Wsplnaspecyfikacja specyfikacjajzykw jzykw(CLS) (CLS) Wsplna Web Web services services Strony Strony ASP.NET ASP.NET Architektura platformy .NET FormularzeWindows

Windows Formularze AplikacjeASP.NET ASP.NET Aplikacje ADO.NET i XML ADO.NET i XML Bibliotekapodstawowa podstawowa(BCL) (BCL) Biblioteka rodowisko uruchomieniowe (CLR) rodowisko uruchomieniowe (CLR) Systemoperacyjny operacyjnyWindows Windows System .NET (lub inne IDE) Visual VisualStudio

Studio .NET (lub inne IDE) Jzyk poredni (MSIL) Jzyk poredni (MSIL) rodowisko uruchomieniowe CLR jest agentem odpowiedzialnym za: Zarzdzanie kodem podczas jego wykonywania Zarzdzanie pamici (mechanizm GC) Zarzdzanie wtkami Wymuszenie zgodnoci typw pomidzy rnymi jzykami programowania Kompilacja Niedopuszczenie do uycia potencjalnie niebezpiecznego kodu (np. wskanikw zmiennych) Podzesp Podstawowa jednostka wdroeniowa .NET Zawiera kod poredni MSIL, niezaleny od procesora (moe by zaleny od OS) Jest to komponent samoopisujcy si (metadane) Nie wymaga rejestracji w systemie (instalacja xcopy)

Moe by dzielony (podobnie jak standardowe DLL) przez wiele aplikacji Wsplny System Typw (CTS) Umoliwia integracj wielu jzykw programowania Dwa podstawowe rodzaje typw: Typy wartoci Typy referencyjne Opakowywanie zmiennej (ang. boxing) Brak wskanikw (zmiennych i funkcji) Delegaty Klasyfikacja typw .NET Typ Typy wartoci Typy referencyjne Wbudowane typy

wartoci Typy wskanikowe Typy samoopisujce si Typy interfejsw Typy wartoci uytkownika Typy klas Typy tablic Typy spakowanych wartoci Delegaty Typy wyliczeniowe Typy uytkownika Wsppraca wielu jzykw CLI Wsplna Infrastruktura Jzykowa CLI (ang. Common

Language Infrastructure) skada si z CLR i CLS. Jest publicznie dostpna; kady moe opracowa kompilator JIT dla dowolnego jzyka tak by by zgodny z platform .NET Faworyzacja jzykw podobnych do C# Jzyki programowania .NET w efekcie rni si pomidzy sob tylko notacj (dialekty jzykw oryginalnych). Przykad: jzyk Smalltalk, z dynamicznym typowniem Standard ECMA (wraz z jzykiem C#) Dostpnych ponad dwadziecia jzykw programowania na platformie .NET (np. C++, C#, J#, Visual Basic, Smalltalk, Python, Perl, Pascal, Eiffel, Fortran) .NET vs J2EE Trudno wskaza jednoznacznie lepsz platform J2EE bardziej dojrzaa (zaprezentowana w 1999 roku) i szerzej akceptowana w przemyle .NET posiada bardziej przejrzyst architektur J2EE wsppracuje z najwaniejszymi systemami operacyjnymi, .NET gwnie MS Windows .NET umoliwia wspprac wielu jzykw, J2EE ogranicza si praktycznie tylko do jzyka Java

.NET oferuje lepsz produktywno Technologia ASP.NET Wany element architektury .NET Kompilowany kod wydajno Separacja kodu prezentacji od kodu obsugi strony (kod zakulisowy); komponenty biznesowe Rozbudowane mechanizmy buforowania stron i danych Wielo stosowanych jzykw programowania Obsuga elektronicznych urzdze przenonych (telefony komrkowe, PDA) Wysoka produktywno Duy poziom bezpieczestwa Naturalna wsppraca z bazami danych i XML Formularze ASP.NET (ang. Web forms) Podstawowy element budulcowy aplikacji ASP.NET Separacja kodu interfejsu od jego obsugi Obiektowy model projektowania Moliwo wykorzystania kodu client-side do walidacji danych uytkownika

Kod zakulisowy web forms MojFormularz.aspx.cs Class MojFormularz MojFormularz.aspx Witaj MojFormularz Witaj Imi: Imi: Haso: Haso: OK Te dwa pliki tworz razem formularz internetowy OK

Struktura ASP.NET web forms Projektowanie Wykonanie System.Web.UI.Page System.Web.UI.Page Dziedziczenie WebForm1.cs WebForm1.cs Kompilacja Dziedziczenie Projekt.dll KlasaWebForm1 WebForm1 Klasa WebForm1.aspx WebForm1.aspx

temporary.dll temporary.dll Wynik do przegldarki lub urzdzenia Strona HTML Cykl ycia formularza ASP.NET Przegldarka internetowa Serwer (Koszyk.aspx) (Koszyk.aspx.cs) Koszyk Dodaj

Mka Dodaj Cukier Dodaj Sl Przycisk Dodaj wysya danie na serwer ObsluzStrone(); PobierzWybProdukt(); DodajDoKoszyka(); StworzNowaStrone(); Odswiez();

Serwer wykonuje danie Koszyk Dodaj Mka Dodaj Cukier Dodaj Sl w wyniku ktrego do przegldarki wracana jest nowa strona

Zarzdzanie stanem Potrzeba zarzdzania stanem; HTTP jako tzw. stateless protocol Dwie generalne metody zarzdzania stanem: Po stronie klienta (np. cookies, query strings) Po stronie serwera (np. wsparcie serwera aplikacji oraz baz danych) Kade podejcie ma swoje wady i zalety; strategi naley dobiera cile do konkretnych wymaga Aspekt bezpieczestwa Zarzdzanie stanem (c.d.) Przykady metod zarzdzania stanem: Widok stanu Ukryte pola formularzy HTML Ciasteczka (ang. cookies) Cigi zapyta (ang. query strings) Stan aplikacji Utrzymanie stanu z uyciem baz danych Kontrolki serwerowe

Analogiczne do kontrolek aplikacji desk-top Sze grup kontrolek serwerowych ASP.NET: Serwerowe kontrolki HTML Serwerowe kontrolki internetowe Kontrolki walidacyjne Kontrolki uytkownika Dostosowane kontrolki internetowe Mobilne kontrolki ASP.NET Dostp do danych w ASP.NET Wykorzystanie technologii ADO.NET jako interfejsu bazodanowego programisty Bezpoczeniowy model klient-serwer; potrzeba cyklu podry w obie strony (ang. round trip) Czstsze odczytywanie danych anieli ich zapis

Minimalizowanie konsumpcji zasobw serwera Dostp do danych z uyciem rozproszonego przetwarzania Zapewnienie odpowiedniego poziomu bezpieczestwa danych Znaczenie procedur skadowanych po stronie serwera bazy danych w aplikacjach internetowych Mechanizmy buforowania Znaczenie buforowania Dwa zasadnicze podjecia: Buforowanie wyjcia (ang. output caching) Buforowanie danych aplikacji (ang. application data caching) Buforowanie fragmentw strony Konfiguracja rodowiska ASP.NET Pliki konfiguracyjne w standardzie XML Moliwo wspistnienia wielu plikw konfiguracyjnych Web.config w ramach jednej aplikacji Znaczenie pliku Machine.config Dziedziczenie ustawie w hierarchii katalogw wirtualnych serwera aplikacji internetowej

Moliwo zmiany konfiguracji w dziaajcej aplikacji, bez potrzeby restartu serwera Rozszerzalno plikw konfiguracyjnych jako plikw XML Ochrona przed niepowoanym dostpem do plikw konfiguracyjnych z zewntrz Bezpieczestwo aplikacji ASP.NET Aspekt bezpieczestwa w aplikacjach internetowych Dwa fundamentalne procesy: Uwierzytelnianie (ang. authentication) sprawdzenie tosamoci danego uytkownika w systemie Autoryzacja (ang. authorization) okrelenie do jakich danych moe mie dostp uwierzytelniony uytkownik Uwierzytelnianie moe nastpowa poprzez: System Windows Formularze ASP.NET Usug Passport Bezpieczestwo aplikacji ASP.NET (c.d) Architektura ASP.NET Klient

Klient AplikacjaASP.NET ASP.NET Aplikacja .NETFramework Framework .NET System operacyjny System operacyjny IIS IIS Optymalizacja ASP.NET Cztery podstawowe czynniki wydajnociowe: Czas wykonania (ang. execution time) Czas odpowiedzi (ang. response time) Skalowalno (ang. scalability) Przepustowo (ang. throughput)

Przyszo technologii ASP.NET Przykady wykorzystania we wspczesnym biznesie (np. DELL, London Stock Exchange, NASDAQ, Microsoft) Nastpca obecnej wersji ASP.NET v1.1 ASP.NET v2.0 Whidbey. Nie zapowiedziano jeszcze terminu prezentacji finalnej wersji. Gwny punkty rozwoju: Produktywno Administracja i zarzdzanie Wydajno Architektura systemu (c.d.) Warstwy programu uytkowego Warstwaprezentacji prezentacji Warstwa Warstwaprzetwarzania przetwarzania Warstwa

Warstwazarzdzania zarzdzaniadanymi danymi Warstwa Architektura systemu (c.d.) Model klienta cienkiego i klienta grubego Cienki klient Warstwaprezentacji prezentacji Warstwa (interfejs uytkownika) (interfejs uytkownika) Warstwaprezentacji prezentacji Warstwa

(interfejsuytkownika) uytkownika) (interfejs ++ Warstwa przetwarzania Warstwa przetwarzania (logikabiznesowa) biznesowa) (logika Warstwaprzetwarzania przetwarzania Warstwa (logika biznesowa) (logika biznesowa) ++ Warstwa zarzdzania danymi Warstwa zarzdzania danymi

Warstwazarzdzania zarzdzaniadanymi danymi Warstwa Gruby klient Przykadowa architektura systemu z ADO.NET warstwa prezentacji Formularze Formularze ASP.NET ASP.NET warstwa logiki biznesowej

Komponentylogiki logiki Komponenty biznesowej biznesowej korzystajce korzystajce ADO.NETprzy przy zzADO.NET dostpie do bazy dostpie do bazy danych danych warstwa danych SQL Server 2000 Podsumowanie

Podsumowanie (1) Globalizacja przestrzeni informacyjnej powoduje nacisk na tworzenie rozproszonych i federacyjnych baz danych, ktre umoliwiyby tworzenie aplikacji globalnych, dziaajcych na zestawie dziesitkw, tysicy lub milionw lokalnych BD. Poczenie tych lokalnych baz danych sieci komputerow stwarza niezbdn infrastruktur techniczn, ale nie rozwizuje ogromnej iloci problemw koncepcyjnych, ktrych cz zostaa omwiona na tym wykadzie. Pewna cz problemw jest rozwizana dla rozproszonych relacyjnych baz danych. Rozproszone obiektowe bazy danych znajduj si na pocztku drogi. Niektre problemy, takie jak: przetwarzanie globalnych transakcji, aktualizowalne perspektywy, rozstrzyganie niezgodnoci schematw, akceptowalna wydajno globalnych aplikacji, itd., prawdopodobnie nie maj oglnego rozwizania. Pozostaj nadzieje na rozwizania czstkowe. Podsumowanie (2) Problemy rozproszenia s skutkiem spadku pozostawionego nam przez naszych poprzednikw. Znaczna cz problemw moe rozwiza si sama poprzez rezygnacj ze spadku, tj. poprzez

wymarcie kopotliwych 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 realizujcego dostp do do danych, w szczeglnoci jzykw zapyta Konieczne s dalsze prace badawcze i wdroeniowe w zakresie przetwarzania i optymalizacji rozproszonych obiektowych zapyta, protokow dostpu, obiektowych perspektyw, ontologii, metamodeli, formatw wymiany danych, rozproszonych transakcji, itd.

Recently Viewed Presentations

  • The Georgia School Superintendents Association would like to

    The Georgia School Superintendents Association would like to

    Vince Lombardi "The supreme quality for leadership is unquestionable integrity. Without it, no real success is possible." ... Joshua Charles Hooper Company:
  • Analyzing Tourism Informationon Twitter for a Local City

    Analyzing Tourism Informationon Twitter for a Local City

    Naïve Bayes P/N classification model. Accuracy compared with scoring method. Seed words selection discussion. ... Extracted useful features from tweets, developed a tourism information analysis system. Help people to understand and organize significant information of the target city.
  • Debugging Approaches for Model Transformation

    Debugging Approaches for Model Transformation

    Exploring Efficient and Scalable Omniscient Debugging for MDE. Jonathan Corley. Committee: Dr. Jeff Gray (Chair) Dr. Eugene Syriani. Dr. Jeffrey Carver
  • Declare - Timi 58

    Declare - Timi 58

    In DECLARE - TIMI 58, the largest SGLT-2i trial, which included a broad representation of 1° and 2° prevention patients: Dapagliflozin reduced CVD/HHF and neither increased nor decreased MACE. Reduction in CVD/HHF was consistent regardless of baseline ASCVD or HF.
  • The Consumer Welfare Gains of Guatemalas Liberal Reforms

    The Consumer Welfare Gains of Guatemalas Liberal Reforms

    The Consumer Welfare Gains of Guatemala's Liberal Reforms Thomas W. Hazlett, Giancarlo Ibarguen S. and Wayne A. Leighton Presentation to "Convergence or Competition?
  • Mobile Application Testing

    Mobile Application Testing

    Mobile Application Testing:-Mobile Application Testing is the testing of mobile applications which we are making as third party for the targeted mobile handset.-Some core feature of the mobile are tested just to see that your application has not created any...
  • Collecting &amp; reporting waste BVPIs through WasteDataFlow

    Collecting & reporting waste BVPIs through WasteDataFlow

    Collecting & reporting waste BVPIs through WasteDataFlow User Group (England) 5th June 2006 Outline Background System changes New questions New reports New guidance Overview of calculation method Timing Points for discussion Background Defra, DCLG & the Audit Commission discussed &...
  • The Book of Revelation: Preparing for The Second

    The Book of Revelation: Preparing for The Second

    Mrs. Cruz: Forgive me, forgive me. You will never know how sorry I am for attacking you. I want you to know that you seemed to have . a radiance about you. That light seemed to stop me. from harming...