Neo4J contre SAP Hana

Il y avait un petit moment que l’on n’avait pas eu de meetup Neo4J sur Paris ! C’est donc avec une façon un peu provocante d’aborder un sujet à connotation BI que nous avons été invités !

Nous étions environ 30 à nous rendre ainsi dans le showroom Zenika.

image

Introduction

Cédric Fauvet, toujours égal à lui-même nous fait son habituelle introduction sur les graphes. Presque habituelle, devrais-je dire, car il fait un peu évoluer son propos de meetup en meetup, tout comme son support.

image

Aujourd’hui, le spectre des problèmes couverts par les bases orientées graphes couvre :

  • La collaboration
  • Le SCM
  • L’analyse géo-spatiale
  • L’étude des interactions moléculaires
  • L’analyse d’impact
  • Le MDM
  • La gestion de lignes-produit
  • Et bien entendu la recommandation et les liens sociaux !

En Juin, Neo4J France devrait nous gratifier d’une présentation d’un projet « Dropbox-like » réalisé par des étudiants !

Cédric attire également notre attention sur le talk de Volker Pacher expliquant pourquoi Neo4J augmentait la capacité de delivery de Shutl (acquis depuis par eBay).

Il est l’heure de la pause pizza, nous allons bientôt attaquer la pièce maîtresse de la soirée !

image

Analyse des tickets de caisse avec Neo4J

Nicolas Mervaillies et Charles Besselièvre nous présentent le projet qu’ils ont développé pour « un grand client retail ». Il s’agit d’un petit projet, c’est à dire moins de 100 j/h, qui devait être développé rapidement. Sur les projets analytiques orientés « real time », cette enseigne s’appuie généralement sur SAP Hana. Mais ce projet tactique présente des échéances de temps incompatibles avec ce type de projet, plus adapté à des solutions légères menées en agile.

image

La problématique est essentiellement simple : trouver des corrélations d’achats. Vous savez, celles qui ont permit de déterminer que les couches culottes sont souvent achetées en même temps que le bière le samedi ou qui ont permit à une enseigne d’apprendre via des bons d’achat à une jeune fille qu’elle était enceinte avant qu’elle même ne le sache ! Ici les corrélations doivent être croisées entre magasins et entre régions. Pour chaque magasin, il faut compter une volumétrie de 300 millions de lignes de ticket par an.

Phase 0 : Prototypage

Pour cela on utilise simplement la console Neo4J ! En fait, on ne représente pas chaque ligne d’achat en liaison avec le ticket de caisse : on agrège ces lignes par sous-familles. Bien sûr, les tickets sont associés à une date, un client et un magasin.

Grâce à cela, on voit avec Cypher si l’on parvient à produire les analyses que l’on souhaite.

Phase 1 : Construction initiale

Premier fonctionnement en production : les données de ticket de caisse sont récupérés tous les mois et injectés avec Spring Batch. Le client peut agréger les données en live via des requêtes Cypher : dans le temps, par famille de produits, par magasin.

Les couplages repérés avec de forts pourcentages sont donc mis en exergue dans certains magasins, on compare les éléments différenciants des magasins ayant de moins bons taux de corrélation !

On a toutefois un problème : trop de lenteurs, dû aux fortes volumétries, mais aussi au déploiement de Neo4J sur des serveurs virtualisés. La virtualisation et les bases de données, ce n’est pas le grand amour, même si certains ingénieurs système essaient de se convaincre du contraire !

Phase 2 : Focus sur le « top 15 »

En analysant les données des différents magasins, on perçoit dans le temps des réccurrences d’association, notamment dans le « top 15 ». Nos artistes choisissent donc de précalculer les associations significatives, celles correspondant au « top 50 » de chaque magasin, mais sans Marc Toesca !

Phase 3 : Optimisation de production

En dernière phase, il faut finalement réaliser des optimisations purement de production : gestion de l’infrastructure, mise en place de cache, etc…

