Introduzione
SortCL, il linguaggio IRI per la definizione e la manipolazione dei dati strutturati, ha da tempo la capacità di trarre valori sostitutivi da file di set esterni contenenti due o più colonne di valori. Questa funzionalità viene utilizzata per le trasformazioni di ricerca nelle operazioni Voracity ETL basate su CoSort, per la pseudonimizzazione di FieldShield e per le funzioni di ripristino e per la selezione di dati di coppie casuali/valide nei lavori di sintesi dei dati di test RowGen.
Questi file di set sono ottimi per informazioni che non cambiano spesso. Ma poiché i file set devono essere ordinati in base al contenuto delle colonne, possono essere ingombranti da usare quando è necessario aggiungere righe, specialmente quando il file set è aperto/in uso.
Inoltre, il contenuto di un set file spesso ha origine in un database. In questi casi, è stato necessario aggiungere un passaggio aggiuntivo (come l'esecuzione della procedura guidata "Imposta file dalla colonna" di IRI Workbench o un'operazione SQL) al flusso di lavoro per estrarre i valori da una tabella in un file di set.
Per risolvere questi inconvenienti, è stata abilitata la ricerca diretta dei valori di sostituzione dalle tabelle del database esistenti. Le ricerche da una tabella di database utilizzano la stessa sintassi e struttura per le ricerche di tabelle già in atto per i file di set. Ciò mantiene la coerenza funzionale nei lavori SortCL e fornisce l'accesso a più valori (in più database e file di set) contemporaneamente.
Sintassi
La sintassi dell'attributo del campo SortCL per l'accesso ai dati in un file di set è stata tradizionalmente:
SET="<Set_Source>"[<[ Search List ]>] [DEFAULT="string"] [ORDER=<Order Option>] [SELECT=<Select Option>] [SEARCH=<Search Option>]
dove
Il tuo programma SortCL (o compatibile) cercherà quindi una corrispondenza tra il valore di questo campo e la colonna di ricerca nel database. Se esiste una corrispondenza, il valore della colonna di sostituzione in questa riga verrà utilizzato come valore finale per il nuovo campo, che dovrebbe avere un nome diverso rispetto al campo a cui si fa riferimento da una delle origini di input.
Le colonne della tabella utilizzate nella ricerca sono specificate in un singolo elemento del linguaggio aggiuntivo all'implementazione iniziale dell'attributo secondario SET: LOOKUP=”<lvalue>,<valore>”.
Il parametro lvalore è il nome della colonna nella tabella che contiene il valore da cercare. Corrisponde alla colonna di sinistra, o prima, in un set file. Il valore parte corrisponde alla colonna di destra in un file di set di due colonne ed è la colonna che contiene il valore da restituire come sostituzione.
Come con le tradizionali ricerche di file di set, se non c'è corrispondenza deve essere specificato un valore predefinito. Viene utilizzata la sintassi DEFAULT="string", dove "string" è il valore predefinito specificato manualmente. Non devono esserci virgole tra nessuno dei parametri di file impostati.
Mettendo tutto insieme, un possibile esempio della sintassi per una ricerca in una tabella potrebbe essere:
SET="nuovo_schema.info;DSN=Nuovo MySQL;" [ACCOUNT_NUMBER] LOOKUP=”ACCOUNTNUM,PHONENUM”
Questo dovrebbe essere un parametro all'interno di una definizione di campo SortCL. La tabella "info" dovrebbe avere colonne denominate ACCOUNTNUM e PHONENUM in questo caso.
In che modo queste nuove ricerche di set possono essere utilizzate nella produzione? Considera questi esempi di script di lavoro IRI:
Esempi
Esempio 1 :pseudonimizzare i dati utilizzando i valori di sostituzione da un database.
Questo lavoro FieldShield cerca i valori dalla colonna "id" nella tabella denominata "lookuptable" a cui si accede tramite il DSN "Mangled". Se il campo ID è lo stesso nell'input (un file di testo) e nella colonna ID della tabella del database di riferimento, tutti i campi nell'output (anche un file di testo) verranno sostituiti con valori di sostituzione falsi ma realistici anche dal stessa tabella di riferimento. Se non ci sono corrispondenze, verranno invece emessi i valori predefiniti specificati nello script.
/INFILE=sensitiveData.txt /PROCESS=DELIMITED /INCOLLECT=200 # limit to 200 records /FIELD=(ID, TYPE=ASCII, POSITION=1, SEPARATOR="|") /FIELD=(NAME, TYPE=ASCII, POSITION=2, SEPARATOR="|") /FIELD=(SSN, TYPE=ASCII, POSITION=3, SEPARATOR="|") /FIELD=(ADDRESS, TYPE=ASCII, POSITION=4, SEPARATOR="|") /REPORT /OUTFILE=pseudonymizedData.txt /PROCESS=RECORD /FIELD=(PSEUDO_ID, TYPE=ASCII, POSITION=1, SEPARATOR="|", SET="lookuptable;DSN=Mangled;" [ID] DEFAULT=”0123456789” LOOKUP="id,fakeid") /FIELD=(PSEUDO_NAME, TYPE=ASCII, POSITION=2, SEPARATOR="|", SET="lookuptable;DSN=Mangled;" [ID] DEFAULT=”John” LOOKUP="id,fakename") /FIELD=(PSEUDO_SSN, TYPE=ASCII, POSITION=3, SEPARATOR="|", SET="lookuptable;DSN=Mangled;" [ID] DEFAULT=”555-55-5555” LOOKUP="id,fakessn") /FIELD=(PSEUDO_ADDRESS, TYPE=ASCII, POSITION=4, SEPARATOR="|", SET="lookuptable;DSN=Mangled;" [ID] DEFAULT=”583 West Ridge Rd” LOOKUP="id,fakeaddress")
Esempio 2 :pseudonimizzare tre colonne da una tabella di database utilizzando valori sostitutivi da un database diverso e crittografare la colonna rimanente.
Questo script esegue una ricerca in base al campo ID preso dalla tabella del database denominata "inputTable", guardando la colonna "id" della tabella denominata "lookuptable" a cui si accede tramite il DSN "Mangled". I valori corrispondenti nelle colonne "fakeid", "fakename", "fakessn" e "fakeaddress" verranno presi se esiste una corrispondenza dal campo ID dati di input alla colonna "id" nella tabella. Se non c'è corrispondenza, verranno invece emessi i valori predefiniti.
L'output verrà inviato a una tabella di destinazione separata. L'output potrebbe anche essere inviato alla stessa tabella dell'input, che maschererebbe i dati in posizione.
/INFILE=”inputTable;DSN=Mangled;” /PROCESS=ODBC /FIELD=(ID, TYPE=ASCII, POSITION=1, SEPARATOR="|") /FIELD=(NAME, TYPE=ASCII, POSITION=2, SEPARATOR="|") /FIELD=(SSN, TYPE=ASCII, POSITION=3, SEPARATOR="|") /FIELD=(ADDRESS, TYPE=ASCII, POSITION=4, SEPARATOR="|") /REPORT /OUTFILE=”outputTable;DSN=Mangled;” /PROCESS=ODBC /FIELD=(PSEUDO_ID, TYPE=ASCII, POSITION=1, SEPARATOR="|", SET="lookuptable;DSN=Mangled;" [ID] DEFAULT=”0123456789” LOOKUP="id,fakeid") /FIELD=(PSEUDO_NAME, TYPE=ASCII, POSITION=2, SEPARATOR="|", SET="lookuptable;DSN=Mangled;" [ID] DEFAULT=”John” LOOKUP="id,fakename") /FIELD=(ENCRYPT_SSN=enc_fp_aes256_alphanum(SSN,”EPWD:p4PagGZq9k7JFaj6/J1/JQ==”, TYPE=ASCII, POSITION=3, SEPARATOR="|") /FIELD=(PSEUDO_ADDRESS, TYPE=ASCII, POSITION=4, SEPARATOR="|", SET="lookuptable;DSN=Mangled;" [ID] DEFAULT=”583 West Ridge Rd” LOOKUP="id,fakeaddress")
Esempio 3 :protezione delle informazioni di identificazione personale (PII) utilizzando sostituzioni realistiche da una serie diversificata di metodi di mascheramento.
Il file di input contiene PII in più colonne (campi). Se esiste una corrispondenza tra il campo del nome nel file CSV di input e la colonna "FIRST_NAME" nella tabella "NAMES", verrà emesso un cognome sostitutivo dalla colonna "LAST_NAME" nella stessa tabella. I cognomi differiscono nella tabella “NOMI” dai dati personali stessi.
/INFILES=personalData.csv /PROCESS=CSV /ALIAS=PERSONALDATA_CSV /FIELD=(FIRST_NAME, TYPE=ASCII, POSITION=1, SEPARATOR=",", FRAME="\"") /FIELD=(LAST_NAME, TYPE=ASCII, POSITION=2, SEPARATOR=",", FRAME="\"") /FIELD=(SSN, TYPE=ASCII, POSITION=3, SEPARATOR=",", FRAME="\"") /FIELD=(BIRTH_DATE, TYPE=AMERICAN_DATE, POSITION=4, SEPARATOR=",", FRAME="\"") /FIELD=(ADDRESS, TYPE=ASCII, POSITION=5, SEPARATOR=",", FRAME="\"") /REPORT /OUTFILE=maskedData.csv /PROCESS=RECORD /FIELD=(FIRST_NAME, TYPE=ASCII, POSITION=1, SEPARATOR=",") /FIELD=(LAST_NAME_DB_SET, TYPE=ASCII, POSITION=2, SEPARATOR=",", SET="NAMES;DSN=mangled;" [FIRST_NAME] LOOKUP="FNAME,LNAME") /FIELD=(SSNENC=enc_fp_aes256_alphanum(SSN), TYPE=ASCII, POSITION=3, SEPARATOR=",") /FIELD=(BIRTH_DATEPLUS=BIRTH_DATE + 30, TYPE=AMERICAN_DATE, POSITION=4, SEPARATOR=",") /FIELD=(ADDRESSSET, TYPE=ASCII, POSITION=5, SEPARATOR=",", SET="C:/IRI/cosort100/sets/addresses.set" SELECT=ANY)
Lo stesso script di lavoro, delinea un diagramma di mappatura, insieme alla tabella dei nomi originale è mostrato nel mio IDE IRI Workbench, basato su Eclipse, di seguito:
Esempio 4 :generazione di dati di test referenzialmente corretti con IRI RowGen
Si consideri una tabella di database, o in altri potenziali casi più tabelle, che contengono dati che corrispondono a una determinata data. Con IRI RowGen e la funzionalità di ricerca tabella, è possibile prendere una selezione di date (da un file impostato o generato casualmente) e aggiungere più campi nell'output che corrispondono a valori realistici in base alla data inserita.
In questo esempio, tutti i dati corrispondenti dalla data sono conservati nella tabella di ricerca mostrata di seguito (sebbene possano essere presi da un numero qualsiasi di tabelle). La tabella ha un anno di date e i relativi valori:
Dal file impostato nel campo di immissione DATA, vengono selezionate 3 date che rientrano nell'intervallo di date incluso nella tabella.
Il file del set include tre voci:2019-10-11, 2019-11-11 e 2019-12-11.
/INFILE=random_file_placeholder /PROCESS=RANDOM /INCOLLECT=3 /FIELD=(DATE, TYPE=ALPHA_DIGIT, POSITION=1, SEPARATOR=",", SET="C:/Users/Devon/Downloads/dates.set" SELECT=ALL) /REPORT /OUTFILE=testPriceData.xml /PROCESS=XML /FIELD=(DATE, TYPE=ALPHA_DIGIT, POSITION=1, SEPARATOR=",") /FIELD=(OPEN, TYPE=ALPHA_DIGIT, POSITION=2, SEPARATOR=",", SET="new_schema2.pricedata;DSN=New MySQL;" [DATE] DEFAULT="170" LOOKUP="Date,Open") /FIELD=(HIGH, TYPE=ALPHA_DIGIT, POSITION=3, SEPARATOR=",", SET="new_schema2.pricedata;DSN=New MySQL;" [DATE] DEFAULT="171" LOOKUP="Date,High") /FIELD=(LOW, TYPE=ALPHA_DIGIT, POSITION=4, SEPARATOR=",",SET="new_schema2.pricedata;DSN=New MySQL;" [DATE] DEFAULT="169" LOOKUP="Date,Low") /FIELD=(CLOSE, TYPE=ALPHA_DIGIT, POSITION=5, SEPARATOR=",",SET="new_schema2.pricedata;DSN=New MySQL;" [DATE] DEFAULT="170.5" LOOKUP="Date,Close") /FIELD=(ADJ_CLOSE, TYPE=ALPHA_DIGIT, POSITION=6, SEPARATOR=",",SET="new_schema2.pricedata;DSN=New MySQL;" [DATE] DEFAULT="170.5" LOOKUP="Date,Adj_Close") /FIELD=(VOLUME, TYPE=ALPHA_DIGIT, POSITION=7, SEPARATOR=",",SET="new_schema2.pricedata;DSN=New MySQL;" [DATE] DEFAULT="523210182" LOOKUP="Date,Volume")
L'output di questo esempio è un file XML standard contenente i valori di ricerca:
Esempio 5 :esecuzione di una trasformazione di ricerca in un ETL Voracity IRI e creazione di rapporti
In questo esempio, abbiamo un file CSV contenente numeri di conto e importi scaduti per diversi clienti. Verrà utilizzata una ricerca nella tabella in due campi nell'output per ottenere ulteriori informazioni sulla corrispondenza da una tabella dei fatti del cliente principale in MySQL, con quella tabella che funge da tabella del cliente principale.
La tabella principale non contiene informazioni sull'importo dovuto e contiene molti più clienti rispetto al file di input che mostra solo i conti dei clienti insoluti. Questo cerca il nome e il numero di telefono dalla tabella in base al numero di conto e restituisce un foglio di lavoro .XLSX in un pratico formato di rapporto con le informazioni di contatto del cliente.
Inserisci CSV
Snippet della tabella clienti principale da confrontare
/INFILE=C:/Users/Devon/Downloads/accountnumsandamountDue.csv /PROCESS=CSV /ALIAS=accountnumsandamountDue /FIELD=(ACCOUNT_NUMBER, TYPE=ASCII, POSITION=1, SEPARATOR=",", FRAME="\"") /FIELD=(AMOUNT_DUE, TYPE=ASCII, POSITION=2, SEPARATOR=",", FRAME="\"") /REPORT /OUTFILE="'Past Due',HEADER;report.xlsx" /PROCESS=XLSX /FIELD=(ACCOUNT_NUMBER, TYPE=ASCII, POSITION=1, SEPARATOR="\t") /FIELD=(LOOKUP_NAME,TYPE=ASCII,POSITION=2, SEPARATOR="\t",SET="new_schema2.info;DSN=New MySQL;" [ACCOUNT_NUMBER] LOOKUP="ACCOUNTNUM,NAME") /FIELD=(LOOKUP_PHONE,TYPE=ASCII,POSITION=3, SEPARATOR="\t",SET="new_schema2.info;DSN=New MySQL;" [ACCOUNT_NUMBER] LOOKUP="ACCOUNTNUM,PHONENUM") /FIELD=(AMOUNT_DUE, TYPE=ASCII, POSITION=4, SEPARATOR="\t")
Report output "Scaduto"
Supporto IRI Workbench
Le ricerche nelle tabelle del database possono essere impostate come regola dalla procedura guidata Nuova regola campo. Questo tipo di regola è indicato come "Ricerca tabella" in Regole di generazione, ma può essere utilizzato in più origini o destinazioni come regola di campo in altri lavori.
Quando si seleziona una ricerca tabella, di norma, un profilo di connessione deve essere già impostato o creato quando richiesto per accedere alle tabelle del database e ai nomi delle colonne tra cui scegliere.
Da lì, seleziona la tabella, la colonna di ricerca e la colonna del valore di sostituzione da utilizzare per la ricerca. Ora questa ricerca nella tabella può essere impostata come regola da applicare in base ai corrispondenti.
Gli insiemi possono essere modificati dal tipo di trasformazione del valore Set:Table Lookup all'interno della finestra di dialogo dell'editor dei campi.
Ciò non è necessario se è già stata impostata e applicata una regola del campo di ricerca nella tabella. Tuttavia, questa finestra di dialogo consente la modifica manuale dei componenti di ricerca della tabella come DSN, tabella, campo di ricerca, colonna di ricerca e colonna dei risultati. Qui può anche essere specificato un valore predefinito.
Riepilogo
Le ricerche impostate ora hanno una nuova possibile origine in SortCL che può espandersi notevolmente e facilitare l'ottenimento dei dati necessari per una ricerca. Ciò è utile nelle operazioni di mascheramento o generazione di dati per fornire valori di sostituzione realistici che preservano le relazioni.
In futuro, i set potrebbero essere ampliati per includere ancora più origini dati. Contatta il tuo rappresentante IRI per ulteriori informazioni.
- Si noti che attualmente gli utenti di RowGen sfruttano i file set per la selezione casuale di valori senza un parametro di ricerca. Questa funzionalità non è supportata nella prima implementazione delle ricerche nelle tabelle DB. Questo perché ogni database ha un metodo o una sintassi specifici per selezionare una riga casuale da una tabella; alcuni database potrebbero non supportare affatto la selezione casuale.
