Création de tableau de bord, BI et entrepôt de données

mercredi 8 juin 2011

OBIEE et les apps en français

Un des avantages d’OBIEE par rapport aux autres produits sur le marché des entrepôts de données est son intégration aux apps (applicatif Oracle, PGI ou ERP) et Peoplesoft appelé BI-Apps.

En quelques mois notre équipe spécialisé avec les applicatifs a donné la possibilité à notre client d'explorer ses données à travers des centaines de rapports et d'indicateurs. C'est toute une réussite lorsqu'on compare le coût et les délais de mise en œuvre de l'entrepôt de données. Le client était réellement impressionné de pourvoir analyser en détails ses transactions comptables selon les segments de la charte comptable en détails puisque qu’avant elle ne pouvait les consulter que de façon agrégé par un cube Hyperion.

Voici quelques extraits d’OBIEE avec BI-Apps

Le tableau de bord d'OBIEE contient un grand nombre d'onglet pour chaque domaine d'affaires.

Pour le grand livre il présente les onglets du bilan, les flux de trésorerie, Budget / Réel, liquidité, structure financière, solde de grand livre et la balance des comptes.

Les comptes fournisseurs permettent de faire le suivit par les soldes des comptes fournisseurs, les paiements dus, des rapports permettent de faire le suivit des factures ouvertes.

Le suivi des comptes des fournisseurs et des comptes clients permet de suivre le délai de recouvrement.


Remarquez aussi qu'OBIEE couvre aussi des domaines comme l'assurance, les services financiers, les pharmacies et autres.



François Bouffard
Architecte BI et entrepôt de données Québec

mardi 24 mai 2011

Google Map et OBIEE (Oracle Business Enterprise Edition)

Google Map et OBIEE (ou Microstrategy, Tableau et autres outils) permettent d'exploiter les données de vos tableaux de bord avec Answer. Les rapports produits avec la carte Google Map sont interactifs et vous permettent d'afficher les informations de votre base de données.

Dans cet exemple nous avons sélectionné les pharmacies de la région de Québec et la carte Google Map s'est ajustée.



Toutes les fonctionnalités de base de Google Map sont disponibles, à l'intérieur du portail OBIEE, comme le zoom et l'affichage satellite. Il est possible d'ajouter les données de nos tableaux (données, calculs et images) dans des bulles d'informations.


Il est possible d'ajouter des légendes, des images personnalisées,


Un nombre représentant le nombre d'enregistrements sur un point géographique. Le nombre est éclaté au fur et à mesure que le zoom est utilisé





François Bouffard
Architecte entrepôt de données
Panoramatechnologies.com

Documentation OBIEE en français

La documentation d'OBIEE en français pour l'utilisation d'Oracle Answer est disponible pour nos clients. Le document est disponible pour 60 $ Canadiens ou 70 Euros transport inclus.

Voici un extrait:

1. Les analyses

· Les analyses

Les analyses permettent de visualiser les données dimensionnelles côte-à-côte et rapidement tout en permettant une grande gamme de personnalisation.

L'utilisateur peut glisser simplement les nouveaux champs dans les rapports.

.... fin extrait 1

· Hiérarchie OBIEE :

Dans une hiérarchie OBIEE les données hiérarchiques sont regroupées sous leur parent :
L'utilisateur peut forer ainsi afin de dévoiler les niveaux hiérarchiques dont il a réellement besoin et ne pas s’embarrasser de données moins pertinentes. Il n'y a pas de perte de temps à chercher où se trouve la bonne rangée contenant vos données car seules celles que vous aurez éclatées seront en évidences.
.... fin extrait 2

7. Le forage

 Le forage dans OBIEE sert à visualiser des détails plus précis sur certaines de nos données. Le forage peut tout aussi bien se faire à partir d’un tableau ou d’un graphique. Lorsque sélectionné il ouvre alors un nouveau rapport contenant les détails demandés. Aussi, un tableau peut devenir un graphique ou même un graphique devenir un tableau par cette méthode. Il existe 2 types de forages principaux :

· Exploration

Le forage par exploration est existant par défaut sur les colonnes d’un niveau hiérarchique. Si l’on insère dans un tableau une colonne de niveau hiérarchique alors un lien de forage d’exploration lui sera associé par défaut.

.... fin des extraits

Vous pouvez acheter votre copie par chèque au nom PanoramaTechnologies.com.

