Solutions Open Source de Business Intelligence ETAT DE L'ART

(1)

Business Intelligence

ETAT DE L'ART

(2)

Préambule

ADULLACT

ADULLACT est une association régie par la loi du 1er juillet 1901 et le décret du 16 août 1901, ayant pour nom : Association des Développeurs et des Utilisateurs de Logiciels Libres pour les Administrations et les Collectivités Territoriales.

L'association a été créée en septembre 2002, par Claude LAMBEY et François ELIE.

L'objectif de l'ADULLACT est de soutenir et coordonner l’action des administrations et des collectivités pour promouvoir, développer, mutualiser et maintenir un patrimoine commun de logiciels libres utiles aux missions de service public (administration, éducation, monde associatif, santé...).

Pour satisfaire les contraintes de transparence, de sécurité, d’interopérabilité et d’évolutivité, indispensables pour gérer dans de bonnes conditions les informations propres aux administrés, en favorisant les télé-procédures. Ce patrimoine logiciel respectera les standards et les protocoles ouverts, et sera librement utilisable, copiable, modifiable et redistribuable par quiconque sans aucune discrimination.

Les standards et protocoles sont dits ouverts s’ils sont publiquement documentés, librement utilisables et implémentables.

L’ADULLACT apporte son soutien à l’usage de Logiciels Libres dans les administrations et dans les collectivités territoriales, et se propose de participer au développement de Logiciels applicatifs Libres.

ADULLACT Projet

ADULLACT Projet est une SCIC (Société Coopérative d'Intérêt Commun) régie par la loi du 10 septembre 1947 portant statut de la coopération, et la loi du 24 juillet 1867 sur les sociétés à capital variable. Elle a été créée en octobre 2006.

En optant pour cette forme de société, les porteurs du projet poursuivent, en accord avec les adhérents de l’ADULLACT à l’origine de cette SCIC, leur action, inscrite dans l’intérêt collectif, en faveur de l’optimisation des systèmes d’information au sein des collectivités territoriales et du monde de la santé et, d’une manière générale, en faveur du développement du Logiciel Libre au sein des Services Publics.

La SCIC ADULLACT Projet s’est donnée pour but, dans un esprit de coopération entre les acteurs publics (usagers) et privés (opérateurs techniques, salariés) :

De répondre aux besoins de refonte des systèmes d'information des administrations, collectivités territoriales et organisations relevant des services Publics à base de Logiciels Libres.

De mutualiser les coûts de développement des logiciels dit Libres ou Open Source dont les avantages (coûts, pérennité, accès au code source) ne sont plus à démontrer.

(3)

S’ajoutent :

Le souci de préserver totalement son indépendance et sa neutralité vis-à-vis des organisations économiques ou industrielles privées, pour garantir la meilleure objectivité de ses services, accompagnements ou aides.

La volonté de ménager, avec les organisations publiques, des partenariats de haute proximité, organisés de manière à faire bénéficier ses partenaires des avancées technologiques les plus récentes.

Cet ouvrage

La Business Intelligence, ou Informatique Décisionnelle, est un domaine bien spécifique des systèmes d'information, qui n'échappe pas à l'Open Source.

Ainsi, cet ouvrage s'efforce :

De mettre en avant les enjeux et les défis de la Business Intelligence dans l'Open Source.

De définir les différents outils décisionnels afin de décomplexifier ce domaine.

De présenter les solutions qui sont, ou ont été, les plus pertinentes dans chaque famille d'outils.

D'établir une analyse de ces applications afin d'en retirer une synthèse mettant en avant les intérêts, et inconvénients, de chacun.

Cette étude est fondée sur plusieurs mois de travail de recherche. Elle n'a pas pour objectif d'établir un classement entre les différents outils mais de mettre en avant leurs potentiels respectifs afin que chaque lecteur puisse s'orienter vers celui qui conviendra le mieux à ses besoins et attentes.

(4)

Table des matières

Préambule...2

ADULLACT...2

ADULLACT Projet...2

Cet ouvrage...3

Introduction...5

Business Intelligence...5

Deux systèmes d'information : transactionnel et décisionnel...5

Historique de la Business Intelligence...5

Règles conceptuelles ...6

Open Source...6

Définition du Logiciel Libre...6

Évolution de ce modèle économique...6

Critères de choix...6

L'Open Source Business Intelligence (OSBI)...7

Apports et avantages...8

Perspectives...8

Les outils décisionnels...9

Extract Transform Load (ETL)...9

Data Warehouse et Data Mart...9

Cubes OLAP ...11

Analyse multidimensionnelle...13

Data Mining...14

Générateur d'état...15

Synthèse...17

Les solutions décisionnelles...18

ETL...18

Clover.ETL...18

Enhydra Octopus...20

Pentaho Data Integration (ex. Kettle)...21

Talend Open Studio (TOS)...23

Data Warehouse...25

Bizgres...25

Ingres...25

MySQL...26

PostgreSQL...26

Serveur OLAP...27

Pentaho Analysis Services (ex. Mondrian)...27

Palo...29

Client OLAP...31

FreeAnalysis...31

Jpalo...33

Jpivot...34

Jrubik...36

Data Mining...38

Waikato Environment for Knowledge Analysis (WEKA)...38

Générateur d'état...40

Business Intelligence and Reporting Tools (BIRT)...40

JasperReport...42

Pentaho Reporting (ex. JfreeReports)...44

OpenReports...46

Suites décisionnelles...48

Jasper Intelligence...48

Marvel IT Dash...50

Pentaho...51

Spago BI...54

Synthèse...56

(5)

Introduction

Business Intelligence

Selon la définition de Robert REIX, « un système d'information est un ensemble organisé de ressources (matérielles, logicielles, personnelles, données, procédures...) permettant d'acquérir, de traiter, de stocker des informations (sous forme de données, textes, images, sons...) dans et entre organisations ». Le choix de l'appellation système n'est pas anodin. Il reflète la logique sous-jacente considérant ce dernier comme un ensemble d'entités en interaction entre elles, que l'on pourrait considérer comme autant de maillons formant une chaîne. De ce fait, ce dernier peut être ainsi observé à différents degrés de précision, soit en le considérant comme un système d'information global, soit en accentuant le zoom afin de mettre en valeur deux sous systèmes.

Deux systèmes d'information : transactionnel et décisionnel

D'une part le système d'information transactionnel. Il gère les applications quotidiennes et se rapproche à ce titre de la couche opérationnelle. Il est typiquement utilisé par les acteurs métiers et se voit plus comme un outil utilisé par ces derniers afin de répondre à des besoins de simplification et d'automatisation.

D'autre part le système d'information décisionnel, angle d'approche de cet ouvrage, qui est utilisé pour prendre les décisions de l'entreprise, et à ce titre doit permettre aux décideurs d'avoir un certain recul sur leur entreprise. Il fournit pour cela les informations nécessaires et pertinentes afin de faire les bons choix. Le Gartner Group définit, en 1993, la Business Intelligence comme l'« ensemble des moyens et méthodes permettant de rassembler, consolider, analyser et rendre accessible les données d'une entreprise dans une perspective d'aide à la décision ». Le décisionnel est donc à l'information de l'entreprise ce que les mathématiques sont à la pensée.

Force est de constater que le concept de Business Intelligence n'est pas récent, et que, depuis sa création, des évolutions notables peuvent être distinguées. Il est nécessaire de connaître ces mutations afin de bien saisir les tenant et aboutissant de leur structure actuelle.

Historique de la Business Intelligence

Au début des années 90, l'informatique est au service de l'entreprise pyramidale. D'une manière très classique, elle remonte les informations de la base vers le haut. Cette époque est celle des Executive Information Systems (EIS).

Milieu des années 90, les besoins d'informations composites révèlent des lacunes dans les systèmes d'informations. Les technologies Data Warehouse et Data Mart se banalisent et l'informatique décisionnelle se tourne vers les cubes OLAP, dans un soucis d'analyse plus poussée.

De nos jours, le décisionnel n'est plus l'apanage des instances dirigeantes et toutes les couches de l'entreprise revendiquent un besoin d'information pertinente, propre à leur fonction. Que ce soit dans des soucis de pilotage par les acteurs du top management, pour des besoins particuliers formulés par des experts ou dans des logiques de reporting classique demandées par les acteurs métiers, cette mutation culturelle s'appuie sur la banalisation et l'accessibilité

(6)

des technologies Web, qui rendent cette divulgation d'information possible à moindre coûts.

Force est de constater également que certaines règles conceptuelles se sont inconsciemment standardisées, et actuellement le système d'information décisionnel peut être schématisé sous trois étapes.

Règles conceptuelles

Tout d'abord, l'extraction des données. L'entreprise étant composée d'informations aussi variées en terme de structure, de format, de taille... le système se doit d'extraire les informations afin de les amener vers la deuxième étape.

Ensuite, la consolidation. Ces données doivent être consolidées afin de pouvoir effectuer le travail nécessaire dessus.

Enfin le traitement. Il doit fournir aux dirigeants les informations pertinentes sous forme d'indicateurs, tout en répondant aux questions que toute mise en place doit se poser : Quelles informations ? Sous quelle forme ? Tous les combien ?...

Open Source

Bien plus qu'un simple copyright, la terminologie Open Source (également connue sous l'appellation Logiciel Libre) reflète une certaine philosophie. Richard STALLMAN, le père fondateur de la Free Software Foundation a coutume de résumer ce qu'est le Logiciel Libre par

