casa › DI › Cos'è il cubo Olap in Excel. Creazione di un progetto SSAS. Cos’è l’analisi e perché è necessaria?

Cos'è il cubo Olap in Excel. Creazione di un progetto SSAS. Cos’è l’analisi e perché è necessaria?

I sistemi informativi di un'impresa seria, di norma, contengono applicazioni progettate per l'analisi complessa dei dati, delle loro dinamiche, tendenze, ecc. Di conseguenza, il top management diventa il principale consumatore dei risultati dell’analisi. Tale analisi è in definitiva intesa a supportare il processo decisionale. E per prendere qualsiasi decisione gestionale è necessario disporre delle informazioni necessarie, solitamente quantitative. Per fare ciò, è necessario raccogliere questi dati da tutti sistemi di informazione imprese, portarli in un formato comune e poi analizzarli. A questo scopo vengono creati Data Warehouse.

Cos'è un data warehouse?

Di solito: il luogo in cui vengono raccolte tutte le informazioni di valore analitico. I requisiti per tali negozi corrispondono alla definizione classica di OLAP e verranno spiegati di seguito.

A volte il Warehouse ha un altro obiettivo: l'integrazione di tutti i dati aziendali, per mantenere l'integrità e la pertinenza delle informazioni all'interno di tutti i sistemi informativi. Quello. il repository accumula non solo le informazioni analitiche, ma quasi tutte le informazioni e può fornirle sotto forma di directory ad altri sistemi.

Un tipico data warehouse è in genere diverso da un tipico database relazionale. Innanzitutto, i database regolari sono progettati per aiutare gli utenti a svolgere il lavoro quotidiano, mentre i data warehouse sono progettati per il processo decisionale. Ad esempio, la vendita di beni e l'emissione di fatture vengono effettuate utilizzando un database progettato per l'elaborazione delle transazioni, e l'analisi delle dinamiche di vendita su più anni, che consente di pianificare il lavoro con i fornitori, viene effettuata utilizzando un data warehouse.

In secondo luogo, mentre i database tradizionali sono soggetti a continui cambiamenti man mano che gli utenti lavorano, il data warehouse è relativamente stabile: i dati in esso contenuti vengono solitamente aggiornati secondo una pianificazione (ad esempio settimanale, giornaliera o oraria, a seconda delle esigenze). Idealmente, il processo di arricchimento consiste semplicemente nell'aggiungere nuovi dati in un periodo di tempo senza modificare le informazioni precedenti già presenti nel magazzino.

E in terzo luogo, i database regolari sono molto spesso la fonte dei dati che finiscono nel magazzino. Inoltre, lo spazio di archiviazione può essere rifornito fonti esterne, ad esempio rapporti statistici.

Come si costruisce un impianto di stoccaggio?

ETL– concetto di base: tre fasi:

Estrazione: estrazione di dati da fonti esterne in un formato comprensibile;
Trasformazione – trasformazione della struttura dei dati di origine in strutture convenienti per costruire un sistema analitico;

Aggiungiamo un'altra fase: la pulizia dei dati ( Pulizia) – il processo di filtraggio di dati irrilevanti o di correzione di dati errati sulla base di metodi statistici o esperti. Per non generare successivamente rapporti come "Vendite per il 20011".

Torniamo all'analisi.

Cos’è l’analisi e perché è necessaria?

L’analisi è lo studio dei dati allo scopo di prendere decisioni. I sistemi analitici sono chiamati sistemi di supporto alle decisioni ( DSS).

Qui vale la pena sottolineare la differenza tra lavorare con DSS e un semplice insieme di report regolamentati e non regolamentati. L'analisi in DSS è quasi sempre interattiva e iterativa. Quelli. l'analista approfondisce i dati, compone e adatta le query analitiche e riceve report la cui struttura potrebbe essere sconosciuta in anticipo. Torneremo su questo argomento più in dettaglio più avanti quando discuteremo del linguaggio di query. MDX.

OLAP

I sistemi di supporto alle decisioni di solito hanno i mezzi per fornire all'utente dati aggregati per vari campioni del set originale in una forma conveniente per la percezione e l'analisi (tabelle, grafici, ecc.). L'approccio tradizionale alla segmentazione dei dati di origine prevede l'estrazione dai dati di origine di uno o più set di dati multidimensionali (spesso chiamati ipercubo o metacubo), i cui assi contengono attributi e le celle contengono dati quantitativi aggregati. (Tali dati possono anche essere archiviati in tabelle relazionali, ma in questo caso stiamo parlando dell'organizzazione logica dei dati e non dell'implementazione fisica della loro archiviazione.) Lungo ciascun asse, gli attributi possono essere organizzati sotto forma di gerarchie, che rappresentano diversi livelli di dettaglio. Grazie a questo modello dati, gli utenti possono formulare query complesse, generare report e ottenere sottoinsiemi di dati.

La tecnologia per l'analisi di dati multidimensionali complessi si chiama OLAP (On-Line Analytical Processing). OLAP è un componente chiave del data warehousing tradizionale. Il concetto di OLAP è stato descritto nel 1993 da Edgar Codd, un rinomato ricercatore di database e autore del modello di dati relazionali. Nel 1995, sulla base dei requisiti stabiliti da Codd, è stato formulato il cosiddetto test FASMI (Fast Analysis of Shared Multidimensional Information), comprendente i seguenti requisiti per le applicazioni per l'analisi multidimensionale:

fornire all'utente i risultati dell'analisi in un tempo accettabile (solitamente non superiore a 5 s), anche a costo di un'analisi meno dettagliata;
la capacità di effettuare qualsiasi analisi logica e statistica caratteristica di questa applicazione e salvandolo in un formato accessibile all'utente finale;
accesso multiutente ai dati con supporto per adeguati meccanismi di blocco e mezzi di accesso autorizzati;
rappresentazione concettuale multidimensionale dei dati, incluso supporto totale per gerarchie e gerarchie multiple (questo è un requisito fondamentale di OLAP);
la possibilità di accedere a qualsiasi informazione necessaria, indipendentemente dal suo volume e dalla posizione di archiviazione.

Va notato che la funzionalità OLAP può essere implementata diversi modi, a partire dai più semplici strumenti di analisi dei dati nelle applicazioni per ufficio e finendo con i sistemi analitici distribuiti basati su prodotti server. Quelli. OLAP non è una tecnologia, ma ideologia.

Prima di parlare delle varie implementazioni OLAP, diamo uno sguardo più da vicino a cosa sono i cubi da un punto di vista logico.

Concetti multidimensionali

Utilizzeremo il database Northwind incluso in Microsoft per illustrare i principi OLAP. server SQL e che è un tipico database che memorizza informazioni sulle operazioni commerciali di un'azienda impegnata nella fornitura all'ingrosso di prodotti alimentari. Tali dati includono informazioni su fornitori, clienti, un elenco dei beni forniti e delle loro categorie, dati sugli ordini e sulle merci ordinate, un elenco dei dipendenti dell'azienda.

Cubo

Prendiamo ad esempio la tabella Fatture1, che contiene gli ordini dell'azienda. I campi di questa tabella saranno i seguenti:

Data dell'ordine
Un paese
Città
Nome del cliente
Corriere
nome del prodotto
Quantità di merci
Prezzo dell'ordine

Quali dati aggregati possiamo ottenere da questa visualizzazione? In genere si tratta di risposte a domande come:

Qual è il valore totale degli ordini effettuati dai clienti di un determinato paese?
Qual è il valore totale degli ordini effettuati dai clienti in un determinato paese e consegnati da una determinata azienda?
Qual è il valore totale degli ordini effettuati dai clienti in un determinato paese in un dato anno e consegnati da una determinata azienda?

Tutti questi dati possono essere ottenuti da questa tabella utilizzando query SQL abbastanza ovvie con raggruppamento.

Il risultato di questa query sarà sempre una colonna di numeri e un elenco di attributi che la descrivono (ad esempio, il paese): si tratta di un set di dati unidimensionale o, in linguaggio matematico, di un vettore.

Immaginiamo di dover ottenere informazioni sul costo totale degli ordini da tutti i paesi e sulla loro distribuzione tra le società di consegna: otterremo una tabella (matrice) di numeri, in cui le società di consegna saranno elencate nelle intestazioni delle colonne, i paesi nella riga intestazioni e nelle celle ci sarà la quantità di ordini. Si tratta di un array di dati bidimensionale. Questo insieme di dati è chiamato tabella pivot ( tabella pivot) o tabella incrociata.

Se vogliamo ottenere gli stessi dati, ma anche per anno, allora apparirà un'altra modifica, ovvero il set di dati diventerà tridimensionale (un tensore condizionale del 3° ordine o un “cubo” tridimensionale).

