Analizzare e pianificare l'applicazione Essbase

Per assicurarsi che l'applicazione Essbase analizzi le informazioni aziendali in modo efficiente, formulare un piano dettagliato che descriva le origini dati, le esigenze dell'utente e gli elementi di database potenziali. L'attenzione a questa fase di progettazione può farti risparmiare tempo di sviluppo e implementazione.

La fase di pianificazione e analisi prevede i seguenti compiti:

• Analizza dati di origine

• Identifica requisiti utente

• Pianificare la sicurezza in un ambiente con più utenti

• Crea modelli di database

Quando si progetta un'applicazione multidimensionale, considerare questi fattori:

• Come fluiscono le informazioni all'interno dell'azienda, chi utilizza i dati per quali scopi

• I tipi di reporting che l'azienda fa: quali tipi di dati devono essere inclusi nella struttura per soddisfare le esigenze di reporting degli utenti

  Nota

  La definizione di un solo database per applicazione migliora l'uso della memoria e la facilità di amministrazione del database.

Analizza dati di origine

Valutare i dati da includere nel database Essbase. Considera da dove proviene e la frequenza e le dimensioni richieste degli aggiornamenti. È necessario caricare in Essbase solo ciò che è necessario per il reporting pivot e il drill-through. Il resto può rimanere in una fonte relazionale, accessibile tramite partizione o drill-through.

Determinare l'ambito del database. Se un'organizzazione dispone di numerose famiglie di prodotti contenenti un numero elevato di prodotti, è possibile memorizzare i valori dei dati solo per le famiglie di prodotti. Intervista i membri di ogni reparto utente per scoprire quali dati elaborano, come calcolano e segnalano i dati oggi e come vogliono farlo in futuro.

Definire attentamente le esigenze di reporting e analisi.

• In che modo gli utenti desiderano visualizzare e analizzare i dati?

• Quanti dettagli deve contenere il database?

• I dati supportano gli obiettivi di analisi e reporting desiderati?

• In caso contrario, di quali dati aggiuntivi hai bisogno e dove puoi trovarli?

Determinare la posizione dei dati correnti.

• Dove vengono attualmente memorizzati i dati di ciascun reparto?

• I dati sono contenuti in un form utilizzabile da Essbase?

• I reparti memorizzano i dati in database relazionali su server Windows o UNIX o in fogli di calcolo Excel?

• Chi aggiorna il database e con quale frequenza?

• Chi ha bisogno di aggiornare i dati ha accesso?

Assicurarsi che i dati siano pronti per essere caricati in Essbase.

• I dati provengono da una singola origine o da più origini?

• I dati sono in un formato utilizzabile da Essbase? Per un elenco delle origini dati valide che è possibile caricare in Essbase, vedere Origini dati.

• Tutti i dati che si desidera utilizzare sono immediatamente disponibili?

Identifica requisiti utente

Quando si pianifica il database Essbase, è necessario discutere le esigenze di informazioni con gli utenti correnti dei dati e richiedere loro report di esempio. Esaminare le informazioni che utilizzano e i report che devono generare per la revisione da parte di altri utenti.

Determinare i seguenti requisiti:

• Quali tipi di analisi richiedono gli utenti?

• Gli utenti hanno bisogno di report ad hoc (stile pivot) e report strutturati?

• Di quali livelli sintetici e dettagliati di informazioni hanno bisogno gli utenti?

• Alcuni utenti richiedono l'accesso alle informazioni che gli altri utenti non dovrebbero visualizzare?

Pianificare la sicurezza in un ambiente con più utenti

Identificare i diversi livelli di esigenze di informazioni utente nell'ambito della pianificazione di come impostare le autorizzazioni di sicurezza di Essbase. Al termine dell'analisi, è necessario disporre di un elenco di utenti e delle autorizzazioni necessarie.

Utilizzare questo elenco di controllo per pianificare la sicurezza:

• Chi sono gli utenti e quali autorizzazioni dovrebbero avere per leggere o scrivere i dati nel database?

• Chi deve disporre delle autorizzazioni per il caricamento dei dati?

• Chi dovrebbe avere l'autorizzazione per eseguire i calcoli?

• A quali utenti possono essere assegnate autorizzazioni simili e raggruppate?

Vedere anche Gestire utenti e ruoli.

Crea modelli di database

Creare un modello del database Essbase. Per costruire il modello, dovrai identificare le prospettive e le opinioni che sono importanti per la tua azienda. Queste viste si traducono nelle dimensioni del modello di database.