« Liberté, Egalité, Fraternité ».

Définition du Logiciel Libre Le Logiciel Libre est ainsi défini par :

La liberté d’utiliser et/ou d’exécuter un logiciel pour tout objectif.

La liberté d’examiner et/ou d’étudier le fonctionnement d’un logiciel et de l’adapter à ses propres besoins (pour ceci l’accès au code source est une condition requise).

La liberté de faire des copies pour des tiers.

La liberté d’améliorer le logiciel et de rendre ces améliorations largement disponibles pour le bien public.

Évolution de ce modèle économique

Ce modèle de développement collaboratif, que certains considèrent encore comme utopique et ne prenant pas en compte les logiques de marchés actuelles, s'avère en réalité être plus que réaliste. En effet, dans son édition de Janvier 2007 du Baromètre des tendances 2006, l'Observatoire du Logiciel Libre (O2L), composé de Anaska et du Groupe Cegos, met notamment en évidence une progression sur un an de 30% des ventes de serveurs sous Linux, de 30% également des formations bureautique (tel OpenOffice) et de 50% de celles concernant la base de données MySQL. Ces observations reflètent un réel engouement pour les solutions Open Source, de la part des entreprises qui les jugent assez fiables pour être implantées au sein de leur organisme.

Critères de choix

Néanmoins, une implantation de solution Open Source doit se faire en prenant en compte certains critères de choix, non pris en considération lors de l'intégration de logiciels

(7)

propriétaires car spécifiques au modèle de développement collaboratif.

Popularité

La visibilité sur la toile est, en plus d'être un facteur de taille, un bon outil pour définir la popularité de la solution, et donc plus de facilité à trouver sa communauté.

De la même façon le taux de fréquentation étant le nombre de téléchargement du produit, il reflète, de la même façon que la visibilité sur la toile, la popularité de la solution.

L'âge du projet permet de se faire une idée de la maturité de la solution. Ce critère est néanmoins très subjectif car il n'y a pas de réelle préférence à avoir entre un projet jeune ou un vieux.

Documentation

Dans l'open source, la communauté est la hotline. La taille de la communauté doit être prise en considération, et Il convient donc de choisir des projets avec de riches forum, une home page, des FAQ dédiées et visibles sur le net.

Les aspect de documentation permettent également de délester une bonne partie de la charge de l'équipe animatrice. De plus, elle peut être considérée comme un gage de qualité.

Développement

Le taux d'activité concerne le développement et désigne le temps passé entre deux versions (il ne doit pas excéder 6 mois, doit être relativisé et comparé au taux de fréquentation).

Le nombre de contributeurs doit être distingué de la communauté car il est un garant de la stabilité de la solution, de sa pérennité et de son évolutibilité.

Les compétences internes de l'entreprise doivent également être prises en compte et il convient de privilégier les projets maintenables ou abordables en interne, et de prendre également en compte les compétences des partenaires.

Déploiement

La portabilité et l'interopérabilité révèlent la compatibilité de l'application avec les fichiers entrant-sortant, ainsi qu'avec les différents systèmes d'exploitation.

Le niveau de Packaging concerne l'installation. Elle comporte aussi bien une documentation d'installation qu'une définition des pré-requis.

Droit

Différentes licences de logiciels libre existent, et il convient de privilégier GPL et CeCiLL. Éviter les licences de type « BSD ».

L'Open Source Business Intelligence (OSBI)

De même que pour les autres classes d'outils (CRM, GED...), le rapprochement entre Open Source et Business Intelligence s'avère de plus en plus performant, et ce depuis quelques années. Bien qu'ayant pâti de leur manque de maturité et de stabilité, les solutions de

(8)

Business Intelligence Open Source s'avèrent être actuellement assez solides pour être employées par nombre d'entreprises et de collectivités, et pour posséder leur premier salon professionnel qui s'est tenu à l'arche de la Défense à Paris, le 18 mars 2008.

Organisé par Micropole-Univers et l'Arche Numérique, ce salon a dressé un portrait de l'Open Source dans le décisionnel par le biais de conférences, ateliers, tables rondes... Animés par de nombreux partenaires d'importance dont notamment les sociétés MySQL, Talend et JasperSoft.

Apports et avantages

L'engouement des entreprises pour ces solutions peut s'expliquer sur plusieurs points.

Intérêts financiers

Tout d'abord dans une logique de coûts. Une solution Open Source n'entraîne pas, de par sa définition même, de coûts de licence. Elle s'avèrent donc actuellement être une alternative plus qu'intéressante pour les sociétés. De même, certaines entités telles que les TPE/PME profitent de cet aspect de par un coût d'entrée moins onéreux.

Mutualisation des compétences

La possibilité de coopération entre entreprises, afin de mutualiser les compétences et d'amoindrir les investissements, tant sur le plan financier qu'humain. Comme le souligne Stefano SCAUZZO, Technical Manager chez Engineering, « Les entreprises sont aussi bien en concurrence sur certains domaines et en collaboration sur d'autres, ce qui crée un éco système de valeurs où chacun doit trouver sa place et jouer son rôle ».

Tester la solution

La possibilité de tester le logiciel avant d'investir dedans, et ce sans limite de temps ou de fonctionnalité. L'entreprise peut ainsi s'apercevoir d'elle même, sans biais commercial ou limitation, de la pertinence de la solution. Cette logique d'avant vente se fait de fait par les utilisateurs qui ne se tournent ensuite vers les SSLL que pour des besoins de connaissances et de formations.

