Guida al data mining a misura di budget

A differenza della tradizionale programmazione delle applicazioni, in cui le funzioni API cambiano ogni giorno, la programmazione del database rimane sostanzialmente la stessa. La prima versione di Microsoft Visual Studio .NET è stata rilasciata nel febbraio 2002, con una nuova versione rilasciata circa ogni due anni, escluse le versioni del Service Pack. Questo rapido ritmo di cambiamento costringe il personale IT a valutare le applicazioni della propria azienda ogni due anni, lasciando intatta la funzionalità della propria applicazione ma con un codice sorgente completamente diverso per rimanere aggiornato con le ultime tecniche e tecnologie.

Lo stesso non si può dire del codice sorgente del database. Una query standard di SELECT / FROM / WHERE / GROUP BY , scritta nei primi giorni di SQL, funziona ancora oggi. Naturalmente, questo non significa che non ci siano stati progressi nella programmazione di database relazionali; c'erano, e sono stati più logici che tecnici .

A partire dai giorni in cui Bill Inmon e Ralph Kimball hanno pubblicato le loro teorie sulla progettazione del data warehouse, i progressi nella programmazione del database si sono concentrati sulla prevenzione della perdita di informazioni preziose e sull'estrazione di tutte le informazioni preziose dai dati. Una volta che Inmon e Kimball hanno introdotto il mondo dei database al data warehousing, sono state apportate importanti modifiche agli strumenti ETL (Extract/Transform/Load) che hanno consentito agli sviluppatori di database di accedere facilmente ai metadati e ai dati provenienti da fonti di database non relazionali, con cui era difficile lavorare nel passato. Ciò ha aumentato la quantità di dati disponibili da cui estrarre informazioni preziose e questo aumento dei dati disponibili ha portato a progressi nell'elaborazione dei dati tramite cubi OLAP e algoritmi di data mining.

L'aggiunta di un data warehouse, cubi OLAP e algoritmi di data mining all'architettura del database può semplificare notevolmente i processi aziendali e illuminare modelli nei dati che altrimenti non avresti mai saputo esistessero. L'automazione può anche avere un profondo impatto sulle capacità di business intelligence.

Tuttavia, prima di iniziare ad aggiungere nuovi strumenti e tecnologie, è necessario assicurarsi che il database delle transazioni sia stato creato correttamente.

Database delle transazioni

Il database delle transazioni è la base e, se il database delle transazioni non è affidabile e preciso, aggiungere qualcosa in cima è una ricetta per il disastro.

Un punto importante da tenere a mente quando si aggiungono livelli aggiuntivi al database è che tutti i progetti devono mostrare un ritorno sull'investimento , motivo per cui è meglio ottenere il massimo dall'architettura attuale prima di aggiungere ulteriori livelli. Tutti questi livelli utilizzano i dati provenienti da un database delle transazioni. In molte situazioni è possibile ottenere lo stesso output semplicemente interrogando il database delle transazioni. Naturalmente, la lettura di tutti i report da un data warehouse o da un cubo OLAP è il metodo ideale, ma quando un'organizzazione non è pronta per quel livello di complessità, è più importante che prima vengano soddisfatte le sue esigenze di reporting. Una volta soddisfatte le esigenze di reporting di base, è molto più semplice avviare una discussione su come un data warehouse adeguato, e possibilmente un cubo OLAP, possono avvantaggiare la propria attività.

Quasi tutti i programmatori conoscono le tre regole di normalizzazione del database. Le procedure memorizzate che leggono dal database delle transazioni sono il percorso per l'ottimizzazione. I problemi da cercare sono la leggibilità, più chiamate alla stessa tabella del database e l'uso non necessario delle variabili.

Tutti i programmatori di database d'élite sono esigenti riguardo alla leggibilità delle loro procedure memorizzate. Ci sono alcuni punti in comune nel modo in cui i professionisti del database formattano le loro query, che è diverso da uno sviluppatore di applicazioni. In genere, le parole chiave e le funzioni di aggregazione sono in maiuscolo, mentre i nomi di tabelle e campi utilizzano camelcase o underscore. Gli alias di tabella hanno una correlazione con il nome effettivo della tabella. L'allineamento delle sezioni della procedura memorizzata ha un tipo di pattern di blocco.

Di seguito è riportato un esempio di query che utilizza un formato leggibile.

 SELECT c.customer_id, c.name, SUM (po.purchase_amount) total_purchase_amount FROM customer c JOIN purchase_orders po ON c.customer_id = po.customer_id GROUP BY c.customer_id, c.name

La prossima cosa da cercare è se una query raggiunge una tabella più di una volta. Nella maggior parte delle query è necessario accedere a una tabella solo una volta, escluse le rare volte in cui è necessario aggregare un'altra funzione di aggregazione. Questo è un altro errore commesso da alcuni programmatori di applicazioni, forse perché un programmatore di applicazioni pensa in termini di progettazione orientata agli oggetti.

La progettazione orientata agli oggetti crea oggetti separati per ogni elemento di dati univoco, ma un programmatore di database deve pensare in termini di logica degli insiemi. Solo perché una query accede a una tabella più volte del necessario non significa che la query stia producendo dati imprecisi, tuttavia le prestazioni della query vengono influenzate.

Un'altra preoccupazione è l'eliminazione o la duplicazione dei record ogni volta che si ha un join, compromettendo l'accuratezza della query. L'uso non necessario delle variabili è un altro segno che una query è stata sviluppata da uno sviluppatore di applicazioni. Gli sviluppatori di applicazioni utilizzano variabili in tutto il codice mentre una query molto raramente deve utilizzare variabili, tranne quando dichiarata come parametro nella stored procedure. Ancora una volta è un segno che lo sviluppatore non stava pensando in termini di logica impostata.

ETL (Extract Transform Load) e reporting

Una volta che il database delle transazioni di un cliente ha query funzionanti correttamente, il passaggio successivo consiste nello snellire i processi aziendali.

Il modo più semplice per identificare la necessità di un'azienda di processi ETL o reporting automatizzato è scoprire chi sta leggendo i dati da un database delle transazioni e quindi manipolando i dati utilizzando un foglio di calcolo. Un foglio di calcolo ha la stessa struttura di una tabella di database. Entrambi contengono righe e colonne. Se hai utenti finali che manipolano i dati da soli, dovresti chiederti: "Perché questo processo non può essere automatizzato?"

L'automazione dei processi aziendali fornisce un ritorno sull'investimento immediato e dovrebbe essere sempre presa in considerazione prima di passare a progetti più costosi, come il data warehousing. Identificare gli utenti finali che manipolano i dati tramite un foglio di calcolo può sembrare semplice, ma c'è un avvertimento in questo processo.

Agli sviluppatori piace automatizzare i processi; è quello che fanno. Agli utenti finali non piacciono necessariamente i processi automatizzati, soprattutto se minacciano il loro lavoro. Quindi, non essere ingenuo e pensa che gli utenti finali si avvicineranno a te e identificheranno le attività quotidiane che possono essere automatizzate. Hai davvero bisogno di assumere un ruolo guida nell'identificare le opportunità di razionalizzazione.

Un sistema ETL ben costruito dovrebbe anche fornire la possibilità di tornare indietro di tutti i dati caricati in un database delle transazioni al file di origine originale. Questo è un pezzo critico dell'architettura del database. Se non si conosce la data/ora esatta in cui è stato aggiunto ogni record, insieme al nome dell'origine (nome utente o nome file) che ha aggiunto i record, non si è preparati a gestire dati errati caricati nel database delle transazioni. Dovresti chiederti: "E se qualcuno ci inviasse un file danneggiato?" Quanto tempo impiegheresti per identificare i record che ne derivano?

Data Warehouse

Esistono due teorie per la progettazione del data warehouse. La differenza tra le teorie di Inmon e Kimball può essere riassunta come segue:

La teoria di Inmon consiste nello sviluppare prima un data warehouse e quindi creare data mart dimensionali per la creazione di report dal data warehouse. La teoria di Kimball consiste nello sviluppare prima i data mart dimensionali per il reporting e quindi unirli insieme per creare il data warehouse.

Vuoi sempre fornire ai clienti il ​​più veloce ritorno sull'investimento. La creazione di data mart è un processo semplice. Inizi prendendo le query dietro i tuoi rapporti e modificandole dalla restituzione dei set di risultati alla memorizzazione dei set di risultati in tabelle permanenti. Devi semplicemente aggiungere TRUNCATE TABLE nometabella ; INSERT INTO tablename prima della parola chiave SELECT originale. Una volta che si dispone di alcune tabelle di data mart funzionali, l'identificazione delle opportunità per unire i data mart dovrebbe essere attuata; cercare query di report che utilizzano lo stesso elenco di tabelle e quindi unire l'elenco di campi. Ciò richiede una query più complicata, soprattutto quando l'elenco delle tabelle aumenta. Tuttavia, se si esegue un test completo della query, è possibile apportare ogni modifica incrementale senza interrompere i normali processi aziendali.

Ogni volta che apporti un miglioramento al design di un data warehouse Kimball, hai l'opportunità di mostrare un ROI al cliente. Questo perché il data warehouse viene creato per primo e i data mart di reporting vengono creati da un data warehouse statico. Pertanto, la maggior parte dei costi viene sostenuta all'inizio del progetto di data warehouse.

Cubo OLAP

Un cubo OLAP può avvantaggiare un'organizzazione fornendo dati aggregati con tempi di risposta rapidi, funzionalità di drill down ad hoc per gli utenti finali e data mining. Quando hai un cubo OLAP adeguato, puoi estrarre ogni bit di valore dai tuoi dati. Un cubo OLAP è costruito su un data warehouse, ma utilizza un linguaggio diverso, MDX, rispetto a un database SQL standard. Richiede anche uno sforzo di configurazione più impegnativo rispetto a un server di database. Tale complessità rende costoso un progetto OLAP, inoltre è difficile trovare sviluppatori MDX esperti.

Gli architetti di dati a volte vedono i cubi OLAP esistenti con nient'altro che un semplice dashboard che utilizza il cubo, senza un singolo processo che non può essere sostituito da una query SQL, un data warehouse o un report predefinito. Un cubo OLAP può fornire un tempo di risposta più rapido rispetto a un report predefinito, ma nella maggior parte dei casi la differenza è trascurabile. Puoi anche trarre vantaggio dalle funzionalità di drill down, tuttavia, prima di fornire funzionalità di drill down agli utenti finali, è una buona idea utilizzare report predefiniti che forniscono un'interfaccia ad hoc simile.

Ciò ti consente di registrare le query ad hoc eseguite dagli utenti finali, quindi puoi identificare nuovi report predefiniti che gli utenti finali non si rendevano conto che potevano essere creati. Poiché sia ​​il tempo di risposta che i miglioramenti del drill-down sono in genere minimi durante lo sviluppo di un cubo OLAP, non è necessario suggerirlo a un client finché non è necessario un'architettura di database in grado di gestire il data mining coinvolto. Questo è il momento in cui puoi davvero impressionare i clienti e mostrare loro qualcosa della loro attività che non avrebbero mai saputo senza una solida architettura di database.

Come accennato in precedenza, la creazione di un cubo OLAP può essere impegnativo. È buona norma considerare un cubo OLAP ibrido. PowerPivot di Microsoft Excel fornisce strumenti di data mining facili da usare senza la complessità di un cubo OLAP completo. Lo svantaggio principale di un ibrido è che non ha lo stesso tempo di risposta. Tuttavia, un grande vantaggio è che è più facile creare report di data mining utilizzando Excel rispetto all'utilizzo di MDX. Durante il data mining, sono disponibili tre report utili. Possiamo guardare alcuni esempi del mondo reale e come interpretarli.

Tutti questi rapporti provengono da un'applicazione di day trading automatizzata creata dall'autore.

Reportistica visiva

Rapporto grafico a dispersione

Un report grafico a dispersione è un report a livello di dettaglio che confronta due variabili. L'aggiunta di colore e dimensione ai punti effettivi aiuta a visualizzare i risultati effettivi in ​​relazione a tali variabili.

Rapporto scatola e baffi

Questo rapporto riassume i valori xey dal rapporto del grafico a dispersione. I valori dell'asse x vengono discretizzati in una serie di bucket.

Le estremità di ogni baffo (linea) rappresentano i valori anomali. Le barre gialle e azzurre rappresentano gli intervalli di deviazione standard superiore e inferiore.

Modello di regressione lineare

Questo rapporto mostra la correlazione tra i valori dell'asse xey, insieme a uno smussamento della linea, che può essere rappresentato da una formula matematica. Il valore R al quadrato è incluso per mostrare quanto sia affidabile la correlazione.

Conclusione

Man mano che la tua azienda cresce, in genere crescerà anche il tuo database.

La maggior parte delle organizzazioni inizialmente non ha bisogno di un professionista del database o di un'azienda dedicata alla scienza dei dati che gestisca le proprie esigenze. Invece, hanno il loro personale IT che si occupa di più responsabilità o, come si suol dire, "indossa molti cappelli". Funziona fino a un certo punto, ma alla fine è necessario coinvolgere specialisti.

Gli elementi elencati in questo documento sono un modo semplice e veloce per identificare i problemi del database di cui potresti non essere a conoscenza. Si spera che abbia anche spiegato come creare strumenti di data mining di prim'ordine senza spendere molto per costose licenze software. In questo modo avrai un'idea migliore di quanto la tua organizzazione potrebbe trarre vantaggio dall'aggiunta di un professionista del database al tuo personale IT.