Einführung
SortCL, die IRI-Sprache für die Definition und Bearbeitung strukturierter Daten, hat seit langem die Fähigkeit, Ersatzwerte aus externen Set-Dateien zu ziehen, die zwei oder mehr Wertespalten enthalten. Diese Funktion wird für Lookup-Transformationen in CoSort-betriebenen Voracity-ETL-Operationen, FieldShield-Pseudonymisierungs- und -Wiederherstellungsfunktionen sowie für die Auswahl zufälliger/gültiger Datenpaare in RowGen-Testdatensynthesejobs verwendet.
Diese Satzdateien eignen sich hervorragend für Informationen, die sich nicht oft ändern. Da Set-Dateien jedoch nach Spalteninhalt sortiert werden müssen, können sie umständlich zu verwenden sein, wenn Zeilen hinzugefügt werden müssen – insbesondere, wenn die Set-Datei geöffnet / verwendet wird.
Außerdem stammen die Inhalte einer Satzdatei oft tatsächlich aus einer Datenbank. In diesen Fällen musste ein zusätzlicher Schritt (wie das Ausführen des IRI-Workbench-Assistenten „Set File from Column“ oder eine SQL-Operation) zum Auftragsablauf hinzugefügt werden, um Werte aus einer Tabelle in eine Set-Datei zu extrahieren.
Um diese Nachteile zu beheben, wurde die direkte Suche nach Ersatzwerten aus bestehenden Datenbanktabellen ermöglicht. Suchen aus einer Datenbanktabelle verwenden die gleiche Syntax und Struktur für Tabellensuchen, die bereits für Set-Dateien vorhanden sind. Dadurch wird die funktionale Konsistenz in SortCL-Jobs aufrechterhalten und der Zugriff auf mehr Werte (in mehreren Datenbanken und Set-Dateien) gleichzeitig ermöglicht.
Syntax
Die SortCL-Feldattributsyntax für den Zugriff auf Daten in einer Set-Datei war traditionell:
SET="<Set_Source>"[<[ Search List ]>] [DEFAULT="string"] [ORDER=<Order Option>] [SELECT=<Select Option>] [SEARCH=<Search Option>]
wo die
Ihr SortCL- (oder kompatibles) Programm sucht dann nach einer Übereinstimmung zwischen dem Wert dieses Felds und der Nachschlagespalte in der Datenbank. Wenn es eine Übereinstimmung gibt, wird der Wert der Ersetzungsspalte in dieser Zeile als endgültiger Wert für das neue Feld verwendet, das einen anderen Namen haben sollte als das Feld, auf das von einer der Eingabequellen verwiesen wird.
Die bei der Suche verwendeten Tabellenspalten werden in einem einzigen zusätzlichen Sprachelement zur anfänglichen Implementierung des SET-Unterattributs angegeben:LOOKUP=”<lvalue>,<rWert>“.
Der Parameter lvalue ist der Name der Spalte in der Tabelle, die den nachzuschlagenden Wert enthält. Dies entspricht der linken oder ersten Spalte in einer Set-Datei. Der rvalue part entspricht der rechten Spalte in einer zweispaltigen Satzdatei und ist diejenige Spalte, die den als Ersatz zurückzugebenden Wert enthält.
Wie bei herkömmlichen Set-File-Lookups sollte ein Standardwert angegeben werden, wenn es keine Übereinstimmung gibt. Es wird die Syntax DEFAULT=“string“ verwendet, wobei „string“ der manuell festgelegte Standardwert ist. Zwischen den eingestellten Dateiparametern dürfen keine Kommas stehen.
Zusammenfassend könnte ein mögliches Beispiel für die Syntax einer Tabellensuche folgendermaßen aussehen:
SET=“new_schema.info;DSN=Neues MySQL;“ [ACCOUNT_NUMBER] LOOKUP="ACCOUNTNUMBER,PHONENUM"
Dies sollte ein Parameter innerhalb einer SortCL-Felddefinition sein. Die Tabelle „info“ sollte in diesem Fall Spalten mit den Namen ACCOUNTNUM und PHONENUM haben.
Wie könnten diese neuen Set-Lookups in der Produktion verwendet werden? Betrachten Sie diese Beispiele für IRI-Jobskripte:
Beispiele
Beispiel 1 :Pseudonymisieren Sie Daten mit Ersatzwerten aus einer Datenbank.
Dieser FieldShield-Job sucht nach Werten aus der „id“-Spalte in der Tabelle mit dem Namen „lookuptable“, auf die über den DSN „Mangled“ zugegriffen wird. Wenn das ID-Feld in der Eingabe (einer Textdatei) dasselbe ist wie in der ID-Spalte der referenzierten Datenbanktabelle, dann werden alle Felder in der Ausgabe (ebenfalls eine Textdatei) durch gefälschte, aber realistische Ersatzwerte auch aus der ersetzt gleiche referenzierte Tabelle. Bei fehlender Übereinstimmung werden stattdessen die im Skript angegebenen Standardwerte ausgegeben.
/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")
Beispiel 2 :Pseudonymisieren Sie drei Spalten einer Datenbanktabelle mit Ersatzwerten aus einer anderen Datenbank und verschlüsseln Sie die verbleibende Spalte.
Dieses Skript führt eine Suche basierend auf dem ID-Feld aus der Datenbanktabelle mit dem Namen „inputTable“ durch und betrachtet die Spalte „id“ aus der Tabelle mit dem Namen „lookuptable“, auf die über den DSN „Mangled“ zugegriffen wird. Die übereinstimmenden Werte in den Spalten „fakeid“, „fakename“, „fakessn“ und „fakeaddress“ werden übernommen, wenn es eine Übereinstimmung zwischen dem Eingabedaten-ID-Feld und der „id“-Spalte in der Tabelle gibt. Wenn es keine Übereinstimmung gibt, werden stattdessen Standardwerte ausgegeben.
Die Ausgabe wird an eine separate Zieltabelle gesendet. Die Ausgabe könnte auch an dieselbe Tabelle wie die Eingabe gesendet werden, wodurch die vorhandenen Daten maskiert würden.
/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")
Beispiel 3 :Schutz personenbezogener Daten (PII) durch realistische Ersetzungen aus einer Vielzahl von Maskierungsmethoden.
Die Eingabedatei enthält PII in mehreren Spalten (Feldern). Wenn es eine Übereinstimmung zwischen dem Vornamensfeld in der Eingabe-CSV-Datei und der Spalte „FIRST_NAME“ in der Tabelle „NAMES“ gibt, wird ein Ersatz-Nachname aus der Spalte „LAST_NAME“ in derselben Tabelle ausgegeben. Die Nachnamen unterscheiden sich in der Tabelle „NAMES“ von den Personendaten selbst.
/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)
Dasselbe Job-Skript, skizziert ein Mapping-Diagramm, zusammen mit der ursprünglichen Namenstabelle, wird unten in meiner IRI Workbench IDE gezeigt, die auf Eclipse basiert:
Beispiel 4 :Generieren referenziell korrekter Testdaten mit IRI RowGen
Stellen Sie sich eine Datenbanktabelle oder in anderen potenziellen Fällen mehrere Tabellen vor, die Daten enthalten, die einem bestimmten Datum entsprechen. Mit IRI RowGen und der Tabellensuchfunktion ist es möglich, eine Auswahl von Daten (aus einer festgelegten Datei oder zufällig generiert) zu nehmen und weitere Felder in der Ausgabe hinzuzufügen, die realistischen Werten basierend auf der bereitgestellten Datumseingabe entsprechen.
In diesem Beispiel werden alle entsprechenden Daten aus dem Datum in der unten gezeigten Nachschlagetabelle gespeichert (obwohl sie aus einer beliebigen Anzahl von Tabellen entnommen werden könnten). Die Tabelle enthält Daten für ein Jahr und die entsprechenden zugehörigen Werte:
Aus der eingestellten Datei im DATUM-Eingabefeld werden 3 Daten ausgewählt, die innerhalb des in der Tabelle enthaltenen Datumsbereichs liegen.
Die Set-Datei enthält drei Einträge:2019-10-11, 2019-11-11 und 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")
Die Ausgabe dieses Beispiels ist eine Standard-XML-Datei mit den Suchwerten:
Beispiel 5 :Durchführen einer Lookup-Transformation in einem IRI Voracity ETL und Reporting-Job
In diesem Beispiel haben wir eine CSV-Datei mit Kontonummern und überfälligen Beträgen für mehrere Kunden. In zwei Feldern der Ausgabe wird eine Tabellensuche verwendet, um zusätzliche übereinstimmende Informationen aus einer Master-Kundenfaktentabelle in MySQL zu erhalten, wobei diese Tabelle als Master-Kundentabelle dient.
Die Haupttabelle enthält keine Informationen über den fälligen Betrag und enthält viel mehr Kunden als die Eingabedatei, die nur säumige Kundenkonten anzeigt. Dadurch wird der Name und die Telefonnummer aus der Tabelle basierend auf der Kontonummer gesucht und in einer .XLSX-Tabelle in einem praktischen Berichtsformat mit Kundenkontaktinformationen ausgegeben.
CSV eingeben
Snippet der Master-Kundentabelle, die nachgeschlagen werden soll
/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")
Bericht „Überfällig“ ausgeben
IRI Workbench-Support
Suchen in Datenbanktabellen können als Regel vom Assistenten für neue Feldregeln eingerichtet werden. Dieser Regeltyp wird unter Generierungsregeln als „Tabellensuche“ bezeichnet, kann aber in anderen Jobs in mehreren Quellen oder Zielen als Feldregel verwendet werden.
Bei der Auswahl einer Tabellensuche muss in der Regel ein Verbindungsprofil entweder bereits eingerichtet sein oder nach Aufforderung erstellt werden, um auf die zur Auswahl stehenden Datenbanktabellen und Spaltennamen zugreifen zu können.
Wählen Sie dort die Tabelle, Suchspalte und Ersatzwertspalte aus, die für die Suche verwendet werden sollen. Jetzt kann diese Tabellensuche als Regel festgelegt werden, die basierend auf Übereinstimmungen angewendet wird.
Sätze können über den Transformationstyp Satz:Tabellensuche im Feldeditordialog geändert werden.
Dies ist nicht erforderlich, wenn bereits eine Tabellensuchfeldregel eingerichtet und angewendet wurde. Dieses Dialogfeld ermöglicht jedoch die manuelle Bearbeitung von Tabellensuchkomponenten wie DSN, Tabelle, Suchfeld, Suchspalte und Ergebnisspalte. Hier kann auch ein Standardwert angegeben werden.
Zusammenfassung
Set-Lookups haben jetzt eine neue mögliche Quelle in SortCL, die das Abrufen der für eine Suche erforderlichen Daten erheblich erweitern und vereinfachen kann. Dies ist nützlich bei Maskierungs- oder Datengenerierungsvorgängen, um realistische Ersatzwerte bereitzustellen, die Beziehungen bewahren.
Zukünftig können Sets um noch mehr Datenquellen erweitert werden. Wenden Sie sich für weitere Informationen an Ihren IRI-Vertreter.
- Beachten Sie, dass RowGen-Benutzer derzeit Set-Dateien für die zufällige Auswahl von Werten ohne Suchparameter verwenden. Diese Funktionalität wird in der ersten Implementierung von DB-Tabellensuchen nicht unterstützt. Dies liegt daran, dass jede Datenbank eine bestimmte Methode oder Syntax zum Auswählen einer zufälligen Zeile aus einer Tabelle hat; Einige Datenbanken unterstützen die zufällige Auswahl möglicherweise überhaupt nicht.
