Pianificazione del data mart per soluzioni e scenari di pianificazione di Business Intelligence

Articolo
03/05/2017

Si applica a: SharePoint Server 2010 Enterprise

Ultima modifica dell'argomento: 2016-11-30

Contenuto dell'articolo:

Schema e layout
Modelli per la soluzione
Creazione di tabelle delle dimensioni
Creazione di tabelle delle gerarchie
Creazione di tabelle dei fatti

Schema e layout

Il data mart verrà creato utilizzando il server relazionale SQL Server 2008 R2 da utilizzare come singolo punto di registrazione per Information Worker, con tutti i dati in ingresso nel data mart rigidamente controllati. Il data mart verrà utilizzato dal server SSAS come origine dati centrale per tutti i cubi, le dimensioni e le gerarchie. Saranno necessari tre tipi di tabelle per supportare il modello di dati SSAS e includere dimensione, gerarchia e fatto.

Nota

Un cubo può utilizzare più tabelle dei fatti. Questo è possibile partizionando il gruppo di misure e utilizzando inoltre più gruppi di misure all'interno del cubo.

Verranno creati i modelli seguenti per supportare i modelli di dati necessari per il processo di pianificazione. Questi modelli determineranno il numero di tabelle presenti nel data mart.

Modelli per la soluzione

Forecast: questo modello di previsione verrà utilizzato principalmente per acquisire l'immissione dati per previsioni di entrate e spese di gestione per periodi futuri.
Account: questa dimensione di tipo conto includerà il piano dei conti con voci dettagliate su entrate e spese per la previsione.
Scenario: questa dimensione di scenario suddividerà i dati tra dati effettivi 'Actual' e dati di previsione 'Forecast'.
Time: questa dimensione temporale determinerà i periodi fiscali per la previsione.
Geography: questa dimensione geografica verrà utilizzata per controllare il processo di immissione dati da parte di ogni Information Worker. I singoli Information Worker di ogni area geografica immetteranno i dati nelle valute locali.
Product: questa dimensione di prodotto viene utilizzata per rappresentare l'elenco completo di prodotti attivi e disponibili. Le entrate previste verranno calcolate in base al prodotto.
HR Budget: questo modello verrà utilizzato dai responsabili di linea per la previsione del budget per i dipendenti previsti per l'anno fiscale. Gli Information Worker interagiranno con questo modello immettendo le ore lavorate previste e la classificazione della scala retributiva per ogni risorsa. Verrà eseguita un'analisi di simulazione per determinare il budget necessario per le paghe e gli stipendi in base a variazioni dei presupposti.
Metric: questa dimensione archivierà membri quali 'Hours Worked', 'Pay Grade', 'Total Compensation' e così via.
Geography: la posizione geografica in cui verrà inserita la risorsa.
Time: il budget per i dipendenti da prevedere a livello annuale.
Employee: un elenco di risorse esistenti e nuovi segnaposto TBH.
Pay Rates: questo modello viene utilizzato per impostare le tariffe di base per l'anno. Le informazioni relative alle tariffe verranno inserite nel modello HR Budget come dati ipotetici di base da utilizzare nei calcoli.
Time: le tariffe vengono immesse a livello annuale.
Pay Grade: un elenco di scale retributive che determineranno la retribuzione di base.
Exchange Rates: il modello dei tassi di cambio viene utilizzato per determinare le tabelle di conversione delle valute da utilizzare ogni mese per la conversione dei dati dal modello di previsione al modello di consolidamento finanziario. Poiché i dati vengono immessi in ogni area geografica con la valuta corrente, verrà utilizzata la tabella dei tassi di cambio per le regole di conversione delle valute e i pacchetti di flusso dei dati.
Time: i tassi di cambio vengono immessi per mese.
SourceCurrency: la valuta di origine di una conversione.
DestinationCurrency: la valuta di destinazione di una conversione.
Financial Consolidation: il modello di consolidamento finanziario viene utilizzato per la creazione di report finanziari con un'unica valuta per tutte le aree geografiche.
Account: il piano dei conti consolidato.
Scenario: includerà 'Actual' e 'Forecast'.
Time: il livello di granularità più basso sarà definito per mese.
Geography: tutte le aree geografiche con profitti e perdite.
Currency Type: è possibile visualizzare i dati nella valuta di dichiarazione (EUR) o nella valuta locale, nel qual caso la valuta dipenderà dall'area geografica attualmente selezionata nel filtro.

