bazy danych.rtf

Wstęp

W ciągu ostatnich lat coraz głośniej się mówi o nowej generacji systemów baz danych - Obiektowych Bazach Danych (OBD). Mimo bardzo małego udziału w rynku systemów zarządzania baz danych (SZBD), zdominowanego przez producentów relacyjnych baz danych (RBD), zyskują one szybko na popularności.

Czym jest spowodowany wzrost zainteresowania obiektowymi bazami danych? Czy wynika to jedynie z ogólnego trendu popularyzacji technologii obiektowej czy tez z realnej potrzeby gruntownej zmiany tradycyjnych narzędzi bazodanowych? Co nowego oferują obiektowe bazy danych? Na ile realne jest wyparcie modelu relacyjnego przez obiektowy w ciągu najbliższych lat?

Aby podpowiedzieć na te pytania, należałoby najpierw scharakteryzować koncepcję obiektowych baz danych i odnieść ją do tego, co oferują nam, obecnie najpowszechniejsze, relacyjne.

Model obiektowy

Technologia obiektowa rozwija się i rozprzestrzenia w bardzo szybkim tempie (języki programowania, narzędzia do analizy i projektowania, biblioteki klas itd.). W ciągu ostatniej dekady również w technologii baz danych wyraźnie obserwuje się ogólny trend w kierunku koncepcji obiektowej. Jednak usystematyzowanie współczesnych kierunków w dziedzinie baz danych nie może być zbyt precyzyjne ze względu na dużą złożoność i wieloaspektowość projektowanych i realizowanych systemów. Dodatkową trudność sprawia brak jednolitej terminologii, systemu pojęć, teorii, a także nawarstwione, często fałszywe stereotypy dotyczące roli teorii w projektowaniu rzeczywistych systemów.

Obiektowe bazy danych pojawiły się w wyniku połączenia pojęć obiektowych języków programowania z koncepcjami, które zostały ustalone w dziedzinie baz danych. Dziedziczą one zatem wszystkie zasadnicze cechy technologii obiektowej (istnienie złożonych obiektów, tożsamość obiektów, dziedziczenie, funkcje polimorficzne, rozszerzalność o nowe typy danych; oraz baz danych, trwałość danych, oddzielenie logicznego i fizycznego poziomu danych, zarządzanie wielodostępem, odtwarzanie spójnego stanu danych po awariach, zarządzanie transakcjami, itp.) Ta kombinacja wniosła nowe spojrzenie zarówno w dziedzinie języków programowania jak i baz danych. Owocem tego są nowe koncepcje, które wcześniej nie były znane w obu dziedzinach. Najbardziej doniosłym wyróżnikiem obiektowości w bazach danych są złożone, hierarchicznie zbudowane obiekty, które mogą być powiązane w sieć poprzez związki o charakterze wskaźników prowadzących od obiektów do obiektów. Historia baz danych składa się z etapów wyznaczanych aktualnie dominującymi ideologiami. Organizacja struktury bazy danych, ich interfejsy oraz inne własności użytkowe dają bardzo dużą swobodę podczas projektowania SZBD, konstrukcji baz danych oraz samych aplikacji.

Model obiektowy dostarcza przede wszystkim wyższego poziomu abstrakcji w sposób znacznie bardziej skuteczny, konsekwentny i jednorodny. Argumentacja na rzecz modelu obiektowego stawia więc na znaczne uproszczenie i usystematyzowanie procesu projektowania i programowania, zwiększenie poziomu abstrakcji, zmniejszenie dystansu pomiędzy poszczególnymi fazami projektowania i programowania oraz zwiększeniu nacisku na rolę czynnika ludzkiego.

Model obiektowy dotyczy głównie struktur danych przechowywanych w obiektowej bazie danych. Jest on spójnym zestawem własności, pojęć, terminologii, notacji, formalizmów służących do:

zapewnienia porozumiewania się profesjonalistów,

uczenia i objaśniania metod i technik obiektowych,

budowy języków, systemów, interfejsów,

·         budowy i objaśniania zasad analizy i projektowania obiektowego.

W stosunku do modelu relacyjnego, obiektowość wprowadza znacznie więcej pojęć, często o niezbyt precyzyjnej semantyce. Z jednej strony stara się uogólnić i rozszerzyć ideologiczne założenia modelu danych, z drugiej strony – objąć nimi te pojęcia, które w modelu relacyjnym były nie do wyrażenia.

Obiektowy model danych (object model, object-oriented model) jest modelem danych, którego podstawą są pojęcia obiektowości, m.in.: obiekt i identyfikator obiektu, tożsamość obiektu, hermetyzacja, klasa i typ, atrybut, metoda, komunikat, hierarcha klas i dziedziczenie, polimorfizm.

