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.

  • 🧩 Automatiskt objekt: En källkvalificerare visas automatiskt när en relationstabell eller en platt fil läggs till i en karta.ping.
  • ✍️ SQL-överstyrning: En anpassad fråga ersätter den genererade SELECT-frågan och prioriteras framför källfiltret och den sorterade portinställningen.
  • 🔢 Portordning: SELECT-listan måste namnge portar i den ordning de visas i transformationen, annars kan sessionen misslyckas.
  • 🎯 Källfilter: Ett filtervillkor trimmar rader i databasen, och nyckelordet WHERE måste utelämnas.
  • 🔗 Enkelpass-koppling: Relaterade tabeller från en relationskälla kan kopplas inuti en källkvalificerare istället för en koppling.
  • ⚡ Less trafik: Arbete som skickas till källfrågan flyttar färre rader över nätverket till sessionen.

Källa Qualifier Transformation i Informatica

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.

Kartaping m_emp_emp_target öppnas i Informatica-kartanping designer

Steg 2) Double-klicka på källkvalifikatortransformationen "SQ_EMP". Det öppnar fönstret Redigera transformationer för det objektet. Sedan

  1. Klicka på fliken Egenskaper
  2. Klicka på SQL Frågeändringsalternativ, detta öppnar ett SQL-redigeringsfönster

Fliken Egenskaper listar SQL-frågaraden som visas nedan.

Fliken Egenskaper för SQ_EMP-källkvalificeraren med SQL-frågeraden markerad

Steg 3) I SQL-redigeringsfönstret

  1. 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.

  2. Välj OK-knappen

SQL-redigeraren innehåller nu den anpassade frågan istället för den genererade.

SQL Editor-fönstret som innehåller den anpassade SELECT-frågan för källkvalificeraren

Steg 4) I fönstret Redigera transformationer,

  1. Välj fliken Portar från menyn
  2. 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.

Fliken Portar i fönstret Redigera transformationer som listar alla portar för källkvalificerare

Steg 5) När portarna har raderats, välj OK-knappen. Endast de fyra återstående portarna finns kvar i listan.

Fliken Portar efter att oönskade källkvalificeringsportar har tagits bort

Klicka nu på fliken Egenskaper igen i fönstret Redigera transformationer, så ser du bara de data som du har valt.

Fliken Egenskaper som visar den sparade SQL-frågeöverskrivningen på källkvalificeraren

När du klickar på "OK"-knappen öppnas SQL-redigerarfönstret.

  1. Det bekräftar att de data du har valt är korrekta och redo att laddas in i måltabellen.
  2. Klicka på OK-knappen för att gå vidare

Bekräftelsefönstret upprepar de fyra kolumnerna som nu ska läsas.

SQL-redigerarfönstret bekräftar den åsidosatta frågan före mappningenping sparas

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.

  1. 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.
  2. 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.

  3. 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.

Fliken Egenskaper för källkvalificerare med källfilter, antal sorterade portar och välj distinkt

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.

Vanliga frågor

Pre-SQL-kommandon körs mot källdatabasen innan integrationstjänsten läser källkoden. Post-SQL-kommandon körs mot samma databas efter att integrationstjänsten har slutfört skrivningen till målet.

Tracing level anger hur mycket detaljer transformationen skriver in i sessionsloggen. En högre nivå hjälper till vid diagnostisering av ett oväntat radantal, men den förstorar loggen och saktar ner körningen, så sänk den efteråt.

SQL-redigeraren har en Validera-knapp. Den kör kommandot mot den valda ODBC-datakällan och rapporterar om syntaxen är korrekt, så att fel dyker upp i Designer istället för i en misslyckad session.

Ja. Parametrar och variabler är tillåtna i frågan, den användardefinierade kopplingen, källfiltret och kommandona före och efter sessionen. Omslut strängparametrar med den citerande stil som källdatabasen förväntar sig.

De deklarerar att en källa returnerar samma data, och samma ordning, mellan körningar. När båda är inställda hoppar integrationstjänsten över att mellanlagra källdata för återställning, vilket förkortar körningen.

Nej. Frågeöverskridanden, användardefinierade kopplingar, källfilter och kommandon före eller efter session skickas in i en databas, så de gäller relationella källor. En platt filkvalificerare styr huvudsakligen tracing och hamnordner.

AI-assistenter läser frågeplaner och arbetsbelastningshistorik för att föreslå predikat, index och kolumnrensning. Maskininlärningsbaserade rådgivare i moderna databaser rangordnar dessa förslag, men en utvecklare validerar fortfarande varje ändring innan den når en session.

Copilot kan utarbeta SELECT-satsen och snabba upp repetitiva kolumnlistor. Den känner inte till portordningen för din transformation, så verifiera den genererade satsen mot fliken Portar innan du sparar den.

Sammanfatta detta inlägg med: