Processore OLAP

Repository di metadati,

Process designer e altre funzioni.

Business Explorer BEx è uno strumento di reporting e analisi che supporta le funzioni di query, analisi e reporting in BI. Utilizzando BEx, è possibile analizzare i dati storici e attuali con diversi gradi di analisi.

• Sistemi SAP (applicazioni SAP / SAP ECC)
• Database relazionale (Oracle, SQL Server, ecc.)
• File flat (Excel, Blocco note)
• Sistemi di origine multidimensionale (universo che utilizza il connettore UDI)
• Servizi Web che trasferiscono i dati alla BI tramite push

In BW 3.5, è possibile caricare i dati nell'Area di gestione temporanea della persistenza e anche nelle destinazioni dal sistema di origine, ma se si utilizza SAP BI 7.0, il caricamento dei dati dovrebbe essere limitato a PSA solo per le versioni più recenti.

Un InfoPackage viene utilizzato per specificare come e quando caricare i dati nel sistema BI da diverse origini dati. Un InfoPackage contiene tutte le informazioni su come i dati vengono caricati dal sistema di origine a un'origine dati o PSA. InfoPackage consiste in una condizione per la richiesta di dati da un sistema di origine.

Si noti che utilizzando un InfoPackage in BW 3.5, è possibile caricare i dati in Persistence Staging Area e anche nelle destinazioni dal sistema di origine, ma se si utilizza SAP BI 7.0 il caricamento dei dati dovrebbe essere limitato a PSA solo per le versioni più recenti.

Nello schema Extended Star, le tabelle dei fatti sono collegate alle tabelle delle dimensioni e la tabella delle dimensioni è collegata alla tabella SID e la tabella SID è collegata alle tabelle dei dati principali. Nello schema a stella esteso le tabelle Fact e Dimension sono all'interno del cubo, tuttavia le tabelle SID sono esterne al cubo. Quando carichi i dati transazionali nel cubo Info, i Dim Id vengono generati in base ai SID e questi Dim id vengono utilizzati nelle tabelle dei fatti.

Nello schema Extended Star una tabella dei fatti può connettersi a 16 tabelle delle dimensioni e a ciascuna tabella delle dimensioni è assegnato un massimo di 248 tabelle SID. Le tabelle SID sono anche chiamate Caratteristiche e ogni caratteristica può avere tabelle di dati master come ATTR, Testo, ecc.

In Star Schema, ogni dimensione è unita a una singola tabella dei fatti. Ogni dimensione è rappresentata da una sola dimensione e non è ulteriormente normalizzata.

La tabella delle dimensioni contiene una serie di attributi utilizzati per analizzare i dati.

Gli Info Object sono noti come unità più piccole in SAP BI e vengono utilizzati in Info Provider, DSO, Multi provider, ecc. Ciascun Info Provider contiene più Info Object.

Gli InfoObject vengono utilizzati nei report per analizzare i dati memorizzati e per fornire informazioni ai responsabili delle decisioni.

Gli oggetti info possono essere classificati nelle seguenti categorie:

• Caratteristiche come cliente, prodotto, ecc.
• Unità come quantità venduta, valuta, ecc.
• Cifre chiave come entrate totali, profitti, ecc.
• Caratteristiche temporali come anno, trimestre, ecc.

L'Area informazioni in SAP BI viene utilizzata per raggruppare tipi di oggetti simili. L'Area informazioni viene utilizzata per gestire gli Info Cubes e gli Info Object. Ogni Info Object risiede in un'Area informazioni e puoi definirla una cartella che viene utilizzata per tenere insieme file simili.

Per accedere direttamente ai dati nel sistema di origine BI. È possibile accedere direttamente ai dati del sistema di origine in BI senza estrazione utilizzando i provider virtuali. I provider virtuali possono essere definiti come InfoProvider in cui i dati transazionali non sono archiviati nell'oggetto. I provider virtuali consentono solo l'accesso in lettura ai dati BI.

VirtualProvider basati su DTP

VirtualProvider con moduli funzionali

VirtualProvider basati su BAPI

VirtualProviders based on DTP -

Questo tipo di provider virtuali si basa sull'origine dati o su un provider di informazioni e assume caratteristiche e figure chiave della fonte. Gli stessi estrattori vengono utilizzati per selezionare i dati nel sistema di origine utilizzati per replicare i dati nel sistema BI.

Quando ai provider virtuali basati su DTP?

Quando viene utilizzata solo una certa quantità di dati.

