Projektowanie hierarchii wymiarów: naturalne lub nienaturalne

Question

Korzystam z usług Analysis Services i podczas projektowania wymiarów nigdy nie jestem pewien, jak daleko posunąć się do zbudowania naturalnej hierarchii.

Mam na myśli to, że dodałem wszystkie autentyczne relacje atrybutów. Zatem większość hierarchii jest naturalna, ale najczęściej żądaną hierarchią jest 3 lub więcej poziomów z średnim poziomem jako wolno zmieniającym się atrybutem.

Scenariusz to śledzenie zadań. Zadanie ma wiele atrybutów, które są statyczne, ale atrybut Dłużnik (tj. Kto płaci fakturę) może się zmienić w trakcie pracy. Więc hierarchie wyglądać następująco

- Manager -> Debtor -> Job Name 
- Director -> Debtor -> Job Name 
- Office -> Debtor -> Job Name 
- Office -> Manager -> Debtor -> Job Name 

tak w wymiarze istnieje wiele hierarchie, które zaczynają się atrybutu (ów) statycznej pracy następuje przez dłużnika (wich powoli zmienia) z nazwą pracy (kluczowy wymiar) w dół.

Tym, co teraz robimy, aby "naturalizować" te hierarchie, jest tworzenie "fałszywych" atrybutów dla każdego dłużnika, który pojawia się w hierarchii, która jest kombinacją atrybutów nad nią. na przykład dla pierwszego przykładu powyżej atrybut poziomu Dłużnika miałby klucz Menedżera i Dłużnika. I na ostatnim przykładzie poziom Menedżera miałby klucz Menedżera i Biura, a atrybut Poziomu Dłużnika miałby klucz Office, Manager & Dłużnik. Następnie ukrywamy wszystkie te atrybuty, aby były używane tylko w hierarchiach.

To sprawia, że ​​nasze wymiary są o wiele bardziej skomplikowane, ale uzyskujemy dodatkową wydajność w przypadku naszych zapytań. Często jest to zauważalna poprawa. Oprócz złożoności nieustannie napotykamy problemy, ponieważ mamy teraz wiele wersji "Dłużnika", a kluczem do atrybutu nie jest id dłużnika. Wpływa to na działania Drillthrough i Reporting, a także utrudnia pewne rodzaje obliczeń, jeśli chcemy zmienić zachowanie dla pewnych poziomów.

Klientami, których używamy są usługi Reporting Services, Excel i Office Web Components.

Powiedziano mi, że na wczesnych wersjach SQL 2005 złożone zapytania zawierające nienaturalne hierarchie mogą spowodować, że serwer zostanie całkowicie powiązany z węzłami, co jest kolejnym powodem, dla którego dołożyliśmy wszelkich starań, aby uniknąć nienaturalnej hierarchii.

Ponadto ostrzeżenie dotyczące znaku wykrzyknika jest tak dramatyczne w programie Visual Studio, że wydaje się, że nienaturalne hierachie wydaje się naprawdę złe.

Co robią inni projektanci w takich sytuacjach? Jak daleko posuwa się, aby uniknąć nienaturalnych hierarchii?

Answer 1

Sposób na tworzenie hierarchii w wolno zmieniającym się wymiarze na kostce SSAS polega na syntezie pseudo-hierarchii z rzeczywistymi kluczami ukrytymi za kulisami, ale pokazującymi atrybuty tak, jakby były kluczami.

Office  Manager DebtorKey Debtor  JobKey Job Name From  To 
Scunthorpe Bloggs  101  Scarper&Co 2001  Fixit  2010-01-01 2010-01-31 
Scunthorpe Bloggs  102  Bodgett  2002  Fixit  2010-02-01 9000-01-01 

Hierarchia zostaje zbudowana na oryginalnym powoli zmieniającym się wymiarze i służy do tworzenia relacji atrybutów. Chcesz, aby poziomy w hierarchii miały odpowiednie relacje atrybutów. IIRC są niezbędne do tego, aby kostka wykonywała optymalizację "Autoexists" (usuń nie-pustkę wyłącznie z wymiaru przed kliknięciem w tabelę faktów) - dlatego kostka jest powolna, gdy te relacje nie są skonfigurowane.

Może zajść potrzeba zastosowania hierarchii do wymiaru w SQL przed zbudowaniem kostki. Oczywiście, jeśli chcesz załadować aktualizacje, klucze muszą pozostać statyczne, chociaż jeśli masz czas na pełne odświeżenie, może nie być to konieczne.