Analiza - zrób sobie sam
-
- Tomasz Kopacz,
- 20.12.2004
Nowym elementem Analysis Services są tzw. KPI (kluczowe wskaźniki wydajności). Są to takie elementy (np. wyliczane na podstawie kostki), które informują o tym, czy określone procesy, które analizuje kostka, przebiegają prawidłowo. KPI mogą być na bieżąco uaktualnione - co więcej mogą sterować przebiegiem analiz (np. w DTS) i np. wymuszać uaktualnienie wszystkich danych w kostce.
W Yukon rozbudowany został mechanizm buforujący. Tak naprawdę nie ma już tak dużej różnicy w wydajności pomiędzy kostkami MOLAP (gdzie wszystkie dane są zgromadzone w serwerze OLAP) a ROLAP (gdzie dane są pobierane z serwera relacyjnego).
Elementy wyliczone mogą być zapisywane w pamięci podręcznej.
Będą uaktualnione w razie potrzeby - ale nie będą musiały być wyliczane za każdym razem, gdy ktoś przegląda kostkę. Dzięki temu może okazać się, że nie ma potrzeby np. wyliczania wszystkich elementów w czasie zasilania kostki.
Praktycznie nowym produktem jest Data Mining - czyli narzędzia do eksploracji danych. Dla analityka dostępnych jest znacznie więcej gotowych modeli dogłębnej eksploracji danych - Naive Bayes, Association Rules Sequence Clustering i wiele innych.
Nowym elementem są mechanizmy pozwalające zapewnić odpowiednią "jakość danych" przy wypełnianiu hurtowni. Dostępne są specjalne miary odległości leksykograficznej pomiędzy elementami. Przy porównaniach można stosować "operator przybliżonego porównania". Można też grupować elementy wg tzw. słabego kryterium i potem wyznaczyć np. właściwą postać podobnie pisanych słów.
W SQL 2000 metadane dla usług Analysis Services są przechowywane w bazie Access. W wersji 2005 jest to plik XML - co otwiera zupełnie nowe możliwości zarządzania metadanymi - jak chociażby dodanie pliku tekstowego do repozytorium kodu.
Kopia i prezentacja
Zwykle w rozbudowanych instalacjach BI dane operacyjne obsługiwane przez aplikacje biznesowe są fizycznie oddzielone od bazy analitycznej - w ten sposób, by analizy nie przeszkadzały w codziennej pracy. Zwykle jest to hurtownia danych.
Jednak czasami wygodniej jest zrobić tzw. mirror bazy danych - miejsce, gdzie dane będą okresowo kopiowane - czy to do oddzielnego serwera, czy do bazy na oddzielnych partycjach dyskowych. Jednak taka operacja zazwyczaj jest wykonywana raz dziennie - czyli dane są niezbyt aktualne. W SQL 2005 można stworzyć "serwer raportujący" (tylko do odczytu), tj. taki, który będzie automatycznie synchronizował się z główną bazą danych. Równocześnie taki serwer może pełnić rolę zapasowego serwera - gotowego do pracy w razie awarii. Jest to pewne rozwinięcie koncepcji log shipping dostępnej w SQL 2000.
Można też postąpić inaczej - stworzyć tzw. widok bazy danych, tj. nie jej pełną kopię, ale specjalny serwer, na którym będą okresowo odwzorowywane zmiany nanoszone w głównej bazie. W ten sposób nie jest konieczne przechowywanie dwóch zestawów danych.
Należy również wspomnieć o stronie prezentacyjnej. Dawno już minęły czasy, gdy raport miał być po prostu "wydrukowany". Obecnie firmy oczekują z jednej strony środowiska do zadawania pytań "ad hoc", a z drugiej, chcą by raport był "żywym obiektem", z którego np. można od razu przenieść się do konkretnych danych operacyjnych.
Microsoft opracował rozwiązanie SharePoint. Jest ono dostępne albo jako "pełnoprawny" serwer, albo jako zbiór usług instalowanych na platformie Windows 2003. SharePoint pozwala na tworzenie w prosty sposób aplikacji intranetowych poprzez składanie ich z tzw. Web Parts - klocków pozwalających na prezentację i pracę z danymi. Co ciekawsze, galeria Web Parts jest bardzo duża, obejmując nie tylko narzędzia i źródła informacji z produktów Microsoftu, lecz także produkty firm trzecich - jak np. Report Viewer dla Crystal Reports czy przeglądarkę danych gromadzonych przez SAS WebHound (monitoring sieci).
Do tworzenia raportów i prezentacji danych Microsoft proponuje także Reporting Services - darmowy dodatek do SQL Server (wraz z Yukon pojawi się kolejna wersja tego pakietu). W Reporting Services raport projektowany jest w Visual Studio .Net - powstaje tutaj plik XML w języku RDL (Report Definition Language), który następnie przetwarzany jest przez odpowiedni motor i ostatecznie zostaje wygenerowany raport. Wynik może być dostępny w wielu formatach - od strony WWW, przez dynamiczne strony ASP .Net aż po statyczne dokumenty DOC czy PDF. Źródłem danych do raportu może być dosłownie wszystko - od danych relacyjnych, przez katalogi LDAP aż po kostki OLAP.
Dosyć szczegółowo można określić prawa dostępu do raportów. Można np. ograniczać dostęp od pewnego poziomu szczegółowości (np. można zobaczyć sumaryczne wydatki na pensje, ale nie każdy może zobaczyć, ile zarabia przysłowiowy Kowalski).
Do administracji wykorzystywany jest Report Manager obsługiwany za pośrednictwem przeglądarki. Reporting Services pozwalają na konfigurację mechanizmów pamięci podręcznej (by pod pewnymi warunkami raport był dostępny "od razu" na podstawie raz wygenerowanej kopii), czy też systemów automatycznej dystrybucji raportów pod pewnymi warunkami.
Należy podkreślić, że SQL Server Raporting Services są mechanizmem, który działa na serwerze. Nawet wtedy, gdy klient chce wyszukać jakąś informację w raporcie, żądanie przesyłane jest na serwer, który generuje odpowiedni wynik.
Microsoft oferuje obecnie (po przejęciu kilku niezależnych firm) również gotowe rozwiązania biznesowe - przede wszystkim system Microsoft CRM (i oddzielnie Navision), rejestrację sprzedaży, system ERP Great Plains i wiele innych. Tak naprawdę zakres zastosowań tych rozwiązań często nakłada się - a co gorsza, każde z nich dysponuje odrębnymi mechanizmami analizy i raportowania. Tak więc raport sprzedaży z Great Plains konstruuje się inaczej niż z Solomon. Jednak wydaje się, że to tylko kwestia czasu, nim Microsoft zintegruje te rozwiązania w ten sposób, by operowały na wspólnej bazie.
Microsoft Business Framework to oficjalna nazwa projektu "Green". Microsoft zamierza stworzyć uniwersalną implementację podstawowych obiektów biznesowych.
Warto tutaj dodać, że kilka lat temu IBM próbował stworzyć podobne rozwiązanie w ramach projektu San Francisco. Jednak ten projekt miał trochę inny zakres funkcjonalny - miał przykładowo zawierać komponenty pozwalające zrealizować dowolny system księgowy dostosowany do wymagań prawnych dowolnego kraju. W pewnym momencie okazało się, że takie założenia sprawiają, iż projekt stał się zbyt rozległy. Dlatego firma z Redmond zdecydowała się na mniej ambitne rozwiązanie.
MBF to raczej zestaw podstawowych komponentów - takich jak "konto rozrachunkowe", "transakcja", "przelew", które oferują podstawową funkcjonalność i są łatwo rozszerzalne - tworzenie nowych aplikacji biznesowych powinno być prostsze z użyciem tych właśnie elementów.
Dobrą analogią jest porównanie z bazami danych. Kilkanaście lat temu każdy system dysponował własną bazą danych - formatem opracowanym wewnętrznie przez programistów. Obecnie tego typu rozwiązania stały się rzadkością - bazy danych są de facto ustandaryzowanym komponentem aplikacji i nikomu już nie opłaca się samodzielnie pisać obsługi transakcji, rekordów, mechanizmów kwerend, przechowywania danych itp. Wszyscy korzystają ze standardowego API - takiego jak ADO .Net, ADO czy ODBC/JDBC.
Być może dzięki MBF okaże się, że także w przypadku innych składników aplikacji biznesowej pojawią się gotowe elementy wspomagające programistę - dodatkowo zlokalizowane w wielu językach z propozycją interfejsu użytkownika służącego do prezentowania danych. W ten sposób znacznie mniejsze firmy będą w stanie tworzyć w rozsądnym czasie nawet rozbudowane aplikacje - a co więcej głównym zadaniem przy konstrukcji systemu będzie konsulting i znajomość danego rynku, tak by informatyczna firma wdrożeniowa nie musiała skupiać się na ponownym wynajdowaniu koła, a raczej zająć się realizacją konkretnych potrzeb danego klienta.
Równocześnie takie API będzie wywierało duży wpływ na rozwój narzędzi analitycznych. Tak naprawdę to, co w tej chwili jest dostępne, bazuje na znajomości konkretnego rozwiązania (czyli znajomości sposobu zapisu informacji i/lub automatyzacja eksportu) i w dużej liczbie przypadków wymaga sięgania bezpośrednio do bazy. Dzięki MBF pojawi się wspólny sposób realizacji (a więc i zapisu) podstawowych "bloków" składowych każdej aplikacji biznesowej. W konsekwencji dwa systemy będą używać tych samych kont czy transakcji, więc tworzenie raportów w środowiskach, gdzie mamy wiele heterogenicznych rozwiązań, będzie znacznie prostsze. Ale to jest jeszcze dość odległa przyszłość, która może się ziścić prawdopodobnie dopiero po Longhornie.
