Post on 08-Jul-2015
5/10/2018 Migrazione dati - slidepdf.com
http://slidepdf.com/reader/full/migrazione-dati 1/5
rima iano INFORMATICA
Q u al i p rob lem atiche deve a ffronta re un ' azienda in fase d i ri n novo
sostanzia le del proprio S is tem a ln forrnativo , spec ie se e pre vis ta la
realizzaz ione d i un s is tem a di E nterprise D ata W arehouse?
Migrazione datie in tegrazioned i s istem i
lnqeqnere inlormatico, ha lavo rato in diverse a zie nde
private. a Rorna e M iLano . co m e p rogetlista d i ba 5 i
dal i e a pplics zioni, in part icolere ha pnzstato servizio,
c ome s pe c ia li st s d i inteqrazioni di sisterni, presso vari
I s t it u Ii d ie r e d i t o e S o de ti l d i In te rr n e di az io n e M ob i-
liare. A tl ualmen Ie seg ue, in qu a lita d i IT C onsu lts nt,
i l p ro c es so di - i nf o r r n a t iZZ<lZ Io n e e d a,vvi cina m en to e l
c i t t ad i n o " del la P ub b l i c a A m m in i s t r a z i o n e
Lo scopo dell'articolo e quello di proporre un fra-
mework per la realrazaaione di progetti fmalizzatia lla in teg raz io ne d i sistern i che abb ia ca ra tte ris ti-
che cii valid ita generale e facilita di applicazione
pratica.
Esso an alizza le p ro b le rn a tiche d i data deaning che una
generica azienda deve affrontare nei casi in cui vengano pia-
nificati interventi di rinnovo sostanziale del proprio Sistema
Informative, ovvero venga prevista la realizzazione d! un
sistema di Enterprise Data Warehouse. In particolare l'analisi
e finalizsata al l ' esame delle problematiche di migrazione dei
dati e realtzzazione dei sisremi d l integrazione,
II dccurnento e strutturato in piu sezioni, in modo da
suddividere l'esposizione tra fattori critici di successo, archi-
tettura d i riferimento di un generico progetto d i integrazionedt applicazioni indipendenri, approcci d i soluzione in due
domini del problema differenti e caratterisuche fondamen-
tali da considerate nell'approccio al problema del "data
cleaning".
Fatto ri c ritic i d i suc ces.so
Nel corso di un progetto di integrazione di applicazioni
indipendenti si possono individuare alcuni fattori critici di
successo caratteristici - osservabili nella realta dell'azienda
- che e utile sintetizzare di seguito, pet poi approfondirli
nel seguito:
• assicurazione della qualua dei dati (data cleaning): ilsistema
di integrazione deve gestire controlli sin di tipo sintatrico
che semarui co (es in una apphcaz tone d i gestione d e l
personale un dipendente non venga assegnato ad una
sede inesisrente; in una applicazione assicurativa la
coppia forma/ageute materials nelle denunce di infortu-
CP118 20
nio assuma valori ammissibili). Questo aspetto e materia
di analisi nel contesto dei prcgetti di Enterprise Data
Warehouse nei quali il sistema di alimentaztone viene
condiviso con altre apphcazioru (c on ta bth ra , c on rr ollo
di gestione). Sarebbe opportune prevedere almeno una
parte della strategia d i qualita del dati - in particolare
quella relativa alla sintassi a cui accennererno in seguito
- nel sistema di integrazione, allo scope d i evitare il pro-
liferare di aigoritmi di validazione e trasfcrmazione del
dati non rtu tilizzab ili. E che p uo esse re causa d i d is all i-
neamenti (l'univocita del risultato dei controlli e delle
elaborazioni sui dati non puo essere assicurata ncorrendo
ad algoritmi ad hoc scritti per ogru appl icaaione di desti-
nazione);
• minimizzazione della riaondanza netic [unzioni: nelle
aziende esistono, di fatto, alcunt domini funzionali cheporenzialmente nschiano di sovrapporsi, in particolare
gl i ambiti di analisi dell'Enterprise Data Warehouse, del
Controllo di Gestione e rnagari di applicativi strumentali
come quelli preposti allagestione del personale, Nel
Sistema Informativo di un'azienda, potrebbe verificarsi
la possibilita di effettuare le stesse anaiisi con sisterni
diversi, con il pericolo di incoerenze nei risultati. Ad
esempio, si supponga di voler aualizzare 10 scostaruento
tra fo rza lavo ro e fabbisogno per un ita o rg an lzaa tiva e
tipo di qualifica. Un simile report e sicuramente genera-
bile per mezzo degli strumenti di uri Data Warehouse rna
e altrettanto possibile effettuarlo nel contesto di un'ap-
plicazione di gestione, Poiche l'allinearnento dei dati rraI'applicazione dt produzione e d il Data Warehouse non
sara, ovviamente, istantaneo (in taluni cast la frequenza
di aggiornarnento potra essere mensile se non trimestrale
o sernestrale) le due anaiisi potrebbero non essere coe-
renti con conseguenze facilmente imrnaginabtli sulla
validita delle scelte da effettuare e sulla credibilita del
fornitore delle inforrnazioni;
• m in im iz za zio ne della ridondtlnza ne i dnti: p o tr eb b er o e sis re re
alcuni piani dei codici gestin da divers! appllcativi senaa
una strategia di allineamento a repl icazione (es, icodicidelle Unita Organizzarive di un'azienda, il piano dei conti
d i c or np e te nz a di un'appl icaztone) con conseguente reate
pericolo di disallineamento ed incongruenza delle in for-
mazicni utilizzate VUOt per compiti operativi vuoi per
r ep or tis ric a. St d ov re bb er o in div id ua re a lc un e a pp lic as io ru
(e conseguentemente le organizzazioni - uffici 0 servizi
- competenti) che assumano il ruolo di "proprietano" di
uno 0 piil domini informativi coruuni a piil appltcazioni e
5/10/2018 Migrazione dati - slidepdf.com
http://slidepdf.com/reader/full/migrazione-dati 2/5
a cui venga demandata Ia gestione delle tabelle del codici
la cui condivisione potra essere gestita con meccanismi
di DBMS Replication e, se il caso, con it suppOrtO di
tecnologie pill sofisticate come gil ETI tools (Extraction/
Transformation/Transport tools, a tal proposiro si veda it
paragrafo "Tecnologie d i integrazione").
A rc hiteUu ra d i rife .rim en·t.oLo scenario di riferimento per un progetto di Iruegraztone
di applicazioni mdipendenri (migranone da vecchie a nuove
apphcazioni e/o colloquia tra applicazioni distinte) e rappre-
sentabile per mezzo di un'architettura a strati come riportato
nella Figura 1.
Larchitetrura e formata dai seguenti strati interconnessi
(nel seguito si fadi riferimento a questa framework - privata
degli strati Data Sourcee Data Target - indicandolo come
sistema di integmzione):
• Sistema sorgente (Data Source Layer)
• Sistema di accesso ai dati (Data Access Layer)
• Sistema d i a cc es so aile informazioni (Information Access
Layer)
• Sistema di gesrione dei dati (Data Staging Layer)
• Sistema destinazione (Data Target Layer)
• Sistema di gestione dei rnetadari (Data Directory Layer)
• Sistema di gestione dei processi (Process Management
Layer)
Questi strati, ognuno per il compito che gli compete,
contribuiscono alia creazione ed elaborazione del flusso dei
dati il cui percorso puo essere sintetizzato nel diagramrna dei
process! d i Figura 2.
D ata S ou rce LayerRappresenta I' appJ i cazrone sorgen te delle infonuaztoni.
Con nferimento alia realta di un'azienda che vuole rin-
novate il proprio Sistema Informativo (SI) e realizzare un
Enterprise Data Warehouse, Ie applicazioni the costitui-
scone questo strata sono individuabili in base aile seguenti
linee guida:
• nel contesto del passaggio dall'attuale alla nueva
architettura del SIlo strata comprende le appllcazioni
dell'architettura attuale (es, gli interventi richiesti pet
eseguire in parallelo la nueva e la vecchia procedura di
Ccntabiiita) ;
• nel conresto dell 'alirn en tazione dell'Enterprise DataWarehouse e dell'applicazione per il Controllo di Gestione
1 0 strata comprende inizialmente le artuali appiicazioni e
suc ce ss iv am en te !e n uo ve .
Un fattore critico da considerare in questo contesto e l'eta
delle applicazioni gia in uso: l'obsolescenza di alcune di esse
implica che anche la tecnologia di accesso ai dati disponibile
puo essere datara, e pertanto diviene cruciale ['apporto del
Data Warehouse per liberate quei dati, per COS1 dire, imprigio-
nati negi: applicativi.
D ata A ccess Layer
Costituisce 1 0 strata che permette agli strati Information
Access e Data Staging di jXlrlare con iI Data Source. Tecni-
camente si risolve in un ltnguaggio univeTsa/e, indipendente
cioe dal RDBMS e dai protocolh di rete e non e altro che 1 0
standard de facto per il data interchange: Structured Query
Language (SQL).
_ F IGURA 1 Schema degli strati (layer] chs compongono un
T framework per tintegrazione di due sistemi [qui
indicati come Source e Target]
i r,
0 :0
J r;;
• ~i 2 '1~.
J
In fo rm a tio n .A cc es s L aye r
E 1 0 strata a diretto contatto con l'utente ed e costituito
dalle inrerfacce grafiche (GUI) delle applicazioni 0 dai tool
dl accesso ai dati che l'utente finale utilizza nel lavoro. Ad
esempio, realizzando un Enterprise Data Warehouse can
tecnologia Oracle, in questo strato troveremo applicazioni
come O ra cle D is co ve re r, O ra cle E xp re ss A na ly zer e Oracle
Reporrs.
Ma anche l'Iruemer browser per l'accesso ad applicazioni
Web based.
D ata S tag in g La yer
Comprende i prccessi e i dati necessari per estrarre,
a gg re ga re /c or nb in ar e e c ar ic ar e i dati ne l Data Target, concom pit; sia di replication management sia di analisi della
qualita dei dati ed applicazicne di particolari filtri sui dati
stessi.Si tratta dello strata piu entice dell'architettura perche
racchiude gran parte dell'inte!ligenza dell'integraaione ed e qui
che va posta Ill.massima attenzione gestendo il trasferimento
delle inforrnazioni.
Tipici problem: da considerare sono:
• gestione delle "antergate'': un movimento relative ad una
applicazione passa ad una certa data con competenza
anteriore (es, il passaggio di qualifica di un dipendente
che viene ccmurucato al sistema in data 01 can compe-
tenza in data D2 < 01). Lo strato deve tenere conto d i
entrarnbe le date nell'aggiomamento del Data Target, e
nel caso del Data \VarehOl.lse interviene una cornplica-zione ulreriore dovuta al fano che si ha necessita d! man-
tenere oltre che la storia dell'evento anche Ill.storia delle
variazioni sull'evento (si pensi aci una decisione presa in
base ad una anal is i effettuata in data D 1 a cui segue in
data D2 > D1 una variazione massiva con cornpetenza
03 <D1);
• gesrione dei controlli sintattici sui dati: conrrollo del for-
mato dei dati, controllo di integrita referenaiale su cerci
dati (es. un dipendente non sia assegnato ad una sede
inesistente) ;
• gestione dei controlli semantici sui dati: definizione delle
matrici di compatibilita dei valori di certi campi (es, la
coppia forma/agente materiale nelle denunce di inforru-
nio, la coppia sede/natura della lesione).
Nella successive sezione vengono descritte Ie tecnologie di
inregrazione che hanna un impatto diretto sulla configura-
zione di questo strata.
21 CP118
5/10/2018 Migrazione dati - slidepdf.com
http://slidepdf.com/reader/full/migrazione-dati 3/5
rima iano
_ F IGURA 2 Schema dei prccessi coinvotti net llusso dei dati dallo strato Source
T a quello Target di Fi.gura 1
Elim i n . l 1 . JQ ne
errur]
Tr.l-,fu",..,,;'mc
Cuicomcnl l> ... ... .. .. _~
fistcamente distinte I'obiettivo e in questo
case quello di assicurare la coerenza delle
mformazioni era le applicazioni in modo
che idati ridondann siano sempre allineati
("agree on the fact");
• modello della dipendenza (vedi Figura 4):
le apphcaziom hanno un rapporto dt dipen-
deuza tale che l'applicazione target B perterminare certi prccessi necessita del dati
generati dall'applicazione source A ("mul-
ristep process").
Tug,,!
Esaminiarno piu in dettaglio le peculiarita dei
due mcdell i .
II prime modello richiede che l e a p p li c az i on i
coinvolte posseggano Ie seguenu caratrerisri-
che:Data Target Layer
Rappresenta l'applicazione destinataria delle informazicni,
Le applicazioni che cosrituisccno tale strato sono individua-
bili proprio nelle nuove componenti del Sistema Informativo
unitamente all'Enterprise Data Warehouse ed all'eventuale
procedure di Controllo di Gestione ..
Data Directory Layer
Costituisce 1 0 strata di gestione dei rnetadati a livello di
sistema ed a livello utente e fornisce informazioni circa;
• 1 0 stato d i aggiornamenro del Data Target;
• il volume del dati rrattati in termini di record caricati/scartati, le lnformasioui sulla durata del caricamenti;
• le caratteristiche del dati trattati (la sezione cii un pro-
gramma COBOL in cui viene descrirto il forma to di un
record costituisce un tipico metadato).
Process Management Layer
Rappresenta 10 strata di controlio dell'esecuzione (sche-
duling) dei task predisposti per alirnentare il Data Target ed
il Data Directory e manrenerli aggiornati. Costituisce quindi
un controllore dei lavori previsti dal sistema di integrazione , sia
per quel che riguarda l'esecuzione automatica sia per quel che
riguarda la gestione degli errori e degli even ti imprevisti (gene-
razione dei log) ..
Tecnologie di integrazione
La consistenza e la qualita dei dati e un obiettivo importance
nell'integrazione sia delle applicazicni transasionali (OLTP)
sia de; sistemi di supporto aile decisioni (OSS).Sl pensi banalmente alia reportistica: quando un report
generato con un'applicazione puo essere considerate suffi-
cientemente consolidate ed essere quindi rilasciato, conside-
rando magari che alcuni dati non sono di proprieta esclusiva
dell'applicazione, ma vengono gestiti anche da altri pacchetti
su piattaforme distinte (problema questa dramrnaticamente
noto a diversi Uffici di un'azienda per quanta nguarda, per
esempio, alcune tabelle di codifica come quells delle Unita
Organizzarive dell 'azienda stessa)?
Nel contesto dt una strategia di integrazione di applica-
zioni diverse (legacy 0 di nuova acquisizione) alia scopo di
assicurare la consistenza e la qualita dei dati, e possibile indi-
viduare almeno due modelli nei quali ricomprendere i tipi di
applicazioni distinguendoli in base aile relazioni che tra esse
insistono:
• modello della ridondanza (vedi Figura 3): le applicaziom
condividono certe informazioni rna operano su basi dati
CP118 22
• siano di fatto disaccoppiate: se il s ls te m a d i i m eg ra zi on e non
e funzionante I'applicanone target continua comunque a
lavorare, quand'anche non sincronizzata,
• 1 0 strato di integrazicne lavora a livello dei dati: la sincro-
niezazione e realizzata per mezzo della rephcaztone a livello
dei DBMS;
• l'apphcazrone target e d ata c en tr ic : l'integrita dei dati eassicurata per 1 0 piu dai constraint definiti nel modello
fisico dei dati.
In tale modello ricadono gli scenari di integrazione dove
i1 sistema target e costituito dall'EDW, applicazione tipica-
mente data centric, ed una possibile solurione per 1 0 strato
di integrazione e l'utilizzo di un Extractton/Transformation/
Transport tool (acquisito sui rnercaro 0 sviluppato ad hoc: in
rnerito sono utilmente consultabili i document! della Gart-
nerGroup, ad esempio [5]) che, tra Ie altre case, deve con-sentire la definiaione di regole pet la verifica della correttezza
sintattica (un campo data contenga una data valida ed in
un forma to opportune) e sernantica (la data di assegnazione
della forza ad una Sede sia coerente con 1 'intervallo di vali-
dita della Sede stessa).
II secondo modelJo richiede che le applicazioni coinvolte
posseggano Ie seguenri caratteristiche:
• siano di fatto strettamente accoppiare, se 1 0 strata di inte-
grazione non e funzionante l'appltcazione target puo non
funzionare;
• 1 0 strato di integrazione lavora a livello dell'applicazione:
i prccessi di integrazione attivano degli update a livellodi programma piuttosto che inserire direrramente i dati
nel DB, questa al fine di demandare l'assicurazione del-
l'integrtta dei dati ai controlli di validazione definiti nelle
rransaaioru;
• I'applicazione target e process centric: l'integnta dei dari
e assicurata per 1 0 piu dai controlli di validazione definiti
nella logica delle transazioni.
In tale modello una possibile soluzione consiste nel definire
un Integration Broker la cui logica di funzionamento tipica-
mente prevede che una variazione su un campo effettuata
dall'applicazione source scateni un evento (trigger) che porta
a propagare tale rnodifica verso il target passando attraverso la
logica di valtdazione dellivello applicarivo.
Le due tecnoIogie d i integtseione sono quindi utili ed
efficaci in due distinti contesti, ed il loro utilizzo va quindi
vaiurato di conseguenza. Quesrione non di poco como,
potendo [a qualita e la consistenza delle informazioni gestite
5/10/2018 Migrazione dati - slidepdf.com
http://slidepdf.com/reader/full/migrazione-dati 4/5
dal sistema d i imegrazione sfuggire al controllo ed essere
comproruesse nel caso in cui la tecnologia adottata non sia
idonea at caso particolare.
Errori nei Dati
Questa sezione si propane d i classificare Ie tipologie di errorinet dan rtlevabih nel corso del processo (ncorrente) di estra-
zione dei dati dai sistemi sorgente (Data Source Layer), trs-stormazione e caricamento det sisterni di destinazione (Data
Target Layer).
Lo scopo e di avere un dettaglio sufflcienternente operativo
utilizzabile per affrontare e pianificare I 'attivita di d a ta c le an in g
nel contesto della "propagasione dei dati" da un sistema ad un
a lt ro , P o ss iam o c la s si fi ca re gli errori in base a lla l or o natura in
quattro categorie:
• errori di validita, errori propriamente detti;
• errori di corupletezza. idati sorgenre non sana compleri,
• errori di consistenza: la categoria pib ampia e piD spinosa in
quanto presenta spesso risvolti semantici:
• errori di cornprensibilita: i dati sorgente risultano "difficili"
da leggere.
Validita
Compaiono del codici che non rispettano una codifica
valida,
Tipicamente I'errore si present a quando le due applica-
zioni utilizzano due piani dei codici diversi per identificare
Ie occorrenze della stessa entita (es. u codice rappresenta-
tivo della qualifica del dipendente: l'archivio dell'Organico
dell'azienda e l'anagraflca Inquadramenti utilizzano codici
differen ti).
Piu sottile il caso in cui un codice e comunque valido nel-
I'applicazione di destinazione rna identifica un'occorrenza
diversa da quella originale.
La consistenza e q ualita dei
dat.ie un obie ttiv o impo rta nte
Nell'applicazione di destinazione vengono caricati dei
dati gia calcolati 0 aggregati, ma il caleolo 0 I'aggregazione
e stata effettuats in rnaniera errata. Esistononel/i sistema/i
sorgente/i dei record duplicati (es. una particolare sede eraattribuita a due dis tin te province).
Le informazioni residenti nel sistema sorgente sono sem-
plicemenre errate (es. era v alo rtzaa to il flag del sesso per un
dipenden te come" F" anziche "M "). Non c 'e altro cia fare che
correggere ilsistema sorgente,
Completezza
II processo dl est razione richiede un record da estrsrre dal
Data Source che non e presente. II processo di estrazlone
richiede un campo da estrarre dal Data Source che non epresente (es, per alcune marricole non em presente la data di
assunzione e quindi non era possibile attribuire l'anzianita, In
questi casi tipicamente si sceglie di attribuire un valore fisso a
programma) .
Consistenza
Dati che in sisto no sullo sres so dominio rn a che provengono
da sistemi diversi possono ovviarnente risultare inconsistenri.
T FIGURA 3 Modello della ridondanza
B
c
A
Ma anche dari che provengono da un unico sistema possono
presentare carattertstiche di inconsistenza dovute al tempo,
alia localizzazione geografica e all'orgaruzaanone che esegue
!'analisi degh stessi,
Nei differenti sistemi sorgente cornpaiono differenti codi-
fiche con 1 0 stesso significate (es. Ia ccdifica della sede di
Crotone dell'azienda era difference rra anagraflca fabbisogno
e anagrafica sedi).
Si riscontrano mancanze d i integrita referenztale dovute a
carenza d i controlli net sistema sorgente (es. a sedi chiuse era
assegnata della forza).
Nel sistema sorgente si fa un usc improprio d i un attribute
(per mancanza d i controlli sui campo).
Si tenra di confrontare due gruppi di informazioni che non
sono dispombili can la stessa granularita ternporale.Risulta sempte enrico - e quindi da controllare per
tempo - l'uso dei nults e degli spaces.
cern prensib ilita
II sistema desrmatario prevede inforrnazioni distinte che nel
sistema sorgente sono cornprese in un unico campo (es, Nome
e Cognome possono essere disrinti in due campi testuali 0
ricompresi in un unico campo testuale).
In applicazioni datate certi campi possono essere stati for-
mattati in modo singolare per morivi d t occupazione di spazio
su disco ovvero il layout di un record varia in manieranon
documen ta tao
Per quanta i codici presenri nei sistemi sorgente siano per1 2 1 stragrande maggioranza univocamente interpretabili, in
alcuni casi possono esistere dei record in cui i codici conten-
gono caratteri non documentati (es. "$").
Standard dei dati
Per una corretta implernentazione di qualsiasi strategia
di Data Moving e conveniente implementare un piano di
conversions delle informazioni provenienti dal Data Source
secondo uno standard accuratarnente definite cos t da peter
applicare in maniera generaluzata g ll algoritmi definiri per la
nlevazione degli errori (processo di D a t a C l ea n in g ).
Occorre considerare che una strategia basata su un accesso
diretto ai dati senza trasformazione (es, "as is" strategy) tara-
mente e vincente, in quanta presuppone che 10 standard nei
dati delle diverse applicazioni sia native e complete.
Nel seguiro si tented; d i classificare icast pill frequenri che
nchiedono la definizione di certi standard e conseguente-
mente Ia specifica di "regale di mappatura" non arnbigue.
23 CP118
5/10/2018 Migrazione dati - slidepdf.com
http://slidepdf.com/reader/full/migrazione-dati 5/5
rima iano
T FIGURA4 ModelLo della dipendenza
-[- ,_- -
A B :- C
I campi elementarl rappresentativi di informazioni prove-
nienti dai sisterni sorgente sono essenzialmenre i seguenri:
• campi usati come flag
• campi rappresenrarivi di codif iche
• campi nurnerici
• campi data
• campi testuali (usati in modo descrittivo)
C amp i fla g
Si tratta d i campi rappresentabili da uri solo bit (1 0 0) indi-
cante "Yes/No", "True!False", "On/Off".
II problema, per quanta bauale, nasce da! valore che tale
campo puo assurnere ne i d iversi sistem i legacy, Ill.Tabella 1
valga come esempio,
E evidente che la mappatura del campo flag del sistema
sorgente andra effettuata facendo corrispondere ad ogni
occorrenza - positiva/negativa - un valore standard (es,(~1)' 0 U O B ) .
Camp i c od ic i
I campi rappresentativi di codifiche presentano pill. di un
problema. Gran parte dei codict esistenti nei sistemi legacy
vengono utilizzati unicamente in una applicazione, per
centro alcuni sono uttlnzati in modo inconsistertte tra Ie
vade applicazicni (es. nei differenti sisterni sorgente com-paiono differenn codifiche con 1 0 stesso signif tcaro, per
esempio la codif ica della sede di Crorone era differente tra
fabbisogno e anagra fie a sedi).
Come ne l case dei f lag, i cod i c i rappresentativi di domini
sernanticarnente omogenei vanno mappati verso uno stan-
dard, ma in questa case ivalori di riferimento non sono solo
due rna potenaialmente pari al numero delle combinazioni
distinte permesse dai campi destinate a contenerli,
E opportune osservare che, quand'anche ci fosse cor-
rispondenza tra applicativi nell'uso di un cerro piano dei
codici, particolare attenzione va riposta nella giust i f icazione
e nel r i empimen to (zero/space filled - right/left justified)
principalmente allo scope di standardizzarei
confronn fraicampi.
In definitiva e necessario specific are ivalori amruissibili per
ogni s ingolo piano del codic i identificando ne i s is te r ni sorgente
tutte le occorrenze che hanna 1 0 sresso significate (mappatura
di ripo "many-to-one").
T A B E L L A 1 Esempio di campi flag
. . * . .
"0 "
Yes/True No/False
· ·N, n"
· · T , . r' " iF. r."l"
CP118 24
TABELLA 2 Esempio di campi data
Short L o n g
, oDMMAA ,o,oMMCCVY
AAMMDD CCVYMMDD
CC VY -MM -,o D la rc hiv i ,o B 2)
DOD
[ pr og r e s s i vo d el r a n n o I
VYDDD
Igiorno "qiuliano" con anna)
CCVYODD
I g :i o rno "g iu li ano " can secolol
Campi n ume ric i
Utilizzando tecniche di elaborazione basate su file
sequenziali possono nascere problemi nel trattare i numeri
negativi e/o decimali in quanta i sistemi legacy spesso
util izzano notazion ipa rticolari come (trasc urando q uelle
standard come ilpacked decimal 0 ilbinary): il segno meno
in corrispondenza della cifra piu significativa, Ie parentesi
ronde che racchiudono il numero: inoltre la virgola deci-
male (0 iI punta nella notazione anglosassone) pub essere
irnplicita od esplicita e la rappresentazione pub essere in
norazione scientifica.
Lo standard su cui mapparli e definito dai le organizzazioni
internazionali ISO e EDl , e per inurneri negativi prevede il
segno a s in is tr a della cifra pill signif tcat iva can l ' tnd tcazione
esplicita delseparatore decimale (che 1 0 standard riconosce
nella virgola).
Nel caso invece d i tecniche basate unicamente su SQL va
posta particolare attenzione alia lunghezza ed al ripo dei dati
("Strong Type Checking").
C am pi d ata
I forman d i rappresentazione sana ipit. vari, distin-
guendo tra formati Short (non pill accettabili per i uoti
problemi le ga ti a ll 'a nn o 2000, e comunque convertibili
per mezzo d i algoritmi come il windowing) e Long si veda
la Tabella 2.
Lo standard EU cui mapparli e definite dalle organizza-
zicni intemazionali ISO e EDI, ed e . ; CCYYMMDD.
Campi te stu a li
Nell'uso del text field con scopi descrittivi e opportune
standardizzare la Iunghezza (es, dati anagrafici come Nome,
Cognome e Indirizzo hanno lunghezze differenti in varisisterni) e definire delle regale per l'uso delle maiuscole.
Conclusio .n i
II framework proposto e abbastanza generale per poter
essere applicate a qualsiasi progetto di system integration,
ed allo stesso tempo e tale da assicurare - se seguito can
costanza - it rigore necessario per man tenere il controllo
degli aspetti pill critici caratteristici di questa tipologia di
attivita. iliI
RIFERIMENTI
[1] Haifei U, Stanley Y.w.su - " B u si ne ss Ob je ct M o d eb 'n g , V a li -d a rio n a n d M e d ia ti on f ar i nt eg ra ti ng h et er og en eo u s a p pl ic a ti onsystems",Journal of Systems Integration, 10,307-328,2001
[2] Adhikari R., "Migrating Legae:y data", Software Magazine,
VoLl6, No.1, 75-80,1996.