Obiektowa baza danych (Object Database, Object-Oriented Database) jest zbiorem obiektów, których zachowanie, stan i związki zostały określone zgodnie z obiektowym modelem danych. Przyjęcie obiektowego modelu, jako podstawy bazy danych, implikuje naturalną jej rozszerzalność bez konieczności wprowadzania zmian do istniejącego systemu. Możliwe są dwa sposoby rozszerzenia bazy danych: rozszerzanie zachowania się i dziedziczenie. Zachowanie się obiektu może zostać rozszerzone przez dołączenie dodatkowych metod do już istniejących. W dowolnym momencie życia systemu można zdefiniować nowe klasy korzystając już z istniejących lub przedefiniować istniejące.

W chwili obecnej nie istnieje żaden, ogólnie przyjęty, standard jednoznacznie definiujący pojęcia obiektowe. Trwają prace nad ustandaryzowaniem pojęć obiektowych w dziedzinie baz danych, prowadzone m.in. przez ODMG (Object Database Management Group). Standard zaproponowany przez ODMG stworzony został w oparciu o trzy istniejące standardy dotyczące baz danych (SQL-92), obiektów (OMG) i obiektowych języków programowania (ANSI).

Obiektowe a relacyjne systemy baz danych

Istnieje dużo elementów łączących bazy obiektowe i relacyjne. Są to podstawowe cechy jakie powinien spełniać system baz danych:

·         możliwość bezpośredniego, interakcyjnego, uzyskiwania informacji z bazy poprzez formułowanie pytań (ad hoc query facility),

·         możliwość przechowywania danych w postaci trwałej (persistence) i zarządzania pamięcią wtórną, w której przechowuje się informacje bazy danych (secondary storage managment),

·         zapewnienie kontroli jednoczesnego dostępu do danych (concurrency),

·         możliwość odzyskiwania danych w wypadku błędów pracy systemu (recovery) i ochrony danych przed niepowołanymi użytkownikami (authorization).

Różnice zaczynają się przy modelowaniu powiązań między rekordami (obiektami).
W RBD do modelowania zależności stosuje się klucze obce (foreign key), natomiast w OBD – atrybuty referencyjne. Klucze obce w RBD stanowią jawne złączenie (explicit join) między tabelami oparte na porównaniu odpowiadających sobie atrybutów z dwóch tabel. W OBD atrybuty referencyjne stanowią niejawne złączenie (implicit join) między obiektami - w rzeczywistości rolę klucza obcego z RBD pełni w OBD identyfikator obiektu.

Dla relacyjnych baz danych operacje zarządzania „schematem" bazy danych sprowadzają się do tworzenia i usuwania tabel oraz dodawania atrybutów do już istniejących tabel, zmiany dla danej tabeli nie wpływają na inne tabele. W przypadku obiektowych baz danych zestaw możliwych modyfikacji schematu jest o wiele większy ze względu na większą złożoność modelu danych oraz to, że modyfikacja jednej klasy może wpływać na inne klasy. Mechanizm dziedziczenia wymaga więc wprowadzenia nowych, w stosunku do relacyjnego modelu operacji, modyfikacji schematu.

W relacyjnych bazach danych jedynym sposobem dostępu do danych jest język wyszukiwania. W przypadku obiektowych baz danych istnieją dwa sposoby dostępu do danych: pierwszy to zastosowanie języka zapytań podobnego do dla relacyjnych baz danych, druga metoda opiera się na możliwości bezpośredniego dostępu do obiektów przez ich identyfikatory.

Rezultaty takich zapytań również zasadniczo różnią się od siebie w poszczególnych modelach danych. W relacyjnym rezultatem wykonania zapytań jest relacja, co między innymi ułatwia konstruowanie zapytań złożonych. W przypadku modelu obiektowego rezultatem zapytań może być obiekt lub zbiór obiektów klas istniejących. Innym rozwiązaniem jest potraktowanie odpowiedzi jako zbioru obiektów należących do klasy ogólnej, która akceptuje wszystkie obiekty, a jej metody są metodami służącymi do drukowania bądź wyświetlania na ekranie tych obiektów.

Zalety i wady poszczególnych systemów

RDBMS

Zalety:

·        oparte na solidnych podstawach teoretycznych (zainteresowanie świata nauki, a nie tylko biznesu)

·        stabilna pozycja na rynku

·        optymalizacja zapytań

Wady:

·        z góry ustalony konstruktor, brak złożonych obiektów

·        brak środków hermetyzacji i modularyzacji (brak oddzielenia implementacji od specyfikacji)