È necessario accedere ai dati aggiornati da un sistema di origine SAP.

Solo pochi utenti eseguono query contemporaneamente sul database.

Virtual Provider with Function Module -

Questo provider virtuale viene utilizzato per visualizzare i dati da un'origine dati non BI a BI senza copiare i dati nella struttura BI. I dati possono essere locali o remoti. Viene utilizzato principalmente per l'applicazione SEM.

Il processo di trasformazione viene utilizzato per eseguire il consolidamento, la pulizia e l'integrazione dei dati. Quando i dati vengono caricati da un oggetto BI a un altro oggetto BI, la trasformazione viene applicata ai dati. La trasformazione viene utilizzata per convertire un campo di origine nel formato dell'oggetto di destinazione.

Regole di trasformazione -

Le regole di trasformazione vengono utilizzate per mappare campi di origine e campi di destinazione. È possibile utilizzare diversi tipi di regole per la trasformazione.

L'acquisizione dei dati in tempo reale si basa sullo spostamento dei dati in Business Warehouse in tempo reale. I dati vengono inviati alla coda delta o alla tabella PSA in tempo reale.

L'acquisizione dei dati in tempo reale può essere ottenuta in due scenari:

Utilizzando InfoPackage per l'acquisizione dei dati in tempo reale tramite Service API.

Utilizzo del servizio Web per caricare i dati in Persistent Storage Area PSA e quindi utilizzando DTP in tempo reale per spostare i dati in DSO.

Processo in background per l'acquisizione dei dati in tempo reale -

Per elaborare i dati in InfoPackage e il trasferimento dei dati elaborare DTP a intervalli regolari, è possibile utilizzare un processo in background noto come Daemon.

Il processo Daemon ottiene tutte le informazioni da InfoPackage e DTP su quali dati devono essere trasferiti e quali oggetti PSA e Data Sore devono essere caricati con i dati.

Gli InfoObject vengono creati nel catalogo degli oggetti Info. È possibile che un Oggetto Info possa essere assegnato a un Catalogo Info diverso.

Un DSO è noto come luogo di archiviazione per mantenere i dati di transazione o master puliti e consolidati al livello di granularità più basso e questi dati possono essere analizzati utilizzando la query BEx.

Un oggetto DataStore contiene cifre chiave e campi di caratteri e i dati di DSO possono essere aggiornati utilizzando l'aggiornamento Delta o altri oggetti DataStore o dati master. Gli oggetti DataStore vengono comunemente archiviati in tabelle di database trasparenti bidimensionali.

DSO component consists of three tables -

Coda di attivazione -

Viene utilizzato per memorizzare i dati prima che venga attivato. La chiave contiene l'ID della richiesta, l'ID del pacchetto e il numero di registrazione. Una volta completata l'attivazione, la richiesta viene eliminata dalla coda di attivazione.

Tabella dati attivi -

Questa tabella viene utilizzata per memorizzare i dati attivi correnti e questa tabella contiene la chiave semantica definita per la modellazione dei dati.

Registro modifiche -

Quando si attiva l'oggetto, le modifiche ai dati attivi vengono memorizzate nel registro delle modifiche. Il registro delle modifiche è una tabella PSA e viene gestito in Administration Workbench nella struttura PSA.

L'oggetto DataStore per l'aggiornamento diretto consente di accedere ai dati per la creazione di report e l'analisi immediatamente dopo il caricamento. È diverso dai DSO standard nel modo in cui ha elaborato i dati. I dati vengono archiviati nello stesso formato in cui sono stati caricati nell'oggetto DataStore per l'aggiornamento diretto dall'applicazione.

una tabella per i dati attivi e nessuna area del registro delle modifiche esiste. I dati vengono recuperati da sistemi esterni utilizzando le API.

Below API’s exists -

• RSDRI_ODSO_INSERT: vengono utilizzati per inserire nuovi dati.

• RSDRI_ODSO_INSERT_RFC: simile a RSDRI_ODSO_INSERT e può essere richiamato da remoto.

• RSDRI_ODSO_MODIFY: serve per inserire dati con nuove chiavi, per dati con chiavi già nel sistema, i dati vengono modificati.

• RSDRI_ODSO_MODIFY_RFC: simile a RSDRI_ODSO_MODIFY e può essere richiamato da remoto.

• RSDRI_ODSO_UPDATE: questa API viene utilizzata per aggiornare i dati esistenti.

• RSDRI_ODSO_UPDATE_RFC: è simile a RSDRI_ODSO_UPDATE e può essere richiamato da remoto.