François Bouffard
Architecte entrepôt de données
Panoramatechnologies.com

jeudi 5 mai 2011

Comparatif MS Report Builder , OBIEE (Oracle Business Intelligence Enterprise édition), MS-Excel tableau croisé dynamique , Oracle Discoverer , IBM Cognos Query Studio

Lors du choix d'une interface d'exploitation pour votre entrepôt de données, il est important de considérer que vos utilisateurs désireront créer leurs propres rapports et les partager dans l'entreprise. Une panoplie d'outils sont disponibles pour les utilisateurs voici les comparaisons entre MS Report Builder , OBIEE (Oracle Business Intelligence Enterprise édition), MS-Excel tableau croisé dynamique , Oracle Discoverer , IBM Cognos Query Studio.

Les utilisateurs ne sont pas nécessairement des programmeurs et devraient avoir des outils qui leur permettent l'exploitation ad-hoc de l'entrepôt de données.

Voici le comparatif synthèse de quelques d'interface d'exploitation disponible sur le marché. Des outils comme Pentaho ont été rejetés car ils n'ont pas de couche logique en langage d'affaires une composante clef pour l'exploitation libre par les utilisateurs (et non les programmeurs). Les outils de Microsoft ont été comparés même s'ils n'ont pas de couche logique en langage d'affaires car MS-Excel est relativement répandu.


MS Report Builder malgré ses présentations attrayante ne répond pas au besoin des utilisateurs finals, ni des programmeurs qui vont préférer utiliser les outils de développement conventionnel de Microsoft. Les utilisateurs vont utiliser MS-Excel car Report Builder n'est pas orienté utilisateur. Les programmeur vont utiliser SSRS ou la suite BI qui sont orientés pour les programmeurs. D'ailleurs l'outils report builder semble peut utilisé et Microsoft offre maintenant Power Pivot.

MS-Excel (maintenant Power Pivot) est toujours populaire car il possède une interface graphique bien connu. Il est facile de se connecter aux bases de données avec cet outil. Cependant, il ne dispose pas de couche en langage d'affaires donc il nécessite l'intervention de programmeur pour créer une requête. Chacun peut créer sa propre requête donc plusieurs vérités possible pour un même besoins d'affaires.

Oracle Discoverer est toujours très populaire au Québec même s'il n'est plus supporté par Oracle à partir de 11gr1. Il possède une couche logique en langage d'affaire qui permet de masquer la complexité de la base de données à l'utilisateur en lui offrant une interface de création de rapport simple mais convivial. Il permet à l'utilisateur de partager et de publier lui même ses rapports sans l'intervention de programmeur. Il est sécuritaire car il réutilise la sécurité de la base de données et dispose en plus de sécurité dans la couche en langage d'affaires sur les fonctionnalités comme le droit de créer et de partager des rapports.

Oracle

François Bouffard
Architecte entrepôt de données
Panoramatechnologies.com

Spécialiste cognos Québec

mercredi 13 avril 2011

Entrepôt de données, Comptoirs de données, ROLAP, MOLAP, faits, dimensions et cubes : La mort des cubes


Un indicateur ou un tableau de bord est utilisé pour donner rapidement et d’un seul coup d’œil la situation de l’entreprise. Cependant lorsqu’une situation à surveiller est mise en relief par l’indicateur, l’utilisateur (décideur) doit en trouver la cause. L’indicateur doit permettre d’analyser avec plus de détail la cause du problème. Cette analyse se fait grâce à l'entrepôt de données.

Un entrepôt de données est composé du détail des mesures (faits) et des axes d’analyses (dimensions) qui ont servi à construire l’indicateur. Les dimensions sont les axes d’analyse comme la charte comptable (segments), les routes, les projets, les accidents, les produits, les dates de transactions, structure de l’organisation. Les faits sont les quantités monétaires, de dénombrement et autres calculs qui sont analysés en fonction des dimensions pour un sujet particulier comme les finances, les assurances, les écritures comptables, la facturation et les bons de commandes.

L’entrepôt de données doit être directement accessible pour l’utilisateur via une couche sémantique. C’est la composante clé de l’entrepôt de données qui permet à l’utilisateur d’exploiter au maximum l’ensemble des données existant dans l’entrepôt de données.

