Apporter des modifications à la table cible

Objective

After completing this lesson, you will be able to mettre à jour les données qui évoluent lentement au fil du temps

Capture des données modifiées (CDM)

Lorsque vous avez une grande quantité de données à mettre à jour régulièrement et une petite quantité de temps d'arrêt du système pour la maintenance planifiée, vous devez choisir la meilleure méthode pour un chargement delta ou pour mettre à jour vos données au fil du temps.

Actualisation complète et capture des données modifiées

Vous pouvez choisir d'effectuer une actualisation complète de vos données ou vous pouvez extraire uniquement des données nouvelles ou modifiées pour mettre à jour le système cible :

Actualisation complète :
La mise à jour complète est facile à implémenter et à gérer. Cette méthode garantit qu'aucune donnée n'est ignorée ou ignorée en raison d'erreurs techniques ou de programmation. Utilisez l'actualisation complète pour effectuer un chargement delta vers un système cible dans un environnement avec une quantité gérable de données source.
Capture des données modifiées :
Lorsqu'une reprise des données initiale est terminée, vous pouvez extraire uniquement les données nouvelles ou modifiées et mettre à jour le système cible. L'identification et le chargement des données modifiées uniquement sont appelés capture des données modifiées (CDM). La CDM est recommandée pour les tables volumineuses.

Avantages de capture de données modifiés

Améliore les performances car le job prend moins de temps à traiter avec moins de données à extraire, transformer et charger.
Le système cible est en mesure de suivre l'historique des modifications afin que les données puissent être analysées correctement au fil du temps.

La configuration d'une solution CDM complète dans Data Services peut ne pas être requise. De nombreuses bases de données disposent désormais d'une prise en charge CDM intégrée, comme Oracle, SQL Server, DB2 et SAP Sybase. Reportez-vous au Guide de Designer pour en savoir plus : https://help.sap.com/docs/SAP_DATA_SERVICES/ec06fadc50b64b6184f835e4f0e1f52f/572111656d6d1014b3fc9283b0e91070.html?locale=en-US&q=preload%20sql

Si vous voulez configurer une solution CDM complète, vous pouvez choisir une CDM basée sur la source et/ou la cible.

Solutions CDM

La CDM basée sur la source évalue les tables source pour déterminer ce qui a changé et extrait uniquement les lignes modifiées à charger dans les tables cible.
La CDM basée sur la source est préférable à la CDM basée sur la cible pour des raisons de performance.
Certains systèmes source ne fournissent pas suffisamment d'informations pour utiliser les techniques CDM basées sur la source.
La CDM basée sur la cible extrait toutes les données de la source, compare les lignes source et cible à l'aide d'une transformation Comparaison de tables, puis charge uniquement les lignes modifiées dans la cible.
Vous pouvez utiliser une combinaison de techniques basées sur la source et sur la cible.

Conservation de l'historique

Lors de la mise à jour des données, vous devez décider si vous voulez suivre ou non vos modifications.

Gestion des modifications de données

Il existe trois façons de gérer les modifications de données :

Aucune conservation de l'historique
Conservation limitée de l'historique
Préservation illimitée de l'historique

Aucune conservation de l’historique

Si la conservation de l'historique n'est pas nécessaire, vous pouvez simplement mettre à jour la ligne modifiée.

L'exemple suivant met à jour le nom d'un commercial, sans suivre les modifications.

Table cible avant modification des données

La table affiche les données avant la modification :

SALES_PERSON_ID	NOM	SALES_TEAM
000120	John B DOE	Nord-Ouest

Table cible après modification des données sans historique

La table affiche les données lorsque le nom du vendeur a été modifié :

SALES_PERSON_ID	NOM	SALES_TEAM
000120	John B, Dupont	Nord-Ouest

Conservation de l'historique limité

Si vous devez suivre les modifications, mais sans stocker toutes les valeurs historiques, vous devez ajouter deux zones supplémentaires par colonne pouvant être mise à jour, une pour enregistrer la nouvelle valeur et une pour enregistrer la date de la modification.

Vous ne pouvez conserver qu'une seule modification par attribut, comme l'ancien et le nouveau ou le premier et le dernier.
Chaque modification requiert au moins une zone supplémentaire par attribut et une autre zone supplémentaire si vous voulez enregistrer la date de la modification.
Bien que la structure de la table contienne toutes les données nécessaires, le code SQL requis pour extraire des informations spécifiques peut être complexe.

Limited History Preserving peut stocker un changement dans les données, mais ne peut pas tenir compte de plusieurs modifications ou répondre de manière adéquate au besoin de reporting sommaire.

L'exemple suivant illustre l'implémentation d'un historique limité préservant la valeur de l'équipe commerciale.

Table cible avant modification des données

La table affiche les données dans la table cible avant la modification :

SALES_PERSON_ID	NOM	SALES_TEAM	OLD_TEAM	EFF_TO_DATE
000120	John B. Smith	Nord-Ouest	NUL	NUL

Table cible après modification des données avec conservation de l'historique limitée

La table indique que l'équipe commerciale du vendeur a été modifiée :

SALES_PERSON_ID	NOM	SALES_TEAM	OLD_TEAM	EFF_TO_DATE
000120	John B. Smith	Sud-Est	Nord-Ouest	Oct_31_2004

Conservation d’historique illimitée

Unlimited History Preserving résout la plupart des problèmes liés à la gestion des modifications de données :

Génère de nouvelles lignes pour les modifications importantes.
Requiert l'utilisation d'une clé unique.
Le cas échéant, ajoute un champ Effective_Date ou deux champs Valid_From et Valid_To.
Le cas échéant, ajoute un champ Est actif.
Vous pouvez ensuite filtrer par Est actif = Y pour afficher les lignes actuelles par rapport aux lignes expirées.

Pour conserver l'historique, vous devez gérer les problèmes de contrainte dans vos tables cibles qui surviennent lorsque vous avez plusieurs enregistrements dans vos tables pour une seule entité, comme un client ou un employé.

Par exemple, avec vos enregistrements de vente, l' ID commercial est la clé primaire et est utilisé pour lier cet enregistrement à toutes les commandes client du commercial. Si vous tentez d'ajouter un nouvel enregistrement avec la même clé primaire, cela entraîne une exception. D'autre part, si vous affectez un nouvel ID commercial au nouvel enregistrement pour ce représentant, vous compromettez votre capacité à établir un rapport précis sur le chiffre d'affaires total du représentant.

Pour résoudre ce problème, créez une clé de substitution en tant que nouvelle colonne dans la table cible. La clé de substitution devient la nouvelle clé primaire pour les enregistrements. En même temps, vous modifiez les propriétés de l'ancienne clé primaire afin qu'il s'agisse simplement d'une colonne de données.

Lorsqu'un nouvel enregistrement est inséré pour le même représentant, une clé de substitution unique est affectée, ce qui vous permet de continuer à utiliser l' ID commercial pour gérer le lien vers les commandes du représentant.

Table cible avant modification des données

La table affiche les données avant la modification :

SALES_PERSON_KEY	SALES_PERSON_ID	NOM	SALES_TEAM
15	000120	John B DOE	Nord-Ouest

Table cible après modification des données

Lorsque vous implémentez la conservation d'historique illimité, deux enregistrements apparaissent comme indiqué dans cette table :

SALES_PERSON_KEY	SALES_PERSON_ID	NOM	SALES_TEAM
15	000120	John B DOE	Nord-Ouest
133	000120	John B DOE	Sud-Est

Mises à jour des tables cible

SAP Data Services marque chaque ligne en interne dans un jeu de données avec un code d'opération qui identifie le statut de la ligne.

Le tableau suivant décrit comment chaque code d'opération peut être obtenu et comment Data Services traite les lignes avec le code d'opération.

Description des codes d'opération

Les codes d'opération indiquent comment chaque ligne du jeu de données est appliquée à la table cible. Les codes d'opération sont les suivants :

Code d'opération	Contexte	Résultat
NORMAL	Ligne extraite d'une source.	Crée une ligne dans la cible.
INSÉRER	La ligne d'un jeu de données a été ajoutée par rapport à une image antérieure du même jeu de données.	Crée une ligne dans la cible.
MISE À JOUR	La ligne d'un jeu de données a été modifiée par rapport à une image antérieure du même jeu de données.	Écrase une ligne existante dans la cible.
SUPPRIMER	La ligne d'un jeu de données a été supprimée par rapport à une image antérieure du même jeu de données.	Supprime la ligne de la cible.

La plupart des transformations fonctionnent uniquement sur les lignes marquées d'un indicateur NORMAL. Ainsi, par exemple, une transformation Query éditera toujours les lignes avec le code d'opération NORMAL.

Remarque

Ce code d'opération génère une instruction insert dans la table cible. Mais si l'option de correction automatique du chargement est définie sur la cible, l'action réelle peut devenir une mise à jour.

La transformation Table_Comparison est utilisée pour comparer deux jeux de données et peut générer des codes d'opération INSERT, UPDATE ou DELETE.

La transformation History_Preserving peut ensuite être utilisée pour modifier les mises à jour dans les insertions et les suppressions dans les mises à jour, par exemple.

Une autre transformation peut être utilisée pour modifier les codes d'opération : la transformation Map_Operation.

Introduction à la transformation Map Operation

La transformation Map_Operation permet de modifier les codes d'opération sur les jeux de données pour produire la sortie souhaitée. Par exemple, si une ligne du jeu de données d'entrée a été mise à jour dans une opération précédente du flux de données, utilisez cette transformation pour mapper l'opération UPDATE à un INSERT. Le résultat peut être de convertir les lignes UPDATE en lignes INSERT pour conserver la ligne existante dans la cible.

Transformation Map Operation

Comme le montre la figure, la transformation Map Operation :

Substitue explicitement les codes d'opération
Peut rejeter des lignes avec des codes d'opération spécifiques
Est utilisé pour la compatibilité ultérieure de la transformation et pour contrôler l'écriture dans la cible.

L'entrée pour la transformation Map Operation est un jeu de données avec des lignes marquées d'un code d'opération.

La transformation Map Operation active la définition de l'option de type de ligne de sortie pour indiquer les nouvelles opérations souhaitées pour le jeu de données d'entrée. Sélectionnez l'un des codes d'opération suivants : INSERT, UPDATE, DELETE, NORMAL ou DISCARD.

Voici un exemple :

Le cas échéant, vous pouvez écrire des expressions de mappage pour chaque colonne, par type de ligne.

Expressions de mappage

Lorsque vous écrivez des expressions de mappage par colonne et par type de ligne (INSERT/UPDATE/DELETE), vous pouvez :

Modifiez la valeur des données d'une colonne.
Exécuter différentes expressions sur une colonne, en fonction de son type de ligne d'entrée.
Utilisez la fonction before _image pour accéder à la valeur pré-image d'une ligne UPDATE.

Vous pouvez, par exemple, charger des données à partir d'une source de livraison, modifier les insertions dans les mises à jour et modifier la valeur de la colonne STATUT des commandes clients en "LIVRÉ".

Next lesson