Catégorie : Base de données

Joiner joint des attributs d'une base de données externes (la plupart des bases de données sont supportées) à une autre base spatiale (ou non spatiale).

Interroge une base de données externe pour retrouver les attributs associés à une entité.Un ou plusieurs attributs (clés étrangères) de l'entité sont joints à une ou plusieurs colonnes (clés primaires) d'une table de la base de données et les valeurs des enregistrements correspondants sont ajoutées aux attributs de l'entité.

Les bases de données disponibles sont : fichiers Access MDB, connexions ODBC, tables Oracle 7 and 8, dBase III, fichiers texte délimité (CSV), tables PostgreSQL/PostGIS, fichiers Microsoft Excel (XLS), et tables DB2.

C'est un Transformer particulièrement puissant avec des paramètres liés très performants.

La configuration de la jointure (type de connexion, source de données, paramètres de connexion, clés...) est réalisée par l'intermédiaire d'un assistant.

Note : Les informations affichées dans l'assistant dépendent de la connexion à la base de données. Selon les connexions, tous les onglets suivant n' apparaissent pas.

Spécifier la Base externe.

Sélectionnez la localisation de la base qui contient les valeurs que vous voulez ajouter à vos entités.

Notez que lorsque vous vous connectez à Microsoft SQL Server, une option est à cocher Utiliser l'authentification Windows qui permet l'authentification Windows pour la base de données. Si cette option est sélectionnée, le nom utilisateur et le mot de passe sont ignorés.

Sélectionner une table

L'assistant affiche une liste de tables. Sélectionnez la table qui contient les données à ajouter à vos entités.

Clés de la base de données

L'assistant affiche les colonnes de la table. Choisissez celles que vous voulez utiliser comme clé et déplacez les dans la liste des clés.

Correspondance des clés

Les clés de la table externe et les attributs de l'entité sont affichés dans deux listes. L'utilisateur doit apparier chaque clé avec l'attribut correspondant. Les valeurs de ces colonnes seront recherchées dans la base et ajoutées aux entités correspondantes.

Colonnes à ajouter

L'assistant affiche toutes les colonnes de la table stockées dans la base de données. Sélectionnez à partir de la liste, les attributs à ajouter aux entités. Les valeurs de ces colonnes seront recherchées dans la base et ajoutées aux entités correspondantes.

Sélectionner le Type de relation

Indique le type de relation entre les colonnes de la base de données et chaque entité. Le type de relation définit le nombre d'enregistrements de la base correspondant à chaque entité (cardinalité) ainsi que le comportement de Joiner si le nombre trouvé ne correspond pas à celui attendu. Si la cardinalité de la relation est de type 1 à n, un nom de liste doit être spécifié pour porter les attributs provenant de la base de données.Chaque enregistrement retourné est ajouté à la liste. L'exploitation de cette liste peut être faite ultérieurement par d'autres Transformers.

Les jointures de type 1:1 sont particulièrement strictes, dans le doute choisir 1:0..0+ ou 1:M

Spécifier les préfixes d'attribut

Pour éviter d'écraser la valeur d'attributs existant, vous pouvez spécifier un préfixe qui sera appliqué à chaque colonne de la base de données ajoutée à l'entité.

Optimiser Joiner

Précisez le nombre de lignes à mettre en cache localement si vous ne voulez pas accepter la valeur par défaut de 5000. Vous pouvez éventuellement spécifier une requête SQL pour précharger le cache.

Normalement le cache est rempli d'enregistrements appariés à la base de données. Toutefois le cache peut être pré chargé (par exemple, avec un jeu de données spécifiques avant que l'appariement ait lieu) en utilisant un requête prefetch. Cette requête prefetch peut sélectionner une table entière ou une partie de table d'avantage susceptible de correspondre aux attributs des entités.

Une requête prefetch, connue pour récupérer toutes les correspondances possibles est nommée une requête exhaustive.Quand une correspondance n'est pas trouvée dans les résultats du cache d'une requête exhaustive, il est alors supposé qu'ancune correspondance n'existe dans la base ; la base de données ne sera donc pas consultée.

La case à cocher Requête Exhaustive indique si une requête prefetch est exhaustive. Même si cette case n'est pas cochée, une requête prefetch est supposée être exhaustive si elle ne contient pas de clause WHERE, et prend la forme :

SELECT * from TableName

Note : Quand la case Requête Exhaustive est cochée, ou qu'il n'y a pas de clause WHERE, FME considère la requête comme exhaustive, et la limite de taille du cache est ignorée. Le cache doit contenir tous les résultats de la requête.

Par exemple, un certains nombre d'entités de type "routes" doivent être appariées à une base de données. La table de la base (myrecords) a un champ (record_type) avec différentes valeurs comme routes, autoroutes, avenues, rues... Pour apparier les entités FME avec les enregistrements où record_type=routes, le processus de jointure serait plus efficace avec la requête prefetch :

SELECT * from myrecords where record_type = 'routes'

Trim Key Fields (apparaît avec les champs)

Ceci réduit les performances et peut avoir lieu si les valeur de la colonne clé de la base de données sont connues. Il n'a aucun effet si une requête exhaustive prefetch est utilisée.

Spécifier le nom de la liste

Quand une entité est reliée à plusieurs enregistrements de la base, un nom de liste doit être spécifié. Cette liste contiendra tous les enregistrements associés à l'entité.

Exemple d'utilisation du Transformer Joiner

Un cache est utilisée par le Transformer Joiner, pour joindre des enregistrements à des entités graphiques. Quand FME lit un enregistrement à apparier, il le met dans le cache. Pour les entités suivantes, le cache est d'abors consulté avant de vérifier la base. Quand des enregistrements sont appariés à plusieurs entités, FME ne vérifie pas la base de données, car l'information est déjà contenue dans la mémoire (le cache). Ceci raccourcit donc le processus de jointure et diminue le trafic réseau.

Voici un bon exemple...

@Relate: Database query statistics for table 'JOINER:MY_TABLE':

7 queries made of which 0 were sequential duplicates

and 1 hit the record cache of 3 records (14% overall cache hit)

Le nombre d'enregistrements appariés n'est pas spécifié, mais on peut supposer qu'il est de 4. 3 entités ont été appariées, toutes avec un IDs différent et FME ajoute 3 enregistrements au cache. La quatrième entité correspondante n'a pas eu à envoyer de requête à la base de données car elle correspondait à l'une des entités mises en cache. Ce qui explique l'origine du 14%. Il y a eu 7 requêtes et une d'elles a utilisé le cache (1/7 = 14%). Ainsi, FME a permis de réduire le traffic réseau pour cette requête de 14%.

La description suivante "sequential duplicates" indique par conséquent le nombre d'entités ayant le même identifiant.Par exemple...

@Relate: Database query statistics for table 'JOINER:MY_TABLE':

7 queries made of which 3 were sequential duplicates

and 2 hit the record cache of 2 records (71% overall cache hit)

Ici, il y a eu deux accès au cache, ainsi que 3 entités dupliquées (2+3 = 5 et 5/7 = 71%).

Le cache affecte donc les performances, mais comment faire pour les améliorer ? Il y a deux paramètres qui peuvent être contrôlés dans Joiner.

Le premier est la taille du cache. Habituellement, seul un sous ensemble des enregistrements est mis en cache. Le paramètre TAILLE DU CACHE spécifie le nombre d'enregistrements devant être mis dans le cache. Une fois le cache rempli, de nouveaux enregistrements ne peuvent être ajoutés qu'en supprimant des existants. Ainsi, plus le cache est important, moins il y a d'accès à la base de données.

Bien sûr, la valeur à donner à ce paramètre dépend du nombre d'enregistrements, de leur fréquence d'appariement et de la mémoire dont dispose votre système. Dans certains cas, il est plus efficace d'accéder systématiquement à la base plutôt que de gérer un cache trop important qui va entraîner un dépassement de mémoire.

Conseil : d
éfinissez une taille de cache correspondant à la taille de votre jeu de données et au nombre d'accès probable au cache.

Un second paramètre de cache disponible est le pré-chargement. Plutôt que de remplir le cache enregistrement par enregistrement, il est possible de le charger en une seule fois à partir d'une requête définie par l'utilisateur. Cette requête prefetch peut sélectionner une table entière ou une partie de table d'avantage susceptible de correspondre aux attributs des entités.

Par exemple, un certains nombre d'entités de type "routes" doivent être appariées à une base de données. La table de la base (myrecords) a un champ (record_type) avec différentes valeurs comme routes, autoroutes, avenues, rues... Les entités FME ne seront appariées qu'avec des enregistrements pour lesquels type=routes, le processus de jointure serait plus efficace avec la requête de pré-chargement:

SELECT * from myrecords where record_type = 'routes'

Implémentation

Fonction(s) de bas niveau utilisée(s) (Function ou Factory): @Relate