Netapsys Blog - Business Intelligence

[Palo Global Roadshow 2010] Palo 3.1 - Une stratégie orientée vers les environnements web intégrés

Alexis Rousset — Mon, 19 Apr 2010 12:40:00 +0200

Le 14/04/2010 a eu lieu à Paris le Palo Global Roadshow 2010 organisé par Jedox pour présenter la nouvelle version de Palo. Netapsys était bien entendu présente à cet évènement pour guetter les nouvelles offres des éditeurs Open Source dans le domaine de la Business Intelligence.

Palo est un des seuls éditeurs de serveur de base données OLAP Open Source. Je vous vois déjà venir en me disant que j'oublie très certainement Mondrian, pourtant difficile de comparer ces deux outils puisque qu'ils ne jouent pas tout à fait dans la même cour. Palo est un serveur OLAP de type MOLAP alors que Mondrian est un serveur de type ROLAP, ce qui signifie que Mondrian se base simplement sur une base de données relationnelle pour simuler un cube alors que Palo est une véritable base de données multidimensionnelle.

En plus de son moteur OLAP qui est sans aucun doute son cœur de métier, Palo semble s'étendre de plus en plus vers le concept de plateforme BI. Son offre s'est très largement élargie en proposant des outils d'ETL, de reporting et d'analyse.

Palo est un outil à ne pas perdre de vue puisqu'il permet d'obtenir des performances intéressantes et qu'il s'interface très largement avec le fameux logiciel Microsoft Excel, que la majorité des utilisateurs utilisent déjà pour faire des analyses.

Les nouveautés dans la version 3.1 de Palo peuvent se résumer en 3 grands points :

Tout d'abord, il est énoncé une amélioration de "la performance et de la stabilité". Difficile encore d'avoir un vrai retour sur ces aspects mais il semblerait que ce soit effectivement le cas au dire de certains utilisateurs.
Palo Web : Un des objectifs majeurs de Palo 3.1 a été d'intégrer dans une seule interface web l'ensemble des composants (ETL, Spreadsheet, Pivot). Le très gros point fort est d'offrir à l'utilisateur un environnement totalement similaire à Excel mais dans un navigateur Web. Palo permet ainsi à l'utilisateur de rester dans un environnement connu et facilite la maintenance et le déploiement de la solution.
Palo OLAP GPU : Un nouveau composant fait son apparition en version Beta. Palo OLAP GPU permet d'utiliser la puissance de calcul des processeurs de carte graphique pour gagner en performance. Les processeurs de carte de graphique sont en effet "optimisés pour le calcul parallèle de données et sont ainsi idéaux pour calculer rapidement des requêtes complexes telles qu’on en rencontre dans les applications de Business Intelligence".

Jedox Palo a une ligne directrice et des objectifs bien définis et clairs qui peuvent donner toute confiance dans l'évolution de cet outil.

Navigation au sein d'un Cube OLAP

Alexis Rousset — Thu, 28 May 2009 14:01:00 +0200

Un des principaux points de la Business Intelligence est l’analyse multidimensionnelle. Il devient primordial de pouvoir étudier une même information suivant différents axes. Par exemple, il est très intéressant pour une entreprise de pouvoir interpréter son chiffre d’affaires par zone géographique, par période temporelle, par produit, par client…

Un moyen pour effectuer ces analyses est d’utiliser des cubes (ou hyper cube). Un cube permet de stocker une information et de la lier à plusieurs dimensions afin d’effectuer des analyses en fonction de celles-ci. Je vous propose dans ce post de nous intéresser à différentes façons de naviguer au sein d’un cube afin de récupérer une information.

Il existe un certain nombre d’outils graphiques, souvent spécifiques aux éditeurs du cube, qui offrent la possibilité de naviguer facilement au sein de celui-ci. Dans ce post, je ne vais parler que de l’outil appelé JPivot qui permet de naviguer au sein d’un cube Mondrian.

Il existe aussi un langage spécifique à la navigation multidimensionnelle : le langage MDX. Ce langage peut être comparé au SQL pour les bases relationnelles. Je vous propose donc de présenter ensuite quelques bases du MDX.

