SQL Server Analysis Services Model tabelaryczny BISM

Transkrypt

1 Marco Russo Alberto Ferrari Chris Webb Microsoft SQL Server 2012 Analysis Services Model tabelaryczny BISM Przekład: Jakub Niedźwiedź, Witold Sikorski APN Promise, Warszawa 2012

2 Microsoft SQL Server 2012 Analysis Services: Model tabelaryczny BISM 2012 APN PROMISE SA Authorized Polish translation of English edition of Microsoft SQL Server Analysis Services: The BISM Tabular Model ISBN: Copyright 2012 by Marco Russo, Alberto Ferrari, Christopher Webb This translation is published and sold by permission of O Reilly Media, Inc., which owns or controls all rights to publish and sell the same. APN PROMISE SA, biuro: ul. Kryniczna 2, Warszawa tel , fax mspress@promise.pl Wszystkie prawa zastrzeżone. Żadna część niniejszej książki nie może być powielana ani rozpowszechniana w jakiejkolwiek formie i w jakikolwiek sposób (elektroniczny, mechaniczny), włącznie z fotokopiowaniem, nagrywaniem na taśmy lub przy użyciu innych systemów bez pisemnej zgody wydawcy. Książka ta przedstawia poglądy i opinie autorów. Przykłady firm, produktów, osób i wydarzeń opisane w niniejszej książce są fikcyjne i nie odnoszą się do żadnych konkretnych firm, produktów, osób i wydarzeń, chyba że zostanie jednoznacznie stwierdzone, że jest inaczej. Ewentualne podobieństwo do jakiejkolwiek rzeczywistej firmy, organizacji, produktu, nazwy domeny, adresu poczty elektronicznej, logo, osoby, miejsca lub zdarzenia jest przypadkowe i niezamierzone. Microsoft oraz znaki towarowe wymienione na stronie legal/en/us/intellectualproperty/trademarks/en-us.aspx są zastrzeżonymi znakami towarowymi grupy Microsoft. Wszystkie inne znaki towarowe są własnością ich odnośnych właścicieli. APN PROMISE SA dołożyła wszelkich starań, aby zapewnić najwyższą jakość tej publikacji. Jednakże nikomu nie udziela się rękojmi ani gwarancji. APN PROMISE SA nie jest w żadnym wypadku odpowiedzialna za jakiekolwiek szkody będące następstwem korzystania z informacji zawartych w niniejszej publikacji, nawet jeśli APN PROMISE została powiadomiona o możliwości wystąpienia szkód. ISBN: Przekład: Jakub Niedźwiedź, Witold Sikorski Redakcja: Marek Włodarz Korekta: Ewa Swędrowska Skład i łamanie: MAWart Marek Włodarz

3 Skrócony spis treści Przedmowa xv Wprowadzenie xvi 1 Wprowadzenie do modelu tabelarycznego Rozpoczęcie pracy w modelu tabelarycznym Ładowanie danych w modelu tabelarycznym Podstawy języka DAX Pojęcie kontekstu wyznaczania wartości Zapytania w modelu tabelarycznym Zaawansowane funkcje DAX Analiza czasowa w języku DAX Narzędzia xvelocity i DirectQuery Tworzenie hierarchii Modelowanie danych w modelu tabelarycznym Korzystanie z zaawansowanych relacji w modelu tabelarycznym Warstwa prezentacji w modelu tabelarycznym Model tabelaryczny i narzędzie PowerPivot Bezpieczeństwo Interfejs modelu tabelarycznego Wdrażanie modelu tabelarycznego Optymalizacja i monitorowanie Dodatek: Opis funkcji DAX Indeks O autorach iii

4

5 Spis treści Przedmowa xv Wprowadzenie xvi 1 Wprowadzenie do modelu tabelarycznego Ekosystem Microsoft BI Czym jest usługa Analysis Services i dlaczego należy jej używać? Krótka historia Analysis Services Obecny zestaw BI firmy Microsoft Samoobsługowa i korporacyjna analiza biznesowa ( BI) Architektura Analysis Services 2012: jeden produkt, dwa modele Model tabelaryczny Model wielowymiarowy Po co są dwa modele? Przyszłość Analysis Services Wybór odpowiedniego modelu dla naszego projektu Licencje Aktualizacja poprzednich wersji Analysis Services Prostota korzystania Kompatybilność z PowerPivot Cechy wydajności zapytań Cechy wydajności przetwarzania Uwarunkowania sprzętowe BI czasu rzeczywistego Narzędzia klienckie Porównanie funkcji Podsumowanie Rozpoczęcie pracy w modelu tabelarycznym Określenie środowiska deweloperskiego Komponenty środowiska deweloperskiego Licencje Proces instalacji Praca z narzędziami danych SQL Server Tworzenie nowego projektu v

6 vi Spis treści Konfiguracja nowego projektu Import z PowerPivot Import wdrożonego projektu z Analysis Services Zawartość projektu tabelarycznego Budowa prostego modelu tabelarycznego Ładowanie danych do tabeli Praca w widoku diagramu Wdrożenie Zapytania w modelu tabelarycznym w Excelu Połączenie z modelem tabelarycznym Zapytania w modelu tabelarycznym w widoku Power View Tworzenie połączenia z modelem tabelarycznym Budowa podstawowego raportu Power View Dodawanie wykresów i fragmentatorów Interakcja z raportem Praca w SQL Server Management Studio Podsumowanie Ładowanie danych w modelu tabelarycznym Dostępne źródła danych Personifikacja Poświadczenia po stronie serwera i po stronie klienta Praca z dużymi plikami Ładowanie z serwera SQL Server Ładowanie z listy tabel Ładowanie relacji Ładowanie z zapytania SQL Ładowanie z widoków Otwieranie istniejących połączeń Ładowanie z programu Access Ładowanie z usług Analysis Services Korzystanie z edytora MDX Ładowanie z tabelarycznej bazy danych Ładowanie z pliku Excela Ładowanie z pliku tekstowego Ładowanie ze schowka Ładowanie z raportu usług Reporting Services Ładowanie raportów przy użyciu strumieniowych źródeł danych

7 Spis treści vii Ładowanie ze strumieniowych źródeł danych Ładowanie z SharePoint Ładowanie z Windows Azure DataMarket Wybór właściwej metody ładowania danych Dlaczego sortowanie danych jest ważne Podsumowanie Podstawy języka DAX Obliczenia w języku DAX Składnia DAX Typy danych języka DAX Operatory DAX Wartości DAX Wyliczane kolumny i miary Wyliczane kolumny Miary Edycja miar przy użyciu edytora DAX Wybór między wyliczanymi kolumnami a miarami Obsługa błędów w wyrażeniach DAX Błędy konwersji Błędy działań arytmetycznych Puste lub brakujące wartości Przechwytywanie błędów Popularne funkcje DAX Funkcje agregacji Funkcje logiczne Funkcje informacyjne Funkcje matematyczne Funkcje tekstowe Funkcje konwersji Funkcje daty i czasu Funkcje relacyjne Stosowanie podstawowych funkcji DAX Podsumowanie Pojęcie kontekstu wyznaczania wartości Kontekst wyznaczania wartości w pojedynczej tabeli Kontekst filtru w pojedynczej tabeli

8 viii Spis treści Kontekst wiersza w pojedynczej tabeli Praca z kontekstem wyznaczania wartości dla pojedynczej tabeli Funkcja EARLIER Kontekst wyznaczania wartości w wielu tabelach Kontekst wiersza z wieloma tabelami Kontekst wiersza i łańcuch relacji Użycie kontekstu filtru z wieloma tabelami Interakcje kontekstów wiersza i filtru Modyfikowanie kontekstu filtru dla wielu tabel Końcowe rozważania dla kontekstu wyznaczania wartości Podsumowanie Zapytania w modelu tabelarycznym Narzędzia do tworzenia zapytań w modelu tabelarycznym Składnia zapytania DAX Zastosowanie funkcji CALCULATETABLE i FILTER Zastosowanie funkcji ADDCOLUMNS Zastosowanie SUMMARIZE Zastosowanie CROSSJOIN, GENERATE oraz GENERATEALL Zastosowanie funkcji ROW Zastosowanie funkcji CONTAINS Zastosowanie funkcji LOOKUPVALUE Definiowanie miar w zapytaniu Testowanie miar za pomocą zapytania Parametry w zapytaniu DAX Zastosowanie zapytania DAX w SQL Server Reporting Services Wykonywanie zapytań za pomocą języka MDX Zastosowanie lokalnych miar DAX w zapytaniach MDX Szczegółowe przeglądanie w MDX Wybór pomiędzy DAX i MDX Podsumowanie Zaawansowane funkcje DAX Funkcje CALCULATE i CALCULATETABLE Kontekst wyznaczania wartości w zapytaniach DAX Modyfikowanie kontekstu filtru za pomocą funkcji CALCULATETABLE Zastosowanie FILTER w argumentach CALCULATE i CALCULATETABLE

9 Spis treści ix Podsumowanie działania funkcji CALCULATE i CALCULATETABLE Sterowanie filtrami i wyborami Zastosowanie funkcji ALLSELECTED do sum wizualnych Filtry i filtry krzyżowe Utrzymywanie złożonych filtrów za pomocą KEEPFILTERS Funkcje sortowania Zastosowanie TOPN Stosowanie funkcji RANKX Zastosowanie funkcji RANK.EQ Funkcje statystyczne Odchylenie standardowe i wariancja z użyciem funkcji STDEV i VAR. 297 Pobieranie próbek za pomocą funkcji SAMPLE Podsumowanie Analiza czasowa w języku DAX Modelowanie tabelaryczne z tabelą dat Tworzenie tabeli Date Definiowanie relacji z tabelami Date Dublowanie tabeli Date Ustawienie metadanych dla tabeli Date Funkcje analizy czasowej w języku DAX Agregowanie i porównywanie w czasie Miary semiaddytywne Podsumowanie Narzędzia xvelocity i DirectQuery Architektura modelu tabelarycznego w Analysis Services Tryb In-Memory i xvelocity Wykonywanie zapytania w trybie In-Memory Bazy danych zorientowane wierszowo i kolumnowo Magazyn xvelocity (VertiPaq) Wykorzystanie pamięci w xvelocity (VertiPaq) Optymalizowanie wydajności przez ograniczanie wykorzystania pamięci Zrozumienie opcji przetwarzania Korzystanie z DirectQuery i trybów hybrydowych Tryb DirectQuery Analizowanie zdarzeń trybu DirectQuery przy użyciu narzędzia SQL Profiler

10 x Spis treści Ustawienia DirectQuery Wdrażanie przy użyciu DirectQuery Podsumowanie Tworzenie hierarchii Hierarchie podstawowe Czym są hierarchie? Kiedy budować hierarchie Tworzenie hierarchii Najlepsze praktyki projektowania hierarchii Hierarchie obejmujące wiele tabel Hierarchie pomiędzy elementami nadrzędnymi i podrzędnymi Czym są hierarchie pomiędzy elementami nadrzędnymi i podrzędnymi? Konfigurowanie hierarchii pomiędzy elementami nadrzędnymi i podrzędnymi Operatory jednoargumentowe Podsumowanie Modelowanie danych w modelu tabelarycznym Zrozumienie różnych technik modelowania danych Korzystanie z bazy danych OLTP Praca z modelami wymiarowymi Praca z powoli zmieniającymi się wymiarami Praca ze zdegenerowanymi wymiarami Korzystanie z migawkowych tabel faktów Obliczanie agregacji ważonych Zrozumienie zależności cyklicznych Zrozumienie możliwości kolumn obliczeniowych: analiza ABC Modelowanie przy włączonym silniku DirectQuery Korzystanie z widoków do odseparowania się od bazy danych Podsumowanie Korzystanie z zaawansowanych relacji w modelu tabelarycznym Korzystanie z relacji wielokolumnowych Grupowanie w modelu tabelarycznym Korzystanie z relacji wiele do wielu Implementowanie analizy koszykowej

11 Spis treści xi Zapytania do modeli danych z zaawansowanymi relacjami Implementowanie konwersji walut Podsumowanie Warstwa prezentacji w modelu tabelarycznym Nazwy, sortowanie i formatowanie Nadawanie nazw obiektom Ukrywanie kolumn Organizowanie miar Sortowanie danych w kolumnie Formatowanie Perspektywy Właściwości związane z Power View Default Field Set Właściwości Table Behavior Zgłębianie danych Kluczowe wskaźniki wydajności (KPI) Podsumowanie Model tabelaryczny i narzędzie PowerPivot PowerPivot for Microsoft Excel Korzystanie z listy pól PowerPivot Zrozumienie tabel połączonych PowerPivot for Microsoft SharePoint Korzystanie z odpowiedniego narzędzia do danego zadania Prototyp w PowerPivot, wdrażanie w modelu tabelarycznym Podsumowanie Bezpieczeństwo Role Tworzenie ról bazodanowych Członkostwo w wielu rolach Zabezpieczenia administracyjne Rola Server Administrator Role bazodanowe i uprawnienia administracyjne Zabezpieczenia danych Podstawowe zabezpieczenia danych Testowanie zabezpieczeń danych Zaawansowane wyrażenia filtra wierszy

12 xii Spis treści Zabezpieczenia dynamiczne Funkcje DAX związane z zabezpieczeniami dynamicznymi Implementowanie zabezpieczeń dynamicznych przy użyciu CUSTOMDATA Implementowanie zabezpieczeń dynamicznych przy użyciu USERNAME Zaawansowane scenariusze uwierzytelniania Łączenie się z usługami Analysis Services spoza domeny Kerberos i problem podwójnego przeskoku Monitorowanie zabezpieczeń Podsumowanie Interfejs modelu tabelarycznego Zrozumienie różnych interfejsów modelu tabelarycznego Zrozumienie konwersji pomiędzy modelem tabelarycznym a wielowymiarowym Korzystanie z AMO z poziomu.net Pisanie kompletnej aplikacji AMO Tworzenie widoków źródeł danych Tworzenie kostki Ładowanie tabeli SQL Server Tworzenie miary Tworzenie kolumny obliczeniowej Tworzenie relacji Wyciąganie wniosków Przeprowadzanie typowych operacji w AMO przy użyciu.net Przetwarzanie obiektu Praca z partycjami Korzystanie z AMO przy pomocy PowerShell Korzystanie z poleceń XMLA Rozszerzenia CSDL Podsumowanie Wdrażanie modelu tabelarycznego Odpowiedni rozmiar serwera Wymagania dla xvelocity Wymagania odnośnie DirectQuery Automatyzacja wdrażania na serwerze produkcyjnym Partycjonowanie tabel

13 Spis treści xiii Definiowanie strategii partycjonowania Definiowanie partycji dla tabeli w modelu tabelarycznym Zarządzanie partycjami tabeli Opcje przetwarzania Dostępne opcje przetwarzania Definiowanie strategii przetwarzania Uruchamianie przetwarzania Automatyzacja przetwarzania Korzystanie z XMLA Korzystanie z AMO Korzystanie z PowerShell Korzystanie z usług SSIS Wdrażanie DirectQuery Definiowanie strategii partycjonowania DirectQuery Implementowanie partycji dla DirectQuery i trybów hybrydowych Zabezpieczenia i personifikacja w DirectQuery Podsumowanie Optymalizacja i monitorowanie Znajdowanie procesu usług Analysis Services Zrozumienie konfiguracji pamięci Korzystanie z liczników wydajnościowych związanych z pamięcią Zrozumienie planów zapytań Zrozumienie funkcji SUMX Zbieranie informacji czasowych z narzędzia Profiler Typowe techniki optymalizacyjne Wymiana walut Stosowanie filtrów w odpowiednim miejscu Korzystanie z relacji, kiedy to możliwe Monitorowanie zapytań MDX Monitorowanie DirectQuery Zbieranie informacji przy wykorzystaniu dynamicznych widoków zarządzających Podsumowanie Dodatek Opis funkcji DAX Funkcje statystyczne Funkcje przekształcania tabeli

14 xiv Spis treści Funkcje logiczne Funkcje informacyjne Funkcje matematyczne Funkcje tekstowe Funkcje daty i czasu Funkcje filtrowania i wartości Funkcje analizy czasowej Indeks O autorach

15 Przedmowa Autorów, którymi są Marco Russo, Alberto Ferrari i Chris Webb, znam od lat ze względu na moją pracę w zespole produktu Analysis Services. Dość wcześnie znaleźli się oni wśród pierwszych osób zajmujących się modelowaniem wielowymiarowym i zaoferowali swoje opinie i sugestie jako wartościowi partnerzy, pozwalający nam na ulepszanie produktu. Gdy w SQL Server 2012 wprowadziliśmy model tabelaryczny, autorzy od początku byli na pokładzie, uczestnicząc przy wstępnych ocenach i stosując swoje znaczące umiejętności w tej nowej technologii. Marco, Alberto i Chris zapewnili konkretną pomoc w kształtowaniu produktu i kierunku jego rozwoju, za co jesteśmy im głęboko wdzięczni. Autorzy to naprawdę jedni z najlepszych i najbardziej błyskotliwych ludzi w tej dziedzinie. Indywidualnie i wspólnie napisali już wiele książek. Książka Expert Cube Development with Microsoft SQL Server 2008 Analysis Services wyróżnia się wśród innych i jest lekturą obowiązkową do zrozumienia modelowania wielowymiarowego w Analysis Services. Prócz pisania zadziwiających książek, Marco, Alberto i Chris często pojawiają się jako mówcy na kluczowych konferencjach, prowadzą kursy szkoleniowe i są konsultantami dla firm, które stosują analizę biznesową do poprawy działania organizacji. Autorzy ci to czołówka w swej dziedzinie; ich blogi są na czele list wyszukiwania niemal każdego zapytania związanego z budową aplikacji w dziedzinie analizy biznesowej. Książka, którą trzymacie w rękach, szczegółowo opisuje sposoby budowania aplikacji analizy biznesowej z wykorzystaniem języka DAX oraz modeli tabelarycznych. Jednak jej największą zaletą są porady praktyczne. Jest to książka, którą mogli napisać tylko dojrzali praktycy analizy biznesowej (BI). To mieszanka informacji, których potrzebujemy najbardziej: pełnego przewodnika po modelowaniu tabelarycznym, zrównoważonego odpowiednimi poradami prowadzącymi nas przez podejmowanie decyzji dotyczących modelowania. Mam nadzieję, że książka ta spodoba się Wam tak jak mnie. Jestem pewien, że stanie się ważnym zasobem, który warto mieć pod ręką podczas pracy nad modelami tabelarycznymi. Edward Melomed Menedżer programowy SQL Server Analysis Services xv

