Często zdarza się, że podczas tworzenia nowego modelu Analysis Services, opieramy go bezpośrednio na tabelach w bazie danych. Takie rozwiązanie jest relatywnie mało pracochłonne, jednak po jakimś czasie może okazać się, że struktura bazy się nieco zmieniła i nasz model przestaje się procesować, rzucając jednocześnie błędami. Niestety – aby naprawić to, co zostało zepsute, czeka nas bardzo dużo pracy. Dlatego model Analysis Services warto opierać o osobną, opartą na widokach strukturę, która zabezpieczy nas przed takimi sytuacjami.
Po pierwsze - postaw na widoki!
Załóżmy, że na Twojej hurtowni danych bazować będzie kilka modeli Analysis Services, a każdy z nich będzie nieco różnił się od innych. Wymiary będą miały różne atrybuty, a w tabeli faktów nie będziemy wykorzystywać tych samych miar. Co w takiej sytuacji? Właściwie mamy dwa wyjścia – utworzyć widoki, albo bazować tylko i wyłącznie na tabelach.
Jeżeli wybierzemy drugą opcję, musimy napisać zapytanie w partycji tabeli, aby wylistować tylko te kolumny, które są nam niezbędne (optymalizacja i te sprawy :). Przy małych modelach jest to OK, ale co jeśli mamy np. 5 partycji i przyjdzie nam dodać do modelu jedną nową kolumnę? Robi się nieciekawie, tym bardziej, że prawdopodobnie za jakiś czas będziemy musieli edytować pewne dane, a przy ich dużej ilości łatwo o pomyłkę.
Może się też zdarzyć, że w naszej hurtowni zostanie zmieniona nazwa kolumny. Aby umożliwić poprawne procesowanie modelu, musimy zmienić tę nazwę w każdej partycji. Jest to dosyć pracochłonne, a co gorsze – może prowadzić do powstawania wielu błędów.
I właśnie w tym miejscu chciałbym zachęcić do budowania modelu na widokach. Taki zabieg zabezpieczy nas przed problemami, jakie mogą powodować przytoczone wyżej sytuacje. W tym przypadku, nawet jeśli zajdzie potrzeba zmiany nazwy kolumny na hurtowni, to bardzo szybko i łatwo wykonamy zmianę na widoku, bez ingerencji w model Analysis Services.
Najpierw zbuduj model na hurtowni danych
Budowę modelu Tabular zacznijmy od utworzenia widoków bazujących na tabelach. Z założenia widoki powinny być identyczne, jak docelowe tabele w Tabularze. Tę samą zasadę stosujemy także do kolumn – nawet jeśli ich nazwy zawierają spacje – możemy je tak zostawić w widoku. Dzięki temu, przy dodawaniu nowej kolumny, nie będziemy musieli zmieniać friendly name. Takie rozwiązanie ma też inne zalety – jeśli ktoś przejmie po nas projekt, będzie dokładnie wiedział, z którego pola tabeli faktów lub wymiarów pochodzą dane zawarte w konkretnej kolumnie. Warto tutaj także dodać, że kolumny i tabele techniczne możemy nazywać inaczej, na przykład z prefiksem _t, dla zaznaczenia, że np. mają być ukryte.
Kolejne zalety tworzenia widoków
Niewątpliwą zaletą jest możliwość zmiany struktury tabel. I nie chodzi tu tylko o nazwy kolumn. Zdarza się czasami, że zachodzi potrzeba dodania jakiegoś pola z innej tabeli – wtedy w widoku możemy połączyć obie tabele. Dzięki temu nie trzeba dodawać fizycznie nowej, co bywa kłopotliwe, ponieważ wymagało by to także dodania procedury do ładowania takiej tabeli.
Kolejnym plusem jest szybkie konfigurowanie zakresu, jaki chcemy ładować. Załóżmy, że potrzebujemy danych tylko od konkretnej daty. Wystarczy wtedy, w jednym miejscu w widoku, dodać klauzulę where i określić od jakiej daty mamy pobierać dane. Czasami przydaje się też sztuczka z wpisaniem where 1=0, jeśli chcemy np. pomiąć tabelę przy procesowaniu.
Ważna zaleta dla korzystających z Partition Managera
Partition Manager, podczas tworzenia nowych partycji, musi mieć szablon zapytania, z którego będzie mógł korzystać. Taki szablon często wygląda tak:
select * from widok where data >{} and data <{}
Wtedy taki szablon zawsze zostanie identyczny. Co jeśli potrzebujemy nowej kolumny? Dodajemy ją w widoku, a partycje pozostają bez zmian. Potrzebujemy usunąć kolumnę? Nie ma problemu! Chcemy mieć dane tylko z 2 spośród 5 tabel, a nie chcemy kasować tego co już jest? Dodajmy where 1=0.
Dlaczego warto korzystać z widoków?
W tym krótkim wpisie chciałem podkreślić, że warto w swojej architekturze do bazy analitycznej uwzględnić tworzenie widoków w hurtowni danych. Z mojego doświadczenia wynika, że jest to bardzo praktyczne rozwiązanie, a możliwości, jakie za sobą niesie, często okazują się bardzo istotne w najmniej spodziewanym momencie.