sexta-feira, 12 de fevereiro de 2010

Criando uma Trigger

Bom vo fazer um exemplo de como criar um gatilho em uma tabela, o usuário deve possuir o privilégio TRIGGER na tabela. 

Na versão atual, gatilhos de declaração (STATEMENT triggers) não estão implementados. 

Consulte o comando DROP TRIGGER para obter informações sobre como remover gatilhos. 
Exemplos

Verificar se o código do distribuidor existe na tabela de distribuidores antes de inserir ou atualizar uma linha da tabela filmes: 


CREATE TRIGGER se_dist_existe
  BEFORE INSERT OR UPDATE ON filmes FOR EACH ROW
  EXECUTE PROCEDURE verificar_chave_primaria ('did', 'distribuidores', 'did');

Antes de remover um distribuidor, ou de atualizar o seu código, remover todas as referências para a tabela filmes: 


CREATE TRIGGER se_filme_existe
  BEFORE DELETE OR UPDATE ON distribuidores FOR EACH ROW
  EXECUTE PROCEDURE verificar_chave_primaria (1, 'CASCADE', 'did', 'filmes', 'did');

O segundo exemplo também pode ser implementado usando uma chave estrangeira, como em:
 
CREATE TABLE distribuidores (
  did DECIMAL(3),
  nome VARCHAR(40),
  CONSTRAINT se_filme_existe
  FOREIGN KEY(did) REFERENCES filmes
  ON UPDATE CASCADE ON DELETE CASCADE  
);

Está situação eu fiz no PostgreSQL com (SQL99).
Bom embreve farei mais posts acompanhem.

O que é Trigger?


Bom aqui este tópico vou falar sobre as
Triggers é um (Gatilho) as melhores coisas que existem em um banco de dados para o programador elas dão uma dorzinha de cabeça mas que... facilitam muito a vida do desenvolvedor do software, mais vamos para entendimento melhor, temos que saber para que serve uma Trigger e qual a sua função dentro do banco. Então Let's GO!!!.

Uma descrição básica e rápida ela é o comando no banco CREATE TRIGGER introduz um novo gatilho no banco de dados atual. O gatilho fica associado com a relação tabela e executa a função especificada função. 

O
gatilho pode ser especificado para disparar antes (BEFORE) da operação ser realizada na tupla (antes das restrições serem verificadas e o INSERT, UPDATE ou DELETE serem efetuados) ou após (AFTER) a operação ser realizada (ou seja, após as restrições serem verificadas e o INSERT, UPDATE ou DELETE ter completado). Se o gatilho disparar antes do evento, o gatilho pode evitar a operação para a tupla atual, ou modificar a tupla sendo inserida (para as operações de INSERT e UPDATE somente). Se o gatilho disparar após o evento todas as modificações, incluindo a última inserção, atualização ou exclusão, são "visíveis" para o gatilho

O
SELECT não modifica nenhuma linha, portanto não é possível criar gatilhos para SELECT. Regras e visões são mais apropriadas para este caso. 

Sintaxe ficariam assim:

Name (CREATE TRIGGER -- define um novo gatilho);
Synopsis (BEFORE | AFTER);
Entradas (nome, tabela, evento, função);
Saídas (Mensagem retornada se o gatilho for criado com sucesso);

Bom  mais para frente irei postar várias Tiggers para vários tipos de Linguagens de Banco de Dados como exemplo Postgre, Firebird, Oracle entre outros...

1º O que são Triggers?

Triggers são códigos de
PL/SQL armazenados dentro do banco de dados, onde podemos definir um "bloco" PL/SQL para que seja executado automaticamente pelo banco, assim toda vez que uma instrução SQL ( evento DML ) for aplicada para uma tabela específica ele irá executar um determinado evento automaticamente.

2º Para que serve uma Trigger?

Bom volto a falar ela esta dentro do
Banco de Dados e tem uma função muito boa a Trigger dentro do seu banco será de uma utilidade enorme, imaginem que temos um banco de dados com 1.500,000 de registros, onde os funcionários da empresa ganham por hora, e você tem que atualizar o banco de horas de cada funcionário por dia, alguns comandos poderia fazer isso por nós, mas seria um pouco complicado e desgastante, então, por este motivo, criamos nossas Triggers, onde definimos o que deve ser mudado na tabela num único arquivo e depois acionamos um único comando DML (Update) para ele, assim, ele irá atualizar os 1.500,000 de registros de uma única só vez.

3º Implementação da Trigger dentro do banco?

Devemos tomar algumas precauções sobre a implementação das
Triggers dentro do banco, fique atento para estes tópicos :
  • Use triggers para garantir a execução de comandos para uma tabela específica;
  • Não fique criando triggers que duplique regras já definidas em CONSTRAINTS do banco;
  • O Oracle recomenda que limitamos os nossos códigos no máximo em 60 linhas,
  • Caso você tenha que criar algo mais complexo crie stored procedure, será mais utíl;
  • ATENÇÃO cuidado ao criar as Triggers que disparem sob uma instrução UPDATE na sua Tabela, não pode alterar a tabela porque isso iria disparar a Triggers mais de N vezes no sistema, e a memória do equipamento não iria agüentar ocasionandos bugs de memória e resultados errôneos.

4º Pontos fundamentais das Triggers?

Segurança e Integridade

Podemos utilizar as Triggers para garantir uma segurança maior no nosso banco, ela tem como tarefa restringir o acesso as tabelas e controlar as atualizações.

Auditoria

Como disse anteriormente, as Triggers são executadas automaticamente, assim, podemos utilizá-las para fazer auditoria sobre acesso ao banco de dados.

Replicação de Dados

São excelentes para criar uma política de replicação síncrona de uma tabela para outra.

Integridade

Apartir das Triggers podemos criar controles mais complexos para os relacionamento das tabelas.

Controle de dados

Caso uma tabela tenha dados, cujo valor depende de outras tabelas, as Triggers pode atualizar automaticamente a coluna com os valores derivados.

Próximos posts vou comentar sobre a Preparação das Triggers passo-a-passo e um resumo sobre os comandos, assim vocês poderam na ultima coluna, estar dominando a criação e a utilização deste mecanismo.

Tipos de Constraints


Bom agora vou falar sobre os tipos de Constraints;

  • Constraint DEFAULT
  • Constraint CHECK
  • Constraint PRIMARY KEY
  • Constraint UNIQUE
  • Constraint FOREIGN KEY

Basicamente falando, integridade de dados é a maneira de dizer que os dados que estão na sua base são confiáveis. Existem dois tipos de implementar integridade de dados nos Bancos de Dados: Declarativa e Procedural.

Declarativa diz respeito ao uso das constraints e das rules.

Procedural diz respeito ao uso de Stored Procedures e Triggers. (recomendo que leia este outro tópico sobre Triggers...)

Observações: 

- É possível criar uma constraint após a criação da tabela.
- Uma Constraint pode ser definida a nível de coluna ou a nível de tabela.
- Constraints são armazenadas no Dicionário de Dados e podem ser facilmente recuperadas se possuírem nomes razoáveis.

Constraint DEFAULT

Bom Constraint Defaukt ela serve para indicar um valor padrão para um campo, quando o mesmo não for especificado. Exemplo: se a tabela TESTE possui dois campos, COD e NOME, e para o campo NOME existe uma constraint DEFAULT criada, ao inserirmos dados nesta tabela podemos somente fornecer o conteúdo do campo COD, pois o conteúdo do campo NOME será automaticamente preenchido com o valor definido na constraint DEFAULT

Esta constraint deve ser utilizada para manter integridade de domínio. Também podemos utilizar esta constraint como um objeto independente, assim como as rules. Não podemos criar constraints em campos com o tipo de dados rowversion e campos que possuem uma propriedade IDENTITY definida.

Constraint CHECK

Esta constraint nos permite criar uma regra para o preenchimento de um certo campo em uma tabela. Nesta regra podemos utilizar valores de outros campos da mesma tabela para fazer a validação dos dados. Ou melhor um método para validar a integridade de todos os dados que entram em sua base e Check Constraints é ótimo para garantir todos  os dados que entram em seus sistemas através de novas soluções ou interfaces.

As Check Constraints também melhoram o aproveitamento de seu sistema. O gerenciador de banco de dados verifica o cumprimento das Check Constraints no nível mais baixo do sistema operacional e por isso a verificação destas regras tem uma carga de trabalho menor do que teria através de aplicativos.

Esta constraint deve ser utilizada para manter integridade de domínio e integridade referencial.

Esta constraint pode ser desabilitada, para caso de uma grande inserção de dados na tabela.

Constraint PRIMARY KEY

Esta constraint serve para definirmos um ou mais campos como chaves primárias. Uma chave primária é o atributo de um ou mais campos que identifica unicamente um registro em uma tabela. Podemos criar somente uma constraint PRIMARY KEY por tabela e não podemos colocar o valor NULL nos campos que compõem a chave primária.

Esta constraint deve ser utilizada para manter integridade de entidade. Quando esta constraint é criada na tabela, um índice também é automaticamente criado sobre as colunas que fazem parte da chave primária. Este índice não pode ser apagado diretamente, devemos apagar a constraint PRIMARY KEY primeiro.

Observações:

- A Constraint Primary Key é uma combinação das constraints Unique e Not Null
- Um índice único é automaticamente criado.

Constraint UNIQUE

Esta constraint faz a validação de valores únicos em uma coluna de uma tabela. Se um campo estiver definido com a constraint UNIQUE nenhum valor repetido poderá ser fornecido para esta campo. Diferente da PRIMARY KEY, podemos colocar várias constraints UNIQUE por tabela mas para cada campo que possue uma constraint UNIQUE somente podemos inserir o valor NULL uma vez.

Esta constraint deve ser utilizada para manter integridade de entidade. Quando esta constraint é criada na tabela, um índice também é automaticamente criado sobre a coluna sobre a qual a constraint está definida. Este índice não pode ser apagado diretamente, devemos apagar a constraint UNIQUE primeiro.

Observações:

- Designa uma coluna ou uma combinação de colunas de tal forma que duas linhas não possam ter o mesmo valor.
- Valores nulos são aceitos.
- Automaticamente é criado um índice único para a(s) coluna(s) especificada(s).

Constraint FOREIGN KEY

Esta constraint é utilizada para implementar o conceito de chave estrangeira e serve para indicar que o conteúdo de um campo deve se referenciar a um outro campo que possua ou uma chave primária ou uma constraint UNIQUE

Quando o campo que está sendo referenciado residir na mesma tabela, não precisamos uitilizar a palavra-chave FOREIGN KEY, podendo somente utilizar REFERENCES. Esta constraint também pode ser desabilitada, para o caso de uma grande inserção de dados na tabela. 

Esta constraint deve ser utilizada para manter integridade refencial e podemos ainda programar eventos em cascata utilizando as cláusulas ON DELETE e ON UPDADE.

Observações:

- Estabelece um relacionamento com a chave primária ou única da mesma ou de outra tabela.
- Deve referenciar um valor existente na tabela pai ou ser nulo.
- Chaves estrangeiras são baseadas em dados e são puramente lógicas, isto é, não são ponteiros físicos.
- Uma chave estrangeira, parte de uma chave primária, não pode ser nula pois uma chave primária não pode ser nula, nem parcialmente nula. 
- Havendo a cláusula ON DELETE CASCADE, uma deleção na tabela pai causa a deleção das linhas relacionadas na tabela filho.

Bom é isso ai espero que tenha respondido muitas perguntas e o porque haha... e muitos programadores desconhece desse assunto mas entendem muito sem saber o que é esses simples recursos que faz sem saber o nome que é Constraints isso nos Bancos de Dados.

É isso em breve muitos exemplos...

O que é uma Constraints?

Olá! vamos falar hoje sobre "O que é uma Constraints?"
Bom é um assunto bem interessante, as CONSTRAINTS, que nada mais são restrições que você estabelece para uma coluna no banco de dados, que nada mais é de um método para validar a integridade de todos os dados que entram em sua base.

Bom antes de você começar a ler este tópico recomendo você ler antes sobre a Integridade no Banco de Dados então depois de ler... volte aqui haha.

Constraints bom podemos ter os seguintes tipos:

  • Primary Key (PK) = Está restrição cria um índice único para um conjunto de colunas ou uma coluna para Chave Primaria.
  • Unique = Está Contraint determina que uma coluna não poderá ter 2 linhas com o mesmo valor.
  • Foreign Key (FK ou Chave Estrangeira) = Determina uma coluna ou um conjunto de colunas que possuem valores em outras tabelas, referente a uma referência ou um relacionamento.
  • Check = Especifica a condição que a coluna precisa para salvar o registro.
  • Not Null = Determina que a coluna tem preenchimento obrigatório.

Bom agora deu para você entender melhor sobre o que estamos falando né haha, as opções de restrições (Constraints), temos que aplicar isso na prática, e para isso vou utilizar um exemplo bem simples. Vamos imaginar que você tem que criar uma tabela para receber informações de consultas de empregados na sua empresa, onde no formulario de cadastro existe os campos Código, Nome, Departamento, Sexo, Idade e E-mail. Então nosso código deverá ter os seguintes campos todas com suas restrições para inclusão.

SQL 1º CREATE TABLE EMPREGADOS (
2
º COD NUMBER(6) NOT NULL CONSTRAINT CODEMP_PK PRIMARY KEY,
3
º NOME VARCHAR2(20) NOT NULL,
4
º DEPARTAMENTO VARCHAR2(40) NOT NULL CONSTRAINT DEPTO_FK REFERENCES DEPTO
5
º INITIALLY DEFERRED, 
6
º SEXO CHAR(1) NOT NULL CONSTRAINT CHECK_SEXO CHECK (SEXO IN ('F','M')),
7
º IDADE NUMBER(2) CONSTRAINT CHECK_IDADE CHECK (IDADE > 18),
8
º EMAIL VARCHAR2(40) NOT NULL UNIQUE
9
º )
10
º TABLESPACE USERS;

Agora vamos analisar o código linha por linha afim de entendermos o que está acontecendo.

1º Linha: Está sendo criada a tabela chamada
EMPREGADOS

2º Linha: Vamos criar uma coluna COD onde tem preenchimento obrigatório e está relacionada com outra tabela chamada CODEMP (Código Empregado) como chave primaria.

3º Linha: Criamos uma coluna NOME que o preenchimento é obrigatório.

4º Linha: Criamos uma coluna DEPARTAMENTO onde o preenchimento é obrigatório e como chave estrangeira para a tabela DEPTO e a cláusula DEFERRED significa que a transição poderá ser adiada até o fim da execução do serviço do banco.

6º Linha: Criação da coluna SEXO onde tem preenchimento obrigatório e só será aceito os caracteres F (Feminino) e M (Masculino).

7º Linha: Criamos uma coluna IDADE onde a idade do empregado da empresa tem que ser superior a 18 anos.

8º Linha: Criação da coluna EMAIL onde o preenchimento é obrigatório e não permite que os valores da coluna seja repetido.

10º Linha: Estamos determinando a área de reserva para aquela tabela.

PRONTO! é isso agora você já deve saber utilizar as restrições para suas tabelas e deixar elas mais utilizáveis no sistema.

Até a próxima.

quinta-feira, 11 de fevereiro de 2010

Integridade no Banco de Dados


Olá Pessoal, beleza... estou devolta... 

Bom comecei este artigo pensando em falar sobre Constraints e Triggers, mas antes, deveria falar sobre o que é uma Integridade no Banco de Dados, então, resolvi preparar este artigo que descreve os tipos e exemplificar cada um deles. 

Vamos lá! Let's GO!!!

Integridade é fundamental! 

Quando vamos projetar um Banco de Dados, imaginamos as possíveis formas para que nossa aplicação grave os dados corretamente no Banco de Dados, mas as vezes, esquecemos de definir, a nível de banco, quais as validações que devem ser feitas para evitar inconsistências nos dados e que, futuramente, se tornariam dores de cabeça. 

Em um Banco de Dados, possuímos 3 formas de Integridade

- Integridade de Domínio 
- Integridade de Entidade 
- Integridade Referencial 


Integridade de Domínio 

Neste tipo de integridade, as validações ocorrem em cada campo de nossa tabela (ou entidade), como por exemplo se um campo deve aceitar valores Null ou apenas uma faixa de valores, por exemplo: 

Temos um campo Sexo, que só deve aceitar valores do tipo M ou F e, independente de nossa aplicação, não deverá aceitar outros valores. Com integridade de domínio, podemos fazer isto facilmente. 

Integridade de Entidade 

Já na integridade de entidade, temos validações um nível acima, onde definimos quais campos de nossa tabela são chaves primárias (PK) ou únicas (UK). 

Um exemplo de chave única é o campo de CPF que nunca pode se repetir. 

OBS: Geralmente chaves únicas são chamadas de chaves candidatas, pois são candidatas a chave primária, mas não são uma. 

Integridade referencial 

E por último, mas não menos importante, vemos a Integridade Referencial, onde criamos nossas referências a campos do tipo PK ou UK de outras tabelas, as famosas chaves estrangeiras FK. Lembre-se que eu não posso criar uma referência (relacionamento) de uma coluna se esta não for uma chave primária de outra tabela. 

Este tipo de integridade é fundamental para verificar se um dado será inserido de forma correta e, como é uma chave estrangeira, se este dado realmente existe.

Vamos tirar por exemplo uma tabela chamada PEDIDO e uma CLIENTE. Eu só posso adicionar um registro de PEDIDO se existir um CLIENTE relacionado a ele, e é assim que as verificações acontecem, no momento da inclusão ou alteração, o SGBD verifica se o registro existe e caso não, retorna um erro

Bom, vimos neste artigo um pouco sobre integridade no banco de dados, no próximo irei falar sobre como criar Constraints e Triggers possamos pôr em prática o que vimos hoje. 

Até a próxima.

 Copyright © 2008-2010 All Right Reserved - Todos os Direitos Reservados Elder Stroparo