16 Wprowadzenie Autorzy tej książki nie byli zbyt zadowoleni, gdy po raz pierwszy usłyszeli o planach firmy Microsoft wobec Analysis Services w wersji SQL Server Analysis Services nie zyskał wielu nowych funkcji od roku 2005, choć w tym czasie stał się narzędziem OLAP o najwyższej sprzedaży. Wydawało się, że firma Microsoft straciła zainteresowanie tym produktem. Wydanie PowerPivot oraz cały szum wokół samoobsługowej wersji analizy biznesowej (Business Intelligence, BI) sugerował, że Microsoft nie jest już zinteresowany tradycyjną korporacyjną BI, a nawet że uważa profesjonalnych deweloperów za niepasujących do dzisiejszego świata, w którym końcowi użytkownicy mogą budować własne aplikacji BI bezpośrednio w Excelu. Potem firma Microsoft ogłosiła, że technologia leżąca u podstaw PowerPivot będzie włączona do Analysis Services i wydawało się, że spełniają się najgorsze obawy: najbardziej rozbudowany model wielowymiarowy został porzucony na rzecz uproszczonego podejścia opartego na tabelach. Dojrzały produkt został zastąpiony przez wersję 1.0, w której brakowało wielu użytecznych funkcji. Na szczęście, gdy autorzy zaczęli korzystać z pierwszych gotowych kopii nowej wersji, okazało się, że się mylili ukazał się znacznie lepszy, choć skomplikowany, obraz sytuacji. SQL Server 2012 jest bez wątpienia kamieniem milowym w rozwoju Analysis Services. Pomimo wszelkich plotek mówiących coś przeciwnego, można z całą stanowczością stwierdzić, że Analysis Services nie umarły ani nie umierają. Przeciwnie, podlegają metamorfozie w kierunku czegoś nowego o znacznie większych możliwościach. W miarę jak zachodzi ta zmiana, Analysis Services staje się dwugłową bestią to dwa niemal odrębne produkty (choć mające wiele wspólnego kodu). Kostki i wymiary Analysis Services, znane wielu ludziom z poprzednich wersji, stały się modelem wielowymiarowym, natomiast część Analysis Services podobna do PowerPivot staje się znana jako model tabelaryczny". Każdy z tych dwóch modeli ma swoje mocne i słabe strony, i są one odpowiednie dla różnego rodzaju projektów. Model tabelaryczny nie zastępuje modelu wielowymiarowego. Model tabelaryczny nie jest lepszy lub gorszy od wielowymiarowego. Oba modele po prostu wzajemnie się uzupełniają. Pomimo wieloletniego przywiązania do modelu wielowymiarowego, model tabelaryczny zrobił na nas wrażenie, gdyż nie tylko jest niezwykle szybki, ale ze względu na swą prostotę przyciągnie do BI wielu nowych zwolenników. Z dwóch powodów autorzy skupili się w tej książce wyłącznie na modelu tabelarycznym. Po pierwsze, w modelu wielowymiarowym nie wprowadzono zbyt wielu zmian, więc wcześniejsze książki na temat Analysis Services są nadal aktualne.

17 Po drugie, jeśli w naszym projekcie korzystamy z Analysis Services, wcześniej musimy podjąć decyzję, którego modelu będziemy używać mało prawdopodobne jest używanie obydwu. Oznacza to, że każdy, kto decyduje się na korzystanie z modelu tabelarycznego, i tak nie będzie zainteresowany modelem wielowymiarowym. Jednym z podstawowych celów tej książki jest podanie informacji potrzebnych do podjęcia decyzji o używanym modelu. Autorzy z przyjemnością uczyli się modelu tabelarycznego i pisali na jego temat i mają nadzieję, że Czytelnicy podzielą to przekonanie. Dla kogo przeznaczona jest ta książka Książka ta jest skierowana do profesjonalnych deweloperów BI: to konsultanci lub członkowie grup deweloperskich BI, którzy mają rozpocząć projekt, korzystając z modelu tabelarycznego. Założenia Choć zaczniemy od podstaw modelu tabelarycznego, więc książkę tę można traktować jako wprowadzenie do tematu, zakładamy jednak, że Czytelnicy znają podstawowe pojęcia BI, takie jak modelowanie wymiarowe oraz projektowanie hurtowni danych. Do zrozumienia struktury modelu tabelarycznego i ładowania do niego danych oraz takich tematów, jak DirectQuery, ważna będzie wiedza o relacyjnych bazach danych, zwłaszcza o SQL Server. Wcześniejsze doświadczenie z modelem wielowymiarowym Analysis Services nie jest konieczne, ale zakładamy, że Czytelnicy wiedzą coś na ten temat i porównujemy jego funkcje z odpowiednimi funkcjami modelu tabelarycznego. Kto nie powinien czytać tej książki Żadna książka nie jest odpowiednia dla każdego odbiorcy i ta nie stanowi wyjątku. Osoby bez doświadczenia w zakresie analizy biznesowej dość szybko znajdą się w kłopotach, podobnie jak menedżerowie bez wykształcenia technicznego. xvii

18 xviii Wprowadzenie Organizacja książki Organizacja książki jest następująca: W pierwszym rozdziale znajduje się wprowadzenie do modelu tabelarycznego, czym on jest i kiedy należy go używać, a kiedy nie. Rozdziały 2 i 3 poświęcono podstawom budowy modelu tabelarycznego. W rozdziałach od 4 do 8 omawiany jest język DAX, jego pojęcia, składnia i funkcje oraz sposób tworzenia wyliczanych kolumn, miar i zapytań. W rozdziałach od 9 do 16 jest mowa o różnych tematach związanych z projektowaniem modelu tabelarycznego, jak hierarchie, relacje, wiele-do-wielu oraz bezpieczeństwo. Wreszcie w rozdziałach 17 i 18 jest mowa o zagadnieniach operacyjnych, takich jak dostosowanie sprzętu oraz konfiguracja, optymalizacja i monitorowanie. Stosowane konwencje i cechy książki Informacje w książce przedstawiono, korzystając z konwencji, dzięki którym mają być one czytelne i łatwe do śledzenia: Elementy w ramkach, takie jak Uwaga podają dodatkowe informacje lub alternatywne metody skutecznego wykonania danego kroku. Tekst do wpisania (poza blokami kodu) jest pogrubiony. Znak plus (+) między nazwami klawiszy oznacza, że trzeba te klawisze nacisnąć jednocześnie. Na przykład tekst naciśnij Alt+Tab oznacza, że trzeba trzymać naciśnięty klawisz Alt, a wtedy nacisnąć klawisz Tab. Pionowa kreska między dwoma lub więcej elementami menu (na przykład Plik Zamknij) oznacza, że trzeba wybrać pierwsze menu lub jego element, potem następny i tak dalej. Wymagania względem systemu Aby zainstalować przykłady kodu oraz przykładowe bazy danych z tej książki, trzeba mieć następujący sprzęt i oprogramowanie: Windows Vista SP2, Windows 7, Windows Server 2008 SP2 lub nowsze. Można korzystać zarówno z wersji 32-bitowych, jak i 64-bitowych. Nie mniej niż 4 GB wolnego miejsca na dysku. Nie mniej niż 4 GB pamięci RAM. Procesor 2,0GHz x86 lub x64, albo lepszy. Instancję modelu tabelarycznego SQL Server Analysis Services 2012 Tabular plus komponenty klienckie. Pełna instrukcja instalacji znajduje się w rozdziale 2, Rozpoczęcie pracy w modelu tabelarycznym.

19 Przykłady kodu xix Przykłady kodu Baza danych wykorzystywana w przykładach tej książki została oparta na przykładowej bazie danych Microsoft Adventure Works 2012 DW. Ponieważ istnieje kilka różnych wersji tej bazy danych, a każda jest nieco inna, zalecamy pobranie tej bazy danych, której link podano niżej, zamiast korzystania w przykładach z własnej kopii Adventure Works. Wszystkie przykładowe projekty oraz przykładową bazę danych można pobrać z następującej strony: Aby pobrać plik BismTabularSample.zip oraz przykładową bazę danych, trzeba postępować zgodnie ze wskazówkami. Instalacja próbek kodu Instalacja próbek kodu na swoim komputerze w celu korzystania z przykładów zawartych w książce, wymaga postępowania zgodnie z poniższymi krokami: 1. Rozpakowujemy plik z przykładami na nasz twardy dysk. 2. Przywracamy dwie bazy danych SQL Server z plików.bak, które można znaleźć w katalogu Databases. Pełną instrukcję postępowania można znaleźć tu: msdn.microsoft.com/en-us/library/ms aspx. 3. Przywracamy tabelaryczną bazę danych Adventure Works do Analysis Services z pliku.abf, która także znajduje się w katalogu Databases. Pełną instrukcję postępowania można znaleźć tu: 4. Każdy rozdział ma swój katalog zawierający przykłady kodu. W wielu przypadkach mają one formę projektu, który trzeba otworzyć za pomocą narzędzi SQL Server Data Tools. Pełną instrukcję instalacji SQL Server Data Tools podano w rozdziale 2, Rozpoczęcie pracy w modelu tabelarycznym.

20 xx Wprowadzenie Errata i wsparcie dla książki Autorzy dołożyli wszelkich starań, aby zapewnić dokładność książki i jej kontekstu. Wszelkie błędy, które zostały zgłoszone po publikacji książki, podano na naszej witrynie Microsoft Press w oreilly.com: Każdy, kto znajdzie błąd, którego nie ma na liście, może go zgłosić na tejże stronie. Ewentualną dodatkową pomoc można uzyskać, pisząc do Microsoft Press Book Support, pod adres mspinput@microsoft.com. Pod powyższymi adresami nie można uzyskać wsparcia dla oprogramowania firmy Microsoft. Czekamy na kontakt W Microsoft Press satysfakcja Czytelników jest podstawowym priorytetem, a kontakty od klientów najcenniejszym zasobem. Czekamy na komentarze na temat tej książki pod adresem: Ankieta jest krótka i czytamy każdy komentarz i pomysł. Z góry dziękujemy za Wasz wkład! Pozostańmy w kontakcie Niech trwa wymiana poglądów. Jesteśmy też na Twitterze: Podziękowania Autorzy chcą podziękować niżej wymienionym osobom za ich pomoc i radę. Są to: Akshai Mirchandani, Amir Netz, Ashvini Sharma, Brad Daniels, Cristian Petculescu, Dan English, Darren Gosbell, Dave Wickert, Denny Lee, Edward Melomed, Greg Galloway, Howie Dickerman, Hrvoje Piasevoli, Jeffrey Wang, Jen Stirrup, John Sirmon, John Welch, Kasper de Jonge, Marius Dumitru, Max Uritsky, Paul Sanders, Paul Turley, Rob Collie, Rob Kerr, TK Anand, Teo Lachev, Thierry D Hers, Thomas Ivarsson, Thomas Kejser, Tomislav Piasevoli, Vidas Matelis, Wayne Robertson, Paul te Braak, Stacia Misner, Javier Guillen, Bobby Henningsen, Toufiq Abrahams, Christo Olivier, Eric Mamet, Cathy Dumas i Julie Strauss.

21 ROZDZIAŁ 1 Wprowadzenie do modelu tabelarycznego Celem tego rozdziału jest wprowadzenie do usług Analysis Services 2012, podanie krótkiego przeglądu idei modelu tabelarycznego (ang. Tabular model) oraz analiza jego związków z modelem wielowymiarowym (ang. Multidimensional model), całością usług Analysis Services 2012 oraz z szerszym zakresem narzędzi firmy Microsoft do analizy biznesowej (BI). Rozdział ten pomoże nam także w podjęciu najważniejszej zapewne decyzji w cyklu życia naszego projektu: czy należy korzystać z modelu tabelarycznego. Ekosystem Microsoft BI W ekosystemie firmy Microsoft, BI nie jest oddzielnym produktem; jest to raczej zestaw funkcji rozdzielonych pomiędzy kilka produktów, co wyjaśnimy w kolejnych punktach. Czym jest usługa Analysis Services i dlaczego należy jej używać? Analysis Services to baza danych OLAP (online analytical processing, przetwarzanie analityczne online), rodzaj bazy danych w wysokim stopniu zoptymalizowanej do wykonywania zapytań i obliczeń powszechnie stosowanych w środowisku analizy biznesowej. Wykonuje wiele działań zbliżonych do relacyjnej bazy danych, ale różni się od niej w wielu elementach. W większości przypadków rozwiązanie biznesowe BI jest łatwiej uzyskać, korzystając z usługi Analysis Services w połączeniu z relacyjną bazą danych, taką jak Microsoft SQL Server, niż korzystając z samego SQL Servera. Analysis Services nie zastępuje relacyjnej bazy danych ani odpowiednio zaprojektowanej hurtowni danych. Usługi Analysis Services można traktować jako dodatkową warstwę metadanych lub model semantyczny, umieszczony ponad hurtownią danych w relacyjnej bazie danych. Ta dodatkowa warstwa zawiera informacje o tym, jak powinny być połączone tabele faktów i tabele wymiarów, jak agregować miary, jakie możliwości eksploracji danych w ramach hierarchii powinni mieć użytkownicy, definicje podstawowych obliczeń i tak dalej. Warstwa ta obejmuje jeden lub więcej modeli zawierających logikę biznesową 1

22 2 Rozdział 1: Wprowadzenie do modelu tabelarycznego naszej hurtowni danych zaś użytkownicy końcowi wykonują zapytania w ramach tych modeli, a nie w zawartej w nich relacyjnej bazie danych. Dzięki temu, że wszystkie informacje znajdują się w jednym centralnym położeniu i są współdzielone przez użytkowników, zapytania pisane przez użytkowników stają się znacznie prostsze: w większości przypadków zapytanie musi jedynie opisać, które wiersze i kolumny są potrzebne, zaś model zastosuje odpowiednią logikę biznesową, aby zwracane wartości były sensowne. Co najważniejsze, niemożliwe staje się napisanie zapytania, które zwraca niepoprawny wynik z powodu błędu użytkownika końcowego, takiego jak niewłaściwe powiązanie dwóch tabel lub sumowanie kolumny, której nie można sumować. To z kolei oznacza, że narzędzia raportowania i analizy po stronie użytkownika końcowego muszą wykonać znacznie mniejszą pracę i mogą dostarczyć prostszy graficzny interfejs do budowania przez niego zapytań. Oznacza to także, że do tego samego modelu można dołączać różne narzędzia, nadal otrzymując spójne wyniki. Innym sposobem myślenia o usługach Analysis Services jest traktowanie ich jako rodzaju pamięci podręcznej używanej do przyspieszenia raportowania. W większości scenariuszy, w których korzystamy z Analysis Services, ładuje się do nich kopię danych z hurtowni danych. W konsekwencji wszystkie zapytania związane z raportami i analizą są realizowane poprzez Analysis Services, a nie w ramach relacyjnej bazy danych. Choć nowoczesne relacyjne bazy danych są mocno zoptymalizowane i zawierają wiele funkcji nakierowanych konkretnie na raporty BI, Analysis Services to baza danych zaprojektowana specjalnie dla tego typu prac i może w większości przypadków dać znacznie lepszą efektywność wykonywania zapytań. Optymalizacja działania zapytania jest niezwykle ważna dla użytkowników końcowych, gdyż pozwala im na przeglądanie danych bez długiego oczekiwania na realizację raportów oraz bez przerw w łańcuchu rozumowania. Największą korzyścią dla działu IT jest możliwość przeniesienia ciężaru tworzenia raportów na użytkowników końcowych. Częstym problemem projektów BI, które nie korzystają z OLAP, jest fakt, że wydział IT musi tworzyć zarówno hurtownie danych, jak i powiązane z nią raporty. Zwiększa to konieczny wysiłek i nakład czasu, często powodując frustrację biznesu w sytuacji, gdy dział IT nie potrafi zrozumieć wymagań związanych z tworzeniem raportów i reagować na nie tak szybko, jak się tego wymaga. Gdy używana jest baza danych OLAP, taka jak Analysis Services, dział IT może udostępniać użytkownikom końcowym używane przez nią modele, pozwalając im na samodzielne budowanie raportów za pomocą takiego narzędzia, jakie im najbardziej odpowiada. Najpopularniejszym narzędziem klienckim jest Microsoft Excel. Od czasu, gdy w Office 2000 tabele przestawne Excela uzyskały możliwość bezpośredniego połączenia z kostkami Analysis Services, Excel 2010 ma niezwykle silne możliwości jako klient Analysis Services. Podsumowując, Analysis Services nie tylko ogranicza nakłady pracy działu IT, lecz także zwiększa satysfakcję użytkownika końcowego, gdyż użytkownicy mogą sami budować raporty zgodnie ze swoimi chęciami i przeglądać dane we własnym tempie bez pośredników.

