Въведение
SortCL, IRI езикът за дефиниране и манипулиране на структурирани данни, отдавна има способността да извлича заместващи стойности от външни наборни файлове, съдържащи две или повече колони със стойности. Тази способност се използва за преобразувания за търсене в захранвани с CoSort операции на Voracity ETL, функции за псевдонимизация и възстановяване на FieldShield и избор на произволни / валидни двойки данни в задачи за синтез на тестови данни на RowGen.
Тези наборни файлове са чудесни за информация, която не се променя често. Но тъй като файловете с набори трябва да бъдат сортирани по съдържание на колони, те могат да бъдат тромави за използване, когато трябва да се добавят редове — особено когато файлът с набор е отворен/използван.
В допълнение, съдържанието на набор файл често всъщност произхожда от база данни. В тези случаи към потока на заданието трябваше да се добави допълнителна стъпка (като стартиране на съветника „Задаване на файл от колона“ на IRI Workbench или SQL операция), за да се извлекат стойности от таблица в набор файл.
За да се преодолеят тези недостатъци, е разрешено директното търсене на заместващи стойности от съществуващи таблици на база данни. Проверките от таблица на база данни използват същия синтаксис и структура за търсения в таблицата, които вече са на място за набор файлове. Това поддържа функционална последователност в заданията на SortCL и осигурява достъп до повече стойности (в множество бази данни и файлове с набори) наведнъж.
Синтаксис
Синтаксисът на атрибута на поле SortCL за достъп до данни във файл с набор традиционно е:
SET="<Set_Source>"[<[ Search List ]>] [DEFAULT="string"] [ORDER=<Order Option>] [SELECT=<Select Option>] [SEARCH=<Search Option>]
където
След това вашата SortCL (или съвместима) програма ще търси съответствие между стойността на това поле и колоната за справка в базата данни. Ако има съвпадение, тогава стойността на заместващата колона в този ред ще се използва като крайна стойност за новото поле, което трябва да има различно име от полето, посочено от един от входните източници.
Колоните на таблицата, използвани при търсенето, са посочени в един допълнителен езиков елемент към първоначалното внедряване на податрибута SET: LOOKUP=”<lvalue>,<rvalue>”.
Параметърът lvalue е името на колоната в таблицата, която съдържа стойността, която трябва да се търси. Това съответства на лявата или първата колона в наборния файл. rvalue част съответства на дясната колона във файл с набор от две колони и е коя колона съдържа стойността, която трябва да бъде върната като замяна.
Както при традиционните търсения на файлове с набор, трябва да се посочи стойност по подразбиране, ако няма съвпадение. Използва се синтаксисът DEFAULT=”string”, където “string” е ръчно зададената стойност по подразбиране. Не трябва да има запетаи между нито един от зададените параметри на файла.
Обединявайки всичко това, възможен пример за синтаксис за търсене в таблица може да бъде:
SET=”new_schema.info;DSN=Нов MySQL;” [ACCOUNT_NUMBER] LOOKUP=”ACCOUNTNUM,PHONENUM”
Това трябва да бъде параметър в дефиницията на поле SortCL. Таблицата „информация“ трябва да има колони с имена ACCOUNTNUM и PHONENUM в този случай.
Как тези нови търсения на набори могат да се използват в производството? Помислете за тези примери за скриптове за работа на IRI:
Примери
Пример 1 :Псевдонимизирайте данни, като използвате заместващи стойности от база данни.
Това задание на FieldShield търси стойности от колоната „id“ в таблицата с име „lookuptable“, достъпна чрез DSN „Mangled“. Ако полето за идентификатор е същото във входа (текстов файл) като в колоната за идентификатор на реферираната таблица на базата данни, тогава всички полета в изхода (също текстов файл) ще бъдат заменени с фалшиви, но реалистични заместващи стойности също от същата посочена таблица. Ако няма съвпадение, вместо това ще бъдат изведени стойностите по подразбиране, посочени в скрипта.
/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")
Пример 2 :Псевдонимизирайте три колони от таблица на база данни, като използвате заместващи стойности от друга база данни, и криптирайте останалата колона.
Този скрипт прави търсене въз основа на полето за идентификация, взето от таблицата на базата данни, наречена „inputTable“, като разглежда колоната „id“ от таблицата с име „lookuptable“, достъпна чрез DSN „Mangled“. Съвпадащите стойности в колоните „fakeid“, „fakename“, „fakessn“ и „fakeaddress“ ще бъдат взети, ако има съвпадение от полето за идентификация на входните данни с колоната „id“ в таблицата. Ако няма съвпадение, вместо това ще бъдат изведени стойности по подразбиране.
Резултатът ще бъде изпратен в отделна целева таблица. Резултатът може също да бъде изпратен до същата таблица като входа, което ще маскира данните на място.
/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")
Пример 3 :Защита на личната информация (PII) с помощта на реалистични замествания от разнообразен набор от методи за маскиране.
Входният файл съдържа PII в няколко колони (полета). Ако има съвпадение между полето за първо име във входния CSV файл и колоната „FIRST_NAME“ в таблицата „NAMES“, тогава от колоната „LAST_NAME“ в същата таблица ще бъде изведено заместващо фамилно име. Фамилните имена се различават в таблицата „NAMES“ от самите лични данни.
/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)
Същият скрипт за работа, очертайте диаграма за картографиране, заедно с оригиналната таблица с имена, е показан в моя IRI Workbench IDE, изграден на Eclipse, по-долу:
Пример 4 :Генериране на референтно правилни тестови данни с IRI RowGen
Помислете за таблица на база данни или в други потенциални случаи множество таблици, които съдържат данни, които съответстват на определена дата. С IRI RowGen и функционалността за търсене на таблица е възможно да вземете селекция от дати (от зададен файл или произволно генерирани) и да добавите още полета в изхода, които съответстват на реалистични стойности въз основа на предоставената дата.
В този пример всички съответни данни от датата се съхраняват в таблицата за справка, показана по-долу (въпреки че могат да бъдат взети от произволен брой таблици). Таблицата съдържа дати за една година и съответните свързани стойности:
От зададения файл в полето за въвеждане ДАТА се избират 3 дати, които са в диапазона от дати, включени в таблицата.
Комплектният файл включва три записа:2019-10-11, 2019-11-11 и 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")
Резултатът от този пример е стандартен XML файл, съдържащ стойностите за търсене:
Пример 5 :Извършване на преобразуване на търсене в IRI Voracity ETL и работа за отчитане
В този пример имаме CSV файл, съдържащ номера на сметки и просрочени суми за няколко клиенти. Търсене на таблица ще се използва в две полета в изхода, за да се получи допълнителна информация за съвпадение от главна таблица с факти на клиента в MySQL, като тази таблица служи като основна таблица на клиентите.
Основната таблица няма информация за дължимата сума и съдържа много повече клиенти от входния файл, който показва само просрочени клиентски сметки. Това търси името и телефонния номер от таблицата въз основа на номера на сметката и извежда в електронна таблица .XLSX в удобен формат на отчет с информация за връзка с клиента.
Въведете CSV
Фрагмент от главната клиентска таблица, срещу която да се търси
/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")
Извеждане на отчет „Просрочено плащане“
Поддръжка на IRI Workbench
Проверките на таблици в базата данни могат да бъдат настроени като правило от съветника за ново поле за правила. Този тип правило се нарича „Търсене на таблица“ в Правилата за генериране, но може да се използва в множество източници или цели като правило на полето в други задачи.
Когато избирате търсене на таблица като правило, профилът за връзка трябва да бъде или вече настроен, или създаден, когато бъдете подканени, за да получите достъп до таблиците на базата данни и имената на колони, от които да избирате.
От там изберете таблицата, колоната за справка и колоната за заместваща стойност, които да използвате за справката. Сега това търсене в таблицата може да бъде зададено като правило, което да се прилага въз основа на съвпадения.
Наборите могат да се променят от типа трансформация на стойността Set:Table Lookup в диалоговия прозорец на редактора на полета.
Това не е необходимо, ако правилото за поле за справка в таблицата вече е настроено и приложено. Този диалогов прозорец обаче позволява ръчно редактиране на компоненти за справка в таблицата като DSN, таблица, поле за търсене, колона за справка и колона с резултати. Тук може да се посочи и стойност по подразбиране.
Резюме
Търсенето на набори вече има нов възможен източник в SortCL, който може значително да разшири и улесни получаването на данните, необходими за търсене. Това е полезно при операции за маскиране или генериране на данни, за да се осигурят реалистични заместващи стойности, които запазват връзките.
В бъдеще наборите могат да бъдат разширени, за да включват още повече източници на данни. Свържете се с вашия представител на IRI за повече информация.
- Обърнете внимание, че в момента потребителите на RowGen използват набор файлове за произволен избор на стойности без параметър за търсене. Тази функционалност не се поддържа при първата реализация на търсене на таблици в DB. Това е така, защото всяка база данни има специфичен метод или синтаксис за избор на случаен ред от таблица; някои бази данни може изобщо да не поддържат произволен избор.
