Database
 sql >> Baza danych >  >> RDS >> Database

Wyszukiwanie tabel w pracach IRI zgodnych z SortCL

Wprowadzenie

SortCL, język IRI służący do definiowania i manipulowania danymi strukturalnymi, od dawna ma możliwość rysowania wartości zastępczych z zewnętrznych plików zestawów zawierających dwie lub więcej kolumn wartości. Ta funkcja jest używana do przekształceń wyszukiwania w operacjach ETL Voracity obsługiwanych przez CoSort, funkcjach pseudonimizacji i przywracania FieldShield oraz losowego wyboru danych / prawidłowych par w zadaniach syntezy danych testowych RowGen.

Te zestawy plików świetnie nadają się do przechowywania informacji, które nie zmieniają się często. Ale ponieważ pliki zestawów muszą być sortowane według zawartości kolumn, mogą być kłopotliwe w użyciu, gdy trzeba dodać wiersze — zwłaszcza gdy plik zestawu jest otwarty / używany.

Ponadto zawartość zbioru często faktycznie pochodzi z bazy danych. W takich przypadkach należało dodać dodatkowy krok (np. uruchomienie kreatora IRI Workbench „Ustaw plik z kolumny” lub operację SQL) w celu wyodrębnienia wartości z tabeli do pliku zestawu.

Aby rozwiązać te wady, włączono bezpośrednie wyszukiwanie wartości zastępczych z istniejących tabel bazy danych. Wyszukiwania z tabeli bazy danych wykorzystują tę samą składnię i strukturę, co w przypadku wyszukiwań tabel, które są już stosowane dla plików zestawów. Utrzymuje to funkcjonalną spójność zadań SortCL i zapewnia dostęp do większej liczby wartości (w wielu bazach danych i plikach zestawów) jednocześnie.

Składnia

Składnia atrybutu pola SortCL do uzyskiwania dostępu do danych w zbiorze tradycyjnie była następująca:

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

gdzie parametr oznacza nazwę ścieżki pliku zestawu. Ten parametr może teraz być również nazwą tabeli ODBC i ciągiem połączenia, podobnie jak w instrukcjach infile lub outfile. Parametr Search List powinien odwoływać się do pojedynczego pola z jednego ze źródeł wejściowych w przypadku wyszukiwania tabel.

Twój program SortCL (lub kompatybilny) będzie wtedy szukał dopasowania między wartością tego pola a kolumną wyszukiwania w bazie danych. Jeśli istnieje dopasowanie, wartość kolumny zastępczej w tym wierszu zostanie użyta jako ostateczna wartość dla nowego pola, które powinno mieć inną nazwę niż pole, do którego odwołuje się jedno ze źródeł danych wejściowych.

Kolumny tabeli używane w wyszukiwaniu są określone w pojedynczym dodatkowym elemencie języka do początkowej implementacji atrybutu podrzędnego SET:WYSZUKAJ=”<lwartość>,<rwartość>”.

Parametr lwartość to nazwa kolumny w tabeli zawierającej wartość do wyszukania. Odpowiada to lewej lub pierwszej kolumnie w zbiorze. wartość r część odpowiada prawej kolumnie w dwukolumnowym pliku zestawu i jest to ta, która kolumna zawiera wartość, która ma zostać zwrócona jako zamiennik.

Podobnie jak w przypadku tradycyjnych wyszukiwań plików zestawów, należy określić wartość domyślną, jeśli nie ma dopasowania. Używana jest składnia DEFAULT=”string”, gdzie „string” jest ręcznie określoną wartością domyślną. Nie powinno być przecinków między żadnym z ustawionych parametrów pliku.

Podsumowując, możliwym przykładem składni dla wyszukiwania tabeli może być:

SET=”nowy_schema.info;DSN=Nowy MySQL;” [ACCOUNT_NUMBER] WYSZUKAJ=”ACCOUNTNUM,PHONENUM”

