Misure e dimensioni del cubo Olap. Cos'è un cubo? OLAP su client e server

/ In stile cubista. Applicazione dei cubi OLAP nella pratica gestionale delle grandi aziende

In contatto con

Compagne di classe

Konstantin Tokmachev, architetto di sistema

In stile cubista.
Applicazione dei cubi OLAP nella pratica gestionale delle grandi aziende

Forse è passato il tempo in cui le risorse informatiche di un'azienda venivano spese solo per la registrazione di informazioni e resoconti contabili. Allo stesso tempo, le decisioni gestionali venivano prese “a occhio” negli uffici, nelle riunioni e nelle sessioni. Forse in Russia è giunto il momento di riportare i sistemi informatici aziendali alla loro risorsa principale, risolvendo i problemi di gestione sulla base dei dati registrati nel computer

Informazioni sui vantaggi dell'analisi aziendale

Nel ciclo di gestione aziendale, tra i dati "grezzi" e le "leve" per influenzare l'oggetto gestito, ci sono "indicatori di prestazione" - KPI. Formano una sorta di "cruscotto" che riflette lo stato di vari sottosistemi dell'oggetto controllato. Dotare l'azienda di indicatori informativi di performance e monitorarne il calcolo e i valori ottenuti è il lavoro di un analista aziendale. I servizi di analisi automatizzata, come l'utilità MS, possono fornire un'assistenza significativa nell'organizzazione del lavoro analitico di un'azienda. server SQL Analysis Services (SSAS) e la sua caratteristica principale è il cubo OLAP.

Qui occorre sottolineare ancora un punto. Diciamo che, nella tradizione americana, una specialità focalizzata sul lavoro con i cubi OLAP si chiama BI (Business Intelligence). Non bisogna illudersi che il BI americano corrisponda all’“analista aziendale” russo. Senza offesa, ma spesso il nostro analista aziendale è un “sottocontabile” e un “sottoprogrammatore”, uno specialista con conoscenze vaghe e un piccolo stipendio, che in realtà non possiede nessuno dei suoi strumenti e della sua metodologia.

Uno specialista di BI è, infatti, un matematico applicato, uno specialista altamente qualificato che utilizza moderni metodi matematici per l'arsenale aziendale (quella che veniva chiamata ricerca operativa). La BI è più coerente con la specialità dell '"analista di sistema" che una volta era in URSS, laureata presso la Facoltà di Matematica Computazionale e Matematica dell'Università Statale di Mosca. M.V. Lomonosov. Il cubo OLAP e i servizi di analisi possono diventare una base promettente per il posto di lavoro di un analista aziendale russo, magari dopo una formazione avanzata nella direzione della BI americana.

Recentemente è emersa un’altra tendenza dannosa. Grazie alla specializzazione è andata perduta la comprensione reciproca tra le diverse categorie di dipendenti dell'azienda. Ragioniere, manager e programmatore, come “un cigno, un gambero e un luccio” nella favola di I.A. Krylov, stanno spingendo la società in direzioni diverse.

Il contabile è impegnato con la rendicontazione; i suoi importi, sia nel significato che nella dinamica, non sono direttamente correlati al processo aziendale dell'azienda.

Il manager è impegnato con la sua parte del processo aziendale, ma non è in grado di valutare globalmente, a livello dell'azienda nel suo complesso, i risultati e le prospettive delle sue azioni.

Infine, il programmatore, che un tempo (grazie alla sua educazione) era un conduttore di idee tecniche avanzate dalla sfera della scienza a quella degli affari, si è trasformato in un esecutore passivo delle fantasie del contabile e del manager, quindi non è non è più raro che i dipartimenti IT delle aziende siano guidati da contabili e, in generale, da tutti coloro che non sono pigri. Una mancanza di iniziativa, un programmatore 1C analfabeta, ma relativamente ben pagato è un vero flagello per le società russe. (Quasi come un calciatore nazionale.) Non sto nemmeno parlando dei cosiddetti “economisti e avvocati”, di loro si è detto tutto già da molto tempo.

Pertanto, la posizione di un analista aziendale, dotato di un apparato SSAS ad alta intensità di conoscenza, esperto nelle basi della programmazione e della contabilità, è in grado di consolidare il lavoro dell'azienda in relazione all'analisi e alla previsione del processo aziendale.

Vantaggi dei cubi OLAP

Il cubo OLAP è rimedio moderno analisi del database del sistema informatico aziendale, che consente di fornire ai dipendenti di tutti i livelli della gerarchia il necessario insieme di indicatori che caratterizzano processo di fabbricazione aziende. Il punto non è solo che la comoda interfaccia e il linguaggio di query flessibile del cubo MDX (MultiDimensional eXpressions) consentono di formulare e calcolare gli indicatori analitici necessari, ma anche la notevole velocità e facilità con cui il cubo OLAP lo fa. Inoltre, questa velocità e facilità, entro certi limiti, non dipendono dalla complessità dei calcoli e dalle dimensioni del database.

Qualche introduzione a OLAP-
il cubo può essere dato da una “tabella pivot” di MS Excel. Questi oggetti hanno logica simile e interfacce simili. Ma, come si vedrà dall'articolo, la funzionalità OLAP è incomparabilmente più ricca e le prestazioni sono incomparabilmente più elevate, quindi la "tabella pivot" rimane un prodotto desktop locale, mentre OLAP è un prodotto di livello aziendale.

Perché il cubo OLAP è così efficace da risolvere compiti analitici? Il cubo OLAP è progettato in modo tale che tutti gli indicatori in tutte le possibili sezioni siano precalcolati (in tutto o in parte) e l'utente possa solo "estrarre" gli indicatori (misure) e le dimensioni (dimensioni) richiesti con il mouse e il programma può ridisegnare le tabelle.

Tutte le possibili analisi in tutte le sezioni formano un campo enorme, o meglio, non un campo, ma solo un cubo OLAP multidimensionale. Qualunque sia la richiesta che l'utente (manager, analista aziendale, dirigente) rivolge al servizio di analisi, la velocità di risposta è spiegata da due cose: in primo luogo, le analisi richieste possono essere facilmente formulate (selezionate da un elenco per nome o specificate da un formula nel linguaggio MDX ), in secondo luogo, di regola, è già stato calcolato.

La formulazione dell'analisi è possibile in tre opzioni: si tratta di un campo di database (o meglio, di un campo di magazzino), oppure di un campo di calcolo definito a livello di progettazione del cubo, oppure di un'espressione del linguaggio MDX quando si lavora in modo interattivo con il cubo.

Ciò significa diverse caratteristiche interessanti dei cubi OLAP. In sostanza, la barriera tra l’utente e i dati scompare. La barriera è rappresentata dal programmatore dell'applicazione che, in primo luogo, deve spiegare il problema (impostare un'attività). In secondo luogo, dovrai attendere che il programmatore dell'applicazione crei un algoritmo, scriva ed effettui il debug del programma, quindi eventualmente lo modifichi. Se i dipendenti sono numerosi e le loro esigenze sono varie e mutevoli, è necessario un intero team di programmatori di applicazioni. In questo senso, un cubo OLAP (e un analista aziendale qualificato) sostituisce un'intera squadra di programmatori di applicazioni in termini di lavoro analitico, proprio come un potente escavatore con un operatore dell'escavatore sostituisce un'intera squadra di lavoratori migranti con pale quando scavano un fossato!

