sql >> Databasteknik >  >> RDS >> Database

Tabelluppslagningar i SortCL-kompatibla IRI-jobb

Introduktion

SortCL, IRI-språket för strukturerad datadefinition och -manipulation, har länge haft förmågan att dra ersättningsvärden från externa uppsättningsfiler som innehåller två eller flera kolumner med värden. Denna funktion används för uppslagstransformationer i CoSort-drivna Voracity ETL-operationer, FieldShield-pseudonymisering och återställningsfunktioner och slumpmässigt/giltigt pardataval i RowGen-testdatasyntesjobb.

Dessa uppsättningsfiler är bra för information som inte ändras ofta. Men eftersom uppsättningsfiler måste sorteras efter kolumninnehåll, kan de vara besvärliga att använda när rader behöver läggas till — särskilt när uppsättningsfilen är öppen/används.

Dessutom har innehållet i en uppsättningsfil ofta sitt ursprung i en databas. I dessa fall behövde ett extra steg (som att köra IRI Workbench 'Set File from Column'-guiden eller en SQL-operation) läggas till i jobbflödet för att extrahera värden från en tabell till en set-fil.

För att komma till rätta med dessa nackdelar har den direkta sökningen av ersättningsvärden från befintliga databastabeller aktiverats. Uppslagningar från en databastabell använder samma syntax och struktur för tabelluppslag som redan finns på plats för inställda filer. Detta upprätthåller funktionell konsekvens i SortCL-jobb och ger tillgång till fler värden (i flera databaser och uppsättningsfiler) samtidigt.

Syntax

Syntax för SortCL-fältattribut för att komma åt data i en uppsättningsfil har traditionellt varit:

SET="<Set_Source>"[<[ Search List ]>]
    [DEFAULT="string"]
    [ORDER=<Order Option>]
    [SELECT=<Select Option>]
    [SEARCH=<Search Option>]

där parametern anger sökvägsnamnet för setfilen. Den här parametern kan nu också vara ett ODBC-tabellnamn och anslutningssträng, precis som den som används i infile- eller outfile-satser. Parametern Search List bör referera till ett enstaka fält från en av ingångskällorna vid tabelluppslagningar.

Ditt SortCL (eller kompatibla) program kommer sedan att leta efter en matchning mellan värdet på detta fält och uppslagskolumnen i databasen. Om det finns en matchning kommer värdet på ersättningskolumnen på den här raden att användas som slutvärde för det nya fältet, som ska ha ett annat namn än fältet som refereras till från en av indatakällorna.

Tabellkolumnerna som används i sökningen specificeras i ett enda ytterligare språkelement till den initiala implementeringen av SET-underattributet:  LOOKUP=”<lvalue>,<rvärde>”.

Parametern lvalue är namnet på kolumnen i tabellen som innehåller värdet som ska slås upp. Detta motsvarar den vänstra, eller första, kolumnen i en uppsättningsfil. rvärdet del motsvarar den högra kolumnen i en fil med två kolumner, och är den kolumn som innehåller värdet som ska returneras som ersättning.

Som med traditionella uppsättningar filsökningar, bör ett standardvärde anges om det inte finns någon matchning. Syntaxen DEFAULT ="sträng", där "sträng" är det manuellt angivna standardvärdet, används. Det ska inte finnas några kommatecken mellan någon av de inställda filparametrarna.

Om man sätter ihop allt kan ett möjligt exempel på syntaxen för en tabelluppslagning vara:

SET=”new_schema.info;DSN=Ny MySQL;” [ACCOUNT_NUMBER] LOOKUP=”ACCOUNTNUM,PHONENUM”

Detta bör vara en parameter inom en SortCL-fältdefinition. Tabellen "info" bör ha kolumner med namnet ACCOUNTNUM och PHONENUM i detta fall.

Hur kan dessa nya uppslagssökningar användas i produktionen? Tänk på dessa IRI-jobbskriptexempel:

Exempel

Exempel 1 :Pseudonymisera data med hjälp av ersättningsvärden från en databas.

Detta FieldShield-jobb slår upp värden från kolumnen "id" i tabellen med namnet "lookuptable" som nås via DSN:et "Mangled". Om ID-fältet är detsamma i inmatningen (en textfil) som i ID-kolumnen i den refererade databastabellen, kommer alla fält i utdata (även en textfil) att ersättas med falska men realistiska ersättningsvärden också från samma refererade tabell. Om det inte finns någon matchning kommer standardvärdena som anges i skriptet att matas ut istället.

/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")

Exempel 2 :Pseudonymisera tre kolumner från en databastabell med hjälp av ersättningsvärden från en annan databas, och kryptera den återstående kolumnen.

Det här skriptet gör en uppslagning baserat på ID-fältet hämtat från databastabellen med namnet "inputTable", och tittar på kolumnen "id" från tabellen med namnet "lookuptable" som nås via DSN "Mangled". De matchande värdena i kolumnerna "fakeid", "fakename", "fakessn" och "fakeaddress" kommer att tas om det finns en matchning från indata-ID-fältet till "id"-kolumnen i tabellen. Om det inte finns någon matchning kommer standardvärden att matas ut istället.

