Procedimento Armazenado

Procedimento Armazenado (Stored Procedure)

Procedimento armazenado ou Stored Procedure é uma coleção de comandos em SQL para dispensamento de Banco de Dados. Encapsula tarefas repetitivas, aceita parâmetros de entrada e retorna um valor de status (para indicar aceitação ou falha na execução). O procedimento armazenado pode reduzir o tráfego na rede, melhorar a performance, criar mecanismos de segurança, etc.

O que é um Stored Procedure?

R: Stored Procedure é um conjunto de comandos, ao qual é atribuído um nome. Este conjunto fica armazenado no Banco de Dados e pode ser chamado a qualquer momento tanto pelo SGBD (Sistema Gerenciador de Banco de Dados) quanto por um sistema que faz interface com o mesmo.

Você pode criar uma Stored Procedure em linha de comando no Query Analizer com a seguinte sintaxe:

Create procedure busca
@nomedebusca varchar (50)
as
select nome1, nome2
from nome_da_tabela
where nome = @nomedebusca

Ou

CREATE PROCEDURE nome_do_stored_procedure
[
{@parametro tipo_de_dados_parametro}[=valor_default] [output]
]
[,...n]
AS
comando1,
comando2,
comando3,
...,
comando2
GO

Algumas considerações:

• Somente poderão executar o comando CREATE STORED PROCEDURE, usuários que são membros da role de servidor sysadmin ou das roles de Banco de Dados db_owner e db_ddladmin;

• Em um Stored Procedure, podemos incluir qualquer comando T-SQL, com exceção dos seguintes: CREATE PROCEDURE, CREATE DEFAULT, CREATE RULE, CREATE TRIGGER E CREATE VIEW;

• Em um Stored Procedure podemos referenciar tabelas, Views, outras Stored Procedures e tabelas temporárias.

Bom, é isso meus amigos espero que isso ajude algo.. foi básica e bem filtrada a minha explicação.

Normalização de Dados

Bom Normalização de Dados para quem nunca ouviu falar eu vou comentar um pouco mais sobre tudo isso aos novatos na área de Banco de Dados. Vou tentar ser o mais breve e objetivo possível. A Normalização de Dados é uma série de passos que se segue no projeto de um banco de dados que permite um armazenamento consistente e um eficiente acesso aos dados em um banco de dados relacional. Esses passos reduzem a redundância de dados e as chances dos dados se tornarem inconsistentes.

No entanto, muitas SGBDs relacionais não têm separação suficiente entre o projeto lógico da base de dados e a implementação física do banco de dados, e isso tem como conseqüência que as consultas feitas a um banco de dados totalmente normalizado têm um mau desempenho. Nestes casos, usa-se por vezes a desnormalização para melhorar o desempenho, com o custo de menores garantias de consistência.

Definição

Consiste em definir o formato lógico adequado para as estruturas de dados identificados no projeto lógico do sistema, com o objetivo de minimizar o espaço utilizado pelos dados e garantir a integridade e confiabilidade das informações.

A normalização é feita, através da análise dos dados que compõem as estruturas utilizando o conceito chamado “Formas Normais (FN)”. As FN são conjuntos de restrições nos quais os dados devem satisfazê-las. Exemplo, pode-se dizer que a estrutura está na primeira forma normal (1FN), se os dados que a compõem satisfizerem as restrições definidas para esta etapa.

A normalização completa dos dados é feita, seguindo as restrições das quatro formas normais
existentes, sendo que a passagem de uma FN para outra é feita tendo como base o resultado obtido na etapa anterior, ou seja, na FN anterior.

Para realizar a normalização dos dados, é primordial que seja definido um campo chave para a estrutura, campo este que permite irá identificar os demais campos da estrutura.

Formas Normais existentes:

1 – Primeira Forma Normal (1FN)

Consiste em retirar da estrutura os elementos repetitivos, ou seja, aqueles dados que podem compor uma estrutura de vetor. Podemos afirmar que uma estrutura está normalizada na 1FN, se não possuir elementos repetitivos. Exemplo:

Estrutura original:

Arquivo de Notas Fiscais (Num. NF, Série, Data emissão, Cod. do Cliente, Nome do cliente, Endereço do cliente, CGC do cliente, Relação das mercadorias vendidas (onde para cada mercadoria temos: Código da Mercadoria, Descrição da Mercadoria, Quantidade vendida, Preço de venda e Total da venda desta mercadoria) e Total Geral da Nota)

Analisando a estrutura acima, observamos que existem várias mercadorias em uma única Nota Fiscal, sendo portanto elementos repetitivos que deverão ser retirados.

Estrutura na primeira forma normal (1FN):

Arquivo de Notas Fiscais (Num. NF, Série, Data emissão, Código do Cliente, Nome Cliente, Endereço do cliente, CGC do cliente e Total Geral da Nota)

Arquivo de Vendas (Num. NF, Código da Mercadoria, Descrição da Mercadoria, Quantidade vendida, Preço de venda e Total da venda desta mercadoria)

Obs. Os campos sublinhados identificam as chaves das estruturas.

Como resultado desta etapa ocorre um desdobramento dos dados em duas estruturas, a saber:

- Primeira estrutura (Arquivo de Notas Fiscais): Dados que compõem a estrutura original, excluindo os elementos repetitivos.

- Segundo estrutura (Arquivo de Vendas): Dados que compõem os elementos repetitivos da estrutura original, tendo como chave o campo chave da estrutura original (Num. NF) e o campo chave da estrutura de repetição (Código da Mercadoria).

2 – Segunda Forma Normal (2FN)

Consiste em retirar das estruturas que possuem chaves compostas (campo chave sendo formado por mais de um campo), os elementos que são funcionalmente dependente de parte da chave. Podemos afirmar que uma estrutura está na 2FN, se ela estiver na 1FN e não possuir campos que são funcionalmente dependente de parte da chave.

Exemplo:

Estrutura na primeira forma normal (1FN):

Arquivo de Notas Fiscais (Num. NF, Série, Data emissão, Código do Cliente, Nome do cliente, Endereço do cliente, CGC do cliente e Total Geral da Nota)

Arquivo de Vendas (Num. NF, Código da Mercadoria, Descrição da Mercadoria, Quantidade vendida, Preço de venda e Total da venda desta mercadoria)

Estrutura na segunda forma normal (2FN):

Arquivo de Notas Fiscais (Num. NF, Série, Data emissão, Código do Cliente, Nome do cliente, Endereço do cliente, CGC do cliente e Total Geral da Nota)

Arquivo de Vendas (Num. NF, Código da Mercadoria, Quantidade vendida e Total da venda desta mercadoria)

Arquivo de Mercadorias (Código da Mercadoria, Descrição da Mercadoria, Preço de venda)

Como resultado desta etapa, houve um desdobramento do arquivo de Vendas (o arquivo de Notas Fiscais, não foi alterado, por não possuir chave composta) em duas estruturas a saber:

- Primeira estrutura (Arquivo de Vendas): Contém os elementos originais, sendo excluídos os dados que são dependentes apenas do campo Código da Mercadoria.

- Segundo estrutura (Arquivo de Mercadorias): Contém os elementos que são identificados apenas pelo Código da Mercadoria, ou seja, independentemente da Nota Fiscal, a descrição e o preço de venda serão constantes.

3 – Terceira Forma Normal (3FN)

Consiste em retirar das estruturas os campos que são funcionalmente dependentes de outros campos que não são chaves. Podemos afirmar que uma estrutura está na 3FN, se ela estiver na 2FN e não possuir campos dependentes de outros campos não chaves.

Exemplo:

Estrutura na segunda forma normal (2FN):

Arquivo de Notas Fiscais (Num. NF, Série, Data emissão, Código do Cliente, Nome do cliente, Endereço do cliente, CGC do cliente e Total Geral da Nota)

Arquivo de Vendas (Num. NF, Código da Mercadoria, Quantidade vendida e Total da venda desta mercadoria)

Arquivo de Mercadorias (Código da Mercadoria, Descrição da Mercadoria, Preço de venda)

Estrutura na terceira forma normal (3FN):

Arquivo de Notas Fiscais (Num. NF, Série, Data emissão, Código do Cliente e Total Geral da Nota)

Arquivo de Vendas (Num. NF, Código da Mercadoria, Quantidade vendida e Total da venda desta mercadoria)

Arquivo de Mercadorias (Código da Mercadoria, Descrição da Mercadoria, Preço de venda) Arquivo de Clientes (Código do Cliente, Nome do cliente, Endereço do cliente e CGC do cliente)

Como resultado desta etapa, houve um desdobramento do arquivo de Notas Fiscais, por ser o único que possuía campos que não eram dependentes da chave principal (Num. NF), uma vez que independente da Nota Fiscal, o Nome, Endereço e CGC do cliente são inalterados. Este procedimento permite evitar inconsistência nos dados dos arquivos e economizar espaço por eliminar o armazenamento freqüente e repetidas vezes destes dados. A cada nota fiscal comprada pelo cliente, haverá o armazenamento destes dados e poderá ocorrer divergência entre eles.

As estruturas alteradas foram pelos motivos, a saber:

- Primeira estrutura (Arquivo de Notas Fiscais): Contém os elementos originais, sendo excluído os dados que são dependentes apenas do campo Código do Cliente (informações referentes ao cliente).

- Segundo estrutura (Arquivo de Clientes): Contém os elementos que são identificados apenas pelo Código do Cliente, ou seja, independente da Nota Fiscal, o Nome, Endereço e CGC dos clientes serão constantes.

Após a Normalização, as estruturas dos dados estão projetadas para eliminar as inconsistências e redundâncias dos dados, eliminando desta forma qualquer problema de atualização e operacionalização do sistema. A versão final dos dados poderá sofrer alguma alteração, para atender as necessidades específicas do sistema, a critério do analista de desenvolvimento durante o projeto físico do sistema.

Tecnologia OLAP

Olá pessoal hoje vou falar de uma tecnologia chamada e para vocês terem uma melhor entendimento sobre oque estarei falando eu vou citar algumas definições para melhor entendimento deste assunto chamado OLAP,ou On-line Analytical Processing é a capacidade para manipular e analisar um grande volume de dados sob múltiplas perspectivas.

As aplicações OLAP são usadas pelos gestores em qualquer nível da organização para lhes permitir análises comparativas que facilitem a sua tomada de decisões diárias.

Classifica-se em ROLAP, MOLAP, HOLAP, DOLAP E WOLAP.

Benefícios

"Online analytical processing", ou OLAP fornece para organizações um método de acessar, visualizar, e analisar dados corporativos com alta flexibilidade e performance. A tecnologia quanto maior e complexa a informação armazenada, mais difícil é para retirá-la. A tecnologia acaba com estas dificuldades levando a informação mais próxima ao usuário que dela necessite. Portanto, o OLAP é freqüentemente utilizado para integrar e disponibilizar informações gerenciais contidas em bases de dados operacionais, sistemas ERP e CRM, sistemas contábeis, e Data Warehouses. Estas características tornaram-no uma tecnologia essencial em diversos tipos de aplicações de suporte à decisão e sistemas para executivos.

Citar uma outra visão geral de OLAP é um Business Intelligence (BI) como citei pouco atrás

• É um processo de coleta, transformação, análise e distribuição de dados para melhorar a decisão de negócios;

• Sua infra-estrutura tecnológica é composta de data warehouses ou data marts, ferramentas OLAP, EIS, data mining, consultas e relatórios e software de visualização dos dados;

• Os bancos de dados são a infra-estrutura básica de qualquer sistema de business intelligence. São neles que vão estar armazenados os dados que serão transformados em informações competitivas.

Hoje OLAP é um dos muitos componentes do Framework de Business Intelligence, assim como outras tecnologias de Suporte à Decisão, tais como: visualização de dados, data mining, data warehousing. Alguns fornecedores têm feito o esforço de incluir na sua linha de produtos estas tecnologias de suporte à decisão, outros fornecedores optaram por um produto aberto formando parcerias com fornecedores de produtos complementares.

Muitas outras tecnologias de suporte à decisão devem se integrar com a tecnologia OLAP, incluindo pacotes de análise estatística, sistemas de informações geográficas (GIS), e ferramentas de visualização de dados.

A maioria de vendedores de servidores OLAP oferecem add-ins para planilha eletrônica como opção de front-end, possibilitando, com isto, apresentar dados multidimensionais via planilha eletrônica. A principal vantagem desta abordagem é que ela combina a exibição flexível, a força em formatação e os cálculos para fins específicos das planilhas com o gerenciamento de dados, cálculos e performance da tecnologia de banco de dados multidimensionais. Os fornecedores de servidores OLAP só precisam produzir diferentes versões de seus add-ins para cada nova versão da planilha.

Modelo de Dados

Em um modelo de dados OLAP, a informação é conceitualmente organizada em cubos que armazenam valores quantitativos ou medidas. Dentro de cada dimensão de um modelo OLAP, os dados podem ser organizados em uma hierarquia que define diferentes níveis de detalhe. Por exemplo, dentro da dimensão tempo, você poderá ter uma hierarquia representando os níveis anos, meses, e dias. Da mesma forma, a dimensão região poderá ter os níveis país, região, estado e cidade. Assim, um usuário visualizando dados em um modelo OLAP irá navegar para cima (drill up) ou para baixo (drill down) entre níveis para visualizar informação com maior ou menor nível de detalhe sem a menor dificuldade. Algumas Aplicações

A aplicação do OLAP é bastante diversificada e seu uso encontra-se em diversas áreas de uma empresa. Alguns tipos de aplicação aonde a tecnologia é empregada são:

- Finanças Análise de L&P, Relatórios L&P, Orçamento, Análise de Balanço, Fluxo de Caixa, Contas a Receber, …

- Vendas Análise de vendas (por região, produto, vendedor, etc.), Previsões, Lucratividade de Cliente/Contrato, Análise de Canais de Distribuição, ….

- Marketing Análise de Preço/Volume, Lucratividade de Produto, Análise de Mercados, …

- Recursos Humanos Análise de Benefícios, Projeção de Salários, Análise de "Headcount", … Manufatura Gerência de Estoque, Cadeia de Fornecimento, Planejamento de Demanda, Análise de custos de matéria-prima.

Banco de Dados Distribuídos

Bom vou hoje falar a você um pouco mais sobre Banco de Dados Distribuído (BDD) ele é uma coleção de vários Base de Dados logicamente inter-relacionados, distribuídos por uma rede de computadores. Existem dois tipos de banco de dados distribuídos, os homogêneos e os heterogêneos. Os homogêneos são compostos pelos mesmos bancos de dados, já os Heterogêneos são aqueles que são compostos por mais de um tipo de banco de dados.

Melhor explicando num banco de dados distribuídos os arquivos podem estar replicados ou fragmentados, esses dois tipos podem ser encontrados aos longos dos nós do sistema de BDD's. Quando os dados se encontram replicados, existe uma cópia de cada um dos dados em cada nó, tornando as bases iguais (ex: tabela de produtos de uma grande loja). Já na fragmentação, os dados se encontram divididos ao longo do sistema, ou seja a cada nó existe uma base de dados diferente se olharmos de uma forma local, mas se analisarmos de uma forma global os dados são vistos de uma forma única, pois cada nó possui um catálogo que contém cada informação dos dados dos bancos adjacentes.

Podendo a replicação dos dados pode se dar de maneira síncrona ou assíncrona. No caso de replicação síncrona, cada transação é dada como concluída quando todos os nós confirmam que a transação local foi bem sucedida. Na replicação assíncrona, o nó principal executa a transação enviando confirmação ao solicitante e então encaminha a transação aos demais nós.

Arquitetura Básica

Aplicações Locais

aplicações que não requerem dados de outros lugares.

Aplicações Globais

aplicações que requerem dados de outros lugares.

Alguns cuidados com a Distribuição de Dados

• A distribuição é transparente — usuários devem poder interagir com o sistema como se ele fosse um único sistema lógico. Isso se aplica ao desempenho do sistema, métodos de acesso, entre outras coisas.
• Transações são transparentes — cada transação deve manter a integridade do banco de dados dentre os múltiplos bancos de dados. Transações devem também ser divididas em subtransações, cada subtransação afetando um sistema de banco de dados...

Vantagens de Bancos de Dados Distribuídos

• Reflete a estrutura organizacional — fragmentos do banco de dados estão localizados nos departamentos que se relacionam com os dados que estes persistem.
• Autonomia Local — um departamento pode controlar seus dados (já que é o mais familiarizado com estes).
• Maior disponibilidade — uma falha em um banco de dados afetará somente um fragmento, ao invés do banco de dados inteiro.
• Melhor performance — os dados estão localizados próximo do local de maior demanda e os sistemas de banco de dados por si só são paralelizáveis, permitindo carregar no banco de dados para o balanceamento entre servidores (a elevada carga em um módulo do banco de dados não irá afetar os outros módulos de banco de dados em um banco de dados distribuído).
• Econômico — custa menos criar uma rede de pequenos computadores com o mesmo poder que um único computador maior.
• Modularidade — sistemas podem ser modificados, adicionados ou removidos do banco de dados distribuído sem afetar os outros módulos (sistemas).

Desvantagens de banco de dados distribuídos

• Complexidade — trabalho extra deve ser feito pelos DBAs para garantir que a natureza da distribuição do sistema é transparente. Trabalho extra deve ser feito para manter sistemas múltiplos diferentes, ao invés de um único grande. Design de banco de dados extra deve também ser feito para levar em conta a natureza desconectada do banco de dados - por exemplo, joins tornam-se proibitivamente caros quando são rodados entre múltiplas plataformas.
• Implantação mais cara — o aumento da complexidade e uma infraestrura mais extensa significa custo extra de trabalho
• Segurança — fragmentos de banco de dados remotos devem ser seguros e, como eles não são centralizados então os lugares remotos também devem ser seguros. A infraestrutura também deve ser segura (por exemplo, pela encriptação dos links de rede entre os lugares remotos).
• Difícil de manter a integridade — em sistemas distribuídos, reforçar a integridade ao longo de uma rede pode exigir demais dos recursos da rede para ser viável.
• Inexperiência — pode ser difícil trabalhar com banco de dados distribuídos e como é uma área relativamente nova ainda não há tantos casos (ou experiências) práticos de seu uso disponíveis como exemplo.
• Falta de padrões – ainda não há metodologias e ferramentas para ajudar usuários a converter um SGBD centralizado para um SGBD distribuído.
• Design do banco de dados mais complexo – além das dificuldades normais, o design de um banco de dados distribuídos tem que considerar a fragmentação dos dados, alocação dos fragmentos em lugares específicos e a replicação de dados.

Espero que vocês tenham gostado e entendido um pouco mais sobre (BDD) ou melhor falando Bando de Dados Distribuídos.