Otimizando desempenho no SQL Server 2005 – Parte II

 

O bom desempenho em consultas de bancos de dados vai além da estratégia de índices utilizada nas tabelas pertencentes à consulta. Questões como: projeto de bancos de dados, dimensionamento do hardware e estratégias de otimização são itens que afetam diretamente o tempo de resposta das consultas em geral.

Este artigo propõe-se a discutir aspectos que transcendem a otimização de consultas de bancos de dados. Outras questões como: memória, processador, disco e subsistema de comunicação também podem se tornar fatores de gargalo e afetar o desempenho no nível do sistema. Entende-se por “gargalo” qualquer componente ou atividade que limita o desempenho do sistema. Veremos alguns desses fatores abaixo.

Projeto de bancos de dados

Quando se projeta um banco de dados deve-se ter a certeza de que todas as funcionalidades serão fornecidas de maneira correta e com o menor tempo de resposta possível. Algumas questões de projeto até podem, mas não devem, ser resolvidas após a colocação do banco de dados em produção. Por exemplo, é possível decidir pela criação de constraint de check em uma determinada coluna de uma tabela do banco de dados após o sistema estar no ar. Porém, há questões de desempenho que são resultantes de um projeto de banco de dados ineficaz ou uma modelagem de dados equivocada que tornam sua utilização uma tarefa quase impossível pelos altos tempos de resposta envolvidos. Nesses casos, a solução mais correta é a alteração da estrutura e um novo projeto de banco de dados. Contudo, a solução de reconstrução do projeto, além de drástica, é extremamente custosa.

Questões como: as maiores tabelas do banco e os processos mais complexos da aplicação devem ser identificados tão logo seja possível, bem como considerações sobre os efeitos no desempenho causados pelo aumento do número de usuários que acessam o banco de dados.

Exemplos de mudanças de projeto que podem fornecer melhoria de desempenho:

·         Imagine uma tabela que contenha milhares de registros, das vendas diárias de uma livraria. Suponha que essas vendas devam ser totalizadas para serem usadas em um relatório diário. É possível adicionar uma ou várias colunas nessa tabela que guardem dados previamente agregados para serem usados no relatório ou utilizar uma estratégia de processamento e construção prévia do conjunto de resultados desejado. A idéia aqui é diminuir a sobrecarga de realizar a soma desses valores em tempo de execução. Portanto, colunas calculadas ou consolidação de dados via trigger seriam boas saídas;

·         Bancos de dados excessivamente normalizados podem ter o desempenho de consultas reduzido. Isso se deve, principalmente, ao fato de existirem muitas pequenas tabelas inter-relacionadas. Esse cenário prejudica o desempenho porque o banco terá de processar os dados de todas as tabelas envolvidas e combiná-los para retornar os resultados. Em certas situações um grau controlado de desnormalização é benéfico à aplicação.

 

Considerações de hardware

Geralmente, quanto maior o banco de dados mais recursos de hardware serão necessários para suportar as operações realizadas por seus usuários. Entretanto, vale ressaltar que outros fatores determinantes incluem o número de sessões concorrentes, throughput de transações (quantidade de transações que podem ser realizadas em um mesmo período de tempo) e os tipos de operações que são utilizadas no banco de dados: select, insert, update e delete.

Por exemplo, um sistema de biblioteca que é pouco atualizado terá menos requisitos de hardware do que um data warehouse corporativo altamente acessado pelo departamento de vendas. Da mesma forma, discos maiores para o armazenamento de dados, maior quantidade de memória e processadores mais rápidos seriam fundamentais ao data warehouse, mas não teria um custo benefício interessante para o sistema de biblioteca.

O mecanismo de armazenamento é uma questão chave para qualquer banco de dados relacional e requer bastante atenção no planejamento. Implementações de sucesso requerem um planejamento cuidadoso e rigoroso na etapa de projeto. Esse planejamento deve incluir considerações sobre as seguintes questões:

·         Como armazenar os dados ao longo dos discos usando arquivos e grupos de arquivos;

·         Que projeto de índice utilizar para fornecer desempenho de consulta no acesso aos dados – para mais informações sobre índices consulte o artigo Otimizando o desempenho no SQL Server 2005 – Parte I, publicado na SQL Magazine nºXX;

·         Como configurar os parâmetros do banco de dados para obter o máximo de desempenho;

