Celem naszego opracowania jest porównanie relacyjnych i obiektowych baz danych (RBD i OBD) w oderwaniu od konkretnych produktów. Mówić będziemy również o obiektowo-relacyjnych BD - najpopularniejszych obecnie (w przeliczeniu na dolary) systemów bazodanowych, stanowiących komercyjny kompromis pomiędzy modelem relacyjnym i obiektowym. Pokrótce scharakteryzujemy każda z tych generacji, zwrócimy uwagę na podstawowe cechy wspólne i różnice.
Zdobyte przez nas materiały dotyczące RBD były pisane w odniesieniu do sieciowych oraz hierarchicznych BD, a te dotyczące OBD pisane w okresie rozkwitu podejścia obiektowego do wszystkich dziedzin informatyki, które tylko można takim spojrzeniem objąć. Dlatego tez nasze opracowanie mimo wielu starań może się okazać nieco "tendencyjne" podobnie jak większość opublikowanych do tej pory porównań RBD i OBD.

Podział i charakterystyka baz danych
Bazy danych bardzo różnią się miedzy bosa - praktycznie każdy produkt tworzy własną kategorie i dlatego trudno je szufladkować. Te zależność najlepiej widać właśnie w przypadku baz relacyjnych i obiektowych: model relacyjny okazał się zbyt skromny dla rosnących potrzeb, a obiektowy zbyt trudny (zbyt kosztowny) w realizacji. Prawa rynku wymusiły wiec powstanie bardzo silnej grupy "relacyjno-obiektowych baz danych", której nie sposób pominąć w naszym opracowaniu.
Jako elementy charakteryzujące dana grupę wybraliśmy

• model danych (data model),

• język zapytań (query language),

• i model obliczeniowy (computational model).

Relacyjne bazy danych (RDBMS)
Technologia relacyjnych baz danych została opracowana przez E. F. Codda i zaimplementowana później m.in. przez IBM. Ostatecznie standard RDBMS został opracowany przez ANSI X3H2. Zwykle produkt kwalifikuje się przy pomocy wersji specyfikacji języka SQL (ostatni to SQL2). Z czasem relacyjne bazy danych oddalały się od swej teoretycznej podstawy - algebry relacji.

Model danych
Dane przechowywane są w tabelach, z których każda ma stała ilość kolumn i dowolna ilość wierszy. Wiersze odpowiadają niepodzielnym krotkom (tuple), a kolumny odpowiednim atrybutom (attribute). Kolumny zawierają dane określonego typu, po jednej wartości w wierszu. Typy są zdefiniowane na etapie projektowania bazy danych i jest ich określona ilość, maja stały rozmiar i zwykle są to ogólnie znane typy proste (liczba, data, godzina, ciąg znaków, znak, itp.). Każda tabela (relacja) ma zdefiniowany klucz (key) - wyróżniony atrybut lub kilka atrybutów, którego wartość jednoznacznie identyfikuje dany wiersz.

Język zapytań
Widok (view) jest to pewien podzbiór bazy danych podawany w formie tabeli, będący wynikiem wykonania zapytania. Dane z bazy są wybierane na podstawie wartości w konkretnych pól w krotkach. Zapytania mogą mieć prosta postać i wymagać danych z wyłącznie jednej tabeli, jak również mogą być bardzo wyrafinowane wymagając od systemu operowania łączeniem (join), zagnieżdżaniem (nesting), różnica i suma teorii zbiorów (set union/difference) oraz innymi operacjami.

Model obliczeniowy
Wszelkie przetwarzanie oparte jest na wartościach pól w krotkach. Krotki nie posiadają uniwersalnego identyfikatora (niezmiennego w czasie). Nie ma tez zabezpieczenia przed odnoszeniem się do innego wiersza tej samej tabeli. Przeglądanie wyników zapytań odbywa się przy pomocy "kursora" umożliwiającego przeglądanie wiersz po wierszu. Podobnie ma się sprawa uaktualniania danych. Manipulacja relacjami odbywa się w sposób globalny przy użyciu operatorów algebry relacji (lub temu podobnych jeżyków) - przetwarzanie wiersz po wierszu nie jest dozwolone.

