I'm Charles-Henri Sauget,
Let's share our knowledge together !

Excellent Mister Sauget!
Je suivrai ton pas à pas de mon côté, ça va être fun :)

PS : tu sais que je suis un relou, mais quand je vois que tu nommes "ODS" ta base de staging y'a mon petit coeur qui pleure... C'est un DS ce truc là, un ODS c'est autre chose, enfin 2 choses différentes selon que tu parles le Kimballien ou l'Inmonien. J'ai prévenu, je suis relou :p

Hello Florian,
Oui j'ai longuement hésité à utiliser le terme (c'est d’ailleurs pour ça que j'ai mis les deux :p) ... La frontière entre ODS et Staging Area étant assez flou en fonction de qui en parle ...
Exemple :
http://infodecisionnel.com/datawarehouse/ods-vs-staging-area/
http://www.geekinterview.com/question_details/44839
...
Mais OK, c'est vendu, je l'enlève!

Tu peux le laisser, chacun fait ce qu'il veut, faut juste s'entendre sur ce que ça veut dire ^^

De mon côté j'ai les définitions suivantes:
* Pour Kimball l'ODS c'est une copie conforme des bases sources (mirroring) qu'on pourra requêter en paix toute la journée sans impacter la production (cf Russo et Ferrari).

* Pour Inmon ce sont des datamarts spécialisés construits pour être lus par d'autres applications qui souhaitent s'alimenter sur le DWH.

Dans le DS - DataStage - tu peux ou non persister tes données sources, c'est un autre débat que celui ODS/DS.

Oh le mec qui coupe les cheveux en 4. Il est pénible ce Fleid :)

Par contre qu'il y ait ou non un ODS (pour faire plaisir à notre ami Fleid :) ), tes tables de collectes n'ont pas de raison d'exister dans ton schéma et sont exactement ta staging area.

Ensuite intervient un chargement avec nettoyage (DQS ici si tu veux) que tu stockes soit dans un ODS (données non agrégées à rafraichissement plus régulier qu'un DWH), soit directement dans ton DWH (toujours dans un soucis de plaire à Fleid, car je le sais friand de cette méthode)

Peux-tu être plus précis sur les raisons de la suppression des tables de collectes ?

Après réflexion (et aussi après avoir mangé) je pense que tu as raison, finalement mes tables de collectes n'aurons pas de réelle valeur ajoutée.
Good point M. Joubert ! D'ailleur même Microsoft est d'accord avec toi : http://msdn.microsoft.com/en-us/library/cc719165%28SQL.100%29.aspx

Charles-Henri je ne suis pas sur que tu aies compris la remarque du DJ. Ce qu'il veut dire c'est tes tables de collecte sont dans ton ODS. Elles n'ont donc pas à apparaître toutes seules comme ça dans ton schéma.

Autrement dit: tu n'as pas une base de collecte et une base de staging, tu as une seule base de staging qui contient des tables de collecte, des référentiels, des tables de transcodage, des tables pour ta qualité de donnée, etc etc...

Vouloir te passer de tables de collecte c'est comme faire de la haute voltige sans filet. Tu peux le faire, mais si tu te plantes ça te fera mal :p

Et je pense que vous êtes encore allé manger chez le Portugais qui sert du rouge, parce que je ne vois pas vraiment où tu trouves que MS confirme ça dans le doc que tu links :)

Après discutions téléphonique avec David pour voir plus clair, ce que je comprends c'est qu'il fait une collecte avec minimum de modifications (type de données ...) dans la base de staging (que j'ai appelé collecte mais qui correspond bien à cet esprit) ensuite il alimente un ODS avec des modifications plus lourde (Corrections de données, règles de gestion) que j'ai appelé Staging.
Pour coller à ce vocabulaire il faudrait donc que j'apporte les modifications suivantes:

-Renommer Collecte en "Staging"
-Renommer Staging en ODS

Par contre l'"ODS" ainsi crée (et qui ne plait pas à Florian) est absolument facultatif dans la mesure ou on pourrait charger directement les données modifier dans le D/W.

Messieurs à votre bon cœur...

Florian, tu as du ouvrir stracraft-bo à la place du lien ...

Si tes commentaires intégraient des liens hypertextes (bonjour 1993!), je ne me tromperais peut-être pas de sites... ;)

Pour terminer sur le sujet, je ne suis pas particulièrement fan de partir à fond sur des "ODS" de stockage des données nettoyées. On en a déjà discuté en long en large et en travers avec le DJ, et aucun de nous 2 n'a réussi à convainvre l'autre :)

Pour moi, soit tu nettoyes tes données et tu les charges dans un modèle en étoile pour l'exploiter, soit tu veux les archiver et alors tu les laisses au format original. Archiver des données nettoyées c'est la meilleure recette pour arriver à TFACMDVDC_02 (pour ceux qui connaissent).

Je comprends l'intérêt d'avoir un "ODS" nettoyé pour régener systématiquement un schéma en étoile clean à chaque chargement - Marco Russo et Alberto Ferrari le recommandent d'ailleurs dans leur doc - mais c'est une architecture qui correspond à un cas particulier qui n'est pas le cas général. La choisir comme option par défaut est pour moi problématique.

Mais il y a des liens hypertext, je ne comprends pas :)

Donc disons CSV -> Staging Area (comprenant mes collectes) -> Cleaning DQS et règles de gestion lors du chargement du D/W -> D/W -> ...

