SAP Business Objects : Bonnes pratiques pour la création d’un univers

L’univers est une couche sémantique utilisée au niveau de la phase de modélisation dans le processus de mise en place d’une chaîne décisionnelle avec Business Objects. C’est en fait une représentation métier des données récupérées à partir d’une base de données (pour BO XI 3.1 et les versions antérieures). Il permet ainsi aux utilisateurs de BO d’interagir avec les données en utilisant leur vocabulaire métier quotidien.

Suite au suivi de la formation SAP BO XI 3.1 de Benoit David, J’ai notamment appris de nombreuses bonnes pratiques intéressantes pour la conception d’un univers BO. Je vous en présente ici un petit échantillon.

Après avoir exposé deux recommandations concernant la création globale de l’univers, je proposerai dans ce post quelques conseils concernant la conception du schéma d’univers puis d’autres bonnes pratiques concernant la création des objets et classes de l’univers.

L’univers est une couche sémantique utilisée au niveau de la phase de modélisation dans le processus de mise en place d’une chaîne décisionnelle avec Business Objects. C’est en fait une représentation métier des données récupérées à partir d’une base de données (pour BO XI 3.1 et les versions antérieures). Il permet ainsi aux utilisateurs de BO d’interagir avec les données en utilisant leur vocabulaire métier quotidien.

Suite au suivi de la formation SAP BO XI 3.1 de Benoit David, J’ai notamment appris de nombreuses bonnes pratiques intéressantes pour la conception d’un univers BO. Je vous en présente ici un petit échantillon.

Après avoir exposé deux recommandations concernant la création globale de l’univers, je proposerai dans ce post quelques conseils concernant la conception du schéma d’univers puis d’autres bonnes pratiques concernant la création des objets et classes de l’univers.

Bonnes pratiques globales

Un univers = un environnement métier

L’objectif d’un univers est de de fournir à l’utilisateur une représentation métier des données qu’il veut récupérer, diffuser, analyser. Il est donc primordial d’impliquer un maximum les futurs utilisateurs de BO dans la conception de l’univers (Les utilisateurs comprenant les créateurs mais aussi et surtout les destinataires des rapports BO). Cela permettra par exemple de déterminer au mieux les noms des classes et des objets de l’univers afin que les utilisateurs ne soient pas perdus lors de la création des rapports BO. Il est également conseillé de définir avec les utilisateurs les descriptions des objets et de les ajouter dans l’univers.

Vérifier l’intégrité de son univers

Le designer d’univers permet de vérifier l’intégrité d’un univers (validation des jointures, détection et résolutions des boucles, validation des cardinalités, validation du typage des données…). Cette fonctionnalité est rapide et assez efficace, ne pas hésiter à l’utiliser après la phase de construction puis à chaque modification de l’univers. Vous la trouverez dans l’onglet « tools » du Designer.

Bonnes pratiques pour la création du schéma d’univers

Eviter si possible les jointures externes

Les jointures externes sont coûteuses en terme de volumétrie engendrée et au niveau du temps d’exécution des requêtes.

Utiliser les tables dérivées

Les tables dérivées sont semblables aux vues de base de données. Ce sont des tables logiques construites à partir de requêtes SQL portant sur une ou plusieurs tables du modèle de données. Les tables dérivées présentent l’intérêt de diminuer le volume de données renvoyées au document pour analyse. Vous pouvez inclure des calculs et des fonctions complexes dans une table dérivée. Ces opérations sont ainsi effectuées avant que l’ensemble de résultats soit renvoyé au document, ce qui permet de gagner du temps et d’éviter des analyses complexe sur de grands volumes de données au niveau du rapport.
Les tables dérivées ont encore un autre avantage : elles peuvent inclure des invites.

Bonnes pratiques pour la création des objets et classes

Le nommage des objets

Un univers est généralement amené à contenir de nombreux objets appelés, nom, code, libellé etc… et cela dans différentes classes. Or Il est nécessaire pour l’utilisateur de bien identifier ce que décrit chaque objet et la classe à laquelle il appartient. Il est donc indispensable que chaque objet ait, dans la mesure du possible, un nom unique et explicite. Une solution simple et efficace est de préfixer les noms des objets avec le nom (ou l’abréviation du nom) de la classe à laquelle ils appartiennent.

Supprimer les listes de valeurs superflues

Par défaut chaque objet créé se voit associé une liste de valeurs. Cette liste contient toutes les valeurs issues du SQL de l'objet (en général les valeurs d'une colonne). Cette liste est notamment affichée lors de l’exécution d’une requête où l'objet est utilisé en invite.
Cependant pour certains types d’objets, afficher la liste de toutes les valeurs est inutile : par exemple pour les dates, les ids, les indicateurs … Pour ces types, autant éviter le chargement et l’affichage de toutes les valeurs de l’objet à chaque exécution d’une requête les impliquant comme invite. Il est donc conseillé :

  • Soit de décocher la case « Associate a List of Values » dans les propriétés des objets quand ce n’est pas pertinent.
  • Soit d’éditer des listes de valeurs spécifiques pour ces objets (par exemple des valeurs issues d’une table calendrier pour les dates).

Attention : L'option "Export with universe" doit être cochée si l'on veut que la liste de valeurs soit disponible pour un autre utilisateur que le créateur de l'univers.

Ne pas utiliser de clause « WHERE » dans un objet

image_BO_amelie

Lorsque plus d’un objet avec une clause WHERE est utilisé dans une requête, toutes les clauses WHERE sont associées avec l’opérateur AND. Ceci peut rendre la requête incohérente. Exemple avec la requête ci-dessous qui ne retourne aucune donnée :

SELECT * FROM couleurs WHERE couleur = 'rouge' AND couleur = 'vert';

Limiter la profondeur de hiérarchie dans les classes

Il est conseillé de limiter le nombre de classes et de dimensions qui doivent être déployées pour qu’un objet soit visible. Ce nombre ne doit pas être supérieur à 1 ou 2 pour des objets d’usage très fréquent, 3 pour des objets d’usage fréquent et à 5 pour les autres objets. Cela est nécessaire pour que l’utilisateur puisse naviguer facilement dans l’univers.

Limiter le nombre d’objets par classe

Là encore pour faciliter la navigation des utilisateurs dans l’univers, il est préférable qu’une classe ne contienne pas plus de 20 objets.

Conclusion

Il y aurait encore beaucoup à dire sur la création d'univers. De nombreux blogs et sites proposent des conseils et tutoriels sur ce sujet. J'en conseillerais un en particulier : http://michaelwelter.wordpress.com/ . On y trouve des retours d'expériences relativement instructifs.

Un commentaire

  1. Modifiez ce script sql si vous voulez ajouter d’autres informations à votre commande.
    Pour forcer la réinstallation d’un module, supprimer la ligne correspondante dans la table « core_resource ».

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.