Memória, Blocos, Cache? ...

Estruturas de Armazenamento

Estruturas de armazenamento são os meios pelo quais os bancos de dados são armazenados em massa por um período prolongado em algum tipo de mídia, seja ela disco rígido, cd-rom, fita magnética, memória principal, etc. Os dados precisam ser recuperados constantemente pelos usuários, para isso estas estruturas foram criadas, utilizando-se de várias técnicas para serem acessados e armazenados com segurança.

a) Hierarquia de memórias e Dispositivos de Armazenamento
No nível de armazenamento primário, a memória cache é usada pela CPU para acelerar a execução do programa. No próximo nível de armazenamento primário, está a memória DRAM, responsável por fornecer a principal área de trabalho para a CPU. No nível de armazenamento secundário, a hierarquia compreende os discos magnéticos (Hard Disk e CD-Rom) e finalmente as fitas, a mais barata nas extremidades. Estas mídias armazenam os dados em massa.

b) Armazenamento de Banco de Dados

Os bancos de dados armazenam grandes quantidades de informações por longos períodos. Estas informações, geralmente são armazenadas permanentemente em armazenamento secundário de discos magnéticos pelas seguintes razões.

a. Os bancos de dados são muito grandes e não cabem na memória principal.
b. As circunstâncias que causam a perda permanente de dados aparecem com menos freqüências nas mídias de armazenamento secundário. (o armazenamento principal é mantido somente na execução do programa).
c. O custo de armazenamento secundário é uma ordem de magnitude menor para discos que para armazenamento primário.
As técnicas que são utilizadas para armazenas grandes quantidades de dados em um disco são de extrema importância para os DBA’s, pois através delas serão escolhidas a melhor técnica de organização dos dados para se adaptar aos requisitos de uma determinada aplicação.
Os discos são divididos em trilhas de dezenas de Kbytes até 150 kbytes que armazenam grandes quantidades de informações, que, por sua vez, é dividida em blocos ou em setores menores.

c) Buffering de Blocos

Quando é necessário buscar estas informações no disco, os blocos são transferidos para a emória principal, todos endereços de blocos são conhecidos e diversos buffer’s são armazenados na memória principal para auxiliar a transferência.
Enquanto um buffer estiver sendo utilizado na memória principal, A CPU pode processar os dados contidos em outro buffer paralelamente. Isso somente é possível porque existe um rocessador de entrada e saída independente, que uma vez inicializado, também pode transferir os blocos de maneira independente.

Devido à importância e limitações de tempo, neste artigo somente serão citados estas estruturas de armazenamento. Outras estruturas de armazenamento como Registros e Tipos de Registros; Arquivos, Registros de Tamanhos fixos e Tamanhos variável; Alocação de blocos de Arquivo em Disco, Acesso paralelo em Disco Usando a Tecnologia Raid, etc, poderão ser encontradas no Livro ELMASRI, Ramez e NAVATHE, Shamkant B. Sistemas de Banco de Dados.

3.3. Índices

Os índices são estruturas que visam melhorar a performance de acesso aos dados em um banco de dados. Os índices, assim como as tabelas, podem ser implementados através de várias estruturas de armazenamento, e sua forma de utilização não é uma fórmula exata que fornece bons resultados automaticamente. É preciso saber quando e como utilizá-los.

Vamos então analisar como os índices devem ser utilizados e suas características em alguns SGBD bastante utilizados.
Embora os comandos de manipulação de dados sejam razoavelmente padronizados entre os produtos baseados em SQL, as características que envolvem os índices são menos padronizadas, pois estão mais próximas da arquitetura física do banco de dados.

A principal razão para se construir um índice é melhorar o desempenho nas consultas realizadas no banco de dados. Uma segunda razão é reforçar a unicidade entre os registros armazenados numa tabela do banco de dados.

Otimização de SGBD

Árvores B - divertido!?

