Mały Glosariusz SAP (część III)

Część trzecia jest prezentacją kilku podejść do tworzenia wirtualnych modeli danych (VDM). Będzie mowa o Core Data Services oraz HANA Views, ich podobieństwach, różnicach i zastosowaniach.

Spis treści:

1. Wstęp

2. Indeks skrótów

Część I

3. SAP HANA Cloud Platform (HCP) vs. SAP Cloud Platform
4. Środowiska i narzędzia deweloperskie (/administracyjne)
   1. Cloud czy on-premise
   2. SAP HANA Studio/Eclipse
   3. Rodzina narzędzi typu Web IDE
      1. SAP Web IDE
      2. SAP HANA Web-based Development Workbench
      3. SAP Web IDE for HANA
      4. SAP Web IDE Full-stack
   4. SAP Design Studio (oraz SAP Lumira, SAP Lumira Discovery, SAP Lumira Designer)
   5. Źródła

Część II

5. HANA vs. HANA DB vs. HANA Platform
   1. Źródła
6. XS vs. XSA/HDI
   1. Wstęp
   2. Extended Application Services Classic (XS lub XSC)
   3. Extended Application Services Advanced (XSA) + HDI
   4. HDI (HANA Deployment Infrastucture)
   5. Cloud Foundry
   6. Źródła
7. S/4HANA, C/4HANA, BW/4HANA (x/4HANA)
8. SAP BW
   1. Źródła
9. BW on HANA, BW powered by HANA, BW/4HANA
   1. Źródła (i auto-źródła)
10. Embedded BW
    1. Źródła
11. S/4HANA Embedded Analytics

Część III

12. Virtual Data Model (VDM)
13. HANA Native Views (HANA Views, HANA Information Views)
    1. Attribute View
    2. Analytic View
    3. Calculation View
    4. SAP HANA Live
    5. SAP HANA Live Browser
    6. Źródła
14. Core Data Services (CDS)
    1. Wstęp
    2. ABAP CDS vs. HANA CDS
    3. Źródła

12. Virtual Data Model (VDM)

Jest to dodatkowa struktura logiczna (warstwa lub warstwy) rozpięta na obiektach, gdzie dane są „fizycznie” przechowywane, np. na tabelach, plikach. Celem VDM jest uzyskanie wartości dodanej. Może to być dla przykładu:

• wzbogacenie informacji już istniejących, przez stworzenie dodatkowych połączeń (kilku różnych tabel), przekształceń, kalkulacji
• przedstawienie informacji w inny sposób (bardziej czytelny, lub ujawniający pewne rzeczy, których nie widać na pierwszy rzut oka)
• wykonanie obliczeń na surowych danych źródłowych i prezentacja gotowych wyników

VDM może służyć jako warstwa bezpieczeństwa, chroniąca przed bezpośrednim dostępem do danych.

13. HANA Native Views (HANA Views, HANA Information Views)

Natywne widoki HANA to widoki bazodanowe budowane za pomocą predefiniowanych building blocks, z wykorzystaniem edytora graficznego. Forma graficzna jest preferowana, natomiast jest również opcja „zaawansowana” tworzenia widoków – w edytorze SQLScript. Jest to podejście niezalecane, w przypadku konieczności wykorzystania skryptów powinny zostać wykorzystane Table Functions.

Niegdyś w użyciu były trzy typy widoków (Attribute View, Analytic View, Calculation View), obecnie jest to ostatni z nich, który wchłonął funkcje dwóch poprzednich. Charakter widoku (w kontekście zestawu starych typów widoków) ustawia się teraz jako jedną z opcji Calculation View (CV).

Każdy z widoków/typów jest skojarzony z domyślnym typem silnika bazodanowego, który go przetwarza. Są trzy rodzaje silników: Join Engine (Attribute View), OLAP Engine (Analytic View) oraz Calculation Engine (Calculation View). Więcej poniżej.

13.1. Attribute View

