Mapping SQL

La fonctionnalité de mapping SQL peut être utilisée pour les exigences de mapping complexes. Elle permet également de remplacer plusieurs règles de mapping * avec * à caractères génériques par un seul passage en revue de la base de données.

Dans cet exemple, le mapping prend approximativement 3 minutes. Avec une règle de mapping SQL unique, il ne prend normalement que 30 secondes environ. Il est possible de remplacer toutes les règles LIKE par une règle de mapping SQL unique, semblable à ce qui suit :

Image représentant la règle de mapping SQL unique.

Le code SQL réel généré et exécuté est le suivant :

Image représentant le code SQL réel.

Dans cet exemple, le mapping SQL a été défini pour la dimension ACCOUNT et les autres règles de mapping * avec * ont été supprimées. L'unique règle de mapping SQL a pris 29 secondes au total. Aucune autre règle de mapping n'est requise.

Les dimensions ACCOUNT et ENTITY peuvent être référencées par ces noms, mais les autres sont mappées avec des dimensions définies par l'utilisateur. Pour rechercher l'ensemble de dimensions dont vous avez besoin pour le mapping SQL, vous devez consulter la définition d'application ou le fichier journal afin de savoir quelles dimensions utiliser. Dans cet exemple, Product et Scenario sont mappés avec UD1 et UD3. Les membres de dimension source utilisent la colonne sans "X". Les valeurs mappées figurent dans la colonne avec "X" en tant que suffixe. Pour la dimension ACCOUNT, la valeur du fichier source se trouve dans la colonne nommée ACCOUNT et la valeur mappée est stockée dans la colonne ACCOUNTX. Le mapping SQL est utilisé pour définir la colonne "X" de chaque dimension.

Le même type de mapping peut être utilisé dans Account Reconciliation. Toutefois, la dimension Profil est classifiée en tant qu'ACCOUNT. Par conséquent, tout mapping SQL pour la dimension Profil doit être spécifié sur la dimension ACCOUNT. Les autres dimensions dans Account Reconciliation doivent être référencées en fonction du mapping indiqué dans la définition d'application.

Chaque type de mapping utilise les ressources différemment. Les performances varient, le mapping explicite étant le plus rapide et le mapping multidimensionnel le moins rapide :

  1. EXPLICIT
  2. IN
  3. BETWEEN et LIKE
  4. MULTI-DIM

Le mapping multidimensionnel est le plus lent. Dans la mesure du possible, ne faites appel aux règles multidimensionnelles que pour les cas d'emploi complexes où vous devez utiliser une combinaison de mappings EXPLICIT et LIKE. Par exemple, ENTITY = 100 AND ACCOUNT LIKE 4*.

Vous pouvez parfois combiner des dimensions source afin de remplacer des mappings multidimensionnels par des mappings explicites, ce qui constitue une stratégie d'ajustement supplémentaire. Par exemple, si ENTITY=100 AND ACCOUNT=4100, vous pouvez concaténer ENTITY et ACCOUNT en tant que source, et définir un mapping EXPLICIT pour 100-4000.

Note:

Bien que présentant un niveau de performances similaire en cas de volume de données très important (plus de 3 millions de lignes), les mappings SQL peuvent échouer en raison des limites du gestionnaire de bases de données. Les expressions d'import sont traitées lors de l'import des données. Elles n'impliquent pas d'opération SQL : l'import ne peut donc pas échouer. C'est pourquoi, pour les volumes de données très importants, il est recommandé d'utiliser des expressions d'import au lieu d'un mapping SQL.