Les Journées SQL Server 2013 : à ne surtout pas rater!

Alors ok, vous connaissez la rengaine, on est reparti pour la promotion du prochain événement du Groupe des Utilisateurs SQL Server, le GUSS, ALORS OUI MAIS NON !

Parce que pardonnez-moi le ton mais… honnêtement cette année on déchire comme jamais au niveau du contenu!

Les JSS2013 ça déchire

Jugez vous-même :

Agenda des JSS2013PS : Oui vous pouvez cliquer dessus si c’est trop petit 🙂

Sur chacune des 2 journées vous retrouverez 2 thèmes, qui sont instanciés côté moteur (dba/SQL) et côté BI :

  • Jour 1, le lundi 2 décembre, on causera des nouveautés SQL 2014 d’une part, et de l’infrastructure et du cloud de l’autre, avec par exemple :
    • Un deep dive sur Hekaton, le in-memory OLTP de SQL Server
    • Une présentation sur PDW v2, la nouvelle solution pour les méga DataWarehouse de Microsoft (miam miam des PetaBytes !)
    • Une bonne grosse tranche de Power BI, pour être certain d’être bien à jour sur la nouvelle vague d’outils BI de notre éditeur favori
    • Un retour sur l’infrastructure, avec comment bien monter son hard pour SQL Server, que ce soit par la BI ou plus globalement avec une vision datacenter
  • Jour 2, le mardi 3 décembre, on causera Usages et Outils d’une part, et on creusera les sujets en mode Perfectionnement de l’autre, avec entre autres :
    • Un panorama exhaustif de tous les sujets à maîtriser pour un dba SQL Server : les stats, les locks, la haute dispo…
    • Toujours pour les dba et aussi pour les développeurs SQL, des choses un peu plus originales comme une session dédiée à vous expliquer les langages bizarres du décisionnel, des astuces pour bien gérer SQL Server pour SharePoint, ou encore un focus sur l’Agilité et son impact sur les bases de données
    • Côté BI on a MARCO RUSSO !!!!! Est-ce que j’ai besoin d’en dire plus ? Bon ok : du SSAS et du SSIS côté perfectionnement, et côté usages et outils, une matinée Big Data et une après-midi BI Agile. Je vais revenir sur la BI Agile parce que je fais partie de la track, mais honnêtement ça me fait rêver : TDD, Tests automatiques, BIML… On s’équipe enfin côté BI !

Ajoutez à ça des tables rondes sur la gestion de carrière, sur l’agilité, et surtout avec les Girls in Tech, ça va bien le faire.

Et puis niveau sponsor on a du lourd cette année, ils seront tous présents dans la zone d’exposition, donc que vous cherchiez un prestataire ou un futur employeur, vous êtes obligé de trouver !

Comme d’habitude les inscriptions sont gratuites, ce sera les lundi 2 et mardi 3 décembre, dans le centre de conférence de Microsoft à Issy-Les-Moulineaux (Paris), alors venez – et faîtes passer le mot 😉

Journées SQL Server 2013

Modélisation dimensionnelle à éviter : La table de faits universelle

Comme vous le savez peut-être, cette année encore je co-animerai la session Modélisation Dimensionnelle aux Journées SQL Server 2012, les 10 et 11 décembre sur Paris, avec mon camarade Charles-Henri. Cette année on passe level 300 (ça commence à causer plus sérieusement) et franchement je pense qu’on va passer un bon moment 🙂

En attendant le jour J, je voulais vous parler d’une technique qui ne sera pas présentée lors de la session : celle de la table de faits universelle. Rencontrée chez un client dernièrement, c’est une modélisation qu’on peut aussi appeler la table de faits unique. Une table de faits pour les gouverner toutes. Une table de faits pour les trouver. Une table de faits pour les amener toutes et dans les ténèbres les lierHumJe divague

Je te vois faire n'importe quoi!

Je te vois faire n’importe quoi!