Ovviamente, il numero massimo di dimensioni è il numero di tutti gli attributi (Data, Paese, Cliente, ecc.) che descrivono i nostri dati aggregati (quantità di ordini, numero di prodotti, ecc.).

È così che arriviamo al concetto di multidimensionalità e alla sua incarnazione - cubo multidimensionale. Chiameremo questo tavolo “ tabella dei fatti" Dimensioni o assi del cubo ( dimensioni) sono attributi le cui coordinate sono espresse dai singoli valori di tali attributi presenti nella tabella dei fatti. Quelli. ad esempio, se le informazioni sugli ordini sono state mantenute nel sistema dal 2003 al 2010, quest'anno l'asse sarà composto da 8 punti corrispondenti. Se gli ordini provengono da tre paesi, l'asse dei paesi conterrà 3 punti, ecc. Indipendentemente dal numero di paesi inclusi nella directory Paese. I punti su un asse sono chiamati i suoi “membri” ( Membri).

In questo caso, i dati aggregati stessi verranno chiamati “misure” ( Misurare). Per evitare confusione con le "dimensioni", queste ultime sono preferibilmente chiamate "assi". L'insieme delle misure forma un altro asse "Misure" ( Le misure). Ha tanti membri (punti) quante sono le misure (colonne aggregate) nella tabella dei fatti.

I membri di dimensioni o assi possono essere combinati da una o più gerarchie ( gerarchia). Spieghiamo cos'è la gerarchia con un esempio: le città degli ordini possono essere unite in distretti, i distretti in regioni, le regioni di un paese, i paesi in continenti o altre entità. Quelli. esiste una struttura gerarchica -continente- paese-regione-distretto-città– 5 livelli ( Livello). Per una regione, i dati vengono aggregati per tutte le città incluse in essa. Per una regione che comprende tutti i distretti che contengono tutte le città, ecc. Perché abbiamo bisogno di più gerarchie? Ad esempio, sull'asse delle date dell'ordine potremmo voler raggruppare i punti (cioè i giorni) in una gerarchia Anno mese giorno o da Anno-Settimana-Giorno: in entrambi i casi i livelli sono tre. Ovviamente Settimana e Mese raggruppano i giorni in modo diverso. Esistono anche gerarchie, il cui numero di livelli non è deterministico e dipende dai dati. Ad esempio, le cartelle sul disco del computer.

L'aggregazione dei dati può avvenire utilizzando diverse funzioni standard: somma, minimo, massimo, media, conteggio.

MDX

Passiamo al linguaggio di query nei dati multidimensionali.
Il linguaggio SQL è stato originariamente progettato non per i programmatori, ma per gli analisti (e quindi ha una sintassi che ricorda il linguaggio naturale). Ma col passare del tempo è diventato sempre più complicato e ora pochi analisti sanno come usarlo bene, se non del tutto. È diventato uno strumento per i programmatori. Anche il linguaggio di query MDX, che si dice sia stato sviluppato dal nostro ex connazionale Mosha (o Mosha) Posumansky nelle terre selvagge di Microsoft, era inizialmente destinato agli analisti, ma i suoi concetti e la sua sintassi (che ricorda vagamente SQL, e completamente invano, cioè perché crea solo confusione), ancora più complicato di SQL. Tuttavia, le sue basi sono ancora facili da capire.

Lo esamineremo in dettaglio perché è l'unico linguaggio che ha ricevuto lo status di standard nell'ambito dello standard generale del protocollo XMLA e in secondo luogo perché ne esiste un'implementazione open source sotto forma di progetto Mondrian dell'azienda Pentaho. Altri sistemi di analisi OLAP (ad esempio Oracle OLAP Option) utilizzano solitamente le proprie estensioni della sintassi SQL, tuttavia dichiarano anche il supporto per MDX.

Lavorare con set di dati analitici significa solo leggerli e non significa scriverli. Quello. MDX non ha clausole per la modifica dei dati, ma solo una clausola di selezione: select.

In OLAP puoi creare cubi multidimensionali fette- cioè. quando i dati vengono filtrati lungo uno o più assi, o proiezioni– quando il cubo “collassa” lungo uno o più assi, aggregando dati. Ad esempio, il nostro primo esempio con la quantità di ordini provenienti dai paesi è una proiezione del cubo sull'asse dei paesi. La query MDX per questo caso sarà simile alla seguente:

Seleziona ...Figli nelle righe da
Cosa c'è qui?

Selezionare– la parola chiave è inclusa nella sintassi esclusivamente per bellezza.
è il nome dell'asse. Tutti i nomi propri in MDX sono scritti tra parentesi quadre.
è il nome della gerarchia. Nel nostro caso, questa è la gerarchia Paese-Città
– questo è il nome del membro dell’asse al primo livello della gerarchia (cioè il paese) Tutti – questo è un meta-membro che unisce tutti i membri dell’asse. C'è un tale meta-termine in ciascun asse. Ad esempio, nell'asse dell'anno c'è "Tutti gli anni", ecc.
Bambiniè una funzione membro. Ogni membro ha diverse funzioni disponibili. Come Genitore. Livello, Gerarchia, che restituiscono rispettivamente l'antenato, il livello nella gerarchia e la gerarchia stessa a cui appartiene in questo caso il membro. Figli: restituisce un insieme di membri figli di questo membro. Quelli. nel nostro caso – paesi.
su righe– Indica come disporre questi dati nella tabella risultante. In questo caso, nell'intestazione delle righe. Valori possibili qui: su colonne, su pagine, su paragrafi, ecc. È anche possibile indicare semplicemente per indice, partendo da 0.
da– questa è l'indicazione del cubo da cui viene effettuata la selezione.

E se non avessimo bisogno di tutti i paesi, ma solo di un paio di paesi specifici? Per fare ciò possiamo specificare esplicitamente nella richiesta i paesi di cui abbiamo bisogno, invece di selezionare tutto utilizzando la funzione Bambini.

Seleziona (..., ...) sulle righe da
Le parentesi graffe in questo caso sono la dichiarazione dell'insieme ( Impostato). Un insieme è una lista, un'enumerazione di membri da un asse.

Ora scriviamo una query per il nostro secondo esempio: output nel contesto di un fattorino:

Seleziona ...Figli nelle righe .Membri nelle colonne da
Aggiunto qui:
– asse;
.Membri– una funzione dell'asse che restituisce tutti i termini su di esso. Gerarchia e livello hanno la stessa funzione. Perché C'è una sola gerarchia in questo asse, quindi la sua indicazione può essere omessa, perché anche il livello e la gerarchia sono gli stessi, quindi puoi visualizzare tutti i membri in un unico elenco.

Penso che sia già ovvio come possiamo continuare con il nostro terzo esempio con i dettagli per anno. Ma è meglio non approfondire per anno, ma filtrare, ad es. costruire una fetta Per fare ciò, scriveremo la seguente query:

Seleziona ..Figli sulle righe .Membri sulle colonne da dove (.)
Dov'è il filtraggio qui?

Dove- parola chiave
è un membro della gerarchia . Il nome completo, compresi tutti i termini, sarebbe: .. , ma perché Poiché il nome di questo membro è univoco all'interno dell'asse, tutti i chiarimenti intermedi del nome possono essere omessi.

Perché la data è tra parentesi? Le parentesi sono una tupla ( tupla). Una tupla è costituita da una o più coordinate vari assi Ad esempio, per filtrare lungo due assi contemporaneamente, tra parentesi elenchiamo due termini da diverso misure separate da virgole. Cioè, la tupla definisce una “fetta” del cubo (o un “filtro”, se tale terminologia è più vicina).

La tupla viene utilizzata per qualcosa di più del semplice filtraggio. Le tuple possono anche trovarsi nelle intestazioni di riga/colonna/pagina, ecc.

Ciò è necessario ad esempio per visualizzare il risultato di una query tridimensionale in una tabella bidimensionale.

Seleziona crossjoin (...Figli, ..Figli) sulle righe .Membri sulle colonne da dove (.)
Giunzione incrociataè una funzione. Restituisce un insieme di tuple (sì, un insieme può contenere tuple!) risultante dal prodotto cartesiano di due insiemi. Quelli. l'insieme risultante conterrà tutte le possibili combinazioni di Paesi e Anni. Le intestazioni delle righe conterranno quindi una coppia di valori: Paese-anno.

La domanda è: dov'è l'indicazione di quali caratteristiche numeriche dovrebbero essere visualizzate? In questo caso, viene utilizzata la misura predefinita definita per questo cubo, ovvero Prezzo dell'ordine. Se vogliamo derivare un'altra misura, ricordiamo che le misure sono membri di una dimensione Le misure. E agiamo esattamente come con gli altri assi. Quelli. filtrando una query in base a una delle misure verrà visualizzata esattamente questa misura nelle celle.