En conclusion…

L’utilisation de Neo4J est parfaitement adaptée à ce type de projet tactique : on a la rapidité de de mise en place et la vitesse d’exécution de ce projet typique d’un projet agile ! Par rapport à SAP Hana, on gagne réellement en time to market !

L’équipe a aussi développé un front-end pour faciliter l’utilisation du système. Mais à la limite, cela aurait pu être omis !

Concernant l’infra : elle a été gérée complètement en interne pour des raisons de non exposition de données sensibles. Toutefois, on a une machine puissante qui ne sert que quelques heures, une fois par mois ! Ce type de configuration se marrie donc bien avec le Cloud.

Enfin, l’aspect communautaire de Neo4J permettant de trouver de l’aide sur les forum a été un plus important !

Faute de disposer du support de présentation, je vous propose ici l’enregistrement de la même session qui s’est déroulée au meetup Neo4J Lillois !

Ce que j’en ai pensé

C’est probablement le meetup Neo4J le plus interactif et le plus convivial auquel j’ai pu assister. Les interventions fort pertinentes d’un connaisseur SAP Hana ont été un gros plus dans la discussion, surtout quand, comme lui, on connait et sait reconnaitre les qualités de ce système. Il est là, juste derrière moi.

Pour clore ce compte-rendu et donner un avis éclairé sur cette confrontation, je le citerai :

« Remplaçons notre argent par notre intelligence ».

Cela me rappelle un peu un slogan des années 70 où il était question de pétrole…

Note de lecture : Expert Cube Development with Microsoft SQL Server 2008 Analysis Services, parChris Webb, Alberto Ferrari & Marco Russo

Note : 6 ; Peut-être pas expert, mais certainement éclairé.

Comme son nom l’indique, ce livre a pour but de faire de vous un « expert » du décisionnel avec SQL Server et plus précisément avec son sous-ensemble Analysis Services. Expert est certainement prétentieux. Disons, raisonnablement opérationnel. Pour arriver à nos fins, ce texte compte 330 pages sur 10 chapitres. Voyons ce qu’il en est.

Le premier chapitre s’abstrait de SQL Server pour présenter les fondamentaux de la conception de modèles OLAP. Il est assez surprenant de pragmatisme et d’efficacité. La plupart des choses que l’on a besoin de savoir sont couvertes dans ses 36 pages.

Le second chapitre ressemble déjà plus à du Packt publishing : on est guidé pas par pas vers la création d’un premier cube simple. Le 3ème chapitre y fait suite avec des éléments plus complexes comme les SCD.

Les aspects mesures et groupes de mesures complètent le panel de ce que l’on peut faire sur les dimensions au chapitre 4.

Les chapitres 5 à 7 se focalisent sur les aspects analyse. D’abord avec le forage de données au chapitre 5, puis avec l’ajout d’indicateurs calculés au chapitre 6 et enfin avec des opérations de conversion au chapitre 7.

Les 3 derniers chapitres ont une coloration « production ». Ca commence au chapitre 8 avec l’exploration des aspects performance. On y parle partition, agrégations et tuning des requêtes MDX. Le chapitre 9 explore les aspects sécurité de façon assez approfondie, plus qu’on en a le plus souvent besoin. Par contre le sujet de l’accès au cube par http mérite le détour. Le chapitre 10 porte le doux nom de « productionization ». On y parle beaucoup gestion des partitions. Enfin le chapitre 11 aborde le monitoring mais n’est pas inoubliable.

Contrairement au livre de Larson, celui-ci fait le choix de se focaliser uniquement sur la construction du cube et non pas sur tout le processus décisionnel qui inclurait alors SSIS. Même si l’on peut arguer que les approches sont différentes et les livres difficilement comparables, je préfère Larson à la fois plus complet et plus pédagogique.

Parmi les points intéressants : des conseils d’usage pour ne pas se retrouver le bac dans l’eau et des liens vers des articles de blog développant tel ou tel aspect…

