sql >> Database teknologi >  >> RDS >> Database

Tabelopslag i SortCL-kompatible IRI-job

Introduktion

SortCL, IRI-sproget for struktureret datadefinition og -manipulation, har længe haft evnen til at tegne erstatningsværdier fra eksterne sætfiler, der indeholder to eller flere kolonner med værdier. Denne funktion bruges til opslagstransformationer i CoSort-drevne Voracity ETL-operationer, FieldShield-pseudonymiserings- og gendannelsesfunktioner og tilfældigt/gyldigt par datavalg i RowGen-testdatasyntesejob.

Disse sætfiler er gode til information, der ikke ændres ofte. Men fordi sætfiler skal sorteres efter kolonneindhold, kan de være besværlige at bruge, når rækker skal tilføjes - især mens den indstillede fil er åben/i brug.

Derudover stammer indholdet af en sæt fil ofte faktisk i en database. I disse tilfælde skulle der tilføjes et ekstra trin (som at køre IRI Workbench 'Set File from Column'-guiden eller en SQL-handling) til jobflowet for at udtrække værdier fra en tabel til en set-fil.

For at løse disse ulemper er det direkte opslag af erstatningsværdier fra eksisterende databasetabeller blevet aktiveret. Opslag fra en databasetabel bruger den samme syntaks og struktur for tabelopslag, der allerede er på plads for indstillede filer. Dette bevarer funktionel konsistens i SortCL-job og giver adgang til flere værdier (i flere databaser og sætfiler) på én gang.

Syntaks

SortCL-feltattributsyntaks til at få adgang til data i en sætfil har traditionelt været:

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

hvor parameter angiver stinavnet til den indstillede fil. Denne parameter kan nu også være et ODBC-tabelnavn og en forbindelsesstreng, ligesom den der bruges i infile eller outfile-sætninger. Parameteren Søgeliste bør referere til et enkelt felt fra en af ​​inputkilderne i tilfælde af tabelopslag.

Dit SortCL (eller kompatible) program vil derefter lede efter et match mellem værdien af ​​dette felt og opslagskolonnen i databasen. Hvis der er et match, vil værdien af ​​erstatningskolonnen i denne række blive brugt som den endelige værdi for det nye felt, som skal have et andet navn end det felt, der henvises til fra en af ​​inputkilderne.

Tabelkolonnerne, der bruges i opslaget, er specificeret i et enkelt ekstra sprogelement til den indledende implementering af SET-underattributten:  LOOKUP=”<lvalue>,<rværdi>".

Parameteren lvalue er navnet på den kolonne i tabellen, der indeholder den værdi, der skal slås op. Dette svarer til venstre eller første kolonne i en sætfil. rværdien del svarer til højre kolonne i en fil med to kolonner, og er den kolonne, der indeholder den værdi, der skal returneres som erstatning.

Som med traditionelle sæt filopslag, skal en standardværdi angives, hvis der ikke er nogen match. DEFAULT ="streng"-syntaksen, hvor "streng" er den manuelt angivne standardværdi, bruges. Der bør ikke være kommaer mellem nogen af ​​de indstillede filparametre.

Hvis man sætter det hele sammen, kan et muligt eksempel på syntaksen for et tabelopslag være:

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

Dette bør være en parameter i en SortCL-feltdefinition. "info"-tabellen skal have kolonner med navnet ACCOUNTNUM og PHONENUM i dette tilfælde.

Hvordan kan disse nye sæt opslag bruges i produktionen? Overvej disse eksempler på IRI-jobscript:

Eksempler

Eksempel 1 :Pseudonymiser data ved hjælp af erstatningsværdier fra en database.

Dette FieldShield-job slår værdier op fra "id"-kolonnen i tabellen med navnet "lookuptable", der er tilgået via DSN "Mangled". Hvis ID-feltet er det samme i inputtet (en tekstfil) som i ID-kolonnen i den refererede databasetabel, så vil alle felter i outputtet (også en tekstfil) blive erstattet med falske, men realistiske erstatningsværdier også fra samme refererede tabel. Hvis der ikke er noget match, vil standardværdierne angivet i scriptet blive udlæst i stedet.

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

Eksempel 2 :Pseudonymiser tre kolonner fra en databasetabel ved hjælp af erstatningsværdier fra en anden database, og krypter den resterende kolonne.

Dette script laver et opslag baseret på ID-feltet taget fra databasetabellen med navnet "inputTable", og ser på "id"-kolonnen fra tabellen med navnet "lookuptable", der er tilgået via DSN "Mangled". De matchende værdier i kolonnerne "fakeid", "fakename", "fakessn" og "fakeaddress" vil blive taget, hvis der er et match fra inputdata-ID-feltet til "id"-kolonnen i tabellen. Hvis der ikke er noget match, vil standardværdier blive udlæst i stedet.

Outputtet vil blive sendt til en separat måltabel. Outputtet kunne også sendes til den samme tabel som inputtet, hvilket ville maskere dataene på plads.

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

