Discussion :

[elmounia]

bonjours à tous

SVP je veux connaitre c quoi exactement ODS (operational data store ), j'ai déjà lu queleque définition mais j'ai pas bien compris
Merci

[lalystar]

Bonjour,


En général, c'est un couche d'acquisition dans laquelle tu fais les chargements de données (SQL*Loader)... Une fois les données purifiées, tu les intègres vraiment à ton DW.


Laly.

[Melvine]

en quelque sorte un ods c'est une table temporaire ?
ou c'est une base de donnée identique au futur systeme decisionnel mais qui se trouve sur le serveur de l'etl ?

[nuke_y]

L'ODS c'est un concept.

Chez nous il y a 2 schemas (pour simplifier) dans la BDD de production : le schema ODS et le schema DWH.

L'ETL va chercher tous les jours des données dans 4 sources différentes (SQLServer, Oracle, DB2 sur AS400 et fichiers plats) et insère les données brutes dans des tables du schema ODS. Par exemple la table ODS.Clients_full_extract, ODS.Ventes_full_extract, ODS.Produits_full_extract, etc.

Puis des process d'extraction + conversion + filtre ont lieu et copient les données de ces tables dans ODS.Clients_filtré, ODS.Ventes_filtré, ODS.Produit_filtré, etc.

Ca permet de ne pas trop compliquer les traitements en travaillant par Extraction/transformation indépendantes. Une fois que TOUS les traitements sont faits et que les données sont bonnes les tables ODS.Clients_final, ODS.Ventes_final, ODS.Produit_final sont alimentées. Ces tables ont EXACTEMENT la même structure et les mêmes contraintes que celles du DWH.

Pour finir on peut alimenter le DWH en faisant une copie STRICTE de ce qu'il y a dans les tables final de l'ODS et les tables du DWH.

L'intérêt de cette technique c'est que ça te permet de dissocier les traitements, de ne pas perdre d'information et surtout de TRES BIEN gérer les rejets, les alimentations par Delta, etc.

Par contre c'est consommateur de temps ET de place.

Tu remarques bien évidemment que l'ODS PEUT se trouver sur une autre BDD que le DWH. Par contre il est conseillé que ce soit dans la même technologie et la même version.

voila si tu as d'autres questions...

PS : on ouvre quand une section décisionnel et Business Intelligence ?

[Melvine]

donc l'ods à le même schema que le dw, et contient aussi les contraintes clé etrangere ,clé primaire ?
Est ce que les tables dans l'ods contienne des contraintes d'integrité c'est à dire est ce qu'elle sont lié entre elles comme dans le dw ?
Et l'ods est utilisé en faite pour permettre de continuer à bosser sur le dw pendant que la phase de chargement des données , c'est pour reduire le temps de chargement ?

[nuke_y]

Alors ça dépend. Si on peut le mieux c'est qu'un schéma de l'ODS soit une réplique exacte du DWH d'un point de vue structure et contraintes. Ca permet de vérifier qu'il n'y aura pas d'erreur sur les clés étrangères, etc.

Maintenant ça dépend des contraintes du système car multiplier les ODS successifs avant la copie dans le DWH ça prend du temps et de la place. LE minimum pour moi c'est :

un schéma ODS_BRUT qui contient des tables qui recoivent les données brutes depuis les différentes sources