Molte aziende analizzano le seguenti viste:

• Periodi

• Misure

• Scenari

• Products

• Clienti

• Regioni geografiche

• Business unit

Successivamente, per aiutarti a raccogliere informazioni e prendere decisioni, dovrai identificare gli obiettivi di analisi dei dati, determinare le dimensioni e i membri del database e analizzare la progettazione del database.

Identifica obiettivi analisi

Dopo aver identificato le viste principali delle informazioni in un'azienda, il passo successivo nella progettazione di un database Essbase consiste nel decidere in che modo il database abilita l'analisi dei dati. Ad esempio, potrebbe essere necessario visualizzare i dati in base al periodo di tempo, alla geografia o al tipo di prodotto.

• Se si esegue l'analisi in base al tempo, quali periodi di tempo sono necessari? L'analisi deve includere solo l'anno corrente o più anni? L'analisi deve includere dati trimestrali e mensili? Dovrebbero includere dati per stagione?

• Se si esegue l'analisi per area geografica, come si definiscono le aree? Definire le aree per aree di vendita? Definire le regioni in base ai confini geografici, ad esempio stati e città?

• Se analizza per linea di prodotti, dovrebbe esaminare i dati per ciascun prodotto? È possibile riepilogare i dati in classi di prodotti?

Indipendentemente dalle viste aziendali, è necessario determinare la prospettiva e i dettagli necessari nell'analisi. Ogni area aziendale analizzata fornisce una vista diversa dei dati.

Determinazione dimensioni e membri

Le dimensioni di Essbase scelte determinano i tipi di analisi che è possibile eseguire. All'interno di ogni dimensione, le gerarchie dei membri rappresentano aspetti dell'azienda. Ad esempio, una gerarchia temporale può includere trimestri e mesi. Una gerarchia di prodotti classifica i prodotti. Una gerarchia regionale si basa sui mercati geografici.

È possibile rappresentare ogni vista business come dimensione standard separata nel database. Puoi sentire gli analisti aziendali fare riferimento ai "bys" della loro attività, ad esempio per prodotto, per geografia e per periodo di tempo. Se è necessario analizzare una vista business per classificazione o attributo, ad esempio in base alla dimensione o al colore dei prodotti, è possibile utilizzare le dimensioni o le proprietà degli attributi per rappresentare le viste di classificazione.

È possibile utilizzare tutte le dimensioni necessarie per l'analisi. Quando sai approssimativamente quali dimensioni e membri hai bisogno, sviluppa un progetto di database provvisorio.

Dopo aver determinato le dimensioni del modello di database, scegliere gli elementi o gli elementi all'interno di ogni dimensione. Questi elementi diventano le gerarchie e i membri delle rispettive dimensioni. Ad esempio, una gerarchia temporale può includere i periodi di tempo che si desidera analizzare, ad esempio trimestri e all'interno di trimestri, mesi. Ogni trimestre e mese diventa un membro della dimensione creata per il tempo. I trimestri e i mesi rappresentano una gerarchia a due livelli di membri e relativi figli. I mesi all'interno di un trimestre possono essere consolidati in un totale per ogni trimestre.

Relazioni tra dimensioni

Considera le relazioni tra le dimensioni. La struttura di un database Essbase semplifica l'analisi delle informazioni da molte prospettive. Un analista finanziario, ad esempio, può porre le seguenti domande:

• Quali sono le vendite per un determinato mese? Come si confronta questa cifra con le vendite nello stesso mese negli ultimi cinque anni?

• In quale percentuale il margine di profitto aumenta?

• Quanto sono vicini i valori effettivi ai valori in budget?

In altre parole, l'analista potrebbe voler esaminare le informazioni da tre dimensioni: tempo, conto e scenario. Il database di esempio illustrato di seguito rappresenta queste tre dimensioni, con una dimensione rappresentata lungo ciascuno dei tre assi:

• Una dimensione tempo, che comprende Jan, Feb, Mar e il totale per Qtr1, viene visualizzata lungo l'asse X.

• Una dimensione conti, costituita da cifre contabili quali Vendite, COGS, Margine e Margine%, viene visualizzata lungo l'asse Y.

• Un'altra dimensione, che fornisce un punto di vista diverso, ad esempio Budget per i valori di budget e Effettivo per i valori effettivi, viene visualizzata lungo l'asse Z.

Figura 1-1 Cubo che rappresenta tre dimensioni del database

