OBIEE - Hiérarchies avec Oracle Business Intelligence Enterprise Edition 11.1.1.7

Une hiérarchie est un ensemble de liens logiques entre les données permettant de les classer, un exemple de hiérarchie est le pays, la province et la ville. Une hiérarchie de date pourrait contenir l'année, le mois et le jour.

La hiérarchie permet d':

- Agréger les données par exemple par jours, par mois, par l’année.
- Forer vers le détail, exemple de l'année vers le mois vers le jour.


Données agrégé par année (somme par an)

   
Ici, je présente les mêmes données mais détaillées par mois en utilisant le forage sur les années. Notez qu'en utilisant OBIEE le forage du rapport est dynamique et peut-être réaliser par l'utilisateur simplement en :

 - Cliquant sur l'icône de forage ( développer )

 - Cliquant sur l'icône agréger ( réduire )

Le niveau supérieur de la hiérarchie est le parent. Les niveaux subséquents sont les enfants. Ainsi dans la hiérarchie de temps l'année est le parent l'année et les enfants sont les mois et les jours.

Lorsque vous travaillez à élaborer un rapport et que votre source de données provient d'un système relationnel, les hiérarchies sont très utiles. Oracle Business Intelligence Enterprise Edition (OBIEE) 11.1.1.7 offre la possibilité de créer des hiérarchies.

Dans le domaine de la comptabilité et du suivi de budget les hiérarchies servent à organiser les segments de la charte comptables en champs indépendants afin de pouvoir regrouper ou détailler les données sur divers niveau.

Au niveau de la disposition, j'ai glissé avec ma souris le code du niveau un, trois et six de l'entrepôt de données ( voir l'image ci-dessous. ) Ils vont s'afficher dans le rapport, mais aucune hiérarchie n'y sera présente. De plus, comme ils ne sont pas liés, je dois les glisser un par un.

Nous avons ici la possibilité de créer une hiérarchie de 6 niveaux soit par les champs noms et/ou les champs codes de l'unité administrative.

Voici un rapport sans hiérarchie:

Pour créer une hiérarchie avec OBIEE, il faut d'abord se connecter sur le serveur et utilisé l'outil Administration OBI pour modifier la couche logique dans la section modèle de gestion et correspondance.

Couche logique de l'outil d'administration OBI

Enfin, toujours dans la couche logique, voici maintenant les dimensions avec une hiérarchie :

Hiérarchie unité administrative de six niveaux

Lorsque l'on utilise une hiérarchie, la relation entre les niveaux est toujours présente. Lorsque l'on passe d'un niveau inférieur à niveau supérieur, un signe + apparaît.

Retournons maintenant à OBIEE au niveau de l'analyse c'est-à-dire dans le rapport dynamique.

La hiérarchie est bien en place et permet de faire des tableaux croisés dynamiques.

Si vous souhaitez en apprendre plus sur Oracle Business Intelligence Enterprise Edition (OBIEE) 11.1.1.7, nous avons des formations pour vous. Vous pouvez visiter notre site :

http://www.panoramatechnologies.com

Panorama Technologies
Spécialiste en BI et tableau de bord au Québec

Autres articles:

Utiliser OBIEE
Les hiérarchies avec PowerPivot pour Excel 2010

Les hiérarchies avec Tableau Desktop 8.0

Analyste d’affaires spécialisé BI, est-ce nécessaire ?

On me pose souvent la question : « Est-ce que l’analyste d’affaires doit avoir des connaissances de l’intelligence d’affaire (BI) ? ». Voici un exemple concret qui différentie le résultat obtenu par l’analyste d’affaires et l’analyste d’affaires BI.

Partons d'un cas vécu dans un ministère au Québec qui gère plusieurs milliards de dollars annuellement.

L’analyste d’affaires recherche et analyse les processus. Pour l’analyste d’affaires les processus sont le centre de son analyse et les composantes informatiques résultantes en seront directement découlées. Par exemple, en comptabilité l’analyste d’affaires trouvera le processus du budget et de la comptabilité du réel au jour le jour. Donc deux processus sur lesquels les étapes subséquentes de l’architecture et de l’implantation seront basés.

Pour l'analyste d'affaires il y a 2 processus qui vont découler de deux comptoirs de données.

L’analyste d’affaires BI recherche et analyse aussi les processus mais en fonction des données. Pour l’analyste d’affaires BI les données primes sur les processus, le cas 2.

 Pour l'analyste d'affaires BI il y a 1 processus qui va découler en un comptoir de données.

Cette différence dans l’analyse d’affaires impose un biais qui a un impact important dans l’entrepôt de données. Ce problème est typique et souvent rencontré dans les organisations.

Dans notre exemple, l’analyse d’affaires du cas 1 résultera en deux silos. Il sera difficile d’avoir des réponses pour des ratios et calculs pour des questions simples comme quelle est l’argent disponible à un moment donné (le budget moins le réel). L’entrepôt de données ne répond pas à des besoins d’affaires simples et vitaux pour l’organisation.

Cas 1 - Silo

Le cas 2 résultera en un comptoir intégré avec le budget et le réel. Il sera facile de faire tous les calculs et ratios entre les deux processus.

Cas 2 - Modèle étoile intégré

On voit donc l’impact majeur des deux types d’analyse. Cette exemple est basé sur un cas vécu dans un important ministère au Québec. Il y avait plusieurs processus comptables : budget, réel et engagement. Et pour chacun l'analyste d'affaires et l'architecte de données avaient demandé la création de silos. Le spécialiste de Panorama Technologies a corrigé le problème au niveau de l’architecture de données afin de créer un seul comptoir intégré contenant tous les processus. Ce comptoir répondait si bien aux besoins qu'il est passé d’une utilisation nulle à un déploiement provincial tant au niveau ministériel, des directions générales que des directions territoriales et services du ministère.

François Bouffard
Analyste d'affaires BI
Panoramatechnologies.com