·         E, caso necessário, qual o tipo de RAID Redundant Array of Independent Disks (Array redundante de discos independentes) de hardware será utilizado.

 

Vejamos a seguir alguns desses itens.

Arquivos e Grupos de Arquivos

Um banco de dados SQL Server é composto de, no mínimo, dois arquivos: um arquivo de dados e um arquivo de log. Esses arquivos, na verdade, só são percebidos pelo sistema operacional uma vez que o SQL Server enxerga o banco como uma unidade indivisível. As informações de dados e log nunca são misturadas no mesmo arquivo. Além disso, existirão arquivos separados para cada banco de dados. A Figura 1 ilustra um banco de dados e seus arquivos.

 

 

Figura 1. Bancos de dados e seus arquivos

 

Um ou mais arquivos podem ser agrupados em estruturas conhecidas como grupos de arquivos. Os grupos de arquivos facilitam tarefas administrativas como operações de backup e restore. Se por ventura a configuração de hardware possuir diversas unidades de disco, é possível alocar os grupos de arquivos em discos individuais. A Figura 2 ilustra a utilização de dois grupos de arquivos: o primary e um segundo grupo de arquivos definido pelo usuário. O grupo de arquivos primary é default (quando uma determinada tabela é criada, se nada for dito em contrário, ela será criada dentro do primary) do SQL Server e guarda as tabelas do catálogo presentes em cada banco de dados. O grupo de arquivos definido pelo usuário guarda objetos de usuário e não objetos do catálogo do sistema. Portanto, é importante que ao criar um novo banco de dados seja criado, logo em seguida, um grupo de arquivos, definido pelo usuário, para o armazenamento dos objetos. Na Figura 2, as tabelas OrdHistYear1 e OrdHistYear1 são armazenadas no grupo de arquivos definido pelo usuário “User-defined Filegroup”. Os arquivos de log de transações não pertencem a grupos de arquivos e são armazenados em estruturas à parte.

 

 

Figura 2. Grupos de arquivos

A utilização de arquivos e grupos de arquivos melhora o desempenho do banco de dados porque é possível criar o banco espalhando seus arquivos ao longo de vários discos, controladoras de disco ou conjuntos RAID. Imagine por exemplo que sua máquina possui quatro discos. É possível criar um banco de dados composto de três arquivos de dados e um arquivo de log e armazenar cada arquivo em um disco diferente. Quando os dados forem acessados, os quatro cabeçotes de leitura e gravação podem ler ou gravar os dados, de forma paralela.

Além disso, as tabelas mais freqüentemente acessadas pode

...

Transações envolvendo DDL no SQL Server 2005

Por Reydeval Rocha

 

 

Olá pessoal!!!

 

Hoje trataremos de um tema muito interessante: transações envolvendo instruções DDL – Data Definition Language.

 

Introdução

 

Sabemos que transações são unidades lógicas de trabalho, ou seja, todas as instruções que compõem o bloco são efetivadas ou nenhuma delas é efetivada. Esse conceito garante a consistência e integridade dos dados. O interessante é que no SQL Server as transações não funcionam apenas com instruções DML, mas também com instruções DDL. Vejamos os exemplos abaixo que ilustram a utilização de transações envolvendo comandos DDL.

 

Usando transações com DDL

 

--CENARIO1-------------------------------------------------

--Transação com instruções DDL

--A instrução insert causa erro de integridade referencial,

--acarretando em rollback em TODAS as instruções.

-----------------------------------------------------------

begin tran

 

     create table tb_mae(codigo     int identity,

                        campo1    char(1))    

 

 

      alter table tb_mae add constraint pk_mae primary key(codigo) 

 

      create table tb_filha( codigo    int identity,

                             campo1  char(1),

                             mae        int)   

 

      alter table tb_filha add constraint pk_filha primary key(codigo)     

 

      insert into tb_filha(campo1,mae)

            values ('S',1)

 

      alter table tb_filha add constraint fk_mae_filha

            foreign key(mae) references tb_mae(codigo)  

&nbs

...

Introdução ao Analysis Services 2005 – Parte 3

Por Reydeval Rocha

 

 

Olá pessoal,

 

Hoje apresentarei o modelo de dados que será utilizado no nosso exemplo Analysis Services.

 

 

Modelo de Dados

 

