Källa Qualifier Transformation i Informatica med EXEMPEL
⚡ Smart sammanfattning
Källkvalificeringstransformationen i Informatica representerar de rader som integrationstjänsten läser från en relationskälla eller platt fil, och den låter en utvecklare åsidosätta standardfrågan, filtrera, sortera och deduplicera dessa data.

Vad är Source Qualifier Transformation?
Källkvalificeringstransformationen är en aktiv, kopplad transformation som representerar de rader som integrationstjänsten läser när en session körs. När en relationskälla eller en platt fil läggs till i en kartaping, en källkvalificerare-transformation krävs, och designern lägger till en automatiskt. Med källkvalificeraren kan du definiera och åsidosätta hur data hämtas från källan.
Transformationen konverterar även källans ursprungliga datatyper till Informatica-transformationsdatatyper, så varje transformation som placeras efter den fungerar med en plattformsneutral uppsättning typer.
Eftersom källkvalificeraren skapar den fråga som faktiskt når databasen är det det första stället att leta på när en kartaping läser fler rader eller fler kolumner än vad som behövs. Exemplet nedan begränsar frågan till fyra kolumner.
Hur man ändrar källkvalificerare i Informatica
I följande exempel kommer vi att modifiera källkvalificeraren för vår karta.ping ”m_emp_emp_target”, så att istället för att returnera alla kolumner returnerar den endast valda kolumner.
Steg 1) Öppna kartanping ”m_emp_emp_target” i kartanping Designer. Kartanping öppnas med EMP-källan, SQ_EMP-källkvalificeraren och EMP_TARGET-målet på arbetsytan.
Steg 2) Double-klicka på källkvalifikatortransformationen "SQ_EMP". Det öppnar fönstret Redigera transformationer för det objektet. Sedan
- Klicka på fliken Egenskaper
- Klicka på SQL Frågeändringsalternativ, detta öppnar ett SQL-redigeringsfönster
Fliken Egenskaper listar SQL-frågaraden som visas nedan.
Steg 3) I SQL-redigeringsfönstret
- Skriv in följande fråga
SELECT EMPNO, ENAME, JOB, MGR FROM EMP
Anmärkningar – vi väljer kolumnerna EMPNO, ENAME, JOB och MGR från källan, så vi har bara behållit de i urvalsfrågan.
- Välj OK-knappen
SQL-redigeraren innehåller nu den anpassade frågan istället för den genererade.
Steg 4) I fönstret Redigera transformationer,
- Välj fliken Portar från menyn
- Under fliken Portar ser du alla portar. Behåll endast portarna EMPNO, ENAME, JOB, MGR och ta bort de andra portarna.
Fliken Portar listar alla portar som transformationen medförde före borttagningen.
Steg 5) När portarna har raderats, välj OK-knappen. Endast de fyra återstående portarna finns kvar i listan.
Klicka nu på fliken Egenskaper igen i fönstret Redigera transformationer, så ser du bara de data som du har valt.
När du klickar på "OK"-knappen öppnas SQL-redigerarfönstret.
- Det bekräftar att de data du har valt är korrekta och redo att laddas in i måltabellen.
- Klicka på OK-knappen för att gå vidare
Bekräftelsefönstret upprepar de fyra kolumnerna som nu ska läsas.
Spara kartanping (med kortkommandot Ctrl+S) och kör arbetsflödeEfter körningen kommer endast de valda kolumnerna att läsas in i målet.
På så sätt kan du i källkvalificeraren åsidosätta vilka kolumner som behöver hämtas från källan, och detta är det enda sättet att kontrollera vilka specifika kolumner som tas med in i kartan.ping.
Egenskaper för Source Qualifier
Du kan använda olika egenskaper hos källkvalificeraren för att avgöra vilken typ av källdata som behöver transformeras och skickas till måltabellen.
- Källfilter – Med hjälp av egenskapen Källfilter kan du minska antalet källposter. Om du till exempel bara vill hämta anställda på avdelningsnummer 10 kan du ange filtervillkoret deptno=10 i egenskapen Källfilter och köra data. Inkludera tabellnamnet och portnamnet i villkoret och utelämna nyckelordet WHERE – ett filter som innehåller WHERE misslyckas med sessionen.
- Antal sorterade portar – I källkvalifikatortransformationen kan du också sortera indataposterna efter portposition. Integrationstjänsten lägger till en ORDER BY-klausul i standardfrågan och räknar portar från toppen av transformationen, så att data redan är sorterade när de når transformationerna inuti kartan.ping.
Eftersom data kan sorteras på en enda port eller på flera portar måste du ange antalet portar som ska användas vid sorteringen. Om du anger värdet 1, kommer endast empno-data att sorteras. Om du anger värdet 2, kommer data att sorteras på både empno och ename.
- Välj Distinkt – du kan bara hämta distinkta poster från källan med den här egenskapen. När du väljer alternativet Välj distinkt lägger integrationstjänsten till en SELECT DISTINCT-sats, så att endast distinkta kombinationer av källdata hämtas av källkvalificeraren.
Fliken Egenskaper som visas nedan innehåller dessa alternativ tillsammans med resten av egenskapslistan.
Den fullständiga egenskapslistan som är tillgänglig för en relationell källkvalificerare sammanfattas i tabellen nedan.
| Fast egendom | Vad den gör |
|---|---|
| SQL-fråga | Ersätter standardfrågan som genereras av integrationstjänsten. En anpassad fråga åsidosätter en användardefinierad koppling och ett källfilter. |
| Användardefinierad koppling | Anger det villkor som används för att sammanfoga data från flera källor som representeras av samma källkvalificerare. |
| Källfilter | Anger filtervillkoret som integrationstjänsten tillämpar vid radfrågor. |
| Antal sorterade portar | Antal kolumner som används för att sortera rader som lästs från relationskällor, tillagda till frågan som ORDER BY. |
| Tracingnivå | Mängd detaljer som skrivits till sessionsloggen för denna transformation. |
| Välj Distinkt | Returnerar unika rader endast genom att lägga till SELECT DISTINCT i frågan. |
| Pre-SQL | Kommandon körs mot källdatabasen innan integrationstjänsten läser källkoden. |
| Post-SQL | Kommandon körs mot källdatabasen efter att integrationstjänsten skriver till målet. |
| Utgången är deterministisk | Deklarerar att källan returnerar samma data mellan körningar när indata är konsekvent. |
| Utgången är repeterbar | Deklarerar att källan returnerar rader i samma ordning mellan körningar, vilket gör att integrationstjänsten hoppar över mellanlagring för återställning. |
Regler och riktlinjer för en SQL-override för källkvalificerare
En SQL-override är kraftfull eftersom den ersätter allt som Designern genererade, och det är också därför den bryts tyst när reglerna nedan ignoreras.
- Anslut portarna först. Länka alla in- och utportar som du tänker använda innan frågan matas in, eftersom den genererade frågan byggs från de anslutna portarna.
- Håll SELECT-listan i portordning. SELECT-satsen måste lista portnamnen i den ordning de visas i transformationen. Om ordningen inte matchar kan sessionen misslyckas eller ge oväntade resultat.
- Kvalificera varje kolumn. Varje kolumnnamn måste ha ett prefix av tabellen, vyn eller synonymen som det tillhör, till exempel ORDERS.ORDER_ID.
- Generera innan du redigerar. Om du klickar på Generera SQL visas standardfrågan, som redan innehåller källfiltret och sorted-ports-klausulen, så åsidosättningen kan byggas från en fungerande sats.
- Validera påståendet. SQL-editorn har en Validera-knapp som kör frågan och rapporterar om syntaxen är korrekt innan sessionen ens startas.
- Citera reserverade ord. Alla databasreserverade ord som används i frågan måste omges av citationstecken.
- Se upp för prioriteten. En anpassad fråga åsidosätter källfiltret och antalet sorterade portar, och en SQL-fråga som anges i session egenskaper åsidosätter både filtervillkoret och frågan som definierats i kartanping.
För Microsoft SQL Server källor finns det en extra regel: antalet kolumner i SELECT-satsen måste matcha antalet portar i transformationen, annars misslyckas sessionen vid hämtning av rader.
Hur man sammanfogar två källor med en källkvalificerare
En enda källkvalificerare kan läsa mer än en tabell. När två relaterade tabeller från samma relationskälla är länkade till en källkvalificerare, sammanfogar integrationstjänsten dem i källfrågan snarare än i kartan.ping, vilket innebär att databasen gör jobbet och färre rader reser till sessionen.
Standardkopplingen är en inner equijoin som skrivs in i WHERE-klausulen som Source1.column_name = Source2.column_name. För att kopplingen ska genereras måste de kopplade kolumnerna ha en primärnyckel-främmande nyckel-relation och matchande datatyper. Om de importerade metadata inte har någon sådan relation kan du skapa en i Källanalysator genom att länka matchande kolumner för de två källdefinitionerna.
När relationen saknas eller kopplingen måste vara en yttre koppling, använd egenskapen User-Defined Join istället. Villkoret som anges där ersätter kopplingsinformationen i metadata, och integrationstjänsten lägger till den i den genererade frågan.
Två begränsningar är värda att komma ihåg. Båda tabellerna måste komma från samma relationskälla, och källor av olika typer – en platt fil och en tabell, eller två olika databaser – måste kopplas samman med Snickarförvandling istället.
Källkvalificerare vs. filter vs. joinertransformation
Tre objekt kan alla minska eller kombinera rader, och att välja fel objekt är en vanlig orsak till långsamma sessioner. Tabellen nedan visar dem sida vid sida.
| Aspect | Källkval | Filtertransformation | Snickarförvandling |
|---|---|---|---|
| Var arbetet går | I källdatabasen, inuti den genererade frågan | I integrationstjänsten, rad för rad | I integrationstjänsten, med hjälp av en cache |
| Huvudsyfte | Läs källrader, åsidosätt frågan, filtrera, sortera, deduplicera | Ta bort rader som misslyckas med ett villkor | Kombinera två pipelines till en raduppsättning |
| Källtyper | Relationella tabeller och platta filer från en källa | Alla pipeline-data | Heterogena källor, inklusive platta filer och olika databaser |
| Gå med i supporten | Inre equijoin eller en användardefinierad koppling inom en relationskälla | Ingen | Normala, master yttre, detaljerade yttre och fullständiga yttre kopplingar |
| Rader som korsar nätverket | Endast de rader som frågan returnerar | Varje källrad läses först | Varje källrad läses först |
Den praktiska regeln är enkel: filtrera och anslut så tidigt som källan tillåter, och sikta på en Filtrera eller en Joiner endast för arbete som källdatabasen inte kan utföra. Att putta in villkor i källkvalificeraren är en av de billigaste vinsterna som finns tillgängliga under prestandajustering.