Jest to typ widoku realizujący funkcję Master Data/Dimension (cecha + atrybuty). Widok łączy dane z tabeli centralnej z tabelami atrybutów, np. tabelę klientów z tabelą adresów. Attribute View nie obsługuje miarek (np. agregacji), traktuje je jako cechy. Głównym silnikiem przetwarzania jest Join Engine.

W nowym Calculation View, funkcjonalność Attribute View osiągana jest poprzez wybranie opcji „Data Category” = „Dimension”.

Powyżej – Przykłady  Calculation View – widoczny jest dodatkowy węzeł (domyślny dla CV typu „Dimension”), czyli projekcja, oraz segmentacja Join’ów.

13.2. Analytic View

Jest to typ widoku dedykowany do wielowymiarowej analizy danych, silnikiem jest OLAP Engine, łączący tabelę faktów z tabelami wymiarów.

W nowym Calculation View, funkcjonalność Attribute View osiągana jest poprzez wybranie opcji „Data Category” = „Cube with Star Join”.

13.3. Calculation View

Calculation View jest widokiem dającym największą elastyczność. Umożliwia tworzenie modeli wielopoziomowych. Bardzo przydatną funkcją przy pracy z CV, jest możliwość podejrzenia danych na każdym poziomie widoku. Tym samym sprawdzanie poprawności działania modelu i wyszukiwanie błędów są dużo łatwiejsze.

Są trzy typy Calculation View, wyboru dokonuje się w momencie tworzenia widoku:

• Dimension (dawny Attribute View), z węzłem domyślnym – Projection
• Cube with Star Join (dawny Analytic View), z węzłem domyślnym – Star Join
• Cube, z węzłem domyślnym – Aggregation

CV jest obecnie jedynym widokiem zalecanym do tworzenia modeli danych.

13.4. SAP HANA Live

Jest to dostarczany przez SAP wirtualny model danych (VDM), zbudowany z wykorzystaniem widoków natywnych HANA (Calculation Views) w architekturze XS. Widoki bazują na tabelach zawierających dane transakcyjne i dane podstawowe (Master Data) z systemów SAP Business Suite (ERP, CRM, SCM, etc.), operujących na bazie HANA. Analogiem HANA Live jest Embedded Analytics w systemie S/4HANA. Pomimo wspólnej koncepcji, HL i EA różnią się technologią, na której bazują. EA wykorzystuje Core Data Services (CDS), a HL widoki natywne.

Model HANA Live jest rozszerzalny (na zasadzie pracy na kopii obiektów), narzędziem do pracy jest HANA Studio (/Eclipse). Jest nieosiągalny z poziomu Web IDE for SAP HANA – narzędzie wspiera tylko architekturę XSA/HDI.

Rozszerzeniem (płatnym) HANA Live, oferującym zestaw raportów dla rożnych narzędzi analitycznych (np. SAP Crystal Reports) jest Rapid Deployment Solutions (RDS).

Idea jest taka sama, jak przy Business Content w systemie SAP BW – dostarczenie modeli danych (HANA Live) i raportów (RDS) gotowych do użycia.

13.5. SAP HANA Live Browser

Jest to aplikacja webowa, pozwalająca na przeglądanie i wyszukiwanie widoków natywnych HANA (zarówno dostarczanych z HANA Live jak i customowych), dzięki czemu możliwe jest wykorzystanie ich w narzędziach SAP Lumira, SAP BusinessObjects Analysis lub innych narzędziach BI. SAP HANA Live Browser wymaga dodatkowej instalacji względem bazy HANA.

13.6. Źródła

• Supported Data Categories for Calculation Views https://help.sap.com/viewer/e8e6c8142e60469bb401de5fdb6f7c00/2.0.00/en-US/e8b26f49218648eaa8e2ce9b54a8b812.html
• SAP HANA Live & S/4HANA Embedded Analytics https://blogs.sap.com/2013/01/02/sap-hana-live-s4hana-embedded-analytics/
• https://www.sap.com/products/operational-reporting-hana-live.html

