Modulo Rappresentazione dell`Informazione

Università degli Studi di Milano-Bicocca
Facoltà di Scienze Matematiche, Fisiche e Naturali
Corso di Laurea Magistrale in Informatica
Rappresentazione
dell’Informazione e della Conoscenza
Modulo Rappresentazione dell’Informazione
Prof. Carlo Batini
Metodologie e Strumenti di Data Profiling
A cura di:
Carmine Carella 055465
Anno Accademico 2008-2009
Metodologie e Strumenti di Data Profiling
1|Pagina
1 Sommario
1
SOMMARIO ........................................................................................................................................................ 2
2
INDICE DELLE FIGURE ......................................................................................................................................... 4
3
INTRODUZIONE .................................................................................................................................................. 5
3.1
DEFINIZIONI .......................................................................................................................................................... 5
3.1.1 Olson Definizione .......................................................................................................................................... 5
3.1.2 TDWI Definizione........................................................................................................................................... 5
3.1.3 IBM Definizione ............................................................................................................................................. 5
3.1.4 DataFlux Definizione ..................................................................................................................................... 6
3.2
DATA PROFILING FONDAMENTALE PER IL PROACTIVE DATA QUALITY ................................................................................ 6
3.2.1 Reactive vs Proactive Data Quality ............................................................................................................... 6
3.2.2 Elementi per un Proactive Data Quality di Successo ..................................................................................... 6
3.3
RUOLO NEI PROGETTI DATA MANAGEMENT ................................................................................................................ 8
3.4
CAMPI DI APPLICAZIONE ........................................................................................................................................ 10
3.5
APPROCCI TRADIZIONALI VS APPROCCI AUTOMATICI ................................................................................................... 11
4
OLSON METODOLOGIA .....................................................................................................................................14
4.1
METODOLOGIA GENERALE ..................................................................................................................................... 14
4.1.1 Raccolta dei Metadati – Documented Metadata........................................................................................ 15
4.1.2 Estrazione dei Metadati – Discovered Metadata........................................................................................ 16
4.1.3 Analysis ....................................................................................................................................................... 18
4.1.4 Validation .................................................................................................................................................... 19
4.1.5 Data Profiling Repository ............................................................................................................................ 20
4.1.6 Mantenimento del Data Profiling ............................................................................................................... 20
4.1.7 Partecipanti al Processo di Data Profiling ................................................................................................... 20
4.2
METODOLOGIA DI DETTAGLIO ................................................................................................................................. 21
4.2.1 Column Property Analysis ........................................................................................................................... 22
4.2.1.1
4.2.1.2
4.2.1.3
4.2.2
Structure Analysis ....................................................................................................................................... 31
4.2.2.1
4.2.2.2
4.2.2.3
4.2.2.4
4.2.3
Definizioni ............................................................................................................................................................39
Il Processo per Simple Data Rule Analysis............................................................................................................41
Rules for Single Business Objects.........................................................................................................................43
Complex Data Rule Analysis ........................................................................................................................ 45
4.2.4.1
4.2.4.2
4.2.4.3
4.2.5
Il Processo di Structure Analysis ..........................................................................................................................33
Rules for Structure ...............................................................................................................................................35
Output Structure Analysis: Inaccurate Data Facts ...............................................................................................37
Sviluppare un Data Model ...................................................................................................................................38
Simple Data Rules Analysis ......................................................................................................................... 39
4.2.3.1
4.2.3.2
4.2.3.3
4.2.4
Definizioni ............................................................................................................................................................22
Il Processo per il Profiling Columns ......................................................................................................................25
Profiling Properties per i Campi ...........................................................................................................................26
Definizioni ............................................................................................................................................................45
Il Processo per il Profiling di Complex Data Rules ................................................................................................46
Profiling Complex Data Rules ...............................................................................................................................47
Value Rule Analysis ..................................................................................................................................... 49
4.2.5.1
4.2.5.2
Definizioni ............................................................................................................................................................49
Processo di Value Rule Analysis ...........................................................................................................................49
Metodologie e Strumenti di Data Profiling
2|Pagina
5
ALTRE METODOLOGIE .......................................................................................................................................51
5.1
BUSINESS DATA QUALITY LTD (BDQ) METODOLOGIA ................................................................................................. 51
5.1.1 Metodologia Generale ................................................................................................................................ 52
5.1.2 Metodologia di Dettaglio ............................................................................................................................ 54
5.2
THE DATA WAREHOUSING INSTITUTE (TDWI) METODOLOGIA ..................................................................................... 56
5.2.1 Metodologia Generale ................................................................................................................................ 56
5.2.2 Metodologia di Dettaglio ............................................................................................................................ 56
5.2.3 Le 4 Aree del Data Profiling......................................................................................................................... 57
5.2.4 Best Practices per il Data Profiling .............................................................................................................. 57
5.3
IBM METODOLOGIA............................................................................................................................................. 59
5.3.1 Metodologia Generale ................................................................................................................................ 59
5.3.2 Metodologia di Dettaglio ............................................................................................................................ 59
5.4
DATAFLUX METODOLOGIA..................................................................................................................................... 60
5.4.1 Metodologia Generale ................................................................................................................................ 60
5.4.2 Metodologia di Dettaglio ............................................................................................................................ 61
5.5
INFORMATICA (THE DATA INTEGRATION COMPANY) METODOLOGIA .............................................................................. 62
5.5.1 Metodologia Generale ................................................................................................................................ 62
5.5.2 Metodologia di Dettaglio ............................................................................................................................ 62
6
CONFRONTO TRA LE METODOLOGIE .................................................................................................................63
7
TOOLS PER IL DATA PROFILING .........................................................................................................................65
8
RIFERIMENTI PER I TOOLS: LINKS, DOCUMENTAZIONE E PAPERS ......................................................................70
9
BIBLIOGRAFIA ...................................................................................................................................................71
Metodologie e Strumenti di Data Profiling
3|Pagina
2 Indice delle Figure
Figura 1 - Modi di utilizzo del data profiling .................................................................................................... 10
Figura 2 - Vantaggi del profiling rispetto agli approcci tradizionali ................................................................. 11
Figura 3 - Confronto approcci tradizionali VS approcci automatici ................................................................. 12
Figura 4 - Approcci per determinare la qualità dei dati .................................................................................. 13
Figura 5 - Fasi della Metodologia Generale di Data Profiling .......................................................................... 14
Figura 6 - Architettura Generale Data Profiling ............................................................................................... 15
Figura 7 - Passi della metodologia di dettaglio di data profiling ..................................................................... 21
Figura 8 - Tipi di analisi per il data profiling.................................................................................................... 21
Figura 9 - Definizioni di column property analysis .......................................................................................... 22
Figura 10 - Processo di profiling columns ........................................................................................................ 25
Figura 11 - Esempio di business object............................................................................................................ 31
Figura 12 - Processo di structure analysis ....................................................................................................... 33
Figura 13 - Processo per analizzare le simple data rule .................................................................................. 41
Figura 14 - Processo per il profiling di complex data rules.............................................................................. 46
Figura 15 - Processo di value rule analysis ...................................................................................................... 49
Figura 16 - Processo di comprensione dei dati BDQ ....................................................................................... 51
Figura 17 - Stakeholders del data profiling...................................................................................................... 51
Figura 18 - Passi metodologia generale BDQ profiling .................................................................................... 52
Figura 19 - Tipi di analisi BDQ .......................................................................................................................... 54
Figura 20 - Esempio di Join Testing ................................................................................................................. 55
Figura 21 - Esempio di analisi dei metadati con dfPower Profile della DataFlux ............................................ 56
Figura 22 - Metodologia DataFlux ................................................................................................................... 60
Figura 23 - Metodologia di dettaglio Informatica ........................................................................................... 62
Metodologie e Strumenti di Data Profiling
4|Pagina
3 Introduzione
L’attività di data quality (DQ) è supportata da molte tecnologie, tra cui data monitoring, data cleansing,
data filtering e data profiling. Il data profiling (DP) è la principale tecnologia per la data accuracy.
I dati all’interno di un organizzazione supportano ogni genere di attività, dal più semplice processo di
business alla decisione strategica più importante. Il loro valore è maggiore se essi sono accurati, completi e
consistenti. La qualità della “risorsa” dati deve sempre essere tenuta sotto controllo in quanto ha un reale
impatto sui profitti e sull’attività aziendale di decision-making.
Una recente inchiesta del Data Warehousing Institute ha stabilito che la scarsa qualità dei dati costa agli
affari americani circa $600bn l’anno dovuti a:
•
•
•
investimenti persi in sistemi che non ritornano benefici concreti
eccessivo overhead di processi basati su dati che non sono adatti allo scopo (not fit for purpose)
decisioni di business sbagliate basate su dati inaccurati e incompleti
La necessità di analizzare i dati è stato alla base di ogni efficiente strategia di data management sin dall’alba
dei moderni sistemi informativi. Il data profiling permette una profonda e ampia analisi in un tempo molto
minore rispetto agli approcci tradizionali di analisi dati.
3.1 Definizioni
3.1.1 Olson Definizione
Il data profiling è definito come l’applicazione di tecniche di analisi dei dati a data source esistenti con lo
scopo di determinare il contenuto, la struttura e la qualità dei dati. Questa tecnologia è focalizzata su
l’estrazione di informazioni relative ai dati stessi, anziché di informazioni di business derivabili dai dati.
Le informazioni in output sono utili per poter utilizzare i dati in modo corretto ed efficiente al di fuori del
contesto delle applicazioni originali.
3.1.2 TDWI Definizione
Il data profiling è il processo di esaminare i dati memorizzati in data source esistenti (ad esempio, un
database o un file) e di raccogliere statistiche e informazioni relative ad essi. L’utilità di queste statistiche è:
scoprire se i dati esistenti possono essere facilmente utilizzati per altri scopi, fornire metriche relative alla
qualità dei dati e gli standard, valutare la fattibilità per l'integrazione dei dati in nuove applicazioni, e
valutare se i metadati descrivono con precisione i valori attuali presenti nel data source.
Il profiling può essere eseguito sia con metodi manuali che con tool semplici o complessi che automatizzano
l’attività.
3.1.3 IBM Definizione
Il data profiling è il processo analitico con il quale si esamina il contenuto di un database e si raccolgono
statistiche e informazioni sui dati per scoprire la struttura, il contenuto e la qualità dei dati.
Metodologie e Strumenti di Data Profiling
5|Pagina
3.1.4 DataFlux Definizione
Il data profiling è il primo passo in un processo di DQ che permette di esaminare la struttura, le relazioni e il
contenuto di data source esistenti per ottenere una descrizione precisa dello stato dei dati. Determinare lo
stato corrente dei dati aiuta a pianificare le corrette azioni per migliorare la qualità delle informazioni
aziendali.
3.2 Data Profiling fondamentale per il Proactive Data Quality
Per assicurare la qualità dei dati che supportano le iniziative di business, le aziende stanno adottando
sempre più processi per analizzare la qualità e mantenerla nel tempo. Un modo per comprendere e
risolvere i problemi di DQ è il data profiling.
3.2.1 Reactive vs Proactive Data Quality
Esistono due tipi di approcci con i quali le aziende effettuano DQ:
•
•
Reactive DQ: questo tipo di approccio è caratterizzato dalla tendenza di reagire ai problemi di DQ
dopo che sono stati scoperti. Non si ha una chiara idea di come è definita la qualità a causa delle
mancanza di documentazione sulle DQ rules. Inoltre i problemi di DQ non sono sistematicamente
registrati.
Proactive DQ: questo tipo di approccio è caratterizzato dalla comprensione di cosa vuol dire qualità
attraverso la definizione delle specifiche per determinare se un dato è di buona qualità (DQ rules) e
come usare tali specifiche per analizzare i dati. Con questo approccio i problemi di DQ sono noti
prima che abbiano un impatto disastroso sul business, aumentando così la fiducia nei dati da parte
degli utenti e supportando meglio le decisioni di business.
3.2.2 Elementi per un Proactive Data Quality di Successo
Elenchiamo alcune caratteristiche chiave di un buon progetto di proactive DQ:
•
•
•
Collaborare con gli esperti di business: la forte collaborazione degli esperti di business in un
progetto di DQ prende il nome di data stewardship. I data steward sono gruppi di esperti di
business che conoscono il significato dei dati e li utilizzano quotidianamente. Appartengono alle
diverse aree di business aziendale come finanza, marketing, ecc. e hanno la responsabilità per i
data elements di interesse e forniscono informazioni su i propri dati (metadati) come definizioni (di
data elements), derivazioni (come il dato è calcolato), DQ rules (quando è considerato di buona
qualità) e il dove si trovano i dati originari (potrebbero essere in più posti).
Supporto di esperti IT: il supporto degli esperti IT è necessario in quanto a volte capire i dati e
capire come essi sono derivati implica studiare le applicazioni che li utilizzano, che sono mal
documentate. Inoltre anche i tool di DP e i metadata repository necessitano del loro supporto
Ottenere e utilizzare i DQ metadati: è importante definire i protocolli e i relativi tool di supporto
per memorizzare i metadati. I metadati includono molte informazioni come definizioni, derivazioni,
DQ rules ma anche i risultati dell’analisi e i feedback degli esperti di business. Conoscere anche la
storia dei dati è importante, ovvero sapere cosa è stato fatto ai dati durante il loro viaggio (lineage),
se è stato manipolato, convertito può aiutare a definire più facilmente le DQ rule. I processi ETL
possono combinare i metadati lineage da loro prodotti con i risultati del profiling e offrire molti
vantaggi. È un dato di fatto che gli sviluppatori di tool ETL per assicurarsi che il loro codice funzioni,
effettuano una forma semplificata di profiling (data inspection) ma i risultati del data inspection
Metodologie e Strumenti di Data Profiling
6|Pagina
•
•
sono raramente condivisi o memorizzati formalmente per usi futuri. Una formale attività di data
profiling può far risparmiare l’attività preliminare di data inspection nei processi ETL.
Memorizzare i metadati: tutti metadati, sia quelli relativi alla qualità, prodotti dal profiling sia
quelli relativi al lineage dei dati prodotti dai tool ETL devono essere memorizzati in un metadata
repository per essere condivisi dagli analisti e dagli altri utenti dei dati.
DQ Rules: le data quality rule sono la risposta alla domanda: quando i dati diventano di scarsa
qualità, come facciamo a saperlo? Gli utenti che lavorano con i dati quotidianamente e che
riconoscono che qualcosa non va in essi, senza saperlo applicano le DQ rule. Alcuni esempi di rules
sono:
Il campo è obbligatorio e quindi deve per forza esserci un valore (identificatori),
Il campo deve avere solo certi valori (campo sesso di una persona),
Il valore nel campo deve essere conforme a un certo pattern di numeri e lettere (numero
telefono),
Il campo deve avere un certo data type e range
Ci deve essere una relazione tra uno o più campi di record differenti nella stessa tabella o in
tabelle diverse.
Le DQ rule possono essere dettate dai data steward e validate sui dati e/o possono essere estratte dai dati
utilizzando un tool e poi verificate da esperti di business. Entrambe sono attività tipiche della pratica del
data profiling.
Metodologie e Strumenti di Data Profiling
7|Pagina
3.3 Ruolo nei Progetti Data Management
Nei progetti di reingegnerizzazione dei sistemi informativi aziendali, utili per renderli più efficienti e aperti
all’integrazione con altri sistemi, si ha la necessità di muovere le applicazioni su database più moderni o
consolidare databases di diverse applicazioni. Tutto questo introduce la gestione di nuove e differenti
interfacce e l’interazione tra dati di differenti divisioni dell’azienda o di sorgenti esterne. Le difficoltà
nell’eseguire tali progetti non sempre portano ai risultati desiderati, con un rilevante spreco di denaro e
tempo. Sebbene ci siamo molte ragioni per questi risultati deludenti, il principale problema è la scarsa
comprensione dei dati.
Molti dei paper presi come riferimento parlano del data profiling come una tecnologia inserita in un
contesto di più ampio respiro, come una importante fase di una metodologia data-driven come può esserlo
un progetto di:
•
•
•
•
data quality improvement
data integration
data warehousing
master data management
Il data profiling dovrebbe essere il primo passo in ogni progetto data-driven, per analizzare i data source
con lo scopo di raccogliere le informazioni necessarie a scoprire i dati, le loro strutture e valutarne la
qualità. Non effettuare il data profiling si traduce in probabili complicazioni nei passi successivi dei progetti
o addirittura in un fallimento netto. Inoltre solo una completa e regolare analisi dei dati può identificare
tutti i possibili problemi prima che essi diventino ingestibili e si rivelino quando ormai risolverli è troppo
costoso.
Ad esempio un articolo TDWI analizzato cita a sua volta un altro articolo del TDWI del 2002 intitolato “data
quality and the bottom line”, descrive la metodologia di nove passi per assicurare dati di alta qualità. Il data
profiling è uno di questi nove passi. I primi tre si focalizzano su tematiche di organizzazione come sviluppo
di piani di progetto, pianificazione delle strategie di data quality e costruzione di data quality team. I
successivi tre passi si occupano dell’analisi di business practice, architetture dati, data sources con
tenologie quali data profiling, data validation, data cleansing, data standardization, data matching, ecc. Il
passo finale riguarda le decisioni da prendere in base alle informazioni acquisite dai passi precedenti:
pulizia dei dati, monitoraggio data quality, ecc.
Un progetto di DQ richiede una combinazione di processi, tecnologie ed esperti. I problemi di DQ non
possono essere superati con una sola tecnologia.
La gestione della data quality è un processo integrato e complesso, per questo esistono dei tool di
automazione che assistono ogni fase del processo. Questi tool devono avere un alto grado di integrazione
per garantire l’obiettivo finale di un processo di data quality. Ad esempio un tool di data profiling deve
rendere disponibili i propri metadati ad un tool di data cleansing in modo che possa applicare le regole
senza ripetere la raccolta dei metadati per risolvere gli errori velocemente.
Mentre è essenziale avere una tecnologia per supportare qualunque iniziativa di DQ, avere un’ appropriata
metodologia per utilizzare la tecnologia è ancora più importante.
Metodologie e Strumenti di Data Profiling
8|Pagina
Risolvere i problemi di qualità nella fasi iniziali di un processo data management
Sembra che nel “mondo dei dati” le buone regole per mitigare i rischi nelle iniziative data-driven siano
quasi sempre dimenticate, un lavoro di analisi dati a priori potrebbe durante i progetti evitare cattive
sorprese nella conoscenza dei dati, eliminando problemi che devono essere risolti in corso d’opera con
meno facilità. Ad esempio ci si può trovare di fronte a campi carattere che contengono numeri, chiavi che si
riferiscono a record inesistenti, campi che esprimono il sesso di una persona con 5 valori distinti, record di
ordini con prezzi negativi, ecc.
Una pratica comune denominata da un esperto di data warehousing “code, load and esplode”, descrive
questa cattiva abitudine nel mondo dei dati: in corso d’opera una volta scoperte le irregolarità, un pool di
esperti applica le nuove regole per correggerle, si riesegue il processo e nuovamente si scoprono altri
“cattivi” dati che necessitano di altre regole. Tutto questo porta ad un ciclo senza fine che aumenta i costi e
i tempi dei progetti.
Il fenomeno del code, load and explode influenza molti e diversi progetti e la prima causa di tutto questo e
la poca comprensione dei dati e la sottovalutazione dei problemi di scarsa qualità che se non risolti in
anticipo portano ritardi e fallimenti nei progetti.
Lo strumento per l’individuazione anticipata dei problemi di qualità è il data profiling che è più efficace se
effettuato nelle fasi di requisiti e analisi di qualunque progetto.
Infine, le informazioni accurate relative ai dati, ottenute dal processo di data profiling possono anche
essere utilizzate per creare una knowledge base ed effetture il reasoning su di essa.
Vantaggi del data profiling
Alcuni vantaggi nell’adottare la tecnologia di data profiling:
migliora la pianificazione dei progetti data-driven
mitiga il rischio di effettuare cambiamenti nelle fasi finali di un progetto
si basa su un processo robusto e iterativo supportato da tool e metodologie
la conoscenza in anticipo dei problemi di qualità, permette di scrivere casi di test migliori e
risparmiare tempo nella comprensione del motivo per cui i test falliscono
fornisce un completo insieme di informazioni valide sui dati (metadati)
rileva gli errori nei dati prima che essi vengano integrati con altri (data warehouse) durante la fase
di load
permette di definire gli obiettivi di business come raggiungibili o non raggiungibili
permette un migliore project planning di risorse (umane e di tempo)
Metodologie e Strumenti di Data Profiling
9|Pagina
3.4 Campi di Applicazione
Il profiling può essere utilizzato per migliorare l’accuratezza a diversi livelli come mostrato in figura 1
Figura 1 - Modi di utilizzo del data profiling
Il data profiling può mostrare le carenze dei dati presenti nel data source e consigliare un progetto di
miglioramento della qualità per aumentarne l’accuratezza.
Può essere utilizzato per definire correttamente i processi di dati ETL (Extraction/Trasformation/Load) che
muovono i dati su altri sistemi.
Il profiling può aiutare nella costruzione corretta di EAI Systems (Enterprise Application Integration)
risolvendo i problemi di traduzione e inconsistenza tra i sistemi partecipanti.
Inoltre, può essere utilizzato nei progetti di migrazione per definire in modo corretto il sistema di
destinazione. Quando questo è predefinito, ad esempio un ERP System (Enterprise Resource Planning), il
data profiling è la base per il mapping accurato di attributi, strutture e valori sul nuovo sistema e permette
di individuare tutte le differenze che non vengono risolte a livello dei dati e richiedono interventi esterni.
Infine, il profiling è utilizzato per correggere l’uso dei dati. Molto spesso i dati sono corretti e gli utenti non
comprendono il contenuto e il significato e li utilizzano nel modo sbagliato.
Metodologie e Strumenti di Data Profiling
10 | P a g i n a
3.5 Approcci Tradizionali vs Approcci Automatici
I metodi tradizionali (tecniche manuali o semi-automatiche) di analisi dati impiegano molto tempo anche su
piccoli campioni e non permettono una completa comprensione dei data source. Le tecniche manuali o
semi-automatiche non possono confrontare i milioni di attributi e valori. La risposta è una nuova categoria
di software chiamata data profiling che offre una comprensione dei dati veloce, accurata e automatica.
Inoltre permette ad un piccolo team di persone con capacità tecniche e di business di eseguire compiti
complessi per ottenere una profonda comprensione dei dati.
“Craig Olson Data Management Review, March 2000”
Il data profiling migliora l’accuratezza dell’analisi dati offrendo:
•
•
•
automazione di tecniche di analisi tradizionali: riduzione del tempo di analisi del 90% con una
comprensione maggiore dei dati
capacità di applicare approcci brute force all’analisi. Gli analisti non sono limitati nel lavorare solo
con campioni di dati. Terabytes di dati possono essere sottoposti a profiling in modo efficiente e
completo
valutazione delle regole che governano i dati che non possono essere facilmente scoperte con
tecniche manuali e ispezione
La tecnologia del data profiling migliora le attività che vengono eseguite sui dati riducendo i rischi, i costi e
le tempistiche.
Figura 2 - Vantaggi del profiling rispetto agli approcci tradizionali
Migliorare la qualità dei dati vuol dire ottenere una migliore comprensione dei dati e delle regole che li
governano. Senza queste informazioni nessun data management plan può essere sviluppato. Il data
profiling fornisce sia il framework e sia la roadmap per migliorare la data quality, per rendere i processi di
business più efficienti e migliorare le performance dell’azienda stessa.
Metodologie e Strumenti di Data Profiling
11 | P a g i n a
Figura 3 - Confronto approcci tradizionali VS approcci automatici
Approcci Tradizionali
•
•
•
•
Nessuna centralizzazione dell’informazione
Tools diversi applicati ad hoc per svolgere le
attività di analisi
Aumento overhead data management
Aumento dei rischi e del carico di lavoro
Approcci Automatici
•
•
•
•
Singolo punto di accesso alle informazioni
Tools definiti e integrati
Riduzione overhead di data management
Miglioramento affidabilità e riduzione dei rischi
Limiti degli approcci tradizionali di profiling
Esistono diversi approcci manuali per valutare la qualità dei dati , ma rispetto ai tool automatici di profiling
hanno dei limiti:
•
•
•
Scoprire gli errori troppo tardi: malgrado la crescente importanza di questo tema si tende sempre a
identificare problemi di data quality troppo tardi, quando ormai sono evidenti nel nuovo sistema e
provocano un perdita di fiducia nei dati da parte degli utenti o addirittura nei casi più estremi il
malfunzionamento.
Metadati non attendibili: per fornire una descrizione del contenuto dei data source, si utilizzano
cataloghi (metadati) associati al sistema. Questi cataloghi sono notoriamente non affidabili: ad
esempio gli sviluppatori del sistema potrebbero non aver creato cataloghi per documentare il
contenuto e aver lasciato la compagnia e quindi la conoscenza è andata perduta. In generale i
cataloghi anche se esistenti raramente sono aggiornati. L’introduzione di errori nei sistemi è molto
frequente e siccome non influenzano il processo operazionale giorno per giorno si pensa che tutto
vada bene. Ma poi vengono a galla in progetti di integrazione in cui si scopre ad esempio che due
campi apparentemente identici non combaciano in quanto un campo può al suo interno aver
rappresentato più di un fatto, contrariamente alla descrizione presente nella documentazione.
Poco accurati: Questi metodi tendono a non essere esaustivi e non rilevano tutti i possibili errori.
Un tipico metodo manuale è la creazione di query SQL per analizzare i data source. Con una query
SQL vengono analizzati i dati utilizzando i campi più importanti ma non è sufficiente a dare una
comprensione completa. Inoltre dipende dalla capacità dell’analista di scrivere buone query SQL e
di capire bene il sistema per determinare in anticipo cosa cercare.
Metodologie e Strumenti di Data Profiling
12 | P a g i n a
Figura 4 - Approcci per determinare la qualità dei dati
Approcci Automatici di Data Profiling
I tool automatici di data profiling superano i limiti degli approcci manuali:
•
•
•
•
•
•
•
•
•
•
Permettono una comprensione completa dei dati, l’identificazione accurata dei problemi di qualità
e minimizzano i rischi nei progetti di integrazione dovuti alla scarsa qualità rispettando il budget e i
tempi.
Analisi esaustiva. Permettono di analizzare ogni singolo campo di ogni record in ciascuna tabella del
data source.
Generano report completi e dettagliati di statistiche e diagrammi che permettono la rilevazione dei
problemi in modo più immediato.
Permettono una buona comprensione della struttura del sistema di destinazione, il range e la
distribuzione dei valori in ciascuna campo e le relazioni tra i campi di una tabella o di diverse
tabelle.
Tecnologia Drill-Down per spostarsi da una vista sommaria dei dati ad una vista dettagliata dei
valori che necessitano di attenzione.
Accelerano il processo di analisi dei dati.
Permettono di analizzare data source di grandi dimensioni e in modo accurato
Una compagnia può utilizzare i tool non solo nell’analisi a priori per i progetti di integrazione, ma
anche per verificare periodicamente la qualità dei database esistenti e avere dei dati affidabili su
cui basare il processo decisionale.
Smascherano le inconsistenze nei processi di business;
Eliminano le figure degli esperti IT come intermediari tra i dati e gli esperti di business, in quanto i
tool sono progettati per essere facilmente utilizzabili da utenti che non hanno competenze
tecniche. Quindi un esperto di business può in un solo task acquisire i risultati e analizzarli, al
contrario di quello che succede con le tecniche manuali in cui un esperto IT genera ed esegue le
query SQL e poi consegna i risultati al business analyst per la valutazione. Comunque gli esperti IT
non vengono totalmente estromessi, poiché per analisi di molti data source con milioni di record
c’è bisogno di una squadra di esperti che generi i report identificando le aree di maggiore interesse
e velocizzi il lavoro.
Metodologie e Strumenti di Data Profiling
13 | P a g i n a
4 Olson Metodologia
4.1 Metodologia Generale
La figura 2 mostra le principali fasi della metodologia generale di data profiling.
Figura 5 - Fasi della Metodologia Generale di Data Profiling
La prima fase è l’identificazione del data source (database, file o altro) che contiene i dati e delle procedure
di accesso all’informazione.
La fase più difficile è quella di raccolta dei metadati e di estrazione dei dati. Sia i metadati sia i dati stessi
costituiscono l’input del profiling.
Come mostra la Figura 6 - Architettura Generale Data Profiling il processo prende in input i metadati
raccolti da tutta la documentazione esterna e i metadati ricavati analizzando i dati stessi. In output viene
generato un insieme di metadati accurati frutto del confronto tra gli insiemi di metadati in ingresso e
vengono rilevati i dati inaccurati attraverso le violazioni che occorrono nei dati rispetto ai metadati accurati
calcolati precedentemente.
Il data profiling non può trovare tutti i possibili dati inaccurati, ma soltanto le violazioni alle regole
identificate.
Metodologie e Strumenti di Data Profiling
14 | P a g i n a
La figura 3, mostra l’architettura generale di data profiling dal punto di vista dell’ input/output.
Figura 6 - Architettura Generale Data Profiling
4.1.1 Raccolta dei Metadati – Documented Metadata
Secondo una definizione molto generale, i metadati sono dati che descrivono le caratteristiche dei dati.
I metadati rappresentano quella parte delle informazioni sui dati provenienti da fonti esterne quali dizionari
dei dati, documentazione di progetti precedenti, interviste con sviluppatori e progettisti e altre sorgenti che
mettono in luce il significato dei dati che devono essere analizzati. Chiamiamo questi metadati
“documented metadata”. Tale termine è utilizzato nel seguito per riferirsi a queste informazioni.
Tutte queste informazioni sono di solito non perfette (inaccurate e incomplete) e bisognerebbe
approcciarsi ad esse con sospetto, in quanto nel tempo la loro correttezza potrebbe essersi deteriorata. I
fattori che contribuiscono a questo sono la scarsa documentazione esistente su: i cambiamenti effettuati al
sistema, sulla struttura dei dati, su particolari convenzioni per le codifiche e su informazioni di qualità.
Se i documented metadata fossero accurati e completi, tutto quello che bisognerebbe fare è confrontare i
dati con i metadati e qualunque violazione costituirebbe fatti di inaccuratezza.
I documented metadata possono essere reperiti da tutte le forme di documentazione esistenti che siano
diverse dai dati stessi:
•
analizzando le interfacce di programmi che forniscono dati al data source, che possono aggiungere
informazioni preziose sui dati che vengono persistiti.
•
recuperando qualunque descrizione dei dati disponibile in dizionari, repositories di metadati e altre
forme di documentazione.
•
esplorando il codice sorgente di applicazioni che manipolano i dati. Il codice può rivelare molte
informazioni sulla codifica, sulla gestione delle regole di business e su altre situazioni che
dall’esterno non sono ovvie.
L’estrazione di informazioni dal codice sorgente può essere sia manuale che automatica, con
software appositamente dedicati. In entrambe le modalità raramente viene eseguita, per diversi
motivi:
Metodologie e Strumenti di Data Profiling
15 | P a g i n a
il codice può essere scarsamente documentato
la dimensione del codice sorgente può essere molto grande e l’estrazione impiegare molto
tempo
lo staff tecnico che esegue l’estrazione può non avere la conoscenza dei linguaggi di
programmazione con cui sono scritti i programmi, ad esempio Cobol
•
cercando regole all’interno di processi esterni : alcune data rules possono essere inserite in
processi aziendali più che in programmi o database.
4.1.2 Estrazione dei Metadati – Discovered Metadata
I dati rappresentano la più utile sorgente di informazione sui dati stessi. Mentre i documented metadata
sono spesso poco accurati e poco completi per il fatto che provengono da fonti esterne poco documentate,
i dati possono soltanto fornire informazioni accurate e complete che non possono essere trovare in altre
sorgenti. Questo è particolarmente vero per le informazioni sulla qualità, che non è mai documentata al di
fuori dei dati.
L’obiettivo di questa fase è estrarre i dati dal data source per analizzarli e produrre i metadati che
descrivono le loro caratteristiche. Chiamiamo questi metadati “discovered metadata”. Tale termine è
utilizzato nel seguito per riferirsi a queste informazioni.
I discovered metadata possono essere estratti:
•
analizzando i campi dei record nelle relazioni del database. Come questo viene fatto dipende dal
tipo di data source, ad esempio in un database relazionale queste informazioni potrebbero essere
estratte da un catalogo.
•
estraendo informazioni strutturali disponibili nel DBMS, ad esempio nel caso relazionale, chiavi
primarie, chiavi esterne e altri vincoli referenziali.
Campionamento
L’estrazione può interessare tutti i dati presenti nel data source oppure un sottoinsieme.
L’estrazione di tutti i dati è chiaramente preferibile all’estrazione di un sottoinsieme, in quanto viene
definita meglio la realtà rappresentata nel data source e soprattutto è garantita la completezza dei
discovered metadata.
Ma, per molti data source misurati in centinaia di righe, usare tutti i dati rende proibitiva l’esecuzione
dell’analisi, questo aggravato dal fatto che il data profiling di solito non è eseguito con supercomputer.
Quando le dimensioni dei data sources sono considerevoli l’utilizzo di sottoinsiemi è preferito purchè siano
rappresentativi di tutti i dati. Questi sottoinsiemi prendono il nome di campioni di dati, che vengono
estratti attraverso tecniche di campionamento studiate nel campo statistico .
Il campionamento è un argomento complesso che influenza l’accuratezza del processo di profiling. In
questo contesto non descriviamo la vasta area del campionamento e delle sue tecniche. Diciamo solo che
se non eseguito bene, il campionamento può portare all’estrazione di record che rappresentano solo una
parte della popolazione dei dati oppure di record che violano le regole strutturali. Il campionamento
Metodologie e Strumenti di Data Profiling
16 | P a g i n a
dovrebbe essere usato solo quando i passi del processo di profiling lo richiedono, ad esempio quando i data
sources sono di grandi dimensioni.
Un vantaggio dell’analisi sui campioni è che riduce il tempo impiegato nell’esecuzione dell’ attività di analisi
che richiede molte risorse, tra cui un intenso lavoro della cpu che può rallentare le prestazioni di un
normale elaboratore che esegue altri task. La fase di estrazione dei dati dovrebbe essere automatizzata da
routine di estrazione.
Trasformazione
Un altro obiettivo di questa fase è la trasformazione dei dati dalla quale si otterrà una nuova
rappresentazione dei dati in una forma adatta ad eseguire il data profiling.
Il profiling richiede una forma tabellare e normalizzata dei dati; infatti per ottenere un risultato corretto il
profiling dovrebbe essere effettuato con dati nella terza forma normale, ma è possibile anche con la prima
e seconda forma.
Contenuto dei Discovered Metadata
Con i discovered metadata possono essere raccolte informazioni sul contenuto e la struttura del data
source:
Alcune informazioni sul contenuto:
Nome e descrizione testuale (business meaning) di attributi
Data type utilizzati
Restrizioni di lunghezza sui valori degli attributi
Precisione di attributi numerici (ad esempio posti decimali)
Valori minimo e massimo degli attributi
Descrizione delle convenzioni per i valori null
Pattern utilizzati nella rappresentazione dei valori
Alcune informazioni sulla struttura:
Dipendenze funzionali tra gli attributi
Chiavi primarie contenute nel data source
Coppie di chiavi esterne/primarie che realizzano le relazioni del data source
Attributi ridondanti nelle relazioni
La comprensione della struttura dei dati, può essere verificata con il business analyst (ogni relazione può
essere tradotta in termini di business) che può indicare se è completa oppure non ha senso. Scoprire le
relazioni strutturali, senza un adeguato strumento di supporto può essere molto difficile in quanto molti
Metodologie e Strumenti di Data Profiling
17 | P a g i n a
vecchi sistemi sono costruiti su DBMS che non hanno alcun controllo sulle relazioni strutturali. Quindi anche
violazioni alla chiave primaria possono verificarsi in sistemi dove l’unicità dei valori non è controllata.
4.1.3 Analysis
Questa è la fase in cui i documented metadata e i discovered metadata vengono confrontati per individuare
le differenze e produrre un insieme di accurate metadata che descrivono le proprietà che dovrebbero
avere i dati per essere considerati di buona qualità. Sono essenziali per determinare l’inaccuratezza, infatti
vengono utilizzati per definire ciò che è esatto e determinare quello che è errato. Questi sono il primo
output del data profiling.
Il data profiling generà il più completo e accurato insieme di informazioni per i dati.
Inoltre in questa prima analisi dei dati possono essere individuati problemi di bad practice nei dati.
Alcuni problemi di bad practice sono: overloaded fields, redefines e repeating arrays. Molto spesso queste
scelte progettuali non sono documentate. Molte scelte non vengono documentate a causa dei
cambiamenti dell’ultimo minuto effettuati dagli sviluppatori quando il sistema è quasi operativo, ovvero
viene effettuata la modifica e non viene documentata, rendendo meno chiaro il sistema e perdendo traccia
di tale modifica che risulterà incomprensibile nel futuro.
Analizziamo in dettaglio queste pratiche comuni.
•
Overloaded fields: un overloaded field è un campo di un record che contiene al suo interno
informazioni di fatti differenti . Un esempio di overloaded field è quello che a volte si verifica nello
sviluppo di applicazioni dove spesso si ha la necessità di avere campi che rappresentino valori
booleani; per non creare un nuovo campo e risparmiare spazio di memorizzazione, si utilizzano dei
bit non utilizzati di campi esistenti. Questi bit potrebbero essere i bit di segno di campi numerici che
non assumeranno mai valori negativi. Un altro esempio è quando si utilizza ciascun bit di un singolo
byte per rappresentare i valori di campi binari diversi. Un esempio più pratico è relativo ad un
campo NOME che contiene il carattere *DECEDUTO. Il campo può esprimere due fatti dirrenti, il
valore Mario Rossi indica che questa persona è viva e il valore Mario Rossi *DECEDUTO indica che la
stessa persona non vive più. Il problema con gli overloaded fields è che di solito non sono mai
documentati, così nei progetti di migrazione dati gli analisti non si accorgono di tali campi e tutti o
alcuni valori all’interno vengono trasformati oppure eliminati perdendo le informazioni di ciascuno
dei fatti differenti registrati nel campo. Per individuare gli overloaded fields bisogna controllare
ogni campo e la documentazione disponibile e quando identificato bisogna dividere il campo
overloaded per rappresentare i diversi fatti con più campi.
•
Redefines: è un campo che viene utilizzato per rappresentare un fatto per alcuni record e un fatto
differente per altri record, il significato dell’attributo dipende dal valore di altri campi.
•
Repetitive arrays: records che potrebbero rappresentare più occorrenze dello stesso business fact,
devono essere analizzati per verificare se rappresentano fatti distinti.
Le decisioni sulle normalizzazioni di redefines e ripetitive arrays sono semantiche e non possono essere
determinate guardando solo alla definizione dei dati, ma potrebbe essere necessario consultare un
business analyst per poter interpretare l’obiettivo di quella particolare struttura dati.
Metodologie e Strumenti di Data Profiling
18 | P a g i n a
4.1.4 Validation
Questa fase consiste nel confrontare gli accurate metadata con i dati per identificare tutte le violazioni alle
proprietà descritte in questi metadati. Tali violazioni sono proprio gli Inaccurate Data Facts che identificano
i problemi di DQ presenti nei nostri dati.
Più problemi di DQ vengono scoperti nella fase di profiling, più corretto sarà l’uso dei dati nei processi
successivi. Una volta individuati i problemi di qualità si possono pianificare delle fasi di miglioramento per
risolvere i problemi.
Alcuni problemi di DQ che possono essere identificati sono:
Attributi utilizzati per scopi differenti rispetto all’obbiettivo originale.
Attributi che non sono utilizzati (non contengono alcun valore al loro interno).
Valori che non rientrano nel range del campo in cui sono memorizzati.
Campi di testo, che spesso contengono valori non validi a causa di errori di digitazione
Inconsistenze dei dati, che possono avere due forme:
1. Inconsistenze nella rappresentazione dovute ai molti modi di rappresentare lo stesso fatto
in un singolo attributo, utilizzando caratteri di separazione diversi, caratteri minuscoli e
maiuscoli e anche abbreviazioni. Cosi ad esempio lo stesso numero di telefono può essere
rappresentato con un trattino separatore 02-345… o senza 02345…
2. Inconsistenze dovute alle modifiche per portare i valori ad un livello di granularità
maggiore, cosi che i valori già memorizzata rimangono al vecchio livello e i nuovi invece
assumono il livello appena definito.
Convenzioni per i valori null. Le convenzioni potrebbero variare passando da un attributo a un altro,
o perfino all’interno dello stesso attributo. Cosi per indicare un valore null si potrebbero utlizzare
convenzioni non supportate dal DBMS quali ?, N/A, **not known**, -unknown- e altri.
Metodologie e Strumenti di Data Profiling
19 | P a g i n a
4.1.5 Data Profiling Repository
Le informazioni accurate ottenute dal processo di profiling (metadati e facts) devono essere memorizzate in
un data profiling repository, che deve mantenere nel tempo l’accuratezza dei dati e garantire essa a fronte
di frequenti aggiornamenti, cambiamenti e ripetute applicazioni del processo di profiling.
Per data profiling repository si intende il luogo in cui registrare tutte le informazioni usate e derivate dal
processo di data profiling; il repository può essere fornito direttamente dal software di profiling oppure può
essere separato da esso, scegliendo una soluzione già esistente oppure progettando la propria. Il
repository dovrà contenere informazioni di vario tipo.
Le informazioni dovrebbero essere registrate in un formato comune per facilitare la gestione di dati
provenienti da diversi data source. Al completamento del processo di profiling tutte o alcune informazioni
possono essere trasferite in un enterprise repository .
Il data profiling è utilizzato con differenti data sourcers, tra cui database relazionali o files.
4.1.6 Mantenimento del Data Profiling
Una volta che il data profiling è stato eseguito, può essere utilizzato per tutti i progetti che necessitano
attingere ai dati del data source. Il profiling dovrebbe essere aggiornato periodicamente man mano che
nuove informazioni sono scoperte e anche per registrare e controllare i cambiamenti sul sistema che come
è noto hanno un’alta probabilità di generare dati non accurati.
Inoltre il profiling deve essere rieseguito per verificare l’efficacia dei rimedi adottati ai problemi di qualità.
Molte figure possono accedere al profiling per eseguire i loro compiti: data architets, application designer,
business analyst e users.
4.1.7 Partecipanti al Processo di Data Profiling
Il data profiling di solito viene effettuato da una squadra di data analyst o da un singolo analyst, ma ci sono
anche altri partecipanti che aggiungono valore al processo.
Il data analyst è una figura che fa parte di un team di data quality assurance e possiede le conoscenze
relative a strutture, architetture e modelli di dati e tecniche di analisi. Non si occupa dell’interpretazione
semantica dei dati per gli obiettivi di business. A questo scopo, il data profiling analyst è affiancato da un
business analyst che ha la conoscenza delle regole di business.
Questa collaborazione è fondamentale nella raccolta delle informazioni sui dati (metadati e dati).
La collaborazione può avvenire in due modi:
il data analyst scopre, attraverso tecniche di analisi, le caratteristiche dei dati e il business analyst
cerca di interpretarle
il business analyst definisce le caratteristiche che i dati dovrebbero avere e il data analyst utilizza
tecniche di analisi per verificarle sui dati
le capacità del data analyst e del business analyst e il loro grado di collaborazione influenza l’accuratezza
del risultato del processo di profiling.
Altre figure utili sono i membri dello staff IT (designer e developer application) che progettano e
implementano le applicazioni, il database administrator, che può aiutare nella comprensione di alcuni
problemi strutturali che possono emergere nel processo di profiling.
Metodologie e Strumenti di Data Profiling
20 | P a g i n a
4.2 Metodologia di dettaglio
La necessità di una metodologia di dettaglio per il data profiling nasce per rendere più efficace il processo
nel raggiungere gli obiettivi. La metodologia di dettaglio fornisce una logica progressione dell’analisi che
permette di costruire le informazioni da un livello al successivo.
La metodologia data profiling di dettaglio utilizza un approccio bottom-up. Parte dal livello dei dati più
atomici muovendosi progressivamente ai livelli più alti delle strutture dati.
La figura 2 mostra i principali passi della metodologia di dettaglio. Ciascun passo si focalizza su uno specifico
tipo di problema di accuratezza: costruisce le definizioni delle regole e successivamente utilizza queste per
trovare le incongruenze tra i dati e le regole.
Figura 7 - Passi della metodologia di dettaglio di data profiling
Ogni passo ha come output delle proprie informazioni sulla qualità, ovvero permette di identificare fatti di
inaccuratezza dei dati che gli altri passi non riescono a fare. Quindi eliminare dei passi nella metodologia di
dettaglio lascia aperta la possibilità di perdere dei fatti sulla qualità dei dati in analisi.
Figura 8 - Tipi di analisi per il data profiling
Metodologie e Strumenti di Data Profiling
21 | P a g i n a
4.2.1 Column Property Analysis
Questo tipo di analisi si focalizza sulle proprietà e valori di un campo indipendentemente dagli altri. Per
esempio una proprietà può essere: ID_DIPARTIMENTO è un campo numerico con un range tra 100 e 999.
Quindi, secondo questa proprietà, 010 sarà considerato una valore non valido.
La lista delle proprietà (metadati) di ciascun campo ricavate con il DP, costituisce l’insieme delle regole per
quel campo. Il numero di proprietà incluse in questo insieme e la completezza della loro definizione
influisce sulla efficacia della ricerca dei valori non validi.
Tutte le violazioni alle proprietà identificate costituiscono valori inaccurati. Comunque non tutti i valori non
accurati vengono rilevati in quanto potrebbero non esserci delle regole per scovarli.
La Column Property Analysis è il processo che si focalizza sui valori atomici per determinare se sono validi
oppure no. Per fare questo bisogna avere a disposizione una definizione di quello che è valido, ovvero i
metadati, che consistono di un insieme di regole che i valori devono rispettare. In pratica forniscono una
definizione di cosa può essere inserito in una campo, restringendo i valori che sono considerati validi.
4.2.1.1 Definizioni
Forniamo alcune definizioni per comprendere il resto del capitolo. Definiamo i termini di campo, dominio,
proprietà, null e field overloading.
La figura mostra come i termini sono relazionati tra loro.
Figura 9 - Definizioni di column property analysis
Campo
È il principale elemento di un database, chiamato anche campo o attributo. È definito come il luogo per
memorizzare un singolo fatto su un business object. Ha una definizione che consiste di un nome più una
descrizione dei requisiti che i dati devono avere per essere inseriti in quel campo (EMPLOYEE_NAME e
CHARACTER 35). Le descrizioni del campo sono necessarie anche per gli sviluppatori per sapere come
trattare quel campo. Queste sono le principali definizioni esistenti presenti ad esempio negli statement
CREATE_TABLE di un database relazionale.
Potrebbero esistere comunque anche altre forme di documentazione, ad esempio data dictionary o
metadata repository. Le descrizioni più dettagliate forniscono anche informazioni sul significato del campo
(business meaning) e sugli obiettivi per cui è stato creato.
Metodologie e Strumenti di Data Profiling
22 | P a g i n a
Dominio
I domini non sono i campi. Essi sono standard che devono essere applicati alle definizioni dei dati di un
business object. Mentre un campo è una specifica istanza di un business fact in quanto definita all’interno
di un business object, il dominio è una definizione generica non collegata ad un particolare istanza, la cui
istanza fisica del suo utilizzo è proprio il campo.
Il concetto di dominio è utile per definire le regole per codificare elementi di business comuni
indipendentemente dalle applicazioni che li utilizzano. Eliminano il rischio di esprimere lo stesso business
fact in molti modi differenti e permettono una migliore manutenibilità delle applicazioni all’interno
dell’azienda, che dovrà contenere nei propri repository la definizione dei domini e il collegamento ai campi
che li utilizzano. Alcuni esempi di domini sono:
•
•
date domain: un date domain può essere definito come una data compresa tra il 01/01/1900 e il
12/31/2099 nel formato mese/giorno/anno. La definizione soprattutto nel formato può variare da
paese a paese ed inoltre possono essere specificate diversi domini relativi alle date come anche
date che includono i termini AD e DC.
zip code domain: esistono diversi modi di esprimere uno zip code, che variano da un paese all’altro
ma anche da azienda ad azienda che ad esempio può definire il proprio dominio con una versione
abbreviata di un codice. Uno zip code può essere espresso dal formato nnnn-nnnn dove n è un
intero compreso tra 0 e 9, ma è solo uno dei possibili formati. Esistono molti domini definiti
appositamente per ogni paese, ma si può definire anche un dominio generale in cui il codice è
espresso come un stringa lunghezza variabile con al massimo 10 caratteri alfanumerici, ma questo
tipo di definizione è meno utile per un test di data accuracy, in quanto quasi tutti i valori
passeranno il test.
Property List
Una proprietà è una regola che definisce i valori permessi in un campo.
La lista delle column property non è solo composta da informazioni sul dominio. Infatti può includere
proprietà tipiche di un dominio: data type, restrizioni sulla lunghezza, range di valori, ma anche regole di
unique, consecutive e null che sono regole aggiuntive che particolarizzano il dominio per un specifico
utilizzo. Ad esempio una regola unique dichiara che ogni valore nella campo deve essere differente l’uno
dall’altro.
Una lista di alcune proprietà possibili per un campo:
•
•
•
•
•
•
•
Name: business name
Business meaning
Domain name
Data type
Character: set, code page
Lenght restrictions
Accetable values
o Discrete list of accetable values
o Range of accetable values
o Text field restrictions
o Character patterns
Metodologie e Strumenti di Data Profiling
23 | P a g i n a
•
•
Null values
Unique values
•
Consecutive values
Quindi un campo può essere definito in termini di un dominio più fattori aggiuntivi che rendono il dominio
particolare per l’uso in quel campo. Ad esempio in una tabella ORDER può esserci un campo
ORDER_NUMBER che ha un dominio definito come un numero di 5 cifre tra 10001 e99999 più requisiti di
UNIQUE, NOT NULL e CONSECUTIVE.
Column Names
La più importante proprietà per un campo è il nome. Avere un nome che identifica la natura del contenuto
è molto importante per il data profiling. Il nome deve essere però descrittivo, ad esempio
QUANTITY_AVAILABLE è più descrittivo di AQ003BZ. Questo però non sempre è possibile, in quanto molte
applicazioni e DBMS restringono la lunghezza dei nomi diminuendone il potere del nome nel descrivere il
campo.
Null
Il termine null è il più controverso nel mondo dei database. La definizione generale per la condizione di null
è quella che il dato non è disponibile per un campo. Ci sono diversi motivi per i quali il dato può essere non
disponibile. Esistono molte definizioni e teorie di come gestire le condizioni di null. Per questo in fase di
design bisogna definire la propria convenzione utilizzata per rappresentare questi valori, se questo non
avviene gli utenti in fase di data entry possono inventare la propria convenzione generando problemi di
accuratezza.
In caso non venga definita nessuna convenzione, molti DBMS relazionali applicano l’indicatore NULL per
evidenziare la condizione di assenza valore, ma altre applicazioni potrebbero inserire un blank per i
caratteri oppure uno zero per i campi con dominio numerico. Quindi la lista delle proprietà deve contenere
le convenzioni usate per le condizioni di null.
Field Overloading
Field overloading è un termine che indica un numero di pratiche che oggi sono considerate cattivi approcci
al design ma che in passato sono state largamente usate. In particolare si riferisce alla pratica di usare un
singolo campo per memorizzare più di un business fact. Questa è molto comune nei legacy sistem dove non
sono mai documentati, creando molte difficoltà nel rilevarli e aumentando i problemi di qualità. L’analisi
column property non può essere eseguita su un overloaded field senza prima dividere i fatti in singoli
campi.
Metodologie e Strumenti di Data Profiling
24 | P a g i n a
4.2.1.2 Il Processo per il Profiling Columns
La figura mostra il processo di profiling per i campi.
Figura 10 - Processo di profiling columns
Il processo ha due obiettivi:
1. definire le proprietà che determinano quali valori sono accettabili in un campo
2. trovare le violazioni a queste proprietà (inaccurate values)
I dati sono analizzati in isolamento, ovvero senza osservare nessuna relazione dei dati con altri.
Gathering Information
In questa fase vengono raccolte le informazioni (metadati) su un campo, e prendono il nome di
documented properties. Sono i metadati che provengono da documentazione esterna e vengono
memorizzati nel repository utilizzato per il processo di data profiling.
Le sorgenti di informazione possono essere: data definition, procedure manuali di data entry, data
dictionary, metadata repository e altre forma di documentazione che non siano i dati stessi.
Discovery from Data
Questa fase del processo permette di raccogliere le proprietà dei dati avendo come unica sorgente di
informazione i dati stessi. I metadati raccolti nella fase precedente non vengono utilizzati.
Al termine di queste due fasi avremo quindi a disposizione due insiemi di metadati indipendenti l’uno
dall’altro che andranno confrontati nella fase successiva per determinare la lista corretta di proprietà da
associare al campo.
La scoperta delle proprietà direttamente dai dati (cardinalità, ranges, data type, lunghezza campo,
convenzioni null, ecc.) è più completa e accurata se eseguita con un software sviluppato per questo scopo.
Se non è disponibile un software bisogna sviluppare delle query per interrogare ciascuna campo e ottenere
le informazioni necessarie. L’utilizzo di quest’ ultimo metodo può essere proibitivo nel caso di database con
migliaia di record.
Metodologie e Strumenti di Data Profiling
25 | P a g i n a
Infine estrarre le proprietà direttamente dai dati, può essere molto difficile per quei dati che non sono in
forma tabellare e per questo la fase di estrazione dei dati che fa parte del processo di profiling deve portare
i dati in una forma adatta ad eseguire il profiling.
Verification of Results
Il passo successivo è quello di confrontare i dati (le proprietà ottenute dai dati) con le documented
properties. L’obiettivo è determinare se qualunque differenza è causata da dati inaccurati oppure da
metadati inaccurati. Nel valutare i risultati bisogna guardare da due prospettive: valori inaccurati e valori
accurati.
I valori inaccurati sono quei valori che non rispettano le documented properties. Ma considerato che tali
metadati sono spesso non completi e di scarsa qualità, potrebbero essere errati gli stessi metadati ad
essere inaccurati. Ma anche i dati spesso lo sono, ad esempio non è raro trovare campi utilizzati in modo
differente rispetto all’intenzione originale.
Considerare i valori accurati è un buon modo per giudicare i metadati. Ad esempio se per una campo è
specificata una lunghezza di 30 byte e l’analisi delle proprietà direttamente dai dati rileva che contiene dei
valori tutti di lunghezza 1 byte, nasce il sospetto che i metadati possano riferirsi ad un’altro campo.
Questo processo di confrontare i metadati con le proprietà scoperte dai dati dovrebbe essere supportato
da analisti, esperti di business e qualunque altro esperto disponibile con l’obiettivo di determinare la lista
delle proprietà corrette di ogni campo.
L’output di questa fase è una lista di proprietà accurate per ogni campo. Un altro possibile output però
possono essere i problemi di qualità che possono essere identificati analizzando solo il campo, come fields
overloading, rappresentazioni inconsistenti di valori null, ecc.
Validation of Data
L’ultimo passo del processo è il confronto tra i dati e la lista di proprietà accurate identificate al passo
precedente. Questo permette l’identificazione di tutte le violazioni alla lista di proprietà e vengono rilevati i
valori inaccurati. I risultati vengono memorizzati nel repository come inaccurate data facts.
Questa fase si differenzia dalla fase di discovery from data, nella quale si identificavano le caratteristiche
dei campi. Ora invece si identificano le differenze tra i dati contenuti nei campi e le caratteristiche
considerate valide per quel campo. Mentre per la fase di discovery può essere sufficiente un campione di
dati, per la fase di validation è necessario l’intero data source.
4.2.1.3 Profiling Properties per i Campi
Analizziamo i tipi di proprietà che possono avere i campi e per ognuna mostriamo come possono essere
usate per trovare valori non validi. La lista delle proprietà potrebbe includere la definizione di un dominio
che fornisce già alcune delle proprietà.
4.2.1.3.1 Business Meaning
Il business meaning di un campo è una proprietà che dichiara cosa dovrebbe essere memorizzato in quel
campo. Per scoprire questa proprietà, basta osservare solo alcune informazioni ritornate dalla fase di
discovery from data e stabilire se il campo è usato per lo scopo previsto. Spesso non è sufficiente solo il
nome di un campo, ma per scoprire il business meaning si ha bisogna di descrizioni più complete.
Metodologie e Strumenti di Data Profiling
26 | P a g i n a
Nella ricerca del business meaning possono essere scoperti alcuni problemi di qualità. Ad esempio si può
scoprire che il campo è usato per un altro scopo rispetto a quello dichiarato nella documentazione o
espresso dal nome. Si può scoprire che un campo Codice Fiscale contiene dei numeri di Documenti di
Identità.
Infine nello stabilire il business meaning, si possono ricavare problemi nella capacità descrittiva del nome.
Infatti dopo avere scoperto il meaning, può capitare che il nome non sia rappresentativo del contenuto e
quindi dovrebbe essere sostituito nel data profiling repository con un nome adatto al meaning scoperto.
4.2.1.3.2 Storage Properties
Queste proprietà definiscono quale forma devono avere i dati per essere memorizzati in un campo.
Includono data type, lunghezza del campo e precisione per i campi numerici. Queste regole sono raramente
violate in quanto i DBMS forzano i controlli nell’inserimento dei dati.
Data Type
Un DBMS specifica una lista di data type che possono essere associati ad un campo e che definiscono quali
valori possono essere memorizzati. Alcuni data type tipici sono:
•
•
•
•
•
•
•
Character
Integer
Small integer
Decimal float
Date
Time
Timestamp
Di solito il data type più utilizzato è il CHARACTER data type. Viene usato anche per memorizzare dati che
non sono caratteri, come dati numerici. Le ragioni sono diverse:
•
•
•
il sistema in uso potrebbe non supportare il particolare data type (DATE, TIME, TIMESTAMP) di quel
dato, invece un CHAR è sempre supportato,
per memorizzare valori che non possono essere rappresentati con quel data type, ad esempio
valori blanks per date non note che un DATE non supporta,
se si accettano valori da sorgenti esterne queste possono contenere valori non conformi al data
type utilizzato nel sistema destinazione, e allora si possono trasformare questi in valori NULL
oppure inserirli in un campo carattere per preservare i valori originali.
Questa pratica però è soggetta ad aumentare la memorizzazione di valori errati, dal fatto che nei campi
carattere può essere immagazzinato qualunque dato e non ci sono controlli restringenti da parte dei DBMS.
Lenght
Questa proprietà specifica la lunghezza di un campo, che comunque deve essere sempre sufficiente per
evitare che inserimenti e aggiornamenti falliscano o che i dati vengano troncati. Esaminare i problemi di
lunghezza può essere importante. Per i campi carattere, osservare la distribuzione delle lunghezze dei valori
nel campo può indicare se il campo è usato per lo scopo giusto oppure no. L’analisi si può focalizzare sui
singoli valori inaccurati. Ad esempio, se in un campo nome il 5% dei valori ha lunghezza pari ad un
Metodologie e Strumenti di Data Profiling
27 | P a g i n a
carattere, si rende necessaria un’analisi approfondita perché probabilmente sono presenti nomi non
accurati. Un altro problema che può essere rilevato anche se non è proprio un problema di qualità è uno
spreco nella memorizzazione dei valori che può portare ad un cambiamento del data type. Ad esempio se
consideriamo un campo numerico, la lunghezza del campo deve essere proporzionata al range di valori
validi e in alcuni casi si può passare da un integer ad un small integer per risparmiare spazio di
memorizzazione.
Precision
Questa proprietà indica il numero di posizioni alla destra del punto decimale in un valore di un campo
numerico. I valori possono essere analizzati e può essere creata una distribuzione che mostra il numero di
valori per ciascuna precisione trovata. Questo può essere utile per determinare il corretto utilizzo del data
type. Ad esempio se tutti i valori risultano essere valori interi ma il data type è un decimal o float si rende
necessario un cambiamento del data type del campo.
4.2.1.3.3 Proprietà per Valori Validi
Dopo aver definito le proprietà di storage e derivato il business meaning può essere avviato il processo di
scoperta dei valori non validi. Questo processo consiste nello specificare uno o più proprietà sui valori per
ogni campo e testare queste sui valori presenti nel data source. Le proprietà variano in base al data type del
campo.
Più dettagliate saranno le definizioni delle proprietà, più valori inaccurati verranno trovati. Le definizioni
delle proprietà restringono la lista di valori accettabili. In alcuni casi tutti i valori possibili possono essere
elencati, in altri casi è possibile solo definire una condizione che i valori devono rispettare, ma alcuni valori
possono verificare la condizione ed essere ancora innaccurati.
Elenchiamo i tipi proprietà possibili per un campo che specificano valori accettabili:
•
•
•
•
•
•
Discrete value list
Range of values
Skip over rules
Text column rules
o Token keywords
o Line enders
Character patterns
Special domain
Discrete value list
I campi possono avere un insieme di specifici valori accettabili che possono essere parole del mondo reale
oppure codici che rappresentano elementi reali. Ad esempio un campo STATE avrà una lista di codici validi
che possono essere rappresentati con uno standard a due caratteri (NY). Un altro esempio se consideriamo
un campo COLOR può contenere una lista di colori (red, green, blue) oppure la loro codifica (R,G,B).
La prima fase del processo di profiling sui valori, è validare la lista di valori accettabili. Si procede creando
una lista dei valori presenti nel campo, magari calcolando la frequenza e confrontando poi con la lista di
valori considerati accettabili.
Metodologie e Strumenti di Data Profiling
28 | P a g i n a
Confrontando i valori, si può scoprire la necessità di ampliare la lista di valori validi oppure di ridurla perché
alcuni valori non vengono utilizzati. Infine si possono scoprire campi sproporzionati (con troppi valori o
troppo pochi) che individuano degli errori in fase di data entry, ovvero può essere presente troppe volte il
valore di default della lista e questo implica che gli utenti non conoscevano il valore corretto da inserire.
Range of Values
Altra proprietà sono i range di valori per un campo. Ad esempio usati su campi date, time o numerici
(0>=value<=1000 su QUANTITY_ORDERED), ma anche per campi di testo. Lo scopo è verificare che il range
di un campo sia giusto o se deve essere modificato in base ai valori contenuti oppure se ci sono alcuni valori
errati che non rientrano nel range che vanno eliminati. Si procede come nel caso precedente col
determinare tramite software il range di valori (utilizzando il calcolo delle frequenze) nei dati attuali e per
poi confrontarlo con il range atteso.
Skip-Over Rules
Queste regole escludono valori particolari all’interno di un range e di solito sono applicate a campi date e
time. Ad esempio dato un campo HIRE_DATE si può inserire una restrizione per la quale si accettano valori
date corrispondenti solo a week-end o a periodo di vacanza.
Text-Column Rules
Per questi campi è molto difficile fissare delle regole per controllarne i valori validi, di conseguenza molti
strumenti di data profiling non effettuano un controllo completo del contenuto dei campi di testo.
Comunque alcune regole possono essere applicate per identificare i valori non validi.
In questi campi possono esser scoperte situazioni anomale, ovvero la presenza di valori che possono essere
specificati con un altro data type, come numeri o date memorizzate come testo. Questi valori dovrebbero
essere testati con regole relative al vero data type e non con le regole per i campi di testo.
Il più semplice valore che può essere presente in un campo testo è costituito da una sola parola e tale
campo di solito non accetta caratteri speciali e di blank, ma solo lettere dell’alfabeto. Le regole di solito si
basano sul controllo di una lista di valori validi che non sempre può essere definita in quanto non si
conoscono in anticipo i valori o ci sono tanti valori che rendono la lista troppo lunga.
Ci sono poi campi di testo che contengono più di una parola separate da caratteri blank che accettano
caratteri speciali quali punto e virgola, ma non altri come &,%,*,$,@,#. Le regole si basano sul controllare
l’assenza di questi caratteri particolari.
Per alcuni campi di testo invece è difficile definire delle regole, sto parlando di campi di testo generici che
possono contenere qualunque cosa (frammenti di testo e caratteri speciali quali line enders e carriage
returns).
Il modo migliore per eseguire il profiling sui campi di testo è eseguire un discovery per identificare possibili
caratteri blank o speciali e per determinare se è veramente un campo testo oppure no.
Metodologie e Strumenti di Data Profiling
29 | P a g i n a
Patterns
I campi di testo possono contenere valori che devono seguire un particolare pattern per essere validi. Ad
esempio per un campo PRODUCT_ID un pattern può essere:
•
•
•
•
il primo carattere indica il tipo di prodotto e può essere A,B o C
i successivi tre caratteri identificano la divisione che lo produce e sono cifre numeriche
il carattere successivo indica il tipo di packaging: R,H,S
gli ultimi cinque caratteri sono cifre numeriche che identificano il singolo prodotto
le regole per questi campi controllano che i valori rispettino il pattern. Poiché i DBMS non fanno controlli
sui pattern si hanno molte violazioni, inoltre sono raramente documentati e quindi bisogna scoprirli tramite
dei software e applicare poi la regola per controllare i valori.
Domini Speciali
Alcuni campi contengono valori appartenenti a domini ben definiti. Esempi sono
SOCIAL_SECURITY_NUMBER, ZIP_CODE, STATE_CODE, ecc. Il vantaggio è che tali domini possono essere
definiti con regole universali a tutte le occorrenze i tutti i database.
4.2.1.3.4 Proprietà per Valori Null
Esistono delle regole per controllare i valori relativi a condizioni Null in un campo. I software permettono di
scandire i dati alla ricerca di valori che indicano condizioni di valori mancanti. Le regole vanno alla ricerca di
tutti i possibili indicatori come blanks, ?, none, **no value, don’t known, ecc. per memorizzarli nel
repository e trasformarli poi nel momento del trasferimento dei dati su un altro sistema nell’indicatore
utilizzato come standard dal sistema destinazione. Comunque non è detto che tutti i valori che indicano
condizioni Null siano esatti, bisogna anche analizzarli da un punto di vista semantico e non solo sintattico,
soprattutto quando essi sono troppi possono indicare degli errori in fase di design dei dati.
Metodologie e Strumenti di Data Profiling
30 | P a g i n a
4.2.2 Structure Analysis
L’analisi strutturale utilizza le regole che definiscono come i campi si relazionano tra loro per formare
tabelle e come le tabelle si relazionano per comporre business objects. Un business object descrive un
singolo business event. Per esempio un ordine di un cliente è un business object. L’oggetto ordine può
essere composto da più parti: intestazione, informazioni sul cliente, informazioni sulla spedizione e linee
d’ordine. Ciascuna parte può essere composta da uno o più campi. Ogni parte, di solito è memorizzata in
tabelle diverse. Nella figura è mostrato il business object appena descritto.
Figura 11 - Esempio di business object
Le regole strutturali definiscono i campi che identificano univocamente uno specifico business object o
tabella all’interno del business object. Vengono inoltre definite le regole relative a come le tabelle si
relazionano tra loro. Per esempio ciascun ordine è identificato in modo univoco da un campo
ORDER_NUMBER. le linee d’ordine sono identificate dal campo ORDER_NUMBER e PRODUCT_ID in quanto
ci possono essere uno o più linee d’ordine appartenenti allo stesso ordine.
L’analisi strutturale ha quindi a che fare con il concetto di vincoli di integrità:
•
•
Vincoli intra-relazionali: ogni vincolo di questo tipo coinvolge una sola relazione del database; si
possono suddividere ulteriormente in:
o Vincoli di tupla : ogni vincolo va valutato su ogni tupla presa singolarmente
(NOT(Lode=‘Sì’)) OR (Voto=30))
o Vincoli di valore o di dominio: impongono delle restrizioni sui domini degli attributi,
coinvolgono un singolo attributo. Sono i vincoli
chiavi primarie
chiavi primarie composte
Vincoli inter-relazionali: ogni vincolo di questo tipo coinvolge più relazioni del database
o Vincoli referenziali (foreign key)
Le informazioni sui campi e sulle regole che definiscono le connessioni tra le tabelle dei business object,
possono essere utilizzate nei progetti di migrazione verso nuove strutture dati.
Metodologie e Strumenti di Data Profiling
31 | P a g i n a
Altre informazioni importanti sono quelle relative a come i business object si relazionano tra loro e possono
essere utilizzate per indagare sul livello di consistenza del data source per applicare un eventuale
reingegnerizzazione.
Le regole strutturali sono spesso trascurate e questo può portare a gravi conseguenze quando si estraggono
i dati per utilizzarli in altre strutture. Il principale motivo di questo è che tale argomento è ostico per le
persone addette all’analisi e non hanno il giusto background per affrontare questo temi.
Completare l’analisi strutturale e documentare la reale struttura dei dati è importante anche per il passo
successivo di analisi business object data rule, in quanto alcune data rule dipendono da una corretta
comprensione della struttura e delle relazioni tra i campi per definire un business object.
I sistemi relazionali contengono molti problemi strutturali, anche se i DBMS forzano i controlli sulla
struttura dei dati. Il problema più comune sono le tabelle denormalizzate, perché sono utilizzate per
migliorare le performance eliminando i JOIN, ma per lo stesso motivo si utilizzano anche dati duplicati e
non si implementano relazioni di chiave primaria/esterna. Inoltre quando la denormalizzazione viene fatta,
essa non viene documentata.
Nel comprendere meglio il seguito, può essere utile conoscere la definizione di alcuni termini utilizzati nella
teoria delle architetture database. Diamo per scontata la conoscenza di termini quali dipendenza
funzionale, chiave, chiave primaria, chiave denormalizzata, campi derivati, chiavi esterne, forme normali
(prima, seconda e terza forma e anche forma denormalizzata e split table), sinonimi. In caso di difficoltà si
rimanda per una descrizione precisa al capitolo 9 sezione 9.1 del testo Data Quality: The Accuracy
Dimension di Jack Olson.
Forniamo solo alcune definizioni:
•
•
•
Dipendenza funzionale: una dipendenza funzionale è una relazione che ha un left-hand-side (LHS),
che consiste di un insieme di campi che determinano il valore di un singolo campo sul right-handside (RHS). Una dipendenza funzionale si dice essere verificata su una tabella se per ogni record,
per ogni valore uguale di LHS, i valori nei campi RHS sono gli stessi. Il concetto di dipendenza
funzionale è alla base delle definizioni di chiave primaria, chiave denormalizzata, campi derivati e
chiave esterna.
Chiave denormalizzata: è una dipendenza funzionale che tra i due lati non include tutti i campi di
una tabella. Quindi determina il valore solo di alcuni campi. Gli altri possono essere parte di altre
dipendenze. Ad esempio in una tabella PRODUCT abbiamo il campo PRODUCT_ID che determina il
campo DESCRIPTION, quindi il valore di questo campo deve poter essere ottenuto guardando la
sola tabella PRODUCT. Ma per ragioni di performance esso viene duplicato in una tabella
ORDER_DETAIL.
Campi derivati: sono quei campi che esistono nel lato RHS di una dipendenza funzionale e il valore è
determinato da una regola sui valori dei campi LHS. Ad esempio se CAMPO_C = CAMPO_A +
CAMPO_B, il CAMPO_C è un campo derivato e la dipendenza funzionale è CAMPO_A, CAMPO_B CAMPO_C. Questa regola può essere una formula matematica (PREZZO =
PREZZO_UNITA’*QUANTITA’) oppure una business rule (come tutti i clienti di Chicago hanno il 10%
di sconto, tutti gli altri il 5%). La dipendenza funzionale che definisce un campo derivato può
includere tutti i campi di una tabella (rendendolo chiave) o un sottoinsieme (rendendolo chiave
denormalizzata).
Metodologie e Strumenti di Data Profiling
32 | P a g i n a
•
•
Tabelle denormalizzate: una tabella è de normalizzata se non è in terza forma normale.
Sinonimi: due campi sono sinonimi se ciascuno contiene lo stesso business fact. Tali campi possono
essere utilizzati per scopi differenti ma il loro contenuto ha lo stesso business meaning. Ad esempio
sono sinonimi i campi DEPARTMENT_NUMBER in una tabella DEPARTMENT, DEP_NO in una tabella
PERSONNEL e un campo DEPT_NUM in una tabella PROJECT.
Estrazione in forma tabellare
Assumiamo che i dati siano rappresentati in forma tabellare, che comunque non è l’unica possibile ma vale
per le strutture relazionali. Tale rappresentazione è utile per eseguire il profiling quindi i dati devono
sempre essere estratti in forma tabellare. L’estrazione di dati è comunque un argomento a parte che viene
trattato approfonditamente in altri riferimenti.
Quindi assumiamo di aver estratto i dati in forma tabellare. È richiesto che i dati siano almeno in prima
forma normale.
4.2.2.1 Il Processo di Structure Analysis
Il processo è simile a quello descritto per le proprietà dei campi. Le sorgenti di informazione e i tool
utilizzati sono differenti ma l’intero processo è lo stesso come mostrato in figura.
Figura 12 - Processo di structure analysis
Gathering Information
Le informazioni sulla struttura possono essere reperite in molti modi.
Metadata Repositories
Le informazioni derivabili da queste fonti permettono di identificare di solito chiavi primarie e chiavi
esterne, ma non sono ricche di dettagli, in quanto sono presenti al livello di tabelle e non di campi.
Metodologie e Strumenti di Data Profiling
33 | P a g i n a
Data Models
Potrebbero esistere data models formali che descrivono la struttura dei dati in maniera più dettagliata,
provenienti da tools di modellazione che possono esser stati usati nello sviluppare il progetto della
struttura dati. L’inconveniente è che questi modelli possono essere non aggiornati in quanto era
consuetudine utilizzarli solo nelle fasi iniziali dei progetti.
Database Definition
Molte informazioni possono essere trovate in catalog o directory di database relazionali o in strutture di
altre tecnologie. Le informazioni più che in altre sorgenti possono essere considerate affidabili in quanto
alcuni DBMS forzano le regole strutturali, per esempio la presenza di chiavi primarie in una tabella. Le
informazioni raccolte rappresentano l’implementazione del database e sono più accurate rispetto alle altre
sorgenti (repositories e models) con le quali avviene comunque un confronto per consolidare le
informazioni.
Discovery from Data
Il passo di scoprire informazioni strutturali direttamente dai dati, è molto difficile se non supportato con
appositi software. Ci sono due possibili approcci. Il primo prevede l’uso di software per scoprire tutte le
dipendenze funzionali e trovare tutte le coppie di campi che sembrano essere sinonimi. Il secondo è testare
le regole strutturali che si ritiene essere valide sui dati per calcolare il grado di matching.
Il primo approccio è preferibile perché si possono scoprire casi non inclusi nelle regole da testare, ai quali
non si è pensato. Con il secondo approccio si lascia aperta la possibilità di non identificare strutture
relazionali che esistono nei dati ma alle quali non si è prestato attenzione e queste strutture non rilevate
possono poi causare problemi nel mapping con altri sistemi.
La ragione per l’utilizzo di speciali software per trovare tutte le dipendenze funzionali, è l’elevato numero di
dipendenze che possono esistere in una tabella. Ad esempio per una tabella con n campi dove la
dipendenza specifica solo un campo sul lato sinistro (campo che determina i valori negli altri campi) il
numero di dipendenze funzionali è n*(n-1). Il numero aumenta con l’aumentare dei campi sul lato sinistro
della dipendenza. Il numero di righe non influenza tale numero ma solo il tempo di esecuzione del test. Il
problema quindi di trovare tutte le possibili dipendenza funzionali in una tabella con un numero arbitrario
di record e campi abbraccia tematiche di efficienza computazionale e richiede le giuste piattaforme e
software.
Verification of Results
Il mapping tra i risultati della fase di discovery con i metadati raccolti può esser fatto da un analista. La fase
di verification deve essere fatta da analisti di business ed esperti. I problemi strutturali si riducono sempre
alle corrispondenti definizioni di business, infatti le tabelle sono correlate ad oggetti del mondo reale e le
relazioni tra le tabelle hanno un preciso significato di business. Molti analisti di business hanno problemi
nell’identificare le strutture dei dati con il loro mondo di business, in quanto hanno poca comprensione dei
termini utilizzati nelle architetture database e quindi l’analista di profiling deve effettuare la traduzione
anche con l’aiuto di diagrammi. Ma molto spesso gli analisti di profiling credono che i problemi strutturali
non riguardano l’interpretazione semantica e non coinvolgono gli esperti di business.
Metodologie e Strumenti di Data Profiling
34 | P a g i n a
4.2.2.2 Rules for Structure
In questa sezione mostro in modo approfondito una tecnica (scoprire le dipendenza funzionali) che può
essere utilizzata per analizzare la struttura dei dati, con l’obiettivo di trovare la corretta definizione della
struttura e trovare le violazioni nei dati. Non è l’implementazione di uno specifico metodo, ma solo una
descrizione di una tecnica che può essere implementata per l’analisi strutturale. Accenno poi ad un’altra
tecnica (trovare i sinonimi) che è meglio descritta nel capitolo 9 del testo di Jack Olson.
Ogni tecnica riguarda un singolo aspetto della struttura e di solito non può essere eseguita con un singolo
software e richiede un’interpretazione semantica per verificare i risultati ottenuti.
4.2.2.2.1 Scoprire le Dipendenze Funzionali
Questa tecnica porta a scoprire chiavi primarie, chiavi denormalizzate e campi derivati. Ricordiamo che
esistono due approcci per trovare le dipendenze funzionali: utilizzare dei software di discovery oppure
validare le dipendenze proposte.
Determinare le dipendenze candidate
Il primo compito è ipotizzare quali possono essere le dipendenze funzionali nei nostri dati e memorizzare
queste nel data profiling repository come dipendenze candidate.
Dall’altro lato di solito si ha un insieme di dipendenze candidate identificate nelle informazioni provenienti
delle diverse forme di documentazione esterna.
Il processo di ipotesi sulle dipendenze, è fatto per aggiungere alla lista le dipendenze che non sono
documentate. Può comunque presentarsi il caso peggiore in cui i metadati identificano poche dipendenze e
quindi si deveno ipotizzare molti possibili candidati.
Il modo migliore per creare una lista di dipendenze candidate è classificare i campi, con l’obiettivo di
individuare l’insieme di campi che possono fungere da componente LHS della dipendenza.
I campi che dovrebbero essere subito esclusi dall’appartenere all’insieme LHS sono quelli contenenti un
solo valore o un’alta percentuale di valori nulli. Questo in generale è vero tranne quando la semantica della
campo suggerisce il contrario.
I campi possono essere classificati semanticamente come: identificatori, descrittori, quantificatori, date e
testo libero. Per fare questo un prerequisito richiesto dall’analisi strutturale è l’analisi delle proprietà dei
campi (descritta precedentemente) che permette di identificare il business meaning e le proprietà del
contenuto dei campi utili per effettuare una buona classificazione.
•
Identificatori: sono campi che per la loro particolare natura identificano un oggetto in una tabella.
Alcuni di essi sono chiaramente identificabili dal nome (ORDER_NUMBER, PRODUCT_ID, ecc.) . Altri
possono essere trovati conoscendo cosa rappresenta il business object e quindi tra i suoi attributi si
possono identificare quelli con funzione di chiave primaria o esterna. Ci sono campi che non sono
da soli buoni candidati e richiedono campi aggiuntivi per identificare univocamente un oggetto in
una tabella, per esempio CUSTOMER_NAME potrebbe richiedere ADDRESS o PHONE_NUMBER per
ottenere l’univocità nel caso di più clienti con lo stesso CUSTOMER_NAME. Le ipotesi sull’insieme di
campi che fungono da identificatori si basano sull’osservazione dei dati e sulle considerazioni del
tipo appena descritte.
Metodologie e Strumenti di Data Profiling
35 | P a g i n a
•
•
•
•
Descrittori: sono campi che permettono di descrivere una singola caratteristica di una tabella.
Alcuni esempi: CUSTOMER_TYPE, ZIP_CODE, COLOR_MODE, ecc. Questi campi sono di solito buoni
candidati RHS.
Quantificatori: sono campi che contengono valori numerici ed esprimono quantità associate ai
business object. Alcuni esempi: PRICE, QUANTITY, ecc. Alcuni possono non essere numerici come
ad esempio GRADE che esprime un giudizio su uno studente all’interno di un corso e quantifica
quindi quanto è stato bravo. Sono candidati come componenti RHS. I campi quantificatori sono
buoni candidati per essere colonne derivate, si possono analizzare tali campi ipotizzando quali di
loro possono essere calcolati da altri, ad esempio TOTAL_PRICE, e si può quindi produrre una lista
di probabili candidati RHS di dipendenze derivate.
Date: sono campi che descrivono quando avviene un evento significativo per un business object.
Alcune tabelle hanno più di un campo date come DATE_OF_ORDER, DATE_CREATED, ecc. Tali campi
sono raramente candidati LHS.
Testo libero: sono campi che contengono testo composto da più parole. La loro funzione è
aumentare l’informazione sul business object. Alcuni esempi: COMMENTS, REVIEWER_NOTE, ecc.
Non hanno funzione di identificazione del record e quindi non possono essere candidati LHS. Quasi
sempre sono campi RHS associati alla sola chiave primaria.
Scoprire le Dipendenze
A questo punto si ha un insieme di dipendenze funzionali candidate che devono essere testate sui dati
attuali presenti nel data source per provare che siano vere dipendenza oppure no.
Il modo migliore per testarle è scoprirle nei dati. Ovvero si esegue un processo per trovare tutte le
dipendenze funzionali in una tabella attraverso l’utilizzo di sofware. Queste dipendenze prodotte saranno
vere su tutti i dati usati per il test. Ma a volte nel test non si utilizzano tutti i dati a causa delle dimensioni
del data source e del conseguente tempo proibitivo per eseguire il processo. Quindi si utilizzano dei
campioni per questa fase di scoperta. I campioni possono essere più di uno e creati utilizzando criteri
differenti.
Un punto su cui prestare attenzione quando si utilizzano i campioni è che tutte le dipendenze devono
essere vere in tutti i campioni. Bisogna eliminare dall’insieme di dipendenze scoperte i falsi positivi, ovvero
che sono vere nei campioni e false quando si considerano tutti i dati, attraverso revisioni semantiche o con
test eseguiti su tutti i dati. Se la fase di scoperta ritorna troppe dipendenze, in generale indica che si hanno
molti falsi positivi. Questo è dovuto alla dimensione troppo piccola dei campioni che devono essere
ridimensionati.
Nel caso di analisi su più campioni separati, si confrontano i risultati considerando solo quelle dipendenze
comuni tra i campioni in quanto le altre possono essere vere solo in quel particolare campione e lo scopo è
eliminare i falsi positivi.
Dopo aver ottenuto l’insieme di dipendenze scoperte bisogna confrontarle con l’insieme di dipendenze
candidate presenti nel repository. Il confronto va effettuato anche su una base semantica, ovvero
scartando quelle dipendenze che non hanno un significato di business. Ogni dipendenza va etichettata
come confermata attraverso la fase di scoperta, non confermata attraverso la fase di scoperta o trovate
con la fase di scoperta (quelle vere ma non ipotizzate).
Metodologie e Strumenti di Data Profiling
36 | P a g i n a
Mostriamo un esempio di dipendenza che dovrebbe essere scartata che è allo stesso tempo un
inconveniente nell’utilizzo dei campioni. Utilizzando un campione si scopre un campo NOME come chiave
primaria con tutti gli altri campi dipendenti da esso. Da una prospettiva di business è noto che ci possono
essere due differenti record con lo stesso valore in quel campo NOME e che quindi non può fungere da
identificatore. Questa dipendenza deve essere scartata e l’errore è stato indotto dal fatto che tale campo
aveva tutti valori univoci nel campione preso in esame.
Testare le Dipendenze
Se non si dispone di un software per effettuare la fase di scoperta delle dipendenze, bisogna costruire dei
test per quelle dipendenze che si ritengono vere. In realtà questo metodo dovrebbe essere utilizzato anche
quando si dispone di un software e si può eseguire la fase di scoperta, per quelle dipendenze candidate che
non compaiono nella lista di dipendenze scoperte dal software.
Poiché il numero di test da scrivere può essere eccessivo, si deve limitare il numero facendo delle
considerazioni prima di iniziare a sviluppare questi test. Ad esempio, non bisogna testare una chiave
primaria quando si è certi che il DBMS forza il controllo sull’univocità in fase di data entry. Oppure si
possono identificare dei campi chiave primaria osservando che la cardinalità del campo sia pari al numero
di record della tabella e questo da la certezza che sia una chiave e non c’è bisogno di nessun altro test.
L’output di questa fase di test può essere una conferma che in tutti i record valgono le dipendenze.
Classificare le Dipendenze
Dopo aver determinato i risultati dei test, l’analista può confrontare questi con le dipendenze candidate e
scoperte per determinare quali sono vere e quali false.
4.2.2.2.2 Altre Tecniche di Analisi
Un'altra tecnica di analisi è trovare i sinonimi, ovvero le coppie di campi che rappresentano lo stesso
business fact e classificare le relazioni esistenti tra loro. Questa analisi può essere fatta sulla singola tabella
o su più tabelle. Il processo di data profiling, determinerà il tipo di sinonimi e le regole per trovare i dati
inaccurati. Questo passo è importante quando si vuole consolidare i dati di diverse sorgenti indipendenti.
Il processo è eseguito da due differenti prospettive:
•
•
Singolo data source: tutte le tabelle rappresentano differenti componenti di business objects e si
cerca di determinare come sono connessi.
Merged data sources: le coppie di tabelle rappresentano gli stessi componenti di business objects e
l’obiettivo è trovare le coppie di campi che rappresentano lo stesso business fact a livello di campi e
testare se possono essere fusi in un unico campo nel data source di destinazione.
4.2.2.3 Output Structure Analysis: Inaccurate Data Facts
Tutte le istanze di violazioni alle regole strutturali devono essere memorizzate. Esse indicano dati
inaccurati. Può anche capitare che i dati inaccurati non vengano inclusi nell’insieme dei risultati, rimanendo
nel data source e minando la sua qualità. Gli inaccurate data facts includono violazioni di chiavi primarie, di
chiavi denormalizzate, di campi derivati e di coppie chiavi primaria/esterna.
Metodologie e Strumenti di Data Profiling
37 | P a g i n a
Descriviamo le violazioni che possono essere rilevate:
•
•
•
•
Chiavi primarie: queste violazioni indicano che il campo contiene valori non univoci e quindi che
minimo due record hanno lo stesso valore per quel campo chiave primaria. Ci sono campi che
contengono valori codificati che lo rendono una reale chiave primarie, come SSN (Social Security
Number) che contiene codici univoci per ogni cittadino. Altre che sono considerate chiavi naturali
come NAME o ADDRESS possono contenere valori duplicati che sono permessi per la natura del
campo e quindi per tali campi vanno analizzati attentamente per verificare se esso è una chiave
primaria di una tabella oppure no. Infine può essere considerata una violazione per un campo
candidato chiave contenere valori NULL, quando si verifica questo caso bisogna analizzare meglio il
campo.
Dipendenze denormalizzate: per queste dipendenze avere duplicati nella componente LHS può
essere accettabile, invece non è possibile avere variazioni nei valori dei campi appartenenti alla
componente RHS in un singolo insieme di valori LHS.
Campi derivati: per questi campi si ha a disposizione una formula che determina in modo preciso
quale dovrebbe essere il valore nei campi RHS. In questo caso si testa la regola più che la
dipendenza funzionale.
Sinonimi: le violazioni sui sinonimi sono molto frequenti, perché a livello di DBMS i controlli non
sono forzati. Le violazioni che possono occorrere sono relative a diversi tipi di sovrapposizione e
campi orfani. Quest’ultimi si verificano quando esiste un valore in un campo, si suppone che esista
anche nell’altro corrispondente ma in realtà non c’è. È frequente nelle coppie di sinonimi chiave
primaria/esterna.
4.2.2.4 Sviluppare un Data Model
Dopo aver completato l’analisi strutturale, si hanno abbastanza informazioni per costruire un data model in
terza forma normale. Questo è utile perché verifica la comprensione dei business object rappresentati dai
dati. Dopo aver costruito il modello, esso va comunque revisionato con gli esperti di business, ogni tabella e
relazione devono avere un senso nel mondo degli esperti, se non è così allora non è stata trovata qualche
dipendenza o coppie di sinonimi e bisogna ritornare all’analisi strutturale. Questa fase quindi ha anche
l’obiettivo di controllare la completezza dell’analisi strutturale effettuata.
Metodologie e Strumenti di Data Profiling
38 | P a g i n a
4.2.3 Simple Data Rules Analysis
Una volta identificati tutti i valori non validi all’interno di un campo e tutte le violazioni alle regole
strutturali, si specificano le regole che definiscono come i valori di diversi campi all’interno di un business
object siano una combinazione di valori accettabili. Questa è la definizione di data rule che specifica una
condizione che deve essere vera in ogni istante attraverso uno o più campi.
Le data rules sono un sottoinsieme delle business rules.
In questa analisi, il data analyst e il business analyst raccolgono le regole che devono essere verificate sui
dati, vengono convertite in formato eseguibile e testate. In questo processo inoltre l’insieme di regole viene
memorizzato nei metadati e vengono identificati gli insiemi di record che le violano.
Le data rule sono specifici statement che definiscono condizioni che dovrebbero sempre essere vere. Una
data rule può riferirsi ad una solo campo , più campi della stessa tabella, più campi di tabelle differenti. Le
regole possono riferirsi a dati relativi ad un singolo business object o possono riferirsi a dati relativi a
insiemi di business object.
Le data rule hanno una semantica che solo gli esperti di business riescono a comprendere e sono loro a
doverle definire ad un livello più alto per poi essere tradotte in un linguaggio adatto all’esecuzione dagli
analisti di data profiling che hanno competenze tecniche e non comprendono le regola dal lato del
business.
Ciascun passo di data profiling riguarda la scoperta di problemi dei dati differenti. Trascurare un passo vuol
dire ridurre l’efficienza dell’analisi. Trascurare le data rules può lasciare una lacuna nell’analisi di strutture
complesse.
4.2.3.1 Definizioni
Business Object
Il termine descrive un singolo oggetto del mondo reale; ad esempio, un ordine, un impiegato, o un unico
articolo in inventario. I dati relativi ad un istanza di business object vengono memorizzati in un record.
Un business object viene identificato con la sua chiave primaria. Gli altri campi forniscono informazioni
addizionali.
L’oggetto può anche avere records in altre tabelle. Queste tabelle secondarie danno informazioni
addizionali. Ad esempio, se un impiegato ha più di una laurea una tabella secondaria viene utilizzata per
descriverle tutte. In questo caso, più record possono rendersi necessari nella tabella secondaria per fornire
tutte le informazioni necessarie per ciascun impiegato. Se un impiegato non è laureato, non ci saranno
record nella tabella secondaria.
Anche se un business object è composto da più tabelle esso è considerato con un entità unica
corrispondente alla definizione del oggetto nel mondo reale. Le tabelle secondarie che contengono
informazioni parziali dell’oggetto sono collegate alla tabella primaria attraverso la relazione chiave
primaria/esterna. Queste permettono di vedere l’oggetto come una singola entità.
Metodologie e Strumenti di Data Profiling
39 | P a g i n a
Data Rule
Come detto precedentemente, una data rule è un’ espressione di una condizione che coinvolge più valori
che deve essere soddisfatta su un insieme di dati affinchè essi siano considerati accurati.
Le data rule esaminano i dati in maniera statica. Ciò significa che si guarda il database nel momento in cui
tutti i business object descritti da quei dati ci si aspetta che siano conformi alle regole.
Le Data rules sono regole negative. Ciò significa che l’espressione significa cosa deve essere vero nei dati. A
nessuno interessa sapere cosa è vero nei dati, ma solo ciò che non è vero. Pertanto, l’esecuzione delle data
rules generalmente consiste nel selezionare dati che non sono quello che la regola stabilisce.
Tutte le data rules dovrebbero essere registrate in repository considerando una parte che è la descrizione
testuale della regola. Questa dovrebbe dichiarare in maniera semplice la condizione desiderata. La regola
dovrebbe essere documentata in un linguaggio logico nella seconda parte. La specificazione logica può
essere difficile da comprendere per i business analyst. La descrizione testuale dovrebbe servire come base
per validare se la logica è una specificazione accurata della regola.
Hard VS Soft Data rules
Alcune data rules devono essere necessariamente vere. Ciascuna violazione è considerata un caso di
inaccuratezza. Queste sono dette hard data rules. Per esempio la DATA_ASSUNZIONE dovrebbe essere
sempre dopo rispetto alla DATA_NASCITA. Non ci possono essere eccezioni alla hard rule.
Una soft data rule deve essere vera quasi sempre, ma ci possono essere eccezioni. Per esempio
DATA_ASSUNZIONE deve essere maggiore di DATA_NASCITA + 18. Ciò significa che ci si aspetta che tutti i
dipendenti abbiano più di 18 anni. Comunque, se si assume un genio che ha già un PhD ma ha solo 16 anni,
si ha un’eccezione alla data rule. Le eccezioni in genere richiedono un controllo ulteriore.
Le Soft data rule sono difficili da trattare. Quando c’è una violazione, non indica necessariamente un caso di
dati non accurati.
Una struttura dati ben progettata avrà un campo nel database che indicherà se un’eccezione alla regola si è
manifestata. Nell’esempio degli anni dei dipendenti assunti, un campo booleano può essere usato per chi è
assunto al di sotto dei 18 anni.
Data rules VS Process rules
Una process rule è una regola che agisce sulla base dei valori di uno o più campi. Potrebbe computare il
valore di un altro campo, creare un record in un’altra tabella, cancellare un record, ecc.
Per esempio un processo di business rule potrebbe essere che un Cliente viene classificato come BUONO se
il numero di fatture in ritardo ancora da pagare è minore di due. Un cliente viene classificato come
CATTIVO se il numero di fatture in ritardo è più alto di due. I BUONI clienti hanno uno sconto del 10%. I
cattivi clienti non possono effettuare nuovi ordini. Questa process rule, definisce una classificazione dei
clienti per valutare l’accettazione di nuovi ordini.
Le process rules non sono intese come data validation rules. Sono utilizzate per stabilire i valori e non per
determinare se i valori assegnati sono corretti. Queste regole possono essere trasformate in data rules per
testare lo stato di un database e determinare se le regole vengono usate.
Metodologie e Strumenti di Data Profiling
40 | P a g i n a
4.2.3.2 Il Processo per Simple Data Rule Analysis
La figura mostra un processo per il profiling di business rules.
Figura 13 - Processo per analizzare le simple data rule
Le data rule hanno una grande componente semantica. Bisogna capire come i dati si relazionano con gli
altri dati nel contesto di come il business decide di operare. La semantica non è identificabile attraverso un
tool.
Gathering Data Rule
Il primo passo è raccogliere le data rule che si vogliono applicare ai dati. La maggior parte dei metadata
repository non hanno molte informazioni su come le data rule sono definite. Ci sono altre fonti da guardare
per reperire le regole: source code delle applicazioni che operano sui dati, database stored procedure,
procedure di business in relazione alle applicazioni, e processi di ipotesi sulle data rule con esperti dei dati e
di business .
Source Code delle Applicazioni
Molte data rules sono catturate da milioni di righe di codice che costituiscono le applicazioni software per i
dati. Esistono software commerciali che assistono l’analista nel esaminare il codice sorgente e nell’estrarre
la logica che costituisce le business rule. Le regole estratte sono data rules o process rules.
Nonostante l’analisi del codice sorgente aiuti a comprendere le regole che evolvono nel tempo, questo
approccio è raramente utilizzato. Le ragioni sono:
1. L’analista che effettua il data profiling non ha le conoscenze sui linguaggi di programmazione usati
in molti legacy system.
2. Il processo è noioso e time-consuming.
3. Il codice sorgente potrebbe non essere disponibile, in particolare questo è vero per le applicazioni
eseguibili che non espongono il codice.
Il codice sorgente può forzare il rispetto delle regole, ma comunque anche in questo caso possono esistere
violazioni nei dati per diverse ragioni:
Metodologie e Strumenti di Data Profiling
41 | P a g i n a
1. Il codice in esame potrebbe non essere l’unico path che i dati seguono per entrare nel database, ci
potrebbero essere più applicazioni che costituiscono paths differenti per gli stessi dati. Ad esempio,
un Ordine può essere inserito da un operatore usando un applicazione legacy oppure un
applicazione Internet Xml-based può inserire lo stesso Ordine nello stesso database. Ciascuno di
questi path applica regole differenti.
2. Il rispetto delle regole può essere forzato in fase di data entry, ma non in fase di updates di diverse
applicazioni.
3. Queries ad hoc costruite ed eseguite da database administrator che conoscono come usare il
linguaggio SQL per effettuare modifiche costituiscono altri path.
4. I dati in questione potrebbero essere stati creati prima che il codice sorgente che li utilizza sia
sfruttato; quindi i dati devono essere conformati alle nuove regole dell’applicazione.
Database-Stored Procedures
Le stored-procedures e triggers sono parti di codice sorgente aggiunti al sistema di database per forzare il
rispetto delle condizioni sui dati in inserimenti, aggiornamenti e cancellazioni. Sono molto diffuse nei
sistemi di database relazionali, ma raramente sono disponibili nei vecchi sistemi. Lo scopo è aggiungere
della logica di controllo sui dati al database engine per rilevare le violazioni nei record che vengono inseriti
nel database. Come per l’analisi del codice sorgente, questa pratica è time-consuming e richiede esperti di
linguaggi di programmazione. Una difficoltà è che i vecchi sistemi di database, non conservano gli
statement originali delle procedure in quanto esse sono memorizzate nei database catalog come codice
compilato, dal quale è difficile risalire al codice originale.
Business Procedures
Alcune data rules sono inglobate in business procedures anziché in applicazioni che utilizzano i dati. Le
business procedures sono delle istruzioni su come effettuare la fase di data entry rivolte al personale di
business. Una volta che le regole sono catturate dal business process, possono essere testate sui dati.
Speculation
Un’altra sorgente di informazione è esaminare i valori dei campi e la loro struttura per creare data rules
usando dei criteri. Il processo di ipotesi per ottenere le data rules, deve essere fatto da un team che
comprende esperti di business e dei dati e deve essere l’ultimo passo della fase di raccolta delle
informazioni per sfruttare le review delle regole da parte degli esperti anche per le altre sorgenti.
L’obiettivo dell’analisi delle data rules da parte degli esperti aiuta a migliorare la completezza e
l’accuratezza dell’insieme di regole raccolte.
Tutte le data rules trovate devono essere memorizzate nel data profiling repository.
Testing Simple Data Rules
Una volta che le data rule vengono raccolte, bisogna testarle sui dati. I test vengono fatti attraverso un
software o attraverso l’esecuzione di query sui dati. I risultati dei test sono i record che contengono le
violazioni alle data rule. I risultati vengono memorizzati nel repository.
Metodologie e Strumenti di Data Profiling
42 | P a g i n a
Validazione dei Dati in Output
Dopo aver eseguito le data rule, si ha bisogno di riunire nuovamente il gruppo di esperti per valutare se
l’output è ragionevole. Bisogna stabilire se la formulazione della data rule è corretta, se l’esecuzione è
appropriata e se l’output rappresenta una vera violazione. La validazione può portare modifiche alle data
rules in quanto esse possono essere formulate in modo errato.
Un altro importante obiettivo di questo passo è classificare le regole in base alla loro importanza e al loro
valore nel scoprire i problemi. Questo è importante perché l’esecuzione delle regole è molto costosa in
termini di risorse computazionali e quindi bisogna prendere le giuste decisioni su quali regole eseguire e in
quale momento.
4.2.3.3 Rules for Single Business Objects
In questa sezione mostriamo alcuni esempi di data rules.
4.2.3.3.1 Esecuzione di Data Rules
L’esecuzione di data rules è molto costosa. Può essere fatta in modo automatico o attraverso la
formulazione di query. L’esecuzione è facilitata se i dati sono in forma tabellare che è poi la forma richiesta
per il data profiling, altrimenti per quei data source che non sono in tale forma e che hanno problemi non
risolti, quali fields overloading, può essere molto complessa.
Più dati si usano per l’esecuzione più risorse macchina saranno utilizzate, ma anche se si utilizzano campioni
troppo piccoli nasce il rischio di non raggiungere il risultato.
Le data rules possono essere eseguite non solo singolarmente, ma anche in modo combinato in una singola
esecuzione. Così viene ridotto il costo e il tempo di esecuzione,ma nasce il problema di separare i risultati
(quale regola produce quale output).
4.2.3.3.2 Tipi di Data Rules
Dates
I business object hanno molti campi con data type DATE e TIME, che riflettono la progressione delle attività
relative all’oggetto. Di solito i valori di tali campi che non sono aggiornati indicano valori inaccurati. Esempi
sono BIRTH_DATE, RETIREMENT_DATE, ecc.
Alcuni oggetti includono anche campi TIME_OF_DAY, che posseggono anche il concetto di ordine. Per
esempio un’officina di riparazione di automobili deve avere il valore del campo START_TIME precedente a
quello del campo STOP_TIME per ogni riparazione.
Un esempio di data rule che utilizza campi di tipo DATE è mostrato di seguito. La regola è costruita dopo
aver analizzato i campi e determinato l’ordinamento.
SHIPPING_DATE IS NOT EARLIER THAN ORDER_DATE RECEIVED_DATE IS NOT EARLIER THAN ORDER_DATE
RENEWAL_DATE IS 1 YEAR AFTER CONTRACT_DATE.
Metodologie e Strumenti di Data Profiling
43 | P a g i n a
Duration
Un campo di tipo duration contiene valori che sono il risultato di un calcolo tra coppie di campi DATE o
TIME. Per esempio la funzione YEARS (HIRE_DATE-BIRTHDATE) determina quanti anni aveva un impiegato
quando è stato assunto.
Un esempio di duration rule è:
DAYS(SHIPPING_DATE_ORDER− DATE) LESS THAN 60 YEARS (HIRE_DATE− BIRTHDATE) GREATER THAN OR
EQUAL TO 18
Valori negativi in campi duration indicano un ordine errato dei campi sorgenti.
Object Subgrouping Columns
Un altro caso da guardare per trovare simple data rules è cercare quei campi che dividono il tipo dell’object
in subtypes. Ad esempio GENDER divide gli impiegati in MALE e FEMALE o MARITAL_STATUS divide gli
impiegati in MARRIED e NOT_MARRIED.
La divisione degli oggetti in sottogruppi ha un impatto sui valori accettabili in altri campi. I campi che
definiscono il sottogruppo non possono essere NULL. Un esempio di regola è:
SPOUSE_NAME IS 'BLANK' IF MARRIED_FLAG IS NOT YES DATE_OF_LAST_BIRTH IS NULL IF GENDER IS
'MALE' IF EMPLOYEE_TYPE IS 'PART_TIME' THEN PAY_TYPE IS 'NONEXEMPT'
Work Flow
Questo tipo di regola coinvolge quei dati che sono relativi a objects coinvolti in passi diversi in un processo.
Appena ciascun passo è completato, all’object vengono aggiunti ulteriori dati. Ciascun punto nel processo
definisce uno stato dei dati. Uno stato di solito coinvolge i valori di qualche campo. Ovvero se per uno stato
un passo non è stato completato, il campo di quello stato dovrebbe essere NULL, in caso contrario deve
essere NOT_NULL.
Le regole work flow sono un sottoinsieme delle process rules. Le data rules possono essere costruite da
queste per determinare la correttezza dei valori dentro ciascuno stato valido.
Esempi di work flow data objects sono ORDERS (placed, shipped, received, returned, cancelled),
LOAN_APPLICATION (requested, reviewed, accepted or rejected, made), e EMPLOYMENT_APPLICATION
(received, reviewed, interviewed, background check, offered/rejected, employed). Un esempio di data
rules per work flow process rules:
IF APPLICATION_STATUS IS "REVIEWED" THEN INTEREST_RATE IS NULL IF APPLICATION_STATUS IS
"ACCEPTED" THEN INTEREST_RATE IS NOT NULL
Derived-Value Rules
Un campo può essere determinato da valori di altri campi attraverso policy o procedure di business. Esempi
sono la determinazione di una valutazione di un cliente o di un fattore di rischio su un investimento. Se le
regole per settare questi valori sono sufficientemente deterministiche possono essere convertite in data
rules per essere verificate sui dati.
Metodologie e Strumenti di Data Profiling
44 | P a g i n a
Un esempio:
IF INVENTORY_USAGE_LAST6MONTHS IS 0 AND ONHAND IS GREATER THAN 0 THEN SALVAGE_FLAG=YES
Qualche volta le business rule sono ambigue e non permettono un'unica interpretazione e queste sono
difficili da trasformare in data rules. Ad esempio per definire un BAD customer si possono usare due
definizioni una molto vaga e l’altra più precisa:
1. Un BAD customer è il contrario di un GOOD customer
2. Un BAD customer è colui che ha un debito di $100,000 da più di 90 giorni
La seconda definizione è più precisa e lascia meno spazio a libertà di interpretazione ed è più facile da
trasformare in data rule per poi essere testata, rispetto alla prima.
4.2.4 Complex Data Rule Analysis
Utilizza data rules più complesse che operano su più business object. La differenza con l’insieme di regole
per un singolo business object è che la quantità di dati per testare le regole è maggiore e coinvolge dati di
più business object, identificando violazioni che sono nascoste in un insieme più grande di record.
Memorizzare come fatti di inaccuratezza tutto l’insieme di record che contiene le violazioni è poco
efficiente, invece è più conveniente memorizzare l’identificativo della regola e il numero di violazioni ad
essa. Questa sezione è la continuazione della parte precedente sulla Simple Data Rules Analysis e tratta il
testing delle data rules su un insieme di business object, anzichè data rules relative ad un singolo object.
Molte delle informazioni della sezione precedente valgono in questa. Qui viene descritta un'altra parte del
processo di trovare data rules utilizzate per evidenziare i dati inaccurati.
4.2.4.1 Definizioni
Business Object Set
Un business object set è un insieme di istanze di business object. Ciascun business object rimane comunque
indipendente all’interno dell’insieme, ognuno con i propri campi. L’insieme può includere:
•
•
•
•
Più istanze dello stesso tipo di business object
Record da differenti tipi di business object
Tutti i dati in una tabella
Tutti i dati di un database combinati con i dati di un altro database
Deve essere definito come le diverse istanze devono essere selezionate e come joinare i record tra le
tabelle.
Data Rules
Le data rule sono le stesse dei singoli business object, ma sull’insieme hanno due caratteristiche in più:
devono definire l’insieme e possono effettuare i test con funzioni di aggregazione quali COUNT, SUM,
AVERAGE, o STANDARD DEVIATION.
Metodologie e Strumenti di Data Profiling
45 | P a g i n a
Hard VS Soft rules
Le data rules sugli insiemi possono essere hard rules o soft rule, come nel caso di data rules su singoli
oggetti.
Data Rules VS Process Rules
Molte regole in questo caso sono il risultato di process rules che possono essere molto complesse.
4.2.4.2 Il Processo per il Profiling di Complex Data Rules
La figura mostra il processo per il profiling di data rules su un insieme di business object. È uguale al caso
delle data rule su singoli oggetti. La loro complessità e la natura semantica non le rende adatte alla fase di
discovery e quindi non esiste questo passo nel processo delle complex data rule.
Figura 14 - Processo per il profiling di complex data rules
Gathering Data
Le sorgenti di informazione sono le stesse delle simple data rule, con qualche differenza.
Source Code
Questi tipi di regole sono raramente ottenute dal codice sorgente delle applicazioni che utilizzano i dati. Le
regole presenti nel codice sono regole applicate a singole transazioni.
Database-Stored Procedures
Data rules complesse non sono quasi mai inserite in queste procedure.
Business Procedures
Anche queste procedure raramente contengono regole su più business object.
Metodologie e Strumenti di Data Profiling
46 | P a g i n a
Speculation
La fonte principale per la raccolta delle regole è il processo di ipotesi su data rules che devono essere
rispettate dall’insieme di dati che viene fatto con esperti di business.
Testing Data Rules
Questa è la fase, dopo aver definito le data rule, di testarle sui dati per trovare le violazioni. Qui il test viene
effettuato su un insieme di business object. Richiede perciò tutti i dati rilevanti e di solito prendere
campioni può portare a false violazioni. Inoltre eseguire la fase di estrazione dati al momento sbagliato può
produrre dati incompleti per una funzione di aggregazione. Ad esempio se si utilizza la funzione MONTHLY,
non si possono considerare solo i dati di una parte del mese, ma bisogna attendere che il mese termini e
prenderli tutti.
Validation of Output Data
Il risultato deve essere esaminato dal team di esperti di business e analisti per determinare se le data rule
sono corrette e determinare il significato delle violazioni. Le data rule confermate vengono memorizzate
nel repository.
4.2.4.3 Profiling Complex Data Rules
Vediamo alcune caratteristiche sull’ esecuzione e sui tipi di queste regole.
4.2.4.3.1 Esecuzione di Data Rules
Le regole su più oggetti tendono a essere molto più complesse e la formulazione di queries SQL per testare
una data rule può essere molto difficile e richiedere speciali programmi per la creazione degli statement.
Quello che è importante in questo caso è l’ottimizzazione del processo di esecuzione. Le regole hanno una
logica molto complessa e l’esecuzione può prendere molto tempo perché ad esempio si deve confrontare
ogni record di una tabella con ogni record di un'altra tabella. Inoltre molte regole richiedono l’accesso ai
dati di differenti database nello stesso momento e questo pone problemi di schedule e che tutte le sorgenti
di dati devono avere gli stessi requisiti di tempi di risposta.
4.2.4.3.2 Tipi di Complex Data Rules
Le data rules per più business object possono avere diverse forme. Vediamo alcuni esempi. Esistono due
principali categorie di complex data rules: rules che sono relative ai valori di un campo e rules relative alle
funzioni di aggregazione.
Dates And Time
Più istanze dello stesso tipo di oggetto non possono condividere lo stesso spazio allo stesso tempo.
L’esempio ovvio di questa affermazione sono i campi DATE e TIME. Un esempio può essere il caso di
noleggio di attrezzature. Una data rule dice che un singolo pezzo di attrezzatura non può essere noleggiato
allo stesso tempo da più di un cliente. Se i record mostrano una sovrapposizione esistono errori nei dati. Il
test è raggruppare i record per tipo di attrezzatura e per ogni record si effettua un confronto con tutti gli
altri record. Il test, assumendo che tutti i record hanno la data di inizio precedente a quella di fine, è:
IF RECORD2.END_DATE&TIME IS EARLIER THAN RECORD1.START_DATE&TIME THEN OK ELSE IF
RECORD2.START_DATE&TIME IS LATER THAN RECORD1.END_DATE&TIME THEN OK ELSE ERROR
Metodologie e Strumenti di Data Profiling
47 | P a g i n a
Classificare i record per OBJECT_IDENTIFIER e START_DATE&TIME rende l’esecuzione più efficiente.
Un altro test che si può effettuare tra gli oggetti è il calcolo delle durate, ovvero del tempo trascorso tra
due eventi registrati in campi DATE o TIME. Osservando la durata si può valutare se essa sia ragionevole, i
casi limite ovvero quando è troppo lunga o troppo corta possono far scoprire problemi di in accuratezza dei
dati. Un esempio tipico per questo è il caso dell’albero genealogico: i record che definiscono una persona in
un albero genealogico devono soddisfare delle relazioni di date e time con altri record dell’albero. Ovvero il
record che rappresenta un padre deve avere una durata di tempo ragionevole tra la sua data di nascita e la
data di nascita del figlio. Un figlio non può essere nato dopo che il genitore è morto.
Location
Il tempo può non essere l’unico fattore che causa l’incompatibilità tra due oggetti. Le location sono un altro
esempio. Consideriamo un database Inventario che ha un campo per posizione di immagazzinamento, se si
scoprono due oggetti con la stessa posizione fisica questo indica che qualcosa è scorretto.
Altri Tipi di Esclusività
Ci possono altri campi che hanno relazioni esclusive tra i record di una tabella. Per esempio il campo
MOGLIE di una tabella Impiegati. Non dovrebbero esserci due impiegati che hanno la stessa moglie.
Questo può essere accaduto perché un impiegato ha divorziato e la ex moglie si è sposata con qualcuno
della stessa azienda e il valore STATO del primo impiegato non è stato aggiornato in CELIBE e questo ha
creato l’incompatibilità al momento della modifica dei dati dell’altro impiegato.
Aggregazioni
Le aggregazioni sono dei test effettuati su un gruppo di oggetti. I tipi di valori aggregati che possono essere
oggetto delle regole sono COUNT, SUM, AVERAGE, MEDIAN, STANDARD DEVIATION, ecc.
Sono buone regole per controllare la completezza. Per esempio questa regola controlla che il numero
minimo di viaggi fatti da un camion dovrebbe essere almeno 10 per mese.
GROUPBY TRUCK, MONTH IF OUT-OF-SERVICE NOT YES THEN NUMBER_TRIPS GREATER THAN 10
Lookup
Un altro modo di identificare l’esistenza di dati inaccurati è confrontare i dati in un campo di un database
con i dati di un altro campo di un database differente che dovrebbero contenere gli stessi dati. Questa è
un'altra forma per verificare che un valore è nell’insieme di valori accettabili.
Ovviamente nasce il problema che il database con cui effettuare il confronto contenga effettivamente dati
accurati, altrimenti se si confrontano i dati e si rileva un’inaccuratezza non si sa quale delle due sorgenti
contiene l’errore.
Metodologie e Strumenti di Data Profiling
48 | P a g i n a
4.2.5 Value Rule Analysis
Talvolta l’esistenza di dati inaccurati può essere esplicitata da valori numerici di aggregazione. Per esempio
la frequenza di un valore in un campo può indicare all’analista che la distribuzione dei dati non è realistica.
Ovviamente per fare questo, l’analista deve possedere una distribuzione attesa ragionevole per effettuare il
confronto.
Esempi di questi valori aggregati sono: cardinalità, conteggi, somme, mediane, frequenze, deviazioni
standard, ecc.
Spesso non è possibile convertire tali indicatori in regole che dicono che un particolare valore deve essere
in quella x percentuale o che dovrebbe cadere in un dato range.
L’analista deve acquisire le regole dal business analyst, eseguire i controlli e presentare i risultati al business
analyst per validarli.
Nei precedenti quattro capitoli sono state discusse le proprietà dei campi, la struttura dei dati e le data
rule, che forniscono una specifica definizione di ciò che è valido e ciò che non è valido.
I test che rilevano la presenza di dati inaccurati ma che non sono così precisi nello stabilire un chiaro limite
fra giusto e sbagliato sono chiamati value rules.
Si calcola un valore o più i valori dai dati e poi si usa l’ispezione per determinare se l’ouput è ragionevole o
no. Si possono facilmente distinguere gli estremi del ragionevole e dell’irragionevole, ma non si può esser
sicuri di cosa accade al centro (fuzzy area).
4.2.5.1 Definizioni
Value Rules
Una value rule è la computazione di uno o più valori dai dati. Sono memorizzate nel repository.
Ispezione Visuale
Questo è il processo di revisione dei risultati per determinare se il risultato combacia con le aspettative.
4.2.5.2 Processo di Value Rule Analysis
Il processo è mostrato nella figura. E’ un semplice processo di creazione ed esecuzione dei test e di
revisione dei risultati.
Figura 15 - Processo di value rule analysis
Metodologie e Strumenti di Data Profiling
49 | P a g i n a
Gathering Value Rule
È necessario raccogliere le value rule dagli utenti che utilizzano i dati. Coloro che comprendono
l’applicazione e lavorano con i dati tutti i giorni sono in grado di fornire un contributo prezioso. Questo
include gli analisti di business e esperti.
È necessario ipotizzare i risultati prima di eseguire i test. Queste ipotesi dovrebbero essere documentate.
Executing Value Rules
Poichè le value rule spesso trattano con valori di aggregazione, è importante che tutti i dati siano utilizzati.
Utilizzando i campioni si possono produrre risultati non accurati, anche se i dati possono essere precisi. La
ragione di questo è che i campioni possono includere solo alcuni dei dati.
Evaluating Results
I risultati devono essere verificati da un gruppo di analisti e esperti di business che devono ricercare
problemi di accuratezza.
Metodologie e Strumenti di Data Profiling
50 | P a g i n a
5 Altre Metodologie
Le metodologie descritte in questa sezione sono state derivate da tutte le possibili informazioni sui prodotti
commerciali di data quality/data management delle diverse aziende esaminate. Business Data Quality Ltd
(BDQ) Metodologia
È un’azienda software specializzata in soluzioni next- generation rivolte ad aiutare le organizzazioni a
sfruttare il vero potenziale dei dati attraverso lo sviluppo di concrete data analysis e management
products. È situata in Inghilterra, precisamente a Londra. (www.businessdataquality.com)
Secondo la BDQ Ltd, la tecnologia del data profiling può essere facilmente integrata in un progetto di data
management esistente. Essa supporta, accelera e migliora molte attività relative alla data analysis.
La soluzione proposta prende il nome di BDQ Analysis, che permette di ottenere un accurata e dettagliata
comprensione dei dati, offrendo un’unica vista del contenuto e della qualità. La Figura 16 - Processo di
comprensione dei dati mostra i tre passi su cui è basato il processo di comprensione dei dati.
Figura 16 - Processo di comprensione dei dati BDQ
La fase di analisi utilizzando i diversi tipi di tecniche che mostreremo nel seguito, permette di rilevare le
anomalie e di costruire una comprensione completa dei dati molto più velocemente rispetto agli approcci
tradizionali.
I dati hanno differenti stakeholders, e ognuno li utilizza in modo proprio per raggiungere gli obiettivi
definiti. BDQ Analysis si basa su un architettura centralizzata che integra le funzioni di profiling, di
management dei risultati e di reporting per rispondere alle esigenze dei diversi utenti.
Figura 17 - Stakeholders del data profiling
Mentre con altri approcci, l’output dell’analisi dati può essere catturata in diversi formati (fogli di calcolo, emails, database ad hoc, ecc.) con la necessità di più tools per gestire i risultati con il rischio di perdere
Metodologie e Strumenti di Data Profiling
51 | P a g i n a
alcune informazioni chiave, BDQ Analysis centralizza la gestione dei risultati offendo un unico supporto per
memorizzarli e condividerli.
Il data profiling offre molti benefici a qualunque utente utilizzi i dati e può essere un ottimo strumento di
comunicazione tra le figure tecniche, di business e di management di un team.
5.1.1 Metodologia Generale
La Figura 18 - Passi metodologia generale BDQ profiling mostra i passi della metodologia di data profiling
proposta dalla BDQ e inserita in un progetto di analisi dati.
Figura 18 - Passi metodologia generale BDQ profiling
La prima fase Scope è di pianificazione dell’analisi in cui può essere necessaria la stesura di un piano di
progetto per pianificare e controllare il processo di profiling. I principali motivi per i quali il piano di
progetto è utile per il data profiling sono:
•
•
•
•
stabilisce le tempistiche da rispettare
definisce tempi e contenuto dei risultati intermedi da produrre
descrive le politiche, le procedure e gli standard da seguire
assegna il carico di lavoro ai partecipanti al processo
In questa fase possono anche essere utili attività di team training: il team di analisi deve prendere
familiarità con il materiale di supporto all’analisi e con i tool da utilizzare. Inoltre deve prendere coscienza
con il piano di progetto, che ne descrive le tempistiche per organizzare il lavoro in modo corretto e
rispettare i tempi. È importante esaminare la documentazione disponibile sul sistema e anche di ottenere
informazioni sulle procedure di accesso al data source e ad un eventuale metadata repository.
La fase di estrazione dati prevede sia l’estrazione dei dati per la derivazione dei metadati che la
trasformazione dei dati nei formati adatti all’analisi, per esempio dati che non presenti alla giusta
granularità. Si prevede l’uso di programmi di estrazione. Inoltre si procede a preparare il caricamento dei
dati attraverso la creazione di file csv (comma separated value) per contenere le strutture relazionali, ogni
Metodologie e Strumenti di Data Profiling
52 | P a g i n a
campo è separato da una virgola e la prima riga del file contiene il nome delle colonne (usati anche per i
metadati). Infine si procede a creare la connessione ODBC appropriata.
Anche se non evidente dalla figura sopra è prevista una fase di raccolta dei metadati (ad esempio le librerie
che descrivono le innumerevoli strutture dati e regole) non è banale. Quest’informazione cruciale spesso
non è accessibile oppure non aggiornata. Di solito queste informazioni vengono prodotte durante
l’implementazione del sistema e memorizzate in documenti di testo che non vengono collegati fisicamente
al sistema. La documentazione del sistema oltre ad essere sparsa nell’organizzazione e anche non
aggiornata, in quanto per naturale evoluzione il sistema cambia e le modifiche non vengono riportate nella
documentazione. Il vantaggio del data profiling è che non si basa solo sulla documentazione esistente, ma
direttamente dai dati vengono ricavate le strutture e le regole che governano i dati stessi, eliminando le
assunzioni non corrette e i problemi trascurati. Una buona soluzione di profiling dovrebbe mettere a
disposizione un framework per catturare e mantenere un dizionario dei dati accurato.
La metodologia prevede anche una fase di Issue Managemet. Una tecnologia di data profiling deve
integrare un supporto per documentare e gestire il ciclo di vita dei problemi di qualità scoperti all’interno
dei dati. Tale supporto si traduce in un repository centrale condiviso di tutti i problemi aperti e risolti, che
offre la possibilità di linkare gli elementi del repository (data quality facts) alle strutture e records nel data
source che sono interessati da tali problemi. Tutto questo si rende indispensabile per quelle analisi che
identificano in modo frequente molti problemi nei dati (ad esempio 300 problemi a settimana) la cui
gestione senza opportuni supporti è impossibile. Il vantaggio di avere un unico strumento che identifica e
gestisce i problemi di qualità è quello di poter collegare direttamente la descrizione del problema con
l’elemento affetto da esso. Le funzioni offerte dal modulo di issue management sono: assegnare le priorità,
verificare lo stato (track progess), suddividere in categorie, tracciare la storia, possibilità di creare report in
formati quali HTML, Microsoft Excel e CSV format.
Metodologie e Strumenti di Data Profiling
53 | P a g i n a
5.1.2 Metodologia di Dettaglio
Vediamo alcuni tipi di analisi per eseguire il profiling proposte dalla BDQ.
Una soluzione di data profiling completa si basa su un’analisi a tre dimensioni, piuttosto che essere limitata
ad un solo tipo di analisi (column profiling), come accade per l’analisi manuale.
Figura 19 - Tipi di analisi BDQ
Column Profiling
Analisi rivolta al singolo attributi per catturare le caratteristiche basilari come data type, percentuale di
valori nulli, distribuzione dei valori, range di valori e lunghezza del campo. Inoltre rispetto ad un’analisi
manuale il data profiling per questo tipo di analisi fornisce alcune capacità aggiuntive:
•
•
•
•
la capacità di analizzare l’intero data source piuttosto che un sottoinsieme di record o attributi in
un tempo accettabile dal team
generazione e verifica di pattern data. Per esempio campi come codici postali, identificativi di
clienti dovranno essere conformi a strutture alfanumeriche standard (pattern). La verifica dei
pattern permette un immediato riconoscimento dei valori non standard. A volte la diversità nel
formato di uno stesso tipo di dato è dovuto all’introduzione di caratteri speciali che bisogna
eliminare per riportare i valori nel formato richiesto. Ad esempio se abbiamo due valori uguali con
formati differenti 123-45-6789 e 12-3456789, e il pattern (3)-(2)-(4) deve essere rispettato il
secondo valore necessita di una correzione.
Calcolo delle frequenze dei valori per permettere agli analisti di identificare valori duplicati ed
estremi.
Controllo di valori nulli, minimi e massimi.
Key Testing
Il key testing permette di verificare l’univocità dei valori di quegli attributi candidati ad essere chiavi
primarie di una tabella. Cosi il principale controllo che viene eseguito si basa sulla ricerca di valori duplicati
all’interno di un campo considerato chiave di quella tabella. Comunque una buona soluzione di data
profiling dovrebbe, per una completa comprensione dei dati e rilevazione dei problemi di qualità,
permettere di analizzare non solo il singolo attributo ma anche le relazioni tra questi all’interno di una
stessa tabella (chiavi composte) o tra tabelle diverse (coppie chiavi primarie/esterne).
Metodologie e Strumenti di Data Profiling
54 | P a g i n a
Dependency Testing
Il dependency test si focalizza sulle relazioni tra valori di attributi differenti in una tabella. In quest’ analisi
l’enfasi è sulla consistenza e non sull’univocità. Ad esempio supponiamo che la combinazione di valori dei
campi Country e PostalCode sia sempre correlata a valori consistenti di City e Region. Più precisamente,
consideriamo la combinazione Country UK e Postal Code MK1, questa dovrebbe sempre occorrere insieme
alla City Milton Keynes all’interno dei record della tabella.
L’analisi si basa sul test di combinazioni di questo tipo e ritorna il grado di correlazione in percentuale dei
valori e i record che soddisfano e non le combinazioni. Nel nostro esempio le percentuali sono sui campi
City e Region e dicono quanto i valori di questi due campi sono in combinazioni accettabili con i valori dei
campi Country e PostalCode. Una percentuale bassa indica problemi di consistenza che di solito sono dovuti
a valori mancanti nell’attributo che deve essere in correlazione.
Join Testing
Testa la consistenza dei dati attraverso più tabelle, anche di sistemi differenti. Infatti è di importanza
cruciale nei progetti di integrazione dati da differenti data sources. Per fare un esempio consideriamo due
tabelle Sales Area e Country di due sistemi differenti contenenti ciascuno l’attributo AREA_ID. Un join test
su questi campi potrebbe dare il seguente risultato:
Figura 20 - Esempio di Join Testing
Sales Area contiene 123 record e tutti i valori del suo AREA_ID sono univoci. Country contiene 291 record e
il proprio AREA_ID contiene tutti i 123 valori di Sales Area. Quindi tutti i valori di Sales Area hanno un valore
corrispondente in Country. Il fatto che ci siano altri record in Country non è preoccupante purchè ci siano
tutti i valori di Sales Area.
Quindi questo tipo di test è utile per verificare le corrispondenze di valori tra attributi in tabelle differenti.
Metodologie e Strumenti di Data Profiling
55 | P a g i n a
5.2 The Data Warehousing Institute (TDWI) Metodologia
Molti dei paper considerati della TDWI sono sponsorizzati dalla DataFlux. La metodologia utilizzata dalla
DataFlux viene descritta meglio nel seguito, il ruolo in questa sezione è di collaborazione con il TDWI.
5.2.1 Metodologia Generale
Come per gli altri casi di studio, ho cercato di trarre le informazioni sulla metodologia adottata dal TDWI e
ho scoperto che il processo di data profiling viene diviso in 4 fasi:
•
•
•
•
Initiation: è una fase di pianificazione in cui si decidono gli obiettivi, le piattaforme e i tool da
utilizzare, i database e gli standard di connessione ai file e di sicurezza
Data Sampling: questa fase identifica il basic profile dei dati attraverso tecniche di campionamento
Discovery: questa fase identifica il complete profile che riguarda tutti i dati. Le caratteristiche della
piattaforma possono limitare l’esecuzione di questa fase su tutti i dati, in questo caso si effettua su
alcuni campioni.
Analysis e rewiev: questa fase permette di documentare i risultati, la definizione delle regole di
miglioramento della qualità.
5.2.2 Metodologia di Dettaglio
A seconda degli obiettivi e della natura dei dati si possono effettuare tre tipi di analisi:
1. Valutare la struttura dei dati: dalla prima valutazione dei metadati, un’analista può ottenere un
vista generale della qualità e della struttura dei dati localizzando aree di possibili problemi. I
metadati identificano il numero di record e valori nulli in ogni campo, data type, lunghezza dei
campi, pattern data, relazioni con altri campi, ecc.
I tool di profiling permettono di catturare metadati accurati scansionando i valori in ogni campo di
una tabella. Da queste informazioni è possibile identificare anomalie nei metadati che sono
sintomo di problemi di qualità. Vediamo un esempio.
Figura 21 - Esempio di analisi dei metadati con dfPower Profile della DataFlux
Come si nota le anomalie sono presenti in Phone Number, dove ci sono 7 diversi data pattern, 681
valori nulli, lunghezza minima del campo di 1 e massima di 14. Questo si traduce in un gran numero
di incompleti e mancanti valori nel campo e la violazione dello standard a 10 cifre dei numeri di
telefono americani.
Metodologie e Strumenti di Data Profiling
56 | P a g i n a
Un altro possibile test è il pattern matching per vedere in questo caso se i 7 data pattern
rappresentano sequenze valide di numeri di telefono. In particolare il tool usa questa convenzione
per costruire i pattern: 9 per indicare gli interi, A per indicare caratteri maiuscoli e a per i caratteri
minuscoli. Si scopre che la sequenza (999-999-9999 non ha nessun record associato e quindi frutto
di un errore di digitazione di una parentesi prima del numero di telefono e quindi bisogna costruire
una regola di standardizzazione per conformare ad uno standard i valori con errori di digitazione.
2. Esaminare i valori dei dati: utile per determinare se i dati rispettano le business rule e in caso
negativo bisogna creare delle regole per trasformare i dati in modo che rispettino gli standard
aziendali. Un esempio di analisi sui valori è riferito ad un campo state, la cui anomalia è quella di
avere 64 valori unici quando ci sono solo 50 stati in USA. Con un’analisi della frequenza dei valori si
arriva alla conclusione che ci sono 5 diversi valori per Ohio, alcuni dei quali non rispettano lo
standard postal code OH. Questi valori devono quindi essere standardizzati.
3. Analizzare le relazioni: utile per comprendere le relazioni dei record all’interno di una tabella o tra
più tabelle, ad esempio per verificare le relazioni chiave primaria/esterna. Un tipo di controllo in
quest’analisi è quello di ridondanza per confrontare i record e determinare sovrapposizioni nei
differenti campi.
5.2.3 Le 4 Aree del Data Profiling
Il TDWI descrive le 4 aree del data profiling : data discovery, data profiling, data monitoring, and
collaboration sui risultati. Analizziamo meglio queste pratiche:
•
•
•
•
Data Discovery: è la pratica che permette di identificare nuovi data source, scoprire inconsistenze,
trasformazioni e sovrapposizioni di dati tra più sistemi, ricostruire le strutture dati distribuite su più
sistemi e trovare la migliore data source di destinazione.
Data Profiling: permette di sviluppare un data inventory ed offre i profiles che sono direttamente
utilizzabili in una varietà di strumenti e progetti.
Data Monitoring & Remediation: valuta lo stato dei dati quotidianamente e permette di tracciare la
loro evoluzione, ponendo rimedio ai problemi di qualità identificati.
Collaboration: permette la condivisione dei profile, degli artifact e di altri risultati tra gli esperti
tecnici e di business e qualunque altro user dei dati.
5.2.4 Best Practices per il Data Profiling
Il TDWI elenca 7 best practices per il data profiling:
1. Il data profiling aiuta a pianificare meglio e a eseguire meglio il progetto: Il data profiling è un
fattore di successo per le diverse iniziative che coinvolgono i dati e quindi deve essere eseguita
come la prima di tutte le attività per comprendere i dati e mitigare i rischi di progetto, quali
sforamento di budget e tempi. I motivi per i quali di solito il data profiling non viene effettuato
sono: errate assunzioni sulla conoscenza dei dati e sottovalutazione del profiling considerata un
attività secondaria, la quale è la prima ad essere eliminata in caso di sforamento di tempi e/o
budget. Il data profiling collabora con le altri fasi di un progetto data-driven (data integration, data
quality, ecc.) rilasciando risultati di alta qualità (metadati, identificazione problemi di qualità,
definizione di regole di risoluzione).
2. Sfruttare il Data Discovery: effettuare il data profiling in modo approfondito utilizzando il data
discovery per scoprire tutte le possibili sorgenti.
Metodologie e Strumenti di Data Profiling
57 | P a g i n a
3. Il data profiling è un task ricorrente: bisogna effettuare il data profiling sui dati appena nuovi data
source diventano disponibili oppure appena si verificano cambiamenti (modifiche delle strutture o
popolazione con nuovi dati).
4. Analisi Cross-System: il profiling non deve essere fatto solo su una parte del data source (tabelle o
frammenti di tabelle), le informazioni statistiche sui campi di una tabella sono utili ma non
abbastanza, invece è necessaria un’analisi cross-system dell’intero data source per scoprire chiavi,
business rules, mappings, trasformazioni, ecc.
5. Il data profiling si divide in due tecnologie, applicate a differenti fasi del progetto: nelle fasi del
progetto quali pianificazione, progettazione e sviluppo il profiling è utilizzato come data discovery e
per creare documentazione. Nelle fasi quali rilascio e manutenzione, il data profiling si trasforma in
data monitoring che esegue l’attività di profiling quotidianamente per assicurare continuamente la
qualità dei dati. Poiché viene eseguito frequentemente senza un tool automatico il monitoring è
quasi impossibile. I tool permettono velocità e efficienza nell’esecuzione dell’attività e supportano
la memorizzazione dello stato dei dati, la definizione di business rules per identificare gli errori.
6. Collaborare attraverso il data profiling: condividere i risultati ottenuti dal processo. Questo implica
che tutti i risultati siano documentati, ma la documentazione è una pratica poco comune perché
difficile da produrre e aggiornare in quanto è time-consuming. Inoltre tutta la documentazione
deve essere posta in un repository centrale accessibile facilmente per recuperare risultati, glossari,
mappings, ecc. Questa attività può essere supportata da tools che permettono a tecnici ed esperti
di business di aggiornare i profiles e riusarli per più progetti aumentando la produttività,
l’accuratezza e la consistenza.
7. I tool automatici di data profiling hanno più vantaggi dei metodi manuali: molti utenti effettuano
il profiling attraverso query ad hoc e registrano i risultati in files come word, csv e altri formati.
Questa forma di documentazione raramente è aggiornata e difficile da integrare in soluzioni di data
integration o data quality. I metodi manuali sono time-consuming e inclini agli errori. I data
profiling tool permettono di ottenere maggiore accuratezza e completezza dell’analisi. I tool
disponibili sul mercato si presentano come:
• tool dedicati al solo task di profiling che permettono di esportare i risultati in formati
standard per facilitare l’integrazione con altri tool (integrazione possibile)
• insieme di funzioni di profiling all’interno di tool più complessi di data integration o data
quality (integrazione definita)
Metodologie e Strumenti di Data Profiling
58 | P a g i n a
5.3 IBM Metodologia
Anche per questo caso di studio, ho cercato di trarre le informazioni sulla metodologia adottata dall’IBM
dai documenti reperiti sul sito aziendale.
5.3.1 Metodologia Generale
Il data profiling è definito come un processo e non come un tool, il quale è suddiviso in diverse fasi.
1. Pianificazione: identificazione degli obiettivi di DQ e dei business data element candidati per il data
profiling. Inoltre individuazione dei data source necessari.
2. Trasferimento : trasferire i dati in un ambiente dove possa essere eseguita un’ analisi di grandi
volumi di dati, senza influenzare i tempi di risposta di altri sistemi (transizione, data warehouse,
ecc.). Questa fase può essere evitata se c’è la disponibilità di macchine robuste e tool che
supportano il parallel processing.
3. Analisi: scoprire quale è il contenuto del data source e costruire tutti i possibili insiemi di DQ rule
da confrontare con i dati.
4. Ricerca problemi DQ: si confrontano le DQ rule con i dati per determinare il grado di matching tra
le rule e i dati e identificare eventuali problemi di qualità.
5. Verifica risultati: controllare i risultati ottenuti con esperti di business che conoscono i dati.
6. Pianificare il miglioramento della qualità dei dati: dai risultati dell’analisi si possono ottenere
informazioni necessarie per pianificare attività di risoluzione dei problemi di DQ e migliorare la
qualità dei dati.
Il processo è iterativo. Infatti se il matching tra i dati e le DQ rule non è positivo questo implica che la
ripetizione dei passi dal 3 al 5 utile per raffinare le DQ rule in base ai risultati ottenuti e al parere dei data
steward. Ad esempio, un data steward potrebbe dichiarare che un campo contiene interi compresi tra 300
e 850, ma i risultati dimostrano che esiste più di un valore 999. A quel punto si ricorda che in fase di
progetto tale valore è stato scelto per rappresentare valori unknown e quindi la rule deve essere riscritta.
Inoltre un matching negativo può semplicemente indicare dati di scarsa qualità che richiedono un
intervento.
5.3.2 Metodologia di Dettaglio
Ci sono quattro tipi di analisi di data profiling:
Column Property Analysis: è un’analisi che si focalizza sul singolo campo indipendentemente dagli
altri. L’output fornisce informazioni su valori, frequenza, univocità, pattern, data type, dimensione,
lunghezza, range, valori massimi e minimi. Le DQ rule di questo tipo di analisi sono le più semplici.
I risultati permettono all’analista di: scoprire i metadati e i problemi di qualità del contenuto,
confrontare i dati con i requisiti e analizzare i valori non validi, di default e quelli mancanti.
Structural Analysis: si focalizza su come i vari tipi di dati (paziente-prescrizione, cliente-ordine)
sono legati attraverso relazioni. Vengono analizzati i possibili attributi che sono identificatori per
verificare che contengano valori univoci. Inoltre assicura che un dato che dovrebbe esistere solo se
è presente una relazione, esista quando la relazione non è definita, ad esempio questo tipo di
analisi rileva se un account esiste senza un cliente, se l’azienda ha definito una regola che un
elemento account è presente solo se è definito un elemento cliente.
Metodologie e Strumenti di Data Profiling
59 | P a g i n a
Data Relationship Analysis: quest’analisi si concentra sulle relazioni tra i dati. Il primo tipo testa le
relazioni dentro un singolo record o business object per assicurare che ci siano combinazioni di
valori accettabili. Per esempio, in una tabella cliente c’è un campo nome cliente e un campo tipo
cliente che può assumere i valori business o personal e una DQ rule che dichiara che se il tipo è
personal allora il campo nome è obbligatorio, invece se il tipo cliente è business, il nome è
opzionale. Il secondo tipo testa le relazioni tra i dati su più tabelle o business object.
Domain Analysis: quest’analisi si focalizza sui valori per scoprire aggregazioni, conteggi o frequenze
che non sono ragionevoli.
5.4 DataFlux Metodologia
La DataFlux è una compagnia SAS che fornisce alle aziende soluzioni di data management per ottenere il
massimo valore dai loro dati garantendo l’accuratezza, la consistenza, la riusabilità e l’affidabilità dei dati.
Soluzioni data quality-driven che permettono il successo di progetti di data migration, data governante,
master data management, data warehouse, customer relationship management (CRM), enterprise re
source planning (ERP) e database marketing. La metodologia di data management adottata comprende
pratiche di data profiling, data quality, data integration, data enrichment e data monitoring. Il primo passo
di tale metodologia è il data profiling che permette di capire la struttura e le relazioni delle informazioni
esistenti prima di migliorare i dati. Il tool di automazione prende il nome di dfPower Studio.
www.dataflux.com per approfondimenti sulle metodologie e le soluzioni di data management.
5.4.1 Metodologia Generale
Il data profiling è il primo passo di una metodologia di data quality composta da fasi quali:
•
•
•
•
•
data profiling, effettua l’analisi dei problemi nei dati,
data quality (standardizing, validating and verifying your data) che inizia il processo di correzione
dei problemi nei dati,
data integration (accessing, linking and connecting data from multiple sources),
data enrichment (augmenting and enhancing your data),
data monitoring (continual examining and auditing your data based on pre-built business rules).
Figura 22 - Metodologia DataFlux
Metodologie e Strumenti di Data Profiling
60 | P a g i n a
5.4.2 Metodologia di Dettaglio
Structure discovery
Permette di definire se i dati in una campo o tabella sono consistenti e incontrano i requisiti.
Esistono diversi modi per effettuare una structure discovery:
•
•
•
Confrontare i dati con i metadati associati, che sono una descrizione delle caratteristiche dei dati.
Questi metadati possono essere nella forma di copy book COBOL, repository di DB relazionali, file di
testo, ecc. I metadati contengono informazioni che indicano datatype, lunghezza dei campi, valori
nulli o univoci, ecc. e vengono inferiti direttamente dal data source per determinare se i dati
rispettano le aspettative degli sviluppatori quando i data source sono stati creati.
Pattern matching: è utilizzato per determinare se i dati in un campo sono nel formato esatto e
verificare che un dato è consistente in diversi data source. Per esempio si attraverso il pattern
matching si può verificare che un numero di telefono contenga tutti i numeri.
Statistiche: alcune informazioni statistiche possono dare un’analisi della validità dei dati. Queste
includono valori minimi e massimi, mediane, deviazione standard, ecc.
Content Discovery
La structure discovery indica le aree problematiche che hanno bisogno di indagini più approfondite. La
content discovery aiuta a determinate quali valori dei dati sono inesatti, incompleti o ambigui. Le tecniche
di quest’analisi sono:
•
•
•
Standardization: permette di rilevare quei casi in cui i valori hanno lo stesso significato ma sono
rappresentati differentemente. Ad esempio I valori “GM”, “General Motors”, “G.M.”, “g.m.” e
“Genrl Mtrs” rappresentano tutti la stessa compagnia. Questi sono detti valori non standardizzati.
Frequency Counts and Outliers: quest’analisi calcola la frequenza dei valori nell’occorrenza dei dati
presenti e permette ai business analyst di evidenziare possibili area che devono essere
approfondite. L’individuazione degli outlier permette di isolare quei valori che sono notevolmente
differenti da altri valori, ad esempio il valore minimo e massimo per una serie di dati. Questa
tecnica è utile sia per i dati numerici che di carattere.
Business Rule Validation: si possono controllare i dati in base alle business rule specifiche per ogni
azienda.
Relantioship Discovery
Molto spesso i dati rilevanti, sono sparsi su differenti tabelle o perfino diversi data store e questo rende
difficile la comprensione. Questo tipo di analisi permette di scoprire le relazioni tra i dati nei data source,
che descrivono entità più complesse come primary/foreign key relationships, cross-table relationships,
cross-database relationships
Alcuni problemi che possono essere rilevati sono ad esempio:
•
•
•
un ID Cliente esiste in un Ordine, ma non corrisponde a nessun Cliente nel database
avere più occorrenze di Cliente con lo stesso ID
si è venduto un prodotto che non esiste, un ID Prodotto esiste in un Ordine ma non corrisponde a
nessun prodotto
Metodologie e Strumenti di Data Profiling
61 | P a g i n a
5.5 Informatica (The Data Integration Company) Metodologia
Le informazioni ottenute su questa azienda, non hanno delineato una precisa metodologia adottata per
l’applicazione del data profiling, viene invece descritta la propria soluzione (insieme di tool) per supportare
le iniziative di DQ, quindi ho dedotto una possibile metodologia generale e di dettaglio dalla descrizione dei
tali tools.
La soluzione prende il nome di Informatica Data Explorer e comprende un tool per il data profiling.
5.5.1
•
•
•
•
Metodologia Generale
Processo di analisi
Condivisione risultati : memorizzazione in repository dei profiles dei dati per accedere e riusare i
risultati, con la possibilità di annotazioni (tags) su ogni elemento del repository
Management dei problemi DQ: documentazione, flag per la risoluzione e comunicazione attraverso
e-mail
Mantenimento del profiling effettuato continuamente e analizzando i cambiamenti al data source
5.5.2 Metodologia di Dettaglio
È adottato un profiling a tre dimensioni per scoprire il contenuto, la struttura e la qualità di complesse
strutture dati:
•
•
•
Column profiling: analizza tutti i valori all’interno di ciascun campo per raccogliere i metadati e i
problemi di qualità del contenuto.
Single-table structural profiling: esamina le relazioni di ciascun campo con ogni altro campo nella
stessa tabella, per scoprire problemi legati alla struttura dei dati (chiavi primarie e dipendenze tra
campi).
Cross-table structural profiling: confronta i dati tra tabelle diverse, determinando quali attributi
contengono sovrapposizioni di valori e scoprendo duplicati all’interno del sistema e chiavi esterne.
Figura 23 - Metodologia di dettaglio Informatica
Metodologie e Strumenti di Data Profiling
62 | P a g i n a
6 Confronto tra le Metodologie
Nel seguito riportiamo il confronto tra le varie metodologie studiate sia per quella generale che di dettaglio.
Le celle marcate con X (maiuscola) vuol dire che la metodologia specifica in modo chiaro una data fase;
invece le celle marcate con x (minuscola) indica che la metodologia accenna ad una determinata fase senza
fornire dettagli.
Metodologia generale
OLSON
BUSINESS DATA QUALITY
TDWI
IBM
DATAFLUX (SAS COMPANY)
INFORMATICA
PIANIFICAZIONE
Piano Progetto
X
(set scope and assign activities)
x
X
X
Team Training
Identif. Data Source
X
X
X
X
x
x
Procedure Accesso
X
X
X
x
x
x
Scelta Tools
X
X
x
Scelta Piattaforma
(Trasferimento Dati)
x
X
X
x
x
x
RACCOLTA METADATI
X
X
ESTRAZIONE DATI
Campionamento
X
X
X
Estrazione Metadati
X
X
X
X
x
Trasformazione Dati
X
X
ANALYSIS
X
x
X
X
x
X
VALIDATION
X
x
x
X
x
X
x
x
X
ISSUE MANAGEMENT
Store in Repository
(capture issue and
documentation)
X
Miglioramento Qualità
MANTENIMENTO
X
X
(Fix Issues and Track Progress)
(DATA MONITORING)
X
X
x
Metodologie e Strumenti di Data Profiling
X
X
X
63 | P a g i n a
Metodologia di Dettaglio
METODOLOGIA /
TIPO ANALISI
(include key analysis)
Structure Analysis
(vincoli intra/inter rel.)
Data Rule Analysis
Jack Olson
X
X
X
Business Data Quality
Ltd
X
X
TDWI
X
X
IBM
X
X
DataFlux (SAS
Company)
X
X
Informatica
X
X
Column Analysis
Metodologie e Strumenti di Data Profiling
X
64 | P a g i n a
7 Tools per il Data Profiling
Dopo una attenta ricerca degli strumenti di data profiling, sono stati trovati sei tool per l’automazione di
questa importante attività di DQ. Questa sezione non descrive in dettaglio gli strumenti, per non andare
oltre gli obiettivi e il carico di lavoro richiesti per questa tesina, ma comunque presentiamo un confronto
dei tool basato sulle caratteristiche principali.
La tesina può essere ulteriormente sviluppata in questa direzione, ovvero sull’analisi approfondita di tali
strumenti. Per ulteriori informazioni rimandiamo alla documentazione trovata e ai siti web dei produttori.
Classifichiamo i tool sulla base della licenza di utilizzo.
Open source software
•
Talend Open Profiler.
Freeware software
•
Oracle Data Profiling and
Oracle Data Quality for
Data Integrator (ODI).
Retail software
•
•
•
IBM WebSphere
Information Analyzer.
Informatica Data Explore.
SAS DataFlux df Power
Profile.
Presentiamo nella tabella seguente, Features Comparison Matrix, i tool analizzati attraverso un confronto
tra le caratteristiche principali (caratteristiche tecniche, tipi di analisi e funzionalità aggiuntive). Ricordiamo
che alcune celle possono essere vuote a causa della mancanza di informazione su quella particolare
caratteristica in quanto per alcuni tool i data sheet erano molto sommari e non c’era la possibilità di
scaricare il software o documentazione più completa.
Metodologie e Strumenti di Data Profiling
65 | P a g i n a
FEATURES / TOOLS
Versione
Talend Open
Profiler
Versione 3.1.3
Sistemi Operativi
Windows, Unix, Linux
Architettura
Oracle Data
Profiling Oracle
Data Integrator
(ODI)
IBM WebSphere
Information
Analyzer
Versione 10g release
3 (10.1.3)
Versione 8.1
Windows, Linux,
Solaris, HPUX Itanium,
AIX
Eclipse based
Client –Server
Architecture
Patterns Shared on
Talend Exchange
Integrato con prodotti
Oracle Data Quality
Informatica Data
Explore
SAS DataFlux df
Power Profile
Integrato con
Informatica Platform
Integrato con DF
Prower Studio
S.O.Windows, Linux,
Solaris, HPUX Itanium,
AIX
Drill-Down Approcch
User Annotation system
Metadata repository
Data Quality Thresholds
DQ issues email notification
Scheduling analysis activities
Visual Display of Results
Creazione report
Integrazione con strumenti di Data
Quality
Metodologie e Strumenti di Data Profiling
Integrato in IBM
Information Server
66 | P a g i n a
FEATURES / TOOLS
Talend Open
Profiler
Oracle Data
Profiling Oracle
Data Integrator
(ODI)
IBM WebSphere
Information
Analyzer
Gestione pattern (individuazione,
user-defined patterns)
Conteggi: unique, distinct, nul e
blank values
Indicatori statistici: media,
distribuzioni e frequenze valori
Column
Analysis Frequenze valori con metrica
Soundex
Proprietà: lenght, data type, range
check, precision check, min e max
values
Primary Key Analysis: validazione e
individuazione chiavi candidate
Intra-table analysis: dipendenze
funzionali tra I campi di una tabella
Cross
Column Inter-table analysis: relazioni
Analysis primary/foreign key, cross-domain
analysis (sovrapposizioni valori e
duplicati)
Metodologie e Strumenti di Data Profiling
67 | P a g i n a
Informatica Data
Explore
SAS DataFlux df
Power Profile
FEATURES / TOOLS
Talend Open
Profiler
Oracle Data
Profiling Oracle
Data Integrator
(ODI)
IBM WebSphere
Information
Analyzer
Correlation Analysis: correlazioni
numeriche e di tempo tra campi
Database e Table structure Analysis:
metadata a livello di db e tabelle
DQ Rule Analysis: definizione e
verifica business rule (user defined
rules)
Metodologie e Strumenti di Data Profiling
68 | P a g i n a
Informatica Data
Explore
SAS DataFlux df
Power Profile
Nella tabella seguente, confrontiamo i tool sulla base delle dimensioni di qualità che i tipi di analisi
permettono di valutare. In particolare il confronto è effettuato secondo questi criteri:
•
•
•
•
•
Completeness – null values analysis
Consistency – business rules analysis, conformità a data types, conformità a data pattern
Business rule compliance – cross-column, cross-table, and cross-database analysis
Relational Integrity – primary key and foreign-key integrity analysis
Accuracy – distribuzioni di frequenza, univocità, duplicati
DIMENSIONI
QUALITÀ / TOOLS
Talend Open
Profiler
Oracle Data
Profiling Oracle
Data Integrator
(ODI)
IBM WebSphere
Information
Analyzer
Informatica
Data Explore
SAS DataFlux df
Power Profile
Completeness
Consistency
Business Rule
Compliance
Relational
Integrity
Accuracy
Metodologie e Strumenti di Data Profiling
69 | P a g i n a
8 Riferimenti per i Tools: Links, Documentazione e Papers
•
•
•
•
•
Talend Open Profiler
o Indirizzo web: www.talend.com/products-data-quality/talend-open-profiler.php
o Talend Open Profiler User Guide: www.talend.com/resources/documentation.php
Oracle Data Profiling and Oracle Data Quality for Data Integrator (ODI)
o Indirizzo web: www.oracle.com/technology/products/oracle-dataintegrator/10.1.3/htdocs/1013_support.html
IBM WebSphere Information Analyzer
o Paper: Profiling: Take the first step toward assuring data quality, IBM Information
Management software, December 2006
o Indirizzo web: www.ibm.com/software/data/infosphere
Informatica Data Explore
o Indirizzo web: www.informatica.com/products_services/data_explorer/Pages/index.aspx
SAS DataFlux df Power Profile
o Indirizzo web: www.dataflux.com/Products/Platform/dfPower-Studio/dfPower-Profile.aspx
Metodologie e Strumenti di Data Profiling
70 | P a g i n a
9 Bibliografia
Business Data Quality Ltd. (2007). Data Profiling Best Practices. White Paper.
Business Data Quality Ltd. (2007). Data Profiling: Underpinning Quality Data Management. White Paper.
DataFlux Corporation, Sas Company. Data Profiling: The Diagnosis for Better Enterprise Information.
DataFlux. (n.d.). DataFlux Methodology. Retrieved from Sito Web DataFlux Corporation: www.dataflux.com
Fryman, L. (2004). Data Profiling: An Essential Element to Understanding Data for Data Integration
Initiatives. TDWI.
Informatica. (n.d.). Informatica The Data Integration Company. Retrieved from www.informatica.com
Olson, J. E. (February 2002). Data Profiling - The Key to Success in Integration Projects. Eai Journal .
Olson, J. E. (2003). Data Quality, The Accuracy Dimension. Morgan Kaufmann.
Plotkin, D. (2008). The case for data profiling. IBM Information Management.
Russom, P. (2008). Best Practices in Data Profiling and Cross-System Data Discovery. TDWI (The Data
Warehousing Institute) Research.
Russom, P. (2007). Unifying the Practices of Data Profiling, Integration and Quality (dPIQ). Sponsored by
DataFlux, a Sas company: TDWI (The Data Warehousing Institute) Monograph.
Wayne, E. W. (2003). Data Profiling: Minimizing Risk in Data Management Projects. TDWI Monograph
Series.
Wayne, E. W. (2002). Data Quality and the Bottom Line. TDWI Report Series.
Metodologie e Strumenti di Data Profiling
71 | P a g i n a