• RSDRI_ODSO_DELETE_RFC: questa API viene utilizzata per eliminare i dati.

Poiché la struttura di questo DSO contiene una tabella per i dati attivi e nessun registro delle modifiche, ciò non consente l'aggiornamento delta a InfoProvider.

In Write Optimized DSO, i dati caricati sono immediatamente disponibili per l'ulteriore elaborazione.

DSO ottimizzato per la scrittura fornisce un'area di archiviazione temporanea per grandi set di dati se si stanno eseguendo trasformazioni complesse per questi dati prima che vengano scritti nell'oggetto DataStore. I dati possono quindi essere aggiornati a ulteriori InfoProvider. Devi solo creare le trasformazioni complesse una volta per tutti i dati.

Gli oggetti DataStore ottimizzati per la scrittura vengono utilizzati come livello EDW per il salvataggio dei dati. Le regole di business vengono applicate solo quando i dati vengono aggiornati a InfoProvider aggiuntivi.

Contiene solo una tabella di dati attivi e non è necessario attivare i dati come richiesto con DSO standard. Ciò consente di elaborare i dati più rapidamente.

Gli infoset sono definiti come un tipo speciale di InfoProvider in cui le origini dati contengono la regola Join su oggetti DataStore, InfoCubi standard o InfoObject con caratteristiche dei dati master. Gli InfoSet vengono utilizzati per unire i dati e tali dati vengono utilizzati nel sistema BI.

Join temporali: vengono utilizzati per mappare un periodo di tempo. Al momento della segnalazione, altri InfoProvider gestiscono i dati anagrafici dipendenti dal tempo in modo tale che ogni volta venga utilizzato il record valido per una data chiave univoca predefinita. È possibile definire un join temporale che contenga almeno una caratteristica dipendente dal tempo o uno pseudo InfoProvider dipendente dal tempo.

Gli infoset vengono utilizzati per analizzare i dati in più InfoProvider combinando le caratteristiche dei dati master, gli oggetti DataStore e gli InfoCubi.

È possibile utilizzare l'unione temporale con InfoSet per specificare un particolare momento in cui si desidera valutare i dati.

È possibile utilizzare i rapporti utilizzando Business Explorer BEx sui DSO senza abilitare l'indicatore BEx.

• Inner Join
• Join esterno sinistro
• Join temporale
• Self Join

InfoCube è definito come set di dati multidimensionale utilizzato per l'analisi in una query BEx. Un InfoCubo è costituito da un insieme di tabelle relazionali che sono unite logicamente per implementare lo schema a stella. Una tabella dei fatti nello schema a stella è unita a più tabelle delle dimensioni.

È possibile aggiungere dati da uno o più InfoSource o InfoProvider a un InfoCube. Sono disponibili come InfoProvider per scopi di analisi e reportistica.

Un InfoCubo viene utilizzato per memorizzare i dati fisicamente. È costituito da una serie di InfoObject riempiti con i dati della gestione temporanea. Ha la struttura di uno schema a stella.

In SAP BI, un Infocube contiene lo schema a stella esteso come mostrato sopra.

Un InfoCubo è costituito da una tabella dei fatti che è circondata da 16 tabelle delle dimensioni e dati principali che si trovano all'esterno del cubo.

Gli InfoCubi in tempo reale vengono utilizzati per supportare l'accesso in scrittura parallela. Gli InfoCubi in tempo reale vengono utilizzati in connessione con l'immissione dei dati di pianificazione.

È possibile inserire i dati negli InfoCubi in tempo reale in due modi diversi:

Transazione per l'immissione dei dati di pianificazione

Staging BI

È possibile creare un InfoCubo in tempo reale utilizzando la casella di controllo Indicatore in tempo reale.

Sì, quando desideri creare rapporti su caratteristiche o dati principali, puoi impostarli come InfoProvider.

Per convertire un InfoCubo standard in un InfoCubo in tempo reale, sono disponibili due opzioni:

Conversione con perdita di dati transazionali

Conversione con conservazione dei dati di transazione

Sì, fare doppio clic sul pacchetto informativo grp → pulsante Manutenzione catena di processo e digitare il nome e la descrizione.

• Gerarchia H
• F valore fisso
• Blank

Sì.

MultiProvider

ODS -

Forniscono dati granulari, consentono la sovrascrittura e i dati sono in tabelle trasparenti, ideali per il drilldown e l'RRI.

InfoCube -

Viene utilizzato per lo schema a stella, possiamo solo aggiungere dati, ideale per i rapporti primari.

MultiProvider -

Contiene dati fisici e consente di accedere ai dati di diversi InfoProvider.

Start Routines -

La routine di avvio viene eseguita per ciascun pacchetto dati dopo che i dati sono stati scritti nel PSA e prima che le regole di trasferimento siano state eseguite. Consente calcoli complessi per una figura chiave o una caratteristica. Non ha valore di ritorno. Il suo scopo è eseguire calcoli preliminari e memorizzarli in strutture dati globali. È possibile accedere a questa struttura o tabella nelle altre routine. L'intero pacchetto dati nel formato della struttura di trasferimento viene utilizzato come parametro per la routine.

Update Routines -

Sono definiti a livello di InfoObject. È come la routine di avvio. È indipendente da DataSource. Possiamo usarlo per definire dati globali e controlli globali.

Viene utilizzato per caricare il nuovo pacchetto dati negli aggregati di InfoCube. Se non abbiamo eseguito un rollup, i nuovi dati dell'InfoCubo non saranno disponibili durante i rapporti sull'aggregato.

Durante il caricamento, eseguire i passaggi nell'ordine seguente:

Caricare prima i dati anagrafici nel seguente ordine: primi attributi, quindi testi, quindi gerarchie.

Caricare prima i dati anagrafici e poi i dati della transazione. In questo modo, ci si assicura che i SID vengano creati prima del caricamento dei dati della transazione e non durante il caricamento dei dati della transazione.

Per ottimizzare le prestazioni durante il caricamento e l'eliminazione dei dati dall'InfoCube -

• Indexes
• Aggregates
• Elemento pubblicitario e cardinalità elevata
• Compression

Per ottenere buone prestazioni di attivazione per gli oggetti DataStore, è necessario tenere presente i seguenti punti:

Creazione di valori SID

La generazione dei valori SID richiede molto tempo e può essere evitata nei seguenti casi:

Non impostare il flag "Genera valori SID", se utilizzi solo l'oggetto DataStore come archivio dati. Se si imposta questo flag, vengono creati SID per tutti i nuovi valori caratteristici.

Se stai utilizzando elementi pubblicitari (numero di documento o timestamp, ad esempio) come caratteristiche nell'oggetto DataStore, imposta il flag in manutenzione caratteristiche per mostrare che sono "solo attributo".

È il metodo per dividere una tabella per l'ottimizzazione del report. SAP utilizza il partizionamento dei file dei fatti per migliorare le prestazioni. Possiamo partizionare solo a 0CALMONTH o 0FISCPER. Il partizionamento delle tabelle consente di eseguire il report più rapidamente poiché i dati vengono archiviati nelle partizioni pertinenti. Anche la manutenzione del tavolo diventa più facile.

Infocube è strutturato come schema a stella in cui una tabella dei fatti è circondata da diverse tabelle dim che sono collegate con DIM'id.

ODS è una struttura piatta senza un concetto di schema a stella e che avrà dati granulari (livello dettagliato). Funzionalità di sovrascrittura.

L'attributo di navigazione viene utilizzato per eseguire il drill down nel report.

Se i separatori vengono utilizzati in modo incoerente in un file CSV, il separatore errato viene letto come un carattere ed entrambi i campi vengono uniti in un campo e possono essere abbreviati. I campi successivi non sono più nell'ordine corretto.

Prima di poter trasferire dati da un file source system, i metadati devono essere disponibili in BI sotto forma di DataSource.

Sì.

Sotto forma di tabelle PSA

La connessione DB viene utilizzata per definire un'altra connessione al database oltre alla connessione predefinita e queste connessioni vengono utilizzate per trasferire i dati nel sistema BI da tabelle o viste.

Per connettere un database esterno, dovresti avere le seguenti informazioni:

• Tools
• Conoscenza dell'applicazione di origine
• Sintassi SQL nel database
• Funzioni di database

Dati universali UD connect consente di accedere a origini dati relazionali e multidimensionali e di trasferire i dati sotto forma di dati flat. I dati multidimensionali vengono convertiti in formato flat quando si utilizza Universal Data Connect per il trasferimento dei dati.

UD utilizza il connettore J2EE per consentire la creazione di report sui dati SAP e non SAP. Sono disponibili diversi connettori BI Java per vari driver, protocolli come adattatori di risorse -

• Connettore BI ODBO
• Connettore BI JDBC
• Connettore BI SAP Query
• Connettore XMLA