14. Core Data Services (CDS)

14.1. Wstęp

CDSy pojawiły się wraz z rozwojem HANY, jako odpowiedź na potrzebę możliwości tworzenia modeli danych dla natywnych aplikacji HANA (XS) oraz ideę przesunięcia części logiki do bazy (Data-Centric Logic). Są dwa typy CDS: ABAP CDS oraz HANA CDS – o tym nieco więcej w kolejnym rozdziale. Tutaj opiszę CDS na przykładzie ABAP CDS.

Pierwotnie, gdy ABAP był podstawą dla realizacji logiki, zarówno język zapytań (Open SQL) oraz definiowane obiektów (widoków, tabel) w ABAP Dictionary, były mocno ograniczone w stosunku do pełnych możliwości standardu SQL. Ograniczenia języka zapytań Open SQL wynikają z operowania w obrębie różnych baz danych. Każda z nich, pomimo wspólnego rdzenia, niektóre aspekty realizuje inaczej (np. kwestie zaokrągleń). Dlatego, aby wyniki uzyskiwane za pomocą Open SQL były zawsze jednakowe, wspierane są jedynie te funkcje, które są wspólne dla wszystkich baz.

Skromny jest również zakres tworzenia obiektów bazodanowych oferowany w ramach ABAP Dictionary – w zasadzie, są to tylko proste widoki SQL – bez możliwości tworzenia struktur wielopoziomowych, czy korzystania z dodatkowych, kalkulowanych pól.

Koncepcja CDS niesie ze sobą istotną separację pomiędzy tworzeniem aplikacji i bazy danych. Praca ze strony dewelopera opiera się na kodzie oraz meta-modelu obiektów bazodanowych (tzw. design-time objects, czyli pliki z definicjami). Dopiero w momencie build’a obiekty te, przyjmują „fizyczną” postać jako run-time objects (widoki, tabele, procedury etc.). Zajmuje się tym system, więc jest to dodatkowy poziom dla zapewnienia spójności modelu.

CDS to dodatkowa warstwa na wierzchu SQL, dająca możliwość wzbogacania czysto technicznych możliwości języka o metadane. Wykorzystując adnotacje (annotations), można systemowi podpowiedzieć np. jakie jest znaczenie kolumny, jaki jest jej opis lub w jaki sposób powinna przebiegać agregacja.

Myślę, że ten artykuł dobrze opisuje koncepcję CDS, warto do niego zajrzeć.

Kilka słów o (ABAP) CDS-ach:

• „Jest to kolekcja języków specjalizowanych (DDL, QL, DCL), służąca definiowaniu i konsumowaniu semantycznie bogatych modeli danych.”

DDL – Data Definition Language:

• Służy modelowaniu i danych na poziomie semantycznie wyższym niż SQL
• Rozszerza możliwości SQL

DCL – Data Control Language:

• Służy kontroli dostępu do danych, według określonych parametrów

QL – Query Language, język zapytań

• Są niezależne od bazy danych (Database Independent)
• Są definiowane w ABAPie (jako meta-obiekty typu design-time), dotyczą natomiast SQL i bazy danych
• Są zintegrowane z ABAP Lifecycle, mogą być transportowane pomiędzy systemami
• Dają podstawę do budowy zunifikowanego modelu, umożliwiającego pracę na danych operacyjnych, wyszukiwanie informacji oraz budowę aplikacji analitycznych

14.2. ABAP CDS vs. HANA CDS

Technologia CDS jest zaimplementowana w dwóch odsłonach: ABAP i HANA. Obydwie zbudowane na ten samej koncepcji, nie są jednak identyczne.

14.3. Źródła

• ABAP Core Data Services – Introduction (ABAP CDS view) https://blogs.sap.com/2017/09/09/abap-core-data-services-introduction-abap-cds-view/