Banques de données
Le logiciel lie les paramètres de transformation SQL et d'éditeur de table cible utilisés dans un flux de données aux configurations de banque de données. Il est également possible d'utiliser une interpolation de variable dans un texte SQL avec ces fonctions pour permettre à la transformation SQL de s'effectuer correctement sans tenir compte de la configuration utilisée par Job server lors de l'exécution du job.
Utilisez l'Administrateur pour sélectionner une configuration système ainsi que pour afficher la configuration de banque de données sous-jacente associée lorsque vous :
• Exécutez des jobs batch
• Planifiez des jobs batch
• Affichez l'historique d'un job batch
• Créez des services pour les jobs en temps réel
Pour utiliser plusieurs configurations correctement, concevez les jobs pour ne pas avoir à modifier les schémas, types de données, fonctions, variables, etc. lorsque vous passez d'une configuration de banque de données à une autre. Par exemple, si vous avez une banque de données avec une configuration pour des sources Oracle et des sources SQL, assurez-vous que les schémas de métadonnées de table correspondent exactement. Utilisez les mêmes noms de table, noms d'alias, numéros et ordre de colonnes, ainsi que les mêmes noms de colonne, types de données et types de contenu.
Rubriques associées
• Guide de référence : descriptions de fonctions intégrées
• Guide de référence : SQL
•
Astuces de portabilité des jobs
5.5.6 Solutions de portabilité
Définissez plusieurs configurations sources ou cibles pour une seule banque de données si vous souhaitez modifier rapidement les connexions à une base de données source ou cible différente. Le logiciel offre plusieurs solutions différentes pour les job de déplacement.
Rubriques associées
•
Développement multi-utilisateurs
•
Configuration d'environnement multi-utilisateurs
5.5.6.1 Migration entre environnements
116 2012-11-22
Banques de données
Lorsque vous devez déplacer les métadonnées du référentiel vers un autre environnement (par exemple du développement au test, ou du test à la production) qui utilise des bases de données sources et cibles différentes, le processus inclut généralement les caractéristiques suivantes :
• Les environnements utilisent le même type de base de données mais peuvent avoir des versions ou des paramètres régionaux de base de données uniques.
• Les objets de base de données (tables et fonctions) peuvent appartenir à des propriétaires différents.
• Chaque environnement a un nom de connexion à la base de données, un nom d'utilisateur, un mot de passe, d'autres propriétés de connexion et un mappage du propriétaire uniques.
• Vous utilisez une procédure de migration du référentiel typique. Soit vous exportez les jobs vers un fichier ATL puis importez le fichier ATL dans un autre référentiel, soit vous exportez directement les jobs d'un référentiel à un autre.
Puisque le logiciel remplace les configurations de banques de données lors de l'exportation, il est recommandé d'ajouter des configurations pour l'environnement cible (par exemple, ajouter des configurations pour l'environnement test lors de la migration du développement au test) au référentiel source (par exemple, ajouter au référentiel de développement avant la migration vers l'environnement test). L'utilitaire Exportation enregistre les configurations supplémentaires dans l'environnement cible, ce qui signifie que vous n'avez pas besoin de modifier les banques de données avant d'exécuter des jobs déplacés dans l'environnement cible.
Cette solution offre les avantages suivants :
• Temps d'arrêt de production minimal. Vous pouvez démarrer les jobs dès que vous les avez importés.
• Problèmes de sécurité minimaux. Les testeurs et les opérateurs en production n'ont pas besoin d'autorisation pour modifier les objets du référentiel.
Rubriques associées
• Guide d'administration : exportation/importation
117
5.5.6.2 Chargement de plusieurs instances
Si vous devez charger plusieurs instances d'une source de données dans un entrepôt de données cible, la tâche est la même que pour un scénario de migration, sauf que vous utilisez un seul référentiel.
5.5.6.2.1 Charger plusieurs instances d'une source de données dans un entrepôt de données cible
1.
Créez une banque de données qui se connecte à une instance particulière.
2.
Définissez la première configuration de banque de données. Cette configuration de banque de données contient toutes les propriétés configurables telles que le type de base de données, le nom de connexion à la base de données, le nom d'utilisateur, le mot de passe, la version de la base de données, et les informations des paramètres régionaux.
2012-11-22
Banques de données
Lorsque vous définissez une configuration d'une banque de données d'adaptateur, assurez-vous que le Job Server pertinent s'exécute afin que Designer puisse rechercher toutes les instances d'adaptateur disponibles pour la banque de données.
3.
Définissez un ensemble de mappage alias-au-propriétaire dans la configuration de banque de données. Lorsque vous utilisez un alias pour une configuration, le logiciel importe tous les objets à l'aide de l'alias de métadonnées plutôt qu'à l'aide des noms de propriétaire réels. Cela permet d'utiliser les objets de base de données pour les jobs qui sont transparents pour les autres instances de base de données.
4.
Utilisez l'outil de renommage du propriétaire de l'objet de la base de données pour renommer les propriétaires des objets de base de données existants.
5.
Importez les objets de la base de données et développez des jobs à l'aide de ces objets, puis exécutez les jobs.
6.
Pour prendre en charge les jobs qui exécutent sous différentes instances, ajoutez des configurations de banque de données pour chaque instance supplémentaire.
7.
Mappez les noms du propriétaire à partir des nouvelles configurations d'instance de base de données aux alias que vous avez définis dans une étape précédente.
8.
Exécutez les jobs dans toutes les instances de base de données.
Rubriques associées
•
Modification du nom du propriétaire de table et de fonction
118
5.5.6.3 Déploiement d'OEM
Si vous concevez des jobs pour un type de base de données et déployez ces jobs vers d'autres types de base de données comme partenaire OEM, le déploiement possède généralement les caractéristiques suivantes :
• L'instance nécessite plusieurs types et versions de base de données source.
• Puisqu'une banque de données peut seulement accéder à une instance à la fois, il est possible que vous deviez déclencher des fonctions lors de l'exécution pour correspondre aux différentes instances.
Si c'est le cas, le logiciel nécessite un texte SQL différent pour les fonctions (telles que lookup_ext et sql) et les transformations (telles que la transformation SQL). Le logiciel nécessite également des paramètres différents pour la table cible (configurables dans l'éditeur de table cible).
• Les instances peuvent utiliser des paramètres régionaux différents.
• Les tables de base de données dans différentes bases de données appartiennent à des propriétaires différents.
• Chaque instance a un nom de connexion à la base de données, un nom d'utilisateur, un mot de passe, d'autres propriétés de connexion et des mappages du propriétaire uniques.
• Vous exportez les jobs vers des fichiers ATL pour le déploiement.
2012-11-22
Banques de données
119
5.5.6.3.1 Déployer des jobs vers d'autres types de base de données comme des partenaires
OEM.
1.
Développez des jobs pour un type particulier de base de données en suivant les étapes décrites dans le scénario
Chargement de plusieurs instances
.
Pour prendre en charge une nouvelle instance sous un nouveau type de base de données, le logiciel copie les propriétés de base de données de la table cible et de la transformation SQL à partir de la configuration précédente vers chaque configuration supplémentaire lorsque vous l'enregistrez.
Si vous avez sélectionné une méthode de chargeur par lots pour une ou plusieurs table(s) cible dans les flux de données du job, et que de nouvelles configurations s'appliquent à des types de base de données différents, ouvrez les cibles et définissez manuellement l'option de chargeur par lots (si vous souhaitez toujours utiliser la méthode de chargeur par lots avec le nouveau type de base de données). Le logiciel ne copie pas les options de chargeur par lot pour les cibles d'un type de base de données à un autre.
Lorsque le logiciel enregistre une nouvelle configuration, il génère également un rapport qui fournit une liste des cibles automatiquement définies pour le chargement par lots. Faites référence à ce rapport pour apporter des modifications manuelles si besoin.
2.
Si le texte SQL dans une transformation SQL ne s'applique pas au nouveau type de base de données, modifiez le texte SQL pour le nouveau type de base de données.
Si le texte SQL contient des noms de propriétaire ou de base de données codés en dur, pensez à remplacer ces noms avec des variables pour fournir des noms de propriétaire et des noms de base de données pour plusieurs types de base de données. Ainsi, vous ne devez pas modifier le texte
SQL pour chaque environnement.
3.
Puisque le logiciel ne prend pas en charge un texte SQL unique pour chaque type ou version de base de données des fonctions sql(), lookup_ext(), et pushdown_sql(), utilisez la fonction db_type et les fonctions similaires pour obtenir le type et la version de base de données de la configuration de banque de données actuelle et fournir le texte SQL correct pour ce type et cette version de base de données à l'aide de la technique de substitution (interpolation) de variables.
Rubriques associées
• Guide de référence : SQL
5.5.6.4 Développement multi-utilisateurs
Si vous utilisez un système de gestion du référentiel central qui permet à plusieurs développeurs, chacun avec leur propre référentiel local, de recharger et d'extraire les jobs, l'environnement de développement possède généralement les caractéristiques suivantes :
• Il possède un référentiel central et un nombre de référentiels locaux.
2012-11-22
Banques de données
120
• Plusieurs environnements de développement sont parfois fusionnés (via des opérations de référentiel central telles que les rechargements et les extractions). Lorsque la fusion se produit, les noms de propriétaire réels (utilisés au départ pour l'importation d'objets) doivent être ensuite mappés à un ensemble d'alias partagés entre tous les utilisateurs.
• Le logiciel conserve l'historique des objets (versions et étiquettes).
• Les instances partagent le même type de base de données mais peuvent avoir des versions ou des paramètres régionaux de base de données différents.
• Les objets de base de données peuvent appartenir à des propriétaires différents.
• Chaque instance a un nom de connexion à la base de données, un nom d'utilisateur, un mot de passe, d'autres propriétés de connexion et un mappage du propriétaire uniques.
Dans le scénario de développement multi-utilisateurs, vous devez définir des alias pour que le logiciel puisse conserver correctement l'historique pour tous les objets dans l'environnement partagé.
5.5.6.4.1 Déplacement de jobs dans un environnement multi-utilisateurs
Lors du déplacement de jobs dans un environnement multi-utilisateurs, prenez en compte ces points :
• Renommez les propriétaires de table et les propriétaires de fonction pour consolider les noms de propriétaire des objets de base de données d'objets dans des alias
• La modification du nom se produit dans les référentiels locaux. Pour renommer les objets de base de données stockés dans le référentiel central, extrayez la banque de données vers un référentiel local et appliquez l'outil de renommage dans le référentiel local.
• Si les objets à renommer ont des objets dépendants, le logiciel vous demande d'extraire les objets dépendants.
• Si tous les objets dépendants peuvent être extraits, le renommage crée un nouvel objet qui possède l'alias et supprime l'objet d'origine qui possède le nom du propriétaire d'origine.
• Si tous les objets dépendants ne peuvent pas être extraits (les flux de données sont extraits par un autre utilisateur), le logiciel affiche un message qui vous laisse l'option de continuer ou d'annuler l'opération. Si vous ne pouvez pas extraire certains objets dépendants, l'outil de renommage affecte uniquement les flux que vous pouvez extraire. Après le renommage, l'objet d'origine coexiste avec le nouvel objet. Le nombre de flux touchés par le processus de renommage affecte les informations sur l'utilisation et les cas d'emploi dans Designer pour l'objet d'origine et le nouvel objet.
• Vous êtes responsable du rechargement de tous les objets dépendants qui ont été extraits durant le processus de renommage du propriétaire. Le rechargement de nouveaux objets n'entraine pas automatiquement le rechargement des objets dépendants qui ont été extraits.
• Le logiciel ne supprime pas les objets d'origine du référentiel central lorsque vous rechargez les nouveaux objets.
• Soyez prudents car le fait de recharger dans les banques de données et de les extraire comme des opérations multi-utilisateur peut remplacer les configurations de banque de données.
• Conservez les configurations de banque de données de tous les utilisateurs en ne remplaçant pas les configurations qu'ils ont créées. Ajoutez plutôt une configuration et définissez-la comme configuration par défaut lorsque vous travaillez dans votre propre environnement.
• Lorsque votre groupe termine la phase de développement, il est recommandé que le dernier développeur supprime les configurations qui s'appliquent aux environnements de
2012-11-22