Con una buona conoscenza dei modelli necessari è possibile configurare l'archivio dati. Verranno create cinque tabelle dei fatti e le tabelle delle dimensioni e delle gerarchie appropriate. Queste tabelle verranno disposte in uno schema star con le tabelle dei fatti al centro e le tabelle delle dimensioni e delle gerarchie a formare le punte della stella dello schema "star". Definendo le relazioni mediante chiavi esterne tra le tabelle dei fatti, le dimensioni e la gerarchia nell'archivio dati, è possibile generare rapidamente la vista origine dati in SSAS quando è il momento di creare i cubi e le dimensioni.

Creazione di tabelle delle dimensioni

Le dimensioni sono i componenti di base di qualsiasi database multidimensionale. Raggruppando un insieme di dimensioni si ottiene la base generale di un cubo. Nelle tabelle delle dimensioni vengono archiviati insieme i dati di un tipo particolare. È ad esempio possibile archiviare insieme in una tabella delle dimensioni tutti i membri di tipo conto, con ogni riga della tabella a rappresentare un membro di tipo conto della dimensione univoco. Nelle tabelle delle dimensioni possono essere archiviate inoltre le proprietà correlate mediante colonne della tabella. Nella dimensione Account ad esempio è presente una colonna denominata 'AccountType' in cui è archiviato il tipo di conto specifico per il membro di dimensione.

MemberId	MemberLabel	MemberName	SortOrder	AccountType	ExpenseType
1	3100	Sales Revenue	100	Income	non applicabile
2	3200	Other Operating Revenue	200	Income	non applicabile
3	8100	Interest Revenues	300	Income	non applicabile

MemberId	MemberLabel	MemberName	SortOrder	Input Currency	Target Currency
1	SEA	Seattle	100	USD	USD
2	OLY	Olympia	200	USD	USD
3	SPK	Spokane	300	USD	USD

Suggerimento

È consigliabile creare i campi seguenti per una tabella delle dimensioni:

Id: per ottenere prestazioni ottimali, è consigliabile utilizzare chiavi delle dimensioni di tipo integer (TinyInt, SmallInt, Int, BigInt) anziché di un altro tipo. Per ulteriori informazioni, vedere la sezione relativa alle prestazioni. Utilizzare inoltre il tipo di dati più appropriato in base alla grandezza della dimensione.

Label: utilizzare un codice univoco per la visualizzazione della didascalia o del nome di un membro di dimensione. L'utilizzo di un elemento univoco consentirà di creare e modificare regole basate sul cubo tramite MdxScript, che può essere letto dagli utenti contrariamente alla specifica del membro con una notazione di valore di chiave, ad esempio '&[chiave]'.

Name: spesso gli utenti finali desiderano visualizzare i membri di una dimensione con un nome descrittivo anziché con il codice di etichetta. In questa soluzione ad esempio sono presenti codici di conto utilizzati nell'etichetta significativi per la creazione e la modifica di regole di calcolo, ma non se visualizzati in una tabella pivot. La creazione di questa proprietà consente di aggiornare facilmente i nomi visualizzati senza intervenire sulla logica sottostante delle definizioni delle regole.

Order: è opportuno disporre di una colonna di ordinamento utilizzabile dalla dimensione per determinare l'ordinamento dei membri di dimensione.

Le tabelle delle dimensioni per gli scenari di pianificazione in genere non superano 200.000 membri. Se si utilizzano dimensioni che sono aumentate in modo significativo, è consigliabile ridurre la dimensione. Tutti i dati associati ai membri di dimensione che vengono troncati possono essere aggregati e inseriti in altri membri di dimensione. Di norma, più le dimensioni sono ridotte, migliori saranno le prestazioni globali dei cubi di pianificazione.

