W ostatnich latach na rynku baz danych zmieniło się wszystko - od teorii, przez narzędzia, aż po rozkład sił między producentami.

Historycznie, jednymi z pierwszych były tzw. bazy danych hierarchiczne. Struktura przechowywanych informacji przypominała odwrócone drzewo, czy - mówiąc prościej - strukturę katalogów i plików. Taka organizacja baz sprawdzała się doskonale we współpracy z napędami taśmowymi. Bazy mogły być zapisywane tak, by kolejne poziomy drzewa znajdowały się na sąsiadujących fragmentach taśm. Wraz ze wzrostem popularności pamięci bębnowych pojawił się sieciowy model bazy danych. Przypominał on model hierarchiczny, z tym że możliwe było tworzenie związków pomiędzy dowolnymi węzłami grafu. Model CODASYL został zaimplementowany w wielu bazach (np. ADABAS) i jest wykorzystywany do dziś. Wadą obu struktur było rozrzutne gospodarowanie pamięcią, a także trudności z aktualizacją baz.

W 1970 r. Edgar F. Codd opublikował pracę, w której postulował podział bazy danych na warstwy logiczną i fizyczną, określił zasady, pozwalające unikać nadmiarowości informacji, oraz sformułował związki pomiędzy teorią baz a teorią mnogości i rachunku predykatów pierwszego rzędu. Tak powstał najpopularniejszy do dziś relacyjny model bazy, w którym operacje na danych znajdują przełożenie na operacje na zbiorach.

Obecnie podejmowane są próby ewolucji baz w kierunku tzw. obiektowych motorów bazodanowych. W dużej mierze wynika to z faktu, że triumfy święci obiektowa teoria modelowania aplikacji. Analityk określa tzw. use case (czyli przypadki użycia danego fragmentu aplikacji), tworzy diagramy przejścia i generuje odpowiednie obiekty. Dzięki nowoczesnym narzędziom proces ten zautomatyzowano. Wiele narzędzi, np. Rational Rose czy ObjectF, potrafi na podstawie modelu w wybranym języku wygenerować prototyp aplikacji. Mimo to problemem pozostaje odwzorowanie niektórych mechanizmów obiektowych w strukturze bazy danych (dotyczy to przede wszystkim dziedziczenia obiektów i usuwania domyślnie tworzonych instancji). Pojawił się pomysł opracowania wyspecjalizowanych, obiektowych baz, które potrafiłyby zapewnić trwałość obiektom tworzonym w aplikacjach.

Konsorcjum ODMG opracowało specyfikację obiektowej bazy danych i język zapytań OQL, który zbudowano na bazie standardu SQL-92. Ma on rozszerzenia pozwalające np. w warunku kwerendy zawrzeć odwołanie do konkretnej metody czy nadrzędnego obiektu. Powstały dwie specyfikacje (nie zaimplementowane): ODMG 93 i 95. Mimo że zdefiniowano język zapytań, to brak języka pozwalającego tworzyć i przekształcać obiekty. Okazało się także, że w większości nowo powstających aplikacji wykorzystywany jest zaledwie ułamek możliwości "obiektowych" baz danych. Wynika to z tego, że dotąd nie opracowano algorytmów, które pozwalają optymalizować zapytania kierowane do baz obiektowych; czas oczekiwania na odpowiedź gwałtownie rośnie wraz ze zwiększaniem liczby danych. Poza tym nie wiadomo jak podzielić aplikację - jakie operacje mają być wykonywane przez bazę, jakie przez aplikację i warstwę środkową.

Dużą popularność zyskały rozwiązania typu ORDBMS, w których na motor relacyjny nakładane są elementy obiektowe. Motory baz pozwalają na programowanie procedur wbudowanych przy użyciu Javy. W ten sposób można po stronie serwera stworzyć klasy, metody dostępu do procedur składowych i wyrafinowane procedury sprawdzania integralności danych. Należy jednak zwrócić uwagę, że współczesne aplikacje tworzone są przeważnie w architekturze trójwarstwowej. Aplikacja kliencka, chcąc zapisać czy odczytać informację z bazy, komunikuje się z obiektami, które działają na serwerze aplikacyjnym i są pośrednikami w dostępie do bazy. Tworzenie obiektów i metody dostępu są implementowane poza serwerem bazy. Okazało się, że tak naprawdę z obiektowych baz danych wykorzystywane są tylko możliwości tworzenia złożonych typów danych oraz, w niektórych przypadkach, rzutowania i tworzenia hierarchii dziedziczenia. Baza przechowuje informacje, a interfejs obiektowy zapewnia warstwa logiki biznesowej, działająca poza serwerem, stworzona w jednym uniwersalnym języku.

