Une dimension BusinessObjects traduit un axe de lecture métier en objet d’univers. Sa qualité détermine les regroupements, les ruptures et les filtres disponibles dans Web Intelligence. Une dimension mal qualifiée ou rattachée à un mauvais contexte produit des rapports plausibles, mais difficilement réconciliables avec la source.
En bref
- Les Dimensions doivent représenter des niveaux d’analyse stables, tels que le client, le produit, la période ou l’organisation, et non la structure physique des tables.
- La Création de dimensions engage la qualification de l’objet, son expression SQL, ses listes de valeurs, ses restrictions d’usage et parfois ses règles de sécurité.
- Les conditions prédéfinies et les fonctions d’univers réduisent les ressaisies, mais elles peuvent aussi cacher des règles de gestion dans les requêtes générées.
- Les Pièges courants viennent surtout des jointures, des contextes, des dimensions fusionnées et des objets techniques rendus visibles aux utilisateurs.
Ce contenu s’adresse aux responsables BI, concepteurs d’univers et chefs de projet qui maintiennent des univers SAP BusinessObjects XI 3.1, BI 4.2 ou BI 4.3. Il traite la couche sémantique et les Rapports BusinessObjects, non la négociation des licences SAP ni la protection des données personnelles, qui relève de votre DPO.
Quel rôle les dimensions jouent-elles dans les rapports BusinessObjects ?
Le Rôle des dimensions consiste à donner un vocabulaire métier aux utilisateurs de Web Intelligence. Une table relationnelle expose des colonnes, des clés et des jointures. Un univers expose des objets compréhensibles, comme Client, Produit, Mois de vente, Responsable commercial ou Entité juridique. Cette séparation évite qu’un utilisateur construise une requête à partir d’une clé technique ou d’un champ de statut mal interprété.
Dans BusinessObjects, une dimension décrit une valeur de regroupement ou de détail. Elle peut être textuelle, numérique ou de type date. Lorsqu’un rapport affiche le chiffre d’affaires par pays, le pays est une dimension et le chiffre d’affaires est un indicateur. Lorsque le même rapport descend au niveau de la ville puis du point de vente, les dimensions définissent les ruptures successives de l’analyse.
Cette distinction paraît connue, mais elle conditionne toute la Modélisation des données. Un code client peut être une dimension si l’utilisateur doit filtrer ou détailler une analyse par client. Le nom complet du client peut être une information associée, utile à l’affichage mais insuffisante pour former une hiérarchie. Une date de facture peut devenir une dimension de date, à condition de préciser ce qui est analysé, la date de commande, la date de livraison ou la date de comptabilisation.
Pourquoi la qualification dimension, indicateur ou information doit rester cohérente
Les univers classiques proposent trois qualifications principales. La dimension porte l’axe d’analyse. L’indicateur porte une valeur agrégée, comme une somme de montant, un nombre de commandes ou une marge. L’information complète une dimension sans devenir un axe autonome. Une adresse client ou un téléphone relèvent souvent de cette dernière catégorie.
La confusion produit des effets visibles dans les tableaux Web Intelligence. Un montant qualifié comme dimension peut provoquer un détail excessif et multiplier les lignes. À l’inverse, un code produit placé en information peut ne pas être disponible lors d’une exploration ou d’une construction de hiérarchie. Le rapport reste techniquement exécutable, mais l’utilisateur perd l’axe d’analyse dont il a besoin.
Les versions BI 4.2 et BI 4.3 utilisent toutes deux le principe de qualification multidimensionnelle dans les univers. Le Designer historique travaille sur des univers UNV, tandis que l’Information Design Tool gère des univers UNX et une architecture plus adaptée aux connexions et fondations de données modernes. La logique métier reste identique. La documentation SAP consacrée à la conception de solutions BusinessObjects, consultée le 18 juin 2026, rappelle que les objets de couche métier servent à rendre la source exploitable par les outils de restitution : parcours SAP sur la conception de solutions BusinessObjects.
| Qualification | Usage dans un rapport | Exemple d’expression attendue | Risque si la qualification est erronée |
|---|---|---|---|
| Dimension | Rupture, filtre, hiérarchie, exploration | Nom du client, mois de vente, famille produit | Analyse impossible ou détail non maîtrisé |
| Indicateur | Agrégation et calcul de performance | Somme du chiffre d’affaires, quantité vendue | Doublons, totaux incohérents ou agrégation absente |
| Information | Complément rattaché à une dimension | Adresse, téléphone, code postal du client | Objet visible sans valeur analytique réelle |
Ce tableau décrit une règle de conception valable pour les univers relationnels BusinessObjects. La vérification doit porter sur les requêtes SQL générées et sur le rendu Web Intelligence. Une qualification correcte dans l’univers ne compense pas une jointure qui multiplie les lignes source.
Le premier contrôle consiste donc à sélectionner une dimension et un indicateur dans une requête minimale. Si le total change lorsque vous ajoutez une dimension qui ne devrait pas modifier le grain, le problème ne se situe pas dans le tableau Web Intelligence. Il se situe dans le modèle, dans une jointure, dans un contexte ou dans une agrégation déclarée trop tôt.
Une dimension n’est pas un libellé esthétique posé au-dessus d’une colonne SQL. Elle représente un engagement de la couche sémantique sur le grain auquel l’utilisateur peut lire un chiffre. La section suivante porte sur la manière de construire cet engagement dans les classes et objets.
Comment organiser les classes et réussir la création de dimensions ?
La Création de dimensions commence par la classe qui les accueille. Une classe organise les objets dans l’univers selon une logique que l’utilisateur reconnaît. Une structure par tables, telle que DIM_CUSTOMER, F_SALES ou REF_PRODUCT, n’a pas sa place dans l’interface métier. Elle expose l’implémentation de la base et transfère son coût de compréhension à l’utilisateur final.
Une classe peut plutôt s’appeler Clients, Ventes, Produits, Réservations, Organisation ou Calendrier. Elle contient les objets mobilisés ensemble lors de la construction d’une requête. Dans un univers de gestion commerciale, le nom du client, son segment, son pays et son commercial relèvent de la classe Clients. Le montant facturé, la quantité et la marge relèvent de Ventes.
Dans le Designer, la fenêtre Classes et objets affiche cette arborescence, avec les objets et leur qualification. Le déplacement par glisser-déposer est commode lors de la phase de construction. Il devient dangereux dans un univers partagé si aucun contrôle ne suit. Déplacer un objet peut modifier les habitudes des utilisateurs, casser un favori de requête ou rendre une règle difficile à retrouver pendant une recette.
Construire des objets indépendants du schéma physique
Un objet comporte un nom, une description et une expression SQL. Le nom doit être suffisamment explicite pour être sélectionné sans consulter la base. Une description doit préciser le périmètre lorsque le nom ne suffit pas. « Chiffre d’affaires » n’est pas un objet complet tant que l’univers ne dit pas s’il s’agit du montant commandé, livré, facturé, net des avoirs ou hors taxes.
L’expression SQL comporte habituellement un fragment SELECT, complété par les tables et conditions nécessaires à la requête générée. Dans un univers UNX, l’Information Design Tool sépare plus clairement la fondation de données, la couche métier et la publication. Cette séparation réduit la tentation de modifier directement un objet métier pour corriger une jointure. Elle ne retire pas l’obligation de documenter chaque règle.
Une création par glisser-déposer depuis une colonne fournit un point de départ. Elle déduit le type de données et crée souvent une dimension. Ce mécanisme ne constitue pas une validation. Une colonne DATE_TRANSACTION peut contenir une date technique de chargement ; la rendre visible sous le nom « Date de vente » crée un défaut métier, même si le type de données est correct.
Un objet calculé peut aussi devenir une dimension. Une tranche d’âge, un statut de portefeuille ou une catégorie de montant peuvent être construits avec une expression CASE ou une fonction du SGBD. Ces objets sont utiles lorsque leur définition est stable et partagée. Ils deviennent fragiles lorsque les seuils changent chaque trimestre sans versionnement de l’univers.
Limiter les objets visibles avant de publier un univers
Une université d’objets trop large ne donne pas plus d’autonomie. Elle augmente les Erreurs fréquentes de sélection. Les identifiants techniques, dates de chargement, clés de jointure et statuts internes doivent rester masqués, sauf besoin métier documenté. La propriété « Peut être utilisé dans » permet aussi de limiter la présence d’un objet dans le résultat, dans les conditions ou dans les tris.
Cette propriété est particulièrement utile pour une dimension coûteuse. Une colonne textuelle issue d’une table volumineuse peut être acceptable dans un filtre contrôlé, mais pas dans une liste de résultats ou un tri serveur. Le choix doit être établi après examen du SQL produit et du volume traité. L’interface ne doit pas laisser croire qu’un objet est neutre parce qu’il est disponible dans une classe.
Les niveaux de sécurité d’accès jouent un rôle distinct. Ils déterminent qui voit un objet, mais ne remplacent pas une restriction de données. Masquer « Marge » à un profil n’empêche pas nécessairement un autre calcul de reconstruire l’information si les composants restent exposés. La sécurité de données se traite dans les profils, les restrictions d’univers et le modèle de droits ; la conformité des données personnelles relève, elle, de votre DPO.
Sur un parc appelé à être repris, la cartographie des classes sert aussi à évaluer la dette de conception. Une classe contenant trente objets dont vingt-trois ne sont jamais utilisés mérite un arbitrage avant migration. Les règles enfouies dans les objets doivent être relevées avec la même méthode que les filtres, comme l’explique ce dossier sur les règles de gestion cachées dans un univers BusinessObjects.
Une classe bien nommée ne rend pas un univers juste, mais elle rend les contrôles possibles. La Gestion des dimensions doit ensuite porter sur les filtres réutilisables et les fonctions qui étendent, ou déforment, leur comportement.
Comment utiliser les conditions prédéfinies sans masquer une règle de gestion ?
Une condition prédéfinie enregistre une restriction SQL sous un nom utilisable dans la requête. Elle peut limiter un résultat aux clients actifs, aux ventes d’un exercice, à une famille de produits ou à une zone commerciale. Elle apparaît comme un objet de filtre dans l’univers et évite aux utilisateurs de reformuler une même condition à chaque rapport.
Le bénéfice est réel lorsque la règle est stable, comprise et applicable dans plusieurs Rapports BusinessObjects. Une condition « Exercices clos » peut éviter qu’un utilisateur mélange des écritures provisoires et des périodes validées. Une condition « Clients actifs » peut uniformiser la définition utilisée par plusieurs équipes. Le gain ne vient pas de l’automatisation seule, mais de la possibilité de vérifier une règle à un emplacement identifié.
Le défaut apparaît lorsqu’une condition devient un écran. Une restriction sur le statut client, posée dans le WHERE d’un objet plutôt que dans un filtre visible du rapport, peut expliquer un écart de chiffre d’affaires sans être détectée lors d’une lecture Web Intelligence. Le rapport présente un total cohérent avec lui-même. Il reste incohérent avec un autre état qui n’emploie pas le même univers ou pas la même condition.
Faire la différence entre filtre métier, filtre de sécurité et filtre de confort
Un filtre métier traduit une règle de calcul ou de périmètre. Il doit être documenté et testé dans les jeux de recette. Un filtre de sécurité limite les données selon le profil connecté. Il doit être validé avec les administrateurs et les responsables habilités. Un filtre de confort réduit un volume affiché, par exemple les douze derniers mois, mais ne doit pas être confondu avec une règle de gestion.
Les conditions prédéfinies peuvent contenir des fonctions BusinessObjects. @Prompt ouvre une saisie à l’exécution de la requête. Sa formulation doit être contrôlée : le libellé, le type de réponse, la multi-sélection et la liste de valeurs influencent directement le périmètre interrogé. Deux invites presque identiques peuvent produire des comportements différents s’il existe une différence de type ou de contrainte.
@Select permet de réutiliser la clause SELECT d’un autre objet. @Where réutilise sa restriction. Ces fonctions limitent la duplication, mais créent une dépendance. Si l’objet source est renommé, modifié ou supprimé, il faut vérifier tous les objets qui le référencent. Le nom métier ne suffit pas : l’inventaire doit inclure les expressions et les dépendances croisées.
La fonction @Aggregate_Aware traite un problème différent. Elle permet d’orienter BusinessObjects vers des tables agrégées ou détaillées selon les objets demandés. Son intérêt est de réduire le volume interrogé lorsque les agrégats sont fiables. Son risque est de produire des totaux divergents si la table agrégée n’est pas alignée avec la table détaillée, notamment après une évolution de la règle de calcul.
| Mécanisme d’univers | Usage métier attendu | Point de contrôle en recette | Défaut observé si le contrôle manque |
|---|---|---|---|
| Condition prédéfinie | Réutiliser un périmètre stable | Comparer le WHERE généré avec la règle validée | Filtre invisible et écart inexpliqué |
| @Prompt | Faire choisir une période ou un périmètre | Tester les valeurs vides et la multi-sélection | Extraction trop large ou trop restrictive |
| @Where | Centraliser une restriction liée à un objet | Identifier tous les objets dépendants | Modification locale avec effet global |
| @Aggregate_Aware | Choisir un niveau de table adapté au grain | Réconcilier agrégé et détaillé sur une période close | Écart de total selon les dimensions demandées |
La documentation du portail SAP BusinessObjects Business Intelligence Platform, consultée le 18 juin 2026, doit rester votre référence pour vérifier les comportements de version et les fonctions disponibles. Aucun environnement BI 4.3 n’a été ouvert pour ce contenu ; les mécanismes décrits s’appuient sur cette documentation et sur les principes de conception d’univers relationnels.
Une condition préconfigurée mérite donc un nom qui porte son périmètre, une description de sa règle et un cas de recette associé. Dès qu’elle modifie un indicateur financier, elle doit figurer dans la matrice de réconciliation. La suite concerne les hiérarchies, car elles peuvent amplifier les défauts de grain déjà présents dans les objets.
Comment construire des hiérarchies de dates fiables pour l’analyse multidimensionnelle ?
L’Analyse multidimensionnelle s’appuie sur des hiérarchies pour passer d’un niveau de lecture à un autre. Une hiérarchie de produits peut suivre Famille, Groupe, Sous-groupe et Produit. Une hiérarchie géographique peut passer de l’entité juridique au pays, puis à la zone commerciale. Une hiérarchie de dates relie fréquemment Année, Trimestre, Mois et Jour.
Une hiérarchie ne crée pas des données. Elle organise les dimensions disponibles pour permettre le forage et les regroupements. Lorsqu’un mois est rattaché à une année sans identifiant fiable, le rapport peut afficher des mois dans le mauvais ordre ou agréger janvier de plusieurs années sous une même étiquette. Le libellé « Janvier » est lisible. Il n’est pas une clé temporelle suffisante.
La construction d’une hiérarchie demande donc une colonne de date ou une clé calendrier cohérente, puis des objets de niveau dérivés. Pour une date de vente, Année de vente, Trimestre de vente et Mois de vente doivent tous dépendre de la même définition de date. Mélanger Année de commande et Mois de facturation dans une même hiérarchie produit une lecture artificielle que Web Intelligence ne peut pas corriger.
Éviter les ambiguïtés entre calendrier, exercice et date métier
Les calendriers de gestion sont souvent plus complexes que la hiérarchie automatique proposée lors de la création d’une dimension date. Un exercice décalé, une semaine commerciale ou une période de clôture ne se déduit pas nécessairement de la date civile. Dans ce cas, les objets Année fiscale, Période fiscale et Semaine de gestion doivent provenir d’une table calendrier validée, et non d’une fonction appliquée directement à la date transactionnelle.
La distinction entre date de réservation, date de séjour, date de vente et date de comptabilisation doit apparaître dans les noms de classes et d’objets. Une univers contenant seulement « Année » et « Mois » oblige l’utilisateur à deviner la date sous-jacente. Cette ambiguïté est l’une des Erreurs fréquentes lors d’une reprise de rapport : la cible récupère le libellé, mais pas la règle qui l’associait à une transaction précise.
Les objets qualifiés comme informations ne participent pas de la même manière à l’exploration que les dimensions et indicateurs. Une date visible comme information peut convenir à un détail de ligne, mais elle ne permet pas forcément de bâtir le chemin d’analyse attendu. Les objets impliqués dans les niveaux de hiérarchie doivent donc être qualifiés et testés comme dimensions.
Contrôler le grain avant d’autoriser le forage dans Web Intelligence
Le contrôle le plus utile consiste à comparer deux niveaux consécutifs. Prenez un indicateur, une année, puis un mois. Le total annuel doit correspondre à la somme des mois du même périmètre, sous réserve des transactions sans date ou des règles explicitement exclues. Si le total augmente lorsque vous descendez au mois, l’univers joint probablement une table de détail supplémentaire.
Une deuxième vérification porte sur les périodes incomplètes. Le mois en cours, les périodes ouvertes et les corrections tardives doivent être identifiés dans la définition du rapport. Une hiérarchie techniquement correcte peut donner l’impression d’une comparaison homogène entre une période close et une période encore alimentée. La différence n’est pas un défaut BusinessObjects ; elle doit être rendue visible dans la règle de restitution.
- Inventoriez les dates disponibles dans la fondation de données et associez chaque date à un événement métier précis.
- Décidez si le calendrier est civil, fiscal ou opérationnel avant de créer les objets Année, Trimestre et Mois.
- Testez chaque niveau avec un indicateur sensible aux doublons, tel qu’un montant facturé ou une quantité de lignes.
- Vérifiez l’ordre de tri sur une clé numérique ou une date réelle, jamais seulement sur un libellé de mois.
- Documentez les dates absentes, les périodes ouvertes et les transactions corrigées après clôture.
Cette discipline devient déterminante lors de la sortie de BusinessObjects. La conversion automatique d’un univers ne restitue pas toujours les hiérarchies métier ni leurs dépendances. Un projet de reprise vers une autre cible doit donc traiter les dimensions temporelles comme des règles de gestion, au même niveau qu’un calcul de marge.
Les hiérarchies structurent les lectures. Elles ne protègent pas contre les rapprochements issus de sources différentes. Les dimensions fusionnées répondent à ce besoin, avec des limites qu’il faut connaître avant de les multiplier dans les rapports.
Quand les dimensions fusionnées résolvent-elles un besoin et quand créent-elles un écart ?
Les dimensions fusionnées de Web Intelligence permettent de rapprocher des valeurs issues de plusieurs fournisseurs de données. Un rapport peut, par exemple, combiner un objectif commercial issu d’un fichier ou d’un univers avec un réalisé issu d’un autre univers. Le code commercial ou le mois devient alors la clé de rapprochement utilisée par le document.
Ce mécanisme est utile lorsque les sources ne peuvent pas être jointes dans le même univers, ou lorsque le rapprochement doit rester local à un rapport précis. Il ne remplace pas une Modélisation des données cohérente. Si dix rapports reproduisent la même fusion de dimensions, la règle doit probablement être déplacée dans une couche contrôlée, après examen de son périmètre et de son coût de maintenance.
Une fusion repose sur l’égalité des valeurs, mais aussi sur leur format, leur casse, leur granularité et leur unicité. « 2026-01 » dans une source et « Janvier 2026 » dans l’autre ne représentent pas automatiquement une clé commune utilisable. De même, le code produit peut être unique dans le référentiel commercial et dupliqué dans une source logistique selon l’entrepôt. La fusion rapproche alors des lignes sans résoudre l’ambiguïté de grain.
Mesurer le risque de duplication avant d’afficher un indicateur fusionné
Supposons une source A contenant un objectif mensuel par commercial et une source B contenant le chiffre d’affaires quotidien par commercial. La fusion sur Commercial sans Mois fait apparaître l’objectif sur toutes les lignes quotidiennes. Un tableau peut sembler acceptable si l’objectif est affiché une seule fois. Une agrégation de l’objectif peut néanmoins le multiplier par le nombre de jours présents.
Le contrôle doit porter sur une période fermée et sur un jeu limité. Prenez trois commerciaux, deux mois et les deux sources brutes. Comparez le nombre de clés distinctes de chaque côté. Si la source des objectifs contient six lignes et la source de réalisé soixante lignes, le rapport ne peut pas additionner indistinctement les deux mesures au même niveau de détail.
Les objets fusionnés demandent aussi une nomenclature claire. « Mois » et « Mois fusionné » ne suffisent pas dans un document contenant plusieurs fournisseurs. Le libellé doit indiquer le rôle de la clé, par exemple Mois de référence commun ou Code client de rapprochement. Cette précision évite qu’une dimension native et une dimension fusionnée soient utilisées ensemble dans le même bloc sans compréhension de leur effet.
| Situation de rapprochement | Fusion locale Web Intelligence | Risque principal | Décision de conception |
|---|---|---|---|
| Deux sources ponctuelles pour un seul rapport | Adaptée si la clé est unique et testée | Formats de clés différents | Documenter la clé fusionnée et conserver un contrôle de valeurs absentes |
| Objectif mensuel et réalisé quotidien | Possible avec précaution | Répétition de l’objectif au grain journalier | Calculer chaque mesure à son grain avant comparaison |
| Même rapprochement dans plusieurs rapports | Peu adaptée | Règle dupliquée dans chaque document | Revoir l’univers ou la couche de préparation |
| Clé client non unique selon l’entité | À éviter sans clé composite | Association de données appartenant à des périmètres différents | Ajouter l’entité, le système source ou une clé de correspondance validée |
La reprise de ces rapports vers une cible différente demande une analyse document par document. Un rapport Web Intelligence contenant trois fournisseurs de données et deux dimensions fusionnées ne se transpose pas par la seule lecture de son écran. Les requêtes, les variables, les filtres de bloc et les contextes de calcul doivent être inventoriés. La méthode de contrôle avant bascule est détaillée dans ce protocole de migration et de réconciliation BI.
La fusion reste donc une fonction de restitution, non une preuve que les sources sont intégrées. Dès qu’elle porte un indicateur de pilotage ou un chiffre financier, les clés, les valeurs non appariées et les écarts doivent être explicitement recensés. La dernière étape consiste à organiser les tests qui détectent ces défauts avant qu’ils n’atteignent les utilisateurs.
Quels contrôles empêchent les pièges courants de passer en production ?
Les Pièges courants dans BusinessObjects ne se détectent pas tous dans le Designer ou dans l’Information Design Tool. Un univers peut se vérifier techniquement, générer une requête SQL valide et rester métierement faux. La recette doit donc relier les objets d’univers, les rapports qui les emploient, les règles visibles et les règles cachées dans les expressions.
Le premier risque vient des objets qui portent une condition intégrée. Un objet « Client actif » ou « Chiffre d’affaires » peut contenir une clause WHERE qui restreint silencieusement le périmètre. Le lecteur Web Intelligence voit le nom de l’objet, pas nécessairement le SQL qui l’accompagne. Il faut extraire ces expressions dans l’inventaire de l’univers avant toute correction structurante ou migration.
Le deuxième risque vient des contextes de requête. Lorsque plusieurs chemins de jointure existent entre des tables, un contexte indique le chemin approprié selon le sujet interrogé. Un contexte Ventes et un contexte Stocks peuvent être corrects séparément. Une requête qui appelle des objets des deux contextes sans stratégie explicite peut conduire à une incompatibilité, à des requêtes séparées ou à une multiplication de lignes selon la conception retenue.
Établir une recette qui part des chiffres, puis remonte aux objets
La recette ne doit pas commencer par la liste complète des objets disponibles. Elle doit commencer par les indicateurs réellement utilisés pour piloter l’activité. Pour chaque indicateur, relevez son rapport de référence, sa période, ses filtres, sa dimension de rupture, son total attendu et la règle métier qui explique son périmètre. Le rapport fournit le point de comparaison, l’univers fournit le chemin de diagnostic.
Une tolérance doit être définie avant le test. Une absence de tolérance pousse soit à bloquer le projet pour des écarts d’arrondi, soit à accepter des écarts significatifs parce qu’ils semblent limités. Une tolérance de montant ne peut pas être reprise d’un autre projet sans contexte. Elle dépend du chiffre suivi, de son volume, de son usage financier et de la cause attendue de l’écart.
Le double run répond à une contrainte pratique. Pendant une période convenue, l’ancien et le nouveau rapport sont exécutés sur un même arrêt de données. Les écarts sont classés, expliqués et acceptés ou corrigés. L’objectif n’est pas de promettre l’identité des chiffres. Il est de borner les différences, d’en attribuer la cause et d’obtenir une décision de bascule sur des éléments vérifiables.
Préparer la reprise des dimensions vers une autre cible
Lors d’une migration vers Power BI, une dimension d’univers n’est pas automatiquement un champ de modèle sémantique prêt à l’emploi. Il faut retrouver sa source, son expression SQL, ses restrictions, sa qualification, sa liste de valeurs et son usage réel dans les documents. Une condition cachée dans l’objet doit devenir un filtre documenté, une transformation de données ou une mesure selon sa nature.
La reprise coûte plus cher que la reconstruction lorsque le parc est réduit et que les objets sont peu documentés. À l’inverse, un parc très utilisé avec des règles métier enfouies mérite souvent une reprise méthodique, car la réécriture risque de perdre des comportements consultés depuis longtemps. Le choix entre les deux n’est pas idéologique. Il dépend du nombre de rapports actifs, des dépendances d’univers et de la qualité des preuves disponibles.
Un inventaire de 120 rapports dont 70 ne sont plus exécutés ne justifie pas la reprise de chaque objet de chaque univers. Il faut d’abord distinguer l’usage réel, les rapports réglementaires ou financiers, les documents périodiques et les rapports exploratoires. Les logs d’audit doivent couvrir au moins un cycle annuel complet lorsque le parc comporte des rapports trimestriels ou annuels ; une fenêtre de 90 jours laisse mécaniquement de côté ces usages.
La cible ne doit pas être choisie avant cette classification. Un rapport Web Intelligence fondé sur des sections, des ruptures et des mises en page de diffusion peut appeler un traitement différent d’un tableau d’analyse interactif. La comparaison entre Web Intelligence et les rapports paginés Power BI aide à séparer ces deux besoins au lieu de les reprendre sous une même forme.
Avant toute modification d’univers, exportez la liste des classes, objets, conditions, contextes et hiérarchies, puis reliez-la aux rapports actifs sur douze mois. Cette action produit le périmètre sur lequel une correction, une reconstruction ou une migration peut être défendue sans masquer les règles qui font encore varier vos chiffres.
Quelle différence existe entre une dimension et une information dans BusinessObjects ?
Une dimension sert d’axe d’analyse, de filtre, de rupture ou de niveau de hiérarchie. Une information complète une dimension, comme une adresse associée à un client, mais ne doit pas porter seule une analyse multidimensionnelle.
Une dimension peut-elle contenir une expression calculée ?
Oui. Une tranche d’âge, un segment commercial ou une catégorie de produit peut être calculé dans l’univers. La règle doit être documentée, testée sur des valeurs limites et revue lorsque les seuils métier changent.
Pourquoi une dimension fusionnée peut-elle fausser un total Web Intelligence ?
Elle peut rapprocher des sources de granularités différentes. Un objectif mensuel fusionné avec un réalisé journalier risque d’être répété sur chaque jour si le calcul n’est pas effectué au bon grain.
Faut-il migrer toutes les dimensions d’un univers BusinessObjects ?
Non. La décision doit partir des rapports réellement consultés, des règles de gestion utilisées et des obligations de restitution. Les objets non utilisés ou purement techniques doivent être écartés du périmètre après vérification des dépendances.
Le dossier complet Recette & réconciliation : prouver que les nouveaux chiffres valent les anciens
