Bazodanowe rozwiązania OLAP

Praktycznie wszyscy producenci relacyjnych baz danych oferują narzędzia analityczne OLAP. W środowisku open source ciągle nie ma stabilnego rozwiązania OLAP.

Praktycznie wszyscy producenci relacyjnych baz danych oferują narzędzia analityczne OLAP. W środowisku open source ciągle nie ma stabilnego rozwiązania OLAP.

Systemy Business Intelligence, będące coraz powszechniejszym elementem systemów informatycznych przedsiębiorstw, są oparte na analitycznych systemach OLAP. Zwykłe bazy transakcyjne nie dają możliwości wyliczania skomplikowaagregatów, są bowiem projektowane w taki sposób, że większość wynikowych informacji nie jest przechowywana. Jeżeli jakaś wartość zostanie wyznaczona na podstawie zawartości kolumn w bazie, to nie musi być ona trwale przechowywana w bazie. W przypadku baz OLAP postępowanie jest odwrotne - projektant określa strukturę kostki OLAP, tzn. wskazuje, jakie informacje mają być gromadzone i agregowane, a następnie motor OLAP wylicza żądane statystyki, które są przechowywane obok informacji bazowych.

Klasycznym przykładem zastosowania kostki OLAP jest analiza wartości sprzedaży. W tym przypadku wymiarami kostki może być typ towaru, region sprzedaży, data sprzedaży czy też nazwa kanału dystrybucyjnego, w którym dany towar był dostępny. By zasilić taką kostkę z systemu OLTP (przetwarzania transakcyjnego), pobiera się informacje dotyczące bieżących obrotów i zapisuje w strukturze OLAP. Nie jest to tylko proste kopiowanie wartości - kostki można zasilać wyliczonymi danymi. Przykładowo, można określić różne poziomy szczegółowości danych (np. grupa towaru, kraina geograficzna czy przedział czasowy: rok, miesiąc, tydzień). Podczas wypełniania kostki motor wylicza np. sumaryczną wartość sprzedaży na całym świecie w określonym roku, a następnie w rozbiciu na poszczególne kontynenty i miesiące. Chociaż zasilanie kostki jest procesem czasochłonnym, to musi być ona aktualizowana w określonym cyklu (np. raz dziennie).

System analityczny może potem szybko czerpać informacje z tak skonstruowanej struktury kostek, tj. wykonywać określone przekroje, np. wybrać dane o wartości sprzedaży w Europie w maju 2002 r., a następnie je uszczegółowić i podać wartość sprzedaży w pierwszym tygodniu maja. Teoretycznie tego typu operacje można wykonać za pomocą bazy OLTP, jednak taka kwerenda mogłaby łatwo spowodować przeciążenie systemu transakcyjnego (zwłaszcza w przypadku jej równoległego wykonywania dla wielu użytkowników). Zastosowanie gotowych agregatów powoduje, że uszczegółowienie wyszukiwania sprowadza się w zasadzie tylko do odczytania zawartości podkostki.

W konkretnej implementacji można tworzyć kostki OLAP, które nie będą przechowywały informacji bazowych, tylko np. ograniczone do określonego poziomu szczegółowości. W przypadku, gdy użytkownik zażąda informacji, które nie są zgromadzone w kostce, motor OLAP pobierze dane źródłowe np. z bazy relacyjnej. Nawet w takim przypadku obciążenie bazy relacyjnej jest małe, bo wybierany jest tylko określony fragment bazy OLTP.

Jakość danych

Tak jak w przypadku hurtowni danych, przy konstrukcji kostek bardzo ważne jest zapewnienie jakości wprowadzanych informacji - sprawdzenie, czy np. nie są błędnie wpisywane nazwy miejscowości, czy adres jest zapisywany w spójnej postaci itp. Bardzo dobrym rozwiązaniem przeznaczonym do kontroli wprowadzanych danych jest mechanizm DTS zawarty Microsoft SQL Server. Pozwala on elastycznie tworzyć mechanizmy przepływu informacji z bazowego systemu OLTP poprzez komponenty (np. kontrolujące poprawność zapisu informacji metodą słownikową) aż do tabel tymczasowych, wykorzystywanych do zasilania kostek OLAP. Działanie DTS nie jest ograniczone tylko do bazy Microsoftu - może czerpać informacje z dowolnego systemu, pod warunkiem że jest w nim dostępny sterownik ODBC/OLEDB.

Niezgodność zapytań

Nie rozwiązanym problemem pozostaje sposób dostępu do danych OLAP-owych. O ile w przypadku danych relacyjnych praktycznie obowiązuje SQL, o tyle w zakresie OLAP niemal każdy producent stosuje odmienne dialekty API, własne metody przechowywania i obróbki metadanych. Microsoft opracował OLEDB for OLAP oraz język MDX. Obecnie duża część niezależnych producentów rozwiązań OLAP dostarcza sterowniki zgodne z tym standardem. Równolegle Hyperion we współpracy z Microsoftem i SAS Institute opracowali XML For Analysis, w którym kwerendy mają składnie podobną do stosowanej w XPatch czy XQuery. W świecie Javy powstał standard JOLAP, pozwalający (przynajmniej w założeniach) na ujednolicony dostęp do danych OLAP z poziomu dowolnego serwera aplikacyjnego zgodnego z J2EE.

Otwartą pozostała kwestia połączenia składni SQL oraz składni zapytań skierowanych do kostki OLAP. W wielu sytuacjach wygodnym rozwiązaniem jest bowiem umieszczenie obok prostego polecenia "Select" określonego agregatu pochodzącego z bazy OLAP. Wyrafinowane rozwiązanie opracował Oracle - jeżeli we frazie where wystąpi słowo OLAP_TABLE, wtedy dany fragment zapytania zostanie przesłany do motoru przetwarzającego dane OLAP. Równocześnie można pobrać relacyjny widok struktury OLAP w taki sposób, aby był on widziany jak normalna tabela SQL. Daje to duże możliwości operowania danymi w bazie.

W Microsoft SQL Server, od wersji 7.0, możliwe jest łączenie wyrażeń OLAP i MDX. Zastosowano w nim mechanizm otwierania dowolnego zbioru rekordów, który może być dostarczony za pośrednictwem sterownika OLEDB, który może łączyć się z serwerem OLAP.