Dispense di Sistemi Informativi PDF - Politecnico di Milano

Politecnico di Milano Scuola di Ingegneria Industriale e dell’Informazione Dispense di Sistemi Informativi v.0.7 Corso di Laurea Triennale in Ingegneria Gestionale A.A. 2023-2024 Autori Cinzia Cappiello, M...

Politecnico di Milano Scuola di Ingegneria Industriale e dell’Informazione Dispense di Sistemi Informativi v.0.7 Corso di Laurea Triennale in Ingegneria Gestionale A.A. 2023-2024 Autori Cinzia Cappiello, Mariagrazia Fugini, Barbara Pernici, Pierluigi Plebani, Mattia Salnitri, Monica Vitali Dip. Elettronica Informazione e Bioingegneria 6 maggio 2024 Indice 1 Introduzione 1 1.1 Sistemi informativi............................... 1 1.2 Modello di riferimento............................. 3 1.2.1 I dati................................... 7 1.2.2 Le funzioni............................... 9 1.2.3 La rete.................................. 12 1.3 Tipologie di sistemi informativi........................ 12 1.4 La progettazione................................ 13 2 Business intelligence 15 2.1 Data warehouse................................. 16 2.1.1 Architettura Data Warehouse..................... 17 2.1.2 Processo ETL.............................. 19 2.1.3 Approccio multidimensionale dei dati................. 20 2.1.4 Operazioni sul Data Warehouse.................... 24 2.1.5 Ciclo di vita del Data Warehouse................... 25 2.2 Data mining................................... 27 2.2.1 Regole di Associazione......................... 29 2.2.2 Classificazione.............................. 30 2.2.3 Clustering................................ 32 3 Applicazioni aziendali 35 3.1 ERP....................................... 36 3.1.1 Storia degli ERP............................ 36 3.1.2 Proprietà degli ERP.......................... 37 3.1.3 Funzionalità di un ERP........................ 38 3.1.4 Aspetti architetturali.......................... 39 3.1.5 Installazione di un ERP........................ 40 3.1.6 Benefici degli ERP........................... 41 3.2 CRM....................................... 43 3.2.1 CRM operativo............................. 44 3.2.2 CRM analitico............................. 47 3.2.3 CRM collaborativo........................... 47 3.2.4 Installazione del CRM......................... 48 3.3 SCM....................................... 48 4 Elementi architetturali e tecnologici 50 4.1 Evoluzione tecnologica............................. 50 i  4.2 Evoluzione applicativa............................. 54 4.2.1 Layer applicativi............................ 54 4.2.2 Distribuzione dei layer applicativi................... 55 4.3 Proprietà dei sistemi distribuiti........................ 57 4.3.1 Scalabilità................................ 58 4.3.2 Disponibilità.............................. 59 4.4 Cloud Computing................................ 60 4.4.1 Modelli di erogazione.......................... 60 4.4.2 Modelli di deployment......................... 63 4.4.3 Cloud Computing e Sistemi Informativi................ 64 4.5 Per approfondire................................ 66 5 La progettazione di sistemi informativi 68 5.1 Il processo di gestione del sistema informativo................ 68 5.2 Pianificazione.................................. 70 5.2.1 Pianificazione strategica........................ 70 5.2.2 Studio di fattibilità........................... 74 5.3 Ciclo di vita di sviluppo del SI......................... 81 5.3.1 Sviluppo SI - Modalità Make..................... 82 5.3.2 Sviluppo SI - modalità BUY...................... 83 5.4 Opzioni di gestione dei SI........................... 85 ii Capitolo 1 Introduzione 1.1 Sistemi informativi L’informazione è la risorsa aziendale che al giorno d’oggi guida gran parte delle innovazio- ni sia di prodotto sia di processo. L’informazione è, infatti, sempre più centrale all’interno delle organizzazioni: viene usata per la comunicazione, per il supporto ai processi e per il supporto alle decisioni (decision making), per il quale si ha bisogno di informazioni sulle alternative strategiche o di controllo possibili. Per esempio, nelle compagnia di telefonia mobile, le informazioni sugli utenti sono utili per proporre nuove tariffe, ottenere feed- back su iniziative di marketing, aggiornare le tariffe. In una linea di produzione, occorre memorizzare informazioni sui lavori effettuati (per esempio, tempo richiesto, percentuali di pezzi danneggiati), identificare problemi o migliorare l’esecuzione del processo. È al- tresì importante considerare che, per alcune aziende, l’informazione è non solo una risorsa ma anche un prodotto. Si pensi ai social network, che raccolgono un’enorme quantità di informazioni dei propri utenti e le utilizzano per vendere spazi pubblicitari altamente personalizzati ad aziende terze. Rispetto a qualsiasi altra risorsa aziendale, l’informazione ha alcune caratteristiche che la distinguono: è intangibile, non deperibile (non viene distrutta con l’uso) e auto-rigenerante (il suo utilizzo porta alla generazione di nuova informazione). Gestire l’informazione si traduce quindi in numerose attività, quali: Creare informazione. Acquisire informazione. Elaborare informazione. Archiviare informazione. Trasmettere informazione. Presentare informazione. È importante sottolineare come lo svolgimento di queste attività coinvolga diversi ruoli e strumenti all’interno di una organizzazione. Ritornando agli esempi esposti in precedenza, nel caso di una azienda manifatturiera, i dati relativi alla difettosità dei pezzi prodotti sono raccolti dagli operatori sulla linea, mentre l’analisi aggregata dei dati di difettosità in un periodo di tempo è competenza del responsabile di produzione, così come l’impatto 1  regole dell organizzazione IS persone eventi dati processi / procedure informazione IT feedback Figura 1.1: Rappresentazione di un sistema informativo () tra difettosità e mancanza di fatturato è invece oggetto di interesse per il management. Sono quindi fondamentali strumenti e conoscenze adeguate che diano supporto specifico ai ruoli interessati per una gestione efficiente ed efficace dei dati e che costituiscono il cosiddetto sistema informativo. Volendo dare una definizione precisa di sistema informativo, ci ispiriamo alla definizione data in che parte dalla considerazione che un sistema informativo è, innanzitutto, un sistema. È quindi un insieme di procedure, metodi e strumenti dedicati allo svolgimento di alcune funzioni per il raggiungimento di un dato risultato. Nel caso specifico dei sistemi informativi, tale sistema si alimenta di eventi, rappresentati con dei dati, che accadono in un’organizzazione e li trasforma in informazioni le quali devono essere opportunamen- te modellate e rappresentate a seconda di chi poi le utilizzerà. Sempre con riferimento all’esempio dell’azienda manifatturiera, gli eventi possono essere: l’arrivo di un ordine, la consegna di un prodotto finito così come la segnalazione di esaurimento di un prodotto a magazzino. Questi eventi possono attivare i processi organizzativi (e.g., l’avvio della pro- duzione dell’ordine, la notifica al corriere per la consegna o l’invio dell’ordine di acquisto per il materiale esaurito) che rappresentano la base di un’organizzazione. Al fine di supportare la trasformazione di eventi in informazione, possiamo fornire la seguente definizione: “Un sistema informativo è definito come l’insieme dei mezzi, della conoscenza or- ganizzativa e delle competenze tecniche per gestire la risorsa informazione” (v. Figura 1.1). Un sistema informativo è quindi qualcosa di complesso che, erroneamente, è spesso confuso con il sistema informatico che ne è l’aspetto tecnologico. Sebbene l’Information Techno- logy (IT) sia diventata pervasiva nel fornire tali strumenti, è utile sottolineare che l’IT non è obbligatorio: l’informazione può essere gestita anche in modo manuale. È chiaro, però, che l’uso dell’IT consente di organizzare e reperire l’informazione in modo efficiente 2 e facilmente replicabile pertanto, soprattutto ora che la quantità di dati prodotta e da gestire è sempre maggiore, ricopre un ruolo fondamentale. È inoltre importante ricordare che un sistema informativo cambia nel tempo con l’evolvere dell’azienda e delle tecnologie. L’evoluzione mantiene come obiettivo primario una effi- cace ed efficiente gestione della risorsa informazione secondo regole e obiettivi aziendali (business rules) con l’utilizzo delle tecnologie per una (o più) organizzazioni. Ciò richiede una adeguata attività di progettazione e sviluppo del sistema informativo attraverso una visione coerente degli aspetti sia di tipo organizzativo che di tipo tecnologico. Questo per rispondere ad una sempre maggiore interdipendenza tra la natura del sistema informativo di una azienda e la capacità dell’azienda stessa di rimanere competitiva. Infatti, quello che l’organizzazione può fare dipende molto spesso da che cosa il suo sistema informativo le permette di fare e, data la connettività fornita da Internet, come il sistema informativo può dialogare con sistemi di altre organizzazioni. Governare la complessità che si viene a creare con siffatti sistemi informativi non è un compito semplice. Per questo motivo sono stati proposti metodologie, metodi, tecniche e strumenti capaci di supportare la progettazione e realizzazione di un sistema infor- mativo che sia in grado di fornire ad un’organizzazione, che vuole definirsi in rete, uno strumento adatto per governare sia i processi organizzativi interni che quelli per cui è necessaria una interazione con altre organizzazioni. Nella prossima sezione si descrive un modello che identifica gli aspetti rilevanti da considerare nella progettazione di un sistema informativo. 1.2 Modello di riferimento Nel passato i sistemi informativi erano poco complessi e sostanzialmente dei sistemi chiusi: non connessi con altre aziende. Detti sistemi erano di supporto a un numero limitato di funzionalità a livello aziendale quali la produzione o la contabilità ed erano organizzati a silos: costituiti da una serie di applicazioni indipendenti specializzate nel supporto e/o ese- cuzione di una specifica funzionalità. Con il passare del tempo, la complessità dei sistemi informativi è aumentata. Si è passati, infatti, a sistemi composti da diverse applicazioni integrate tra di loro per supportare sia processi interni dell’azienda (intra-aziendali) sia processi che prevedono la collaborazione con altre aziende (interaziendali). Per definire la struttura del sistema informativo si ricorre al concetto di Architettura. Co- me già anticipato, l’architettura di un sistema può essere vista come la descrizione dei suoi componenti, delle relazioni fra gli stessi e dei principi che definiscono la loro progettazione e evoluzione nel tempo. Inoltre, tra gli aspetti più importanti nella definizione di una architettura vi è anche la necessità di considerare le diverse prospettive degli stakeholder del sistema. Definendo stakeholder coloro che sono in qualche modo interessati al siste- ma considerato, si può dire che gli stakeholder hanno interessi relativi all’intero ciclo di vita del sistema ma possono aver bisogno di analizzare l’architettura da diversi punti di vista (i.e., viewpoint). Si pensi ad esempio all’architettura di una città formata da diversi componenti quali edifici, strade, parchi ecc. Addetti degli uffici del comune della città potrebbero aver bisogno di una veduta aerea (cioè, una prospettiva globale) della città per vedere l’architettura nel suo complesso al fine di programmare interventi di sviluppo e crescita dell’area urbana. Una prospettiva locale, focalizzata sui dintorni di un singolo edificio potrebbe invece essere utile al proprietario di quell’edificio per analizzare la possi- 3 bilità di espansione dell’edificio e chiedere permessi di ampliamento. In tutti e due i casi, i due stakeholder sono interessati alla architettura della città per diversi obiettivi e quindi necessitano di analizzare l’architettura da due diverse prospettive. La definizione di una architettura deve permettere dunque di soddisfare le diverse esigenze degli stakeholder dando la possibilità di analizzare il sistema da diversi punti di vista e con diversi livelli di granularità. È per questo che ci si avvale di framework architetturali che stabiliscono le convenzioni, i principi e i metodi per descrivere le architetture in diversi domini e per diversi stakeholder. Se proviamo ad applicare questo concetto generale di architettura a un’organizzazione e al suo sistema informativo arriviamo alla definizione di Enterprise Architecture (EA). In , l’Enterprise Architecture viene definita come il mezzo per analizzare e descrivere una organizzazione nel suo stato attuale e futuro partendo da una prospettiva integrata di strategia, business e tecnologica. Rispetto a quanto visto per le architetture dei cal- colatori, in una Enterprise Architecture le componenti riguardano i dati, gli applicativi, le risorse organizzative, i processi aziendali. Pertanto il livello di astrazione considerato in questo ambito è più elevato rispetto al dettaglio molto tecnico discusso nella presen- tazione delle precedenti architetture (e.g., distribuite vs. centralizzate). L’EA fornisce, infatti, una panoramica (mappa) dei processi, sistemi, tecnologia, strutture e capacità di una organizzazione. Detta mappa fornisce un contesto strategico per supportare l’evo- luzione continua del sistema informativo dettata dalle spinte di business o tecnologiche. L’Enterprise Architecture può essere vista cioè come un blueprint di alto livello del siste- ma, che serve per capire la sua struttura interna come supporto alla sua progettazione, riprogettazione, configurazione e manutenzione. Questo non è molto diverso dell’architettura (tecnica) di un edificio complesso, un ponte oppure una metropolitana. Il fatto che un’architettura sia una matrice di alto livello signi- fica che l’enfasi è su una rappresentazione astratta, concettuale, e non sui singoli dettagli tecnici. Anche per questo è confrontabile con altri tipi di architetture: l’architettura di un edificio complesso o di un ponte, che non è specificata in termini di singoli colonne, mattoni, muri, ecc., ma con disegni astratti della costruzione da realizzare. Alla fine degli anni 90, John Zachman definì fondamentale l’uso di una architettura per descrivere il sistema informativo aziendale in quanto la tecnologia iniziava a consentire la distribuzione di applicazioni e dati su macchine diverse: a suo parere la decentralizzazione senza una struttura ben precisa avrebbe generato il caos. Propose così il framework per definire l’Enterprise Architecture : una tassonomia per organizzare documenti, specifiche e modelli architetturali (vedere Figura 1.2). In questo caso, il blueprint è definito da una matrice che organizza in modo sistematico quelli che sono i modelli utilizzati per rappresentare singole componenti della Enterprise Architecture. Il framework di Zachman è organizzato in righe e colonne. Le colonne definiscono gli Aspetti da analizzare, in particolare: Dati (cosa): si considerano i dati di cui l’organizzazione ha bisogno per operare. Funzioni (come): si analizzano le funzionalità eseguite dall’azienda per mandare avanti il proprio core business. Rete (dove): è relativa alla distribuzione geografica dell’organizzazione Persone (chi): la gente coinvolta nell’esecuzione delle diverse funzionalità aziendali 4  33 Figura 1.2: Il framework per l’Enterprise Architecture di Zachman 5  Tempo (quando): relativo agli eventi significativi per il business Motivazione (perché): si considerano gli obiettivi dell’azienda Le righe invece mettono in luce i diversi Punti di vista che possono interessare diversi stakeholder. In particolare Zachman individua: Scopo (contestuale): interessa chi deve fare pianificazione e fornisce una rappre- sentazione ad alto livello che descrive il sistema in termini di dimensioni, forma, relazioni e obiettivi di base Modello dell’azienda (modello concettuale): interessa il proprietario del sistema ed è una prospettiva orientata alla progettazione del business. Modello del sistema (modello logico): pensato per il progettista, fornisce una speci- fica dettagliata attraverso la definizione del modello del sistema Modello tecnologico (modello fisico): pensato per chi deve realizzare il sistema e deve tradurre il progetto logico in un progetto fisico Rappresentazione dettagliata: raccoglie le specifiche da dare ai programmatori per la realizzazione effettiva del sistema Funzionalità organizzativa: effettiva implementazione del sistema che è parte del- l’organizzazione Le celle del framework di Zachman create dall’intersezione tra righe e colonne definiscono le Viste che identificano i modelli e diagrammi in grado di fornire le informazioni su un particolare aspetto secondo un certo punto di vista. Se si ripercorre la colonna relativa ai dati, per esempio, si può vedere come lo scopo viene descritto attraverso la lista delle cose importanti da modellare in un particolare contesto. Il modello concettuale della ba- se di dati da realizzare viene fornito tramite diagrammi noti in letteratura (es. modello Entità-Relazione ER). La progettazione concettuale viene poi seguita dalla progettazione logica che traduce il diagramma definito a livello concettuale nella rappresentazione dei dati adeguata alla tecnologia prescelta. La realizzazione effettiva della base di dati viene preceduta da un modello fisico e dalla definizione puntuale dei dati da inserire nel siste- ma. L’implementazione effettiva, infine, genera la funzionalità organizzativa costituita dal database specifico (es. database Ordini). Ogni colonna letta dall’alto verso il basso specifica come diversi diagrammi e modelli vengono raffinati per passare dalle indicazioni del business all’effettiva realizzazione del sistema. Il framework di Zachman è uno strumento efficace per descrivere il sistema informativo dell’organizzazione nel suo complesso. Oltre allo scopo descrittivo, la descrizione dell’EA può essere utilizzata anche a scopo prescrittivo al fine di guidare l’evoluzione del sistema. Infatti, una cosa da sottolineare a questo punto è che anche l’Enterprise Architecture deve essere gestita, soprattutto con riferimento alle continue evoluzioni del sistema. Innanzitutto, durante un progetto, è necessario sviluppare l’architettura di riferimento futura (‘to-be’) in relazione a quella in essere (architettura presente, o ‘as is’). Inoltre, durante lo sviluppo di singole fasi di progetto, sarà necessario avere cura che l’architettura di riferimento prevista e quella effettivamente realizzata rimangano allineate nel tempo (Figura 1.3). 6  Archite(ura futura Governance e ges,one Archite(ura a(uale Figura 1.3: Processo di gestione della Enterprise Architecture Per ottenere questi due obiettivi, sono necessarie sia attività di governance (gestione strategica del sistema) sia di gestione nell’ambito dei singoli progetti. Nelle prossime sezioni si evidenziano gli aspetti maggiormente rilevanti ai fini di questo corso quali i dati, le funzioni e la rete. 1.2.1 I dati Nell’ambito dei dati è necessario prima di tutto evidenziare la differenza tra i termini dato e informazione. Questi due termini sono solitamente considerati sinonimi ma, in realtà, nell’ambito dei sistemi informativi hanno una forte caratterizzazione. Al fine di illustrare le differenze, si prenderà a riferimento la cosiddetta piramide della conoscenza mostrata in Figura 1.4 detta anche DIKW (Data Information Knowledge Wisdom). Si può notare come il dato rappresenti la base di tutto. La parola dato, infatti, deve essere interpretata come il participio passato del verbo dare. Quindi con dato noi in- tendiamo un fatto, una misura, qualcosa che è da considerarsi vera per definizione e che rappresenta una porzione della realtà che si vuole rappresentare. Associato ad un da- to vi è sempre il suo tipo e cioè il dominio di valori che tale dato può assumere. Ad esempio, se si vuole rappresentare la numerosità di una classe di studenti, il tipo di dato deve essere necessariamente numerico o, per essere più precisi, il tipo di dato deve essere un intero naturale poiché non è corretto rappresentare questa porzione di realtà usan- do numeri negativi, tantomeno utilizzando numeri con decimali. Oltre al tipo, un dato può essere caratterizzato dalla sua unità di misura. Ad esempio, volendo rappresentare la temperatura in un’aula, oltre ad associare un tipo numerico - questa volta reale - va altresì indicata la scala di misura (gradi Celsius o Fahrenheit). Siccome i dati raccolti possono essere numerosi, la disciplina delle basi di dati definisce metodi e strumenti per organizzarli all’interno di strutture più o meno complesse e più o meno flessibili in grado di rendere agevole e ottimale non solo la loro memorizzazione, ma anche il loro recupero. Difatti lo scopo di una base dati è rappresentare una porzione della realtà attraverso la memorizzazione di un insieme di dati che in qualche modo riflettono tale realtà. Questo è suggerito dal primo modello utilizzato per la progettazione di una base di dati e, cioè, il modello concettuale il cui scopo è appunto rappresentare ad alto livello la realtà per poter poi, attraverso trasformazioni tra modelli, riuscire a codificarle all’interno di un sistema informatico. Seguendo sempre lo schema suggerito dalla piramide della conoscenza, sopra il dato si 7  Figura 1.4: Piramide della conoscenza (fonte Wikipedia) posiziona l’informazione. Come detto in precedenza, molto spesso questi due termini sono usati come sinonimi. In realtà, l’informazione è costruita a partire dai dati e, in particolare, l’informazione può essere definita come l’organizzazione dei dati in categorie di comprensione. Infatti, un dato preso da solo senza alcun contesto di riferimento spesso non è utile. Avere un dato di temperatura senza sapere che questa temperatura si riferisce a un ambiente interno, ad esempio un’aula, oppure ad un ambiente esterno non ha alcun senso. Per questo motivo, affinché un dato sia utile deve essere combinato con altri dati al fine di definire un contesto che permetta di caratterizzare meglio la realtà che si sta rappresentando. Quindi, associato al numero di studenti, è utile avere l’anno accademico a cui si fa riferimento, mentre associata alla temperatura è utile avere la data in cui tale temperatura è stata misurata, assieme all’aula in cui tale misura è avvenuta. L’informazione si può quindi definire come l’output di interrogazioni rivolte ad un insieme di dati (presumibilmente organizzate in una basi dati), come ad esempio “quanti gradi ci sono oggi in aula magna?” oppure “qual è la media degli studenti iscritti negli ultimi cinque anni a ingegneria meccanica?”. Continuando a risalire la piramide, sopra l’informazione si trova la conoscenza (i.e., kno- wledge) che è ottenibile integrando l’informazione con l’esperienza. Sapere infatti che a metà dicembre nell’aula magna vi sono 32°C suggerisce la presenza di qualche anomalia in quanto tale valore si discosta da quanto l’esperienza suggerisce, e cioè dalla media di temperature solitamente osservate in quel periodo. La componente esperienziale porta quindi a dare una connotazione soggettiva alla conoscenza. Inoltre, mentre l’informa- zione permette di rappresentare la realtà in modo completo e utile, la conoscenza guida eventuali decisioni che possono influire sulla situazione attuale. Va sottolineato come la conoscenza viene acquisita nel tempo, attraverso l’esperienza di un soggetto, e solitamente non può essere trasferita ad altri soggetti. Al contrario, si possono trasferire informazioni 8 o, al massimo, esperienza con il problema però di riuscire a formalizzare quest’ultima. Ad esempio, che intorno temporale, rispetto alla misura della temperatura osservata, va considerato per il calcolo della serie storica? Solo il giorno stesso? Una settimana, un mese? Infine, vi è la saggezza (i.e., wisdom) che rappresenta un’estensione della classica piramide della conoscenza (il cui nome suggerisce che al vertice ci sia, appunto, la conoscenza) e che può essere definita come l’esperienza applicata alla conoscenza per guidare un soggetto a intraprendere l’azione più adatta in un determinato momento. Tornando all’esempio, l’aver capito - attraverso il confronto tra la temperatura attuale dell’aula magna e la serie storica delle temperature - che vi è una anomalia, può essere motivo per pensare di spegnere il riscaldamento in quanto l’esperienza insegna che tale azione ha influenza sulla temperatura. L’utilizzo della piramide, quale figura geometrica per la rappresentazione di questi concetti non è casuale. Innanzitutto offre una stratificazione a livelli, evidenziando come i livelli superiori sono costruiti a partire dai livelli inferiori: per ottenere l’informazione si ha bisogno dei dati, così come per generare conoscenza si ha bisogno di informazione. In secondo luogo, l’area ricoperta da ogni livello diminuisce con l’aumento di livello. Questo vuole rappresentare il grado di sintesi: in basso abbiamo i dati che sono molto numerosi e a un livello di granularità fine e quindi poco sintetici; in alto la saggezza è rappresentata con un numero minore di elementi e quindi molto sintetica e a granularità grossa. Sul ruolo dei dati, sulla progettazione delle basi di dati e sulle modalità di realizzazione di sistemi a supporto delle basi di dati è dedicata la prima parte del corso. Il testo di riferimento, per questa prima parte è. Successivamente, al supporto all’analisi dei dati con sistemi di business intelligence è dedicato il Capitolo 2 di questa dispensa. 1.2.2 Le funzioni Le funzioni si riferiscono alle operazioni svolte. In un’azienda vengono rappresentate da processi. Solitamente un processo è definito come l’insieme di attività che l’organizzazione nel suo complesso svolge per gestire il ciclo di vita di una risorsa, o di un gruppo omogeneo di risorse, per raggiungere un risultato definito e misurabile (prodotto/servizio). Per dare una classificazione dei processi e delle applicazioni, si può far riferimento al mo- dello gerarchico dell’organizzazione dato dalla Piramide di Anthony mostrato in Fig. 1.5. Nel modello di Anthony si distinguono tre livelli, legati alla struttura dell’organiz- zazione: un livello operativo, detto anche operazionale, in cui si considerano le attività di tipo operativo dell’azienda, un livello di programmazione e controllo, in cui si considera- no le attività tattiche quali la programmazione delle risorse disponibili e il controllo sul conseguimento degli obiettivi programmati, e un livello di pianificazione strategica, dove si collocano le attività legate alla scelta degli obiettivi aziendali e alla definizione delle politiche aziendali. Esempi di processi presso una pubblica amministrazione, quale un’amministrazione co- munale, sono i seguenti (suddivisi per livello): Operativo: contabilizzazione dei pagamenti dei cittadini, manutenzione delle strade. Controllo: controllo dei pagamenti, solleciti, confronti mensili tra entrate previste ed effettive, monitoraggio inquinamento. 9  Pianificazione strategica Scelta degli obiettivi aziendali Definizione delle politiche aziendali A"vità strategiche Programmazione Programmazione delle risorse e controllo disponibili Controllo sul conseguimento degli A"vità Ta"che obiettivi programmati Livello operazionale Conduzione delle attività aziendali A"vità opera2ve Figura 1.5: Modello a Piramide di Anthony 3 Strategico: verifica dei costi e dei ricavi relativi ai servizi sociali, definizione di nuove tariffe, piani regolatori. Presso una banca, esempi di processi ai tre livelli sono i seguenti: Operativo: gestione movimenti dei conti correnti, prelievi bancomat (ATM). Controllo: revisione degli scoperti, concessione di un mutuo. Strategico: verifica dell’andamento di un servizio, decisione di aprire nuovi servizi. Presso una azienda manifatturiera, esempi di processi sono i seguenti: Operativo: registrazione costi delle commesse, gestione magazzino. Controllo: controllo scostamenti settimanali tra preventivo e consuntivo. Strategico: scelta delle aree di mercato più convenienti. La piramide di Anthony offre anche la possibilità di comprendere la natura dei dati ge- stiti dai diversi livelli. Come mostrato in Figura 1.6, i sistemi informativi operazionali trattano alti volumi di dati che rappresentano in dettaglio gli eventi che accadono nell’or- ganizzazione. Tali dati sono ben strutturati (solitamente memorizzati in basi di dati) e provenienti dall’interno dell’organizzazione. Spostandosi ai sistemi informativi direzionali i dati sono sempre più aggregati poiché, nelle decisioni prese a questi livelli la sintesi è un requisito necessario. Al tempo stesso anche il formato potrebbe non essere più ben strutturato (vi sono anche documenti scritti in linguaggio naturale) e la loro provenienza è anche esterna. Un’altra differenza rilevante è l’orizzonte temporale considerato. Mentre livello operativo, i processi usano solitamente dati puntuali su un determinato evento (es., un singolo ordine), a livello di controllo e strategico, i dati utilizzati hanno un orizzonte 10  Dati Dati analitici sintetici Bassi Pianificazione volumi strategica Programmazione e controllo Alti volumi Attività operative Profilo informativo Livello di controllo Controllo operativo Controllo Pianificazione direzionale strategica Formato Dati elementari Sintesi Sintesi Struttura Predefinita Predefinita Variabile Frequenza Continua Periodica Non prefissata Fonte Interna Interna ed esterna Prev. esterna Figura 1.6: Profilo informativo dei sistemi informativi temporale esteso (es., gli ordini effettuati nell’ultimo mese o nell’ultimo anno). Esempi di dati operativi sono gli importi dei versamenti, le ore di presenza dei dipendenti; esempi di dati a livello di controllo sono i saldi mensili, la quantità di lavoro mensile di ciascun reparto; i dati strategici sono i dati macroeconomici, gli indicatori generali, o i dati di bilancio. Una ulteriore distinzione tra i livelli può essere fatta sulla base della natura dei processi supportati. Infatti, a livello operativo troviamo attività che vengono svolte in modo frequente e prevedibile, con un basso livello di discrezionalità relativamente al quando e al come eseguire un determinato processo. Nell’esempio precedente relativo alla banca, la gestione dei conti correnti deve essere effettuata ogni volta che viene effettuata una richiesta e i passi da eseguire saranno sempre gli stessi per ogni caso. Al contrario, la scelta di aprire un nuovo servizio è un attività per cui è difficile prevedere quando verrà effettuata e il processo decisionale potrebbe cambiare significativamente di volta in volta. Per questo motivo, i processi operativi sono facilmente automatizzabili, mentre quelli strategici che richiedono un alto livello di discrezionalità non possono esserlo. Alla luce di quanto discusso, è possibile individuare una stretta dipendenza tra i processi descritti nella piramide di Anthony e i livelli introdotti nella piramide della conoscenza. Ragionando sulle caratteristiche dei dati necessari per supportare i diversi livelli della pi- ramide di Anthony, è infatti possibile individuare delle corrispondenze tra le due piramidi. In particolare, il livello operativo userà il livello dei dati della piramide DIKW, caratteriz- zato da un alto livello di dettaglio. Il livello di controllo richiede l’uso di dati organizzati per categorie e aggregati, quindi utilizza informazioni. Il livello strategico deve permettere di unire le informazioni disponibili con l’esperienza dell’utente e di supportare sia analisi complesse dello stato corrente dell’organizzazione, sia prevedere l’effetto di determinate scelte nel futuro. Per questo motivo, il livello strategico utilizza i livelli della conoscenza e della saggezza della piramide DIKW. Il Capitolo 3 approfondisce le tematiche esposte, descrivendo i tipici sistemi a supporto 11 delle funzioni aziendali tra cui ERP, CRM, SCM. 1.2.3 La rete L’identificazione della localizzazione di un sistema informativo porta alla definizione dei nodi di elaborazione da cui è composto e dalla loro distribuzione geografica. Oggi la chiave di successo consiste nel progettare e realizzare sistemi informativi distribuiti, ovvero co- stituiti da applicazioni e dati risiedenti su vari nodi elaborativi, che permettono a diverse organizzazioni di lavorare in sinergia per gestire il carico applicativo e l’informazione in rete in maniera interconnessa, ma al tempo stesso mantenendo un certo livello d’indipen- denza tra le parti. Questa visione si contrappone con i sistemi informativi centralizzati, spesso basati su mainframe, che fino a pochi decenni fa costituivano la soluzione principale e che, nonostante la loro obsolescenza, sono ancora adesso parte del patrimonio hardware e software di diverse organizzazioni rendendo quindi la prospettata sinergia con l’esterno molto difficile da ottenere. Negli ultimi anni, questa tendenza a realizzare sistemi sempre più distribuiti, si concretizza nel Cloud Computing. Un approfondimento su alcune delle tecnologie e architetture oggigiorno rilevanti a sup- porto di un sistema informativo è incluso nel Capitolo 4. 1.3 Tipologie di sistemi informativi Data la complessità del dominio, non è pensabile avere un singolo sistema informativo in grado di coprire tutti i processi e gestire tutte le risorse organizzative. Per questo motivo, esistono diversi sistemi informativi (che possono anche essere integrati tra di loro) che si focalizzano su qualche processo o che sono in grado di gestire determinate risorse. Una classificazione di questi sistemi informativi è possibile prendendo a riferimento la piramide di Anthony e che permette di distinguere i sistemi informativi in: sistemi infor- mativi operazionali e sistemi informativi decisionali (detti anche Management Information Systems o, da alcuni autori, sistemi informazionali). La finalità dei sistemi operazionali è di svolgere operazioni di base, quotidiane, di normale amministrazione, quali la gestione di transazioni e di lavoro di ufficio, la contabilità, in generale la elaborazione di quelle che sono dette le situazioni aziendali. Le parti fondamentali di un sistema informativo operazionale sono la base di dati operazionale (che contiene in forma strutturata l’intera informazione operativa, ovvero a livello operativo nella piramide di Anthony) e le funzioni operative. In questo contesto, è fondamentale progettare in modo accurate le basi di dati. Ri- mandando al testo per tutti i dettagli, una base di dati operazionale solitamente si basa su tecnologia OLTP (On Line Transactional Processing) e organizza i dati all’interno di un DBMS (Data Base Management System) secondo il modello detto modello logico-relazionale. I sistemi decisionali o informazionali sono sistemi informativi a supporto delle at- tività decisionali e strategiche aziendali, in risposta all’esigenza di sfruttare il pa- trimonio dei dati per identificare le informazioni utili al processo decisionale. Con l’aumentare della quantità dei dati disponibili, è anche aumentata la richiesta di 12  Il bisogno di un’archite3ura funzionalità demand tecnologia pull technology qualità push stru3ura Business IT Figura 1.7: Il bisogno di una Enterprise“Beyond Architecture e-Business” Paul Grefen 2015 estrazione di informazioni strategiche. I sistemi informativi rispondono a questa esigenza con strumenti che si sono evoluti dagli originari strumenti di reportistica o strumenti tipo i fogli elettronici. Oggi esistono funzionalità sofisticate di estrazione e analisi dati a fini strategici, spesso basati su basi di dati di tipo OLAP (On Line Analytical Processing), alcuni delle quali saranno discusse nel Capitolo 2. 1.4 La progettazione Come già accennato in precedenza, un sistema informativo è un elemento vivo all’interno dell’organizzazione, soggetto a continue evoluzioni dettate da bisogni di innovazione di natura diversa con grado di impatto diverso sulla struttura organizzativa. Tale innovazio- ne deve essere opportunamente guidata, e questo avviene attraverso una piena conoscenza dei bisogni e dei vincoli organizzativi, così come dei bisogni e dei vincoli tecnologici Focalizzandosi sulla natura dei bisogni di innovazione, come illustrato in Figura 1.7, la necessità di cambiamento di un sistema informativo può derivare da spinte tecnologi- che (technology push) e/o spinte di business (requirements pull ) che vanno conciliate e integrate per lo sviluppo organico del sistema informativo. Le spinte di business possono derivare dal bisogno di nuove funzionalità oppure dall’e- sigenza di migliorare la qualità delle funzionalità offerte. Le spinte tecnologiche invece possono essere causate da una necessaria evoluzione tecnologica che spesso richiede an- che un adeguamento della struttura del sistema informativo. Si noti come le due spinte al cambiamento poi si possono influenzare a vicenda: la richiesta di nuove funzionalità necessariamente portano all’evoluzione tecnologica, mentre l’evoluzione tecnologica porta spesso alla possibilità di erogare nuovi servizi e funzionalità. Per mantenere gestibili le relazioni tra il lato business e quello tecnologico, è necessa- rio progettare strutture di natura astratta, in modo da risultare indipendenti da scelte specifiche, tecnologiche o di business. 13  Paradigm shift Redesign RISK Rationalization Automation RETURN Figura 1.8: Impatto trasformazione digitale sulle organizzazioni Indipendentemente da quale è la spinta che determina la necessità di innovare il siste- ma informatico, non tutte le trasformazioni operanti sul sistema informativo hanno lo stesso impatto. Utilizzando la classificazione proposta in , è possibile classificare le azioni che vanno sotto il cappello generale di digital transformation in quattro macro- categorie: automation, rationalization, redesign, paradigm shift. Come mostrato in Figu- re 1.8, le diverse evoluzioni hanno diversi gradi di rischio proporzionali al grado di ritorno sull’investimento. Nel caso dell’automation, l’azione coinvolge un supporto sempre maggiore della parte IT, toccando solo in minima parte l’aspetto organizzativo. L’obiettivo è, infatti, offrire un supporto per aumentare l’efficienza e l’efficacia nell’esecuzione dei task che costituiscono dei processi aziendali senza necessariamente modificare la struttura del processo stesso. La struttura del processo può invece essere oggetto di modifica in un’ottica di razionaliz- zazione in cui anche le risorse utilizzate nello svolgimento delle attività potrebbero essere riviste al fine di ottimizzare i processi. Nelc caso del redesign, dove possiamo trovare il business process reengineering, è prevista una modifica sostanziale dei processi, che di rimando coinvolge anche il sistema informativo a supporto delle attività che li compon- gono. Infine, l’innovazione potrebbe anche prevedere un cambio di paradigma aziendale, aprendo o modificando il business aziendale. Il Capitolo 5 affronta la tematica della progettazione descrivendo i passi fondamentali che devono essere svolti. 14 Capitolo 2 Business intelligence La progettazione e la realizzazione delle basi di dati descritta in riguarda principalmente la gestione di dati che, utilizzando la classificazione offerta dalla piramide di Anthony, si collocano principalmente a livello operativo. I dati sono però una risorsa importante non solo a livello operativo, ma anche a livello strategico e tattico per supportare i processi decisionali all’interno di un’organizzazione. Nasce quindi la necessità di accedere a dati aggregati in tempo reale e di eseguire in- terrogazioni complesse come l’analisi della correlazione tra diverse variabili (ad esempio la relazione esistente tra il luogo di residenza di un cliente e la sua predisposizione ad usufruire di una categoria di servizi). Quando ci si sposta dal livello operazionale verso i livelli più alti della piramide di Anthony cambiano sia la tipologia di dati di interesse, sia il modo in cui questi vengono usati. Perché le attività tattiche e strategiche abbiano successo è necessario fornire strumenti in grado di estrarre le informazioni di interesse da diverse fonti (interne ed esterne) e in modo veloce ed efficace oltre che supportarne la loro analisi. Tali strumenti rientrano all’interno della cosiddetta business intelligence. I primi strumenti di business intelligence sono stati i report. I report contengono dei dati spesso analitici, ottenuti dall’analisi della base di dati operazionale, che vengono prodotti seguendo un formato prefissato a scadenze regolari. Questo strumento soffre di diverse limitazioni: innanzitutto, i dati contenuti sono dati statici con cui l’utente non può interagire per ottenere dettagli o ulteriori informazioni su alcuni aspetti non previsti e, a fronte di una modifica dei dati operativi, solo rigenerando il report è possibile aggiornare lo stesso. Siccome la produzione dei report può risultare complessa e richiedere un tempo non trascurabile, questo può rendere molto difficile accedere all’informazione aggiornata. Infine, i report danno una visione limitata degli aspetti di interesse per le decisioni strategiche in quanto si basano soltanto sui dati interni dell’organizzazione che vengono estratti e aggregati dalla base di dati operazionale. Uno strumento più evoluto e parzialmente più dinamico per realizzare report è costituito dai fogli di calcolo (excel). In questo caso le analisi possono essere definite direttamente dall’utente finale che può cambiarle a suo piacimento ed eseguirle nel momento in cui le informazioni sono necessarie. Nonostante questi vantaggi rispetto ai report, i fogli excel risultano comunque limitativi a causa dei procedimenti complessi necessari per esportare i dati dal data base ed importarli nel foglio elettronico. Inoltre, usando un tale strumento, ogni utente può creare uno strumento personalizzato che nonostante i suoi vantaggi non 15 ha il beneficio di un controllo di integrità e di correttezza delle analisi che invece è tipico di strumenti condivisi. Oltre a questa breve descrizione dei report, tra gli strumenti di business intelligence più utilizzati, questo capitolo illustra i Data Warehouse (v. Sezione 2.1) e gli algoritmi di data mining (v. Sezione 2.2). 2.1 Data warehouse Il Data Warehouse è una base dati che raccoglie dati sintetici, integrati e strutturati di interesse per un organizzazione. In senso più esteso, si può definire invece il data ware- housing come l’insieme di tutte le operazioni atte alla progettazione e popolazione della base di dati, al suo mantenimento, e tutte le tecniche di interrogazione che permettono di estrarre l’informazione dal database direzionale. Il data warehouse è un sistema di tipo OLAP (On Line Analytical Processing) e deve quindi godere delle proprietà FASMI (Fast, Analytical, Shared, Multidimensional, Informational): deve fornire una visione multidimensionale dei dati (multidimensional) che devono contenere tutte le informazioni di interesse (informational) su cui permette di effettuare analisi complesse (analytical) a più utenti ma con diversi permessi di accesso ai dati (shared) rispondendo alle loro richie- ste in un tempo ridotto (fast). Inoltre, il data warehouse si caratterizza per i seguenti aspetti: Orientato alle entità : offre una analisi in cui l’elemento da considerare sono le entità rilevanti per il dominio in esame. Per esempio le vendite, gli ordini, i prodotti possono essere delle entità di analisi. Integrato: i dati considerati vengono prelevati sia da fonti interne che da fonti esterne all’azienda. Partendo da dati disomogenei essi devono essere resi consistenti e integrati in modo da avere una visione completa e chiara delle entità analizzate. Variabile nel tempo: Il data warehouse memorizza dati storici. Al fine di analizzare la storicità degli eventi tutti i dati sono associati a un’etichetta temporale che ne identifica il periodo di riferimento. Persistente: una volta inseriti in un data warehouse, i dati non vengono solitamente modificati. I dati sono archiviati in modalità di sola lettura. Come detto in precedenza, i data warehouse sono sistemi di tipo OLAP. Questo li distingue dai DBMS tradizionali che invece si poggiano su tecnologie di tipo OLTP (v. Figura 2.1). I sistemi OLTP (On-line Transaction Processing) sono quelli che trattano operazioni ca- ratterizzate da un gran numero di transazioni brevi e on-line1 che spesso si caratterizzano dall’uso di operazioni quali INSERT, UPDATE, DELETE. I sistemi OLTP sono focaliz- zati sulla gestione molto rapida delle query, sul mantenere l’integrità dei dati in ambienti multi-accesso e sul garantire l’efficienza ed efficacia del sistema, misurata dal numero di transazioni al secondo. Scopo dei sistemi OLTP è garantire le proprietà ACID (Atomicity, 1 Si noti che il termine on-line in questo ambito non indica il una transazione visibile su Web, ma una transazione i cui effetti sono immediatamente riscontrabili sul sistema. Questo termine evidenzia l’evoluzione rispetto ai sistemi usati in precedenza detti di tipo batch, che rendevano visibili gli effetti della transazione solo a fronte di un aggiornamento che avveniva a intervalli regolari (solitamente notturno). 16  OLTP vs OLAP OLTP OLAP Utente Impiegato (molti) Dirigente (pochi) Funzione Operazione giornaliere Supporto alle decisioni Progettazione Orientata all applicazione Orientata al soggetto Dati Correnti, aggiornati, Storici, aggregati, dettagliati, relazionali, multidimensionali, omogenei eterogenei Uso Ripetitivo Casuale Accesso Read-write, indicizzato Read, sequenziale Unità di lavoro Transazione breve Interrogazione complessa Metrica Throughput Tempo di risposta Figura 2.1: OLTP e OLAP OLTP Online Transac.on Processing – livello opera.vo Consistency, Isolation, and Durability) che permettono di avere una base dati condivisa su cui è possibile gestire le informazioni tipiche delle transazioni a livello operativo (e.g., aggiunta di un ordine, inserimento nuove fasi di lavorazione, stato di una lavorazione). Per questo nei sistemi di gestione di dati OLTP sono memorizzati dati dettagliati e attua- li. Lo schema usato per mantenere le basi di dati transazionali in genere segue un modello relazionale e le query accedono a record individuali o gruppi limitati (per esempio, la sin- gola fattura, le fatture del mese, le lavorazioni in esecuzione). Per questi motivi, i sistemi OLTP sono adeguati nella gestione di processi a livello operativo e di controllo. I sistemi di gestione di dati OLAP (On-line Analytical Processing) invece trattano dati storici (o d’archivio). Il paradigma OLAP è caratterizzato da poche transazioni e inter- rogazioni (query) complesse che richiedono aggregazione di dati. I sistemi OLAP hanno come misura di efficienza il tempo di risposta. e memorizzano i dati secondo schemi multi- dimensionali. Spesso, le interrogazioni accedono a grandi quantità di dati per rispondere a quesiti complessi come, per esempio, qual è stato il profitto netto realizzato dall’azienda in una certa area geografica nello scorso anno. Quindi, i sistemi OLAP sono utilizzati per l’elaborazione di dati orientata al supporto decisionale, e di conseguenza sono adeguati a funzionalità collocate a livello di pianificazione e strategico della piramide di Anthony. Essi permettono infatti di realizzare operazioni complesse e casuali, in cui ogni singola operazione può coinvolgere molti dati aggregati, storici, e in genere anche non attuali, e per cui le proprietà ACID – pensate per l’ambito transazionale – non sono rilevanti perché le operazioni sono di sola lettura. Come si vedrà successivamente, le tecnologie OLAP sono classificate in base alle strutture utilizzate (MOLAP - Multidimensional OLAP, ROLAP - Relational OLAP o HOLAP - Hybrid OLAP). 2.1.1 Architettura Data Warehouse Per meglio comprendere quelle che sono le peculiarità di un data warehouse è utile partire dalla sua tipica architettura, mostrata in Figura 2.2. Alla base dell’architettura ci sono le sorgenti, cioè le fonti da cui i dati che popoleranno il data warehouse devono essere estratti. Queste sorgenti comprendono sicuramente i database operazionali dell’organizzazione, 17  Query Data Sorgenti Esterne Data Mart Mining Motore OLAP ETL Report Big Data Data Warehouse Strumenti di Report Data Mart DB Operazionali Staging Area Sorgenti Operazioni ETL Dati Informazionali Strumenti di Analisi Figura 2.2: Architettura del data warehouse a tre livelli ma anche altre basi di dati e/o sorgenti interne o esterne all’organizzazione stessa che possono essere strutturate secondo varie forme (database, report, big data, ecc.). Tutte queste sorgenti vengono elaborate da un insieme di strumenti detti ETL (Extraction, Transformation, and Loading) che permettono di estrarre dalle sorgenti i dati di interesse, di trasformarli secondo la struttura multidimensionale desiderata, e caricarli all’interno del data warehouse. La fase di popolamento può far uso di un database intermedio tra le sorgenti e il data warehouse vero e proprio chiamato staging area. Il data warehouse è invece la base di dati multidimensionale contenente tutte le informazioni di interesse accessibili mediante la valorizzazione delle dimensioni di analisi. In base alla presenza o meno della staging area, l’architettura del DW può essere a due (senza staging area) o tre (con staging area) livelli. A valle del data warehouse ci può essere un altro tipo di base di dati chiamata data mart. I data mart sono dei piccoli data warehouse tematici contenenti un estratto del- l’informazione contenuta nel data warehouse completo. Quest’ultimo può infatti avere dimensioni molto elevate che difficilmente sono di interesse per tutti gli utenti del siste- ma. Utilizzando i data mart è possibile definire viste del data warehouse che contengono un sotto-insieme delle informazioni. Questo sotto-insieme può essere una riduzione delle dimensioni di analisi (si prendono in esame solo quelle di interesse per la categoria di utenti a cui il data mart è indirizzato), del livello di granularità delle dimensioni, oppure dell’orizzonte temporale selezionato. Si noti che un’architettura in cui si ha solo il DW si definisce architettura centralizzata: qui tutti i dati sono contenuti nel solo database multidimensionale centralizzato. Al contrario, l’uso dei data mart permette l’uso di un’architettura distribuita in cui i diversi database tematici possono essere posizionati su nodi diversi. Per fare un esempio possiamo riferirci ad una catena di supermercati che utilizza il data warehouse per migliorare la propria azienda. Qui le sorgenti di informazioni possono esse- re varie. Prima di tutto ci sono i database operazionali, nel caso specifico il database con i dati delle vendite e quello delle scorte di magazzino. Possono inoltre essere di interesse per le analisi anche le informazioni relative alle campagne pubblicitarie condotte dalla catena. Altre sorgenti che possono influenzare le decisioni possono invece provenire dall’esterno 18 come i dati meteorologici (un’analisi delle vendite di alcuni prodotti potrebbe essere in- fluenzata anche dalle condizioni atmosferiche), e dati provenienti da agenzie specializzate nell’analisi delle vendite. Queste informazioni vengono trasformate e ristrutturate utiliz- zando le trasformazioni ETL per essere poi immagazzinate nel Data Warehouse aziendale. Dalla interazione con il data warehouse possono essere prese decisioni che sono influen- zate da tutte le sorgenti analizzate, come ad esempio la pianificazione dei rifornimenti. Altri settori, come la gestione dei clienti o la pianificazione logistica, usano invece un sot- toinsieme dei dati contenuti nel data warehouse e per questo motivo si può pensare alla creazione di data mart tematici che possono essere interrogati tramite un motore OLAP e da cui è possibile estrarre in modo automatizzato dei report. Nel seguito saranno approfonditi alcuni degli aspetti che costituiscono il DW. Innanzitutto il processo ETL che, partendo dalle sorgenti, permetterà di alimentare il DW. In secondo luogo si definiranno le caratteristiche del modello multi-dimensionale utilizzato per la rappresentazione dei dati all’interno del DW o dei data mart. Infine, saranno illustrate le operazioni OLAP necessarie all’analisi di un DW o dei data mart. 2.1.2 Processo ETL Il processo ETL si compone di tre macro-fasi il cui obiettivo è quello di estrarre, trasfor- mare e caricare i dati nel data warehouse. Per quanto riguarda l’estrazione, essa definisce quali dati devono essere estratti e come devono essere trattati (es. se devono essere aggregati alla fonte o estratti al massimo livello di dettaglio). Inoltre, l’estrazione può essere: (a) statica se vengono considerati tutti i dati presenti nelle sorgenti o (b) incrementale se vengono presi in considerazione solo i dati prodotti o modificati dalle sorgenti nell’intervallo di tempo intercorso dall’ultimo aggiornamento del data warehouse. A seguito dall’estrazione, i dati necessitano di alcune trasformazioni in quanto derivando da fonti eterogenee possono essere rappresentati in formati diversi e di conseguenza po- trebbero risultare non facilmente integrabili. Le principali operazioni di trasformazione che vengono eseguite sono: Pulizia dei dati: i dati estratti dalle sorgenti molte volte contengono errori che devo- no essere corretti prima del loro inserimento nel data warehouse. Questa operazione viene solitamente fatta per prima nella fase di trasformazione ma in alcuni casi può essere fatta anche dopo o durante. I principali problemi relativi alla qualità dei dati che vengono risolti in questa fase sono la mancanza di dati, la presenza di valori inammissibili e l’inconsistenza tra valori presenti in campi diversi che sono legati da particolari regole o che hanno lo stesso significato. Riconciliazione: l’integrazione di dati diversi deve essere preceduta da questa ope- razione che mira a mettere in relazione i dati relativi allo stesso “oggetto”. Standardizzazione dei formati: i dati devono essere resi omogenei con delle ope- razioni di standardizzazione. Dette operazioni si riferiscono a (i) Congiunzione o spezzamento di campi: informazioni presenti in più campi vengono ricondotti a un campo solo o informazione presente in un campo viene riportata in campi separati; (ii) Standardizzazione di codici di classificazione: convenzioni diverse per indicare 19  lo stesso criterio vengono allineate a una stessa codifica; (iii) Standardizzazione del formato dei dati: dati rappresentati con formati diversi vengono resi omogenei Ricerca e eliminazione dei duplicati: in caso di presenza di informazioni duplicate, questa operazione permette di identificarle e di ridurle a una singola istanza. Infine, il processo ETL si conclude con la fase di caricamento che si occupa di trasferire i dati nel data warehouse seguendo il modello multidimensionale adottato, come sarà discusso nella Sezione 2.1.3. Le funzionalità svolte dagli strumenti ETL sono supportate e documentate da metadati (dati relativi ai dati). I metadati sono una parte importante dell’architettura di un data warehouse e di solito sono raccolti in un repository che include: Struttura del DW : i metadati descrivono la struttura del DW (schemi, viste, dimen- sioni, gerarchie, la scomposizione in data mart e relativa localizzazione. Metadati operazionali: si riferiscono alla storia dei dati e documentano la fonte di origine e le trasformazioni subite. Metadati per mappare i dati operazionali ai dati caricati nel DW : forniscono infor- mazioni sulle sorgenti e sul loro contenuto, le regole di trasformazione e di aggior- namento del DW. Statistiche d’uso: i metadati descrivono anche come e con che frequenza viene utilizzato il DW. 2.1.3 Approccio multidimensionale dei dati L’ipercubo I dati sintetici usati a supporto delle attività strategiche e decisionali si differenziano dai dati operazionali per diverse caratteristiche (vedi Fig. 2.1): e.g., hanno un grado di aggregazione maggiore, sono di volume minore, derivano da operazioni anche complesse su dati di dettaglio. Date queste caratteristiche, il classico modello relazionale non è soddisfacente per realiz- zare una base di dati analitica, cioè che sarà utilizzato principalmente per analizzare i dati contenuti piuttosto che per supportare le transazioni operative. Per questo motivo si ricorre ad altri tipi di modelli, come il modello multi-dimensionale. In tale modello l’informazione è rappresentata tramite il concetto di ipercubo, formato da un numero variabile di dimensioni N in cui ogni dimensione è una dimensione di analisi per la base di dati. Ogni elemento è un oggetto della base di dati, cioè la registrazione di un’infor- mazione, il cui valore è definito dalle coordinate rappresentate dalle dimensioni di analisi. Gli elementi costitutivi di una base dati multidimensionale sono: Fatto: il fatto è l’elemento dell’ipercubo ottenuto specificando un valore per ogni dimensione; Dimensione: coordinate di ciascun elemento che corrispondono a dimensioni di analisi; Misura: valore quantitativo del fatto elementare. 20  Prod.6 MISURA: Costo unità = 5.70 Prodotto Prod.5 Quantità = 58 Sconto = 0.57 Prod.4 Prod.3 Prod.2 06/03/2017 05/03/2017 04/03/2017 03/03/2017 Prod.1 02/03/2017 Data 01/03/2017 Negozio1 Negozio3 Negozio5 Negozio2 Negozio4 Negozio6 Punto Vendita Figura 2.3: Ipercubo a tre dimensioni che rappresenta gli aspetti rilevanti per l’analisi delle vendite di una catena di supermercati Un esempio di ipercubo tridimensionale per l’analisi delle vendite di una catena di super- mercati è mostrato in Figura 2.3, in cui le dimensioni di analisi sono il tempo, il prodotto e il punto vendita, mentre il fatto è costituito dalla vendita e ha come misure la quantità venduta, il costo unitario e lo sconto applicato. Ogni dimensione rappresenta una delle coordinate del fatto e ha un dominio di valori discreti che permettono di definire l’insieme dei fatti di interesse. Nel caso in cui i valori di una dimensione non siano discreti, questi devono essere resi tali applicando ad esempio delle soglie. Le dimensioni possono essere numerose e organizzate in gerarchie, dove il livello di granularità varia da livello a livello. Le gerarchie delle dimensioni sono organizzate in modo che esista una dipendenza fun- zionale tra un livello a più alta granularità e un livello a più bassa granularità , tale che tra di essi esista una relazione del tipo 1...N. Nell’esempio di Figura 2.4, i prodotti sono suddivisi in più categorie. Ogni categoria comprende uno o più tipi di prodotti e ogni tipo comprende più prodotti specifici. Lungo una linea gerarchica le relazioni determina- no aggregazioni diverse per la dimensione considerata. Ritornando quindi all’ipercubo di Figura 2.3, la dimensione prodotto può essere manipolata cambiando il livello di granu- larità , ad esempio considerando non i singoli prodotti ma raggruppandoli per categoria. In questo caso, il contenuto del fatto sarà l’aggregazione delle informazioni per tutti i prodotti appartenenti alla categoria considerata. Simili operazioni sulle dimensioni, le loro granularità o i loro valori permettono di selezionare il livello di dettaglio di interesse per l’analisi. Modello concettuale del Data Warehouse Così come visto anche per i data base tradizionali, la progettazione di un data warehouse come insieme di dati multi-dimensionali passa attraverso una progettazione di tipo concet- tuale, logica e fisica. Relativamente al primo aspetto, esistono divesi modelli concettuali per rappresentare i sistemi multidimensionali. Quello più utilizzato è il Dimensional Fact Model (DFM). Nel DFM, il fatto è rappresentato come un rettangolo contenente le misure 21  Prodotto Tipo Categoria ID Prodotto Pesce Alimentari Carne Detersivi Bagnoschiuma Bibite Biscotti Figura 2.4: Esempio di gerarchia per la dimensione prodotto. Il livello di granularità cresce da destra verso sinistra. corrispondenti. Le dimensioni sono invece rappresentate come cerchi etichettati collegati al fatto stesso. Le dimensioni possono essere semplici attributi del fatto oppure delle gerarchie, rappresentate come alberi che hanno come radici le dimensioni di base. Alcuni attributi delle gerarchie possono essere opzionali e questo viene indicato nel DFM tramite una barra sulla linea corrispondente all’attributo. Un esempio di DFM rappresentante il fatto vendita per la catena di supermercati citato prima è riportato in Figura 2.5. Il fatto in questo caso è rappresentato dalla vendita che ha come misure la quantità venduta, il valore unitario e l’eventuale sconto corrispondente. Il fatto è determinato da quattro dimensioni: la data in cui la vendita è stata effettuata, il luogo in cui si è verificato il fatto, il prodotto oggetto della vendita e il cliente. Ad ognuna di queste dimensioni è associata una gerarchia, attraverso la quale è possibile effettuare analisi più o meno dettagliate sui fatti registrati nel data warehouse. Ad esempio è possibile analizzare la quantità totale di vendite relative ad uno specifico prodotto per tutto il periodo di analisi per i punti vendita relativi alla città di Milano raggruppati in base al sesso dei clienti. Queste informazioni risultano dall’aggregazione lungo le varie gerarchie delle dimensioni considerate. Nel DFM modellato, l’attributo età per il cliente è opzionale. Il DFM mostrato come esempio corrisponde all’ipercubo relativo alle vendite per la catena di supermercati. Il Data Warehouse però non sarà composto da un solo ipercubo, ma da tanti ipercubi, ognuno in grado di modellare le dimensioni relative ad un fatto di interesse per l’analisi. Per ognuno di questi ipercubi sarà quindi modellato un DFM, con la definizione del fatto, delle misure, delle dimensioni e delle loro gerarchie. Modelli logici del Data Warehouse Una volta definito il modello concettuale della base dati multidimensionale, questa deve essere implementata traducendo il modello concettuale in un modello logico. Si deve quindi scegliere che DBMS utilizzare per gestire l’informazione multidimensionale. Modelli MOLAP La scelta più diretta potrebbe essere quella di utilizzare un modello logico di tipo MOLAP (Multidimensional OLAP). Il modello MOLAP traduce il model- lo concettuale in un database multidimensionale che può essere interrogata utilizzando motori multidimensionali progettati appositamente per trattare questa tipologia di dati. Questo tipo di modello ha il vantaggio di tradurre in modo esatto il modello concettuale e di sfruttare tutti i vantaggi di una base di dati multidimensionale, rendendo le inter- rogazioni efficienti e veloci. D’altro canto però, i database multidimensionali sono molto meno diffusi dei classici database relazionali e utilizzarli richiede conoscenze specifiche che 22  Categoria Tipo Marchio Prodotto Settimana VENDITA Costo Unità Quantità Stato Regione Città Zona Punto Data Mese Trimestre Anno Sconto Vendita Cliente Attributo Opzionale Sesso Età Figura 2.5: Data Fact Model per le vendite di un supermercato l’utente medio non possiede. Inoltre si tratta per lo più di modelli e linguaggi proprie- tari per i quali uno standard diffuso non è definito. Infine, il modello multidimensionale si basa sul concetto di ipercubo, in cui per ogni possibile combinazione dei valori delle dimensioni deve essere allocata una cella di memoria per salvare il fatto corrispondente, anche se questo in realtà non si è verificato e la cella rimane vuota. Modelli ROLAP Per ovviare a questi problemi è possibile utilizzare in alternativa al modello MOLAP un modello logico di tipo ROLAP (Relational OLAP). I modelli RO- LAP traducono il modello concettuale multidimensionale in un modello relazionale che rappresenta quindi i dati mediante l’uso di tabelle e permette di svolgere le interrogazioni utilizzando linguaggi di interrogazione noti basati su SQL ed effettuando operazioni di JOIN sulle tabelle descriventi il fatto e le sue dimensioni. I vantaggi principali di questo modello sono una conseguenza della conoscenza degli strumenti di interrogazione su da- tabase relazionali che permettono quindi agli utenti di interagire con il Data Warehouse senza conoscenze specifiche. Inoltre, essendo basata sul modello relazionale, lo spazio occupato da questa rappresentazione è ridotto rispetto a quello necessario per il modello MOLAP, poichè ogni fatto corrisponde ad una riga del DB e non è necessario riservare spazio anche per fatti che non sono stati registrati. Questo modello ha però degli svan- taggi dovuti alla difficoltà di aderire con il modello concettuale dei dati e alla lentezza e macchinosità delle interrogazioni su un motore relazionale che poco si presta a gestire dati multidimensionali. Al fine di mappare un database multidimensionale in uno schema relazionale è necessario identificare le tabelle che comporranno questo schema. In letteratura esistono due ap- procci principali per questo scopo: lo schema a stella e lo schema a fiocco di neve. Nello schema a stella, vengono utilizzate due tipologie di tabelle: la tabella dei fatti e le tabel- le delle dimensioni. La prima contiene tutti gli attributi corrispondenti alle misure del fatto e ogni riga di questa tabella corrisponderà quindi ad un fatto specifico. Le tabelle delle dimensioni contengono invece, per ogni dimensione associata al fatto nello schema multidimensionale, tutti gli attributi relativi alla gerarchia corrispondente alla dimensio- ne. Un’interrogazione si tradurrà quindi in un JOIN tra tutte le tabelle coinvolte sulla base del fatto di interesse. In questo modo però viene perso il concetto di gerarchia delle 23  Prodotto ID_Prodotto NomeP Data DescrizioneP ID_Data Regione Tipo ID_Tipo Giorno ID_Regione ID_Tipo DescrizioneTipo Mese NomeRegione Data Prodotto DescrizioneTipo ID_Marchio Anno ID_Stato ID_Categoria ID_Data ID_Prodotto NomeMarchio Trimestre Stato NomeCategoria Giorno NomeP LogoMarchio Settimana ContinenteSt PuntoVendita Mese DescrizioneP ID_Categoria ID_PuntoV Vendita Anno ID_Tipo NomeCategoria Marchio Indirizzo Città Trimestre ID_Marchio ID_Vendita Settimana ID_Marchio ID_Zona ID_Art ID_Citta DescrizioneZ Cliente NomeCitta NomeMarchio ID_Data Vendita Cliente LogoMarchio ID_Citta ID_Cliente ID_Tessera CAPCitta NomeCitta ID_Regione ID_Vendita ID_Tessera ID_Prodotto CF_Cliente PuntoVendita CAPCitta ID_Art CF_Cliente Costo Unità Nome ID_PuntoV ID_Data Nome ID_Regione Quantità Cognome Indirizzo ID_Cliente Cognome NomeRegione Sconto Indirizzo ID_Zona ID_Prodotto Indirizzo ID_Stato Mail DescrizioneZ Costo Unità Mail Stato Sesso ID_Citta Quantità Sesso ContinenteSt FasciaEta Sconto FasciaEta (a) Schema a stella (b) Schema a fiocco di neve Figura 2.6: Confronto tra schema a stella e schema a fiocco di neve per rappresentare il fatto Vendite di una catena di supermercati dimensioni, che viene appiattita all’interno di un’unica tabella. Un approccio alternativo prevede di usare uno schema a fiocco di neve, in cui ad ogni dimensione vengono associate più tabelle con le opportune relazioni, che permettono così di conservare alcune delle di- pendenze funzionali più rilevanti per gli utenti. Un confronto tra i due schemi è mostrato in Figura 2.6 in cui sono mostrati lo schema a stella e lo schema a fiocco di neve relativi al modello multidimensionale il cui modello concettuale è mostrato in Figura 2.5. Modelli HOLAP Il modello HOLAP (Hybrid OLAP) traduce il modello multidimen- sionale in modo ibrido, solitamente utilizzando un database relazionale per il Data Ware- house, limitando l’occupazione di spazio e permettendo l’interazione con strumenti cono- sciuti. I database multidimensionali sono invece usati per i data mart tematici, in cui le dimensioni sono comunque limitate per la loro natura, ma che hanno in questo modo il vantaggio di interrogazioni più efficienti. 2.1.4 Operazioni sul Data Warehouse Il Data Warehousing comprende, oltre ad un modello dei dati direzionali, anche un insie- me di tecniche che possono essere utilizzate per analizzare i dati. Queste tecniche devono permettere ad utenti anche poco esperti di interagire con l’ipercubo dei fatti per ottenere informazioni più o meno dettagliate sulla base delle esigenze, focalizzandosi sulle dimen- sioni di interesse. L’interazione parte solitamente da un’ipotesi formulata da un utente che porta all’estrazione del sottoinsieme dei dati di interesse che può essere approfondi- ta con interazioni successive. Ogni interazione consiste nell’applicazione di un operatore OLAP. I principali operatori OLAP sono: drill down, roll up, slice e dice. Il drill down è l’operazione che permette di ottenere dati più dettagliati scendendo lungo una gerarchia di una dimensione e quindi passando da un livello di aggregazione più alto ad uno più basso. Considerando il DFM di Figura 2.5, ad esempio un’operazione di drill down potrebbe far passare da un’analisi delle vendite per trimestre ad un’analisi per singolo giorno (v. Figura 2.7). L’operazione opposta al drill down è quella di roll up, in cui il livello di dettaglio si riduce passando ad un livello di granularità minore lungo una dimensione di analisi. Un esempio può essere quello di passare da un analisi mensile delle vendite ad una annuale in cui i valori per mese sono aggregati insieme. Oppure una operazione di roll up si può effettuare eliminando una dimensione di analisi 24  Prod.6 Prod.5 Prodotto Roll-up Giorno->Trimestre Prod.4 Prod.3 Prod.2 4Q 2017 3Q 2017 Prod.1 2Q 2017 Trimestre 1Q 2017 Negozio1 Negozio3 Negozio5 Negozio2 Negozio4 Negozio6 Punto Vendita Prod.6 Prod.5 Prodotto Prod.4 Drill-down Prod.3 Trimestre-giorno Prod.2 06/03/2017 05/03/2017 04/03/2017 03/03/2017 Prod.1 02/03/2017 Data 01/03/2017 Negozio1 Negozio3 Negozio5 Negozio2 Negozio4 Negozio6 Punto Vendita Figura 2.7: Esempio di roll-up e drill-down con aggregazione/disaggregazione su dimensione Data che non risulta più rilevante. Ad esempio dall’analisi mensile delle vendite posso togliere la dimensione punto vendita e aggregare in base a valori uguali delle altre dimensioni (v. Figura 2.8). L’operatore slice permette di focalizzare l’analisi su una porzione dei dati fissando il valore per una delle dimensioni di analisi. Ad esempio è possibile focalizzarsi sulle vendite relative ad un singolo punto vendita, mantenendo però tutti i dettagli relativi alle altre dimensioni di analisi. Il risultato di questa operazione è una fetta dell’ipercubo originale, identificata dalla dimensione fissata (v. Figura 2.9). Si noti che contrariamente al roll-up presentato precedentemente lo slice seleziona un singolo negozio e non aggrega rispetto al negozio. Un’altra operazione di riduzione è quella di dice in cui però ad essere identificare sono un insieme di coordinate a qualsiasi livello gerarchico per qualsiasi dimensione desiderata. Il risultato in questo caso è sempre un ipercubo ma con un insieme ridotto dei dati. Ad esempio è possibile analizzare i dati delle vendite relativi a un prodotti (e.g., prodotto1) in un determinato punto vendita (e.g., negozio1). 2.1.5 Ciclo di vita del Data Warehouse La costruzione del DW, soprattutto quando le fonti dati sono numerose e popolose, può essere una attività complessa. Pertanto, si è soliti seguire un approccio iterativo: si parte identificando il fatto di maggiore interesse e si modella e popola quindi il primo ipercubo; successivamente, uno alla volta, altri ipercubi di interesse vengono progettati, aggiunti e a loro volta popolati. Questo approccio ha un duplice vantaggio: da una parte rende possibile individuare i fatti di interesse in momenti successivi, rispondendo a nuove esigenze dell’organizzazione; d’altro canto limita l’investimento iniziale sviluppando la base di dati multidimensionale un pezzo alla volta. Oltre al popolamento iniziale, che si sviluppa nell’esecuzione del processo ETL descritto in precedenza, è importante considerare anche le problematiche relative all’aggiornamento 25  Prod.6 Prod.5 Prodotto Roll-up Rimozione Prod.4 dimensione Punto vendita Prod.3 Prod.2 06/03/2017 05/03/2017 04/03/2017 03/03/2017 Data Prod.1 02/03/2017 01/03/2017 Prod.6 Prod.5 Prodotto Prod.4 Drill-down Prod.3 Aggiunta dimensione Prod.2 Punto Vendita 06/03/2017 05/03/2017 04/03/2017 03/03/2017 Prod.1 02/03/2017 Data 01/03/2017 Negozio1 Negozio3 Negozio5 Negozio2 Negozio4 Negozio6 Punto Vendita Figura 2.8: Esempio di roll-up e drill-down con eliminazione di dimensione Punto vendita dei dati che può riguardare i fatti o le dimensioni. Aggiornare un fatto significa inserire un valore non esistente per una combinazione di dimensioni, o modificare un valore esi- stente aggiornandolo. Aggiornare una dimensione può invece portare ad una situazione di inconsistenza. Ad esempio, se la dimensione indirizzo per un cliente varia nel tempo, sarà necessario prendere una delle seguenti decisioni: (1) aggiornare il valore indirizzo anche per i fatti pre-esistenti in modo che un cliente sia sempre associato allo stesso indirizzo; (2) mantenere valido il valore precedente senza eseguire nessun aggiornamento; (3) adot- tare una soluzione ibrida in cui si conserva traccia dei diversi indirizzi relativi al cliente relazionati ai relativi intervalli temporali. L’ultima soluzione è quella più complessa da gestire. Il ciclo di vita di un data warehouse mette in luce anche i suoi limiti. Infatti, è importante sottolineare come il processo ETL possa richiedere, per la sua esecuzione, anche diverso tempo. Non è infatti da considerarsi un’attività necessariamente automatica. Specie nella fase di trasformazione, dove è necessario risolvere alcune discordanze tra dati provenienti da fonti diverse, potrebbe rendersi necessario anche l’intervento umano. Pertanto, non solo la creazione di un data warehouse è un’operazione onerosa, ma anche il suo mantenimento e il continuo aggiornamento dei dati richiede un discreto sforzo. Questa complessità produce, come effetto, un aumento della distanza tra l’aggiornamento dei dati nei data base sorgenti - che avviene molto di frequente - e il momento in cui questi aggiornamenti sono visibili in un data warehouse. Per ridurre questa distanza, negli ultimi anni, sono stati proposti approcci alternativi ai data warehouse che spesso sfruttano algoritmi e tecniche proprie dei big data che, pur non richiedendo una fase di progettazione così dettagliata come nel caso del data warehouse, sono in grado di produrre risultati di analisi in tempo reale, spesso sfruttando data storage in-memory. 26  Prod.6 Slice Prod.5 Prodotto Filtro su Punto Vendita Prod.4 Prod.3 Prod.6 Prod.2 06/03/2017 05/03/2017 04/03/2017 Prod.5 Prod.1 03/03/2017 Data 02/03/2017 Prodotto 01/03/2017 Negozio1 Prod.4 Punto Vendita Prod.3 (Filtro = Negozio1) Prod.2 06/03/2017 05/03/2017 04/03/2017 03/03/2017 Prod.1 02/03/2017 Data 01/03/2017 Negozio1 Negozio3 Negozio5 Negozio2 Negozio4 Negozio6 (filtro = Prod 1) Punto Vendita 06/03/2017 Prodotto 05/03/2017 04/03/2017 Prod.1 03/03/2017 Data 02/03/2017 01/03/2017 Dice Negozio1 Filtro su Punto