Volendo semplificare per approccio NON tradizionale alla BI vogliamo intendere che non adoperiamo gli standard dell’operatività di una iniziativa di business intelligence all’interno di un’azienda.
I campi dove impatta maggiormente questo “nuovo” modo di pensare la BI sono l’ETL che va praticamente a scomparire nella parte di TRANSFORM dell’equazione fermandosi al Extraction e passando direttaemente al Loading.
Tramite delle viste materializzate direttamente nel sistema OLTP vengono “duplicate” le tabelle tradizionali creando delle viste normalizzate dei dati.
Così facendo si “aggredisce” anche un altro “totem” della BI “classica”, il cosiddetto Star Schema, sostituendo le Fact Tables con tabelle o rappresentazioni “FLAT” dei dati oggetto di analisi.
Chiaramente dobbiamo comunque dotarci di un sistema dove “parcheggiare” i dati, dove poterli lavorare e di un ambiente dove poterli PRESENTARE.
Abbiamo individuato nel software opensource coreBOS lo strumento ideale per poterlo fare.
http://www.corebos.org - il software centrale per la creaziione dell’intera suite
Piccola storia per spiegare come è cominciato il tutto:
Evolutivo è questo… i purple people between IT and Business Users.
“Stephen Wright was hired most recently by IT. That’s who usually hires him. He’s a database administrator, so he’s most comfortable in those clothes. They want only for him to take care of the database while the business people — those dangerous data moochers — suck the database of its vital juices.
His trick, though, is more subtle than running a database. He says all he really does is give the business users — Tableau users, in his current job — what they want: access to data.
Why, you ask, can’t an existing DBA do this? Are none of them smart enough? Are they too frightened? Are there no executives courageous enough to simply slam a fist down and tell them to do it? None of those.
The typical IT worker, he explains, is that they simply never will do this. He cites a 40-year-old book that explained the nerdy mind: Gerald Weinberg in The Psychology of Computer Programming explains how the nerd will never do things the easy way when there’s a hard way to do it. “They’re always tuning,” Wright says “and they’ll wreck your company doing it.”
Ted Corbett, a consultant I met years ago at an earlier Tableau conference — noted in a keynote then for putting Tableau in Seattle Children’s Hospital — does the same but has a slightly different view.
He came from the business side. Now at a job in Sacramento, he says the business people he works with prefer numbers. “They don’t seem to trust charts,” he says. Charts are good for exploring, but business people are just as risk-averse as most IT people.Is the trend improving? He thinks about it: Yeah, a little.
I’ve never heard before that business people prefer rows and columns, and it’s sure not what I’d expect from a Tableau partisan. But the purple people are their own people.
“
http://datadoodle.com/2013/09/12/men-in-the-middle-see-both-sides-of-the-it-business-split/
Gli strumenti più importanti per ottenere il risultato sono individuati in 2 strumenti.
Il primo è un portale ad uso dei membri della comunità Evolutivo. Questo portale è un vero è proprio Toolbox per poter creare script di caricamento dati, script di generazione di tabelle “flat” relazionate a entità “padre”, strumenti di reportistica. Si tratta di uno strumento compatibile con la maggior parte degli strumenti CRM derivati da sugar CRM (tra cui ricordiamo il più importante vtiger CRM).
Il secondo è il software vero e proprio, cioè la base per appoggiare tutto l’impianto.
Abbiamo scelto coreBOS (http://www.corebos.org), un fork derivativo di vtigerCRM, in quanto la filosofia promette una stabilità e retrocompatibilità dei rilasci, rimanendo aperto comunque a sviluppi futuri delle 2 comunità principali (appunto Sugar e vtiger).
http://www.evolutivo.it - una iniziativa che raccoglie aziende esperte nei software CRM/BPM basati su stack LAMP o nuove tecnologie MEAN (Node.js - MongoDB)
http://toolbox.evolutivo.it - lo strumento per generare viste, script, reportistica.
http://www.sugarcrm.com/download - Sugar CRM
http://www.vtiger.com - vtigerCRM
The whole application is itself a metadata layer, a database, a presentation layer and a BI server
No, he didn’t do any ETL, Sandy explained. “We didn’t realize how important that was,” he recalled. “We had always just stuck the raw data into the database and then realized, ‘Hey, this data’s a mess.’” He instructed users to clean it themselves. “You get the data from the horse’s mouth. You’re the expert. We didn’t realize how powerful this was.”
In Sandy’s system, you don’t worry about database design. He and his partners not only didn’t worry about ETL, they wondered how data analysis could not be done their way — import first, clean later. “It makes good sense if you can get away with it.”
Uno dei problemi che tenta di risolvere l’ETL è la trasformazione del dato operativo (tabelle per esempio dei pagamenti delle fatture) in un dato “compatibile” con la logica dello Star Schema della BI tradizionale.
In questo paper non vogliamo certamente disconoscere il valore dello Star schema (it helps in various ways including: reducing the # of joins queries might have, reducing the usage of left/right outer for data that is missing)
Ma ci sono stati numerosi miglioramenti nelle tecnologie e in particolare con i database colonnari.
So there would a great benefit by simplifying and “flattening” the model. With a columnar DB, there’s not nearly as much need for complex schemas. In fact, for dimensions that have a built-in hierarchy (like timestamp, for instance), you can simply denormalize that dimension directly into the fact table.
Let’s consider an example..let’s say you have a demographic dimension of sex, being “Male”, “Female”, or “Unknown” and a fact table with 1 billion rows. If you model that dimension in a separate dimension table, then you have essentially 3 rows in that table, one for each distinct value.
What happens if you denormalize that dimension into the 1 billion row fact table…for most of the credible columnar databases, do you get one of those 3 values 1 billon times? Nope…the values are stored column-wise, and then compressed down to the 3 distinct values. So essentially, the storage footprint of storing that dimension in a separate table versus the storage footprint of denormalizing that dimension into the 1 billion row fact table are essentially the same….however, now you don’t have to do a join to get or filter the necessary values. And, it’s also easier for end business users to understand.
So, knowing we’d get similar performance either way, we denormalized our primary schema as much as operationally possible.
Essentially, one update process feeds raw data to the fact table (and this one process has all the elements it’s need to insert/update the fact table), and the dimension tables are sourced directly from the OLTP system.
It’s a simple design, simple to manage, simple to get data into and maintain it, and simple to understand.
https://www.linkedin.com/groups/Does-Star-schema-still-good-2705782.S.268544373 —
There’s a vast pool of data professionals that knows just what to do with the SQL-like select, aggregation, sum and string-matching options that the SQL database provide.
But then there’s the far larger universe of business analysts and professionals who aren’t SQL savvy.
That’s where our “intuition” comes in.
We are proposing to use the internal Query Builder of the application itself .
In effect the Reporting facility of coreBOS itself (or vtigerCRM, sadly not the same for SugarCRM), these business users, they can connect to data source and interact with that information in a visual and intuitive way.
Users of software won’t have to know a thing about data integration or data mapping and will be able to fly through vast data sets with all the visualization options they’re accustomed to in the software.
In the previous section we stressed the importance of end-user accessible BI tools.
Obviously we cannot only rely on “easy” SQL queries, but we need also a simpler approach in creating a set of tools for the reporting applications.
In effect we are building a complementary ecosystem of tools (in Evotoolbox), to help focus business professionals on enabling self-service and empowering them to get more out of their data.
I moduli dell’applicativo rappresentano tabelle di metadati relazionate ad altre entità di metadato.
La definizione del dato stesso quindi viene lasciata al Business User e la mappatura dei campi può avvenire tramite le stesse interfacce del software stesso.
Ogni modulo presenta le stesse funzionalità
Essendo derivato da un CRM/BPM i moduli presentano strumenti di inserimento dati a livello “operational”. Per esempio è possibile inserire moduli per la raccolta diretta di dati, così come azioni massive.
Reso possibile dalle tecnologie moderne:
[] columnar databases (infiniDB)
[] high performance engine (TOKUDB)
Vtapp bla bla bla
Tutto in un client, approccio non tradizionale alla esposizione delle pivot interattive (cubi OLAP).
Non tradizionale per 3 motivi:
Creazione di un tool per l’import di tabelle relazionali all’interno della modularità dell’applicativo.
In pratica viene tutto caricato tramite flat files in formato csv o da tabelle di frontiera anche esse “piatte”.
Non viene trasformato nulla (o quasi) nell’export dalle fonti dati, avviene solo il caricamento (insert / update)
Una interfaccia innovativa per la tecnologia web (facendo uso massivo di client javascript, dove l’elaborazione avviene nel browser dell’utente finale) permette di caricare dati nell’applicativo direttamente da fogli di calcolo o applicativi desktop.
Importantissima funzionalità di caricamento tramite una esposizione di servizi REST e SOAP (parzialmente)
The Vtapp Creator is contained in a section of the Toolbox that is used just as reporting tool exploiting existing reports in coreBOS or predetermined Materialized Views created by a Business user.
The advantages are that the tool can be used independently from any installation of coreBOS, even more times because in fact it is a graphical tool that generates a php-javascript application.
The reports that can be created are much more an analytical tools, as it is possible to create Pivot or Multidimensional applications.
It offers the opportunity for advanced users to create reports from custom queries , thus freeing them from direct queries against the system. The vtapp creator represents graphically the queries generated in the application with some important possibilities (the ability to sort columns, rename them, to group one or more columns, do the research for column etc.).
To have the ability to use the Vtapp Creator, the tool re-creates a schema of the original database (the logic, not the records) and every time the database changes it can be updated.
in questo abbiamo una generazione del cosiddetto ADHOC Reporting, cioè decidiamo a livello di business user quali sono le variabili da implementare a monte della possibilità di visualizzare i dati
Con questo strumento partiamo direttamente da file csv “piatti” ottenuti esportando tabelle MV dal BI server
Punti veramente a favore per costi/opportunità:
E’ uno strumento “solo” per la PMI ?
Utilizzabile come BI dipartimentale dalle grandi aziende, per la semplicità delle tecnologie utilizzate
Roadmap per il 2014:
Si tratta di uno strumento per “sviluppatori” per connettere diverse vtapp in un unico pannello. Vorremmo trasformarlo in uno strumento a prova di utente