Konstrukcja systemów obiektowych i rozproszonych
-
Upload
rosalyn-morrow -
Category
Documents
-
view
26 -
download
0
description
Transcript of Konstrukcja systemów obiektowych i rozproszonych
© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 11, Folia 1 styczeń 2005
Konstrukcja systemów obiektowych i rozproszonych
Wykładowca: Kazimierz Subieta
Polsko-Japońska Wyższa SzkołaTechnik Komputerowych, [email protected]
Instytut Podstaw Informatyki PAN, [email protected]
Wykład 11: Architektury rozproszonych baz danych
© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 11, Folia 2 styczeń 2005
Podejścia do projektowania rozproszonych BD: top-down i bottom-up
Od ogółu do szczegółów (top-down): Odgórne zaprojektowanie całej bazy danych, z uwzględnieniem optymalizacji przechowywanych danych, narzuconej przez fakt geograficznego rozproszenia producentów i konsumentów informacji przechowywanej w bazie danych.
Od szczegółów do ogółu (bottom-up): Zintegrowanie już istniejących (spadkowych) lub zaprojektowanych lokalnych baz danych w jedną globalną rozproszoną bazę danych.
© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 11, Folia 3 styczeń 2005
Projektowanie: podejście top-down
Analiza systemowa: rozpoznanie wymagań, precyzowanie kontekstu przyszłej bazy danych.
Projektowanie schematu pojęciowego
Projektowanie struktury logicznej Kryteria rozproszenia są związane z
faktem fizycznego rozproszenia źródeł i odbiorców danych oraz autonomii lokalnych baz danych.
Ustalają one decyzje, które fragmenty projektu pojęciowego będą przechowywane w poszczególnych miejscach, a także jak należy zdekomponować schemat logiczny na poszczególne miejsca
Analiza
Model pojęciowy scentralizowany
Model logiczny scentralizowany
Kryteriarozproszenia
Modele logiczne dla poszczególnych miejsc
© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 11, Folia 4 styczeń 2005
Dalsze fazy postępowania w podejściu top-down
Określenie danych podlegających replikacjom (lokalnych kopii) oraz strategii replikacji.
Zróżnicowanie logicznego schematu danych w zależności od typu SZBD w poszczególnych miejscach.
Określenie lokalnych schematów dla poszczególnych miejsc. Określenie danych autonomicznych dla poszczególnych miejsc, nie
uczestniczących w rozproszonej bazie danych; co prowadzi do określenia schematu pojęciowego i logicznego dla danych widzianych z zewnątrz.
Podział schematu logicznego: Wg różnych reguł związanych na ogół z fizycznym ulokowaniem obiektów rzeczywistych (np. osób zatrudnionych, sprzętu, co pociąga za sobą odpowiedni podział schematu logicznego) lub też z fizycznym ulokowaniem programów aplikacyjnych działających na tych obiektach.
© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 11, Folia 5 styczeń 2005
Podstawowe metody fragmentacji schematu
Fragmentacja pionowa oznacza przyporządkowanie poszczególnych klas obiektów do poszczególnych miejsc, lub rozbicie obiektów danej klasy na dwa lub więcej podobiektów, przy czym takie podobiekty są przechowywane w różnych miejscach.
Fragmentacja pionowa może oznaczać konieczność odpowiedniego podziału informacji zawartych w klasach obiektów oraz ustalenia środków podtrzymania jednoznacznej tożsamości obiektów.
Fragmentacja pozioma oznacza rozbicie populacji obiektów danej klasy na dwa lub więcej miejsc geograficznych.
Fragmentacja pozioma może być dokonywana na podstawie różnych kryteriów, które często wiązane są z geograficznym ulokowaniem obiektów rzeczywistych, lub też z geograficznym ulokowaniem przetwarzania tych obiektów.
© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 11, Folia 6 styczeń 2005
Fragmentacja pionowa relacyjnej bazy danych
DOSTAWCA_DANE
DNR
D1D2D3D4D5
NAZW
AbackiBoberCzernyDąbekErbel
STATUS
2010302030
DC
DNR
D1D1D1D1D1D1D2D2D3D4D4D4
CNR
C1C2C3C4C5C6C1C2C2C2C4C5
ILOŚĆ
300200400200100100300400200200300400
Warszawa
DOSTAWCA_MIASTO
DNR
D1D2D3D4D5
MIASTO
LublinPoznańPoznańLublinRadom
Gdańsk
Kutno
Sieć
© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 11, Folia 7 styczeń 2005
Fragmentacja pozioma relacyjnej bazy danych
DOSTAWCA
DNR
D2D3
NAZW
BoberCzerny
STATUS
1030
MIASTO
PoznańPoznań
DC
DNR
D2D2D3
CNR
C1C2C2
ILOŚĆ
300400200
Poznań
DOSTAWCA
DNR
D1D4
NAZW
AbackiDąbek
STATUS
2020
MIASTO
LublinLublin
DC
DNR
D1D4D4
CNR
C6C2C4
ILOŚĆ
100200300
Lublin
DOSTAWCA
DNR
D5
NAZW
Erbel
STATUS
30
MIASTO
Radom
Radom
Sieć
© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 11, Folia 8 styczeń 2005
Fragmentacja pionowa obiektów Pracownik
Radom Klasa danych osobistych
Nowakdane osobiste
Kowalskidane osobiste
...
Kalisz Klasa danych o ocenach
Nowakdane o ocenach
Kowalski dane o ocenach
...
Kraków Klasa danych o zatrudnieniu
Nowak dane o zatrud.
Kowalskidane o zatrud.
...
Sieć
© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 11, Folia 9 styczeń 2005
Fragmentacja pozioma obiektów Pracownik
Radom Klasa Pracownik
PracownikNowak
PracownikKowalski
...
Kraków
PracownikMalasa
PracownikZagórny.
...
Sieć Kalisz
PracownikStyka
PracownikMalina
...
Klasa Pracownik
Klasa Pracownik
Obiekty Pracownik są przechowywane zgodnie z geograficznym położeniem pracodawcy.
© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 11, Folia 10 styczeń 2005
Inne fragmentacje danych w rozproszonej BD
Możliwe są inne, bardziej złożone fragmentacje danych, które łączą fragmentacje pionowe, fragmentacje poziome oraz redundantne dane (replikacje).
Bardziej złożone fragmentacje rodzą trudności z:
• zarządzaniem metadanymi: gdzieś muszą być ulokowane informacje odnośnie tego w jaki sposób podzielone dane mają być scalone w kompletne obiekty lub kolekcje w ramach rozproszonej bazy danych. Jest to rola metadanych oraz mechanizmu właściwej dystrybucji metadanych pomiędzy uczestników rozproszonej bazy danych.
• przetwarzaniem zapytań: dekompozycja zapytania na pod-zapytania adresowane do poszczególnych miejsc staje się znacznie bardziej kłopotliwa. Przesyłanie fragmentów obiektów celem ich zmaterializowania po stronie klienta może być zbyt kosztowne.
Bardziej złożone fragmentacje mogą być nie do uniknięcia w rozproszonej bazie danych integrującej istniejące bazy danych (podejście bottom-up). Ma to konsekwencje dla zarządzania metadanymi.
© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 11, Folia 11 styczeń 2005
Projektowanie: podejście bottom-up
Podejście ad hoc: Budowa uniwersalnych lub specyficznych dla danego zastosowania pomostów (gateways) umożliwiających dostęp z danego systemu bazy danych do innych baz danych. Pomost może (nie musi) zapewniać przezroczystość rozproszenia.
Podejście oparte o globalny schemat: Wszystkie składniki rozproszonej BD są objęte jednym globalnym schematem, jednakowym dla każdego miejsca i zapewniającym przezroczystość rozproszenia. Istotną wadą podejścia opartego na globalnym schemacie jest brak możliwości sterowania zakresem autonomii każdego lokalnego systemu.
Federacyjna baza danych: Każda lokalna baza danych zachowuje swoją autonomię, udostępniając tylko część danych dla innych miejsc w RBD. Podejście federacyjne zakłada, że każda lokalna baza danych jest widziana poprzez pewną perspektywę (view), ukrywającą niektóre dane dla rozproszonych aplikacji.
© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 11, Folia 12 styczeń 2005
Baza danych 1
Miejsce 1
Schemat lokalny 1
Aplikacje lokalneAplikacje lokalneAplikacje lokalne
Baza danych 2
Miejsce 2
Schemat lokalny 2
Aplikacje lokalneAplikacje lokalneAplikacje lokalne
Federacyjna BD tworzona metodą bottom-up
Schemat federacyjnej bazy danych
Podejście federacyjne okazało się skuteczne ze względu na zapewnienie autonomii, bezpieczeństwa i efektywności. Rodzi jednak dużo problemów, m.in. z zapewnieniem jednolitej ontologii biznesowej, uniwersalnością aplikacji, wydajnością, itd.
PerspektywaMediatorOsłona
PerspektywaMediatorOsłona
Aplikacje globalneAplikacje globalneAplikacje globalne
.....
© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 11, Folia 13 styczeń 2005
Architektura klient-serwer
Całość pracy wykonywanej przez system komputerowy jest podzielona na dwie części:
wykonywaną po stronie klienta (zwykle związaną z interakcją z użytkownikiem)
wykonywaną po stronie serwera (komunikacja, dostęp do
bazy danych, zarządzanie repozytoriami pamięci,
zarządzanie globalną przestrzenią nazw)
Określenie mechanizmu komunikacji pomiędzy klientem a serwerem.
Określenie jednostki komunikacji klient - serwer
Podział funkcji na te, które są wykonywane po stronie klienta i te, które są wykonywane po stronie serwera
Podstawowe problemy:
© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 11, Folia 14 styczeń 2005
Reguły architektury klient-serwer (1)
Zachowanie autonomii serwera. Klienci powinni zachowywać reguły wykorzystania serwera, nie powinni powodować jego niedostępność (np. zamykać duże ilości danych), nie powinni łamać ograniczeń integralności.
Zachowanie autonomii klienta. Klienci nie powinni zachowywać się różnie w zależności od tego, czy serwer jest lokalny czy odległy. Powinni być odizolowani od kwestii fizycznego ulokowania danych.
Wspomaganie dla aplikacji niezależnych od serwera.
Dostęp do własności (danych, usług) serwera. Klienci mogą żądać od serwera wykonanie przewidzianych dla niego funkcji.
Wspomaganie dla bieżącego dostępu do danych. Dostęp ten powinien być bezpośredni, bez pośrednictwa plików przekazywanych do/od klienta.
Minimalny wpływ architektury K/S na wymagania dla klienta. Oprogramowanie klienta w architekturze K/S nie powinno wykazywać znacznego zwiększenia zapotrzebowania na RAM lub objętość dysku.
© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 11, Folia 15 styczeń 2005
Reguły architektury klient-serwer (2)
Kompletność opcji niezbędnych do połączenia. Oprogramowanie klienta nie powinno zawierać kodu realizującego połączenie z serwerem.Powinien to zapewniać serwer komunikacyjny.
Możliwość budowy lokalnych prototypów. Programista powinien mieć możliwość budowy i testowania aplikacji K/S wyłącznie na stacji klienta.
Kompletność narzędzi użytkownika końcowego. Projektowanie ekranów, generacja zapytań, itd. powinny być częścią środowiska.
Kompletność środowiska budowy aplikacji. Powinno przewidywać możliwość łączenia się w sieci, dostęp do usług globalnych w zakresie nazw, lokacji danych, itd.
Otwarte środowisko języka-gospodarza. Powinno zapewniać możliwość użycia uniwersalnego języka programowania do budowy aplikacji.
Szczególna troska o standardy. Im bardziej będą one przestrzegane, tym mniej będzie późniejszych kłopotów ze współdziałaniem.
© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 11, Folia 16 styczeń 2005
Przykład architektury SZBD typu klient-serwer
Aplikacja generująca transakcje
Zarządzanie transakcjami
Zarządzanie buforami
Zarządzanie zasobami
Klient 1
Aplikacja generująca transakcje
Zarządzanietransakcjami
Zarządzanie buforami
Zarządzanie zasobami
Klient n
Zarządzaniesiecią
. . .
Interfejs serwera
Zarządzanietransakcjami
Zarządzanie buforami
Zarządzaniezasobami
Serwer
Zarządzanielogiem
Zarządzaniezamkami
© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 11, Folia 17 styczeń 2005
Architektura klient-(multi) serwer (1)
s1s1
s2s2s3s3
s4s4
k6k6
k5k5
k4k4
k3k3k2k2
k1k1
k10k10
k9k9
k8k8
k7k7
k11k11
Połączenia bezpośrednie:
© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 11, Folia 18 styczeń 2005
Architektura klient-(multi) serwer (2)
s1s1
s2s2
s3s3
s4s4
k6k6
k5k5
k4k4
k3k3k2k2 k1k1
k9k9
k8k8
k7k7
Połączenia poprzez sieć: nie ma bezpośrednich połączeń, zarówno serwery jak i klienci są przyłączani w jednakowy sposób do wspólnej sieci komputerowej.
Sieć komputerowa
© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 11, Folia 19 styczeń 2005
Architektura trzywarstwowa i wielowarstowathree-tier architecture
Interfejsużytkownika
Serwerbazy
danych
Serwerbazy
danych
multi-tier architecture
Logika przetwarzania
Architektura klient-serwer podzielona na trzy warstwy:
• interfejs użytkownika,
• logikę przetwarzania (reguły biznesu, logikę biznesu)
• serwer (serwery) bazy danych.
Warstwy są zaprojektowane i istnieją niezależnie, co ma duże znaczenie dla pielęgnacyjności systemu ze względu na możliwość zmian w dowolnej warstwie bez konieczności zmian w pozostałych warstwach.
Często warstwy są zrealizowane na odrębnych platformach: interfejs na MS Windows, logika przetwarzania na serwerze aplikacji i baza danych na serwerze bazy danych.
Środkowa warstwa może składać się z wielu warstw, co jest określane jako architektura wielowarstwowa.
© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 11, Folia 20 styczeń 2005
Logiczna architektura oprogramowania
Architektura klient-serwer powinna odzwierciedlać logiczny podział oprogramowania na części. Nie jest to tak istotne w systemie scentralizowanym.
Warstwa prezentacyjna(interfejs użytkownika)
Warstwa prezentacyjna(interfejs użytkownika)
Warstwa zarządzania bazą danych
Warstwa zarządzania bazą danych
Architektura trójwarstwowa:
Warstwa przetwarzania(logika biznesu)
Warstwa przetwarzania(logika biznesu)
Staranne rozdzielenie tych warstw jest bardzo istotne z punktu widzenia tworzenia i modyfikowalności oprogramowania. Dzięki temu rozdzieleniu, możliwa jest np. poprawa interfejsu użytkownika bez jakichkolwiek interwencji w pozostałe warstwy oprogramowania.
Zasada oddzielania aspektów (separation of concerns principle, E.Dijkstra)
cienkiklient
grubyklient
© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 11, Folia 21 styczeń 2005
Cienki i gruby klient
Terminy cienki klient (thin client) oraz gruby klient (fat client) odnoszą się do mocy i jakości przetwarzania po stronie klienta w architekturze klient-serwer.
Model cienkiego klienta: klient posiada niezbyt wielką moc przetwarzania, ograniczoną do prezentacji danych na ekranie. Przykładem jest klient w postaci przeglądarki WWW.
Model grubego klienta: klient posiada znacznie bogatsze możliwości przetwarzania, w szczególności może zajmować się nie tylko warstwą prezentacji, lecz także warstwą przetwarzania aplikacyjnego (logiki biznesu).
Powyższy podział posiada oczywiście pewną gradację.
Model cienkiego klienta jest najczęstszym rozwiązaniem w sytuacji, kiedy system scentralizowany jest zamieniany na architekturę klient-serwer. Wadą jest duże obciążenie serwera i linii komunikacyjnych.
Model grubego klienta używa większej mocy komputera klienta do przetwarzania zarówno prezentacji jak i logiki biznesu. Serwer zajmuje się tylko obsługą transakcji bazy danych. Popularnym przykładem grubego klienta jest bankomat. Zarządzanie w modelu grubego klienta jest bardziej złożone.
© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 11, Folia 22 styczeń 2005
Architektury dwuwarstwowe
Uproszczone architektury trójwarstwowe z cienkim lub grubym klientem.
Warstwa prezentacyjna(interfejs użytkownika)
Warstwa prezentacyjna(interfejs użytkownika)
Warstwa przetwarzania(logika biznesu) +
Warstwa zarządzania bazą danych
Warstwa przetwarzania(logika biznesu) +
Warstwa zarządzania bazą danych
cienkiklient
Warstwa prezentacyjna(interfejs użytkownika)
+ Warstwa przetwarzania(logika biznesu)
Warstwa prezentacyjna(interfejs użytkownika)
+ Warstwa przetwarzania(logika biznesu)
grubyklient
Warstwa przetwarzania(logika biznesu) +
Warstwa zarządzania bazą danych
Warstwa przetwarzania(logika biznesu) +
Warstwa zarządzania bazą danych
W tym modelu przetwarzanie (logika biznesu) jest dzielone pomiędzy klienta i serwera. Zaprojektowanie jej jest trudniejsze.
© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 11, Folia 23 styczeń 2005
BankomatBankomat
BankomatBankomat
BankomatBankomat
BankomatBankomat
Serwer kont klientów banku
Monitor tele-przetwarzania
Baza danych kont klientów banku
Oprogramowanie pośredniczące organizujące komunikację z odległymi klientami i szeregujące transakcje klientów celem przetwarzania ich przez bazę danych.
Przykład architektury K/S - sieć bankomatów
© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 11, Folia 24 styczeń 2005
klientklient
klientklient
klientklient
klientklient
Serwer Web:generacja
dynamicznych stron HTML dla klienta
+zlecenia do bazy
danych
Serwer Web:generacja
dynamicznych stron HTML dla klienta
+zlecenia do bazy
danych
Serwer bazy danych:
wykonywanie zapytań w SQL
Serwer bazy danych:
wykonywanie zapytań w SQL
zapytania SQL
wynikizapytań
SQL
interakcja poprzez HTTP
Przykład architektury K/S - portal WWW
© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 11, Folia 25 styczeń 2005
3-warstwowa architektura aplikacji Web
Przeglądarka
SiećInternet
Baza danych
Baza danych
Serwer bazy danych
Serwer Web
Serwer aplikacji
Serwer
HTTP
© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 11, Folia 26 styczeń 2005
2-warstwowa architektura aplikacji Web
Przeglądarka
SiećInternet
Baza danych
Baza danych
Serwer bazy danych
Serwer WebSerwer aplikacji
Serwer
HTTP
Wiele warstw pośredniczących powoduje dodatkowe obciążenie.
© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 11, Folia 27 styczeń 2005
Zastosowanie różnych architektur K/S Dwuwarstwowa architektura K/S z cienkim klientem
• Systemy spadkowe (legacy), gdzie oddzielenie przetwarzania i zarządzania danymi jest niepraktyczne.
• Aplikacje zorientowane na obliczenia, np. kompilatory, gdzie nie występuje lub jest bardzo mała interakcja z bazą danych.
• Aplikacje zorientowane na dane (przeglądanie i zadawanie pytań) gdzie nie występuje lub jest bardzo małe przetwarzanie.
Dwuwarstwowa architektura K/S z grubym klientem• Aplikacje w których przetwarzanie jest zapewnione przez wyspecjalizowane
oprogramowanie klienta, np. MS Excel.• Aplikacje ze złożonym przetwarzaniem (np. wizualizacją danych, przetwarzaniem
multimediów).• Aplikacje ze stabilną funkcjonalnością dla użytkownika, użyte w środowisku z dobrze
określonym zarządzaniem.
Trzywarstwowa lub wielowarstwowa archiktektura K/S• Aplikacje o dużej skali z setkami lub tysiącami klientów.• Aplikacje gdzie zarówno dane jak i aplikacje są ulotne (zmienne).• Aplikacje integrujące dane z wielu rozproszonych źródeł.
© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 11, Folia 28 styczeń 2005
Architektura rozproszonych obiektów (1)
W architekturze klient-serwer istnieje wyraźna asymetria pomiędzy klientem i serwerem; w szczególności, nie występuje tam komunikacja bezpośrednio pomiędzy klientami. Model taki dla wielu zastosowań jest mało elastyczny i zapewnia zbyt małą skalowalność.
Architektura rozproszonych obiektów znosi podział na klientów i serwery. Każde miejsce w rozproszonym systemie jest jednocześnie klientem i serwerem.
Konieczne jest sprowadzenie wszystkich danych i usług do jednego standardu.
Taki standard obejmuje:
• Model (pojęciowy i logiczny) danych i usług, który jest w stanie "przykryć" wszystkie możliwe dane i usługi, które mogą kiedykolwiek pojawić się w systemie rozproszonym;
• Specjalne oprogramowanie zwane pośrednikiem (broker), które akceptuje wspólny model danych i usług umożliwiając ich udostępnienie dla dowolnych miejsc w systemie rozproszonym.
• Specjalne oprogramowanie, zwane osłoną, adapterem lub mediatorem, które przystosowuje konkretne miejsce do modelu przyjętego przez pośrednika.
© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 11, Folia 29 styczeń 2005
Pośrednik Pośrednik Pośrednik ......Szyna oprogramowania (software bus)
Miejsce 1 Miejsce 2 Miejsce 3
Osłona 1 Osłona 2 Osłona 3
Aplikacja napisana w
C++
Aplikacja na relacyjnej
bazie danych
Aplikacja na Lotus
Notes
Architektura rozproszonych obiektów (2)
© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 11, Folia 30 styczeń 2005
Operacje naobiektach
Struktura logiczna rozproszonych obiektów
O6O6
O5O5O3O3
O2O2O1O1
O4O4
O7O7
O8O8O9O9
K1K2
K3K4
Obiekty
Szyna oprogramowania tworzy jedną przestrzeń obiektów. Obiekty te są dostępne dla dowolnego miejsca poprzez operacje (zgrupowane w klasach). Miejsca i sposoby implementacji obiektów są niewidoczne. Aplikacje korzystają z całej puli obiektów.
Szyna oprogramowania (software bus)
A1 A2 A3Aplikacje
© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 11, Folia 31 styczeń 2005
Architektura serwera stron
strony
Zarządzanie zamkamiZarządzanie składem
Zarządzanie kieszenią stron
Obiektowabaza
danych
Aplikacja
Przeglądarkaobiektów
InterfejszapytaniowyOptymalizacja
zapytań
Interfejsprogramistyczny
Zarządzanie obiektamiZarządzanie plikami i indeksami
Zarządzanie kieszenią stron
Przedmiotem zarządzaniasą fizyczne strony dyskowe
© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 11, Folia 32 styczeń 2005
Architektura serwera obiektów
obiekty
Zarządzanie obiektamiOptymalizacja zapytań
Zarządzanie zamkamiZarządzanie składem
Zarządzanie stronami i kieszeniami
Obiektowabaza
danych
Aplikacja
Przeglądarkaobiektów
Interfejszapytaniowy
Interfejsprogramistyczny
Zarządzanie obiektamiPrzedmiotem zarządzaniasą obiekty