SAP HANA-beräkningsvy: Typer och hur man skapar

⚡ Smart sammanfattning

Beräkningsvy i SAP HANA är den kraftfullaste informationsvyn. Den kombinerar tabeller, kolumnvyer, analysvyer och andra beräkningsvyer via join-, union-, projektions-, aggregerings- och ranknoder.

  • 🧩 Kärnsyfte: Hanterar scenarier som behöver mått från mer än en faktatabell, vilket en analytisk vy inte kan göra.
  • 🗂️ Data Foundation: Tabeller, kolumnvyer, analysvyer och andra beräkningsvyer kan alla vara källor.
  • 🔧 Fem nodtyper: Join, Union, Projection, Aggregation och Rank bygger scenariot grafiskt.
  • ⚖️ Nodgränser: En join-nod accepterar exakt två källor; en projektion accepterar en; en union accepterar många.
  • 🌐 Inbyggd hantering: Klient-, språk- och valutakonvertering stöds inbyggt.
  • ✍️ Två smaker: Grafiska vyer är byggda i editorn; skriptbaserade vyer är skrivna i SQLScript.
  • 📊 Rapporteringsflexibilitet: En beräkningsvy kan innehålla flera mått, eller inga alls för rapportering med listformat.

SAP HANA-beräkningsvy

Vad är beräkningsvy?

SAP HANA Beräkningsvy är en kraftfull informationsvy.

SAP HANA Analytisk vymått kan väljas från endast en faktatabell. När det finns behov av mer faktatabell i informationsvyn kommer beräkningsvyn med i bilden. Beräkningsvy stöder komplexa beräkningar.

Databasen för beräkningsvyn kan inkludera tabeller, kolumnvyer, analytiska vyer och beräkningsvyer.

Vi kan skapa Fogar, fackföreningar, aggregering och prognoser på datakällor.

Beräkningsvy kan innehålla flera mått och kan användas för flerdimensionell rapportering eller inget mått som används i listtypsrapportering.

Kännetecknande för SAP HANA-beräkning Se nedan –

  • Stöd komplexa beräkningar.
  • Stöd OLTP- och OLAP-modeller.
  • Support Kundhantering, språk, valutaomvandling.
  • Support Union, Projection, Aggregation, Rank, etc.

SAP HANA Calculation View är av två typer –

  1. SAP HANA grafisk beräkningsvy (Skapad av SAP HANA Studio grafisk redaktör).
  2. SAP HANA Skriptbaserade beräkningar Views (Skapade av SQL-skript av SAP HANA Studio).

Grafisk kontra skriptbaserad beräkningsvy

De två smakerna producerar samma typ av objekt men är byggda och underhållna på väldigt olika sätt, och valet är svårt att vända när en vy väl är i produktion.

Parameter Grafiskt Scriptbaserat
Byggt med Dra och släpp noder i redigeraren SQLScript i ett CE_- eller SQL-block
optimering Motorn kan rensa oanvända noder vid körning Körs som skrivet, mindre utrymme för optimering
läsbarhet Scenariediagrammet dokumenterar sig självt Beror helt på författaren
Capability Täcker de flesta krav Hanterar logik som ingen nodkombination kan uttrycka
Underhåll Vilken modell som helst kan följa den Kräver SQLScript-kunskaper
Rekommendation Standardval Bara där grafik verkligen inte kan göra det

Prestandapunkten är den avgörande. En grafisk vy låter HANA ignorera noder vars utdata inte behöver någon kolumn i frågan, så en oanvänd join kostar ingenting. En skriptbaserad vy kör varje instruktion den innehåller oavsett. Starta grafiskt och flytta en enskild nod till skriptet endast när kravet kräver det.

SAP HANA grafisk beräkningsvy

In SAP HANA analytisk vy, kan vi bara välja ett mått från en tabell.

Så när det finns ett krav på en vy som innehåller mått från den olika tabellen kan den inte uppnås genom analytisk vy utan genom beräkningsvy.

