Trabalhando com Controles Lookup

Trabalhando com Controles Lookup

No Delphi chamamos de “Lookup” o mecanismo que representa o relacionamento entre duas tabelas dinamicamente e de forma automatizada para a manipulação de uma delas. Isso consiste em duas operações:

A primeira é de exibir a descrição de um dado a qual não existe no registro da tabela que esta sendo manipulada.
A segunda é, ao mesmo tempo que lista a descrição, sincronizadamente, atribui o valor do campo chave, de relacionamento entra as tabelas envolvidas no lookup, para a tabela que esta sendo manipulada.

Por exemplo, vejamos o relacionamento entre duas tabelas: “Produtos” e “Categoria de Produtos” (as quais usamos no artigo anterior). Primeiro a tabela Producs, abaixo:

Temos o ID da Categoria, mas não temos a descrição dela nesta tabela. A descrição da Categoria encontra-se na tabela Categories.

Existe um relacionamento entre elas ... (Mas isso não é obrigatório para se fazer o Lookup). Essa relação entre os campos pode ser feita pela aplicação, basta que exista um relacionamento lógico entre as colunas das tabelas que serão relacionadas.

O que essa estrutura me força previamente entender? _ Devo entender que para atualizar a tabela de “Produtos” dependerei sempre dos valores existentes na tabela “Categorias”. Isso porque, os valores possíveis para a categoria de produtos está armazenado na tabela Categoria, e a constraint que define a integridade referencial entre as duas tabelas jamais permitirá que seja inserido um valor para categoryID na tabela “Products” que não exista em “Categories”. Isso é muito bom que seja dessa forma.

O Lookup permite reproduzirmos essa relação, respeitando a referencia entre as tabelas de forma automática, suprimindo totalmente a necessidade da codificação de sequer uma linha de código para isso.

Os Controles de Lookup mais comuns são:

DBLookupComboBox: TDBLookupComboBox;
DBLookupListBox: TDBLookupListBox;

Intraweb Framework
IWDBLookupComboBox: TIWDBLookupComboBox;
IWDBLookupListBox: TIWDBLookupListBox;

Dev Express
cxDBLookupComboBox: TcxDBLookupComboBox;
cxDBCheckComboBox: TcxDBCheckComboBox;

Jedi
JvDBLookupComboEdit: TJvDBLookupComboEdit;

Campo Virtual LookUp

Tfield fkLookup: A mesma lógica descrita acima é aplicada também aos Datasets, especificamente quando, através deles trabalhamos com o que a literatura chama de campos persistentes. Trata-se de objetos da classe Tfield. Quando manipulamos dados usando Datasets (TDataset) podemos criar objetos que representam a referência linha/coluna de uma tabela. Esses objetos chamamos de campos de um Dataset, eles nos permitem acessar um determinado dado de um registro. Os Tfields podem ser de vários tipos. Cada tipo determina um grupo de operações que poderá realizar o Tfield. A Propriedade FieldKind determina o tipo do Tfield.
fkData, fkCalculated, fkLookup, fkInternalCalc, fkAggregate são os valores possiveis para a propriedade FieldKind. A Classe TFieldKind, definida na unit DB, define esses valores:

type TFieldKind = (fkData, fkCalculated, fkLookup, fkInternalCalc, fkAggregate);

O Tfield usado para fazermos Lookup é do tipo “fkLookup”. Isso quer dizer que a propriedade FieldKind é “fkLookup”.

Usamos a técnica de Lookups com os Fields (TFild) de um Dataset (Um TclientDataSet por exemplo) quando existe a necessidade de acessarmos (disponibilizarmos, visualizarmos) dados provenientes de tabelas diferentes num único resultset. Como por exemplo, ao apresentar uma listagem de “Pedidos” precisamos explicitamente exibir na tela: O nome do cliente que efetuou a compra, a data do pedido e a descrição dos produtos vendidos. Obviamente, a primeira coisa que vem a mente é o recurso de utilizarmos um join em SQL.

SELECT
  C.NomeCliente,
  P.DataPedido,
  I.Quantidade,
  I.PrecoVenda,
 (I.Quantidade * I.PrecoVenda) Total,
  P.DescricaoProduto
FROM
  Clientes C
  inner join Pedidos P on
    C.ClienteID = P.ClikenteID
  inner join Itens I on
    I.PedidoID = P.PedidoID
  inner join Produtos Pr on
    Pr.ProdutoID = I.ProdutosID

Contudo, num Dataset, isto impossibilitaria a utilização do mesmo para qualquer atualização nestes dados (Obviamente, isso é verdadeiro se não consideramos a técnica de gerenciarmos explicitamente, via código, o evento “BeforeUpdateRecord” do DataSetProvider – Falaremos sobre está técnica mais adiante).
No Delphi, o campo (TField) “virtual” lookUp funciona, no que tange a visualização de dados, de forma semelhante ao join. Ou seja, podemos configurar um determinado Dataset trazendo dados através de um comando SQL genérico (Select * from ) de uma única tabela, como o exemplo anterior, “Products”, e adicionarmos a ele um campo virtual que irá conter informações de um outro Dataset. A exemplo da relação entre Products e Categories, demonstrado acima. A grande vantagem desta técnica é porque mesmo disponibilizando dados de tabelas diferentes e ainda assim podermos atualizar os dados usando os comandos convencionais do próprio Dataset. Para fazermos uso do campo LookUp basta que os Datasets possuam um campo de relacionamento.

Vejamos agora, a utilização do campo LookUp:

Suponha que neste momento queremos criar um cadastro (CRUD) de produtos. Mas temos um problema, o banco apresenta um normalização para a tabela produtos de maneira que o dado categoria do produto esta em outra tabela. A tabela Categorias (no caso Categories) é uma tabela de referência. Ela não é transacional e possui um número relativamente pequeno de registros.
Lembre-se que, na hora de incluirmos novos Produtos precisamos digitar, na interface, os dados necessários da tabela de produtos, sendo que para os campos “CategoryID” e “SupplierID” presimos apresentar as descrições de cada um dos campos. Entretanto, o dado, descrição da categoria, por exemplo, encontra-se na tabela de Categories. Ou seja, temos que ler da tabela de Categories: a descrição (Categories.Description), e o valor do respectivo vampo de relacionamento (Categories.CategoryID). Para, então, atribuir a Produtos (Products.CategoryID).

Para isso usaremos um Dataset, o CdsProdutos, criaremos nele um campo lookUp que apontará para o campo Description de Categories no CdsCategorias.
Existe o campo de relacionamento entre essas duas tabelas, esses dois campos estão presentes tanto no CdsProdutos (Products.CategoryID), quanto no CdsCategorias (Categories.CategoryID) possibilitando desta forma um “join virtual”, entre CdsProdutos e CdsCategorias. Consequentimente, podemos ainda assim a atualizar o recordset do CdsProdutos. Outro bonus fundamental dessa técnica é, o que que propositalmente guardei para relembrar no final, de que com o campo LookUp a atribuição de valor ao campo “Products.CategoryID” e feita automaticamente sem a necessidade de código para isso, proveniente do link feito com Categories.CategoryID. Isso ocorre imediatamente a ação do usuário selecionar a descrição da categoria no controle lookup disponibilizado na interface.

As linhas vermelhas indicam as propriedades envolvidas na configuração de um de um controle DBLookup (DBLookupComboBox). AS Linhas verdes indicam os valores, e suas origens, que devem ser associadas as respectivas propriedades.

Criando o Campo Virtual LookUp

Com o botão direito do mouse sobre o CdsProdutos, selecione “Fields Editor ...”

Para criar um novo Field, botão direito no “Fields Editor” e selecione “New Field” (Ou digite “Ctrl + N”).

No Diálogo de definição do novo Field configure as propriedades conforme ilustrado na figura abaixo.

Na propriedade “Name” será definido o nome da coluna/campo virtual. Automaticamente, enquanto você digitar o Delphi gera o nome do objeto Tfield em “Component”. A propriedade “Type” define o tipo de dado que o Tfield irá trabalhar, internamente isso irá definir a propriedade DataType cujo o tipo é “TfieldType”, por sua vez isso refletirá na definição de uma classe que especializa o Tfield a qual o Field criado instanciará.
Dependendo do tipo escolhido em “Type” será imprescindível definir o tamanho do Field. Isso quer dizer, por exemplo, se o campo for do tipo String, o limite máximo quanto ao número de caracteres que o Field poderá armazenar. Logo, na propriedade “Size” digite um valor adequado para o tamaho, limite de caracteres, no campo “CategoriaVirt”. É mais que aconselhável você conferir no banco qual o tamanho da coluna “Categories.CategoryName”, visto que será os valores armazenados por ela listados por esse novo campo.

Em Field Type marque Lookup, em resposta a essa ação os campos de “Lookup definition” serão habilitados, em “Key Fields” e “Lookup Keys” selecionamos as colunas de relacionamento entre os Datasets envolvidos no Lookup. Todavia, para habilitar a propriedade Dataset (onde devemos definir o Dataset que disponibilizara os dados para Lookup, no nosso caso CdsCategorias), temos que selecionar primeiro a coluna do CdsProdutos que faz o relacionamento com Categorias (CategoryID).

Na propriedade DataSet, repetindo, é onde definimos o Dataset de Lookup. Selecione CdsCategorias.
Na propriedade “Lookup Keys”, selecionamos a coluna, do Dataset o qual escolhemos na propriedade “Dataset”, que se relaciona com o CdsProdutos (CategoryID).
Por fim, na propriedade “Result Field” selecionamos a coluna do CdsCategorias que servirá para listar os dados da descrição da categoria. Ou melhor, a coluna para a qual nosso campo virtual “CategoriaVirt” apontará. Selecione “CategoryName”.

Portanto, olhando a tamanho da coluna em “Disign Table” no Enterprise Manager, podemos definir o valor 15 para a propriedade “Size”.

Para finalizar, após definir todas as propriedades, click em “OK”

Se você fizer um Drag and Drop do novo Field virtual Lookup para o Form veja que será criado um controle DbLookupCombobox associado ao CdsProdutos pelo DataSource “DsProdutos”.

Para testar, adicione um DbGrid ao Form1, associe ele ao DataSource DsProdutos (através da propriedade “DataSource” do DbGrid, no Object Inspector). No Evento OnCreate Do Form1 abra os dois Cds (CdsProdutos e CdsCategorias).

procedure TForm1.FormCreate(Sender: TObject);
begin
  CdsCategotias.Open;
  CdsProdutos.Open;
end;

Observações:

Embora apresente um ganho extraordinário para o desenvolvimento no front-end ,em situações onde trabalhamos com CRUD que envolve tabelas normalizadas, a técnica de lookup nem sempre será adequada. Observamos diversas situações em que o emprego do Lookup trará grande inconveniência, tanto no para usabilidade quanto para outros pontos importantes como: Performance e manutenibilidade. Um caso onde o Lookup é desaconselhado é quando a tabela de lookup possui muitos registros.

Em substituição a técnica de Lookup devemos usar, em conjunto, mais de uma técnica. Um exemplo comum é o join no próprio SQL do Dataset que manipula os dados, para tratar o pacote transacional posteiormente no evento BeforeUpdateRecord do DatasetProvider. Mas isso exige conhecimento intermediário em DataSnap. Em Breve abordaremos esse tema!