Progettazione di gerarchie di dimensioni: naturali o innaturali

Question

Utilizzo Analysis Services e quando si progettano le quote non sono mai sicuro di quanto lontano fare per costruire le gerarchie naturali.

Ciò che intendo è che ho aggiunto in tutte le relazioni degli attributi originali. Quindi la maggior parte delle gerarchie è naturale, ma la gerarchia più comunemente richiesta è 3 o più livelli con un livello medio come attributo che cambia lentamente.

Lo scenario sta monitorando i lavori. Il lavoro ha molti attributi che sono tutti statici ma l'attributo del debitore (cioè chi paga la fattura) può cambiare nel corso del lavoro. Così le gerarchie simile a questa

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

Così all'interno della dimensione ci sono molte gerarchie che iniziano con l'attributo statico (s) del lavoro seguita da parte del debitore (wich cambia lentamente) con il nome del processo (chiave di dimensione) a il fondo.

Quindi ciò che facciamo al momento di "naturalizzare" queste gerarchie è creare attributi "falsi" per ogni debitore che appare in una gerarchia che è una combinazione degli attributi sopra di esso. per esempio. per il primo esempio sopra l'attributo del livello Debitore avrebbe una chiave di id Manager e Debitore. E per l'ultimo esempio il livello Manager avrebbe una chiave di Manager e Office e l'attributo di livello Debitore avrebbe una chiave di Office, Manager & Debitore. Nascondiamo quindi tutti questi attributi in modo che vengano utilizzati solo nelle gerarchie.

Quindi questo rende le nostre dimensioni molto più complicate ma otteniamo il vantaggio di prestazioni extra sulle nostre query. Spesso questo è un miglioramento notevole. A parte la complessità, abbiamo costantemente problemi, perché ora abbiamo più versioni di un "Debitore" e la chiave dell'attributo non è l'id del debitore. Pertanto, ciò influisce sulle azioni Drillthrough e Reporting, oltre a rendere più difficili alcuni tipi di calcolo se si desidera modificare il comportamento per determinati livelli.

I client che utilizziamo sono Reporting Services, Excel e Office Web Components.

Mi è stato detto che nelle prime versioni delle query complesse di SQL 2005 che coinvolgono gerarchie non naturali, il server poteva essere completamente legato in nodi, un'altra ragione per cui abbiamo fatto di tutto per evitare gerarchie non naturali.

Inoltre, l'avviso di design punto esclamativo è così drammatico in Visual Studio che sembra davvero una brutta cosa avere gerarchie innaturali.

Cosa fanno gli altri designer in queste situazioni? Quanto vai lontano per evitare gerarchie innaturali?

Answer 1

Il modo di fare le gerarchie in una dimensione che cambia lentamente su un cubo SSAS è di sintetizzare una pseudo-gerarchia con le chiavi reali nascoste dietro le quinte ma semplicemente mostrando gli attributi come se fossero chiavi.

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 

Questa gerarchia viene costruita sopra la dimensione originale che cambia lentamente e viene utilizzata per eseguire le relazioni di attributo. Si desidera che i livelli in una gerarchia abbiano le relazioni di attributo appropriate. IIRC sono necessari affinché il cubo faccia l'ottimizzazione 'Autoexists' (risolve la non-emptiness dalla dimensione prima di colpire la tabella dei fatti) - che è il motivo per cui il cubo è lento quando queste relazioni non sono impostate.

Potrebbe essere necessario applicare la gerarchia alla dimensione in SQL prima di costruire il cubo. Certamente, se si desidera caricare gli aggiornamenti, le chiavi dovranno rimanere statiche, sebbene se si ha il tempo di eseguire un aggiornamento completo potrebbe non essere necessario.