Essbase

rdf:langString Essbase

rdf:langString Essbase è un sistema di gestione di database multidimensionale (MDBMS) che fornisce una piattaforma di database multidimensionale su cui costruire applicazioni analitiche. Essbase, il cui nome deriva da "database esteso per fogli di calcolo", è nato come prodotto di Arbor Software, che si è fusa in Hyperion Software nel 1998. Oracle Corporation ha acquisito Hyperion Solutions Corporation nel 2007, dal 2009 Oracle ha commercializzato Essbase come "Oracle Essbase" (un prodotto locale) e, più recentemente, Essbase viene offerto come parte di Oracle Analytics Cloud. Fino alla fine del 2005 IBM commercializzava anche una versione OEM di Essbase come DB2 OLAP Server. Il ricercatore di database EF Codd ha coniato il termine "elaborazione analitica on-line" ( OLAP ) in un white paper che stabilisce dodici regole per i sistemi analitici (un'allusione alla sua precedente serie di dodici regole che definiscono il modello relazionale ). Questo white paper, pubblicato da Computerworld, era in qualche modo esplicito nel suo riferimento alle funzionalità di Essbase, e quando in seguito fu scoperto che Codd era stato sponsorizzato da Arbor Software, Computerworld ritirò il documento. A differenza della "elaborazione delle transazioni online" ( OLTP ), OLAP definisce una tecnologia di database ottimizzata per l'elaborazione di query di alto livello anziché delle transazioni. I risultati di questo orientamento sono stati che i database multidimensionali orientavano i loro requisiti di prestazione attorno a una serie diversa di parametri di riferimento (Analytic Performance Benchmark, APB-1) rispetto a quello di RDBMS ( Transaction Processing Performance Council (TPC)). Hyperion ha ribattezzato molti dei suoi prodotti nel 2005, dando a Essbase un nome ufficiale di Hyperion System 9 BI + Analytic Services, ma il nuovo nome è stato ampiamente ignorato dai professionisti. Il marchio Essbase è stato in seguito restituito al nome ufficiale del prodotto per scopi di marketing, ma il software del server portava ancora il titolo "Analytic Services" fino a quando non è stato incorporato nel prodotto Oracle Business Intelligence Foundation Suite (BIFS). Nell'agosto 2005, la rivista Information Age ha nominato Essbase come una delle 10 innovazioni tecnologiche più influenti degli ultimi 10 anni, insieme a Netscape, BlackBerry, Google, virtualizzazione, Voice Over IP ( VOIP ), Linux, XML, il Processore Pentium e ADSL . L'editore Kenny MacIver ha dichiarato: "Hyperion Essbase è stata la tecnologia di database multidimensionale che ha messo l'elaborazione analitica online nel mondo della business intelligence. Ha stimolato la creazione di decine di prodotti OLAP rivali e miliardi di cubi OLAP ". Sebbene Essbase è stato classificato come database multidimensionale generico, è stato originariamente sviluppato per risolvere i problemi di scalabilità associati a fogli di calcolo come Lotus 1-2-3 e Microsoft Excel . In effetti, il brevetto che copre (ora scaduto) Essbase utilizza fogli di calcolo come esempio motivante per illustrare la necessità di un tale sistema. In questo contesto, "multidimensionale" si riferisce alla rappresentazione di dati finanziari in formato foglio elettronico. Un tipico foglio di calcolo può visualizzare intervalli di tempo lungo le intestazioni di colonna e i nomi degli account nelle intestazioni di riga. Per esempio: Se un utente desidera suddividere questi valori per regione, ad esempio, ciò comporta in genere la duplicazione di questa tabella su più fogli di calcolo: Una rappresentazione alternativa di questa struttura richiederebbe una griglia di foglio di calcolo tridimensionale, dando origine all'idea che "Tempo", "Conto" e "Regione" sono dimensioni di analisi. Man mano che vengono aggiunte ulteriori dimensioni al sistema, diventa molto difficile mantenere fogli di calcolo che rappresentano correttamente i valori multidimensionali. Database multidimensionali come Essbase forniscono un archivio dati per valori che esistono, almeno concettualmente, in un " ipercubo " multidimensionale. Con l'aumentare del numero e delle dimensioni delle dimensioni, gli sviluppatori di database multidimensionali affrontano sempre più problemi tecnici nella rappresentazione fisica dei dati. Supponiamo che l'esempio sopra sia stato esteso per aggiungere una dimensione di analisi "Cliente" e "Prodotto": Se il database multidimensionale riservasse spazio di archiviazione per ogni possibile valore, sarebbe necessario memorizzare 2.400.000.000 (4 × 4 × 3 × 10.000 × 5.000) celle. Se il software mappa ogni cella come un valore in virgola mobile a 64 bit, ciò equivale a un requisito di memoria di almeno 17 gigabyte (esattamente 19.2 GB). Nella realtà ovviamente, il numero di combinazioni di "Cliente" e "Prodotto" che contengono valori significativi sarà un piccolo sottoinsieme dello spazio totale. Questa proprietà degli spazi multidimensionali viene definita scarsità. I sistemi OLAP generalmente forniscono livelli multipli di dettaglio all'interno di ciascuna dimensione disponendo i membri di ciascuna dimensione in una o più gerarchie . Una dimensione temporale, ad esempio, può essere rappresentata come una gerarchia che inizia con "Tempo totale" e si suddivide in più anni, quindi trimestri, quindi mesi. Una dimensione Conti può iniziare con "Margine", che si divide in "Ricavi" e "Costi" e così via. Nell'esempio sopra, se "Prodotto" rappresenta SKU di singoli prodotti, gli analisti potrebbero anche voler creare report utilizzando aggregazioni come "Gruppo di prodotti", "Famiglia di prodotti", "Linea di prodotti", ecc. Allo stesso modo, per "Cliente", aggregazioni naturali possono organizzare i clienti in base alla posizione geografica o al settore. Il numero di valori aggregati impliciti da un insieme di dati di input può diventare sorprendentemente grande. Se le dimensioni del cliente e del prodotto sono ciascuna in profondità sei "generazioni", allora 36 (6 × 6) valori aggregati sono influenzati da un singolo punto dati. Ne consegue che se tutti questi valori aggregati devono essere memorizzati, la quantità di spazio richiesta è proporzionale al prodotto della profondità di tutte le dimensioni di aggregazione. Per database di grandi dimensioni, ciò può far sì che i requisiti di archiviazione effettivi siano centinaia di volte le dimensioni dei dati da aggregare.