slutter sig til SAP HANA: Typer, syntaks og eksempler

Af: Murer Garcia Murer Garcia
Hours Opdateret

⚡ Smart opsummering

SAP HANA forbinder connect-tabeller og informationsvisninger, så en model returnerer præcis de rækker, en rapport har brug for. Indre, ydre, referentielle, tekst-, tidsmæssige og rumlige typer ændrer hver især ydeevne, kardinalitetshåndtering og resultatstørrelse.

  • 🔗 Anvendelsesområde: Sammenkæder linktabeller og informationsvisninger i grafiske modeller og i almindelige SQL-sætninger i databasen.
  • ☑️ Standardtyper: Inner, left outer, right outer og full outer joins opfører sig præcis som de gør i ANSI SQL.
  • ✅ Kun modelleringstyper: Referentielle og tekstlige joinforbindelser findes kun inside informationsvisninger og har ingen tilsvarende SQL-nøgleord.
  • 🧪 Avancerede noder: Temporale, rumlige, dynamiske og stjernesammenføringer udvider beregningsvisninger ud over simpel kolonnematchning.
  • 🛠️ Ydelsesgreb: Kardinalitet og flaget Optimer Join-kolonner afgør, om SAP HANA kan beskære en tabel under kørsel.
  • 📈 Modernisering: Attribut- og analytiske visninger er forældede, så nye joins hører hjemme i grafiske beregningsvisninger.
Læs mere

Join-typer, der bruges til at kombinere tabeller og informationsvisninger i SAP HANA

Hvad er SAP HANA være med?

En deltager SAP HANA kombinerer rækker fra to eller flere tabeller, eller fra en tabel og en informationsvisning, og returnerer de værdier, der kræves af forespørgslen. Joins defineres grafisk i join-noden i en informationsvisning, og de skrives også direkte i SQL-sætninger, der kører på databasen.

De to former er ikke identiske. En join indeni en beregningsvisning udføres af SAP HANA-beregningsmotor, som kan springe en tabel over, når der ikke kommer en anmodet kolonne fra den, hvorimod en join skrevet i SAP HANA SQL udføres altid præcis som kodet.

Følgende join-typer er tilgængelige, når SAP HANA-tabeller og informationsvisninger kombineres.

Deltag Type Du bruger Kommentar
INNER Inner join vælger det sæt af poster, der matcher i begge tabeller. Rækker uden en partner på begge sider kasseres.
VENSTRE YDRE JOIN Venstre ydre join vælger det komplette sæt af poster fra den første tabel med den matchende post fra den anden tabel, hvor en er tilgængelig. Hvis der ikke findes et match i den anden tabel, returneres null-værdier for dens kolonner.
HØJRE YDRE JOIN Højre ydre join vælger det komplette sæt af poster fra den anden tabel med den matchende post fra den første tabel, hvor en er tilgængelig. Hvis der ikke findes et match i den første tabel, returneres null-værdier for dens kolonner.
FULD YDRE TILSLUTNING Fuld outer join vælger alle poster fra begge tabeller. Uoverensstemmende rækker fra begge sider udfyldes med nullværdier.
REFERENTIEL TILSLUTNING Opfører sig som en inner join, under antagelse af at referentiel integritet opretholdes mellem de to tabeller. Tilgængelig i attributvisninger, analytiske visninger og beregningsvisninger, der forbinder noder.
TEKST TILMELD Tekstsammenføring vælger den sprogspecifikke beskrivelse, der tilhører en nøgle, ved hjælp af sprogkolonnen i teksttabellen. Sprogkolonnen, normalt SPRAS, skal markeres i join-egenskaberne.

Referentielle og tekstlige joins er kun modelleringstyper. De findes i join-noden i en informationsvisning og har intet tilsvarende nøgleord i SQL, hvilket er grunden til, at de vises i SAP HANA-modellering værktøjer i stedet for i en SELECT-sætning.

SAP HANA Join-syntaks og SQL-eksempler

Indre og ydre joins er skrevet i SAP HANA SQL med standard ANSI-syntaks, så en forespørgsel, der testes på en anden relationsdatabase, kører normalt uændret. Eksemplet nedenfor forbinder en salgsordretabel med en kundetabel og derefter med en tilstandstabel.

SELECT so.ORDER_ID, c.NAME, s.STATE_NAME, so.AMOUNT
FROM SALES_ORDER AS so
INNER JOIN CUSTOMER AS c
  ON so.CUSTOMER_ID = c.CUSTOMER_ID
LEFT OUTER JOIN STATE AS s
  ON c.STATE_CODE = s.STATE_CODE
WHERE so.AMOUNT > 1000
ORDER BY so.ORDER_ID;

Den indre join fjerner alle salgsordrer, hvis kundestamdata mangler. Den venstre ydre join beholder alle resterende ordrer, selv når tilstandskoden ikke har nogen beskrivelse, og returnerer et null-tilstandsnavn for disse rækker.ping De to join-typer ændrer derfor antallet af rækker, ikke kun de viste kolonner.

Grafiske modeller når det samme resultat uden SQL. En join-node placeres mellem to datakilder i visningseditoren, de kolonner, der danner join-betingelsen, kortlægges, og join-typen og kardinaliteten angives i nodeegenskaberne. SAP HANA Studio Både editoren og den browserbaserede modeler genererer runtime-SQL'en ud fra disse indstillinger.

Avancerede jointyper i SAP HANA-beregningsvisninger

Beregningsvisninger tilføjer join-adfærd, som almindelig SQL ikke udtrykker i et enkelt nøgleord. Disse indstillinger konfigureres på join-noden eller via en dedikeret nodetype.

Deltag Type Hvad gør den Typisk brug
Midlertidig tilslutning Matcher transaktionsposter med den stamdataversion, der var gyldig på en given dato, ved hjælp af felterne fra og til i stamdatakilden. Tidsafhængige stamdata, såsom et omkostningscenter, der har skiftet ejer. Join-typen skal være referentiel, og nøglen skal være en dato, et tidsstempel eller et heltal.
Rumlig sammenføjning Forbinder to kilder på en geometrisk kolonne med et rumligt prædikat såsom intersects eller within, i stedet for på en lighedsbetingelse. Geografisk analyse, for eksempel matchning af kundeplaceringer med salgsområder.
Dynamisk sammenføjning Opbygger join-betingelsen under kørsel ud fra de join-kolonner, som forespørgslen rent faktisk anmoder om, og aggregerer de resterende kolonner, før join'et udføres. Flerkolonne-joins, hvor forespørgselsgranulariteten varierer. Mindst én join-kolonne skal anmodes om, ellers mislykkes forespørgslen.
Stjernetilslutning Forbinder én faktakilde med flere dimensionsberegningsvisninger i en enkelt node. Stjerneskemamodeller, der erstatter den ældre analytiske visning.

En dynamisk join ændrer rækkefølgen af ​​operationer snarere end den matchende regel. I en statisk join deltager hver defineret kolonne i betingelsen, og aggregering sker bagefter; i en dynamisk join aggregeres de uanmodede kolonner først, hvilket normalt returnerer færre rækker og en forskellig total. De to besvarer derfor forskellige forretningsmæssige spørgsmål, så flaget er sat bevidst, ikke som en generel optimering.

RELATEREDE ARTIKLER

Sådan vælger du den rigtige join-type SAP HANA modellering

Valg af join påvirker både korrekthed og kørselstid, og den hurtigste join er den SAP HANA behøver aldrig at blive udført. Følgende regler dækker de fleste modelleringsbeslutninger.

  • Referenceforbindelse — brug den kun, når hver række på den ene side garanteret har en partner, fordi motoren muligvis udelader joiningen helt, når der ikke anmodes om nogen kolonne fra den joinede tabel.
  • Indvendig sammenføjning — brug det, når referentiel integritet ikke er garanteret, og uoverensstemmende rækker skal udelades.
  • Venstre ydre samling — brug den, når den første tabel styrer resultatet, og manglende stamdata stadig skal vises.
  • Fuld ydre samling — brug det sparsomt, da det er den dyreste mulighed og sjældent er påkrævet i rapporteringsmodeller.
  • Tekstforbindelse — brug den, når en beskrivelseskolonne afhænger af logonsproget.

