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.

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 –
- SAP HANA grafisk beräkningsvy (Skapad av SAP HANA Studio grafisk redaktör).
- 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
- Gå till paket (Här Modellering) och högerklicka.
- Välj Nytt alternativ.
- Välj Beräkningsvy.
En beräkningsvyredigerare kommer att visas, där scenariepanelen visas enligt nedan –
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
- 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.
- Union: Detta används för att utföra all operation mellan flera källor. Källan kan vara n antal objekt.
- 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.
- Aggregering: Detta används för att utföra aggregering på specifika kolumner baserat på de valda attributen.
- 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)
- 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".
- 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".
- 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".
- Klicka på Gå med i nod från palett och dra och släpp till scenarioområdet.
- Anslut Projection_PO-noden till Join_1-noden.
- Anslut Projection_FI-noden till Join_1-noden.
- Klicka på Aggregationsnod från paletten och dra och släpp till scenarioområdet.
- Anslut Join_1-noden till Aggregationsnoden.
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.
- Välj all kolumn från Projection_PO Node för utdata.
- Välj all kolumn från noden Projection_FI för utdata.
- Koppla samman noden Projection_PO med noden Projection_FI i kolumnen Projection_PO.PO_Number = Projection_FI.PO_NO.
Steg 4) I detta steg
- Klicka på Aggregation nod och detalj kommer att visas på höger sida av rutan.
- Välj Kolumn för utdata från Join_1 som visas på höger sida i detaljfönstret.
Steg 5) Klicka nu på Semantics Node.
Detaljskärmen kommer att visas enligt nedan. Definiera attribut och måtttyp för kolumnen och markera även nyckeln för denna utdata.
- Definiera attribut och mått.
- Markera PO_Number och COMPANY som nyckel.
- Markera ACC_DOC_NO som nyckel.
Steg 6) Validera och aktivera beräkningsvy, från den övre raden i fönstret.
- Klicka på ikonen Validera.
- Klicka på Aktivera ikon.
Beräkningsvy kommer att aktiveras och visas under Modelleringspaket enligt nedan –
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 –
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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.