Expert Cube Developpement with Microsoft SQL Server 2008 Analysis Services

Référence complète : Expert Cube Development with Microsoft SQL Server 2008 Analysis Services – Chris Webb, Alberto Ferrari & Marco Russo – Packt Publishing 2009 – ISBN : 978-1-847197-221

Expert Cube Development with Microsoft SQL Server 2008 Analysis Services

https://www.goodreads.com/book/add_to_books_widget_frame/1847197221?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

SQL Server et l’agilité

Le GUSS, c’est à dire le Groupe des Utilisateurs de SQL Server organisait cette rencontre pour évoquer un sujet qui m’est cher au sein d’une communauté pas franchement reconnue pour son adhésion à l’agilité. Franchement, je ne savais pas à quoi m’attendre !

Déjà un bon point pour le cadre de rencontre convivial, certainement à retenir pour de prochaines Scrum Beer !

GUSS-Avril13-01

Maintenant, arrivons-en au fond. Je ne vais pas laisser trainer le suspens : j’ai passé une excellente soirée !

L’agilité est un sujet jeune dans cette communauté, on n’y trouve pas la touche de suffisance que l’on croise par ici ou le regard blazé que l’on rencontre par là … L’enthousiasme est là, avec l’envie d’avancer , la soif de faire mieux et le questionnement sur ce que l’on fait.

En parlant de questionnement, j’ai été aussi surpris par l’ouverture d’esprit des personnes présentes. J’ai souvent été confronté dans ce milieu à des personnes prisonnières de leur paradigmes, empreintes de dogmes pour ne pas dire de certitudes. Rien de tel ce soir-là.

Il me serait difficile de vous faire un compte-rendu circonstancié des discussions, mais je vais évoquer quelques points qui m’ont marqué. Dans le désordre.

Les limites de l’outillage

On peut aimer les outils qu’on utilise et faire preuve de lucidité à leur égard. La difficulté principale rencontrée par les développeurs BI utilisant Integration Services semble être l’aspect monolithique des solutions SSIS qui rendent inopérants les fonctionnement en branches avec les merges que cela nécessite.

Le second point évoqué est le problème de la resynchronisation des métadonnées qui fonctionne manuellement et nécessite de repasser sur tous les packages. Si on souhaite travailler sur un modèle de manière itérative, on fait face à ce problème très rapidement, et c’est d’autant plus handicapant que le projet est gros…

Le future du BI agile n’est peut-être pas le cube

Travailler sur un cube de manière itérative n’est pas facile. Vraiment. D’abord si on souhaite faire des “sashimi”, on devrait travailler sur un modèle de données évolutif. Or la synchronisation des métadonnées de SSIS est un obstacle à cela.

D’un autre côté, il n’est pas possible de rajouter des dimensions à un cube une fois en production, car cela remet en cause la granularité des faits qui alimentent déjà le cube !

Mes observations et mes réflexions m’amènent à penser que l’avenir du BI et surtout du BI agile réside dans des solutions “sans schémas” adoptées de manière différentes par le monde des bases NoSQL, je pense surtout aux bases orientées colonnes comme Hadoop. Il s’agit là non seulement de la disparition du schéma explicite, mais d’un paradigme différent où la structuration de la données disparait au profit de la capacité à retrouver cette donnée et à la traiter, et souvent de manière scalable. Un aspect prépondérant quand le monde du BI est tiré vers le Big Data.

C’était mieux avant…

Une voix discordante s’est élevée au milieu de ces reflexions agiles.

“Lors d’une itération, on a oublié de décliner des règles métiers sur d’autres tables. Avec un cycle en V, la spécification détaillée aurait pris en compte cela et évité l’erreur.”

Bien sûr l’argument ne tient pas. Notre interlocuteur aurait dû au contraire se féliciter de n’avoir eu à attendre qu’une itération pour corriger un oubli que le cycle en V ne saurait pas plus garantir ! De toute évidence, la contre-argumentation est d’ors et déjà acquise pour nos DBA Agilistes. Que du plaisir !

La difficulté d’un résultat de sprint démontrable

Quand je demande à mes interlocuteurs de m’expliquer leurs découpage en sprint, j’entends un motif recourent : d’abord un sprint de modélisation de base, un ou plusieurs sprints d’alimentation de Sas, puid d’ODS, viennent enfin les sprints de construction de cube puis de présentation !

C’est le moment de prendre mon air horrifié : pourquoi ne pas construire les sprints verticalement, avec une tranche fine allant de la modélisation de la base à la présentation en passant par les différents étages d’alimentation ?

Nous avons donné la réponse plus haut : la difficulté de construire une table de fait dont la granularité se rafinerait au fur et à mesure de l’ajout de dimensions, la pénalité de SSIS aux changements de métadonnées, etc…

Seconde question, donc : mais alors, si vous n’allez pas au bout de la tranche, que démontrez-vous ?

La réponse est bien sûr : ce qu’on peut ! Dans le cas d’un sprint de modélisation, par exemple, ce sera le modèle de données. Sur papier !

Bref, Scrum c’est l’art du possible, mais il y a vraiment matière à progression de ce côté. On en est pas au “vrai Scrum” !

Le poids des cérémonies de Scrum

Autre point évoqué : 2 semaines, c’est court, et en plus il faut ménager du temps pour la démo, la rétro, le planning meeting. Sans compter que ce dernier se trouve souvent pénalisé par la découverte “in situ” des aspects fonctionnels, laissant la portion congrue de la réunion au découpage en tâches et à l’estimation.

Ces problèmes ne sont ni nouveaux, ni spécifiques au BI avec SQL Server. Ce sont des choses que j’ai rencontré avec des équipes de développement Java. De ce côté nous avions amélioré les choses avec quelques pratiques courantes ou non :

  • Découpage en 2 (à quelques jours d’interval) du planning meeting : un volet découverte fonctionnel, et après 2 jours pour réflechir et assimiler, un pur planning meeting plus court.
  • Des workshops de tests d’acceptance regroupant développeur, PO, client final (quand il est différent) et représentant de l’équipe de test (quand il y en a une).
  • Et bien sûr des rétrospectives pour introduire des pratiques, alléger ou faire disparaitre celles qui paraissent inutiles.

En ensuite…

Pas mal d’échanges, l’envie d’aller plus loin … Le GUSS a émis l’idée d’une table ronde, elle me plait bien ! Tout le monde a l’air motivé, donc peut-être d’ici Juin ?

Note de lecture : Agile Analytics, par Ken Collier

Note : 4 ; L’agilité expliquée aux praticiens du décisionnel

Lorsque j’ai acquis ce livre, j’escompté en savoir plus sur l’adaptation et les spécificités de la mise en œuvre de l’agilité dans le monde du BI. Beaucoup de choses y sont différentes par rapport aux projets de développement : les outils, l’architecture et la cinématiques des applications, l’environnement et la culture. Pourtant, il m’apparaît évident qu’un mode de travail collaboratif et fortement itératif est particulièrement adapté aux projets décisionnels, alors que le mode de travail généralement admis dans le milieu emprunte au « cycle en V » avec sa litanie de phase de spécification, de modélisation et de recettage et sa structuration en MOA / MOE.

En fait, ce n’est pas l’angle du livre. Celui-ci s’adresse au praticien du projet décisionnel, justement celui qui est un habitué du projet mené à l’ancienne. Si, comme moi, vous êtres déjà un habitué des principes et pratiques agiles dans un projet classique mais êtes désireux de connaître comment celles-ci se déclinent dans le monde du BI, ce texte n’est pas pour vous !