O modelo simplificado utilizado possui 4 tabelas de dimensão, também conhecidas como lookups, e uma tabela de fatos que consolida dados sobre vendas, meta de vendas, lucro líquido, comissão e desconto. A modelagem utilizada é star schema. A figura 1.0 ilustra o modelo utilizado.

 

 

 

Populando a estrutura

 

Abaixo estão os scripts para preencher a estrutura de dados. Cada instrução encontra-se devidamente comentada.

 

----------------------------------------------------------------

--Criação das lookups - tabelas de DIMENSÃO

----------------------------------------------------------------

 

--Dimensão ESTADO

create table lk_estado(codigo                 integer          identity,

                           descricao                 varchar(100))

 

alter table lk_estado add constraint pk_estado primary key (codigo)

go

 

--Dimensão LOJA

create table lk_loja(codigo            integer          identity,                                                      

                       descricao  varchar(100))

 

alter table lk_loja add constraint pk_loja primary key (codigo)

go

 

--Dimensão VENDEDOR

create table lk_vendedor(codigo             integer          identity,

                                descricao   varchar(100))

 

alter table lk_vendedor add constraint pk_vendedor primary key (codigo)

go

 

 

--Dimensão PERÍODO

create table lk_periodo(data_venda         datetime       not null)

 

alter table lk_periodo add constraint pk_periodo primary key (data_venda)

go

 

-----------------------------------------------------

--Criação da tabela de FATO

-----------------------------------------------------

 

create table ft_fato1(loja                       integer          not null,

                        estado              integer not null,

                        vendedor           integer not null,

                        data_venda                 datetime not null,

                        vendas              decimal(12,2),

                        meta_vendas              decimal(12,2),

                        lucro_liquido                decimal(12,2),

                        comissao           decimal(12,2),

                        desconto           decimal(12,2))

 

alter table ft_fato1

   add constraint pk_fato1 primary key (loja,estado,vendedor,data_venda)

go

 

alter table ft_fato1

   add constraint fk_fato1_loja foreign key (loja)

      references lk_loja(codigo)

go

 

alter table ft_fato1

   add constraint fk_fato1_estado foreign key (estado)

      references lk_estado(codigo)

go

 

alter table ft_fato1

   add constraint fk_fato1_vendedor foreign key (vendedor)

      references lk_vendedor(codigo)

go

 

alter table ft_fato1

   add constraint fk_fato1_periodo foreign key (data_venda)

      references lk_periodo(data_venda)

go

 

----------------------------------------------------------------

--Instruções DML para popular a base de dados

----------------------------------------------------------------

 

--Preenchendo a lookup de ESTADO

insert into lk_estado(descricao)

  values  ('Bahia')

...

Introdução ao Analysis Services 2005 – Parte 2

Por Reydeval Rocha

 

Olá pessoal!!!

 

Dando continuidade à nossa série sobre o Analysis Services, trataremos hoje sobre modelagem multidimensional, star schema e snowflake schema, além de falarmos sobre as formas OLAP existentes.

 

Modelagem Multidimensional

 

Técnica de modelagem utilizada para representar as diferentes visões pelas quais um mesmo conjunto de informações pode ser analisado. A modelagem multidimensional visa facilidade de entendimento e desempenho nos acessos aos dados. Existem duas formas básicas de representar um modelo multidimensional usando bancos de dados relacionais: star schema (esquema estrela) e snowflake schema (esquema floco de neve). Vejamos a seguir.

 

Star Schema

 

É composto de uma tabela central, com chave composta, chamada tabela fato, e um conjunto de tabelas menores e periféricas, chamadas tabelas dimensões.

 

 

Tabelas de Fato

 

Corresponde à tabela central que reúne o conjunto de medidas que podem ser analisadas através de várias visões e que contribuem para apurar o resultado de um processo de interesse ou para sinalizar tendências e oportunidades de negócio.

 

 

 

Os campos vendas, comissão e desconto, na parte inferior da tabela fato, são chamados de métricas ou medidas. Tais campos possuem dados numéricos dos quais podem derivar diferentes informações dependendo da visão empregada sobre os mesmos.

 

Tabelas de Dimensão

 

São perspectivas através das quais uma ou mais medidas da tabela fato podem ser analisadas. Uma dimensão é composta por atributos, altamente correlacionados, e é identificada através de um atributo chave.

 

 

 

Snowflake Schema

...

Introdução ao Analysis Services 2005 – Parte 1

Por Reydeval Rocha

 

 

Olá pessoal!!!

 

É bom estar de volta! Estaremos iniciando uma série de artigos sobre o Analysis Services 2005 que culminará com um cenário para a construção de uma aplicação de exemplo. Espero que aproveitem os recursos dessa poderosa ferramenta para construção de análises gerenciais. Vamos lá.

 

 

Introdução

 

O Microsoft SQL Server Analysis Services (SSAS) é uma ferramenta de processamento analítico - OLAP -  utilizada para integração de dados relacionais. Através do SSAS é possível criar soluções de business intelligence e data mining de uma forma fácil, interativa e a um custo muito inferior de outras ferramentas OLAP consagradas.

 

 

Conceitos

 

Antes de iniciarmos os trabalhos com o SSAS é necessário a explanação de alguns conceitos que serão bastante utilizados ao longo desta série de artigos.

 

Data Warehouse

...

Compartilhando dados entre Procedures Aninhadas no SQL Server 2000

por Reydeval Rocha

 

Olá Pessoal!

 

Há certas situações em que se faz necessário acessar um conjunto de resultados, a partir de uma procedure “B’, pertencentes à uma procedure “A”. Nessa suposição a procedure “A” é quem chama a procedure “B”. Vamos lá.

 

Tabelas temporárias

 

Ao criar tabelas temporárias numa procedure todos os triggers ou procedures que forem chamados a partir dela também obterão acesso às tabelas temporárias. Esse comportamento pode ser útil em diversas situações onde se deseja compartilhar dados ou conjuntos de resultados entre duas stored procedures ou entre uma stored procedure e um trigger. Vale ressaltar que não é necessário criar tabelas temporárias globais, que se obtém usando ##NOME_TABELA_TEMPORÁRIA ao invés de #NOME_TABELA_TEMPORÁRIA, para que o comportamento descrito possa ser utilizado.

 

Vamos utilizar um exemplo meramente didático, sem valor real. Criaremos uma procedure que fará uso de uma tabela temporária e em seguida chamará uma segunda procedure. De dentro dessa segunda procedure “enxergaremos” os dados da tabela temporária criada anteriormente e atualizaremos alguns dados nesta. De volta à primeira stored procedure é só acessar os dados da tabela temporária atualizados.

 

Vamos ao exemplo:

 

--Criando uma tabela de usuários

create table tb_usuario(

                            codigo                    integer          identity,

                            nome                     varchar(100),

                            login                      varchar(10),

                            data_desativaçao     datetime)

 

alter table tb_usuario add constraint pk_usuario primary key (codigo)

go

 

--Populando a tabela de usuários

insert into tb_usuario(nome,login,data_desativacao)

  values ('Paulo','psantos',null)

 

insert into tb_usuario(nome,login,data_desativacao)

  values ('Andre','arocha',null)

 

insert into tb_usuario(nome,login,data_desativacao)

  values ('Ana','apassos',null)

 

insert into tb_usuario(nome,login,data_desativacao)

  values ('Joao','jpereira','03/09/2007')

 

insert into tb_usuario(nome,login,data_desativacao)

  values ('Ricardo','rsouza','01/01/2007')

 

...

Variáveis Table no SQL Server 2000

por Reydeval Rocha

 

Olá Pessoal!

 

Continuando a linha de artigos rápidos e úteis mostraremos hoje o recurso de variáveis table no SQL Server 2000.

 

Variáveis Table

 

Variáveis table são um tipo de dados especial. Pode-se através deste tipo, declarar variáveis locais que armazenam conjuntos de resultados para processamento posterior. Funcionam como uma tabela temporária. Entretanto, ao invés de serem armazenadas no banco de sistema TEMPDB (onde ficam as tabelas temporárias), são armazenadas em memória. As restrições do uso de variáveis table são em comandos SELECT/INTO e INSERT/EXEC.

 

Usar variáveis table em stored procedures gera menos recompilações do que as versões usando tabelas temporárias. Além disso, como as variáveis são armazenadas em memória, geram menos retenção no TEMPDB. Isso faz com que o SQL Server gaste menos recursos com locking. A recomendação é: use variáveis table, ao invés de tabelas temporárias, sempre que possível. Como as variáveis table possuem escopo local, são destruídas tão logo a stored procedure, o trigger ou o script onde forem definidas finalizar.

 

Vamos a um exemplo de utilização de variáveis table. A procedure abaixo declara uma variável table, preenche-a com valores e em seguida realiza um select. Este simples exemplo mostra que a utilização das variáveis table é muito semelhante ao uso de tabelas temporárias.

 

Vejamos o cenário abaixo:

 

--Criação de stored procedure para demonstração do uso de variáveis table

create procedure up_usa_variavel_table

as

         --Declaração da variável table      

         declare @ltb_tabela1 table(codigo  integer          identity,

                                         objeto       varchar(100),

...

Campos calculados no SQL Server 2000

por Reydeval Rocha

 

 

Olá Pessoal!

 

Mais um super rápido e útil artigo. Campos calculados no SQL Server 2000.

 

O recurso de campos calculados ou computados no SQL Server 2000 é extremamente útil em situações que são necessários muitos cálculos na aplicação, em stored procedures ou triggers. Através deste recurso é possível criar um cálculo na definição da tabela. Essa definição fica associada a qualquer operação de insert ou update. Os valores são atualizados nos campos calculados sem intervenção do usuário. Na verdade o campo criado através de um determinado cálculo não pode ser manipulado diretamente.

 

Imagine uma tabela que guarde prestações de serviços juntamente com os valores. A tabela precisa guardar também o valor do imposto iss retido para cada fornecedor. Para facilitar a visualização dos dados em relatórios futuros, criaremos também um campo contendo o valor líquido que será o cálculo do valor da prestação de serviço menos o valor do iss. Vamos ao exemplo.

 

Vejamos o cenário abaixo:

 

 

--Criação da tabela com a definição dos campos calculados

CREATE TABLE tb_fornecimento_servico

   (

    codigo                integer                   identity,

    fornecedor          varchar(100),

    serviço               varchar(100),

    valor_servico       decimal(12,2),        

    iss           as valor_servico * 0.05, --Cálculando o valor do ISS

    valor_liquido        as valor_servico - (valor_servico * 0.05),--valor líquido

    data_insercao      as getdate(),    --Setando default para a data de inserção

    usuario_insercao  as suser_sname()) --Setando default para o usuário que inseriu

 

...

Reposicionando valores de campos identity

por Reydeval Rocha

 

 

Olá pessoal! Feliz Ano Novo! Desejo um 2007 como muita saúde e muito código pra todo mundo! Hoje trataremos de um assunto que vez por outra precisamos ter contato. Como reposicionar os valores de um campo identity. Vamos começar os trabalhos.

 

 

Como reposicionar um campo identity

 

Há situações em que desejamos reposicionar o valor de um campo identity. Por exemplo, suponha que inserimos três registros numa tabela cuja chave primária seja um campo identity. Após as inserções, excluímos o registro com o campo código de valor 3 (valor da chave primária). Se agora inserirmos outro registro, o valor 3 não será mais aproveitado. O valor do campo código "pulará" para o valor 4. Como fazer  para voltarmos ao valor 3?

 

Vejamos o cenário abaixo:

 

--Criando a tabela tb_tabela

create table tb_tabela (      codigo          integer          identity,

                                      nome            varchar(100),

                                      sobrenome     varchar(100))

go

 

alter table tb_tabela add constraint pk_tabela primary key(codigo)

go

 

 

--Realizando os inserts

insert into tb_tabela (nome,sobrenome)

  values ('Pedro','Rocha')

 

insert into tb_tabela (nome,sobrenome)

  values ('Sandra','Rocha')

 

insert into tb_tabela (nome,sobrenome)

  values ('Reydeval','Rocha')

 

Vejamos os dados inseridos

 

select * from tb_tabela

 

...

Auditoria usando Alertas no SQL Server 2000

por Reydeval Rocha

 

Olá leitores!

 

Hoje mostraremos uma estratégia de auditoria de dados envolvendo a criação de triggers, mensagens de erro definidas pelo usuário, alertas e operadores no SQL Server 2000. O artigo está bastante interessante e útil. Espero que aproveitem. Vamos lá!

 

Necessidade de auditar ações do usuário

 

Há situações no dia a dia de um DBA em que é necessário auditar as atividades realizadas no banco de dados como por exemplo: o quê foi alterado, quando foi alterado, por quem foi alterado, etc. Uma estratégia interessante é a criação de um alerta que monitore a ocorrência de um dado evento, definido pelo usuário como erro, a ser disparado por um trigger.

 

Nossa estratégia será montada sobre os seguintes passos:

 

è        Criação de uma tabela de log que conterá informações sobre as ações realizadas;

è        Criação da mensagem de erro definida pelo usuário;

è        Criação do trigger para disparar a mensagem de erro. O trigger deve ser definido na tabela de usuário que se quer monitorar;

è        Criação do operador que receberá a mensagem;

è        Criação do alerta para monitorar a mensagem de erro definida no passo 2. O alerta usará o serviço mensageiro do Windows para entregar a mensagem.

 

Sendo assim, segue abaixo o desenho da nossa estratégia:

 

Resumindo:

 

è        O usuário realiza a ação inserindo, alterando ou excluindo dados de uma determinada tabela (devem ser definidas quais as tabelas que serão monitoradas)

è        O trigger da ação em questão, insert, update ou delete, gera uma entrada na tabela de log além de disparar a mensagem de erro que será capturada pelo alerta.

è        O alerta verifica que a mensagem de erro definida pelo usuário chegou no log de eventos do windows e dispara a mensagem de alerta para o operador definido anteriormente.

 

Criando a estratégia

 

Vamos iniciar criando a tabela tb_tabela, que será monitorada, e a tabela de log, tb_log. Seguem os scripts:

 

 

--Tabela TB_TABELA que será monitorada

Create table tb_tabela (codigo      integer          identity,

            &nbs

...

Gerenciando a segurança no SQL Server 2000 – Parte 2

por Reydeval Rocha

 

 

Oi pessoal!

 

Neste artigo final, veremos a criação de cargos definidos pelo usuário, atribuições de permissões de instruções e permissões de objetos finalizando assim nosso capítulo sobre segurança no SQL Server 2000.

 

 

Cargos definidos pelo usuário

 

Em certas situações necessitamos reunir um grupo de permissões e atribuí-las a usuários com o mesmo perfil de atividades. Nesses casos indicam-se a criação de cargos, perfis, definidos pelo usuário. Após a criação do cargo, basta atribuir as permissões desejadas e em seguida adicionar os usuários. O gerenciamento de permissões a grupos de usuários, cargos, é muito mais efetivo e simples do que para cada usuário individual. Isso reduz a carga de trabalho administrativo do DBA liberando-o para outras atividades.

 

 

Criando cargos definidos pelo usuário

 

Para gerenciar cargos definidos pelo usuário utilizaremos duas stored procedures:

 

Procedimento

Descrição

...

Gerenciando a segurança no SQL Server 2000 – Parte 1

por Reydeval Rocha

 

 

Olá pessoal!

 

Iniciaremos hoje um dos mais importantes capítulos na vida profissional de um DBA: gerenciamento da segurança.

                                                                                                   

Objetivando o aprendizado, apresentaremos os aspectos de segurança do SQL Server 2000 em duas partes.

 

Na parte 1, aprenderemos sobre: criação de logins, criação de users, associação de logins e users a cargos de servidor e de bancos de dados.

 

No artigo final, veremos a criação de cargos definidos pelo usuário, atribuições de permissões de instruções e permissões de objetos.

 

Mãos à obra!

 

Contas de Login e contas de usuário (user)

 

O processo de autenticação no SQL Server 2000 ocorre em duas etapas: autenticação login, onde o SQL Server verifica se o usuário tem permissão para acessar o servidor de banco de dados, e validação das permissões, processo no qual o SQL Server verifica se o usuário possui permissões para acessar um objeto específico dentro de um banco de dados. Portanto, não basta apenas “entrar”, ter acesso ao servidor. È preciso ter permissão de acesso nos objetos de cada banco de dados do servidor em questão.

 

Para conectar-se a um servidor SQL Server 2000, um usuário pode usar autenticação windows ou autenticação SQL Server. Na primeira abordagem o SQL Server “confia” no sistema operacional, windows NT / 2000 / 2003, e não solicita login e senha ao usuário que deseja conectar-se ao servidor de banco de dados. Isso ocorre porque o SQL Server parte do pressuposto de que o Sistema Operacional já realizou o processo de autenticação quando do login do usuário na rede. É importante lembrar que essa estratégia de autenticação, conhecida como Trusted Connection – conexão confiável, só pode ser utilizada quando a totalidade dos clientes forem windows.

 

A outra estratégia de autenticação permitida no SQL Server 2000 é a autenticação SQL. Nessa abordagem o SQL Server solicita um login e uma senha ao usuário que deseja se conectar. É um mecanismo muito utilizado quando os clientes da rede não são 100% windows ou quando há clientes Internet.

 

 

Selecionando o modo de autenticação

 

No Enterprise Manager é possível configurar o modo de autenticação para Modo Misto (Windows ou SQL Server) ou Modo Autenticação Windows. Para tanto, basta clicar com o botão direito do mouse no servidor de banco de dados desejado e em seguida escolher a opção propriedades. Na aba Security, selecione a opção de autenticação desejada.


Figura 1.0 - Selecionendo um modo de autenticação.

Criando contas de login do Windows no SQL Server 2000

 

Quando a estratégia usada for autenticação windows, o gerenciamento das contas de login de usuários ou grupos de usuários do windows NT / 2000 / 2003 dentro do SQL Server será feito pelas procedures:

 

Procedimento

Descrição

...

Atenção ao usar UNIONS!

 

Olá leitores da SQLMagazine! Hoje apresentaremos mais um operador que pode ser utilizado em conjunto com a instrução SELECT: o operador UNION.

 

A função deste operador é combinar os resultados de duas ou mais consultas em um único conjunto de resultados. Algumas regrinhas precisam ser atendidas para que instruções SELECT com UNION possam funcionar. Vejamos quais são:

 

ü       O número de colunas no conjunto de resultados deve ser o mesmo em todas as instruções SELECT

 

ü       A ordem das colunas no conjunto de resultados deve ser a mesma em todas as instruções SELECT

 

ü       O tipo das colunas de uma instrução SELECT deve ser compatível com o tipo das colunas, das outras instruções SELECT, nas posições correspondentes.

 

Para demonstrar o uso do operador UNION, utilizaremos um pequeno conjunto de tabelas conforme o DER abaixo:

Na tabela de pedidos, tb_pedido, existe um campo, flg_situação_pedido, que indica o estado atual de cada pedido. Aprovado - “A”, Cancelado - “C”, Pendente - “P” ou Finalizado - “F”.  O conjunto de resultados abaixo mostra a situação dos variados pedidos existentes na base de dados. 

Imagine que seja necessário gerar um conjunto de resultados único de acordo com variados critérios de pesquisa. Uma opção é utilizar várias instruções INSERT/SELECT numa tabela temporária. Cada instrução INSERT/SELECT deve ter um critério de pesquisa específico. Isso justifica a existência de várias instruções. Após todas as instruções INSERT/SELECT teremos na tabela temporária o resultado final com todas as linhas desejadas.

 

Outra forma de implementar tal conjunto de resultados único é utilizando várias instruções SELECT combinadas com o operador UNION. Mostrarei abaixo as duas abordagens.

 

Usando INSERT/SELECT

 

Inicialmente vamos criar uma tabela temporária para guardar os dados gerados pelas instruções INSERT/SELECT. O comando abaixo cria tal tabela:

 

create table #tmp_resultados_insert(

                                      codigo                    integer         identity,

                                               tipo_produto           varchar(50),

                                               produto                           varchar(50),

                                               situacao_pedido       varchar(50),

                                               total_qtde              integer)

 

 

 

Em seguida, iremos preencher a tabela #tmp_resultados_insert com as instruções INSERT/SELECT:

 

--Inserindo os dados na #tmp_resultados usando inserts individuais

insert into #tmp_resultados_insert(tipo_produto,produto,situacao_pedido,total_qtde)

 SELECT TP.DESCRICAO AS TIPO_PRODUTO,

         P.DESCRICAO AS PRODUTO,

         case ped.flg_situacao_pedido

                   when 'A' then 'Aprovado'

                   when 'F' then 'Finalizado'

                   when 'C' then 'Cancelado'

                   when 'P' then 'Pendente'

         end as SITUACAO_PEDIDO,

        ip.qtde as TOTAL_QTDE_PEDIDO

  from tb_tipo_produto tp,

       tb_produto p,

       tb_itens_pedido ip,

       tb_pedido ped

where tp.codigo = p.tipo_produto and

      p.codigo = ip.codigo_produto and

      ped.codigo = ip.codigo_pedido and   

      ped.flg_situacao_pedido = 'A'   -- Estado do pedido: APROVADO  

 

insert into #tmp_resultados_insert(tipo_produto,produto,situacao_pedido,total_qtde)

 SELECT TP.DESCRICAO AS TIPO_PRODUTO,

         P.DESCRICAO AS PRODUTO,

         case ped.flg_situacao_pedido

                   when 'A' then 'Aprovado'

                   when 'F' then 'Finalizado'

                   when 'C' then 'Cancelado'

                   when 'P' then 'Pendente'

         end as SITUACAO_PEDIDO,

        ip.qtde as TOTAL_QTDE_PEDIDO

  from tb_tipo_produto tp,

       tb_produto p,

       tb_itens_pedido ip,

       tb_pedido ped

where tp.codigo = p.tipo_produto and

      p.codigo = ip.codigo_produto and

      ped.codigo = ip.codigo_pedido and   

      ped.flg_situacao_pedido = 'P'  and  -- Estado do pedido: PENDENTE

      ped.data_pedido >= '01/09/2006' and

      ped.data_pedido <= '10/10/2006'     

 

insert into #tmp_resultados_insert(tipo_produto,produto,situacao_pedido,total_qtde)

 SELECT TP.DESCRICAO AS TIPO_PRODUTO,

         P.DESCRICAO AS PRODUTO,

         case ped.flg_situacao_pedido

                   when 'A' then 'Aprovado'

                   when 'F' then 'Finalizado'

                   when 'C' then 'Cancelado'

                   when 'P' then 'Pendente'

         end as SITUACAO_PEDIDO,

        ip.qtde as TOTAL_QTDE_PEDIDO

  from tb_tipo_produto tp,

       tb_produto p,

       tb_itens_pedido ip,

       tb_pedido ped

where tp.codigo = p.tipo_produto and

      p.codigo = ip.codigo_produto and

      ped.codigo = ip.codigo_pedido and   

      ped.flg_situacao_pedido = 'C'  and -- Estado do pedido: CANCELADO

...

Totalizando dados usando os operadores ROLLUP e CUBE no SQLServer 2000

Reydeval Rocha

 

Introdução

 

Quando trabalhamos com data warehouses, business intelligences ou simples relatórios gerenciais, freqüentemente precisamos criar totais, subtotais ou agrupamentos para que as informações sejam, sumarizadas.

 

Um modelo bastante utilizado é criar um select que retorne os dados para que a aplicação faça os agrupamentos necessários. Outra abordagem é a criação de stored procedures que retornem as informações num formato desejado.

 

Os operadores ROLLUP e CUBE podem, em alguns casos, ser utilizados para suprir a necessidade de totalizações fornecendo as informações desejadas com apenas um select. Vejamos um exemplo a seguir.

 

Seja a tabela vendas_veículos contendo as informações dos veículos vendidos numa dada revendedora. A tabela possui os campos: veiculo, cor e o valor do veículo. A instrução select * from vendas_veículos retorna os dados abaixo:

 

 

Figura 1 – resultset da tabela vendas_veiculos

 

 

Operador ROLLUP

 

Imagine agora que você precisa criar um relatório que totalize esses dados mostrando as seguintes informações:

 

ü      Total vendido de cada veículo (independente da cor)

ü      Total geral

 

O operador ROLLUP pode ser utilizado da seguinte forma:

 

SELECT CASE

                 WHEN (GROUPING(veiculo) = 1) THEN 'Total'

                     ELSE ISNULL(veiculo, 'NÃO INFORMADO')

               END AS veiculo,

              CASE

                     WHEN (GROUPING(cor) = 1) THEN 'Total'

                     ELSE ISNULL(cor, 'NÃO INFORMADO')

...

Boas Vindas - Reydeval Rocha

 

Olá a todos!

Quero dizer da imensa alegria e grande satisfação que inicio como colunista
do portal SQLMagazine. Discutiremos aqui aspectos sobre administração e
implementação de bancos de dados SQLServer. Também enfocarei temas como data
warehouses, extração de dados, business intelligence e dicas interessantes
sobre erros comuns de programação em SQL.

O primeiro artigo será "Totalizando dados usando os operadores Rollup e Cube
no SQLServer 2000". Espero que gostem do artigo. Comentários, dúvidas e
sugestões serão bem-vindos.

Tenham uma ótima leitura!

-->">