Allo stesso tempo, viene raggiunta un'altra qualità molto importante dei dati analitici ottenuti. Poiché esiste un solo cubo OLAP per l'intera azienda, ovvero Questo è lo stesso campo con gli analisti per tutti, il che elimina fastidiose discrepanze nei dati. Quando un manager deve chiedere lo stesso compito a più dipendenti indipendenti per eliminare il fattore soggettività, ma questi portano comunque risposte diverse, che ognuno si impegna a spiegare in qualche modo, ecc. Il cubo OLAP garantisce l'uniformità dei dati analitici a diversi livelli della gerarchia aziendale, ad es. se un manager vuole dettagliare un certo indicatore di suo interesse, arriverà sicuramente ai dati di livello inferiore con cui lavora il suo subordinato, e questi saranno proprio i dati sulla base dei quali è stato calcolato l'indicatore di livello superiore , e non qualche altro dato, ricevuto in qualche altro modo, in qualche altro momento, ecc. Cioè, l’intera azienda vede le stesse analisi, ma a diversi livelli di aggregazione.

Facciamo un esempio. Diciamo che un manager controlla la contabilità clienti. Finché il KPI dei crediti scaduti è verde significa che tutto è normale e non sono necessarie azioni di gestione. Se il colore è cambiato in giallo o rosso, qualcosa non va: tagliamo i KPI per reparti commerciali e vediamo subito i reparti “in rosso”. Viene identificata la sezione successiva dei gestori e del venditore i cui clienti sono in ritardo con i pagamenti. (Inoltre, l'importo scaduto può essere diviso per clienti, termini, ecc.) Il capo dell'azienda può contattare direttamente i trasgressori a qualsiasi livello. Ma in generale, lo stesso KPI (ai livelli gerarchici) è visto sia dai capi reparto che dai responsabili delle vendite. Pertanto, per correggere la situazione, non hanno nemmeno bisogno di aspettare una "chiamata sul tappeto"... Naturalmente, il KPI stesso non deve necessariamente essere l'importo dei pagamenti scaduti, può essere il periodo medio ponderato degli scaduti o, in generale, il tasso di rotazione dei crediti.

Notiamo che la complessità e la flessibilità del linguaggio MDX, insieme ai risultati rapidi (a volte istantanei), ci consentono di risolvere (tenendo conto delle fasi di sviluppo e debug) compiti di controllo complessi che altrimenti non sarebbero stati affatto posti. a causa della complessità per i programmatori dell'applicazione e dell'incertezza iniziale nella formulazione. (Scadenze lunghe per i programmatori di applicazioni per risolvere problemi analitici a causa di formulazioni poco comprese e lunghe modifiche dei programmi quando le condizioni cambiano spesso nella pratica.)

Prestiamo attenzione anche al fatto che ogni dipendente dell'azienda può raccogliere dal campo generale dell'analista OLAP esattamente il raccolto di cui ha bisogno per il suo lavoro, e non accontentarsi della “striscia” che gli viene ritagliata in comune. “rapporti standard”.

L'interfaccia multiutente per lavorare con un cubo OLAP in modalità client-server consente a ciascun dipendente, indipendentemente dagli altri, di avere i propri blocchi analitici (report) (anche realizzati da sé con una certa abilità), che, una volta definiti, vengono automaticamente aggiornato - in altre parole, sono sempre aggiornati.

Cioè, il cubo OLAP consente di rendere il lavoro analitico (che in realtà viene svolto non solo dagli analisti della reception, ma, di fatto, da quasi tutti i dipendenti dell'azienda, anche dai logisti e dai manager che controllano i saldi e le spedizioni) più selettivo, “non in termini generali”, che crea le condizioni per migliorare il lavoro e aumentare la produttività.

Per riassumere la nostra introduzione, notiamo che l'utilizzo dei cubi OLAP può elevare la gestione di un'azienda ad un livello superiore. L'uniformità dei dati analitici a tutti i livelli della gerarchia, la loro affidabilità, complessità, facilità di creazione e modifica degli indicatori, impostazioni individuali, alta velocità di elaborazione dei dati e, infine, risparmio di denaro e tempo spesi per supportare percorsi analitici alternativi (programmatori di applicazioni, calcoli indipendenti dei dipendenti) aprono prospettive per l'uso dei cubi OLAP nella pratica delle grandi aziende russe.

OLTP + OLAP: schema feedback nella catena di gestione aziendale

Consideriamo ora l'idea generale dei cubi OLAP e il loro punto di applicazione nella catena di gestione aziendale. Il termine OLAP (OnLine Analytical Processing) è stato introdotto dal matematico britannico Edgar Codd in aggiunta al termine precedentemente introdotto OLTP (OnLine Transactions Processing). Questo verrà discusso più avanti, ma E. Codd, ovviamente, ha proposto non solo i termini, ma anche le teorie matematiche di OLTP e OLAP. Senza entrare nei dettagli, nell'interpretazione moderna, OLTP è un database relazionale, considerato come un meccanismo per registrare, archiviare e recuperare informazioni.

Metodologia della soluzione

I sistemi ERP (Enterprice Resource Planning), come 1C7, 1C8, MS Dynamics AX, dispongono di interfacce software orientate all'utente (immissione e modifica di documenti, ecc.) e di un database relazionale (DB) per l'archiviazione e il recupero delle informazioni, rappresentato oggi da software prodotti come MS SQL Server (SS).

Tieni presente che le informazioni registrate nel database del sistema ERP sono davvero una risorsa molto preziosa. Il punto non è solo che le informazioni registrate garantiscono il flusso di documenti corrente della società (estrazione di documenti, modifica degli stessi, possibilità di stampa e riconciliazione, ecc.) e non solo la capacità di calcolare rendiconti finanziari (tasse, audit, ecc. ). Dal punto di vista gestionale, è molto più importante che il sistema OLTP (database relazionale) sia, di fatto, un vero e proprio modello digitale a grandezza naturale delle attività dell’azienda.

Ma per gestire il processo non è sufficiente registrare le informazioni a riguardo. Il processo dovrebbe essere presentato sotto forma di un sistema di indicatori numerici (KPI) che ne caratterizzino il progresso. Inoltre, è necessario definire intervalli di valori accettabili per gli indicatori. E solo se il valore dell'indicatore non rientra nell'intervallo consentito, dovrebbe seguire un'azione di controllo.

Riguardo a questa logica (o mitologia) del controllo (“controllo per deviazione”), sia l’antico filosofo greco Platone, che creò l’immagine del timoniere (cybernose), che si appoggia al remo quando la barca devia dalla rotta, sia il Il matematico americano Norbert Wiener, che creò la scienza della cibernetica alla vigilia dell'era dei computer.

Oltre al consueto sistema di registrazione delle informazioni utilizzando il metodo OLTP, è necessario un altro sistema: un sistema per analizzare le informazioni raccolte. Questo add-on, che nel loop di controllo svolge il ruolo di feedback tra il management e l'oggetto di controllo, è un sistema OLAP o, in breve, un cubo OLAP.

Come implementazione software di OLAP, considereremo l'utilità MS Analysis Services, che fa parte della fornitura standard di MS SQL Server, abbreviata SSAS. Si noti che, secondo il piano di E. Codd, il cubo OLAP nell'analisi dovrebbe offrire la stessa ampia libertà di azione che il sistema OLTP e il database relazionale (SQL Server) forniscono nell'archiviazione e nel recupero delle informazioni.

Logistica OLAP

Ora diamo un'occhiata alla configurazione specifica dispositivi esterni, programmi applicativi e operazioni tecnologiche su cui si basa il funzionamento automatizzato del cubo OLAP.

Supponiamo che l'azienda utilizzi un sistema ERP, ad esempio 1C7 o 1C8, all'interno del quale le informazioni vengono registrate come al solito. Il database di questo sistema ERP si trova su un determinato server ed è supportato da MS SQL Server.

Supponiamo inoltre che su un altro server sia installato del software, incluso MS SQL Server con l'utilità MS Analysis Services (SSAS), nonché MS SQL Server Management Studio, MS C#, MS Excel e MS Visual Studio. Questi programmi insieme costituiscono il contesto richiesto: gli strumenti e le interfacce necessarie per lo sviluppatore di cubi OLAP.

Il server SSAS ha un programma distribuito gratuitamente chiamato blat, chiamato (con parametri) da riga di comando e fornire il servizio postale.

Nelle postazioni di lavoro dei dipendenti, all'interno rete locale, tra le altre cose, vengono installati i programmi MS Excel (versioni non inferiori alla 2003) ed eventualmente un driver speciale per garantire che MS Excel funzioni con MS Analysis Services (a meno che il driver corrispondente non sia già incluso in MS Excel).

Per chiarezza, supporremo che un sistema operativo sia installato sulle postazioni di lavoro dei dipendenti. Sistema Windows XP e sui server - WindowsServer 2008. Inoltre, è possibile utilizzare MS SQL Server 2005 come SQL Server, con Enterprise Edition (EE) o Developer Edition (DE) installato sul server con il cubo OLAP. In queste edizioni è possibile utilizzare il cosiddetto. “misure semiadditive”, ovvero aggiuntivo funzioni aggregate(statistiche) diverse dalle somme ordinarie (ad esempio, estreme o medie).

Progettazione del cubo OLAP (cubismo OLAP)

Diciamo alcune parole sulla progettazione del cubo OLAP stesso. Nel linguaggio statistico, un cubo OLAP è un insieme di indicatori di prestazione calcolati in tutte le sezioni necessarie, ad esempio l'indicatore di spedizione nelle sezioni per cliente, per merce, per data, ecc. A causa della traduzione diretta dall'inglese nella letteratura russa sui cubi OLAP, gli indicatori sono chiamati "misure" e le sezioni sono chiamate "dimensioni". Questa è una traduzione matematicamente corretta, ma sintatticamente e semanticamente non molto riuscita. Le parole russe "misura", "dimensione", "dimensione" sono quasi le stesse nel significato e nell'ortografia, mentre le parole inglesi "misura" e "dimensione" sono diverse sia nell'ortografia che nel significato. Pertanto, diamo la preferenza ai tradizionali termini statistici russi “indicatore” e “taglio”, che hanno un significato simile.

Esistono diverse opzioni per l'implementazione software di un cubo OLAP in relazione al sistema OLTP in cui vengono registrati i dati. Considereremo solo uno schema, il più semplice, affidabile e veloce.

In questa progettazione, OLAP e OLTP non condividono tabelle e le analisi OLAP vengono calcolate nel modo più dettagliato possibile durante la fase di aggiornamento del cubo (processo), che precede la fase di utilizzo. Questo schema si chiama MOLAP (Multidimensional OLAP). I suoi svantaggi sono l'asincronia con l'ERP e gli elevati costi di memoria.

Sebbene formalmente un cubo OLAP possa essere costruito utilizzando tutte (migliaia) le tabelle del database relazionale del sistema ERP come origine dati e tutti (centinaia) i loro campi come indicatori o sezioni, in realtà ciò non dovrebbe essere fatto. Viceversa. Per caricare in un cubo, è più corretto preparare un database separato, chiamato “vetrina” o “magazzino”.

Diverse ragioni ci costringono a farlo.

• in primo luogo, Collegare un cubo OLAP alle tabelle di un database reale creerà sicuramente problemi tecnici. La modifica dei dati in una tabella può attivare un aggiornamento del cubo e l'aggiornamento di un cubo non è necessariamente un processo veloce, quindi il cubo sarà in uno stato di ricostruzione costante; Allo stesso tempo, la procedura di aggiornamento del cubo può bloccare (in fase di lettura) i dati delle tabelle del database, rallentando il lavoro degli utenti nella registrazione dei dati nel sistema ERP.
• In secondo luogo, Avere troppi indicatori e tagli aumenterà notevolmente l'area di archiviazione del cubo sul server. Non dimentichiamo che il cubo OLAP memorizza non solo i dati di origine, come nel sistema OLTP, ma anche tutti gli indicatori riepilogati su tutte le possibili sezioni (e anche tutte le combinazioni di tutte le sezioni). Inoltre, la velocità di aggiornamento del cubo e, in definitiva, la velocità di creazione e aggiornamento delle analisi e dei report utente basati su di essi rallenteranno di conseguenza.
• Terzo, troppi campi (indicatori e sezioni) creeranno problemi nell'interfaccia dello sviluppatore OLAP, perché le liste di elementi diventeranno immense.
• In quarto luogo, Il cubo OLAP è molto sensibile alle violazioni dell'integrità dei dati. Non è possibile creare il cubo se i dati chiave non si trovano nel collegamento specificato nella struttura delle connessioni dei campi del cubo. Violazioni temporanee o permanenti dell'integrità, campi vuoti sono comuni in un database di sistema ERP, ma questo non è assolutamente adatto per OLAP.

È inoltre possibile aggiungere che il sistema ERP e il cubo OLAP dovrebbero trovarsi su server diversi per condividere il carico. Ma poi, se esistono tabelle comuni per OLAP e OLTP, si pone anche il problema del traffico di rete. Problemi praticamente irrisolvibili sorgono in questo caso quando è necessario consolidare diversi sistemi ERP disparati (1C7, 1C8, MS Dynamics AX) in un cubo OLAP.

Probabilmente potremo continuare ad accumulare problemi tecnici. Ma soprattutto, ricorda che, a differenza di OLTP, OLAP non è un mezzo per registrare e archiviare dati, ma uno strumento di analisi. Ciò significa che non è necessario caricare e scaricare dati “sporchi” dall’ERP all’OLAP “per ogni evenienza”. Al contrario, è necessario prima sviluppare un concetto di gestione dell'azienda, almeno a livello di sistema KPI, e poi progettare un data warehouse applicativo (warehouse), situato sullo stesso server del cubo OLAP, e contenente un piccolo , raffinata quantità di dati da ERP necessari per la gestione.

Senza promuovere cattive abitudini, il cubo OLAP nei confronti dell’OLTP può essere paragonato al noto “still”, attraverso il quale si estrae un “prodotto puro” dalla “massa fermentata” della registrazione reale.

Quindi, abbiamo capito che l'origine dati per OLAP è un database speciale (magazzino), situato sullo stesso server di OLAP. Generalmente questo significa due cose. Innanzitutto, devono esserci procedure speciali che creeranno un magazzino dai database ERP. In secondo luogo, il cubo OLAP è asincrono con i suoi sistemi ERP.

Tenendo conto di quanto sopra, proponiamo la seguente versione dell'architettura del processo di calcolo.

Architettura della soluzione

Supponiamo che ci siano molti sistemi ERP di una determinata società (holding) situati su server diversi, i dati analitici per i quali vorremmo vedere consolidati in un cubo OLAP. Sottolineiamo che nella tecnologia descritta combiniamo i dati dei sistemi ERP a livello di magazzino, lasciando invariato il design del cubo OLAP.

Sul server OLAP creiamo immagini (copie vuote) dei database di tutti questi sistemi ERP. Periodicamente (ogni notte) eseguiamo la replica parziale dei corrispondenti database ERP attivi su queste copie vuote.

Successivamente, viene avviato SP (stored procedure), che, sullo stesso server OLAP senza traffico di rete, basato su repliche parziali dei database del sistema ERP, crea (o riempie) un magazzino (magazzino), l'origine dati del cubo OLAP.

Successivamente viene avviata la procedura standard per l'aggiornamento/creazione di un cubo basato sui dati del magazzino (operazione di processo nell'interfaccia SSAS).

Commentiamo alcuni aspetti della tecnologia. Che tipo di lavoro svolgono gli SP?

Come risultato della replica parziale, i dati attuali vengono visualizzati nell'immagine di alcuni sistemi ERP sul server OLAP. A proposito, la replica parziale può essere eseguita in due modi.

Innanzitutto, da tutte le tabelle del database del sistema ERP, durante la replica parziale, vengono copiate solo quelle necessarie per costruire un magazzino. Questo è controllato da un elenco fisso di nomi di tabelle.

In secondo luogo, la replica parziale può anche significare che non vengono copiati tutti i campi della tabella, ma solo quelli coinvolti nella costruzione del magazzino. L'elenco dei campi da copiare viene specificato o creato dinamicamente in SP nell'immagine della copia (se non tutti i campi sono inizialmente presenti nella copia della tabella).

Naturalmente è possibile non copiare intere righe della tabella, ma solo aggiungere nuovi record. Tuttavia, ciò crea seri inconvenienti quando si tiene conto delle revisioni ERP “retroattivamente”, come spesso accade nei sistemi reali. Quindi è più semplice, senza ulteriori indugi, copiare tutti i record (o aggiornare la “coda” a partire da una certa data).

Successivamente, il compito principale di SP è convertire i dati del sistema ERP nel formato di magazzino. Se esiste un solo sistema ERP, il compito della conversione si riduce principalmente alla copia ed eventualmente alla riformattazione dei dati necessari. Ma se è necessario consolidare più sistemi ERP di strutture diverse nello stesso cubo OLAP, le trasformazioni diventano più complicate.

Il compito di unire più sistemi ERP diversi in un cubo è particolarmente difficile se gli insiemi dei loro oggetti (elenchi di merci, appaltatori, magazzini, ecc.) si sovrappongono parzialmente, gli oggetti hanno lo stesso significato, ma sono naturalmente descritti in modo diverso nelle directory di sistemi diversi (nel senso di codici, identificatori, nomi, ecc.).

In realtà, un quadro del genere si presenta in una grande holding, quando molte delle società autonome dello stesso tipo che la compongono svolgono approssimativamente gli stessi tipi di attività approssimativamente nello stesso territorio, ma utilizzano sistemi di registrazione propri e non concordati. In questo caso, quando si consolidano i dati a livello di magazzino, non è possibile fare a meno delle tabelle di mappatura ausiliarie.

Prestiamo attenzione all'architettura di stoccaggio del magazzino. Tipicamente, uno schema di cubo OLAP è rappresentato sotto forma di una "stella", cioè come una tabella di dati circondata da "raggi" di directory - tabelle di valori di chiave secondaria. Una tabella è un blocco di “indicatori”; i libri di consultazione sono le loro sezioni. In questo caso, la directory, a sua volta, può essere un albero sbilanciato arbitrario o una gerarchia equilibrata, ad esempio una classificazione multilivello di merci o appaltatori. In un cubo OLAP, i campi numerici di una tabella dati di un magazzino diventano automaticamente "indicatori" (o misure) e le sezioni (o dimensioni) possono essere definite utilizzando tabelle di chiavi secondarie.

Questa è una descrizione visiva “pedagogica”. In effetti, l'architettura di un cubo OLAP può essere molto più complessa.

Innanzitutto un magazzino può essere composto da più “stelle”, eventualmente collegate tramite directory comuni. In questo caso, il cubo OLAP sarà l'unione di più cubi (diversi blocchi di dati).

In secondo luogo, il "raggio" di un asterisco può non essere solo una directory, ma un intero file system (gerarchico).

In terzo luogo, sulla base delle sezioni dimensionali esistenti, è possibile definire nuove sezioni gerarchiche utilizzando gli strumenti dell'interfaccia sviluppatore OLAP (ad esempio, con meno livelli, con un diverso ordine di livelli, ecc.)

In quarto luogo, sulla base degli indicatori e delle sezioni esistenti, utilizzando le espressioni del linguaggio MDX, è possibile definire nuovi indicatori (calcoli). È importante notare che nuovi cubi, nuovi indicatori, nuove sezioni vengono automaticamente completamente integrati con gli elementi originali. Va inoltre notato che calcoli mal formulati e sezioni gerarchiche possono rallentare notevolmente il funzionamento di un cubo OLAP.

MS Excel come interfaccia con OLAP

Di particolare interesse è l'interfaccia utente con i cubi OLAP. Naturalmente, l'interfaccia più completa è fornita dall'utilità SSAS stessa. Ciò include un toolkit per sviluppatori di cubi OLAP, un progettista di report interattivo e una finestra lavoro interattivo con un cubo OLAP utilizzando query MDX.

Oltre allo stesso SSAS, esistono molti programmi che forniscono un'interfaccia a OLAP, coprendone le funzionalità in misura maggiore o minore. Ma tra questi ce n'è uno che, a nostro avviso, presenta innegabili vantaggi. Questo è MS Excel.

L'interfaccia con MS Excel è fornita da un apposito driver, scaricabile separatamente o incluso nella distribuzione Excel. Non copre tutte le funzionalità di OLAP, ma con l'aumento dei numeri di versione di MS Excel, questa copertura sta diventando più ampia (ad esempio, una rappresentazione grafica dei KPI appare in MS Excel 2007, cosa che non era il caso in MS Excel 2003, eccetera.).

Naturalmente, oltre alla sua funzionalità abbastanza completa, il vantaggio principale di MS Excel è la distribuzione capillare di questo programma e la stretta familiarità con esso da parte della stragrande maggioranza degli utenti di Office. In questo senso, a differenza di altri programmi di interfaccia, l'azienda non ha bisogno di acquistare nulla in più e non ha bisogno di formare ulteriormente nessuno.

Il grande vantaggio di MS Excel come interfaccia con OLAP è la capacità di elaborare ulteriormente in modo indipendente i dati ottenuti nel report OLAP (ovvero continuare a studiare i dati ottenuti da OLAP su altri fogli dello stesso Excel, non più utilizzando gli strumenti OLAP, ma utilizzando i normali strumenti di Excel).

Ciclo di trattamenti notturni Facubi

Ora descriveremo il ciclo computazionale giornaliero (notturno) dell'operazione OLAP. Il calcolo viene effettuato sotto il controllo del programma facubi, scritto in C# 2005 e lanciato tramite Task Scheduler su un server con warehouse e SSAS. All'inizio facubi va su Internet e legge i tassi di cambio attuali (utilizzati per rappresentare una serie di indicatori in una valuta). Successivamente, eseguire i seguenti passaggi.

Innanzitutto facubi lancia SP che eseguono la replica parziale dei database di vari sistemi ERP (elementi di contenimento) disponibili sulla rete locale. La replica viene eseguita, come abbiamo detto, su "sfondi" pre-preparati: immagini di sistemi ERP remoti situati sul server SSAS.

In secondo luogo, tramite SP, viene eseguita una mappatura dalle repliche ERP allo storage del magazzino, un DB speciale, che è l'origine dei dati del cubo OLAP e si trova sul server SSAS. In questo caso, vengono risolti tre compiti principali:

• Dati ERP adattato ai formati cubo richiesti; stiamo parlando sia sulle tabelle che sui campi della tabella. (A volte la tabella richiesta deve essere "creata", ad esempio, da diversi fogli MS Excel.) Dati simili possono avere formati diversi in diversi ERP, ad esempio, i campi ID chiave nelle directory 1C7 hanno un codice di caratteri di 36 cifre di lunghezza 8 , e campi _idrref nelle directory 1С8 – numeri esadecimali di lunghezza 32;
• durante la lavorazione viene effettuato il controllo logico dei dati (compresa la scrittura dei valori predefiniti al posto dei dati mancanti, ove possibile) e il controllo dell'integrità, vale a dire verificare la presenza delle chiavi primarie e secondarie nei corrispondenti classificatori;
• consolidamento del codice oggetti che hanno lo stesso significato in diversi ERP. Ad esempio, gli elementi corrispondenti di directory di diversi ERP possono avere lo stesso significato, ad esempio sono la stessa controparte. Il problema del consolidamento dei codici viene risolto costruendo tabelle di mappatura, dove vari codici gli stessi oggetti sono portati all'unità.

In terzo luogo, i lanci di facubi procedura standard aggiornamento dei dati del cubo di elaborazione (dalle procedure dell'utilità SSAS).

Sulla base delle liste di controllo, facubi invia e-mail sullo stato di avanzamento delle fasi di elaborazione.

Dopo aver eseguito facubi, l'Utilità di pianificazione avvia a turno diversi file Excel, in cui i report vengono precreati in base agli indicatori del cubo OLAP. Come abbiamo detto, MS Excel ha una particolarità interfaccia software(driver scaricabile separatamente o integrato) per lavorare con i cubi OLAP (con SSAS). Quando si avvia MS Excel, vengono attivati ​​i programmi MS VBA (come le macro), che garantiscono l'aggiornamento dei dati nei report; i report vengono modificati se necessario e inviati via mail (programma blat) agli utenti secondo checklist.

Gli utenti della rete locale con accesso al server SSAS riceveranno report “in tempo reale” configurati per il cubo OLAP. (In linea di principio, loro stessi, senza posta, possono aggiornare i report OLAP in MS Excel che si trovano sul loro file computer locali.) Gli utenti al di fuori della rete locale riceveranno report originali, ma con funzionalità limitate, oppure per loro (dopo aver aggiornato i report OLAP in MS Excel) verranno calcolati report speciali "morti" che non accedono al server SSAS.

Valutazione dei risultati

Abbiamo parlato in precedenza dell'asincronia tra OLTP e OLAP. Nella variante tecnologica in esame, il ciclo di aggiornamento del cubo OLAP viene eseguito di notte (ad esempio inizia all'1 di notte). Ciò significa che nella giornata lavorativa corrente gli utenti lavorano con i dati di ieri. Poiché OLAP non è uno strumento di registrazione (guarda l'ultima revisione del documento), ma uno strumento di gestione (comprendi l'andamento del processo), tale ritardo solitamente non è critico. Tuttavia, se necessario, anche nella versione descritta dell'architettura cubica (MOLAP), l'aggiornamento può essere effettuato più volte al giorno.

Il tempo di esecuzione delle procedure di aggiornamento dipende dalle caratteristiche di progettazione del cubo OLAP (più o meno complessità, definizioni più o meno riuscite di indicatori e sezioni) e dal volume dei database dei sistemi OLTP esterni. Secondo l'esperienza, la procedura di costruzione del magazzino dura da alcuni minuti a due ore, la procedura di aggiornamento del cubo (Processo) dura da 1 a 20 minuti. Stiamo parlando di cubi OLAP complessi che uniscono dozzine di strutture a stella, dozzine di "raggi" comuni (sezioni di riferimento) per loro e centinaia di indicatori. Stimando il volume dei database dei sistemi ERP esterni basati sui documenti di spedizione, parliamo di centinaia di migliaia di documenti e, di conseguenza, di milioni di linee di prodotti all'anno. La profondità di elaborazione storica di interesse per l'utente era compresa tra tre e cinque anni.

La tecnologia descritta è utilizzata in numerosi grandi aziende: dal 2008 nella Russian Fish Company (RRK) e nella Russian Sea company (RM), dal 2012 nella compagnia Santa Bremor (SB). Alcune società sono principalmente società commerciali e di acquisto (PPC), altre sono società di produzione (impianti di lavorazione del pesce e dei frutti di mare nella Repubblica di Moldavia e nella Repubblica di Bielorussia). Tutte le società sono grandi holding, che uniscono diverse società con sistemi contabili informatici indipendenti e vari, che vanno dai sistemi ERP standard come 1C7 e 1C8 ai sistemi contabili "reliquia" basati su DBF ed Excel. Aggiungerò che la tecnologia descritta per il funzionamento dei cubi OLAP (senza tener conto della fase di sviluppo) non richiede affatto dipendenti speciali o è responsabilità di un analista aziendale a tempo pieno. Il problema circola da anni Modalità automatica, fornendo quotidianamente alle diverse categorie di dipendenti aziendali una reportistica aggiornata.

Pro e contro della soluzione

L'esperienza dimostra che la soluzione proposta è abbastanza affidabile e facile da usare. È facilmente modificabile (connessione/disconnessione di nuovi ERP, creazione di nuovi indicatori e sezioni, creazione e modifica di report Excel e relative mailing list) con invarianza programma di controllo facubi.

MS Excel come interfaccia con OLAP offre sufficiente espressività e consente a diverse categorie di impiegati di familiarizzare rapidamente con la tecnologia OLAP. L'utente riceve report OLAP “standard” giornalieri; utilizzando l'interfaccia MS Excel con OLAP, è possibile creare in modo indipendente report OLAP in MS Excel. Inoltre, l'utente può continuare in modo indipendente a studiare le informazioni dei report OLAP utilizzando le consuete funzionalità del suo MS Excel.

Il database di magazzino “raffinato”, in cui vengono consolidati più sistemi ERP eterogenei (in fase di costruzione del cubo), anche senza alcun OLAP, consente di risolvere (su server SSAS, utilizzando il metodo query in Transact SQL o il metodo SP , ecc.) molti problemi di gestione applicata. Ricordiamo che la struttura del database di magazzino è unificata e molto più semplice (in termini di numero di tabelle e numero di campi della tabella) rispetto alle strutture di database dell'ERP originale.

Notiamo in particolare che nella nostra soluzione proposta esiste la possibilità di consolidare diversi sistemi ERP in un cubo OLAP. Ciò consente di ottenere analisi per l'intera azienda e mantenere la continuità a lungo termine nelle analisi quando una società passa a un altro sistema ERP contabile, ad esempio quando passa da 1C7 a 1C8.

Abbiamo utilizzato il modello del cubo MOLAP. I vantaggi di questo modello sono l'affidabilità operativa e l'elevata velocità di elaborazione delle richieste degli utenti. Svantaggi: OLAP e OLTP sono asincroni, così come grandi quantità di memoria per l'archiviazione di OLAP.

In conclusione, ecco un altro argomento a favore dell’OLAP che avrebbe potuto essere più appropriato nel Medioevo. Perché il suo potere probatorio si basa sull'autorità. Un matematico britannico modesto e chiaramente sottovalutato, E. Codd, sviluppò la teoria dei database relazionali alla fine degli anni '60. La forza di questa teoria era tale che ora, dopo 50 anni, è già difficile trovare un database non relazionale e un linguaggio di interrogazione del database diverso da SQL.

La tecnologia OLTP, basata sulla teoria dei database relazionali, è stata la prima idea di E. Codd. In effetti, il concetto dei cubi OLAP è la sua seconda idea, espressa da lui all'inizio degli anni '90. Anche senza essere un matematico, puoi aspettarti che la seconda idea sarà efficace quanto la prima. In termini di analisi informatica, le idee OLAP presto conquisteranno il mondo e sostituiranno tutte le altre. Semplicemente perché il tema dell’analisi trova nell’OLAP la sua completa soluzione matematica, e questa soluzione è “adeguata” (termine di B. Spinoza) al problema pratico dell’analisi. “Adeguatamente” significa in Spinoza che Dio stesso non avrebbe potuto pensare a niente di meglio...

1. Larson B. Sviluppo di analisi aziendali in Microsoft SQL Server 2005. – San Pietroburgo: “Peter”, 2008.
2. Codd E. Completezza relazionale dei sottolinguaggi dei database, sistemi di database, Courant Computer Science Sumposia Series 1972, v. 6, scogliere di Englwood, N.Y., Prentice – Hall.

In contatto con

Forse per alcuni, l'uso della tecnologia OLAP (On-line Analytic Processing) durante la creazione di report sembrerà alquanto esotico, quindi l'uso di OLAP-CUBE per loro non è affatto uno dei requisiti più importanti quando si automatizza il budget e la contabilità di gestione.

In realtà è molto comodo da usare CUBO multidimensionale quando si lavora con il reporting gestionale. Quando sviluppi formati di budget, potresti incontrare il problema dei moduli multivariati (puoi leggere ulteriori informazioni al riguardo nel Libro 8, "Tecnologia per impostare il budget in un'azienda" e nel libro "Impostazione e automazione della contabilità di gestione").

Ciò è dovuto al fatto che una gestione efficace di un’azienda richiede una reportistica gestionale sempre più dettagliata. Cioè, il sistema utilizza sezioni analitiche sempre più diverse (in sistemi di informazione le analisi sono definite da una serie di libri di riferimento).

Naturalmente, ciò porta al fatto che i manager desiderano ricevere report in tutte le sezioni analitiche che li interessano. Ciò significa che i resoconti devono essere fatti “respirare” in qualche modo. In altre parole, possiamo dire che in questo caso stiamo parlando del fatto che lo stesso rapporto dovrebbe fornire informazioni sotto diversi aspetti analitici. Pertanto, i report statici non sono più adatti a molti manager moderni. Hanno bisogno della dinamica che un CUBO multidimensionale può fornire.

Pertanto, la tecnologia OLAP è già diventata un elemento obbligatorio nei sistemi informativi moderni e futuri. Pertanto, quando si sceglie un prodotto software, è necessario prestare attenzione al fatto che utilizzi la tecnologia OLAP.

Inoltre bisogna saper distinguere i CUBI veri da quelli imitati. Una di queste simulazioni sono le tabelle pivot in MS Excel. Sì, questo strumento assomiglia a un CUBO, ma in realtà non lo è, poiché si tratta di tabelle statiche, non dinamiche. Inoltre, hanno un'implementazione molto peggiore della capacità di creare report utilizzando elementi provenienti da directory gerarchiche.

Per confermare l'importanza dell'utilizzo di CUBE nella costruzione del reporting gestionale, possiamo fornire un semplice esempio con un budget di vendita. Nell'esempio in esame risultano rilevanti per l'azienda le seguenti sezioni analitiche: prodotti, filiali e canali di vendita. Se queste tre analisi sono importanti per l'azienda, il budget delle vendite (o report) può essere visualizzato in diverse versioni.

Va notato che se si creano linee di budget basate su tre sezioni analitiche (come nell'esempio in esame), ciò consente di creare modelli di budget piuttosto complessi e creare report dettagliati utilizzando CUBE.

Ad esempio, un budget di vendita può essere compilato utilizzando solo un'analisi (directory). Viene presentato un esempio di budget di vendita costruito sulla base di un'analisi "Prodotti". Figura 1.

Riso. 1. Un esempio di budget di vendita costruito sulla base di un'analisi "Prodotti" in OLAP-CUBE

Lo stesso budget di vendita può essere compilato utilizzando due analitiche (directory). Viene presentato un esempio di budget di vendita costruito sulla base di due analisi "Prodotti" e "Filiali". figura 2.

Riso. 2. Un esempio di budget di vendita costruito sulla base di due "Prodotti" e "Filiali" di analisi nell'OLAP-CUBE del pacchetto software INTEGRAL

.

Se è necessario creare report più dettagliati, lo stesso budget di vendita può essere compilato utilizzando tre analisi (directory). Un esempio di budget di vendita costruito sulla base di tre analisi "Prodotti", "Filiali" e "Canali di vendita" è presentato in Figura 3.

Riso. 3. Un esempio di budget di vendita costruito sulla base di tre analisi "Prodotti", "Filiali" e "Canali di vendita" nell'OLAP-CUBE del pacchetto software INTEGRAL

È bene ricordare che il CUBO utilizzato per generare i report permette di visualizzare i dati in diverse sequenze. SU Figura 3 Il budget di vendita viene prima “ampliato” per prodotto, poi per filiale e infine per canale di vendita.

Gli stessi dati possono essere presentati in una sequenza diversa. SU Figura 4 lo stesso budget di vendita viene “ampliato” prima per prodotto, poi per canale di vendita e infine per filiale.

Riso. 4. Un esempio di budget di vendita costruito sulla base di tre analisi "Prodotti", "Canali di distribuzione" e "Filiali" nell'OLAP-CUBE del pacchetto software INTEGRAL

SU Figura 5 lo stesso budget di vendita viene “dispiegato” prima per filiali, poi per prodotti, quindi per canali di vendita.

Riso. 5. Un esempio di budget di vendita costruito sulla base di tre analisi "Filiali", "Prodotti" e "Canali di vendita" nel pacchetto software OLAP-CUBE "INTEGRAL"

In realtà non è tutto possibili opzioni ritiro del budget di vendita.

Inoltre, devi prestare attenzione al fatto che CUBE ti consente di lavorare struttura gerarchica libri di riferimento. Negli esempi presentati, le directory gerarchiche sono “Prodotti” e “Canali Distributivi”.

Dal punto di vista dell'utente, in questo esempio riceve diversi report di gestione (vedi. Riso. 1-5), e dal punto di vista delle impostazioni in prodotto software- questo è un rapporto. Semplicemente utilizzando il CUBO è possibile visualizzarlo in diversi modi.

Naturalmente, in pratica, è possibile un numero molto elevato di opzioni per la produzione di vari report di gestione se i loro articoli sono basati su uno o più analisti. E l’insieme di analisi stesso dipende dalle esigenze di dettaglio degli utenti. È vero, non dobbiamo dimenticare che, da un lato, quanto più grande è l'analista, tanto più dettagliati possono essere costruiti i resoconti. Ma, d’altro canto, ciò significa che il modello di bilancio finanziario sarà più complesso. In ogni caso, qualora sia presente un KUB, l'azienda avrà la possibilità di visionare la reportistica necessaria in diverse versioni, secondo le sezioni analitiche di interesse.

È necessario menzionare molte altre funzionalità dell'OLAP-CUBE.

In un CUBO OLAP gerarchico multidimensionale ci sono diverse dimensioni: tipo di riga, data, righe, directory 1, directory 2 e directory 3 (vedi. Riso. 6). Naturalmente nel report vengono visualizzati tanti pulsanti con directory quanti ce ne sono nella linea di budget contenente il numero massimo di directory. Se non è presente un solo libro di consultazione in nessuna linea di budget, il rapporto non avrà un solo pulsante con i libri di consultazione.

Inizialmente, l'OLAP-CUBE è costruito lungo tutte le dimensioni. Per impostazione predefinita, quando il report viene creato inizialmente, le dimensioni si trovano esattamente nelle aree mostrate in Figura 6. Cioè, una dimensione come "Data" si trova nell'area delle dimensioni verticali (dimensioni nell'area delle colonne), dimensioni "Righe", "Directory 1", "Directory 2" e "Directory 3" - nella area delle dimensioni orizzontali (dimensioni nelle righe dell'area) e la dimensione "Tipo riga" si trova nell'area delle dimensioni "non espanse" (dimensioni nell'area della pagina). Se una dimensione si trova nell'ultima area, i dati nel rapporto non si "espanderanno" su quella dimensione.

Ognuna di queste dimensioni può essere posizionata in una qualsiasi delle tre aree. Una volta trasferite le misurazioni, il report viene immediatamente ricostruito per corrispondere alla nuova configurazione di misurazione. Ad esempio, puoi scambiare la data e le righe con i libri di consultazione. Oppure puoi spostare uno dei libri di consultazione nell'area di misurazione verticale (vedi. Riso. 7). In altre parole, è possibile “torcere” il report nell'OLAP-CUBE e selezionare l'opzione di output del report più conveniente per l'utente.

Riso. 7. Un esempio di ricostruzione di un report dopo aver modificato la configurazione di misura del pacchetto software INTEGRAL

La configurazione della misura può essere modificata sia nella maschera principale di CUBE che nell'editor di modifica mappa (vedi. Riso. 8). In questo editor puoi anche trascinare e rilasciare le misurazioni da un'area all'altra con il mouse. Inoltre, puoi scambiare le misurazioni in un'area.

Inoltre nello stesso modulo è possibile configurare alcuni parametri di misura. Per ciascuna dimensione è possibile personalizzare la posizione dei totali, l'ordinamento degli elementi e i nomi degli elementi (vedi. Riso. 8). È inoltre possibile specificare quale nome dell'elemento visualizzare nel report: abbreviato (Name) o completo (FullName).

Riso. 8. Editor delle mappe di misura del pacchetto software INTEGRAL

È possibile modificare i parametri di misurazione direttamente in ciascuno di essi (vedi. Riso. 9). Per fare ciò, fare clic sull'icona situata sul pulsante accanto al nome della misurazione.

Riso. 9. Esempio di modifica della directory 1 Prodotti e servizi in

Utilizzando questo editor, puoi selezionare gli elementi che desideri mostrare nel report. Per impostazione predefinita, tutti gli elementi vengono visualizzati nel report, ma, se necessario, alcuni elementi o cartelle possono essere omessi. Ad esempio, se desideri visualizzare un solo gruppo di prodotti nel report, devi deselezionare tutti gli altri nell'editor delle misurazioni. Successivamente, il report conterrà un solo gruppo di prodotti (vedi. Riso. 10).

Puoi anche ordinare gli elementi in questo editor. Inoltre, gli elementi possono essere riorganizzati diversi modi. Dopo tale raggruppamento, il report viene immediatamente ricostruito.

Riso. 10. Esempio di output in un report di un solo gruppo di prodotti (cartella) nel pacchetto software INTEGRAL

Nell'editor delle dimensioni puoi creare rapidamente i tuoi gruppi, trascinare e rilasciare gli elementi dalle directory, ecc. Per impostazione predefinita, viene creato automaticamente solo il gruppo Altro, ma è possibile creare altri gruppi. Pertanto, utilizzando l'editor delle dimensioni, è possibile configurare quali elementi dei libri di consultazione e in quale ordine devono essere visualizzati nel report.

Va notato che tutti questi riarrangiamenti non vengono registrati. Cioè, dopo aver chiuso il report o dopo il suo ricalcolo, tutte le directory verranno visualizzate nel report secondo la metodologia configurata.

In effetti, tutte queste modifiche avrebbero potuto essere apportate inizialmente durante l'impostazione delle linee.

Utilizzando le restrizioni è possibile ad esempio specificare anche quali elementi o gruppi di directory devono essere visualizzati nel report e quali no.

Nota: l'argomento di questo articolo viene discusso in modo più approfondito nei workshop "Gestione del budget di un'impresa" E "Organizzazione e automazione della contabilità di gestione" condotto dall'autore di questo articolo, Alexander Karpov.

Se l'utente ha bisogno quasi regolarmente di visualizzare solo determinati elementi o cartelle di directory nel report, è meglio definire tali impostazioni in anticipo durante la creazione delle righe del report. Se per l'utente sono importanti diverse combinazioni di elementi di directory nei report, non è necessario impostare alcuna restrizione durante l'impostazione della metodologia. Tutte queste restrizioni possono essere configurate rapidamente utilizzando l'editor di misurazione.

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 che dovresti fare è creare Progetto SSAS utilizzando le offerte. 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. Crea un 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. Innanzitutto, la procedura guidata ti guida attraverso il processo di creazione di un oggetto e 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 origine 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

Un file cubo autonomo (.cub) archivia i dati in un modulo in un cubo OLAP (Online Analytical Processing). Questi dati possono rappresentare parte di un database OLAP da un server OLAP oppure possono essere stati creati indipendentemente da qualsiasi database OLAP. Per continuare a utilizzare i rapporti di tabella pivot e grafico pivot quando il server non è disponibile o quando è offline, utilizzare un file cubo offline.

Ulteriori informazioni sui cubi offline

Quando si utilizza un rapporto di tabella pivot o grafico pivot basato su un'origine dati di un server OLAP, utilizzare la Creazione guidata cubo offline per copiare i dati di origine in un file del cubo offline separato nel computer. Per creare questi file offline, è necessario disporre di un provider di dati OLAP che supporti queste funzionalità, ad esempio MSOLAP di Microsoft SQL Server Analysis Services, installato nel computer.

Nota: Creazione e utilizzo di file cubo offline da Microsoft SQL Server Analysis Services, soggetti a termini e licenze Installazioni Microsoft Server SQL. Esamina le informazioni sulla licenza appropriate per la tua versione di SQL Server.

Utilizzo della procedura guidata del cubo offline

Per creare un file di cubo offline, utilizzare la Creazione guidata cubo offline per selezionare un sottoinsieme di dati nel database OLAP, quindi salvare il set. Non è necessario che il report includa tutti i campi inclusi nel file ed è possibile selezionare qualsiasi dimensione e campo dati disponibile nel database OLAP. Per ridurre al minimo le dimensioni del file, puoi includere solo i dati che desideri visualizzare nel report. È possibile ignorare tutte le dimensioni e, per la maggior parte dei tipi di dimensioni, anche i dettagli e le funzionalità di livello inferiore livello superiore, che non è necessario visualizzare. Per un file offline, vengono salvati anche tutti gli elementi che possono essere inclusi nei campi delle proprietà disponibili nel database per tali elementi.

Portare i dati offline e quindi riportarli online

A tale scopo, è necessario innanzitutto creare un rapporto di tabella pivot o di grafico pivot basato sul database del server, quindi creare un file cubo autonomo dal rapporto. Successivamente, quando si lavora con un report, è possibile passare in qualsiasi momento dal database del server al file offline (ad esempio, quando si lavora su un laptop a casa o in viaggio e quindi si ricollega il computer alla rete).

Di seguito vengono descritti i passaggi di base per portare i dati offline e riportarli online.

Nota:

Fare clic sul rapporto di tabella pivot. Se si tratta di un rapporto di grafico pivot, seleziona il rapporto di tabella pivot associato.

Sulla "scheda" Analisi" in gruppo calcoli fare clic sul pulsante Servizio OLAP e premere il pulsante OLAP offline.

seleziona un oggetto OLAP con connettività e quindi fare clic sul pulsante OK.

Se viene richiesto di trovare un'origine dati, fare clic su Trova la fonte e trovare un server OLAP sulla rete.

Fare clic sul rapporto di tabella pivot basato sul file del cubo offline.

In Excel 2016: nella scheda " dati" in gruppo richieste e collegamenti Aggiorna tutto e premere il pulsante Aggiornamento.

In Excel 2013: nella scheda " dati" in gruppo connessioni fare clic sulla freccia accanto al pulsante Aggiorna tutto e premere il pulsante Aggiornamento.

Sulla "scheda" Analisi" in gruppo calcoli fare clic sul pulsante Servizio OLAP e premere il pulsante OLAP offline.

Fare clic sul pulsante Modalità OLAP offline, poi - .

Nota: Fermare nella finestra di dialogo.

Avvertimento:

Creazione di un file cubo offline da un database del server OLAP

Nota: Se il database OLAP è di grandi dimensioni e il file del cubo è necessario per fornire l'accesso a un ampio sottoinsieme di dati, molti spazio libero su disco e il salvataggio del file potrebbe richiedere molto tempo. Per migliorare le prestazioni, è consigliabile creare file di cubi autonomi utilizzando uno script MDX.

Problema: il mio computer non dispone di spazio su disco sufficiente durante il salvataggio di un cubo.

I database OLAP sono progettati per gestire grandi quantità di dati dettagliati, pertanto un database ospitato su un server può occupare molto più spazio di quello disponibile sul disco rigido locale. Se selezioni una grande quantità di dati per un cubo di dati offline, potresti non avere abbastanza spazio libero su disco. L'approccio seguente consentirà di ridurre la dimensione del file del cubo offline.

Liberare spazio su disco o selezionare un disco diverso Prima di salvare il file del cubo, rimuoverlo dal disco. file non necessari o salvare il file su un'unità di rete.

Includere meno dati in un file cubo offline Considera come ridurre al minimo la quantità di dati inclusi nel file in modo che il file contenga tutti i dati necessari per un rapporto di tabella pivot o un grafico pivot. Prova i passaggi seguenti.

Connessione di un file cubo offline a un database del server OLAP

Aggiornamento e ricreazione di un file cubo offline

L'aggiornamento di un file cubo offline creato dai dati più recenti ottenuti da un cubo server o da un nuovo file cubo offline può richiedere molto tempo e una grande quantità di spazio su disco temporaneo. Esegui questo processo quando non hai bisogno dell'accesso immediato ad altri file, dopo esserti assicurato di avere spazio sufficiente sul disco rigido.

Problema: i nuovi dati non vengono visualizzati nel report una volta aggiornato.

Verifica della disponibilità del database di origine Il file del cubo offline potrebbe non essere in grado di connettersi al database del server di origine per ottenere nuovi dati. Assicurarsi che il database originale sul server che costituisce l'origine dati per il cubo non sia stato rinominato o spostato in un'altra posizione. Assicurati che il server sia accessibile e possa essere connesso.

Controllo di nuovi dati Rivolgiti all'amministratore del database per verificare se i dati da includere nel report sono stati aggiornati.

Verifica dell'immutabilità dell'organizzazione del database Se Cubo OLAP server è stato modificato, l'accesso ai dati modificati potrebbe richiedere la riorganizzazione del report, la creazione di un file del cubo offline o l'esecuzione della Creazione guidata cubo OLAP. Per informazioni sulle modifiche al database, contatta l'amministratore del database.

Inclusi altri dati nel file del cubo offline

Il salvataggio di un file cubo offline modificato può richiedere molto tempo e richiede lavoro Microsoft Excel non è possibile durante il salvataggio del file. Esegui questo processo quando non hai bisogno dell'accesso immediato ad altri file, dopo esserti assicurato di avere spazio sufficiente sul disco rigido.

Verificare che sia disponibile una connessione di rete e che il database del server OLAP di origine da cui il file del cubo offline ha ottenuto i dati sia accessibile.

Fare clic su un rapporto di tabella pivot creato da un file cubo autonomo o su un rapporto di tabella pivot associato per un rapporto di grafico pivot.

Sulla scheda Opzioni in gruppo Servizio fare clic sul pulsante Servizio OLAP e premere il pulsante Modalità OLAP offline.

Fare clic sul pulsante Modalità OLAP offline, poi - Modifica file di dati offline.

Seguire la procedura guidata del cubo offline per selezionare altri dati da includere in questo file. Nell'ultimo passaggio, specificare il nome e il percorso del file da modificare.

Nota: Per annullare il salvataggio del file, fare clic sul pulsante Fermare nella finestra di dialogo Creazione di un file cubo: progresso.

Eliminazione di un file cubo offline

Avvertimento: Se si elimina un file cubo offline per un report, non è più possibile utilizzare il report offline e non è più possibile creare un file cubo offline per quel report.

Chiudere tutte le cartelle di lavoro che contengono report che utilizzano il file del cubo offline oppure assicurarsi che tutti questi report vengano eliminati.

IN Microsoft Windows Individuare ed eliminare il file del cubo offline (file CUB).

Informazioni aggiuntive

Puoi sempre porre una domanda a uno specialista della community tecnica di Excel, chiedere aiuto nella community Risposte e anche suggerire nuova caratteristica o miglioramenti sul sito web

In una tabella pivot standard, i dati di origine vengono archiviati sul disco rigido locale. In questo modo potrai sempre gestirli e riorganizzarli, anche senza accesso alla rete. Ma questo non si applica in alcun modo alle tabelle pivot OLAP. Nelle tabelle pivot OLAP la cache non viene mai archiviata sul disco rigido locale. Pertanto, subito dopo esserti disconnesso dalla rete locale, la tua tabella pivot non funzionerà più. Non sarai in grado di spostare un singolo campo al suo interno.

Se è ancora necessario analizzare i dati OLAP dopo essere passati offline, creare un cubo di dati offline. Un cubo di dati offline è un file separato che funge da cache della tabella pivot e archivia i dati OLAP visualizzati dopo la disconnessione dalla rete locale. I dati OLAP copiati in una tabella pivot possono essere stampati; ciò è descritto in dettaglio sul sito http://everest.ua.

Per creare un cubo di dati autonomo, creare prima una tabella pivot OLAP. Posiziona il cursore all'interno della tabella pivot e fai clic sul pulsante Strumenti OLAP nella scheda contestuale Strumenti, che fa parte del gruppo di schede contestuali Strumenti tabella pivot. Selezionare il comando OLAP offline (Fig. 9.8).

Sullo schermo viene visualizzata la finestra di dialogo Impostazioni cubo dati OLAP offline. Fare clic sul pulsante Crea file di dati offline. È stata avviata la creazione guidata del file del cubo di dati. Fare clic sul pulsante Avanti per continuare la procedura.

Per prima cosa è necessario specificare le dimensioni e i livelli che verranno inclusi nel cubo di dati. Nella finestra di dialogo è necessario selezionare i dati che verranno importati dal database OLAP. L'idea è specificare solo le dimensioni che saranno necessarie dopo che il computer sarà disconnesso dalla rete locale. Più dimensioni specifichi, più grande sarà il cubo di dati autonomo.

Fare clic sul pulsante Avanti per passare alla finestra di dialogo della procedura guidata successiva. Ciò offre la possibilità di specificare membri o elementi dati che non verranno inclusi nel cubo. In particolare, non sarà necessaria la misura Importo esteso delle vendite su Internet, pertanto la relativa casella di controllo verrà deselezionata nell'elenco. Una casella di controllo deselezionata indica che l'elemento specificato non verrà importato e occuperà spazio non necessario sul disco rigido locale.

Nell'ultimo passaggio, specificare la posizione e il nome del cubo di dati. Nel nostro caso, il file del cubo si chiamerà MyOfflineCube.cub e si troverà nella cartella Lavoro.

I file del cubo di dati hanno l'estensione .cucciolo

Dopo un po' di tempo, Excel salverà il cubo di dati offline nella cartella specificata. Per testarlo, fare doppio clic sul file, che genererà automaticamente una lavorazione Cartelle di lavoro di Excel, che contiene una tabella pivot associata al cubo di dati selezionato. Una volta creato, puoi distribuire il cubo di dati offline a tutti gli utenti interessati che lavorano in modalità LAN offline.

Una volta connesso alla rete locale, puoi aprire il file del cubo di dati offline e aggiornarlo insieme alla tabella di dati associata. Il principio fondamentale afferma che il cubo di dati offline viene utilizzato solo per funzionare quando la rete locale è disconnessa, ma è necessario aggiornarlo una volta ripristinata la connessione. Il tentativo di aggiornare un cubo di dati offline dopo un errore di connessione comporterà un errore.