·        brak środków do przechowywania informacji proceduralnych

·        niezgodność modelu pojęciowego z modelem implementacyjnym

ODBMS

Zalety:

·        złożone obiekty

·        typy danych definiowane przez użytkownika

·        tożsamość obiektów (identyfikator), trwałość

·        hermetyzacja, hierarchia, dziedziczenie

·        rozszerzalność

·        zgodność we wszystkich fazach życia bazy i danych

·        metody i funkcje przechowywane wraz z danymi

·        nowe możliwości (wersjonowanie, rejestracja zmian, powiadamianie ...)

·        możliwość nowych zastosowań mniejszym kosztem (bazy mulitmedialne, przestrzenne, bazy aktywne...)

·        porównywalna wydajność (i wciąż rośnie)

Wady:

·        brak optymalizacji zapytań (rozumianej jak w poprzednich modelach)

·        niedopracowane mechanizmy zarządzania dużą baza obiektów, sterowania wersjami, ...

·        mała liczba ekspertów od technik obiektowych

·        nie wiadomo z jakimi kosztami wiąże się migracja dużych systemów

·        brak dopracowanych standardów

Należy tu jednak zaznaczyć, że większość wad z czasem samoczynnie zaniknie, gdyż są spowodowane zbyt dużym tempem rozwoju w porównaniu do innych dziedzin (szkolenia programistów czy zmiany mentalności, itd.)

Oczywiście, mimo opisanych zalet OBD, dla większości użytkowników, którzy zainwestowali już duże środki finansowe w zainstalowane i działające systemy bazodanowe oraz w pracowników obsługujących systemy RBD, szybkie zaadoptowanie nowej technologii baz danych jest niemożliwe. To zadecydowało o rozpowszechnieniu baz obiektowo-relacyjnych (Object Relational lub Extended Relational), które w większym lub mniejszym stopniu wykorzystują elementy modelu relacyjnego. Główną zasadą działania takich systemów jest budowanie nad systemem zarządzania relacyjna bazą danych warstwy programowej pozwalającej przetwarzać obiekty logiczne na składniki podstawowe modelu relacyjnego, czyli umożliwiające przechowywanie obiektów w tablicach relacyjnej bazy danych.

Dużą popularność zyskały również narzędzia middleware służące do pogodzenia modelu obiektowego z relacyjnym (np. Persistence, DBtools.h++). Za ich pomocą dokonuje się konwersji obiektów na postać odpowiednia do przechowywania ich w istniejących RBD. Podejścia te pozwalają na korzystanie z dobrodziejstw jakie niesie technologia obiektowa przy zachowaniu podrzędnego relacyjnego modelu bazy danych.
ORDBMS korzysta z modelu danych zawartego w standardzie SQL3, który mówi, że "obiektowo-relacyjny model danych próbuje dodać obiektowości do tablic". Dane są wciąż przechowywane w tabelach, jednak wartości mogą mięć nieco bogatszą niż dotychczas postać - ADT (Abstract Data Type). Pola typu ADT zachowują funkcjonalność zwykłych pól (mogą być używane do indeksowania, wyszukiwania, pobierania lub umieszczania danych) przy nowych zawartościach (jak np. multimedia).

Ponieważ ten model rozszerza model relacyjny, dlatego opracowywany obecnie SQL3 (nazywany tez ObjectSQL) jest rozszerzeniem SQL. Rozszerzenie dotyczy rozbudowy możliwości zapytań o obiekty zagnieżdżone, ADT, atrybuty o wartości wyliczanej (np. metody obiektu), itp. Wyniki są jednak wciąż podawane w formie tabel, krotek, a nie jako kolekcje obiektów.

Rozszerzony język SQL jest podstawowym interfejsem dostępu do danych. Bezpośrednie odwzorowanie miedzy obiektami z języka programowania a obiektami / tabelami w bazie nie istnieje, tłumaczenie wciąż obciąża programistę.

ORDBMS

Zalety:

·        przystosowanie do multimediów (duże obiekty BLOB, CLOB i dane binarne)

·        dane przestrzenne (spatial)

·        abstrakcyjne typy danych (ADT)

·        metody (funkcje i procedury) definiowane przez użytkownika w rożnych językach (C++, VisualBasic, Java)

·        kolekcje (zbiory, wielozbiory, sekwencje, tablice zagnieżdżone, tablice o zmiennej długości)

·        typy referencyjne

·        przeciążanie funkcji

·        optymalizacja zapytań

Wady:

·        wciąż nie uniknięto wielu błędów modelu relacyjnego

·        brak perspektyw na przyszłość

