Download No Slide Title

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