Baza po ewolucji

Tomasz Kopacz,
23.05.2005

Baza bez relacji

Bazy "nierelacyjne" zaczynają odgrywać coraz mniejszą rolę. Stworzona przez Software AG, oparta na XML baza Tamino praktycznie zniknęła z rynku, zaś rozwiązania czysto obiektowe - jeśli spojrzeć na zastosowania biznesowe, także są coraz rzadziej spotykane. Być może dlatego, że Oracle 10g czy SQL Server 2005 przestały być bazami czysto relacyjnymi i pozwalają wygodnie przechowywać także obiekty Java czy .Net. W SQL 2005 obiekt .Net może być oddzielnym typem danych, a w wyrażeniach SQL można umieszczać warunki odnoszące się do własności klas. Oczywiście, nie jest to pełna obiektowość, znana z takich serwerów, jak Poet, ale dla popularnych zastosowań taka "okrojona" obiektowość w zupełności wystarczy. Nawet jeśli nie korzystamy z tych mechanizmów, bardzo duża część programistów korzysta z jakiś mechanizmów kojarzenia logiki obiektowej z relacyjną.

Przykładem takiego rozwiązania jest Hibernate (Java) czy nHibernate w .Net. Te narzędzia pozwalają zapisać strukturę obiektową do bazy, oferują język wyszukiwania, który opiera się na obiektach itp. W efekcie programista może zapomnieć, że gdzieś "pod spodem" działa baza danych - po prostu utrwala obiekt (persistance). Hibernate implementuje JSR-220 - standardowy mechanizm zapisu obiektów EJB.

Warto dodać, że w ramach projektu Eclipse trwa obecnie spór o to, jaki mechanizm ORM (Object Relational Mapping) ma być dla tej architektury narzędziowej standardowy. Biorąc pod uwagę fakt, że Eclipse jest jedynym naprawdę liczącym się pakietem IDE dla Javy, ma to duże znaczenie. Wiadomo, że na pewno podstawą ORM w Eclipse będzie JSR-220, jednak pytanie, czy wybrane zostanie rozwiązanie Versant (Open Access), czy to, które opracuje Oracle, wciąż pozostaje otwarte. Być może ostatecznie podstawą narzędzi ORM stanie się właśnie Hibernate? Ten typ mapowania ORM zakłada jednak, że mamy dobrą strukturę obiektową, z którą możemy pracować, że znamy język kwerend oraz że wygenerowane tabele będą optymalne i szybko przetwarzane przez bazę. Poza konfiguracją narzędzia mapującego, praktycznie nikt i nic nie ma wpływu na automat generujący taką strukturę.

Postępy analizy

Pewnego rodzaju konsolidacja następuje także w dziedzinie rozwiązań OLAP. Tak naprawdę systematycznie spada udział rozwiązań "dostosowanych" - a coraz popularniejsze stają się części systemów ERP, jak SAP Business Warehouse, oraz (wciąż przybierający na popularności) serwer analityczny Microsoft.

Należy podkreślić, że formalnie systemy OLAP i OLTP to zupełnie inne światy. OLAP zakłada wielowymiarową analizę danych, pracę na wielowymiarowej "kostce". Musi mieć specjalny język zapytań oraz inne mechanizmy "wypełniania" owej "kostki. Rozwiązanie OLAP opiera się zwykle na hurtowni danych (która agreguje i czyści dane), ale może też opierać się na "surowych" danych transakcyjnych.

Patrząc na udział w rynku w 2004 r. (za firmą analityczną OLAP Reports), największy udział ma Microsoft (27,4% - w 2000 r. miał jedynie 11%), na drugim miejscu jest Hyperion z 20,7% (którego udział systematycznie spada), a potem Cognos, Business Objects, MicroStrategy i SAP. Pozostałe firmy są znacznie poniżej 5-proc. udziału w rynku.

Warto też dodać, że w SQL 2005 część analityczna została bardzo rozbudowana (pisaliśmy o tym szeroko w CW 44 i 45/2004, a także wcześniej). Rozbudowany jest mechanizm ETL. W ogóle Data Transformation Services i OLAP w SQL 2005 to zupełnie nowe produkty. Na pewno w dużym stopniu zmieni ten produkt układ sił na rynku.

Zdaniem wielu analityków rozwiązania Hyperiona czy Cognosa są znacznie lepsze niż rozwiązanie Microsoftu. Ale lepsze, oznacza zwykle tyle, że mają więcej funkcji i... wyższą cenę. Gdy Microsoft zaczął zyskiwać udziały w rynku, równocześnie zaczęła spadać cena rozwiązań OLAP - zarówno rozwiązań serwerowych, jak i aplikacji klienckich. Dzięki bardzo dobrej integracji usług Microsoft OLAP z Excelem okazało się, że inni producenci muszą także oferować interfejs zgodny z Analysis Services. Zresztą owe dodatkowe funkcjonalności oferowane przez np. Business Object były z punktu widzenia klienta znacznie trudniej dostępne, tymczasem to tabela przestawna z agregatami (i ew. wykres) przesądza o wygodzie pracy ze strukturami OLAP.

Wbrew powszechnej opinii kostki OLAP nie są olbrzymimi zbiorami. Podstawowe założenie jest takie, że kostka służy do przechowywania wyliczonych agregatów. Z kilkudziesięciu GB danych zgromadzonych w hurtowni może powstać kostka mająca zaledwie kilkanaście MB. Wielkość kostki świadczy często o tym, jak dobrze projektant zna "biznesową" wartość danych - czy jest w stanie wybrać właściwe agregaty, czy też pracuje na zasadzie "agregujmy wszystko co się da", choć oczywiście nie można tego traktować w sposób absolutny.

Wciąż nierozwiązany pozostaje problem, w jaki sposób można połączyć kwerendy SQL z kwerendami wielowymiarowymi. Oracle zaproponował pewne rozwiązanie (bazujące jeszcze na produktach z serii Express). Microsoft oferował możliwość "otworzenia" połączenia z serwem analitycznym i traktowania go jako zewnętrznego źródła rekordów. W SQL Server 2005 dostępna jest specjalna składnia, która pozwala łączyć wyrażenia MDX i SQL. Wykorzystuje ona standard XML for Analysis.

W świecie Javy opracowywany jest JOLAP (JSR 69) - zestaw API przeznaczony dla aplikacji J2EE, który ma za zadanie uprościć korzystanie z różnych rozwiązań klasy BI (w tym kostek OLAP i serwerów analitycznych). Jest to bardzo szeroki plan - obejmuje Java Metadata Interface (JSR 40), który pozwala zdefiniować tzw. metamodel hurtowni danych. Problem w tym, że nawet Hyperion (który traktuje XML i JOLAP jako technologie uzupełniające się) nie implementuje JOLAP. Opracował własne API (oparte na Javie), ale dla aplikacji klienckich oferuje XML.