Kildekvalifikationstransformation i Informatica med EKSEMPEL

⚡ Smart opsummering

Kildekvalifikatortransformationen i Informatica repræsenterer de rækker, som integrationstjenesten læser fra en relationel kilde eller flad fil, og den lader en udvikler tilsidesætte standardforespørgslen, filtrere, sortere og deduplikere disse data.

🧩 Automatisk objekt: En kildekvalifikator vises automatisk, når en relationel tabel eller en flad fil tilføjes til et kort.ping.
✍️ SQL-tilsidesættelse: En brugerdefineret forespørgsel erstatter den genererede SELECT og prioriteres over kildefilteret og indstillingen for sorterede porte.
🔢 Havneordre: SELECT-listen skal navngive porte i den rækkefølge, de vises i transformationen, ellers kan sessionen mislykkes.
🎯 Kildefilter: En filterbetingelse fjerner rækker i databasen, og nøgleordet WHERE skal udelades.
🔗 Enkeltpassage-sammenføjning: Relaterede tabeller fra én relationel kilde kan joineres i én kildekvalifikator i stedet for en joiner.
⚡ Less Trafik: Arbejde, der skubbes ind i kildeforespørgslen, flytter færre rækker på tværs af netværket ind i sessionen.

Læs mere

Hvad er kildekvalifikationstransformation?

Kildekvalifikatortransformationen er en aktiv, forbundet transformation, der repræsenterer de rækker, som integrationstjenesten læser, når en session kører. Når en relationel kilde eller en flad fil tilføjes til et kortping, en kildekvalifikatortransformation er påkrævet, og designeren tilføjer en automatisk. Med kildekvalifikatoren kan du definere og tilsidesætte, hvordan dataene hentes fra kilden.

Transformationen konverterer også kildens native datatyper til Informatica-transformationsdatatyper, så hver transformation, der placeres efter den, fungerer med ét platformneutralt sæt af typer.

Fordi kildekvalifikatoren opbygger den forespørgsel, der rent faktisk når databasen, er det det første sted, man skal kigge, når en kortping læser flere rækker eller flere kolonner end nødvendigt. Eksemplet nedenfor indsnævrer forespørgslen til fire kolonner.

Sådan ændrer du kildekvalifikatoren i Informatica

I det følgende eksempel ændrer vi kildekvalifikatoren for vores kort.ping “m_emp_emp_target”, så i stedet for at returnere alle kolonnerne returneres kun de valgte kolonner.

Trin 1) Åbn kortetping "m_emp_emp_target" i Kortping Designer. Kortetping åbner med EMP-kilden, SQ_EMP-kildekvalifikatoren og EMP_TARGET-målet på lærredet.

Trin 2) Double-klik på kildekvalifikatortransformationen “SQ_EMP”. Det åbner vinduet Rediger transformationer for det pågældende objekt. Derefter

Klik på fanen Egenskaber
Klik på knappen SQL Forespørgselsændringsindstilling, dette åbner et SQL-editorvindue

Fanen Egenskaber viser den SQL-forespørgselsrække, der er vist nedenfor.

Trin 3) I vinduet SQL-editor

Indtast følgende forespørgsel
```
SELECT  EMPNO,  ENAME,  JOB,  MGR FROM  EMP
```
Bemærk – vi vælger kolonnerne EMPNO, ENAME, JOB og MGR fra kildekoden, så vi har kun beholdt dem i select query'en.
Vælg OK-knappen

SQL-editoren indeholder nu den brugerdefinerede forespørgsel i stedet for den genererede.

Trin 4) I vinduet Rediger transformationer,

Vælg fanen Porte i menuen
Under fanen Porte kan du se alle portene. Behold kun portene EMPNO, ENAME, JOB og MGR, og slet de andre porte.

Fanen Porte viser alle porte, der blev medført af transformationen før sletningen.

Trin 5) Når portene er slettet, skal du vælge OK-knappen. Kun de fire resterende porte er tilbage på listen.

Klik nu på fanen Egenskaber igen i vinduet Rediger transformationer, hvorefter du kun vil se de data, du har valgt.

Når du klikker på knappen "OK", åbnes SQL Editor-vinduet.

Det vil bekræfte, at de valgte data er korrekte og klar til indlæsning i måltabellen.
Klik på OK-knappen for at fortsætte

Bekræftelsesvinduet gentager de fire kolonner, der nu skal læses.

Gem kortetping (ved hjælp af genvejstasten Ctrl+S) og udfør workflowEfter udførelse vil kun de valgte kolonner blive indlæst i målet.

På denne måde kan du i kildekvalifikatoren tilsidesætte, hvilke kolonner der skal hentes fra kilden, og dette er den eneste måde at kontrollere, hvilke specifikke kolonner der bringes ind i kortet.ping.

Egenskaber for kildekvalifikation

Du kan bruge forskellige egenskaber i kildekvalifikatoren til at bestemme, hvilken type kildedata der skal transformeres og sendes til måltabellen.

Kildefilter – Ved at bruge egenskaben Kildefilter kan du reducere antallet af kildeposter. Hvis du f.eks. kun vil hente medarbejderne i afdeling nr. 10, kan du indtaste filterbetingelsen deptnr.=10 i egenskaben Kildefilter og udføre dataene. Medtag tabelnavnet og portnavnet i betingelsen, og udelad nøgleordet WHERE – et filter, der indeholder WHERE, mislykkes med sessionen.
Antal sorterede porte – I Source Qualifier-transformationen kan du også sortere inputposterne efter portposition. Integrationstjenesten tilføjer en ORDER BY-klausul til standardforespørgslen og tæller porte fra toppen af transformationen, så dataene allerede er sorteret, når de når transformationerne inde i kortet.ping.
Da data kan sorteres på en enkelt port eller på flere porte, skal du angive antallet af porte, der skal bruges til sorteringen. Hvis du angiver værdien 1, sorteres kun empno-data. Hvis du angiver værdien 2, sorteres dataene på både empno og ename.
Vælg Distinkt – du kan kun hente forskellige poster fra kilden ved hjælp af denne egenskab. Når du vælger indstillingen Vælg forskelligartet, tilføjer integrationstjenesten en SELECT DISTINCT-sætning, så kun forskellige kombinationer af kildedata hentes af kildekvalifikatoren.

Fanen Egenskaber, der er vist nedenfor, indeholder disse muligheder sammen med resten af egenskabslisten.

Den fulde liste over egenskaber, der er tilgængelig for en relationel kildekvalifikator, er opsummeret i tabellen nedenfor.

Ejendom	Hvad gør den
SQL-forespørgsel	Erstatter standardforespørgslen genereret af integrationstjenesten. En brugerdefineret forespørgsel tilsidesætter en brugerdefineret join og et kildefilter.
Brugerdefineret tilslutning	Angiver den betingelse, der bruges til at sammenføje data fra flere kilder repræsenteret af den samme kildekvalifikator.
Kildefilter	Angiver den filterbetingelse, som integrationstjenesten anvender under forespørgsler på rækker.
Antal sorterede porte	Antal kolonner, der bruges til at sortere rækker læst fra relationelle kilder, tilføjet til forespørgslen som ORDER BY.
Tracniveau	Mængden af detaljer, der er skrevet til sessionsloggen for denne transformation.
Vælg Distinkt	Returnerer kun unikke rækker ved at tilføje SELECT DISTINCT til forespørgslen.
Pre-SQL	Kommandoer køres mod kildedatabasen, før integrationstjenesten læser kildekoden.
Post-SQL	Kommandoer kører mod kildedatabasen, efter at integrationstjenesten skriver til målet.
Outputtet er deterministisk	Erklærer, at kilden returnerer de samme data mellem kørsler, når inputtet er konsistent.
Outputtet er gentageligt	Erklærer, at kilden returnerer rækker i samme rækkefølge mellem kørsler, hvilket gør det muligt for integrationstjenesten at springe staging over for gendannelse.

Regler og retningslinjer for en SQL-override af kildekvalifikatorer

En SQL-override er effektiv, fordi den erstatter alt, hvad Designeren genererede, og det er også derfor, den afbrydes stille og roligt, når reglerne nedenfor ignoreres.

Tilslut portene først. Forbind alle input- og outputporte, du har til hensigt at bruge, før forespørgslen indtastes, fordi den genererede forespørgsel er bygget ud fra de tilsluttede porte.
Hold SELECT-listen i portrækkefølge. SELECT-sætningen skal angive portnavnene i den rækkefølge, de vises i transformationen. Hvis rækkefølgen ikke stemmer overens, kan sessionen mislykkes eller returnere uventede resultater.
Kvalificér hver kolonne. Hvert kolonnenavn skal have et præfiks af den tabel, visning eller det synonym, det tilhører, for eksempel ORDERS.ORDER_ID.
Generer før du redigerer. Hvis du klikker på Generer SQL, vises standardforespørgslen, som allerede indeholder kildefilteret og sorted-ports-klausulen, så tilsidesættelsen kan bygges ud fra en fungerende sætning.
Valider udsagnet. SQL-editoren har en Valider-knap, der kører forespørgslen og rapporterer, om syntaksen er korrekt, før sessionen overhovedet startes.
Citat reserverede ord. Alle databasereserverede ord, der bruges i forespørgslen, skal omsluttes af anførselstegn.
Hold øje med præcedensen. En brugerdefineret forespørgsel tilsidesætter kildefilteret og antallet af sorterede porte, og en SQL-forespørgsel indtastet i Session egenskaber tilsidesætter både filterbetingelsen og den forespørgsel, der er defineret i kortetping.

Til Microsoft SQL Server kilder er der én ekstra regel: antallet af kolonner i SELECT-sætningen skal stemme overens med antallet af porte i transformationen, ellers mislykkes sessionen under hentning af rækker.

Sådan forbinder du to kilder med én kildekvalifikator

En enkelt kildekvalifikator kan læse mere end én tabel. Når to relaterede tabeller fra den samme relationelle kilde er linket til én kildekvalifikator, forbinder integrationstjenesten dem i kildeforespørgslen i stedet for i kortet.ping, hvilket betyder, at databasen udfører arbejdet, og færre rækker bevæger sig til sessionen.

Standardjoinen er en indre equijoin, der er skrevet ind i WHERE-klausulen som Source1.column_name = Source2.column_name. For at denne join kan genereres, skal de joinede kolonner have en primær nøgle-fremmednøgle-relation og matchende datatyper. Hvor de importerede metadata ikke indeholder en sådan relation, kan du oprette en i Kildeanalysator ved at linke de matchende kolonner i de to kildedefinitioner.

Når relationen mangler, eller join'en skal være en outer join, skal du i stedet bruge egenskaben User-Defined Join. Den betingelse, der indtastes der, erstatter join-oplysningerne i metadataene, og integrationstjenesten tilføjer dem til den genererede forespørgsel.

To begrænsninger er værd at huske på. Begge tabeller skal komme fra den samme relationelle kilde, og kilder af forskellige typer – en flad fil og en tabel eller to forskellige databaser – skal forbindes med Snedker transformation i stedet.

Kildekvalifikator vs. filter vs. joiner-transformation

Tre objekter kan alle reducere eller kombinere rækker, og at vælge det forkerte objekt er en almindelig årsag til langsomme sessioner. Tabellen nedenfor viser dem side om side.

Aspect	Kildekvalifikation	Filtertransformation	Snedker transformation
Hvor arbejdet foregår	I kildedatabasen, inde i den genererede forespørgsel	I integrationstjenesten, række for række	I integrationstjenesten, ved hjælp af en cache
Hovedformål	Læs kilderækker, tilsidesæt forespørgslen, filtrer, sorter, deduplikér	Slip rækker, der ikke opfylder én betingelse	Kombinér to pipelines i ét rækkesæt
Kildetyper	Relationelle tabeller og flade filer fra én kilde	Eventuelle pipeline-data	Heterogene kilder, herunder flade filer og forskellige databaser
Tilmeld dig support	Indre equijoin eller en brugerdefineret join inden for én relationel kilde	Ingen	Normal, master ydre, detaljeret ydre og fuld ydre joinforbindelse
Rækker der krydser netværket	Kun de rækker, som forespørgslen returnerer	Hver kilderække læses først	Hver kilderække læses først

Den praktiske regel er enkel: filtrer og tilslut dig så tidligt som kilden tillader det, og find en Filtrer eller en Joiner kun til arbejde, som kildedatabasen ikke kan udføre. At pushe betingelser ind i kildekvalifikatoren er en af de billigste gevinster, der er tilgængelige under præstationsindstilling.

Ofte Stillede Spørgsmål

Pre-SQL-kommandoer køres mod kildedatabasen, før integrationstjenesten læser kilden. Post-SQL-kommandoer køres mod den samme database, efter integrationstjenesten er færdig med at skrive til destinationen.

Tracing level angiver, hvor mange detaljer transformationen skriver ind i sessionsloggen. Et højere niveau hjælper med at diagnosticere et uventet rækkeantal, men det forstørrer loggen og forsinker kørslen, så sænk det bagefter.

SQL-editoren har en Valider-knap. Den kører sætningen mod den valgte ODBC-datakilde og rapporterer, om syntaksen er korrekt, så fejlene dukker op i Designer i stedet for i en mislykket session.

Ja. Parametre og variabler er tilladt i forespørgslen, den brugerdefinerede join, kildefilteret og kommandoerne før og efter sessionen. Omslut strengparametre i den citeringsstil, som kildedatabasen forventer.

De erklærer, at en kilde returnerer de samme data og den samme rækkefølge mellem kørsler. Når begge er angivet, springer integrationstjenesten over at stille kildedataene til rådighed til gendannelse, hvilket forkorter kørslen.

Nej. Forespørgselsoverstyringer, brugerdefinerede joins, kildefiltre og kommandoer før eller efter session sendes ind i en database, så de gælder for relationelle kilder. En flad filkildekvalifikator styrer primært tracing og havneordre.

AI-assistenter læser forespørgselsplaner og arbejdsbelastningshistorik for at foreslå prædikater, indekser og kolonnebeskæring. Maskinlæringsbaserede rådgivere i moderne databaser rangerer disse forslag, men en udvikler validerer stadig hver ændring, før den når en session.

Copilot kan udarbejde SELECT-sætningen og fremskynde gentagne kolonnelister. Den kender ikke portrækkefølgen for din transformation, så verificer den genererede sætning mod fanen Porte, før du gemmer den.