Cela contenterait tout le monde ?

Je te kiffe :)
Fais ce que tu veux, tant que tu assumes derrière ;)

Je pense que le point souvent négligé est qu'un datawarehouse contient des données agrégées (normalement).

L'intérêt d'un ODS est donc de garder les données au niveau fin.

Charles-Henri en passant, quand on ajoute un commentaire et qu'on le poste, la page est rafraîchie mais on voit pas le commentaire.
Je suis sur que tu peux facilement corriger ça.

Nop Mister, en tout cas ni en Kimball ni en Inmon.

Dans le schéma en étoile on conserve la granularité la plus basse possible. Tu te souviens dans l'introduction du Datawarehouse Toolkit c'est dans les 10 mythes concernant la modélisation dimensionnelle. Je sais que tu l'as lu dernièrement en plus :)


MOUAHAHAHAHAH

Recommencez pas votre débat ici ! :)

David j'ai bien pris ton commentaire sur les commentaires je m'occupe de ça !

Fleid, toi aussi mon fils, un kimballien convaincu aura noté que la définition du datawarehouse selon Kimball est l'ensemble des différents datamarts.

La définition d'un datamart :

Le DataMart est un ensemble de données ciblées, organisées, regroupées et agrégées pour répondre à un besoin spécifique à un métier ou un domaine donné. Il est donc destiné à être interrogé sur un panel de données restreint à son domaine fonctionnel, selon des paramètres qui auront été définis à l’avance lors de sa conception.

donc ton datawarehouse kimballien est par définition agrégé. CQFD

OMG tu la sors d'où cette définition? :)
Si tu parles de dwh kimballien, prends la définition du datamart par Kimball, sinon c'est triché ;)

Toi je sens que tu troll pour le plaisir de troller on dirait :D

PS: Charles-Henri, je commence à douter que 2+2 font 4, ça aussi y'aurait moyen de le changer plz :)

Définition de Kimball : Le DataMart est un sous-ensemble du DataWarehouse, constitué de tables au niveau détail et à des niveaux plus agrégés, permettant de restituer tout le spectre d’une activité métier. L’ensemble des DataMarts de l’entreprise constitue le DataWarehouse.

Tu préfères un vieux captcha impossible à recopier ?

C'est la definition wikipedia, j'ose espérer que le mec a recopié le bouquin.

Apres faut bien que je trouve pourquoi on m'a toujours fait faire un ODS, déjà que personne est d'accord avec ce qu'on met dedans. :p

bonjour, je me permets de participer a ce debat interessant. Pour l'archi, je dirai que si 'ods est historise alors on peut monter une multitude de datamart qui compseront le datawarehouse. si l'ods n'est pas persistant alors le datawarehouse doit avoir le niveau le plus fin degranularite. Concernant le nettoyage et l'application de regle de gestion, je suis ok pour le cleaning avant le dwh.Par contre l'application de regle de gestion doit intervenir le plus tard possible (entre dwh et dmt) pour minimiser les impacts des eventuelles evolutions des regles de gestion sur le dwh. a vous lire Guillaume (www.guillaumelecerf.fr)

Guillaume,

Encore une fois il faut savoir de quelle théorie on parle. Un datamart Kimball contient le niveau le plus bas de granularité - il le répète assez dans tous ses bouquins - contrairement à un datamart Inmon qui lui agrège les données. A mon sens l'historisation de l'ODS ne doit pas rentrer en ligne de compte à ce niveau là.

Pour l'application des règles de gestion, l'argument de les appliquer le plus tard me plait beaucoup. Cela dit il existe des règles qui seront toujours vraies et/ou qui sont trop lourdes pour être exécutées au moment du requêtage, et qui donc gagnent à être calculées par l'ETL.

Guillaume,

Encore une fois il faut savoir de quelle théorie on parle. Un datamart Kimball contient le niveau le plus bas de granularité - il le répète assez dans tous ses bouquins - contrairement à un datamart Inmon qui lui agrège les données. A mon sens l'historisation de l'ODS ne doit pas rentrer en ligne de compte à ce niveau là.

Pour l'application des règles de gestion, l'argument de les appliquer le plus tard me plait beaucoup. Cela dit il existe des règles qui seront toujours vraies et/ou qui sont trop lourdes pour être exécutées au moment du requêtage, et qui donc gagnent à être calculées par l'ETL.

Merci pour votre réponse,

Je vous rejoins sur les aspects théoriques mais pour être en phase avec les projets et les problématiques de nos clients (ou sociétés), il faut souvent anticiper le besoin de demain. Ainsi, si l'ODS est non historisé et qu'on a un datamart selon Inmon, l'ajout d'une nouvelle dimension entraine une phase de reprise de données (à moins que la dimension n'ait un sens qu'à partir de la mise en prod). Les reprises de données sont souvent galères d'ou mon idée de conserver quelque part l'ensemble des données au niveau de granularité le plus fin. Voici une raison pour laquelle, j'aime associer :
ODS histo avec DMT Inmon
ODS tempo avec DWH Kimball

En effet, toutes les règles de gestion ne peuvent pas etre réalisées au moment du requetage. Par le passé, j'ai rencontré des architectures un peu hybride du type :
ODS tempo avec DWH Kimball puis DMT agregé
Les règles étaient donc calculées avec l'ETL entre le DWH et le DMT.
Guillaume