Eksempel 3 :Beskyttelse af personligt identificerbare oplysninger (PII) ved hjælp af realistiske erstatninger fra en række forskellige maskeringsmetoder.

Inputfilen indeholder PII i flere kolonner (felter). Hvis der er et match mellem fornavnsfeltet i input-CSV-filen og "FIRST_NAME"-kolonnen i "NAMES"-tabellen, vil et erstatningsefternavn blive udlæst fra "LAST_NAME"-kolonnen i den samme tabel. Efternavnene adskiller sig i "NAVNE"-tabellen fra selve de personlige data.

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

Det samme jobscript, skitser et kortlægningsdiagram, sammen med den originale navnetabel er vist i min IRI Workbench IDE, bygget på Eclipse, nedenfor:

Eksempel 4 :Generering af referencerigtige testdata med IRI RowGen

Overvej en databasetabel, eller i andre potentielle tilfælde flere tabeller, der indeholder data, der svarer til en bestemt dato. Med IRI RowGen og tabelopslagsfunktionalitet er det muligt at tage et udvalg af datoer (fra en indstillet fil eller tilfældigt genereret) og tilføje flere felter i outputtet, der svarer til realistiske værdier baseret på det angivne datoinput.

I dette eksempel er alle de tilsvarende data fra datoen gemt i opslagstabellen vist nedenfor (selvom den kan tages fra et hvilket som helst antal tabeller). Tabellen har et års datoer og de tilsvarende relaterede værdier:

Fra den indstillede fil i DATO-indtastningsfeltet vælges 3 datoer, der er inden for det datointerval, der er inkluderet i tabellen.

Sætfilen indeholder tre poster:2019-10-11, 2019-11-11 og 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")

Outputtet fra dette eksempel er en standard XML-fil, der indeholder opslagsværdierne:

Eksempel 5 :Udførelse af en opslagstransformation i et IRI Voracity ETL og rapporteringsjob

I dette eksempel har vi en CSV-fil, der indeholder kontonumre og forfaldne beløb for flere kunder. Et tabelopslag vil blive brugt i to felter i outputtet for at få yderligere matchende information fra en masterkundefakta-tabel i MySQL, hvor denne tabel fungerer som masterkundetabel.

Stamtabellen har ikke oplysninger om det skyldige beløb og indeholder mange flere kunder end inputfilen, som kun viser forfaldne kundekonti. Dette slår navnet og telefonnummeret op fra tabellen baseret på kontonummeret og udlæses til et .XLSX-regneark i et praktisk rapportformat med kundekontaktoplysninger.

Input CSV

Uddrag af hovedkundetabellen, der skal slås op mod

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

Output "Forsinket"-rapport

IRI Workbench Support

Opslag i databasetabel kan som regel sættes op fra guiden Ny feltregel. Denne type regel omtales som et "Tabelopslag" under Genereringsregler, men den kan bruges i flere kilder eller mål som en feltregel i andre job.

Når du som regel vælger et tabelopslag, skal en forbindelsesprofil enten allerede være konfigureret eller oprettet, når du bliver bedt om det, for at få adgang til databasetabellerne og kolonnenavnene at vælge imellem.

Derfra skal du vælge tabellen, opslagskolonnen og erstatningsværdikolonnen, der skal bruges til opslag. Nu kan dette tabelopslag indstilles som en regel til at blive anvendt baseret på matchere.

Sæt kan ændres fra værditransformationstypen Set:Table Lookup i feltredigeringsdialogen.

Dette er ikke nødvendigt, hvis en tabelopslagsfeltregel allerede er konfigureret og anvendt. Denne dialog giver dog mulighed for manuel redigering af tabelopslagskomponenter såsom DSN, tabel, søgefelt, opslagskolonne og resultatkolonne. En standardværdi kan også angives her.

Oversigt

Set-opslag har nu en ny mulig kilde i SortCL, der i høj grad kan udvide og lette indhentning af de nødvendige data til et opslag. Dette er nyttigt i maskerings- eller datagenereringsoperationer for at give realistiske erstatningsværdier, der bevarer relationer.

I fremtiden kan sæt blive udvidet til at omfatte endnu flere datakilder. Kontakt din IRI-repræsentant for at få flere oplysninger.

  1. Bemærk, at RowGen-brugere i øjeblikket udnytter sætfiler til det tilfældige valg af værdier uden en opslagsparameter. Denne funktionalitet understøttes ikke i den første implementering af DB-tabelopslag. Dette skyldes, at hver database har en specifik metode eller syntaks til at vælge en tilfældig række fra en tabel; nogle databaser understøtter muligvis slet ikke tilfældigt udvalg.

  1. Installer PostgreSQL på Ubuntu 20.04

  2. SQL Sådan opdateres SUM for kolonne over gruppe i samme tabel

  3. Hvor værdi i kolonne, der indeholder kommaseparerede værdier

  4. Hvordan kan jeg klone en SQL Server-database på den samme server i SQL Server 2008 Express?