Il n’en demeure pas moins que l’auteur connaît son affaire, aussi bien sur le volet agile que sur les projets décisionnels. Pour ce qui est du volet agile, ses deux mentors sont Jim Highsmith et Scott Ambler. J’approuve pour le premier, moins pour le second. Quoi qu’il en soit, ses sources d’inspiration sont très visibles au long de l’ouvrage. Mais il est temps de passer au livre lui-même.

Le texte compte environ 300 pages, divisées en 10 chapitres, eux-mêmes regroupés au sein de 2 parties : Mangement methods (140 pages) et technical methods (le reste).

Toute la première partie, constituée des 5 premiers chapitres, reprend les principes de base de l’agilité. On y trouve peu de matériel qui soit une déclinaison des principes agiles adaptés au monde du décisionnel. Le chapitre 1 qui compte 24 pages est une introduction qui répond à la question du « pourquoi » de l’application d’agile au monde du BI.

Le chapitre 2, long d’une trentaine de pages, traite de gestion de projets agile. Elle reprends pratiquement point pour point, les principes du même noms énoncés par Jim Highsmith dans « agile project management », avec notamment le cycle « envision / explore ». Le lecteur déjà familier avec la prose de Jim Highsmith ne sera pas perdu par le texte. Mais on peut aussi noter que Ken Collier possède bien son sujet et le traite fort bien.

Au chapitre 3 traite de la collaboration, qui n’est pas là non plus un sujet de première fraicheur pour les agilistes, mais les points importants y sont bien traités. J’ai bien aimé le modèle « doers / planners / customers » dans cette partie.

Ce sont les users stories et l’estimation qui forment la matière du chapitre 4. Le sujet n’est plus guère original, pas plus que je n’ai trouvé d’éléments d’adaptation au monde du décisionnel.

Cette première partie se conclut par le chapitre 5 consacré à l’auto-organisation des équipes. Parmi les éléments intéressants, j’ai relevé le « 6 hats of thinking » que j’emploierais à l’occasion pour mes rétrospectives. Le reste est bel et bien du classique. Cette première section me laisse bien sur ma faim, même si j’ai pu en picorer quelques éléments intéressants par ci par là…

La seconde partie est aussi formée de 5 chapitres et s’avère plus prometteuse sur le papier. On commence par le chapitre 6 « evolving excellent design » qui compte quand même 50 pages. L’auteur y expose son modèle d’architecture décisionnelle incrémentale basée sur du message queue. C’est intéressant mais on est hors sujet par rapport au livre ! L’auteur peut être certainement fier de sa réalisation, mais ne peut-on appliquer agile dans le BI que par le biais de cette architecture ?

Le TDD et le Data Warehouse est le sujet du chapitre 7. C’est hélas très abstrait et peut d’élément pour la mise en œuvre. Sauf peut-être une petite astuce technique avec Microsoft SQL Server Integration Services. Ca tombe bien, c’est mon ETL ! Mais comment font les autres ?

Nous arrivons au chapitre 8 qui traite du versionning. Il nous dit qu’il faut versionner (grande nouvelle), en utilisant … Subversion ! Après nous avoir expliqué qu’il faut versionner les sources et non les produits générés (ce que je sais depuis pas loin de 20 ans), eh bien on est arrivé au bout du chapitre !

On se rapproche doucement de la fin : le chapitre 9 traite de l’automatisation, mais là encore si on a un peu d’éléments sur ce qui est une séquence de build typique sur un projet BI, le reste traite d’outils qui ne sont plus de prime jeunesse … comme Ant !

L’ouvrage se termine au chapitre 10 avec des propos plus généraux comme la conduite du changement en milieu décisionnel.

Bref, ce livre m’a déçu, en grande partie parce que je n’étais pas le bon public. Cela se reflète sur la note, mais c’est la règle du jeu. Comme je l’ai dit au début, l’auteur connaît sa matière, ses matières devrais-je dire et il est parfaitement crédible pour traiter le sujet. La prose tend à tirer un peu trop en longueur, ce qui est dit sur 300 pages pourrait l’être sur 220 pages sans nécessiter de sacrifices sur le contenu. Le fil rouge du case study vécu est généralement rafraichissant, mais il est raté ici : les épiques sont trop longues et ne servent pas correctement le sujet.

