Discussion :

[bassoum]

salut, je ne comprend pas qu'est ce qui permet de faire l'historisation en Datawarehouse,
Càd l'outil qui permet de changer l'état à chaque fois, en gardant la trace ou l'historique de l'état précédant.
merci d'avance

[nuke_y]

Bonjour.

Il y a rarement un outil spécifique pour faire ça (enfin je n'en connais pas mais il doit bien en exister un quelquepart). Chacun fait comme il veut et a ses propres techniques. Je prépare un document à ce sujet mais pour te donner des pistes :
- un trigger sur une table T à historiser, à chaque modification, une nouvelle ligne est ajoutée dans une table T_HIST qui est une copie de la table T avec un champ date_modification en plus
- de manière régulière on sauvegarde tout le contenu de la table T dans une table T_HIST qui est une copie de la table T avec un champ date_sauvegarde en plus
- de manière régulière on sauvegarde tout ce qui a changé entre T et T_HIST dans la table T_HIST qui est une copie de la table T avec un champ date_sauvegarde en plus

Voila 3 techniques, avec leurs avantages et leurs inconvénients. Il en existe d'autres.

[Benoit_Durand]

Tu ne serais pas en train d'évoquer les dimensions changeantes (SCD) ?

Par ex comment historiser les adresses d'un client ou l'évolution d'un produit.

Si oui tu peux faire une recherche rapide sur SCD Slowly Changing Dimensions.

Sinon l'outil le plus classique pour alimenter un entrepôt et permettant de gérer l'historisation est un ETL (Extract Transform & Load)

Si avec Nuke nous sommes à coté de la plaque, tu peux préciser ta requête ^^.

Cordialement,

[Aitone]

Je pense que la question relève bien de l'historisation des données afin de ne pas avoir la table principale trop "lourde".
L'exemple le plus fréquent est pour les commandes de ventes... On historise les données dans une autre table afin de garder propre et "peu encombrée" la table des commandes. On garde toutefois une trace de l'ensemble des commandes qui ont été passées. On peut également supprimer quelques infos qui deviennent obsolète...

[ygrim]

Je pense que BASSOUM parle effectivement des changements dans les dimensions (Slow Changing Dimensions). J'ai écris quelque chose à ce sujet : http://grim.developpez.com/articles/...ing-dimension/
La gestion du changement dans les entrepots relève plus de la technique de conception plutot que d'outils spécialisés. Bien que la plupart des environnement de développement décisionnels proposent des assistants pour gérer le changement (composants d'ETL).
Quand à l'historisation selon Adrien, il faut faire très attention, car la valeur ajoutée d'un entrepôt réside justement dans le fait d'avoir TOUTES les données de l'entreprise. Je parlerais plus de partitionnement pour séparer les données "moins utilisée" des données "actives"

[Benoit_Durand]

hehe

Bassoum !!! Qui est le plus proche de la réponse attendu ?

ygrim, je suis persuadé qu'on va gagner

[Jester]

L'utilisation des BigTable de google permet d'avoir du versionning directement dans la BD. Puis ça tiens bien la charge, ils ont 700To de données.

Allez je parie que je suis le plus loin de la réponse voulue.

[Aitone]

Quand à l'historisation selon Adrien, il faut faire très attention, car la valeur ajoutée d'un entrepôt réside justement dans le fait d'avoir TOUTES les données de l'entreprise. Je parlerais plus de partitionnement pour séparer les données "moins utilisée" des données "actives"

Pour reprendre mon exemple de commandes de vente. Ton client passe sa commande et toi tu vas la traiter. Une fois qu'elle est soldée (facturée, livrée, réglée et tout ce que vous voulez), tu auras encore besoin de certaines informations de ces commandes mais pas toutes. Afin d'obtenir les normes qualités ISO etc. il faut pouvoir garder une tracabilité et je voyais plus l'historisation comme un archivage des données.

[ygrim]

L'utilisation des BigTable de google permet d'avoir du versionning directement dans la BD. Puis ça tiens bien la charge, ils ont 700To de données.

Allez je parie que je suis le plus loin de la réponse voulue.

Non t'es toujours dans le sujet
Mais les Big Tables est vraiment un phénomène à suivre, les application au BI sont plus qu'évidents et c'est carrément révolutionnaire en terme de montée en charge et capacité de stockage. Merci d'avoir introduit ce concept

[nuke_y]

J'adore quand on arrive à faire une page de suppositions pour essayer de répondre à une question imprécise

[Aitone]

J'adore quand on arrive à faire une page de suppositions pour essayer de répondre à une question imprécise

[ygrim]

N'empeches.... on ne sait toujours toujours pas qui suppose juste....

[yphilogene]

Dans un data warehouse, il est parfois demandé:

1 - d'historiser les faits

Historiser les faits est assez simple. Par exemple, si on souhaite faire une photo des chiffres tous les x jours, on peut gérer une colonne de date supplémentaire correspondant à la date de la photo. Ainsi, les tables de faits sont constitués de plusieurs couches, une par date de photographie.

A l'utilisation, pour la construction des rapports, c'est facile; on choisit la photo qu'on souhaite interroger au préalable avant d'élaborer le reste. Certaines rapports peuvent vouloir tracer l'historique d'un indicateur, ce qui nécessitera l'intérrogation de la donnée dans plusieurs couches.

Pour gérer les problèmes de volumétrie et de performance dans le data warehouse, c'est une autre paire de manches et l'avis d'un DBA est plus que souhaitable. En effet, faire une photo tous les x jours fait rapidement augmenter la taille des tables de faits. Une politique d'élimination des données obsolètes doit être appliquée.

2 - de tracer les changements de certains attributs des éléments dimensionnels

Connu sous le terme "Slowly Changing Dimension", l'historisation des changements (peu fréquent) de certains attributs des éléments dimensionnels peut s'avérer être une vraie prise de tête.

Dans la littérature, on trouve des définitions pour le SCD1, SCD2 et SCD3. La plupart des attributs sont du type SCD1, c'est à dire que tout changement sur ces attributs écrasent les anciennes valeurs. C'est donc le SCD2 et SCD3 qui permet de faire de l'historisation des dimensions.

Pour les attributs du type SCD2, il s'agit de créer un nouvel élément dimensionnel à chaque changement de valeurs de l'attribut tracé, en créant une nouvelle clé pour ce nouvel élément. C'est une historisation en ligne.

Pour les attributs du type SCD3, il s'agit de gérer au moins 2 colonnes pour un même attribut. Par exemple, valeur précédente, valeur actuelle. C'est une historisation en colonne.



Dans la pratique, je n'ai jamais eu l'occasion d'implémenter le SCD2 et quand j'y réfléchis, j'ai un mal de crâne à chaque fois.

[bassoum]

hehe

Bassoum !!! Qui est le plus proche de la réponse attendu ?

ygrim, je suis persuadé qu'on va gagner

non il na pas gagné je parle bien de ce que Mister Adrien a dit.
Merci pour tout

[Aitone]

non il na pas gagné je parle bien de ce que Mister Adrien a dit.
Merci pour tout

Et nos réponses t'ont-elles satisfaites au moins ?

[estemcasa]

bonjour nuke__y
le probleme cé ke l'enregistrement q'on va changer,peut etre elle est changeable n fois,c-a-d il y aura un redondance de données dans la table historique,ce qui donne un probleme de performance,si vous avez une autre idée pour gérer ce probleme.
merci d'avance