Domanda: Qual è la differenza tra il filtraggio in dove e il filtraggio specificando i membri dell'asse nelle righe. Risposta: praticamente nulla. Semplicemente dove è indicata una fetta per quegli assi che non partecipano alla formazione delle intestazioni. Quelli. stesso asse non può essere presente allo stesso tempo su righe, e dentro Dove.

Membri calcolati

Per più interrogazioni complesseÈ possibile dichiarare membri calcolati. Membri degli assi degli attributi e delle misure. Quelli. Puoi dichiarare, ad esempio, una nuova misura che mostrerà il contributo di ciascun paese all'importo totale degli ordini:

Con membro. as '.CurrentMember / ..', FORMAT_STRING='0.00%' seleziona ...Figli sulle righe da dove .
Il calcolo avviene nel contesto di una cella di cui sono noti tutti gli attributi delle sue coordinate. Le coordinate corrispondenti (membri) possono essere ottenute dalla funzione CurrentMember per ciascuno degli assi del cubo. Qui dobbiamo capire che l'espressione .MembroAttuale/..’ non divide un termine per un altro, ma divide dati aggregati rilevanti fette di cubo! Quelli. la fetta per il territorio corrente verrà divisa in una fetta per tutti i territori, ad es. il valore totale di tutti gli ordini. FORMAT_STRING – imposta il formato per la visualizzazione dei valori, ad es. %.

Un altro esempio di membro calcolato, ma sull'asse degli anni:

Con membro. COME '. - .'
Ovviamente il report non conterrà un'unità, ma la differenza delle sezioni corrispondenti, cioè la differenza nella quantità di ordini in questi due anni.

Visualizzazione in ROLAP

I sistemi OLAP sono in un modo o nell'altro basati su una sorta di sistema di archiviazione e organizzazione dei dati. Quando stiamo parlando di RDBMS, poi parlano di ROLAP (lasceremo MOLAP e HOLAP per autodidatta). ROLAP – OLAP su database relazionale, ovvero descritti sotto forma di ordinarie tabelle bidimensionali. I sistemi ROLAP convertono le query MDX in SQL. Il principale problema informatico per i database è la rapida aggregazione. Per aggregare più velocemente, i dati nel database sono generalmente altamente denormalizzati, vale a dire non vengono archiviati in modo molto efficiente in termini di spazio su disco occupato e monitoraggio dell'integrità del database. Inoltre contengono anche tabelle ausiliarie che memorizzano dati parzialmente aggregati. Pertanto, per OLAP, viene solitamente creato uno schema di database separato, che replica solo parzialmente la struttura dei database transazionali originali in termini di directory.

Navigazione

Molti sistemi OLAP offrono strumenti di navigazione interattivi per una query già generata (e dati di conseguenza selezionati). In questo caso viene utilizzata la cosiddetta “perforazione” o “perforazione”. Una traduzione più adeguata in russo sarebbe la parola “approfondimento”. Ma questa è una questione di gusti, in alcuni ambienti la parola “perforazione” è rimasta impressa.

Trapano– si tratta di dettagliare il report riducendo il grado di aggregazione dei dati, combinato con il filtraggio lungo qualche altro asse (o più assi). Esistono diversi tipi di perforazione:

scavare a fondo– filtraggio lungo uno degli assi sorgente del report con la visualizzazione di informazioni dettagliate sui discendenti all'interno della gerarchia del membro filtrante selezionato. Ad esempio, se è presente un report sulla distribuzione degli ordini suddiviso per Paesi e Anni, cliccando sull'anno 2007 verrà visualizzato un report suddiviso per gli stessi Paesi e mesi del 2007.
lato perforazione– filtraggio sotto uno o più assi selezionati e rimozione dell'aggregazione lungo uno o più altri assi. Ad esempio, se è presente un report sulla distribuzione degli ordini suddiviso per Paesi e Anni, cliccando sull'anno 2007 verrà visualizzato un altro report suddiviso, ad esempio, per Paesi e Fornitori con filtraggio per 2007.
trivellazione– rimuovendo l'aggregazione lungo tutti gli assi e filtrando simultaneamente lungo di essi – consente di vedere i dati di origine dalla tabella dei fatti da cui è stato ottenuto il valore nel report. Quelli. Quando fai clic sul valore di una cella, viene visualizzato un report con tutti gli ordini che hanno fornito questo importo. Una sorta di perforazione istantanea nelle “profondità” del cubo.

È tutto. Ora, se decidi di dedicarti alla Business Intelligence e all’OLAP, è il momento di iniziare a leggere letteratura seria.

Tag: aggiungi tag

Risiedo ad Habr da un po 'di tempo, ma non ho mai letto articoli sul tema dei cubi multidimensionali, OLAP e MDX, anche se l'argomento è molto interessante e diventa ogni giorno sempre più rilevante.
Non è un segreto che durante quel breve periodo di sviluppo di database, contabilità elettronica e sistemi online, si siano accumulati molti dati. Ora è interessante anche un’analisi completa degli archivi e forse un tentativo di prevedere situazioni future per modelli simili.
D’altro canto, le grandi aziende, anche nel corso di diversi anni, mesi o addirittura settimane, possono accumulare quantità di dati così grandi che anche la loro analisi di base richiede approcci straordinari e requisiti hardware rigorosi. Questi potrebbero essere sistemi di elaborazione delle transazioni bancarie, agenti di cambio, operatori telefonici eccetera.
Penso che tutti siano ben consapevoli di 2 diversi approcci alla progettazione di database: OLTP e OLAP. Il primo approccio (Online Transaction Processing - elaborazione delle transazioni in tempo reale) è progettato per un'efficiente raccolta dei dati in tempo reale, mentre il secondo (Online Analytical Processing - elaborazione analitica in tempo reale) è finalizzato specificamente al campionamento e all'elaborazione dei dati nel modo più efficiente modo.

Diamo un'occhiata alle principali capacità dei moderni cubi OLAP e quali problemi risolvono (come base vengono presi i servizi di analisi 2005/2008):

accesso veloce ai dati
preaggregazione
gerarchia
lavorare con il tempo
linguaggio di accesso ai dati multidimensionale
KPI (indicatori chiave di prestazione)
estrazione della data
memorizzazione nella cache multilivello
supporto multilingue

Diamo quindi un'occhiata più in dettaglio alle funzionalità dei cubi OLAP.

Qualcosa in più sulle possibilità

Accesso rapido ai dati
In realtà, l'accesso rapido ai dati, indipendentemente dalla dimensione dell'array, è la base dei sistemi OLAP. Poiché questo è l'obiettivo principale, un data warehouse è solitamente costruito su principi diversi da quelli dei database relazionali.
In questo caso, il tempo necessario per recuperare dati semplici viene misurato in frazioni di secondo e una query che supera pochi secondi molto probabilmente richiede un'ottimizzazione.

Preaggregazione
Oltre a recuperare rapidamente i dati esistenti, offre anche la possibilità di preaggregare i valori "con maggiore probabilità di utilizzo". Ad esempio, se disponiamo di registrazioni giornaliere delle vendite di un determinato prodotto, il sistema Forse Possiamo anche preaggregare gli importi delle vendite mensili e trimestrali, il che significa che se richiediamo dati mensilmente o trimestralmente, il sistema ci fornirà immediatamente il risultato. Perché non sempre avviene la preaggregazione? Perché le combinazioni teoricamente possibili di beni/tempo/ecc. può essercene un numero enorme, il che significa che è necessario avere regole chiare per quali elementi verrà costruita l'aggregazione e per quali no. In generale, il tema della presa in considerazione di queste regole e dell’effettiva progettazione delle aggregazioni è piuttosto ampio e meriterebbe un articolo a parte.

Gerarchie
È naturale che quando si analizzano i dati e si costruiscono rapporti finali, è necessario tenere conto del fatto che i mesi sono costituiti da giorni e essi stessi formano quarti e le città sono incluse in aree che a loro volta fanno parte di regioni o paesi . La buona notizia è questa Cubi OLAP inizialmente considerano i dati dal punto di vista delle gerarchie e delle relazioni con altri parametri della stessa entità, quindi costruire e utilizzare gerarchie nei cubi è una questione molto semplice.

Lavorare con il tempo
Poiché l'analisi dei dati avviene principalmente in aree temporali, nei sistemi OLAP viene data particolare importanza al tempo, il che significa che semplicemente definendo per il sistema in cui abbiamo il tempo qui, in futuro sarà possibile utilizzare facilmente funzioni come Year To Date, Month To Date (il periodo dall'inizio dell'anno/mese alla data corrente), Periodo parallelo (nello stesso giorno o mese, ma l'anno scorso), ecc.

Linguaggio di accesso ai dati multidimensionali
MDX(Espressioni multidimensionali) - un linguaggio di query per un accesso semplice ed efficiente a strutture di dati multidimensionali. E questo dice tutto: di seguito verranno riportati alcuni esempi.

