Bonnes Pratiques Business ObjectsConsultez toutes les FAQ
Nombre d'auteurs : 4, nombre de questions : 21, création le 24 novembre 2013
Sommaire→Designer- Restreindre le nombre de sous classes
- Ne pas autoriser les libellés en condition. Modifier la liste de valeur de l'identifiant en ajoutant le libellé
- Privilégier les alias sur des tables de faible volumétrie, utiliser les contextes pour les gros volumes
- Faire attention à l'activation ou la désactivation du cadenas sur un univers au moment de l'importation
- Éviter d'utiliser un schéma de base de données qui a accès à d'autres tables que celles souhaitées
- A chaque ajout ou modification d'un objet, cliquer sur Analyser avant de cliquer sur OK
- Ne pas mettre d'objets avec une formule 'moyenne' dans l'univers
- Utiliser les contextes si le modèle est en étoile
- Avant chaque export dans le référentiel cliquer sur le bouton 'Vérifier l'intégrité'
- Utiliser les sous-classes au maximum et faire en sorte qu'une classe ouverte tienne sur un écran (en ayant les sous-classes fermées)
- Ne jamais supprimer d'objet, les masquer et les déplacer dans une classe 'poubelle' elle-même masquée
- Mettre la fonction sum() sur tous les indicateurs voués à être sommés
Version : Toutes
Pourquoi : Univers illisible pour les utilisateurs s'ils doivent dérouler 7 sous classes pour trouver un objet.
Version : Toutes
Pourquoi : La requête sera plus performante en utilisant l'identifiant.
Version : Toutes
Pourquoi : Un alias sur une table de forte volumétrie va augmenter le temps de requêtage.
Pourquoi : Ce cadenas ne verrouille pas l'export d'un univers, mais il signale que quelqu'un travaille dessus.
Versions : BI4
Pourquoi : en BI4 il est possible d'éditer les requêtes pour faire une autre qui n'a rien à voir avec l'original, comme interroger des tables systèmes.
Pourquoi : Cela permet de vérifier rapidement si l'objet est correct ou pas. Si on ajoute ou modifie une centaine d'objets c'est bien de voir les erreurs dès le premier objet afin de ne pas les reproduire sur les suivants.
Versions : toutes sauf BI4
Pourquoi : En effet ces objets ne peuvent pas être projetés/recalculés dans le document. Par exemple si on prend en requête la moyenne du prix de vente par pays et magasin on ne peut avoir la moyenne du prix de vente par pays, car on ne peut pas sommer les différentes moyennes ... Il vaut mieux calculer ces moyennes dans le document.
Versions : toutes
Pourquoi : Les objets propres aux dimensions sont uniques et sont mis dans des dossiers spécifiques. Si on utilisait des alias il faudrait les dupliquer.
Versions : toutes
Cela permet de vérifier facilement les anomalies et de trouver des erreurs qu'on n'aurait pas vu.
TDB : Non. Souvent les calculs de cardinalités peuvent tomber dans inconnu et générer des erreurs qui n'en sont pas... Ca reste une bonne pratique, mais le résultat de l'analyse est à interpréter.
Version : Toutes
Pourquoi : Difficile pour un utilisateur de trouver un objet quand il est noyé dans la masse ... Il faut offrir une vue condensée des objets disponibles en les regroupant par thème.
Version : Toutes
Pourquoi : Difficile de s'assurer qu'un rapport n'utilise pas l'objet qu'on veut supprimer. Le masquer permet d'empêcher son utilisation sans pour autant causer de régression (et donc éviter la fameuse erreur "des objets obsolètes ont été supprimés de la requête")
Version : Toutes
Pourquoi : Le calcul de somme est effectué en base et la requête génère un GROUP BY. Résultat : requête plus rapide et rapport moins lourd
Doc : : Vrai ... mais attention, l'indicateur sera aussi sommé en condition de requête. Cela amène des erreurs fréquentes où on pense être au détail et qu'on ne l'est pas. Par exemple, on veut les clients ayant acheté un produit de plus de 1000 euros. On est naturellement tenté de mettre le client en résultat et le montant en condition, car on est au détail. Mais comme c'est sommé on aura les clients ayant au total plus de 1000 euros ...