un schéma ODS qui contient les tables avec une structure proche de celle du DWH (on peut imaginer que les tables de cet ODS aient des champs supplémentaires par rapport au DWH, comme DATE_CREATION de type DATE et DATE_MODIF qui permettent de savoir quand est-ce qu'on a manipulé les données). Les données des tables de ce schéma peuvent être manipulées, transformées, traitées, modifiées, plusieurs fois avant la copie dans le DWH.

un schéma DWH dans lequel on viendra copier les données de l'ODS.

[Melvine]

donc dans un ODS et en general,les tables sont relié entre elle avec clé etrangere et primaire?

[Melvine]

L'ods se trouve dans le data staging area ?ou l'ods=le data staging area ?

[Melvine]

[nuke_y]

Qu'appelles-tu data staging area ?

[sg-40]

J'ai trouvé cette définition sur le net pour un ODS :
" An operational data store (ODS) is a type of database often used as an interim area for a data warehouse. Unlike a data warehouse, which contains static data, the contents of the ODS are updated through the course of business operations. An ODS is designed to quickly perform relatively simple queries on small amounts of data (such as finding the status of a customer order), rather than the complex queries on large amounts of data typical of the data warehouse. An ODS is similar to your short term memory in that it stores only very recent information; in comparison, the data warehouse is more like long term memory in that it stores relatively permanent information."

Ils disent qu'un ODS est fait pour le requêtage simple. Est ce une utilisation fréquente ?

Les tables de l'ODS sont elles généralement effacées après traitement ?

Par rapport au DW comment est géré l'intégration des deltas quotidiens ?

Merci.

[nuke_y]

An ODS is designed to quickly perform relatively simple queries on small amounts of data (such as finding the status of a customer order), rather than the complex queries on large amounts of data typical of the data warehouse.

Je ne suis pas trop d'accord mais ce n'est que mon avis.

Déjà parce que l'ODS ne contient des données que sur une faible période : si on archive par mois par exemple, on va garder 1 mois d'historique + le mois en cours, donc entre 1 et 2 mois de données dans l'ODS. Donc faire une requête dans l'ODS, sauf si c'est pour VERIFIER les données avant l'intégration dans le DWH, c'est sans trop d'intérêt pour moi. Sauf dans le cas où la bascule ODS/DWH n'a lieu que tous les n périodes de temps. Dans ce cas il est intéressant de pouvoir faire un mini-DWH ou pré-DWH sur l'ODS, pour pouvoir consulter les données en cours. Mais si c'est "pratique" ce n'est pas "prudent" car ces données sont justement susceptibles de bouger.

Ensuite parce que le terme "queries" désigne pour moi des requêtes de mise à jour, de suppression ou d'insertion. Alors que dans le DWH les seules requêtes seront des requêtes de sélection (sauf quand on bascule les données de l'ODS dans le DWH).

Par contre je suis d'accord avec ça :

Unlike a data warehouse, which contains static data, the contents of the ODS are updated through the course of business operations.

Et c'est ça qui est important : les données ne doivent PLUS changer une fois dans le DWH. Ce sont des données consolidées et figées. Dans l'ODS par contre on peut leur appliquer des modifications à la pelle jusqu'à obtenir le bloc de donnée qu'on souhaite, bloc qu'on basculera dans le DWH.

Les tables de l'ODS PEUVENT être effacées après utilisation. Tout dépend si on souhaite garder un historique. Par exemple pour des opérations de delta il peut être intéressant de conserver les données de la veille.

L'intégration du delta quotidient dans le DWH dépend des besoins. Si il existe un besoin de reporting quotidien, alors il faudra faire en sorte que ce soit possible soit en organisant un reporting dans l'ODS ou dans un pré-DWH, soit en basculant les données quotidiennement dans le DWH.

Tout dépendra des besoins et des contraintes. Je te donne un exemple vécu :
- des données quotidiennes sont récupérées dans l'ODS.
- on ne les bascule dans le DWH qu'en fin de mois, donc il faut attendre la fin du mois pour pouvoir requêter sur les données en cours.

Un besoin de reporting hebdomadaire et semi-hebdomadaire apparaît. On change donc le système :
- les données quotidiennes sont récupérées dans l'ODS.
- on les bascule quotidiennement dans le DWH.

Jusque là tout va bien. Mais un nouveau besoin apparaît. Des données supplémentaires sont disponibles en différé (2 à 3 jours plus tard) et il faudrait les utiliser pour rajouter une information dans les données du DWH. On change donc le système :
- les données quotidiennes sont récupérées dans l'ODS.
- on les bascule quotidiennement dans le DWH.
- les données différées sont récupérées quotidiennement dans l'ODS.
- on met à jour les données du DWH grâce aux données différées.

Et LA il y a un problème tu vois. Je vais modifier le contenu du DWH, on le considérant comme un ODS, or ce n'est PAS un ODS. Et là on a un problème de principe. Et je te garanti que je le sent bien tous les jours.

La solution ? Considérer que les données qui doivent encore être mises à jour ne sont PAS des données figées et donc créer un ODS2 qui contient ces données et ne les passera dans le DWH qu'APRES la modification par les données différées. Mais ça oblige à un gros refactoring alors pour l'instant on laisse comme c'est.

[sg-40]

Merci pour ce complément d'informations.

Je pense connaitre la réponse mais j'ai des tables de la base de donnée de production qui ne doivent subir aucuns traitement (ou au pire un filtrage simple des données) avant que les enregistrements ne soient enregistrés dans les tables de dimension dans le DW. Dois je passer par l'ODS ?


Sinon je me demandais comment cela se passait, plus précisément, au niveau de l'intégration du delta quotidien. Comment cela se passe t'il pour ne prendre en compte que les nouvelles données ? Cela doit etre géré par l'ETL mais comment (sorte de pointeur sur une table ? )

[nuke_y]

Alors si c'est un copie simple des données de prod dans le DWH on PEUT se passer d'un ODS. Si tu es sûr qu'il n'y a pas de traitement à faire ET que les données que tu extraits ne vont pas évoluer alors pas besoin.

Si les données de prod sont susceptibles d'évoluer alors tu risques un jour de te retrouver avec des différence entre la production et le DWH. Et on te demandera d'expliquer pourquoi. Dans ce cas mieux vaut un ODS, qui te permettra d'être sûr que les informations que tu as copié à un instant t sont bien celles que tu as dans le DWH. Après si en prod ils s'amusent à modifier les données sans que te l'ai spécifié, ce n'est pas ton problème.

Le delta maintenant, gros morceau ça. Les techniques pour le delta sont nombreuses et je n'ai à mon grand regret qu'on connaissance échantillonesque du sujet.
Il existe plusieurs solution : je crois qu'à partir de la 9i Oracle offre des mécanismes qui permettent d'identifier les lignes qui ont changées depuis la dernières fois, je laisse ceux qui savent s'exprimer là dessus.
Les solutions que je connais :

1) Modifier la production pour qu'elle garde un listing des lignes nouvelles ou modifiées (si possible un flag 0 pour ancienne, 1 pour nouvelle et 2 pour ancienne mais modifiée). A tout moment tu peux venir chercher les lignes flaggées > 0 et faire ta sauce dans l'ODS puis flagger ces lignes en production à 0 et charger le DWH avec le contenu de l'ODS.
Cette solution t'oblige à modifier la production et donc à intégrer à ta production ton système d'extraction.

2) Utiliser les possibilités de la production : si tes données de production possèdent un champ qui indique la date de dernière modification, tu peux l'utiliser. A tout moment tu peux venir chercher les lignes dont la date de modification est > à la dernière date d'extraction, faire ta sauce dans l'ODS et charger le DWH avec le contenu de l'ODS.
Cette solution t'oblige à faire confiance à la production.

3) Extraire tout puis faire le delta : si le volume est faible tu peux extraire toutes tes données dans ton ODS et les comparer avec les données extraites de la dernière fois. En faisant une jointure entre les tables de l'ODSNEW et l'ODSOLD tu trouves les lignes différentes que tu peux copier ou flagger comme nouvelles. Après fais ta sauce dans l'ODSCURRENT et tu finis par charger le DWH.

4) Extraire une partie puis faire le delta : si le volume est trop important tu peux extraire seulement une partie des données dans ton ODS et les comparer avec les données extraites de la dernière fois. En menant une analyse tu peux par exemple constater qu'au dela d'une semaine les données ne bougent plus et que donc il suffit de récupérer une semaine à chaque fois pour faire le delta. En faisant une jointure entre les tables de l'ODSNEW et l'ODSOLD tu trouves les lignes différentes que tu peux copier ou flagger comme nouvelles. Après fais ta sauce dans l'ODSCURRENT et tu finis par charger le DWH.

5) Garder des informations dans l'ODS. Si les données ne peuvent pas bouger mais seulement apparaître et disparaître tu peux appliquer la technique 3 seulement sur les clés. Tu fais un delta sur les clés et ensuite tu récupères les données qu'il te manque.

6) Utiliser les possibilités de l'ETL. Beaucoup d'ETL vont utiliser une de ces techniques, mais il y en a sûrement d'autres que je ne connais.

Et toujours, voir d'abord si une fontionnalité d'Oracle ne répond pas à ton besoin.

[Melvine]

DSA:data staging area;
c'est un espace dans lequel on travail les données avant de les integré dans le DWH;mais j'ai l 'impression que c'est comme l'ODS;

le delta ?qu'est ce que c'est ?

[nuke_y]

Oui je dirais que c'est plus ou moins la même chose.

Disons que ODS veut dire Operationnal Data Storage et désigne en fait les données copiées brute depuis leurs sources, sources qui sont souvent des systèmes OPERATIONNELS. D'où le Operationnal. Après ces données sont transformées avant d'être basculées dans le DWH. Donc on peut dire :
Système opérationnel (Logiciel de compta, de paye, etc.)
| copie brute
\/
ODS (sur le serveur de BDD)
| transformation 1
\/
DSA 1
| transformation 2
\/
DSA 2
| transformation ...
\/
...
| transformation n
\/
DSA n
| bascule des données finales
\/
DWH


Une alimentation par Delta c'est une alimentation qui permet de ne modifier que ce qui a changé (le delta) entre la dernière fois et le traitement en cours. Ca permet de ne pas avoir à tout effacer/recréer.

[abdelelomari]

Oui je dirais que c'est plus ou moins la même chose.

Disons que ODS veut dire Operationnal Data Storage et désigne en fait les données copiées brute depuis leurs sources, sources qui sont souvent des systèmes OPERATIONNELS. D'où le Operationnal. Après ces données sont transformées avant d'être basculées dans le DWH. Donc on peut dire :
Système opérationnel (Logiciel de compta, de paye, etc.)
| copie brute
\/
ODS (sur le serveur de BDD)
| transformation 1
\/
DSA 1
| transformation 2
\/
DSA 2
| transformation ...
\/
...
| transformation n
\/
DSA n
| bascule des données finales
\/
DWH


Une alimentation par Delta c'est une alimentation qui permet de ne modifier que ce qui a changé (le delta) entre la dernière fois et le traitement en cours. Ca permet de ne pas avoir à tout effacer/recréer.

I'ODS est une source de confusion et la réponse dépend à qui tu poses la question.

Théoriquement l'ODS est ce qui suit :
" Un environnement qui sert à la prise de décisions tactiques, qui contient des données détaillées, extraites en presque temps-réels des systèmes opérationnels pour répondre à des besoins de reporting immédiat et qui peut être mis à jour par les utilisateurs".

Il est souvent mis en place pour répondre à au moins un des besoins suivants :
- Intégrer les données provenant de plusieurs sources. Normalement ce genre d'intégration devrait être réalisé dans les systèmes sources, mais parceque cela peut couter chèr ( temps, dispo et rentabilité) on mets en place un ODS.
- Fournir les données pour prendre des décisions tactiques (reporting)
- Permettre de consolider les mises à jour communes aux systèmes sources.

Un ODS peut servir de "staging area" pour alimenter un DW, cependant cela ne doit pas être sa raison d'être.
pour une architecture qui met en évidence les différentes composantes veuillez se référer au lien suivant :
http://www.systemeetl.com/architectures_dw_suite_2.htm


Le tableau suivant présente (en anglais) les différences entre OLTP/ODS/DW/DM



Mon Opinion :
La fréquence d'alimentation d'un DW est devenue de plus en plus sérée, Il existe donc des systèmes ou l'on alimente l'entrepôt de données chaque nuit, Il devient donc difficile de convaincre les décideurs de la necessité d'un ODS et surtout que cela coute cher en général.
N'oublions pas non plus que les fournisseurs des suites ETL intègrent de plus en plus des fonctionnalités Real-time ETL à leur solutions. Un DW d'ici peu de temps ( si ce n'est déjà le cas avec le CDC) pourrait être alimenté en temps réel ce qui fait, à mon avis, tomber la necessité de mettre en place un ODS

Abdel
www.systemeetl.com

[aeled]

Je "déterre" un topic très interessant ma foi.

Et c'est ça qui est important : les données ne doivent PLUS changer une fois dans le DWH. Ce sont des données consolidées et figées. Dans l'ODS par contre on peut leur appliquer des modifications à la pelle jusqu'à obtenir le bloc de donnée qu'on souhaite, bloc qu'on basculera dans le DWH.

Un petit cas d'étude :

* remontée de données journalières dans un ODS.
* traitements jusqu'à obtenir les données souhaitées
* bascule des données consolidées pour la journée dans le DWH

Tout va bien dans le meilleur des mondes.

Mais arrivé en début de mois m, on souhaite consolider les données du mois m-1 à partir des données consolidées (donc dans le DWH) de l'ensemble des jours du mois m-1. Ma question : où faire ce traitement ? Rebasculer dans l'ODS les données pour tous les jours de m-1, traiter puis rebasculer les données traitées dans le DWH ? Envisagable ?

Merci aux gens qui ont eu ce genre de problématique à mettre en place d'éclairer ma lanterne

David