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.