o-bidi-font-style: normal">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,
"
);
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 TABLE EMPREGADO
ADD CONSTRAINT PK_EMPREGADO
PRIMARY KEY (CODEMPREGADO);
ALTER TABLE EMPRESA
ADD CONSTRAINT PK_EMPRESA
PRIMARY KEY (CODEMPRESA);
ALTER TABLE ESTADO
ADD CONSTRAINT PK_ESTADO
PRIMARY KEY (UF);
É importante lembrar que para um campo ser Primary Key ele não deve aceitar informação nula, claro. Ou seja, deve-se, no momento de criação do campo especificar-se Not Null para o campo.
Unique Key
Agora criaremos uma ...
