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.
Objets de données Paramètre pour requêtes générées
// 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
// 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);
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.
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 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.
- 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.
- 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.
- 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.
- 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.