Så i det här fallet kan vi använda två olika analytiska vyer för varje tabell och slå samman dem i beräkningsvyn.

Vi kommer att skapa en grafisk beräkningsvy "CA_FI_LEDGER" genom att sammanfoga två analytiska vyer "AN_PURCHASE_ORDER" och "AN_FI_DOCUMENT".

CA_FI_LEDGER kommer att visa finansdokumentdetaljer relaterade till en inköpsorder.

Steg 1) I detta steg

  1. Gå till paket (Här Modellering) och högerklicka.
  2. Välj Nytt alternativ.
  3. Välj Beräkningsvy.

SAP HANA grafisk beräkningsvy

En beräkningsvyredigerare kommer att visas, där scenariepanelen visas enligt nedan –

SAP HANA grafisk beräkningsvy

Detalj av scenariopanelen är enligt nedan –

Palett: Det här avsnittet innehåller noder nedan som kan användas som källa för att bygga våra beräkningsvyer. Vi har 5 olika typer av noder, de är

  1. Ansluta sig: Denna nod används för att sammanfoga två källobjekt och skicka resultatet till nästa nod. Sammanfogningstyperna kan vara inre, vänster yttre, höger yttre och textsammanfogning. Obs: Vi kan bara lägga till två källobjekt till en kopplingsnod.
  2. Union: Detta används för att utföra all operation mellan flera källor. Källan kan vara n antal objekt.
  3. Utsprång: Detta används för att välja kolumner, filtrera data och skapa ytterligare kolumner innan vi använder det i nästa noder som en union, aggregering och rangordning. Obs: Vi kan bara lägga till ett källobjekt i en projektionsnod.
  4. Aggregering: Detta används för att utföra aggregering på specifika kolumner baserat på de valda attributen.
  5. Rank: Detta är den exakta ersättningen för RANK-funktionen i SQL. Vi kan definiera partitionen och ordna efter klausul baserat på kravet.

Steg 2)

  1. Klicka på Projektionsnod från paletten och dra och släpp till scenarioområdet från analysvyn för inköpsorder. Döpte om det till "Projection_PO".
  2. Klicka på Projektionsnod från paletten och dra och släpp till scenarioområdet för FI-dokumentanalysvy. Döpte om det till "Projection_FI".
  3. Dra och släpp den analytiska vyn "AN_PURCHASE_ORDER" och "AN_FI_DOCUMENT" från innehållsmappen till noden "Projection_PO" respektive noden "Projection_FI".
  4. Klicka på Gå med i nod från palett och dra och släpp till scenarioområdet.
  5. Anslut Projection_PO-noden till Join_1-noden.
  6. Anslut Projection_FI-noden till Join_1-noden.
  7. Klicka på Aggregationsnod från paletten och dra och släpp till scenarioområdet.
  8. Anslut Join_1-noden till Aggregationsnoden.

SAP HANA grafisk beräkningsvy

Vi har lagt till två analytiska vyer för att skapa en beräkningsvy.

Steg 3) Klicka på Join_1-noden under aggregering och du kan se detaljsektionen visas.

  1. Välj all kolumn från Projection_PO Node för utdata.
  2. Välj all kolumn från noden Projection_FI för utdata.
  3. Koppla samman noden Projection_PO med noden Projection_FI i kolumnen Projection_PO.PO_Number = Projection_FI.PO_NO.

SAP HANA grafisk beräkningsvy

Steg 4) I detta steg

  1. Klicka på Aggregation nod och detalj kommer att visas på höger sida av rutan.
  2. Välj Kolumn för utdata från Join_1 som visas på höger sida i detaljfönstret.

SAP HANA grafisk beräkningsvy

Steg 5) Klicka nu på Semantics Node.

SAP HANA grafisk beräkningsvy