Faites attention à être la bonne cible avent de débuter cette lecture. Sinon, celle-ci risque d’être frustrante.

Agile Analytics

Référence complète : Agile Analytics, a value-driven approach to business intelligence and data warehousing – Ken Collier – Addison Wesley / ASD series 2012 – ISBN : 978-0-321-50481-4

Agile Analytics: A Value-Driven Approach to Business Intelligence and Data Warehousing


http://www.goodreads.com/book/add_to_books_widget_frame/032150481X?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : Le Datawarehouse, guide de conduite de projet par Ralph Kimball & al.

Note: 3 ; Ennuyeux et obsolète

Ralph Kimball est le grand prêtre du DataWarehouse, il était donc logique que je me dirige vers l’un de ses ouvrages. Prendre une version française était alors le gage d’un certain « confort » par rapport à un sujet où je suis loin d’être à l’aise ! Finalement j’ai été déçu à plusieurs points de vue.

Tout d’abord ce volume est apparu comme assez ancien, âgé de 12 ans environ ! Le sérieux de l’éditeur français lançant une 4ème réimpression d’un ouvrage aussi démodé est en cause, alors même qu’une seconde édition américaine est sortie (la date de millésime de l’ouvrage d’origine n’apparait pas) ! De nombreux points relatifs à la technologie s’avèrent de fait sujets à caution. Sans remettre la totalité du livre en cause, cela relativise au moins 25% de son contenu.

Le second point à trait au contenu lui-même. Si le volume compte 550 pages, on n’a guère l’impression que le contenu utile le justifie. La moitié aurait suffit ! Notons quand même qu’il s’agit d’un guide de conduite de projet. On y collecte matière utile assez largement sur divers sujets : modélisation, recueil des besoins, architecture, modélisation et approche des extractions. On est assez loin des processus agiles avec une organisation assez rigide, mais j’ai quand même été assez surpris de voir une tendance en ce sens tout au long de ma lecture.

Le dernier point de déception fut d’apprendre rapidement qu’en fait cet ouvrage constituait la suite d’un précédant livre. Pour le moins, cela n’apparaissait pas évident et cela s’avère maladroit par rapport au lecteur. On est ainsi frustré de manière répétitive, surtout sur les parties traitant de la modélisation, par les renvois incessants au précédant ouvrage !

Au final, si le livre dispense d’excellents conseils sur la façon de mener un projet datawarehouse, il ne justifie guère le temps investi dans sa lecture. Sa dépendance par rapport à un livre précédant le rend d’autant moins plaisant à lire. Bref, hélas pas une lecture indispensable !

datawarehous-guide-conduite-projet

Référence complète : Le Datawarehouse, guide de conduite de projet – Ralph Kimball, Laura Reeves, Margy Ross & Warren Thornthwaite – Eyrolles 2005 (V.O. The Datawarehouse Lifecycle Toolkit, Expert methods for designing, developping and deploying Data Warehouses ; John Wiley & sons ; ISBN: 0471255475) – EAN: 978 2 212 11600 7

Le Datawarehouse, guide de conduite de projet


http://www.goodreads.com/book/add_to_books_widget_frame/18280882?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : Entrepôts de données, par Ralph Kimball & Margy Ross

Note : 5 ; Un véritable et ennuyeux tutorial sur la modélisation dimensionnelle

Comment effectuer la modélisation décisionnelle des principaux thèmes abordés en entreprise ? C’est la question à laquelle ce livre souhaite répondre. Assez curieusement, il y parvient plutôt bien. Et ce ne sont pas moins de 400 pages et 17 chapitres qui sont nécessaires pour atteindre ce but. 400 pages d’ennui mortel, hélas aussi. On compte en fait 3 parties à cet ouvrage, même si l’ouvrage n’est pas découpé ainsi :

