Gdyby istniała Nagroda Nobla w dziedzinie informatyki, to murowanym kandydatem do tego wyróżnienia za "całokształt" byłby niewątpliwie Edgar F. Codd. W 1970 r. sfromułował on założenia relacyjnego modelu danych. I to właśnie on samokrytycznie zauważył później, że jego koncepcja nie nadaje się do celów analizy gospodarczej wielkiej ilości danych i sformułował kilkanaście reguł, jakie powinno spełniać oprogramowanie OLAP. Reszta jest już dziełem przemysłu software'owego.

Długie lata udoskonalano relacyjne bazy danych pod kątem ich wydajności dla systemów o dużej liczbie stosunkowo niewielkich transakcji - np. księgowość. Tymczasem operacje analityczne wymagają różnorodnych zapytań, które korzystają z wielkich ilości danych. Sam problem elastyczności zapytań udało się rozwiązać. Wiadomo że SQL nie jest narzędziem dla specjalisty ds. marketingu. Można przecież odpowiednim generatorem raportów przygotować paletę aplikacji, spełniających swe zadanie w typowej sytuacji. Dla zapytań indywidualnych użytkownik otrzymuje jedną z przyjaznych przeglądarek (browser) i sprawa rozwiązana.

Ale tylko pozornie. Bo oto po stronie serwerów przybywa danych. A który organizator technologii informacyjnej jest w stanie przewidzieć, o co zechce "zapytać" użytkownik? Wystarczy łączenie tablic (JOIN) z grupowaniem (GROUP BY), żeby proste zapytanie stało się śmiertelnym ciosem dla wydajności naszego sprzętu. Oczywiście, pod warunkiem że operujemy na dużej liczbie danych. Wprawdzie akurat to założenie jest coraz częściej bardzo dokładnie spełniane we współczesnych systemach informatyki gospodarczej.

Pomińmy przy tym wyrozumiałym milczeniem materiały reklamowe "na wysoki połysk", naszpikowane wspaniałymi konfiguracjami z pamięciami operacyjnymi o rozmiarach sporego dysku i liczbie procesorów, jaką dałoby się obsłużyć salon gier komputerowych. Tego rodzaju systemy nadają się do bicia rekordów szybkości, ale jeśli akurat implementowany projekt nie jest kolejną chałturą dla Pentagonu, lepiej zapytajmy zleceniodawcę, czy dostaniemy pieniądze na takie cacko. Cóż bowiem robić, jeśli nasze tablice idą w gigabajty i zawierają miliony rekordów?

Skąd tyle danych? Przecież teoretycznie powinno ich być mniej. I nie chodzi tu nawet o wynik mnożeń typu: liczba klientów x liczba produktów x liczba okresów czasowych. Owszem, łatwo zauważyć, że takie iloczyny lubią mieć na końcu sporo zer ale przecież żaden menedżer nie będzie zajmował się np. wszystkimi klientami naraz. Do odpowiedzi na pytanie analityczne wystarczy często niewielka ilość danych, które stanowią jednak zaledwie wierzchołek potężnej piramidy i czasami trzeba zejść aż do ostatniego kamienia u jej podstawy, aby zobaczyć, dlaczego czubek się chwieje! Problem polega więc na tym, że nigdy nie wiadomo, który to będzie "kamień" i kiedy nastąpi owo "czasami".

Cóż więc robić, gdy indeksowanie i grona tablic (cluster) nie dają zadowalających efektów? Oczywiście "zapominamy" o teorii projektowania relacyjnych baz danych i denormalizujemy nasze tablice, co kończy się redundancją. W gruncie rzeczy staramy się więc "przyciąć" tabele pod zapytania użytkownika. Łatwo przy tym zapędzić się na manowce optymalizacji, gdzie zabawa przeradza się w rąbanie wiórów, przy którym drwa lecą. I tu właśnie przychodzi nam w sukurs wielowymiarowy model danych, który można przedstawić w postaci hipersześcianu. Do jego zrozumienia przydadzą się nam teraz godziny spędzone nad rozgryzaniem kostki Rubika.

W przykładzie występują tylko trzy wymiary: produkty, klienci i czas; w rzeczywistości wymiarów może być więcej, tyle że znacznie trudniej je rozrysować na kartce papieru. Relacyjne bazy danych operują dwuwymiarowymi tablicami, w których dane występują w postaci rekordów. Wielowymiarowe bazy danych zapamiętują informacje w wielowymiarowych komórkach. Jeśli przyjmiemy, że nasza kostka pokazuje wielkość sprzedaży w tonach, to widać, że Kraków zakupił 6 t jogurtu w marcu 1996 r. Takie komórki danych układają się w warstwy, a te z kolei w przestrzenne modele. Superkostkę można teraz "obracać" i "przecinać", tak aby uzyskać dane w różnych przekrojach (perspektywach).

OLAP gwarantuje też prowadzenie szczegółowej analizy dogłębnej, przy czym trzeba pamiętać, że cała idea powstała z chęci oddzielenia danych analitycznych (zagregowanych) od masy danych operacyjnych. Wdrażanie takich rozwiązań w przedsiębiorstwie powinno też uwzględniać konieczność koegzystencji różnych modeli danych. I tak identyfikatory płaskich (liniowych) zbiorów danych muszą być w razie potrzeby (ładowania bazy danych) zamienione w wielowymiarowe adresy. Z kolei podczas modyfikacji hiperkostki istnieje potrzeba dostępu do wielu różnych komórek - w relacyjnej bazie danych często wystarczy proste dołączenie rekordu do odpowiedniej tabeli. Wielowymiarowe modele danych nie są więc ideałem na każdą sytuację. Technologia ta może wszakże być cennym uzupełnieniem dla dominujących rozwiązań relacyjnych.