Detaljskärmen kommer att visas enligt nedan. Definiera attribut och måtttyp för kolumnen och markera även nyckeln för denna utdata.

  1. Definiera attribut och mått.
  2. Markera PO_Number och COMPANY som nyckel.
  3. Markera ACC_DOC_NO som nyckel.

SAP HANA grafisk beräkningsvy

Steg 6) Validera och aktivera beräkningsvy, från den övre raden i fönstret.

SAP HANA grafisk beräkningsvy

  1. Klicka på ikonen Validera.
  2. Klicka på Aktivera ikon.

Beräkningsvy kommer att aktiveras och visas under Modelleringspaket enligt nedan –

SAP HANA grafisk beräkningsvy

Välj beräkningsvy och högerklicka -> Förhandsgranskning av data

Vi har lagt till två analytiska vyer och väljer mått (TAX_AMOUNT, GROSS_AMOUNT) från båda analytiska vyerna.

Skärmen för förhandsgranskning av data kommer att visas enligt nedan –

SAP HANA grafisk beräkningsvy

CE-funktioner i skriptbaserade vyer

⚠️ Versionsinformation: Beräkningsmotorns planoperatorer, CE_-funktionerna som beskrivs nedan, är föråldrade av SAPDe finns fortfarande dokumenterade här eftersom en stor del av befintlig kod använder dem, men ny utveckling bör använda standard-SQL, vilket optimeraren nu hanterar minst lika bra. Att blanda CE_-funktioner och SQL i ett programsats är också en känd orsak till dåliga planer.

CE-funktioner även kända som beräkningsmotorplan Operator (CE Operators) är alternativ till SQL-satser.

CE-funktionen är två typer -

Funktion för åtkomst till datakälla

Den här funktionen binder en kolumntabell eller en kolumnvy till en tabellvariabel. Nedan följer en lista över funktioner för åtkomst till datakällor –

  • CE_COLUMN_TABLE
  • CE_JOIN_VIEW
  • CE_OLAP_VIEW
  • CE_CALC_VIEW

Relations Operator Funktion

Genom att använda Relational Operator kan användaren kringgå SQL processorn under utvärderingen och kommunicera direkt med beräkningsmotorn. Nedan följer några relationella Operator Funktionslista –

  • CE_JOIN (Används för att utföra en inner join mellan två källor och läsa nödvändiga kolumner/data.)
  • CE_RIGHT_OUTER_JOIN (Används för att utföra en höger yttre koppling mellan de två källorna och visa de efterfrågade kolumnerna i utdata.)
  • CE_LEFT_OUTER_JOIN (Används för att utföra left outer join mellan källorna och visa de efterfrågade kolumnerna i utdata).
  • CE_PROJECTION (Denna funktion visar specifika kolumner från källan och tillämpar filter för att begränsa data. Den tillhandahåller även funktioner för alias för kolumnnamn.)
  • CE_CALC (Används för att beräkna ytterligare kolumner baserat på affärskraven. Detta är samma sak som beräknad kolumn i grafiska modeller.)

Nedan är en lista över SQL med CE-funktion med några exempel-

Fråga namn SQL-fråga CE-Inbyggd funktion
Välj fråga i kolumntabell VÄLJ C, D Från "COLUMN_TABLE". CE_COLUMN_TABLE(“COLUMN_TABLE”,[C,D])
Välj fråga i attributvyn VÄLJ C, D Från "ATTRIBUTE_VIEW" CE_JOIN_VIEW(“ATTRIBUTE_VIEW”,[C,D])
Välj Fråga i analytisk vy VÄLJ C, D, SUM(E) Från "ANALYTIC_VIEW"-gruppen efter C,D CE_OLAP_VIEW(”ANALYTIC_VIEW”,[C,D])
Välj Fråga i beräkningsvy VÄLJ C, D, SUM(E) Från "CALCULATION_VIEW" Grupp efter C,D CE_CALC_VIEW(“CALCULATION_VIEW”,[C,D])
Var har VÄLJ C, D, SUM(E) Från “ANALYTIC_VIEW” Där C = 'värde' var1 = CE_KOLUMN_TABELL("KOLUMN_TABELL");
CE_PROJECTION(:var1,[C,D],'”C” = ”värde”')

