Database Project

1. Database e Business Intelligence
Progetto
Matteo Pozzani Alessandro Trentin
126118 126134
m.phobos@gmail.com 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 pi` strumenti
u
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 pi` fedelmente
u
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 pi`
u
degli strumenti precedentemente valutati, permetta di navigare a pi` livelli il contenuto del
u
data warehouse da noi progettato.

2. 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

3. 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

4. 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 particolare
Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Elenco delle tabelle

5. 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 una
fase preliminare del progetto, dove all’interno del COMPAS Consortium stesso si sta cercando di
definire e progettare tutto quanto concerne il Conceptual Data Model.
Il nostro lavoro preveder` quindi in input di tale modello e, tramite conseguente traduzione in sche-
a
mi Entit` -Relazione, dovr` produrre la base necessaria per la costruzione di un modello concettuale
a a
grafico 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 scopo
primario di integrare i dati provenienti dalle diverse sorgenti esistenti. Esso permette di separare
l’elaborazione di tipo analitico (OLAP - On-Line Analytical Processing) da quella transazionale
(OLTP - On-Line Transactional Processing), costruendo un nuovo raccoglitore di informazioni che
integra 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 concentra
sulla rappresentazione della realt` di interesse in maniera formale e completa, ma indipendente
a
dal DBMS utilizzato. A questo scopo, a partire dal Conceptual Data Model e dall’E-R diagram
effettueremo la progettazione concettuale, che permetter` di rappresentare tutti i concetti utili alla
a
modellazione 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 anche
le misure, ossia le propriet` numeriche che descrivono aspetti quantitativi dei fatti, le dimensioni,
a
che rappresentano le coordinate di analisi di ciascun fatto, e infine le gerarchie, raffiguranti gli
alberi 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 del
progetto COMPAS. Si prevede dunque un processo ETL (Extraction, Transformation, Loading),
che consiste nell’estrazione dei dati dalle sorgenti di dati eterogenee, nella loro trasformazione e
standardizzazione, e nel caricamento all’interno del data warehouse, rendendoli utilizzabili per le
successive 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 data
warehouse, e di fornire anche feedback sulle caratteristiche della strumentazione utilizzata.

6. 2 Contesto
E’ sempre pi` frequente, nell’ambito dei sistemi IT, la fornitura di prestazioni in termini di soluzio-
u
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 come
base 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 diverse
problematiche di conformit` che si devono affrontare durante tutte le fasi di sviluppo ed implemen-
a
tazione, e la mancanza da parte dell’approccio SOA di strategie chiare per una corretta gestione di
tali problemi durante l’intero ciclo di vita del progetto.
Le conformit` a cui si fa riferimento possono riguardare teoricamente ogni singola regola appli-
a
cata ad ogni business process, sia esso trasversale oppure interno all’organizzazione. Detto ci` , la
o
conformit` pu` essere richiesta ad esempio nei confronti di service composition policies, service
a o
deployment policies, security policies, QoS policies, oppure di intellectual property e brevetti.
Data l’eterogenea natura delle sorgenti di conformit` , allo stato attuale non viene fornito un unico
a
software framework che permetta di mantenere l’intero sistema costantemente conforme a tutte le
`
regole, perch` per alcune di queste e difficile l’oggettiva identificazione di ogni singolo aspetto.
e
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, nonch` di un architectural framework allo
e
scopo di garantire alle aziende la possibilit` di sviluppare business compliance solutions, utilizzan-
a
do un unico insieme di strumenti di controllo per l’intero ciclo di vita del progetto. L’approccio uti-

7. `
lizzato e il model-driven software development (MSDS), che si avvale di linguaggi domain-specific
per ridurre i tempi, i costi e le difficolt` tecniche di realizzazione delle soluzioni, mantenendo il
a
pi` alto grado di conformit` ad ogni aspetto regolativo considerato.
u a
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 conformit` di cui tener conto. Il
a
framework assicurer` inoltre lo sviluppo di business processes e servizi in grado di rispondere
a
ai requisiti del maggior numero di aspetti di conformit` , e permetter` di identificare compliance
a a
policies semplicemente utilizzabili contestualmente a tali processi e servizi.

8. 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 la
realizzazione del prodotto finale, dal momento che un’errata comprensione delle aspettative e una `
delle maggiori cause di fallimento nei progetti software. Per ridurre al minimo questo rischio, e `
utile formalizzare le richieste di chi commissiona il progetto e gli obiettivi dello stesso in elenco di
voci, che prende il nome di documento dei requisiti.
Tali requisiti possono sembrare astratti e intangibili, specialmente per gli sviluppatori di software,
o`
e la conseguenza di ci` e l’accorpamento delle fasi di design e di raccolta dei requisiti. E’ invece
`
fondamentale mantenere le due fasi separate: la documentazione dei requisiti e uno sforzo nella
comprensione 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 ci` di cui gli
o
utenti hanno bisogno affinch´ il sistema funzioni, ed i requisiti non funzionali, indicanti dei fattori
e
globali che contribuiscono al successo generale del sistema.
Di seguito verranno evidenziati, in maniera superficiale, alcuni dei requisiti fondamentali del pro-
getto. Sar` per l’appunto un’analisi di carattere generale, poich´ , in fase di definizione del proble-
a e
`
ma, e stato deciso di utilizzare un approccio basato sulle sorgenti, e non sui requisiti, per quanto
riguarda la definizione della progettazione concettuale. Ci` significa che attraverso lo studio di
o
schemi operazionali sar` possibile derivare un prototipo di schema concettuale in modo pressoch´
a e
automatico.
Tra i requisiti funzionali pi` importanti citiamo:
u
• accesso tramite web browser, in modo da rendere utilizzabile l’applicazione dal maggior
numero di utenti, e senza che essi debbano installare alcun componente software sul proprio
computer;
• compatibilit` multipiattaforma, e connesso con il requisito precedente, dal momento che si
a `
prevede di poter accedere allo strumento realizzato indipendentemente dal sistema operativo
utilizzato;
• tempi di risposta ridotti tra la richiesta dell’utente e la risposta del sistema, per evitare lunghe
attese;

9. • flessibilit` nel soddisfare le esigenze dell’utente in termini di analisi dei dati, permetten-
a
dogli di creare le proprie queries secondo le proprie necessit` , non vincolandolo a valori
a
predefiniti.
Per quanto concerne i requisiti non funzionali vanno menzionati:
• scalabilit` , in modo da soddisfare le richieste di un numero crescente di utenti;
a
• usabilit` , in termini di semplicit` d’uso e di intuitivit` nell’interazione con l’interfaccia dello
a a a
strumento;
• affidabilit` , ossia assicurare un alto rate di successo nella soddisfazione delle richieste degli
a
utenti;
• non ambiguit` nell’interpretazione dei risultati mostrati;
a
• semplicit` dell’interfaccia.
a
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 gi` riportato, lo scopo del progetto COMPAS stesso e il monitoraggio della compliance
a
delle attivit` aziendali rispetto alle regole definite dall’azienda stessa, ma anche da altre sorgen-
a
ti. Considerando quanto appena enunciato come obiettivo di alto livello, il nostro data mart deve
permettere di identificare e monitorare i casi di non conformit` , definiti come violazioni, le quali
a
devono poter essere successivamente analizzate dal tool grafico. Detto ci` , nell’ottica di mappare
o
`
quanto richiesto nel data warehouse, e possibile ipotizzare che l’unico fact candidate interessante
in questo dominio sia appunto la violazione, dal momento che, considerando il livello di dettaglio
`
desiderato dagli utenti, e l’unico concetto al quale si pu` associare la caratteristica di dinamicit`
o a
che ne renda in qualche modo utile un’analisi.
Partendo quindi dall’unico ipotetico fatto identificato, sempre riferendoci alle necessit` degli utiliz-
a
`
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 utilizzata
come punto di partenza per la costruzione del data warehouse. Per il fatto violation, identifichiamo

10. come probabili dimensioni la Business execution e la Regola alla quale la violazione fa riferimen-
to, nonch´ la data in cui questa viene riscontrata, per ottenere la possibilit` di un’analisi storica
e a
delle 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, perch` e
il verificarsi del fatto stesso coincide con una misura, dal momento che l’interesse degli utenti e `
la quantit` di violazioni riscontrate, ad esempio, per una determinata attivit` riguardo una certa
a a
regola.
3.3 Il carico di lavoro preliminare
`
Il riconoscimento di fatti, dimensioni e misure e strettamente collegato all’identificazione di un
carico di lavoro preliminare[Golfarelli e Rizzi(2002)]. Nel nostro caso, data la specificit` del do-
a
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 pi` significativo associato alla gerarchia di ciascuna dimensione di aggregazione.
u
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 per
`
l’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 pattern
Regola, Policy, Goal, Sorgente, Tipo di sorgente, al fine di ottenere un quadro sempre pi` generale
u
delle violazioni riscontrate.
Infine, contestualmente alla dimensione Business execution, potrebbe avere senso un aggregation
pattern 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’azienda
maggiormente soggette a non conformit` alle regole stabilite dalle policies.
a

11. 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 concettuale
di un data warehouse, perch´ non si concentra sufficientemente sull’interazione dell’utente con la
e
base di dati per l’indagine e la ricerca di informazioni.
In questo progetto sar` infatti adottato il DFM (Dimensional Fact Model), un modello concettuale
a
grafico 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 interrogazioni
dell’utente.
La base di partenza per la costruzione del DFM da utilizzare sar` comunque un diagramma E-R,
a
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 rappresenta
schematicamente, attraverso notazione UML, il dominio in cui si andr` ad operare.
a
Business
process Source Regulation
BP
fragment 1..N
0..N
BP activity 0..N License
Business Subgoal Goal
Sub-subject
service
QoS policy
0..N 1..N
0..N 0..N Business 1..N 0..N
Role Policy Behavioral
subject
composition
1..N model
0..N 0..N 1..N
0..N 0..N Business 0..N 0..N Process/service
Employee Violation Rule composition
execution
model
0..N 0..N
Business Business Security policy
data events
...
Figura 3: COMPAS conceptual model
Osservando il modello pi` in dettaglio, forniamo ora una descrizione dei concetti che lo compon-
u
gono.
Secondo la nostra analisi, il punto di maggiore interesse per il COMPAS Consortium [Com(2008)]

12. e il Business subject, che identifica le attivit` svolte dall’azienda allo scopo di realizzare i propri
` a
prodotti. Tali attivit` devono essere oggetto di costantemente monitoraggio al fine di garantirne la
a
continua compatibilit` con le regole e specifiche definite dalle compliance rules.
a
Il Business subject pu` fare riferimento a diverse entit` , che sono comunque legate alle attivit`
o a a
aziendali. 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 comprenderne
le modalit` di esecuzione, ossia Business execution, che permettono di ottenere un maggiore li-
a
vello di dettaglio nella descrizione degli scenari di interesse, anche attraverso l’identificazione dei
soggetti che le svolgono (Employee), e nella successiva valutazione.
Un altro importante aspetto da considerare e la definizione delle Policies, ossia i regolamenti da
`
utilizzare come base di valutazione per stabilire il grado di compliance delle attivit` . Queste po-
a
licies espongono regole precise, identificate dal concetto Rule, che fanno riferimento a sorgenti
legislative 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 necessit` di evidenziare il livello di agreement delle attivit` aziendali con le
a a
policies definite al fine di poter agire tempestivamente e puntualmente in caso di violazioni. A
questo proposito, quindi, nel modello concettuale assume un ruolo di primaria importanza il con-
cetto di Violation, che identifica con precisione le incompatibilit` delle attivit` con le regole che
a a
le governano. Per meglio comprendere quanto appena descritto, riportiamo di seguito due esempi
in cui il modello concettuale viene applicato ad uno specifico contesto pratico. In particolare, si
fa riferimento ad un business processes aziendale e ad una sua parte specifica, e si evidenziano le
possibili violazioni alle regole per essi definite.
4.1.1 Loan process
Rappresentiamo ora lo schema concettuale del Loan Process, cio` il processo di valutazione e
e
concessione di credito.
`
In questo caso, tutto il processo di concessione di un prestito e affidato ad un solo employee, e tale
prassi genera delle eccezioni sulle policy applicate.
In particolare, si evidenzia la necessit` della suddivisione dei ruoli in tale processo, accorgimento
a
da mettere in atto al fine di soddisfare il principio di design per l’information protection, ma anche
per prevenire errori o potenziali problemi dovute all’accentramento di responsabilit` in un solo
a
soggetto.

13. 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 la
`
richiesta 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 violazioni
alle 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 entit` e le relazioni che descrivono il
a
dominio di interesse [Giorgini(2008b)].
La rappresentazione relazionale rispecchia generalmente quanto raffigurato in fig. 3, anche se sono
state operate alcune scelte progettuali nell’ottica di semplificare il modello concettuale, per poterci
meglio concentrare sullo scopo primario del progetto.

14. Figura 5: Credit check BP fragment object diagram [Consortium(2008a)]
In primo luogo, abbiamo deciso di raggruppare alcune entit` per semplificarne la gestione nelle fasi
a
successive del progetto, dato che anche ai fini dell’analisi che andremo a compiere non ricoprono
ruoli di primaria importanza. In particolare, abbiamo considerato le entit` Business process, BP
a
Fragment, BP Activity e Business Service come tipologie di Business Subject, e quindi le abbiamo
codificate in fig. 6 con l’entit` Type of Business Subject, alla quale sono associati come attributi
a
un identificatore e una descrizione.
`
Lo stesso principio e stato adottato per le diverse sorgenti di riferimento dei goals, le quali sono
state raggruppate nell’entit` Source, che ha come attributo una descrizione testuale, e viene iden-
a
tificata da una chiave primaria, composta da un idenficatore interno associato a quello dell’entit` a
Type of source, utilizzata per descrivere le diverse tipologie di sorgenti a disposizione.
Nella nostra rappresentazione abbiamo inoltre trattato le date come entit` , invece che come sem-
a
plici attributi, per cercare di fornire una struttura uniforme ad un tipo di dato generalmente molto
complesso da gestire. A questa entit` , poi, oltre ad un identificatore univoco, sono stati associati
a
gli 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 identificare
una particolare relazione 1-a-2 Start/End tra Business execution e Date, dal momento che ad ogni
Business execution sono associate una data di inizio e una di fine dell’attivit` .a
A differenza di quanto riportato nel modello concettuale, inoltre, abbiamo ritenuto utile l’inseri-
mento della relazione domain tra le entit` Business subject e Policy, in quanto potrebbe permettere
a
di avere una visione d’insieme pi` generale, e non solamente inerente le violazioni commesse dalle
u
`
Business execution sulle singole regole. Questa modifica, comunque, e riferita solamente al dia-
gramma E-R, e non viene utilizzata ulteriormente, perch´ il nostro progetto prevede l’analisi delle
e

15. Figura 6: Entity Relationship model

16. violazioni, e non delle performance generali di compliance delle attivit` aziendali.
a
Abbiamo infine considerato la Violation come una relazione tra Business execution, Date e Rule,
e non come un’entit` a se stante. Questa scelta ci ha permesso di individuare in questa relazione il
a
punto di partenza per la costruzione del Data Warehouse da utilizzare come supporto tecnologico
per 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 entit` o relazioni che rappresentano archivi
a
frequentemente modificati dei buoni candidati per la definizione di fatti [Giorgini(2008c)].
`
Nel nostro caso, l’unica relazione che ha natura dinamica e la Violation, perci` la possiamo consi-
o
derare come candidata a ricoprire il ruolo di fact nel DFM che andremo a realizzare. Non riteniamo
di dover identificare alcun ulteriore fatto, perch` le altre relazioni non sono sufficientemente dina-
e
miche da essere considerate come fatti. Detto ci` , esplodiamo la relazione di violazione, come
o
visualizzato in fig. 7, e scendiamo in dettaglio per meglio comprendere la composizione delle en-
tit` e degli attributi coinvolti nel fatto principale.
a
E’ stato assegnato a Violation un identificatore composto dalle chiavi primarie di Business execu-
tion, Rule e Date, in modo da prevedere anche la possibilit` di gestire violazioni multiple della
a

17. stessa regola da parte della stessa business execution.
Come discusso precedentemente, le date non sono state considerate come attributi, ma come entit` ,
a
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 di
aggregazione ed analisi dei dati.
4.3 Database
Coerentemente con il processo di progettazione e sviluppo di un data warehouse, il diagramma
Entity-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 e`
stato utilizzato come base per la realizzazione del database stesso, oltre che come punto di parten-
za per la realizzazione del DFM. Tale particolarit` ha portato, una volta sviluppato e popolato il
a
DB, ad alcune differenze nella progettazione dell’ER diagram e nella realizzazione del database,
le quali si sono manifestate perch` solo l’implementazione pratica ha reso chiare alcune esigenze
e
dell’analisi dei dati.
`
Osservando la figura 8, e dunque immediatamente possibile notare che la ragione principale di
`
quanto appena descritto e dovuta alla presenza di relazioni molti-a-molti tra alcune tabelle, le quali
impedivano, nell’implementazione originale del database, il legame diretto dei dati con la tabella
Violation, utile ai fini dell’analisi.
Le modifiche effettuate, dunque, hanno avuto lo scopo di poter fornire ad ogni istanza della ta-
bella Violation la totalit` delle informazioni ad essa legate, fornendo tutti gli strumenti per una
a
corretta analisi dei dati in essa contenuti. In particolare, con riferimento alla fig. 8, si nota che
`
le tabelle coinvolte in relazioni n-n, tali per cui una particolare violazione non ne e univocamente
riconducibile 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 coinvolta
in una singola violazione. L’implementazione di questo livello di informazione nel database
ha richiesto l’inserimento del campo Source ID nella tabella Violation;
• Employee: permette di conoscere l’identit` della persona responsabile di una violazione,
a
qualora la Business Execution preveda l’esecuzione di attivit` da parte di un lavoratore.
a
`
Questa relazione non e obbligatoria, perch` alcune attivit` possono essere senza intervento
e a
umano. 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,