23 Ekosystem Microsoft BI 3 Krótka historia Analysis Services Usługi SQL Server Analysis Services inaczej usługi OLAP, zgodnie z wcześniejszą terminologią wprowadzoną przy udostępnieniu SQL Server 7.0 stanowiły pierwsze wejście firmy Microsoft na rynek BI. Po ich wprowadzeniu wiele osób uznało, że pokazały one, iż oprogramowanie BI może wyjść z niszy i wejść na masowy rynek. Sukces Analysis Services i pozostałych produktów BI firmy Microsoft, jaki miał miejsce w ostatniej dekadzie, potwierdził te przewidywania. Usługi SQL Server Analysis Services 2000 stanowiły pierwszą wersję Analysis Services, która zyskała duże znaczenie na rynku. Analysis Services 2005 szybko stały się najlepiej sprzedającym się narzędziem OLAP, gdy zaś Analysis Services 2008 i 2008 R2 jeszcze poprawiły skalowalność i wydajność, coraz więcej firm zaczęło je przyjmować jako podstawę swojej strategii BI. Terabajtowe kostki są teraz dość częste, a słynnym przykładem jest tu kostka Yahoo! o rozmiarach 24 TB, pokazując, ile można osiągnąć. Dziś Analysis Services to dojrzały produkt, który odniósł sukces i jest używany w tysiącach wdrożeń firmowych, ciesząc się pełnym zaufaniem. Obecny zestaw BI firmy Microsoft Sukces usług Analysis Services nie byłby możliwy, gdyby nie stanowiły one części szerszego zestawu narzędzi BI, które firma Microsoft z sukcesem wprowadzała z upływem lat. Tych narzędzi jest bardzo wiele, dlatego warto je wymienić, dodając krótki opis działania każdego z nich. Zestaw BI firmy Microsoft BI można podzielić na dwie główne grupy: produkty stanowiące część zestawu narzędzi SQL Server oraz produkty stanowiące część grupy Office. Narzędzia związane z SQL Server BI w obrębie SQL Server 2012 obejmują: Relacyjną bazę danych SQL Server Flagowy produkt zestawu SQL Server i platforma relacyjnej hurtowni danych. SQL Azure Wersja SQL Servera przygotowana przez Microsoft w oparciu o chmurę, która obecnie nie jest powszechnie używana do celów BI, ale w przyszłości, gdy inne produkty oparte na chmurze staną się bardziej popularne, będzie coraz więcej używana. Równoległa hurtownia danych Wysoce specjalizowana wersja SQL Servera, skierowana dla firm posiadających hurtownie danych o pojemności wielu terabajtów, w której obciążenie pracą można rozdzielić na wiele fizycznych serwerów. aspx

24 4 Rozdział 1: Wprowadzenie do modelu tabelarycznego SQL Server Integration Services Narzędzie do wybierania, transformacji i ładowania (ETL extract, transform, load) przeznaczone do przenoszenia danych z miejsca na miejsce. Zwykle wykorzystywane jest do ładowania danych do hurtowni danych. integrationservices.aspx Apache Hadoop Szeroko stosowane narzędzie open-source służące do agregacji i analizy dużej liczby danych. Firma Microsoft zdecydowała się na bezpośrednią jego obsługę w systemie Windows i zapewnia narzędzia pomocnicze do jego integracji z resztą zestawu Microsoft BI. Usługi raportowania SQL Server Reporting Services Narzędzie do tworzenia statycznych i semistatycznych sformatowanych raportów, będące prawdopodobnie najszerzej używanym narzędziem SQL Server BI. Raportowanie SQL Azure Wersja SQL Server Reporting Services oparta na chmurze, w czasie pisania książki dostępna jako wersja beta. Power View Narzędzie do wizualizacji i analizy o dużych możliwościach, dostępne za pośrednictwem Microsoft SharePoint, które działa jako zewnętrzne opakowanie Analysis Services. breakthrough-insight.aspx StreamInsight Złożona platforma przetwarzania zdarzeń służąca do analizy danych, które przychodzą za szybko i w zbyt wielkiej liczbie, aby pozostać w relacyjnej bazie danych. complex-event-processing.aspx Usługi Master Data Services Narzędzie do zarządzania spójnym zbiorem podstawowych danych w systemach BI. master-data-services.aspx Usługi jakości danych (Data Quality Services) Narzędzie zapewniające jakość i czyszczenie danych. PowerPivot Samoobsługowe narzędzie BI, które umożliwia użytkownikom zbudowanie własnych rozwiązań raportowania w Excelu i publikowanie ich