Indicatori chiave di prestazione (KPI)
indicatore chiave di prestazioneè un sistema di misurazione finanziario e non finanziario che aiuta un'organizzazione a determinare il raggiungimento degli obiettivi strategici. Gli indicatori chiave di prestazione possono essere definiti in modo molto semplice nei sistemi OLAP e utilizzati nei report.

Data di estrazione
Estrazione dei dati(Data Mining) - essenzialmente, identificando modelli nascosti o relazioni tra variabili in set di dati di grandi dimensioni.
Il termine inglese "Data Mining" non ha una traduzione univoca in russo (data mining, data mining, information mining, estrazione di dati/informazioni), quindi nella maggior parte dei casi viene utilizzato nell'originale. La traduzione indiretta di maggior successo è il termine “data mining” (DMA). Tuttavia, questo è un argomento separato, non meno interessante da considerare.

Cache multilivello
In realtà, per garantire la massima velocità di accesso ai dati, oltre a complesse strutture e preaggregazioni di dati, i sistemi OLAP supportano il caching multilivello. Oltre a memorizzare nella cache query semplici, vengono memorizzate nella cache anche parti di dati letti dallo store, valori aggregati e valori calcolati. Pertanto, più a lungo si lavora con un cubo OLAP, più velocemente inizierà a funzionare. Esiste anche il concetto di "riscaldamento della cache", un'operazione che prepara il sistema OLAP a lavorare con report, query specifici o tutti combinati.

Supporto multilingue
Sì sì sì. Come minimo, Analysis Services 2005/2008 (anche se Enterprise Edition) supporta nativamente il multilinguismo. È sufficiente fornire una traduzione dei parametri della stringa dei tuoi dati e il cliente che ha specificato la sua lingua riceverà i dati localizzati.

Cubi multidimensionali

Allora cosa sono esattamente questi cubi multidimensionali?
Immaginiamo uno spazio tridimensionale i cui assi sono Tempo, Prodotti e Clienti.
Un punto in tale spazio indicherà il fatto che uno degli acquirenti ha acquistato un prodotto specifico in un determinato mese.

Infatti, il piano (o l'insieme di tutti questi punti) sarà il cubo e, di conseguenza, Tempo, Prodotti e Clienti saranno le sue dimensioni.
È un po 'più difficile immaginare (e disegnare) un cubo quadridimensionale o più, ma l'essenza non cambia e, soprattutto, per i sistemi OLAP non importa affatto in quante dimensioni lavorerai (entro limiti ragionevoli) limiti, ovviamente).

Un po' di MDX

Allora, qual è il bello di MDX? Molto probabilmente, è che dobbiamo descrivere non come vogliamo selezionare i dati, ma Che cosa esattamente vogliamo.
Per esempio,

SELEZIONARE
( . ) SULLE COLONNE,
( ., . ) SU RIGHE
DA
DOVE (., .)

Ciò significa che voglio il numero di iPhone venduti a giugno e luglio in Mozambico.
Allo stesso tempo descrivo Quale questi sono i dati che voglio e Come Voglio vederli nel rapporto.
Bello, non è vero?

Qui è un po' più complicato:

CON MEMBRO AverageSpend AS
. / .
SELEZIONARE
(Spesa media) SULLE COLONNE,
( .., .. ) SU RIGHE
DA
DOVE(.)
* Questo codice sorgente è stato evidenziato con Evidenziatore codice sorgente.

Infatti, prima determiniamo la formula per calcolare la “dimensione media dell'acquisto” e proviamo a confrontare chi (di quale sesso) spende più soldi in una visita allo store Apple.

La lingua in sé è estremamente interessante sia da studiare che da usare, e forse merita molte discussioni.

Conclusione

In realtà, questo articolo copre ben poco anche dei concetti di base; lo definirei un "antipasto" - un'opportunità per interessare la comunità Habra a questo argomento e svilupparlo ulteriormente. Per quanto riguarda lo sviluppo, qui c'è un enorme campo non arato e sarò felice di rispondere a tutte le tue domande.

PS Questo è il mio primo post su OLAP e la prima pubblicazione su Habré: sarei molto grato per un feedback costruttivo.
Aggiornamento: L'ho trasferito su SQL, lo trasferirò su OLAP non appena mi consentiranno di creare nuovi blog.

Tag: aggiungi tag

Nell’ambito di questo lavoro verranno presi in considerazione i seguenti temi:

Cosa sono i cubi OLAP?
Cosa sono le misure, le dimensioni, le gerarchie?
Quali tipi di operazioni possono essere eseguite sui cubi OLAP?

Il concetto di cubo OLAP

Il postulato principale di OLAP è la multidimensionalità nella presentazione dei dati. Nella terminologia OLAP, il concetto di cubo, o ipercubo, viene utilizzato per descrivere uno spazio dati discreto multidimensionale.

Cuboè una struttura dati multidimensionale da cui un utente-analista può interrogare informazioni. I cubi vengono creati da fatti e dimensioni.

Dati- si tratta di dati su oggetti ed eventi aziendali che saranno soggetti ad analisi. Fatti dello stesso tipo costituiscono misure. Una misura è il tipo di valore in una cella cubica.

Misure- questi sono i dati in base ai quali vengono analizzati i fatti. Una raccolta di tali elementi costituisce un attributo di dimensione (ad esempio, i giorni della settimana possono formare un attributo di dimensione temporale). Nelle attività di analisi aziendale per le imprese commerciali, le dimensioni spesso includono categorie come “tempo”, “vendite”, “prodotti”, “clienti”, “dipendenti”, “ubicazione geografica”. Le misurazioni sono più spesso strutture gerarchiche, che sono categorie logiche in base alle quali l'utente può analizzare i dati effettivi. Ciascuna gerarchia può avere uno o più livelli. Pertanto, la gerarchia della dimensione “localizzazione geografica” può includere i livelli: “paese - regione - città”. Nella gerarchia temporale possiamo distinguere, ad esempio, la seguente sequenza di livelli: Una dimensione può avere più gerarchie (ogni gerarchia di una dimensione deve avere lo stesso attributo chiave della tabella delle dimensioni).

Un cubo può contenere dati effettivi da una o più tabelle dei fatti e molto spesso contiene più dimensioni. Ogni dato cubo di solito ha un focus specifico per l'analisi.

La Figura 1 mostra un esempio di cubo progettato per analizzare le vendite di prodotti petroliferi da parte di una determinata azienda per regione. Questo cubo ha tre dimensioni (tempo, prodotto e regione) e una misura (volume delle vendite espresso in termini monetari). I valori delle misure vengono memorizzati nelle celle corrispondenti del cubo. Ogni cella è identificata in modo univoco da un insieme di membri di ciascuna dimensione, chiamato tupla. Ad esempio, la cella situata nell'angolo inferiore sinistro del cubo (contiene il valore $98399) è specificata dalla tupla [luglio 2005, Estremo Oriente, Diesel]. Qui il valore di $ 98.399 mostra il volume delle vendite (in termini monetari) di diesel in Estremo Oriente per luglio 2005.

Vale anche la pena notare che alcune celle non contengono alcun valore: queste celle sono vuote perché la tabella dei fatti non contiene dati per esse.

Riso. 1. Cubo con informazioni sulle vendite di prodotti petroliferi nelle varie regioni

L'obiettivo finale della creazione di tali cubi è ridurre al minimo il tempo di elaborazione delle query che estraggono le informazioni richieste dai dati effettivi. Per eseguire questa attività, i cubi in genere contengono totali precalcolati chiamati aggregazioni(aggregazioni). Quelli. il cubo copre uno spazio dati più grande di quello reale: contiene punti logici e calcolati. Le funzioni di aggregazione consentono di calcolare i valori dei punti nello spazio logico in base ai valori effettivi. Le funzioni di aggregazione più semplici sono SUM, MAX, MIN, COUNT. Quindi, ad esempio, utilizzando la funzione MAX, per il cubo riportato nell'esempio, è possibile individuare quando si è verificato il picco delle vendite di gasolio in Estremo Oriente, ecc.

Un'altra caratteristica specifica dei cubi multidimensionali è la difficoltà di determinarne l'origine. Ad esempio, come si imposta il punto 0 per la dimensione Prodotto o Regioni? La soluzione a questo problema è introdurre un attributo speciale che combini tutti gli elementi della dimensione. Questo attributo (creato automaticamente) contiene un solo elemento: Tutti. Per funzioni di aggregazione semplici come sum, l'elemento All equivale alla somma dei valori di tutti gli elementi nello spazio reale di una determinata dimensione.

Un concetto importante in un modello di dati multidimensionale è il sottospazio, o sottocubo. Un sottocubo è una parte dell'intero spazio di un cubo sotto forma di una figura multidimensionale all'interno del cubo. Poiché lo spazio multidimensionale di un cubo è discreto e limitato, anche il sottocubo è discreto e limitato.