18. 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 documento
relativi al lavoro concettuale precedentemente svolto, ma piuttosto di evidenziare la dinamicit` a
`
della 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 vera
e propria del sistema.
Un ulteriore precisazione va fatta relativamente alle tabelle Business Event e Business Data, che
sono da considerarsi come specializzazioni di Business Execution. Pur avendo implementato tali
tabelle all’interno del nostro database, abbiamo deciso di non considerarle nelle fasi successive
della progettazione del data warehouse, perch` l’apporto informativo dei dati contenuti in tali ta-
e
`
belle e sostanzialmente minimo, ed abbiamo preferito concentrarci su altri aspetti, quali ad esempio
l’identificazione dei ruoli o degli employees che compiono le violazioni.

19. Figura 8: Database Diagram

20. 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 dei
dati, alla prima versione dell’albero vengono applicate alcune procedure con lo scopo di eliminare
i livelli di dettaglio non necessari. Le due pratiche principali sono la potatura, che se applicata ad
un vertice dell’albero ne elimina tutto il sottoalbero che ha quel particolare vertice come radice, e
l’innesto, che permette di eliminare un vertice non utile, ma di mantenere le informazioni conte-

21. nute nei suoi discendenti.
`
Dopo aver applicato tali procedure, il risultato del nostro attributes tree e mostrato in fig. 10, nel
quale 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 di
dettaglio troppo alto, oppure non utile. Ad esempio, sono stati rimossi gli attributi che facevano
e `
riferimento a Business subject o Source, perch` si e ritenuta pi` utile al fine dell’analisi la presenza
u
di tali entit` associate alla propria tipologia.
a
`
Per quanto riguarda la dimensione data invece, negli alberi degli attributi e stato rappresentato
quello che nella nostra opinione pu` essere l’aggregation path per l’analisi dei dati, anche se alcuni
o
degli step di questo percorso (ad esempio il livello di aggregazione trimestrale) saranno calcolati,
invece di essere salvati nel data warehouse come attributi, perch` sono facilmente ottenibili dalle
e

22. informazioni originariamente contenute nel data mart.
Infine, come e possibile notare dalle fig. 9 e 10, emerge che il fact candidate Violation sar` vuoto,
` a
`
senza cio` alcuna measure. La ragione di questa scelta e da ricondurre alla natura stessa della
e
a `
violazione di una regola da parte di un’attivit` , che e binaria, nel senso che questa pu` avvenire o
o
non avvenire, e quindi l’unica informazione ottenibile da un data mart basato su quanto progettato
`
e la quantit` di violazioni avvenute, la quale potr` per` essere aggregata sulla base di tutte le
a a o
dimensioni di aggregazione disponibili.
I diagrammi mostrati in figg. 9 e 10 sono utilizzati anche per l’identificazione delle dimensions,
le quali stabiliscono la granularit` degli eventi primari. Nel nostro caso sono state identificate le
a
seguenti tre dimensioni:
Business Execution che identifica il fenomeno oggetto di analisi, ossia le attivit` di cui si vuole
a
monitorare la compliance rispetto alle regole definite nelle diverse policies. La gerarchia di
aggregazione di questa dimensione permette di ottenere informazioni sulle violazioni com-
messe da ogni business subject, ma anche di identificare gli eventuali soggetti responsabili
di tali violazioni.
Rule cio` il termine di confronto per le attivit` svolte dall’azienda. Aggregando a partire da
e a
`
questa dimensione e possibile inoltre verificare le violazioni sia in base alle policies definite
dall’azienda che rispetto alle sorgenti da cui tali policies sono derivate.
Date che rappresenta la dimensione temporale necessaria all’analisi, dato che le attivit` di cui ci
a
`
si deve occupare sono dilazionate nel tempo. A partire da questa dimensione e stato definito
l’aggregation path che permette di raggruppare i dati delle violazioni in intervalli temporali
di 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 nel
data 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 Business
subject e tra Employee e Business execution, dal momento che, come emerso dai colloqui con
`
il personale impegnato nel COMPAS Consortium, e possibile avere alcune attivit` da monitorare
a
che non richiedono interventi umani per essere compiute, ma che possono comunque dare origine a
violations. Fanno parte della seconda tipologia le relazioni tra Business Data e Business execution
e tra Business Event e Business execution, dal momento che si tratta di relazioni di specializza-
zione della Business execution, e a tale entit` non vanno necessariamente associati Business Data
a
o Events.

23. 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 piattaforma
stabile 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, ma
anche di individuare i percorsi di aggregazione pi` efficaci in relazione alla natura dell’analisi. Per
u
`
il nostro progetto, l’unico fact candidate a disposizione (Violation) e stato effetivamente tradotto
in fatto, come mostrato in fig. 11, nella quale vengono anche fornite alcune informazioni supple-
mentari rispetto a quanto gi` stabilito dall’analisi degli attributes trees.
a
In primo luogo, come anticipato nella spiegazione dell’attributes tree, il fact non contiene misure,
perci` l’aggregazione su ogni dimensione potr` avvenire solamente tenendo conto del verificarsi o
o a
meno 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 pu` es- o
sere identificato a partire da molteplici sorgenti, e per rendere chiaro che ad ogni Business subject
possono essere associate diverse Business execution. Inoltre, a quest’ultima entit` , possono essere
a
connessi molteplici Business data e Business event, oltre che Employee. Infine, l’arco multiplo
e risultato utile per stabilire la relazione di cardinalit` n tra Business subject e Role.
` a
Una volta definito il DFM per il data warehouse, il paso successivo consiste nella progettazione
logica del data mart, che sar` oggetto del prossimo capitolo, nel quale ci occuperemo di definire il
a
modello della base di dati coerentemente con le esigenze di analisi.

24. Figura 11: Dimensional Fact model

25. 5 Progettazione Logica
`
A differenza della progettazione concettuale, per quanto riguarda l’aspetto logico e molto stretta la
connessione con il modello scelto per l’implementazione del progetto. Per questo motivo a livello
logico vanno ponderate diverse alternative, al fine di scegliere la migliore non solo in termini di
prestazioni, ma anche tenendo presente la natura del sistema software a supporto del data ware-
house nonch´ il carico di lavoro per esso ipotizzato. Nel nostro caso, infatti, il data warehouse
e
sar` costruito avvalendosi di un Data Base Management System relazionale, al fine di rendere pi`
a u
semplice 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 quale
pu` essere rappresentata utilizzando due distinti modelli logici[Giorgini(2008d)]:
o
MOLAP (Multidimensional On-Line Analytical Processing) nel quale i dati sono memorizzati
attraverso strutture intrinsecamente multidimensionali, come ad esempio i vettori multidi-
mensionali. Sistemi di questo tipo rappresentano soluzioni capaci di ottime prestazioni, ma
non 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’ambito
di sistemi MOLAP, il problema della sparsit` , secondo cui solo una minima parte delle celle
a
dei cubi multidimensionali di analisi contengono effettivamente informazioni utili.
ROLAP (Relational On-Line Analytical Processing) che utilizza il modello relazionale per la
`
rappresentazione dei dati multidimensionali, la cui tecnologia e consolidata e ampiamente
utilizzata. Questo modello richiede una quantit` elevata di risorse in termini di queries sulla
a
base di dati, data la natura relazionale della stessa, ma offre nel contempo migliore scalabilit`
a
e pi` semplice gestione del database utilizzato.
u
Nel nostro progetto ci avvarremo di modelli del secondo tipo, dal momento che meglio si adattano
all’infrastruttura software relazionale a nostra disposizione. Tali modelli ci permettono di tenere
conto della scalabilit` del sistema, ossia di utilizzare grandi quantit` di dati senza apprezzabili per-
a a
dite di performance, ma anche di ridurre considerevolmente il problema della sparsit` tipico dei
a
modelli MOLAP. Abbiamo inoltre a disposizione uno strumento flessibile che fornisce supporto
all’analisi delle informazioni utilizzando un elevato numero di dimensioni, senza avere la necessit` a
di reingegnerizzare il modello per adattarlo a nuove dimensioni. Oltre a ci` , attraverso l’adozione
o
di modelli ROLAP possiamo avvalerci di SQL come strumento principale per l’interazione con la
base 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 informazioni
riguardanti le gerarchie di attributi legate alle dimensioni di analisi dei fatti di interesse.

26. Star schema che osservando la fig. 12 consiste operativamente nella relazione tra la fact table e le
dimension tables, ciascuna delle quali contiene tutte le informazioni relative alla gerarchia ad
essa legata, presentando dunque dipendenze funzionali transitive al proprio interno. Infatti
l’architettura dello schema a stella risulta essere la pi` semplice quando si vuole disegnare
u
una base di dati[Golfarelli e Rizzi(2002)]. In dettaglio:
• fatti: indicatori numerici aggregabili, quali per esempio le vendite od altre quantit`
a
`
numeriche sommabili; la tabella dei fatti e altamente normalizzata.
• dimensioni: attributi verso i quali si analizzano i fatti (quali, ad esempio, i clienti, i
materiali, 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 numero
variabile di tabelle delle dimensioni tutte direttamente legate alla prima. Le peculiari- t` di
a
questo 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;
• Granularit` : la tabella dei fatti riporta le informazioni di dettaglio e non presenta alcun
a
tipo 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 possono
essere prestabilite, per ogni richiesta sar` necessario operare estrazioni molto onerose.
a
Snowflake schema che, come rappresentato in fig. 13, pu` essere considerato come una forma
o
particolare dello star schema, caratterizzato per` dalla normalizzazione delle dimension ta-
o
bles. E’ infatti possibile ottenere uno snowflake schema a partire da uno star procedendo
alla graduale eliminazione delle dipendenze funzionali transitive presenti nelle dimension
tables[Golfarelli e Rizzi(2002)]. La soluzione che sfrutta uno schema a fiocco di neve, quin-
`
di, e caratterizzata dal fatto che pu` utilizzare direttamente lo schema del database che pro-
o
duce le informazioni. In questo caso le tabelle coinvolte sono quasi sempre ben normalizzate
`
e si presentano in una forma che e tipica dei database transazionali. Questa soluzione e da`
consigliare solo nei casi in cui la mole di dati da trattare sia esigua. Se i dati fossero mol-
ti, infatti, la complessit` delle join che si rendono necessarie comporterebbe tempi di attesa
a
inaccettabili. La soluzione a fiocco di neve pu` essere necessaria se le informazioni che
o
si vogliono estrarre devono assolutamente essere allineate con quelle del momento e non e `
accettabile un ritardo di un giorno o di qualche ora.

27. Figura 12: Star schema
Figura 13: Snowflake schema

28. 5.1 Data warehouse schema
Una volta analizzate le alternative teoriche e considerata la non eccessiva complessit` del nostro
a
sistema, abbiamo scelto di implementare il data warehouse seguendo uno star schema. Questa
`
scelta e motivata anche dalla presenza di un solo fact candidate, e dalla necessit` di relazionare
a
direttamente ogni attributo di ogni dimensione alla fact table. La nostra proposta per lo schema del
`
data 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 riportate
solamente le chiavi che identificano gli attributi primari delle diverse dimension tables. Questo e `
stato possibile grazie alle modifiche apportate in corso d’opera allo schema del data base, le quali
hanno 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 di
lavoro richiesto per le interrogazioni del data warehouse, perch´ si minimizzano le operazioni di
e
join tra tabelle per ottenere le informazioni.

29. 5.2 Dimension tables
Osservando la figura 14, si vede che per ogni gerarchia viene creata una dimension table che ne
contiene tutti gli attributi, i quali saranno accessibili tramite queries SQL al fine di fornire i diversi
livelli 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 permesso
di individuare alcune modifiche riguardanti la dimensione BusinessExecution: infatti, sono pre-
senti i riferimenti alle tabelle Employee e Role, necessarie per poter sviluppare un’analisi corretta
e strutturata della base di dati. In questa maniera sar` possibile ovviare alla particolare struttura
a
delle 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, come
attributi di dimensione, i relativi riferimenti all’interno di BusinessExecution. Un ulteriore aspetto
`
di notevole importanza che ci ha convinti ad effettuare questa operazione, e stata la possibilit` di a
eliminare alcune ridondanze presenti nei dati. Inoltre i riferimenti alle tabelle BusinessData e Bu-
sinessEvent sono stati tralasciati, sia per una questione di semplicit` , visto che anche questi valori
a
hanno 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 della
dimensione BusinessExecution riguardano i campi StartingDate e EndingDate; per semplicit` ven- a
gono da noi considerati come attributi semplici, poich´ secondo la nostra analisi questi 2 campi
e
rappresentano semplicemente delle informazioni di carattere descrittive. La stessa metodologia e `
stata utilizzata anche per la modellazione della dimensione Rule, nella quale sono stati aggiunti i
riferimenti alle tabelle Goal, Source e TypeOfSource. In questo modo, l’accesso ai dati e quindi le
interrogazioni SQL che saranno successivamente sviluppate all’interno del codice per la creazione
ed utilizzo dei tool grafici, risulteranno di complessit` inferiore. Il terzo vertice del nostro schema
a
`
a 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 da
poter 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 utilizzare
come opzioni di navigazione.

30. 6 Progettazione dell’alimentazione
Una volta completata la progettazione e l’implementazione della struttura del data warehouse, si
`
e 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 i
dati provenienti dalle sorgenti operazionali [Golfarelli e Rizzi(2002)].
Nel nostro caso, non siamo in presenza di un vero e proprio livello riconciliato, dove cio` tutti i
e
dati delle diverse sorgenti sono puliti e normalizzati. Essendo nostro compito la progettazione del
database sorgente e il caricamento di dati al suo interno, abbiamo potuto utilizzare formati standard
per dati numerici e relativi a date, oltre che strumenti e procedure utili a semplificare l’utilizzo di
tali 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 pu` essere suddivisa in due fasi,
o
relative rispettivamente al database sorgente e al data warehouse.
6.1 Caricamento dati database
Come gi` anticipato, una volta implementata la struttura del database sul DBMS (nel nostro caso si
a
` `
e optato per Microsoft SQL Server 2005), il nostro compito e stato quello di creare, in quasi totale
assenza di dati reali, una base di dati verosimile per da poter utilizzare poi nel successivo processo
di ETL per il data warehouse.
Per popolare il nostro database, ci siamo avvalsi di un database di test fornitoci da COMPAS
Consortium, 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 fogli
di calcolo per effettuare le trasformazioni necessarie al caricamento dei dati COMPAS nel nostro
database, 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 conformare
i dati allo schema a stella utilizzato nel data warehouse. In generale, dato che ci siamo occupati
anche della progettazione e realizzazione della sorgente, tali procedure non si sono rivelate troppo
`
complesse, 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 tables
utilizzate. Le modifiche effettuate in sede di progettazione del database, poi, hanno permesso di

31. mantenere il pi` alto livello di linearit` nel data warehouse, rendendo necessaria, per ciascuna
u a
delle tabelle DimRule e DimBusinessExecution, l’identificazione di una sola chiave surrogata che
permette di identificarne univocamente ciascuna tupla di valori inseriti. La procedura di creazione
`
delle 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 particolare
gerarchia;
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 si
`
e associata una chiave automatica all’elenco di chiavi identificanti una particolare istanza
della gerarchia di interesse;
3. caricamento dati nella dimension table (fig.17): utilizzando una operazione di join tra la
view e la tabella contenente le surrogate keys, abbiamo realizzato la tabella sorgente da cui
popolare, 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

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

33. 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 tale
tabella come identificatori univoci per la gerarchia temporale. A questo punto, ancora una volta
con 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 della
tabella Violations, avvalendoci dei dati presenti nel database e delle surrogate keys generate per il
caricamento dei dati nelle dimension tables.
Una precisazione va fatta sulle scelte relative alla gestione della dimensione temporale all’interno
a `
del data warehouse. Per quanto riguarda la granularit` di questa dimensione, si e scelto come unit` a
minima il giorno, perch` abbiamo ipotizzato che questo potesse essere il livello pi` dettagliato per
e u
cui l’analisi delle violazioni potesse essere di un certo interesse. Inoltre, dati i propositi alla base di
questo 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 primariamente
sulla progettazione di uno strumento software per l’analisi delle informazioni con l’ausilio di tools
grafici. 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 comparativa
dei 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 le
diverse fasi di realizzazione del progetto, concentrandoci in particolare sui prodotti atti al comple-
tamento delle procedure di realizzazione del data warehouse, nonch´ delle procedure di extraction,
e
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 del
`
progetto. 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 di
copia 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 trasformare
i dati da una vasta gamma di origini, ad esempio file di dati XML, file flat e origini dati relazionali
e quindi caricarli in una o pi` destinazioni.
u

34. 6.3.2 Microsoft SQL Server Analysis Services
`
Analysis service e un particolare applicativo Microsoft che offre funzionalit` di elaborazione anali-
a
tica in linea (OLAP) e di data mining per soluzioni di Business Intelligence[Cub(2008)]. Analysis
services offre flessibilit` e potenza del modello di reporting relazionale e funzionalit` di analisi
a a
avanzata 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, che
possono essere utilizzati come base per le normali attivit` di reporting, analisi OLAP, scorecard
a
KPI (Key Performance Indicator) e data mining. Tutte le query degli utenti finali provenienti da
applicazioni OLAP, di report e di Business Intelligence personalizzate accedono ai dati tramite il
modello 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 questo
progetto per verificare la correttezza del modello logico del nostro data warehouse, e per poter
compiere dei test durante le fasi di trasformazione e caricamento dei dati.

35. 7 Tools Grafici
In questo capitolo saranno brevemente illustrate alcune soluzioni software per la composizione
di grafici interattivi all’interno di applicazioni web tra le quali abbiamo operato la nostra scelta
in fase di progettazione del tool grafico oggetto di questo lavoro. In generale, come mostrato in
`
fig. 18, ciascuno di questi strumenti e in grado di fornire un layer grafico ad un progetto di data
warehousing, 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 pu` essere utilizzata su qualsiasi piattaforma software. Questo tool
o
grafico utilizza il framework .NET fornendo quindi agli utenti/sviluppatori C++ e VB.Net una
soluzione di facile utilizzo e apprendimento. Le sue principali caratteristiche:
• facilit` d’uso;
a
• vasto supporto alle diverse tipologie di database;
• differenti modelli grafici per la visualizzazione dei dati.

36. Dotnet Charting crea un nuovo path in grado di integrare 3 diverse funzionalit` , fornendo quindi
a
un 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 pi` complessi e costosi applicativi di business intelligence. La sua facilit`
u a
d’uso la rende facile e rapida da installare, ma soprattutto, la connettivit` che la contraddistingue
a
con quasi tutte le tipologie di data sources, la rende facile da implementare.
iDashboards migliora in maniera significativa la visibilit` dei dati, nonostante essi siano memoriz-
a
zati all’interno di complessi archivi di dati. Gli indicatori di performance presenti all’interno di
questa applicazione permettono una soluzione intuitiva nell’accesso e nel susseguente caricamento
di 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 sar` quindi
a
possibile identificare ed analizzare l’immensa mole di dati, con la possibilit` da poter interveni-
a
re ed interagire con l’applicazione stessa in tempo reale ove si verificasse un problema. Alcune
caratteristiche:
• 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 di
grafici utilizzando alcuni file flash precompilati. Il chart generator funziona con la maggior parte
dei linguaggi passando da PHP a Java o da Ruby a Python grazie a librerie di supporto scritte dai
vari utilizzatori.

37. 7.4 Dundas
`
Dundas Chart for ASP.NET [dun(2008)] e la pi` recente versione di un pacchetto di charting
u
piuttosto diffuso e altamente professionale in grado di generare grafici di numerosissimi tipi, ma
anche di fornire capacit` notevoli quanto a analisi statistiche, manipolazione dei dati, calcolo di
a
formule, 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 di
grafici attorno a quattro pilastri e relative funzionalit` : selezione, drill-down, movimenti del mouse,
a
ed embedded UI. Il controllo Dundas Chart impiega tecniche di hit testing per determinare su quale
`
elemento del grafico si e fatto click. Quindi il controllo stabilisce autonomamente quale azione
intraprendere. Per esempio, se l’utente ha fatto click sulla fetta di un diagramma a torta, la fetta
`
viene “esplosa”. Dal punto di vista del programmatore la selezione e un processo naturalmente
associato con eventi server. L’interfaccia HTML cattura attivit` lato client (e.g. un click) ed effettua
a
un postback AJAX. Sul server il controllo lancia un evento server sul controllo Dundas Chart che
lo sviluppatore pu` gestire tramite codice C# o Visual Basic .NET.
o
7.5 Tool sviluppato
Dopo aver fornito un’overview degli strumenti disponibili, esponiamo il risultato pratico di quanto
analizzato e sviluppato fino ad ora.
`
Originariamente, la proposta dei membri del COMPAS Consortium e stata quella di utilizzare il
tool iDashboards, identificato come la migliore alternativa per la creazione di un dashobard interat-
tivo per l’analisi del data warehouse del progetto. Data per` la pressoch´ immediata indisponibilit`
o e a
`
di 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 un
progetto 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 Web
Application 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 interattivo
attraverso cui l’utente abbia la possibilit` di navigare il data warehouse attraverso l’applicazione di
a
filtri successivi, resa possibile dall’interattivit` dei grafici utilizzati.
a
Basandoci sulla figura 19, descriviamo ora le diverse aree che compongono lo strumento. All’in-

38. Figura 19: Compas Graphics Tool

39. terno del nostro tool figurano due macro aree, che raggruppano i diversi path di aggregazione dei
dati 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 loro
andamento temporale. Al livello di default, i dati sono aggregati per anno, presentando il numero
`
totale di violazioni e il trend rispetto all’anno precedente, il quale e identificato con un preciso
codice composto da colore e immagine:
• colore rosso e marker a freccia orientata in alto per l’elemento che ha un valore maggiore
del 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’utente
di effettuare un drill-down dei dati, per passare ad un livello di dettaglio maggiore. Per l’andamento
temporale 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 al
livello 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 aggrega
per giorno della settimana e propone una suddivisione percentuale, mentre la seconda mostra il
totale delle istanze della fact table rappresentate nel grafico temporale, ed evidenzia inoltre i valori
massimo e minimo di tale serie di dati, nonch´ il valore medio.
e
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 della
distribuzione delle violazioni all’interno della gerarchia relativa alle attivit` responsabili delle vio-
a
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 pi` adatta per la rap-
u
presentazione del tipo di informazioni di interesse, dal momento che in questo caso l’andamento
`
temporale e secondario. A questo proposito, comunque, ogni elemento di ciascuno dei due grafici
viene presentato come la somma delle violazioni suddivisa secondo il livello di dettaglio espresso
dal grafico principale (andamento temporale). In fig. 20, ad esempio, per ogni elemento il totale
` `
delle violazioni e suddiviso secondo l’anno, che in questo caso e il livello di dettaglio di default
`
del grafico temporale. Tale suddivisione e resa visibile grazie alla differente colorazione in base al
raggruppamento temporale. Sempre con riferimento alla fig. 20, facciamo notare all’interno del
grafico alcuni indicatori lineari, che hanno funzioni ben precise:

40. Figura 20: Business Subject con suddivisione per anno delle violazioni
• indicatore giallo (Avg): da il valore medio delle violazioni, calcolato su tutti gli elementi
della 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 per
anno, calcolata per ogni elemento tenendo in considerazione anche tutti gli elementi ad esso
precedenti.
Inoltre, per entrambe le dimensioni, viene data la possibilit` di scegliere il livello di dettaglio per la
a
presentazione dei dati attraverso la drop down list presente nella parte alta di fig. 20, che fornisce
la seguente gerarchia:
1. type of business subject;
2. business subject;
3. business execution.
La stessa funzionalit` viene fornita per la dimensione DimRule, ma in questo caso la gerarchia
a
utilizzata sar` :
a

41. 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 possono
essere definite come violazioni automatiche, ossia compiute dall’attivit` in s´ , e non da un partico-
a e
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 livello
`
di 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

42. DimBusinessExecution e DimRule rapportato al totale delle violazioni del periodo, dato che questi
due 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 valore
in 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 il
processo 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’interattivit` dello strumento e l’interdipendenza delle sue parti.
a
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’area
Violations, cos` come il gauge rappresentato in fig. 22, rappresenta il totale delle violazioni per
ı
l’anno 2007. Inoltre, il totale delle violazioni di ogni elemento dei grafici Business Subject 2007
e 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 2007
stesso mostra ora la suddivisione in Business Execution legate alla particolare Business Subject, e
il 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 numero
totale 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 di
tali violazioni avviene utilizzando raggruppamenti per Business Execution (relative alla Business
Subject) e Rule (della Policy scelta).

43. Figura 23: Drill down dell’anno 2007

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

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

46. 8 Future Works
Data la natura accademica del progetto, il nostro obiettivo principale era quello di poter meglio
comprendere 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 cui
dimensione reale viene difficilmente colta durante le lezioni frontali. Non ci siamo spinti quindi
troppo in profondit` all’interno del dominio del problema, e abbiamo trattato alcune questioni in
a
modo non molto approfondito, dal momento che non le abbiamo ritenute fondamentali per il rag-
giungimento degli obiettivi di progetto, oppure perch´ alcuni di questi temi sono stati affrontati,
e
magari ugualmente non in profondit` , in alcune aree dello sviluppo, e trattarle nuovamente allo
a
stesso grado di complessit` avrebbe significato una semplice duplicazione di un lavoro gi` affron-
a a
tato.
In particolare, riteniamo che ulteriori lavori di approfondimento potrebbero essere compiuti se-
guendo principalmente tre filoni. In primis, potrebbero essere implementate alcune modifiche alla
struttura del data warehouse per permettere la storicizzazione dei dati inseriti, e quindi evitare di
perdere le informazioni gi` presenti nel momento di un aggiornamento del data warehouse.
a
In secondo luogo, potrebbe essere possibile estendere le informazioni contenute in particolare nella
dimensione DimBusinessExecution, prevedendo la disponibilit` di dati relativi a BusinessEvent e
a
BusinessData, 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 quadro
informativo pi` completo di quanto sia disponibile ad oggi.
u
8.1 Le marche temporali
`
Allo stato attuale del progetto, non si e approfondito particolarmente il tema della dinamicit` , a
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 cui
`
l’evento si e verificato, il quale richiede l’inserimento di nuovi record nelle tabelle dimensionali
qualora i nuovi fatti lo richiedano. Potrebbe essere utile, per` , ai fini di fornire un’analisi compa-
o
rativa di diverse situazioni temporali, modificare la struttura del data warehouse per permettere di
tenere traccia di eventuali aggiornamenti nella fact table o nelle dimension tables, e di utilizzare
anche queste informazioni in sede di analisi.

47. 8.2 BusinessEvent e BusinessData
Uno sviluppo futuro potrebbe essere quello di considerare la possibilit` di integrare all’interno del
a
data warehouse le tabelle BusinessData e BusinessEvent, allo scopo di raffinare l’analisi relativa al-
la tabella BusinessExecution, le quali invece, per motivi di semplicit` , sono state omesse dall’attua-
a
le analisi. Questo processo riteniamo non comporti un carico di lavoro eccessivo, visto soprattutto
che 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 pi` precisa ed accurata classificazione delle BusinessExecution.
u
Come gi` accennato sopra, questa operazione richieder` : una nuova modellazione del diagramma
a a
degli 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, inserendo
queste 2 tabelle all’interno di una Dimension; il caricamento dei rispettivi valori all’interno delle
tabelle.
8.3 Compliance
Un ulteriore e possibile sviluppo futuro riguarder` l’analisi non solo relativa alle violazioni, ma
a
prender` in esame anche la compliance effettiva dei vari processi all’interno del caso di studio. Sar`
a a
quindi un’analisi della maggior parte degli aspetti di conformit` presenti all’interno di un business
a
process, con il risultato di ottenere e quindi di riuscire a sviluppare business compliance solutions.
La soluzione che verr` sviluppata consister` nel considerare l’entit` compliance allo stesso modo
a a a
dell’entit` violations, in modo da identificarla come un fatto in grado poi di permettere l’analisi e
a
lo studio delle proprie dimensioni; per completare questo processo di sviluppo sar` resa necessario
a
una migliore mappatura dei legami e delle relazioni tra il modello entit` relazione, il database e
a
il data warehouse. In questo modo sar` possibile ottenere e studiare l’intero processo da un altro
a
punto di vista, oltre naturalmente all’analisi tramite le violazioni, e cos` fornire un quadro sia di
ı
confronto che di ulteriore analisi all’intero caso oggetto di studio.

48. Riferimenti bibliografici
[Com(2008)] (2008). Compas - compliance-driven models, languages, and architectures for
services. [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 Business
Intelligence].
[Giorgini(2008b)] Giorgini P. (2008b). Entity relationship model. [Slide del corso di Database e
Business Intelligence].
[Giorgini(2008c)] Giorgini P. (2008c). Progettazione concettuale. [Slide del corso di Database e
Business Intelligence].
[Giorgini(2008d)] Giorgini P. (2008d). Progettazione logica. [Slide del corso di Database e
Business Intelligence].
[Golfarelli e Rizzi(2002)] Golfarelli M.; Rizzi S. (2002). Data Warehouse - teoria e pratica della
progettazione. McGraw-Hill, Milano.