Powinien to być parametr w definicji pola SortCL. Tabela „informacje” powinna zawierać kolumny o nazwach ACCOUNTNUM i PHONENUM w tym przypadku.

W jaki sposób można wykorzystać te nowe wyszukiwania zestawów w środowisku produkcyjnym? Rozważ te przykłady skryptów pracy IRI:

Przykłady

Przykład 1 :Pseudonimizuj dane za pomocą wartości zastępczych z bazy danych.

To zadanie FieldShield wyszukuje wartości z kolumny „id” w tabeli o nazwie „lookuptable” dostępnej przez DSN „Mangled”. Jeśli pole ID jest takie samo na wejściu (plik tekstowy) jak w kolumnie ID tabeli bazy danych, do której się odwołuje, to wszystkie pola na wyjściu (także plik tekstowy) zostaną zastąpione fałszywymi, ale realistycznymi wartościami zastępczymi również z ta sama tabela odniesienia. Jeśli nie ma dopasowania, zamiast tego zostaną wyświetlone wartości domyślne określone w skrypcie.

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

Przykład 2 :Pseudonimizuj trzy kolumny z tabeli bazy danych, używając wartości zastępczych z innej bazy danych i zaszyfruj pozostałą kolumnę.

Ten skrypt wykonuje wyszukiwanie na podstawie pola identyfikatora pobranego z tabeli bazy danych o nazwie „inputTable”, patrząc na kolumnę „id” z tabeli o nazwie „lookuptable” dostępnej za pośrednictwem DSN „Mangled”. Pasujące wartości w kolumnach „fakeid”, „fakename”, „fakessn” i „fakeaddress” zostaną pobrane, jeśli istnieje zgodność między polem ID danych wejściowych a kolumną „id” w tabeli. Jeśli nie ma dopasowania, zamiast tego zostaną wyświetlone wartości domyślne.

Dane wyjściowe zostaną wysłane do oddzielnej tabeli docelowej. Dane wyjściowe mogą być również wysyłane do tej samej tabeli co dane wejściowe, co zamaskuje dane w miejscu.

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

Przykład 3 :Ochrona informacji umożliwiających identyfikację osoby (PII) przy użyciu realistycznych zamienników ze zróżnicowanego zestawu metod maskowania.

Plik wejściowy zawiera PII w kilku kolumnach (polach). Jeśli istnieje zgodność między polem imienia w wejściowym pliku CSV a kolumną „IMIĘ_NAZWISKO” w tabeli „NAZWISKO”, w kolumnie „NAZWISKO” w tej samej tabeli zostanie wyświetlone zastępcze nazwisko. Nazwiska różnią się w tabeli „NAZWY” od samych danych osobowych.

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

Ten sam skrypt zadania, zarys diagramu mapowania, wraz z oryginalną tabelą nazw jest pokazany w moim IRI Workbench IDE, zbudowanym na Eclipse, poniżej:

Przykład 4 :Generowanie poprawnych referencyjnie danych testowych za pomocą IRI RowGen

Rozważ tabelę bazy danych lub w innych potencjalnych przypadkach wiele tabel, które zawierają dane odpowiadające określonej dacie. Dzięki funkcji IRI RowGen i funkcji wyszukiwania w tabeli możliwe jest wybranie wybranych dat (z zestawu plików lub wygenerowanych losowo) i dodanie większej liczby pól w danych wyjściowych, które odpowiadają realistycznym wartościom w oparciu o podane dane wejściowe.

W tym przykładzie wszystkie odpowiednie dane z daty są przechowywane w tabeli przeglądowej pokazanej poniżej (chociaż mogą być pobrane z dowolnej liczby tabel). Tabela zawiera daty roczne i odpowiadające im wartości:

Z pliku zestawu w polu wejściowym DATA wybierane są 3 daty, które mieszczą się w zakresie dat zawartym w tabeli.

Plik zestawu zawiera trzy wpisy:2019-10-11, 2019-11-11 i 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")

