Inleiding
SortCL, de IRI-taal voor het definiëren en manipuleren van gestructureerde gegevens, heeft al lang de mogelijkheid om vervangende waarden te halen uit externe setbestanden die twee of meer kolommen met waarden bevatten. Deze mogelijkheid wordt gebruikt voor opzoektransformaties in CoSort-aangedreven Voracity ETL-bewerkingen, FieldShield-pseudonimiserings- en herstelfuncties en willekeurige/geldige-paargegevensselectie in RowGen-testgegevenssynthesetaken.
Deze setbestanden zijn geweldig voor informatie die niet vaak verandert. Maar omdat setbestanden moeten worden gesorteerd op kolominhoud, kunnen ze omslachtig zijn om te gebruiken wanneer rijen moeten worden toegevoegd, vooral als het setbestand open of in gebruik is.
Daarnaast komt de inhoud van een setfile vaak ook daadwerkelijk uit een database. In die gevallen moest een extra stap (zoals het uitvoeren van de IRI Workbench 'Set File from Column'-wizard of een SQL-bewerking) worden toegevoegd aan de taakstroom om waarden uit een tabel naar een setbestand te extraheren.
Om deze nadelen aan te pakken, is het direct opzoeken van vervangende waarden uit bestaande databasetabellen mogelijk gemaakt. Opzoekacties uit een databasetabel gebruiken dezelfde syntaxis en structuur voor zoekacties in tabellen die al bestaan voor setbestanden. Dit handhaaft functionele consistentie in SortCL-taken en biedt toegang tot meer waarden (in meerdere databases en setbestanden) tegelijk.
Syntaxis
De syntaxis van het SortCL-veldattribuut voor toegang tot gegevens in een setbestand is van oudsher:
SET="<Set_Source>"[<[ Search List ]>] [DEFAULT="string"] [ORDER=<Order Option>] [SELECT=<Select Option>] [SEARCH=<Search Option>]
waar de
Uw SortCL (of compatibele) programma zal dan zoeken naar een overeenkomst tussen de waarde van dit veld en de opzoekkolom in de database. Als er een overeenkomst is, wordt de waarde van de vervangende kolom in deze rij gebruikt als de uiteindelijke waarde voor het nieuwe veld, dat een andere naam moet hebben dan het veld waarnaar wordt verwezen vanuit een van de invoerbronnen.
De tabelkolommen die bij het opzoeken worden gebruikt, worden gespecificeerd in één extra taalelement naast de initiële implementatie van het subkenmerk SET: LOOKUP=”<lvalue>,<rwaarde>”.
De parameter lwaarde is de naam van de kolom in de tabel die de op te zoeken waarde bevat. Dit komt overeen met de linkerkolom of de eerste kolom in een setbestand. De rwaarde deel komt overeen met de rechterkolom in een setbestand met twee kolommen, en is de kolom die de waarde bevat die als vervanging moet worden geretourneerd.
Net als bij traditionele zoekacties voor setbestanden, moet een standaardwaarde worden opgegeven als er geen overeenkomst is. De syntaxis DEFAULT=”string”, waarbij “string” de handmatig opgegeven standaardwaarde is, wordt gebruikt. Er mogen geen komma's tussen de ingestelde bestandsparameters staan.
Alles bij elkaar genomen, zou een mogelijk voorbeeld van de syntaxis voor het opzoeken van een tabel kunnen zijn:
SET=”new_schema.info;DSN=Nieuwe MySQL;” [ACCOUNT_NUMBER] LOOKUP=”ACCOUNTNUM,PHONENUM”
Dit moet een parameter zijn binnen een SortCL-velddefinitie. De "info"-tabel zou in dit geval kolommen ACCOUNTNUM en PHONENUM moeten hebben.
Hoe kunnen deze nieuwe set-lookups worden gebruikt in de productie? Bekijk deze voorbeelden van IRI-jobscripts:
Voorbeelden
Voorbeeld 1 :Pseudonimiseer gegevens met behulp van vervangende waarden uit een database.
Deze FieldShield-taak zoekt waarden op uit de kolom "id" in de tabel met de naam "lookuptable" die toegankelijk is via de DSN "Mangled". Als het ID-veld hetzelfde is in de invoer (een tekstbestand) als in de ID-kolom van de databasetabel waarnaar wordt verwezen, dan worden alle velden in de uitvoer (ook een tekstbestand) vervangen door valse maar realistische vervangingswaarden, ook van de dezelfde referentietabel. Als er geen overeenkomst is, worden in plaats daarvan de standaardwaarden die in het script zijn opgegeven, uitgevoerd.
/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")
Voorbeeld 2 :Pseudonimiseer drie kolommen uit een databasetabel met vervangende waarden uit een andere database en versleutel de resterende kolom.
Dit script doet een zoekopdracht op basis van het ID-veld uit de databasetabel met de naam "inputTable", kijkend naar de kolom "id" uit de tabel met de naam "lookuptable" die toegankelijk is via de DSN "Mangled". De overeenkomende waarden in de kolommen "fakeid", "fakename", "fakessn" en "fakeaddress" worden genomen als er een overeenkomst is tussen het invoergegevens-ID-veld en de kolom "id" in de tabel. Als er geen overeenkomst is, worden in plaats daarvan standaardwaarden uitgevoerd.
De uitvoer wordt naar een aparte doeltabel gestuurd. De uitvoer kan ook naar dezelfde tabel worden gestuurd als de invoer, waardoor de aanwezige gegevens zouden worden gemaskeerd.
/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")
Voorbeeld 3 :persoonlijk identificeerbare informatie (PII) beschermen met realistische vervangingen van een diverse reeks maskeringsmethoden.
Het invoerbestand bevat PII in verschillende kolommen (velden). Als er een overeenkomst is tussen het voornaamveld in het invoer-CSV-bestand en de kolom "FIRST_NAME" in de tabel "NAMES", dan wordt een vervangende achternaam uitgevoerd vanuit de kolom "LAATNAAM" in diezelfde tabel. De achternamen in de tabel "NAMEN" verschillen van de persoonlijke gegevens zelf.
/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)
Hetzelfde taakscript, een overzicht van een toewijzingsdiagram, samen met de originele naamtabel wordt hieronder weergegeven in mijn IRI Workbench IDE, gebouwd op Eclipse:
Voorbeeld 4 :referentieel correcte testgegevens genereren met IRI RowGen
Overweeg een databasetabel, of in andere mogelijke gevallen meerdere tabellen, die gegevens bevatten die overeenkomen met een bepaalde datum. Met IRI RowGen en de functionaliteit voor het opzoeken van tabellen is het mogelijk om een selectie van datums te nemen (uit een vast bestand of willekeurig gegenereerd) en meer velden in de uitvoer toe te voegen die overeenkomen met realistische waarden op basis van de opgegeven datuminvoer.
In dit voorbeeld worden alle corresponderende gegevens van de datum bewaard in de onderstaande opzoektabel (hoewel ze uit een willekeurig aantal tabellen kunnen worden gehaald). De tabel heeft een jaartal aan datums en de bijbehorende gerelateerde waarden:
Uit het ingestelde bestand in het DATE-invoerveld worden 3 datums geselecteerd die binnen het datumbereik vallen dat in de tabel is opgenomen.
Het setbestand bevat drie items:2019-10-11, 2019-11-11 en 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")
De uitvoer van dit voorbeeld is een standaard XML-bestand met de opzoekwaarden:
Voorbeeld 5 :Een opzoektransformatie uitvoeren in een IRI Voracity ETL en een taak rapporteren
In dit voorbeeld hebben we een CSV-bestand met rekeningnummers en achterstallige bedragen voor verschillende klanten. Een tabelzoekopdracht wordt gebruikt in twee velden in de uitvoer om aanvullende overeenkomende informatie te krijgen uit een hoofdklantgegevenstabel in MySQL, waarbij die tabel als hoofdklanttabel dient.
De hoofdtabel heeft geen informatie over het verschuldigde bedrag en bevat veel meer klanten dan het invoerbestand dat alleen achterstallige klantrekeningen toont. Dit zoekt de naam en het telefoonnummer op uit de tabel op basis van het accountnummer en voert dit uit naar een .XLSX-spreadsheet in een handig rapportformaat met contactgegevens van de klant.
CSV invoeren
Snippet van de hoofdklantentabel waartegen moet worden gezocht
/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")
Rapport "Vervallen" uitvoeren
IRI Workbench-ondersteuning
Het opzoeken van databasetabellen kan als regel worden ingesteld vanuit de wizard Nieuwe veldregel. Dit type regel wordt onder Generatieregels een 'Tabel opzoeken' genoemd, maar het kan in meerdere bronnen of doelen worden gebruikt als veldregel in andere taken.
Wanneer u als regel een tabelzoekopdracht selecteert, moet er al een verbindingsprofiel zijn ingesteld of worden gemaakt wanneer daarom wordt gevraagd om toegang te krijgen tot de databasetabellen en kolomnamen waaruit u kunt kiezen.
Van daaruit selecteert u de tabel, opzoekkolom en vervangingswaardekolom die u wilt gebruiken voor de zoekopdracht. Nu kan het opzoeken van deze tabel worden ingesteld als een regel die moet worden toegepast op basis van overeenkomsten.
Sets kunnen worden gewijzigd vanuit het transformatietype Set:Table Lookup value in het dialoogvenster van de veldeditor.
Dit is niet nodig als er al een regel voor het opzoeken van tabellen is ingesteld en toegepast. Dit dialoogvenster maakt echter handmatige bewerking van tabelopzoekcomponenten mogelijk, zoals DSN, tabel, zoekveld, opzoekkolom en resultaatkolom. Hier kan ook een standaardwaarde worden opgegeven.
Samenvatting
Set-lookups hebben nu een nieuwe mogelijke bron in SortCL die enorm kan uitbreiden en het verkrijgen van de gegevens die nodig zijn voor een lookup gemakkelijker kan maken. Dit is handig bij het maskeren of bij het genereren van gegevens om realistische vervangingswaarden te bieden die relaties behouden.
In de toekomst kunnen sets worden uitgebreid met nog meer gegevensbronnen. Neem contact op met uw IRI-vertegenwoordiger voor meer informatie.
- Merk op dat RowGen-gebruikers momenteel gebruikmaken van setbestanden voor de willekeurige selectie van waarden zonder een opzoekparameter. Deze functionaliteit wordt niet ondersteund bij de eerste implementatie van DB-tabelzoekacties. Dit komt omdat elke database een specifieke methode of syntaxis heeft voor het selecteren van een willekeurige rij uit een tabel; sommige databases ondersteunen misschien helemaal geen willekeurige selectie.