Artigo no estilo: Curso

Do que trata o artigo

Desenvolvimento de aplicação com validações realizadas por meio do banco de dados. Distribuição de tarefas entre banco de dados e aplicação, permitindo uma comparação e compreensão de como e quando usar estes recursos.


Para que serve

Permitir um total entendimento e visualização de sobre aplicação de recursos de bancos de dados e recursos de projeto, permitindo uma comparação e escolha do que deve ser feito em determinados casos.


Em que situação o tema é útil

Criar regras de validação no banco de dados que agilizem a manipulação de dados de acordo com diferentes situações, aplicar conceitos de boas práticas de programação em seus projetos, realizar comparativos entre modos de atualização via projeto e via banco de dados possibilitando assim uma visualização sua de livre escolha de qual utilizar, de acordo com sua necessidade.

Resumo do DevMan

Nesta parte do nosso artigo daremos continuação aos cadastros de nosso projeto, criando formulários não baseados em herança e aprendendo dicas interessantes para suas aplicações. Abordaremos também a utilização de validações realizadas por Triggers, visualizando as vantagens, maneiras de utilizar e compreendendo um pouco mais sobre este poderoso recurso.

Nas partes anteriores de nosso mini-curso já abordamos várias etapas do desenvolvimento de um software, passando por modelagem de dados, criação do banco de dados, definição de domínios, criação de métodos iniciais, organização da aplicação através de Data Modules, criação de conceitos de boas práticas e orientação a objetos abrangendo tópicos como herança e encapsulamento, gerenciamento, manipulação e entendimento de recursos de memória na criação de formulários, desenvolvimento de interfaces adotando os recursos de Ribbon Controls e introdução a novos componentes. Também passamos por uma parte interessante, onde realizamos melhorias em nossa aplicação, exibindo as vantagens de manutenção em uma aplicação bem estruturada e bem definida.

Nesta parte de nosso artigo iremos finalizar os cadastros restantes, trabalhar com a manipulação de dados através das Triggers do banco de dados, permitindo que o banco de dados gerencie as tarefas automaticamente, encarregando-se de realizar diferentes ações de acordo com o tipo de ocorrência. Realizaremos mais adaptações em nossos Data Modules, criaremos formulários não baseados em nossa herança, mas que possuam características semelhantes e que permitam a manipulação de dados diretamente no banco.

Por último realizaremos como dito na parte anterior a introdução aos relatórios, fazendo nessa parte a preparação do ambiente para os relatórios futuros de nosso projeto. Depois desta breve introdução vamos botar a mão na massa, pois temos muitas novidades a explorar e muito trabalho a desenvolver. Começaremos então pelo banco de dados e Data Modules.

Adaptando os Data Modules e Banco de dados

Antes de continuarmos, vamos realizar todas as adaptações necessárias em nossos Data Modules, realizando modificações para suportar nossas futuras consultas, relatórios, reservas, empréstimos e até mesmo todas as validações que até o momento não tínhamos visto.

Para suportar nossas futuras consultas, iremos alterar o DMPesquisa, portanto abra-o e insira mais dois conjuntos do trio SQLDataSet, DataSetProvider e ClientDataSet. Renomeie os SQLDataSets para sqlPesquisaReserva e sqlPesquisaEmprestimo, os DataSetProviders para dspPesquisaReserva e dspPesquisaEmprestimo e por último os ClientDataSets para cdsPesquisaReserva e cdsPesquisaEmprestimo. Observe como ficou o nosso Data Module naFigura 1.

Figura 1.DMPesquisa após modificações

Após adicionar os componentes vamos configurar suas propriedades para que possamos começar os cadastros. Ligue os DataSetProviders aos respectivos SQLDataSets por meio da propriedade DataSet e acrescente em Options a opção poAllowCommandText. Selecione os ClientDataSets e ligue-os aos DataSetProviders através de seu ProviderName. Passaremos agora para o Data Module principal, apenas para setar as propriedades restantes de nosso cdsFita.

Simplesmente abra o cdsFita e em seus campos configure a propriedade DefaultExpression para 0 no campo IDFITA e em seguida adicione à mesma propriedade do campo STATUS o conteúdo ‘D’ para finalizar as adaptações necessárias para o DMPrincipal. Isso faz com que esses valores sejam setados como padrão quando um novo registro for incluído.

Abra o DMRelatorio para criarmos o método que faz com que ele seja criado automaticamente em sua chamada, assim como visto na parte anterior de nosso artigo. Observe o código daListagem 1.

Listagem 1. Ajuste em DMRelatorio

...
var
  DM: TDMRelatorios;
 
function DMRelatiorios : TDMRelatorios;
 
implementation
//Adicione Forms ao uses
function DMRelatiorios : TDMRelatorios;
begin
  if not Assigned(DM) then
    DM := TDMRelatorios.Create(Application);
  Result := DM;
end;

Apenas relembrando o que já foi visto anteriormente, a variável DMRelatorios é renomeada para DM, o método Assigned verifica se a variável do formulário está nula e então se encarrega de criar automaticamente o Data Module. Desta forma temos uma chamada ao Data Module de maneira comum (ou seja, como se fosse uma variável global, o padrão do Delphi). Por enquanto deixaremos este Data Module assim, sem adicionar nada a ele.

Aqui nesta parte faremos algumas modificações no banco de dados de nosso projeto. Primeiramente vamos criar um novo domínio que consiste em um campo do tipo Data, porém, que não atribuirá valor inicial à data e que permitirá a atribuição de valores nulos. Execute o Script a seguir no gerenciador de bancos de dados de sua preferência:

CREATE DOMAIN D_DATA_NULL AS DATE;

Feito isso, adicionaremos um campo em nossa tabela LOCACAO para que futuramente possamos realizar a baixa dos empréstimos e controlar automaticamente os status das reservas e disponibilidade dos filmes. Novamente execute o Script a seguir:

ALTER TABLE LOCACAO ADD DATA_DEVOLUCAO D_DATA_NULL;

Tendo alterado nossa base dados, vamos implementar as futuras validações que serão feitas por nosso banco de dados de forma automática por meio de Triggers. Faremos duas Triggers para o cadastro de reservas, uma para a tabela de locação e uma para a tabela de itens de locação. Inicialmente execute os Scripts daListagem 2que são responsáveis pelo controle do Status dos filmes de acordo com suas respectivas ações.

Listagem 2. Triggers da tabela RESERVAS

CREATE TRIGGER RESERVAS_AD0 FOR RESERVAS
ACTIVE AFTER DELETE POSITION 0
AS
BEGIN
  UPDATE FITA SET FITA.STATUS = 'D'
  WHERE FITA.IDFITA = OLD.IDFITA;
END;
 
CREATE TRIGGER RESERVAS_BIU FOR RESERVAS
ACTIVE AFTER INSERT OR UPDATE POSITION 0
AS
BEGIN
  IF (NEW.STATUS = 'A') THEN
    UPDATE FITA SET FITA.STATUS = 'R'
    WHERE FITA.IDFITA = NEW.IDFITA;
  ELSE IF (NEW.STATUS = 'F') THEN
    UPDATE FITA SET FITA.STATUS = 'D'
    WHERE FITA.IDFITA = NEW.IDFITA;
END;

Observe que naListagem 2temos duas Triggers. A primeira chama-se RESERVAS_AD0 e como podemos notar ela é ativada toda vez que é excluída uma determinada reserva, fazendo com que o estado do filme reservado seja alterado para D (disponível). A segunda Trigger (RESERVAS_BIU) ocorre após inserir ou atualizar registros na tabela de RESERVAS. Nesta, temos a atualização realizada de acordo com o tipo de Status da reserva, caso esteja A (aberta) o filme é automaticamente colocado como R (reservado), sendo o Status da reserva F (fechado), então o filme é novamente posto como D (disponível).

Nota do DevMan

Triggers, ou gatilhos como também podem ser chamados, são recursos que permitem validação/ realização de ações em determinados momentos de ocorrência. Lembrando que Triggers são recursos que referem-se às tabelas e possuem eventos de manipulação. Existem três estados de Triggers sendo: Insert, Delete e Update e que podem ter seus estados combinados com as ações que podem variar entre Before (antes) e After (depois). Deste modo podemos obter combinações do tipo:

...

Quer ler esse conteúdo completo? Tenha acesso completo