Liczące się na rynku RDBMS
Oracle (wersje 7.x), System 10/11 [Sybase], Dynamic Server [Informix], DB/2 [IBM], OpenIngres [Computer Associates]

Obiektowe bazy danych (ODBMS)
Obiektowe bazy nie są określone żadnym oficjalnym standardem. Obowiązujący obecnie standard de facto opracowany przez ODMG został opublikowany w roku 1993. Jednym z podstawowych celów modelu obiektowego jest bezpośrednie odwzorowanie obiektów i powiązań miedzy nimi wchodzących w skład aplikacji na zbiór obiektów i powiązań w bazie danych. Dzięki mechanizmom obiektowym można tez zwiększyć niezależność danych od aplikacji poprzez przeniesienie procedur obsługi danych (w postaci metod) do systemu zarządzania baza.

Model danych
Model danych stosowany w obiektowych bazach danych korzysta z pojęć takich jak klasy, atrybuty, metody, udostępnia identyfikatory obiektów (OID), hermetyzacje danych oraz metod, wielokrotne dziedziczenie, etc.
Obiektowe bazy danych łącza własności obiektowości i obiektowych języków programowania z możliwościami systemów bazodanowych, a wiec nie tylko przechowywanie danych czy obiektów. Rozszerzają możliwości obiektowych języków programowania (takich jak C++, Java czy Smalltalk) czyniąc z nich narzędzia do łatwego i efektywnego tworzenia systemów baz danych zmniejszając stopień złożoności i ilość kodu programów dzięki zgodności koncepcyjnej na każdym etapie powstawania produktu.

Jezyk zapytan
Obiektowo zorientowany język staje się zarówno językiem programowania jak i językiem bazy danych, zapewniając 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.
Standard ODMG-93 dostarcza dodatkowo deklaratywny języki OQL. Język ten nie jest w pełni kompatybilny z SQL. SQL2 pomija zupełnie pojecie typu w znaczeniu postrzeganym przez model obiektowy. Wynik zapytania w języku OQL może natomiast być struktura, literałem, obiektem lub zbiorem obiektów. Większość baz obiektowych jest jednak wyposażona w SQL w celu zapewnienia zgodności ze standardem ODBC (Object Database Connectivity).

Model obliczeniowy
Mimo, ze podobnie jak w RDBMS, wciąż możliwe są zapytania deklaratywne, głównym sposobem tworzenia i modyfikacji obiektów jest korzystanie bezpośrednio z odpowiedniego dla bazy obiektowego języka programowania. Ponadto tworzone obiekty otrzymują unikalne identyfikatory niezmienne w czasie, które mogą być wykorzystywane przez inne obiekty w celu definiowania powiązań z tymi obiektami. Zwykle identyfikatory są konwertowane na wskaźnik do pamięci w chwili wczytywania konkretnego obiektu - uzyskujemy dzięki temu skrócenie dostępu do obiektu gdy jest on obecny np. w pamięci podręcznej.

Liczące się na rynku ODBMS
Jasmine [Computer Associates], Gemstone, O2, Object Store [Object Design], Objectivity/DB [Objectivity], Versant ODMBS [Versant]

Obiektowo-relacyjne bazy danych (ORDBMS)
Stanowią bardzo silna grupę systemów, która w ostatnim czasie dobrze zaznaczyła się na rynku oprogramowania. Nazywane są Object Relational lub Extended Relational. Są wynikiem ostrożnej ewolucji systemów relacyjnych w kierunku obiektowych. Kierunek rozwoju jest wyznaczany przez dwie tendencje:

• dążenie do zniwelowania niedostatków technologii relacyjnej, szczególnie w zakresie danych multimedialnych, dołączania metod lub reguł "zachowania się" danych, modelowania pojęciowego,

• chęć wprowadzenia wielu cech obiektowości, takich jak klasy, metody, dziedziczenie, abstrakcyjne typy danych (ADT) - własności potwierdzające choć częściowa obiektowość systemu relacyjnego.

Model danych
ORDBMS korzysta z modelu danych zawartego w standardzie SQL3, który mówi, ze "obiektowo-relacyjny model danych próbuje dodać obiektowości do tablic". Dane są wciąż przechowywane w tabelach, jednak wartości mogą mięć nieco bogatsza 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).

Jezyk zapytan
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.

Model obliczeniowy
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ę.

Liczące się na rynku ORDBMS
Oracle (wersje 8.x), Illustra (Universal Server) [Informix], DB/2 Extenders (Universal Database) [IBM], UniSQL/X [UniSQL], OSMOS [Unisys]

Migracja

Na powyższym schemacie widać najistotniejsze zmiany architektury dokonane przy przejściu z modelu relacyjnego na obiektowy. Należy tu szczególnie zwrócić uwagę, ze cześć informacji tkwiącej w bibliotekach, typach, aplikacjach i modułach została usystematyzowana i umieszczona bezpośrednio w klasach.

 

Porównanie
Poniższa tabelka jest próba zebrania w przejrzysty sposób informacje podanych wcześniej wraz z wypływającymi z nich wnioskami.

cecha	RDBMS	ORDBMS	ODBMS
Standard	SQL2 (ANSI X3H2)	SQL3/4 (w opracowaniu)	ODMG-v2.0
współpraca z obiektowymi językami programowania	słaba, programiści musza dostosowywać program obiektowy do potrzeb bazy	graniczona głownie do nowych typów danych	bezpośrednia, szeroko rozumiana
użytkowanie	łatwa do zrozumienia struktura, wiele narzędzi dla użytkowników	zapewnia niezależność danych od aplikacji, trudno odzwierciedlać złożone powiązania	łatwe dla programistów, użytkownikom pozostaje pewien dostęp przez SQL
programowanie	zapewnia niezależność danych od aplikacji, trudno odzwierciedlać złożone powiązania	zapewnia niezależność danych od aplikacji, trudno odzwierciedlać złożone powiązania	obiekty w naturalny sposób odzwierciedlają dziedzinę, łatwość modelowania różnorodnych typów i powiązań
rozszerzalność	brak	głownie ograniczona do nowych typów danych	daje sobie rade z dowolna złożonością dziedziny, użytkownicy mogą pisać metody i dołączać struktury
złożone dane i powiązania miedzy nimi	trudne do zrealizowania	trudne do zrealizowania	daje sobie rade z dowolna zlozonoscia dziedziny, uzytkownicy moga pisac metody i dolaczac struktury
"dojrzałość" systemów	bardzo dojrzale, dobrze poznana i przetestowana metodologia, liczne implementacje, stabilność na rynku	niedojrzałe, rozszerzenia są nowe, wciąż ewoluujące i stosunkowo słabo poznane	dość dojrzale (dzięki powszechności OOA i OOD)
możliwość utrzymania się na rynku	przewidywana dla dużych przedsiębiorstw obecnych na rynku	przewidywana dla przedsiębiorstw znanych z RDBMS, dołączają się nowi	na razie trudno prognozować mimo iż sukces modelu obiektowego wydaje się oczywisty

Wady i zalety poszczególnych modeli

Poniżej podajemy te cechy poszczególnych modeli, które w zasadniczy sposób odróżniają je miedzy sobą. Wydaje nam się, ze taka zwięzła charakterystyka jest łatwiejsza do przeanalizowania, niż długa tabela, która w większości pól zawierałaby "nie dotyczy".

RDBMS Relacyjne bazy danych

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ść impedancji

• niezgodność modelu pojęciowego z modelem implementacyjnym

