Blog éclectique & sans sujet précis - “The Data Warehouse Lifecycle Toolkit” (Second Edition) de Ralph Kimball & co - Commentaires<p>Si ça me passe par la tête, si ça n’intéresse que moi, alors c’est peut-être ici. Ou pas.</p>2024-02-13T09:44:49+01:00L'éditeur est le propriétaire du domaineurn:md5:bf83720a7189bba489682d945b972671Dotclear“The Data Warehouse Lifecycle Toolkit” (Second Edition) de Ralph Kimball & co - Le webmestreurn:md5:488dab253077b652dddf6b32854b90182021-06-25T17:06:01+02:002021-06-25T16:06:01+02:00Le webmestre<p>@Kazan : oui, je ne pense pas que le domaine se soit amélioré en 10 ans (je l'ai quitté depuis, DBA ça occupe assez et on ne s'embête plus avec des cliquodromes).</p>
<p>Déjà il y a 10 ans on voyait le NoSQL, la non-modélisation, le datalake (aka gros foutoir), la self-BI où l'utilisateur final se débrouille tout seul dans son coin pour contourner l'informatique trop lente à répondre, tout ça n'a rien arrangé.</p>
<p>Je pense surtout que les modélisateurs n'ont pas vraiment été formés. Il y en a qui confondent BI et simple copie de tables via un ETL, sur lequelles l'utilisateur final plaquera un Qlickview ou un Tableau ou le truc à la mode ce jour-là. Et comme il veut tout, tout de suite, on n'a jamais le temps de faire un truc carré.</p>“The Data Warehouse Lifecycle Toolkit” (Second Edition) de Ralph Kimball & co - Kazanurn:md5:e3debbed8f636f9f15da4145d86ff1222021-06-25T16:28:14+02:002021-06-25T15:53:08+02:00Kazan<p>Je découvre un confrère en SGBDR, dix ans après !<br />
J'ai lu ce bouquin de Kimball, il y a 3 ans entre deux missions, et il est très inspirant ! Si certains concepts sont discutables, c'est très clairement la praticité et le bon sens qui prennent le dessus.</p>
<p>Et c'est d'autant plus drôle que, lorsque je reprends des DWH (une demi-douzaine avant la lecture de ce bouquin, deux ou trois après) la plupart des modélisateurs font tout l'inverse ou ignorent (pas de tables de dimension temps, on mélange les relations N/M, on veut absolument tout historiser parce que "on sait pas ce que veut l'utilisateur, donc pour être sûr on lui fournit l'historique...")</p>“The Data Warehouse Lifecycle Toolkit” (Second Edition) de Ralph Kimball & co - Le webmestreurn:md5:0eead601fceba919215a8055711600d92012-09-06T19:03:01+02:002012-09-06T18:03:01+02:00Le webmestre<p>@vpo : Pour un décisionnel c'est pire car c'est transverse, pas directement lié à un domaine, ça pose plein de questions, parfois gênantes, ça oblige les gens à réfléchir, ça n'a pas forcément d'utilité directe pour les personnes impliquées (leurs données serviront à d'autres, mais ils seront bien contents d'avoir accès aux données d'autres domaines), et ça finit souvent par prouver que tous les rapports existants autrefois, sur lesquels des carrières se sont bâties, calculaient n'importe comment.</p>“The Data Warehouse Lifecycle Toolkit” (Second Edition) de Ralph Kimball & co - vpourn:md5:54f7d5f774564cdc542a5f719fc6a7082012-09-06T13:00:54+02:002012-09-06T12:00:54+02:00vpo<p>règle n°1 : se trouver un sponsor de poids capable d’imposer aux autres de bosser pour le projet datawarehouse que tout le monde attend sans vouloir lui consacrer une seconde</p>
<p>C'est le cas pour tout projet. Si le sponsor du projet n'a pas le pouvoir ET la volonté de soutenir le projet cela risque fatalement d'être un fiasco. C'est le grand classique du projet stratégique voulu par les chefs mais qui ne veulent pas mettre de sous dedans / de gens dessus car, "tu comprends, y a pas le temps / de ressource / etc".</p>
<p>Bah faut pas le faire alors ça économisera un poste de chef de projet pour un truc voué à l'échec.</p>“The Data Warehouse Lifecycle Toolkit” (Second Edition) de Ralph Kimball & co - Le webmestreurn:md5:e7709f3e3afc1d8a1ebc370f4a30d2762012-09-05T21:10:59+02:002012-09-05T20:10:59+02:00Le webmestre<p>@Eric : Quand je dis que le bouquin n'est pas pour les débutants dans le métier, je sous-entends que c'est le cas aussi pour le billet. Ce qui fait une intersection vachement réduite avec mon lectorat habituel :-)</p>
<p>DW = datawarehouse (je viens de corriger). Le modèle en étoile c'est une table de faits avec que des indicateurs (~chiffres) et des clés étrangères vers des tables de dimensions. Floconner c'est ajouter des tables de deuxième niveau (FAIT-VENTES -> DIM-MAGASIN -> DIM-VILLE -> DIM-DEPT ->DIM-REGION : 3 niveaux de floconnage) alors que le mieux est quand même une étoile pure (FAIT-VENTES contient les clés vers toutes les autres ; oui c'est redondant mais dans ce genre de base on ne normalise pas, on pense aux perfs pures).</p>
<p>Le « grain » de la table de faits, c'est en gros sa clé primaire, un regroupement de certaine des clés étrangères (mois/magasin/produit par exemple). On essaie de faire des tables au grain le plus fin possible. Le choix de floconner ou pas dépend en partie des différents grains nécessaires.</p>“The Data Warehouse Lifecycle Toolkit” (Second Edition) de Ralph Kimball & co - Eric C.urn:md5:02505412861f00e600e2b84526563a8b2012-09-05T10:41:54+02:002012-09-05T09:41:54+02:00Eric C.<p>Ma curiosité polythématique superficielle chronique fait qu'il y a peu de domaines dont le vocabulaire m'est totalement étranger (ce qui ne veut pas dire que j'y comprends quelque chose), mais là, en lisant<br />
"Autre grand moment de modélisation : je floconne, ou je floconne pas <a href="https://www.coindeweb.net/blogsanssujetprecis/index.php?post/11" title="11" rel="ugc nofollow">11</a> ? Kimball et son équipe sont des adversaires déclarés de la normalisation dans DW (l’étoile, rien que l’étoile, ça allège les jointures), et plus le temps passe, plus j’évolue comme ça aussi. Après, faut voir si les grains des tables collent."<br />
j'avoue que je n'ai pas pu m'empêcher de réprimer un sourire du genre "mais keskidi ?" :)</p>