Data Warehouse -->ODS<--

[AA_27]

Bonjour à Tous,

Actuellement je travail sur la conception d'un Data Warehouse souhaitant regrouper l'ensemble des activités d'une entreprise (c'est d'ailleurs le rôle du DW !).

simplement, ce qui est naturel dans les DW !, mes bases de données sont répaties sur plusieurs sources de données comprenant chacune une activité clé de l'entreprise.

je que je veux faire c'est qu'avant d'arriver au niveau du DW, je veux passer par un ODS (Operationnel Data Store) sous forme d'une base tempon qui va accueillir l'ensemble de mes bases de données.

ma question :

- Est-ce possible d'heberger plusieurs bases de donnes issues de différentes sources (access, Notes,fichier plats, SQL server...) dans un seul et même ODS ?. si oui comment ?

car l'objectif de tout ça est de pouvoir faire des transformations sur ces bases de donnes, les étudiées avant de les chargées définitivement dans un vrai Data Warehouse !

les bases de donnes susceptibles de se retrouver dans l'ODS sont :
- BD_Commerciale
- BD_Activite
- BD_RH
- BD_Compta
- BD_Paie
- ...
après les avoir importés dans un même ODS, l'étude me permetra justement de définir par example les dimention partagés, et les transformation nécessaires (traitement des champs null ...)

Merci d'avance,

Amara.

[tbabulle]

Re-bonjour Amara,

Je vais essayer d'être exhaustif et clair car ta question regroupe plusieurs questions.

Envoyé par AA_27

- Est-ce possible d'heberger plusieurs bases de donnes issues de différentes sources (access, Notes,fichier plats, SQL server...) dans un seul et même ODS ?. si oui comment ?

Effectivement c'est tout à fait possible. Si tu as des sources multiples avec des formats différents, tu devras te poser 2 questions :
1- est-ce que je veux 1 seul ODS (1 seule base de données) avec toutes mes données, et dans ce cas tu devras transformer tes sources pour les mettre toutes au même format.
2- est-ce que je veux conserver mes sources dans leurs formats d'origine, et donc pour se faire créer autant d'ODS que nécessaire.

Pour rappel, un ODS est "juste" un "tampon" dans lequel on va mettre les données évènementielles du jour, de la semaine, .... de la période que l'on a choisi comme mise à jour du DWH.

Envoyé par AA_27

car l'objectif de tout ça est de pouvoir faire des transformations sur ces bases de donnes, les étudiées avant de les chargées définitivement dans un vrai Data Warehouse !

Aie aie aie, là ça se gate. Un ODS n'est certainement pas fait pour ça. Les transformations que tu devras faire se feront "entre ODS et DWH", voir après le DWH pour alimenter des DataMarts (DM).
Dans l'ODS, je te conseille vivement de n'avoir que le reflet exact de tes données source, au format près. Par exemple si ta source est une table Access, et que tu as décidé que ton ODS serait en Oracle, avoir l'équivalent Oracle de ta table Access.

Par principe, tu dois être en mesure de tracer l'ensemble des infos de ton DWH, que ce soit de l'interface (portail) de restitution, vers le DWH ; ou de l'ODS vers le DWH. Car si tu as un plantage à l'alimentation, comment remonter tes processus sans faire un backup... et un backup dans la BI avec quelques TO de données cela peut être très drôle... demande à ton DBA

Envoyé par AA_27

après les avoir importés dans un même ODS, l'étude me permetra justement de définir par example les dimention partagés, et les transformation nécessaires (traitement des champs null ...)

Fondamentalement, c'est le genre de chose que tu dois faire AVANT de commencer. C'est réellement la phase amont du projet : Définition des besoins, des règles de gestion, phase de conception, analyse détaillée, ....

Voilà j'espère avoir été clair et avoir répondu au mieux à tes questions.
A ton service

Thierry
tbabulle@objectif-informatique.fr

[AA_27]

Merci tbabulle,

Effectivement, la question que j'aurais dû posé et qui répond réellement à mes besoins actuels est la suivantes :

--> Je veux conserver mes sources dans leurs formats d'origine, et donc pour se faire créer autant d'ODS que nécessaire.

sachant que le travail se fera sous SQL Server 2005, donc j'importe les sources de données (différentes base de données) en créant un ODS propore à chacune des source tout en gardant le format bien sûr.

ma motivation pour cette solution vient du fait que j'ai choisi l'architecture Ascendante c-à-d, je met en place d'abord mes DataMarts puis construire le DW global.

d'ailleurs je me suis mis à charger source par source dans SQL Server 2005. et pour cet effet je souhaite accéder à plus de doc concernant les lot SSIS (EX lot DTS !)si vous en connaissez quelques unes ?

Encore merci pour toute vos intervention et commentaire

Amara.

[kijak]

Bonjour,

