Migrazione dati

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



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



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



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



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.

Documents

Migrazione dati