Operazioni sui cubi OLAP

Su un cubo OLAP è possibile eseguire le seguenti operazioni:

fetta;
rotazione;
consolidamento;
dettagli.

Fetta(Figura 2) è un caso speciale di sottocubo. Questa è una procedura per formare un sottoinsieme di un array di dati multidimensionale corrispondente a un singolo valore di uno o più elementi di dimensione non inclusi in questo sottoinsieme. Ad esempio, per scoprire come sono andate nel tempo le vendite di prodotti petroliferi solo in una determinata regione, precisamente negli Urali, è necessario fissare la dimensione “Prodotti” sull’elemento “Ural” ed estrarre il corrispondente sottoinsieme (sottocubo) dal cubo.

Riso. 2. Fetta del cubo OLAP

Rotazione(Figura 3) - l'operazione di modifica della posizione delle misurazioni presentate in un report o nella pagina visualizzata. Ad esempio, un'operazione di rotazione può comportare la riorganizzazione delle righe e delle colonne di una tabella. Inoltre, la rotazione di un cubo di dati sposta le dimensioni fuori tabella in posizione con le dimensioni presenti nella pagina visualizzata e viceversa.

In generale, ogni specialista sa cos'è OLAP oggi. Almeno, i concetti di “OLAP” e “dati multidimensionali” sono saldamente collegati nelle nostre menti. Tuttavia, il fatto che questo argomento venga sollevato di nuovo, spero, sarà approvato dalla maggioranza dei lettori, perché affinché l'idea di qualcosa non diventi obsoleta nel tempo, è necessario comunicare periodicamente con persone intelligenti o leggere articoli in una buona pubblicazione...

Data warehouse (posto di OLAP nella struttura informativa dell'impresa)

Il termine "OLAP" è indissolubilmente legato al termine "data warehouse" (Data Warehouse).

Ecco la definizione formulata dal “padre fondatore” del data warehousing, Bill Inmon: “Un data warehouse è una raccolta di dati immutabile, specifica per un dominio e limitata nel tempo, per supportare il processo decisionale del management”.

I dati nel magazzino provengono da sistemi operativi (sistemi OLTP), progettati per automatizzare i processi aziendali. Inoltre, il repository può essere rifornito da fonti esterne, come i rapporti statistici.

Perché costruire data warehouse: dopo tutto contengono informazioni ovviamente ridondanti che già "vivono" nei database o nei file del sistema operativo? La risposta può essere breve: è impossibile o molto difficile analizzare direttamente i dati dei sistemi operativi. Ciò è dovuto a vari motivi, tra cui la frammentazione dei dati, la loro archiviazione in diversi formati DBMS e in diversi “corner” rete aziendale. Ma anche se un’azienda archivia tutti i suoi dati su un server di database centrale (cosa estremamente rara), un analista quasi certamente non ne capirà le strutture complesse, a volte confuse. L'autore ha un'esperienza piuttosto triste nel cercare di "nutrire" analisti affamati con dati "grezzi" provenienti da sistemi operativi: si è rivelato "troppo per loro".

Pertanto, lo scopo del repository è quello di fornire le “materie prime” per l’analisi in un unico posto e in una struttura semplice e comprensibile. Ralph Kimball, nella prefazione al suo libro "The Data Warehouse Toolkit", scrive che se, dopo aver letto l'intero libro, il lettore capisce solo una cosa - cioè che la struttura del magazzino dovrebbe essere semplice - l'autore considererà la sua compito completato.

C'è un'altra ragione che giustifica la comparsa di un repository separato: complesse query analitiche informazioni operative rallentare lavoro attuale aziende, bloccando tavoli per lungo tempo e sequestrando le risorse del server.

A mio avviso, un repository non significa necessariamente un gigantesco accumulo di dati: l'importante è che sia conveniente per l'analisi. In generale, esiste un termine separato per le piccole strutture di archiviazione: Data Mart (chioschi dati), ma nella nostra pratica russa non lo senti spesso.

OLAP: un comodo strumento di analisi

La centralizzazione e una strutturazione conveniente non sono tutto ciò di cui un analista ha bisogno. Ha ancora bisogno di uno strumento per visualizzare e visualizzare le informazioni. I report tradizionali, anche quelli basati su un unico repository, mancano di una cosa: la flessibilità. Non possono essere "ruotati", "espansi" o "compressi" per ottenere la visualizzazione desiderata dei dati. Naturalmente, puoi chiamare un programmatore (se vuole venire), e lui (se non è occupato) farà un nuovo rapporto abbastanza velocemente - diciamo, entro un'ora (sto scrivendo questo e non ci credo lo stesso - non succede così in fretta nella vita; diamogli tre ore). Si scopre che un analista non può testare più di due idee al giorno. E lui (se è un buon analista) può inventare diverse idee simili all'ora. E più “fette” e “sezioni” di dati vede l’analista, più idee ha, le quali, a loro volta, richiedono sempre più “fette” per la verifica. Se solo avesse uno strumento che gli permettesse di espandere e comprimere i dati in modo semplice e conveniente! OLAP funge da tale strumento.

Sebbene OLAP non sia un attributo necessario di un data warehouse, viene sempre più utilizzato per analizzare le informazioni accumulate nel data warehouse.

I componenti inclusi in un tipico repository sono mostrati in Fig. 1.

Riso. 1. Struttura del data warehouse

I dati operativi vengono raccolti da varie fonti, puliti, integrati e archiviati in un negozio relazionale. Inoltre, sono già disponibili per l'analisi utilizzando vari strumenti di reporting. Quindi i dati (totalmente o parzialmente) vengono preparati per l'analisi OLAP. Possono essere caricati in uno speciale database OLAP o archiviati in un archivio relazionale. Il suo elemento più importante sono i metadati, ovvero informazioni sulla struttura, il posizionamento e la trasformazione dei dati. Grazie a loro è garantita l'interazione efficace dei vari componenti di archiviazione.

Riassumendo, possiamo definire OLAP come un insieme di strumenti per l'analisi multidimensionale dei dati accumulati in un magazzino. Teoricamente, gli strumenti OLAP possono essere applicati direttamente ai dati operativi o alle loro copie esatte (in modo da non interferire con gli utenti operativi). Ma così rischiamo di calpestare il limite già descritto sopra, cioè di iniziare ad analizzare dati operativi che non sono direttamente adatti all'analisi.

Definizione e concetti base di OLAP

Innanzitutto decifriamo: OLAP è Online Analytical Processing, ovvero analisi di dati operativi. I 12 principi che definiscono l'OLAP sono stati formulati nel 1993 da E. F. Codd, l'"inventore" dei database relazionali. Successivamente, la sua definizione è stata rielaborata nel cosiddetto test FASMI, che richiede che l'applicazione OLAP fornisca la capacità di analizzare rapidamente informazioni multidimensionali condivise ().

Prova FASMI

Veloce(Veloce) - l'analisi dovrebbe essere effettuata con la stessa rapidità su tutti gli aspetti dell'informazione. Il tempo di risposta accettabile è di 5 secondi o meno.

Analisi(Analisi) - deve essere possibile effettuare tipologie base di analisi numeriche e statistiche, predefinite dallo sviluppatore dell'applicazione o liberamente definite dall'utente.

Condiviso(Condiviso) - molti utenti devono avere accesso ai dati, mentre è necessario controllare l'accesso alle informazioni riservate.

Multidimensionale(Multidimensionale) è la caratteristica principale ed essenziale di OLAP.

Informazione(Informazioni): l'applicazione deve essere in grado di accedere a tutte le informazioni necessarie, indipendentemente dal volume e dalla posizione di archiviazione.

OLAP = Vista multidimensionale = Cubo

OLAP fornisce mezzi convenienti e veloci per accedere, visualizzare e analizzare le informazioni aziendali. L'utente riceve un modello di dati naturale e intuitivo, organizzandoli sotto forma di cubi multidimensionali (Cubes). Gli assi del sistema di coordinate multidimensionale sono gli attributi principali del processo aziendale analizzato. Ad esempio, per le vendite potrebbe essere prodotto, regione, tipo di acquirente. Il tempo è utilizzato come una delle dimensioni. Alle intersezioni degli assi - dimensioni (Dimensions) - ci sono dati che caratterizzano quantitativamente il processo - misure (Measures). Possono trattarsi di volumi di vendita in pezzi o in termini monetari, saldi di magazzino, costi, ecc. L'utente analizzando le informazioni può "tagliare" il cubo in direzioni diverse, ricevere informazioni riassuntive (ad esempio per anno) o, al contrario, dettagliate (per settimana) ed eseguire altre manipolazioni che gli vengono in mente durante il processo di analisi.

Come misure nel cubo tridimensionale mostrato in Fig. 2, vengono utilizzati gli importi delle vendite e come dimensioni vengono utilizzati tempo, prodotto e negozio. Le misurazioni sono presentate a livelli specifici di raggruppamento: i prodotti sono raggruppati per categoria, i negozi per paese e i dati sui tempi delle transazioni per mese. Un po' più tardi esamineremo più in dettaglio i livelli di raggruppamento (gerarchia).

Riso. 2. Esempio di cubo

"Tagliare" un cubo

Anche un cubo tridimensionale è difficile da visualizzare sullo schermo di un computer in modo che siano visibili i valori delle misure di interesse. Cosa possiamo dire dei cubi con più di tre dimensioni? Per visualizzare i dati memorizzati in un cubo, di norma vengono utilizzate viste bidimensionali familiari, cioè tabulari, con intestazioni gerarchiche complesse di righe e colonne.

Una rappresentazione bidimensionale di un cubo può essere ottenuta “tagliandolo” lungo uno o più assi (dimensioni): fissiamo i valori di tutte le dimensioni tranne due, e otteniamo una tabella bidimensionale regolare. L'asse orizzontale della tabella (intestazioni di colonna) rappresenta una dimensione, l'asse verticale (intestazioni di riga) ne rappresenta un'altra e le celle della tabella rappresentano i valori delle misure. In questo caso, un insieme di misure viene effettivamente considerato come una delle dimensioni: selezioniamo una misura da visualizzare (e poi possiamo inserire due dimensioni nelle intestazioni di riga e colonna), oppure mostriamo diverse misure (e poi una delle gli assi della tabella saranno occupati dai nomi delle misure e gli altri dai valori dell'unica dimensione "non tagliata").