JPivot

JPivot est un moyen simple pour un utilisateur non informaticien d’obtenir une information à partir d’un cube, il permet de transcrire des actions graphiques en requête MDX.

L’outil JPivot présente le cube sous forme de tableau croisé. Il permet d’insérer en abscisse ou en ordonné les différentes dimensions afin d’étudier les mesures du cube.

Regardons pour commencer une petite vidéo pour ressortir le Chiffre d’affaires par Produit et par marché sur différentes années : http://blog.netapsys.fr/public/images/BI/video/JPivot_skin.swf

Comme vous pouvez le voir, rien de plus simple pour obtenir l’information que l’on souhaite. On peut grâce à cet outil accéder à toutes les informations contenues dans le cube. Cependant, cet outil qui a été développé dans le but de rester simple et facile d’utilisation ne permet pas de profiter de toutes les possibilités qu’offre le langage MDX. Il est donc intéressant d’avoir quelques bases sur ce langage afin de répondre à des besoins parfois plus spécifiques.

Les bases du MDX

Je vous propose de décortiquer la requête qui a été générée par JPivot dans la vidéo. Pour faciliter l’explication, cette requête a été un peu simplifiée.

SELECT 
	Crossjoin([Time].[All Years].Children,{[Measures].[Quantity]})
	ON COLUMNS,
	Crossjoin([Markets].[All Markets].Children, [Product].[All Products].Children)
	ON ROWS
FROM [SteelWheelsSales]

Résultat :

Pour ceux qui connaissent le SQL, je pense que vous ne serez pas perdus. En effet, il y a beaucoup de ressemblances, vous verrez cependant que ce langage offre des nouvelles possibilités grâce à certaines fonctions très intéressantes que je détaillerai un peu plus bas.

La requête est séparée en plusieurs parties : SELECT, FROM, WHERE.

SELECT

La principale différence avec le SQL vient justement du SELECT qui demande des informations sur les champs à mettre en colonne et des informations sur les champs à mettre en ligne. C’est ce qui est interprété avec les tags ON COLUMNS et ON ROWS.

Nous avons donc
Crossjoin([Time].[All Years].Children,{[Measures].[Quantity]})
en colonne et
Crossjoin([Markets].[All Markets].Children, [Product].[All Products].Children)
en ligne.

La fonction Crossjoin() permet de croiser les données sur les axes et donc d’avoir cet aspect d’arborescence dans le tableau. Nous voyons pour les lignes que nous croisons les Marchés avec les Produits, et pour les colonnes nous croisons le Temps avec la mesure Quantité.

Attention cependant, il est interdit de mettre des champs d’une même dimension en ligne et en colonne. Par exemple, il n’est pas possible d’indiquer

SELECT
	[Time].[All Years].Children ON COLUMS,
	[Time].[All Years].[Months].Children ON ROWS
FROM ...

Pourquoi ? Tout simplement parce que ceci n’a aucun sens. Une information n’est liée qu’une seule fois à une dimension.

FROM

Le champ FROM permet simplement d’indiquer le cube que nous souhaitons utiliser, au même titre que les tables en SQL.

WHERE

Le champ WHERE, qui n’est pas présent dans cet exemple de requête, permet d’indiquer des conditions sur les dimensions non présentes dans le champ SELECT.

Quelques fonctions utiles en MDX

La fonction Children

Vous avez sans doute remarqué que les dimensions dans la requête se terminent par .Children. Cette fonction retourne les enfants d’un membre d’une hiérarchie.

Dans notre cas la hiérarchie « Time » était de cette forme :

Time
|
`-- All Years
	|
	`-- 2003
		|
		`-- Janvier
		|
		`-- Février
		|
		`-- …
	|
	`-- 2004
		|
		`-- Janvier
		|
		`-- Février
		|
		`-- …
	|
	`-- 2005

[Time].[All Years].Children retroune donc 2003, 2004, 2005 alors que [Time].[All Years].[2003].Children aurait retourné Janvier, Février, Mars, …

Le mot clé NON EMPTY

Il arrive parfois que des membres d’une hiérarchie ne contiennent pas de valeur. Le mot clé NON EMPTY permet d’éliminer les cellules qui sont vides. Si, par exemple, il n’y avait pas eu de vente en 2004, la requête ci-dessous n’aurait pas affiché la colonne 2004.

SELECT 
	NON EMPTY Crossjoin([Time].[All Years].Children,{[Measures].[Quantity]})
	ON COLUMNS,
	Crossjoin([Markets].[All Markets].Children, [Product].[All Products].Children)
	ON ROWS
FROM [SteelWheelsSales]

La fonction Order()

La fonction Order() permet, comme son nom l’indique, de classer les éléments en sortie. Cette fonction attend au moins 2 paramètres :

Les membres à classer
La mesure qu’il faut prendre en compte pour les classer
(Facultatif) le mot clef DESC, si l’on souhaite les classer par ordre décroissant.

La requête ci-dessous aurait classé les lignes par marché en fonction de la quantité vendue dans l’ordre croissant :

SELECT
	Crossjoin([Time].[All Years].Children, {[Measures].[Quantity]}) ON COLUMNS,
	Crossjoin(
		Order([Markets].[All Markets].Children, [Measures].[Quantity]), [Product].[All Products].Children
	) ON ROWS
FROM [SteelWheelsSales]

La fonction Topcount()

La fonction Topcount() est une amélioration de la fonction Order(). Cette fonction trie un jeu en ordre décroissant et retourne le nombre spécifié d'éléments avec les valeurs les plus élevées.

La requête ci-dessous permet de ne sélectionner en ligne que les 2 produits avec la plus grande quantité vendue par marché.

SELECT
	Crossjoin([Time].[All Years].Children, {[Measures].[Quantity]}) ON COLUMNS,
  	
	Crossjoin(
		[Markets].[All Markets].Children,
		Topcount([Product].[All Products].Children, 2.0, [Measures].[Quantity])
	) ON ROWS
FROM [SteelWheelsSales]

Le langage MDX offre encore bien d’autres fonctionnalités que je n’ai pas présentées ici. Si vous souhaitez en connaître d’avantage, je vous conseille d’aller voir la documentation de msdn qui est très complète : http://msdn.microsoft.com/fr-fr/library/ms145506.aspx.

Pentaho et les Cubes

Alexis Rousset — Wed, 06 May 2009 09:28:00 +0200

Dans ce post je vous propose de présenter la création d’un cube dans la suite Pentaho. Nous aurons l’occasion de parler de l’outil Mondrian incorporé dans Pentaho et de l’utilitaire Schéma Workbench.

La suite Pentaho se base sur l’outil Mondrian pour l’analyse multidimensionnelle. Mondrian fait partie des cubes de type R-OLAP (Relational Online Analytical Processing), c'est-à-dire qu’il se base sur une base de données relationnelle et transcrit des requêtes MDX (Multidimensional Expressions) en requêtes SQL. La base de données doit avoir une topologie en étoile (comme celle dans l’exemple ci-dessous) ou en flocon afin de coller à l’analyse multidimensionnelle.

Mondrian a comme avantage d’être facilement et rapidement applicable dans une solution. En contre partie, de par son type R-OLAP, il se trouve parfois limité en terme de performance. Il existe cependant des moyens pour pallier en partie ces faiblesses.

Contexte

Pour créer notre cube nous avons besoin :

D’une table de fait
De dimensions
De hiérarchies
De mesures

Nous allons nous baser sur un petit exemple, ci-dessous le diagramme de la base de données.

La table de fait est la table centrale dans la topologie de la base relationnelle, elle est liée aux différentes dimensions avec des clés étrangères et contient les mesures à calculer.
Les dimensions contiennent les hiérarchies linéarisées.

Création d’un cube (Schéma Workbench)

La création d’un cube au sens Mondrian est tout simplement la rédaction d’un fichier XML. Ce fichier permet de lier les informations du cube que nous souhaitons faire apparaître et la base de données. Pour faciliter la création de ce fichier, nous allons utiliser l’outil Schéma Workbench qui offre une interface graphique pour effectuer cette tâche.

Après avoir configurer dans les « Préférences » la base de données sur laquelle nous souhaitons nous baser, nous pouvons commencer à créer notre cube.

Je vous propose de regarder la vidéo pour suivre les différentes étapes. Vidéo disponible à l’adresse : http://blog.netapsys.fr/public/images/BI/video/schemaWorkbenchCube_skin.swf

Introduction à l'ETL Talend

Alexis Rousset — Fri, 17 Apr 2009 14:39:00 +0200

Présentation du contexte

Dans ce post je vais présenter quelques fonctionnalités de Talend en me basant sur un exemple simple.

Il me permettra de parler de :

La création de metadonnées
La création d'un job
L'utilisation des tables
La transformation sur un champ
La jointure entre tables
L'insertion des données dans une table
Le lancement d'un job

Le but de l'exemple est de remplir une table contenant pour une zone de nom de domaine les informations sur son Top-Level-Domain, son continent et le nom de son pays si il y a lieu.

Nous possédons pour cet exemple :

une table « zone » contenant toutes les zones sur lesquelles nous souhaitons associer les informations
une table « zone_tld » avec pour chaque zone le top-level-domain correspondant
une table « continent_country » avec pour chaque code pays le continent correspondant et le noms du pays.

Nous souhaitons créer une table avec comme information : zon_id, zon_name, zon_tld, zon_extension, zon_country_name, zon_continent.

Creation des Metadonnées

Tout d'abord, il faut créer une connexion à la base de données comme indiqué sur l'image ci-dessous.

Ensuite, il faut insérer les tables que nous souhaitons utiliser. Il suffit de sélectionner la base que nous venons d'ajouter et de cliquer sur "Retrieve Schema" afin de choisir les tables dans la liste qui est proposée.

Les tables ajoutées apparaissent dans l'arborescence de gauche.

Création d'un Job

Il est maintenant nécessaire de créer un job. Pour cela, rien de plus simple : sélectionnez "Job Design", clic droit puis "Create Job". Il ne vous reste plus qu'a indiquer le nom du job.

Insertion des tables à utiliser

Nous allons maintenant insérer dans le job les tables dans lesquelles nous souhaitons récupérer les informations. Il suffit d'aller dans les metadata que nous avons créées et de glisser/déposer les tables à utiliser dans la zone de travail. Il faut ensuite sélectionner le type d'utilisation de la table, si c'est une entrée depuis cette table (Input) ou une sortie vers cette table (Output). En gros, Input pour faire des SELECT et Output pour des INSERT ou UPDATE.

Dans notre cas, nous insérons les tables comme ci-dessous :

Transformation sur un champ

Dans la table zone_codump, il y a toutes les zones que nous souhaitons traiter. Les zones sont par exemple : FR, TM.FR, COM.FR, ASSO.FR, PRESSE.FR ... Notre but est de récupérer la dernière extension des zones pour l'indiquer dans le champ zon_extension de la table finale.

Pour cela, nous allons utiliser l'outil tMap afin de gérer cette transformation. Il suffit de sélectionner dans la liste de droite l'outil "tMap" de la catégorie "Processing" puis de le déposer dans l'espace de travail. Il faut ensuite créer le lien entre la table zone_codump et le tMap.

Double cliquez sur le tMap afin de le configurer puis cliquez sur le "plus" de la colonne de droite pour ajouter une sortie. Il ne vous reste plus qu'a indiquer le nom de la sortie.

