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.
DataObjects de parámetro para consultas generadas
// 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
// 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);
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.
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 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.
- 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.
- 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.
- 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.
- 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.