Dai un'occhiata alla fig. 3 - ecco una fetta bidimensionale del cubo per una misura - Unit Sales (pezzi venduti) e due dimensioni "non tagliate" - Store (Store) e Time (Time).

Riso. 3. Fetta di cubo 2D per una misura

Nella fig. La Figura 4 mostra solo una dimensione "non tagliata": Negozio, ma mostra i valori di diverse misure: Vendite unitarie (unità vendute), Vendite in negozio (importo di vendita) e Costo del negozio (spese del negozio).

Riso. 4. Fetta di cubo 2D per misure multiple

Una rappresentazione bidimensionale di un cubo è possibile anche quando più di due dimensioni rimangono “non tagliate”. In questo caso, due o più dimensioni del cubo “tagliato” verranno posizionate sugli assi della sezione (righe e colonne) - vedere Fig. 5.

Riso. 5. Fetta di cubo 2D con più dimensioni su un asse

Tag

I valori "posizionati" lungo le dimensioni sono chiamati membri o etichette. Le etichette servono sia per “tagliare” il cubo sia per limitare (filtrare) i dati selezionati - quando in una dimensione che rimane “non tagliata” non siamo interessati a tutti i valori, ma a un sottoinsieme di essi, ad esempio tre città su diverse dozzine. I valori delle etichette vengono visualizzati nella vista del cubo 2D come intestazioni di righe e colonne.

Gerarchie e livelli

Le etichette possono essere combinate in gerarchie costituite da uno o più livelli. Ad esempio, le etichette della dimensione Negozio sono naturalmente raggruppate in una gerarchia con livelli:

Paese

Stato

Città

Negozio.

I valori aggregati vengono calcolati in base ai livelli della gerarchia, ad esempio il volume delle vendite per gli USA (livello "Country") o per la California (livello "State"). È possibile implementare più di una gerarchia in una dimensione, ad esempio per il tempo: (Anno, Trimestre, Mese, Giorno) e (Anno, Settimana, Giorno).

Architettura delle applicazioni OLAP

Tutto ciò che è stato detto sopra sull'OLAP si riferisce essenzialmente alla presentazione multidimensionale dei dati. Il modo in cui i dati vengono archiviati, in parole povere, non riguarda né l'utente finale né gli sviluppatori dello strumento utilizzato dal cliente.

La multidimensionalità nelle applicazioni OLAP può essere suddivisa in tre livelli:

Rappresentazione multidimensionale dei dati: strumenti per l'utente finale che forniscono visualizzazione e manipolazione multidimensionali dei dati; strato rappresentazione multidimensionale astrae dalla struttura fisica dei dati e percepisce i dati come multidimensionali.
Elaborazione multidimensionale: uno strumento (linguaggio) per formulare query multidimensionali (relazionali tradizionali linguaggio SQL risulta inadatto in questo caso) e un processore in grado di elaborare ed eseguire tale richiesta.
L'archiviazione multidimensionale è un mezzo per organizzare fisicamente i dati che garantisce l'esecuzione efficiente di query multidimensionali.

I primi due livelli sono obbligatori in tutti gli strumenti OLAP. Il terzo livello, seppur diffuso, non è necessario, poiché i dati per una rappresentazione multidimensionale possono essere estratti da strutture relazionali ordinarie; Il processore di query multidimensionali in questo caso traduce le query multidimensionali in query SQL che vengono eseguite dal DBMS relazionale.

Prodotti OLAP specifici, di norma, sono uno strumento di rappresentazione di dati multidimensionali, un client OLAP (ad esempio, tabelle pivot in Excel 2000 di Microsoft o ProClarity di Knosys) o un server DBMS multidimensionale, un server OLAP (ad esempio, Oracle Express Server o servizi Microsoft OLAP).

Il livello di elaborazione multidimensionale è solitamente integrato nel client OLAP e/o nel server OLAP, ma può essere isolato nella sua forma pura, come il componente Servizio tabelle pivot di Microsoft.

Aspetti tecnici dell'archiviazione di dati multidimensionali

Come accennato in precedenza, gli strumenti di analisi OLAP possono anche estrarre dati direttamente dai sistemi relazionali. Questo approccio era più interessante in quei giorni in cui i server OLAP non erano inclusi nei listini prezzi dei principali produttori di DBMS. Ma oggi Oracle, Informix e Microsoft offrono server OLAP a tutti gli effetti, e anche quei manager IT che non amano creare uno "zoo" di software di diversi produttori nelle loro reti possono acquistare (o meglio, fare una richiesta corrispondente) (gestione aziendale) Server OLAP della stessa marca del server del database principale.

I server OLAP, o server di database multidimensionali, possono archiviare i propri dati multidimensionali in diversi modi. Prima di considerare questi metodi, dobbiamo parlare di un aspetto così importante come lo stoccaggio delle unità. Il fatto è che in qualsiasi data warehouse - sia ordinario che multidimensionale - insieme ai dati dettagliati estratti dai sistemi operativi, vengono archiviati anche indicatori sintetici (indicatori aggregati, aggregazioni), come la somma dei volumi di vendita per mese, per categoria merceologica, ecc. Gli aggregati vengono archiviati esplicitamente al solo scopo di velocizzare l'esecuzione delle richieste. Dopotutto, da un lato, di norma, nel magazzino viene accumulata una quantità molto grande di dati e, dall'altro, nella maggior parte dei casi gli analisti non sono interessati a indicatori dettagliati, ma generalizzati. E se si dovessero sommare ogni volta milioni di vendite individuali per calcolare le vendite totali dell'anno, molto probabilmente la velocità sarebbe inaccettabile. Pertanto, quando si caricano i dati in un database multidimensionale, tutti gli indicatori totali o parte di essi vengono calcolati e archiviati.

Ma, come sai, devi pagare tutto. E per la velocità di elaborazione delle richieste di dati di riepilogo bisogna pagare per un aumento dei volumi di dati e del tempo per caricarli. Inoltre, un aumento di volume può diventare letteralmente catastrofico, in uno dei pubblicati test standardizzati un calcolo completo degli aggregati per 10 MB di dati originali richiedeva 2,4 GB, ovvero i dati sono cresciuti 240 volte! Il grado di “rigonfiamento” dei dati nel calcolo degli aggregati dipende dal numero di dimensioni del cubo e dalla struttura di queste dimensioni, ovvero dal rapporto tra il numero di “padri” e “figli” a diversi livelli di misurazione. Per risolvere il problema della memorizzazione degli aggregati, a volte vengono utilizzati schemi complessi che consentono di ottenere un aumento significativo delle prestazioni delle query quando non si calcolano tutti gli aggregati possibili.

Ora sulle varie opzioni per la memorizzazione delle informazioni. Sia i dati granulari che quelli aggregati possono essere archiviati in strutture relazionali o multidimensionali. L'archiviazione multidimensionale consente di trattare i dati come un array multidimensionale, che garantisce calcoli altrettanto rapidi degli indicatori totali e varie trasformazioni multidimensionali lungo qualsiasi dimensione. Qualche tempo fa, i prodotti OLAP supportavano l'archiviazione relazionale o multidimensionale. Oggi, di norma, lo stesso prodotto fornisce entrambi questi tipi di archiviazione, nonché un terzo tipo: misto. Si applicano i seguenti termini:

MOLAP(OLAP multidimensionale) - sia i dati dettagliati che quelli aggregati sono archiviati in un database multidimensionale. In questo caso si ottiene la massima ridondanza, poiché i dati multidimensionali contengono completamente dati relazionali.
ROLAP(OLAP relazionale) - i dati dettagliati rimangono dove originariamente "vivevano" - nel database relazionale; gli aggregati vengono archiviati nello stesso database in tabelle di servizio appositamente create.
OLAP(OLAP ibrido): i dati dettagliati rimangono al loro posto (in un database relazionale) e gli aggregati vengono archiviati in un database multidimensionale.

Ciascuno di questi metodi presenta vantaggi e svantaggi e dovrebbe essere utilizzato a seconda delle condizioni: volume di dati, potenza del DBMS relazionale, ecc.

Quando si memorizzano dati in strutture multidimensionali, esiste un potenziale problema di "gonfiamento" dovuto alla memorizzazione di valori vuoti. Dopotutto, se in un array multidimensionale lo spazio è riservato a tutte le possibili combinazioni di etichette dimensionali, ma solo una piccola parte viene effettivamente riempita (ad esempio, un certo numero di prodotti viene venduto solo in un numero limitato di regioni), allora la maggior parte il cubo sarà vuoto, anche se lo spazio sarà occupato. I moderni prodotti OLAP possono far fronte a questo problema.

Continua. In futuro parleremo di prodotti OLAP specifici realizzati da produttori leader.

07/04/2011 Derek Comingore

Se hai lavorato in qualsiasi campo legato alla tecnologia, probabilmente hai sentito il termine "cubo"; tuttavia, la maggior parte degli amministratori e sviluppatori di database comuni non lavoravano con questi oggetti. I cubi forniscono una potente architettura dati per aggregare rapidamente informazioni multidimensionali. Se la tua organizzazione ha bisogno di analizzare grandi volumi di dati, allora soluzione ideale sarà un cubo

Cos'è un cubo?

I database relazionali sono stati progettati per gestire migliaia di transazioni simultanee mantenendo le prestazioni e l'integrità dei dati. In base alla progettazione, i database relazionali non sono efficienti nell'aggregare e ricercare grandi volumi di dati. Per aggregare e restituire grandi volumi di dati, un database relazionale deve ricevere una query basata su set, le cui informazioni verranno raccolte e aggregate al volo. Tali query relazionali sono molto costose perché si basano su più join e funzioni aggregate; Le query relazionali aggregate sono particolarmente inefficaci quando si lavora con grandi quantità di dati.

I cubi sono entità multidimensionali progettate per risolvere questa carenza nei database relazionali. Utilizzando un cubo è possibile fornire agli utenti una struttura dati che fornisce una risposta rapida alle query con grandi volumi di aggregazione. I cubi eseguono questa "magia di aggregazione" aggregando innanzitutto i dati (dimensioni) su più dimensioni. La preaggregazione del cubo viene solitamente effettuata durante la lavorazione. Quando si elabora un cubo, si producono aggregazioni di dati precalcolate che vengono archiviate in formato binario su disco.

Il cubo è la struttura dati centrale in sistema operativo Analisi dei dati OLAP di SQL Server Analytical Services (SSAS). I cubi sono generalmente costruiti a partire da un database relazionale sottostante chiamato modello dimensionale, ma sono entità tecniche separate. Logicamente, un cubo è un data warehouse costituito da dimensioni (dimensioni) e misurazioni (misure). Le dimensioni contengono caratteristiche e gerarchie descrittive, mentre le dimensioni sono i fatti descritti nelle dimensioni. Le dimensioni sono raggruppate in combinazioni logiche denominate gruppi di dimensioni. Le dimensioni vengono collegate ai gruppi di misurazione in base a una caratteristica: il grado di dettaglio.

IN file system un cubo è implementato come una sequenza di file binari collegati. L'architettura binaria del cubo facilita il rapido recupero di grandi volumi di dati multidimensionali.