Beräkningsvytyper: Dimension, Kub och Kub med stjärnkoppling

Aktuella SAP HANA-versioner frågar efter en datakategori när en beräkningsvy skapas, och valet avgör vad vyn kan göra och hur rapporteringsverktyg behandlar den.

Datakategori Innehåller åtgärder Stjärnanslutning tillgänglig Ersätter
Dimensionera Nej Nej Attributvy
Cube Ja Nej Enkla analytiska scenarier
Kub med stjärnkoppling Ja Ja Analytisk vy

Det är därför som nuvarande projekt ofta bara bygger beräkningsvyer. En vy av kategorin Dimension utför jobbet som en attributvy, och Cube med Star Join gör jobbet av en analytisk vy, så en objekttyp täcker hela modellen. Befintliga attribut- och analysvyer fortsätter att fungera, och koncepten mappas direkt till kategorierna ovan.

Tips för prestanda i beräkningsvyn

En beräkningsvy är tillräckligt flexibel för att kunna byggas dåligt, och samma scenario kan köras på en sekund eller en minut beroende på hur noderna är arrangerade. Sex regler täcker det mesta av skillnaden.

  1. Filtrera så tidigt som möjligt. Placera ett filter i projektionen närmast källan. Filtrering efter en aggregering innebär att hela datamängden aggregerades först, sedan ignorerades det mesta.
  2. Sammanställ innan du går med där det är möjligt. Att sammanfoga två stora detaljuppsättningar och aggregera dem efteråt flyttar betydligt fler rader än att aggregera varje sida först.
  3. Markera endast de kolumner du behöver. Varje kolumn som transporteras genom en nod lagras i minnet under hela körningen, och oanvända kolumner blockerar nodbeskärning.
  4. Föredrar fackförening framför att gå med för att kombinera liknande data. Att stapla utvärderade värden och planen är en förening. Att uttrycka det som en koppling multiplicerar rader och behöver sedan ett filter för att ångra skadan.
  5. Titta på kopplingskardinaliteten. Att deklarera 1..1 där data är 1..N duplicerar rader och blåser upp varje mått, vilket är den vanligaste orsaken till felaktiga totaler.
  6. Undvik att stapla vyer för djupt. En beräkningsvy i en beräkningsvy i en analytisk vy är tillåten men svår att optimera och svårare att felsöka. Två nivåer är oftast tillräckligt.

Använd verktygen för prestandaanalys i redigeraren istället för att gissa.Viz visar vilken nod som förbrukade tiden, och svaret är ofta ett filter som placerats en nod för sent. Den bredare metoden beskrivs i SAP HANA-modellering handledning och proceduralternativ i SQL-skript.

Vanliga frågor

En join är en binär operation, så noden speglar det. Att koppla ihop tre källor innebär att kedja ihop två join-noder, vilket också gör utvärderingsordningen explicit.

Nej. Beräkningsmotorns planoperatorer är föråldrade. Befintlig kod fortsätter att fungera, men standard-SQL är den rekommenderade metoden och ger generellt sett en bättre exekveringsplan.

Ja. Läser planenViz utdata identifierar AI den nod som förbrukar tid och rekommenderar vanligtvis att man flyttar ett filter tidigare eller aggregerar före en join.

Ja. Varje CE_-operator har en direkt SQL-ekvivalent, så AI kan översätta blocket och markera de få fall där beteendet skiljer sig åt. Jämför resultaten innan du ersätter produktionskod.

Ja. En vy av datakategorin Dimension innehåller endast attribut och används för rapportering av listformat eller som en återanvändbar huvuddatakälla för andra vyer.

Sammanfatta detta inlägg med: