Microsoft SQL Server 2005 to kompletna platforma zarządzania i analizy danych dostarczająca funkcje i narzędzia niezbędne do tworzenia zarówno klasycznych, jak i innowacyjnych aplikacji analitycznych. W tym dokumencie znajduje się wprowadzenie do narzędzi używanych do tworzenia aplikacji analitycznych z wyróżnieniem nowych funkcji ułatwiających tworzenie i zarządzanie kompleksowymi systemami Business Intelligence (BI).
Microsoft SQL Server 2005 to kompletna platforma zarządzania i analizy danych dostarczająca funkcje i narzędzia niezbędne do tworzenia zarówno klasycznych, jak i innowacyjnych aplikacji analitycznych. W tym dokumencie znajduje się wprowadzenie do narzędzi używanych do tworzenia aplikacji analitycznych z wyróżnieniem nowych funkcji ułatwiających tworzenie i zarządzanie kompleksowymi systemami Business Intelligence (BI).
SQL Server 2005 zawiera dwa nowe składniki: SQL Server Management Studio oraz SQL Server Business Intelligence Development Studio. Inne podstawowe elementy BI – Integration Services, usługi Analysis Services OLAP, usługi Analysis Services Data Mining oraz Reporting Services – zostały w istotny sposób zmodyfikowane i ulepszone. Relacyjna baza danych SQL Server 2005 zawiera kilka nowych, ważnych funkcji. Narzędzia Microsoft Office do tworzenia zapytań oraz rozwiązania portalowe nie są częścią SQL Server, ale aktualne wydania będą działać z SQL Server 2005. Funkcje BI narzędzi pakietu Office będą rozwijane w kolejnych wersjach Microsoft Office System.
Zestaw narzędzi SQL Server 2005 Business Intelligence zapewnia pełną integrację aplikacji BI:
- Projektowanie: Business Intelligence Development Studio to pierwsze zintegrowane środowisko programowania zaprojektowane dla programistów zajmujących się systemami Business Intelligence. Business Intelligence Development Studio opracowane na bazie programu Visual Studio 2005 stanowi bogatą, zintegrowaną, profesjonalną platformę dla programistów zajmujących się systemami analizy danych i raportowania. Debugowanie, kontrola źródeł oraz opracowywanie skryptów i kodu jest dostępne dla wszystkich składników aplikacji BI.
- Synteza: Usługi SSIS (SQL Server Integration Services) zostały napisane na nowo, tak, aby zapewnić szybką złożoną integrację, transformację i syntezowanie ogromnych ilości danych. Dzięki Business Intelligence Development Studio tworzenie i debugowanie pakietów jest znacznie ułatwione Usługi SSIS, Analysis Services oraz Reporting Services współpracują ze sobą, aby zapewnić jednolity wygląd danych pochodzących ze zróżnicowanych źródeł.
- Zapisywanie: SQL Server 2005 zaciera granice między relacyjnymi i wielowymiarowymi bazami danych. Dane można przechowywać w relacyjnej bądź w wielowymiarowej bazie danych. Można też użyć nowej funkcji Proactive Cache (bufor proaktywny), aby skorzystać z najlepszych cech obu tych rozwiązań.
- Analizy: Nowa wersja narzędzi Data Miting znacznie rozszerza ich możliwości dzięki zastosowaniu nowych, ważnych algorytmów: w tym reguł związków (Association Rules), szeregów czasowych (Time Series), drzew regresji (Regression Trees), podobieństw sekwencyjnych (Sequence Clustering), sieci neuronowych (Neural Nets) oraz Naive Bayes. Do modułów usług Analysis Services dodano także nowe możliwości analityczne: struktura kluczowych wskaźników wydajności (Key Performance Indicator framework), skrypty MDX i inne narzędzia zaawansowanej analizy danych. Infrastruktura dostarczania i zarządzania raportami w ramach usług Reporting Services umożliwia łatwą dystrybucję złożonych analiz do szerokiej grupy odbiorców.
- Dostarczanie: Usługi Reporting Services rozszerzają platformę Microsoft Business Intelligence w taki sposób, aby mogła być w pełni wykorzystana przez użytkowników biznesowych potrzebujących szybkiego dostępu do zaawansowanych analiz. Reporting Services to środowisko raportowania zarządzane na poziomie przedsiębiorstwa, osadzone i administrowane za pomocą Web Serwisów (Web Services). Raporty mogą być personalizowane i dostarczane w różnorodnych formatach z szerokim zakresem interaktywności i możliwości drukowania. Dzięki temu nawet złożone analizy mogą być dostępne dla bardzo szerokiej grupy tzw. konsumentów informacji. Nadal jednak popularnym sposobem uzyskiwania dostępu do danych w usługach Analysis Services i w relacyjnych bazach danych pozostaną narzędzia Microsoft i Partnerów służące do tworzenia raportów ad-hoc oraz analiz.
- Zarządzanie: SQL Server Management Studio integruje elementy służące do zarządzania komponentami SQL Server 2005.
Kluczowe zadanie składników SQL Server 2005 Business Intelligence to wspieranie procesu tworzenia i wykorzystania rozwiązań Business Intelligence w przedsiębiorstwach każdej wielkości oraz możliwość ich używania przez wszystkich pracowników – nie tylko przez menedżerów i analityków, ale także przez szeregowych pracowników i zewnętrznych współpracowników. Pod tym względem SQL Server 2005 jest rozwiązaniem kompletnym, zintegrowanym, łatwym w użyciu, pozwalającym publikować dane w postaci Web Serwisów (Web Services), zapewniającym znakomitą wydajność na standardowym sprzęcie i zawierającym wiele nowych funkcji, które można wykorzystać do tworzenia innowacyjnych aplikacji analitycznych.
Relacyjne hurtownie danych
Silnik relacyjnej bazy danych SQL Server 2005 zawiera funkcjonalność kluczową dla projektowania i utrzymania aplikacji obsługujących hurtownie danych. Należą do nich:
- Partycje tabel umożliwiające szybkie ładowanie danych i upraszczające utrzymanie ogromnych tabel
- Proste tworzenie serwera raportów
- Usprawnienia języka Transact-SQL obejmujące nowe typy danych i nowe funkcje analityczne
- Operacje indeksowania online
- Precyzyjne operacje tworzenia kopii zapasowych/odtwarzania
- Szybkie inicjowanie plików
Serwer raportów
Typową techniką zmniejszenia obciążenia powodowanego przez relacyjne raportowanie oparte o systemy transakcyjne jest utrzymywanie serwera raportów. Serwer raportów przechowuje opóźniony w pewnym stopniu obraz transakcyjnej bazy danych – najczęściej jest to obraz z poprzedniego dnia. Serwer raportów wykorzystywany jest do tworzenia większości raportów i wyciągów z hurtowni danych.
Microsoft SQL Server 2005 został wyposażony w dwie nowe funkcje, dzięki którym tworzenie i utrzymanie serwera raportów jest znacznie ułatwione. Serwer raportów SQL Server może mieć znacznie mniejsze niż dzienne opóźnienie. Serwer raportów jest zaprojektowany tak, aby mógł działać jako system rezerwowy do systemu transakcyjnego.
Aby utworzyć serwer raportów, należy najpierw zdublować bazę danych (database mirror) – pozwala na to nowa funkcja SQL Server 2005 zapewniająca natychmiastowe stworzenie zapasowego systemu o wysokiej dostępności. Do zdublowanej bazy danych nie można bezpośrednio wysyłać zapytań i w tym obszarze ma zastosowanie druga nowa funkcja - utworzenie widoku na zdublowanej bazie danych (Create a database view on the mirror). Widok na bazę danych to jest jej kopia, ale tylko do odczytu z pewnego punktu w czasie. Widok na bazę danych nie jest pełną kopią i dzięki temu zapewnia niezwykłą oszczędność miejsca. Może istnieć wiele widoków na bazę danych, ale trzeba pamiętać, że utrzymywanie widoku ma pewien wpływ na bazę danych transakcji, na której jest oparty dany widok. Tworząc widok na kopii bazy danych, można łatwo utworzyć samodzielny serwer zapasowy o wysokiej dostępności, działający również jako serwer raportowania.
Partycje tabel
Tabele z partycjami i indeksami mają dane podzielone na poziome jednostki, przez co grupy wierszy są mapowane na poszczególne partycje. Operacje wykonywane na danych, takie jak zapytania, są przeprowadzane tak, jakby cała tabela lub indeks były osobną jednostką. Partycjonowanie może:
- Poprawić możliwości zarządzania tabelą i indeksem.
- Poprawić działanie zapytań na komputerach wieloprocesorowych.
W relacyjnej hurtowni danych tabele faktów w naturalny sposób kwalifikują się do zastosowania partycjonowane, a partycjonowanie na podstawie zakresów danych jest najczęstszą strategią.
Do czynności niezbędnych dla zdefiniowania tabeli partycjonowanej należą:
- Utworzenie funkcji partycjonowania, określającej, jak można partycjonować tabelę, która używa tej funkcji.
- Utworzenie schematu partycjonowania, określającego umieszczenie partycji funkcji partycjonującej w grupach plików.
- Utworzenie tabeli lub indeksu za pomocą schematu partycjonowania.
Ten sam schemat partycjonowania może być wykorzystany w wielu tabelach.
W najczęściej stosowanym schemacie partycjonowania, tabela faktów jest partycjonowana na podstawie zakresu danych: na przykład roku, kwartału, miesiąca lub nawet dnia. W większości scenariuszy partycjonowanie ogromnej tabeli faktów według daty daje większe możliwości zarządzania danymi. Aby uzyskać poprawę funkcjonowania zapytań, tabela wymiaru czasowego powinna być partycjonowana według tego samego schematu.
- Tabela partycjonowana zachowuje się tak samo, jak tabela niepartycjonowana.
- Zapytania do tabeli są rozwiązywane poprawnie.
- Bezpośrednie wstawienia, aktualizacje i usunięcia są automatycznie realizowane we właściwych partycjach.
Korzystanie z partycji tabel do szybkiego ładowania danych
W większości projektów wdrożenia hurtowni danych istnieje konieczność ładowania coraz większych ilości danych w krótkim – kurczącym się – czasie ładowania. Typowy proces rozpoczyna się od pobrania danych z kilku systemów źródłowych, po czym następują etapy czyszczenia, transformacji, syntezowania i nadawania sensu tym danym. Aplikacja do zarządzania danymi musi się uporać z pobraniem, transformacją i załadowaniem danych w przydzielonym czasie ładowania. Biznesowi użytkownicy systemu mają zazwyczaj surowe wymagania odnośnie skracania czasu, w którym hurtownia danych jest niedostępna i nie udziela odpowiedzi na zapytania. Operacje „zapisu” aplikacji do zarządzania danymi, w której dane są wstawiane do istniejącej hurtowni danych, muszą być tak zaprojektowane, aby odbywały się szybko i w minimalnym stopniu były odczuwane przez użytkowników.
Aby znacznie skrócić czas ładowania danych, modelem odzyskiwania bazy musi być Bulk Logged bądź Simple, a tabela musi być pusta lub zawierać dane bez indeksów. Jeśli te warunki są spełnione, to jest możliwe ładowanie nierejestrowane. W SQL Server 2000, zanim pojawiły się tabele partycjonowane, warunki te były spełnione jedynie podczas początkowego ładowania danych historycznych. Niektórzy klienci, posiadający ogromne hurtownie danych, tworzyli struktury quasi-partycjonowane, budując widok UNION ALL osobnych fizycznych tabel; te tabele były zapełniane w każdym cyklu ładowania przy użyciu techniki nierejestrowanej. Takie podejście nie było w pełni satysfakcjonujące i partycjonowanie tabel w SQL Server 2005 zapewnia znacznie lepsze efekty.
W SQL Server 2005 nie można wykonywać nierejestrowanego ładowania bezpośrednio do partycji. Można jednak wykonać ładowanie do osobnej tabeli, którą będziemy nazywać pseudopartycją. Pod pewnymi warunkami można przełączyć pseudopartycję na tabelę partycjonowaną w operacji na metadanych – jest to operacja wykonywana bardzo szybko. Taka technika spełnia wymagania w zakresie:
- minimalizowania całkowitego czasu ładowania: ładowanie pseudopartycji odbywa się bez zapisywania do logu transakcyjnego oraz
- minimalizowania odczuwania wpływu tej operacji przez użytkowników i zapewnienia integralności hurtowni danych: pseudopartycje można ładować w czasie, gdy użytkownicy wysyłają zapytania do hurtowni danych. Aplikacja zarządzająca danymi może czekać, aż wszystkie tabele faktów zostaną załadowane i przygotowane, wtedy może wykonać przełączenie partycji. Operacja przełączenia partycji odbywa się bardzo szybko – w czasie krótszym niż jedna sekunda.
Dodatkowo, można utworzyć kopię zapasową pseudopartycji jako osobnej tabeli, co zwiększa możliwości zarządzania systemem.
Korzystanie z partycji tabel do szybkiego usuwania danych
W wielu hurtowniach danych stosowane jest tzw. ruchome okno (sliding window), zawierające „aktywne” dane analityczne najniższego szczebla. Przykładowo, tabela faktów może zawierać dane z trzech, pięciu bądź dziesięciu lat. Najstarsze dane są okresowo usuwane z tabeli. Podstawowa przyczyna usuwania danych to potrzeba zapewnienia lepszej obsługi zapytań i minimalizowanie kosztów ich składowania.
Dzięki partycjom SQL Server 2005, usuwanie starych danych z ogromnych partycjonowanych tabel jest znacznie uproszczone: należy utworzyć pustą pseudopartycję (opisaną powyżej), a następnie przełączyć na partycjonowaną tabelę. Partycjonowana tabela ma pustą partycję w miejscu, w którym wcześniej miała zapełnioną partycję; pseudopartycja zawiera dane w miejscu, które wcześniej było puste. Można utworzyć kopię zapasową pseudopartycji, można ją skrócić bądź usunąć – w zależności od potrzeb.
Można też ponownie zdefiniować funkcję partycjonowania tak, aby łączyła wszystkie puste partycje w jedną.
Kwerendy rekurencyjne
Dzięki nowym funkcjom SQL Server 2005 możliwe jest używanie kwerend rekurencyjnych (recursive queries).
Kwerenda rekurencyjna to kwerenda wykonywana na tabeli z tzw. self-join. Najczęściej spotykane przykłady to tabele przechowujące informacje o pracownikach i ich kierownikach oraz tabele ze spisem materiałów. Tabelę ze złączeniami wewnętrznymi ilustruje tabela Employee z bazy danych AdventureWorks.
Pobieranie, transformacja i ładowanie (ETL; Extract, Transformation, and Loading)
Usługi Integration Services (SSIS) są w SQL Server 2005 nowym elementem. Usługi DTS, będące popularną funkcją SQL Server 2000 zostały przeprojektowane, tak aby stanowiły platformę ETL na poziomie korporacyjnym. Usługi SSIS zawierają wiele funkcji i zapewniają wydajność na wysokim poziomie, niezbędną do tworzenia aplikacji ETL dla przedsiębiorstwa. Usługi SSIS są w pełni programowalne, zagnieżdżalne i rozszerzalne – dzięki tym cechom są one idealne dla platformy BI.
Usługi Analysis Services
Usługi SQL Server 2000 Analysis Services składają się z dwóch głównych, dopełniających się funkcji: On-Line Analytical Processing (OLAP) oraz Data Mining. Te dwa składniki wciąż występują w usługach Analysis Services 2005 jako kluczowe elementy aplikacji analitycznych.
Istnieją dwie główne drogi tworzenia analitycznych baz danych:
- Pełne dostosowanie: Poczynając od źródła danych, na ogół relacyjnego, definiując wymiary, kostki wielowymiarowe, kluczowe wskaźniki wydajności (KPIs), obliczenia i modele eksploracji (drążenia) danych. Ta droga jest odpowiednia dla klientów mających już hurtownię danych lub data mart. Na pierwszym ekranie kreatora modułu ta opcja jest oznaczona jako „Use existing DB/Data Warehouse” (Użyj istniejącej bazy danych/hurtowni danych).
- Szablon dostosowywany: Poczynając od szablonu, definiowanie i generowanie całej aplikacji, w tym relacyjnych baz danych, pakietów SSIS oraz baz danych usług Analysis Services OLAP. Te składniki są zaprojektowane i wygenerowane tak, aby współdziałały ze sobą jak pełna aplikacja. To podejście jest odpowiednie dla klientów instalujących pełne rozwiązania Business Intelligence na podstawie szablonu. Na pierwszym ekranie kreatora modułu ta opcja jest oznaczona jako „Design BI model without data source” (Zaprojektuj model BI bez źródła danych).
W obu podejściach w podstawowym projekcie systemu zakłada się, że istnieje już znana struktura Business Intelligence składająca się z jednego bądź z kilku systemów źródłowych zasilających wymiarową relacyjną hurtownię danych, która z kolei jest używana do zapełniania bazy danych usług Analysis Services. SQL Server 2005 posiada także wiele opcji umożliwiających odchylenia od tego podstawowego projektu przez eliminowanie lub wirtualizację różnych składników.
Tworzenie konfigurowalnej bazy danych na podstawie istniejącego źródła
Pierwsza metoda tworzenia bazy danych usług Analysis Services jest najlepiej znana użytkownikom SQL Server 2000. Poczynając od źródła bazy danych o dowolnej strukturze:
- Wymiarowej bazy danych o strukturze zbudowanej z tabel faktów i wymiarów lub
- dowolnej innej struktury bazy danych, w tym ze znormalizowanych systemów transakcyjnych;
Możliwość użycia jako źródła znormalizowanej bazy danych jest znacznym postępem w stosunku do usług Analysis Services 2000, które wymagały struktury wymiarowej, gwiazdy, płatka śniegu lub spłaszczonej. Dzięki temu łatwiej jest tworzyć aplikacje BI o niewielkim opóźnieniu aktualizacji danych.
Wiele wymagań użytkowników można zaspokoić najprościej i najtaniej przez utworzenie bazy danych usług Analysis Services bezpośrednio na transakcyjnej bazie danych, bez uprzedniego tworzenia formalnej hurtowni danych. Jeśli dane choćby w minimalnym stopniu wymagają transformacji, czyszczenia i integracji, zanim będą gotowe do użycia, należy rozważyć użycie bazy danych usług Analysis Services w celu uzupełnienia lub zastąpienia istniejącego raportowania relacyjnego. Pozwala to wykorzystać siłę i interakcyjność usług Analysis Services, a jednocześnie umożliwia lepsze zarządzanie obciążeniem systemów transakcyjnych.
Wprawdzie można utworzyć i utrzymywać bazę danych usług Analysis Services bezpośrednio na systemach transakcyjnych, ale wiele wymagań analitycznych przedsiębiorstwa najlepiej zaspokaja się, gdy najpierw utworzy się relacyjną hurtownię danych. Problemy złożonej integracji danych i zarządzania zmianami danych najlepiej rozwiązywać za pomocą klasycznej architektury hurtowni danych, w której baza danych Analysis Services działa jako silnik zapytań i analiz.
Źródła danych (Data sources) i widoki źródeł danych
Pierwszy krok w tworzeniu nowej aplikacji analitycznej to utworzenie nowego projektu usług Analysis Services w Business Intelligence Development Studio. Gdy zostanie utworzony pusty projekt, należy utworzyć źródło danych (Data Source) do podłączenia do źródłowej bazy danych, która może się znajdować w dowolnym obsługiwanym systemie zarządzania relacyjną bazą danych. W wersji Beta 2 radzi się zaczynać od relacyjnych baz danych SQL Server 2000 lub SQL Server 2005 jako źródeł danych.
Źródło danych (Data Source) przechowuje informacje niezbędne do połączenia się ze źródłem danych. Widoki źródeł danych (Data Source Views) zawierają informacje na temat istotnych podzbiorów tabel w źródłowej bazie danych. Te informacje nie są ograniczone do fizycznej struktury tabel w źródłowej bazie danych; można dodać informacje takie jak relacje, przyjazne nazwy tabel i kolumn, kolumny obliczane i nazwane zapytania.
Widoki źródeł danych mogą być udostępniane między projektami BI oraz projektami SSIS. Widoki źródeł danych są zawsze przydatne, ale szczególnie cenne są, gdy:
- Źródłowa baza danych zawiera tysiące tabel, z których jedynie względnie niewielka liczba jest przydatna w pojedynczej aplikacji BI.
- Baza danych usług Analysis Services korzysta z danych z różnych źródeł, takich jak wiele baz danych, serwery, pliki płaskie lub systemy RDBMS.
- Programista tworzący system BI nie ma uprawnień administratora systemu do źródłowej bazy danych i nie jest upoważniony do tworzenia widoków fizycznych ani do modyfikowania źródłowej bazy danych.
- Programista tworzący system BI musi pracować w trybie offline, bez połączenia ze źródłową bazą danych. Zadania projektowania i programowania mają miejsce w oparciu o widok źródła danych, który jest odłączony od źródłowej bazy danych.
Inwestycja utworzenia dobrych nazw i relacji w widoku źródła danych zwraca się w postaci prostoty tworzenia aplikacji analitycznej.
Tworzenie wymiarów i kostek wielowymiarowych
Po utworzeniu widoku źródła danych można utworzyć kostkę wilowymiarową, klikając prawym przyciskiem myszy ikonę „Cubes” w okienku Solution Explorer i wybierając polecenie „New cube”. Pojawi się opcja włączenia wykrywania i podpowiadania IntelliCube. Jeśli użytkownik postanowi korzystać z opcji IntelliCube, to musi zdecydować, czy utworzyć kostkę zoptymalizowaną na potrzeby tabel przestawnych, czy raportów. Technologia IntelliCube bada bazę danych oraz relacje kardynalności danych w widoku źródła danych oraz inteligentnie charakteryzuje tabele jako tabele faktów, tabele wymiarów bądź tabele pomostowe wymiar-fakt, które są przekształcane na relacje wiele do wielu. W wersji Beta 2 różnica spowodowana wyborem optymalizacji kostek i wymiarów na potrzeby tabel przestawnych bądź raportowania jest niewielka. Jedyna różnica sprowadza się do tego, czy technologia IntelliCube próbuje tworzyć hierarchiczne relację między atrybutami w wymiarze.
Tworzenie i wdrażanie
Dotychczas opisane kroki pozwalały po prostu utworzyć definicje wymiarów i kostek wielowymiarowych oraz struktury w postaci plików XML w środowisku programistycznym. Business Intelligence Development Studio oraz Configuration Manager pozwalają zarządzać procesem tworzenia i wdrażania projektu na docelowym serwerze. Domyślnie, deweloperski serwer docelowy to lokalny serwer użytkownika. Można utworzyć alternatywne konfiguracje na potrzeby wdrażania w innych środowiskach. Kluczowe właściwości projektu, takie jak nazwa docelowego serwera oraz ciągi tekstowe definiujące połączenia do źródeł danych mogą się zmieniać w różnych konfiguracjach.
Aby obejrzeć i przetestować kostki i wymiary podczas cyklu projektowego, należy utworzyć i wdrożyć projekt na przeznaczonym do tego docelowym serwerze, wybierając polecenie Deploy z głównego menu programu Business Intelligence Development Studio. Można też nacisnąć klawisz F5 lub wybrać polecenie Debug. Start z głównego menu Business Intelligence Development Studio. Zostanie uruchomione jedno z kilku narzędzi debugowania i przeglądania w zależności od tego, co robił użytkownik w momencie wybrania polecenia Deploy. W zależności od tego kontekstu proces wdrażania (Deploy) uruchomi przeglądarkę kostek, debuger skryptów MDX lub przeglądarkę KPI.
Po zdefiniowaniu wymiarów, miar i kostek użytkownik może chcieć obejrzeć system prototypowy. Należy przeliczyć testową bazę danych ze względnie małą ilością danych i sprawdzić, czy dane i struktury zachowują się zgodnie z oczekiwaniami.
Jako część prototypu użytkownik może chcieć zaprojektować kilka z bardziej złożonych komponentów bazy danych Analysis Services, kluczowe wskaźniki wydajności (KPIs), akcje i obliczenia. Jeśli baza danych będzie używana przez inne społeczności użytkowników, które są zainteresowane innymi widokami danych, warto wykorzystać Perspectives. Jeśli planowane jest wdrażanie bazy danych w skali międzynarodowej dla użytkowników mówiących różnymi językami, można przedstawić zlokalizowane nazwy obiektów za pomocą funkcji Translations (tłumaczenia). I wreszcie prototyp powinien ocenić alternatywne fizyczne konfiguracje, takie jak Partitions (partycje) i różne opcje Proactive Caching (buforowanie proaktywne).
Gdy zostanie utworzona baza danych Analysis Service, obiekty bazy danych są wdrażane do ostatecznego testowania, przemieszczania lub na serwerze produkcyjnym. Efekt końcowy projektu, powstały podczas tworzenia, może być wykorzystany jako wejście dla narzędzia wdrażania usług Analysis Services. To narzędzie pomaga wdrażać i przetwarzać bazę danych.
Tworzenie konfigurowalnej bazy danych na podstawie szablonu
Alternatywna metoda tworzenia w wersji 2005 aplikacji analitycznej to wybranie opcji „Design BI model without data source” (Zaprojektuj model BI bez źródła danych) na drugim ekranie kreatora Cube Wizard. Ta ścieżka kreatora jest analogiczna do projektowania w SQL Server 2000 Accelerator for Business Intelligence. W tej metodzie projektowania z szablonu powstaje kompletna konfigurowalna aplikacja: bogate struktury wymiarowe i funkcje analityczne zawierające opcjonalnie relacyjną hurtownię danych i pakiety SSIS. Szablony mogą być dostarczane przez firmę Microsoft, integratorów, bądź niezależnych producentów oprogramowania.
Można zaprojektować identyczne bazy danych Analysis Services, wybierając dowolną ze ścieżek kreatorów – tworzenia na podstawie źródłowej bazy danych lub tworzenia na podstawie szablonu. W pierwszej opcji zakłada się, że użytkownik utworzy w pełni konfigurowalny system. Nazwy obiektów i struktury są całkowicie konfigurowalne, a początkowy projekt jest oparty na nazwach i strukturach ze źródłowej bazy danych. Opcja tworzenia na podstawie szablonu również pozwala uzyskać konfigurowalną bazę danych, ale początkowy projekt jest oparty na szablonie, którego schemat został opracowany przez ekspertów.
Wielu użytkowników będzie łączyć oba te podejścia. Częsty scenariusz będzie polegać na tworzeniu większości bazy danych Analysis Services na podstawie istniejącego źródła, ale wymiar czasu będzie generowany na podstawie szablonu.
Unified Dimentional Model
Program Analysis Services 2005 zaciera granice między relacyjnymi bazami danych i wielowymiarowymi bazami danych OLAP. Bazy danych OLAP zawsze miały ogromne zalety z punktu widzenia aplikacji analitycznych:
- znakomitą wydajność zapytań,
- bogactwo możliwości analitycznych oraz
- prostotę użycia przez analityka biznesowego.
Do niedawna, zalety te były okupione pewnym kosztem. W bazach danych OLAP, w tym w bazie danych usług Analysis Services 2000 trudno było zapewnić:
- obsługę złożonych schematów, w tym relacji wiele do wielu,
- szczegółowe raportowanie na szerokim zestawie atrybutów oraz
- niewielkie opóźnienie danych.
Łącząc najlepsze cechy tradycyjnych rozwiązań analizy OLAP i raportowania relacyjnego, usługi Analysis Services 2005 zapewniają jednolity, zunifikowany model wymiarowy (Unified Dimentional Model) zaspokajający oba zestawy potrzeb. Zestaw kostek i wymiarów zdefiniowany w SQL Server 2005 określa się jako Unified Dimensional Model (UDM). Zalety i elastyczność modelu UDM owocują zmianami w procesie projektowania. W przeszłości architekt BI wybierał podejście relacyjne lub OLAP, uwzględniając korzyści i koszty alternatywnych infrastruktur. Teraz architekt projektuje model UDM, a następnie określa, w którym punkcie między tymi tradycyjnymi skrajnościami umieścić projekt logiczny i fizyczną konfigurację systemu usług Analysis Services.
Wymiary oparte na atrybutach
W Analysis Services 2005, struktura kostki tworzona jest wokół atrybutów wymiarowych, a nie wokół hierarchii wymiarowych. W Analysis Services 2000 projekty wymiarowe były zdominowane przez hierarchie takie jak {Rok, Miesiąc, Dzień} bądź {Kraj, Region, Miasto}. Te hierarchie wymagały silnych relacji między danymi poziomami. Atrybuty, które ujawniały się jako właściwości elementów lub wymiary wirtualne, były znacznikami drugiej kategorii. Wprawdzie było możliwe przekształcenie atrybutów na fizyczne wymiary, ale problemy z wydajnością powodowały, że ta technika nie była szeroko stosowana. Użytkownicy przyzwyczajeni do struktur relacyjnych byli skonsternowani silnym skupieniem się na hierarchiach w bazach OLAP.
Struktura usług Analysis Services 2005 jest bliższa strukturze wymiarów relacyjnych. Wymiar zawiera wiele atrybutów, a każdy z nich może być użyty w kwerendach dzielących (ang. slicing queries) i filtrujących i każdy z nich można łączyć w hierarchie niezależnie od relacji między danymi.
Użytkownicy posiadający doświadczenie w zakresie technologii OLAP rozumieją znaczenie silnych hierarchii, w których Miasta w jasny sposób składają się na Regiony, a te na Kraje. Te naturalne hierarchie wciąż istnieją i powinny być definiowane tam, gdzie jest to uzasadnione: ich użycie zwiększa wydajność kwerend.
Jako przykład rozważmy wymiar Klient. Relacyjna tabela źródłowa ma osiem kolumn:
- CustomerKey (klucz klienta)
- CustomerName (nazwa klienta)
- Age (wiek)
- Gender (płeć)
- Email
- City (miasto)
- Region
- Country (kraj)
Odpowiedni wymiar usług Analysis Services powinien mieć siedem atrybutów:
- Customer (integer key – klucz o wartości całkowitej , CustomerName typu danych name)
- Age, Gender, Email, City, Region, Country
Istnieje naturalna hierarchia danych {Country, Region, City, Customer}. Na potrzeby nawigacji projektant aplikacji może utworzyć hierarchię {Age, Gender}. Użytkownicy biznesowi nie będą widzieć różnicy w zachowaniu obu hierarchii, ale naturalna hierarchia korzysta ze struktury indeksów – niewidocznej dla użytkownika – dla której relacje hierarchiczne są zrozumiałe.
Najważniejsze zalety nowej struktury wymiarowej to:
- Nie ma potrzeby ładowania wymiarów do pamięci. W efekcie wymiary mogą być bardzo duże (w wersji Beta 2 przeprowadzono testy na setkach milionów składowych).
- Hierarchie atrybutów mogą być dodawane i usuwane bez ponownego przetwarzania wymiaru. Struktura indeksowa hierarchii atrybutu jest obliczana w tle, podczas gdy moduł pozostaje dostępny dla zapytań.
- Zostały wyeliminowane zdublowane informacje wymiarowe, przez co wymiary są mniejsze.
- Wydajność przetwarzania wymiarów poprawiła się, gdyż silnik wykorzystuje możliwości przetwarzania równoległego.
Grupy miar i perspektywy
W usługach Analysis Services 2005 wprowadzono grupy miar (ang. measure group) i perspektywy (ang. perspective) w celu uproszczenia projektowania i wdrażania analitycznych baz danych. W usługach Analysis Services 2000 użytkownicy byli zachęcani do tworzenia wielu kostek fizycznych. Każda kostka odpowiadała konkretnej wymiarowości i na ogół konkretnej relacyjnej tabeli faktów. Kostki wirtualne łączyły wiele tabel faktów w sposób niewidoczny dla użytkownika biznesowego, ale ich definiowanie przez programistę było niepotrzebnie skomplikowane.
W wersji 2005 najbardziej typowy scenariusz będzie zawierać pojedynczą kostkę fizyczną zawierającą jedną grupę miar lub kilka takich grup. Dane faktów w grupie miar mają konkretną ziarnistość zdefiniowaną przez przecięcie hierarchii wymiarów. Zapytania są automatycznie odpowiednio kierowane do różnych grup miar. Na poziomie fizycznym partycje – analogiczne do partycji usług Analysis Services 2000 – są zdefiniowane w oparciu o grupy miar.
Rozbudowana aplikacja może przedstawiać użytkownikowi dużą liczbę wymiarów, grup miar i miar i nawigowanie w takiej aplikacji może być trudne. Perspektywa, zdefiniowana jako Perspectives w edytorze Cube Editor, tworzy podzbiór „widoków” kostki. Aby zapewnić pewien stopień personalizacji, rola zabezpieczeń może być związana ze zbiorem perspektyw, mających zastosowanie do tej roli.
Należy się spodziewać, że większość baz danych usług Analysis Services 2005 będzie zawierać jedną kostkę z wieloma grupami miar oraz wieloma perspektywami.
Inne istotne usprawnienia struktury faktów w kostce i wydajności zapytań obejmują:
- Miary mogą być nie określane (nullable); w SQL SERVER 2000 miary null były traktowane jako zero.
- Wydajność zapytań dla miar Distinct Count (liczba różnych) została poprawiona o kilka rzędów wielkości dla odpowiednio partycjonowanych modułów.
- Został zapewniony dostęp do alternatywnych systemów zarządzania bazami danych dzięki rozszerzalnej infrastrukturze kasetowej (ang. cartridge infrastructure). Kaseta dla systemu RDBMS określa sposób optymalizacji poleceń SQL na potrzeby relacyjnych kwerend i zapisów. Kasety dla dodatkowych systemów relacyjnych mogą być dodawane w prosty sposób; kaseta jest implementowana jako plik XSL.
Obliczenia i analizy
Jednym z najważniejszych argumentów za używaniem serwera analitycznego, takiego jak usługi Analysis Services, jest możliwość centralnego definiowania złożonych obliczeń.
Jednym z takich pojęć była miara semiaddytywna. Najczęściej spotykane miary, takie jak [Sales] (sprzedaż), sumują się bez problemów we wszystkich wymiarach: [Total Sales] (sprzedaż łączna) za cały czas jest sprzedażą wszystkich produktów do wszystkich klientów przez cały czas. Z kolei miara semiaddytywna może się sumować w niektórych wymiarach, ale w innych nie. Najczęstszy scenariusz to saldo, takie na przykład jak liczba elementów w magazynie. Łączne saldo z wczoraj i z dzisiaj nie jest oczywiście sumą salda z wczoraj i salda z dzisiaj. Prawdopodobnie jest to saldo końcowe, ale w niektórych scenariuszach będzie to saldo początkowe. W usługach Analysis Services 2000 trzeba było zdefiniować skomplikowane obliczenia MDX, aby zapewnić poprawną miarę. W usługach Analysis Services 2005 salda końcowe i początkowe to naturalne typy agregacji.
Miary Distinct count zostały ulepszone w wersji 2005. Miara „liczba różnych” może być teraz definiowana na danych w postaci ciągów i można definiować kwerendy, które będą wyliczać tę miarę na dowolnym zbiorze. Usługi Analysis Services 2000 wykonywały obliczenia miary „liczba różnych” jedynie na predefiniowanej strukturze hierarchicznej.
Kreator „Time Intelligence” utworzy wymiar obliczeń czasowych zawierający obliczenia dla tego okresu w stosunku do poprzedniego okresu, obliczenia średnich ruchomych i inne typowe konstrukcje obliczeniowe związane z czasem.
Skrypty MDX
Wyrażenia wielowymiarowe (MDX, MultiDimensional Expressions) to język używany najczęściej do definiowania obliczeń i reguł zabezpieczeń usług Analysis Services 2000. W usługach Analysis Services 2005 zdefiniowano nowy model obliczeń za pomocą skryptów MDX, w których stosuje się uproszczoną składnię i prostsze konstrukcje.
Język MDX jest również językiem zapytań w systemach Analysis Services. Narzędzia zapytań, takie jak Tabele przestawne programu Excel, generują zapytania MDX na podstawie operacji przeciągania i upuszczania wykonywanych przez użytkownika. Takie użycie języka MDX nie jest związane ze skryptami MDX; skrypty MDX są używane do obiektów definiowanych przez serwer, takich jak obliczanie składowe (ang. calculated members) i obliczenia w komórkach, a nie w zapytaniach użytkownika.
Gdy zostanie zdefiniowana kostka usług Analysis Services 2005, to składa się ona jedynie ze struktury, bez danych. Skrypt MDX Script jest częścią struktury kostki. Jedno domyślne polecenie skryptu MDX jest zawsze zdefiniowane – obliczenie domyślnych agregacji. Domyślne polecenie skryptu MDX Script składa się z jednej instrukcji:
Calculate;
Po całkowitym przetworzeniu kostki, ale przed zastosowaniem domyślnego skryptu MDX, kostka zawiera dane poziomu liścia, ale żadnych agregacji. Gdy zostanie zastosowany zawierający pojedynczą instrukcję domyślny skrypt MDX, agregacje zostaną obliczone i zapisane. Instrukcja skryptu MDX zawiera następujące polecenia, rozdzielone średnikami:
- Instrukcje zasięgu ograniczające zasięg instrukcji
- Formuły i przypisania wartości
- Definicje składowych obliczanych
- Definicje zbiorów nazwanych
W interfejsie użytkownika projektowania modułu Business Intelligence Development Studio skrypty MDX – w tym składowe obliczane i zbiory nazwane – są konstruowane w widoku Calculations (obliczenia). Skrypty MDX można wyświetlać w domyślnym widoku Calculations Form (formularz obliczeń), który oferuje wskazówki dotyczące składni, lub w widoku Calculations Script (skrypt obliczeń), w którym skrypty MDX są wyświetlane w postaci zbioru poleceń zakończonych średnikami. Można się przełączać między tymi widokami, ale w widoku formularza, aby było możliwe wyświetlenie skryptu, konieczna jest poprawność składniowa całego skryptu.
Istnieje kilka kluczowych cech skryptów MDX:
Procedury składowane
W usługach Analysis Services 2005 wprowadzono procedury składowane w celu rozszerzenia możliwości zapewnianych przez funkcje definiowane przez użytkownika (UDF, User Defined Functions). Procedura składowana może być napisana w dowolnym języku programowania, takim jak C++, Visual Basic czy C. Procedury składowane upraszczają opracowywanie i implementację bazy danych dzięki umożliwieniu natychmiastowego opracowania wspólnego kodu, zapisania go w pojedynczej lokalizacji i wielokrotne używanie w innych procedurach przechowywanych, obliczeniach i zapytaniach użytkownika.
Istnieją dwa typy procedur składowanych:
- Procedury składowane w postaci funkcji MDX są jak inne funkcje MDX i stanowią mechanizm prostego rozszerzania języka MDX.
- Niestandardowe procedury składowane służą do wykonywania zadań specyficznych dla implementacji, takich przetwarzanie modułu lub aktualizacja komórek we fragmencie modułu.
Procedura składowana może być użyta do wykonywania dowolnych zadań, które może wykonać aplikacja kliencka.
Kluczowe wskaźniki wydajności (KPIs)
W usługach Analysis Services 2005 wprowadzono infrastrukturę kluczowych wskaźników wydajności (KPI, Key Performance Indicator) na potrzeby definiowania tych obliczeń, wykonywanych po stronie serwera. Wskaźniki KPI będą wyświetlane w raportach, na portalach i pulpitach zarządczych za pośrednictwem interfejsów API dostępu do danych oraz narzędzi firmy Microsoft oraz innych firm. W wersji Beta 2 nie ma żadnych narzędzi klienckich służących do wyświetlania wskaźników KPI.
W Microsoft SQL Server Analysis Services 2005 pojęcie KPI jest precyzyjnie zdefiniowane w czterech krokach:
- Wartość, która ma być zmierzona: miara fizyczna, taka jak sprzedaż, miara obliczana, taka jak zysk lub miara zdefiniowana wewnątrz wskaźnika KPI,
- Wartość docelowa: wartość (lub wyrażenie MDX dające w wyniku wartość) definiująca cel miary,
- Stan: wyrażenie MDX dające w wyniku aktualny stan wartości w postaci wartości znormalizowanej z przedziału od -1 (bardzo źle) do +1 (bardzo dobrze),
- Trend: wyrażenie dające w wyniku aktualny trend wartości. Czy wartość poprawia się czy pogarsza w stosunku do celu?
Rozwiązania Business Intelligence czasu rzeczywistego
Aplikacje hurtowni danych i Business Intelligence tradycyjnie korzystały z „przestarzałych” lub mocno opóźnionych danych – z danych odświeżanych raz na miesiąc, raz na tydzień lub codziennie. Tradycjonaliści będą zakładać, że rozwiązanie BI czasu rzeczywistego to wewnętrzna sprzeczność – decyzje strategiczne nie mogą wymagać danych bardziej aktualnych, niż w najlepszym wypadku odświeżane raz na dzień. Rozwiązania Business Intelligence powinny być jednak obecne w całym przedsiębiorstwie, a nie wdrożone jedynie na potrzeby wąskiego grona osób wyłącznie dla umożliwienia im podejmowania strategicznych i taktycznych decyzji. Operacyjne rozwiązania Business Intelligence wymagają danych o niewielkim opóźnieniu.
Usługi Analysis Services 2005 oferują nowe możliwości przetwarzania na potrzeby operacyjnych rozwiązań Business Intelligence. Moduły w usługach Analysis Services 2000 – niezależnie od ich trybu przechowywania lub strategii partycjonowania – były przetwarzane w modelu „Pull”. Uruchamiany był proces Analysis Services poszukujący nowych informacji w źródłowej bazie danych, przetwarzający i ewentualnie zapisujący dane szczegółowe oraz obliczane i zapisane agregacje.
Ten model jest wciąż obsługiwany w usługach Analysis Services 2005, ale dołączone zostały dodatkowe opcje, szczególnie przydatne do zastosowań Business Intelligence korzystających z danych o niskim opóźnieniu:
- Push data from the SSIS pipeline (Wypchnij dane ze strumienia SSIS) lub z niestandardowej aplikacji. Dane mogą przepływać bezpośrednio do partycji usług Analysis Services ze strumienia pakietu SSIS bez pośredniego przechowywania. Ten scenariusz może być wykorzystany do zredukowania opóźnienia (i kosztów składowania) danych analitycznych.
- Manage the cube as a proactive cache, (Zarządzaj kostką jako buforem proaktywnym) bez działań administracyjnych, aby utrzymywać bufor o określonym opóźnieniu i określonej charakterystyce wydajności.
Charakterystyka wydajnościowa zapytań w Analysis Services przy wykorzystaniu wielowymiarowego przechowywania danych jest lepsza niż przy przechowywaniu relacyjnym. Za[pytania działają najlepiej w modelu przechowywania wielowymiarowego (MOLAP). Negatywny aspekt to opóźnienie: przechowywanie wielowymiarowe jest rozwiązaniem niższego poziomu w stosunku do relacyjnego źródła. Trik w technologii proaktywnego buforowania polega na maksymalizowaniu wydajności kwerend przy minimalizowaniu opóźnienia danych i kosztów administracyjnych.
Funkcja buforowania proaktywnego upraszcza proces zarządzania dezaktualizacją danych. Jeśli w źródłowej bazie danych ma miejsce transakcja, taka jak składowa nowego wymiaru lub nowa transakcja faktu, wówczas istniejący bufor dezaktualizuje się. Proaktywne buforowanie oferuje regulowany mechanizm określania, jak często bufor wielowymiarowy jest odbudowywany – w celu określania, w jaki sposób udzielać odpowiedzi na zapytania podczas odbudowy bufora – i w celu uruchamiania procesu bez udziału administratora.
Buforowanie proaktywne pozwala skonfigurować moduł w taki sposób, aby automatycznie był odświeżany bufor wielowymiarowy, gdy będzie miała miejsce transakcja. Wprawdzie usługi Analysis Services przetwarzają dane niezwykle szybko, to jednak i tak przetwarzanie zajmuje pewien czas. Opcjonalnie konfiguracja bufora proaktywnego może zapewniać automatyczne przekierowywanie kwerend do magazynu relacyjnego, jeśli ponowne przetwarzanie bufora wielowymiarowego nie zostało zakończone.
Przy projektowaniu konfiguracji bufora proaktywnego należy pamiętać, że ten bufor jest ustawiany dla każdej wielowymiarowej partycji. Jeśli partycja zawiera dane dla krótkiego okresu, takiego jak godzina, wówczas proces odświeżania bufora może trwać niezwykle krótko. Najbardziej złożone konfiguracje bufora zależą od powiadomień z bazy danych do usług Analysis Services, że miała miejsce aktualizacja. Relacyjna baza danych Microsoft SQL Server obsługuje takie powiadomienia. W wypadku baz danych, które nie wysyłają powiadomień, usługi Analysis Services można skonfigurować w taki sposób, aby uzyskiwały informacje o zmianach na podstawie zdefiniowanej kwerendy.
Parametry bufora proaktywnego to:
- Quiet period (okres ciszy): Czas, przez który w źródle relacyjnym nie może być transakcji, zanim serwer rozpocznie przetwarzanie nowych informacji. Parametr jest z reguły ustawiany na wartość mniejszą niż dziesięć sekund. Czekanie na okres ciszy ma zapobiegać powtarzalnemu odrzucaniu i odbudowywaniu bufora w sytuacji, gdy ma miejsce wiele aktualizacji źródła relacyjnego następujących jedna po drugiej.
- Latency (opóźnienie): Jak długo użytkownicy mogą uzyskiwać dostęp do przestarzałych danych. Jeśli opóźnienie jest ustawione na wartość zero, kwerendy użytkowników są przekierowywane do źródła relacyjnego, gdy tylko zostanie odebrane powiadomienie. Jeśli opóźnienie jest ustawione na wartość 600 sekund, wówczas użytkownicy uzyskują dostęp do danych, które nie są starsze niż sprzed dziesięciu minut. Ustawienie -1 oznacza, że użytkownicy będą uzyskiwać dostęp do przestarzałych danych do czasu zakończenia przetwarzania bufora proaktywnego.
- Silence override interval (okres zastępujący okres ciszy): Maksymalny czas między odebraniem powiadomienia o zmianie a rozpoczęciem przetwarzania buforu proaktywnego. Jeśli źródłowa baza danych jest aktualizowana bez przerwy, ten parametr zastąpi ustawienie „Quiet period”.
- Force rebuild interval (okres wymuszenia odbudowy): Ten parametr jest używany w celu zapewnienia prostej funkcji bufora proaktywnego w systemach, w których system źródłowej bazy danych nie jest w stanie zapewnić powiadomień o zmianie. Jeśli dane źródłowe znajdują się w systemie RDBMS SQL Server, ten parametr powinien mieć wartość zero.
Data Mining
Technologia Microsoft SQL Server 2005 Data Mining to technologia Business Intelligence umożliwiająca tworzenie złożonych modeli analitycznych oraz integrowanie tych modeli z działaniami biznesowymi. Modele wydobywania danych pozwalają uzyskać odpowiedzi na pytania takie jak:
- Jakie jest ryzyko kredytowe związane z tym klientem?
- Jaki jest ogólny profil moich klientów?
- Jakie produkty ludzie są skłonni kupować razem?
- Jaka jest spodziewana sprzedaż produktu w następnym miesiącu?
Celem wielu projektów związanych z wydobywaniem danych jest zbudowanie aplikacji analitycznej, z której codziennie będą mogli korzystać użytkownicy biznesowi, partnerzy oraz klienci, bez konieczności znajomości złożonych obliczeń, jakie leżą u podstaw aplikacji. Z osiągnięciem tego celu wiążą się dwa główne kroki: zbudowanie modelu wydobywania danych i utworzenie aplikacji. Dzięki SQL Server 2005 Data Mining wykonanie obu tych kroków jest znacznie uproszczone.
Celem firmy Microsoft leżącym u podstaw funkcji Data Mining w wersji 2005 jest utworzenie narzędzi, które:
- Są proste w użyciu
- Dostarczają pełny zestaw funkcji
- Dają się łatwo osadzać w aplikacjach produkcyjnych
- Ściśle się integrują z innymi technologiami BI SQL Server oraz
- Rozszerzają rynek dla aplikacji wydobywania danych.
Większość osób najprawdopodobniej korzystała (aktywnie bądź nie) z aplikacji Data Mining. Jeśli czytelnik kupował online książki lub muzykę oraz otrzymał rekomendację, że „innym klientom, takim jak on, podobało się” lub, że firma obsługująca karty kredytowe prosiła go o sprawdzenie podejrzanej transakcji, to używał bądź korzystał z zalet aplikacji Data Mining. Do niedawna, w opracowywaniu takich aplikacji, koncentrowano się na największych problemach w największych firmach – w takich, które stać było na zatrudnienie doświadczonych analityków oraz na poniesienie wysokich kosztów programowania, wymaganych do zbudowania aplikacji Data Mining. Podobnie jak w wypadku technologii OLAP firmy Microsoft, które pomogły we wzroście rynku OLAP, chcemy rozszerzyć stosowanie technologii Data Mining na przedsiębiorstwa i oddziały firm, które nie były w stanie opracować takich aplikacji w przeszłości.
SQL Server 2005 Data Mining wykorzystywane są do badania zestawu danych pod kątem istnienia prawidłowości i ewentualnie opracować prognozy w oparciu o te prawidłowości. Na tym polega Data Mining: eksploracja, wykrywanie prawidłowości i prognozowanie.
Usługi Reporting Services
W Microsoft SQL Server 2005 firma Microsoft rozszerzyła kilka głównych składników zintegrowanej platformy Business Intelligence. Usługi SQL Server Reporting Services rozszerzają wizję firmy Microsoft dotyczącą rozwiązań BI, ułatwiając uzyskiwanie odpowiednich informacji przez właściwe osoby – w dowolnym środowisku biznesowym.
Usługi Reporting Services są kompletną, opartą na serwerze platformą tworzenia, zarządzania i dostarczania tradycyjnych i interaktywnych raportów. Zawierają one wszystkie gotowe narzędzia do tworzenia i dystrybuowania raportów oraz zarządzania nimi. Jednocześnie modularna budowa produktu oraz wszechstronne interfejsy API umożliwiają programistom, dostawcom danych i przedsiębiorstwom integrowanie raportowania ze starszymi systemami lub aplikacjami innych firm.
Usługi Reporting Services są dostarczane z SQL Server 2005 i obejmują:
- Pełny zestaw narzędzi do tworzenia, zarządzania i przeglądania raportów
- Silnik do przechowywania i przetwarzania raportów
- Rozszerzalną architekturę oraz otwarte interfejsy do osadzania raportów oraz do integrowania rozwiązania z różnorodnymi środowiskami IT.
Podsumowanie
Microsoft SQL Server 2005 to kompletna platforma BI zapewniająca infrastrukturę oraz składniki serwerowe do tworzenia:
- dużych, złożonych hurtowni danych, do których łatwo zadawać zapytania i które są tanie w utrzymaniu;
- niewielkich systemów raportowania i analiz, które mniejsze przedsiębiorstwa lub działy wielkich przedsiębiorstw mogą łatwo zbudować i którymi mogą bez problemów zarządzać;
- systemów o niskim opóźnieniu dostarczających dane analityczne do użytkowników odpowiedzialnych za sprawy operacyjne;
- systemów analitycznych i wydobywania danych działających w układzie zamkniętym oraz
- osadzonych systemów rozszerzających zasięg rozwiązań Business Intelligence.
Znane narzędzia – relacyjna baza danych SQL Server, usługi Integration Services, Reporting Services, Analysis Services OLAP i Data Mining – zostały znacznie ulepszone. Nowe funkcje, takie jak Business Intelligence Development Studio i SQL Server Management Studio, w jeszcze większym stopniu rozszerzają platformę Microsoft BI. Każde narzędzie jest innowacyjne i zaprojektowane tak, aby pomóc użytkownikowi osiągnąć więcej przy mniejszym wysiłku na: tworzenie, wdrażanie i zarządzanie wielkimi aplikacjami Business Intelligence z wykorzystaniem mniejszych ilości sprzętu, w mniejszym zespole, a także szybciej i lepiej niż dotychczas.
Spis treści