Università degli Studi di Padova - SIAGAS

 
Università degli Studi di Padova - SIAGAS
Università degli Studi di Padova
 Dipartimento di Matematica "Tullio Levi-Civita"
                Corso di Laurea in Informatica

Confronto tra modellazione classica con SAP
    Hana e modellazione XS Advanced
                         Tesi di laurea triennale

Relatore                                            Laureando
Prof. Tullio Vardanega                               Leo Moz

                     Anno Accademico 2018-2019
Università degli Studi di Padova - SIAGAS
Leo Moz: Confronto tra modellazione classica con SAP Hana e modellazione XS
Advanced, Tesi di laurea triennale, c Luglio 2019.
Sommario

Il presente documento descrive il lavoro svolto durante il periodo di stage dal laureando
Leo Moz presso l’azienda Méthode S.r.l di San Vendemiano (TV). Lo stage è stato
svolto alla conclusione del percorso di studi della Laurea Triennale in Informatica per
una durata totale di 320 ore.
Gli obiettivi da raggiungere rispondono alla necessità aziendale di ottenere una pano-
ramica sulle funzionalità del nuovo approccio di modellazione virtuale offerto da XS
Advanced in SAP Hana rispetto a quello classico attualmente in uso.
Il primo capitolo presenta la realtà aziendale, il suo dominio applicativo e gli strumenti
utilizzati. Il secondo capitolo descrive invece lo stage nel contesto di obiettivi, vantaggi
aziendali e vincoli da rispettare. Il terzo capitolo documenta lo svolgimento dello stage
presentando le attività svolte per punti salienti ed eventuali difficoltà incontrate. Il
quarto ed ultimo capitolo contiene una valutazione retrospettiva dello svolgimento
dello stage rispetto agli obiettivi iniziali e alle conoscenze acquisite dallo studente.

                                            iii
Indice

1 L’azienda                                                                                                                1
  1.1 Profilo aziendale . . . . . . . . . . . . .     .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    1
  1.2 Organizzazione interna . . . . . . . . . .      .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    1
  1.3 Dominio applicativo e soluzioni aziendali       .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    2
  1.4 Tecnologie utilizzate . . . . . . . . . . .     .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    4
       1.4.1 Back-end . . . . . . . . . . . . .       .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    4
       1.4.2 Front-end . . . . . . . . . . . . .      .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    5
       1.4.3 Altre tecnologie . . . . . . . . . .     .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    5
  1.5 Strumenti di supporto . . . . . . . . . .       .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    6
       1.5.1 Web Office (WO) . . . . . . . . .        .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    6
       1.5.2 FreshService . . . . . . . . . . . .     .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    7
       1.5.3 Wildix . . . . . . . . . . . . . . .     .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    7
       1.5.4 Google suite . . . . . . . . . . . .     .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    7
  1.6 Clienti . . . . . . . . . . . . . . . . . . .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    8
  1.7 Innovazione . . . . . . . . . . . . . . . .     .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    8

2 Lo stage                                                                                                                 9
  2.1 Vantaggi aziendali . . . . . . . . . . . . . . . . . . . . .                        .   .   .   .   .   .   .   .    9
  2.2 Presentazione del progetto . . . . . . . . . . . . . . . . .                        .   .   .   .   .   .   .   .   10
      2.2.1 Database colonnari e modellazione classica . . .                              .   .   .   .   .   .   .   .   11
      2.2.2 Extended Application Services Advanced (XSA)                                  .   .   .   .   .   .   .   .   11
      2.2.3 Confronto tra XSC e XSA . . . . . . . . . . . . .                             .   .   .   .   .   .   .   .   12
  2.3 Aspettative aziendali . . . . . . . . . . . . . . . . . . . .                       .   .   .   .   .   .   .   .   12
  2.4 Vincoli . . . . . . . . . . . . . . . . . . . . . . . . . . . .                     .   .   .   .   .   .   .   .   13
      2.4.1 Vincoli metodologici . . . . . . . . . . . . . . . .                          .   .   .   .   .   .   .   .   13
      2.4.2 Vincoli tecnologici . . . . . . . . . . . . . . . . .                         .   .   .   .   .   .   .   .   14
      2.4.3 Vincoli temporali . . . . . . . . . . . . . . . . . .                         .   .   .   .   .   .   .   .   14
  2.5 Aspettative personali . . . . . . . . . . . . . . . . . . . .                       .   .   .   .   .   .   .   .   15

3 Resoconto dello stage                                                                                                   17
  3.1 Pianificazione del lavoro . . . . . . . . . . . . . . .                 .   .   .   .   .   .   .   .   .   .   .   17
  3.2 Database colonnari . . . . . . . . . . . . . . . . . .                  .   .   .   .   .   .   .   .   .   .   .   17
      3.2.1 I database colonnari . . . . . . . . . . . . .                    .   .   .   .   .   .   .   .   .   .   .   17
      3.2.2 Confronto con i database row-oriented . . .                       .   .   .   .   .   .   .   .   .   .   .   19
      3.2.3 Database colonnari disponibili sul mercato .                      .   .   .   .   .   .   .   .   .   .   .   19
  3.3 SAP Hana Platform . . . . . . . . . . . . . . . . .                     .   .   .   .   .   .   .   .   .   .   .   21
  3.4 SAP Cloud Platform . . . . . . . . . . . . . . . . .                    .   .   .   .   .   .   .   .   .   .   .   23
      3.4.1 Neo & Cloud Foundry . . . . . . . . . . . .                       .   .   .   .   .   .   .   .   .   .   .   23

                                            v
vi                                                                                                                           INDICE

     3.5   Modellazione virtuale XS Classic      .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   25
           3.5.1 Calculation View . . . . .      .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   25
           3.5.2 Altri oggetti . . . . . . . .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   26
           3.5.3 Hana Studio . . . . . . .       .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   26
     3.6   Modellazione XS Advanced . . .        .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   28
           3.6.1 Cambio architetturale . .       .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   28
           3.6.2 Calculation View in XSA         .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   30
           3.6.3 WebIDE . . . . . . . . . .      .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   31
     3.7   Flowgraph XSA . . . . . . . . . .     .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   32
     3.8   Visione complessiva . . . . . . . .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   33

4 Valutazione retrospettiva                                                                                                          35
  4.1 Soddisfacimento degli obiettivi . . . . . . . . . . . . . . . . . . . . . .                                                    35
  4.2 Conoscenze acquisite . . . . . . . . . . . . . . . . . . . . . . . . . . . .                                                   35
  4.3 Confronto tra università e lavoro . . . . . . . . . . . . . . . . . . . . .                                                    36

Glossario                                                                                                                            37

Bibliografia                                                                                                                         39
Elenco delle figure

 1.1    Il ciclo di analisi nella BI moderna che evidenzia la natura interat-
        tiva dei report per rispondere più rapidamente alle domande sorte
        dalle precedenti (https://www.tableau.com/it-it/learn/articles/
        business-intelligence) . . . . . . . . . . . . . . . . . . . . . . . . .        2
 1.2    Infografica delle tipologie di soluzione offerte da Méthode (http://www.
        methode.it/soluzioni.php) . . . . . . . . . . . . . . . . . . . . . . .         3
 1.3    I principali strumenti di lavoro divisi per area di sviluppo e software
        house di provenienza . . . . . . . . . . . . . . . . . . . . . . . . . . . .     4
 1.4    La pianificazione delle attività secondo la vista divisa per team, in verde
        le attività in sede e in bianco quelle fuori sede . . . . . . . . . . . . . .   6
 1.5    Ciclo di vita di un ticket in FreshService (https://it.freshservice.
        com/incident-management-software) . . . . . . . . . . . . . . . . .              7

 2.1 Relazioni ed intersezioni degli intenti delle parti coinvolte in uno stage
     (https://link.medium.com/ifBGuxZf7X) . . . . . . . . . . . . . . . .               10
 2.2 L’avviso degli strumenti SAP che invita a passare ai nuovi strumenti
     (https://launchpad.support.sap.com/#/notes/2609527) . . . . . .                    11
 2.3 L’analogia Pizza as a Service che illustra le differenze tra On-Premise e
     Cloud (IaaS, PaaS e SaaS) (https://www.ebcgroup.co.uk/on-premises-
     vs-cloud#cloud-computing-as-a-pizza) . . . . . . . . . . . . . . .                 12
 2.4 Diagramma di Gantt dello stage . . . . . . . . . . . . . . . . . . . . .           15

 3.1    Differenza tra la memorizzazione row-oriented e column-oriented (https:
        //help.sap.com/doc/fb8f7a9f7860468b84a07eab0a7d0a98/2.0.01/en-
        US/SAP_HANA_Modeling_Guide_for_SAP_HANA_Studio_en.pdf (pag. 9)) 18
 3.2    SAP Hana Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . .       21
 3.3    SAP Hana Platform SQL Engine . . . . . . . . . . . . . . . . . . . . .          21
 3.4    Le operazioni sui due database in-memory . . . . . . . . . . . . . . . . 22
 3.5    SCP Neo e Cloud Foundry a confronto (https://blogs.sap.com/2019/
        02/24/sap-cloud-platform-environment-cloud-foundry-vs-neo)                      23
 3.6    Una Calculation View di tipo Dimension che associa ai materiali la loro
        descrizione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
 3.7    I nodi disponibili in Hana Studio per una Calculation View (https://
        help.sap.com/viewer/57a523b496cc4531a3676f5d94644899/1.0.12/
        en-US/a27ee2517d014277836442d37d6af25a.html) . . . . . . . . . . 26
 3.8    Hana Studio durante la realizzazione di una Calculation View . . . . .          27
 3.9    L’architettura di SAP Hana XS Advanced . . . . . . . . . . . . . . . . 28
 3.10   HDI risulta come uno schema isolato dagli altri . . . . . . . . . . . . . 29

                                           vii
3.11 Schema dei permessi necessari in HDI ( https://blogs.sap.com/2019/
      04/02/xsa-accessing-remote-sources-external-objects-schemas-
      etc) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .    29
 3.12 Una Calculation View in XSA ed i nuovi nodi disponibili . . . . . . .             30
 3.13 WebIDE con un progetto espanso nella colonna di sinistra . . . . . . .            31
 3.14 I nodi a disposizione per Flowgraph in XSA . . . . . . . . . . . . . . .          32
 3.15 Esempio di Flowgraph . . . . . . . . . . . . . . . . . . . . . . . . . . .        32

Elenco delle tabelle

 2.1   Obiettivi fissati dall’azienda . . . . . . . . . . . . . . . . . . . . . . . .   13

 3.1   Vantaggi e svantaggi dei database orientati alle colonne e alle righe (http:
       //www.timestored.com/time-series-data/what-is-a-column-oriented-
       database) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

                                          viii
Capitolo 1

L’azienda

1.1       Profilo aziendale
Méthode S.r.l. nasce nel 2004 quando tre giovani professionisti decidono di scommet-
tere sulla specializzazione nella Business Intelligence (BI)g . I valori fondanti sono
appunto la specifica focalizzazione, l’attenzione ai processi e la costante ricerca di vera
innovazione da portare alle aziende nel campo della Business Intelligence e Advanced
Analyticsg .1 (Si veda anche la sezione 1.3 sul dominio applicativo).
Inizialmente partner Business Object, è dal 2008 partner SAP: ad oggi Méthode è
SAP Gold Partner (SAP Recognized Expertise per la Business Intelligence, SAP Hana
e Enterprise Information Management).2
Opera principalmente nel Nord e nel Centro Italia tramite la sede legale ed operativa
in provincia di Treviso e la sede operativa di Milano.
In forte e recente espansione, Méthode si presenta come una struttura snella e compatta
di consulenti specializzati capaci di realizzare complessi progetti di BI.
L’ambiente di lavoro è giovane, stimolante e dinamico: i diversi team ed i singoli indivi-
dui lavorano a stretto contatto permettendo lo sviluppo di progetti di primo piano con
Aziende leader di settore. Tale ecosistema garantisce il confronto e l’interazione tra
colleghi dalle diverse competenze ed aiuta i tirocinanti durante il loro ingresso nella
realtà aziendale. A riprova di ciò è certificata Great Place to Work.3

1.2       Organizzazione interna
Méthode nasce come una piccola azienda e non si dota, inizialmente, di una vera e
propria struttura organizzata e ben definita. Nel corso degli anni è stata protagonista
di una forte crescita vantando ad oggi oltre 70 persone suddivise nelle due sedi aziendali.
Tale crescita è stata accompagnata da vari cambiamenti culminati nel recente avvio di
una ristrutturazione di tutti i settori dell’organizzazione interna.
Il personale è stato diviso in team basandosi sull’ambito di competenza specifica, ogni
team è guidato da un Team Leader che in accordo con i Project Manager assegnano e
  1 Méthode:  About. url: http://www.methode.it/about.php.
  2 SAP   Partner: Méthode. url: https : / / partneredge . sap . com / content / %20partnerfinder /
search.html#/partner/details/0000940767.
   3 Great Place to Work. url: https://www.greatplacetowork.it/aziende-certificate.

                                                1
2                                                            CAPITOLO 1. L’AZIENDA

supervisionano le attività produttive. A fianco dei team vi sono i reparti per la gestione
delle risorse umane, dell’amministrazione e del marketing.
La ristrutturazione, iniziata circa due anni fa, è ancora in corso di rifinitura e
miglioramento; i principali obiettivi sono:

    • essere pronti ad un’eventuale ulteriore crescita del personale;

    • migliorare l’interazione tra i clienti ed i consulenti aziendali;

    • ampliamento e miglioramento della gestione clienti per soddisfare in modo più
      efficace e più efficiente le diverse necessità;

    • continuare ad innalzare la qualità dei processi aziendali e dei prodotti finali.

1.3      Dominio applicativo e soluzioni aziendali
Méthode è un’azienda specializzata nel settore della Business Intelligence (BI).
La BI costituisce un ramo della cosiddetta informatica aziendale, consiste di strategie
e tecniche utili alle aziende per colmare la distanza tra i dati, le informazioni e le
persone che devono prendere decisioni: è un percorso che va dall’estrazione del dato,
al suo trattamento, fino alla sua presentazione nella forma migliore per fini di gestione
aziendale di varia tipologia.
Con il termine Business Intelligence ci si riferisce sia all’insieme dei processi aziendali
destinati a raccogliere ed analizzare informazioni, sia alle tecnologie e agli strumenti
impiegate nel processo; la finalità ultima è quella di analizzare e poi accedere ai risultati
per migliorare decisioni e prestazioni aziendali.4

Figura 1.1: Il ciclo di analisi nella BI moderna che evidenzia la natura interattiva dei report
            per rispondere più rapidamente alle domande sorte dalle precedenti (https:
            //www.tableau.com/it-it/learn/articles/business-intelligence)
   4 Gartner IT Glossary: BI. url: https://www.gartner.com/it-glossary/business-intelligenc

e-bi.
1.3. DOMINIO APPLICATIVO E SOLUZIONI AZIENDALI                                           3

Méthode propone varie soluzioni per supplire a queste esigenze aziendali d’importanza
strategica nel mondo business; le principali soluzioni offerte ricadono nei seguenti
campi:
   • Business Analytics
     Per decisioni di business basate su informazioni più precise, dettagliate ed
     aggiornate; offre reportingg , data discoveryg e dashboardg .
   • Predictive & Advanced Analytics
     Basata sull’analisi predittiva, supera la natura descrittiva della BI classica
     associando ad un evento la probabilità che accada; supporta tutti gli ambiti
     aziendali, dalle campagne pubblicitarie mirate, alla fidelizzazione del cliente, ed
     alla pianificazione di cicli manutentivi.
   • Process Mining
     Focalizzato sui propri processi aziendali per individuarne i punti deboli e le
     criticità; permette di comprendere se il proprio modello di business è efficiente, e
     nel caso di anomalie identificarle e correggerle.
   • BigData
     Fondamento delle successive analisi, con sempre più dispositivi e fonti informative
     (come sensori, social network, e strumenti connessi alla rete) è vitale istanziare
     processi e tecnologie per la gestione e l’immagazzinamento di queste grandi moli
     di dati; si ricorre pertanto a basi di dati performanti, efficaci e flessibili che
     consentano in seguito data integrationg , data qualityg , ed elaborazioni real time.
   • Cloud Solutions
     Il cloudg costituisce un nuovo approccio all’infrastruttura tecnologica, potenzial-
     mente può ridurre i costi (TCOg ) ed offrire possibilità più vicine all’Internet of
     Things (IoT)g e maggiormente scalabili.
   • Corporate Performance Management
     Per una migliore governance aziendale basata su strumenti per il budgeting, la
     pianificazione ed il controllo.

Figura 1.2: Infografica delle tipologie di soluzione offerte da Méthode (http://www.methode.
            it/soluzioni.php)
4                                                           CAPITOLO 1. L’AZIENDA

1.4         Tecnologie utilizzate
Data la complessità del dominio d’interesse (sezione 1.3), Méthode basa la quasi totalità
della sua offerta su prodotti, strumenti e suite software forniti da SAP, Microsoft, Qlik
e Tableau; queste software house propongono molteplici prodotti per ogni esigenza e
coprono l’intero stack di sviluppo, dall’immagazzinamento dei dati alla visualizzazione
di report finali.
Tali software operano prevalentemente per via grafica, raramente quindi lo sviluppo si
basa sulla tradizionale scrittura di codice; questo approccio permette di focalizzarsi
sulla logica del problema e demanda agli strumenti le ottimizzazioni di basso livello.
Sono inoltre d’aiuto nella gestione e sviluppo di progetti in contesti estesi e complessi.
In particolare la maggior parte delle attività aziendali gravita attorno all’universo SAP
ed i suoi svariati strumenti. Segue una panoramica dei principali suddivisa per area di
sviluppo.

Figura 1.3: I principali strumenti di lavoro divisi per area di sviluppo e software house di
            provenienza

1.4.1       Back-end
    • SAP Data Services5
      Strumento per l’Extract, Transform, Load (ETL)g , utilizzato principalmente per
      le sue funzionalità di data integration, data quality e data cleansingg .
    • SAP Hana Platform6
      Composto di vari moduli, usato per il suo database engine colonnare in-memory
      e per la modellazione dei dati. (Verrà approfondito nel capitolo 3).
    • SAP BW/4Hana7
      Per la creazione e la gestione di Enterprise Data Warehouseg , progettato per
    5 SAPProducts: Data Services. url: https://www.sap.com/products/data-services.html.
    6 SAPProducts: Hana Platform. url: https://www.sap.com/products/hana.html.
   7 SAP Products: BW/4Hana. url: https://www.sap.com/products/bw4hana-data-warehousing.

html.
1.4. TECNOLOGIE UTILIZZATE                                                                5

      operare al di sopra di Hana Platform e sfruttarne la tecnologia in-memory per
      migliori performance.
   • SQL Server Integration Services (SSIS)8
     Piattaforma software di Microsoft, offre funzionalità di ETL e di data integration.

1.4.2     Front-end
   • SAP BusinessObjects Business Intelligence suite9
     Piattaforma composta di strumenti per la creazione di report e analisi, include:
        – Information Design Tool (IDT): per la gestione del livello semantico ("uni-
          verso" nella terminologia SAP) che mappa i dati sottostanti in oggetti più
          familiari al mondo business (come prodotti, clienti e fatture);
        – Web Intelligence (WebI): per la realizzazione dei report.
   • SAP Lumira10
     Per la realizzazione di dashboard e lo sviluppo di applicazioni client.
   • QlikView11
     Strumento di Qlink per la creazione e la visualizzazione di dashboard.
   • PowerBI12
     Controparte Microsoft per la realizzazione di dashboard e la creazione di report.
   • Tableau13
     Soluzione proprietaria per il dashboarding interattivo.

1.4.3     Altre tecnologie
Oltre alle suite software citate, il lavoro in Méthode prevede, alla necessità, l’utilizzo
di un’ampia serie di altre tecnologie e linguaggi, tra cui:
   • Structured Query Language (SQL)
     In varie sue declinazioni, per l’interazione con database quali Oracle e SQL Server
     di Microsoft, in particolare nelle attività di back-endg .
   • Python
     Come linguaggio di scripting.
   • R
     Linguaggio specifico per l’analisi statistica.
   • C#, Java e NodeJS
     Linguaggi su cui si basano i principali strumenti utilizzati.
   • JavaScript, HTML e CSS
     Sussidio alle attività di front-endg .
   8 Microsoft: SQL Server Integration Services. url: https://docs.microsoft.com/en- us/sql/

integration-services/sql-server-integration-services.
   9 SAP Products: SAP BusinessObjects. url: https://www.sap.com/products/bi-platform.html.
  10 SAP Products: Lumira. url: https://www.sap.com/products/lumira.html.
  11 Qlik: QlikView. url: https://www.qlik.com/us/products/qlikview.
  12 Microsoft: PowerBI. url: https://powerbi.microsoft.com/en-us/what-is-power-bi/.
  13 Tableau. url: https://www.tableau.com/products/desktop.
6                                                          CAPITOLO 1. L’AZIENDA

1.5      Strumenti di supporto
Il personale di Méthode ha a sua disposizione alcuni strumenti di supporto, tali
strumenti sono parte integrante dell’ambiente e della configurazione aziendale; essi
facilitano la gestione del lavoro, la comunicazione interna ed esterna con i clienti.

1.5.1     Web Office (WO)
Sviluppato all’interno dell’azienda, è il principale strumento di supporto ed offre una
serie di servizi per la gestione delle risorse non informatiche, per la gestione delle
attività del personale e della regolamentazione aziendale.
I servizi offerti sono:
    • Bacheca
      Utilizzata per la pubblicazione di documenti e procedure generali destinate a
      tutto il personale, come: regolamenti, piani di evacuazione e informative sulla
      privacy.
    • Gestione dei rapportini
      Sezione in cui ogni lavoratore deve rendicontare le attività giornaliere svolte.
    • Scheduler sale e auto
      Riporta le prenotazione e le assegnazioni delle sale riunioni e delle auto aziendali.
    • Scheduler utente
      Sezione dedicata alla gestione delle attività, compilata dai Team Leader e dai
      Project Manager, elenca tutto il personale e le relative attività assegnate ad
      ognuno ogni giorno, mostra inoltre se la persona è in sede o presso il Cliente;
      questo permette di sapere con anticipo su cosa si dovrà lavorare, e consente la
      gestione e l’assegnazione delle risorse.
    • Gestione delle trasferte e delle note spesa
    • Gestione dei permessi e delle ferie

Figura 1.4: La pianificazione delle attività secondo la vista divisa per team, in verde le
            attività in sede e in bianco quelle fuori sede
1.5. STRUMENTI DI SUPPORTO                                                               7

1.5.2     FreshService
Portale web, è il sistema di ticketingg dell’azienda per il supporto interno, permette di:
   • prenotare una risorse condivisa (smartphone, tablet, ecc);
   • richiedere l’installazione o l’abilitazione a software particolari;
   • richiedere le credenziali e l’accesso alle macchine e ai servizi di sede;
   • gestire le sostituzioni della dotazione hardware (come schermi, tastiere);
   • segnalare anomalie alle infrastrutture o alle dotazioni.
Alla necessità occorre aprire un ticket che verrà preso in carica dal team di supporto
interno che provvederà, in base a urgenza e disponibilità, alla sua risoluzione. Dopo la
chiusura viene chiesto un feedback : sia funzionale (la richiesta è stata evasa interamente
e con successo) sia qualitativo (una valutazione di gradimento dell’intervento).

Figura 1.5: Ciclo di vita di un ticket in FreshService (https://it.freshservice.com/
            incident-management-software)

1.5.3     Wildix
Applicazione web per la gestione della telefonia sia verso numeri interni sia verso
numerazioni esterne. Consente di effettuare chiamate ai Clienti con la numerazione di
sede anche a chi è sprovvisto di telefono aziendale; costituisce inoltre punto di contatto
da parte dei Project Manager e dei colleghi fuori sede.

1.5.4     Google suite
Suite di servizi di Google, usata principalmente per:
   • GMail
     Il servizio di posta elettronica tramite il quale avvengono le comunicazioni con i
     Clienti.
   • Hangouts
     La chat integrata, che funge da strumento di comunicazione rapida interna.
   • GDrive
     Ogni team ha un suo spazio in cui sono condivise documentazioni, file d’interesse
     generale e materiale per l’auto-formazione.
8                                                               CAPITOLO 1. L’AZIENDA

1.6        Clienti
Méthode si rivolge a piccole, medie e grandi imprese intenzionate a ampliare la visione
che il loro management ha del proprio business. Più in generale si rivolge a quelle
aziende che desiderano conoscere il loro stato e le loro performance in modo innovativo,
più efficiente e più rapido, proponendo inoltre attività di analisi predittiva a partire
dallo storico aggiornato dei dati aziendali. Tali aziende appartengono ai settori più
disparati, tra i quali: alimentare, farmaceutico, manifatturiero, metalmeccanico, side-
rurgico e della moda.
Solitamente i Servizi sono sviluppati a partire da esigenze del Cliente: tali esigenze pos-
sono riguardare porzioni ristrette del loro business (come la gestione di dati telemetrici
di specifiche macchine) o aree più ampie che riguardano la quasi totalità dei dati in
loro possesso (come migrazionig o integrazioni di basi di dati con servizi preesistenti).
L’azienda si occupa anche della manutenzione e dell’evoluzione dei servizi sviluppati
qualora i Clienti riscontrino problematiche, cambino alcune logiche o richiedano nuove
funzionalità.

1.7        Innovazione
Lo sforzo innovativo di Méthode si concentra principalmente in tre aree.
     • Innovazione della struttura organizzativa interna
       Come detto la rapida crescita ha portato l’azienda a ripensare completamente
       la propria organizzazione interna, il processo è tutt’ora in corso con lo scopo di
       migliorare e rinnovare molti dei processi aziendali e produttivi.
       Offrono inoltre occasioni di stage, allo scopo di incorporare nuove menti e nuove
       idee e di formare i nuovi membri nelle discipline della Business Intelligence.14
       (Si veda anche il capitolo 2).
     • Innovazione tecnologica
       Come partner di SAP e di Qlik e come consulente di aziende leader di mercato,
       Méthode mira costantemente all’innovazione delle proprie soluzioni e quindi delle
       tecnologie e degli strumenti di lavoro. Propone già soluzioni di analisi predittiva
       il cui futuro è vicino al machine learning e all’intelligenza artificiale, ricerca e
       impiega le più moderne tecniche per la gestione di database e grosse moli di dati
       e recentemente sta lavorando su alcuni progetti di IoT e di real time monitoring;
       infine molti degli strumenti, piattaforme e software utilizzati offrono versioni
       basate sul cloud, l’oggetto di questo elaborato è appunto lo studio di uno di essi.
       Quando una nuova tecnologia o soluzione è stata provata e giudicata utile e
       stabile vengono organizzati dei corsi interni per la formazione del personale che
       la utilizzerà, si redigono poi guide all’uso e collezioni di best practiceg che si
       espanderanno nel tempo.

     • Istruzione e formazione
       Organizza approfondimenti, eventi, webinarg ed altre iniziative destinati ad enti
       esterni per pubblicizzare e diffondere i vantaggi dei nuovi approcci della Business
       Intelligence e delle nuove soluzioni tecnologiche15 .

    14 Méthode:   Internship. url: https://methode.breezy.hr/p/247d5e3ae5df01-internship.
    15 Méthode:   Mediateca. url: http://www.methode.it/mediateca.php.
Capitolo 2

Lo stage

2.1      Vantaggi aziendali
Méthode è un’azienda in crescita e nel corso di una forte ristrutturazione della sua
organizzazione interna ed è quindi alla ricerca di nuovo personale da formare ed
aggiungere all’organico. Dal 2018 infatti partecipa all’evento Stage-IT 1 per incontrare
e discutere con gli studenti proposte di stage.
In base al corso di studi di provenienza del candidato, il periodo e le attività di
tirocinio vengono investite per svolgere prove ed esplorazioni su nuovi strumenti, nuove
funzionalità e nuove versioni degli strumenti già in uso.
Affinché l’esperienza sia significativa lo stagista viene inserito in un team, gli vengono
erogati i fondamenti degli strumenti e delle logiche in gioco così che al termine dello stage
curricolare sia una potenziale risorsa già avviata ed integrata nel contesto aziendale.
Al primo periodo di apprendimento e formazione ne segue uno di esplorazione, i possibili
temi sono decisi dall’azienda sulla base della provenienza del candidato e delle necessità
interne correnti; questo approccio porta all’azienda tre principali vantaggi:

   • permette l’esplorazione e la sperimentazione delle novità, sia tecnologiche sia
     metodologiche, senza sottrarre tempo al personale già occupato con le tradizionali
     attività provate e consolidate;

   • consente di rimanere informati sullo stato delle novità, se o quanto esse siano
     mature per un uso commerciale;

   • in tutti i casi, al termine dello stage, la risorsa risulterà aggiornata ed informata
     sullo stato e le capacità di quanto esplorato, e costituirà una solida posizione da cui
     partire per integrare la novità nel ciclo produttivo o semplicemente approfondire
     l’analisi in seguito a cambiamenti.

La presenza di nuovo personale è anche occasione per erogare e quindi migliorare corsi
di formazione interna. Questi corsi, tenuti dal personale più esperto, sono destinati sia
ai nuovi arrivati sia al personale già presente che per qualsiasi esigenza abbia bisogno di
aggiungere uno strumento o delle conoscenze in qualche ambito; una nuova erogazione
consente di aggiornare e migliorare il materiale di supporto e l’esposizione migliorando
la qualità della formazione interna.
Infine la presenza di menti fresche, esterne alla realtà aziendale e dal diverso trascorso,
  1 UniPD:   Stage-IT. url: http://informatica.math.unipd.it/laurea/stageit.html.

                                             9
10                                                              CAPITOLO 2. LO STAGE

garantisce all’azienda nuovo ossigeno dal quale possono sorgere nuove idee o nuovi
approcci a problemi presenti o futuri.

Figura 2.1: Relazioni ed intersezioni degli intenti delle parti coinvolte in uno stage (https:
            //link.medium.com/ifBGuxZf7X)

2.2          Presentazione del progetto
Méthode, attraverso lo strumento dello stage, mira sia ad identificare personale da
formare sia ad esplorare le novità e gli aggiornamenti di strumenti e tecnologie.
Il progetto di stage oggetto di questa relazione è di natura esplorativa, e si divide in
tre parti principali:
     • lo studio delle tecnologie aziendali, dei database colonnari e della modellazione
       "classica" in SAP Hana nota come XSC (Extended Application Services Classic);
     • l’esplorazione delle novità, delle differenze e delle potenzialità della modellazione
       XSA (Extended Application Services Advanced) in SAP Hana;
     • il confronto tra le due modalità di modellazione.
Per mezzo di questo stage Méthode punta ad esplorare le novità introdotte nelle versioni
più recenti di SAP Hana Platform ed in particolare quelle derivanti dalla modellazione
XSA rispetto a quanto attualmente in uso.
La necessità di quest’esplorazione deriva dal fatto che SAP raccomanda ormai la piena
adozione delle nuove versioni ed indica chiaramente che la direzione da intraprendere
è XSA. Nonostante SAP abbia dichiarato la piena retro-compatibilità, ha intenzione
di dismettere il proprio Cloud a favore di quello Amazon, e destina i rilasci di nuove
feature solo alle nuove versioni dei suoi strumenti presenti appunto su AWS e nella
versione on-premise.2

     2 SAP   Notes: Deprecation of XSC. url: https://launchpad.support.sap.com/#/notes/2465027.
2.2. PRESENTAZIONE DEL PROGETTO                                                         11

Figura 2.2: L’avviso degli strumenti SAP che invita a passare ai nuovi strumenti (https:
            //launchpad.support.sap.com/#/notes/2609527)

L’azienda è internamente suddivisa in team per aree di competenza, per poter svolgere al
meglio l’esplorazione richiesta sono stato inserito nel team Data Modeling & Integration
SAP il cui Team Leader è anche il tutor aziendale.
Il capitolo 3 costituisce il resoconto della mia attività di stage ed approfondisce la
terminologia con cui ci si riferisce a tecnologie e strumenti.

2.2.1     Database colonnari e modellazione classica
La prima parte dello stage è dedicata all’inserimento nel contesto aziendale, alla co-
noscenza reciproca e allo studio degli strumenti e dell’ambito applicativo del team di
riferimento.
Al consolidamento delle conoscenze del linguaggio SQL, segue un approfondimento
teorico sui database colonnari, in particolare nella loro variante in-memory di cui
l’esempio pratico è costituito dal database di SAP Hana Platform.
Questa parte termina con l’acquisizione per via teorica e pratica delle nozioni di model-
lazione dei dati nella vecchia modalità in uso in SAP Hana Platform originariamente
nota come Extended Application Services (XS) poi rinominata Extended Application
Services Classic (XSC) per distinguerla dal nuovo approccio.3

2.2.2     Extended Application Services Advanced (XSA)
Dopo aver acquisito i concetti e sperimentato con esercizi la modellazione in XSC,
la seconda parte è dedicata allo studio e all’esplorazione della nuova modalità di
modellazione che prende il nome di Extended Application Services Advanced (XSA).4
L’azienda richiede che ne vengano analizzate le differenze, le novità in termini di feature
ed eventuali problematiche ad essa collegate. Inoltre dovranno essere indagati anche i
nuovi strumenti e le nuove modalità operative con le quali è possibile l’utilizzo di XSA.
SAP rilascia le funzionalità di XSA sia nelle sue installazioni on-premise sia nelle più
recenti installazioni su Amazon Cloud Platform (AWS).
   3 SAP Glossary: XSC. url: https://help.sap.com/doc/abapdocu_752_index_htm/7.52/en-

US/abenxsc_glosry.htm.
   4 SAP Glossary: XSA. url: https://help.sap.com/doc/abapdocu_752_index_htm/7.52/en-

US/abenxsa_glosry.htm.
12                                                          CAPITOLO 2. LO STAGE

Figura 2.3: L’analogia Pizza as a Service che illustra le differenze tra On-Premise e Cloud
            (IaaS, PaaS e SaaS) (https://www.ebcgroup.co.uk/on-premises-vs-cloud#
            cloud-computing-as-a-pizza)

2.2.3      Confronto tra XSC e XSA
Lo scopo dell’ultima parte dello stage è un confronto tra le due modalità di modellazione
dati in Hana: quella "Classica" e quella "Advanced". Tale confronto ha il fine di capire
se le novità di XSA abbiano un valore aggiunto spendibile nel contesto aziendale, e se
la tecnologia e gli strumenti siano sufficientemente stabili ed affidabili.
A tal fine quest’analisi comparativa dovrà focalizzarsi principalmente su:
     • Feature
       Le funzionalità che cambiano o vengono meno rispetto alla modellazione classica,
       e quelle che invece si aggiungono con il nuovo approccio.
     • Vincoli
       L’individuazione di particolari vincoli derivanti da una delle due tipologie di
       modellazione.
     • Performance
       Sia degli strumenti sia di quanto ottenuto con i due diversi approcci di modella-
       zione.
Al termine l’azienda deciderà se provare sul campo alcune delle novità di XSA,
possibilmente in un contesto di dati reali.

2.3      Aspettative aziendali
L’azienda al termine del periodo di stage si aspetta che sia stata definita una panoramica
più ampia possibile riguardo le funzionalità aggiuntive della modellazione XSA ed in
particolare sugli strumenti che la rendono disponibile. È necessaria dunque una buona
comprensione degli argomenti esposti durante i corsi di formazione e l’acquisizione di
conoscenze sufficienti a garantire un buon grado di autonomia nell’uso degli strumenti.
Perché la panoramica richiesta assuma rilevanza deve riguardare in primo luogo i
vantaggi che la modellazione XSA potrebbe portare nella produttività aziendale in
termini di soluzioni più manutenibili, facilità di realizzazione, aumento di possibili
2.4. VINCOLI                                                                                13

soluzioni alle richieste dei Clienti e possibili nuove offerte. Inoltre l’azienda è interessata
ai cambiamenti derivanti dalla nuova modellazione, sia nel caso di mancata retro-
compatibilità sia di cambi radicali dei metodi di sviluppo e di utilizzo degli strumenti.
Da tali aspettative è scaturito un confronto con il tutor sugli obiettivi, presenti nel
piano di lavoro, che il progetto doveva soddisfare. Gli obiettivi, di natura formativa e
di natura esplorativa, sono stati aggiornati, integrati e ripartiti secondo due tipologie:
obbligatori e desiderabili. Gli obiettivi aggiuntivi invece sono emersi in corso
d’opera dall’opportunità generata da una richiesta di un Cliente: come dettagliato in
sezione 3.7, abbiamo deciso di affrontarla approfondendo i flowgraph nella modellazione
XSA.

         Obiettivi obbligatori
         Confronto tra database colonnari e database relazionali tradizionali
         Analisi Hana Cloud Platform (HCP)
         Analisi dell’architettura di XSA
         Valutazione delle nuove integrazioni disponibili in XSA
         Valutazione di eventuali nuovi vincoli
         Analisi dei nuovi nodi delle Calculation View
         Test dei nuovi nodi delle Calculation View

         Obiettivi desiderabili
         Modellazione di dati reali in XSA
         Confronto delle performance tra XSC e XSA
         Test delle nuove integrazioni disponibili in XSA
         Valutazione della maturità degli strumenti per impiego commerciale

         Obiettivi aggiuntivi
         Analisi dei Flowgraph
         Test di Flowgraph
         Implementazione di Flowgraph con dati reali
                         Tabella 2.1: Obiettivi fissati dall’azienda

2.4      Vincoli
2.4.1     Vincoli metodologici
Di comune accordo con l’azienda abbiamo deciso che avrei svolto lo stage presso la
sede principale a San Vendemiano (TV) per favorire dialogo e confronto con il tutor e
l’interazione con le altre figure presenti utile a fugare eventuali dubbi.
La metodologia aziendale richiede inoltre che, su base giornaliera, ogni persona compili
un rapportino telegrafico per la rendicontazione dell’attività svolta mediante lo stru-
mento interno Web Office (descritto nella sezione 1.5.1). Oltre a ciò, in accordo con il
tutor, abbiamo stabilito di effettuare un resoconto orale più dettagliato che permettesse
14                                                            CAPITOLO 2. LO STAGE

un costante allineamento ed il tempestivo emergere di problematiche: per il periodo
iniziale il resoconto avrebbe avuto luogo al termine di ogni attività o al più con cadenza
giornaliera; ne avremo poi ridotto la frequenza sulla base delle singole attività. Nei
casi in cui uno scambio orale non fosse praticabile l’avremo sostituito con email.

2.4.2      Vincoli tecnologici
Avrei svolto tutte le attività con il computer portatile ad uso personale fornito. Qualora
le attività avessero necessitato dell’utilizzo di servizi o strumenti non residenti sul
computer in dotazione avrei usufruito delle macchine remote di sede o di quanto indicato
dal team di supporto interno.
Nel rispetto delle politiche aziendali, non è permesso in nessun caso il trasporto di
dati all’esterno dell’ambiente in cui si trovano se non previa autorizzazione; l’unica
eccezione è costituita dai dati previsti per meri scopi di esercizio.
Avrei dovuto osservare il vincolo costituito dalla necessità di svolgere le esplorazioni
su strumenti e servizi previsti o comunque di cui l’azienda abbia licenza, prestando
particolare attenzione durante l’analisi al venir meno della compatibilità con quanto
già in uso; in tali casi avrei annotato e riferito l’incompatibilità per successivi eventuali
approfondimenti.

2.4.3      Vincoli temporali
Lo stage curricolare prevede una durata compresa fra le 300 e le 320 ore complessive,
abbiamo ripartito uniformemente queste ore in 8 settimane lavorative da 40 ore l’una
per un totale di 320 ore che avrei svolto nel corso di due mesi in osservanza dell’orario
lavorativo aziendale: dal Lunedì al Venerdì, dalle 09:00 alle 18:00 con un’ora di pausa
pranzo e flessibilità oraria d’ingresso dalle 08:30 alle 09:15.
Nella proposta di stage, l’azienda ha indicato una ripartizione temporale su base
settimanale delle attività e i contenuti di massima previsti:
     • settimana 1 - introduzione, database relazionali e concetti di Data Warehouse;
     • settimana 2 - formazione e ricerca sui database colonnari;
     • settimana 3 e 4 - SAP Hana e logiche di modellazione virtuale;
     • settimana 5 - introduzione ad Hana Cloud Platform su Amazon Web Services;
     • settimana 6 e 7 - test di modellazione in XSA;
     • settimana 8 - confronto e test reale.
Nel corso dei primi giorni ne ho discusso con il tutor e sono emerse tre tematiche
principali:
     • Evitare esercizi fini a sé stessi
       Le attività di formazione prevedono degli esercizi per consolidare quanto visto
       e accertarne la comprensione; qualora l’argomento fosse stato compreso veloce-
       mente avremo evitato di investire tempo in esercizi sterili, sostituendoli, secondo
       necessità, con piccole attività per conto di Clienti.
     • Rivedere alcune allocazioni temporali
       È difficile stilare un piano preciso senza aver avuto modo di conoscere la persona
       e le sue capacità concrete; per migliore la comprensione degli argomenti più ostici
2.5. ASPETTATIVE PERSONALI                                                              15

      ed evitare ripetizioni infruttuose avremo modificato la durata prevista per le
      attività secondo necessità. In particolare parte del tempo pianificato per SQL
      sarà re-investito in Oracle SQL inizialmente non previsto.
   • Possibilità di adattare il percorso d’esplorazione
     Alcuni degli strumenti necessari all’esplorazione richiesta sono articolati e recenti,
     saremmo quindi potuti incorrere in problemi bloccanti con lunghi tempi di
     risoluzione. Nel momento in cui uno strumento si fosse rivelato temporaneamente
     inadatto o non funzionante, avremo vagliato soluzioni alternative che consentissero
     comunque ai temi principali di procedere.
In seguito a queste considerazioni abbiamo deciso di mantenere il piano di lavoro quanto
più flessibile possibile rimanendo comunque all’interno degli obiettivi di massima dello
stage. Ho poi rappresentato le attività nel seguente Diagramma di Ganttg ; le modifiche,
ove necessarie, sono affrontate nel capitolo 3.

                      Figura 2.4: Diagramma di Gantt dello stage

2.5     Aspettative personali
Questa è la mia prima esperienza lavorativa in un contesto aziendale in ambito infor-
matico e la considero un banco di prova per mettere in pratica quanto appreso negli
anni di studio universitario.
Nel corso degli studi l’applicazione pratica dei concetti appresi è sempre avvenuta
per mezzo dei progetti didattici: nei primi anni ristretti per dimensioni e dominio
applicativo e culminati con il progetto di Ingegneria del Software dell’ultimo anno di
corso. Questi progetti sono stati esperienze formative e mi hanno permesso di fissare i
concetti studiati anche alla luce delle problematiche incontrate e risolte, ma restano
comunque inerentemente di natura accademica. Quest’esperienza è un’opportunità di
provare con mano quanto appreso, notare le differenze e i diversi approcci del mondo
accademico degli studenti rispetto a quello aziendale con i suoi vincoli di scadenze,
fatturazioni e Clienti. I progetti accademici mi hanno facilitato il fissare i concetti e
16                                                          CAPITOLO 2. LO STAGE

mi hanno insegnato a riconsiderare e trasformare le nozioni teoriche in qualcosa che si
traducesse poi in un prodotto; confido che l’esperienza lavorativa, con il suo approccio
più pratico, costituisca il proseguo di questa strada aggiungendo ulteriori sfide da
affrontare e potenzialmente nuovi ostacoli da superare.
In ultimo mi aspetto che il mondo lavorativo possa offrire nuovi stimoli e possibilità di
approfondimento e crescita diversi, per modi e temi, di quanto viene offerto dall’am-
biente accademico; in particolare che non sia solo una mera applicazione di quanto
studiato in aula o il consolidamento di nozioni teoriche pre-esistenti, ma che sia esso
stesso fonte di nuovi argomenti e scenari che valgano la pena essere approfonditi ed
appresi in un’ottica di crescita professionale.
Per garantirmi una possibilità di scelta più ampia possibile, ho partecipato all’evento
Stage-IT organizzato da Università degli Studi di Padova. Tale evento consente un
incontro agevolato tra studenti ed aziende; alcune di queste operano in settori che non
rientrano nei miei interessi più sinceri, altre invece hanno attirato la mia attenzione e
con alcune di esse ho svolto un breve colloquio conoscitivo.
Oltre alle aziende presenti all’evento, ne ho vagliate alcune altre suggeritemi da ex
colleghi di studi; ho poi aggiunto all’elenco un altro paio di aziende con sede nelle
vicinanze del mio luogo di residenza che hanno suscitato il mio interesse.
In conclusione ho optato per Méthode, azienda presente a Stage-IT ma con cui non
avevo avuto occasione di parlare, che ha colto la mia curiosità proponendo uno stage
esplorativo su tecnologie e strumenti tipicamente destinati al mondo business e con cui
difficilmente si entra in contatto in ambiente accademico.
Tra le molte aspettative su questo stage, alcune delle principali erano sicuramente:
     • entrare in contatto con il mondo del lavoro misurandomi con una realtà aziendale;

     • esplorare il mondo della Business Intelligence, ambito a me fondamentalmente
       sconosciuto;
     • interagire con personale qualificato, per scambiare opinioni e per poter ricevere
       consiglio in caso di difficoltà;
     • studiare e valutare un nuovo approccio ad un’attività già consolidata;

     • provare ed applicare sul campo alcune delle nozioni apprese nel corso degli studi;
     • espandere le mie conoscenze su argomenti che esulano dall’ambiente accademico;
     • individuare possibili ambiti d’interesse per la mia crescita professionale;

     • instaurare un rapporto umano e lavorativo con persone che da tempo svolgono
       questo mestiere.
Capitolo 3

Resoconto dello stage

3.1     Pianificazione del lavoro
All’inizio del periodo di stage ho discusso il piano di lavoro proposto con il tutor azien-
dale individuando le attività principali. L’esito di questa discussione è dettagliato nel
capitolo 2: in particolare nella sezione 2.4.3 per quanto riguarda le criticità riscontrate
e in figura 2.4 per lo svolgimento previsto delle attività.
Come accennato in sezione 2.4.1, al termine di ogni attività ho effettuato un resoconto
orale (o telematico) che è stato di volta in volta spunto di partenza per le attività
successive ed occasione per evidenziare eventuali problematiche incontrate.
Nelle sezioni seguenti vengono affrontati caso per caso gli strumenti che ho utilizzato e
analizzato. Alcune delle attività secondarie svolte sono il frutto di opportunità scaturite
dall’esigenza di Clienti e mi hanno permesso di conferire un valore aggiunto alla pura
sperimentazione.
Al termine dello stage avrei stilato una guida pratica alla nuova metodologia indivi-
duata, evidenziando le differenze con la precedente. Inoltre avrei tenuto una breve
presentazione al tutor su quanto emerso dalla mia analisi.

3.2     Database colonnari
Come parte della formazione ho svolto un approfondimento su funzionamento e di-
sponibilità sul mercato dei database colonnari presentati brevemente nelle sezioni
seguenti.

3.2.1     I database colonnari
Le tabelle di un DBMS relazionale costituiscono un’astrazione dei dati salvati in
memoria e l’operazione più costosa in termini di performance è il loro recupero; pertanto
i diversi approcci si concentrano sull’ottimizzare la memorizzazione per migliorare le
prestazioni negli scenari d’interesse.
Nei database colonnari o column-oriented le tabelle dei dati vengono memorizzate
per colonne anziché per righe come invece accade nei database "tradizionali" o row-
oriented. All’uso pratico i DBMS relazionali di una o dell’altra tipologia consentono le
stesse funzionalità tramite linguaggi di tipo SQL, le differenze emergono analizzando

                                            17
18                                     CAPITOLO 3. RESOCONTO DELLO STAGE

le operazioni tipiche eseguite sui dati memorizzati rendendo un approccio migliore
dell’altro in determinati contesti.

Database row-oriented
Nei DBMS row-oriented i dati sono immagazzinati in modo sequenziale riga per riga a
cui il sistema assegna un identificativo, ne risultano pertanto una sequenza di valori
contigui di tipo eterogeneo definito dal column type di ogni colonna.
Un sistema di questo tipo è efficiente nel recupero di tutti i dati di una riga (o record )
impiegando poche operazioni da e verso la memoria; tuttavia non risulta ottimizzato
nelle interrogazioni che riguardino la totalità della tabella come il recupero di tutte le
righe che rispettino una certa condizione.
Per mitigare quest’effetto si usano gli indici, che aiutano in questo tipo di operazioni
aggiungendo però un costo per il mantenimento dell’indice stesso.
Ad esempio, volendo popolare una pagina dei dettagli personali, un DBMS row-oriented
risulta efficiente nel recuperare tutte le informazioni di un dato Cliente da una tabella
anagrafica.

Figura 3.1: Differenza tra la memorizzazione row-oriented e column-oriented (https:
            //help.sap.com/doc/fb8f7a9f7860468b84a07eab0a7d0a98/2.0.01/en-
            US/SAP_HANA_Modeling_Guide_for_SAP_HANA_Studio_en.pdf (pag. 9))

Database column-oriented
Nei DBMS column-oriented invece i dati vengono salvati sequenzialmente per colonne,
similmente a quanto avviene per gli indici tradizionali.
Al contrario dei row-oriented, essendo i dati memorizzati consecutivamente, sono
ottimizzate interrogazioni che si riferiscono all’interezza di una o più colonne piuttosto
che a tutte le colonne di una (o poche) righe. Scenari di questo tipo sono comuni nei
casi concreti in cui i dati sono sparsi e molte colonne sono opzionali.
Ad esempio, volendo ottenere una rubrica per un centralino, risulta efficiente recuperare
da una tabella anagrafica l’elenco di nomi e numeri di telefono di tutti i Clienti.
La memorizzazione dei dati per colonne consente di avere situazioni in cui sono contigui:

     • i dati dello stesso tipo (column type);

     • i valori di colonne con insiemi ristretti (come il genere maschio/femmina);

     • i valori nulli in presenza di dati sparsi o campi opzionali.
3.2. DATABASE COLONNARI                                                                     19

Tutto ciò consente l’impiego più efficace1 di tecniche di compressione quali LZW2 o
RLE3 che traggono vantaggio da quest’uniformità.
Sempre allo scopo di migliorare i tempi di particolari interrogazioni, i database orientati
alle colonne raramente presentano una struttura normalizzata evitando così frequenti
operazioni di join, di contro però le modifiche sono più onerose dovendo evitare le
anomalie.4

3.2.2     Confronto con i database row-oriented
I database che lavorano per righe sono più diffusi nei sistemi con esigenze di tipo OLTPg
in cui sono frequenti le richieste di uno o pochi record interi (come le pagine di dettaglio
di un prodotto in un e-commerce) o in cui sono frequenti le operazioni localizzate di
scrittura o aggiornamento (ad esempio nei sistemi di transazioni bancarie).
I database che lavorano per colonne sono invece più diffusi nei sistemi con necessità
di tipo OLAPg che tipicamente compiono interrogazioni complesse distribuite su una
grande quantità di dati a scopi analitici (scopo principale dei data warehouse).
La seguente tabella confronta i principali punti di forza e le principali debolezze dei
due approcci.

                     Operazione                        Column-store         Row-store

      recupero di tutti i dati di un solo record            peggiore          migliore
     recupero di tutti i dati di una sola colonna           migliore          peggiore
     comportamento in presenza di dati sparsi               migliore          peggiore
                      aggregazioni                          migliore          peggiore
      inserimenti e aggiornamenti di un record              peggiore          migliore
            migliore con operazioni di tipo                 OLAP               OLTP
                     compressione                             1:10               1:3
Tabella 3.1: Vantaggi e svantaggi dei database orientati alle colonne e alle righe
             (http://www.timestored.com/time-series-data/what-is-a-column-
             oriented-database)

3.2.3     Database colonnari disponibili sul mercato
Anche se in misura minore rispetto ai row-oriented, il mercato offre diverse alternative
riguardo i database (o piattaforme che contengano un database) che possano operare
per colonne. Segue una breve descrizione di tre tra quelli su cui ho svolto delle ricerche
per confrontarli ad alto livello con il database colonnare di SAP Hana Platform.

MonetDB
Sviluppato presso il CWI (Centrum Wiskunde & Informatica, istituto nazionale di
   1 VLDB 2009: Column-Oriented Database Systems. url: http://www.cs.yale.edu/homes/dna/

talks/Column_Store_Tutorial_VLDB09.pdf.
   2 IEEE: Lempel–Ziv–Welch (LZW). url: https://ieeexplore.ieee.org/document/1659158.
   3 IEEE: Run-length encoding (RLE). url: https://ieeexplore.ieee.org/document/1447423.
   4 WhatIsDBMS: Normalization. url: https : / / whatisdbms . com / normalization - in - dbms -

anomalies-advantages-disadvantages.
20                                       CAPITOLO 3. RESOCONTO DELLO STAGE

ricerca olandese per la matematica e l’informatica), è open-sourceg e orientato alle
colonne5 , supporta SQL e fornisce compressione dei dati.6

Vertica Analytics Platform
Proprietario e sviluppato da Vertica System; ha un DBMS column-oriented e dichiara
la possibilità di ottenere forti compressioni dei dati su cui è possibile eseguire operazioni
senza decompressione.
Supporta pienamente le interrogazioni SQL e si appoggia su un’architettura MPP
(Massive Parallel Processing) che gli permette di distribuire le interrogazioni su nodi
indipendenti.7

Oracle Database
Sviluppato da Oracle, oltre all’approccio per righe supporta anche quello per colonne8 ;
se espressamente impostato lavora in modo misto: lettura e analisi dalla memorizzazione
per colonne e modifiche salvate per righe in una buffer cache. Dalla versione 12C è
possibile usare la modalità in-memory 9 (approfondita nella sezione 3.3), questo lo
rende uno dei principali rivali di SAP Hana10 .

SAP Hana
Proprietario e sviluppato da SAP SE, è integrato in SAP Hana Platform approfondita
in sezione 3.3.
Fortemente orientato alle colonne offre compressione di tipo dizionario e lavora inte-
ramente in-memory; tuttavia fornisce un buon supporto anche alle operazioni OLTP
tipiche dei DBMS orientati alle righe.
Oltre ad appartenere all’ecosistema di strumenti SAP con cui ha una buona integrazio-
ne, uno dei suoi punti di forza è l’offerta di oggetti e strumenti per la modellazione
virtuale.11 (Si veda anche la sezione 3.5).

Confronto prestazionale
Dopo una ricerca informativa, ho provato ad approfondire l’ambito delle prestazioni:
specificatamente ho cercato confronti che mostrassero se vi sono importanti differenze
tra le diverse soluzioni. Tuttavia non ho trovato dei veri e propri dati prestazionali
comparativi, svolti ad esempio su macchine fisiche equivalenti, con tabelle di partenza
uguali e una serie di interrogazioni predefinite. SAP rilasciava dei benchmark compara-
tivi di questo tipo fino a qualche anno fa, ma non sono più disponibili e non ne svolge
di nuovi.12

     5 MonetDB: Column-store. url: https://www.monetdb.org/content/column-store-features.
     6 MonetDB Solutions: MonetDB. url: https://monetdbsolutions.com/solutions/monetdb.
   7 Vertica System: Vertica Analytics Platform. url: https://www.vertica.com/overview/.
   8 Oracle Doc: Column-store. url: https://docs.oracle.com/en/database/oracle/oracle-

database/12.2/inmem/in-memory-column-store-architecture.html.
   9 Dell Knowledge Base: Oracle in-memory options. url: https : / / www . dell . com / support /

article/us/en/04/sln310834/how-do-i-configure-oracle-database-12c-in-memory-option.
  10 Oracle: Oracle DB vs SAP Hana. url: https://www.oracle.com/assets/dbim-vs-sap-hana-

2215625.pdf.
  11 SAP Blog: Hana virtual data model. url: https://blogs.sap.com/2019/03/27/back- to-

basics-sap-hana-and-the-virtual-data-model.
  12 Forbes: Oracle vs SAP. url: https://www.forbes.com/sites/oracle/2015/12/18/oracle-

challenges-sap-on-in-memory-database-claims.
3.3. SAP HANA PLATFORM                                                                21

3.3     SAP Hana Platform
SAP Hana Platform (dove HANA sta per High-Performance ANalytic Appliance) non
è costituita solo da un database, è piuttosto una vera e propria piattaforma con al suo
interno un database e che SAP continua ad espandere perché possa coprire sempre
più l’intero stack di sviluppo. Di tutta la piattaforma, la maggior parte dei miei
approfondimenti è focalizzata su ciò che riguarda la modellazione dei dati.

                           Figura 3.2: SAP Hana Platform

Il blocco JavaScript, SQLScript, SQL di figura 3.2 riceve le richieste d’interroga-
zione, le interpreta, le ottimizza e le assegna al componente adatto: in questo caso a
Stored Procedure & Data Models che fondamentalmente è quanto rappresentato
in figura 3.3. Il suo compito è dunque quello di identificare la tipologia e assegnare la
richiesta al giusto engine tra: OLAP Engine, Calculation View Engine e Join
Engine.

                     Figura 3.3: SAP Hana Platform SQL Engine
22                                     CAPITOLO 3. RESOCONTO DELLO STAGE

Si può notare che in figura 3.3 compaiono sia un Column Engine sia un Row Engine,
questo perché ogni installazione è composta da due database engine in-memory per la
gestione delle tabelle in colonna e in riga. Entrambi lavorano in modalità in-memory:
l’intero database è quindi caricato in memoria RAM ed il disco rigido viene usato solo
per la persistenza e mai per le operazioni.
Nonostante questi accorgimenti, la conversione e la successiva compressione dei dati
da riga a colonna è onerosa; pertanto i nuovi dati inseriti (dati delta) vengono tempo-
raneamente immagazzinati in-memory in formato row per poi essere accorpati agli
altri in modalità colonnare in un secondo momento (delta merge). Così facendo si
ottengono buone prestazioni anche nelle operazioni di inserimento e modifica.

                  Figura 3.4: Le operazioni sui due database in-memory

Nel caso di richieste di lettura che coinvolgono i dati delta, avviene un’operazione di
UNION così da garantire il risultato sempre corretto ed aggiornato. SAP Hana si
delinea dunque in grado di gestire sia operazioni OLAP sia OLTP.
In caso di malfunzionamenti o arresti improvvisi la consistenza viene mantenuta grazie
a file di log che tengono traccia delle modifiche così da poterle ripetere.
La peculiarità di Hana è la possibilità di creare, al di sopra dei dati, una serie di viste
logiche, che non duplicano i dati e che permettono di interrogare le tabelle fisiche a
runtime (si veda anche la sezione 3.5). Costituisce di fatto un diverso approccio di
sviluppo, invita a delegare le operazioni intensive all’engine in-memory piuttosto che
eseguirle a livello di logica applicativa.
Puoi anche leggere
DIAPOSITIVE SUCCESSIVE ... Annulla