SQL Server OLAP Service

SQL Server OLAP Service to wcześniejsza nazwa komponentu analitycznego, dziś znanego jako Analysis Services.

SQL Server OLAP Service jako poprzednia nazwa Analysis Services

SQL Server OLAP Service była historyczną nazwą komponentu analitycznego firmy Microsoft przeznaczonego do wielowymiarowej analizy danych. Technologia ta była związana z SQL Server 7.0, a w SQL Server 2000 otrzymała nazwę SQL Server Analysis Services. Nie chodziło o osobny system operacyjny ani o zwykłą usługę odpowiedzialną za przechowywanie tabel relacyjnych. Był to silnik analityczny, który pobierał dane z relacyjnych źródeł, porządkował je według wymiarów i udostępniał obliczenia przydatne w raportowaniu oraz analizie przekrojowej.

Podstawową strukturą w klasycznym modelu OLAP był sześcian analityczny, czyli cube. Sześcian zawierał miary, takie jak suma sprzedaży, liczba zamówień albo średnia wartość transakcji, oraz wymiary opisujące sposób filtrowania i grupowania danych. Wymiarem mógł być na przykład czas, produkt, region lub klient, przy czym każdy wymiar mógł mieć własną hierarchię. Dla czasu typowa hierarchia obejmowała rok, kwartał, miesiąc i dzień. Dzięki temu użytkownik mógł przechodzić od danych zagregowanych do bardziej szczegółowych poziomów analizy.

Model wielowymiarowy, kostki i hierarchie danych

OLAP Services wykonywał agregacje przygotowane na podstawie definicji kostki. Agregacja jest wstępnie obliczoną wartością, na przykład sumą sprzedaży dla konkretnego miesiąca i regionu, dzięki czemu zapytanie nie musi za każdym razem przeliczać wszystkich rekordów źródłowych. Administrator lub projektant modelu określał, które agregacje mają powstać i z jakich poziomów hierarchii powinny korzystać. Ich dobór wpływał na czas odpowiedzi, wykorzystanie pamięci oraz rozmiar danych pomocniczych.

W klasycznym Analysis Services, będącym następcą SQL Server OLAP Service, stosowano trzy sposoby przechowywania danych analitycznych: MOLAP, ROLAP i HOLAP. MOLAP przechowywał dane oraz agregacje w strukturach wielowymiarowych silnika analitycznego. ROLAP pozostawiał dane w relacyjnej bazie danych i kierował obliczenia do tabel oraz zapytań SQL. HOLAP łączył oba podejścia, przechowując część informacji w strukturach wielowymiarowych, a szczegółowe rekordy pozostawiając w źródle relacyjnym. Wybór trybu nie zmieniał historycznej nazwy produktu, ale wpływał na sposób odświeżania danych i obsługi zapytań.

Ważnym elementem był język MDX, czyli Multidimensional Expressions. Służył do odczytywania danych z kostek, definiowania obliczeń oraz poruszania się po hierarchiach wymiarów. Zapytanie MDX operowało na pojęciach charakterystycznych dla modelu wielowymiarowego, takich jak członkowie wymiaru, poziomy hierarchii, zestawy i miary. Jest to odmienny model pracy niż bezpośrednie odpytywanie tabel relacyjnych przy użyciu T-SQL, dlatego sama znajomość zapytań SQL nie oznacza automatycznie znajomości MDX.

Przepływ danych od SQL Server do warstwy analitycznej

Typowy przepływ rozpoczynał się od relacyjnej bazy danych, hurtowni danych albo innego obsługiwanego źródła. Projektant tworzył połączenie ze źródłem, wskazywał tabele lub widoki, a następnie definiował relacje pomiędzy faktami i wymiarami. Tabela faktów zawierała zdarzenia mierzalne, na przykład pozycje sprzedaży, natomiast tabele wymiarów dostarczały opisów używanych do filtrowania i grupowania. Na tej podstawie tworzono źródło danych, widok źródła danych, wymiary oraz kostki.

Po zdefiniowaniu modelu następował proces przetwarzania. Podczas processingu silnik odczytywał dane ze źródła, budował indeksy, wyliczał agregacje i zapisywał wynik w strukturach używanych przez zapytania analityczne. Jeśli dane źródłowe zmieniły się, kostka nie zawsze odzwierciedlała te zmiany natychmiast. Konieczne było ponowne przetworzenie odpowiednich wymiarów, partycji albo całej kostki, zależnie od zastosowanego modelu oraz zakresu zmian. Błędna konfiguracja harmonogramu przetwarzania mogła powodować rozbieżność między raportem a aktualnym stanem tabel źródłowych.

W praktycznej diagnostyce należało rozdzielić trzy poziomy problemu: dostęp do źródła, poprawność przetwarzania oraz wykonanie zapytania. Brak połączenia z relacyjną bazą mógł zatrzymać import danych. Błąd relacji lub niezgodność kluczy mogły spowodować niepełne wymiary albo nieprawidłowe agregacje. Z kolei niepoprawne zapytanie MDX, brak uprawnień do kostki lub niedostępna instancja Analysis Services mogły uniemożliwić odczyt danych mimo poprawnie zakończonego processingu.

Rozpoznawanie pozostałości po starej nazwie w środowisku SQL Server

Określenie „SQL Server OLAP Service” może pojawiać się w dawnych instrukcjach, nazwach dokumentów, skryptach instalacyjnych lub opisach starszych środowisk. Przy analizie takiego materiału trzeba ustalić wersję SQL Server, ponieważ nazwa wskazuje przede wszystkim na historyczny etap rozwoju produktu. W późniejszej dokumentacji właściwym określeniem jest SQL Server Analysis Services, często skracane do SSAS. Nie należy utożsamiać tej nazwy z usługą silnika relacyjnego SQL Server Database Engine, ponieważ są to odrębne komponenty o innych zadaniach i konfiguracji.

Na komputerze używanym do pracy z takim środowiskiem warto sprawdzić, czy zainstalowano komponent Analysis Services, jaki model projektu wykorzystuje aplikacja oraz czy połączenie wskazuje właściwą instancję analityczną. Istotne są również nazwy kostek, wymiarów i miar używanych przez raporty. Sam fakt, że relacyjna baza SQL Server działa poprawnie, nie potwierdza dostępności warstwy OLAP. Raport może nadal zwracać błąd, jeśli instancja analityczna nie działa, kostka nie została przetworzona albo aplikacja odwołuje się do historycznej konfiguracji, której nie ma już w obecnym środowisku.

Przy naprawie komputera lub przygotowaniu stanowiska do pracy z narzędziami administracyjnymi należy zachować zgodność wersji klienta, sterowników i komponentów Analysis Services z używanym serwerem. Pomocne jest porównanie komunikatu błędu z konfiguracją połączenia, sprawdzenie dostępności usługi oraz zweryfikowanie, czy problem dotyczy lokalnego stanowiska, czy zdalnego serwera analitycznego. Dzięki temu można odróżnić awarię sprzętu lub systemu na komputerze użytkownika od błędu konfiguracji samego środowiska SQL Server OLAP.