Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Federacyjne bazy danych Kazimierz Subieta Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa Instytut Podstaw Informatyki PAN, Warszawa K.Subieta. Federacyjne bazy danych, Folia 1 1 czerwiec 2000 Co to jest “Federacyjna Baza Banych” (FDB)? Federated Database FDB jest kolekcją heterogenicznych, autonomicznych baz danych, połączonych siecią komputerową, zarządzana systemem określanym jako Federacyjny System Zarządzania Bazą Danych (FSZBD). FDB może włączać dziesiątki, setki, tysiące lub więcej lokalnych baz danych. Przykładem jest budowana obecnie w USA baza danych integrująca dane z ponad tysiąca instytucji opieki zdrowotnej. FSZBD umożliwia tworzenie aplikacji globalnych, działających na całości federacyjnej bazy danych. FSZBD spełnia warunki odizolowania twórców aplikacji globalnych od szczegółów organizacji sieci i przechowywania danych. Warunki te są określane jako przezroczystość i niezależność danych. FSZBD może być zainstalowany w wielu węzłach sieci (m.in. w każdym lokalnym miejscu FDB), umożliwiając tworzenie aplikacji globalnych w wielu miejscach geograficznych. Poszczególne FSZBD współpracują ze sobą celem zapewnienia spójności i integralności przetwarzania. K.Subieta. Federacyjne bazy danych, Folia 2 1 czerwiec 2000 Architektura federacyjnej bazy danych Aplikacje globalne FSZBD 1 Przestrzeń robocza Aplikacje globalne ... Schemat FBD FSZBD m Przestrzeń robocza Schemat FBD Sieć komputerowa Schemat eksportowy Osłona API 1 Lokalny SZBD 1 BD 1 Aplikacje lokalne K.Subieta. Federacyjne bazy danych, Folia 3 Schemat eksportowy Osłona API 2 Lokalny SZBD 2 BD 2 Aplikacje lokalne ... Schemat eksportowy Osłona API n Lokalny SZBD n BD n Aplikacje lokalne 1 czerwiec 2000 Problem: heterogeniczność (niejednorodność) heterogeneity Heterogeniczność jest nieodłączną cechą sieci komputerowych i rozproszonych aplikacji.Jest to cecha Internetu, Intranetu, WWW, systemów przepływu prac, rozproszonych baz danych. Np. rozproszona aplikacja może składać się z różnorodnego sprzętu: - komputerów klasy mainframe - stacji roboczych UNIX - komputerów PC pracujących pod MS Windows - komputerów Apple Macintosh - central telefonicznych - robotów, zautomatyzowanych linii produkcyjnych ...włączać różnorodne protokoły komunikacyjne: Ethernet, FDDI, ATM, TCP/IP, Novell Netware, protokoły oparte na RPC,... ...bazować na różnych systemach zarządzania bazą danych/dokumentów: Oracle, Informix, SQL Server, DB2, Lotus Notes, Excell, ObjectStore,.... ...oraz wymieniać pomiędzy sobą niejednorodne dane, podlegające różnym modelom danych, schematom, semantyce, mechanizmom dostępu,... K.Subieta. Federacyjne bazy danych, Folia 4 1 czerwiec 2000 Przyczyny heterogeniczności Niezależność działania: wytwórcy systemów nie uzgadniają między sobą ich cech. Standardy, o ile się pojawiają, są spóźnione, niekompletne i nie przestrzegane w 100%. Konkurencja: wytwórcy systemów starają się wyposażyć systemy w atrakcyjne cechy, których nie posiadają konkurujące systemy Różnorodność pomysłów: Nie zdarza się, aby było jedno rozwiązanie dla złożonego problemu. Różne zespoły znajdują różne rozwiązania, bazujące często na odmiennych celach i założeniach. Efektywność finansowa i kompromisy: Wytwórcy oferują produkty o różnej cenie, funkcjonalności i jakości, zgodnie z wyczuciem potencjalnych potrzeb klientów, dostosowaniem się do ich portfela i maksymalizacją swoich zysków. Systemy spadkowe (legacy): Systemy, które dawno zostały wdrożone i działają efektywnie, nie mogą być z tego działania wyłączone. Nie jest możliwe (lub jest bardzo kosztowne) zastąpienie ich nowymi systemami. Nowe systemy, o podobnym przeznaczeniu, posiadają inne założenia, cechy i funkcjonalności K.Subieta. Federacyjne bazy danych, Folia 5 1 czerwiec 2000 Autonomia autonomy Autonomia lokalnej bazy danych w federacji baz danych oznacza, że: Lokalne dane podlegają lokalnym priorytetom, regułom własności, autoryzacji dostępu, bezpieczeństwa, itd. Lokalna baza danych może odrzucić zlecenia przychodzące z federacji, o ile naruszają one lokalne ograniczenia. Lokalna baza danych może udostępniać aplikacjom działającym na federacji baz danych tylko część swoich danych i usług. Programiści tych aplikacji nie mają jakichkolwiek środków dostępu do pozostałych danych i usług. Włączenie lokalnej bazy danych do federacji nie może powodować konieczności zmiany programów aplikacyjnych działających na lokalnej BD. Federacja może przetwarzać lokalne zasoby tylko poprzez interfejs programowania aplikacji (API) specyficzny dla lokalnego systemu. Inne metody (np. bezpośredni dostęp do plików) są niedozwolone. Federacja nie może żądać od lokalnej bazy danych zmiany/rozszerzenia jej usług (np. udostępnienia lokalnego dziennika transakcji). Możliwa jest pewna skala autonomii. Definicja pojęcia autonomii jest problematyczna. K.Subieta. Federacyjne bazy danych, Folia 6 1 czerwiec 2000 Przyjacielskość, wysoki poziom abstrakcji Złożoność, niezawodność i koszty tworzenia i pielęgnacji globalnych aplikacji zwiększają nacisk na prostotę, naturalność, przyjacielskość, wysoki poziom abstrakcji interfejsów programistycznych. Nie ma zgody co to znaczy. W tym zakresie świat komercyjny przypomina „ministerstwo śmiesznych kroków” z Monthy Python: SQL (dwa kroki w przód), C++ (krok w bok), VisualBasic (krok do tyłu), Java, XML (radosny pląs z obrotami), itd. Istnieje szereg kryteriów, które mogą być wskaźnikami w/w cech: Przezroczystość, niezależność danych Mocne abstrakcje programistyczne (klasy, typy, interfejsy, moduły, procedury) Ortogonalność (każda sensowna kombinacja cech interfejsu jest dozwolona) Dostęp poprzez języki zapytań (deklaracyjność, makroskopowość) Brak redundantnych cech interfejsów (brzytwa Occama) Semantyczny relatywizm (własności części są takie same jak własności całości) ......... itd. K.Subieta. Federacyjne bazy danych, Folia 7 1 czerwiec 2000 Przezroczystość transparency Oddzielenie semantyki danych wysokiego poziomu od detali implementacyjnych niskiego poziomu. Jest to warunek konieczny redukcji złożoności oprogramowania działającego na federacyjnej bazie danych. Główne aspekty przezroczystości: Przezroczystość lokacji i dostępu : te same metody działania na wszystkich bazach danych objętych federacją, programy aplikacyjnych są zwolnione z konieczności uwzględniania informacji o położeniu danych. Przezroczystość implementacji danych: zwolnienie programów aplikacyjnych z konieczności uwzględniania informacji o implementacji i organizacji danych. Przezroczystość współbieżności: umożliwienie jednoczesnej pracy wielu programów aplikacyjnych bez utraty spójności i integralności danych. Również przezroczystość: protokołów, skalowania, awarii, replikacji, aktywacji, fragmentacji, migracji, wydajności,... K.Subieta. Federacyjne bazy danych, Folia 8 1 czerwiec 2000 Niezależność danych data independence Możliwość projektowania, utrzymywania, udostępniania, zmiany nośników, zmiany reprezentacji, itp. działań na danych niezależnie od programów, które na nich operują. Nie ma potrzeby zmiany kodu programów aplikacyjnych mimo zmian organizacji lub schematów danych. Niezależność danych oznacza dostęp do danych na odpowiednim poziomie abstrakcji, gdy niewidoczne są szczegóły implementacji danych. Fizyczna niezależność danych: ukrycie detali organizacji fizycznej i technik dostępu, dzięki czemu możliwa jest ich zmiana bez wpływu na kod aplikacji. Logiczna niezależność danych: umożliwienie niektórych zmian schematu logicznego bez wpływu na kod aplikacji, np. dodanie atrybutów do relacji, zmiana kolejności atrybutów, zmiana ich typów, utworzenie nowych relacji, itd. Ewolucja schematu (schema evolution): umożliwienie daleko idących zmian schematu danych przy jednoczesnym utworzeniu perspektyw (views) zachowujących stary schemat. Kod aplikacji nie ulega zmianie dzięki temu, że odwołuje się do danych poprzez te perspektywy. K.Subieta. Federacyjne bazy danych, Folia 9 1 czerwiec 2000 Object store Global schemadostępu do External sub-schemataBD 3-poziomowa architektura lokalnej (in an extended ODL) (through an accessibility matrix) Lokalna baza danych Lokalny schemat eksportowy Zewnętrzne podschematy użytkowników (macierz dostępu) Zewnętrzny podschemat 1 Zewnętrzny podschemat 2 Zewnętrzny podschemat 3 Interfejs IA1 Dostęp Zakaz Zakaz Interfejs IA2 Zakaz Zakaz Dostęp Dostęp Zakaz Dostęp Interfejs IC1 Zakaz Dostęp Zakaz Ob.wirt. VV3 Ob.wirt. 3V Dane wirt. 1 Perspektywa V1 Zakaz Dostęp Dostęp Ob.wirt. VV3 Ob.wirt. 3V Dane wirt. 2 Perspektywa V2 Dostęp Zakaz Zakaz Obiekty A Obiekty A Obiekty Dane B A Obiekty Dane C A API Osłona Obiekty A Obiekty A Obiekty Dane A A Interfejs IB1 definiuje Administrator lokalnej bazy danych K.Subieta. Federacyjne bazy danych, Folia 10 Użytkownik Użytkownik 1 2 Użytkownik 3 1 czerwiec 2000 Osłony wrappers Osłona udostępnia dane i usługi lokalnego systemu i (dostępne w pewnym API i) dla aplikacji globalnych (wykorzystujących wspólny API f). Osłony przystosowują lokalne obowiązującego w federacji. SZBD do interfejsu programistycznego Federacyjny SZBD API f API f Osłona 1 Osłona 2 API 1 Lokalny SZBD 1 API 2 Lokalny SZBD 2 API f ... Osłona n API n Lokalny SZBD n Osłonom przypisuje się małe skomplikowanie; proste odwzorowanie interfejsów. K.Subieta. Federacyjne bazy danych, Folia 11 1 czerwiec 2000 Mediatory mediators Mediator stanowi warstwę pośrednią pomiędzy lokalną bazą danych (izolowaną przez osłonę) a federacyjną bazą danych. Koncepcyjne granice pomiędzy pojęciem mediatora a pojęciem perspektywy nie są jasne. Zadania mediatorów: Rozstrzyganie rozbieżności pomiędzy schematem lokalnym a schematem federacyjnym. Wyłowienie cech formalnych z danych niesformatowanych (np. tekstowych). Selekcja właściwej informacji i jej udostępnienie we właściwej reprezentacji. Wspomaganie dla informacji sumarycznych, wyliczalnych oraz o większym stopniu abstrakcji. Wykrywanie nieznanych związków w danych (eksploracja danych). Zasady konstrukcji mediatorów nie są jasne. Autorzy powołują się np. na metody sztucznej inteligencji. W większości przypadków mediator musi być pisany techniką niskiego poziomu i przypisany do aplikacji (nie uniwersalny). K.Subieta. Federacyjne bazy danych, Folia 12 1 czerwiec 2000 Ontologie ontologies Ontologią nazywa się formalną teorię lub formalny opis bytu lub rzeczywistości. Termin ten przybiera ostatnio znaczenie techniczne: ontologią jest wszystko to, co programista powinien wiedzieć o pewnych środowisku danych lub usług, aby poprawnie napisać program aplikacyjny odwołujący się do tego środowiska. Podejście do ontologii od strony logiki matematycznej jest utopią produkowaną przez obóz tzw. matematycznych podstaw sztucznej (ćwierć-) inteligencji. Złożoność obecnych ontologii danych wyklucza zastosowanie prostego formalizmu (lub wręcz dowolnego matematycznego formalizmu). Pewne elementy ontologii powinny być określone formalnie (np. schemat danych). Pewne elementy ontologii mogą być określone pół-formalnie (np. sygnatury interfejsów) Większość elementów ontologii musi być opisana nieformalnie (np. znaczenie danych w rzeczywistości biznesowej). K.Subieta. Federacyjne bazy danych, Folia 13 1 czerwiec 2000 Co powinna opisywać ontologia? Znaczenie, pragmatykę i zachowanie się danych i usług w rzeczywistości; Statyczne i dynamiczne ograniczenia pomiędzy danymi; Asocjacje i inne semantyczne związki pomiędzy danymi; API do danych i do usług; Związki pomiędzy danymi i usługami; Środki dostępu do danych, środki pielęgnacji i utrzymania danych; Prywatność, bezpieczeństwo i ochronę danych; przetwarzanie transakcji; Wyjątki, komunikaty o błędach, przypadki ekstremalne, efekty uboczne; Abstrakcje wbudowane w dane, takie jak perspektywy, reguły, procedury BD; Konwencje nazywania danych, znaczenie nazw w rzeczywistości; Niektóre szczegóły reprezentacji danych (istotne dla logiki pretwarzania); Organizację metadanych odnoszących się do danych i usług. Lista nie jest kompletna. K.Subieta. Federacyjne bazy danych, Folia 14 1 czerwiec 2000 Odwzorowanie pomiędzy ontologiami Lokalne bazy danych uczestniczące w federacji posiadają na ogół różne ontologie. Przenaszalność i interoperacyjność wymagają odwzorowania ontologii w taki sposób, aby ontologia lokalnej bazy danych A mogła być widziana jako zadana ontologia B. Zadania deweloperów federacyjnej bazy danych są więc następujące: Zrozumienie i opisanie ontologii każdej lokalnej bazy danych uczestniczącej w federacji; Opracowanie ontologii wspólnej dla całej federacji (kanonicznej ontologii); Zdefiniowanie odwzorowań lokalnych ontologii w kanoniczną ontologię; Zintegrowanie kanonicznych ontologii w globalną kanoniczną ontologię. Dowolny szczegół (jeden bit!) lokalnej ontologii, kanonicznej ontologii, ich odwzorowania lub ich integracji, który nie będzie dobrze zrozumiany, może stać się przyczyną błędnie działającej globalnej aplikacji. Stąd nacisk na to, aby kanoniczna ontologia była na bardzo wysokim poziomie abstrakcji, przykrywającym większość szczegółów implementacyjnych. Patrz CORBA. K.Subieta. Federacyjne bazy danych, Folia 15 1 czerwiec 2000 W jaki sposób odwzorowywać ontologie? Mediatory: Uniwersalność zależna wyłącznie od talentu programisty, który może wykorzystać w tym celu dowolne środki języka programowania. Niska pielęgnowalność, niska generyczność (zależność od aplikacji). Perspektywy (views): tradycyjne pojęcie baz danych, funkcja działająca na danych zapamiętanych i zwracająca dane wirtualne. Komfort w programowaniu, dobra pielęgnowalność. Brak uniwersalności, szczególnie w zakresie aktualizacji danych wirtualnych. Współczesne (?) języki programowania nie „rozumieją” perspektyw. Komercyjny „hype” dookoła perspektyw, myślenie życzeniowe, sprzeczność pomiędzy mocą aktualnie znanych perspektyw (np. perspektyw w SQL) a mocą niezbędną do odwzorowania silnie heterogenicznych ontologii. Konieczne są perspektywy o pełnej mocy algorytmicznej i pragmatycznej, wyposażone w niezbędne abstrakcji, w pełni przezroczyste, aktualizowalne i optymalizowalne. Jak dotąd, takie perspektywy są pobożnym życzeniem. K.Subieta. Federacyjne bazy danych, Folia 16 1 czerwiec 2000 Jak skonstruować kanoniczną ontologię? Jest wiele pomysłów i pseudo-pomysłów: Kanoniczna ontologia może opierać się na: Modelu relacyjnym i SQL; Modelu obiektowym CORBA; Modelu obiektowym ODMG; Modelu obiektowym Java; (Syntaktycznym) meta-standardzie XML; Innych środkach, np. formalizmach do opisu danych pół-strukturalnych. Model powinien być na tyle dobrze sformalizowany, aby można było tworzyć precyzyjne odwzorowania pomiędzy ontologiami. Poszukiwanie dobrego modelu do zapisu kanonicznej ontologii nie jest łatwe. K.Subieta. Federacyjne bazy danych, Folia 17 1 czerwiec 2000 Kryteria wyboru kanonicznej ontologii Ekspresyjność (expressiveness): w jakim stopniu dana ontologia jest w stanie bezpośrednio odwzorować pojęcia z modelu pojęciowego dziedziny aplikacyjnej oraz definiować nowe operacje, typy danych i więzy integralności. Np. model relacyjny nie ma bezpośrednich odwzorowań złożonych obiektów, dziedziczenia, agregacji, informacji behawioralnych, itd., wobec czego ma niską ekspresyjność. Pod tym względem model obiektowy ma przewagę. Relatywizm semantyczny (semantic relativism): stopień, w jakim dana ontologia umożliwia wiele punktów widzenia na tę samą dziedzinę aplikacyjną. Miarą relatywizmu semantycznego danego modelu jest możliwość budowania dowolnych schematów zewnętrznych (perspektyw) nad schematem bazy danych. Model relacyjny posiada pewien stopień relatywizmu, dzięki jego zdolności definiowania perspektyw (ograniczonej, szczególnie w zakresie aktualizacji perspektyw). K.Subieta. Federacyjne bazy danych, Folia 18 1 czerwiec 2000 Niezgodności schematów schematic discrepancies Nie istnieje ani “jeden” ani “najlepszy” sposób odwzorowania dziedziny przedmiotowej w struktury danych zapamiętane w bazie danych. Różni projektanci projektują całkowicie odmienne struktury dla tego samego problemu. Dlaczego? Obiekty tej samej dziedziny problemowej mogą być odmiennie widziane przez różnych projektantów. Systemy zarządzenia BD mają ograniczenia struktur danych, które wymuszają różne sposoby myślenia projektantów nad koncepcją struktur danych. Różne środki manipulacji strukturami dostarczane przez SZBD wymuszają różną koncepcję. Projektanci podejmują różne decyzje co do koncepcji struktur danych w związku z zamierzonymi własnościami użytkowymi, np. szybkością dostępu lub ochroną. Nie istnieje jeden model świata (rzeczywistości biznesowej) opisywanego przez dane. Podejścia AI zakładające istnienie takiego modelu są idealistyczne i utopijne (prowokujące ironiczne zdania o „sztucznej (ćwierć-) inteligencji”). K.Subieta. Federacyjne bazy danych, Folia 19 1 czerwiec 2000 Rodzaje niezgodności Reprezentacja danych. Np. w jednej BD nazwisko jest pisane dużymi literami na 15 znakach, w innej z dużej litery (dalej małe) na 30 znakach; w jednej bazie danych data jest stringiem, w innej są to 3 liczby short; itp. Zawartość struktur danych. Np. w jednej BD projektanci wprowadzili atrybut NazwiskoPanieńskie, w innej z tego zrezygnowano. Różna strukturalizacja informacji. Np. w jednej BD utworzono odrębną tabelę PrzynależnośćDoZwiązkuZawodowego, zaś w innej ta przynależność jest atrybutem tabeli Pracownik; w jednej BD atrybut Adres jest polem tekstowym, w innej zaś strukturą z polami Miejscowość, Ulica, NrDomu, itd. Podział danych i metadane. Np. w jednej BD atrybut Zawód tabeli Pracownicy jest stringiem, zaś w innej utworzono odrębne tabele Piekarze, Stolarze, itd. Zawartość semantyczna danych. Np. w jednej BD rejestrowany jest zarobek miesięczny brutto+premia, w innej zaś tygodniowy bez premii. Istnieje wiele innych niezgodności danych. Do nich dochodzą niezgodności w metodach dostępu do danych. K.Subieta. Federacyjne bazy danych, Folia 20 1 czerwiec 2000 Klasyfikacja niezgodności Prosta niezgodność dająca się mitygować przy pomocy prostych perspektyw w SQL. Np. w jednej bazie danych mamy atrybut o nazwie „zawód” zaś w innej atrybut o nazwie „stanowisko” (zawartość jest taka sama). Aktualizacja nie stanowi problemu. Odwzorowywalna niezgodność, którą można mitygować zakładając, że język odwzorowań będzie miał pełną moc algorytmiczną. (SQL jest znacznie poniżej tej mocy.) Np. nie ma możliwości odwzorowania metadanych w dane i odwrotnie. Mniej-więcej odwzorowywalna niezgodność, dająca się mitygować przy pomocy dodatkowych założeń akceptowalnych dla danej aplikacji. Np. „zarobek” w PLN i „salary” w US$ można przeliczyć zakładając jakiś kurs bankowy. Nieodwzorowywalna niezgodność, nie dająca się mitygować w żaden sposób. Np. w jednej bazie danych dane o zarobku są: miesięczne, w złotych, brutto, bez darmowego lunchu, ze składkami na ubezpieczenie, z regularną premią; w innej są: tygodniowe, w dolarach, netto, z darmowym lunchem, bez składek na ubezpieczenie, z premiami uznaniowymi zależnymi od zysku danego działu. Nieodwzorowywalna niezgodność oznacza, ze twórca aplikacji globalnych musi być jej świadomy, co oczywiście komplikuje jego rozumienie całości federacji. K.Subieta. Federacyjne bazy danych, Folia 21 1 czerwiec 2000 Perspektywy views Perspektywy uważa się za podstawowy element architektoniczny federacyjnej bazy danych. Perspektywom przypisuje się rolę odwzorowania schematów lokalnych baz danych na schematy eksportowe, które: (1) zapewniają autonomię poprzez ograniczenie dostępu do lokalnych danych, (2) przystosowują schematy lokalne do schematu globalnego federacji BD. Te oczekiwania co do roli perspektyw pozostają w rażącym kontraście z obecnym stanem sztuki w zakresie definiowania i przetwarzania perspektyw. Co to jest perspektywa? (nie zmaterializowana) Perspektywa jest nazwanym odwzorowaniem danych zapamiętanych w bazie danych na dane “wirtualne”, t.j. pochodne lub wyliczalne. Uważa się, że perspektywa jest funkcją określoną na danych, która zwraca wynik zgodny z przyjętym modelem danych. Np. w modelu relacyjnym perspektywa jest funkcją, której argumentem są tabele BD, zaś wynik jest również tabelą. Dzięki tej własności zapytania (w SQL) są identyczne dla zapamiętanych danych, jak i dla perspektyw (danych wirtualnych). K.Subieta. Federacyjne bazy danych, Folia 22 1 czerwiec 2000 Zasada przezroczystości perspektyw view transparency Z punkty widzenia użytkownika/programisty dowolne operacje na perspektywach nie powinny niczym różnić się od podobnych operacji na zapamiętanych danych. Jeżeli w federacyjnej bazie danych lokalny SZBD udostępnia dane poprzez perspektywę (a nie poprzez interfejs), wówczas użytkownik lub programista końcowy nie powinien być zmuszany do modyfikacji swoich programów. Zasada przezroczystości perspektyw jest trudna do spełnienia, gdyż: Środki definiowania perspektyw (np. SQL) są niewystarczające m.in. ze względu na silne niezgodności schematów. Potrzebna jest moc języków programowania. Problem aktualizacji perspektyw nie jest rozwiązany w zadowalającym stopniu. Aplikacje globalne mogą używać interfejsów programistycznych, a nie języków zapytań. Te interfejsy (np. Java, C++) “nie rozumieją” perspektyw. Powstają zasadnicze problemy z wydajnością przetwarzania. W/w perspektywy są bezstanowe. Często konieczne są perspektywy, które wymagają wprowadzenia pojęcia stanu (capacity augmenting views). K.Subieta. Federacyjne bazy danych, Folia 23 1 czerwiec 2000 Przykład aktualizacji perspektyw Dane rzeczywiste Dział zatrudnia Nazwa * view updating Perspektywa Pracownik Nazwisko Zarobek /MojeDziały Nazwa ŚredniZarobek Podwyższ średni zarobek w dziale „Krasnale Ogrodowe” o 500 zł: update MojeDziały set ŚredniZarobek = ŚredniZarobek + 500 where Nazwa = ‘Krasnale Ogrodowe; ? Oczywiście, zlecenie jest błędne, gdyż: (1) nie ma danej o nazwie ŚredniZarobek. (2) nawet gdybyśmy chcieli je poprawnie wykonać na danych rzeczywistych, mamy do wyboru nieskończenie wiele sposobów. Istnieją pewne możliwości aktualizacji perspektyw, np. w systemie Oracle. Są one jednak daleko nie wystarczające dla celów federacyjnych baz danych. Znacznie gorzej jest w systemach obiektowych: temat nie wyszedł z fazy badawczej. K.Subieta. Federacyjne bazy danych, Folia 24 1 czerwiec 2000 Klasyfikacja złożoności perspektyw Proste perspektywy, np. definiowane poprzez operatory selekcji i projekcji w relacyjnych BD. Mała przydatność dla federacyjnych baz danych. Perspektywy bardziej złożone, np. wymagające złączeń i grupowania, ale wyrażalne w SQL i OQL. Problemy z aktualizacją perspektyw i wydajnością. Perspektywy umożliwiające zmianę reprezentacji danych. Perspektywy uwzględniające niezgodności schematów, np. zamieniające atrybut Zawód z wartościami “piekarz”, “stolarz” itd. na wirtualne tabele Piekarz, Stolarz, itd. Wymagają dostępu do metabazy i mechanizmu refleksji (reflection). Perspektywy uwzględniające niezgodności semantyczne pomiędzy danymi. Często nie ma możliwości odzyskania informacji, która pozwoliłaby usunąć te niezgodności. Konieczne jest wtedy zrezygnowanie z pełnej przezroczystości. Perspektywy z (trwałym) stanem, o pełnej mocy algorytmicznej. Wydajność? Pozostałe kryteria klasyfikacyjne: generyczność, moc, stopień uwzględnienia pojęć modelu obiektowego, perspektywy rekurencyjne, perspektywy z parametrami, możliwości aktualizacji perspektyw, możliwości optymalizacji, itd. K.Subieta. Federacyjne bazy danych, Folia 25 1 czerwiec 2000 Perspektywy w obiektowych bazach danych? Zapytania w OQL Klasy, wirtualne klasy Typy Obiektowe schematy BD Prywatność danych Związki pomiędzy obiektami Metody w C++, Smaltalk, Java Obiektowe perspektywy Hermetyzacja Konstrukcje imperatywne w językach zapytań Witualne atrybuty Abstrakcyjne typy danych Dynamiczne role Tożsamość Zapamiętane atrybuty w wirtualnych obiektach Eklektyzm, eksplozja pojęć, brak prostych i uniwersalnych pomysłów. K.Subieta. Federacyjne bazy danych, Folia 26 1 czerwiec 2000 Przetwarzanie zapytań w FBD Podstawowe algorytmy przetwarzania zapytań w homogenicznych i federacyjnych relacyjnych BD są podobne. Różnice dotyczą cech autonomii i heterogeniczności, które znacznie komplikują problem. Algorytmy polegają na dekompozycji zapytania na pewne podzapytania kierowane do lokalnych BD, następnie na skomponowaniu globalnego wyniku z wyników cząstkowych zwróconych przez lokalne BD. Komplikacje • Niezgodności schematów, które wymagają mechanizmu refleksji lub nowych operatorów w SQL. • Brak algorytmicznej uniwersalności SQL. • Ograniczona moc mechanizmu definiowania perspektyw. Problem został rozwiązany dla niektórych przypadków, ale nie dla generalnego. Wygląda na to, że w ramach obecnych paradygmatów modelu relacyjnego niewiele więcej da się zrobić. W obiektowych bazach danych problem jest na początku drogi. Nie są mi znane istotne prace, które dałyby nadzieję na rozwiązanie. K.Subieta. Federacyjne bazy danych, Folia 27 1 czerwiec 2000 FBD w standardzie CORBA Oprogramowanie komponentowe budowane wg standardu CORBA może być podstawą federacyjnych baz danych. Host globalnej aplikacji Host lokalnej BD Obiekty Obiekty Obiekty Klient Wywołanie operacji Pieniek klienta zlecenie Implementacja interfejsów do obiektów (szkielety + kod) Pośrednik (ORB, Object Request Broker) wynik, parametry wyj Implementacja interfejsów do obiektów po stronie serwera powstaje ze szkieletu automatycznie generowanego z wyrażenia IDL, który jest wypełniany kodem operacji. Taki szkielet pełni jednocześnie funkcję osłony oraz funkcję perspektywy. ORB jest w stanie zapewnić autonomię lokalnej BD. K.Subieta. Federacyjne bazy danych, Folia 28 1 czerwiec 2000 Problemy z FBD w standardzie CORBA CORBA nie jest nastawiona na przetwarzanie danych trwałych i masowych przy pomocy języków zapytań. Jest to poziom języków takich jak C++ i Java, znacznie niższy. Obecny stan standardyzacji w zakresie Query Service i Persistence Service jest uważany za niezadowalający. CORBA nie wprowadza pojęcia perspektywy. Osłony w CORBA są pisane w językach niskiego poziomu, są zorientowane na daną aplikację, nie dają konceptualizacji takiej, jaką dają perspektywy. Pojęcia logicznej niezależności danych i ewolucji schematu umknęły twórcom standardu CORBA. Wobec powyższego, mogą być znaczne narzuty na wydajność maszynową i produktywność programistów globalnych aplikacji. CORBA nie wnosi nic do rozwiązania problemów związanych z przetwarzaniem transakcji w federacyjnych bazach danych. Model obiektowy standardu CORBA jest ograniczony, m.in. nie uwzględnia związków i zagnieżdżonych kolekcji. Te możliwości są uwzględniane w usługach (np. Relationship Service), które są bardzo niskiego poziomu. K.Subieta. Federacyjne bazy danych, Folia 29 1 czerwiec 2000 Podsumowanie Globalizacja przestrzeni informacyjnej powoduje nacisk na tworzenie federacyjnych baz danych, które umożliwiłyby tworzenie aplikacji globalnych, działających na zestawie dziesiątków, tysięcy lub milionów lokalnych BD. Połączenie tych lokalnych baz danych siecią komputerową stwarza niezbędną infrastrukturę techniczną, ale nie rozwiązuje ogromnej ilości problemów koncepcyjnych, których część została omówiona. Część problemów jest rozwiązana dla federacji relacyjnych baz danych. Federacyjne obiektowe bazy danych znajdują się na początku drogi. Problemy przetwarzania transakcji z zachowaniem pełnej autonomii, aktualizowalnych perspektyw, rozstrzygania niezgodności schematów, akceptowalnej wydajności globalnych aplikacji, itd. prawdopodobnie nie mają ogólnego rozwiązania. Pozostają nadzieje na rozwiązania cząstkowe. Problemy FBD są skutkiem “spadku” pozostawionego nam przez naszych poprzedników. Znaczna część problemów może rozwiązać się sama poprzez rezygnację ze spadku, tj. poprzez wymarcie kłopotliwych SZBD i powstanie nowych SZBD lepiej przystosowanych do tworzenia federacji. K.Subieta. Federacyjne bazy danych, Folia 30 1 czerwiec 2000 Literatura: 1996 http://www.informatik.uni-trier.de/~ley/db/index.html 1. Jim Klwein: Practical Issues with Commercial Use of Federated Databases. VLDB 1996: 580 [DBLP:conf/vldb/Klwein96] 2. Georges Gardarin, Fei Sha, Zhao-Hui Tang: Calibrating the Query Optimizer Cost Model of IRO-DB, an Object-Oriented Federated Database System.VLDB 1996: 378-389 [DBLP:conf/vldb/GardarinST96] 3. Antonio Si, Chi C. Ying, Dennis McLeod: On Using Historical Update Information for Instance Identification in Federated Databases. CoopIS 1996: 68-77 [DBLP:conf/coopis/SiYM96] 4. Jonghyun Kahng, Dennis McLeod: Dynamic Classification Ontologies for Discovery in Cooperative Federated Databases. CoopIS 1996: 26-35 [DBLP:conf/coopis/KahngM96] 5. Paul W. P. J. Grefen, Jennifer Widom: Integrity Constraint Checking in Federated Databases. CoopIS 1996: 38-47 [DBLP:conf/coopis/GrefenW96] 6. Marie-Pierre Haye, Olivier Caron: ADEPTE Project: An Individual Federated Database On A Smart Card. RIDE-NDS 1996: 44-49 [DBLP:conf/ride/HayeC96] 7. Silvana Castano: An Approach to Deriving Global Authorizations in Federated Database Systems. DBSec 1996: 58-75 [DBLP:conf/dbsec/Castano96] 8. Martin S. Olivier: Integrity Constraints in Federated Databases. DBSec 1996: 43-57 [DBLP:conf/dbsec/Olivier96] 9. Zahir Tari, George Fernandez: Security Enforcement in the DOK Federated Database System. DBSec 1996: 23-42 [DBLP:conf/dbsec/TariF96] 10. A. Saoudi, G. Nachouki, Henri Briand: Checking Extensional Constraints of Federated Databases. DEXA Workshop 1996: 398-403 [DBLP:conf/dexaw/SaoudiNB96] 11. Elke Radeke: Extending ODMG for Federated Database Systems. DEXA Workshop 1996: 304-312 [DBLP:conf/dexaw/Radeke96] 12. Mark Roantree, Pierce Hickey, Alan Crilly, John Cardiff: Metadata Modelling for Healthcare Applications in a Federated Database System. TreDS 1996:71-83 [DBLP:conf/treds/RoantrHCC96] 13. Doug Fang, Shahram Ghandeharizadeh: An Experimental System for Object-Based Sharing in Federated Databases. VLDB Journal 5(2): 151165 (1996) [DBLP:journals/vldb/FangGM96] 14. Arie Segev, Abhirup Chatterj: A Framework for Object Matching in Federated Databases and Its Implementation. IJCIS 5(1): 73- (1996) [DBLP:journals/ijcis/SegevC96] K.Subieta. Federacyjne bazy danych, Folia 31 1 czerwiec 2000 Literatura: 1997 http://www.informatik.uni-trier.de/~ley/db/index.html 1. Zohra Bellahsene: Extending a View Mechanism to Support Schema Evolution in Federated Database Systems. DEXA 1997: 573-582 [DBLP:conf/dexa/Bellahsene97] 2. Yangjun Chen, Wolfgang Benn: On the Query Treatment in Federated Systems. DEXA 1997: 583-592 [DBLP:conf/dexa/ChenB97] 3. Georges Gardarin: Multimedia Federated Databases on Intranets: Web-Enabling IRO-DB. DEXA 1997: 16-27 [DBLP:conf/dexa/Gardarin97] 4. Xuequn Wu: Query Processing and Transforming for a Federated Database System. DEXA 1997: 593-602 [DBLP:conf/dexa/Wu97] 5. Hamideh Afsarmanesh, Luis M. Camarinha-Matos: Federated Information Management for Cooperative Virtual Organizations. DEXA 1997: 561-572 [DBLP:conf/dexa/AfsarmaneshC97] 6. Yangjun Chen, Wolfgang Benn: Building DD to Support Query Processing in Federated Systems. KRDB 1997: 5.1-5.10 [DBLP:conf/krdb/ChenB97] 7. Zahir Tari, John Stokes: Designing the Reengineering Services for the DOK Federated Database System. ICDE 1997: 465-475 [DBLP:conf/icde/TariS97] 8. Georges Gardarin, Fei Sha: Using Conceptual Modeling and Intelligent Agents to Integrate Semi-structured Documents in Federated Databases. Conceptual Modeling 1997: 87-99 DBLP:conf/er/GardarinS97] 9. Zahir Tari: Designing Security Agents for the DOK Federated System. DBSec 1997: 35-59 DBLP:conf/dbsec/Tari97] 10. Mike P. Papazoglou, Hans Weigand, Steven Milliner: TopiCA: A Semantic Framework for Landscaping the Information Space in Federated Digital Libraries. DS-7 1997: 0- [DBLP:conf/ds/PapazoglouWM97] 11. Jean-Michel Hannoff, Jean-Christophe Nicolas, Fred Hemery: Approach to Service Uses in Federated Systems Information. DEXA Workshop 1997: 706-712 [DBLP:conf/dexaw/HannoffNH97] 12. Elisabeth Kapsammer, Roland Wagner: The IRO-DB Approach - Processing Queries in Federated Database Systems. DEXA Workshop 1997: 713-718 [DBLP:conf/dexaw/KapsammerW97] 13. Elena Rodríguez, Marta Oliva, Fčlix Saltor, Benet Campderrich: On Schema and Functional Architectures for Multilevel Secure and Multiuser Model Federated DB Systems. EFDBS 1997: 93-104 [DBLP:conf/efdbs/RodriguezOSC97] 14. Wilhelm Hasselbring: Extending the Schema Architecture of Federated Database Systems for Replicating Information in Hospitals. EFDBS 1997: 33-44 [DBLP:conf/efdbs/Hasselbring97] 15. Barry Eaglestone, Nayyer Masood: Schema Interpretation: An Aid to the Schema Analysis in Federated Database Design. EFDBS 1997: 1-12 [DBLP:conf/efdbs/EaglestoneM97] 16. Alfredo Gońi, Arantza Illarramendi, Eduardo Mena, J. M. Blanco: Monitoring the Evolution of Databases in Federated Relational Database Systems. EFDBS 1997: 81-91 [DBLP:conf/efdbs/GoniIMB97] 17. Mark Roantree, John Murphy: An Architecture for Federated Database Metadata. EFDBS 1997: 23-32 [DBLP:conf/efdbs/RoantreeM97] 18. Stefan Conrad, Barry Eaglestone, Wilhelm Hasselbring, Mark Roantree, Fčlix Saltor, Martin Schönhoff, Markus Strässler, Mark W. W. Vermeer: Research Issues in Federated Database Systems: Report of EFDBS '97 Workshop. SIGMOD Record 26(4): 54-56 (1997) [DBLP:journals/sigmod/ConradEHRSSSV97] 19. Alfredo Gońi, Arantza Illarramendi, Eduardo Mena, J. M. Blanco: An Optimal Cache for a Federated Database System. JIIS 9(2): 125-155 (1997) [DBLP:journals/jiis/GoniIMB97] 20. Paul W. P. J. Grefen, Jennifer Widom: Protocols for Integrity Constraint Checking in Federated Databases. Distributed and Parallel Databases 5(4): 327-355 (1997) [DBLP:journals/dpd/GrefenW97] 21. Curt Powley, David Benjamin, David Grossman, Robert Neches, Paul Postel, Ernesto Broderson, Rupal Fadia, Quan Zhu, Peter Will: DASHER: A Prototype for Federated E-Commerce Services. IEEE Internet Computing 1(6): 62-71 (1997) [DBLP:journals/internet/PowleyBGNPBFZW97] 22. Wilhelm Hasselbring: Federated Integration of Replicated Information Within Hospitals. Int. J. on Digital Libraries 1(3): 192-208 (1997) [DBLP:journals/jodl/Hasselbring97] K.Subieta. Federacyjne bazy danych, Folia 32 1 czerwiec 2000 Literatura: 1998 http://www.informatik.uni-trier.de/~ley/db/index.html 1. Stefan Conrad, Ingo Schmitt, Can Türker: Considering Integrity Constraints During Federated Database Design. BNCOD 1998: 199133[DBLP:conf/bncod/ConradST98] 2. Hamideh Afsarmanesh, César Garita, L. O. Hertzberger: Virtual Enterprises and Federated Information Sharing. DEXA 1998: 374-383 [DBLP:conf/dexa/AfsarmaneshGH98] 3. Frédéric Mulatéro, Jean-Marc Thévenin, Pierre Bazex: A Global Garbage Collector for Federated Database Management Systems. DEXA 1998: 596-609 [DBLP:conf/dexa/MulateroTB98] 4. D. D. Karunaratna, W. A. Gray, N. J. Fiddian: Organising Knowledge of a Federated Database System to Support Multiple View Generation. KRDB 1998: 12.1-12.10 [DBLP:conf/krdb/KarunaratnaGF98] 5. Peter Fankhauser, Georges Gardarin, M. Lopez, J. Muńoz, Anthony Tomasic: Experiences in Federated Databases: From IRO-DB to MIRO-Web. VLDB 1998: 655-658 [DBLP:conf/vldb/FankhauserGLMT98] 6. Ralf Nikolai, A. Traupe, Ralf Kramer: Thesaurus Federations: A Framework for the Flexible Integration of Heterogeneous, AutonomousThesauri. ADL 1998: 46-55 [DBLP:conf/adl/NikolaiTK98] 7. Erich J. Neuhold, Reginald Ferber: Scientific Digital Libraries in Germany: Global-Info, a Federal Government Initiative. ECDL 1998: 29-39 [DBLP:conf/ercimdl/NeuholdF98] 8. Catherine Houstis: Federated Scientific Data Repositories for the Environment Towards Global Scalable Management of Environmental Information: How Useful Will They Be? What Is Their Potential Impact? Shall We Save the Environment? ECDL 1998: 741-742 [DBLP:conf/ercimdl/Houstis98] 9. Martin Schönhoff: Issues of Global Version Management in Federated Database Systems for Engineering Environments. Grundlagen von Datenbanken 1998: 119-122 [DBLP:conf/gvd/Schonhoff98] 10. Michael Höding, Stefan Conrad: Data-Mining Tasks in Federated Database Systems Design. IADT 1998: 384-391[DBLP:conf/iadt/HodingC98] 11. Rajesh Kaushal, Barry Eaglestone: View-Based Support for Transparent Schema Evolution in Federated Database Systems. IADT 1998: 160-167 [DBLP:conf/iadt/KaushalE98] 12. CongDuc Pham, Rajive Bagrodia: Building Parallel Time-Constrained HLA Federates: A Case Study with the Parsec Parallel Simulation Language. Winter Simulation Conference 1998: 1555-1562 [DBLP:conf/wsc/PhamB98] 13. Michael Gertz: Managing Data Quality and Integrity in Federated Databases. Integrity and Internal Control 1998: 211-230 [DBLP:conf/tc11-5/Gertz98] 14. Mark W. W. Vermeer, Peter M. G. Apers: Specifying Global Behaviour in Database Federations. Information Systems 23(3-4): 217-233 (1998) [DBLP:journals/is/VermeerA98] 15. Laurence Cholvy: Reasoning About Data Provided by Federated Deductive Databases. JIIS 10(1): 49-80 (1998) [DBLP:journals/jiis/Cholvy98] 16. James A. Senn: WISs at Federal Express. CACM 41(7): 117-118 (1998) [DBLP:journals/cacm/Senn98] 17. Dirk Jonscher: Access Control in Object-Oriented Federated Database Systems. 1998, Infix Verlag, St. Augustin, Germany, ISBN 3-89601-449-8 [DBLP:books/infix/Jonscher98] K.Subieta. Federacyjne bazy danych, Folia 33 1 czerwiec 2000 Literatura: 1999 http://www.informatik.uni-trier.de/~ley/db/index.html 1. L. Deruelle, Mohammed Bouneffa, G. Goncalves, Jean-Christophe Nicolas: Local and Federated Database Schemas Evolution, An Impact Propagation Model. DEXA 1999: 902-911 [DBLP:conf/dexa/DeruelleBGN99] 2. Mary Tork Roth, Fatma Ozcan, Laura M. Haas: Cost Models DO Matter: Providing Cost Information for Diverse Data Sources in a Federated System. VLDB 1999: 599-610 [DBLP:conf/vldb/RothOH99] 3. Martin Schönhoff, Markus Strässler: Global Version Management for a Federated Turbine Design Environment. NGITS 1999: 203-220 [DBLP:conf/ngits/SchonhoffS99] 4. Ralf Schenkel, Gerhard Weikum, Norbert Weißenberg, Xuequn Wu: Federated Transaction Management with Snapshot Isolation. FMLDO 1999:139-158 [DBLP:conf/fmldo/SchenkelWWW99] 5. Nelson Mendonça Mattos, Jim Kleewein, Mary Tork Roth, K. Zeidenstein: From Object-Relational to Federated Databases. BTW 1999: 185-209 [DBLP:conf/btw/MattosKRZ99] 6. Henrike Berthold: Design of a Federated Multimedia Database System. Grundlagen von Datenbanken 1999: 7-11 [DBLP:conf/gvd/Berthold99] 7. Hassan Gomaa, G. A. Farrukh: A Reusable Architecture for Federated Client/Server Systems. SSR 1999: 113-121 [DBLP:conf/ssr/GomaaF99] 8. Kai-Uwe Sattler, Gunter Saake: Supporting Information Fusion with Federated Database Technologies (Position Paper). EFIS 1999: 179-184 [DBLP:conf/efdbs/SattlerS99] 9.Wilhelm Hasselbring: Top-Down vs. Bottom-Up Engineering of Federated Information Systems. EFIS 1999: 131-138 [DBLP:conf/efdbs/Hasselbring99] 10. Ralf Schenkel, Gerhard Weikum: Experiences with Building a Federated Transaction Manager based on CORBA OTS. EFIS 1999: 79-94 DBLP:conf/efdbs/SchenkelW99] 11. John Murphy: The Minerva Method: Layered Use Case Modelling for Requirements Modelling in Federated and Interoperable Systems. EFIS 1999:167-178 [DBLP:conf/efdbs/Murphy99] 12. Martin Gaedke, Klaus Turowski: Generic Web-Based Federation of Business Application Systems for E-Commerce Applications. EFIS 1999: 25-42 [DBLP:conf/efdbs/GaedkeT99] 13. Fčlix Saltor, Elena Rodríguez: On Semantic Issues in Federated Information Systems (Extended Abstract). EFIS 1999: 1-4 [DBLP:conf/efdbs/SaltorR99] 14. Michael Höding, Kerstin Schwarz, Stefan Conrad, Gunter Saake, Sören Balko, A. Diekmann, Eyk Hildebrandt, Kai-Uwe Sattler, Ingo Schmitt, Can Türker: SIGMAFDB: Overview of the Magdeburg-Approach to Database Federations. EFIS 1999: 139-146 [DBLP:conf/efdbs/HodingSCSBDHSST99] 15. Uwe Hohenstein, Andreas Ebert: An Integrated Toolkit for Building Database Federations. EFIS 1999: 43-60 [DBLP:conf/efdbs/HohensteinE99] 16. P. A. Dearnley, D. J. Smith: Discovering and Using Entity Mappings in Federated Databases. SP&E 29(1): 17-42 (1999) [DBLP:journals/spe/DearnleyS99] 17. Mike P. Papazoglou, J. Hoppenbrouwers: Contextualizing the Information Space in Federated Digital Libraries. SIGMOD Record 28(1): 40-46 (1999) [DBLP:journals/sigmod/PapazoglouH99] 18. Stefan Conrad, Wilhelm Hasselbring, Uwe Hohenstein, Ralf-Detlef Kutsche, Mark Roantree, Gunter Saake, Fčlix Saltor: Engineering Federated Information Systems: Report of EFIS '99 Workshop. SIGMOD Repord 28(3): 9-11 (1999) [DBLP:journals/sigmod/ConradHHKRSS99] 19. Bruce R. Schatz, William H. Mischo, Timothy W. Cole, Ann P. Bishop, Susan Harum, Eric H. Johnson, Laura Neumann, Hsinchun Chen, Dorbin Ng: Federated Search of Scientific Literature. IEEE Computer 32(2): 51-59 (1999) [DBLP:journals/computer/SchatzMCBHJNCN99] 20. Jean-Luc Hainaut, Ph. Thiran, Jan-Marc Hick, S. Bodart, A. Deflorenne: Methodology and Case Tools for the Development of Federated Databases. IJCIS 8(2-3): 169-194 (1999) [DBLP:journals/ijcis/HainautTHBD99] 21. Patricia D. Fletcher, Lisa K. Westerback: Catching a Ride on the NII: The Federal Policy Vehicles Paving the Information Highway. JASIS 50(4): 299-304 (1999) [DBLP:journals/jasis/FletcherW99] 22. Dirk Jonscher: Access Control in Object-Oriented Federated Database Systems. Datenbank Rundbrief 23: 26-27 (1999) [DBLP:journals/gidr/Jonscher99] K.Subieta. Federacyjne bazy danych, Folia 34 1 czerwiec 2000