Le celle all'interno del cubo, in cui i membri si intersecano, contengono i dati rilevanti per tutti e tre i membri che si intersecano, ad esempio le vendite effettive a gennaio.

Esempio di struttura dimensione-membro

La tabella riportata di seguito mostra un riepilogo delle dimensioni TBC. Il designer dell'applicazione ha creato tre colonne, con le dimensioni nella colonna di sinistra e i membri nelle due colonne di destra. I membri nella colonna 3 sono sottocategorie dei membri nella colonna 2. In alcuni casi, i membri nella colonna 3 sono divisi in un altro livello di sottocategorie; ad esempio, il margine della dimensione Misure è diviso in vendite e costo merce venduta.

Tabella 1-1 Dimensioni campione TBC

Dimensioni	Membri	Membri figlio
Year	Qtr1	gen, feb, mar
Year	Trimestre 2	apr, mag, giu
Year	Trimestre 3	lug, ago, set
Year	Trimestre 4	ott, nov, dic
Misure	Profitto	Margine: vendite, costo merce venduta Totale spese: marketing, ciclo paghe, varie
Misure	Inventario	Magazzino di apertura, incrementi, magazzino finale
Misure	Rapporti	% margine, % profitto, Profitto per oncia
Product	Colas (100)	Cola (100‑10), Dieta Cola (100‑20), Cola senza caffeina (100‑30)
Product	Birra Radice (200)	Old Fashioned (200‑10), Dieta Root Beer (200‑20), Sarsaparilla (200‑30), Birra di betulla (200‑40)
Product	Soda Crema (300)	Crema Scura (300‑10), Crema Vaniglia (300‑20), Crema Dieta Soda (300‑30)
Product	Soda di frutta (400)	Uva (400‑10), Arancione (400‑20), Fragola (400‑30)
Market	East	Connecticut, Florida, Massachusetts, New Hampshire, New York
Market	Regione dell’Ovest	California, Nevada, Oregon, Utah, Washington
Market	Sud	Louisiana, Nuovo Messico, Oklahoma, Texas
Market	Centrale	Colorado, Illinois, Iowa, Missouri, Ohio, Wisconsin
Scenario	Effettivo	ND
Scenario	Budget	ND
Scenario	Varianza	ND
Scenario	% varianza	ND

Inoltre, il designer dell'applicazione ha aggiunto le seguenti dimensioni attributo per abilitare l'analisi del prodotto in base alle dimensioni e all'imballaggio:

Tabella 1-2 Dimensioni attributo campione TBC

Dimensioni	Membri	Membri figlio
Once	Grande Piccola	64.32.20 16.12
Tipo imballaggio	Bottiglia Può	ND

Elenco di controllo per la determinazione di dimensioni e membri

Per determinare le dimensioni e i membri del database dei modelli, utilizzare l'elenco di controllo riportato di seguito.

• Quali sono i candidati per le dimensioni?

• Una o più dimensioni classificano o descrivono altre dimensioni? Queste dimensioni sono candidate per le dimensioni attributo.

• Gli utenti desiderano qualificare la vista di una dimensione? Le categorie in base alle quali qualificano una dimensione sono candidate per le dimensioni attributo.

• Quali sono i candidati per i membri?

• Quanti livelli richiedono i dati?

• Come si consolidano i dati?

Analizzare la progettazione del database

Rivedere la progettazione dimensionale iniziale di Essbase in base a queste linee guida relative al numero di dimensioni, al valore analitico combinato e all'evitamento della ripetizione. L'esecuzione di questa analisi iniziale ti aiuterà a ottenere una progettazione efficiente del database che soddisfi i tuoi obiettivi di consolidamento e calcolo dei dati.

Il numero di membri necessari per descrivere un potenziale datapoint deve determinare il numero di dimensioni. Se non si è certi di dover eliminare una dimensione, conservarla e applicare altre regole di analisi finché non si è sicuri di eliminarla o conservarla.

Dimensioni dense e sparse

Le dimensioni sparse e dense influiscono sulle prestazioni. Fare riferimento a quanto riportato di seguito.

• Dimensioni sparse e dense

• Progetta un profilo per ottimizzare le prestazioni

Dimensioni standard e attributo

Per semplicità, gli esempi in questo argomento mostrano arrangiamenti alternativi per quello che inizialmente era stato progettato come due dimensioni. È possibile applicare la stessa logica a tutte le combinazioni di dimensioni.

Considera il design di un'azienda che vende prodotti a più clienti su più mercati; i mercati sono unici per ogni cliente:

             Cust A  Cust B  Cust C
New York     100     N/A     N/A
Illinois     N/A     150     N/A
California   N/A     N/A     30

Il cliente A è solo a New York, il cliente B è solo in Illinois e il cliente C è solo in California. L'azienda può definire i dati in una dimensione standard:

Market
  New York
    Cust A
  Illinois
    Cust B
  California
    Cust C

Tuttavia, se si guarda a un campione più ampio di dati, si può vedere che molti clienti possono essere in ogni mercato. Il cliente A e il cliente E sono a New York; il cliente B, il cliente M e il cliente P sono in Illinois; il cliente C e il cliente F sono in California. In questa situazione, l'azienda definisce tipicamente la dimensione grande, Cliente, come una dimensione standard e la dimensione più piccola, Mercato, come una dimensione attributo. La società associa i membri della dimensione Mercato come attributi dei membri della dimensione Cliente. I membri della dimensione Mercato descrivono le posizioni dei clienti: ogni cliente ha esattamente un mercato.

Customer (Standard dimension)
  Cust A (Attribute:New York)
  Cust B (Attribute:Illinois)
  Cust C (Attribute:California)
  Cust E (Attribute:New York)
  Cust F (Attribute:California)
  Cust M (Attribute:Illinois)
  Cust P (Attribute:Illinois)
Market (Attribute dimension)
  New York
  Illinois
  California

Considera un'altra situazione. Ancora una volta, l'azienda vende prodotti a più clienti su più mercati, ma l'azienda può vendere a un cliente che ha sedi in diversi mercati:

             Cust A  Cust B  Cust C
New York     100      75     N/A
Illinois     N/A     150     N/A
California   150     N/A      30

Il cliente A è a New York e in California. Il cliente B è a New York e Illinois. Il cliente C è solo in California. L'utilizzo di una dimensione attributo non funziona in questa situazione; un membro cliente non può avere più membri attributo. Pertanto, l'azienda progetta i dati in due dimensioni standard:

Customer
  Cust A
  Cust B
  Cust C
Market
  New York
  Illinois
  California

Combinazioni dimensioni

Rompere ogni combinazione di due dimensioni in una matrice bidimensionale. Ad esempio, le dimensioni proposte in TBC includono le seguenti combinazioni:

• Anno tra misure

• Anno nel prodotto

• Anno nel mercato

• Anno nello scenario

• Misure tra prodotti

• Misure nel mercato

• Misure nello scenario

• Mercato nel prodotto

• Mercato in uno scenario

• Scenario tra prodotti

• Once nel tipo di pacchetto

Le once e il tipo di pacchetto, come dimensioni attributo associate alla dimensione Prodotto, possono essere considerati con la dimensione Prodotto.

Per facilitare la visualizzazione di ogni dimensione, disegnare una matrice e includere alcuni membri di prima generazione. L'immagine seguente mostra un set semplificato di matrici per tre dimensioni.

Figura 1-2 Analisi delle relazioni dimensionali

Per ogni combinazione di dimensioni, porre tre domande:

• Aggiunge valore analitico?

• Aggiunge una utility per la generazione di report?

• Evita un eccesso di combinazioni inutilizzate?

Per ogni combinazione, le risposte alle domande consentono di determinare se la combinazione è valida per il database. Idealmente, la risposta a ciascuna domanda è sì. In caso contrario, considerare la possibilità di riorganizzare i dati in dimensioni più significative. Durante l'esecuzione di questo processo, discutere le esigenze di informazioni con gli utenti.

Ripetizione nei profili

La ripetizione di elementi in un contorno spesso indica la necessità di dividere le dimensioni. Gli esempi seguenti mostrano come evitare la ripetizione.

In questo esempio, la colonna a sinistra, denominata "Ripetizione", mostra Profitto, Margine, Vendite, Costo merce venduta e Spese ripetute in Budget ed Effettivo nella dimensione Conti. La colonna di destra, denominata "Nessuna ripetizione", separa Budget ed Effettivo in un'altra dimensione (Scenario), lasciando solo un set di membri Profitto, Margine, Vendite, Costo merce venduta e Spese nella dimensione Conti. Questo approccio semplifica la struttura e fornisce una visione più semplice del budget e delle cifre effettive delle altre dimensioni nel database.

Figura 1-3 Esempio di eliminazione della ripetizione mediante la creazione di una dimensione scenario

In questo esempio, la colonna di sinistra, denominata "Ripetizione", utilizza membri condivisi nella dimensione Dieta per analizzare le bevande dietetiche. I membri 100-20, 200-20 e 300-20 sono ripetuti: una volta sotto la dieta e una volta sotto i rispettivi genitori. La colonna di destra, denominata "Nessuna ripetizione", semplifica il profilo creando una dimensione attributo Diet di tipo Booleano (Vero o Falso). Tutti i membri sono mostrati solo una volta, sotto i rispettivi genitori, e sono contrassegnati con l'attributo appropriato ("Dieta: Vero" o "Dieta: Falso").

Figura 1-4 Esempio di eliminazione della ripetizione mediante la creazione di una dimensione attributo

Le dimensioni attributo forniscono inoltre funzionalità analitiche aggiuntive. Vedere Vantaggi degli attributi Essbase.

Irrilevanza interdimensionale

L'irrilevanza interdimensionale si verifica quando molti membri di una dimensione sono irrilevanti in altre dimensioni. Essbase definisce i dati irrilevanti come dati che Essbase memorizza solo a livello di riepilogo (dimensione). In questo caso, è possibile rimuovere una dimensione dal database e aggiungerne i membri a un'altra dimensione o dividerla in database separati.

Ad esempio, TBC ha preso in considerazione l'analisi degli stipendi come membro della dimensione Misure. Ma le informazioni sullo stipendio spesso si rivelano irrilevanti nel contesto di un database aziendale. La maggior parte degli stipendi sono riservati e si applicano alle persone. L'individuo e lo stipendio rappresentano in genere una cella, senza motivo di intersecarsi con qualsiasi altra dimensione.

TBC ha considerato la separazione dei dipendenti in una dimensione separata. La tabella seguente mostra un esempio di come TBC ha analizzato la dimensione Dipendente proposta per l'irrilevanza interdimensionale. I membri della dimensione Dipendente proposta (rappresentati nella riga dell'intestazione della tabella) vengono confrontati con i membri della dimensione Misure (rappresentati nella colonna più a sinistra). I membri della dimensione Misure (ad esempio Ricavi) si applicano a tutti i dipendenti. Solo la misura Stipendio è rilevante per i singoli dipendenti.

Tabella 1-3 Esempio di irrilevanza interdimensionale

	Joe Smith	Mary Jones	Mike Garcia	Tutti i dipendenti
Revenue	Irrilevanza	Irrilevanza	Irrilevanza	Pertinenza
Costi variabili	Irrilevanza	Irrilevanza	Irrilevanza	Pertinenza
COGS	Irrilevanza	Irrilevanza	Irrilevanza	Pertinenza
In fase di pubblicazione	Irrilevanza	Irrilevanza	Irrilevanza	Pertinenza
Stipendi	Pertinenza	Pertinenza	Pertinenza	Pertinenza
Costi fissi	Irrilevanza	Irrilevanza	Irrilevanza	Pertinenza
Spese	Irrilevanza	Irrilevanza	Irrilevanza	Pertinenza
Profitto	Irrilevanza	Irrilevanza	Irrilevanza	Pertinenza

Motivi per suddividere i database

Poiché le informazioni sui singoli dipendenti sono irrilevanti per le altre informazioni presenti nel database e anche perché l'aggiunta di una dimensione Dipendente aumenterebbe notevolmente le esigenze di storage del database, TBC ha creato un database HR separato. Il nuovo database HR contiene un gruppo di dimensioni correlate e include stipendi, benefit, assicurazioni e piani 401(k).

Ci sono molti motivi per dividere un database; ad esempio, supponiamo che un'azienda mantenga un database organizzativo che contiene diverse filiali internazionali in diversi fusi orari. Ogni società controllata si basa su calcoli finanziari sensibili al tempo. È possibile suddividere il database per gruppi di società controllate nello stesso fuso orario per garantire che i calcoli finanziari siano tempestivi. È anche possibile utilizzare un'applicazione partizionata per separare le informazioni per società controllata.

Lista di controllo per analizzare la progettazione del database

Utilizzare la seguente lista di controllo per analizzare la progettazione del database:

• Hai ridotto al minimo il numero di dimensioni?

• Per ogni combinazione dimensionale, ha chiesto:

  • Aggiunge valore analitico?

  • Aggiunge una utility per la generazione di report?

  • Evita un eccesso di combinazioni inutilizzate?

• Hai evitato la ripetizione nel profilo?

• Hai evitato l'irrilevanza interdimensionale?

• Hai diviso i database in base alle esigenze?