La première partie est constituée du chapitre d’introduction. Il nous initie à la modélisation dimensionnelle, à l’architecture d’un système décisionnel et au vocabulaire utilisé pour cette modélisation : tables de faits et dimensions.

La seconde partie est dédiée aux traitement des domaines de l’entreprise. Sept chapitres y sont consacrés est consacrée. La chapitre 3 « grande distribution » est de mon point de vue à rapprocher de la 3ème partie. Je sais, il n’y a pas de découpage en parties à ce livre…

La troisième partie traite des secteurs d’activité, soit 7 chapitres.

La quatrième partie constituée des 2 derniers chapitres forme la conclusion du livre. Le chapitre 16 parle de processus d’ingénierie et sent bien la poussière, tandis que le chapitre 17 nous présente les perspectives d’avenir. Si certaines sont depuis bel et bien en marche, au moins ce chapitre nous donne-t-il à réfléchir.

Revenons sur la (virtuelle) seconde partie. Elle couvre de manière remarquable un très grand nombre de secteurs métiers : gestion des stocks, achats, gestion des commandes et de la relation client, comptabilité, ressources humaines et direction financière. Sur chaque partie, l’auteur se focalise sur les problématiques propres à ce secteur. Ainsi sur la gestion de stocks, les auteurs développent la notion de « transaction de stock », tandis que la modélisation des multiples tables de faits d’un processus d’achat est développée dans le chapitre suivant.

Tout comme la seconde partie couvre les activités standard d’une entreprise, les grands secteurs d’activité sont couverts par la 3ème partie : grande distribution, distribution (eau, électricité et télécommunication), transport, enseignement, santé, commerce électronique et assurance.

Chaque chapitre apporte des éléments de modélisation qui peuvent être propres au domaine métier, mais également transposables à d’autres domaines. Cela en fait un ouvrage de référence plutôt précieux.

En fait, le plus gros défaut de ce livre vient de son style incroyablement ennuyeux. En venir à bout est hélas une véritable torture.

entrepot-donnees

Référence complète : Entrepôts de données, guide pratique de modélisation dimensionnelle, 2nd édition – Ralph Kimball & Margy Ross – Vuibert 2003 (V.O. : The DataWarehouse toolkit, 2nd edition ; John Wiley & sons 2002) – EAN : 978 2 7117 4811 2

Entrepôts de données, guide pratique de modélisation dimensionnelle


http://www.goodreads.com/book/add_to_books_widget_frame/18280868?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : Delivering Business Intelligence with Microsoft SQL Server 2008, par Brian Larson

Note: 7 ; Une approche didactique, complète et progressive d’Analysis Services

Et encore un bon gros pave de 770 pages! Tout aussi effrayant que cela soit, j’ai en fait été surpris par l’aisance que j’ai eu à avaler les 19 chapitres de cet ouvrage. Il faut dire qu’ayant commencé par voir sur Amazon quel était le meilleur texte sur Analysis Services, je n’ai été qu’à moitié surpris. Je n’hésite pas à le dire, ce livre est un quasi parfait didacticiel, capable de remplacer une formation sur le sujet. Le contenu équilibre fort bien les aspects théoriques, la présentation des fonctionnalités SSAS et la mise en pratique par les « Learning by doing ».

La plus flagrante faiblesse que j’y vois concerne justement les « LBD » : j’ai trouvé les descriptions des mises en pratiques bien trop micro managées, à tel point qu’on finit par ne plus savoir ni comprendre ce que l’on fait ! C’est bien dommage, car par ailleurs ces exercices (et ils sont nombreux) ont des finalités tout à fait pertinentes.