Je développe actuellement une solution BI dans le cadre d'un stage et c'est dans ce cadre que j'ai déjà terminé la conception de mon DDS suivant les besoins fonctionnels et non fonctionnels et puisque j'ai opté pour l'architecture ODS+DDS, je dois maintenant faire la conception de mon ODS. Et ma question est : est-ce que l'ODS a la même conception que le DDS sauf que le premier est normalisé ou bien est-ce qu'ils ont deux conception totalement différente ?

Merci d'avance.

[hoss69]

Tu veux dire quoi par DDS ??

Concernant l'ODS (Operating Data Staging), il sert à enregistrer les données en provenance des applications opérationnelles sources. C'est une sorte d'espace (Base de donnée par exemple) temporaire qui est vidé à chaque nouveau chargement. Les données présents dans l'ODS sont généralement organisé de la même façon que la source.

Tous simplement :
c'est une copie des données sources pour un chargement

[Jester]

La confusion est souvent faite entre l'operational data store et le data staging. Pour moi le data staging correspond à une copie des données de prod, c'est aussi là où on fera des transfo intermédiaires si besoin.

L'ODS correspond à des données de qualité data warehouse, mais qui sont accédée par l'opérationnel (i.e. le temps de réponse doit être assez court). Du coup, on ne conserve que les données récentes.

[hoss69]

Merci pour la correction

[Melvine]

Salut Jester,

Je ne te suis pas trop ,
un ODS c'est censé contenir les données dont on a besoin pour alimenter un data warehouse.

J'ai des sources hétérogènes (fichier client,table client sqlserver,table client access..);dans mon ODS j'aurai une table client qui elle va contenir les données des différentes table client (sur une période donnée)
et ensuite à partir de cette table,je vais faire des transformation
puis alimenter mon DW.

Du coup je travail sur l' ODS et non les bases de production
et donc pas d'accès concurrent,pas de lenteur...
et si jamais l'intégration des données plante dans le datawarehouse;
je pourrai la recommencer.
Est-ce bien cela ?

Par contre,ton data staging,
je capte pas trop ce que c'est et à quoi cela sert ?

[Jester]

Pour moi on peut faire :
prod -> data staging -> ODS -> DWH

ou bien :
prod -> data staging -> DWH -> ODS

Ce qui est le clone pure de la prod c'est le staging. Dans de nombreux cas c'est aussi l'ODS. Généralement avant d'avoir mis en place une stratégie BI, l'entreprise faisait son reporting avec ça. Il subsiste du legacy pour une période qui peut être infinie voire d'autre dev avec le staging qui dans ce cas devient l'ODS. Ce n'est pas propre mais c'est ce qui arrive très souvent. Quand presque plus personne ne fait de query dans le data staging, le project DWH est un succès.

Ensuite vient l'étape de clean et d'intégration qui donne des data de qualité supérieure. En général ça remplit directement le DWH. Comme le process est journalier ou hedbomadaire, de toute façon ça ne correspond pas à des besoin opérationnels. On a usuellement des process ETL de plus grande fréquence pour remplir l'ODS et qui peut aussi utiliser le DWH (pour obtenir le scoring client par exemple).

Je n'ai jamais vu de process ETL qui remplit l'ODS, puis cette ODS qui est utilisé pour remplir le DWH. Ce n'est pas forcément une mauvaise idée, mais c'est plus compliqué à faire et ensuite on arrive vite à une boucle où l'ODS remplit le DWH et le DWH enrichit l'ODS.

[Melvine]

donc en faite l'ODS serait une sorte de copie de la base de production.
du coup comme c'est sur la même base que la base de production alors
pas besoin de l'etl pour l'alimenter.

[hoss69]

Bonjour,

Envoyé par Melvine

donc en faite l'ODS serait une sorte de copie de la base de production.
du coup comme c'est sur la même base que la base de production alors
pas besoin de l'etl pour l'alimenter.

Je suppose que tu voulais dire ODS ?

Jester, je n'ai jamais croisé dans ma courte expérience une alimentation de l'ODS depuis le DWH (DWH -> ODS) . Peux-tu nous donner un cas d'utilisation ?

Merci

[Jester]

Le cas arrive quand on extrait de nouvelles infos des données du data warehouse : prévisions de charges, scoring client, collaborative filtering. Par exemple le people you may know de LinkedIn ou les suggestions d'Amazon peuvent tomber dans ce cas.

[hoss69]

Merci pour ta réponse
Je profites pour t'embêter encore avec mes questions
Ça sert a quoi de dupliquer ces données, calculées au niveau DWH, dans l'ODS ?
Merci encore

[Jester]

1- pas sur qu'on ai envie qu'une application (e.g. CRM) tappe directement dans le DWH.
2- Le DWH gardera sans doutes l'historique et plein d'autres choses inutiles.
3- Le DWH n'est pas indexé pareil, par exemple il n'y a pas forcément d'index sur l'id client. Inutilisable donc par une appli qui veut des temps de réponses rapide.

Après il y a aussi la réalité. Si c'est un scoring, le score sera sans doute exporté dans la DB de l'appli CRM. Si c'est des prévisions de charge, ce sera exporté dans le système de planning.

[hoss69]

C plus clair
Merci pour les exemples concrets