Capture de données modifiées
• Recherche de lignes mises à jour :
SELECT * FROM source_table
WHERE Create_Timestamp <= $Last_Timestamp AND
Update_Timestamp > $Last_Timestamp)
De là, les nouvelles lignes sont soumises au processus de génération de clés et sont insérées dans la cible. Les lignes mises à jour passent par le processus de recherche de clé et sont mises à jour dans la cible.
Pour des raisons de performances, vous pouvez éventuellement isoler l'extraction des nouvelles lignes dans un flux de données distinct pour tirer parti du chargement par lots dans la cible. Les lignes mises
à jour ne peuvent pas être chargées par lots dans la même cible au même moment.
20.5.4 Exemples de CDM basée sur l'horodatage
20.5.4.1 Conservation des clés générées
Pour des raisons de performances, la plupart des tables de dimension des entrepôts de données utilisent des clés générées pour effectuer la jointure avec la table des faits. Par exemple, le client ABC a la clé générée 123 dans la table de la dimension Client. Tous les faits du client ABC ont 123 comme clé client. Même si la dimension Client est de petite taille, vous ne pouvez pas simplement la recharger chaque fois qu'un enregistrement est modifié : à moins d'affecter la clé générée 123 au client ABC, la table de la dimension Client et la table des faits ne sont pas en corrélation.
Vous pouvez conserver les clés générées en utilisant la fonction de recherche ou en comparant les tables.
Rubriques associées
•
Utilisation de la fonction lookup
•
Comparaison de tables
20.5.4.1.1 Utilisation de la fonction lookup
Si la conservation de l'historique ne présente pas de problème et que le seul objectif est de générer les bonnes clés pour les lignes existantes, la technique la plus simple consiste à rechercher la clé de toutes les lignes à l'aide de la fonction lookup dans une requête. Si vous ne recherchez pas la clé, générez-en une nouvelle.
759 2012-11-22
Capture de données modifiées
Dans l'exemple suivant, la table de la dimension Client contient des clés générées. Lorsque vous exécutez un job pour mettre à jour cette table, les lignes source des clients doivent correspondre aux clés existantes.
Table source des clients
Nom de société ID client
ABC 001
DEF
GHI
JKL
002
003
004
Table de dimension cible
Gen_Key
123
124
125
Nom de société
ABC
DEF
GHI
ID client
001
002
003
Cet exemple de flux de données effectue les actions suivantes :
1.
Il extrait les lignes source.
2.
Il récupère les clés existantes à l'aide d'une fonction lookup dans le mappage d'une nouvelle colonne dans une requête.
3.
Il charge le résultat dans un fichier (pour pouvoir tester cette phase du flux de données avant d'ajouter les étapes suivantes).
La fonction lookup compare les lignes source à la cible. Les arguments de la fonction sont les suivants :
760 2012-11-22
Capture de données modifiées
761
arguments de la fonction de recherche
target_ds.owner.customer
GKey
NULL
CACHE_DE_PRECHARGEMENT
Customer_ID
Customer_ID
Description
Nom qualifié complet de la table cible contenant les clés générées.
Nom de la colonne de la table cible contenant les clés générées.
Valeur NULL à insérer dans la colonne des clés si aucune clé existante n'est trouvée.
Option de mise en cache pour optimiser les performances de la recherche.
Colonne de la table cible contenant la valeur à utiliser pour faire correspondre les lignes.
Colonne de la table source contenant les valeurs
à utiliser pour faire correspondre les lignes.
Le jeu de données résultant contient toutes les lignes de la source comportant les clés générées si elles sont disponibles.
Jeu de données du résultat
Gen_Key Nom de société ID client
123
124
ABC
DEF
001
002
125
NULL
GHI
JKL
003
004
L'ajout d'une clé générée aux nouveaux enregistrements requiert le filtrage des nouvelles lignes à partir des lignes existantes et mises à jour. Dans le flux de données, les étapes suivantes sont nécessaires :
2012-11-22
Capture de données modifiées une requête pour sélectionner les lignes avec des clés générées de valeur NULL. Une transformation
Key_Generation pour déterminer la clé appropriée à ajouter. Un cible pour charger les nouvelles lignes dans la table de la dimension Client.
Ce flux de données gère les nouvelles lignes. Cependant, les lignes de la source dont les clés ont été trouvées dans la table cible peuvent contenir des données mises à jour. Comme cet exemple suppose que la conservation de l'historique n'est pas une exigence, le progiciel charge toues les lignes de la source dans la cible.
Gestion des lignes mises à jour dans le flux de données
Le flux de données requiert de nouvelles étapes pour gérer les lignes mises à jour, comme suit :
1.
Une nouvelle ligne quittant la requête qui a recherché les clés existantes.
2.
Une requête pour filtrer les lignes comportant des clés existantes des lignes sans clés.
3.
Un cible pour charger les lignes dans la table de la dimension Client.
20.5.4.1.2 Comparaison de tables
Inconvénient de la méthode des clés générées, même si la ligne n'a pas été modifiée, elle génère une opération UPDATE et elle est chargée dans la cible. Si le nombre de lignes est important, une transformation Table_Comparison présente une meilleure alternative en permettant au flux de données de charger uniquement les lignes modifiées.
La transformation Table_Comparison examine toutes les lignes sources et effectue les opérations suivantes :
• Elle génère une ligne INSERT pour toute nouvelle ligne absente de la table cible.
• Elle génère une ligne UPDATE pour toute ligne de la table cible ayant été modifiée.
• Elle ignore toute ligne de la table cible n'ayant pas été modifiée.
• Elle remplit les clés générées pour les lignes mises à jour.
Vous pouvez ensuite soumettre le résultat à une transformation Key Generation pour affecter une nouvelle clé à chaque ligne INSERT. C'est le jeu de données chargé dans la table cible par le progiciel.
Le flux de données qui applique cette transformation comprend les étapes suivantes :
1.
Une source pour extraire les lignes des tables source.
2.
Une requête pour mapper les colonnes de la source.
3.
Une transformation Table_Comparison pour générer les lignes INSERT et UPDATE et renseigner les clés existantes.
4.
Une transformation Key Generation pour générer les nouvelles clés.
5.
Un cible pour charger les lignes dans la table de la dimension Client.
762 2012-11-22
Capture de données modifiées
763
20.5.4.2 Conservation de l'historique
La transformation History Preserving permet à l'entrepôt de données ou au datamart de gérer l'historique des données pour pouvoir les analyser au fil du temps. Vous appliquerez probablement la conservation de l'historique aux tables de dimension.
Par exemple, si un client déménage d'une région de vente dans une autre, la simple mise à jour de la fiche client pour tenir compte de la nouvelle région donne des résultats trompeurs dans une analyse par région dans le temps, parce que les achats effectués par ce client avant son déménagement seront attribués de manière erronée à la nouvelle région.
SAP BusinessObjects Data Services fournit une transformation spéciale qui conserve l'historique des données pour éviter ce genre de situation. La transformation History_Preserving ignore tout, sauf les lignes marquées comme UPDATE. Pour ces lignes, elle compare les valeurs des colonnes indiquées et marque la ligne comme INSERT si les valeurs ont été modifiées. Cela génère une deuxième ligne dans la cible au lieu de remplacer la première ligne.
Pour développer la manière dont le progiciel gère l'exemple du client qui déménage d'une région à une autre :
• Si Régionest une colonne marquée pour la comparaison, la transformation History_Preserving génère une nouvelle ligne pour ce client.
• Une transformation History_Preserving attribue à la nouvelle ligne une clé générée et la charge dans la table de la dimension Client.
• La ligne d'origine qui décrit le client reste dans la table de la dimension Client avec une clé unique générée.
Dans l'exemple suivant, un client a déménagé de la région Est dans la région Ouest et le numéro de téléphone d'un autre client a changé.
Table Client source
Client
Café Chez Fred
Les beignets de Jane
Confiserie Sandy
Région
Est
Ouest
Centre
Téléphone
(212) 123-4567
(650) 222-1212
(115) 231-1233
Table Client cible
GKey
1
Client
Café Chez Fred
Région
Est
Téléphone
(212) 123-4567
2012-11-22
Capture de données modifiées
764
GKey
2
3
Client
Les beignets de Jane
Confiserie Sandy
Région
Est
Centre
Téléphone
(201) 777-1717
(115) 454-8000
Dans cet exemple, le flux de données conserve l'historique pour la colonne Région, mais pas pour la colonne Téléphone. Le flux de données comporte les étapes suivantes :
1.
Une source pour extraire les lignes des tables source.
2.
Une requête pour mapper les colonnes de la source.
3.
Une transformation Table_Comparison pour générer les lignes INSERT et UPDATE et renseigner les clés existantes.
4.
Une transformation History_Preserving pour convertir certaines lignes UPDATE en lignes INSERT.
5.
Une transformation Key Generation pour générer de nouvelles clés pour les lignes mises à jour, maintenant marquées comme INSERT.
6.
Un cible pour charger les lignes dans la table de la dimension Client.
Il y a maintenant deux lignes pour Les beignets de Jane, les corrélations entre la table de dimension et la tables des faits doivent utiliser la valeur de clé la plus élevée.
Notez que les mises à jour des colonnes sans conservation de l'historique mettent à jour toutes les versions de la ligne si la mise à jour est effectuée sur la clé naturelle (par exemple, Client), et actualisent uniquement la dernière version si la mise à jour porte sur la clé générée (par exemple,
GKey
). Vous pouvez contrôler la clé à utiliser pour la mise à jour en configurant correctement les options de chargement dans l'éditeur de la cible.
20.5.4.2.1 date de début_validité et date de fin_validité
Pour prendre en charge des requêtes temporelles telles que "Quelle était l'adresse de facturation du client au 24 mai 1998", SAP BusinessObjects Data Services prend en charge les colonnes de date de
Début de validité et de date de Fin de validité.
Dans les techniques de conservation de l'historique, plusieurs enregistrements sont définis dans la table cible avec les mêmes valeurs clés primaires source. Un enregistrement de la table source est considéré valide dans la table de dimensions pour toutes les valeurs de date t, de sorte que la date de Début de validité soit antérieure ou identique à t, qui est antérieur à la date de Fin de validité.
(Valide dans ce sens signifie que la valeur clé d'enregistrement générée est utilisée pour charger la table de faits au cours de cet intervalle de temps.)
Lorsque vous indiquez les entrées Début de validité et Fin de validité, la transformation History_Pre serving génère une mise à jour d'enregistrement et une instruction INSERT pour des raisons de conservation de l'historique (elle convertit une instruction UPDATE en une instruction INSERT). La mise à jour d'enregistrement activera la colonne de date Fin de validité pour l'enregistrement en cours
(l'une avec la même clé primaire comme instruction INSERT) sur la valeur figurant dans la colonne de date Début de validité dans l'enregistrement INSERT.
2012-11-22