Si ça avait été fait par un stagiaire, ou un client qui s’essayait au décisionnel en dilettante, je trouverais ça mignon. Sincèrement. J’applaudirais pour l’effort et on prendrait une demi-journée ensemble pour causer modélisation. Mais là c’est réalisé par une équipe de consultants spécialisés dans le décisionnel.  Et c’est facturé. Moins mignon.

Alors voyons à quoi ça ressemble:

La table de faits universelle

Dans cette même table de faits, qui s’appelle juste « Fait » (c’est plus simple) on retrouve :

  • Les ventes quotidiennes
  • L’inventaire hebdomadaire
  • Les budgets trimestriels des magasins
  • Les objectifs trimestriels des commerciaux

C’est quand même bien fait ! On a tout sous les yeux d’un seul coup. Pas besoin de jointures, les requêtes SQL sont simplissimes. Alors que reprocher à cette modélisation ?

Déjà, je vous avoue qu’en 6 ans de missions en décisionnel, je n’ai jamais vu ça. J’en ai même parlé lors d’un afterworks du GUSS, auquel étaient présents des consultants d’à peu près tous les pure-players en décisionnel Microsoft, et personne n’en avait entendu parler non plus.

Mais vous me connaissez, je n’allais pas me limiter à ça. Regardons donc ce qu’en dit la littérature :

  • Wikipedia – Fact Table : “In data warehousing, a fact table consists of the measurements, metrics or facts of a business process.”  Une table de faits pour un processus métier donc, les ventes ou l’inventaire ou les budgets… mais un seul. J’avoue, en effet, ils auraient pu insister et mettre: “ a SINGLE business process”. Mais à mon avis personne ne se doutait qu’on verrait arriver la table de faits unique.
  • Wikipedia – Base de données relationnelle : « Dans une base de données relationnelle chaque enregistrement d’une table contient un groupe d’informations relatives à un sujet (…) ». Même commentaire, et là on parle de toute la technologie de la base de données relationnelle, plus seulement du décisionnel.
  • Ralph Kimball, l’inventeur du schéma en étoile, indique lui que chaque table de faits représente un processus métier, que chacune de ces tables est reliée à des dimensions, les mêmes dimensions pour tout le monde (alors dites conformées), et que toute la valeur de la modélisation en étoile vient justement de là. Parce qu’entre nous, quitte à faire une table de fait unique, autant pas s’embêter à faire des tables de dimensions hein… Et là le lien je le fais par vers un article spécifique, mais vers le bouquin de Kimball, parce qu’à un moment il va falloir le lire ce livre si vous vous dites consultant ou développeur décisionnel.
  • Bill Inmon, l’inventeur du schéma en flocon, indique la même chose. En effet les différences entre les deux modèles se situent au niveau de la structure des dimensions et du processus de génération du modèle, pas des tables de faits.
  • Et quid de Datavault ? La troisième modélisation très contestée du décisionnel ? Là c’est pire puisqu’on normalise complètement et qu’on conserve le format source original (une table pour les clients, une table pour les magasins, une table de relation entre les 2, etc, etc). Pas de table unique en vue.

Pas de chance, la littérature ne fait donc aucune mention de cette technique, et c’est même plutôt l’inverse qui est recommandé : créer une table de faits par processus métier. Soit dans notre cas, 4 tables : ventes, inventaires, budgets et objectifs.

Je précise au passage que dans ces sources, il ne faut pas interpréter la phrase « la table de faits est au centre du schéma en étoile » comme une indication qu’il n’y en ait qu’une seule. En effet un datawarehouse ce n’est pas un mais plusieurs schémas en étoile, plusieurs datamarts, autant qu’il y a de processus métier. Et en théorie l’ensemble de ces étoiles s’appelle une constellation, mais ça devient trop poétique donc on emploie rarement le terme.

