Consulta generada por JDBC Mediator

Si no proporciona una sentencia SELECT de SQL (Lenguaje de consulta estructurada), DMS (Data Mediator Service) genera una con los metadatos proporcionados en la creación de la instancia.

El motor de consulta interno utiliza información de los metadatos acerca de tablas, columnas, relaciones, filtros y tipo de ordenación para crear una consulta. Igual que con las consultas suministradas, se generan automáticamente las sentencias UPDATE, DELETE e INSERT para cada DataObject al que se van a aplicar cuando el Mediator compromete los cambios realizados en el DataGraph de nuevo a la base de datos.

Filtros

Los filtros definen cláusulas WHERE de SQL que podrían contener marcadores de parámetro. Estos se añaden a la cláusula WHERE de la sentencia SELECT del DataGraph. Los filtros se utilizan tal cual están; no se analizan ni interpretan de ningún modo, por lo tanto, no hay una comprobación de errores. Si utiliza un nombre, predicado o función incorrecto, no se detectará y la consulta generada no será válida. Si una cláusula WHERE de filtro contiene marcadores de parámetro, entonces el nombre y el tipo de parámetro correspondientes se definen utilizando argumentos de filtro. Los DataObjects de parámetro rellenan estos parámetros antes de que se recupere el gráfico. A continuación figura un ejemplo de DataObjects de filtros y parámetro para consultas generadas.

Limitación: Dada la naturaleza del DataGraph similar a un árbol, cualquier tabla en una rama aparece en más de una subconsulta en la unión final y la tabla raíz aparece en todas las vías de acceso. Esto significa que no es posible filtrar en una tabla que aparece en más de una vía de acceso independiente de todas las demás vías de acceso. Todos los filtros definidos en una tabla en particular se unen mediante un operador AND booleano y se utilizan en todos los lugares donde aparece la tabla.

DataObjects de parámetro para consultas generadas

Los clientes utilizan un DataObject de parámetro para suministrar argumentos que se aplican a los filtros proporcionados en los metadatos de DMS. Un DataObject de parámetro es un DataObject, pero no es parte de ningún DataGraph. Se construye mediante el DMS de JDBC cuando lo solicita el cliente. El DataObject de parámetro para consultas generadas se crea basándose en los metadatos del mediator. Cada argumento de cada filtro de cada tabla se incluye en el DataObject de parámetro. A diferencia del DataObject de parámetro de consulta proporcionado, los parámetros tienen el nombre asignado a ellos mediante los argumentos de filtro. El DataObject de parámetro utiliza este nombre para establecer una correlación con el parámetro que se va a rellenar. El código de ejemplo siguiente ilustra cómo se crea un filtro para una tabla en los metadatos del Mediator. También demuestra el uso de un DataObject de parámetro para pasar valores de parámetro de filtro a una instancia de Mediator. En el ejemplo se supone que ya se ha definido la tabla Customer (Cliente):
// La fábrica es un objeto MetadataFactory
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 es el objeto de tabla de cliente
custTable.setFilter(filter);


..... // configuración de mediador 


DataObject parameters = mediator.getParameterDataObject();

// Observe que el primer parámetro es el nombre dado al 
// argumento del FilterArgument.
parameter.setString("customerState", "NY");
parameter.setInt("customerZipCode", 12345);
DataObject graph = mediator.getGraph(parameters);

Order-by

La ordenación de los resultados de consulta se especifica utilizando objetos OrderBy que identifican una columna de una tabla para ordenar los resultados. Esta ordenación puede ser ascendente o descendente. Los objetos OrderBy son parte de los metadatos y se aplican automáticamente a las consultas generadas. A continuación figura un ejemplo de esto con los resultados de una tabla de cliente ordenados por nombre:
// En este ejemplo se supone que custTable, una tabla en 
// los metadatos y fábrica, la MetaDataFactory 
// ya se han creado. 
Column firstName = ((TableImpl)custTable).getColumn("CUSTFIRSTNAME");
OrderBy orderBy = factory.createOrderBy();
orderBy.setColumn(firstName);
orderBy.setAscending(true);
metadata.getOrderBys().add(orderBy);
Limitación: Aunque se definen cláusulas Order-by en cada tabla del metadato, el modelo de RDBMS requiere que se apliquen a la consulta final. Esto tiene muchas implicaciones. Por ejemplo, no puede ordenar una tabla y luego utilizar el resultado en una unión con otra tabla y propagar la ordenación en la primera tabla. Como un conjunto de resultados es una unión de todas las tablas del DataGraph, la naturaleza del conjunto de resultados único requiere que se rellene con nulos, lo que puede afectar a las cláusulas order-by, particularmente en las tablas no raíz. Esto puede dar resultados inesperados.

Tablas externas

Una tabla externa es una tabla definida en los metadatos que no es necesaria en el DataGraph devuelto por el DMS de JDBC. Esto podría ser adecuado si desea filtrar el conjunto de resultados basándose en los datos de una tabla pero esos datos de la tabla no son necesarios en el conjunto de resultados. Un ejemplo de esto con la relación Customers (Clientes) y Orders (Pedidos) sería filtrar los resultados para devolver todos los clientes que solicitaron artículos con una fecha de pedido del primero del año. En este caso, no desea que se devuelva ninguna información del pedido, pero no tiene que filtrar en la información del pedido. Si hace que la tabla Orders (Pedidos) sea externa se excluye la información de pedidos del DataGraph y por lo tanto se reduce el tamaño del DataGraph, lo que mejora la eficacia. Para designar una tabla como externa, puede llamar al método setExternal(true) desde un objeto tabla del metadato del DMS del JDBC. Si el cliente intenta acceder a una tabla externa del DataGraph, se produce una excepción de argumento no permitido.

Limitación: Muchos RDBMS requieren que aparezca una columna orderby en el conjunto de resultados final; las columnas de una tabla externa en general no se pueden utilizar para ordenar un conjunto de resultados. Las cláusulas Order-by realmente se aplican al conjunto de resultados (la palabra "set" es clave aquí) y no a resultados de consulta intermedios.

Limitaciones generales de consultas generadas

Para comprender las limitaciones de la función de generación de consultas del DMS de JDBC, hay dos cosas que se han de tener en cuenta. La primera es que el DataGraph impone un modelo que es un gráfico dirigido y conectado sin ciclos (es decir, un modelo que es un árbol) en un modelo relacional que es un gráfico no dirigido y potencialmente desconectado con ciclos. Dirigido significa que el desarrollador elige la orientación del gráfico seleccionando una tabla raíz. Conectado significa que se puede llegar a todas las tablas que son miembros del DataGraph desde la raíz. Las tablas a las que no se pueda llegar desde la raíz no se pueden incluir en el DataGraph. Para que se pueda llegar a una tabla desde la raíz, debe haber al menos una relación de clave foránea definida entre cada para de tablas del DataGraph. Sin ciclos significa que sólo hay una relación de clave foránea entre un par de tablas del DataGraph. La naturaleza de árbol del DataGraph determina cómo se crean las consultas y qué datos se devuelven de la consulta.

El segundo elemento a tener en cuenta es la siguiente descripción de alto nivel de cómo la generación de consulta produce consultas de lectura de los DataGraph:
  1. El DMS de JDBC crea un solo conjunto de resultados (es decir, un DataGraph) tanto si el DataGraph se compone de una sola tabla o de varias.
  2. Cada vía de acceso en las relaciones de clave foránea de metadatos de DMS desde la raíz a las hojas representa una vía de acceso aparte. Los datos de la vía de acceso se recuperan utilizando uniones a través de las claves foráneas definidas entre las tablas de la vía de acceso. Las uniones son las uniones interiores predeterminadas.
  3. Todas las vías de acceso de un DataGraph se unen para crear un solo conjunto de resultados de la consulta que el mediador genera y de este modo se tratan de modo independiente unas de otras.
  4. Cualquier filtro definido por el usuario se realiza primero en las tablas. Luego el resultado se une al resto de la vía de acceso.
  5. Las bases de datos relacionales generalmente requieren que se apliquen cláusulas order-by a todo el conjunto de resultados final y no a los resultados intermedios.

Icon that indicates the type of topic Reference topic



Timestamp icon Last updated: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rdat_sdogquery
File name: rdat_sdogquery.html