25 Ekosystem Microsoft BI 5 w SharePoint. Jest blisko związane z Analysis Services i jest dokładniej omawiane w punkcie Samoobsługowa i korporacyjna analiza biznesowa (BI). Narzędzia BI opracowane w ramach grupy Office obejmują: SharePoint 2010 Flagowy portal i produkt do współpracy firmy Microsoft. Z punktu widzenia firmy Microsoft wszelkie nasze raporty BI powinny znaleźć się w SharePoint, za pośrednictwem aplikacji Excel i Excel Services, Reporting Services, Power View oraz PerformancePoint. Służy także jako centrum współdzielenia modeli PowerPivot, dzięki zastosowaniu PowerPivot dla SharePoint. Usługi PerformancePoint Services Narzędzie do tworzenia pulpitu nawigacyjnego BI w ramach SharePoint. Excel 2010 Od dawna używany arkusz kalkulacyjny i zapewne najszerzej na świecie używane narzędzie BI. Excel od dawna potrafił połączyć się bezpośrednio z Analysis Services poprzez tabele przestawne i formuły kostek. Teraz, po wprowadzeniu PowerPivot, który jest dodatkiem (add-in) do Excela, stanowi on centrum samoobsługowej strategii BI firmy Microsoft. Warto też wspomnieć, że firma Microsoft udostępnia coraz więcej eksperymentalnych narzędzi BI na swojej witrynie SQL Azure Labs ( które obejmują projekty określane jako Social Analytics (Analiza społeczna) i Data Explorer (Eksplorator danych). Ponadto wielu innych dostawców oprogramowania ma swój udział w ekosystemie BI firmy Microsoft, na przykład tworząc narzędzia klienckie dla usług Analysis Services. Samoobsługowa i korporacyjna analiza biznesowa ( BI) Jednym z najbardziej znaczących trendów ostatnich lat w dziedzinie BI było pojawienie się tak zwanych samoobsługowych narzędzi BI, takich jak QlikView oraz Tableau. Celem tych narzędzi jest wyposażenie użytkowników w możliwość tworzenia niewielkich rozwiązań BI bez pomocy działu IT lub z niewielką pomocą z ich strony. W pewnym sensie usługi Analysis Services zawsze były swego rodzaju narzędziem samoobsługowym BI, umożliwiającym użytkownikom końcowym budowanie własnych zapytań i raportów, jednak nadał wymagają specjalisty z dziedziny IT do projektowania i budowania bazy danych Analysis Services oraz związanej z nią hurtowni danych. Oznacza to, że są one zwykle połączone z innymi, bardziej tradycyjnymi narzędziami korporacyjnymi BI, w których projektowanie baz danych, raportowanie i dostęp do danych są ściśle kontrolowane przez dział IT. W wielu organizacjach, zwłaszcza tych mniejszych, brakuje po prostu zasobów do realizacji większych projektów BI; jeśli nawet się ich podejmują, istnieje duży procent niepowodzeń dla tego typu projektów, stąd dla pewnej grupy użytkowników samoobsługowe narzędzia IT są atrakcyjne, gdyż pozwalają im robić wszystko samodzielnie.

26 6 Rozdział 1: Wprowadzenie do modelu tabelarycznego Najprostszym sposobem wywołania sporu między dwoma specjalistami BI jest zadanie im pytania, co myślą o samoobsługowych BI. Z jednej strony samoobsługowe BI sprawiają, że tworzenie BI jest bardzo skoncentrowane na biznesie, zapewnia dobrą reakcję na potrzeby i jest elastyczne. Z drugiej strony może to wzmocnić problemy związane z utrzymywaniem nieaktualnych danych, marną jakością danych, brakiem integracji między wieloma systemami źródłowymi oraz różnymi interpretacjami sposobu modelowania danych, zwłaszcza że zwolennicy samoobsługowych BI twierdzą, że czasochłonny etap tworzenia hurtowni danych jest zbędny. Niezależnie od wad i zalet samoobsługowych BI jest to szybko rosnący rynek, którego Microsoft, jako firma zajmująca się oprogramowaniem, nie mogła zignorować, więc w roku 2010 wypuściła własne samoobsługowe narzędzie BI o nazwie PowerPivot. PowerPivot to wersja Analysis Services przeznaczona na komputery osobiste, przyjmuje jednak postać dodatku do aplikacji do Excela 2010, który można bezpłatnie pobrać. (Więcej szczegółów można znaleźć na Sprawia ona, że użytkownicy Excela mogą łatwo importować dane z wielu źródeł, budować własne modele oraz przeszukiwać je za pomocą tabel przestawnych. Baza danych PowerPivot działa jako proces wewnętrzny Excela; wszystkie importowane dane są tam przechowywane i wszystkie zapytania z Excela są realizowane względem nich. Użytkownicy Excela mogą działać na znacznie większej liczbie danych niż kiedykolwiek wcześniej, gdy przechowywali je bezpośrednio w arkuszu Excela, przy szybkich jak błyskawica czasach odpowiedzi zapytań. Podczas zapisywania skoroszytu Excela, baza danych PowerPivot i wszystkie pozostałe dane są przechowywane wewnątrz skoroszytu; skoroszyt można potem skopiować i współdzielić, tak jak inne skoroszyty Excela, jednak każdy użytkownik, który chce przeglądać dane przechowywane w PowerPivot, musi mieć PowerPivot zainstalowany na swoim komputerze. Aby bardziej efektywnie współdzielić modele i raporty między grupami użytkowników, potrzebna jest usługa Power- Pivot for SharePoint, która integruje się z wersją Microsoft SharePoint 2010 Enterprise. Dzięki PowerPivot for SharePoint możliwe stało się załadowanie do aplikacji SharePoint skoroszytu zawierającego bazę danych PowerPivot, a użytkownicy uzyskali dostęp do przeglądania przez sieć WWW raportów w skoroszytach za pomocą Excel Service. Można także wykonywać zapytania dotyczące danych przechowywanych w PowerPivot na serwerze, używając w tym celu Excela lub innego narzędzia klienta Analysis Services dostępnego na swoim komputerze. Udostępnienie PowerPivot nie oznacza, że zmniejszyło się zaangażowanie formy Microsoft w narzędzia korporacyjne. Żadne narzędzie nie jest właściwe we wszystkich sytuacjach. Zaletą firmy Microsoft jest to, że nie tylko sprzedaje zarówno samoobsługowe narzędzia BI, jak i narzędzia korporacyjne, lecz ma także spójne zasady współistnienia obu typów narzędzi w ramach jednej organizacji. Microsoft przewiduje sytuację, w której działy IT i zaawansowani użytkownicy żyją w harmonii, w której projekty prowadzone przez dział IT korzystają z korporacyjnych narzędzi BI i przekazują do wszystkich dane z centralnej hurtowni danych za pomocą raportów i kostek

27 Architektura Analysis Services 2012: jeden produkt, dwa modele 7 Analysis Services. Jednocześnie zaawansowani użytkownicy mogą swobodnie budować swoje własne samoobsługowe modele w PowerPivot, współdzielić je z innymi oraz, jeśli ich modele zyskają popularność, przekazywać je działowi IT, aby je dalej rozwijał, obsługiwał i ewentualnie włączał do modelu korporacyjnego. PowerPivot for SharePoint zapewnia pewną liczbę pulpitów pozwalających działowi IT na monitorowanie wykorzystania modeli PowerPivot, które zostały załadowane do SharePoint, zaś w Analysis Services 2012 możliwe jest także importowanie modeli utworzonych w PowerPivot do Analysis Services. Kolejne wersje będą prawdopodobnie zawierać funkcje pomocne w budowaniu mostów pomiędzy światami samoobsługowych i korporacyjnych BI. Architektura Analysis Services 2012: jeden produkt, dwa modele W tej części rozdziału wyjaśniono element architektury Analysis Services, która w SQL Server 2012 jest podzielona na dwa modele. Pierwszą i najważniejszą kwestią dotyczącą Analysis Services 2012 jest fakt, że są to w zasadzie dwa produkty w jednym. Analysis Services w wersji SQL Server 2008 R2 i wcześniejszych jest nadal dostępny, ale nazywa się teraz modelem wielowymiarowym (Multidimensional model). Został poprawiony w zakresie wydajności, skalowalności i możliwości zarządzania, ale nie zawiera nowych funkcji. Natomiast nowa wersja Analysis Services, która bardzo przypomina PowerPivot, nosi nazwę modelu tabelarycznego (Tabular model). Właśnie Model tabelaryczny jest tematem tej książki. Podczas instalacji Analysis Services trzeba wybrać, czy instalujemy instancję, która pracuje w trybie tabelarycznym, czy w trybie wielowymiarowym. Więcej szczegółów na temat instalacji podano w rozdziale 2, Rozpoczęcie pracy w modelu tabelarycznym. Instancja tabelaryczna może obsługiwać tylko bazy danych zawierające modele tabelaryczne, zaś instancja wielowymiarowa może obsługiwać bazy danych zawierające modele wielowymiarowe. Choć obie części Analysis Services mają wiele wspólnego kodu, w wielu aspektach muszą być traktowane jak oddzielne produkty. Koncepcje związane z projektem dwóch typów modeli bardzo się różnią, więc nie można przekształcić tabelarycznej bazy danych w bazę wielowymiarową i odwrotnie, bez przebudowania wszystkiego do nowa. Po tym stwierdzeniu trzeba podkreślić, że z punktu widzenia użytkownika końcowego oba modele wykonują niemal te same zadania i wydają się identyczne, jeśli używane są z poziomu narzędzia klienckiego jak Excel. W kolejnych podrozdziałach porównano dostępne funkcje modeli tabelarycznego i wielowymiarowego oraz zdefiniowano niektóre ważne terminy używane w dalszej części tej książki.

28 8 Rozdział 1: Wprowadzenie do modelu tabelarycznego Model tabelaryczny W modelu tabelarycznym obiektem najwyższego poziomu jest baza danych, co przypomina koncepcję bazy danych w relacyjnej bazie danych SQL Server. Instancja Analysis Services może zawierać wiele baz danych, zaś każda baza danych może być traktowana jak zawarta w niej kolekcja obiektów i danych odnoszących się do jednego rozwiązania biznesowego. Jeśli przy pisaniu raportów lub analizowaniu danych okazuje się, że trzeba wykonywać zapytania względem wielu baz danych, zapewne popełniliśmy gdzieś błąd, gdyż wszystko, czego potrzebujemy, powinno być zawarte w jednej bazie danych. Modele tabelaryczne są zaprojektowane za pomocą narzędzi SQL Server Data Tools (SSDT), zaś projekt w SSDT jest odwzorowany na bazę danych w Analysis Services. Po utworzeniu projektu w SSDT, musimy go wdrożyć w instancji Analysis Services, co oznacza, że SSDT wykonuje kilka poleceń, aby utworzyć nową bazę danych w Analysis Services lub zmienia strukturę istniejącej bazy danych. SQL Server Management Studio (SSMS), narzędzie używane do zarządzania już wdrożonymi bazami danych, może być także wykorzystane do pisania zapytań względem baz danych. Bazy danych składają się z jednej lub większej liczby tabel danych. Tabela w modelu tabelarycznym jest bardzo podobna do tabeli w relacyjnych bazach danych. Jest ona zwykle ładowana z pojedynczej tabeli w relacyjnej bazie danych lub z wyników instrukcji SQL SELECT. Tabela ma ściśle ustaloną liczbę kolumn, które są definiowane w momencie projektowania. Może mieć zmienną liczbę wierszy, zależnie od liczby danych do niej załadowanych. Każda kolumna ma niezmienny typ, na przykład kolumna może zawierać tylko wartości całkowite, tylko teksty lub tylko wartości dziesiętne. Ładowanie danych do tabeli jest określane jako przetwarzanie tabeli. Podczas projektowania można też zdefiniować relacje między tabelami. W przeciwieństwie do SQL, nie można definiować relacji podczas realizacji zapytań; wszystkie zapytania muszą korzystać z wcześniej istniejących relacji. Jednak relacje między tabelami mogą być oznaczone jako aktywne lub nieaktywne, zaś podczas zapytania można wybrać, które relacje między tabelami będą używane. Wewnątrz zapytań i obliczeń można też symulować efekt relacji, które nie istnieją. Wszystkie relacje są relacjami jeden-do-wielu i muszą obejmować tylko jedną kolumnę z każdej z dwóch tabel. Nie można zdefiniować relacji, które mają jawnie postać jeden-do-jednego albo wiele-do- -wielu, choć ten sam efekt można osiągnąć, pisząc zapytania i obliczenia w określony sposób. Nie jest także możliwe zaprojektowanie relacji opartych na więcej niż jednej kolumnie z tabeli ani relacji rekurencyjnych, łączących tabelę z nią samą. Model tabelaryczny wykorzystuje wyłącznie mechanizm oparty na pamięci i przechowuje na dysku tylko kopię swoich danych, tak więc żadne dane nie zostaną utracone, jeśli usługa zostanie zrestartowana. Podczas gdy model wielowymiarowy, jak większość relacyjnych mechanizmów baz danych, przechowuje swoje dane w formacie opartym na wierszach, model tabelaryczny korzysta z bazy danych opartej na kolumnach, noszącej nazwę pamięciowego mechanizmu analitycznego xvelocity, który

29 Architektura Analysis Services 2012: jeden produkt, dwa modele 9 w większości przypadków oferuje znaczące polepszenie wydajności zapytań. (Więcej szczegółów na temat bazy danych opartej na kolumnach można znaleźć w en.wikipedia.org/wiki/column-oriented_dbms). UWAGA Pamięciowy mechanizm analityczny xvelocity był przed wydaniem Analysis Services 2012 znany jako mechanizm Vertipaq. W dokumentacji, postach na blogach i w innych materiałach online pozostało wiele odwołań do nazwy Vertipaq. Pozostaje ona nawet wewnątrz samego produktu, w nazwach własnościowych oraz zdarzeniach aplikacji Profiler. Nazwa xvelocity jest używana także w odniesieniu do większej rodziny powiązanych technologii, w tym do nowej funkcji indeksu pamięci kolumnowej w mechanizmie relacyjnej bazy danych SQL Server Więcej szczegółów na temat tej terminologii można znaleźć pod adresem -analysis-services.aspx. W modelu tabelarycznym zapytania i obliczenia są zdefiniowane w DAX (Data Analysis expressions), podstawowym języku modelu tabelarycznego i w PowerPivot. Narzędzia klienckie, takie jak Power View mogą generować zapytania w DAX, aby wyciągać dane z modelu tabelarycznego. Można też pisać własne zapytania w DAX i wykorzystywać je w raportach. Możliwe jest także pisanie zapytań w języku MDX używanym w modelu wielowymiarowym. Oznacza to, że model tabelaryczny jest wstecznie kompatybilny z wieloma istniejącymi narzędziami klienckimi Analysis Services, takimi jak Excel i SQL Server Reporting Services, oraz narzędziami innych producentów oprogramowania. Do tabeli w modelu tabelarycznym można dodawać wyznaczane kolumny, określane jako kolumny wyliczane; wykorzystuje się w nich wyrażenia DAX, aby zwracać wartości na podstawie danych znajdujących się w innych kolumnach tej samej lub innej tabeli w obrębie tej samej bazy danych Analysis Services. Podczas przetwarzania oraz po zakończeniu przetwarzania kolumny wyliczane zachowują się dokładnie tak samo jak zwykłe kolumny. Za pomocą wyrażeń DAX na tabelach można także definiować miary. Miarami nazywamy wyrażenia DAX, które zwracają pewną zagregowaną wartość na podstawie danych z jednej lub wielu kolumn. Prostym przykładem miary jest wartość sumy wszystkich wartości z kolumny zawierającej wielkości sprzedaży. Kluczowe wskaźniki wydajności (KPI) są bardzo podobne do miar, jednak stanowią kolekcję obliczeń, dzięki której można określić stosunek miary do wartości docelowej oraz to, czy w miarę upływu czasu zbliża się ona do wyznaczonego celu. W większości narzędzi użytkowych, takich jak Excel, do zapytań w modelu tabelarycznym stosuje się zasady podobne do tych w tabelach przestawnych: kolumny z różnych tabel można przeciągać względem osi wierszy i kolumn tabeli przestawnej, tak aby określone wartości z tych kolumn stały się poszczególnymi wierszami i kolumnami tabeli przestawnej, a miary wewnątrz tabeli pokazywały zagregowane wartości liczbowe. Końcowy efekt przypomina nieco zapytanie Group By w SQL, ale definicja sposobu agregacji danych jest z góry zdefiniowana wewnątrz miar i nie musi być

30 10 Rozdział 1: Wprowadzenie do modelu tabelarycznego podawana wewnątrz samego zapytania. Aby poprawić wrażenia użytkownika, można także zdefiniować dla tabel hierarchię wewnątrz modelu tabelarycznego, co tworzy wielopoziomowe, predefiniowane ścieżki postępowania. Perspektywy mogą ukrywać niektóre części złożonego modelu, co zwiększa wartości użytkowe, zaś role zabezpieczeń mogą być wykorzystane do odmowy dostępu do określonych wierszy danych z tabeli określonego użytkownika. Jednak perspektyw nie należy mylić z zabezpieczeniami; nawet jeśli obiekt jest ukryty w perspektywie, nadal można wysłać do niego zapytanie, zaś samej perspektywy nie można zabezpieczyć. Model wielowymiarowy Na swoim najwyższym poziomie model wielowymiarowy jest bardzo podobny do modelu tabelarycznego: dane są zorganizowane w bazy danych, zaś bazy danych są zaprojektowane w SSDT (wcześniej w BI Development Studio lub w BIDS) i zarządzane przez SQL Server Management Studio. Różnice stają się widoczne poniżej poziomu bazy danych, gdzie koncepcje wielowymiarowe przeważają nad relacyjnymi. W modelu wielowymiarowym dane są modelowane jako seria kostek i wymiarów, a nie tabel. Na każdą kostkę składa się jedna lub więcej grupa miar, zaś każda grupa miar jest kostką odwzorowaną na jedną tablicę faktów w hurtowni danych. Grupa miar zawiera jedną lub więcej miar, zaś miary są bardzo podobne do miar w modelu tabelarycznym. Kostka ma dwa lub więcej wymiarów: jeden specjalny wymiar, wymiar miar, który zawiera wszystkie miary z każdej grupy miar oraz różne inne wymiary, takie jak czas, produkt, położenie geograficzne, klient i tak dalej, które mają odwzorowanie w wymiarach logicznych w modelu wymiarowym. Każdy z wymiarów niebędący miarą składa się z jednego lub więcej atrybutów (na przykład w wymiarze Data mogą być to takie atrybuty, jak Dzień, Miesiąc i Rok), zaś atrybuty te mogą być z kolei używane w jednopoziomowych hierarchiach lub tworzyć wielowymiarowe hierarchie użytkownika. Hierarchię można stosować przy budowaniu zapytań. Użytkownicy rozpoczynają od analizy danych na wysoce zagregowanym poziomie, jak poziom roku w wymiarze czasu, a potem mogą przechodzić na niższe poziomy, jak kwartały, miesiące i dni, aby zobaczyć trendy i interesujące anomalie. Ponieważ model wielowymiarowy jest bezpośrednim następcą poprzednich wersji Analysis Services, zgodnie z oczekiwaniami obejmuje on bogaty i dojrzały zestaw funkcji reprezentujący owoce ponad dekady rozwoju, choć niektóre z tych funkcji używane są niezbyt często. Większość funkcji dostępnych w modelu tabelarycznym istnieje także w modelu wielowymiarowym, lecz model wielowymiarowy ma także wiele funkcji, które nie zostały jeszcze zaimplementowane w modelu tabelarycznym. Szczegółowe porównanie funkcji w obu modelach znajduje się w dalszej części rozdziału. W modelu wielowymiarowym można przechowywać dane na trzy sposoby: OLAP wielowymiarowy (Multidimensional OLAP, MOLAP), gdzie dane są przechowywane we własnym formacie Analysis Services opartym na pamięci dyskowej.

31 Architektura Analysis Services 2012: jeden produkt, dwa modele 11 OLAP relacyjny (Relational OLAP, ROLAP), gdzie Analysis Services działa jak warstwa metadanych i żadne dane nie są przechowywane w samej usłudze Analysis Services; gdy zapytania kierowane są do kostki, zapytania SQL są uruchamiane względem źródłowej relacyjnej bazy danych. OLAP hybrydowy (Hybrid OLAP, HOLAP), który jest taki sam jak ROLAP, ale zawiera trochę wcześniej zagregowanych wartości zapisanych w MOLAP. Pamięć MOLAP jest używana w przeważającej większości implementacji, choć czasem, gdy potrzebne jest tak zwane BI czasu rzeczywistego, używana jest pamięć ROLAP. Pamięć HOLAP prawie nigdy nie jest używana. Obszarem, w którym modele wielowymiarowy i tabelaryczny różnią się, są obsługiwane języki zapytań i obliczeń. Podstawowym językiem modelu wielowymiarowego jest MDX i tylko w nim można definiować zapytania i obliczenia. Język MDX odniósł sukces i jest obsługiwany przez wiele narzędzi klienckich Analysis Services innych producentów. Był on także promowany jako pół otwarty standard przez grono producenckie pod nazwą XMLA Council (teraz w zasadzie niedziałające), a w rezultacie został także przyjęty przez wiele innych narzędzi OLAP, które są bezpośrednimi konkurentami Analysis Services. Jednak problemem MDX jest to, co stanowi ogólnie problem wielu użytkowników z modelem wielowymiarowym: choć ma on wielkie możliwości, wielu specjalistów BI miało trudności z nauczeniem się go, gdyż używane w nim pojęcia, takie jak wymiary i hierarchie, znacznie różnią się od tych, do których przyzwyczaił nas język SQL. Ponadto firma Microsoft publicznie zobowiązała się (w swoim poście na blogu zespołu Analysis Services i w innych ogłoszeniach publicznych, analysisservices/archive/2011/05/16/analysis-services-vision-amp-roadmap-update.aspx), że w modelu wielowymiarowym będzie można obsługiwać zapytania DAX po wdrożeniu Analysis Services 2012, jako część pakietu serwisowego. Pozwoli to, aby Power View tworzył zapytania dla modeli wielowymiarowych i modeli tabelarycznych, choć prawdopodobnie będzie trzeba przyjąć pewne kompromisy, a niektóre z funkcji modelu wielowymiarowego mogą nie działać zgodnie z oczekiwaniami, gdy będziemy używać zapytań DAX. Po co są dwa modele? Dlaczego nastąpił ten podział? Choć firma Microsoft nie komentuje tej sprawy publicznie, istnieje wiele prawdopodobnych powodów. Wielowymiarowa wersja Analysis Services starzeje się. Została zaprojektowana w erze 32-bitowych serwerów z jednym lub dwoma procesorami i pamięci RAM mniejszej od 1 GB, zaś pamięć na dyskach stanowiła dla baz danych tylko jedną z opcji. Czasy się zmieniły, a nowy sprzęt uległ radykalnej zmianie. Nowa generacja kolumnowych baz danych opartych na pamięci ustanowiła standard

32 12 Rozdział 1: Wprowadzenie do modelu tabelarycznego dla wydajności zapytań z analitycznymi zadaniami, więc Analysis Services musi się dostosować do nowej technologii. Wsteczne upakowanie nowego pamięciowego mechanizmu xvelocity do istniejącego modelu wielowymiarowego nie jest prostym zadaniem, więc konieczne stało się wprowadzenie nowego modelu tabelarycznego, który w pełni wykorzysta mechanizm xvelocity. Pomimo sukcesu wielowymiarowych Analysis Services, panowała opinia, że trudno się go nauczyć. Niektórzy specjaliści od baz danych, przyzwyczajeni do relacyjnego modelowania baz danych, mieli trudności z opanowaniem koncepcji wielowymiarowych, zaś ci, którzy je opanowali, stwierdzali, że droga nauki jest trudna. Jeśli więc Microsoft chce dotrzeć z BI do szerszej publiczności, musi uprościć proces tworzenia stąd przejście od złożonego świata modelu wielowymiarowego do względnie prostych i znanych koncepcji modelu tabelarycznego. Firma Microsoft postrzega samoobsługową BI jako potencjalne źródło znacznego wzrostu, zaś PowerPivot stanowi jej wejście na rynek. Jest istotne, aby zachować spójność między narzędziami samoobsługowymi i korporacyjnymi firmy. Jeśli więc usługi Analysis Services muszą zostać zmodernizowane, powinny być kompatybilne z PowerPivot, zapewniając podobne zasady projektowania, aby modele samoobsługowe mogły być łatwo zaktualizowane do pełnych rozwiązań korporacyjnych. Niektóre typy danych są modelowane w bardziej odpowiedni i prostszy sposób za pomocą podejścia tabelarycznego, a innym typom danych bardziej odpowiada podejście wielowymiarowe. Dwa oddzielne modele dają programistom wybór takiego podejścia, które lepiej pasuje do ich potrzeb w danych okolicznościach. Czym jest model semantyczny BI? Jednym z terminów przewijających się przy omawianiu Analysis Services 2012 jest semantyczny model BI (BISM, BI Semantic Model). Ten termin nie odnosi się ani do modelu wielowymiarowego, ani do tabelarycznego, lecz opisuje działanie Analysis Services w zestawie Microsoft BI: działa on jako warstwa semantyczna leżąca ponad relacyjną hurtownią danych, dodając bogatą warstwę metadanych obejmującą hierarchie, miary i obliczenia. W tym zakresie model ten jest bardzo podobny do modelu UDM (Unified Dimensional Model), który był używany w czasach wprowadzania SQL Server W niektórych przypadkach określenie semantyczny model BI odnosiło się tylko do modelu tabelarycznego, ale nie jest to właściwe. Ponieważ ta książka jest poświęcona przede wszystkim modelowi tabelarycznemu, nie będziemy często używać tego terminu, jednak uważamy, że trzeba dokładnie rozumieć, czym on jest i jak powinien być używany.

33 Wybór odpowiedniego modelu dla naszego projektu 13 Przyszłość Analysis Services Fakt, że wewnątrz Analysis Services istnieją dwa modele oraz dwa języki zapytań i obliczeń, nie jest idealną sytuacją. Przede wszystkim oznacza to, że rozpoczynając projekt musimy wybrać, którego modelu będziemy używać, a wtedy możemy mieć za mało danych, aby wiedzieć, który z nich jest odpowiedni to jest zagadnienie, które jest omawiane w następnym punkcie. Oznacza to także, że każdy, kto zdecyduje się specjalizować w Analysis Services, musi nauczyć się dwóch technologii. Taki stan rzeczy zapewne nie będzie trwał długo. Firma Microsoft jasno twierdzi, że model wielowymiarowy nie jest deprecjonowany, zaś model tabelaryczny nie ma go zastąpić. Możliwe, że w kolejnych wersjach Analysis Services pojawią się nowe funkcje przeznaczone dla modelu wielowymiarowego. Fakt, że modele tabelaryczny i wielowymiarowy mają wspólną część kodu sugeruje, że niektóre funkcje mogą być z łatwością rozwijane jednocześnie dla obu modeli. Post na blogu Analysis Services sugerował wcześniej, że z czasem oba modele zbliżą się do siebie i będą oferować te same funkcje, więc decyzje co do używanego modelu będą oparte na tym, czy deweloper woli modelowanie wielowymiarowe, czy też relacyjne. Krokiem w tym kierunku będzie moment, gdy w modelu wielowymiarowym stanie się dostępna obsługa zapytań DAX. Jeszcze jedna kwestia związana z przyszłością Analysis Services jest jasna: usługi te będą przenoszone na chmury. Wprawdzie w chwili pisania tej książki do publicznej wiadomości nie podano żadnych szczegółów, firma Microsoft potwierdziła, że pracuje na wersji Analysis Services opartej na chmurze, zaś wersja ta wraz z SQL Azure, SQL Azure Reporting Services oraz Office 365 będą stanowić jądro strategii BI firmy. Wybór odpowiedniego modelu dla naszego projektu Może wydawać się dziwne, że w tym miejscu książki zajmujemy się tematem, czy model tabelaryczny jest odpowiedni dla naszego projektu, choć nic jeszcze nie wiemy o samym modelu, ale na takie pytanie trzeba sobie odpowiedzieć na podobnie wczesnym etapie naszego projektu BI. Z grubsza można stwierdzić, że dla procent projektów każdy z modeli działa podobnie, ale dla pozostałych procent prawidłowy wybór modelu jest bardzo ważny. Jak wcześniej napisano, po rozpoczęciu prac z jednym modelem w ramach Analysis Services nie ma możliwości przejścia na drugi i trzeba zacząć wszystko od początku, marnując wiele cennego czasu, więc dokonanie prawidłowej decyzji powinno nastąpić możliwie wcześnie. Podczas podejmowania decyzji trzeba wziąć pod uwagę wiele czynników. W tej części omawiamy wszystkie elementy na rozsądnym poziomie szczegółowości. Można mieć w pamięci te czynniki podczas czytania dalszych części książki, zaś po jej zakończeniu będziemy wiedzieć, czy mamy korzystać z modelu tabelarycznego czy wielowymiarowego.

34 14 Rozdział 1: Wprowadzenie do modelu tabelarycznego Licencje Pakiet Analysis Services 2012 jest dostępny w następujących wersjach: SQL Server Standard, SQL Server Business Intelligence oraz SQL Server Enterprise. W wersji SQL Server Standard dostępny jest jednak tylko model wielowymiarowy, zaś dostępne funkcje są identyczne jak w poprzednich wersjach Analysis Services. Oznacza to, że kilka ważnych funkcji potrzebnych do skalowania modelu wielowymiarowego, takich jak podział na partycje, jest niedostępnych w wersji SQL Server Standard. Wersja SQL Server Business Intelligence zawiera zarówno model wielowymiarowy, jak i tabelaryczny, podobnie jak wersja SQL Server Enterprise. W zakresie funkcji Analysis Services obie wersje są identyczne; jedyną różnicą między tymi wersjami jest fakt, że licencja SQL Server Business Intelligence opiera się na licencji serwerowej plus licencje klienckie (CAL, Client Access License), podczas gdy wersja SQL Server Enterprise jest licencjonowana oddzielnie na każdy CPU. (Nie można już uzyskać licencji dla wersji SQL Server Enterprise na serwer plus CAL, jak to było w przeszłości). W wersjach SQL Server Business Intelligence i SQL Server Enterprise oba modele, tabelaryczny i wielowymiarowy, zawierają wszystkie dostępne funkcje i mogą korzystać z tylu rdzeni, na ile pozwala system operacyjny. W rezultacie czasami korzystanie z modelu tabelarycznego może być droższe niż użycie modelu wielowymiarowego, gdyż model wielowymiarowy jest dostępny w wersji SQL Server Standard, w przeciwieństwie do modelu tabelarycznego. Przy ograniczonym budżecie i znajomości modelu wielowymiarowego, gdy liczba danych nie wymaga z korzystania z takich funkcji, jak partycjonowanie, dla oszczędności sensowny jest wybór modelu wielowymiarowego i wersji SQL Server Standard. Jeśli jednak chcemy zapłacić nieco więcej za wersję SQL Server Business Intelligence lub SQL Server Enterprise, to przy wyborze modelu nie należy kierować się kosztami licencji. Aktualizacja poprzednich wersji Analysis Services Jak już wspomniano, nie ma możliwości przekształcenia modelu wielowymiarowego w model tabelaryczny. Z pewnością na rynku pojawią się narzędzia, które będą obiecywać przekształcenie za pomocą kilku kliknięć myszą, ale takie narzędzia mogą działać tylko względem bardzo prostych modeli wielowymiarowych i nie zaoszczędzą nam wiele czasu. Dlatego, jeśli mamy zaawansowaną implementację modelu wielowymiarowego oraz umiejętności w zakresie jego obsługi, nie ma zapewne sensu porzucania go na rzecz modelu tabelarycznego, o ile nie mamy konkretnych problemów z modelem wielowymiarowym, które model tabelaryczny mógłby rozwiązać. Prostota korzystania Jeśli z kolei zaczynamy korzystać z Analysis Services 2012 bez żadnego doświadczenia z modelem wielowymiarowym lub OLAP, zapewne stwierdzimy, że model tabelaryczny jest znacznie prostszy do nauki niż model wielowymiarowy. Nie tylko sama

35 Wybór odpowiedniego modelu dla naszego projektu 15 koncepcja jest prostsza do zrozumienia, zwłaszcza jeśli korzystaliśmy z relacyjnych baz danych, lecz także proces budowy projektu jest bardziej oczywisty, a do nauczenia się jest znacznie mniej funkcji. Budowa pierwszego modelu tabelarycznego jest znacznie szybsza i prostsza niż budowa pierwszego modelu wielowymiarowego. Można też stwierdzić, że łatwiej nauczyć się języka DAX niż języka MDX, zwłaszcza w zakresie podstawowych obliczeń, choć w rzeczywistości oba te języki są tak samo mylące dla osób przyzwyczajonych do SQL. Kompatybilność z PowerPivot Model tabelaryczny oraz PowerPivot są niemal identyczne, jeśli chodzi o sposób projektowania; interfejsy użytkownika są w obu przypadkach praktycznie jednakowe, oba też korzystają z języka DAX. Modele PowerPivot mogą być importowane do narzędzi danych SQL Server w celu wygenerowania modelu tabelarycznego, choć procesu tego nie można przeprowadzić w kierunku przeciwnym. Modelu tabelarycznego nie można przekształcić na model PowerPivot. Jeśli więc zależy nam na użytkowaniu samoobsługowej BI z wykorzystaniem PowerPivot, sens ma korzystanie z modelu tabelarycznego w naszych korporacyjnych modelach BI, gdyż projekty i kod można między nimi przenosić. Cechy wydajności zapytań Wprawdzie niebezpieczne jest tu generalizowanie na temat wydajności zapytań, ale można stwierdzić, że w modelu tabelarycznym będą w większości przypadków działać nie gorzej niż w wielowymiarowym, zaś przy niektórych określonych scenariuszach będą znacznie lepsze. Na przykład pewne miary obliczeniowe, które są słabością modelu wielowymiarowego, działają bardzo dobrze w modelu tabelarycznym. Konkretne dowody także wskazują na to, że zapytania względem szczegółowych raportów (na przykład zapytania zwracające wiele wierszy oraz dane na poziomie tabeli faktów), będą działać w modelu tabelarycznym znacznie lepiej, o ile napiszemy je w języku DAX, a nie w MDX. Niestety przy bardziej skomplikowanych obliczeniach i technikach modelowania, jak w relacjach wiele-do-wielu, znacznie trudniej jest stwierdzić, czy lepiej działa model wielowymiarowy, czy tabelaryczny i tylko sprawdzenie koncepcji może nam wskazać, czy wydajność danego modelu będzie spełniać wymagania. Cechy wydajności przetwarzania Trudne jest także porównanie wydajności przetwarzania w modelach wielowymiarowym i tabelarycznym. W modelu tabelarycznym przetwarzanie dużej tabeli może być znacznie wolniejsze niż dla podobnej grupy miar w modelu wielowymiarowym, gdyż model tabelaryczny nie potrafi przetwarzać równolegle partycji w ramach tej samej tabeli, zaś model wielowymiarowy (pod warunkiem posiadania wersji SQL Server Business Intelligence lub SQL Server Enterprise, które tworzą partycje grup miar) może przetwarzać równolegle partycje w tej samej grupie miar. Odrzucając różne

36 16 Rozdział 1: Wprowadzenie do modelu tabelarycznego działania niekompatybilne, wykonywane przez każdy z modeli podczas przetwarzania, jak budowa agregacji i indeksów w modelu wielowymiarowym, liczba wierszy surowych danych, które można przetwarzać na sekundę w jednej partycji, zapewne będzie podobna. Jednak w zakresie przetwarzania model tabelaryczny ma pewne znaczące zalety wobec modelu wielowymiarowego. Po pierwsze, w modelu tabelarycznym nie ma agregacji, co oznacza, że w czasie przetwarzania odpada jedno czasochłonne zadanie. Po drugie, przetwarzanie jednej tabeli w modelu tabelarycznym nie ma bezpośredniego wpływu na inne tabele modelu, zaś w modelu wielowymiarowym przetwarzanie wymiaru ma swoje konsekwencje. Wykonanie całego procesu względem wymiaru w modelu wielowymiarowym oznacza, że trzeba wykonać całe przetwarzanie na kostkach, w których używany jest ten wymiar, a ponadto nawet aktualizacja wymiaru wymaga procesu indeksowania na kostce, aby przebudować agregacje. Oba te elementy przyprawiają o ból głowy przy dużych wdrożeniach wielowymiarowych, zwłaszcza gdy mamy dostępne niewielkie okno przetwarzania. Uwarunkowania sprzętowe Modele wielowymiarowy i tabelaryczny mają także bardzo różne wymagania sprzętowe. Pamięć dyskowa modelu wielowymiarowego oznacza, że ważne są dyski o dużej wydajności i o bardzo dużej pojemności. Potrzebna jest także pamięć podręczna, więc korzystne jest posiadanie odpowiedniej pamięci RAM, choć nie jest to wymóg konieczny. W modelu tabelarycznym wydajność pamięci dyskowej nie jest priorytetowa, gdyż baza danych przechowywana jest w pamięci. Dlatego ważne jest posiadanie pamięci RAM wystarczającej do przechowywania bazy danych i do obsługi szczytów wykorzystania pamięci, które mają miejsce podczas realizacji zapytań lub przetwarzania danych. Wymagania dyskowe modelu wielowymiarowego będą zapewne łatwiejsze do zaspokojenia niż zapotrzebowanie na pamięć modelu tabelarycznego. Zakup dużych pamięci dyskowych dla serwera jest stosunkowo tani i prosty dla działu IT. Wiele firm ma sieciowe obszary pamięci (SAN), które może nie dają znacznej wydajności, ale pozwalają łatwo zapewnić odpowiednią pojemność pamięci (lub zwiększać ją). Natomiast zakup dużych ilości pamięci RAM dla serwera może być trudny wymaganie pół terabajta pamięci RAM dla serwera powoduje zdziwienie. Ponadto, jeśli okaże się, że potrzebujemy więcej pamięci RAM niż przewidywano na początku, zwiększenie dostępnej ilości może być kłopotliwie. Z doświadczenia wiadomo, że można zacząć pracę z pojemnością pamięci RAM, która wydaje się rozsądna, ale wraz z rozbudową tabeli faktów, dodawaniem nowych danych do modelu i coraz bardziej skomplikowanymi zapytaniami, można zacząć napotykać błędy braku pamięci. Ponadto w przypadku niektórych bardzo wielkich, obejmujących kilka terabajtów danych implementacji Analysis Services, zakup serwera z pamięcią wystarczającą na przechowywanie modelu może okazać się niemożliwy, a wtedy model wielowymiarowy będzie jedyną opcją możliwą do realizacji.

37 Wybór odpowiedniego modelu dla naszego projektu 17 BI czasu rzeczywistego Temat nie jest już tak popularny jak kilka lat temu, ale wymagania dotyczące czasu rzeczywistego lub warunków bliskich czasowi rzeczywistemu mogą w projektach BI stać się coraz częstsze. BI czasu rzeczywistego odnosi się zwykle do potrzeby użytkowników końcowych, aby zapytania i analiza danych były możliwe natychmiast po załadowaniu danych do hurtowni danych, bez długiego oczekiwania na załadowanie danych do Analysis Services. Model wielowymiarowy może obsłużyć ten problem na jeden z dwóch sposobów: przez wykorzystanie pamięci MOLAP i podział danych tak, aby wszystkie nowe dane w hurtowni danych wędrowały do jednej, stosunkowo niewielkiej partycji, którą można szybko przetwarzać, lub poprzez wykorzystanie pamięci ROLAP i wyłączenie stosowania pamięci podręcznej, aby model wielowymiarowy wydawał zapytania SQL przy każdym przekazaniu zapytania. Pierwsza z tych opcji jest zwykle preferowana, choć może być trudna do implementacji, zwłaszcza gdy tabele wymiarów i tabele faktów ulegają zmianie. Aktualizacja danych w wymiarze może być powolna i wymagać przebudowy agregacji. Pamięć ROLAP w modelu wielowymiarowym może często w przypadku dużych ilości danych powodować niską wydajność, więc czas na realizację zapytania w trybie ROLAP może być dłuższy niż czas do ponownego przetworzenia partycji MOLAP w pierwszej z opcji. Model tabelaryczny oferuje w zasadzie te same dwie opcje, ale mają one mniej wad niż ich odpowiedniki w modelu wielowymiarowym. Jeśli dane są przechowywane w mechanizmie pamięci xvelocity, aktualizacja danych w jednej tabeli nie ma wpływu na dane w pozostałych tabelach, więc czasy przetwarzania mogą być szybsze, zaś implementacja znacznie prostsza. Jeśli dane mają pozostać w mechanizmie relacyjnym, to podstawową różnicę stanowi oczekiwanie, że odpowiednik trybu ROLAP, określany jako DirectQuery, będzie działał znacznie lepiej niż ROLAP. Jest tak dlatego, że w trybie DirectQuery usługi Analysis Services próbują przenieść całe przetwarzanie zapytań z powrotem do relacyjnej bazy danych przez translację całego otrzymanego zapytania na zapytanie SQL. (Wielowymiarowy tryb ROLAP tego nie robi; przekłada niektóre wewnętrzne działania na zapytania SQL, ale część działań, takich jak wykonywanie obliczeń, wykonuje sam). Jednak DirectQuery ma także szereg ograniczeń: w trybie DirectQuery akceptuje tylko zapytania DAX, a nie MDX, co oznacza, że na przykład użytkownicy Excela nie mogą zobaczyć danych czasu rzeczywistego, gdyż Excel generuje jedynie zapytania MDX; jako źródło danych obsługiwany jest tylko SQL Server; zabezpieczenie danych musi być implementowane na serwerze SQL Server, a nie może być implementowane w Analysis Services; wreszcie ani obliczone kolumny, ani wiele popularnych funkcji DAX nie jest obsługiwanych, więc można korzystać tylko z modeli z bardzo prostymi obliczeniami DAX. Pełny opis konfiguracji trybu DirectQuery podano w rozdziale 9, Narzędzia xvelocity i DirectQuery.

38 18 Rozdział 1: Wprowadzenie do modelu tabelarycznego Narzędzia klienckie W wielu przypadkach sukces lub porażka projektu BI zależy od jakości narzędzi używanych przez użytkowników końcowych do analizy dostarczanych danych. Dlatego ważna jest odpowiedź na pytanie, jakie narzędzia klienckie obsługuje każdy z modeli. Zarówno model tabelaryczny, jak i wielowymiarowy, obsługują zapytania MDX, więc teoretycznie narzędzia klienckie Analysis Services powinny obsługiwać oba modele. Jednak w praktyce, choć niektóre narzędzia klienckie, takie jak Excel i SQL Server Reporting Services, działają tak samo dobrze w obu przypadkach, może być konieczna aktualizacja niektórych narzędzi klienckich innych dostawców, zaś nadal stosowane niektóre starsze narzędzia mogą w ogóle nie działać poprawnie. W czasie gdy ta książka była pisana, tylko model tabelaryczny obsługiwał zapytania DAX, choć ich obsługa przez model wielowymiarowy była obiecywana w przyszłości w modelu wielowymiarowym. Oznacza to, że przynajmniej na początku Power View nowe promowane przez Microsoft narzędzie wizualizacji danych będzie działać tylko w modelach tabelarycznych. Nawet gdy obsługa języka DAX w modelach wielowymiarowych zostanie wprowadzona, zapewne funkcje Power View nie będą tam działać, podobnie jak nie wszystkie funkcje modelu wielowymiarowego będą działać zgodnie z oczekiwaniami przy obsłudze zapytań za pomocą DAX. Porównanie funkcji Kolejną sprawą do rozważenia przy wyborze modelu są funkcje dostępne w modelu wielowymiarowym, które nie mają odpowiedników w modelu tabelarycznym lub są tylko w nim częściowo implementowane. Jednak nie wszystkie funkcje są ważne przy wszystkich projektach, więc trzeba stwierdzić, że w wielu scenariuszach w modelu tabelarycznym można przybliżyć niektóre funkcje modelu wielowymiarowego za pomocą sprytnego wykorzystania DAX w obliczanych kolumnach i miarach. W każdym przypadku, jeśli nie mamy doświadczenia z modelem wielowymiarowym, nie będzie nam brakować funkcji, z których nigdy nie korzystaliśmy. Oto lista najważniejszych funkcji, których brak w modelu tabelarycznym: Zapis zwrotny, możliwość zapisania przez użytkownika końcowego wartości do wielowymiarowej bazy danych. Może to być na przykład bardzo istotne w aplikacjach finansowych, gdzie użytkownik wprowadza dane budżetowe. Translacje, w których metadane modelu wielowymiarowego mogą pojawiać się w różnych językach u użytkowników korzystających z wersji lokalnych na swoich komputerach osobistych. Bezpieczeństwo miar w wymiarze, czyli funkcjonalność pozwalająca nadawać lub odbierać prawa do dostępu do pojedynczej miary. Bezpieczeństwo komórek, dzięki któremu można nadać lub odebrać prawo do dostępu do pojedynczych komórek. Nie ma możliwości implementacji takiej

39 Wybór odpowiedniego modelu dla naszego projektu 19 funkcjonalności w modelu tabelarycznym, ale funkcja ta używana jest rzadko w modelu wielowymiarowym. Zmienne hierarchie, często używana technika zapobiegająca korzystaniu z hierarchii dziecko/rodzic. W modelu wielowymiarowym hierarchia użytkownika może się upodobnić do hierarchii rodzic/dziecko poprzez ukrycie jej elementów w razie spełnienia pewnych warunków; na przykład, gdy element ma taka samą nazwę jak jego rodzic. Jest to określane jako zmienna hierarchia. W modelu tabelarycznym nie ma niczego podobnego. Wymiary pełniące rolę są raz tworzone i przetwarzane, a potem pojawiają się wiele razy w tym samym modelu pod różnymi nazwami i w różnych relacjach z grupami miar. W modelu wielowymiarowym są to wymiary pełniące rolę. Podobna konstrukcja jest możliwa w modelu tabelarycznym, dzięki czemu można tworzyć wiele relacji między dwiema tabelami (patrz rozdział 3, Ładowanie danych w modelu tabelarycznym ), ale choć funkcja jest bardzo użyteczna, nie wykonuje dokładnie tego samego zadania jak wymiar pełniący rolę. Jeśli w modelu tabelarycznym chcemy zobaczyć tę samą tabelę w dwóch miejscach jednocześnie, musimy ją dwukrotnie załadować, co wydłuża czas wykonania i utrudnia utrzymanie bazy. Przypisania w zakresach oraz działania jednoargumentowe to funkcje zaawansowanych obliczeń, dostępne w MDX w modelu wielowymiarowym, ale niemożliwe lub bardzo trudne do odtworzenia w języku DAX w modelu tabelarycznym. Te rodzaje obliczeń są często stosowane w aplikacjach finansowych, więc to i brak zapisu zwrotnego oraz rzeczywistej hierarchii rodzic/dziecko oznacza, że model tabelaryczny nie jest odpowiedni dla tego typu zastosowań. Wymienione poniższej funkcje są w modelu tabelarycznym obsługiwane tylko częściowo: Obsługa hierarchii rodzic/dziecko jest w modelu wielowymiarowym specjalnym typem hierarchii zbudowanym na podstawie tabeli wymiaru z samopołączeniem, dzięki któremu każdy wiersz tabeli reprezentuje jeden element hierarchii i ma połączenie z innym wierszem reprezentującym jego element rodzicielski w hierarchii. Hierarchie rodzic/dziecko mają w modelu wielowymiarowym wiele ograniczeń i mogą powodować problemy z wydajnością zapytań. Jednak są bardzo wygodne do modelowania hierarchii, takich jak struktury organizacyjne w przedsiębiorstwie, gdyż deweloper nie musi podczas projektowania znać maksymalnej głębokości hierarchii. Model tabelaryczny implementuje podobną funkcję za pomocą funkcji języka DAX, takich jak PATH (patrz szczegóły w rozdziale 9), ale niestety deweloper musi zdecydować o maksymalnej głębokości hierarchii w czasie projektowania.

40 20 Rozdział 1: Wprowadzenie do modelu tabelarycznego Obsługa relacji wiele-do-wielu w modelu wielowymiarowym jest jedną z najważniejszych funkcji i jest stale wykorzystywana. (Niektóre zastosowania można znaleźć w materiałach w witrynie W modelu tabelarycznym można odtworzyć tę funkcję za pomocą DAX, co opisano w rozdziale 12, Korzystanie z zaawansowanych relacji w modelu tabelarycznym, ale choć przy tym podejściu wydajność zapytań może być tak dobra jak w modelu wielowymiarowym, powoduje to znaczną komplikację budowy wyrażeń DAX używanych w miarach. Jeśli model zawiera wiele relacji wiele-do-wielu lub powiązane relacje wiele-do-wielu, ta dodatkowa złożoność może oznaczać, że utrzymanie wyrażeń DAX używanych w miarach jest niezwykle trudne. Szczegółowe przeglądanie (drillthrough) funkcja, dzięki której użytkownik może kliknąć komórkę, aby zobaczyć wszystkie szczegółowe dane, które zagregowano, aby otrzymać daną wartość. Funkcja ta jest obsługiwana w obu modelach, ale w modelu wielowymiarowym można określić, które kolumny z których wymiarów i grup miar są dzięki niej podawane. W modelu tabelarycznym nie ma interfejsu w narzędziach danych SQL Server, który by na to pozwolił, więc funkcja szczegółowego przeglądania podaje domyślnie każdą kolumnę z tabeli, na której się oparto. Można jednak ręcznie dokonać edycji definicji XMLA swego modelu, jak opisano to w poście na blogu pod adresem: marco_russo/archive/2011/08/18/drillthrough-for-bism-tabular-and-attribute-keys-in- -ssas-denali.aspx. Interfejs użytkownika do automatyzacji procesu edycji jest także dostępny w dodatku BIDS Helper ( Podsumowanie W tym rozdziale zobaczyliśmy, czym są modele tabelaryczny i wielowymiarowy w Analysis Services 2012, jakie są ich zalety i wady oraz jak należy ich używać. Kluczowym elementem do zapamiętania jest fakt, że bardzo się one różnią w zasadzie są to oddzielne produkty i nie należy podejmować decyzji o korzystaniu z modelu tabelarycznego w projekcie bez sprawdzenia, czy dobrze pasuje on do naszych wymagań. W następnym rozdziale postawimy pierwsze kroki przy budowie modeli tabelarycznych.

41 ROZDZIAŁ 2 Rozpoczęcie pracy w modelu tabelarycznym Po wstępnym zaprezentowaniu funkcji zestawu Microsoft Business Intelligence (BI), Analysis Services 2012 i modelu tabelarycznego, w tym rozdziale pokażemy, jak rozpocząć tworzenie projektu. Poznamy sposób instalacji Analysis Services, zasady pracy z projektami z użyciem narzędzi SQL Server Data Tools, podstawowe moduły modelu tabelarycznego oraz jak tworzyć i wdrażać bardzo prosty model tabelaryczny oraz jak wykonywać w nim zapytania. Określenie środowiska deweloperskiego Przed rozpoczęciem pracy z modelem tabelarycznym trzeba określić swoje środowisko deweloperskie. Komponenty środowiska deweloperskiego Środowisko deweloperskie ma trzy komponenty logiczne: deweloperska stacja robocza, serwer obszaru roboczego oraz serwer deweloperski. Każdy z tych komponentów można zainstalować na jednym komputerze lub na oddzielnych jednostkach. Każdy komponent pełni swoją rolę i musimy te role dobrze zrozumieć. Deweloperska stacja robocza Model tabelaryczny będziemy implementować na stacji roboczej. Jak wiemy, modele tabelaryczne są projektowane przy użyciu narzędzi SQL Server Data Tools (wcześniej noszących nazwę BI Development Studio, czyli BIDS); jest to Visual Studio 2010 plus kilka szablonów projektów związanych z SQL Server. Nie jest potrzebna oddzielna licencja na Visual Studio, więc można w pełni zainstalować SQL Server Data Tools za pomocą instalatora SQL Server. Jeśli mamy licencję na pełną wersję Visual Studio 2010 do wykonywania prac w środowisku.net lub innym, wtedy szablony projektów SQL Server pojawią się jako dodatkowe opcje w oknie dialogowym nowego projektu. Po zakończeniu projektowania naszego modelu tabelarycznego za pomocą SQL Server Data Tools (SSDT) trzeba zbudować i wdrożyć nasz projekt. Budowa projektu przypomina kompilację kodu: w procesie budowy następuje translacja wszystkich 21

42 22 Rozdział 2: Rozpoczęcie pracy w modelu tabelarycznym informacji zapisanych w plikach projektu na język definicji danych zwany XML for Analysis (XMLA). Wdrożenie obejmuje wówczas wykonanie pliku XMLA w ramach tabelarycznej instancji Analysis Services, działającej na naszym serwerze wdrożeniowym. Wynikiem będzie albo utworzenie nowej bazy danych, albo zmiana w bazie istniejącej. Serwer deweloperski Serwer deweloperski to serwer z zainstalowaną instancją usług Analysis Services działających w trybie tabelarycznym, którego można używać do przechowywania swoich modeli podczas ich tworzenia. Projekt wdrażamy na serwerze deweloperskim ze swojej stacji roboczej. Serwer powinien znajdować się w tej samej domenie co stacja robocza wdrażania projektu. Po wdrożeniu projektu na serwerze, my i każda osoba przez nas upoważniona możemy widzieć swój model tabelaryczny i wysyłać do niego zapytania. Jest to szczególnie ważne dla innych członków naszego zespołu, którzy tworzą raporty lub inne fragmenty naszego rozwiązania BI. Nasza stacja robocza i serwer, związane z tworzeniem projektu, mogą znajdować się na oddzielnych komputerach lub obie funkcje może spełniać jeden komputer. Z wielu powodów jest jednak lepiej, żeby funkcję serwera deweloperskiego spełniała oddzielna, dedykowana jednostka. Prawdopodobnie dedykowany serwer będzie miał znacznie lepsze parametry niż stacja robocza, zaś jak wkrótce zobaczymy w szczególności ilość dostępnej pamięci jest bardzo ważna podczas tworzenia modelu tabelarycznego. Wymagania dotyczące pamięci oznaczają, że istotne jest stosowanie systemu 64-bitowego, zaś stacja robocza może mieć nadal zainstalowaną 32-bitową wersję systemu Windows, choć dla serwerów wersja 64-bitowa jest dziś standardem. Korzystanie z oddzielnego serwera ułatwi także przydzielanie innym deweloperom, testerom i użytkownikom praw dostępu do naszych modeli tabelarycznych jeszcze w trakcie pracy nad nim. Umożliwia im to uruchamianie własnych zapytań i budowanie raportów bez przeszkadzania nam; niektóre zapytania mogą wymagać wielu zasobów, a nie chcielibyśmy, aby nasza stacja robocza zaczęła się niespodziewanie zacinać, gdy ktoś uruchomi duże zapytanie. Ponadto oczywiście nikt nie będzie w stanie uruchomić zapytania na naszej stacji roboczej, gdy ją wyłączymy i pójdziemy do domu. Dedykowany serwer umożliwi nam także zmiany modeli podczas wykonywania innej pracy. Tak jak w poprzednim punkcie, przetwarzanie dużego modelu wymaga wielu zasobów i może trwać kilka godzin. Próba wykonywania tego na własnej stacji roboczej może uniemożliwić nam jakąkolwiek inną pracę. Dedykowany serwer deweloperski będzie miał zapewne regularnie wykonywaną kopię zapasową, co zmniejszy prawdopodobieństwo utraty wyników naszej pracy w przypadku awarii sprzętowej.

43 Określenie środowiska deweloperskiego 23 Pracę bez dedykowanego serwera deweloperskiego można rozważać tylko w przypadku, jeśli brakuje nam sprzętu lub gdy nie pracujemy nad oficjalnym projektem, lecz sprawdzamy model tabelaryczny lub dokonujemy instalacji w celu kształcenia się. Serwer bazy danych obszaru roboczego Jednym ze sposobów, w jaki model tabelaryczny ułatwia nam pracę, jest podejście WYSIWYG (dostajesz to, co widzisz), więc przy każdej zmianie modelu ma ona natychmiast swoje odbicie w danych, które widzimy w SSDT, bez konieczności zapisywania lub wdrażania czegokolwiek. Jest to możliwe, gdyż SSDT ma swoją własną, prywatną tabelaryczną bazę danych, określaną jako baza danych obszaru roboczego, w której może automatycznie dokonać wdrożenia przy każdej wprowadzonej zmianie. Można traktować tę bazę danych jak rodzaj bazy danych na czas trwania prac. Ważne jest, aby nie pomylić bazy danych obszaru roboczego z tworzoną bazą danych. Tworzoną bazę danych można współdzielić z całym zespołem deweloperskim i można ją aktualizować raz, dwa razy dziennie. Natomiast baza obszaru roboczego nie powinna być nigdy przeszukiwana ani zmieniania inaczej niż przez używaną przez nas instancję SSDT. Choć tworzona baza danych może nie zawierać wszystkich danych, które docelowo będą używane w wersji produkcyjnej, ale będzie miała reprezentatywną próbkę i tak dość sporych rozmiarów. Baza danych obszaru roboczego musi być bardzo często zmieniana i może zawierać tylko niewielką ilość danych. Wreszcie, jak już wiemy, istnieje wiele powodów, dla których tworzona baza danych powinna znajdować się na oddzielnym serwerze; natomiast jest kilka istotnych powodów, dla których serwer bazy danych obszaru roboczego powinien być umieszczony na tej samej maszynie, na której tworzymy bazę. Licencje Wszystkie instalacje w środowisku tworzenia projektu muszą korzystać z wersji SQL Server Developer Edition. Wersja ta ma wszystkie funkcje wersji Enterprise Edition, ale kosztuje znacznie mniej. Jedyną niedogodnością takiej licencji jest to, że nie można z niej korzystać na serwerze produkcyjnym. Proces instalacji Nauczymy się teraz, jak instalować różne komponenty środowiska deweloperskiego. Instalacja deweloperskiej stacji roboczej Na deweloperskiej stacji roboczej trzeba zainstalować następujące aplikacje: SQL Server Data Tools i SQL Server Management Studio; dokumentację SQL Server; system kontroli źródeł oraz inne użyteczne narzędzia deweloperskie, takie jak BIDS Helper.

44 24 Rozdział 2: Rozpoczęcie pracy w modelu tabelarycznym Deweloperskie narzędzia instalacyjne Potrzebne komponenty można zainstalować na deweloperskiej stacji roboczej z poziomu instalatora SQL Server w opisany niżej sposób: 1. Logujemy się jako użytkownik z uprawnieniami administracyjnymi. 2. Klikamy dwukrotnie SETUP.EXE, aby uruchomić SQL Server Installation Center. 3. Klikamy Installation w menu z lewej strony okna, jak pokazano na rysunku 2-1. RYSUNEK 2-1 Strona SQL Server Installation Center 4. Klikamy pierwszą opcję po prawej stronie, New SQL Server Stand-Alone Installation Or Add Features To An Existing Installation (Nowa niezależna instalacja SQL Server lub dodatki do istniejącej instalacji). Kreator sprawdza zasady SQL Server Support Rules, aby stwierdzić, czy pliki pomocnicze można bez przeszkód zainstalować. 5. Jeśli wszystkie testy zakończą się pozytywnie, klikamy OK. Kreator sprawdza, czy są aktualizacje SQL Server, takie jak pakiety serwisowe, które chcielibyśmy zainstalować. 6. Zakładamy, że nie ma żadnych dodatków, więc klikamy Next (Dalej), a pliki konfiguracji zostaną zainstalowane.

45 Określenie środowiska deweloperskiego 25 Kreator sprawdza Setup Support Rules (Zasady obsługi instalacji), jak pokazano na rysunku 2-2, aby sprawdzić, czy nie występują błędy, które mogłyby spowodować niepowodzenie instalacji. Problemy trzeba rozwiązać, zanim instalacja się rozpocznie. Ostrzeżenia, które widać na rysunku 2-2 jako elementy oznaczone trójkątami, można zignorować, jeśli uważamy je za bez znaczenia. 7. Klikamy Next, aby kontynuować. RYSUNEK 2-2 Strona zasad instalacji Setup Support Rules 8. Na stronie Installation Type (Typ instalacji) wybieramy przycisk Perform A New Installation Of SQL Server 2012 (Wykonaj nową instalację SQL Server 2012), a następnie klikamy Next. 9. Na stronie Product Key (Klucz produktu), wybieramy Enter A Product Key (Wprowadź klucz produktu) i podajemy klucz do naszej licencji SQL Server Developer Edition. 10. Na stronie License Terms (Warunki licencji) zaznaczamy pole wyboru I Accept The License Terms (Akceptuję warunki licencji), a następnie klikamy Next. 11. Na stronie Setup Role (Ustawienia roli), wybieramy przycisk opcji SQL Server Feature Installation (Instalacja funkcji SQL Server), a następnie klikamy Next. 12. Na stronie Feature Selection (Wybór funkcji), zaznaczamy pola wyboru dla SSDT, Documentation Components, Management Tools Basic oraz Management Tools Complete, jak widać na rysunku 2-3.

46 26 Rozdział 2: Rozpoczęcie pracy w modelu tabelarycznym RYSUNEK 2-3 Wybór funkcji na stronie Feature Selection WAŻNE Teraz, przy instalacji serwera bazy danych obszaru roboczego na tej samej maszynie co deweloperska stacja robocza, trzeba także wykonać kroki podane w części Instalacja serwera bazy danych obszaru roboczego. 13. Na stronie Installation Rules (Zasady instalacji), jeśli zasady są spełnione, klikamy Next. 14. Na stronie Disk Space Summary (Podsumowanie pamięci dyskowej), klikamy Next, jeśli mamy dość miejsca na dysku, aby kontynuować instalację. 15. Na stronie Error Reporting (Raportowanie błędów) klikamy Next. 16. Na stronie Installation Configuration Rules (Zasady konfiguracji instalacji), jeśli zasady są spełnione, klikamy Next. 17. Na stronie Ready To Install (Gotowe do instalacji) klikamy Install (Instaluj), rozpoczynając instalację. 18. Po zakończeniu instalacji zamykamy kreator. Instalacja dokumentacji SQL Server W tym miejscu mamy gotową instalację SSDT i SQL Server Management Studio, ale nie mamy lokalnej kopii pomocy i dokumentacji. Instalacja dokumentacji oznacza, że zawsze mamy dostęp do najnowszej wersji, ale nie możemy z niej korzystać, gdy nie jesteśmy połączeni z Internetem. Podczas pierwszego użycia SQL Server Documentation zobaczymy okno dialogowe, takie jak to pokazane na rysunku 2-4.

47 Określenie środowiska deweloperskiego 27 RYSUNEK 2-4 Wybór domyślnych ustawień pomocy Jeśli klikniemy Yes (Tak), otworzy się nasza przeglądarka i zostaniemy skierowani do dokumentacji SQL Server na witrynie MSDN. Jeśli jednak spodziewamy się, że możemy w jakimś punkcie pracować offline, pomocne może być przełączenie się na pomoc offline. Można tego dokonać, klikając Manage Help Settings (Zarządzaj ustawieniami pomocy), które znajdziemy w menu Start systemu Windows. Przechodzimy do All Programs Microsoft SQL Server 2012 Documentation and Community Manage Help Settings (Wszystkie programy Microsoft SQL Server 2012 Dokumentacja i społeczność Zarządzaj ustawieniami pomocy). Uruchamia to aplikację Help Library (Biblioteka pomocy). Przejście na pomoc lokalną wymaga wykonania następujących kroków: 1. Klikamy Choose Online Or Local Help (Wybierz pomoc online lub pomoc lokalną), co widać na rysunku 2-5. RYSUNEK 2-5 Wybór Choose Online Or Local Help na stronie Help Library Manager 2. Wybieramy przycisk opcji I Want To Use Local Help (Chcę używać pomocy lokalnej), co widać na rysunku 2-6.

48 28 Rozdział 2: Rozpoczęcie pracy w modelu tabelarycznym RYSUNEK 2-6 Wybór pomocy lokalnej 3. Klikamy OK, aby wrócić do głównego menu, a następnie wybieramy Install Content From Online (Zainstaluj zawartość z sieci). Otwarte zostaje okno dialogowe Install Content From Online (Instalowanie zawartości z sieci). 4. Klikamy Add (Dodaj) przy wszystkich trzech opcjach pokazanych poniżej SQL Server 2012, co widać na rysunku 2-7. RYSUNEK 2-7 Wybór opcji na stronie Install Content From Online 5. Klikamy Update (Aktualizuj), a wtedy pakiety plików pomocy zostaną załadowane na naszą stację roboczą. 6. Klikamy Finish and Exit (Zakończ i wyjdź).

49 Określenie środowiska deweloperskiego 29 Kontrola kodu źródłowego W tym miejscu trzeba dysponować jakąś kontrolą kodu źródłowego, która daje się dobrze zintegrować z Visual Studio, jak Team Foundation Server, aby sprawdzać tworzone projekty za pomocą SSDT. Tworzenie rozwiązania BI dla Analysis Services nie różni się od innych form prac deweloperskich, więc jest niezwykle ważne, aby nasz kod źródłowy zawarty w projekcie SSDT był zapisany bezpiecznie, a także by dało się wrócić do wcześniejszych wersji po dokonaniu w projekcie zmian. Inne narzędzia Na swojej deweloperskiej stacji roboczej trzeba także zainstalować Office 2010, aby była możliwość przeglądania modelu tabelarycznego po jego wdrożeniu, ponieważ tego nie można robić w SSDT. W dalszej części rozdziału pokazano, że gdy będziemy gotowi, SSDT podejmie próbę uruchomienia aplikacji Microsoft Excel. Przeglądarka wchodząca w skład SQL Server Management Studio jest bardzo ograniczona (opiera się na sterowaniu generatorem zapytań MDX w SQL Server Reporting Services) i jest znacznie gorsza od przeglądarki kostki, która była dostępna w poprzednich wersjach SQL Server Management Studio. Ponadto na swojej deweloperskiej stacji roboczej trzeba zainstalować wymienione poniżej bezpłatne narzędzia, które zapewniają dodatkowe użyteczne funkcje. W kolejnych rozdziałach będziemy się do nich odwoływać. BIDS Helper Nagradzany darmowy dodatek do Visual Studio opracowany przez członków społeczności Microsoft BI jako rozszerzenie SSDT. Choć większość jego funkcjonalności ma zastosowanie tylko w modelu wielowymiarowym, dodano także nowe funkcje dla modelu tabelarycznego, takie jak możliwość definiowania działań. Można go załadować z witryny Rozszerzenia OLAP PivotTable Dodatek do Excela daje dodatkowe funkcje wykorzystywane przez PivotTable w połączeniu ze źródłami danych w Analysis Services. Pozwala on między innymi na obejrzenie kodu MDX wygenerowanego przez PivotTable. Można go pobrać z witryny: com/. Edytor DAX dla SQL Server Dodatek do Visual Studio przygotowany przez zespół deweloperski Analysis Services, który udostępnia w SSDT pełny edytor języka DAX. Warto zauważyć, że ten dodatek, choć został opracowany przez pracowników firmy Microsoft, nie ma oficjalnego wsparcia ze strony Microsoft. Można go pobrać z witryny BISM Normalizer Narzędzie służące do porównywania i scalania dwóch modeli tabelarycznych. Jest ono szczególnie użyteczne, gdy próbujemy połączyć ze sobą modele utworzone w PowerPivot i istniejący model tabelaryczny. Można go pobrać z witryny 5be8704f bfb9-01a78f475c64.

50 30 Rozdział 2: Rozpoczęcie pracy w modelu tabelarycznym Instalacja serwera deweloperskiego Aby na swoim serwerze deweloperskim zainstalować instancję Analysis Services w trybie tabelarycznym, trzeba wykonać wszystkie kroki do 11. włącznie, opisane w części Instalacja deweloperskiej stacji roboczej. Potem wykonujemy następujące działania: 1. Na stronie Feature Selection (Wybór funkcji), zaznaczamy pole wyboru Analysis Services, co widać na rysunku 2-8. RYSUNEK 2-8 Wybór Analysis Services na stronie Feature Selection 2. Na stronie Instance Configuration (Konfiguracja instancji) wybieramy instancję domyślną lub nazwaną, aby zainstalować instancję domyślną lub nazwaną, co widać na rysunku 2-9. Zalecana jest instancja nazwana o znaczącej nazwie (na przykład tabelaryczna), gdyż przy instalacji innej instancji Analysis Services na tym samym serwerze, lecz uruchomionej w trybie wielowymiarowym, będzie znacznie łatwiej określić, z którą instancją aktualnie się łączymy. 3. Na stronie Disk Space Requirements (Wymagania dotyczące miejsca na dysku), klikamy Next, jeśli mamy dość miejsca na dysku, aby kontynuować instalację. 4. Na stronie Server Configuration (Konfiguracja serwera), w zakładce Service Accounts (Konta usług), wprowadzamy nazwę użytkownika i hasło potrzebne potem przy uruchamianiu usługi Analysis Services Windows. Musi być to konto domeny utworzone specjalnie w tym celu.

51 Określenie środowiska deweloperskiego 31 RYSUNEK 2-9 Wybór instancji na stronie Instance Configuration 5. Na zakładce Collation (Sortowanie) wybieramy sposób porządkowania. Lepiej nie używać sortowania zależnego od wielkich i małych liter, gdyż nie będziemy musieli wtedy pamiętać tego podczas wprowadzania zapytań i obliczeń. Klikamy Next. 6. Na stronie Analysis Services Configuration (Konfiguracja Analysis Services), w zakładce Server Configuration (Konfiguracja serwera), wybieramy przycisk opcji Tabular Mode (Tryb tabelaryczny), co widać na rysunku Klikamy przycisk Add Current User (Dodaj bieżącego użytkownika) lub przycisk Add (Dodaj), aby dodać użytkownika jako administratora Analysis Services. Trzeba tu podać co najmniej jednego użytkownika. 7. Na zakładce Data Directories (Katalogi danych) możemy podać katalogi, które Analysis Services będą wykorzystywać jako katalogi Data, Log, Temp i Backup. Zaleca się, aby w tym celu utworzyć specjalne katalogi, umieszczając je na dysku o dużej pojemności, a nie na dysku C. Pozwoli to łatwiej znaleźć te katalogi, gdy będziemy chcieli sprawdzić ich rozmiar i zawartość. 8. Na stronie Error Reporting (Raportowanie błędów) klikamy Next. 9. Na stronie Installation Configuration Rules (Zasady konfiguracji instalacji), jeśli zasady są spełnione, klikamy Next. 10. Na stronie Ready To Install (Gotowe do instalacji) klikamy Install (Instaluj), rozpoczynając instalację. Po zakończeniu instalacji zamykamy kreator.

52 32 Rozdział 2: Rozpoczęcie pracy w modelu tabelarycznym RYSUNEK 2-10 Wybór zakładki Tabular Mode na stronie Analysis Services Configuration UWAGA Podczas pracy będziemy prawdopodobnie musieli mieć także dostęp do instancji mechanizmu relacyjnej bazy danych SQL Server; można rozważyć jego instalację na naszym serwerze deweloperskim. Instalacja serwera bazy danych obszaru roboczego Instalacja serwera bazy danych obszaru roboczego obejmuje podobne kroki jak instalacja serwera deweloperskiego, ale przed rozpoczęciem instalacji trzeba tu odpowiedzieć na dwa istotne pytania. Najpierw trzeba podjąć decyzję, na jakim fizycznym komputerze zainstalować serwer bazy danych obszaru roboczego. Instalacja na własnym serwerze dedykowanym byłaby marnowaniem sprzętu, ale można go zainstalować zarówno na deweloperskiej stacji roboczej, jak i na serwerze deweloperskim. Każda opcja ma swoje za i przeciw, ale na ogół zalecamy w miarę możliwości instalację na stacji roboczej. Są ku temu następujące powody: SSDT ma opcję tworzenia kopii zapasowej bazy danych obszaru roboczego podczas zapisywania projektu (aczkolwiek nie jest to opcja domyślna). Podczas tworzenia nowego projektu tabelarycznego z istniejącego skoroszytu PowerPivot można importować dane i metadane. Łatwiej jest importować dane z Excela, Microsoft Access lub z plików tekstowych.

53 Praca z narzędziami danych SQL Server 33 Drugim pytaniem jest, z jakiego konta będziemy korzystać do uruchomienia usługi Analysis Services. W poprzedniej części dla instalacji deweloperskiej bazy danych zalecano oddzielne konto w domenie; dla bazy danych obszaru roboczego wygodniejsze może być skorzystanie z konta, na które normalnie logujemy się do usługi Analysis Services. Pozwoli to instancji bazy danych obszaru roboczego na dostęp do wszystkich lokalizacji plików, do których mamy dostęp, więc będzie łatwiej wykonać kopię roboczą tych baz danych z poziomu PowerPivot. Wszystkie te możliwości są dokładnie przedstawione w poście na blogu Cathy Dumas pod adresem: -workspace-database-server.aspx. Praca z narzędziami danych SQL Server Po skonfigurowaniu środowiska deweloperskiego można zacząć korzystać z narzędzi danych SQL Server Data Tools, aby wykonać kilka zadań. Tworzenie nowego projektu Gdy wszystko jest gotowe, można zacząć budowę nowego modelu tabelarycznego. W tym celu musimy utworzyć nowy projekt w SSDT. Tego nauczymy się w tej części rozdziału. Najpierw uruchamiamy SSDT. Jeśli jest to pierwsze wykonanie, pokaże się okno dialogowe wyświetlone na rysunku 2-11, pytając nas o wybór domyślnych ustawień środowiska. Trzeba wybrać ustawienia Business Intelligence Settings (Ustawienia analizy biznesowej). RYSUNEK 2-11 Wybór ustawienia Business Intelligence Settings na stronie Default Environment Settings

54 34 Rozdział 2: Rozpoczęcie pracy w modelu tabelarycznym Po pojawieniu się strony startowej z menu File (Plik) wybieramy New Project. Pojawi się wówczas okno dialogowe pokazane na rysunku Na liście po lewej stronie Installed Templates (Zainstalowane szablony) klikamy Analysis Services, aby pokazać opcje tworzenia nowego projektu Analysis Services. RYSUNEK 2-12 Okno dialogowe New Project (Nowy projekt) Pierwsze dwie opcje z listy służą do tworzenia projektów modelu wielowymiarowego, więc je zignorujemy. Pozostają nam jeszcze trzy opcje: Analysis Services Tabular Project (Projekt tabelaryczny usług Analysis Services) Tworzy nowy, pusty projekt przeznaczony do projektowania modelu tabelarycznego. Import From PowerPivot (Importuj z programu PowerPivot) Umożliwia import modelu utworzonego za pomocą PowerPivot do nowego projektu SSDT. Import From Server (Tabular) (Importuj z serwera) Umożliwia wskazanie modelu wdrożonego wcześniej w Analysis Services i import jego metadanych do nowego projektu. Klikamy opcję Analysis Services Tabular Project, aby utworzyć nowy projekt; pozostałe dwie opcje poznamy w dalszej części rozdziału.

55 Praca z narzędziami danych SQL Server 35 Edycja projektów w trybie online Czytelnicy, którzy mają doświadczenie z wielowymiarowymi modelami Analysis Services, wiedzą, że z modelami wielowymiarowymi można pracować w SSDT także w inny sposób: w trybie online. Dzięki temu można połączyć się z wielowymiarową bazą danych, która została wcześniej wdrożona i edytować ją na serwerze w taki sposób, że każdy zapis natychmiast powoduje zmiany na serwerze. Opcja ta nie jest obsługiwana w trybie tabelarycznym i nie działa automatycznie w zakupionej wersji pakietu. Konfiguracja nowego projektu Po utworzeniu nowego projektu musimy skonfigurować różne jego właściwości. Kreator właściwości domyślnych Jeśli po raz pierwszy tworzymy nowy projekt tabelaryczny w SSDT, kreator pomaga nam w ustawieniu jednej ważnej właściwości projektu: serwer, którego chcemy używać zarówno jako domyślny serwer bazy danych obszaru roboczego, jak i domyślny serwer deweloperski, co widać na rysunku RYSUNEK 2-13 Ustawianie domyślnego serwera obszaru roboczego Jest jednak możliwe korzystanie z różnych serwerów dla bazy danych obszaru roboczego i bazy deweloperskiej; dalej pokazany jest sposób ręcznej zmiany ustawień. Właściwości projektu Właściwości projektu można ustawić, klikając prawym przyciskiem myszy nazwę projektu w oknie Solution Explorer (Eksplorator rozwiązań), a następnie wybierając Properties. Pojawia się okno dialogowe Project Properties (Właściwości projektu), pokazane na rysunku 2-14.

56 36 Rozdział 2: Rozpoczęcie pracy w modelu tabelarycznym RYSUNEK 2-14 Okno dialogowe Project Properties Trzeba ustawić podane poniżej właściwości. (Niektóre inne właściwości będą omawiane w dalszej części książki). Deployment Options\Processing Option (Opcje wdrażania\przetwarzanie opcji) Właściwość ta określa, jaki typ przetwarzania ma miejsce po wdrożeniu projektu na serwerze deweloperskim; określa, czy i w jaki sposób Analysis Services automatycznie ładuje dane do modelu po dokonaniu w nim zmian. Ustawienie domyślne, Default (Domyślny), ponownie przetwarza każdą tabelę, która nie była przetwarzana lub w której wdrożone zmiany pozostawiłyby ją w stanie nieprzetworzonym. Można także wybrać Full (Pełne), co oznacza, że cały model będzie ponownie przetwarzany. Zalecamy jednak wybranie opcji Do Not Process (Nie przetwarzaj), aby automatycznie nie wykonywać żadnego przetwarzania. Jest to lepsze, gdyż przetwarzanie dużego modelu może zająć dużo czasu, zaś często zdarza się, że chcemy wdrożyć zmiany bez przetwarzania lub przy przetworzeniu tylko wybranych tabel. Deployment Server\Server (Serwer wdrażania\serwer) Właściwość ta zawiera nazwę serwera wdrażania, na którym chcemy dokonać wdrożenia. Domyślne ustawienie jest zgodne z danymi z kreatora Default Properties Wizard (Kreator właściwości domyślnych). Nawet jeśli korzystamy z lokalnego serwera, trzeba usunąć wartość domyślną i wstawić pełną nazwę serwera deweloperskiego (w formacie nazwa_serwera\nazwa_instancji), na wypadek, gdyby model był kiedykolwiek używany na innej stacji roboczej. Deployment Server\Edition (Serwer wdrażania\wersja) Właściwość ta umożliwia ustawienie wersji SQL Server, której będziemy używać na serwerze produkcyjnym i zapobiega wdrożeniu z wykorzystaniem funkcji, które w danej wersji

57 Praca z narzędziami danych SQL Server 37 nie są dostępne. Ponieważ obecnie nie ma różnicy w funkcjach między wersjami Enterprise i Business Intelligence SQL Server jedynymi wersjami, w których dostępny jest model tabelaryczny ustawienie tej właściwości nie ma znaczenia, ale można ją ustawić na wypadek przyszłych różnic w dostępnych funkcjach. Deployment Server\Database (Serwer wdrażania\baza danych) Tu mamy nazwę bazy danych, w której wdrażamy projekt. Domyślnie jest ona ustawiona na nazwę projektu, ale nazwa bazy danych widoczna jest dla użytkowników końcowych, więc trzeba uzgodnić z nimi, jakiej nazwy chcieliby używać. Deployment Server\Cube Name (Serwer wdrażania\nazwa kostki) Tu mamy nazwę kostki, wyświetlaną we wszystkich narzędziach klienckich, które będą wydawać zapytania do modelu w MDX lub w Excelu. Domyślną nazwą jest Model, ale zaleca się zmianę tej nazwy po jej skonsultowaniu z użytkownikami końcowymi. Właściwości modelu Są też właściwości, które trzeba ustawić dla samego modelu. Można je znaleźć po kliknięciu prawym przyciskiem myszy pliku Model.bim w oknie Solution Explorer, a następnie trzeba wybrać Properties, aby wyświetlić panel znajdujący się w SSDT, co widać na rysunku RYSUNEK 2-15 Okno dialogowe Model Properties

58 38 Rozdział 2: Rozpoczęcie pracy w modelu tabelarycznym Właściwości trzeba ustawić według następujących zasad: Data Backup (Kopia zapasowa danych) Tu określa się, co się będzie działo z bazą danych obszaru roboczego po zamknięciu naszego projektu. Domyślnym ustawieniem jest Do Not Back Up To Disk (Nie wykonuj kopii zapasowej na dysku), co oznacza, że przy zamykaniu projektu nie jest zachowywana żadna kopia. Jeśli jednak pracujemy z lokalnym serwerem bazy danych obszaru roboczego, instancja tego serwera bazy danych działa na koncie z wystarczającymi uprawnieniami, aby zapisywać w katalogu projektu (jak własne konto domeny, co zalecano już w tym rozdziale), zaś ilość danych w bazie danych obszaru roboczego jest niewielka, można rozważyć zmianę tej właściwości na Back Up To Disk (Wykonaj kopię zapasową na dysku). Podczas zamykania projektu baza danych obszaru roboczego zostanie zapisana w tym samym katalogu co projekt SSDT. Powody, dla których taka sytuacja może być użyteczna, podano w poście na blogu: msdn.com/b/cathyk/archive/2011/09/20/working-with-backups-in-the-tabular-designer. aspx, jednak powody te nie są zbyt istotne, zaś tworzenie kopii zapasowej zwiększa czas potrzebny na zapisanie projektu. File Name (Nazwa pliku) Tu określa się nazwę pliku.bim naszego projektu; dalej, w punkcie Zawartość projektu tabelarycznego, jest dokładny opis tego pliku. Zmiana nazwy pliku.bim może być użyteczna, jeśli w ramach jednego rozwiązania SSDT pracujemy przy kilku projektach. Workspace Retention (Przechowywanie obszaru roboczego) Ta właściwość określa, co się dzieje z bazą danych obszaru roboczego (o nazwie podanej we właściwości tylko do odczytu, Workspace Database) na serwerze bazy, gdy zamykamy nasz projekt SSDT. Domyślne ustawienie to Unload From Memory (Zwolnij z pamięci). Baza danych zostaje odłączona, pozostając na dysku, ale nie zużywając pamięci. Gdy projekt jest ponownie otwierany, zostaje szybko ponownie podłączona. Ustawienie Keep In Memory (Zachowaj w pamięci) wskazuje, że baza danych nie zostaje odłączona i w chwili zamknięcia projektu jej stan nie ulega zmianie. Ustawienie Delete Workspace (Usuń obszar roboczy) wskazuje, że baza danych ma zostać całkowicie usunięta i przy ponownym otwarciu projektu musi zostać ponownie utworzona. Dla projektów o małym zestawie danych lub dla projektów chwilowych, tworzonych na potrzeby testowania i eksperymentalnie zaleca się ustawienie Delete Workspace, gdyż inaczej skumulujemy wiele baz danych obszaru roboczego, które zblokują serwer i zużyją przestrzeń dyskową. Jeśli pracujemy z jednym projektem lub korzystamy z wielkich ilości danych, użyteczne może być ustawienie Keep In Memory, gdyż zmniejsza ono czas potrzebny na otwarcie projektu. Workspace Server (Serwer obszaru roboczego) Tu podajemy nazwę instancji tabelarycznej Analysis Services 2012, której chcemy używać jako serwera bazy danych obszaru roboczego.

59 Praca z narzędziami danych SQL Server 39 Okno dialogowe opcji Wiele z domyślnych ustawień właściwości wymienionych powyżej można także zmienić wewnątrz SSDT, więc nie trzeba ich rekonfigurować dla każdego tworzonego projektu. Aby wykonać to zadanie, z menu Tools (Narzędzia) wybieramy Options (Opcje), aby otworzyć okno dialogowe Options, co widać na rysunku Po lewej stronie wybieramy Analysis Services\Data Modeling (Analysis Services\ Modelowanie danych), aby ustawić domyślne wartości właściwości modelu dla Workspace Server, Workspace Retention i Data Backup. Strona Analysis Services\Deployment (Analysis Services\Wdrożenie) umożliwia nam wstawienie nazwy serwera wdrożeniowego, który ma być używany domyślnie, zaś strona Business Intelligence Designers\ Analysis Services Designers\General (Projektowanie BI\Projektowanie Analysis Services\Ogólne) pozwala na ustawienie domyślnej wartości dla właściwości Deployment Server Edition (Wydanie serwera wdrażania). RYSUNEK 2-16 Okno dialogowe Options Import z PowerPivot Zamiast tworzenia pustego projektu w SSDT, można zaimportować do nowego projektu metadane, a w niektórych przypadkach także model z PowerPivot. Aby tego dokonać, tworzymy nowy projekt i w oknie dialogowym New Project (Nowy projekt) wybieramy Import From PowerPivot (Importuj z programu PowerPivot), co widać na rysunku Następnie wybieramy skoroszyt Excela zawierający model PowerPivot, który chcemy importować, a wtedy zostanie utworzony model tabelaryczny identyczny z modelem zawartym w PowerPivot. Jeśli konto usługi, z którego uruchamiamy serwer bazy danych obszaru roboczego, nie ma uprawnień do odczytu wybranego pliku, pojawi się okno dialogowe,

60 40 Rozdział 2: Rozpoczęcie pracy w modelu tabelarycznym widoczne na rysunku 2-17, wskazujące, że z modelu będą importowane tylko metadane, a nie dane. RYSUNEK 2-17 Okno dialogowe importu z PowerPivot z ostrzeżeniem Kliknięcie Yes (Tak) spowoduje utworzenie projektu baz danych. Jeśli wszystkie dane projektu PowerPivot pochodzą z zewnętrznych źródeł danych, ponowne załadowanie danych będzie względnie proste. Jeśli jednak niektóre lub wszystkie dane modelu pochodzą z samego skoroszytu, do załadowania danych trzeba wykonać większą pracę, więc może się okazać, że łatwiej będzie nadać odpowiednie uprawnienia do tego pliku kontu usługi bazy danych obszaru roboczego. Więcej informacji na ten temat można znaleźć w poście na blogu: -from-cryptic-errors-thrown-when-importing-from-powerpivot.aspx. Informacje o tym, co się dzieje w tle, gdy importujemy model PowerPivot, można znaleźć w poście na blogu: -import-from-powerpivot-actually-do.aspx. Import wdrożonego projektu z Analysis Services Nowy projekt można również utworzyć z istniejącej tabelarycznej bazy danych Analysis Services, która została wcześniej wdrożona na serwerze. Może to być pomocne, jeśli musimy szybko utworzyć kopię projektu lub jeśli projekt został utracony, zmieniony lub zepsuty, a nie korzystaliśmy z kontroli źródła. Aby wykonać to zadanie w oknie dialogowym New Project, wybieramy Import From Server (Tabular) (Importuj z serwera (tabelarycznie)), co widać na rysunku Otrzymamy prośbę o połączenie się z serwerem, a baza danych, którą chcemy importować, zostanie utworzona. Zawartość projektu tabelarycznego Trzeba znać wszystkie pliki powiązane z projektem tabelarycznym w SSDT. Pliki związane z nowym, pustym projektem można zobaczyć w okienku Solution Explorer, co widać na rysunku 2-18.

61 Praca z narzędziami danych SQL Server 41 Przycisk Show All Files Panel Solution Explorer RYSUNEK 2-18 Okienko Solution Explorer Na pierwszy rzut oka wydaje się, że projekt ma tylko jeden plik, model.bim. Jeśli jednak klikniemy przycisk Show All Files (Pokaż wszystkie pliki), w górnej części okienka Solution Explorer zobaczymy kilka innych plików i folderów (niektóre z nich tworzone są przy pierwszym tworzeniu projektu), co widać na rysunku Warto poznać te pliki. RYSUNEK 2-19 Zawartość projektu tabelarycznego

62 42 Rozdział 2: Rozpoczęcie pracy w modelu tabelarycznym Model.bim zawiera metadane projektu oraz wszelkie dane, które zostały do obiektu skopiowane lub wklejone. (Więcej na ten temat napisano w rozdziale 3, Ładowanie danych w modelu tabelarycznym ). Metadane mają postać polecenia alter XMLA alter. (XMLA jest opartym na XML językiem definiowania danych, używanym w Analysis Services). Zwróćmy uwagę, że te same metadane były używane do tworzenia bazy danych obszaru roboczego; nie muszą to być te same metadane, których używano podczas wdrażania projektu na serwerze deweloperskim. Jeśli plik Model.bim zostanie z jakiegoś powodu uszkodzony lub nie daje się otworzyć, można go odtworzyć, wykonując kroki opisane w poście na blogu: -can-t-save-the-bim-file.aspx. Pliki.asdatabase,.deploymentoptions i.deploymenttargets zawierają właściwości, które mogą być różne przy wdrażaniu projektu w lokalizacji, takiej jak serwer tworzonej bazy danych, a nie na serwerze bazy danych obszaru roboczego. Zawierają one takie właściwości, jak nazwa serwera i bazy danych do wdrożenia. Można je ustawić w oknie dialogowym Project Properties Właściwości projektu), pokazanym na rysunku Więcej informacji na temat tych plików można znaleźć pod adresem: Plik.abf file zawiera kopię zapasową bazy danych obszaru roboczego, która jest tworzona, gdy właściwość Data Backup w pliku Model.bim jest ustawiona na wartość Back Up To Disk. Plik.settings zawiera kilka właściwości, które są zapisywane na dysku przy każdym otwarciu projektu. Więcej informacji o wykorzystaniu tego pliku można znaleźć pod adresem -data-come-from-when-you-open-a-bim-file.aspx/bismdata. Jeśli chcemy zrobić kopię całego projektu SSDT za pomocą kopiowania i wklejenia jego folderu do nowej lokalizacji na dysku, musimy wyrzucić ten plik ręcznie, co szczegółowo opisano w poście na blogu: creating-a-copy-of-a-bism-tabular-project.asp. Plik.layout zawiera informacje dotyczące wielkości, położenia oraz stanu różnych okien i okienek z wnętrza SSDT w momencie zapisywania projektu. Więcej informacji na ten temat można znaleźć pod adresem archive/2011/12/03/new-for-rc0-the-layout-file.aspx. Budowa prostego modelu tabelarycznego W tej części przechodzimy proces tworzenia i wdrażania prostego modelu, aby pomóc w opanowaniu interfejsu użytkownika SSDT i zilustrować pojęcia opisane wcześniej w tym rozdziale. Jest to bardzo podstawowe wprowadzenie do tego procesu, a w dalszych rozdziałach książki kroki te zostaną przedstawione bardziej szczegółowo. Zanim

63 Budowa prostego modelu tabelarycznego 43 zaczniemy, trzeba sprawdzić, czy wszystkie konta używane do uruchamiania instancji Analysis Services w obszarze roboczym i na serwerze deweloperskim mają dostęp do instancji SQL Server i przykładowej bazy danych Works DW 2012 na naszym serwerze deweloperskim. (Adventure Works DW dla SQL Server 2012 można pobrać z Ładowanie danych do tabeli Najpierw tworzymy nowy projekt tabelaryczny w SSDT; ekran powinien przypominać to, co pokazano na rysunku 2-18 po otwarciu pliku Model.bim. Mamy teraz pusty projekt i trzeba załadować dane do jego tabeli. Z menu Model (widocznego tylko wtedy, gdy otwarty jest plik Model.bim) na górze ekranu wybieramy Import From Data Source (Importuj ze źródła danych); uruchomiony zostanie kreator Table Import Wizard (Kreator importu tabeli), co pokazano na rysunku RYSUNEK 2-20 Pierwszy krok kreatora Table Import Wizard Pod nagłówkiem Relational Databases (Relacyjne bazy danych) wybieramy Microsoft SQL Server i klikamy Next. Na następnej stronie łączymy się z bazą danych Adventure Works DW 2012 w SQL Server, co widać na rysunku Ponownie klikamy Next. W kroku Impersonation Information (Informacje o personifikacji) konfigurujemy sposób, w jaki Analysis Services będzie łączyć się z SQL Server, aby załadować dane. W tym miejscu najłatwiej jest wybrać opcję Specific Windows User Name And Password (Określ nazwę i hasło użytkownika Windows), aby

64 44 Rozdział 2: Rozpoczęcie pracy w modelu tabelarycznym wprowadzić nazwę użytkownika i hasło naszego bieżącego logowania, co widać na rysunku Pełne wyjaśnienie tego procesu można znaleźć w rozdziale 3. RYSUNEK 2-21 Sposób połączenia z SQL Server w kreatorze Table Import Wizard RYSUNEK 2-22 Sposób podania ustawień osobistych w kreatorze Table Import Wizard

65 Budowa prostego modelu tabelarycznego 45 Ponownie klikamy Next i sprawdzamy, czy wybrano opcję Select From A List Of Tables And Views (Wybierz z listy tabel i widoków), a następnie znowu klikamy Next. Następnie, w Select Tables And Views (Wybierz tabele i widoki) wybieramy tabele, zgodnie z tym, co widać na rysunku 2-23: DimProduct, DimProductCategory, DimProductSubcategory oraz FactInternetSales. RYSUNEK 2-23 Sposób wybierania tabel i widoków w kreatorze Table Import Wizard Klikamy Finish (Zakończ) i widzimy, że dane z wybranych tabel są ładowane do naszej bazy danych obszaru roboczego. Powinno to zająć jedynie kilka sekund; jeśli napotkamy tu błędy, powodem może być fakt, że używana instancja Analysis Services nie może połączyć się z bazą danych SQL Server. Aby naprawić ten błąd, musimy powtórzyć poprzednie kroki, a w kroku Impersonation Information próbujemy inną nazwę użytkownika, która ma odpowiednie uprawnienia, lub korzystamy z innego konta usług. Jeśli korzystamy z serwera obszaru roboczego na komputerze innym niż nasz komputer deweloperski, trzeba sprawdzić, czy zapory sieciowe nie blokują połączenia z Analysis Services do SQL Server oraz czy SQL Server może akceptować zdalne połączenia. Kończmy pracę w kreatorze, klikając Close (Zamknij). W tym miejscu praca w Grid View (Widok siatki) daje ekran pokazany na rysunku 2-24, na którym widać dane w tabeli w widoku siatki.

66 46 Rozdział 2: Rozpoczęcie pracy w modelu tabelarycznym Lista rozwijana kolumn Nagłówki kolumn Dane tabeli Panel właściwości (Properties) dla tabeli Przycisk Diagram View Zakładki tabel RYSUNEK 2-24 Okno Grid View Widok siatki Przycisk Grid View Dane z różnych tabel można obejrzeć, klikając zakładkę z nazwą tabeli. Wybór tabeli powoduje, że jej właściwości pojawiają się w okienku Properties. Niektóre właściwości oraz możliwość usuwania tabeli i przenoszenia jej na liście zakładek można ustawić po kliknięciu prawym przyciskiem myszy zakładki danej tabeli. Konkretną kolumnę tabeli można znaleźć za pomocą poziomego paska przewijania, znajdującego się bezpośrednio nad zakładkami tabel lub z rozwijanej listy kolumn powyżej tabeli. Aby znaleźć dane z tabeli, klikamy strzałkę w dół obok nagłówka kolumny. Przeglądanie danych umożliwia kliknięcie strzałki przy nazwie kolumny, co widać na rysunku Możemy posortować dane według wartości w kolumnie i filtrować je dzięki wybraniu lub usunięciu poszczególnych wartości lub za pomocą wbudowanych zasad filtrowania. Zwróćmy uwagę, że filtrowane są tylko dane wyświetlone na ekranie, a nie wszystkie dane zawarte w tabeli. Kliknięcie prawym przyciskiem myszy na kolumnie pozwala nam ją usunąć, zmienić jej nazwę, zablokować ją (co oznacza, że kolumna będzie zawsze widoczna, niezależnie od przewijania, podobnie jak kolumny w Excelu) oraz kopiować dane.

67 Budowa prostego modelu tabelarycznego 47 RYSUNEK 2-25 Filtrowanie kolumny w widoku Grid View Tworzenie miar Jednym z najważniejszych zadań, z których możemy korzystać w Grid View (Siatka miar), jest tworzenie miar. Jak pamiętamy, miary są zdefiniowanym sposobem agregowania danych w tabelach. Najprostszym sposobem utworzenia miary jest kliknięcie na pasku narzędzi przycisku sumy (Σ), co widać na rysunku 2-26 i utworzenie nowej miary, która sumuje wartości w kolumnie, lub kliknięcie strzałki rozwijania obok tego przycisku, aby wybrać inny rodzaj agregacji. W utworzonym właśnie modelu znajdźmy w tabeli FactInternetSales kolumnę SalesAmount i utwórzmy miarę wyznaczającą jej sumę. Po utworzeniu miary pojawia się ona w siatce miar poniżej wyróżnionej kolumny, co widać na rysunku Nazwa miary i przykładowy wynik (który stanowi zagregowana suma aktualnie wyświetlonych wierszy) są widoczne w siatce miary, zaś kliknięcie tej komórki powoduje wyświetlenie w pasku wzoru definicji tej miary w języku DAX, gdzie można ją poddać edycji. Choć domyślnie miara pojawia się w siatce miar poniżej kolumny, która była wyróżniona w momencie jej tworzenia, położenie miary w siatce jest bez znaczenia i możemy przenieść ją w inne miejsce. Ponieważ łatwo możemy pogubić się w miarach utworzonych w danym modelu, warto ustanowić standardowe położenie, w którym będziemy przechowywać swoje miary; na przykład w pierwszej kolumnie siatki miar. Aby

68 48 Rozdział 2: Rozpoczęcie pracy w modelu tabelarycznym RYSUNEK 2-26 Tworzenie miary w Grid View (Siatka miar) Definicja miary w pasku formuły Miara w siatce miar RYSUNEK 2-27 Miara w siatce miar

69 Budowa prostego modelu tabelarycznego 49 przenieść miarę w obrębie siatki miar, klikamy prawym przyciskiem myszy, wybieramy Cut (Wytnij), potem wybieramy komórkę, do której chcemy przenieść miarę i wybieramy Paste (Wklej). Warto zwrócić uwagę, że gdy wybierzemy miarę w siatce miar, w okienku Properties wyświetlane są jej właściwości. Definicje miar w pasku wzorów przyjmują postać jak niżej. <Nazwa miary name> := <Definicja DAX> Jeśli mamy do czynienia z bardziej skomplikowanymi definicjami miar, dobrym pomysłem jest zmiana wielkości paska tak, aby mógł pokazać więcej niż jeden wiersz. Podział wiersza można wstawić do wzoru za pomocą kombinacji klawiszy Shift+Enter. Pomocą w pisaniu własnych wyrażeń w języku DAX w pasku wzorów może być rozbudowana pomoc IntelliSense dla tabel, kolumn i funkcji, co widać na rysunku Gdy piszemy wyrażenie, SSDT wyświetla na rozwijanej liście znajdującej się poniżej paska wzorów listę obiektów i funkcji dostępnych w danym kontekście; wybór element z listy i naciśnięcie na klawiaturze klawisza tabulacji powoduje wstawienie obiektu lub funkcji do naszego wyrażenia w pasku wzorów. RYSUNEK 2-28 Sposób korzystania z IntelliSense podczas definiowania miary

70 50 Rozdział 2: Rozpoczęcie pracy w modelu tabelarycznym Tworzenie wyliczanych kolumn Wyliczane kolumny można w Grid View tworzyć na dwa sposoby. Pierwszym sposobem jest przewinięcie tabeli do końca w prawo, gdzie wyświetlona jest ostatnia kolumna o nazwie Add Column (Dodaj kolumnę), co widać na rysunku Wybranie tej kolumny umożliwia nam wprowadzenie do niej w pasku wzorów nowego wyrażenia DAX w pokazanej niżej postaci. = <Definicja DAX> RYSUNEK 2-29 Tworzenie wyliczanej kolumny Edycja wyrażenia DAX dotyczącego wyliczanej kolumny jest w pasku wzorów identyczna jak podczas edycji wyrażenia dla miary, jednak w obrębie wyrażenia nie można poddać edycji nazwy kolumny. IntelliSense działa tak samo jak w przypadku miar. Po wprowadzeniu wyrażenia DAX, które ma dotyczyć wyznaczanej kolumny, i naciśnięciu klawisza Enter, tworzona jest nowa wyliczana kolumna o nazwie CalculatedColumn1. Nazwę kolumny można zmienić na jakąś znaczącą, klikając dwukrotnie nagłówek kolumny i wpisując nową nazwę lub dokonując edycji właściwości Column Name (Nazwa kolumny) w okienku Properties. Inną metodą jest kliknięcie istniejącej kolumny prawym przyciskiem myszy i wybranie z menu kontekstowego pozycji Insert Column (Wstaw kolumnę). Powoduje to utworzenie nowej wyliczanej kolumny obok wybranej przez nas kolumny.