Requête générée par le médiateur JDBC

Si vous ne fournissez pas d'instruction SELECT SQL (Structured Query Language), le service DMS (Data Mediator Service) en génère une à l'aide des métadonnées fournies au moment de la création de l'instance.

Le moteur de requêtes interne utilise des informations contenues dans les métadonnées sur les tables, les colonnes, les relations, les filtres et les objets ORDER BY pour générer une requête. Comme avec les requêtes fournies, les instructions UPDATE, DELETE et INSERT sont automatiquement générées pour chaque objet de données en vue d'être appliquées lorsque le médiateur valide les modifications apportées au datagraphe dans la base de données.

Filtres

Les filtres définissent une clause SQL WHERE qui peut contenir des marqueurs de paramètre. Ces derniers sont ajoutés à la clause WHERE de l'instruction SELECT du datagraphe. Les filtres sont utilisés tels quels ; ils ne sont pas analysés ni interprétés et ne sont donc soumis à aucune vérification d'erreur. Si vous utilisez un nom, un prédicat ou une fonction incorrects, ils ne sont pas détectés et la requête générée n'est pas valide. Si une clause WHERE d'un filtre contient des marqueurs de paramètre, alors le nom et le type du paramètre correspondant sont définis à l'aide des arguments du filtre. Les objets de données Paramètre renseignent ces paramètres avant que le graphique ne soit extrait. Un exemple d'objets de données Filtres et Paramètre pour les requêtes générées est fourni ci-dessous.

Restriction : En raison de la nature arborescente du datagraphe, toute table située au niveau d'une branche figure dans plusieurs sous-requêtes dans le résultat final et la table racine figure dans tous les chemins d'accès. Cela signifie qu'il n'est pas possible d'effectuer un filtrage sur une table qui figure dans plusieurs chemins indépendants de tous les autres chemins. Tous les filtres définis sur une table spécifique sont reliés par un opérateur booléen AND et utilisés partout où cette table apparaît.

Objets de données Paramètre pour requêtes générées

Les clients utilisent un objet de données Paramètre pour fournir des arguments qui sont appliqués aux filtres fournis dans les métadonnées DMS. Un objet de données Paramètre est un objet de données qui ne fait partie d'aucun datagraphe. Il est créé par le service DMS JDBC lorsque le client émet une requête. L'objet de données Paramètre pour les requêtes générées est créé en fonction des métadonnées du médiateur. Chaque argument de chaque filtre de chaque table est placé dans l'objet de données Paramètre. A la différence de ce qui se passe avec l'objet de données Paramètre d'une requête fournie, un nom est affecté aux paramètres par les arguments du filtre. L'objet de données Paramètre utilise ce nom pour effectuer un mappage vers le paramètre qui doit être renseigné. L'exemple de code suivant illustre la façon dont un filtre est créé pour une table dans les métadonnées du médiateur. Il illustre également l'utilisation d'un objet de données Paramètre pour transmettre des valeurs de paramètres de filtre à une instance du médiateur. L'exemple suppose que la table Customer a déjà été définie :
// The factory is a MetadataFactory object
Filter filter = factory.createFilter();
filter.setPredicate("CUSTSTATE = ? AND CUSTZIP = ?");

FilterArgument arg0 = factory.createFilterArgument();
arg0.setName("customerState");
arg0.setType(Column.String);
queryInfo.getFilterArguments().add(arg0);

FilterArgument arg1 = factory.createFilterArgument();
arg1.setName("customerZipCode");
arg1.setType(Column.Integer);
queryInfo.getFilterArguments().add(arg1);

// custTable is the Customer Table object
custTable.setFilter(filter);


..... // setting up mediator 


DataObject parameters = mediator.getParameterDataObject();

// Notice the first parameter is the name given to the 
// argument by the FilterArgument.
parameter.setString("customerState", "NY");
parameter.setInt("customerZipCode", 12345);
DataObject graph = mediator.getGraph(parameters);

Order-by

L'ordre de tri des résultats de requêtes est spécifié à l'aide des objets OrderBy qui identifient une colonne d'une table pour trier les résultats. Cet ordre de tri peut être soit croissant, soit décroissant. Les objets OrderBy font partie des métadonnées et sont appliqués automatiquement aux requêtes générées. Voici un exemple s'appliquant aux résultats d'une table de clients devant être triés en fonction des prénoms :
// This example assumes that the custTable, a table in 
// the metadata, and factory, the MetaDataFactory 
// object, have already been created. 
Column firstName = ((TableImpl)custTable).getColumn("CUSTFIRSTNAME");
OrderBy orderBy = factory.createOrderBy();
orderBy.setColumn(firstName);
orderBy.setAscending(true);
metadata.getOrderBys().add(orderBy);
Restriction : Bien que des objets Order-by soient définis sur chaque table dans les métadonnées, le modèle SGBDR nécessite qu'ils soient appliqués à la requête finale. Cela a de nombreuses implications. Par exemple, vous ne pouvez pas trier une table, puis l'utiliser dans une jonction vers une autre table et propager l'ordre de tri de la première table. Etant donné qu'un ensemble de résultats représente une union de toutes les tables du datagraphe, la nature de l'ensemble de résultats unique nécessite qu'il soit rempli de valeurs NULL, ce qui peut affecter les objets ORDER BY, en particulier dans les tables autres que la table racine. Cela peut produire des résultats inattendus.

Tables externes

Une table externe est une table définie dans les métadonnées et qui n'est pas requise dans le datagraphe renvoyé par le service DMS JDBC. Son utilisation peut être appropriée lorsque vous souhaitez filtrer l'ensemble de résultats en fonction des données d'une table, mais que les données de cette table ne sont pas requises dans l'ensemble de résultats. Un exemple d'utilisation de table externe avec la relation Customers et Orders consisterait à filtrer les résultats de façon à renvoyer à tous les clients ayant commandé des articles une date de commande correspondant au premier jour de l'année. Dans ce cas, vous ne souhaitez pas que des informations de commande soient renvoyées, mais vous avez besoin d'effectuer un filtrage des informations de commande. En faisant de la table Orders une table externe, vous excluez les informations de commande du datagraphe et réduisez donc la taille de ce dernier, d'où une efficacité accrue. Pour désigner une table comme étant externe, vous devez appeler la méthode setExternal(true) à partir d'un objet de table dans les métadonnées du service DMS JDBC. Si le client tente d'accéder à une table externe à partir du datagraphe, une exception d'argument non autorisé est générée.

Restriction : De nombreux SGBDR requièrent qu'une colonne ORDER BY figure dans l'ensemble de résultats final : les colonnes d'une table externe ne peuvent pas, en général, être utilisées pour appliquer un ordre de tri à un ensemble de résultats. Les objets ORDER BY sont réellement appliqués à l'ensemble de résultats (le terme "ensemble" est significatif ici), et non aux résultats des requêtes intermédiaires.

Limitations générales des requêtes générées

Pour comprendre les limitations de la fonction de génération de requêtes dans le service DMS JDBC, il faut tenir compte de deux facteurs. Le premier est que le datagraphe impose un modèle qui est un graphique connecté et dirigé ne comportant pas de cycles (c'est-à-dire que ce modèle est une arborescence) de préférence à un modèle relationnel non dirigé, potentiellement déconnecté et comportant des cycles. Dirigé signifie que le développeur choisit l'orientation du graphique en choisissant une table racine. Connecté signifie que toutes les tables faisant partie du datagraphe sont accessibles à partir de la racine. Toute table qui n'est pas accessible à partir de la racine ne peut pas être inclue dans le datagraphe. Pour qu'une table soit accessible à partir de la racine, au moins une relation de clé externe doit être définie entre chaque paire de tables du datagraphe. Aucun cycle signifie qu'il existe une seule relation de clé externe entre une paire de tables du datagraphe. La nature arborescente du datagraphe détermine la façon dont les requêtes sont créées et quelles données sont renvoyées à partir d'une requête.

Le deuxième aspect à prendre en considération est la description de haut niveau suivante de la façon dont la génération de requêtes génère des demandes de lecture d'un datagraphe :
  1. Le service DMS JDBC crée un seul ensemble de résultats, ou datagraphe, que ce datagraphe soit composé à partir d'une seule table ou de plusieurs tables.
  2. Chaque chemin déterminé par les relations de clé externe des métadonnées DMS à partir de la racine jusqu'aux feuilles représente un chemin d'accès. Les données associées à ce chemin d'accès sont extraites à l'aide de jointures à travers les clés externes définies entre les tables incluses dans le chemin. Les jointures sont par défaut des jointures internes.
  3. Tous les chemins d'accès d'un datagraphe sont réunis de façon à ne générer qu'un seul ensemble de résultats pour la requête générée par le médiateur et sont donc traités indépendamment les uns des autres.
  4. Tout filtrage défini par l'utilisateur s'effectue d'abord sur les tables. Le résultat est ensuite joint au reste du chemin d'accès.
  5. Les bases de données relationnelles requièrent généralement que les objets ORDER BY soient appliqués à l'ensemble de résultats final dans son intégralité, mais pas aux résultats intermédiaires.

Icône indiquant le type de rubrique Rubrique de référence



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rdat_sdogquery
Nom du fichier : rdat_sdogquery.html