Pessoal! vejam que divertido que é árvores B e como algo gráfico pode trasnformar algo complexo em algo super interessante de se aprender.

https://www.cs.tcd.ie/Jeremy.Jones/vivio/trees/B-tree.htm

(Podem aceitar a instalação do activeX)

http://slady.net/java/bt/view.php

PDF --> Árvores B

Oracle: Estrutura Lógica e Física

Artigo 1 da série “Arquitetura em posts”

Enquanto o nosso laboratório está sendo montado, aproveito para falar de teoria.

Neste artigo vou tratar as relações e os conceitos da estrutura lógica e física do Oracle que é representada na figura abaixo.




Instance

Na instância são executados processos e espaços em memória, estes permitem ao Oracle cumprir com seu papel de manter a integridade, confidencialidade e disponibilidade dos dados armazenados.

A instância fica alocada na memória compartilhada (shared memory) e é a combinação do System Global Area (SGA) com os processos background Oracle.

Por ser fundamental no funcionamento do banco de dados (BD), a arquitetura e a descrição dos caches e processos da instância serão tratados em posts posteriores, por enquanto fiquemos com a visão geral que a instância é usada para gerência e acesso ao banco de dados.

Database

Segundo Loney e Bryla, “database é uma coleção de dados em disco em um ou mais arquivos em servidor de banco de dados que coleta e mantém informações relacionadas”.

Para um banco de dados (database) ser usado ele precisa ser montado, ou seja, associado a uma instância. Antes disso, os dados estão inacessíveis a qualquer usuário ou aplicação.

Separar a instância do banco é apenas uma forma didática de explicar, pois, na prática, esta separação não ocorre. No entanto, pode acontecer de haver múltiplas instâncias rodando na mesma máquina, cada uma associada ao seu banco de dados físico.

Nota do autor: costuma existir uma confusão entre banco de dados (database) e o servidor de BD. Pode-se dizer que o servidor de BD é a associação do banco de dados com a instância.

Schema

Representa a coleção de vários objetos de um usuário de banco de dados como, por exemplo, tabelas, índices, seqüências, sinônimos etc. São associados a um banco de dados na razão de vários esquemas para um BD.

Tablespace e Datafile

Um banco de dados é armazenado logicamente em uma ou mais tablespaces que, por sua vez, é armazenada fisicamente no disco em um ou mais arquivos para cada tablespace.

Segment

Os objetos do Banco (tabelas, índices, etc) são armazenados como segmentos. Existem diferentes tipos de segmentos, como:

- Data segments (segmento de dados): armazena os dados das tabelas não clusterizadas. Para tabelas particionadas, cada partição tem seu segmento de dados.

- Index segments: segmentos de índices. Vale a regra da partição.

- Undo segments (de undo): a informação deste segmento é usado para gerar a leitura consistente e, durante o recovery, o rollback de informações não “comitadas”.

- Temporary segments (temporários): usadas quando um comando SQL precisa de uma área temporária para completar a execução.

A relação é de um ou mais segmentos para um tablespace.

Extent

Cada segmento contém um ou mais extents, que são grupos de blocos de dados contíguos (ou adjacentes).

Por exemplo, quando se cria uma tabela, o BD aloca um número inicial de extents para o segmento, quando estes extents enchem, o BD automaticamente aloca um número incremental de extents. (Estes valores são configuráveis pela clausula STORAGE do comando CREATE TABLE ou ALTER TABLE ou podem ser otimamente dimensionados pelo Oracle).

É importante notar que cada extent só pode estar em um data file.

DB Block e OS Block

Blocos de banco de dados é o menor nível de granularidade e é onde as informações são armazenadas.

O DB Bloco é um múltiplo do OS Block (bloco do sistema operacional) e o tamanho é definido por uma variável (DB_BLOCK_SIZE) no momento da criação do tablespace.

Oracle: Estruturas de Memória

A parte azul do diagrama representa a estrutura de memória no Oracle, que contêm:

1. System Global Area (SGA): Compartilhada por todos os processos;

2. Program Global Area (PGA): Exclusiva de cada de processo.

No diagrama ainda temos representados processos servidores que são criados dinamicamente para atender usuários, e processos background que realizam tarefas específicas na administração e controle do BD.


Database Buffer Cache

Armazena em memória os blocos de dados recuperados do banco de dados e é onde os dados são trabalhados. Esta é uma área importante para o desempenho do BD, pois o correto dimensionamento minimizará gravações e leitura em disco.

Redo Log Buffer

Aqui ficam as informações de redo antes de serem gravadas no arquivo físico.

Estas informações servem para recuperação da instância em caso de falha. Além disso, um usuário só recebe retorno de sucesso em uma operação após o redo ter sido gravado em disco.

Shared Pool

Divide-se em dois subcaches:

1. Biblioteca: para códigos SQL e PL/SQL;

2. Dicionário de dados.

No cache de biblioteca, se um código consta no cache, a análise sintática e o plano de execução serão aproveitados; se o código não consta no cache, os procedimentos serão feitos e armazenados.

No cache de dicionário de dados estão os metadados essenciais para o funcionamento do BD (como os objetos e privilégios de usuários), estes ficam armazenados num conjunto de tabelas possuídas pelos esquemas SYS e SYSTEM.

Streams Pool

São estruturas para a utilização do Oracle Streams, recurso da versão Enterprise do Oracle, que permite a gerênci e o compartilhamento de dados e eventos em um ambiente distribuído.

Java Pool

É usado em cada sessão pela Java Virtual Machine Oracle para executar os códigos Java da mesma maneira que o SQL e o PL são executados no shared pool.

Large Pool

Certas operações precisam de grandes blocos de memória, é este recurso que reserva estas áreas no momento que as operações necessitam. Um aplicativo que comumente usa esta área é o RMAN.

Oracle Armazenamentos!

Oracle: Dinâmica -> update

O desenho representa o servidor de banco de dados. O que está dentro do quadrado pontilhado é a Instância que é composta pela System Global Area (quadrados azuis) e os Processos em Background (bolas verdes e amarelas). Os arquivos são representados pelos cilindros marrons.

Para montar o BD de forma que seja utilizável pelos usuários (modo open), o servidor utilizará o Control File para saber onde estão os arquivos, e o Parameter File para alocar a memória.

Após ser validado, o usuário se conectará ao BD através de um processo servidor dedicado ou compartilhado. Um pouco sobre como a conexão acontece já foi tratado aqui.

Ao receber a solicitação de update do usuário, o BD checará se o usuário tem direito de fazer isto nesta tabela. Se não tiver, o BD retornará um erro e estará encerrada a solicitação.

Caso o usuário tenha este direito, o BD tratará o update submetido, verificando se este já se encontra na Library Cache (biblioteca para códigos) e, se já estiver, será imediatamente executado. Se não estiver, será feito a análise sintática (parse), o plano de execução, armazenamento na biblioteca de códigos, e a execução.

Na execução, o Oracle primeiramente checa se os dados necessários estão no Database Buffer Cache e, caso não estejam lá, os dados serão buscados nos datafiles e transferidos para este cache.

É feito o update.

Imediatamente é aplicado um row-level lock para impedir que outros usuários tentem alterar a mesma linha, e também é registrada a transação no Redo Log Buffer.

O usuário faz então um commit para validar a transação.

Neste momento o servidor altera o dado no Database Buffer Cache, o processo Log Writer escreve a transação no Redo Log File e é retornada a mensagem de sucesso na transação para o usuário.

Outros processos ainda vão trabalhar para direta, ou indiretamente, garantir a integridade do BD:

- O processo ARC0 transferirá o on line redo log file para a área destinada aos Archive Files a cada log switch;

- O processo DBW0 escreverá o dado do Database Buffer Cache para o Datafile;

- O CKPT auxiliará a sincronia do Database Buffer Cache com os Data Files, anotando o SCN nos Control Files.

Oracle: Armazenamento Físico

ESTRUTURA FÍSICA:
Control Files

Contêm dados sobre o próprio BD, também conhecidos como metadados, que são informações sobre a estrutura física. Sua leitura é essencial para que o software do banco de dados consiga abrir os arquivos de dados.

Estes arquivos podem ser multiplexados para dar mais segurança, mas somente um será utilizado como primário.

Os Control Files (arquivos de controle) também guardam informações utilizadas pelo RMAN (Recovery Manager), solução de backup da Oracle.

Data Files

Arquivos de armazenamento final dos dados dos usuários ou das aplicações no BD.

Lembrando o post “Estrutura Física e Lógica”, um banco de dados pode ter múltiplos tablespaces que, cada um, pode estar armazenado em um ou mais arquivos de dados. No entanto, um arquivo é associado a um único tablespace.

Redo Log Files (on line)

Se um banco de dados parar por qualquer motivo, desde que não ocorra perda de arquivos de dados, a instância poderá voltar ao estado que estava antes do travamento aplicando os Redo Log Files.

Para uma transação ser completada e retornar uma confirmação que está ok para o usuário, o processo LGW0 precisa gravá-la no arquivo de log de redo.

ARQUIVOS ADICIONAIS:
Parameter File

Defini a configuração da instância na inicialização do BD. Entre outras coisas este arquivo contém informações de:

1. Localização dos arquivos;

2. Configurações do SGA;

3. Número de usuários que podem se conectar.

Password File

Arquivo que guarda informações de autenticação do SYSDBA e SYSOPER para administração remota.

Backup Files

Cópias de segurança utilizadas para a recuperação de banco de dados quando o arquivo original é danificado.

Archive Log Files

O processo ARC0 faz o armazenamento contínuo dos Red Log Files nos Archive Log Files, com estes arquivos têm-se um histórico das alterações de um BD. Usando o backup mais este histórico pode-se recuperar um datafile perdido.


MULTIPLEXAÇÃO
A multiplexação de um arquivo para diversos discos é uma forma de proteger o BD de falhas de mídia.

Pode-se:

1. Usar um sistema automatizado com RAID ou o ASM (produto da Oracle);

2. Multiplexar manualmente, que é fazer o Oracle gravar em diversos locais arquivos de:

a. Control Files;

b. Log de redo;

c. Archive Log Files.

Inner join X left join

Banco de dados é uma coisa simples... quando se quer fazer coisas simples!


Às vezes, mesmo para se fazer uma coisa simples, é necessário um procedimento um pouco mais rebuscado. Já para fazer uma coisa complicada...


O que eu quero fazer não é complicado, mas como eu nunca trabalhei com os INNER, LEFT, RIGHT, OUTER etc., não foi tão trivial assim.

Estou desenvolvendo um pequeno sistema de cobrança (sim, em PHP mesmo!) onde, na listagem de clientes, entre outras coisas, é exibida a cidade e uf a que pertencem.


Até aí, tudo bem! Nada demais. Fiz um JOIN simples:


SELECT cli.*, cid.nome AS nome_cidade, cid.uf

FROM clientes AS cli, cidades AS cid

WHERE cid.id_cidade = cli.cidade

O problema é que, da forma como foi feita, a frase só me retorna os clientes cujo campo cidade esteja preenchido com um valor que conste na tabela cidades. Valores nulos ou inexistentes não retornam os registros.

Uma "solução" (ou seria bacalhau?? ^[1]) para isso seria não permitir a deleção da cidade na sua tabela, mas isso acaba nos limitando, por diversos motivos.
Eu nunca fiz um JOIN que me retornasse registros desta forma (com os correspondentes nulos ou inexistentes), mas chegara a hora de ter de fazê-lo.

Pesquisando um pouco (foi pouco mesmo!), descobri como fazer um JOIN que me retornasse o que a query acima me retorna:

SELECT * FROM clientes AS cli

INNER JOIN cidades AS cid ON cli.cidade = cid.id_cidade

Bom, até aí, tudo bem! Mas não resolveria o meu problema...

Lembrando um pouco do que eu já tinha lido sobre o tema, percebi o "INNER" na frase e imaginei que seu oposto seria o "LEFT OUTER". Logo cheguei à seguinte formulação:

SELECT * FROM clientes AS cli

LEFT OUTER JOIN cidades AS cid ON cli.cidade = cid.id_cidade



Ei-lo como qui-lo! (Ou quase...)

A sentença me retornou todos os campos da tabela de clientes, inclusive aquele registro que tinha o cídogi inválido para a cidade. Agora só faltava manipular os nomes dos campos, por causa da duplicidade (nome do cliente x nome da cidade):

SELECT cli.*, cid.nome AS nome_cidade, cid.uf

FROM clientes AS cli

LEFT OUTER JOIN cidades AS cid ON cli.cidade = cid.id_cidade

Normalização!!!

Modelagem de Dados - Final (Normalização)

Caros leitores. Estou de volta com a última parte desta série, onde falarei sobre Normalização.

Normalização é um processo baseado nas chamadas formais normais. Uma forma normal é uma regra de deve ser aplicada na construção das tabelas do banco de dados para que estas fiquem bem projetadas. Segundo autores, existem 4 formas normais. Neste artigo vou falar sobre as 3 primeiras, sendo as principais.

Com o banco de dados construído, devem-se aplicar as 3 formas normais em cada tabela, ou grupo de tabelas relacionadas. As formas têm uma ordem e são dependentes, isto é, para se aplicar a segunda norma, deve-se obrigatoriamente ter aplicado a primeira e assim por diante.

Então, vamos às normas:

1 Forma Normal: Verificação de Tabelas Aninhadas.

Para uma tabela estar na primeira forma normal ela não deve conter tabelas aninhadas. Um jeito fácil de verificar esta norma é fazer uma leitura dos campos das tabelas fazendo a pergunta: Este campo depende de qual?.

Vamos exemplificar, com a tabela Venda. Este é o esquema relacional da tabela:

Venda(Codvenda, Cliente, Endereco, Cep, Cidade, Estado, Telefone, Produto, Quantidade, Valorunitario, Valorfinal).

O raciocínio é o seguinte: A tabela Venda, deve armazenar informações da venda. Pois bem, verificando o campo Cliente, sabemos que ele depende de CodVenda, afinal para cada Venda há um cliente. Vendo o campo Endereço, podemos concluir que ele não depende de Codvenda, e sim de Cliente, pois é uma informação referente particularmente ao cliente. Não existe um endereço de venda, existe sim um endereço do cliente para qual se fez a venda. Nisso podemos ver uma tabela aninhada. Os campos entre colchetes, são referentes ao cliente e não á venda.

Venda (Codvenda, [Cliente, Endereço, Cep, Cidade, Estado, Telefone, Produto, Quantidade, Valorunitario, Valorfinal).

A solução é extrair estes campos para uma nova tabela, adicionar uma chave-primária à nova tabela e relaciona-la com a tabela Venda criando uma chave-estrangeira.

Ficaria desta forma:

Cliente (Codcliente, Nome, Endereço, Cep, Cidade, Estado, Telefone).

Venda (Codvenda, Codcliente, Produto, Quantidade, Valorunitario, Valorfinal).

Agora aplicamos novamente á primeira forma normal as 2 tabelas geradas. Uma situação comum em tabelas de cadastro é o caso Cidade-Estado. Analisando friamente pela forma normal, o Estado na tabela Cliente, depende de Cidade. No entanto Cidade, também depende de Estado, pois no caso de a cidade ser Curitiba o estado sempre deverá ser Paraná, porém se o Estado for Paraná, a cidade também poderá ser Londrina. Isso é o que chamamos de Dependência funcional: é onde aparentemente, uma informação depende da outra. No caso Cidade-Estado a solução é simples:

Extraímos Cidade e Estado, de Cliente e geramos uma nova tabela. Em seguida, o mesmo processo feito anteriormente: adicionar uma chave-primária à nova tabela e relaciona-la criando uma chave-estrangeira na antiga tabela.

Cidade (Codcidade, Nome, Estado).

Cliente (Codcliente, Codcidade, Nome, Endereço, Cep, Telefone).

Venda (Codvenda, Codcliente, Codcidade, Produto, Quantidade, Valorunitario, Valorfinal).

Seguindo com o exemplo, a tabela Cliente encontra-se na 1 forma normal, pois não há mais tabelas aninhadas. Verificando Venda, podemos enxergar mais uma tabela aninhada. Os campos entre colchetes são referente á mesma coisa: Produto de Venda

Venda (Codvenda, Codcliente, Codcidade, [Produto Quantidade, [Valorunitario, Valorfinal).

Na maioria das situações, produtos têm um valor previamente especificado. O Valorunitário depende de Produto. Já a Quantidade (campo entre Produto e Valorunitario) não depende do produto e sim da Venda.

Cidade (Codcidade, Nome, Estado).

Cliente (Codcliente, Codcidade, Nome, Endereço, Cep, Telefone).

Produto (Codproduto, Nome, Valorunitario).

Venda (Codvenda, Codcliente, Codcidade, Codproduto, Quantidade, Valorfinal).

Passando a tabela Venda pela primeira forma normal, obtivemos 3 tabelas. Vamos á próxima forma

2 Forma Normal: Verificação de Dependências Parciais

Para uma tabela estar na segunda formal, além de estar na primeira forma ela não deve conter dependências parciais. Um jeito de verificar esta norma é refazer a leitura dos campos fazendo a pergunta: Este campo depende de toda a chave? Se não, temos uma dependência parcial..

Vimos antes o caso Cidade-Estado que gerava uma dependência funcional. É preciso entender este conceito para que você entenda o que é Dependência Parcial.

Após a normalização da tabela Venda, acabamos com uma chave composta de 4 campos:

Venda (Codvenda, Codcliente, Codcidade, Codproduto, Quantidade, Valorfinal).

A questão agora é verificar se cada campo não-chave depende destas 4 chaves. O raciocínio seria assim:

1. O primeiro campo não-chave é Quantidade.


2. Quantidade depende de Codvenda, pois para cada venda há uma quantidade específica de itens.


3. Quantidade depende de Codvenda e Codcliente, pois para um cliente podem ser feitas várias vendas, com quantidades diferentes.


4. Quantidade não depende de Cidade. Quem depende de Cidade é Cliente. Aqui está uma dependência parcial.


5. Quantidade depende de Codproduto, pois para cada produto da Venda á uma quantidade certa.

Quantidade depende de 3 campos, dos 4 que compõe a chave de Venda. Quem sobrou nessa história foi Codcidade. A tabela Cidade já está ligada com Cliente, que já está ligado com Venda. A chave Codcidade em Venda é redundante, portanto podemos eliminá-la.

Venda (Codvenda, Codcliente, Codproduto, Quantidade, Valorfinal).

O próximo campo não-chave é Valorfinal. Verificando Valorfinal, da mesma forma que Quantidade, ele depende de toda a chave de Venda. Portanto vamos á próxima norma.

3 Forma Normal: Verificação de Dependências Transitivas

Para uma tabela estar na segunda formal, além de estar na segunda forma ela não deve conter dependências transitivas. Um jeito de verificar esta norma é refazer a leitura dos campos fazendo a pergunta: Este campo depende de outro que não seja a chave? Se Sim, temos uma dependência transitiva..

No exemplo de Venda, temos um caso de dependência transitiva:

Na tabela Venda, temos Valorfinal. Este campo é o resultado do valor unitário do produto multiplicado pela quantidade, isto é, para um valor final existir ele DEPENDE de valor unitário e quantidade. O Valorunitário está na tabela Produto, relacionada à Venda e Quantidade está na própria Venda. Valorfinal depende destes 2 campos e eles não são campos-chave, o que nos leva a pensar: Se temos valor unitário e quantidade, porque teremos valor final? O valor final nada mais é que o resultado de um cálculo de dados que já está estão no banco, o que o torna um campo redundante.

Quando for necessário ao sistema obter o valor final, basta selecionar o valor unitário e multiplicar pela quantidade. Não há porque guardar o valor final em outro campo. Aqui a solução é eliminar o campo Valorfinal.

Cidade (Codcidade, Nome, Estado).

Cliente (Codcliente, Codcidade, Nome, Endereco, Cep, Telefone).

Produto (Codproduto, Nome, Valorunitario).

Venda (Codvenda, Codcliente, Codproduto, Quantidade).

Em tese, agora temos todas as tabelas normalizadas. Ainda restou o caso do campo Estado na tabela Cidade, mas eu deixarei para uma outra ocasião, pois o objetivo aqui é mostrar conceitualmente o processo de normalização do banco de dados.

É muito comum, no processo de normalização enxergamos todas as formas normais ao mesmo tempo. Enquanto separamos as tabelas aninhadas, já conseguimos ver as dependências transitivas e logo mais encontramos uma dependência parcial, tudo assim, ao mesmo tempo. Isso é normal. Só tome cuidado, para não deixar nada passar batido.

Trigges! O que é? como usar?

Introdução à TRIGGERS

Há tempos que venho estudando sobre esse tipo de implementação voltada primeiramente ao SQL Server e agora também, podendo ser utilizada no MySQL em sua versão de número 5 ou posterior.

Embora muitos desenvolvedores e entusiastas digam que eles são boas práticas dentro de bancos de dados, resolvi estudar a fundo, para deixar aqui a minha posição sobre o assunto.

Existem várias maneiras de tratarmos ou nos dirigirmos a esse tipo de implementação. Podemos chamar de TRIGGER, gatilhos ou disparadores. Neste artigo, usarei o termo mais conhecido entre administradores de Banco de Dados, TRIGGER.

Todos os scripts que aqui serão exibidos foram testados em um ambiente Windows XP Professional, rodando SQL Server 2000 Service Pack 4.

CONCEITOS:

· O que são TRIGGERS;

· Usos e aplicabilidade dos TRIGGERS;

· Considerações e boas práticas em relação aos TRIGGERS;

· Quando e como usá-los;

Primeiramente, vamos abordar o conceito central de TRIGGERS:

Um trigger é um tipo especial de procedimento armazenado, que é executado sempre que há uma tentativa de modificar os dados de uma tabela que é protegida por ele.

- Associados a uma tabela
Os TRIGGERS são definidos em uma tabela específica, que é denominada tabela de TRIGGERS;
- Chamados Automaticamente
Quando há uma tentativa de inserir, atualizar ou excluir os dados em uma tabela, e um TRIGGER tiver sido definido na tabela para essa ação específica, ele será executado automaticamente, não podendo nunca ser ignorado.

- Não podem ser chamados diretamente
Ao contrário dos procedimentos armazenados do sistema, os disparadores não podem ser chamados diretamente e não passam nem aceitam parâmetros.
- É parte de uma transação

O TRIGGER e a instrução que o aciona são tratados como uma única transação, que poderá ser revertida em qualquer ponto do procedimento, caso você queria usar “ROLLBACK”, conceitos que veremos mais a frente.

Orientações básicas quando estiver usando TRIGGER.

- As definições de TRIGGERS podem conter uma instrução “ROLLBACK TRANSACTION”, mesmo que não exista uma instrução explícita de “BEGIN TRANSACTION”;
- Se uma instrução “ROLLBACK TRANSACTION” for encontrada, então toda a transação (o TRIGGER e a instrução que o disparou) será revertida ou desfeita. Se uma instrução no script do TRIGGER seguir uma instrução “ROLLBACK TRANSACTION”, a instrução será executada, então, isso nos obriga a ter uma condição IF contendo uma cláusula RETURN para impedir o processamento de outras instruções.

- Não é uma boa prática utilizar “ROLLBACK TRANSACTION” dentro de seus TRIGGERS, pois isso gerará um retrabalho, afetando muito no desempenho de seu banco de dados, pois toda a consistência deverá ser feita quando uma transação falhar, lembrando que tanto a instrução quanto o TRIGGER formam uma única transação. O mais indicado é validar as informações fora das transações com TRIGGER para então efetuar, evitando que a transação seja desfeita.

- Para que um TRIGGER seja disparado, o usuário o qual entrou com as instruções, deverá ter permissão de acessar tanto a entidade e consequentemente ao TRIGGER.

VEJA MAIS!!!!

Executar o "faxina" ? SP in oracle

Pessoal! Todos estavam com problemas em executar um SP dentro do Oracle, a tal faxina né?! pronto, seus problemas acabariummmm... Segue abaixo a sequência de imagens que ilustram como resolver isso no Oracle Application Express.

Avaliem que é necessário importar o faxina.sql para dentro do oracle, e após executar como uma SP.

Begin .... end;

Valeus.
[]'Galina

Visualizar todas as tabelas?!

Galerinha!

Segue aqui o comando sql para visualizar todas as tabelas no oracle.

SELECT table_name FROM USER_TABLES

Valeus!

Flashback Drop no Oracle 10g

Olá,
Dropar tabelas por engano sempre foi um problema para usuários e DBAs. Usuários assim que percebem que cometeram um engano e então, percebem que é tarde demais para voltar atrás, pensam: E agora?
Historicamente, não há um jeito fácil de recuperar todos estes objetos dropados como tabelas, índices, restrições de integridade, gatilhos, etc...
Nas versões anteriores ao Oracle 10g, se você quisesse recuperar uma tabela que foi dropada acidentalmente, seria necessário importar esta tabela de um arquivo de exportação (dump) recente ou realizar uma recuperação incompleta baseada em horário, onde a recuperação é encerrada após todas as alterações feitas até determinado momento terem sido submetidas à commit.

Trabalhando com Flashback Drop no Oracle 10g

Sequence!!! Terrível!?

Pessoal!

Todo o semestre acho que é bom relembrar! Sequence em Oracle! uffffff que mão hein!! Sql Server just (identity) mas aqui no oracle... ahhhhhh só com trigger!!!

Então está aih o exemplo.

SQL> create sequence T_SEQ_NEW start with 1 increment by 1 maxvalue 999 nocycle;

SQL> create table Cliente(Codigo number(4), Nome varchar2(100));

SQL> select * from Cliente;

SQL> insert into Cliente values (T_SEQ_NEW.NEXTVAL,'Professor Galina');

SQL> insert into Cliente values (T_SEQ_NEW.NEXTVAL,'Alunos');

SQL> select * from Cliente;
Codigo Nome
---------- ----------------------------------------
1 Professor Galina
2 Alunos

Link na prática --> http://www.devmedia.com.br/articles/viewcomp.asp?comp=402

Goood luck'
[]`s Galina.

Modelagem Conceitual X Lógico

Alow pessoal!

Importantíssimo artigo da web referente a Modelagem Conceitual X Lógico!

Avaliem e postem suas dúvidas

Link: http://imasters.uol.com.br/artigo/6800/bancodedados/modelo_conceitual_vs_modelo_logico/