Wynikiem tego przykładu jest standardowy plik XML zawierający wartości wyszukiwania:

Przykład 5 :Wykonywanie transformacji wyszukiwania w IRI Voracity ETL i zadania raportowania

W tym przykładzie mamy plik CSV zawierający numery kont i przeterminowane kwoty dla kilku klientów. Wyszukiwanie tabeli zostanie użyte w dwóch polach danych wyjściowych, aby uzyskać dodatkowe pasujące informacje z głównej tabeli faktów klientów w MySQL, przy czym ta tabela będzie służyć jako główna tabela klientów.

Tabela główna nie zawiera informacji o należnej kwocie i zawiera znacznie więcej klientów niż plik wejściowy, który pokazuje tylko zaległe konta klientów. Spowoduje to wyszukanie nazwy i numeru telefonu z tabeli na podstawie numeru konta i wyprowadzenie do arkusza kalkulacyjnego .XLSX w poręcznym formacie raportu z informacjami kontaktowymi klienta.

Wpisz plik CSV

Fragment głównej tabeli klientów do sprawdzenia

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

Wyjście raportu „Zaległe”

Wsparcie IRI Workbench

Wyszukiwania tabel bazy danych można skonfigurować z reguły za pomocą Kreatora nowej reguły pola. Ten typ reguły jest określany jako „Wyszukiwanie tabeli” w Regułach generowania, ale może być używany w wielu źródłach lub celach jako reguła pola w innych zadaniach.

Podczas wybierania wyszukiwania tabeli jako reguły, profil połączenia musi być już skonfigurowany lub utworzony po wyświetleniu monitu, aby uzyskać dostęp do tabel bazy danych i nazw kolumn do wyboru.

Stamtąd wybierz tabelę, kolumnę odnośnika i kolumnę wartości zastępczej do użycia w odnośniku. Teraz to wyszukiwanie w tabeli może być ustawione jako reguła stosowana na podstawie dopasowań.

Zestawy można modyfikować za pomocą typu przekształcenia wartości Zestaw:Wyszukiwanie wartości w oknie dialogowym edytora pól.

Nie jest to potrzebne, jeśli skonfigurowano i zastosowano już regułę pola wyszukiwania tabeli. Jednak to okno dialogowe umożliwia ręczną edycję składników wyszukiwania tabeli, takich jak DSN, tabela, pole wyszukiwania, kolumna wyszukiwania i kolumna wyników. W tym miejscu można również określić wartość domyślną.

Podsumowanie

Zestaw wyszukiwania mają teraz nowe możliwe źródło w SortCL, które może znacznie rozszerzyć i ułatwić uzyskanie danych potrzebnych do wyszukiwania. Jest to przydatne w operacjach maskowania lub generowania danych, aby zapewnić realistyczne wartości zastępcze, które zachowują relacje.

W przyszłości zestawy mogą zostać rozszerzone o jeszcze więcej źródeł danych. Aby uzyskać więcej informacji, skontaktuj się z przedstawicielem IRI.

  1. Zauważ, że obecnie użytkownicy RowGen wykorzystują zestaw plików do losowego wyboru wartości bez parametru wyszukiwania. Ta funkcja nie jest obsługiwana w pierwszej implementacji wyszukiwania tabel DB. Dzieje się tak, ponieważ każda baza danych ma określoną metodę lub składnię wybierania losowego wiersza z tabeli; niektóre bazy danych mogą w ogóle nie obsługiwać losowego wyboru.

  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Sterownik ODBC Quickbooks

  2. Przywróć kopię swojej bazy danych

  3. Nie lubisz wyzwalaczy bazy danych? Po prostu nie wiesz, jak z nimi pracować!

  4. Co się właściwie dzieje z tym Seek?

  5. Raport dotyczący bazy danych Open Source 2019:najlepsze bazy danych, chmura publiczna a lokalna, trwałość Polyglot