SAP

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

Kwiecień 26, 2019 0
Podziel się:

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. 4.1. Cloud czy on-premise
  2. 4.2. SAP HANA Studio/Eclipse
  3. 4.3. Rodzina narzędzi typu Web IDE
    1. 4.3.1. SAP Web IDE
    2. 4.3.2. SAP HANA Web-based Development Workbench
    3. 4.3.3. SAP Web IDE for HANA
    4. 4.3.4. SAP Web IDE Full-stack
  4. 4.4. SAP Design Studio (oraz SAP Lumira, SAP Lumira Discovery, SAP Lumira Designer)
  5. 4.5. Źródła
część
II
  • 5. HANA vs. HANA DB vs. HANA Platform

  1. 5.1. Źródła
  • 6. XS vs. XSA/HDI

  1. 6.1. Wstęp
  2. 6.2. Extended Application Services Classic (XS lub XSC)
  3. 6.3. Extended Application Services Advanced (XSA) + HDI
  4. 6.4. HDI (HANA Deployment Infrastucture)
  5. 6.5. Cloud Foundry
  6. 6.6. Źródła
  • 7. S/4HANA, C/4HANA, BW/4HANA (x/4HANA)

  • 8. SAP BW

  1. 8.1. Źródła
  • 9. BW on HANA, BW powered by HANA, BW/4HANA

  1. 9.1. Źródła (i auto-źródła)
  • 10. Embedded BW

  1. 10.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. 13.1. Attribute View
  2. 13.2. Analytic View
  3. 13.3. Calculation View
  4. 13.4. SAP HANA Live
  5. 13.5. SAP HANA Live Browser
  6. 13.6. Źródła
  • 14. Core Data Services (CDS)

  1. 14.1. Wstęp
  2. 14.2. ABAP CDS vs. HANA CDS
  3. 14.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.

Przykład Attribute View

Przykład Attribute View

 

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

Przykład Calculation View (cz. 1)

Przykład Calculation View (cz. 1)

Przykład Calculation View (cz. 2)

Przykład Calculation View (cz. 2)

Przykład Calculation View (cz. 3)

Przykład Calculation View (cz. 3)

Przykład Calculation View (cz. 4)

Przykład Calculation View (cz. 4)

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.

Przykład Analytic View (cz. 1)

Przykład Analytic View (cz. 1)

Przykład Analytic View (cz. 2)

Przykład Analytic View z punktem centralnym – Star Join (cz. 2).

Jako wymiary wykorzystane są widoki typu Attribute View.

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

Przykład Calculation View (odwzorowanie Analytic View)

Przykład analogicznego Calculation View (typ: Cube with Star Join). Jako wymiary wykorzystane są widoki typu Calculation View.

     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.

Calculation View i rodzaje węzłów.

Calculation View typu CUBE. Podstawowe węzły CV: Join, Union, Projection, Aggregation i Rank

 

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

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ć.

Przykład ABAP CDS DD z adnotacjami

Przykład ABAP CDS DD z adnotacjami (@…)

 

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

Tworzeniem ABAP CDS wg. wzorca

Tworzenie ABAP CDS z wykorzystaniem wzorców

     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.

ABAP CDS HANA CDS
Baza danych Any DB HANA DB
Repozytorium

(design-time objects)

ABAP Data Dictionary HANA Repository
Narzędzia SAP HANA Studio/Eclipse (ABAP Tools) SAP HANA Studio/Eclipse (HANA DB Dev Tools), WEB IDE
Cel Model danych dla dowolnych aplikacji Model danych dla natywnych aplikacji HANA
Kto (perspektywa) ABAP Developer DB Developer
Autoryzacje Możliwe wykorzystanie ABAP-based authorizations; CDS DCL Autoryzacje na poziomie bazy danych; CDS DCL
Natywny dla HANA nie tak
Komentarz ad-hoc no.1 Uproszczenie w stosunku do HANA CDS pod względem autoryzacji – operowanie na poziomie aplikacyjnym i wykorzystanie modelu ABAPowego HANA CDS daje dostęp do większej liczby natywnych funkcji HANA
Komentarz ad-hoc no.2 ABAP CDS wykorzystane są w S4/HANA Embedded Analytics

     14.3. Źródła

 

Oceń ten post
Kategorie: SAP
Bartosz Kurowski
Autor: Bartosz Kurowski
Konsultant i deweloper SAP BW/HANA z nutą ABAPa.

Imię i nazwisko (wymagane)

Adres email (wymagane)

Temat

Treść wiadomości

Zostaw komentarz