Information Design Tool de SAP BI4 : Astuces et bonnes pratiques

A propos de Information Design Tool (IDT) :

Information Design Tool (ou outil de conception de l'information en français) est un le nouvel outil de SAP Business Objects destiné aux concepteurs pour créer les univers dans la suite BI4.

Les nouveautés de l'IDT :

L'IDT permet de tirer parti des nouvelles et importantes fonctionnalités de conception d'univers, parmi lesquelles :

• Univers dimensionnels prenant en charge les hiérarchies et les dimensions OLAP
• Univers à sources multiples fédérant plusieurs sources de données relationnelles
• Environnement de conception facilitant le travail d'équipe des créateurs et le partage des ressources d'univers
• Editeur de sécurité pour les métadonnées et les données d'univers
• Gestion étendue des connexions
• Gestion plus aisée des ressources de référentiel

Les composants de l'IDT :

L'IDT permet un développement structuré et organisé de ses univers.

Cette structuration passe par les composants suivants :

• Projet : Un projet est un espace de travail local nommé qui contient les ressources utilisées pour créer un ou plusieurs univers. Un projet peut contenir un nombre quelconque de ressources indépendantes; des fondations de données, des couches de gestion et des connexions, par exemple. Toutes les ressources contenues dans un projet peuvent être utilisées de façon interchangeable ; une connexion peut être utilisée par plusieurs fondations de données dans le même projet, par exemple.
• Connexion : c'est l'ensemble nommé de paramètres qui définissent la façon dont un univers peut accéder à une base de données relationnelle ou OLAP.
• Une connexion est une ressource indépendante qui peut être utilisée par plusieurs univers. Il est possible de créer des univers à sources multiples qui référencent une ou plusieurs connexions relationnelles.
• Fondation de données : Une fondation de données est un schéma définissant les tables et jointures pertinentes dans une ou plusieurs bases de données relationnelles. Elle devient la base d'une ou de plusieurs couches de gestion.
• Couche de gestion : Une couche de gestion est un ensemble d'objets de métadonnées fournissant une abstraction des entités de bases de données relationnelles ou des cubes OLAP, compréhensible par un utilisateur professionnel. Ces objets incluent les dimensions, hiérarchies, indicateurs, attributs et conditions prédéfinies. La couche de gestion désigne l'univers en construction et, lorsque la couche de gestion est terminée, elle est compilée avec les connexions ou raccourcis de connexion et la fondation de données, publiée et déployée sous forme d'univers.

Avec ces composants, il est donc possible de créer un seul projet (Projet entreprise) contenant toutes les connexions vers les différentes sources de l'entreprise, une fondation de données contenant ces connexions, et plusieurs couches de gestion (une couche de gestion par métier/domaine) comme illustré dans le schéma suivant :

Les bonnes pratiques

Nous allons organiser ces bonnes pratiques selon 3 catégories :

• Focus Utilisateur : Pour apporter une valeur ajoutée au métier
• Focus Développement: Pour construire une solution solide techniquement avec quelques astuces pour aller plus vite dans les développements.
• Focus Performance : Pour assurer de bonnes performances

Focus Utilisateur :

Important :

Toutes les règles et bonnes pratiques de ce paragraphe doivent être définies et validées en étroite collaboration avec le métier.

Organisation des classes et objets :

L'organisation de l'univers (classes, objets, noms , descriptions) doit être pertinente pour le métier :

• Respecter dans la mesure du possible un processus métier (on peut s'inspirer des applications opérationnelles).
• Limiter le nombre de sous-classes ( pas plus de 4)
• Limiter le nombre d'objets par classe (20-25)
• Organiser les classes dans l'ordre suivant :
• Dimensions (référentiels)
• Indicateurs (à organiser par thème/domaine métier)
• Paramètres (s'il y en a)
• Ajouter une classe cachée pour les objets obsolètes (les supprimer peut rendre certaines rapports incorrects)

Règles de nommage :

Les règles de nommage permettent de garantir la cohérence et la stabilité des univers au sein de l'entreprise.

Ces règles doivent être universelles (au sein de l'entreprise) en utilisant le plus possible des termes du métier (pour que ces règles aient du sens).

Ces règles doivent être respectées dans tous les univers.

Elles peuvent concerner :

• Le nom de l'univers : un nom métier clair et précis
• Les noms des classes : 
• En plus d'un nom métier compréhensible, il est très utile d'utiliser des préfixes (3 lettres par exemple) (*). 
• Ne pas dépasser 60 caractères.
• Les noms des objets : 
• idem que les classes. 
• Il est possible de s'inspirer des applications opérationnelles (au moins pour garder le même nom). 
• Préfixer avec le même préfixe que sa classe.
• Le nom doit être unique.
• Les filtres prédéfinis: 
• Le nom du filtre prédéfinie doit contenir la condition en question
• Les invites : 
• Ajouter '?' pour montrer qu'il s'agit d'une invite (et surtout différencier avec les filtres prédéfinis)
• Les descriptions (des classes et des objets) : 
• Tous les objets doivent avoir une description
• Elles doivent être compréhensibles et apporter une vraie aide à l'utilisateur

(*) point sur les préfixes : l'utilisation des préfixes apporte une vraie valeur ajoutée lors de la création/modification des rapports surtout quand l'univers est assez conséquent avec plusieurs classes et des centaines d'objets. En effet, ils permettent :

• De ne pas mélanger les objets dans le fournisseur de données
• Un affichage ordonné des objets dans le rapport (volet gauche)
• L'unicité du nom sans besoin d'avoir un nom très long qui peut ne pas s'afficher en entier (dans l'éditeur des fournisseurs de données)
• De trouver, en se basant sur le préfixe, la classe de chaque objet
• La simplification de la recherche d'un objet dans l'univers (surtout en cas de modification)

Listes de valeurs :

Penser à personnaliser les listes de valeurs pour ajouter toutes les informations qui faciliteront le choix de la valeur (en plus du code, ajouter le nom/le libellé, pour un objet appartenant à une hiérarchie ajouter tous les niveaux supérieurs, ajouter un tri ...)

Format des objets

Définir le format des objets dans l'univers permet d'éviter de le faire dans chaque rapport. Il est à définir principalement pour :

• Les dates : définir le format qui sera utilisé dans tous les rapports
• Les objets date (comme l'année, le trimestre…) : pour par exemple éviter l'affichage par défaut des séparateurs de milliers.
• Les nombres : Attention au nombre de décimales. La définition du nombre de décimales dans l'univers peut engendrer un problème d'arrondi dans les rapports.

Focus Développement:

Connexion

Connectivité native : 

Toujours utiliser la connectivité native de l'éditeur

Eviter les drivers génériques comme ODBC pour Oracle

Nom de la connexion : 

Bien nommer la connexion (afin d'identifier facilement la base de données source)

Dans un univers multi-source, le nom de la connexion est utilisée dans la définition SQL des objets (@catalog('Nom_connexion')), il faut donc choisir un nom générique indépendant de l'environnement (développement, test, recette, production).

Connection pool mode : 

Il existe 3 modes de connexion à la base :

• Déconnecter après chaque transaction

• Conserver la connexion active pendant une durée à fixer

• Conserver la connexion active pendant toute la durée de la session

Le processus de création d'une connexion de base de données est assez cher en temps, il est donc préférable de garder la connexion ouverte plus longtemps. Mais les connexions ouvertes consomment des ressources sur le serveur de base de données, il faut donc limiter le nombre de connexion au minimum.

Il faut donc trouver le mode optimum en fonction de l’utilisation

Fondation de données

Préférences : 
Paramétrer, dans les préférences, le mode d'affichage des jointures pour avoir une meilleure visibilité (opter pour lignes droites) : 

Bien organiser la structure :

Tables de faits au centre

Tables de dimensions à gauche et à droite

Les tables de dimensions qui sont liées entre elles doivent être du même côté

Disposer les tables de telle sorte que les cardinalités 1-n soient de gauche à droite
Ajouter des commentaires

Les familles et les vues:

Utiliser les familles et les vues pour bien organiser la fondation de données

Créer une famille par thème/axe d'analyse/table de faits/Tables dérivées…
Ajouter une légende pour les couleurs

Créer une vue par contexte

Exemple d'utilisation de ces deux points :  

Pas de table isolée :

Toute table utilisée ne doit pas être isolée. Il faut éviter les produits cartésiens

Les jointures doivent se faire sur des indexs :

S’assurer que toutes les jointures implémentées dans l’univers ont des indexs correspondants.

Dans les jointures éviter :

Les jointures externes

les formules

les jointures avec Or

les jointures n-n

les jointures 1-1

Une modélisation bien faite est donc nécessaire avant de développer l’univers.

Jointure isolée :

Eviter les jointures ne faisant partie d’aucun contexte

Cardinalités :

Les cardinalités doivent être toujours définies

Ne pas détecter automatiquement

Pas de génération automatiques des jointures :

Il vaut mieux les faire manuellement

Les contextes :

Créer un contexte par table de faits

Donner un nom métier au contexte

SQL options :

Ne pas autoriser les produits cartésiens

Cocher plusieurs SQL pour chaque contexte

Quelques astuces :

Ajout d'une jointure :

Bien choisir le sens de la jointure (de la table contenant la clé primaire vers celle qui contient la clé étrangère) quand on déssine le trait correspondant

Lorsqu'on ajoute une jointure il faut s'assurer qu'elle ne reste pas neutre, il faut l'inclure dans les contextes correspondants et l'exclure des autres.

Le fait de laisser une jointure neutre (pour 1 ou plusieurs contextes) peut générer des problèmes de boucles , de produit cartésien ou d'incompatibilité

Suppression d'une jointure :

Pour supprimer une jointure il faut s'assurer que cette jointure est neutre (par rapport à tous les contextes) avant la suppression, il faut donc vérifier tous les contextes pour la rendre neutre.

La suppression d'une jointure inclue ou exclue d'un contexte supprimera aussi ce contexte (mais on est alerté).

Modification d'une table dans une jointure :

Pour modifier une jointure (remplacer l'une des tables par une autre), il suffit d'ouvrir la jointure et de la modifier dans la fenêtre affichée (modifier la table, puis choisir les colonnes). Pas besoin de la supprimer et de créer une nouvelle.

Ceci fonctionnera même si on veut remplacer toutes les tables de la jointure.

Et la jointure reste dans tous les contextes (ça nous évite donc de supprimer/ajouter une jointure et de parcourir tous les contextes pour ajouter la nouvelle jointure).

Couche de gestion

Options de requêtes : 

• Plusieurs SQL pour chaque mesure : éviter de cocher cette option. Le fait de cocher cette option générera une requête SQL par indicateurs (même si plusieurs indicateurs sont dans la même table). Cette règle (ne pas cocher cette option) sous-entend une modélisation bien faite (pas de problème de doublons, contextes bien définis...).
• Garder les autres options cochées
• Les limites : les limites sont à paramétrer en fonction de la taille de la base et des rapports. Pour éviter les mauvaises surprises ( résultats partiels, arrêt de la requête, ...) ne pas cocher ces limites.

Description : 
Utiliser le champ description pour décrire fonctionnellement l'univers

Commentaires : 
Utiliser ce champ pour le versionning avec description de chaque modification

Les indicateurs :

- Donner un nom unique en respectant les règles de nommage
- Toujours donner une description fonctionnelle de l'indicateur à définir avec le métier. Préciser s'il y a des spécificités particulières
- La fonction SQL d'agrégat doit être définie dans la clause SELECT.
- Eviter, dans la mesure du possible, de renseigner les clauses WHERE. Si besoin utiliser la fonction decode (IfElse) dans la clause SELECT.
- Définir la fonction de projection.

Les dimensions :

- Donner un nom unique en respectant les règles de nommage
- Toujours donner une description fonctionnelle de l'indicateur à définir avec le métier. Préciser s'il y a des spécificités particulières
- Eviter, dans la mesure du possible, de renseigner les clauses WHERE.

La fonction @Select :
La fonction @select permet de simplifier: 
- Les SQL complexes
- La maintenance des objets s'ils sont liés entre eux


Requêtes : 
Utiliser systématiquement les requêtes SQL pour tester

Vérifier l'intégrité : 
à faire systématiquement, surtout avant chaque publication

HTML : 
Utiliser les balises HTML pour donner des couleurs à la description de l'objet : 

Focus Performance :

Tables dérivées :

À éviter dans la mesure du possible. À la place créer des tables ou des vues matérialisées.

Raccourci jointure :

Utiliser les raccourcis jointures dans la mesure du possible pour réduire le nombre de tables dans la requête

Nombre de lignes :

Toujours afficher le nombre de lignes de chaque table. Principalement pour deux raisons :

Repérer facilement les tables avec des données manquantes

Pour vérifier l’intégrité des cardinalités des jointures

Affichage du nombre de lignes : 

Les indexs :

Le but des indexs est de substituer les Identifiants aux descriptions afin de gagner en performance.

Les indexs permettent d’éliminer certains jointures et d’utiliser les clés étrangères.

À utiliser principalement sur des objets description sur lesquels il y a des filtres.

L’index remplace le filtre sur la description par un filtre sur l’Identifiant.

Les clés primaires et les clés étrangères doivent être définies pour chaque objet qu’on veut remplacer par un index :

Aggregate Awareness :

-La fonction Aggregate Awareness permet de choisir le chemin optimal en fonction du niveau de détail demandé dans la requête
-Les étapes nécessaires :
-Définir les tables d’agrégats
-Définir l’objet avec la fonction @Aggregate_Aware
-Définir les incompatibilités des classes/objets avec les tables d’agrégats

Univers mono vs multi-source :

Préférer l'univers mono-source en raison de la générative native du SQL

Array Fetch Size : 
Cette option définit le nombre de lignes ramenées à chaque extraction. La valeur par défaut est 10, mais elle peut être augmentée jusqu'à 1000 pour de meilleurs performances mais cela nécessite plus de mémoire.
Il faut tester plusieurs valeurs jusqu'à trouver le bon équilibre avec le transfert réseau.


A utiliser sans modération :)