Wzór obiektu w bazie relacyjnej

Standardem w programowaniu nowych aplikacji jest obiektowość, ale obiektów nie da się łatwo zapisać w relacyjnej bazie danych.

Standardem w programowaniu nowych aplikacji jest obiektowość, ale obiektów nie da się łatwo zapisać w relacyjnej bazie danych.

Przy pisaniu aplikacji w Javie lub C++, gdy dane w niej używane zapisywane są w relacyjnej bazie danych, posługującej się SQL, pojawia się coś, co inżynierowie elektronicy nazywają "niedopasowaniem impedancji", którego to terminu (z braku lepszego) używają również programiści.

Struktura obiektów aplikacji nie pasuje do struktury bazy danych, dlatego aplikacja nie może "porozumieć się" z bazą. Relacyjne bazy danych przechowują informacje w wielu płaskich tabelach z wieloma wierszami i wyróżnionymi kolumnami. Cała informacja jest przechowywana na jednym poziomie. Natomiast języki obiektowe, takie jak C++ czy Java, posługują się hierarchicznymi strukturami obiektów o wielu poziomach klas. Przed programistą stoi zadanie odwzorowania tej struktury na płaski model danych.

Jedną z metod odwzorowania obiektów na płaski model jest użycie narzędzi do tworzenia obiektowo-relacyjnej mapy danych. Narzędzia OR w pewnym sensie "normalizują" obiekty, przekształcając je na jedną lub więcej encji do zapisania w bazie relacyjnej lub zapisując wiele obiektów w jednej encji. Nadają się do tworzenia map obiektowo-relacyjnych dla większości popularnych baz danych. Znane są od początku lat 90. i były używane głównie w środowiskach akademickich dla programów pisanych w języku C++.

Wraz ze wzrostem popularności Javy jej cechy obiektowe są wykorzystywane coraz lepiej. Obiektowe metody tworzenia aplikacji obecnie przeważają nad metodami proceduralnymi, gdyż w końcowym wyniku istotna jest łatwość utrzymania i aktualizowania aplikacji.

Odwzorowanie obiektowo-relacyjne OR dotyczy wszystkich programistów posługujących się językami o orientacji obiektowej, nie tylko Javy. Ponieważ jednak Java "wymusza" obiektowość, producenci narzędzi OR do odwzorowania obiektów na bazy relacyjne koncentrują się właśnie na tym języku. Programowanie obiektowe jest również coraz bardziej popularne w środowisku Windows i problem dotyczy go w równej mierze.

Co z bazami obiektowymi?

Jeżeli baza relacyjna nie może przechowywać obiektów, to po co jej używać? Odpowiedź jest prosta - ponad 90% istniejących danych jest zapisanych w bazach relacyjnych. Jeżeli więc mamy już pewne dane w bazie relacyjnej - nie ma wyboru.

Jeżeli jednak wybieramy bazę dla nowej aplikacji obiektowej, która nie korzysta z istniejących zasobów danych, lepszym wyborem jest baza obiektowa. Zależnie od rodzaju danych może ona działać 100-1000 razy szybciej niż baza relacyjna; odwzorowanie obiektów na bazę relacyjną zdecydowanie spowalnia aplikację. Wprawdzie najwięksi producenci baz relacyjnych dodają im cechy obiektowe, jednak nie istnieje nic takiego, jak możliwość bezpośredniego przechowywania obiektów Javy w bazie.

Oszczędzać czas i pieniądze

Czy warto korzystać z narzędzi OR? Zawsze można ręcznie wpisać w kodzie aplikacji wywołania funkcji JDBC. Trzeba jednak mieć świadomość, że to zadanie czasochłonne i podatne na błędy. Ponadto utrzymywanie kodu napisanego przez inną oso- bę jest znacznie łatwiejsze w przypadku stosowania narzędzi OR wysokiego poziomu niż w przypadku wpisywania kodu JDBC bezpośrednio do kodu Java aplikacji.

Dobre narzędzia OR pozwalają na bieżąco zmienić odwzorowanie obiektowo-relacyjne, co pozwala modyfikować strukturę lub zreorganizować bazę, bez zmiany kodu aplikacji. To poważny argument, by ich używać.

Dostępne narzędzia OR są wygodne w użyciu, mają prosty interfejs graficzny i - zdaniem producentów - mogą się nimi posługiwać nieprofesjonaliści. Nie oznacza to bynajmniej, że operacja odwzorowania to zadanie trywialne. Stworzenie dobrych reguł odwzorowania obiektów na tabele bazy wymaga sporego doświadczenia i znajomości technik obiektowych. Istnieje bowiem wiele różnych możliwości odwzorowania.


TOP 200