Consulta Gerada pelo Mediador JDBC

Se você não fornecer uma instrução SELECT SQL (Structured Query Language), o DMS (Data Mediator Service) gerará uma utilizando os metadados fornecidos na criação da instância.

O mecanismo de consulta interno usa informações nos metadados sobre tabelas, colunas, relacionamentos, filtros e order-bys para construir uma consulta. Assim como com as consultas fornecidas, as instruções UPDATE, DELETE e INSERT são automaticamente geradas para cada DataObject a ser aplicado quando o mediador consolidar as alterações feitas no DataGraph de volta ao banco de dados.

Filtros

Os filtros definem uma cláusula SQL WHERE que pode conter marcadores de parâmetro. Eles são incluídos na cláusula WHERE da instrução SELECT do DataGraph. Os filtros são utilizados no estado em que se encontram; eles não são analisados ou interpretados de qualquer maneira; portanto, não há verificação de erros. Se você utilizar nome, predicado ou função incorreta, ela não será detectada e a consulta gerada não será válida. Se a cláusula WHERE de Filter contiver marcadores de parâmetro, o nome e o tipo do parâmetro correspondente serão definidos utilizando argumentos Filter. O parâmetro DataObjects preenche esses parâmetros antes que o gráfico seja recuperado. Segue um exemplo de DataObjects de Filtros e Parâmetro para consultas geradas.

Limitação: Como a natureza em formato de árvore do DataGraph, qualquer tabela em uma ramificação aparece em mais de uma subconsulta na união final com a tabela raiz aparecendo em todos os caminhos. Isso significa que não é possível filtrar em uma tabela que aparece em mais de um caminho independente de todos os outros caminhos. Todos os filtros definidos em uma tabela específica são unidos por um AND booleano e utilizados em qualquer lugar que a tabela apareça.

DataObjects de Parâmetro para Consultas Geradas

Os clientes utilizam um DataObject de Parâmetro para fornecer argumentos que são aplicados a filtros fornecidos nos metadados do DMS. Um DataObject de Parâmetro é um DataObject, mas não faz parte de qualquer DataGraph. Ele é construído pelo JDBC DMS quando solicitado pelo cliente. O Objeto de Dados do Parâmetro para consultas geradas é criado com base nos metadados do mediador. Cada argumento de cada filtro de cada tabela é colocado no no DataObject de Parâmetro. Ao contrário do DataObject de Parâmetro da consulta fornecida, os parâmetros possuem o nome designado a eles pelos argumentos Filter. O DataObject de Parâmetro utiliza esse nome para mapear para o parâmetro a ser preenchido. O código de amostra a seguir ilustra como um filtro é criado para uma tabela nos metadados do mediador. Ele também demonstra o uso de um DataObject de Parâmetro para transmitir valores de parâmetro de filtro a uma instância do mediador. A amostra supõe que a tabela Cliente já foi definida:
// O depósito de informações do provedor é um 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 is the Customer Table object
custTable.setFilter(filter);


..... // configurando o mediador 


DataObject parameters = mediator.getParameterDataObject();

// Observe que o primeiro parâmetro é o nome atribuído ao 
// argumento pelo FilterArgument.
parameter.setString("customerState", "NY");
parameter.setInt("customerZipCode", 12345);
DataObject graph = mediator.getGraph(parameters);

Order-by

A solicitação dos resultados de consulta é especificada utilizando objetos OrderBy que identificam uma coluna de uma tabela para classificar os resultados. Essa classificação pode ser ascendente ou descendente. Os objetos OrderBy fazem parte dos metadados e são aplicados automaticamente às consultas geradas. Um exemplo disso para resultados da tabela de um cliente a ser classificado pelo primeiro nome é o seguinte:
// Esse exemplo supõe que custTable, uma tabela nos 
// metadados e o depósito de informações do provedor, o objeto MetaDataFactory, 
// já tenham sido criados. 
Column firstName = ((TableImpl)custTable).getColumn("CUSTFIRSTNAME");
OrderBy orderBy = factory.createOrderBy();
orderBy.setColumn(firstName);
orderBy.setAscending(true);
metadata.getOrderBys().add(orderBy);
Limitação: Embora os Order-bys sejam definidos em cada tabela nos metadados, o modelo RDBMS requer que eles sejam aplicados à consulta final. Isso tem várias implicações. Por exemplo, você não pode solicitar uma tabela e, em seguida, utilizá-la em uma união com outra tabela e propagar a classificação na primeira tabela. Como um conjunto de resultados é uma união de todas as tabelas no DataGraph, a natureza do único conjunto de resultados requer que ele seja preenchido com nulos, o que pode afetar os ordenados por, especialmente nas tabelas não raiz. Isso pode provocar resultados inesperados.

Tabelas externas

Uma tabela externa é uma tabela definida nos metadados que não é necessária no DataGraph retornado pelo JDBC DMS. Isso pode ser apropriado quando você desejar filtrar o conjunto de resultados com base nos dados de uma tabela, mas os dados dessa tabela não são necessários no conjunto de resultados. Um exemplo disso com o relacionamento de Clientes e Pedidos seria filtrar os resultados para retornar todos os clientes que solicitaram itens com uma data de pedido do primeiro dia do ano. Nesse caso, você não deseja que qualquer informação de pedido seja retornada, mas precisa filtrar as informações de pedido. Tornar a tabela de Pedidos externa exclui as informações de pedidos do DataGraph e, portanto, reduz o tamanho do DataGraph, melhorando a eficiência. Para designar uma tabela como externa, você chama o método setExternal(true) de um objeto da tabela nos metadados do JDBC DMS. Se o cliente tentar acessar uma tabela externa do DataGraph, ocorrerá uma exceção de argumento ilegal.

Limitação: Vários RDBMSs requerem que uma coluna orderby apareça no conjunto de resultados final; as colunas de uma tabela externa não podem ser utilizadas, em geral, para ordenar um conjunto de resultados. Order-bys são na verdade aplicados no conjunto de resultados (a palavra "conjunto" é a chave aqui), e não para resultados da consulta intermediários.

Limitações Gerais de Consultas Geradas

No entendimento das limitações do recurso de geração de consulta no JDBC DMS, há duas coisas a serem lembradas. A primeira é que o DataGraph impõe um modelo que é um gráfico conectado direcionado sem ciclos (ou seja, um modelo que é uma árvore) em um modelo relacional que é um gráfico potencialmente desconectado não direcionado com ciclos. Direcionado significa que o desenvolvedor escolhe a orientação do gráfico selecionando uma tabela raiz. Conectado significa que todas as tabelas que são um membro do DataGraph podem ser alcançadas a partir da raiz. Quaisquer tabelas que não forem alcançadas a partir da raiz não poderão ser incluídas no DataGraph. Para que uma tabela possa ser alcançável a partir da raiz, deve haver pelo menos um relacionamento de chave estrangeira definido entre cada par de tabelas no DataGraph. Sem Ciclos significa que há apenas um relacionamento de chave estrangeira entre um par de tabelas no DataGraph. A natureza da árvore do DataGraph determina como as consultas são construídas e quais dados são retornados de uma consulta.

O segundo item a ser lembrado é a seguinte descrição de alto nível de como a geração de consulta produz consultas de leitura para um DataGraph:
  1. O JDBC DMS cria um único conjunto de resultados (ou seja, um DataGraph) independentemente do DataGraph ser composto de uma única tabela ou de várias tabelas.
  2. Cada caminho por meio dos relacionamentos de chave estrangeira nos Metadados DMS da raiz até as folhas representa um caminho separado. Os dados para esse caminho são recuperados utilizando as uniões por meio de chaves estrangeiras definidas entre as tabelas no caminho. As uniões são, por padrão, uniões internas.
  3. Todos os caminhos em um DataGraph são unidos a fim de criar um único conjunto de resultados pela consulta que é gerada por um mediador e, portanto, são tratados independentemente entre si.
  4. Qualquer filtragem definida pelo usuário é feita primeiro nas tabelas. Em seguida, o resultado é unido ao resto do caminho.
  5. Os bancos de dados relacionais geralmente requerem que os order-bys sejam aplicados ao conjunto de resultados final inteiro e não nos resultados intermediários.

Ícone que indica o tipo de tópico Tópico de Referência



Ícone de registro de data e hora Última atualização: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rdat_sdogquery
Nome do arquivo: rdat_sdogquery.html