Par de simples glisser/déposer, ajoutez les colonnes que vous souhaitez récupérer. Dans notre cas, nous prenons zon_id et zon_name, puis nous ajoutons un champ (en cliquant sur le + de l'encadré en bas à droite) afin de récupérer l'extension de la zone.

Le champ zon_extension que nous venons de rajouter est pour le moment vide. En cliquant sur le bouton "..." de la cellule Expression de la ligne correspondant à notre champ, nous allons pouvoir inscrire du code java qui va nous permettre de récupérer l'extension. Dans notre cas nous utilisons le code suivant :

row1.zon_name.lastIndexOf('.') != -1 ? row1.zon_name.substring(row1.zon_name.lastIndexOf('.')+1) : row1.zon_name

Nous avons donc maintenant pour chaque ligne : zon_id, zon_name et zon_extension.

Jointure entre des tables

Afin de retrouver pour chaque zone le top-level-domain, le continent et le nom du pays, nous avons besoin de lier les tables entre elles. Pour faire cette opération nous allons encore utiliser l'outil tMap. Procédez comme à l'étape précédente afin d'ajouter le composant puis liez le composant avec les différentes tables.

Double cliquez sur le tMap afin de le configurer. Pour créer les jointures il suffit de prendre un champ et de le déposer dans la cellule Expr. Key. Les jointures ne sont pas des "inner join" par défaut, il est possible de paramétrer la jointure en utilisant le menu "Unique Match" et la case à choser "Inner Join". Une fois les jointures mises en place nous arrivons à l'état ci-dessous.

Insertion des données dans une table

Nous allons maintenant gérer les données qui vont être insérées dans la table finale. Pour cela nous commençons par créer le lien de sortie du dernier tMap puis nous le lions avec la dernière table. A la question "Do you want to get the schema of the target component ?" nous répondons "Yes", cela permet de pré-remplir les champs à insérer dans la sortie "Out" que nous avons créée.

Il ne nous reste plus qu'a glisser/déposer les informations que nous souhaitons insérer dans chaque champ.

Pour gérer le fait que toutes les zones n'ont pas forcement de continent ou de nom de pays associé nous mettons une petite condition sur ces deux champs afin de leur définir une valeur. Nous pouvons par exemple faire pour le champ zon_continent : row3.continent != null ? Row3.continent : "Non défini"

Lancement du job

Notre Job est maintenant terminé et ressemble à :

Pour lancer le job il suffit d'aller dans l'onglet Run de l'encadré du bas et de cliquer sur "Run". Il est possible de faire quelques configurations comme cocher la case "Statistique" qui permettra d'afficher l'avancement du processus en indiquant le nombre de lignes traitées.

BI - Open Source vs Propriétaire

Alexis Rousset — Wed, 01 Apr 2009 10:23:00 +0200

Etat du marché

Je vous propose, pour commencer, de faire un petit tour du marché actuel de la BI en comparant différents produits open source et propriétaires.

Ci-dessous, un tableau créé à partir de mon expérience personnelle (pour les fonctionnalités qui ont été testées) et des informations que j'ai pu récupérer sur le site des éditeurs (pour les fonctionnalités non testées).

Les principaux outils testés pris en compte dans l’étude sont les suivants :

Open source : Pentaho, SpagoBI, JasperSoft
Propriétaire : BusinessObject, SAS, Cognos

Une première conclusion : les produits open source remplissent les fonctionnalités majeures des projets BI. Ils couvrent ce large panel avec plus ou moins de facilité de prise en main, mais sont capables de répondre à la plupart des besoins des projets de Business Intelligence.
Il faut cependant admettre que l'ergonomie est souvent plus travaillée dans les produits propriétaires. On peut prendre l'exemple du reporting ad-hoc qui touche directement l'utilisateur final : cette fonctionnalité implémentée dans les produits open source n'égale pas les produits propriétaires en matière d'ergonomie, de facilité d'utilisation ou de résultat. On regrettera, par exemple, l'impossibilité d'ajouter des graphiques dans le reporting ad-hoc de Pentaho.

D'autre part, une différence majeure se situe sur les fonctionnalités plus spécifiques aux différents métiers qui sont développées par les éditeurs propriétaires.
En effet, les produits open source restent généralistes et ne proposent pas d'outils adaptés spécifiquement à un métier. Des outils comme SAS Human Capital Management ou IBM Workforce Performance, pour les ressources humaines, offrant aux entreprises une solution dite complète et rapide d'installation, sont inexistants en open source. Il en est de même pour les domaines du CRM (Customer Relation Ship Management) et de la gestion des Achats.
On peut cependant s'interroger sur la réelle utilité de ces logiciels. Sont-ils suffisamment adaptables à chaque entreprise ? Ne sont-ils pas des moyens commerciaux pour appâter les clients et des « gadgets » au final ?

Pour conclure, je pense que les produits open source ont la capacité de répondre à un grand nombre de besoins en matière de Business Intelligence. Ils sont cependant limités dans les domaines du reporting ad-hoc et sont plus adaptés pour des accès via des portails.

Open Source Avantages / Inconvénients ?

Les interrogations les plus fréquentes en matière d'utilisation de produits open source sont les suivantes :

Interrogation sur la pérennité ?
Interrogation sur la documentation et le support ?
Interrogation sur la complexité ?

Chacune de ces interrogations doit être étudiée au cas par cas suivant les solutions envisagées. Voici notre tableau de synthèse concernant les outils de BI open source :

Avantages

Coût minimum : Atout majeur incontesté.
Adaptabilité : Les outils n'ont normalement pas de restriction de connectivité avec d'autres produits (en théorie), contrairement aux produits propriétaires qui ont souvent des contrats avec d'autres produits.
Idéal pour la création de prototype : Pas besoin de prendre de période d'évaluation parfois trop courte pour tester le produit.
Contrôle sur le produit final : Les outils propriétaires ont majoritairement un grand nombre d'assistants ce qui peut être au détriment du contrôle sur le résultat.
Normalisation : Les outils open source sont par définition « ouverts » en utilisant des normes communes contrairement aux outils propriétaires qui ont parfois tendance à renfermer les utilisateurs sur leurs produits.

Inconvénients

Pas d'obligation de résultat : Malheureusement si ça ne marche pas il est difficile de se plaindre comme on pourrait le faire vis-à-vis d’un éditeur.
Délai d'ajout de nouvelles fonctions : Bien que certaines communautés soient très actives, il est parfois difficile d’avoir une visibilité fine sur le planning de développement.
Mise à jour parfois instable : Cela peut aussi arriver chez les propriétaires, mais c'est tout de même moins fréquent.
Ergonomie : Les utilisateurs finaux ont souvent plus de facilité à prendre en main un produit d'un éditeur propriétaire.

Les étapes et notions d'un projet BI

Alexis Rousset — Fri, 27 Mar 2009 14:54:00 +0100

Tout d'abord pour bien commencer le sujet et poser le contexte je vous propose une définition de la Business Intelligence aussi connue sous le nom d'informatique décisionnelle :

L'informatique décisionnelle désigne les moyens, les outils et les méthodes qui permettent de collecter, consolider, modéliser et restituer les données immatérielles d'une entreprise en vue d'offrir une aide à la décision et de permettre aux responsables de la stratégie d'entreprise d'avoir une vue d'ensemble de l'activité traitée. Source Wikipédia

Dans ce post je vais présenter les différentes étapes qu'il est nécessaire de mettre en place dans une chaine décisionnelle afin de profiter pleinement et efficacement d'une plateforme de business intelligence. Le but étant de comprendre le rôle et l'intérêt de chacune des étapes afin de saisir l'importance de celles-ci.

Les étapes

La chaîne décisionnelle comprend différentes phases :

La phase d'alimentation : Cette phase va faire intervenir des processus ETL qui se chargeront de récupérer toutes les données nécessaires depuis les différentes sources de stockage.
La phase de modélisation : Cette phase est le moment où les données sont stockées sous une forme adaptée pour les analyses que nous souhaitons effectuer. Elle contient notamment le datawarehouse chargé de centraliser les données. Elle fait aussi intervenir les notions de cubes et de datamarts nécéssaire pour coller au plus près des attentes métiers.
La phase de restitution : C'est dans cette phase que les différents outils de restitution vont intervenir. Nous trouverons des outils de reporting, des portails d'accès à des tableaux de bord, des outils de navigation dans des cubes, ou des outils de statistiques.
La phase d'analyse : C'est dans cette phase que les utilisateurs finaux interviennent et analysent les informations qui leurs sont fournies. Elle peut aussi faire intervenir des spécialistes en analyse pour utiliser des outils de statistique et ressortir des prévisions ou des estimations futures (datamining).

Les processus ETL

Les processus ETL (Extraction, Transformation et Chargement) sont en charge de récupérer les données depuis l'ensemble des sources opérationnelles existantes et de les charger vers le système décisionnel :

Extraction de données des bases de données opérationnelles (ERP, SGBDR, fichiers en dur, etc.)
Transformation de ces données pour nettoyer, conformer, standardiser, documenter, corriger et dé dupliquer.
Chargement des données dans le système décisionnelles : Datawarehouse, Datamarts, ou Cube.

Pourquoi est-il intéressant d'utiliser un outil ETL ?

Les données à traiter pour les systèmes décisionnelles sont généralement très volumineuses, les ETL sont adaptés à cette volumétrie en croissance exponentielle.
D'autres part, les ETL proposent un grand nombre de composant permettant de se connecter facilement à tout type de source. Ils implémentent aussi des outils qui offrent des services annexes comme par exemple un envoi d'alertes pour prévenir les administrateurs en cas de problèmes.
La représentation graphique des scripts offre une prise en main facile et rapide. Ces outils permettent de clarifier et standardiser les processus ce qui est un gain en matière d’évolution et de maintenance du système.

Le Datawarehouse

Le Datawarehouse est le point de stockage de toutes les données utilisées par le système pour analyser les informations. Il assure dans un premier temps une étanchéité entre le système opérationnel et le système décisionnel. Il n’y a donc pas de risque que les outils décisionnels affectent les performances du système déjà en place.

Il suit 4 grands principes :

Orienté métiers : C'est à dire que sa structure est conçus en fonction des besoins utilisateurs. Il se base généralement sur une topologie en étoile et va privilégier les performances de réponse au détriment de la normalisation.
Non volatile : Un datawarehouse est dans son utilisation une base en lecture seule.
Intègre : Nécessaire pour obtenir des résultats fiables et cohérents.
Historisé : Toutes les informations sont datés et aucune n'est supprimés.

Son unicité permet une centralisation et une uniformisation de l’information au sein de l’entreprise. Tous les services pourront se baser sur une information commune et sûre.

Les Datamarts

Les datamarts peuvent être considérer comme un sous ensemble du datawarehouse. De ce fait il suivent les mêmes principes que celui-ci, leur différence se situe sur le fait qu'un datamart va répondre à un besoin métier plus spécifique que le datawarehouse.

Les Cubes

Les Cubes OLAP (ou hypercubes) permettent une représentation multidimensionnelle de l'information et le calcul de mesures aggrégées.

Chaque dimension a la possibilité d'être hiérarchisée en fonction des besoins de l'utilisateur. Une dimension temps pourra par exemple utiliser la hiérarchie : Année, Trimestre, Mois, Semaine.

Il est ainsi possible d’accéder facilement et rapidement à l'information souhaiter en fonction de plusieurs dimensions. La navigation au sein d'un cube peut être faite soit en utilisant le langage MDX (Multidimensional Expressions), soit à travers des outils proposant des interfaces intuitives ne nécessitant pas de connaissance spécifique en informatique.

Le Reporting

Les outils de reporting permettent de restituer les données sous forme de rapport. Il existe deux grand domaines dans le reporting : le reporting ad hoc et le reporting de masse.

Le reporting ad hoc offre la possibilité à l’utilisateur de créer lui-même le rapport qui l’intéresse avec les données qu’il souhaite. L’utilisateur aura accès à des vues métiers spécialement conçu en fonction de ses besoins qui lui permettront de choisir facilement l’information qu’il souhaite. Aucune connaissance en base de donnée n'est nécessaire, les vues font la passerelle entre les données stockés et les besoins de l’utilisateur.
Le reporting de masse quant à lui va permettre de créer à l’avance des modèles de rapport qui seront susceptible d’être souvent demandé par les utilisateurs. Le reporting de masse permet de répondre rapidement à un besoin régulier de beaucoup d’utilisateurs.

Le Datamining

Les outils de datamining ouvrent de nouvelles perspectives sur l’utilisation de la masse d’information disponible dans le système opérationnel. Le datamining est l'utilisation d'outils statistiques ou d'algorythmes mathématiques sur les données afin de prédire, expliquer, ou de classer des informations. Les outils sont variés, on peut citer : la régression linéaire multiple, les arbres de décisions, les réseaux de neurones...