Motory bazodanowe są wykorzystywane do specjalnych celów. POET (obecnie FastObjects) jest przykładem wyspecjalizowanej, "czysto" obiektowej bazy danych. Serwer pozwala utworzyć repozytorium obiektów, dostępne dla wielu użytkowników. W odróżnieniu od rozwiązań ORDBMS, FastObjects stosuje blokadę zasobów na poziomie pojedynczego obiektu, dzięki czemu może obsłużyć wiele użytkowników. Do bazy można uzyskać dostęp z poziomu kodu w C++ i Javie. Oprócz "pełnego" motoru bazodanowego, istnieją bardziej popularne wersje tej bazy, przeznaczone do osadzania w aplikacji. Programista zyskuje dodatkowe biblioteki, które pozwalają w naturalny sposób zapisać stan obiektów w programie, a ponadto zapewniają interfejs do wyszukiwania informacji. FastObjects j2 to motor przeznaczony dla urządzeń wbudowanych (wymaga tylko 450 KB pamięci) i zapewnia te same funkcje co "pełny" motor. Z kolei w rozbudowanej wersji Fast- Objects e7 dostęp do danych może być realizowany poprzez interfejs typu ODBC.

W zdecydowanej większości baz wprowadzono tylko pewne obiektowe rozszerzenia do istniejących motorów relacyjnych. Obiekty i mechanizmy dostępu oprogramowuje się w Javie, a obiekt jest umieszczany w relacyjnych "wierszach" tabel. Tak działają m.in. IBM DB2, Sybase ASE 12.5 oraz Oracle od wersji 8i.

Baza dla aplikacji

Kilka lat temu większość aplikacji korzystała jeszcze z baz plikowych. Program samodzielnie decydował, co i gdzie ma zapisać w pliku o określonym formacie. W aplikacjach, z których korzystało jednocześnie wielu użytkowników, były stosowane np. dodatkowe pliki z zapisem blokad. Programy te mogły jednak obsłużyć tylko ograniczoną liczbę użytkowników, ponieważ o prędkości całego rozwiązania decydował najwolniejszy komputer kliencki. Poza tym w aplikacjach powszechnie stosowano rozwiązania, które np. zakładały odczytywanie wszystkich rekordów z bazy do wygenerowania nawet szczątkowego raportu.

Obecnie powstają dwa typy aplikacji bazodanowych - z tzw. cienkim i grubym klientem. Cienki klient to rozwiązania oparte na interfejsie WWW. Ponieważ komputery klienckie są coraz bardziej wydajne, często spotyka się rozwiązanie, w którym klient nie jest ciągle połączony z serwerem, ale np. lokalnie gromadzi informacje i w trybie wsadowym przesyła je do serwera. Coraz popularniejsze są rozwiązania, w których po stronie klienta działa okrojony motor bazy danych, przechowujący "tymczasowe" informacje, później replikowane z serwerem. Takie motory działają nawet na palmtopach (Oracle Lite, SQL 2000 dla PocketPC czy Sybase Anywhere). Producenci doskonalą mechanizmy replikacji - niemal każda baza pozwala automatycznie synchronizować bazę, praktycznie bez interwencji programisty.

Od dawna panuje przekonanie, że baza do efektywnej pracy wymaga "strojenia". Producenci starają się obalić ten mit. Najdalej poszedł w tym kierunku Microsoft. Mechanizmy kontroli nad serwerem SQL 2000, który od roku zajmuje pierwsze miejsce w testach TPC/C, sprowadzają się do kilku parametrów ustawianych w oknie Opcji. Dzięki temu dystrybucja bazy z własną aplikacją nie wymaga skomplikowanego procesu instalacyjnego. Inne rozwiązanie wybrał Sybase. Firma umożliwiła "profilowanie" swojego serwera, tak by twórcy aplikacji mogli określać, jak baza ma działać, aby użytkownik w ogóle nie musiał zajmować się strojeniem.