D’une manière plus pratique, si on abandonne la littérature et qu’on s’interroge sur les mérites d’une telle modélisation, on peut se faire les réflexions suivantes :

  • Performances
    • A priori elles ne seront navrantes. En effet pour aller chercher un élément particulier de la table (les budgets), le moteur doit parcourir toutes les lignes de la table (les ventes, les inventaires…). C’est largement inefficace.
    • L’index le plus rapide de tous est l’index cluster (celui qui dicte comment les données sont écrites sur le disque). Comme vous le savez, on ne peut en définir qu’un seul par table (par définition). Tout mettre dans la même table c’est donc se priver d’un des meilleurs outils d’optimisation de la base de données. A la place d’en avoir un par processus métier, il n’y en aura qu’un seul, qui en plus ne sera pas très bon. Car évidemment, l’index s’optimise différemment en fonction du sujet. On indexe les ventes (par jour/magasin/produit) différemment qu’on indexe les objectifs (par trimestre/commerciaux). Et croisez les doigts pour que l’unicité des lignes des 4 processus métiers tiennent en moins de 16 colonnes.
    • Même remarque pour le partitionnement.
  • Confort d’utilisation / Qualité du requêtage
    • Si on s’économise les jointures en SQL, j’ai peur de ce à quoi vont ressembler les clauses WHERE. Et on n’a pas intérêt à se tromper sur ces filtres, sans quoi on va additionner des choux et des carottes (des quantités de ventes et des quantités d’inventaires). Le risque métier est important avec cette approche, il est inexistant avec la modélisation classique.
    • Et là où les jointures reviendront en force, c’est si on veut obtenir un état avec par exemple du budget et du facturé. Il faudra en effet faire une auto jointure (en FULL OUTER JOIN) de la table unique sur elle-même. Ce sera douloureux en écriture de requête et en performance.
    • Enfin, on l’a bien compris, impossible d’exposer ce modèle directement à un utilisateur. Il faudra définir un modèle de métadonnées devant chaque outil de reporting (Excel, Tableau, SSAS, SSRS…). Attention au coût de développement masqué.
  • Maintenabilité / Evolutivité
    • J’ai peur que l’ajout d’un nouveau processus métier (comme il est prévu dans le lot 2 j’imagine ?) ne se traduise par l’ajout de nouvelles colonnes dans cette table. Dans ce cas il faudra changer toutes les requêtes déjà développées (clauses WHERE, agrégations), toutes les métadonnées, et toutes les optimisations déjà réalisées. En somme il faudra tout refaire. A chaque évolution.
    • Enfin, si on s’enferme dans cette architecture, impossible de trouver un prestataire digne de ce nom qui assurera la TMA ou les évolutions sans d’abord tout refondre.

Bon et bien on le voit, si c’est une nouvelle théorie, c’est l’équivalent de remplacer les groupes sanguins par les signes du zodiaque pour déterminer la compatibilité dans les transfusions sanguines. De temps en temps ça va marcher, certes, mais sur le long terme…

Et sinon, comment modéliser ça de manière satisfaisante ?

En identifiant les dimensions utilisées pour chaque processus métier, leur grain, et en construisant les tables de fait en fonction (c’est dans le livre, ou dans le webcast) :

Oh la jolie étoile!

PS : Les périodes temporelles diverses (semaines, trimestres) sont gérées directement dans la dimension temps.

Là on dispose d’une constellation composée de 4 étoiles, qui utilise des dimensions conformées (partagées), qui répond aux problématiques de performance, de confort d’utilisation et de maintenabilité. Si on souhaite intégrer un nouveau processus métier, on ajoute une nouvelle table de faits, sans avoir à modifier l’existant. Chaque processus peut évoluer indépendamment des autres. Chaque amélioration d’une dimension profite à toutes les analyses.

De tout ça on en reparle lundi 10 décembre, aux Journées SQL Server 2012. Inscrivez-vous 😉

Petit guide pour bien naviguer lors des événements de la communauté

Ho le vl’a qui radote encore sur la communauté!

Hé oui! Quatre articles sur le sujet en deux semaines, il faut croire que ça me tient à cœur 😉

Si vous vous interrogez à venir à un afterwork ou à une conférence, que vous ne savez pas quoi faire lors de ces réunions, quoi dire, comment rompre la glace, alors vous êtes bien tombés !