ODBMS Obiektowe bazy danych

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 (wers jonowanie, 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

Większość wad z czasem samoczynnie zaniknie, gdyż są spowodowane po prostu zbyt dużym tempem rozwoju w porównaniu do innych dziedzin (np. szkolenia programistów, zmiany mentalności, ...).

ORDBMS Obiektowo-relacyjne bazy danych

Zalety:

• przystosowanie do multimediow (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 (np. niezgodności impedancji)

• 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)

 

Krótkie porównanie relacyjnych i obiektowych baz danych

	RELACYJNE	OBIEKTOWE
Cechy podstawowe	Dane zawarte w tabelach Tabele składają się z kolumn Typy - predefiniowalne Liczba wierszy zmienna Value-based Nie ma wskaźników lecz klucze zewnętrzne	Obiekt w bazie reprezentuje obiekt w świecie rzeczywistym Typ obiektowy (klasa): definicja złożonego typu danych (może zawierać inne typy obiektowe lub ich kolekcje) procedury (metody) i operatory do manipulowania tymi danymi Identity-based Enkapsulacja Dziedziczenie: strukturalne: potomek dziedziczy strukturę danych. behawioralne: potomek dziedziczy metody i operatory
Przykłady systemów	Oracle, Informix, Sybase, Ingres, DB2, Progress, Gupta, Access	GemStone, O2, Persistence, Versant, POET, Objectivity, ODI
Stan na dzisiaj	Dominuje w zastosowaniach komercyjnych (ok. 95% rynku baz danych)	Mniej popularne, jednak dobrze rokują na przyszłość
Zalety	niezależność od języka programowania sprawdzone, dobrze zdefiniowana teoria możliwość zarządzania wielka ilością danych możliwość złożonych kryteriów wyszukiwawczych możliwość dostępu do danych fizycznych dobre mechanizmy kontroli dostępu do danych mechanizmy perspektyw	dość łatwa reprezentacja świata dokładnie reprezentuje złożone zależności miedzy obiektami łatwość działania na złożonych obiektach duża podatność na zmiany możliwość definiowania własnych typów, metod dobra integracja z językami programowania ogólnego przeznaczenia (np. C++, Smalltalk) ujednolicony model pojęciowy - obiektowe podejście do analizy, projektowania i implementacji
Wady	brak bezpośredniej reprezentacji n-m dla trudniejszych problemów bardzo dużo tabel mało naturalna reprezentacja danych ograniczona podatność na zmiany brak złożonych typów danych trudne operowanie na danych złożonych trudne operowanie na danych rozproszonych w sieci heterogenicznej niezgodność z modelem używanym przez języki ogólnego przeznaczenia (impedance mismatch)	powiązanie z jednym językiem programowania słaba obsługa przeszukiwania danych brak powszechnie zaakceptowanego języka zapytań brak możliwości optymalizacji zapytań trudny lub nawet niemożliwy dostęp do fizycznych danych słaba kontrola dostępu małe możliwości optymalizacji pracy serwera
Lepsze gdy...	dane są proste, niezagnieżdżone, łatwe do umieszczenia w tablicy dane maja postać bierna, a procesy korzystające z danych stale się zmieniają często potrzeba wyszukiwać dane spełniające różnorodne warunki	dane maja złożona lub zagnieżdżoną strukturę zdefiniowana przez użytkownika dane tworzą hierarchie dane są rozproszone w sieci heterogenicznej dane dynamicznie zmieniają rozmiar

 

 

Bibliografia
1. Steve McClure; "Object Database vs. Object-Relational Databases"; Sierpien 1997
2. Kazimierz Subieta; "Obiektowe Bazy Danych kontra Relacyjne Bazy Danych"
3. Won Kim; "Wprowadzenie do obiektowych baz danych"; Wydawnictwa Naukowo-Techniczne
4. Kazimierz Subieta; "Slownik czesto spotykanych terminow dotyczacych obiektowosci; Wrzesien 1997