Warto w tym miejscu wspomnieć o bazie Pevarsive.SQL 2000, następcy Btrieve, która popularność w Polsce zawdzięcza systemowi NetWare (była ona dystrybuowana wraz z oprogramowaniem Novella). To baza przeznaczona dla małych i średnich aplikacji, wymagających motoru bazodanowego. Architektura Pevarsive jest oparta na mikrojądrze, które pozwala na szybki dostęp do danych. Stara baza Btrieve nie była w pełni relacyjna. Pozwalała na pewnego rodzaju kontrolę nad transakcjami, jednak sposób przechowywania informacji przypominał bazy plikowe. Pevarsive.SQL udostępnia API zgodne z Btrieve, a równocześnie zapewnia dodatkową warstwę odpowiadającą za obsługę relacji. Dzię-ki temu do bazy można uzyskać także dostęp za pośrednictwem ODBC, JDBC, a także "rodzimych" sterowników OLEDB (komunikujących się z mikrojądrem, a nie z warstwą relacyjną).

Analiza danych - inny świat

Hurtownie danych to bardzo wyspecjalizowane serwery bazodanowe. Ich podstawowym zadaniem jest przechowywanie olbrzymich ilości informacji i zapewnienie szybkiego dostępu do określonych danych. Zasilanie hurtowni danych to tzw. proces ETL (Extract Transform Load), czyli uzyskanie informacji z systemów produkcyjnych, transformacja struktury i dostosowanie jej do organizacji bazy oraz wczytanie do serwera.

Bazy produkcyjne zwykle są systemami transakcyjnymi (tzn. zapisują dokładny plik log wszystkich operacji tak, by można było je "wycofać"). W hurtowniach taka organizacja przeszkadza (ładowanie 1 GB danych spowoduje powstanie zupełnie niepotrzebnego olbrzymiego logu). Tak więc większość producentów baz stara się rozgraniczyć systemy relacyjne i moduły przeznaczone do hurtowni danych czy wielowymiarowych analiz OLAP. W przypadku MS SQL 2000 hurtownia danych i serwer OLAP są integralnym elementem serwera. Inne systemy bazodanowe wymagają dokupienia oddzielnych licencji na narzędzia analityczne.

W przypadku dużych hurtowni danych przedsiębiorstwa sięgają po wyspecjalizowane rozwiązania - systemy SAS czy NCR Terradata, które są projektowane z myślą o przechowywaniu dużych ilości informacji i zapewnieniu mechanizmów szybkiej analizy.

NCR Terradata potrafi tworzyć bazy o pojemności 1023 petabajtów (w klastrze może być do 512 węzłów). Wspiera zarówno wieloprocesorową architekturę SMP, jak i MPP. Ponieważ z założenia nie jest to rozwiązanie, w którym dane często się zmieniają, baza NCR w oryginalny sposób przetwarza kwerendy kierowane do systemu. Wykorzystuje klastry share-nothing - kwerenda rozbijana jest na wiele równoległych procesów AMP, które odczytują informacje z bazy. Każdy AMP może działać jednocześnie z innymi i zajmuje się tylko swoim fragmentem bazy. NCR opracował własny sposób komunikacji węzłów klastra, który pozwala na znacznie szybsze, jednokierunkowe przekazywanie zadań (a następnie zbieranie wyników). Do Terradaty wprowadzono wiele modułów pozwalających szybko wczytywać dane do bazy (np. równoległe wczytywanie danych do wielu tabel przez niezależne procesy).

Analizy wielowymiarowe OLAP pozwalają analizować informacje przechowywane w bazie danych. Na istniejące dane nakładana jest definicja wymiarów, miar i pewnych dodatkowych funkcji statystycznych generujących podsumowania. Nie należy utożsamiać analiz OLAP z eksploracją danych z hurtowni. Proces eksploracji polega na odkrywaniu ukrytych związków pomiędzy informacjami w bazie (np. dodatkowych związków między preferencjami klientów a ich kolorem oczu). OLAP pozwala natomiast wizualizować strukturę informacji, np. przeglądać dane historyczne o sprzedaży z dodatkowym podziałem geograficznym na różnych poziomach szczegółowości. Jednak bardzo często serwer OLAP jest wykorzystywany jako motor do przechowywania informacji z hurtowni danych. Warto wspomnieć, że jednym z popu- larniejszych samodzielnych serwerów OLAP jest Hyperion Essbase. Umożliwia on użytkownikowi pracę na wielowymiarowej kostce danych tak, jak pracuje się w arkuszu kalkulacyjnym.

Zamieszanie z XML

XML to język oparty na znacznikach, pozwalający wygodnie zapisywać hierarchiczne dokumenty. Obecnie XML to również język definiujący strukturę dokumentu (DTD, XML-Schema), a także język zapytań (Xquery, Xpath) do wyszukiwania informacji w dokumencie. Łatwo zauważyć, że w gruncie rzeczy są to cechy... bazy danych. Wiele operacji, które dotychczas były wykonywane w bazie, teraz można wykonać przy użyciu parsera XML. Także w motorach relacyjnych pojawiło się kilka elementów związanych z obsługą tego formatu danych.

