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.