Personnalisation et innovation

Personnalisation et innovation sont également des facteurs clefs de ce choix. En effet, outre l'innovation entrainée par le développement collaboratif, Stéphane LAISNE, Responsable d'étude de solutions chez Lectra souligne que « l'Open Source permet une réelle collaboration car le client apporte vraiment sa touche en donnant sa vision de la solution, ce qui permet d'une part de la personnaliser mais également de la faire évoluer en ce sens ».

Perspectives

Bien que des composants comme les ETL ou les bases de données s'avèrent être les plus aboutis, les outils Open Source de Business Intelligence doivent encore s'enrichir sur des aspects métiers et fonctionnels, et arriver à maturité sur certaines briques logicielles.

Néanmoins, l'arrivée de différents acteurs sur ce marché, ainsi que la marche de progression possible de par sa faible part dans la BI, nous autorise à envisager une évolution grandissante.

(9)

Les outils décisionnels

Contrairement aux autres applications s'intégrant à d'autres fonctions de l'entreprise, comme par exemple les SCM qui gèrent la chaîne logistique ou les CRM qui s'occupent de la relation client, l'Informatique Décisionnelle est composée de plusieurs outils qui, imbriqués les uns aux autres ou utilisés séparément, conduisent à créer un véritable système décisionnel. Nous verrons donc ici les différents composants de ce domaine, en partant de la couche la plus invisible de l'iceberg, jusqu'à sa partie la plus visible.

Extract Transform Load (ETL)

Un ETL, pour Extract Transform Load, est utilisé pour alimenter le Data Warehouse à partir des bases de données de production.

Comme son nom l'indique, un ETL :

Extract : extrait les données à partir de différentes sources.

Transform : transforme ces dernières afin de les unifier sous un même format.

Load : charge les données dans le Data Warehouse.

Les intérêts d'un ETL sont multiples :

Il peut prendre en charge différentes natures de sources (SGBD relationnels, flux XML, fichiers CSV...), que ce soit en entrée comme en sortie.

L'intégration d'un nouveau flux ne nécessite pas de développement spécifique, une configuration interactive, par le biais d'interface graphique, des 3 étapes vues précédemment suffit.

L'intégration d'outil de planification, au sein même des ETL, permet d'éviter le développement de programmes batch spécifiques, ainsi que leur maintenance.

Il est cependant important de souligner qu'un ETL fonctionne sous un mode Point à Point. Bien qu'il récupère les données de plusieurs sources, il n'a pas pour vocation de construire un flux agrégé entre deux sources différentes.

Afin de ne pas retomber dans les erreurs du passé (échec de réalisation, dépassement de budget...) relatives à la mise en place de projets décisionnels, il est impératif d'apprécier à sa juste valeur cette phase de collecte et de préparation des données, et ainsi d'y consacrer les ressources nécessaires. A titre informatif, cette phase doit représenter environ les ¾ temps du projet.

Data Warehouse et Data Mart

Littéralement entrepot de données, Le Data Warehouse est une base de données recueillant et gérant toutes les données collectées au sein de l'organisme, dans le cadre de la prise de décision.

En ce sens, elle est :

Exclusivement réservée à cet usage.

Organisée, structurée et préparée à des fins de traitement décisionnel.

(10)

Alimentée en données depuis les bases de production a l'aide d'outils de type ETL.

Bill Immon, père du concept du Data Warehouse, le décrit comme tel : '' Subject oriented, integrated, nonvolatile, time variant collection of data in support of management decisions '' - Building the Data Warehouse, John Wiley and son, 1996

Il doit donc répondre à 4 caractéristiques essentielles :

1. Orienté sujet : les données sont organisées par thème.

2. Intégré : les données provenant de sources hétérogènes, elles utilisent chacune un type de format. Elles doivent donc être intégrées avant d'être proposées à utilisation.

3. Non volatile : les données ne disparaissent pas et ne changent pas au fil des traitements, au fil du temps.

4. Historisé : les données sont horodatées, afin de visualiser l'évolution dans le temps d'une valeur donnée.

Le degré de détail de l'archivage est bien entendu relatif à la nature des données. Toutes les données ne méritent pas d'être archivées.

Il existe plusieurs natures de Data Warehouse possibles (bases relationnelles, bases OLAP, bases hybrides...). Nous ne les recenserons pas ici mais proposerons plutôt ce tableau mettant en avant les caractéristiques différenciant les Data Warehouse et les bases de données relationnelles classiques.

Comparatif entre Base de Données etData Warehouse Caractéristique Base de Données Data Warehouse Opération Gestion courante.

Production. Analyse.

Support à la décision.

Modèle de données Entité / relation. 3NF.

Etoile.

Flocon de neige.

Normalisation Fréquente. Plus rare dans les Data Marts.

Données Actuelles.

Brutes. Historisées.

Parfois agrégées.

Mise à jour Immédiate.

Temps réel. Souvent différée.

Niveau de consolidation

Faible. Elevé.

Perception Bidimensionnelle. Multidimensionnelle.

Opérations Lecture.

Mises à jour.

Suppressions.

Lectures.

Analyses croisées.

Rafraîchissements.

Taille En giga-octets. En téra-octets.

Source : Wikipédia

(11)

Cubes OLAP

Le concept OLAP (On Line Analytical Processing) a été défini en 1993 par le Dr Ef Codd. Ce dernier doit respecter 12 règles de conception :

Multidimensionalité : le modèle OLAP l'est par nature.

Transparence : l'emplacement physique du serveur OLAP est transparent pour l'utilisateur.

Accessibilité : l'utilisateur OLAP dispose de l'accessibilité à toutes les données nécessaires à ses analyses.

Stabilité : la performance des reportings reste stable indépendamment du nombre de dimensions.

Client-Serveur : le serveur OLAP s'intègre dans une architecture de la sorte.

Dimensionnement : il est générique, afin de ne pas fausser les analyses.

Gestion complète : le serveur OLAP assure la gestion des données clairsemées.

Multi-utilisateurs : le serveur OLAP offre un support multi-utilisateurs (gestion des mises à jour, intégrité, sécurité...).

Inter Dimension : Le serveur OLAP permet la réalisation d'opérations inter dimensions sans restriction.

Intuitif : Le serveur OLAP permet une manipulation intuitive des données.

Flexibilité : La flexibilité (ou souplesse) de l'édition des rapports est intrinsèque au modèle.

Analyse sans limites : Le nombre de dimensions et de niveaux d'agrégation possibles est suffisant pour autoriser les analyses les plus poussées.

Cette notion a vu le jour du fait que les bases de données de type relationnel (SGBDR) sont inadaptées aux besoins décisionnel. En effet, les requêtes décisionnelles, particulièrement complexes par principe, mobilisent abusivement les ressources machines et perturbent les traitements de production.

Les outils OLAP permettent de modéliser l'activité d'une entreprise suivant des axes ou paramètres, répondant ainsi à ces contraintes. Pour ce faire, la structure de données construite est parfois appelé schéma en étoile, du fait de sa forme :

Exemple de modèle de données en étoile TEMPS

ID_TEMPS Date

PRODUIT ID_PRODUIT NOM_PRODUIT

POINT DE VENTE ID_PV ADR_PV

VENDEUR ID_VENDEUR NOM_VENDEUR PRENOM_VENDEUR VENTE

ID_TEMPS ID_PRODUIT ID_PV ID_VENDEUR Quantite Prix

(12)

Nous pouvons ainsi distinguer deux types de tables :

Celles formant les branches des étoiles, utilisées comme critères d'analyse. Elles sont appelées dimensions ou axes.

Celle qui forme le centre de l'étoile. Appelée table de fait, elle contient les indicateurs, également appelés mesures.

Ces indicateurs sont donc fonctions des différentes dimensions, c'est pour cela que l'on emploie le terme multidimensionnel.

Si l'on représente cette conceptualisation sous forme schématique, on obtient ce type de graphique :

La représentation de cette base de données donne donc un Cube. On appelle Cube OLAP une représentation des données selon des axes. Cette structure présente de nombreux avantages pour des applications de Business Intelligence, en particulier grâce à sa capacité à faire évoluer, recalculer et transformer les tableaux de bord. Le concept OLAP s’est spécialisé avec différentes déclinaisons : multidimensionnelles, hybrides, desktop… Le Cube complet est appelé population d'analyse. Dès qu'on dépasse trois dimensions, on parle d'hypercube.

Dans la mesure où toutes les cases du Cube ne seront pas forcément remplies (ex. : tel point de vente ne vend pas tel produit), il est possible d'indiquer au moteur OLAP les caractéristiques d'une variable, dimension dense ou éparse, afin d'optimiser la gestion de l'espace disque et l'accès aux données.

Il peut être intéressant de définir des hiérarchies sur les dimensions. Ainsi, l'axe Temps pourra se découper en jour, semaine, mois... Et de même pour Point de Vente qui pourra se découper en ville, canton, département... On utilisera les termes parents, enfants... pour décrire les différents niveaux entre eux.

Temps

Produits

Points de Vente

Prod. A Prod. B Prod. C Prod. D Fêvrier

Avril Mars Janvier

Lyon

Paris Nantes Montpellier

Exemple de Cube OLAP

(13)

Ainsi, le modèle conceptuel découlant de ces différentes hiérarchies donne :

La structure de cette base de données, dans la même lignée que l'appellation schéma en étoile, est appelée schéma en flocons.

Sous cette forme là, les seuls indicateurs possibles sont donc, comme vu précédemment, la quantité et le prix. Néanmoins, il n'est pas nécessaire de définir, à l'origine, tous les indicateurs possibles. Ainsi, d'autres indicateurs, non stockés à la base, seront calculés à partir de ceux stockés, selon certains calculs. Ils sont souvent appelés formules.

Analyse multidimensionnelle

L'analyse multidimensionnelle s'effectue à partir des Cubes OLAP. Les Cubes OLAP, comme vu précédemment, comportent de nombreux doublons du fait de leur structure. Il convient donc d'agréger certaines données afin de faciliter la compréhension des résultats.

Les jeux d'informations sont caractérisés par :

Des attributs, qualifiant l'information (référence client, date, région ...).

Des grandeurs, portant l'information quantitative (quantités, prix...).

On distingue également :

Des grandeurs cumulables (montant, nombre d'items...).

Des grandeurs non cumulables (âge, date...).

Les attributs constituent les axes potentiels d'analyse. Néanmoins, la redondance de certaines informations, bien que nécessaire dans un premier temps, est telle qu'il est nécessaire d'agréger dans un second temps, certaines données en fonction d'axes potentiels d'analyse définis, les plus pertinentes étant généralement les grandeurs cumulables.

Exemple de modèle de données en flocons JOUR

ID_JOUR DESC _JOUR

MOIS ID_MOIS DESC _MOIS

SEMAINE ID_SEMAINE DESC _SEMAIN E

TEMPS ID_TEMPS ID_JOUR ID_MOIS ID_SEMAINE

VENTE ID_TEMPS ID_PRODUIT ID_PV ID_VENDEUR Quantite Prix

POINT DE VENTE ID_PV

ID_VILLE

VILLE ID_VILLE ID_C ANTON DESC _VILLE

CANTON ID_C ANTON DESC _C ANTON

(14)

L'analyse multidimensionnelle à proprement parler consistera à sélectionner les axes d'analyses souhaités, ainsi que leur ordre. Chaque hiérarchisation d'axes d’analyse correspond à une question que l’on se pose, et il n'est pas forcément nécessaire de les utiliser tous.

Les axes sont également scindés selon deux types :

A valeur discrète, (ou discontinues) : définis par un nombre fini de valeurs (code postal, segment CSP...).

A valeurs continues (date, prix...).

Il est plus intéressant de disposer d'axes à valeur discrète, plus aisément manipulables. Ainsi, on ramènera, autant que faire ce peut, les valeurs continues en valeurs discrètes (en définissant des tranches par exemple).

Data Mining

Que l'on peut traduire par forage de données, le Data Mining consiste donc à forer dans un grand volumes de données afin d'en extraire des informations pertinentes pour le décideur.

Le point important du Data Mining est que l'utilisateur ne sait pas ce qu'il cherche. En effet, les outils de Data Mining recherchent, de manière semi-automatisés, des corrélations invisibles entre des données n'ayant à priori aucun lien entre elles.

L'utilité même du Data Mining peut être comprise par l'exemple (plus ou moins légendaire) Wall-Mart. Cette entreprise Américaine, spécialisée dans la grand distribution, utilisa les premières techniques de Data Mining sur leurs données produits. Ainsi, les résultats de ces recherches mirent en avant une corrélation entre les ventes de couches et celles de bières le samedi après-midi. Après analyse, il s'avéra que le lien entre ces deux produits était induit par le fait que le samedi après-midi, pour les couples ayant un ou plusieurs enfants en bas âge, les femmes délèguaient les courses à leur mari. Ces derniers achetaient ainsi les couches pour leur nourrissons, ainsi que des bières pour eux-mêmes. De ce fait, une réorganisation de l'agencement des rayons, mettant côte à côte les rayons couches et bières, firent grimper les ventes de ces dernières en flèche.

Cet exemple du Data Mining est tout particulièrement éloquent car il met en avant les points essentiels de cet outil :

1. Ce n'est pas l'utilisateur qui cherche des réponses à des questions spécifiques mais l'application qui met en valeur des axes de réflexion à suivre.

2. Cet outil est particulièrement adapté au traitement de grands volumes de données.

3. Une analyse des résultats obtenus doit être effectuée afin de définir, d'une part quel type de relation se cache derrière ces résultats (cause à effets, résultante d'une cause conjointe...), et d'autre part les causes de cette relation.

4. L'information pertinente, résultante de cette analyse, doit aboutir à des préconisations utilisables par le décideur.

Il en découle ainsi plusieurs points :

1. Le Data Mining est plus considéré comme un art que comme une science, car sa pertinence réside dans l'analyse effectuée, et les résultats qui en découlent, sur les données retournées.

2. Il s'utilise sur un volume de données important, dont une chronologie peut être établie (typiquement des Data Warehouse), à contrario de l'analyse statistique.

3. Cette technique peut tout aussi bien être utilisée à des fins explicatives que dans un

(15)

objectif prédictif.

Il existe ainsi non pas une technique de Data Mining mais plusieurs, chacune reposant sur des algorithmes mathématiques bien spécifiques, à choisir en fonction des résultats escomptés :

Les méthodes utilisant les techniques de classification et de segmentation.

Les méthodes utilisant des principes d'arbres de décision assez proches des techniques de classification

Les méthodes fondées sur des principes et des règles d'associations ou d'analogies Les méthodes exploitant les capacités d'apprentissage des réseaux de neurones Les algorithmes génétiques, utilisés pour les études d'évolution des populations.

Une utilisation performante des outils de Data Mining nécessite 3 conditions obligatoires, chacune possédant ses contraintes :

Une collecte des données complète, minutieuse et fiable (longue et coûteuse).

Une étude des résultats approfondie, à mettre en relation avec d'autres techniques d'analyse (nécessite du temps et des compétences).

Une absence de réponse du système ne doit pas être systématiquement considérée comme une négation. Il peut parfois indiquer la nécessité d'aborder le problème sous un autre angle (nécessite du temps et le recul nécessaire).

Générateur d'état

Le générateur d'état permet de réaliser des états, appelés également reporting, qui sont des rapports présentant de manière synthétique et lisible des données, sous forme de tableaux de chiffres, tout en gérant la mise en page (en-tête, pied de pages...).

D'une manière générale, le fonctionnement d'un générateur d'état se décline sous 4 phases : 1. Obtention d'un fichier modèle XML.

2. Construction d'un rapport à partir du modèle.

3. Remplissage du modèle à l'aide des sources de données.

4. Exportation sous différents formats.

Nous pouvons ainsi le schématiser de la sorte :

Schéma de fonctionnement d'un générateur d'état

Moteur de reporting

Outil de designer Modèle XML Rapport rempli

Fichiers Base de données

Etape 1

Etape 2

Etape 3

Etape 4

(16)

La particularité d'un générateur d'état est qu'il peut se décliner sous deux aspects :

Interactif : l'utilisateur pourra tout aussi bien générer un état en le déclinant sous plusieurs variantes (année, produit, région...).

Figé : les règles de gestion sont définies à la base et l'utilisateur ne se servira de l'application que dans un mode Client-Serveur.

Cette particularité induit ainsi deux modes de conception diamétralement opposés :

Dans le mode interactif, la phase de paramétrage et de production ne requiert aucune expertise particulière car elle est sous le contrôle de l'utilisateur final.

Dans le mode figé, a contrario, l'utilisateur ne peut modifier les paramètres des états.

La conception initiale nécessite donc une expertise spécifique et rigoureuse.

Il est cependant plus intéressant de mettre à disposition des générateurs d'état figés. Bien que cette orientation nécessite un coût plus important, aussi bien en terme de temps que d'argent, et qu'elle rigidifie les possibilités d'utilisation, l'expérience montre que les utilisateurs ont en général d'autres priorités que celles de l'apprentissage de l'application et de la définition des ses paramétrages.

Le principal inconvénient des générateurs d'états vient de leur utilisation. En effet, bien qu'ils permettent au décideur de disposer d'une vue d'ensemble précise de son organisation, ils sont plus utilisés afin de rendre des comptes. Cela s'inscrit dans une logique de management par le contrôle, et non dans celle de la Business Intelligence.

Il existe également des générateurs de graphiques qui, comme leur nom l'indique, permettent la visualisation des données sous forme de graphes. Néanmoins, bien que certains documents distinguent ces outils des générateurs d'états, nous ne ferons pas la différence dans cet ouvrage car la plupart de ces générateurs sont actuellement utilisés comme des moteurs graphiques implémentés directement dans les générateurs d'états.

Point important : il ne faut pas confondre reporting et tableau de bord. Le premier est généré par le générateur d'état alors que le second propose une vision plus globale.

(17)

Synthèse

Après avoir défini les différents outils, nous proposerons ici une vue d'ensemble de leurs articulations et de leur liens, sous une représentation graphique théorique.

Cette représentation est schématique. En effet, elle illustre d'une manière globale les différentes interactions entre chaque outil. Elle doit être considérer comme un socle d'analyse et non comme une vérité absolue. Chaque cas d'implémentation d'une solution de Business Intelligence est unique, et doit faire l'objet d'une étude des besoins. Ainsi, il n'est pas rare de voir de nombreux systèmes d'information décisionnels dépourvus de solution de Data Mining, ou bien encore d'en rencontrer où les données à analyser étant uniquement stockées dans une base de données relationnelle, les générateurs d'états travaillent directement dessus sans passer par un ETL, un Data Warehouse et un Data Mart. Ainsi, il est bon d'avoir une représentation globale des différents éléments de Business Intelligence mais elle doit être adapter aux différents cas et contextes rencontrés.

BD Interne

BD Externe

Fichiers TXT, C SV...

Source de Données

Générateur d'état

Analyse Multidimensionnelle

Data Mining

Tableaux de bord

Extraction Stockage Restitution

Réprésentation d'un sytème d'information décisionnel

ETL

Data Mart Data Warehouse

Data Mart

C ube OLAP

(18)

Les solutions décisionnelles

Nous analyserons dans cette partie un panel des solutions existants dans le décisionnel, en décrivant les aspects techniques, les fonctionnalités des outils et les caractéristiques globales des communautés s'articulant autour.

ETL

Clover.ETL

● Clover.ETL est un ETL Open Source, basé sur un framework Java qui peut être utilisé pour transformer des données structurées. Il peut être utilisé seul, comme un serveur d'application, ou peut être embarqué dans d'autres applications, comme une librairie de transformation.

Fiche d'identité

Caractéristiques générales de la solution Projet âgé de 3 ans.

Bonne documentation.

Distribué sous Licence GPL.

Communauté

Sponsorisé par OpenSys, un administrateur et six développeurs ont clairement étaient identifiés.

Taille de la communauté et visibilité Internet assez faible.

Taux de fréquentation très bon.

Niveau d'accessibilité Interface graphique.

Faible niveau de packaging.

Pas de traduction Française.

OS Indépendant.

Taux d'activité Très bon.

02 avril 2008

Accès aux données

L'accès aux données est somme toute juste moyen. Bien que reconnaissant la plupart des fichiers plats, fournissant un outil de création de requêtes, permettant leur exécution et ayant une très bonne reconnaissance des bases de données, il ne gère pas les relations avec les

(19)

cubes OLAP et ne permet pas la lecture et l'écriture de types de données complexes.

Caractéristiques spécifiques

Il ne possède que de faibles caractéristiques spécifiques, comme un outil de debugging, mais ne permet pas la génération de documentation fonctionnelle ou technique. De plus, il ne possède pas d'outil d'analyse d'impact, contrairement à d'autres ETL.

Déclenchement des processus

Aucun déclenchement des processus n'est possible, ni leur planification.

Déploiement et mise en production

Une facilité de déploiement et de mise en production et cependant à noter. Basé sur Eclipse RCP, le code est visible et autonome, ce qui permet de ne pas avoir nécessairement à l'installer sur les serveurs de production. Néanmoins, aucune visualisation de l'historique de mise en production n'est possible.

Traitement des données

Le traitement des données est assez faible. Il est certes possible d'ajouter de nouvelles transformations et processus métiers, mais le manque de certaines fonctions natives, telles que la transformation des dates, des nombres ou de statistiques de qualité se fait ressentir.

Sécurité

Le niveau de sécurité est assez faible, il se base uniquement sur celle du SGBD utilisé.

Néanmoins, certaines fonctions de base comme la gestion automatisée des logs et des systèmes de test ou de debugging sont présentes.

Conclusion

Encore assez jeune, il n'apparaît pas comme suffisamment mature pour être utilisé. Les caractéristiques techniques approchent faiblement la moyenne de ce qui se fait et la sécurité n'est pas au rendez vous. Il est pour le moment réservé à une utilisation personnelle et pour spécialiste mais possède une communauté florissante et très active. Il convient de suivre son évolution car ses perspectives, notamment de par son intégration dans ObjectWeb, peuvent s'avérer intéressantes. A suivre...

(20)

Enhydra Octopus

Enhydra Octopus est un ETL basé sur du Java. Il peut se connecter à n'importe qu'elle source de données via JDBC et réalise les transformations définies en fichier XML.

Mauvaise documentation.

Communauté

Sponsorisé par Together Teamlösungen EDV-

Dienstleistungen GmbH, trois administrateurs et quatre développeurs ont clairement étaient identifiés.

Taille de la communauté et visibilité Internet assez faible.

Taux de fréquentation non communiqué.

Niveau d'accessibilité

Pas d'interface graphique, ni de traduction Française.

Faible niveau de packaging.

OS Indépendant.

Taux d'activité

En chute libre depuis 2004.

02 avril 2008

De même que pour Clover.ETL, l'accès aux données s'avère être tout juste moyen. De caractéristiques assez similaires, il se différencie par le fait qu'il ne dispose pas d'outil de création de requête.

Il ne possède aucune réelle caractéristique spécifique et aucun moyen de déclenchement de processus.

Son déploiement est cependant assez bon. Basé sur Java, son code est également visible et autonome et ne permet pas la visualisation de l'historique de mise en production.

Le traitement des données est assez faible, de même que pour Clover.ETL, à la différence

(21)

notable que Enhydra Octopus possède nativement des fonctions de transformations de dates et de nombres.

Sécurité

Le niveau de sécurité est assez faible, il se base uniquement sur celle du SGBD utilisé.

Néanmoins, certaines fonctions de base comme la gestion automatisée des logs et des systèmes de test ou de debugging sont présentes.

Conclusion

N'a pour mérite que le fait d'avoir été l'un des précurseur dans le domaine des ETL Open Source. De faibles caractéristiques techniques et sécuritaires, un niveau d'accessibilité très mauvais et une communauté sur le déclin depuis 2004. ETL à éviter.

Pentaho Data Integration (ex. Kettle)

Pentaho Data Integration est un puissant ETL ayant pour objectif de faire le lien entre Business et Technologies de l'Information, une transformation des données de l'entreprise en profits.

Caractéristiques générales de la solution Intégré à Pentaho depuis 2 ans.

Très bonne documentation.

Distribué sous Mozilla Public Licence 1.1 Communauté

Sponsorisé par Pentaho, 9 administrateurs et 19 développeurs ont clairement étaient identifiés.

Taux de fréquentation et visibilité Internet très bon.

Taille de la communauté difficile à déterminer car reliée directement à la suite décisionnelle Pentaho.

Très bon niveau de packaging.

Dispose d'une traduction Française.

OS Indépendant.

Taux d'activité Assez modeste.

02 avril 2008

(22)

Pentaho Data Integration se révèle être un outil performant en ce qui concerne l'accès aux données. En effet, hormis la possibilité de lier des fichiers plats de type CSV, XLS... Il permet la liaison avec les cubes OLAP Mondrian. De plus, certains connecteurs sont déjà existant, comme SAP, ce qui évite leur mise en relation manuelle. Il peut également être lié à des Web Services.

Il ne possède pas de grande caractéristique spécifique. Le seul point positif est qu'il est possible de disposer d'outils d'analyse d'impact et de debugging.

Le déclenchement par processus est disponible sous deux formes. L'une est par type de polling, l'autre est par planification des exécutions, à l'aide de Pan et Kitchen.

Son déploiement est cependant assez bon. Basé sur SWT, son code n'est malheureusement pas visible, ni autonome, ce qui nécessite de disposer d'un composant pour faire tourner les Jobs.

Le traitement des données est tout juste moyen. Hormis la possibilité d'ajouter de nouvelles transformations et processus métiers, il est également possible d'effectuer des jointures externes.

Sécurité

Le niveau de sécurité est sûrement le meilleur des ETL étudiés dans cet ouvrage. La mise en place d'une console d'administration permet un niveau de sécurité important, tant au niveau de l'accès aux métadonnées que sur celui de la création de scénarios et même sur leur mise à jour. De plus, une gestion automatisée des logs ainsi que des systèmes de test et de debugging.

Conclusion

Anciennement Kettle, poursuit une ascension des plus fortes depuis qu'il a rejoint le projet Pentaho. Fort de caractéristiques techniques et d'un niveau de sécurité plus que bon, il peut également se vanter d'être d'un excellent niveau d'accessibilité. Il pêche néanmoins par ce qui fait sa force : la suite Décisionnelle Pentaho. En effet, il n'existe pas réellement de communauté propre à cet ETL mais plutôt une globale concernant la suite Décisionnelle, ce qui explique son faible taux d'activité. Bien qu'étant une excellente solution, elle s'inscrira plutôt dans une perspective d'intégration globale de la suite Décsionnelle Pentaho que pour une utilisation seule.

Talend Open Studio (TOS)

(23)

Talend Open Studio est doté de capacités avancées qui améliorent grandement la productivité des modèles d'intégration de données, et ce tout en conservant une éxecution optimale.

Bonne documentation.

Communauté

Sponsorisé par Talend, 3 administrateurs et 18 développeurs ont clairement étaient identifiés.

Taille, taux de fréquentation et visibilité Internet très bon.

Très bon niveau de packaging.

Dispose d'une traduction Française.

OS Indépendant.

Très bon (environ une nouvelle version tous les mois).

02 avril 2008

Talend Open Studio possède les caractéristiques techniques les plus performantes des ETL traitées ici. L'accès aux données est quasiment parfait. En effet, il gère aussi bien les fichiers plats que les cubes OLAP, dispose d'un outil de création de requête, et est doté de connecteurs nativement, tel Sugar CRM et SalesForce. De plus, il peut également se connecter à des sources de données complexes comme les données cartographiques.

Hormis les spécificités standards de génération de documentation, le point intéressant de TOS est la possibilité de combiner l'approche ETL classique avec celle de l'ELT. Cette dernière permet d'utiliser les ressources du SGBDR pour exécuter les transformations, ce qui permet ainsi de diminuer considérablement les ressources nécessaires.

La plupart des déclenchements de processus sont disponibles, que ce soit par message ou par polling. Il est également possible de planifier les exécutions.

(24)

Son déploiement et sa mise en production sont assez bonnes. Basé sur Eclipe RCP, son code est visible et autonome ce qui n'entraîne pas ainsi la nécessité d'installer TOS sur les serveurs de production.

Le traitement des données est quant à lui de très bonne qualité car bien qu'il existe la possibilité d'ajouter de nouvelles fonctions, de nombreuses fonctions de transformation des dates, nombres ou de statistiques avancées sont déjà incorporées. De plus, il supporte les jointure de flux.

Sécurité

Le niveau de sécurité rivalise presque avec celui de Pentaho Data Integration. Doté des mêmes caractéristiques, TOS se distingue cependant par l'absence de sécurité sur le lancement des tâches, d'un système de test et de debugging en temps réel ainsi qu'un type de sécurité propriétaire.

Conclusion

Sans nul doute le meilleur ETL Open Source du moment. Excellentes caractéristiques techniques, très bon niveau de sécurité et une facilité de prise en main plus qu'accessible. De plus, il est soutenu par une communauté extrêmement active qui focalise tous ses efforts sur cet outil. Ne serait ce que pour l'année 2007, le nombre de nouvelles versions s'est élevé à une par mois. De plus, il à été choisi pour être l'ETL de référence par les suites Décisionnelles Jasper et Spago BI. Nous ne traiterons pas ici du choix d'une suite décisionnelle à adopter mais il est plus que certain que Talend Open Studio est l'ETL par excellence.

(25)

Data Warehouse

Nous avons décidé de ne pas traiter, à proprement parler, les solutions de Data Warehouse en Open Source. Ce choix délibéré résulte directement de la pertinence de son utilisation. En effet, la décision de mettre en place un Data Warehouse entraîne :

Le remplissage de ce dernier en informations par le biais d'un ETL.

L'utilisation de ce Data Warehouse par la mise en place d'un outil de restitution.

Ce choix peut avoir ses avantages dans le développement d'une solution de Business Intelligence créée de toutes pièces. Néanmoins, dans la mesure ou plusieurs plate-formes décisionnelles répondent à ce besoin, et ce, comme nous le verrons, à différents niveaux de pertinence, cet ouvrage ne traitera pas différentes possibilités.

Nous effectuerons tout de même un bref aperçu des différents possibilités, afin d'avoir une idée globale des solutions existantes.

Bizgres

Le projet Bizgres a été enregistré début 2005. S'appuyant sur PostgreSQL, il a été créé afin de spécialiser ce dernier pour du Data Warehoue. Greenplum est sponsor principal de ce projet. Le projet est sous licence BSD. La dernière news en ce qui concerne le projet date de septembre 2006. Néanmoins, si l'on analyse en profondeur le projet et les différents acteurs, on s'aperçoit également que la première version de la Greenplum Database a été proposée très peu de temps après cette version. Cette solution s'appuie sur Bizgres mais n'est pas distribuée sous la même licence, car elle impose un contrat de licence pour de l'utilisation. De plus, Greenplum proposant, et ayant en charge tout ou partie du projet Bizgres, il n'est pas inconsidéré de penser que le projet Bizgres a été relégué au placard, et que Greenplum déploie tout ses efforts sur son unique produit. Il nous semble donc que, d'une part, que le projet Bizgres n'est plus réellement suivi, et d'autre part que la Greenplum Database ne correspond pas aux critères Open Source de cet ouvrage.

Ingres

Ingres a été développé en 1977. Possédant une grosse notoriété dans les années 80 et 90 chez les grands comptes, il possède encore de très bonne références chez ces derniers tel que l'Oréal, Leroy Merlin ou Eiffage.

Néanmoins, le projet n'est distribué sous licence Open Source que depuis peu. En effet, à l'origine le projet est sous licence propriétaire, mais en 2005 ce dernier est cédé par Computer Associates à un fond d'investissement qui, par l'intermédiaire de la société Ingres Corporation, le distribue en licence GPL afin de redynamiser son développement. Bien que réputé pour sa robustesse et pour sa capacité à monter en charge, il apparaît encore très délicat d'émettre un avis sur ce projet. En effet, bien que commencé en 1977, nous pouvons considérer que le projet est somme toute très jeune car Open Source depuis 2005. De plus, le changement de modèle économique d'une logique propriétaire à une Open Source doit être étudié sur le temps, notamment du fait de l'importance d'acteurs majeurs que sont MySQL et PostgreSQL, déjà présents sur ce secteur depuis de nombreuses années.

(26)

MySQL

Apparu en 1995, le projet MySQL a vu la société en charge de son développement, MySQL AB, récemment rachetée par Sun Microsystem. Disponible sous la plupart des systèmes d'exploitation, il est distribué sous licence GPL. Soutenu par une communauté très importante, MySQL apparaît comme un incontournable de la base de données Open source. Simple de configuration, de déploiement et d'utilisation, il s'avère être grandement utilisé lors de la conception de sites Web, et c'est pour cela que la plupart des hébergeurs gratuits le supportent. Néanmoins, de nombreuses structures professionnelles l'utilisent également comme base de données interne, et non pour l'usage unique de site Web.

En effet, MySQL est le plus à même pour traiter les données d'une masse volumique assez courante. Néanmoins, bien que plus performant et plus rapide que PostgreSQL, ses avantages ont également le revers de la médaille. Nous pouvons noter deux principaux points négatifs :

D'une part cette rapidité d'exécution s'explique par le fait que MySQL ne gère pas l'intégrité référentielle.

D'autre part MySQL s'avère être limité lors d'une masse de données importante.

L'exemple notamment de la migration de SourceForge d'une base de données MySQL à une PostgreSQL s'explique par ce point là, MySQL ne gérant plus assez efficacement les montées en charge.

PostgreSQL

La première version du projet PostgreSQL, appelé Postgre à l'origine, remonte à 1986. Devenu libre et distribué sous licence BSD depuis 1996, il est intéressant de noter que le créateur de PostgreSQL est également le créateur d'Ingres. Réputé pour ses excellentes performances, il possède de solides références chez les grands comptes, comme Météo France ou la RATP. Le fait que ce projet ne fonctionnait pendant longtemps que sous système UNIX explique les raisons d'une communauté plus faible que chez MySQL. Néanmoins, depuis la version 8.0, il est disponible sous Windows. Un peu plus complexe de prise en main que MySQL, il est néanmoins plus à même de traiter les masses de données importantes et garantie une cohérence de la quasi-totalité des données car il gère l'intégrité référentielle. Notre ouvrage traitant les différents modules de la Business Intelligence, il est également important de signaler que Talend, leader de l'ETL dans l'Open Source, et EnterpriseDB, acteur majeur proposant des solutions basées sur PostgreSQL, ont récemment annoncé un partenariat technologique sous forme d'offre combinée entre les bases de données PostgreSQL et l'intégrateur de données Open Source de Talend. L'objectif de ce partenariat est de fournir une solution de gestion de données capable de supporter des transactions complexes et d'être distribuée à travers de nombreux sites géographiques.

(27)

Serveur OLAP

Avant toute analyse des types de Cubes et des différents serveurs, 3 points importants sont à noter, en ce qui concerne l'OLAP :

1. Un client M-OLAP (ex. : Palo Web Client) ne pourra pas travailler sur un serveur R-OLAP (ex. : Mondiran), et inversement.

2. Le projet OLAP4J cherche à définir une API commune pour tous ces projets.

3. Mondrian travaille directement sur le SGBDR alors que Palo doit importer les données.

Pentaho Analysis Services (ex. Mondrian)

Mondrian est un serveur OLAP écrit en Java. Il autorise une analyse interactive très large des données stockées dans une base de données SQL sans avoir à écrire de code SQL.

Caractéristique spécifique de la solution Type de Cube : R-OLAP.

Point fort : la capacité.

Très bonne documentation.

Distribué sous Licence CPL.

Communauté

Sponsorisé par Pentaho, 1 administrateur et 22 développeurs ont clairement étaient identifiés.

Taux de fréquentation et visibilité Internet très bon.

Taille de la communauté difficile à déterminer car reliée directement à la suite décisionnelle Pentaho.

Niveau d'accessibilité

Pas d'interface graphique.

faible niveau de packaging.

Ne dispose pas d'une traduction Française.

OS Indépendant.

Taux d'activité Plutôt bon.

03 avril 2008

Chargement des données

Le temps de chargement des données dans le Cube est très faible. En effet, les données sont directement intégrées dans le Cube lors de leur extraction, par le biais d'un ETL.

(28)

Développement

D'une manière générale, il est souvent nécessaire de développer des connecteurs spécifiques pour traiter les tables agrégables. De même pour les tables très détaillées, il est souvent impératif de développer des sur-tables afin de remédier aux problèmes de performances liés à l'importance de ces tables.

Fonctionnalités

Bien que, de part leur conceptualisation M-OLAP il n'existe pas la possibilité d'utiliser les techniques d'analyses propres aux cubes R-OLAP, le problème est relativement contourné grâce aux évolutions du langage SQL dans le domaine de l'analyse multidimensionnelle.

Outils

Il existe un nombre important d'outils à disposition de l'utilisateur. Le principal problème vient du fait que, comme nous l'avons souligné précédemment, le traitement s'avère difficile sur les tables détaillées provenant de données agrégées. Néanmoins, le point fort de Pentaho Analysis Services vient de sa conceptualisation sous forme Relationnelle, qui permet ainsi à d'autre outils, tel les outils classiques de reporting, d'être utilisés sur ces Cubes. Notons tout de même que, d'une manière globale, les outils sont moins performants que ceux existants sur les Cubes M-OLAP.

Requêtes

Les outils de traitement de données non agrégables, comme les textes descriptifs par exemple, bénéficient d'une bonne performance. Néanmoins, ces outils sont peu appropriés aux modèles ne traitant pas bien le SQL, comme notamment les rapports financiers.

Sécurité

Le niveau de sécurité est directement lié à celui de la base de données traitée. Il est ainsi possible d'obtenir un bon niveau en utilisant les outils disponibles avec cette dernière.

Volume de données

En opposition aux Cubes M-OLAP, Pentaho Analysis Service est plus à même de traiter une masse importante de données.

Conclusion

Grâce à un bon couplage avec un ETL performant, les Cubes R-OLAP bénéficient d'un temps de chargement des données des plus faibles. Bien que leur approche relationnelle ne leur permette pas d'utiliser les méthode d'analyses poussées propres aux Cubes multidimensionnels, ce problème est contourné grâce aux évolutions du langage SQL dans ce domaine. De plus, le nombre important d'outils et la possibilité, de par leur approche relationnelle, d'utiliser d'autres outils de reporting directement sur ces Cubes, en font une architecture plus qu'intéressante, et comble le fait que les différents outils sont, d'une manière globale, moins performants que ceux utilisant l'approche M-OLAP, et traitent moins bien les tables détaillées. La bonne performance des outils de traitement de données non agrégables, telles que les textes, la possibilité d'obtenir un bon niveau de sécurité en utilisant les paramètres de la base de données traitée et le fait que ce type de Cube est plus à même de traiter un volume de données important font que la plupart des outils Open Source sont fondés sur cette approche. Point négatif à prendre en compte : il est souvent nécessaire de

(29)

développer des connecteurs spécifiques pour les tables agrégables, ainsi que des sur-tables pour palier les problèmes de performance des tables détaillées. De plus, signalons que ces outils, de part leur utilisation SQL, se révèlent peu appropriés sur des modèles tels que les rapports financiers.

Le serveur Mondrian est fondé sur l'approche R-OLAP. Les outils utilisant ce dernier bénéficient des spécificités propres à ce type d'architecture, que ce soit les points positifs ou négatifs.

D'une manière plus générale, le projet Mondrian a rejoint le projet Pentaho, il bénéficie donc à ce titre d'une communauté globale à ce projet, plus que d'une propre à lui. Sa popularité est plus que forte, ainsi que sa visibilité Internet. Fort d'une excellente documentation, il pêche néanmoins sur un niveau d'accessibilité assez faible, lorsqu'il s'agit de l'implémenter seul, hors suite Décisionnelle Pentaho. De plus il est important de souligner que de nombreux clients, tels que Jrubik ou Jpivot pour ne citer qu'eux, sont conçus pour ne fonctionner qu'avec lui.

Palo

Palo est un serveur multidimensionnel Le système opère en temps réel et supporte la consolidation hiérarchique comme de nombreux outils de Business Intelligence.

Caractéristique spécifique de la solution Type de Cube : M-OLAP.

Point fort : la performance.

Très mauvaise documentation.

Communauté

Sponsorisé par Jedox AG, 1 administrateur et 11 développeurs ont clairement étaient identifiés.

Taux de fréquentation est assez faible.

Taille visibilité Internet relativement bonne.

Bon niveau de packaging.

Dispose pas d'une traduction Française.

OS Indépendant.

Difficile à déterminer du fait de son jeun âge.

03 avril 2008

(30)

Chargement des données

Les outils disponibles de chargement de données sont peu rapides.

Fonctionnalités

De part leur conceptualisation, il est possible d'utiliser pleinement les techniques d'analyse propres aux Cubes OLAP.

Outils

D'une manière globale, les outils sont plus performants que ceux existants pour les Cubes R-OLAP. Néanmoins, il est à noter que d'une part, certains outils ont du mal à traiter les bases de données de plus dix dimensions et, d'autre part, que de par leur multidimensionnalité, les clients OLAP sont les seuls outils capables de communiquer avec.

Requêtes

L'optimisation du stockage permet une rapidité d'exécution des requêtes. Cependant, leur performance n'est pas au rendez vous sur ce type de données.

Stockage

La taille de stockage des données est plus faible que dans les Cubes relationnels, et ce même pour des données similaires. De plus, le modèle tableau permet l'utilisation d'un indexage naturel qui s'avère puissant.

Volume de données

Bien que ce type de Cube ait des difficultés à traiter un grand nombre de données, le problème est approximativement contourné par la mise en place de processus incrémentaux, vérifiant uniquement les données modifiées, ou les mises à jour.

Conclusion

Le point fort de l'architecture multidimensionnelle est la possibilité d'utiliser des techniques d'analyse extrêmement poussées. Bien que certains outils aient du mal à traiter des bases de plus de dix dimensions, il restent tout de même plus performant, que ceux reposant sur les Cubes R-OLAP. A noter cependant qu'il ne sera pas possible d'utiliser des outils de reporting différents sur ces tables, de par leur architecture. La conception du Cube est également à la base d'un des atouts fort du M-OLAP : une taille de stockage plus faible, du fait d'une conception optimisée, ainsi qu'une rapidité d'exécution des requêtes. Bien que ce modèle ne soit pas le plus à même p traiter un volume important de données, le problème est contourné par la mise en place de processus incrémentaux. Néanmoins, soulignons que les outils de chargement des données sont peu rapides, et que la conception de Cubes M-OLAP entraîne une redondance des données.

Le serveur Palo repose quant à lui sur une architecture de type M-OLAP. Bien que son niveau d'activité soit moins important que celui de Mondrian, mettons cet aspect en relation avec son jeune âge (moins de deux ans). Ce point doit tout de même être pris en considération car il implique également que la documentation autour de ce projet est très faible et que les compétences partenaires à son sujet sont rares. Le point fort de Palo est que ce dernier s'intègre dans un projet propre à l'analyse dimensionnelle, incluant ainsi un client Web (Palo Web Client) et un client lourd (Palo Client).