·        produkt hybrydowy "dwa w jednym" (redundancja kodu i danych)

·        brak bazy intelektualnej

·        zmiany wprowadzane ad hoc (kumulowanie błędów koncepcyjnych)

Zastosowanie obiektowych baz danych i tendencje rozwoju

Obiektowe bazy danych są wykorzystywane przeważnie w systemach z dużą ilością użytkowników oraz olbrzymią pojemnością danych (niektóre aplikacje zawierają do 1TB danych). Branże stosujące systemy z obiektowymi bazami danych, to przede wszystkim:

·         badania naukowe,

·         transport, komunikacja,

·         wydawnictwo,

·         rozwój oprogramowania,

·         lotnictwo,

·         consulting,

·         finanse, bankowość,

·         medycyna,

·         produkcja.

Ogólne trendy we współczesnym przemyśle komputerowym wskazują na dalszy wzrost popularności obiektowych baz danych. W ciągu ostatnich lat sytuacja jednak zmieniła się diametralnie. Gwałtowny rozwój sieci spowodował decentralizacje magazynowania danych. Dodatkowo komputery osobiste, najczęściej pełniące role terminali, dysponują dziś znaczną mocą obliczeniową, która w ten sposób jest rozproszona w całej sieci.
W konsekwencji coraz większą popularność zyskują systemy rozproszone, w których szczególną rolę pełni tzw. technologia obiektów rozproszonych.

Obiekty w tym systemie, będąc autonomicznymi "kawałkami" kodu, tworzą otwarte środowisko, w którym aplikacja może korzystać z usług wielu specyficznych obiektów zaimplementowanych za pomocą różnych języków programowania oraz działających na rożnych platformach sprzętowych. Aby umożliwić tego typu działania, został definiowany ujednolicony standard dla obiektowych baz danych ODMG-93 (przez komitet Object Database Management Group).

Głównym celem takiego standardu było zapewnienie przenoszalności danych pomiędzy rożnymi systemami OBD oraz możliwości "przepytywania" jednego systemu przez drugi. Standard ODMG składa się z modelu obiektowego, języka zapytań OQL (Object Query Language) oraz zbioru języków programowania.
Bardzo istotnym faktem jest to, że obiektowo zorientowane języki programowania są jednocześnie językami baz danych. Zapewnia to bezpośrednią zależność miedzy obiektem w aplikacji a obiektem w bazie. Z takiej bezpośredniej zależności korzystają języki definicji danych, przetwarzania danych oraz zapytań. OBDMS zostały do tej pory zintegrowane z językami C++, C, Smalltalk, Java i LISP.

Należy zaznaczyć, że język OQL nie jest w pełni kompatybilny z SQL. SQL2 pomija zupełnie pojecie typu w znaczeniu postrzeganym przez model obiektowy. Wynikiem zapytania w języku OQL może natomiast być struktura, literał, obiekt lub zbiór obiektów. Większość baz obiektowych jest jednak wyposażona w SQL w celu zapewnienia zgodności ze standardem ODBC (Object Database Connectivity).

Przejście od architektury klient-serwer w kierunku technologii obiektów rozproszonych stwarza dobre perspektywy rozwoju dla OBD. Prawdziwym wyzwaniem dla OBD jest tez gwałtowny rozwój Internetu. W miarę wzrostu ilości użytkowników oraz przechowywanych danych, serwery stron WWW w coraz większym stopniu potrzebują cech charakterystycznych dla baz danych, takich jak oddzielenie logicznego i fizycznego poziomu danych (dane maja logiczna strukturę, która jest niezależna od fizycznej reprezentacji danych na dysku), obsługa równoległego dostępu do danych dla wielu użytkowników, obsługa transakcji, obsługa zapytań (np. wyznaczanie filtrów), zapewnienie spójności danych oraz możliwość zmiany struktury całego systemu.

Mimo to, iż większość producentów relacyjnych baz danych wprowadziła w ostatnim czasie nowe narzędzia do wspomagania integracji swoich produktów z WWW, wydaje się, że obiektowe bazy danych oferują zasadniczo nowa jakość w dziedzinie integracji serwerów WWW z bazami danych.

Dane przechowywane na serwerze WWW składają się ze stron napisanych w języku HTML, połączonych miedzy sobą odsyłaczami. Każda strona ma strukturę hierarchiczną, która może być doskonale opisana za pomocą modelu obiektowego. Coraz częściej serwery przechowują dane natury multimedialnej, co także zwiększa przewagę stosowania obiektowych baz danych nad relacyjnymi konkurentami.

