Obiektowe bazy danych
Technologia obiektowa rozwija się i rozprzestrzenia w bardzo szybkim tempie. W ostatnich latach również w technologii baz danych wyraźnie obserwuje się ogólny trend w kierunku koncepcji obiektowej.
Pierwszym językiem proceduralnym łączącym dane z ich zachowaniem był język Simula, który był wykorzystywany w zadaniach naukowych do symulowania zachowania jednostek. Obiekty, w sensie zarządzania danymi, zostały wprowadzone po raz pierwszy na początku lat siedemdziesiątych przez Palo Alto Research Center z firmy Xerox.
Podejście obiektowe podkreśla bardziej naturalną reprezentację danych. W dzisiejszym środowisku modele danych są dużo bardziej wymagające. Ich zadaniem jest przetwarzanie dźwięku, obrazu, tekstu, grafiki itp. Potrzeby te wymagają dużo bardziej elastycznego formatu przechowywania danych niż hierarchiczne, sieciowe, czy relacyjne bazy danych mogą zapewnić. Jedynie obiektowe bazy danych będą mogły sprostać tym wymaganiom.
Obiektowa baza danych jest zbiorem obiektów, których zachowanie się i stan oraz związki są określone zgodnie z obiektowym modelem danych. Obiektowy system zarządzania bazą danych (OSZBD) jest systemem wspomagającym definiowanie, zarządzanie, utrzymywanie, zabezpieczanie i udostępnianie obiektowej bazy danych.
Systemy obiektowych baz danych były rozwijane w celu dostarczenia elastycznego modelu danych bazującego na tym samym paradygmacie, co obiektowe języki programowania. Obiektowe bazy danych dają możliwość silniejszego powiązania z aplikacjami obiektowymi, niż było to w przypadku relacyjnych baz danych. Dzięki temu można zminimalizować ilość operacji związanych z przechowywaniem i dostępem do danych zorientowanych obiektowo. Zaleta ta staje się szczególnie cenna w przypadku, gdy obiektowy model danych jest naprawdę skomplikowany.
Obiektowe systemy zarządzania bazą danych zapewniają tradycyjną funkcjonalność baz danych, lecz bazują na modelu obiektowym.
Do klasycznych funkcji obsługiwanych przez OSZBD można zaliczyć:
zarządzanie pamięcią zewnętrzną,
zarządzanie schematem,
sterowanie współbieżnością,
zarządzanie transakcjami,
odtwarzalność,
przetwarzanie zapytań,
kontrolę dostępu.
Do przedstawionych powyżej funkcji, OSZBD dokładają dodatkowo:
złożone obiekty,
typy definiowane przez użytkownika,
tożsamość obiektów,
hermetyzację,
typy i/lub klasy oraz ich hierarchię,
przesłanianie, przeciążanie, późne wiązanie,
kompletność obliczeniową (pragmatyczną).
Poza bezsprzecznymi zaletami OSZBD, istnieje wiele powodów powstrzymujących ich dynamiczny rozwój i powodujących, iż systemy relacyjnych baz danych wciąż posiadają znacznie większy udział w rynku. Do powodów tych zaliczyć można:
Niedojrzałość technologii – wiele organizacji wykorzystuje obecnie OSZBD do aplikacji o mniejszym znaczeniu, z uwagi na ryzyko wiążące się z wykorzystaniem nowej technologii.
Niestabilność producentów – producenci OSZBD wydają się być relatywnie małymi firmami, co powstrzymuje niektóre organizacje przed inwestowaniem w te systemy z obawy, że w niedalekiej przyszłości firmy te mogą zniknąć z rynku.
Brak wykwalifikowanego personelu – niestety wciąż brakuje informatyków wykwalifikowanych w obsłudze obiektowych systemów zarządzania bazami danych.
Koszty konwersji – niebagatelną przeszkodę stanowią koszty konwersji na nowy system. Należy tu wziąć pod uwagę koszty nowego oprogramowania i jego instalacji, a także w przypadku firm już istniejących na rynku, inwestycje poczynione dotychczas w systemy relacyjnych baz danych.
Trwałość obiektu
Trwałość obiektu (ang. object persistence) jest jedną z najważniejszych usług dostarczanych przez obiektowe systemy zarządzania bazami danych. Przez trwałość rozumie się zachowanie polegające na tym, że obiekt jest stale dostępny, a jego stan pozostanie niezmieniony pomiędzy kolejnymi wywołaniami.
Obiekty, które nie są stale dostępne nazywane są ulotnymi. Zależnie od aplikacji, niektóre obiekty muszą zmieniać swój stan z ulotnego na trwały, a zadaniem OSZBD jest zarządzanie tą konwersją. OSZBD przyporządkowuje każdemu obiektowi unikalny identyfikator, który jest wykorzystywany głównie do ustalenia powiązań pomiędzy trwałymi obiektami. OSZBD posiada procedury odzyskiwania zapewniające, że trwałe obiekty przetrwają wszelkie awarie systemu.
Istnieją dwie metody wykorzystywane przez OSZBD w celu uzyskania dostępu do trwałych obiektów. Są to wirtualne wskaźniki adresu pamięci oraz tablice z kodowaniem mieszającym.
Trwałe obiekty są stale gotowe do wywołania. Są one przechowywane na dysku, natomiast obiekty ulotne istnieją w pamięci RAM. W OSZBD obiekty mogą przechodzić z jednego stanu w drugi, mając swoją reprezantację w pamięci RAM, a także na dysku.
Poniżej przedstawiono niektóre z działań, które OSZBD musi wykonywać w związku z zarządzaniem trwałością obiektów:
wyszukiwanie obiektów na dysku i przyporządkowywanie im nowych identyfikatorów w pamięci RAM,
przyporządkowywanie i alokowanie przestrzeni w składzie trwałych obiektów,
automatyczne zwiększanie przestrzeni w razie potrzeby,
zarządzanie wolną przestrzenią w składzie trwałych obiektów,
interfejs pomiędzy systemem wejścia-wyjścia a składem trwałych obiektów,
zapewnienie, że trwałe obiekty mogą być odzyskane,
zarządzanie buforami bazy danych,
zarządzanie mapowaniem pomiędzy fizycznymi adresami a identyfikatorami obiektów.
Architektura
Istnieje kilka koncepcji odnośnie architektury obiektowego systemu zarządzania bazą danych. Najbardziej abstrakcyjną jest architektura zaproponowana przez komitet ANSI/SPARC. Wyróżnia ona trzy poziomy:
poziom pojęciowy systemu, wspólny dla wszystkich jego użytkowników,
poziom zewnętrzny, specyficzny dla konkretnego użytkownika,
poziom fizyczny, który odnosi się do implementacji bazy danych.
Kolejnym rodzajem jest architektura klient-serwer, gdzie występuje podział na dwie części: serwer bazy danych, wykonujący przykładowo wyrażenia SQL wysyłane przez klientów oraz druga część, którą stanowi jeden lub kilku klientów wysyłających żądania do serwera.
Bardziej zaawansowane są architektury trzywarstwowa oraz wielowarstwowa. Jak sama nazwa wskazuje, architektura trzywarstwowa charakteryzuje się podziałem na trzy warstwy: interfejs użytkownika, logikę przetwarzania oraz bazę danych. Warstwy te są zaprojektowane i istnieją niezależnie, co ma duże znaczenie dla utrzymania całego systemu ze względu na możliwość zmian w dowolnej warstwie bez konieczności interwencji w pozostałych warstwach. Warstwa środkowa może być złożona z kilku warstw i mamy wówczas do czynienia z architekturą wielowarstwową.
Poniższy rysunek pokazuje typową architekturę obiektowego systemu zarządzania bazą danych ujętą z funkcjonalnego punktu widzenia (rys. 3.1). Przedstawione zostały zależności pomiędzy podstawowymi funkcjonalnymi komponentami systemu [Subieta 1999b].
RYSUNEK 3.1. PRZYKŁADOWA ARCHITEKTURA OBIEKTOWEGO SYSTEMU ZARZĄDZANIA
BAZĄ DANYCH (OSZBD).
Obiektowo-relacyjne bazy danych
Obiektowo-relacyjne bazy danych są najnowszym osiągnięciem w rozwoju hybrydowych architektur baz danych. Systemy te pojawiły się między innymi z powodu ogromnych inwestycji poczynionych przez różne organizacje w systemy relacyjnych baz danych. Bezpośrednie przekwalifikowanie z relacyjnych na obiektowe systemy baz danych wiązałoby się z dodatkowymi kosztami, natomiast obiektowo-relacyjne bazy danych stanowią swoisty kompromis.
Obiektowe bazy danych nie posiadają niektórych cech, do których przywykli użytkownicy poprzednich systemów. Dodatkowo, w chwili obecnej obiektowe systemy baz danych nie mają odpowiedniej infrastruktury, aby przejąć rynek relacyjnych baz danych, podobnie jak bazy relacyjne uczyniły to z systemami hierarchicznymi i sieciowymi.
Rozwiązaniem dla firm takich jak Oracle, Informix, Sybase, czy IBM jest rozwój ich systemów polegający na przekształcaniu ich w systemy obiektowo-relacyjnych baz danych.
Systemy obiektowo-relacyjne są wyposażane w wiele cech umożliwiających efektywną produkcję aplikacji. Wśród nich można wymienić przystosowanie do multimediów (duże obiekty BLOB, CLOB i pliki binarne), dane przestrzenne, abstrakcyjne typy danych (ADT), metody (funkcje i procedury) definiowane przez użytkownika w różnych językach, kolekcje (zbiory, wielozbiory, sekwencje, zagnieżdżone tablice, tablice o zmiennej długości), typy referencyjne, przeciążanie funkcji, późne wiązanie i inne. Systemy te zachowują jednocześnie wiele technologii, które sprawdziły się w systemach relacyjnych (takie jak architektura klient/serwer, mechanizmy buforowania i indeksowania, przetwarzanie transakcji, optymalizacja zapytań) [Subieta 1999a].
Obiektowo-relacyjne bazy danych zdobywają uznanie, gdyż wiele organizacji dostrzega, że relacyjne bazy danych nie są wystarczające do obsługi ich złożonych wymagań. Zamiast więc bezpośredniego przejścia na systemy czysto obiektowe, podejście obiektowo-relacyjne pozwala organizacjom na zapoznanie się z technologią obiektową w rozsądnym tempie. Dodatkową zaletą jest uniknięcie konwersji aktualnych baz danych do nowego, obiektowego formatu danych, co oszczędza czas i pieniądze. Obiektowo-relacyjne bazy danych stanowią zatem pomost pomiędzy relacyjnymi a obiektowymi bazami danych.
komentarze
Copyright © 2008-2010 EPrace oraz autorzy prac.