Un comptoir de données est un découpage logique de l’entrepôt de données selon les besoins d'affaires. Dans les entrepôts de données modernes ce découpage ne se fait pas de façon physique comme dans les années 90 et 2000, mais plutôt de façon logique. Le découpage est fait en fonction des besoins utilisateurs et non en fonction des contraintes techniques. Les contraintes techniques en mode ROLAP (Relational OnLine Analytical Processing) ont été levées grâce au schéma étoile. Les schémas étoiles peuvent avoir un nombre illimité de dimensions (axes d’analyse). Un de mes clients ministériel à un schéma étoile de 500 millions d’enregistrements avec 40 dimensions. Tous les grands fournisseurs de produit BI permettent l'exploitation ROLAP.

Un cube est un sous ensemble physique de l'entrepôt de données qui est utilisé afin d’augmenté la performance. C'est l'approche MOLAP (Multidimensionnal OnLine Analytical Processing). Le cube contient les calculs physiquement pour tous les croisements des dimensions et ce peu importe si le croisement a des valeurs significatives. La grosseur du cube est exponentiel au nombre d’enregistrements de chacune des dimensions. Donc un comptoir qui contient dix dimensions de 1000 enregistrements aura un cube de 1 x 10 30 valeurs (catégories). Les cubes sont limités et permettent seulement un nombre restreint de dimensions (axe d’analyse).

Pour obtenir des cubes de grosseur raisonnables il faut donc limiter le nombre de dimensions utilisés. L'approche agrégée par cube apporte donc des problèmes de silos de données. Des silos apparaissent par exemple lorsqu'on ne peut pas croiser les données de budget avec les données de transactions réelles. Pourtant ces deux faits (budget et transaction) ont la majorité des dimensions en commun (date, segments comptables, période comptables etc) et on devrait pouvoir les comparer et y faire des calculs rapidement et facilement. Une mauvaise architecture de données à causé se problème à un ministère qui devait comparer ses données de bon de commande (engagement), de facturation (réel) et de budget. Les trois faits, engagement, réel et budget avait été séparés dans des cubes différents rendant de simple calcul comme le budget disponible  (budget – engagement – réel = budget disponible) impossible.  Une bonne architecture ROLAP a permit d’intégrer ces notions dans une seule table de fait et de permettre les calculs pour les gestionnaire et utilisateurs de façon convivial. Ces calculs sont importants puisque le ministère gère plusieurs milliards de dollars par année.

C'est là que l'entrepôt de données avec ces comptoirs de données se différencie des cubes. Si les comptoirs sont biens construits ils partagent entre eux des dimensions conformes qui permettent de croiser les données d'un fait à l'autre. Les comptoirs n'ayant pas de limitation au niveau des dimensions disponibles permettent des croisements de données précis.

Des essaies ont été fait pour croiser d'un cube à l'autre via les dimensions des cubes. Ces essaies sont la plus pars du temps vain car les cubes sont limités dans le nombre de dimension disponibles et les dimensions communes entre les deux cubes ne permettent pas d'obtenir des résultats significatifs. Le forage vers le détail des cubes est aussi souvent problématique. Afin de pouvoir construire un cube qui respectent les contraintes physiques du cube, les dimensions sont souvent dénaturées et agrégées et non conformes d'une table de faits à l'autre. Le détail permettant de cibler une transaction est ainsi perdu.

Les cubes sont donc des objets indépendants sans relations entre eux qu'on nomme des silos. Cette approche est très problématique dans les organisations d'aujourd'hui où toutes les données doivent être croisées pour faciliter le processus de décision.

Le cube est un objet propriétaire qui peut-être exploité par un nombre limité d’outil. De plus le cube est une copie supplémentaire des données qui doit-être généré, souvent à partir de l'entrepôt de données, rajoutant une étape supplémentaires à la fin de l'ETL.

Les utilisateurs désirant avoir accès à toutes les données et leur détaille préfèrent donc travailler dans un environnement ouvert et non compartimenté en silo. Les outils courant du marché ont tous ouverts leurs solutions BI à l’exploitation directe sur les comptoirs de données.

Dans ce contexte on peut prévoir une utilisation des cubes de moins en moins fréquente.

Les cubes peuvent être utiles dans les petites organisations où le volume de données, le nombre de dimension et le nombre d'occurrences des dimensions est faible. Les cubes peuvent aussi compenser pour les lacunes en architecture de données puisqu’ils offrent un cadre relativement rigide où les notions de dimensions et de tables de faits ne peuvent pas être ignorées.