Wszystkie zmiany na rynku baz danych zależą jednak od polityki komercyjnej kilku największych producentów RBD, których olbrzymi potencjał może mięć decydujący wpływ na kierunek rozwoju wydarzeń. Jednak nowoczesne tendencje w przemyśle oprogramowania zmusiły tych potentatów do rezygnacji w większym lub mniejszym stopniu z modelu tradycyjnego i dostarczenia cech obiektowych w najnowszych wersjach swoich produktów.

Oracle wprowadził swój najnowszy produkt - obiektowo-relacyjny serwer Oracle8, rozszerzony o możliwości obsługi dodatkowych typów danych takich jak wideo, audio, tekst oraz dane przestrzenne. Oracle8 został zintegrowany z najnowszą koncepcją Oracle'a - architekturą przetwarzania sieciowego (Network Computing Architecture), która dostarcza środowisko dla tworzenia, przechowywania i zarządzania "komponentami" (autonomicznymi fragmentami kodu), które mogą być wykorzystywane przy tworzeniu aplikacji sieciowych działających w środowisku heterogenicznym.

Informix od dłuższego czasu inwestuje w system Illustra, będący jednym z najbardziej zaawansowanych obiektowo-relacyjnych baz danych, dostępnych na rynku. Informix zapowiedział wprowadzenie na rynek tzw. Universal Server, skupiającego zaawansowane cechy obu tych narzędzi (relacyjnej i obiektowo-relacyjnej bazy danych).

Sybase natomiast wybrał inna drogę pogodzenia modeli relacyjnego i obiektowego. Współpracując z Persistence Software Inc. Sybase postanowił utworzyć specjalny pomost (gateway) pomiędzy relacyjną bazą danych a obiektową aplikacja użytkowa, który "w locie" wykonuje konwersje obiektów na relacje przechowywane w bazie danych. Pozwala to na szybsze wprowadzenie na rynek produktu obsługującego obiekty, ponieważ podrzędny relacyjny system Sybase'a jest pozostawiany bez zmian. Na dłuższa metę jednak podejście to nie jest konkurencyjne wskutek niedopuszczalnie dużych kosztów czasowych przejścia danych poprzez pośrednie warstwy przetwarzania podczas translacji obiektowo-relacyjnej.
 

Czy zatem relacyjne bazy danych znikną?

Wydaje się, ze nieprędko. Dla pewnych typów aplikacji relacyjne bazy danych nadal są najbardziej atrakcyjnym narzędziem ich realizacji. Prostota, jaką oferuje model relacyjny jak również oddzielenie danych od programów z nich korzystających może być istotna dla niektórych rodzajów zastosowań. Model relacyjny jest "formalny matematycznie", co umożliwia m.in. zastosowanie wyrafinowanych algorytmów optymalizacji zapytań do baz danych.

Pozycja, jaką zyskały relacyjne bazy danych na rynku w ciągu ostatniej dekady, jest bardzo mocna. Wystarczy powiedzieć, ze ich udział w rynku systemów baz danych jest obecnie blisko 100-krotnie większy od udziału systemów OBD. Rynek RBD jest podzielony pomiędzy kilku wiodących producentów, których wszystkie produkty są niemal zgodne z ujednoliconym standardem SQL.

W odróżnieniu od relacyjnych baz danych dzisiejsze systemy OBD bardzo się różnią miedzy sobą nawet na najwyższym poziomie (np. na poziomie architektury) prezentując własne rozwiązania charakterystyczne tylko dla danego produktu. Każdy produkt posiada swoje własne obszary, w których prezentuje się najlepiej. Taki stan rzeczy jest spowodowany niedojrzałością "branży OBD", brakiem ujednoliconego standardu przyjętego przez wszystkich producentów obiektowych baz danych (choć większość dostępnych produktów OBD jest częściowo zgodna z ODMG-93) oraz bardziej złożona natura obiektowych baz danych.

Mimo to OBD są koncepcyjnie bardziej dojrzale od swojego poprzednika. To znaczy, ze pozwalają przejść na zasadniczo inny poziom abstrakcji, nieosiągalny w granicach modelu relacyjnego. Oczywiście, wskutek tego mają równocześnie bardziej złożoną budowę.

Podsumowując, można powiedzieć, ze OBD już teraz sprawują się najlepiej w zastosowaniach, gdzie relacyjny model tradycyjne napotyka na trudności. Przede wszystkim są to systemy, przechowujące dane o naturze zagnieżdżonej. Jest wiec wielce prawdopodobne, ze w miarę wzrostu potrzeby przechowywania danych multimedialnych, rozwoju Internetu i WWW, OBD będą szybko zyskiwać na popularności dzięki ich naturalnemu dopasowaniu do takich zastosowań.

KONIEC