Processeur OLAP

Référentiel de métadonnées,

Concepteur de processus et autres fonctions.

Business Explorer BEx est un outil de reporting et d'analyse qui prend en charge les fonctions de requête, d'analyse et de reporting dans BI. En utilisant BEx, vous pouvez analyser les données historiques et actuelles à différents degrés d'analyse.

• Systèmes SAP (Applications SAP / SAP ECC)
• Base de données relationnelle (Oracle, SQL Server, etc.)
• Fichier plat (Excel, Bloc-notes)
• Systèmes source multidimensionnels (univers utilisant un connecteur UDI)
• Services Web qui transfèrent des données vers la BI par push

Dans BW 3.5, vous pouvez charger des données dans la zone de transit de persistance et également dans les cibles du système source, mais si vous utilisez SAP BI 7.0, le chargement des données doit être limité à PSA uniquement pour les dernières versions.

Un InfoPackage est utilisé pour spécifier comment et quand charger des données dans le système de BI à partir de différentes sources de données. Un InfoPackage contient toutes les informations sur la manière dont les données sont chargées du système source vers une source de données ou un PSA. InfoPackage consiste en une condition pour demander des données à partir d'un système source.

Notez qu'en utilisant un InfoPackage dans BW 3.5, vous pouvez charger des données dans Persistence Staging Area et également dans des cibles du système source, mais si vous utilisez SAP BI 7.0, le chargement de données doit être limité à PSA uniquement pour les dernières versions.

Dans le schéma Extended Star, les tables de faits sont connectées aux tables de dimension et la table de dimension est connectée à la table SID et la table SID est connectée aux tables de données de base. Dans le schéma en étoile étendu, vous avez des tables de faits et de dimensions à l'intérieur du cube, mais les tables SID sont à l'extérieur du cube. Lorsque vous chargez les données transactionnelles dans le cube Info, les ID Dim sont générés en fonction des SID et ces ID Dim sont utilisés dans les tables de faits.

Dans le schéma Extended Star, une table de faits peut se connecter à 16 tables de dimensions et chaque table de dimension est affectée à 248 tables SID maximum. Les tables SID sont également appelées caractéristiques et chaque caractéristique peut avoir des tables de données de base telles que ATTR, texte, etc.

Dans le schéma en étoile, chaque dimension est jointe à une seule table de faits. Chaque dimension est représentée par une seule dimension et n'est pas normalisée davantage.

La table de dimension contient un ensemble d'attributs utilisés pour analyser les données.

Les objets d'information sont connus comme la plus petite unité dans SAP BI et sont utilisés dans les fournisseurs d'informations, les DSO, les fournisseurs multiples, etc. Chaque fournisseur d'informations contient plusieurs objets d'informations.

Les InfoObjects sont utilisés dans les rapports pour analyser les données stockées et fournir des informations aux décideurs.

Les objets d'information peuvent être classés dans les catégories ci-dessous -

• Des caractéristiques telles que le client, le produit, etc.
• Des unités telles que la quantité vendue, la devise, etc.
• Chiffres clés tels que les revenus totaux, les bénéfices, etc.
• Les caractéristiques temporelles telles que l'année, le trimestre, etc.

La zone d'informations dans SAP BI est utilisée pour regrouper des types d'objet similaires. La zone d'informations permet de gérer les cubes d'informations et les objets d'informations. Chaque objet d'information réside dans une zone d'information et vous pouvez le définir comme un dossier qui est utilisé pour contenir des fichiers similaires ensemble.

Pour accéder directement aux données du système source BI. Vous pouvez accéder directement aux données du système source dans BI sans extraction à l'aide de fournisseurs virtuels. Les fournisseurs virtuels peuvent être définis comme des InfoProviders où les données transactionnelles ne sont pas stockées dans l'objet. Les fournisseurs virtuels autorisent uniquement l'accès en lecture aux données BI.

VirtualProviders basés sur DTP

VirtualProviders avec modules fonctionnels

VirtualProviders basés sur les BAPI

VirtualProviders based on DTP -

Ce type de fournisseurs virtuels sont basés sur la source de données ou un fournisseur d'informations et ils prennent les caractéristiques et les chiffres clés de la source. Les mêmes extracteurs sont utilisés pour sélectionner les données dans le système source que vous utilisez pour répliquer les données dans le système BI.

Quand aux fournisseurs virtuels basés sur DTP?

Lorsque seule une certaine quantité de données est utilisée.