To nodeegenskaber er lige så vigtige som selve jointypen. Kardinalitet (1:1, 1:n, n:1 eller n:m) fortæller motoren, hvor mange rækker der kan forventes på hver side, og funktionen Foreslå kardinalitet udleder den fra dataene. Flaget Optimer joinkolonner tillader derefter SAP HANA til at fjerne en join-kolonne fra udførelsesplanen, når forespørgslen ikke anmoder om den. En forkert kardinalitet kan lydløst multiplicere målinger, så den verificeres mod dataene i stedet for at antages.

En yderligere begrænsning former ny udvikling. Attributvisninger og analytiske visninger er udfaset, og SAP anbefaler at konvertere dem til grafiske beregningsvisninger, så en join, der er designet i dag, bygges normalt i en join-node til beregningsvisning eller stjernejoin. Baggrund om de ældre objekter er stadig nyttig, når en eksisterende model vedligeholdes, og attributvisning og analytisk visning Siderne beskriver, hvordan disse joins blev konfigureret. SAP Læringsmateriale om tilslut noder dækker den samme adfærd i SAP HANA Cloud og den bredere SAP HANA-vejledning Serien forklarer, hvor informationsvisninger passer ind i platformen.

Ofte Stillede Spørgsmål

Kardinalitet (1:1, 1:n, n:1, n:m) fortæller systemet, hvor mange matchende rækker der kan forventes på hver side. Det muliggør beskæring af sammenføjninger og beskytter aggregater. Foreslået kardinalitet udleder indstillingen fra dataene, hvilket er sikrere end at gætte.

Det lader SAP HANA fjerner en join-kolonne fra udførelsesplanen, når klientforespørgslen aldrig anmoder om den. Færre kolonner betyder færre grupper.pings og hurtigere runtimes, men resultaterne kan ændre sig, hvis den fjernede kolonne påvirkede aggregeringsniveauet.

Eksisterende objekter kører stadig, men begge visningstyper er forældede og kan ikke tilføjes til nye beregningsvisninger. SAP anbefaler at konvertere dem til grafiske beregningsvisninger, hvor de samme sammenføjningstyper plus stjernesammenføjning og spatial sammenføjning er tilgængelige.

Den skal bevare umatchede rækker fra begge sider, så ingen tabeller kan beskæres, og alle rækker materialiseres. En referentiel join kan derimod springes helt over, når forespørgslen ikke anmoder om nogen kolonne fra den joinede tabel.

Sprogkolonnen i teksttabellen, normalt SPRAS i SAP tabeller, er markeret i join-egenskaberne. SAP HANA filtrerer derefter beskrivelser efter sessionssproget, så én model betjener hvert logonsprog uden en separat visning.

Ja. En join-node accepterer tabeller, tabelfunktioner og andre beregningsvisninger som datakilder, hvilket er sådan dimensionsvisninger er knyttet til en faktatabel. Kolonnenavne kan variere, da join-betingelsen eksplicit knytter kolonner.

Maskinlæring profilerer kolonneværdier for at foreslå join-nøgler og kardinalitet, markerer modeller, hvis målinger oppustes efter en join, og grupperer næsten dublette visninger. SAP integrerer også prædiktive og generative tjenester i platformen, så scoring kører ved siden af ​​de modellerede data.

Copilot udarbejder kompetent standard SQL-joins og fremskynder gentagne SELECT-sætninger. Den kender ikke et skemas referentielle integritet, så join-type, kardinalitet og modelleringsindstillinger, såsom tekstjoin, skal stadig gennemgås i forhold til de faktiske data.

Opsummer dette indlæg med: