Pas ça ! (tiré du blog : coding horror de jeff Atwood)
La vallée en question correspond, sur un schéma, à la zone de perception négative ressentie par un observateur humain face à un robot humanoïde.
Cette expression utilisée dans le monde de la cybernétique peut etre étendue à d'autre domaine comme celui des architectures applicatives.
Actuellement , une barrière existe entre les applications de gestion et les applications décisionnelles. Souvent l'utilisateur est obligé de quitter l'application de gestion pour se rendre dans un environnement décisionnel distinct et réciproquement. Ce clivage se retrouve au sein même d'une direction informatique. Le décisionnel est fréquemment géré par des équipes spécialisées et dédiées. Ce fossé est historique, le décisionnel a toujours été qualifié de 'stratégique' , c'est l'aristocratie de l'informatique , par les technologies utilisées et par la nature de ses utilisateurs. La fin inéluctable des clients lourds de restitution au profit du client léger à sonné le glas de cette suprématie. Les éditeurs de suite décisionnelle ont été obligés d'empiler des couches de composants hétéroclites et se sont dispersés. L'erreur grave a été de vouloir faire d'un portail décisionnel le portail métier de l'entreprise. La tendance est à l'inverse: le décisionnel vient s'intégrer dans les infrastructures de l'entreprise tel un CMS ou un wiki.
Le schéma de l'infrastructure peut etre le suivant:
Avec deux problèmes a régler:
Comment alimenter l'entrepôt (modèle en étoile) à partir de la base de gestion ?:
* Par requete SQL : ici la base de production n'a pas l'initiative du transfert des données.
* Par fichiers d'extraction générés par la base de production : il faut développer du code d'extraction et de mise en forme des données.
* Par synchronisation par dblink ou autre: Cette solution est à déconseiller pour des soucis de performance et de sécurité de la base de production.
La solution 1 reste la plus simple à mettre en oeuvre.
Le problème du calcul des agrégats.
Calculer par avance les agrégats , au moment du chargement (ou avant ???) est une pratique courante. Avec comme inconvénient d'avoir une gestion complexe de recalcul d'agrégat sur des antérieurs.
Mondrian adopte une stratégie fine qui consiste à calculer les agrégats à la volée ou à utiliser des tables d'agrégats indépendantes.
Le problème est identique pour une restitution de résultat de recherche : quand indexer les données ? Au chargement ou après le chargement.
Des solutions ?
Dans le '01 informatique de fevrier' un article titrait : comment se passer des entrepôts de données ? La solution est peut là.
Il est possible d'utiliser un système NoSQL à la place d'utiliser un modèle en étoile dans un SGBDR. Le NoSQL peut être une base cle/valeur :couchDB ou une table en colonne (Bigtable)
Si on regarde les connecteurs disponibles pour Jasperreport :
En rouge : les connecteurs XML : soit par lecture d'un fichier XML soit par l'appel d'un service distant en RESTFull.
Remarque: les sources entourées de vert : JasperReport est capable de s'interfacer directement avec du mondrian.
Concernant la lecture d'un fichier XML, il ne sera pas nécessaire de générer un fichier dans le répertoire puis de lancer le compilateur de jasperreport. Il est possible par exemple de générer à la demande le flot XML et de l'envoyer directement par un 'pipe' au programme XmlJasperInterface et de récupérer l'etat généré dans le flot de sortie.
Un exemple est donnée ici en Ruby on rails :How to Integrate JasperReports with Ruby on Rails.
L'utilisation d'un flux distant est encore plus simple, une simple URL suffit.
Il faudrait donc remplacer l'entrepôt par une base clé/valeur capable de générer du XML et de faire de l'indexation à la volée: ce produit miracle existe c'est couchDB.
Nativement couchDB restitue ses résultats au format JSON ou XML . CouchDB sait utiliser des algorithmes MAP/REDUCE qui permettent de distribuer le travail d'indexation sur plusieurs processeurs ou sur plusieurs machines nativement grace au Erlang (voir la page de wikipédia). Cette technique qui est la poule aux oeufs d'or de google est la seule capable de traiter des gros volumes de manières distribuées (voir ici le détail).
Avec tous ses composants , l'intégration des restitutions du domaine décisionnelles dans une application de gestion devient possible.
(voir aussi les travaux sur ce thème de SAP )
Aucun commentaire:
Enregistrer un commentaire