Vous devez accéder à des données à jour à partir d'un système source SAP.

Seuls quelques utilisateurs exécutent des requêtes simultanément sur la base de données.

Virtual Provider with Function Module -

Ce fournisseur virtuel est utilisé pour afficher les données d'une source de données non BI vers BI sans copier les données dans la structure BI. Les données peuvent être locales ou distantes. Ceci est principalement utilisé pour l'application SEM.

Le processus de transformation est utilisé pour effectuer la consolidation, le nettoyage et l'intégration des données. Lorsque les données sont chargées d'un objet BI vers un autre objet BI, la transformation est appliquée aux données. La transformation est utilisée pour convertir un champ de source dans le format d'objet cible.

Règles de transformation -

Les règles de transformation sont utilisées pour mapper les champs source et les champs cible. Différents types de règles peuvent être utilisés pour la transformation.

L'acquisition de données en temps réel est basée sur le déplacement des données vers Business Warehouse en temps réel. Les données sont envoyées à la file d'attente delta ou à la table PSA en temps réel.

L'acquisition de données en temps réel peut être réalisée dans deux scénarios -

En utilisant InfoPackage pour l'acquisition de données en temps réel à l'aide de Service API.

Utilisation du service Web pour charger des données dans PSA de la zone de stockage persistante, puis en utilisant le DTP en temps réel pour déplacer les données vers DSO.

Processus d'arrière-plan d'acquisition de données en temps réel -

Pour traiter les données vers InfoPackage et le processus de transfert de données DTP à intervalles réguliers, vous pouvez utiliser un processus d'arrière-plan appelé Daemon.

Le processus démon obtient toutes les informations d'InfoPackage et de DTP sur les données à transférer et les objets PSA et Data à charger avec des données.

Les InfoObjects sont créés dans le catalogue d'objets Info. Il est possible qu'un objet d'information puisse être affecté à un catalogue d'informations différent.

Un DSO est connu comme un lieu de stockage pour conserver les données de transaction ou de base nettoyées et consolidées au niveau de granularité le plus bas et ces données peuvent être analysées à l'aide d'une requête BEx.

Un objet DataStore contient des ratios et des champs de caractères et les données de DSO peuvent être mises à jour à l'aide de Delta update ou d'autres objets DataStore ou données de base. Les objets DataStore sont généralement stockés dans des tables de base de données transparentes en deux dimensions.

DSO component consists of three tables -

File d'attente d'activation -

Ceci est utilisé pour stocker les données avant leur activation. La clé contient l'identifiant de la demande, l'identifiant du package et le numéro d'enregistrement. Une fois l'activation terminée, la demande est supprimée de la file d'attente d'activation.

Tableau de données actif -

Cette table est utilisée pour stocker les données actives actuelles et cette table contient la clé sémantique définie pour la modélisation des données.

Journal des modifications -

Lorsque vous activez l'objet, les modifications apportées aux données actives sont enregistrées dans le journal des modifications. Le journal des modifications est une table PSA et est conservé dans Administration Workbench sous l'arborescence PSA.

L'objet DataStore pour la mise à jour directe vous permet d'accéder aux données pour le reporting et l'analyse immédiatement après leur chargement. Il diffère des DSO standard dans la manière dont il traite les données. Les données sont stockées dans le même format dans lequel elles ont été chargées dans l'objet DataStore pour une mise à jour directe par l'application.

une table pour les données actives et aucune zone de journal des modifications n'existe. Les données sont récupérées à partir de systèmes externes à l'aide d'API.

Below API’s exists -

• RSDRI_ODSO_INSERT: Ils sont utilisés pour insérer de nouvelles données.

• RSDRI_ODSO_INSERT_RFC: similaire à RSDRI_ODSO_INSERT et peut être appelé à distance.

• RSDRI_ODSO_MODIFY: Ceci est utilisé pour insérer des données ayant de nouvelles clés. Pour les données avec des clés déjà dans le système, les données sont modifiées.

• RSDRI_ODSO_MODIFY_RFC: similaire à RSDRI_ODSO_MODIFY et peut être appelé à distance.

• RSDRI_ODSO_UPDATE: Cette API est utilisée pour mettre à jour les données existantes.

• RSDRI_ODSO_UPDATE_RFC: Ceci est similaire à RSDRI_ODSO_UPDATE et peut être appelé à distance.

• RSDRI_ODSO_DELETE_RFC: Cette API est utilisée pour supprimer les données.

Comme la structure de ce DSO contient une table pour les données actives et aucun journal des modifications, cela n'autorise pas la mise à jour delta des InfoProviders.

Dans DSO optimisé en écriture, les données chargées sont immédiatement disponibles pour un traitement ultérieur.

Le DSO optimisé en écriture fournit une zone de stockage temporaire pour de grands ensembles de données si vous exécutez des transformations complexes pour ces données avant qu'elles ne soient écrites dans l'objet DataStore. Les données peuvent ensuite être mises à jour vers d'autres InfoProviders. Vous ne devez créer les transformations complexes qu'une seule fois pour toutes les données.

Les objets DataStore optimisés en écriture sont utilisés comme couche EDW pour enregistrer les données. Les règles métier ne sont appliquées que lorsque les données sont mises à jour vers des InfoProviders supplémentaires.

Il ne contient que le tableau des données actives et il n'est pas nécessaire d'activer les données comme requis avec le DSO standard. Cela vous permet de traiter les données plus rapidement.

Les jeux d'informations sont définis comme un type spécial d'InfoProvider où les sources de données contiennent une règle de jointure sur des objets DataStore, des InfoCubes standard ou des InfoObject avec des caractéristiques de données de base. Les InfoSets sont utilisés pour joindre des données et ces données sont utilisées dans le système de BI.

Jointures temporelles: sont utilisées pour cartographier une période de temps. Au moment de la création de rapports, d'autres InfoProviders traitent les données de base dépendantes du temps de telle sorte que l'enregistrement qui est valide pour une date de référence unique prédéfinie est utilisé à chaque fois. Vous pouvez définir une jointure temporelle qui contient au moins une caractéristique dépendante du temps ou un pseudo-fournisseur InfoProvider temporel.

Les jeux d'informations sont utilisés pour analyser les données dans plusieurs InfoProviders en combinant des caractères de données de base, des objets DataStore et des InfoCubes.

Vous pouvez utiliser la jointure temporelle avec InfoSet pour spécifier un moment particulier où vous souhaitez évaluer les données.

Vous pouvez utiliser les rapports à l'aide de Business Explorer BEx sur les DSO sans activer l'indicateur BEx.

• Jointure interne
• Jointure externe gauche
• Jointure temporelle
• Auto-rejoindre

InfoCube est défini comme un ensemble de données multidimensionnel utilisé pour l'analyse dans une requête BEx. Un InfoCube se compose d'un ensemble de tables relationnelles qui sont jointes de manière logique pour implémenter un schéma en étoile. Une table de faits dans un schéma en étoile est jointe à plusieurs tables de dimension.

Vous pouvez ajouter des données d'un ou de plusieurs InfoSource ou InfoProviders à un InfoCube. Ils sont disponibles en tant qu'InfoProviders à des fins d'analyse et de reporting.

Un InfoCube est utilisé pour stocker les données physiquement. Il se compose d'un certain nombre d'InfoObjects qui sont remplis avec les données de la préparation. Il a la structure d'un schéma en étoile.

Dans SAP BI, un Infocube contient un schéma en étoile étendu, comme indiqué ci-dessus.

Un InfoCube se compose d'une table de faits entourée de 16 tables de dimensions et de données de base situées à l'extérieur du cube.

Les InfoCubes en temps réel sont utilisés pour prendre en charge l'accès en écriture parallèle. Les InfoCubes en temps réel sont utilisés lors de la saisie des données de planification.

Vous pouvez saisir les données dans les InfoCubes en temps réel de deux manières différentes -

Transaction de saisie des données de planification

Mise en scène BI

Un InfoCube en temps réel peut être créé à l'aide de la case à cocher Indicateur en temps réel.

Oui, lorsque vous souhaitez créer un rapport sur des caractères ou des données de base, vous pouvez les définir comme InfoProvider.

Pour convertir un InfoCube standard en InfoCube en temps réel, vous avez deux options -

Convertir avec perte de données transactionnelles

Conversion avec conservation des données de transaction

Oui, double-cliquez sur le paquet d'informations grp → bouton Process Chain Maintenance et saisissez le nom et la description.

• Hiérarchie H
• F valeur fixe
• Blank

Oui.

MultiProvider

ODS -

Ils fournissent des données granulaires, permettent l'écrasement et les données sont dans des tables transparentes, idéales pour l'exploration et la RRI.

InfoCube -

Ceci est utilisé pour le schéma en étoile, nous ne pouvons ajouter que des données, idéal pour les rapports principaux.

MultiProvider -

Il contient des données physiques et permet d'accéder aux données de différents InfoProviders.

Start Routines -

La routine de démarrage est exécutée pour chaque paquet de données après que les données ont été écrites dans le PSA et avant que les règles de transfert aient été exécutées. Il permet des calculs complexes pour un chiffre clé ou une caractéristique. Il n'a pas de valeur de retour. Son but est d'exécuter des calculs préliminaires et de les stocker dans des structures de données globales. Cette structure ou table est accessible dans les autres routines. L'ensemble des données au format de structure de transfert est utilisé comme paramètre pour la routine.

Update Routines -

Ils sont définis au niveau de l'InfoObject. C'est comme la routine de démarrage. Il est indépendant du DataSource. Nous pouvons l'utiliser pour définir les données globales et les contrôles globaux.

Ceci est utilisé pour charger un nouveau package de données dans les agrégats InfoCube. Si nous n'avons pas effectué de cumul, les nouvelles données InfoCube ne seront pas disponibles lors de la création de rapports sur l'agrégat.

Pendant le chargement, effectuez les étapes dans l'ordre ci-dessous -

Chargez d'abord les données de base dans l'ordre suivant: d'abord les attributs, puis les textes, puis les hiérarchies.

Chargez d'abord les données de base, puis les données de transaction. En procédant ainsi, vous vous assurez que les SID sont créés avant le chargement des données de transaction et non pendant le chargement des données de transaction.

Pour optimiser les performances lors du chargement et de la suppression des données de l'InfoCube -

• Indexes
• Aggregates
• Élément de campagne et cardinalité élevée
• Compression

Pour obtenir de bonnes performances d'activation pour les objets DataStore, vous devez noter les points suivants -

Création de valeurs SID

La génération de valeurs SID prend beaucoup de temps et peut être évitée dans les cas suivants -

Ne définissez pas l'indicateur «Générer les valeurs SID» si vous utilisez uniquement l'objet DataStore comme magasin de données. Si vous activez cet indicateur, des SID sont créés pour toutes les nouvelles valeurs de caractéristique.

Si vous utilisez des éléments de ligne (numéro de document ou horodatage, par exemple) comme caractéristiques dans l'objet DataStore, définissez l'indicateur dans la gestion des caractéristiques pour montrer qu'ils sont "attribut uniquement".

C'est la méthode de division d'un tableau pour l'optimisation des rapports. SAP utilise le partitionnement des fichiers de faits pour améliorer les performances. Nous ne pouvons partitionner qu'à 0CALMONTH ou 0FISCPER. Le partitionnement de table permet d'exécuter le rapport plus rapidement car les données sont stockées dans les partitions appropriées. L'entretien de la table devient également plus facile.

Infocube est structuré comme un schéma en étoile où une table de faits est entourée de différentes tables dim qui sont liées aux DIM'ids.

ODS est une structure plate sans concept de schéma en étoile et qui aura des données granulaires (niveau détaillé). Écraser la fonctionnalité.

L'attribut de navigation est utilisé pour explorer le rapport.

Si les séparateurs sont utilisés de manière incohérente dans un fichier CSV, le séparateur incorrect est lu comme un caractère et les deux champs sont fusionnés en un seul champ et peuvent être raccourcis. Les champs suivants ne sont alors plus dans le bon ordre.

Avant de pouvoir transférer des données à partir d'un système source de fichiers, les métadonnées doivent être disponibles dans BI sous la forme d'une DataSource.

Oui.

Sous forme de tableaux PSA

La connexion à la base de données est utilisée pour définir une autre connexion à la base de données en plus de la connexion par défaut et ces connexions sont utilisées pour transférer des données dans le système de BI à partir de tables ou de vues.

Pour connecter une base de données externe, vous devriez avoir les informations ci-dessous -

• Tools
• Connaissance de l'application source
• Syntaxe SQL dans la base de données
• Fonctions de base de données

Universal data UD connect vous permet d'accéder à des sources de données relationnelles et multidimensionnelles et de transférer les données sous forme de données plates. Les données multidimensionnelles sont converties au format plat lorsque Universal Data Connect est utilisé pour le transfert de données.

UD utilise le connecteur J2EE pour permettre la création de rapports sur les données SAP et non SAP. Différents connecteurs Java BI sont disponibles pour différents pilotes, protocoles comme adaptateurs de ressources -

• Connecteur BI ODBO
• Connecteur BI JDBC
• Connecteur de requête BI SAP
• Connecteur XMLA