sábado, 5 de outubro de 2013
sábado, 31 de agosto de 2013
Triggers PostgreSQL
Olá, vamos falar hoje sobre Triggers ou Gatilhos.
Irei realizar esse post de acordo com o banco de dados que pertence a este elefante abaixo, espero que vocês saibam de qual banco se trata!
Uma funções de gatilho possui um recurso muito útil quando estamos falando de bancos de dados pois pouco utilizam as Triggers devido a complexidade.
Bom, existem inúmeras formas para se realizar e implementar funções de gatilho. Algumas de uma forma um
pouco diferente uns dos outros.
Vamos criar um seguinte exemplo e vamos identificar como funciona os gatilhos no SGBD PostgreSQL.
Sempre uma função de gatilho pode ser criada para executar antes (BEFORE) ou
após (AFTER) as consultas INSERT, UPDATE OU DELETE, uma vez para cada
registro (linha) modificado ou por instrução SQL. Logo que ocorre um
desses eventos do gatilho a função do gatilho é disparada
automaticamente para tratar o evento.
No que diz respeito a declaração de um gatilho, para o banco
PostgreSQL, sempre devemos atrelar uma FUNÇÃO ao gatilho, enquanto nos
demais bancos de dados, o algoritmo a ser executado fica no corpo da
declaração do gatilho.
Sintaxe de um TRIGGER em PostgreSQL:
CREATE TRIGGER nome { BEFORE | AFTER } { evento [ OR ... ]
ON tabela [ FOR [ EACH ] { ROW | STATEMENT } ]
EXECUTE PROCEDURE
nome_da_funcao ()
|
Sempre devemos declarar quando a trigger deve ser disparada: antes (BEFORE) ou após (AFTER) um evento (INSERT, UPDATE, DELETE ou SELECT) em determinada tabela, para cada linha (ROW) ou instrução (STATEMENT), e qual função (PROCEDURE) deve ser executada.
Como ficaria no banco de dados:
A tabela de usuários
id
|
nm_login
|
ds_senha
|
fg_bloqueado
|
nu_tentativa_login
|
1
|
hallan
|
hallan2011
|
false
|
0
|
2
|
joao
|
123456
|
false
|
0
|
3
|
maria
|
abcd1234
|
false
|
2
|
Vamos usar sempre que um usuário for excluído, guardar as suas informações em uma tabela reserva.
SQL para
a criação da tabela de backup:
CREATE TABLE bkp_usuario (
id integer NOT NULL,
nm_login character varying,
ds_senha character varying,
fg_bloqueado boolean,
nu_tentativa_login
integer,
data_exclusao
timestamp,
CONSTRAINT pk_bkp_usuario
PRIMARY KEY (id)
);
|
Temos, então,
a seguinte tabela, chamada bkp_usuario:
id
|
nm_login
|
ds_senha
|
fg_bloqueado
|
nu_tentativa_login
|
data_exclusao
|
O próximo
passo então é criar a função que será disparada toda vez que um usuário for
excluído. Apesar de ser um exemplo simples, serve para o entendimento de um
gatilho.
Podemos
criar, então, a função da seguinte forma:
CREATE OR REPLACE FUNCTION backup_usuario()
RETURNS TRIGGER AS
$$
BEGIN
INSERT INTO bkp_usuario
(id, nm_login, ds_senha, fg_bloqueado,
nu_tentativa_login, data_exclusao)
VALUES
(OLD.id, OLD.nm_login, OLD.ds_senha,
OLD.fg_bloqueado, OLD.nu_tentativa_login, NOW()
);
RETURN NEW;
END;
$$ LANGUAGE plpgsql;
|
A palavra
reservada OLD representa o registro antigo (para o caso de um update ou
um delete). No corpo da função, estamos apenas lendo os dados do registro
antigo e efetuando um insert na tabela de backup. A função NOW() retorna
a data e hora atual do sistema.
Com a
função pronta, devemos criar o gatilho que fará ela ser disparada toda vez que
ocorrer um comando de DELETE na
tabela de usuários.
Devemos
criar o gatilho da seguinte forma:
CREATE TRIGGER trigger_usuario AFTER DELETE
ON usuario
FOR EACH ROW
EXECUTE PROCEDURE backup_usuario();
|
Nosso gatilho será disparado sempre depois de um comando de exclusão (AFTER DELETE) na tabela de usuário, e para cada linha (FOR EACH ROW) executa a função (EXECUTE PROCEDURE) backup_usuario.
Desta
forma, se efetuarmos a seguinte instrução:
Delete from usuario where id=2;
A tabela de usuário ficará da seguinte forma:
Delete from usuario where id=2;
A tabela de usuário ficará da seguinte forma:
id
|
nm_login
|
ds_senha
|
fg_bloqueado
|
nu_tentativa_login
|
1
|
hallan
|
hallan2011
|
false
|
0
|
3
|
maria
|
abcd1234
|
false
|
2
|
E a
tabela bkp_usuario ficará da seguinte forma:
id
|
nm_login
|
ds_senha
|
fg_bloqueado
|
nu_tentativa_login
|
data_exclusao
|
2
|
joao
|
123456
|
false
|
0
|
2011-11-11
21:01:49.906
|
Bom acho
que deu para entender quando é executado este gatilho somente quando ocorre a
exclusão de registro na tabela de usuários. E logo em seguida ele acaba realizando
automaticamente o insert na outra tabela backup usuários onde com os registros
e a data atuação da execução do gatilho.
Abraço!
Abraço!
quinta-feira, 29 de agosto de 2013
O que é Instâncias de Banco de Dados?
Instância nada mais é onde existem os principais componentes de um típico
servidor, onde pode ser uma ou mais CPU’s alocando espaço em discos e memória.
Existe alguns casos uma instância sem um banco de dados. Você pode criar uma
instância sem problema algum porém, ela não irá realizar acesso a qualquer
arquivo de banco de dados, pois ela não está associada com um banco. Ela pode
existir sem problema algum mas sem um banco de dados ela seria totalmente inútil.
A importância de uma Instância em um banco de dados serve para poder acessar o banco sem restrições alguma. Você cria sua instância, onde o objetivo é montar ela especificamente para um banco de dados para melhor desempenho.
Você pode configurar múltiplas Instâncias para acessar o mesmo grupo de arquivos
ou
banco de dados. Muitas instâncias em vários servidores acessando um banco de dados central permitem escalabilidade e alta disponibilidade de desempenho.
banco de dados. Muitas instâncias em vários servidores acessando um banco de dados central permitem escalabilidade e alta disponibilidade de desempenho.
Bom nada mais do que é, ou seja uma instância como falei e volto a falar ela
serve para realizar uma combinação da memória e dos processos que são parte de
uma instalação em funcionamento e ou a instância é usada para a gerência e
acesso ao banco de dados.
Somente informando quando uma instância é iniciada,
o banco aloca uma área de memória chamada de SGA (Área do Sistema Global) e
inicia um ou mais processos em background. SGA é uma área de memória usada para armazenar informações do banco, que são compartilhadas pelos processos do
banco.
Bom é isso ai espero que a explicação seja útil a
todos pois sei que poucos entendem uma instância por mais complexa que seja.
terça-feira, 27 de agosto de 2013
Dump
O que é um Dump?
Dump é um programa para sistemas operacionais Unix usado para fazer backups de arquivos de sistema. Este é um dos programas do gênero mais antigos, sendo considerado um dos melhores.
Melhor explicando um Dump nada mais é que um backup.
Vamos entender aprofundadamente utilizando um dump em banco de dados.
Em MySQL você pode usar o seguinte comando (dentro do terminal mysql).
ficaria assim:
Database: meubanco
Host: localhost
Username: nomeusuario
Password: senha
Host: localhost
Username: nomeusuario
Password: senha
$mysql -h localhost -u nomeusuario -senha meubanco < backup_meubanco.sql
Em Oracle você pode usar o seguinte comando (dentro do terminal Oracle).
ficaria assim:
Username: user1
Password: senha_do_user1
exp user1/senha_do_user1 file=arquivo_dump.dmp log=log_dump.log
Outro exemplo um pouco diferente mas também é a realização de um Dump.
Vamos pegar um exemplo o SQL Server 2000.
Requisito: É necessário possuir o SQL Server 2000, com a ferramente
Enterprise Manager, instalado no ambiente onde o procedimento será
executado.
1° - Configurar a conexão com a sua base de dados na Plug In no seu Enterprise Manager, em ambiente de desenvolvimento por exemplo;
2° - Clicando com o botão direito do mouse sobre a sua base já configurada clicar em Tasks > Generate SQL Script para copiar todos os Create Tables da sua base remota;
3° - Utilizar os Create Tables em seu servidor SQL Server local, ambiente de desenvolvimento, para clonar a base de dados remota;
4° - Clicando novamente com o botão direito do mouse sobre a base clonada selecionar em Tasks > Import Data, e informar os dados de origem da base remota;
5° - Clicando novamente com o botão direito do mouse sobre a base clonada selecionar Tasks > Backup.
Bom pessoal acho que é isso uma breve visão como realizar um dump.
Citei somente em MySQL, Oracle e SQL Server 2000.
Outro post irei fazer especificando mais a cada versão de banco de dados.
domingo, 14 de julho de 2013
Arquiteturas dos Bancos de Dados NoSQL
Bom a Arquiteturas dos Bancos de Dados NoSQL é constituida de várias maneiras.
Para
explicar melhor a arquitetura dos bancos nosql será comparado com os bancos
relacionais, é importante salientar a diferença entre os bancos e o seu uso,
uma má escolha no padrão de persistência pode acarretar em mais horas do que a planejada, além no não
atendimento do seu requisito. As aplicações em quase sua maioria é atendida
pelo banco relacional seria semelhante a um carro utilitário, que serve para
várias pistas, quando se tem a
necessidade de uma maior velocidade e desempenho uma boa opção seria os bancos
nosql que seria comparado a um carro de corrida, no entanto eles atendem a
casos específicos será improdutivo
colocar um carro de formula 1 em uma
pista de rally.
SQL
Modelo de persistência: Os atuais bancos de dados tentam explorar ao máximo o modelo A.C.I.D.
cujos os princípios são:
Atomicidade: Trata o trabalho como parte indivisível, ou seja ou tudo
feito ou nada feito
Consistência: o processo deve
deixar o banco integro ou não será executado
Isolamento: tratar cada operação como individual
Durabilidade: os processos em caso de sucesso serão permanente
Armazenamento: Em
função disso ganham certa limitação nas
transações com gigantescos volumes de dados, cargas de trabalhos normais de
operações modernas. Essas informações em sua grande maioria se concentram no disco rígido, gastando alto
poder computacional de I/O.
Acesso da informação: Os bancos relacionais possuem estruturas bem
semelhantes e possuem alguns comandos em comuns que é o SQL ANSI, para se
conectar e acessar as informações do banco de dados usa-se um driver, Em java,
por exemplo, trocar de banco de dados na maioria dos casos resultam em impactos
zero para a aplicação, já que basta apenas modificar o driver de conexão de um
banco de dados para outro. Nesse tipo de bancos as informações podem ser
recuperada de N maneiras a mineração de dados com esses tipos de bancos é bastante
fácil.
Escalabilidade: Esse
modelo trabalha melhor com a escalabilidade vertical que consiste em adicionar
mais poder de processamento, memória ou disco em uma máquina,
NOSQL
Modelo de persistência: Com a
necessidade de se ganhar mais performance principalmente no trabalho com
grandes blocos de dados foi criado os bancos que usam o princípio do BASE. A ideia desse modelo é estar dando prioridade há
uma alta disponibilidade e escalabilidade além de um alto grau de performance.
Armazenamento: com o objetivo da disponibilidade boa parte
desse modelo usam memória principal e durante um período de tempo são jogados
no disco rígido, alguns modelos trabalham 100% com memória principal.
Acesso da informação: No nosql, não existe semelhança nenhum entre os
bancos de dados, atualmente pode-se dividir os grupos de bancos de dados em
quatro que são: grande tabela, chave-valor, grafos, documentos ( serão
explicados melhor no decorrer do artigo) cada um com características
específicas e objetivos específicos. Para se conectar ou acessar um desses
bancos de dados é usado uma API, então mudanças de bancos de dados causará
bastante impacto para a aplicação, mesmo que os bancos de dados sejam do mesmo
tipo, por exemplo,de Big Table da Google para cassandra apesar de
ambos possuírem o mesmo modelo de banco de dados que é o de grande
tabela a mudança de código mesmo que apenas em uma camada (DAO) será
relativamente alta, mas a tendência é que daqui a alguns anos cada um dos tipos
de banco de dados existem uma implementação de referência semelhante ao JPA.
Outra informação importante é que você boa parte dos bancos você recupera a
informação apenas a partir de uma chave.
Escalabilidade: Existem modelos que trabalham tanto na forma
vertical tanto na forma horizontal que é a
capacidade de adicionar novas máquinas para, de forma distribuída, aumentar os
recursos de processamento, memória e disco.
História do NoSQL
Bom vamos falar sobre a história do NoSQL.
NoSQL nada mais é do que um termo genérico para uma classe definida de banco de dados não-relacionais que rompe uma longa história de banco de dados relacionais com propriedades ACID. Outros termos equivalentes para esta categoria de bancos é NF², N1NF (non first normal form), nested relational, dimensional, multivalue, free-form, schemaless, document database e MRNN (Modelo Relacional Não Normalizado).
Como todos sabem que os bancos de dados que estão sob estes rótulos não podem exigir
esquemas de tabela fixa e, geralmente, não suportam instruções e
operações de junção SQL.
Onde existem as tendências em arquiteturas de computadores, como a computação na nuvem e a necessidade crescente de prover serviços escaláveis, estão
pressionando bancos de dados numa direção onde eles necessitam oferecer escalabilidade horizontal.
Bancos de dados NoSQL armazenam os dados com técnicas que visam atender
a esse requisito.
Há alguns exemplos proeminentes de softwares de
código fechado que atendem estes requisitos, sendo alguns deles Google's BigTable e Amazon's DynamoDB. E alguns exemplos de sofware open-source como Apache Cassandra (originalmente desenvolvido para o Facebook), Apache HBase, LinkedIn's e vários outros.
A História da criação do termo NoSQL foi primeiramente utilizado em 1998 como o nome de um banco de dados relacional
de código aberto SQL. Seu
autor, Carlo Strozzi, alega que o movimento NoSQL "é completamente
distinto do modelo relacional e portanto deveria ser mais apropriadamente
chamado "NoREL" ou algo que produzisse o mesmo efeito"
que não possuía uma interface.
O termo NoSQL foi re-introduzido no início de 2009 por um funcionário do Rackspace, Eric Evans, quando Johan Oskarsson da Last.fm queria organizar um evento para discutir bancos de dados open source distribuídos. O nome — uma tentativa de descrever o surgimento de um número crescente de banco de dados não relacionais, que não tinham a preocupação de fornecer garantias ACID — faz referência ao esquema de atribuição de nomes dos bancos de dados relacionais mais populares do mercado: MySQL, MS SQL, PostgreSQL etc.
Os Banco de Dados NOSQL foram criados,
principalmente, para resolver problemas com aplicações web que precisam operar
com gigantescas cargas de dados além de poder escalar com grande facilidade.
É importante entender que o intuito não é eliminar bancos de dados
relacionais, mas oferecer uma alternativa. Pois, durante muito tempo o
modelo relacional foi usado como "bala de prata" para todos os problemas
de persistência.
Assinar:
Postagens (Atom)