Intelligent Cube to narzędzie w Microstrategy, które pozwala na optymalizację prędkości przetwarzania danych. Dzięki niemu nie trzeba wysyłać zapytania do bazy danych za każdym razem, gdy chcemy wyświetlić dane. Dane są przechowywane w pamięci podręcznej po uruchomieniu kostki. Najczęściej wykorzystywanym typem kostki jest standardowa Intelligent Cube. Microstrategy oferuje również drugi rodzaj kostki, jakim jest Default Attribute Form Caching Intelligent Cube.
W tym przypadku (o czym wspomniane jest również w komunikacie widocznym po prawej stronie na zdjęciu powyżej), na tym typie kostki nie ma możliwości zbudowania raportu. Kostka ta również nie może być wykorzystywana jako zbiór danych do budowy dokumentu lub dossiera. Obiekt ten służy natomiast do cachowania attribute formów atrybutów które zostaną do niej dodane. W ten sposób, posiadając w projekcie taką kostkę, która zawierałaby w sobie wszystkie dostępne atrybuty, wszelkie attribute formy będą zawsze pobierane z pamięci podręcznej, jednocześnie zdecydowanie usprawniając wydajność raportów.
Aby taka kostka funkcjonowała poprawnie, należy zaznaczyć poniższe, widoczne na zdjęciu opcje na poziomie konfiguracji projektu.
W ten sposób zapewniamy możliwość tego, aby każdy raport, który zawiera w sobie wszystkie lub część atrybutów, dynamicznie wybierał źródło danych jako właśnie te przechowywane na Intelligence Serverze, za pośrednictwem naszej kostki.
Warto zwrócić uwagę, w jaki sposób taka kostka generuje SQL – jest to szereg pojedynczych zapytań „select” (jeden na każdą tabelę, z której pobierane są dane). Nie ma zatem potrzeby martwienia się o połączenia między tabelami („joiny”), oraz samą strukturę modelu.
Aby wykorzystać funkcjonalność Default Attribute Form Caching Cube należy:
1. Stworzyć kostkę, wybierając Default Attribute Form Caching Cube.
2. Wyświetli się okno edycji kostki. Warto zauważyć, że domyślnie w przypadku tej kostki wśród obiektów raportu zawsze pojawia się System Hierarchy. W przypadku pozostawienia tego obiektu, do kostki zostaną pobrane wszystkie atrybuty, wraz ze wszystkimi attribute forms jakie znajdują się na projekcie. Na potrzeby tego przykładu, System Hierarchy zostanie usunięte.
3. Kolejnym krokiem jest wybranie atrybutów, które chcemy przechowywać w kostce, oraz zadbanie o to, by miały zaznaczone attribute formy, które nas interesują.
4. Następnie należy stworzyć standardowy raport, wykorzystujący atrybuty, które zawarliśmy wcześniej w naszej kostce do cachowania. Warto zauważyć, że ma być to zwykły raport, a nie „oparty” na kostce.
5. Należy upewnić się, czy (podobnie, jak zostało to zrobione na poziomie projektu), raport również ma aktywny „dynamic sourcing”. Ustawienie znajduje się w zakładce Data > VLDB Properties.
6. Następnie po uruchomieniu kostki, oraz następnie raportu, attribute formy użytych atrybutów powinny być dynamicznie pobierane z Intelligent Servera. Wskazuje na to widoczny zapis w SQL wygenerowanego przez raport, w którym wskazana jest stworzona wcześniej kostka.
Warto zauważyć, że w żadnym z poprzednich etapów nie zostało wskazane, że nasz raport ma odnosić się do tej kostki. Dzieje się tak, ponieważ jeżeli zarówno na poziomie ustawień projektu, jak i ustawień konkretnego raportu „dynamic sourcing” jest aktywne, to raporty same będą znajdować odpowiednie Default Attribute Form Caching Cube. Jest to jednocześnie bardzo wygodny i efektywny sposób na optymalizacje prędkości zapytań, ale w związku z właśnie wspomnianym aspektem warto jest zachować szczególną ostrożność przy wykorzystywaniu Default Attribute Form Caching Cube.
Mimo szeregu zalet niesie ona również ze sobą kilka negatywów, tożsamych ze zwykłymi Intelligent Cubes, jednak biorąc pod uwagę, że działa ona na poziomie całego projektu, ich konsekwencje mogą być bardziej dotkliwe. Najbardziej istotną rzeczą, o jakiej należy pamiętać, jest to, aby zadbać o odświeżanie danych, oraz możliwie unikać wykorzystywania „default caching” w przypadku attribute formów, które ulegają częstym zmianom.
