Artigo Clube Delphi 77 - Validações na prática

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (1)  (0)

Artigo da Revista Clube Delphi Edição 77.

Esse artigo faz parte da revista Clube Delphi Edição 77. Clique aqui para ler todos os artigos desta edição

imagem_pdf.jpg

Mão na Massa

Validações na prática

 

O intuito deste artigo é demonstrar as várias formas de validação de dados, desde o BD até a interface, seja ela Windows ou Web, e os casos onde elas podem ser utilizadas em nossas aplicações. Mais especificamente apresentaremos validação no banco de dados, utilizando o InterBase/Firebird, validações em aplicações Win32 e validações em ASP.NET. Ao final de cada item, discutiremos as vantagens e desvantagens de cada um, para que você possa analisar como implementar as validações levando em conta cada projeto.

 

Tipos de validação no Banco de Dados

Validações em bancos de dados podem ser criadas através de Constraints, que permitem definir regras de integridade do banco e, por que não, regras de negócios. O IB/FB possui, nativamente, os seguintes tipos de regras:

·         Not Null: cria uma regra simples informando que um campo é obrigatório, ou seja, não pode ser nulo. Essa regra é criada no momento de definição do campo;

·         Check Constraints: cria uma regra, também à nível de campo, para validar o conteúdo recebido. Cada campo pode ter uma única regra Check, mas essa restrição pode ser superada com a utilização de um domínio que também contenha um Check. Na base de dados que criaremos, utilizaremos os Checks para impedir que seja informado um código menor ou igual a zero e também que os campos UF sejam informados em maiúsculo;

·         Primary Keys: cria a chave primária da tabela e com isso também existirá uma regra que impedirá que registros diferentes possuam a mesma informação nesse campo;

·         Unique Key: cria regras para não aceitar valores duplicados em um determinado campo, mesmo que o campo não seja chave primária. Na base de dados de exemplo, utilizaremos o Unique para o campo CPF, impedindo assim que os empregados possuam o mesmo CPF;

·         Foreign Keys: cria regras de relações entre as tabelas impedindo que associações sejam feitas se os dados não constarem nas tabelas envolvidas.

 

Além dessas formas, que são as usadas com mais frequência, também podemos utilizar outros recursos do banco de dados para criar validações de preenchimento e validações envolvendo regras de negócio. Esses recursos são:

·         Trigger: recurso que existe na maioria dos SGBDs. É uma implementação desenvolvida no banco, e que está atrelada a um determinado evento de uma tabela, como por exemplo, ao evento Before Insert da tabela EMPRESA. Muito parecido com os eventos dos objetos no Delphi;

·         Stored Procedure: popularmente conhecido como Procedimento, e o nome já diz tudo, recebe parâmetros de entrada (opcionais), executa comandos e após o término, retorna os parâmetros de saída (opcionais) ou resultado;

·         Exception: uma mensagem cadastrada na base de dados e que será utilizada nas Triggers e nas Stored Procedures para retornar erros para as aplicações clientes.

 

Criando o banco de dados de exemplo

Para iniciar nosso exemplo prático, criaremos um banco de dados com alguns relacionamentos e campos interessantes para as técnicas de validação. Na Figura 1 temos o DER da nossa base, onde usamos o Firebird 1.5.

 

Figura 1. Diagrama ER da aplicação exemplo

 

A princípio parece estranho termos o ESTADO sem alguma relação, mesmo porque ela poderia estar relacionada com a tabela EMPRESA que também possui um campo UF. Mas justamente para exemplificar uma forma diferente de validação proposta neste artigo, vamos deixá-la assim, sem relacionamento.

Na Listagem 1 temos o script para criação das quatro tabelas. Abra o seu gerenciador preferido (uma sugestão é o IBExpert - www.ibexpert.com), crie um novo banco de dados e execute o script. Nesse script criamos apenas as regras de validação para campos não nulos, através da declaração Not Null.

 

Listagem 1. Script de criação das entidades

CREATE TABLE "DEPARTAMENTO"

(

  "CODDEPARTAMENTO"       INTEGER NOT NULL,

  "CODEMPRESA"              INTEGER NOT NULL,

  "RESPONSAVEL"     INTEGER,

  "DESCRICAO"         VARCHAR(60)

);

 

CREATE TABLE "EMPREGADO"

(

  "CODEMPREGADO"   INTEGER NOT NULL,

  "CODDEPARTAMENTO"       INTEGER NOT NULL,

  "CODEMPRESA"              INTEGER NOT NULL,

  "NOMECOMPLETO"  VARCHAR(100),

  "CPF"                   VARCHAR(11) NOT NULL,

  "TELEFONE"         VARCHAR(20)

);

 

CREATE TABLE "EMPRESA"

(

  "CODEMPRESA"              INTEGER NOT NULL,

  "RAZAOSOCIAL"     VARCHAR(20),

  "FANTASIA"         VARCHAR(100),

  "CNPJ"                VARCHAR(14) NOT NULL,

  "UF"                    CHAR(2)

);

 

CREATE TABLE "ESTADO"

(

  "UF"          CHAR(2) NOT NULL,

  "NOME"       VARCHAR(20) NOT NULL

);

 

Primary Keys

Depois de criada as tabelas, criaremos as Constraints iniciando pelas Primary Keys, através do script da Listagem 2. É comum criar as Primary Keys junto com a tabela, informando o comando “Primary Key” ao lado do campo que se deseja como chave. Mas isso não é bom, pois o banco criará um nome genérico para essa Constraint, e com isso, dificultando um tratamento na aplicação cliente diferenciado para cada erro que ocorre.

 

Listagem 2. Script para criação das Primary keys

ALTER TABLE DEPARTAMENTO

ADD CONSTRAINT PK_DEPARTAMENTO

PRIMARY KEY (CODDEPARTAMENTO, CODEMPRESA);

 

ALTER "

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?