START
La decisione oltre al dato
Relazione del progetto formativo svolto presso
l’azienda Sesa spa
Candidata Tutore accademico
Caterina Falchi Franco Turini
Tutori aziendali Moreno Falchi Andrea Biancalani
Corso di Laurea Magistrale in Data Science & Business Informatics Anno accademico 2018/2019
Ai miei genitori, Daniele, Stefania e tutti coloro che mi hanno sostenuto durante questo percorso
Indice
Capitolo 1- Introduzione ... 6
1.1 Presentazione del problema ... 6
1.2 Contenuto della tesi ... 7
Capitolo 2 – Caso di Studio ... 8
2.1 L’azienda: Sesa spa ... 8
2.2 Sistema Informativo pre-esistente ... 8
2.3 Sistema di Business Intelligence pre-esistente ... 9
2.4 Data Warehouse ... 11
2.5 Dai dati alla conoscenza ... 12
2.6 Modelli di Data Mining ... 13
3 – Il progetto ... 16
3.1 Creazione del Data Warehouse ... 16
3.1.1 Fact Table ... 16 3.1.2 Gli Articoli ... 17 3.1.3 I Depositi ... 20 3.1.4 I Clienti ... 21 3.1.5 Le date ... 22 3.1.6 I documenti ... 24
3.1.7 Il nuovo Data Warehouse ... 26
3.2 Processo ETL di caricamento dati ... 28
3.2.1 SQL Server Integration Services ... 28
3.2.2 Sviluppo del processo ETL ... 28
3.2.3 Caricamento degli Articoli ... 30
3.2.4 Caricamento dei Depositi ... 32
3.2.6 Caricamento delle Date ... 33
3.2.7 Caricamento dei Documenti ... 34
3.2.8 Caricamento della tabella dei Fatti ... 34
3.3 Creazione del cubo OLAP ... 36
3.3.1 SQL Server Analysis Services ... 36
3.3.2 Preparazione dei dati ... 37
3.3.3 Creazione delle dimensioni ... 39
3.3.4 Creazione del cubo ... 41
3.4 Creazione delle strutture e dei modelli di Data Mining ... 44
3.4.1 Microsoft Clustering ... 44
3.4.2 Applicazione di Microsoft Clustering ... 47
3.5 Visualizzazione dei risultati ... 55
3.5.1 Visual Analytics ... 55
3.5.2 MVC ... 55
3.5.3 Dashboard START ... 56
4 – Conclusioni, sviluppi futuri e ringraziamenti ... 65
5 – Bibliografia ... 66
5.1 Elenco degli acronimi usati ... 66
5.2 Elenco dei siti consultati ... 66
Capitolo 1- Introduzione
1.1 Presentazione del problema
L’innovazione rappresenta l’elemento trainante di ogni settore tecnologicamente avanzato: nel caso di un'azienda leader nella distribuzione di HW, SW e servizi cloud, la proattività è d'obbligo. Nasce quindi la necessità di anticipare le esigenze dei clienti per proporre loro soluzioni adeguate alle loro attività e coerenti con la loro business vision. Questo rappresenta una comodità per i clienti che possono sperare in servizi sempre più all'avanguardia, ma nello stesso tempo è una sfida per le aziende ormai alle prese con una competizione sempre più spietata.
Proprio per questo motivo si tende a delineare accuratamente non solo la strategia da applicare, ma anche l'ambito in cui concentrare i propri sforzi. L'acquisizione, il mantenimento e la gestione della conoscenza, diventano quindi variabili critiche per il raggiungimento del successo.
Il presente lavoro descrive il progetto formativo svolto a conclusione del Corso di Laurea Magistrale in Data Science & Business Informatics erogato dall'Università di Pisa. Il progetto formativo è stato svolto presso l’azienda Sesa spa di Empoli (FI) per un periodo che va da Maggio a Novembre 2019. Il progetto realizzato e descritto in questa tesi punta ad analizzare i dati storici relativi ai clienti di un’azienda leader in Italia nella distribuzione di Hardware, Software e servizi cloud. Lo scopo principale del progetto consiste nella segmentazione dei clienti attraverso una Cluster Analysis che consideri le loro abitudini di acquisto e i loro dati demografici. Tale segmentazione, unitamente ai dati principali di ogni cliente, viene poi mostrata mediante un’interfaccia web MVC interrogabile dal personale commerciale.
1.2 Contenuto della tesi
La tesi è strutturata in 5 capitoli:
1. Nel primo capitolo viene introdotto sommariamente l’argomento della tesi, evidenziando la necessità di anticipare le richieste dei clienti in un contesto competitivo;
2. Il secondo capitolo illustra l’organizzazione dell’azienda esaminata durante il progetto formativo, nonché il sistema informativo gestionale e di Business Intelligence già esistenti; inoltre esso contiene una breve introduzione teorica al Data Warehousing e all’estrazione di informazioni mediante il Data Mining;
3. Il terzo capitolo descrive come si è svolto il progetto formativo. È organizzato in più sezioni, una per ogni fase di esecuzione del progetto:
a. La creazione del nuovo Data Warehouse b. Il processo ETL di caricamento dei dati c. La creazione del cubo OLAP
d. Il processo di clustering mediante l’utilizzo del Data Mining e. La visualizzazione dei risultati ottenuti mediante una
web-dashboard in MVC
4. Il quarto capitolo contiene alcune considerazioni sul progetto svolto e su eventuali sviluppi futuri;
5. Il quinto capitolo contiene i riferimenti bibliografici utilizzati per la scrittura della tesi.
Capitolo 2 – Caso di Studio
In questa sezione vengono introdotti i tool e le tecnologie usati per lo sviluppo del progetto formativo, nonché l’azienda e i sistemi informativi pre-esistenti.
2.1 L’azienda: Sesa spa
Il Gruppo Sesa ha iniziato la propria attività negli anni settanta nel settore dei servizi di information technology a favore delle imprese dei distretti industriali della Toscana. A partire dagli anni ottanta, allo scopo di assecondare l’evoluzione tecnologica del settore, il Gruppo ha esteso la propria attività alla commercializzazione di personal computer IBM, all’assistenza software ed alla manutenzione hardware. Nel 1994, sulla base delle competenze sviluppate e del successo raggiunto, il Gruppo ha espanso la propria attività ad una nuova area di business relativa alle soluzioni e servizi a valore aggiunto (Value Added Distribution o VAD) gestita da una società dedicata. Essa, in breve tempo, è divenuta uno dei principali player italiani di soluzioni IT a valore aggiunto, con particolare riferimento ai prodotti IBM (hardware e software), cui si sono affiancati in modo progressivo soluzioni di ulteriori operatori internazionali quali Cisco, Microsoft, Lenovo, HP, Oracle, Emc, Dell. Per lo sviluppo del presente progetto formativo è stata considerata questa società, leader in Italia nella distribuzione di HW, SW e servizi cloud.
2.2 Sistema Informativo pre-esistente
L’azienda considerata nel progetto di tesi ha un’esperienza pluriennale nella vendita alle imprese e pertanto ha numerosi dati storici a disposizione. Il sistema informativo gestionale utilizzato è una piattaforma i-Series, più comunemente conosciuta come AS400. Nel tempo, con l’evoluzione dei sistemi informativi, sono stati introdotti strumenti più innovativi per gestire i flussi aziendali. Anche se la gestione dei dati e dei programmi rimane per buona parte sulla piattaforma originale, sono state realizzate alcune
procedure ed interfacce mediante web application che si appoggiano a database SQL Server.
2.3 Sistema di Business Intelligence pre-esistente
Dal 2009 l’azienda si avvale di uno strumento di Business Intelligence aziendale: “Cognos”, piattaforma di BI ideata da IBM che permette di realizzare query, reporting, analisi, dashboard e scoreboard. Questa soluzione supporta i diversi approcci e attività degli utenti che desiderano comprendere le prestazioni di business e prendere decisioni importanti con strumenti per interagire, ricercare e assemblare i diversi punti di vista dell’attività aziendale.
Cognos si basa attualmente su un database relazionale SQL Server composto da numerose tabelle, viste e indici. Il caricamento dei dati in tale database è periodico ed avviene in due fasi:
1. Ricalcolo dei dati su piattaforma i-Series: la prima fase del caricamento prevede la scrittura di alcuni file mediante una procedura in linguaggio RPG1. Essa va ad analizzare sia i file di
anagrafica che quelli dei movimenti, effettua una pulizia dei dati e li inserisce in alcuni file sequenziali;
2. Processo ETL e caricamento su SQL Server: nella seconda fase del caricamento, viene eseguita una procedura implementata con gli strumenti di SQL Server Integration Services. Essa va a leggere i file scritti nella fase precedente su piattaforma i-Series, rielabora i dati in essi contenuti e li inserisce nelle tabelle del database SQL Server.
Figura 1 Processo di caricamento ETL in Cognos
Una volta terminato il caricamento dei dati sul database, Cognos aggiorna in automatico il proprio framework: è all’interno di esso che avviene il binding tra dati del database e dati che Cognos rende disponibili per l’interrogazione. Questi ultimi vengono organizzati in package che potranno essere richiamati dagli utenti per la costruzione di report, dashboard e analisi di vario tipo. Cognos offre due ambienti diversificati per la progettazione di report:
Cognos Workspace Advanced: strumento utilizzato da tutti gli utenti per costruire report semplici, costituiti da una sola pagina;
Figura 2 Cognos Workspace Advanced
Cognos Report Studio: strumento utilizzato per la creazione di report più avanzati, costituiti da più pagine e organizzati in layout particolari.
Figura 3 Cognos Report Studio
I dati attualmente disponibili su Cognos sono relativi agli articoli con giacenza o movimentati, tutti i clienti e i fornitori, e tutti i tipi di movimento:
ordine a fornitore, carico di magazzino, preventivo a cliente, ordine a cliente, fattura a cliente. I dati sono inoltre esplorabili attraverso molte dimensioni, come la provenienza (e-commerce o altro) e il deposito (se Cash & Carry o altro tipo di magazzino).
2.4 Data Warehouse
I dati contenuti all’interno dello strumento di Business Intelligence aziendale descritto costituiscono un Data Warehouse. Per Data Warehouse si intende un database di supporto alle decisioni con dati storici e non volatili, costruito dalle operazioni di business, strutturato e messo a punto per facilitare l'analisi delle prestazioni dei principali processi aziendali e per migliorarli2. È quindi
una collezione di dati orientata al soggetto e integrata, con l’obiettivo di offrire supporto alle decisioni aziendali. Le sue principali caratteristiche sono quindi:
Subject-Oriented: all’interno del Data Warehouse i dati vengono memorizzati per soggetto di studio, che può variare da un’azienda ad un’altra;
Integrato: il Data Warehouse integra in modo coerenti dati provenienti da diverse sorgenti;
Evolution-Story: i dati all’interno del Data Warehouse sono dati storici, che descrivono l’evoluzione dei processi di business aziendali nel tempo;
Statico: i dati non cambiano con l’interazione dell’utente, ma vengono semplicemente letti. L’aggiunta di nuovi dati viene tipicamente effettuata ad intervalli prefissati;
Decision Support: la funzione primaria di un Data Warehouse è il supporto alle decisioni. I dati in esso contenuti vengono condensati in report e dashboard informative chiare e utili ai manager.
2 Definizione di William Immon
Gli elementi che costituiscono un Data Warehouse sono i seguenti:
Fatti: costituiscono l’osservazione del processo di business analizzato; Misure: attributi numerici dei fatti, ne descrivono quantitativamente
un aspetto;
Dimensioni: gruppi di attributi che descrivono il contesto del processo di business preso in analisi. Tra gli attributi di una dimensione possiamo individuare delle relazioni dette Gerarchie.
La combinazione di questi elementi determina la composizione di un Data Warehouse. In particolare, aggregando le misure per le diverse dimensioni disponibili possiamo ottenere delle Metriche: le più importanti per il processo di business analizzato prendono il nome di KPI3.
Un Data Warehouse viene tipicamente memorizzato mediante strutture multidimensionali adatte alla gestione di grandi quantità di dati: i Cubi
OLAP4. Essi consistono in una struttura di memorizzazione efficiente che
permette un’analisi interattiva dei dati da più punti di vista in modo semplice.
2.5 Dai dati alla conoscenza
Con KDD o più precisamente Knowledge Discovery in Databases, intendiamo il processo di ricerca di nuova conoscenza a partire da dati esistenti. Tale processo ha quindi un duplice scopo:
Modellare il mondo reale;
Identificare nuovi modelli, precisi e utili per il supporto alle decisioni. Il processo KDD si compone di varie fasi:
Data Consolidation: a partire da Data Source già esistenti andiamo a creare dei Dati Consolidati identificando i dati target che ci occorrono;
3 Key Performance Indicators 4 On-Line Analytical Processing
Selection and Preprocessing: attraverso una selezione e un preprocessing dei dati consolidati, otteniamo un Data Warehouse pronto all’uso. In questa fase abbiamo quindi una pulizia dei dati e una riduzione degli stessi, ricercando caratteristiche utili, variabili dimensionali e rappresentazioni invarianti;
Data Mining: è la fase più lunga del processo KDD. Automatizza la scoperta di schemi e sviluppa modelli preditivi chiari. Raccoglie più discipline: tecnologia dei database, statistica, intelligenza artificiale, e altre;
Interpretation & Evaluation: analisi dei risultati attraverso la loro visualizzazione e interpretazione;
Figura 4 KDD Process
Il sistema di Business Intelligence attualmente utilizzato non prevede la costruzione di alcun modello: i dati vengono visualizzati mediante dashboard e report, senza effettuare alcun tipo di analisi particolare. Il progetto formativo ha appunto lo scopo di costruire modelli di Data Mining che possano produrre conoscenza e informazioni nuove ed utili al management aziendale.
2.6 Modelli di Data Mining
Il Data Mining consiste nell’esplorazione e nell’analisi attraverso mezzi automatici e semiautomatici di grandi quantità di dati, allo scopo di scoprire modelli e relazioni che possono essere impiegati in un contesto decisionale
e di business. Nel tempo, sono stati creati vari approcci al Data Mining: nel 1996 l’Unione Europea ha promosso il progetto CRISP5 che prevedeva di
unificare l’approccio identificandone varie fasi:
Figura 5 Fasi del processo di Data Mining secondo CRISP
Business Understanding: fase preliminare in cui si cerca di comprendere il problema, il contesto in cui è inserito e si idealizzano possibili soluzioni;
Data Understanding: in questa fase si analizzano i dati disponibili, si cerca di capire quali sono quelli rilevanti, e si controlla la loro qualità; Data Preparation: è la fase preparatoria all’analisi, in cui si
trasformano i dati utilizzando tecniche specifiche, e si effettua una pulizia degli stessi sulla base delle esigenze previste dalla fase di modellazione;
Modelling: scelta e applicazione di tecniche di Data Mining ai dati, ricavando modelli da analizzare;
Evaluation: analisi dei risultati e del raggiungimento degli obiettivi prefissati;
Deployment: rilascio ed utilizzo dei modelli creati.
5 CRoss-Industry Standard Process
Il Data Mining potrebbe migliorare molto l’attività di commercializzazione dei prodotti: pensiamo ad una semplice analisi sugli articoli, trovando quelli acquistati più frequentemente insieme si potrebbe creare un suggeritore sul portale e-commerce. Oppure classificando i clienti in cluster sulla base dei loro acquisti e dei loro dati demografici, potremo proporre loro certi articoli piuttosto che altri.
3 – Il progetto
3.1 Creazione del Data Warehouse
Il Data Warehouse pre-esistente per il sistema di Business Intelligence conteneva sia i dati di fatturato che di ordinato a clienti e fornitori, nonché i preventivi a clienti. Inoltre presentava ridondanze e relazioni multiple gestite in vari modi, a seconda delle esigenze. Durante l’analisi iniziale del progetto, è stato deciso di creare un nuovo Data Warehouse per:
1. Modellare in modo più veritiero e congruo la realtà aziendale;
2. Preparare un Data Warehouse ben strutturato ai fini della costruzione di un cubo nelle fasi successive del progetto;
3. Ridurre i dati considerati, poiché troppi allo scopo del progetto di tesi. Illustriamo le misure, i fatti e le dimensioni individuate durante l’analisi e mostriamo come sono state strutturate sia nel Dimensional Fact Model6 che
nel modello logico relazionale.
3.1.1 Fact Table
I fatti considerati per il nuovo Data Warehouse sono di tipo transazionale7, e
riguardano i dati di fatturato dell’azienda nell’anno 2018. Per ogni vendita effettuata, sono state individuate tre misure:
Quantità Fatturata: numero di articoli venduti;
Valore Fatturato: importo ricavato dalla vendita degli articoli;
Valore D’acquisto: importo speso per l’acquisto degli articoli venduti. Nel Data Warehouse pre-esistente tali informazioni erano memorizzate nella tabella delle vendite insieme ai dati sui documenti di vendita; nel nuovo Data Warehouse è stata creata una fact table che contenesse solo le misure considerate.
6 Modello concettuale per la rappresentazione di Data Warehouse
Figura 6 Fact table delle vendite
I fatti hanno granularità a livello di riga di ogni documento. Procediamo adesso ad analizzare le dimensioni considerate per la costruzione del Data Warehouse.
3.1.2 Gli Articoli
Nel Data Warehouse pre-esistente, gli articoli venduti erano rappresentati da una sola tabella che conteneva sia i dati di ogni articolo che la relativa classificazione. Ogni articolo ha infatti un codice breve (assegnato dall’azienda ad uso interno), un codice lungo o codice fornitore (assegnato dal fornitore), una descrizione, un flag per indicare se esso è fuori produzione o meno, un flag Stampa Web per indicare se esso è pubblicato sull’e-commerce sul sito Internet. Oltre a questi attributi, ogni articolo ha un produttore (codice e descrizione) ed è classificato secondo due modalità:
Business Unit, Settore, Reparto, Famiglia, Sottofamiglia: classificazione utilizzata internamente per identificare gli articoli e gestirli;
Prodotto, Categoria, Sottocategoria: classificazione utilizzata sul sito e-commerce dell’azienda.
Durante l’analisi, è stata creata la nuova dimensione Articolo e sono stati definiti gli attributi e le gerarchie intercorrenti tra loro. In particolare è stata individuata la gerarchia tra Business Unit, Settore, Reparto, Famiglia e sottofamiglia; infatti una classificazione Reparto, Famiglia, Sottofamiglia appartiene ad un solo Settore, ed ogni Settore può appartenere ad una sola Business Unit. Questa gerarchia è stata arricchita dall’introduzione dell’attributo Super Business Unit: si tratta logicamente di un macro-raggruppamento per le Business Unit. Questo campo si trovava su una tabella a sé nel Data Warehouse pre-esistente, ma è stato scelto di inserirlo
nella dimensione Articolo in quanto parte della gerarchia appena descritta. Ricordiamo che ogni membro della gerarchia appena citata è rappresentato da un codice e da una descrizione, ma nel modello ne riportiamo solo il nome per comodità di visualizzazione. Un’altra gerarchia individuata è quella tra Prodotto, Categoria e Sottocategoria, che rappresentano (come già descritto) un’altra modalità di classificazione degli articoli.
Figura 7 Tabella degli articoli nel Data Warehouse pre-esistente
Lo schema multidimensionale sopra descritto è stato successivamente tradotto in uno schema logico applicato concretamente nella costruzione del Data Warehouse. La tabella degli articoli creata contiene quindi i codici articolo, la descrizione e i due flag; la chiave primaria della tabella è costituita da un nuovo attributo ID Articolo. La tabella degli articoli è collegata per mezzo di una chiave esterna alla tabella dei produttori, che contiene per ognuno di essi un codice e una descrizione. Per modellare le classificazioni degli articoli, sono state create due tabelle, ognuna con un campo ID univoco come chiave primaria. Nella tabella degli articoli abbiamo quindi due chiavi esterne, ognuna di esse riguardante una classificazione. Nella tabella dei reparti-famiglia-sottofamiglia abbiamo le chiavi esterne verso le rispettive tabelle e verso quella dei settori. La tabella dei settori è collegata a quella delle Business Unit, che a sua volta è collegata a quella delle Super Business Unit.
3.1.3 I Depositi
Un’altra delle dimensioni considerate nell’analisi è quella dei depositi. Essi rappresentano:
i magazzini fisici da cui la merce viene spedita ai clienti;
i negozi fisici (Cash & Carry) in cui la merce viene direttamente venduta.
Nel Data Warehouse pre-esistente i depositi erano rappresentati da una sola tabella che conteneva i dati necessari ad identificarli, quali il codice, la descrizione e un flag per distinguere i negozi fisici dai magazzini. La tabella conteneva poi alcuni dati aggregati come il valore fatturato per ogni trimestre ad esempio: tali dati non sono stati inclusi nella dimensione delineata poiché ricavabili tramite interrogazioni sul nuovo Data Warehouse.
Figura 10 Rappresentazione dei depositi nel modello multidimensionale
A partire dal modello multidimensionale, è stata ricavata una tabella dei depositi con un ID avente funzione di chiave primaria, il codice deposito, la descrizione e il flag di distinzione.
3.1.4 I Clienti
I clienti dell’azienda considerata per il progetto formativo erano memorizzati in una tabella costruita appositamente nel Data Warehouse pre-esistente. Essa includeva non solo informazioni di natura anagrafica (come la ragione sociale e la sede legale), ma anche altre aggiunte dall’azienda come i customer care e i commerciali associati al cliente, i fidi accordati ed eventuali blocchi finanziari applicati. Mostriamo la struttura della tabella pre-esistente, includendo i soli attributi considerati ai fini della tesi.
Figura 12 Tabella dei clienti nel Data Warehouse pre-esistente
Durante l’analisi svolta è stato scelto di creare una nuova dimensione per i clienti con tutti gli attributi necessari alla loro rappresentazione.
Osserviamo la presenza di una gerarchia tra gli attributi che determinano la località geografica del cliente.
La dimensione dei clienti del modello multidimensionale è stata tradotta in tre tabelle nel nuovo Data Warehouse, collegate tra loro:
Tabella dei clienti: contenente il codice cliente, la ragione sociale, la data creazione dell’anagrafica, il flag di apertura da C&C, il negozio C&C di default. È stato aggiunto il campo ID Cliente come chiave primaria della tabella; sono state inoltre aggiunte due chiavi esterne alle tabelle delle Località e dei Commerciali;
Tabella dei commerciali: contiene un ID che fa da chiave primaria, un codice e una descrizione del commerciale;
Tabella delle località: contiene un ID che svolge il ruolo di chiave primaria, e i campi relativi alla posizione geografica della sede legale del cliente, quindi l’indirizzo, il cap, la città, la provincia, la regione e infine la nazione. È stato scelto di creare una tabella delle località per evidenziare l’importanza della gerarchia individuata durante la costruzione del modello multidimensionale.
La tabella dei clienti è ovviamente collegata alla tabella dei fatti mediante una chiave esterna.
Figura 14 Rappresentazione dei clienti nel modello logico del nuovo Data Warehouse
3.1.5 Le date
Il Data Warehouse pre-esistente conteneva una tabella Calendario, creata per identificare temporalmente gli eventi: in questo caso consideriamo
come evento la vendita ad un cliente, quindi siamo interessati a collocare nel tempo i documenti e il sell-flow8. La tabella conteneva i campi: data,
anno, quarter, mese, descrizione del mese, week, giorno. Oltre a questi attributi ne avevamo anche altri, come Anno-mese e Anno-mese-giorno, ottenuti tramite la concatenazione dei rispettivi elementi.
Figura 15 Tabella Calendario nel Data Warehouse pre-esistente
Per modellare l’aspetto temporale nel nuovo Data Warehouse è stata creata appositamente una nuova dimensione. Tra gli attributi considerati è stata individuata una gerarchia tra la data, la settimana, il mese, il trimestre e l’anno. Inoltre sono stati riportati la descrizione del mese, e i campi costruiti mediante la concatenazione.
Figura 16 Rappresentazione del calendario nel modello multidimensionale
8 Flusso di vendita
Come negli altri casi, a partire dal modello multidimensionale è stata ricavata una nuova tabella. Essa ha la stessa struttura di quella del Data Warehouse pre-esistente; è stata aggiunto un attributo ID Calendario avente funzione di chiave primaria.
Figura 17 Rappresentazione del Calendario nel modello logico del nuovo Data Warehouse
3.1.6 I documenti
I documenti considerati ai fini del progetto formativo sono le bolle di vendita. Nel Data Warehouse pre-esistente tali documenti erano memorizzati nella tabella delle vendite che quindi conteneva sia le misure che i dati relativi ai documenti stessi. La granularità della tabella era a livello di riga, quindi la chiave era formata dai seguenti campi:
Anno del documento; Tipo del documento; Numero del documento; Riga del documento.
Oltre a questi attributi descritti ne erano presenti molti altri nella tabella delle vendite. Per comodità descriviamo solo quelli considerati ai fini del progetto di tesi quali: flag ordine web per indicare se l’ordine legato alla bolla considerata proviene dal sito web dell’azienda o meno, flag C&C per indicare se la vendita è stata effettuata in un negozio C&C.
Figura 18 Tabella delle vendite nel Data Warehouse pre-esistente
Durante l’analisi svolta per il progetto formativo, è stata creata la nuova dimensione Documento contenente i dati precedentemente descritti.
Figura 19 Rappresentazione dei documenti nel modello multidimensionale
Questa rappresentazione nel modello multidimensionale si traduce in una tabella dei documenti nel modello logico con gli attributi descritti e un ID con funzione di chiave primaria.
3.1.7 Il nuovo Data Warehouse
Il Dimensional Fact Model creato per il nuovo Data Warehouse prevede quindi una fact table delle vendite e le dimensioni ad essa collegate, quali i clienti, gli articoli, i depositi, i documenti e le date.
Figura 21 Modello multidimensionale
Da questo modello multidimensionale è stato ricavato uno schema logico relazionale composto da più tabelle. All’interno della tabella dei fatti sono state inserite le chiavi esterne necessarie per le relazioni con le tabelle dimensionali.
Il Data Warehouse è stato materialmente realizzato su SQL Server, un RDBMS9
prodotto da Microsoft, che permette di gestire in modo efficiente e completo database di grandi dimensioni. Si avvale di elevata scalabilità e integra molte funzionalità al suo interno. Il Magic Quadrant di Gartner10, che
fornisce una rapida panoramica nel mercato della BI, posiziona Microsoft come leader del settore “Analytics and Business Intelligence Platforms”.
Figura 23 Magic Quadrant for Analytics and Business Intelligence Platform
9 Relational DataBase Management System
10 Società di consulenza e ricerca nota per le sue analisi di mercato periodiche che forniscono una
3.2 Processo ETL di caricamento dati
Una volta creato il Data Warehouse su SQL Server, è necessario inserirvi i dati. Come già spiegato, i dati considerati per il progetto formativo sono relativi al fatturato dell’azienda nell’anno 2018; illustriamo in questa sezione come essi vengono inseriti nel nuovo Data Warehouse mediante query di lettura sul Data Warehouse pre-esistente utilizzato per Cognos, lo strumento di Business Intelligence aziendale.
3.2.1 SQL Server Integration Services
Lo strumento utilizzato per il caricamento dei dati nel nuovo Data Warehouse è SSIS o SQL Server Integration Services. SSIS è una piattaforma per la creazione di soluzioni di integrazione e trasformazione di dati a livello aziendale. È indicato per operazioni come il caricamento di Data Warehouse, pulizia di dati, gestione di oggetti e dati di SQL Server. Include sia strumenti grafici che linguaggi specifici, utili per creare processi di trasformazione dati, come ad esempio i processi ETL.
SSIS organizza i progetti in Packages: un pacchetto o package è una raccolta organizzata di connessioni, elementi di flusso di controllo, elementi di flusso di dati, gestori eventi, variabili, parametri e configurazioni che possono essere assemblati usando gli strumenti di progettazione grafica disponibili in Integration Services, oppure compilati a livello di codice. Ogni package è costituito quindi da un Flusso di controllo e, facoltativamente, da uno o più Flussi di dati.
3.2.2 Sviluppo del processo ETL
Il processo ETL creato per il caricamento dei dati è stato ispirato al processo già esistente che si occupa di aggiornare il database di Cognos. Tale processo è stato analizzato per capire come funzionassero le connessioni, la gestione degli errori e la manipolazione dei dati; una volta appreso il suo funzionamento, è stato creato un nuovo processo ETL per il Data Warehouse Start.
Il processo creato è stato organizzato in più packages: essi vengono richiamati ordinatamente da un package principale che prende il nome di _ETL_Start.
Figura 24 Packages creati per il processo di caricamento dati
Il primo task del Package _ETL_Start consiste nell’invio di una mail di inizio caricamento: esso è stato implementando mediante l’Attività Invia messaggi che consente di inviare messaggi di posta elettronica tramite il protocollo SMTP11.
Il secondo task del package è implementato mediante l’Attività Esegui SQL e consiste nel reset delle chiavi primarie delle tabelle. Infatti, dopo un certo numero di caricamenti eseguiti, il processo dà errore se non si effettua il reset delle chiavi primarie, riportandole a 0. È stato quindi scelto di introdurre questo passaggio per non dover resettare manualmente le chiavi primarie una volta arrivate al limite consentito da SQL Server. L’istruzione utilizzata a questo scopo è la seguente:
DBCC CHECKIDENT(_tableName_, RESEED, 0); Il processo prosegue con delle Attività Esegui
Pacchetto che richiamano appunto l’esecuzione di
11 Simple Mail Transfer Protocol
altri Packages, necessari al caricamento dati delle tabelle dimensionali e di quella dei fatti. L’ultima attività che viene svolta nel processo è l’invio di una mail per notificare al team di sviluppo l’avvenuta terminazione del caricamento.
3.2.3 Caricamento degli Articoli
Il primo package di caricamento richiamato da quello principale riguarda gli Articoli e tutte le tabelle ad essi relativi come quella dei produttori e quelle delle classificazioni.
Figura 26 Package degli articoli
Il flusso di controllo di questo package inizia con un’Attività Esegui SQL che cancella il contenuto delle tabelle coinvolte mediante semplici istruzioni di DELETE. Il caricamento prosegue poi con l’esecuzione di Attività Flusso Dati che leggono dati dal Data Warehouse pre-esistente creato per Cognos e li scrivono sul Data Warehouse nuovo, appositamente ideato per il progetto formativo. Le letture avvengono mediante l’attività Origine OLE DB che permette di estrarre dati da un database utilizzando query SQL o semplicemente scegliendo le tabelle interessate dal processo di estrazione. Le scritture avvengono invece mediante l’attività Destinazione OLE DB che permette di caricare dati in un database relazionale conforme ad OLE DB. Queste due attività utilizzano delle connessioni a database che vengono gestite dai Connection Manager12 di SSIS. Mentre per le Super Business Unit il
caricamento prevede una semplice lettura-scrittura, per le Business Unit avviene anche un passaggio intermedio che riguarda la chiave esterna
verso la tabella delle Super Business Unit. Essa viene inserita nei dati mediante l’attività Ricerca che permette di creare un join con alcune colonne aggiuntive al flusso i dati, cercando i valori in una tabella. Nel nostro caso, per ogni record letto dalla tabella delle Business Unit nel Data Warehouse di Cognos, andiamo a ricercare l’ID della Super Business Unit corrispondente nella tabella delle Super BU: questo è il motivo per cui quest’ultima viene caricata per prima.
Figura 27 Flusso Dati per il caricamento delle Business Unit
Il flusso prosegue con il caricamento dei Settori per i quali viene eseguita l’attività Ricerca per andare a inserire la chiave esterna verso la tabella delle Business Unit. I passaggi successivi per il caricamento di Sottofamiglie, Famiglie e Reparti, prevedono semplici letture dal vecchio Data Warehouse e scritture nel nuovo. Un Flusso Dati importante è quello seguente, dove andiamo a riempire la tabella per la classificazione mediante gli attributi Reparto, Famiglia, Sottofamiglia. Per ogni tripla letta dalla tabella degli articoli nel Data Warehouse pre-esistente, andiamo a ricercare l’ID del reparto, della famiglia, della sottofamiglia e del settore corrispondenti nelle nuove tabelle riempite in precedenza. I record con cui non troviamo corrispondenza, vengono inseriti in un file CSV in modo da poter essere analizzati una volta terminato il caricamento.
Gli stessi passaggi vengono ripetuti per l’altra classificazione che prevede Prodotto, Categoria e Sottocategoria: le corrispondenti tabelle vengono riempite mediante semplici letture e scritture. In seguito viene caricata la seconda tabella di classificazione mediante la ricerca degli ID di Prodotto, Categoria e Sottocategoria che compongono le triple. La penultima attività prevede il caricamento della tabella dei produttori: essendo solo legati agli articoli, essi vengono semplicemente letti dal Data Warehouse pre-esistente ed inseriti nella nuova tabella del Data Warehouse Start.
L’ultima attività Flusso Dati riguarda il caricamento della tabella degli articoli. Essa viene riempita con i codici, le descrizioni e i flag letti dal Data Warehouse pre-esistente, mentre gli ID delle classificazioni e dei produttori vengono aggiunti mediante un’attività Ricerca.
3.2.4 Caricamento dei Depositi
Il package del caricamento dei depositi prevede due sole attività: la prima è un’Attività Esegui SQL mediante la quale la tabella dei depositi del nuovo Data Warehouse viene svuotata. La seconda attività è di tipo Flusso Dati e consiste in una semplice lettura e scrittura dalla tabella dei depositi nel Data Warehouse pre-esistente a quella nuova del Data Warehouse Start.
Figura 29 Package dei depositi
3.2.5 Caricamento dei Clienti
Il package del caricamento dei clienti prevede una prima Attività Esegui SQL per eliminare tutti i record nelle tabelle delle Località, dei Commerciali e dei Clienti. Esso prosegue poi con tre Attività Flusso Dati; la prima riguarda la tabella delle Località nella quale vengono inserite le località distinte
individuate nella tabella dei clienti del Data Warehouse pre-esistente. Anche in questo caso, le letture e le scritture vengono effettuate per mezzo di attività Origine OLE DB e Destinazione OLE DB. Il secondo Flusso Dati riguarda i Commerciali: anche per questa tabella viene effettuato un Distinct13 dei commerciali dalla tabella dei clienti del Data Warehouse
pre-esistente, che vengono riportati nel nuovo Data Warehouse. L’ultimo passaggio del Flusso di controllo consiste nel Flusso Dati che va ad agire direttamente sulla tabella dei clienti. Essi vengono letti dal Data Warehouse pre-esistente e mediante due attività Ricerca, vengono aggiunte ai dati le chiavi esterne alle nuove tabelle delle Località e dei Commerciali create. Infine i dati vengono caricati nella nuova tabella.
Figura 30 Attività Flusso Dati per il caricamento dei Clienti
3.2.6 Caricamento delle Date
Il caricamento delle date nella nuova tabella Calendario del Data Warehouse Start avviene mediante un package dedicato. Come gli altri, anche questo è composto da una prima Attività Esegui SQL che cancella il contenuto della tabella. Successivamente, mediante un’Attività di tipo Flusso Dati, vengono caricati nella tabella Calendario tutti i record riguardanti il periodo scelto per l’analisi, ovvero l’anno 2018. Il riempimento della tabella avviene mediante letture dal Data Warehouse di Cognos e scritture in quello nuovo creato appositamente per il progetto formativo.
13 Istruzione SQL contenente “Distinct”
Figura 31 Package di caricamento dati per la tabella Calendario
3.2.7 Caricamento dei Documenti
Il caricamento dei dati nella tabella dei Documenti consiste di un flusso di Controllo molto semplice, come per la tabella Calendario. La prima Attività svolta cancella i dati contenuti nella tabella; la seconda Attività, di tipo Flusso Dati, si occupa materialmente del caricamento dei record relativi a vendite effettuate nell’anno 2018. Per ottenere questi dati, è stata effettuata una query di lettura sulla tabella delle vendite del Data Warehouse pre-esistente, ricavando i documenti emessi dall’azienda.
Figura 32 Package per il caricamento dei dati relativi a documenti di vendita
3.2.8 Caricamento della tabella dei Fatti
Una volta caricati i dati nelle tabelle dimensionali, possiamo andare ad inserire record nella tabella dei fatti. La prima attività nel Flusso di Controllo del package delle vendite consiste nella cancellazione del contenuto della fact table. Il secondo task svolto è un Flusso Dati che si occupa di caricare i record relativi alle vendite del 2018 nella tabella del nuovo Data Warehouse. La fact table, come abbiamo visto nello schema logico, contiene chiavi esterne verso la tabella degli articoli, dei clienti, dei documenti, delle date e dei depositi. Per inserire questi dati non sono state utilizzate le attività Ricerca come negli altri casi, perché sarebbe stato troppo costoso da un punto di
vista computazionale. I dati completi da inserire nella tabella sono stati ricavati da una query SQL che unisce record del Data Warehouse pre-esistente e di quello creato per il progetto formativo.
Figura 33 Package per il caricamento dati nella Fact Table
Figura 34 Schema di rappresentazione delle provenienze di ogni attributo della Fact Table durante il caricamento dati
3.3 Creazione del cubo OLAP
Ai fini della visualizzazione delle informazioni e quindi dell’interrogazione efficiente dei dati, nonché dell’applicazione di algoritmi e modelli di Data Mining, a partire dal Data Warehouse creato è stato costruito un Cubo OLAP mediante l’utilizzo di un tool di SQL Server.
3.3.1 SQL Server Analysis Services
SQL Server Analysis Services è un motore sw che permette di fornire modelli di dati usati in applicativi per l’analisi aziendale e per il supporto alle decisioni. Si può interfacciare con applicazioni client come Excel, Power BI, Reporting Services e altri strumenti di visualizzazione dei dati. La particolarità di Analysis Services consiste nella possibilità di creare modelli di diversa tipologia:
Tabulari: costrutti di modellazione relazionale, trattando tabelle, colonne e attributi;
Multidimensionali: sfruttano costrutti di modellazione OLAP, trattando cubi, dimensioni e misure.
Analysis Services supporta vari linguaggi di query e scripting: MDX,
MultiDimensional eXpressions, è un linguaggio utilizzato nell’interrogazione di
strutture multidimensionali come i cubi OLAP. Ha una sintassi simile a SQL14,
ma permette di organizzare il dataset estratto come un cubo, utilizzando una distribuzione dei dati su righe e colonne. Un altro linguaggio supportato da Analysis Services è DMX (Data Mining Extensions): esso permette di interrogare i modelli di Data Mining, per capire ad esempio a quale cluster appartenga un record.
14 Structured Query Language
3.3.2 Preparazione dei dati
Prima di andare a creare materialmente il cubo OLAP è stato necessario preparare i dati su Analysis Services. Essi andavano infatti importati dentro il tool di SQL Server, creando un’Origine dati. In un modello multidimensionale di Analysis Services un oggetto Origine dati rappresenta una connessione al Data Source dal quale si elaborano o si importano dati. Per crearla, è stato eseguito il Wizard15 dedicato impostando una connessione al Data
Warehouse Start.
Figura 35 Wizard di creazione dell'origine dati
Una volta eseguita la creazione dell’Origine dati, essa è apparsa nel progetto come disponibile per l’elaborazione. Per aggiornare i dati in essa contenuti, occorre Distribuire ed Elaborare il progetto. Con la Distribuzione il progetto viene spostato su un server (nel nostro caso localhost), mentre l’Elaborazione è composta da una serie di passaggi durante i quali, tramite Analysis Services, vengono caricati i dati da un'origine dati relazionale in un modello multidimensionale. Una volta creata l’Origine dati è stato necessario generare una Vista origine dati corrispondente: essa è un'astrazione di un'origine dati relazionale che diventa la base dei cubi e
delle dimensioni creati in un progetto multidimensionale. Lo scopo di una Vista è fornire il controllo sulle strutture dati utilizzate nel progetto e funzionare indipendentemente dalle origini dati sottostanti (ad esempio, con la possibilità di rinominare o concatenare campi senza modificare direttamente l'origine dati). In Analysis Services è possibile creare più viste della stessa origine dati. La vista origine dati creata mediante lo strumento di creazione automatica dedicato, rispecchia il modello logico del Data Warehouse descritto nel primo capitolo.
Figura 36 Vista origine dati
Questa vista origine dati non è stata manipolata, non sono stati aggiunti attributi o campi calcolati poiché non ne è stata avvertita l’esigenza.
A partire dalla vista origine dati creata, sono state generate le dimensioni e infine il cubo.
3.3.3 Creazione delle dimensioni
Ai fini della creazione del cubo, è stato necessario prima creare le dimensioni che lo compongono. A tale scopo sono stati applicati gli strumenti di creazione delle dimensioni offerti da Analysis Services alle tabelle dimensionali della vista origine dati.
Figura 37 Tool di creazione guidata delle dimensioni su Analysis Services
La creazione guidata prevede più fasi:
Scelta della modalità di creazione: possiamo scegliere di utilizzare una vista origine dati già esistente, oppure crearne una nuova;
Impostazione dell’informazione d’origine: in questa fase vengono scelte la vista origine dati e la tabella da utilizzare, viene inoltre specificato l’attributo chiave della tabella;
Selezione delle tabelle correlate: questo stadio della creazione ci permette di scegliere se includere dati di tabelle eventualmente correlate a quella scelta;
Selezione degli attributi: fase di scelta degli attributi dimensionali da includere e da rendere esplorabili. È anche possibile scegliere la natura dell’attributo: se si tratta di una località geografica oppure di date, quindi attributi temporali, ad esempio;
Completamento della procedura: nell’ultima fase della creazione guidata vengono riepilogati gli attributi della dimensione e viene richiesto il nome della stessa.
Analizziamo ora la costruzione delle tabelle dimensionali, osservando i campi inclusi delle tabelle correlate e illustrando le gerarchie costruite.
Per la costruzione della dimensione Articolo doveva essere scelto come gestire le tabelle correlate dei produttori, della classificazione per Reparto-Famiglia-Sottofamiglia e di quella per Prodotto-Categoria-Sottocategoria. È stato scelto di includere tutte le tabelle correlate in modo da avere a disposizione nella dimensione tutti gli attributi necessari per le analisi. Sono state create poi due gerarchie che modellassero le classificazioni descritte in precedenza.
Figura 38 Dimensione Articolo
Lo stesso ragionamento è stato applicato alla dimensione Cliente, in cui sono state inclusi gli attributi delle tabelle correlate delle Località e dei Commerciali. È stata inoltre aggiunta una gerarchia per modellare le relazioni tra gli attributi della tabella correlata delle Località: tale gerarchia è la stessa ideata nel Dimensional Fact Model in fase di analisi.
Per le dimensioni riguardanti i Depositi, le Date e i Documenti, è stato più semplice creare le dimensioni, in quanto non c’è stata la necessità di gestire alcuna tabella correlata.
Per la dimensione Calendario sono state modellate le gerarchie previste dal Dimensional Fact Model.
Figura 40 Dimensione Deposito
Figura 41 Dimensione Calendario
Figura 42 Dimensione Documento
3.3.4 Creazione del cubo
Una volta costruite le dimensioni, è stata avviata la creazione del cubo mediante lo strumento dedicato all’interno del tool Analysis Services. È stata scelta come tabella dei fatti la fact table creata in precedenza: tra le misure incluse, oltre alla quantità, al valore fatturato e al valore d’acquisto, è stato aggiunto il conteggio delle righe della fact table. Quest’ultima misura è stata aggiunta in automatico da Analysis Services.
Figura 43 Fase di selezione delle misure da includere nel cubo
Dopo il completamento della creazione del cubo, è stato possibile esplorarne i dati all’interno di Analysis Services. Questo ha permesso di conoscerli meglio e di capire quali fossero gli attributi più importanti da considerare per le successive analisi.
Figura 44 Prima esplorazione dei dati all'interno del cubo
Per l’interrogazione del cubo, oltre allo strumento di esplorazione dati di Analysis Services, è stato usato SQL Server Management Studio, un ambiente integrato per la gestione di qualsiasi infrastruttura SQL che offre gli strumenti per configurare, monitorare e amministrare le istanze di SQL Server, i database e i modelli multidimensionali. È proprio attraverso Management Studio che è stato possibile eseguire query MDX sul nuovo cubo creato. Con
la query seguente, ad esempio, è stato possibile ricavare la numerica degli articoli venduti per mese.
3.4 Creazione delle strutture e dei modelli di Data Mining
In questo paragrafo illustriamo la divisione dei clienti in cluster in base alle loro abitudini d’acquisto e ai loro dati anagrafici. Per effettuare questo tipo di analisi è stato necessario creare modelli e strutture utilizzando gli algoritmi di Data Mining offerti da Microsoft Analysis Services. Descriviamo tali algoritmi illustrando successivamente la loro applicazione al caso analizzato.
3.4.1 Microsoft Clustering
L’algoritmo Microsoft Clustering è un algoritmo di segmentazione o clustering che esegue quindi un raggruppamento di record simili all’interno di un dataset. Tali raggruppamenti sono utili per l’esplorazione dei dati, l’identificazione delle relative anomalie e la creazione di stime, ma soprattutto per individuare relazioni che non sarebbe possibile derivare mediante osservazioni casuali. Come ogni algoritmo di clustering, ha un duplice obiettivo:
1. Minimizzare le distanze intra-cluster: oggetti dello stesso cluster sono molto simili tra loro;
2. Massimizzare le distanze inter-cluster: oggetti di cluster diversi sono molto distanti tra loro.
L'algoritmo Microsoft Clustering identifica innanzitutto le relazioni esistenti in un dataset e genera una prima serie di cluster, basandosi su tali relazioni. Una volta definiti i cluster, l’algoritmo calcola l’accuratezza con cui i record sono raggruppati e tenta di migliorare la classificazione eseguendo iterazioni di questo processo fino a quando non è più possibile migliorare i risultati ottenuti. A differenza di altri algoritmi disponibili nella suite di Analysis Services, Microsoft Clustering non necessita di designare una colonna stimabile per compilare un modello di clustering. L’algoritmo esegue infatti il training del modello rigorosamente in base alle relazioni esistenti tra i dati e ai cluster identificati.
L’algoritmo Microsoft Clustering, per impostazione predefinita, normalizza gli attributi utilizzando statistiche z-score e presupponendo una distribuzione normale, in modo da ridurre l’effetto di attributi che potrebbero avere grandezze eccessive e outlier.
L’algoritmo può essere personalizzato valorizzando più parametri, quali: CLUSTERING_METHOD: permette di scegliere la tecnica di clustering
da utilizzare;
CLUSTERING_COUNT: numero di cluster da creare. Se il parametro non viene impostato o viene settato con 0, l’algoritmo determinerà il numero ottimale di cluster da creare mediante un’euristica;
MIMINUM_SUPPORT: permette di specificare il numero minimo di record necessari per ottenere un cluster.
Le possibili tecniche di clustering disponibili, individuate dal valore del parametro CLUSTERING METHOD, sono 4:
1. EM Scalabile; 2. EM non scalabile; 3. K-means scalabile; 4. K-means non scalabile.
Le prime due tecniche di clustering sopra elencate indicano l’applicazione dell’algoritmo EM ovvero Expectation Maximization. Esso è un algoritmo di raffinamento iterativo di tipo soft clustering in cui non esistono confini ben definiti tra i cluster: EM assegna infatti ciascun oggetto ad un cluster secondo un peso che rappresenta la sua probabilità di appartenenza. Tale probabilità è espressa in forma logaritmica rispetto al record considerato e al cluster scelto. EM calcola dapprima un modello iniziale determinando i centri dei cluster che saranno creati. Successivamente, ad ogni iterazione, vengono eseguiti due step:
1. Expectation Step: ciascun record xi viene assegnato a un cluster Ck
2. Maximization Step: vengono utilizzate le stime di probabilità precedenti per raffinare i parametri del modello. Viene quindi massimizzata la probabilità della distribuzione rispetto ai dati.
Questa tecnica di clustering viene indicata come la predefinita nei modelli Microsoft Clustering poiché offre più vantaggi rispetto a K-means:
Funziona anche con memoria RAM limitata; Utilizza un cursore forward-only;
Offre prestazioni elevate rispetto ad altri approcci.
L'implementazione di Microsoft prevede due opzioni: EM scalabile e EM non scalabile. Con EM scalabile vengono utilizzati i primi 50.000 record per inizializzare il modello: se l’inizializzazione ha successo il modello utilizza solo quei dati, altrimenti vengono letti altri 50.000 record e si ritenta di ottenere un fit. Nell'algoritmo EM non scalabile, invece, viene letto l'intero dataset, indipendentemente dalla sua dimensione. Nel caso del progetto formativo, è stato utilizzato EM scalabile poiché più performante rispetto alla versione non scalabile, in quanto utilizza un buffer locale ed ha quindi un uso della cache della CPU molto più efficiente. Questa scelta non ha comunque avuto effetti sul dataset considerato che si compone di circa 14.000 record (< 50.000).
L’altra modalità di clustering offerta da Analysis Services è K-means, una tecnica di hard clustering che prevede l’individuazione di cluster ben definiti. Esso utilizza un centroide in ogni cluster, ovvero un punto dato scelto e perfezionato in modo iterativo fino a rappresentare la media reale di tutti i record nel cluster. La lettera “K” indica il numero di cluster che saranno creati. Questa tecnica assegna ogni record ad esattamente un unico cluster e l’appartenenza di un record a un cluster è espressa come distanza dal centroide di tale raggruppamento. Anche K-Means prevede due metodi di campionamento del dataset: con K-means non scalabile viene caricato l’intero set di dati, indipendentemente dalla sua dimensione. Nella versione scalabile invece vengono utilizzati i primi 50.000 record, e ne
vengono letti altri solo se necessario per ottenere un modello appropriato. Anche in questo caso è stata utilizzata la versione scalabile dell’algoritmo, benché fosse indifferente avendo un dataset composto da meno di 50.000 record.
3.4.2 Applicazione di Microsoft Clustering
Ai fini dell’applicazione concreta dell’algoritmo ai dati considerati per il progetto formativo sono state effettuate delle scelte: era importante capire come impostare l’analisi, quali tipi di relazioni e informazioni si volevano estrapolare e soprattutto a quale livello di granularità. Effettuando delle prove a vari livelli, considerando le prestazioni del tool (che ricordiamo essere su un pc in locale e non su un server) e tenendo conto della struttura con cui i dati dovevano essere passati all’algoritmo, è stato deciso di non utilizzare il cubo per la costruzione dei modelli di Data Mining. Il cubo è stato utilizzato successivamente nella fase di visualizzazione dati.
È stata quindi costruita una vista nel Data Warehouse, nella quale sono stati inseriti i seguenti dati relativi ai clienti:
Codice Cliente;
Flag apertura da Cash & Carry;
Codice del negozio Cash & Carry default; Data creazione del cliente nel sistema; Regione della sede legale del cliente; Nazione della sede legale del cliente; Valore fatturato per ogni Business Unit; Totale del valore fatturato;
Totale del valore fatturato nei negozi Cash & Carry. La vista è stata creata mediante la query seguente:
CREATE VIEW [dbo].[fatt_bu_cli]
AS
(
SELECT [cod_cliente] ,[aperto_da_cash] ,[cash_default]
,[data_creazione] ,[nazione]
,[regione]
,case when [BU1] is null then 0 else [BU1] end as BU1 ,case when [BU2] is null then 0 else [BU2] end as BU2 ,case when [BU3] is null then 0 else [BU3] end as [BU3] ,case when [BU4] is null then 0 else [BU4] end as [BU4] ,case when [BU5] is null then 0 else [BU5] end as [BU5] ,case when [BU6] is null then 0 else [BU6] end as [BU6] ,case when [BU7] is null then 0 else [BU7] end as [BU7] ,case when [BU8] is null then 0 else [BU8] end as [BU8] ,case when [BU9] is null then 0 else [BU9] end as [BU9] ,case when [BU10] is null then 0 else [BU10] end as [BU10] ,case when [BU11] is null then 0 else [BU11] end as [BU11] ,case when [BU12] is null then 0 else [BU12] end as [BU12] ,case when [BU13] is null then 0 else [BU13] end as [BU13] ,case when [BU14] is null then 0 else [BU14] end as [BU14] ,case when [BU15] is null then 0 else [BU15] end as [BU15] ,case when [BU16] is null then 0 else [BU16] end as [BU16] ,case when [BU17] is null then 0 else [BU17] end as [BU17] ,case when [BU18] is null then 0 else [BU18] end as [BU18] ,case when [BU19] is null then 0 else [BU19] end as [BU19] ,case when [BU20] is null then 0 else [BU20] end as [BU20] ,case when [BU21] is null then 0 else [BU21] end as [BU21] ,case when [BU22] is null then 0 else [BU22] end as [BU22]
, tot_fatt, case when tot_fatt_cec is null then 0 else tot_fatt_cec end as tot_fatt_cec FROM (SELECT cli.cod_cliente, cli.aperto_da_cash, cli.cash_default, cli.data_creazione, l.nazione, l.regione, b.dex_bu, v.valore as valore, ft.tot_fatt as tot_fatt
,fatcec.tot_fatt_cec as tot_fatt_cec FROM d_clienti cli
JOIN F_Vendite v on v.ID_cliente = cli.ID_cliente
join D_Calendario cal on v.ID_calendario = cal.ID_data and cal.anno = 2018
join D_Luoghi l on l.ID_Luogo = cli.ID_luogo
join D_Articoli a on v.ID_articolo = a.ID_articolo
join D_RepFamSottofam rfs on a.ID_repfamsottofam = rfs.ID_repfamsottofam
join D_Settori s on s.ID_settore = rfs.ID_settore
join D_Bu b on b.ID_bu = s.ID_bu
left join (
select c.cod_cliente, sum(valore) as tot_fatt_cec
from D_Clienti c join F_Vendite v on v.ID_cliente = c.ID_cliente
join d_documenti doc on v.id_documento = doc.id_documento
where doc.flag_cec = 'S'
group by c.cod_cliente
) fatcec on cli.cod_cliente = fatcec.cod_cliente
left join (
select c.cod_cliente, sum(valore) as tot_fatt
from D_Clienti c join F_Vendite v on v.ID_cliente = c.ID_cliente
group by c.cod_cliente
) ft on cli.cod_cliente = ft.cod_cliente) x PIVOT (sum(valore) FOR dex_bu IN
[BU11],[BU12],[BU13],[BU14],[BU15],[BU16],[BU17],[BU18],[BU19],[BU20],[BU21],[BU22 ])
) p
)
Per poter applicare l’algoritmo Microsoft Clustering ai dati è stata creata una Struttura di Data Mining in Analysis Services, a cui poi sono stati aggiunti i modelli. Una Struttura di Data Mining definisce i dati in base ai quali vengono compilati i modelli; un Modello di Data Mining è un set di dati, statistiche e modelli che possono essere applicati ai dati per generare stime ed eseguire inferenze sulle relazioni. Un modello di Data Mining rimane vuoto finché i dati forniti dalla struttura non vengono elaborati e analizzati. Dopo essere stato elaborato, un modello di Data Mining contiene metadati, risultati e associazioni alla struttura di Data Mining. La struttura di Data Mining è stata creata mediante lo strumento di creazione guidata dedicato, e vi sono stati inclusi tutti i campi della vista sopra descritta.
Figura 46 Struttura di Data Mining creata per il clustering dei clienti
Nella struttura di Data Mining sono stati aggiunti due Modelli di Data Mining: il primo utilizzando K-Means scalabile, il secondo utilizzando EM scalabile. In
entrambi i casi il parametro CLUSTER_COUNT è stato impostato su 0 in modo che il modello individuasse da solo il numero ottimale di cluster.
Figura 47 Modelli di Data Mining costruiti all'interno della Struttura di Data Mining
Per la costruzione dei modelli, i dati sono stati divisi nella Struttura di Data Mining in due set:
Training Set: insieme di dati utilizzati per costruire il modello; Test Set: insieme di dati utilizzati per testare il modello.
Attraverso il parametro HoldoutMaxCases è stata infatti impostata la percentuale di dati destinati al test set per un valore pari al 30%. I modelli sono stati distribuiti e quindi elaborati, ed hanno fornito due risultati diversi. Il primo modello, creato utilizzando K-Means, ha fornito un risultato di soli 4 cluster molto diversificati tra loro. Il primo, quello più numeroso, si compone di 6131 record, il secondo di 3114, il terzo di 107 record e infine l’ultimo di 18 record. La distribuzione dei record tra i cluster è quindi molto sbilanciata.
Figura 48 Cluster ottenuti con K-Means
Analysis Services ci permette di visualizzare i cluster con dei grafici che rappresentano la distribuzione dei dati per ogni attributo.
Figura 49 Distribuzione dei valori di alcuni attributi nei cluster
Dalle analisi effettuate, possiamo ricavare le seguenti osservazioni sui cluster: Cluster 1: clienti per la maggior parte aperti da sede centrale, che hanno ampi volumi di fatturato, sia per Hardware che Software; essi hanno effettuato acquisti importanti anche nei negozi Cash & Carry; Cluster 2: clienti con un fatturato ingente soprattutto per le Business
Unit che riguardano la vendita di servizi e configurazioni; hanno anche un volume di fatturato considerevole nei negozi Cash & Carry;
Cluster 3: clienti la cui anagrafica non è stata aperta da un negozio C&C e che hanno acquistato soprattutto Hardware per un volume di fatturato modesto;
Cluster 4: clienti che hanno acquistato solo Hardware da negozi Cash & Carry; in particolare, si tratta di articoli appartenenti ad una sola Business Unit.
I risultati sopra elencati sono stati resi disponibili grazie a query DMX (Data
Mining Extensions): come già anticipato nei capitoli precedenti, esso
permette di interrogare i modelli di Data Mining per capire ad esempio a quale cluster appartenga un record. Nel nostro caso una delle query più utili è stata la seguente:
SELECT *
FROM [Clustering_KMeans_Scalabile].CASES
WHERE IsInNode('NUMERO_CLUSTER')
Essa ci permette, dato un cluster, di ottenere tutti i record che vi appartengono: in questo modo possiamo osservare subito quali siano le caratteristiche comuni ai record considerati e descrivere i cluster diventa più semplice.
Un altro strumento molto utile di Analysis Services è senza dubbio l’Analisi
discriminante tra cluster: essa ci permette di osservare le caratteristiche di
ogni cluster e confrontarle con quelle degli altri, oppure con un cluster specifico.
Il clustering ottenuto utilizzando l’algoritmo Expectation Maximization ha prodotto un risultato molto diverso da quello di K-Means. I cluster ottenuti sono risultati ben 8.
Figura 51 Cluster ottenuti con Expectation Maximization
Cluster 1: composto da 3794 record, si tratta dei clienti che hanno un basso valore fatturato in ogni Business Unit; le loro anagrafiche sono state aperte sia da Cash & Carry che da sede centrale;
Cluster 2: composto da 3224 record, tratta i clienti che hanno acquistato soprattutto articoli da Business Unit che trattano Hardware per cifre poco più alte rispetto a quelle del primo cluster. Hanno inoltre totalizzato un valore fatturato modesto nei Cash & Carry, benché per buona parte le loro anagrafiche siano stati aperte da sede centrale; Cluster 3: composto da 903 record, i clienti che si trovano al suo interno
mostrano un fatturato sempre modesto, ma localizzato in Business Unit specifiche, come ad esempio Samsung. Il valore fatturato di questi clienti è più alto rispetto a quello dei primi due cluster, sia da un punto di vista totale che del fatturato Cash & Carry; i volumi raggiunti rimangono comunque non troppo alti;
Cluster 4: composto da 780 record, per l’85% sono clienti non aperti da negozio Cash & Carry ed hanno un volume fatturato medio,
localizzato soprattutto nelle Business Unit che trattano articoli Hardware. Il fatturato Cash & Carry è ad un livello medio;
Cluster 5: composto da 281 record, riguarda i clienti che hanno un buon volume di fatturato in alcune Business Unit che riguardano la rivendita di Hardware, ma anche di servizi cloud. Il fatturato Cash & carry è ad un buon livello rispetto agli altri cluster;
Cluster 6: composto da 174 record, contiene i clienti con un buon livello di fatturato soprattutto per i servizi di configurazione e Hardware, con particolare attenzione verso gli acquisti nel settore della sicurezza (come videocamere di sorveglianza ad esempio). Il livello di fatturato nei negozi Cash & Carry è simile a quello del cluster 5;
Cluster 7: composto da 122 record, raccoglie tutti i clienti che hanno acquistato da tutte le Business Unit e per volumi di fatturato molto ampi;
Cluster 8: composto da 92 record, riguarda clienti che hanno acquistato soprattutto da Business Unit che trattano prodotti Software, per un volume di fatturato contenuto. Tali clienti non hanno praticamente effettuato acquisti dai negozi Cash & Carry.
Confrontando i due risultati di clustering ottenuti emerge che Expectation Maximization modella molto meglio la realtà aziendale, segmentando la clientela in modo più specifico e dettagliato. Inoltre, da un punto di vista computazionale, come visto nel paragrafo precedente, K-Means è risultato meno prestante e più lento durante l’elaborazione.
3.5 Visualizzazione dei risultati
Illustriamo in questo paragrafo come è stata costruita la dashboard Start, che mostra sia i dati relativi ai clienti analizzati, che il cluster a cui ognuno di essi appartiene (determinato mediante l’algoritmo Expectation Maximization).
3.5.1 Visual Analytics
Oltre a conoscere come analizzare i dati, è molto importante anche saper leggere le analisi effettuate e soprattutto estrarvi informazioni utili. La disciplina del Visual Analytics ci aiuta a conciliare l’esigenza di visualizzazione dei dati con la necessità di estrazione di nuove conoscenze. I metodi del Visual Analytics consentono al management di combinare la propria flessibilità, creatività e conoscenza con le enormi capacità di archiviazione ed elaborazione dei computer, in modo da ottenere informazioni nuove su problemi complessi. Utilizzando questo tipo di interfacce avanzate, possiamo quindi prendere decisioni sulla gestione aziendale con più consapevolezza.
3.5.2 MVC
MVC, acronimo di Model View Controller, è un pattern16 architetturale che
divide un’applicazione in tre componenti interagenti tra loro:
1. Model o modello: gestisce i dati e l’accesso ad essi, la logica e le regole dell’applicazione. Si occupa quindi di fare da tramite tra l’applicazione e il database sottostante;
2. View o vista: permette all’utente dell’applicazione di visualizzare l’interfaccia e utilizzarla. La vista è generata in base ai dati forniti dal modello ed è possibile generarne diverse a partire dallo stesso; 3. Controller o controllore: definisce il meccanismo mediante il quale
il modello e la vista comunicano. Realizza la connessione logica tra
l’interazione dell’utente con l’interfaccia applicativa e i servizi della business-logic nel back-end del sistema. Una richiesta (request) fatta al sistema passa attraverso il controller che individua all’interno del modello il relativo gestore (request handler). Una volta ottenuto il risultato dell’elaborazione (response), il controller determina a quale vista passare i dati per presentarli all’utente. Lo schema creato con MVC consente di separare la logica di business (del modello) dalla logica dell’interfaccia grafica (della vista) e dalla logica di input (del controller); inoltre rende più facile il testing dell’applicazione. Il pattern MVC è alla base della dashboard creata per il progetto formativo.
Figura 52 Pattern MVC
3.5.3 Dashboard START
La dashboard informativa è stata creata con Visual Studio, utilizzando il framework MVC con linguaggio C# e alcune librerie front-end per gli stili e i grafici. Tra queste ultime la più importante è senz’altro d3.js, scoperta durante l’esame di Visual Analytics sostenuto nel periodo di studi. D3 è una libreria JavaScript che permette di realizzare visualizzazioni interattive mediante Html, Svg e CSS. Grazie all’utilizzo di alcuni standard, d3 offre tutte le funzionalità dei browser moderni senza la necessità di legarsi ad alcun framework, combinando componenti di visualizzazione ad un approccio basato sulla manipolazione del DOM. Unitamente a d3.js è stata utilizzata anche NVD3, una libreria che permette di creare componenti grafici riutilizzabili con d3.