Ho menzionato che i cubi sono costruiti a partire da un database relazionale sottostante chiamato modello dimensionale. Il modello dimensionale contiene tabelle relazionali (fatti e dimensioni) che lo collegano alle entità del cubo. Le tabelle dei fatti contengono dimensioni come la quantità di un prodotto venduto. Le tabelle dimensionali memorizzano attributi descrittivi come nomi di prodotti, date e nomi di dipendenti. In genere, le tabelle dei fatti e delle dimensioni sono correlate tramite vincoli di chiave esterna primaria, con le chiavi esterne posizionate nella tabella dei fatti (questa relazione relazionale si riferisce all'attributo di granularità del cubo discusso in precedenza). Quando le tabelle delle dimensioni sono collegate direttamente a una tabella dei fatti, viene formato uno schema a stella. Quando le tabelle delle dimensioni non sono direttamente collegate a una tabella dei fatti, il risultato è uno schema a fiocco di neve.

Si prega di notare che i modelli dimensionali sono classificati in base all'applicazione. Un data mart è un modello dimensionale progettato per un singolo processo aziendale, ad esempio le vendite o la gestione dell'inventario. Un data warehouse è un modello dimensionale progettato per acquisire i processi aziendali componenti in modo da facilitare l'analisi dei processi interaziendali.

Requisiti software

Ora che hai una conoscenza di base di cosa sono i cubi e perché sono importanti, accenderò gli ingranaggi e ti accompagnerò in un tour passo passo per costruire il tuo primo cubo utilizzando SSAS. Ci sono alcuni componenti di base Software, di cui avrai bisogno, quindi prima di iniziare a costruire il tuo primo cubo, assicurati che il tuo sistema soddisfi i requisiti.

Il cubo di esempio per le vendite su Internet verrà creato dal database di test AdventureWorksDW 2005. Costruirò il cubo di test da un sottoinsieme delle tabelle presenti nel database di test che saranno utili per analizzare i dati delle vendite su Internet. La Figura 1 mostra il layout di base delle tabelle del database. Poiché utilizzo la versione 2005, puoi seguire le mie istruzioni utilizzando SQL Server 2005 o SQL Server 2008.

Figura 1. Sottoinsieme del data mart delle vendite Internet di Adventure Works

Il database di formazione Adventure WorksDW 2005 è disponibile sul sito Web CodePlex: msftdbprodsamples.codeplex.com. Trovare il collegamento "I database di esempio dei prodotti SQL Server 2005 sono ancora disponibili" (http://codeplex.com/MSFTDBProdSamples/Release/ProjectReleases.aspx?ReleaseId=4004). Il database di training è contenuto nel file AdventureWorksBI.msi (http://msftdbprodsamples.codeplex.com/releases/view/4004#DownloadId=11755).

Come accennato, è necessario avere accesso a un'istanza di SQL Server 2008 o 2005, inclusi i componenti SSAS e Business Intelligence Development Studio (BIDS). Utilizzerò SQL Server 2008, quindi potresti notare alcune sottili differenze se utilizzi SQL Server 2005.

Creazione di un progetto SSAS

La prima cosa da fare è creare un progetto SSAS utilizzando BIDS. Trovare BIDS nel menu Start e poi nel menu Microsoft SQL Server 2008/2005, sottovoce SQL Server Business Intelligence Development Studio. Facendo clic su questo pulsante verrà avviato BIDS con la schermata iniziale predefinita. Creare nuovo progetto SSAS selezionando File, Nuovo, Progetto. Verrà visualizzata la finestra di dialogo Nuovo progetto, illustrata nella Figura 1. Selezionare la cartella del progetto Analysis Services e impostare la descrizione del progetto su SQLMAG_MyFirstCube. Fare clic su OK.

Una volta creato il progetto, fare clic con il pulsante destro del mouse su di esso in Esplora soluzioni e selezionare menù contestuale Elemento Proprietà. Ora seleziona la sezione Distribuzione sul lato sinistro della finestra di dialogo SQLMAG_MyFirstCube: Pagine delle proprietà ed esamina le impostazioni delle impostazioni del server di destinazione e del database, come mostra la Figura 2. Se lavori in un ambiente SQL Server distribuito, dovrai qualificarti la proprietà Target Server con il nome del server su cui verrà distribuita. Fai clic su OK quando sei soddisfatto delle impostazioni di distribuzione per questo progetto SSAS.

Definizione dell'origine dati

Il primo oggetto che devi creare è l'origine dati. Un oggetto origine dati fornisce lo schema e i dati utilizzati per creare gli oggetti associati e alla base del cubo. Per creare un oggetto origine dati in BIDS, utilizzare la Creazione guidata origine Dati Procedura guidata di origine.

Avviare la procedura guidata origine dati facendo clic con il pulsante destro del mouse sulla cartella Origine dati nel pannello Esplora soluzioni e selezionando Nuova origine dati. Scoprirai che la creazione di oggetti SSAS in BIDS ha natura di sviluppo. La procedura guidata ti guida innanzitutto attraverso il processo di creazione dell'oggetto e le impostazioni generali. Quindi apri l'oggetto SSAS risultante nel designer e, se necessario, personalizzalo in dettaglio. Una volta superata la schermata di richiesta, definire una nuova connessione dati facendo clic sul pulsante Nuova. Seleziona e crea una nuova connessione basata su Native OLEDB\SQL Server Native Client 10 puntando a quella desiderata Server SQL Server che possiede l'istanza del database desiderata. È possibile utilizzare l'autenticazione Windows o SQL Server, a seconda delle impostazioni dell'ambiente SQL Server. Fare clic sul pulsante Prova connessione per assicurarsi di aver identificato correttamente la connessione al database, quindi fare clic su OK.

Poi vengono le informazioni sulla rappresentazione che, come l'associazione dei dati, dipendono da come è strutturato l'ambiente SQL Server. Il prestito dei privilegi è il contesto di sicurezza su cui SSAS fa affidamento durante l'elaborazione dei suoi oggetti. Se gestisci la tua distribuzione su un singolo server primario (o laptop), come presumo sia la maggior parte dei lettori, puoi semplicemente selezionare l'opzione Utilizza l'account di servizio. Fare clic su Avanti per completare la procedura guidata dell'origine dati e impostare AWDW2005 come nome dell'origine dati. È abbastanza conveniente utilizzare questo metodo a scopo di test, ma in un ambiente di produzione reale non è il massimo la migliore pratica- utilizzare un account di servizio. È meglio specificare il dominio Conti per prendere in prestito i diritti di connessione SSAS all'origine dati.

Visualizzazione origine dati

Per l'origine dati definita, il passaggio successivo nel processo di creazione del cubo SSAS consiste nel creare una vista origine dati (DSV). DSV offre la possibilità di separare lo schema previsto dal cubo da quello del database sottostante. Di conseguenza, DSV può essere utilizzato per estendere lo schema relazionale sottostante durante la creazione di un cubo. Alcune delle funzionalità principali di DSV per l'estensione degli schemi di origini dati includono query denominate, relazioni logiche tra tabelle e colonne calcolate denominate.

Andiamo avanti e facciamo clic con il pulsante destro del mouse sulla cartella DSV e selezioniamo Nuova visualizzazione origine dati per avviare la procedura guidata Crea nuova visualizzazione DSV. Nella finestra di dialogo, nel passaggio Seleziona un'origine dati, selezionare una connessione al database relazionale e fare clic su Avanti. Seleziona le tabelle FactInternetSales, DimProduct, DimTime, DimCustomer e fai clic sul singolo pulsante freccia destra per spostare queste tabelle nella colonna Incluso. Infine, fai clic su Avanti e completa la procedura guidata accettando il nome predefinito e facendo clic su Fine.

A questo punto, dovresti avere una vista DSV situata nella cartella Visualizzazioni origine dati in Esplora soluzioni. Fare doppio clic sul nuovo DSV per avviare il designer DSV. Dovresti vedere tutte e quattro le tabelle per un determinato DSV, come mostrato nella Figura 2.

Creazione di dimensioni del database

Come spiegato in precedenza, le dimensioni forniscono caratteristiche descrittive di dimensioni e gerarchie utilizzate per consentire l'aggregazione al di sopra del livello di dettaglio. È importante comprendere la differenza tra una dimensione del database e una dimensione del cubo: le dimensioni del database forniscono gli oggetti dimensione sottostanti per le diverse dimensioni del cubo che verranno utilizzate per creare il cubo.

Le dimensioni del database e del cubo forniscono una soluzione elegante a un concetto noto come "dimensioni del ruolo". Le dimensioni basate sui ruoli vengono utilizzate quando è necessario utilizzare più volte una singola dimensione in un cubo. La data è un esempio perfetto in questa istanza del cubo: costruirai una singola dimensione di data e ti farai riferimento una volta per ogni data per la quale desideri analizzare le vendite online. La data del calendario sarà la prima dimensione creata. Fare clic con il pulsante destro del mouse sulla cartella Dimensioni in Esplora soluzioni e selezionare Nuova dimensione per avviare la Creazione guidata dimensione. Selezionare Utilizza una tabella esistente e fare clic su Avanti nel passaggio Seleziona metodo di creazione. Nel passaggio Specifica informazioni sull'origine, specificare la tabella DimTime nell'elenco a discesa della tabella Principale e fare clic su Avanti. Ora, nel passaggio Seleziona attributi dimensione, è necessario selezionare gli attributi della dimensione temporale. Selezionare ciascun attributo, come illustrato nella Figura 3.

Fare clic su Avanti. Come passaggio finale, immettere Dim Date nel campo Nome e fare clic su Fine per completare la Creazione guidata dimensione. Ora dovresti vedere la nuova dimensione Dim Date situata nella cartella Dimensioni in Esplora soluzioni.

Quindi utilizzare la Creazione guidata dimensione per creare dimensioni prodotto e cliente. Seguire gli stessi passaggi per creare la dimensione base di prima. Quando utilizzi la Creazione guidata dimensione, assicurati di selezionare tutti i potenziali attributi nel passaggio Seleziona attributi dimensione. I valori predefiniti per le altre impostazioni vanno bene per un'istanza del cubo di prova.

Creazione di un cubo di vendita su Internet

Ora che hai preparato le dimensioni del database, puoi iniziare a costruire il cubo. In Esplora soluzioni, fare clic con il pulsante destro del mouse sulla cartella Cubi e selezionare Nuovo cubo per avviare la Creazione guidata cubo. Nella finestra Seleziona metodo di creazione, seleziona l'opzione Utilizza tabelle esistenti. Selezionare la tabella FactInternetSales per Gruppo di misure nel passaggio Seleziona tabelle del gruppo di misure. Deseleziona le caselle accanto alle dimensioni Chiave promozione, Chiave valuta, Chiave territorio di vendita e Numero di revisione nel passaggio Seleziona misure e fai clic su Avanti.

Nella schermata Seleziona dimensioni esistenti verificare che tutte le dimensioni del database esistenti siano selezionate per essere utilizzate come dimensioni del cubo. Poiché desidero mantenere questo cubo il più semplice possibile, deseleziona la dimensione FactInternetSales nel passaggio Seleziona nuove dimensioni. Lasciando selezionata la dimensione FactInternetSales, creerai quella che viene chiamata dimensione dei fatti o dimensione degenerata. Le dimensioni dei fatti sono dimensioni create utilizzando una tabella dei fatti di base anziché una tabella delle dimensioni tradizionale.

Fare clic su Avanti per andare al passaggio Completamento della procedura guidata e immettere "Il mio primo cubo" nel campo Nome cubo. Fare clic sul pulsante Fine per completare il processo di creazione guidata del cubo.

Espansione ed elaborazione di un cubo

Ora sei pronto per distribuire ed elaborare il primo cubo. Fare clic con il pulsante destro del mouse sull'icona del nuovo cubo in Esplora soluzioni e selezionare Processo. Verrà visualizzata una finestra di messaggio che informa che il contenuto sembra non essere aggiornato. Fare clic su Sì per distribuire il nuovo cubo sul server SSAS di destinazione. Quando distribuisci un cubo lo invii FileXML for Analisis (XMLA) al server SSAS di destinazione, che crea un cubo sul server stesso. Come accennato, l'elaborazione di un cubo popola i relativi file binari sul disco con i dati dell'origine principale, nonché con metadati aggiuntivi aggiunti (dimensioni del cubo, dimensioni e impostazioni).

Una volta completato il processo di distribuzione, viene visualizzata una nuova finestra di dialogo Process Cube. Fare clic sul pulsante Esegui per iniziare l'elaborazione del cubo, che si apre con la finestra Avanzamento processo. Al termine dell'elaborazione, fare clic su Chiudi (due volte per chiudere entrambe le finestre di dialogo) per completare i processi di distribuzione ed elaborazione del cubo.

Ora hai creato, distribuito ed elaborato il tuo primo cubo. È possibile visualizzare questo nuovo cubo facendo clic con il pulsante destro del mouse su di esso nella finestra Esplora soluzioni e selezionando Sfoglia. Trascina le dimensioni al centro della tabella pivot e gli attributi delle dimensioni su righe e colonne per esplorare il tuo nuovo cubo. Notare la velocità con cui il cubo elabora varie query di aggregazione. Ora puoi apprezzare la potenza illimitata, e quindi il valore aziendale, del cubo OLAP.

Derek Comingore ( [e-mail protetta]) è un architetto senior presso B. I. Voyage, che ha lo status di partner Microsoft nel campo dell'analisi aziendale. Possiede il titolo SQL Server MVP e diverse certificazioni Microsoft

Popolare nella categoria: