Database e Business IntelligenceProgetto

Matteo Pozzani

126118

m.phobos@gmail.com

Alessandro Trentin

126134

ale.trentin@gmail.com

6 febbraio 2009

Sommario

Il progetto e stato realizzato come elaborato finale per il corso di Database e Business

Intelligence. In questo elaborato ci occupiamo di analizzare il conceptual model prodotto dal

COMPAS Consortium, al fine di realizzare un data warehouse e di fornire uno o piu strumenti

software che ne permettano la consultazione e la navigazione dinamica. Come prima fase,

ci occuperemo dell’analisi dell’ambito operativo del COMPAS Consortium, ed in particolare

del modello concettuale che lo rappresenta. Successivamente, collaborando con lo staff del

consorzio, provvederemo alla costruzione di un data warehouse che rispecchi il piu fedelmente

possibile il modello analizzato. Al termine dell’analisi del data warehouse, ci occuperemo

dell’analisi di alcuni strumenti software che permettono la navigazione grafica di una base di

dati. Infine provvederemo alla progettazione di un’applicazione che, utilizzando uno o piu

degli strumenti precedentemente valutati, permetta di navigare a piu livelli il contenuto del

data warehouse da noi progettato.

1

Indice

1 Introduzione 5

2 Contesto 6

2.1 COMPAS consortium[Com(2008)] . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3 Requisiti 8

3.1 Requisiti funzionali e non funzionali . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.2 I fatti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.3 Il carico di lavoro preliminare . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4 Progettazione concettuale 11

4.1 Conceptual model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4.1.1 Loan process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.1.2 Credit check fragment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.2 Entity Relationship Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.3 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.4 Attributes tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.5 Dimensional Fact Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5 Progettazione Logica 25

5.1 Data warehouse schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.2 Dimension tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

6 Progettazione dell’alimentazione 30

6.1 Caricamento dati database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

6.2 ETL data warehouse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

6.3 Strumenti utilizzati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

6.3.1 Microsoft SQL Server Integration Services . . . . . . . . . . . . . . . . . 33

6.3.2 Microsoft SQL Server Analysis Services . . . . . . . . . . . . . . . . . . 34

2

7 Tools Grafici 35

7.1 DOTNET Charting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

7.2 iDashboards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

7.3 Open Flash Charts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

7.4 Dundas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

7.5 Tool sviluppato . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

7.5.1 Un esempio d’utilizzo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

8 Future Works 46

8.1 Le marche temporali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

8.2 BusinessEvent e BusinessData . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

8.3 Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Elenco delle figure

1 SOA diagram[SOA(2008)] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 COMPAS lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3 COMPAS conceptual model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4 Loan BP process object diagram [Consortium(2008b)] . . . . . . . . . . . . . . . 13

5 Credit check BP fragment object diagram [Consortium(2008a)] . . . . . . . . . . . 14

6 Entity Relationship model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

7 Fact identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

8 Database Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

9 Attributes tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

10 Cleaned attributes tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

11 Dimensional Fact model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

12 Star schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

13 Snowflake schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

14 Data Warehouse schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3

15 Business Execution DB view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

16 Surrogate Key temp table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

17 Business Execution View joined to Surrogate Key temp table . . . . . . . . . . . . 32

18 Charting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

19 Compas Graphics Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

20 Business Subject con suddivisione per anno delle violazioni . . . . . . . . . . . . . 40

21 Suddivisione delle violazioni per Role ed Employee . . . . . . . . . . . . . . . . . 41

22 Gauge per il totale delle violazioni visualizzate . . . . . . . . . . . . . . . . . . . 42

23 Drill down dell’anno 2007 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

24 Drill down dell’anno 2007, per una particolare Business Subject . . . . . . . . . . 44

25 Drill down dell’anno 2007, per una particolare Business Subject e una particolarePolicy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Elenco delle tabelle

4

1 Introduzione

L’obiettivo principale di questo progetto riguarda l’analisi di un data warehouse e la valutazione,attraverso l’utilizzo di una serie di tool grafici, dei dati in esso contenuti.Tuttavia, un potenziale problema potrebbe essere dato dal poco tempo trascorso dall’inizio del pro-getto COMPAS, sul quale ci si basa per l’ottenimento della base di dati. Ci troviamo infatti in unafase preliminare del progetto, dove all’interno del COMPAS Consortium stesso si sta cercando didefinire e progettare tutto quanto concerne il Conceptual Data Model.Il nostro lavoro prevedera quindi in input di tale modello e, tramite conseguente traduzione in sche-mi Entita-Relazione, dovra produrre la base necessaria per la costruzione di un modello concettualegrafico rivolto alla modellazione di un data warehouse. Il data warehouse (letteralmente, magaz-zino di dati) e una base di dati eterogenea che non sostituisce quelle esistenti, ma che ha lo scopoprimario di integrare i dati provenienti dalle diverse sorgenti esistenti. Esso permette di separarel’elaborazione di tipo analitico (OLAP - On-Line Analytical Processing) da quella transazionale(OLTP - On-Line Transactional Processing), costruendo un nuovo raccoglitore di informazioni cheintegra i dati elementari provenienti da sorgenti di varia natura, li organizza in una forma appro-priata e li rende quindi disponibili per l’analisi e la valutazione[Giorgini(2008a)].Dal momento che il data warehouse, a differenza dei database management system relazionali, per-mette analisi multidimensionali dei dati, una volta compreso il modello concettuale ci si concentrasulla rappresentazione della realta di interesse in maniera formale e completa, ma indipendentedal DBMS utilizzato. A questo scopo, a partire dal Conceptual Data Model e dall’E-R diagram

effettueremo la progettazione concettuale, che permettera di rappresentare tutti i concetti utili allamodellazione del data warehouse.In particolare, realizzeremo il Dimensional Fact Model (DFM), che si concentra sull’identificazio-ne di tutti i concetti di interesse per il progetto, definiti fatti. Oltre ai fatti, andranno definite anchele misure, ossia le proprieta numeriche che descrivono aspetti quantitativi dei fatti, le dimensioni,che rappresentano le coordinate di analisi di ciascun fatto, e infine le gerarchie, raffiguranti glialberi degli attributi direzionali dei fatti di interesse.La fase successiva consiste nella popolazione della base di dati, per la quale verranno probabil-mente utilizzati dei dati fittizi, data la mancanza di dati reali dovuti alla condizione iniziale delprogetto COMPAS. Si prevede dunque un processo ETL (Extraction, Transformation, Loading),che consiste nell’estrazione dei dati dalle sorgenti di dati eterogenee, nella loro trasformazione estandardizzazione, e nel caricamento all’interno del data warehouse, rendendoli utilizzabili per lesuccessive analisi multidimensionali.La parte finale del progetto prevede la realizzazione di strumenti software che permettono, trami-te l’ausilio di diversi tools per la visualizzazione grafica dei dati, l’analisi sul contenuto del datawarehouse, e di fornire anche feedback sulle caratteristiche della strumentazione utilizzata.

5

2 Contesto

E’ sempre piu frequente, nell’ambito dei sistemi IT, la fornitura di prestazioni in termini di soluzio-ni composte da servizi. Una delle maggiori applicazioni di tali servizi trova riscontro nel Service

Oriented Computing (SOC), un computing paradigm relativamente recente che li utilizza comebase per lo sviluppo di grandi applicazioni distribuite, secondo specifiche architetture definite Soft-

ware Oriented Architectures (SOA).

Figura 1: SOA diagram[SOA(2008)]

Uno dei maggiori problemi dell’attuale sviluppo di SOAs[SOA(2008)], tuttavia, riguarda le diverseproblematiche di conformita che si devono affrontare durante tutte le fasi di sviluppo ed implemen-tazione, e la mancanza da parte dell’approccio SOA di strategie chiare per una corretta gestione ditali problemi durante l’intero ciclo di vita del progetto.Le conformita a cui si fa riferimento possono riguardare teoricamente ogni singola regola appli-cata ad ogni business process, sia esso trasversale oppure interno all’organizzazione. Detto cio, laconformita puo essere richiesta ad esempio nei confronti di service composition policies, servicedeployment policies, security policies, QoS policies, oppure di intellectual property e brevetti.Data l’eterogenea natura delle sorgenti di conformita, allo stato attuale non viene fornito un unicosoftware framework che permetta di mantenere l’intero sistema costantemente conforme a tutte leregole, perche per alcune di queste e difficile l’oggettiva identificazione di ogni singolo aspetto.

2.1 COMPAS consortium[Com(2008)]

In questo contesto trova collocazione il COMPAS consortium, i cui obiettivi riguardano la progetta-zione e l’implementazione di nuovi modelli e linguaggi, nonche di un architectural framework alloscopo di garantire alle aziende la possibilita di sviluppare business compliance solutions, utilizzan-do un unico insieme di strumenti di controllo per l’intero ciclo di vita del progetto. L’approccio uti-

6

lizzato e il model-driven software development (MSDS), che si avvale di linguaggi domain-specificper ridurre i tempi, i costi e le difficolta tecniche di realizzazione delle soluzioni, mantenendo ilpiu alto grado di conformita ad ogni aspetto regolativo considerato.

Figura 2: COMPAS lifecycle

Compito del progetto e quindi lo sviluppo di un design-for-compliance technology framework,che si occupa dell’estensione di linguaggi per la descrizione di business process, e dell’adozio-ne di nuovi specification models e languages per descrivere le conformita di cui tener conto. Ilframework assicurera inoltre lo sviluppo di business processes e servizi in grado di rispondereai requisiti del maggior numero di aspetti di conformita, e permettera di identificare compliancepolicies semplicemente utilizzabili contestualmente a tali processi e servizi.

7

3 Requisiti

Ogni progetto di sviluppo software ha come obiettivo principe la soddisfazione di richieste e biso-gni del committente. Tuttavia, la corretta definizione di tali richieste e uno dei punti cruciali per larealizzazione del prodotto finale, dal momento che un’errata comprensione delle aspettative e unadelle maggiori cause di fallimento nei progetti software. Per ridurre al minimo questo rischio, eutile formalizzare le richieste di chi commissiona il progetto e gli obiettivi dello stesso in elenco divoci, che prende il nome di documento dei requisiti.Tali requisiti possono sembrare astratti e intangibili, specialmente per gli sviluppatori di software,e la conseguenza di cio e l’accorpamento delle fasi di design e di raccolta dei requisiti. E’ invecefondamentale mantenere le due fasi separate: la documentazione dei requisiti e uno sforzo nellacomprensione del problema; il design del prodotto porta invece alla risoluzione del problema.

3.1 Requisiti funzionali e non funzionali

Come in ogni progetto software, possiamo distinguere all’interno della fase di raccolta e defini-zione dei requisiti due principali categorie: i requisiti funzionali, che rappresentano cio di cui gliutenti hanno bisogno affinche il sistema funzioni, ed i requisiti non funzionali, indicanti dei fattoriglobali che contribuiscono al successo generale del sistema.Di seguito verranno evidenziati, in maniera superficiale, alcuni dei requisiti fondamentali del pro-getto. Sara per l’appunto un’analisi di carattere generale, poiche, in fase di definizione del proble-ma, e stato deciso di utilizzare un approccio basato sulle sorgenti, e non sui requisiti, per quantoriguarda la definizione della progettazione concettuale. Cio significa che attraverso lo studio dischemi operazionali sara possibile derivare un prototipo di schema concettuale in modo pressocheautomatico.Tra i requisiti funzionali piu importanti citiamo:

• accesso tramite web browser, in modo da rendere utilizzabile l’applicazione dal maggiornumero di utenti, e senza che essi debbano installare alcun componente software sul propriocomputer;

• compatibilita multipiattaforma, e connesso con il requisito precedente, dal momento che siprevede di poter accedere allo strumento realizzato indipendentemente dal sistema operativoutilizzato;

• tempi di risposta ridotti tra la richiesta dell’utente e la risposta del sistema, per evitare lungheattese;

8

• flessibilita nel soddisfare le esigenze dell’utente in termini di analisi dei dati, permetten-dogli di creare le proprie queries secondo le proprie necessita, non vincolandolo a valoripredefiniti.

Per quanto concerne i requisiti non funzionali vanno menzionati:

• scalabilita, in modo da soddisfare le richieste di un numero crescente di utenti;

• usabilita, in termini di semplicita d’uso e di intuitivita nell’interazione con l’interfaccia dellostrumento;

• affidabilita, ossia assicurare un alto rate di successo nella soddisfazione delle richieste degliutenti;

• non ambiguita nell’interpretazione dei risultati mostrati;

• semplicita dell’interfaccia.

3.2 I fatti

Una volta definiti alcuni requisiti generali per il tool software di analisi dei dati, dobbiamo concen-trarci nello specifico sui bisogni degli utenti riguardanti il data warehouse che stiamo progettando.Per ottenere queste informazioni abbiamo avuto alcuni colloqui con i membri del COMPAS Con-sortium, dai quali sono emerse le linee generali che il nostro progetto deve seguire.Come gia riportato, lo scopo del progetto COMPAS stesso e il monitoraggio della compliancedelle attivita aziendali rispetto alle regole definite dall’azienda stessa, ma anche da altre sorgen-ti. Considerando quanto appena enunciato come obiettivo di alto livello, il nostro data mart devepermettere di identificare e monitorare i casi di non conformita, definiti come violazioni, le qualidevono poter essere successivamente analizzate dal tool grafico. Detto cio, nell’ottica di mapparequanto richiesto nel data warehouse, e possibile ipotizzare che l’unico fact candidate interessantein questo dominio sia appunto la violazione, dal momento che, considerando il livello di dettagliodesiderato dagli utenti, e l’unico concetto al quale si puo associare la caratteristica di dinamicitache ne renda in qualche modo utile un’analisi.Partendo quindi dall’unico ipotetico fatto identificato, sempre riferendoci alle necessita degli utiliz-zatori, e possibile dare una prima definizione di quelle che saranno le dimensioni ad esso associate,le quali saranno utili per la costruzione di pattern di aggregazione al fine di analizzare sotto diffe-renti punti di vista e a diversi livelli di dettaglio i dati puntuali contenuti nella base di dati utilizzatacome punto di partenza per la costruzione del data warehouse. Per il fatto violation, identifichiamo

9

come probabili dimensioni la Business execution e la Regola alla quale la violazione fa riferimen-to, nonche la data in cui questa viene riscontrata, per ottenere la possibilita di un’analisi storicadelle informazioni a disposizione.A questo livello preliminare, inoltre, possiamo dare una prima possibile definizione delle misu-re interessanti per l’aggregazione, anche se nelle successive fasi di progettazione tale definizione,scendendo nel dettaglio del dominio oggetto di analisi, potrebbe anche non trovare ulteriori riscon-tri. Secondo noi, nel particolare caso del fatto violazione, non vengono considerate misure, percheil verificarsi del fatto stesso coincide con una misura, dal momento che l’interesse degli utenti ela quantita di violazioni riscontrate, ad esempio, per una determinata attivita riguardo una certaregola.

3.3 Il carico di lavoro preliminare

Il riconoscimento di fatti, dimensioni e misure e strettamente collegato all’identificazione di uncarico di lavoro preliminare[Golfarelli e Rizzi(2002)]. Nel nostro caso, data la specificita del do-minio, che porta all’analisi delle informazioni secondo pochi e semplici pattern di aggregazione,possiamo identificare alcuni pattern di default, che stabiliscono il diverso livello di dettaglio se-condo noi piu significativo associato alla gerarchia di ciascuna dimensione di aggregazione.Per la dimensione Date, pensiamo che un possibile pattern sia quello contenente gli attributi tem-porali Giorno, Mese e Anno, mentre consideriamo irrilevante ai fini dell’analisi l’aggregazione perl’ora in cui e avvenuta una violazione, considerando quindi l’attributo tempo come non dimensio-nale.La gerarchia legata alla dimensione Regola potrebbe permettere di aggregare secondo il patternRegola, Policy, Goal, Sorgente, Tipo di sorgente, al fine di ottenere un quadro sempre piu generaledelle violazioni riscontrate.Infine, contestualmente alla dimensione Business execution, potrebbe avere senso un aggregationpattern che generalizzi l’analisi tramite Business execution, Business subject, Tipo di business su-

bject, al fine di comprendere nel migliore dei modi quali sono le aree di business dell’aziendamaggiormente soggette a non conformita alle regole stabilite dalle policies.

10

4 Progettazione concettuale

L’Entity-Relationship model e il formalismo universalmente adottato per la progettazione di siste-mi informativi relazionali, ma questa metodologia non e sufficiente per la progettazione concettualedi un data warehouse, perche non si concentra sufficientemente sull’interazione dell’utente con labase di dati per l’indagine e la ricerca di informazioni.In questo progetto sara infatti adottato il DFM (Dimensional Fact Model), un modello concettualegrafico per data mart. Tale modello permette di supportare efficacemente il progetto concettuale,ma anche di creare un ambiente in cui e possibile formulare in modo intuitivo le interrogazionidell’utente.La base di partenza per la costruzione del DFM da utilizzare sara comunque un diagramma E-R,costruito a partire dal conceptual model fornitoci dal COMPAS consortium.

4.1 Conceptual model

In questa fase e preso in analisi il conceptual model del progetto COMPAS, che rappresentaschematicamente, attraverso notazione UML, il dominio in cui si andra ad operare.

0..N

Business

process

BP activity

Business

service

BP

fragment

Business

execution

Business

events

Violation Rule

Policy

Source

Goal

Regulation

QoS policy

Behavioral

composition

model

License

Subgoal

...

0..N

1..N

1..N

1..N

1..N 0..N

0..N

0..N0..N Process/service

composition

model

Security policy

Business

subject

0..N

0..N

Sub-subject

Business

data

0..N

Role

Employee

0..N 0..N

0..N 0..N

1..N

0..N

Figura 3: COMPAS conceptual model

Osservando il modello piu in dettaglio, forniamo ora una descrizione dei concetti che lo compon-gono.Secondo la nostra analisi, il punto di maggiore interesse per il COMPAS Consortium [Com(2008)]

11

e il Business subject, che identifica le attivita svolte dall’azienda allo scopo di realizzare i propriprodotti. Tali attivita devono essere oggetto di costantemente monitoraggio al fine di garantirne lacontinua compatibilita con le regole e specifiche definite dalle compliance rules.Il Business subject puo fare riferimento a diverse entita, che sono comunque legate alle attivitaaziendali. Questa caratteristica permette quindi di descrivere, e successivamente monitorare, l’o-perato dell’azienda su differenti livelli. Fanno riferimento al Business subject, quindi, Business

processes e services, ma anche sottoparti di questi, come BP activities e fragments.Una volta identificati i processi da prendere in considerazione, e dunque necessario comprendernele modalita di esecuzione, ossia Business execution, che permettono di ottenere un maggiore li-vello di dettaglio nella descrizione degli scenari di interesse, anche attraverso l’identificazione deisoggetti che le svolgono (Employee), e nella successiva valutazione.Un altro importante aspetto da considerare e la definizione delle Policies, ossia i regolamenti dautilizzare come base di valutazione per stabilire il grado di compliance delle attivita. Queste po-licies espongono regole precise, identificate dal concetto Rule, che fanno riferimento a sorgentilegislative eterogenee di natura interna ed esterna all’azienda stessa, quali ad esempio QoS poli-cies, security policies, brevetti e licenze o behavioral composition models.Risulta naturale la necessita di evidenziare il livello di agreement delle attivita aziendali con lepolicies definite al fine di poter agire tempestivamente e puntualmente in caso di violazioni. Aquesto proposito, quindi, nel modello concettuale assume un ruolo di primaria importanza il con-cetto di Violation, che identifica con precisione le incompatibilita delle attivita con le regole chele governano. Per meglio comprendere quanto appena descritto, riportiamo di seguito due esempiin cui il modello concettuale viene applicato ad uno specifico contesto pratico. In particolare, sifa riferimento ad un business processes aziendale e ad una sua parte specifica, e si evidenziano lepossibili violazioni alle regole per essi definite.

4.1.1 Loan process

Rappresentiamo ora lo schema concettuale del Loan Process, cioe il processo di valutazione econcessione di credito.In questo caso, tutto il processo di concessione di un prestito e affidato ad un solo employee, e taleprassi genera delle eccezioni sulle policy applicate.In particolare, si evidenzia la necessita della suddivisione dei ruoli in tale processo, accorgimentoda mettere in atto al fine di soddisfare il principio di design per l’information protection, ma ancheper prevenire errori o potenziali problemi dovute all’accentramento di responsabilita in un solosoggetto.

12

Figura 4: Loan BP process object diagram [Consortium(2008b)]

4.1.2 Credit check fragment

In questo esempio, ci si concentra su una parte di quanto appena illustrato, e si descrive una pro-cedura di assegnazione di credito.Lo scenario prevede due employees, David e James. James e il supervisore di David, e ha il com-pito di controllare che l’operazione sia redditizia e il rischio basso, e quindi autorizzarla, se larichiesta riguarda cifre superiori ad 1 milione di euro. Altrimenti, e sufficiente il controllo e l’e-ventuale approvazione di David.Nel diagramma sono evidenziate, oltre al processo appena descritto, anche le possibili violazionialle regole stabilite dalla Profitable operation and risk mitigation policy.

4.2 Entity Relationship Model

Una volta descritti i concetti inerenti il dominio del progetto, viene proposta in figura 6 una rappre-sentazione del modello relazionale, in cui sono individuate le entita e le relazioni che descrivono ildominio di interesse [Giorgini(2008b)].

La rappresentazione relazionale rispecchia generalmente quanto raffigurato in fig. 3, anche se sonostate operate alcune scelte progettuali nell’ottica di semplificare il modello concettuale, per potercimeglio concentrare sullo scopo primario del progetto.

13

Figura 5: Credit check BP fragment object diagram [Consortium(2008a)]

In primo luogo, abbiamo deciso di raggruppare alcune entita per semplificarne la gestione nelle fasisuccessive del progetto, dato che anche ai fini dell’analisi che andremo a compiere non ricopronoruoli di primaria importanza. In particolare, abbiamo considerato le entita Business process, BP

Fragment, BP Activity e Business Service come tipologie di Business Subject, e quindi le abbiamocodificate in fig. 6 con l’entita Type of Business Subject, alla quale sono associati come attributiun identificatore e una descrizione.Lo stesso principio e stato adottato per le diverse sorgenti di riferimento dei goals, le quali sonostate raggruppate nell’entita Source, che ha come attributo una descrizione testuale, e viene iden-tificata da una chiave primaria, composta da un idenficatore interno associato a quello dell’entitaType of source, utilizzata per descrivere le diverse tipologie di sorgenti a disposizione.Nella nostra rappresentazione abbiamo inoltre trattato le date come entita, invece che come sem-plici attributi, per cercare di fornire una struttura uniforme ad un tipo di dato generalmente moltocomplesso da gestire. A questa entita, poi, oltre ad un identificatore univoco, sono stati associatigli attributi che ne descrivono la componente giorno e quelli per la componenteora, i quali potran-no essere utilizzati in fase di aggregazione ed analisi dei dati. Questo ha portato ad identificareuna particolare relazione 1-a-2 Start/End tra Business execution e Date, dal momento che ad ogniBusiness execution sono associate una data di inizio e una di fine dell’attivita.A differenza di quanto riportato nel modello concettuale, inoltre, abbiamo ritenuto utile l’inseri-mento della relazione domain tra le entita Business subject e Policy, in quanto potrebbe permetteredi avere una visione d’insieme piu generale, e non solamente inerente le violazioni commesse dalleBusiness execution sulle singole regole. Questa modifica, comunque, e riferita solamente al dia-gramma E-R, e non viene utilizzata ulteriormente, perche il nostro progetto prevede l’analisi delle

14

Figura 6: Entity Relationship model

15

violazioni, e non delle performance generali di compliance delle attivita aziendali.Abbiamo infine considerato la Violation come una relazione tra Business execution, Date e Rule,e non come un’entita a se stante. Questa scelta ci ha permesso di individuare in questa relazione ilpunto di partenza per la costruzione del Data Warehouse da utilizzare come supporto tecnologicoper l’analisi dei dati, identificando nella Violation il fatto principale del Dimensional Fact Model

associato al nostro scenario.

Figura 7: Fact identification

Avendo definito la rappresentazione relazionale del dominio, dobbiamo ora considerare che i fatti

corrispondono tipicamente ad eventi che accadono dinamicamente all’interno dello scenario og-getto di analisi; possiamo quindi individuare nelle entita o relazioni che rappresentano archivifrequentemente modificati dei buoni candidati per la definizione di fatti [Giorgini(2008c)].Nel nostro caso, l’unica relazione che ha natura dinamica e la Violation, percio la possiamo consi-derare come candidata a ricoprire il ruolo di fact nel DFM che andremo a realizzare. Non riteniamodi dover identificare alcun ulteriore fatto, perche le altre relazioni non sono sufficientemente dina-miche da essere considerate come fatti. Detto cio, esplodiamo la relazione di violazione, comevisualizzato in fig. 7, e scendiamo in dettaglio per meglio comprendere la composizione delle en-tita e degli attributi coinvolti nel fatto principale.E’ stato assegnato a Violation un identificatore composto dalle chiavi primarie di Business execu-

tion, Rule e Date, in modo da prevedere anche la possibilita di gestire violazioni multiple della

16

stessa regola da parte della stessa business execution.Come discusso precedentemente, le date non sono state considerate come attributi, ma come entita,e in questo diagramma vengono chiaramente esposte le relazioni che legano sia Business execu-tion che Violation con Date, le quali ci permetteranno di utilizzare la data come dimensione diaggregazione ed analisi dei dati.

4.3 Database

Coerentemente con il processo di progettazione e sviluppo di un data warehouse, il diagrammaEntity-Relationship dovrebbe servire anche come rappresentazione del database relazionale da uti-lizzare come sorgente di dati per il data warehousing. Nel nostro caso, invece, tale diagramma estato utilizzato come base per la realizzazione del database stesso, oltre che come punto di parten-za per la realizzazione del DFM. Tale particolarita ha portato, una volta sviluppato e popolato ilDB, ad alcune differenze nella progettazione dell’ER diagram e nella realizzazione del database,le quali si sono manifestate perche solo l’implementazione pratica ha reso chiare alcune esigenzedell’analisi dei dati.Osservando la figura 8, e dunque immediatamente possibile notare che la ragione principale diquanto appena descritto e dovuta alla presenza di relazioni molti-a-molti tra alcune tabelle, le qualiimpedivano, nell’implementazione originale del database, il legame diretto dei dati con la tabellaViolation, utile ai fini dell’analisi.Le modifiche effettuate, dunque, hanno avuto lo scopo di poter fornire ad ogni istanza della ta-bella Violation la totalita delle informazioni ad essa legate, fornendo tutti gli strumenti per unacorretta analisi dei dati in essa contenuti. In particolare, con riferimento alla fig. 8, si nota chele tabelle coinvolte in relazioni n-n, tali per cui una particolare violazione non ne e univocamentericonducibile ad una particolare istanza, sono 3:

• Source: la sorgente da cui vengono definiti i Goal che le policies andranno a soddisfare.Nella configurazione iniziale non e possibile sapere esattamente quale sorgente sia coinvoltain una singola violazione. L’implementazione di questo livello di informazione nel databaseha richiesto l’inserimento del campo Source ID nella tabella Violation;

• Employee: permette di conoscere l’identita della persona responsabile di una violazione,qualora la Business Execution preveda l’esecuzione di attivita da parte di un lavoratore.Questa relazione non e obbligatoria, perche alcune attivita possono essere senza interventoumano. Nella tabella Violation e stata aggiunta la colonna Employee ID;

• Role: dal momento che a ciascuna Business Subject possono essere associati da 0 a n ruoli,

17

pensiamo possa essere utile ai fini dell’analisi fornire una correlazione tra Violation e Role.Per questo abbiamo inserito nella tabella Violation la colonna Role ID.

Dato che la modifica al database si e ritenuta necessaria solo in fase di progettazione e alimen-tazione dello stesso, abbiamo ritenuto opportuno non modificare i grafici presenti nel documentorelativi al lavoro concettuale precedentemente svolto, ma piuttosto di evidenziare la dinamicitadella progettazione, mostrando come sia possibile dover modificare quanto e stato realizzato a li-vello teorico al fine di soddisfare esigenze identificate solamente durante l’implementazione verae propria del sistema.Un ulteriore precisazione va fatta relativamente alle tabelle Business Event e Business Data, chesono da considerarsi come specializzazioni di Business Execution. Pur avendo implementato talitabelle all’interno del nostro database, abbiamo deciso di non considerarle nelle fasi successivedella progettazione del data warehouse, perche l’apporto informativo dei dati contenuti in tali ta-belle e sostanzialmente minimo, ed abbiamo preferito concentrarci su altri aspetti, quali ad esempiol’identificazione dei ruoli o degli employees che compiono le violazioni.

18

Figura 8: Database Diagram

19

4.4 Attributes tree

Una volta individuato il fact candidate, si procede alla conversione del diagramma E-R [Giorgini(2008c)]in un albero degli attributi, mostrato in fig. 9, la cui radice e l’identificatore del fatto, e fa corri-spondere ogni vertice ad un attributo (semplice o composto), dello schema sorgente.

Figura 9: Attributes tree

Dal momento che non tutti gli attributi identificati dall’albero saranno poi utili per l’analisi deidati, alla prima versione dell’albero vengono applicate alcune procedure con lo scopo di eliminarei livelli di dettaglio non necessari. Le due pratiche principali sono la potatura, che se applicata adun vertice dell’albero ne elimina tutto il sottoalbero che ha quel particolare vertice come radice, el’innesto, che permette di eliminare un vertice non utile, ma di mantenere le informazioni conte-

20

nute nei suoi discendenti.

Dopo aver applicato tali procedure, il risultato del nostro attributes tree e mostrato in fig. 10, nelquale sono comunque visibili le parti dell’albero ritenute non interessanti. In generale, l’approccio

Figura 10: Cleaned attributes tree

e stato quello di cercare di semplificare sottoalberi di attributi che potessero fornire un livello didettaglio troppo alto, oppure non utile. Ad esempio, sono stati rimossi gli attributi che facevanoriferimento a Business subject o Source, perche si e ritenuta piu utile al fine dell’analisi la presenzadi tali entita associate alla propria tipologia.Per quanto riguarda la dimensione data invece, negli alberi degli attributi e stato rappresentatoquello che nella nostra opinione puo essere l’aggregation path per l’analisi dei dati, anche se alcunidegli step di questo percorso (ad esempio il livello di aggregazione trimestrale) saranno calcolati,invece di essere salvati nel data warehouse come attributi, perche sono facilmente ottenibili dalle

21

informazioni originariamente contenute nel data mart.Infine, come e possibile notare dalle fig. 9 e 10, emerge che il fact candidate Violation sara vuoto,senza cioe alcuna measure. La ragione di questa scelta e da ricondurre alla natura stessa dellaviolazione di una regola da parte di un’attivita, che e binaria, nel senso che questa puo avvenire onon avvenire, e quindi l’unica informazione ottenibile da un data mart basato su quanto progettatoe la quantita di violazioni avvenute, la quale potra pero essere aggregata sulla base di tutte ledimensioni di aggregazione disponibili.I diagrammi mostrati in figg. 9 e 10 sono utilizzati anche per l’identificazione delle dimensions,le quali stabiliscono la granularita degli eventi primari. Nel nostro caso sono state identificate leseguenti tre dimensioni:

Business Execution che identifica il fenomeno oggetto di analisi, ossia le attivita di cui si vuolemonitorare la compliance rispetto alle regole definite nelle diverse policies. La gerarchia diaggregazione di questa dimensione permette di ottenere informazioni sulle violazioni com-messe da ogni business subject, ma anche di identificare gli eventuali soggetti responsabilidi tali violazioni.

Rule cioe il termine di confronto per le attivita svolte dall’azienda. Aggregando a partire daquesta dimensione e possibile inoltre verificare le violazioni sia in base alle policies definitedall’azienda che rispetto alle sorgenti da cui tali policies sono derivate.

Date che rappresenta la dimensione temporale necessaria all’analisi, dato che le attivita di cui cisi deve occupare sono dilazionate nel tempo. A partire da questa dimensione e stato definitol’aggregation path che permette di raggruppare i dati delle violazioni in intervalli temporalidi larghezza crescente.

Per quanto riguarda l’attributes tree, un’ulteriore precisazione da fare riguarda l’uso degli archi

opzionali, i quali identificano dimensioni le cui istanze non saranno obbligatoriamente presenti neldata mart. In particolare, abbiamo reputato come non obbligatorie due tipologie di violazioni lega-te alla Business subject e alla Business execution. La prima riguarda i legami tra Role e Businesssubject e tra Employee e Business execution, dal momento che, come emerso dai colloqui conil personale impegnato nel COMPAS Consortium, e possibile avere alcune attivita da monitorareche non richiedono interventi umani per essere compiute, ma che possono comunque dare origine aviolations. Fanno parte della seconda tipologia le relazioni tra Business Data e Business executione tra Business Event e Business execution, dal momento che si tratta di relazioni di specializza-zione della Business execution, e a tale entita non vanno necessariamente associati Business Datao Events.

22

4.5 Dimensional Fact Model

Una volta ottenuto l’albero degli attributi, lo step successivo della progettazione concettuale del si-stema e la realizzazione del Dimensional Fact Model, che permette la creazione di una piattaformastabile e non ambigua utile alle fasi successive del progetto [Golfarelli e Rizzi(2002)].Il DFM permette di identificare e descrivere i Facts che caratterizzeranno il data warehouse, maanche di individuare i percorsi di aggregazione piu efficaci in relazione alla natura dell’analisi. Peril nostro progetto, l’unico fact candidate a disposizione (Violation) e stato effetivamente tradottoin fatto, come mostrato in fig. 11, nella quale vengono anche fornite alcune informazioni supple-mentari rispetto a quanto gia stabilito dall’analisi degli attributes trees.In primo luogo, come anticipato nella spiegazione dell’attributes tree, il fact non contiene misure,percio l’aggregazione su ogni dimensione potra avvenire solamente tenendo conto del verificarsi omeno dell’evento. Questa caratteristica dello schema di fatto vuoto permette di definire:

Evento primario come rappresentazione del verificarsi dell’evento;

Evento Secondario come rappresentazione del numero di eventi primari ad esso corrispondenti,ottenuto tramite l’operatore COUNT.

Inoltre, nel DFM alcuni legami, in genere tra dimensioni, sono stati rappresentati con archi multi-pli. Questa notazione si e resa necessaria per identificare alcune associazioni -a-molti, che risulta-vano di difficile individuazione all’interno dell’attributes tree.Nel nostro diagramma, abbiamo fatto uso di archi multipli per specificare che ogni Goal puo es-sere identificato a partire da molteplici sorgenti, e per rendere chiaro che ad ogni Business subjectpossono essere associate diverse Business execution. Inoltre, a quest’ultima entita, possono essereconnessi molteplici Business data e Business event, oltre che Employee. Infine, l’arco multiploe risultato utile per stabilire la relazione di cardinalita n tra Business subject e Role.Una volta definito il DFM per il data warehouse, il paso successivo consiste nella progettazionelogica del data mart, che sara oggetto del prossimo capitolo, nel quale ci occuperemo di definire ilmodello della base di dati coerentemente con le esigenze di analisi.

23

Figura 11: Dimensional Fact model

24

5 Progettazione Logica

A differenza della progettazione concettuale, per quanto riguarda l’aspetto logico e molto stretta laconnessione con il modello scelto per l’implementazione del progetto. Per questo motivo a livellologico vanno ponderate diverse alternative, al fine di scegliere la migliore non solo in termini diprestazioni, ma anche tenendo presente la natura del sistema software a supporto del data ware-house nonche il carico di lavoro per esso ipotizzato. Nel nostro caso, infatti, il data warehousesara costruito avvalendosi di un Data Base Management System relazionale, al fine di rendere piusemplice l’interazione del tool grafico di analisi dei dati con il data mart.In generale, comunque, dovremo interagire con una struttura di dati multidimensionale, la qualepuo essere rappresentata utilizzando due distinti modelli logici[Giorgini(2008d)]:

MOLAP (Multidimensional On-Line Analytical Processing) nel quale i dati sono memorizzatiattraverso strutture intrinsecamente multidimensionali, come ad esempio i vettori multidi-mensionali. Sistemi di questo tipo rappresentano soluzioni capaci di ottime prestazioni, manon sono molto ulizzati per la mancanza di strumenti software standard, e anche per la dif-fusa conoscenza e l’ampio utilizzo dei sistemi relazionali. Va inoltre segnalato, nell’ambitodi sistemi MOLAP, il problema della sparsita, secondo cui solo una minima parte delle celledei cubi multidimensionali di analisi contengono effettivamente informazioni utili.

ROLAP (Relational On-Line Analytical Processing) che utilizza il modello relazionale per larappresentazione dei dati multidimensionali, la cui tecnologia e consolidata e ampiamenteutilizzata. Questo modello richiede una quantita elevata di risorse in termini di queries sullabase di dati, data la natura relazionale della stessa, ma offre nel contempo migliore scalabilitae piu semplice gestione del database utilizzato.

Nel nostro progetto ci avvarremo di modelli del secondo tipo, dal momento che meglio si adattanoall’infrastruttura software relazionale a nostra disposizione. Tali modelli ci permettono di tenereconto della scalabilita del sistema, ossia di utilizzare grandi quantita di dati senza apprezzabili per-dite di performance, ma anche di ridurre considerevolmente il problema della sparsita tipico deimodelli MOLAP. Abbiamo inoltre a disposizione uno strumento flessibile che fornisce supportoall’analisi delle informazioni utilizzando un elevato numero di dimensioni, senza avere la necessitadi reingegnerizzare il modello per adattarlo a nuove dimensioni. Oltre a cio, attraverso l’adozionedi modelli ROLAP possiamo avvalerci di SQL come strumento principale per l’interazione con labase di dati.Nell’ambito dei modelli OLAP relazionali, sono disponibili due possibili alternative, che si dif-ferenziano nella trattazione dell’implementazione all’interno della base di dati delle informazioniriguardanti le gerarchie di attributi legate alle dimensioni di analisi dei fatti di interesse.

25

Star schema che osservando la fig. 12 consiste operativamente nella relazione tra la fact table e ledimension tables, ciascuna delle quali contiene tutte le informazioni relative alla gerarchia adessa legata, presentando dunque dipendenze funzionali transitive al proprio interno. Infattil’architettura dello schema a stella risulta essere la piu semplice quando si vuole disegnareuna base di dati[Golfarelli e Rizzi(2002)]. In dettaglio:

• fatti: indicatori numerici aggregabili, quali per esempio le vendite od altre quantitanumeriche sommabili; la tabella dei fatti e altamente normalizzata.

• dimensioni: attributi verso i quali si analizzano i fatti (quali, ad esempio, i clienti, imateriali, il tempo); in questo caso le varie tabelle sono denormalizzate.

Uno schema a stella e caratterizzato dalla presenza di una sola tabella dei fatti e da un numerovariabile di tabelle delle dimensioni tutte direttamente legate alla prima. Le peculiari- ta diquesto approccio sono:

• De-normalizzazione: questo conferisce al sistema prestazioni notevolmente superiori,soprattutto se la mole di dati da analizzare e molto elevata;

• Concentrazione: tutte le informazioni oggetto dell’indagine sono concentrate in un’u-nica struttura: la tabella dei fatti;

• Granularita: la tabella dei fatti riporta le informazioni di dettaglio e non presenta alcuntipo di aggregazione.

La soluzione basata su uno schema a stella presenta alcuni limiti di cui e bene tener conto.Come abbiamo evidenziato, infatti, le informazioni sono qui presenti nella loro forma ele-mentare. Questo significa che, se lo scopo della base dati e fornire aggregazioni che possonoessere prestabilite, per ogni richiesta sara necessario operare estrazioni molto onerose.

Snowflake schema che, come rappresentato in fig. 13, puo essere considerato come una formaparticolare dello star schema, caratterizzato pero dalla normalizzazione delle dimension ta-bles. E’ infatti possibile ottenere uno snowflake schema a partire da uno star procedendoalla graduale eliminazione delle dipendenze funzionali transitive presenti nelle dimensiontables[Golfarelli e Rizzi(2002)]. La soluzione che sfrutta uno schema a fiocco di neve, quin-di, e caratterizzata dal fatto che puo utilizzare direttamente lo schema del database che pro-duce le informazioni. In questo caso le tabelle coinvolte sono quasi sempre ben normalizzatee si presentano in una forma che e tipica dei database transazionali. Questa soluzione e daconsigliare solo nei casi in cui la mole di dati da trattare sia esigua. Se i dati fossero mol-ti, infatti, la complessita delle join che si rendono necessarie comporterebbe tempi di attesainaccettabili. La soluzione a fiocco di neve puo essere necessaria se le informazioni chesi vogliono estrarre devono assolutamente essere allineate con quelle del momento e non eaccettabile un ritardo di un giorno o di qualche ora.

26

Figura 12: Star schema

Figura 13: Snowflake schema

27

5.1 Data warehouse schema

Una volta analizzate le alternative teoriche e considerata la non eccessiva complessita del nostrosistema, abbiamo scelto di implementare il data warehouse seguendo uno star schema. Questascelta e motivata anche dalla presenza di un solo fact candidate, e dalla necessita di relazionaredirettamente ogni attributo di ogni dimensione alla fact table. La nostra proposta per lo schema deldata warehouse e rappresentata in figura 14.

Figura 14: Data Warehouse schema

Come si nota, a differenza dello schema del DB in figura 8, nella tabella Violation sono riportatesolamente le chiavi che identificano gli attributi primari delle diverse dimension tables. Questo estato possibile grazie alle modifiche apportate in corso d’opera allo schema del data base, le qualihanno permesso di costruire delle semplici dimension tables in grado di contenere tutti gli attribu-ti necessari, senza avvalerci di bridge tables o ulteriori chiavi esterne da inserire nella fact table[Golfarelli e Rizzi(2002)]. La scelta dello star schema ci permette anche di diminuire il carico dilavoro richiesto per le interrogazioni del data warehouse, perche si minimizzano le operazioni dijoin tra tabelle per ottenere le informazioni.

28

5.2 Dimension tables

Osservando la figura 14, si vede che per ogni gerarchia viene creata una dimension table che necontiene tutti gli attributi, i quali saranno accessibili tramite queries SQL al fine di fornire i diversilivelli di aggregazione dei dati in fase di analisi. Come conseguenza allo sviluppo e all’imple-mentazione della tabella Violation, abbiamo sviluppato la tabella riferita alla dimensione Busines-

sExecution. La sezione relativa alla definizione dello schema del data warehouse ci ha permessodi individuare alcune modifiche riguardanti la dimensione BusinessExecution: infatti, sono pre-senti i riferimenti alle tabelle Employee e Role, necessarie per poter sviluppare un’analisi correttae strutturata della base di dati. In questa maniera sara possibile ovviare alla particolare strutturadelle relazioni di tipo molti-a-molti, nelle quali risulta difficile l’analisi e lo studio dei dati, elimi-nando di fatto le tabelle RoleBusinessSubject ed BusinessExecutionEmployee introducendo, comeattributi di dimensione, i relativi riferimenti all’interno di BusinessExecution. Un ulteriore aspettodi notevole importanza che ci ha convinti ad effettuare questa operazione, e stata la possibilita dieliminare alcune ridondanze presenti nei dati. Inoltre i riferimenti alle tabelle BusinessData e Bu-

sinessEvent sono stati tralasciati, sia per una questione di semplicita, visto che anche questi valorihanno la caratteristica di poter assumere valore NULL, e sia in relazione alla loro natura di tabel-la specializzante rispetto a BusinessExecution. L’ultima operazione di modifica all’interno delladimensione BusinessExecution riguardano i campi StartingDate e EndingDate; per semplicita ven-gono da noi considerati come attributi semplici, poiche secondo la nostra analisi questi 2 campirappresentano semplicemente delle informazioni di carattere descrittive. La stessa metodologia estata utilizzata anche per la modellazione della dimensione Rule, nella quale sono stati aggiunti iriferimenti alle tabelle Goal, Source e TypeOfSource. In questo modo, l’accesso ai dati e quindi leinterrogazioni SQL che saranno successivamente sviluppate all’interno del codice per la creazioneed utilizzo dei tool grafici, risulteranno di complessita inferiore. Il terzo vertice del nostro schemaa stella e rappresentato dalla dimensione Date. Secondo la letteratura[Golfarelli e Rizzi(2002)],i riferimenti alle date vengono sviluppati all’interno di una tabella a se stante, in modo tale dapoter implementare e quindi modellare a piacimento la gerarchia presente all’interno della stessa,e quindi ottenere, per quanto riguarda lo sviluppo del tool grafico, viste particolari da utilizzarecome opzioni di navigazione.

29

6 Progettazione dell’alimentazione

Una volta completata la progettazione e l’implementazione della struttura del data warehouse, sie resa necessaria la progettazione delle procedure di extraction, transformation, loading (ETL).Durante questa fase vengono definite le procedure necessarie a caricare all’interno del data mart idati provenienti dalle sorgenti operazionali [Golfarelli e Rizzi(2002)].Nel nostro caso, non siamo in presenza di un vero e proprio livello riconciliato, dove cioe tutti idati delle diverse sorgenti sono puliti e normalizzati. Essendo nostro compito la progettazione deldatabase sorgente e il caricamento di dati al suo interno, abbiamo potuto utilizzare formati standardper dati numerici e relativi a date, oltre che strumenti e procedure utili a semplificare l’utilizzo ditali dati nelle fasi di estrazione e caricamento del data warehouse, riducendo al minimo le trasfor-mazioni necessarie per poter utilizzare correttamente i dati ottenuti dalle sorgenti a disposizione.In particolare, quindi, per il nostro progetto l’alimentazione puo essere suddivisa in due fasi,relative rispettivamente al database sorgente e al data warehouse.

6.1 Caricamento dati database

Come gia anticipato, una volta implementata la struttura del database sul DBMS (nel nostro caso sie optato per Microsoft SQL Server 2005), il nostro compito e stato quello di creare, in quasi totaleassenza di dati reali, una base di dati verosimile per da poter utilizzare poi nel successivo processodi ETL per il data warehouse.Per popolare il nostro database, ci siamo avvalsi di un database di test fornitoci da COMPASConsortium, in cui erano presenti i dati di alcune violazioni relative ad un particolare documento(Sarbanese Oxley Act), ma anche di altri dati fittizi. In particolare, abbiamo fatto uso di foglidi calcolo per effettuare le trasformazioni necessarie al caricamento dei dati COMPAS nel nostrodatabase, e per generare automaticamente i dati fittizi di cui avevamo bisogno.

6.2 ETL data warehouse

Una volta costruita la sorgente dati, abbiamo progettato e realizzato le procedure per conformarei dati allo schema a stella utilizzato nel data warehouse. In generale, dato che ci siamo occupatianche della progettazione e realizzazione della sorgente, tali procedure non si sono rivelate troppocomplesse, ma ci e stato richiesto uno sforzo minimo per caricare i dati nel data warehouse.Le trasformazioni che si sono rivelate indispensabili hanno riguardato soltanto relative la creazio-ne di surrogate keys, al fine di identificare univocamente ciascuna istanza delle dimension tablesutilizzate. Le modifiche effettuate in sede di progettazione del database, poi, hanno permesso di

30

mantenere il piu alto livello di linearita nel data warehouse, rendendo necessaria, per ciascunadelle tabelle DimRule e DimBusinessExecution, l’identificazione di una sola chiave surrogata chepermette di identificarne univocamente ciascuna tupla di valori inseriti. La procedura di creazionedelle surrogate keys si e sviluppata in tre fasi:

1. creazione database view (fig.15): abbiamo creato alcune views nel database sorgente, avva-lendoci di alcune operazioni di join, per visualizzare tutte le chiavi relative ad una particolaregerarchia;

Figura 15: Business Execution DB view

2. creazione surrogate key (fig.16): utilizzando Microsoft SQL Server Integration Services(SSIS) sono state create delle procedure per la creazione di tabelle fittizie, nelle quali sie associata una chiave automatica all’elenco di chiavi identificanti una particolare istanzadella gerarchia di interesse;

3. caricamento dati nella dimension table (fig.17): utilizzando una operazione di join tra laview e la tabella contenente le surrogate keys, abbiamo realizzato la tabella sorgente da cuipopolare, avvalendoci ancora di SSIS, le dimension tables e la fact table del data warehouse.

La stessa metodologia e stata utilizzata per la composizione della gerarchia DimRule, mentre in-vece abbiamo proceduto in maniera diversa per le fasi di transformation e loading riguardanti la

31

Figura 16: Surrogate Key temp table

Figura 17: Business Execution View joined to Surrogate Key temp table

32

tabella DimDate. In questo contesto, infatti, ci siamo avvalsi direttamente del campo Date presen-te nella tabella Violation di origine, e abbiamo utilizzato i marker temporali delle istanze di taletabella come identificatori univoci per la gerarchia temporale. A questo punto, ancora una voltacon l’ausilio di Microsoft SSIS, abbiamo caricato nel data warehouse le informazioni utili al po-polamento della tabella dimensionale. L’ultimo passo e stato quello di popolare le istanze dellatabella Violations, avvalendoci dei dati presenti nel database e delle surrogate keys generate per ilcaricamento dei dati nelle dimension tables.Una precisazione va fatta sulle scelte relative alla gestione della dimensione temporale all’internodel data warehouse. Per quanto riguarda la granularita di questa dimensione, si e scelto come unitaminima il giorno, perche abbiamo ipotizzato che questo potesse essere il livello piu dettagliato percui l’analisi delle violazioni potesse essere di un certo interesse. Inoltre, dati i propositi alla base diquesto progetto, non abbiamo implementato alcun meccanismo di storicizzazione dei dei dati al-l’interno del data warehouse. Questa scelta e stata effettuata al fine di concentrarci primariamentesulla progettazione di uno strumento software per l’analisi delle informazioni con l’ausilio di toolsgrafici. Potrebbe essere quindi utile, in caso di sviluppi futuri del modello logico utilizzato per que-sto progetto, implementare un sistema di time-markers al fine di permettere l’analisi comparativadei dati, oltre che di facilitare il processo di aggiornamento del contenuto del data warehouse.

6.3 Strumenti utilizzati

Forniamo ora una breve descrizione degli strumenti software di cui ci siamo avvalsi durante lediverse fasi di realizzazione del progetto, concentrandoci in particolare sui prodotti atti al comple-tamento delle procedure di realizzazione del data warehouse, nonche delle procedure di extraction,transformation e loading dei dati destinati a popolarlo.

6.3.1 Microsoft SQL Server Integration Services

Ci siamo avvalsi di Microsoft Integration Services [Cub(2008)] per completare la parte di ETL delprogetto. Tale prodotto e una piattaforma per la creazione di soluzioni di integrazione e trasforma-zione di dati con la quale e possibile risolvere problemi aziendali complessi, tramite operazioni dicopia o download di file, aggiornamento di data warehouse, pulizia dei dati e data mining e gestio-ne di oggetti e dati di SQL Server. Mediante Integration Services e possibile estrarre e trasformarei dati da una vasta gamma di origini, ad esempio file di dati XML, file flat e origini dati relazionalie quindi caricarli in una o piu destinazioni.

33

6.3.2 Microsoft SQL Server Analysis Services

Analysis service e un particolare applicativo Microsoft che offre funzionalita di elaborazione anali-tica in linea (OLAP) e di data mining per soluzioni di Business Intelligence[Cub(2008)]. Analysisservices offre flessibilita e potenza del modello di reporting relazionale e funzionalita di analisiavanzata e le straordinarie prestazioni del classico modello OLAP. Con SQL Server 2005, Ana-lysis Services consente di ottenere una visione unificata e integrata di tutti i dati aziendali, chepossono essere utilizzati come base per le normali attivita di reporting, analisi OLAP, scorecardKPI (Key Performance Indicator) e data mining. Tutte le query degli utenti finali provenienti daapplicazioni OLAP, di report e di Business Intelligence personalizzate accedono ai dati tramite ilmodello UDM, che offre una singola visualizzazione aziendale di tali dati relazionali.In Microsoft SQL Server 2005 Analysis Services (SSAS) un cubo viene sviluppato in base a tabel-le e viste modellate a partire da una origine dati. Abbiamo utilizzato questo strumento in questoprogetto per verificare la correttezza del modello logico del nostro data warehouse, e per potercompiere dei test durante le fasi di trasformazione e caricamento dei dati.

34

7 Tools Grafici

In questo capitolo saranno brevemente illustrate alcune soluzioni software per la composizionedi grafici interattivi all’interno di applicazioni web tra le quali abbiamo operato la nostra sceltain fase di progettazione del tool grafico oggetto di questo lavoro. In generale, come mostrato infig. 18, ciascuno di questi strumenti e in grado di fornire un layer grafico ad un progetto di datawarehousing, permettendo quindi la navigazione all’interno della base di dati.

Figura 18: Charting

7.1 DOTNET Charting

Dotnet Charting [Dot(2008)] combina una visualizzazione grafica di ottimo livello con un’inter-faccia user friendly, la quale puo essere utilizzata su qualsiasi piattaforma software. Questo toolgrafico utilizza il framework .NET fornendo quindi agli utenti/sviluppatori C++ e VB.Net unasoluzione di facile utilizzo e apprendimento. Le sue principali caratteristiche:

• facilita d’uso;

• vasto supporto alle diverse tipologie di database;

• differenti modelli grafici per la visualizzazione dei dati.

35

Dotnet Charting crea un nuovo path in grado di integrare 3 diverse funzionalita, fornendo quindiun accesso immediato alla propria base di dati:

• database access;

• data aggregation;

• data handling;

7.2 iDashboards

iDashboards [Ida(2008)] si presenta come una soluzione user-friendly capace di fornire un’alter-nativa interessante ai piu complessi e costosi applicativi di business intelligence. La sua facilitad’uso la rende facile e rapida da installare, ma soprattutto, la connettivita che la contraddistinguecon quasi tutte le tipologie di data sources, la rende facile da implementare.iDashboards migliora in maniera significativa la visibilita dei dati, nonostante essi siano memoriz-zati all’interno di complessi archivi di dati. Gli indicatori di performance presenti all’interno diquesta applicazione permettono una soluzione intuitiva nell’accesso e nel susseguente caricamentodi dati, siano essi immagazzinati in un foglio di calcolo di Microsoft Excel, siano invece presen-ti all’interno di una applicazione Oracle. Tramite semplici operazioni di drill down sara quindipossibile identificare ed analizzare l’immensa mole di dati, con la possibilita da poter interveni-re ed interagire con l’applicazione stessa in tempo reale ove si verificasse un problema. Alcunecaratteristiche:

• diretta estrazione dei dati da qualsiasi database relazionale;

• supporto e utilizzo con qualsiasi browser;

• utilizzo di viste 3D, animazioni e mappe;

7.3 Open Flash Charts

Open Flash Charts [fla(2008)] e una libreria opensource che permette di generare tantissimi tipi digrafici utilizzando alcuni file flash precompilati. Il chart generator funziona con la maggior partedei linguaggi passando da PHP a Java o da Ruby a Python grazie a librerie di supporto scritte daivari utilizzatori.

36

7.4 Dundas

Dundas Chart for ASP.NET [dun(2008)] e la piu recente versione di un pacchetto di chartingpiuttosto diffuso e altamente professionale in grado di generare grafici di numerosissimi tipi, maanche di fornire capacita notevoli quanto a analisi statistiche, manipolazione dei dati, calcolo diformule, aggragazioni e filtri, annotazioni dinamiche e supporto per l’interfaccia utente (toolbar,wizard).Dundas Chart for ASP.NET costruisce il proprio supporto per la programmazione interattiva digrafici attorno a quattro pilastri e relative funzionalita: selezione, drill-down, movimenti del mouse,ed embedded UI. Il controllo Dundas Chart impiega tecniche di hit testing per determinare su qualeelemento del grafico si e fatto click. Quindi il controllo stabilisce autonomamente quale azioneintraprendere. Per esempio, se l’utente ha fatto click sulla fetta di un diagramma a torta, la fettaviene “esplosa”. Dal punto di vista del programmatore la selezione e un processo naturalmenteassociato con eventi server. L’interfaccia HTML cattura attivita lato client (e.g. un click) ed effettuaun postback AJAX. Sul server il controllo lancia un evento server sul controllo Dundas Chart chelo sviluppatore puo gestire tramite codice C# o Visual Basic .NET.

7.5 Tool sviluppato

Dopo aver fornito un’overview degli strumenti disponibili, esponiamo il risultato pratico di quantoanalizzato e sviluppato fino ad ora.Originariamente, la proposta dei membri del COMPAS Consortium e stata quella di utilizzare iltool iDashboards, identificato come la migliore alternativa per la creazione di un dashobard interat-tivo per l’analisi del data warehouse del progetto. Data pero la pressoche immediata indisponibilitadi tale strumento, si e dovuto optare per una soluzione differente. Analizzando le diverse alterna-tive a disposizione, anche in base alle nostre conoscenze riguardanti l’aspetto operativo che unprogetto di questo genere richiede, abbiamo scelto di procedere allo sviluppo del nostro tool grafi-co avvalendoci della tecnologia Microsoft ASP.NET [Asp(2008)] per la realizzazione di una WebApplication che, una volta connessa alla sorgente dati, ne permetta l’analisi multidimensionale se-condo alcuni path dimensionali ben definiti.Nei meeting preliminari di questo progetto e emerso che, data l’ipotetica fascia d’utenza a cui de-stinare questo tool, non sarebbe stato opportuno fornire un normale tool per il data warehousing,che permette all’utente di interagire con la base di dati selezionando i path di aggregazione me-diante combinazione degli attributi dimensionali, ma si e preferito fornire un sistema interattivoattraverso cui l’utente abbia la possibilita di navigare il data warehouse attraverso l’applicazione difiltri successivi, resa possibile dall’interattivita dei grafici utilizzati.Basandoci sulla figura 19, descriviamo ora le diverse aree che compongono lo strumento. All’in-

37

Figura 19: Compas Graphics Tool

38

terno del nostro tool figurano due macro aree, che raggruppano i diversi path di aggregazione deidati del data warehouse. La prima zona, posta nella parte superiore, consente il controllo dell’a-spetto temporale dell’analisi, presentando le informazioni relative alle violazioni secondo il loroandamento temporale. Al livello di default, i dati sono aggregati per anno, presentando il numerototale di violazioni e il trend rispetto all’anno precedente, il quale e identificato con un precisocodice composto da colore e immagine:

• colore rosso e marker a freccia orientata in alto per l’elemento che ha un valore maggioredel precedente;

• colore verde e marker a freccia verso il basso per l’item con valore minore del precedente.

Ogni elemento con valore diverso da zero visualizzato nel grafico e interattivo, e permette all’utentedi effettuare un drill-down dei dati, per passare ad un livello di dettaglio maggiore. Per l’andamentotemporale proponiamo tre livelli di dettaglio:

• years: visualizzazione ad alto livello, in cui i dati sono raggruppati per anno;

• months: le informazioni sono raggruppate per mese, e filtrate in base all’anno scelto allivello precedente;

• days: vista relativa ai giorni del mese selezionato al livello superiore.

Nella stessa area vengono fornite anche alcune viste aggregate delle violazioni: la prima aggregaper giorno della settimana e propone una suddivisione percentuale, mentre la seconda mostra iltotale delle istanze della fact table rappresentate nel grafico temporale, ed evidenzia inoltre i valorimassimo e minimo di tale serie di dati, nonche il valore medio.Nella parte inferiore della pagina web trova invece posto l’area che fornisce la visione dei da-ti raggruppati sia per DimBusinessExecution che per DimRule, che permettono la visione delladistribuzione delle violazioni all’interno della gerarchia relativa alle attivita responsabili delle vio-lazioni oltre che nell’ottica delle regole oggetto di violazione.Per questi charts si e scelta la visualizzazione a barre, che secondo noi e la piu adatta per la rap-presentazione del tipo di informazioni di interesse, dal momento che in questo caso l’andamentotemporale e secondario. A questo proposito, comunque, ogni elemento di ciascuno dei due graficiviene presentato come la somma delle violazioni suddivisa secondo il livello di dettaglio espressodal grafico principale (andamento temporale). In fig. 20, ad esempio, per ogni elemento il totaledelle violazioni e suddiviso secondo l’anno, che in questo caso e il livello di dettaglio di defaultdel grafico temporale. Tale suddivisione e resa visibile grazie alla differente colorazione in base alraggruppamento temporale. Sempre con riferimento alla fig. 20, facciamo notare all’interno delgrafico alcuni indicatori lineari, che hanno funzioni ben precise:

39

Figura 20: Business Subject con suddivisione per anno delle violazioni

• indicatore giallo (Avg): da il valore medio delle violazioni, calcolato su tutti gli elementidella gerarchia;

• indicatore rosso: indica la media delle violazioni per anno per ogni singolo elemento;

• indicatore nero tratteggiato: indica una running average, ossia la media delle violazioni peranno, calcolata per ogni elemento tenendo in considerazione anche tutti gli elementi ad essoprecedenti.

Inoltre, per entrambe le dimensioni, viene data la possibilita di scegliere il livello di dettaglio per lapresentazione dei dati attraverso la drop down list presente nella parte alta di fig. 20, che forniscela seguente gerarchia:

1. type of business subject;

2. business subject;

3. business execution.

La stessa funzionalita viene fornita per la dimensione DimRule, ma in questo caso la gerarchiautilizzata sara:

40

1. type of source;

2. source;

3. goal;

4. policy;

5. rule.

Un’ulteriore informazione relativa alle violazioni viene fornita dai gauges in fig. 21, i quali rappre-sentano la suddivisione delle violazioni per Role e per Employee, enfatizzando quelle che possonoessere definite come violazioni automatiche, ossia compiute dall’attivita in se, e non da un partico-lare employee o role.

Figura 21: Suddivisione delle violazioni per Role ed Employee

Per mantenere una correlazione con l’area temporale dell’applicazione, dal momento che il livellodi drill-down di quest’ultima e utilizzato come filtro per tutte le interrogazioni al data warehouse,mostriamo un gauge (fig. 22) che rappresenta il numero totale di violazioni mostrate nei grafici di

41

DimBusinessExecution e DimRule rapportato al totale delle violazioni del periodo, dato che questidue grafici sono interdipendenti dal punto di vista dei filtri. Questo particolare indicatore mostra

Figura 22: Gauge per il totale delle violazioni visualizzate

il numero di violazioni risultanti solo dall’applicazione del filtro temporale, identificato dal valorein rosso sull’asse y, e il numero delle violazioni dopo l’applicazione dei filtri su DimBusinessExe-cution e DimRule. I due grafici, infatti, sono da considerarsi interdipendenti, dal momento che ilprocesso di drill down di uno dei due viene utilizzato come filtro per l’insieme dei dati dell’altro.

7.5.1 Un esempio d’utilizzo

Forniamo d’ora a titolo di esempio alcuni screenshots dell’applicazione durante un test d’uso, attra-verso i quali vogliamo mostrare l’interattivita dello strumento e l’interdipendenza delle sue parti.Per la situazione iniziale, facciamo riferimento alla figura 19, e ci concentriamo ora sull’opera-zione di drill down per l’anno 2007 del grafico riportante l’andamento temporale delle violazioni(fig. 23). Come si nota, l’andamento temporale e ora suddiviso nei mesi dell’anno scelto, e l’areaViolations, cosı come il gauge rappresentato in fig. 22, rappresenta il totale delle violazioni perl’anno 2007. Inoltre, il totale delle violazioni di ogni elemento dei grafici Business Subject 2007e Policy 2007 e dato dalla somma delle violazioni mensili.Scegliendo poi un particolare elemento nel grafico Business Subject 2007, come mostrato in fig.24, si osserva che, a fronte di una invarianza dell’area temporale, il grafico Business Subject 2007stesso mostra ora la suddivisione in Business Execution legate alla particolare Business Subject, eil grafico Policy 2007 mostra solo le violazioni imputate alla particolare Business Subject scelta.Inoltre, il gauge a termometro tiene traccia della somma dei filtri applicati per il calcolo del numerototale delle violazioni mostrate. Una volta esplosa anche una particolare Policy del grafico Poli-cy 2007, il risultato ottenuto (fig. 25) riguarda il numero di violazioni compiute nell’anno 2007,da una particolare Business Subject nei confronti di una particolare Policy, e la visualizzazione ditali violazioni avviene utilizzando raggruppamenti per Business Execution (relative alla BusinessSubject) e Rule (della Policy scelta).

42

Figura 23: Drill down dell’anno 2007

43

Figura 24: Drill down dell’anno 2007, per una particolare Business Subject

44

Figura 25: Drill down dell’anno 2007, per una particolare Business Subject e una particolare Policy

45

8 Future Works

Data la natura accademica del progetto, il nostro obiettivo principale era quello di poter megliocomprendere le tecniche di data warehousing e analisi dei dati attraverso un’applicazione prati-ca, dovendoci quindi misurare con problematiche e tematiche tipiche della progettazione, la cuidimensione reale viene difficilmente colta durante le lezioni frontali. Non ci siamo spinti quinditroppo in profondita all’interno del dominio del problema, e abbiamo trattato alcune questioni inmodo non molto approfondito, dal momento che non le abbiamo ritenute fondamentali per il rag-giungimento degli obiettivi di progetto, oppure perche alcuni di questi temi sono stati affrontati,magari ugualmente non in profondita, in alcune aree dello sviluppo, e trattarle nuovamente allostesso grado di complessita avrebbe significato una semplice duplicazione di un lavoro gia affron-tato.In particolare, riteniamo che ulteriori lavori di approfondimento potrebbero essere compiuti se-guendo principalmente tre filoni. In primis, potrebbero essere implementate alcune modifiche allastruttura del data warehouse per permettere la storicizzazione dei dati inseriti, e quindi evitare diperdere le informazioni gia presenti nel momento di un aggiornamento del data warehouse.In secondo luogo, potrebbe essere possibile estendere le informazioni contenute in particolare nelladimensione DimBusinessExecution, prevedendo la disponibilita di dati relativi a BusinessEvent eBusinessData, al momento trattati solamente in sede di progettazione concettuale del modello.Infine, rivedendo la parte concettuale della progettazione, potrebbe essere utile prevedere una re-lazione di Compliance tra Business Execution e Rule, in modo da fornire agli utenti un quadroinformativo piu completo di quanto sia disponibile ad oggi.

8.1 Le marche temporali

Allo stato attuale del progetto, non si e approfondito particolarmente il tema della dinamicita,considerando uno scenario temporale di tipo oggi o ieri [Golfarelli e Rizzi(2002)], nel quale cia-scun evento viene riportato alla configurazione assunta dalle gerarchie nell’istante di tempo in cuil’evento si e verificato, il quale richiede l’inserimento di nuovi record nelle tabelle dimensionaliqualora i nuovi fatti lo richiedano. Potrebbe essere utile, pero, ai fini di fornire un’analisi compa-rativa di diverse situazioni temporali, modificare la struttura del data warehouse per permettere ditenere traccia di eventuali aggiornamenti nella fact table o nelle dimension tables, e di utilizzareanche queste informazioni in sede di analisi.

46

8.2 BusinessEvent e BusinessData

Uno sviluppo futuro potrebbe essere quello di considerare la possibilita di integrare all’interno deldata warehouse le tabelle BusinessData e BusinessEvent, allo scopo di raffinare l’analisi relativa al-la tabella BusinessExecution, le quali invece, per motivi di semplicita, sono state omesse dall’attua-le analisi. Questo processo riteniamo non comporti un carico di lavoro eccessivo, visto soprattuttoche le 2 tabelle sopra citate altro non sono che una specializzazione della tabella BusinessExecu-

tion. In questo modo si potrebbe ampliare il dettaglio di analisi riferito alla BusinessExecution,in modo tale da permettere una piu precisa ed accurata classificazione delle BusinessExecution.Come gia accennato sopra, questa operazione richiedera: una nuova modellazione del diagrammadegli attributi, visto che noi, nella fase di progettazione concettuale, abbiamo tagliato i 2 rami cor-rispondenti alle tabelle BusinessEvent e BusinessData; la modifica del data warehouse, inserendoqueste 2 tabelle all’interno di una Dimension; il caricamento dei rispettivi valori all’interno delletabelle.

8.3 Compliance

Un ulteriore e possibile sviluppo futuro riguardera l’analisi non solo relativa alle violazioni, maprendera in esame anche la compliance effettiva dei vari processi all’interno del caso di studio. Saraquindi un’analisi della maggior parte degli aspetti di conformita presenti all’interno di un businessprocess, con il risultato di ottenere e quindi di riuscire a sviluppare business compliance solutions.La soluzione che verra sviluppata consistera nel considerare l’entita compliance allo stesso mododell’entita violations, in modo da identificarla come un fatto in grado poi di permettere l’analisi elo studio delle proprie dimensioni; per completare questo processo di sviluppo sara resa necessariouna migliore mappatura dei legami e delle relazioni tra il modello entita relazione, il database eil data warehouse. In questo modo sara possibile ottenere e studiare l’intero processo da un altropunto di vista, oltre naturalmente all’analisi tramite le violazioni, e cosı fornire un quadro sia diconfronto che di ulteriore analisi all’intero caso oggetto di studio.

47

Riferimenti bibliografici

[Com(2008)] (2008). Compas - compliance-driven models, languages, and architectures forservices. [Online; controllata il 20-novembre-2008].

[Cub(2008)] (2008). Cube and analysys service. [Online; controllata il 15-dicembre-2008].

[Dot(2008)] (2008). Dotnetcharting. [Online; controllata il 20-dicembre-2008].

[dun(2008)] (2008). Dundas chart. [Online; controllata il 21-dicembre-2008].

[Ida(2008)] (2008). idashboards. [Online; controllata il 20-dicembre-2008].

[Asp(2008)] (2008). Microsoft asp.net. [Online; controllata il 01-febbraio-2009].

[fla(2008)] (2008). Open flash chart. [Online; controllata il 21-dicembre-2008].

[SOA(2008)] (2008). Service-oriented architecture. [Online; controllata il 30-novembre-2008].

[Consortium(2008a)] Consortium C. (2008a). Credit check bp fragment.

[Consortium(2008b)] Consortium C. (2008b). Loan bp process.

[Giorgini(2008a)] Giorgini P. (2008a). Datawarehouse. [Slide del corso di Database e BusinessIntelligence].

[Giorgini(2008b)] Giorgini P. (2008b). Entity relationship model. [Slide del corso di Database eBusiness Intelligence].

[Giorgini(2008c)] Giorgini P. (2008c). Progettazione concettuale. [Slide del corso di Database eBusiness Intelligence].

[Giorgini(2008d)] Giorgini P. (2008d). Progettazione logica. [Slide del corso di Database eBusiness Intelligence].

[Golfarelli e Rizzi(2002)] Golfarelli M.; Rizzi S. (2002). Data Warehouse - teoria e pratica della

progettazione. McGraw-Hill, Milano.

48