Motor Sybase ASE 12.5 pozwala na równorzędne traktowanie zapytań SQL i Xpath. W momencie zapytania Xpath serwer generuje XML-owy obraz danych relacyjnych. Jest on przechowywany tak, by kolejne zapytanie nie wymuszało ponownej budowy dokumentu XML.

W Microsoft SQL Server 2000 programista może sam zdecydować, jak będzie tworzony XML-owy obraz bazy danych. Definiując odpowiednią strukturę, XDR określa dokładnie sposób odwzorowania danych relacyjnych (można pominąć niektóre atrybuty pól czy wręcz zrezygnować z części informacji). Operacje na XML po stronie serwera wymagają otworzenia specjalnego typu kursora i aktualizacji danych relacyjnych za pośrednictwem widoku XML.

Podobne rozwiązanie przyjęto w IBM DB2 7.1 Można generować "widok relacyjny" dokumentu XML albo na podstawie wybranej kwerendy tworzyć dokument XML. IBM wprowadził nowy typ pola do przechowywania danych XML i zintegrował bazę z parserem, co pozwala z poziomu procedur wbudowanych wykonywać większość operacji w tym języku.

Także w bazie Oracle jest dostępny nowy typ pola i zintegrowany parser. Można wyszukiwać najpierw rekody, które spełniają dane warunki SQL, a następnie wybrać odpowiednim wyrażeniem XPath dane z pola XML.

Dostępne są także rozwiązania, w których nie jest konieczna transformacja pomiędzy danymi relacyjnymi a XML. Tamino to pierwsza baza danych, w której informacje są przechowywane w formacie XML. Nie jest to baza relacyjna, jej architektura przypomina bazy sieciowe. Jednak w odróżnieniu od nich Tamino pozwala na bardziej elastyczne modelowanie.

Tamino, podobnie jak bazy sieciowe, szczególnie nadaje się do generowania raportów czy integracji danych z różnych źródeł. Zapytania kierowane do bazy sieciowej są formułowane w naturalny sposób (określane są warunki nakładane na kolejne węzły grafu). Warto dodać, że XML i hierarchiczna struktura pozwalają znacznie lepiej definiować poziom poufności informacji. Można blokować dostęp niepowołanym osobom do pól imienia i nazwiska, a udostępniać inne pola. Stworzenie takiej struktury w bazach relacyjnych jest dosyć trudne.

Jednak systemy RDBMS to nie tylko motory, ale także cały zestaw narzędzi ułatwiających pracę programiście (generatory kwerend, narzędzia tworzące fragmenty kodu standardowych formatek itp.). Do baz XML takich narzędzi nie ma. Można próbować wykorzystywać tradycyjne narzędzia do manipulacji XML-a. Zresztą programista przyzwyczajony do pracy z bazami relacyjnymi dosyć szybko przestawi się na "myślenie hierarchiczne".

Tamino ciekawie rozwiązuje problem interfejsu dostępu do bazy. Oprócz specjalnego API (przeznaczonego głównie dla Javy), może zintegrować się z serwerem WWW. Pozwala też, by kwerendy były zadawane w podobny sposób, w jaki są przekazywane parametry w URL. Producent Tamino rozszerzył standard HTTP o kilka pól związanych z obsługą zapytań i odpowiedzi XML.

Jaką rolę odegra XML (poza uniwersalnym formatem wymiany) w aplikacjach bazodanowych? Na pewno jest językiem, który pozwala stosunkowo prosto skonstruować pamięć podręczną do przechowywania danych. Nadaje się też jako format pośredni, wykorzystywany w warstwie pomiędzy aplikacją a serwerem bazodanowym. Dzięki temu można tworzyć tzw. rozłączone zestawy danych, w których aplikacja kliencka działa bez stałego połączenia z serwerem.

Czy w takim razie kombinacja XML + parser nie zastąpi "ultralekkich" motorów bazodanowych? Z jednej strony, długość parsera XML jest porównywalna z długością mikromotorów bazodanowych. Z drugiej jednak, dane kodowane w XML zajmują zwykle więcej miejsca niż analogiczne pliki bazodanowe. W takiej sytuacji na palmtopie z systemem PocketPC bardziej opłaca się instalacja SQL 2000 niż próba zmieszczenia dużych dokumentów XML.

<hr>

Za tydzień opublikujemy artykuł o bazodanowych rozwiązaniach klastrowych.