Pour résumer, et avant d’en survoler le contenu, je dirais que ce livre recèle 2 gros points forts :

  • L’équilibre entre les explications théoriques sur les principes (qu’est-ce que le BI, qu’est-ce qu’UDM, quels sont les différents modèles OLAP, etc..), les explications sur la façon dont ils sont mis en œuvre dans SQL Server, et la mise en pratique concrète (les LBD dont nous avons parlé précédemment).
  • La couverture du sujet, qui ne se localise pas à Analysis Services sensu stricto, mais inclut la modélisation dimensionnelle (relationnelle), l’alimentation, la fabrication d’un Cube, l’analyse avec MDX et même le Data Mining et la mise en place de reports avec Reporting Services ou Excel et ses pivot tables !

Je ne vais pas rentrer dans le détail de la table des matières, ce serait trop fastidieux, mais simplement évoquer les 5 grandes parties du livre.

La première partie « Business Intelligence » couvre 5 chapitres totalisant 90 pages. L’objectif de cette partie est de mettre en place les concepts liés au BI : qu’est-ce que c’est ? Quand et pourquoi s’en sert-on ? Quels sont ces concepts liés au BI (data Mart, OLAP, UDM, etc..), à quoi ressemble une modélisation dimensionnelle ? Comment tout cela est-il architecturé dans le système ? Cette première partie se termine par une introduction à Visual studio qui sera abondamment utilisé par la suite.

La seconde partie « Defining business intelligence structures » est longue de 3 chapitres couvrant 200 pages ! Elle rentre dans le vif de la modélisation dimensionnelle et de sa mise en place dans une base relationnelle. Mais en fait, ce qui explique la taille de cette partie est la longue mise en pratique de SSIS. L’ETL Microsoft est par ailleurs le sujet de livres à part entière, mais j’avoue que les deux chapitres qui figurent ici n’ont pas à rougir avec certain d’entre eux ! Utilisant SSIS très régulièrement depuis 2 ans, j’y ai découvert des choses !

La troisième partie « Analysing cube content » avoue 170 pages découpé en 4 chapitres. Comme son nom l’indique, cette partie se consacre à l’exploitation du cube décisionnel. Mais avant de l’exploiter, il faut le construire ! On commence donc par concevoir le cube, avec ses dimensions et ses groupes de mesures, puis par le déployer. Une fois cela fait, on peut mettre en place des KPI, les relations de hiérarchie et autres agrégations. Et bien sûr, on termine par les opérations de navigation dans le cube, par SSMS ou via les requêtes MDX.

La quatrième partie se consacre au Data Mining, car SQL Server possède bel et bien des fonctions de data mining intégrées ! 90 pages organisées en 3 chapitres couvrent ce sujet. On débute bien entendu par une présentation de ce domaine et des différents algorithmes de data mining. Puis on pénètre réellement dans le sujet en construisant un « data mining model ». Le reste de cette partie est consacré à la mise en œuvre des différents algorithmes de data mining proposés par Microsoft.

La dernière partie « Delivering » s’étend sur 180 pages en 4 chapitres. Elle couvre la restitution d’information. Cette partie est surtout conséquente parce que l’auteur est par ailleurs un expert reconnu de Reporting Services (il est l’auteur d’un best seller sur le sujet). Donc Reporting Services couvre ici 3 chapitres, et plutôt de très bonne façon, reconnaissons-le, tandis que les Pivot Table sont réduites à la portion congrue, ce qui est un peu frustrant.

J’en ai terminé avec l’aspect descriptif. Voici maintenant mon conseil : Vous voulez vous mettre à SSAS ? C’est LE livre, ne le ratez pas.

delivering-bi-sqlserver2008

Référence complète : Delivering Business Intelligence with Microsoft SQL Server 2008 – Brian Larson – McGraw-Hill 2009 – ISBN: 978 0 07 154944 8

Delivering Business Intelligence with Microsoft SQL Server 2008


http://www.goodreads.com/book/add_to_books_widget_frame/0071549447?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on