Nota

Le colonne della dimensione e le proprietà dei membri sono strettamente correlate.

Creazione di tabelle delle gerarchie

Le tabelle delle gerarchie sono necessarie quando si utilizza la caratteristica della gerarchia padre-figlio in SSAS. Nella gerarchia padre-figlio devono essere utilizzate tre colonne, key (che rappresenta un membro della dimensione della gerarchia), parent key (un altro membro della stessa dimensione) e sort per l'ordinamento dei membri in un livello della gerarchia. La maggior parte delle gerarchie padre-figlio è supportata da queste 3 colonne, ad eccezione dei casi in cui è necessaria un'aggregazione di membri personalizzata. Per un piano dei conti ad esempio sarà necessario definire un'aggregazione personalizzata. Le aggregazioni di conti sono determinate da ogni tipo di conto del membro di tipo conto e dal membro di tipo conto padre corrispondente. Per supportare le gerarchie con aggregazione personalizzata, è necessario creare una quarta colonna, Unary Operator, in cui saranno contenuti i valori seguenti: +, - e ~ , dove + indica l'aggregazione con l'elemento padre, - indica la sottrazione dall'elemento padre e ~ indica di ignorare l'aggregazione con l'elemento padre.

Id	Parent Id	Sort Order	Unary Operator	Label	Name
1	102	100	+	3100	Sales Revenue
2	102	200	+	3200	Other Operating Revenue
3	103	300	+	8100	Interest Revenues
4	103	400	+	9100	Gain on Sale of Assets

Id	Parent Id	Sort Order	Label	Name
1	4	500	SEA	Seattle
2	4	700	OLY	Olympia
3	4	600	SPK	Spokane

Le gerarchie basate sul livello vengono create secondo le colonne definite in una dimensione. Le colonne di una tabella relazionale possono costruire gerarchie di attributi in SSAS. La definizione di relazioni tra gerarchie di attributi consentirà di creare gerarchie basate sul livello efficienti. Per il momento sarà sufficiente includere tutte le proprietà correlate di una dimensione come colonne nella tabella delle dimensioni al momento dell'elaborazione di gerarchie basate sul livello in SSAS.

Per ulteriori informazioni, vedere Gerarchie e livelli (scheda Struttura dimensione, Progettazione dimensioni) (SSAS).

Creazione di tabelle dei fatti

Nelle tabelle dei fatti vengono archiviati tutti i dati numerici di un cubo. Il numero di colonne di una tabella dei fatti dipenderà dal numero di dimensioni associate al cubo. Il cubo Forecast ad esempio include sette colonne, di cui sei rappresentano ogni dimensione correlata al cubo e una viene utilizzata per l'archiviazione del valore numerico. La colonna in cui viene archiviato il valore numerico è la colonna di tipo misura. In questa soluzione viene utilizzata una sola misura per la tabella dei fatti.

Ogni colonna, eccetto quella di tipo misura, è correlata a una dimensione mediante la relativa chiave. Nell'esempio seguente è possibile osservare come il modello HR Budget includa cinque dimensioni correlate alla tabella dei fatti e come ogni riga della tabella dei fatti rappresenti un singolo record di fatti. È consigliabile evitare valori duplicati nei record di fatti nelle chiavi di dimensioni. Se ad esempio lo stesso valore viene utilizzato in tutte le chiavi di dimensioni in più righe dei fatti, combinare il valore in un'unica riga.

Rowld	Metric ID	Geography ID	EmployeeID	TimeID	Value
1	2	15	1010	20100000	2000
2	2	15	1009	20100000	2000
3	2	15	1008	20100000	2000

Rowld	Account ID	TimeID	ScenarioID	Geography ID	ProductID	VersionID	Value
1151	1	20100200	1	1	232	1	1391
1153	1	20100400	2	1	232	1	1124
1155	1	20100600	2	1	232	1	1322