Certains parlent d’ODS (Operating Data Store ou magasin de données opérationnelles) d’autres de Staging Area. Mais quelles en sont les points communs et les différences?
l’ODS et le Staging Area ont deux points communs :
- ils permettent de stocker les données extraites des SI sources
- de faire des opérations sur ces données
Leurs différences :
Dans le cas du staging Area, les données sont détruites directement après avoir été chargées dans le Datawarehouse mais pas pour l’ODS où les données auront quand même une durée de vie plus longue.
Finalement l’ODS répond plus à une problématique de reporting immédiat dans le sens où l’ODS sera mis à jour plus souvent que le datawarehouse : on pourrait dire que l’ODS pourrait être alimenté toutes les semaines et le Datawarehouse une fois par mois.
l’ODS n’est donc pas forcement indispensable si l’entreprise peut recharger son Datawarehouse toutes les semaines : Il sera plus utilisé dans ce cas un Staging Area. C’est une question de politique, de stratégie.
Et vous, dans quel cas êtes-vous?
29 avril 2009 à 9 h 21 min
Après une première lecture, je n’étais pas d’accord avec ce qui est écrit dans cet article.
Après réflexion, il me semble néanmoins qu’il y a une erreur de « traduction » des termes utilisés et donc de la description des éléments. ODS (Operating Data Store) ne désigne (communément) pas l’endroit où l’on va stocker et analyser des données opérationnelles mais l’endroit où l’on va les traiter en vue d’une intégration dans un datawarehouse.
Staging Area et ODS n’ont qu’un rôle de « passage », de « transformation » dans une architecture décisionnelle.
En aucun cas ils ne doivent servir de source(s) pour du reporting par exemple ! Ce ne sont pas dans ces endroits que se trouvent les données consolidées et historisées !
A mon sens, on a :
- Le SA (Stage Area) qui est un ensemble de base de données permettant de stocker les différentes sources, commencer à les homogénéiser et en vérifier la qualité. C’est un lieu où, par exemple, on va pouvoir stocker des données qui arrivent à des moments différents. C’est une zone d’attente, une « salle d’embarquement ».
En aucun cas on ne croisera les sources dans cet élément.
C’est à partir du SA que l’on pourra être « full database » et ne plus avoir de sources externes dans des formats bizarres. Bien évidemment, le SA est purgé à chaque exécution de l’ETL !
- L’ODS (Operating Data Store), qui est le lieu où vont être effectuées les transformations, les croisements, etc. C’est l’étape juste avant l’alimentation du datawarehouse et il utilise, comme source … le SA !
L’ODS devrait théoriquement être vidé à chaque lancement de l’ETL, on pourra admettre qu’on ne vide que les tables qui voient leurs données modifiées depuis la dernière exécution.
Sur le point « on met à jour certaines bases à la semaine, d’autres au mois ». Si on a les sources à la semaine, alors on traite également le datawarehouse à la semaine. C’est ensuite lors du reporting que l’on filtrera la période de temps à considérer.
De plus, pourquoi faire du reporting sur deux éléments différents (ODS et DW) alors que le but même du décisionnel est de centraliser/historiser/consolider puis, ensuite, d’agréger et de filtrer avant de creuser ?
Si c’est pour répondre à des problématiques opérationnelles, alors il faut envisager la construction d’un système adaptée (autre outil, puissance des serveurs, délais de traitements, …) mais utiliser l’ODS comme une source de reporting me parait très dangereux !
On pourrait éventuellement imaginer un second datawarehouse, moins fourni en données historisées et donc plus rapide à traiter et répondant ainsi à des problématiques opérationnelles.
Enfin, à la remarque « l’ODS n’est donc pas forcement indispensable », je dirais que c’est plutôt le SA !
L’ODS est primordial (tous les schémas théoriques considèrent cet élément, c’est la clé et la raison même de l’ETL !) alors que le SA peut éventuellement être supprimé, dans ce cas on insère directement les sources dans l’ODS.
Qu’entendiez vous exactement par ODS dans cet article ?
Thomas Malbaux
Cogoobi
29 avril 2009 à 18 h 11 min
Bonjour,
tout d’abord merci pour ce commentaire dont je n’ai eu le mail de modération que ce matin…Et merci de débattre de termes qui ne sont pas forcement compris de tout le monde, j’en suis la preuve.
D’après votre explication je comprends que :
l’ODS est un lieu ou des transformations sont effectués. avant d’être mis dans le DW
le SA est un infocentre (données des différentes sources copiées en attente d’un traitement)
le datawarehouse n’est que la source des rapports…
Donc si je récapitule avec un petit schéma :
SA —–>ODS——>DW
Dans mon article effectivement je fais ressortir le contraire :
ODS : correspond à l’infocentre ou l’on peut directement créer des rapports pour des demandes urgentes sans modélisation multidimensionnelle
SA : correspond à une zone de traitement ou l’on aurait nos tables de travail, tables de rejets…
Je pense que j’ai finalement inversée les 2 notions.
J’espère avoir bien compris avec ce petit récap…
Qu’en pensez vous Thomas?
30 avril 2009 à 10 h 08 min
Merci de votre réponse.
Effectivement, cela est plus juste. Attention néanmoins au terme « infocentre » qui reste ambigu (du fait de son histoire).
Le schéma est correcte : c’est le sens de travail d’un processus décisionnel.
Enfin, le datawarehouse n’est quand même « pas que » pour les rapports
! Entre les dashboards, l’historisation, les rapports, le datamining, … il y a quand même un bon paquet d’applications à en tirer.
Mais c’est l’idée générale : on ne travaillera que sur le DW (et ses éventuels datamarts), qui sont les seules bases consolidées et « sûres ».
Bonne continuation avec l’apprentissage de toutes ces notions !
Thomas Malbaux
Cogoobi
10 novembre 2010 à 14 h 41 min
Bonjour,
Suite à un besoin d’expliquer l’inulité l’ods sur un projet, je suis tombée sur votre article.
Je ne veux dire qu’une chose Bravo Thomas.
Nawel
10 novembre 2010 à 15 h 02 min
Merci à vous d’utiliser ce blog!
10 décembre 2010 à 9 h 45 min
Juste un petit merci pour cet article super intéressant et très utile
5 janvier 2011 à 16 h 29 min
Bonjour,
Ce petit poste en passant, de mon expérience de DBA Décisionnel :
L’opérating Data Store comme son nom l’indique, contient des données opérationnelles, c’est à dire brutes. C’est donc la première étape en entrant dans un Data Warehouse, on y stocke les enregistrements de production lié à l’activité de l’entreprise utile au pilotage stratégique. LEs données opérationnelles ou brutes, une fois entrées, ne sont plus des données utile aux opérationnels mais aux décideurs, et sont donc appelées données décisionnelles.
Après l’ODS vient le DSA, Data Staging Area où les données sont nettoyées, transformées et fusionnées pour établir une unité métier dans la multitude de fragments des bases de données opérationnelles captés par l’ODS. Ce qui donne la dernière étape le DWH ou Data Warehouse.
DBA Z.
5 janvier 2011 à 18 h 18 min
Merci à vous pour tous ces commentaires…
26 juillet 2011 à 10 h 00 min
Bonjour,
je partage la vision de « Dba Z » et non celle de Tomas.
Données Source –> ODS —> DSA –> DWH
16 janvier 2013 à 18 h 20 min
Merci pour cet article, très claire, très explicite !
11 septembre 2015 à 13 h 31 min
Bonjour,
Dans mes différentes expériences (8 ans en BI), j’ai rencontré différentes archi :
1er cas :
Source –> ODS –> STG –> DWH –> DMT
Avec l’ODS sur la même base de données que l appli source.
Dans ce cas, cela sert à ne pas pénaliser le systeme opérationnel. La table ODS est accédée plusieurs fois pour constituer les différents DWH du groupe (sous différents SGBD).
Le STG est sous la même base BDD que le DWH, les formatages, et filtres ont lieu. Ensuite la table STG sert à l alim du DWH.
Les tables ODS et STG sont vidées avant chaque rechargement (elles contiennent donc les données de la dernière journée).
le DWH est alimenté à partir d’une à plusieurs tables STG.
2eme cas :
Source –> STG –> ODS –> DWH –> DMT
Une colonne supplémentaire de date de la donnée est ajoutée dans chaque table (à tous les niveaux)
STG : le staging area contient les données de la source sans aucun formatage ni filtre (chargement de fichier plat). Le staging est la copie exacte de la donnée source.
mode d alim : truncate insert
l’ODS: les données sont formatées et rejetées si elles ne correspondent pas au format. L historique peut être conservé si les données sources sont nécessaires.
mode d alim : truncate insert ou delete insert si conservation d un historique
le DWH est alimenté à partir d’une à plusieurs tables d’ODS.
3eme cas :
Source –> STG –> DWH
Mode bcp plus allégé.
Les données des sources sont intégrées avec formatage dans le staging et sont rejetées si elles ne correspondent pas.
Dès que les données sont consommées par le DWH, les données sont vidées.
le DWH est alimenté à partir d’une à plusieurs tables STG.
On peut voir, qu’en fonction de l’architecte BI en place dans la société, les utilisations sont différentes pour l ODS et le Staging Area.
Pour avoir pratiqué ces différentes manières de les utilisées, je peux vous dire que la seconde est de loin la meilleure.
Le fait de ne pas vider les données après la consommation de celles ci permet de reprendre rapidement les traitements si un problème de qualité de données apparait. (Les problèmes rencontrés ne sont pas toujours un plantage simple…)
Le fait de ne formater que dans un second temps permet de voir s’il manque des données dès la source. Le STG qui est une copie exacte de la source est vraiment une source d information intéressante pour savoir où les données se perdent lors de l’intégration (non fournies par la source, rejetées lors du formatage de l’ODS, non intégrées dans le DWH à cause des règles de gestion…).
Qu’importe le nom que vous données à vos tables de pré-traitement, le but est vraiment qu’elles facilitent l’intégration et la traçabilité des données.
12 octobre 2016 à 11 h 21 min
Merci CelBA.
Très utile ton intervention…