Utdata kommer att skickas till en separat måltabell. Utdata kan också skickas till samma tabell som indata, vilket skulle maskera data på plats.

/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")

Exempel 3 :Skydda personligt identifierbar information (PII) med realistiska ersättningar från en mängd olika maskeringsmetoder.

Indatafilen innehåller PII i flera kolumner (fält). Om det finns en matchning mellan förnamnsfältet i indata-CSV-filen och kolumnen "FIRST_NAME" i tabellen "NAMES", kommer ett ersättningsefternamn att matas ut från kolumnen "LAST_NAME" i samma tabell. Efternamnen skiljer sig i tabellen "NAMN" från själva personuppgifterna.

/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)

Samma jobbskript, skissera ett mappningsdiagram, tillsammans med den ursprungliga namntabellen visas i min IRI Workbench IDE, byggd på Eclipse, nedan:

Exempel 4 :Genererar referensmässigt korrekta testdata med IRI RowGen

Överväg en databastabell, eller i andra potentiella fall flera tabeller, som innehåller data som motsvarar ett visst datum. Med IRI RowGen och tabelluppslagningsfunktioner är det möjligt att ta ett urval av datum (från en uppsättningsfil eller slumpmässigt genererad) och lägga till fler fält i utdata som motsvarar realistiska värden baserat på den angivna datuminmatningen.

I det här exemplet hålls all motsvarande data från datumet i uppslagstabellen som visas nedan (även om den kan hämtas från valfritt antal tabeller). Tabellen har ett års datum och motsvarande relaterade värden:

Från uppsättningsfilen i inmatningsfältet DATUM väljs 3 datum som ligger inom intervallet för datum som ingår i tabellen.

Uppsättningsfilen innehåller tre poster:2019-10-11, 2019-11-11 och 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")

Utdata från detta exempel är en standard XML-fil som innehåller uppslagsvärdena:

Exempel 5 :Utföra en uppslagstransform i ett IRI Voracity ETL och rapporteringsjobb

I det här exemplet har vi en CSV-fil som innehåller kontonummer och förfallna belopp för flera kunder. En tabelluppslagning kommer att användas i två fält i utdata för att få ytterligare matchande information från en huvudkundfaktatabell i MySQL, med den tabellen som huvudkundtabell.

Huvudtabellen har ingen information om det förfallna beloppet och innehåller många fler kunder än indatafilen som bara visar förfallna kundkonton. Detta slår upp namnet och telefonnumret från tabellen baserat på kontonumret och skickas till ett .XLSX-kalkylblad i ett praktiskt rapportformat med kundkontaktinformation.

Mata in CSV

Utdrag från huvudkundtabellen som ska slås upp mot

/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")

Utdata "Förfallen"-rapport

IRI Workbench Support

Uppslagningar i databastabeller kan ställas in som regel från guiden New Field Rule. Denna typ av regel hänvisas till som en "tabellsökning" under Genereringsregler, men den kan användas i flera källor eller mål som en fältregel i andra jobb.

När du väljer en tabelluppslagning som regel måste en anslutningsprofil antingen redan vara konfigurerad eller skapad när du uppmanas att få tillgång till databastabellerna och kolumnnamnen att välja mellan.

Därifrån väljer du tabellen, uppslagskolumnen och ersättningsvärdeskolumnen som du vill använda för uppslagningen. Nu kan denna tabelluppslagning ställas in som en regel för att tillämpas baserat på matchare.

Uppsättningar kan ändras från värdetransformationstypen Set:Table Lookup i dialogrutan för fältredigerare.

Detta behövs inte om en regel för tabelluppslagsfält redan har ställts in och tillämpats. Den här dialogrutan tillåter dock manuell redigering av tabelluppslagskomponenter som DSN, tabell, sökfält, uppslagskolumn och resultatkolumn. Ett standardvärde kan också anges här.

Sammanfattning

Set-uppslagningar har nu en ny möjlig källa i SortCL som avsevärt kan expandera och underlätta erhållandet av de data som behövs för en uppslagning. Detta är användbart vid maskering eller datagenerering för att tillhandahålla realistiska ersättningsvärden som bevarar relationer.

I framtiden kan uppsättningar utökas till att omfatta ännu fler datakällor. Kontakta din IRI-representant för mer information.

  1. Observera att för närvarande använder RowGen-användare uppsättningsfiler för slumpmässigt urval av värden utan en uppslagsparameter. Den här funktionen stöds inte i den första implementeringen av DB-tabelluppslagningar. Detta beror på att varje databas har en specifik metod eller syntax för att välja en slumpmässig rad från en tabell; vissa databaser kanske inte stöder slumpmässigt urval alls.

  1. Hur genererar man ett intervall av siffror mellan två siffror?

  2. 5 tecken på att du har vuxit ur Excel

  3. Kan jag använda ADFS 2.0 för att autentisera vissa användare mot SQL Server?

  4. Oracle PL/SQL:UTL_FILE.FCOPY Exempel