Parce que ces questions peuvent sembler stupides, mais ce n’est pas toujours évident de savoir créer des rencontres lors de ces événements très artificiels. En effet la rencontre d’une dizaine de personnes qui ne se connaissent souvent même pas de vue, c’est assez étrange. D’autant plus pour nous autres informaticiens, dont les aptitudes sociales ne sont pas toujours le point fort…

Déjà rassurez-vous : ces drôles de rencontres sonnent faux et artificiel pour tout le monde. A part peut-être pour JP, qui a définitivement ça dans le sang, sinon les premières fois vous allez certainement vous demander ce que vous faites là. Et c’est une très bonne question à se poser : qu’êtes-vous venu chercher à cet événement ?

Car si j’encourage les sociétés à s’interroger sur pourquoi elles font les choses, je crois sincèrement que c’est une démarche qui s’applique également au niveau personnel. C’est de là que vous tirerez la motivation nécessaire pour appréhender ce type d’événement, avant que vous ne veniez simplement pour le plaisir de retrouver les copains que vous vous serez fait (mon cas désormais).

Venir à un afterwork, participer à une conférence comme les JSS2012, c’est faire un choix actif dans sa carrière, tout comme s’abonner à une newsletter technique ou à un blog, ou encore acheter et lire un livre traitant de son métier. A mon sens, dans un monde où la plupart se suffisent du minimum, ce sont des actes forts qui montrent une volonté de prendre sa carrière en main. Alors ok ce sont de petites étapes, mais ce sont les premières et elles sont incontournables.

Maintenant pourquoi vous voulez prendre votre carrière en main ? Il n’y a que vous pour répondre à cette question. Mais je ne peux que vous féliciter de ce choix !

Ça c’était la théorie. Pour la pratique, les choses sont simples :

  • Je l’ai déjà dit, oui tout ça sonne faux, artificiel, et oui tout le monde le ressent. Donc on peut ignorer le sentiment et passer à autre chose 😉
  • Il n’y a aucun problème à ce que vous restiez dans un coin à observer pour les premières fois, histoire de sentir la température et vous habituer à la chose. Mais ça ne doit pas devenir une habitude (confère vos objectifs)
  • S’il y a des tours de table de présentation, pas de honte à juste bredouiller rapidement son prénom, son poste et sa société. Certains n’aiment pas prendre la parole en public, les organisateurs le savent, et passeront vite la parole au suivant s’ils sentent un malaise.
  • Vous pouvez facilement entamer la conversation avec n’importe qui en utilisant la méthode de Jen Stirrup :
    • Si ce n’est pas déjà fait, vous vous présentez rapidement : « Bonsoir moi c’est David. Je suis Animateur Décisionnel chez Itecor, et vous ? »
    • Vous pouvez échanger sur vos technologies de prédilection dans la stack BI : « Moi je suis un fan de SSIS, l’alimentation c’est pour les garçons ! Et vous ? »
    • Vous pouvez interroger la personne sur son parcours, pourquoi la BI, pourquoi Microsoft, pourquoi ce poste ? « Animateur décisionnel ? Vous ne connaissez pas ? Je vais vous expliquer… »
    • Et je rajoute : vous pouvez évoquer vos projets actuels (techniquement parlant, notez qu’il y a toujours un petit tabou sur le nom des clients), ainsi que vos dernières difficultés techniques, et là je suis sûr qu’il y a matière à tenir 3 ans de conversation avec ça 😉

Si malgré tout ça vous vous sentez mal à l’aise, qu’il y a des gros creux de conversations, ou des sous-groupes qui ricanent dans leur coin, c’est que les organisateurs se sont plantés. Perso je ne leur jetterai pas la pierre, organiser ce genre d’événement n’est pas évident. Donc laissez leur une deuxième chance, et si les mêmes choses se reproduisent, c’est en effet qu’il faut changer de groupe… Sauf si ça vous arrive à un afterwork du GUSS, là vous avez le droit de nous faire un retour sanglant, histoire qu’on s’améliore 🙂