Administraçao e Desenvolvimento - Curso Completo PDF

É proibido o uso deste material em Sala de Aula e Para Ministrar Treinamentos!!!
SQL SERVER 2005 ADMINISTRAÇÃO E DESENVOLVIMENTO

Copyright © 2005 by Júlio Battisti
Copyright © 2005 by Axcel Books do Brasil Editora Ltda.
Nenhuma parte desta publicação poderá ser reproduzida

sem autorização prévia e escrita de Axcel Books do Brasil Editora.
Editora de Produção: Gisella Narcisi

Editor Responsável: Ricardo Reinprecht
SQL Server 2005 Administração e Desenvolvimento Curso Completo

Júlio Battisti
ISBN: 85-7323-249-8
Suporte Técnico ao Leitor

Limite de garantia: Nosso suporte técnico limita-se ao conteúdo específico do livro, e não a
questões gerais referentes ao(s) software(s) descrito(s), cessando caso esta publicação
tenha sido esgotada. Para obter esse suporte técnico específico, o leitor deve
informar título, autor e página, somente via e-mail.
Todos os originais de livros enviados para avaliação pela Editora serão destruídos,
caso não sejam aprovados. Não será feita sua devolução em nenhuma hipótese.
Os conceitos emitidos nesta obra são de inteira responsabilidade do Autor.
E-mail:
editora@axcel.com.br
Visite nossa Home Page

http://www.axcel.com.br
Axcel Books do Brasil Editora

Av. Paris, 571 – Bonsucesso
21041-020 – Rio de Janeiro – RJ
Tel. (21) 564-0085
II00✦00Curso Completo
SUMÁRIO
CRÉDITOS
PRODUÇÃO
Alberto Baptista Garcia, Carlos Alberto Sá Ferreira,
Fagner Silva Henrique, Ingo Bertelli e Marcio Teixeira de Mello
REVISÃO
Sandro Gomes
ARTE E DIAGRAMAÇÃO
Ingo Bertelli
SUPERVISOR DE PRODUÇÃO
Carlos Alberto Sá Ferreira
CAPA
Ingo Bertelli
EDITORA DE PRODUÇÃO
Gisella Narcisi
EDITOR RESPONSÁVEL
Ricardo Reinprecht
Curso Completo00✦00III
Nota sobre direitos autorais:

Este e-book é de autoria de Júlio Battisti, sendo comercializado diretamente através do site
www.juliobattisti.com.br ou através do site de leilões Mercado Livre:
www.mercadolivre.com.br, mediante contato através do email: batisti@hotmail.com ou
webmaster@juliobattisti.com.br, diretamente pelo autor. No Mercado Livre, somente o
usuário GROZA (meu apelido no Mercado Livre) é que tem autorização para comercializar
este e-book. Nenhum outro usuário/email e/ou empresa está autorizada a
comercializar este ebook.
Ao adquirir este ebook você tem o direito de lê-lo na tela do seu computador e de imprimir
uma cópia para uso pessoal. É vetada a distribuição deste arquivo, mediante cópia ou
qualquer outro meio de reprodução, para outras pessoas. Se você recebeu este ebook
através do e-mail ou via ftp de algum site da Internet, ou através de um CD de Revista,
saiba que você está com uma cópia pirata, ilegal, não autorizada, a qual constitui crime de
Violação de Direito Autoral, de acordo com as Leis 5988, 9118 e 9610. Se for este o caso
entre em contato com o autor, através do e-mail webmaster@juliobattisti.com.br, para
regularizar esta cópia. Ao regularizar a sua cópia você irá remunerar, mediante uma
pequena quantia, o trabalho do autor e incentivar que novos trabalhos sejam
disponibilizados. Se você tiver sugestões sobre novos cursos que gostaria de ver
disponibilizados, entre em contato pelo e-mail: webmaster@juliobattisti.com.br. Visite
periodicamente o site www.juliobattisti.com.br para ficar por dentro das novidades:
• Cursos de informática.
• Guias de Estudo para os Exames de Certificação da Microsoft.
• Artigos e dicas sobre Certificações da Microsoft.
• Artigos sobre Carreira e Trabalho.
• Dicas de livros e sites sobre diversos assuntos.
• Simulados gratuitos, em português, para os exames da Microsoft.
• ESTE E-BOOK NÃO PODE SER FORNECIDO EM UM CD

OU DVD DE NENHUMA REVISTA
• SE VOCÊ OBTEVE UMA CÓPIA DESTE E-BOOK
ATRAVÉS DO E-MULE, KAZAA, MORPHEUS OU
OUTRO PROGRAMA DE COMPARTILHAMENTO,
SAIBA QUE VOCÊ ESTÁ COM UMA CÓPIA ILEGAL,
NÃO AUTORIZADA, O QUE É CRIME, COM PENA
PREVISTA DE 2 A 5 ANOS DE CADEIA.
• USAR UMA CÓPIA NÃO AUTORIZADA É CRIME DE
VIOLAÇÃO DE DIREITOS AUTORAIS, COM PENA
PREVISTA DE CADEIA
• VOCÊ SÓ PODE USAR ESTE E-BOOK SE VOCÊ
COMPROU ELE DIRETAMENTE COM O AUTOR: JÚLIO
BATTISTI
PIRATARIA É CRIME, COM PENA DE CADEIA. EU

AGRADEÇO PELA SUA HONESTIDADE. SE VOCÊ
COMPROU UMA CÓPIA DESTE CURSO,
DIRETAMENTE EM
WWW.JULIOBATTISTI.COM.BR OU
DIRETAMENTE COM O AUTOR, NÃO DISTRIBUA
CÓPIAS PARA OUTRAS PESSOAS.
SE VOCÊ BAIXOU UMA CÓPIA DESTE ARQUIVO

USANDO UM SOFTWARE TAL COMO O E-MULE OU
O KAZAA, SAIBA QUE VOCÊ ESTÁ COM UMA
CÓPIA PIRATA, ILEGAL. USAR UMA CÓPIA
ILEGAL É CRIME DE VIOLAÇÃO DE DIREITOS
AUTORAIS.
ESTE ARQUIVO NÃO PODE SER DISTRIBUIDO

GRAVADO EM UM CD OU DVD DE REVISTA OU
LIVRO. A ÚNICA MANEIRA DE OBTER ESTE
ARQUIVO É COMPRANDO DIRETAMENTE COM O
AUTOR OU ATRAVÉS DO SITE
WWW.JULIOBATTISTI.COM.BR
SE VOCÊ RECEBEU UMA CÓPIA ILEGAL DESTE

ARQUIVO, NÃO ADQUIRIDA DIRETAMENTE
PELOS MEIOS DESCRITOS NO INÍCIO DA
PÁGINA, ENTRE EM CONTATO E REGULARIZE A
SUA CÓPIA.
AGRADECIMENTOS
Este livro tem um sentido bastante especial. Em épocas em que o mercado livreiro não anda dos mais
animados, lançar um livro deste porte é sempre um desafio. Um desafio tanto em termos de tempo
investido pelo autor, quanto em termos do esforço de investimento e divulgação que tem que ser feito
pela Editora. Por isso que gostaria de iniciar meus agradecimentos, com uma menção especial ao
amigo Ricardo, presidente da Axcel Books, o qual, mesmo em uma época de mercados não muito
animados, aposta em mais um trabalho deste autor.
Em seguida a equipe da Axcel que mais uma vez aposta em um trabalho de minha autoria, passando
pelos colegas de produção, edição, arte gráfica, revisão, enfim, uma equipe trabalhando muito para
que mais este livro chegue às mãos do amigo leitor. Eu poderia dizer, sem medo de errar, que hoje eu e
a Axcel não temos mais uma relação Autor – Editora, mas sim uma relação de parceria, buscando
sempre soluções satisfatórias para o autor, para a Editora mas, principalmente, para o amigo leitor.
À minha esposa Lu, pelo carinho, amor, dedicação, companheirismo e tolerância. Gostaria de deixar
registrado que aprendi muito e continuo aprendendo contigo. Tu és a pessoa que está sempre ao meu
lado, me apoiando e me ensinando. Em 2004, quando passastes por momentos delicados em relação a
tua saúde, demonstrastes uma coragem inimaginável. Mais uma vez me ensinastes como são pequenos
os desafios materiais e de trabalho do dia-a-dia, diante de problemas maiores, como os de saúde. Tenho
certeza de que após a tua cirurgia estamos ainda mais unidos, mais ligados nesta e em muitas outras
vidas. Que Deus te ilumine e ajude a realizar todos os teus sonhos. Um grande sonho já foi realizado,
com a tua formatura no dia 10-01-2005. Formatura que, em tantos momentos de incerteza, por questões
de saúde, não sabíamos ser iria acontecer. Mas o Grande Arquiteto dos Mundos assim o quis e, com a sua
bênção e com o teu esforço, conseguistes vencer mais esta batalha. És uma guerreira de coragem ímpar.
Cada vez admiro mais a tua coragem diante dos obstáculos da vida. Sei que não foram e não estão sendo
fáceis os momentos que passastes após a tua cirurgia para recuperação da tua saúde. Que Deus te dê toda
a saúde do mundo para que possamos criar nossos filhos que em breve virão a este mundo.
À dona Lucy, minha mãe, por sempre me apoiar e ser uma grande admiradora e incentivadora de tudo
o que faço. Por ter me dado como primeiro presente um livro, despertando em mim uma paixão
ardente de leitor, daqueles que sempre compra mais livros do que realmente pode ler. Por ter muito
orgulho do meu trabalho e por entender as vezes em que fico algumas semanas sem poder visitá-la em
minha terra natal, o nosso bom e velho Boqueirão do Leão.
Ao meu Pai, em memória, pelo jeito simples e pacato, que me ensinou a parar e refletir nos momentos
difíceis. Aos meus irmãos agradeço pelos bons momentos que juntos passamos.
Aos leitores que leram os outros livros de minha autoria e sempre entram em contato via e-mail, para solucionar
dúvidas, enviar sugestões, críticas e elogios. Agradeço a todos. Este retorno é muito importante, é um grande
motivador. Aos leitores que enviam e-mail com dúvidas e sugestões, a todos o meu mais sincero agradecimento.
A Deus por nos dar a inteligência, a capacidade de discernimento e a determinação na busca de cada
vez fazer as coisas de uma maneira melhor e mais simples, com o objetivo de ajudar mais e mais
pessoas. E que o Grande Criador e Arquiteto de tudo o que existe permita-me ainda muitos trabalhos,
permita-me sempre ajudar mais e mais pessoas a alcançar seus objetivos e a aprender um pouco mais
sobre cada um dos assuntos sobre os quais escrevo.
IV00✦00Curso Completo
SUMÁRIO
SOBRE O AUTOR
Júlio Battisti é profissional certificado da Microsoft, tendo sido aprovado em 31 exames da Microsoft,
com os quais obteve certificações como: MCP, MCP+I, MCSE 2000 e 2003, MCSE+I, MCDBA 2000,
MCSA 2000 e 2003, MCSD e MVP. É Técnico da Receita Federal, na Delegacia de Santa Maria – RS, e é
autor de dez livros, todos publicados pela Axcel Books. Também é autor de artigos sobre TI, Carreira,
Trabalho, Vida e Felicidade, publicados no site do autor: http://www.juliobattisti.com.br. Atua como
instrutor de cursos de informática tanto na Secretaria da Receita Federal como para turmas em
Universidades e outros cursos. Colunista de diversos sites da Internet e da revista Developers Maga-
zine. Você pode entrar em contato com o autor pelo e-mail: webmaster@juliobattisti.com.br.
Curso Completo00✦00V
Sumário
PARTE 1 – FUNDAMENTOS .............................................................................................................................. 1
CAPÍTULO 1: INTRODUÇÃO AOS BANCOS DE DADOS RELACIONAIS E À LINGUAGEM SQL ............................................. 3
Introdução .......................................................................................................................................................... 4
Fundamentos em: Conceitos Básicos
de Bancos de Dados Relacionais .............................................................................................................................. 6
Entidades e Atributos ..................................................................................................................................... 6
O Conceito de Chave Primária ...................................................................................................................... 9
Relacionamentos Entre Tabelas ........................................................................................................................ 11
Relacionamento do Tipo Um para Um ........................................................................................................ 12
Relacionamento do Tipo Um para Vários .................................................................................................... 13
Relacionamento do Tipo Vários para Vários ................................................................................................ 15
Integridade Referencial ................................................................................................................................ 15
Normalização de Tabelas ................................................................................................................................... 16
Primeira Forma Normal ................................................................................................................................ 17
Segunda Forma Normal ................................................................................................................................ 17
Terceira Forma Normal ................................................................................................................................. 18
Passos Para Projetar um Banco de Dados .......................................................................................................... 19
Fundamentos em: Noções Básicas da Linguagem
SQL – Structured Query Language ......................................................................................................................... 22
Introdução ........................................................................................................................................................ 22
A Instrução SELECT .......................................................................................................................................... 23
A Instrução UPDATE ......................................................................................................................................... 29
A Instrução INSERT ........................................................................................................................................... 31
A Instrução DELETE .......................................................................................................................................... 31
Conclusão ......................................................................................................................................................... 32
CAPÍTULO 2 – FUNDAMENTOS DO MICROSOFT SQL SERVER 2005 ....................................................................... 35
Introdução ........................................................................................................................................................ 36
Fundamentos em: Modelo de Aplicações
Para a Era do Comércio Eletrônico ........................................................................................................................ 37
Fundamentos em: Arquitetura de Aplicações ....................................................................................................... 43
A Complexidade de Gerenciamento do Modelo
Cliente/Servidor e Aplicações de Duas Camadas .............................................................................................. 43
Aplicações em Duas Camadas ........................................................................................................................... 44
Aplicações em Três Camadas ............................................................................................................................ 45
Aplicações em Quatro Camadas ....................................................................................................................... 46
Questões a Considerarmos nos
Modelos de Três ou Mais Camadas ................................................................................................................... 48
Fundamentos em: As Principais Novidades e
Melhoramentos do Microsoft SQL Server 2005 .................................................................................................... 48
Novidades e Melhorias do Banco de Dados ...................................................................................................... 49
Novidades no Desenvolvimento de Aplicações ........................................................................................... 49
Novidades no Gerenciamento da Máquina de Banco de Dados do SQL Server 2005 ................................. 51
Novidades que melhoram o tempo de UpTime do SQL Server 2005 .......................................................... 52
Outras Novidades da Máquina de Banco de Dados do SQL Server 2005. ................................................... 53
Novidades e Melhorias das Ferramentas
e Utilitários de Administração .......................................................................................................................... 53
VI00✦00Curso Completo
SUMÁRIO
Fundamentos em: Instalação do Microsoft SQL Server 2005 ............................................................................... 55
As Diferentes “Edições” do Microsft SQL Server 2005 ..................................................................................... 55
Requisitos de Hardware e Software Para a Instalação do SQL Server 2005 ...................................................... 56
Recomendações de segurança, antes Instalação do SQL Server 2005 .............................................................. 58
Nomeando as Instâncias do SQL Server 2005 .................................................................................................. 59
Instalando o SQL Server 2005 no Windows Server 2003 ................................................................................. 60
A Estrutura de Pastas e Arquivos do SQL Server 2005 ...................................................................................... 69
Criando uma Segunda Instância do SQL Server Developer Edition ................................................................. 70
Fazendo o Upgrade do SQL Server 2000 Para o SQL Server 2005 .................................................................... 75
Fundamentos em: Serviços Disponíveis com o SQL Server 2005 ......................................................................... 80
O Serviço “SQL Server” ..................................................................................................................................... 81
O Serviço “SQL Server Agent” ........................................................................................................................... 83
O Serviço Microsoft Distributed Transaction Cordinator – MSDTC ................................................................ 83
O Serviço Microsoft Search ............................................................................................................................... 84
O Serviço Microsoft Report Services ................................................................................................................. 84
O Serviço Analysis Services ............................................................................................................................... 84
Fundamentos em: Gerenciamento dos Serviços do SQL Server 2005 ................................................................... 85
Um Pequeno Parênteses Para Aprender Sobre MMC e Snap-ins ...................................................................... 85
Utilizando o Snap-in Service Manager – O Console Serviços ........................................................................... 91
Utilizando o Console SQL Computer Manager, que vem com o SQL Server 2005 ......................................... 95
Conclusão ......................................................................................................................................................... 97
CAPÍTULO 3 – TRABALHANDO COM BANCO DE DADOS NO MICROSOFT SQL SERVER 2005 .................................... 101
Introdução ...................................................................................................................................................... 102
Fundamentos em: Utilização do SQL Server Management Studio ..................................................................... 103
Fundamentos em: Armazenamento Básico x Armazenamento Dinâmico ......................................................... 121
Armazenamento Básico e Armazenamento Dinâmico ................................................................................... 122
Fundamentos em: A Estrutura de Armazenamento dos Bancos de Dados no SQL Server 2005 ........................ 126
Entendendo o Conceito de Filegroups ........................................................................................................... 127
Fundamentos em: Criar Bancos de Dados no SQL Server 2005 com o SQL Server Management Studio .......... 130
Verificação dos Arquivos Criados Para o Exemplo1 e para o Exemplo2 ........................................................ 138
Fundamentos em: Entender e Utilizar Comandos T-SQL ................................................................................... 139
Fundamentos em: Criação de Bancos de Dados Usando Comandos T-SQL ....................................................... 143
Fundamentos em: Alteração de Bancos de Dados Usando Comandos T-SQL .................................................... 150
Fundamentos em: Exclusão de Bancos de Dados com o Query Analyzer e com o Enterprise Manager ............ 153
Conclusão ....................................................................................................................................................... 155
CAPÍTULO 4 – CRIANDO TABELAS, ÍNDICES E VIEWS COM O SQL SERVER 2005 .................................................. 157
Introdução ...................................................................................................................................................... 158
Fundamentos em: Projeto de Banco de Dados e Tipos de Dados do SQL Server 2005 ....................................... 159
Algumas Dicas Para Definir os Tipos de Dados Para Uma Coluna ................................................................. 162
Fundamentos em: Criação de Tabelas com o SQL Server Management Studio .................................................. 163
Fundamentos em: Criação de Tabelas Usando Comandos T-SQL ...................................................................... 177
Fundamentos em: Alterar a Estrutura de uma Tabela com o SQL Server Management Studio .......................... 182
Fundamentos em: Alterar a Estrutura de uma Tabela com Comandos T-SQL .................................................... 183
Fundamentos em: Tipos de Dados Definidos Pelo Usuário ................................................................................ 185
Criando um Tipo de Dados Definido Pelo Usuário com o SQL Server Management Studio ........................ 186
Criando um Tipo de Dados Definido Pelo Usuário, Usando a Janela de Comandos T-SQL .......................... 191
Excluindo Tipos Definidos Pelo Usuário ........................................................................................................ 192
Fundamentos em: Exclusão de Tabelas ............................................................................................................... 194
Para Excluir uma Tabela com o SQL Server Management Studio .................................................................. 194
Curso Completo00✦00VII
Excluindo uma Tabela com o Query Analyzer ............................................................................................... 195
Fundamentos em: Definição da Chave Primária de uma Tabela ........................................................................ 195
Definindo uma Chave Primária Utilizando o SQL Server Management Studio ............................................ 196
Definindo uma Chave Primária Utilizando Comandos T-SQL ...................................................................... 198
Fundamentos em: Conceito e Criação de Índices ............................................................................................... 199
Uma Visão Geral dos Índices no SQL Server 2005 ......................................................................................... 200
Clustered Index ............................................................................................................................................... 200
Nonclustered Index ........................................................................................................................................ 203
Mais Algumas Questões Teóricas Sobre Índices .............................................................................................. 205
Criando Índices no SQL Server 2005 .............................................................................................................. 207
Criando um Clustered Index Simples com o SQL Server Management Studio ............................................. 207
Criando Índices Usando Comandos T-SQL .................................................................................................... 209
Um Fator Importante: FILLFACTOR OPTION ................................................................................................ 212
Fundamentos em: Comandos Adicionais Para Trabalhar com Índices ............................................................... 213
Excluindo Índices ........................................................................................................................................... 215
Excluindo um Índice com o Query Analyzer ................................................................................................. 215
Novidade do SQL Server 2005 – Desativação de Índices ................................................................................ 216
Conclusão ....................................................................................................................................................... 216
PARTE 2 – KNOW-HOW ............................................................................................................................. 219
CAPÍTULO 5 – APRENDENDO SOBRE TRANSAÇÕES, BACKUP E AGENDAMENTO DE TAREFAS ...................................... 221
Introdução ...................................................................................................................................................... 222
Know-how em: Conceito de Log de Transações no SQL Server 2005 ................................................................. 223
Um Pouco Mais Sobre o Conceito de Transação ............................................................................................ 224
Como Funciona o Log de Transações ............................................................................................................. 225
Know-how em: Tipos e Estratégias de Backup .................................................................................................... 226
Introdução ...................................................................................................................................................... 227
Métodos de Backup Quanto ao Conteúdo do Backup ................................................................................... 229
Tipos de Backup .............................................................................................................................................. 231
Alguns Exemplos de Estratégias de Backup/Restore ....................................................................................... 232
Know-how em: O Conceito Backup Devices e Criação de Backup Devices ........................................................ 236
O que são Backup Devices? ............................................................................................................................. 236
Devices Lógicos e Devices Físicos ................................................................................................................... 237
Criando um Backup Device Lógico com o SQL Server Management Studio ................................................. 238
Criando um Backup Device Lógico Usando Comandos T-SQL ...................................................................... 240
Excluindo Backup Devices .............................................................................................................................. 242
Know-how em: Fazer o Backup das Informações ................................................................................................ 244
Fazendo o Backup com o SQL Server Management Studio ............................................................................ 244
Fazendo o Backup do Log de Transações e Criando um Agendamento Para o Backup ................................. 249
Fazendo o Backup com o Query Analyzer ...................................................................................................... 254
Um Exemplo Mais Completo ......................................................................................................................... 258
Know-how em: Fazer o Restore das Informações ................................................................................................ 258
Fazendo o Restore com o SQL Server Management Studio ............................................................................ 260
Fazendo o Restore com o Query Analyzer ...................................................................................................... 263
Know-how em: Agendamento de Tarefas no SQL Server 2005 ........................................................................... 269
Criando um Job com o SQL Server Management Studio ............................................................................... 271
Conclusão ....................................................................................................................................................... 279
CAPÍTULO 6 – SEGURANÇA NO SQL SERVER 2005 ......................................................................................... 281
Introdução ...................................................................................................................................................... 282
Know-how em: Segurança no SQL Server 2005 .................................................................................................. 283
VIII00✦00Curso Completo
SUMÁRIO
Primeiro Precisamos Conectar com o Servidor SQL Server 2005 ................................................................... 283
Depois de Conectados, Precisamos de Permissões Para Acessar os Objetos do Banco de Dados ................... 288
Schemas – Principal Novidade de Segurança do SQL Server 2005 ................................................................. 291
Um Resumo da Teoria Sobre Segurança no SQL Server 2005 ......................................................................... 294
Know-how em: Segurança no Windows 2000 Server e Windows Server 2003 ................................................... 295
Domínios, Workgroups e Active Directory ..................................................................................................... 295
Domínios e Grupos de Trabalho (Workgroups) ......................................................................................... 295
Active Directory ......................................................................................................................................... 297
Contas de Usuários ......................................................................................................................................... 299
Grupos de Usuários e Tipos de Grupos Existentes
no Windows 2000 Server e no Windows Server 2003 .................................................................................... 303
Know-how em: Criação e Gerenciamento de Login e Roles no SQL Server 2005 .............................................. 311
Criando Logins com o SQL Server Management Studio ................................................................................ 312
Criando Logins com Comandos T-SQL .......................................................................................................... 317
Criando Roles no SQL Server 2005 ................................................................................................................. 324
Criando Novas Roles com o SQL Server Management StudioSQL Server 2005 ............................................. 326
Criando Novas Roles Usnado Comandos T-SQL ............................................................................................ 328
Know-how em: Configuração de Acesso aos Objetos de um Banco de Dados do SQL Server 2005 .................. 330
Dando Permissão de Acesso ao Banco de Dados com o SQL Server Management Studio ............................. 331
Dando Permissão de Acesso ao Banco de Dados, Usando Comandos T-SQL ................................................. 334
Adicionando Usuários Como Membros de uma ou Mais Roles ..................................................................... 336
Know-how em: Configuração, Planejamento e Teste de Permissões de Acesso aos Objetos
de um Banco de Dados do SQL Server 2005 ....................................................................................................... 341
Definindo Permissões em Nível de SERVIDOR\instância .............................................................................. 342
Dando Permissões Para Banco de Dados ........................................................................................................ 344
Dando Permissões a Objetos do Banco de Dados ........................................................................................... 352
Trabalhando com Schemas ............................................................................................................................. 360
Conclusão ....................................................................................................................................................... 364
CAPÍTULO 7 – ADMINISTRANDO, MONITORANDO E OTIMIZANDO O SQL SERVER 2005 ......................................... 365
Introdução ...................................................................................................................................................... 366
Know-how em: Criação de um Plano de Manutenção Para um Banco de Dados do SQL SERVER 2005 ........... 367
Know-how em: Comandos DBCC – Database Consistency Checker ................................................................. 376
Principais Comandos DBCC de Manutenção ................................................................................................. 376
Principais Comandos DBCC de Status ........................................................................................................... 383
Principais Comandos DBCC de Validação ..................................................................................................... 386
Mais um Comando DBCC .............................................................................................................................. 388
Know-how em: Importação e Exportação de Dados com o DTS – Data Transformation Services ..................... 389
Importando Dados de Outras Fontes de Dados .............................................................................................. 389
Exportando Dados do SQL Server 2005Para Outras Fontes de Dados ........................................................... 398
Know-how em: Monitoração de Desempenho no SQL SERVER 2005 ................................................................ 403
Monitorando o Processador e a Memória do seu Servidor ............................................................................. 407
Monitorando o Acesso ao Sistema de Discos .................................................................................................. 412
Contadores a Serem Monitorados em Servidores ........................................................................................... 415
Valores Indicativos de Limites de Desempenho Para Contadores ................................................................. 416
Configurando o Console Desempenho Para Capturar Dados Automaticamente .......................................... 418
Montando Gráficos de Desempenho a Partir de Informações de Arquivos de Log ....................................... 429
Utilizando Alertas Para Monitorar Situações Limite ...................................................................................... 433
Utilizando o Console Desempenho Para Monitorar o SQL Server 2005 ........................................................ 436
Utilizando o Profiler ....................................................................................................................................... 438
Curso Completo00✦00IX
Conclusão ............................................................................................................................................................ 446
CAPÍTULO 8 – REPLICAÇÃO: CONCEITO, IMPLEMENTAÇÃO E MANUTENÇÃO ........................................................... 447
Introdução ...................................................................................................................................................... 448
Know-how em: Fundamentos Básicos sobre Replicação ..................................................................................... 449
Fatores Ligados à Replicação ........................................................................................................................... 452
Benefícios da Replicação e Onde Utilizá-la ..................................................................................................... 453
Know-how em: O Modelo de Replicação do SQL Server 2005 ........................................................................... 454
Publisher ..................................................................................................................................................... 455
Distributor .................................................................................................................................................. 456
Subscriber ................................................................................................................................................... 457
Artigo .......................................................................................................................................................... 457
Publicações ................................................................................................................................................. 459
Know-how em: Subscrições e Tipos de Subscrições ............................................................................................ 460
Push Subscription ........................................................................................................................................... 461
Pull Subscriptions ........................................................................................................................................... 461
Know-how em: Tipos de Replicação .................................................................................................................... 462
Snapshot Replication ...................................................................................................................................... 462
Transactional Replication ............................................................................................................................... 463
Merge Replication ........................................................................................................................................... 464
Know-how em: Os Agentes de Replicação no SQL Server 2005 .......................................................................... 464
Know-how em: Configurando a Replicação no SQL Server 2005 ....................................................................... 466
Know-how em: Configuração e Administração de Publicações .......................................................................... 480
Know-how em: Habilitação de Subscribers ......................................................................................................... 482
Os Agentes Criados Para a Replicação em SERVIDOR\SQL2005 ................................................................... 493
Know-how em: Configurar Subscrições do Tipo Pull Subscriptions ................................................................... 498
Excluindo Elementos da Replicação ............................................................................................................... 505
Know-how em: Replicação Para Outros Tipos de Subscribers – Não SQL Server 2005 ....................................... 507
Replicando Dados Para um Subscriber do Microsoft Access .......................................................................... 509
Conclusão ....................................................................................................................................................... 520
CAPÍTULO 9 – DESENVOLVIMENTO NO SQL SERVER 2005 – ELEMENTOS BÁSICOS ................................................ 523
Introdução ...................................................................................................................................................... 524
Know-how em: Importando o Banco de Dados Pubs de uma Instância do SQL Server 2000 ............................ 525
Know-how em: Implementação de Integridade dos Dados no SQL Server 2005 ............................................... 528
Os Tipos de Integridade de Dados Existentes no SQL Server 2005 ................................................................ 532
Know-how em: Criação e Teste de Constraints no SQL Server 2005 .................................................................. 534
Criando Constraints com Comandos T-SQL .................................................................................................. 536
NOT NULL Constraint .................................................................................................................................... 536
DEFAULT Constraints ..................................................................................................................................... 537
CHECK Constraints ........................................................................................................................................ 538
PRIMARY KEY Constraints .............................................................................................................................. 540
UNIQUE Constraints ...................................................................................................................................... 542
FOREIGN KEY Constraints ............................................................................................................................. 542
Verificação dos Dados Quando uma Constraint é Adicionada ...................................................................... 546
Desabilitando e Habilitando Novamente Constraints ................................................................................... 547
Excluindo Constraints .................................................................................................................................... 547
Know-how em: Conceitos e Criação de Views no SQL Server 2005 ................................................................... 551
Introdução ...................................................................................................................................................... 551
Tipos de Views Quanto ao Conjunto de Dados Retornados .......................................................................... 552
Por que Utilizar Views? ................................................................................................................................... 553
X00✦00Curso Completo
SUMÁRIO
Limitações na Criação de Views ..................................................................................................................... 553
Criando Views com o SQL Server Management Studio ................................................................................. 554
Criando Views com o SQL Server Management Studio ................................................................................. 555
Exemplo Prático 01: Usando Views Para Criar Campos Calculados e Totalizações ....................................... 559
Exemplo Prático 02: Usando Views Para Criar Campos Calculados e Totalizações ....................................... 566
Exemplo Prático 03: Criando uma View Baseada em Outra View. ................................................................. 571
Criando Views com a Janela de Execução de Comandos T-SQL .................................................................... 574
Conclusão ....................................................................................................................................................... 577
PARTE 3 – DESENVOLVIMENTO .................................................................................................................... 579
CAPÍTULO 10 – DESENVOLVIMENTO NO SQL SERVER 2005 – STORED PROCEDURES E TRIGGERS ............................ 581
Introdução ...................................................................................................................................................... 582
Desenvolvimento em: Teoria e Desenvolvimento de Stored Procedures no SQL Server 2005 ........................... 583
Criando Stored Procedures ............................................................................................................................. 586
Criando Stored Procedures com a Janela de Execução de Comandos T-SQL ................................................. 586
Criando Stored Procedures com Parâmetros de Entrada ................................................................................ 588
Utilizando Estruturas de Decisão em um Stored Procedure ........................................................................... 592
A Estrutura IF...ELSE ........................................................................................................................................ 592
A Estrutura WHILE...CONTINUE .................................................................................................................... 595
Definindo Parâmetros de Saída (ou de Retorno) Para um Stored Procedure ................................................. 598
Excluindo um Stored Procedure ..................................................................................................................... 600
Criando Stored Procedures com o SQL Server Management Studio .............................................................. 600
Criando Stored Procedures com a Opção New Stored Procedures ................................................................. 600
Verificando Informações Sobre os Stored Procedures de um Banco de Dados .............................................. 602
O Comando sp_help ....................................................................................................................................... 602
O Comando sp_helptext ................................................................................................................................. 602
O Comando sp_stored_procedures ................................................................................................................. 603
Desenvolvimento em: Teoria e Desenvolvimento de Triggers no SQL Server 2005 ........................................... 603
Criando Triggers com Comandos T-SQL ........................................................................................................ 607
Criando Triggers com o SQL Server Management Studio .............................................................................. 614
Mais Alguns Comandos Relacionados com Triggers ...................................................................................... 615
O Comando sp_helptext ................................................................................................................................. 615
O Comando sp_helptrigger ............................................................................................................................ 616
Habilitando e Desabilitando Triggers ............................................................................................................. 616
Desenvolvimento em: Comandos Avançados da Linguagem T-SQL .................................................................. 617
Pesquisando Dados em Múltiplas Tabelas ...................................................................................................... 617
Tipos de Join ................................................................................................................................................... 619
Join com Mais do que Duas Tabelas ............................................................................................................... 621
Utilizando Subconsultas ................................................................................................................................. 623
Conclusão ....................................................................................................................................................... 625
CAPÍTULO 11 – DESENVOLVENDO APLICAÇÕES QUE ACESSAM DADOS NO SQL SERVER 2005 ................................. 627
Introdução ...................................................................................................................................................... 628
Desenvolvimento em: Uma Introdução ao Desenvolvimento de Aplicações em n Camadas ........................... 629
Modelo em Duas Camadas – Cliente/Servidor Tradicional ............................................................................ 629
Aplicações em Duas Camadas ......................................................................................................................... 630
Aplicações em Três Camadas .......................................................................................................................... 632
Aplicações em Quatro Camadas ..................................................................................................................... 633
Questões a Considerarmos nos Modelos de Três ou Mais Camadas .............................................................. 634
Desenvolvimento em: Preparação do Servidor Para Acompanhar os Exemplos Deste Capítulo ....................... 635
Criando a Pasta Onde Iremos Gravar os Exemplos Deste Capítulo ............................................................... 636
Curso Completo00✦00XI
Tornando a Pasta LivroSQL2005, Parte do Servidor IIS .................................................................................. 637
Desenvolvimento em: Um Pouco Sobre ODBC, OLE DB e ADO ........................................................................ 642
Um Pouco Sobre ODBC – Open Database Connectivity ................................................................................ 643
Criando uma Fonte ODBC Para um Banco de Dados do Microsoft Access ................................................... 644
Criando uma Fonte ODBC Para um Banco de Dados Pubs, da Instância SERVIDOR\SQL2005 .............. 648
Um Pouco Sobre OLE DB e ADO .................................................................................................................... 653
Desenvolvimento em: O Modelo de Objetos do ADO – Activex Data Objects .................................................. 655
Desenvolvimento em: Aplicações com ASP – Active Server Pages ...................................................................... 658
O Objeto Connection ..................................................................................................................................... 661
Criando Conexões ODBC .......................................................................................................................... 661
O Objeto Connection – Métodos, Propriedades e Eventos ........................................................................ 662
Criando Conexões Utilizando OLE DB ...................................................................................................... 663
A Propriedade ConnectionString ............................................................................................................... 664
Configurando Conexões com Bancos de Dados do Microsoft SQL Server 2005 ........................................... 666
O Primeiro Exemplo – Conectando com o Banco de Dados Northwind,
da Instância SERVIDOR\SQL2005 .................................................................................................................. 666
Configurando Conexões OLE DB, com Bancos de Dados ORACLE .......................................................... 670
Comentários Finais Sobre o Objeto Connection ....................................................................................... 671
O Método Close ......................................................................................................................................... 672
“Pool” de Conexões ................................................................................................................................... 672
Um Exemplo Utilizando ODBC ...................................................................................................................... 673
O Objeto RecordSet ......................................................................................................................................... 679
Um Pouco Sobre Cursores .......................................................................................................................... 680
Localização do Cursor ................................................................................................................................ 682
Lock de Registros ........................................................................................................................................ 684
Propriedades do Objeto RecordSet ............................................................................................................. 685
Métodos do Objeto RecordSet .................................................................................................................... 686
Uma Página ASP Para Inserir Informações no Banco de Dados ..................................................................... 687
Demais Operações Utilizando ASP ................................................................................................................. 699
Para Localizar um Registro .............................................................................................................................. 699
Utilizando o Nosso Exemplo ...................................................................................................................... 703
Editando e Excluindo Registros ...................................................................................................................... 704
Conclusão ....................................................................................................................................................... 705
CAPÍTULO 12 – ACESSANDO DADOS COM O MICROSOFT ACCESS E O PADRÃO XML .............................................. 707
Introdução ...................................................................................................................................................... 708
Desenvolvimento em: Uma Rápida Revisão Sobre a Estrutura
de um Banco de Dados do Microsoft Access ....................................................................................................... 709
Tabelas ............................................................................................................................................................. 710
Consultas ........................................................................................................................................................ 711
Formulários ..................................................................................................................................................... 713
Relatórios ........................................................................................................................................................ 715
Páginas ............................................................................................................................................................ 716
Macros ............................................................................................................................................................. 720
Módulos .......................................................................................................................................................... 721
Desenvolvimento em: Como Acessar Dados do Servidor SQL Server 2005 Utilizando o Microsoft Access ....... 722
Importando Dados do SQL Server em Tabelas do Microsoft Access .............................................................. 722
Anexando Tabelas no Microsoft Access .......................................................................................................... 731
Criando Consultas no Microsoft Access, Baseadas em Tabelas do SQL Server 2005 ...................................... 736
Desenvolvimento em: Acessando Dados do Servidor SQL Server 2005 com o Navegador e o Padrão XML ..... 744
XII00✦00Curso Completo
SUMÁRIO
Configurando o Acesso Através do Navegador .............................................................................................. 746
Testando o Acesso aos Dados do SQL Server 2005, Através do Navegador .................................................... 752
Uma Pouco Sobre Extensible Markup Language – XML ................................................................................ 754
Primeiro um Pouco de História ...................................................................................................................... 755
O que Mais tem a Oferecer Este Tal de XML? ................................................................................................. 756
Conclusão ....................................................................................................................................................... 757
CAPÍTULO 13 – .NET E PÁGINAS ASP.NET COM O SQL SERVER 2005 ........................................................... 759
Introdução ...................................................................................................................................................... 760
Desenvolvimento Em: O Primeiro Contato com o Framework .NET ................................................................. 762
Apresentando o Conceito de Serviços – Web Services .................................................................................... 762
Apresentando o CLR – Common Language Runtime ................................................................................ 764
.NET Framework Class Library ................................................................................................................... 766
Desenvolvimento em: Um Pequeno Parênteses Para “falar mal” dos Modelos Anteriores ................................ 767
Aí que saudade do MS-DOS??? ................................................................................................................... 767
Prazer. Eu sou o Windows! ......................................................................................................................... 768
Redes e Internet – Mais problemas (ou soluções) à Vista! ......................................................................... 769
Aplicações em 3 camadas. .......................................................................................................................... 770
Aplicações em quatro camadas. ................................................................................................................. 771
Um Modelo Baseado em Componentes ..................................................................................................... 772
Desenvolvimento em: Os elementos do Framewor .NET em Detalhes .............................................................. 773
Linguagens de programação habilitadas ao .NET ...................................................................................... 773
Common Type System ............................................................................................................................... 776
Metadata ..................................................................................................................................................... 777
Assemblies .................................................................................................................................................. 778
Desenvolvimento em: Interfaces com o usuário.. ............................................................................................... 779
Windows Forms .......................................................................................................................................... 780
Web Forms .................................................................................................................................................. 781
Desenvolvimento: Os servidores .NET ................................................................................................................ 782
Desenvolvimento em: ADO.NET ......................................................................................................................... 785
Desenvolvimento em: CLR – Common Language Runtime ............................................................................... 787
Compilar ou não compilar, eis a questão? ................................................................................................. 788
O papel dos meta dados (Metadata). ......................................................................................................... 788
Integração Entre Deferentes Linguagens: Promessa ou Realidade? ........................................................... 789
Desenvolvimento em: O processo de execução de código do CLR. ................................................................... 789
Mais Algumas Observações Sobre o JIT ...................................................................................................... 791
Desenvolvimento em: Assemblies ....................................................................................................................... 792
Uma definição em poucas palavras. ........................................................................................................... 792
Funções do assembly. ................................................................................................................................. 793
Componentes do assembly. ....................................................................................................................... 794
O que temos no “Manifesto”? .................................................................................................................... 795
Desenvolvimento em: CTS – Common Type System ......................................................................................... 796
Classificação dos tipos do CTS ................................................................................................................... 796
Desenvolvimento em: .NET Framework Class Library – Biblioteca de classes do Framework .NET ................. 797
Desenvolvimento em: Conceitos básicos de orientação a objetos ..................................................................... 802
O que é um objeto? .................................................................................................................................... 803
Mensagens .................................................................................................................................................. 805
Classes ........................................................................................................................................................ 805
Herança ...................................................................................................................................................... 806
Reutilização de código. ............................................................................................................................... 810
Curso Completo00✦00XIII
Desenvolvimento em: Uma Rápida Introdução à Tecnologia ASP.NET .............................................................. 812
Mais uma versão de ASP??? ........................................................................................................................ 812
Novidades e melhorias do ASP.NET. ........................................................................................................... 812
Um visão geral do acesso a dados ................................................................................................................... 820
Quais as principais diferenças do ADO.NET em relação ao ADO? ............................................................ 822
Bancos de Dados Utilizados nos Exemplos ......................................................................................................... 823
O banco de dados do SQL Server – pubs. .................................................................................................. 823
Uma Introdução ao ADO.NET ............................................................................................................................. 824
Informando que Você Deseja Utilizar Classes de um Determinado Namespace ....................................... 825
Classe ou objeto; objeto ou classe? ............................................................................................................ 825
Estabelecendo Conexões ................................................................................................................................. 825
Estabelecendo uma Conexão com o SQL Server 2000 ou SQL Server 2005 – SqlConnection .................. 826
Uma Visão Geral do Processo de Acesso a Dados ........................................................................................... 830
Criando Objetos Command ........................................................................................................................... 831
Retornando dados com DataAdapter ............................................................................................................. 832
O Objeto DataSet ............................................................................................................................................ 834
O objeto DataView .......................................................................................................................................... 835
Um pouco mais sobre o controle DataGrid. ................................................................................................... 841
Primeira maravilha do DataGrid: Paginação. ............................................................................................ 841
Segunda maravilha do DataGrid: Mais do que um conjunto de dados na mesma página. ...................... 842
Conclusão ....................................................................................................................................................... 846
CAPÍTULO 14 – REPORTING SERVICES – O SERVIÇO DE RELATÓRIOS DO SQL SERVER 2005 ................................. 849
Introdução ...................................................................................................................................................... 850
Desenvolvimento Em: Entendendo o Reporting Services .................................................................................. 851
Introdução ao Reporting Services ................................................................................................................... 851
Relatórios acessados via Web – Vantagens ................................................................................................. 852
Principais componentes do Reporting Services .............................................................................................. 853
Report Designer .......................................................................................................................................... 854
Report Server .............................................................................................................................................. 854
Desenvolvimento Em: Requisitos para que o Reporting Services Funcione Corretamente. .............................. 858
Requisitos do IIS e do ASP.NET Para a Instalação do Reporting Services ....................................................... 859
Desenvolvimento Em: Importando o Northwind.mdb
e Definindo os Relacionamentos ......................................................................................................................... 859
Desenvolvimento Em: Utilizando o Reporting Services ..................................................................................... 867
Exemplo prático – O primeiro relatório. ........................................................................................................ 867
Salvando o Relatório em Diferentes Formatos ............................................................................................... 876
Publicando o relatório no servidor WEB ........................................................................................................ 880
Desenvolvimento Em: Criando relatórios do tipo Matrix. ................................................................................. 882
Entendendo as Referências Cruzadas – matrix ............................................................................................... 882
Criando Relatórios usando a opção Grupos. .................................................................................................. 899
Desenvolvimento Em: O console Reporting Services Configuration ................................................................. 907
Introdução ao console Reporting Services Configuration .............................................................................. 907
Conclusão ...................................................................................................................................................... 910
CAPÍTULO 15 – EXEMPLOS PRÁTICOS E MAIS NOVIDADES DO SQL SERVER 2005 ............................................... 913
Introdução ...................................................................................................................................................... 914
Desenvolvimento Em: Snapshot Databases ........................................................................................................ 915
Quando usar a opção de Snapshot ................................................................................................................. 915
Limitações em Relação ao uso de Snapshots .................................................................................................. 916
Limitações em Relação ao Banco de Dados Fonte ..................................................................................... 916
Limitações Existentes nos Snapshots do Banco de Dados ......................................................................... 916
XIV00✦00Curso Completo
SUMÁRIO
Requerimentos de Espaço em Disco ............................................................................................................... 917
Recomendações Para a Criação de um Snapshot ........................................................................................... 918
Recomendações Sobre a Nomeação dos Snapshots ................................................................................... 918
Limitar o Número de Snapshots a Serem Mantidos .................................................................................. 918
Criando Snapshots de um Banco de Dados .................................................................................................... 919
Desenvolvimento Em: Criação de Diagramas do Banco de Dados ..................................................................... 921
Desenvolvimento Em: Transferir Bancos de Dados Entre Instâncias ................................................................. 926
O comando sp_detach_db .............................................................................................................................. 929
Desenvolvimento Em: Acessando Dados das Tabelas do Banco de Dados ......................................................... 930
Desenvolvimento Em: Usar a Opção de Geração
de Scripts do SQL Server Management Studio .................................................................................................... 932
Desenvolvimento Em: Edições do SQL Server 2005 ........................................................................................... 938
Introdução ...................................................................................................................................................... 939
SQL Server 2005 Enterprise Edition (32-bits e 64-bits) ................................................................................... 939
SQL Server 2005 Standard Edition (32-bits e 64-bits) ..................................................................................... 939
SQL Server 2005 Workgroup Edition (somente em 32 bits) ........................................................................... 939
SQL Server 2005 Developer Edition (32-bits e 64-bits) .................................................................................. 940
Comparação Entre as Versões ......................................................................................................................... 940
Conclusão ....................................................................................................................................................... 941
ANEXO .................................................................................................................................................... 943
ÍNDICE REMISSIVO .................................................................................................................................... 943
Curso Completo00✦00XV
INTRODUÇÃO
O uso da Tecnologia da Informação – TI – como suporte às atividades diárias de empresas e indivíduos
é uma realidade inquestionável. Desde atividades como um simples Cadastro de Clientes até operações
mais complexas como o controle de atividades industriais estão sendo controladas e mesmo executadas
com o suporte de sistemas de TI cada vez mais avançados. O que mais nos impressiona, ou assusta, é o
ritmo com que as mudanças vêm acontecendo nos últimos anos. Talvez o que realmente nos apavora
é que não sabemos qual será o ritmo das mudanças para os próximos anos; a única certeza que temos
é que o ritmo das mudanças será ainda maior.
Dentro deste cenário, em que a TI desempenha um papel fundamental, é que aumenta, a cada dia, a
utilização de Sistemas Gerenciadores de Banco de Dados Relacionais – SGBDR. Não existe aplicação
que não dependa de dados, os quais são armazenados e manipulados com o auxílio de um SGBDR. Ao
consultar, por exemplo, o site da Receita Federal (www.receita.fazenda.gov.br) e verificar se a sua
Restituição do Imposto de Renda está no próximo lote, o amigo leitor irá utilizar um sistema que
consulta um Banco de Dados. Ao consultar um CEP no site dos Correios, você também irá utilizar
informações armazenadas em um Banco de Dados. Poderíamos preencher páginas e páginas com
exemplos de aplicações baseadas em bancos de dados, pelo simples motivo de que toda e qualquer
aplicação é baseada em um banco de dados. O mais difícil seria encontrar alguns exemplos de sistemas
que não dependam de um Banco de Dados.
Além disso, os sistemas de Banco de Dados devem ser capazes de garantir a segurança da informação,
garantindo pré-requisitos básicos de segurança, tais como: Integridade, Confidencialidade e
Disponibilidade. Afinal de contas você quer ter certeza de que o sistema de um site de comércio eletrônico
é seguro, antes de digitar o número do seu cartão de crédito.
É neste contexto – evolução cada vez mais rápida, necessidade cada vez maior de segurança, desempenho
e disponibilidade e Bancos de Dados como suporte aos sistemas de TI – que iremos aprender a trabalhar
com a mais nova versão do Banco de Dados empresarial da Microsoft – Microsoft SQL Server 2005.
Neste livro, iremos aprender desde os conceitos básicos de Banco de Dados Relacionais até a utilização
de recursos avançados de Administração e Desenvolvimento do Microsoft SQL Server 2005. Você
aprenderá sobre o modelo relacional de dados, entenderá os conceitos de chave primária, integridade
referencial e normalização de tabela, aprenderá a instalar o SQL Server 2005, aprenderá a fazer o up-
grade do SQL Server 2000 para o SQL Server 2005, aprenderá a utilizar as novas ferramentas de
administração do SQL Server 2005, aprenderá a criar e a configurar bancos de dados, aprenderá a criar,
configurar e a administrar tabelas, consultas, triggers, aprenderá sobre segurança, sobre replicação,
sobre importação e exportação de dados, sobre o desenvolvimento de aplicações com o SQL Server
2005, sobre o novo service de criação de relatórios e muito mais.
A QUEM SE DESTINA ESTE LIVRO?

Se você está iniciando na área de Banco de Dados e está precisando aprender os conceitos básicos, bem
como uma ferramenta para aplicá-los, este livro foi feito sob encomenda para você, amigo leitor.
XVI00✦00Curso Completo
INTRODUÇÃO
SUMÁRIO
Mesmo que você não conheça Bancos de Dados Relacionais e jamais tenha utilizado o Microsoft SQL
Server, em qualquer uma de suas versões, mesmo assim terá condições de acompanhar este livro do
início ao fim. Em cada capítulo, apresento os conceitos necessários ao entendimento dos tópicos em
questão, juntamente com exemplos de aplicação prática dos tópicos vistos no capítulo. Desta forma,
você poderá acompanhar o livro, aprendendo a utilizar o Microsoft SQL Server de maneira bastante
simples e prática.
MAS E OS USUÁRIOS QUE JÁ POSSUEM ALGUMA EXPERIÊNCIA?

Se você já possui alguma experiência com Bancos de Dados e com o Microsoft SQL Server, este
livro pode ajudá-lo no entendimento de conceitos importantes que você ainda não domina, como
por exemplo:
♦ Replicação de dados.
♦ Automação de tarefas.
♦ Otimização de índices.
♦ Desenvolvimento de aplicativos.
♦ Acesso a dados do SQL Server utilizando Visual Basic, ASP, ASP.NET e o Microsoft Access.
♦ Introdução à linguagem XML.
♦ Utilização de ADO e OLE DB para acesso aos dados.
♦ Utilização do novo serviço de relatórios do SQL Server 2005-03-08.
♦ E muitos outros tópicos, indicados para os usuários intermediários e avançados.
Em cada um dos capítulos irei apresentar uma série de exemplos práticos. Através destes exemplos,
você poderá entender melhor a aplicação dos conceitos teóricos apresentados. Em muitas situações, a
melhor maneira de entender um determinado assunto é através da utilização do tópico em questão,
para resolução de um problema prático do dia-a-dia. Muitos dos exemplos apresentados podem ser
facilmente adaptados para uso em aplicações que você esteja desenvolvendo.
Ao final de cada capítulo, irei apresentar algumas questões e exercícios, os quais servem como uma
revisão dos conceitos apresentados no capítulo.
VISÃO GERAL DOS CAPÍTULOS DO LIVRO

Capítulo 1: A Teoria de Banco de Dados Relacionais. Neste capítulo veremos a teoria de Banco de Dados
Relacionais. Você aprenderá a identificar o que são Tabelas (entidades) e seus Campos (atributos). Veremos
conceitos como Chave Primária, Chave Estrangeira, Relacionamentos, Integridade Referencial, Diagrama
Entidade x Relacionamentos, Normalização e Design de Banco de Dados. Este é um capítulo que apresenta
a parte teórica necessária ao acompanhamento do restante dos capítulos do livro. Em seguida teremos
uma noção de linguagem SQL – Structured Query Language, a qual é utilizada para efetuar pesquisas em
Bancos de Dados, além de operações como inserção, alteração e exclusão de dados. Não avance para os
capítulos seguintes sem compreender bem os conceitos apresentados neste capítulo.
Curso Completo00✦00XVII
Capítulo 2: Uma Visão Geral do Microsoft SQL Server 2005. Veremos quais as novidades apresentadas pela
versão 2005 do Microsoft SQL Server e uma visão geral do SQL Server. Também aprenderemos sobre os
diferentes ambientes onde o Microsoft SQL Server 2005 pode ser utilizado, bem como as diferentes edições
disponíveis. Veremos o conceito de aplicações Cliente/Servidor e de aplicações de três ou n camadas.
Aprenderemos a fazer a instalação do SQL Server, assim como a criar múltiplas instâncias do SQL Server 2005
em um único servidor. Veremos quais os serviços instalados com o SQL Server, e como fazer o gerenciamento
dos diferentes serviços. Também mostrarei como fazer o upgrade do SQL Server 2000 para o SQL Server 2005.
Capítulo 3: Vamos apresentar a maneira como são armazenados e criados Bancos de Dados. Veremos
conceitos como RAID-0, RAID 1 e RAID-5. Também aprenderemos a melhor maneira de utilizar o
sistema de discos de forma a obter performance dos nossos Bancos de Dados. Aprenderemos a utilizar
o SQL Server Management Studio (que é o principal console de Administração do SQL Server 2005, o
qual substitui o SQL Server Enterprise Manager, o qual era utilizado no SQL Server 2000) e o Query
Analyzer (que é a interface baseada em comandos) para criar um Bancos de Dados. Apresentarei diversos
exemplos práticos, para ilustrar os conceitos teóricos apresentados.
Capítulo 4: Neste capítulo aprenderemos a criar tabelas em um Banco de Dados e definir as diversas
características de cada campo de cada tabela. Também aprenderemos sobre índices e como criá-los. Veremos
como a correta utilização dos índices pode ajudar na melhoria da performance. Aprenderemos a utilizar
diversos comandos T-SQL para criação, administração, atualização e monitoramento dos índices.
Capítulo 5: Informações fundamentais estão armazenadas em Bancos de Dados. A perda destas

informações pode representar um desastre irrecuperável. Para evitar que tal desastre aconteça,
aprenderemos a fazer o backup das informações contidas em um Banco de Dados do Microsoft
SQL Server 2005. Veremos os diferentes tipos de backup possíveis, bem como as vantagens e
desvantagens de cada tipo. Também aprenderemos a fazer a restauração dos dados, a partir do
backup, quando necessário. Na seqüência, falaremos sobre o agendamento e automatização de
tarefas com o SQL Server 2005.
Capítulo 6: Nos sistemas atuais, principalmente com o crescimento da Internet, segurança é um ponto
fundamental. Neste capítulo aprenderemos a configurar a segurança de acesso para um Banco de Dados
do SQL Server. Veremos como o SQL Server 2005 se integra com o Active Directory do Windows 2000
Server ou do Windows Server 2003 e as diversas opções de configuração possíveis. Veremos como configurar
a segurança em nível de SERVIDOR\instância, Banco de Dados e objetos do banco de Dados.
Apresentaremos diversos exemplos passo a passo, para facilitar a aprendizagem dos conceitos apresentados.
Você verá que existem mudanças conceituais e práticas, muito importantes, na maneira como a segurança
é implementada no SQL Server 2005, em relação à maneira como era implementada no SQL Server 2000.
Capítulo 7: Neste capítulo, aprenderemos a configurar, monitorar e gerenciar o servidor SQL. Veremos
como utilizar ferramentas como o Microsoft SQL Profiler. Veremos como analisar o desempenho do servidor
SQL, através da utilização do Performance Monitor do Windows 2000. Você também aprenderá a utilizar
os recursos do Integration Services do SQL Server 2005 (no SQL Server 2000 era a ferramenta DTS – Data
Transformation Services). Os recursos do Integration Services estendem, em muito, as funcionalidades do
DTS. Você aprenderá a usar os recursos do Integration Services, através de exemplos práticos, passo a passo.
Capítulo 8: Replicação de dados. A replicação de dados é um dos recursos mais importantes e úteis do
SQL Server. Veremos o que é a replicação e os diferentes tipos disponíveis. Mostrarei diversos exemplos
XVIII00✦00Curso Completo
INTRODUÇÃO
SUMÁRIO
práticos, passo a passo, com explicações detalhadas de cada um dos componentes da replicação no
SQL Server 2005. Você também aprenderá sobre a arquitetura de replicação implementada pelo SQL
Server 2005, sobre os diferentes componentes do sistema de replicação, aprenderá a implementar e a
administrar a replicação e também aprenderá sobre questões de segurança, relacionadas à replicação.
Capítulo 9: Veremos tópicos relacionados com o desenvolvimento de aplicações com o Microsoft SQL
Server 2005. Vamos criar Constraints e Rules. Veremos como estes mecanismos podem ajudar a manter
a integridade dos dados. Também mostrarei uma das principais novidades do SQL Server 2005, que é a
integração do SQL Server com o Framework .NET. O que isso significa? Significa muito, uma verdadeira
revolução. Por exemplo, você poderá criar stored procedures, triggers, constraint e rules usando a sua
linguagem de programação preferida, tal como VB.NET, C# ou Delphi.NET.
Capítulo 10: Neste capítulo continuaremos tratando de desenvolvimento no SQL Server 2000.
Aprenderemos a criar stored procedures e triggers. Veremos como a utilização de triggers permite que
sejam implementadas Regras de Negócio, no próprio Banco de Dados. Na parte final do capítulo,
veremos algumas opções avançadas da linguagem T-SQL. Também apresentarei as novidades e melhorias
da linguagem T-SQL, introduzidas no SQL Server 2005.
Capítulo 11: Acessando dados de um Servidor SQL com o Microsoft Access e com a tecnologia ASP –
Active Server Pages. Também aprenderemos sobre a estratégia UDA (Universal Data Access) da Microsoft,
dentro da qual se encaixam conceitos como ADO (Activex Data Objects) e OLE DB (sem tradução).
Capítulo 12: Neste capítulo, abordarei a linguagem XML – Xtensible Markup Language. O mundo
Web vive um novo momento, no qual a possibilidade de integração e troca de dados entre os mais
diferentes sistemas é uma realidade. O que torna isto possível é a utilização do XML como uma forma
padronizada para troca de informações entre sistemas que vão, desde aplicativos de mainframe, a
sistemas modernos desenvolvidos para o ambiente Windows.
Capítulo 13: Acessando dados de um Servidor SQL com o Microsoft Access e com a tecnologia ASP.NET.
O ASP.NET foi introduzido com o Framework .NET e apresenta muitas melhorias em relação ao ASP
3.0. Com ASP.NET você tem acesso a uma riquíssima biblioteca de tipos e funções do Framework .NET.
Neste capítulo farei uma apresentação do Framework .NET, mostrando qual a proposta de
desenvolvimento do modelo .NET. Também mostrarei como criar páginas ASP.NET que fazem conexão
com bancos de dados do SQL Server 2005.
Capítulo 14: Serviços de Relatórios do SQL Server 2005 – Reporting Services. Uma brincadeira bem
conhecida no mundo de TI é que “Criamos um banco de dados para jogar informações para dentro
dele e depois ficamos ansiosos, para criar os relatórios, para extrair informações do banco de dados”.
Mas não temos como fugir desta realidade, ou seja, uma vez criado o banco e todos os seus objetos, o
objetivo final é extrair informações deste banco, quer seja via listagens em uma página Web criada
dinamicamente, quer seja via relatórios impressos. O Reporting Services é uma das grandes novidades
do SQL Server 2005. Os desenvolvedores irão simplesmente adorar esta novidade, pois com o Report-
ing Services ficou muito mais fácil (eu diria “uma verdadeira barbada”) a criação, configuração,
administração e distribuição de relatórios, a partir de bancos de dados do SQL Server.
Capítulo 15: Exemplos Práticos e Mais Novidades do SQL Server 2005. Neste capítulo eu apresentarei,
na forma de exemplos práticos, mais algumas novidades do SQL Server 2005. Apresentarei novidades
que, por motivos de organização do livro, não puderam ser colocadas nos capítulos anteriores. Também
Curso Completo00✦00XIX
apresentarei alguns exemplos práticos sobre tarefas comuns ao dia-a-dia do DBA (Database Adminis-
trator). Este é o típico capítulo do tipo “Salada de Frutas”. Ou seja, um tópico aqui, outro ali e assim por
diante. Julguei importante incluir este capítulo, porque nele abordo tópicos práticos, que certamente
o DBA usará no seu trabalho diário.
Anexo: Um resumo de comandos da linguagem SQL e exemplos práticos através da utilização do SQL.
Fontes adicionais de informação sobre o Microsoft SQL Server 2005, na Internet.
EQUIPAMENTO E SOFTWARE NECESSÁRIOS

Para acompanhar todos os exemplos propostos no livro, precisamos de um computador com uma das
seguintes versões do Windows:
♦ Windows XP Profesional
♦ Windows 2000 Professional
♦ Windows 2000 Server
♦ Windows Server 2003
Também faz-se necessário que o IIS (a versão do IIS depende da versão do Windows que você estiver
usando) esteja instalado e corretamente configurado. Caso você não tenha o IIS instalado, não se
preocupe. Mais adiante, ainda nesta introdução, mostrarei um passo-a-passo, o qual ensina a instalar o
IIS, caso o mesmo não tenha sido instalado durante a instalação do Windows 2000.
A configuração mínima de hardware necessário depende de uma série de fatores.
Se o equipamento vai ser utilizado como um servidor Web na Internet, vários são os aspectos a serem
considerados, tais como:
♦ Aplicações implementadas no servidor, número de usuários simultâneos e recursos de hard-

ware necessários, tais como memória, disco e processador.
♦ Número estimado de acessos simultâneos e diários, sendo esta uma das estimativas mais difíceis
de se obter, uma vez que o sucesso de um site pode ser determinado por um número muito
grande de fatores, nem todos de fácil mensuração.
♦ Grau de segurança necessário e desejável. Neste caso, entram questões como criptografia, uso
de certificados digitais, criação de VPN – Virtual Private Networks (Redes Privadas Virtuais),
procedimentos de recuperação a falha, plano de contingência, etc.
♦ Percentual de “folga” desejado para recursos tais como: memória, processador, disco. Ao projetar
um site, é bastante comum utilizar hardware que atenda as necessidades atuais com uma certa
folga, para que seja possível atender a crescimentos maiores do que os estimados. Alguns sites
famosos já enfrentaram problemas de crescimentos maiores do que os esperados, em um período
muito curto de tempo. Quando isso acontece, mais recursos de hardware precisam ser
adicionados com o site em funcionamento. É a bem conhecida situação de “trocar o pneu com
o carro andando”. Eu diria que hoje, na velocidade em que as mudanças acontecem, seria um
pouco pior, algo como: “trocar a turbina com o avião em pleno vôo”.
XX00✦00Curso Completo
INTRODUÇÃO
SUMÁRIO
Como equipamento para ser utilizado em casa, ou em um laboratório de teste na sua empresa, com o
objetivo de acompanhar os exemplos apresentados neste livro, aconselho a seguinte configuração mínima:
♦ Processador Pentium 1 GHz ou superior.
♦ 256 MB de RAM, quanto mais melhor.
♦ 10 GB de disco rígido.
♦ Drive de CD-ROM.
Além de uma das versões do Windows citadas e do IIS, também precisaremos ter os seguintes programas
e serviços instalados, para que possamos acompanhar os exemplos deste livro:
♦ Internet Explorer 6.x ou superior.
♦ Microsoft Access 2000 ou superior.
INSTALANDO E TESTANDO O IIS

Caso você não tenha instalado o IIS, quando da instalação do Windows, é possível fazer a instalação
quando for necessário. A seguir mostrarei, passo a passo, como instalar o IIS 6.0 (que é a versão que
vem com o Windows Server 2003. O procedimento para instalar a versão do IIS que vem com o Win-
dows 2000 ou Windows XP é praticamente o mesmo).
Para instalar o IIS 6.0, o qual faz parte do Windows Server 2003, siga os passos indicados a seguir:
1. Faça o logon no Windows com uma conta com permissões de administrador.

2. Abra o Painel de controle (Iniciar -> Painel de controle).
3. Abra a opção Adicionar ou remover programas. Surgirá a janela indicada na Figura i.1.
Figura i.1 Janela Adicionar ou remover programas.
Curso Completo00✦00XXI
4. No lado esquerdo da janela, dê um clique na opção Adicionar/remover componentes do Windows.
5. Será exibida, por breves instantes, uma mensagem “Aguarde”. Depois, surge a janela Assistente
de componentes do Windows, indicada na Figura i.2.
Figura i.2 A janela para alterar a instalação do Windows.
Utilizando o Assistente de componentes do Windows, podemos adicionar novos serviços do Windows

2000, ou remover serviços que não sejam mais necessários. Por exemplo, é através desta janela que você
pode instalar serviços tais como o DNS, DHCP, WINS e tantos outros disponíveis no Windows Server 2003.
6. Vá descendo com a barra de rolagem vertical, até localizar o item Application Server (Servidor
de aplicativo) e clique neste item para marcá-lo, conforme indicado na Figura i.3.
7. Clique no botão Details (Detalhes). Será exibida uma lista com os diversos serviços relacionados
ao desenvolvimento de aplicações. Marque a opção Internet Information Services (IIS), conforme
indicado na Figura i.4.
8. Observe que ao marcar esta opção, o botão Details (Detalhes) é habilitado. O IIS é formado por
uma série de componentes e funcionalidades. Existe um servidor de páginas (servidor HTTP),
um servidor de ftp, um servidor de notícias (NNTP) e assim por diante. Ao instalarmos o IIS,
podemos escolher um ou mais dos seus componentes, dependendo das necessidades do nosso
servidor Web. Não é necessário que todos os componentes do IIS sejam instalados. Por exemplo,
se o serviço de cópia de arquivos não for necessário, não temos por que instalar o serviço de ftp.
NOTA
Na prática, em um servidor da sua rede, instale somente os serviços realmente necessários. Não é uma boa idéia instalar todos os serviços
disponíveis, mesmo que somente alguns sejam utilizados. Quanto mais serviços instalados, maiores as possibilidades de ataque e quebra da
segurança do servidor, por parte de um hacker, além da maior utilização de memória e processador no servidor.
XXII00✦00Curso Completo
INTRODUÇÃO
SUMÁRIO
Figura i.3 O grupo Application Server.
Figura i.4 Selecionando o IIS para instalação.
9. Clique no botão Details (Detalhes). Será exibida uma lista com os componentes que fazem
parte do IIS.
10. Na lista de opções disponíveis, exibida na Figura i.5, certifique-se de que todas as opções estejam
marcadas, conforme indicado na Figura i.5. Não esqueça de usar a barra de rolagem vertical, para
marcar também os componentes que não são exibidos na tela.
Curso Completo00✦00XXIII
Figura i.5 Instalando todos os componentes do IIS.
11. A opção Servidor World Wide Web Service também é dividida em vários componentes. Clique
nesta opção para marcá-la. Em seguida clique no botão Details (Detalhes). Será exibida a janela
com os componentes do serviço World Wide Web. Certifique-se de que todas as opções estejam
marcadas, conforme indicado na Figura i.6.
Figura i.6 Opções do servidor World Wide Web.

NOTA
Importante: Nunca é demais repetir que a instalação de todos os componentes está sendo feita apenas para uso didático, para que você
aprenda a utilizá-los. Na prática, devem ser instalados apenas os componentes realmente necessários, por motivos já expostos anteriormente.
XXIV00✦00Curso Completo
INTRODUÇÃO
SUMÁRIO
12. Clique em OK para fechar a janela da Figura i.6. Você estará de volta à janela Internet Information
Services (IIS), indicada na Figura i.5. Clique em OK para fechá-la e aplicar as configurações selecionadas.
13. Você estará de volta à janela do Assistente de componentes do Windows. Observe que, após ter
selecionado os componentes a serem instalados, o Windows Server 2003 exibe o espaço em
disco necessário para a instalação dos novos componentes selecionados.
14. Dê um clique no botão Next (Avançar) para ir para a próxima etapa do assistente.
15. O Windows Server 2003 exibe uma janela indicando o progresso da instalação.
16. Caso o Windows Server 2003 não encontre os arquivos necessários à instalação do IIS, no disco
rígido, você será solicitado a inserir o CD de instalação do Windows Server 2003.
17. Insira o CD de instalação do Windows Server 2003 e aguarde. O Windows detecta que o CD foi
inserido e inicia, automaticamente, o processo de cópia dos arquivos.
18. Após concluída a cópia dos arquivos, o assistente emite uma mensagem dizendo que o processo
foi concluído com sucesso.
19. Dê um clique no botão Finish (Concluir) para encerrar o assistente.
20. Você estará de volta à janela Adicionar ou remover programas. Dê um clique no botão Close
(Fechar) para sair desta janela.
21. Você estará de volta ao Painel de controle. Feche o Painel de controle.
22. Agora o IIS está instalado e pronto para ser utilizado, pelo menos as funcionalidades básicas do IIS.
Agora que já temos o IIS instalado vamos testar se ele está funcionando corretamente.
Figura i.7 O IIS instalado e funcionando e a página padrão sendo exibida.
Curso Completo00✦00XXV
Para testar se o IIS foi instalado com sucesso, siga os seguintes passos:
1. Abra o Internet Explorer.

2. Digite o seguinte endereço: http://localhost
3. Será aberta uma página padrão (iisstart.htm), que é uma página apenas com um aviso de que o
site está em construção, conforme indicado na Figura i.7.
4. Esta é a página inicial do IIS logo após a instalação. A pasta padrão do IIS fica gravada em
C:\Inetpub\wwwroot. Isto comprova que o IIS foi instalado com sucesso. Feche o Internet Explorer.
VAMOS AO TRABALHO
Feitas as devidas apresentações, é hora de iniciarmos nossa jornada através do Microsoft SQL Server 2005.
O código-fonte, com os exemplos de programação, e os scripts SQL, apresentados no livro, estão

disponíveis para donwload no site da Editora Axcel Books: www.axcel.com.br.
No Capítulo 1 você aprenderá sobre os fundamentos teóricos, que formaram a base para acompanhar
todos os demais capítulos do livro. Eu considero este, sem dúvida, o capítulo mais importante do livro.
Entender bem os fundamentos do Modelo Relacional é fundamental para o aprendizado do SQL Server.
Então leia e releia o Capítulo 1, até que não fique nenhuma dúvida sobre os tópicos teóricos que serão
apresentados no Capítulo 1.
Caso você tenha alguma sugestão sobre tópicos que gostaria de ver incluída em futuras edições deste
livro, queira enviar críticas e sugestões ou relatar algum erro encontrado. Basta entrar em contato
através do e-mail: webmaster@juliobattisti.com.br. Será um prazer trocar idéias com o amigo leitor.
Desejo a todos uma boa leitura, e que este trabalho possa ajudá-los na busca de um aperfeiçoamento
contínuo, rumo ao sucesso em sua carreira profissional.
XXVI00✦00Curso Completo
Parte 1
FUNDAMENTOS
Capítulo 1
INTRODUÇÃO AOS BANCOS DE DADOS
RELACIONAIS E À LINGUAGEM SQL
SQL SERVER 2005 ADMINISTRAÇÃO E DESENVOLVIMENTO – PARTE I: FUNDAMENTOS
INTRODUÇÃO
É correto dizer que existe um capítulo que seja “o mais importante de um livro?”. Eu acredito que sim.
É o caso deste primeiro capítulo, o qual, sem nenhuma dúvida, é o mais importante deste livro. Este
capítulo apresenta os fundamentos teóricos do modelo relacional de dados e da linguagem T-SQL, os
dois pilares sobre os quais foram construídos todos os serviços do SQL Server 2005.
Neste capítulo você aprenderá sobre os conceitos básicos de Bancos de Dados Relacionais. Também
aprenderá sobre os comandos básicos da linguagem SQL – Structured Query Language. No SQL Server
2005 a linguagem é chamada de T-SQL, sendo o “T” de Transact.
Durante muitos anos, no início da informatização das empresas, as aplicações eram baseadas em
computadores de grande porte, conhecidos como Mainframes. Nesta época as aplicações,
normalmente desenvolvidas em linguagens de programação tais como Cobol, PL1, Algol ou Natural
Adabas, ficavam residentes nestes computadores e os dados também. A lógica para acesso aos dados
estava embutida dentro da própria aplicação. Com isso, se mudasse a estrutura de armazenamento
das informações, a aplicação teria que ser reescrita. Para acessar as aplicações, o usuário utilizava os
chamados “terminais burros” (também conhecidos como “terminais verdes”, devido à cor das letras
normalmente ser verde em um fundo preto). Estes terminais eram, simplesmente, uma extensão do
mainframe, equipados com teclado e vídeo. Nenhum processamento era realizado no próprio termi-
nal. Todo e qualquer comando era enviado para processamento no mainframe, e os resultados
mandados de volta para o terminal.
Observe que utilizei os verbos sempre no passado. Você deve estar pensando: “Este cara está maluco,
pois ainda hoje muitas aplicações rodam, e bem, no bom e velho mainframe”. E eu serei obrigado a
concordar com o amigo leitor. Muitas e importantes são as aplicações que ainda rodam em main-
frames e duvido que em um futuro próximo, digamos cinco anos, todas estas aplicações sejam migradas
para outras plataformas e modelos de desenvolvimento. Mas também precisamos admitir que é muito
pequeno, para não dizer mínimo, o desenvolvimento de novas aplicações para o modelo Terminal –
mainframe clássico.
Com o deslocamento do modelo de desenvolvimento do mainframe; primeiro para o modelo Cliente/

Servidor clássico de duas camadas, depois a evolução para o modelo de desenvolvimento Web com três
ou mais camadas, também sofreram modificações os Bancos de Dados que dão suporte ao
desenvolvimento destas aplicações. O mainframe utiliza formatos de Bancos de Dados proprietários,
criados pelos fabricantes dos equipamentos, na maioria dos casos a IBM.
NOTA
No Capítulo 2 iremos detalhar os modelos de desenvolvimento em duas, três ou n camadas. Também falaremos sobre as vantagens e
desvantagens de cada modelo.
Com a expansão cada vez maior das redes locais de computadores e a interconexão destas redes
entre si, formando a WAN da empresa e a interconexão mundial das WANs, formando a Internet, e
com a expansão do modelo Cliente/Servidor em 2 ou mais camadas, a utilização dos chamados
Bancos de Dados Relacionais cresceu exponencialmente. Hoje a grande maioria das novas aplicações
400✦00Curso Completo
CAPÍTULO 1 – INTRODUÇÃO AOS BANCOS DE DADOS RELACIONAIS E À LINGUAGEM SQL
(para não dizermos a quase totalidade) é baseada neste tipo de Bancos de Dados, ou seja: Bancos de
Dados Relacionais.
Neste capítulo falarei sobre os princípios básicos dos Bancos de Dados Relacionais, que é o modelo de
Banco de Dados utilizado pelo Microsoft SQL Server 2005. Outros Bancos de Dados bastante conhecidos
e que também utilizam este modelo:
♦ Microsoft Access – para aplicações de menor porte.
♦ Oracle.
♦ DB2 da IBM.
♦ Sybase.
♦ MySQL para Linux.
O modelo Relacional também possui suas limitações, porém é bastante adequado para a grande maioria
das aplicações comerciais atualmente em uso ou sendo desenvolvidas. Algumas aplicações especiais
que necessitam utilizar dados mais complexos, como por exemplo arquivos multimídia, dados
geográficos, dados espaciais e séries temporais, podem se beneficiar mais das características dos chamados
Bancos de Dados Orientados a Objetos. Este tipo de Banco de Dados ainda não é amplamente utilizado,
a não ser em situações específicas.
Um exemplo de Banco de Dados Orientado a Objetos é o Jasmine da CA.
Estudaremos, ao longo deste capítulo, os princípios básicos dos Bancos de Dados Relacionais
devido a sua grande aceitação e utilização. Caso você queira maiores detalhes sobre este tipo de
Banco de Dados, existe uma farta bibliografia, bem como inúmeros sites na Internet com
informações sobre o assunto.
O Microsoft SQL Server utiliza uma série de comandos para realizar as diversas operações sobre os dados
armazenados nos Bancos de Dados do SQL Server. São exemplos de operações realizadas sobre os dados:
♦ Selecionar um conjunto de registros com base em um ou mais critérios especificados.
♦ Ordenar um conjunto de registros com base em um ou mais campos de dados.
♦ Alterar informações no Banco de Dados.
♦ Excluir informações no Banco de Dados.
♦ Inserir informações no Banco de Dados.
Para realizar estas operações é utilizada uma linguagem conhecida com SQL – Structured Query Language. A
linguagem SQL foi desenvolvida pela IBM, porém, devido ao seu poder e facilidade de utilização, rapidamente
tornou-se um padrão de mercado, sendo hoje utilizada pela maioria dos Bancos de Dados que seguem o
modelo Relacional. No SQL Server 2005 a linguagem é chamada de T-SQL, sendo o “T” de Transact.
NOTA
Pequenas diferenças podem existir entre os comandos SQL de diferentes Bancos de Dados como por exemplo o Microsoft SQL Server e o Oracle.
Neste livro serão utilizados, evidentemente, os comandos e a sintaxe da linguagem T-SQL, a qual é utilizada pelo Microsoft SQL Server 2005.
Curso Completo00✦005
FUNDAMENTOS EM: CONCEITOS BÁSICOS

DE BANCOS DE DADOS RELACIONAIS
PRÉ-REQUISITOS
♦ Nenhum.
METODOLOGIA
♦ Apresentação e descrição dos elementos que fazem parte do modelo Relacional.
TÉCNICA
♦ Utilização de exemplos práticos para ilustrar a teoria apresentada.
Neste item apresentarei os principais conceitos sobre Bancos de Dados Relacionais. Estes conceitos são
importantes (eu diria até “fundamentais”) para a correta utilização dos Bancos de Dados, bem como para
o projeto e criação de Bancos de Dados. O SQL Server 2005 é um Banco de Dados que segue o modelo
Relacional. Conhecer os fundamentos teóricos sobre bancos relacionais é indispensável. A teoria sobre o
Modelo Relacional de Dados está para o SQL Server 2005, assim como o Cálculo e a Física estão para um
Engenheiro (e sei muito bem deste aspecto, pois a minha formação é em Engenharia Elétrica).
Em muitas situações teremos que conectar nossas aplicações com Bancos de Dados já existentes, e
neste caso precisamos conhecer os conceitos aqui apresentados, para podermos utilizar o Banco de
Dados de uma maneira correta e otimizada.
Em outras situações teremos que criar o Banco de Dados a ser utilizado pela aplicação que está
sendo desenvolvida. Neste caso, os conceitos apresentados neste capítulo auxiliam no projeto e
criação de um Banco de Dados melhor estruturado e otimizado, tanto em termos de espaço de
armazenamento, quanto da qualidade, confiabilidade, segurança, desempenho e disponibilidade
das informações nele contidas.
Apresentarei os seguintes tópicos teóricos, sobre o Modelo Relacional de Dados:
♦ Entidades e Atributos, os elementos básicos de um Banco de Dados.
♦ Chave Primária.
♦ Relacionamentos entre Entidades (Tabelas).
♦ Integridade Referencial.
♦ Normalização de Tabelas.
♦ Análise de um Banco de Dados relacional.
ENTIDADES E ATRIBUTOS
Toda a informação de um Banco de Dados Relacional é armazenada em Tabelas, as quais também são
chamadas (o termo técnico) de Entidades. Por exemplo, poderíamos ter uma tabela “Clientes”.
Para cada um dos clientes poderíamos armazenar informações tais como número do CPF, código do
cliente, número do RG, nome completo, endereço, bairro, cidade, estado, CEP, etc.
Essas diversas características de cada cliente são os “Atributos” do cliente, muitas vezes chamados de
campos da entidade Cliente, ou de maneira mais simples: “Os campos da tabela Clientes”.
O conjunto de todos os atributos de um cliente e os valores de cada atributo formam o Registro

do Cliente. Com isso teremos a tabela constituída por um conjunto de registros (uma linha
completa com informações sobre o cliente) e cada registro formado por um conjunto de atributos
(Nome, Endereço, etc.).
Resumindo:
♦ Entidade ou Tabela -> Um conjunto de registros.
♦ Campos ou Atributos -> Características individuais de cada entidade.
Considere o exemplo da Figura 1.1: temos uma tabela Clientes com os seus diversos campos (atributos).
Figura 1.1 A entidade (tabela) Clientes e seus diversos atributos (campos).
Neste exemplo, temos uma entidade Clientes e seus diversos atributos:
♦ Código do cliente.
♦ Nome da empresa.
♦ Nome do contato.
♦ Cargo do contato.
♦ Endereço.
Neste caso, os campos (Atributos) da tabela Clientes são: Código do cliente, Nome da empresa, Nome
do contato, Cargo do contato, Endereço, etc.
Em cada linha temos um conjunto de atributos e seus valores. Cada linha forma um registro que
identifica um cliente. Cada coluna é um atributo da tabela Clientes.
Considere o exemplo da Figura 1.2, onde temos a tabela Clientes e os dados para os primeiros registros
sendo exibidos:
Figura 1.2 Os primeiros registros da tabela Clientes, sendo exibidos.
Um dos grandes desafios em se projetar um Banco de Dados com sucesso é a correta determinação das
entidades que existirão no Banco de Dados (as tabelas que farão parte do Banco de Dados, de tal
maneira que os requisitos do Banco de Dados sejam atendidos), bem como dos atributos de cada
entidade (os campos que existirão em cada tabela). Mais adiante veremos algumas dicas e técnicas para
determinar as tabelas necessárias, bem como os campos necessários em cada tabela.
É importante lembrar que o que determina quais as tabelas e campos em cada tabela que serão necessários
são o escopo e os objetivos do problema que está sendo abordado. Por exemplo, se estamos
desenvolvendo um sistema para acompanhamento do desempenho individual de cada funcionário,
com certeza não teremos necessidade de uma tabela de clientes (permitam-me o exagero, para poder
ilustrar bem a importância de manter o objetivo do Banco de Dados, sempre em mente). Por outro
lado, se o desempenho de cada funcionário a ser acompanhado estiver ligado ao número de clientes
atendidos pelo funcionário ou ao volume de vendas para cada cliente, a tabela Clientes passa a ter
importância para o problema em questão.
Com isso podemos dizer que o que determina as tabelas e campos necessários é o problema real que o
sistema a ser desenvolvido deverá solucionar.
Outro fato importante, e que iremos repetir ao longo deste capítulo, é que cada tabela deve conter
dados de um determinado assunto. Não devemos misturar dados de diversos assuntos em uma mesma
tabela. A regra número 1 do projeto de Banco de Dados é: “Assuntos diferentes em tabelas diferentes”.
Ou de outra maneira: “Não se misturam campos de dois ou mais assuntos na mesma tabela”.
Observe o exemplo da Tabela 1.1.
Tabela 1.1 Clientes e seus pedidos.
Nome Endereço Fone Núm. Pedido Data Valor
José da Silva Rua ABC – 40 222-2222 10234 10-01-2001 R$ 450,00

Jose da Silva Rua ABC – 40 222-2222 10345 12-01-2001 R$ 370,00
José da Silva Rua ACB – 40 222-2222 12321 23-02-2001 R$ 234,30
Para Pedro Rua YYU – 234 111-1111 12345 23-02-2001 R$ 654,33
Para Pedro Rua YYU – 234 111-1111 12444 28-02-2001 R$ 456,70
Maria José Rua BBB – 221 123-2222 12445 01-03-2001 R$ 443,25
Maria José Rua BBB – 221 123-2222 12446 07-03-2001 R$ 500,32
Observe que, nesta tabela, cometemos, propositalmente, o erro de “misturar” dois assuntos:
♦ Dados sobre os “Clientes”
♦ Dados sobre os “Pedidos dos Clientes”
Quando este tipo de erro é cometido, temos uma série de problemas que irão refletir em todo o sistema
que está sendo desenvolvido. Dentre os principais problemas podemos citar:
♦ Informação repetida: Observe que, para cada pedido de um determinado cliente, precisamos
informar novamente os campos: Nome, Endereço e Fone do cliente.
♦ Informação inconsistente: Observe que, por um erro de digitação, o nome do cliente José da
Silva está digitado incorretamente (sem o acento) no segundo registro, e o seu endereço está
digitado incorretamente, no terceiro registro. Isso causa inconsistências no Banco de Dados,
gerando resultados errados quando forem feitas pesquisas pelo nome do cliente ou pelo endereço
ou quando forem gerados relatórios com totalizações por cliente, tais como o total anual de
vendas para cada cliente ou a média mensal de vendas, por cliente.
Para evitar este tipo de problema, deveríamos separar as informações dos clientes e dos seus pedidos
em duas tabelas distintas. Veremos como fazer isso mais adiante, neste capítulo. Por enquanto, mantenha
sempre em mente a regra número um do projeto de Bancos de Dados relacionais: “Assuntos diferentes
em tabelas diferentes”. Ou de outra maneira: “Não se misturam campos de dois ou mais assuntos na
mesma tabela”.
O CONCEITO DE CHAVE PRIMÁRIA

O conceito de Chave Primária é fundamental para entender o funcionamento de um Banco de Dados.
Vamos procurar entender o que significa um campo ser a chave primária de uma tabela.
Ao definirmos um campo como sendo uma chave primária, estamos informando ao Banco de Dados
que não podem existir dois registros com o mesmo valor na chave primária, ou seja, os valores no
campo Chave Primária precisam ser únicos.
Por exemplo, se defino um campo “Número da Identidade” da tabela Clientes como sendo uma chave
primária, estou dizendo ao Banco de Dados que não podem existir dois clientes com o mesmo valor no
campo “Número da Identidade”. Na prática, estou garantindo que não podem ser cadastrados dois
clientes com o mesmo número de identidade.
Em outras palavras, poderíamos dizer que o campo Chave Primária identifica de maneira única cada
registro de uma tabela, isto é, de posse do valor da chave primária somente localizaremos um registro
com aquele valor no campo Chave Primária.
Outro exemplo de campo que ilustra bem o conceito de chave primária é um campo Número do
pedido, na tabela Pedidos. Este campo deve ser único, o que na prática significa que não podem ser
cadastrados dois pedidos, com o mesmo valor no campo Número do Pedido. Nós veremos a parte
prática, sobre como definir um campo para ser do tipo chave primária, no Capítulo 4.
Este é um conceito muito importante, pois conforme veremos mais adiante os conceitos de Integridade
Referencial e Normalização estão diretamente ligados ao conceito de chave primária.
Alguns exemplos de campos que podem ser definidos como “Chave Primária” em suas respectivas tabelas:
♦ O campo Número do Pedido, em um tabela de Pedidos.
♦ O campo Número da Identidade ou CPF em uma tabela de Clientes Pessoa Física.
♦ O campo Número do CNPJ em uma tabela de Clientes Pessoa Jurídica.
♦ O campo Código do Produto em uma tabela de Produtos.
♦ O campo ISBN em uma tabela de Livros.
Na Figura 1.3, vemos um exemplo da tabela Clientes onde o campo Código do Cliente é definido
como uma chave primária. Observe que não existem dois clientes com o mesmo código.
Um detalhe importante é que a chave primária pode ser formada pela combinação de mais do que um
campo. Podem existir casos (embora não sejam muito comuns) em que um único campo não é capaz
de atuar como chave primária, pelo fato de apresentar valores repetidos. Nestes casos, podemos definir
uma combinação de dois ou mais campos para ser a nossa chave primária. Além disso, uma tabela
somente pode ter uma chave primária, seja ela simples ou composta. Outro detalhe importante é que
nem todas as tabelas têm que ter, obrigatoriamente, uma chave primária (seja simples ou composta).
Dependendo de cada projeto, pode haver situações onde uma tabela não terá nenhum campo (ou
combinação de campos), definido como do tipo chave primária.
Um cuidado especial que devemos ter é quanto ao desempenho das consultas em tabelas que possuem
chave primária composta por mais do que um campo. Em muitas situações, o desempenho das consultas
é inversamente proporcional ao tamanho da chave primária. Com isso, quanto maior o tamanho da
chave primária, menor o desempenho das consultas, isto é, mais demoradas se tornam as consultas.
Figura 1.3 O campo Código do Cliente é uma chave primária.
Na prática, dificilmente teremos uma chave primária composta por mais do que três ou quatro cam-
pos. Se você se deparar com uma situação em que precise de uma chave primária composta de mais de
quatro campos, revise o projeto do Banco de Dados, porque devem existir alguns problemas.
RELACIONAMENTOS ENTRE TABELAS

Na prática, em um Banco de Dados Relacional, podem existir diversas tabelas, como por exemplo:
♦ Clientes
♦ Produtos
♦ Pedidos
♦ Detalhes do Pedido
♦ Fornecedores
♦ Categorias
♦ Funcionários, etc.
Embora as informações estejam separadas em cada uma das tabelas, devemos ter algum mecanismo
que nos permita reunir dados de duas ou mais tabelas. Por exemplo, para fazer um relatório do total
anual de vendas, por funcionário, precisarei de informações das seguintes tabelas:
♦ Funcionários
♦ Pedidos
♦ Detalhes do Pedido.
O mecanismo que nos permite acessar, de maneira consolidada, dados de diversas tabelas é o
“Relacionamento entre Tabelas”.
Por exemplo: um pedido é feito por um cliente e neste pedido podem existir diversos Itens. As
informações sobre o cabeçalho do pedido (Número do pedido, Data, Código do cliente, Endereço de
entrega, Código do funcionário, etc.) são armazenadas na tabela Pedidos. Já as informações sobre os
itens do pedido (Número do pedido – para identificar a qual pedido pertence o item, Código do produto,
Quantidade, Preço unitário, etc.) são armazenadas na tabela Detalhes do Pedido. Além disso, cada
pedido possui um número único, mas um mesmo cliente pode fazer diversos pedidos. Com esta
separação entre as informações do cabeçalho do pedido (na tabela Pedidos) e dos Itens do pedido (na
tabela Detalhes do pedido), evitamos uma série de problemas, tais como a repetição desnecessária de
informações. Se colocássemos todas as informações em uma única tabela, teríamos que repetir todos
os dados do cabeçalho do pedido, para cada um dos itens do pedido. E quem garante que estas
informações seriam inseridas corretamente, para todos os itens de um pedido?
Veja que o parágrafo acima descreve relações do mundo real. Estas relações do mundo real são o nosso
guia, para definir as relações entre as diversas tabelas do Banco de Dados.
Em um Banco de Dados precisamos de alguma maneira para representar estes relacionamentos da vida
real, em termos das tabelas e seus atributos. Isto é possível com a utilização dos Relacionamentos, os
quais podem ser de três tipos:
♦ Um para Um
♦ Um para Vários
♦ Vários para Vários
Vamos analisar cada um destes tipos de relacionamentos, individualmente e detalhadamente.
Procure entender bem o conceito de relacionamentos, pois este é um conceito fundamental para
entender o SQL Server 2005.
RELACIONAMENTO DO TIPO UM PARA UM

Esta relação existe quando os campos que se relacionam são ambos chaves primárias em suas respectivas
tabelas. Cada um dos campos não apresenta valores repetidos. Na prática existem poucas situações
onde utilizaremos um relacionamento deste tipo.
Vamos imaginar o seguinte exemplo: uma escola com um cadastro de alunos na tabela Alunos, e destes
apenas uma pequena parte participa da banda da escola. Por questões de projeto do Banco de Dados
podemos optar por criar uma segunda tabela “Alunos da Banda”, a qual pode se relacionar com a
tabela Alunos através de um relacionamento Um para Um. Cada aluno somente é cadastrado uma vez
na tabela Alunos e uma única vez na tabela Alunos da Banda. Poderíamos utilizar o campo “Matrícula
do Aluno” como o campo que relaciona as duas tabelas.
Na tabela Alunos da Banda poderíamos colocar apenas o número da matrícula do aluno, além das
informações a respeito do instrumento que ele toca, tempo de banda, etc. Quando fosse necessário
buscar as informações tais como Nome, Endereço, etc., estas poderiam ser recuperadas através do
relacionamento existente entre as duas tabelas, evitando, com isso, que a mesma informação (Nome,
Endereço, etc.) tenha que ser duplicada nas duas tabelas, diminuindo a probabilidade de erros de digitação.
Na Figura 1.4 vemos o exemplo de um relacionamento do tipo Um para Um entre as tabelas Alunos e
Alunos da Banda.
Figura 1.4 Um relacionamento do tipo Um para Um.
RELACIONAMENTO DO TIPO UM PARA VÁRIOS

Este, sem nenhuma dúvida, é o tipo de relacionamento mais comum entre duas tabelas. Uma das
tabelas (o lado Um do relacionamento) possui um campo que é a chave primária e a outra tabela (o
lado Vários) se relaciona através de um campo cujos valores podem se repetir.
Considere o exemplo entre a tabela Clientes e a tabela Pedidos. Cada cliente é somente cadastrado
uma única vez na tabela Clientes (por isso o campo Código do Cliente é uma chave primária,
indicando que não podem ser cadastrados dois clientes com o mesmo valor no campo Código do
cliente). Com isso a tabela Clientes será o lado Um do relacionamento. Por outro lado, cada cliente
pode fazer diversos pedidos, portanto o mesmo valor para o campo Código do Cliente poderá
aparecer várias vezes na tabela Pedidos – tantas vezes quantos forem os pedidos que o Cliente tiver
feito. Por exemplo, se o cliente cujo código for ALFKI tiver feito 10 pedidos, o código deste cliente
aparecerá em 10 registros diferentes, na tabela Pedidos. Já na tabela Clientes, o código ALFKI
aparecerá em um único registro, o qual representa o cadastro do cliente. Por isso que temos um
relacionamento do tipo Um para Vários entre as tabelas Clientes e Pedidos, através do campo
Código do Cliente, indicando que um mesmo cliente pode fazer diversos pedidos. O lado um é na
tabela Clientes – cada cliente será cadastrado um única vez; o lado vários é a tabela Pedidos – cada
cliente poderá fazer vários pedidos.
Na Figura 1.5, vemos um exemplo de um relacionamento Um para Vários entre as tabelas Clientes e
Pedidos, através do campo Código do cliente.
No lado Um do relacionamento o campo é definido como uma chave primária (campo CódigoDoCliente
na tabela Clientes) e no lado Vários o campo CódigoDoCliente não é uma chave primária (campo
CódigoDoCliente na tabela Pedidos), indicando que no lado Vários o código do cliente pode se repetir,
o que faz sentido, uma vez que um mesmo cliente pode fazer diversos pedidos.
Figura 1.5 Um relacionamento do tipo Um para Vários.
Podemos citar outro exemplo clássico de relacionamentos do tipo Um para Vários: entre as tabelas
Pedidos e Detalhes do Pedido, através do campo NúmeroDoPedido. Na tabela Pedidos o campo
NúmeroDoPedido é chave primária (não podem ser cadastrados dois ou mais pedidos com o mesmo
número). Na tabela Detalhes do Pedido, o campo NúmeroDoPedido não é chave primária. Na tabela
Detalhes do Pedido, temos as informações sobre os diversos itens de cada pedido. Este relacionamento
indica que “um” mesmo “pedido” pode ter “diversos itens”, o que faz sentido.
Na Figura 1.6, vemos um exemplo de um relacionamento Um para Vários entre as tabelas Pedidos e
Detalhes do Pedido, através do campo NúmeroDoPedido.
Figura 1.6 Mais um exemplo de relacionamento do tipo Um para Vários.

NOTA
O campo do lado Vários do relacionamento também é conhecido como sendo uma “Chave Estrangeira”. No exemplo da Figura 1.6, o campo
NúmeroDoPedido, na tabela Detalhes do Pedido, seria a nossa Chave Estrangeira do relacionamento em questão. No exemplo da Figura 1.5,
o campo CódigoDoCliente, na tabela Clientes, seria a chave estrangeira.
RELACIONAMENTO DO TIPO VÁRIOS PARA VÁRIOS

Este tipo de relacionamento ocorre em uma situação onde, em ambos os lados do relacionamento, os
valores podem se repetir. Vamos considerar o caso entre as tabelas Produtos e Pedidos. Posso ter vários
pedidos nos quais aparece um determinado produto, e além disso vários produtos podem aparecer no
mesmo pedido. Esta é uma situação em que temos um relacionamento do tipo Vários para Vários:
vários produtos podem aparecer em vários pedidos, e vários pedidos podem conter vários produtos.
Na prática não temos como implementar um relacionamento deste tipo, devido a uma série de problemas
que este tipo de relacionamento traria.
Para evitar problemas, é bastante comum “quebrarmos” um relacionamento do tipo Vários para Vários
em dois relacionamentos do tipo Um para Vários. Isso é feito através da criação de uma nova tabela, a
qual fica com o lado Vários dos relacionamentos. No nosso exemplo poderíamos criar a tabela Detalhes
do Pedido, onde ficam armazenadas as informações sobre os diversos itens de cada pedido. Desta
forma, ao invés de termos um relacionamento do tipo Vários para Vários, teremos dois relacionamentos
do tipo Um para Vários, conforme indicado na Figura 1.7:
Figura 1.7 “Quebrando” um relacionamento Vários para Vários.
Esta situação, em que um relacionamento Vários para Vários é “quebrado” em dois relacionamentos
do tipo Um para Vários, é bastante comum. Diversas vezes utilizamos esta técnica para eliminar uma
série de problemas no Banco de Dados, tais como informação repetida, inconsistência de dados e
“mistura” de dois ou mais assuntos na mesma tabela.
Agora que já conhecemos os tipos de relacionamentos existentes, veremos o conceito de Integridade

Referencial. O mecanismo da Integridade Referencial nos garante a consistência dos dados.
INTEGRIDADE REFERENCIAL
A Integridade Referencial é utilizada para garantir a integridade dos dados entre as diversas tabelas
relacionadas de um Banco de Dados, evitando inconsistências nos dados, bem como repetições
desnecessárias.
Por exemplo, existe um relacionamento do tipo Um para Vários entre a tabela Clientes e a tabela
Pedidos (um cliente pode fazer vários pedidos). Com a Integridade Referencial, o Banco de Dados não
permite que seja cadastrado um pedido para um cliente que ainda não foi cadastrado na tabela de
clientes. Através da Integridade Referencial, também podemos garantir outros mecanismos importantes:
♦ Quando o código de um cliente for alterado na tabela Clientes, o Banco de Dados atualiza,
automaticamente, todos os códigos do cliente na tabela Pedidos, de tal maneira que não fiquem
registros órfãos, isto é, registros de pedidos com um código de cliente que não existe mais na
tabela Clientes. Essa ação é conhecida como “Propagar atualização dos campos relacionados”
ou “Propagar atualizações em cascata”.
♦ Quando um cliente for excluído da tabela Clientes, podemos pedir para que o Banco de Dados
exclua, na tabela Pedidos, todos os pedidos para o cliente que está sendo excluído. Essa opção
é conhecida como “Propagar exclusão dos registros relacionados” ou “Propagar exclusões em
cascata”, e pode ser habilitada ou não, dependendo do projeto do Banco de dados. Caso seja
necessário manter todo o histórico de compras do cliente, por exemplo, esta opção não deve
ser habilitada. Com isso, quando o cliente for eliminado da tabela Clientes, os seus pedidos
continuarão gravados na tabela Pedidos.
Essas opções são definidas no momento da criação do Banco de Dados, quando da criação das tabelas
e dos relacionamentos entre as tabelas.
A opção de “Propagar atualização dos campos relacionados” é utilizada na maioria das situações, já a
opção de “Propagar exclusão dos registros relacionados” deve ser estudada, caso a caso.
NORMALIZAÇÃO DE TABELAS
O objetivo da normalização é evitar os problemas provocados por falhas no projeto do Banco de
Dados, bem como eliminar a “mistura” de assuntos e as correspondentes redundâncias de dados. A
normalização de tabelas é utilizada para tentar detectar erros no projeto das tabelas e atributos de cada
tabela e corrigir estes erros, antes da criação e utilização do Banco de Dados. É bem mais fácil (e
barato), corrigir os erros na fase de projeto do que depois que o Banco de Dados já está em uso.
Uma “Regra de Ouro” que devemos observar quando do projeto de Banco de Dados é a de “não
misturar assuntos em uma mesma tabela”, conforme já descrito anteriormente.
Por exemplo, na tabela Clientes devemos colocar somente campos relacionados com o assunto Clientes.
Não devemos misturar campos relacionados com outros assuntos, tais como pedidos, produtos, etc.
Essa “mistura de assuntos” em uma mesma tabela acaba por gerar repetição desnecessária dos dados
bem como inconsistência dos dados.
O processo de normalização aplica uma série de regras sobre as tabelas de um Banco de Dados, para
verificar se estas estão corretamente projetadas. Embora existam cinco formas normais (ou regras de
normalização), na prática usamos um conjunto de três formas normais.
Freqüentemente, após a aplicação das regras de normalização, algumas tabelas acabam sendo divididas
em duas ou mais, o que no final gera um número maior de tabelas do que o número de tabelas
originalmente projetado. Este processo causa a simplificação dos atributos de uma tabela, colaborando
significativamente para a estabilidade do projeto do Banco de Dados, reduzindo-se as necessidades de
manutenção e alterações, após o banco ter sido colocado em produção.
Vamos estudar e entender o processo de normalização através de exemplos práticos.
PRIMEIRA FORMA NORMAL

Regra: “Uma tabela está na Primeira Forma Normal quando seus atributos não contêm grupos de repetição.”
Por isso dissemos que uma tabela que possui grupos de repetição não está na Primeira Forma Normal.
Considere a Figura 1.8:
Figura 1.8 Uma tabela que não está na Primeira Forma Normal.
Podemos notar que uma tabela com esta estrutura apresenta diversos problemas. Por exemplo, se um
casal tiver mais do que um filho, teríamos que digitar o nomes do pai e da mãe diversas vezes, tantas
quantos forem os filhos. Isso forma um grupo de repetição. Pode ser que, por erro de digitação, o nome
dos pais não apareça exatamente igual todas as vezes, o que pode acarretar problemas na hora de fazer
pesquisas ou emitir relatórios. Este problema ocorre porque misturamos assuntos em uma mesma
tabela. Colocamos as informações dos pais e dos filhos em uma mesma tabela.
A solução para este problema é simples: criamos uma tabela separada para a informação dos pais e
relacionamos a tabela Pais com a tabela Filhos através de um relacionamento do tipo Um para Vários,
ou seja, Um casal pode ter vários filhos. Esta solução é indicada na Figura 1.9.
Figura 1.9 As tabelas Pais e Filhos estão na Primeira Forma Normal.
As duas tabelas resultantes da aplicação da Primeira Forma Normal, Pais e Filhos, estão na Primeira
Forma Normal. A tabela original, a qual misturava informações de pais e filhos, não está na
Primeira Forma Normal.
SEGUNDA FORMA NORMAL

Podemos aplicar a Segunda Forma Normal quando tivermos uma chave primária composta. Neste
caso, devemos observar se todos os campos, que não fazem parte da chave primária composta, dependem
de todos os campos que compõem a chave primária composta. Se algum campo depender somente de
parte da chave primária composta, então este campo deve pertencer a outra tabela.
Observe o exemplo indicado na Figura 1.10:
Figura 1.10 Uma tabela que não está na Segunda Forma Normal.
A chave primária composta é formada pela combinação dos campos NúmeroDaMatrícula e

CódigoDoCurso. O campo Avaliação depende tanto do CódigoDoCurso quanto do NúmeroDaMatrícula
(cada aluno – representado por sua matrícula, tem uma nota em cada disciplina – representada pelo
campo CódigoDocurso), porém o campo DescriçãoDoCurso depende apenas do CódigoDoCurso (a
descrição do curso não tem relação com o NúmeroDaMatrícula). Com isso, temos um campo que não
faz parte da Chave Primária composta e depende apenas de um dos campos que compõem a chave
primária composta. Assim podemos dizer que esta tabela não está na Segunda Forma Normal.
A resolução para este problema também é simples: dividimos a tabela, que não está na Segunda Forma
Normal, em duas outras tabelas, conforme indicado pela Figura 1.11, sendo que as duas tabelas
resultantes estarão na Segunda Forma Normal.
Figura 1.11 Duas tabelas que estão na Segunda Forma Normal.

NOTA
A distinção entre a Segunda e a Terceira Forma Normal, que veremos no próximo item, muitas vezes é confusa. A Segunda Forma Normal
está ligada à ocorrência de chaves primárias compostas.
TERCEIRA FORMA NORMAL

Na definição dos campos de uma tabela podem ocorrer casos em que um campo não seja dependente
diretamente da chave primária, ou de parte dela, mas sim dependente de um outro atributo constante
na tabela, atributo este que não seja a chave primária.
Quando isto ocorre, dizemos que a tabela não está na Terceira Forma Normal, conforme indicado pela
Figura 1.12:
Figura 1.12 Uma tabela que não está na Terceira Forma Normal.
Observe que o campo DescriçãoDoCurso depende apenas do campo CódigoDoCurso, o qual não faz
parte da chave primária. Por isso dizemos que esta tabela não está na Terceira Forma Normal.
A solução para este caso também é simples. Novamente basta dividir a tabela em duas outras, conforme
indicado pela Figura 1.13. As duas tabelas resultantes estão na Terceira Forma Normal.
Figura 1.13 Duas tabelas que estão na Terceira Forma Normal.

NOTA
Com isso podemos concluir que, como resultado do processo de normalização, iremos obter um número maior de tabelas do que o existente
antes do processo de normalização, porém sem problemas de redundância e inconsistência dos dados, ou com estes problemas minimizados.
PASSOS PARA PROJETAR UM BANCO DE DADOS

Neste item apresentarei os passos básicos para projetar um Banco de Dados. Mostrarei como aplicar os
conhecimentos sobre Entidades, Atributos, Relacionamentos, Chave Primária e Normalização.
Um Banco de Dados bem projetado fornece um acesso conveniente às informações desejadas, de tal
maneira que as informações estejam disponíveis para os usuários que dela necessitarem no momento
em que a informação for necessária.
NOTA
Neste item estou falando do projeto físico do Banco de Dados, isto é, a definição de quais tabelas e do relacionamento entre as tabelas. O
resultado final desta fase será o que chamamos de Diagrama Entidade x Relacionamentos. O projeto completo de uma aplicação de n
camadas que irá rodar na rede de uma empresa envolve várias outras etapas. A descrição completa de todas as etapas foge ao escopo deste
livro, sendo disciplina de Análise de Sistemas. Um bom livro sobre o assunto é o seguinte: “Analyzing Requirementes and Defining Solution
Architectures MCSD Training Kit”, Microsoft Press, ISBN: 0735608547.
Etapas no projeto e estruturação de um Banco de Dados:
♦ Determinar qual o objetivo do Banco de Dados. Isto ajuda na determinação de quais dados
devem ser armazenados.
♦ Determinar as tabelas necessárias. Após definirmos o objetivo do Banco de Dados, as informações

devem ser definidas e separadas em assuntos diferentes, tais como Clientes, Empregados, Pedidos,
pois cada um irá compor uma tabela no Banco de Dados.
♦ Determinar os campos necessários em cada tabela. Definir quais informações devem ser mantidas
em cada tabela. Por exemplo, a tabela Clientes poderia ter um campo para o código do cliente,
outro para o nome do cliente e assim por diante.
♦ Determinar quais campos serão as chaves primárias. Determinar, em cada tabela, qual ou
quais campos serão utilizados como chave primária. Esta é uma etapa importante para a
definição dos relacionamentos que vêm a seguir. Podem ocorrer casos onde uma tabela não
tem chave primária.
♦ Determinar os relacionamentos entre as tabelas. Decidir como os dados de uma tabela se
relacionam com os dados de outras tabelas. Por exemplo, clientes podem fazer vários pedidos.
fornecedores podem fornecer vários produtos, etc.
♦ Refinar a estrutura do Banco de Dados. Antes de inserir muitos dados, ou até mesmo
antes de inserir qualquer dado, verificar se a estrutura contém erros, isto é, verificar se os
resultados obtidos são os desejados. Isto é feito através do processo de normalização de
tabelas, descrito anteriormente.
Com uma boa estrutura, gasta-se menos tempo na construção e manutenção do Banco de Dados e, ao
mesmo tempo, assegura-se resultados mais rápidos e precisos.
Dicas para determinação dos campos em uma tabela:
♦ Relacionar diretamente cada campo ao assunto da tabela. Se um campo descreve o assunto de

uma tabela diferente, este campo deve pertencer a outra tabela. O mesmo acontece quando
uma informação se repete em diversas tabelas. Este é um indício de que existem campos
desnecessários em algumas tabelas.
♦ Não incluir dados derivados ou calculados. Não é recomendado armazenar o resultado de
cálculos nas tabelas. O correto é que o cálculo seja executado quando necessitarmos do resultado.
Normalmente os cálculos são efetuados com o uso de consultas (Views – Capítulo 9) ou através
de programação (usando Stored Procedures – Capítulo 10).
♦ Incluir todas as informações necessárias. Como é fácil esquecer informações importantes, deve-
se ter em mente todas as informações coletadas desde o início do processo e perguntar se com
elas é possível obter todos os resultados esperados.
♦ Armazenar todas as informações separadamente. Existe uma tendência em armazenar

informações em um único campo. Por exemplo, o nome do curso e o tempo de duração em um
mesmo campo. Como as duas informações foram combinadas em um único campo, ficará
difícil conseguir um relatório classificado pelo tempo de duração dos cursos, por exemplo.
Como escolher o campo que será a chave primária?
Um bom Sistema Gerenciador de Banco de Dados Relacionais (SGBDR) é aquele que encontra e nos fornece,
rapidamente, todas as informações necessárias que nele estejam armazenadas, mesmo em diferentes tabelas.
Para que isto seja possível é necessário incluir um campo ou conjunto de campos que identifiquem de um
modo único cada registro de uma tabela. Esta informação é chamada chave primária, conforme descrito
anteriormente. Deve-se ter certeza de que este campo (ou conjunto de campos) seja sempre diferente para
cada registro, por não serem permitidos valores duplicados em um campo de chave primária.
Figura 1.14 Um diagrama Entidade x Relacionamentos.
Ao escolher campos de chave primária, considere os seguintes detalhes:
♦ Não é permitida duplicidade de valores ou nulos (informações desconhecidas).
♦ Caso não exista um identificador único para uma determinada tabela, pode-se usar um campo
que numere os registros seqüencialmente.
♦ Pode-se utilizar o valor deste campo para encontrar registros.
♦ O tamanho da chave primária afeta a velocidade das operações, e portanto, para um melhor
desempenho, devemos utilizar o menor tamanho que acomode os valores necessários para
armazenar no campo.
Na Figura 1.14, temos um exemplo de um diagrama Entidade x Relacionamentos. Este diagrama mostra
a estrutura do Banco de Dados Nwind.mdb, o qual é fornecido juntamente com o Microsoft Access 97
e também como exemplo na instalação do Microsoft SQL Server 2000. Os campos que são chave
primária estão indicados em negrito.
FUNDAMENTOS EM: NOÇÕES BÁSICAS DA LINGUAGEM

SQL – STRUCTURED QUERY LANGUAGE
PRÉ-REQUISITOS
♦ Noções sobre os elementos básicos do modelo relacional.
METODOLOGIA
♦ Apresentação dos principais comandos e cláusulas da linguagem SQL.
TÉCNICA
♦ Utilização de exemplos práticos.
Como o próprio nome sugere, a linguagem para acesso a dados, utilizada pelo Microsoft SQL Server
2005, é o T-SQL – Transact - Structured Query Language. A linguagem T-SQL é utilizada para uma série
de operações, como por exemplo:
♦ Selecionar um conjunto de registros com base em um ou mais critérios de pesquisa.
♦ Criar um Banco de Dados.
♦ Criar novas tabelas.
♦ Excluir registros.
♦ Criar e alterar índices.
♦ Definir permissões de segurança, etc.
Embora a maioria destas operações possa ser feita através da interface gráfica do Microsoft SQL Server
2005 (SQL Server Management Studio), existem situações em que precisamos conhecer e utilizar a
linguagem T-SQL. Para a criação de Stored Procedures, Triggers e outros recursos avançados, iremos
utilizar a linguagem T-SQL.
Neste item eu apresentarei uma noção básica da linguagem T-SQL. Você aprendera os comandos para
manipulação de dados – consultar, inserir, alterar e excluir. Em todos os demais capítulos deste livro,
serão utilizados comandos da linguagem T-SQL, os quais serão explicados nos momentos devidos.
INTRODUÇÃO
A linguagem T-SQL foi desenvolvida para ser uma linguagem padrão para operações em Banco de
Dados. A linguagem T-SQL foi elaborada para ser independente de hardware ou software. Ao usar T-
SQL, você não precisa saber a respeito do software de Banco de Dados ou do hardware envolvido em
uma operação. Tudo o que você precisa conhecer é o método (instrução) T-SQL a ser utilizado, para
solicitar informações desejadas.
NOTA
Na prática, existem pequenas diferenças nas implementações da linguagem SQL de diferentes fabricantes. Desta forma, algumas rotinas
escritas utilizando o SQL Plus do Oracle podem não rodar, sem alterações no Microsoft SQL Server e vice-versa.
Na listagem a seguir temos um exemplo de uma instrução T-SQL. Embora a instrução, em um

primeiro momento, possa parecer complexa, veremos que a linguagem T-SQL é bastante simples
e de fácil aprendizado.
Exemplo de um comando T-SQL:
SELECT Orders.OrderID, Orders.OrderDate, Orders.ShipCountry, Orders.ShipCity

FROM Orders
WHERE Orders.ShipCountry Like ‘[A-M]%’
AND
Orders.OrderDate > 01/01/1997
ORDER BY Orders.OrderDate
NOTA
Por questões de simplicidade, deste ponto em diante (e também nos demais capítulos), farei referência à linguagem T-SQL, usando apenas
o termo “linguagem SQL” ou “instrução SQL”.
Uma instrução SQL descreve o conjunto de dados que você deseja obter (quais campos, de quais
tabelas, quais critérios de filtragem utilizar, qual a classificação aplicada, expressões calculadas, etc.).
Todas as instruções SQL são executadas como se fossem um único comando, o qual contém uma
descrição completa das informações que devem ser retornadas. Ao escrever uma instrução SQL, você
não deve se preocupar em como os dados serão recuperados, mas somente com o conteúdo do conjunto
de dados que você deseja obter. Esse é o principal benefício da linguagem SQL.
Lembre-se que o SQL é um padrão genérico para expressões de consulta em Banco de Dados. Embora
a maior parte das versões do SQL compartilhe elementos básicos, elas não são idênticas. O Access SQL
usa algumas palavras-chave que você não encontra em outras versões do SQL. Também existem pequenas
diferenças entre o Microsoft Access e o Microsoft SQL Server.
Veremos, através de exemplos, a utilização das principais palavras-chave do SQL para a construção de
expressões SQL para pesquisa e operações em tabelas de um Banco de Dados.
A INSTRUÇÃO SELECT
Esta, sem dúvidas, é a instrução SQL mais importante e mais utilizada. Não existe pesquisa que não
utilize esta instrução. Vamos conhecê-la em detalhes.
A instrução Select é utilizada para especificar quais os campos de quais tabelas farão parte da consulta,
quais os critérios de pesquisa que serão utilizados, qual a ordem de classificação, etc.
A sintaxe simplificada da instrução é a seguinte:
SELECT
campo1, campo2, campo3
FROM nome_da_tabela
[WHERE condição ]
[GROUP BY nome_do_campo ]
[HAVING ... ]
[ORDER BY... ]
Na Tabela 1.2 temos uma descrição destes elementos.
Tabela 1.2 Os principais elementos da instrução Select.
Elemento Descrição
campo1, campo2... campon Nome dos campos a serem retornados a partir de uma ou mais tabelas.
nome_da_tabela Nome da tabela a partir da qual os dados devem ser recuperados.
WHERE Permite que sejam especificados critérios de pesquisa.
GROUP BY Podemos agrupar os resultados em torno de um ou mais campos de dados. Por exemplo, em
um relatório de vendas anuais, posso ter os resultados agrupados por mês, com a soma das
vendas do mês logo após a listagem das vendas.
HAVING Especifica critérios para serem utilizados juntamente com Group By.
ORDER BY Podemos ordenar os resultados obtidos com base em um ou mais campos de dados. Por
exemplo, podemos ordenar uma listagem de vendas em ordem alfabética do nome do cliente
ou do nome do vendedor.
Vamos analisar alguns exemplos práticos de utilização da linguagem SQL.
Exemplo 1: Criar uma instrução SQL que retorne os campos NúmeroDoPedido, DataDoPedido, Frete e
PaísDeDestino da tabela Pedidos.
SELECT Pedidos.NúmeroDoPedido, Pedidos.DataDoPedido, Pedidos.PaísDeDestino, Pedidos.Frete FROM Pedidos
Observe que os nomes dos campos estão separados por vírgula; além disso estamos utilizando o nome
completo, isto é: Nome_da_tabela.Nome_do_campo. Também poderíamos utilizar o comando, sem o
nome da tabela antes do nome do campo, conforme indicado no seguinte comando:
SELECT NúmeroDoPedido, DataDoPedido, PaísDeDestino, Frete FROM Pedidos

NOTA
Somente é obrigatória a utilização do nome da tabela antes do nome do campo quando o mesmo campo existir em duas ou mais tabelas que
fazem parte da instrução Select, para indicar de qual tabela deve ser retornado o respectivo campo.
Por exemplo, imagine que estejamos escrevendo uma instrução SQL para criar uma listagem com o
código e o nome do cliente, bem como todos os pedidos efetuados pelo cliente. Acontece que o código
do cliente, no nosso exemplo, existe em duas tabelas: Clientes e Pedidos. Neste caso devemos especificar
o nome da tabela, antes do nome do campo.
Exemplo 2: Alterar a instrução SQL anterior para que os registros sejam classificados em ordem crescente
pelo valor do frete.

ORDER BY Frete
Observe a utilização da cláusula “ORDER BY Frete” para classificar os registros em ordem crescente. A
classificação em ordem crescente é a padrão. Quando formos classificar em ordem decrescente,
precisamos especificar a palavra DESC, conforme indicado no seguinte comando:

ORDER BY Frete DESC
Exemplo 3: Agora vamos começar a inserir critérios de filtragem. Muitas vezes as condições são
chamadas de filtro e, uma vez estabelecida uma condição, somente os registros que “atendem” a
condição especificada serão retornados. Desta forma a condição atua como se fosse um filtro.
Neste exemplo, vamos alterar a instrução SQL anterior para que sejam exibidos somente os pedidos
cujo PaísDeDestino seja Brasil.

WHERE PaísDeDestino=‘Brasil’
ORDER BY Frete
Observe a utilização da cláusula WHERE para filtrar somente os pedidos cujo campo PaísDeDestino
contenha o valor Brasil. Como o campo PaísDeDestino é um campo do tipo texto, o valor do critério
(Brasil) tem que vir entre apóstrofes. Vamos trabalhar um pouco mais com a cláusula WHERE.
Exemplo 4: Altere a instrução SQL anterior para que sejam exibidos somente os pedidos para o Brasil
ou Alemanha como PaísDeDestino.

WHERE Pedidos.PaísDeDestino=‘Brasil’ OR Pedidos.PaísDeDestino=‘Alemanha’
ORDER BY Frete
Observe a utilização da cláusula OR ligando os dois critérios. Lembre que a cláusula OR retorna um
registro se o PaísDeDestino atender um dos dois critérios. Assim, se for Brasil ou se for Alemanha, o
registro será selecionado, o que é exatamente o que desejamos, ou seja, todos os pedidos para o Brasil
ou todos os pedidos para a Alemanha.
Exemplo 5: Altere a instrução SQL anterior, retirando o critério para PaísDeDestino. Adicione um
critério para NúmeroDoPedido maior do que 10500, retire a classificação do campo Frete e classifique
pelo campo NúmeroDoPedido.

WHERE NúmeroDoPedido>10500
ORDER BY NúmeroDoPedido
Observe a cláusula WHERE utilizando o operador de comparação maior do que ( > ) e a classificação
através da cláusula ORDER BY no campo NúmeroDoPedido.
Podemos ver, através dos exemplos, que a linguagem SQL não é tão difícil como pode parecer à primeira vista.
Observe que a sintaxe da linguagem é bastante intuitiva e orientada à extração de dados, através das consultas.
Vamos continuar analisando alguns exemplos de aplicação da linguagem SQL com a utilização de
recursos mais avançados.
Exemplo 6: Alterar a instrução SQL anterior, e adicionar um critério de tal maneira que somente sejam
exibidos os pedidos para o ano de 1995. Tirar o critério do campo NúmeroDoPedido.

WHERE Year(DataDoPedido)=1995
Observe a utilização da função YEAR para extrairmos apenas o ano do campo DataDoPedido a fim de
especificarmos como critério o Ano=1995. Também a cláusula ORDER BY foi mantida, classificando a
listagem em ordem crescente pelo número do pedido. A utilização de funções junto com os comandos
SQL nos fornece inúmeras possibilidades de refinamento em nossas consultas.
Exemplo 7: Alterar a instrução SQL anterior, para que sejam exibidos somente os pedidos no período de
01/01/1995 até 31/08/1995 e que tenham como PaísDeDestino Brasil, Argentina, Alemanha ou Canadá.

WHERE DataDoPedido Between ‘1/1/95’ And ‘8/31/95’
AND
PaísDeDestino In (‘Brasil’,‘Argentina’,‘Alemanha’,‘Canadá’)
Observe a utilização de vários critérios em diferentes campos. Colocamos critérios nos campos
DataDoPedido e PaísDeDestino. Os critérios de dois ou mais campos são ligados através do operador
AND, indicando que um registro deve atender ambos os critérios para ser selecionado. Também
temos a utilização dos operadores BETWEEN (Entre) para selecionar as datas dentro de um
determinado intervalo e do operador IN (Em) para selecionar o campo PaísDeDestino que seja
igual a um dos valores apresentados na lista. Observe, também, que os valores de data vêm
delimitados por apóstrofes (‘).
Exemplo 8: Criar uma instrução SQL que retorne os campos NúmeroDoPedido, DataDoPedido,
DataDeEntrega, Frete e PaísDeDestino da tabela Pedidos. Criar uma coluna adicional que calcula o
número de dias entre a DataDeEntrega e a DataDoPedido. Chamar esta coluna de Dias_Ped_Entr.
SELECT NúmeroDoPedido, DataDoPedido, DataDeEntrega, PaísDeDestino, Frete, DataDeEntrega-

DataDoPedido AS Dias_Ped_Entr FROM Pedidos
WHERE (DataDoPedido Between ‘1/1/95’ And ‘8/31/95’)
AND
(PaísDeDestino In (‘Brasil’,‘Argentina’,‘Alemanha’,‘Canadá’))
ORDER BY Pedidos.NúmeroDoPedido
Veja que a coluna calculada DataDeEntrega-DataDoPedido está junto com a listagem dos campos no
início da instrução Select. Além disso, foi utilizada a palavra AS para atribuir um nome (apelido) para
esta coluna calculada. Este nome é o que será utilizado para fazer referência à coluna, em uma página
ASP ou um programa desenvolvido em Visual Basic, por exemplo.
Você também pode classificar a listagem em ordem crescente ou decrescente de um campo calculado.
Por exemplo, se você quisesse classificar a listagem do item anterior, em ordem crescente, do número
de dias entre a DataDeEntrega e a DataDoPedido, bastaria utilizar a seguinte instrução SQL:
DataDoPedido AS Dias_Ped_Entr
FROM Pedidos
WHERE (DataDoPedido Between ‘1/1/95’ And ‘8/31/95’)
AND
(PaísDeDestino In (‘Brasil’,‘Argentina’,‘Alemanha’,‘Canadá’))
ORDER BY DataDeEntrega-DataDoPedido
Exemplo 9: Alterar a instrução SQL anterior, eliminando os critérios para a DataDoPedido e para o
PaísDeDestino. Colocar um novo critério para PaísDeDestino, onde sejam exibidos apenas os pedidos
cujo PaísDeDestino tem a primeira letra na faixa de A até M. Utilize o operador LIKE.

DataDoPedido AS Dias_Ped_Entr
FROM Pedidos
WHERE PaísDeDestino Like ‘[A-M]%’
ORDER BY PaísDeDestino
Observe a utilização do operador Like no critério de pesquisa para esta consulta. Nunca é demais
salientar que a utilização das instruções SQL juntamente com as funções e operadores, como o LIKE,
nos fornecem um amplo conjunto de possibilidades. O caractere % é utilizado como um caractere
curinga. Por exemplo, se especificarmos o seguinte critério:
WHERE NomeDoCLiente Like ‘João%’
serão retornados todos os registros para clientes cujo nome inicia com João. O caractere curinga %
significa, em termos simples: “qualquer coisa”, ou seja, o critério especifica que o nome inicie com
João, não importando (qualquer coisa) o que vier depois.
NOTA
Aqui cabe um aviso importante para os usuários do Microsoft Access. Naquele aplicativo, o caractere curinga é o *, já no Microsoft SQL Server
2005 (e também nas versões anteriores do SQL Server), utilizamos como caractere curinga o %, o qual também é utilizado na construção de
páginas ASP. Para maiores informações sobre a tecnologia ASP – Active Server Pages, consulte o e-book “Criando Sites Dinâmicos com ASP
3.0”, 732 páginas, de minha autoria, disponível no formato .PDF em: http://www.juliobattisti.com.br/ebooksdoautor
Até agora trabalhamos com instruções que selecionam registros de uma única tabela. Porém é
bastante comum criarmos instruções SQL baseadas em duas ou mais tabelas. Quando criamos
instruções SQL que buscam dados em duas ou mais tabelas, dizemos que está sendo feito um Join
entre as duas ou mais tabelas.
Normalmente este Join (ou ligação) é feito através de um campo comum às duas tabelas. Por exemplo,
NúmeroDoPedido na tabela Pedidos e NúmeroDoPedido na tabela Detalhes do Pedido. Outro exemplo,
CódigoDoCliente na tabela Pedidos e CódigoDoCliente na tabela Clientes. Pode acontecer de termos
consultas que trabalham com três ou mais tabelas, e neste caso teremos diversos “Joins”. O número de
joins é sempre igual ao número de tabelas menos um. Por exemplo, se a nossa consulta acessar dados
de quatro tabelas, teremos três joins.
Agora passaremos e explorar na prática, através de exemplos, a construção de instruções SQL que
trabalhem com duas ou mais tabelas.
Exemplo 10: Criar uma instrução SQL que selecione os seguintes campos:
♦ NúmeroDoPedido da tabela Pedidos

♦ DataDoPedido da tabela Pedidos
♦ PaísDeDestino da tabela Pedidos
♦ Frete da tabela Pedidos
♦ CódigoDoProduto da tabela DetalhesdoPedido
♦ PreçoUnitário da tabela DetalhesdoPedido
♦ Quantidade da tabela DetalhesdoPedido
Além disso, as tabelas Pedidos e DetalhesDoPedido estão relacionadas pelo campo NúmeroDoPedido,
através de um relacionamento do tipo Um para Vários.
Classificar a listagem em ordem crescente do número do pedido. Para resolver este exemplo podemos
utilizar a seguinte instrução SQL:
SELECT Pedidos.NúmeroDoPedido, Pedidos.DataDoPedido, Pedidos.PaísDeDestino, Pedidos.Frete,

DetalhesdoPedido.CódigoDoProduto, DetalhesdoPedido.PreçoUnitário, DetalhesdoPedido.Quantidade
FROM Pedidos
INNER JOIN
DetalhesdoPedido
ON Pedidos.NúmeroDoPedido = DetalhesdoPedido.NúmeroDoPedido
Primeiro devemos observar que, pelo fato de tratarmos com dados de duas tabelas, estamos utilizando
a nomenclatura completa, isto é, Nome_da_tabela.Nome_do_campo.
Observe a utilização da cláusula INNER JOIN, ligando as tabelas Pedidos e DetalhesdoPedido, através
do campo NúmeroDoPedido, conforme especificado na cláusula ON, onde temos o seguinte:
Observe que esta listagem irá trazer vários registros para cada pedido, tantos quantos forem os itens de
cada pedido.
Mas, se ao invés do CódigoDoProduto, nós quiséssemos que fosse exibida a descrição do produto?
Em primeiro lugar esta informação encontra-se na tabela Produtos; logo, teremos que adicionar a tabela
Produtos à nossa consulta, a qual irá se ligar à tabela DetalhesdoPedido através do campo CódigoDoProduto.
Com isso teremos mais um join. Para três tabelas teremos dois joins.
Após adicionar a tabela Produtos e substituir o campo CódigoDoProduto pelo campo NomeDoProduto,
a nossa instrução SQL deve ficar conforme indicado no seguinte comando:

Produtos.NomeDoProduto, DetalhesdoPedido.PreçoUnitário, DetalhesdoPedido.Quantidade
FROM Produtos
INNER JOIN (Pedidos INNER JOIN DetalhesdoPedido
ON Pedidos.NúmeroDoPedido=DetalhesdoPedido.NúmeroDoPedido)
ON
Produtos.CódigoDoProduto=DetalhesdoPedido.CódigoDoProduto
Observe que neste caso temos um INNER JOIN dentro do outro. Dentro do parênteses é feita a ligação
entre as tabelas Pedidos e DetalhesDoPedido, através do campo NúmeroDoPedido, e externamente é
feita a ligação entre as tabelas Produtos e DetalhesdoPedido, através do campo CódigoDoProduto.
Podemos utilizar diversos níveis de INNER JOIN, embora esta não seja uma prática recomendada, pois
se aumentarmos muito os níveis de INNER JOIN, podemos ter como resultado pesquisas mais lentas,
em conseqüência do aumento da complexidade das consultas. Até três ou quatro níveis é considerado
normal, acima disso repense a maneira de construir a consulta.
Exemplo 11: Alterar a instrução SQL do item anterior para que somente sejam exibidos os pedidos para
os produtos cujo NomeDoProduto inicie com uma letra na faixa de A até J. Tirar a classificação do
campo NúmeroDoPedido e classificar em ordem crescente do campo NomeDoProduto.

Produtos.NomeDoProduto, DetalhesdoPedido.PreçoUnitário, DetalhesdoPedido.Quantidade
FROM Pedidos
INNER JOIN (Produtos INNER JOIN DetalhesdoPedido
ON
Produtos.CódigoDoProduto=DetalhesdoPedido.CódigoDoProduto)
ON
Pedidos.NúmeroDoPedido = DetalhesdoPedido.NúmeroDoPedido
WHERE (Produtos.NomeDoProduto Like ‘[A-J]%’)
ORDER BY Produtos.NomeDoProduto
Observe, além dos dois INNER JOIN, a utilização da cláusula WHERE em conjunto com operador Like
para especificar o critério desejado.
Até este momento apresentei instruções SQL que executam consultas em Bancos de Dados. Especifiquei
quais campos serão exibidos, critérios de filtragem para estes campos e uma ordem de classificação. A
partir de agora mostrarei como utilizar instruções SQL para a construção de outros tipos de operações,
tais como operações que realizam alterações nos dados e inclusões de novos registros, em tabelas de
um Banco de Dados.
A INSTRUÇÃO UPDATE
A instrução UPDATE é utilizada para alterar informações em um Banco de Dados. Poderíamos, por
exemplo, criar um formulário onde o usuário pode alterar os seus dados cadastrais. Primeiro os dados
são recuperados a partir do Banco de Dados (usando uma instrução SELECT), e em seguida as alterações
são enviadas de volta para o Banco de Dados, através de uma instrução UPDATE. Vamos estudar esta
instrução através de exemplos, assim como fizemos com a instrução SELECT.
Exemplo 1: Criar uma instrução SQL que aumenta o PreçoUnitário em 20%, em todos os registros da
tabela DetalhesdoPedido, devido a um ajuste na moeda e uma desvalorização em relação ao Dólar.
UPDATE DetalhesdoPedido
SET PreçoUnitário = PreçoUnitário*1.2
Observe a simplicidade da instrução SQL. Utilizamos uma instrução UPTADE, seguida do nome da
tabela onde será feita a atualização. Em seguida uma instrução SET com a expressão de atualização para
aumentar em 20% o PreçoUnitário em todos os registros da tabela DetalhesdoPedido.
Vamos alterar a instrução anterior, para incluir um critério na consulta de atualização.
Exemplo 2: Alterar a instrução SQL do item anterior para que somente seja aumentado em 20%, o
campo PreçoUnitário dos registros cujo PreçoUnitário for maior ou igual a R$20,00.
WHERE PreçoUnitário>=20
Adicionamos uma cláusula WHERE, para atualizar apenas os registros cujo PreçoUnitário seja maior
ou igual a R$20,00.
Exemplo 3: Alterar a instrução SQL do exemplo anterior para que somente sejam aumentados os
registros cujo PreçoUnitário for maior ou igual a R$20,00 e cujo NúmeroDoPedido seja menor
do que 10500.
WHERE (PreçoUnitário>=20)
AND
(NúmeroDoPedido<10500)
Observe que utilizamos critérios em dois campos (PreçoUnitário e NúmeroDoPedido) e que estes critérios
estão ligados por um operador AND, o que significa que um registro somente será atualizado se ele
atender aos dois critérios ao mesmo tempo (PreçoUnitário maior ou igual a 20 e NúmeroDoPedido
menor do que 10500). Se o registro atender apenas uma das condições, o registro não terá o seu
PreçoUnitário atualizado.
Vamos refinar um pouco mais a nossa consulta de atualização. Vamos fazer com que somente sejam
atualizados os pedidos para o ano da DataDoPedido igual a 1995, e ainda iremos manter os critérios
adicionados até agora.
Exemplo 4: Alterar a instrução SQL do exemplo anterior para incluir um critério para que o ano da
DataDoPedido seja 1995. Você terá que incluir a tabela Pedidos, uma vez que o campo DataDoPedido
encontra-se nesta tabela.
UPDATE Pedidos INNER JOIN DetalhesdoPedido

SET DetalhesdoPedido.PreçoUnitário = PreçoUnitário*1.2
WHERE (DetalhesdoPedido.PreçoUnitário>=20)
AND
(DetalhesdoPedido.NúmeroDoPedido<10500)
AND
Year(DataDoPedido)=1995)
Temos diversos detalhes interessantes a observar nesta instrução SQL.
Primeiro um INNER JOIN relacionando as tabelas Pedidos e DetalhesdoPedido, através do campo

NúmeroDoPedido. Isso mostra que é perfeitamente possível utilizar um INNER JOIN dentro de uma
consulta de atualização. Segundo, temos a utilização da função YEAR para extrair apenas o ano do
campo DataDoPedido e compará-lo com o critério 1995, conforme já exemplificado quando dos
exemplos da instrução SELECT.
Novamente a utilização de operadores e funções nos fornece uma grande flexibilidade em termos de
construção de nossas consultas.
A INSTRUÇÃO INSERT
A instrução INSERT é utilizada para adicionar registros em uma tabela de um Banco de Dados. Por
exemplo, quando o usuário preenche os dados de um formulário de cadastro e envia estes dados para
o Banco de Dados, podemos utilizar a instrução INSERT para inserir estes dados em uma tabela do
Banco de Dados.
Vamos analisar alguns exemplos.
Exemplo 1: Este exemplo cria um novo registro na tabela Funcionários:
INSERT INTO Funcionários (Nome, Sobrenome, Cargo)

VALUES (‘Paulo’, ‘Braga’, ‘Estagiário’)
Esta instrução insere um registro na tabela Funcionários com os seguintes dados:
♦ Nome: Paulo
♦ Sobrenome: Braga
♦ Cargo: Estagiário
Exemplo 2: Este exemplo seleciona todos os estagiários de uma tabela Estagiários que tenham sido
contratados há mais de 30 dias e adiciona os registros selecionados à tabela Funcionários.
INSERT INTO Funcionários

SELECT Estagiários.* FROM Estagiários
WHERE DataDaContratação < Date() - 30
Observe que utilizamos a função DATE( ) para capturar a data do sistema e subtraímos 30, para obter
apenas os funcionários contratados a mais do que 30 dias.
A INSTRUÇÃO DELETE
A instrução DELETE é utilizada para excluir registros de um Banco de Dados. Vamos supor que você
tenha desenvolvido uma aplicação Web para agenda eletrônica, onde o usuário pode cadastrar contatos,
endereços, telefones e compromissos. Podemos criar uma página ASP que permite ao usuário eliminar
dados que não sejam mais necessários na agenda. Neste caso podemos fazer uso da instrução DELETE.
Vamos a um exemplo prático.
Exemplo 1: Criar uma instrução SQL que elimine todos os pedidos da tabela Pedidos cujo PaísDeDestino
seja a Alemanha
DELETE Pedidos.PaísDeDestino
FROM Pedidos
WHERE Pedidos.PaísDeDestino=‘Alemanha’
A instrução é tão simples que praticamente dispensa comentários. A única recomendação importante
é que não devemos utilizar uma instrução DELETE, sem a utilização de uma cláusula WHERE. Utilizar
um DELETE sem uma cláusula WHERE significa eliminar todos os registros da tabela.
Neste item apresentei uma breve introdução à linguagem SQL, que no Microsoft SQL Server é chamada
de Transact-SQL (T-SQL). De maneira alguma vimos todas as instruções e comandos disponíveis. Ao
longo deste livro, em diversos momentos, irei utilizar comandos da linguagem SQL. Assim, aprenderemos
detalhes e utilizações mais avançadas desta linguagem.
CONCLUSÃO
Este capítulo, perfeitamente, poderia ser o capítulo inicial de um livro de Oracle, Sybase, Access, DB2
ou de qualquer Banco de Dados relacional. Os conceitos teóricos apresentados neste capítulo são
necessários ao entendimento e utilização de qualquer sistema gerenciador de Banco de Dados Relacional.
Para que possamos utilizar o Microsoft SQL Server, precisamos dominar os conceitos apresentados, tais como:
♦ Modelo Relacional.
♦ Tabelas (Entidades).
♦ Campos (Atributos).
♦ Chave Primária.
♦ Relacionamentos: Um para Um, Um para Vários e Vários para Vários.
♦ Integridade Referencial: Atualizar em cascata e Excluir em cascata.
♦ Regras de Normalização: Primeira, Segunda e Terceira Formas Normais.
♦ A importância do projeto físico do Banco de Dados.
Na seqüência deste capítulo, apresentei uma noção básica da linguagem SQL (Transact-SQL no caso do
Microsoft SQL Server 2005).
Você aprendeu a utilizar diversos elementos da linguagem, como por exemplo:
♦ A instrução SELECT e as suas diversas cláusulas
♦ A instrução UPDATE
♦ A instrução INSERT INTO
♦ A instrução DELETE
♦ O operador LIKE
♦ As cláusulas WHERE e ORDER BY
♦ O operador IN
♦ Os operadores AND e OR
Agora que vimos a parte teórica, estamos prontos para começar a trabalhar com o Microsoft SQL Server
2005. Mas isso já é assunto para o Capítulo 2, onde você aprenderá sobre as novidades do SQL Server
2005 e aprenderá a fazer a instalação do SQL Server 2005 e a fazer o upgrade do SQL Server 7.0 para o
SQL Server 2005 e do SQL Server 2000 para o SQL Server 2005.
NOTA
Não siga para os próximos capítulos sem ter entendido, completamente, os conceitos teóricos apresentados neste capítulo.
Capítulo 2
FUNDAMENTOS DO MICROSOFT
SQL SERVER 2005
INTRODUÇÃO
Neste capítulo você aprenderá sobre os seguintes tópicos:
♦ Aplicações do tipo Cliente/Servidor de duas camadas.
♦ A evolução para as aplicações de três ou mais camadas.
♦ Qual o papel do SQL Server 2005 no desenvolvimento de aplicações de duas ou mais camadas.
♦ As novidades do SQL Server 2005.
♦ As diferentes edições do SQL Server 2005.
♦ Como instalar o SQL Server 2005.
♦ Como fazer o upgrade de versões anteriores do SQL Server.
♦ O conceito de “instância” e como criar várias “instâncias” do SQL Server 2005, no mesmo
servidor.
♦ Verificar se a instalação do SQL Server 2005 foi finalizada com sucesso e quais os serviços
disponíveis.
Com os conceitos apresentados neste capítulo, você terá uma noção clara sobre “o que é” e “em que
situações” pode utilizar o SQL Server 2005.
Outra idéia que vamos procurar esclarecer é sobre qual é o papel de um Banco de Dados como o SQL
Server 2005 nas aplicações empresariais desenvolvidas atualmente. Muitas vezes, temos a noção de
que o Banco de Dados simplesmente cumpre funções tais como:
♦ Armazenar os dados.
♦ Fornecer mecanismos para garantir a integridade dos dados.
♦ Fornecer mecanismos para a recuperação dos dados através de consultas.
♦ Disponibilizar mecanismos de segurança para que não sejam feitos acessos não-autorizados
aos dados.
♦ Fornecer mecanismos de recuperação dos dados em caso de imprevistos e problemas.
Ao finalizar este capítulo, você deverá estar com duas instâncias do SQL Server 2005 instaladas e
funcionando. Nos exemplos dos demais capítulos deste livro, será utilizado um computador Pentium
IV 2.8 GHz, com 1 GB de RAM e com as seguintes configurações:
♦ Windows 2000 Server em português, com Service Pack 4 instalado.
♦ O Windows 2000 está instalado como DC – Domain Controler de um domínio chamado

groza.com.
♦ O número IP utilizado é: 10.1.1.3.
♦ A máscara de sub-rede é: 255.0.0.0.
♦ O nome do servidor é: Servidor, com o nome completo incluindo o domínio: servidor.groza.com.
CAPÍTULO 2 – FUNDAMENTOS DO MICROSOFT SQL SERVER 2005
NOTA
Para maiores informações sobre Controladores de Domínio – DC, configurações do TCP-IP e configuração de um servidor com o Windows
2000 Server, consulte o seguinte livro: “Manual de Estudos Para o Exame 70-217”, 752 páginas, de minha autoria, publicado pela editora
Axcel Books do RJ (http://www.axcel.com.br).
Caso você esteja utilizando um computador com nome, domínio ou configurações de rede diferentes,
utilize os parâmetros da sua configuração nos exercícios que forem apresentados. Por exemplo, se o
nome do seu computador for “testesql”, sempre que necessário, substitua o nome “servidor” pelo
nome que você está utilizando.
Em alguns exemplos, como nos exemplos de instalação e upgrade deste capítulo, utilizarei um segundo
computador Pentium de 1 GHz, com 512 MB de RAM e com as seguintes configurações:
♦ Windows Server 2003 Standard Edition, em português.
♦ Instalado como DC – Domain Controler de um domínio chamado xyz.com.br
♦ O número IP utilizado é: 10.1.1.5.
♦ A máscara de sub-rede é: 255.0.0.0.
♦ O nome do servidor é: Servidor2, com o nome completo incluindo o domínio:

servidor2.xyz.com.br
FUNDAMENTOS EM: MODELO DE APLICAÇÕES

PARA A ERA DO COMÉRCIO ELETRÔNICO
PRÉ-REQUISITOS
♦ Noções básicas de Internet e do modelo relacional.
METODOLOGIA
♦ Apresentação dos elementos que compõem as necessidades de aplicativos empresariais atuais e habilitados para a Internet.
Que estamos no meio de uma revolução que se iniciou no meio da década de 90 e não tem prazo para
terminar (nem sequer sabemos aonde vai chegar), todos nós sabemos, e que esta revolução é marcada
pelo comércio eletrônico, ou o chamado e-business, também todos nós sabemos. As revistas e publicações
especializadas (e muitas que nem sequer são da área) e os meios de comunicação apresentam matérias,
diariamente, sobre o comércio eletrônico. As possibilidades são inúmeras, tanto para as empresas,
quanto para os usuários, quanto para os profissionais envolvidos. O comércio eletrônico deixou de ser
apenas uma previsão em livros e revistas, e passou a ser uma realidade, presente no dia-a-dia de todos
nós, com crescimento sustentado de volume de vendas, ano após ano. Com isso, uma nova geração de
sites está sendo criada, muito mais complexa do que as anteriores, necessitando de ferramentas de
desenvolvimento e gerenciamento cada vez mais sofisticadas.
Por outro lado, as aplicações empresariais, que dão suporte às operações diárias da empresa, também
estão crescendo em complexidade. Para piorar a situação, estas aplicações precisam ser desenvolvidas
em um prazo cada vez menor e com maior qualidade e segurança.
Como desenvolver as aplicações internas, manter o site da empresa sempre atrativo e dar suporte às
operações de comércio eletrônico? Este é o grande desafio das equipes de desenvolvimento, quer sejam
estas internas ou terceirizadas.
Grande parte do orçamento de informática das empresas está direcionado para atividades ligadas ao
comércio eletrônico e ao desenvolvimento dos sistemas informatizados, de uso interno da empresa.
Novas tecnologias surgem todos os dias, prometendo facilitar a criação de sites para comércio eletrônico
e outras atividades envolvidas.
Muitas empresas possuem duas faces bem distintas. Uma é a face, a imagem que é “mostrada” para o
público externo, isto é, para os seus clientes. Para estes a empresa mostra uma fachada de modernidade,
facilidades de atendimento e suporte, através de um site cuidadosamente projetado e implementado.
Porém, para o público interno, isto é, para os funcionários, a empresa oferece sistemas obsoletos, que
não atendem às necessidades reais do trabalho e não facilitam, em nada, a vida dos funcionários. O
pior é que a equipe interna, utilizando sistemas obsoletos, precisa ter um desempenho compatível
com as expectativas dos clientes, os quais esperam o melhor atendimento possível por parte da empresa.
De maneira alguma vou afirmar que a solução mágica que irá solucionar todos os problemas de
desenvolvimento é a utilização do Microsoft SQL Server 2005. O que vou procurar mostrar é que o
papel que o Banco de Dados desempenha é de fundamental importância para que tenhamos sistemas
modernos e funcionais. Dentro deste contexto, acredito que o Microsoft SQL Server, devido as suas
funcionalidades, é uma excelente opção, tanto para o desenvolvimento de aplicativos que darão suporte
ao comércio eletrônico, como para o desenvolvimento dos aplicativos corporativos.
O comércio eletrônico pode acontecer de duas maneiras distintas:
♦ B2B – Business to Business: Acontece quando são feitas transações comerciais entre duas
empresas. Pode ser uma montadora de automóveis comprando peças de um fornecedor, ou
uma livraria encomendando livros de uma editora. Em termos de volume financeiro, o B2B é
responsável por um grande percentual do que é comercializado via Internet.
♦ B2C – Business to Consumer: É um cliente como eu ou você, comprando um livro ou um CD
através da Internet. É o cliente comprando através de uma loja virtual na Internet. Hoje existem
sites de comércio eletrônico que vendem uma série de coisas: livros, revistas, cosméticos, CDs,
roupas, animais de estimação, cursos de informática, CDs com mensagens de auto-ajuda e até
remédios e carros.
À medida que aumenta o número de sites de comércio eletrônico, aumenta também a concorrência.
Com isso conquistar e manter clientes tem sido o grande desafio. Não basta colocar um catálogo de
produtos, garantir a segurança e entregar a mercadoria no local correto e no prazo estipulado. Embora
estas sejam questões fundamentais, não são mais suficientes para garantir a fidelidade do cliente, pois,
diferentemente do comércio tradicional, no comércio eletrônico, o concorrente está a apenas um
clique de mouse.
Hoje, um dos grandes desafios é conhecer o cliente, saber identificar os seus hábitos e armazenar o
maior número de informações possíveis sobre os hábitos de navegação e consumo, bem como sobre as
preferências do cliente, tal como o histórico de compras e pesquisas realizadas no catálogo de produtos.
De posse destas informações, o site deve ser capaz de fazer ofertas personalizadas para o cliente.
Posso citar o meu caso como exemplo. Há tempos que compro livros importados no site
www.amazon.com. Ao acessar o site, após me identificar, aparece um link: “Sugestões para o Júlio”.
Vejam que até o link já vem personalizado, e isso atrai o cliente. É como entrar no mercadinho da
esquina e o seu Manoel ir dizendo: “Olá, seu Júlio, aquele queijo colonial que o senhor gosta chegou.”
Ao clicar no link de sugestões, recebo uma listagem de livros. O mais interessante é que na listagem,
realmente, estão os livros nos quais estou interessado. Que milagre é este? Não é milagre nenhum.
Acontece que, desde a primeira compra, o site vem armazenando informações sobre as minhas compras,
bem como sobre as pesquisas que faço no catálogo de livros. Com isso, foi possível identificar minhas
preferências e elaborar uma lista de sugestões personalizada, de acordo com os meus gostos e preferências.
Quanto maior a quantidade de informações, mais precisa é esta lista.
Não fica difícil adivinhar quem é o responsável pelo armazenamento e recuperação deste gigantesco
volume de informações, com as preferências e hábitos de compra dos clientes. Evidentemente que é
um Banco de Dados.
Vejam que os sites de comércio eletrônico estão tentando fazer o que o seu Manoel do mercadinho da
esquina faz há muitos anos. Estão tentando dar um tratamento personalizado para os seus clientes,
com o objetivo de mantê-los satisfeitos. Clientes satisfeitos significam vendas e lucro para a empresa.
Conhecer as preferências do cliente é apenas um dos exemplos de aplicação a ser baseada nos dados
dos clientes, obtidos através do site. Uma vez formada uma base de dados grande e confiável, muitas
aplicações podem ser construídas sobre os dados obtidos. Por isso que a maioria dos sites, mesmo os
que fornecem serviços gratuitos, exigem que você preencha um cadastro, antes de disponibilizar o
acesso a serviços e informações. Com os dados obtidos através do cadastro, a empresa está tentando
montar a sua base de dados sobre os seus clientes e usuários do site (nem todo usuário cadastrado
torna-se um cliente).
Vamos salientar um detalhe importante sobre o parágrafo anterior. Veja que o ponto-chave é ter uma
base de dados grande e, principalmente, confiável. Mais uma vez o Banco de Dados desempenha um
papel central, garantindo a consistência e segurança dos dados obtidos. Você não gostaria que os dados
do seu cadastro no banco, onde você tem conta, fossem acessados por qualquer internauta, gostaria?
Obviamente que não.
Vejam que os dados precisam ser obtidos e armazenados em um Banco de Dados. Depois a segurança
dos dados precisa ser garantida. Já pensou se alguém consegue invadir o site de uma empresa e
obter uma listagem de números de cartões de crédito? (o que já ocorreu realmente em algumas
ocasiões. O efeito foi tão negativo que as empresas que tiveram seus Bancos de Dados invadidos
foram todas à falência, devido a perda de credibilidade junto ao público). Seria péssimo para a
imagem e para as vendas desta empresa. Além da segurança, novas aplicações estão sendo
construídas para fazer uso destes dados, com o objetivo não só de melhorar as vendas, mas também
de melhorar as relações com os clientes.
Não basta que a empresa seja capaz de vender. Para sobreviver, ela precisa “continuar vendendo” para
o cliente. Para continuar vendendo, isto é, para fidelizar o cliente, a área de atendimento ao cliente é
de fundamental importância. Se você compra, por exemplo, um CD e este é entregue fora do prazo,
você reclama. Se a sua reclamação não for satisfatoriamente atendida, você simplesmente deixa de
comprar desta empresa e procura outra empresa. Afinal, na Internet, o concorrente está a um clique de
mouse, conforme descrevemos antes.
Um dos assuntos, que mais é discutido no momento, é representado pela sigla CRM – Customer Rela-
tionship Management. Traduzindo teríamos: Gerenciamento das Relações com o Cliente. CRM
representa um conjunto de soluções de hardware e software, capazes de melhorar a relação das empresas
com os clientes, principalmente no atendimento a questões do cliente, seja suporte técnico, dúvidas
sobre novos produtos, etc.
Quem já não ligou para uma central de atendimento, e teve que contar a mesma história uma dezena
de vezes? Você liga, alguém atende. Você descreve o seu problema, a pessoa diz que não é com ela e
passa para um outro setor. Um novo atendente e a mesma história; você é passado para um outro setor.
Depois da décima transferência (contando que você seja uma pessoa paciente, se não na terceira você
já desliga o telefone), você desliga irritado, sem ter solucionado o problema. Muito provavelmente,
esta empresa acaba de perder mais um cliente.
Melhorar o atendimento ao cliente ou, de uma maneira mais genérica, a relação dos clientes com a
empresa, é o objetivo das soluções de CRM. Ao ligar para uma central de atendimento, o cliente
identifica-se através do seu código de cliente, o sistema de CRM busca no Banco de Dados (olha o
papel central do Banco de Dados aí de novo!) todas as informações sobre o cliente, incluindo o histórico
de compras e o histórico de reclamações, bem como as reclamações ainda não solucionadas. Ele descreve
o problema o qual é inserido no sistema. Caso o atendente não seja capaz de solucioná-lo, a chamada
é transferida diretamente para a pessoa capaz de solucionar o problema. Porém toda a descrição do
problema, também está acessível para a pessoa que irá atender o cliente (os dados foram passados pelo
sistema de CRM, quando da transferência do chamado). Com isso o cliente não precisa repetir toda a
história. É atendido, soluciona o seu problema e fica satisfeito. Cliente satisfeito continua comprando.
A descrição do parágrafo anterior representa uma situação ideal. É claro que os sistemas de CRM ainda
não são perfeitos. Porém novas técnicas estão sendo introduzidas, com a possibilidade de atendimentos
através da Internet, acessando o site da empresa. Com a melhoria dos sistemas de telecomunicações,
poderemos tornar realidade um atendimento de alta qualidade e conclusividade, através da Internet.
Por exemplo, o cliente está pesquisando o catálogo de produtos. Na página com os dados do produto,
existe um link “Outras dúvidas”. Ao clicar neste link, o cliente entra numa seção de bate-papo com um
atendente da empresa. O cliente pode colocar as suas dúvidas, as quais serão solucionadas em tempo
real. Assim, a probabilidade de que o pedido seja feito é bem maior. Além disso as dúvidas do cliente
podem ser armazenadas no Banco de Dados (olha o papel importante do Banco de Dados novamente).
Quando uma dúvida começar a aparecer com uma determinada freqüência, os dados que solucionam
a dúvida podem ser disponibilizados no catálogo de soluções. Com isso, os próximos clientes que
tiverem a mesma dúvida não precisarão do auxílio de um atendente. Vejam que novamente estamos
em um processo de aquisição de informações, através do próprio site, e utilização destas informações
para melhorar a qualidade dos serviços e produtos oferecidos. E me permitam ser chato: onde
armazenaremos estas informações? Claro, no Banco de Dados.
No B2B também existem muitas questões a serem gerenciadas. Para entendermos a complexidade
destas situações imagine o seguinte exemplo, ilustrado pela Figura 2.1:
Figura 2.1 A complexidade das questões envolvidas no B2B.
Temos uma rede de concessionárias que presta serviços de manutenção para uma determinada marca
de automóveis. O objetivo é ter um controle automatizado de estoque de peças de reposição. Cada
peça catalogada possui um nível mínimo de unidades em estoque. Quando este nível mínimo é atingido,
automaticamente, o Banco de Dados deve lançar, via Internet, um pedido para este item. O
funcionamento do sistema é o seguinte:
O cliente vai na concessionária para comprar uma determinada peça. O atendente efetua a venda, e o
estoque é atualizado, automaticamente, pelo sistema de vendas. Se a peça atingir o nível mínimo,
previamente estabelecido, um pedido deve ser automaticamente gerado. Este pedido contém
informações sobre a concessionária, bem como sobre as peças que estão sendo encomendadas.
As informações sobre o pedido são criptografadas, para garantir a segurança, e o pedido é enviado,
através da Internet, para o fornecedor da peça. Dentro de um prazo preestabelecido, a peça é entregue,
evitando que esta falte no estoque.
Observe que, neste caso, existe uma troca de informações entre as concessionárias e os fornecedores.
Para que possa haver esta troca de informações, os sistemas das duas empresas devem ser capazes de
trocar dados em um formato comum. Com isso as empresas serão capazes de fazer negócios através da
Internet. No Capítulo 12, falaremos um pouco sobre o XML – eXtensible Markup Language, que pode
ser utilizado para a troca de informações em um formato padrão, o qual está sendo cada vez mais
adotado na Internet e também nos sistemas internos das empresas.
Poderíamos introduzir mais algumas questões, que complicariam um pouco mais a infra-estrutura
necessária para a realização do B2B. Por exemplo, ao invés de comprar uma determinada peça, sempre
do mesmo fornecedor, pode ser que o sistema deva ser capaz de enviar o pedido para vários fornecedores
e selecionar aquele que fizer a melhor oferta, tanto em termos de preço quanto de prazo de entrega.
Neste caso, a concessionária lança o pedido no seu site e aguarda as propostas dos fornecedores. Após
recebidas as respostas, uma delas é selecionada. Este parece ser um sistema de leilão ao contrário, ou
seja, o comprador anuncia que está precisando de um determinado produto, e os fornecedores esforçam-
se para fazer a melhor oferta, dentro do prazo máximo estipulado pelo cliente. Esta forma de fazer
compras é conhecida como e-procurement. Em determinados casos, a lista de propostas está disponível
para todos os fornecedores, isto é, se um fornecedor “A” fez uma proposta, depois, ao consultar a lista,
viu que um fornecedor “B” fez uma proposta melhor do que a sua, o fornecedor “A” pode alterar a sua
proposta, dentro de um período de tempo estipulado pelo comprador, no nosso caso, a concessionária.
Vejam que, mesmo no sistema de B2B, a lógica tem sido revertida em favor do cliente, isto é, os
fornecedores é que disputam o cliente, através de boas ofertas, preços competitivos e prazos
adequados de entrega.
Porém, a criação de sistemas deste tipo é uma tarefa complexa. A todo momento temos acesso a
informações dos Bancos de Dados, questões de segurança no acesso às informações, além de uma
lógica bastante complexa.
Mais uma vez reforço que o Microsoft SQL Server 2005 nos oferece uma série de recursos interessantes
para a criação de aplicações de alta complexidade, como as descritas nos exemplos deste capítulo.
Vamos introduzir mais alguns detalhes no nosso exemplo. Pode ser que, além de fazer o pedido, a concessionária,
uma vez aprovada a compra, deva fazer o pagamento do pedido, através de uma transação on-line. O pagamento
pode ser feito, por exemplo, através de uma transferência da conta corrente da concessionária para a conta
corrente do fornecedor. Neste ponto, precisamos introduzir o conceito de transação.
Uma transação, de uma maneira bastante simples, é um conjunto de operações sobre os dados, que
deve acontecer como um todo, ou seja, todas as operações contidas na transação devem ser finalizadas
com sucesso, ou nenhuma delas deve ser realizada. Caso uma das operações, contida na transação,
falhe, as operações ainda pendentes devem ser canceladas; e as operações já realizadas devem ser
revertidas. Com isso garantimos que a transação aconteça como um todo, ou que nenhuma das operações
contidas na transação seja realizada.
Para entender, na prática, o conceito de transações, vamos voltar ao exemplo anterior. Ao efetuar um
pagamento, o sistema deve transferir valores da conta corrente da concessionária para a do fornecedor.
Estas duas ações devem acontecer no contexto de uma transação, conforme indicado a seguir:
Início da Transação
Ação 1: Debita o valor da conta corrente da Concessionária.

Ação 2: Credita o valor na conta corrente do Fornecedor.
Final da Transação.
A primeira ação efetua o débito na conta corrente da concessionária. Vamos supor que a Ação 1 ocorra
com sucesso, porém na hora de fazer o crédito na conta corrente do fornecedor, ocorra um problema. O
que devemos fazer? O valor deve ser estornado para a conta da Concessionária, ou seja, a Ação 1 deve
ser revertida, uma vez que nem todas as ações dentro da transação puderam ser concluídas com êxito.
Vejam a importância do conceito de transação pois, neste caso, se não usássemos transação, o valor
seria debitado da conta corrente da concessionária, sem ser creditado na conta corrente do fornecedor.
FUNDAMENTOS EM: ARQUITETURA DE APLICAÇÕES

PRÉ-REQUISITOS
♦ Conhecimento da complexidade no desenvolvimento e manutenção de aplicações para a Internet.
METODOLOGIA
♦ Apresentação dos modelos e comparação entre eles.
Embora utilizemos o exemplo de comércio eletrônico, CRM, e-procurement, etc., como situações onde
o Banco de Dados desempenha um papel fundamental, hoje em dia, com o aumento da complexidade
das redes de computadores baseadas em PCs, existe uma tendência bastante acentuada em favor do
desenvolvimento de aplicações que seguem o modelo Web. São aplicações que são acessadas através de
um navegador. Neste tópico, iremos falar um pouco sobre aplicações Cliente/Servidor tradicionais e os
problemas deste tipo de modelo. Falaremos sobre aplicações de duas, três ou n camadas, e as vantagens
destas últimas em relação ao modelo Cliente/Servidor tradicional.
A COMPLEXIDADE DE GERENCIAMENTO DO MODELO

CLIENTE/SERVIDOR E APLICAÇÕES DE DUAS CAMADAS
O modelo Cliente/Servidor foi criado tendo como base a descentralização dos dados e recursos de
processamento, em oposição ao modelo centralizado utilizado na época em que o mainframe dominava
absoluto. No modelo Cliente/Servidor, conforme indicado pela Figura 2.2, em uma rede de
computadores, existem uma ou mais máquinas que atuam como servidores, disponibilizando recursos
para as demais máquinas, as quais atuam como clientes.
Figura 2.2 O Modelo Cliente/Servidor tradicional.
Conforme pode ser visto na Figura 2.2, temos servidores para arquivos, Banco de Dados e outras funções,
tais como: servidores de impressão, servidores Web, etc. Estas redes, tipicamente, são formadas por
servidores, os quais são equipamentos com um maior poder de processamento e armazenamento do
que os clientes (estações de trabalho dos usuários, conectadas à rede), os quais, na maioria dos casos,
são microcomputadores PCs ligados em rede.
APLICAÇÕES EM DUAS CAMADAS

No início da utilização do modelo Cliente/Servidor, as aplicações foram desenvolvidas utilizando-se
um modelo de desenvolvimento em duas camadas. Neste modelo, um programa, normalmente
desenvolvido em um ambiente de desenvolvimento gráfico, como o Visual Basic, Delphi ou Power
Builder, é instalado em cada cliente. Este programa acessa dados em um servidor de Banco de Dados,
conforme ilustrado na Figura 2.3:
Figura 2.3 O modelo de desenvolvimento em duas camadas.
No modelo de duas camadas, temos um programa que é instalado em cada cliente da rede, onde o
programa será utilizado. Este programa é que faz acesso ao Banco de Dados residente no servidor de
Banco de Dados. Na maioria dos casos, a máquina do cliente é um PC rodando Windows, e a aplicação
Cliente é desenvolvida utilizando-se um dos ambientes conhecidos de desenvolvimento, conforme
citado anteriormente. Sendo a aplicação Cliente um programa para Windows (na grande maioria dos
casos), esta deve ser instalada em cada um dos computadores da rede, que farão uso da aplicação. É o
processo de instalação normal, para qualquer aplicação Windows. No modelo de duas camadas, a
aplicação Cliente é responsável pelas seguintes funções:
♦ Apresentação: O código que gera a interface visível do programa faz parte da aplicação Cliente.
Todos os formulários, menus e demais elementos visuais estão contidos no código da aplicação
Cliente. Caso sejam necessárias alterações na interface do programa, faz-se necessária a geração de
uma nova versão do programa, e todos os computadores que possuem a versão anterior devem
receber a nova versão, para que o usuário possa ter acesso às alterações da interface. Então começam
a surgir os problemas no modelo de duas camadas: uma simples alteração de interface é suficiente
para gerar a necessidade de atualizar a aplicação, em centenas ou milhares de computadores. O
gerenciamento desta tarefa é algo extremamente complexo e o custo de manutenção é muito elevado.
♦ Lógica do Negócio: As regras, que definem a maneira como os dados serão acessados e processados,
são conhecidas como “Lógica do Negócio” ou “Regras do Negócio”. Fazem parte das Regras do Negócio,
desde funções simples de validação da entrada de dados, como o cálculo do dígito verificador de um
CPF ou CNPJ, até funções mais complexas, como descontos escalonados para os maiores clientes, de
acordo com o volume da compra. Questões relativas à legislação fiscal e escrita contábil também
fazem parte da Lógica do Negócio. Por exemplo, um programa para gerência de recursos humanos,
desenvolvido para a legislação dos EUA, não pode ser utilizado, sem modificações, por uma empresa
brasileira. Isso acontece porque a legislação dos EUA é diferente da brasileira. Em síntese, as regras
para o sistema de recursos humanos são diferentes. Como alterações nas regras do negócio são bastante
freqüentes, ainda mais com as repetidas mudanças na legislação do nosso país, faz-se necessária a
geração de uma nova versão do programa, cada vez que uma determinada regra muda, ou quando
regras forem acrescentadas ou retiradas. Desta forma, todos os computadores que possuem a versão
anterior devem receber a nova versão, para que o usuário possa ter acesso às alterações. Agora temos
mais problemas no modelo de duas camadas: qualquer alteração nas regras do negócio é suficiente
para gerar a necessidade de atualizar a aplicação, em centenas ou milhares de computadores. O que já
era complicado piorou um pouco mais, principalmente considerando que, no nosso país, a legislação
e outras normas legais mudam com uma freqüência realmente espantosa.
Por isso, o modelo de duas camadas demonstrou-se de difícil manutenção e gerenciamento, além de
apresentar um TCO – Total Cost Ownership (Custo Total de Propriedade) elevado.
A outra camada, no modelo de duas camadas, é o Banco de Dados, que fica armazenado no servidor de
Banco de Dados. Uma aplicação desenvolvida em Visual Basic, a qual acessa um Banco de Dados em
um servidor Microsoft SQL Server 2005, é um típico exemplo de uma aplicação em duas camadas.
Em busca de soluções para os problemas do modelo de duas camadas, é que surgiu a proposta do
modelo de três camadas, conforme analisaremos a seguir.
APLICAÇÕES EM TRÊS CAMADAS

Como uma evolução do modelo de duas camadas, surge o modelo de três camadas. A idéia básica do modelo
de três camadas é retirar as regras do negócio do cliente e centralizá-las em um determinado ponto, o qual é
chamado de servidor de Aplicações. O acesso ao Banco de Dados é feito através das regras contidas no servidor
de aplicações. Ao centralizar as regras do negócio em um único ponto, fica muito mais fácil a atualização das
regras do negócio. A Figura 2.4 nos dá uma idéia geral do modelo em três camadas:
Figura 2.4 O modelo de desenvolvimento em três camadas.
Todo o acesso do cliente ao Banco de Dados é feito de acordo com as regras contidas no Servidor de
aplicações. O cliente não tem acesso ao Banco de Dados, sem antes passar pelo servidor de Aplicações.
Com isso as três camadas são as seguintes:
♦ Apresentação: Continua no programa instalado no cliente. Alterações na interface do programa

geram a necessidade de atualizar a aplicação em todos os computadores, onde a mesma está
sendo utilizada. Porém cabe ressaltar que alterações na interface são menos freqüentes do que
alterações nas regras do negócio.
♦ Lógica: São as regras do negócio, as quais determinam de que maneira os dados serão utilizados.
Esta camada foi deslocada para o servidor de aplicações. Desta maneira, quando uma regra do
negócio for alterada, basta atualizá-la no servidor de aplicações. Após a atualização, todos os
usuários passarão a ter acesso à nova versão, sem que seja necessário reinstalar o programa em
cada um dos computadores da rede. Vejam que, ao centralizar as regras do negócio em um
servidor de aplicações, estamos facilitando a tarefa de manter a aplicação atualizada. As coisas
estão começando a melhorar.
♦ Dados: Nesta camada temos o servidor de Banco de Dados, no qual reside toda a informação necessária
para o funcionamento da aplicação. Cabe reforçar que os dados somente são acessados através do
servidor de aplicação, e não diretamente pela aplicação Cliente. Com isso o acesso aos dados,
obrigatoriamente, é feito de acordo com as regras de negócios, contidas no servidor de aplicação.
Com a introdução da camada de Lógica, resolvemos o problema de termos que atualizar a aplicação,
em centenas ou milhares de computadores, cada vez que uma regra do negócio for alterada. Porém
continuamos com o problema de atualização da interface da aplicação, cada vez que forem necessárias
mudanças na interface da aplicação. Por isso que surgiram os modelos de n-camadas.
No próximo tópico, iremos falar um pouco sobre o modelo de quatro camadas. Ao longo deste livro
falaremos um pouco mais sobre transações e outros conceitos envolvidos com o desenvolvimento de
aplicações de n-camadas.
APLICAÇÕES EM QUATRO CAMADAS

Como uma evolução do modelo de três camadas, surge o modelo de quatro camadas. A idéia básica do
modelo de quatro camadas é retirar a apresentação do cliente e centralizá-las em um determinado
ponto, o qual na maioria dos casos é um servidor Web. Com isso, o próprio cliente deixa de existir
como um programa que precisa ser instalado em cada computador da rede. O acesso à aplicação é feito
através de um navegador, como o Internet Explorer ou o Netscape Navigator. A Figura 2.5 nos dá uma
idéia geral do modelo em quatro camadas.
Para acessar a aplicação, o cliente acessa o endereço da aplicação, utilizando o seu navegador.
Por exemplo http://www.empresa-xy.com/sistemas/rh.aspx. Todo o acesso do cliente ao Banco
de Dados é feito de acordo com as regras contidas no servidor de aplicações. O cliente não tem
acesso ao Banco de Dados, sem antes passar pelo servidor de aplicações. Com isso as quatro
camadas são as seguintes:
♦ Cliente: Neste caso, o cliente é o navegador utilizado pelo usuário, quer seja o Internet Explorer,
Netscape Navigator, ou outro navegador qualquer, compatível com as aplicações utilizadas.
Figura 2.5 O modelo de desenvolvimento em quatro camadas.
♦ Apresentação: Neste modelo, se desloca do cliente para o servidor Web. A interface pode ser
composta de páginas HTML, ASP, PHP ou qualquer outra tecnologia capaz de gerar conteúdo
para o navegador. Com isso, alterações na interface da aplicação são feitas diretamente no
servidor Web, sendo que estas alterações estarão, automaticamente, disponíveis para todos os
clientes. Com este modelo não existe a necessidade de reinstalar a aplicação em todos os
computadores da rede, sempre que houver alterações na interface das aplicações. Fica muito
mais fácil garantir que todos estão tendo acesso à versão mais atualizada da aplicação. A única
coisa que o cliente precisa ter instalado na sua máquina é o navegador.
♦ Lógica: São as regras do negócio, as quais determinam de que maneira os dados serão utilizados.
Esta camada está no servidor de aplicações. Desta maneira, quando uma regra do negócio for
alterada, basta atualizá-la no servidor de aplicações. Após a atualização, todos os usuários passarão
a ter acesso à nova versão, sem que seja necessário reinstalar o programa em cada um dos
computadores da rede. Vejam que, ao centralizar as regras do negócio em um servidor de
aplicações, estamos facilitando a tarefa de manter a aplicação atualizada.
♦ Dados: Nesta camada, temos o servidor de Banco de Dados, no qual reside toda a informação
necessária para o funcionamento da aplicação.
Com o deslocamento da camada de apresentação para um servidor Web, resolvemos o problema de

termos que atualizar a aplicação, em centenas ou milhares de computadores, cada vez que a interface
da aplicação for alterada. Neste ponto, a atualização das aplicações é uma tarefa mais gerenciável,
muito diferente do que acontecia no caso do modelo em duas camadas. O custo de manutenção dos
sistemas é muito menor.
Os servidores de aplicação, Web e Banco de Dados não precisam, necessariamente, ser servidores
separados, isto é, uma máquina para fazer o papel de cada um dos servidores. O conceito de servidor de
aplicação, servidor Web ou servidor de Banco de Dados é um conceito relacionado com a função que
o servidor desempenha. Podemos ter, em um mesmo equipamento, estes diferentes servidores. Claro
que questões de desempenho devem ser levadas em consideração e cuidadosamente projetadas, para
não prejudicar o desempenho e a segurança das aplicações.
Também podemos ter a funcionalidade do servidor de aplicações distribuída através de vários servidores,
com cada servidor tendo alguns componentes que formam parte das funcionalidades da aplicação.
Este modelo onde temos componentes em diversos equipamentos é conhecido como Modelo de
Aplicações Distribuídas. Também podemos colocar os componentes em mais do que um servidor para
obtermos um melhor desempenho, ou redundância, no caso de um servidor falhar.
QUESTÕES A CONSIDERARMOS NOS

MODELOS DE TRÊS OU MAIS CAMADAS
Muitas são as vantagens dos modelos de três ou mais camadas, em relação à facilidade de gerenciamento
e atualização das aplicações. Porém considerações devem ser feitas em relação a desempenho e
dimensionamento dos equipamentos que atuarão como servidores.
A partir do momento em que estamos deslocando funcionalidades (tipicamente lógica e apresentação)

do cliente para um ou mais servidores, também estamos deslocando capacidade de processamento em
termos de memória RAM e processador. Funções que antes eram executadas pelos clientes, utilizando
memória e processador da estação Cliente, agora foram deslocadas para os servidores, consumindo
memória e processador do servidor. Desta forma, um dos fatores-chave é o correto dimensionamento
dos equipamentos servidores.
Para fazer o dimensionamento dos servidores, precisamos conhecer o número de usuários que irão
acessar a aplicação simultaneamente, o nível de exigência de cada usuário, os recursos necessários
pelos softwares do servidor, dentre outros. Para determinar o nível de recursos necessários em cada um
dos servidores, você precisa fazer um estudo bem detalhado, de tal forma que o servidor não fique sub-
dimensionado. Quando o servidor não está corretamente dimensionado, a tendência é que o acesso à
aplicação fique bastante lento, o que causa insatisfação entre os usuários.
Observe que, quer seja no modelo de duas camadas, quer seja em outros modelos, sempre temos a
presença de um Banco de Dados. Devido à importância deste elemento chave é que precisamos da
figura do DBA – Database Administrator. O DBA é a pessoa responsável por manter o banco de Dados
em funcionamento e proceder às alterações necessárias relativas à segurança e manutenção do banco.
O conteúdo deste livro é quase todo relacionado com atividades que devem ser desempenhadas pelo
DBA. A partir do Capítulo 9, abordarei tópicos mais relacionados com o desenvolvimento de aplicações
com o Microsoft SQL Server 2005 e com tecnologias de programação Web, tais como ASP e ASP.NET.
FUNDAMENTOS EM: AS PRINCIPAIS NOVIDADES E

MELHORAMENTOS DO MICROSOFT SQL SERVER 2005
PRÉ-REQUISITOS
♦ Conhecimentos do modelo relacional e de arquitetura de aplicações.
METODOLOGIA
♦ Apresentação das principais novidades do SQL Server 2005.
Neste item, veremos as melhorias e novidades introduzidas no SQL Server 2005, em relação às versões
anteriores (apresentarei as principais melhorias e novidades). Você pode utilizar esta seção como uma
referência para analisar se vale a pena migrar os seus sistemas atuais para a nova versão do Microsoft
SQL Server. Dividirei as novidades em categorias, para que possamos analisar as novas funcionalidades
de uma maneira mais estruturada.
Evidentemente que irei apresentar as principais novidades e melhorias. Pois para apresentar todas as
novidades seria necessário um livro separado, só com as novidades. Aliás este livro já existe e é uma
excelente introdução ao SQL Server 2005. O livro que apresenta todas as novidades do SQL Server
2005 é o seguinte, disponível somente em Inglês: “SQL Server 2005 New Features”, Editora McGraw
Hill, 275 páginas. Mais detalhes em: http://www.amazon.com/exec/obidos/tg/detail/-/0072227761/
qid=1110935474/sr=1-1/ref=sr_1_1/002-8063366-0124867?v=glance&s=books
NOVIDADES E MELHORIAS DO BANCO DE DADOS

Centenas de novos recursos e novidades foram inseridos nas capacidades do Banco de Dados do SQL
Server 2005 (o nome técnico seria na “Máquina do Banco de Dados do SQL Server 2005”, ou o termo
em Inglês: “SQL Server 2005 Database Engine”). Como são muitas as novidades, vamos dividi-las em
subcategorias, para facilitar a apresentação das novidades.
NOVIDADES NO DESENVOLVIMENTO DE APLICAÇÕES

Esta foi, na minha opinião, uma das áreas onde o SQL Server 2005 mais avançou e apresentou
melhorias, em relação às versões anteriores. Na minha opinião, só a integração com o Framework
.NET (que descreverei em mais detalhes logo a seguir) já vale o upgrade. Com a integração com o
Framework .NET, é possível criar objetos tais como triggers, stored procedures e tipos de dados definidos
pelo usuário, usando qualquer linguagem suportada pelo framework .Net, tais como VB.NET, C#,
Delphi.NET, etc. Este é um avanço considerável, ou seja, agora você não está limitado a somente usar
o T-SQL, para a criação destes objetos. Com a integração com o .Net, os horizontes de desenvolvimento
se ampliam, consideravelmente.
Outra excelente novidade é que estes objetos podem, facilmente, ser criados, usando o Visual
Studio .NET – 2005 (ainda em versão Beta, enquanto eu escrevo este livro). Com o Visual Studio
.NET, é extremamente simples a criação de objetos tais como triggers e stored procedures e a
instalação destes objetos, para serem utilizados em um ou mais Bancos de Dados do SQL Server
2005. A seguir descrevo mais algumas importantes novidades, na área de desenvolvimento de
aplicações com o SQL Server 2005:
♦ Acesso HTTP SOAP Nativo: Com o SQL Server 2005 é possível acessar os dados de um Banco
de Dados, diretamente, usando o protocolo SOAP. Para isso, basta configurar o SQL Server
2005 para atuar como um endpoint de acesso SOAP, o qual é capaz de receber os pacotes SOAP
e retornar os dados solicitados. Isso, por exemplo, permite acessar os dados de um Banco de
Dados do SQL Server 2005, sem ter que usar um servidor Web tal com o IIS ou o Apache.
♦ Um novo tipo de dados – xml: Foi criado um novo tipo de dados, o qual é capaz de tratar
diretamente com dados e documentos no formato XML.
♦ Criar Funções definidas pelo usuário, usando qualquer linguagem suportada pelo Frame-
work .NET: Esta é uma conseqüência da integração com o framework .NET. Com o SQL Server
2000 foi introduzida a possibilidade de o programador criar as suas próprias funções, em adição
às funções já fornecidas pela linguagem Transact-SQL (T-SQL). Estas funções podem retornar um
valor simples, ou até mesmo uma tabela. Por exemplo, você pode criar uma função para validação
do DV do CPF ou do CNPJ, uma outra função para cálculo do Imposto de Renda e assim por
diante. No SQL Server 2000, estas funções só podiam ser criadas usando o T-SQL. No SQL Server
2005, estas funções podem ser criadas, usando qualquer linguagem suportada pelo Framework
.NET. Estas funções podem ser facilmente criadas, usando-se o Visual Studo .NET 2005.
♦ Novas consultas para acesso a metadados: Os metadados são informações sobre os dados. Ou,
falando de uma maneira mais simples, são informações sobre a estrutura do Banco de Dados e
das tabelas. Por exemplo, uma lista com o nome de todas as tabelas de um Banco de Dados é uma
informação de metadados. Outro exemplo, uma lista de todos os campos de uma tabela, com
informações sobre as propriedades de cada campo também são informações de metadados. No
SQL Server 2005 foram introduzidas dezenas de novas Views (consultas), as quais podem ser
utilizadas para obter informações detalhadas sobre a estrutura de um Banco de Dados.
♦ Triggers associadas a alterações na estrutura do Banco de Dados: Nas versões anteriores

do SQL Server, só era possível criar triggers associadas com alterações nos dados das tabelas
de um Banco de Dados. Por exemplo, você poderia criar uma trigger associada ao campo
Quantidade em estoque, da tabela Produtos no estoque, a qual fosse disparada sempre que o
valor do campo Quantidade for alterado. Esta trigger poderia receber como parâmetro o
código do produto que está tendo a sua quantidade em estoque alterada e verificar se o
produto não atingiu o estoque mínimo. Se o estoque mínimo foi atingido, a trigger poderá
gravar um registro, na tabela de pedidos pendentes, para que seja feito um pedido do produto.
A novidade no SQL Server 2005 é que é possível criar triggers que são disparadas quando são
feitas alterações na estrutura do Banco de Dados. Por exemplo, quando as propriedades de
um campo de uma tabela são alteradas, ou quando um novo campo é criado ou excluído, ou
quando uma nova tabela é criada ou excluída e assim por diante. Com triggers que podem
ser disparadas por alterações na estrutura do Banco de Dados, o desenvolvedor pode
implementar um sistema de monitoramento bem mais eficaz, podendo inclusive criar trig-
gers que não permitam que a estrutura de tabelas e/ou campos críticos sejam alterados ou
que tabelas e/ou campos críticos, sejam excluídos.
♦ Novos recursos da linguagem T-SQL: Muitos novos recursos e melhoramentos foram inseridos
na linguagem T-SQL. Uma das novidades é a possibilidade de criar consultas recursivas. Um
novo operador foi criado – operador APPLY, o qual facilita a combinação entre dados de duas
ou mais tabelas, onde alguns campos são retornados a partir de uma tabela e, para cada valor
da primeira tabela, são exigidos todos os registros correspondentes, na segunda tabela. Foram
incluídos novos operadores PIVOT e UNPIVOT, os quais facilitam a transposição de linhas em
colunas e vice-versa, em uma consulta de referência cruzada. O operador TOP, o qual é utilizado
para retornar apenas um número específico de registros ou um percentual do número total de
registros de uma consulta, também foi melhorado no SQL Server 2005. Agora, além de números,
você pode fornecer uma variável como valor do operador TOP, o qual utilizará o valor da
variável. Esta mudança nos dá bem mais flexibilidade na utilização do operador TOP em rotinas
de programação.
♦ Query Notification: Este é um recurso realmente valioso, principalmente para melhorar o
desempenho das aplicações. Com este recurso é possível criar aplicações, as quais são capazes
de manter em cache o resultado de uma ou mais consultas. Além disso, o SQL Server 2005
pode ser configurado, para notificar a aplicação, sempre que houver alterações nos dados
originais, de tal forma que o resultado da consulta seja atualizado no cache, para evitar que
dados desatualizados sejam acessados. Este é um recurso realmente valioso e pode ter, nas
aplicações, o mesmo efeito de desempenho que um servidor de cache de páginas Web tem na
velocidade de acesso a Internet.
♦ Outras novidades: Existem muitas outras novidades, no desenvolvimento de aplicações no
SQL Server 2005, que por falta de espaço não temos como descrever em detalhes neste livro.
Mas você encontra informações detalhadas, sobre as seguintes novidades, no Books Online, o
qual é o sistema de Ajuda, instalado com o SQL Server 2005: Iniciar -> Programas -> Microsoft
SQL Server 2005 -> SQL Server Books Online. Clique em SQL Server Books Online -> What’s
New in SQL Server 2005 -> Database Engine Enhancements -> Database Engine Programmabil-
ity Enhancements.
NOVIDADES NO GERENCIAMENTO DA MÁQUINA DE BANCO DE DADOS DO SQL SERVER 2005

Nesta área, encontramos as seguintes melhorias:
♦ Separação entre Usuários e Esquemas: Nas versões anteriores do SQL Server, cada objeto
tinha um dono e este dono é que, por padrão, tinha permissões para fazer alterações na estrutura
do objeto. No SQL Server 2005 todos os objetos fazem parte de um esquema (Schema) e um
usuário ou grupo (roles) pode ser dono do esquema. Com isso, fica mais fácil gerenciar as
permissões e garantir que um grupo de usuários possa atuar como dono de vários objetos,
sendo dono do schema ao qual os objetos pertencem. Esta é uma importante inovação que
também está relacionada à área de segurança. Eu irei detalhar esta novidade, no Capítulo 6, o
qual será completamente dedicado ao gerenciamento de segurança no SQL Server 2005.
♦ Nova Cláusula – ATTACH_REBUILD_LOG: Esta nova cláusula permite configurar um Banco

de Dados para ser usado em um outro servidor (chamamos isso de “atachar” o Banco de Dados),
sem que seja preciso carregar todos os arquivos de LOG do Banco de dados. Um exemplo
prático onde esta cláusula pode ser utilizada seria em uma situação onde estamos querendo
levar uma cópia de um Banco de Dados para um outro servidor, sendo que esta cópia será
somente leitura. Neste caso, não é preciso carregar também todos os arquivos de log. Esta
operação pode ser feita, usando a nova cláusula ATTACH_REBUILD_LOG.
♦ Outras novidades: Existem outras novidades, no gerenciamento da máquina de Banco de

Dados do SQL Server 2005. Você encontra informações detalhadas, sobre estas novidades, no
Books Online, o qual é o sistema de Ajuda, instalado com o SQL Server 2005: Iniciar -> Programas
-> Microsoft SQL Server 2005 -> SQL Server Books Online. Uma vez aberto o Books online,
clique em SQL Server Books Online -> What’s New in SQL Server 2005 -> Database Engine
Enhancements -> Database Engine Manageability Enhancements.
NOVIDADES QUE MELHORAM O TEMPO DE UPTIME DO SQL SERVER 2005

Nesta área, encontramos diversas melhorais, responsáveis por manter o SQL Server 2005 em
funcionamento, minimizando o máximo possível interrupções e tempos de parada, devido a erros ou
problemas de software ou hardware. A seguir apresento as principais novidades nesta área.
♦ Aumento no número de nós de cluster: Nas versões anteriores do SQL Server, eram suportados
clusters com quatro nós, para as versões de 64 bits do SQL Server e de 2 nós, para as versões de
32 bits. Com o SQL Server 2005 são suportados 8 nós para as versões de 32 bits e 4 nós para as
versões de 64 bits.
♦ Aumento no número de instâncias: A possibilidade de ter mais de uma instância, do SQL

Server, no mesmo servidor, foi introduzida com o SQL Server 2000. No SQL Server 2000 o
número máximo de instâncias, por servidor, estava limitado a 16. No SQL Server 2005, podemos
ter até 50 instâncias, por servidor, para o SQL Server 2005 Enterprise Edition e até 16 instâncias
para as demais edições do SQL Server 2005.
♦ Criação de servidores espelhados (Database Mirroring): Esta é uma novidade que eu

realmente aprecio, pois é de grande utilidade. Com o SQL Server 2005 você pode configurar
um servidor espelho de um servidor de produção. Quaisquer alterações que forem feitas no
servidor de produção serão repassadas, automaticamente, para o servidor espelho. Havendo
qualquer problema com o servidor de produção, rapidamente o servidor espelho poderá
ser ativado, para assumir o papel do servidor de produção. A grande vantagem do Database
Mirroring é que o tempo de parada é bastante reduzido e o servidor espelho é sempre
mantido atualizado.
♦ Instance Availability: Dedicated Administrator Connection (Conexão dedicada para o
Administrador): Este é outro recurso de grande valor. Em determinadas situações, pode
ocorrer de uma instância do SQL Server simplesmente congelar, trancar. Nestas situações,
o servidor fica instável e pode ocorrer de você não conseguir se conectar usando as
ferramentas de administração tradicionais, tais como o SQL Server Management Studio.
Muitas vezes, o administrador acaba reinicializando o Windows, para tentar normalizar a
instância do SQL Server que está com problemas. Com o SQL Server 2005, você tem a
opção de criar uma Dedicated Administrator Connection (Conexão dedicada para o
Administrador), através da qual será possível diagnosticar e resolver problemas, mesmo em
uma instância que esteja instável, não respondendo aos comandos e ferramentas
tradicionais. Uma Dedicated Administrator Connection (Conexão dedicada para o
Administrador) é como se fosse uma conexão de alta prioridade, para a qual o SQL Server
2005 “dá atenção” e responde, mesmo em situações extremas, com problemas graves. É um
recurso realmente de grande utilidade.
♦ Hot-Add Memory (Adição de memória a quente): Com o SQL Server 2005, desde que o
hardware do servidor dê suporte, evidentemente, você pode adicionar mais memória RAM,
sem desligar o servidor. O SQL Server 2005 automaticamente reconhece e passa a utilizar a
nova quantidade de memória disponível. Não é possível remover memória, sem desligar o
servidor. Somente é possível adicionar memória, sem o desligamento do servidor.
♦ Database Snapshots: Com o SQL Server 2005 é possível criar um snapshot de um Banco de
Dados e, se necessário, utilizar este snapshot para restaurar o Banco de Dados ao estado de
quando o snapshot foi feito. Por exemplo, às nove horas você cria um snapshot de um Banco
de Dados. Todos os dados e configurações do Banco de Dados e de todos os seus objetos
estarão gravados no snapshot. Agora suponhamos que em torno de 9:05 você executou, por
engano, comandos que fizeram uma verdadeira “bagunça” no Banco de Dados, excluindo
tabelas e configurações vitais para o funcionamento do Banco de Dados. Você pode
simplesmente utilizar o Snapshot criado às 9:00, para restaurar o Banco de Dados ao estado
em que ele se encontrava às 9:00 horas, ou seja, antes de terem sido executados os comandos
que “bagunçaram” o Banco de Dados. A vantagem do snapshot, em relação ao backup/re-
store, é que o snapshot é bem mais fácil e rápido de ser utilizado, reduzindo com isso o
tempo de parada do Banco de Dados.
♦ Online Restores: Nas versões anteriores do SQL Server, era preciso concluir o restore de
todo o Banco de Dados, antes que este pudesse ser colocado online e acessado pelos
usuários. Com o SQL Server 2005, o banco é colocado online logo após o início do restore
e os dados que já foram restaurados já passam a estar disponíveis para os usuários. Isso
também reduz o tempo de indisponibilidade do servidor, por ocasião do restore de um
Banco de Dados.
♦ Outras novidades: Existem outras novidades, na melhoria do Uptime dos Bancos de Dados do
SQL Server 2005. Você encontra informações detalhadas, sobre estas novidades, no Books Online,
o qual é o sistema de Ajuda, instalado com o SQL Server 2005: Iniciar -> Programas -> Microsoft
SQL Server 2005 -> SQL Server Books Online. Uma vez aberto o Books online, clique em SQL
Server Books Online -> What’s New in SQL Server 2005 -> Database Engine Enhancements ->
Database Engine Availability Enhancements.
OUTRAS NOVIDADES DA MÁQUINA DE BANCO DE DADOS DO SQL SERVER 2005

Você encontra uma série de outras novidades, sobre a máquina de Banco de Dados do SQL Server 2005,
nos seguintes caminhos, dentro do Books Online:
♦ SQL Server Books Online -> What’s New in SQL Server 2005 -> Database Engine Enhancements
-> Database Engine XML Enhancements
-> Database Engine Scalability and Performance Enhancements
-> Database Engine International Enhancements
NOVIDADES E MELHORIAS DAS FERRAMENTAS

E UTILITÁRIOS DE ADMINISTRAÇÃO
Esta foi outra áreas que o SQL Server 2005 deu um verdadeiro “salto” em relação às versões anteriores.
A seguir descrevo as principais novidades nesta área, sendo que a maioria delas será detalhada, no
decorrer deste livro.
♦ Novo console de administração – SQL Server Management Studio: No SQL Server 2000, o
principal console de administração era o SQL Server Enterprise Management. No SQL Server
2005 foi criado um novo console – SQL Server Management Studio. Este novo console
apresenta uma série de novas funcionalidades e melhorias, dentre as quais cabe destacar a
integração da interface para execução de comandos, diretamente no SQL Server Manage-
ment Studio. Por exemplo, no SQL Server 2000 havia o SQL Server Enterprise Management
que era a interface gráfica para administração e o Query Analyzer, o qual era utilizado para
execução de comandos T-SQL. No SQL Server 2005, estas duas funções estão integradas no
SQL Server Management Studio, conforme você verá, através dos exemplos práticos, nos
demais capítulos deste livro.
♦ Melhorias na ferramenta de criação de consultas: A ferramenta gráfica para a criação de

consulta foi bastante melhorada no SQL Server 2005. Você irá utilizar esta ferramenta quando
for abordada a criação de Views (Capítulo 9) e no Capítulo 14 - Serviços de Relatórios do SQL
Server 2005 – Reporting Services.
♦ Nova ferramenta – SQL Computer Manager: Esta ferramenta concentra em uma única
ferramenta a administração de vários serviços do SQL Server 2005: SQL Server, SQL Server
Agent, Analysis Server, Report Server, Microsoft Search, Microsoft Distributed Transaction Co-
ordinator (MS DTC)Full-Text Search. Usando o SQL Computer Manager é possível parar, pausar
e reinicializar estes serviços. Também é possível fazer configurações básicas dos protocolos de
redes, utilizados pelo SQL Server 2005, usando o SQL Computer Manager.
♦ Melhorias na ferramenta Database Tuning Advisor: O Database Tuning Advisor é um

assistente, o qual é utilizado para fazer uma análise dos índices de uma tabela ou de todo o
Banco de Dados. Este assistente após a análise pode sugerir e aplicar alterações, para melhorar
o desempenho dos índices e do Banco de Dados como um todo. Diversas melhorias foram
introduzidas neste assistente, tais como a possibilidade de gerar os resultados da sua execução
no formato XML, a possibilidade de fazer ajuste em triggers, etc.
♦ Melhorias no DTS Import/Export Wizard: O DTS é uma ferramenta utilizada para importação
e exportação de dados do e para o SQL Server 2005. Além de importar e exportar dados, nos
mais variados formatos, o DTS permite que sejam feitas alterações e depurações nos dados,
durante a importação/exportação. Muitas melhorias foram introduzidas no DTS do SQL Server
2005. Você aprenderá a utilizá-las no Capítulo 7.
Você encontra uma descrição completa de todas as novidades sobre as ferramentas e utilitários de
administração do SQL Server 2005 no seguinte caminho, dentro do Books Online: SQL Server Books
Online -> What’s New in SQL Server 2005 -> Tools and Utilities Enhancements.
Muitas outras melhorias e funcionalidades foram introduzidas. Conforme descrevi no início deste
tópico, não temos aqui espaço suficiente para descrever todas. A maioria delas será descrita e
exemplificada ao longo do livro. Como por exemplo o novo serviço Reporting Services, o qual será
detalhadamente abordado no Capítulo 14. Se você quer entrar de cabeça e saber logo, em detalhes,
sobre todas as novidades do SQL Server 2005, consulte uma das seguintes fontes:
♦ Acesse o Books Online: Iniciar -> Programas -> Microsoft SQL Server 2005 -> SQL Server Books
Online.
♦ O seguinte livro: “SQL Server 2005 New Features”, Editora McGraw Hill, 275 páginas. Mais
detalhes em: http://www.amazon.com/exec/obidos/tg/detail/-/0072227761/qid=1110935474/
sr=1-1/ref=sr_1_1/002-8063366-0124867?v=glance&s=books
FUNDAMENTOS EM: INSTALAÇÃO DO

MICROSOFT SQL SERVER 2005
PRÉ-REQUISITOS
♦ Conhecimentos básicos de instalação de programas no ambiente Windows.
METODOLOGIA
♦ Instalação passo a passo do SQL Server 2005.
Neste item aprenderemos a instalar o Microsoft SQL Server 2005 e a fazer o Upgrade de versões anteriores
do SQL Server 2005. Também veremos as principais diferenças entre as funcionalidades disponíveis
nas diferentes versões do SQL Server.
AS DIFERENTES “EDIÇÕES” DO MICROSFT SQL SERVER 2005

O termo “Edição” identifica as diferentes funcionalidades e capacidades do SQL Server 2005. Por
exemplo, as funcionalidades e capacidades do SQL Server 2005 Express Edition são bem diferentes das
capacidades do SQL Server 2005 Enterprise Edition.
Temos as seguintes edições:
♦ SQL Server 2005 Enterprise Edition: Esta é a versão mais completa do SQL Server 2005. É a
versão a ser utilizadas em servidores, nos quais estarão Bancos de Dados a serem utilizados
pelos usuários da rede. Por exemplo, se você precisa de um Banco de Dados, para dar suporte
a um site de Comércio Eletrônico, ou um Banco de Dados de serviços de RH, a ser consultado
por milhares de funcionários de todas as filiais da empresa, esta é a versão do SQL Server
2005 a ser utilizada.
♦ SQL Server 2005 Developer Edition: Esta edição é especialmente indicada para
desenvolvedores. Ele tem todas as funcionalidades do SQL Server 2005 Enterprise Edition,
porém é licenciada apenas para uso em uma estação de desenvolvimento e testes. Você já deve
estar pensando “e seu eu comprar esta edição, que é mais barata e usar ela em um servidor de
produção”. Além de ser ilegal, não irá funcionar, pois esta edição tem um número bem limitado
de conexões que são aceitas, simultaneamente, o que impede, na prática, o seu uso em um
servidor da rede. Você pode desenvolver todos os Bancos de Dados e aplicativos usando a
Developer Edition. Uma vez tendo sido tudo testado e aprovado, você pode simplesmente
fazer o upgrade para a Enterprise Edition, para colocar o Banco de Dados e os sistema
desenvolvidos, em produção.
♦ SQL Server 2005 Express Edition: Esta é uma edição que contém um conjunto mínimo de
funcionalidades do SQL Server 2005. Esta edição é utilizada no desenvolvimento de aplicações.
Por exemplo, se você está desenvolvendo uma aplicação, usando VB.NET, e quer armazenar os
dados desta aplicação em um Banco de Dados do SQL Server 2005. Você pode utilizar o SQL
Server 2005 Express Edition como servidor de Banco de Dados. Você terá acesso somente as
funcionalidades mínimas, tais como criação de tabelas, índices e consultas. Como esta Edição
é gratuita, ele barateia bastante o desenvolvimento de aplicações que armazenam dados em
Bancos de Dados no formato do SQL Server 2005. Claro que ela tem limitações quanto ao
desempenho e capacidades, sendo indicada apenas para pequenas aplicações. Eu diria para
aplicações a serem utilizadas por 10 ou menos usuários.
♦ SQL Server 2005 Mobile Edition: É uma edição limitada SQL Server 2005, a qual é indicada para
uso em dispositivos móveis, tais como Notebooks e Assistentes pessoais. Apresenta capacidades
de replicação de dados com servidores rodando o SQL Server 2005 Enterprise Edition.
REQUISITOS DE HARDWARE E SOFTWARE

PARA A INSTALAÇÃO DO SQL SERVER 2005
Antes de instalarmos o SQL Server 2005, existem algumas recomendações que devemos observar,
segundo a documentação do Books OnLine, conforme descrito a seguir.
Antes de instalar o SQL Server 2005, verifique os seguintes fatores:
♦ Certifique-se de que o computador onde será instalado o SQL Server 2005 (versões de 32 bits)
atenda aos requisitos mínimos de hardware, que são:
1. Processador padrão Intel, Pentium 600 MHz ou superior. O recomendado é um mínimo de

Pentium de 1 GHz.
2. Memória RAM de, no mínimo, 256 MB, sendo 512 MB recomendado.
3. Depende dos serviços que você irá instalar. O SQL Server 2005 precisa em torno de 350 MB.
Se você for instalar também o Analysis Services, precisará de algo em torno de 150 MB
adicionais. Se você for instalar também o Reporting Services, precisará mais 100 MB. Ou
seja, com 1 GB dá e sobra, mesmo instalando todos os serviços disponíveis.
4. Monitor ou superior, com resolução de 1024 x 768 ou superior.

5. Microsoft mouse ou compatível.
6. Drive de CD-ROM ou leitor de DVD.

NOTA
Evidentemente que estas são características mínimas de hardware, para que você possa instalar o SQL Server 2005. Na prática, o hardware
a ser utilizado depende da utilização que o servidor SQL sofrerá. Para isso devemos levar em consideração fatores como o número de
usuários simultâneos, o volume de informações sendo acessadas, etc.
♦ Os requisitos mínimos de software dependem da versão do SQL Server 2005 que será instalada.
No início deste item, temos uma descrição completa das diferentes edições do SQL Server. Na
Tabela 2.1, você tem uma relação, contida no Books Online, a qual descreve em quais versões
do Windows cada edição do SQL Server 2005 pode ser instalada.
Tabela 2.1 Versões do Windows x Edições do SQL Server 2005.
Versão do Windows/Edição do SQL Server 2005 Developer Edition SQL Express Edition
Windows Server 2003 Standard Edition Yes Yes

Windows Server 2003 Enterprise Edition Yes Yes
Windows Server 2003 Datacenter Edition Yes Yes
Windows 2003 Embedded Edition Yes Yes
Windows 2003 Web Edition Yes Yes
Windows Small Business Server 2003 Standard Edition Yes Yes
Windows Small Business Server 2003 Premium Edition Yes Yes
Windows XP Professional SP1 or later Yes Yes
Windows XP Media Edition, SP1 or later Yes Yes
Windows XP Tablet Edition, SP1 or later Yes Yes
Windows 2000 Professional SP41 or later Yes Yes
Windows 2000 Server SP41 or later Yes Yes
Windows 2000 Advanced Server SP41 or later Yes Yes
Windows 2000 Datacenter Server SP4 or later
1
Yes Yes
♦ Se você estiver fazendo um upgrade de uma versão anterior do SQL Server, faça o backup de
todos os Bancos de Dados, antes de iniciar o upgrade.
♦ Faça um planejamento cuidadoso para definir fatores como as pastas de instalação do SQL
Server, as opções regionais relativas ao conjunto de caracteres e ordem de ordenação, o número
de instâncias que você irá instalar e as demais opções envolvidas durante o processo de instalação.
É sempre recomendável fazermos a instalação em um ambiente de teste. Depois de estarmos
familiarizados com o processo de instalação, podemos partir para o servidor de produção.
Antes de iniciar a instalação do SQL Server, tome mais os seguintes cuidados:
1. Crie uma ou mais contas com as quais irão rodar os serviços do SQL Server. No nosso exemplo,
estarei utilizando a conta de administrador do domínio. Em muitas situações o ideal é criar
uma conta especialmente para o SQL Server, ao invés de utilizar a conta de administrador.
2. Parar qualquer serviço que esteja utilizando ODBC, como por exemplo o IIS – Internet Infor-
mation Services. Para parar o IIS utilize o seguinte comando em um prompt de comando:
net stop w3svc
para reiniciar o IIS utilize o seguinte comando:

net start w3svc
3. Quando for instalar o SQL Server 2005, faça o logon com uma conta que tenha permissões de
Administrador do domínio, ou Administrador local, se você estiver instalando o SQL Server
2005 em um servidor que não faz parte de um domínio.
RECOMENDAÇÕES DE SEGURANÇA, ANTES INSTALAÇÃO DO SQL SERVER 2005

Existem alguns cuidados e recomendações, em relação à segurança, os quais devem ser observados,
antes de partirmos para a instalação SQL Server 2005. A seguir descrevo os cuidados a serem observados:
♦ O primeiro passo é garantir medidas básicas de segurança (tanto físicas quanto lógicas), para o
servidor onde será instalado o SQL Server 2005. Estas medidas incluem ações tais como:
♦ Garantir a segurança física e o controle de acesso à sala dos servidores.
♦ Instalação e configuração de um firewall entre a rede da sua empresa e o mundo externo. Se

clientes de fora precisarem acessar dados no servidor SQL Server 2005, as portas TCP 1433 e
UDP 1434 deverão estar habilitadas, no firewall.
♦ Sempre que possível, instale diferentes serviços em diferentes servidores. Por exemplo, instale
os serviços básicos de Banco de Dados em um servidor e os serviços de geração de relatórios
em outro servidor. Isso evita que problemas em um dos serviços paralisem todos os demais
serviços (o que ocorreria se todos estivessem no mesmo servidor).
♦ Nunca instale o SQL Server 2005 em um DC do domínio, por questões de desempenho. Nos
exemplos deste livro, estou utilizando o SQL Server 2005 em um DC, apenas por questões de
falta de mais computadores, na minha rede doméstica. Mas em um ambiente de produção,
você deve, sempre que possível, evitar de instalar o SQL Server 2005 em um DC do domínio,
por questões de desempenho e segurança.
♦ Use somente partições formatadas com o sistema de arquivos NTFS. O uso de partições com
FAT32 deve ser completamente descartado, por questões de segurança. Se você usar
criptografia na pasta onde forem armazenados os arquivos dos Bancos de Dados do SQL
Server 2005, os arquivos serão criptografados em nome da conta com a qual foi configurado
para rodar o Serviço do SQL Server 2005. Somente esta conta será capaz de descriptografar
os dados. Se, por algum motivo, você precisar alterar a conta com a qual é executado o
service do SQL Server 2005, você deverá primeiro descriptografar os arquivos, usando a
conta antiga e então criptografá-los novamente, usando a nova conta.
♦ Para garantir um melhor desempenho e redundância, você pode usar volumes do tipo RAID-
5, para dados críticos, os quais necessitam de melhor desempenho e maior disponibilidade.
O mais indicado (embora seja mais caro) é o uso de soluções da RAID implementadas em
hardware (placas de RAID). Se não for possível o uso de soluções de RAID via hardware, você
pode usar as soluções de RAID em software, disponíveis no Windows 2000 Server e no
Windows Server 2003.
♦ Outro aspecto fundamental a ser considerado, em um ambiente de produção, é a segurança
física. A sala onde estará o computador, no qual o SQL Server 2005 será instalado, deve estar
protegida do acesso ao público, tendo o acesso controlado e liberado somente para pessoas
autorizadas. De nada adiantará você cuidar de toda a segurança lógica do acesso às informações
do SQL Server 2005, se a segurança física for deixada de lado.
NOMEANDO AS INSTÂNCIAS DO SQL SERVER 2005

Uma das novidades introduzidas no SQL Server 2000 foi a possibilidade de instalar múltiplas instâncias
do SQL Server, em um mesmo servidor. No SQL Server 2000 você poderia instalar até 16 instâncias em
um mesmo servidor. No SQL Server 2005, este limite foi aumentado para até 50 instâncias em um
único servidor. Neste tópico, apresentarei algumas considerações, sobre a nomeação de múltiplas
instâncias, em um servidor com o SQL Server 2005.
Conforme descrevi no início do capítulo, o SQL Server 2005 é um servidor de Banco de Dados (sua
principal função, dentre outras). O mais comum é manter os dados no SQL Server 2005, e criar aplicações
clientes, que acessam estes dados, quer sejam aplicações Cliente/Servidor tradicionais, até as mais
modernas aplicações Web com quatro ou mais camadas.
As aplicações clientes se conectam com uma instãncia do SQL Server 2005, para acessar as tabelas e
demais objetos dos Bancos de Dados do SQL Server 2005. Cada instância do SQL Server 2005 é como se
fosse um servidor completamente independente, podendo oferecer um diferente conjunto de services
e configurações.
Uma instância pode ser de dois tipos: A instância padrão ou uma instância nomeada. A instância
padrão é gerada pelo programa de instalação do SQL Server 2005, baseada no nome do computador no
qual o SQL Server 2005 está sendo instalado e não requer que a aplicação cliente especifique o nome da
instância, para fazer a conexão. Por exemplo, em um servidor chamado dbserv01, o nome do servidor
– dbsrv01 será também o nome da instância padrão, ou seja, a instância à qual os clientes irão se
conectar, a menos que seja especificado o nome de uma instância diferente. Já uma instância nomeada
é identificada pelo nome do computador, bem como pelo nome da instância, a qual é criada pelo
usuário. Por exemplo, no servidor dbsrv01, o usuário pode criar uma instância nomeada como vendas.
Neste caso, o nome completo da instância fica sendo: dbsrv01\vendas. Observe que o padrão para as
instâncias nomeadas é: nome_do_servidor\nome_da_instância.
Quando você instala o SQL Server, pela primeira vez em um servidor, o programa de instalação irá criar
automaticamente a instância padrão. Você pode aceitar esta opção ou alterar para criar já uma instância
nomeada, sem que seja instalada uma instância padrão.
Considere os seguintes detalhes, em relação à nomeação de instâncias, no SQL Server 2005:
♦ As instâncias nomeadas não diferem maiúsculas de minúsculas. Para o SQL Server 2005,
dbsrv01\vendas ou DBSRV01\VENDAS ou dbsrv01\Vendas, representam exatamente a
mesma instância.
♦ O nome de uma instância nomeada não pode conter palavras reservadas do SQL Server 2005,
tais como SELECT, Default, MSSQLServer e assim por diante. Se você especificar uma palavra
reservada, o processo de instalação irá apresentar um erro e não será concluído.
♦ O nome da instância é limitado a 16 caracteres.
♦ O primeiro caractere do nome da instância deve ser uma letra ou um sinal de sublinhado ( _ ). Os
caracteres subseqüentes podem ser letras, números decimais, o sinal de $ ou sublinhado ( _ ).
♦ Não são permitidos espaços em branco no nome da instância e nem os seguintes caracteres: \
, : ‘ & # @
♦ Considere os seguintes detalhes, ao decidir se você irá criar uma instância default ou uma
instância nomeada:
♦ Se você estiver fazendo o upgrade do SQL Server 7.0 para o SQL Server 2005, obrigatoriamente
será criada uma instância default.
♦ Se você for instalar uma única instância do SQL Server 2005, opte por usar uma instância
default.
♦ Se você estiver instalando o Microsoft SQL Server 2005 Express Editionl, a opção Named In-
stance (Instância Nomeada) virá selecionada, automaticamente, no assistente de instalação.
Para instalar uma instância default do SQL Server Express Edition, selecione a opção Default
Instance.
Para acompanhar os exemplos deste livro, você deve instalar o SQL Server 2005 Developers Edition ou o SQL Server 2005 Enterprise Edition. No
NOTA
exemplo do próximo tópico, mostrarei como instalar, passo-a-passo, o SQL Server 2005 – Developers Edition. Utilizarei a versão Beta 2 do SQL
Server 2005, a qual é a versão disponível, no momento em que escrevo este livro. Pequenas diferenças poderão existir entre a versão Beta 2 e
a versão final, normalmente relacionadas a problemas e erros existentes na versão Beta 2, os quais são corrigidos para a versão final. Mas são
pequenas diferenças mesmo, sendo que a quase totalidade das telas e comandos será exatamente a mesma, na versão final.
INSTALANDO O SQL SERVER 2005 NO WINDOWS SERVER 2003

Vamos aprender, passo a passo, a instalar o SQL Server 2005, Developer Edition. Neste exemplo usarei
um computador que está rodando o Windows Server 2003. Você pode usar um computador rodando
qualquer uma das seguintes versões do Windows: Windows 2000 Professional, Windows 2000 Server,
Windows XP Professional ou Windows Server 2003. Iremos instalar o SQL Server 2005 em um
computador chamado SERVIDOR2. Inicialmente iremos criar uma instância default.
Para Instalar o SQL Server 2005 Developer Edition, siga os passos indicados a seguir:
1. Faça o logon com uma conta com permissões de Administrador no servidor onde o SQL Server
2005 será instalado.
2. Coloque o CD-ROM do SQL Server 2005 no drive de CD e aguarde alguns instantes. Deve
surgir a tela indicada na Figura 2.6. Esta tela apresenta três grupos de opções: O primeiro grupo
é Prepare. Este grupo dá acesso a opções de preparação, as quais devem ser tomadas antes da
instalação do SQL Server 2005. Ao clicar na opção Review Hardware e Software Requirements,
será aberta uma janela de ajuda, com informações sobre o hardware e software, necessários à
instalação do SQL Server 2005. A opção Read the release notes abre o arquivo readme.txt, que
está gravado no diretório raiz do CD. Este arquivo contém orientações que foram elaboradas
pela equipe do SQL Server 2005, com dicas de última hora. É sempre uma boa idéia ler este
arquivo antes de iniciar a instalação. Visit Our Web Site: Esta opção é um link para o site oficial
do SQL Server, no seguinte endereço: www.microsoft.com/sql.
Figura 2.6 Tela inicial da instalação do SQL Server 2005.
3. Para iniciar a instalação, clique na opção Run the SQL Server Instalattion Wizard. Será exibida
uma tela, com o contrato de licença do SQL Server 2005. Para seguir com a instalação, você
deve marcar a opção “I accept de licensing terms and conditions” e clicar em Next. Faça isso.
Será exibida a próxima tela do assistente.
4. Será exibida uma tela, mostrando quais componentes serão instalados, para que seja possível a
instalação do SQL Server 2005, conforme indicado na Figura 2.7. Nesta figura você pode observar
que será instalado o .NET Framework 2.0, o Microsoft SQL Native Client e o SQL Server 2005
(Beta 2). Clique no botão Install, para continuar com a instalação.
Figura 2.7 Lista de componentes de suporte que serão instalados.
5. A instalação dos itens que são pré-requisitos para o SQL Server 2005, tais como o .NET Framewok,
será iniciada. O andamento será indicado, conforme exemplo da Figura 2.8:
Figura 2.8 Instalando os componentes necessários à instalação do SQL Server 2005.
6. A instalação dos componentes que são necessários, antes que o SQL Server 2005 possa ser
instalado, será concluída. Quando a instalação for concluída, o botão Finish será habilitado.
Clique no botão Finish para iniciar a instalação do SQL Server 2005 propriamente dito, já que
o que foi instalado até agora foram os componentes que dão suporte à execução do SQL Server
2005, tais como o .NET Framework 2.
Figura 2.9 A tela inicial do assistente de instalação do SQL Server 2005.
7. O processo de instalação do SQL Server 2005 faz uma série de verificações e passa a copiar
arquivos do CD de instalação. A tela inicial do assistente de instalação do SQL Server 2005 será
exibida, conforme indicado na Figura 2.
8. Clique em Next para seguir para a próxima etapa do assistente de instalação. O assistente de
instalação fará uma verificação, para certificar-se de que está tudo OK para iniciar a instalação.
Será exibida uma listagem dos componentes verificados. Se algum problema for detectado,
será exibido um x ao lado do componente com problemas. Na coluna Message é
disponibilizado um link. Se você clicar neste link, é exibida uma mensagem indicando o que
deve ser feito, para solucionar o problema que está impedindo a instalação do SQL Server
2005. Você deve solucionar o problema, antes de prosseguir com a instalação. No nosso
exemplo, nenhum problema foi detectado e a instalação pode continuar, sem problemas,
conforme indicado na Figura 2.10
Figura 2.10 Não foram encontrados problemas que impeçam a continuação da instalação.
9. Clique no botão Continue, para continuar com a instalação do SQL Server 2005.
10. O assistente de instalação faz uma série de preparações e exibe uma tela, para que você coloque
o seu nome, nome da sua empresa e o número de série do SQL Server 2005, conforme indicado
na Figura 2.11:
Figura 2.11 Inserindo informações do nome e número de série.
11. Clique em Next, para seguir para a próxima etapa do assistente de instalação.
12. Nesta etapa você deve marcar quais os serviços que serão instalados, conforme exemplo da
Figura 2.12. Ao instalar o SQL Server 2005, diversos serviços podem ser instalados. De uma
maneira simples, um serviço é um programa que fica residente na memória do servidor, mesmo
que não exista usuário logado na console do servidor. Quando o usuário faz o log off, o serviço
continua carregado na memória atendendo às requisições dos clientes. Todo serviço no Win-
dows 2000 ou no Windows Server 2003 precisa ser executado no contexto de uma conta. Por
isso que precisamos informar uma conta para que os serviços possam ser inicializados. No
Windows 9.x não existe o conceito de serviço. No final do capítulo veremos um pouco mais
sobre os serviços que são instalados com o SQL Server e como gerenciar estes serviços. O SQL
Server é o service básico, o Banco de Dados em si. Você pode instalar outros serviços, tais como
o Analysis Services, Reporting Services e assim por diante. A dica aqui é instalar somente os
serviços que você irá realmente utilizar. Se você está instalando o SQL Server 2005 em um
servidor de produção, deve instalar somente os serviços que serão utilizados. Se você está
instalando o SQL Server 2005 em um servidor para estudo, deve instalar todos os serviços, para
tê-los disponíveis para estudar, quando necessário.
13. Marque os serviços a serem instalados e clique em Next, para seguir para a próxima etapa do
assistente de instalação.
14. Nesta etapa é que você seleciona se você deseja criar uma instância default ou uma instância
nomeada, conforme descrito anteriormente. Nesta primeira instalação, vamos criar uma
instância nomeada. Certifique-se de que a opção Default instance esteja marcada e clique em
Next, para seguir para a próxima etapa do assistente de instalação.
Figura 2.12 Selecione os serviços a serem instalado.
15. Nesta etapa você irá definir com qual conta cada serviço do SQL Server irá rodar. Você pode
definir a mesma conta para todos os serviços, ou definir uma conta diferente para cada um
dos serviços. Você pode optar por usar a conta local System (sendo esta a opção mais
recomendada), ou informar uma conta do domínio. Se você marcar a opção Customize for
each service account, a lista abaixo desta opção será habilitada. Aí você escolhe um serviço
na lista e define a conta para o serviço selecionado. Depois você seleciona um novo serviço
na lista e define a conta para este novo serviço e assim por diante. Com a opção Customize
for each service account, você pode definir configurações personalizadas, para cada um dos
serviços. No nosso exemplo, vou usar a mesma conta para todos os serviços (opção Custom-
ize for each service account desmarcada) e vou informar uma conta do domínio, conforme
exemplo da Figura 2.13:
Figura 2.13 Definindo as configurações de conta.
16. Defina as configurações desejadas e clique em Next, para seguir para a próxima etapa do
17. Nesta próxima etapa você deve definir o modo de autenticação que será usado, pela instância
do SQL Server que está sendo instalada. Existe o modo Windows Authentication Mode. Com
esse modo, somente contas do domínio poderão ser utilizadas para acessar o SQL Server 2005.
Usando o modo Mixed Mode, poderão ser usadas contas do domínio e também contas do SQL
Server 2005. No Capítulo 6, sobre segurança, você aprenderá mais detalhes sobre os modos de
autenticação. Nesta etapa, você também pode definir uma senha para a conta sa. A conta sa é
a conta de administrador do SQL Server 2005, ou seja, a conta com maiores “poderes” no SQL
Server 2005. Por isso sempre é recomendado definir uma senha forte para esta conta. Entenda-
se por senha forte uma senha que usa letras, números e caracteres especiais e que tenha, no
mínimo, 10 caracteres. Defina as configurações desejadas, conforme exemplo da Figura 2.14:
Figura 2.14 Definindo o modo de autenticação e a senha da conta sa.
19. Nesta etapa você define as configurações de Collation (cada idioma tem configurações próprias)
e outras características que afetam a maneira como o SQL Server 2005 irá fazer as comparações
de dados, para filtrar os registros, ao executar uma consulta. Você pode habilitar ou desabilitar
opções como Case sensitive (diferenciar maiúsculas e minúsculas ou não), Accent sensitve
(diferenciar acentos ou não) e assim por diante. Defina as configurações desejadas e clique em
Next, para seguir para a próxima etapa do assistente.
20. Nesta etapa você deve informar se o Banco de Dados do Reporting Services será armazenado na
instância que está sendo instalada ou em uma instância já existente. No nosso exemplo, como é a
primeira instância que está sendo instalada, certifique-se de que a opção Host in the current instace
of SQL Server esteja marcada e clique em Next, para seguir para a próxima etapa do assistente.
21. Nesta etapa você deve informar o nome de um servidor smpt e o endereço do remetente.
Estas informações serão utilizadas pelo Reporting Services, para o envio de relatórios por e-
mail. Você aprenderá mais sobre estas funcionalidades no Capítulo 14. Informe o nome do
servidor SMPT e o endereço de e-mail do remetente e clique em Next, para seguir para a
próxima etapa do assistente.
22. Nesta etapa você pode marcar a opção para enviar relatórios diretamente para a Microsoft, em
caso de erros fatais na execução do SQL Server 2005 ou de um dos seus componentes. Não sei
se esta etapa estará disponível na versão final ou se somente nas versões Beta. Aceite as
configurações sugeridas e clique em Next, para seguir para a próxima etapa do assistente.
23. Será exibida a tela final do assistente, com um resumo de todas as opções selecionadas, conforme
indicado na Figura 2.15:
Figura 2.15 Etapa final do assistente de instalação.
24. Você pode usar o botão Back para voltar a uma das etapas anteriores e alterar alguma
configuração, caso seja necessário. Para concluir a instalação, clique no botão Install e aguarde.
Será exibida uma janela, com o progresso da instalação, conforme indicado na Figura 2.16:
25. Uma vez concluída a instalação será habilitado o botão Next. Será exibida a tela final do assistente,
indicando que a instalação foi concluída com sucesso, conforme indicado na Figura 2.17.
26. Clique em Finish para encerrar o assistente. Pronto, o SQL Server 2005 está instalado no
seu computador. Agora só precisamos aprender a utilizá-lo. Mas isso é assunto para todo o
restante deste livro.
Figura 2.16 O progresso da instalação do SQL Server 2005.
Figura 2.17 Instalação concluída com sucesso.
A seguir descrevo alguns dados importantes sobre o SQL Server 2005, tais como a estrutura de pastas e
subpastas que é criada e quais os principais arquivos relacionados a cada serviço do SQL Server 2005.
A ESTRUTURA DE PASTAS E ARQUIVOS DO SQL SERVER 2005

Neste item, mostrarei qual a estrutura de pastas e arquivos, que é criada pelo SQL Server 2005. Uma
instalação do SQL Server 2005 é formada por uma ou mais instâncias, podendo ser uma instância
padrão e uma ou mais instâncias nomeadas, conforme descrito anteriormente. Cada instância tem um
conjunto de arquivos únicos, utilizados somente pela instância. Existe também um conjunto de pastas
e arquivos comuns, isto é, utilizados por todas as instâncias. Por exemplo, para uma instância do SQL
Server 2005, na qual foram instalados os services básicos da máquina de Banco de Dados, além do
Analysis Services e do Reporting Services, cada componente, de cada instância, tem um conjunto
próprio de dados e arquivos executáveis, além de um conjunto de arquivos que é compartilhado por
todos os componentes, de todas as instâncias.
Por padrão, o SQL Server 2005 é instalado na seguinte pasta:
♦ C:\Arquivos de programas\Microsoft SQL Server
Os arquivos comuns, isto é, os arquivos que são compartilhados por todas as instâncias do SQL Server
2005, são gravados na seguinte pasta: C:\Arquivos de programas\Microsoft SQL Server\90,
considerando que o SQL Server 2005 foi instalado no drive C:
Figura 2.18 Estrutura de pastas e subpastas do SQL Server 2005.
Na Figura 2.18, retirada do Books Online, temos uma representação que mostra, claramente, a estrutura
de pastas utilizada pelo SQL Server 2005. Nesta figura, temos a representação da estrutura onde são
gravados os arquivos compartilhados por todas as instâncias e das estruturas de pastas que são utilizadas
por cada instância, individualmente.
Na Tabela 2.2, obtida a partir do Books Online, é exibido o caminho padrão, para os principais arquivos
do SQL Server 2005. Este caminho pode ser alterado, durante a instalação. Systemdrive representa o
drive onde o SQL Server 2005 foi instalado; normalmente é o drive C:, mas pode ser outro drive.
Tabela 2.2 Caminho padrão de instalação dos principais componentes.
Funcionalidade Caminho padrão
Database Engine
Server Components \Program Files\Microsoft SQL Server\MSSQL.n\MSSQL\Binn\
Data Files \Program Files\Microsoft SQL Server\MSSQL.n\MSSQL\Data\
Analysis Services
Analysis Server \Program Files\Microsoft SQL Server\MSSQL.n\OLAP\Bin\
Data Files \Program Files\Microsoft SQL Server\MSSQL.n\OLAP\Data
Reporting Services
Report Server \Program Files\Microsoft SQL Server\MSSQL.n\Reporting Services\ReportServer\Bin\
Report Manager \Program Files\Microsoft SQL Server\MSSQL.n\Reporting Services\ReportManager\Bin\
Notification Services \Program Files\Microsoft SQL Server\90\NotificationServices\
Data Transformation Services \Program Files\Microsoft SQL Server\90\DTS\
CRIANDO UMA SEGUNDA INSTÂNCIA

DO SQL SERVER DEVELOPER EDITION
Anteriormente havíamos instalado uma instância default (não nomeada) no computador chamado
SERVIDOR2. Agora vamos instalar uma segunda instância, a qual será obrigatoriamente uma instância
nomeada (lembre-se de que temos uma única instância padrão e todas as demais são instâncias nomeadas)
chamada JBCURSOS, neste mesmo servidor. Com isso, teremos as seguintes instâncias disponíveis:
♦ SERVIDOR2: esta é a instância default
♦ SERVIDOR2\JBCURSOS: primeira instância nomeada
Conforme descrito anteriormente, é como se tivéssemos dois servidores SQL Server completamente
separados, porém rodando no mesmo computador. Então mãos à obra.
Para criar uma segunda instância do SQL Server 2005 Developer Edition, siga os passos indicados a seguir:
1. Faça o logon com uma conta com permissões de administrador.
2. Coloque o CD do SQL Server 2005 Developer Edition no drive de CD. Será exibida a tela inicial
do CD de instalação.
3. Na tela inicial da instalação, dê um clique na opção Rum the SQL Server Installation Wizard.
4. Será exibida a tela com o contrato de licença. Marque a opção “I accept the licensing terms and
conditions” e clique no botão Next, para seguir para a próxima etapa.
5. Na tela inicial, dê um clique no botão Next. Será exibida a janela Computer Name.
6. Certifique-se de que a opção Local Computer esteja marcada e dê um clique no botão Next.
7. Será exibida a janela Installation Selection. Certifique-se de que a opção Create a new instance
of SQL Server, or install Client Tools esteja selecionada e dê um clique no botão Next. Como é
uma segunda instância que está sendo instalada, os componentes que são pré-requisitos para o
SQL Server 2005 já estão instalados, tais como o .NET Framewok 2. Será exibida uma tela,
informando que os componentes necessários à instalação do SQL Server 2005 já estão
disponíveis. Clique em Finish, para fechar esta tela. O assistente de instalação será iniciado.
Aguarde até que seja exibida a primeira tela do assistente de instalação. A primeira tela é apenas
informativa. Clique em Next, para seguir para a próxima etapa do assistente.
8. O assistente de instalação fará uma verificação, para certificar-se de que está tudo OK para
iniciar a instalação, ou seja, que todos os componentes que são pré-requisitos para a instalação
estão instalados e corretamente configurados. Será exibida uma listagem dos componentes
verificados. Se algum problema for detectado, será exibido um x ao lado do componente com
problemas. Na coluna Message é disponibilizado um link. Se você clicar neste link, é exibida
uma mensagem indicando o que deve ser feito para solucionar o problema, que está impedindo
a instalação do SQL Server 2005. Você deve solucionar o problema, antes de prosseguir com a
instalação. No nosso exemplo, nenhum problema foi detectado e a instalação pode continuar,
sem problemas, conforme indicado na Figura 2.19.
Figura 2.19 Não foram encontrados problemas que impedem a continuação da instalação.
9. Clique no botão Continue, para continuar com a instalação da segunda instância do SQL
Server 2005.
10. O assistente de instalação faz uma série de preparações e exibe uma tela, para que você coloque o seu
nome, o nome da sua empresa e o número de série do SQL Server 2005. Insira as informações solicitadas.
12. Nesta etapa você deve marcar quais os serviços que serão instalados, conforme exemplo já descrito
anteriormente, na Figura 2.12. Ao instalar o SQL Server 2005, diversos serviços podem ser instalados.
No final do capítulo veremos um pouco mais sobre os serviços que são instalados com o SQL Server
e como gerenciar estes serviços. O SQL Server é o serviço básico, o Banco de Dados em si. Você pode
instalar outros serviços, tais como o Analysis Services, Reporting Services, DTS e assim por diante.
A dica aqui é instalar somente os serviços que você irá realmente utilizar. Se você está instalando o
SQL Server 2005 em um servidor de produção, deve instalar somente os serviços que serão utilizados.
Se você está instalando o SQL Server 2005 em um servidor para estudo, deve instalar todos os
serviços, para tê-los disponíveis para estudar, quando necessário.
14. Nesta etapa é que você seleciona se deseja criar uma instância default ou uma instância nomeada,
conforme descrito anteriormente. No exemplo prático anterior, criamos uma instância de-
fault. Agora iremos criar a instância nomeada CURSOSJB. Marque a opção Named instance e
digite o nome da instância, conforme indicado na Figura 2.20. Clique em Next, para seguir
para a próxima etapa do assistente de instalação.
Figura 2.20 Criando uma instância nomeada CURSOSJB.
15. Se na etapa 12 você selecionou serviços que já estavam instalados em outras instâncias, o SQL
Server 2005 exibirá uma tela, informando os componentes comuns, para os serviços que estão
também em outras instâncias. Clique em Next para seguir para a próxima etapa do assistente.
definir a mesma conta para todos os serviços, ou definir uma conta diferente, para cada um dos
serviços. Você pode optar por usar a conta local System (sendo esta a opção mais recomendada),
ou informar uma conta do domínio. Se você marcar a opção Customize for each service account,
a lista abaixo desta opção será habilitada. Aí você pode escolher um serviço na lista e define a
conta para o serviço selecionado. Depois você seleciona um novo serviço na lista e define a conta
para este novo serviço e assim por diante. Com a opção Customize for each service account, você
pode definir configurações personalizadas, para cada um dos serviços. No nosso exemplo, vou
usar a mesma conta para todos os serviços (opção Customize for each service account desmarcada)
e vou informar uma conta do domínio. Defina as configurações desejadas e clique em Next, para
seguir para a próxima etapa do assistente de instalação.
autenticação. Nesta etapa, você também pode (ou melhor, você deve definir uma senha) definir
uma senha para a conta sa. A conta sa é a conta de Administrador do SQL Server 2005, ou seja,
a conta com maiores “poderes” no SQL Server 2005. Por isso sempre é recomendado definir
uma senha forte para esta conta. Entenda-se por senha forte uma senha que usa letras, números
e caracteres especiais e que tenha, no mínimo, 10 caracteres. Defina as configurações desejadas
e clique em Next, para seguir para a próxima etapa do assistente de instalação.
19. Nesta etapa você deve informar o nome das pastas virtuais, utilizadas pelo Reporting Ser-
vices. Informe o nome das pastas virtuais e clique em Next, para seguir para a próxima
etapa do assistente.
20. Nesta etapa você deve informar se o Banco de Dados do Reporting Services será armazenado na
instância que está sendo instalada ou em uma instância já existente. No nosso exemplo, como
estamos configurando esta segunda instância, independente da primeira, certifique-se de que
a opção Host in the current instace of SQL Server esteja marcada e clique em Next, para seguir
para a próxima etapa do assistente.
21. Nesta etapa você deve informar o nome de um servidor SMTP e o endereço do remetente. Estas
informações serão utilizadas pelo Reporting Services, para o envio de relatórios por e-mail.
Você aprenderá mais sobre estas funcionalidades no Capítulo 14. Informe o nome do servidor
SMPT e o endereço de e-mail do remetente e clique em Next, para seguir para a próxima etapa
do assistente.
23. Será exibida a tela final do assistente, com um resumo de todas as opções selecionadas, conforme
Figura 2.21 Etapa final do assistente de instalação.
24. Você pode usar o botão Back para voltar a uma das etapas anteriores e alterar alguma
configuração, caso seja necessário. Para concluir a instalação, clique no botão Install e aguarde.
Será exibida uma janela, com o progresso da instalação.
25. Uma vez concluída a instalação, será habilitado o botão Next. Será exibida a tela final do
assistente, indicando que a instalação foi concluída com sucesso.
26. Clique em Finish para encerrar o assistente de instalação do SQL Server 2005. Pronto, uma
segunda instância do SQL Server 2005 está instalada no seu computador. No nosso exemplo,
foi instalada a seguinte instância nomeada: SERVIDOR2\CURSOSJB
Conforme veremos neste e nos demais capítulos, existem diversas ferramentas para administrar e
realizar as tarefas com o SQL Server 2005. Sempre que estivermos utilizando uma destas ferramentas
teremos a opção de selecionar com qual das instâncias do SQL Server instaladas queremos realizar uma
determinada operação.
Agora vamos aprender sobre os serviços que são instalados com cada instância do SQL Server e
como configurá-los para que sejam carregados automaticamente quando o Windows 2000 Server
for inicializado.
FAZENDO O UPGRADE DO SQL SERVER 2000 PARA O SQL SERVER 2005

Você pode fazer o upgrade de versões anteriores do SQL Server para o SQL Server 2005. Na listagem
a seguir, descrevo os caminhos de upgrade possíveis, de versões anteriores do SQL Server para o
SQL Server 2005:
♦ Do SQL Server 2000 SP3/SP3a ou superior para o SQL Server 2005 Beta 2 ou Superior (Beta 3 e
versão final).
♦ Do SQL Server 2005 Beta 2 para o Beta 3 ou versão Final.
♦ Não é possível desatachar um Banco de Dados do SQL Server 2005 – Beta 1 e atachar o Banco
de Dados no SQL Server 2005 – Beta 2.
Não é possível fazer o upgrade diretamente para o SQL Server 2005, a partir das versões a seguir:
♦ Do SQL Server 6.5 para o SQL Server 2005.
♦ Do SQL Server 7.0 para o SQL Server 2005.
♦ Atualização de um failover cluster não é suportada.
♦ Upgrade of MSDE is not supported.
♦ Upgrade do SQL Server 2000 (64-bit) não é suportado.
♦ Upgrade do Reporting Services 2000 não é suportado.
♦ Upgrade do Notification Services 2000 não é suportado.
♦ Não existe suporte para a atualização do MSDE para o SQL Server 2005 Beta 2 – Express Edi-
tion. Talvez tenha na versão final do Express Edition.
♦ Nesta seção, vamos fazer o upgrade do SQL Server 2000 rodando em um computador com o
Windows XP Professional, para o SQL Server 2005. Para que este upgrade seja possível, o SP3
ou SP3a do SQL Server 2000 deve estar instalado.
Exemplo: Para fazer o upgrade do SQL Server 2000 para o SQL Server 2005, siga os passos indicados a seguir:
1. Faça o logon com uma conta com permissões de administrador.
2. Coloque o CD-ROM do SQL Server 2005 no drive de CD e aguarde alguns instantes. Deve surgir a tela
de abertura do CD, indicada anteriormente na Figura 2.6. Esta tela apresenta três grupos de opções: O
primeiro grupo é Prepare. Este grupo dá acesso a opções de preparação, as quais devem ser tomadas
antes da instalação do SQL Server 2005. Ao clicar na opção Review Hardware e Software Require-
ments, será aberta uma janela de ajuda, com informações sobre o hardware e software, necessários à
instalação do SQL Server 2005. A opção Read the release notes abre o arquivo readme.txt, que está
gravado no diretório raiz do CD. Este arquivo contém orientações que foram elaboradas pela equipe
do SQL Server 2005, com dicas de última hora. É sempre uma boa idéia ler este arquivo antes de
iniciar a instalação. Visit Our Web Site: Esta opção é um link para o site oficial do SQL Server, no
seguinte endereço: www.microsoft.com/sql.
3. Para iniciar a instalação, clique na opção Run the SQL Server Instalattion Wizard. Será exibida
uma tela, com o contrato de licença do SQL Server 2005. Para seguir com a instalação, você
deve marcar a opção “I accept de licensing terms and conditions” e clicar em Next. Faça isso.
Será exibida a próxima tela do assistente.
4. Será exibida uma tela, mostrando quais componentes serão instalados, para que seja possível a
instalação do SQL Server 2005, conforme indicado na Figura 2.22. Nesta figura você pode
observar que será instalado o .NET Framework 2.0, o Microsoft SQL Native Client e o SQL
Server 2005 (Beta 2). Clique no botão Install, para continuar com a instalação.
Figura 2.22 Lista de componentes de suporte que serão instalados.
5. A instalação dos itens que são pré-requisitos para o SQL Server 2005, tais como o .NET
Framewok será iniciada. O andamento será indicado na tela do assistente de instalação.
Esta etapa pode demorar de meia hora a uma hora, dependendo do equipamento que você
está utilizando. Aguarde.
6. A instalação dos componentes que são necessários, antes que o SQL Server 2005 possa ser
instalado, será concluída. Quando a instalação é concluída, o botão Finish é habilitado. Clique
no botão Finish para iniciar a instalação do SQL Server 2005 propriamente dito, já que o que
foi instalado até agora foram os componentes que dão suporte à execução do SQL Server 2005,
tais como o .NET Framework 2 e outros.
7. O processo de instalação do SQL Server 2005 faz uma série de verificações e passa a copiar
arquivos do CD de instalação. A tela inicial do assistente de instalação do SQL Server
2005 será exibida.
8. Clique em Next para seguir para a próxima etapa do assistente de instalação. O assistente de
instalação fará uma verificação, para certificar-se de que está tudo OK para iniciar a instalação.
Será exibida uma listagem dos componentes verificados. Se algum problema for detectado,
será exibido um x ao lado do componente com problemas. Na coluna Message é disponibilizado
um link. Se você clicar neste link, é exibida uma mensagem indicando o que deve ser feito,
para solucionar o problema, que está impedindo a instalação do SQL Server 2005. Você deve
solucionar o problema, antes de prosseguir com a instalação. No nosso exemplo, nenhum
problema foi detectado e a instalação pode continuar, sem problemas.
9. Clique no botão Continue, para continuar com a instalação do SQL Server 2005.
10. O assistente de instalação faz uma série de preparações e exibe uma tela, para que você
coloque o seu nome, o nome da sua empresa e o número de série do SQL Server 2005. Digite
as informações solicitadas.
12. Nesta etapa você deve marcar quais os serviços que serão instalados. Ao instalar o SQL Server
2005, diversos serviços podem ser instalados. No final deste capítulo veremos um pouco mais
sobre os serviços que são instalados com o SQL Server e como gerenciar estes serviços. O SQL
Server é o serviço básico, o Banco de Dados em si. Você pode instalar outros serviços, tais como
o Analysis Services, Reporting Services e assim por diante. A dica aqui é instalar somente os
serviços que você irá realmente utilizar. Se você está instalando o SQL Server 2005 em um
servidor de produção, deve instalar somente os serviços que serão utilizados. Se você está
instalando o SQL Server 2005 em um servidor para estudo, deve instalar todos os serviços, para
tê-los disponíveis para estudar, quando necessário.
14. IMPORTANTE: Nesta etapa, indicada na Figura 2.23 é que vem o detalhe fundamental. É nesta
etapa que você irá informar que, ao invés de instalar uma nova instância do SQL Server 2005,
quer fazer o upgrade de uma instância já existente, do SQL Server 2000. Dê um clique no botão
Installed instances, em destaque na Figura 2.23.
15. Será exibida uma lista com as instâncias já instaladas. No nosso exemplo, indicado na Figura
2.24, temos um única instância do SQL Server 2000 instalada. Observe que a versão da instância
selecionada é 8.00.761, a qual indica o SQL Server 2000, com Service Pack 3.a instalado. Marque
a instância a qual será atualizada para o SQL Server 2005, conforme indicado na Figura 2.24 e
dê um clique em OK.
Figura 2.23 O botão Installed instances.
Figura 2.24 Selecionando a instância que será atualizada.
16. Você estará de volta ao assistente de instalação do SQL Server 2005. Clique em Next, para
seguir para a próxima etapa do assistente.
17. Será exibida uma janela, com a lista de componentes já instalados no computador e que serão
atualizados. Clique em Next, para seguir para a próxima etapa do assistente.
definir a mesma conta para todos os serviços, ou definir uma conta diferente, para cada um
dos serviços. Você pode optar por usar a conta local System (sendo esta a opção mais
recomendada), ou informar uma conta do domínio ou uma conta de administrador local, caso
o computador que você esteja utilizando não pertença a um domínio. Se você marcar a opção
Customize for each service account, a lista abaixo desta opção será habilitada. Feito isso, você
pode escolher um serviço na lista e definir a conta para o serviço selecionado. Depois você
seleciona um novo serviço na lista e define a conta para este novo serviço e assim por diante.
Com a opção Customize for each service account, você pode definir configurações
personalizadas, para cada um dos serviços. No nosso exemplo, vou usar a mesma conta para
todos os serviços (opção Customize for each service account desmarcada) e vou informar uma
conta de administrador local do computador, conforme exemplo da Figura 2.25 (pois o
computador que eu estou utilizando para este exemplo não está configurado para fazer parte
de um domínio baseado no Active Directory). Observe que como nome do domínio eu coloquei
o próprio nome do computador – MICROXP-01:
Figura 2.25 Definindo as configurações de conta.
19. Defina as configurações desejadas e clique em Next, para seguir para a próxima etapa do
autenticação. Nesta etapa, você também pode definir uma senha para a conta sa. A conta sa é
a conta de administrador do SQL Server 2005, ou seja, a conta com maiores “poderes” no SQL
Server 2005. Por isso sempre é recomendado definir uma senha forte para esta conta. Entenda-
se por senha forte uma senha que usa letras, números e caracteres especiais e que tenha, no
mínimo, 10 caracteres. Defina as configurações desejadas.
24. Será exibida a tela final do assistente, com um resumo de todas as opções selecionadas. Você
pode usar o botão Back para voltar a uma das etapas anteriores e alterar alguma configuração,
caso seja necessário. Para concluir a instalação, clique no botão Install e aguarde. Será exibida
uma janela, com o progresso da instalação/upgrade.
25. Uma vez concluída a instalação será habilitado o botão Next. Clique em Next, para exibir a tela
final do assistente. Será exibida a tela final do assistente, indicando que a instalação/upgrade
foi concluída com sucesso.
26. Clique em Finish para encerrar o assistente. Pronto, a instância do SQL Server 2000 foi atualizada
para o SQL Server 2005, no seu computador. Agora só precisamos aprender a utilizá-lo. Mas
isso é assunto para todo o restante deste livro.
No próximo tópico deste capítulo você aprenderá sobre MMC e Snap-in e sobre os serviços do SQL
Server 2005. No Capítulo 3 você aprenderá a utilizar o console de Administração do SQL Server 2005 –
SQL Server Management Studio.
FUNDAMENTOS EM: SERVIÇOS

DISPONÍVEIS COM O SQL SERVER 2005
PRÉ-REQUISITOS
♦ Ter instalado uma instância nomeada do SQL Server 2005.
METODOLOGIA
♦ Verificação dos serviços instalados e inicializados.
TÉCNICA
♦ Utilizar os consoles de administração do Windows e do SQL Server 2005, para o gerenciamento de serviços.
Conforme já foi descrito anteriormente, um serviço é um programa que fica residente na memória do
servidor. Um serviço é o responsável por atender às requisições dos clientes quando estes se conectam
com o Banco de Dados. Por exemplo, quando um usuário de uma aplicação faz uma pesquisa, através
da rede, no servidor SQL Server, é um serviço que recebe a solicitação do cliente, obtém os dados
solicitados e retorna o resultado para o cliente.
Como o SQL Server 2005 oferece uma série de funcionalidades, existem alguns serviços que estão
disponíveis com cada instância instalada do SQL Server. A seguir vamos descrever estes serviços.
O SERVIÇO “SQL SERVER”

Este é o principal serviço do SQL Server 2005. Ele é responsável pelas principais funções do Banco
de Dados. Se este serviço, por algum motivo, não tiver sido inicializado, os clientes não serão
capazes de se conectar com o servidor SQL Server. É como se não existisse o servidor SQL ou se este
estivesse fora da rede.
Durante a instalação das instâncias do SQL Server, será gerado um identificador para cada instância, o
qual é conhecido como Instance ID. Para cada componente do SQL Server é gerado um identificador,
separadamente. Os componentes são a máquina do Banco de Dados (Database Engine), o Analysis
Services e o Reporting Services. O identificador de instância está no formato MSSQL.n, é um número
inteiro, iniciando em 1. Este identificador de instância é utilizado para criar a estrutura de pastas onde
estão os arquivos da instância e também na Registry do Windows.
O primeiro identificador de instância gerado será MSSQL.1, o segundo será MSSQL.2 e assim por diante.
Podem ocorrer falhas na seqüência de numeração; no caso em que uma instância é instalada, outras
são instaladas após ela e depois ela é desinstalada. Quando uma nova instância for instalada, seguirá a
numeração, a partir do último identificador gerado, e não será preenchido o espaço, deixado pela
instância que foi desinstalada.
Os componentes e arquivos de uma instância serão instalados em uma estrutura de pastas, nomeada
como o mesmo identificador da instância. Por exemplo, a primeira instância do SQL Server 2005,
instalada como default, tendo sido instalado o SQL Server (database engine), o Analysis Services e o
Reporting Services, terá a seguinte estrutura de pastas:
♦ Arquivos de Programas>\Microsoft SQL Server\MSSQL.1\MSSQL\ para o Banco de Dados
♦ Arquivos de programas>\Microsoft SQL Server\MSSQL.2\OLAP\ para o Analysis Services
♦ Arquivos de programas>\Microsoft SQL Server\MSSQL.3\RS\ para o Reporting Services
♦ Para o Sistema Operacional, cada serviço, de cada instância, tem um nome específico.
Por exemplo, o serviço do Database Engine (a máquina de Banco de Dados, o SQL Server
propriamente dito), para a primeira instância, terá o nome MSSQL.1. Observe que é
utilizado o identificador da instância – Instance ID. Caso tenhamos mais do que uma
instância instalada, cada uma delas terá o seu próprio serviço SQL Server, o qual é nomeado
de acordo com o ID da respectiva instância. Observe que o uso de identificadores de
instância (Instance ID) é uma maneira de criar atalhos, para fazer referência a cada serviço,
de cada uma das instâncias.
Por exemplo, suponha que tenhamos duas instâncias do SQL Server 2005 instaladas; teremos dois
serviços SQL Server carregados na memória. Estes serviços, para o Windows 2000, serão identificados
pelos seguintes nomes:
♦ MSSQL.1
♦ MSSQL.2
Nós podemos, facilmente, verificar se existem duas instâncias deste serviço carregadas na memória.
Para isso, faça o seguinte:
1. Pressione Ctrl+Alt+Del para abrir a janela Segurança no Windows.
2. Dê um clique no botão Gerenciador de Tarefas, para abrir o gerenciador de tarefas do Windows.
3. Na janela que surge, dê um clique na guia Processos. Depois dê um clique no botão com o
nome da coluna “Nome da imagem”, para classificar os processos carregados pelo nome.
4. Vá rolando com a barra de rolagem vertical, até encontrar um processo chamado sqlservr.exe,
conforme indicado na Figura 2.26.
Observe que temos dois processos sqlservr.exe carregados na memória. Cada um deles é responsável
pelo serviço SQL Server de cada uma das respectivas instâncias do SQL Server 2005 instaladas.
Figura 2.26 Processos para as instâncias do SQL Server.
5. Feche o gerenciador de tarefas.
O SERVIÇO “SQL SERVER AGENT”

Este serviço é responsável pelo agendamento de tarefas para execução em períodos programados, emissão
de alertas com base em determinadas condições, notificações e planos de manutenção de Banco de
Dados. Este serviço é dependente do serviço SQL Server, ou seja, se o serviço SQL Server (Database
engine) não tiver sido inicializado com sucesso, não será possível inicializar o serviço SQL Server Agent.
A exemplo do serviço SQL Server, existe uma instância do SQL Server Agent para cada uma das respectivas
instâncias do SQL Server 2005 instaladas. O nome do serviço também é ligado ao identificador de
instância, conforme descrito anteriormente.
Na Figura 2.27, podemos ver, no gerenciador de tarefas, os dois processos responsáveis por estas duas
instâncias do serviço SQL Server Agent.
Voltaremos a falar do serviço SQL Server Agent quando falarmos do agendamento de tarefas, no
Capítulo 5.
Figura 2.27 Processos para as instâncias do SQL Server Agent.
O SERVIÇO MICROSOFT DISTRIBUTED

TRANSACTION COORDINATOR – MSDTC
Este serviço é um coordenador de transações, o qual permite que dados das mais diferentes fontes,
desde o mainframe até uma planilha do Excel, sejam acessados em uma aplicação desenvolvida para o
SQL Server. Tais tipos de aplicações podem ser desenvolvidas em diversas linguagens, como por exemplo
o Visual Basic, Delphi, Power Builder, C#, ASP.NET, etc. Este serviço garante a consistência em todas as
fontes de dados. Por exemplo, se você está acessando dados do mainframe e de um planilha Excel, está
fazendo cálculos que alteram dados em ambas as fontes e salvam os resultados em um Banco de Dados
Oracle. O serviço MSDTC garante que todas as operações ocorrerão com sucesso, no contexto de uma
transação, ou que os dados serão retornados ao seu estado original antes do início da transação, caso
uma única das operações da transação apresente falha. Ou seja, é o famoso “tudo ou nada”.
Diferente dos serviços SQL Server e SQL Server Agent, existe somente uma instância do serviço MSDTC,
independente de quantas instâncias do SQL Server 2005 estejam instaladas no servidor. Isto faz sentido,
pois o papel do MSDTC é justamente facilitar o acesso a várias fontes de dados, incluindo Bancos de
Dados, de diferentes instâncias do SQL Server 2005.
O SERVIÇO MICROSOFT SEARCH

Quando fazemos uma instalação personalizada (Custom), podemos optar por não instalar o serviço
Microsoft Search. Este serviço somente deve ser instalado se realmente for utilizado, pois caso contrário
estará consumindo recursos no servidor, tais como memória RAM e processador. O serviço Microsoft
Search oferece a possibilidade de pesquisas avançadas para o idioma Inglês.
Diferente dos serviços SQL Server e SQL Server Agent, existe somente uma instância do serviço Microsoft
Search, independente de quantas instâncias do SQL Server 2005 estejam instaladas no servidor. O
nome do serviço é msftesql$SQL2005.
O SERVIÇO MICROSOFT REPORT SERVICES

Este é o serviço responsável pelas funcionalidades do Reporting Services. Ele fornece uma interface de
fácil utilização para a criação e, principalmente, para a publicação e distribuição de relatórios.
Abordaremos o Reporting Services no Capítulo 14.
O SERVIÇO ANALYSIS SERVICES

O Microsoft SQL Server 2005 Analysis Services fornece funcionalidades para o processamento analítico
online, as chamadas consultas OLAP, baseadas em cubos de dados. Também fornece uma série de
funcionalidades para o desenvolvimento de aplicações de data mining e business intelligence. A idéia
básica do Analysis Services é facilitar a criação de estruturas multidimensionais de dados, conhecidas
como cubos de dados. Os dados de um cubo podem ser obtidos a partir de fontes diversas, tais como
Bancos de Dados do SQL Server, planilhas do Excel, dados do mainframe e outras fontes relacionais e
não relacionais de dados.
Agora que já conhecemos os serviços disponíveis, vamos aprender a gerenciá-los, utilizando duas
ferramentas: o Computer Management (console que é instalado juntamente com o SQL Server 2005) e
o Snap-in Services (o qual faz parte do Windows).
FUNDAMENTOS EM: GERENCIAMENTO DOS

SERVIÇOS DO SQL SERVER 2005
PRÉ-REQUISITOS
♦ Ter instalado duas instâncias do SQL Server 2005.
METODOLOGIA
♦ Gerenciamento dos serviços de cada instância do SQL Server 2005.
TÉCNICA
♦ Utilizar o gerenciador de tarefas do Windows 2000 e o console Computer Management, do SQL Server 2005.
Nós podemos configurar um determinado serviço para que ele seja inicializado, automaticamente,
quando o Windows é iniciado (Windows 2000, Windows Server 2003 ou Windows XP). Para serviços
fundamentais, como o serviço SQL Server (database engine), o qual deve estar sempre disponível, a
opção de inicializar automaticamente é a mais indicada (mais do que a mais indicada, é fundamental).
Porém para serviços que somente serão utilizados eventualmente, o ideal é que o serviço não seja
inicializado automaticamente, mas somente quando o serviço for necessário, para evitar que o serviço
consuma recursos de hardware desnecessariamente. Um serviço que não é inicializado automaticamente
pode ser inicializado a qualquer momento, utilizando as ferramentas que apresentarei nesta seção.
Antes de continuarmos, vamos fazer um parênteses para falar de MMC – Microsoft Management Con-
sole – e Snap-ins (vamos optar por não traduzir, uma vez que o termo já é consagrado), pois a principal
ferramenta de administração do SQL Server 2005, o SQL Server Management Studio, é uma ferramenta
baseada nos conceitos de MMC e Snap-ins.
UM PEQUENO PARÊNTESES PARA

APRENDER SOBRE MMC E SNAP-INS
O conceito de MMC foi criado, ainda na época do NT Server 4.0 e do SQL Server 7.0, para servir como
uma interface unificada para a administração e gerenciamento dos mais variados recursos do Win-
dows e dos demais produtos da Microsoft, tais como o SQL Server, SMS Server, Exchange Server, IIS,
etc. Em versões anteriores à criação do MMC, os produtos da Microsoft, cada tarefa possuía um aplicativo
com uma interface diferente. Por exemplo, no Windows NT Server 4.0, a interface do User Manager for
Domains (o qual é utilizado para criar contas e grupos) era completamente diferente da interface de
outras ferramentas administrativas, tais como o Disk Manager (utilizado para gerenciar os discos rígidos
e partições). Com isso o administrador precisava aprender a utilizar uma série de interfaces diferentes,
uma para cada categoria de tarefas a ser executada.
O MMC se propõe a resolver esse problema, fornecendo uma interface muito semelhante para todas as
tarefas administrativas. O MMC vem sendo utilizado em programas como o Internet Information
Server desde a versão 4.0 (Servidor Web da Microsoft), Proxy Server 2.0 (Firewall para proteção da rede
interna), Microsoft SQL Server desde a versão 7.0, dentre outros programas da Microsoft.
Na verdade, o MMC sozinho não oferece nenhuma funcionalidade. O MMC fornece uma maneira
padronizada para a criação de ferramentas administrativas. Toda a funcionalidade do MMC é fornecida
por aplicações de gerenciamento e administração chamadas snap-ins. O MMC funciona simplesmente
como um “hospedeiro” para os diversos snap-ins disponíveis. Em outras palavras, o MMC é utilizado
para abrir um snap-in, sendo o snap-in o responsável por fornecer as funcionalidades de administração
dos mais diversos produtos e serviços da Microsoft.
Você pode utilizar o MMC para uma série de atividades, tais como:
♦ Realizar a maioria das tarefas administrativas do dia-a-dia.
♦ Fazer o gerenciamento e a administração de uma maneira centralizada.
♦ Fazer administração e gerenciamento remoto, desde que possua as devidas permissões para isso.
Por exemplo, quando abrimos a ferramenta para administrar contas de usuários e grupos do Windows
2000 Server, por exemplo, na verdade estamos abrindo o MMC e carregando o snap-in especialmente
projetado para realizar as tarefas administrativas relativas à administração de usuários e grupos. Podemos
ter um ou mais snap-ins carregados no MMC, de tal forma que em uma mesma janela podemos realizar
as mais variadas tarefas administrativas. O melhor exemplo disso é o snap-in Gerenciamento do
Computador (Iniciar -> Programas -> Ferramentas administrativas -> Gerenciamento do computador).
Utilizaremos este snap-in mais adiante.
Exemplo 1: Vamos abrir o MMC sem nenhum snap-in carregado. Conforme este exercício mostrará o
MMC em si não oferece funcionalidade nenhuma, a qual é fornecida pelos snap-ins carregados.
Para abrir o MMC sem nenhum snap-in carregado, siga os passos indicados a seguir:
1. Dê um clique no botão Iniciar.
2. Clique na opção Executar.
3. Na janela que surge, no campo Abrir, digite mmc e dê um clique em OK.
4. Será aberta uma janela conforme indicado na Figura 2.28. Esta janela mostra o MMC sem
nenhum snap-in carregado.
Figura 2.28 MMC sem nenhum snap-in carregado.
Agora vamos abrir o MMC com alguns snap-ins já carregados. Vamos também dar uma analisada na
interface do mesmo.
Feche o MMC aberto anteriormente.
Para abrir o MMC para gerenciamento do computador:
1. Dê um clique no botão Iniciar, aponte para Programas e dentro de Programas para Ferramentas
administrativas.
2. No menu de opções que surge dê um clique em Gerenciamento do computador.
Caso não estejam aparecendo todas as opções, dê um clique na opção que é uma “flechinha” dupla para
baixo. Com isso o Windows 2000 Server exibe todas as opções do menu, inclusive as menos utilizadas.
3. Irá surgir a janela indicada na Figura 2.29. Observe que temos diversos snap-in carregados.
Nesta janela você pode administrar Armazenamento, Pastas Compartilhadas, Analisar os logs
do sistema, etc.
Figura 2.29 MMC com vários snap-ins carregados.
A maneira de utilizarmos um snap-in e navegar pelas opções disponíveis é exatamente igual à utilizada
no Windows Explorer. Vamos navegando através do painel da esquerda e, quando um elemento do
painel da esquerda é selecionado, o seu conteúdo é exibido no painel da direita. Você verá que esta é
exatamente a maneira de navegar através do SQL Server Management Studio, o qual é o principal
console de administração do SQL Server 2005 (você aprenderá a utilizá-lo no Capítulo 3).
Além disso os menus e botões da barra de ferramentas vão se modificando, dependendo do elemento
selecionado. Isso porque as ações que podemos realizar, por exemplo, sobre um usuário são diferentes
das ações que podemos realizar sobre um disco rígido. Essa mudança nos menus e na barra de ferramentas
serve para refletir quais ações são possíveis sobre o elemento selecionado.
4. Para abrir a pasta Grupos, dê um clique no sinal de + ao lado da opção “Usuários e grupos
locais”. Esta opção se abre mostrando duas opções ligadas a ela: Usuários e Grupos. Se o seu
servidor for um Controlador de domínio, a opção Usuários e grupos locais estará desabilitada,
o que é indicado por um “x” vermelho.
5. Para ver uma listagem dos grupos em seu computador, dê um clique em Grupos. No painel da
direita será exibida uma listagem com os grupos disponíveis.
Você também pode utilizar o botão direito do mouse. Por exemplo, se você clicar com o botão direito
sobre a opção Usuários, surge um menu cuja primeira opção é “Novo usuário”. Esta opção pode ser
utilizada para cadastrar um novo usuário.
NOTA
Dependendo de o computador ser um Controlador de Domínio ou um Member Server, esta interface pode apresentar algumas diferenças.
6. Feche o MMC para gerenciamento do computador.
Um MMC com um ou mais snap-ins carregados é chamado de um Console MMC. Quando instalamos
o Windows 2000 Server ou o Windows Server 2003, já são adicionados diversos Consoles MMC pré-
configurados para que possamos executar as tarefas administrativas mais comuns. Estes consoles podem
ser acessados através do menu Ferramentas administrativas. O SQL Server 2005 nos fornece o console
SQL Server Management Studio, o qual iremos utilizar ao longo deste livro.
Também podemos criar nossos próprios consoles pré-configurados, os quais podem ser salvos em
arquivos com a extensão .MSC. Depois para abrirmos um console pré-configurado basta abrirmos o
arquivo com a extensão .MSC, utilizando para isso o MMC.
Vamos a mais um exemplo prático.
Suponhamos que você queira um console somente para administrar contas de usuários e grupos do
Windows, sem todas as demais opções do console pré-configurado Gerenciamento do computador.
Vamos abrir o MMC sem nenhum snap-in e carregar apenas o snap-in para administração de contas de
usuários e grupos. Depois vamos salvar este console com o nome de administra_usuarios.msc. Por
último vamos verificar que o Windows 2000 Server já cria um atalho automaticamente para o novo
console criado, no menu Ferramentas administrativas.
Para abrir o MMC sem nenhum snap-in carregado:
1. Dê um clique no botão Iniciar.
2. Clique na opção Executar.
3. Na janela que surge, no campo Abrir digite mmc e dê um clique em OK.
4. Será aberta uma janela sem nenhum snap-in carregado.
Para carregar apenas o snap-in para administração de contas de usuários e grupos:
1. Com o MMC, aberto no exercício anterior, dê um clique no menu Console e escolha a opção
Adicionar/remover snap-in. Será exibida a janela indicada na Figura 2.30.
2. Dê um clique no botão Adicionar.
3. Será exibida a janela Adicionar snap-in autônomo, na qual é exibida uma listagem com
todos os snap-ins disponíveis, no computador que você está utilizando. Localize na listagem
o seguinte snap-in: Usuários e grupos locais. Dê um clique sobre ele para selecioná-lo e clique
no botão Adicionar.
Figura 2.30 Clique no botão Adicionar para adicionar um snap-in.

NOTA
Caso você esteja em um controlador de domínio, escolha o snap-in “Usuários e computadores do Active Directory”. Para maiores informações
sobre contas de usuários e grupos e Active Directory, consulte o livro Windows Server 2003 – Curso Completo, 156 páginas, de minha
autoria, publicado pela editora Axcel Books (www.axcel.com.br).
4. Surge a janela Escolher máquina de destino. Essa janela permite que você defina em qual
computador você quer gerenciar as contas de usuários e grupos. Neste momento você pode
gerenciar usuários e grupos de um computador remoto, através da rede, desde que você tenha
permissão para isso. Por padrão vem selecionado o computador Local. Vamos aceitar a
configuração padrão. Dê um clique no botão Concluir.
5. Você estará de volta à janela Adicionar snap-in autônomo. Como não queremos adicionar
mais nenhum snap-in, dê um clique no botão Fechar.
6. Você estará de volta à janela Adicionar/remover snap-in. Observe que o snap-in Usuários e
grupos locais (local) já aparece na listagem, conforme indicado na Figura 2.31. Dê um clique
em OK para fechar a janela Adicionar/remover snap-in.
Figura 2.31 Snap-in Usuários e grupos locais já adicionado.

NOTA
O local entre parênteses indica o computador local.
Você estará de volta ao MMC, agora com o snap-in Usuários e grupos locais já carregado.
Para salvar o console com o nome de administra_usuarios.msc:
1. Dê um clique no menu Console e escolha a opção Salvar.
2. Na janela Salvar como, no campo Nome do arquivo, digite administra_usuarios.msc.
3. Dê um clique no botão Salvar.
4. Feche o MMC.
Para verificar se o Windows criou um atalho para o novo console criado:
1. Dê um clique no botão Iniciar, aponte para Programas e dentro de Programas para Ferramentas
administrativas.
2. No menu de opções que surge verifique se foi adicionada uma opção chamada
administra_usuarios.msc.
3. Essa opção é um atalho para o console recém-criado, o qual possui apenas o snap-in Usuários
e grupos locais, carregado.
4. Se você clicar nesta opção, será aberto o console anteriormente criado.
Existem muitas aplicações práticas para a criação de consoles personalizados. Por exemplo, caso um
funcionário seja responsável apenas pelo gerenciamento de usuários e grupos, você pode criar um
console personalizado somente com o snap-in necessário. Isso facilita o trabalho, uma vez que a inter-
face fica mais simples e impede o acesso a operações que não fazem parte das atribuições do funcionário.
Agora vamos encerrar o nosso pequeno parênteses sobre MMC e snap-in e voltar ao gerenciamento de
serviços do SQL Server 2005. Vamos aprender a utilizar o Snap-in Serviços e o aplicativo SQL Com-
puter Manager, o qual é instalado com o SQL Server 2005.
UTILIZANDO O SNAP-IN SERVICE MANAGER – O CONSOLE SERVIÇOS

Qualquer serviço disponível, e não somente os serviços do SQL Server 2005, pode ser gerenciado pelo Snap-
in Service Manager. Através deste snap-in podemos efetuar diversas configurações, como por exemplo:
♦ Configurar um serviço para que seja inicializado automaticamente.
♦ Parar um serviço.
♦ Inicializar um serviço.
♦ Configurar qual a conta que será utilizada para inicializar o serviço.
♦ Configurar o comportamento do serviço em caso de falha. Por exemplo, podemos pedir para
que o serviço seja reinicializado em caso de falha.
Vamos aprender a utilizar o snap-in Serviços através de um exemplo prático. Vamos abri-lo e verificar
as opções de configuração disponíveis para o serviço SQLServer (CURSOSJB), que conforme foi visto
anteriormente é o serviço SQL Server para a instância CURSOSJB, no servidor SERVIDOR2.
Para verificar as opções de configuração do serviço SQLServer (CURSOSJB), siga os passos indicados a seguir:
1. Faça o logon no Servidor onde está instalada a instância a ser gerenciada, usando uma conta
com perfil de administrador.
2. Abra o Snap-in Serviços: Iniciar -> Programas -> Ferramentas administrativas -> Serviços. Surge
a janela indicada na Figura 2.32.
3. Na listagem de serviços, a qual por padrão está ordenada ascendentemente pelo nome do
serviço, localize o serviço chamado SQLServer (CURSOSJB).
Observe que, ao lado do nome do serviço, temos mais colunas de informação. Estas colunas informam
se o serviço está carregado na memória (Iniciado); o tipo de inicialização indica se o serviço é carregado
automaticamente ou não, quando o Windows é inicializado e assim por diante.
4. Dê um clique com o botão direito do mouse sobre o nome do serviço.
No menu que surge temos diversas opções, conforme descrito a seguir:
♦ Iniciar: Esta opção carrega o serviço na memória. Se o serviço já estiver carregado, esta opção
estará desabilitada.
Figura 2.32 O console para gerenciamento de serviços.
♦ Parar: Esta opção pára o serviço, descarregando-o da memória. Os usuários não poderão mais
se conectar com o servidor SQL enquanto o serviço não for reinicializado. Os usuários que
estiverem conectados serão desconectados.
♦ Pausar: Esta opção faz com que o servidor SQL Server não aceite novas conexões, porém os
usuários que estão atualmente conectados continuam podendo acessar os recursos do servidor
SQL Server.
♦ Continuar: Faz com que o servidor SQL Server volte a aceitar novas conexões. Esta opção está
desabilitada se o serviço não estiver em pausa.
♦ Reiniciar: Descarrega o serviço da memória e o carrega novamente. Esta opção pode ser utilizada
quando o servidor começar a apresentar algum comportamento estranho, sem justificativa
aparente. Nestas situações reinicializar o servidor pode ser a melhor opção.
5. Dê um clique duplo no nome do serviço. Será aberta a janela “Propriedades SQLServer

(CURSOSJB).”, a qual apresenta quatro guias de opções.
Na guia Geral, conforme indicado na Figura 2.33, é exibido o nome do serviço, e temos a opção de
inserir uma descrição para o serviço. Na lista Tipo de inicialização, podemos escolher se o serviço deve
ser inicializado automaticamente, manualmente ou se deve ser desativado. Há ainda botões para Iniciar,
Parar, Pausar e Continuar o serviço. Também temos um campo para passar um parâmetro de inicialização,
caso o serviço em questão exija algum.
Figura 2.33 A guia Geral das propriedades do serviço.
Figura 2.34 A guia Logon das propriedades do serviço.
Na guia Logon, conforme indicado na Figura 2.34, podemos definir qual a conta que será utilizada
para inicializar o serviço. Caso tenhamos mais do que um perfil de hardware, podemos habilitar ou
desabilitar o serviço, nos diferentes perfis existentes. Vamos supor que você tenha criado um perfil de
hardware chamado manutenção. Quando você inicializa o servidor e seleciona este perfil de hardware,
pode ser interessante que o servidor tenha todos os serviços não necessários à manutenção desabilitados
para que sejam liberados recursos como memória e processador para as tarefas de manutenção.
Na guia Recuperação, conforme indicado na Figura 2.35, podemos definir qual deve ser o
comportamento do serviço no caso de uma falha. Estas opções são uma das novidades do Windows
2000 e do Windows Server 2003 em relação ao Windows NT Server 4.0. Podemos definir diferentes
ações para a primeira falha do serviço, para a segunda falha do serviço e para as falhas posteriores,
dentro de um período de tempo definido no campo “Zerar a contagem de falhas após x dias”. As ações
possíveis são: Não executar nenhuma ação, Reiniciar o serviço, Executar um arquivo ou Reiniciar o
computador. Por exemplo, podemos escolher Reiniciar o serviço para a primeira falha; Executar um
arquivo, para executar um programa que avisa o Administrador via e-mail e reinicializa o serviço para
a segunda falha; e Reiniciar o computador para uma falha posterior. As opções Executar arquivo e
Parâmetros de linha de comando somente serão habilitadas quando escolhermos executar um arquivo
como ação para uma das falhas – primeira, segunda ou posterior.
Figura 2.35 A guia Recuperação das propriedades do serviço.
Na guia Dependências, conforme indicado na Figura 2.36, temos informações de quais Serviços o
serviço em questão depende, e quais Serviços dependem do serviço em questão. Conforme a Figura
2.36, o serviço SQL Server Agent depende do serviço SQL Server. Isto significa que, se o serviço SQL
Server não estiver inicializado, o serviço SQL Server Agent não poderá ser inicializado. O Windows
utiliza estas informações para determinar a ordem correta de inicialização dos serviços ao inicializar o
sistema operacional.
6. Clique em Cancelar para fechar a janela com as propriedades do serviço SQLServer

(CURSOSJB).”,.
Figura 2.36 A guia Dependências das propriedades do serviço.
7. Feche o console Serviços.
Muitas vezes uma determinada funcionalidade do Windows ou do SQL Server não está funcionando corretamente. Um dos locais que
NOTA
devemos verificar é no console Serviços, para nos certificar de que todos os serviços necessários foram devidamente inicializados.
As opções vistas neste exemplo estão disponíveis para todos os serviços e não apenas para os serviços do SQL Server 2005.
UTILIZANDO O CONSOLE SQL COMPUTER MANAGER,

QUE VEM COM O SQL SERVER 2005
Ao instalarmos o SQL Server 2005 é instalado um console chamado SQL Computer Manager, o qual
pode ser acessado utilizando o seguinte comando: Iniciar -> Programas -> Microsoft SQL Server 2005 ->
SQL Computer Manager. Este console é um utilitário que nos permite gerenciar os serviços do SQL Server
de uma maneira bastante simples, pois apresenta somente os serviços do SQL Server 2005 e não todos os
demais serviços, instalados no computador.
Utilizando o SQL Computer Manager podemos realizar as seguintes ações com os serviços do SQL
Server 2005:
♦ Inicializar um serviço.
♦ Continuar o serviço, caso ele tenha sido colocado em Pausa.
♦ Colocar o serviço em Pausa.
♦ Configurar o serviço para inicializar automaticamente quando o sistema operacional é

inicializado.
Na Figura 2.37, vemos a tela inicial do SQL Computer Manager, o qual é aberto usando o comando
Iniciar -> Programas -> SQL Server 2005 -> SQL Computer Manager.
Figura 2.37 SQL Computer Manager.
Se a opção Serviços e aplicativos não estiver aberta, clique no sinal de +, ao lado desta opção, para abri-
la. Serão exibidas várias opções, dentre as quais a opção SQL Computer Manager. É através desta opção
que temos acesso a todos os serviços do SQL Server 2005, instalados no computador. Clique no sinal de
+ opção SQL Computer Manager. Abaixo da opção SQL Computer Manager, dê um clique no sinal de
+ ao lado da opção Services. Será exibida uma lista de todos os serviços do SQL Server 2005, instalados
no computador, conforme indicado na Figura 2.38.
Clique em um dos serviços. Por exemplo, clique no serviço SQL Server, que é a máquina do Banco de
Dados do SQL Server 2005. No painel da direita, serão exibidas todas as instâncias do SQL Server 2005,
instaladas, conforme indicado na Figura 2.39.
No painel da direita, você pode clicar com o botão direito do mouse, no serviço a ser gerenciado. Será
exibido um menu com opções para inicializar, parar, pausar e para acessar as propriedades do serviço.
A idéia básica do SQL Computer Manager é servir de um ponto central para gerenciamento dos serviços
do SQL Server 2005. No SQL Computer Manager são listados apenas os serviços do SQL Server 2005 e
não todos os serviços disponíveis no computador.
Figura 2.38 Lista de serviços do SQL Server 2005.
Figura 2.39 Instâncias do SQL Server 2005 instaladas.
CONCLUSÃO
Iniciamos o capítulo com uma introdução a uma série de conceitos importantes como comércio
eletrônico, CRM, transações, etc. Na seqüência, aprendemos sobre arquitetura de aplicações,
desde a tradicional arquitetura Cliente/Servidor com seus problemas, até modernas aplicações
de três ou mais camadas.
Foram apresentados os principais problemas com a arquitetura de duas camadas, principalmente quanto
a dificuldade de manutenção e ao elevado TCO deste modelo. Apresentamos as soluções propostas
pelos modelos de três ou mais camadas, sendo que as principais são as seguintes:
♦ Facilidade de instalação e manutenção das aplicações.
♦ Facilidade na atualização de versões.
♦ Redução do TCO.
Entender as vantagens e desvantagens de cada uma das arquiteturas é muito importante para que
possamos desenvolver as soluções mais adequadas a cada situação.
É importante sempre lembrarmos o papel de um Banco de Dados como o SQL Server 2005 no
desenvolvimento de aplicações. O SQL Server 2005 não é a ferramenta que será utilizada para o
desenvolvimento da aplicação como um todo. Para o desenvolvimento/codificação de uma aplicação
utilizamos ferramentas como o Visual Basic, Delphi, Visual C++, Visual Interdev, Borland C++, Power
Builder, etc. Além das ferramentas de desenvolvimento, utilizada uma série de outras ferramentas que
dão apoio ao processo de desenvolvimento de aplicações.
O SQL Server 2005 oferece várias funcionalidades sempre ligadas ao Banco de Dados da aplicação,
como por exemplo:
♦ Armazenamento das tabelas de dados.
♦ Pesquisa nos dados com a utilização da linguagem T-SQL.
♦ Suporte a transações.
♦ Níveis de segurança e auditoria no acesso aos dados.
♦ Suporte a replicação de dados entre servidores.
♦ Rotinas de backup e restore.
Uma vez que estamos utilizando diversas funcionalidades oferecidas pelo próprio Banco de Dados,
não precisamos codificar estas funcionalidades dentro da nossa aplicação. Isto facilita e simplifica o
processo de desenvolvimento das aplicações.
Você também aprendeu sobre as principais novidades e melhoramentos do SQL Server 2005, em relação
às versões anteriores. Também mostrei onde encontrar, no Books Online, referência completa de todas
as novidades do SQL Server 2005.
Seguindo no capítulo, aprendemos a fazer a instalação do SQL Server 2005. Também aprendemos a
criar múltiplas instâncias do SQL Server em um mesmo servidor. Fizemos, passo a passo a instalação de
uma instância padrão, a instalação de uma segunda instância e um upgrade de uma instância do SQL
Server 2000 para o SQL Server 2005.
Após instalado o SQL Server, aprendemos a gerenciar os serviços que compõem o SQL Server e a
utilizar o console Serviços e o SQL Computer Manager, que vem junto com o SQL Server 2005.
Também fizemos um pequeno parênteses para apresentar os conceitos de MMC e Snap-in. Apresentamos
alguns exemplos de utilização do MMC, bem como da criação de consoles personalizados.
SQL Server 2005 instalado e os respectivos serviços corretamente inicializados, agora é hora de
começarmos a utilizar o Banco de Dados. Mas isto é assunto para o próximo capítulo.
Por enquanto se você quiser estudar um pouco mais sobre o SQL Server 2005, pode consultar um dos
seguintes endereços:
♦ www.microsoft.com/sql
♦ www.swyink.com
♦ www.sqlmag.com
CAPÍTULO 3 – TRABALHANDO COM BANCO DE DADOS NO MICROSOFT SQL SERVER 2005
Capítulo 3
TRABALHANDO COM BANCO DE DADOS
NO MICROSOFT SQL SERVER 2005
INTRODUÇÃO
Já aprendemos os conceitos básicos sobre Bancos de Dados Relacionais no Capítulo 1. Também
aprendemos a instalar e gerenciar os serviços do SQL Server 2005 no Capítulo 2. Agora vamos começar
a trabalhar com o SQL Server 2005.
Neste capítulo aprenderemos um pouco mais sobre as ferramentas de administração que são
disponibilizadas com o SQL Server 2005. Neste capítulo, trabalharemos com a seguinte ferramenta:
♦ SQL Server Management Studio
Também aprenderemos a configurar alguns parâmetros importantes, os quais afetam cada instância do
SQL Server 2005, separadamente. Por exemplo, podemos limitar a quantidade de memória RAM disponível
para cada instância ou podemos deixar que o próprio SQL Server gerencie a quantidade de memória a ser
utilizada. Também podemos definir, para o caso de servidores multiprocessados, se todos os processadores
podem ser utilizados ou se serão alocados processadores separados para cada instância, etc.
Depois daremos uma passeada pelo SQL Server Management Studio, mostrando as principais opções
de configuração disponíveis e quais as tarefas que podem ser realizadas. Conforme veremos, o SQL
Server Management Studio nada mais é do que um snap-in de administração para o SQL Server 2005.
O SQL Server Management Studio é o substituto do Enterprise Manager, o qual era o principal console
de administração do SQL Server 2000.
Ainda utilizando o SQL Server Management Studio veremos quais os Bancos de Dados que são criados,
automaticamente, quando da instalação do SQL Server 2005. Veremos qual a função de cada um dos
Bancos de Dados criados na instalação. Também mostrarei como instalar os Bancos de Dados de
exemplos, os quais não são instalados por padrão, quando da instalação do SQL Server 2005.
Em seguida apresentaremos algumas sugestões para a otimização dos Bancos de Dados em relação ao
armazenamento em disco. Veremos os conceitos de RAID-0, RAID-1 e RAID-5. A utilização de arranjos do
tipo RAID fornece tolerância a falhas e também maior desempenho do Banco de Dados. Veremos algumas
configurações que podem nos ajudar a obter um melhor desempenho na utilização dos discos.
Na seqüência veremos qual a estrutura de um Banco de Dados no SQL Server 2005. Veremos quais os
arquivos que são criados para um Banco de Dados e para os logs de transação do Banco de Dados, e
aprenderemos a identificar cada tipo de arquivo pela sua extensão.
Uma vez entendida a estrutura física do Banco de Dados, vamos partir para a criação de um Banco de
Dados, através de um exemplo prático, passo a passo. Na verdade, criaremos dois Bancos de Dados de
exemplo: um utilizando o SQL Server Management Studio e outro utilizando comandos T-SQL para a
criação de Banco de Dados. Após criados os Bancos de Dados, vamos conferir se os arquivos referentes
a cada um dos Bancos de Dados foram realmente criados.
Encerrado este capítulo, o amigo leitor deverá estar habilitado para as seguintes tarefas:
♦ Acessar as diversas instâncias do SQL Server, utilizando o SQL Server Management Studio e
utilizando comandos T-SQL.
♦ Configurar as principais opções para cada uma das instâncias instaladas.
♦ Entender a estrutura de armazenamento em disco de um Banco de Dados do SQL Server 2005.
♦ Criar Bancos de Dados utilizando o SQL Server Management Studio e comandos T-SQL.
♦ Conhecer os arranjos de RAID-0, RAID-1 e RAID-5, sabendo qual oferece tolerância a falhas e como
cada um se comporta em relação ao desempenho das operações de leitura e escrita no arranjo.
FUNDAMENTOS EM: UTILIZAÇÃO DO SQL SERVER MANAGEMENT STUDIO

PRÉ-REQUISITOS
♦ Noções básicas do Windows e dos MMC – Microsoft Management Console.
METODOLOGIA
♦ Apresentação dos elementos principais do SQL Server Management Studio.
No SQL Server 2000, a principal ferramenta de administração era o Enterprise Manager. A principal
ferramenta de administração do SQL Server 2005 é o console SQL Server Management Studio, o qual
pode ser acessado utilizando-se o seguinte caminho: Iniciar -> Programas -> Microsoft SQL Server 2005
-> SQL Server Management Studio. Este console nos dá acesso à maioria das tarefas necessárias à criação
e manutenção de um Banco de Dados no SQL Server 2005 (na verdade é difícil imaginar uma tarefa
que não seja possível fazer usando o SQL Server Management Studio).
Vamos, através de exemplos práticos, aprender a utilizar algumas das funcionalidades do SQL Server
Management Studio. Ao longo deste livro, voltarei diversas vezes ao SQL Server Management Studio
para executar as tarefas propostas, tais como criação de Banco de Dados, criação e alteração de tabelas,
criação e alteração de views, criação e alteração de usuários e grupos de usuários, configurações de
segurança, configurações de replicação, etc.
Exemplo: Abrindo e navegando pelas opções do SQL Server Management Studio:
1. Faça o logon com uma conta com permissão de administrador e abra o SQL Server Management
Studio: Iniciar -> Programas -> Microsoft SQL Server 2005 -> SQL Server Management Studio.
Será aberta a tela inicial do SQL Server Management Studio, indicada na Figura 3.1.
Nesta tela você informa o tipo de servidor com o qual deseja se conectar. Por padrão é selecionada a
opção SQL Server. Também estão disponíveis as opções Analysis Server, Report Server, SQL Mobile e
DTS Server. Observe que é possível usar o SQL Server Management Studio para administrar todos os
serviços do SQL Server 2005. Na lista Server name, você seleciona o nome do servidor com o qual você
deseja se conectar. Nesta lista, você pode selecionar a opção <Browse for more>, para abrir a janela
Browse for servers. Através desta janela, você pode se conectar com qualquer servidor SQL da rede (ou
de outros tipos, tais como o Analysis Server ou Report Server). Observem que é possível usar o console
SQL Server Management Studio, para administrar, remotamente, qualquer servidor SQL Server da rede,
para o qual você tenha as devidas permissões. Na lista Authentication, você seleciona o tipo de
autenticação. No Capítulo 6 você aprenderá mais sobre os tipos de autenticação disponíveis no SQL
Server 2005. No Exemplo da Figura 3.2, escolhi me conectar a um servidor SQL Server, com a instância
SERVIDOR\SQL2005, usando autenticação integrada com o Windows.
Figura 3.1 A tela inicial do SQL Server Management Studio.
Figura 3.2 Conectando com o servidor SERVIDOR\SQL2005.
Selecione as opções desejadas e clique em Connect. Após alguns instantes será feita a conexão com o
servidor selecionado e será apresentado o ambiente de administração fornecido pelo SQL Server Man-
agement Studio, conforme indicado na Figura 3.3.
Figura 3.3 Ambiente de administração do SQL Server Management Studio.
É uma janela tradicional de um console MMC, com menus e dividida em painéis, bem no estilo do
Windows Explorer. Na esquerda, tem uma janela com os servidores SQL Server já registrados, com os
quais você já fez uma conexão. Esta parte do console está indicada na Figura 3.4, onde temos um único
servidor registrado: SERVIDOR\SQL2005
Figura 3.4 A janela Registered Servers.
Logo abaixo temos a janela Object Explorer. Nesta janela, abaixo do nome do servidor, é exibida uma
árvore, onde aparecem os diversos elementos que compõem um servidor SQL Server 2005. O primeiro
elemento é Databases. Ao expandir esta opção, serão exibidos todos os Bancos de Dados que estão
disponíveis nesta instância do Servidor SQL Server, conforme podemos ver na Figura 3.5. Os Bancos de
Dados são agrupados em Bancos de dados do sistema (System Databases), Banco de dados de snapshot
(Snapshot Databases) e os demais Bancos de Dados. Os Bancos de Dados contidos em System Data-
bases são os bancos criados e mantidos pelo próprio SQL Server 2005 e fundamentais ao funcionamento
do SQL Server 2005.
Figura 3.5 Bancos de Dados da instância SERVIDOR\SQL2005
Mantenha o SQL Server Management Studio.

NOTA
Falarei sobre a função dos Bancos de Dados do sistema, ao longo dos capítulos deste livro. O SQL Server Management Studio também tem
dezenas de outras funcionalidades, janelas e painéis, as quais aprenderemos a utilizar ao longo deste livro.
Porém, você deve estar lembrado, do Capítulo 2, que podemos ter várias instâncias do SQL Server 2005
instaladas no mesmo servidor ou até mesmo em servidores diferentes. Para poder administrar e ter
acesso aos elementos de outras instâncias, é preciso registrá-las no SQL Server Management Studio.
Lembre que, na prática, as diversas instâncias do SQL Server se comportam como se fossem servidores
completamente independentes. Vamos aprender a registrar uma outra instância do servidor SQL Server
no SQL Server Management Studio.
Exemplo: Para registrar a instância SERVIDOR\SRVINST02 no SQL Server Management Studio, siga os
passos indicados a seguir:
1. O SQL Server Management Studio deve ter sido mantido aberto no exemplo anterior. Caso este
tenha sido fechado, abra-o novamente.
2. Clique com o botão direito do mouse em “Microsoft SQL Servers”, na janela Registered
Servers, logo abaixo do menu File.
3. No menu de opções que surge, dê um clique na opção New -> Server Registration.
4. Será aberta a janela New Server Registration, na qual você deve informar os dados da instância
a ser conectada. Observe que a opção SQL Server já vem selecionada no campo Server Type e
não pode ser alterada. No campo Server Name digite o nome do servidor com o qual você quer
se conectar e selecione o tipo de autenticação. No Exemplo da Figura 3.6 estou me conectando
com SERVIDOR2\CURSOSJB, ou seja, a instância CURSOSJB no servidor chamado SERVIDOR2,
usando autenticação integrada do Windows.
Figura 3.6 Bancos de Dados da instância SERVIDOR\SQL2005.
5. No campo Registered Server Name você pode digitar um nome que servirá como um apelido,
como uma referência ao servidor. O padrão é o próprio nome da instância. No nosso exemplo,
o nome padrão é SERVIDOR2\CURSOSJB. Você pode digitar um nome mais amistoso, tal como
Servidor de Cursos, ou Servidor da Matriz. Você pode digitar uma descrição no campo Regis-
tered server description.
6. Após fornecer as informações necessárias, clique em Save. O novo servidor já estará disponível
para ser utilizado. Observe que o servidor já aparece no painel Registered Servers, conforme
Figura 3.7 A instância SERVIDOR2\CURSOSJB, recém-registrada.
7. Dê um clique duplo em SERVIDOR2\CURSOSJB, no painel Registered Servers e este servidor já

passará a ser exibido no painel Object Explorer, conforme indicado na Figura 3.8:
Figura 3.8 Acessando todos os objetos da instância SERVIDOR2\CURSOSJB, recém-registrada.
Observe que, após o registro da instância SERVIDOR2\CURSOSJB, passamos a ter acesso a todos os seus
objetos. Isso mostra como é fácil usar o SQL Server Management Studio, para administrar, remotamente,
todos os servidores SQL Server 2005 da sua rede. Claro que para isso você deve ter as devidas permissões.
Se a conta com a qual você está acessando um determinado servidor não tiver as permissões necessárias
para uma determinada ação (como por exemplo criar um novo Banco de Dados), você receberá uma
mensagem de acesso negado, ao tentar executar a ação para a qual você não tem permissão.
8. Mantenha SQL Server Management Studio aberto, pois continuaremos a utilizá-lo neste tópico.
Agora vamos aprender a configurar algumas opções importantes de uma instância do SQL Server 2005.
Estas opções são facilmente acessadas e configuradas com a utilização do SQL Server Management Studio.
Exemplo: Para configurar algumas opções da instância SERVIDOR\SQL2005, siga os passos indicados
a seguir:
1. As opções de configuração de uma instância são acessadas através das propriedades da instância.
Se o SQL Server Management Studio não estiver aberto, abra-o.
2. Para acessar as propriedades da instância SERVIDOR\SQL2005, dê um clique com o botão

direito nesta instância, na janela Object Explorer. No menu de opções que surge dê um
clique em Properties. Será aberta a janela de propriedades da instância, na qual temos onze
grupos de opções. As guias estão do lado esquerdo. Clicando em uma das guias, serão exibidas
as respectivas opções do lado direito da janela de propriedades. As principais opções que
podem ser configuradas em cada guia serão descritas na seqüência. Por padrão, vem selecionada
a guia General (Geral).
3. Na guia General, conforme indicado na Figura 3.9, é exibida uma série de informações sobre a
instância SERVIDOR\SQL2005. Observe que para o sistema operacional é informada a versão NT
– 5.0 (2195), que nada mais é do que o Windows 2000 Server versão final. Nesta guia também
podemos configurar se os serviços do SQL Server devem ser inicializados automaticamente quando
o sistema operacional é inicializado. Para isso, basta clicar no botão Configure, que será aberto o
Computer Manager, com a lista de todos os serviços do SQL Server 2005, conforme descrito no
Capítulo 2. Clique na opção Autostart Services. Nesta opção, você pode marcar os seguintes
serviços, para que sejam ou não inicializados, automaticamente: SQL Server (MSSQLServer), SQL
Server Agent (SQLServerAgent), Microsoft Search (MSFTESQL) e o MSDTC.
Figura 3.9 A guia General.
4. Também podemos definir parâmetros de inicialização para o SQL Server. Para isso clique na
guia Startup Parameters.
5. Na guia Memory, conforme indicado na Figura 3.10, podemos definir qual a memória que
estará disponível para o SQL Server. Existe a opção de configurarmos manualmente estes valores
ou permitirmos que o próprio SQL Server configure estes valores. Na maioria das situações, é
mais indicada a configuração automática pelo SQL Server (Dynamic Memory Configuration).
Figura 3.10 A guia Memory.
A seguir temos uma descrição das principais opções da guia Memory:
♦ Dynamically Memory Configuration: Permite que o próprio SQL Server gerencie a utilização
da memória. É a opção mais indicada, para a maioria das situações.
♦ Minimum server memory (in MB): Esta opção define qual a quantidade mínima de memória
que deve estar disponível, para que o SQL Server possa ser inicializado.
♦ Maximum server memory (in MB): Esta opção determina qual a quantidade máxima de
memória que pode ser utilizada pelo SQL Server.
♦ Minimum query memory: Determina a quantidade mínima de memória que deve ser alocada
para a execução de consultas dos usuários. O valor padrão é 1024 KB, ou seja, 1 MB.
♦ Configured values: Esta opção exibe os valores atualmente em uso e permite que você os
altere. Se você alterar algum valor, clique na opção Running values para verificar se as alterações
já tiveram efeito. Se as alterações que você fez ainda não tiverem sido implementadas, você
deverá parar e reinicializar o serviço SQL Server para a instância que está sendo configurada.
♦ Running values: Exibe os valores atualmente em uso. Estes valores não podem ser alterados
enquanto a opção Running values estiver selecionada.
6. Clique na guia Processors. Nesta guia, conforme indicado na Figura 3.11, podemos configurar
como o SQL Server utilizará o(s) processador(es) instalado(s) no servidor. Caso tenhamos uma
máquina com múltiplos processadores, podemos definir qual o processador (ou processadores)
que deve ser utilizado pela instância do SQL Server que está sendo configurada.
Figura 3.11 A guia Processor.
A seguir temos uma descrição das principais opções da guia Processor:
♦ Boost SQL Server priority on Windows: Podemos definir que a instância do SQL Server que está
sendo configurada rode em um nível de prioridade mais elevado do que outros processos que estão
rodando no servidor. Quanto mais elevado o nível de prioridade, maior o tempo que o processador
dedica para um determinado processo. O valor padrão é 0, o qual estabelece uma prioridade 7, que é
a prioridade padrão. Se definirmos um valor 1 para esta opção, estaremos definindo uma prioridade
13, tanto no Windows NT 4.0 quanto no Windows 2000 ou Windows Server 2003. Segundo o Books
OnLine, somente devemos alterar o valor padrão elevando-o, em servidores que são dedicados
exclusivamente ao SQL Server. Em servidores que executam outras funções, como um servidor Web
com o IIS, se elevarmos a prioridade de execução do SQL Server, iremos penalizar o desempenho dos
demais processos, em favor do SQL Server. Ou seja, prejudicaremos o desempenho de outros serviços,
para melhorar o desempenho do SQL Server 2005.
♦ Use Windows fibers: Esta é uma opção bastante técnica, que altera a maneira como o Win-
dows executa os processos do SQL Server. Ao definirmos esta opção, solicitamos que uma
determinada instância do SQL Server utilize fibers ao invés de threads. Esta configuração de-
fine que seja alocada uma thread por CPU a um fiber para cada usuário concorrente, até o valor
definido no campo Maximum worker threads. Esta configuração somente terá efeito após a
reinicialização do SQL Server. Para maiores informações sobre threads, fibers e processos, consulte
o site msdn.microsoft.com.
♦ Configured values: Esta opção exibe os valores atualmente em uso e permite que você os
altere. Se você alterar algum valor, clique na opção Running values para verificar se as alterações
já tiveram efeito. Se as alterações que você fez ainda não tiverem sido implementadas, você
deverá parar e reinicializar o serviço SQL Server para a instância que está sendo configurada.
♦ Running values: Exibe os valores atualmente em uso. Estes valores não podem ser alterados
enquanto a opção Running values estiver selecionada.
7. Clique na guia Security. Nesta guia, conforme indicado na Figura 3.12, podemos configurar
qual o tipo de segurança que iremos utilizar – Windows Authentication Mode ou SQL Server
and Windows Authentication Mode. Aprenderemos mais sobre segurança no SQL Server, no
Capítulo 6. Também podemos definir os níveis de auditoria desejados. Outra opção, que pode
ser configurada nesta guia, é a conta que será utilizada para a inicialização do serviço SQL
Server, relativo à instância que está sendo configurada.
Figura 3.12 A guia Security.
8. Clique na guia Connections. Nesta guia, conforme indicado na Figura 3.13, podemos definir
alguns parâmetros importantes, os quais definem a maneira como as conexões com o servidor
SQL serão tratadas. Por exemplo, no campo “Maximum concurrent user connections”
podemos definir o número máximo de conexões de usuário suportadas pela instância do
SQL Server, que está sendo configurada. Um valor 0 significa um número ilimitado de
conexões. A opção Remote query time-out define o tempo máximo que uma consulta do
usuário pode ficar rodando. Limitar este valor é importante, pois impede que consultas com
problemas fiquem rodando indefinidamente e ocupando recursos do servidor, o que pode
fazer com que o desempenho do servidor como um todo seja prejudicado (incluindo o
desempenho de todas as demais instâncias instaladas no mesmo servidor). Este valor é definido
em segundos. Um valor 0 significa tempo ilimitado, sendo que, conforme foi dito, esta não
é uma boa opção.
Figura 3.13 A guia Connections.
9. Na guia Database Settings, conforme indicado na Figura 3.14, podemos definir qual o fator de
preenchimento das páginas dos índices. Conforme veremos no Capítulo 4, o fator de
preenchimento de páginas de um índice influencia no desempenho das consultas. Também
podemos definir qual o diretório padrão onde serão criados os arquivos de dados para novos
Bancos de Dados – Default data directory e o diretório padrão para os arquivos de log de cada
Banco de Dados – Default log directory.
Figura 3.14 A guia Database Settings.
10. Clique na guia Misc Server Settings. Nesta guia, conforme indicado na Figura 3.15, podemos
definir qual o idioma que será utilizado para as mensagens de erro enviadas pelo SQL Server.
Também podemos definir algumas configurações mais avançadas como a utilização de triggers
aninhadas – Allow triggers fired other triggers. Veremos mais sobre triggers no Capítulo 10.
Também podemos definir como o SQL Server irá interpretar uma data que for digitada com
apenas dois dígitos no ano – Interpre a two-digit year as falling between.
11. Clique na guia Advanced. Nesta guia, conforme indicado na Figura 3.16, podemos definir
opções tais como o tempo limite para logon remoto (Remote Login Timeout), o tamanho do
pacote de rede (Network Packet Size) e assim por diante.
12. Clique na guia Permissions. Nesta guia, conforme indicado na Figura 3.17, podemos definir
uma série de permissões tais como alterar Bancos de Dados, alterar credenciais e outras. Veremos
mais detalhes sobre permissões e segurança no Capítulo 6.
13. Neste momento não iremos alterar nenhuma das configurações padrão desta instância do SQL
Server 2005. Dê um clique no botão Cancelar para fechar a janela de propriedades da instância
SERVIDOR\SQL2005.
Para completar a nossa introdução ao SQL Server Management Studio, iremos acessar a opção Data-
bases da instância SERVIDOR\SQL2005 e verificar quais Bancos de Dados são criados quando da
instalação de uma instância do SQL Server. Veremos que existe um Banco de Dados que é
imprescindível ao funcionamento do SQL Server – o Banco de Dados master, o qual está dentro da
opção System Databases – e outros que são Bancos de Dados de exemplo. Além dos que são criados
automaticamente, também poderemos criar os nossos próprios Bancos de Dados, conforme
aprenderemos ainda neste capítulo. Depois iremos verificar quais os elementos que estão disponíveis
dentro de um determinado Banco de Dados.
Figura 3.15 A guia Misc Server Settings.
Figura 3.16 A guia Advanced.
Figura 3.17 A guia Permissions.
Ao encerrarmos este tópico, o amigo leitor deverá ter uma visão geral do funcionamento e das possibilidades
oferecidas pelo SQL Server Management Studio. No restante deste livro, você irá executar uma série de
tarefas e exemplos práticos, os quais são realizados utilizando-se o SQL Server Management Studio.
Exemplo: Verificando os Bancos de Dados instalados por padrão, em uma instância do SQL Server
2005, siga os passos indicados a seguir:
1. Se você não estiver com o SQL Server Management Studio aberto, abra-o.
2. Clique no sinal de mais ao lado da instância SERVIDOR\SQL2005 (ou da instância instalada

no seu computador, o qual você está usando para acompanhar este capítulo), na janela Object
Explorer, para expandi-la. Serão exibidas as diversas categorias de objetos que compõem uma
instância do SQL Server 2005.
3. Nas opções que surgem abaixo desta instância, clique no sinal de mais ao lado da opção Data-
bases para expandi-la. Abaixo de Databases é exibida uma lista com os Bancos de Dados
disponíveis na instância SERVIDOR\SQL2005, conforme pode ser visto na Figura 3.18.
4. Dê um clique na opção Databases. No painel da direita, serão exibidas informações sobre os

Bancos de Dados do usuário, tal como a última vez em que foram feitos o backup do Banco de
Dados e o backup do log de transações. No SQL Server 2005, os Bancos de Dados são divididos
em categorias, tais como System Databases, Databases Snapshots e depois os Bancos de Dados
criados pelo usuário. Clique no sinal de +, ao lado da opção System Databases, para expandi-la.
Será exibida a lista de Bancos de Dados chamados de Bancos de Dados do sistema. Estes bancos
são fundamentais ao funcionamento do SQL Server 2005. De uma maneira mais simples, diríamos
que são para uso pelo próprio SQL Server 2005. Por exemplo, o Banco de Dados master é o
principal Banco de Dados de uma instância do SQL Server 2005. Nele estão tabelas com a lista de
todos os Bancos de Dados existentes na instância, com a lista de cada tabela de cada banco, a lista
de campos de cada tabela de cada banco e assim por diante. Se, por algum motivo, o Banco de
Dados master for corrompido, a instância do SQL Server 2005 simplesmente deixa de funcionar.
Figura 3.18 Os Bancos de Dados criados durante a instalação.
A seguir apresento uma breve descrição de cada um destes Bancos de Dados:
♦ master database: Este é o principal Banco de Dados para qualquer instância de qualquer servidor
SQL. É neste Banco de Dados que estão armazenadas informações de vital importância para o
funcionamento do SQL Server. Nas tabelas do Banco de Dados master, temos informações
sobre a inicialização do SQL Server, sobre a existência de outros Bancos de Dados, sobre as
contas disponíveis para logon, sobre segurança, etc. Se, por algum motivo, o Banco de Dados
master tiver sido corrompido e não pudermos recuperá-lo a partir de um backup recente,
simplesmente não poderemos mais utilizar o servidor SQL e nem ter acesso aos seus dados. Isso
demonstra bem a importância deste Banco de Dados.
♦ model database: É utilizado como um modelo para a criação de novos Bancos de Dados, isto
é, sempre que criarmos um novo Banco de Dados, este terá as definições padrões iguais às do
Banco de Dados model. Este Banco de Dados não pode ser excluído. Se desejarmos que todo
novo Banco de Dados, ao ser criado, já possua alguma tabela ou alguma outra configuração,
basta adicionar estas características ao model. Ao criarmos um novo Banco de Dados, este
“herdará” todas as características do Banco de Dados model.
♦ database msdb: Este Banco de Dados é necessário ao funcionamento do serviço de agendamento
de tarefas – SQL Server Agent. Embora possamos acessar toda a informação contida nas tabelas
do Banco de Dados msdb, não é aconselhável modificar o seu conteúdo diretamente. Devemos
deixar toda e qualquer modificação para o serviço SQL Server Agent.
♦ tempdb database: Este Banco de Dados é utilizado para operações temporárias. Por exemplo,
o resultado parcial de uma consulta é armazenado para ordenação. Somente depois de ordenado
é que o resultado seria enviado de volta para o cliente que fez a solicitação. Este Banco de
Dados é recriado, toda vez que o SQL Server é inicializado. As operações realizadas neste Banco
de Dados também são registradas no log de transações, para que os dados das tabelas envolvidas
na operação possam ser restaurados ao seu estado original, caso algum problema aconteça
durante a operação. O tamanho do tempdb pode aumentar automaticamente, conforme a
necessidade. Este controle é feito pelo próprio SQL Server.
♦ AdventureWorks: Este Banco de Dados, não mais na lista de System Databases, mas sim na
lista geral de Bancos de Dados, é um Banco de Dados de exemplo, o qual é disponibilizado com
o SQL Server. É interessante o estudo dos exemplos apresentados neste Banco de Dados, pois
muitos aspectos interessantes do SQL Server 2005 podem ser estudados através dos exemplos
presentes neste banco. Neste livro utilizarei este Banco de Dados para salientar alguns aspectos
de utilização do SQL Server. Embora este Banco de Dados possa ser eliminado, sugiro que você
o mantenha, pois serve como um boa fonte de estudos.
5. Mantenha o SQL Server Management Studio aberto. No próximo exemplo iremos a um nível
adiante, verificando quais elementos podem existir em um Banco de Dados do SQL Server 2005.
Exemplo: Para verificar quais os elementos que fazem parte de um Banco de Dados:
1. Dê um clique no sinal de mais ao lado do Banco de Dados AdventureWorks para expandi-lo e

depois dê um clique em AdventureWorks para selecioná-lo. Na Figura 3.19, podemos ver os
vários elementos que fazem parte de um Banco de Dados. Ao longo deste livro, você aprenderá
a criar, alterar e gerenciar estes elementos.
A seguir, uma breve descrição dos principais elementos:
♦ Tables: Ao selecionarmos esta opção serão exibidas todas as tabelas do Banco de Dados. Também
podemos utilizar esta opção para criar uma nova tabela, para importar dados de uma outra
fonte para uma tabela do SQL Server ou exportar dados de uma ou mais tabelas do SQL Server
para outro formato de dados. Para acessar os dados de uma tabela basta clicar com o botão
direito sobre o nome da tabela. No menu de opções que surge aponte para Script Table as ->
SELECT To -> New Query Editor Window. Será aberta uma janela do Query Editor, com o
código T-SQL para retornar os registros da tabela, na qual você clicou com o botão direito do
mouse. Esta janela é a substituta do Query Analyzer, o qual era um utilitário separado no SQL
Server 2000. No SQL Server 2005, todas as funções do Query Analyzer são executadas diretamente
dentro do SQL Server Management Studio, através desta janela específica para execução de
comandos. Para executar o comando basta clicar no botão Execute ou pressionar Ctrl+E. O
comando será executado e os registros da tabela serão exibidos, conforme exemplo da Figura
3.20. Embora possamos acessar os dados de uma tabela através do SQL Server Management
Studio, este não é um procedimento comum. Conforme descrito anteriormente, o SQL Server
2005 é um servidor de Banco de Dados, no qual ficam armazenadas as informações, sendo que
o SQL Server oferece uma série de funcionalidades para gerenciar e manter em segurança estes
dados. Porém para acessar ou alterar os dados, normalmente utilizamos aplicações Cliente, as
quais podem ser desde um programa desenvolvido em Visual Basic e utilizando a tradicional
arquitetura Cliente/Servidor até uma moderna aplicação Web, desenvolvida em ASP.NET,
utilizando uma arquitetura em n camadas.
Figura 3.19 Os elementos de um Banco de Dados.
♦ Views: Nesta opção são exibidas as consultas que foram salvas no Banco de Dados. Uma consulta
é criada através da definição de uma instrução que utiliza a linguagem SQL que, no caso do
SQL Server 2005, é chamada de T-SQL. Podemos ter acesso à instrução que define uma view,
simplesmente clicando com o botão direito do mouse sobre a view e, no menu que surge,
clicando em Modifty View.
♦ Programmability -> Stored Procedures: Um stored procedure é um grupo de comandos que

foram gravados no Banco de Dados. Um stored procedure pode ser chamado dentro de um
programa do cliente. Parâmetros de entrada podem ser passados para um stored procedure,
sendo que este pode retornar os seus resultados utilizando parâmetros de saída. Os comandos
de um stored procedure podem ser compilados e armazenados em memória pelo Servidor SQL.
Podemos, por exemplo, criar stored procedures que executam as consultas mais utilizadas;
pelo fato de os comandos serem compilados e armazenados em memória, que acelera a execução
da consulta, acaba gerando um desempenho melhor para a aplicação do cliente. Para ter acesso
aos comandos de um stored procedure basta clicar com o botão direito sobre o stored proce-
dure e selecionar Modify no menu de opções que surge. Na Figura 3.21, temos o exemplo dos
comandos de um stored procedure. No Capítulo 10 aprenderemos um pouco mais sobre a
linguagem para a criação de stored procedures e criaremos alguns exemplos.
Figura 3.20 Dados da tabela EmployeeDepartmentHistory.
Figura 3.21 Os comandos de um stored procedure.
♦ As opções Security -> Users e Security -> Roles: Estas opções estão relacionadas com a segurança
de acesso aos elementos de um Banco de Dados. No Capítulo 6 trabalharemos com segurança
no SQL Server 2005.
♦ Programmability -> Rules: A criação de rules foi mantida no SQL Server 2005 por questões de
compatibilidade. Com a utilização de rules, podemos definir regras para os valores que podem
ser aceitos em um determinado campo de uma tabela. Por exemplo, podemos definir que o
campo ValorDoFinanciamento da tabela empréstimos deve ter um valor entre R$ 1.500,00 e
R$ 10.000,00. No SQL Server 2005 podemos utilizar o mecanismo de CHECK Constraints, o
qual é mais eficiente do que a utilização de rules. No Capítulo 10 aprenderemos o funcionamento
e também aprenderemos a criar CHECK Constraints.
♦ Programmability -> Defaults: A criação de defaults permite que seja definido um valor padrão
para um campo de uma tabela, caso o campo não seja preenchido pelo usuário. No Capítulo
10, aprenderemos a criar defaults.
2. SQL Server Management Studio.
Agora finalizamos o nosso passeio inicial pelo SQL Server Management Studio. Já sabemos da existência
dos vários elementos que fazem parte de um servidor SQL Server, bem como os diversos elementos que
compõem um Banco de Dados. Agora estamos aptos a começar a trabalhar com estes elementos. O
primeiro passo é aprendermos sobre a criação de novos Bancos de Dados.
Antes de partirmos para a criação de Bancos de Dados no SQL Server 2005, vamos revisar alguns
conceitos importantes sobre os tipos de volumes que podem ser criados no Windows 2000 Server e no
Windows Server 2003. Aprenderemos conceitos como RAID-0, RAID-1 e RAID-5, bem como a forma de
implementá-los no Windows 2000 Server. Mas este é assunto para o próximo item.
FUNDAMENTOS EM: ARMAZENAMENTO

BÁSICO X ARMAZENAMENTO DINÂMICO
PRÉ-REQUISITOS
♦ Noções do sistema operacional Windows.
METODOLOGIA
♦ Apresentação dos diferentes tipos de armazenamento no Windows 2000.
O Windows 2000 Server e também o Windows Server 2003 apresentam algumas melhorias no
gerenciamento de discos, partições e volumes, em relação às versões anteriores. Um conceito importante
que foi introduzido é o conceito de armazenamento dinâmico. Em seguida veremos a diferença entre
o armazenamento dinâmico e o armazenamento básico, o qual é o padrão utilizado pelas versões
anteriores do Windows.
Neste item tratarei da criação de volumes redundantes através de software. Também existe a possibilidade
da criação de volumes redundantes através da utilização das chamadas Placas de RAID, as quais são
projetadas especificamente para este fim. Com o Windows 2000 Server e o Windows Server 2003,
podemos implementar RAID em software ou em hardware. Se você estiver tendo problemas com o
desempenho, a opção de RAID por hardware pode ajudar, embora a implementação seja mais onerosa
do que a por software.
ARMAZENAMENTO BÁSICO E ARMAZENAMENTO DINÂMICO

Utilizarei a palavra disco como referência a um disco rígido. Então, sempre que você encontrar uma
referência a disco, entenda como sendo um disco rígido e não um disquete ou outro tipo de mídia.
Antes que seja possível utilizar um novo disco no Windows, temos que realizar algumas operações
sobre o disco. Um dos aspectos que temos que definir é o tipo de armazenamento que iremos utilizar
neste disco. No Windows podemos optar entre dois tipos de armazenamento: básico ou dinâmico.
Abaixo temos detalhes sobre cada um dos tipos de armazenamento.
♦ Armazenamento básico: É o tipo de armazenamento que vem sendo utilizado desde a época do
DOS. É utilizado por sistemas como o Windows 95, Windows 98, Windows NT Server 4.0 e
Windows NT Workstation 4.0. É o tipo padrão no Windows 2000 Server, Windows Server 2003
e no Windows XP, isto é, todos os discos são criados com armazenamento básico. Caso seja
necessário, o administrador deve transformá-los para armazenamento dinâmico sem perda de
dados. Um disco com armazenamento básico é chamado de disco básico.
♦ É importante salientar que um disco somente pode ser configurado para um tipo de
armazenamento. Não podemos, por exemplo, ter uma porcentagem do disco com
armazenamento básico e o restante com armazenamento dinâmico.
♦ No armazenamento básico, o disco é dividido em partições. Uma partição é uma parte do disco que
se comporta como se fosse uma unidade de armazenamento separada. Por exemplo, em um disco
de 4 GB, posso criar duas partições de 2 GB, que na prática se comportam como se fossem dois
discos de 2 GB independentes. Em um disco com armazenamento básico, podemos ter partições
primárias, partições estendidas e drivers lógicos. Vamos ver detalhes sobre estes elementos.
♦ Partição primária: O Windows 2000 Server pode utilizar uma partição primária para inicializar o
computador, sendo que somente partições primárias podem ser marcadas como ativas. Uma partição
ativa é onde o computador procura pelos arquivos de inicialização para efetuar o processo de boot.
Um disco somente pode ter uma partição marcada como ativa. Um disco básico pode conter no
máximo quatro partições primárias. Considere o exemplo da Figura 3.22, onde um disco de 6 GB
foi dividido em quatro partições primárias. Duas de 2 GB e duas de 1 GB. Observe que, para cada
partição primária, é atribuída uma letra de unidade C:, D: e assim por diante.
♦ Partição estendida: Podemos ter uma única partição estendida em um disco básico. Partições
estendidas são criadas a partir do espaço livre em um determinado disco. Espaço livre é o espaço
que não está sendo ocupado por nenhuma outra partição. Por isso é aconselhável, quando da
criação de uma partição estendida, que todo o espaço livre seja ocupado. Nós dividimos a partição
estendida em segmentos, sendo que cada segmento representará um drive lógico. Devemos atribuir
uma letra para cada driver lógico e formatá-los com um sistema de arquivos – FAT, FAT32, NTFS
ou NTFS 5. Com o uso de uma partição estendida e drivers lógicos, podemos superar o limite de
quatro unidades por disco, limite que é imposto quando utilizamos apenas partições primárias.
Considere o exemplo da Figura 3.23, onde temos um disco com três partições primárias (C:, D: e
E:), e um volume estendido, no qual foram criados dois drivers lógicos (F: e G:).
Figura 3.22 No máximo podemos ter quatro partições primárias.
Figura 3.23 Utilizando partições estendidas.
♦ Para o Windows 2000 Server ou Windows Server 2003 existem duas partições que são muito
importantes. A Partição do Sistema – System Partition – é a partição ativa que contém os
arquivos necessários para o processo de boot do Windows 2000 Server. Normalmente é a primeira
partição ativa do primeiro disco. A Partição de Boot – Boot partition – é uma partição primária,
ou um driver lógico onde os arquivos do Windows 2000 Server estão instalados, normalmente
em um diretório chamado Winnt. Muitas vezes estes conceitos causam uma certa confusão,
porque podemos dizer que a “Partição do sistema contém os arquivos de boot e a Partição de
boot contém os arquivos do sistema operacional”. Normalmente, a partição do sistema e a
Partição de boot estão na mesma partição, tipicamente no drive C:.
Dependendo da maneira com que as partições são criadas ou combinadas, podemos ter diversos tipos
de partições, conforme indicado abaixo:
♦ Partição do Sistema: Contém os arquivos necessários para o boot do Windows 2000 Server ou
♦ Partição de Boot: Contém os arquivos do Windows 2000 Server ou Windows Server 2003,
tipicamente em uma pasta Winnt.
♦ Volume set: Neste tipo de partição, combinamos o espaço de duas ou mais partições, no mesmo
disco ou em discos diferentes, de tal forma que aparecem para o Windows como uma única
unidade. Por exemplo, posso combinar uma partição de 1 GB com outra de 4 GB, para formar
uma unidade de 5 GB. O Windows preenche todo o espaço da primeira partição, depois o da
segunda e assim por diante. Se uma das partições apresentar problemas, todo o Volume set será
perdido. Posso juntar partições de tamanhos diferentes. Não pode conter a Partição do sistema,
nem a Partição de boot. Não é uma boa opção utilizarmos um volume set para armazenar os
Bancos de Dados do SQL Server 2005. O volume set não oferece melhorias no desempenho
nem tolerância a falhas.
♦ Stripe set: Neste tipo de partição combinamos espaços iguais de dois ou mais discos, não
podendo utilizar duas partições do mesmo disco. Podemos utilizar até 32 partições. Os dados
são gravados em todas as partições de uma maneira uniforme, isto é, o espaço de cada partição
vai sendo preenchido à medida que os dados são gravados. Não apresenta tolerância a falhas,
pois, se uma das partições apresentar problemas, todo o Stripe set será perdido. A única vantagem
do Stripe set é que o desempenho melhora devido às gravações simultâneas em mais de um
disco. Não pode conter a Partição do sistema, nem a Partição de boot.
♦ Mirror set – RAID 1: Permite a duplicação de qualquer partição. Com isso à medida que os
dados vão sendo gravados, o Windows, automaticamente, vai duplicando os dados na partição
espelhada. Pode conter a Partição do sistema e também a Partição de boot. O maior
inconveniente é que existe um comprometimento de 50% do espaço em disco. Por exemplo,
para fazer o espelhamento de uma partição de 2 GB, estaremos ocupando 4 GB em disco.
Apresenta tolerância a falhas, pois se uma das partições espelhadas falhar, a outra continua
funcionando. Podemos substituir o disco defeituoso e restabelecer o espelhamento. Este tipo
de partição só está disponível nas versões de servidor do Windows, tais como o Windows NT
Server, Windows 2000 Server e Windows Server 2003.
♦ Stripe set com paridade – RAID 5: Um stripe set com paridade é um stripe set com tolerância
a falhas. Junto com os dados, o Windows grava informações de paridade (obtidas a partir de
cálculos matemáticos) nos vários discos que formam o stripe set com paridade. Com isso, no
evento de falha de um dos discos, toda a informação do disco com problemas pode ser
reconstituída a partir das informações de paridade dos outros discos. O disco defeituoso pode
ser substituído, e a informação nele contida, recriada a partir das informações de paridade,
contidas nos demais discos do RAID-5. Para que possamos construir um volume deste tipo, um
mínimo de três discos é necessário. Porém, se dois discos falharem ao mesmo tempo, não será
possível recuperar a informação. Também existem implementações de RAID-5 em hardware,
que são mais rápidas, porém mais caras. Esta é uma boa opção para armazenamento dos Bancos
de Dados do SQL Server 2005. Este tipo de partição só está disponível nas versões de servidor
do Windows, tais como o Windows NT Server, Windows 2000 Server e Windows Server 2003.
♦ Armazenamento dinâmico: No armazenamento dinâmico, que é somente suportado pelo

Windows 2000 Server, Windows XP e Windows Server 2003, é criada uma única partição com
todo o espaço do disco. Um disco configurado com armazenamento dinâmico é chamado de
“Disco dinâmico”. Um disco dinâmico pode ser dividido em volumes. Um volume pode conter
uma ou mais partes de um ou mais discos. Também é possível transformar um disco básico em
um disco dinâmico, sem perda dos dados. Podemos ter diferentes tipos de volumes. O tipo de
volume a ser utilizado é determinado por fatores tais como espaço disponível, performance e
tolerância a falhas. A tolerância a falhas diz respeito à possibilidade de o Windows 2000 Server
manter as informações, mesmo no evento de comprometimento de um disco ou volume.
Temos os seguintes tipos de volume:
♦ Volume simples: É formado por espaço de um único disco, e além disso não fornece nenhum
mecanismo de tolerância a falhas, isto é, se houver algum problema com o disco onde está
o volume, toda a informação será perdida.
♦ Volume expandido: Pode incluir espaço de até 32 diferentes discos. O Windows começa a
preencher o espaço do primeiro disco e, após este estar esgotado, passa para o espaço
disponível no segundo disco e assim por diante. Não fornece nenhum mecanismo de
tolerância a falhas. Se um dos discos que formam o volume apresentar problemas, todo o
volume estará comprometido. Também não oferece melhoria no desempenho, uma vez
que a informação somente é gravada ou lida em um disco ao mesmo tempo. Não é uma boa
opção para armazenamento dos Bancos de Dados do SQL Server 2005, principalmente porque
não oferece melhorias no desempenho.
♦ Volume espelhado (Mirrored volume) ou RAID-1: É formado por duas cópias idênticas do
mesmo volume, sendo que as cópias são mantidas em discos separados e sincronizadas, em
tempo real, pelo Windows. Volumes espelhados oferecem proteção contra falha, uma vez
que, se um dos discos falhar, a informação do outro disco pode ser utilizada. O espelhamento
pode ser desfeito, o disco defeituoso substituído, e o espelhamento pode ser refeito. O único
inconveniente é que, devido à duplicidade das informações, o espaço de armazenamento
necessário é exatamente o dobro. Se a performance não for um fator determinante é uma
opção a ser analisada para o armazenamento dos Bancos de Dados do SQL Server 2005.
♦ Striped Volume ou RAID-0: Podem ser combinadas áreas de espaço livre de até 32 discos. Não
apresenta nenhum mecanismo de tolerância a falhas, pois se um dos discos do striped volume
falhar, toda a informação estará comprometida. Uma das vantagens é que o desempenho melhora,
uma vez que as informações são gravadas nos diversos discos ao mesmo tempo.
♦ Volume do tipo RAID-5: Um volume do tipo RAID-5 é um striped volume, porém com
tolerância a falhas. Junto com os dados, o Windows grava informações de paridade (obtidas
a partir de cálculos matemáticos) nos vários discos que formam o RAID-5. Com isso, no
evento de falha de um dos discos, toda a informação do disco com problemas pode ser
reconstituída a partir das informações de paridade dos outros discos. O disco defeituoso
pode ser substituído e a informação nele contida recriada a partir da informação de paridade
nos demais discos do RAID-5. Para que possamos construir um RAID-5, um mínimo de três
discos é necessário. Porém se dois discos falharem, ao mesmo tempo, não será possível
recuperar a informação.
NOTA
Para informações sobre como criar e gerenciar os diversos tipos de volumes apresentados neste item, consulte a Unidade VIII, do livro
“Microsoft Windows 2000 Server Curso Básico & Rápido”, da editora Axcel Books, já citado anteriormente, disponível para compra no
formato de e-book, em: http://www.juliobattisti.com.br/cursos
FUNDAMENTOS EM: A ESTRUTURA DE ARMAZENAMENTO

DOS BANCOS DE DADOS NO SQL SERVER 2005
PRÉ-REQUISITOS
♦ Não há.
METODOLOGIA
♦ Apresentação dos elementos que compõem um Banco de Dados do SQL Server 2005.
Um Banco de Dados do SQL Server 2005 é formado por um conjunto de arquivos. Cada Banco de Dados
contém dois tipos de arquivos: arquivos de dados e arquivos de log. Os arquivos de dados são utilizados
para armazenar os diversos elementos de um Banco de Dados, como tabelas, views, triggers, stored
procedures, etc. Os arquivos de log armazenam o chamado log de transações. O Log de transações é um
registro das operações que são efetuadas nos dados do Banco de Dados. Veremos detalhes sobre o log
mais adiante. Os arquivos de dados podem ser de dois tipos: arquivos primários e secundários.
Todo Banco de Dados deve possuir pelo menos um arquivo primário e um arquivo de log. O arquivo
primário contém as informações necessárias para inicialização do Banco de Dados e é utilizado para armazenar
as chamadas tabelas do sistema, que são tabelas necessárias ao funcionamento do Banco de Dados. As
tabelas criadas pelos usuários podem ser armazenadas também no arquivo primário ou em arquivos
secundários. De acordo com a necessidade, podemos adicionar um ou mais arquivos secundários de dados.
Um arquivo, quer seja de dados, quer seja de log, somente pode ser utilizado por um Banco de Dados, isto
é, não podemos ter arquivos compartilhados por mais do que um Banco de Dados. Quando estamos
falando de arquivos de dados (primários ou secundários) e arquivos de log, estamos nos referindo a arquivos
do sistema operacional como por exemplo: C:\livrosql\contas\principal.mdf. Este seria um exemplo de
um arquivo de dados primário, que, conforme detalharemos logo em seguida, possui a extensão .mdf.
Por exemplo, o Banco de Dados master é formado, por padrão, por um arquivo primário e um de log
com os seguintes nomes:
♦ Arquivo de dados primário -> master.mdf
♦ Arquivo de log -> master.ldf
Vamos ver em detalhes os tipos de arquivos que fazem parte de um Banco de Dados:
♦ Arquivo de dados primário (Primary data file): Todo Banco de Dados deve conter um, e
somente um, arquivo de dados primário. Este arquivo possui a extensão .mdf. Neste arquivo
ficam informações necessárias à inicialização do Banco de Dados, bem como informações sobre
a localização dos outros arquivos que fazem parte do Banco de Dados. Esta informação também
é armazenada nas tabelas do Banco de Dados master, já descrito anteriormente. Se, por algum
motivo, o arquivo de dados primário for corrompido, e não puder ser restaurado, perderemos
todo o Banco de Dados, mesmo que os demais arquivos estejam intactos. Perder o arquivo
primário é como perder o “mapa para as demais informações do Banco de Dados”.
♦ Arquivo de dados secundário (Secondary data files): Em um Banco de Dados podemos ter um
ou mais arquivos de dados secundário. Não somos obrigados a criar arquivos de dados secundários.
À medida que o Banco de Dados vai crescendo podemos utilizar arquivos de dados secundários
para gravar a informação em diferentes volumes. Esta técnica pode ajudar no desempenho do
Banco de Dados como um todo. A extensão destes arquivos secundários é .ndf.
♦ Arquivos do log de transações (Transaction log files): Nestes arquivos fica gravado todo o
registro das operações realizadas no Banco de Dados, o qual deve ter pelo menos um arquivo
de log. Conforme a necessidade, arquivos de log, adicionais, podem ser criados. A extensão
para os arquivos de log é .ldf.
O tamanho máximo para um arquivo de dados (quer seja primário ou secundário) é 32 TB (Tera bytes). Para um arquivo de log, o tamanho
NOTA
máximo é 32 TB também, tanto nas versões de 32 bits quanto de 64 bits do SQL Server 2005. O número máximo de arquivos por Banco de
Dados é de 32767.
Com o SQL Server 2005 não é obrigatória a utilização das extensões .mdf, .ndf e .ldf para arquivos primários, secundários e de log,
respectivamente. Esta é apenas uma recomendação para facilitar a identificação do tipo do arquivo.
Arquivos de dados e de log podem ser gravados tanto em partições formatadas com FAT como NTFS, porém a partição (no caso de NTFS) não
pode estar compactada.
ENTENDENDO O CONCEITO DE FILEGROUPS

No SQL Server 2005 (na verdade a partir do SQL Server 7.0), temos o conceito de Filegroup. Este
conceito muitas vezes não é utilizado na prática por falta de entendimento do que ele significa, como
pode ser utilizado e quais as vantagens em utilizar filegroups.
A utilização de um filegroup permite que os arquivos de um Banco de Dados sejam agrupados para
facilitar o gerenciamento, bem como a distribuição ao longo de volumes redundantes e de melhor
desempenho (RAID-0, RAID-1, etc.). A utilização de filegroup pode ser um auxiliar valioso na melhoria
do desempenho de um Banco de Dados, ao permitir que o Banco de Dados (através dos seus diversos
arquivos) seja criado em múltiplos discos, múltiplas controladoras ou em sistemas do tipo RAID, quer
seja RAID por software ou por hardware, conforme descrito no item anterior. Também podemos fazer
com que uma tabela ou índice seja criada em um disco específico, simplesmente associando a tabela ou
índice com um filegroup. Isto nos abre maiores possibilidades. Por exemplo, podemos deslocar uma
tabela que é muito consultada para um sistema de discos de melhor desempenho. Um arquivo pode estar
associado com um único filegroup. O uso de filegroups também pode ser empregado para facilitar o
gerenciamento das rotinas de backup/restore, pois ao fazer o backup de um filegroup, todos os arquivos
contidos no filegroup – mesmo que estejam em discos e volumes separados serão incluídos no backup.
NOTA
Os arquivos de log não fazem parte de nenhum filegroup, sendo que estes são gerenciados separadamente pelo Banco de Dados.
Podemos ter três tipos de filegroups. A seguir descrevemos os três tipos existentes:
♦ Primary filegroup: É o filegroup padrão. Contém todos os arquivos de dados primários (.mdf)
e qualquer arquivo que não tenha sido, explicitamente, atribuído a outro filegroup. Todo Banco
de Dados possui as chamadas tabelas de sistema, as quais possuem informações sobre os usuários
autorizados a acessar os objetos do Banco de Dados e o nível de permissão de acesso de cada
um. As tabelas de sistema são criadas automaticamente pelo SQL Server, quando criamos o
Banco de Dados. Estas tabelas ficam gravadas no arquivo de dados primário (.mdf) o qual, por
padrão, é associado com o Primary filegroup (o qual é, por padrão, o default filegroup).
♦ User-defined filegroups: É qualquer filegroup criado pelo usuário durante o processo de criação
ou alteração de uma tabela. Conforme descrito anteriormente, podemos criar tabelas ou índices
associados com um filegroup criado pelo usuário.
♦ Default filegroup: Toda tabela ou índice ao ser criado será associado com o filegroup padrão,
a menos que seja explicitamente associado com um filegroup definido pelo usuário. O filegroup
padrão, por definição, é o Primary filegroup. Cada Banco de Dados possui o seu default filegroup,
com o qual é associado. Conforme veremos ainda neste capítulo, existem comandos T-SQL
que permitem alterar o filegroup associado com um determinado Banco de Dados.
A criação de filegroups adicionais não é obrigatória e, para muitas aplicações, todos os dados podem
ser colocados no Primary filegroup. Porém em situações mais complexas, onde o desempenho precisa
ser otimizado o máximo possível, a utilização de filegroups pode ser um auxiliar valioso para distribuir
os dados entre diferentes discos, controladores ou sistemas de RAID. Por exemplo, a colocação de uma
tabela que está sendo intensamente acessada, em um RAID de hardware, de vários discos, pode melhorar
bastante o desempenho do sistema.
Todos nós sabemos que uma imagem vale por mil palavras. Então vamos apresentar alguns exemplos
de utilização de filegroups.
Considere o exemplo apresentado na Figura 3.24. Neste exemplo, temos apenas o filegroup padrão
(Primary filegroup) e todos os arquivos do Banco de Dados em um único disco. Esta situação apresenta
um desempenho bastante insatisfatório para grandes Bancos de Dados, os quais serão utilizados por
um grande número de usuários. Um único disco, uma única controladora = desempenho nada
satisfatório se o volume de dados e o número de usuários forem grandes.
Agora vamos fazer algumas modificações. Iremos adicionar mais três discos. Vamos criar mais dois
filegroups, além do Primary filegroup: Filegroup1 e Filegroup2. Vamos deslocar os arquivos secundários
para estes filegroups em outros discos. Também iremos deslocar o arquivo de log para um quarto disco,
conforme indicado na Figura 3.25. Neste caso, estamos melhorando consideravelmente o desempenho
do nosso sistema.
Figura 3.24 Uma situação com possíveis problemas no desempenho.
Figura 3.25 Melhorando o desempenho do nosso Banco de Dados.
Poderíamos otimizar ainda mais o desempenho do nosso sistema de discos. Por exemplo, ao invés de
termos simplesmente Disco 2 e Disco 3, estes poderiam ser sistemas de RAID-5 com controladoras
diferentes, o que otimizaria ainda mais o desempenho.
A seguir, apresento alguns detalhes importantes, os quais você não pode esquecer quando for definir a
sua estratégia de filegroups:
♦ Um arquivo somente pode fazer parte de um único filegroup.
♦ Informações de dados e do log de transações não podem fazer parte do mesmo arquivo. Por
isso, os arquivos de log sempre são gerenciados separadamente dos arquivos de dados.
♦ Os arquivos de log não podem fazer parte de um filegroup e são gerenciados separadamente
pelo SQL Server 2005.
Até neste momento tratamos apenas da teoria sobre a estrutura de um Banco de Dados no SQL Server 2005 e de filegroups. Aprenderemos,
NOTA
no próximo tópico, a criar Bancos de Dados, a criar arquivos secundários (Secondary data files) e a criar filegroups. Conforme descrito
anteriormente, aprenderemos a realizar estas operações utilizando o SQL Server Management Studio. Também aprenderemos a executar
estas tarefas, usando comandos T-SQL, na janela para execução de comandos, dentro do próprio SQL Server Management Studio (a qual
substitui o Query Analyzer), o qual era um aplicativo separado, no SQL Server 2000.
FUNDAMENTOS EM: CRIAR BANCOS DE DADOS NO

SQL SERVER 2005 COM O SQL SERVER MANAGEMENT STUDIO
PRÉ-REQUISITOS
♦ Noções do SQL Server 2005.
♦ Utilização dos consoles baseados no MMC.
♦ Conhecer os opções que fazem parte de uma instância do SQL Server 2005.
METODOLOGIA
♦ Apresentação dos passos utilizados para a criação de Bancos de Dados.
TÉCNICA
♦ Criação de Bancos de Dados com o SQL Server Management Studio.
Antes de criarmos um novo Banco de Dados quero fazer um pequeno parênteses sobre segurança. Você
deve ter notado que, sempre que abrimos o SQL Server Management Studio, tivemos acesso a todos os
elementos do SQL Server 2005. Nunca foi solicitado que digitássemos um nome de usuário e senha.
Isto acontece porque, ao instalarmos o SQL Server 2005 no Capítulo 2, optamos pela segurança integrada
com o Windows. Como estou fazendo o logon com a conta Administrator, esta possui “poderes totais”
sobre todos os elementos do servidor SQL Server, quando estamos utilizando a segurança integrada
com o Windows. Falaremos detalhadamente sobre segurança no Capítulo 6.
Agora chega de conversa e vamos à criação de um Banco de Dados de exemplo.
A seguir, temos os detalhes sobre o Banco de Dados que iremos criar:
Nome no SQL Server: Exemplo-1

Arquivo primário: C:\livrosql\exemplo1\exemplo1-prim.mdf
Arquivo secundário: C:\livrosql\exemplo1\exemplo1-sec1.ndf
Arquivo de log: C:\livrosql\exemplo1\exemplo1-log.ldf
Exemplo prático: Criando um novo Banco de Dados na instância SERVIDOR\SRVINST01, usando o

SQL Server Management Studio:
1. Abra o SQL Server Management Studio e conecte-se com o servidor no qual você deseja criar
um novo Banco de Dados. Neste exemplo, estou fazendo a conexão com o servidor
SERVIDOR\SQL2005.
2. No painel da esquerda, localize a janela Object Explorer. Se esta janela não estiver aberta,
pressione a tecla de função F8 para exibi-la. Caso a janela não esteja na posição desejada, você
pode arrastá-la para qualquer posição, dentro da janela do SQL Server Management Studio.
Clique no sinal de + ao lado da instância na qual será criado o Banco de Dados.
3. Nas opções que surgem abaixo da instância, dê um clique em Databases para selecioná-la.
4. Clique com o botão direito do mouse em Databases. No menu que surge dê um clique na
opção New Database. Será exibida a janela New Database, conforme indicado na Figura 3.26,
com a guia General, selecionada por padrão.
Figura 3.26 A janela New Database.
5. Na guia General, iremos definir o nome do Banco de Dados. No nosso exemplo digitaremos:
Exemplo1. Nesta guia também podemos definir qual a Collation que será definida para este
Banco de Dados. Podemos optar por utilizar a Collation definida para o servidor quando da
instalação do mesmo ou um outro tipo. Lembre-se que Collation define propriedades importantes
da maneira como os dados serão armazenados e recuperados. A possibilidade de ter diferentes
opções para cada Banco de Dados é uma novidade do SQL Server 2000 a qual, evidentemente, faz
parte do SQL Server 2005. Nesta guia você também define quem será o usuário dono do Banco de
Dados. O usuário dono, por padrão, tem permissões completas sobre todos os objetos do Banco
de Dados. Por padrão, é sugerido o usuário as, que é o usuário com permissões de administrador
no SQL Server 2005. Vamos aceitar a sugestão e deixar o usuário as como dono do Banco de
Dados. Nesta guia aceite a opção padrão do servidor e digite Exemplo1 no campo Name.
6. Na parte de baixo desta guia, poderemos definir quais os arquivos de dados que serão utilizados
para o Banco de Dados Exemplo1. Lembre que neste caso teremos o arquivo primário
C:\livrosql\exemplo1\exemplo1-prim.mdf e o secundário C:\livrosql\exemplo1\ exemplo1-
sec1.ndf. Poderemos criar estes dois arquivos na guia Data Files.
7. No campo File Name, digite o nome do arquivo primário exemplo1-prim sem a extensão. Você
também pode definir o tamanho inicial para o arquivo. No nosso exemplo, digite 20 na coluna
Initial Size do arquivo primeiro, para criarmos um arquivo primário com um tamanho inicial
de 10 MB. Na coluna Autogrowth (Autocrescimento), você define de que maneira o arquivo
primário irá crescer, à medida que os dados forem sendo adicionados. O padrão é crescer de 10
em 10 por cento, com tamanho ilimitado (evidentemente que o tamanho máximo será limitado
pelo espaço disponível em disco). Se você quiser alterar a forma de crescimento, clique no
botão com as reticências ... ao lado da opção selecionada. Será exibida a janela Change
Autogrowht, indicada na Figura 3.27, na qual você pode definir diferentes formas de crescimento
para o arquivo primário exemplo1-prim, do Banco de Dados Exemplo1. Você pode habilitar ou
desabilitar o crescimento automático, pode fazer com que o crescimento seja em percentual ou
em MB e pode permitir um tamanho máximo ou crescimento irrestrito. Selecione as opções
desejadas, que para o nosso exemplo serão: Tamanho inicial: 10 MB, Crescimento automático
em incrementos de 1 MB e Poderá crescer até o máximo de 50 MB. Selecione estas opções e
clique em OK, para fechar a janela Change Autogrowht.
Figura 3.27 Definindo as opções de crescimento do arquivo primário.
8. Agora vamos definir a pasta onde será gravado o arquivo primário. Por padrão, o SQL Server 2005
sugere o seguinte caminho: C:\Arquivos de programas\Microsoft SQL Server\MSSQL.1\MSSQL\
DATA. Vamos alterar o caminho para: C:\livrosql\exemplo1. Você pode digitar este caminho direta-
mente, ou clicar no botão com as reticências, para selecionar o caminho com o mouse e deixar que
o SQL Server 2005 preencha esta coluna, com o caminho selecionado.
9. Ainda na guia General, e seguindo as orientações passadas anteriormente, vamos configurar as opções
do arquivo secundário C:\livrosql\exemplo1\exemplo1-sec1.ndf, com as seguintes características:
♦ Tamanho inicial: 10 MB.
♦ Crescimento automático em incrementos de 2 MB.
♦ Poderá crescer até o máximo de 100 MB.
10. Para adicionar um arquivo secundário, clique no botão Add, na parte de baixo da guia General.
Uma nova linha será criada. Na coluna File name, digite exemplo1-sec1.ndf. Na coluna File
Type selecione Data. Na coluna Filegroup selecione Primary. Na colunia Initial Size (MB), digite
10. Clique no botão de reticências, ao lado da opção de Autocrescimento, para abrir a janela
Change Autogrowth e selecione um crescimento automático em incrementos de 2 MB e defina
que o arquivo poderá crescer até o máximo de 100 MB. Clique em OK para fechar a janela
Change Autogrowth.
11. Agora vamos definir a pasta onde será gravado o arquivo secundário. Por padrão, o SQL Server
2005 sugere o seguinte caminho: C:\Arquivos de programas\Microsoft SQL Server\MSSQL.1\
MSSQL\DATA. Vamos alterar o caminho para: C:\livrosql\exemplo1. Você pode digitar este
caminho diretamente, ou clicar no botão com as reticências, para selecionar o caminho com o
mouse e deixar que o SQL Server 2005 preencha esta coluna, com o caminho selecionado. Suas
configurações devem estar conforme indicado na Figura 3.28.
Figura 3.28 Arquivos primário e secundário, já configurados.
O passo final é a definição do arquivo de log C:\livrosql\exemplo1\exemplo1-log.ldf. Este arquivo já

vem com definições padrão, na linha logo abaixo de onde foi definido o arquivo primário. Vamos criar
um arquivo de log com as seguintes características:
♦ Tamanho inicial: 5 MB.
♦ Crescimento automático em incrementos de 10%.
♦ Poderá crescer até o máximo de 40 MB.
12. Observe que na coluna File Type já vem selecionado Log e na coluna Filegroup vem selecionada
a opção Not Applicabe. Na colunia Initial Size (MB), digite 5. Clique no botão de reticências, ao
lado da opção de Autocrescimento, para abrir a janela Change Autogrowth e selecione um
Crescimento automático em incrementos de 10% e defina que o arquivo poderá crescer até o
máximo de 40 MB. Clique em OK para fechar a janela Change Autogrowth.
13. Agora vamos definir a pasta onde será gravado o arquivo de log. Por padrão, o SQL Server 2005
sugere o seguinte caminho: C:\Arquivos de programas\Microsoft SQL Server\MSSQL.1\MSSQL\
DATA. Vamos alterar o caminho para: C:\livrosql\exemplo1. Você pode digitar este caminho
diretamente, ou clicar no botão com as reticências, para selecionar o caminho com o mouse e
deixar que o SQL Server 2005 preencha esta coluna, com o caminho selecionado. Suas
configurações devem estar conforme indicado na Figura 3.29.
Figura 3.29 Configurações para o Banco de Dados Exemplo1.

NOTA
Poderíamos usar as demais guias – Options, Filegroups e Extended Properties para definir opções avançadas do Banco de Dados. Para este
primeiro exemplo, estas guias não serão utilizadas.
A pasta C:\livrosql\exemplo1 já deve ter sido criada, se não será gerado um erro na hora de criar o Banco de Dados Exemplo1.
13. Dê um clique no botão OK, e após alguns segundos o Banco de Dados Exemplo1 terá sido criado.
14. Agora vamos nos certificar de que o Banco de Dados Exemplo1 foi, efetivamente, criado. Na
janela Object Explorer clique no sinal de + ao lado da opção Databases, abaixo da instância na
qual o Banco de Dados foi criado. Na lista de Banco de Dados já deverá ser exibido o Banco de
Dados Exemplo1. Dê um clique neste Banco de Dados, para exibir as suas propriedades, no
painel da direita, conforme indicado na Figura 3.30:
Figura 3.30 O Banco de Dados Exemplo1, recém-criado.

NOTA
Caso o Banco de Dados Exemplo1 ainda não esteja aparecendo na listagem, clique com o botão direito do mouse na opção Databases e no
menu de opções que surge clique em Atualizar (Refresh).
14. Após termos criado um Banco de Dados, podemos, facilmente, adicionar novos arquivos de
dados ou de log. Para isso basta clicar com o botão direito do mouse no nome do Banco de
Dados e no menu que surge selecionar Propriedades. Será exibida a janela de propriedades do
Banco de Dados. Basta clicar na guia Files, para ter acesso às opções de alterações dos arquivos
existentes e de adição de novos arquivos secundários.
Agora que já sabemos criar um Banco de Dados utilizando o Enterprise Manager, vamos propor um
pequeno exercício para o amigo leitor fixar os conceitos apresentados.
Exercício proposto: Acesse as propriedades do Banco de Dados Exemplo1 e crie mais um arquivo
secundário e um arquivo de log, conforme definido a seguir. Para isso basta clicar com o botão
direito do mouse no Banco de Dados Exemplo1 e, no menu de opções que é exibido, clicar em
Propriedades. Na janela de propriedades que é exibida, clique na guia Files. Agora é só usar o botão
Add, para adicionar novos arquivos e configurar as propriedades de cada novo arquivo, conforme
definições da Tabela 3.1:
Tabela 3.1 Criando arquivos adicionais, no banco de dados Exemplo1.
Arquivo Definições
Secundário C:\livrosql\Exemplo1\exemplo1-sec2.ndf.
Crescimento automático habilitado.
Tamanho inicial: 5 MB.
Crescimento em incrementos de 5 %.
Tamanho máximo de 20 MB.
Arquivo de log C:\livrosql\Exemplo1\exemplo1-log2.ldf.
Crescimento em incrementos de 1 MB.
Exercício: Criar o Banco de Dados indicado na Tabela 3.2, utilizando os passos que você aprendeu no
exemplo prático anterior. O Banco de Dados será chamado de Exemplo2 e será criado na instância
SERVIDOR\SQL2005 (use a instância que você tem disponível, no seu computador). Os arquivos do
Banco de Dados Exemplo2 serão gravados na pasta: C:\livrosql\Exemplo2. Lembre-se de que esta
pasta já deve ter sido criada, antes que o Banco de Dados possa ser criado, se não será gerado um erro
na hora da criação do Banco de Dados.
Tabela 3.2 O banco de dados Exemplo2.
Primário C:\livrosql\Exemplo2\exemplo2-prim.ndf.
Então mãos à obra. Em caso de dúvidas sobre a criação do Banco de Dados Exemplo2, é só entrar em
contato, pelo e-mail: webmaster@juliobattisti.com.br
Observação importante sobre o crescimento automático de arquivos.
Vamos falar um pouco mais sobre o crescimento automático dos arquivos – primário, secundário e de
log – de um Banco de Dados. Por exemplo, vamos supor que estejamos criando um Banco de Dados
com as características indicadas na Tabela 3.3.
Tabela 3.3 Algumas questões sobre espaço em disco.
Primário C:\livrosql\qualeur\qualquer-prim.mdf.
Secundário C:\livrosql\qualquer\qualquer-sec1.ndf.
Arquivo de log C:\livrosql\qualquer\qualquer-log1.ldf.
Vamos responder às seguintes questões:
1) Ao criarmos este Banco de Dados, quanto ele estará, inicialmente, ocupando de espaço em disco?
R: 19 MB. Este valor é a soma dos tamanhos iniciais do arquivo primário (5 MB), mais todos os arquivos
secundários, que no caso temos apenas um (7 MB), mais todos os arquivos de log, que no nosso
exemplo temos apenas um (7 MB).
Com isso podemos concluir que um arquivo (primário, secundário ou de log) de um Banco de Dados do
SQL Server, é criado com o seu tamanho inicial. Este tamanho vai aumentando, conforme definido pelas
configurações de autocrescimento, à medida que mais espaço vai sendo necessário no Banco de Dados.
2) Qual o tamanho máximo que pode atingir este Banco de Dados?
Esta parece e é fácil. Basta somar os tamanhos máximos que cada arquivo pode atingir. No nosso
exemplo, teríamos: 10+15+25 = 50 MB. Porém, se a pergunta fosse um pouco diferente, como: Qual o
tamanho máximo para dados deste Banco de Dados? Neste caso devemos desconsiderar os arquivos de
log, nos quais ficam registradas apenas as operações realizadas sobre os dados.
A utilização do crescimento automático juntamente com a definição de tamanho máximo são

mecanismos importantes para o administrador do Banco de Dados. O crescimento automático facilita
a vida do DBA – Database Administrator, pois dispensa o administrador de ter que aumentar,
manualmente, o tamanho dos arquivos do Banco de Dados, sempre que o tamanho máximo fosse
atingido. A definição de um tamanho máximo também é recomendada, pois evita que, devido a alguma
operação com problemas, devido a algum erro de programação, todo o espaço do disco seja preenchido.
VERIFICAÇÃO DOS ARQUIVOS CRIADOS PARA

O EXEMPLO1 E PARA O EXEMPLO2
Vamos fazer uma pequena verificação, para conferir se os arquivos dos Bancos de Dados Exemplo1 e
Exemplo2 foram realmente criados (os arquivos do Banco de Dados Exemplo2 somente serão criados
se você concluiu o exercício proposto anteriormente):
1. Abra o Windows.
2. Navegue até a pasta C:\livrosql.
Devem aparecer as pastas Exemplo1 e Exemplo2.
3. Dê um clique na pasta Exemplo1. No painel da direita devem ser exibidos os arquivos do

Banco de Dados Exemplo1, conforme indicado na Figura 3.31:
Figura 3.31 Os arquivos do Banco de Dados Exemplo1.
Observe o tamanho dos arquivos, o qual é exatamente o tamanho inicial quando da criação do Banco
de Dados Exemplo1: 10 MB para o arquivo primário (.mdf), 10 MB para o arquivo secundário (.ndf) e
5 MB para o arquivo de log (.log). Os arquivos continuam com o tamanho inicial pois nenhum dado
foi adicionado ao Banco de Dados Exemplo1. Nem mesmo tabelas foram criadas neste Banco de Dados
– mas isto é assunto para o próximo capítulo.
4. Clique na pasta exemplo2 e observe os arquivos presentes bem como o tamanho dos arquivos.
5. Feche o Windows Explorer.
FUNDAMENTOS EM: ENTENDER E UTILIZAR COMANDOS T-SQL

PRÉ-REQUISITOS
♦ Noções dos conceitos básicos sobre Bancos de Dados Relacionais.
METODOLOGIA
♦ Apresentação dos principais elementos e funções da janela para Execução de Comandos T-SQL, dentro do SQL Server Management Studio.
TÉCNICA
♦ Aprender através de exemplos práticos.
Já falamos algumas vezes sobre a ferramenta Query Analyzer, a qual era utilizada no SQL Server 2000.
O Query Analyzer era a ferramenta usada para a execução de comandos T-SQL. No SQL Server 2005, o
Query Analyzer deixou de existir e, dentro do próprio SQL Server Management Studio, podemos abrir
uma janela para execução de comandos T-SQL (na verdade esta janela, aberta dentro do SQL Server
Management Studio, é muito parecida, em funcionalidade, com o que era o Query Analyzer no SQL
Server 2000). Na verdade, na opinião deste autor, no SQL Server 2005, simplesmente o Query Analyzer
deixou de ser uma ferramenta separada e teve a sua funcionalidade embutida dentro do SQL Server
Management Studio. Neste item, veremos a janela para execução de comandos T-SQL, dentro do SQL
Server Management Studio.
É possível, literalmente, executar qualquer ação, usando comandos T-SQL. Criar Bancos de Dados,
configurar Bancos de Dados, criar tabelas, chaves primárias, relacionamentos entre tabelas, criar
consultas, etc. Qualquer ação do SQL Server 2005 é possível de ser executada, usando comandos T-
SQL. A idéia básica de execução dos comandos é que cada comando é executado em relação a um
determinado objeto. Por exemplo, um comando T-SQL para criação de um novo Banco de Dados é
executado em uma instância do SQL Server 2005. Um comando T-SQL para criar uma nova tabela é
executado em um Banco de Dados. Um comando T-SQL para definir permissões de acesso para um ou
mais usuários, para os dados de uma determinada tabela, é executado na tabela e assim por diante.
Com isso, temos uma regra geral para abrir uma janela para execução de comandos T-SQL, em relação
a um determinado objeto do SQL Server 2005. Por exemplo, se você quer executar um comando em
uma instância do SQL Server 2005, abra o SQL Server Management Studio, clique com o botão direito
do mouse na referida instância, na janela Object Explorer e, no menu de opções que é exibido, clique
em New Query. Se você quer executar um comando T-SQL em um Banco de Dados, clique com o botão
direito do mouse no Banco de Dados, na janela Object Explorer e, no menu de opções que é exibido,
clique em... adivinhe: New Query. A idéia básica é essa, localize o objeto sobre o qual serão executados
os comandos T-SQL, clique com o botão direito do mouse neste objeto e, no menu de opções que é
exibido, clique em New Query. Será aberta uma janela para execução de comandos T-SQL, no painel da
direita do SQL Server Management Studio, conforme exemplo da Figura 3.32:
Observe, no título da janela de execução de comandos, que é informado com qual objeto você está
conectado. No exemplo da Figura 3.32, com o Banco de Dados Exemplo1, da instância
SERVIDOR\SQL2005.
Por padrão, a conexão para execução de comandos é feita com a mesma conta com a qual você se
conectou com o SQL Server Management Studio. Caso a conta que você esteja utilizando não tenha
permissão para executar comandos no objeto selecionado, será solicitado que você informe uma conta
e a respectiva senha, conta esta que deve ter as permissões para execução de comandos, no objeto
selecionado. Estas informações são necessárias, pois não são todos os usuários que têm acesso a todos
os objetos de uma instância do servidor SQL.
Figura 3.32 Janela para execução de comandos T-SQL, no Banco de Dados Exemplo1.
A janela de execução fornece um espaço, para que você digite o comando a ser executado. Claro que
até este momento você conhece somente o básico dos comandos T-SQL, os quais foram apresentados
no Capítulo 1. Ao longo deste livro, você aprenderá uma grande quantidade de comandos. E muitos
outros ainda existem, os quais, por falta de espaço (se não o livro ficaria com umas 10 mil páginas),
não têm como ser abordados em um único livro. No Books Online, você encontra uma referência
completa e detalhada, com exemplos, sobre todos os comandos T-SQL disponíveis no SQL Server
2005. E são, literalmente, milhares de comandos.
Os comandos T-SQL podem ser digitados diretamente no que eu chamo de área de trabalho, que é
onde está o cursor piscando. A melhor maneira de vermos a janela de execução de comandos em
funcionamento é através de um exemplo prático.
Vamos começar executando uma consulta simples, a qual retorna todos os registros da tabela
HumanResources.Employee, do Banco de Dados AdventureWorks, o qual é o Banco de Dados de
exemplos, instalado com o SQL Server 2005. Para isso precisamos fazer o seguinte:
Então vamos, passo a passo, fazer o exemplo proposto.
Exemplo prático: Executando uma consulta simples, usando a janela de execução de comandos T-SQL,
do SQL Server Management Studio.
Para executar um comando, que retorna todos os registros da tabela HumanResources.Employee, do

Banco de Dados AdventureWorks, siga os passos indicados a seguir:
1. Faça o logon com uma conta com permissão de administrador.
2. Abra o SQL Server Management Studio.
3. Na janela Object Explorer, clique no sinal de + ao lado da instância SERVIDOR\SQL2005, para

exibir as opções disponíveis.
4. Clique no sinal de + ao lado da opção Databases, para exibir os Bancos de Dados disponíveis
nesta instância do SQL Server 2005.
5. Na lista de Banco de Dados, clique com o botão direito do mouse no Banco de Dados
AdventureWorks e, no menu de opções que é exibido, clique em New Query. A janela para
execução de comandos será aberta e exibida na área central do SQL Server Management Stu-
dio. Observe que a janela já vem conectada com o Banco de Dados AdventureWorks, pois foi
neste Banco de Dados que você clicou com o botão direito do mouse.
6. Na janela de execução de comandos T-SQL, digite o seguinte comando:

SELECT * FROM HumanResources.Employee
Observe que à medida que você digita, o SQL Server 2005 vai colocando os comandos e nome de
tabelas em cores diferentes. Isto significa que o comando que você está digitando está sendo entendido.
Caso o nome de um comando não fique colorido após a digitação, significa que o comando não foi
entendido. Provavelmente você deve ter cometido um erro de digitação.
7. Após ter digitado o comando, pressione F5 para executá-lo. Ao invés de F5 você pode pressionar
Ctrl+E para executar os comandos que foram digitados.
O resultado da execução deste comando é uma listagem com todos os registros da tabela
HumanResources.Employee do Banco de Dados AdventureWorks, conforme indicado na Figura 3.33:
Observe que, na parte de baixo da janela, temos duas guias: Results, que é onde são exibidos os resultados
de uma consulta; e Messages, que é onde serão exibidas mensagens. No caso de a consulta ter sido
executada com sucesso, a mensagem limita-se ao número de linhas que foram retornadas, como por
exemplo:
(290 row(s) affected)
para o caso de termos digitado um comando com erros a mensagem descreve o tipo de erro. Por
exemplo o comando:
SELECT * FROM HumanResources.Employeexx
irá retornar a seguinte mensagem de erro:
Msg 208, Level 16, State 1, Line 1
Invalid object name ‘HumanResources.Employeexx’.
Figura 3.33 Resultado da execução do comando T-SQL.
Neste caso digitei o nome da tabela incorretamente. Como não existe uma tabela chamada
HumanResources.Employeexx, no Banco de Dados AdventureWorks, não foi possível executar o
comando e foi emitida a mensagem de erro informando o motivo.
Mas a janela para execução de comandos T_SQL não se limita à execução de comandos T-SQL simples,
para consultas. Na verdade, a linguagem T-SQL é bastante poderosa. Podemos criar um Banco de Dados
e todos os seus objetos, simplesmente utilizando comandos T-SQL. No próximo item, veremos como
criar um Banco de Dados e depois alterá-lo, utilizando comandos T-SQL.
Existe um comando que permite que seja alterado o Banco de Dados padrão dentro da própria seqüência
de comandos T-SQL. Por exemplo, vamos supor que o Banco de Dados atual seja o AdventureWorks e você
deseja executar uma instrução SQL no banco master. Poderíamos utilizar a seguinte seqüência de comandos
para, primeiro, alternarmos para o Banco de Dados master e, depois, executarmos uma instrução SQL nele.
USE master
SELECT * FROM SYS.TABLES
Todos os comandos SQL que aprendemos no Capítulo 1 podem ser executados nesta janela de execução
de código. Por exemplo, vamos executar uma consulta no Banco de Dados NorthWind (você ainda
não tem este Banco de Dados no SQL Server 2005. Mostrarei como importar este Banco de Dados, no
capítulo sobre o DTS, onde falarei sobre importação e exportação de dados com o SQL Server 2005), a
qual retorna apenas os clientes (Customers) mexicanos, isto é, em que o campo Country possui o valor
Mexico. Para isso poderíamos utilizar o seguinte comando:
USE NORTHWIND
SELECT * FROM CUSTOMERS WHERE COUNTRY=‘Mexico’
Neste caso, serão retornados apenas cinco registros, isto é, apenas os registros para os clientes mexicanos.
Existem muitas outras funcionalidades nesta janela de execução de comandos. Vamos trabalhar com
muitas destas funcionalidades ao longo deste livro. A janela para execução de comandos T-SQL é de
grande utilidade para que o DBA possa executar comandos diretamente nos Bancos de Dados do SQL
Server. Conforme aprenderemos ao longo deste livro, existe uma série de comandos para manutenção
e otimização dos elementos de um Banco de Dados do SQL Server; comandos estes que podem ser
executados através da janela de execução de código. Para fechar esta janela, basta clicar no x no lado
direito da janela (não no x bem em cima, se não você irá fechar o SQL Server Management Studio).
Podemos inserir comentários nos comandos T-SQL. Utilizar comentários sempre é uma boa prática de programação. Um comando T-SQL com
NOTA
muitas linhas pode ser gravado em um arquivo de texto e depois carregado na janela de execução de código para futuras execuções. Desta
forma não precisamos digitar o comando, ou conjunto de comandos, cada vez que estes precisarem ser executados. Para inserir comentários
em um comando T-SQL, basta iniciar a linha do comentário com dois traços, como no exemplo a seguir:
— Este comando retorna apenas os clientes do México
USE NORTHWIND
SELECT * FROM CUSTOMERS WHERE COUNTRY=‘México’
Cada linha de comentário deve iniciar com —.

Caso você queira inserir um comentário com várias linhas, sem precisar iniciar cada linha com —, podemos utilizar os caracteres /* para
iniciar o bloco de comentários e */ para finalizar o bloco de comentários, conforme indicado no exemplo a seguir:
/*
Nesta rotina, iremos extrair dados de diversas tabelas e consolidá-los de acordo com o Código do Produto, Código do Vendedor e Região de Vendas.
No Final, os dados serão inseridos em uma tabela temporária chamada temp_result, no Banco de Dados Consolidado
*/
USE ...
SELECT * ...
FUNDAMENTOS EM: CRIAÇÃO DE BANCOS

DE DADOS USANDO COMANDOS T-SQL
PRÉ-REQUISITOS
♦ Noções dos conceitos básicos sobre Bancos de Dados relacionais.
♦ Saber utilizar a janela para execução de comandos T-SQL.
♦ Conhecer a estrutura de armazenamento de um Banco de Dados do SQL Server 2005.
METODOLOGIA
♦ Apresentação dos comandos T-SQL para criação de Bancos de Dados.
TÉCNICA
♦ Criação de Bancos de Dados utilizando os comandos apresentados.
Para criarmos um Banco de Dados, utilizamos o comando CREATE DATABASE. A seguir temos a sintaxe
para este comando, conforme descrito no Books Online:
CREATE DATABASE database_name

[ ON
[ < filespec > [ ,...n ] ]
[ , < filegroup > [ ,...n ] ]
]
[ LOG ON { < filespec > [ ,...n ] } ]
[ COLLATE collation_name ]
[ FOR LOAD | FOR ATTACH ]
< filespec > ::=
[ PRIMARY ]
( [ NAME = logical_file_name , ]
FILENAME = ‘os_file_name’
[ , SIZE = size ]
[ , MAXSIZE = { max_size | UNLIMITED } ]
[ , FILEGROWTH = growth_increment ] ) [ ,...n ]
< filegroup > ::=
FILEGROUP filegroup_name < filespec > [ ,...n ]
Este formato genérico não é muito intuitivo e nem de fácil entendimento. Vamos simplificar um
pouco. A seguir, apresento uma sintaxe simplificada, somente com as opções necessárias para criar o
Banco de Dados, com um arquivo primário, um arquivo secundário e um arquivo de log:
CREATE DATABASE NOME_DO_BANCO_DE_DADOS

ON
— *************************
— Definição do Arquivo Primário
— *************************
(NAME= Nome_Lógico_Arquivo_Primário,
FILENAME = ‘Caminho para gravar o arquivo, por ex. C:\livrosql\exemplo3\ex3-prim.mdf’,
SIZE= Tamanho_Inicial,
MAXSIZE= Tamanho_Máximo_Admitido,
FILEGROWTH = Incremento),
— ***************************
— Definição do Arquivo Secundário
— ***************************
(NAME= Nome_Lógico_Arquivo_Secundário,
FILENAME = ‘Caminho para gravar o arquivo, por ex. C:\livrosql\exemplo3\ex3-sec.ndf’,
FILEGROWTH = Incremento)
— *************************
— Definição do Arquivo de Log
— *************************
LOG ON
(NAME= Nome_Lógico_Arquivo_Log,
FILENAME = ‘Caminho para gravar o arquivo, por ex. C:\livrosql\exemplo3\ex3-log.ldf’,
— ***************************************
— Final do comando de criação do Banco de Dados
— ***************************************
NOTA
Lembrando que as linhas que iniciam com — são linhas de comentário, cujo objetivo é tornar a leitura e interpretação do comando T-SQL mais fáceis.
Agora vamos utilizar um comando que cria um Banco de Dados chamado Exemplo3, com as
características definidas na Tabela 3.4. Os arquivos primário, secundário e de log deverão ser salvos em
C:\livrosql\exemplo3.
Tabela 3.4 Banco de dados Exemplo3.
Primário C:\livrosql\exemplo3\exemplo3-prim.mdf.
Secundário C:\livrosql\exemplo3\exemplo3-sec1.ndf.
Arquivo de log C:\livrosql\exemplo3\exemplo3-log1.ldf.
Exemplo prático: Criar o Banco de Dados Exemplo3, com as definições dadas pela Tabela 3.4. Criar o
Banco de Dados na instância SERVIDOR\SQL2005 (ou utilize uma instância disponível no computador
que você está usando).

4. Clique com o botão direito do mouse na instância SERVIDOR\SQL2005 e, no menu de opções

que é exibido, clique em New Query. Será aberta a janela para execução de comandos T-SQL, já
descrita anteriormente.
5. Digite o seguinte comando, o qual irá criar o Banco de Dados Exemplo3, com as definições da
Tabela 3.4:
CREATE DATABASE Exemplo3

ON
— *************************
— *************************
(NAME= exemplo3_prim,
FILENAME = ‘C:\livrosql\exemplo3\exemplo3-prim.mdf ‘,
SIZE= 7MB,
MAXSIZE= 25MB,
FILEGROWTH = 1MB),
— ***************************
— ***************************
(NAME= exemplo3_sec1,
FILENAME = ‘C:\livrosql\exemplo3\exemplo3-sec1.ndf ‘,
SIZE= 10MB,
MAXSIZE= 50MB,
FILEGROWTH = 10%)
— *************************
— *************************
LOG ON
(NAME= exemplo3_log1,
FILENAME = ‘C:\livrosql\exemplo3\exemplo3-log1.ldf ‘,
SIZE= 7MB,
MAXSIZE= 25MB,
FILEGROWTH = 2MB)
— ***************************************
— ***************************************
Veja que estamos utilizando o caractere de sublinhado _ para os nomes lógicos, pois não podemos utilizar o sinal -, o qual não é um caractere
NOTA
válido para um nome lógico. Se utilizarmos o sinal - , ao executarmos o comando obteremos a seguinte mensagem de erro:
Server: Msg 170, Level 15, State 1, Line 14
Line 14: Incorrect syntax near ‘-’.
Importante: Antes de executar este comando, a pasta C:\livrosql\exemplo3 já deve ter sido criada, caso contrário será exibida a seguinte
mensagem de erro:
Device activation error. The physical file name ‘C:\livrosql\exemplo3\exemplo3-prim.mdf’
may be incorrect.
CREATE DATABASE failed. Some file names listed could not be created. Check previous errors.
Ao executar este comando, se você não tiver cometido nenhum erro de digitação, o Banco de Dados
Exemplo3 terá sido criado e a seguinte mensagem será exibida na guia Messages:
Command(s) completed successfully.
Com isso o nosso Banco de Dados Exemplo3 foi criado, com as características definidas na Tabela 3.4.
Mantenha o SQL Server Management Studio aberto.
Agora vamos verificar se o Banco de Dados Exemplo3 foi realmente criado.
Exemplo prático: Verificando se o Banco de Dados Exemplo3 foi realmente criado:
1. Abra o SQL Server Management Studio (já deve estar aberto do exemplo anterior).
2. Na janela Object Explorer, clique no sinal de mais ao lado da instância SERVIDOR\SQL2005

para expandi-la (use a instância disponível no computador que você está utilizando).
3. Clique no sinal de mais ao lado de Databases para expandi-la.
4. Observe que o Exemplo3 já deve aparecer na listagem de Banco de Dados. Caso o Banco de
Dados Exemplo3 ainda não esteja sendo exibido, clique na opção Databases para selecioná-la
e pressione a tecla F5 para atualizar a visão.
Vamos fazer mais algumas observações sobre o comando CREATE DATABASE.
♦ Os tamanhos para os parâmetros SIZE e MAXSIZE podem ser definidos em kilobyte (KB), mega-
byte (MB), gigabyte (GB) ou terabyte (TB). O padrão é MB, isto é, se não for especificada a
unidade, o número é considerado em MB.
♦ O parâmetro FILEGROWTH, o qual especifica o incremento para o crescimento automático,
pode ser definido em valores absolutos (KB, MB, GB ou TB) ou em valores percentuais, como
por exemplo: 10%, 15%, etc.
♦ O número máximo de Bancos de Dados que podemos ter em uma instância do SQL Server é
32.767.
♦ Não podemos especificar valores decimais para os parâmetros SIZE, MAXSIZE e FILEGROWTH.
Por exemplo, não posso ter SIZE = 2,5 MB. Ao invés disso devo fazer uma pequena conta. Por
exemplo: Cada MB possui 1024 KB, logo 2,5 MB = 2,5 x 1024 = 2560. Agora basta especificarmos
SIZE = 2560KB.
Agora vamos aprender a utilizar o comando CREATE DATABASE com a opção de colocar alguns arquivos
do Banco de Dados em outro filegroup que não o primário. Nos exemplos anteriores, como não
especificamos em qual filegroup os arquivos (primário ou secundário) deveriam ser criados, estes fo-
ram criados no filegroup padrão que é o Primary Filegroup. Lembrando que filegroup é simplesmente
um conceito que permite agruparmos, logicamente, um conjunto de arquivos e até mesmo tabelas e
índices. Este agrupamento lógico pode ser utilizado para facilitar a distribuição dos arquivos ao longo
de vários discos, facilitar as rotinas de backup, etc. Vamos aprender estas opções com o auxílio de um
exemplo um pouco mais complexo do que os anteriores.
Exemplo prático: Utilizar o comando CREATE DATABASE para criar um Banco de Dados chamado
Exemplo4, com as características indicadas na Tabela 3.5.
Tabela 3.5 Banco de dados Exemplo4.
Primário C:\livrosql\exemplo4\exemplo4_prim.mdf.
Crescimento em incrementos de 15%.
No filegroup Primary.
Secundário C:\livrosql\exemplo4\exemplo4_sec1.ndf.
No filegroup Primary.
No filegroup SalesGroup1.
No filegroup SalesGroup1
Arquivo de log C:\livrosql\exemplo4\exemplo4_log.ldf.
Observe que os arquivos serão salvos na pasta C:\livrosql\exemplo4. Criaremos o Banco de Dados
Exemplo4 na instância SERVIDOR\SQL2005. Também nunca é demais lembrar que a pasta
C:\livrosql\exemplo4 já deve existir, antes que o comando Create Database seja executado, se não o
comando irá falhar e será gerada uma mensagem de erro.
Para criar o Banco de Dados Exemplo4, com as características definidas na Tabela 3.5, siga os passos
indicados a seguir:


5. Digite o seguinte comando:
CREATE DATABASE Exemplo4

— Especifica o filegroup Primary
ON PRIMARY
( NAME = exemplo4_prim,
FILENAME = ‘C:\livrosql\exemplo4\exemplo4_prim.mdf’,
SIZE = 10,
MAXSIZE = 50,
FILEGROWTH = 15% ),
( NAME = exemplo4_sec1,
FILENAME = ‘C:\livrosql\exemplo4\exemplo4_sec1.ndf’,
SIZE = 10,
MAXSIZE = 50,
FILEGROWTH = 15% ),
— Os próximos arquivos serão associados com
— Filegroup SalesGroup1
FILEGROUP SalesGroup1
SIZE = 10,
MAXSIZE = 50,
FILEGROWTH = 5 ),
SIZE = 10,
MAXSIZE = 50,
FILEGROWTH = 5 ),
— Os próximos arquivos serão associados com
— Filegroup SalesGroup2
FILEGROUP SalesGroup2
SIZE = 10,
MAXSIZE = 50,
FILEGROWTH = 5 ),
SIZE = 10,
MAXSIZE = 50,
FILEGROWTH = 5 )
LOG ON
( NAME = exemplo4_log,
FILENAME = ‘C:\livrosql\exemplo4\exemplo4_log.ldf’,
SIZE = 5MB,
MAXSIZE = 25MB,
FILEGROWTH = 5MB )
Vamos repetir esta observação porque ela é importante. Veja que estamos utilizando o caractere de sublinhado _ para os nomes lógicos, pois
NOTA
não podemos utilizar o sinal de menos -, o qual não é um caractere válido para um nome lógico. Se utilizarmos o sinal - , ao executarmos o
comando obteremos a seguinte mensagem de erro:
Line 14: Incorrect syntax near ‘-’.
Vamos repetir este aviso porque o mesmo é importante: Antes de executar este comando, a pasta C:\livrosql\exemplo4 já deve ter sido
criada, caso contrário será exibida uma mensagem de erro.
Exemplo4 terá sido criado e a seguinte mensagem é exibida na guia Messages:
Esta mensagem é a confirmação de que o Banco de Dados foi criado com sucesso.
Agora vamos verificar se o Banco de Dados Exemplo4 foi realmente criado.
Exemplo prático: Verificando se o Banco de Dados Exemplo4 foi realmente criado:
1. Abra o SQL Server Management Studio (já deve estar aberto do exemplo anterior).

para expandi-la (use a instância disponível no computador que você está utilizando).
4. Observe que o Banco de Dados Exemplo4 já deve aparecer na listagem de Banco de Dados.
Caso o Banco de Dados Exemplo ainda não esteja sendo exibido, clique na opção Databases
para selecioná-la e pressione a tecla F5 para atualizar a visão.
Agora que aprendemos a utilizar o comando CREATE DATABASE, vamos aprender mais alguns comandos
T-SQL para o trabalho com Bancos de Dados.
FUNDAMENTOS EM: ALTERAÇÃO DE BANCOS

DE DADOS USANDO COMANDOS T-SQL
PRÉ-REQUISITOS
METODOLOGIA
♦ Apresentação dos comandos T-SQL para alteração de Bancos de Dados.
TÉCNICA
♦ Alteração de Bancos de Dados utilizando os comandos apresentados.
Com o comando ALTER DATABASE podemos fazer uma série de alterações em um Banco de Dados,
como por exemplo adicionar arquivos secundários e arquivos de log. A seguir, temos a sintaxe oficial,
segundo o Books OnLine, para o comando ALTER DATABASE:
ALTER DATABASE database

{ ADD FILE < filespec > [ ,...n ] [ TO FILEGROUP filegroup_name ]
| ADD LOG FILE < filespec > [ ,...n ]
| REMOVE FILE logical_file_name
| ADD FILEGROUP filegroup_name
| REMOVE FILEGROUP filegroup_name
| MODIFY FILE < filespec >
| MODIFY NAME = new_dbname
| MODIFY FILEGROUP filegroup_name {filegroup_property | NAME = new_filegroup_name }
| SET < optionspec > [ ,...n ] [ WITH < termination > ]
| COLLATE < collation_name >
}
Como a sintaxe descrita na documentação oficial não é o que se possa chamar de muito amistosa e
nem de fácil entendimento, vamos aprender a utilizar este comando através de exemplos práticos.
Exemplo prático: Alterar o Banco de Dados Exemplo3, criado anteriormente, adicionando um arquivo
secundário e um arquivo de log, conforme orientações da Tabela 3.6
Tabela 3.6 Alterando o Banco de Dados Exemplo3.
Adicionar C:\livrosql\exemplo3\exemplo3-sec1.ndf.
Secundário Crescimento automático habilitado.
Adicionar C:\livrosql\exemplo3\exemplo3-log2.ldf.
Arquivo de log Crescimento automático habilitado.
Para alterar o Banco de Dados Exemplo3, siga os passos indicados a seguir:

exibir as opções disponíveis (utilize uma instância do SQL Server 2005, disponível no
computador que você está utilizando).
ALTER DATABASE Exemplo3

ADD FILE
(
NAME = exemplo3_sec2,
FILENAME = ‘c:\livrosql\exemplo3\exemplo3_sec2.ndf’,
SIZE = 12MB,
MAXSIZE = 65MB,
FILEGROWTH = 20%
)
GO
ADD LOG FILE
( NAME = exemplo3_log2,
FILENAME = ‘c:\livrosql\exemplo3\exemplo3_log2.ldf’,
SIZE = 7MB,
MAXSIZE = 25MB,
FILEGROWTH = 5%)
Observe que, após fecharmos o comando que adiciona um arquivo de dados - ADD FILE, precisamos inserir um comando GO, para que o
NOTA
primeiro arquivo ALTER DATABASE seja executado e o arquivo exemplo3_sec2.ndf seja adicionado. Após o GO é executado o segundo
comando ALTER DATABASE, agora para adicionar um arquivo de LOG. Não posso utilizar na mesma seqüência de comandos ALTER DATABASE
as opções ADD FILE e ADD LOG FILE. Por isso preciso de dois comandos ALTER DATABASE separados. A maneira de fazer com que mais do que
um comando seja executado de uma única vez é inserindo o comando GO.
6. Ao executar este comando, se você não tiver cometido nenhum erro de digitação, o Banco de
Dados Exemplo4 terá sido criado e a seguinte mensagem será exibida:
Esta mensagem é a confirmação de que o Banco de Dados Exemplo4 foi alterado com sucesso.
Vamos a mais um exemplo prático:
Exemplo prático: Como remover um arquivo de um Banco de Dados, usando comandos T-SQL:
No comando a seguir, estamos utilizando o comando ALTER DATABASE para remover o arquivo
exemplo3_log2 adicionado no exemplo anterior:
USE master
GO
REMOVE FILE exemplo3_log2
GO
Ao finalizar este comando é exibida a seguinte mensagem:
The file ‘exemplo3_log2’ has been removed.
Observe que o nome utilizado é o nome lógico e não o nome do arquivo e disco
(C:\livrosql\exemplo3\exemplo3_log2.ndf). Bem, já estava na hora de apresentarmos alguma utilidade
para o nome lógico do arquivo. A utilidade é exatamente esta, podemos nos referir ao nome lógico do
arquivo nos comandos T-SQL, o que, convenhamos, é bem mais fácil do que nos referir ao nome do
arquivo no disco.
Exemplo prático: Como modificar um arquivo de um Banco de Dados, usando comandos T-SQL?
No comando a seguir, eu utilizo o comando ALTER DATABASE para modificar o arquivo exemplo3_sec2
adicionado no exemplo anterior:
USE master
GO
MODIFY FILE
(NAME = exemplo3_sec2,
SIZE = 25MB)
GO
Ao finalizar este comando, é exibida a seguinte mensagem:
The command(s) completed successfully.
FUNDAMENTOS EM: EXCLUSÃO DE BANCOS DE DADOS

COM O QUERY ANALYZER E COM O ENTERPRISE MANAGER
PRÉ-REQUISITOS
♦ Conhecer e saber utilizar a interface do SQL Server Management Studio.
♦ Saber utilizar a janela de execução de comandos T-SQL.
METODOLOGIA
♦ Apresentação dos comandos T-SQL para exclusão de Bancos de Dados.
TÉCNICA
♦ Exclusão de Bancos de Dados utilizando os comandos apresentados.
Uma vez que um Banco de Dados não seja mais necessário, podemos excluir o Banco de Dados do
servidor SQL Server. A exclusão pode ser feita utilizando-se o SQL Server Management Studio ou o
comando DROP DATABASE.
Para excluir um Banco de Dados com o SQL Server Management Studio, basta localizar o Banco de
Dados a ser excluído, clicar com o botão direito do mouse sobre o Banco de Dados e, no menu de
opções que surge, clicar na opção Delete.
Surgirá uma janela pedindo confirmação, conforme indicado na Figura 3.34.
Figura 3.34 Confirmando a exclusão de um Banco de Dados.
Para excluir um Banco de Dados usando a janela de execução de comandos T-SQL, utilizamos o comando
DROP DATABASE, conforme ilustrado nos exemplos a seguir.
Para excluir o Exemplo4 utilize o seguinte comando:
DROP DATABASE Exemplo4
Ao executar este comando, no Query Analyzer, será exibida a seguinte mensagem:

NOTA
Ao excluir um Banco de Dados utilizando o comando DROP DATABASE, não será pedida confirmação. Fique atento a este detalhe.
Podemos excluir mais do que um Banco de Dados. Para isto basta separar o nome dos Bancos de Dados
a serem excluídos com vírgula, conforme indicado no exemplo a seguir:
DROP DATABASE Exemplo4, Exemplo3
Este comando irá excluir os Bancos de Dados Exemplo3 e Exemplo4. Se um dos Bancos de Dados a ser
excluído não existir, será gerada uma mensagem de erro, semelhante à indicada a seguir:
Cannot drop the database ‘Exemplo4’, because it does not exist or you do not have permission.
CONCLUSÃO
Neste capítulo você aprendeu uma série de conceitos importantes e que serão utilizados no restante
deste livro.
Mostrei como utilizar as duas principais ferramentas de administração do SQL Server 2005:
♦ SQL Server Management Studio.
♦ Janela para execução do comandos T-SQL.
Utilizamos o SQL Server Management Studio para navegar pelos principais componentes de um servidor
SQL Server 2005 e de um Banco de Dados. Também aprendemos a configurar as diversas opções de
uma instância do SQL Server 2005, como por exemplo o gerenciamento de memória, gerenciamento
dos processadores, segurança, etc.
Também vimos qual a estrutura de um Banco de Dados no SQL Server 2005, o qual é formado por uma
série de arquivos do sistema operacional, arquivos estes que podem ser de um dos seguintes tipos:
♦ Um arquivo de dados primário (Primary File).
♦ Um ou mais arquivos de dados secundários (Secondary File).
♦ Um ou mais arquivos de log (Log File).
Na seqüência, aprendemos sobre o sistema de armazenamento do Windows 2000 e do Windows Server

2003, bem como sobre as implementações de RAID.
Na parte final deste capítulo tratamos da criação e alteração de Bancos de Dados utilizando a interface
gráfica do SQL Server Management Studio e também comandos T-SQL executados na janela de execução
de comandos, a qual faz parte do SQL Server Management Studio.
Também aprendemos a alterar e excluir Bancos de Dados, utilizando o SQL Server Management Studio
e comandos T-SQL.
O próximo passo natural é aprendermos a criar e gerenciar os diversos elementos que compõem um
Banco de Dados. O primeiro elemento são as tabelas. Mas isso já é assunto para o Capítulo 4.
Capítulo 4
CRIANDO TABELAS, ÍNDICES E
VIEWS COM O SQL SERVER 2005
INTRODUÇÃO
No Capítulo 3, aprendemos a criar Bancos de Dados utilizando o SQL Server Management Studio e
também a janela para execução de comandos T-SQL. “Porém, um Banco de Dados em si não serve para
nada”. Não se assuste com a afirmação, pois é exatamente isso. Ou seja, só o banco de dados não serve
para “absolutamente nada”. Precisamos criar os diversos elementos que compõem o banco de dados,
para que este possa ter alguma utilidade. Neste capítulo aprenderemos sobre os seguintes elementos,
que fazem parte de um banco de dados:
♦ Tipos de dados
♦ Tabelas
♦ Índices
Iniciaremos o capítulo aprendendo sobre os tipos de dados predefinidos no SQL Server 2005. Conforme
explicarei em detalhes, cada coluna deve conter dados de um determinado tipo, por exemplo: Texto,
Números inteiros, Números reais, Data e hora, etc.
Na seqüência aprenderemos a criar tabelas em um Banco de Dados do SQL Server 2005. Utilizaremos o
SQL Server Management Studio e também comandos T-SQL. Veremos diversos exemplos de criação de
tabelas e definição dos campos que fazem parte da tabela. Também aprenderemos a definir as
propriedades de cada campo.
Uma vez criadas as tabelas, podemos aprender a definir índices para as tabelas. Também aprenderemos
a definir um campo como sendo a chave primária da tabela. Conforme será explicado, os índices
desempenham um papel muito importante no desempenho das consultas (views). Uma correta definição
dos índices pode ser um auxiliar valioso para obter um desempenho otimizado. Aprenderemos a criar
índices utilizando o SQL Server Management Studio e utilizando comandos T-SQL.
Após ter estudado este capítulo, o amigo leitor deverá estar habilitado para:
♦ Criar tabelas em um Banco de Dados do SQL Server 2005.
♦ Definir as características dos campos de uma tabela.
♦ Entender a importância da criação de índices para o desempenho de consultas.
♦ Saber criar índices utilizando as diversas ferramentas disponíveis.
Observe que, neste capítulo, iremos criar tabelas e índices. Não faremos a entrada de dados, inserindo registros nas tabelas que forem
NOTA
criadas neste capítulo. Conforme descrito anteriormente, o SQL Server 2005 não é um front-end para desenvolvimento de aplicações. A
entrada de dados em um Banco de Dados do SQL Server (ou do ORACLE, DB2 da IBM, etc.), normalmente, é feita através de formulários de
uma aplicação desenvolvida em Visual Basic, Delphi, ASP ou qualquer outra ferramenta de desenvolvimento capaz de se comunicar com um
Banco de Dados do SQL Server 2005.
CAPÍTULO 4 – CRIANDO TABELAS, ÍNDICES E VIEWS COM O SQL SERVER 2005
FUNDAMENTOS EM: PROJETO DE BANCO DE DADOS

E TIPOS DE DADOS DO SQL SERVER 2005
PRÉ-REQUISITOS
METODOLOGIA
♦ Apresentação dos tipos básicos do SQL Server 2005.
♦ Considerações sobre o projeto de Bancos de Dados.
Conforme vimos no Capítulo 1, antes de começarmos a criar um Banco de Dados, devemos fazer uma
análise bastante criteriosa para determinar quais as tabelas que farão parte do banco de dados; quais
campos farão parte de cada tabela; quais as propriedades de cada um dos campos; qual campo será a
chave primária de cada tabela; quais os relacionamentos entre as tabelas e as definições de Integridade
Referencial. O passo final é a aplicação das regras de normalização.
Uma vez definidos todos estes pontos, teremos o Diagrama Entidade x Relacionamentos, o qual serve
como um mapa para a estrutura do Banco de Dados. Neste capítulo iremos aprender a criar as tabelas
definidas no Diagrama Entidades x Relacionamentos.
Antes de criarmos as tabelas, vamos aprender sobre os tipos de dados disponibilizados pelo SQL Server
2005. O “tipo” do dado de um determinado campo define quais as informações que podem ser
armazenadas no campo. Por exemplo, um campo que é definido como Inteiro não poderá conter
caracteres nem números com decimais. Já um campo do tipo Data não irá aceitar uma entrada como:
30/02/2005, a qual é uma data inválida. Já se, ao invés de data, o campo fosse do tipo Texto, a entrada
30/02/2005 seria aceita. Observe que, ao definir um tipo para cada campo, já temos uma maneira de
limitar os valores que são aceitos para este campo. No projeto do Banco de Dados também definimos
os tipos dos diversos campos de cada tabela.
Na Tabela 4.1 temos os principais tipos de dados disponíveis no SQL Server 2005.
Tabela 4.1 Principais tipos de dados do SQL Server 2005.
Tipo Descrição Tamanho
bigint Um inteiro de 8 bytes. Seus valores variam 8 bytes

na seguinte faixa: -2^63
(-9,223,372,036,854,775,808) até 2^63 -1
(9,223,372,036,854,775,807)
binary(n) Um binário de tamanho fixo (n bytes), onde o n+4 bytes
valor máximo de n é 8000. Devemos utilizar este
tipo, quando os dados de uma coluna terão mais
ou menos o mesmo tamanho, como por exemplo
a foto de um funcionário.
Continua
Continuação
bit É um inteiro que somente pode conter os valores 0, 1 Variável. Depende do

ou NULL. Colunas com o tipo de dados bit não podem número de colunas.
ser indexadas. O Microsoft SQL Server 2005 otimizou o
espaço utilizado para armazenar valores do tipo bit. Por
exemplo, se em uma tabela houver até oito colunas com
dados do tipo bit, estas colunas serão armazenadas como
um byte; se houver entre 9 e 16 colunas do tipo com dados
do tipo bit, estas colunas serão armazenas como dois
bytes e assim por diante. Valores do tipo String, True e False
podem ser convertidos para dados do tipo Bit, sendo
True = 1 e False = 0.
char(n) Texto de tamanho fixo (n bytes), com caracteres não n bytes
Unicode. O valor máximo para n é 8000.
cursor Contém uma referência (ponteiro) para um cursor. Não aplicável.
Falaremos mais sobre cursores a partir do Capítulo 9.
datetime Data e hora na período de 01/01/1753 à 31/12/9999. 8 bytes
float(n) Um número decimal que pode variar de -1.79E+38 até 4 a 8 bytes
+1.79E+38. O valor n indica o número de bits utilizado dependendo da
para armazenar a mantissa do número e varia de 1 a 53. precisão
image Utilizado para dados binários de tamanho variável e 16 bytes por pointer
maiores do que 8000 bytes. Tem um tamanho
máximo de (2^31) -1 byte (cerca de 2 GB). Uma
coluna deste tipo é simplesmente um ponteiro para
a localização da imagem. Os dados da imagem são
armazenados separadamente dos dados da tabela.
integer Um inteiro variando de -(2^31) (-2.147.483.648) 4 bytes
ou int até (2^31)-1 (+.147.483.647)
money Valores monetários variando de -(2^63) 8 bytes
(-922.337.203.685.477,5808) até +(2^63)-1
(+922.337.203.685.477,5807).
nchar(n) Dados do tipo caractere, de tamanho fixo (n) com 2 x número de
caracteres Unicode. n pode variar de 1 até 4000. caracteres digitados
Caracteres Unicode utilizam 2 bytes por caractere, no campo.
mas em contrapartida suportam todos os caracteres
internacionais, tais como os utilizados no alfabeto
Chinês ou Árabe.
ntext Pode conter caracteres Unicode. É um campo de 16 bytes por
tamanho variável, podendo conter até (2^30) ponteiro, mais 2
caracteres (1.073.741.823 caracteres). A coluna bytes x número
do tipo ntext não contém os dados mas sim um caracteres digitados
ponteiro para o arquivo com os dados, os quais são para o campo.
armazenados separadamente dos dados da tabela.
nvarchar Pode conter caracteres Unicode. É um campo de 2 bytes vezes o
tamanho variável, com n variando de 1 até 4000. número de caracteres
digitados para o
campo.
real É um número decimal variando de –1.18E – 38 4 bytes
até 3.40E + 38. É o mesmo que float(24).
Continua
Continuação
smalldatetime Pode conter valores de data e hora, no 4 bytes

período de 01/01/1900 até 06/06/2079.
smallint Pode conter números inteiros na faixa de -(2^15) 2 bytes
(-32.768) até (2^15)-1 (32.767).
smallmoney Pode conter valores monetários na faixa de 4 bytes
-214.748,3648 até 214.748,3647.
sql_variant Permite valores de diferentes tipos. Variável
table Pode ser utilizada para tabelas temporárias, para Varia com a definição
definir uma variável local ou para retornar da tabela
valores a partir de uma função definida pelo usuário.
text Utilizado para valores de texto com tamanho 16 bytes por caractere
variável e maiores do que 8000 caracteres.
Pode conter até (2^31)-1.
timestamp Uma coluna do tipo timestamp é atualizada, 8 bytes
automaticamente, toda vez que uma linha for
inserida ou alterada. Podemos ter somente uma
coluna do tipo timestamp por tabela.
tinyint Inteiro variando de 1 até 255. 1 byte
unique-identifier Contém um binário de 16 bytes, o qual é um 16 bytes
globally unique identifier (GUID). Não são gerados
dois valores iguais, nunca, para um campo deste
tipo.
varbinary Pode conter um valor binário de tamanho Tamanho dos
variável de 1 até 8000 bytes. dados + 4 bytes
varchar(n) Pode conter dados do tipo caractere, não Unicode, Tamanho dos
variando n de 1 até 8000 caracteres no máximo. dados digitados
Dois novos tipos de dados foram disponibilizados com o SQL Server 2005: varbinary(max) e XML.
Vamos apresentar estes dois tipos, logo a seguir.
Um dado do tipo varbinary(n | max) pode conter dados binários, de tamanho variável. O valor de n
pode variar de 1 até 8000. Max indica o tamanho máximo de armazenamento, o qual é de 2^31 – 1
bytes. O espaço de armazenamento é igual ao tamanho do dado + 2 bytes. Quando o valor de n não for
especificado, será assumido como n=1. O uso de varbinary(n | Max) é indicado para colunas, cujo
tamanho dos dados varia muito de registro para registro. Quando o tamanho for mais ou menos fixo,
é mais indicado o uso do tipo binary. Também é recomendado o uso de varbinary(Max), quando o
tamanho dos dados exceder 8000 bytes.
Grande parte das melhorias do SQL Server 2005 são na área do tratamento e trabalho de dados no formato
XML. Uma das novidades é justamente a disponibilidade de um novo tipo possível para uma coluna,
justamente o tipo XML. Este tipo de dado permite que documentos XML ou partes de documentos sejam
gravados em colunas de uma tabela e que o formato XML seja mantido (o que evidentemente é o mais
importante). É possível a criação de colunas e também de variáveis de programação do tipo XML, as quais
poderão conter dados no padrão XML. Este é um grande avanço e uma novidade muito bem vinda, para
todos que precisam trabalhar com o padrão XML, no SQL Server 2005.
Para detalhes sobre os tipos de dados disponíveis no SQL Server 2005, você pode consultar o tópico
Transact-SQL Reference, no Books OnLine.
ALGUMAS DICAS PARA DEFINIR OS TIPOS DE DADOS PARA UMA COLUNA

Vamos ver algumas considerações que podem nos ajudar na escolha do tipo de dados mais adequado
para cada coluna.
O fator determinante na escolha do tipo de dados de uma coluna são os próprios dados a serem
armazenados na coluna. Por exemplo, se a coluna for armazenar a data de aniversário do cliente, na
tabela Clientes é obvio que o campo deve ser do tipo datetime, a menos que haja algum outro motivo.
Campos que irão conter valores devem ser do tipo respectivo, isto é, se o campo irá conter somente
números inteiros, podemos utilizar os tipos integer, smallint ou tinyint, dependendo da faixa de valores
esperados para o respectivo campo. Já se o campo contiver valores com decimais devemos optar pelos
tipos real, float ou money, dependendo da faixa de valores.
Embora pareçam considerações óbvias, muitas vezes são esquecidas na hora de projetar um Banco de
Dados. Vamos considerar um campo que deva armazenar valores de CPF, tendo o seguinte formato:
111.111.111-11
Se quisermos armazenar no Banco de Dados os pontos e o traço, não poderemos definir o campo CPF
como sendo do tipo integer, ao invés disso devemos defini-lo como sendo do tipo texto. Porém se
quisermos armazenar apenas os números podemos defini-lo como sendo do tipo integer. Outra questão
que surge é se podemos armazenar, no nosso exemplo, o campo CPF como do tipo texto e mesmo
assim fazer cálculos com este campo, como por exemplo calcular o DV – Dígito Verificador (dois
últimos dígitos) do CPF. Tecnicamente isto é possível, pois podemos utilizar funções que retornam
cada um dos caracteres do CPF e depois convertê-los para números de tal forma que possamos fazer os
cálculos necessários, usando programação (que seja programação T-SQL ou usando as linguagens do
Framework .NET, tais como VB.NET e C#, uma vez que o SQL Server 2005 é completamente integrado
com o Framework .NET). Porém este procedimento pode ocasionar processamento adicional, o que
prejudica o desempenho das aplicações que estão acessando o Banco de Dados.
Estas pequenas questões reforçam a idéia de que devemos fazer uma análise criteriosa na fase de projeto
do Banco de Dados.
Outro fator que devemos levar em consideração é se vamos utilizar campos de tamanho fixo ou cam-
pos de tamanho variável.
De uma maneira geral devemos utilizar campos de tamanho fixo se os dados de uma coluna tiverem
um tamanho que não varia muito. Quando os dados de uma coluna sofrem grandes variações de
tamanho, a utilização de um tipo de dados de tamanho fixo pode causar um desperdício de espaço em
disco. Vamos considerar o seguinte exemplo:
♦ Uma coluna do tipo texto.
♦ Definida com um tamanho fixo de 250 caracteres.
♦ A tabela possui 200.000 registros.
♦ Em média 80% dos registros armazenam apenas 50 caracteres neste campo, o qual foi definido
como tamanho de 250 por causa de alguns poucos registros em que o campo atinge este
tamanho.
Vamos calcular o desperdício:
♦ 80% de 200.000 registros = 160.000 registros
♦ 160.000 registros vezes um desperdício de 200 bytes por registro
♦ Desperdício total = 30,5 MB
Mantidas as mesmas proporções, se esta tabela tiver 1.000.000 de registros, teríamos um desperdício
de 152,5 MB. Multiplique isso por diversas tabelas e diversos bancos de dados, e poderemos chegar a
desperdícios gigantescos em um único servidor SQL Server 2005.
Nestas situações pode ser justificável a utilização, por exemplo, de um campo de texto de tamanho
variável, com tamanho máximo definido em 250 – char(250). Nesta situação o espaço ocupado não
seria 250 bytes para todos os campos, mas somente o tamanho real dos dados digitados no campo,
conforme descrito na Tabela 4.1.
Mas, então, por que não utilizamos sempre campos de tamanho variável? A resposta é simples: porque
campos de tamanho variável acarretam processamento adicional para o Banco de Dados, e estes somente
devem ser utilizados em situações onde realmente sejam necessários. Estas situações tipicamente ocorrem
quando não sabemos com precisão a variação do tamanho dos dados em um determinado campo, e a
utilização de um tamanho fixo acarretaria muito desperdício de espaço em disco.
Agora vamos aprender a criar tabelas no SQL Server 2005.
FUNDAMENTOS EM: CRIAÇÃO DE TABELAS COM

O SQL SERVER MANAGEMENT STUDIO
PRÉ-REQUISITOS
♦ Conhecer os tipos básicos de dados do SQL Server 2005.
♦ Saber utilizar o SQL Server Management Studio.
METODOLOGIA
♦ Utilização do SQL Server Management Studio para a criação de tabelas.
TÉCNICA
♦ Criação de tabelas nos Bancos de Dados criados no Capítulo 3.
Agora vamos aprender a criar tabelas utilizando o SQL Server Management Studio. Mais uma vez a
melhor maneira de aprendermos é através de um exemplo prático. Vamos criar a tabela Clientes, no
banco de dados Exemplo1 (banco de dados este que foi criado no Capítulo 3, na instância
SERVIDOR\SQL2005) com os campos indicados na Tabela 4.2.
Tabela 4.2 A tabela Clientes.
Campo Tipo de dado
CódigoCliente Integer
NomeEmpresa Texto de, no máximo, 50 caracteres.
Rua Texto de, no máximo, 50 caracteres.
Bairro Texto de, no máximo, 20 caracteres.
Cidade Texto de, no máximo, 25 caracteres.
CEP Integer
DataCadastro datetime
Vamos criar esta tabela no Banco de Dados Exemplo1, lembrando que este banco de dados foi criado
no Capítulo 3, na instância SERVIDOR\SQL2005. Iremos inicialmente criar a tabela Clientes definindo
apenas características básicas: nome, tamanho máximo, tipo e se o campo pode conter valores nulos
ou não. Na seqüência, apresentaremos mais um exemplo, onde vamos trabalhar com mais propriedades
de cada campo da tabela.
Exemplo prático: Criando a tabela Clientes, no banco de dados Exemplo1, da instância

SERVIDOR\SQL2005, usando o SQL Server Management Studio.
1. Se você não estiver com o SQL Server Management Studio aberto, abra-o (Iniciar -> Programas
-> Microsoft SQL Server 2005 -> SQL Server Management Studio).

para expandi-la.
3. Nas opções que surgem abaixo desta instância, clique no sinal de mais ao lado da opção Data-
bases para expandi-la. Abaixo de Databases é exibida uma lista com os bancos de dados
disponíveis na instância SERVIDOR\SQL2005.
4. Dê um clique no sinal de +, ao lado da opção Databases, para expandi-la. Será exibida uma lista
dos bancos de dados disponíveis, dentre os quais devem estar o banco de dados Exemplo1,
criado no Capítulo 3.
5. Dê um clique no sinal de + ao lado de Exemplo1, para mostrar as opções disponíveis. Localize

a opção Tables. Dê um clique com o botão direito do mouse na opção Tables. No menu de
opções que surge, dê um clique na opção New Table. Mais ou menos no centro do SQL Server
Management Studio será exibida uma janela para a criação de uma nova tabela, conforme
indicado na Figura 4.1.
Esta janela é muito parecida com a janela para a criação de novas tabelas, em um banco de dados do
Microsoft Access. Na parte de cima, em cada linha, criamos um novo campo. Após digitar o nome do
campo, na coluna “Column Name”, na parte de baixo da janela, serão habilitadas as diversas
propriedades do campo. O conjunto de propriedades é diferente para cada tipo de campo. Por exemplo,
campos do tipo char terão um conjunto diferente de propriedades do que campos do tipo datetime. Na
parte de cima da janela para a criação de tabelas, temos três colunas, as quais estão descritas a seguir:
♦ Column Name: Nesta coluna definimos o nome do campo.
♦ Data Type: Aqui podemos definir o tipo de dados para o campo que está sendo criado. Podemos
selecionar em uma lista de tipos predefinidos. Caso o usuário tenha definido algum tipo
personalizado, este também irá aparecer nesta lista. Veremos como criar tipos personalizados
ainda neste capítulo.
♦ Allow Nulls: Serve para definir se o campo que está sendo criado irá ou não aceitar valores nulos.
Valor Null é diferente de valor em branco. Uma valor Null é de tipo desconhecido e, ao ser
utilizado em funções e em programação, irá retornar um erro. Já valores em branco não retornam
erros ao serem utilizados como parâmetros de função ou em variáveis de programação. Por
exemplo, se o usuário entrar em um campo do tipo texto e pressionar Enter, ele estará criando
uma string de comprimento zero, a qual é um valor em branco, diferente de um valor Null.
Figura 4.1 A janela para criação de uma nova tabela.
Na parte de cima desta janela definimos os campos, um por linha. À medida que estamos definindo
um determinado campo, podemos definir propriedades adicionais para o mesmo. Estas propriedades
aparecem na parte inferior da janela. O conjunto de propriedades é diferente para diversos tipos de
campo, isto é, as propriedades para um campo do tipo integer são diferentes das propriedades para um
campo do tipo datetime. Um detalhe importante a ser observado é que as propriedades da parte de
baixo da janela são referentes ao campo da linha onde está o cursor, na parte de cima da janela. É
importante estarmos cientes deste detalhe, para não alterarmos as propriedades de um campo quando
na verdade estamos querendo alterar as propriedades de um outro campo. No próximo exercício
aprenderemos sobre estas diversas propriedades.
No lado direito da janela de criação de campos, é exibida a janela Properties, nas quais são exibidas as
propriedades gerais da tabela que está sendo criada, conforme indicado na Figura 4.2:
Figura 4.2 A janela de propriedades da tabela.
Por exemplo, uma das propriedades é a propriedade (Name), a qual define o nome da tabela. O SQL
Server 2005 atribui nomes, automaticamente, nos formatos Table_1, Table_2 e assim por diante. Vamos
alterar a propriedade Name e vamos colocá-la como Clientes. Com isso estou definindo o nome da
tabela. Aprenderemos sobre as demais propriedades, no decorrer deste livro.
6. Vamos começar criando o campo CódigoCliente. Para isso preencha a primeira linha com as
seguintes informações:
♦ Column Name -> CódigoCliente
♦ Data Type -> int
♦ Allow Null -> Não (caixinha desmarcada).
Sua janela deve estar conforme indicado na Figura 4.3.
Figura 4.3 Definindo o campo CódigoCliente.
7. Defina os demais campos, conforme as seguintes orientações:
♦ Column Name -> NomeEmpresa
♦ Data Type -> char
♦ Size -> 50 (ao definir o tipo do campo, serão exibidas as propriedades do campo, na parte de
baixo da janela. Defina a propriedade Lenght com o tamanho desejado. Que neste caso é 50).
♦ Allow Null -> Não (caixinha desmarcada)
♦ Column Name -> Rua
♦ Size -> 50 (Defina a propriedade Lenght com o valor 50)
♦ Column Name -> Bairro
♦ Column Name -> Cidade
♦ Column Name -> CEP
♦ Data Type -> int (vamos digitar o CEP sem o tracinho, por exemplo: 97070888. Por isso
vamos usar um campo do tipo int e não do tipo char)
♦ Column Name -> DataCadastro
♦ Data Type -> datetime
Após a definição destes campos, sua janela deve estar conforme indicado na Figura 4.4.
Figura 4.4 Definição dos campos da tabela Clientes.
Agora é hora de salvarmos a tabela no Banco de Dados Exemplo1.
8. Dê um clique no botão Save (botão da barra de ferramentas, com o desenho de um disquete)

ou pressione Ctrl+S.
9. Caso você ainda não tenha definido o nome da tabela, através da definição da propriedade Name,
surgirá uma janela pedindo o nome da tabela. Digite Clientes e dê um clique no botão OK.
10. Você estará de volta à janela para definição dos campos. Feche-a.
11. Você estará de volta ao SQL Server Management Studio. Dê um clique no botão com o sinal de
mais ao lado do Banco de Dados Exemplo1 para expandi-lo.
12. Dê um clique no sinal de + ao lado da opção Tables, para expandi-la. A tabela Clientes já deve
estar aparecendo na listagem de tabelas do Banco de dados Exemplo1, conforme indicado na
Figura 4.5. Se a tabela Clientes ainda não estiver sendo exibida, clique na opção Tables, para
selecioná-la e pressione a tecla F5, para atualizar a listagem.
13. Clique com o botão direito do mouse na tabela Clientes, aponte para Script Table as -> SELECT
T0 – New Query Editor Window. Será aberta a janela para execução de comandos T-SQL, já
com o comando SELECT necessário para exibir todos os dados da tabela Clientes. Para executar
o comando, pressione a tecla F5. Nenhum registro será retornado. Obviamente que é este o
resultado esperado, pois recentemente criamos a tabela Clientes, definindo quais campos farão
parte da tabela e as características básicas de cada campo. Porém, nenhum registro ainda foi
inserido na tabela. Por isso que, como resultado da execução do comando SELECT na tabela,
obtivemos um resultado em branco, simplesmente porque ainda não existem registros na tabela,
apenas a sua estrutura é que foi definida.
Figura 4.5 A tabela Clientes recém-criada.
14. Feche o SQL Server Management Studio.
Conforme descrito no exemplo anterior, as tabelas criadas pelo próprio SQL Server 2005 iniciam com
sys. Esta é uma convenção que facilita a identificação das tabelas com informações sobre o próprio
Banco de Dados.
Quando criamos nossas tabelas também podemos utilizar uma convenção de nomes, o que pode vir a
facilitar a identificação e o desenvolvimento de aplicativos. Por exemplo, poderíamos iniciar todas as
tabelas criadas pelo DBA por usr, como um prefixo que identifica as tabelas dos usuários.
Você também pode, a qualquer momento, alterar a definição da estrutura de uma tabela. Por exemplo,
podemos inserir novos campos, renomear campos ou alterar as características de um ou mais campos.
Porém devemos ter muito cuidado com estes procedimentos. Se você, por exemplo, renomear uma
tabela, todos os aplicativos que acessam dados desta tabela precisarão ser alterados (alterar significa
modificar o código do aplicativo, recompilar o código e reinstalar, em todas as estações de trabalho, a
nova versão do programa) e o nome da tabela atualizado no código destes aplicativos. Por isso que é de
grande importância o cuidadoso planejamento do Banco de Dados antes da sua implementação efetiva.
Um bom planejamento minimiza ou até mesmo elimina alterações deste tipo, as quais irão impactar
os aplicativos que acessam dados no Banco de Dados.
Para alterar as propriedades de uma tabela basta localizá-la no SQL Server Management Studio, clicar
com o botão direito do mouse na tabela e, no menu de opções que surge, clicar na opção Modify Table.
Será aberta a janela com a definição de todos os campos, janela esta que você utilizou no exemplo
anterior, onde você poderá alterar os campos existentes ou adicionar novos campos.
Agora vamos a um exemplo mais detalhado. Vamos criar a tabela Funcionários com os campos descritos na
Tabela 4.3. Além disso vamos aprender sobre as diversas propriedades que cada campo pode apresentar.
Tabela 4.3 A tabela Funcionários.
Campo Tipo de dado/Tamanho máximo
CódigoFuncionário Integer
NomeCompleto Texto de, no máximo, 50 caracteres.
Cargo Texto de, no máximo, 30 caracteres.
DataNascimento datetime
DataContrato datetime
CEP Integer
FoneResidencial Texto de, no máximo, 25 caracteres.
Foto image
Vamos criar esta tabela no Banco de Dados Exemplo1, criado no capítulo anterior, na instância
SERVIDOR\SQL2005. Neste exemplo, além das propriedades básicas de cada campo, aprenderemos a
definir uma série de outras propriedades.
Exemplo prático: Criando a tabela Funcionários, no banco de dados Exemplo1, usando o SQL Server
Management Studio.

para expandi-la.
3. Dê um clique no sinal de +, ao lado da opção Databases, para expandi-la. Será exibida uma lista
dos bancos de dados disponíveis, dentre os quais deve estar o banco de dados Exemplo1,
criado no Capítulo 3.
4. Dê um clique no sinal de + ao lado de Exemplo1, para mostrar as opções disponíveis. Localize

a opção Tables. Dê um clique com o botão direito do mouse na opção Tables. No menu de
opções que surge, dê um clique na opção New Table. Mais ou menos no centro do SQL Server
Management Studio será exibida uma janela para a criação de uma nova tabela, conforme já
indicado anteriormente na Figura 4.1.
5. Vamos começar criando o campo CódigoFuncionário. Para isso preencha a primeira linha com
as seguintes informações:
Column Name -> CódigoFuncionário

Data Type -> int
Allow Null -> Não (caixinha desmarcada).
Na parte de baixo da janela, conforme já descrito anteriormente, temos as diversas propriedades que
podem ser configuradas, para o campo que está sendo criado. Por padrão, estas propriedades são exibidas
por categoria (General, Table designer e assim por diante). Você pode exibir as propriedades em ordem
alfabética, clicando no segundo botão da barra de botões disponível logo acima das propriedades (é
um botão com A Z e uma seta). Clicando no primeiro botão, volta a exibição por categoria. Na parte de
baixo da janela temos as seguintes propriedades adicionais, que podem ser configuradas para os cam-
pos de uma tabela:
♦ Description: Esta propriedade define o texto que será exibido na coluna quando os dados da
tabela forem exibidos, usando um comando SELECT, conforme já descrito anteriormente. Se
esta propriedade não estiver definida, o texto a ser exibido é o próprio nome do campo. Para o
campo CódigoFuncionário digite o código do funcionário para esta propriedade.
♦ Default Value or Binding: Nesta propriedade aparece uma lista com todas as “global con-
straints” já definidas no Banco de Dados (se a lista não estiver disponível, é porque ainda
não foi criada nenhuma “global constraint”). O valor default é um valor que será atribuído
ao campo caso o usuário não insira nenhum valor neste campo. Por exemplo, vamos supor
que 99% dos funcionários sejam da cidade de São Paulo. Podemos definir São Paulo como
valor default para o campo Cidade. Desta maneira sempre que uma aplicação for inserir
dados na tabela Funcionários, o campo Cidade já aparece com o valor São Paulo preenchido.
Caso o funcionário que está sendo cadastrado seja de uma outra cidade é só colocar o cursor
no campo Cidade e digitar o nome da cidade. Com isso podemos ver que a definição de um
valor padrão não impede que valores diferentes sejam digitados no campo. Para o campo
CódigoFuncionário não existe valor padrão, pois cada funcionário possui um código diferente.
Neste caso deixe esta propriedade em branco. Aprenderemos a criar Constraints nos capítulos
sobre desenvolvimento.
♦ Identity: Define se a coluna será utilizada pelo SQL Server como uma coluna de identificação.
Veremos a função deste tipo de coluna no capítulo sobre replicação. Não altere esta propriedade.
♦ Identity Seed: Define o valor inicial para colunas do tipo Identity. Somente está habilitada
quando a propriedade Identity estiver definida em Yes. Não altere esta propriedade.
♦ Identity Increment: Define o valor do incremento para colunas do tipo Identity. Somente está
habilitada quando a propriedade Identity estiver definida em Yes. Não altere esta propriedade.
♦ Is RowGuid: Define se esta coluna será utilizada pelo SQL Server como uma coluna do tipo
GUID. Somente pode ser definida em Yes para colunas em que Identity foi definida em Yes.
Não altere esta propriedade.
♦ Formula: Exibe a fórmula para o caso de colunas calculadas. Lembrando do Capítulo 1, sempre
que possível devemos evitar a presença de colunas calculadas. Não altere esta propriedade.
♦ Collation: Exibe o valor de Collation definido para a coluna. Para maiores informações sobre
Collation consulte os Capítulos 2 e 3, bem como o Books OnLine. Não altere esta propriedade.
♦ Indexed: Esta propriedade somente aparece se houver um índice definido para o campo. Como
estamos criando uma nova tabela, ainda não temos índices definidos. Os valores possíveis são:
No (Não existe índice para esta coluna); Yes (duplicates OK), e existe índice e ele aceita valores
repetidos, e Yes (no duplicates) existe índice e ele não aceita valores duplicados, o qual é utilizado
para campos do tipo Chave Primária. Para maiores informações sobre campos que são chave
primária, consulte o Capítulo 1.
No nosso exemplo alteramos apenas a propriedade Description, conforme indicado na Figura 4.6.
Figura 4.6 Propriedades do campo CódigoFuncionário.
6. Defina os demais campos da tabela Funcionários, e suas propriedades, conforme as orientações

a seguir:
♦ Campo NomeCompleto
♦ Column Name -> NomeCompleto
♦ Data Type -> Char
♦ Size -> 50
Propriedades:
♦ Description: Nome do Funcionário.
♦ Default Value: Em branco.
♦ Identity: Não altere.
♦ Identity Seed: Não altere.
♦ Identity Increment: Não altere.
♦ Is RowGuid: Não altere.
♦ Formula: Não altere.
♦ Collation: Não altere.
♦ Campo Cargo
♦ Column Name -> Cargo
♦ Data Type -> Char
♦ Size -> 30
Propriedades:
♦ Description: Cargo do Funcionário.
♦ Não altere as demais propriedades.
♦ Campo DataNascimento
♦ Column Name -> DataNascimento
♦ Size -> 8 (definido pelo próprio SQL Server).
Propriedades:
♦ Description: Data de Nascimento.
♦ Campo DataContrato
♦ Column Name -> DataContrato
♦ Size -> 8 (definido pelo próprio SQL Server).
Propriedades:
♦ Description: Data de Contratação
♦ Campo Rua
♦ Column Name -> Rua
♦ Size -> 50
Propriedades:
♦ Description: Rua do Funcionário.
♦ Campo Bairro
♦ Column Name -> Bairro
♦ Size -> 20
Propriedades:
♦ Description: Bairro do Funcionário.
♦ Campo Cidade
♦ Column Name -> Cidade
♦ Size -> 25
Propriedades:
♦ Description: Cidade do Funcionário.
♦ Default Value: São Paulo (estamos definindo o valor padrão como São Paulo, pois a maioria
dos funcionários é da cidade de São Paulo). Observe que, após definirmos o valor padrão, o
SQL Server coloca o valor definido entre apóstrofes: ‘São Paulo’.
♦ Campo CEP
♦ Column Name -> CEP
♦ Data Type -> int
♦ Size -> 4
Propriedades:
♦ Description: CEP
♦ Campo FoneResidencial
♦ Column Name -> FoneResidencial
♦ Size -> 25
Propriedades:
♦ Description: Telefone Residencial.
♦ Campo Foto
♦ Column Name -> Foto
♦ Data Type -> image
♦ Size -> 16 (definido automaticamente pelo SQL Server. Conforme descrito anteriormente
este tamanho de 16 bytes é simplesmente um ponteiro que aponta para o arquivo com a
imagem. O arquivo com a imagem pode conter até cerca de 2 GB).
Propriedades:
♦ Description: Foto do Funcionário.
Agora é hora de salvarmos a tabela no Banco de Dados Exemplo1.
7. Dê um clique no botão Save (botão com o desenho de um disquete) ou pressionne Ctrl+S.
Surge uma janela pedindo o nome da tabela. Digite Funcionários e dê um clique no botão OK.
8. Você estará de volta à janela para definição dos campos. Feche-a.
9. Você estará de volta ao SQL Server Management Studio. Dê um clique no botão com o sinal de
mais ao lado do Banco de Dados Exemplo1 para expandi-lo.
10. Dê um clique no sinal de + ao lado da opção Tables. A tabela Funcionários já deve estar
aparecendo na listagem de tabelas do Banco de Dados Exemplo1, conforme indicado na Figura
4.7. Caso a tabela ainda não esteja aparecendo pressione a tecla F5 (Refresh) para atualizar a
visão Tables do Banco de Dados Exemplo1.
Figura 4.7 A tabela Funcionários recém-criada.
11. Com isso criamos a tabela Funcionários no banco de dados Exemplo1. Clique com o botão
direito do mouse na tabela Funcionários, aponte para Script Table as -> SELECT To – New
Query Editor Window. Será aberta a janela para execução de comandos T-SQL, já com o comando
SELECT necessário, para exibir todos os dados da tabela Funcionários. Para executar o comando,
pressione a tecla F5. Nenhum registro será retornado. Obviamente que é este o resultado
esperado, pois recentemente criamos a tabela Funcionários, definindo quais campos farão parte
da estrutura da tabela e as características básicas de cada campo. Porém, nenhum registro
ainda foi inserido na tabela. Por isso que como resultado da execução do comando SELECT na
tabela, obtivemos um resultado em branco, simplesmente porque ainda não existem registros
na tabela, apenas a sua estrutura é que foi definida.
Agora já estamos “craques” na criação de tabelas com o SQL Server Management Studio. O próximo
passo será aprendermos a criar tabelas utilizando o comando CREATE TABLE, o qual será executado na
janela para execução de comandos T-SQL, que já conhecemos bem.
Mas antes disso vamos a um exercício para que o leitor possa fixar os conceitos apresentados.
Exercício: Crie a tabela Fornecedores, utilizando o SQL Server Management Studio, com os campos
indicados na Tabela 4.4.
Tabela 4.4 A tabela Fornecedores.
CódigoFornecedor Integer
NomeEmpresa Texto de, no máximo, 50 caracteres.
NomeContato Texto de, no máximo, 30 caracteres.
CargoContato Texto de, no máximo, 20 caracteres.
CEP Integer
Fone Texto de, no máximo, 25 caracteres.
FAX Texto de, no máximo, 25 caracteres.
WebSite Texto de, no máximo, 100 caracteres.
FUNDAMENTOS EM: CRIAÇÃO DE

TABELAS USANDO COMANDOS T-SQL
PRÉ-REQUISITOS
♦ Noções sobre os tipos básicos de dados do SQL Server 2005.
METODOLOGIA
♦ Apresentação dos comandos T-SQL para criação de tabelas.
TÉCNICA
♦ Criação de tabelas utilizando os comandos apresentados.
Para criarmos uma tabela utilizamos o comando CREATE TABLE, na janela de execução de comandos
T-SQL, dentro do SQL Server Management Studio. A seguir temos a sintaxe deste comando, conforme
descrito no Books Online:
Sintaxe completa - Books OnLine - Transact SQL Reference:

CREATE TABLE
[ database_name.[ owner ] . | owner. ] table_name
( { < column_definition >
| column_name AS computed_column_expression
| < table_constraint > ::= [ CONSTRAINT constraint_name ] }
| [ { PRIMARY KEY | UNIQUE } [ ,...n ]
)
[ ON { filegroup | DEFAULT } ]
[ TEXTIMAGE_ON { filegroup | DEFAULT } ]
< column_definition > ::= { column_name data_type }

[ COLLATE < collation_name > ]
[ [ DEFAULT constant_expression ]
| [ IDENTITY [ ( seed , increment ) [ NOT FOR REPLICATION ] ] ]
]
[ ROWGUIDCOL]
[ < column_constraint > ] [ ...n ]
< column_constraint > ::= [ CONSTRAINT constraint_name ]

{ [ NULL | NOT NULL ]
| [ { PRIMARY KEY | UNIQUE }
[ CLUSTERED | NONCLUSTERED ]
[ WITH FILLFACTOR = fillfactor ]
[ON {filegroup | DEFAULT} ] ]
]
| [ [ FOREIGN KEY ]
REFERENCES ref_table [ ( ref_column ) ]
[ ON DELETE { CASCADE | NO ACTION } ]
[ ON UPDATE { CASCADE | NO ACTION } ]
[ NOT FOR REPLICATION ]
]
| CHECK [ NOT FOR REPLICATION ]
( logical_expression )
}
< table_constraint > ::= [ CONSTRAINT constraint_name ]
{ [ { PRIMARY KEY | UNIQUE }
[ CLUSTERED | NONCLUSTERED ]
{ ( column [ ASC | DESC ] [ ,...n ] ) }
[ WITH FILLFACTOR = fillfactor ]
[ ON { filegroup | DEFAULT } ]
]
| FOREIGN KEY
[ ( column [ ,...n ] ) ]
REFERENCES ref_table [ ( ref_column [ ,...n ] ) ]
[ ON DELETE { CASCADE | NO ACTION } ]
[ ON UPDATE { CASCADE | NO ACTION } ]
[ NOT FOR REPLICATION ]
| CHECK [ NOT FOR REPLICATION ]
( search_conditions )
}
Este formato genérico não é muito intuitivo, ou melhor, não é nada intuitivo. Vamos simplificar um
pouco. A seguir apresento uma sintaxe simplificada, somente com as principais opções para criar uma
tabela com alguns campos.
CREATE TABLE Nome_da_tabela

— Agora inicio a definição básica dos campos da tabela
(
Campo1 tipo_do_Campo1 NULL ou NOT NULL
<LCampo5 tipo_do_Campo5 NULL ou NOT NULL
Campon tipo_do_Campon NULL ou NOT NULL

)
A título de exemplo, vamos criar a tabela Produtos, no banco de dados Exemplo1, da instância
SERVIDOR\SQL2005, com os campos indicados na Tabela 4.5.
Tabela 4.5 A tabela Produtos.
CódigoProduto Integer
NomeProduto Texto de, no máximo, 50 caracteres.
CódigoCategoria Integer
PreçoUnitário Money
UnidadesEstoque Integer
EstoqueMínimo Integer
Descontinuado bit (0=sim, 1=não)
Agora vamos criar esta tabela no Banco de Dados Exemplo1 da instância SERVIDOR\SQL2005. Vamos
utilizar, para isso, a janela de execução de comandos do SQL Server Management Studio.
Exemplo prático: Utilizando a janela de execução de comandos para criar a tabela Produtos, conforme
descrito na Tabela 4.5.

4. Clique no sinal de + ao lado da opção Databases, para exibir as opções disponíveis. Localize o
banco de dados Exemplo1 e clique com o botão direito do mouse, no banco de dados Exemplo1.
No menu de opções que é exibido, clique em New Query. Será aberta a janela para execução de
comandos T-SQL, já descrita anteriormente. Digite o seguinte comando:
— Definição do nome da tabela.
CREATE TABLE Produtos
— Inicio a definição dos campos.
(
CódigoProduto int,
NomeProduto char(50),
CódigoFornecedor int,
CódigoCategoria int,
PreçoUnitário money,
UnidadesEstoque int,
EstoqueMínimo int,
Descontinuado bit
)
NOTA
Certifique-se de ter clicado com o botão direito do mouse no banco de dados Exemplo1, pois, se você tiver clicado em um outro banco de
dados, a tabela Produtos será criada no banco de dados no qual você clicou.
Ao executar este comando, se você não tiver cometido nenhum erro de digitação, a tabela Produtos
terá sido criada no Banco de Dados Exemplo1 e a seguinte mensagem é exibida:
Com isso, vemos que a tabela Produtos foi criada.
5. Mantenha a janela de execução de comandos T-SQL aberta, pois vamos utilizá-la para mais
alguns exemplos neste capítulo.
Agora vamos utilizar o SQL Server Management Studio para verificar se a tabela Produtos foi realmente criada.
Exemplo:
Verificando se a tabela Produtos foi realmente criada:
1. Se o SQL Server Management Studio não estiver aberto, abra-o.
2. Na janela Object Explorer, clique no sinal de + ao lado da instância SERVIDOR\SQL2005.
4. Clique no sinal de mais ao lado do Banco de Dados Exemplo1 para exibir as suas opções.
5. Nas opções que surgem clique no sinal de + ao lado da opção Tables para exibir as tabelas do
Banco de Dados Exemplo1. Observe que a tabela Produtos já deve aparecer na listagem de
tabelas. Se a tabela Produtos ainda não aparecer na listagem de tabelas, clique na opção Tables
do Banco de Dados Exemplo1 e pressione F5 para atualizar a listagem.
No exemplo anterior criamos uma tabela utilizando as opções básicas do comando CREATE TABLE.
Vamos ver mais alguns exemplos deste comando, utilizando opções mais avançadas do CREATE TABLE.
Mas antes disso vamos ver alguns “limites” do SQL Server 2005.
♦ O número máximo de tabelas que pode existir em um banco de dados é limitado pelo número
máximo de objetos que pode existir em um banco de dados do SQL Server 2005. Este número
é de: 2.147.483.647.
♦ O número máximo de colunas por tabela é 1024.
♦ Os números máximos de linhas e do tamanho de uma tabela são limitados apenas pelo espaço
disponível em disco.
♦ O número máximo de bytes por linha é de 8060. Se criarmos tabelas com colunas do tipo
varchar, nvarchar ou varbinary, nas quais o total de bytes do registro excede 8060 bytes, a
tabela será criada, porém uma mensagem de aviso será emitida. Ao efetuarmos alguma operação
de alteração ou inserção em que um determinado registro fique com mais do que 8600 bytes,
receberemos uma mensagem de erro e o comando não será executado.
Um comando CREATE TABLE que inclui colunas do tipo sql_variant poderá gerar o seguinte aviso:
“The total row size (xx) for table ‘yy’ exceeds the maximum number of bytes per row (8060).
Rows that exceed the maximum number of bytes will not be added.”
NOTA
Algumas das opções do comando CREATE TABLE somente serão utilizadas no Capítulo 9, onde aprenderemos a criar Constraints, Defaults e Rules.
Conforme visto na seção anterior, podemos definir uma série de propriedades para cada campo de
uma tabela, utilizando o SQL Server Management Studio. A pergunta que fica é: “Também podemos
definir estas opções utilizando o comando CREATE TABLE?”. E a resposta é sim. Mais uma vez vamos
aprender através da utilização de um exemplo prático.
Exemplo prático: Como faço para definir que um campo não deve aceitar valores NULL?
Vamos alterar um pouco o comando do exemplo anterior, conforme indicado a seguir:

(
CódigoProduto int NOT NULL,
NomeProduto char(50) NOT NULL,
CódigoFornecedor int NOT NULL,
CódigoCategoria int NOT NULL,
PreçoUnitário money NOT NULL,
UnidadesEstoque int NOT NULL,
EstoqueMínimo int NOT NULL,
Descontinuado bit NOT NULL
)
Este comando criaria a mesma tabela Produtos do exemplo anterior, porém sem permitir valores nulos
nos campos da tabela.
Para permitir NULL em algum campo, bastaria trocar NOT NULL por NULL.
Assim como devemos criar uma padronização para o nome dos Bancos de Dados e tabelas, também
devemos ter um certo padrão para a nomeação dos campos de uma tabela. Consulte a documentação
da sua empresa para saber se já existe um documento definindo o padrão para a nomeação de Bancos
de Dados, tabelas e campos.
NOTA
Nomes de colunas, tabelas, campos ou qualquer objeto no SQL Server 2005 podem ter um tamanho máximo de 128 caracteres. Podemos
incluir letras, dígitos e os símbolos: #, $, @ e _ nos nomes de objetos do SQL Server 2005.
Exercício: Para fixar a sintaxe do comando CREATE TABLE, crie a tabela Produtos Especiais, com os
campos conforme descrito na Tabela 4.6.
Tabela 4.6 A tabela Produtos Especiais.
Campo Tipo de dado/Tamanho máximo NULL
CódigoProdutoEsp Integer Não

NomeProdutoEsp Texto de, no máximo, 50 caracteres. Não
CódigoFornecedor Integer Não
CódigoCategoria Integer Não
PreçoUnitário money Não
UnidadesEstoque Integer Não
EstoqueMínimo Integer Sim
EstoqueMáximo Integer Sim
Descontinuado bit (0=sim, 1=não) Não
FUNDAMENTOS EM: ALTERAR A ESTRUTURA DE UMA

TABELA COM O SQL SERVER MANAGEMENT STUDIO
PRÉ-REQUISITOS
METODOLOGIA
♦ Utilização do SQL Server Management Studio para alterar a estrutura de uma tabela.
Embora não seja recomendado, podemos alterar a estrutura de uma tabela. Não é uma prática
recomendada, pois, se o Banco de Dados for bem projetado (conforme venho insistindo e repetindo
diversas vezes no decorrer deste livro), não haverá necessidade de alterações na estrutura das tabelas.
Mas caso seja necessária tal alteração, podemos fazê-la utilizando o SQL Server Management Studio,
conforme aprenderemos neste item, ou comandos T-SQL, conforme aprenderemos no item seguinte.
Para alterar uma tabela, basta localizá-la no SQL Server Management Studio, clicar com o botão direito
do mouse no nome da tabela e, no menu que surge, clicar na opção Modify Table. Será exibida a janela
com a estrutura da tabela. Nesta janela podemos fazer as seguintes alterações, dentre outras:
♦ Excluir um campo: Para isso basta selecionar a linha que define o campo e pressionar a tecla
Delete. Para selecionar uma linha, basta clicar no botão cinza, bem à esquerda da linha, conforme
exemplo indicado na Figura 4.8.
Figura 4.8 Selecionando o campo a ser excluído.
♦ Alterar as propriedades de um campo, simplesmente editando as informações para este campo.
♦ Incluir novos campos.
Feitas as alterações é só clicar no botão Save ou pressionar Ctrl+S, para salvar as alterações efetuadas.
NOTA
Muitas vezes, devido a prazos apertados, o cuidadoso projeto do Banco de Dados é encarado como uma “perda de tempo” e deixado em
segundo plano. Isso acaba por trazer uma série de problemas que poderiam ser evitados com um cuidadoso projeto do Banco de Dados.
Lembre que é muito mais complicado remendar do que fazer bem feito da primeira vez.
FUNDAMENTOS EM: ALTERAR A ESTRUTURA DE

UMA TABELA COM COMANDOS T-SQL
PRÉ-REQUISITOS
METODOLOGIA
♦ Apresentação dos comandos T-SQL para alteração de tabelas.
TÉCNICA
♦ Alterar tabelas, utilizando os comandos apresentados.
Existem alguns comandos T-SQL que permitem que sejam feitas alterações em uma tabela. Vamos
aprender a utilizá-los.
Para adicionar uma coluna em uma tabela já existente, utilizamos o seguinte comando:
ALTER TABLE nome_da_tabela

ADD nome_do_campo tipo_dado
Vamos tentar o seguinte exemplo:
ALTER TABLE CLIENTES

ADD Campo1 Char(25) Not Null
Este exemplo irá gerar a seguinte mensagem de erro:
ALTER TABLE only allows columns to be added that can contain nulls or have a DEFAULT
definition specified. Column ‘Campo1’ cannot be added to table ‘CLIENTES’ because it does not
allow nulls and does not specify a DEFAULT definition.
Sem subestimar o conhecimento de inglês do amigo leitor, esta mensagem está nos dizendo que o
comando ALTER TABLE somente permite que sejam adicionadas colunas que permitem valores nulos
ou que possuem um valor padrão definido para a coluna. Como não podemos “brigar” com o SQL
Server 2005, vamos alterar um pouco o comando para que a coluna Campo1 que está sendo adicionada
permita valores nulos. Nosso comando fica assim:
ALTER TABLE CLIENTES

ADD Campo1 Char(25)
Agora nosso comando executa sem maiores problemas e recebemos a seguinte mensagem:
Exercício: Utilize o SQL Server Management Studio e verifique se a coluna Campo1 realmente foi
adicionada à tabela Clientes, conforme indicado na Figura 4.9.
Figura 4.9 A coluna Campo1 recém-adicionada.
Observe que a coluna Campo1 admite valores nulos.
Para excluir uma coluna em uma tabela, utilizamos o seguinte comando:

DROP COLUMN nome_do_campo
Vamos excluir a coluna Campo1 adicionada no exemplo anterior.
ALTER TABLE Clientes

DROP COLUMN Campo1
Este comando executa com sucesso e retorna a mensagem:
Exercício: Utilize o SQL Server Management Studio e verifique se a coluna Campo1 realmente foi
excluída da tabela Clientes.
Também podemos fazer alterações em uma coluna já existente, utilizando o comando ALTER COL-
UMN. No exemplo a seguir, vamos adicionar um campo chamado teste, o qual é do tipo smallint.
Depois vamos alterá-lo para o tipo int e finalmente vamos excluí-lo da tabela Clientes.
— Adicionando o campo teste do tipo smallint

ADD teste smallint
GO
—Alterando o tipo do campo para int
ALTER COLUMN teste int
GO
—Excluindo o campo teste
DROP COLUMN teste
Ao executarmos este comando recebemos a seguinte mensagem:
FUNDAMENTOS EM: TIPOS DE DADOS DEFINIDOS PELO USUÁRIO

PRÉ-REQUISITOS
♦ Saber Utilizar o SQL Server Management Studio e a janela de execução de comandos T-SQL.
♦ Conhecer os tipos básicos de dados do SQL Server 2005.
METODOLOGIA
♦ Utilizar o SQL Server Management Studio e a janela de execução de comandos T-SQL, para criar tipos de dados personalizados.
No início do capítulo vimos os diversos tipos de dados disponibilizados pelo SQL Server 2005. São os
chamados “Tipos de dados do sistema” (System data types). Com o SQL Server 2005, o usuário pode
criar seus próprios tipos de dados. Esta não é nenhuma novidade do SQL Server 2005, já que linguagens
bastante antigas (e ainda muito utilizadas), tais como o C e C++, permitem a criação de tipos
personalizados pelo usuário.
Por exemplo, vamos supor que o usuário queira padronizar que todos os campos com nomes próprios,
quer seja de funcionários, clientes ou fornecedores, devam ser do tipo char com tamanho máximo de
50 caracteres. O usuário poderia criar um novo tipo chamado nome_próprio e definir este tipo como
sendo char(50). Desta maneira, quando for criar as suas tabelas, o usuário pode definir os campos
como sendo do tipo nome_próprio, que automaticamente será assumido char(50). Uma das vantagens
evidentes é a facilidade de manutenção. Vamos supor que, após algum tempo de utilização do Banco
de Dados, chegou-se à conclusão de que char(40) é suficiente para os campos com nomes próprios.
Para alterar a definição de todos os campos, bastaria alterar o tipo nome_próprio definido pelo usuário.
Se não estivéssemos utilizando um tipo definido pelo usuário, teríamos que ir de tabela em tabela
alterando o campo NomeDoFuncionário de char(50) para char(40).
Ao criar tipos definidos pelo usuário (User-defined data types), devemos utilizar um padrão de nomes
consistente, de tal forma que o nome seja um indicativo das características do tipo de dados.
Ao criarmos um tipo definido pelo usuário, este somente estará disponível no Banco de Dados onde o tipo tiver sido criado. Se criarmos um
NOTA
tipo definido pelo usuário no Banco de Dados Model, este tipo passará a fazer parte de todos os novos Bancos de Dados que forem criados,
depois que o tipo foi criado no banco de dados Model.
Agora vamos aprender a criar User-defined data types. Inicialmente vamos criá-los utilizando o SQL Server Management Studio e, na
seqüência, a janela de execução de comandos T-SQL.
CRIANDO UM TIPO DE DADOS DEFINIDO PELO USUÁRIO

COM O SQL SERVER MANAGEMENT STUDIO
A título de exemplo, vamos criar um tipo chamado nome_próprio no Banco de Dados Exemplo1, da
instância SERVIDOR\SQL2005. O tipo terá as seguintes características:
♦ Nome do tipo: usr_nome_próprio
♦ Tipo: char(50)
♦ Não aceita valores nulos.

NOTA
Veja que para o nome do tipo utilizamos o prefixo usr. Esta é uma convenção para indicar que o tipo de dados foi criado pelo usuário, ou seja,
que é um tipo de dados definido pelo usuário. Também é importante lembrar que este tipo de dados só estará disponível para o banco de
dados Exemplo1, onde o tipo foi criado.
Exemplo prático: Criando o tipo usr_nome_próprio com o SQL Server Management Studio.

4. Clique no sinal de + ao lado da opção Databases, para exibir os bancos de dados disponíveis na
instância SERVIDOR\SQL2005.
5. Clique no sinal de + ao lado do banco de dados Exemplo1, para exibir as categorias de objetos
deste banco de dados.
6. Clique no sinal de + ao lado da opção Programmability, para exibir as opções de programação

disponíveis.
7. Clique no sinal de + ao lado da opção Types, abaixo de Programmability, para exibir as opções
disponíveis. Observe que existe uma opção User-defined Data Types.
8. Dê um clique nesta opção para selecioná-la. Observe que, por padrão, não existe nenhum tipo
de dados definido pelo usuário, conforme indicado na Figura 4.10:
Figura 4.10 Não existe ainda nenhum tipo definido pelo usuário.
9. Clique com o botão direito do mouse na opção User-defined Data Types. No menu de opções
que surge dê um clique em New User-defined Data Type.
10. Surge uma janela onde podemos definir as características do tipo que está sendo criado. Para o
nosso exemplo, defina as características do tipo usr_nome_próprio conforme indicado na Figura
4.11. Dê um clique em OK para criar este novo tipo.
Figura 4.11 Criando o tipo usr_nome_próprio.

NOTA
As opções Rule e Default serão vistas no Capítulo 9.
11. Você estará de volta ao SQL Server Management Studio e o tipo usr_nome_próprio já terá sido criado.
12. Vamos criar mais um tipo chamado usr_money_real, com as seguintes características:
♦ Nome do tipo: usr_money_real
♦ Tipo: money
♦ Aceita valores nulos.
13. Clique com o botão direito do mouse na opção User-defined Data Types. No menu de opções
que surge dê um clique em New User-defined Data Type.
14. Para criar o tipo usr_money_real, defina as características do tipo conforme indicado na Figura
4.12. Dê um clique em OK para criar este tipo.
15. Você estará de volta ao SQL Server Management Studio e o tipo usr_money_real já terá sido
criado.
Figura 4.12 Criando o tipo usr_money_real.
Agora que criamos tipos definidos pelo usuário, podemos utilizá-los na definição de colunas em nossas
tabelas, dentro do banco de dados Exemplo1. Vou repetir, mais uma vez, para você não esquecer: os
tipos de dados foram criados dentro do banco de dados Exemplo1 e só poderão ser utilizados dentro
do banco de dados onde foram criados. Considere o exemplo a seguir, o qual cria, no Banco de Dados
Exemplo1, a tabela Produtos 2:

CREATE TABLE Produtos2
(
CódigoProduto int,
NomeProduto usr_nome_próprio,
PreçoUnitário usr_money_real,
EstoqueMínimo int,
Descontinuado bit
)
Execute este comando na janela de execução de comandos T-SQL, estando conectado à instância
SERVIDOR\SQL2005 e sendo Exemplo1 o Banco de Dados atual. Observe que estamos utilizando os
tipos definidos pelo usuário: usr_nome_próprio e usr_money_real.
Vamos criar mais uma tabela chamada Produtos3 onde utilizaremos apenas o tipo usr_nome_próprio,
conforme indicado no comando a seguir:
CREATE TABLE Produtos3
(
CódigoProduto int,
NomeProduto usr_nome_próprio,
EstoqueMínimo int,
Descontinuado bit
)
Execute este comando na janela de execução de comandos T-SQL, estando conectado à instância
SERVIDOR\SQL2005 e sendo Exemplo1 o Banco de Dados atual.
Agora temos as tabelas Produtos2 e Produtos3. O tipo usr_nome_próprio foi utilizado nas duas tabelas
e o tipo usr_money_real somente foi utilizado na tabela Produtos2.
Podemos verificar em quais tabelas um determinado tipo definido pelo usuário está sendo utilizado.
No SQL Server Management Studio, clique com o botão direito do mouse no tipo usr_nome_próprio.
No menu de opções que surge dê um clique em Propriedades. Na janela de Propriedades, no painel da
esquerda, dê um clique na opção Dependencies. Será exibida uma janela com a lista de tabelas onde o
tipo usr_nome_próprio é utilizado, conforme indicado pela Figura 4.13.
Figura 4.13 Tabelas que utilizam o tipo usr_nome_próprio.
Dê um clique em OK para fechar a janela da Figura 4.13.
CRIANDO UM TIPO DE DADO DEFINIDO PELO USUÁRIO,

USANDO A JANELA DE COMANDOS T-SQL
A título de exemplo, vamos criar um tipo chamado usr_nome_rua, no Banco de Dados Exemplo1, da
instância SERVIDOR\SQL2005. O tipo terá as seguintes características:
♦ Nome do tipo: usr_nome_rua
♦ Tipo: char(25)
♦ Não aceita valores nulos.

NOTA
Veja que para o nome do tipo utilizamos o prefixo usr. Esta é uma convenção para indicar que o tipo de dados foi criado pelo usuário.
Exemplo prático: Criando o tipo usr_nome_rua, usando comandos T-SQL:
4. Clique com o botão direito do mouse no banco de dados Exemplo1 e, no menu de opções que
é exibido, clique na opção New Query. Será aberta a janela para execução de comandos T-SQL.

Use Exemplo1
exec sp_addtype usr_nome_rua, ‘char(25)’,‘NOT NULL’
Estamos utilizando um stored procedure que faz parte do SQL Server 2005: sp_addtype. Existe uma
infinidade de Stored Procedures que fazem parte do SQL Server 2005, os quais fazem parte do Banco de
Dados master, conforme indicado na Figura 4.14. Estes stored procedures iniciam com “sp” e executam
uma série de funções. Utilizaremos vários destes stored procedures nos exemplos dos demais capítulos
deste livro.
A sintaxe simplificada para o stored procedure sp_addtype é a seguinte:
exec sp_addtype nome_tipo, ‘tipo_básico’, ‘NULL ou NOT NULL’
6. Após executar o comando indicado no passo anterior, o tipo usr_nome_rua terá sido criado.
Podemos conferir se o tipo foi realmente criado, utilizando o SQL Server Management Studio.
A seguir apresentamos algumas dicas a serem consideradas para a criação de tipos definidos pelo usuário
– User-defined Data Types:
♦ Se uma determinada coluna apresenta variação no tamanho dos dados, pode ser mais vantajoso
utilizar um tipo variável, como por exemplo varchar, ao invés de um tipo de tamanho fixo,
como por exemplo char(50). Conforme descrito no início do capítulo, tipos de tamanho variável
como varchar podem propiciar economia de espaço em disco.
Figura 4.14 Stored procedures que fazem parte do SQL Server 2005.
♦ Se os dados a serem armazenados são maiores do que 8000 bytes, utilize os tipos text ou image.
Para dados menores do que 8000 bytes utilize binary, char ou varchar. Sempre que possível
utilize char ou varchar, pois estes tipos apresentam mais funcionalidades do que os demais tipos.
♦ É sempre importante ter uma idéia dos valores que serão armazenados em uma coluna. Se você
souber que os valores de uma determinada coluna variam de 1 a 200, por exemplo, é mais
vantajoso utilizar um tipo tinyint que ocupa menos espaço do que um tipo int.
EXCLUINDO TIPOS DEFINIDOS PELO USUÁRIO

Podemos excluir os tipos definidos pelo usuário, desde que estes não estejam sendo utilizados em
alguma tabela.
Vamos tentar excluir o tipo usr_nome_próprio, o qual está sendo utilizado pelas tabelas Produtos2 e
Produtos3. Tentaremos excluí-lo com o SQL Server Management Studio e com o stored procedure
sp_droptype e iremos observar as mensagens de erro que serão emitidas. Depois excluiremos o tipo
usr_nome_rua utilizando o stored procedure sp_droptype.
Para excluir um tipo definido pelo usuário com o SQL Server Management Studio, basta localizar o
tipo a ser excluído, clicar com o botão direito sobre o tipo a ser excluído e, no menu que surge, clicar
na opção Delete. Surge uma janela exibindo o tipo a ser excluído, conforme indicado na Figura 4.15.
Figura 4.15 Excluindo o tipo usr_nome_próprio.
Clique em OK para confirmar a exclusão do tipo usr_nome_próprio. No nosso exemplo surge uma
mensagem de advertência. Esta mensagem informa que o tipo usr_nome_próprio não pode ser excluído
pois ele está sendo utilizado em uma ou mais tabelas.
Clique em OK e você estará de volta ao SQL Server Management Studio. Feche-o.
Agora vamos excluir o tipo usr_nome_rua utilizando o stored procedure sp_droptype.
Exemplo prático: Excluindo o tipo usr_nome_rua, usando comandos T-SQL:

Use Exemplo1
exec sp_droptype usr_nome_rua
A sintaxe simplificada para o stored procedure sp_droptype é a seguinte:
exec sp_droptype nome_tipo
6. Após executar o comando indicado no passo anterior, o tipo usr_nome_rua terá sido excluído
do banco de dados Exemplo1 e a seguinte mensagem será exibida:
Podemos conferir se o tipo usr_nome_rua foi realmente excluído, utilizando o SQL Server Manage-
ment Studio.
NOTA
Se você tentar excluir um tipo que está sendo utilizado por alguma tabela, o Query Analyzer emite a seguinte mensagem de erro:
Cannot drop type ‘dbo.usr_nome_próprio’ because it is currently in use.
FUNDAMENTOS EM: EXCLUSÃO DE TABELAS

PRÉ-REQUISITOS
METODOLOGIA
♦ Utilização do SQL Server Management Studio e da janela de execução de comandos T-SQL, para a exclusão de tabelas.
Não é uma situação comum, mas pode existir a necessidade de excluirmos uma tabela de um
Banco de Dados. É importante salientar que, ao excluirmos uma tabela, todos os seus dados serão
também excluídos.
PARA EXCLUIR UMA TABELA COM O SQL SERVER MANAGEMENT STUDIO

Abra o SQL Server Management Studio e “navegue” até a tabela a ser excluída. Clique com o botão
direito do mouse na tabela e no menu que surge selecione a opção Delete. Surge a janela indicada
na Figura 4.16.
Dê um clique no botão OK e pronto, a tabela foi excluída.
Figura 4.16 Excluindo a tabela Produtos2.
EXCLUINDO UMA TABELA COM O QUERY ANALYZER

Para excluir uma tabela podemos utilizar o seguinte comando T-SQL:
DROP TABLE nome_da_tabela
Exemplo:
Para excluir a tabela Produtos3 do Banco de Dados Exemplo1, poderíamos utilizar o seguinte comando:
DROP TABLE Produtos3
Este comando retorna a seguinte mensagem:
FUNDAMENTOS EM: DEFINIÇÃO DA CHAVE PRIMÁRIA DE UMA TABELA

PRÉ-REQUISITOS
♦ Saber utilizar o SQL Server Management Studio e a janela de execução de comandos T-SQL.
METODOLOGIA
♦ Utilizar o SQL Server Management Studio e a janela de execução de comandos T-SQL para definir um campo como chave primária de uma tabela.
Conforme vimos na teoria sobre o modelo relacional de dados, no Capítulo 1, temos os chamados
campos que são chave primária para uma determinada tabela. Um campo definido como chave primária
deve ser único, isto é, não podem existir dois registros com o mesmo valor para o campo Chave
Primária e geralmente são campos de código, como por exemplo:
♦ CódigoCliente ou CPF na tabela Clientes.
♦ CódigoFuncionário ou Matrícula na tabela Funcionários.
♦ CPF na tabela Contribuintes Pessoa Física.
♦ CNPJ (antigo CGC) na tabela Contribuintes Pessoa Jurídica.
♦ CódigoDoProduto na tabela Produtos.
Podemos definir um determinado campo como sendo chave primária, tanto usando a interface gráfica
do SQL Server Management Studio quanto usando comandos T-SQL. Vamos mais uma vez utilizar
exemplos para aprender a definir um campo como sendo chave primária.
DEFININDO UMA CHAVE PRIMÁRIA UTILIZANDO

O SQL SERVER MANAGEMENT STUDIO
Exemplo: Definir o campo CódigoFuncionário da tabela Funcionários, do banco de dados
Exemplo1, da instância SERVIDOR\SQL2005, como sendo uma chave primária. Para isso siga os

4. Nas opções que surgem abaixo desta instância, clique no sinal de + ao lado da opção Databases
para expandi-la. Abaixo de Databases é exibida uma lista com os Bancos de Dados disponíveis
na instância SERVIDOR\SQL2005.
5. Dê um clique no sinal de + ao lado do Banco de Dados Exemplo1 para exibir seus objetos.
6. Dê um clique no sinal de + ao lado da opção Tables, para exibir uma listagem com as tabelas do
Banco de Dados Exemplo1.
7. Dê um clique com o botão direito do mouse na tabela Funcionários. No menu que surge dê um
clique na opção Modify Table. Será exibida uma janela com a estrutura da tabela Funcionários.
8. O passo seguinte é selecionar a linha correspondente ao campo que será definido como chave
primária. Selecione a linha CódigoFuncionário, conforme indicado na Figura 4.17.
Figura 4.17 Selecionando o campo CódigoFuncionário.
9. Clique com o botão direito do mouse em qualquer parte da linha selecionada. No menu de
opções que é exibido clique em “Set primary key” (você também pode clicar no botão Set
Primary Key – botão com o desenho de uma pequena chave amarela). Feito isso, o campo
CódigoFuncionário é definido como chave primária, conforme indicado por uma pequena
chave amarela ao lado do nome do campo.
10. Clique no botão Save ou pressione Ctrl+S para salvar as alterações feitas na estrutura da tabela.
NOTA
Caso você esteja definindo um campo como chave primária, porém já existam registros na tabela e existam valores duplicados para o campo
que está sendo definido como Chave Primária, na hora de salvar as alterações será exibida a mensagem de erro, informando que o campo
não pode ser definido como chave primária, pois existem valores duplicados no campo.
A seguir temos o texto completo da mensagem de erro:
‘Funcionários’ table
- Unable to create index ‘PK_Funcionários’.
ODBC error: [Microsoft][ODBC SQL Server Driver][SQL Server]CREATE UNIQUE INDEX terminated
because a duplicate key was found for index ID 1.
Most significant primary key is ‘1’.
[Microsoft][ODBC SQL Server Driver][SQL Server]Could not create constraint.
See previous errors.
[Microsoft][ODBC SQL Server Driver][SQL Server]The statement has been terminated.
Observe que a parte mais significativa da mensagem é a seguinte:
“because a duplicate key was found for index ID 1”
Esta parte está informando que foi encontrado um valor duplicado para o campo CódigoFuncionário
e, portanto, este campo não pode ser definido como chave primária.
NOTA
Conforme veremos na parte final deste capítulo, ao criarmos uma chave primária, na verdade estamos definindo um índice que não permite
duplicação de valores, para o campo que está sendo definido como chave primária.
11. Agora feche a janela com as propriedades da tabela Funcionários.
12. Você estará de volta ao SQL Server Management Studio. Feche-o.
Para fazer com que um campo não seja mais chave primária, basta repetir os passos do exemplo anterior, marcar o campo desejado e clicar
NOTA
novamente no botão “Set Primary Key”. Este botão funciona como uma chave de liga e desliga. Se o campo selecionado já for chave primária
ao clicarmos no botão “Set Primary Key”, o mesmo deixa de ser. Caso o campo não seja uma chave primária, ao clicarmos no botão “Set
Primary Key”, o campo é marcado como chave primária. Você também tem a opção de clicar com o botão direito do mouse no campo
selecionado e, no menu que é exibido, clicar em em Remove Primary Key.
Conforme veremos a seguir, não posso fazer com que um campo deixe de ser chave primária se o campo fizer parte de algum relacionamento.
DEFININDO UMA CHAVE PRIMÁRIA UTILIZANDO COMANDOS T-SQL

A definição de uma chave primária através de comandos utiliza o conceito de Constraint. Neste capítulo
nos limitaremos ao comando que permite a criação de uma chave primária, sem detalharmos o conceito
de Constraints. No Capítulo 9 falaremos em detalhes sobre Constraints.
Utilizamos o comando ALTER TABLE, com a seguinte sintaxe:

ADD CONSTRAINT nome_da_chave_primária
PRIMARY KEY CLUSTERED (nome_do_campo_a_ser_definido_como_chave_primária)
Exemplo: Definir o campo CódigoProduto da tabela Produtos, do banco de dados Exemplo1, da instância
SERVIDOR\SQL2005 como sendo uma chave primária.
Para isso faça o seguinte:
3. Clique no sinal de + ao lado de Databases para expandi-la.
ALTER TABLE Produtos
ADD CONSTRAINT chave_prim_produtos
PRIMARY KEY CLUSTERED (CódigoProduto)
Após executar o comando indicado no passo anterior, o campo CódigoProduto da tabela Produtos terá
sido definido como chave primária e a seguinte mensagem será exibida:
Podemos conferir se o campo foi realmente definido como chave primária, utilizando o SQL Server Management Studio. Acesse a tabela
NOTA
Produtos, clique com o botão direito do mouse na tabela Produtos e, no menu de opções que é exibido, clique em Modify Table. Verifique se
há o desenho de uma pequena chave amarela, ao lado do campo CódigoProduto. Este desenho comprova que o campo CódigoProduto foi
definido como chave primária da tabela Produtos.
6. Feche a janela de execução de comandos T-SQL. Se o SQL Server 2005 perguntar se você deseja
salvar a Query, clique em No.
Importante: Se a coluna que estiver sendo definida como chave primária admitir valores nulos, o
comando do passo 3 resultará na seguinte mensagem de erro:

Cannot define PRIMARY KEY constraint on nullable column in table ‘Produtos’.
Could not create constraint. See previous errors.
Se a coluna que estiver sendo definida como chave primária contiver valores repetidos, o comando do
passo 3 resultará na seguinte mensagem de erro:

CREATE UNIQUE INDEX terminated because a duplicate key was found for index ID 1.
Most significant primary key is ‘110’.
Could not create constraint. See previous errors.
The statement has been terminated.
FUNDAMENTOS EM: CONCEITO E CRIAÇÃO DE ÍNDICES

PRÉ-REQUISITOS
♦ Saber utilizar a janela de execução de comandos T-SQL e o SQL Server Management Studio.
METODOLOGIA
♦ Apresentação dos conceitos e dos comandos T-SQL para criação de índices.
TÉCNICA
♦ Criação de índices utilizando os comandos apresentados.
UMA VISÃO GERAL DOS ÍNDICES NO SQL SERVER 2005

A criação de índices é uma ferramenta poderosa para o projetista do Banco de Dados. Um índice é uma
estrutura auxiliar que melhora o desempenho das consultas. O papel principal do índice é reduzir o
número de operações de I/O (leitura e escrita (Input/Output) no disco) necessárias para localizar os
dados solicitados pela consulta. Ao utilizar índices, ajudamos o SQL Server 2005 a, rapidamente, localizar
e disponibilizar os dados necessários, através de um número de operações de I/O muito menor do que
se não tivéssemos índices no Banco de Dados. Uma analogia que aparece em diversos livros sobre
Bancos de Dados é a comparação com o índice de um livro (O sumário do início do livro ou mais
precisamente o índice remissivo, que vem no final do livro. Estas duas são também estruturas auxiliares,
cujo objetivo é facilitar a localização de um conteúdo, dentro do livro). Você procura o tópico desejado
no índice e abre o livro diretamente na página relacionada, ao invés de folhear página por página, o
que teria que ser feito se não tivéssemos o índice.
Podemos criar índices em qualquer coluna de uma tabela, inclusive em uma coluna com valores
calculados (esta foi uma das novidades do SQL Server 2000, a qual, evidentemente, também faz parte
do SQL Server 2005). Se não utilizarmos índices, o SQL Server precisa realizar uma operação conhecida
como “Table Scan”, para localizar os dados solicitados por uma consulta. Uma operação de Table Scan
é uma leitura seqüencial de todos os registros da tabela, o que implica muito mais operações de I/O de
disco do que quando utilizamos índices. Como operações de I/O de disco normalmente são bastante
lentas quando comparadas com operações de leitura ou escrita em memória, a utilização de índices, ao
reduzir o número de operações de I/O de disco, melhora significativamente o desempenho das consultas.
Se não definirmos nenhum índice para uma tabela, os registros serão armazenados aleatoriamente,
sem nenhuma ordem específica.
No SQL Server podemos ter dois tipos de índices, conforme descrito a seguir.
CLUSTERED INDEX
Um clustered index ordena os dados de acordo com os valores do campo onde o índice foi definido. Os
dados são armazenados na própria tabela. Neste caso, o índice está alterando a ordem em que os
registros são armazenados na própria tabela, ao invés de uma ordem aleatória (utilizado no caso de
não termos índices); os registros são armazenados em uma ordem definida pelo índice. Este tipo de
índice é bastante eficiente para agilizar operações de localização de registros. Somente podemos ter um
clustered index por tabela, pois só poderemos armazenar os dados em ordem de um determinado
critério (não há como armazenar o mesmo conjunto de dados em duas ou mais ordens diferentes. Por
isso que só podemos ter um clustered index, por tabela). Observe que, embora o índice melhore o
desempenho das consultas, existe um pequeno “overhead” para operações de atualização, inserção e
exclusão de registros, pois estas operações podem fazer com que a ordem dos registros seja alterada, e
que estes tenham que ser reposicionados para manter a ordem definida pelo índice.
Os índices no SQL Server 2005 são organizados em uma estrutura semelhante a uma árvore de cabeça
para cima, as chamadas B-trees. Os dados são divididos em páginas (na verdade o SQL Server 2005
armazena os dados de uma tabela divididos em páginas de 8 KB). Cada página de um clustered index
possui um cabeçalho que identifica a página mais as linhas do índice (Index Rows). Cada linha do
índice contém um valor-chave e um ponteiro para outra página do índice ou para um registro de
dados. Cada página do índice é chamada de nó – Index Node. O primeiro nó da árvore é chamado de
nó raiz – Root Node. O último nível ou camada de nós é chamado de nós folhas – Leaf Nodes. Entre o
nó raiz e o último nível, podemos ter diversos níveis intermediários. As páginas de cada nível são
ligadas em forma de uma lista duplamente encadeada. As páginas com dados são as páginas ou nós
folhas (Leaf Nodes).
Na Figura 4.18, retirada do Books OnLine, temos uma ilustração da estrutura de um clustered index.
Figura 4.18 A estrutura em forma de B-tree de um clustered index.
Os dados encontram-se nas chamadas Leaf Pages; as demais páginas do índice (também conhecidas
como Non-Leaf Pages) contêm informações que facilitam a localização dos dados contidos nas
Leaf Pages.
Para entender o funcionamento de um clustered index, vamos observar como um determinado registro
é localizado, utilizando a estrutura de um clustered index. Considere o exemplo da Figura 4.19.
Figura 4.19 Acessando dados com um clustered index.
Vamos supor que você queira localizar o registro para o cliente Raul. O SQL Server 2005 fará o seguinte:
♦ Ao receber a pesquisa, o SQL Server detecta a existência de um índice na coluna nome e que a
utilização deste índice auxiliará no processo de pesquisa. Então, utiliza um mecanismo interno
para preparar um “Plano de Execução” para uma determinada consulta (esta decisão sobre a
utilização ou não do índice e se esse uso irá melhorar o desempenho da consulta é tomada
internamente, pelo mecanismo de banco de dados do SQL Server 2005). Este plano procura
determinar qual a maneira mais rápida de executar a consulta. Neste caso, o SQL Server 2005
determina que a melhor maneira é através da utilização do índice.
♦ Nas páginas do índice (Non-Leaf Pages), a pesquisa inicia na página root (125). O valor procurado
Raul vem depois do último valor desta página, que é Marcos. Com isso a pesquisa prossegue
para a página “apontada pela página 125”, que no caso é a página 127.
♦ A pesquisa continua na página de índice 127. Nesta página, o valor Raul está na faixa entre
Marcos e Silvano. Agora a pesquisa é deslocada para a página de dados em que o primeiro
registro começa com Marcos (página 60), conforme indicado pelas flechas da Figura 4.19.
♦ Agora a pesquisa já alcançou o nível dos dados (Leaf Pages) e está na página que contém o
registro procurado. A página 60 será percorrida seqüencialmente, até localizar o registro para o
usuário Raul. Observe que o número de operações de leitura foi bastante reduzido com a
utilização do índice, em comparação à situação em que tivéssemos que fazer uma varredura de
todos os registros da tabela, até encontrar o registro procurado (o que teria que ser feito, caso
não existisse o índice).
Este exemplo ilustra o quanto os índices podem melhorar o desempenho das consultas. Como regra
geral devemos criar clustered indexes em colunas que são freqüentemente utilizadas como critério
para pesquisas. Por exemplo a coluna NomeCliente de uma tabela de clientes ou campo
NúmeroDoPedido da tabela Pedidos e assim por diante.
Ao criarmos clustered indexes (aprenderemos a criá-los mais adiante neste capítulo), devemos considerar
os seguintes fatos:
1. Conforme descrito anteriormente, cada tabela pode conter apenas um clustered index.
2. A ordem física das linhas da tabela (Leaf Nodes) e das linhas do índice (Non-Leaf Nodes) é a
mesma. Caso queiramos utilizar um clustered index e um nonclustered index na mesma tabela,
devemos criar o clustered index primeiro, uma vez que isso modifica a ordem dos registros na
tabela.
3. Os valores da chave em um clustered index devem ser únicos. Isto é possível com a utilização
da palavra UNIQUE na criação do índice, conforme veremos mais adiante. Se não utilizarmos
a palavra UNIQUE, o SQL Server adicionará um identificador interno, o qual será único para
cada chave do índice. Este identificador interno é de 8 bytes e é somente para uso do SQL
Server, não podendo seus valores serem acessados pelo usuário através de um comando SE-
LECT, por exemplo.
4. De uma maneira geral, o espaço em disco ocupado por um clustered index é cerca de 5% do
tamanho da tabela. Este percentual varia, dependendo do tamanho da coluna que está
sendo indexada.
5. Durante o processo de criação do índice o SQL Server ocupa, temporariamente, espaço em

disco. A criação de um clustered index requer cerca de 1,2 vezes o tamanho da tabela que está
sendo indexada. Este espaço é liberado após a criação do índice. Caso o seu Banco de Dados
não permita o crescimento automático dos arquivos que o compõem e não exista este espaço
disponível, o índice não poderá ser criado.
NONCLUSTERED INDEX
Este tipo de índice cria uma estrutura separada das páginas da tabela. A ordem dos registros na tabela
não é alterada com a criação de um nonclustered index. Com isso, os registros são armazenados em
uma ordem aleatória. Este tipo de índice também apresenta uma estrutura do tipo B-tree com um nó
root (Root Node) e Leaf Pages, os quais contêm informações do índice e não os dados, pois os dados
ficam armazenados nas páginas de dados da própria tabela. Pela descrição podemos confirmar que um
nonclustered index cria uma estrutura completamente separada da estrutura da tabela, sendo que as
informações contidas no índice são utilizadas para localizar rapidamente informações nos registros da
tabela. Em uma linguagem mais técnica dizemos que: “Os níveis mais baixos de um nonclustered
index contêm valores-chaves, e cada um destes valores-chave aponta para uma linha de dados
correspondente à chave. Por exemplo, a chave poderia ser o número de CPF do funcionário. Este valor
armazenado no nonclustered index é utilizado para, rapidamente, localizar o registro correspondente
na tabela Funcionários. Este ponteiro é chamado de Localizador de registro – Row Locator.
A estrutura do Row Locator depende de a tabela ter ou não um clustered index. Se a tabela já possui
um clustered index, a chave contida no Row Locator é igual e aponta para a chave contida no
clustered index. Portanto, o nonclustered index está apontando para a chave correspondente no
clustered index.
Se a tabela não contiver um clustered index (conhecida como Heap), a chave do Row Locator aponta
diretamente para o registro correspondente à chave do Row Locator.
Na Figura 4.20, retirada do Books OnLine, temos uma ilustração da estrutura de um nonclustered
index.
Figura 4.20 A estrutura em forma de B-tree de um nonclustered index.
A utilização de nonclustered indexes é indicada quando o usuário precisa pesquisar os dados por
diversos critérios diferentes, uma vez que podemos criar mais do que um nonclustered index por
tabela. Por exemplo, se criamos um clustered index na coluna CódigoProduto, podemos criar um
nonclustered index na coluna NomeProduto, para agilizar a pesquisa tanto pelo Código quanto pelo
nome. É importante salientar que mesmo sem o índice é possível pesquisar por um ou mais campos de
qualquer tabela, porém a consulta será mais demorada.
Mais algumas observações sobre nonclustered indexes:
1. Nonclustered index é o default para a criação de índices no SQL Server 2005.
2. Podemos ter um máximo de 249 nonclustered indexes por tabela.
3. É mais indicada a criação de nonclustered indexes em colunas que possuem dados que variam
de registro para registro, como por exemplo CódigoCliente ou NomeCliente. Em campos do
tipo Sim ou Não, por exemplo, não é aconselhável a criação de Nonclustered Indexes.
4. No SQL Server 2005 temos uma importante novidade em relação aos nonclustered index. No
SQL Server 2005 é possível ampliar a funcionalidade de um nonclustered index, através da
inclusão de colunas que não são chaves, como parte das páginas Leaf do índice. Esta opção
pode melhorar consideravelmente o desempenho das consultas, principalmente em casos onde
todas as colunas do comando T-SQL fazem parte do nonclustered index, sejam estas colunas
do tipo Chave ou não. Isso ocorre porque, sendo todas as colunas de uma consulta parte do
índice, bastará ao SQL Server 2005 pesquisar diretamente no índice, o que é muito mais rápido,
do que, após localizar um registro no índice, ainda ter que percorrer a página de dados para a
qual aponta o valor encontrado no índice.
MAIS ALGUMAS QUESTÕES TEÓRICAS SOBRE ÍNDICES

Vamos analisar os seguintes conceitos sobre índices: Index Keys e Index Uniqueness.
♦ Index Keys: Chamamos de Index Key – chave do índice – a(s) coluna(s) utilizada(s) para definição
do índice. A chave do índice (Index Key) é um valor que permite que o registro correspondente
seja rapidamente localizado. Por exemplo, se definirmos um índice na coluna CódigoCliente,
o valor 2356 é a chave para localizar o registro correspondente ao cliente cujo código é 2356.
Normalmente os valores Index Key são passados para uma consulta através da utilização da
cláusula WHERE. Para mais informações sobre a cláusula WHERE, consulte a introdução à
linguagem SQL no Capítulo 1. Podemos ter chaves de índices simples ou compostas, dependendo
do tipo de índice que foi definido.
Um índice simples é o que inclui apenas uma coluna de uma tabela. Esta coluna é que deve ser utilizada
como parâmetro para a cláusula WHERE da consulta. Este tipo de índice é adequado para colunas que
apresentam diferentes valores para diferentes registros, como por exemplo: CódigoCliente,
CódigoFuncionário, NomeCliente, NomeFuncionário, não sendo indicado para colunas que apresentam
pequenas variações nos seus valores. Por exemplo, suponhamos que você tenha um cadastro de
1.000.000 de clientes, sendo que estes pertencem somente a três estados: SP, RJ ou MG. Criar um índice
simples na coluna Estado não será de grande valor como auxiliar no desempenho das consultas, uma
vez que o valor desta coluna somente varia entre os valores SP, RJ ou MG.
Um índice composto é formado por duas ou mais colunas de uma tabela. Um índice composto pode
ser acessado utilizando-se uma ou mais chaves que fazem parte do índice. No SQL Server 2005, um
índice pode ser formado por, no máximo, 16 colunas, sendo que a soma dos tamanhos das colunas do
índice não pode ultrapassar 900 bytes (estes já eram os valores limites no SQL Server 2000 e não foram
alterados no SQL Server 2005). Esta limitação tem a ver com a questão de desempenho, pois de nada
adiantaria criar índices muito grandes, pois, dependendo do tamanho dos índices, estes podem até
tornar as consultas mais lentas, ao invés de acelerá-las.
Quando construímos as consultas, não precisamos incluir todos os campos que formam o índice
na cláusula WHERE da consulta. Porém não devemos esquecer que o índice somente será utilizado
se a cláusula WHERE contiver pelo menos um dos campos que fazem parte do índice. Se a cláusula
WHERE não contiver nenhum campo do índice, será utilizado um table scan, pois o índice em
nada poderá ajudar a melhorar o desempenho da consulta, neste caso.
♦ Index Uniqueness: No SQL Server 2005 podemos ter índices que são únicos ou não são. Em
índices únicos não temos valores repetidos para a chave do índice. Um índice não-único permite
valores repetidos para a chave, e será tanto mais efetivo quanto mais diferentes forem os valores
que o formam.
Por exemplo, em uma tabela de cadastro de clientes, um índice para o campo CódigoCliente será
único, já que não existem dois clientes com o mesmo código. Veja que, quando definimos um campo
como sendo uma chave primária, na verdade estamos criando um índice único para este campo,
conforme descrito anteriormente.
Em uma tabela de pedidos, teríamos que criar um índice não-único no campo CódigoCliente. Uma vez
que um cliente pode fazer mais do que um pedido, o campo CódigoCliente apresentará valores repetidos,
isto é, o código de um determinado cliente irá se repetir tantos quantos forem os pedidos para este
cliente. Com isso, os valores de chave para o índice não serão únicos e teremos um índice não-único.
Em termos de eficiência, um índice único é melhor do que índices não-únicos, uma vez que estes
últimos exigem um número maior de operações de I/O de disco para localizar os dados solicitados.
Podemos ter uma combinação de índices quanto a serem simples ou compostos e a serem únicos ou
não-únicos. Desta forma poderemos ter os seguintes tipos de índices:
♦ Índice simples e único.
♦ Índice simples e não-único.
♦ Índice composto e único.
♦ Índice composto e não-único.
Agora que vimos um pouco de teoria sobre os índices, estamos preparados para aprender a criar índices
no SQL Server 2005. Este é o assunto do próximo item.
CRIANDO ÍNDICES NO SQL SERVER 2005

Podemos criar índices utilizando diferentes ferramentas, como por exemplo:
♦ Janela para executar Comandos T-SQL
Iremos criar diferentes tipos de índices utilizando estas ferramentas.
CRIANDO UM CLUSTERED INDEX SIMPLES

Neste exemplo, vamos criar um clustered index na coluna CódigoCliente da tabela Clientes do Banco
de Dados Exemplo1, da instância SERVIDOR\SQL2005, criada anteriormente. Vamos fazer com que
este índice não admita valores duplicados; desta maneira vamos criar um índice único, ou seja, uma
chave primária para a tabela Clientes. Vamos chamar este índice de CodCliIndex.
Exemplo prático: Para criar o clustered index CodCliIndex, na coluna CódigoCliente, da tabela Clientes,
do Banco de Dados Exemplo1, da instância SERVIDOR\SQL2005, siga os passos indicados a seguir:
1. Abra o SQL Server Management Studio (Iniciar -> Programas -> Microsoft SQL Server -> SQL
Server Management Studio).
2. Na Janela Object Browser, clique no sinal de + ao lado da instância SERVIDOR\SQL2005 para

expandi-la.
3. Nas opções que surgem abaixo desta instância, clique no sinal de + ao lado da opção Databases
para expandi-la. Abaixo de Databases é exibida uma lista com os Bancos de Dados disponíveis
nesta instância.
4. Clique no sinal de + ao lado do banco de dados Exemplo1.
5. Clique no sinal de + ao lado da opção Tables.
6. Nas tabelas que são exibidas, clique no sinal de + ao lado da tabela Clientes (na verdade
dbo.Clientes. Você aprenderá o porquê do dbo, no Capítulo 6, quando falarei sobre Segurança
no SQL Server 2005).
7. Nas opções que são exibidas, abaixo da tabela Clientes, clique na opção Indexes, para selecioná-la.
8. Clique com o botão direito do mouse na opção Indexes e, no menu de opções que é exibido,
clique em New Index. Será aberta a janela New Index, com a categoria General selecionada
por padrão, conforme indicado na Figura 4.21.
Figura 4.21 Janela para a criação de um índice.

NOTA
Podemos notar, na Figura 4.21, que para o nome da tabela aparece dbo.Clientes. DBO é um acrônimo para Database Owner (dono do Banco
de Dados) e indica o usuário que criou a tabela. Falaremos mais sobre o dono do Banco de Dados e de seus objetos no Capítulo 6 quando
trataremos sobre segurança em Bancos de Dados do SQL Server 2005.
9. No campo Index name digite: CodCliIndex.
10. Na lista Index Type selecione a opção Clustered.
11. Marque a opção Unidque.
12. Agora temos que informar qual o campo para o qual será criado o índice, que no nosso caso será
o campo Código Cliente. Dê um clique no botão Add. Será aberta a janela Select Columns, com
a lista de campos da tabela Clientes. Marque o campo CódigoCliente e clique em OK.
13. Você estará de volta à janela New Index. Observe que o campo CódigoCliente, selecionado no
Passo 12, já aparece na lista Index Key Columns, conforme indicado na Figura 4.22.
No painel da esquerda, clique na opção Storage. Observe que temos a opção de definir em qual filegroup
o índice será colocado. Por padrão o índice será colocado no filegroup Primary, que é o único existente
antes que outros filegroups sejam criados. Para definir um filegroup diferente, basta marcar a opção
Filegroup e selecionar um nome na lista ao lado.
Figura 4.22 Criando o índice CodCliIndex.
14. Dê um clique no botão OK.
15. Pronto. O índice CodCliIndex foi criado e já deve aparecer na opção Indexes, da tabela Clientes, do
banco de dados Exemplo1. Se o índice CodCliIndex ainda não estiver sendo exibido, clique na
opção Indexes, abaixo da tabela Clientes e pressione a tecla F5 para atualizar a listagem de índices.
CRIANDO ÍNDICES USANDO COMANDOS T-SQL

Agora aprenderemos uma série de comandos para trabalhar com índices. Além dos comandos para a
criação de índices aprenderemos alguns stored procedures internos do SQL Server 2005, para a verificação
e manutenção de índices.
Para criar índices utilizamos o comando CREATE INDEX. A seguir temos a sintaxe para o comando
CREATE INDEX, conforme descrito no Books OnLine:
CREATE [ UNIQUE ] [ CLUSTERED | NONCLUSTERED ] INDEX index_name

ON { table | view } ( column [ ASC | DESC ] [ ,...n ] )
[ WITH < index_option > [ ,...n] ]
[ ON filegroup ]
< index_option > :: =
{ PAD_INDEX |
FILLFACTOR = fillfactor |
IGNORE_DUP_KEY |
DROP_EXISTING |
STATISTICS_NORECOMPUTE |
SORT_IN_TEMPDB
}
Mais uma vez vamos simplificar a sintaxe para este comando. No formato simplificado teríamos o
seguinte:

ON { table | view }
( column [ ASC | DESC ] [ ,...n ] )
No banco de dados NorthWind era um banco de dados fornecido como banco de dados de Exemplo,
com o SQL Server 2000. O Northwind não é mais instalado com o SQL Server 2005. Mas é possível
importar o Northwind de uma instância do SQL Server 2000, para uma com o SQL Server 2005. Foi
exatamente o que eu fiz, para ter o banco de dados Northwind disponível no SQL Server 2005, banco
este que será utilizado em vários exemplos deste livro. Para todos os detalhes sobre como importar o
banco de dados Northwind, de uma instância do SQL Server 2000 para uma instância do SQL Server
2005, consulte o anexo, no final deste livro.
Vamos a um exemplo prático. Para criar o seguinte índice:
♦ Tabela Customers do Banco de Dados Northwind
♦ Nome: CityIndex
♦ Colunas: City
♦ Permitir valores duplicados.
utilizaríamos o seguinte comando:
CREATE INDEX CityIndex ON Customers (City)
Vamos a um exemplo um pouco mais elaborado. Qual seria o comando para criar o seguinte índice?
♦ Nome: PK_Customers
♦ Colunas: CustomerID
♦ Não permitir valores duplicados.
Neste caso, utilizaríamos o seguinte comando:
CREATE UNIQUE CLUSTERED

INDEX PK_Customers ON Customers (CustomerID)
WITH DROP_EXISTING
Ao utilizarmos a opção WITH DROP_EXISTING estamos orientando o SQL Server a excluir o índice
caso ele já exista, e a recriá-lo novamente. Se não utilizarmos esta opção e o índice já existir, será
emitida a seguinte mensagem de erro:

The operation failed because an index or statistics with name ‘PK_Customers’ already exists
on table ‘dbo.Customers’.
Vamos a mais um exemplo. Agora vamos criar um índice composto com as seguintes características:
♦ Nome: EnderecoIndex
♦ Colunas: Address, City e Region
♦ Não permitir valores duplicados
♦ Ignorar valores duplicados.
Neste caso utilizaríamos o seguinte comando:
CREATE UNIQUE INDEX EnderecoIndex

ON Customers (Address, City, Region)
WITH IGNORE_DUP_KEY
Neste caso utilizamos a opção UNIQUE para criar um índice único e a opção WITH IGNORE_DUP_KEY
para ignorar valores duplicados já existentes.
Algumas considerações para a criação de índices compostos por mais do que um campo:
1. Podemos criar um índice composto por, no máximo, 16 colunas. Além disso a soma do tamanho
das 16 colunas não pode ultrapassar 900 bytes.
2. Todas as colunas de um índice composto devem pertencer à mesma tabela. Como no SQL
Server 2005 podemos criar índices em views (consultas) e uma View pode retornar dados de
várias colunas, ao criarmos um índice composto em uma view, as colunas que formam o índice
composto devem pertencer à mesma tabela.
3. Em termos de desempenho, devemos definir a coluna que possui valores mais diferenciados
em primeiro lugar. Por exemplo, no índice EnderecoIndex, do qual fazem parte as colunas:
Address, City e Region, a coluna que apresenta a maior variação, com certeza, é a coluna
Address (existem muitos endereços em uma cidade), depois a coluna City (existem muitas
cidades em uma região) e por último a coluna Region. Ao definirmos o índice devemos passar
as colunas nesta mesma ordem, pois isso melhora o desempenho das consultas.
4. Desta maneira podemos concluir que a ordem das colunas importa no desempenho, e além
disso, os dois comandos a seguir definem índices diferentes. Observe que a única diferença
entre os dois é a ordem das colunas:

WITH IGNORE_DUP_KEY
e
ON Customers (City, Address, Region)
WITH IGNORE_DUP_KEY
5. Ao construirmos uma consulta, a cláusula WHERE deve fazer referência a todas as colunas do
índice composto, caso contrário o índice não será utilizado.
UM FATOR IMPORTANTE: FILLFACTOR OPTION

Esta opção é igualmente importante e pouco utilizada. Talvez seja pouco utilizada pelo não
conhecimento da aplicabilidade desta opção. Vamos explicá-la de uma maneira simples.
Ao criarmos um clustered index, os dados da tabela são armazenados em páginas de dados de acordo
com a ordem dos valores da coluna indexada. Ao inserirmos novos registros na tabela, estes precisam
ser inseridos na ordem definida pelo campo que compõe o índice. Nestas situações pode acontecer de
registros terem que ser deslocados para outras páginas para que o registro que está sendo inserido seja
colocado na ordem correta. Este procedimento também acontece quando utilizamos nonclustered
index, ao adicionarmos ou alterarmos os registros da tabela.
Ao criarmos um índice podemos especificar um valor para a opção FILL FACTOR (clique na opção
Options, no painel da esquerda, da janela de criação do índice, quando usando o SQL Server Manage-
ment Studio ou a cláusula FILLFACTOR = %, quando usando comandos T-SQL). Este valor define um
percentual a ser deixado em branco, sem registros gravados, em cada página de dados. O objetivo deste
espaço em branco é agilizar as operações de inserção, alteração e exclusão de dados, evitando que
tenham que ser feitas movimentações de registros entre páginas e, em casos mais extremos,
desdobramento de páginas. Com isso obtém-se um melhor desempenho nestas operações.
Pode parecer um detalhe sem muita importância, mas imagine, por exemplo, um sistema de reserva de
passagens aéreas de uma grande companhia. Milhares de terminais de atendimentos conectados ao
Banco de Dados, com operações de inserção, alteração e exclusão sendo feitas a todo instante. Nestas
situações o ganho em performance é considerável. Mas, como tudo na vida, temos que considerar o
outro lado da situação. Ao definirmos um FILL FACTOR elevado estaremos deixando um percentual de
espaço em branco, disponível em cada página. Para sistemas que fazem basicamente consulta, um FILL
FACTOR elevado será prejudicial, pois a consulta terá que acessar um número maior de páginas de
dados para reunir a informação necessária. Maior número de páginas, mais operações de I/O de disco
= pior desempenho.
Então em sistemas DSS (Decision Support Systems), onde não temos alterações nem inserções de dados,
mas sim um grande volume de consultas aos dados, o ideal é um FILL FACTOR de 100%, ou seja, sem
espaço nas páginas de dados.
NOTA
Falaremos um pouco mais sobre os diferentes ambientes de trabalho (DSS – Decision Support System), OLTP e OLAP no Apêndice.
O valor do parâmetro FILL FACTOR é um valor percentual, o qual varia de 0 a 100%. Um valor de
100% significa que as páginas de dados serão ocupadas completamente, o que implica menor espaço
para armazenamento e também menos operações de I/O de disco para as consultas, conforme descrito
anteriormente.
Na maioria das situações o valor padrão definido pelo próprio SQL Server 2005 já é satisfatório, mesmo
para aplicações que tenham muitas operações de inserção e atualização.
O percentual de espaço livre é definido na criação do índice. À medida que novos registros vão sendo
inseridos ou alterados, as páginas de dados vão sendo preenchidas e o percentual de espaço livre vai
diminuindo. Caso você queira redefinir o percentual de espaço livre, basta recriar o índice com a
definição do FILL FACTOR para o percentual desejado.
O valor default para o FILL FACTOR é 0%. Porém este valor não significa que as páginas de dados estão
zero por cento preenchidas. Na prática este valor instrui o SQL Server a criar páginas de dados
praticamente preenchidas, deixando apenas um pouco de espaço para otimizações do índice. Você
pode alterar este valor padrão acessando as propriedades da instância do servidor SQL Server, através
da guia Database Settings, conforme indicado na Figura 4.23:
Figura 4.23 Valor default para o FILL FACTOR.
Para criar um índice com a opção FILL FACTOR, basta utilizar WITH FILLFACTOR = x %, conforme
indicado no exemplo a seguir:
CREATE NONCLUSTERED INDEX NomeIndex

ON Autores (nome)
WITH FILLFACTOR = 65
FUNDAMENTOS EM: COMANDOS ADICIONAIS

PARA TRABALHAR COM ÍNDICES
PRÉ-REQUISITOS
♦ Noções básicas sobre o conceito de índices.
METODOLOGIA
♦ Apresentação dos comandos T-SQL relacionados com índices.
Neste item veremos alguns comandos úteis para trabalhar com índices.
♦ O comando sp_helpindex: Este comando retorna uma série de informações sobre os índices de
uma tabela ou view.
A sintaxe para este comando é bastante simples.
exec sp_helpindex nome_da_tabela_ou_view
Por exemplo, o comando:
exec sp_helpindex Customers
retorna o resultado indicado na Figura 4.24.
Figura 4.24 Informações retornadas por sp_helpindex.

NOTA
Uma coluna indexada em ordem descendente será listada com um sinal de menos após o nome.
♦ O comando sp_spaceused: Este comando retorna informações sobre o espaço ocupado por
uma tabela.
exec sp_spaceused nome_da_tabela
exec sp_spaceused Customers
retorna o resultado indicado na Figura 4.25.
Figura 4.25 Informações retornadas por sp_spaceused.
Observe que uma das informações retornadas é o tamanho do índice.
♦ O comando sp_help: Este comando retorna uma série de informações sobre uma determinada
tabela, inclusive informações sobre os índices.
exec sp_help nome_da_tabela
exec sp_help Customers
retorna uma série de informações sobre a tabela Customers.
EXCLUINDO ÍNDICES
Para excluir um índice é bastante simples. Podemos excluir um índice com o SQL Server Management
Studio ou através de comandos T-SQL. Com o SQL Server Management Studio, basta localizar o índice
a ser excluído, clicar com o botão direito do mouse no índice e, no menu de opções que é exibido,
clicar em Delete. Será exibida uma janela de confirmação. Clique em OK e pronto, o índice será excluído.
EXCLUINDO UM ÍNDICE COM O QUERY ANALYZER

Para excluir um índice utilizando comandos T-SQL, utilizamos o comando DROP INDEX. A sintaxe
para este comando é a seguinte:
DROP INDEX nome_da_tabela.nome_do_indice
Observe a nomenclatura, onde utilizamos o nome da tabela, um ponto (.) e o nome do índice. Por
exemplo, para excluir o índice CodCliIndex da tabela Clientes, do Banco de Dados Exemplo1, deveríamos
utilizar o seguinte comando:
DROP INDEX Clientes.CodCliIndex
NOVIDADE DO SQL SERVER 2005 – DESATIVAÇÃO DE ÍNDICES

Uma das novidades do SQL Server 2005, em relação aos índices, é a possibilidade de “desativar um
índice”. Ao desabilitar um nonclustered index, este não poderá ser acessado pelos usuários, porém o
acesso aos dados da tabela continua liberado. Ao desabilitar um clustered index, os usuários não terão
acesso nem ao índice e nem aos dados da respectiva tabela. As definições do índice serão mantidas,
porém suas estatísticas serão perdidas. Já, se o índice que estiver sendo desabilitado for um índice de
uma view, os dados do índice serão perdidos. Ao desabilitar um clustered index, o acesso aos dados da
tabela não estará disponível, porém os dados não serão excluídos. Uma vez habilitado novamente o
clustered index, o acesso aos dados será liberado.
Durante um upgrade de versões anteriores do SQL Server para o SQL Server 2005, automaticamente o
Setup desabilita os índices existentes. Ou o próprio administrador poderá desabilitar um índice, usando
o comando ALTER INDEX. Você também pode desabilitar um índice, localizando o índice com o SQL
Server Management Studio, clicando com o botão direito do mouse no índice e, no menu que é exibido,
clicar em Disable. Será exibida uma janela para você confirmar a desabilitação do índice. Clique em
OK e pronto, o índice foi desabilitado. Para habilitar novamente o índice, usando o SQL Server Man-
agement Studio, localize o índice a ser reabilitado, clique com o botão direito do mouse no índice e, no
menu de opções que é exibido, clique em Rebuild. Para habilitar novamente um índice são utilizados
os comandos ALTER INDEX REBUILD ou CREATE INDEX WITH DROP_EXISTING.
Como exemplo, considere o comando: “ALTER INDEX IX_Employee_ManagerID ON HumanResources.

Employee DISABLE”. Este comando desabilita o índice IX_Employee_ManagerID, na tabela
HumanResources.Employee.
CONCLUSÃO
Iniciamos o capítulo com a apresentação dos tipos de dados existentes no SQL Server 2005. Depois
aprendemos a criar tipos de dados definidos pelo usuários User-defined data types.
Em seguida aprendemos a criar tabelas, tanto utilizando o SQL Server Management Studio quanto
utilizando comandos T-SQL.
Finalmente fizemos um estudo detalhado sobre a aplicação e criação de índices.
Para finalizar o capítulo gostaria de colocar algumas recomendações quanto à criação de índices.
Use índices nas seguintes situações:
♦ Para consultas com critérios baseados em uma faixa de valores e que retornam um pequeno
número de linhas.
♦ Colunas que são utilizadas freqüentemente em operações de join devem ser utilizadas para a
criação de índices.
♦ Consultas que retornam dados de uma forma ordenada. Neste caso basta criar um clustered
index para o campo e ordem desejada. Por exemplo, se você tem uma consulta que deve listar
todos os pedidos por ordem do número do pedido, ao invés de ordenar a consulta utilizando a
cláusula ORDER BY, crie um clustered index na coluna NúmeroPedido, na ordem desejada pela
consulta (Ascendente ou Descendente).
Orientações para a utilização de índices:
♦ Utilize índices com moderação. Não saia simplesmente indexando todas as colunas de todas as
tabelas, pois o efeito obtido pode ser uma redução no desempenho das consultas ao invés de um
aumento de desempenho, devido à necessidade de manutenção dos índices. Lembre que toda
vez que dados são inseridos, alterados ou excluídos, os índices precisam ser atualizados, o que
gasta recursos do servidor SQL Server, tanto em termos de memória quanto de processamento.
♦ Para pequenas tabelas, isto é, tabelas com poucos registros, não se justifica a criação de índices. É mais
onerosa a manutenção dos índices do que a realização de um table scan em uns poucos registros.
♦ Sempre que possível utilize as chamadas “Covering querys”, as quais são consultas em que
todas as colunas que fazem parte da consulta possuem índices. Desta forma somente o índice
é acessado, sem a necessidade de pesquisar na tabela diretamente. Isto reduz drasticamente as
operações de I/O de disco e aumenta muito o desempenho.
No próximo capítulo trataremos de Backup e de outras tarefas para manter o Banco de Dados em
“plena forma” e funcionamento.
CAPÍTULO 5 – APRENDENDO SOBRE TRANSAÇÕES, BACKUP E AGENDAMENTO DE TAREFAS
Parte 2
KNOW-HOW
NOTA
Capítulo 5
APRENDENDO SOBRE TRANSAÇÕES,
BACKUP E AGENDAMENTO DE TAREFAS
SQL SERVER 2005 ADMINISTRAÇÃO E DESENVOLVIMENTO – PARTE 2: KNOW-HOW
INTRODUÇÃO
Os dados armazenados nos bancos de dados da empresa são o seu maior patrimônio. Transformar estes
dados em informações úteis para o negócio da empresa é o grande desafio da TI – Tecnologia da
Informação. É a já velha e conhecida, porém sempre atual máxima: “A informação certa, para a pessoa
certa e no tempo certo”.
Uma vez que estes dados são de vital importância, obviamente que devemos possuir mecanismos de
proteção para eles, a fim de evitar perdas (garantindo a disponibilidade), adulteração e acesso indevido
aos dados (garantindo a integridade e autenticidade dos dados). Evitar adulteração e acesso indevido
aos dados faz parte da segurança de acesso aos dados, quer da segurança lógica quanto da segurança
física – do acesso à sala dos servidores. Porém segurança é assunto para o Capítulo 6. Neste capítulo
vamos tratar das estratégias e mecanismos de implementação de rotinas de backup dos dados (cópias
de segurança dos dados). O backup é certamente uma das técnicas mais antigas e mais eficientes para
se proteger contra a perda de dados (infelizmente, por incrível que possa parecer, as atividades de
backup/restore, os planos de contingência e de recuperação a desastres, continuam não tendo a devida
atenção, cuidado e planejamento necessários).
Iniciaremos o capítulo falando sobre transações e o Log de Transações (Transaction Log) em Bancos de
Dados do SQL Server 2005. Precisamos entender o conceito de log de transações, para que possamos
estudar as diversas estratégias de backup e identificar qual a estratégia mais adequada para cada situação.
Entendido o conceito de log de transações, podemos partir para o estudo das estratégias de backup/
Restore. A operação de restore é a utilização de uma cópia de backup para “Restaurar” os dados de volta
para o Banco de Dados, em caso de perda dos originais. Por isso, não existe sentido falar somente em
backup. Quando fazemos uma cópia de segurança do Banco de Dados para outro dispositivo,
normalmente uma fita magnética ou uma pasta no HD, estamos fazendo um backup (cópia de
segurança). Se acontecer algum problema com os dados, precisamos “Restaurar” (Restore) os dados a
partir do backup, de volta para o Banco de Dados. Existe até uma brincadeira bastante conhecida entre
os DBAs: “O backup sempre funciona, o problema é o restore”. Nesta situação, o DBA (Database Ad-
ministrator) está querendo dizer que a operação de backup, normalmente, não apresenta problemas.
As maiores complicações acontecem na hora de restaurar os dados. Embora seja uma “brincadeira”,
esta afirmativa representa uma realidade, muitas vezes bastante cruel. Se não formos cuidadosos e
planejarmos com precisão o nosso sistema de backup/restore, poderemos ter problemas bastante
desagradáveis. Já pensou a reação do chefe quando você informa que não poderá restaurar os dados
com as operações financeiras da última semana porque na hora de fazer o backup foi tudo bem, porém
na hora de restaurar os dados, nada funcionou?
Uma vez entendidas as diversas estratégias de backup/restore, iremos para a implementação prática
das rotinas de backup/restore. Em um exercício prático, faremos o backup de um Banco de Dados,
depois iremos “corromper” os dados e aí teremos que restaurar os dados a partir do backup feito
inicialmente. Seguindo o padrão dos demais capítulos, aprenderemos a fazer backup/restore utilizando
o SQL Server Management Studio e também comandos T-SQL, usando a janela de execuão de comandos
do SQL Server Management Studio, a qual você já aprendeu a utilizar nos Capítulos 3 e 4.
À medida que o banco de dados vai crescendo, pode tornar-se praticamente impossível fazer o backup
manualmente. E se o backup tiver que ser feito às 5h da manhã? Ou se tiver que iniciar às 2:00 hs da
manhã, para que possa ser concluído antes das 8:00 hs, que é quando inicia o expediente? Iremos
contratar um DBA especialmente para esta tarefa? Conforme veremos, é possível “Agendar Tarefas” no
SQL Server 2005. E um ótimo exemplo de tarefa que se presta a ser agendada é a execução de rotinas de
backup, fora do horário de expediente. Aprenderemos a agendar tarefas e fazer com que, após a execução
da tarefa, uma determinada mensagem seja enviada para o DBA. Também veremos quais outros tipos
de tarefas -podem ser agendados e os demais recursos para agendamento de tarefas.
KNOW-HOW EM: CONCEITO DE LOG DE

TRANSAÇÕES NO SQL SERVER 2005
PRÉ-REQUISITOS
♦ Fundamentos apresentados na Parte I.
METODOLOGIA
♦ Apresentação teórica sobre o log de transações.
No Capítulo 2, em uma breve introdução a respeito de transações, defini uma transação da seguinte maneira:
“Uma transação, de uma maneira bastante simples, é um conjunto de operações sobre os dados, que
deve acontecer como um todo, ou seja, todas as operações contidas na transação devem ser finalizadas
com sucesso, ou nenhuma delas deve ser realizada. Caso uma das operações, contidas na transação,
venha a falhar, as operações ainda pendentes devem ser canceladas; e as operações já realizadas devem
ser revertidas. Com isso garantimos que a transação acontece como um todo, ou que nenhuma de suas
operações seja realizada.”
No Capítulo 3, onde aprendemos a criar Bancos de Dados no SQL Server 2005, nós vimos que todo
Banco de Dados deve ter, no mínimo, um arquivo de log, o qual também é chamado de Transaction
Log do Banco de Dados. Em resumo, todo Banco de Dados do SQL Server 2005 deve possuir pelo
menos um arquivo de log, sendo que não é possível desativar o mecanismo de log no SQL Server 2005.
De agora em diante iremos utilizar o termo: Log de Transações do Banco de Dados.
No Capítulo 3 escrevi o seguinte parágrafo:
“Os arquivos de log armazenam o chamado log de transações. O log de transações é um registro das
operações que são efetuadas nos dados do Banco de Dados. Veremos mais detalhes sobre o log mais adiante.”
No log de transações do Banco de Dados são registradas as seguintes operações efetuadas sobre os dados:
♦ INSERT
♦ UPDATE
♦ DELETE
No log de transações fica o registro da transação, caso esta tenha sido executada com sucesso, ou o
registro da reversão (Roll Back) da transação, caso uma ou mais das operações que compõem a transação
venha a falhar. Este mecanismo é fundamental para garantir a integridade dos dados, garantindo que
estes estejam em um estado sempre consistente.
Agora vamos detalhar um pouco mais estes conceitos.
UM POUCO MAIS SOBRE O CONCEITO DE TRANSAÇÃO

Conforme descrevemos no Capítulo 2, uma transação representa um conjunto de operações, sendo
que todas as operações devem ser executadas com sucesso. Caso uma única operação venha a falhar, as
operações restantes serão canceladas e as que já foram executadas serão “revertidas”.
Quando todas as operações são executadas com sucesso dizemos que a transação sofreu um Commit.
Quando a transação falha (pelo fato de uma de suas operações ter falhado), dizemos que a transação
sofreu um roll back. Quando a transação sofreu um roll back, os dados estarão no mesmo estado, isto
é, com os mesmos valores, que estavam antes do início da transação.
O exemplo mais típico é o que envolve a transferência entre duas contas correntes em um banco. Para
ilustrar o conceito, vamos repetir o exemplo colocado no Capítulo 2. Utilizando a terceira maior invenção
do milênio passado, que na minha opinião é o Copiar e Colar (Ctrl+C, Ctrl+V), transcrevo abaixo o
exemplo de transação apresentado no Capítulo 2:
“O pagamento pode ser feito, por exemplo, através de uma transferência da conta corrente da
concessionária, para a conta corrente do fornecedor. Neste ponto, precisamos introduzir o conceito de
transação, o qual será bastante detalhado em outros capítulos deste livro. (...)”
Para entender, na prática, o conceito de transações, vamos voltar ao exemplo anterior. Ao efetuar um
pagamento, o sistema deve transferir valores da conta corrente da concessionária para a conta corrente do
fornecedor. Estas duas ações devem acontecer no contexto de uma transação, conforme indicado abaixo:
Início da Transação
Ação 1: Debita o valor da conta corrente da Concessionária.

Ação 2: Credita o valor na conta corrente do Fornecedor.
Final da Transação.
A primeira ação efetua o débito na conta corrente da concessionária. Vamos supor que a Ação 1
ocorra com sucesso, porém, na hora de fazer o crédito na conta corrente do Fornecedor, ocorra um
problema. O que devemos fazer? O valor deve ser estornado para a conta da concessionária, ou seja,
a Ação 1 deve ser revertida, uma vez que nem todas as ações dentro da transação puderam ser
concluídas com êxito. Vejam a importância do conceito de transação, pois, neste caso, se não
usássemos transação, o valor seria debitado da conta corrente da concessionária, porém não teria
sido creditado na conta corrente do fornecedor.”
Revisado o conceito de transação, vamos analisar as características que definem uma transação. Existem
quatro características que toda transação deve apresentar:
♦ Atomicidade
♦ Consistência
♦ Isolação
♦ Durabilidade
Estas quatro características são resumidas pela sigla ACID. Vamos ver o que significa cada uma destas
características.
♦ Atomicidade: A transação deve representar uma unidade de trabalho “atômica”, isto é,

indivisível. Com isso ou todas as operações de uma transação devem ser executadas com sucesso,
ou nenhuma delas deve ser executada. Esta característica parece se confundir com o próprio
conceito de transação: ou tudo ou nada. O “nada”, conforme descrito anteriormente, é garantido
pelo mecanismo de roll back, isto é, se uma das operações que faz parte da transação falhar, as
operações já executadas serão revertidas. No SQL Server 2005, o mecanismo de log apresenta
exatamente este comportamento.
♦ Consistência: Ao ser finalizada a transação, todos os dados devem estar em um estado

consistente. Estar em um estado consistente, em um Banco de Dados relacional, significa que
todas as regras e a integridade referencial foram respeitadas. Por exemplo, uma transação não
deve ser capaz de cadastrar um pedido na tabela Pedidos, para um cliente que ainda não foi
cadastrado na tabela Clientes. Se isto acontecer, os dados não estarão em um estado consistente.
Ao final de uma transação, estruturas auxiliares, como por exemplo os índices, também deverão
ter sido atualizadas. Com o SQL Server 2005, a consistência dos dados é garantida, quer a
transação tenha sido realizada com sucesso ou tenha sofrido um roll back.
♦ Isolamento: Em um ambiente com muitos usuários, diversas transações serão executadas

simultaneamente. O mecanismo de isolamento garante que uma determinada transação não
utilizará dados em um estado intermediário. Vamos supor que uma transação que chamaremos
TR1 tenha iniciado. Antes que TR1 tenha terminado inicia-se uma segunda transação TR2.
Agora imagine que uma das operações de TR2 precise acessar dados que estejam sendo
modificados por TR1. Pelo mecanismo do isolamento, TR2 terá acesso aos dados no estado em
que estes encontravam-se antes do início de TR1 – caso TR1 ainda não tenha sido encerrada –
ou no estado após o encerramento de TR1 – caso TR1 já tenha sido encerrada. Desta maneira
uma transação (no nosso exemplo TR2) não será afetada por valores que tenham sido alterados
por outra transação (no nosso exemplo TR1), enquanto estas alterações não tenham se tor-
nado definitivas, isto é, a transação tenha sido completada com sucesso. Existem diferentes
níveis de isolamento, os quais serão estudados no Capítulo 10: Read uncommitted, Read com-
mitted, Repeatable read e Serializable.
♦ Durabilidade: Uma vez encerrada a transação, as alterações por ela efetuadas serão definitivas.
Mesmo que ocorra alguma falha com o SQL Server, o sistema operacional ou o equipamento,
quando o SQL Server 2005 for reinicializado as transações que estão no log e ainda não
foram “aplicadas” ao Banco de Dados serão aplicadas, fazendo com que as modificações
tornem-se permanentes.
Vamos analisar um pouco melhor o que significa “aplicar” uma transação ao Banco de Dados.
COMO FUNCIONA O LOG DE TRANSAÇÕES

Quando estamos desenvolvendo uma aplicação – quer seja em Visual Basic, VB.NET, ASP, ASP.NET,
Microsoft Access, Delphi, C#, etc. –, que acessa dados em um servidor SQL Server 2005, devemos
definir o início e o fim de uma transação no próprio aplicativo, e desta maneira controlamos quais
operações devem acontecer no contexto de uma transação. Por exemplo, podemos criar uma página
ASP que executa no contexto de uma transação; desta maneira todas as operações realizadas pela
página ASP, em um Banco de Dados do SQL Server 2005, ocorrerão no contexto de uma transação: ou
todas são executadas com sucesso (Commit) ou todas falham (Roll Back).
Quando uma transação é iniciada e as operações individuais – INSERT, DELETE ou UPDATE – começam
a ser enviadas para o Banco de Dados, os seguintes passos são executados no servidor SQL Server 2005:
1. As páginas que contêm os dados que estão sendo afetados (ou a página na qual os dados serão
inseridos) são localizadas no disco e carregadas na memória, a qual é chamada de Cache de
dados. Antes de carregar uma página no cache de dados, o SQL Server 2005 verifica se a página
já está no cache de dados. Se a página não estiver no cache, ela será localizada no disco e
carregada na memória.
2. As alterações/inclusões/exclusões nunca são feitas diretamente no disco, mas sim nas páginas
de dados carregadas na memória. As alterações/inclusões/exclusões são então registradas no
arquivo de log. Neste momento as modificações estão registradas apenas no log e não foram
ainda realizadas nos arquivos de dados, no disco.
3. Um processo chamado de Checkpoint é responsável por fazer com que as transações que tenham
sido completadas com sucesso (Commit) sejam aplicadas ao Banco de Dados periodicamente,
fazendo com que as modificações sejam definitivamente aplicadas ao Banco de Dados, isto é,
gravadas no disco. O processo de checkpoint grava no log de transações informações para
saber quais transações já foram aplicadas ao Banco de Dados e quais ainda não foram. Transações
que sofreram um roll back não serão aplicadas ao Banco de Dados. O processo de checkpoint
fica periodicamente checando se existem transações completadas com sucesso (Committed
Transactions) no log do Banco de Dados, as quais ainda não foram executadas no arquivo de
dados, no disco. Caso aconteça alguma falha que interrompa o servidor SQL Server 2005, um
processo de recuperação automática é disparado na próxima inicialização do servidor. Este
processo de recuperação automática faz com que transações que forem completadas e não
aplicadas ao Banco de Dados sejam aplicadas neste momento, garantindo, com isto, a
“durabilidade” da transação.
Agora que conhecemos o conceito de transação e o mecanismo do log de transações no SQL Server
2005, podemos estudar algumas estratégias de backup que utilizam o log de transações.
KNOW-HOW EM: TIPOS E ESTRATÉGIAS DE BACKUP

PRÉ-REQUISITOS
METODOLOGIA
♦ Apresentação teórica sobre tipos e estratégias de backup.
Antes de aprendermos a criar backups/restore na prática, precisamos aprender sobre os tipos de backup
disponíveis e sobre as estratégias de backup/restore mais utilizadas.
INTRODUÇÃO
Sendo as informações o bem mais valioso da sua empresa e estando estas informações armazenadas
nos bancos de dados da empresa, é de fundamental importância que tenhamos uma estratégia bem
definida para a proteção deste bem tão valioso. Devemos nos preocupar não apenas com a perda dos
dados, mas também com acessos indevidos ou até mesmo com roubo de informações. Se um concorrente
conseguir invadir a sua rede e copiar dados estratégicos você estará com um grande problema.
Também pode haver perda de dados por erros humanos, como a utilização de comandos do SQL. O caso mais
típico é a utilização de um comando DELETE sem uma cláusula WHERE, como exemplificado a seguir:
DELETE * FROM Clientes
Este comando, aparentemente inocente, irá apagar todos os registros da tabela Clientes. E se você não
tiver uma boa estratégia de backup? Problemas à vista.
Cada vez mais as empresas conectam suas redes locais à Internet. Os benefícios são muitos, porém
existem também problemas. Ao conectar a rede da empresa com a Internet, devemos nos preocupar
com diversos fatores que podem causar danos às informações armazenadas no Banco de Dados, como
por exemplo:
♦ Invasões e ataques de hackers.
♦ Perda de informações devido a problemas com vírus.
♦ Acesso indevido às informações.
Como se tudo isso não bastasse também devemos nos preocupar com a segurança física, desastres
naturais e problemas com hardware.
De nada adianta você configurar cuidadosamente a segurança de acesso aos dados do Servidor SQL
Server, ter uma boa estratégia de backup/restore se qualquer um puder entrar na sala onde estão as fitas
de backup e levar a fita em baixo do braço, para ler os dados em outro lugar. Existe um caso bastante
conhecido em que um estranho ligou para a empresa e pediu para que o DBA deixasse a fita com o
backup dos dados na portaria. Sem maiores preocupações a fita foi deixada com o porteiro que a
entregou para a pessoa que havia solicitado. Veja que situação cômica se não fosse tão grave. Por isso
a segurança física deve fazer parte da política de segurança da empresa.
Desastres naturais não devem ser desconsiderados. Incêndios, inundações e outros acontecem e devem
ser levados em conta na hora de montarmos a política de segurança da empresa. Vamos supor que para
a empresa seja de fundamental importância que seu site esteja disponível 100% do tempo, mesmo em
caso de calamidades. Neste caso você deve considerar a hipótese de ter os dados duplicados em duas ou
mais localidades físicas diferentes, como por exemplo: Rio de Janeiro e São Paulo. Desta forma, se o
escritório do Rio de Janeiro pegar fogo, as operações podem ser deslocadas para o site de São Paulo, o
qual deve ser uma cópia fiel do site do Rio de Janeiro. No Capítulo 8 você aprenderá sobre a replicação
de dados, o que nos permite manter cópias idênticas dos dados em diversos servidores.
Outra situação que devemos considerar é o local de armazenamento das fitas de backup. É comum
vermos empresas que armazenam as fitas de backup na própria sala dos servidores de Banco de
Dados; desta maneira se a sala pegar fogo, já queima os servidores e também as fitas, e a empresa
perde todas as cópias dos dados. Já deu para perceber que esta é uma péssima estratégia? O ideal é
termos uma sala separada para o armazenamento das fitas de backup, de preferência uma sala-cofre
à prova de fogo e inundações.
Falhas de hardware acontecem e devemos estar preparados para este tipo de falha. Aquele disco de 300
GB com os arquivos do Banco de Dados de vendas pifou? E agora? Se a nossa estratégia de backup foi
eficiente, é só substituir o disco e restaurar os dados a partir do backup. Podem existir situações em que
o tempo necessário para restaurar os dados a partir do backup é inaceitável. Por exemplo, o site da
empresa não pode esperar, digamos, 6 horas para que os dados sejam restaurados. Nesta situação
podemos considerar a hipótese de manter cópias idênticas dos dados em dois ou mais servidores.
Conforme descrito anteriormente, podemos fazer esta duplicação dos dados utilizando Replicação.
Desta maneira se houver uma falha de hardware em um dos servidores, outro servidor pode assumir o
trabalho do servidor que falhou. No SQL Server 2005 temos novidades que facilitam a criação de
servidores e bancos de dados duplicados. São os novos recursos de: Databases Snapshots e Mirroring,
os quais serão vistos no Capítulo 15, onde apresentarei uma série de exemplos práticos, relacionados
com as novidades do SQL Server 2005.
Um fator que devemos levar em consideração, na hora de montarmos a nossa estratégia de backup/
restore e proteção dos dados, é o valor da informação que está sendo protegida. Se a informação a ser
protegida é de valor estratégico para a empresa, e os dados precisam estar sempre disponíveis e nem se
imagina a hipótese de perdê-los; é evidente que os gastos para proteger esta informação serão elevados,
porém mais facilmente justificáveis. Em resumo, o nível de investimento em segurança e backup é
proporcional à importância dos dados para a empresa.
Devemos identificar os requisitos de disponibilidade dos dados quando formos escolher a nossa estratégia
de backup. Vamos supor que o requisito seja: os dados devem estar disponíveis 100% do tempo. Neste
caso é plenamente justificável a utilização de dois ou mais servidores SQL Server 2005 com cópias
idênticas dos dados, de tal maneira que, se um deles apresentar problemas, um dos outros pode assumir
no seu lugar. Nesta situação, a simples utilização de backup em fita não atenderia o requisito de
disponibilidade, uma vez que os dados estariam indisponíveis durante o tempo de restauração da fita
para o Banco de Dados.
A seguir coloco mais algumas questões que devemos levar em consideração ao montarmos a nossa
estratégia de backup/restore:
♦ Quais os requisitos de disponibilidade? O Banco de Dados deve estar on-line as 24 horas do

dia, sete dias por semana ou pode ser colocado off-line em determinados horários?
♦ Qual o custo de parar as operações da empresa devido à indisponibilidade dos dados? Qual o
custo – financeiro e para a imagem da empresa – quando o site da empresa fica indisponível,
devido a problemas com o Banco de Dados?
♦ Em caso de uma falha de hardware qual é o tempo aceitável até a restauração da normalidade?
♦ A sua empresa possui um DBA dedicado ou o serviço é terceirizado? Quem é o responsável

pelas rotinas de backup? Quem é o responsável por verificar se os procedimentos de backup/
restore estão sendo realizados em conformidade com a estratégia proposta?
Outras questões podem ser relevantes para a sua empresa. O importante é fazer um planejamento
bastante cuidadoso.
Em uma estratégia de backup definimos o tipo de backup a ser utilizado (conforme veremos a seguir),
bem como a freqüência do backup.
Pela importância do procedimento vou repetir a seguinte recomendação: “Não basta fazer o backup,
precisamos de uma estratégia de testes e simulação de restauração dos dados, pois muitas vezes o backup
é completado sem problemas, mas na hora de restaurar os dados é que acontecem os problemas. Por isso
uma rotina de testes de restauração a partir dos backups deve fazer parte da nossa estratégia de backup.“
MÉTODOS DE BACKUP QUANTO AO CONTEÚDO DO BACKUP

Quanto ao conteúdo do backup, temos duas abordagens para o backup de um Banco de Dados:
♦ Fazer o backup somente do Banco de Dados: Com esta abordagem o backup do Banco de
Dados é feito periodicamente. Caso aconteça algum problema com o Banco de Dados, as
alterações que tenham sido feitas desde o último backup serão perdidas. Considere o exemplo
da Figura 5.1.
Figura 5.1 backup somente do Banco de Dados.
Fazer o backup apenas do Banco de Dados apresenta como principal vantagem a simplicidade, e como
principal desvantagem a perda das alterações entre o último backup e o momento em que o problema
ocorre no Banco de Dados. Com esta abordagem, a restauração também é bastante simples, conforme
veremos mais adiante, na parte prática deste capítulo. Utilizamos este tipo de abordagem para pequenos
Bancos de Dados devido a sua simplicidade. Para Bancos de Dados maiores, mais complexos, devemos
fazer o backup também do log de transações, conforme descrito a seguir.
♦ backup do Banco de Dados e do log de transações: Com esta abordagem fazemos o backup
de todo o Banco de Dados menos freqüentemente do que no caso anterior; em contrapartida é
feito o backup do log de transações entre os backups do Banco de Dados. Poderíamos ter a
seguinte estratégia de backup:
1. Backup do Banco de Dados no domingo às 20h.
2. Backup do log de transações na segunda-feira às 9:00, 15:00, 18:00 e 21:00h
3. Backup do log de transações na terça-feira às 9h, 15h, 18h e 21h.
4. Backup do log de transações na quarta-feira às 9h, 15h, 18h e 21h.
5. Backup do log de transações na quinta-feira às 9h, 15h, 18h e 21h.
6. Backup do log de transações na sexta-feira às 9h, 15h, 18h e 21h.
7. Backup do log de transações no sábado às 9h, 15h, 18h e 21h.
8. Backup do Banco de Dados no domingo às 2h.
Agora vamos imaginar que o Banco de Dados tenha sido corrompido na sexta-feira, às 20h. A que
situação podemos restaurá-lo?
Poderemos restaurá-lo à situação do último backup do log de transações, que no caso foi feito na sexta-
feira às 18h. Na verdade, conforme veremos mais adiante, é possível, dependendo das condições,
restaurar o Banco de Dados até próximo do horário em que o banco foi corrompido, digamos um
minuto antes de o banco ter sido corrompido. Neste caso apenas as alterações feitas por transações que
ainda não tenham sido completadas (Committed Transactions) serão perdidas.
NOTA
No próximo item veremos as estratégias para a restauração do Banco de Dados quando utilizamos backups do Banco de Dados e do log de
transações.
Este tipo de abordagem é mais complexa do que a anterior, sendo indicada para Bancos de Dados
maiores e que não podem, em hipótese alguma, perder alterações que tenham sido feitas desde o
último backup do banco de dados. A complexidade aumenta, principalmente, na hora de restaurar os
dados. Utilizando o exemplo anterior, em que o banco de dados corrompeu na sexta-feira, às 20h,
teríamos que restaurar o backup do Banco de Dados feito no domingo e todos os logs de transação
feitos neste intervalo. A restauração tem que ser feita em seqüência. Além disso, ao restaurarmos os
logs de transação, estes devem ser restaurados na ordem cronológica em que foram feitos. É como se
estivéssemos “aplicando” novamente todos os comandos que foram executados no Banco de Dados,
uma vez que o llog de transações é um registro dos comandos executados no Banco de Dados,
principalmente comandos que inserem, alteram ou excluem dados.
Temas uma novidade importante do SQL Server 2005, em relação ao backup/restauração do banco de
dados. Com o SQL Server 2000, o banco de dados permanece indisponível para uso, durante todo o
processo de restauração, o que aumenta o tempo de indisponibildiade do banco de dados. Já o SQL
Server 2005 suporta um recurso conhecido como “Partil Restore”. No SQL Server 2005, o banco de dados
passa a estar disponível para uso, assim que for concluída a restauração do filegroup Primary. O filegroup
Primary contém as informações da estrutura do banco de dados, sem as quais não é possível colocar um
banco de dados on line. Uma vez restaurado o filegroup Primary, o banco de dados passa a estar online
e disponível para o uso e o processo de restauração continua. Se um usuário tentar acessar um conjunto
de dados que ainda não foi restaurado (por exemplo, dados que estão em filegroups que ainda não foram
restaurados), o usuário receberá uma mensagem de que os dados estão off-line e que ele deve tentar
novamente mais tarde. Se o usuário tentar acessar dados de um filegroup que já foi restaurado, os dados
serão acessados, normalmente, e o usuário nem fica sabendo que o processo de restauração dos demais
filegroups ainda está em andamento (a não ser por uma queda no desempenho, queda esta que será
perfeitamente normal, para o caso de uma restauração de backup estar em andamento).
Outra novidade do SQL Server 2005, na área de backup/restore, é conhecida como “Concurrente Data-
base and Log backups”, ou seja, a possibilidade de fazer o backup, ao mesmo tempo, tanto do banco de
dados quando do log de transações do banco de dados. No SQL Server 2000 você primeiro tinha que
aguardar o backup do banco de dados ser completado, para depois poder fazer o backup do log de
transações. No SQL Server 2005 não existe mais esta limitação, sendo possível fazer o backup do banco
de dados e do log de transações, simultaneamente. Pode parecer que não seja de grande importância
esta nova funcionalidade, mas é. Em grandes bancos de dados, um dos principais problemas é a chamada
janela de backup ou, em palavras mais simples, o tempo que o backup demora para ser completado.
Com a possibilidade de fazer o backup do banco de dados e do log de transações, simultaneamente,
você pode instalar duas ou mais unidades de fita e fazer o backup de ambos ao mesmo tempo, o que
pode diminuir, consideravelmetne, a janela de backup. Porém ainda existe uma limitação, que é a de
somente poder fazer o backup de um dos arquivos de dados de um banco de dados (arquivos .mdf ou
.ndf), por vez. Quem sabe no SQL Server 2005 esta limitação seja superada?
TIPOS DE BACKUP
Com o SQL Server 2005 podemos ter os seguintes tipos de backup:
♦ backup completo – full backup.
♦ backup diferencial.
♦ backup do log de transações.
♦ backup de filegroups.
♦ backup de arquivos de dados.
Dependendo do tipo de backup a ser utilizado, teremos diferentes estratégias, conforme veremos mais
adiante. Vamos estudar em detalhes cada um destes tipos.
♦ backup completo – full backup: Este tipo de backup faz o backup de todo o Banco de Dados,
incluindo todos os filegroups e arquivos de dados que fazem parte do Banco de Dados. Caso
tenhamos mais de um Banco de Dados, devemos fazer o backup de todos eles. Neste tipo de
backup é feita a cópia de todo o Banco de Dados, independente das alterações que tenham sido
feitas desde o último backup. Para grandes Bancos de Dados pode não ser viável a utilização de
uma estratégia baseada somente neste tipo de backup, devido ao tempo que o backup pode
demorar, pois a cada backup todo o Banco de Dados é copiado para a mídia de backup (fita,
CD, disco rígido, etc.). Este tipo de backup somente é aconselhável para pequenos Bancos de
Dados devido a sua simplicidade.
♦ backup diferencial: Quando utilizamos o backup diferencial, apenas as informações que
foram alteradas desde o último backup completo é que serão copiadas. O backup diferencial
é mais rápido do que o backup completo, pois um número menor de informações (somente
as que foram alteradas. Entenda-se informações como sendo páginas de dados, sendo que
em uma página de dados pode haver diversos registros.) é copiado. Copiando menos
informações, o backup é finalizado mais rapidamente. Para grandes Bancos de Dados o tempo
de backup, chamado de “janela de backup”, é um fator crítico. Vamos supor que o Banco de
Dados somente possa ser retirado do ar para backup entre 1h e 5h da manhã. Neste caso
somente teremos 4 horas como janela de backup. Usando uma estratégia que mescla back-
ups completos com backups diferenciais, para restaurar o Banco de Dados, em caso de falha,
devemos restaurar o último backup completo, mais o último backup diferencial e mais os
backups do log de transações na seqüência correta. Conforme pode ser visto, o processo de
restauração também a torna mais complexo com a utilização do backup diferencial. Pode
parecer que o backup diferencial somente introduz complicações desnecessárias mas, na
prática, em muitas situações o backup completo simplesmente não é uma opção viável devido
ao tempo disponível para backup – janela de backup.
♦ backup do log de transações: Este tipo de backup permite que façamos o backup do log de
transações do Banco de Dados. Conforme veremos no próximo item, com a utilização de backup
do log de transações podemos reduzir a probabilidade de perda de dados.
♦ backup de filegroups: Com este tipo de backup podemos fazer o backup de todos os arquivos
de dados associados com um filegroup (podendo ser arquivos de um ou mais bancos de dados).
Apenas para recordar, os arquivos de log são armazenados separadamente, sendo que estes não
fazem parte de nenhum filegroup. Todos os arquivos de dados são copiados para o backup,
independente de terem havido alterações ou não nos dados.
♦ backup de arquivos de dados: Com este tipo de backup, podemos copiar apenas um arquivo
específico, quer seja um arquivo primário (.mdf) ou arquivo secundário (.ndf). Uma vez que
podemos fazer o backup de um único arquivo de dados, evidentemente que também é possível
restaurar um único arquivo de dados.
NOTA
O backup de filegroup e o backup de arquivo de dados podem ser uma solução para Bancos de Dados muito grandes, em que até mesmo um
backup diferencial não caberia na janela de tempo do backup.
ALGUNS EXEMPLOS DE ESTRATÉGIAS DE BACKUP/RESTORE

Vamos ver alguns exemplos teóricos de estratégias de backup/restore, onde consideramos os diferentes
tipos de backup: completo, diferencial e do log de transações.
♦ Exemplo 01: O backup completo diário do Banco de Dados: Nesta estratégia fazemos um
backup completo do Banco de Dados diariamente. Vamos considerar a programação de backup
descrita na Tabela 5.1.
Tabela 5.1 Backup completo do Banco de Dados.
Dia Backup/horário(s)
Segunda-feira Completo às 23h

Terça-feira Completo às 23h
Quarta-feira Completo às 23h
Quinta-feira Completo às 23h
Sexta-feira Completo às 23h
Sábado Completo às 23h
Domingo Completo às 23h
♦ Hipótese: Na quinta-feira, às 9 horas da manhã o Banco de Dados é corrompido.
♦ Recuperação do Banco de Dados: Nesta situação somente poderemos restaurar os dados na

situação em que estes estavam na quarta-feira, às 23 horas, que foi o horário do último backup
completo. Todas as alterações realizadas, entre as 23 horas de quarta-feira e o momento em que
o Banco de Dados foi corrompido, serão perdidas.
♦ Procedimento de restore: Restaurar o último backup completo disponível, que neste caso é o
backup da quarta-feira às 23h.
♦ Exemplo 02: O backup completo combinado com o backup do log de transações: Nesta estratégia
fazemos um backup completo do Banco de Dados em períodos mais espaçados, digamos uma
ou duas vezes por semana. Entre um backup completo e outro, são feitos backups do log de
transações. Vamos considerar a programação de backup descrita na Tabela 5.2.
Tabela 5.2 Backup completo do Banco de Dados mais backup do Log de transações.

Domingo Backup do log às 9h, 12h, 15h e 18h
Segunda-feira Backup do log às 9h, 12h, 15h e 18h
Terça-feira Backup do log às 9h, 12h, 15h e 18h
Quarta-feira Backup do log às 9h, 12h, 15h e 18h
Quinta-feira Backup do log às 9h, 12h, 15h e 18h
Sexta-feira Backup do log às 9h, 12h, 15h e 18h
♦ Hipótese: Na quinta-feira, às 9h30 o Banco de Dados é corrompido.
♦ Recuperação do Banco de Dados: Neste situação poderemos restaurar os dados à situação em

que estes estavam na quinta-feira, às 9h, que foi o horário do último backup do log de transações.
Todas as alterações realizadas entre as 9h e 9h30 da quinta-feira, e o momento em que o Banco
de Dados foi corrompido, serão perdidas. Na verdade existem algumas técnicas avançadas que
permitem recuperar os dados até próximo da hora em que o banco foi corrompido.
Aprenderemos estas técnicas mais adiante, neste capítulo.
Procedimento de restore: Restaurar o backup completo do sábado às 23h e todos os backups do log de
transações, na seqüência correta, até o backup do log de transações da quinta-feira às 9h.
Observe que nesta situação teríamos que restaurar 18 backups:
♦ um completo do sábado +
♦ quatro backups do Log do domingo (9h, 12h, 15h e 18h) +
♦ quatro backups do Log da segunda-feira (9h, 12h, 15h e 18h) +
♦ quatro backups do Log da terça-feira (9h, 12h, 15h e 18h) +
♦ quatro backups do Log da quarta-feira (9h, 12h, 15h e 18h) +
♦ um backup do Log da segunda-feira (9h)
Total = 18 backups a serem restaurados.
Conforme podemos conferir pelo exemplo, esta estratégia é mais complexa na hora de restaurar o
Banco de Dados, porém temos uma perda de alterações bem menor do que no caso da utilização de
somente backup completo. Em caso de perdas, estas são em menor número do que no caso do backup
somente do Banco de Dados.
♦ Exemplo 03: O backup completo combinado com o backup diferencial e com o backup do log
de transações: Nesta estratégia fazemos um backup completo do Banco de Dados em períodos
mais espaçados, uma ou duas vezes por semana. Entre um backup completo e outro são feitos
backups do log de transações e também um backup diferencial na quarta-feira. Vamos considerar
a programação de backup descrita na Tabela 5.3.
Tabela 5.3 Utilizando backups completos, diferenciais e do log de transações.

Backup diferencial às 23h
Sábado Diferencial às 23h
Continua
Continua

Backup diferencial às 23h
Sábado Diferencial às 23h
Observe que somente fizemos um backup completo no início do ciclo, depois vamos fazendo
nas quartas e sábados backups diferenciais e, entre os backups diferenciais, quatro backups diários
do log de transações.
Hipótese: Na quinta-feira, às 9h30, o Banco de Dados é corrompido.
Recuperação do Banco de Dados: Nesta situação poderemos restaurar os dados à situação em que estes
estavam na quinta-feira, às 9h, que foi o horário do último backup do log de transações. Todas as
alterações, realizadas entre as 9h e 9h30 da quinta-feira e o momento em que o Banco de Dados foi
corrompido, serão perdidas. Na verdade existem algumas técnicas avançadas que permitem recuperar
os dados até próximo da hora em que o banco foi corrompido. Aprenderemos estas técnicas mais
adiante, neste capítulo.
Procedimento de restore: Restaurar o backup completo do sábado às 23h, depois restaurar o backup
diferencial da quarta-feira às 23h e o backup do log de transações da quinta-feira às 9h.
Observe que nesta situação teríamos que restaurar três backups:
♦ um completo do sábado +
♦ um diferencial na quarta-feira (23h) +
♦ um backup do log da quinta-feira (9h)
Total = 3 backups a serem restaurados.
Fica bastante claro que a utilização do backup diferencial facilita muito o processo de restauração do
Banco de Dados que, conforme salientado pelo exemplo, diminui o número de backups que devam ser
restaurados, em relação a uma estratégia que usa somente backups completos e do log de transações.
Com o SQL Server 2005 podemos efetuar o backup com o Banco de Dados on-line, isto é, sendo
utilizado por uma ou mais aplicações. Porém não poderemos criar ou excluir arquivos de dados –
primários (.mdf) ou secundários (.ndf) enquanto o backup estiver sendo realizado.
Agora que conhecemos a parte teórica a respeito do log de transações e dos tipos de backup possíveis
no SQL Server 2005, podemos aprender a fazer o backup dos dados e a restaurar os dados, quando
necessário. Mas antes um pouco sobre backup devices.
Estou utilizando um computador que não possui drive de fita instalado, por isso, nos exemplos deste capítulo, farei o backup em uma pasta
NOTA
do disco rígido. Na prática um servidor com o SQL Server 2005, usado em um ambiente de produção na empresa, certamente terá um drive
de fita para efetuar o backup, sendo esta a estratégia recomendada. Não é recomendada a realização de backups no disco rígido, pois se o
disco rígido for danificado o backup será perdido. Fazer o backup no disco rígido é análogo à situação em que as fitas de backup são
guardadas na mesma sala do servidor. O princípio básico é que devemos deixar, fisicamente separados, os dados e as mídias de backup. Se
possível em prédios separados com as fitas de backup em uma sala-cofre à prova de fogo.
KNOW-HOW EM: O CONCEITO BACKUP

DEVICES E CRIAÇÃO DE BACKUP DEVICES
PRÉ-REQUISITOS
♦ Noções sobre o log de transações.
♦ Noções sobre estratégias de backup.
♦ Fundamentos apresentados na Parte I do Livro.
METODOLOGIA
♦ Apresentação teórica sobre backup Devices.
TÉCNICA
♦ Utilizar o SQL Server Management Studio e a janela de execução de comandos T-SQL para a criação de backup Devices.
Ao efetuarmos um backup devemos especificar um “backup device”, onde o backup será efetuado.
Conforme veremos a seguir, um backup device é um conceito que associa um dispositivo físico de
backup, como um drive de fita ou um volume em um disco rígido, com um backup device. Falando de
uma maneira bastante simples, o backup device é um “nome” que associamos com um dispositivo
físico de backup, como por exemplo um drive de fita. Depois, na hora de fazer o backup, utilizamos o
nome (backup device) ao invés de utilizar o caminho físico para o dispositivo. O objetivo básico do
backup device é facilitar a identificação dos dispositivos físicos de backup.
Vamos aprender um pouco mais sobre backup devices.
O QUE SÃO BACKUP DEVICES?

Com o SQL Server 2005 podemos fazer o backup do Banco de Dados, do log de transações ou dos
arquivos de dados para fita ou disco rígido. Para que possamos fazer um backup, devemos criar um
backup device associado ao dispositivo onde será realizado o backup. Com isso teremos backup de-
vices de disco e backup devices de fita.
♦ backup devices de disco: Este tipo de device é associado com um arquivo no disco rígido. O
arquivo associado com o backup device é um arquivo como outro qualquer. Podemos associar
um backup device de disco com um arquivo localizado no disco rígido local ou em um
compartilhamento da rede. O tamanho máximo para este tipo de backup device é limitado
apenas pelo espaço disponível em disco.
Ao efetuarmos um backup em uma pasta compartilhada, podemos utilizar a convenção de nomes UNC – Universal Naming Convention. O
NOTA
formato é \\nome_do_servidor\nome_do_compartilhamento. A conta com a qual está rodando o servidor SQL deve ter permissão de
escrita (Write) na pasta compartilhada, onde será efetuado o backup, para que o backup possa ser efetuado com sucesso. Ao efetuarmos um
backup através da rede sempre devemos levar em consideração o tráfego de rede gerado pelo backup.
♦ Backup devices de fita: São backup devices associados com um drive de fita. O drive de fita deve
estar instalado no servidor SQL Server 2005, onde o backup será efetuado, isto é, não posso
acessar um drive de fita que está em outro servidor. Caso o backup não caiba em uma fita, o SQL
Server 2005 solicita que uma nova fita seja inserida e continua o backup nesta nova fita.
DEVICES LÓGICOS E DEVICES FÍSICOS

Podemos fazer referência a um backup device tanto utilizando o seu nome lógico quanto o nome
físico. O nome físico do backup device é o nome utilizado pelo Windows para identificar o backup
device, como por exemplo: C:\sqlbackup\clientes\backup_clientes.bak.
Conforme descrito anteriormente um backup device lógico é um nome (apelido do inglês “alias”)
utilizado para identificar, fazer referência ao device físico. A associação entre o device lógico e o device
físico é armazenada na tabela sysdevices do Banco de Dados master, conforme indicado na Figura 5.2.
Figura 5.2 A tabela sysdevices do Banco de Dados master.
Um device é criado no servidor\instância e pode ser utilizado para fazer o backup de qualquer Banco
de Dados do servidor\instância.
A principal vantagem da utilização de device backup lógicos é a simplicidade; por exemplo, é muito
mais fácil fazer referência a backup_clientes do que a C:\sqlbackup\clientes\backup_clientes.bak.
Ao efetuarmos o backup de um Banco de Dados podemos utilizar tanto o backup device físico quanto
o backup device lógico. Conforme descrito no parágrafo anterior o backup device lógico facilita e
simplifica a referência ao dispositivo de backup.
CRIANDO UM BACKUP DEVICE LÓGICO COM O SQL SERVER MANAGEMENT STUDIO

Agora vamos aprender a criar um backup device lógico, com as seguintes características:
♦ Nome: backup_clientes
♦ Localização física: D:\backups\backup_clientes.bak.
Embora estejamos criando um device chamado backup_clientes, não significa que somente poderemos
fazer o backup do Banco de Dados Clientes, neste device. Conforme descrito anteriormente, um backup
device é criado em nível de servidor\instância e posso fazer o backup de qualquer Banco de Dados para
o backup device.
NOTA
Crie a pasta D:\backups ou outra pasta que você for utilizar para acompanhar este exemplo, antes de criar o device backup. Caso a pasta
ainda não exista será emitido um aviso na hora da criação do backup device.
Exemplo prático: Para criar o backup device backup_clientes, usando o SQL Server Management Stu-
dio, siga os passos indicados a seguir:
-> Microsoft SQL Server -> SQL Server Management Studio).
Figura 5.3 Criando um novo bakcup device.
2. Na janela Object Browser, dê um clique no sinal de + ao lado da instância na qual você irá criar
o backup device.
3. Nas opções que surgem abaixo desta instância, clique no sinal de mais ao lado da opção Man-
agement para expandi-la. Abaixo de Management existe uma opção backup Devices, a qual
utilizaremos para criar o backup device backup_clientes.
4. Dê um clique com o botão direito do mouse na opção backup Devices. No menu de opções que
surge, dê um clique na opção New backup Device. Surge a janela para a criação de um novo
backup device, conforme indicado na Figura 5.3.
5. No campo Device Name digite: backup_clientes.
6. No campo File Name digite: D:\backups\backup_devices.BAK. Ao invés de digitar o caminho

completo, você pode utilizar o botão com as reticências (...) para navegar até a pasta onde deve
ser criado o backup device.
Observe que a opção Tape está desabilitada, pois no servidor que estou utilizando não existe um drive
de fita instalado, conforme descrito anteriormente.
Sua janela deve estar conforme indica a Figura 5.4.
Figura 5.4 Criando o backup device backup_clientes.
7. Dê um clique no botão OK e pronto; o backup device backup_clientes foi criado e está associado
com a pasta D:\backups\backup_clientes.bak.
Para conferir se o device foi criado com sucesso verifique se já aparece, abaixo da opção backup De-
vices, o device backup_clientes. Caso esta opção ainda não esteja sendo exibida, clique na opção Backup
Devices para selecioná-la e pressione a tecla F5, para atualizar a listagem. O backup device backup_clientes
já deve estar sendo exibido, conforme indicado na Figura 5.5.
Figura 5.5 backup device backup_clientes criado com sucesso.
Exercício 1: Utilizando o SQL Server Management Studio, crie os seguintes backup devices:
1. Device 1:
Nome: backup_produtos
Localização física: D:\backups\backup_produtos.bak
2. Device 2:
Nome: backup_pedidos
Localização física: C:\backups\backup_pedidos.bak.
NOTA
Crie a pasta C:\backups ou outra pasta que você for utilizar para acompanhar este exemplo, antes de criar o device backup. Caso a pasta
ainda não exista, será emitido um aviso na hora da criação do backup device.
CRIANDO UM BACKUP DEVICE LÓGICO USANDO COMANDOS T-SQL

Para criarmos um backup device utilizamos o comando sp_addumpdevice na janela de execução de
comandos T-SQL do SQL Server Management Studio. Na verdade, este é um stored procedure que faz
parte do Banco de Dados master. Conforme descrevemos anteriormente, existe uma série de stored
procedures no banco master, as quais são utilizadas para várias tarefas administrativas no SQL Server
2005, como, por exemplo, criar um backup device. A seguir, temos a sintaxe deste comando, conforme
descrito no Books Online:
Sintaxe completa – Books OnLine – Transact SQL Reference:

exec sp_addumpdevice [ @devtype = ] ‘device_type’ ,
[ @logicalname = ] ‘logical_name’ ,
[ @physicalname = ] ‘physical_name’
[ , { [ @cntrltype = ] controller_type
| [ @devstatus = ] ‘device_status’
}
]
Este formato genérico não é muito intuitivo, ou melhor, não é nada intuitivo. A seguir apresento uma
sintaxe simplificada, somente com as principais opções para criar uma tabela com alguns campos.
Sintaxe simplificada:
exec sp_addumpdevice ‘tipo: disk ou tape’, ‘nome_lógico’, ‘caminho físico’
Um exemplo simples que cria um backup device no disco:
USE master
exec sp_addumpdevice ‘disk’, ‘backup_geral’, ‘C:\backups\geral.bak’
NOTA
Observe que antes de utilizarmos o comando sp_addumpdevice tornamos o Banco de Dados master o banco atual. Isto é necessário porque
as informações sobre os backups device são armazenadas na tabela sysdevices do Banco de Dados master.
Agora um exemplo que cria um device associado ao compartilhamento “backups” no servidor “server05”:
USE master
exec sp_addumpdevice ‘disk’, ‘backup_rede’, ‘\\server05\backups\rede.bak’
Mais um exemplo simples que cria um backup device associado ao drive de fita:
USE master
exec sp_addumpdevice ‘tape’, ‘fita_srv01’, ‘\\.\tape0’
NOTA
\\.\tape0 é uma referência ao drive de fita.
Agora vamos utilizar a janela de execução de comandos T-SQL para criar um backup device lógico,
com as seguintes características:
♦ Nome: backup_Exemplo1
♦ Localização física: D:\backups\backup_exemplo1.bak.
NOTA
Este dispositivo será utilizado, mais adiante, para fazer um backup do Banco de Dados Exemplo 1 que criamos no Capítulo 3.
Exemplo prático: Para criar o backup device backup_exemplo1, siga os passos indicados a seguir:
2. Na janela Object Explorer, clique com o botão direito do mouse na instância na qual você
deseja criar o backup device. No menu de opções que é exibido, clique em New Query.
3. Será aberta a janela de execução de comandos T-SQL, com a qual você já trabalhou diversas vezes.
4. Para criar o backup device backup_exemplo1 proposto, digite o seguinte comando:

exec sp_addumpdevice ‘disk’, ‘backup_exemplo1’, ‘D:\backups\exemplo1.bak’
5. Pressione Ctrl+E (ou tecle F5) para executar o comando.
O comando é executado com sucesso e a seguinte mensagem é exibida:
Caso você especifique o nome de um backup device que já existe, receberá a seguinte mensagem
de erro:
Msg 15026, Level 16, State 1, Procedure sp_addumpdevice, Line 72

Logical device ‘backup_exemplo1’ already exists..
6. Mantenha a janela de execução de comandos T-SQL aberta, pois iremos utilizá-la nos
próximos exemplos.
NOTA
O comando sp_addumpdevice não pode ser executado no contexto de uma transação.
Falaremos sobre segurança no Capítulo 6, mas cabe ressaltar que somente usuários que forem membros
das roles sysadmin e diskadmin terão permissões para executar o comando sp_addumpdevice. No
Capítulo 6 veremos que roles são semelhantes a grupos de usuários no Windows NT, Windows 2000
Server e no Windows Server 2003.
EXCLUINDO BACKUP DEVICES

Quando não for mais necessário, um backup device pode ser excluído. Podemos excluir um backup
device com o SQL Server Management Studio ou com o comando sp_dropdevice.
Para excluir um backup device utilizando o SQL Server Management Studio, basta navegar até o backup
device a ser excluído, clicar com o botão direito do mouse no backup device e, no menu de opções que
é exibido, clicar em Delete. Será exibida uma janela solicitando confirmação. Clique em OK e pronto,
o backup device será excluído.
Para excluir um backup device usando comandos T-SQL, utilizamos o comando sp_dropdevice. O
exemplo a seguir exclui o backup device chamado teste:
exec sp_dropdevice ‘teste’, DELFILE

NOTA
Por padrão, o arquivo físico associado ao device não é excluído ao utilizarmos o comando sp_dropdevice. Para excluir inclusive o arquivo
físico devemos utilizar o parâmetro DELFILE como segundo parâmetro para o comando sp_dropdevice.
Exercício 3: Utilizando o comando sp_addumpdevice, crie os seguintes backup devices:
1. Device 1:
Tipo: Disk
Nome: backup_northwind
Localização física: D:\backups\backup_northwind.bak
2. Device 2:
Tipo: Disk
Nome: backup_master
Localização física: D:\backups\master.bak
3. Device 3:
Tipo: Disk
Nome: master_diferencial
Localização física: D:\backups\master_diferencial.bak
4. Device 4:
Tipo: Disk
Nome: backup_adventureworks
Localização física: D:\backups\backup_adventureworks
NOTA
É importante que você complete este exercício pois utilizaremos estes backup devices no próximo item.
Como estamos criando diversos backup devices, pode ficar a impressão que para cada backup devemos ter um diferente backup device
associado. Porém na prática podemos efetuar diversos backups no mesmo backup device. Poderíamos ter um único backup device associado
com um drive de fita e efetuarmos o backup de todos os Bancos de Dados da instância, neste device. Conforme veremos no próximo item, na
hora de fazer o backup podemos definir se o backup que está sendo feito deve ser anexado aos backups já existentes no device backup ou
se os backups já existentes devem ser excluídos.
KNOW-HOW EM: FAZER O BACKUP DAS INFORMAÇÕES

PRÉ-REQUISITOS
♦ Noções sobre estratégias de backup e restore.
METODOLOGIA
♦ Exercícios: Fazer o backup de Bancos de Dados.
TÉCNICA
♦ Apresentação dos procedimentos necessários para a realização do backup com o SQL Server Management Studio e também usando
comandos T-SQL.
Podemos fazer o backup utilizando qualquer uma das seguintes ferramentas:
♦ Comandos T-SQL
FAZENDO O BACKUP COM O SQL SERVER MANAGEMENT STUDIO

Para aprender a fazer o backup com o SQL Server Management Studio vamos começar fazendo um
backup completo do Banco de Dados AdventureWorks. Faremos o backup no backup device
backup_adventureworks que você criou no Exercício 3.
Exemplo prático: Para criar um backup completo do Banco de Dados AdventureWorks, siga os passos
indicados a seguir:
2. Na janela Object Explorer, navegue até o banco de dados para o qual você deseja fazer um
backup completo. No nosso exemplo, navegue até o banco de dados AdventureWorks, dentro
da opção Databases, da instância SERVIDOR\SQL2005.
3. Dê um clique com o botão direito do mouse no Banco de Dados AdventureWorks, e no menu

de opções que surge clique na opção Tasks -> Back up.
Surge a janela para que você possa configurar as definições do backup a ser criado, conforme indicado
na Figura 5.6.
Na guia Geral (General) podemos definir as seguintes opções:
♦ Database: Nesta lista selecionamos o nome do Banco de Dados para o qual será feito o backup.
No nosso exemplo certifique-se de que o AdventureWorks está selecionado nesta lista. Por padrão,
já vem selecionado o banco de dados, no qual você clicou com o botão direito do mouse.
Figura 5.6 Janela para definição do backup.
♦ Recovery model: O conceito de Recovery Model é um conceito que foi introduzido no SQL
Server 2000 e que também faz parte do SQL Server 2005. Vamos fazer um parênteses um pouco
maior, para falar mais sobre o conceito de Recovery Model. No SQL Server 2000 e SQL Server
2005, as operações de backup e restore ocorrem no contexto de um modelo de recuperação –
recovery models. O modelo de recuperação é uma propriedade do banco de dados, a qual afeta
a maneira como são executadas as operações de backup e restore de um banco de dados. As
operações de backup e restore serão executadas de diferentes maneiras, dependendo do recov-
ery model configurado para o banco de dados. O recovery model configurado para um banco
de dados determina de que maneira as transações são gravadas no log, se é necessário ou não
fazer o backup do log de transações e quais opções de restore estarão disponíveis para o banco
de dados. O uso do conceito de recovery models traz diversos benefícios, dentre os quais é
possível destacar os seguintes: simplifica os procedimentos de backup e restore, ao agregar um
conjunto predefinido de ações e opções em cada recovery model, simplifica o planejamento
das ações de recuperação a desastres e, por fim, simplifica os procedimentos de backup e re-
store. Estão disponíveis três diferentes modelos de recuperação:
♦ Full recovery model: Um banco de dados configurado para utilizar este modelo mantém no
log de transações o registro de todas as operções de dados, executadas no banco de dados, até
mesmo depois de ser feito o backup do banco de dados. Usando este modelo, é possível recuperar
um banco de dados, exatamente ao ponto em que ele se encontrava, no momento da falha,
desde que tenha sido feito o backup dos logs das transações executadas após o último backup.
Para garantir este grau de “recuperabilidade”, em um banco de dados que está configurado
para utilizar este modelo, todas as operações, incluindo operações em massa de dados (bulk
operations), tais como SELECT INGO, CREATE INDEXT, bem como operações de importação
em massa de dados, são gravadas no log de transações. Todas as opções de recovery estão
disponíveis, quando é utilizado o modelo Full Recovery Model. Para proteger o banco de
dados, contra perdas no log de transações, quando o banco de dados usa o modelo Full Recov-
ery Model, é fundamental que os arquivos do log de transações estejam em um sistema de
discos tolerante a falhas, sendo recomendado um RAID-5. Também poderia ser um RAID-1
(espelhamento), porém o desempenho de um sistema RAID-1 é bem inferior ao do RAID-5.
♦ Logged recovery model: Um banco de dados configurado para utilizar este modelo grava uma
quantidiade mínima de operações em massa, tais como criação de índices e importação em
massa de dados. As demais operações são todas gravadas no log de transações. Este modelo
melhora bastante o desempenho para operações de massa, tais como a criação e atualização de
índices, uma vez que estas ações não são gravadas no log de transações. Este modelo, normalmente,
é utilizado em situações específicas. Por exemplo, suponhamos que você tem uma grande
quantidade de dados para importar ou um grande número de índices para criar. Você pode
colocar o banco de dados, temporariamente, no modelo Logged Recovery Model, para melhorar
o desempenho e reduzir o tempo de execução destas operações e, uma vez concluídas estas
operações, colocar o banco de dados novamente no modelo Full Recovery Model.
♦ Simple recovery model: Um banco de dados configurado para utilizar este modelo grava
apenas uma quantidade mínima de informações no log de transações, quantidade esta somente
suficiente para garantir a consistência do banco de dados após um problema no servidor, tal
como uma queda de energia ou para garantir a consistência, após a restauração de um backup.
Este modelo simplifica bastante as operações de backup e restore, por eliminar o trabalho
adicional de fazer o backup e restaurar os logs de transações. Porém, em contra-partida a esta
simplificação, com a utilização deste modelo, as probabilidades de perda de dados são bem
maiores do que nos outros modelos. Devido à falta do backup do log de transações, fica
impossível restaurar o banco de dados ao estado em que ele se encontrava no momento da
falha, somente sendo possível restaurá-lo ao ponto do último backup disponível.
Observe que para o backup do banco de dados, na lista Recovery Model, está disponível
somente a opção Simple. Isso acontece porque, nas propriedades do banco de dados
AdventureWorks, está configurada a propriedade Recovery Model como Simple.
♦ backup type: Nesta lista estão disponíveis as opções: Full: Define que será feito um backup
completo do Banco de Dados ou Differential: Define que será feito um backup diferencial do
Banco de Dados.
♦ backup component: Você pode marcar a opção Database, para fazer o backup do banco de
dados ou a opção Files e filegroups (a qual não está disponível para o modelo Simple), para
fazer o backup somente de arquivos ou filegroups específicos.
♦ Name: Um nome simplificado para o backup.
♦ Description: Uma descrição mais detalhada sobre o backup que está sendo criado.
♦ backup set will expire: Você pode definir uma data de expiração para o backup. Passada a
data de expiração, o backup não poderá mais ser utilizado, para restauração dos dados.
♦ Destination -> backup to: Nesta opção devemos selecionar um ou mais backup devices, os
quais utilizaremos para o backup.
4. Você pode marcar a opção Disk, para usar um backup device em disco ou a opção Type, para
fazer um backup em fita. No nosso exemplo, a opção Type não está habilitada, pois não está
instalado um drive de fita de backup, no servidor que eu estou utilizando. Para selecionar um
novo device clique no botão Add, irá surgir a janela indicada na Figura 5.7.
Figura 5.7 Selecionando backup devices.
Observe que nesta janela podemos selecionar um backup device físico (file name), isto é, diretamente
o nome do arquivo em disco ou um backup device lógico (backup device), quando selecionamos um
backup device previamente criado.
5. Dê um clique na opção backup device e, na lista de backup devices previamente criados, selecione
backup_adventureworks.
NOTA
Caso você tenha recém-criado os backup devices do item anterior, pode ser que nem todos apareçam na listagem de backup devices
disponíveis. Se este for o seu caso, feche o SQL Server Management Studio e abra-o novamente. Com isso a listagem será atualizada.
6. Após selecionar o backup device a ser utilizado, basta dar um clique em OK e pronto; você
estará de volta à janela de backup com o backup device backup_adventureworks adicionado,
conforme indicado na Figura 5.8. Se houver algum outro backup device na lista, além do
backup device backup_adventureworks, clique no backup device que está a mais e depois clique
no botão Remove.
Dê um clique na guia Options. As principais opções desta guia estão descritas a seguir:
♦ Append to existing backup set: Esta opção define que o backup que está sendo criado deve
ser anexado a quaisquer outros backups que já existam no backup device selecionado. Certifique-
se de que esta opção está selecionada.
♦ Overwrite all existing backup sets: Esta opção elimina quaisquer backups que já tenham sido
criados no backup device selecionado.
Figura 5.8 O backup device backup_northwind já adicionado.
♦ Botão Schedule, na barra de botões: Esta opção permite que seja feito um agendamento para
o backup. Veremos mais sobre agendamento de tarefas, mais adiante, neste capítulo.
♦ Verify backup when finished: Define que a integridade da mídia de backup deve ser verificada
após o término do backup.
♦ Truncate the transaction log by removing inactive entries: Após o término do backup todas
as transações completas (Committed Transactions) serão excluídas do log. No nosso exemplo
esta opção está desabilitada pois não estamos fazendo um backup do log de transações, uma
vez que o banco de dados AdventureWorks usa o modelo Simple Recovery Model.
♦ Check media set name and backup set expiration: Esta opção evita que um backup que
ainda não expirou seja sobrescrito pelo backup que está sendo realizado.
7. Não altere as opções da guia Options. Dê um clique em OK e o backup será inicializado e surge
uma janela indicando o progresso do backup.
Após finalizar o backup, o SQL Server 2005 emite uma mensagem avisando que o backup foi finalizado
com sucesso.
8. Você estará de volta ao SQL Server Management Studio.
Podemos conferir que o backup realmente foi feito, acessando a pasta D:\backups. Nesta pasta podemos
verificar que o arquivo backup_adventureworks possui o tamanho de cerca de 67 MB, conforme indicado
na Figura 5.9.
Figura 5.9 Arquivo backup_adventureworks com cerca de 67 MB.
FAZENDO O BACKUP DO LOG DE TRANSAÇÕES

E CRIANDO UM AGENDAMENTO PARA O BACKUP
Agora vamos aprender a criar um backup do log de transações e agendar o backup para que seja feito
três vezes ao dia, em horários determinados. No nosso exemplo vamos fazer o backup do Banco de
Dados Exemplo1 (o qual foi criado no Capítulo 3). O backup será feito no backup device
backup_exemplo1 criado anteriormente. Para criar o backup e o agendamento utilizaremos o SQL
Server Management Studio. Siga os passos indicados no próximo exemplo.
Exemplo prático: Fazer o backup do log de transações do Banco de Dados Exemplo1. Agendar este
backup para que seja realizado todos os dias, às 9h, 12h, 15h e 18h.
Para criar o backup e o agendamento do exemplo, siga os passos indicados a seguir:
2. Dê um clique no sinal de mais ao lado de Microsoft SQL Servers para expandir esta opção.
3. Na janela Object Browser, dê um clique no sinal de + ao lado da instância SERVIDOR\SQL2005,

que foi a instância onde criamos o banco de dados Exemplo1, no Capítulo 3.
4. Nas opções que surgem, abaixo desta instância, clique no sinal de + ao lado da opção Data-
bases para expandi-la. Abaixo de Databases surge uma lista com os Bancos de Dados da instância
SERVIDOR\SQL2005.
5. Dê um clique com o botão direito do mouse no Banco de Dados Exemplo1. No menu de opções
que surge, selecione o comando Tasks -> Back Up. Será aberta a janela para definição das opções
de backup, a qual você já aprendeu a utilizar anteriormente, com a guia General selecionada.
6. Para o campo Name digite AgendLogExemplo1, e para o campo Description, digite backup do
log de transações.
7. Na lista backup type, selecione a opção Transaction Log.
Agora vamos selecionar o device backup_exemplo1, no qual faremos o backup do log de transações.
8. Na parte de baixo da janela, abaixo de Destination, dê um clique no botão Add.
9. Na janela Select backup Destination, clique na opção backup device e na lista de backup de-
vices selecione backup_exemplo1.
10. Dê um clique no botão OK para fechar a janela Select backup Destination.
11. Você estará de volta à janela para definição do backup. Se houver outro backup device na
lista, além de backup_exemplo1, elimine estes outros devices. Para isso, basta clicar no
device a ser retirado da lista e depois clicar no botão Remove. Certifique-se de que somente
o device backup_exemplo1 esteja na lista. Clique na guia Options. Certifique-se de que a
opção Append to existing backup set esteja selecionada. Sua janela deve estar conforme
indicado na Figura 5.10 (configurações da guia General). Mantenha a janela de configurações
do backup aberta.
Figura 5.10 Definições do backup do log de transações.
Agora vamos definir o agendamento do backup.
12. Clique na botão Schedule.
13. Surge a janela Job Schedule, conforme indicado na Figura 5.11. Nesta janela você pode definir
um nome para o job e um nome para o agendamento (conforme você verá no final deste
capítulo, um mesmo job pode ter mais de um agendamento).
Figura 5.11 A janela para definição do agendamento (Schedule).
Na lista Schedule type, vem selecionado, por padrão, o tipo de agendamento Recurring. Nesta lista,
podemos definir os seguintes tipos de agendamentos:
♦ Recurring: Agenda o backup para ser executado periodicamente, em determinados dias e

horários configurados no agendamento. É o nosso caso, onde queremos que o backup seja
executado diariamente, às 9h, 12h, 15h e 18h.
♦ Start automatically when SQL Server Agent starts: Esta opção agenda o backup para ser feito
toda vez que o serviço SQL Server Agent for inicializado.
♦ Start whenever the CPU(s) become idle: Esta opção agenda o backup para ser executado toda
vez que a(s) CPU(s) do servidor estiverem ociosas (entenda-se CPUs como sendo os
processadores). O tempo de inatividade para definir se a CPU está ociosa é definido na guia
Advanced das propriedades do SQL Server Agent.
♦ One Time: Executa o backup uma única vez em uma data e horário especificados.
14. Mantenha a opção Recurring selecionada e defina que o backup deve ocorrer, diariamente, às
9h, 12h, 15h e 18h. Para isso, configure as opções indicadas na Figura 5.12.
Figura 5.12 Definindo o agendamento do backup.
15. Observe que selecionamos a opção Daily (diário), ocorrendo a cada 3 horas com início às 9h e
término às 18h. Isto faz com que o backup seja executado exatamente quatro vezes, às 9:00,
12h, 15h e 18h, que é exatamente a programação desejada para o nosso exemplo.
16. Digite o nome AgendLogExemplo1 no campo Job name, e clique em OK para criar o
agendamento. O agendamento será criado e será exibida uma janela, informando que o
agendamento foi criado com sucesso. Clique em OK para fechar esta janela.
17. Você estará de volta à janela para definição do backup. Dê um clique na guia Options. Certifique-
se de que a opção “Truncate the transaction log by removing inactive entries” esteja selecionada.
Esta opção faz com que as transações que foram completadas com sucesso sejam excluídas do
log de transações após o backup ter sido efetuado. Esta opção evita que o log de transações
cresça indefinidamente.
18. Clique em OK.
Com isso o agendamento para o backup do log de transações terá sido criado. Se você não tiver criado,
anteriormente, um backup do banco de dados, será emitida uma mensagem de erro, informando que
o backup do log de transações não poderá ser efetuado, pois não existe um backup do banco de dados.
É importante lembrar (veja estratégias de backup/restore no início do capítulo) que de nada serve um
backup do log de transações, se você não tiver um backup do banco de dados.
O agendamento de uma tarefa de backup é como se fosse o agendamento de qualquer outra tarefa do
SQL Server 2005. Quando criamos uma tarefa agendada, na linguagem do SQL Server 2005, estamos
criando um job. No nosso exemplo, demos o nome de AgendLogExemplo1 para a tarefa, ou melhor,
para o job que executa o backup do log de transações do banco de dados Exemplo1. Podemos conferir
se este job foi realmente criado, expandindo a opção SQL Server Agent. Abaixo de SQL Server Agent, dê
um clique no sinal de + ao lado da opção Jobs. Abaixo de Jobs, deve ser exibido o job AgendLogExemplo1,
Figura 5.13 O job AgendLogExemplo1.
Podemos fazer com que um job seja executado a qualquer momento, sem ter que esperar pelo
próximo horário de execução, definido no agendamento. Para isso basta clicar com o botão direito
no Job a ser executado, e no menu que surge clicar em Start Job. Se fizermos isso com o job
AgendLogExemplo1, este será imediatamente executado e o backup do log de transações do Banco
de Dados Exemplo1 será feito.
Veremos mais sobre o agendamento de tarefas, ou melhor, a criação de jobs, na parte final deste
capítulo.
19. Agora o nosso backup está agendado e irá rodar diariamente, nos horários por nós definidos.
Agora vamos aprender a fazer backup utilizando comandos T-SQL, na janela de execução de comandos.
FAZENDO O BACKUP COM O QUERY ANALYZER

Utilizando comandos T-SQL podemos fazer o backup completo, backup diferencial, backup de um
arquivo ou filegroup e o backup do log de transações. Através de comandos podemos, inclusive, criar
o agendamento de um backup.
Fazendo o backup do Banco de Dados:
Para fazer o backup de um Banco de Dados utilizamos o comando BACKUP DATABASE. A seguir a
sintaxe completa deste comando, conforme apresentada no Books OnLine.
Sintaxe do comando BACKUP DATABASE:
BACKUP DATABASE { database_name | @database_name_var }

TO < backup_device > [ ,...n ]
[ WITH
[ BLOCKSIZE = { blocksize | @blocksize_variable } ]
[ [ , ] DESCRIPTION = { ‘text’ | @text_variable } ]
[ [ , ] DIFFERENTIAL ]
[ [ , ] EXPIREDATE = { date | @date_var }
| RETAINDAYS = { days | @days_var } ]
[ [ , ] PASSWORD = { password | @password_variable } ]
[ [ , ] FORMAT | NOFORMAT ]
[ [ , ] { INIT | NOINIT } ]
[ [ , ] MEDIADESCRIPTION = { ‘text’ | @text_variable } ]
[ [ , ] MEDIANAME = { media_name | @media_name_variable } ]
[ [ , ] MEDIAPASSWORD = { mediapassword | @mediapassword_variable } ]
[ [ , ] NAME = { backup_set_name | @backup_set_name_var } ]
[ [ , ] { NOSKIP | SKIP } ]
[ [ , ] { NOREWIND | REWIND } ]
[ [ , ] { NOUNLOAD | UNLOAD } ]
[ [ , ] RESTART ]
[ [ , ] STATS [ = percentage ] ]
]
Conforme já descrevemos anteriormente, a sintaxe completa não é muito intuitiva. Vamos aprender a
utilizar o comando BACKUP DATABASE através de exemplos.
Exemplo1: Criar um backup device chamado bknw, o qual é associado com o arquivo D:\backups\bknw.
Depois fazer o backup completo do Banco de Dados Northwind para o backup device bknw. Para fazer
o backup proposto utilizaríamos os seguintes comandos:
— Primeiro criamos o backup device bknw

— Lembre-se de tornar o Banco de Dados master o Banco de Dados atual
— pois os backup devices são criados sendo o banco master o Banco de Dados atual.
USE master
EXEC sp_addumpdevice ‘disk’, ‘bknw’, ‘D:\backups\bknw.bak’
BACKUP DATABASE northwind TO bknw
Ao executar estes comandos, com sucesso, no Query Analyzer será emitida a seguinte mensagem:
Processed 560 pages for database ‘northwind’, file ‘Northwind_Data’ on file 1.

Processed 1 pages for database ‘northwind’, file ‘Northwind_Log’ on file 1.
BACKUP DATABASE successfully processed 561 pages in 0.833 seconds (5.509 MB/sec).
Observe que, conforme descrito anteriormente, o backup completo de um Banco de Dados faz o backup
dos arquivos de dados e também dos arquivos de log.
Uma sintaxe mais simplificada para o comando BACKUP DATABASE:
BACKUP DATABASE nome_banco_dados

TO nome_backup_device1, nome_backup_device2,..., nome_backup_devicen
[WITH OPTIONS]
Observe que podemos fazer o backup de um Banco de Dados para mais do que um backup device ao
mesmo tempo. Este procedimento pode ser utilizado para agilizar o backup. Para fazermos o backup
para múltiplos volumes devemos criar uma “Media Set”, ou seja, um conjunto de mídias. O caso mais
típico é quando temos duas ou mais unidades de fita ligadas a um servidor. Neste caso podemos criar
uma Media Set com as unidades disponíveis e fazer o backup, simultaneamente, para todas as unidades.
Desta maneira, o tempo de backup (janela de backup) pode ser reduzido. Para maiores informações
sobre a utilização de múltiplos devices, consulte “Using Media Sets and Families” no Books OnLine.
Agora vamos descrever as principais opções que podem ser utilizadas com o comando BACKUP DATA-
BASE. Estas opções são especificadas no final do comando, com a cláusula WITH. Caso mais do que
uma opção esteja sendo utilizada, devemos separá-las por vírgula.
♦ As opções INIT e NOINIT: Ao fazermos um backup temos a opção de excluir os backups já existentes
no backup device, ou manter os backups existentes e apenas anexar o que está sendo feito.
A opção NOINIT é a opção padrão e faz com que o backup seja anexado ao backup device, mantendo os
backups feitos anteriormente. Se selecionarmos a opção INIT, o SQL Server 2005 irá gravar o backup que está
sendo feito na parte inicial do backup device, eliminando os backups anteriores. Se existirem backups no
backup device que foram feitos com a opção EXPIREDATE, e estes backups ainda não tiverem expirado, a
utilização da opção INIT irá causar um erro. Utilizamos a opção EXPIREDATE para garantir que um determinado
backup seja mantido por um período mínimo. A seguir um exemplo de utilização destas opções.
Vamos fazer um backup do Banco de Dados Northwind para um device chamado device_exemplo. Vamos
fazer o backup utilizando a opção EXPIREDATE. Depois vamos fazer um novo backup, para o device
device_exemplo tentando utilizar a opção INIT e vamos observar a mensagem de erro que é exibida.
Os comandos a seguir fazem o backup usando a opção WITH EXPIREDATE:
— Tornar o Banco de Dados master o banco atual

USE master
— Criar o backup device device_exemplo

EXEC sp_addumpdevice ‘disk’, ‘device_exemplo’, ‘D:\backups\device_exemplo.bak’
— Fazer o backup do banco de dados Northwind

— com a opção EXPIREDATE
BACKUP DATABASE northwind TO device_exemplo
WITH EXPIREDATE = ‘20010315’
— Fazer um backup com a opção INIT, sendo que o backup anterior

— Somente expira em 15 de março de 2001, conforme definido anteriormente
— pela opção WITH EXPIREDATE = ‘20050415’
WITH INIT
Será emitida a seguinte mensagem de erro:
Processed 560 pages for database ‘northwind’, file ‘Northwind_Data’ on file 2.

Processed 1 pages for database ‘northwind’, file ‘Northwind_Log’ on file 2.
The medium on device ‘device_exemplo(D:\backups\device_exemplo.bak)’ expires on Apr 15 2005
12:00:00:000AM and cannot be overwritten.
BACKUP DATABASE is terminating abnormally.
Observe que a mensagem informa que o backup somente irá expirar em 15 de abril de 2005 e não
poderá ser sobrescrito: The medium on device ‘device_exemplo (D:\backups\device_exemplo.bak)’
expires on Apr 15 2005 12:00:00:000AM and cannot be overwritten.
♦ A opção RESTART: Utilizamos esta opção para que o SQL Server 2005 reinicialize um backup
que tenha sido interrompido, exatamente do ponto onde o backup parou. Esta opção poupa
tempo, uma vez que o backup não precisa ser reinicializado desde o início. Para reinicializar
um backup, basta repetir o comando que foi utilizado para fazer o backup, e acrescentar WITH
RESTART no final do comando.
♦ A opção DIFFERENTIAL: Esta opção define que seja feito um backup diferencial. O comando,
a seguir, faz um backup diferencial do Banco de Dados Northwind para o backup device
device_exemplo, criado no exemplo anterior:
WITH DIFFERENTIAL
♦ A opção PASSWORD: Esta opção permite que seja definida uma senha para o backup. Ao
fazermos um restore deste backup teremos que fornecer a senha; caso contrário a operação de
restore será cancelada. O exemplo a seguir faz o backup do Banco de Dados pubs para o backup
device device_exemplo e especifica uma senha.
BACKUP DATABASE pubs TO device_exemplo
WITH PASSWORD = ‘senha123’
♦ A Opção NAME: Esta opção permite que seja definido um nome para o backup. Se o nome não
for especificado, o nome será assumido como uma string em branco.
Estas são as principais opções disponíveis para o comando BACKUP DATABASE. Para uma descrição completa
de todas as opções disponíveis, consulte BACKUP no tópico Transact-SQL Reference no Books OnLine.
Fazendo o backup do log de transações:
Para fazer o backup do log de transações, utilizamos o comando BACKUP LOG. A seguir, a sintaxe
completa deste comando, conforme apresentada no Books OnLine.
Sintaxe do comando BACKUP LOG:
BACKUP LOG { database_name | @database_name_var }

{
TO < backup_device > [ ,...n ]
[ WITH
[ BLOCKSIZE = { blocksize | @blocksize_variable } ]
[ [ , ] DESCRIPTION = { ‘text’ | @text_variable } ]
[ [ ,] EXPIREDATE = { date | @date_var }
| RETAINDAYS = { days | @days_var } ]
[ [ , ] FORMAT | NOFORMAT ]
[ [ , ] { INIT | NOINIT } ]
[ [ , ] MEDIADESCRIPTION = { ‘text’ | @text_variable } ]
[ [ , ] NAME = { backup_set_name | @backup_set_name_var } ]
[ [ , ] NO_TRUNCATE ]
[ [ , ] { NORECOVERY | STANDBY = undo_file_name } ]
[ [ , ] { NOSKIP | SKIP } ]
[ [ , ] RESTART ]
]
}
Conforme já descrevemos anteriormente, a sintaxe completa não é muito intuitiva. Vamos aprender a
utilizar o comando BACKUP LOG através de exemplos.
Exemplo1: Criar um backup device chamado bklog, o qual é associado com o arquivo D:\backups\bklog.
Depois, fazer o backup do log de transações do Banco de Dados Exemplo1 para o backup device bklog.
Para fazer o backup proposto utilizamos o seguinte comando:
— Primeiro criamos o backup device bklog

— Lembre-se de tornar o Banco de Dados master o Banco de Dados atual
— pois os backup devices são criados sendo o master o Banco de Dados atual.
USE master
EXEC sp_addumpdevice ‘disk’, ‘bklog’, ‘D:\backups\bklog.bak’
BACKUP LOG Exemplo1 TO bklog
Uma sintaxe mais simplificada para o comando BACKUP LOG:
BACKUP LOG nome_banco_dados

TO nome_backup_device1, nome_backup_device2,..., nome_backup_devicen
[WITH OPTIONS]
As principais opções para o comando BACKUP LOG são praticamente as mesmas opções que para o comando
BACKUP DATABASE. Temos duas opções que são específicas para o backup do log de transações:
♦ A opção NO_LOG ou TRUNCATE_ONLY: Estas duas opções são sinônimas. Ao utilizarmos

esta opção não será feito o backup do log, e o log será truncado, isto é, todas as transações que
sofreram Commit serão excluídas do log. Como não é feito o backup do log, não precisamos
especificar o backup device a ser utilizado.
♦ A opção NO_TRUNCATE: É utilizada para fazer o backup do log sem que as transações completas
sejam excluídas do log após o backup. Esta opção é utilizada para situações em que o Banco de
Dados foi danificado e queremos restaurá-lo a uma situação imediatamente anterior ao momento
em que o banco foi corrompido. Utilizaremos esta opção no próximo item, quando
aprenderemos a fazer o restore do Banco de Dados.
UM EXEMPLO MAIS COMPLETO

Vamos fazer um exemplo completo em que utilizaremos diversas opções apresentadas anteriormente.
Exemplo: Criar uma seqüência de comandos T-SQL que faça o seguinte:
1. Crie um device chamado device_real.
2. Faça o backup completo do Banco de Dados Exemplo1, com data de expiração definida para 31
de dezembro de 2005, o qual irá anexar o backup aos já existentes no device device_real.
3. Fazer o backup do log de transações do Banco de Dados Exemplo1.
O nosso comando deve ficar da seguinte maneira:
— ********************************************
— ********** Script T-SQL de exemplo ****
— ********** Autor: Júlio Battisti ****
— ********** e-mail: batisti@hotmail.com ****
— ********************************************
— Tornar o Banco de Dados master o Banco de Dados atual
USE master
— Criar o device device_real

EXEC sp_addumpdevice ‘disk’, ‘device_real’, ‘D:\backups\device_real.bak’
— backup completo do Banco de Dados pubs com data

— de expiração para 31 de dezembro de 2005.
BACKUP DATABASE Exemplo1 TO device_real
WITH EXPIREDATE = ‘20051231’, NOINIT
— Agora faço o backup do log do Banco de Dados pubs.

BACKUP LOG Exemplo1 TO device_real
— ********************************************
— ********************************************
Ao executarmos este comando, com sucesso, será emitida uma mensagem, semelhante à indicada a seguir:
(1 row(s) affected)
‘Disk’ device added.

Processed 112 pages for database ‘Exemplo1’, file ‘exemplo1-prim’ on file 1.
Processed 16 pages for database ‘Exemplo1’, file ‘exemplo1-sec1’ on file 1.
Processed 1 pages for database ‘Exemplo1’, file ‘exemplo1-log’ on file 1.
Processed 1 pages for database ‘Exemplo1’, file ‘exemplo1-log’ on file 2.
BACKUP LOG successfully processed 1 pages in 0.508 seconds (0.011 MB/sec).
KNOW-HOW EM: FAZER O RESTORE DAS INFORMAÇÕES

PRÉ-REQUISITOS
♦ Noções sobre estratégias de backup e restore.
METODOLOGIA
♦ Exercícios: Fazer o restore de Bancos de Dados e do log de transações.
TÉCNICA
♦ Apresentação dos procedimentos necessários para a realização do restore, com o SQL Server Management Studio e com comandos T-SQL.
Ao fazermos o backup copiamos os dados do Banco de Dados para um dispositivo de backup (backup
device), que na maioria dos casos é um drive de fita. Mas o único objetivo para fazermos o backup é
para que possamos restaurar os dados, quando algum problema acontecer. Restaurar os dados (fazer o
restore) é a operação de copiar os dados do backup de volta para o Banco de Dados. A maneira de
restaurar o Banco de Dados ao seu estado normal depende da nossa estratégia de backup. As estratégias
de restore são diferentes, dependendo do tipo de backup que você está utilizando: backups completos,
diferenciais ou combinando estes backups com backups do log de transações.
No item “Estratégias de backup”, no início deste capítulo, falamos sobre as diversas estratégias de backup/restore, dependendo do tipo de
NOTA
backup que estamos utilizando. Foram analisados diversos exemplos. No item anterior aprendemos a fazer os diversos tipos de backup
disponíveis no SQL Server 2005. Agora aprenderemos a fazer o restore.
Nesta seção aprenderemos a fazer o restore utilizando as seguintes ferramentas:
♦ Janela de Execução de Comandos T-SQL
Dependendo do tipo de backup teremos diferentes estratégias de restore. Vamos considerar as seguintes
situações:
♦ Restore a partir de um backup completo: Para esta situação basta restaurar o último backup
completo disponível. Todas as alterações entre o último backup completo e o momento do
restore serão perdidas.
♦ Restore a partir de um backup completo e backups diferenciais: Neste caso restauramos o
último backup completo e em seguida o último backup diferencial. Todas as alterações entre o
último backup diferencial e o momento do restore serão perdidas.
♦ Restore a partir de um backup completo e backups do log de transações: Quando temos
backups do log de transações, devemos restaurar o último backup completo e depois todos os
backups do log de transações. É de fundamental importância que os backups do log de transações
sejam restaurados na ordem correta, do mais antigo até o mais recente. As alterações entre o
último backup do log de transações e o momento do restore serão perdidas. Esta estratégia torna
o restore mais demorado, pois precisamos restaurar uma série de backups do log de transações.
♦ Restore a partir de um backup completo, backups diferenciais e backups do log de
transações: Neste caso devemos restaurar o backup completo, depois o último backup diferencial
e depois todos os backups do log de transações. É de fundamental importância que os backups
do log de transações sejam restaurados na ordem correta, do mais antigo até o mais recente. As
alterações entre o último backup do log de transações e o momento do restore serão perdidas.
Esta estratégia torna o restore menos demorado, pois precisamos apenas restaurar os backups
do log de transações entre o último backup diferencial e o momento em que houve o problema.
FAZENDO O RESTORE COM O SQL SERVER MANAGEMENT STUDIO

Podemos fazer o restore utilizando o SQL Server Management Studio, quer seja o restore de um backup
completo, de um backup diferencial ou de um backup do log de transações. Lembrando que cada
situação pode exigir uma seqüência de restore específica.
Exemplo prático: Fazer o restore de um backup completo do Banco de Dados Northwind (substitua
Northwind pelo nome do banco de dados para o qual você dispõe de um backup completo, backup
este que você deseja restaurar). Ao fazermos este restore, o Banco de Dados estará de volta à situação
que estava no momento em que o backup completo foi realizado.
Para fazer o restore de um backup completo do Banco de Dados Northwind, siga os passos indicados a
seguir:
2. Na janela Object Explorer, dê um clique no sinal de + ao lado da instância na qual está o banco
de dados que você deseja restaurar a partir do backup completo.
3. Nas opções que surgem abaixo desta instância, clique no sinal de + ao lado da opção Data-
bases para expandi-la. Abaixo de Databases surge uma lista com os Bancos de Dados da
instância SERVIDOR\SQL2005 (instância onde está o banco de dados Northwind, que eu
estou utilizando neste exemplo).
Figura 5.14 A janela Restore database.
4. Dê um clique com o botão direito do mouse no Banco de Dados Northwind, e no menu de
opções que surge selecione Tasks -> Restore -> Database. Surge a janela Restore Database, onde
podemos selecionar os backups a serem restaurados (backups que já foram efetuados,
anteriormente), conforme exemplo da Figura 5.14, onde temos um único backup disponível
para restauração, sendo este um backup do tipo Full.
Na guia General temos as seguintes opções:
♦ To database: Nesta lista podemos selecionar para qual Banco de Dados o backup será restaurado.
♦ From Database: Permite que selecionemos um banco de dados, para que sejam exibidos os
backups disponíveis para o banco de dados que for selecionado.
♦ From device: Este opção permite que seja selecionado um device a partir do qual queremos
fazer o restore.
Estando a opção From database selecionada, na parte de baixo da janela, será exibida a lista de backups
disponíveis para o banco de dados selecionado. Você clica no backup para selecioná-lo. Os dados do
backup selecionado serão utilizados para fazer a restauração do banco de dados. Você poderá selecionar
mais de um backup. Por exemplo, se você tem um backup completo e um backup diferencial, feito
após o backup completo, você poderá selecionar os dois backups para serem restaurados, conforme
exemplo da Figura 5.15:
Figura 5.15 Restaurando o backup completo mais o diferencial.
♦ To apoint in time: Nesta guia também é importante observar a opção To a point in time, a qual
permite que você faça o restore até um determinado horário, desde que você tenha acesso aos
backups do log de transações e ao log do banco de dados. Por exemplo, se você detectou um
problema às 9:15, pode usar esta opção, para tentar restaurar o banco de dados até a situação em
que ele se encontrava às 9:00, perdendo apenas as alterações efetuadas entre 9:00 e 9:15. No SQL
Server 2000, esta opção somente estava disponível quando fosse selecionada a opção From data-
base, já no SQL Server 2005 esta opção está sempre disponível, independentemente de selecionar-
se a opção From database ou From device. Podemos utilizar esta opção para restaurar o Banco de
Dados à situação em que estava em um determinado horário. Por exemplo, vamos supor que seja
feito um backup completo no domingo, backups do log de transações diários às 9h, 12h e 17h.
Na quarta-feira também é feito um backup diferencial às 23h, além dos backups do log de
transações. Vamos supor que o Banco de Dados foi corrompido na quinta-feira, devido a um
comando errado executado às 15h05. A estratégia de restore mais adequada seria:
a. Fazer um backup do log de transações, utilizando a opção WITH NO_TRUNCATE. Esta opção
somente é possível se o Log de transação e o arquivo de dados primário não estão fisicamente
corrompidos no disco.
b. Primeiro restaurar o backup completo do domingo.

c. Depois restaurar o backup diferencial da quarta-feira, que é o último backup diferencial disponível.
d. Restaurar o backup do log de transações feito às 9h da quinta-feira.

e. Restaurar o backup do log de transações feito às 12h da quinta-feira.
f. Restaurar o backup do log de transações feito no item a, utilizando a opção “Point in time
restore”, para restaurar este log até as 15;00 horas. Observe que restauramos o log somente
até as 15h, para evitar que o comando incorreto, que foi executado em torno de 15h05, seja
executado novamente e venha a corromper o Banco de Dados. Nesta situação perderemos
somente as alterações feitas entre 15h e 15h05.
5. Certifique-se de que o(s) backup(s) a ser(em) restaurado(s) esteja(m) selecionado(s). Dê um

clique na guia Options. As principais opções desta guia são as seguintes:
♦ Leave database ready for use by rolling back the uncommitted transactions: Se esta
opção estiver marcada o Banco de Dados estará disponível para ser usado ao final do restore.
Utilizamos esta opção quando não temos mais nenhum log de transações para restaurar.
♦ Leave database non operational and do not roll back the uncommitted transactions: Se
esta opção estiver marcada, o Banco de Dados não poderá ser acessado pelos aplicativos.
Quando estamos restaurando diversos backups do log de transações, temos que utilizar esta
opção para que os diversos backups possam ser restaurados.
♦ Leave database in read-only mode for inspection: Ao selecionarmos esta opção, os
aplicativos podem acessar o Banco de Dados apenas para leitura dos dados. Alterações,
inserções e exclusões não serão permitidas. Em contrapartida, poderemos continuar
restaurando backups do Log de transação.
6. Certifique-se de que a opção “Leave database ready for use by rolling back the uncommitted
transactions” esteja selecionada. Dê um clique no botão OK para restaurar o backup do Banco
de Dados Northwind. Será exibida uma janela com o progresso do processo de restore, para
cada backup que estiver sendo restaurado. Quando todos os backups selecionados tiverem sido
restaurados, será exibida uma mensagem de confirmação.
7. Clique no botão OK para fechar esta mensagem.
8. Você estará de volta ao SQL Server Management Studio. Mantenha-o aberto, pois iremos utilizá-
lo no próximo tópico.
FAZENDO O RESTORE COM O QUERY ANALYZER

Para fazer o restore de um Banco de Dados utilizamos o comando RESTORE DATABASE. Para fazer o
restore do log de transações utilizamos o comando RESTORE LOG. A seguir, a sintaxe completa destes
comandos, conforme apresentada no Books OnLine.
Sintaxe do comando RESTORE DATABASE:
RESTORE DATABASE { database_name | @database_name_var }

[ FROM < backup_device > [ ,...n ] ]
[ WITH
[ RESTRICTED_USER ]
[ [ , ] FILE = { file_number | @file_number } ]
[ [ , ] MOVE ‘logical_file_name’ TO ‘operating_system_file_name’ ]
[ ,...n ]
[ [ , ] KEEP_REPLICATION ]
[ [ , ] { NORECOVERY | RECOVERY | STANDBY = undo_file_name } ]
[ [ , ] REPLACE ]
[ [ , ] RESTART ]
]
Sintaxe do comando RESTORE LOG:
RESTORE LOG { database_name | @database_name_var }

[ FROM < backup_device > [ ,...n ] ]
[ WITH
[ RESTRICTED_USER ]
[ [ , ] FILE = { file_number | @file_number } ]
[ [ , ] MOVE ‘logical_file_name’ TO ‘operating_system_file_name’ ]
[ ,...n ]
[ [ , ] KEEP_REPLICATION ]
[ [ , ] { NORECOVERY | RECOVERY | STANDBY = undo_file_name } ]
[ [ , ] RESTART ]
[ [ , ] STATS [= percentage ] ]
[ [ , ] STOPAT = { date_time | @date_time_var }
| [ , ] STOPATMARK = ‘mark_name’ [ AFTER datetime ]
| [ , ] STOPBEFOREMARK = ‘mark_name’ [ AFTER datetime ]
]
]
Mais uma vez vamos procurar simplificar um pouco, através de exemplos, esta sintaxe. Vamos iniciar
pelo comando RESTORE DATABASE.
Para restaurar um backup completo de um Banco de Dados podemos utilizar o seguinte comando:
RESTORE DATABASE nome_banco_dados FROM nome_device
Por exemplo, para restaurarmos um backup completo do Banco de Dados Exemplo1, a partir do device
device_real, podemos utilizar o seguinte comando:
RESTORE DATABASE Exemplo1 FROM backup_geral
Este comando é executado com sucesso e a seguinte mensagem é exibida:
Processed 192 pages for database ‘Exemplo1’, file ‘exemplo1-prim’ on file 1.

Processed 8 pages for database ‘Exemplo1’, file ‘exemplo1-sec1.ndf’ on file 1.
Processed 8 pages for database ‘Exemplo1’, file ‘exemplo1-sec2.ndf’ on file 1.
Processed 1 pages for database ‘Exemplo1’, file ‘exemplo1-log.ldf’ on file 1.
Processed 0 pages for database ‘Exemplo1’, file ‘exemplo1-log2.ldf’ on file 1.
RESTORE DATABASE successfully processed 209 pages in 0.400 seconds (4.280 MB/sec).
Uma sintaxe mais simplificada para o comando RESTORE DATABASE é a seguinte:
RESTORE DATABASE nome_banco_dados

FROM nome_device
[WITH OPTIONS]
As principais opções para este comando são as seguintes:
♦ PASSWORD: Esta opção permite que especifiquemos uma senha, caso o backup tenha sido
efetuado com uma senha anteriormente.
♦ NORECOVERY: Esta opção deve ser especificada quando iremos restaurar mais backups do log
de transações ou restaurar um backup diferencial. É sinônimo de STANDBY. É semelhante a
selecionar a opção Leave database non operational and do not roll back the uncommitted
transactions, no SQL Server Management Studio.
♦ RECOVERY: Esta é a opção padrão. É utilizada quando não temos mais nenhum backup do log
de transações ou backup diferencial para restaurar. Qualquer transação que esteja em um estado
uncommitted sofrerá um roll back. Esta é a opção padrão, isto é, se não especificarmos nada,
será assumida a opção RECOVERY.
♦ RESTART: Utilizamos esta opção para reinicializar uma operação de restore que foi interrompida.
♦ STATS = percentage: Faz com que seja emitida uma mensagem depois que o percentual
especificado, da operação de restore, tenha sido alcançado. Podemos utilizar esta opção para
acompanhamento de operações de restore de grandes Bancos de Dados.
♦ MOVE nome_lógico TO nome_físico_arquivo: Esta opção pode ser utilizada para restaurar o
backup para um lugar alternativo. Considere o seguinte exemplo do Books OnLine:
RESTORE DATABASE MyNwind FROM MyNwind_1
WITH NORECOVERY,
MOVE ‘MyNwind’ TO
‘c:\Program Files\Microsoft SQL Server\MSSQL\Data\NewNwind.mdf’,
MOVE ‘MyNwindLog1’
TO ‘c:\Program Files\Microsoft SQL Server\MSSQL\Data\NewNwind.ldf’
Agora vamos aprender um pouco mais sobre o comando RESTORE LOG. Considere o exemplo a seguir:
RESTORE LOG Exemplo1

FROM backup_log_exemplo1
WITH NORECOVERY
STATS = 5
Este comando restaura o log do Banco de Dados Exemplo1, a partir do backup device
backup_log_exemplo1 e não coloca o Banco de Dados on-line (NORECOVERY). Desta maneira mais
backups do log ou backups diferenciais poderão ser restaurados. A cada 5% da operação de restore é
emitida uma mensagem para acompanhamento (STATS = 5).
Simplificando a sintaxe do comando RESTORE LOG, teríamos:
RESTORE LOG nome_banco_dados

FROM nome_device
[WITH opções]
A maioria das opções do comando RESTORE LOG são as mesmas do comando RESTORE DATABASE.
Uma opção que é exclusiva do comando RESTORE LOG é a seguinte:
♦ STOP AT = ‘data e hora’: Esta opção pode ser utilizada para restaurar o backup do log de
transações até uma hora e data especificadas. Considere o exemplo a seguir conforme consta
no Books OnLine:
RESTORE DATABASE MyNwind
FROM MyNwind_1, MyNwind_2
WITH NORECOVERY
RESTORE LOG MyNwind
FROM MyNwindLog1
WITH NORECOVERY
RESTORE LOG MyNwind
FROM MyNwindLog2
WITH RECOVERY, STOPAT = ‘Apr 15, 2005 12:00 AM’
Para fixar melhor estes comandos vamos fazer um exercício completo.
Exercício: Neste exercício apresentarei os comandos necessários para executar a seguinte seqüência de tarefas:
♦ Criar um backup device chamado exercicio_capitulo5.
♦ Fazer um backup completo do Banco de Dados Northwind.
♦ Por padrão, o Banco de Dados Northwind possui a opção “trunc. log on chkpt” setada em
TRUE. Quando esta opção é verdadeira, não é possível fazer o backup do log de transações. Por
isso precisaremos desabilitar esta opção. É importante desabilitarmos esta opção antes de
fazermos as alterações, pois caso contrário as alterações efetuadas serão descartadas do log de
transações e não poderemos restaurar o log conforme proposto mais adiante.
♦ Em seguida faremos algumas alterações em intervalos de cinco minutos na tabela Customers
do Banco de Dados Northwind.
♦ Em seguida faremos um backup do log de transações.
♦ Na seqüência, iremos restaurar o backup completo.
♦ Depois restauraremos o backup do log de transações utilizando a opção STOPAT.
♦ Faremos um restore do backup completo para restaurar o Banco de Dados Northwind à condição
inicial.
As diversas etapas deste exercício serão executadas, utilizando comandos T-SQL, na janela de execução de comandos do SQL Server Manage-
NOTA
ment Studio. Os backups serão feitos em um device chamado exercicio_capitulo5, o qual está associado ao arquivo
D:\backups\exercicio_capitulo5.bak. O objetivo principal deste exercício é fazer uma revisão dos comandos relacionados à criação de
backup devices, criação de backups e de restore, já vistos anteriormente, neste capítulo.
Vamos abrir a janela de execução de comandos do SQL Server Management Studio e criar o device
exercicio_capitulo5.
1. Para criar o device exercicio_capitulo5 execute o seguinte comando:

USE master
exec sp_addumpdevice ‘disk’, ‘exercicio_capitulo5’, ‘D:\backups\exercicio_capitulo5.bak’
Com isso temos o nosso backup device exercicio_capitulo5 criado.
Fazer um backup completo do Banco de Dados Northwind.
2. Para fazer o backup solicitado, execute o seguinte comando:

BACKUP DATABASE Northwind to exercicio_capitulo5
Por padrão o banco de dados Northwind possui a opção “trunc. log on chkpt” setada em TRUE. Quando
esta opção é verdadeira, não é possível fazer o backup do log de transações. Por isso precisaremos
desabilitar esta opção.
3. Para desabilitar a opção “trunc. log on chkpt”, no Banco de Dados Northwind, execute o
seguinte comando:
use master
exec sp_dboption ‘northwind’, ‘trunc. log on chkpt’, ‘FALSE’
Faremos algumas alterações em intervalos de cinco minutos, na tabela Customers do Banco de Dados
Northwind. No nosso exemplo irei alterar a tabela Customers às 21h30. Nesta alteração farei com que o
campo Country de todos os registros seja alterado para Brasil. Às 21h35 irei alterar o campo Country para
EUA, e às 21h40 alterarei o campo Country de todos os registros da tabela Customers para Alemanha.
4. Para alterar o campo Country de todos os registros da tabela Customers para Brasil, execute o
seguinte comando:
Use Northwind
UPDATE Customers
SET Country = ‘Brasil’
Este comando foi executado às 21h30.
Na Figura 5.16 podemos ver o resultado deste comando. Para ver os dados de uma tabela no SQL Server
2005, basta executar um SELECT * FROM NOME_DA_TABELA.
Figura 5.16 Country = Brasil para todos os registros da tabela Customers.
5. Para alterar o campo Country de todos os registros da tabela Customers para EUA, execute o
seguinte comando:
Use Northwind
UPDATE Customers
SET Country = ‘EUA’
Na Figura 5.17 podemos ver o resultado deste comando.
Figura 5.17 Country = EUA para todos os registros da tabela Customers.
6. Para alterar o campo Country de todos os registros da tabela Customers para Alemanha, exe-
cute o seguinte comando:
Use Northwind
UPDATE Customers
SET Country = ‘Alemanha’
Na Figura 5.18 podemos ver o resultado deste comando.
Figura 5.18 Country = Alemanha para todos os registros da tabela Customers.
7. Faremos agora um backup do log de transações do Banco de Dados Northwind. Para isso,
execute o seguinte comando:
BACKUP LOG Northwind to exercicio_capitulo5
8. Restaure o backup completo para que o Banco de Dados Northwind volte à situação original,
executando o seguinte comando:
RESTORE DATABASE Northwind FROM exercicio_capitulo5
WITH NORECOVERY
NOTA
Devemos utilizar a opção WITH NORECOVERY pois queremos restaurar o log de transações na seqüência. Para isso precisamos deixar o Banco
de Dados não-operacional. Isto é feito com a opção NORECOVERY.
Agora restauraremos o backup do log de transações utilizando a opção STOPAT.
9. Para restaurar o log de transações até as 21h35, execute o seguinte comando:

RESTORE LOG Northwind
FROM exercicio_capitulo5
WITH RECOVERY, STOPAT = ‘20010308 21:35’
Neste caso deveremos estar de volta à situação de 21h35 (substitua a data indicada no comando pela
data e hora que você está utilizando, para acompanhar o exemplo).
Faremos, então, um restore do backup completo para restaurar o Banco de Dados Northwind a sua
condição inicial.
10. Para restaurar o Banco de Dados Northwind a sua condição inicial, execute o seguinte comando:
RESTORE DATABASE Northwind FROM exercicio_capitulo5
Na Figura 5.19 podemos conferir que os dados originais foram restaurados.
Figura 5.19 Dados originais restaurados.
Com isso encerramos o nosso item sobre restore.

NOTA
Você pode encontrar mais informações sobre backup/restore, no Books OnLine.
KNOW-HOW EM: AGENDAMENTO DE TAREFAS NO SQL SERVER 2005

PRÉ-REQUISITOS
♦ Saber utilizar o SQL Server Management.
METODOLOGIA
♦ Definir agendamentos de jobs no SQL Server 2005.
TÉCNICA
♦ Apresentação dos procedimentos necessários para o agendamento de tarefas/jobs no SQL Server 2005.
Podemos automatizar uma série de tarefas administrativas no SQL Server 2005 através da criação de
jobs. Um job é uma tarefa administrativa, composta de um ou mais passos, a qual é agendada para
executar automaticamente, em datas e horários determinados, nas configurações do job. Por exemplo,
poderíamos criar um job que executa um backup completo do Banco de Dados Northwind aos domingos
à noite, às 22:00 horas e um backup diferencial ao final de cada dia, de segunda a sexta-feira. Também
poderíamos criar jobs mais sofisticados, que fazem pesquisas em um Banco de Dados e enviam os
resultados por e-mail para um gerente. Podemos agendar tarefas que executam manutenção nos índices
de tabelas para executarem periodicamente, e assim por diante. As possibilidades são muitas.
Um job também pode ser criado e não agendado para executar periodicamente, sendo que o DBA pode
executá-lo manualmente, quando for necessário.
Normalmente agendamos, para execução automática, aquelas tarefas rotineiras que o DBA deve executar,
como backups, manutenção de índices e qualquer outra tarefa que tenha que ser executada
periodicamente. Com isso liberamos o DBA de uma série de tarefas administrativas repetitivas.
Para que a execução de tarefas funcione corretamente, o serviço SQL Server Agent deve estar rodando. O
ideal é que este serviço seja configurado para inicializar automaticamente. Podemos fazer esta configuração
utilizando o SQL Computer Manager, conforme descrito no Capítulo 2. A Figura 5.20 mostra o serviço
SQL Server Agent configurado para iniciar automaticamente, usando o SQL Computer Manager.
Figura 5.20 O Serviço SQL Server Agent.
Cabe ainda lembrar que cada instância do SQL Server 2005 instalada no servidor possui o seu próprio
serviço SQL Server Agent associado, isto é, se tivermos duas ou mais instâncias do SQL Server instaladas,
poderemos ter o SQL Server Agent rodando em uma das instâncias e configurado para não iniciar
automaticamente na outra instância.
Além do serviço SQL Server Agent, precisamos do Banco de Dados msdb (o qual está dentro da opção
System Databases). É neste Banco de Dados que ficam armazenadas as informações e os agendamentos
dos jobs. Observe a Figura 5.21, onde temos uma visão do conteúdo da tabela sysjobs, onde temos
informações sobre diversos jobs. Os jobs que aparecem nesta tabela foram criados quando criamos
agendamento para os backups do log de transações, no item anterior. Lembre que foi dito que a maneira
de criar um agendamento para o backup era através da criação de um job.
Figura 5.21 A tabela sysjobs, do Banco de Dados msdb.
Neste item aprenderemos a criar e a gerenciar jobs.
CRIANDO UM JOB COM O SQL SERVER MANAGEMENT STUDIO

A título de exemplo, vamos criar um job que faz o backup completo dos Bancos de Dados Exemplo1 e
AdventureWorks, para o backup device exercicio_capitulo5. Vamos agendar este job para executar
diariamente às 23h.
NOTA
O backup device exercicio_capitulo5 já deve ter sido criado, caso contrário o job irá falhar na execução. Este backup device foi criado em um
dos exemplos anteriores, neste capítulo.
Exemplo prático: Para criar um job que faz o backup completo dos Bancos de Dados Exemplo1 e
AdventureWorks, para o backup device exercicio_capitulo5, siga os passos indicados a seguir:
2. Dê um clique no sinal de + ao lado da instância SERVIDOR\SQL2005, onde estão os bancos de

dados Exemplo1 e AdventureWorks, os quais farão parte do backup a ser executado
automaticamente, pelo job que estamos criando.
3. Nas opções que surgem abaixo desta instância, clique no sinal de + ao lado da opção SQL
Server Agent para expandi-la.
4. Observe que, abaixo da opção jobs, serão exibidos os Jobs já existentes.
5. Para criar um novo job, clique com o botão direito do mouse na opção Jobs e, no menu de
opções que surge, dê um clique em New Job. Surge a janela New Job Properties, para a criação
de um novo job, conforme indicado na Figura 5.22, com a guia General selecionada por padrão:
Figura 5.22 Criação de um novo job.
6. Para o nome do job digite backupExemplo1AdventureWorks, no campo Name.
7. Na lista Category, selecione Databasa Maintenance. Este campo apenas atribui uma determinada
categoria ao job, o que ajuda na identificação das funções do mesmo.
8. No campo Owner, podemos selecionar o “dono” do job. Conforme veremos no próximo
capítulo, todo objeto no SQL Server possui um dono. O dono de um objeto é o usuário que
estava logado e que criou o objeto. No nosso exemplo, como estou utilizando a segurança do
próprio SQL Server utiliza conta as de logon do próprio SQL Server. Com isso vou selecionar a
conta as, que é a conta de administrador do SQL Server 2005. No próximo capítulo estudaremos
a segurança no SQL Server 2005 em detalhes.
9. No campo Description, digite o seguinte:

Faz o backup de Exemplo1 e AdventureWorks, diariamente, às 23:00 h.
Sua janela deve estar conforme indicado na Figura 5.23:
Figura 5.23 A guia General da janela de criação do job.
10. Dê um clique na guia Steps. Nesta guia poderemos definir os passos que o job executará. No
nosso exemplo, haverá dois passos. Um que faz o backup do Banco de Dados Exemplo1 e outro
que faz o backup do Banco de Dados AdventureWorks.
11. Para criar um novo passo, dê um clique no botão New. Surge a janela indicada na Figura 5.24:
Figura 5.24 Criando um novo passo para o Job.
12. Preencha os campos da seguinte maneira:
♦ Step Name: backupExemplo1.
♦ Type: Certifique-se de que esteja selecionado Transact-SQL Script (T-SQL). Isto indica que
o passo que está sendo criado executará um comando T-SQL. À medida que você for ficando
mais familiarizado com a linguagem T-SQL, verá que é possível automatizar a maioria das
tarefas de administração do SQL Server 2005.
♦ Database: Selecione Exemplo1.
♦ Command: Digite o seguinte comando:

BACKUP DATABASE Exemplo1 to exercicio_capitulo5
13. Para verificar se o comando digitado está correto clique no botão Parse. Se o comando estiver
correto, surge uma janela com a mensagem The command has suces parsed. Clique em OK
para fechar esta mensagem. Dê um clique em OK e pronto, o primeiro passo terá sido criado.
14. Para criar o segundo passo, dê um clique no botão New.
15 Preencha os campos da seguinte maneira:
♦ Step Name: backupAdventureWorks.
♦ Type: Certifique-se de que esteja selecionado Transact-SQL Script (T-SQL). Isto indica que o
passo que está sendo criado executará um comando T-SQL.
♦ Database: Selecione AdventureWorks.
♦ Command: Digite o seguinte comando:

BACKUP DATABASE AdventureWorks to exercicio_capitulo5
16. Dê um clique em OK e pronto, o segundo passo do job terá sido criado, conforme indicado na
Figura 5.25:
Figura 5.25 Dois passos já adicionados ao job.
Os passos são executados na ordem em que foram criados. Você pode alterar a ordem dos passos,
clicando no passo e depois clicando nos botões com seta para cima e seta para baixo.
O passo final é configurar o agendamento para o job que está sendo criado. Conforme descrito no
início deste exemplo, vamos agendar o job para executar diariamente, às 23h.
17. Dê um clique na guia Schedules.
18. Para criar um novo agendamento, dê um clique no botão New. Surge a janela indicada na
Figura 5.26, na qual você poderá definir o agendamento para o job.
Figura 5.26 Criando um novo agendamento.
19. Para o nome do agendamento digite DiarioAs23horas.
As opções para agendamento foram descritas no item sobre o backup do log de transações, neste capítulo.
20. Certifique-se de que a opção Recurring esteja marcada. Agora vamos configurar o horário de
execução do job.
21. Configure as opções conforme indicado na Figura 5.27.
22. Dê um clique no botão OK para fechar a janela da Figura 5.27.
23. Você estará de volta à guia Schedules. Observe que o novo agendamento já foi adicionado.
Podemos configurar mais do que um agendamento para um job. Por exemplo, se quiséssemos que o job fosse executado diariamente às 23h
NOTA
e às segundas, quartas e sextas iniciando às 8h, até as 20h, executando de duas em duas horas, teríamos que criar dois agendamentos
distintos. Para criar mais um agendamento, bastaria clicar novamente no botão New. e definir as configurações para o novo agendamento.
Agora já temos todas as definições necessárias para a criação do job proposto.
24. Dê um clique no botão OK e o job backupExemplo1AdventureWorks será criado e será executado

diariamente às 23h.
Figura 5.27 Definindo o agendamento do job.
Não precisamos esperar até as 23 para ver se o job vai executar com sucesso. Podemos executar o job
manualmente, a qualquer momento. Para isso basta clicar com o botão direito do mouse no job e, no
menu que surge, clicar em Start Job. Quando um job possui mais do que um passo, surge uma janela
com a lista dos passos e perguntando qual deve ser o primeiro passo a ser executado, conforme indicado
na Figura 5.28. Para iniciar a execução do job, basta clicar no botão Start.
Figura 5.28 Lista de passos do job.
Você pode impedir que um job seja executado desabilitando o job. Para desabilitá-lo, clique com o
botão direito do mouse sobre o job e no menu de opções que surge, dê um clique na opção Disable.
Surge uma janela com uma mensagem. Clique em Close para fechá-la. Enquanto o job estiver
desabilitado, este não será executado. Para habilitá-lo novamente, clique com o botão direito do mouse
no job, e no menu de opções que surge dê um clique na opção Enable.
Para verificar se um job está executando corretamente você pode consultar o histórico de execução do
Job. Para consultar este histórico, clique com o botão direito do mouse no job, e no menu de opções
que surge dê um clique na opção View History.
Surge a janela Job History, com todas as execuções do job, onde são indicadas as seguintes informações
sobre cada execução, conforme indicado na Figura 5.29:
Figura 5.29 O histórico de execução do job.
♦ Data.
♦ Resultado da execução: Successful indica que o job executou com sucesso.
♦ Notificações: Podemos fazer com que o job notifique o administrador em caso de sucesso ou
falha na execução.
♦ Duração da execução do job.
À medida que você dominar a linguagem T-SQL, a utilização de jobs passa a ser uma ferramenta de
grande valor para automatizar uma série de tarefas repetitivas e rotineiras.
Na maioria das vezes quando um job não funciona corretamente, pode ser um dos seguintes problemas:
1. O serviço SQL Server Agent não está rodando.

2. O comando T-SQL está incorreto.
CONCLUSÃO
Neste capítulo aprendemos conceitos fundamentais para a manutenção de um Banco de Dados no
SQL Server 2005.
Iniciamos o capítulo aprendendo sobre transações e o log de transações no SQL Server 2005. Conforme
vimos, o log de transações tem um papel fundamental na recuperação de um Banco de Dados em caso
de falhas e também na manutenção da consistência e da integridade dos dados.
Ainda na parte teórica, aprendemos sobre os tipos de backup disponíveis no SQL Server 2005, quais as
estratégias de recuperação para os diferentes tipos de backup e alguns exemplos práticos de utilização
das estratégias apresentadas.
Na seqüência, aprendemos o conceito de backup device. Também aprendemos a criar backup devices
com o SQL Server e usando comandos T-SQL. Em seguida, aprendemos a criar e a restaurar backups,
utilizando o SQL Server Management Studio e comandos T-SQL.
Fechamos o capítulo aprendendo a criar e agendar jobs, para automatizar a execução de tarefas
administrativas.
Saber utilizar as ferramentas administrativas para executar backups e restore quando necessário é
importante, porém é de fundamental importância o planejamento das rotinas de backup/restore a
serem utilizadas. Conforme visto neste capítulo, diversos fatores devem ser levados em conta na hora
de montar a nossa estratégia de backup/restore, como por exemplo:
♦ Tempo máximo de parada para backup (janela de backup).
♦ Backup completo, diferencial ou de log.
♦ Qual o tempo de downtime aceitável, isto é, em caso de falha no Banco de Dados, qual o
tempo aceitável para que o banco de dados seja colocado de volta on-line.
♦ Qual o custo da perda dos dados.
♦ É admissível perda dos dados? Qual o nível de perdas aceitável? Um dia? Uma hora? Um
minuto?
Agora é hora de aprendermos sobre segurança no SQL Server 2005. Mas isso é assunto para o próximo
capítulo.
Capítulo 6
SEGURANÇA NO SQL SERVER 2005
INTRODUÇÃO
O SQL Server 2005 pode ser utilizado como Banco de Dados em uma série de situações, como por
exemplo:
♦ Para sites de comércio eletrônico.
♦ Para armazenar os dados do site de um banco.
♦ Para as diversas aplicações que rodam na empresa, como por exemplo aplicações financeiras,
contábeis, etc.
♦ Para cadastro de alunos, disciplinas, turmas, matrículas e notas em uma universidade ou grande
escola.
♦ Enfim, onde um Banco de Dados for necessário.
O que podem apresentar em comum ambientes tão diversos?
Muito simples: a necessidade de segurança no acesso às informações. Falando de uma maneira simples,
a segurança no acesso às informações significa que o usuário deve ser capaz de acessar os dados
necessários com nível de acesso suficiente (e não mais do que suficiente), para que o usuário realize o
seu trabalho. Se um usuário trabalha no atendimento ao público, fornecendo informações aos clientes,
é óbvio que ele não deve ter permissão para alterar, excluir ou inserir dados, mas somente permissão
para leitura dos dados. Ao configurarmos corretamente os mecanismos de segurança do SQL Server
2005, garantiremos que somente podem acessar os dados de um Banco de Dados os usuários autorizados
e com o nível de acesso necessário para que executem o seu trabalho.
Através dos mecanismos de segurança também evitamos que pessoas não-autorizadas tenham acesso
aos dados. Claro que não existe sistema operacional ou sistema de Banco de Dados 100% seguro.
Diariamente temos notícias de sistemas que foram invadidos, principalmente através da Internet.
Mas, com certeza, se configurarmos corretamente a segurança do Windows 2000 Server ou Windows
Server 2003 e do SQL Server 2005, dificultaremos, enormemente, a vida de quem quer invadir nossos
sistemas. Muitas das invasões conhecidas acontecem por má configuração dos mecanismos de segurança
disponíveis (uma das situações mais conhecidas, com o SQL Server 2000, era o caso de servidores com
a senha da conta sa em branco. Este era o padrão para o SQL Server 2000, ou seja, a menos que você
definisse uma senha para a conta sa, a senha padrão seria em branco. E para piorar um pouco mais, a
conta é a conta com “poderes máximos” no SQL Server. Ou seja, deixar um servidor com a conta sa
com senha em branco é equivalente a deixar a chave embaixo do tapete, na porta da frente e pendurar
um luminoso com letras bem grandes com a frase “A chave está embaixo do tapete”. Este era um
NOTA
exemplo típico de problema de segurança, devido à má configuração do SQL Server, ou seja, o

administrador deixava a senha da conta em branco).
Por que essa conversa toda sobre segurança?
Porque este é justamente o assunto deste capítulo. Veremos quais os mecanismos de segurança
disponíveis no SQL Server 2005, para garantir a segurança no acesso às informações contidas nos
Bancos de Dados. Aprenderemos a configurar e administrar estes mecanismos. Também falaremos,
brevemente, sobre os mecanismos básicos de segurança do Windows 2000 Server ou Windows
Server 2003.
CAPÍTULO 6 – SEGURANÇA NO SQL SERVER 2005
Neste capítulo apresentaremos:
♦ Uma visão geral da segurança no SQL Server 2005.
♦ As novidades do SQL Server 2005, na área de segurança.
♦ Tipos de segurança disponíveis no SQL Server 2005.
♦ O papel, criação e administração de Schemas e User Logins – contas de usuários para logon no
servidor SQL Server 2005.
♦ Como atribuir permissões aos objetos de um Banco de Dados.
♦ O que são Roles, como criá-las e administrá-las.
♦ O planejamento e o gerenciamento da segurança.
Utilizarei a mesma metodologia dos capítulos anteriores. Sempre que for cabível, você aprenderá a
executar as operações propostas utilizando tanto o SQL Server Management StudioSQL Server 2005,
quanto comandos T-SQL, na janela de execução de comandos do SQL Server Management Studio.
KNOW-HOW EM: SEGURANÇA NO SQL SERVER 2005

PRÉ-REQUISITOS
♦ Saber utilizar o SQL Server Management Studio SQL Server 2005 e o Query Analyzer.
METODOLOGIA
♦ Apresentação teórica sobre o modelo de segurança do SQL Server 2005.
A segurança no SQL Server 2005 é baseada nos seguintes conceitos:
♦ Logins
♦ User Accounts
♦ Schemas
♦ Roles
♦ Permissions
PRIMEIRO PRECISAMOS CONECTAR COM O SERVIDOR SQL SERVER 2005

O primeiro passo para que o usuário possa acessar o servidor SQL Server é estabelecer uma conexão
com uma instância do servidor SQL Server 2005. Ao estabelecer uma conexão, o usuário deve fornecer
o seu nome (login) e senha. O SQL Server verifica se o login e senha fornecidos têm permissão de
acesso ou, melhor, permissão para conectar com a instância do SQL Server 2005. Em caso afirmativo,
a conexão com o servidor SQL Server 2005 é estabelecida. A Figura 6.1 ilustra este conceito.
Figura 6.1 Usuário conectando com o servidor SQL Server 2005.
Nesta situação, descrita na Figura 6.1, o usuário jsilva conseguirá estabelecer a conexão, que tecnicamente
chamamos de sessão, com a instância SRVINST01 do servidor SQL Server SERVIDOR ->
SERVIDOR\SRVINST01. Ao tentar efetuar a conexão, as informações de login e senha são passadas
para o servidor SQL e comparadas com a lista de usuários autorizados a acessar o servidor. Caso o
usuário esteja na lista de usuários autorizados e a senha esteja correta, a conexão será estabelecida. No
nosso exemplo, o usuário cadastrado como maria não conseguirá a conexão, pois não existe login
maria, cadastrado no servidor SQL Server.
Agora vamos analisar uma situação um pouco diferente, conforme indicado na Figura 6.2.
Figura 6.2 Acesso negado devido a senha incorreta.
Nesta segunda situação, o usuário com login maria continua não tendo acesso ao servidor SQL. Porém
agora o problema é que a senha foi informada incorretamente.
Normalmente o usuário está utilizando uma aplicação que acessa um Banco de Dados no servidor SQL
Server 2005. Dentro da própria aplicação, o usuário deve digitar o seu login e senha de acesso. Pode ser
que a aplicação seja uma página ASP ou uma aplicação Cliente/Servidor, desenvolvida em Delphi ou
em Visual Basic. Da mesma maneira poderíamos construir um formulário com campos para que o
usuário informe o seu login e senha.
Porém pode ser, no mínimo, incômodo fazer com que o usuário forneça informações de login e
senha, cada vez que for usar cada diferente aplicação, que faz conexão com uma ou mais instâncias
do SQL Server 2005. Vamos supor que o usuário tenha feito o logon em um domínio do Windows
2000 Server ou do Windows Server 2003. Não poderíamos utilizar as informações de logon do
usuário no domínio Windows 2000 Server ou do Windows Server 2003, como credenciais para
acessar o servidor SQL Server? Em outras palavras, não poderíamos autorizar o acesso ao servidor
SQL Server diretamente para usuários ou grupos do domínio do Windows 2000 Server ou do Win-
dows Server 2003?
A resposta a ambas as perguntas é sim. Essas duas possibilidades, ou seja, usar contas de usuários
criadas no próprio SQL Server 2005 ou usar contas de um domínio do Windows 2000 Server ou Win-
dows Server 2003 é que caracterizam os dois diferentes modos de autenticação que podemos utilizar
no SQL Server 2005. Os modos de autenticação possíveis são os seguintes:
♦ Windows Authentication mode.
♦ SQL Server and Windows Authentication mode.
No modo SQL Server and Windows Authentication mode podemos dar autorização de acesso para
as contas de um domínio do Windows 2000 Server ou Windows Server 2003. Com este modo não
é necessária a criação de logins (contas de usuário) no próprio SQL Server 2005. O usuário utiliza
uma aplicação para acessar o Banco de Dados e a aplicação já passa as informações do logon que o
usuário fez no domínio (nome de usuário e senha) diretamente para o SQL Server 2005, evitando
que o usuário tenha que digitar novamente informações de login e senha. Porém este modo também
permite que sejam criadas contas de login no próprio SQL Server 2005. As contas criadas no SQL
Server 2005 ficam armazenadas no Banco de Dados master de cada instância. Esta prática não é
recomendada, uma vez que teremos várias listas de usuários e senhas para administrar: a lista do
domínio e uma lista em cada instância do SQL Server. Ao invés de criar contas no SQL Server 2005,
podemos dar permissão de acesso para as contas do domínio. Por padrão, a conta Administrador
do domínio recebe permissões completas de acesso ao SQL Server e a todos os seus objetos. A conta
Administrador é adicionada à lista de contas com permissão de acesso quando da instalação do
SQL Server 2005. Esta conta possui as mesmas permissões que a conta sa. A conta sa é uma conta
do próprio SQL Server, a qual é criada quando da instalação do SQL Server. Esta conta também
possui poderes totais sobre todos os objetos de uma instância do SQL Server 2005. Na Figura 6.3,
podemos observar que a conta Administrador do domínio SERVIDOR já foi incluída na lista de
contas com permissão de acesso ao servidor.
Figura 6.3 Conta SERVIDOR\Administrador com permissão de login.

NOTA
Mais adiante aprenderemos a acessar a opção Logins, indicada na Figura 6.3. Utilizarei os termos login e conta com o mesmo significado.
Para maiores informações sobre Domínios do Windows 2000 Server e do Active Directory consulte o livro Manual de Estudos Para o Exame
70-217, 752 páginas, de minha autoria e publicado pela Editora Axcel Books. Para maiores informações sobre Domínios do Windows Server
2003 e sobre o Active Directory no Windows Server 2003, consulte o livro “Windows Server 2003 – Curso Completo de minha autoria,
também publicado pela Editora Axcel Books (www.axcel.com.br).
No modo de segurança Windows Authentication mode, somente serão aceitas contas do domínio do
Windows. Ou seja, para que o usuário tenha acesso ao SQL Server, este deve ter uma conta cadastrada
no domínio e a sua conta deve ter recebido permissão de acesso ao servidor SQL. Neste modo não
poderemos criar contas no próprio SQL Server. É importante salientar que, mesmo no modo Win-
dows Authentication mode, a conta sa continua válida e pode ser utilizada. A conta sa, por ser uma
conta de administrador do SQL Server 2005, é uma exceção e pode ser utilizada em qualquer modo.
Outro detalhe importante a ser salientado é que, para usar o modo Windows Authentication mode,
não é obrigatório (embora seja recomendado) que exista um domínio baseado no Active Directory.
Se não houver um domínio, poderão ser utilizadas as contas locais, da base de usuários locais, do
servidor Windows 2000 Server ou Windows Server 2003, onde está instalada a instância do SQL
Server 2005.
Podemos alterar entre os modos Windows Authentication Mode e SQL Server and Windows Authenti-
cation Mode facilmente, utilizando o SQL Server Management Studio. Veja o exemplo prático a seguir.
Para alterar o modo de segurança do SQL Server 2005, faça o seguinte:
1. Abra o SQL Server Management StudioSQL Server 2005 (Iniciar -> Programas -> Microsoft SQL
Server 2005 -> SQL Server Management Studio).
2. No janela Object Explorer, clique com o botão direito do mouse na instância a ser configurada
e, no menu que surge, dê um clique em Properties.
3. Na janela que surge dê um clique na opção Security, no painel da esquerda. Surge a janela
indicada na Figura 6.4. Nesta janela, no grupo Server authentication, você seleciona a forma
de autenticação a ser utilizada, pela instância do SQL Server 2005, que está sendo configurada.
Figura 6.4 Alterando o modo de segurança do SQL Server 2005.
4. Se você alterar o modo e clicar em OK, o SQL Server 2005 emite uma mensagem dizendo que
as alterações somente terão efeito depois que o serviço SQL Server for parado e reinicializado.
5. Para reinicializar o serviço do SQL Server 2005, clique com o botão direito do mouse na instância
que está sendo configurada e, no menu de opções que é exibido, clique na opção Restart.
6. Surge uma janela indicando o progresso da reinicialização do serviço. Após reinicializado o

serviço, já estará valendo o modo e autenticação selecionados.
NOTA
O modo de segurança é configurado de maneira independente para as diversas instâncias do servidor SQL Server 2005 instaladas em um
mesmo servidor. Por exemplo, se tivermos duas instâncias instaladas, uma pode estar no modo Windows Authentication mode e a outra estar
no modo SQL Server and Windows Authentication mode.
DEPOIS DE CONECTADOS, PRECISAMOS DE PERMISSÕES

PARA ACESSAR OS OBJETOS DO BANCO DE DADOS
Ter permissão de login, quer seja um login do próprio SQL Server 2005 ou um login do domínio, é
apenas a primeira etapa do processo. Muito bem, você conseguiu fazer o logon no SQL Server 2005, e
agora? Uma vez conectado ao servidor SQL Server, o usuário precisa de permissões de acesso a um ou
mais Bancos de Dados e para acessar os objetos (tabelas, views, stored procedures, etc.) de um ou mais
Bancos de Dados.
Conforme vimos no Capítulo 2, em um único servidor SQL Server, podemos ter uma ou mais instâncias
do SQL Server instaladas. Cada instância é como se fosse um servidor completamente separado. Em cada
instância podemos ter vários Bancos de Dados, os quais podem ter os seguintes objetos, dentre outros:
♦ Tables
♦ Views
♦ Stored Procedures
♦ Extended Stored Procedures
♦ Users
♦ Roles
♦ Rules
♦ Defaults
♦ User Defined Data Types
♦ User Defined Functions
♦ Full-Text Catalogs.
NOTA
Já aprendemos a criar alguns destes elementos e iremos aprender a criar outros no decorrer deste livro.
No item anterior vimos que o usuário precisa de um login para conectar-se com uma instância do servidor
SQL. A conexão sempre é feita com uma instância do servidor SQL Server. Ao fazer a conexão, o usuário
é automaticamente associado a um dos Bancos de Dados da instância à qual se conectou. Conforme
veremos na parte prática, é possível definir com qual Banco de Dados o login será automaticamente
associado. Mas isso não significa que o usuário somente poderá acessar dados do Banco de Dados com o
qual ele é automaticamente associado, durante a conexão. Aí é que entra o segundo estágio de segurança
pelo qual o usuário terá que passar. Além de fazer a conexão, o usuário precisa estar autorizado para
acessar o(s) Banco(s) de Dado(s), nos quais estão as informações que o usuário precisa acessar. Então, o
próximo passo é autorizar o usuário a acessar um ou mais Bancos de Dados.
Podemos dar permissão para o usuário ou para uma role ao qual ele pertence. O conceito de role, no
SQL Server 2005, é exatamente igual ao conceito de Grupos de Usuários no Windows 2000 Server ou
no Windows Server 2003. Uma role pode conter um ou mais usuários. Se dermos uma permissão para
uma role, todos os usuários que pertencem à role irão herdar as permissões atribuídas à Role. É ou não
é a mesma coisa que grupos de usuários no Windows, no UNIX, Linux, Novell, etc.? Mas, enfim, quem
sou eu para criticar a criatividade do pessoal que inventa os nomes para os objetos do SQL Server 2005?
Vejam que o usuário já precisa passar por dois níveis de segurança:
♦ Permissão para fazer a conexão com o SERVIDOR\INSTÂNCIA.
♦ Permissão para acessar um ou mais Bancos de Dados.
Observe o exemplo da Figura 6.5.
Figura 6.5 Usuário com permissão de conexão, porém sem permissão no Banco de Dados.
Nesta situação, o usuário jsilva tem permissão para fazer a conexão com uma instância do servidor SQL
Server, porém não tem permissão para acessar o Banco de Dados Clientes, que está no servidor SQL.
Neste caso se jsilva tentar acessar algum objeto do Banco de Dados Clientes, o acesso será negado, pois
jsilva não tem permissão de acesso a este Banco de Dados.
Para que jsilva possa ter acesso ao Banco de Dados Clientes temos que adicioná-lo à lista de usuários
autorizados a acessar o Banco de Dados Clientes e dar as permissões para que ele possa realizar as
tarefas necessárias (você verá no próximo tópico que, na verdade, as permissões são dadas não
diretamente aos objetos do Banco de Dados, tais como tabelas e views, mas sim ao schema ao qual
pertence o objeto. No próximo tópico farei uma explicação detalhada sobre schemas, pois esta é uma
das novidades de segurança, mais importantes do SQL Server 2005). Exemplos de permissões para
Bancos de Dados são as seguintes:
♦ Criar tabelas
♦ Excluir tabelas
♦ Alterar tabelas
♦ Criar roles
♦ Criar views
Conectei com o servidor SQL, tenho permissão de acesso ao Banco de Dados e ainda não consigo
executar uma consulta. O que está acontecendo?
Figura 6.6 Usuário com permissão de conexão, permissão no Banco de Dados,

porém sem permissão na tabela Pagamentos.
Além das permissões para acessar o Banco de Dados, podemos e devemos definir permissões de acesso
para cada objeto de um Banco de Dados. Por exemplo pode ser que alguns usuários devam ter permissão
de leitura na tabela Cadastro do Banco de Dados Clientes, porém somente os gerentes devem ter
permissão de leitura na tabela Pagamentos do Banco de Dados Clientes. Podemos definir o acesso,
individualmente, para cada tabela, view, etc., para cada objeto de um Banco de Dados. Portanto, podemos
definir permissões de acesso para cada objeto que faz parte de um Banco de Dados.
O fato de podermos definir permissões para cada objeto nos dá uma grande flexibilidade. A partir desta
flexibilidade é que podemos definir diferentes níveis de acesso para diferentes usuários, o que é bastante
comum e necessário nas aplicações atuais. Alguns usuários devem ter permissão de leitura aos dados;
outros de leitura e alteração; outros leitura, alteração e exclusão e assim por diante.
Observe o exemplo da Figura 6.6.
Neste exemplo, temos os seguintes passos:
1. O usuário jsilva consegue fazer a conexão com a instância do servidor SQL Server 2005.
2. O usuário jsilva está autorizado a acessar o Banco de Dados Clientes.
3. O usuário jsilva NÃO ESTÁ AUTORIZADO a acessar os dados da tabela Pagamentos.
Veja que temos três barreiras de segurança a serem vencidas, antes que o usuário possa acessar os dados
de uma tabela: 1) permissão de logon; 2) permissão no Banco de Dados; 3) permissão no objeto que ele
precisa acessar.
SCHEMAS – PRINCIPAL NOVIDADE DE SEGURANÇA DO SQL SERVER 2005

O SQL Server 2005 introduziu uma importante mudança no modelo de segurança, em relação ao SQL
Server 2000: A separação entre usuários e o schema. Para que o amigo leitor não fique perdido e possa
entender bem o que é um schema e qual foi a mudança introduzida pelo SQL Server 2005, vamos,
inicialmente, definir alguns conceitos importantes e, depois, mostrar como estes conceitos se relacionam
com a segurança e com a definição de schema.
O primeiro conceito que temos que conhecer é o conceito de Principal. Um principal é considerado
qualquer objeto que possa solicitar acesso a recursos do SQL Server 2005. Sob este ponto de vista,
usuários, grupos de usuários e processos podem ser considerados como Principals. Uma outra definição,
mais voltada para Banco de Dados, seria que um principal é qualquer objeto, para o qual possa se
definir permissões de acesso (ou negá-las) para os objetos de um Banco de Dados. Sob este ponto de
vista, seriam principals objetos tais como usuários e grupos do Windows, logins e roles do SQL Server
2005, e applications roles. Como eu gosto de simplificar ainda mais, em termos desta discussão, vou
considerar como principals usuários ou grupos do Windows ou do SQL Server 2005.
Muito bem. Conhecido o conceito de principals é hora de conhecermos um pouco mais sobre outro
importante conceito: Schema. No SQL Server 2000 o conceito de schema era praticamente ignorado;
já para o modelo de segurança do SQL Server 2005, este conceito é de fundamental importância. Então
vamos a ele.
Pelos padrões de definição do Ansi SQL-92, um schema é um conjunto de objetos, sendo que todos os
objetos pertencentes a um schema têm como dono o mesmo principal. Em outras palavras, dentro de
um schema, todos os objetos pertencentes ao schema têm como dono do objeto o mesmo usuário ou
grupo (roles se for um grupo do SQL Server 2005). De uma maneira ainda mais simples, podemos
definir um schema, como sendo um container para outros objetos, de tal maneira que todos os objetos
contidos em um schema têm o mesmo dono. Outra característica importante do schema é que ele deve
formar um espaço de nomes. O que significa formar um espaço de nomes? Significa que o nome de
cada objeto, dentro do espaço de nomes, deve ser único. Ou traduzindo: não pode haver dois objetos,
com o mesmo nome, dentro do mesmo schema. Por exemplo, duas tabelas somente poderão ter o
mesmo nome, se pertencerem a schemas diferentes.
No SQL Server 2000 não havia uma separação entre os conceitos de Usuário e schema. No SQL Server
2000, todo usuário é o dono de um schema, o qual tem o mesmo nome do usuário. Por exemplo, o
usuário jsilva, automaticamente, é configurado como dono de um schema chamado jsilva. O mesmo
é válido para todos os usuários do SQL Server 2000. Com esta ligação, o dono de um objeto é exatamente
o mesmo dono do schema que contém o objeto. Por isso que, no SQL Server 2000, antes de poder
excluir um usuário, você tinha que excluir todos os objetos dos quais o usuário era o dono, ou teria que
alterar o dono de todos estes objetos. Por exemplo, considere o objeto a seguir (lê-se de trás para frente:
tabela clientes, cujo dono é o usuário jsilva, tabela esta pertencente ao Banco de Dados vendas, do
servidor “servidor”), pertencente a um Banco de Dados do SQL Server 2000:
servidor.vendas.jsilva.clientes
Neste exemplo, o dono da tabela Clientes é o usuário jsilva. Se o administrador do Banco de Dados
precisar excluir o usuário jsilva, ele terá que, primeiro, excluir este e todos os demais objetos quais o
usuário jsilva é o dono ou terá que alterar o dono destes objetos. Um trabalho e tanto, convenhamos. Por
exemplo, o administrador poderia alterar o dono da tabela clientes, para que, ao invés do usuário jsilva,
o novo dono fosse o usuário pedro. Com isso, o nome completo do nosso objeto ficaria assim:
servidor.vendas.pedro.clientes
Observe que, ao alterar o dono do objeto, o nome completo do objeto também se altera, passando de
servidor.vendas.jsilva.clientes para servidor.vendas.pedro.clientes. Este era um problemão que existia no
SQL Server 2000. Pois, ao alterar o nome completo de um objeto, qualquer programa cujo código faça
referência ao nome completo do objeto terá que ser alterado. Vejam que uma simples renomeação de
objeto pode gerar uma grande carga de trabalho, com a necessidade de revisão do código das aplicações,
geração de novas versões atualizadas e instalação destas versões nos clientes. Um senhor trabalho!
Bem, felizmente isso tudo mudou no SQL Server 2005. No SQL Server 2005 todos os objetos de um
Banco de Dados têm como dono um schema. Nenhum objeto de Banco de Dados pode ter como dono
um usuário ou grupo (Principal seria o nome técnico, mas estou utilizando o termo usuário ou grupo).
Os usuários são donos de schemas e não mais diretamente de objetos do Banco de Dados, tais como
tabelas ou views. Lembrando também que todos os objetos estão dentro de um schema, ou seja, o
schema é um container para objetos. Com isso podemos ver que existe uma separação, explícita, entre
usuários e schemas, muito diferente do que ocorria no SQL Server 2000. No SQL Server 2005, temos a
seguinte sintaxe, para o nome completo de um objeto:
Nome_do_Servidor.Nome_do_Banco_de_Dados.Nome_do_Schema.Nome_do_Objeto
Mas onde está a vantagem desta mudança? Bem simples. No SQL Server 2005 os objetos do Banco de
Dados estão contidos dentro de um schema, e não existe nenhuma relação entre o schema e os usuários.
Com isso, posso alterar o dono de um schema, sem problemas, pois só irá alterar o dono do schema,
mas não será alterado o nome do schema. Por exemplo, considere o seguinte objeto:
SRVDB.Vendas.Dados.Clientes
No SQL Server 2005 este objeto é a tabela Clientes, a qual pertence ao schema Dados, do Banco de
Dados Vendas, do servidor SRVDB. Se precisarmos alterar o dono do schema Dados, não tem problema,
pois isso só irá alterar o dono do schema e não o seu nome. Isso só ocorre porque houve esta separação
entre schema e usuários, no SQL Server 2005. Com isso, o nome do schema pode permanecer sempre
o mesmo e podemos alterar o seu dono, quando necessário. Com isso, o nome completo do objeto não
muda, o que evita a revisão freqüente no código das aplicações, o que ocorria no SQL Server 2000.
Podemos resumir estas mudanças, da seguinte maneira:
♦ Um schema é um container para objetos.
♦ Todo objeto pertence a um schema.
♦ Todos os objetos de um schema têm o mesmo dono, que é o dono do schema.
♦ As permissões podem ser atribuídas para o schema também para os objetos dentro de um schema.
Principais benefícios da separação entre usuários e schemas:
♦ Múltiplos usuários podem ser donos de um schema, através da definição de uma role ou um
grupo do Windows, como dono do schema. Com isso, todos os usuários que forem membros
da role ou do grupo do Windows serão donos do schema. Ou seja, defino uma role ou grupo
do Windows como sendo o dono de um schema e todos os seus membros passam a ser
donos do schema.
♦ O processo de exclusão de um usuário ficou bem mais simplificado, conforme descrito

anteriormente. Para excluir um usuário, não é mais necessário alterar o dono de todos os
objetos cujo usuário era dono, uma vez que no SQL Server 2005 o usuário não é mais dono de
objetos e sim de schema. Isso evita uma série de problemas, conforme descrito anteriormente.
♦ Com a possibilidade de definição de permissões diretamente em um schema e também nos

objetos contidos no schema, podemos definir um nível de permissões muito mais granular do
que no SQL Server 2000.
Outro importante conceito introduzido pelo SQL Server 2005 é o conceito de Default Schema
(Esquema padrão). Este conceito é utilizado para definir que nome deve ser utilizado, quando é feita
referência a um objeto, sem utilizar o nome completo. Por exemplo, considere o objeto
DBSRV01.vendas.aplicacoes.clientes. Este é o nome completo (Full Qualified Name), da tabela Clientes,
do schema aplicações, do Banco de Dados Vendas, do servidor DBSRV01. No SQL Server 2000, se não
for especificado o nome completo, inicialmente será procurado por um nome que inclui um schema
com o mesmo nome do usuário que é o dono do objeto. Por exemplo, se o dono da tabela clientes
for o usuário jsilva e você especificar apenas o nome da tabela clientes, o SQL Server 2000 irá procurar,
inicialmente, por um objeto chamado jsilva.clientes. Se ele não encontrar, ele procura por um schema
chamado dbo, ou seja, irá procurar por dbo.clientes. Já no SQL Server 2005, com a separação entre os
usuários e os schemas, o schema definido como default schema define qual será o primeiro nome de
schema a ser utilizado para tentar localizar um objeto, quando não é especificado o nome completo
do objeto. Por exemplo, suponha que o schema default para o usuário seja um schema chamado
dados. Se o usuário especificar apenas o nome da tabela Clientes, o SQL Server 2005 irá, primeiramente,
procurar por um objeto chamado dados.clientes, porque dados é o schema default para o usuário. O
schema default pode ser definido e/ou alterado, usando a opção DEFAULT_SCHEMA, do comando
CREATE USER ou do comando ALTER USER, comandos estes que você aprenderá a utilizar neste
capítulo. Se, por acaso, não for definido um schema padrão, o Banco de Dados utilizará, como schema
padrão, o schema dbo. O conceito e uso de default schema traz uma série de vantagens, dentre as
quais podemos destacar.
♦ Diversos usuários podem compartilhar o mesmo default schema, o que facilita a uniformidade
e a padronização, na resolução de nomes.
♦ O fato de um schema padrão poder ser compartilhado por vários usuários permite aos
desenvolvedores de aplicação armazenarem os objetos utilizados pela aplicação, em um schema
especificamente criado para a aplicação, ao invés de usar o schema DBO.
UM RESUMO DA TEORIA SOBRE SEGURANÇA NO SQL SERVER 2005

Conforme descrevemos neste item, existem dois modos de segurança no SQL Server 2005. O modo
Windows Authentication mode, onde somente são aceitos login de usuários do domínio, quer seja de
um domínio Windows NT 2000 Server ou Windows Server 2003 ou usuários locais de um servidor
baseado no Windows 2000 Server ou Windows Server 2003. O modo SQL Server and Windows Au-
thentication mode admite as contas do domínio e também contas criadas no próprio SQL Server 2005.
Para conectar com o servidor, o usuário precisa de um login, quer seja do domínio ou do próprio SQL
Server. Depois o usuário precisa estar na lista de usuários autorizados a acessar os Bancos de Dados
necessários. Dentro de cada Banco de Dados, podem ser definidas as permissões para os schemas onde
estão os objetos a serem acessados e, dentro dos schemas, diretamente para acesso aos objetos. Por
exemplo, um usuário pode receber permissão para consultar os dados de uma tabela e para consultar e
alterar os dados de outra tabela, dentro do mesmo schema.
Pode parecer paranóia todas estas medidas de segurança, mas, conforme descrevemos anteriormente,
a informação é o bem mais valioso de que as empresas dispõem. Proteger este bem é de fundamental
importância. Qual o preço da perda total de um Banco de Dados para os negócios da empresa? Com
certeza bem menor do que treinar o DBA para que este possa entender e configurar corretamente as
opções de segurança do Banco de Dados.
O que vimos até aqui é a teoria sobre segurança no SQL Server 2005. Nos próximos itens você aprenderá
a implementar a segurança na prática. Aprenderemos a criar Login Accounts, a autorizar usuários a
acessar Bancos de Dados, schemas e seus objetos.
Mas antes de aprendermos a parte prática, vamos fazer uma pequena parada para falar de alguns
conceitos básicos de segurança do Windows 2000 Server, como por exemplo os conceitos de Domínio
e Workgroup, contas de usuários e grupos de usuários. Estes conceitos são integralmente válidos para
o Windows Server 2003.
Importante: Até o Capítulo 5, sempre que fazíamos uma conexão com o servidor SQL, estávamos nos conectando com a conta do usuário
NOTA
Administrador. Por isso que tivemos permissão para executar todas as tarefas, como por exemplo criar Bancos de Dados, backup devices, etc.
Por padrão, quando usamos o modo de autenticação Windows Authentication mode, as contas pertencentes ao grupo Administradores têm
poderes totais no SQL Server 2005.
KNOW-HOW EM: SEGURANÇA NO

WINDOWS 2000 SERVER E WINDOWS SERVER 2003
PRÉ-REQUISITOS
♦ Noções básicas do Windows 2000 Server e Windows Server 2003.
METODOLOGIA
♦ Apresentação teórica sobre o modelo de segurança do Windows 2000 Server e Windows Server 2003.
NOTA
Para um curso completo sobre os recursos de segurança no Windows Server 2003, consulte o seguinte livro de minha autoria, publicado pela
editora Axcel Books – www.axcel.com.br : Windows Server 2003 – Curso Completo, 1568 páginas.
Vimos que, no modelo de segurança do SQL Server 2005, podemos dar autorização para usuários e
grupos de usuários de um domínio do Windows 2000 Server ou Windows Server 2003, para conexão
com o servidor SQL Server. Neste item vamos fazer um pequeno parênteses para falar sobre alguns
conceitos de segurança do Windows 2000 Server e também do Windows Server 2003. Estes conceitos
ajudarão o amigo leitor a entender melhor o modelo de segurança do SQL Server 2005.
Neste item tratarei dos seguintes tópicos:
♦ Workgroup x Domínios.
♦ Active Directory.
♦ Contas de usuários em um domínio.
♦ Grupos de usuários em um domínio.
DOMÍNIOS, WORKGROUPS E ACTIVE DIRECTORY

Vamos aprender as diferenças entre um domínio e um workgroup e como o Active Directory encaixa-
se neste conceito.
DOMÍNIOS E GRUPOS DE TRABALHO (WORKGROUPS)

Um rede com Windows 2000 Server ou com o Windows Server 2003 pode ser criada utilizando-se dois
conceitos diferentes, dependendo da maneira como os servidores Windows são configurados. Os
servidores podem ser configurados para fazerem parte de um domínio ou de um grupo de trabalho,
mais comumente chamado de workgroup, termo que utilizarei de agora em diante.
Um domínio é simplesmente um agrupamento lógico de usuários (contas de usuários) e recursos, os

quais compartilham políticas de segurança. Em um domínio podemos ter dois tipos de servidores
Windows: Controladores de Domínio (DC – Domain Controlers) e Servidores Membro (Member Serv-
ers). Veremos um pouco mais sobre Controladores de Domínio e Servidores Membro mais adiante.
A criação de contas de usuários e alterações nas políticas de segurança podem ser feitas em qualquer
um dos controladores de domínio, que estas alterações serão automaticamente repassadas (o termo
técnico utilizado é “replicadas”) para os demais DCs do domínio. Por isso se você cria uma conta para
o usuário jsilva e cadastra uma senha para este usuário, essa conta passa a ser válida em todo o domínio,
sendo que o usuário jsilva pode receber permissões para acessar recursos e serviços em qualquer servidor
do domínio, seja em um controlador de domínio ou em um servidor membro.
Por isso que o domínio nos transmite a idéia de um agrupamento lógico de Contas de Usuários e Grupos,
bem como de políticas de segurança, uma vez que todo o domínio compartilha a mesma lista de usuários,
a mesma lista de Grupos e as mesmas políticas de segurança. A criação de domínios facilita enormemente
a administração de uma rede baseada no Windows 2000 Server ou no Windows Server 2003, sendo
altamente recomendada para qualquer rede maior do que uma meia dúzia de máquinas.
Nos servidores membros podem ser criadas contas de usuários e grupos, as quais somente serão válidas
no Servidor Membro onde forem criadas. Estas contas e grupos são conhecidas como contas locais e
grupos locais, respectivamente. Embora isso seja possível, essa prática não é recomendada, uma vez que
isso dificulta enormemente a administração quando o número de usuários e grupos for grande. Você
pode atribuir permissões, para os recursos (pastas compartilhadas, impressoras compartilhadas, aplicativos,
etc.) de um servidor membro, a contas de usuários e grupos do domínio, sem a necessidade de criar esses
usuários ou grupos localmente. Com isso, podemos concluir que um servidor membro é um servidor
que, embora não mantenha uma cópia da lista de usuários e grupos, possui acesso a essa lista, sendo que
podem ser atribuídas permissões aos recursos do servidor membro para as contas e grupos do domínio.
Em um domínio, todos os controladores de domínio compartilham uma lista de usuários, grupos e políticas
de segurança, além de algumas outras características que veremos no tópico sobre o Active Directory. Além
disso, alterações feitas em um dos controladores de domínio são automaticamente replicadas para os demais.
Essa replicação, por padrão, ocorre de 5 em 5 minutos dentro da mesma rede local e de 3 em 3 horas através
de links de WAN, mais lentos, entre controladores de domínio de redes remotas.
Como os servidores membro não possuem uma cópia da lista de usuários e grupos do domínio, estes
não efetuam a autenticação dos clientes e também não armazenam informações sobre as políticas de
segurança para o Domínio, as quais também são conhecidas por GPOs – Group Policy Objects.
Quando os servidores Windows 2000 Server são configurados para trabalhar com um workgroup, não
existe o conceito de domínio e nem de controlador de domínio. Cada servidor mantém uma lista
separada para contas de usuários, grupos e políticas de Segurança. Com isso, se um usuário precisa
acessar recursos em três servidores, por exemplo, será necessário criar uma conta para esse usuário nos
três servidores diferentes. Um workgroup somente é recomendado para redes extremamente pequenas,
normalmente com um único servidor Windows 2000 Server ou Windows Server 2003 e não mais do
que dez estações clientes.
ACTIVE DIRECTORY
O Active Directory é, talvez, a mudança mais significativa incluída com o Windows 2000 Server e
também presente no Windows Server 2003. É também a novidade mais divulgada e comentada do
Windows 2000 Server.
Mas, de uma maneira simples, o que é o Active Directory?
O Active Directory é o serviço de diretórios do Windows 2000 Server e do Windows Server 2003. Um
serviço de diretórios é um serviço de rede, no qual estão armazenadas informações sobre todos os objetos
e serviços disponíveis na rede. Com o Active Directory podemos pesquisar todos os recursos disponíveis
em uma rede, e acessar estes recursos de acordo com as definições de segurança implementadas, ou seja,
o usuário somente tem acesso aos recursos para os quais tem permissão de acesso.
Pela descrição formal acima, podemos ver que o Active Directory é um serviço de rede, no qual ficam
armazenadas informações sobre dados dos usuários, impressoras, servidores, grupos de usuários,
computadores e políticas de segurança. Cada um desses elementos é conhecido como objetos.
Os recursos disponíveis através do Active Directory são organizados de maneira hierárquica, através do
uso de domínios. Uma rede, na qual o Active Directory está instalado, pode ser formada por um ou
mais domínios. Com a utilização do Active Directory um usuário somente precisa ser cadastrado em
um dos domínios, sendo que pode receber permissões para recursos em qualquer um dos domínios.
A utilização do Active Directory simplifica em muito a administração, pois fornece um local centralizado,
através do qual todos os recursos da rede podem ser administrados. Todos os controladores de domínio
possuem o Active Directory instalado. A maneira de criar um domínio é instalar o Active Directory em
um member server e informar que este é o primeiro controlador de domínio.
O Active Directory utiliza o DNS – Domain Name Systems – como o seu serviço de nomeação de
servidores e recursos. Por isso, um dos pré-requisitos para que o Active Directory possa ser instalado e
funcione perfeitamente é que o DNS esteja instalado e corretamente configurado.
Com o agrupamento de objetos em um ou mais domínios permito que a rede de computadores reflita
a organização lógica da sua empresa. Para que um usuário cadastrado em um domínio possa receber
permissões para acessar recursos em outros domínios, o Windows cria e mantém, automaticamente,
relações de confiança entre os diversos domínios. As relações de confiança são bidirecionais e transitivas.
Isso significa que, se o Domínio A confia no Domínio B, o qual por sua vez confia em um Domínio C,
então o Domínio A também confia no Domínio C. Isso é bastante diferente do que acontecia em
versões anteriores do Windows, tais como o NT Server 4.0, pois nas versões antigas as relações de
confiança tinham que ser criadas e mantidas pelos administradores dos domínios.
Todo domínio possui as seguintes características:
♦ Todos os objetos de uma rede (contas de usuários, grupos, impressoras, políticas de segurança,
etc.) existem em um domínio. Cada domínio somente armazena informações sobre os
objetos próprios.
♦ Cada domínio possui suas próprias políticas de segurança.
Quando temos diversos domínios se relacionando através de relações de confiança, criadas e mantidas
automaticamente pelo Active Directory, dizemos que temos uma Árvore. Uma árvore nada mais é do
que um agrupamento ou arranjo hierárquico de um ou mais domínios do Windows 2000 Server, os
quais “compartilham um espaço de nome”.
Vamos entender um pouco mais o que significa a expressão “compartilham um espaço de nome”.
Primeiramente observe a Figura 6.7.
Figura 6.7 Todos os domínios de uma árvore compartilham um espaço de nomes em comum.
Observe que, no diagrama anterior, temos uma árvore com sete domínios. Mas o que significa mesmo
“compartilhar um espaço de nome”?
Observe que o domínio inicial é microsoft.com. Os domínios seguintes são: vendas.microsoft.com e

suporte.microsoft.com. Quando formamos uma hierarquia de Domínios, compartilhar um espaço de
nomes significa que o nome do objeto filho contém o nome do objeto pai. Por exemplo,
vendas.microsoft.com contém microsoft.com. Descendo mais ainda na hierarquia, vemos que isso
continua verdadeiro. Por exemplo, o objeto filho sistemas.vendas.microsoft.com contém o nome do
objeto pai, vendas.microsoft.com.
Com isso dizemos que uma árvore de domínios deste tipo forma um espaço de nomes contínuo, onde
o nome do objeto filho sempre contém o nome do objeto pai.
Você pode ainda dividir um domínio em “Unidades Organizacionais”. Uma unidade organizacional é
um container, o qual podemos utilizar para organizar os objetos de um determinado domínio em um
agrupamento lógico para efeitos de administração. Isso resolve uma série de problemas de versões
anteriores do Windows. No Windows NT Server 4.0, se um usuário fosse adicionado ao grupo
Administradores (grupo com poderes totais sobre qualquer recurso, em qualquer servidor do domínio),
ele poderia tomar qualquer ação em qualquer servidor do domínio. Com a utilização de unidades
organizacionais, podemos atribuir poderes administrativos apenas na unidade organizacional, sem
que com isso o usuário tenha poderes sobre todo o domínio.
Cada domínio pode implementar a sua hierarquia de unidades organizacionais, independentemente

dos demais domínios, isto é, os diversos domínios que formam uma determinada árvore de domínios
não precisam ter a mesma estrutura hierárquica de unidades organizacionais.
No exemplo da Figura 6.7, exibida anteriormente, o domínio vendas.microsoft.com poderia ter

uma estrutura hierárquica de unidades organizacionais, projetada para atender as necessidades do
domínio vendas. Essa estrutura poderia ser completamente diferente da estrutura do domínio
suporte.microsoft.com, a qual será projetada para atender as necessidades do Domínio suporte.
Com isso ficamos com uma flexibilidade bastante grande, de tal forma que a nossa árvore de
domínios e a organização dentro de cada domínio, em uma hierarquia de unidades organizacionais,
possa atender perfeitamente às necessidades da empresa. A utilização de unidades organizacionais
não é obrigatória.
Utilize unidades organizacionais quando:
♦ Você quiser representar a estrutura e organização da sua companhia em um domínio. Sem a

utilização de unidades organizacionais, todas as contas de usuários são mantidas e exibidas em
uma única lista, independente da localização, departamento ou função do usuário.
♦ For necessário delegar tarefas administrativas sem que para isso tenhamos que dar poderes
sobre todo o domínio. Com o uso de unidades organizacionais, você pode dar permissões para
um usuário somente na unidade organizacional.
♦ Facilitar e melhor acomodar alterações na estrutura da sua companhia. Por exemplo, é muito
mais fácil mover contas de usuários entre unidades organizacionais do que entre domínios.
Os conceitos de domínio e controladores de domínio, bem como do Active Directory, são muito
importantes para o Windows 2000 Server e também para o Windows Server 2003.
CONTAS DE USUÁRIOS
Quando trabalhamos com uma rede de computadores, segurança é um dos itens de maior importância.
O administrador da rede deve ser capaz de permitir que cada usuário somente tenha acesso aos recursos
– sejam eles arquivos, impressoras ou serviços – os quais sejam necessários para a realização do seu
trabalho. Por exemplo, um usuário que trabalha no departamento de bagagem não deve ser capaz de
acessar informações sobre salários contidas nos arquivos de um servidor SQL Server 2005, do
departamento de Recursos Humanos.
No Windows 2000 Server e também no Windows Server 2003, podemos limitar os recursos aos quais
cada usuário tem acesso, através do uso de permissões. As permissões de acesso podem ser atribuídas
para um usuário individualmente, ou para um grupo de usuários. Para que possamos atribuir permissões,
cada usuário deve ser cadastrado no sistema. Cadastrar o usuário significa criar uma “Conta de Usuário”
para cada usuário. Com uma conta, o usuário pode efetuar o logon e receber permissões para acessar os
mais variados recursos disponibilizados na rede.
Uma conta pode ser criada em um controlador de domínio – situação em que a conta é válida e
reconhecida em todo o domínio; ou a conta pode ser criada em um servidor membro – situação em
que a conta somente é válida e reconhecida no servidor membro onde ela foi criada.
Contas criadas em um controlador de domínio são chamadas de “Domain User Accounts” (Contas de
Usuários do Domínio). Essas contas permitem que o usuário faça o logon em qualquer computador do
domínio e receba permissões para acessar recursos em qualquer computador do domínio. No decorrer
desta item, trabalharemos e criaremos contas em um domínio chamado GROZA, com um domínio
DNS chamado groza.com. Para criar contas em servidores membro, o procedimento é bastante
semelhante, apenas a quantidade de campos de informação de cada conta é um pouco menor.
Contas criadas em um servidor membro são chamadas de “Local User Accounts” (Contas de Usuários
Locais). Essas contas somente permitem que o usuário faça o logon e receba permissões para acessar
recursos do computador onde a conta foi criada. Sempre que possível evite criar contas locais em
servidores que fazem parte de um domínio. Utilizar as contas do domínio, as quais ficam armazenadas
no Active Directory, torna a administração bem mais fácil.
Outro detalhe que você deve observar é a utilização de um padrão para o nome das contas de usuários.
Isto é válido para contas do domínio como também para contas do SQL Server 2005, caso você esteja
utilizando o modo de segurança SQL Server and Windows Authentication mode.
Você deve estabelecer um padrão para a criação de nomes, pois não podemos ter dois usuários com o
mesmo nome de logon dentro da mesma unidade organizacional. Por exemplo se tivermos na mesma
unidade organizacional dois José da Silva e os dois resolverem utilizar como logon “jsilva”, não será
possível. Para isso é importante que seja definido um padrão e no caso de nomes iguais deve ser
definida uma maneira de diferenciá-los. Por exemplo, poderíamos usar como padrão a primeira letra
do nome e o último sobrenome. No caso de nomes iguais, acrescentam-se números. No nosso exemplo
o primeiro José da Silva cadastrado ficaria como jsilva, já o segundo a ser cadastrado ficaria como
jsilva1. Caso no futuro tivéssemos mais um José da Silva dentro da mesma unidade organizacional,
este seria o jsilva2 e assim por diante.
Quando formos criar nomes de logon para os usuários, devemos levar em consideração os seguintes fatos:
♦ Nomes de usuários do domínio devem ser únicos dentro do domínio.
♦ Podem ter no máximo 20 caracteres.
♦ Os seguintes caracteres não podem ser utilizados como parte do nome: “ / \: ; [ ] | = , + * ? < >
Sempre que você for cadastrar um usuário também deve ser cadastrada uma senha para o usuário. O
número máximo de caracteres da senha é 128, sendo recomendado usar senhas de, no mínimo, 8 caracteres.
NOTA
Para as senhas, o Windows 2000 Server distingue letras maiúsculas de minúsculas. Por exemplo a senha “Abc123” é diferente da senha
“abc123”.
Vamos praticar um pouco. Vamos criar algumas contas de usuários. Vamos utilizar estas contas para
atribuir permissões de acesso no SQL Server 2005, mais adiante, neste capítulo.
Exemplo prático: Criar as seguintes contas de usuários com as respectivas senhas:
Tabela 6.1 Contas de usuários do domínio GROZA.
Nome da conta Senha Nome completo
user1 senha123 Usuário1 da Silva

Para criar a conta para o usuário user1, siga os passos indicados a seguir:
1. Efetue o logon com uma conta com permissão de administrador.
2. Abra o console Usuários e Computadores do Active Directory (Iniciar -> Programas ->
Ferramentas administrativas -> Usuários e Computadores do Active Directory). Será inicializado
o console para “Gerenciamento do Active Directory”.
3. Dê um clique no sinal de ao lado de groza.com (provavelmente o nome do seu domínio seja

diferente, dê um clique no sinal de ao lado do nome do seu domínio). Abaixo de groza.com
surgem diversas opções.
NOTA
Se você não tiver acesso a um servidor com o Active Directory, você pode criar contas locais. Para isso use o console Gerenciamento do
Computador, o qual é acessado através da opção Ferramentas Administrativas, do Painel de controle.
4. Dê um clique na opção Users (ou usuários se o snap-in já estiver traduzido para o português).
No painel da direita é exibida uma listagem com o nome de todos os usuários já cadastrados,
Figura 6.8 Listagem com todos os usuários já cadastrados.
5. Dê um clique com o botão direito do mouse, na opção Users.
6. No menu que surge, aponte para a opção Novo -> Usuário (New – User).
7. Surge um assistente para ajudá-lo a criar um novo usuário. Digite as informações para criar o
usuário user1, conforme indicado na Figura 6.9.
Figura 6.9 Criando o usuário User1.
“Nome de logon do usuário” é o nome que o usuário utiliza para efetuar o logon em computadores com o Windows 2000 Server, Windows
NOTA
XP ou Windows Server 2003. Já “Nome de logon do usuário (anterior ao Windows 2000)” é o nome que o usuário utiliza para efetuar o
logon em computadores com versões mais antigas do Windows NT, tais como o Windows NT Server 4.0 ou Windows 98. Por simplicidade estes
dois nomes devem ser iguais; observe que à medida que você digitar o primeiro, o segundo será automaticamente preenchido.
À medida que você for digitando o Nome, Iniciais e Sobrenome, o Windows vai preenchendo o campo Nome completo. Caso você queira é
possível alterar o Nome completo, sem que isso provoque mudança nos demais campos.
8. Dê um clique no botão Avançar, seguindo para a próxima etapa.
9. Na próxima tela você deve digitar a senha do usuário duas vezes, para confirmação. Digite
senha123 nos campos Senha e Confirmar senha. Observe que, à medida que você digita a
senha, o Windows exibe apenas asteriscos (*) nos campos Senha e Confirmar senha.
Outras opções que podem ser configuradas nesta tela:
♦ O usuário deve alterar a senha no próximo logon: Se esta opção estiver marcada, na primeira
vez que o usuário fizer o logon será solicitado que o usuário altere a sua senha. Esta opção é
utilizada para que o usuário possa colocar uma senha que somente ele conhece, pois, quando
o usuário é cadastrado, a senha é digitada pelo administrador, o qual fica sabendo a senha do
usuário. No próximo logon o usuário altera a senha de tal maneira que somente ele saiba qual
a senha para a sua conta.
♦ O usuário não pode alterar a senha: Se esta opção estiver marcada, a senha somente poderá
ser alterada pelo administrador. Normalmente utilizada para empregados temporários e para
estagiários.
♦ A senha nunca expira: Independente das políticas de segurança do domínio, se esta opção estiver
marcada, o usuário nunca precisará trocar a sua senha. Caso contrário, de tempos em tempos
(conforme configurado nas políticas de segurança do domínio), o usuário deve trocá-la.
♦ A conta está desativada: O administrador marca esta opção para bloquear a conta de um
usuário. Usuários com a conta bloqueada não podem mais efetuar logon e, conseqüentemente,
não podem mais acessar nenhum recurso. Esta opção normalmente é utilizada para desativar,
temporariamente, a conta de empregados que estão em férias. Quando o empregado retorna
ao serviço, o administrador libera a sua conta, simplesmente desmarcando esta opção.
10. Certifique-se de que as quatro opções acima descritas estejam desmarcadas e dê um clique no
botão Avançar.
Surge uma tela informando que um novo objeto será criado. Lembre-se que todos os elementos do
Active Directory são chamados de objetos, conforme descrito anteriormente.
11. Dê um clique no botão Concluir. Após isso, o usuário Usuário1 da Silva já aparece na listagem
de usuários.
12. Repita os passos anteriores para criar as contas dos demais usuários indicados na Tabela 6.1.
13. Feche o console Usuários e Computadores do Active Directory.
Para testar se as contas foram criadas com sucesso, você pode fazer o logoff e fazer o logon utilizando uma das contas recém-criadas. Por
NOTA
padrão, para fazer o logon diretamente no servidor, a conta do usuário deve possuir o seguinte direito “Log on locally.” Se você não tiver
conseguindo fazer o logon com as contas recém-criadas, entre em contato com o administrador da rede para que ele dê este direito às contas
recém-criadas. Se você mesmo for o administrador da rede, melhor ainda.
GRUPOS DE USUÁRIOS E TIPOS DE GRUPOS EXISTENTES

NO WINDOWS 2000 SERVER E NO WINDOWS SERVER 2003
Agora vamos falar um pouco de teoria sobre grupos de usuários. Em seguida vamos praticar, criando
alguns grupos e adicionando alguns membros aos grupos criados.
Um grupo de usuários é uma coleção de contas de usuários. Por exemplo, podemos criar um grupo
chamado Contabilidade, do qual farão parte todos os usuários do departamento de Contabilidade.
A principal função dos grupos de usuários é facilitar a administração e a atribuição de permissões para
acesso a recursos, tais como: pastas compartilhadas, impressoras remotas, serviços diversos, etc. Ao
invés de darmos permissões individualmente, para cada um dos usuários que necessitam acessar um
determinado recurso, podemos criar um grupo e atribuir permissões para o grupo. Para que um usuário
tenha permissão ao recurso, basta incluí-lo no grupo que tem permissão de acesso ao recurso, pois
todos os usuários de um determinado grupo herdam as permissões dos grupos aos quais pertence.
Quando um usuário troca de seção, por exemplo, basta trocar o usuário de grupo. Vamos supor que o
usuário jsilva trabalha na seção de contabilidade e pertence ao grupo Contabilidade. Ao ser transferido
para a seção de marketing, basta movermos o usuário do grupo Contabilidade para o grupo Marketing.
Com isso, ele deixa de ter as permissões atribuídas ao grupo Contabilidade e passa a ter as mesmas
permissões que tem o grupo Marketing. Veja o quanto a utilização de grupos pode facilitar a atribuição
e o gerenciamento de permissões.
Podemos inclusive ter situações mais específicas. Vamos supor que exista um sistema chamado SEAT,
para o qual somente um número restrito de usuários deve ter acesso, sendo que são usuários de diferentes
seções. A maneira mais simples de gerenciar esta questão é criar um grupo chamado SEAT e dar permissões
para esse grupo. Assim cada usuário que precisar acessar o sistema SEAT deve ser incluído no grupo
SEAT. Quando o usuário não deva mais ter acesso ao sistema SEAT, basta removê-lo do grupo SEAT.
Na Figura 6.10 vemos uma ilustração para o conceito de grupo de usuários. O grupo Contabilidade
possui direito para um recurso compartilhado, o qual pode ser acessado através da rede. Todos os
usuários que pertencem ao grupo Contabilidade também possuem permissão para o recurso
compartilhado, uma vez que os usuários de um grupo herdam as permissões do grupo.
Figura 6.10 O usuário herda as permissões do grupo.
Quando estiver trabalhando com grupos de usuários, considere o seguinte:
♦ Grupo de usuários é uma coleção de contas de usuários.
♦ Os membros de um grupo herdam as permissões atribuídas ao grupo.
♦ Os usuários podem ser membros de vários grupos.
♦ Grupos podem ser membros de outros grupos.
Agora vamos dar uma olhada nos tipos de grupos existentes no Windows 2000 Server e também no
Podemos ter dois tipos de grupos: Grupos de segurança (Security groups) e Grupos de distribuição
(Distribution groups).
♦ Grupos de segurança: Utilizados para atribuir permissões de acesso a recursos da rede. Um

grupo de segurança também pode ser utilizado como um grupo de distribuição, embora essa
não seja uma situação muito comum. Esses grupos, assim como as contas de usuários, são
armazenados no Banco de Dados do Active Directory.
♦ Grupos de distribuição: São utilizados para funções não relacionadas com segurança. Uma
das utilizações típicas para um grupo de distribuição é o envio de mensagens de e-mail para
um grupo de usuários de uma só vez. Somente aplicativos que foram programados para trabalhar
com o Active Directory poderão utilizar grupos de distribuição. Provavelmente, as novas versões
dos principais sistemas de correio eletrônico estarão habilitadas para trabalhar com o Active
Directory. Não podemos utilizar grupos de distribuição para funções relacionadas com segurança.
Escopo de grupos de usuários:
Quando criamos um grupo de usuários, devemos selecionar um tipo e um escopo. O escopo permite
que o grupo seja utilizado em diferentes locais, para a atribuição de permissões. O escopo de um grupo
determina em que partes da rede poderemos usar o grupo para atribuir permissões para o grupo,
permissões estas que serão herdadas por todos os membros do grupo. Existem três escopos para grupos
de usuários, conforme descrito a seguir:
♦ Grupos globais (Global group):
♦ Somente pode conter membros do domínio no qual o grupo é criado.
♦ Pode receber permissões para recursos localizados em qualquer domínio.
♦ Grupos locais do domínio (Domain local group):
♦ Pode conter membros de qualquer domínio.
♦ Somente pode receber permissões para recursos do domínio no qual o grupo é criado.
♦ Grupos universais (Universal group):
♦ Pode conter membros de qualquer domínio.
♦ Pode receber permissões para recursos localizados em qualquer domínio.
O escopo de um grupo também determina quem pode ser membro do grupo. Tanto usuários como
outros grupos podem ser membros de um determinado grupo. Considere as regras a seguir:
♦ Grupo global:
♦ Pode conter: Contas de usuários e grupos globais do mesmo domínio.
♦ Pode ser membro de: Grupos universais e grupos locais do domínio em qualquer domínio
ou grupos globais no mesmo domínio.
♦ Grupo local do domínio:
♦ Pode conter: Contas de usuários, grupos universais e grupos globais de qualquer domínio
ou grupos locais do domínio do mesmo domínio.
♦ Pode ser membro de: Grupos locais no domínio do mesmo domínio.
♦ Grupo universal:
Pode conter: Contas de usuários, grupos universais e grupos globais de qualquer domínio.
Pode ser membro de: Grupos locais do domínio ou grupos universais de qualquer domínio.
Vamos aprender a criar grupos. Vamos criar os grupos indicados na Tabela 6.2.
Tabela 6.2 Grupos de Usuários.
Nome da conta Membros do grupo
Grupo1 user1, user2 e user3

Grupo2 user3, user4 e user5
Exemplo prático: Para criar os grupos Grupo1 e Grupo2, indicados na Tabela 6.2, faça o seguinte:
1. Efetue o logon como administrador ou com uma conta com permissão de administrador.
2. Abra o console Usuários e Computadores do Active Directory (Iniciar -> Programas ->
Ferramentas administrativas -> Usuários e Computadores do Active Directory). Será inicializado
o console para “Usuários e Computadores do Active Directory”.
3. Dê um clique no sinal de + ao lado de groza.com (provavelmente o nome do seu domínio seja

diferente; dê um clique no sinal de + ao lado do nome do seu domínio). Abaixo de groza.com
surgem diversas opções.
4. Dê um clique na opção Users (ou Usuários se o snap-in já estiver traduzido para o português).
No painel da direita é exibida uma listagem com o nome de todos os usuários e grupos do
domínio groza.com.
NOTA
Na prática, a opção Users nada mais é do que uma unidade organizacional, a qual pode conter contas de usuários e de grupos de usuários.
5. Dê um clique com o botão direito do mouse, na opção Users.
6. No menu que surge, aponte para a opção Novo -> Grupo (New –> Group).
7. Surge um assistente para ajudá-lo a criar um novo grupo. Digite as informações para criar o
grupo Grupo1, conforme indicado na Figura 6.11.
8. Dê um clique no botão OK para criar o grupo. Você estará de volta ao console “Usuários e
Computadores do Active Directory”.
Observe no painel da esquerda que já aparece o grupo chamado Grupo1. Neste momento o grupo está
criado, porém não temos nenhum usuário pertencente ao grupo. No próximo exemplo, aprenderemos
a adicionar usuários ao grupo.
Figura 6.11 Criando o grupo Grupo1.
9. Repita os passos de 5 a 8 para criar o grupo Grupo2.
10. Mantenha o console Usuários e Computadores do Active Directory aberto.
Agora temos que adicionar os usuários user1, user2 e user3 ao grupo Grupo1 e os usuários user3, user4
e user5 ao grupo Grupo2. Observe que o usuário user3 pertence aos dois grupos.
Exemplo prático: Para adicionar os usuários aos respectivos grupos, conforme indicado na Tabela 6.2,
siga os passos indicados a seguir:
1. Você deve estar com o console Usuários e Computadores do Active Directory aberto. Se não
estiver, abra-o e navegue até a opção Users.
2. No painel da direita, localize Grupo1 e dê um clique duplo para abrir as propriedades do grupo.
Surge a janela indicada na Figura 6.12, onde a guia Geral vem selecionada por padrão. Preencha
os campos Descrição e Comentários, conforme indicado na figura.
3. Dê um clique na guia Membros. Vamos utilizar esta guia para adicionar os usuários user1,
user2 e user3 como membros de Grupo1. Observe que a guia Membros ainda não possui nenhum
usuário adicionado.
4. Para adicionar usuários ao grupo, dê um clique no botão Adicionar. Surge a janela “Selecione
Usuários, Contatos ou Computadores”, conforme indicado na Figura 6.13. Nesta janela é exibida
uma listagem com todos os usuários cadastrados no domínio.
Figura 6.12 Alterando as propriedades do Grupo1.
Figura 6.13 Lista de usuários, contatos e computadores do domínio.
5. Para adicionar o usuário user1 (Usuário1 da Silva) localize-o na listagem, dê um clique sobre
ele para marcá-lo e depois dê um clique no botão Adicionar. Você também pode dar um clique
duplo sobre o nome do usuário, pois este será adicionado diretamente.
6. Repita a operação do passo anterior, para os usuários user2 (Usuário2 da Silva) e user3 (Usuário3
da Silva).
7. Dê um clique no botão OK para fechar essa janela e voltar à guia Membros.
8. Sua janela deve estar conforme indicado na Figura 6.14, a qual indica que os usuários Usuário1
da Silva (user1), Usuário2 da Silva (user2) e Usuário3 da Silva (user3) foram adicionados como
membros do grupo Grupo1.
Figura 6.14 Três usuários adicionados como membros do grupo Grupo1.
9. Dê um clique em OK para fechar a janela de propriedades do grupo Grupo1.
10. Repita as operações anteriores para adicionar os usuários user3, user4 e user5 ao grupo Grupo2.
11. Feche o console Usuários e Computadores do Active Directory.
A partir deste momento, qualquer permissão que for atribuída ao grupo Grupo1 será herdada por
todos os membros deste grupo. No nosso exemplo, pelos usuários user1, user2 e user3.
Existem algumas contas de usuário que são criadas no momento em que o Windows é instalado. Essas contas são conhecidas como “Built-in
NOTA
Accounts”. A mais importante delas é a conta Administrador (Administrator na versão em inglês). Essa conta tem poderes totais sobre o domínio,
não tendo nenhuma restrição de segurança. Muito cuidado com quem vai usar essa conta em um ambiente de produção. Precisa ser uma pessoa
qualificada e que sabe o que está fazendo. A conta Administrador pode ser renomeada, porém não pode ser excluída nem bloqueada.
Outra conta que é criada quando da instalação do Windows 2000 Server é a conta de usuário
“Convidado” (Guest). Esta conta, normalmente, é utilizada para acesso de usuários que não possuem
uma conta cadastrada no domínio. Por padrão esta conta está desabilitada. O administrador pode
habilitar a conta Convidado. Porém isso deve ser feito com cuidado. Sempre que um usuário precise
acessar algum recurso, o ideal é cadastrar o usuário e incluir o usuário no grupo (ou grupos), que tem
permissão para acessar os recursos necessários.
Existem também alguns grupos criados durante a instalação do Windows, são os chamados “Built-in
Groups”. O mais importante de todos é o grupo Administradores. Todo membro deste grupo tem plenos
poderes no domínio. No console “Usuários e Computadores do Active Directory (Iniciar -> Programas ->
Ferramentas administrativas -> Usuários e Computadores do Active Directory), existe uma opção chamada
Built-in. Ao clicar nessa opção será exibida uma listagem com diversos grupos criados durante a instalação
do Windows. Observe na coluna tipo que o tipo destes grupos é “Grupo de segurança – local interno” e
na coluna descrição podemos ver um resumo das permissões de cada um dos grupos.
Exercício: Com os conhecimentos apresentados neste item, crie os usuários e grupos indicados na
Tabelas 6.3 e 6.4, respectivamente. Utilizaremos estes usuários e grupos nos demais itens deste capítulo.
Tabela 6.3 Criando mais contas de usuários no domínio groza.com.
Nome da conta Senha Nome completo
user6 senha123 User6 da Silva

jose senha123 José da Silva
maria senha123 Maria da Silva
pedro senha123 Pedro da Silva
paulo senha123 Paulo da Silva
jovina senha123 Jovina da Silva
Tabela 6.4 Criando mais grupos de usuários no domínio groza.com.
Nome do grupo Membros do grupo
Consulta user3, user6, jose, maria

Alteração user3, user7, pedro e paulo
Dbas paulo, user8 e jovina
Exclusão user3, jose
Com isso tivemos uma noção geral sobre usuários e grupos no Windows. Agora podemos fechar o
nosso parênteses sobre segurança no Windows 2000 Server e Windows Server 2003 e voltar à segurança
no SQL Server 2005.
KNOW-HOW EM: CRIAÇÃO E GERENCIAMENTO

DE LOGIN E ROLES NO SQL SERVER 2005
PRÉ-REQUISITOS
♦ Noções básicas sobre o modelo de segurança do SQL Server 2005.
♦ Noções básicas sobre o modelo de segurança do Windows 2000 Server e Windows Server 2003.
METODOLOGIA
♦ Apresentação dos comandos necessários para a criação e gerenciamento de logins e roles.
TÉCNICA
♦ Criação de logins e roles nos Bancos de Dados criados nos capítulos anteriores, utilizando o SQL Server Management Studio e a janela de
execução de comandos T-SQL.
A partir de agora aprenderemos a adicionar logins e roles em instâncias do SQL Server 2005. Não me
canso de repetir e salientar: role é apenas um novo nome que inventaram para grupos de usuários.
Uma role é um grupo de usuários no SQL Server 2005.
Vamos fazer uma rápida apresentação do servidor e das configurações que vou utilizar para os exemplos
deste tópico e do restante do capítulo. Estou trabalhando em um servidor com o Windows 2000 Server
instalado. Este servidor não tem o Active Directory instalado. O nome deste servidor é SERVIDOR.
Nele temos duas instâncias do SQL Server 2005 instaladas, que são as seguintes:
♦ SERVIDOR\SQL2005
♦ SERVIDOR\CURSOSJB
Utilizando as instruções do início do capítulo, certifique-se de que as instâncias estão utilizando os

modos de segurança indicados na Tabela 6.5.
Tabela 6.5 Cada instância em um modo de segurança diferente.
Instância Modo de segurança
SERVIDOR\SQL2005 Windows Authentication mode

SERVIDOR\CURSOSJB SQL Server and Windows Authentication mode
Na instância SERVIDOR\SQL2005 somente poderemos adicionar logins do Windows, pois esta instância
está no modo de segurança Windows Authentication mode. Já na instância SERVIDOR\CURSOSJB,
poderemos adicionar logins do Windows e também do SQL Server 2005, pois estamos no modo de
segurança SQL Server and Windows Authentication mode.
Utilizarei os termos logins e users com significados diferentes. Adicionar um login significa dar permissão a um usuário para que o usuário
NOTA
faça a conexão com o Servidor SQL Server 2005. Adicionar um user significa pegar um dos usuários com permissão de conexão (isto é, um
dos logins) ao Servidor SQL Server e dar permissão de acesso a um schema ou a um Banco de Dados. Então resumidamente: um login dá
permissão de conexão com o servidor SQL Server 2005, e user dá permissão de acesso a um ou mais Bancos de Dados. Na prática estes são
os termos utilizados pelo SQL Server 2005. No SQL Server Management Studio, nas opções de cada instância, temos uma opção Security.
Dentro da opção Security temos uma opção Logins, que é onde iremos adicionar os usuários com permissão de login. Já dentro de cada Banco
de Dados temos uma opção Security -> Users, que é onde adicionaremos os usuários com permissão de acesso ao Banco de Dados. Na Figura
6.15 podemos ver estas duas opções.
Figura 6.15 Logins para a instância, users para o Banco de Dados.
Seguindo a nossa metodologia, vamos aprender a adicionar usuários utilizando SQL Server Manage-
ment Studio e comandos T-SQL.
Parece um trabalho enorme, mas veremos que é extremamente simples. Juro que este exemplo dá mais
trabalho para elaborar do que para executar.
CRIANDO LOGINS COM O SQL SERVER MANAGEMENT STUDIO

Vamos aprender a criar logins utilizando o SQL Server Management Studio.
Utilizaremos o SQL Server Management Studio para adicionar os logins da Tabela 6.6. Adicionaremos
estes logins à instância SERVIDOR\SQL2005, a qual está no modo Windows Authentication mode.
Neste exemplo, as contas user1, user2, user3, user4, user5, grupo1 e o grupo grupo2 já devem existir no
Windows. Caso estas contas não existam, você deverá criá-las, previamente. Isso é válido tanto para
contas de um domínio baseado no Active Directory, quanto para contas locais, criadas em um servidor
que não faz parte de um domínio, ou que faz parte de um domínio mas não é um DC.
Tabela 6.6 Logins a serem adicionados a SERVIDOR\SQL2005.
Nome da conta Tipo Já existe? É?
user1 Windows Sim Usuário

grupo1 Windows Sim grupo
Exemplo prático: Para adicionar os logins da Tabela 6.6, faça o seguinte:
2. Na janela Object Explorer, dê um clique no sinal de + ao lado da instância SERVIDOR\SQL2005

para expandi-la.
3. Nas opções que surgem abaixo desta instância, clique no sinal de + ao lado da opção Security,
para expandi-la.
Abaixo de Security existe uma opção Logins, a qual utilizaremos para adicionar logins à instância
SERVIDOR\SQL2005. Neste caso, como a instância SERVIDOR\SQL2005 está no modo de segurança
Windows Authentication mode, somente poderemos adicionar como logins desta instância contas de
usuários ou grupos do Windows, quer sejam contas do Active Directory (se você tiver uma rede baseada
no Active Directory, com um domínio criado), quer sejam contas locais. Adicionaremos as contas
indicadas na Tabela 6.6.
4. Clique no sinal de + ao lado da opção Logins. Observa que, por padrão, já são adicionados
alguns logins. A conta sa, que é a conta de administrador do próprio SQL Server 2005, a conta
administrador do domínio ou Administrador local (para computadores que não fazem parte
do domínio), o grupo Administradores e assim por diante.
5. Dê um clique com o botão direito do mouse na opção Logins. No menu de opções que surge, dê
um clique na opção New Login. Surge a janela para adição de um novo login, com a guia General
selecionada, por padrão. Observe que a opção Windows authentication já vem selecionada.
6. No campo Login name, podemos digitar o nome do login. Quando estamos adicionando
usuários ou grupos de um domínio, devemos utilizar a nomenclatura DOMINIO\nome_usuário.
Por exemplo, para adicionar o usuário jsilva do domínio ABC, digite ABC\jsilva para adicionar
o grupo Contabilidade, do domínio XYZ, digite XYZ\Contabilidade. Para adicionar usuários e
grupos locais, para o caso de servidores que não façam parte de um domínio, você usa uma
nomenclatura semelhante. Neste caso você usa: NOME_DO_SERVIDOR\Nome_do_usuário ou
NOME_DO_SERVIDOR\Nome_do_grupo. Para este exemplo, estou utilizando as contas locais
de um servidor cujo nome é SERVIDOR. Por exemplo, a conta jsilva será SERVIDOR\jsilva, o
grupo grupo1 será SERVIDOR\grupo1 e assim por diante. Você também pode clicar no botão
Search. para abrir uma janela que exibe a lista de usuários e grupos disponíveis e selecionar os
usuários e/ou grupos, clicando diretamente neles.
7. Para adicionar o usuário user1 do servidor chamado SERVIDOR, digite SERVIDOR\user1. Você
também pode utilizar o botão Search. para obter uma lista de usuários e grupos, conforme
exemplo indicado na Figura 6.16.
Figura 6.16 Lista de usuários e grupos do servidor.
8. Clique no botão Search. para exibir a listagem de usuáros e grupos. Na listagem de usuários e
grupos, localize o usuário user1 e dê um clique duplo para adicioná-lo à parte de baixo da
janela. Dê um clique no botão OK e você estará de volta à janela Login - New, com o campo
Login Name já preenchido com SERVIDOT\user1, conforme indicado na Figura 6.17.
Figura 6.17 Adicionando o usuário SERVIDOR\user1.

NOTA
Uma limitação é que somente podemos adicionar um login por vez. Não podemos selecionar diversos usuários ou grupos e adicionar todos
de uma só vez.
9. Observe que podemos permitir o acesso ao servidor (Grant Server access) ou negar o acesso
para o usuário e/ou grupo que está sendo adicionado (Deny Server access). Certifique-se de que
a opção Grant server access esteja selecionada.
Na lista Database (na parte de baixo da janela) podemos selecionar qual Banco de Dados será, por
padrão, associado ao usuário que está recebendo permissão de login no SQL Server 2005:
SERVIDOR\user1, quando o usuário conectar-se com a instância SERVIDOR\SQL2005. O Banco de
Dados padrão é aquele em que os comandos do usuário terão efeito, a menos que seja utilizado um
comando USE nome_de_outro_banco_dados, para acessar outro Banco de Dados. A simples associação
com um Banco de Dados padrão não garante o direito de acesso aos objetos deste Banco de Dados para
isso o login que está sendo adicionado terá que ser inserido na lista de usuários autorizados do Banco
de Dados. Aprenderemos a fazer isso mais adiante, em um dos próximos itens.
10. No nosso exemplo, vamos associar todos os usuários com o Banco de Dados AdventureWorks.
Na lista Database, selecione o Banco de Dados AdventureWorks.
Na guia Server Roles, podemos fazer com que o login que está sendo adicionado pertença a uma ou
mais roles predefinidas no servidor SQL Server 2005. Uma role tem função semelhante à função de um
grupo de usuários do Windows e, no SQL Server 2005, pode conter um ou mais logins. As roles
predefinidas possuem uma série de permissões associadas a cada uma delas. Se adicionarmos um login
a uma role, o login herdará as permissões e direitos da role. Por exemplo, se adicionarmos um login a
role sysadmin, daremos poderes totais sobre todos os objetos de todos os Bancos de Dados da instância,
a este login. Isto porque a role sysadmin tem poderes totais e, ao ser adicionada a role, o login herda
estes poderes. Na Tabela 6.7, descrevo as permissões associadas com as principais roles predefinidas no
SQL Server 2005.
Tabela 6.7 Permissões associadas com as principais roles predefinidas.
Nome da role Permissões
sysadmin Poderes totais sobre todos os objetos da instância.

securityadmin Pode gerenciar logins do servidor.
serveradmin Pode configurar a maioria das opções do servidor.
diskadmin Gerenciar os arquivos de um Banco de Dados.
dbcreator Criar e alterar Bancos de Dados.
11. Como nosso usuário não precisa de permissões tão avançadas, não iremos adicioná-lo a
nenhuma role predefinida.
12. Na guia Database Access, poderíamos habilitar o acesso do login que está sendo adicionado, a
um ou mais Bancos de Dados. Não faremos isso agora. Na guia Permissions, poderíamos definir
permissões de acesso para o login que está sendo adicionado, a um ou mais objetos dos Bancos
de Dados da instância. Aprenderemos a fazer isso nos próximos itens. Vamos nos manter no
foco deste exemplo, que é mostrar como adicionar logins a uma instância do SQL Server 2005.
13. Dê um clique no botão OK e pronto, o login SERVIDOR\user1 será adicionado à instância

SERVIDOR\SQL2005. Será exibida uma mensagem informando que o login que está sendo
adicionado – SERVIDOR\user1 não possui permissão de acesso ao Banco de Dados definido
como padrão – que é o Banco de Dados AdventureWorks. Isso ocorre porque ainda não demos
permissões de acesso para o login SERVIDOR\user1, aos objetos do Banco de Dados
AdventureWorks. Aprenderemos a fazer isso nos próximos tópicos deste capítulo. Clique em
OK para fechar a mensagem com o aviso e adicionar o login assim mesmo.
14. Repita os passos que você aprendeu neste exemplo, para adicionar os demais logins indicados
na Tabela 6.6. Ao final, a sua janela deverá estar conforme indicado na Figura 6.18.
Conforme podemos constatar, adicionar logins a uma instância do SQL Server 2005 é uma tarefa
bastante simples. Aliás como é simples a maioria das tarefas administrativas com o SQL Server 2005,
desde que a teoria seja bem conhecida e entendida.
Figura 6.18 Diversos logins já adicionados.
CRIANDO LOGINS COM COMANDOS T-SQL

Vamos aprender a criar logins utilizando comandos T-SQL, na janela de execução de comandos do SQL
Server Management Studio.
Utilizaremos comandos T-SQL para adicionar os logins da Tabela 6.8. Adicionaremos estes logins à
instância SERVIDOR\SQL2005, a qual está no modo de autenticação SQL Server and Windows Au-
thentication mode (caso você não lembre como alterar o modo de autenticação de uma instância do
SQL Server 2005, volte ao início do capítulo e revise o tópico sobre alteração do modo de autenticação.
Depois, altere o modo de autenticação da instância SERVIDOR\SQL2005, para SQL Server and Win-
dows Authentication mode). Para senha dos usuários do próprio SQL Server, isto é, usuários que não
são de um domínio do Windows ou contas locais de um servidor Windows, utilizaremos a senha
“senha123” e como Banco de Dados padrão o Banco de Dados AdventureWorks.
Tabela 6.8 Logins a serem adicionados à instância SERVIDOR\SQL2005.
jose Windows Sim Usuário

maria Windows Sim Usuário
pedro Windows Sim Usuário
paulo Windows Sim Usuário
jovina Windows Sim Usuário
sqluser1 SQL Server Não Usuário
Ao adicionarmos logins, temos que considerar os dois modos de segurança: Windows Authentication
mode e SQL Server and Windows Authentication mode. No caso de estarmos adicionando permissão
de login a um usuário ou grupo do Windows, utilizamos o comando sp_grantlogin. Com este comando
garantimos a um usuário ou grupo já existente no Windows o direito de login no servidor SQL Server
2005. Para o modo de autenticação SQL Server and Windows Authentication mode, em que podemos
criar novos logins no próprio SQL Server, utilizamos o comando sp_addlogin. Na Tabela 6.9 temos um
resumo destes comandos.
Tabela 6.9 Comandos para adicionar logins.
Comando Utilizado
sp_grantlogin Para adicionar logins do domínio do Windows 2000. Podemos adicionar usuários ou grupos. Utilizamos
o formato DOMÍNIO\nome ou SERVIDOR\nome.
sp_addlogin Para adicionar novos logins do SQL Server 2005, para o caso de estarmos utilizando o modo de
segurança SQL Server and Windows Authentication mode.
Sintaxe para o comando sp_grantlogin:
exec sp_grantlogin ‘DOMÍNIO\nome’
ou
exec sp_grantlogin [DOMÍNIO\nome]
ou
exec sp_grantlogin ‘NOME_DO_SERVIDOR\nome’
Por exemplo, para adicionarmos o usuário chico, do domínio GROZA, utilizamos o seguinte comando:
exec sp_grantlogin ‘GROZA\chico’
ou
exec sp_grantlogin [GROZA\chico]
Algumas observações sobre o comando sp_grantlogin:
♦ sp_grantlogin não pode ser executado como parte de uma transação definida pelo usuário ou
por um aplicativo que o usuário está utilizando.
♦ Somente membros das roles System Administrators (sysadmin) e Security Administrators
(securityadmin) têm permissão, por padrão, para utilizar o comando sp_grantlogin.
Para o nosso exemplo, descrito na Tabela 6.8, utilizaremos o comando sp_grantlogin para adicionar os
usuários: jose, maria, pedro, paulo, jovina, grupo1 e grupo2.
Podemos remover a permissão de login para um usuário ou grupo do Windows, utilizando o comando
sp_revokelogin.
Sintaxe para o comando sp_revokelogin:
exec sp_revokelogin ‘DOMÍNIO\nome’
ou
exec sp_revokelogin [DOMÍNIO\nome]
ou
exec sp_revokelogin ‘Nome_Do_Servidor\nome’
Por exemplo, para removermos a permissão de login do usuário chico, do domínio GROZA, utilizamos
o seguinte comando:
exec sp_revokelogin ‘GROZA\chico’
ou
exec sp_revokelogin [GROZA\chico]
Algumas observações sobre o comando sp_revokelogin:
♦ Ao removermos a permissão de login, o usuário não poderá mais conectar-se com o servidor
SQL, a menos que um dos grupos aos quais o usuário pertença tenha permissão de login.
Lembre que o usuário sempre herda as permissões do grupo. Se o usuário pertencer a vários
grupos que possuem permissão de login e a um único grupo que tem o login explicitamente
negado, o usuário não poderá conectar-se com o servidor SQL. Lembre que negar (deny) sempre
tem precedência sobre permitir.
(securityadmin) têm permissão, por padrão, para utilizar o comando sp_revokelogin.
Podemos negar, explicitamente, a permissão de login para um usuário ou grupo do Windows, utilizando
o comando sp_denylogin. Neste caso, a conta do usuário ou grupo continua na lista de logins, porém
com o direito de conexão com o servidor SQL, explicitamente negado.
Sintaxe para o comando sp_denylogin:
exec sp_denylogin ‘DOMÍNIO\nome’
ou
exec sp_denylogin [DOMÍNIO\nome]
ou
exec sp_denylogin ‘Nome_Do_Servidor\nome’
Por exemplo, para negarmos, explicitamente, a permissão de login do usuário chico, do domínio
GROZA, utilizamos o seguinte comando:
exec sp_denylogin ‘GROZA\chico’
ou
exec sp_denylogin [GROZA\chico]
Algumas observações sobre o comando sp_denylogin:
♦ sp_denylogin não pode ser executado como parte de uma transação definida pelo usuário ou
(securityadmin) têm permissão, por padrão, para utilizar o comando sp_denylogin.
♦ Para permitir que o usuário volte a se conectar, removendo o efeito de sp_denylogin, podemos
utilizar sp_grantlogin.
Agora vamos tratar dos comandos para adicionar e remover logins do próprio SQL Server, os quais
podem ser utilizados, quando a instância do SQL Server 2005 estiver configurada para o modo de
autenticação SQL Server and Windows Authentication mode.
Para adicionar um login do SQL Server 2005, podemos utilizar o comando sp_addlogin.
Sintaxe para o comando sp_addlogin, conforme descrito no Books OnLine:

sp_addlogin [ @loginame = ] ‘login’
[ , [ @passwd = ] ‘password’ ]
[ , [ @defdb = ] ‘database’ ]
[ , [ @deflanguage = ] ‘language’ ]
[ , [ @sid = ] sid ]
[ , [ @encryptopt = ] ‘encryption_option’ ]
Observe que podemos definir uma série de opções, tais como a senha (passwd), o Banco de Dados
associado com o login (defdb), a linguagem associada com o login (deflanguage), um identificador de
segurança único (sid) e a definição se a senha deve ou não ser criptografada ao ser armazenada no
servidor SQL Server (encryptopt). Normalmente não especificamos o parâmetro sid, e com isso o
identificador único de segurança será gerado pelo próprio SQL Server 2005, no momento da criação do
login. O sid é um número do tipo varbinary(16). Os valores possíveis para o parâmetro encryptopt
estão descritos na Tabela 6.10.
Tabela 6.10 Valores do parâmetro encryptopt.
Valor Descrição
NULL A senha será criptografada. Este é o valor padrão.

skip_encryption A senha já está criptografada. O valor será gravado sem a necessidade de criptografá-lo novamente.
skip_encryption_old A senha deve ser criptografada de acordo com versões anteriores do SQL Server. O valor será gravado
sem criptografá-lo novamente. Esta opção normalmente é utilizada durante a fase de migração de
versões anteriores.
Por exemplo, para adicionarmos o usuário flavio1, com senha em branco e associado ao Banco de
Dados master, que é o Banco de Dados padrão, quando nenhum outro for definido, utilizamos o
seguinte comando:
exec sp_addlogin ‘flavio1’
Ao executar o comando anterior, você receberá uma mensagem de erro, informando que a senha não atende os requisitos de complexidade.
NOTA
Aqui temos uma demonstração de como o SQL Server 2005 foi projetado, tendo a segurança como uma das principais diretivas. Por padrão,
não é possível adicionar um login com senha em branco (o que era possível nas versões anteriores do SQL Server, inclusive para a conta sa,
a qual podia ter uma senha em branco). Como não usei a opção @passwd, a senha é definida como em branco, o que não é aceito pelas
políticas padrão de segurança do SQL Server 2005.
Agora vamos adicionar um usuário chamado luciano, com uma senha nene e associado ao Banco de
Dados Clientes:
exec sp_addlogin ‘luciano’, ‘nene’, ‘Clientes’
Algumas observações sobre o comando sp_addlogin:
♦ sp_addlogin não pode ser executado como parte de uma transação definida pelo usuário ou

(securityadmin) têm permissão, por padrão, para utilizar o comando sp_addlogin.
Para o nosso exemplo, descrito na Tabela 6.8, utilizaremos o comando sp_addlogin, para adicionar os
usuários: sqluser1 e sqluser2.
Para excluirmos um login do SQL Server, podemos utilizar o comando sp_droplogin.
Sintaxe para o comando sp_droplogin.:
exec sp_droplogin. ‘nome’
Por exemplo, para excluirmos o usuário luciano, podemos utilizar o seguinte comando:
exec sp_droplogin. ‘luciano’
Algumas observações sobre o comando sp_droplogin.:

(securityadmin) têm permissão, por padrão, para utilizar o comando sp_droplogin.
♦ Caso o login que está sendo excluído esteja adicionado como usuário de algum Banco de
Dados, o login não poderá ser excluído. Primeiro precisamos remover o login da lista de usuários,
utilizando o comando sp_drpouser, o qual aprenderemos a utilizar mais adiante.
♦ Os seguintes logins não poderão ser excluídos:
1. O login de administração sa.
2. Um login que esteja atualmente conectado com o servidor SQL Server.
♦ O comando sp_droplogin deverá checar todos os Bancos de Dados para verificar se o login
que está sendo excluído não está adicionado à lista de usuários com permissão de acesso ao
Banco de Dados. Por isso, para que este comando possa ser executado com sucesso, as seguintes
condições devem ser atendidas:
1. O usuário logado, que está executando sp_droplogin, deve ter permissão de acesso aos Bancos
de Dados; ou;
2. A conta guest deve estar habilitada a acessar o Banco de Dados.
Ao criarmos novos logins no SQL Server, devemos levar os seguintes fatos em consideração:
1. Um login não pode conter o caractere de barra invertida \ como parte do nome. Não confundir
com a barra invertida utilizada para separar o nome do domínio do nome do usuário.
2. Logins e senhas podem conter até 128 caracteres, incluindo letras, símbolos e dígitos.
3. Não podemos adicionar um login com o mesmo nome de um login reservado, como por exemplo
sa ou public.
4. O nome de login não pode conter o valor NULL ou ser uma string vazia ‘ ‘.
Agora que já aprendemos os diversos comandos envolvidos com logins, podemos criar os logins
indicados na Tabela 6.8. Lembrando que estes logins serão criados na instância SERVIDOR\SQL2005.
Exemplo prático: Para criar os logins indicados na Tabela 6.8, siga os passos indicados a seguir (no
exemplo a seguir, criarei os logins na instância SERVIDOR\SQL2005. Substitua este nome pelo nome
da instância que você estiver utilizando, para acompanhar este exemplo):
1. Se você não estiver com o SQL Server Management Studio, abra-o.
2. Na janela Object Explorer, localize a instância SERVIDOR\SQL2005 e dê um clique no sinal de

+, ao lado da instância, para exibir as opções disponíveis.

que é exibido, clique em New Query.
Será aberta a janela para execução de comandos T-SQL, a qual você já utilizou diversas vezes neste livro.
4. Para criar os logins indicados na Tabela 6.8, digite os seguintes comandos:

— Utilizo sp_grantlogin para adicionar
— usuários do Windows
exec sp_grantlogin ‘SERVIDOR\jose’

exec sp_grantlogin ‘SERVIDOR \maria’
exec sp_grantlogin ‘SERVIDOR \pedro’
exec sp_grantlogin ‘SERVIDOR \paulo’
exec sp_grantlogin ‘SERVIDOR \jovina’
exec sp_grantlogin ‘SERVIDOR \grupo1’
exec sp_grantlogin ‘SERVIDOR \grupo2’
— Agora utilizo sp_addlogin para adicionar

— logins do SQL Server 2005
exec sp_addlogin ‘sqluser1’, ‘senha123’, ‘AdventureWorks

exec sp_addlogin ‘sqluser2’, ‘senha123’, ‘AdventureWorks’
5. Pressione Ctrl+E para executar o comando.
6. O comando é executado com sucesso e a seguinte mensagem é exibida:

7. Agora vamos alterar o Banco de Dados padrão para os usuários do Windows. Lembrando que,
como não foi definido o Banco de Dados padrão, é utilizado como padrão o Banco de Dados
master. Para alterá-lo, utilizamos o comando sp_defautldb, com a seguinte sintaxe:
exec sp_defaultdb ‘usuário’, ‘Banco de Dados’
8. Para alterar o Banco de Dados padrão para os usuários do Windows, utilize os seguintes
comandos:
exec sp_defaultdb ‘SERVIDOR\jose’, ‘AdventureWorks’
exec sp_defaultdb ‘SERVIDOR\maria’, ‘AdventureWorks’
exec sp_defaultdb ‘SERVIDOR\pedro’, ‘AdventureWorks’
exec sp_defaultdb ‘SERVIDOR\paulo’, ‘AdventureWorks’
exec sp_defaultdb ‘SERVIDOR\jovina’, ‘AdventureWorks’
9. Pressione Ctrl+E para executar o comando.
10.O comando é executado com sucesso e a seguinte mensagem é exibida:

11. Pronto, os logins da Tabela 6.8 foram adicionados e o Banco de Dados padrão alterado para o
Banco de Dados AdventureWorks.
12. Feche a janela de execução de comandos T-SQL. Surge uma mensagem perguntando se você
deseja salvar os comandos digitados. Dê um clique em No.
Exercício: Usando os conhecimentos apresentados neste tópico, crie os logins indicados na Tabela
6.11. É importante que você faça este exercício, pois utilizaremos estes logins nos demais exemplos
deste capítulo.
Tabela 6.11 Logins a serem adicionados.

CRIANDO ROLES NO SQL SERVER 2005

Conforme já descrevemos, podemos utilizar roles para simplificar a atribuição de permissões de acesso
aos objetos do SQL Server 2005. Também nunca é demais salientar que role é semelhante, para não
dizer idêntico, ao conceito de grupos de usuários do Windows.
Por exemplo, podemos criar uma role chamada FinançasConsulta e outra chamada FinançasAlteração.
No Banco de Dados Finanças damos permissão somente de leitura para a role FinançasConsulta e de
leitura, escrita, alteração e exclusão para a role FinançasAlteração. Depois incluímos os usuários que
precisam de acesso somente de leitura na role FinançasConsulta, e os que precisam de acesso de leitura
e alteração, incluímos na role FinançasAlteração. Se um usuário não deve mais ter acesso de alteração,
é só retirá-lo da role FinançasAlteração. Com isso a administração da segurança no SQL Server 2005
fica bastante simplificada.
É também importante salientar as mudanças e novidades do SQL Server 2005, na área de segurança, já
descritas anteriormente. A principal mudança é a separação entre usuários e schemas. No SQL Server
2005, todos os objetos de um Banco de Dados, tais como tabelas e views, pertencem a um schema.
Agora, um usuário ou rule é o dono de um schema e não existe mais o dono de um determinado
objeto. Conforme descrito anteriormente, esta separação entre usuários e schemas facilita, bastante, a
administração, principalmente em casos onde temos que alterar o dono de um determinado objeto ou
excluir um usuário, o que era bem complicado de se fazer no SQL Server 2000. Para mais detalhes sobre
schemas e a questão do dono dos objetos, consulte o tópico teórico, no início do capítulo, sobre o
modelo de segurança do SQL Server 2005.
Existem algumas roles que já são criadas no momento de instalação de uma determinada instância do
SQL Server 2005. Temos as chamadas Server Roles e as Databases Roles. A seguir, temos as permissões
associadas com cada uma destas roles.
As server roles têm permissão para realizar as tarefas administrativas mais comuns. Por exemplo, se um
usuário é responsável por adicionar ou remover logins, você pode colocá-lo como membro da role
securityadmin, e este usuário herdará as permissões da role securityadmin. Isto evita que você tenha
que adicioná-lo à role Sysadmin, dando-lhe mais permissões do que realmente necessita para realizar
o seu trabalho. Na Tabela 6.12, temos a descrição destas roles.
Tabela 6.12 Permissões associadas com as principais server roles.
Nome da role Permissões para os membros desta role
Sysadmin Poderes totais sobre todos os objetos do servidor.

Securityadmin Pode gerenciar logins do servidor.
Serveradmin Pode configurar a maioria das opções do servidor.
Diskadmin Gerenciar os arquivos de um Banco de Dados.
Dbcreator Criar e alterar Bancos de Dados.
Processadmin Gerenciar processos rodando no SQL Server.
Setupadmin Pode gerenciar e configurar a replicação entre servidores SQL Server e extender store procedures.
NOTA
Não é possível criar novas roles de servidor. Ou seja, você está limitado a utilizar as server roles que são criadas quando o SQL Server 2005
é instalado.
Também temos algumas roles predefinidas para Banco de Dados. Na Tabela 6.13, temos a descrição
destas roles.
Tabela 6.13 Permissões associadas com as principais Fixed Database Roles.
Nome da role Permissões para os membros desta role.
db_owner Tem poderes totais sobre o Banco de Dados.

db_accessadmin Pode adicionar e remover usuários ao Banco de Dados.
db_datareader Pode ler dados em todas as tabelas de usuário do Banco de Dados.
db_datawriter Pode adicionar, alterar ou excluir dados em todas as tabelas de usuário do banco de dados.
db_ddladmin Pode adicionar, modificar ou excluir objetos no Banco de Dados.
db_securityadmin Pode gerenciar roles e adicionar ou excluir usuários às roles do Banco de Dados. Pode gerenciar as
permissões para objetos do Banco de Dados.
db_backupoperator Pode fazer o backup do Banco de Dados.
db_denydatareader Não pode consultar dados em nenhuma das tabelas do Banco de Dados, mas pode efetuar alterações na
estrutura do Banco de Dados e de seus objetos.
db_denydatawriter Não pode alterar dados no Banco de Dados.
Existe ainda uma role chamada public. Todo usuário adicionado a um Banco de Dados automaticamente
pertence a esta role. Não podemos adicionar novos usuários a esta role, pois qualquer usuário ou role
que é adicionado ao Banco de Dados fará parte desta role. A role public não pode ser excluída. Devemos
ter cuidado com as permissões atribuídas a esta role, uma vez que todos os usuários e roles do Banco de
Dados fazem parte dela. Por outro lado, a role public, se corretamente utilizada, pode simplificar a
administração, em determinadas situações. Por exemplo, se todos os usuários de um Banco de Dados
devem ter acesso de leitura, basta dar a permissão de leitura para a role public. Como todos os usuários
pertencem à role public, eles irão herdar a permissão de leitura, atribuída à role public.
Agora precisamos aprender a criar roles no SQL Server 2005 e a adicionar usuários a roles. Vamos seguir
a nossa metodologia. Aprenderemos a criar roles utilizando o SQL Server Management Studio e também
comandos T-SQL, na janela de execução de comandos. Lembrando que somente é possível criar novas
roles em nível de Banco de Dados, isto é, não poderemos adicionar novas roles em nível de servidor.
CRIANDO NOVAS ROLES COM O SQL SERVER

MANAGEMENT STUDIO E SQL SERVER 2005
Exemplo prático: Utilizando o SQL Server Management Studio, crie as roles indicadas na Tabela 6.14.
Tabela 6.14 Roles a serem criadas usando o SQL Server Management Studio.
Nome da role Banco de Dados – Instância
consulta Exemplo1 – SERVIDOR\SQL2005

gerentes Exemplo1 – SERVIDOR\SQL2005
fazbackup Exemplo1 – SERVIDOR\SQL2005
consulta AdventureWorks – SERVIDOR\SQL2005
gerentes AdventureWorks – SERVIDOR\SQL2005
fazbackup AdventureWorks – SERVIDOR\SQL2005
Para criar as roles da Tabela 6.14, siga os passos indicados a seguir:
1. Abra o SQL Server Management Studio e, na janela Object Explorer, clique no sinal de + ao
lado da instância SERVIDOR\SQL2005.
2. Dê um clique no sinal de + ao lado do Banco de Dados Exemplo1, para exibir as suas opções.
Nas opções que são exibidas, abaixo do Banco de Dados Exemplo1, clique no sinal de + ao lado
da opção Security.
3. Nas opções que surgem, dê um clique na opção Roles para selecioná-la.
4. Clique com o botão direito do mouse na opção Roles. No menu que surge dê um clique na opção
New -> New Database Role... Surge a janela para a criação de uma nova role de Banco de Dados.
5. No campo Name digite Consulta. No campo Owner você pode especificar qual schema será o
dono da role que está sendo criada.
6. Na lista Schemas owned by this role, você pode marcar um ou mais dos schemas disponíveis
no Banco de Dados, sendo que a role que está sendo criada passará a ser o novo dono das
roles selecionadas. No nosso exemplo, a role Consutla não será dono de nenhum dos
schemas disponíveis.
7. Na parte de baixo da janela, você poderia adicionar um ou mais usuários ou até mesmo outras roles,
como membro da role que você está criando. Por enquanto ainda não temos Users adicionados ao
Banco de Dados Exemplo1. Por isso, neste momento, não temos como adicionar usuários à role
Consulta, que está sendo criada. Vou insistir novamente, porque é muito importante que você tenha
em mente o modelo de segurança do SQL Server 2005. No item anterior, nós adicionamos logins,
sendo que um login pode ser uma conta do Windows ou um login criado no próprio SQL Server 2005
(desde que a instância esteja configurada para o modo de autenticação SQL Server and Windows
Authentication mode). O login só dá direito de fazer um logon na instância. Mas, na prática, o que os
usuários precisam, além do logon, é ter permissão aos dados de um ou mais Bancos de Dados. Para
que um usuário possa ter permissão de acesso, o login do usuário tem que ser adicionado como um
user, nos Bancos de Dados que ele precisa acessar. Além de adicionar o login do usuário como user do
Banco de Dados, o user deve receber permissões de acesso. As permissões podem ser dadas diretamente
para o user ou, o que é mais indicado, podemos adicionar o user como membro de uma role que
possui a permissão. Ao ser adicionada a role, o usuário herda as permissões da role. Para fixar bem este
modelo, vamos considerar o que é preciso para que o usuário jsilva de um domínio chamado ABC
(portanto ABC\jsilva) possa ter acesso de leitura a tabela Clientes, do Banco de Dados Exemplo1, da
instância SERVIDOR\SQL2005. Para isso, teríamos que executar os seguintes passos:
♦ Adicionar a conta ABC\jsilva como um login na instância SERVIDOR\SQL2005.
♦ Adicionar o login ABC\jsilva como um user no Banco de Dados Exemplo1.
♦ Dar permissão de leitura na tabela Clientes, para o User ABC\jsilva, ou adicionar o User
ABC\jsilva a uma role que tenha permissão de leitura na tabela Clientes.
Clique em OK. A nova role consulta foi criada, conforme indicado na Figura 6.19:
Figura 6.19 Role consulta já criada no Banco de Dados Exemplo1.
8. Repita os passos descritos anteriormente para criar as roles gerentes e fazbackup no Banco de
Dados Exemplo1 da instância SERVIDOR\SQL2005.
9. Utilize as informações que você aprendeu neste exemplo, para criar as roles consulta, gerentes
e fazbackup no Banco de Dados AdventureWorks da instância SERVIDOR\SQL2005.
CRIANDO NOVAS ROLES USANDO COMANDOS T-SQL

Para adicionar uma nova role a um Banco de Dados, utilizamos o comando sp_addrole.
Sintaxe para o comando sp_addrole:
exec sp_addrole ‘nome’, ‘dono da role’
Por exemplo, para adicionar uma role chamada teste, cujo dono seja o schema Clientes, utilize o
seguinte comando:
exec sp_addrole ‘teste’, ‘Clientes

NOTA
Se não for especificado o parâmetro dono, o dono da role será o Schema dbo – database owner.
Algumas observações sobre o comando sp_addrole:
♦ O nome de uma role pode conter até 128 caracteres, porém não pode conter a barra invertida
e nem pode ser um valor nulo (NULL) ou uma string vazia ‘ ‘.
♦ Somente membros das roles sysadmin, db_securityadmin e db_owner têm permissão para utilizar
o comando sp_addrole.
♦ Não podemos criar novas roles à nível de servidor, somente à nível de Banco de Dados.
Para excluir uma role, podemos utilizar o comando sp_droprole.
Sintaxe para o comando sp_droprole:
exec sp_droprole ‘nome’
Por exemplo, para excluir a role chamada teste, criada anteriormente, utilize o seguinte comando:
exec sp_droprole ‘teste’
Algumas observações sobre o comando sp_droprole:
♦ Somente membros das roles sysadmin, db_securityadmin e db_owner têm permissão para utilizar
o comando sp_droprole.
♦ Não podemos excluir uma role que possui membros. Antes, temos que retirar todos os membros
da role, para depois poder excluir a role. Aprenderemos a adicionar e a excluir membros de
uma role, no próximo item.
♦ O comando sp_droprole não pode ser executado no contexto de uma transação definida pelo
usuário.
♦ Não podemos excluir roles predefinidas – Server Roles e Database Roles.
Também podemos utilizar o comando sp_helprole para obter informações sobre as diversas roles em
um Banco de Dados. Considere o exemplo a seguir:
use AdventureWorks
exec sp_helprole
Na Figura 6.20 temos o resultado da execução deste comando. Observe que as roles Consulta, Gerentes
e Fazbackup, que criamos anteriormente, já aparecem na listagem.
Figura 6.20 Resultado do comando sp_helprole, no Banco de Dados AdventureWorks.
Agora vamos a um exemplo prático.
Exemplo prático: Utilizando a janela de execução de comandos T-SQL, crie as roles indicadas na Tabela 6.15.
Tabela 6.15 Roles a serem criadas com comandos T-SQL.
role1 Exemplo1 – SERVIDOR\SQL2005

Para criar as roles da Tabela 6.15, siga os passos indicados a seguir:
1. Se você não estiver com o SQL Server Management Studio, abra-o.

Será aberta a janela para execução de comandos T-SQL, a qual você já utilizou diversas vezes neste livro.
4. Para criar as roles indicadas na Tabela 6.15, digite os seguintes comandos:

— Alterna para o Banco de Dados Exemplo1
use exemplo1
— Utilizo sp_addrole para criar as novas roles.
exec sp_addrole ‘role1’

5. Pressione Ctrl+E para executar estes comandos.

6. As roles role1, role2 e role3 são adicionadas ao Banco de Dados Exemplo1, da instância
SERVIDOR\SRVINST01, e a seguinte mensagem é exibida:
7. Feche a janela de execução de comandos T-SQL.
Muito bem, agora temos uma série de logins e roles adicionados à instância SERVIDOR\SQL2005, do
SQL Server 2005. O próximo passo é aprendermos a adicionar logins como users de um Banco de
Dados e a dar permissões de acesso aos Bancos de Dados e seus objetos, para users e roles. Também
vamos aprender como se comporta a segurança quando um usuário pertence a uma ou mais roles, e
quando, além das permissões permitidas, temos permissões explicitamente negadas (deny). Também
aprenderemos a adicionar usuários às roles que criamos. Mas este é o assunto do próximo item.
KNOW-HOW EM: CONFIGURAÇÃO DE ACESSO AOS

OBJETOS DE UM BANCO DE DADOS DO SQL SERVER 2005
PRÉ-REQUISITOS
♦ Noções básicas sobre o modelo de segurança do Windows 2000 Server e Windows Server 2003.
♦ Ter criados os logins de exemplo e roles, dos exemplos dos itens anteriores.
METODOLOGIA
♦ Apresentação dos comandos necessários para a configuração das permissões de acesso aos objetos de um Banco de Dados.
TÉCNICA
♦ Configurar o acesso aos objetos de um Banco de Dados do SQL Server 2005, utilizando os comandos apresentados.
Agora que já adicionamos vários logins, precisamos dar autorização para que estes logins possam acessar os
Bancos de Dados de uma instância do servidor SQL Server. Em cada Banco de Dados, temos uma opção
chamada Users, dentro das opções Security. Nesta opção, por padrão, estão adicionados os logins dbo, guest,
INFORMATION_SCHEMA e sys. Para darmos permissão de acesso, por exemplo ao usuário SERVIDOR\user1,
precisamos adicioná-lo a esta lista de usuários. Na hora em que estamos adicionando um usuário, podemos já
adicioná-lo a uma ou mais roles do Banco de Dados. Após ter adicionado o usuário, ainda será possível incluí-
lo e excluí-lo de uma ou mais roles, conforme as necessidades de acesso do usuário.
Apenas para manter o foco, vamos recapitular os passos que fizemos até agora:
1. Adicionamos usuários do Windows como logins para a instância SERVIDOR\SQL2005 do SQL Server.
2. Criamos novos logins no próprio SQL Server 2005, na instância SERVIDOR\SQL2005, a qual
está no modo de autenticação SQL Server and Windows Authentication mode.
3. Criamos algumas roles em alguns Bancos de Dados.
O que faremos neste item:
1. Daremos permissão de acesso aos logins anteriormente adicionados, para alguns Bancos de
Dados, adicionando os respectivos logins como usuários do Banco de Dados (opção Security -
> Users do Banco de Dados).
2. Adicionaremos os usuários a uma ou mais roles.
O passo final, que aprenderemos no próximo item, é dar permissões sobre os objetos do Banco de
Dados para os usuários e roles que têm permissão de acesso ao Banco de Dados.
NOTA
Para uma descrição detalhada do modelo de segurança no SQL Server 2005, consulte o item “Uma visão geral da segurança no SQL Server
2005”, no início deste capítulo.
DANDO PERMISSÃO DE ACESSO AO BANCO DE DADOS

Neste item aprenderemos a adicionar logins à lista de usuários com permissão de acesso a um
Banco de Dados. Vamos dar permissão de acesso para os usuários nos respectivos Bancos de Dados
Tabela 6.16 Dando permissão de acesso ao Banco de Dados.
Login Banco de Dados – Instância
user1 e user2 Exemplo1 – SERVIDOR\SQL2005

grupo1 e grupo2 Exemplo1 – SERVIDOR\SQL2005
user3, user4 e user5 AdventureWorks – SERVIDOR\SQL2005
grupo1 e grupo2 AdventureWorks – SERVIDOR\SQL2005
Exemplo prático: Para adicionar os users indicados na Tabela 6.16, siga os passos indicados a seguir:
2. Na janela Object Explorer, dê um clique no sinal de + ao lado da instância SERVIDOR\SQL2005,

para expandi-la.
3. Nas opções que surgem, dê um clique no sinal de + ao lado de Databases para exibir os Bancos
de Dados disponíveis.
4. Dê um clique no sinal de + ao lado do Banco de Dados Exemplo1, para exibir os objetos deste
Banco de Dados.
5. Dê um clique no sinal de + ao lado da opção Security, para exibir as opções de segurança,

disponíveis para o Banco de Dados Exemplo1.
6. Dê um clique com o botão direito do mouse na opção Users.
7. No menu de opções que surge, dê um clique em New User. Surge a janela Database User - New,
para adição de um novo usuário ao Banco de Dados.
8. No campo User name você informa o nome que o usuário terá no Banco de Dados. Todo
usuário é associado a um login e é recomendado que você use para nome de usuário o mesmo
nome de login. Podemos utilizar este campo User name, para que o usuário tenha um nome
diferente do seu nome de login. Esta não é uma prática recomendada, por isso vamos manter
o nome do usuário no Banco de Dados igual ao seu nome de login no servidor SQL Server. No
campo User name e também no campo Login name, digite SERVIDOR\user1. Ou seja, estou
adicionando o login SERVIDOR\user1, como sendo o usuário SERVIDOR\user1, do Banco de
Dados Exemplo1. Com isso, o user SERVIDOR\user1 poderá receber permissões de acesso aos
objetos do Banco de Dados Exemplo1 e também poderá ser incluído como membro de uma ou
mais roles, do Banco de Dados Exemplo1.
Na parte debaixo da janela, você poderá incluir o usuário em uma ou mais roles do Banco de Dados.
Lembre-se que, ao incluir o usuário em uma role, ele irá herdar todas as permissões da role. Também
lembre que todo usuário, automaticamente, pertence a role public e você não pode retirá-lo desta role.
Observe que a role public nem aparece na lista de roles, pois você não pode configurar para que o user
não pertença à role public.
Outro detalhe importante é que nesta tela você pode definir qual o schema default, associado ao User
que está sendo adiconado. Para isso, basta selecionar o schema na lista Default Schema. Para todos os
detalhes sobre schema e default schema, consulte o tópico “Modelo de Segurança do SQL Server 2005”,
no início do capítulo.
Vamos incluir o usuário na role consulta. Para isso, na lista Database role membership, marque a role
Consulta. Sua tela deve estar conforme indicado na Figura 6.21:
Figura 6.21 Adicionando o user SERVIDOR\user1.
9. Dê um clique no botão OK e pronto, o usuário SERVIDOR\user1 é adicionado à lista de usuários

com permissão de acesso ao Banco de Dados Exemplo1.
10. Seguindo as orientações deste exemplo, adicione a permissão de acesso para os usuários e grupos,
aos respectivos Bancos de Dados, indicados na Tabela 6.16. Também faça todos os usuários que
estão sendo adicionados membros da role Consulta no Banco de Dados Exemplo1. No Banco de
Dados AdventureWorks, mantenha os usuários apenas como membros da role public.
Na Figura 6.22, temos a lista dos users do Banco de Dados Exemplo1.
Adicionamos usuários à lista de usuários. No caso do Banco de Dados Exemplo1, também fizemos os usuários membros da role Consulta. Porém
NOTA
ainda não definimos as permissões destes usuários aos objetos do Banco de Dados. Por exemplo quem pode consultar quais tabelas? Quem pode
consultar e alterar quais tabelas? Quem pode criar novas tabelas e views? Veremos como definir estas permissões mais adiante, neste capítulo.
Para excluir usuários da lista de usuários com permissão de acesso é bastante simples. Para isso basta
navegar até a opção Users, onde está o usuário a ser excluído, e clicar com o botão direito do mouse no
usuário a ser excluído. No menu que surge, dê um clique na opção Delete. Ao excluir um usuário da
opção Users, ele deixa de ter permissão de acesso ao Banco de Dados, porém o seu login continua na
lista de logins do servidor SQL Server.
Figura 6.22 Usuários com permissão de acesso ao Banco de Dados Exemplo1.
DANDO PERMISSÃO DE ACESSO AO BANCO DE DADOS, USANDO COMANDOS T-SQL

Neste item aprenderemos a adicionar logins à lista de usuários com permissão de acesso a um Banco de
Dados, utilizando comandos T-SQL, na janela de execução de comandos.
Para adicionarmos um login à lista de usuários autorizados a acessar um Banco de Dados, utilizamos o
comando sp_grantdbaccess.
Sintaxe para o comando sp_grantdbaccess:
use database
exec sp_grantdbaccess ‘nome de login’
Por exemplo, para adicionar o usuário user1, do domínio SERVIDOR ao Banco de Dados
AdventureWorks, podemos utilizar os seguintes comandos:
use AdventureWorks
exec sp_grantdbaccess ‘SERVIDOR\user1’
Algumas observações sobre o comando sp_grantdbaccess:
♦ Somente membros das roles sysadmin e das roles de Banco de Dados db_accessadmin e db_owner
é que têm permissão para utilizar este comando.
♦ Este comando não pode ser executado no contexto de uma transação iniciada pelo usuário.
Exemplo prático: Vamos dar permissão de acesso para os usuários nos respectivos Bancos de Dados
Tabela 6.17 Dando permissão de acesso ao Banco de Dados.
Login Permissão no Banco de Dados – Instância
jose e paulo AdventureWorks – SERVIDOR\SQL2005

jovina e maria AdventureWorks – SERVIDOR\SQL2005
pedro, sqluser1 e sqluser2 AdventureWorks – SERVIDOR\SQL2005
grupo1 e grupo2 AdventureWorks – SERVIDOR\SQL2005
Para dar permissão de acesso, conforme indicado na Tabela 6.17, siga os passos indicados a seguir:
1. Abra o SQL Server Management Studio e, na janela Object Explorer, navegue até a instância
SERVIDOR\SQL2005. Clique com o botão direito do mouse na instância SERVIDOR\SQL2005
e, no menu de opções que é exibido, clique em New Query. Será aberta a janela para execução
de comandos T-SQL.
2. Digite os seguintes comandos:

— Tornando o Banco de Dados AdventureWorks o banco atual
use AdventureWorks
— Adiciono as permissões de acesso ao Banco de Dados AdventureWorks
— para isso utilizo o comando sp_grantdbaccess
exec sp_grantdbaccess ‘SERVIDOR\jose’

exec sp_grantdbaccess ‘SERVIDOR\paulo’
exec sp_grantdbaccess ‘SERVIDOR\jovina’
exec sp_grantdbaccess ‘SERVIDOR\maria’
exec sp_grantdbaccess ‘SERVIDOR\pedro’
— Agora adiciono os logins do próprio SQL Server,

— isto é, logins que não são do Windows
exec sp_grantdbaccess ‘sqluser1’

exec sp_grantdbaccess ‘sqluser2’
— e por último os grupos do WINDOWS
exec sp_grantdbaccess ‘SERVIDOR\grupo1’

exec sp_grantdbaccess ‘SERVIDOR\grupo2’
3. Pressione Ctrl+E para executar estes comandos. Os usuários da Tabela 6.17 serão adicionados à
lista Users do Banco de Dados AdventureWorks da instância SERVIDOR\SQL2005.
4. A seguinte mensagem será emitida:
Para retirar a permissão de acesso do usuário a um Banco de Dados, podemos utilizar o comando
sp_revokedbaccess.
NOTA
Para compatibilidade com versões anteriores, também poderíamos utilizar o comando sp_dropuser, mas é recomendada a utilização de
sp_revokedbaccess sempre que possível. O comando sp_dropuser não deverá mais estar disponível, nas próximas versões do SQL Server.
Por exemplo, para remover o usuário SERVIDOR\user1, do Banco de Dados AdventureWorks,

poderíamos utilizar os seguintes comandos:
use AdventureWorks
exec sp_revokedbaccess ‘SERVIDOR\user1’
Algumas observações sobre o comando sp_revokedbaccess:
♦ Somente membros da server role sysadmin e das roles de Banco de Dados db_accessadmin e
db_owner é que têm permissão para utilizar este comando.
♦ Com o comando sp_revokedbaccess não é possível remover os seguintes usuários:
a. A role public ou o usuário dbo.
b As roles fixas do Banco de Dados, como db_owner, db_datareader, etc.
c. Os usuários guest, nos Bancos de Dados master e tempdb.
ADICIONANDO USUÁRIOS COMO MEMBROS DE UMA OU MAIS ROLES

Agora vamos aprender a adicionar usuários como membros de uma ou mais roles. Apenas para
recapitular, devemos ter as roles criadas pelo usuário indicadas na Tabela 6.18. Estas roles foram criadas
anteriormente, neste capítulo.
Tabela 6.18 Roles criadas pelo usuário.
leitores Exemplo1 – SERVIDOR\SQL2005

gerentes Exemplo1 – SERVIDOR\SRVINST01
fazbackup Exemplo1 – SERVIDOR\SRVINST01
leitores pubs – SERVIDOR\SRVINST02
gerentes pubs – SERVIDOR\SRVINST02
fazbackup pubs – SERVIDOR\SRVINST02
role1 Exemplo1 – SERVIDOR\SRVINST01
Vamos utilizar o SQL Server Management Studio para adicionar alguns usuários a algumas das roles
anteriormente criadas, conforme indicado na Tabela 6.19.
Tabela 6.19 Adicionando usuários a roles.
Nome da role Usuários a serem adicionados
role1 user1 e user2

role2 grupo1 e grupo2
Exemplo prático: Para adicionar os usuários indicados na Tabela 6.19, faça o seguinte:

3. Clique no sinal de + ao lado da opção Databases.
4. Dê um clique no sinal de + ao lado do Banco de Dados Exemplo1 para exibir os objetos deste
Banco de Dados.
5. Clique no sinal de + ao lado da opção Security. Nas opções que são exibidas, clique no sinal de
+ ao lado da opção Roles. Devem aparecer, na listagem de roles, dentre outras, as roles role1 e
role2 criadas anteriormente, conforme indicado na Figura 6.23:
Figura 6.23 Roles role1 e role2 criadas anteriormente.
6. Dê um clique duplo na role1 para abrir as suas propriedades. Surge a janela com as propriedades
da role.
7. Para adicionar usuários, dê um clique no botão Add, na parte de baixo da janela.
8. Será exibida a janela Select Database User or Role. Você pode digitar o nome de um ou mais users
ou roles, separados por ponto-e-vírgula. Uma opção mais prática é fazer com que seja exibida
uma listagem dos users e roles disponíveis. Para isso, clique no botão Browse. Será exibida a
janela Browse for Objects, na qual são exibidos os users e roles do Banco de Dados Exemplo1.
Marque os usuários SERVIDOR\user1 e SERVIDOR\user2, conforme indicado na Figura 6.24:
Figura 6.24 Adicionando usuários.
9. Dê um clique no botão OK. Você estará de volta à janela Select Database User or role, com os
usuários já adicionados: [SERVIDOR\user1]; [SERVIDOR\user2]. Clique em OK.
Você estará de volta à janela de propriedades da role1 e os usuários SERVIDOR\user1 e SERVIDOR

\user2 já estarão na lista de usuários da role, conforme indicado na Figura 6.25:
10. Dê um clique em OK e feito: os usuários [SERVIDOR\user1] e [SERVIDOR\user2] terão sido

adicionados a role role1. Você estará de volta ao SQL Server Management Studio com a listagem
das roles do Banco de Dados Exemplo1 sendo exibida.
11. Dê um clique duplo na role role2 para abrir a janela com as suas propriedades.
12. Dê um clique no botão Add, para adicionar usuários a esta role.
13. Clique no botão Browse para exibir a lista de usuários. Na lista de usuários selecione
SERVIDOR\grupo1 e SERVIDOR\grupo2. Dê um clique em OK. Você estará de volta à janela
Select Database User or role, com os usuários já adicionados: [SERVIDOR\grupo1];
[SERVIDOR\grupo2]. Clique em OK.
14. Você estará de volta à janela de propriedades da role2 e os usuários SERVIDOR\grupo1 e

SERVIDOR\grupo2 já estarão na lista de usuários da role role2.
Figura 6.25 Usuários já aparecem na lista de users da role.
15. Dê um clique em OK e feito, os usuários terão si
do adicionados à role. Você estará de volta ao SQL Server Management Studio.
Exemplo prático: Para adicionar usuários a uma role de servidor (sysadmin, securityadmin, etc.):
1. Abra o SQL Server Management Studio e na janela Object Explorer clique no sinal de + ao lado
da instância com a qual você irá trabalhar.
2. Nas opções que surgem, dê um clique no sinal de + ao lado da opção Security.
3. Nas opções que surgem, dê um clique no sinal de + ao lado da opção Server Roles. Será exibida
a listagem com as roles de servidor.
4. Clique com o botão direito do mouse na role a ser alterada e, no menu de opções que é exibido,
clique em Manage Members. Surge a janela com as propriedades da role.
5. Para adicionar usuários dê um clique no botão Add. Será exibida a janela Select logins. Para
exibir a lista de logins disponívies, clique no botão Browse. Será exibida a lista de logins
disponíveis na instância, conforme exemplo da Figura 6.26:
Figura 6.26 Logins disponíveis na instância SERVIDOR\SQL2005.
6. Selecione os logins a serem adicionados e dê um clique em OK. Você estará de votla à janela
Select logins. Clique em OK. Você estará de volta à janela de propriedades da role, com os
usuários selecionados já adicionados como membros da role.
7. Dê um clique no botão OK e pronto, os usuários foram adicionados.
Para excluir um membro de uma role, basta abrir as propriedades da role, marcar o usuário a ser
excluído e dar um clique no botão Remove. Depois dê um clique no botão OK.
Podemos adicionar logins a roles do servidor, adicionar usuários a roles de um Banco de Dados, excluir
logins de uma role do servidor e também excluir usuários de uma role de Banco de Dados, utilizando
comandos T-SQL.
Para adicionar um usuário a uma role de servidor, utilizamos o seguinte comando:
exec sp_addsrvrolemember ‘login’, ‘role’
Por exemplo, para adicionar os usuários SERVIDOR\user1 e SERVIDOR\user2 à role sysadmin, podemos
utilizar os seguintes comandos:
exec sp_addsrvrolemember ‘SERVIDOR\user1’, ‘sysadmin’

exec sp_addsrvrolemember ‘SERVIDOR\user2’, ‘sysadmin’
Para excluir um usuário de uma role do servidor, utilizamos o seguinte comando:
exec sp_dropsrvrolemember ‘login’, ‘role’
Por exemplo, para excluir os usuários SERVIDOR \user1 e SERVIDOR \user2 da role sysadmin, podemos
utilizar os seguintes comandos:
exec sp_dropsrvrolemember ‘SERVIDOR\user1’, ‘sysadmin’

exec sp_dropsrvrolemember ‘SERVIDOR\user2’, ‘sysadmin’
Para adicionar um usuário a uma role de Banco de Dados, utilizamos o seguinte comando:
use database
exec sp_addrolemember ‘role’, ‘usuário’
Por exemplo, para adicionar os usuários SERVIDOR \user1 e SERVIDOR \user2, como membros da role
Consulta, do Banco de Dados Exemplo1, utilizamos os seguintes comandos:
use exemplo1
exec sp_addrolemember ‘consulta’, ‘SERVIDOR\user1’
exec sp_addrolemember ‘consulta’, ‘SERVIDOR\user2’
Para excluir um usuário de uma role de Banco de Dados, utilizamos o seguinte comando:
use database
exec sp_droprolemember ‘role’, ‘usuário’
Por exemplo, para excluir os usuários SERVIDOR\user1 e SERVIDOR\user2, da role Consulta, do Banco
de Dados Exemplo1, utilizamos os seguintes comandos:
use exemplo1
exec sp_droprolemember ‘consulta’, ‘SERVIDOR\user1’
exec sp_droprolemember ‘consulta’, ‘SERVIDOR\user2’
NOTA
Observe que, no caso de roles do servidor, o primeiro parâmetro é o nome do login seguido do nome da role – exec sp_addsrvrolemember
‘login’, ‘role’ ou exec sp_dropsrvrolemember ‘login’, ‘role’. Já no caso de roles de Banco de Dados é o contrário, isto é, o primeiro
parâmetro é o nome da role e o segundo, o nome do usuário – exec sp_addrolemember ‘role’, ‘usuário’ ou exec sp_droprolemember ‘role’,
‘usuário’. Explicação? Não me atrevo a tanto.
KNOW-HOW EM: CONFIGURAÇÃO, PLANEJAMENTO E

TESTE DE PERMISSÕES DE ACESSO AOS OBJETOS
DE UM BANCO DE DADOS DO SQL SERVER 2005
PRÉ-REQUISITOS
♦ Noções básicas sobre o modelo de segurança do Windows 2000 Server e do Windows Server 2003.
METODOLOGIA
♦ Análise de diversas situações envolvendo permissões de acesso.
Até agora já aprendemos a adicionar logins, criar roles, adicionar usuários ao Banco de Dados,
adicionar usuários a roles do Banco de Dados e logins a roles do servidor. O passo final das
configurações de segurança é configurar as permissões de acesso aos diversos objetos dos Bancos
de Dados, para usuários e roles.
Por exemplo, criamos uma role Consulta, no Banco de Dados Exemplo1. Como fazer com que os
membros desta role somente tenham permissão de leitura nos dados do Banco de Dados Exemplo1?
Muito simples. Temos que definir as permissões para a role Consulta, de tal forma que esta tenha
permissão somente de leitura. E se tivermos dez usuários que pertencem à role Consulta, mas por
determinação do chefe um deles não deve ter acesso ao Banco de Dados Exemplo1? Como fazer?
Muito simples. É só negar o direito de leitura para este usuário especificamente. Isto é, que chamamos
de configurar permissões de acesso.
As permissões definem o que um login e as roles de servidor podem fazer no servidor, como por exemplo,
criar novos Bancos de Dados, excluir os existentes, etc. e o que os usuários e as roles de Bancos de Dados
podem fazer dentro do Banco de Dados, por exemplo, consultar, alterar, excluir, inserir dados, criar novas
tabelas, excluir as existentes, criar novas consultas, criar novas triggers, adicionar usuários, etc.
Vamos simplificar: Permissões definem quem pode fazer o que e onde.
Isto é o que aprenderemos neste item, ou seja, configurar permissões. Veremos os seguintes tópicos:
♦ Dando permissões no SERVIDOR\instância.
♦ Dando permissões dentro do Banco de Dados.
♦ Dando permissões a objetos do Banco de Dados – tabelas, views, etc.
DEFININDO PERMISSÕES EM NÍVEL DE SERVIDOR\INSTÂNCIA

Permissões em nível de SERVIDOR\instância definem o que um determinado login pode fazer. Por
exemplo, logins que são membros do grupo sysadmin podem fazer qualquer coisa, tais como:
♦ Criar novos Bancos de Dados.
♦ Excluir Bancos de Dados.
♦ Alterar Bancos de Dados.
♦ Agendar tarefas.
A maneira de darmos permissões em um SERVIDOR\instância para um determinado login é

adicionando-o a uma das roles do servidor, de acordo com o nível de permissão que o login necessita.
Por exemplo, se precisamos que um determinado login seja capaz de gerenciar logins, devemos adicioná-
lo à role securityadmin; se queremos dar a um login permissões totais na instância, basta adicionar este
login como membro da role sysadmin.
Para adicionar um login a uma role, temos duas opções. Abrir as propriedades da role, clicar no botão
Add e adicionar um ou mais usuários. Este procedimento foi descrito no item anterior.
Outra maneira é acessarmos as propriedades do login. Para isso abra o SQL Server Management Studio,
clique no sinal de + ao lado da instância que você está trabalhando (por exemplo SERVIDOR\SQL2005).
Nas opções que surgem, dê um clique no sinal de + ao lado da opção Security para expandi-la. Abaixo
de Security dê um clique no sinal de + ao lado da opção Logins. Será exibida uma lista com todos os
logins da instância em questão. Para acessar as propriedades de um determinado login, basta dar um
clique duplo sobre o login a ser configurado. Na janela de propriedades, temos diversas guias, dentre as
quais podemos destacar as seguintes:
♦ General: Nesta guia podemos definir se permitimos (Grant server access) ou negamos (Deny
server access) o acesso ao login em questão. Também podemos definir o Banco de Dados e a
linguagem padrão para quando o login fizer a conexão com a instância do servidor SQL Server.
♦ Server Roles: Nesta guia podemos adicionar o login a uma ou mais roles do servidor. Lembre que ao
adicionar um login a uma role, o login irá herdar todas as permissões atribuídas à role. Quer ser
demitido? Adicione todo mundo à role sysadmin. A menos que você consiga provar que não está em
suas plenas capacidades mentais, é demissão na certa. Também lembre que não é possível adicionar
novas roles de servidor, além das roles criadas durante a instalação do SQL Server 2005. Para adicionar
o login a uma ou mais roles, basta marcar as roles desejadas, conforme exemplo indicado na Figura
6.27, onde estou adicionando o login SERVIDOR\user1 e as roles diskadmin e securityadmin.
Figura 6.27 Adicionando o login a uma ou mais roles.
♦ Database Access: Nesta guia podemos adicionar o login em questão, como usuário de um ou
mais Bancos de Dados, da instância que está sendo configurada. Ao selecionarmos um Banco
de Dados nesta janela, na parte inferior da janela surge uma listagem com as roles do Banco de
Dados selecionado. Neste momento, além de adicionar o login como usuário de um ou mais
Banco de Dados, podemos incluí-lo em uma ou mais roles do Banco de Dados, conforme as
necessidades de acesso do usuário. Na Figura 6.28 o usuário SERVIDOR\user1 tem permissão
de acesso ao Banco de Dados Exemplo1 e está sendo adicionado às roles public, db_accessadmin
e db_securityadmin.
Figura 6.28 Adicionando o login como usuário do Banco de Dados Exemplo1.
Depois de feitas as configurações necessárias, é só dar um clique no botão OK.

NOTA
Para adicionar um login a uma role do servidor, também podemos utilizar o comando sp_addsrvrolemember, conforme descrito anteriormente.
DANDO PERMISSÕES PARA BANCO DE DADOS

Para um Banco de Dados, podemos definir, dentre outras, as seguintes permissões:
♦ Create Table (Criar Tabela).
♦ Create View (Criar Consulta).
♦ Create SP (Criar Stored Procedure).
♦ Create Default.
♦ Create Rule.
♦ Create Function.
♦ Backup DB (Backup do Banco de Dados).
♦ Backup Log (Backup do Log de transações).
Podemos atribuir estas permissões para usuários e roles do Banco de Dados. Devemos sempre ter em
mente as seguintes regras:
♦ Uma permissão pode ser atribuída ou negada.
♦ Podemos atribuir ou negar permissões para usuários e roles.
♦ O usuário herda todas as permissões das roles às quais ele pertence.
♦ Negar tem precedência sobre permitir. Por exemplo, se um usuário pertencer a três roles –
role1, role2 e role3. A role1 tem permissão para criar tabelas – Create Table. A role2 tem permissão
para criar consultas – Create View. Com isso o usuário herda as permissões para criar tabelas e
consultas. A role3 tem negadas as permissões para criar tabelas e consultas. Como negar tem
precedência sobre permitir, e o usuário pertence às três roles, o usuário terá negadas as permissões
para criar tabela e consultas. A permissão efetiva deste usuário será: Negadas as permissões para
criar tabelas e consultas.
♦ Procure agrupar os usuários que têm necessidades de acesso iguais em uma role. Atribua as
permissões para a role em vez de atribuir para os usuários individualmente. Este procedimento
irá facilitar bastante a administração de segurança e da administração das permissões de acesso
no SQL Server 2005.
Agora vamos aprender a atribuir permissões para usuários e roles. Depois vamos testar as permissões.
Exemplo prático: Utilizando o SQL Server Management Studio, atribua as seguintes permissões para o
Banco de Dados Exemplo1, da instância SERVIDOR\SQL2005:
♦ Usuário: SERVIDOR\user1.
♦ Permitir: Create Table, Create View.
♦ Negar: Backup database, Backup log.
♦ Role: role1
♦ Permitir: Create View, Backup database, Backup Log e Create rule.
Lembre que o usuário SERVIDOR\user1 é membro da role role1. Outro detalhe é que esta role ainda
não foi adicionada como um user com permissão de acesso ao Banco de Dados Exemplo1. Faremos isso
também, no decorrer do exemplo prático a seguir.
Para configurar as permissões sugeridas, siga os passos indicados a seguir:
2. Na janela Object Explorer, navegue até o Banco de Dados Exemplo1, da instância

SERVIDOR\SQL2005.
3. Dê um clique com o botão direito no Banco de Dados Exemplo1 e, no menu de opções que
surge, dê um clique em Properties.
4. Na janela de propriedades do Banco de Dados Exemplo1, dê um clique na opção Permissions.

Surge a janela indicada na Figura 6.29.
Figura 6.29 Definindo permissões para o Banco de Dados Exemplo1.
Nesta janela podemos configurar as permissões para o Banco de Dados. Na parte de cima temos uma lista com
todos os usuários do Banco de Dados (observe que a Role role1 não faz parte desta lista). Na parte de baixo da
janela podemos configurar as diversas permissões disponíveis, para o user selecionado na parte de cima. Por
padrão a permissão vem desmarcada, o que significa que o usuário não tem esta permissão. Antes de
configurarmos as permissões, vamos adicionar a role role1 à lista de users do Banco de Dados. Para isso, clique
no botão Add. Será aberta a janela Select Users or Roles. No campo Enter the object names, digite role1 e
clique em OK. Pronto, agora a role role1 faz parte da lista de users do Banco de Dados Exemplo1.
5. Vamos começar definindo as permissões para o User SERVIDOR\user1. Na parte de cima da

janela, clique no User SERVIDOR\user1, para selecioná-lo e, na parte de baixo da janela, defina
as permissões conforme indicado na Figura 6.30. Observe que a lista de permissões é bastante
extensa. Você terá que usar a barra de rolagem, até localizar as permissões Create table e Create
view, as quais serão permitidas (Allow), para o usuário SERVIDOR\user1. Observe que esta
mesma janela pode ser utilizada para, explicitamente, negar uma ou mais permissões – coluna
Deny. Localize as permissões Backup database e Backup log e marque a coluna Deny, para
negar estas permissões para o usuário SERVIDOR\user1, conforme proposto no nosso exemplo.
6. Agora vamos definir as permissões para a role role1. Clique em role1, na parte de cima da
janela, para selecioná-la. Na parte de baixo da janela, localize as permissões Create view, Backup
database, Backup log e Create rule e marque a coluna Allow, para permitir estas permissões
para a role role1, no Banco de Dados Exemplo1. Com estas configurações, na prática, todos os
membros da role role1, herdarão as permissões que estão sendo atribuídas a role role1, ou seja:
Create view, Backup database, Backup log e Create rule.
Figura 6.30 Definindo as permissões para o usuário SERVIDOR\user1.
7. Dê um clique em OK e pronto, as permissões terão sido definidas.
8. A pergunta agora é: “Qual a permissão efetiva para o usuário SERVIDOR\user1”.
Vamos analisar com calma.
♦ Primeiro: O usuário SERVIDOR\user1 pertence à role role1, portanto herdará as permissões

desta role.
♦ Segundo: Ao analisar as permissões efetivas, gosto de analisar para cada permissão,
separadamente. Então vamos lá:
♦ Permissão Create table: O usuário tem esta permissão, e na role role1 não é negada a
permissão. Portanto, o usuário terá esta permissão e poderá criar novas tabelas no Banco
de Dados Exemplo1.
♦ Permissão Create view: O usuário tem a permissão e também herda a permissão da role
role1. Portanto, o usuário poderá criar novas views no Banco de Dados Exemplo1.
♦ Permissão Create rules: O usuário herda a mesma da role role1. Portanto o usuário poderá
criar novas rules no Banco de Dados Exemplo1.
♦ Permissão Backup database: Esta permissão é negada ao usuário. Não preciso nem continuar
a minha análise, pois negar tem precedência sobre qualquer outra atribuição, ou seja, mesmo
que o usuário herdasse de alguma outra role a permissão de fazer o backup do Banco de
Dados, o negar teria precedência. Portanto o usuário não poderá fazer o backup do Banco de
Dados. Se ele tentar fazer um backup, utilizando o comando BACKUP DATABASE, a seguinte
mensagem será exibida:

BACKUP DATABASE permission denied in database ‘Exemplo1’.
BACKUP DATABASE is terminating abnormally.
Observe que a mensagem indica, claramente, uma falta de permissões para efetuar a operação.
♦ Permissão Backup log: São válidos os mesmos comentários feitos para a permissão Backup
database. Lembrar sempre que negar tem precedência sobre permitir. Se o usuário tentar fazer
um backup do log, a seguinte mensagem será exibida:
BACKUP LOG permission denied in database ‘Exemplo1’.
BACKUP LOG is terminating abnormally.
Também podemos definir as permissões, utilizando comandos T-SQL.
Para atribuí-las utilize o comando GRANT.
Sintaxe para o comando GRANT:
GRANT { ALL | statement [ ,...n ] }

TO security_account [ ,...n ]
Vamos utilizar alguns exemplos para ilustrar a utilização do comando GRANT.
Exemplo 1: Garantir para o login SERVIDOR\user1 a permissão de criar novos Bancos de Dados:
USE Master
GRANT CREATE DATABASE TO [GROZA\user1]
Usei, primeiro, o comando USE Master, para tornar o Banco de Dados Master o banco atual. Isso é
necessário porque a permissão de criar novos Bancos de Dados só pode ser dada, sendo o Banco de
Dados Master o banco atual. Na prática, ao criar um Banco de Dados, o usuário precisa gravar dados
nas tabelas do Banco de Dados master, que é onde ficam as informações sobre tudo o que existe em
uma instância do SQL Server 2005.
Quando o login for um usuário do domínio do Windows, o nome deve vir entre colchetes, como no
exemplo: [SERVIDOR\user1]
Podemos atribuir mais do que uma permissão ao mesmo tempo, para um ou mais logins ou usuários.
Exemplo 2: Atribuir as permissões CREATE TABLE, CREATE RULE e CREATE VIEW, para o usuário
SERVIDOR\user1 no Banco de Dados Exemplo1.
USE Exemplo1
GRANT CREATE TABLE, CREATE RULE, CREATE VIEW
TO [SERVIDOR\user1]
Exemplo 3: Atribuir as permissões CREATE TABLE, CREATE RULE e CREATE VIEW, para os usuários
SERVIDOR\grupo1 e SERVIDOR\grupo2, no Banco de Dados Exemplo1.
SE Exemplo1
GRANT CREATE TABLE, CREATE RULE, CREATE VIEW
TO [SERVIDOR\grupo1], [SERVIDOR\grupo2]
As principais permissões de Banco de Dados, possíveis de serem atribuídas com este comando, são
descritas nas Tabelas 6.20 e 6.21.
Tabela 6.20 Principais permissões de Banco de Dados.
Permissão Se aplica a:
CREATE DATABASE Banco de Dados master.

CREATE DEFAULT Todos os Bancos de Dados.
CREATE PROCEDURE Todos os Bancos de Dados.
CREATE RULE Todos os Bancos de Dados.
CREATE TABLE Todos os Bancos de Dados.
CREATE VIEW Todos os Bancos de Dados.
BACKUP DATABASE Todos os Bancos de Dados.
BACKUP LOG Todos os Bancos de Dados.
Tabela 6.21 Principais permissões de objetos do Banco de Dados.
Permissão Se aplica a:
SELECT Tabelas, views e colunas.

INSERT Tabelas e views.
DELETE Tabelas e views.
UPDATE Tabelas, views e colunas.
EXECUTE Stored Procedures.
NOTA
As permissões SELECT, INSERT, DELETE, UPDATE e EXECUTE são definidas para objetos do Banco de Dados. Aprenderemos a utilizar o comando
GRANT para definir estas permissões logo em seguida.
Exemplo 4: Atribuir todas as permissões para o usuário SERVIDOR\user2, no Banco de Dados Exemplo1.
USE Exemplo1
GRANT ALL
TO [SERVIDOR\user2]
Observe que utilizamos a palavra ALL, para significar todas as permissões.
NOTA
Para uma descrição completa, de todas as opções do comando GRANT, consulte o tópico Transact SQL Reference, no Books OnLine.
Para retirar (revoke) as permissões de Banco de Dados, utilize o comando REVOKE.
Sintaxe para o comando REVOKE:
REVOKE { ALL | statement [ ,...n ] }

FROM security_account [ ,...n ]
Vamos a alguns exemplos para ilustrar a utilização do comando REVOKE.
Exemplo 1: Retirar a permissão de criar novos Bancos de Dados, atribuída para o login SERVIDOR\user1,
anteriormente.
USE MASTER
REVOKE CREATE DATABASE TO [SERVIDOR\user1]
Podemos retirar mais do que uma permissão ao mesmo tempo, para um ou mais logins.
Exemplo 2: Retirar as permissões CREATE TABLE, CREATE RULE e CREATE VIEW, atribuídas para o
usuário SERVIDOR\user1 no Banco de Dados Exemplo1.
USE Exemplo1
REVOKE CREATE TABLE, CREATE RULE, CREATE VIEW
TO [SERVIDOR\user1]
Exemplo 3: Retirar as permissões CREATE TABLE, CREATE RULE e CREATE VIEW, atribuídas para os
usuários SERVIDOR\grupo1 e SERVIDOR\grupo2, no Banco de Dados Exemplo1.
USE Exemplo1
REVOKE CREATE TABLE, CREATE RULE, CREATE VIEW
TO [SERVIDOR\grupo1], [SERVIDOR\grupo2]
Exemplo 4: Retirar todas as permissões atribuídas ao usuário SERVIDOR\user2, no Banco de Dados

Exemplo1.
USE Exemplo1
REVOKE ALL
TO [SERVIDOR\user2]
Agora vamos à análise de mais um estudo de caso e, na seqüência, fica um exercício para o amigo
leitor, onde temos a combinação de permissões em diversas roles e uma combinação entre permitir e
negar permissões.
Estudo de Caso: Considere a situação descrita na Figura 6.31:
Figura 6.31 Permissões no Banco de Dados Exemplo1.
Para definir a permissão efetiva de um usuário devemos lembrar que o usuário herda as permissões das
roles às quais ele pertence. Também devemos lembrar que estas permissões são cumulativas, isto é, se
uma das roles às quais o usuário pertence tiver permissão CREATE TABLE e a outra role à qual o usuário
pertence tiver permissão CREATE VIEW, o usuário herdará as duas permissões.
No nosso exemplo, o user1 tem as permissões CREATE TABLE e CREATE VIEW. Além disso, como
pertence a role role1, ele herda as permissões da role role1. Com isso o usuário user1 está acumulando
as permissões CREATE TABLE, CREATE VIEW, CREATE RULE e CREATE PROCEDURE, sendo as duas
últimas herdadas da role role1.
Qual a permissão efetiva do usuário user1?
♦ CREATE TABLE.
♦ CREATE VIEW.
♦ CREATE RULE.
♦ CREATE PROCEDURE.
Vamos analisar a situação para o usuário user2. Este usuário tem as permissões CREATE TABLE e CRE-
ATE VIEW. Como também pertence à role role1, ele herda as permissões CREATE RULE e CREATE
PROCEDURE. Como o usuário também pertence à role role2, ele herda as permissões da role2, que são
“negar CREATE TABLE” e “negar CREATE VIEW”. Como negar tem precedência sobre permitir, o usuário
user2 terá somente as permissões CREATE RULE e CREATE PROCEDURE.
Qual a permissão efetiva do usuário user2?
♦ CREATE RULE.
♦ CREATE PROCEDURE.
Exercício: Considerando a situação descrita na Figura 6.32, determine as permissões efetivas para os
usuário user1, user2, user3, user4 e user5.
Figura 6.32 Determine as permissões efetivas para cada usuário.
Observe que à medida que novas permissões vão sendo atribuídas pode ser difícil determinar o real
nível de acesso de cada usuário. Para que você possa manter um controle sobre a atribuição de permissões,
faço as seguintes sugestões:
♦ Mantenha uma documentação sobre as atribuições de permissão. É chato? É. Ninguém gosta?

Ninguém gosta. Porém a documentação é de fundamental importância, pois se não tivermos
um controle sobre as atribuições de permissão, podemos chegar a situações onde usuários que
não devem ter acesso estão tendo e usuários que devem ter acesso não estão tendo. Enfim, uma
grande bagunça.
♦ Procure sempre atribuir permissões a roles e não aos usuários individualmente. Isto facilita
bastante a administração das permissões.
♦ Procure agrupar os usuários que têm necessidades de acesso iguais em uma role. Atribua as
permissões para a role em vez de atribuir para os usuários individualmente. Este procedimento
irá facilitar bastante a administração de segurança no SQL Server 2005.
DANDO PERMISSÕES A OBJETOS DO BANCO DE DADOS

As permissões a objetos aplicam-se aos diversos elementos de um Banco de Dados. Por exemplo, em
uma tabela podemos ter permissão de leitura dos dados (SELECT), adição de novos registros (INSERT),
exclusão de registros (DELETE) e assim por diante. As permissões objetos são as que mais diretamente
se relacionam com as atividades diárias dos usuários do Banco de Dados. Por exemplo, se um
determinado usuário utiliza uma aplicação que acessa o Banco de Dados no servidor SQL Server e este
usuário deve ter permissão somente de leitura para os dados de uma determinada tabela, o incluímos
em uma role com permissão SELECT na tabela e pronto, o usuário somente poderá consultar os dados.
Na Tabela 6.22, temos a descrição das principais permissões a objetos.
Tabela 6.22 Principais permissões de objetos do Banco de Dados.
Permissão Se aplica à:
SELECT Tabelas, views e colunas.

INSERT Tabelas e views.
DELETE Tabelas e views.
UPDATE Tabelas, views e colunas.
EXECUTE Stored procedures.
REFERENCES (DRI) Tabelas e colunas.
Podemos atribuir estas permissões para usuários e roles do Banco de Dados. As considerações que
podemos fazer em relação à atribuição de permissões para objetos do Banco de Dados são as mesmas
que fizemos para o caso de permissões para o Banco de Dados.
Agora vamos aprender a atribuir permissões nos objetos do Banco de Dados Exemplo1, para usuários e
roles. Depois vamos testar as permissões.
Exemplo prático: Utilizando o SQL Server Management Studio, atribua as seguintes permissões indicadas
na lista a seguir, para a tabela Clientes, do Banco de Dados Exemplo1, da instância SERVIDOR\SQL2005:
♦ SERVIDOR\user1: SELECT E INSERT
♦ SERVIDOR\user2: INSERT E DELETE
♦ role1: UPDATE e DELETE
Para configurar as permissões sugeridas, siga os passos indicados a seguir:
1. Abra o SQL Server Management Studio, e navegue até o Banco de Dados Exemplo1, da instância
SERVIDOR\SQL2005.
2. Dê um clique no sinal de + ao lado de Exemplo1, para exibir as classes de objetos deste Banco
de Dados.
3. Dê um clique no sinal de + ao lado da opção Tables, para exibir as tabelas do Banco de Dados.
4. Dê um clique com o botão direito do mouse na tabela Clientes e, no menu que surge, dê um
clique em Properties. Será exibida a janela de propriedades da tabela Clientes.
5. Nesta janela dê um clique na opção Permissions, no painel da esquerda. Surge a janela para
definição de permissões da tabela Clientes.
6. A lista de users, com permissões, está em branco. Então, o primeiro passo é adicionar os users
SERVIDOR\user1, SERVIDOR\user2 e a role role1. Para fazer isso, clique no botão Add. Será
aberta a janela Select User or Roles. Clique no botão Browse., para exibir a lista de User e Roles
disponíveis. Será aberta a janela Browse for Objects. Marque os users SERVIDOR\user1,
SERVIDOR\user2 e a role role1, conforme exemplo da Figura 6.33. Clique em OK para fechar a
janela Browse for Objects. Você estará de volta à janela Select Users and Roles. Clique em OK
para fechar esta janela. Você estará de volta à guia Permissions, da janela de propriedades da
tabela Clientes, do Banco de Dados Exemplo1.
Figura 6.33 Adiconando users e roles que receberão permissões.
7. Para definir as permissões para cada usuário/role, é só selecionar o respectivo usuário na lista
User or roles e, na parte de baixo da janela, definir as permissões para o usuário/role selecionado.
A exemplo do que ocorre com as permissões de Banco de Dados, as permissões para objetos de
um Banco de Dados também podem ser permitidas (Allow) ou negadas (Denny).
8. Clique no user SERVIDOR\user1, para selecioná-lo. Marque as permissões SELECT e INSERT,

na coluna Allow, para dar estas permissões para o usuário SERVIDOR\user1.
9. Clique no user SERVIDOR\user2, para selecioná-lo. Marque as permissões INSERT e DELETE,

na coluna Allow, para dar estas permissões para o usuário SERVIDOR\user2.
10. Clique na role role1, para selecioná-la. Marque as permissões UPDATE e DELETE, na coluna
Allow, para dar estas permissões para a role role1, conforme indicado na Figura 6.34.
11. Definidas as permissões propostas no nosso exemplo, dê um clique em OK para fechar a janela
de propriedades da tabela Clientes.
Figura 6.34 Definindo as permissões para a role role1.
12. A pergunta é: “Qual a permissão efetiva para os usuários SERVIDOR\user1 e SERVIDOR\user2,

na tabela Clientes, do Banco de Dados Exemplo1, com base nas permissões atribuídas no nosso
último exemplo?
Vamos analisar com calma.
Primeiro: O usuário SERVIDOR\user1 pertence a role role1, portanto o usuário user1 herdará as
permissões desta role. Portanto o usuário SERVIDOR\user1 acumulará as permissões explicitamente
atribuídas para ele – SELECT e INSERT – e as herdadas da role role1 – UPDATE e DELETE. Com isso a
permissão efetiva do usuário SERVIDOR\user1 será:
♦ SELECT
♦ INSERT
♦ UPDATE
♦ DELETE
ou seja, o usuário poderá selecionar, inserir, alterar e excluir registros.
Exercício: Determine as permissões efetivas do usuário SERVIDOR\user2 na tabela Clientes.
Também podemos definir as permissões de Banco de Dados, utilizando comandos T-SQL.
Para atribuir permissões de objetos do Banco de Dados utilize o comando GRANT.
Sintaxe para o comando GRANT:
GRANT
{ ALL [ PRIVILEGES ] | permission [ ,...n ] }
{
[ ( column [ ,...n ] ) ] ON { table | view }
| ON { table | view } [ ( column [ ,...n ] ) ]
| ON { stored_procedure | extended_procedure }
| ON { user_defined_function }
}
[ WITH GRANT OPTION ]
[ AS { group | role } ]
Como a sintaxe completa não é muito amistosa, vamos utilizar alguns exemplos para ilustrar a utilização
do comando GRANT.
Exemplo 1: Garantir para o usuário SERVIDOR\user1 a permissão de selecionar novos registros e atualizar
os registros existentes, na tabela Clientes do Banco de Dados Exemplo1:
Use Exemplo1
GRANT SELECT, UPDATE ON Clientes
TO [SERVIDOR\user1]
Quando o login for um usuário do Windows, o nome deve vir entre colchetes, como no exemplo:
[SERVIDOR\user1]
Podemos atribuir mais do que uma permissão ao mesmo tempo, para um ou mais logins ou usuários.
Exemplo 2: Garantir para os usuários SERVIDOR\user1 e SERVIDOR\user2 a permissão de selecionar

novos registros, atualizá-los e excluí-los, na tabela Clientes do Banco de Dados Exemplo1:
Use Exemplo1
GRANT SELECT, UPDATE, DELETE ON Clientes
TO [SERVIDOR\user1], [SERVIDOR\user2]
Exemplo 3: Atribuir todas as permissões para o usuário SERVIDOR\user2, na tabela Clientes do Banco
de Dados Exemplo1.
USE Exemplo1
GRANT ALL ON Clientes
TO [SERVIDOR\user2]

NOTA
Para uma descrição completa, de todas as opções do comando GRANT, consulte o tópico Transact SQL Reference, no Books OnLine.
Para retirar (revoke) as permissões de objetos do Banco de Dados utilize o comando REVOKE.
Sintaxe para o comando REVOKE:
REVOKE [ GRANT OPTION FOR ]

{
}
{ TO | FROM }
security_account [ ,...n ]
[ CASCADE ]
[ AS { group | role } ]
do comando REVOKE.
Exemplo 1: Retirar a permissão UPDATE, atribuída para o usuário SERVIDOR\user1, anteriormente.
USE Exemplo1
REVOKE UPDATE ON Clientes
TO [SERVIDOR\user1]
Podemos retirar mais do que uma permissão ao mesmo tempo, para um ou mais usuários.
Exemplo 2: Retirar as permissões SELECT, UPDATE E DELETE, atribuídas para o usuário SERVIDOR\user1
na tabela Clientes do Banco de Dados Exemplo1.
USE Exemplo1
REVOKE SELECT, UPDATE, DELETE ON Clientes
TO [SERVIDOR\user1]
Exemplo 3: Retirar todas as permissões atribuídas ao usuário SERVIDOR\user2, na tabela Clientes do

USE Exemplo1
REVOKE ALL ON Clientes
TO [SERVIDOR\user2]
Para negar (negar) as permissões de objetos do Banco de Dados utilize o comando DENY.
Sintaxe para o comando DENY:
DENY
{
}
[ CASCADE ]
do comando DENY.
Exemplo 1: Negar permissão UPDATE, para o usuário SERVIDOR\user1, na tabela Clientes, do Banco
de Dados Exemplo1.
USE Exemplo1
DENY UPDATE ON Clientes
TO [SERVIDOR\user1]
Podemos negar mais do que uma permissão ao mesmo tempo, para um ou mais usuários.
Exemplo 2: Negar as permissões SELECT, UPDATE E DELETE, para o usuário SERVIDOR\user1, na

tabela Clientes do Banco de Dados Exemplo1.
USE Exemplo1
DENY SELECT, UPDATE, DELETE ON Clientes
TO [SERVIDOR\user1]
Exemplo 3: Negar todas as permissões atribuídas ao usuário SERVIDOR\user2, na tabela Clientes do

USE Exemplo1
DENY ALL ON Clientes
TO [SERVIDOR\user2]
Observe que utilizamos a palavra ALL, para significar todas as permissões. Na Figura 6.35, temos a
janela com as permissões da tabela Clientes, após a execução do comando do Exemplo 3:
Figura 6.35 Todas as permissões negadas para SERVIDOR\user2.
Observe que todas as permissões foram negadas para o usuário SERVIDOR\user2, com exceção de
permissões tais como Alter, Control, Take Ownership e outras, as quais não se aplicam a tabelas, e sim
a outros objetos de um Banco de Dados, tais como views e stored procedures.
E para finalizar, mais um pequeno exercício.
Exercício: Considerando a situação descrita na Figura 6.36, determine as permissões efetivas para os
usuário user1, user2, user3, user4 e user5, na tabela Produtos do Banco de Dados Exemplo1.
Figura 6.36 Determine as permissões efetivas para cada usuário.
Observe que, à medida que novas permissões vão sendo atribuídas, pode ser difícil determinar o real
nível de acesso de cada usuário, a cada objeto, de cada um dos Bancos de Dados. Para que você possa
manter um controle sobre a atribuição de permissões, faço as seguintes sugestões:
♦ Mantenha uma documentação sobre as atribuições de permissão. É chato? É. Ninguém gosta?

Ninguém gosta. Porém a documentação é de fundamental importância, pois, se não tivermos
um controle sobre as atribuições de permissão, podemos chegar a situações onde usuários que
não devem ter acesso estão tendo e usuários que devem ter acesso não estão tendo. Enfim, uma
grande bagunça.
♦ Procure sempre atribuir permissões a roles e não aos usuários individualmente. Isto facilita
bastante a administração das permissões.
TRABALHANDO COM SCHEMAS

No início do capítulo, onde eu falei sobre as novidades na parte de segurança do SQL Server 2005, em
relação às versões anteriores do SQL Server, eu salientei que uma das principais mudanças era a separação
que foi feita entre usuários e schemas. Também mostrei as vantagens desta separação, onde não existe
mais o conceito de dono dos objetos de um Banco de Dados, tais como tabelas, views e stored proce-
dures. No SQL Server 2005, todos os objetos pertencem a um schema e temos o dono do schema e não
mais o dono dos objetos.
Neste tópico, mostrarei as ações práticas para trabalhar com schemas, usando o SQL Server Manage-
ment Studio. Você aprenderá a executar as seguintes ações:
♦ Criar novos schemas
♦ Atribuir objetos a um schema
♦ Alterar o dono de um schema
Exemplo1: Os schemas são criados dentro de um Banco de Dados. Neste exemplo, vamos criar um
schema chamado Produção, dentro do Banco de Dados Exemplo1, da instância SERVIDOR\SQL2005.
Para criar o schema Produção, no Banco de Dados Exemplo1, da instância SERVIDOR\SQL2005, siga
os passos indicados a seguir:
2. Na janela Object Explorer, navegue até o Banco de Dados Exemplo1, da instância

SERVIDOR\SQL2005.
3. Clique no sinal de + ao lado de Exemplo1, para exibir as opções disponíveis. Os schemas fazem
parte da opção Security.
4. Clique no sinal de + ao lado da opção Security, para exibir as opções disponíveis. Observe que
uma das opções disponíveis é Schemas.
5. Clique no sinal de + ao lado da opção schemas e observe a lista de schemas já definidos, no

Banco de Dados Exemplo1, conforme indicado na Figura 6.37.
6. Clique com o botão direito do mouse na opção schemas e, no menu de opções que é exibido,
clique em New schema.
7. Será aberta a janela schema – New. No campo Name digite Produção e, para dono deste schema,
vamos selecionar a role Gerentes. No campo schema Owner digite Gerentes. Sua tela deve estar
8. Clique em OK e pronto, o novo schema Produção terá sido criado no Banco de Dados Exemplo1,
sendo o dono deste schema a role Gerentes.
Figura 6.37 schemas existentes no Banco de Dados Exemplo1.
Figura 6.38 Criando o novo schema Produção.
Após criar um schema você poderá criar novos objetos e adicioná-los a este schema, poderá alterar as
propriedades dos objetos já existentes, para que passem a fazer parte deste schema e poderá atribuir
permissões de acesso, diretamente ao schema.
Ao criar um novo objeto, como por exemplo uma nova tabela, você pode definir a qual schema a tabela
irá pertencer. O SQL Server 2005 atribuirá o novo objeto que está sendo criado, ao schema definido como
Default schema, para o usuário logado. Na maioria dos casos, o Default schema é o schema dbo. Mas, na
hora da criação de um objeto, você pode definir a qual schema o objeto irá pertencer.
Por exemplo, para criar uma nova tabela, você navega até a opção Tabelas, do Banco de Dados onde a
tabela será criada, clica com o botão direito do mouse na opção Tables e, no menu de opções que é exibido,
clica na opção New Table. Será aberta a janela para criação de novas tabelas, janela esta que você aprendeu
a utilizar no Capítulo 4. A definição de a qual schema irá pertencer a tabela é feita na janela Propriedades.
Se a janela Propriedades não estiver sendo exibida, tecle F4 para exibir a janela propriedades. Na janela de
propriedades, na lista schema, você seleciona o schema ao qual irá pertencer a tabela que está sendo criada,
conforme exemplo da Figura 6.39, onde estou selecionando o schema Produção.
Figura 6.39 Selecionando o schema ao qual irá pertencer a tabela Vendas.
Após salvar e fechar a janela de criação da tabela, ela será exibida, na lista de tabelas do Banco de
Dados, com o nome Produção.Vendas, ou seja, seguindo o padrão: Nome_do_Schema.Nome_da_Tabela,
conforme exemplo da Figura 6.40:
Figura 6.40 A tabela Vendas do schema Produção.
No início do capítulo, quando falei sobre as vantagens da separação entre schemas e users, falei que
uma das principais vantagens é que podíamos alterar o dono de um schema e isso não mudaria o
nome completo para acessar os objetos que pertencem ao schema, pois o que estava mudando era
apenas o dono e não o nome do schema. Isso não ocorria nas versões anteriores do SQL Server, porque
não havia esta separação entre usuários e schemas. Ao mudar o dono de um schema, mudava também
o seu nome, o que poderia causar enormes transtornos, tais como aplicações tendo que ser alteradas,
com alteração no código das aplicações, para atualizar o nome dos objetos que mudaram devido a
mudança no dono de um ou mais schemas.
Alterar o dono de um schema é um processo muito simples, no SQL Server 2005. Basta abrir o SQL
Server Management Studio e localizar o schema a ser alterado. Dê um clique duplo no schema, para
abrir a janela de Propreidades do schema. Na janela de propriedades, na guia Geral, no camo schema
Owner, basta digitar o nome do novo dono (que pode ser um usuário ou uma role) e clicar em OK.
Pronto, o dono do schema foi alterado, sem causar nenhuma alteração no nome completo dos objetos
pertencentes ao schema. Todas as aplicações que utilizavam os objetos do schema continuam
funcionando, normalmente, sem nenhuma necessidade de alteração. Bem mais simples e prático do
que nas versões anteriores do SQL Server.
CONCLUSÃO
Neste capítulo tratamos, extensivamente, sobre a configuração de segurança no acesso ao servidor e
aos dados de um servidor SQL Server 2005. Também apresentamos os conceitos básicos sobre usuários
e grupos no Windows 2000 Server e Windows Server 2003.
Aprendemos que existem dois modos de autenticação:
♦ Windows Authentication mode.
♦ SQL Server and Windows Authentication mode.
Em seguida nós vimos que existem diversos estágios a serem vencidos até que o usuário possa ter
acesso aos dados.
O primeiro estágio é estar cadastrado com um login no SERVIDOR\instância. Para gerenciar logins,
utilizamos a opção Logins, a qual está dentro da opção Security, em cada instância.
O segundo estágio é estar cadastrado na lista de usuários com permissão de acesso ao Banco de Dados.
Cada Banco de Dados possui a sua própria lista de usuários. Para gerenciar usuários, utilizamos a opção
Security -> Users, do Banco de Dados.
O estágio final é dar as devidas permissões de acesso, tanto em nível do Banco de Dados, quanto em
nível dos objetos do Banco de Dados. As permissões em nível de Banco de Dados definem quem pode
criar novos objetos, alterar os objetos existentes ou até mesmo excluir objetos. Já as permissões em
nível de objeto definem o nível de acesso aos dados, por exemplo somente leitura (SELECT), alteração
(UPDATE) e assim por diante.
Falamos bastante sobre o papel das roles e a sua semelhança de funcionalidade com os grupos do
Windows 2000 e Windows Server 2003.
Aprendemos a realizar as tarefas utilizando as seguintes ferramentas:
♦ Comandos T-SQL, na janela de execução de comandos.
Sei que o capítulo foi longo, mas não poderia ser diferente, devido à grande importância do assunto
segurança.
Capítulo 7
ADMINISTRANDO, MONITORANDO E
OTIMIZANDO O SQL SERVER 2005
INTRODUÇÃO
Nos capítulos anteriores aprendemos a criar Bancos de Dados, tabelas e índices. Também aprendemos
a fazer o backup e o restore de Bancos de Dados. No Capítulo 6 aprendemos a configurar a segurança
no SQL Server 2005 e a integração com a segurança do Windows. Agora, já temos um Banco de
Dados configurado e razoavelmente seguro. Porém existe uma série de outras tarefas que devem ser
executadas para garantir, além da disponibilidade e segurança, o desempenho e a confiabilidade do
Banco de Dados.
Neste capítulo aprenderemos a utilizar uma série de ferramentas que auxiliam o DBA a administrar,
monitorar e otimizar os Bancos de Dados de uma ou mais instâncias do servidor SQL Server 2005.
Iniciaremos o capítulo aprendendo a criar um “Plano de Manutenção” para o Banco de Dados. Iremos
criar este plano de manutenção utilizando o assistente Maintenance Plan.
Depois aprenderemos a utilizar os chamados comandos DBCC – Database Consistency Checker. Estes
comandos são utilizados para efetuar uma série de verificações de consistência em um Banco de Dados;
em resumo, nos ajudam a diagnosticar e corrigir problemas que possam existir nas tabelas e índices do
banco de dados. Com isso, trabalhamos de maneira proativa, procurando nos antecipar aos problemas,
antes mesmo que eles aconteçam.
Também aprenderemos a importar dados para uma tabela do Banco de Dados e exportar dados do
SQL Server para fontes externas. Continuaremos o capítulo aprendendo a utilizar o DTS – Data
Transformation Services. Na verdade, DTS é o nome da ferramenta que coordena o acesso a diversas
fontes de dados no SQL Server 2000. No SQL Server 2005 esta ferramenta é bem mais poderosa e
mais fácil de utilizar.
Esta é uma ferramenta que permite a integração entre fontes de dados nos mais diversos formatos,
através da tecnologia OLE-DB. Por exemplo, podemos consolidar nas tabelas de um Banco de Dados
do SQL Server 2005 dados originados do mainframe, combinados com dados do Microsoft Access e
dados do DB2 da IBM. Ou, quem sabe, para misturar um pouco mais, vamos também adicionar dados
de uma planilha do Excel e de um Banco de Dados no formato Dbase (.dbf). Esta integração é possível,
graças ao Business Intelligence Development Studio, que é como é conhecido todo o ambiente do
DTS, no SQL Server 2005. Mas o mais interessante é que não estamos limitados a integrar dados de
fontes diversas, também podemos transformá-los (T de Transformation).
Na continuação aprenderemos a utilizar uma ferramenta de monitoração de performance do

Windows 2000 Server/Windows Server 2003: o console Desempenho. Através deste console
NOTA
podemos medir o desempenho de uma série de objetos/contadores relacionados com o SQL Server
2005. Por exemplo, podemos determinar o número de transações por segundo, o número de
logins por segundo, etc. Vamos fazer alguns exemplos práticos para aprender a utilizar este con-
sole. O console Desempenho pode ser utilizado para monitorar o desempenho de uma série de
objetos/contadores, não estando limitado a objetos/contadores do SQL Server 2005. Assim,
podemos, por exemplo, monitorar o uso de recursos críticos para o servidor Windows, tais como
a utilização do processador, da memória RAM e das operações de I/O de disco. Porém, neste
capítulo nos limitaremos à análise de desempenho dos objetos/contadores relacionados com o
SQL Server 2005.
CAPÍTULO 7 – ADMINISTRANDO, MONITORANDO E OTIMIZANDO O SQL SERVER 2005
NOTA
Explicarei em detalhes o conceito de objetos/contadores na seção sobre desempenho.
A próxima e última ferramenta a ser analisada neste capítulo é o Profiler. Esta ferramenta permite a
monitoração das atividades de cada instância do servidor SQL Server 2005, separadamente. Também
podemos monitorar as atividades de Banco de Dados. Além de monitorar, a atividade pode ser salva e
depois executada novamente contra o Banco de Dados. Também podemos salvar os dados capturados
em uma tabela, em um arquivo ou em um Script SQL.
KNOW-HOW EM: CRIAÇÃO DE UM PLANO DE MANUTENÇÃO

PARA UM BANCO DE DADOS DO SQL SERVER 2005
PRÉ-REQUISITOS
♦ Fundamentos sobre segurança no SQL Server 2005.
♦ Saber utilizar o Enterprise Manager.
METODOLOGIA
♦ Apresentação dos passos necessários para a criação de um plano de manutenção.
TÉCNICA
♦ Criação de um plano de manutenção utilizando o SQL Server Management Studio.
Um plano de manutenção define uma série de tarefas que devem ser executadas no Banco de Dados
para garantir o bom funcionamento do banco, com bom desempenho e garantia de disponibilidade
dos dados, através de uma estratégia adequada de backup/restore. Com o plano de manutenção também
são definidas as tarefas de backup para evitar a perda de informações, além de tarefas que verificam a
integridade dos objetos do Banco de Dados. Esta série de tarefas pode ser criada de uma maneira
consolidada, através da utilização da criação de um plano de manutenção (Maintenance Plan).
Você pode criar um plano de manutenção manualmente, mas a maneira mais fácil e prática é criarmos
um plano de manutenção do Banco de Dados, utilizando o assistente Maintenance Plan Wizard. Este
assistente, ao ser executado, cria e agenda para execução periódica vários jobs, sendo que cada job
executa uma determinada tarefa. Os jobs, criados pelo assistente Database Maintenance Plan Wizard,
executam as seguintes tarefas:
♦ Reorganizam os dados nas páginas de dados e índices através da reconstrução dos índices com
um novo valor para o parâmetro Fill Factor. Isto garante uma melhor distribuição dos dados,
com uma melhora no desempenho. Para maiores informações sobre o parâmetro Fill Factor,
consulte o Capítulo 4.
♦ Fazem a compactação do Banco de Dados, removendo páginas de dados que estão vazias.
♦ Atualizam uma série de informações sobre os índices do Banco de Dados. Estas informações
são chamadas de “Indexes Statistics”. Com essa atualização, o SQL Server 2005 tem condição
de tomar melhores decisões na hora de executar uma consulta. O resultado final é um
desempenho bem melhor.
♦ Fazem uma verificação interna na consistência dos dados, para certificar-se de que os dados
não estão corrompidos ou em um estado inconsistente.
♦ Agendam o backup do Banco de Dados e do log de transações. Além disso, podemos configurar
um período durante o qual os backups deverão ser mantidos. Porém, para manter um histórico
dos backups, devemos levar em consideração as necessidades de armazenamento e mídias, no
caso de estarmos efetuando o backup em fita magnética.
NOTA
A replicação de dados pode também ser utilizada para manter cópias idênticas dos dados em dois ou mais servidores. Aprenderemos sobre
replicação no Capítulo 8. No Capítulo 14 aprenderemos sobre novos recursos do SQL Server 2005, os quais também podem ser utilizados
para duplicação de dados, tais como Database Snapshot e Database Mirror.
Para que você possa criar um plano de manutenção, usando o Maintenance Plan Wizard, o login que
você está utilizando deve ser um membro da seguinte role: MaintenanceUserRole. Evidentemente que,
por padrão, a conta sa tem estas permissões, bem como todas as contas pertencentes ao grupo
Administradores, do Windows. Você pode atribuir a permissão de criar planos de manutenção para
qualquer login. Para isso, basta navegar até a opção Security, da instância a ser configurada, expandir
a opção Logins, clicar com o botão direito do mouse no login a ser configurado e, no menu de opções
que é exibido, clicar em Propriedades. Será aberta a janela de propriedades do login, com a guia Gen-
eral selecionada por padrão. Clique na guia Database Access. Na lista Databases acessible by this login,
marque o banco de dados msdb. Na lista Database roles for: msdb, na parte de baixo da janela, marque
a role MaintenanceUserRole e clique em OK. Pronto, o login foi configurado, com permissão de criar
um plano de manutenção, usando o assistente.
Agora vamos aprender a criar um plano de manutenção, utilizando o Maintenance Plan Wizard, ou
melhor, o Assistente de Plano de Manutenção.
Exemplo prático: Para criar um plano de manutenção para o Banco de Dados AdventureWorks, da
instância SERVIDOR\SQL2005, siga os passos indicados a seguir:
1. Abra o SQL Server Management Studio (Iniciar -> Programas -> Microsoft SQL Server 2005 ->
SQL Server Management Studio).

+, ao lado desta instância, para exibir as opções disponíveis.
3. Nas opções que surgem, dê um clique no sinal de + ao lado da opção Management, para exibir
as opções disponíveis.
4. Dentre as opções que são exibidas, clique com o botão direito do mouse na opção Mainte-
nance Plans. No menu que surge, clique na opção Maintenance Plan Wizard.
5. Será exibida a tela inicial do assistente, com uma mensagem informando sobre o que pode ser
feito com o assistente. Dê um clique no botão Next, seguindo para a próxima etapa. Surgirá a
tela indicada na Figura 7.1.
Figura 7.1 Definindo a instância do SQL Server 2005, na qual será criado o plano.
6. Nesta etapa você define em qual instância do SQL Server 2005 será criado o plano de
manutenção. Por padrão, vem selecionada a instância dentro da qual estava a opção Manage-
ment -> Maintenance Plans, na qual você clicou com o botão direito do mouse. Vamos aceitar
a instância sugerida, pois é exatamente nesta que queremos criar um plano de manutenção.
Dê um clique no botão Next, seguindo para a próxima etapa do assistente.
7. Nesta etapa você define quais tarefas farão parte do plano de manutenção. Por padrão, vêm
selecionadas todas as tarefas: Chek database integrity, Shrink database, Defragment index(es),
Re-index, Update statistics, History cleanup, Launxh SQL Server agent job, Backup database
(full), Backup database (Differential) e Backup database (Transaction Log). Deixe todas as opções
marcadas, com exceção da opção Backup database (Differential). Dê um clique no botão Next,
seguindo para a próxima etapa do assistente.
8. Nesta etapa você define a ordem em que as tarefas serão executadas. Para alterar a ordem, você
marca uma determinada tarefa e clica no botão Move up, para movê-la para cima na lista, ou
Move down, para movê-la para baixo na lista. Não vamos alterar a ordem sugerida. Dê um
clique no botão Next, seguindo para a próxima etapa do assistente.
9. Abra a lista Select one or more. Ao abrir esta lista, serão disponibilizadas diversas opções. Nesta
etapa podemos definir se o plano de manutenção incluirá todos os Bancos de Dados da instância
(All databases), ou apenas os do sistema (All system databases (master, model, and msdb)), ou
se incluirá todos os Bancos de Dados do usuário (All user databases (all databases other than
master, model, and msdb)) ou apenas os selecionados (These specific databases). A opção These
specific databases já vem selecionada por padrão. Na lista de Bancos de Dados podemos
selecionar aqueles que queremos incluir no plano de manutenção.
No nosso exemplo iremos incluir apenas o Banco de Dados AdventureWorks.
Certifique-se de que o Banco de dados AdventureWorks esteja selecionado na lista de Bancos de Dados.
Sua janela deve estar semelhante à indicada na Figura 7.2:
Figura 7.2 Selecionando o banco de dados AdventureWorks.
10. Clique em OK para fechar a lista de opções e certifique-se de que a opção Include indexes,
esteja selecionada, para garantir que a otimização dos índices do banco de dados AdventureWorks
seja incluída no plano de manutenção. Dê um clique no botão Avançar para ir para a próxima
11. Nesta etapa, definiremos para quais bancos de dados serão criadas tarefas de otimização. Abra
a lista Select one or more. Ao abrir esta lista, serão disponibilizadas diversas opções, já descritas
anteriormente. A opção These specific databases já vem selecionada por padrão. Na lista de
Bancos de Dados podemos selecionar aqueles que queremos incluir no plano de manutenção.
No nosso exemplo iremos incluir apenas o Banco de Dados AdventureWorks. Certifique-se de
que o Banco de dados AdventureWorks esteja selecionado na lista de Bancos de Dados. Clique
em OK para fechar a lista de opções. Ao selecionar um banco de dados, serão habilitadas as
porções de otimização e recuperação de espaço. Aceite as configurações sugeridas e dê um
clique no botão Next para ir para a próxima etapa do assistente.
12. Nesta etapa podemos definir uma série de configurações a respeito da otimização dos índices e
das páginas de dados do Banco de Dados. Nesta etapa você tem três listas de opções. Na primeira
lista você pode ver quais bancos de dados serão incluídos no plano de manutenção, para terem
os índices de suas tabelas e views desfragmentados. Abra a primeira lista (Database(s):) e selecione
somente o banco de dados AdventureWorks. Na segunda lista (Object), você seleciona a opção
Table – para otimizar somente os índices das tabelas, ou a opção View, para otimizar somente
os índices das views, ou a opção Tables and Views, para otimizar os índices tanto das tabelas
quanto das views. Selecione a opção Tables and Views. Ao selecionar a opção Table and Views,
automaticamente, serão selecionadas todas as tabelas e views. Se você selecionar uma opção
individual, como por exemplo Table, na terceira lista, você poderá marcar somente determinadas
tabelas, para ter os índices otimizados. Com as opções selecionadas, sua janela deve estar
semelhante à indicada na Figura 7.3.
Figura 7.3 Definindo otimizações dos índices.
13. Dê um clique no botão Next para ir para a próxima etapa do assistente.
14. Nesta etapa você seleciona para quais bancos de dados serão criadas tarefas, que irão recriar os
índices, quando as tarefas forem executadas. As três primeiras listas têm funcionamento idêntico
às três listas da Figura 7.3. Na primeira lista você marca um ou mais bancos de dados, na
segunda lista você seleciona as opções Table, Views ou Tables and Views e, na terceira lista, os
objetos, individualmente, dependendo de qual opção foi selecionada na segunda lista. Esta
tela tem uma série de opções avançadas, que somente um DBA experiente deverá alterar, ou
seja, somente altere estas opções se você conhecer exatamente o que está fazendo. Para o nosso
exemplo, na primeira lista, selecione o banco de dados AdventureWorks e, na segunda lista,
selecione a opção Tables and Views. Mantenha as demais opções desta etapa inalteradas. Dê
um clique no botão Next para ir para a próxima etapa do assistente.
15. Nesta etapa você seleciona para quais bancos de dados serão criadas tarefas, para atualizar as
estatísticas das tabelas e views, quando as tarefas forem executadas. As três primeiras listas têm
funcionamento idêntico às três listas da Figura 7.3. Na primeira lista você marca um ou mais
bancos de dados, na segunda lista você seleciona as opções Table, Views ou Tables and Views e,
na terceira lista, os objetos, individualmente, dependendo de qual opção foi selecionada na
segunda lista. Para o nosso exemplo, na primeira lista, selecione o banco de dados AdventureWorks
e, na segunda lista, selecione a opção Tables and Views. Mantenha as demais opções desta etapa
inalteradas. Dê um clique no botão Next para ir para a próxima etapa do assistente.
16. Nesta etapa você seleciona quais opções de históricos serão limpas, quando as tarefas do
plano de manutenção forem executadas e a periodicidade com que estas tarefas (específicas
para limpeza dos históricos) devem ser executadas. Nesta etapa, você pode marcar as opções
Backup and Restory history, SQL Server Agent Job history e Database Maintenance Plan
History. Por padrão, estas três opções vêm selecionadas. Na parte de baixo da janela, você
define quais dados devem ser excluídos do histórico. Por padrão, vem selecionada a opção 4
Week(s), significando que serão criadas tarefas, no plano de manutenção, para excluir dados
que tenham sido gravados a mais de quatro semanas, nos históricos selecionados. Nesta
etapa vamos aceitar as configurações padrão, indicadas na Figura 7.4. Dê um clique no botão
Next para ir para a próxima etapa do assistente.
Figura 7.4 Definindo opções para limpar dados dos históricos.
17. Nesta etapa são exibidos os jobs já existentes, criados anteriormente. Você pode marcar um ou
mais jobs para serem executados, também como parte do plano de manutenção. No nosso
exemplo, incluiremos todos os jobs já existentes, como parte do plano de manutenção.
Certifique-se de que todos os jobs estejam selecionados. Dê um clique no botão Next para ir
18. Nesta etapa você irá definir para quais bancos de dados serão criadas tarefas de backup, como
parte do plano de execução. Abra a lista Databases e, abaixo da opção These specific databases,
marque o banco de dados AdventureWorks e clique em OK. As demais opções serão habilitadas.
Você pode definir se o backup será feito em disco ou em fita, em qual pasta será feito o backup
(no caso de um backup em disco), se os backups já existentes devem ser sobrescritos ou não e
assim por diante. Defina as opções desejadas e clique em Next, para seguir para a próxima
19. Nesta etapa você pode criar tarefas que farão o backup diferencial de um ou mais bancos de
dados. Vamos incluir um backup diferencial do banco de dados AdventureWorks, como
parte do plano de manutenção. Na lista Database(s):, selecione o banco de dados
AdventureWorks e clique em OK. Aceite as demais opções e clique em Next, para seguir
20. Nesta etapa você pode criar tarefas que farão o backup do log de transações de um ou mais
bancos de dados. Vamos incluir um backup do log do banco de dados AdventureWorks, como
parte do plano de manutenção. Na lista Database(s):, selecione o banco de dados
AdventureWorks e clique em OK. Aceite as demais opções e clique em Next, para seguir para a
21. Nesta etapa você pode definir uma conta conhecida como Proxy Account. Se for
configurada uma conta como Proxy Account, as tarefas serão executadas no contexto
desta conta, ou seja, a conta configurada como Proxy Account deverá ter todas as
permissões necessárias para executar as tarefas do plano de manutenção. Para o nosso
exemplo, não irei configurar uma conta como Proxy Account. Clique em Next, para seguir
22. Nesta etapa você define em qual pasta será gravado um relatório sobre o plano de manutenção.
Por padrão vem selecionado C:\. Vamos aceitar as configurações sugeridas. Clique em Next,
para seguir para a próxima etapa do assistente.
23. Será exibida a tela final do assistente. Se você precisar alterar alguma opção, utilize o botão
Back. Para finalizar o assistente e criar o plano de manutenção, clique em Finish. O SQL
Server 2005 mostrará o progresso da criação do plano de manutenção, conforme indicado
na Figura 7.5.
24. Uma vez concluída a criação do plano de manutenção, será exibida a janela com o resultado da
criação. Clique em Close para fechar esta janela. Pronto, o plano de manutenção foi criado.
Figura 7.5 Progresso da criação do plano de manutenção.
Você pode alterar um plano de manutenção quando for necessário. Para isso basta localizar o plano de
manutenção, clicar com o botão direito do mouse no mesmo, e no menu que surge, clicar em Modify.
Na Figura 7.6 temos a janela de propriedades do plano de manutenção criado neste exemplo. Observe
que, bem no lado esquerdo da tela, é exibido o painel Maintenance Tasks. Neste painel, é exibida a lista
de tarefas que compõem o plano de manutenção.
No lado direito da tela, são exibidas as guias que dão acesso às propriedades do plano de manutenção.
Dê um clique na guia Subplan Editor. Observe que as diversas tarefas que compõem o plano de
manutenção são representadas na forma de um diagrama de blocos seqüencial, onde uma tarefa é
executada após a outra, conforme indicado na Figura 7.7.
Você pode, facilmente, acessar os comandos T-SQL associados a cada uma das tarefas. Por exemplo,
clique na primeira tarefa – Check database, para selecioná-la. Estando o retângulo da primeira tarefa
selecionado, clique com o botão direito do mouse nele e, no menu de opções que é exibido, clique em
Edit. Será aberta a janela de propriedades da tarefa. Clique no botão View T-SQL. Serão exibidos os
comandos T-SQL que serão executados, quando a tarefa for executada. Clique em Close para fechar a
janela de comandos T-SQL. Clique em OK para fechar a janela de propriedades do job.
Para fazer com que todas as tarefas do plano de manutenção sejam executadas, imediatamente, basta
clicar no plano de execução com o botão direito do mouse e, no menu de opções que é exibido, clicar
em Execute. Para acessar o histórico de execução, clique com o botão direito do mouse e, no menu de
opções que é exibido, clique em View History.
Figura 7.6 Propriedades do plano de manutenção.
Figura 7.7 Podemos ver os diversos jobs criados pelo plano de manutenção.
O assistente para criação de um plano de manutenção é um bom auxiliar para ajudar na criação de
planos de manutenção básicos. Claro que, depois que você já for um DBA mais experiente, mais rodado,
você, provavelmente, utilizará o assistente apenas como um ponto de partida. Depois, com base na sua
experiência, irá personalizar as tarefas criadas pelo assistente e, até mesmo, criar novas tarefas.
KNOW-HOW EM: COMANDOS DBCC – DATABASE CONSISTENCY CHECKER

PRÉ-REQUISITOS
♦ Noções sobre o log de transações.
METODOLOGIA
♦ Apresentação dos principais comandos DBCC.
No SQL Server 2005, através da linguagem T-SQL, temos uma série de comandos para manutenção e
otimização de tabelas e índices, comandos estes conhecidos como “comandos DBCC”. Este grupo de
comandos é conhecido como “comandos DBCC”, porque todos iniciam com o prefixo DBCC. A grande
maioria destes comandos é utilizada para verificação da consistência física e lógica de um Banco de
Dados e de seus elementos, tais como tabelas e índices. Em muitas situações, o comando, além de fazer
a verificação, é capaz de corrigir os problemas encontrados.
Podemos dividir os comandos DBCC em quatro categorias, conforme descrito na Tabela 7.1.
Vamos estudar os principais comandos em cada uma destas categorias.
Tabela 7.1 Categorias para os comandos DBCC.
Categoria Descrição
Manutenção Executam tarefas de manutenção do Banco de Dados, índices e filegroups.

Status Fazem a verificação de variáveis do Banco de Dados.
Validação Fazem a validação de determinadas operações no Banco de Dados, em índices, tabelas, catálogos,
filegroups, tabelas do sistema e alocação de páginas de dados.
Diversos Executam uma série de operações variadas.
PRINCIPAIS COMANDOS DBCC DE MANUTENÇÃO

COMANDO DBCC DBREINDEX
Utilizamos este comando para reconstruir um ou mais índices em uma tabela de um Banco de Dados.
Sintaxe conforme Books OnLine:
DBCC DBREINDEX
( [ ‘database.owner.table_name’
[ , index_name
[ , fillfactor ]
]
]
) [ WITH NO_INFOMSGS ]
Na nossa missão de simplificar a sintaxe e o entendimento dos comandos da linguagem T-SQL, vamos
a alguns exemplos práticos. Porém, antes dos exemplos, vamos fazer algumas observações a respeito
deste comando:
♦ Não podemos utilizar este comando em tabelas do sistema (master, msdb, etc.).
♦ Por padrão, somente a role de servidor sysadmin e as roles de Banco de Dados db_owner e
db_ddladmin têm permissão para executar este comando.
♦ É mais vantajosa a utilização do comando DBCC DBREINDEX do que a utilização dos comandos
DROP INDEX e CREATE INDEX. Por exemplo, em uma tabela com diversos índices, podemos
utilizar o comando DBCC DBREINDEX para reconstruir todos os índices de uma única vez, ao
invés de utilizar vários comandos DROP INDEX e CREATE INDEX, um para cada índice. Além
disso, o comando DBCC DBREINDEX é executado com sucesso ou falha como um todo, ou
seja, atende o conceito de Atomicidade.
Vamos a alguns exemplos práticos.
Reconstruir o índice UPKCL_auidind, da tabela authors do Banco de Dados pubs.
Use pubs
DBCC DBREINDEX (‘authors’, UPKCL_auidind, 50)
Observe que o nome da tabela vai entre apóstrofos e o nome do índice, não. O terceiro parâmetro é a
definição para o FILL FACTOR, que, conforme descrevemos no Capítulo 4, é uma medida para o
percentual de espaço a ser deixado em branco, nas páginas do Banco de Dados, quando da construção
do índice.
Para reconstruir todos os índices de uma tabela, basta não especificar um nome para o índice; apenas
coloque dois apóstrofos, conforme indicado no exemplo a seguir, onde são reconstruídos todos os
índices da tabela titles do Banco de Dados pubs:
Use pubs
DBCC DBREINDEX (‘titles’, ‘ ‘, 60)
Importante: O comando DBCC DBREINDEX será descontinuado nas futuras versões do SQL Server. É
importante que você conheça este comando, para poder entender códigos e scripts já existentes, porém
não é recomendado que você utilize o comando DBCC DBREINDEX, na criação de novos scripts e
códigos. Ao invés do comando DBCC DBREINDEX, você deve utilizar o comando ALTER INDEX, o
qual descreverei logo a seguir.
COMANDO ALTER INDEX

Utilizamos este comando para alterar os índices de uma tabela ou view (quer seja de dados relacionais
ou no padrão XML). O comando ALTER INDEX pode ser utilizado para desabilitar um índice, reorganizar
ou recriar um índice. Este comando também pode ser utilizado para configurar opções de um índice.
Para poder executar o comando ALTER INDEX você deve ter, no mínimo, permissão de alteração
ALTER, na tabela ou view à qual pertence o índice que está sendo alterado. Esta permissão é garantida,
por padrão, para a role de servidor sysadmin e para as roles de banco de dados db_ddladmin e db_owner.
O comando ALTER INDEX não pode ser utilizado para particionar um índice ou para mover um índice
de um filegroup para outro. Este comando também não pode ser utilizado para alterar a definição de
um índice, tal como adicionar ou excluir colunas do índice ou alterar a ordem das colunas, no índice.
Para executar estas operações você deve executar o comando CREATE INDEX, com a opção DROP
EXISTING.
A seguir apresento alguns exemplos de uso do comando ALTER INDEX.
No exemplo a seguir, utilizo o comando ALTER INDEX, para recriar o índice NúmeroPedido_PK, da
tabela dbo.Pedidos, do banco de dados NorthWind.
USE NorthWind;
GO
ALTER INDEX NúmeroPedido_PK ON dbo.Pedidos
REBUILD;
GO
A seguir apresento um exemplo do Books Online, onde o comando ALTER INDEX é utilizado para
alterar diversas opções de um índice. Este comando define as opções STATISTICS_NORECOMPUTE,
IGNORE_DUP_KEY e ALLOW_PAGE_LOCKS, do índice:
USE AdventureWorks;
GO
ALTER INDEX AK_SalesOrderHeader_SalesOrderNumber ON
Sales.SalesOrderHeader
SET (
STATISTICS_NORECOMPUTE = ON,
IGNORE_DUP_KEY = ON,
ALLOW_PAGE_LOCKS = ON
) ;
GO
Daria para escrever um capítulo inteiro só sobre o comando ALTER INDEX. Mas nada do que eu possa
escrever aqui acrescentarei em relação ao que já tem no Books Online. Por isso, para uma referência
completa sobre todas as opções do comando ALTER INDEX e dezenas de outros exemplos de uso deste
comando, consulte o BOOKS ONLINE. Você verá que, na prática, todos os comandos DBCC que eram
utilizados para alterar índices podem ser substituídos pelas opções do comando ALTER INDEX.
COMANDO DBCC DBREPAIR

Este comando era utilizado, nas versões anteriores do SQL Server, para excluir um Banco de Dados
danificado. Este comando somente era fornecido para compatibilidade com versões anteriores do SQL
Server. Por exemplo, você pode ter criado stored procedures ou scripts que utilizam este comando e
que não iriam funcionar, sem alterações, no SQL SERVER 2002. No SQL Server 2005 não existe mais
suporte para este comando. Ao invés do comando DBCC DBREPAIR, você utiliza o comando DROP
DATABASE, já descrito no Capítulo 3.
COMANDO DBCC INDEXDEFRAG

Utilizamos este comando para desfragmentar Clustered e Secondary indexes de uma tabela. Este
comando também será descontinuado em futuras versões do SQL Server. Ao invés do comando DBCC
INDEXDEFRAG, você pode utilizar o comando ALTER INDEX, conforme mostrarei mais adiante.
DBCC INDEXDEFRAG
( { database_name | database_id | 0 }
, { table_name | table_id | ‘view_name’ | view_id }
, { index_name | index_id }
) [ WITH NO_INFOMSGS ]
Vamos simplificar a sintaxe e o entendimento dos comandos da linguagem T-SQL através de

alguns exemplos práticos. Porém, antes dos exemplos, vamos fazer algumas observações a respeito
deste comando:
♦ Não podemos utilizar este comando em tabelas do sistema (master, msdb, etc.).
♦ Este comando, além de desfragmentar os índices, compacta suas páginas, levando em conta o
valor original do parâmetro FILL FACTOR, quando da criação do índice.
Desfragmentar o índice UPKCL_auidind, da tabela authors do Banco de Dados pubs.
Use pubs
DBCC INDEXDEFRAG (pubs, authors, UPKCL_auidind)
Ao ser executado com sucesso, este comando informa, de 5 em 5 minutos, o andamento da

desfragmentação dos índices.
Observe que, simplificando a sintaxe, poderíamos colocar da seguinte maneira:
Use banco_de_dados
DBCC INDEXDEFRAG (banco_de_dados, tabela, índice)
COMANDO DBCC SHRINKDATABASE

Este comando é utilizado para que possamos reduzir o tamanho de um ou mais arquivos de dados de
um Banco de Dados.
DBCC SHRINKDATABASE
( database_name [ , target_percent ]
[ , { NOTRUNCATE | TRUNCATEONLY } ]
)
Para simplificar a sintaxe e o entendimento dos comandos da linguagem T-SQL, vamos a alguns exemplos
práticos. Porém, antes dos exemplos, vamos fazer algumas observações a respeito deste comando:
♦ Não podemos reduzir o tamanho de um Banco de Dados a menos do que o tamanho do Banco
de Dados model. Por exemplo, se o model tiver o tamanho de 5 MB, este será o menor tamanho
ao qual um Banco de Dados poderá ser reduzido.
♦ Por padrão, somente a role de servidor sysadmin e a role de Banco de Dados db_owner têm
permissão para executar este comando.
♦ Este comando não irá reduzir um arquivo do Banco de Dados a um tamanho menor do que o
tamanho dos seus dados. Por exemplo, se um arquivo de dados, primário ou secundário, contiver
7 MB em dados, este é o menor tamanho ao qual este arquivo poderá ser reduzido.
Reduzir o tamanho dos arquivos do Banco de Dados Exemplo1, mantendo um espaço livre de 25% em
cada arquivo.
Use Exemplo1
DBCC SHRINKDATABASE (Exemplo1, 25)
Ao ser executado com sucesso, este comando emite a seguinte mensagem:
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
O segundo parâmetro 25 indica o percentual de espaço livre que deve ser mantido, em cada arquivo de
dados, após a execução do comando. Por exemplo, um arquivo de dados possui 20 MB, dos quais 10
MB estão ocupados com dados. Após a execução do comando, serão mantidos, evidentemente, os 10
MB de dados, mais 2,5 MB (25%) de espaço livre. Na verdade o SQL Server irá arredondar para 13 MB.
Para os arquivos de log, o valor percentual de espaço livre é contabilizado como um todo e não para
cada arquivo individualmente. No nosso exemplo, após executado o comando, somando o tamanho
de todos os arquivos de log, o espaço livre seria de 25%.
Com o comando DBCC SHRINKDATABASE, podemos utilizar as opções NOTRUNCATE ou TRUNCATE

ONLY. A opção NOTRUNCATE faz com que o espaço liberado seja mantido no Banco de Dados e não
liberado para o sistema operacional. Já com a opção TRUNCATE ONLY, o espaço liberado é retornado para
o sistema operacional. A seguir, temos um exemplo de utilização da opção TRUNCATE:
Use Exemplo1
DBCC SHRINKDATABASE (Exemplo1, 25,NOTRUNCATE)
COMANDO DBCC SHRINKFILE

Utilizamos este comando para reduzir o tamanho de um arquivo de dados (primário ou secundário),
ou de um arquivo de log do Banco de Dados.
DBCC SHRINKFILE
( { file_name | file_id }
{ [ , target_size ]
| [ , { EMPTYFILE | NOTRUNCATE | TRUNCATEONLY } ]
}
)
Algumas observações a respeito deste comando:
♦ Não podemos reduzir o tamanho de um Banco de Dados a menos do que o tamanho do Banco
de Dados model. Por exemplo, se o model tiver o tamanho de 5 MB, este será o menor tamanho
ao qual qualquer Banco de Dados poderá ser reduzido.
♦ Por padrão, somente a role de servidor sysadmin e a role de Banco de Dados db_owner têm
permissão para executar este comando.
♦ Este comando não irá reduzir um arquivo do Banco de Dados a um tamanho menor do que o
tamanho dos seus dados. Por exemplo, se um arquivo de dados, primário ou secundário, contiver
7 MB em dados, este é o menor tamanho ao qual este arquivo poderá ser reduzido.
Reduzir o tamanho do arquivo primário de dados, do Banco de Dados Exemplo1 a 7 MB.
USE Exemplo1
DBCC SHRINKFILE (‘exemplo1-prim’, 7)
O segundo parâmetro 7 já indica o tamanho final do arquivo de dados, em MB. exemplo1-prim é o

nome lógico associado com o arquivo primário de dados.
Com o comando DBCC SHRINKFILE, podemos utilizar as opções NOTRUNCATE, TRUNCATE ONLY
ou EMPTYFILE. A opção NOTRUNCATE faz com que o espaço liberado seja mantido no Banco de
Dados e não liberado para o sistema operacional. Já com a opção TRUNCATE ONLY, o espaço liberado
é retornado para o sistema operacional. A opção EMPTYFILE migra todos os dados do arquivo
especificado, para outros arquivos de dados no mesmo Filegroup. Novos dados não poderão ser gravados
em um arquivo em que a opção EMPTYFILE foi especificada; com isso poderemos excluir o arquivo,
utilizando o comando ALTER DATABASE. A seguir, temos um exemplo de utilização da opção
EMPTYFILE. Depois utilizamos o comando ALTER DATABASE para excluir o arquivo:
USE Exemplo1
DBCC SHRINKFILE (‘exemplo1-sec1’,EMPTYFILE)
GO
REMOVE FILE ‘exemplo1-sec1’
COMANDO DBCC UPDATEUSAGE

Este comando informa e corrige erros nas informações e estatísticas sobre o espaço utilizado em disco.
Estes erros podem fazer com que o comando sp_spaceused retorne informações incorretas.
DBCC UPDATEUSAGE
( { ‘database_name’ | 0 }
[ , { ‘table_name’ | ‘view_name’ }
[ , { index_id | ‘index_name’ } ] ]
)
[ WITH [ COUNT_ROWS ] [ , NO_INFOMSGS ]
]
♦ Se não existirem problemas nas informações e estatísticas de uso de espaço em disco, este
comando não retornará nenhuma mensagem. Este comando tenta corrigir erros nas seguintes
colunas da tabela sysindexes: rows, used, reserved e dpages.
Utilizar o comando DBCC UPDATEUSAGE no Banco de Dados Northwind.
DBCC UPDATEUSAGE (‘Northwind’)
DBCC UPDATEUSAGE: sysindexes row updated for table ‘syscolumns’ (index ID 2):
USED pages: Changed from (4) to (5) pages.
RSVD pages: Changed from (8) to (10) pages.
DBCC UPDATEUSAGE: sysindexes row updated for table ‘syscolumns’ (index ID 1):
DBCC UPDATEUSAGE: sysindexes row updated for table ‘sysdepends’ (index ID 2):
DBCC UPDATEUSAGE: sysindexes row updated for table ‘Orders’ (index ID 4):
DBCC UPDATEUSAGE: sysindexes row updated for table ‘Order Details’ (index ID 2):
No exemplo do servidor que estou utilizando, este comando fez uma série de correções. Isto aconteceu porque fiz muitas alterações no Banco
NOTA
de Dados Northwind. Na verdade, como dizemos no dia-a-dia: “Fucei bastante neste Banco de Dados”. Ao rodar este comando em um Banco
de Dados que não foi muito alterado, é provável que não existam correções ou que as correções sejam mínimas. Mas, a título de exemplo,
foi uma feliz coincidência, uma vez que a mensagem mostra as diversas correções efetuadas por este comando.
PRINCIPAIS COMANDOS DBCC DE STATUS

COMANDO DBCC SHOWCONTIG
Este comando exibe informações sobre a fragmentação dos dados e dos índices de uma determinada
tabela.
DBCC SHOWCONTIG
[ ( { table_name | table_id | view_name | view_id }
[ , index_name | index_id ]
)
]
[ WITH { ALL_INDEXES
| FAST [ , ALL_INDEXES ]
| TABLERESULTS [ , { ALL_INDEXES } ]
[ , { FAST | ALL_LEVELS } ]
}
]
♦ DBCC SHOWCONTIG é utilizado para determinar o quão fragmentada está uma tabela. A
fragmentação ocorre devido a operações que alteram dados, como inserções, alterações e
exclusões. Estas modificações não são distribuídas de uma maneira uniforme entre as linhas da
tabela, de tal forma que as páginas de dados não apresentam um fator de preenchimento
homogêneo. Esta fragmentação pode prejudicar o desempenho de pesquisas realizadas nos
dados da tabela. A queda no desempenho pode ser pior ainda no caso de consultas que utilizam
uma ou mais cláusulas Join.
♦ Com o comando DBCC SHOWCONTIG, podemos utilizar as seguintes opções:
♦ WITH FAST: Determina que seja feita uma verificação rápida nos índices.
♦ WITH TABLERESULTS: Exibe os resultados da verificação em forma de tabela.
♦ WITH ALL_INDEXES: Efetua a verificação em todos os índices de uma tabela ou view.
♦ WITH ALL_LEVELS: Somente pode ser utilizada em conjunto com a opção TABLERESULTS.
Faz com que informações mais detalhadas, para cada nível dos índices, sejam retornadas
pelo comando DBCC SHOWCONTIG.
Utilizar o comando DBCC SHOWCONTIG para retornar informações sobre todos os índices de todas
as tabelas, do Banco de Dados Northwind.
USE Northwind
DBCC SHOWCONTIG WITH TABLERESULTS, ALL_INDEXES
Na Figura 7.8 são exibidas as primeiras linhas retornadas como resultado do comando anterior.
Figura 7.8 Execução do comando DBCC SHOWCONTIG com a opção ALL_INDEXES.
Também poderíamos retornar as informações sobre a fragmentação em uma única tabela, conforme o
exemplo a seguir, onde retornamos informações sobre a fragmentação na tabela Orders do Banco de
Dados Northwind:
USE Northwind
DBCC SHOWCONTIG (Orders)
Este comando irá retornar o seguinte resultado:
DBCC SHOWCONTIG scanning ‘Orders’ table...

Table: ‘Orders’ (21575115); index ID: 1, database ID: 6
TABLE level scan performed.
- Pages Scanned................................: 20
- Extents Scanned..............................: 5
- Extent Switches..............................: 4
- Avg. Pages per Extent........................: 4.0
- Scan Density [Best Count:Actual Count].......: 60.00% [3:5]
- Logical Scan Fragmentation ..................: 0.00%
- Extent Scan Fragmentation ...................: 40.00%
- Avg. Bytes Free per Page.....................: 146.5
- Avg. Page Density (full).....................: 98.19%
NOTA
Para maiores informações sobre o comando DBCC SHOWCONTIG e sobre os resultados retornados por este comando, consulte a referência da
linguagem T-SQL no Books OnLine.
COMANDO DBCC USEROPTIONS

Com este comando obtemos informações sobre as opções definidas para a conexão ativa com o Banco
de Dados. Por exemplo, quando acessamos a janela de execução de comandos T-SQL ou o SQL Server
Management Studio, estamos estabelecendo uma conexão com uma instância do servidor SQL Server
2005. O comando DBCC USEROPTIONS retorna uma série de informações sobre esta conexão.
DBCC USEROPTIONS
NOTA
Qualquer usuário tem permissão para executar este comando.
Exemplo:
DBCC USEROPTIONS

Set Option Value
textsize 64512
language us_english
dateformat mdy
datefirst 7
quoted_identifier SET
arithabort SET
ansi_null_dflt_on SET
ansi_defaults SET
ansi_warnings SET
ansi_padding SET
ansi_nulls SET
concat_null_yields_null SET
PRINCIPAIS COMANDOS DBCC DE VALIDAÇÃO

COMANDO DBCC CHECKDB
Faz a verificação da alocação do espaço nas páginas de dados e da integridade estrutural de todos os
objetos de um Banco de Dados. Além da verificação, este comando é capaz de reparar problemas com
a alocação de espaço no Banco de Dados. Dependendo do tamanho do Banco de Dados e do volume de
dados, este comando pode demorar um bom tempo para ser executado.

DBCC CHECKDB
( ‘database_name’
[ , NOINDEX
| { REPAIR_ALLOW_DATA_LOSS
| REPAIR_FAST
| REPAIR_REBUILD
} ]
) [ WITH { [ ALL_ERRORMSGS ]
[ , [ NO_INFOMSGS ] ]
[ , [ TABLOCK ] ]
[ , [ ESTIMATEONLY ] ]
[ , [ PHYSICAL_ONLY ] ]
}
]
♦ Por padrão, somente a role de servidor sysadmin e a role de Banco de Dados db_owner é que
têm permissão para executar este comando.
♦ Este comando faz uma verificação da integridade de todos os elementos de um Banco de Dados.
Fazer uma verificação de integridade no Banco de Dados AdventureWorks.
Use AdventureWorks
DBCC CHECKDB
Ao ser executado com sucesso, este comando emite uma longa mensagem. As primeiras linhas desta
mensagem estão indicadas a seguir:
DBCC results for ‘AdventureWorks’.
Service Broker Msg 9675, Level 10, State 1: Message Types analyzed: 13.
Service Broker Msg 9676, Level 10, State 1: Service Contracts analyzed: 5.
Service Broker Msg 9667, Level 10, State 1: Services analyzed: 3.
Service Broker Msg 9668, Level 10, State 1: Service Queues analyzed: 3.
Service Broker Msg 9669, Level 10, State 1: Conversation Endpoints analyzed: 0.
Service Broker Msg 9674, Level 10, State 1: Conversation Groups analyzed: 0.
Service Broker Msg 9670, Level 10, State 1: Remote Service Bindings analyzed: 0.
DBCC results for ‘sys.sysrowsetcolumns’.
There are 1257 rows in 10 pages for object ‘sys.sysrowsetcolumns’.
DBCC results for ‘sys.sysrowsets’.
There are 239 rows in 2 pages for object ‘sys.sysrowsets’.
DBCC results for ‘sysallocunits’.
There are 493 rows in 6 pages for object ‘sysallocunits’.
DBCC results for ‘sys.sysfiles1’.
There are 2 rows in 1 pages for object ‘sys.sysfiles1’.
DBCC results for ‘sys.syshobtcolumns’.
There are 1257 rows in 11 pages for object ‘sys.syshobtcolumns’.
DBCC results for ‘sys.syshobts’.
There are 239 rows in 2 pages for object ‘sys.syshobts’.
DBCC results for ‘sys.sysftinds’.
There are 0 rows in 0 pages for object ‘sys.sysftinds’.
DBCC results for ‘sys.sysserefs’.
There are 493 rows in 3 pages for object ‘sys.sysserefs’.
DBCC results for ‘sys.sysowners’.
There are 29 rows in 1 pages for object ‘sys.sysowners’.
DBCC results for ‘sys.sysprivs’.
There are 13 rows in 1 pages for object ‘sys.sysprivs’.
DBCC results for ‘sys.sysschobjs’.
There are 536 rows in 10 pages for object ‘sys.sysschobjs’.
DBCC results for ‘sys.syscolpars’.
There are 1052 rows in 19 pages for object ‘sys.syscolpars’.
DBCC results for ‘sys.sysnsobjs’.
There are 7 rows in 1 pages for object ‘sys.sysnsobjs’.
DBCC results for ‘sys.syscerts’.
There are 0 rows in 0 pages for object ‘sys.syscerts’.
NOTA
Observe que neste exemplo o comando não encontrou nenhum erro de alocação e também não encontrou nenhuma inconsistência.
Também podemos utilizar algumas opções com o comando DBCC CHECKDB. Por exemplo, a opção
NOINDEX define que os nonclustered indexes das tabelas criadas pelo usuário não devem ser verificados.
A seguir temos um exemplo de utilização desta opção.
DBCC CHECKDB (‘AdventureWorks, NOINDEX)

NOTA
Para informação sobre todas as opções do comando DBCC CHECKDB, consulte a referência da linguagem T-SQL, no Books OnLine.
COMANDO DBCC CHECKTABLE

Faz a verificação da integridade das páginas de dados, índices e páginas com valores de campos do tipo
text, ntext e image. Devemos utilizar este comando em tabelas com suspeita de dados corrompidos.
DBCC CHECKTABLE
( ‘table_name’ | ‘view_name’
[ , NOINDEX
| index_id
| { REPAIR_ALLOW_DATA_LOSS
| REPAIR_FAST
| REPAIR_REBUILD }
]
) [ WITH { [ ALL_ERRORMSGS | NO_INFOMSGS ]
[ , [ TABLOCK ] ]
[ , [ ESTIMATEONLY ] ]
[ , [ PHYSICAL_ONLY ] ]
}
]
♦ Por padrão, somente a role de servidor sysadmin e a role de Banco de Dados db_owner é que
têm permissão para executar este comando.
♦ É feita uma verificação da integridade física de tabelas.
Verificar a integridade da tabela Orders do Banco de Dados Northwind.
Use Northwind
DBCC CHECKTABLE(‘orders’)
DBCC results for ‘Orders’.

There are 830 rows in 20 pages for object ‘Orders’.
Verificar a integridade somente das páginas de dados da tabela Orders do Banco de Dados Northwind,
isto é, sem fazer a verificação dos índices.
Use Northwind
DBCC CHECKTABLE (‘orders’) WITH PHYSICAL_ONLY
NOTA
Para informação sobre todas as opções do comando DBCC CHECKTABLE, consulte a referência da linguagem T-SQL, no Books OnLine.
MAIS UM COMANDO DBCC

COMANDO DBCC HELP
Retorna a sintaxe para um determinado comando DBCC.
DBCC HELP ( ‘dbcc_statement’ | @dbcc_statement_var | ‘?’ )
♦ Por padrão, somente a role de servidor sysadmin é que tem permissão para executar este
comando.
Considere o exemplo:
DBCC HELP (‘CHECKDB’)
Este comando irá retornar a sintaxe para o comando DBCC CHECKDB.
Agora considere o seguinte exemplo:
DBCC HELP (‘?’)
Este comando retorna uma listagem de todos os comandos DBCC, sem o prefixo DBCC, para os quais
está disponível ajuda, através do comando DBCC HELP.
Para uma referência completa de todos os comandos DBCC, você pode acessar o item DBCC, na
referência da linguagem T-SQL, no Books OnLine.
KNOW-HOW EM: IMPORTAÇÃO E EXPORTAÇÃO DE DADOS

COM O DTS – DATA TRANSFORMATION SERVICES
PRÉ-REQUISITOS
METODOLOGIA
♦ Aprender a utilizar o DTS Import and Export Wizard.
TÉCNICA
♦ Importar e exportar dados utilizando o DTS.
Com o SQL Server 2005 podemos, facilmente, importar e exportar dados que estão em outros formatos,
como por exemplo:
♦ Dados do Microsoft Access.
♦ Dados no formato Dbase (.dbf).
♦ Dados no formato de planilhas do Excel (.xls).
♦ Dados no formato de arquivos de texto delimitado ou largura fixa (.txt).
♦ Dados de outros Bancos de Dados como o ORACLE, DB2 da IBM, etc.
Também podemos importar e exportar dados entre diferentes Bancos de Dados do SQL Server dentro
da mesma instância, entre instâncias do mesmo servidor e até mesmo entre instância de servidores
diferentes. As instâncias podem ser todas do SQL Server 2005, ou de diferentes versões do SQL Server
2005. Por exemplo, você pode importar dados de um banco de dados de uma instância do SQL Server
2000 (é um dos exemplos que faremos neste capítulo) para uma instância do SQL Server 2005.
Para ilustrar estas capacidades faremos alguns exemplos práticos, onde importaremos e exportaremos
dados. Para situações em que seja necessária a integração com fontes mais complexas, como por exemplo
dados armazenados no Mainframe, devemos utilizar o Business Intelligence Development Studio. Neste
item, trataremos de importações e exportações simples, com Bancos de Dados do Microsoft SQL Server,
Microsoft Access e no formado .dbf. Também veremos um exemplo de transformação dos dados
importados, com o auxílio do DTS.
IMPORTANDO DADOS DE OUTRAS FONTES DE DADOS

A seguir faremos um exemplo, onde importaremos dados de um Banco de Dados do Microsoft Access.
Exemplo prático: Neste exemplo vamos criar um novo Banco de Dados chamado ImportAccess, na
instância SERVIDOR\SQL2005. Depois vamos importar algumas tabelas de um banco de dados do
Access, para dentro deste Banco de Dados.
♦ Procedimento 1 – Criar na instância SERVIDOR\SQL2005 um Banco de Dados chamado

ImportAccess, com as seguintes características:
♦ Nome no SQL Server: ImportAccess
♦ Arquivo primário: C:\livrosql\ImportAccess\ImportAccess-prim.mdf, tamanho inicial de

10 MB, tamanho máximo de 50 MB e crescimento automático habilitado com incrementos
de 1 MB.
♦ Arquivo secundário: C:\livrosql\ImportAccess\ImportAccess-sec1.ndf, tamanho inicial de
15 MB, tamanho máximo de 50 MB e crescimento automático habilitado com incrementos
de 10%.
♦ Arquivo de log: C:\livrosql\ImportAccess\ImportAccess-log.ldf, tamanho inicial de 5 MB, tamanho

máximo de 50 MB e com crescimento automático habilitado com incrementos de 1 MB.
Para criar o Banco de Dados ImportAccess, na instância SERVIDOR\SQL2005, siga os passos indicados
a seguir:
2. Na janela Object Explorer, clique com o botão direito do mouse na instância SERVIDOR\SQL2005
e, no menu de opções que é exibido, clique em New Query. Será aberta a janela para execução de
comandos T-SQL, com a qual você já trabalhou diversas vezes neste livro.
NOTA
Importante: Antes de executar os comandos indicados a seguir, a pasta C:\Livrosql\ImportAccess já deve ter sido criada, se não os comandos
não serão executados e será gerada uma mensagem de erro. Verifique se a pasta C:\Livrosql\ImportAccess já existe. Caso esta pasta ainda
não exista, crie a pasta, antes de executar os comandos indicados no próximo passo.
3. Digite e execute (Ctrl+E) o seguinte comando:

CREATE DATABASE ImportAccess
ON
— *************************
— *************************
(NAME= ‘ImportAccess-prim’,
FILENAME = ‘C:\livrosql\ImportAccess\ImportAccess-prim.mdf’,
SIZE= 10MB,
MAXSIZE= 50MB,
FILEGROWTH = 1MB),
— ***************************
— ***************************
(NAME= ‘ImportAccess-sec’,
FILENAME = ‘C:\livrosql\ImportAccess\ImportAccess-sec.ndf’,
SIZE= 15MB,
MAXSIZE= 50MB,
FILEGROWTH = 10%)
— *************************
— *************************
LOG ON
(NAME= ‘ImportAccess-log’,
FILENAME = ‘C:\livrosql\ImportAccess\ImportAccess-log.ldf’,
SIZE= 5MB,
MAXSIZE= 50MB,
FILEGROWTH = 1MB)
— ***************************************
— ***************************************
ImportAccess terá sido criado e a seguinte mensagem será exibida no painel inferior do Query Analyzer:
4. Feche a janela de execução de comandos e feche o SQL Server Management Studio.
♦ Procedimento 2: Importar as tabelas do Banco de Dados C:\Meus Documentos\Northwind.mdb,

no formato do Microsoft Access XP, para o Banco de Dados ImportAccess, recém-criado na instância
SERVIDOR\SQL2005 do SQL Server 2005. Você pode utilizar qualquer banco de dados do Access
disponível no seu computador. Eu estou utilizando, por questões de facilidade, o banco de dados
NorthWind.mdb, que é um banco de dados de exemplos, que é automaticamente instalado
junto com o Microsoft Access.
NOTA
Se você estiver utilizando outro nome para o Banco de Dados, para a instância do SQL ou para o arquivo teste.mdb, substitua estas opções
pelas opções que você está utilizando, quando estes nomes aparecerem nos procedimentos práticos deste exercício.
Para importar as tabelas do Banco de Dados C:\Meus documentos\NorthWind.mdb, para o banco de

dados ImportAccess, da instância SERVIDOR\SQL2005, siga os passos indicados a seguir:
2. Navegue até a opção Databases da instância SERVIDOR\SQL2005.
3. Dê um clique no sinal de + ao lado da opção Databases, para exibir os bancos de dados

disponíveis. O banco de dados ImportAccess já deve estar sendo exibido, conforme
exemplificado na Figura 7.9. Se o banco de dados ainda não estiver sendo exibido, pressione a
tecla F5 para atualizar a listagem.
Figura 7.9 O banco de dados ImportAccess, recém-criado.
4. Dê um clique no sinal de + ao lado de ImportAccess e depois dê um clique no sinal de + ao lado

da opção Tables. Observe que somente existem as chamadas tabelas do sistema – System Tables,
aquelas criadas automaticamente pelo SQL Server 2005, quando da criação de um Banco de
Dados. Conforme descrevemos anteriormente, as tabelas do sistema contêm informações sobre
o próprio Banco de Dados. Vamos importar uma série de tabelas que estão em um arquivo do
Microsoft Access. Na Figura 7.10 podemos ver as tabelas que serão importadas.
Figura 7.10 Tabelas do arquivo Northwind.mdb.
5. Dê um clique com o botão direito do mouse no Banco de Dados ImportAccess. Nas opções que
surgem, clique no comando Tasks -> Impor Data. Será aberto o “Data Transformation Services
Import/Export Wizard”.
6. A primeira tela do assistente é apenas informativa. Dê um clique no botão Next, seguindo para
a próxima etapa do assistente.
Na segunda etapa devemos selecionar qual o formato dos dados a serem importados. Por padrão vem
selecionado, na lista Data Source, o drive para Microsoft OLE DB Provider for SQL Server. Mas existe a
possibilidade de se importar dados de várias outras fontes, como por exemplo:
♦ Dbase III, IV e V.
♦ Microsoft Access.
♦ Microsoft Excel 3, 4, 5, 97 e 2000.
♦ Paradox 3, 4 e 5.
♦ Fox Pro.
♦ Visual Fox Pro.
♦ ORACLE.
♦ Arquivos de texto.
7. Nesta lista Data source selecione a opção Microsoft Access, pois vamos importar dados de um
arquivo .mdb, que é um Banco de Dados do Access. Observe que as demais opções desta etapa
se modificam, para que você possa informar onde está o banco de dados do Access, a partir do
qual serão importados os dados.
Quando escolhemos uma opção na lista Data Source, as demais opções desta etapa mudam para refletir
os parâmetros que devem ser fornecidos para a fonte de dados escolhida. No caso de uma fonte do
Microsoft Access, devemos definir a localização do arquivo e um nome de usuário e senha, caso o
Banco de Dados esteja protegido.
8. No campo File Name, digite C:\Meus documentos\Northwind.mdb. Deixe os campos Username

e Password em branco, pois este Banco de Dados não está protegido. Você também pode utilizar
o botão Browse, para navegar até a pasta onde está o Banco de Dados com as tabelas a serem
importadas. Sua tela deve estar conforme indicado na Figura 7.11.
A partir de um Banco de Dados do Microsoft Access, podemos importar somente tabelas e consultas (views). Os formulários, relatórios,
NOTA
macros e módulos não poderão ser importados. Isto acontece porque estes objetos são objetos de aplicação, isto é, que constroem a interface
com o usuário e dão suporte às funcionalidades da interface. Conforme já salientamos diversas vezes, o Microsoft SQL Server é um servidor
de Banco de Dados, o qual disponibiliza os dados para aplicativos desenvolvidos com outras ferramentas, como o Visual Basic, Basic.NET, ASP,
ASP.NET, C#, Delphi, etc.
9. Dê um clique no botão Next, para ir à próxima etapa do assistente.
Figura 7.11 Definindo a origem dos dados.
10. Nesta etapa devemos definir para qual Banco de Dados, os dados serão importados. Como
abrimos o assistente, clicando com o botão direito do mouse no Banco de Dados ImportAccess
(da instância SERVIDOR\SQL2005) e selecionando o comando Tasks -> Import data, o banco
de dados ImportAccess e a instância SERVIDOR\SQL2005 já vêm selecionados,
automaticamente. Aceite esta seleção, pois é justamente o que queremos: importar as tabelas
do Banco de Dados Northwind.mdb do Access, para o Banco de Dados ImportAccess da instância
SERVIDOR\SQL2005 do SQL Server 2005. Nesta tela, poderíamos definir um outro Banco de
Dados como o destino, caso fosse necessário.
O mais interessante é que o Banco de Dados de destino não precisa, obrigatoriamente, ser um Banco de
Dados do SQL Server 2005. Poderíamos, por exemplo, importar de um Banco de Dados do Microsoft
Access, para um do Paradox ou do Dbase IV. Observe também que, quando escolhemos uma opção na
lista Destination, as demais opções desta etapa mudam para refletir os parâmetros que devem ser
fornecidos para a fonte de destino dos dados. Nesta etapa você também define qual o tipo de autenticação
que está sendo utilizado, pela instância onde está o banco de dados de destino.
Na lista Server podemos selecionar a instância do SQL Server, na qual está o Banco de Dados de destino.
11. Certifique-se de que na lista Server esteja selecionada a opção SERVIDOR\SQL2005, e na lista
Database esteja selecionada a opção ImportAccess, conforme indicado na Figura 7.12.
12. Dê um clique no botão Next, para ir para a próxima etapa do assistente.
Figura 7.12 Definindo o banco de dados de destino.
Nesta etapa, com base nos formatos de origem e destino selecionados, temos duas opções:
♦ Copy data from one or more tables or views: Esta opção exibirá, na próxima etapa, uma
listagem das tabelas e consultas (views), do arquivo de origem (no nosso exemplo C:\Meus
documentos\NorthWind.mdb). Salientando o que foi dito anteriormente, somente podemos
importar tabelas e consultas, não sendo possível importar os demais objetos de um banco de
dados do Access, tais como formulários, relatórios e páginas de dados.
♦ Use a query to specify the data to transfer: Esta opção exibirá, na próxima etapa, uma janela
gráfica, na qual podemos construir uma instrução SQL que retorna dados de uma ou mais
tabelas. A grade a ser exibida é praticamente igual à grade para criação de consultas no Access,
onde você arrasta tabelas, campos e define critérios de filtragem.
13. Certifique-se de que a opção “Copy data from one or more tables or views” esteja selecionada.
14. Dê um clique no botão Next, para ir para a próxima etapa.
Nesta etapa, devemos selecionar as tabelas e consultas a serem importadas. No nosso exemplo
selecionaremos apenas as tabelas. Observe que, para distinguir entre as tabelas e consultas, podemos
observar o ícone no lado esquerdo do nome de cada objeto. Para tabelas o ícone é de uma pequena
tabela, já para consultas o ícone é a figura de um pequeno quadrado com setas para fora, sobrepondo
a figura de uma pequena tabela. Ao selecionar uma tabela ou consulta, você pode clicar no botão
Preview, que será exibida uma listagem dos dados do objeto selecionado.
15. Certifique-se de que todas as tabelas estejam selecionadas, conforme indicado na Figura 7.13.
Figura 7.13 Selecionando todas as tabelas do Banco de Dados de origem – NorthWind.mdb.
Nesta etapa, temos as seguintes opções:
♦ Run Immediately: Esta opção faz com que a importação seja executada imediatamente após
finalizarmos o assistente.
♦ Schedule DTS package for later execution: Esta opção permite que agendemos a importação
para acontecer em intervalos programados, através da criação de um job. Observe que esta
opção pode ser marcada em conjunto com as demais opções. Por exemplo, podemos executar
a importação imediatamente (Run Immediately) e também agendar a importação para ocorrer
em períodos determinados. Se selecionarmos esta opção, podemos utilizar o botão (...) para
alterar o agendamento. Se o agendamento não for alterado, ele será programado para execução
diária à meia-noite (00:00:00 h).
Também podemos salvar as definições de importação, selecionando a opção Save DTS Package. Temos dois
formatos possíveis para salvar as configurações do pacote DTS: SQL Server storage e DTSX File storage.
17. Certifique-se de que apenas a opção Run Immediately esteja selecionada, e dê um clique no
botão Next, para seguir para a próxima etapa do assistente.
Você estará na tela final do assistente, onde é apresentado um resumo das opções selecionadas durante
as etapas anteriores do assistente. Caso você queira alterar alguma opção é só utilizar o botão Back.
18. Para encerrar o assistente e fazer a importação, dê um clique no botão Finish.
O SQL Server 2005 exibe uma janela com o progresso da importação, conforme mostra a Figura 7.14.
Figura 7.14 A importação em andamento.
19. Ao final do processo de importação, você estará de volta à janela de progresso indicada na
Figura 7.14. Dê um clique no botão Close para fechá-la.
20. Você estará de volta ao SQL Server Management Studio. Dê um clique no sinal de + ao lado do
Banco de Dados ImportAccess para exibir as opções deste banco de dados.
21. Dê um clique no sinal de + ao lado da opção Tables, para exibir uma listagem das tabelas do
Banco de Dados ImportAccess. Observe, na Figura 7.14, as sete tabelas que foram importadas
do Banco de Dados Northwind.mdb. Se as tabelas não estiverem sendo exibidas, clique na
opção Tables, para selecioná-la e pressione a tecla F5, para atualizar a listagem de tabelas, do
banco de dados ImportAccess.
Figura 7.15 Tabelas importadas do Banco de Dados NorthWind.mdb.
EXPORTANDO DADOS DO SQL SERVER 2005 PARA OUTRAS FONTES DE DADOS

Em determinadas situações pode ser necessária a exportação dos dados que estão em um servidor SQL
Server para outros formatos de dados. Por exemplo, podemos exportar uma tabela ou o resultado de
uma view para uma planilha do Excel. A pessoa responsável, por exemplo uma secretária, pode preparar
um relatório a partir da planilha do Excel.
A exemplo da importação de dados, podemos exportar dados para uma variedade de formatos. Vamos
fazer dois exemplos de exportação de dados. No primeiro, exportaremos dados para uma planilha do
Excel; no segundo exemplo, para o formato de um arquivo de dados do Dbase III.
Exemplo prático: Exportar as tabelas Pedidos, Detalhes do pedido e Clientes, do Banco de Dados
ImportAccess, da instância SERVIDOR\SQL2005, para uma planilha do Excel. A planilha será gravada
na pasta C:\Meus documentos, com o nome de ExportadoDoSQLServer.xls.
NOTA
Importante: Quando exportamos dados para uma planilha do Excel é necessário que o arquivo já tenha sido criado previamente. Caso o
arquivo C:\Meus documentos\ ExportadoDoSQLServer.xls não exista, crie este arquivo, pois se não será gerado um erro, durante a execução
do assistente de exportação.
Procedimento: Para exportar as tabelas Pedidos, Detalhes do pedido e Clientes, do Banco de Dados ImportAccess,
da instância SERVIDOR\SQL2005, para uma planilha do Excel, siga os passos indicados a seguir:
2. Navegue até a opção Databases da instância SERVIDOR\SQL2005.
3. Dê um clique no sinal de + ao lado da opção Databases, para exibir os bancos de dados

disponíveis. O banco de dados ImportAccess deve estar sendo exibido na listagem.
4. Dê um clique com o botão direito do mouse no Banco de Dados ImportAccess. Nas opções que
surgem, clique no comando Tasks -> Export Data. Será aberto o “Data Transformation Services
Import/Export Wizard”.
5. A primeira tela do assistente é apenas informativa. Dê um clique no botão Next, seguindo para
a próxima etapa do assistente.
Na segunda etapa podemos selecionar o formato dos dados a serem exportados. Por padrão vem
selecionado, na lista Data Source, o drive para SQL Server: Microsoft OLE DB Provider for SQL Server.
Mas existe a possibilidade de exportar dados para diversos formatos, como por exemplo:
♦ Dbase III, IV e V.
♦ Microsoft Access.
♦ Microsoft Excel 3, 4, 5, 97 e 2000.
♦ Paradox 3, 4 e 5.
♦ Fox Pro.
♦ Visual Fox Pro.
♦ ORACLE.
♦ Arquivos de texto.
6. Como estamos exportando dados do SQL Server 2005, certifique-se de que na lista Data Source
esteja selecionado Microsoft OLE DB Provider for SQL Server.
Quando escolhemos uma opção na lista Data Source, as demais opções desta etapa mudam para refletir
os parâmetros que devem ser fornecidos, de acordo com a fonte de dados escolhida. No caso de uma
fonte do Microsoft OLE DB Provider for SQL Server, devemos definir a instância e o nome do Banco de
Dados e as informações para conexão. Como acionamos o assistente clicando com o botão direito do
mouse no Banco de Dados ImportAccess, da instância SERVIDOR\SQL2005, estas informações já vêm
selecionadas, automaticamente.
7. Para autenticação marque a opção Use Windows Authentication. Dê um clique no botão Next,
para ir à próxima etapa do assistente.
8. Nesta etapa devemos definir para qual formato e para qual arquivo, se for o caso, os dados
serão exportados. Na lista Destination selecione: Microsoft Excel 97-2000. No campo File Name
digite: C:\Meus documentos\ ExportadoDoSQLServer.xls. Sua tela deve estar conforme indicado
na Figura 7.16.
Figura 7.16 Definindo o formato e o arquivo de destino dos dados.
Nesta etapa, com base nos formatos de origem e destino selecionados, temos duas opções:
♦ Copy data from on or more tables or views: Esta opção exibirá, na próxima etapa, uma listagem
das tabelas e consultas (views) do banco de dados de origem.
♦ Use a query to specify the data to transfer: Esta opção exibirá, na próxima etapa, uma
janela gráfica, na qual podemos construir uma instrução SQL que retorna dados de uma
ou mais tabelas.
10. Certifique-se de que a opção “Copy data from on or more tables or views” esteja selecionada,
e clique em Next para seguir para a próxima etapa do assistente.
Nesta etapa devemos selecionar as tabelas e consultas a serem exportadas. No nosso exemplo
selecionaremos apenas as tabelas Pedidos, Detalhes do Pedido e Clientes. É também importante observar
que o banco de dados não tem views, somente tabelas. Ao selecionar uma tabela (ou consulta), você
pode clicar no botão Preview que serão exibidos os dados do objeto selecionado. Cada tabela será
exportada como uma nova planilha na pasta de trabalho C:\Meus documentos\
ExportadoDoSQLServer.xls. Na coluna Destination você pode alterar o nome que será atribuído a cada
planilha. Por padrão, é atribuído o nome da tabela de origem.
11. Certifique-se de que as tabelas Pedidos, Detalhes do Pedido e Clientes estejam selecionadas.
Clique no botão Next, para ir para a próxima etapa do assistente.
Nesta etapa, temos as seguintes opções:
♦ Run Immediately: Esta opção faz com que a exportação seja executada imediatamente após
finalizarmos o assistente.
♦ Schedule DTS package for later execution: Esta opção permite que agendemos a exportação
para acontecer em intervalos programados, através da criação de um job. Observe que esta opção
pode ser marcada em conjunto com as demais opções. Por exemplo, podemos executar a
importação imediatamente (Run Immediately) e também agendar a importação para ocorrer em
períodos determinados. Se selecionarmos esta opção, podemos utilizar o botão Edit Schedule
para alterar o agendamento. Se o agendamento não for alterado, ele será programado para execução
diária à meia-noite (00:00:00 h).
Também podemos salvar as definições de exportação, selecionando a opção Save DTS Package.
12. Certifique-se de que apenas a opção Run Immediately esteja selecionada, e dê um clique no
botão Next, seguindo para a próxima etapa do assistente.
13. Você estará na tela final do assistente, onde é apresentado um resumo das opções selecionadas.
Caso você queira alterar alguma opção, é só utilizar o botão Back. Para iniciar a exportação, dê
um clique no botão Finish.
O SQL Server 2005 exibe uma janela com o progresso da exportação.
Ao final, é exibida uma mensagem informando o número de objetos que foram exportados, conforme
14. Dê um clique no botão Close para fechar esta janela.
15. Você estará de volta ao SQL Server Management Studio. Feche-o.
Abra o Excel e abra o arquivo C:\Meus documentos\ExportadoDoSQLServer.xls. Na Figura 7.18,

podemos ver que as tabelas Pedidos, Detalhes do Pedido e Clientes foram exportadas para o arquivo do
Excel e que cada tabela foi exportada para uma planilha com o nome da tabela.
Figura 7.17 Exportação concluída com sucesso.
Figura 7.18 Dados na planilha do Excel.
KNOW-HOW EM: MONITORAÇÃO DE DESEMPENHO

NO SQL SERVER 2005
PRÉ-REQUISITOS
♦ Noções básicas de hardware.
♦ Noções básicas do Windows 2000 Server ou Windows Server 2003.
♦ Noções sobre utilização do MMC.
METODOLOGIA
♦ Apresentação dos métodos utilizados para monitoração de desempenho.
TÉCNICA
♦ Utilização do console Desempenho para monitoramento.
Um servidor é tão rápido quanto for o desempenho do seu dispositivo mais lento. Em outras palavras,
o desempenho de um servidor pode ser comprometido se um ou mais dos seus dispositivos estiver
apresentando problemas de funcionamento ou estiver inadequadamente dimensionado. Por exemplo,
não adianta você ter um servidor multiprocessado, com uma grande quantidade de memória RAM e
um sistema de discos lentos. Neste caso, o sistema de discos irá limitar o desempenho do seu servidor.
Chamamos o elemento limitador de “gargalo do sistema”, porém o termo mais conhecido é o termo
em inglês: Bottleneck. Utilizarei o termo gargalo.
Um gargalo é causado, normalmente, pelo uso excessivo de um ou mais recursos do sistema. Por
exemplo, em um servidor de Bancos de Dados, em que são realizadas consultas complexas, a memória
pode se tornar um fator limitador do desempenho do sistema. Neste caso dizemos que a memória é o
gargalo do sistema. Muitas vezes, ao solucionarmos um gargalo, imediatamente outro componente
torna-se um novo gargalo. No exemplo anterior, poderíamos adicionar mais memória RAM, aí o
processador ficaria sobrecarregado, e eis que o processador tornou-se o nosso novo gargalo.
Conforme podemos ver, o processo de monitorar o desempenho é um processo contínuo, ou seja,

resolvemos um gargalo e vamos em busca do próximo. Nesta seção aprenderemos a monitorar os
principais elementos de hardware, bem como a monitorar o servidor SQL Server 2005, em busca de
informações que nos ajudem a mantê-lo com um desempenho satisfatório.
A monitoração é uma maneira de o administrador acompanhar o aumento de carga em um ou mais

servidores da rede, acompanhando qual a ocupação/utilização dos principais elementos de hardware,
tais como memória, processadores, interfaces de rede e sistemas de disco. Com o acompanhamento da
carga de trabalho em cada um destes elementos, o administrador pode fazer uma estimativa, com
antecedência, de quando será necessário o upgrade de um ou mais destes elementos de hardware, como
por exemplo adicionar mais memória RAM, trocar a placa controladora de discos por uma mais rápida e
assim por diante. Se o administrador não tem este acompanhamento, o que acontece é que chega-se a
um ponto onde os serviços e o acesso aos sistemas tornam-se lentos e os usuários começam a reclamar.
Neste ponto o administrador não sabe exatamente o que está acontecendo (apenas suspeita que pode ser
sobrecarga em um ou mais dos itens de hardware do servidor). Como o administrador não fez a lição de
casa, isto é, não fez um monitoramento preventivo, terá que “tentar descobrir” quais os elementos de
hardware que estão sobrecarregados, apresentar um relatório solicitando recursos, encomendar o hard-
ware necessário para finalmente providenciar a troca. Ou seja, tudo na base do improviso, da pressa.
Definitivamente esta não é uma boa maneira de trabalhar e administrar a sua rede.
O monitoramento sistemático, isto é, com regras bem definidas e com uma metodologia de
monitoramento, faz com que o administrador trabalhe de uma maneira proativa (um amigo meu diria
que este termo é ‘chique’), sempre prevendo com boa antecedência as necessidades de upgrade de
hardware, evitando com isso que se chegue ao ponto em que o desempenho caia exponencialmente e
os usuários comecem a reclamar. Outro fator que tem que ser considerado é que se chega a um ponto
onde o limite do servidor é atingido, ou seja, não é mais possível expandir a memória, não é possível
adicionar novos processadores e assim por diante. Nestas situações faz-se necessária a troca do servidor
por outro com maiores capacidades. Mais uma vez fica clara a importância do monitoramento para
“prever”, com uma boa antecedência, uma necessidade de troca de servidor. Principalmente porque
servidor e hardware de servidor não é como hardware de PC, que você encontra a pronta entrega no
mercado. Normalmente hardware de servidor é feito sob encomenda e demora alguns dias (ou até
semanas) para estar disponível. Se o administrador não prever com uma boa antecedência a necessidade
de troca, corre o risco de ter que conviver durante semanas com um ou mais servidores que não
atendem as demandas dos usuários, com um desempenho sofrível e, o que é o pior, com um telefone
que não pára de tocar, com usuários reclamando (e com toda a razão) do desempenho do sistema.
Neste tópico você aprenderá a utilizar o console para monitoração de desempenho, de forma a
acompanhar a taxa de utilização dos principais elementos do sistema. Mostrarei uma série de assuntos
relacionados com o monitoramento, otimização e manutenção do Windows Server 2003 (os exemplos
serão baseados no Windows Server 2003, porém se aplicam, praticamente sem modificações, ao Win-
dows 2000 Server). Com os conceitos e exemplos práticos vistos neste tópico, você terá condições de
fazer um monitoramento dos servidores, atuando de maneira proativa.
Monitorar a utilização dos principais recursos de um servidor é uma tarefa importante para o
administrador do servidor, principalmente em servidores que estão sendo utilizados para o
compartilhamento de recursos (por ex. arquivos e impressoras, bancos de dados do SQL Server, sites
baseados no IIS e assim por diante) na rede. O desempenho de um servidor fica seriamente comprometido
se um dos seguintes elementos estiver sobrecarregado:
♦ Memória RAM.
♦ Processador.
♦ Interface de rede.
♦ Sistema de discos.
Neste tópico mostrarei como utilizar o console Desempenho, para acompanhar a taxa de ocupação de
cada um destes elementos. Também mostrarei como configurar o Windows Server 2003 para que faça
a coleta automática, em períodos definidos, da taxa de ocupação de determinados elementos, de tal
maneira que você possa ter uma idéia da utilização destes elementos em condições normais de trabalho.
Com este acompanhamento você também terá condições de verificar a evolução nas taxas de utilização
de cada um dos elementos que estão sendo monitorados. Assim, quando um determinado elemento
tiver a sua taxa de utilização constantemente aumentada, é possível agir preventivamente, normalmente
providenciando a substituição do elemento, como por exemplo a instalação de um processador mais
rápido ou de uma quantidade adicional de memória RAM ou a substituição de discos IDE por um
sistema de discos SCSI.
Em alguns livros e na documentação oficial do Windows Server 2003, o console Performance também
é chamado de System Monitor (Monitor do Sistema). Neste capítulo utilizarei os termos System Moni-
tor ou console Performance como sinônimos.
Para monitorar estes elementos, utilizamos o console Desempenho: Iniciar -> Todos os programas ->
Ferramentas Administrativas -> Desempenho. Antes de aprendermos a utilizar este console, vamos
apresentar alguns elementos teóricos, necessários à utilização do console Desempenho. Veremos os
conceitos de Objeto, Contador e Instância.
♦ Objeto: No contexto do console Desempenho, um objeto é um dos recursos que podem ser
mensurados. Exemplos de objetos são: a memória RAM, o processador, a interface de rede e
assim por diante.
♦ Contador: Cada objeto pode ter um ou mais contadores. Por exemplo, para o objeto processador
podemos ter os contadores Interrupções por segundo, %Tempo do usuário, %Tempo privilegiado
e assim por diante. Para o objeto memória podemos ter, dentre outros, os contadores Páginas
por segundo, Bytes disponíveis, etc. Cada contador reflete o nível de utilização de um
determinado aspecto do objeto.
♦ Instância: Para um mesmo objeto, podemos ter uma ou mais instâncias. Por exemplo, em um
servidor com múltiplos processadores, cada processador é uma instância do objeto processador.
Cada instância pode apresentar valores diferentes, para os diversos contadores de cada objeto.
Por exemplo, em um dos processadores, o percentual de utilização pode estar em 60% e no
segundo processador, em 75%.
Além da memória RAM, Interface de rede, Sistema de discos e Processador, existem diversos outros
elementos que podem prejudicar o desempenho de um servidor, como um todo, porém estes quatro
são os mais importantes. Podem existir situações, por exemplo, em que a utilização da memória RAM
e do Processador esteja baixa, porém o Sistema de discos esteja sobrecarregado e, neste caso, o
desempenho do sistema como um todo fica bastante prejudicado. Dependendo do tipo de função que
o servidor está exercendo, um recurso de hardware pode ter mais ou menos influência no desempenho
como um todo. Por exemplo, servidores de banco de dados, como é o caso de um servidor com uma ou
mais instâncias do SQL Server 2005, são muito dependentes de bons processadores e de uma boa
quantidade de memória RAM; já servidores de arquivos dependem mais de um bom sistema de disco e
de uma conexão rápida com a rede.
Dependendo do papel que o servidor esteja desempenhando na rede, a utilização de cada um

destes componentes será maior ou menor. Por exemplo, computadores que atuam como servidores
de Banco de dados (com o Microsoft SQL Server, por exemplo) ou servidores de aplicação (como o
Microsoft Transaction Server, por exemplo) fazem um uso muito intensivo dos processadores. Neste
caso pode ser recomendável, dependendo do número de usuários, a utilização de servidores
multiprocessados. Já no caso de servidores de arquivos, a utilização da interface de rede e do sistema
de discos pode ser bastante elevada; neste caso a utilização de placas mais velozes ou até mesmo de
mais de uma placa de rede e de sistemas de discos mais rápidos pode ser uma solução para melhorar
o desempenho.
A monitoração do desempenho ajuda a determinar qual o componente que está sendo o principal
limitador do desempenho do sistema (o ‘gargalo’ do sistema), além de permitir a análise da carga de
trabalho à qual o respectivo componente está submetido (por exemplo, o processador está com 80%
de utilização, o sistema de discos está constantemente com dados na fila de espera para leitura e
gravação e assim por diante). O administrador também pode utilizar a monitoração do desempenho
para fazer uma estimativa do crescimento na utilização dos componentes do sistema. Com isso fica
mais fácil fazer uma previsão sobre as necessidades futuras de atualizações de hardware. Além disso, de
posse de dados de monitoração consistentes, fica mais fácil justificar o gasto envolvido na aquisição e
atualização de componentes de hardware.
Conforme mostrarei nos próximos itens, a monitoração é feita através do console Desempenho, também
conhecido como System Monitor. Este console é acessado através da opção Desempenho, no menu
Ferramentas administrativas. No console de desempenho você adiciona “Objetos” a serem monitorados.
Um exemplo de objeto pode ser um Processador, Memória, Disco físico, Fila de impressão, etc. Um
objeto representa um elemento que pode ser monitorado pelo Windows. Para cada objeto, estão
disponíveis vários contadores que são indicativos da utilização dos recursos do respectivo objeto. Por
exemplo para o objeto Processador, dentre outros, existem os seguintes contadores: “Porcentagem de
tempo do processador”, “Interrupções por segundo” e assim por diante. Para o objeto Fila de impressão,
existem os contadores “Total de páginas impressas”, “Trabalhos no spool”, e assim por diante.
Vários objetos e seus respectivos contadores são instalados durante a instalação do Windows. À medida
que novos serviços ou aplicativos são instalados, novos objetos e contadores são adicionados. Por
exemplo, ao instalar o Microsoft SQL Server, novos objetos são adicionados. Outro exemplo, quando
é instalado o servidor Web IIS, novos objetos são adicionados e assim por diante.
Saber exatamente quais objetos e quais contadores utilizar é um processo que envolve testes e muita
paciência. Somente com a experiência é que o administrador saberá quais contadores observar para
verificar a existência de problemas de desempenho.
A otimização do desempenho é um processo contínuo. Muitas vezes em uma primeira análise, o

administrador descobre que um dos componentes está sendo o gargalo do sistema, por exemplo, a memória
RAM. Aí mais memória RAM é acrescentada ao servidor. Pode ser que outro componente passe a ser o
gargalo, por exemplo a placa de rede ou o processador. Monitorar e otimizar o desempenho é um desafio
bastante grande, porém é uma necessidade. Não é possível simplesmente trocar de equipamento toda
vez que houver problemas de desempenho, pois isso seria um desperdício de dinheiro.
Também é possível configurar o console Desempenho para que seja feita a captura de dados
automaticamente. O administrador pode configurar a captura de dados para que seja feita a captura
apenas de determinados contadores de determinados objetos, ou seja, somente aqueles contadores
que interessam ao administrador. Com base nesta captura é possível verificar os limites normais de
operação para componentes como o processador, memória RAM e assim por diante. Entenda-se por
limites normais de operação as taxas de utilização dos diversos componentes de hardware e software,
durante o horário normal de expediente. Depois faz-se o agendamento de um monitoramento contínuo
e compara-se os resultados obtidos com os limites de operação obtidos durante a primeira captura.
Quando um determinado componente começar a apresentar aumento na sua taxa de utilização deve
ser verificado o motivo para este aumento e, se for o caso, providenciar a substituição do dispositivo
antes que a sua taxa de utilização atinja limites que possam comprometer o desempenho do servidor.
No próximo tópico você aprenderá a utilizar o console Performance (Desempenho), através de
exemplos práticos.
MONITORANDO O PROCESSADOR E A MEMÓRIA DO SEU SERVIDOR

Neste item você aprenderá a utilizar o console Desempenho. Também verá como monitorar alguns
contadores dos objetos Memória e Processador. Apresentarei diversos detalhes sobre a utilização da
interface e das funcionalidades do console Desempenho. O console Desempenho já vem configurado
para carregar o snap-in para medição de desempenho.
NOTA
No Windows NT Server 4.0 existe um programa chamado Performance Monitor, o qual é utilizado para a monitoração de desempenho. A partir
do Windows 2000 está disponível o console Desempenho, o qual também está disponível no Windows XP e no Windows Server 2003.
Exemplo: Monitorando o uso da memória e do processador – Windows Server 2003.
Para utilizar o console Desempenho, para monitorar a memória e o processador, siga os seguintes passos:
1. Faça o logon como administrador, ou com uma conta com permissão de administrador.
2. Abra o console Desempenho: Iniciar -> Ferramentas administrativas -> Desempenho.
3. Será aberto o console Desempenho, conforme indicado na Figura 7.19:
Figura 7.19 O console para monitoração do desempenho.
Observe que, por padrão, os seguintes contadores já estão adicionados e sendo monitorados:
♦ O contador Pages/sec do objeto Memory.
♦ Comprimento médio de fila de disco (Avg. Disk Queue Length) do objeto Physical Disk.
♦ O objeto %Tempo do processador (%Processor Time) do objeto Processor.

NOTA
Os gráficos que vão sendo “desenhados” na tela do console indicam os valores associados com cada um dos contadores. No exemplo da
Figura 7.19 a taxa de ocupação do processador chegou a picos de 100% mas, na média, estava abaixo dos 20%.
Para o exemplo proposto você irá excluir os contadores que foram adicionados automaticamente pelo
Windows e irá adicionar outros contadores.
4. Clique no contador Páginas/sec (na parte de baixo do painel, abaixo do gráfico, onde aparece a
lista de contadores) e pressione a tecla Delete. Repita a operação para excluir os demais contadores.
5. Neste console, no painel da esquerda, é exibida a opção Monitor do sistema, que é a opção
utilizada para adicionar novos contadores para os objetos a serem monitorados, no nosso
exemplo a memória e o processador. A opção Logs e alertas de desempenho será vista nos
próximos itens.
6. Dê um clique na opção Monitor do Sistema, para selecioná-la.
Figura 7.20 Janela para adicionar os contadores a serem monitorados.
7. Dê um clique no botão Adicionar na barra de ferramentas – botão com um sinal de + na
barra de ferramentas – ou pressione Ctrl+I. Será exibida a janela Adicionar contadores, na
qual você pode selecionar objetos e adicionar os contadores a serem monitorados, conforme
Na lista Objeto de desempenho, por padrão já vem selecionado o objeto Processador. Nesta lista você
pode selecionar um objeto para o qual serão adicionados contadores a serem monitorados. Ao selecionar
um objeto na lista de objetos, na lista Selecionar contadores na lista, serão exibidos os contadores
relacionados ao objeto selecionado. Um mesmo contador pode ter uma ou mais instâncias. Por exemplo,
ao selecionar o contador % tempo de processador, em um computador com dois processadores, na
lista Selecionar instâncias na lista, serão exibidas as duas instâncias do referido contador, uma para
cada processador. Você pode monitorar somente uma das instâncias ou ambas.
Um detalhe interessante é que, no mesmo console, você pode monitorar contadores de um ou mais servidores. Por exemplo, você pode
NOTA
monitorar a utilização do processador de dois ou mais servidores da rede, utilizando um único console Desempenho. Para isso, na janela da
Figura 7.20, digite o nome do computador no campo Selecionar contadores do computador. Digite o nome do computador no formato
\\NomeDoComputador. Ao digitar o nome e pressionar Enter serão exibidos os objetos do referido servidor. Selecione um ou mais contadores.
Você pode fazer isso para os diversos servidores que serão monitorados simultaneamente. Com isso, em um mesmo console, você poderá
monitorar contadores de diferentes servidores da sua rede.
8. Certifique-se de que o objeto Processador esteja selecionado na lista de Objetos. Na caixa de listagem
Selecionar contadores na lista, marque o contador % tempo de processador. Para ver uma explicação
detalhada sobre o que significa este contador, dê um clique no botão Explicar. Será exibida uma
janela com a descrição do contador selecionado, conforme indicado na Figura 7.21. Você pode
utilizar o botão Explicar para obter um texto explicativo sobre qualquer contador selecionado.
Figura 7.21 Janela que é exibida com a explicação sobre o contador selecionado.
Veja que no campo Selecionar contadores do computador já vem, por padrão, o nome do computador local, onde foi aberto o console de
NOTA
desempenho. Podemos monitorar o desempenho de outros computadores da rede. Por exemplo, para acessar contadores de um computador
chamado SERVER2, basta digitar \\SERVER2, neste campo e pressionar Enter. Em poucos instantes o Windows Server 2003 exibe uma
listagem com os contadores do computador a ser monitorado. Você pode adicionar, para monitoração, contadores de diferentes computadores,
conforme já descrito anteriormente. Por exemplo, você pode adicionar o percentual de ocupação do processador para os diversos servidores
da rede, para determinar qual ou quais estão com utilização excessiva do processador.
9. Dê um clique no botão Adicionar, para adicionar o contador % tempo de processador.
10. Agora é hora de adicionar um contador para a memória. Primeiro, na lista Objeto de
desempenho, selecione o objeto Memória. Na caixa de listagem Selecionar contadores na lista,
são exibidos os contadores disponíveis para o objeto Memória.
11. Dê um clique no contador % de bytes confirmados em uso. Clique no botão Adicionar e depois
dê um clique no botão Fechar. Você estará de volta ao console de desempenho, sendo que
agora os dois contadores que você adicionou já estão sendo monitorados, conforme mostrado
pelo gráfico da Figura 7.22.
Figura 7.22 Um contador do processador e outro da memória, sendo monitorados.
12. Observe que o processador teve picos de quase 100% de utilização. Já a memória tem se mantido
em torno de 25% de utilização. Existem alguns indicadores que podem nos levar a certas
conclusões interessantes. Por exemplo, se a taxa de utilização do processador permanecer por
longos períodos de tempo, sempre próxima ou acima de 80%, pode ser um indicativo de que o
processador é um gargalo para o sistema. O processador deve ser substituído por um outro
mais rápido, ou a utilização de mais do que um processador deve ser considerada. Por outro
lado picos de 100% são perfeitamente normais. Quando você abre um aplicativo é normal que
a utilização do processador chegue próxima dos 100%. O que não pode acontecer é uma alta
taxa de utilização permanente, próxima ou superior a 80%.
13. No nosso exemplo a utilização da memória (em torno de 25%) está em uma patamar ótimo.
Até 60% seria um valor bastante razoável. Lembrando que picos podem acontecer e, o que é
um indicativo de sobrecarga em um dos componentes de hardware, é uma taxa de utilização
constante em patamares elevados.
14. O console de desempenho exibe uma série de informações para cada um dos contadores que estão
sendo monitorados. Observe que cada um dos contadores possui um gráfico com cor diferente. Na
parte de baixo do console, ao clicar em um contador, você irá selecioná-lo. Observe que logo
abaixo do gráfico são exibidas diversas informações, dependendo do contador selecionado.
15. Ao selecionarmos o contador % tempo de processador, por exemplo, são exibidas diversas
informações, tais como: valor médio, valor mínimo, valor máximo e assim por diante.
16. Para adicionar novos contadores, basta utilizar novamente o botão (Adicionar - botão com um
sinal de +) ou pressionar Ctrl+I.
17. Quando você está monitorando diversos contadores, pode ser útil pôr em destaque o contador
selecionado. Para isso basta pressionar Ctrl+H, que o contador selecionado será posto em
destaque, isto é, ficará com a linha do gráfico mais espessa e destacada.
18. Para retirar o destaque do contador, basta pressionar Ctrl+H novamente.
Figura 7.23 Alterando as propriedades do gráfico e incluindo grades de referência.
19. Você pode excluir um contador, simplesmente clicando no contador, na parte de baixo do
console Desempenho, abaixo do gráfico e teclando Delete.
20. Você pode alterar diversas propriedades do gráfico que é exibido no console desempenho,
como por exemplo: cor da linha, cor de fundo, exibir ou não uma grade de referência, etc. Para
acessar estas propriedades, dê um clique com o botão direito do mouse em qualquer parte do
gráfico. No menu que surge clique em Propriedades.
21. Será exibida a janela Propriedades de Monitor do sistema, onde, através das guias Geral, Fonte,
Dados, Gráfico e Aparência, você pode alterar diversas propriedades da exibição do gráfico de
desempenho. No exemplo da Figura 7.23, foram incluídas grades de referência. Esta configuração
é feita através da guia Gráfico, da janela de propriedades.
22. Feche o console de desempenho.
Pratique um pouco: Abra novamente o console Desempenho e adicione alguns contadores do processador e da memória. Para o objeto
PRATIQUE
Processador adicione os contadores Interrupções por segundo e % Tempo privilegiado. Utilize o botão Explicação para exibir a descrição
destes contadores. Altere algumas propriedades do gráfico. Altere o campo atualizar automaticamente a cada 1 segundo para 2 segundos.
Este campo é acessível através da guia Geral das propriedades do gráfico. Para acessar as propriedades clique com o botão direito do mouse
em qualquer local do gráfico, e no menu que surge dê um clique na opção Propriedades.
MONITORANDO O ACESSO AO SISTEMA DE DISCOS

Neste item mostrarei como monitorar alguns contadores dos objetos Disco físico e Disco lógico.
É importante lembrar que o objeto Disco físico se refere a um disco como um todo, independente
de o disco estar dividido em partições (disco básico) ou volumes (disco dinâmico). Já o objeto
Disco lógico, refere-se às partições ou volumes, independente de estarem localizadas em um
único disco, ou distribuídas ao longo de vários discos, como no caso de um volume RAID-5 ou
de um volume set.
IMPORTANTE
Nunca é demais lembrar que no Windows NT 4.0 os contadores para os objetos Disco físico e Disco lógico estão desabilitados, por padrão. O
objeto Disco Lógico nem sequer aparecia na listagem de objetos. O objeto Disco físico aparecia na listagem, mas se você adicionasse alguns
dos seus contadores, estes ficariam sempre em zero, uma vez que estavam desabilitados. Para habilitar os contadores para os objetos Disco
físico e Disco lógico, no NT 4.0, era necessário executar o seguinte comando: diskperf –y e reinicializar o computador para que os contadores
sejam habilitados. NO WINDOWS SERVER 2003 NÃO É NECESSÁRIO ESTE PROCEDIMENTO, POIS OS CONTADORES, TANTO PARA DISCO FÍSCIO
QUANTO PARA DISCO LÓGICO, ESTÃO HABILITADOS, AUTOMATICAMENTE.
Agora é hora de monitorar alguns contadores dos contadores dos objetos Disco físico e Disco lógico.
Para o exemplo proposto estou utilizando um computador com dois discos físicos, os quais estão divididos em um ou mais volumes. Para este
NOTA
exemplo estou utilizando um servidor com o Windows Server 2003, em inglês, o que pode ser comprovado pelas telas em inglês. Conforme
visto no Capítulo 5 do livro “Windows Server 2003 – Curso Completo”, 1568 páginas, de minha autoria, é possível criar mais de um volume
(disco lógico) em um mesmo disco físico. Por exemplo, é possível dividir um disco de 40 GB em dois volumes de 20 GB. A cada volume estaria
associada uma letra, como por exemplo: C: e E: Cada volume representa um disco lógico, isto é, uma unidade.
Exemplo prático: Monitorando a atividade de discos, usando o console de desempenho.
Para monitorar a atividade do sistema de discos, siga os passos indicados a seguir:
3. No painel da esquerda, clique na opção Monitor do sistema, para marcá-la.
4. Dê um clique no botão Adicionar, na barra de ferramentas – botão com um sinal de + ou

pressione Ctrl+I. Será exibida a janela Adicionar contadores, na qual podemos adicionar os
objetos e respectivos contadores que serão monitorados.
Figura 7.24 Monitorando o objeto Disco físico.
5. No campo Objeto de desempenho, selecione o objeto Disco físico. Será exibida uma listagem
com os discos instalados no seu computador e as partições (ou volumes no caso de discos de
Armazenamento dinâmico) criadas em cada um dos discos. No exemplo da Figura 7.24, são
exibidos dois discos: Disco 0 e Disco 1. O espaço do disco 0 é todo ocupado pelo volume C: Já
o espaço do disco 1 é ocupado pelos volumes D:, E: e F: Observe que também é exibida uma
instância denominada ‘_Total’. A instância _Total é utilizada para monitorar a atividade somada
de todos os discos do sistema. Por exemplo, se você selecionar o contador Gravações em disco
por segundo e selecionar a instância total, estará sendo monitorada a atividade total combinada
de escrita em todos os discos do servidor.
6. Na caixa de listagem Selecionar contadores na lista, selecione o contador Gravações em disco

por segundo. Este contador é uma medida da freqüência das operações de gravação em disco.
Ele irá indicar a atividade de gravação de informações no disco.
7. Na caixa de listagem Selecionar instâncias na lista, você tem a opção de definir se quer monitorar
todos os discos físicos (_Total), ou somente alguns deles. Esta caixa exibe todas as ocorrências
do objeto Disco físico, isto é, exibe todos os discos instalados no computador. Por exemplo,
para monitor apenas o Disco 0, clique na opção ‘0 C:’ para selecionar esta instância do contador
Gravações em disco por segundo.
NOTA
Caso existam vários discos e você queira monitorar apenas alguns deles, você deve selecionar apenas os discos a serem monitorados antes
de clicar no botão Adicionar. Para selecionar os diversos discos a serem monitorados, pressione a tecla Ctrl e vá clicando nos discos a serem
monitorados. À medida que você for clicando, os discos serão selecionados.
8. Dê um clique no botão Adicionar, para incluir este contador para monitoração.
9. Agora você irá monitorar a freqüência de gravação somente do volume E:. Para isto, na lista
Objeto de desempenho, selecione o objeto Disco lógico.
10. Na caixa de listagem Selecionar contadores na lista, selecione o contador Disk Gravações em
disco por segundo.
11. Observe que, na caixa de listagem da direita, é exibida uma lista com todos os volumes
disponíveis. Dê um clique no volume E: (ou em um volume disponível no servidor que você
está utilizando) para marcá-lo.
12. Dê um clique no botão Adicionar, para incluir este contador para monitoração.
13. Dê um clique no botão Fechar.
14. Você estará de volta ao console Desempenho, com contadores para monitorar a atividade de
gravação do Disco 0 e da partição E:, conforme indicado pela Figura 7.25.
15. A monitoração da atividade dos discos, através dos diversos contadores disponíveis, é de grande
importância, principalmente para servidores que atuam como servidores de disco (basicamente
com compartilhamento de pastas e arquivos) ou servidores Web para a Internet ou para uma
intranet. Normalmente o sistema de discos é a parte mais lenta do sistema, a parte que pode
causar os maiores problemas em relação ao desempenho. Muitas vezes pode ser necessária a
atualização para discos mais rápidos ou para a implementação de níveis de RAID-5 ou RAID-10
baseados em hardware. Porém estas utilizações somente se justificam em servidores com um
volume de acesso elevado.
Figura 7.25 Gráfico indicativo da atividade de gravação.
16. Feche o console Desempenho.
Exercício: Abra novamente o console Desempenho e monitore os seguintes contadores para o Disco
físico, para o disco 0: Leituras de disco por segundo e Transferência de disco por segundo. Utilize o
botão Explicar para ver o que representa cada um destes contadores. Feche o console Desempenho.
CONTADORES A SEREM MONITORADOS EM SERVIDORES

Na tabela a seguir, da ajuda do Windows Server 2003, apresento uma lista de contadores que a Microsoft
recomenda que sejam monitorados permanentemente nos servidores da rede.
Tabela 7.2 Contadores recomendados pela Microsoft
Componente Aspecto do desempenho sendo monitorado Contadores a monitorar
Disco Uso PhysicalDisk\Leituras de disco/s

PhysicalDisk\Gravações de disco/s
LogicalDisk\% de espaço livre
Interprete cuidadosamente o contador % tempo de disco. Como

a instância _Total desse contador pode não refletir com
precisão o uso em sistemas de vários discos, é importante usar
também o contador % Tempo ocioso. Observe que esses
contadores não podem exibir um valor acima de 100%.
Componente Aspecto do desempenho sendo monitorado Contadores a monitorar
Disco Gargalos Disco físico\ Comprimento médio da fila de disco (todas as

instâncias)
Memória Uso Memória\Bytes disponíveis
Memória\Bytes de cache
Memória Gargalos ou vazamentos Memória\Páginas/s
Memória\Leituras de página/s
Memória\Falhas de transição/s
Memória\Bytes de pool paginável
Memória\Bytes de memória não-paginável
Embora não sejam especificamente contadores do objeto Memória,

as opções a seguir também são úteis para análise de memória:
Arquivo de paginação\% uso (todas as instâncias)

Cache\Acertos de mapa de dados %
Servidor\Bytes de pool paginável e Servidor\Bytes de memória
não-paginável
Rede Taxa de transferência Contadores de transmissão de protocolo (varia de acordo com o
protocolo de rede); para TCP/IP:
Interface de rede\Total de bytes/s
Interface de rede\Pacotes/s
Servidor\Total de bytes/s ou Servidor\Bytes transmitidos/s e
Servidor\Bytes recebidos/s
Processador Uso Processador\% tempo de processador (todas as instâncias)
Processador Gargalos Sistema\Comprimento da fila de processador (todas as instâncias)
Processador\Interrupções/s
Sistema\Alternâncias de contexto/s
VALORES INDICATIVOS DE LIMITES DE DESEMPENHO PARA CONTADORES

Definir exatamente qual é o limite aceitável para o valor de um ou mais contadores não é uma ciência
exata. Por exemplo, afirmar que sempre que a taxa de utilização do processador se mantiver em torno
de 80%, por longos períodos, é um indicativo de queda no desempenho ou um indicativo de que o
processador deve ser substituído não é algo preciso. Claro que existem valores para determinados
contadores que servem para disparar o alarme, isto é, servem para alertar o administrador a que uma
parte do sistema pode estar sendo responsável pela queda de desempenho, ou seja, pode estar sendo o
que chamamos de ‘gargalo do sistema’.
Na tabela a seguir, da Ajuda do Windows Server 2003, apresento alguns valores para determinados
contadores, valores estes que, pelas recomendações da Microsoft, devem servir de alerta ao administrador.
Tabela 7.3 Valores limites recomendados pela Microsoft.
Recurso Objeto\Contador Limite sugerido Comentários
Disco Disco físico\% de espaço livre

Disco lógico\% de espaço livre 15%
Disco Disco físico\% tempo de disco
Disco lógico\% tempo de disco 90%
Disco Disco físico\Leituras de disco/s, Depende das especificações Verifique a taxa de transferência especificada
Disco físico\Gravações de disco/s do fabricante para seus discos, para ter certeza de que
ela não ultrapassa as especificações. Em
geral, os discos Ultra Wide SCSI podem
gerenciar de 50 a 70 operações de E/S
por segundo. Observe que o fato de a E/S
ser seqüencial ou aleatória pode ter um
forte efeito sobre os valores de leituras de
disco/s e gravações de disco/s.
Disco Disco físico\Comprimento da Número de eixos mais 2 Esse contador é instantâneo. Observe seu
fila de disco atual valor durante vários intervalos. Para obter
uma média ao longo do tempo, use Disco
físico\ Comprimento médio da fila de disco.
Memória Memória\Bytes disponíveis Para computadores com Pesquise o uso da memória e adicione
mais memória, mais de 4 MB memória se necessário.
Memória Memória\Páginas/s n páginas/s por arquivo Pesquise a atividade de paginação.
de paginação Observe o volume de E/S transferido para
os discos com arquivos de paginação.
Arquivo de paginação Arquivo de paginação\% uso Acima de 70% Revise este valor juntamente com Bytes
disponíveis e Páginas/s para entender a
atividade de paginação do computador.
Processador Processador\% tempo de processador 85% Descubra o processo que está usando uma
alta porcentagem do tempo do processador.
Atualize para um processador mais
rápido ou instale um processador adicional.
Processador Processador\Interrupções/s Depende do processador; Um aumento brusco no valor desse
um bom ponto de partida contador, sem um aumento
é 1.000 interrupções correspondente na atividade do sistema,
por segundo indica um problema de hardware.
Identifique o adaptador de rede, o disco
ou outro tipo de hardware que está
causando as interrupções.
Servidor Servidor\Total de bytes/s Se a soma de Total de bytes/s para todos
os servidores for aproximadamente igual
às taxas de transferência máximas de sua
rede, convém segmentar a rede.
Servidor Servidor\Falta de itens de trabalho 3 Se o valor atingir este limite, considere
adicionar as entradas DWORD
InitWorkItems (o número de itens de
trabalho alocados para um processador
durante a inicialização) ou MaxWorkItems
(o número máximo de buffers de
recebimento que um servidor pode alocar)
ao Registro (em HKEY_LOCAL_MACHINE\
SYSTEM\CurrentControlSet\Services\
LanmanServer\Parameters). A entrada
InitWorkItems pode variar de 1 a 512,
enquanto MaxWorkItems pode variar de 1
a 65.535. Comece por qualquer valor para
InitWorkItems e um valor igual a 4.096
para MaxWorkItems e dobre esses valores
até que o limite de Servidor\Falta de itens
de trabalho fique abaixo de 3.
Recurso Objeto\Contador Limite sugerido Comentários
Servidor Servidor\Pico de pool paginável Quantidade de RAM física Esse valor é um indicador do tamanho
máximo do arquivo de paginação e da
quantidade de memória física.
Servidor Filas de trabalho do 4 Se o valor atingir esse limite, poderá
servidor\Comprimento da fila haver um gargalo no processador. Esse
contador é instantâneo. Observe seu valor
durante vários intervalos.
Vários processadores Sistema\Comprimento da fila 2 Esse contador é instantâneo. Observe seu
de processador valor durante vários intervalos.
Claro que estes são apenas valores sugeridos, os quais servem como alerta para o administrador.
Conforme descrito anteriormente, o processo de monitoração é um processo contínuo, de
acompanhamento na evolução dos principais contadores, sugeridos anteriormente.
A seguir apresento, de uma forma resumida, os principais contadores e respectivos limites, ou seja,
valores que podem indicar que o problema é com o respectivo componente:
♦ Processador\% tempo de processador: Não deve estar por longos períodos acima dos 80%.
♦ Sistema\Comprimento da fila de processador: Não deve ser maior do que 2.
♦ LogicalDisk\Comprimento da fila de disco atual: Se este valor estiver constantemente acima

de 2, o sistema de discos deve ser substituído por um sistema mais rápido. Por exemplo, se os
discos forem IDE, você pode substituir por um sistema SCSI. Outra alternativa é implementar
um volume Set sem paridade.
♦ LogicalDisk\Comprimento da fila de disco atual: Valem os mesmos comentários do item
anterior.
♦ Memória\Páginas/s: Um valor maior do que 20 pode indicar a necessidade de um upgrade de

memória, normalmente com a adição de mais memória RAM.
♦ Memória\Bytes confirmados: Deve ser sempre menor do que a quantidade total de memória
instalada.
CONFIGURANDO O CONSOLE DESEMPENHO

PARA CAPTURAR DADOS AUTOMATICAMENTE
Na introdução sobre a monitoração de desempenho, falei sobre a possibilidade de configurar o console
Desempenho para efetuar a captura automática de dados, conforme destacado no trecho a seguir:
“Também é possível configurar o console Desempenho para que seja feita a captura de dados
automaticamente. O administrador pode configurar o console desempenho para que sejam capturados
dados sobre os objetos/contadores a serem monitorados. Com base nesta captura, o administrador
pode verificar os limites normais de operação para componentes como o processador, memória RAM
e assim por diante. Depois faz-se um monitoramento contínuo e compara-se os resultados obtidos
com os limites de operação obtidos em outras medições. Quando um determinado componente
começar a apresentar aumento na sua taxa de utilização o administrador deve verificar o motivo
para este aumento e, se for o caso, providenciar a substituição do elemento que está apresentando
elevação em suas taxas de utilização, antes que a sua taxa de utilização atinja limites que possam
comprometer o desempenho do servidor.”
Conforme pode ser concluído pelo parágrafo anterior, o principal objetivo em configurar a coleta
automática de dados é para determinar quais as taxas normais de utilização dos componentes a serem
monitoradas, em situação normal de uso. Depois são feitas novas observações para acompanhar a
evolução destas taxas de ocupação, para poder agir preventivamente quando um determinado
componente estiver atingindo níveis elevados de utilização.
A captura automática de dados é feita utilizando a opção Logs e alertas de desempenho, do console
Desempenho. Com esta opção, você pode coletar automaticamente dados de desempenho de
computadores locais ou remotos. Você pode visualizar os dados que foram gravados no log usando o
console Desempenho ou exportar os dados para programas de planilha ou banco de dados, para fins de
análise e geração de relatórios. Por exemplo, você pode importar os dados gravados em um log de
desempenho, para um banco de dados do Microsoft Access e utilizar estes dados para a criação de
relatórios personalizados.
Com a opção Logs e alertas de desempenho, estão disponíveis os seguintes recursos:
♦ Coleta de dados em formato separado por vírgulas ou por tabulações para facilitar a importação
por programas de planilha ou programas de banco de dados. É fornecido também um formato
de arquivo de log binário para registro em log circular ou para registro em log de instâncias,
como segmentos ou processos, que podem começar depois do início da coleta de dados. (O
registro em log circular é o processo de registro contínuo de dados em um único arquivo,
sobrescrevendo os dados anteriores com novos dados.)
♦ Você também pode coletar dados em formato de banco de dados SQL. Essa opção define o
nome de um banco de dados SQL e conjunto de logs existentes dentro do banco de dados em
que os dados de desempenho serão lidos ou gravados. Esse formato de arquivo é útil ao coletar
e analisar dados de desempenho de toda a empresa, em vez de servidor por servidor. Por exemplo,
a partir de um único console Desempenho, você pode obter dados sobre diversos servidores da
rede e armazenar estes dados centralizadamente em um único banco de dados do SQL Server.
NOTA
Importante: Lembre-se que, quando houver a necessidade de capturar dados de desempenho de diversos servidores e consolidar estas dados em um
único banco de dados, a opção mais indicada é fazer com que os dados obtidos sejam gravados em um banco de dados do SQL Server.
♦ Os dados coletados podem ser visualizados durante a coleta ou após seu término. Como o log
funciona da mesma maneira que um serviço do Windows Server 2003, a coleta de dados ocorre
independentemente de haver um usuário logado ou não, no servidor que está sendo monitorado.
♦ Você pode definir os momentos de início e parada, nomes de arquivos, tamanho máximo de
arquivo e outros parâmetros para a geração automática do log.
♦ Você pode gerenciar várias sessões de log em uma única janela de console.
♦ Você pode definir um alerta em um contador, especificando que uma mensagem seja
enviada, um programa seja executado e uma entrada seja feita no log de eventos do Win-
dows Server 2003 ou um log seja iniciado quando o valor do contador selecionado for
superior ou inferior a uma configuração especificada. Por exemplo, você pode monitorar a
taxa de utilização do processador e solicitar que o administrador seja avisado quando esta
taxa ultrapassar um determinado patamar, digamos 85%, ou você pode monitorar o espaço
livre em todas as unidades de disco ou em todos os volumes, de todos os servidores da rede
e pedir que seja disparado um alerta para o administrador, sempre que uma unidade
apresentar espaço livre inferior a 20%.
Para que a coleta de dados possa funcionar corretamente, o serviço “Logs e alertas de desempenho” deve ter sido inicializado corretamente.
NOTA
Antes de prosseguir você irá verificar (no exemplo logo a seguir) se este serviço está configurado para inicialização automática. Caso não
esteja, irá configurá-lo para que seja inicializado automaticamente.
Exemplo: Verificando as opções de configuração e inicialização do serviço “Logs e alertas de

desempenho”.
1. Faça o logon como administrador ou com uma conta com permissão de administrador.
2. Abra o console Serviços que está disponível no menu Ferramentas administrativas.
Figura 7.26 Configurando o serviço Logs e alertas de desempenho para iniciar automaticamente.
3. Localize o serviço Logs e alertas de desempenho e verifique o valor indicado na coluna Tipo de
inicialização. Se o valor desta coluna estiver em Manual, significa que o serviço não está sendo
inicializado automaticamente. Se for este o caso, dê um clique duplo no serviço para exibir a
janela com as propriedades do serviço.
4. Na janela de propriedades do serviço, na guia Geral, altere o tipo de inicialização para

Automático, conforme indicado na Figura 7.26.
5. Clique no botão Iniciar para fazer com que o serviço seja inicializado imediatamente.
6. Surge a mensagem indicada na Figura 7.27.
Figura 7.27 Mensagem sobre o serviço Logs e alertas de desempenho.
Esta mensagem informa que o serviço foi inicializado e encerrado, pois no momento não existe nenhuma
coleta de dados em andamento. Porém o Windows Server 2003 irá iniciar o serviço automaticamente,
quando uma coleta de dados for configurada. O Windows Server 2003 detecta que o serviço deve estar
ativo para que a coleta de dados possa ser feita e inicializa o serviço automaticamente.
7. Clique em OK para fechar a mensagem de aviso. Você estará de volta à janela de propriedades
do serviço. Clique em OK para fechá-la.
8. Feche o console Serviços.
Uma vez estando configurado corretamente o serviço Logs e alertas de desempenho, temos à disposição
as seguintes funcionalidades:
♦ Iniciar e parar o log manualmente, por demanda ou automaticamente, com base em um

agendamento definido pelo usuário.
♦ Definir configurações adicionais para log automático, como renomear o arquivo

automaticamente e definir parâmetros para parar ou iniciar um log com base no tempo decorrido
ou no tamanho do arquivo.
♦ Criar logs de rastreamento. Usando o provedor de dados do sistema padrão do Windows Server
2003 ou outro provedor de aplicativos, os logs de rastreamento registram detalhadamente os
eventos de aplicativos do sistema, quando ocorrem certas atividades, como uma operação de
entrada/saída (E/S) de disco ou uma falha de página. Quando o evento ocorre, o Windows
Server 2003 registra os dados em um arquivo de log especificado pelo serviço de logs e alertas
de desempenho. Isso difere da operação dos logs de contadores. Quando eles estão em uso, o
serviço obtém dados do sistema no fim do intervalo de atualização, em vez de esperar por um
evento específico. Uma ferramenta de análise é necessária para interpretar o resultado do log
de rastreamento.
♦ Definir um programa que seja executado quando um log for parado. Por exemplo, você pode
configurar que seja executado um script que copia os arquivos com os dados para um drive da
rede, onde o arquivo será importado em um banco de dados. O script também pode ser
configurado para enviar uma mensagem para o administrador.
Se você desejar exportar dados do log para o Microsoft Excel, o serviço de logs e alertas de desempenho deverá ser parado, porque o
NOTA
Microsoft Excel exige acesso exclusivo ao arquivo de log. Não há informações sobre outros programas que exijam esse acesso exclusivo.
Portanto, você geralmente pode trabalhar com dados de um arquivo de log enquanto o serviço estiver coletando dados para esse arquivo.
Para parar o serviço de logs e alertas utilize o console Serviços, conforme descrito no exemplo anterior.
Agora você acompanhará alguns exemplos práticos de coleta de dados.
Exemplo 1: Configurar o serviço de logs e alertas para monitorar a taxa de ocupação do processador.
Serão monitorados os seguintes contadores:
♦ % tempo de processador
♦ Interrupções/s
Os dados deverão ser obtidos em intervalos de 5 segundos e salvos em um arquivo do tipo texto. Os
dados deverão ser gravados no arquivo C:\Monitora o processador_000001.csv.
Para fazer o acompanhamento proposto e gerar o arquivo de log, siga os passos indicados a seguir:
3. No painel da esquerda, clique no sinal de + ao lado da opção Logs e alertas de desempenho.
Serão exibidas as opções indicadas na Figura 7.28:
Figura 7.28 Opções de configuração para logs e alertas de desempenho.
4. Clique na opção Logs do contador. Observe que, por padrão, já existe um log configurado. Este
log, chamado Visão geral do sistema, coleta dados de um conjunto de objetos/contadores, os
quais fornecem uma visão geral do desempenho do servidor. Você pode iniciar a coleta de dados
para este log, clicando nele para marcá-lo e depois selecionando o comando Ação -> Iniciar ou
clicando no botão Iniciar (botão com o desenho de um pequeno triângulo para a direita).
5. Neste exemplo você irá criar um novo log. Para criar um novo log clique na opção Logs do
contador e selecione o comando Ação -> Novas configurações de log. Surge uma janela
solicitando o nome do novo log. Digite Monitora o processador, conforme indicado na Figura
7.29 e clique em OK.
Figura 7.29 Definindo um nome para o novo log.
Não pode haver nenhum log selecionado, se não a opção Novas configurações de log não será exibida no menu Ação. Se esta opção não
NOTA
estiver sendo exibida, clique novamente na opção Logs do contador, no painel da esquerda. Isso fará com que qualquer log que esteja
marcado seja desmarcado.
Surge a janela Monitora o processador, na qual nós temos as seguintes guias:
♦ Geral: Esta guia é utilizada para definir quais objetos/contadores farão parte do log, definir
uma descrição para o log, definir o intervalo de coleta dos dados e definir se o log executará no
contexto do usuário padrão do sistema ou no contexto de uma conta de usuário específica.
♦ Arquivos de log: Nesta guia você define o formato para o arquivo de log, a forma de nomeação
dos arquivos, um comentário e se os arquivos existentes devem ser sobrescritos ou mantidos.
Você somente poderá acessar esta guia se tiver adicionado pelo menos um objeto ou contador,
usando a guia Geral.
♦ Agendar: Nesta guia o administrador pode definir um agendamento para a coleta. Por exemplo,
de segunda a sexta-feira, das 8:00 às 18:00.
Agora você adicionará os contadores % tempo de processador e Interrupções/s, do objeto Processador.
6. Clique na guia Geral. Clique no botão Adicionar contadores. Será exibida a janela Adicionar
contadores, a qual já utilizamos nos exemplos anteriores. Adicione os contadores % tempo de
processador e Interrupções/s, do objeto Processador e clique em Fechar.
7. No campo Intervalo, defina um intervalo de 5 segundos para a coleta dos dados. A guia Geral
deve estar conforme indicado na Figura 7.30:
Figura 7.30 Configurações da guia Geral, para o exemplo proposto.
8. Clique na guia Arquivos de log. Para o formato selecione Arquivo de texto (delimitado por
vírgulas). Clique no botão Configurar para definir o local onde será criado o arquvio de log e
um tamanho máximo.
Figura 7.31 Definindo configurações para o arquivo de log.
9. Ao clicar no botão Configurar será exibida a janela Configurar Arquivos de log. Defina as
configurações indicadas na Figura 7.31.
10. Clique em OK para fechar a janela Configurar arquivos de log.
11. Você estará de volta à guia Arquivos de log. Clique na guia Agendar.
12. Defina um agendamento para que a coleta seja iniciada e encerrada. Por exemplo, configure o
log para iniciar em uma data e horário específicos, conforme exemplo indicado na Figura 7.32.
Nesta guia você também pode definir o que deve ser feito, caso o arquivo de log atinja o seu
tamanho máximo. Estão disponíveis as seguintes opções: Iniciar um novo arquivo de log ou
Executar este comando.
Figura 7.32 Definindo um agendamento para a coleta de dados.
13. Clique em OK. Você estará de volta ao console Desempenho. O log Monitora o processador foi
criado e iniciará a coleta de dados no horário determinado, conforme configurações definidas
na guia Agendar. Observe que o log Monitora o processador já aparece na lista de logs,
juntamente com o log Visão geral do sistema, sendo que este último é automaticamente criado
pelo Windows Server 2003, conforme descrito anteriormente.
NOTA
Se você precisar alterar alguma configuração de um log, basta dar um clique duplo no respectivo log que será exibida a janela com as
propriedades do log, onde você terá acesso às guias Geral, Arquivos de log e Agendar.
14. O administrador pode fazer com que o log inicie a coleta de dados imediatamente, independente
do agendamento definido. Para isso clique no log Monitora o processador, para marcá-lo e
selecione o comando Ação -> Iniciar.
15. O log será inicializado e os dados começarão a ser capturados e salvos no arquivo C:\Monitora o
processador_000001.csv. Aguarde uma meia hora para que o Windows Server 2003 possa coletar
uma boa quantidade de dados. Observe que, após ser inicializado, o pequeno ícone, ao lado do
nome do log, alterna para a cor verde. Este é um indicativo de que o log está em execução.
16. Para suspender a execução do log e a coleta dos dados, basta clicar no log a ser suspenso e
depois selecionar o comando Ação -> Parar. Você também pode clicar com o botão direito do
mouse no log e, no menu que é exibido, clicar na opção Parar.
Além do menu Ação, você também pode utilizar o botão direito do mouse, clicando no respectivo log, para ter acesso aos comandos Iniciar
NOTA
e Parar. Na barra de ferramentas do console Desempenho, existem o botão Iniciar - botão com o desenho de um pequeno triângulo – e o
botão Parar - botão com o desenho de um pequeno quadrado.
17. Após meia hora de coleta, suspenda a execução do log.
Agora vamos analisar os dados obtidos, os quais foram gravados no arquivo C:\Monitora o
processador_000001.csv.
Exemplo 2: Analisando os dados obtidos com o log Monitora o processador, criado no exemplo anterior.
Para abrir o arquivo com os dados obtidos, faça o seguinte:
1. Faça o logon como administrador ou com uma conta do tipo administrador do computador.
2. Abra o bloco de notas.
3. Abra o arquivo C:\Monitora o processador_000001.csv.
4. Na listagem a seguir temos uma amostra dos dados de monitoração que foram salvos:
“05/01/2002 16:31:04.511”,”99.99991106930112",”237.43538236310363",”Monitora o processador”
***************************************************************************
A listagem apresenta dados para cerca de 4 minutos, com início em 16:31:04.511 e término em
16:35:04.864. A primeira coluna representa o horário da coleta do dado, a segunda coluna é o valor
correspondente ao contador % tempo do processador, a terceira coluna é o valor correspondente ao
contador Interrupções/s. A quarta e última coluna é o nome do log, nome este que é definido pelo
usuário quando da criação do log, conforme visto anteriormente.
Observe que existe um intervalo de 5 segundos entre uma linha e outra, que é exatamente o intervalo
que você configurou no exemplo de criação do log.
5. Feche o bloco de notas.
Com os dados no formato .csv, você pode importá-los facilmente para o Excel ou para o Access, para
fazer uma série de análises, usando as ferramentas destes programas. Por exemplo, você pode utilizar
os dados para calcular a taxa média de ocupação do processador, ou o número médio de interrupções
por segundo. O formato .csv pode ser aberto diretamente no Excel e é facilmente importado pelo
Microsoft Access.
A seguir coloco uma lista resumida (em relação à lista apresentada anteriormente) dos contadores mais
comumente utilizados para verificação do desempenho do computador como um todo e que são
candidatos a serem configurados para coleta automática, utilizando logs de desempenho. Esta lista é
obtida na documentação oficial do Windows Server 2003.
Contadores para identificar gargalos em recursos de memória:
♦ Memória\Bytes disponíveis
♦ Memória\Páginas/s
Contadores para identificar gargalos em recursos de disco:
♦ PhysicalDisk -> % tempo de disco e % Tempo ocioso
♦ PhysicalDisk -> Leituras de disco/seg e Gravações de disco/seg
♦ PhysicalDisk -> Comprimento médio da fila de disco
♦ LogicalDisk -> % de espaço livre
Monitore contadores de memória para determinar se a paginação excessiva está sobrecarregando o disco. Quando o computador tem pouca
IMPORTANTE
memória, o Windows Server 2003 é obrigado a utilizar intensivamente os arquivos de paginação (Swap). O arquivo de trocas, por padrão,
fica na raiz do disco C:, com o nome de pagefile.sys ou pode também ficar em outros discos e até mesmo distribuído em dois ou mais discos,
conforme configurações efetuadas pelo administrador. Com o uso intensivo do arquivo de trocas, as taxas de utilização do disco rígido
aumentam significativamente, porém o problema não é com o sistema de discos e sim devido à falta de memória (que é a causa da
paginação excessiva). Ao acrescentar mais memória RAM, você irá reduzir a utilização do arquivo pagefile.sys e, conseqüentemente, reduzir
as taxas de utilização do disco rígido.
Contadores para identificar gargalos em recursos do processador:
♦ Processador -> Interrupções por segundo
♦ Processador -> % tempo de processador
♦ Processo (processo) -> % tempo de processador
♦ Sistema -> Comprimento da fila de processador

NOTA
Um número muito elevado de interrupções por segundo pode ser causado por problemas em um dispositivo de hardware, ou em um driver
de hardware, conforme descrito anteriormente.
Contadores para identificar gargalos em recursos de rede:
♦ Interface de rede ->Total de bytes/segundo, Bytes enviados/s e Bytes recebidos/s
♦ Objeto_de_camada_de_protocolo -> Segmentos recebidos/s, Segmentos enviados/s, Quadros

enviados/s e Quadros recebidos/s
♦ Servidor -> Total de bytes/segundo, Bytes recebidos/s e Bytes enviados/s
Contadores para identificar gargalos em recursos de impressora:
♦ Fila de impressão -> Bytes impressos/s
♦ Fila de impressão -> Erros de trabalhos
MONTANDO GRÁFICOS DE DESEMPENHO A PARTIR DE INFORMAÇÕES DE ARQUIVOS DE LOG

É possível utilizar o console Desempenho para acessar as informações gravadas em um arquivo de log,
como o que criamos no exemplo anterior. Ao abrir o arquivo podemos especificar para quais contadores
queremos montar o gráfico. Quando abrimos um arquivo de log, evidentemente, somente estarão
disponíveis os contadores para os quais foram salvas informações no arquivo.
Vamos a um exemplo prático, onde acessaremos informações do arquivo C:\Monitora o

processador_000001.csv, criado no exemplo anterior.
Exemplo: Acessando os dados de um arquivo de log já existente.
Para acessar os dados do arquivo C:\Monitora o processador_000001.csv, siga os passos indicados a

seguir:
3. Será aberto o console de monitoração de desempenho, com alguns indicadores já adicionados,
conforme descrito anteriormente.
4. Para limpar as configurações atuais clique no botão Novo conjunto de contadores, que é o primeiro
botão da barra de ferramentas ou pressione Ctrl+E. Todos os contadores serão excluídos. Agora
você irá carregar o arquivo de log C:\Monitora o processador_000001.csv, criado anteriormente.
5. Clique no botão Exibir dados de logs, que é o quarto botão da esquerda para a direita, na barra de
ferramentas, ou pressione Ctrl+L. Será exibida a janela Propriedades do Monitor do sistema, com
a guia Fonte já selecionada. Você utiliza a guia Fonte para informar o arquivo de log a ser carregado.
Figura 7.33 Selecionando o arquivo de log a ser carregado.
6. Na guia Fonte clique na opção Arquivos de log e depois clique no botão Adicionar. Será aberta
a janela Selecionar arquivo de log. Selecione o arquivo C:\Monitora o processador_000001.csv,
7. Clique no botão Abrir. Você estará de volta à guia Fonte, com o arquivo C:\Monitora o
processador_000001.csv já selecionado.
8. Clique em OK e o arquivo de log será carregado. Por padrão ainda não estão sendo exibidas
informações sobre os contadores do arquivo de log. Esta é a próxima etapa, dentre os contadores
que existem no arquivo de log, para qual ou quais queremos exibir informações.
9. Clique no botão Adicionar, botão com um sinal de +, ou pressione Ctrl+I. Será exibida a janela
Adicionar contadores. Abra a lista objeto de desempenho. Observe que somente aparece o
objeto Processador. Isto acontece porque, no arquivo de log que abrimos, somente existem
informações sobre os contadores % tempo do processador e Interrupções/s do objeto Processador.
10. Na lista Selecione contadores da lista, selecione o contador % tempo do processador e clique
no botão Adicionar.
11. Clique em Fechar.
12. Você estará de volta ao console Desempenho. Observe que foi montado um gráfico com os
valores do contador % tempo do processador Time, para o período contido no arquivo de log,
que conforme podemos observar na Figura 7.34 é de 20 minutos e 1 segundo.
Figura 7.34 Gráfico montado com informações do arquivo de log.
Você pode fazer com que o gráfico seja baseado apenas em um determinado período e não em toda a
janela de tempo do arquivo de log. Agora você aprenderá a limitar o período de tempo no qual o
gráfico é baseado.
13. Clique com o botão direito do mouse em qualquer parte do gráfico. No menu de opções que é
exibido clique em Propriedades.
14. Na janela de propriedades que é exibida, dê um clique na guia Fonte.
15. Na parte de baixo da janela existem dois controles deslizantes, que você pode deslocar para
definir uma janela de tempo na qual o gráfico será baseado, conforme exemplo da Figura 7.35:
Figura 7.35 Definindo uma janela de tempo.
16. Defina uma janela de tempo e clique em OK.
17. Você estará de volta ao console Desempenho.
18. Observe que o período dos dados já foi limitado, conforme pode ser conferido no campo
Duração, nos campos logo abaixo do gráfico.
19. Agora você irá configurar algumas propriedades do gráfico.
20. Clique com o botão direito do mouse em qualquer parte do gráfico. No menu de opções que é
exibido clique em Propriedades.
21. Na janela de propriedades que é exibida, dê um clique na guia Gráfico. Nesta guia você pode
definir um título para o gráfico, se serão exibidas grades verticais e horizontais, bem como
definir a escala do eixo vertical. Defina as opções conforme indicado na Figura 7.36:
Figura 7.36 Configurando opções do gráfico.
22. Clique em OK e observe que as alterações já são aplicadas ao gráfico.
23. Veja que o gráfico fica com um aspecto bem melhor, conforme indicado na Figura 7.37:
Figura 7.37 O gráfico após as formatações.
UTILIZANDO ALERTAS PARA MONITORAR SITUAÇÕES LIMITE

O administrador pode configurar alertas com base em contadores de desempenho. Por exemplo, posso
configurar um alerta que é disparado sempre que um determinado contador atinge um valor limite.
Podem ser configuradas diferentes ações como resposta a um alerta: Enviar uma mensagem para um
usuário, normalmente o administrador, gravar um evento no log de eventos do Windows Server 2003,
executar um programa ou iniciar a captura de dados de desempenho, com base nas configurações de
um log predefinido.
A seguir apresento um exemplo prático de criação de um alerta com base no valor limite de um contador.
Exemplo: Criar um alerta que será disparado sempre que o contador % tempo do processador ultrapassar
5%. Como resposta ao alerta, uma mensagem deve ser enviada para o usuário Administrador.
NOTA
Evidentemente que 5% é um valor muito baixo. Estou utilizando este valor apenas para forçar que o alerta seja disparado e com isso você
possa conferir se a mensagem está realmente sendo enviada para o administrador.
Para criar o alerta proposto siga os passos indicados a seguir:
3. No painel da esquerda, clique no sinal de + ao lado da opção Logs e alertas de desempenho.
4. Clique na opção Alertas. Observe que, por padrão, nenhum alerta é criado.
5. Vou criar um novo alerta para monitorar o contador % tempo de processador.
6. Para criar um novo alerta selecione o comando Ação -> Novas configurações de alerta.
7. Surge uma janela solicitando que você digite um nome para o alerta que está sendo criado.
Digite Alerta-Teste, conforme indicado na Figura 7.38 e clique em OK.
8. Será exibida a janela Alerta-Teste com as guias Geral, Ação e Agendar, na qual você define as
características do alerta que está sendo criado.
9. O primeiro passo é adicionar o contador ou os contadores, que serão monitorados. Na guia
Geral dê um clique no botão Adicionar. Será exibida a janela Adicionar contadores, a qual já
foi utilizada em exemplos anteriores. Na lista de objetos selecione Processador e na lista de
contadores selecione % tempo de processador. Clique no botão Adicionar e depois clique no
botão Fechar. Você estará de volta à guia Geral da janela do alerta.
10. Na guia Geral você também pode definir um comentário e o valor limite para o contador que
foi adicionado. No nosso exemplo digite 5, no campo Limite e certifique-se de que na lista
“Alertar quando o valor for” esteja selecionado Superior a. Com isso estou configurando o
alerta para ser disparado quando o contador % tempo de processador atingir um valor superior
a 5%. Suas configurações devem estar conforme indicado na Figura 7.39.
Figura 7.38 Definindo o nome do alerta que está sendo criado.
Figura 7.39 Configurações da guia Geral.
11. Dê um clique na guia Ação. Nesta guia você define uma ou mais ações que serão executadas quando
o alerta for disparado. Para o nosso exemplo quero apenas que uma mensagem seja enviada para o
usuário Administrador. Defina as configurações conforme indicado na Figura 7.40.
12. Clique em OK e o alerta será criado e já será inicializado. Alertas podem ser iniciados e parados,
assim como logs para a captura automática de dados que também podem ser iniciados e parados.
Para parar um alerta que está em andamento, clique no botão Parar – botão com o desenho de
um quadradinho – ou clique com o botão direito do mouse no alerta e, no menu de opções que
é exibido, clique em Parar. A ação associada ao alerta somente será disparada enquanto o alerta
estiver em execução.
13. Na Figura 7.41 mostro o exemplo da mensagem que é enviada para o usuário Administrador
quando o alerta deste exemplo é disparado, ou seja, quando o contador % tempo de processador
atingir mais do que 5%. Esta mensagem foi enviada na estação de trabalho onde o administrador
estava logado, que no exemplo era uma estação de trabalho com o Windows XP Professional.
Ou seja, a mensagem é enviada para onde o administrador estiver logado, independente do
servidor onde está configurado o alerta.
Figura 7.40 Configurações da guia Ação.
Figura 7.41 Mensagem enviada em resposta ao alerta.
UTILIZANDO O CONSOLE DESEMPENHO

PARA MONITORAR O SQL SERVER 2005
Agora vamos praticar um pouco. Neste item vamos monitorar alguns dos objetos de desempenho
disponibilizados pelo SQL Server 2005. São muitos os objetos e respectivos contadores do SQL Server
2005. Para localizar estes objetos na lista de objetos disponíveis, procure por objetos que iniciam com
MSSQL. Podemos fazer o monitoramento de objetos independentemente, para cada instância do SQL
Server. Na Tabela 7.4 temos uma relação entre o nome dos objetos e a respectiva instância do SQL Server.
Tabela 7.4 Relação Objeto x Instância.
Instância Nome do objeto inicia com...
SERVIDOR\SQL2005 MSSQL$SQL2005
SERVIDOR\SRVINST02 MSSQL$SRVINST02
Para cada instância do SQL Server, são disponibilizados, dentre dezenas de outros, os seguintes objetos:
♦ Access Methods
♦ Backup Device
♦ Buffer Manager
♦ Buffer Partition
♦ Cache Manager
♦ Databases
♦ General Statistics
♦ Latches
♦ Locks
♦ Memory Manager
♦ Replication Agents
♦ Replication Distribution
♦ Replication Logreader
♦ Replication Merge
♦ Replication Snapshot
♦ SQL Statistics
♦ User Settable
NOTA
Para uma descrição completa, de todos estes objetos e todos os contadores de cada objeto, acesse o Books.
Agora vamos a um exemplo prático, onde iremos monitorar alguns contadores relacionados à instância
SERVIDOR\SQL2005. Também iremos monitorar contadores do objeto Processador e do objeto Memória.
Exemplo: Utilizar o console Desempenho para monitorar os contadores indicados na Tabela 7.5.
Tabela 7.5 Contadores a serem monitorados.
Objeto Contadores
MSSQL$SQL2005: General Statistics Logins/sec

MSSQL$SQL2005: General Statistics Logouts/sec
MSSQL$SQL2005: General Statistics User Connections
Processador Porcentagem de tempo do processador.
Processador % Tempo de usuário
Memória Mbytes disponíveis.
A seguir temos uma descrição dos contadores do SQL Server para o objeto MSSQL$SQL2005: General
Statistics.
♦ Logins/sec: O número de logins inicializados por segundo na instância em questão.
♦ Logouts/sec: O número de logouts inicializados por segundo na instância em questão.
♦ User Connections: Número de usuários conectados à instância em questão.
Para adicionar os contadores indicados na Tabela 7.5, siga os passos indicados a seguir:
1. Abra o console Desempenho (Iniciar -> Programas -> Ferramentas Administrativas ->
Desempenho).
2. Dê um clique no botão Adicionar (botão com um sinal de +). Surge a janela Adicionar contadores.
3. Na lista de objetos selecione MSSQL$SQL2005: General Statistics.
4. Dê um clique no contador Logins/sec para marcá-lo, depois dê um clique no botão Adicionar.
5. Dê um clique no contador Logouts/sec para marcá-lo, depois dê um clique no botão Adicionar.
6. Dê um clique no contador User connections para marcá-lo, depois dê um clique no botão
Adicionar.
7. Na lista de objetos selecione processador.
8. Dê um clique no contador Porcentagem de tempo do processador para marcá-lo, depois dê um
clique no botão Adicionar.
9. Dê um clique no contador % Tempo de usuário para marcá-lo, depois dê um clique no botão
Adicionar.
10. Na lista de objetos selecione Memória.
11. Dê um clique no contador Mbytes disponíveis para marcá-lo, depois dê um clique no botão
Adicionar.
12. Dê um clique no botão Fechar. Você estará de volta ao console Desempenho.
Na Figura 7.42 temos um exemplo da medição dos contadores adicionados neste exemplo.
Figura 7.42 Monitorando diversos contadores.
13. Na parte de baixo do gráfico, na listagem de contadores, ao clicarmos em um contador, são

exibidos valores Máximos, Mínimos, Médio, o último valor e o período de coleta dos dados.
14. Para pôr um contador em destaque, basta clicar sobre o contador e pressionar Ctrl+H.
UTILIZANDO O PROFILER
O Profiler é uma ferramenta que podemos utilizar para monitorar a atividade em uma ou mais instâncias
de um servidor SQL Server. Entenda-se por atividades desde uma conexão efetuada pelo usuário até os
comandos T-SQL executados através desta conexão.
Com a utilização do Profiler, o DBA pode, por exemplo, monitorar somente as tentativas de conexão
sem sucesso ou somente as consultas que demoram mais do que um determinado tempo para executar.
Com isso, o DBA pode detectar tentativas de acesso indevido, como no caso de sucessivas tentativas de
logon sem sucesso, até consultas mal escritas, com erros de lógica no código T-SQL e que estejam
demorando muito para executar. Enfim, é uma ferramenta em que o DBA pode ter um acompanhamento
do que está sendo executado em uma ou mais instâncias do servidor SQL Server.
Também temos a possibilidade de filtrar as atividades capturadas. Podemos especificar um filtro para
que sejam exibidas apenas as consultas executadas em um determinado Banco de Dados, por exemplo.
A atividade capturada pode ser salva em um arquivo ou em uma tabela de um Banco de Dados, para
análise posterior ou em tempo real. Você pode fazer com que os dados sejam capturados e enviados
para uma tabela, e desenvolver consultas que façam pesquisas nesta tabela.
O conjunto de eventos e ações capturadas define o que chamamos de um “Trace”. Podemos criar um
trace novo, onde vamos definir quais os eventos queremos acompanhar, ou podemos utilizar alguns
modelos de trace que são fornecidos junto com o SQL Server. A seguir descrevemos os principais
modelos de trace já existentes. Estes modelos de trace encontram-se na seguinte pasta:
C:\Arquivos de programas\Microsoft SQL Server\90\Tools\Profiler\Templates\Microsoft SQL Server\90
Os templates que eram disponibilizados com o SQL Server 2000, estão disponíveis em: C:\Arquivos de
programas\Microsoft SQL Server\90\Tools\Profiler\Templates\Microsoft SQL Server\80. Os templates
de trace do SQL Server 7.0 estão disponíveis na pasta: C:\Arquivos de programas\Microsoft SQL
Server\90\Tools\Profiler\Templates\Microsoft SQL Server\70
Para os caminhos indicados anteriormente, considerei que o SQL Server 2005 foi instalado no drive C:
A seguir a descição dos principais modelos de trace disponíveis.
♦ SP_Counts.tdf: Monitora o número de stored procedures que foram executados. Os resultados

são agrupados pelo nome do stored procedure e informa quantas vezes cada um foi executado.
♦ Standard.tdf: Captura informações sobre conexões (login e logout), execução de stored proce-
dures e a execução de comandos SQL em batch, na ordem em que os comandos vão sendo
executados.
♦ TSQL.tdf: Coleta informações sobre todos os comandos T-SQL que foram enviados para o
servidor SQL Server e a data e hora em que o comando foi enviado.
♦ TSQL_Duration.tdf: Coleta o comando T-SQL e o tempo de duração para a execução dos
comandos.
♦ TSQL_Grouped.tdf: Coleta informações semelhantes às coletadas pelo modelo TSQL.tdf, porém

agrupa as informações pelo nome do usuário que enviou o comando.
♦ TSQL_Replay.tdf: Fornece uma série de informações detalhadas sobre os comandos que foram
executados no servidor e permite que os comandos sejam reexecutados no servidor.
♦ TSQL_SPs.tdf: Informa o stored procedure que foi executado, além de informar os comandos
que foram executados dentro do stored procedure. Exibe os comandos na ordem em que fo-
ram executados.
♦ Tuning.tdf: Coleta dados sobre a execução de stored procedures e a execução de comandos

em batch.
Depois que capturamos uma série de comandos enviados para uma instância do SQL Server, podemos
enviar novamente estes comandos para a execução. Na prática, os mesmos comandos são executados
novamente, na ordem em que foram capturados. Este procedimento é útil para testar alterações que
foram feitas no Banco de Dados, para melhorar o desempenho. Ao executarmos novamente os mesmos
comandos, podemos observar se o tempo de execução melhorou após as alterações efetuadas.
De uma maneira geral, devemos utilizar o profiler para as seguintes tarefas:
♦ Monitorar o desempenho de uma instância do SQL Server.
♦ Depurar a execução de comandos T-SQL e stored procedures.
♦ Identificar consultas que estejam com problemas de desempenho, isto é, com um tempo de
execução muito elevado, muito acima do esperado.
♦ Testar a execução de comandos T-SQL e stored procedures durante a fase de desenvolvimento

de uma aplicação, de tal forma que possamos conferir se estes estão executando de acordo com
o esperado.
♦ Testar hipóteses. Podemos capturar as atividades normais em um servidor de produção e executar
esta atividade contra um servidor de teste, no qual fizemos algumas alterações. Com isso
podemos verificar se as alterações efetuadas produzirão os efeitos desejados. Em caso afirmativo,
podemos implementar as alterações no servidor de produção. Ninguém é maluco o suficiente
para fazer testes no servidor de produção (embora eu conheça muita gente que trabalha
exatamente desta maneira, ou seja, sem planejar).
♦ Fazer auditoria de segurança nas atividades de uma instância do servidor SQL Server. Com isso
o administrador pode acompanhar, por exemplo, tentativas de acesso indevido ao servidor.
Exemplo: Vamos utilizar o profiler para fazer o acompanhamento das atividades da instância
SERVIDOR\SQL2005. Utilizaremos o modelo Standard.TDF. Nosso exemplo será constituído dos
seguintes procedimentos:
♦ Procedimento 1: Abrir o profiler e criar um novo trace baseado no modelo Standard.TDF.
♦ Procedimento 2: Gerar atividades na instância SERVIDOR\SQL2005. Iremos gerar atividades

utilizando o SQL Server Management Studio.
♦ Procedimento 3: Voltar ao profiler, parar a captura e observar a atividade capturada. Depois

salvaremos esta atividade em uma tabela chamada TraceEx1, no Banco de Dados Exemplo1
(banco de dados este criado no Capítulo 4). Esta tabela será criada pelo próprio profiler, na
hora de salvar a atividade capturada.
Então, mãos à obra.
♦ Procedimento 1: Para abrir o profiler e criar um novo trace baseado no modelo Standard.tdf,
1. Abra o profiler (Iniciar -> Programas -> Microsoft SQL Server 2005 -> Profiler). Surge a janela do
profiler, indicada na Figura 7.43.
2. Para criar um novo trace, selecione o comando File -> New -> Trace, ou pressione Ctrl+N.
3. Surge uma janela perguntando qual instância do servidor SQL Server queremos monitorar. Na
lista SQL Server selecione SERVIDOR\SQL2005. Para autenticação certifique-se de que a opção
Windows authentication esteja selecionada. Dê um clique em Connect, para efetuar a conexão.
Figura 7.43 A janela principal do profiler.
Surge a janela Trace Properties. Nesta janela podemos definir qual o modelo de trace que será utilizado
e personalizar algumas características do trace, conforme indicado na Figura 7.44.
Figura 7.44 Configurando as propriedades do trace.
4. A guia General já vem selecionada, por padrão. No campo Trace name digite: Trace de teste.
5. Observe que no campo Trace SQL Server já aparece SERVIDOR\SQL2005. Na lista Template
name, certifique-se de que esteja selecionado o modelo Standard (default).
A guia Events Selection: Nesta guia podemos definir quais os eventos que devem ser registrados no
trace. Os eventos que aparecem nesta guia são ligados ao modelo selecionado. Para cada modelo de
trace temos um conjunto diferente de eventos a serem monitorados e capturados pelo profiler. Nesta
guia podemos adicionar ou excluir eventos, para personalizar o trace de acordo com nossas necessidades.
Observe que os eventos estão divididos em uma série de categorias: Cursors, Databases, Errors and
Warnings, etc. Dentro de cada categoria temos uma série de eventos, que podem ser adicionados ao
trace, marcando o evento, ou removidos, simplesmente desmarcando o evento. Para cada evento que
seleciona, você pode marcar uma ou mais colunas, para definir quais informações serão capturadas
para cada evento. Não vamos alterar nada nesta guia.
6. Dê um clique no botão Run para iniciar a captura de eventos pelo profiler.
Sua janela deve estar conforme indicado na Figura 7.45.
Figura 7.45 A captura foi iniciada.
Agora vamos gerar atividades na instância SERVIDOR\SQL2005, para que sejam capturados eventos
no profiler.
7. Minimize o profiler e vamos para o próximo procedimento.
♦ Procedimento 2: Gerar atividades na instância SERVIDOR\SQL2005. Iremos gerar atividades

utilizando o Enterprise Manager e a janela de execução de comandos T-SQL. Faremos algumas
tentativas de logon com a senha incorreta, para gerar um evento de falha de logon.
1. SQL Server Management Studio.
2. Navegue até a instância SERVIDOR\SQL2005 e, depois, até o Banco de Dados Northwind.

Clique com o botão direito do mouse na instância e, no menu de opções que é exibido, clique
em New Query. Será aberta a janela de execução de comandos T-SQL.
3. Execute os seguintes comandos:

USE NorthWind
SELECT * FROM DBO.ORDERS
4. Restaure o profiler e observe que uma série de eventos já foi capturada, conforme indicado na
Figura 7.46.
Figura 7.46 O profiler capturando atividades na instância SERVIDOR\SQL2005.
5. Observe que na figura aparece em destaque o comando executado quando abrimos a tabela
Orders: SELECT * FROM Orders.
6. Minimize o profiler.
♦ Procedimento 3: Voltar ao Profiler, parar a captura e observar a atividade capturada. Depois

salvaremos esta atividade em uma tabela chamada TraceEx1, no Banco de Dados Exemplo2.
Esta tabela será criada pelo próprio profiler, na hora de salvar a atividade capturada.
1. Restaure o profiler.
2. Para parar a captura selecione o comando File -> Stop Trace.
3. No meu caso foram capturados 8261 eventos, sendo que o último evento é justamente a parada
do trace: TraceStop, conforme indicado na Figura 7.47.
Figura 7.47 O evento de parada do trace: Trace Stop.
Poderíamos reiniciar o trace, utilizando o comando File -> RunTrace.
Poderíamos localizar um evento específico utilizando o comando Edit -> Find.
Para descartar todos os eventos capturados utilizamos o comando Edit -> Clear Trace Window.
Podemos gerar um script com todos os comandos capturados. Este Script pode ser gerado para a versão
SQL Server 2002 ou SQL Server 2005. Para isso utilizamos os comandos File -> Export -> Script Trace
Definition -> For SQL Server 2005 ou File -> Export -> Script Trace Definition -> For SQL Server 2000,
respectivamente.
4. Agora vamos salvar o trace em uma tabela do Banco de Dados Exemplo1, criado no Capítulo 3.
5. Selecione o comando File -> Save As -> Trace Table.
6. Surge uma janela solicitando o nome da instância e o tipo de autenticação. Na lista SQL Server,
selecione SERVIDOR\SQL2005, e marque Windows authentication.
7. Dê um clique no botão Connect para conectar com a instância selecionada.
8. Na janela Destination Table, que é exibida, devemos selecionar o nome do Banco de Dados e o
nome da tabela onde serão salvos os dados capturados.
9. Na lista Database selecione Exemplo1.
10. No campo Table, digite TraceEx1, conforme indicado na Figura 7.48.
Figura 7.48 Salvando os eventos capturados.
11. Dê um clique no botão OK e pronto. A tabela TraceEx1 será criada no Banco de Dados
Exemplo1, da instância SERVIDOR\SQL2005 e os dados capturados pelo profiler serão
gravados nesta tabela.
12. Você estará de volta ao profiler. Feche-o.
Você pode abrir o SQL Server Management Studio e acessar a tabela TraceEx1 criada anteriormente. Na
Figura 7.49 podemos ver os dados que foram salvos nesta tabela.
Figura 7.49 A tabela TraceEx1.
CONCLUSÃO
Neste capítulo aprendemos a utilizar uma série de ferramentas e comandos para administração,
monitoramento e otimização do SQL Server 2005.
Aprendemos a criar um plano de manutenção utilizando o assistente Maintenance Plan Wizard. Também
aprendemos a utilizar uma série de comandos, os chamados comandos DBCC. Estes comandos são
utilizados para análise e correção de problemas na estrutura física de um Banco de Dados.
Monitorar o desempenho de um servidor em busca de gargalos é um dos papéis do DBA. É importante

que seja feita uma manutenção periódica para que possamos nos antecipar aos problemas de
desempenho que possam surgir. Com um acompanhamento periódico podemos prever quando um
determinado componente se tornará um gargalo e aí temos condições de tomar as ações necessárias.
Na parte final do capítulo aprendemos a utilizar o profiler, uma ferramenta bastante poderosa, que
permite que seja capturada toda a atividade executada em uma determinada instância do SQL Server.
Capítulo 8
REPLICAÇÃO: CONCEITO,
IMPLEMENTAÇÃO E MANUTENÇÃO
INTRODUÇÃO
Replicação é o processo de manter duas ou mais réplicas (cópias) dos dados em diferentes instâncias
do SQL Server 2005 (podendo até mesmo ser diferentes instâncias de diferentes servidores). Podemos
replicar desde um conjunto de linhas ou colunas de uma tabela até um Banco de Dados inteiro. Com
o SQL Server 2005, temos uma série de funções e assistentes que nos permitem configurar o processo
de replicação. Uma vez estabelecida a replicação, o SQL Server 2005 encarrega-se de manter
sincronizadas as diversas réplicas. No contexto deste capítulo, chamaremos de réplica uma cópia de
um conjunto de dados, mantida automaticamente sincronizada pelo SQL Server, em duas ou mais
instâncias do SQL Server 2005.
A necessidade de replicação não é exclusiva de ambientes de Bancos de Dados. Podemos citar o caso do
Active Directory do Windows 2000 Server ou Windows Server 2003. Em um domínio do Windows
2000, a informação sobre os diversos objetos da rede é armazenada em um Banco de Dados hierárquico:
Active Directory. Existem servidores chamados DCs (Domain Controlers), os quais têm uma cópia
completa do Banco de Dados do Active Directory. Alterações podem ser feitas em qualquer DC do
domínio. Como é que o Windows faz para que todos os DCs recebam as alterações feitas em um
determinado DC? Utilizando o mecanismo de replicação.
O mecanismo de replicação do Windows é controlado pelo próprio Windows, e não tem nenhuma relação com os mecanismos de replicação
NOTA
do SQL Server 2005, os quais iremos tratar neste capítulo. Apenas citamos o caso do Active Directory para ilustrar uma situação real onde a
replicação é utilizada. Também poderíamos ter citado uma rede com o NDS da Novell, ou uma rede com servidores Lotus Notes ou Microsoft
Exchange Server.
O processo de replicação é bastante confiável, sendo que este é capaz de reiniciar do ponto onde foi
interrompido, em caso de falhas de comunicação ou outra falha qualquer. Com isso o SQL Server 2005
é capaz de garantir a integridade e a confiabilidade dos dados replicados.
No início do capítulo veremos que, com a complexidade dos sistemas de informação atuais, a replicação
é muitas vezes mais do que uma opção, é uma necessidade. Analisaremos diferentes cenários onde o
uso da replicação ajuda na manutenção de um ambiente distribuído, onde temos diversos servidores
de Banco de Dados, sendo que estes estão distribuídos em diferentes localizações geográficas.
Em seguida, veremos qual a “metáfora” utilizada pelo SQL Server 2005 para viabilizar o processo de
replicação. Veremos a definição dos principais termos utilizados quando tratarmos com replicação no
NOTA
SQL Server 2005.
Na seqüência, veremos os tipos de replicação existentes no SQL Server 2005. Para diferentes
necessidades temos diferentes tipos de replicação que podem ser implementados. Aprenderemos a
identificar qual o tipo mais adequado para uma determinada situação. Também falaremos sobre os
modelos físicos de replicação e como os diferentes tipos de replicação se encaixam nos diferentes
modelos físicos de replicação.
Após entendidos os conceitos associados com a replicação e apresentados os diferentes tipos e modelos
físicos, estamos aptos a partir para a implementação. Aprenderemos a configurar a replicação, através
CAPÍTULO 8 – REPLICAÇÃO: CONCEITO, IMPLEMENTAÇÃO E MANUTENÇÃO
de exemplos práticos, passo a passo. Como temos duas instâncias do SQL Server 2005 instaladas,
vamos configurar a replicação entre as duas instâncias e entre dois Bancos de Dados da mesma instância.
KNOW-HOW EM: FUNDAMENTOS BÁSICOS SOBRE REPLICAÇÃO

PRÉ-REQUISITOS
METODOLOGIA
♦ Apresentação sobre os conceitos básicos de replicação.
A replicação nos permite manter cópias de um conjunto de dados em diferentes localizações. São
muitas, conforme veremos a seguir, as aplicações práticas para a replicação. Uma vez configurado o
processo de replicação, o SQL Server 2005 mantém, automaticamente, sincronizadas as diversas cópias.
Vamos imaginar a rede de uma grande empresa, com diversos escritórios espalhados pelo mundo. Em
cada um destes escritórios temos uma rede local. As diversas redes locais são conectadas por linhas de
comunicação de dados de diferentes velocidades. O que acabamos de descrever nada mais é do que
uma típica WAN – Wide Area Network. Na Figura 8.1 temos uma representação genérica da WAN da
nossa empresa fictícia. Chamaremos esta empresa de ABC Ltda.
Figura 8.1 A WAN da empresa ABC Ltda.
Agora vamos analisar algumas situações onde pode ser necessária a utilização de replicação.
Situação 1: Em cada um dos escritórios da empresa ABC Ltda. temos uma rede local. Em cada rede local
temos um servidor SQL Server 2005 com diversos Bancos de Dados. Na Tabela 8.1, temos o nome dos
servidores SQL Server 2005 de cada localidade.
Tabela 8.1 Servidores de cada localidade.
Localidade SERVIDOR\instância
São Paulo SQLSRVSP\PRODUÇÃO

Rio de Janeiro SQLSRVRJ\PRODUÇÃO
Porto Alegre SQLSRVPA\PRODUÇÃO
Belo Horizonte SQLSRVBH\PRODUÇÃO
Os pedidos dos clientes de cada região são digitados em um aplicativo de vendas, desenvolvido usando
VB.NET, o qual armazena as informações no Banco de Dados Vendas do servidor SQL Server 2005 da
respectiva localidade. Durante a noite, uma cópia dos pedidos feitos durante o dia, em cada região,
deve ser enviada para o Banco de Dados do escritório de São Paulo. Os dados devem ser consolidados
em uma segunda instância do SQL Server 2005 do servidor de São Paulo. Esta instância é denominada
SQLSRVSP\CONSOLIDADO e a sua função é conter uma cópia completa dos pedidos realizados em
todo o Brasil. Como podemos implementar a solução solicitada?
Na Figura 8.2, temos uma visualização para o problema proposto.
Figura 8.2 Pedidos digitados em diferentes servidores SQL Server 2005.
Para solucionar o problema proposto, a melhor solução é utilizarmos replicação. Podemos configurar
os servidores SQL Server, de tal forma que os servidores que receberam os pedidos em São Paulo, Rio de
Janeiro, Belo Horizonte e Porto Alegre enviem os pedidos do dia para a base consolidada em um Banco
de Dados da instância SQLSRVSP\CONSOLIDADO. Desta maneira, todas as noites os servidores ficam
enviando cópias (replicando) dos pedidos recebidos durante o dia, para o Banco de Dados consolidado.
Após feitas as replicações, uma cópia de todos os pedidos estará disponível no Banco de Dados
consolidado. É interessante observar mais uma vez que, após configurada a replicação, esta continua
funcionando automaticamente, ou seja, não precisamos configurar a replicação todos os dias.
Poderíamos fazer com que esta replicação ocorresse de hora em hora ou de vinte em vinte minutos. O
que vai definir o intervalo de replicação são as necessidades da empresa e as velocidades dos links de
comunicação disponíveis. Na Figura 8.3, temos uma visão deste processo de replicação.
Figura 8.3 Escritórios replicando dados para a base consolidada.
Situação 2: Agora vamos mudar um pouco as nossas exigências. Vamos supor que todos os escritórios
também devam ficar com uma cópia completa de todos os pedidos. Como a replicação pode nos ajudar?
Muito simples mais uma vez. Poderíamos configurar a replicação de tal maneira que os escritórios
enviassem os pedidos para a base consolidada. Após a replicação ter sido completada com sucesso,
poderíamos iniciar um novo ciclo de replicação, onde a base consolidada passa a enviar dados para os
escritórios regionais. Ao final deste segundo ciclo de replicação, todos os servidores SQL Server ficariam
com uma cópia idêntica do Banco de Dados de pedidos, cópia esta que contém todos os pedidos.
Na Tabela 8.2, temos um exemplo de como poderíamos configurar estes dois ciclos de replicação.
Neste caso fizemos uma programação da replicação, de tal maneira que todos os Bancos de Dados
fiquem com uma cópia completa dos pedidos. A partir das 22h, os escritórios começam a replicar com
a base consolidada em São Paulo, cada um enviando os pedidos do dia. Após o último escritório ter
replicado, a base consolidada está completa. A partir da zero hora (00:00), a base consolidada começa
a replicar com os escritórios. Ao final deste segundo ciclo de replicação, os escritórios também terão
uma base completa, com todos os pedidos.
Tabela 8.2 Agendamento das replicações.
Hora Descrição
22:00 Porto Alegre envia os pedidos para a base consolidada.

22:30 Rio de Janeiro envia os pedidos para a base consolidada.
23:00 Belo Horizonte envia os pedidos para a base consolidada.
23:30 São Paulo envia os pedidos para a base consolidada. Envia de uma instância para a
outra, no mesmo servidor.
00:00 São Paulo envia a base completa para Porto Alegre.
00:30 São Paulo envia a base completa para Rio de Janeiro.
01:00 São Paulo envia a base completa para Belo Horizonte.
Na Figura 8.4, temos uma visualização deste processo de replicação, em que a sincronização dos dados
ocorre em dois sentidos.
Figura 8.4 Replicação nos dois sentidos.
A replicação pode ser implementada de diferentes maneiras. Por exemplo, em cada replicação pode ser
enviada uma cópia completa de todo o Banco de Dados. Outra maneira é fazer com que sejam enviados
apenas os registros que foram alterados ou inseridos. Neste capítulo veremos os diferentes tipos de
replicação que podem ser implementados com o SQL Server 2005 e as características de cada um.
FATORES LIGADOS À REPLICAÇÃO

Quando formos planejar um esquema de replicação, como forma de manter sincronizadas duas ou
mais cópias de um determinado conjunto de dados, devemos levar em consideração diversos fatores.
A seguir descrevemos quais são estes fatores.
♦ Latência: É o tempo que demora para que dois conjuntos de dados estejam sincronizados. Com a
replicação, não temos como garantir que as diversas réplicas estejam exatamente iguais o tempo
todo. À medida que alterações vão sendo introduzidas em uma réplica, demora um certo tempo
(latência), até que estas alterações sejam propagadas para as demais réplicas. Devemos levar em
consideração qual o nível de latência aceitável para cada caso: minutos, horas, dias, etc.
Existe uma técnica conhecida como “Transações Distribuídas – Distributed Transactions”. Com esta técnica, à medida que uma transação é
NOTA
aplicada em um Banco de Dados, a mesma transação é, automaticamente, aplicada nas demais réplicas do Banco de Dados. Desta forma, é como
se a alteração estivesse sendo feita, ao mesmo tempo, em todos os Bancos de Dados. A grande vantagem desta técnica é que as diversas cópias
estão perfeitamente sincronizadas, o tempo todo. O grande problema com Distributed Transactions é quando um dos servidores, que contém uma
das cópias, está fora do ar. Neste caso não temos como aplicar as transações neste servidor. Com isso, quando o servidor voltar a estar disponível,
precisamos utilizar uma outra técnica para sincronizá-lo com os demais, antes que ele volte a ser colocado online, em produção.
♦ Autonomia da réplica: Este fator tem a ver com a possibilidade de o servidor em que está uma
réplica poder continuar em funcionamento, caso o servidor perca o contato com os demais
servidores. A perda de contato pode ser ocasionada, por exemplo, devido a uma falha na linha
de comunicação de dados. No caso de replicação, o servidor pode continuar funcionando sem
problemas. Quando a comunicação for restabelecida, os dados passarão a ser sincronizados, de
acordo com a programação da replicação. Imagine no caso da empresa ABC, que tem escritórios
em São Paulo, Rio de Janeiro, Belo Horizonte e Porto Alegre. Um dos escritórios não pode parar
de aceitar pedidos porque houve uma falha na linha de comunicação. O escritório continua
aceitando pedidos e, quando a linha de comunicação for restabelecida, os dados são replicados
com a base consolidada.
♦ Conflitos de atualização: No caso de diversas réplicas, em que os dados podem ser alterados
em qualquer delas, podemos ter uma situação em que o mesmo registro foi alterado em duas
réplicas diferentes. Ao replicar este registro, teremos um conflito de replicação. O SQL Server
tem alguns mecanismos automáticos para resolução deste tipo de conflitos.
♦ Velocidade dos links de WAN: Este é um fator de grande importância. Replicação implica
informação sendo enviada pela rede. Devemos fazer uma estimativa do volume de dados a ser
replicados e comparar com a capacidade do link disponível. Isto evita que, devido à replicação,
o link fique sobrecarregado, impedindo que outras aplicações críticas, como por exemplo e-
mail, tenham um desempenho satisfatório.
BENEFÍCIOS DA REPLICAÇÃO E ONDE UTILIZÁ-LA

O benefício mais óbvio da replicação é a possibilidade de mantermos, em diferentes servidores, cópias
de um mesmo conjunto de dados. Com base nesta idéia básica, podemos dizer que a replicação deve
ser considerada como solução, nas seguintes situações:
♦ Permitir que diferentes localidades tenham à disposição uma cópia atualizada de um Banco de
Dados. Por exemplo, podemos ter a matriz replicando um catálogo de produtos e uma lista de
preços para suas diversas filiais. Neste caso a replicação é uma maneira de manter todas as localidades
com dados atualizados, pois as alterações feitas no Banco de Dados original da matriz (conhecido
como Banco de Dados mestre) são replicadas automaticamente para as demais localidades.
♦ Manter em servidores separados, por questões de desempenho, duas cópias idênticas do mesmo
Banco de Dados. Um exemplo típico é a separação do Banco de Dados para ambientes OLTP
(On Line Transaction Processing) e OLAP (On Line Analytical Processing). Um ambiente OLTP
é um ambiente onde são feitas basicamente entradad de dados ou consultas simples, como por
exemplo localizar o cadastro de um cliente para consulta ou atualização. Um exemplo típico
deste ambiente é uma central de atendimento ao contribuinte em uma unidade da Receita
Federal ou do INSS. Neste caso, há uma série de terminais dos atendentes. Estes terminais estão
conectados a um Banco de Dados centralizado. As operações realizadas normalmente limitam-
se a digitar um novo registro ou buscar um já existente. As aplicações de um ambiente OLAP,
no entanto, realizam consultas bastante complexas, tipicamente consultas de referência cruzada.
Este tipo de ambiente é utilizado, normalmente, por gerentes e “tomadores” de decisão, que
necessitam de dados consolidados. Um bom exemplo é um gerente que utiliza uma aplicação
de Data Mining, procurando padrões de crescimento de vendas de um determinado produto
em períodos específicos do ano, em regiões específicas. Neste caso, são elaboradas consultas
bastante complexas que exigem bastante do Banco de Dados, em termos de recursos e de
desempenho. Separar aplicações destes dois ambientes em servidores SQL Server separados é
uma boa solução para melhorar o desempenho. Aí utilizamos a replicação para manter as duas
cópias sincronizadas. Nesta situação as alterações são feitas pelos aplicativos do ambiente OLTP
e são replicadas para o Banco de Dados que dá suporte ao ambiente OLAP.
♦ Sempre que precisamos copiar e distribuir um conjunto de dados para diversas localidades.
♦ Permitir que alterações sejam feitas em diversas réplicas do Banco de Dados e fazer com que
estas modificações sejam repassadas para as demais cópias. Sempre devemos considerar a
possibilidade de conflitos de replicação.
KNOW-HOW EM: O MODELO DE REPLICAÇÃO DO SQL SERVER 2005

PRÉ-REQUISITOS
♦ Noções sobre replicação.
METODOLOGIA
♦ Apresentação do modelo de replicação do SQL Server 2005 e dos tipos de replicação existentes.
O SQL Server 2005 utiliza um modelo de replicação, muitas vezes chamado de metáfora de replicação,
baseado nos seguintes elementos:
♦ Publisher
♦ Distributor
♦ Subscribers
♦ Publicação
♦ Article
Este é praticamente o mesmo modelo de replicação utilizado pelo SQL Server 2000. A replicação foi uma área onde não houve grandes
NOTA
novidades no SQL Server 2005, em relação ao SQL Server 2000. Foram feitas pequenas melhorias, mas a estrutura básica e conceitual da
replicação permaneceu a mesma do SQL Server 2000.
Com uma visão geral, podemos dizer que o publisher é quem publica informações a serem replicadas
para um ou mais dubscribers. Sendo que as informações não são enviadas diretamente do publisher
para os subscribers, pois no meio do caminho havia um distributor, havia um distributor no meio do
caminho. Drummond que me perdoe pelos direitos autorais.
Bem, falando sério, vamos detalhar estes diversos elementos que fazem parte do modelo de replicação
do SQL Server 2005. Para melhor explicarmos estes elementos, vamos nos basear na Figura 8.5.
Figura 8.5 O modelo de replicação do SQL Server 2005.
Um servidor SQL Server 2005 pode representar um ou mais dos papéis indicados na Figura 8.5: Pub-
lisher, distributor ou subscriber. Em toda replicação, temos a presença destes três papéis. Podemos ter
diferentes servidores realizando cada um dos papéis ou, em um caso extremo, um único servidor
configurado como publisher, distributor e subscriber. Esta última situação pode parecer absurda, mas é
a configuração que vou utilizar para os exemplos deste livro. No computador que estou utilizando
neste livro, vou configurar uma instância do SQL Server como publisher e distributor e a outra instância
como subscriber. Na empresa é comum termos pelo menos as funções de publisher e subscriber em
servidores diferentes. Vamos detalhar um pouco mais cada uma destas funções.
PUBLISHER
Um servidor atuando como publisher é um servidor SQL Server 2005 que está disponibilizando dados
para serem replicados para outros servidores. O publisher mantém a cópia original dos dados e envia o
conjunto de dados a ser replicado para um ou mais distributors. O publisher disponibiliza conjuntos
definidos de dados através de publicações. Podemos ter uma ou mais publicações, cada uma
representando um conjunto de dados. Além de disponibilizar dados para a replicação, o publisher
possui mecanismos para detectar quais dados sofreram alterações e, portanto, definir quais dados
devem ser incluídos no conjunto de dados a ser replicado. Por padrão, esta função não está habilitada
em um servidor SQL Server 2005. Esta função somente será habilitada quando configurarmos este
servidor para atuar como um publisher.
Mais uma vez é importante lembrar que, quando estamos falando de servidor SQL Server 2005, queremos fazer referência a uma instância
NOTA
do SQL Server 2005. Se existirem, por exemplo, duas instâncias do SQL Server 2005 instaladas no mesmo computador, é como se fossem
dois servidores completamente independentes, sendo que um deles pode disponibilizar dados para replicação e o outro não. Ou pode ser que
o conjunto de dados disponibilizado pelas diferentes instâncias seja completamente distinto.
DISTRIBUTOR
O distributor recebe do publisher uma cópia dos dados que foram alterados e devem ser replicados e
disponibiliza estes dados para um ou mais subscribers. A função do distributor varia com o tipo de
replicação que estamos implementando. No próximo item trataremos dos diferentes tipos de replicação
do SQL Server 2005.
Figura 8.6 Um distributor com vários publishers.
Podemos ter um distributor local, situação em que o distributor é o mesmo servidor que publica os
dados (publisher), isto é, as duas funções estão configuradas na mesma instância do mesmo servidor
SQL Server 2005. Também podemos ter um distributor remoto, onde o servidor que desempenha a
função de distributor não é o mesmo que desempenha a função de publisher. Também podemos ter
situações em que um único distributor recebe dados de vários publishers e envia estes dados para um
ou mais subscribers, conforme indicado na Figura 8.6.
SUBSCRIBER
Um subscriber é um servidor SQL Server que armazena uma réplica dos dados e recebe atualizações
periódicas dos dados. Os dados recebidos pelo subscriber podem ser alterados em determinadas
configurações. O subscriber pode inclusive publicar um outro conjunto de dados, situação na qual
estará atuando como publisher para outros servidores. Analisaremos alguns exemplos mais adiante.
Ao configurarmos um servidor como subscriber temos que informar em quais publicações estamos
nos inscrevendo.
NOTA
Um conceito fundamental que não devemos esquecer é que todo o conjunto de dados a ser replicado somente pode ter um único publisher,
ou seja, não podemos ter o mesmo conjunto de dados, isto é, a mesma publicação sendo publicada por dois ou mais publishers diferentes.
Bem, você já deve estar curioso para saber um pouco mais sobre publicações. Então, vamos lá, agora é
hora de detalhar os conceitos de artigos (Article) e publicações.
ARTIGO
Um artigo pode ser uma tabela de dados ou um objeto do Banco de Dados, como um stored procedure
que é configurado para replicação. Podemos ter um artigo que engloba uma tabela inteira, ou um
artigo que engloba apenas algumas colunas – o que chamamos de filtragem vertical. Também podemos
ter artigos que englobam apenas algumas linhas, o que chamamos de filtragem horizontal. Podemos
ter ainda artigos que englobam stored procedures ou views. No caso de um artigo que engloba uma
view, podemos publicar dados de várias tabelas.
Vamos considerar o caso de um escritório que mantém um Banco de Dados com informações sobre
produtos: CódigoDoProduto, DescriçãoDoProduto, CódigoDaCategoria, Preço, Fornecedor,
CódigoEmbalagem, DataDeEntrada, UnidadesEmEstoque, etc. Podemos ter uma situação em que os
escritórios regionais necessitem de apenas algumas informações, como por exemplo: CódigoDoProduto,
DescriçãoDoProduto, Preço e UnidadesEmEstoque. Neste caso podemos criar um artigo que inclua
apenas as colunas necessárias. Em vez de replicar a tabela completa, replicamos apenas os campos
utilizados pelos escritórios regionais. Neste caso estamos aplicando um filtro vertical, no qual apenas
algumas colunas são replicadas.
Também poderíamos ter uma situação especial, onde determinado escritório somente revendesse
produtos de determinadas categorias. Neste caso, devemos aplicar um filtro horizontal, onde o nosso
artigo somente incluirá as linhas com os produtos que se encaixam nas categorias definidas pelo filtro.
Também é possível aplicar uma combinação de filtros verticais e horizontais, onde apenas algumas
colunas e alguns registros são incluídos no artigo.
Com isso podemos concluir que é através da criação de um artigo que definimos quais dados devem
ser replicados. Isto evita que tenhamos que replicar uma tabela inteira quando apenas um subconjunto
dos dados precisa ser replicado.
Também podemos incluir a definição de um stored procedure como parte de um artigo. Outra
possibilidade é incluir no artigo a execução de um Stored Procedure, ao invés de incluir os dados
alterados pela execução do Stored Procedure. Com isso a mesma execução acontece no Banco de Dados
de destino, processando as alterações neste Banco de Dados da mesma maneira que foram processadas
no original. O resultado é que os dois conjuntos de dados ficam iguais, porém com um tráfego de rede
bem menor, pois ao invés de replicar todos os dados que foram alterados, apenas são replicados os
comandos que alteraram os dados, para que estes mesmos comandos sejam executados em outras
réplicas, nos servidores de destinos (subscribers).
Na Figura 8.7, temos um exemplo onde aplicamos um filtro vertical para criar um artigo que inclui
apenas algumas colunas da tabela Orders. Incluimos as seguintes colunas: OrderID, CustomerID,
OrderDate e ShipCountry.
Figura 8.7 Um artigo com filtro vertical.
Figura 8.8 Um artigo com filtro horizontal.
Na Figura 8.8, temos um exemplo onde aplicamos um filtro horizontal, para criar um artigo que inclui
apenas alguns registros da tabela Orders. Incluimos apenas os registros para o PaísDeDestino = ‘Brazil’.
Na Figura 8.9, temos um exemplo onde aplicamos um filtro vertical e um filtro horizontal para criar
um artigo que inclui apenas alguns registros da tabela Orders. Incluimos apenas as colunas OrderID,
CustomerID, OrderDate e ShipCountry, para os registros em que PaísDeDestino = ‘Brazil’.
NOTA
Na parte prática deste capítulo aprenderemos a criar artigos e a aplicar os diferentes tipos de filtros.
Figura 8.9 Um artigo com filtro horizontal e vertical.
PUBLICAÇÕES
Uma publicação é um conjunto de um ou mais artigos de um Banco de Dados. A publicação é a
unidade de replicação. Em outras palavras, o subscriber se inscreve em uma publicação e não em um
artigo. Mesmo que somente tenhamos que replicar dados de um único artigo, devemos criar uma
publicação que inclui este único artigo.
Normalmente uma publicação reúne os diversos artigos que dão suporte a uma determinada aplicação.
Vamos supor que, nos escritórios regionais, uma aplicação de atendimento ao cliente necessite dados
de diversas tabelas de um determinado Banco de Dados. A maneira mais prática de distribuir estes
dados é criar uma série de artigos, criar uma publicação que inclui os diversos artigos e replicá-la para
os escritórios regionais.
Podemos criar uma ou mais Publicações em um Banco de Dados, porém uma publicação não pode
conter artigos de diferentes Bancos de Dados.
Na Figura 8.10 temos uma visão geral da utilização dos diversos elementos apresentados nesta seção; é
a representação dos diversos elementos que compõem o modelo de replicação do SQL Server 2005.
Figura 8.10 Publisher, distributors, subscribers, artigos e publicações.
Temos um publisher no qual foram criadas duas Publicações. Cada publicação contém vários artigos.
Este publisher está enviando suas alterações para dois distributors. Para cada um dos distributors,
temos vários subscribers, sendo que um dos subscribers está inscrito para receber dados dos dois dis-
tributors. Vejam que na rede de uma grande empresa, com filiais em diversos pontos do país ou até
mesmo em diversos países, podemos chegar a um modelo de replicação bastante sofisticado. Por isso é
fundamental entender os conceitos que foram apresentados na parte inicial deste capítulo, para que
possamos fazer um planejamento cuidadoso da replicação.
Um pouco mais de paciência e teoria e logo partiremos para implementar a replicação na prática.
KNOW-HOW EM: SUBSCRIÇÕES E TIPOS DE SUBSCRIÇÕES

PRÉ-REQUISITOS
♦ Conhecer o modelo de replicação do SQL Server 2005.
METODOLOGIA
♦ Apresentação do conceito de subscrição e dos tipos de subscrições existentes.
Chamamos de subscrição o processo pelo qual um servidor se inscreve para receber cópia dos dados de uma
ou mais publicações. Ao se inscrever para receber cópias dos dados o servidor torna-se um subscriber.
Podemos ter dois tipos de subscrições: Pull subscription e Push subscription. O tipo de subscrição
define como a subscrição é criada e administrada e também de que maneira os dados serão replicados.
PUSH SUBSCRIPTION
Este tipo de subscrição é feito durante a criação ou administração de uma publicação. Neste tipo de
subscrição, o distributor é responsável por enviar (push = empurrar) as alterações para um ou mais
subscribers. Note que push significa “empurrar” e não puxar. Uma analogia que pode ser utilizada é que
neste tipo de subscrição é o distributor que “empurra”, envia as alterações para um ou mais subscribers.
Utilizamos Push subscriptions quando queremos ter um controle centralizado sobre o agendamento
das replicações. É muito mais fácil configurar várias subscrições em um único servidor, no caso o
distributor, do que ter que configurar a subscrição em diversos servidores, no caso os diversos subscrib-
ers. Neste caso, é do distributor a iniciativa de enviar as alterações para os subscribers (é o distributor
que “empurra” as alterações para os subscribers).
Assim, o “Agente de replicação”, que é o serviço responsável por fazer a replicação, roda no distributor
ou no publisher, dependendo de como foi feita a configuração da replicação. Devemos ter em mente
que este agente irá consumir recursos como memória e processador no distributor ou no publisher.
Caso tenhamos um número considerável de subscribers, devemos considerar esta necessidade de recursos
de memória e processamento.
Lembre “push não é puxar”; “push é empurrar”, ou seja, o distributor é o responsável por enviar as
alterações para os subscribers conforme o agendamento configurado.
PULL SUBSCRIPTIONS
Este tipo de subscrição é feito no subscriber, que tomará a iniciativa de solicitar o início da replicação
e envio dos dados do distributor para o subscriber. Pull significa puxar, ou seja, o subscriber “puxa” os
dados atualizados que estão no distributor.
Com este tipo de subscrição deixamos o controle e o agendamento da replicação a cargo de cada
subscriber. A administração fica mais distribuída, e ao mesmo tempos damos maior liberdade para
cada subscriber. Por exemplo, localidades ligadas por links mais lentos podem programar a replicação
em períodos mais espaçados (maior latência na atualização dos dados). Este tipo de subscrição também
é indicada para usuários móveis. Por exemplo, um vendedor que, ao atender o cliente, conecta-se à
rede da empresa através da linha telefônica e dispara uma replicação (puxa) para atualizar uma tabela
de preços que está no SQL Server 2005 instalado no seu notebook.
Para Pull subscriptions o agente de replicação roda no subscriber, consumindo memória e processador
deste equipamento.
KNOW-HOW EM: TIPOS DE REPLICAÇÃO

PRÉ-REQUISITOS
METODOLOGIA
♦ Apresentação dos tipos de replicação existentes no SQL Server 2005.
Temos três tipos de replicação no SQL Server 2005: Snapshot replication, Transactional replication e Merge
replication. Neste item veremos as características de cada um dos tipos de replicação, bem como suas diferenças.
Ao criarmos uma publicação, também definimos o tipo de replicação que será utilizado para esta publicação.
Em um mesmo Banco de Dados, podemos ter diferentes Publicações com diferentes tipos de replicação.
Vamos analisar as diferentes características de cada um dos tipos de replicação.
SNAPSHOT REPLICATION
Com este tipo de replicação, todo o conjunto de dados é replicado a cada intervalo programado.
Mesmo dados que não foram alterados serão também replicados. Um ou mais subscribers são atualizados
com uma cópia exata dos dados publicados pelo publisher. São enviados, para os subscribers, todos os
dados, quer tenham sido modificados ou não.
É o tipo mais simples de replicação, pois os servidores envolvidos na replicação não precisam monitorar
os dados para verificar quais alterações foram feitas, uma vez que todos os dados são replicados. A
principal desvantagem deste tipo de replicação é que ela transmite uma grande quantidade de
informações a cada ciclo de replicação. Em links de WAN, dependendo do volume de dados a ser
replicado, pode ser inviável a utilização de snapshot replication.
Algumas características da snapshot replication:
♦ Não é indicada para grandes volumes de dados.
♦ Exige pouco do processador, uma vez que não existe a necessidade de um monitoramento
constante para verificação das alterações efetuadas no conjunto de dados a ser replicado.
♦ Possui uma latência elevada, sendo a latência igual ao intervalo de replicação. Por exemplo,
se uma snapshot replication está programada para ocorrer uma vez ao dia, a latência será
de até 24 horas.
Quando falamos do monitoramento das alterações, o envio dos dados a serem replicados para o distributor e outras tarefas ligadas à
NOTA
replicação, estamos nos referindo a uma série de agentes de replicação. Os agentes de replicação são programas que rodam como serviços
e executam uma série de tarefas que viabilizam a replicação dos dados entre diferentes servidores. Temos, por exemplo, um snapshot agent,
um distributor agent e assim por diante. Falarei mais sobre agentes ao longo deste capítulo.
TRANSACTIONAL REPLICATION
Neste tipo de replicação somente as alterações efetuadas no publisher é que são replicadas para um ou
mais subscribers. Qualquer alteração feita, em um ou mais artigos de uma publicação, é imediatamente
capturada a partir do log de transações e replicada para o distributor. Dependendo das configurações e
da velocidade de conexão entre os servidores, podemos manter as diversas réplicas sincronizadas quase
que instantaneamente.
A principal vantagem é que podemos manter as diversas réplicas praticamente idênticas, diminuindo
bastante a latência (questão de segundos) de atualização entre as diversas réplicas. A grande desvantagem
é que este monitoramento contínuo em busca das alterações implica uma maior exigência de memória
e processamento no servidor SQL Server.
Um detalhe importante a ser observado é a autonomia das réplicas. Para manter-se atualizada, a réplica
precisa estar em contato com os demais servidores que participam da replicação, mais especificamente,
com o subscriber e o distributor. Este fator pode ser um problema para o caso de servidores em localidades
remotas, ligados à rede da empresa por links de WAN de baixa velocidade (links de 128 KB ainda são
bastante comuns em cidades do interior).
NOTA
Apenas transações concluídas (committed transactions) serão replicadas para os subscribers, e serão aplicadas nas réplicas, na mesma ordem
em que foram aplicadas no Banco de Dados original.
Este é o tipo de replicação que mantém os dados o mais atualizados possível, com o menor nível de
latência em relação aos demais tipos de replicação do SQL Server 2005.
NOTA
Tanto a Snapshot replication quanto Transactional replication somente permitem que alterações sejam feitas no publisher, isto é, os dados
não podem ser alterados no subscriber. Existe, porém, um mecanismo que combina dois itens: a opção “Immediate Update Subscribers
Option” e “Two-phase commit protocol”. Com estas duas opções, os dados podem ser alterados nos subscribers e as alterações serão aplicadas
no publisher ao mesmo tempo, através da utilização do protocolo Two-phase commit protocol.
A seguir descrevo as situações, onde é indicado o uso da replicação do tipo Transactional Replication:
♦ Para fazer com que as alterações sejam repassadas para os subscribers, com a menor latência possível.
♦ Os dados replicados serão utilizados por aplicações que precisam de um tempo de latência
muito baixo, o menor possível.
♦ Em situações onde existe um grande número de operações de inserção, atualização e exclusão

no publisher.
♦ Quando o publisher ou o subscriber não for um Banco de Dados do SQL Server, tais como o
ORACLE ou o DB2 da IBM.
MERGE REPLICATION
A principal característica deste tipo de replicação é que alterações podem ser feitas em qualquer uma
das réplicas dos dados. As alterações feitas em uma das réplicas serão repassadas para as demais réplicas.
O SQL Server 2005 utiliza um mecanismo próprio para resolução de conflitos de replicação.
Ao iniciarmos o processo de replicação, temos uma snapshot replication na primeira vez que os dados
são enviados para um ou mais subscribers. Na seqüência, o mecanismo de replicação fica monitorando
as alterações efetuadas nas diversas réplicas e fica repassando as alterações para as demais réplicas. Não
temos a garantia de que todas as réplicas estarão perfeitamente sincronizadas instantaneamente. Porém
temos a certeza de que as diversas réplicas irão convergir com o passar do tempo.
O SQL Server 2005 adiciona, automaticamente, um coluna com dados do tipo Identificador Único às
tabelas que fazem parte da replicação. Os valores desta coluna são criados e mantidos pelo mecanismo
de replicação do SQL Server.
KNOW-HOW EM: OS AGENTES DE REPLICAÇÃO NO SQL SERVER 2005

PRÉ-REQUISITOS
♦ Conhecer os tipos de replicação existentes no SQL Server 2005.
METODOLOGIA
♦ Apresentação dos agentes de replicação existentes no SQL Server 2005.
O suporte à replicação no SQL Server 2005 é feito por um conjunto de agentes, os chamados “SQL
Server Replication Agents”. Estes agentes são os responsáveis por fazer com que os dados sejam passados
do publisher para um ou mais distributors e destes para um ou mais subscribers. Um agente nada mais
é do que um serviço rodando no Windows. A seguir, vamos ver um pouco sobre os agentes existentes
no SQL Server 2005.
♦ Snapshot agent: Este agente é responsável por criar e distribuir o conjunto de dados a ser replicado
do publisher para o distributor. Além da definição do conjunto de dados a ser replicado, o snap-
shot agent também inclui informações sobre o conjunto de dados (metadados), as quais são
utilizadas pelo distributor para transferir dados para um ou mais subscribers. Este agente também
mantém informações sobre o andamento da sincronização entre as diversas réplicas.
Na Figura 8.11, temos uma figura retirada do Books OnLine, onde vemos a utilização do snapshot agent.
Os passos a seguir descrevem o funcionamento deste agente.
1. O snapshot agent é executado no distributor. Em períodos determinados este agente conecta

com o subscriber e bloqueia os dados das tabelas a serem replicadas, de tal forma que estes
dados não podem ser alterados enquanto o agente estiver copiando os dados do publisher para
o subscriber.
Figura 8.11 Snapshot agent em ação.
2. Após transferir os dados para o distributor, o snapshot agent retira o lock das tabelas no sub-
scriber, liberando-as para novas alterações. Devido ao lock que é imposto nas tabelas do sub-
scribers, pode ser necessário que o agente seja configurado para executar fora do horário de
expediente normal.
NOTA
Os dados, que estão no distributor para serem replicados para um ou mais subscribers, são referenciados como “os dados do Banco de Dados
do distributor”, ou o termo mais comum em inglês: “The distributor database”.
♦ Distribution agent: Este agente é responsável por enviar os dados a serem replicados, tanto no
caso de Snapshot replication quanto no caso de Transaction replication, da base do distributor
para um ou mais subscribers. Cada publicação possui o seu próprio distributor agent. Para
Push subscriptions, o distributor agent roda no distributor; para Pull subscriptions, o distribu-
tor agent roda no subscriber.
♦ Log Reader agent: É utilizado em replicações do tipo Transactional replication. O trabalho
deste agente é capturar as alterações no log de transações no publisher, e passar estas transações
para o distributor. Lembrando que apenas Committed transactions é que são replicadas.
Cada Banco de Dados, que utiliza Transactional replication, tem o seu próprio Log Reader
agent no publisher.
♦ Merge agent: É responsável por sincronizar as alterações entre as diversas réplicas; sincroniza
dados nos dois sentidos, entre o publisher e os subscribers, passando evidentemente pelo distribu-
tor. Para Push subscriptions, o Merge agent roda no distributor; para Pull subscriptions, o Merge
agent roda no subscriber. Este agente não é utilizado em Snapshot e Transactional replications.
Agora que já conhecemos a teoria básica sobre replicação no SQL Server 2005, estamos preparados
para começar a implementar a replicação na prática.
KNOW-HOW EM: CONFIGURANDO A

REPLICAÇÃO NO SQL SERVER 2005
PRÉ-REQUISITOS
♦ Conceitos teóricos sobre replicação apresentados nos itens iniciais deste capítulo.
METODOLOGIA
♦ Apresentação dos comandos e assistentes para implementação da replicação.
TÉCNICA
♦ Implementar a replicação no SQL Server 2005.
Vamos configurar a replicação entre as duas instâncias instaladas no nosso servidor. Apenas para lembrar,
o nome do servidor que estou utilizando é SERVIDOR e tenho as seguintes instâncias instaladas no mesmo:
♦ SERVIDOR\SQL2005
♦ SERVIDOR\CURSOSJB
Iremos configurar a instância SERVIDOR\SQL2005 como publisher e distributor. Depois, vamos

configurar a instância SERVIDOR\CURSOSJB como subscriber. Lembrando que, na prática, é como se
cada instância fosse um servidor SQL Server completamente separado.
NOTA
Se você não tiver duas instâncias do servidor SQL Server instaladas, não tem problema, pois é possível configurar uma mesma instância
como sendo publisher, distributor e subscriber. Esta é uma situação pouco usual, sendo somente indicada para sala de aula, treinamentos ou
para um projeto-piloto onde queremos testar a replicação no SQL Server 2005.
Na configuração de um servidor SQL Server para replicação, o primeiro passo é a criação do publisher
e do distributor. Estes dois passos são executados com a utilização dos assistentes de replicação do SQL
Server 2005. Vamos, finalmente, à prática. Uma diferença importante do SQL Server 2005 em relação
ao SQL Server 2000 é que no SQL Server 2005 o mesmo assistente que configura a instância como
publisher também oferece opções para criar um ou mais artigos. Na verdade não tem um assistente
específico só para configurar a instância como publisher. O assistente é para criar uma publicação, já
definindo os artigos que farão parte da publicação (faremos um exemplo, logo a seguir, onde criaremos
uma publicação e adicionaremos três artigos). Ao criar uma publicação, você já configura a instãncia
como um publisher. A seguir um exemplo prático, passo a passo.
Exemplo prático: Configurar a instância SERVIDOR\SQL2005 como publisher e distributor:
Para configurar a instância SERVIDOR\SQL2005 como publisher e distributor, siga os seguintes passos:
1. Abra o SQL Server Management Studio (Iniciar -> Programas -> Microsoft SQL Server 2005 ->
SQL Server Management Studio).
para expandir esta opção.
3. Nas opções que são exibidas, dê um clique no sinal de + ao lado da opção Replication, para
exibir as opções disponíveis. Serão exibidas as opções Publications e Subscriptions at This Server.
4. Para criar uma nova publicação clique com o botão direito do mouse na opção Publications e, no
menu de opções que é exibido, clique em New Publication para iniciar o assistente de publicação.
5. Surgirá a tela inicial do assistente, na qual são informadas as ações que o assistente irá ajudá-lo
a executar.
6. A primeira tela é apenas informativa. Dê um clique no botão Next, seguindo para a próxima
Na segunda etapa devemos selecionar qual servidor\instância atuará como distributor. Podemos utilizar
a instância SERVIDOR\SQL2005 como publisher e também distributor, ou podemos selecionar um
outro servidor\instância para atuar como distributor.
Para que possamos selecionar um outro servidor\instância como distributor, este já deve ter sido
previamente configurado como um distributor e também deve estar registrado no SQL Server Manage-
ment Studio.
Figura 8.12 Definindo um novo distributor.
7. No nosso exemplo, vamos utilizar a instância SERVIDOR\SQL2005 como publisher e também
distributor. Para isso, deixe a primeira opção selecionada, conforme indicado na Figura 8.12.
Ao criarmos um novo distributor, ao invés de utilizar um já existente, o assistente irá efetuar as
configurações necessárias (Distribution database e log), para preparar o servidor selecionado
como distributor.
8. Dê um clique no botão Next, para seguir para a próxima etapa do assistente.
9. Nesta etapa será definida a pasta onde serão armazenadas cópias dos dados (Snapshots) recebidas
do publisher. Por padrão, é sugerida a seguinte localização:
C:\Arquivos de programas\Microsoft SQL Server\MSSQL.1\MSSQL\ReplData
Aqui temos uma questão importante a considerar. Se você usar um caminho do tipo C:\, D:\, etc., não
serão suportadas subscrições do tipo Pull Subscriptions, que são Subscrições onde a iniciativa de
transferência dos dados é feita pelo subscriber (Pull = Puxar, é o subscriber quem “puxa” as alterações
a partir do distributor). Usando uma caminho local, do tipo C:\ , D:\ , etc, somente serão suportadas
Subscrições do tipo Push Subscriptions, que são subscrições onde a iniciativa de transferência dos
dados é feita pelo distributor (Push = Empurrar, ou seja, é o distributor que “empurra” os dados para o
subscriber). Para que sejam aceitas subscrições tanto do tipo Pull Subsciptions quanto Push Subscrip-
tions, deve ser utilizado um caminho de rede, como no exemplo a seguir:
\\servidor\C$\Arquivos de programas\Microsoft SQL Server\MSSQL.1\MSSQL\ReplData
Figura 8.13 Aviso quando utilizamos um compartilhamento administrativo.
Observe que utilizamos o caminho de rede e não um drive do tipo C:\. No exemplo, temos o SQL
Server instalado no drive C:, o qual é acessado através do compartilhamento administrativo C$. Por
padrão, o Windows compartilha a raiz de todos os drives com um nome de compartilhamento Drive$
– C$, D$, E$, etc. Este compartilhamento somente pode ser acessado por usuários com permissão de
administrador. Se mantivermos o caminho padrão, o qual utiliza o compartilhamento administrativo,
pode ser que agentes rodando em outros servidores não possam acessar este compartilhamento e a
replicação venha a falhar. Neste caso, você deve criar manualmente um novo compartilhamento,
atribuir as permissões NTFS necessárias e informar o caminho nesta etapa. Na Figura 8.13 temos a tela
de aviso que surge quando utilizamos um compartilhamento administrativo do tipo C$.
Para maiores informações sobre permissões NTFS e permissões de compartilhamento no Windows 2000, consulte o livro “Manual de Estudos
NOTA
Para o Exame 70-217”, 752 páginas, de minha autoria, publicado pela Axcel Books (www.axcel.com.br). Para maiores informações sobre
segurança no SQL Server 2005 consulte o Capítulo 6 do presente livro. Para maiores informações sobre permissões NTFS e permissões de
compartilhamento no Windows Server 2003, consulte o livro “Windows Server 2003 – Curso Completo”, 1568 páginas, de minha autoria,
publicado pela editora Axcel Books (www.axcel.com.br).
O restante do caminho é a pasta onde o SQL Server 2005 é instalado por padrão: Arquivos de
programas\Microsoft SQL Server\MSSQL.1\MSSQL\ReplData. Observe que temos a pasta MSSQL.1.
Cada instância do SQL Server 2005 é instalada em uma pasta separada.
Não vamos alterar o caminho sugerido.
10. Altere o caminho para usar um caminho de servidor. \\servidor\C$\Arquivos de

programas\Microsoft SQL Server\MSSQL.1\MSSQL\ReplData
11. Dê um clique no botão Next, seguindo para a próxima etapa do assistente.
12. Nesta etapa você deve selecionar o Banco de Dados no qual estão as informações que serão
publicadas. Para o nosso exemplo, vamos selecionar o Banco de Dados AdventureWorks.
Selecione o Banco de Dados AdventureWorks e clique em Avançar, para seguir para a próxima
13. Nesta etapa você deve selecionar o tipo de publicação que será utilizado. Para o nosso exemplo,
vamos selecionar Snapshot Publication, conforme indicado na Figura 8.14.
15. Agora você deve selecionar uma conta de logon que será utilizada pelo agente de replicação. É
fundamental que a conta tenha as devidas permissões na pasta de replicação e de acesso aos dados
que estão sendo replicados. Se a conta selecionada não tiver as permissões necessárias, o processo
de replicação irá falhar. Para selecionar uma conta clique no botão Security Settings. Será exibida a
janela Snapshot Agent Security. Nesta janela você informa a conta e respectiva senha a ser utilizada
pelo Snapshot Agent. Dependendo do modo de autenticação que está configurado para a instância
do SQL Server 2005, você poderá usar somente contas do Windows ou tanto contas do Windows
quanto do SQL Server 2005. Para usar uma conta do SQL Server 2005, você deve marcar a opção
Use the following SQL Server login. No nosso exemplo vamos usar uma conta de logon do Win-
dows, conforme exemplo indicado na Figura 8.15.
Figura 8.14 Selecionando o tipo Snapshot Replication.
Figura 8.15 Informando a conta de logon para o Snapshot Agent.
16. Informe os dados da conta a ser utilizada e clique em OK, para fechar a janela Snapshot
Agent Security.
17. Você estará de volta ao Assistente de publicação. Dê um clique no botão Next, seguindo para a
18. É nesta etapa que você irá definir quais dados serão publicados, ou seja, é nesta etapa que você
irá criar um ou mais artigos, os quais farão parte da publicação e serão replicados. No início
deste capítulo, você viu que um artigo pode ser uma tabela inteira, pode ser uma view, um
stored procedure (o que será publicado é o resultado da execução do stored procedure), pode
ser apenas algumas linhas de uma tabela (filtro horizontal), pode ser apenas algumas colunas
de uma tabela (filtro vertical) e pode ser somente algumas linhas com algumas colunas (filtros
horizontal e vertical). Para o nosso exemplo, iremos criar os artigos indicados a seguir:
♦ Art_Produtos: Este artigo conterá todos os registros da tabela Product.
♦ Art_Employee: Este artigo conterá apenas algumas das colunas da tabela Employee, ou seja,
aplicaremos um filtro Vertical. Este artigo irá replicar somente os seguintes campos da tabela
Employee: EmployeeID, NationalIDNumber, DepartmentID, ManagerID e EmergencyContactID.
♦ Art_Redmond: Este artigo será baseado na tabela Person.Address e irá replicar somente os
registros onde o campo City=’Redmond”. Ou seja, vamos aplicar um filtro horizontal, para
replicar somente as linhas que atendam a um determinado conjunto de critérios, no nosso
exemplo: City=’Redmond”.
Vamos então à tarefa de criar os três artigos propostos. Para isso vamos usar a tela do assistente,
indicada na Figura 8.16:
Figura 8.16 – Tela para criação dos artigos que farão parte da publicação.
19. Vamos iniciar pelo artigo Art_Produtos, o qual é o mais simples de ser criado. Clique no sinal
de + ao lado da opção Tables, para exibir a lista de tabelas do Banco de Dados AdventureWorks.
Clique na caixa de seleção ao lado da tabela Product, para selecioná-la. Ao selecionar uma
tabela, automaticamente, todos os seus campos são selecionados. Isso pode ser comprovado,
clicando no sinal de + ao lado da tabela Product. Observe que todos os seus campos foram
selecionados. Clique no sinal de – ao lado da tabela Product, para ocultar a lista de campos.
Pronto, está criado o artigo Art_Produtos. Como não temos nenhum filtro – nem horizontal
e nem vertical – a ser aplicado, está OK o artigo Art_Produtos, o qual irá publicar a tabela
Product completa, ou seja, todos os seus campos e todos os seus registros. Vamos para a
criação do próximo artigo.
20. Vamos iniciar pelo artigo Art_Employee. Este artigo irá publicar apenas algumas das colunas da
tabela Employee, ou seja, vamos aplicar um filtro vertical. Você deve estar com a opção Tables
expandida, com a lista de tabelas sendo exibida. Se não estiver sendo exibida a lista de tabelas,
clique no sinal de + ao lado da opção Tables. Clique na caixa de seleção ao lado da tabela
Employee, para selecioná-la. Ao selecionar uma tabela, automaticamente, todos os seus cam-
pos são selecionados. Isso pode ser comprovado, clicando no sinal de + ao lado da tabela
Employee. Observe que todos os seus campos foram selecionados. Para o nosso exemplo,
somente os seguintes campos devem ficar marcados: EmployeeID, NationalIDNumber,
DepartmentID, ManagerID e EmergencyContactID. Certifique-se de que somente estes cam-
pos da tabela Employee estejam marcados e desmarque os demais campos. Sua janela deve
estar semelhante à indicada na Figura 8.17:
Figura 8.17 Aplicando um filtro vertical à tabela Employee.
21. Agora vamos criar o nosso último artigo: Art_Redmond: Este artigo será baseado na tabela
Person.Address e irá replicar somente os registros onde o campo City=’Redmond’. Ou seja,
vamos aplicar um filtro horizontal, para replicar somente as linhas que atendam a um
determinado conjunto de critérios, no nosso exemplo: City=’Redmond”. Clique na caixa de
seleção ao lado da tabela Address, para selecioná-la. Ao selecionar uma tabela, automaticamente,
todos os seus campos são selecionados. Isso pode ser comprovado, clicando no sinal de + ao
lado da tabela Address. Observe que todos os seus campos foram selecionados. Clique no sinal
de – ao lado da tabela Address, para ocultar a lista de campos. Nesta etapa não temos mais o
que fazer. O critério City=’Redmond’ será aplicado em uma das próximas etapas do assistente.
23. Eu fui, propositalmente, para a próxima etapa, para que surgisse a mensagem indicada na
Figura 8.18:
Figura 8.18 Mensagem informando sobre a replicação dos schemas.
Esta mensagem informa que um ou mais dos objetos que estão sendo publicados têm como donos
schemas que não o schema padrão dbo. A messagem continua informando que estes schemas já deverão
existir nos subscribers, caso contrário a replicação não irá funcionar. No nosso exemplo prático criamos
três artigos. O artigo Art_Produtos publica dados da tabela Production.Product, ou seja, da tabela Prod-
uct, cujo dono é o schema Production. Para garantir que a replicação irá funcionar, sem problemas, o
schema deverá existir em qualquer subscriber que seja configurado para receber a replicação ou você
deve alterar o dono, durante a replicação, para ser o schema dbo, o qual já existe, automaticamente,
em toda instância do SQL Server 2005 (veremos como fazer isso logo em seguida). O artigo Art_Employee,
o qual publica dados da tabela Humanresources.Employee, ou seja, da tabela Employee, cujo dono é o
schema HumanResources. Para garantir que a replicação irá funcionar, sem problemas, este Schema
deverá existir em qualquer subscriber que seja configurado para receber a replicação ou você deve
alterar o dono, durante a replicação, para ser o Schema dbo, o qual já existe, automaticamente, em
toda instância do SQL Server 2005 (veremos como fazer isso logo em seguida). E, finalmente, o artigo
Art_Redmond, o qual publica dados da tabela Person.Address, ou seja, da tabela Address, cujo dono é
o schema Person. As mesmas considerações anteriores são válidas em relação ao schema Person.
Muito bem, agora vou mostrar como configurar o schema dbo para ser o dono, no destino, de todos os
objetos replicados. Ou seja, no destino, o dono será o schema dbo, o qual já existe, automaticamente,
em toda instância do SQL Server 2005.
24. Dê um clique no botão Back, para voltar para a etapa anterior do assistente. É isso mesmo,
vamos voltar à etapa anterior do assistente.
Figura 8.19 Definindo o schema dbo como dono no destino – nos subscribers.
25. Clique na opção Tables para selecioná-la. Clique no botão Article Properties. Dentre as opções
que são exibidas clique em Set Properties of all Tables Articles. Ou seja, vamos fazer alterações
que se aplicam a todos os artigos de tabelas, que fazem parte da publicação. Será aberta a janela
Properties for all Tables Articles. Clique no campo Destination Object Owner, apague o valor
atual e digite o novo valor: dbo, conforme indicado na Figura 8.19. Ou seja, estamos definindo
o schema dbo como sendo o dono de todos os objetos replicados, no destino, ou seja, nos
subscribers. Como o schema dbo existe, automaticamente, em toda instância do SQL Server
2005, com isso garantimos que a replicação irá funcionar, sem problemas, independentemente
de os schemas que são os donos no publisher existirem ou não nos subscribers.
26. Clique em OK para fechar a janela de propriedades dos artigos. Você estará de volta ao assistente
de publicação.
27. Dê um clique no botão Next, seguindo para a próxima etapa do assistente. Observe que agora o
aviso da Figura 8.18 não é mais exibido e o assistente já vai diretamente para a etapa onde você
pode definir filtros horizontais (critérios de filtragem), para os artigos que estão sendo publicados.
28. Agora temos que criar um filtro para o artigo Art_Redmond, no qual colocaremos o seguinte
critério: City=’Redmond’. Dê um clique no botão Add. Será aberta a janela Add Filter. Na lista
Select the table to filter, selecione a tabela Address (Person). Observe que no campo Filter state-
ment aparece o comando T-SQL adaptado para a publicação: SELECT <published_columns> FROM
[Person].[Address] WHERE. Observe a cláusula WHER já incluída, pronta para receber um ou
mais critérios. Na lista Columns clique no campo City, para marcá-lo. Clique no botão >, para
incluir o campo City no comando T-SQL. Neste momento, o comando T-SQL deve estar assim:
SELECT <published_columns> FROM [Person].[Address] WHERE [City]. Agora só falta definirmos
o valor do critério para o campo City. Isso é feito digitando diretamente no comando T-SQL. O
comando completo deve ficar assim: SELECT <published_columns> FROM [Person].[Address]
WHERE [City] = ‘Redmond’. A sua janela deve estar conforme indicado na Figura 8.20.
Figura 8.20 Definindo um filtro horizontal para um dos artigos.
29. Clique em OK para fechar a janela Add Filter. Você estará de volta ao assistente de publicação.
Observe que a tabela Address já aparece na lista Filtered Tables, conforme indicado na Figura 8.21:
Figura 8.21 Lista de tabelas com filtros definidos.
31. Nesta etapa você define se deve ser criado um snapshot imediatamente (uma cópia integral
dos dados que serão replicados). Feita a publicação dos dados, estes estarão disponíveis para
um ou mais subscribers. Quando um servidor se inscreve para receber os dados, ele recebe,
inicialmente, um snapshot, ou seja, uma cópia completa dos dados. Depois, o subscriber passa
a receber somente as alterações efetuadas no publisher. Lembrando que a replicação Snapshot
é unidirecional, ou seja, não poderão ser feitas alterações nos dados, nos subscribers, somente
no publisher. Você também pode criar um agendamento para fazer com que um snapshot seja
recriado, de acordo com um agendamento determinado, como por exemplo todos os dias, às
2:00 da madrugada. Para criar um agendamento, marque a opção Schedule the Snapshot Agent
to run at the following times e clique no botão Change, para definir um ou mais agendamentos.
No nosso exemplo não vamos definir agendamentos. Certifique-se de que somente a opção
Create a snapshot immediately esteja marcada e clique em Next, seguindo para a próxima
32. Nesta etapa você pode marcar a opção Create the publication immediately, para que a publicação
seja criada imediatamente e também pode marcar a opção Generate a script, caso você queira
que seja criado um arquivo, contendo todos os comandos, necessários para gerar a publicação,
de acordo com as opções que você selecionou no assistente. Este script pode ser útil, por exemplo,
para rapidamente recriar a publicação, em caso de problemas. Você pode gravar estes comandos
em um arquivo e, quando for necessário recriar a publicação, é só copiar estes comandos e
executá-los na janela de execução de comandos T-SQL. Marque as duas opções desta etapa,
conforme indicado na Figura 8.22:
Figura 8.22 Criar a publicação e gerar um arquivo com os comandos T-SQL.
34. Nesta etapa (que só é exibida se você marcar a opção para gerar o script, na etapa anterior),
você definie onde será gravado o script, o nome do arquivo e as propriedades do arquivo.
Selecione as opções indicadas na Figura 8.23.
36. Será exibida a tela final do assistente, onde é apresentado um resumo de todas as opções
selecionadas. Caso você tenha que alterar alguma opção, é só utilizar o botão Back. Nesta etapa
você deve digitar um nome para publicação. Digite Minha Publicação, no campo Publication
Name e clique em Finish para encerrar o assistente e criar a publicação.
Figura 8.23 Configurações do arquivo com os comandos.
37. O SQL Server 2005 começará a criar a publicação e exibirá uma janela, indicando o progresso
do trabalho, conforme exemplo da Figura 8.24:
Figura 8.24 Progresso da criação da publicação.
38. Concluídas as diversas etapas de criação da publicação, clique em Close para fechar a janela
New Publication Wizard. Muito bem, a publicação foi criada, com os três artigos que criamos
neste exemplo. A seguir veremos como conferir se a publicação foi realmente criada e como
podemos fazer configurações em uma publicação já existente. Antes, apenas a título de
curiosidade, coloco a seguir o script gerado pelo assistente (lembre que, em uma das etapas
finais, marcamos a opção para gerar um arquivo com todos os comandos T-SQL, necessários
para criação da publicação):
*********************************************************************************************************
- Enabling the replication database
use master
exec sp_replicationdboption @dbname = N’AdventureWorks’, @optname = N’publish’, @value =
N’true’
GO
— Adding the snapshot publication
use [AdventureWorks]
exec sp_addpublication @publication = N’Minha Publicação’, @description = N’Snapshot
publication of database ‘’AdventureWorks’’ from Publisher ‘’SERVIDOR\SQL2005'’.’,
@sync_method = N’native’, @retention = 0, @allow_push = N’true’, @allow_pull = N’true’,
@allow_anonymous = N’true’, @enabled_for_internet = N’false’, @snapshot_in_defaultfolder =
N’true’, @compress_snapshot = N’false’, @ftp_port = 21, @ftp_login = N’anonymous’,
@allow_subscription_copy = N’false’, @add_to_active_directory = N’false’, @repl_freq =
N’snapshot’, @status = N’active’, @independent_agent = N’true’, @immediate_sync = N’true’,
@allow_sync_tran = N’false’, @autogen_sync_procs = N’false’, @allow_queued_tran =
N’false’, @allow_dts = N’false’, @replicate_ddl = 1
exec sp_addpublication_snapshot @publication = N’Minha Publicação’, @frequency_type = 1,
@frequency_interval = 0, @frequency_relative_interval = 0, @frequency_recurrence_factor =
0, @frequency_subday = 0, @frequency_subday_interval = 0, @active_start_time_of_day = 0,
@active_end_time_of_day = 235959, @active_start_date = 0, @active_end_date = 0, @job_login
= N’SERVIDOR\Administrador’, @job_password = null, @publisher_security_mode = 1
GO
exec sp_addarticle @publication = N’Minha Publicação’, @article = N’Address’,
@source_owner = N’Person’, @source_object = N’Address’, @type = N’logbased’, @description
= null, @creation_script = null, @pre_creation_cmd = N’drop’, @schema_option =
0x00000000000044F1, @identityrangemanagementoption = N’manual’, @destination_table =
N’Address’, @destination_owner = N’dbo’, @status = 0, @vertical_partition = N’false’,
@filter_clause = N’[City] = ‘’Redmond’’’
— Adding the article filter

exec sp_articlefilter @publication = N’Minha Publicação’, @article = N’Address’,
@filter_name = N’FLTR_Address_1__58', @filter_clause = N’[City] = ‘’Redmond’’’,
@force_invalidate_snapshot = 1, @force_reinit_subscription = 1
— Adding the article synchronization object
exec sp_articleview @publication = N’Minha Publicação’, @article = N’Address’, @view_name
= N’SYNC_Address_1__58', @filter_clause = N’[City] = ‘’Redmond’’’,
@force_invalidate_snapshot = 1, @force_reinit_subscription = 1
GO
exec sp_addarticle @publication = N’Minha Publicação’, @article = N’Employee’,
@source_owner = N’HumanResources’, @source_object = N’Employee’, @type = N’logbased’,
@description = null, @creation_script = null, @pre_creation_cmd = N’drop’, @schema_option
= 0x00000000000044F1, @identityrangemanagementoption = N’manual’, @destination_table =
N’Employee’, @destination_owner = N’dbo’, @status = 0, @vertical_partition = N’true’
— Adding the article’s partition column(s)
exec sp_articlecolumn @publication = N’Minha Publicação’, @article = N’Employee’, @column
= N’EmployeeID’, @operation = N’add’, @force_invalidate_snapshot = 1,
@force_reinit_subscription = 1
= N’NationalIDNumber’, @operation = N’add’, @force_invalidate_snapshot = 1,
= N’DepartmentID’, @operation = N’add’, @force_invalidate_snapshot = 1,
= N’ManagerID’, @operation = N’add’, @force_invalidate_snapshot = 1,
= N’EmergencyContactID’, @operation = N’add’, @force_invalidate_snapshot = 1,
— Adding the article synchronization object
exec sp_articleview @publication = N’Minha Publicação’, @article = N’Employee’, @view_name
= N’SYNC_Employee_1__58', @filter_clause = null, @force_invalidate_snapshot = 1,
GO
exec sp_addarticle @publication = N’Minha Publicação’, @article = N’Product’,
@source_owner = N’Production’, @source_object = N’Product’, @type = N’logbased’,
@description = null, @creation_script = null, @pre_creation_cmd = N’drop’, @schema_option
= 0x00000000000044F1, @identityrangemanagementoption = N’manual’, @destination_table =
N’Product’, @destination_owner = N’dbo’, @status = 0, @vertical_partition = N’false’
GO
********************************************************************************************************
Sem dúvidas, podemos dizer que temos aqui comandos T-SQL bem avançados. Ainda bem que temos
os assistentes para nos ajudar. É bem mais fácil usar o assistente do que aprender todos estes comandos
e as respectivas sintaxes.
KNOW-HOW EM: CONFIGURAÇÃO E ADMINISTRAÇÃO DE PUBLICAÇÕES

Após ter criado uma publicação, você poderá alterá-la, conforme for necessário. Após ter criado uma
publicação, ela passa a ser exibida na opção Replication -> Publications, dentro da instância onde a
publicação foi criada. No exemplo da Figura 8.25, temos a publicação Minha Publicação, do Banco de
Dados AdventureWorks, da instância SERVIDOR\SQL2005, já sendo exibida na lista de publicações.
Para acessar as propriedades de uma publicação, clique com o botão direito do mouse na publicação e,
no menu de opções que é exibido, clique em Properties. Será aberta a janela de propriedades da
publicação, com a guia General automaticamente selecionada. Na guia General, você pode alterar a
descrição da publicação, mas não pode alterar o nome da publicação. Nesta guia, você também pode
definir se as subscrições irão expirar ou não. O padrão é que as subscrições não expirem. Na guia
General você pode marcar a opção “Subscriptions expire and may be dropped if not synchronized in
the following number of hours:”, para definir por quantas horas os dados estarão disponíveis para
serem replicados para os subscribers. Se não houver uma replicação no tempo definido no campo
Hours, os dados não serão mais replicados e serão excluídos. Somente quando um novo conjunto de
dados for gerado, será feita uma nova replicação.
Dê um clique na guia Articles. As opções desta guia são idênticas às opções da etapa do assistente, onde
você definiu quais artigos fariam parte da publicação. Você pode usar a guia Articles para alterar os
arquivos existentes, excluir artigos e incluir novos artigos na publicação. Você também pode usar o
botão Article Properties, para definir as propriedades para um artigo em particular ou para todos os
artigos, ao mesmo tempo.
Figura 8.25 A publicação Minha Publicação, criada no exemplo anterior.
Dê um clique na guia Filter Rows. Nesta guia você define os filtros horizontais, definindo critérios de
filtragem para um ou mais dos artigos. Apenas para lembrar, no exemplo anterior, nós definimos um
filtro para o artigo Art_Redmond. Definimos o seguinte filtro: City=’Redmond’. Nesta guia você pode
alterar os filtros existentes, adicionar novos filtros ou excluir filtros.
Dê um clique na guia Snapshot. Nesta guia você define várias opções, que afetam a maneira como o
snapshot dos dados será efetuado. Inicialmente, você pode definir o formato dos dados. A opção
Native SQL Server deve ser utilizada se os subscribers forem também instâncias do SQL Server. Já a
opção Character deve ser utilizada se o publisher ou um ou mais dos subscribers não são uma instância
do SQL Server. Nesta guia você também pode definir se os arquivos, contendo os dados a serem
replicados, serão colocados no caminho padrão sugerido pelo SQL Server 2005, ou em uma pasta que
você selecionar. Por fim, você também pode configurar scripts que serão executados antes e/ou depois
da criação do snapshot. Por exemplo, se você está replicando dados no formato Character, para serem
importados por um outro Banco de Dados que não o SQL Server, você pode rodar um script após a
criação do snapshot, para adaptar os dados para o formato esperado pelos subscribers.
Dê um clique na guia FTP Snapshot. Nesta guia você define se o protocolo FTP deverá ou não ser
utilizado pelos subscribers, para fazer download dos arquivos de dados a serem replicados. Por padrão,
está desabilitada a opção de usar FTP. Eu recomendo que você mantenha esta opção desabilitada e
deixe os agentes de replicação do SQL Server se encarregarem da transferência dos dados a serem
replicados. É bem mais seguro do que o uso do FTP, o qual é um protocolo bastante frágil, em termos
de segurança.
Dê um clique na guia Subscriptions Options. Nesta guia você pode configurar uma série de opções que
irão definir como serão aceitas as subscrições para esta publicação. Por exemplo, você usa a opção
Allow pull subscriptions, para definir se serão ou não aceitas subscrições do tipo Pull, nas quais é o
subscriber que inicia o processo de solicitar a cópia dos dados que estão no distributor, ou seja, na
subscrição do tipo Pull é o subscriber que puxa os dados (Pull = puxar).
Dê um clique na guia Subscriptions Options. Nesta guia você pode configurar uns grupos, com permissão
para fazerem Subscrições nesta publicação. Você pode usar o botão Add para adicionar novos usuários
e/ou grupos; o botão Remove para remover um usuário e/ou grupo e o botão Remove All, para remover
todos os usuários/grupos da lista. Se um usuário não estiver nesta lista, ele não conseguirá se inscrever
para receber os dados desta publicação. Esta lista é uma maneira de limitar quais usuários poderão
receber réplicas dos dados.
Dê um clique na guia Agent Security. Nesta guia você define a conta e respectiva senha, com a qual será
executado o Agente de Replicação. Para alterar a conta e/ou senha, clique no botão Security Settings.
Definidas as configurações desejadas para a publicação é só clicar em OK e pronto, as modificações

serão aplicadas.
KNOW-HOW EM: HABILITAÇÃO DE SUBSCRIBERS

PRÉ-REQUISITOS
♦ Ter criado uma publicação no item anterior.
METODOLOGIA
♦ Apresentação dos comandos e assistentes para configuração de um subscriber.
TÉCNICA
♦ Configurar um subscriber utilizando o SQL Server Management Studio.
Criamos uma publicação no item anterior. O objetivo da criação de uma publicação é para que esta
possa ser replicada para um ou mais subscribers. Aprenderemos neste item como habilitar subscribers
e configurar subscrições.
Conforme já descrito anteriormente, podemos configurar dois tipos de subscrições:
♦ Pull subscriptions
♦ Push subscriptions
Iremos usar o assistente de subscrição, para configurar uma subscrição do tipo Push subscription (push
= empurrar, ou seja, é o distributor quem “empurra” os dados para um ou mais subscribers). Este tipo
de subscrição é configurado no publisher, conforme descrito anteriormente. É indicado para situações
nas quais devemos fazer um gerenciamento centralizado das subscrições. Porém não devemos esquecer
que, neste tipo de subscrição, os agentes responsáveis pela replicação rodam no distributor, consumindo
memória e processamento deste servidor. Estas necessidades adicionais de memória e processamento
devem ser levadas em consideração.
Vamos configurar uma subscrição do tipo Push subscription. Conforme descrito na parte teórica, no
início deste capítulo, este tipo de Subscrição tem as seguintes características:
♦ Com este tipo de subscrição, o distributor é responsável por enviar as alterações para um ou
mais subscribers. Lembre que push significa “empurrar” e não puxar. Uma analogia que pode
ser utilizada é que neste tipo de subscrição é o distributor que “empurra”, envia as alterações
para um ou mais subscribers.
♦ Utilizamos Push subscriptions quando queremos ter um controle centralizado sobre o agendamento
das replicações. É muito mais fácil configurar várias subscrições em um único servidor, no caso o
distributor, do que ter que configurar a subscrição em diversos servidores, no caso, os diversos
subscribers. É do distributor a iniciativa de enviar as alterações para os subscribers.
♦ Assim como o Agente de replicação, serviço responsável por fazer a replicação, roda no dis-
tributor ou no publisher, dependendo de como foi feita a configuração da replicação, devemos
ter em mente que este agente estará consumindo recursos como memória e processador no
distributor ou no publisher. Caso tenhamos um número considerável de subscribers, devemos
planejar cuidadosamente esta necessidade de recursos de memória e processamento.
Antes de configurarmos a subscrição para a publicação Minha Publicação, vamos excluir o Banco de
Dados AdventureWorks, da instância SERVIDOR2\CURSOSJB. Vamos fazer isso para verificar se realmente
só estão sendo replicados os dados definidos pelos três artigos da publicação Minha Publicação.
Para excluir o Banco de Dados AdventureWorks da instância SERVIDOR2\CURSOSJB: abra o SQL Server
Management Studio; navegue até o Banco de Dados AdventureWorks da instância
SERVIDOR2\CURSOSJB; clique com o botão direito do mouse em AdventureWorks e, no menu de
opções que é exibido; dê um clique em Delete. Surge uma mensagem pedindo confirmação dê um
clique no botão OK para confirmar a exclusão.
Exemplo prático: Configurar a instância SERVIDOR2\CURSOSJB como subscriber da publicação Minha

Publicação, criada no item anterior. Criar uma subscrição do tipo Push subscription, ou seja, configurada
a partir do publisher, que no nosso caso é a instância SERVIDOR\SQL2005.
Para criar a subscrição solicitada, siga os passos indicados a seguir:
3. Clique no sinal + ao lado da opção Replication, abaixo da instância SERVIDOR\SQL2005, para
4. Clique no sinal de + ao lado da opção Publications, para exibir as publicações disponíveis nesta
instância. No momento, deve estar disponível somente a publicação Minha Publicação, criada
anteriormente.
5. Clique com o botão direito do mouse na publicação Minha publicação e, no menu de opções
que é exibido, clique em New Subscriptions.
6. Será aberto o assistente para criação de novas subscrições – New Subscription Wizard. A
primeira tela do assistente é somente informativa. Clique em Next, para seguir para a
7. Nesta etapa você deve selecionar a publicação para a qual será criada uma nova subscrição. Na
lista publisher, já deve ter vindo selecionada a instância SERVIDOR\SQL2005. Se não veio
selecionada esta instância, selecione-a. Na parte de baixo da janela serão exibidas as publicações
disponíveis (no nosso exemplo somente será exibida a publicação Minha Publicação). Clique
na publicação Minha Publicação, para selecioná-la, conforme indicado na Figura 8.26:
Figura 8.26 A publicação Minha Publicação, criada no exemplo anterior.
8. Clique em Next, para seguir para a próxima etapa do assistente.
9. Nesta etapa você irá definir se o assistente irá criar uma ou mais subscrições do tipo Push
subscriptions (onde os agentes de replicação rodam no distributor), ou se serão subscrições do
tipo Pull subscriptions (onde os agentes de replicação rodam nos subscribers). Usando o assistente
você pode criar várias subscrições, de uma só vez, mas todas do mesmo tipo, ou seja, ou todas
Pull subscriptions ou todas Push subscriptions. Se você precisar criar subscrições de diferentes
tipos, terá que rodar o assistente mais de uma vez. Certifique-se de que a opção (push subscrip-
tions) esteja selecionada, conforme indicado na Figura 8.27:
Figura 8.27 Definindo o tipo de subscrição.

11. Nesta etapa você pode adicionar uma ou mais instâncias do SQL Server 2005, as quais serão
subscribers da publicação Minha Publicação. Por padrão, somente a própria instância, onde foi
criada a publicação, é exibida na lista. No nosso exemplo, por padrão somente a instância
SERVIDOR\SQL2005, que é onde foi criada a publicação Minha Publicação, está sendo exibida.
Vamos adicionar a instância SERVIDOR2\CURSOSJB. Para isso, clique no botão Add SQL Server.
Será exibida a janela Connect to server. Na lista Server name, selecione o nome da instância
que será o subscriber; no nosso exemplo, selecione SERVIDOR2\CURSOSJB. É importante
salientar que, nesta lista, somente serão exibidos os nomes das instâncias registradas no SQL
Server Management Studio. Caso a instância desejada não esteja sendo exibida nesta lista,
você pode cancelar o assistente e, no SQL Server Management Studio, clicar com o botão
direito do mouse em Microsoft SQL Servers (na janela Registered Servers) e usar o comando
New -> Server Registration, para registrar uma ou mais instâncias do SQL Server. Depois é só
voltar e executar o assistente novamente. Na lista Authentication selecione Windows Authen-
tication. Sua janela deve estar conforme indicado na Figura 8.28:
Figura 8.28 Adicionando um novo subscriber.
12 . Dê um clique no botão Connect.
13 . Você estará de volta ao assistente e a instância SERVIDOR2\CURSOSJB já terá sido adicionada

à lista. Certifique-se de que somente esta instância esteja selecionada. Na coluna Subscription
database, você deve informar se os dados serão replicados para um Banco de Dados já existente
ou para um novo Banco de Dados. Para o nosso exemplo, selecione a opção New database,
conforme indicado na Figura 8.29. É nesta etapa que você pode adicionar quantos subscribers
forem necessários. Para adicioná-los, basta que eles já tenham sido registrados no SQL Server
Management Studio, conforme descrito anteriormente.
Figura 8.29 Selecionando o subscriber e o Banco de Dados de destino.
14. Será aberta a janela para criação de um novo Banco de Dados, janela esta que você aprendeu a
utilizar no Capítulo 3. Utilizando os conhecimentos do Capítulo 3, crie um Banco de Dados
com as seguintes características (é importante salientar que, antes de criar este Banco de Dados,
a pasta C:\livrosql\ExReplicacao já deve ter sido criada, caso contrário será gerado um erro. Se
esta pasta ainda não existe, abra o Windows Explorer e crie a pasta C:\livrosql\ExReplicacao):
Tabela 8.3 O Banco de Dados ExReplicacao.
Primário C:\livrosql\ExReplicacao\ExReplicacao-prim.mdf
Secundário C:\livrosql\ExReplicacao\ExReplicacao-sec1.ndf
Secundário C:\livrosql\ExReplicacao\ExReplicacao-sec2.ndf
Arquivo de log C:\livrosql\ExReplicacao\ExReplicacao-log1.ldf
NOTA
A criação de um novo Banco de Dados para receber os dados replicados não é, de maneira alguma, necessária. Poderíamos utilizar um Banco
de Dados já existente. Optamos por criar um novo Banco de Dados para salientar a execução deste procedimento.
15. A tela de criação do novo Banco de Dados deverá estar conforme indicado na Figura 8.30:
Figura 8.30 Definições para criação do Banco de Dados ExReplicacao.
16. Clique em OK para criar o Banco de Dados ExReplicacao. Você estará de volta ao assistente de subscrição.
Figura 8.31 Configurações de segurança, para o agente de distribuição.
18. Nesta etapa você irá definir as configurações de segurança (conta de conexão e opções de conexão),
para cada agente de distribuição que for utilizado. No nosso exemplo, tem um único agente de
Distribuição, pois configuramos um único subscriber. Se você tivesse configurado vários sub-
scribers, seriam listados tantos agentes de distribuição quantos fossem os subscribers configurados.
Clique no botão OK, para fazer as configurações de segurança. Será aberta a janela Distribution
Agent Security. Informe a conta a ser utilizada e a respectiva senha, conforme indicado na Figura
8.31. Não altere as demais opções. Clique em OK. Você estará de volta ao assistente.
20. Nesta etapa você deve definir um agendamento para cada um dos subscribers que estão sendo
configurados. Por exemplo, você poderia definir uma replicação de duas em duas horas para
subscribers remotos, porém ligados por links de alta velocidade, uma replicação de 15 em 15
minutos para subscribers da mesma rede local e uma replicação uma vez por dia, de madrugada,
para subscribers remotos, ligados por links de WAN de baixa velocidade. No nosso exemplo,
temos um único subscriber. Vamos configurar uma replicação diariamente, de duas em duas
horas. Clique na coluna Agent Schedule, abra a lista e seleicone a opção Define Schedule.
21. Será aberta a janela para definição do agendamento, janela esta que você já aprendeu a utilizar no
capítulo sobre Jobs e Agendamento de tarefas. Para definir uma replicação diária, de duas em duas
horas, configure as opções indicadas na Figura 8.32 e clique em OK para criar o agendamento.
Figura 8.32 Definindo o agendamento da replicação.
22. Você estará de volta ao assistente para criação de novas subscrições. Clique em Next, para
23. Nesta etapa o assistente informa que cada subscrição tem que ser inicializada com uma replicação
completa, do tipo snapshot dos dados e do schema. Nesta etapa você informa, para cada
subscrição (no nosso exemplo é uma única subscrição), quando que este snapshot inicial deve
ser criado. Você tem a opção de criá-lo imediatamente – opção Immediately na coluna “Initial-
ize When” – ou no próximo agendamento – opção At firs synchronization. Por padrão, vem
selecionada a opção Immediately. Vamos manter esta opção selecionada.
25. Nesta etapa você pode marcar a opção Create the subscription(s) immediately, para que a
subscrição seja criada imediatamente e também pode marcar a opção Generate a script, caso
você queira que seja criado um arquivo, contendo todos os comandos, necessários para criar a
subscrição, de acordo com as opções que você selecionou no assistente. Este script pode ser
útil, por exemplo, para rapidamente recriar a subscrição, em caso de problemas. Você pode
gravar estes comandos em um arquivo de texto e, quando for necessário recriar a publicação, é
só copiar estes comandos do arquivo de texto e executá-los na janela de execução de comandos
T-SQL. Marque as duas opções desta etapa, conforme indicado na Figura 8.33:
Figura 8.33 Criar a subscrição e gerar um arquivo com os comandos T-SQL.
Selecione as opções indicadas na Figura 8.34:
29. Será exibida a tela final do assistente, onde é apresentado um resumo de todas as opções selecionadas.
Caso você tenha que alterar alguma opção, é só utilizar o botão Back. Clique em Finish para encerrar
o assistente e criar a subscrição (ou subscrições, caso você tenha configurado mais de uma subscrição).
30. O SQL Server 2005 começará a criar a subscrição e exibirá uma janela, indicando o progresso
do trabalho, conforme exemplo da Figura 8.35.
31. Concluídas as diversas etapas de criação da subscrição, clique em Close para fechar a janela
New Subscription Wizard. Muito bem, a subscrição foi criada. A partir deste momento, a instância
SERVIDOR2\CURSOSJB passará a receber os dados da publicação Minha Publicação, da instância
SERVIDOR\SQL2005. Esta replicação será feita de duas em duas horas e os dados serão gravados
no Banco de Dados ExReplicacao. A seguir veremos como conferir se a subscrição foi realmente
criada e vamos verificar se os dados estão sendo copiados para o Banco de Dados ExReplicacao,
da instância SERVIDOR\SQL2005. Também veremos como forçar uma replicação.
Figura 8.35 Progresso da criação da subscrição.
Antes, apenas a título de curiosidade, coloco a seguir o script gerado pelo assistente (lembre que, em
uma das etapas finais, marcamos a opção para gerar um arquivo com todos os comandos T-SQL,
necessários para criação da subscrição):
*********************************************************************************************************
————————BEGIN: Script to be run at Publisher ‘SERVIDOR\SQL2005’————————-
exec sp_addsubscription @publication = N’Minha Publicação’, @subscriber =
N’SERVIDOR2\CURSOSJB’, @destination_db = N’ExReplicacao’, @subscription_type = N’Push’,
@sync_type = N’automatic’, @article = N’all’, @update_mode = N’read only’
exec sys.sp_addpushsubscription_agent @publication = N’Minha Publicação’, @subscriber =
N’SERVIDOR2\CURSOSJB’, @subscriber_db = N’ExReplicacao’, @job_login =
N’SERVIDOR\Administrador’, @job_password = N’’, @subscriber_security_mode = 1, @frequency_type
= 4, @frequency_interval = 1, @frequency_relative_interval = 0, @frequency_recurrence_factor =
1, @frequency_subday = 8, @frequency_subday_interval = 2, @active_start_time_of_day = 0,
@active_end_time_of_day = 235900, @active_start_date = 20050509, @active_end_date = 99991231,
@enabled_for_syncmgr = N’False’, @dts_package_location = N’Distributor’
GO
————————END: Script to be run at Publisher ‘SERVIDOR\SQL2005’————————-
*********************************************************************************************************
Agora vamos verificar quais modificações foram introduzidas na instância SERVIDOR\SQL2005 após
termos configurado a replicação. Veremos quais agentes foram implementados, o histórico de replicação
dos agentes. Depois verificaremos se os dados foram realmente replicados.
OS AGENTES CRIADOS PARA A REPLICAÇÃO EM SERVIDOR\SQL2005

Vamos conferir quais os jobs que foram criados na instância SERVIDOR\SQL2005, para dar suporte à
replicação do tipo Snapshot que configuramos nos exercícios anteriores. Para isso utilizaremos a opção
SQL Server Agent -> Jobs, da instância SERVIDOR\SQL2005. Também iremos verificar o histórico de
execução destes agentes, para sabermos se a replicação já está sendo efetuada com sucesso.
Exemplo prático: Para verificar quais jobs foram criados e verificar o histórico de execução dos jobs
relacionados com a replicação, siga os passos indicados a seguir:
para expandir esta opção.
3. Dê um clique no sinal de + ao lado da opção SQL Server agent, para expandir esta opção.
4. Dê um clique no sinal de + ao lado da opção Jobs, abaixo de SQL Server Agent, para exibir a
lista de jobs disponíveis.
5. Observe que temos uma série de jobs relacioandos com a replicação, conforme pode ser indicado
pelo nome dos Jobs. Observe que vários jobs têm, em alguma parte do nome, termos relacionados
à replicação, tais como Subscription, Replication, Distribution e assim por diante.
6. Na Figura 8.36 você pode conferir a lista de jobs da instância SERVIDOR\SQL2005:
Figura 8.36 Lista de jobs criados para dar suporte à replicação.
Agora vamos verificar o histórico de execução de um dos jobs – Replication agents checkup.
7. Dê um clique com o botão direito do mouse no job Replication agents checkup. No menu que
surge, dê um clique na opção View History.
É exibida a janela com informações detalhadas, sobre todo o histórico de execuções do job, conforme
indicado na Figura 8.37. No nosso exemplo, observe que o job já foi executado diversas vezes. Para
cada execução são informadas a data e a hora de início da execução do job (lembrando que um mesmo
Job pode conter mais de um comando, para execução).
Figura 8.37 A janela com o histórico de execução do job.
Para ver mais detalhes sobre uma execução do job, dê um clique no sinal de +, ao lado da data e hora
de execução do job.
Você pode filtrar o histórico de execução, para exibir apenas as ocorrências que atendam a determinados
critérios, tais como uma data inicial e uma data final. Para isso, clique no botão Filter. Será aberta a
janela Filter Settings. Defina os critérios de filtragem desejados, como no exemplo da Figura 8.38, onde
estou definindo que sejam exibidas apenas as execuções para o período de 09/05/2005 a 10/05/2005.
Marque a opção Apply Filter e clique em OK. Pronto, o histórico de execução será filtrado, para exibir
somente as execuções que atendam os critérios especificados.
8. Dê um clique no botão Close para fechar a janela do histórico de execução do job.
9. Você estará de volta ao SQL Server Management Studio. Mantenha-o aberto.
Figura 8.38 Opções para filtrar o histórico de execução do job.
Lembre que o nosso agente está programado, ou melhor, agendado para executar de duas em duas
horas. Ao executar, o agente transmite toda a publicação Minha publicação do publisher (que no
nosso exemplo é a instância SERVIDOR\SQL2005) para o distributor (que no nosso exemplo também
é a instância SERVIDOR\SQL2005). Devemos observar que é transmitida toda a publicação e não
somente os dados que foram alterados, pois estamos utilizando uma replicação do tipo Snapshot rep-
lication. Ou seja, a cada replicação, o conjunto completo de dados é replicado e não somente o que foi
alterado, adicionado ou excluído entre uma replicação e outra. Esta é a principal característica da
replicação Snapshot Replication.
Podemos fazer com que um ou mais dos jobs sejam executados imediatamente, antes mesmo do
agendamento programado. Para isso basta clicar com o botão direito do mouse no job e, no menu de
opções que é exibido, clicar em Start Job. Também convém lembrar que, para a replicação do tipo
Snapshot replication, o Snapshot agent roda no distributor. Quando o agente é executado, ele se conecta
com o publisher e copia os dados do publisher para o distributor.
Já vimos que, ao habilitarmos a replicação, uma série de modificações foi feita em SERVIDOR\SQL2005.
Agora vamos verificar se os dados foram realmente replicados para o Banco de Dados ExReplicacao da
instância SERVIDOR2\CURSOSJB. Os dados já devem ter sido replicados, pois, conforme conferimos
no histórico de replicação, os jobs responsáveis pela replicação executaram com sucesso. Mas nunca é
demais dar uma conferida.
Também cabe lembrar que, na publicação Minha Publicação, que foi criada para a replicação, temos
apenas três artigos. Somente os dados dos artigos que fazem parte da publicação é que são replicados e
não todo o Banco de Dados AdventureWorks. Apenas para recordar, os artigos da Publicação1 estão
definidos conforme indicado a seguir:
♦ Art_Produtos: Este artigo conterá todos os registros da tabela Product.
♦ Art_Employee: Este artigo conterá apenas algumas das colunas da tabela Employee, ou seja,
aplicaremos um filtro Vertical. Este artigo irá replicar somente os seguintes campos da tabela Em-
ployee: EmployeeID, NationalIDNumber, DepartmentID, ManagerID e EmergencyContactID.
♦ Art_Redmond: Este artigo será baseado na tabela Person.Address e irá replicar somente os registros
onde o campo City=’Redmond”. Ou seja, vamos aplicar um filtro horizontal, para replicar somente
as linhas que atendam a um determinado conjunto de critérios, no nosso exemplo: City=’Redmond”.
Exemplo prático: Para verificar se os dados estão sendo replicados com sucesso, para o Banco de Dados
ExReplicacao, da instância SERVIDOR2\CURSOSJB, siga os passos indicados a seguir:

2. Verifique se a instância SERVIDOR2\CURSOSJB aparece na lista de instâncias registradas, na
janela Registered Servers. Esta instância certamente já deve aparecer, se não você não teria
conseguido criar a subscrição, em um dos exemplos anteriores. Se, por algum motivo, esta
instância não estiver aparecendo, clique com o botão direito do mouse em Microsoft SQL
Servers, na janela Registered Servers e, no menu de opções que é exibido, clique em New ->
Server Registration, para registrar a instância SERVIDOR2\CURSOSJB.
3. Na janela Object Explorer, dê um clique no sinal de + ao lado da instância SERVIDOR2\CURSOSJB,
para exibir as opções disponíveis.
4. Abaixo de SERVIDOR2\CURSOSJB, dê um clique no sinal de +, ao lado da opção Databases.
5. Nas opções que são exibidas, observe que o Banco de Dados ExReplicação já é exibido na lista
de Banco de Dados, conforme indicado na Figura 8.39. Este é um indicativo de que a replicação
já foi executada, pelo menos uma vez, com sucesso.
Figura 8.39 O Banco de Dados ExReplicacao.
6. Dê um clique no sinal de + ao lado de ExReplicacao, para exibir os objetos deste Banco de Dados.
7. Dê um clique no sinal de + ao lado da opção Tables, para exibir as tabelas do Banco de Dados
ExReplicacao. Observe que, além da opção System Tables, são exibidas três outras tabelas,
justamente as tabelas criadas pela replicação:
♦ dbo.Address
♦ dbo.Employee
♦ dbo.Product
NOTA
O nome das tabelas no Banco de Dados de destino não precisa ser igual ao nome no Banco de Dados de origem. Lembre que esta opção é configurada
quando criamos a publicação. Para maiores detalhes, consulte o exercício, neste capítulo, onde criamos a publicação Minha Publicação.
8. Clique com o botão direito do mouse no Banco de Dados ExReplicação e, no menu de opções
que é exibido, clique em New Query. Será exibida a janela de execução de comandos T-SQL.
Execute o seguinte comando:
SELECT * FROM dbo.Address
Observe que somente temos endereços para a cidade de Redmond. Isso confirma que o filtro que
colocamos no artigo Art_Redmond está funcionando corretamente. Apenas para lembrar, durante a
criação da publicação Minha Publicação, definimos o seguinte filtro, para o artigo que publica a tabela
Address: City = ‘Redmond’. Observe que o filtro está sendo aplicado, pois somente estão sendo replicados
os registros da tabela Address, onde City=’Redmond’. Pelo jeito funciona mesmo.
9. Mantenha a janela de execução de comandos T-SQL aberta. Vamos utilizá-la logo em seguida.
Vamos também conferir se a replicação da tabela Employee está funcionando corretamente. Lembre que,
para esta tabela, definimos um filtro vertical, onde somente devem ser replicados os seguintes campos:
♦ EmployeeID
♦ NationalIDNumber
♦ DepartmentID
♦ ManagerID
♦ EmergencyContactID
10. Execute o seguinte comando:
SELECT * FROM dbo.Employee
Observe que somente foram replicados os campos EmployeeID, NationalIDNumber, DepartmentID,

ManagerID e EmergencyContactID, conforme indicado na Figura 8.40:
Figura 8.40 Filtro vertical para a tabela Employee.
Isto comprova que o nosso filtro vertical está funcionando corretamente.
11. Feche a janela de execução de comandos T-SQL. Se for emitida uma mensagem, perguntando
se você deseja salvar os comandos, clique em No.
KNOW-HOW EM: CONFIGURAR SUBSCRIÇÕES

DO TIPO PULL SUBSCRIPTIONS
PRÉ-REQUISITOS
♦ Ter criado publicações no item anterior.
METODOLOGIA
♦ Apresentação dos comandos e assistentes para configuração de subscrição do tipo Pull subscription.
TÉCNICA
♦ Configurar uma subscrição do tipo Pull subsciption utilizando o SQL Server Management Studio.
Pull subscriptions são configuradas no subscriber, ou seja, é o subscriber que tomará a iniciativa de
solicitar que a replicação seja iniciada e os dados sejam enviados do distributor para o subscriber. Pull
significa puxar, ou seja, o subscriber “puxa” os dados que estão no distributor.
Com este tipo de subscrição deixamos o controle e o agendamento da replicação a cargo de cada
subscriber. A administração fica mais distribuída mas, ao mesmo tempo, damos maior liberdade para
cada subscriber. Outro fato importante é que os agentes de replicação rodam no subscriber, o que alivia
a carga no distributor. Por exemplo, localidades ligadas por links mais lentos podem programar a
replicação em períodos mais espaçados (maior latência na atualização dos dados). Este tipo de subscrição
também é indicado para usuários móveis. Por exemplo, um vendedor que, ao atender o cliente, conecta-
se à rede da empresa, utilizando uma linha telefônica e “dispara” uma replicação (puxa) para atualizar
uma tabela de preços ou um catálogo de produtos e promoções.
Para Pull subscriptions o agente de replicação roda no subscriber, consumindo memória e processador
deste equipamento. Vamos a um exemplo prático.
Exemplo prático: Vamos criar uma subscrição do tipo Pull subscription em SERVIDOR2\CURSOSJB.
Esta subscrição será baseada na publicação Minha Publicação, criada anteriormente, no publisher
SERVIDOR\SQL2005. Os dados replicados serão armazenados no Banco de Dados ExPullReplication, o
qual será criado durante o processo de configuração da subscrição. Agendaremos esta subscrição para
replicar diariamente, de 6 em 6 horas. Neste exemplo o publisher é a instância SERVIDOR\SQL2005 e
o subscriber é a instância SERVIDOR2\CURSOSJB. Quem iniciará a replicação é a instância
SERVIDOR2\CURSOSJB, pois é uma Pull subscription. Dizemos que a instância SERVIDOR2\CURSOSJB
“puxa” os dados do distributor.
Para criar a subscrição do tipo Pull subscription solicitada, siga os passos indicados a seguir:
2. Certifique-se de que a instância SERVIDOR2\CURSOSJB esteja registrada no SQL Server Man-
agement Studio. Se esta instância ainda não estiver registrada, registre-a, seguindo os passos já
descritos nos exemplos anteriores.
3. Na janela Object Explorer, dê um clique no sinal de + ao lado da instância
SERVIDOR2\CURSOSJB, para exibir as opções disponíveis nesta instância.
4. Clique com o botão direito do mouse na opção Replication e, no menu de opções que é aberto,
clique em New -> Subscriptions.
5. Será aberto o assistente para criação de novas subscrições – New Subscription Wizard. A
primeira tela do assistente é somente informativa. Clique em Next, para seguir para a próxima
lista publisher, selecione a instância SERVIDOR\SQL2005 (pois é nesta instância que está a
publicação Minha Publicação, para a qual estamos criando uma Subscrição). Se não veio
disponíveis (no nosso exemplo somente será exibida a publicação Minha Publicação). Clique
na publicação Minha Publicação, para selecioná-la, conforme indicado na Figura 8.41:
Figura 8.41 A publicação Minha Publicação, criada anteriormente.
tipos, terá que rodar o assistente mais de uma vez. Certifique-se de que a opção (pull subscrip-
tions) esteja selecionada.
subscribers da publicação Minha Publicação. Por padrão, somente a própria instância, na
qual estamos trabalhando, é exibida na lista. No nosso exemplo, por padrão somente a
instância SERVIDOR2\CURSOSJB, que é onde estamos trabalhando, está sendo exibida.
Certifique-se de que somente esta instância esteja selecionada. Na coluna Subscription data-
base, você deve informar se os dados serão replicados para um Banco de Dados já existente
ou para um novo Banco de Dados. Para o nosso exemplo, na coluna Subscription Database,
selecione a opção New database.
11. Será aberta a janela para criação de um novo Banco de Dados, janela esta que você aprendeu a
utilizar no Capítulo 3. Utilizando os conhecimentos do Capítulo 3, crie um Banco de Dados
com as seguintes características (é importante salientar que, antes de criar este Banco de Dados,
a pasta C:\livrosql\Ex2Replicacao já deve ter sido criada, caso contrário será gerado um erro,
quando o SQL Server 2005 tentar criar o Banco de Dados. Se esta pasta ainda não existe, abra o
Windows Explorer e crie a pasta C:\livrosql\Ex2Replicacao):
Tabela 8.4 O Banco de Dados NorthwindPull.
Primário C:\livrosql\Ex2Replicacao\Ex2Replicacao-rim.mdf
Secundário C:\livrosql\Ex2Replicacao\Ex2Replicacao-sec1.ndf
Arquivo de log C:\livrosql\Ex2Replicacao\Ex2Replicacao-log1.ldf
Arquivo de log C:\livrosql\Ex2Replicacao\Ex2Replicacao-log2.ldf
crescimento automático habilitado.
NOTA
A criação de um novo Banco de Dados para receber os dados replicados não é, de maneira alguma, obrigatória. Poderíamos utilizar um
Banco de Dados já existente. Optamos por criar um novo Banco de Dados para salientar a execução deste procedimento.
12. A tela de criação do novo banco de dados deverá estar conforme indicado na Figura 8.42.
13. Clique em OK para criar o Banco de Dados ExReplicacao. Você estará de volta ao assistente de
subscrição.
14 . Clique em Next, para seguir para a próxima etapa do assistente.
15 . Nesta etapa você irá definir as configurações de segurança (conta de conexão e opções de
conexão), para cada agente de distribuição que for utilizado. No nosso exemplo, há um único
agente de Distribuição, pois configuramos um único subscriber. Se você tivesse configurado
vários subscribers, seriam listados tantos agentes de distribuição quantos fossem os subscribers
configurados. Clique no botão OK, para fazer as configurações de segurança. Será aberta a
janela Distribution Agent Security. Informe a conta a ser utilizada e a respectiva senha, conforme
indicado na Figura 8.43. As contas devem ser informadas no formato NOME-DO-
SERVIDOR\NOME-DACONTA ou NOME-DO-DOMÍNIO\NOME-DA-CONTA. Não altere as
demais opções. Clique em OK. Você estará de volta ao assistente.
Figura 8.42 Definições para criação do Banco de Dados Ex2Replicacao.
temos um único subscriber. Vamos configurar uma replicação diariamente, de seis em seis
horas. Clique na coluna Agent Schedule, abra a lista e selecione a opção Define Schedule.
18. Será aberta a janela para definição do agendamento, janela esta que você já aprendeu a utilizar
no capítulo sobre jobs e agendamento de tarefas. Para definir uma replicação diária, de seis em
seis horas, configure as opções indicadas na Figura 8.44 e clique em OK para criar o agendamento.
completa, do tipo Snapshot dos dados e do schema. Nesta etapa você informa, para cada
subscrição (no nosso exemplo é uma única subscrição), quando que este snapshot inicial deverá
ize When”, ou no próximo agendamento – opção At first synchronization. Por padrão, vem
T-SQL. Marque as duas opções desta etapa.
selecionadas. Caso você tenha que alterar alguma opção, é só utilizar o botão Back. Clique em
Finish para encerrar o assistente e criar a subscrição (ou subscrições, caso você tenha configurado
mais de uma subscrição).
do trabalho. Concluídas as diversas etapas de criação da subscrição, clique no botão Close para
fechar a janela New Subscription Wizard. Muito bem, a subscrição foi criada. A partir deste
momento, a instância SERVIDOR2\CURSOSJB passará a receber os dados da publicação Minha
Publicação, da instância SERVIDOR\SQL2005. Esta replicação será feita de seis em seis horas e
os dados serão gravados no Banco de Dados Ex2Replicacao.
Apenas a título de curiosidade, coloco a seguir o script gerado pelo assistente (lembre que, em uma das
etapas finais, marcamos a opção para gerar um arquivo com todos os comandos T-SQL, necessários
para criação da subscrição):
*********************************************************************************************************
————————BEGIN: Script to be run at Publisher ‘SERVIDOR\SQL2005’————————-
exec sp_addsubscription @publication = N’Minha Publicação’, @subscriber =
N’SERVIDOR2\CURSOSJB’, @destination_db = N’Ex2Replicacao’, @sync_type = N’Automatic’,
@subscription_type = N’pull’, @update_mode = N’read only’
GO
————————END: Script to be run at Publisher ‘SERVIDOR\SQL2005’————————-
————————BEGIN: Script to be run at Subscriber ‘SERVIDOR2\CURSOSJB’————————-
use [Ex2Replicacao]
exec sp_addpullsubscription @publisher = N’SERVIDOR\SQL2005', @publication = N’Minha
Publicação’, @publisher_db = N’AdventureWorks’, @independent_agent = N’True’,
@subscription_type = N’pull’, @description = N’’, @update_mode = N’read only’, @immediate_sync
= 1
exec sp_addpullsubscription_agent @publisher = N’SERVIDOR\SQL2005', @publisher_db =
N’AdventureWorks’, @publication = N’Minha Publicação’, @subscriber = N’SERVIDOR2\CURSOSJB’,
@subscriber_db = N’Ex2Replicacao’, @distributor = N’SERVIDOR\SQL2005',
@distributor_security_mode = 1, @distributor_login = null, @distributor_password = null,
@enabled_for_syncmgr = N’False’, @frequency_type = 4, @frequency_interval = 1,
@frequency_relative_interval = 0, @frequency_recurrence_factor = 1, @frequency_subday = 8,
@frequency_subday_interval = 6, @active_start_time_of_day = 0, @active_end_time_of_day =
235900, @active_start_date = 20050510, @active_end_date = 99991231, @alt_snapshot_folder =
N’’, @working_directory = N’’, @use_ftp = N’False’, @job_login = N’XYZ\Administrador’,
@job_password = N’’, @publication_type = 0
GO
————————END: Script to be run at Subscriber ‘SERVIDOR2\CURSOSJB’————————
*********************************************************************************************************
EXCLUINDO ELEMENTOS DA REPLICAÇÃO

Podemos facilmente remover subscrições e publicações.
Para remover uma Publicação, basta abrir o SQL Server Management Studio e navegar até a publicação
a ser excluída. Uma vez localizada a publicação, dê um clique com o botão direito do mouse na publicação
e, no menu de opções que é exibido, dê um clique na opção Delete.
Para remover uma subscrição, você deve navegar até a publicação, na qual está a subscrição a ser removida.
Clique no sinal de + ao lado da publicação. Serão exibidas todas as subscrições para a publicação, conforme
indicado na Figura 8.46, onde estão sendo exibidas as duas subscrições da publicação Minha publicação
(uma do tipo Pull e outra do tipo Push), que criamos nos exemplos deste capítulo.
Figura 8.46 As subscrições da publicação Minha Publicação.

NOTA
Para excluir uma subscrição, basta clicar com o botão direito do mouse na subscrição a ser excluída e, no menu de opções que é exibido, clicar
em Delete. Vamos a um exemplo prático.
Vamos remover a subscrição do tipo Pull subscription, que criamos anteriormente. Identificamos esta
replicação, facilmente, porque ela faz a replicação com o Banco de Dados Ex2Replicação. O nome dela
aparece como: SERVIDOR2\CURSOSJB: Ex2Replicação. O ícone, ao lado dela, é de uma folha inteira,
sem o canto dobrado. Para isso, siga os seguintes passos:
1. Abra o SQL Server Management Studio e navegue até a instância SERVIDOR\SQL2005.

2. No Object Explorer, clique no sinal de + ao lado da instância SERVIDOR\SQL2005.
3. Na lista de opções que é exibida clique no sinal de + ao lado da opção Replication, para exibir
as opções disponíveis.
4. Clique no sinal de + ao lado da opção Publications. Serão exibidas as publicações disponíveis,
que no nosso exemplo é somente a publicação Minha Publicação: AdventureWorks.
5. Clique no sinal ao lado de Minha Publicação: AdventureWorks, para exibir a lista de subscrições
desta publicação.
6. Na lista de subscrições que é exibida, clique com o botão direito do mouse em
SERVIDOR2\CURSOSJB: Ex2Replicação. No menu de opções que é exibido, clique em Delete.
7. Surge uma janela pedindo confirmação da exclusão. Nesta janela, indicada na Figura 8.47,
você também pode marcar a opção “Connect to subscriber and delete Record of this subscrip-
tion at subscriber also”. Se esta opção for marcada, as informações sobre a subscrição também
serão excluídas na instância SERVIDOR2\CURSOSJB. É importante salientar que somente as
informações e configurações da subscrição serão excluídas. Os dados que já foram replicados
não serão excluídos. Você pode confirmar isso, acessando a instância SERVIDOR2\CURSOSJB
e verificando que o Banco de Dados Ex2Replicacao e todas as suas tabelas, bem como os dados
que haviam sido replicados, são mantidos, mesmo após a exclusão da subscrição. Ao excluir
uma subscrição, apenas deixarão de ser feitas novas replicações. Porém os dados já replicados
serão mantidos. Dê um clique em Yes para confirmar.
Figura 8.47 Confirmando a exclusão da subscrição.
8. Será exibida a janela para você informar os dados para conexão com a instância
SERVIDOR2\CURSOSJB. Informe os dados de conexão e clique no botão Connect.
9. Muito bem, a subscrição foi excluída. Você pode confirmar este fato, pois a subscrição
SERVIDOR2\CURSOSJB: Ex2Replicação não é mais exibida abaixo da publicação Minha Publicação.
Ao excluirmos uma subscrição, o Banco de Dados de destino não será excluído. No nosso exemplo, o
Banco de Dados de destino era Ex2Replicaca, no subscriber que, no nosso exemplo, era a instância
SERVIDOR2\CURSOSJB.
KNOW-HOW EM: REPLICAÇÃO PARA OUTROS

TIPOS DE SUBSCRIBERS – NÃO SQL SERVER 2005
PRÉ-REQUISITOS
♦ Configurações de replicação no SQL Server 2005 apresentadas nos itens anteriores.
METODOLOGIA
♦ Apresentação dos comandos e assistentes para configuração de um subscriber que não seja um SQL Server 2005.
TÉCNICA
♦ Configurar um subscriber, que não seja o SQL Server 2005, utilizando o SQL Server Management Studio.
Podemos replicar dados para um subscriber que não seja uma instância do SQL Server 2005. Por exemplo,
podemos ter dados em um publisher SQL Server 2005, sendo replicados para um subscriber Microsoft
Access. Podemos replicar para diversos tipos de subscribers, como por exemplo:
♦ Microsoft Access
♦ ORACLE
♦ IBM DB2/AS400
♦ IBM DB2/MVS
♦ IBM DB2/NT
♦ IBM/DB2 6000
Também podemos ter subscribers do tipo ODBC ou OLE DB. Com isso, podemos replicar para qualquer
formato de dados, para o qual esteja disponível um drive ODBC ou um OLE DB Provider, o que amplia
enormemente as opções disponíveis.
Um drive ODBC deve atender os seguintes requisitos:
♦ Deve ser ODBC level-1 compilant (compatível com ODBC nível-1).
♦ Deve ser um drive de 32 bits e thread-safe.
♦ Deve suportar transações.
♦ Deve suportar DDL – Data Definition Language.
♦ Não pode ser read-only (somente leitura).
♦ Deve suportar nomes longos de tabelas, como por exemplo MSreplication_subscriptions.
Um OLE DB Provider deve ser capaz de suportar os seguintes objetos para a replicação transacional:
♦ Objeto DataSource.
♦ Objeto Session.
♦ Objeto Command.
♦ Objeto Rowset.
♦ Objeto Error.
NOTA
Estes objetos são suportados pela grande maioria dos OLE DB Providers disponíveis.
REPLICANDO DADOS PARA UM SUBSCRIBER DO MICROSOFT ACCESS

Para aprendermos a criar subscrições para outros tipos de subscribers, iremos fazer um exemplo prático.
Vamos criar uma subscrição para um Banco de Dados do Microsoft Access. Utilizaremos o Banco de
Dados C:\livrosql\ExReplicacao.mdb, o qual já deve ter sido criado previamente usando o Access. Use
o Access para criar o Banco de Dados ExReplicacao.mdb na pasta C:\livrosql. O passo seguinte será
adicionarmos este Banco de Dados, via configurações de ODBC, como um subscriber autorizado. Ao
adicionarmos um subscriber do Microsoft Access, este passará a aparecer como se fosse mais um servidor
registrado no SQL Server Management Studio, quando executamos o assistente para adição de novas
Subscrições. Depois iremos criar uma subscrição para este Banco de Dados para a publicação Minha
Publicação, a qual criamos nos exemplos anteriores. Como estamos configurando a publicação a partir
do publisher, será uma subscrição do tipo Push subscription, pois estaremos “empurrando” os dados
do publisher (SQL Server 2005 – SERVIDOR\SQL2005) para o subscriber (Microsoft Access –
C:\livrosql\ExReplicacao.mdb). Após criada a subscrição iremos conferir se os dados foram realmente
replicados para o Banco de Dados do Microsoft Access. Vamos aos exemplos práticos.
NOTA
Para que possamos criar subscrições para outros tipos de subscribers, que não o SQL Server 2005, devemos adicionar estes subscribers
previamente, conforme veremos no exemplo prático, logo a seguir.
Você pode acompanhar este exemplo utilizando tanto o Microsoft Access 97 quanto o Microsoft Access 2000.
Exemplo prático: Criar o Banco de Dados c:\livrosql\ExReplicacao.mdb configurar este Banco de Dados
como um subscriber da publicação Minha Publicação.
Para criar a subscrição solicitada, executaremos os seguintes procedimentos:
♦ Procedimento 1: Criar o Banco de Dados C:\livrosql\ExReplicacao.mdb.
♦ Procedimento 2: Registrar o Banco de Dados C:\livrosql\ExReplicacao.mdb. como um sub-

scriber autorizado.
♦ Procedimento 3: Criar uma subscrição do Banco de Dados do Microsoft Access, para a publicação
Minha Publicação da instância SERVIDOR\SQL2005, do SQL Server.
♦ Procedimento 4: Verificar se os dados estão sendo realmente replicados.

NOTA
Já havíamos criado a pasta C:\livrosql nos capítulos anteriores. Caso você ainda não tenha criado esta pasta, crie antes de iniciar este
procedimento.
Então mãos à obra, que temos bastante trabalho a fazer.
Procedimento 1: Para criar o Banco de Dados C:\livrosql\ExReplicacao.mdb, siga os passos indicados

a seguir (estou usando o Microsoft Access 2000):
1. Abra o Microsoft Access (Iniciar -> Programas -> Microsoft Access).
2. Na janela que surge, dê um clique na opção Banco de Dados vazio, para criar um novo Banco
de Dados do Access, conforme indicado na Figura 8.48. Clique no botão OK.
Figura 8.48 Criando um novo Banco de Dados do Access.
3. Surge a janela Novo arquivo de Banco de Dados, onde temos que informar a pasta e o nome do
Banco de Dados a ser criado.
4. Na lista Salvar em, selecione C:.
5. Serão exibidas todas as pastas do drive C:. Dê um clique duplo na pasta livrosql para abri-la.
6. No campo Nome do arquivo, digite ExReplicacao.mdb, e clique no botão Criar.
Será criado o Banco de Dados ExReplicacao.mdb e este será carregado no Microsoft Access. Observe
que é criado um Banco de Dados vazio, sem nenhuma tabela. Após a replicação, nós vamos abrir este
Banco de Dados novamente e vamos verificar que os artigos da publicação Minha Publicação foram
replicados como tabelas no Banco de Dados ExReplicacao.mdb.
7. Feche o Microsoft Access.
Agora vamos registrar este Banco de Dados como um subscriber autorizado no publisher
SERVIDOR\SQL2005.
Procedimento 2: Para registrar o Banco de Dados C:\livrosql\ ExReplicacao.mdb como um subscriber

autorizado no publisher SERVIDOR\SQL2005, siga os passos indicados a seguir:
2. No Object Explorer, clique no sinal de + ao lado da instância SERVIDOR\SQL2005.
3. Clique com o botão direito do mouse na opção Replication. No menu de opções que é exibido
clique em Publisher Properties.
4. Será aberta a janela de propriedades do publisher, com a guia General selecionada por padrão.
Para habilitar um subscriber que não seja SQL Server, vamos utilizar a guia subscribers. Dê um
clique na guia Subscriptions para selecioná-la. Serão exibidas as opções indicadas na Figura 8.49:
Figura 8.49 A guia subscribers.
5. Clique no botão Add. Nas opções que são exibidas, clique em Add OLE DB subscriber.
6. Será aberta a janela Propriedades de Vinculação de dados, com a guia Conexão selecionada, por
padrão. Dê um clique na guia Provedor. Serão exibidas as opções indicadas na Figura 8.50. Na guia
Provedor, você irá informar o formato dos dados do subscriber, que no nosso exemplo será Microsoft
Access (Microsoft Jet 4.0 OLE DB Provider). Selecione a opção indicada na Figura 8.50.
7. Clique na guia Conexão. No campo “Selecione ou insira o nome de um Banco de Dados”, digite
o seguinte: C:\livrosql\ExReplicacao.mdb. Se o Banco de Dados tiver um usuário e senha, digite
o nome do usuário, a respectiva senha e marque a opção Permitir salvamento de senha. No
nosso exemplo, não temos usuário e senha. Com isso serão usados os valores padrão, que é
Admin para o usuário, senha em branco, marcar a opção Senha em branco e deixar desmarcada
a opção Permitir salvamento de senha. Sua janela deve estar conforme indicado na Figura 8.51.
Figura 8.50 Definindo o formato dos dados do subscriber.
Figura 8.51 Definindo o Banco de Dados que será o subscriber.
8. Para verificar se as configurações estão OK e o SQL server consegue se comunicar com o Banco
de Dados do Access, dê um clique no botão Testar conexão. Se estiver tudo OK, será exibida a
janela indicada na Figura 8.52:
Figura 8.52 A conexão com o subscriber está OK.
9. Clique em OK para fechar o aviso.
10. Você estará de volta à janela Propriedades de vinculação de dados. Clique em OK para concluir
as configurações.
11. Você estará de volta à janela Publisher Properites. Obseve que agora já aparece na lista o sub-
scriber ExReplicação (o qual está associado ao Banco de Dados C:\livrosql\ExReplicacao.mdb),
Figura 8.53 O subscriber do Access já aparece na lista.
12. Clique no botão de reticências ..., ao lado de ExReplicação e certifique-se de que o nome do
usuário esteja como Admin e senha em branco, conforme indicado na Figura 8.54. Esta
confirmação é necessária, porque às vezes o campo Login fica em branco e isso irá gerar um
erro na hora de criar o subscriber. Clique em OK para fechar esta janela. Você estará de volta à
janela Publisher Properties. Clique em OK para fechá-la.
Figura 8.54 Confirmando usuário e senha.
13. Você estará de volta ao SQL Server Management Studio e o subscriber do ExReplicação já estará
habilitado para ser um subscriber. Com isso já vencemos as etapas 1 e 2 do nosso exercício.
Agora só faltam as etapas 3 e 4, as quais repito a seguir:
♦ Procedimento 3: Criar uma subscrição do Banco de Dados do Microsoft Access, para a

publicação Minha publicação da instância SERVIDOR\SQL2005, do SQL Server.
♦ Procedimento 4: Verificar se os dados estão sendo realmente replicados.
Vamos então executar os procedimentos que estão faltando.
Procedimento 3: Para criar uma Subscrição do tipo Push subscription, do Banco de Dados do Microsoft
Access, para a publicação Minha Publicação, da instância SERVIDOR\SQL2005 do SQL Server 2005,

3. Clique no sinal + ao lado da opção Replication, abaixo da instância SERVIDOR\SQL2005, para
4. Clique no sinal de + ao lado da opção Publications, para exibir as publicações disponíveis
nesta instância. No momento, deve estar disponível somente a publicação Minha Publicação,
criada anteriormente.
5. Clique com o botão direito do mouse na publicação Minha Publicação e, no menu de opções
que é exibido, clique em New Subscriptions.
6. Será aberto o assistente para criação de novas subscrições – New Subscription Wizard. A primeira tela
do assistente é somente informativa. Clique em Next, para seguir para a próxima etapa do assistente.
lista publisher, já deve ter vindo selecionada a instância SERVIDOR\SQL2005. Se não veio
disponíveis (no nosso exemplo somente será exibida a publicação Minha Publicação, pois é a
única disponível). Clique na publicação Minha Publicação, para selecioná-la.
tipos, terá que rodar o assistente mais de uma vez. Certifique-se de que a opção (push subscrip-
tions) esteja selecionada. Como o subscriber será um Banco de Dados do Microsoft Access,
vamos usar um subscrição do tipo Push Subscription, ou seja, os agentes vão rodar no distribu-
tor (que será o SQL Server 2005), empurrando (push = empurrar) os dados para as tabelas do
Banco de Dados do Access.
subscribers da publicação Minha Publicação. Observe que, na lista de possíveis subscribers, já
aparece o subscriber ExReplicação, que é justamente o subscriber que configuramos na Etapa
2. Este subscriber está associado ao arquivo C:\livrosql\ExReplicacao.mdb. Selecione o sub-
scriber ExReplicacao. Sua janela deve estar conforme indicado na Figura 8.55. A replicação será
feita com o Banco de Dados ExReplicacao.mdb, e cada artigo da pubilcação será uma tabela no
Banco de Dados de destino.
12 . Clique em Next, para seguir para a próxima etapa do assistente.
13. Nesta etapa você irá definir as configurações de segurança (conta de conexão e opções de
conexão), para cada agente de distribuição que for utilizado. No nosso exemplo, tem um
único agente de Distribuição, pois configuramos um único subscriber. Se você tivesse
configurado vários subscribers, seriam listados tantos agentes de distribuição quantos fossem
os subscribers configurados. Clique no botão ..., para fazer as configurações de segurança.
Será aberta a janela Distribution Agent Security. Informe a conta a ser utilizada e a respectiva
senha, conforme indicado na Figura 8.56. Não altere as demais opções. Clique em OK. Você
estará de volta ao assistente.
Figura 8.55 O subscriber ExReplicacao.
temos um único subscriber. Vamos configurar uma replicação diariamente, de duas em duas
horas. Clique na coluna Agent Schedule, abra a lista e seleicone a opção Define Schedule.
16. Será aberta a janela para definição do agendamento, janela esta que você já aprendeu a
utilizar no capítulo sobre jobs e agendamento de tarefas. Para definir uma replicação diária,
de duas em duas horas, configure as opções indicadas na Figura 8.57 e clique em OK para
criar o agendamento.
completa, do tipo Snapshot dos dados e do schema. Nesta etapa você informa, para cada
subscrição (no nosso exemplo é uma única subscrição), quando que este snapshot inicial deve
ize When”, ou no próximo agendamento – opção At first synchronization. Por padrão, vem
T-SQL. Marque as duas opções desta etapa.
selecionadas. Caso você tenha que alterar alguma opção, é só utilizar o botão Back. Clique em
Finish para encerrar o assistente e criar a subscrição.
do trabalho.
26. Concluídas as diversas etapas de criação da subscrição, clique em Close para fechar a janela
New Subscription Wizard. Muito bem, a subscrição foi criada. A partir deste momento, o Banco
de Dados C:\livrosql\ExReplicacao.mdb passará a receber os dados da publicação Minha
Publicação, da instância SERVIDOR\SQL2005. Esta replicação será feita de duas em duas horas
e os dados serão gravados no Banco de Dados ExReplicacao.mdb. Cada artigo da publicação
será uma tabela no Banco de Dados ExReplicacao.mdb. A seguir veremos como conferir se a
subscrição foi realmente criada e vamos verificar se os dados estão sendo copiados para o
Banco de Dados ExReplicacao.mdb.
Antes, apenas a título de curiosidade, coloco a seguir o script gerado pelo assistente (lembre que, em
uma das etapas finais, marcamos a opção para gerar um arquivo com todos os comandos T-SQL,
necessários para criação da subscrição):
*********************************************************************************************************
————————BEGIN: Script to be run at Publisher ‘servidor\sql2005’————————-
exec sp_addsubscription @publication = N’Minha Publicação’, @subscriber = N’ExReplicacao’,
@destination_db = N’(default destination)’, @subscription_type = N’Push’, @sync_type =
N’automatic’, @article = N’all’, @update_mode = N’read only’
exec sys.sp_addpushsubscription_agent @publication = N’Minha Publicação’, @subscriber =
N’ExReplicacao’, @subscriber_db = N’(default destination)’, @job_login =
N’SERVIDOR\Administrador’, @job_password = N’’, @subscriber_security_mode = 0,
@subscriber_login = N’Admin’, @frequency_type = 4, @frequency_interval = 1,
@frequency_relative_interval = 0, @frequency_recurrence_factor = 1, @frequency_subday = 8,
@frequency_subday_interval = 2, @active_start_time_of_day = 0, @active_end_time_of_day =
235900, @active_start_date = 20050512, @active_end_date = 99991231, @enabled_for_syncmgr =
N’False’, @dts_package_location = N’Distributor’
GO
————————END: Script to be run at Publisher ‘servidor\sql2005’————————-
*********************************************************************************************************
Muito bem. Já criamos o Banco de Dados C:\livrosql\ExReplicacao.mdb – Procedimento 1. Depois

habilitamos um subscriber que aponta para este Banco de Dados, com o nome de ExReplicacao –
Procedimento 2. Na seqüência, criamos uma subscrição do tipo Push subscription para o subscriber
ExReplicacao – Procedimento 3.
Agora vamos abrir o Banco de Dados C:\livrosql\ExReplicacao.mdb, para verificar se os dados foram
realmente replicados.
Procedimento 4: Para verificar se os dados foram realmente replicados, faça o seguinte:
1. Abra o Windows Explorer (Iniciar -> Programas -> Acessórios -> Windows Explorer) e navegue
até a pasta C:\livrosql.
2. Dê um clique duplo no arquivo ExReplicacao.mdb para abri-lo no Microsoft Access. Já devem
aparecer as tabelas: Orders, Products e Customers.
Neste item podemos ver, na prática, a possibilidade de replicar dados entre diferentes formatos.
Esta possibilidade facilita a integração de Bancos de Dados do SQL Server, com diversos outros
formatos de Bancos de Dados. Esta é uma funcionalidade de grande valor, principalmente para as
empresas que trabalham com diferentes formatos de dados, e que precisam acessar estes dados de
uma maneira consolidada.
CONCLUSÃO
Neste capítulo aprendemos sobre os princípios básicos de replicação com o SQL Server 2005.
Iniciamos o capítulo apresentando uma série de conceitos sobre a replicação no SQL Server 2005.
Aprendemos sobre a metáfora Publisher -> subscriber utilizada no SQL Server. Também aprendemos
que no meio do caminho existe um tal de distributor. Analisamos algumas situações onde a replicação
pode ser aplicada com sucesso.
Também aprendemos sobre os diversos tipos de replicação existentes: Snapshot, Transaction e Merge.
Uma vez apresentada a teoria, partimos para uma série de exemplos práticos, os quais ilustram os
conceitos apresentados.
Iniciamos o nosso estudo prático pela criação de uma publicação – Minha Publicação. Utilizamos
um assistente passo a passo para a criação de uma nova publicação. Vimos que uma publicação é
composta de um ou mais artigos. Um artigo pode ser uma tabela inteira, somente algumas colunas
de uma tabela (filtro horizontal), ou somente as linhas que atendam determinados critérios (filtro
vertical). Um artigo também pode ser uma view ou outros elementos, cuja execução gere um
conjunto de dados a ser replicado.
Após a criação da publicação, você aprendeu a criar uma ou mais subscrições para esta publicação.
Mostrei como criar subscrições do tipo Pull Subscriptions, onde o agente de replicação roda no sub-
scriber, puxando os dados a partir do distributor. Também mostrei como criar uma subscrição do tipo
Push Subscription, onde o agente de replicação é executado no distributor, empurrando os dados para
um ou mais subscribers.
O assunto Replicação é bastante extenso. Sem nenhuma dúvida, daria para escrever um livro inteiro,
com 500 ou 600 páginas, só sobre Replicação no SQL Server 2005. A Microsoft fez um bom trabalho de
documentação, especialmente neste tópico de Replicação. A parte sobre Replicação, no Books Online,
está realmente muito boa. Com os fundamentos apresentados neste capítulo, você terá condições de
acompanhar, sem problemas, a documentação sobre Replicação do Books Online. Para acessar esta
documentação, abra o Books Online: Iniciar -> Programas -> Microsoft SQL Server 2005 -> Books
Online. Clique no sinal de + ao lado de SQL Server Books Online. Dentre as opções que são exibidas,
clique no sinal de + ao lado de Replication. Você terá acesso a centenas de páginas, com excelentes
informações sobre a Replicação no SQL Server 2005. No site http://www.microsoft.com/sql, você também
encontra artigos detalhados e sempre atualizados sobre a Replicação e sobre as demais funcionalidades
do SQL Server 2005. É um site de visita obrigatória para quem trabalha com o SQL Server 2005 ou com
as versões anteriores do SQL Server.
Muto bem, a partir do próximo capítulo, começarei a tratar de assuntos relacionados com o
desenvolvimento de aplicações que utilizam o SQL Server 2005 como Banco de Dados.
Capítulo 9
DESENVOLVIMENTO NO SQL
SERVER 2005 – ELEMENTOS BÁSICOS
INTRODUÇÃO
Neste capítulo aprenderemos tópicos relacionados ao desenvolvimento de aplicações no SQL Server
2005. Tratarei de elementos que são criados em um Banco de Dados do SQL Server 2005 e podem ser
acessados por aplicações desenvolvidas em Visual Basic, Delphi, ASP, ASP.NET, etc.
Iniciaremos o capítulo falando sobre integridade de dados. No Capítulo 1 apresentei os conceitos de

chave primária, Chave Estrangeira, relacionamentos e tipos de relacionamentos e integridade referencial.
No SQL Server 2005, a integridade de dados é configurada através do uso de constraints, rules, stored
procedures e defaults. Aprenderemos sobre os tipos de constraints existentes e também aprenderemos
a criar os diversos tipos de constraints que dão suporte à integridade de dados no SQL Server 2005.
Após implementada a integridade de dados, vamos testar o funcionamento, através de tentativas de
inserções e alterações que não “respeitem” as regras impostas, para verificar se o SQL Server irá “aplicar
as regras que nós definimos”. Para implementá-la, iremos fazer uma cópia do Banco de Dados Pubs.
Chamaremos a cópia de PubsIntF. Ao efetuarmos a cópia, iremos copiar apenas as tabelas e views,
sendo que não copiaremos as diversas constraints já existentes neste Banco de Dados. Depois passaremos
a implementar a integridade de dados na cópia PubsIntF. O banco de dados Pubs não é fornecido com
o SQL Server 2005. Ele era um banco de dados de exemplos, que era instalado com o SQL Server 2000.
Vamos importar o banco de dados Pubs de uma instância do SQL Server 2000 para a instância
SERVIDOR\SQL2005, do SQL Server 2005.
Uma vez implementada a integridade de dados através de constraints, aprenderemos a criar views.
Uma view nada mais é do que uma consulta, a qual pode ser baseada em um ou mais critérios e pode
acessar dados de uma ou mais tabelas. Com a utilização de views, podemos criar listagens consolidadas
dos dados. Por exemplo, em um Banco de Dados de vendas, corretamente modelado, de acordo com as
regras do Modelo Relacional de Dados, as informações sobre o cabeçalho do pedido estão na tabela
Pedidos e as informações sobre os itens de cada pedido estão na tabela Detalhes do pedido. Podemos
utilizar uma view, por exemplo, para obter uma listagem com o número do pedido, a data de envio, o
nome do cliente e o valor total, o qual é calculado através da soma dos itens individuais de cada
pedido. Observe que, neste caso, estamos acessando dados das tabelas Pedidos e Detalhes do Pedido.
Isto é possível de ser feito através da utilização de uma view. Além disso devemos ter definido um
relacionamento do tipo um para vários entre a tabela Pedidos (lado Um no campo NúmeroDoPedido)
e a tabela Detalhes do Pedido (lado Vários no campo NúmeroDoPedido), ou seja, um pedido pode
conter vários itens ou utilizar uma cláusula Join no comando T-SQL que define a view.
No final do capítulo aprenderemos a definir permissões de acesso a views e testaremos as permissões.
Para acompanhar os tópicos apresentados neste capítulo, o amigo leitor deve ter um bom entendimento dos conceitos de: chave primária,
NOTA
Relacionamentos, tipos de relacionamentos, chave estrangeira, normalização e noções básicas da linguagem T-SQL. Estes conceitos foram
apresentados no Capítulo 1. Caso você tenha dúvida em algum destes conceitos, revise o Capítulo 1 antes de iniciar o estudo dos tópicos deste
capítulo. Você também deve ter acesso a uma instância do SQL Server 2000, para poder importar o banco de dados Pubs. Caso você não tenha
acesso a uma instância do banco de dados Pubs, utilize qualquer outro banco de dados disponível. No exemplo, altere as referências ao banco de
dados Pubs, por referências ao banco de dados que você está utilizando. O mesmo deve ser feito em relação às tabelas e campos referenciados
nos exemplos, os quais deverão ser substituídos pelos nomes de tabelas e campos do banco de dados que você estiver utilizando.
CAPÍTULO 9 – DESENVOLVIMENTO NO SQL SERVER 2005 – ELEMENTOS BÁSICOS
KNOW-HOW EM: IMPORTANDO O BANCO DE DADOS PUBS,

DE UMA INSTÂNCIA DO SQL SERVER 2000
PRÉ-REQUISITOS
METODOLOGIA
♦ Utilização do DTS Import/Export Wizard, apresentada nos capítulos anteriores.
Neste tópico, mostrarei, passo a passo, como usar o DTS Import/Export Wizard, para importar o
banco de dados Pubs, de uma instância do SQL Server 2000, para a instância SERVIDOR\SQL2005,
do SQL Server 2005.
Exemplo prático: Para importar o banco de dados Pubs, de uma instância do SQL Server 2000 para a
instância SERVIDOR\SQL2005, do SQL Server 2005, siga os passos indicados a seguir:
1. Faça o logon com uma conta de administrador, no servidor onde está instalada a instância
SERVIDOR\SQL2005.
2. Abra o assistente de Importação/Exportação: Iniciar -> Programas -> Microsoft SQL Server 2004
-> DTS Import and Export Wizard.
3. Será aberto o assistente de importação e exportação de dados.
4. A primeira tela do assistente é apenas informativa. Clique em Next, para seguir para a próxima
5. Nesta etapa você deve informar a fonte dos dados, ou seja, de onde serão copiados os dados.
No meu exemplo, irei copiar os dados da instância padrão do SQL Server 2000, instalada em
um servidor chamado microxp-01. No campo Server name, digite microxp-01 e pressione Tab.
Aguarde alguns instantes até que o assistente conecte com o servidor microxp-01 e consiga
trazer a lista de tabelas da instância padrão. Após aguardar alguns instantes, abra a lista Data-
base e selecione o banco de dados Pubs.
7. Nesta etapa você deve informar o destino dos dados. O nosso objetivo é copiar o banco de
dados Pubs, de uma instância do SQL Server 2000 para a instância SERVIDOR\SQL2005. Ou
seja, o destino é um banco de dados do SQL Server 2005, na instância SERVIDOR\SQL2005.
Selecione as opções indicadas na Figura 9.1.
8. Já definimos para qual instância o banco de dados Pubs será importado. Agora temos que
definir o nome do banco de dados. Poderíamos importar os objetos do banco de dados Pubs
para dentro de um banco de dados já existente. Para isso, bastaria selecionar o banco de dados
na lista Database. No nosso exemplo, queremos criar um novo banco de dados, que será chamado
Pubs e, dentro deste novo banco de dados, importar todos os objetos do banco de dados Pubs,
de uma instância do SQL Server 2000. Dê um clique no botão New. Será exibida a janela Create
Database. Defina as configurações indicadas na Figura 9.2.
Figura 9.1 Definindo o destino dos dados.
Figura 9.2 Criando um novo banco de dados.
9. Dê um clique em OK. Você estará de volta ao assistente de importação, com o banco de dados
Pubs já selecionado, na lista Database.
11. Nesta etapa marque a opção “Copy data from one or more tables or views” e clique em Next,
13. Nesta etapa será exibida a lista de todos os objetos do banco de dados Pubs, os quais podem ser
importados. Clique no botão Select All, para selecionar todos os objetos.
15. Nesta etapa, certifique-se de que a opção Run immediately esteja selecionada e clique em Next,
Figura 9.3 Confirmando a importação do banco de dados Pubs.
16. Será exibida a tela final do assistente, com um resumo das opções selecionadas. Caso você
precise alterar alguma opção é só clicar em Back, para voltar para as etapas anteriores. Clique
em Finish para iniciar a importação dos dados.
17. O assistente inicia a importação e, uma vez concluída, o botão Close será habilitado. Clique
em Close para encerrar o assistente.
18. Pronto, o banco de dados Pubs foi importado para a nossa instância SERVIDOR\SQL2005.
Agora poderemos utilizar este banco de dados em nossos exemplos, deste capítulo. Você pode
abrir o SQL Server Management Studio e navegar até a opção Databases, da instância
SERVIDOR\SQL2005, para confirmar que o banco de dados Pubs e seus objetos foram realmente
importados, conforme indicado na Figura 9.3.
KNOW-HOW EM: IMPLEMENTAÇÃO DE

INTEGRIDADE DOS DADOS NO SQL SERVER 2005
PRÉ-REQUISITOS
METODOLOGIA
♦ Apresentação teórica sobre a implementação da integridade dos dados no SQL Server 2005.
♦ Apresentação dos tipos de integridade existentes no SQL Server 2005.
Implementar a integridade de dados, na prática, significa evitar que os dados de um Banco de

Dados estejam em um estado inconsistente. Um exemplo de dados em um estado inconsistente
é termos itens de um pedido, na tabela Detalhes do pedido, porém o cabeçalho do pedido não
existe na tabela Pedidos. Outro tipo de problema que temos que evitar é a entrada de valores fora
da faixa permitida em uma coluna. Por exemplo, se tivermos um campo Orçamento, em uma
tabela Projetos, podemos fazer com que este campo aceite um valor máximo, digamos de R$
25.000. Se for digitado um valor superior a R$25.000, o SQL Server 2005 não deve aceitar e o
registro não deve ser gravado.
Neste item, você aprenderá a definir diversos elementos que ajudam a manter a integridade e a
confiabilidade dos dados, no SQL Server 2005. Conforme descrito na introdução deste capítulo,
iniciaremos fazendo uma cópia do Banco de Dados Pubs (o qual foi importado no exemplo do
item anterior), da instância SERVIDOR\SQL2005. Os exemplos serão feitos na cópia do banco de
dados Pubs. Criaremos esta cópia em um Banco de Dados chamado PubsIntF, o qual será criado
neste item.
Exemplo prático: Criar o Banco de Dados PubsIntF, na instância SERVIDOR\SQL2005, e copiar as

tabelas e views do Banco de Dados Pubs para o BANCO DE DADOS PubsIntF, o qual deve ser criado
conforme indicado na Tabela 9.1.
Tabela 9.1 O Banco de Dados PubsIntF.
Primário C:\livrosql\PubsIntF\PubsIntF-prim.mdf.
Secundário C:\livrosql\PubsIntF\PubsIntF-sec.ndf.
Arquivo de log C:\livrosql\PubsIntF\PubsIntF-log1.ldf.
Arquivo de log C:\livrosql\PubsIntF\PubsIntF-log2.ldf.
Vamos dividir o nosso exercício em dois procedimentos.

NOTA
Antes de criar o Banco de Dados PubsIntF, a pasta C:\livrosql\PubsIntF já deve ter sido criada, caso contrário será gerada uma mensagem de
erro. Crie esta pasta.
Procedimento 1: Para criar o Banco de Dados PubsIntF, siga os passos indicados a seguir:

2. Na janela Object Explorer, clique com o botão direito do mouse na instância
SERVIDOR\SQL2005 e, no menu de opções que é exibido, clique em New Query.
Será aberta a janela de execução de comandos T-SQL.
3. Digite o seguinte conjunto de comandos:

CREATE DATABASE PubsIntF
ON
— *************************
— *************************
(NAME= PubsIntF_prim,
FILENAME = ‘C:\livrosql\PubsIntF\PubsIntF-prim.mdf ‘,
SIZE= 10MB,
MAXSIZE= 20MB,
FILEGROWTH = 10%),
— ***************************
— ***************************
(NAME= PubsIntF_sec,
FILENAME = ‘C:\livrosql\PubsIntF\PubsIntF-sec.ndf ‘,
SIZE= 10MB,
MAXSIZE= 20MB,
FILEGROWTH = 10%)
— *************************
— Definição dos Arquivos de Log
— *************************
LOG ON
(NAME= PubsIntF_log1,
FILENAME = ‘C:\livrosql\PubsIntF\PubsIntF-log1.ldf ‘,
SIZE= 10MB,
MAXSIZE= 20MB,
FILEGROWTH = 10%),
— *************************
— Segundo arquivo de log
— *************************
(NAME= PubsIntF_log2,
FILENAME = ‘C:\livrosql\PubsIntF\PubsIntF-log2.ldf ‘,
SIZE= 10MB,
MAXSIZE= 20MB,
FILEGROWTH = 10%)
— ***************************************
— ***************************************
PubsIntF terá sido criado e a seguinte mensagem será:
Com isso o nosso Banco de Dados PubsIntF foi criado, na instância SERVIDOR\SQL2005.
Agora vamos ao segundo procedimento, onde iremos copiar as tabelas e dados do Banco de Dados
Pubs da instância SERVIDOR\SQL2005, para o Banco de Dados PubsIntF, desta mesma instância, criado
no Procedimento 1.
Procedimento 2: Para copiar as tabelas e views do Banco de Dados Pubs da instância SERVIDOR\SQL2005,
para o Banco de Dados PubsIntF, siga os passos indicados a seguir:
2. Navegue até o banco de dados Pubs, da instância SERVIDOR\SQL2005.
3. Dê um clique com o botão direito do mouse no Banco de Dados Pubs. No menu de opções que
surge, selecione o comando Tasks -> Export Data.
Será iniciado o assistente DTS Import/Export Wizard. Na tela inicial é exibida uma mensagem com um
resumo das funcionalidades do assistente.
5. Nesta etapa definimos a origem dos dados. Como abrimos o assistente clicando com o botão
direito do mouse no Banco de Dados Pubs e selecionando o comando Tasks -> Export Data, o
Banco de Dados Pubs já vem definido como origem dos dados a serem exportados.
7. Nesta etapa, devemos definir o destino dos dados. No nosso caso o destino é o Banco de Dados
PubsIntF, da instância SERVIDOR\SQL2005. Na lista Server selecione SERVIDOR\SQL2005, e
na lista Database selecione PubsIntF, conforme indicado na Figura 9.4:
Figura 9.4 Definindo o destino dos dados.
9. Nesta etapa, certifique-se de que a opção “Copy data from one or more tables or views” esteja
selecionada, e clique em Next, para seguir para a próxima etapa do assistente.
10. Nesta etapa podemos selecionar quais tabelas e views serão copiadas para o Banco de Dados de
destino. Dê um clique no botão Select All, para copiar todas as tabelas e views, e depois clique
em Next, para seguir para a próxima etapa do assistente.
11. Nesta etapa podemos definir um agendamento, para que a cópia seja efetuada em períodos
determinados. Não é o nosso caso, somente queremos que a cópia seja efetuada uma vez.
Certifique-se de que a opção Run immediately esteja selecionada e que as demais opções estejam
desmarcadas. Dê um clique no botão Next, seguindo para a próxima etapa do assistente.
Você estará na tela final do assistente. Um resumo das opções selecionadas é apresentado nesta tela.
Caso você queira alterar alguma opção, utilize o botão Back.
12. Dê um clique no botão Finish.
É exibida uma tela com o progresso da cópia dos diversos objetos – tabelas e views.
13. No final, é exibida uma mensagem indicando que a cópia foi efetuada com sucesso. Dê um
clique em Close para fechar esta mensagem.
Você estará de volta ao SQL Server Management Studio; e todas as tabelas e views do Banco de Dados
Pubs foram copiadas para o PubsIntF.
Agora que já preparamos o Banco de Dados PubsIntF, vamos aprender a criar diversos elementos que
garantem a integridade e consistência dos dados, neste Banco de Dados.
OS TIPOS DE INTEGRIDADE DE DADOS EXISTENTES NO SQL SERVER 2005

Garantir a integridade dos dados significa termos dados confiáveis armazenados no Banco de
Dados, em resumo, dados de qualidade. No Books OnLine, encontramos a seguinte definição de
integridade de dados:
“Integridade dos dados é um estado no qual todos os dados armazenados no Banco de Dados estão
corretos. Se valores incorretos foram armazenados no Banco de Dados, dizemos que o banco de dados
perdeu a integridade dos dados.”
Por exemplo, não devemos permitir que sejam inseridos dois pedidos com o mesmo número de pedido
ou dois funcionários com o mesmo número de matrícula. Também não devemos aceitar que sejam
cadastrados produtos para uma categoria de produtos que não existe na tabela Categorias. Outro exemplo
de dado incorreto é um dado que está fora de uma faixa permitida. Por exemplo, a entrada de um valor
1.000.000.000 em um campo valor da hora extra.
Para garantir que estes tipos de incorreções não aconteçam é que o SQL Server 2005 disponibiliza uma
série de elementos que nos ajudam a garantir a integridade dos dados.
No SQL Server 2005, temos os seguintes tipos de integridade de dados:
♦ Integridade de Domínio (Domain Integrity): Este tipo de integridade também é conhecido
como integridade de Coluna e define o conjunto ou faixa de valores que são aceitáveis para um
determinado campo de uma tabela. Temos vários mecanismos para impor este tipo de
integridade. Por exemplo, ao definirmos o tipo de um campo como sendo numérico, já estamos
impedindo que sejam digitados valores de texto neste campo. O tipo de campo – integer,
double, etc. – também define uma faixa de valores aceitáveis. Também podemos utilizar con-
straints para impor integridade de domínio. Podemos definir uma constraint que somente
aceita, os valores 1, 2 ou 3 em um determinado campo. O conceito de constraint é semelhante
ao conceito de regra de validação, o qual é utilizado no Microsoft Access.
♦ Integridade de Entidade (Entity Integrity): Este tipo de integridade está relacionado com a
definição de uma chave primária para a tabela. Lembrando que um campo do tipo chave
primária não pode conter valores repetidos. Por exemplo, se definimos o campo CPF como
sendo a chave primária da tabela Clientes, não podemos cadastrar dois clientes com o mesmo
número de CPF, isto é, não podemos ter valores repetidos neste campo.
♦ Integridade Referencial: Conforme explicamos no Capítulo 1, a integridade referencial faz

com que o SQL Server impeça que algumas ações sejam executadas e força a execução de outras
ações. Para clarear este conceito, vamos considerar o exemplo da Figura 9.5.
Figura 9.5 Relação entre as tabelas Pedidos, Clientes e Detalhes do pedido.
Temos dois relacionamentos. Um relacionamento do tipo Um para Vários entre as tabelas Pedidos e
Detalhes do pedido, ou seja, Um pedido pode conter Vários itens. Temos um outro relacionamento do
tipo Um para Vários entre as tabelas Clientes e Pedidos, ou seja, um cliente pode fazer vários pedidos.
A integridade referencial pode evitar as seguintes situações:
♦ Que sejam adicionados registros em uma tabela relacionada (lado Vários), sem que tenha sido
adicionado o registro relacionado na tabela primária (lado Um). No nosso exemplo, isto evita
que sejam adicionados itens na tabela Detalhes do pedido, para um pedido que ainda não
tenha sido cadastrado na tabela Pedidos. Ou que seja adicionado um pedido para um Cliente
que ainda não foi cadastrado na tabela Clientes.
♦ Alteração de valores na tabela primária (lado Um), deixando “registros órfãos” na tabela
relacionada (lado Vários). No nosso exemplo, ao alterarmos o número do pedido na tabela
Pedidos, o campo NúmeroDoPedido dos itens relacionados, na tabela Detalhes do pedido, será
também atualizado. Este mecanismo é conhecido como Atualização em Cascata, no Microsoft
Access. Ou ao alterarmos o código do cliente, na tabela Clientes, o respectivo código também
será atualizado em todos os pedidos efetuados pelo cliente, na tabela Pedidos.
♦ Impedir que sejam excluídos registros na tabela primária (lado Um), se existirem registros
correspondentes na tabela relacionada (lado Vários). Por exemplo, impedir que seja excluído
um pedido na tabela Pedidos, para o qual ainda existam itens na tabela Detalhes do pedido. No
Microsoft Access, existe um mecanismo chamado Exclusão em Cascata. Quando este mecanismo
é ativado, se excluirmos o registro na tabela primária, todos os registros correspondentes, na
tabela relacionada, serão também excluídos.
Uma outra característica interessante é que a integridade pode ser definida pelo usuário. O usuário
pode definir regras personalizadas de integridade, em atendimento às necessidades de uma ou mais
aplicações. Por exemplo, podemos definir uma regra que impeça funcionários de uma determinada
categoria de aprovarem parcelamentos acima de um determinado valor. Estas regras podem ser
implementadas com o uso de constraints, stored procedures e triggers. Aprenderemos sobre constraints
e triggers neste capítulo e sobre stored procedures no próximo capítulo.
KNOW-HOW EM: CRIAÇÃO E TESTE DE

CONSTRAINTS NO SQL SERVER 2005
PRÉ-REQUISITOS
♦ Saber utilizar a janela de execução de comandos T-SQL.
♦ Noções sobre integridade de dados e os tipos de integridade de dados existentes no SQL Server 2005.
METODOLOGIA
♦ Apresentação do conceito de Constraint e dos procedimentos para a criação e teste de constraints.
TÉCNICA
♦ Utilização da janela de execução de comandos T-SQL para a criação e teste de constraints.
A utilização de constraints, para garantir a integridade dos dados, é o método recomendado pela própria
Microsoft. Com a utilização de constraints, a integridade dos dados é garantida automaticamente.
Podemos utilizar constraints para limitar os valores que podem ser inseridos em uma determinada
coluna (integridade de domínio) e também para garantir o relacionamento entre tabelas (integridade
referencial). Uma constraint que atua somente sobre uma coluna é chamada de “column Constraint”,
já uma constraint que atua sobre duas ou mais colunas; é conhecida como “table Constraint”.
Na Tabela 9.2, temos um resumo dos diversos tipos de constraints.
Tabela 9.2 Tipos de constraints e utilização de cada uma delas.
Tipo Descrição
DEFAULT Define um valor a ser atribuído a uma coluna, caso não tenha sido digitado nenhum valor para esta coluna.
Por exemplo, se a maioria dos clientes é da cidade de São Paulo, podemos definir um valor padrão São Paulo
para o campo Cidade. Com isso se não for especificado um valor diferente, o campo cidade conterá o valor São
Paulo, para cada novo registro que for criado na tabela Clientes. Este é um tipo de Integridade de domínio. No
Microsoft Access, esta propriedade é chamada de Valor padrão.
CHECK Define uma regra de validação para o campo. Por exemplo, podemos definir que o campo Salário não pode
conter valores maiores do que R$ 7.000,00. Este é um tipo de Integridade de domínio. No Microsoft Access, esta
propriedade é chamada de Regra de Validação.
PRIMARY KEY Define um campo como sendo chave primária da tabela. Não serão permitidos valores repetidos ou nulos
(NULL), neste campo. Ao definirmos um campo como chave primária, é criado um clustered index neste campo.
FOREIGN KEY Define um campo como chave estrangeira. Lembrando que a chave estrangeira é um campo ou conjunto de
campos em uma tabela secundária, relacionados com uma chave primária em uma tabela primária. Por exemplo,
o campo CódigoCliente, na tabela Pedidos, é uma chave estrangeira, relacionada com o campo chave primária
CódigoCliente, na tabela Clientes.
UNIQUE Não permite valores duplicados em um determinado campo, porém valores nulos são aceitos. Um índice é criado
para melhorar o desempenho. A diferença entre a constraint UNIQUE e a PRIMARY KEY é que a UNIQUE aceita
valores nulos e a PRIMARY KEY não.
Agora vamos a alguns exemplos práticos de criação dos diversos tipos de constraints.
Podemos criar constraints no momento de criação de uma tabela, quando utilizamos o comando CREATE
TABLE. Também podemos criar constraints em uma tabela já existente, utilizando o comando ALTER TABLE.
constraints podem estar associadas com uma ou mais colunas. Considere os seguintes fatos:
♦ Uma constraint associada com uma única coluna é conhecida como “column-level Constraint”.
♦ Uma constraint associada com múltiplas colunas é conhecida como “table-level Constraint”.
♦ DEFAULT constraints somente podem ser associadas com um único campo, isto é, são col-
umn-level constraints.
♦ constraints não são definidas na tabela do Banco de Dados, isto é, uma constraint não pode
referenciar colunas de outras tabelas. Por exemplo, não podemos definir uma constraint para
um campo da tabela Clientes, a qual acessa valores em outras tabelas.
♦ Podemos adicionar, alterar e excluir constraints, sem termos que excluir e recriar a tabela.
♦ Quando adicionamos uma constraint, o SQL Server 2005 verifica se os dados da tabela se
enquadram na constraint que está sendo adicionada. Por exemplo, se tentarmos adicionar
uma constraint do tipo UNIQUE, em um campo onde existem valores repetidos, a constraint
não será adicionada e uma mensagem de erro será emitida.
NOTA
Ao criar uma constraint, devemos definir um nome para a constraint, pois caso contrário o SQL Server 2005 irá gerar um nome. O problema
é que o nome gerado, automaticamente, pelo SQL Server 2005, não é nada amistoso e, tampouco, indicativo da função da constraint.
CRIANDO CONSTRAINTS COM COMANDOS T-SQL

Para criar constraints com a janela de execução de comandos T-SQL, utilizamos os comandos CREATE
TABLE, caso estejamos definindo uma ou mais constraints no momento da criação da tabela. Para
definirmos uma ou mais constraints, em uma tabela já existente, utilizamos o comando ALTER TABLE.
Vamos revisar a sintaxe destes comandos, focando apenas nas opções para criação de constraints:
Sintaxe para o comando CREATE TABLE:
CREATE TABLE table_name

( { < column_definition >
| Constraint constraint_name TIPO (coluna1, coluna2,..., coluna_n }
[ ,...n ]
)
Sintaxe para o comando ALTER TABLE, para excluir uma constraint existente:
ALTER TABLE nome_tabela

DROP CONSTRAINT nome_da_constraint
Sintaxe para adicionar uma constraint:
ALTER TABLE nome_tabela

ADD CONSTRAINT nome_da_constraint TIPO FOR nome(s)_do(s)_campo(s)
Vamos fazer alguns exemplos práticos para que possamos entender melhor a sintaxe e o funcionamento
destes comandos.
NOT NULL CONSTRAINT

Este é o tipo mais simples de constraint. Ele evita que sejam aceitos valores nulos em um determinado
campo.
Exemplo: No exemplo a seguir, criamos uma tabela chamada Clientes, onde os campos Nome, CPF e
Endereço não podem conter valores nulos.
CREATE TABLE Clientes

(
CPF char(14) NOT NULL,
Nome char(50) NOT NULL,
Endereço char(50) NOT NULL,
Fone char(20),
Cidade char(20),
e_mail char(50),
Empresa char(50)
)
Se tentarmos inserir um registro, onde temos um valor NULL para um dos campos – CPF, Nome ou
Endereço –, o SQL Server 2005 não insere o registro e emite uma mensagem de erro. Por exemplo,
vamos utilizar o seguinte comando:
INSERT INTO Clientes (CPF,Nome,Endereço,fone,cidade,e_mail,empresa)

VALUES (‘111.111.111-11’, ‘José da Silva’, NULL, ‘2222222’,‘Santa Maria’,‘’,‘’)
Este comando tenta inserir um registro na tabela Clientes. Porém estamos definindo um valor NULL
para o campo Endereço, o que não é permitido. Ao tentarmos executar este comando, será emitida a
seguinte mensagem de erro:

Cannot insert the value NULL into column ‘Endereço’, table ‘PubsIntF.dbo.Clientes’; column
does not allow nulls. INSERT fails.
DEFAULT CONSTRAINTS
Uma constraint do tipo DEFAULT é associada com uma única coluna. Quando inserimos um registro, se
não for fornecido um valor para uma determinada coluna, e esta coluna não tiver uma constraint DE-
FAULT associada, será atribuído o valor NULL para o campo associado à coluna. Caso tenha sido definida
uma constraint NOT NULL para a coluna, a inserção do registro falha e uma mensagem de erro será
exibida. Quando definimos uma constraint do tipo DEFAULT, estamos especificando qual valor será definido
para uma determinada coluna, em caso de não ter sido definido, explicitamente, um valor para a coluna.
Por exemplo, podemos definir como valor padrão para a coluna cidade o valor SÃO PAULO. Sempre que
for inserido um registro, sem que tenha sido definido um valor para a coluna Cidade, a coluna assumirá o
valor SÃO PAULO, ao invés de NULL. Conforme descrevemos anteriormente, este mecanismo é chamado
de Valor padrão, no Microsoft Access. DEFAUTL Constraint é um tipo de integridade de domínio.
Não podemos definir DEFAULT constraints para colunas que contenham o seguinte tipo de dados:
♦ timestamp
♦ IDENTITY
♦ ROWGUIDCOL
Os valores para este tipo de coluna são gerados automaticamente pelo SQL Server 2005.
DEFAULT constraints são aplicadas quando utilizamos um comando INSERT. Não são aplicadas para
comandos UPDATE. Podemos utilizar funções internas do SQL Server 2005 para definir o valor de uma
DEFAULT Constraint. Por exemplo, se quisermos que o valor DEFAULT de um campo data seja a data
do sistema, poderíamos utilizar a função GETDATE.
Vamos a alguns exemplos.
Vamos adicionar uma DEFAULT Constraint associada com a coluna Cidade da tabela Clientes, criada
nos exemplos do item anterior. Definiremos São Paulo como valor padrão para a coluna Cidade.
Para definir a constraint podemos executar o seguinte comando:
ALTER TABLE dbo.Clientes

ADD CONSTRAINT DefCidade DEFAULT ‘São Paulo’ FOR Cidade
Agora vamos inserir um registro onde não é fornecido o valor para o campo Cidade:
INSERT INTO dbo.Clientes (CPF,Nome,Endereço,fone)

VALUES (‘222.222.222-22’, ‘José da Silva’, ‘Rua abc - 20’, ‘2222222’)
Não informamos um valor para o campo Cidade. Como existe uma DEFAUTL Constraint definida para
este campo, ele assume o valor São Paulo, que é o valor definido na constraint. Como nós gostamos de
ver para crer, vamos dar um SELECT na tabela clientes, para conferir.
Conferindo o funcionamento da constraint DefCidade:
CPF Nome Endereço Fone Cidade e-mail Empresa

222.222.222-22 José da Silva Rua abc - 20 2222222 São Paulo NULL NULL
Observe que para os campos e-mail e Empresa, para os quais não foram informados valores e também
não existe DEFAUTL Constraint, foi definido como valor NULL.
Utilizamos os comandos sp_helpconstraint nome_da_tabela e sp_help nome_da_constraint para obter

informações a respeito de uma constraint. Considere os exemplos.
Obtendo informações sobre constraints na tabela Clientes:
exec sp_helpconstraint Clientes
Obtendo informações sobre a constraint DefCidade:
exec sp_help DefCidade
Na Figura 9.6, temos o resultado da execução deste comando.
Figura 9.6 Resultado do comando exec sp_help DefCidade.
CHECK CONSTRAINTS
Uma CHECK Constraint permite que seja definido um conjunto ou uma faixa de valores aceitáveis
para um determinado campo. Por exemplo, podemos definir que o campo Cidade somente deve aceitar
os valores ‘São Paulo’, ‘Rio de Janeiro’ e ‘Belo Horizonte’. Ou podemos definir uma faixa de valores; por
exemplo, uma coluna Salário deve estar na faixa de 1000 a 5000. Este mecanismo é conhecido como
Regra de Validação no Microsoft Access.
Considere o seguinte sobre CHECK constraints:
♦ É feita uma verificação dos dados toda vez que executamos um comando INSERT ou um
comando UPDATE.
♦ A definição da constraint pode referenciar outras colunas na mesma tabela, porém não pode
referenciar colunas de outras tabelas.
♦ Não podemos definir CHECK constraints para colunas que contenham o seguinte tipo de dados:
♦ timestamp
♦ IDENTITY
♦ unique-identifier
♦ Não pode conter subconsultas.
Para exemplificar o uso de CHECK constraints, vamos adicionar uma coluna financiamento, do tipo
float, a nossa tabela Clientes. Depois vamos criar duas constraints do tipo CHECK. Uma que define
que o financiamento deva estar na faixa de entre 1000 e 5000 reais e outra que defina que o campo
Bairro somente pode ser ‘Centro’, ‘Itararé’ ou ‘Camobi’.
Para adicionar o campo Financiamento, utilizamos o seguinte comando:

ADD Financiamento Float
Para definir que o campo Financiamento deve ser maior ou igual a 1000 e menor ou igual a 5000,
utilizamos o seguinte comando:

ADD CONSTRAINT FaixaFinanciamento
CHECK (Financiamento>=1000 AND Financiamento<= 5000)
Vamos testar esta constraint. Tentaremos inserir um registro, onde o financiamento é maior do que
5000. Tentaremos executar o seguinte comando:
INSERT INTO Clientes (CPF,Nome,Endereço,fone,cidade,e_mail,empresa,financiamento)

VALUES (‘666.333.333-33’, ‘Para Pedro’, ‘XYZ’, ‘2222222’,‘Santa Maria’,‘’,‘’,7000)
Este comando não será executado e a seguinte mensagem de erro será exibida:

INSERT statement conflicted with CHECK constraint ‘FaixaFinanciamento’.
The conflict occurred in database ‘PubsIntF’, table ‘Clientes’, column ‘Financiamento’.
Agora vamos alterar o nosso comando, reduzindo o financiamento a 3000,00. Com isso, o comando
será executado com sucesso:
INSERT INTO Clientes (CPF,Nome,Endereço,fone,cidade,e_mail,empresa,financiamento)

VALUES (‘333.333.333-33’, ‘Para Pedro’, ‘XYZ’, ‘2222222’,‘Santa Maria’,‘’,‘’,3000)
Vamos adicionar um campo chamado Bairro e depois vamos definir um conjunto de valores possíveis
para este campo.
Para adicionar o campo Bairro, utilizamos o seguinte comando:

ADD Bairro Char(25)
Para definir que o campo Bairro somente deve aceitar os valores ‘Centro’, ‘Itararé’ e ‘Camobi’, utilizamos
o seguinte comando:

ADD CONSTRAINT ValoresBairro
CHECK (Bairro=‘Centro’ or Bairro=‘Itararé’ or Bairro=‘Camobi’)
Vamos testar esta constraint. Tentaremos inserir um registro, onde o bairro é igual a ‘Urlândia’.
Tentaremos executar o seguinte comando:
INSERT INTO Clientes (CPF,Nome,Endereço,fone,cidade,e_mail,empresa,financiamento,bairro)

VALUES (‘444.444.444-44’, ‘Pedro Para’, ‘KKK’, ‘2222222’,‘Santa Maria’,‘’,‘’,2300,‘Urlândia’)
Este comando não será executado e a seguinte mensagem de erro será exibida:

INSERT statement conflicted with CHECK constraint ‘ValoresBairro’.
The conflict occurred in database ‘PubsIntF’, table ‘Clientes’, column ‘Bairro’.
Agora vamos alterar o nosso comando, alterando o bairro para ‘Centro’, que é um dos valores permitidos
pela constraint. O seguinte comando será executado com sucesso:

VALUES (‘444.444.444-44’, ‘Pedro Para’, ‘KKK’, ‘2222222’,’Santa Maria’,’’,’’,2300,’Centro’)
Podemos construir CHECK constraints mais elaboradas. Por exemplo, podemos construir uma que
somente aceite o CPF se este for digitado no formato nnn.nnn.nnn-nn, onde n é um número entre 0
e 9. Vamos a um exemplo.
Definir uma constraint que força o CPF a ser digitado no formato nnn.nnn.nnn-nn; caso contrário, o
registro não será aceito. Podemos utilizar o seguinte comando:

ADD CONSTRAINT FormatCPF
CHECK (CPF like ‘[0-9][0-9][0-9].[0-9][0-9][0-9].[0-9][0-9][0-9]-[0-9][0-9]’)
Vamos tentar inserir um registro em que o CPF não atende a regra definida na constraint FormatCPF.
Iremos trocar o tracinho por um ponto. Tente executar o seguinte comando:

VALUES (‘555.555.555.55’, ‘Maria Silva’, ‘POP’, ‘4445566’,‘Santa Maria’,‘’,‘’,2300,‘Centro’)
O comando não será executado e a seguinte mensagem de erro será emitida:

INSERT statement conflicted with CHECK constraint ‘FormatCPF’.
The conflict occurred in database ‘PubsIntF’, table ‘Clientes’, column ‘CPF’.
Também podemos utilizar os comandos sp_helpconstraint nome_tabela e sp_help nome_da_constraint

para obter informações sobre uma CHECK Constraint.
PRIMARY KEY CONSTRAINTS

Este tipo de constraint é utilizado para definir qual campo ou campos formam a chave primária de
uma tabela. Este campo não poderá conter valores repetidos ou NULL. O valor da chave primária,
identifica de maneira única cada registro de uma tabela, conforme já descrevemos no Capítulo 1, onde
falei sobre o Modelo Relacional de Dados. Ao definirmos uma chave primária é automaticamente
criado um índice associado ao campo chave primária. Por padrão, é criado um clustered index, desde
que ainda não exista um na tabela, uma vez que cada tabela somente pode conter um clustered index.
Também podemos definir que seja criado um nonclustered index. Lembrando que PRIMARY KEY é um
tipo de Entity integrity, conforme já descrito anteriormente.
Somente podemos ter uma chave primária em cada tabela. Os valores da chave primária devem ser
únicos e não são permitidos valores NULL. Podemos definir um campo como sendo chave primária,
no momento da criação da tabela, como no exemplo a seguir, onde criamos a tabela Pedidos e definimos
o campo NúmeroPedido, como sendo a chave primária da tabela:
CREATE TABLE Pedidos

(
NúmeroPedido char(14) PRIMARY KEY,
DataPedido datetime NOT NULL,
DataEnvio datetime NOT NULL,
MatrFunc char(20),
CNPJ char(20),
Empresa char(50)
)
O método utilizado neste exemplo não é o mais adequado, pois não atribuímos um nome a esta chave
primária, o que faz com que o SQL Server 2005 atribua, automaticamente, um nome nada intuitivo. O
ideal é que, ao criar a chave primária, também seja definido um nome para a chave. Vamos excluir a
tabela Pedidos e criá-la novamente, agora definindo um nome para a chave primária. Para isso utilizamos
o seguinte comando:
DROP TABLE Pedidos

GO
CREATE TABLE Pedidos
(
NúmeroPedido char(14) CONSTRAINT Num_Ped PRIMARY KEY,
DataPedido datetime NOT NULL,
DataEnvio datetime NOT NULL,
MatrFunc char(20),
CNPJ char(20),
Empresa char(50)
)
Também podemos definir uma chave primária em uma tabela já existente, desde que esta tabela
ainda não tenha uma chave primária, já definida. Para isto, utilizamos o comando ALTER TABLE.
No exemplo a seguir, utilizaremos este comando para definir o campo CPF da tabela Clientes
como sendo a chave primária:

ADD CONSTRAINT PrimCPF PRIMARY KEY CLUSTERED(CPF)
Se você tentar definir um campo como chave primária e já existir uma chave primária definida na
tabela, a seguinte mensagem de erro será exibida:

Table ‘Clientes’ already has a primary key defined on it.
Could not create Constraint. See previous errors.
UNIQUE CONSTRAINTS
Ao definirmos uma UNIQUE Constraint em uma coluna, estamos garantindo que não existam valores
repetidos para esta coluna. Porém a coluna pode aceitar valores NULL, sendo esta uma das diferenças
da UNIQUE Constraint em relação à PRIMARY KEY Constraint. Outra diferença é que podemos ter
várias UNIQUE constraints em uma mesma tabela, diferentemente de PRIMARY KEY Constraint, que
somente pode existir uma por tabela.
Somente podemos criar uma UNIQUE Constraint em uma coluna que não faça parte de uma chave
primária. Uma UNIQUE Constraint pode ser formada por uma ou mais colunas, caso em que teremos
uma UNIQUE CONSTRAINT composta. Uma coluna com uma UNIQUE Constraint pode ser referenciada
por uma chave estrangeira, definida por uma FOREIGN KEY Constraint.
A unicidade de um campo associado a uma UNIQUE CONSTRAINT é garantida através da criação de

um índice que não permite valores duplicados. Este índice, por padrão, é criado como um nonclustered
index. Porém, podemos definir que o índice seja criado como um clustered index, desde que não exista
outro clustered index já definido na tabela.
Podemos definir uma UNIQUE Constraint, no momento de criação de uma tabela. No exemplo a
seguir, estamos definindo o campo NúmMatrícula como chave primária e o campo NúmeroIdentidade
como sendo único, através de uma UNIQUE Constraint neste campo, ao criarmos a tabela Funcionários:
CREATE TABLE Funcionários

(
NúmMatrícula char(14) CONSTRAINT Num_Matr PRIMARY KEY,
NúmeroIdentidade char(14) CONSTRAINT Num_Iden UNIQUE NONCLUSTERED,
DataEntrada datetime NOT NULL,
DataAniversário datetime NOT NULL,
Nome char(50),
Cargo char(20),
Função char(50),
Salário float
)
Outra possibilidade é adicionarmos uma UNIQUE Constraint a uma tabela já existente, utilizando o
comando ALTER DATABASE. Vamos criar uma UNIQUE Constraint composta, a qual é associada aos
campos Nome, Cargo e Salário.
NOTA
Este exemplo não tem muito sentido prático. Iremos utilizá-lo apenas para exemplificar a sintaxe de criação de uma UNIQUE Constraint
composta.
ALTER TABLE Funcionários

ADD CONSTRAINT Constr_Comp UNIQUE NONCLUSTERED (Nome,Cargo,Salário)
Observe que neste caso especificamos que seja criado um nonclustered index.
FOREIGN KEY CONSTRAINTS

Utilizamos FOREIGN KEY constraints para implementar a integridade referencial no Banco de Dados.
Ao definirmos uma FOREIGN KEY associada a uma coluna (ou um conjunto de colunas), estamos
definindo esta coluna como uma chave estrangeira. A chave estrangeira representa o lado vários de um
relacionamento do tipo Um para Vários.
NOTA
É muito importante, eu diria até indispensável, que você tenha entendido todos os conceitos sobre o Modelo Relacional de dados, apresentados
no Capítulo 1. Se você tiver qualquer dúvida sobre um destes conceitos – chave primária, Chave estrangeira, relacionamentos, tipos de
relacionamentos e integridade referencial, por favor volte ao Capítulo 1 e revise estes conceitos, antes de seguir adiante.
Por exemplo, temos um relacionamento do tipo Um para Vários entre a tabela Fornecedores (lado Um)
e a tabela Produtos (lado Vários). Na tabela Fornecedores, o campo CódigoDoFornecedor é uma chave
primária. Na tabela Produtos, o campo CódigoDoFornecedor é uma chave estrangeira. O campo
CódigoDoFornecedor é o lado vários, na tabela Produtos, pois um mesmo fornecedor pode fornecer
vários produtos. Por exemplo, se um fornecedor fornecer 50 produtos diferentes, haverá 50 registros
na tabela Produtos, onde o campo CódigoDoFornecedor terá o código do respectivo fornecedor, nos
50 registros. Observe que, neste exemplo, o campo irá aparecer 50 vezes, ou genericamente várias
vezes. Sendo que as duas tabelas são relacionadas através de um relacionamento do tipo Um para
Vários, significando que Um fornecedor pode fornecer Vários produtos.
Uma chave estrangeira pode ser relacionada com um campo em que temos uma PRIMAY KEY Con-
straint ou uma UNIQUE Constraint.
Para que possamos estabelecer o relacionamento entre uma chave estrangeira e uma chave primária,
algumas regras devem ser observadas:
♦ O número de colunas da chave estrangeira e os tipos de dados especificados no comando

FOREIGN KEY devem coincidir com os especificados na cláusula REFERENCE. Porém, o nome
das colunas não precisa ser o mesmo. Veja a sintaxe do comando mais adiante e exemplos de
uso destes comandos.
♦ Quando criamos uma FOREIGN KEY Constraint não é criado, automaticamente, um índice.
Porém, na prática, pode ser útil a criação de um índice associado à chave estrangeira. Para
aprender sobre a criação e manutenção de índices consulte o Capítulo 4.
♦ Para modificar dados em uma tabela que possui uma constraint do tipo FOREIGN KEY, o usuário
deve ter permissões SELECT ou REFERENCE na tabela primária. Por exemplo, vamos considerar
o relacionamento entre as tabelas Categorias (lado Um) e Produtos (lado Vários), relacionadas
através do campo CódigoDaCategoria. Na tabela Categorias, o campo CódigoDaCategoria é uma
chave primária; já na tabela Produtos, o campo CódigoDaCategoria é uma Chave Estrangeira.
Para que o usuário possa alterar dados na tabela Produtos, ele precisa ter permissão SELECT ou
REFERENCE, na tabela Categorias, que é a tabela relacionada com produtos.
♦ Podemos criar uma referência entre duas colunas da mesma tabela. Neste caso, utilizamos
apenas a cláusula REFERENCES, sem a cláusula FOREIGN KEY.
Vamos pôr em prática toda esta teoria. Nos exemplos anteriores criamos uma tabela Clientes e uma
tabela Pedidos, com os campos indicados na Figura 9.7.
Figura 9.7 Tabelas Clientes e Pedidos, criadas nos exemplos anteriores.
Observe que o campo CPF existe nas duas tabelas e, na tabela Clientes, este campo é uma chave
primária – indicado por uma pequena chave amarela ao lado do campo. Vamos criar um relacionamento
entre estas duas tabelas. O relacionamento será do tipo Um (tabela Clientes) para Vários (tabela Pedidos).
Para definirmos este relacionamento, vamos criar uma FOREIGN KEY Constraint no campo CPF da
tabela Pedidos, sendo que esta FOREIGN KEY irá fazer referência (em bom português vai se relacionar
com) ao campo CPF da tabela Clientes.
Para criar uma FOREIGN KEY no campo CPF da tabela Pedidos, vamos executar o seguinte comando:
ALTER TABLE Pedidos

ADD CONSTRAINT Rel_Ped_Cli FOREIGN KEY(CPF)
REFERENCES Clientes(CPF)
Uma vez executado este comando, teremos criado um relacionamento entre as tabelas Clientes e Pedidos,
Figura 9.8 Relacionamento criado entre as tabelas Clientes e Pedidos.
Observe que definimos uma constraint do tipo FOREIGN KEY em uma tabela já existente. Porém
podemos definir este tipo de constraint no momento da criação da tabela.
Vamos supor que foi solicitada a criação de uma tabela chamada Dependentes. Um cliente poderá
autorizar um ou mais dependentes, para que façam compras em seu nome. Neste caso, teremos um
relacionamento do tipo Um para Vários entre a tabela Clientes e a tabela Dependentes. O campo que
irá relacionar as duas tabelas é o campo CPF. A tabela Clientes é o lado um do relacionamento e a
tabela Dependentes é o lado vários. Neste caso, a constraint do tipo FOREIGN KEY será criada na tabela
Dependentes. Como a tabela Dependentes ainda não existe, iremos criá-la e, durante a criação, especificar
uma FOREIGN Constraint no campo CPF, a qual referencia o campo CPF da tabela Clientes. A tabela
Dependentes terá os seguintes campos:
CPF Char(14) FOREIGN KEY relacionada com o campo CPF da tabela Clientes.
Nome Char(50)
Fone Char(25)
e_mail Char(50)
Para criar a tabela Dependentes e definir o relacionamento solicitado, devemos executar o seguinte
comando:
CREATE TABLE Dependentes

(
CPF Char(14) NOT NULL,
Nome Char(50) NOT NULL,
Fone Char(25) NOT NULL,
e_mail Char(50),
CONSTRAINT Rel_Cli_Dep FOREIGN KEY(CPF)
REFERENCES Clientes(CPF)
)
Após a execução deste comando teremos o relacionamento entre as tabelas Clientes e Dependentes já
definido. A Figura 9.9 mostra as tabelas Clientes, Pedidos e Dependentes e os respectivos
relacionamentos.
Figura 9.9 Mais um relacionamento criado: Clientes e Dependentes.
Vamos fazer alguns testes referentes à integridade referencial. Uma vez definido o relacionamento entre
as tabelas Clientes e Dependentes, o SQL Server 2005 não deve deixar que seja adicionado um registro na
tabela Dependentes, para um cliente que ainda não tenha sido cadastrado na tabela Clientes. Vamos
fazer o seguinte teste: tentaremos adicionar um dependente para o cliente com o CPF 999.999.999-99.
Acontece que este cliente não existe na tabela Clientes. Tente executar o seguinte comando:
INSERT INTO Dependentes (CPF,Nome,fone,e_mail)
VALUES (‘999.999.999-99’, ‘Faustino da Silva’, ‘2222222’,‘faustino@abc.com’)
O comando não será executado e a seguinte mensagem de erro será exibida:

INSERT statement conflicted with FOREIGN KEY constraint ‘Rel_Cli_Dep’.
The conflict occurred in database ‘PubsIntF’, table ‘Clientes’, column ‘CPF’.
Observe o seguinte trecho desta mensagem:

The conflict occurred in database ‘pubs’, table ‘Clientes’, column ‘CPF’.
Este trecho, embora não muito claramente, está nos dizendo que não existe o CPF 999.999.999-99, na
tabela Clientes, ou seja, que estamos tentando cadastrar um dependente para um cliente que ainda
não existe. Agora vamos alterar o comando anterior, substituindo o CPF inexistente pelo CPF de um
cliente cadastrado nos exercícios anteriores. Execute o seguinte comando:
INSERT INTO Dependentes (CPF,Nome,fone,e_mail)
VALUES (‘666.333.333-33’, ‘Faustino da Silva’, ‘2222222’,‘faustino@abc.com’)
Agora sim, o comando é executado com sucesso e um dependente é adicionado na tabela Dependentes.
Com este exemplo, podemos observar como o SQL Server gerencia, automaticamente, a integridade
referencial, uma vez definidos os relacionamentos. Quando trabalhamos com o SQL Server 2005, ou
qualquer outro Banco de Dados que segue o modelo Relacional, é de fundamental importância que
entendamos os conceitos apresentados no Capítulo 1 e aqui exemplificados. Sem o domínio destes
conceitos, iremos projetar Bancos de Dados com problemas, ou melhor, com muitos problemas. Muitas
vezes, estes problemas somente aparecem quando colocamos uma ou mais aplicações em produção.
Surgem desde consultas com desempenho “sofrível” até inconsistência e falta de integridade dos dados.
VERIFICAÇÃO DOS DADOS QUANDO UMA CONSTRAINT É ADICIONADA

Por padrão, o SQL Server 2005 verifica os dados existentes em uma tabela, quando uma constraint é
adicionada. Caso os dados não se enquadrem nas definições da constraint, esta não será criada. Por
exemplo, se você tentar definir uma constraint do tipo UNIQUE em uma coluna que contém valores
repetidos, o comando não será executado e uma mensagem de erro será exibida. Embora não seja
recomendado, esta verificação automática pode ser desabilitada. Somente podemos desabilitar a
verificação dos dados, quando uma Constraint é adicionada para constraints dos tipos CHECK e FOR-
EIGN KEY. A verificação sempre será feita para constraints dos tipos PRIMARY KEY e UNIQUE.
Para desabilitar a verificação, utilizamos a opção WITH NOCHECK, com o comando ALTER DATA-
BASE, conforme o exemplo a seguir:
ALTER TABLE Produtos
WITH NOCHECK
ADD CONSTRAINT Constr_1
CHECK (Preço >= 0)
Neste exemplo estamos adicionando uma constraint do tipo CHECK, definindo que o campo Preço,
da tabela Teste, deve ter um valor maior ou igual a zero. A cláusula WITH NOCHECK faz com que os
dados existentes na tabela Produtos não sejam verificados e, mesmo que existam valores negativos na
coluna Preço, a constraint será adicionada.
A única situação em que pode ser admissível a utilização da opção WITH NOCHECK seria em uma
situação em que temos um grande volume de dados, e estes já estão, comprovadamente, depurados.
Nesta situação, desabilitaríamos a verificação ao adicionar a constraint, para poupar tempo.
NOTA
A opção WITH NOCHECK não desabilita a verificação para os registros que são adicionados após a definição da constraint. Se formos
adicionar um registro que não atende a definição de uma ou mais constraints definidas na tabela, o registro não será inserido e uma
mensagem de erro será exibida.
DESABILITANDO E HABILITANDO NOVAMENTE CONSTRAINTS

Podemos desabilitar, temporariamente, uma ou mais constraints. Por exemplo, quando formos importar
um grande volume de dados, estando estes dados em um estado consistente, podemos desabilitar uma
ou mais constraints, para agilizar a importação dos dados. Uma vez encerrada a importação, voltamos
a habilitá-las. Somente podemos desabilitar constraints dos tipos CHECK e FOREIGN KEY.
Para desabilitar uma constraint utilizamos a cláusula NOCHECK CONSTRAINT nome_constraint, com
o comando ALTER DATABASE. Para reabilitar a constraint, utilizamos a cláusula CHECK CONSTRAINT
nome_constraint, com o comando ALTER DATABASE.
Para desabilitarmos a constraint FaixaFinanciamento, criada na tabela Clientes, utilizamos o seguinte comando:

NOCHECK CONSTRAINT FaixaFinanciamento
Para voltar a habilitar esta constraint, utilizamos o seguinte comando:

CHECK CONSTRAINT FaixaFinanciamento
EXCLUINDO CONSTRAINTS
Podemos excluir uma constraint, utilizando o comando ALTER TABLE. Utilizamos a seguinte sintaxe:

DROP CONSTRAINT nome_da_constraint
Por exemplo, para excluir uma constraint chamada Teste, da tabela Clientes, do Banco de Dados Vendas,
USE Vendas
DROP CONSTRAINT Teste
Exercício: Vamos propor um exercício, para que você possa revisar os diversos comandos vistos neste
item. O exercício será baseado no Banco de Dados PubsIntF, que criamos no início do capítulo.
Lembrando que este é uma cópia do Banco de Dados Pubs, importado a partir de uma instância do SQL
Server 2000. Vamos criar alguns relacionamentos neste Banco de Dados.
Das diversas tabelas que compõem este Banco de Dados, vamos nos concentrar nas quatro tabelas
mostradas na Figura 9.7.
Figura 9.10 Algumas tabelas do Banco de Dados PubsIntF.
Primeiro, vamos fazer uma análise sobre os relacionamentos que devem ser definidos para as tabelas
apresentadas, e depois partimos para a definição das constraints a serem implementadas em cada tabela.
Os seguintes campos serão definidos como chaves primárias:
♦ Campo au_id na tabela authors.
♦ Campo pub_id na tabela publishers.
♦ Campo title_id na tabela titles.
Definiremos os seguintes relacionamentos:
♦ Relacionamento do tipo Um para Vários entre as tabelas authors (lado Um) e a tabela titleauthor
(lado Vários), através do campo au_id.
♦ Relacionamento do tipo Um para Vários entre as tabelas titles (lado Um) e a tabela titleauthor
(lado Vários), através do campo title_id.
♦ Relacionamento do tipo Um para Vários entre as tabelas publishers (lado Um) e a tabela titles
(lado Vários), através do campo pub_id.
Então vamos à prática.
1. Abra o SQL Server Management Studio, navegue até o banco de dados PubsInf. Clique com o
botão direito do mouse no banco de dados PubsInf e, no menu de opções que é exibido, clique
em New Query. Será aberta a janela de execução de comandos T-SQL.
2. Torne PubsIntF o Banco de Dados atual, utilizando o seguinte comando:
USE PubsIntF
3. Para definir o campo au_id, da tabela authors, como uma chave primária, execute o seguinte
comando:
ALTER TABLE authors
ADD CONSTRAINT Prim_authors PRIMARY KEY CLUSTERED(au_id)
4. Para definir o campo pub_id, da tabela publishers, como uma chave primária, execute o seguinte
comando:
ALTER TABLE publishers
ADD CONSTRAINT Prim_publishers PRIMARY KEY CLUSTERED(pub_id)
5. Para definir o campo title_id, da tabela titles, como uma chave primária, execute o seguinte
comando:
ALTER TABLE titles
ADD CONSTRAINT Prim_titles PRIMARY KEY CLUSTERED(title_id)
Neste ponto, o nosso Banco de Dados já possui definidas três chaves primárias, conforme indicado na
Figura 9.11, na qual o campo chave primária é indicado pela pequena chave amarela.
Figura 9.11 Chaves primárias já definidas.
Agora vamos para a definição dos relacionamentos. Lembrando que um relacionamento é definido
através de uma constraint do tipo FOREIGN KEY.
6. Crie uma constraint do tipo FOREIGN KEY, associada com o campo au_id da tabela titleauthor,
a qual referencia o campo au_id da tabela authors. Para criar este relacionamento, utilize o
seguinte comando:
ALTER TABLE titleauthor
ADD CONSTRAINT FK_author FOREIGN KEY(au_id)
REFERENCES authors(au_id)
7. Crie uma constraint do tipo FOREIGN KEY, associada com o campo title_id da tabela titleauthor,
a qual referencia o campo title_id da tabela titles. Para criar este relacionamento, utilize o
seguinte comando:
ALTER TABLE titleauthor
ADD CONSTRAINT FK_title FOREIGN KEY(title_id)
REFERENCES titles(title_id)
8. Crie uma constraint do tipo FOREIGN KEY, associada com o campo pub_id da tabela titles, a
qual referencia o campo pub_id da tabela publishers. Para criar este relacionamento, utilize o
seguinte comando:
ALTER TABLE titles
ADD CONSTRAINT FK_pub FOREIGN KEY(pub_id)
REFERENCES publishers(pub_id)
Após executados estes comandos, os relacionamentos propostos terão sido criados, conforme indicado
na Figura 9.12:
Figura 9.12 Relacionamentos propostos já definidos.
Muito bem, com isso concluímos o exercício proposto.
KNOW-HOW EM: CONCEITOS E CRIAÇÃO DE

VIEWS NO SQL SERVER 2005
PRÉ-REQUISITOS
♦ Conhecer os comandos básicos da linguagem T-SQL.
♦ Saber utilizar a janela de execução de Comandos T-SQL e o SQL Server Management Studio.
♦ Conhecimento sobre relacionamentos e o modelo relacional de dados.
METODOLOGIA
♦ Apresentação dos procedimentos necessários para a criação de views com comandos T-SQL e usando o SQL Server Management Studio.
TÉCNICA
♦ Criação e teste de views, utilizando comandos T-SQL e o SQL Server Management Studio.
INTRODUÇÃO
Quando executamos um comando T-SQL na janela de execução de comandos, este é processado e
uma mensagem é exibida. Por exemplo, quando executamos um comando CREATE TABLE, uma
tabela é criada no Banco de Dados atual e uma mensagem, dizendo que o comando foi executado
com sucesso, é emitida.
Também podemos executar consultas, como por exemplo:
SELECT * FROM Orders WHERE ShipCountry = ‘Brazil’
O comando é executado e será retornada uma listagem com todos os registros da tabela Orders, em que
o campo ShipCountry for igual a Brazil. Se fecharmos a janela de execução de comandos T-SQL e
abrirmos novamente, teremos que digitar o comando mais um vez para executá-lo. Este tipo de consulta
é conhecido com “Consulta Ad-hoc”. Alguns autores traduzem a expressão “Ad-hoc” como sendo sob
demanda. A mim, parece uma tradução aceitável, uma vez que a consulta é executada no momento
em que é solicitada; depois, ao fechar a janela de execução de comando T-SQL, os comandos e o
resultado são descartados.
Porém, para aplicativos que executam repetidamente um determinado conjunto de consultas este
método de consultas Ad-hoc não é o mais adequado. No SQL Server 2005, temos a opção de salvar uma
instrução SQL que retorna dados. A instrução é salva e um nome é atribuído à instrução (ou ao conjunto
de instruções). Com isso, podemos definir view de uma maneira bastante simples:
“View é uma instrução T-SQL que retorna dados e é salva no Banco de Dados com um nome, ou
seja, passa a ser um objeto do Banco de Dados. Quando uma view é executada, esta retorna
um conjunto de dados no formato de uma tabela. Uma view pode retornar dados de uma ou
mais tabelas.”
Para criar uma view, utilizamos o comando CREATE VIEW. Vamos criar uma view, chamada Ped_USA,
a qual seleciona os registros da tabela Pedidos em que o campo ShipCountry é igual a USA.
USE Northwind
GO
CREATE VIEW Ped_USA
AS
SELECT * FROM ORDERS WHERE ShipCountry = ‘USA’
Este exemplo é baseado no banco de dados Northwind. Este banco de dados é fornecido como exemplo, no SQL Server 2000. Ele não é
NOTA
instalado com o SQL Server 2005. Mas você pode utilizar o DTS Import/Export Wizard, para importar o banco de dados Northwind, de uma
instância do SQL Server 2000, para uma instância do SQL Server 2005. Para um passo-a-passo sobre como importar o banco de dados
Northwind, consulte o Anexo, no final deste livro.
Agora, ao executarmos a view, basta darmos um SELECT * Nome_da_view. A view será executada e
todos os registros, por ela selecionados, serão retornados. No caso, serão retornados os pedidos onde o
campo ShipCountry = USA. Para executar a view Ped_USA, execute o seguinte comando:
SELECT * FROM Ped_USA
Serão retornados os resultados indicados na Figura 9.13.
Figura 9.13 Resultado da execução da view Ped_USA.
TIPOS DE VIEWS QUANTO AO CONJUNTO DE DADOS RETORNADOS

Podemos ter diversos tipos de views, dependendo do conjunto de dados retornados. Uma view que
retorna apenas algumas colunas de uma tabela é conhecida como “Sub-set of table columns”. Podemos
utilizar este tipo de view para fazer com que o usuário somente receba o conjunto de dados que lhe
interessa. Por exemplo, uma consulta feita por um vendedor pode retornar apenas a descrição do
produto, o preço, o valor do frete e o prazo de entrega. Já uma consulta feita pelo responsável pelo
estoque pode retornar somente o código do produto e o nível de estoque do produto, bem como o
nível mínimo de estoque aceitável.
Uma view, que retorna apenas um subconjunto das linhas de uma tabela, é conhecida como “Subset of
table rows”. É o caso típico da consulta onde é utilizada a cláusula WHERE, para filtrar o conjunto de dados.
Também podemos criar views que retornam dados de diversas tabelas, através de uma ou mais cláusulas
Join. Além disso, também podemos utilizar as chamadas funções de agregação como por exemplo
SUM para calcular a soma em um determinado campo ou AVG para calcular a média.
Também podemos definir uma cláusula SELECT dentro de outra, o que é mais conhecido como
SUBCONSULTA. Aprenderemos a criar subconsultas, bem como os demais tipos de views mais adiante,
neste item. Quando trabalhamos com subconsultas, devemos considerar, seriamente, questões
relacionadas ao desempenho.
POR QUE UTILIZAR VIEWS?

Existem vários motivos que justificam a utilização de views. Vamos falar sobre os principais.
Com a utilização de views, podemos ocultar a complexidade no acesso aos dados. Se um usuário ou
aplicação precisa de acesso a um conjunto de dados, o qual é obtido a partir de várias tabelas, podemos
simplificar este acesso, criando uma view que consolida e retorna os dados necessários. Depois é só
fazer com que o usuário ou aplicação acesse e execute esta view.
Simplifica a atribuição de permissões. Podemos definir permissões na view, o que simplifica bastante o
gerenciamento de permissões, uma vez que temos que gerenciar um número menor de objetos e
permissões. Uma Banco de Dados normalizado apresenta um grande número de tabelas. Com isso, as
consultas executadas pelos usuários precisam acessar dados de diversas tabelas. Este meio-campo pode
ser feito, com grandes vantagens, com a criação de views.
O desenvolvimento e manutenção de aplicações também fica simplificado. Se existirem alterações na

estrutura de uma ou mais tabelas e a aplicação tiver sido desenvolvida para acessar os dados diretamente
das tabelas, a aplicação terá que ser reescrita quando fizermos alterações nas tabelas. Podemos evitar
este problema criando uma view e fazendo com que a aplicação acesse a view. Se houver alterações nas
tabelas, alteramos a view para que o mesmo conjunto de dados seja retornado, evitando, com isso, que
a aplicação tenha que ser alterada.
NOTA
Existem outras técnicas que simplificam a manutenção de aplicações. Falaremos mais sobre estas técnicas nos Capítulos 10 e 11.
LIMITAÇÕES NA CRIAÇÃO DE VIEWS

Ao criarmos views, devemos considerar as seguintes limitações:
♦ Somente podemos criar uma view no Banco de Dados atual, embora esta possa acessar dados
de tabelas de outros Bancos de Dados ou até mesmo de outros servidores, quer seja outras
instâncias do SQL Server ou os chamados linked servers.
♦ Uma view pode ter, no máximo, 1024 colunas.
♦ O usuário, que está criando a view, deve ter permissão de acesso a todas as colunas incluídas na
view, caso contrário o usuário não conseguirá criá-la.
♦ Podemos “aninhar” views, isto é, uma view pode referenciar outra, até um nível de 32 views
aninhadas.
Uma vez apresentada a teoria, vamos à prática. Seguindo a metodologia utilizada até o momento,
aprenderemos a criar views utilizando as seguintes ferramentas:
♦ Janela de execução de comandos T-SQL.
CRIANDO VIEWS COM O SQL SERVER MANAGEMENT STUDIO

Este é um ponto em que tenho que ser sincero com o amigo leitor. Na minha modesta opinião, era
bem mais simples criar uma view no SQL Server 2000 do que no SQL Server 2005. No SQL Server 2000,
tínhamos um assistente, que nos conduzia, passo a passo, na criação de views. Era extremamente
simples de usar e muito semelhante à interface de criação de consultas do Access. Uma verdadeira
barbada. Já com o SQL Server 2005 simplesmente não tem esta opção. Para criar um view em um
banco de dados do SQL Server 2005, temos que digitar, na mão, o comando T-SQL para a criação da
view. Sinceramente, não consegui entender o que a Microsoft tentou fazer nesta área, pois não ajudou
e nem facilitou, em nada. Bem pelo contrário, atrapalha bastante para quem está iniciando seus estudos
sobre o SQL Server.
Figura 9.14 O Diagrama Entidade x Relacionamentos do banco de dados NorthWind.mdb.
Como não temos mais o bom e velho assistente, no formato parecido com o que tínhamos no Access,
não adianta chorar. O que temos que fazer é procurar algo de bom nesta mudança. O que eu encontrei
de bom, para passar para os amigos leitores, é fazermos um estudo mais detalhado dos comandos da
linguagem T-SQL, comandos utilizados para a criação de views, de tal forma que possamos aprimorar
mais ainda os nossos conhecimentos da linguagem T-SQL. Depois, aplicaremos estes conhecimentos
para a criação de views. Basicamente é isso.
No Capítulo 1 você aprendeu os fundamentos básicos da linguagem T-SQL. Seria importante que,
neste momento, você voltasse ao Capítulo 1 e revisasse os pontos onde você tem dúvidas sobre os
tópicos que foram apresentados. Neste tópico sobre a criação de views, eu utilizarei o que foi apresentado
no Capítulo 1 e adicionarei tópicos novos. Os novos tópicos serão apresentados através de exemplos.
Nos exemplos eu irei propor uma consulta, apresentarei os comandos para a criação da view e depois
irei explicar, detalhadamente, os comandos utilizados.
Para os exemplos deste tópico, você deve criar um banco de dados chamado NwindAccess. Este banco de dados será criado na instância
NOTA
SERVIDOR\SQL2005 e terá um único arquivo primário, com tamanho inicial de 100 MB e autocrescimento permitido em incrementos de 10%.
Este banco de dados terá um único arquivo de log, com tamanho inicial de 50 MB e com autocrescimento permitido em incrementos de 10%. Em
caso de dúvidas sobre como criar um banco de dados, consulte o Capítulo 3, onde apresentei exemplos práticos, passo a passo, sobre a criação de
banco de dados. Após criar o banco de dados NwindAccess, utlize o DTS Import/Export Wizard, para importar todas as tabelas do banco de dados
Northwind.mdb, do Access, para dentro do banco de dados NwindAccess, do SQL Server 2005. O banco de dados NorthWind.mdb é instalado
juntamente com o Microsoft Access, desde as versões antigas até a versão mais atual. Os exemplos de views, que criaremos, serão baseadas neste
banco de dados. Na Figura 9.14, apresento o diagrama Entidades x Relacionamentos, do banco de dados Northwind.mdb.
CRIANDO VIEWS COM O SQL SERVER MANAGEMENT STUDIO

Neste item vamos fazer um exemplo prático, de criação de view com o SQL Server Management Stu-
dio. Vamos iniciar com uma view bem simples, apenas para ilustrar os passos para a criação de uma
view, usando o SQL Server Management Studio. Logo em seguida, mostrarei como acessar as propriedades
de uma view, para alterá-la. Também mostrarei como executar uma view, para conferir se esta está
retornando os resultados esperados. O nosso primeiro exemplo será a criação de uma view, que lista
alguns campos da tabela Clientes. Feito este primeiro exemplo, bastante simples, iremos apresentar
uma série de situações práticas, e mostraremos como resolvê-las, através da utilização de views. Farei
diversos exemplos, porque este é um tópico muito importante, tanto para o administrador do banco
de dados, quanto para a equipe de desenvolvimento.
Exemplo prático 01: Criar uma view chamada ListaContatos, no banco de dados NwindAccess, da
instância SERVIDOR\SQL2005. Esta view deverá listar somente os campos NomeDaEmpresa,
NomeDoContato, País, Cidade e Telefone, da tabela Clientes. Classificar a listagem em ordem alfabética
do campo Nome da Empresa. Executar a view para observar se os resultados retornados são os esperados.
Para resolver o exemplo proposto, siga os passos indicados a seguir:
1. Abra o SQL Server Management Studio, navegue até o banco de dados PubsInf.
3. Clique no sinal de + ao lado da opção Databases.
4. Clique no sinal de + ao lado do banco de dados NwindAccess (veja as orientações anteriores,
para criação deste banco de dados e importação das tabelas do banco de dados
NorthWind.mdb, do Access).
5. Dentre as opções que são exibidas, observe que temos uma opção chamada views. Esta é a
opção que utilizaremos para criar novas views. Clique com o botão direito do mouse em views
e, no menu de opções que é exibido, clique em New view. Será exibida a janela view – New,
indicada na Figura 9.15.
Figura 9.15 A janela para criação de uma nova view.
6. No campo view name você informa o nome da view. Digite ListaContatos. O campo Data-
base name já vem preenchido com NwindAccess, que é o banco de dados onde a view será
criada. Na lista Schema, você define qual schema será o dono da view. Por padrão é
selecionado o schema dbo. Para mais detalhes sobre segurança no SQL Server 2005 e schemas,
7. Abaixo da lista Schemas, está disponível uma série de opções que podem ser habilitadas para a
view que está sendo criada. A principal opção deste grupo é a opção Encrypt text. Se esta opção
for marcada, os comandos que formam a view serão gravados no banco de dados, na forma
criptografada. É importante não fazer confusão neste ponto. O que será criptografado são os
comandos que formam a view e não os dados, por ela retornados.
8. A view é criada na parte de baixo. Criar a view é, basicamente, digitar o comando T-SQL que será
executado, quando a view for executada. Observe que a parte inicial do comando, que é a parte
que cria a view, já é automaticamente criada. No nosso exemplo, temos o seguinte comando:
CREATE VIEW [dbo].[ListaContatos] AS
9. O nosso trabalho, agora, é digitar, na linha abaixo do AS, o restante do comando. No nosso
exemplo, será uma instrução SELECT, que retorna somente os campos NomeDaEmpresa,
NomeDoContato, País, Cidade e Telefone, da tabela Clientes. E classifica a listagem em ordem
alfabética do campo Nome da Empresa.
10. Complete o comando com a seguinte instrução SELECT:

SELECT Clientes.NomeDaEmpresa, Clientes.NomeDoContato, Clientes.País, Clientes.Cidade,
Clientes.Telefone FROM Clientes
11. Você deve estar se perguntando se eu não esqueci a cláusula ORDER BY NomeDaEmpresa, para fazer
a ordenação pelo nome da empresa. Acontece que não é permitido o uso da cláusula Order By em
views. Por isso, para fazer a ordenação, teremos que usar a cláusula Order By, na hora de executar a
view, mais adiante A janela de criação da view deve estar conforme indicado na Figura 9.16.
Figura 9.16 Comando para a criação da view.
12. Antes de salvar a view, você pode verificar se existe algum erro de sintaxe. Clique com o botão
direito do mouse na área em branco, abaixo da última linha da instrução SELECT. No menu de
opções que é exibido, dê um clique em Check Sintax. Se a instrução SQL estiver correta, será
exibida uma mensagem informando que tudo está OK. Clique em OK para fechar esta mensagem.
13. Pressione Ctrl+S para salvar a view.
14. Para fechar a janela de criação da view, clique com o botão direito do mouse na área em
branco, abaixo da última linha da instrução SELECT. No menu de opções que é exibido, dê um
clique em Close.
15. Agora a view ListaContatos foi criada.
16. Clique no sinal de +, ao lado da opção views, abaixo do banco de dados NwindAccess. Clique na
opção views. Se a view ListaContatos ainda não estiver sendo exibida, pressione a tecla F5 para
atualizar a listagem. A view Lista contatos já deverá estar sendo exibida, abaixo da opção views.
17. Caso você precise alterar a view, futuramente, é só clicar com o botão direito do mouse na view
e, no menu de opções que é exibido, clique em Modify view. A janela com as configurações da
view será exibida e você poderá alterá-las. Faça as alterações desejadas, salve pressionando
Ctrl+S e feche a janela de configurações da view.
18. Agora vamos a etapa final do exemplo proposto. Vamos executar a view ListaContatos e ordenar
os resultados em ordem alfabética do campo NomeDaEmpresa.
19. Clique com o botão direito do mouse no banco de dados NwindAccess e, no menu de opções
que é exibido, clique em New Query. Será aberta a janela de execução de comandos T-SQL. Para
executar a view ListaContatos e ordenar os resultados em ordem alfabética do campo
NomeDaEmpresa, execute o seguinte comando:
SELECT * FROM ListaContatos Order By NomedaEmpresa
20. A view ListaContatos será executada e os resultados ordenados pelo campo NomeDaEmpresa,
conforme exemplificado na Figura 9.17.
Figura 9.17 Executando a view ListaContatos.
Muito bem, com isso concluímos o nosso primeiro exemplo. Agora já sabemos como criar uma view,
como alterá-la e como executar uma view. Agora vamos estudar mais alguns exemplos práticos, os
quais serão solucionados com o uso de views.
Nos próximos exemplos, não irei repetir, cada vez, todos os passos necessários para criar, alterar e executar
uma view, uma vez que todos estes passos já foram descritos neste primeiro exemplo. Nos próximos
exemplos, vou me concentrar em exemplos práticos, os quais são resolvidos através de views. Farei os
exemplos passo a passo, mostrando quais os comandos T-SQL a serem utilizados em cada etapa, até
chegarmos à solução pretendida. Estude com bastante atenção estes exemplos, pois eles serão de grande
utilidade na sua vida prática, como administrador e desenvolvedor do SQL Server 2005.
EXEMPLO PRÁTICO 01: USANDO VIEWS PARA CRIAR CAMPOS CALCULADOS E TOTALIZAÇÕES
No Capítulo 1, eu apresentei os fundamentos do Modelo Relacional de Dados, que é o modelo utilizado
pelo SQL Server 2005. Dentre outras, apresentei duas regras fundamentais:
♦ Cada assunto em uma tabela. Não se misturam assuntos, na mesma tabela.
♦ Não se armazenam valores calculados, a não ser em casos específicos, de bancos de dados
utilizados para dados consolidados, para suporte a sistemas de decisão ou Data Mining.
Neste nosso primeiro exemplo, vamos analisar um caso que se encaixa bem com estas duas regras
básicas. Vamos continuar trabalhando com o banco de dados NwindAccess, o qual você importou para
o SQL Server 2005, no início deste capítulo. Neste banco de dados, temos uma tabela Pedidos, na qual
estão armazenadas as informações do cabeçalho do pedido, tais como: Número do Pedido, Código do
Cliente, Código do Funcionário, Data do Pedido, Valor do frete e assim por diante. Neste banco de
dados, foi criada uma segunda tabela, chamada Detalhes do Pedido.
Figura 9.18 As tabelas Pedidos e Detalhes do Pedido.
Esta tabela contém os itens individuais, de cada pedido. Esta separação foi necessária, porque um
mesmo pedido pode ter vários itens. Se não tivesse sido feita esta separação, as informações do cabeçalho
do pedido teriam que ser repetidas tantas vezes quantos fossem os itens do pedido. Vimos que esta
repetição vai contra todos os princípios do Modelo Relacional e só causaria problemas. Por isso a
separação em duas tabelas. Na Figura 9.18, temos uma visão geral das tabelas Pedidos e Detalhes do
Pedido, os campos de cada tabela e o relacionamento que existe entre elas, através do campo
NúmeroDoPedido.
Muito bem, o nosso primeiro problema prático é diretamente relacionado com as tabelas Pedidos e
Detalhes do Pedido. Note que não temos um campo que calcula o valor total para cada pedido. Este
será justamente o nosso trabalho, neste exemplo. Vamos criar uma view que nos dê o resultado indicado
na Figura 9.19.
Figura 9.19 O resultado que deve ser retornado pela nossa view.
Neste exemplo, será exibido o número do pedido, a data do pedido, o nome do cliente e o valor total
para o pedido. Observe que não temos armazenado, nas tabelas, o valor total para o pedido. Mas, por
outro lado, temos todas as informações necessárias para calcular este total. Se fôssemos calcular,
manualmente, o total do pedido, o que teríamos que fazer?
Muito simples. Primeiro devemos calcular o valor individual de cada item do pedido. Depois, somar
os valores de todos os itens do pedido. Para o cálculo do valor de cada item, vamos usar uma fórmula
bem simples, na qual utilizaremos o PreçoUnitário do item, a quantidade e o percentual de desconto.
A fórmula que utilizaremos, para o total de cada item, individualmente, será a seguinte:
([Quantidade]*[PreçoUnitário])*(1-[Desconto])
Bem, a questão que fica é: Como chegar a este resultado, usando uma view, no SQL Server 2005? A
resposta está logo a seguir. Continue acompanhando.
Exemplo prático: Criar uma view que retorne os resultados indicados na Figura 9.19. Para criar esta
view, siga os passos indicados a seguir:
1. Abra o SQL Server Management Studio e navegue até o banco de dados NwindAccess.
2. Clique no sinal de + ao lado do banco de dados NwindAccess.
3. Clique com o botão direito do mouse na opção views, abaixo de NwindAccess e, no menu de
opções que é exibido, clique em New View.
4. Será exibida a janela para criação de uma nova view, a qual você aprendeu a utilizar no exemplo
anterior. No campo view name, digite Con - Total por Pedido.
5. Na parte do comando da view, após o AS é que vem o comando T-SQL para a criação da view.
Vamos iniciar bem “light”, onde criaremos um comando que exibe os campos NúmeroDoPedido
da tabela Pedidos, DataDoPedido da tabela Pedidos e NomeDoDestinatário da tabela Pedidos.
Para criar esta view inicial, digite o seguinte comando, na linha abaixo do AS:
SELECT Pedidos.NúmeroDoPedido, Pedidos.DataDoPedido, Pedidos.NomeDoDestinatário FROM
Pedidos
6. Pressione Ctrl+S para salvar a view e feche a janela de criação da view.
7. Abra a janela de execução de comandos T-SQL e execute o seguinte comando:
SELECT * FROM [Con - Total por Pedido]
NOTA
Observe que o nome da view vem entre colchetes. Isso é necessário porque existem espaços em branco no nome da view.
8. Você deverá obter os resultados indicados na Figura 9.20.
9. Muito bem. Agora vamos começar a alterar nossa view. O primeiro passo será adicionar também
campos da tabela Detalhes do Pedido. Com isso, veremos como fica o comando para criar uma
view que retorna dados de duas ou mais tabelas relacionadas.
10. Localize a view Con - Total por Pedido, clique com o botão direito do mouse na view e, no
menu de opções que é exibido, clique em Delete. Será exibida uma janela solicitando
confirmação. Clique em OK para confirmar a exclusão da view. É preciso excluir a view e criá-
la novamente, pois vamos adicionar novas colunas na view.
11. Clique com o botão direito do mouse na opção views, abaixo de NwindAccess e, no menu de
12. Será exibida a janela para criação de uma nova view. No campo view name, digite Con - Total
por Pedido.
Vamos agora usar um comando que, além dos campos que já existiam na versão anterior da
view, irá adicionar também os campos PreçoUnitário, Quantidade e Desconto, da tabela detalhes
do pedido. O objetivo desta etapa é mostrar como representar, através de comandos T-SQL, o
relacionamento entre duas ou mais tabelas. Para criar esta view, digite o seguinte comando, na
linha abaixo do AS:
SELECT Pedidos.NúmeroDoPedido, Pedidos.DataDoPedido, Pedidos.NomeDoDestinatário,
[Detalhes do Pedido].PreçoUnitário, [Detalhes do Pedido].Quantidade,
[Detalhes do Pedido].Desconto FROM Pedidos
INNER JOIN [Detalhes do Pedido] ON Pedidos.NúmeroDoPedido = [Detalhes do Pedido].NúmeroDoPedido
O detalhe realmente importante, nesta versão da view, é o seguinte trecho do comando:

INNER JOIN [Detalhes do Pedido] ON Pedidos.NúmeroDoPedido = [Detalhes do
Pedido].NúmeroDoPedido
Este é o trecho que faz o relacionamento entre as tabelas Pedidos e Detalhes do pedido, através do
campo NúmeroDoPedido. O nome da tabela Detalhes do Pedido vem sempre entre colchetes, porque
há espaços no nome da tabela.

NOTA
16. Você deverá obter os resultados indicados na Figura 9.20:
Figura 9.20 Resultados da versão 2.0 da nossa view.
Observe que já são exibidos os campos PreçoUnitário, Quantidade e Desconto, da tabela Detalhes do
Pedido. Ainda estamos longe do resultado final desejado, mas estamos caminhando na direção certa.
Um detalhe interessante a observar é que, na listagem, são exibidas várias linhas para cada um dos
pedidos. Por exemplo, para o primeiro pedido – 10248 – são exibidas três linhas. Isso ocorre porque
este pedido tem três itens. Cada linha tem informação de um dos itens do pedido.
Muito bem. Qual o próximo passo?
Agora vamos alterar novamente o comando T-SQL. Vamos retirar os campos PreçoUnitário, Quantidade
e Desconto. No lugar destes três campos, vamos criar um único campo calculado, o qual nos fornecerá
o total por item de cada pedido. Vamos ao trabalho então.
17. Localize a view Con – Total por Pedido, clique com o botão direito do mouse na view e, no
la novamente, pois vamos retirar colunas e adicionar uma nova coluna (calculada) na view.
18. Clique com o botão direito do mouse na opção Views abaixo de NwindAccess e, no menu de
por Pedido.
Vamos agora usar um comando que, além dos campos NúmeroDoPedido, DataDoPedido e
NomeDoDestinatário, da tabela Pedidos, exiba também um campo calculado, que chamaremos
de TotalDoPedido. O valor deste campo será calculado na fórmula que indicamos anteriormente:
([Quantidade]*[PreçoUnitário])*(1-[Desconto]). Para criar a versão 3.0 da nossa view, digite o
seguinte comando, na linha abaixo do AS:

([Quantidade]*[PreçoUnitário])*(1-[Desconto]) AS TotalDoPedido
FROM Pedidos INNER JOIN [Detalhes do Pedido] ON Pedidos.NúmeroDoPedido = [Detalhes do
A novidade, nesta versão da view, é o seguinte trecho do comando:

([Quantidade]*[PreçoUnitário])*(1-[Desconto]) AS TotalDoPedido
Este é o trecho onde criamos um campo calculado. O campo calculado vem junto com os demais
campos. Observe que, logo após o campo NomeDoDestinatário, coloco a fórmula de cálculo e depois
da fórmula, uma cláusula AS para dar nome ao campo calculado. Neste exemplo, a fórmula é
([Quantidade]*[PreçoUnitário])*(1-[Desconto]) e o nome atribuído a esta coluna é TotalDoPedido.

Figura 9.21 Resultados da versão 3.0 da nossa view.
Observe que agora, com a versão 3.0 da nossa view, já estamos bem mais próximos do resultado final
proposto. Ainda não estamos lá, mas falta muito pouco. Observe que já é exibido o total de cada item
de cada pedido. Porém, ainda não está sendo totalizado por pedido. Por exemplo, o pedido 10248 tem
três itens. Estão sendo exibidas três linhas para este pedido, uma para cada item. Em cada linha é
exibido o total do item. Nós temos que fazer com que o SQL Server 2005 “junte todos os itens do
mesmo pedido em uma única linha e, ao invés do total por item, some os valores dos itens do pedido,
exibindo o total do pedido”. Conforme você verá, logo a seguir, é bastante simples fazer esta totalização.
Vamos continuar modificando a nossa view. Agora iremos criar a versão 4.0, que será a nossa versão
final. Então mãos à obra.
24. Localize a view Con - Total por Pedido, clique com o botão direito do mouse na view e, no
la novamente, pois vamos fazer alterações.
opções que é exibido, clique em New view.
por Pedido.
Vamos criar um comando que, além de retornar os resultados da versão 3.0 da nossa view, faça
também a totalização por pedido. Para criar a versão 4.0 da nossa view, digite o seguinte
comando, na linha abaixo do AS:
Sum(([Quantidade]*[PreçoUnitário])*(1-[Desconto])) AS TotalDoPedido
FROM Pedidos INNER JOIN [Detalhes do Pedido] ON Pedidos.NúmeroDoPedido = [Detalhes do
GROUP BY Pedidos.NúmeroDoPedido, Pedidos.DataDoPedido, Pedidos.NomeDoDestinatário;
Aqui temos diversas novidades a serem consideradas. Vamos comentá-las por partes. A primeira novidade
é o uso da função SUM, para fazer a soma do campo Calculado TotalDoPedido:
Sum(([Quantidade]*[PreçoUnitário])*(1-[Desconto])) AS TotalDoPedido
Porém temos que orientar o SQL Server em como agrupar as linhas. Pois é dentro de cada agrupamento
que a soma será efetuada. No nosso exemplo, vamos agrupar por pedidos. Dentro de um mesmo
pedido, os campos NúmeroDoPedido, DataDoPedido e NomeDoDestinatário são iguais, para todos os
itens de um pedido. Com isso, vamos pedir que estes itens sejam agrupados em um único e que os
diferentes valores de cada item sejam somados. Ou seja, o resultado prático é obter cada pedido listado
uma única vez com o respectivo total. Para fazer este agrupamento, utilizamos a cláusula GROUP BY,
conforme trecho de código a seguir:
GROUP BY Pedidos.NúmeroDoPedido, Pedidos.DataDoPedido, Pedidos.NomeDoDestinatário
Observe que utilizamos a cláusula GROUP BY nos três campos da tabela Pedidos, ou seja, justamente
os campos que são iguais, para todos os itens de um mesmo pedido.

SELECT * FROM [Con - Total por Pedido] ORDER BY NúmeroDoPedido
Observe que agora cada pedido aparece uma única vez e, na última coluna, é exibido o total para o
pedido, total este que nada mais é do que a soma dos itens do pedido.
31. Muito bem, com isso concluímos o exercício proposto, ou seja, criar uma view que retornasse
o total por pedido. Vimos que, basicamente, criar um view, é saber criar o comando T-SQL para
retornar o resultado desejado. Por isso que venho insistindo, ao longo de todo o capítulo, na
importância de conhecer os comandos T-SQL. Pois tudo no SQL Server 2005 se resume a
comandos T-SQL. Mesmo quando você está usando a interface gráfica, é apenas uma interface
mais amigável, que o está ajudando a criar um comando T-SQL o qual será executado. Com
comandos T-SQL você cria e modifica bancos de dados, cria tabelas, views, triggers, stored
procedures, configura a segurança e a replicação, enfim, faz tudo no SQL Server 2005.
A seguir você aprenderá um pouco mais sobre as views chamadas de Referência Cruzada, as quais usam
as cláusulas TRANSFORM e PIVOT. Você verá que é possível fazer pequenas maravilhas com estas
cláusulas.
Figura 9.22 Resultados da versão 4.0 da nossa view – versão final.
Muito bem. Para não perdermos o ritmo, vamos a mais alguns exemplos.
EXEMPLO PRÁTICO 02: USANDO VIEWS

PARA CRIAR CAMPOS CALCULADOS E TOTALIZAÇÕES
Neste nosso segundo exemplo, vamos analisar um caso que se encaixa bem no uso das diversas opções
da linguagem T-SQL, para a criação de listagens personalizadas, com valores calculados. Vamos continuar
trabalhando com o banco de dados NwindAccess, o qual você importou para o SQL Server 2005, no
início deste capítulo. Neste banco de dados, temos uma tabela Pedidos, na qual estão armazenadas as
informações do cabeçalho do pedido, tais como: Número do Pedido, Código do Cliente, Código do
Funcionário, Data do Pedido, Valor do frete e assim por diante. Neste banco de dados, foi criada uma
segunda tabela, chamada Detalhes do Pedido. Esta tabela contém os itens individuais, de cada pedido,
conforme já descrito anteriormente. Para este segundo exemplo, também vamos utilizar dados da
tabela Funcionários. Na Figura 9.23, temos uma visão geral das tabelas Pedidos, Detalhes do Pedido e
Funcionários, os campos de cada tabela e o relacionamento que existe entre elas.
Muito bem, o nosso segundo problema prático é diretamente relacionado com as tabelas Pedidos,
Detalhes do pedido e Funcionários. O nosso objetivo é listar o total de vendas por PaísDeDestino e,
dentro de cada PaísDeDestino, por funcionário. Novamente teremos que criar um campo calculado,
para ter o total por cada item de cada pedido. Depois teremos que agrupar por PaísDeDestino e, dentro
do país, agrupar por Funcionário. Este será justamente o nosso trabalho, neste exemplo. Vamos criar
uma view que nos dê o resultado indicado na Figura 9.24.
Figura 9.23 As tabelas Pedidos, Detalhes do Pedido e Funcionários.
Neste exemplo, serão exibidos os totais por país e, dentro do país, por funcionário. Por exemplo, a
primeira linha exibe o total de vendas feitas para clientes da Alemanha, pelo funcionário Andrew; a
segunda linha apresenta o total de vendas para clientes da Alemanha, feitas pelo funcionário Anne e
assim por diante.
Bem, a questão que fica é: Como chegar a este resultado, usando uma view, no SQL Server 2005? A
resposta está logo a seguir. Continue acompanhando.
anterior. No campo view name, digite Con - Total por País e Funcionario.
5. Na parte do comando da view, após o AS, é que vem o comando T-SQL para a criação da Para
esta view. Digite o seguinte comando, na linha abaixo do AS:
SELECT Pedidos.PaísDeDestino, Funcionários.Nome, Sum(([Quantidade]*[PreçoUnitário])*(1-
[Desconto])) AS TotalDeVendas
FROM
(Funcionários INNER JOIN Pedidos ON Funcionários.CódigoDoFuncionário =
Pedidos.CódigoDoFuncionário) INNER JOIN [Detalhes do Pedido] ON Pedidos.NúmeroDoPedido =
[Detalhes do Pedido].NúmeroDoPedido
GROUP BY Pedidos.PaísDeDestino, Funcionários.Nome
Este comando não tem grandes novidades em relação ao que já aprendemos. Mas vale a pena comentar
os trechos utilizados neste código.
O primeiro trecho a ser analisado é o seguinte:

SELECT Pedidos.PaísDeDestino, Funcionários.Nome, Sum(([Quantidade]*[PreçoUnitário])*(1-
[Desconto])) AS TotalDeVendas
Este trecho define os campos que serão retornados. No nosso exemplo são retornados os campos
PaísDeDestino da tabela Pedidos, Nome da tabela Funcionários e um campo calculado, o qual chamamos
de total de vendas. A fórmula de cálculo é a seguinte: (([Quantidade]*[PreçoUnitário])*(1-[Desconto]). Você
pode estar se perguntando: “Mas e a função SUM, o que está fazendo neste comando?”. Muito bem, para
entender o que a função SUM está fazendo, temos que nos deslocar para a parte final da instrução SQL:
Esta parte orienta o SQL Server a agrupar os resultados por país e, dentro do país, por Nome do funcionário.
A ordem é definida pela posição dos campos. Como primeiro vem o campo PaísDeDestino, primeiro é
feito o agrupamento por país e, dentro do país, por funcionários. Se invertêssemos esta ordem, seria feito
primeiro o agrupamento por puncionário e, dentro das vendas de um mesmo funcionário, por país.
Bem, agrupamos por país e, dentro do país, por funcionário. E o que devemos fazer para obter os totais de
vendas, dentro destes agrupamentos? Somar os valores do campo TotalDeVendas. É exatamente por isso
que foi utilizada a função SUM. Agora você já sabe o porquê de utilizar o SUM.
Um detalhe importante que você deve ter observado (ou talvez não) é que não fizemos a ordenação
dos resultados, no comando de criação da view. Ou seja, não usamos uma cláusula ORDER BY para
ordenar por país e depois pelo nome. Isso porque não é permitido o uso desta cláusula, dentro da view.
A pergunta natural que surge é: Então, como faremos para ordenar os resultados? Muito simples. Na
hora de executar a view (conforme mostrarei logo a seguir), utilizaremos a cláusula ORDER BY, para
ordenar os resultados retornados pela view.
O restante do comando é onde é feito o relacionamento entre as tabelas Pedidos e Detalhes do Pedido,
através do campo NúmeroDoPedido e entre as tabelas Pedidos e Funcionários, através do campo
CódigoDoFuncionário. Basicamente são duas cláusulas INNER JOIN, conforme indicado no trecho de
código a seguir.
FROM
(Funcionários INNER JOIN Pedidos ON Funcionários.CódigoDoFuncionário =
Muito bem, vamos salvar e testar a nossa view.

SELECT * FROM [Con - Total por País e Funcionario] ORDER BY PaísDeDestino, Nome
NOTA
Figura 9.25 Resultados da execução da nossa view em conjunto com ORDER BY.
Eu estou insistindo, bastante, no entendimento dos comandos T-SQL, pois eles são o que há de mais
importante no SQL Server 2005. Para salientar o poder e flexibilidade destes comandos, vamos fazer
uma pequena alteração na nossa view.
9. Muito bem. Agora vamos começar a alterar nossa view. Vamos alterar o comando SQL da view
para que, ao invés da soma das vendas por país e por funcionário, seja exibido o número de
pedidos por país de destino e por funcionário. Para isso, vamos substituir o campo calculado
TotalDeVendas pelo campo NúmeroDoPedido, pois esse é o campo que é único para cada
pedido. Por isso é indicado para ser utilizado em uma contagem. Além disso, vamos trocar a
função SUM pela função COUNT. Mãos à obra.
10. Localize a view Con - Total por País e Funcionario, clique com o botão direito do mouse na
view e, no menu de opções que é exibido, clique em Delete. Será exibida uma janela solicitando
la novamente, pois vamos adicionar novas colunas na view e retirar colunas.
11. Clique com o botão direito do mouse na opção views, abaixo de NwindAccess, e, no menu de
por País e Funcionario.
13. Na parte do comando da view, após o AS, é que vem o comando T-SQL para a criação da view.
Vamos agora alterar o comando, em relação ao que foi utilizado anteriormente. Vamos retirar
a coluna calculada TotalDeVendas. No seu lugar, vamos inserir o campo NúmeroDoPedido, da
tabela Pedidos e, neste campo, vamos usar a função COUNT. Para criar esta view, digite o
seguinte comando, na linha abaixo do AS:
SELECT Pedidos.PaísDeDestino, Funcionários.Nome, Count(Pedidos.NúmeroDoPedido) AS
ContarDeNúmeroDoPedido
FROM (Funcionários INNER JOIN Pedidos ON Funcionários.CódigoDoFuncionário =

SELECT * FROM [Con - Total por País e Funcionario] ORDER BY PaísDeDestino, Nome
Observe que, agora, ao invés do total de vendas por país e por funcionário, temos o número de pedidos
por país e por funcionário. Observe como o conhecimento dos comandos T-SQL nos dá uma vantagem
muito grande, permitindo a criação de views, para a obtenção dos resultados desejados. Conhecer bem
os comandos T-SQL é mais do que uma obrigação do administrador e do desenvolvedor que trabalha
com o SQL Server 2005: É INDISPENSÁVEL.
Vamos continuar analisando casos de usos dos comandos T-SQL para a criação de views.
Figura 9.26 Resultados da execução da nossa view, após as alterações.
EXEMPLO PRÁTICO 03: CRIANDO UMA VIEW BASEADA EM OUTRA VIEW

Neste nosso terceiro exemplo, vamos usar um conceito de grande importância, o qual é muito pouco
utilizado, talvez por falta de conhecimento ou por falta de hábito: a criação de uma view baseada em
outra view. Este é um recurso realmente muito poderoso. Muitas vezes, não conseguimos obter os
resultados desejados, com uma única view. Nestas situações, podemos dividir o nosso problema em
partes, onde cada parte é solucionada com a criação de uma view. Criamos uma view para solucionar
uma parte do problema. Depois criamos uma segunda view, baseada na primeira, para solucionar a
segunda parte do problema. Depois, criamos uma terceira view, baseada na segunda, para solucionar
mais uma parte do problema. E assim por diante, até chegarmos ao resultado final.
Vamos imaginar que estamos criando uma view chamada view2, a qual será baseada em uma view já
existente, chamada view1. Quando a view2 for executada, primeiro o SQL Server 2005 executa a view1.
O conjunto de dados retornados pela view1 será utilizado para a execução da view2. Todo esse processo
é transparente para o usuário.
Neste nosso exemplo, apenas para ilustrar, didaticamente, este conceito, vamos criar uma seqüência
de três views (na verdade a primeira que utilizaremos já foi criada no Exemplo Prático 01). A segunda
view será baseada na primeira e a terceira será baseada na segunda.
Nota: Poderíamos solucionar este exemplo usando uma única view. Mas para salientar o conceito de
view baseada em view, vamos dividir o problema em três views.
Neste exemplo, o nosso objetivo é listar o total de vendas por ano. Vamos criar uma view, que nos dê
o resultado indicado na Figura 9.27.
Bem, a questão que fica é: Como chegar a este resultado, usando views, no SQL Server 2005? A resposta
esta logo a seguir. Continue acompanhando.
3. Clique com o botão direito do mouse na opção Views, abaixo de NwindAccess, e, no menu de
anterior. A primeira view que nós precisamos já existe. É a view Con - Total por Pedido, a qual
calcula o total por pedido. Nos criaremos a segunda view, a qual será baseada nesta primeira
view e que exibirá duas colunas calculadas adicionais. Uma que exibe somente o ano do campo
DataDoPedido e outra que exibe somente o mês, do campo DataDoPedido. No campo view
name, digite Con – Totais com Ano e Mês.
5. Na parte do comando da view, após o AS é que vem o comando T-SQL para a criação da Para
desta view. Digite o seguinte comando, na linha abaixo do AS:
SELECT [Con - Total por Pedido].NúmeroDoPedido, [Con - Total por Pedido].DataDoPedido,
Year([DataDoPedido]) AS AnoPedido, Month([DataDoPedido]) AS MêsPedido,
[Con - Total por Pedido].TotalDoPedido
FROM [Con - Total por Pedido];
Este comando tem algumas novidades em relação ao que já aprendemos. Vamos comentar estas
novidades.
O primeiro trecho a ser analisado é o seguinte:

Year([DataDoPedido]) AS AnoPedido, Month([DataDoPedido]) AS MêsPedido
Neste trecho, utilizei a função Year, para criar um campo que retorna apenas o ano do campo
DataDoPedido. Chamei este campo de AnoPedido. Também utilizei a função Month, para criar um
campo que retorna apenas o mês do campo DataDoPedido.
Observe também que estamos selecionando o campo TotalDoPedido, o qual é um campo calculado da
view Con - Total por Pedido.

SELECT * FROM [Con – Totais com Ano e Mês] ORDER BY AnoPedido, MêsPedido
NOTA
Figura 9.28 Resultados da execução da nossa view, com campos para o ano e mês.
Observe que agora temos uma view, baseada em outra view. Ou seja, criamos a view Con – Totais com
Ano e Mês, a qual por sua vez é baseada na view Con – Total por Pedido. Quando a view Con – Totais
com Ano e Mês é executada, primeiro será executada a view Con – Total por Pedido. Os resultados
retornados pela view Con - Total por Pedido é que serão utilizados como base para a view Con – Totais
com Ano e Mês.
9. Muito bem. Agora vamos criar uma terceira view. Vamos chamá-la de Com – Totais Anuais de
Venda. Esta view será baseada na view Con – Totais com Ano e Mês. Então mãos à obra.
10. Clique com o botão direito do mouse na opção views, abaixo de NwindAccess, e, no menu de
anterior. No campo view name, digite Con – Totais Anuais de Venda.
12. Na parte do comando da view, após o AS é que vem o comando T-SQL para a criação desta
view. Digite o seguinte comando, na linha abaixo do AS:
SELECT [Con – Totais com Ano e Mês].AnoPedido,
Sum([Con – Totais com Ano e Mês].TotalDoPedido) AS TotalAnualDeVendas
FROM [Con – Totais com Ano e Mês]
GROUP BY [Con – Totais com Ano e Mês].AnoPedido
Observe que, basicamente, estamos selecionando os campos AnoPedido e TotalDoPedido, da view

Con – Totais com Ano e Mês. No campo TotalDoPedido estamos fazendo uma soma e chamando esta
soma de TotalAnualDeVendas. Por último, agrupamos pelo campo AnoPedido. Mais uma vez é só o
uso do bom e velho T-SQL, nada de mais.

SELECT * FROM [Con – Totais Anuais de Venda] ORDER BY AnoPedido
15. Pronto, solucionado o exemplo proposto. Você deverá obter os resultados indicados na Figura 9.29:
Figura 9.29 Totais anuais de vendas.
Muito bem, com estes exemplos, podemos ver o valor dos comandos T-SQL. Ao dominarmos estes
comandos, poderemos criar views que atendam demandas reais, por listagens com totalizações, filtragens
e uma série de outros requisitos.
CRIANDO VIEWS COM A JANELA DE EXECUÇÃO DE COMANDOS T-SQL

Criar views com janela de execução de comandos T-SQL é simplesmente uma questão de utilizar o
comando CREATE VIEW. Vamos estudar este comando neste item.
A sintaxe para o comando CRETE VIEW é a seguinte:
CREATE VIEW [ < database_name > . ] [ < owner > . ] view_name [ ( column [ ,...n ] ) ]
[ WITH < view_attribute > [ ,...n ] ]
AS
select_statement
[ WITH CHECK OPTION ]
Simplificando a sintaxe apresentada no Books OnLine, teríamos o seguinte:
CREATE VIEW Nome_da_view

AS
Comando SQL
Por exemplo, para criar uma view chamada Pedidos_Teste, que retorna os campos OrderID, OrderDate,
ShipCountry e ShipCity da tabela Orders do Banco de Dados Northwind, utilizamos o seguinte comando:
USE Northwind
GO
CREATE VIEW Pedidos_Teste
AS
SELECT OrderID, OrderDate, ShipCountry
FROM Orders
NOTA
É importante que você coloque o comando GO, antes do comando CREATE VIEW, caso o comando CREATE VIEW não seja o primeiro comando.
Se não utilizarmos o comando GO, será emitida a seguinte mensagem de erro:
‘CREATE VIEW’ must be the first statement in a query batch.
O mais importante para a criação de views, utilizando a janela de execução de comandos T-SQL, é
conhecer a linguagem T-SQL. Pois uma view nada mais é do que um comando T-SQL gravado em um
Banco de Dados. Isso só reforça o que eu insisti, exaustivamente, nos exemplos anteriores, ou seja, a
importância de conhecer e dominar os comandos T-SQL.
Quando criamos uma view, o que é gravado no Banco de Dados é apenas o comando T-SQL, além de
informações sobre permissões de acesso. Os dados que a view retornar são obtidos a partir das tabelas
do Banco de Dados, toda vez que a view for executada.
A permissão para utilizar o comando CREATE VIEW é atribuída para as roles de Banco de Dados db_owner
e db_ddladmin, além da role de servidor sysadmin.
Podemos fazer com que o texto da view, que é armazenado na tabela syscomments, seja criptografado.
Isto impede que o código seja acessado simplesmente através de um SELECT na tabela syscomments.
Ou melhor, o código até que pode ser acessado, só que o texto estará criptografado, impedindo que
seja lido, a menos que a criptografia seja quebrada. A seguir, um exemplo de criação de uma view com
a utilização da opção WITH ENCRYPTION:
CREATE VIEW Pedidos_Criptografada

WITH ENCRYPTION
AS
SELECT OrderID, OrderDate, ShipCountry, ShipCity
FROM Orders
WHERE ShipCountry = ‘Alemanha’
Vamos a um exemplo: criar uma view chamada Média_Vendas_por_Ano. Esta view será criada no
banco de dados NwindAccess. Esta view deve exibir um registro para cada ano em que existem pedidos
e o valor médio de vendas para cada ano.
O detalhe nesta view é que temos que utilizar dados da tabela Pedidos e da tabela Detalhes do Pedido.
Pois os cálculos do total por pedido, os quais vão possibilitar o cálculo da média anual, são realizados
a partir dos campos da tabela Detalhes do pedido. Além disso, teremos que utilizar a função Year, para
extrair apenas o ano do campo DataDoPedido. Depois, agrupamos o campo ano e utilizamos a função
AVG na coluna que calcula o valor das vendas.
Para criar esta view, siga os passos indicados a seguir:
1. Abra a janela de execução de comandos T-SQL.
2. Digite e execute o seguinte comando:

USE NwindAccess
GO
CREATE VIEW Média_Vendas_por_Ano
AS
SELECT YEAR(DataDoPedido) AS [Ano do Pedido],
AVG(([Quantidade] * [PreçoUnitário])* (1 -[Desconto])) AS [Média Anual]
FROM [Pedidos]
INNER JOIN
[Detalhes do Pedido] ON [Pedidos].[NúmeroDoPedido] =
[Detalhes do Pedido].[NúmeroDoPedido]
GROUP BY YEAR(DataDoPedido)
Agora vamos testar se a view Média_Vendas_por_Ano está retornando os resultados desejados.

SELECT * FROM Média_Vendas_por_Ano
Você deve obter os resultados indicados na Figura 9.30.
Figura 9.30 Média anual de vendas.
Já que estamos com a janela de execução de comandos T-SQL aberta, vamos aprender a atribuir
permissões para views e depois testar estas permissões.
NOTA
Para uma discussão aprofundada sobre o modelo de segurança e atribuição de permissões, consulte o Capítulo 6 deste livro.
No Capítulo 6, havíamos dado permissão para os usuários SERVIDOR\user1 e SERVIDOR\user2 acessar
a instância SERVIDOR\SQL2005. Agora, vamos adicioná-los como usuários com permissão de acesso
ao Banco de Dados NwindAccess, da instância SERVIDOR\SQL2005.
1. Você ainda deve estar com a janela de execução de comandos T-SQL aberta e logado na instância
SERVIDOR\SQL2005. Execute o seguinte comando:
USE NwindAccess
GO
Agora vamos dar permissão de acesso para o usuário SERVIDOR\user1 para a view Média_Vendas_por_Ano,
e vamos negar permissão de acesso a esta view, para o usuário SERVIDOR\user2.
2. Para dar permissão de acesso ao usuário SERVIDOR\user1, execute o seguinte comando:

GRANT SELECT ON Média_Vendas_por_Ano
TO [SERVIDOR\user1]
3. Para negar permissão de acesso ao usuário SERVIDOR\user2, execute o seguinte comando:

DENY SELECT ON Média_Vendas_por_Ano
TO [SERVIDOR\user2]
Se o usuário SERVIDOR\user2 tentar executar o seguinte comando:

ele obterá a seguinte mensagem de erro:

SELECT permission denied on object ‘Média_Vendas_por_Ano’, database ‘NwindAccess,
A mensagem nos informa que o usuário não tem permissão de acesso. Isto confere com as configurações
de permissões que fizemos.
4. Feche a janela de execução de comandos T-SQL e feche o SQL Server Management Studio.
No próximo capítulo e no Apêndice, falarei ainda mais sobre a linguagem T-SQL e também sobre
funções disponíveis. No exemplo anterior, utilizamos a função Year, para extrair apenas o ano do
campo OrderDate. No próximo capítulo, veremos uma série de funções que podem ser utilizadas em
comandos T-SQL.
CONCLUSÃO
Neste capítulo apresentamos os elementos básicos para o desenvolvimento de aplicações que se baseiam
no SQL Server 2005.
Iniciamos o capítulo tratando sobre integridade de dados e como o SQL Server 2005 faz para mantê-la.
Falamos sobre os diferentes tipos de integridade e aprendemos a implementá-los, utilizando constraints.
Vimos diversos exemplos de construção de constraints.
Depois, passamos a tratar da criação de views. Através de uma view, podemos facilitar e simplificar o
acesso aos dados. Podemos ocultar a complexidade de determinadas consultas, através da construção
de uma view. Tudo o que a aplicação precisa fazer é chamar a view, ao invés de ter que entender toda
a complexidade necessária para acessar os dados. Com a view, também podemos atribuir permissões
de uma maneira centralizada, o que facilita a administração da segurança.
No próximo capítulo, continuaremos tratando de desenvolvimento, tendo como base elementos do

próprio SQL Server 2005. Nos capítulos seguintes – Capítulo 11 e Capítulo 12 –, passaremos a tratar do
desenvolvimento de aplicações que acessam os Bancos de Dados do SQL Server 2005.
Parte 3
DESENVOLVIMENTO
SQL SERVER 2005 ADMINISTRAÇÃO E DESENVOLVIMENTO – PARTE 3: DESENVOLVIMENTO
NOTA
CAPÍTULO 10 – DESENVOLVIMENTO NO SQL SERVER 2005 – STORED PROCEDURES E TRIGGERS
Capítulo 10
DESENVOLVIMENTO NO SQL SERVER 2005 –
STORED PROCEDURES E TRIGGERS
INTRODUÇÃO
Neste capítulo aprenderemos tópicos avançados de desenvolvimento de aplicações no SQL SERVER
2005. Tratarei de elementos que são criados em um Banco de Dados do SQL SERVER 2005 e podem ser
acessados por aplicações desenvolvidas em Visual Basic, Delphi, ASP, ASP.NET, VB.NET, C#, etc.
Iniciaremos o capítulo falando sobre stored procedures. Conforme veremos, existem muitas
aplicações práticas e vantagens de utilizarmos stored procedures. A linguagem que utilizamos para
criar stored procedures, como não poderia deixar de ser em se tratando de SQL SERVER 2005, é a
linguagem T-SQL.
Stored procedures são semelhantes a procedimentos e sub-rotinas em outras linguagens. Por exemplo:
♦ Podem ser chamados por outro stored procedures ou por programas desenvolvidos em ASP,
Visual Basic, Delphi, ASP.NET, C#, VB.NET, etc.
♦ Podem receber um ou mais parâmetros de entrada e retornar um ou mais parâmetros de saída.
♦ Podem conter lógica de programação, como instruções de controle e de laço.
A utilização de stored procedures nos fornece vantagens, como por exemplo: programação modular,
execução mais rápida, redução de tráfego de rede e, ainda, podem ser utilizados como um mecanismo
de segurança.
Depois, passaremos a estudar o mecanismo de Triggers.
Triggers são uma classe especial de stored procedures. Uma trigger pode ser programada para executar
sempre que um comando UPDATE, INSERTE ou DELETE for executado em um Banco de Dados. A
principal utilização de triggers é para impor “Regras de Negócio” ao Banco de Dados. Uma regra de
negócio é uma regra do mundo real que deve ser respeitada pelas operações efetuadas sobre os
dados do Banco de Dados. Vamos supor que um gerente de um determinado banco não possa
aprovar mais do que R$ 50.000,00 em empréstimos por mês. Ao inserir um novo empréstimo no
Banco de Dados, podemos fazer com que seja verificado o total de empréstimos já aprovados pelo
gerente, no mês corrente. Se o total exceder o valor máximo para o gerente, o novo empréstimo
não será aprovado. Podemos inclusive fazer com que o chefe imediato do gerente receba um e-
mail avisando desta situação.
Também mostraremos um exemplo de triggers que atualizam, automaticamente, uma página HTML
com dados de uma ou mais tabelas. Veremos passo a passo como construir esta página e testaremos a
atualização automática da página.
Na parte final do capítulo, tratarei de alguns comandos avançados da linguagem T-SQL. Falaremos
sobre joins avançados e os diferentes tipos de joins existentes, sobre “Sumarização” de dados. Também
trataremos das diversas funções que podem ser utilizadas em uma instrução SELECT. Também veremos
criação de subconsultas e os cuidados em relação ao desempenho, quando utilizamos subconsultas.
Este capítulo apresenta uma série de conceitos de fundamental importância para o desenvolvimento
de aplicações com o SQL Server 2005 ou baseadas no SQL Server 2005. Nos próximos capítulos, falaremos
um pouco mais sobre aplicações, principalmente utilizando páginas ASP para acessar um Banco de
Dados no SQL Server 2005.
DESENVOLVIMENTO EM: TEORIA E DESENVOLVIMENTO DE STORED

PROCEDURES NO SQL SERVER 2005
PRÉ-REQUISITOS
♦ Saber utilizar o SQL Server Management Studio e o Query Analyzer.
♦ Noções sobre Integridade de Dados e os tipos de integridade existentes no SQL Server 2005.
♦ Noções sobre os comandos básicos da linguagem T-SQL.
METODOLOGIA
♦ Apresentação do conceito de stored procedures e dos principais comandos para a criação e teste de stored procedures.
TÉCNICA
♦ Utilização da janela de execução de comandos T-SQL e do SQL Server Management Studio para a criação e teste de stored procedures.
A primeira pergunta que temos que responder é a seguinte:
“O que é um stored procedure?”
Resposta formal: “Um stored procedure é uma coleção de comandos, à qual é atribuído um nome,
sendo que esta coleção nomeada de comandos é salva no Banco de Dados.”
Resposta descomplicada: “Podemos gravar um conjunto de comandos, que realiza uma função específica
no Banco de Dados. Ao salvarmos este conjunto de comandos damos um nome a ele. Pronto, acabamos
de criar um stored procedure.”
Uma vez criado, o stored procedure pode ser executado sempre que for necessário, simplesmente
“chamando” o stored procedure pelo nome, o que evita que tenhamos que digitar o conjunto de
comandos repetidamente, cada vez que ele tiver que ser utilizado. A utilização de stored procedures é
uma técnica eficiente quanto temos que executar o mesmo conjunto de comandos, repetidas vezes. Ao
invés de digitar os comandos cada vez que a operação precisa ser executada, criamos um stored proce-
dure e executamos o stored procedure, sempre que for necessário. Isso evita que o mesmo conjunto de
comandos tenha que ser inserido em diversos locais no Banco de Dados. Se tivermos que alterar o
conjunto de comandos de uma determinada operação, basta alterá-lo no stored procedures e todos os
objetos que chamam o stored procedure passarão a ter acesso à nova versão. Isto facilita muito as
alterações na lógica do Banco de Dados. É ou não é muito parecido com a idéia de Procedimentos e
Funções de linguagens como o Pascal e o C.
Em um stored procedure também podemos ter estruturas de controle e decisão, típicas das linguagens
de programação. Em termos de desenvolvimento de aplicações, também temos vantagens com a
utilização de stored procedures.
Vamos imaginar que estamos criando uma aplicação em Visual Basic e que a aplicação acessa dados de
um Banco de Dados do SQL Server 2005. Sem a utilização de stored procedures, a aplicação precisa
enviar o conjunto de comandos T-SQL necessários à execução de cada tarefa. Pode ser que, em diversas
partes do programa, seja necessária a execução da mesma tarefa. A pior técnica possível seria codificar
estes comandos, nos diversos pontos do programa, onde os comandos são necessários. Qualquer
alteração iria demandar que todo o código do programa fosse revisado e as ocorrências dos comandos
alteradas. Simplesmente um pesadelo.
Poderíamos melhorar um pouco esta situação isolando o conjunto de comandos em uma função e
chamando a função onde os comandos são necessários. Isso faria com que apenas tivéssemos que
modificar a função, sempre que houvesse alteração na lógica de processamento dos dados. Mas imagi-
ne uma empresa grande, com milhares de usuários utilizando a aplicação em Visual Basic. Modificar
uma função interna da aplicação significa ter que reinstalar a aplicação em milhares de estações de
trabalho. A tarefa de manutenção da aplicação atualizada torna-se bastante complicada e dispendiosa
em termos de custos e tempo.
Se, ao invés de uma função interna da aplicação, criarmos um stored procedure e fizermos com que o
programa chame o stored procedure, para executar os comandos necessários, teremos mais facilidades
no momento de atualizar a aplicação. Pois, neste caso, bastaria alterar o stored procedure no servidor
SQL Server 2005 e pronto, a aplicação já passaria a ter acesso a versão modificada, evitando uma
reinstalação da aplicação cliente em milhares de estações de trabalho.
NOTA
Existem soluções ainda mais sofisticadas do que a utilização de stored procedures. São as chamadas aplicações em n camadas. Este é o
modelo recomendado pela Microsoft. Falaremos sobre aplicações de n camadas no Capítulo 11.
Além de facilitar a manutenção e alteração das aplicações, a utilização de stored procedures nos fornece
outras vantagens, dentre as quais destacamos as seguintes:
♦ Ocultar a complexidade de acesso ao Banco de Dados: Quando utilizamos a normalização

de tabelas, a tendência é que tenhamos um número elevado de tabelas no Banco de Dados.
Porém, do ponto de vista do usuário, as consultas por ele executadas envolvem dados de
diversas tabelas. Ao invés de fazer com que a aplicação tenha que tratar desta complexidade
– acessando e consolidando dados de diversas tabelas para exibi-los de uma maneira
consolidada para o usuário – podemos “ocultar” esta complexidade num stored procedure.
O stored procedure contém todos os comandos necessários para buscar os dados necessários
e fornece os dados para o usuário. A única coisa que a nossa aplicação precisa fazer é chamar
o stored procedure e receber os resultados. Veja que isto simplifica, enormemente, o
desenvolvimento de aplicações.
♦ Pode receber parâmetros de entrada e retornar resultados, através de parâmetros de saída:

Com isso um stored procedure pode ser desenvolvido, de tal forma que receba parâmetros de
entrada e, com base nos parâmetros recebidos, execute diferentes comandos ou retorne diferentes
conjuntos de dados.
♦ Redução no tráfego de rede gerado pela aplicação: Esta redução acontece porque, ao invés
de a aplicação enviar um grande número de comandos, é enviado para o servidor apenas o
pedido de execução do stored procedure e os parâmetros de entrada necessários. O stored
procedure executa e retorna somente os resultados, na forma de parâmetros de saída.
♦ Facilita e centraliza o gerenciamento de permissões: Podemos atribuir permissões em nível
de usuário ou role para a execução de um stored procedure.
♦ Melhoria na velocidade de execução: O SQL Server 2005 compila os comandos do stored
procedure, na primeira vez que este é executado, e mantém estes comandos na memória cache,
para agilizar as próximas execuções. Isto faz com que as chamadas subseqüentes executem
bem mais rápido.
Temos diversos tipos de stored procedures. Neste capítulo aprenderemos a criar os chamados “User-
defined stored procedures”, ou seja, stored procedures criados (definidos) pelo usuário. Podemos criar
User-defined stored procedures em qualquer Banco de Dados do usuário.
Os tipos de stored procedures existentes são os seguintes:
♦ User-defined stored procedures: São criados nos Bancos de Dados do usuário. São utilizados
para execução de tarefas repetitivas, facilitando a manutenção e alteração destas tarefas.
♦ Temporary stored procedures: São criados e mantidos pelo próprio SQL Server 2005, no Banco
de Dados tempdb. Normalmente, estão associados a tarefas de manutenção e gerenciamento
de conexões de usuários com o servidor SQL Server 2005. Podemos ter dois tipos:
♦ stored procedures temporários locais: O nome inicia com o sinal # e somente a conexão
que criou um stored procedure temporário poderá executá-lo; ao ser encerrada a conexão, o
stored procedure é eliminado.
♦ Stored procedures temporários globais: O nome inicia com ## e podem ser executados por
todas as conexões ativas com o Banco de Dados, até que a conexão que criou o stored proce-
dure seja encerrada, quando então o stored procedure é excluído.
♦ System stored procedures: Já falamos e utilizamos bastante este tipo de stored procedures.
São criados no momento da instalação do SQL Server 2005 e ficam gravados no Banco de
Dados master. Iniciam com “sp_”. São utilizados para uma série de tarefas de manutenção e
gerenciamento dos diversos objetos e configurações do servidor SQL Server 2005.
♦ Extended stored procedures: Executam funções externas ao servidor SQL Server 2005,
normalmente funções típicas do sistema operacional. São criados no momento da instalação
do SQL Server 2005 e tem o nome iniciando com “xp_”. Alguns System stored procedures têm
sua funcionalidade baseada na chamada a Extended stored procedures.
Ao criarmos um stored procedure, os comandos do stored procedure são verificados em busca de erros
de sintaxe. Se houver erros, uma mensagem é emitida e o stored procedure não poderá ser salvo enquanto
os erros não forem corrigidos. Na Figura 10.1, temos um exemplo de uma mensagem de erro, na
verificação da sintaxe dos comandos de um stored procedure.
Figura 10.1 Erro nos comandos de um stored procedure.
Agora que já conhecemos o que é e quais as vantagens, podemos partir para a criação de stored procedures.
CRIANDO STORED PROCEDURES

Criar um stored procedure consiste, basicamente, em definir o conjunto de comandos do stored proce-
dure e salvar este conjunto com um nome, no Banco de Dados.
A exemplo de outros objetos de Banco de Dados, podemos criar um stored procedure, utilizando duas
maneiras diferentes:
♦ A janela de execução de comandos T-SQL
Vamos começar pela janela de execução de comandos T-SQL, para que possamos aprender os diversos
comandos que podem ser incluídos em um stored procedure.
CRIANDO STORED PROCEDURES COM

A JANELA DE EXECUÇÃO DE COMANDOS T-SQL
Para criar um stored procedure, utilizamos o comando CREATE PROCEDURE. Ao criarmos stored pro-
cedures devemos lembrar dos seguintes detalhes:
♦ O tamanho máximo de um stored procedure é 128 MB. Convenhamos que é mais do que
suficiente. Se você tiver que escrever um stored procedure e este for muito grande, é provável
que deva ser adotada outra solução, como a criação de um objeto COM+ ou um Web Service,
na nova arquitetura .net da Microsoft.
♦ Somente usuários que são membros da role de servidor sysadmin ou das roles de Banco de
Dados db_owner e db_ddladmin têm permissão para executar o comando CREATE PROCE-
DURE. Esta permissão pode ser atribuída por membros da role sysadmin, para outros usuários.
♦ Em um stored procedures podemos referenciar tabelas, views, outros stored procedures e tabelas
temporárias.
♦ Podemos incluir, em um stored procedure, qualquer comando T-SQL, com exceção dos seguintes
comandos: CREATE PROCEDURE, CREATE DEFAULT, CREATE RULE, CREATE TRIGGER e
CREATE VIEW.
Sintaxe para o comando CREATE PROCEDURE:
CREATE PROCEDURE nome_do_stored_procedure

[
{@nome_parâmetro1 tipo_de_dados_do_parâmetro} [=valor_default] [OUTPUT]
]
[,..n]
AS
comando 1
comando 2
...
comando n
Vamos a um exemplo simples.
Exemplo prático: Criar e testar um stored procedure que retorna todos os registros da tabela Pedidos,
do Banco de Dados NwindAccess (para detalhes sobre a criação e importação de dados para este Banco
de Dados, consulte o Capítulo 9), em que o campo PaísDeDestino é igual a Brasil. Gravar o stored
procedure com o nome usp_PedidosDoBrasil. Este stored procedure será criado no Banco de Dados
NwindAccess da instância SERVIDOR\SQL2005.
NOTA
Estamos utilizando o prefixo usp_ para indicar user stored procedure. Porém esta não é uma convenção obrigatória, apenas uma recomendação.
Para criar o stored procedure usp_PedidosDoBrasil, siga os passos indicados a seguir:
1. Abra o SQL Server Management Studio e navegue até o Banco de Dados NwindAccess, da
2. Clique com o botão direito do mouse no Banco de Dados NwindAccess e, no menu de opções
3. Será aberta a janela de execução de comandos T-SQL, sendo o Banco de Dados NwindAccess, o
Banco de Dados atual. Execute o seguinte comando:
USE NwindAccess
GO
CREATE PROCEDURE usp_PedidosDoBrasil
AS
SELECT * FROM Pedidos
WHERE PaísDeDestino = ‘Brasil’
O comando é executado e a seguinte mensagem é exibida:

Figura 10.2 A execução do stored procedure usp_PedidosDoBrasil.
4. Agora podemos executar o stored procedure sempre que for necessário. Para executá-lo, exe-
cute o seguinte comando:
exec usp_PedidosDoBrasil
O stored procedure é executado, os comandos que o compõem são executados e os resultados, retornados
(somente os pedidos para o Brasil), conforme indicado na Figura 10.2.
Muito bem, acabamos de criar e de executar o nosso primeiro stored procedures. Vamos continuar
avançando no nosso estudo. No próximo tópico, tratarei sobre a criação de stored procedures que
aceitam parâmetros de entrada.
CRIANDO STORED PROCEDURES COM PARÂMETROS DE ENTRADA

A utilização de parâmetros de entrada permite a criação de stored procedures mais flexíveis. Vamos
considerar o stored procedure usp_PedidosDoBrasil, criado no exemplo anterior. Da maneira como foi
criado, sem parâmetros de entrada, o critério de pesquisa será sempre o mesmo: PaísDeDestino = ‘Brasil’.
Podemos criar um stored procedure mais genérico, o qual aceita o nome do País de Destino como
parâmetro de entrada e retorna somente os pedidos para o país passado como parâmetro de entrada.
Para criar um stored procedure com um ou mais parâmetros de entrada, utilizamos a seguinte sintaxe:
CREATE PROCEDURE nome_StorProc

@nome_parâmetro tipo_parâmetro
AS
comando 1
comando 2
...
comando n
Caso tenhamos mais do que um parâmetro de entrada, devemos separá-los por vírgula, conforme
indicado a seguir:
CREATE PROCEDURE
@nome_parâmetro1 tipo_parâmetro1,
...
@nome_parâmetron tipo_parâmetron
AS
comando 1
comando 2
...
comando n
Para utilizar o parâmetro nos comandos do stored procedure, basta utilizar @nome_do_parâmetro.
Vamos a alguns exemplos práticos, os quais facilitarão o entendimento desta sintaxe.
Exemplo 1: Criar um stored procedure chamado usp_Pedidos_PaisParametro. Este store procedure será
criado no Banco de Dados NwindAccess, da instância SERVIDOR\SQL2005. O stored procedure deve
aceitar um parâmetro de entrada chamado Pais, o qual é do tipo nvarchar(25), e usará o valor passado
neste parâmetro como critério de pesquisa, para retornar apenas os pedidos para o país passado como
parâmetro de entrada.
Para criar o stored procedure usp_Pedidos_PaisParametro, siga os passos indicados a seguir:
3. Será aberta a janela de execução de comandos T-SQL, sendo o Banco de Dados NwindAccess o

USE NwindAccess
GO
CREATE PROCEDURE usp_Pedidos_PaisParametro
@Pais nvarchar(25)
AS
WHERE PaísDeDestino = @Pais
5. Para executar o stored procedure usp_Pedidos_PaisParametro, passando Campinas como

parâmetro, utilizamos o seguinte comando:
Execute usp_Pedidos_PaisParametro “EUA”
Na Figura 10.3, temos os resultados da execução do stored procedure, com EUA sendo passado como
Figura 10.3 Execução de um stored procedure com valor do parâmetro de entrada = EUA.
6. Para executar o stored procedure usp_Pedidos_PaisParametro, passando França como parâmetro,
Execute usp_Pedidos_PaisParametro “França”
Na Figura 10.4, temos os resultados da execução do stored procedure, com França sendo passado como
Figura 10.4 Execução de um ptored procedure com valor do parâmetro de entrada = França.
Observe que agora temos um stored procedure bem mais flexível, onde podemos informar o critério de
pesquisa para o campo PaísDeDestino, simplesmente passando um valor para o parâmetro de entrada.
7. Mantenha a janela de execução de comandos T-SQL aberta, pois vamos continuar a utilizá-la,
no próximo exemplo.
Exemplo prático 02: Criar um stored procedure chamado usp_Ped_Cid_País. Este será criado no
Banco de Dados NwindAccess, da instância SERVIDOR\QL2005. O stored procedure deve aceitar
dois parâmetros de entrada: um chamado cidade, o qual é do tipo nvarchar(15), e outro chamado
país, o qual é do tipo nvarchar(15). O stored procedure usará os valores passados nestes parâmetros
como critérios de pesquisa, para retornar apenas os pedidos para a cidade e país de destino passados
como parâmetros.
Para criar o stored procedure usp_Ped_Cid_País, siga os passos indicados a seguir:
USE NwindAccess
GO
CREATE PROCEDURE usp_Ped_Cid_País
@cidade nvarchar(15),
@país nvarchar(15)
AS
SELECT * FROM Orders
WHERE (CidadeDeDestino = @cidade) and (PaisDeDestino=@país)
5. Para executar o stored procedure usp_Ped_Cid_País, passando “Buenos Aires” como valor para o
parâmetro cidade, e “Argentina” como valor para o parâmetro país, utilizamos o seguinte comando:
Execute usp_Ped_Cid_País “Buenos Aires”, “Argentina”
6. Para executar o stored procedure usp_Ped_Cid_País, passando “Sao Paulo” como valor para o
parâmetro cidade, e “Alemanha” como valor para o parâmetro país, utilizamos o seguinte comando:
Execute usp_Ped_Cid_País “Sao Paulo”, “Alemanha”
Evidentemente que esta última execução não irá retornar nenhum registro, apenas a seguinte mensagem
será exibida:
(0 row(s) affected)
Se passarmos apenas o parâmetro cidade, ignorando o parâmetro país, conforme indicado no seguinte
comando:
Execute usp_Ped_Cid_País “Sao Paulo”
iremos obter a seguinte mensagem de erro:
Msg 201, Level 16, State 4, Procedure usp_Ped_Cid_País, Line 0

Procedure or Function ‘usp_Ped_Cid_País’ expects parameter ‘@país’, which was not supplied..
Observe que a mensagem informa que é esperado um parâmetro chamado país (@país) e que este
parâmetro não foi informado, ao ser feita a execução do stored procedure.
Se passarmos parâmetros a mais, conforme indicado no seguinte comando:
Execute usp_Ped_Cid_País “Sao Paulo”, “Alemanha”, “12/06/2001”
Msg 8144, Level 16, State 2, Procedure usp_Ped_Cid_País, Line 0

Procedure or function usp_Ped_Cid_País has too many arguments specified.
UTILIZANDO ESTRUTURAS DE DECISÃO EM UM STORED PROCEDURE

A linguagem que utilizamos para os comandos de um stored procedure é a linguagem T-SQL. Como
toda linguagem que se preza, temos estruturas de decisão na linguagem T-SQL. A seguir, vamos apresentar
as principais estruturas de controle disponíveis.
A ESTRUTURA IF...ELSE
Este é o bom e velho IF que existe em qualquer linguagem. A estrutura do IF...ELSE é a seguinte:
IF Teste_booleano
Comandos se o teste for verdadeiro
ELSE
Comandos se o teste for falso
Vamos a um exemplo prático: Criar um stored procedure que recebe o nome de dois países como parâmetros
de entrada. O stored procedure conta o número de pedidos enviados para cada país. O número de pedidos
de cada país é armazenado em uma variável local do stored procedure. Depois, um teste é efetuado, utilizando
a cláusula IF...ELSE e diferentes mensagens serão emitidas, dependendo de o teste ser verdadeiro ou falso. O
stored procedure será criado como o nome usp_ExIF e será gravado no Banco de Dados NwindAccess. As
pesquisas serão feitas na tabela Pedidos do Banco de Dados NwindAccess, da instância SERVIDOR\SQL2005.
O comando para criar o stored procedure proposto é o seguinte:
USE NwindAccess
GO
CREATE PROCEDURE usp_ExIF
@país1 nvarchar(15),
@país2 nvarchar(15)
AS
— Cria as variáveis locais

DECLARE @TotPed1 int, @TotPed2 int
DECLARE @mensagem1 Char(100), @mensagem2 Char(100)
— Define o valor de cada variável
SET @TotPed1 = (SELECT Count(NúmeroDoPedido) FROM Pedidos WHERE PaísDeDestino=@país1)

— Executo o teste, utilizando IF...ELSE
IF (@TotPed1) > (@TotPed2)

BEGIN
SET @mensagem1= ‘O Número de pedidos do primeiro país é maior’
Print(@mensagem1)
END
ELSE
BEGIN
SET @mensagem2= ‘O Número de pedidos do segundo país é maior’
Print(@mensagem2)
END
Para executarmos este stored procedure, utilizamos o seguinte comando:
exec usp_ExIF “Brasil”,“EUA”
O stored procedure usp_ExIF é executado e a seguinte mensagem é emitida:
O Número de pedidos do segundo país é maior
Como somos um pouco “desconfiados”, vamos conferir se o stored procedure está funcionando
corretamente. Para isso, vamos simplesmente inverter os dois parâmetros, conforme indicado no
comando a seguir:
exec usp_ExIF “EUA”,“Brasil”
O Número de pedidos do primeiro país é maior
Isto confirma o funcionamento do nosso stored procedure. Como nós estamos com “más intenções”,
vamos tentar “confundir” o stored procedure usp_ExIF. Vamos passar o mesmo país para os dois
parâmetros, conforme indicado no comando a seguir:
exec usp_ExIF “EUA”,“EUA”
Opa !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Um pequeno “bug” no nosso stored procedure?
É isso mesmo.
Observe o seguinte trecho de código:

BEGIN
Print(@mensagem1)
END
ELSE
BEGIN
Print(@mensagem2)
END
Veja que apenas testamos se o número de pedidos do país 1 é maior do que o número de pedidos do
país 2 (IF (@TotPed1) > (@TotPed2)). Se o número de pedidos for igual – o que aconteceu quando
passamos o mesmo país para os dois parâmetros de entrada –, o teste falha e serão executados os
comandos da parte ELSE. Para corrigir este pequeno bug, temos que alterar o stored procedure, prevendo
uma terceira situação, na qual o número de pedidos dos dois países é igual. Bem, digamos que este foi
um bug introduzido de propósito. Pois agora aprenderemos dois novos detalhes:
♦ A estrutura IF com mais do que um ELSE.
♦ O comando ALTER PROCEDURE, para alterar um stored procedure já existente.
Exemplo prático: Utilizar o comando ALTER PROCEDURE, para alterar o stored procedure usp_ExIF e
corrigir o “bug” existente. Para fazer esta alteração, utilizamos o seguinte comando:
USE NwindAccess
GO
ALTER PROCEDURE usp_ExIF
@país1 nvarchar(15),
@país2 nvarchar(15)
AS
— Cria as variáveis locais

DECLARE @TotPed1 int, @TotPed2 int
DECLARE @mensagem1 Char(100), @mensagem2 Char(100)
DECLARE @mensagem3 Char(100)
— Define o valor de cada variável

— Executo o teste, utilizando IF...ELSE

BEGIN
Print(@mensagem1)
END
ELSE
IF (@TotPed1)<(@TotPed2)
BEGIN
Print(@mensagem2)
END
ELSE
BEGIN
SET @mensagem3= ‘O Número de pedidos dos dois países é igual’
Print(@mensagem3)
END
Observe que, para alterar o stored procedure, utilizamos o comando ALTER PROCEDURE e, após a
cláusula AS, temos que informar todos os comandos que irão redefinir o stored procedure. Os comandos
informados irão substituir o conjunto de comandos existentes.
NOTA
Somente o “dono” do stored procedure e as roles sysadmin, db_owner e db_ddladmin é que têm permissão para executar o comando ALTER
PROCEDURE. Esta permissão não pode ser atribuída a outros usuários ou roles.
Vamos testar novamente o stored procedure.
Para executarmos este stored procedure, utilizamos o seguinte comando:
exec usp_ExIF “Brazil”,“EUA”
OK. Este é o resultado esperado. Vamos continuar nossos testes. Execute o seguinte comando:
exec usp_ExIF “EUA”,“Brasil”
O Número de pedidos do primeiro país é maior
Maravilha. Estamos quase lá. Só falta o derradeiro teste. Execute o seguinte comando:
exec usp_ExIF “EUA”,“EUA”
O Número de pedidos dos dois países é igual
Maravilha !!!!!!!!!!!!!!!
Isto comprova que o bug foi corrigido.
Mais alguns comentários sobre o exemplo anterior:
♦ Utilizamos a cláusula DECLARE, para declarar variáveis locais, que são utilizadas pelo stored
procedure. A sintaxe para o comando DECLARE é a seguinte:
DECLARE @variável1 tipo, @variável2 tipo
♦ Para atribuir valores a uma variável local, utilizamos o comando SET. A sintaxe para o comando
SET é a seguinte:
SET @variável = valor
♦ Observe que o resultado retornado, por um comando SELECT, foi atribuído a uma variável
local, como no exemplo:
Agora vamos aprender mais uma estrutura de controle.
A ESTRUTURA WHILE...CONTINUE
Esta estrutura faz com que um conjunto de comandos continue sendo executado, enquanto uma
determinada condição for verdadeira.
A sintaxe para este comando é a seguinte:
WHILE Teste
BEGIN
Comando1
Comando2
...
Comandon
END
Enquanto o teste for verdadeiro, os comandos dentro do bloco BEGIN...END continuarão a ser executados.
Quando a condição tornar-se falsa, a execução continua no primeiro comando após o CONTINUE.
NOTA
Os comandos dentro do bloco BEGIN...END devem modificar o valor da variável (ou variáveis) que está sendo testada no início do laço
WHILE; caso contrário, a condição nunca se tornará falsa e o laço continuará executando sem parar. Veja o exemplo a seguir.
Exemplo: Vamos criar uma tabela chamada SomaNaturais. Esta tabela será criada no Banco de Dados
NwindAccess e terá a seguinte estrutura:
Tabela 10.1 Estrutira da tabela SomaNaturais.
Campo Tipo
Número float
SomaAcumulada float
Após criar a tabela SomaNaturais, vamos criar um stored procedure chamado usp_CalculaSoma, o qual
calcula a soma dos “n” primeiros números inteiros e armazena a soma nas respectivas colunas, conforme
indicado no exemplo a seguir:
Tabela 10.2 Valores da Soma no campo Soma Acumulada.
Número Soma Acumulada
1 1
2 3
3 6
4 10
5 15
E assim por diante. O valor de n será passado como parâmetro de entrada para o stored procedure.
O primeiro passo é criar a tabela SomaNaturais. Para isto utilizamos o seguinte comando:
USE NwindAccess
GO
CREATE TABLE SomaNaturais
(
Número float,
SomaAcumulada float
)
Agora vamos à criação do stored procedure:
USE NwindAccess
GO
CREATE PROCEDURE usp_CalculaSoma
@numero int
AS
— Cria uma variável para controle do laço
— e inicializa a variável com o valor 1.
DECLARE @contador int

SET @contador = 1
— Cria uma variável para a soma

DECLARE @soma float

SET @soma = 0
WHILE (@contador<=@numero)
BEGIN
SET @soma = @soma + @contador
INSERT INTO SomaNaturais VALUES (@contador,@soma)
SET @contador = @contador + 1
END
NOTA
Observe o comando SET @contador = @contador + 1, no interior da estrutura WHILE. Se não colocássemos este comando, a variável
@contador jamais se tornaria igual ao parâmetro @numero e o laço WHILE entraria em execução infinita. A criação de laços infinitos é uma
das causas mais comuns para o travamento de programas.
Agora vamos testar o stored procedure usp_CalculaSoma. Vamos passar como parâmetro o número 10.
Para isso utilizamos o seguinte comando:
EXEC usp_CalculaSoma 10
A execução deste comando retorna a seguinte mensagem:
(1 row(s) affected)
(1 row(s) affected)
(1 row(s) affected)
(1 row(s) affected)
(1 row(s) affected)
(1 row(s) affected)
(1 row(s) affected)
(1 row(s) affected)
(1 row(s) affected)
(1 row(s) affected)
Agora vamos dar um SELECT na tabela SomaNaturais. Utilize o seguinte comando:
SELECT * FROM SomaNaturais
Você obterá o seguinte resultado:
Tabela 10.3 Resultado da execução do Stored Procedure.
Número SomaAcumulada
1.0 1.0
2.0 3.0
3.0 6.0
Continua
Continuação
Número SomaAcumulada
4.0 10.0
5.0 15.0
6.0 21.0
7.0 28.0
8.0 36.0
9.0 45.0
10.0 55.0
Isto comprova que o stored procedure usp_CalculaSoma está funcionando corretamente. Poderíamos
fazer uma pequena modificação nele. Se executarmos novamente o usp_CalculaSoma, os registros
existentes na tabela SomaNaturais serão mantidos e novos registros serão incluídos. O ideal é que
somente sejam mantidos os registros da última execução. Para isso, basta excluirmos os registros já
existentes. Isto é feito com um comando SQL que exclui todos os registros da tabela SomaNaturais,
antes de entrar na estrutura WHILE. Vamos alterar o stored procedure usp_CalculaSoma para inserir
este comando SQL. Para isso, utilizamos o seguinte comando:
USE NwindAccess
GO
ALTER PROCEDURE usp_CalculaSoma
@numero int
AS
— Elimina os registros da tabela SomaNaturais
DELETE SomaNaturais
— Cria uma variável para controle do laço

DECLARE @contador int

SET @contador = 1
— Cria uma variável para a soma

DECLARE @soma float

SET @soma = 0
WHILE (@contador<=@numero)
BEGIN
SET @soma = @soma + @contador
INSERT INTO SomaNaturais VALUES (@contador,@soma)
SET @contador = @contador + 1
END
DEFININDO PARÂMETROS DE SAÍDA (OU DE RETORNO) PARA UM STORED PROCEDURE

Assim como podemos passar valores, na forma de parâmetros de entrada, também podemos
receber valores do stored procedure, na forma de parâmetros de saída. Para definir que um
parâmetro é de saída, basta colocar a palavra OUTPUT após a definição do tipo do parâmetro,
como no exemplo a seguir:
CREATE PROCEDURE usp_ParamSaida @paramsaida int OUTPUT
Podemos ter um ou mais parâmetros de saída. Nos comandos que definem o stored procedure atribuímos
um valor ao parâmetro de saída, utilizando o comando SET. Ao ser executado o stored procedure, o
SQL Server retorna o valor associado com um ou mais parâmetros de saída.
Exemplo: Criar um stored procedure que retorna o valor médio dos pedidos para um país que é passado
como parâmetro de entrada. Criar o stored procedure no Banco de Dados NwindAccess, com o nome
de usp_MédiaPedidosPaís.
Para criar o stored procedure usp_MédiaPedidosPaís, utilizamos o seguinte comando:
USE NwindAccess
GO
CREATE PROCEDURE usp_MédiaPedidosPaís
@país varchar(15),
@média float OUTPUT
AS
SET @média= (SELECT AVG(([Quantidade]*[PreçoUnitário]) * (1-[Desconto])) AS Media
FROM [Pedidos]INNER JOIN [Detalhes do Pedido]
ON [Pedidos].[NúmeroDoPedido] = [Detalhes do Pedido].[NúmeroDoPedido]
WHERE ([PaísDeDestino]=@país))
Observe que executamos um comando SELECT que calcula a média para o país passado no parâmetro
de entrada @país. O resultado deste comando SELECT é atribuído à variável de saída @média. Vamos à
execução deste stored procedure:
DECLARE @Resultado float

EXEC usp_MédiaPedidosPaís “Brasil”, @Resultado OUTPUT
PRINT (@Resultado)
Será retornado o seguinte resultado:
526.728
Algumas observações importantes, sobre este exemplo:
♦ Temos que especificar o parâmetro de saída tanto na criação como na execução do stored
procedure, conforme indicado no exemplo:
EXEC usp_MédiaPedidosPaís “Brasil”, @Resultado OUTPUT
O stored procedure é executado e o valor de retorno é armazenado na variável @resultado. Depois

utilizamos o comando Print para exibir o valor desta variável.
♦ O número máximo de parâmetros – incluindo parâmetros de entrada e saída – é 1024.
Agora execute o seguinte comando:
DECLARE @Resultado float

EXEC usp_MédiaPedidosPaís “EUA”, @Resultado OUTPUT
PRINT (@Resultado)
Será retornado o seguinte resultado:
697.684
EXCLUINDO UM STORED PROCEDURE

Para excluir um stored procedure, executamos o comando DROP PROCEDURE.
Por exemplo, para excluir o stored procedure usp_MédiaPedidosPaís, criado no exemplo anterior,
DROP PROCEDURE usp_MédiaPedidosPaís
Podemos excluir mais do que um stored procedure, passando o nome dos vários stored procedures a
serem excluídos, separando o nome por vírgulas, conforme indicado no exemplo a seguir:
DELETE PROCEDURE proc1, proc2, ..., procn
CRIANDO STORED PROCEDURES COM O SQL SERVER MANAGEMENT STUDIO

Podemos utilizar o SQL Server Management Studio para criar stored procedures.
CRIANDO STORED PROCEDURES COM A OPÇÃO NEW STORED PROCEDURES

O menu New stored procedure é acessado clicando com o botão direito do mouse na opção Program-
mability -> stored procedures, do Banco de Dados onde será criado o stored procedure.
Ao clicarmos na opção New stored procedure, surge a janela indicada na Figura 10.5.
Nesta janela definimos o nome do stored procedure, no campo Stored procedure name.
A criação do stored procedure se resume a definição de seus comandos. Assim, temos que conhecer a
linguagem T-SQL, pois, mesmo utilizando a opção New stored procedure, teremos que digitar os
comandos, não tem outro jeito.
Por exemplo, para criar um stored procedure chamado usp_PedidosBrAlAr, definiríamos os comandos
de criação, conforme indicado na Figura 10.6.
Para verificar se a sintaxe dos comandos está correta, clique com o botão direito do mouse em qualquer
uma das linhas de comando e, no menu de opções que é exibido, clique em Check Sintax. Se os
comandos estiverem corretos, será emitida a mensagem indicada na Figura 10.7.
Figura 10.5 Janela para criação de um novo stored procedure.
Figura 10.6 Criando o stored procedure usp_PedidosBrAlAr.
Figura 10.7 Syntax dos comandos – OK.
Uma vez definidos os comandos que farão parte do stored procedure, pressione Ctrl+S para salvá-lo e
feche a janela de criação do stored procedure (clique no botão x mais de baixo). O stored procedure,
recém-criado, já deve aparecer na lista de stored procedures do Banco de Dados. Caso isso não aconteça,
dê um clique na opção stored procedures e pressione a tecla F5 para atualizar a listagem.
Não temos como executar o stored procedure utilizando a interface do Enterprise Manager. Para testar
o usp_PedidosBrAlAr, abra a janela de execução de comandos T-SQL e execute o seguinte comando:
USE NwindAccess
EXEC usp_PedidosBrAlAr
Serão retornados apenas os pedidos para o Brasil, Alemanha e Argentina.
Você pode renomear um stored procedure. Para isso, dê um clique com o botão direito do mouse no stored
procedure e, no menu que surge, dê um clique em Rename. Digite o novo nome e pressione ENTER.
Se você renomear um stored procedure que está sendo chamado dentro de outros stored procedures, ou que está sendo chamado dentro de
NOTA
uma aplicação, os stored procedures e as aplicações que chamam o stored procedure renomeado terão que ser atualizados, caso contrário
deixarão de funcionar corretamente.
VERIFICANDO INFORMAÇÕES SOBRE OS STORED PROCEDURES DE UM BANCO DE DADOS

Existem algumas System stored procedures que nos fornecem informações sobre os stored procedures
existentes em um Banco de Dados.
O COMANDO SP_HELP
Podemos utilizar o stored procedure sp_help, para obter informações sobre qualquer objeto do Banco
de Dados. A sintaxe para este comando é a seguinte:
exec sp_help nome_do_stored_procedure.
Por exemplo, para obter informações sobre o stored procedure usp_PedidosBrAlAr, utilizamos o seguinte
comando:
USE NwindAccess
exec sp_help usp_PedidosBrAlAr
Serão retornadas as seguintes informações:
Name Owner Type Created_datetime

usp_PedidosBrAlAr dbo stored procedure 2005-05-28 19:48:32.123
O COMANDO SP_HELPTEXT
Podemos utilizar o stored procedure sp_helptext, para exibir os comandos do stored procedure, desde que
este não tenha sido criado com a opção WITH ENCRYPTION. A sintaxe para este comando é a seguinte:
exec sp_helptext nome_do_stored_procedure
Por exemplo, para obter informações sobre os comandos do stored procedure usp_PedidosBrAlAr,
USE NwindAccess
exec sp_helptext usp_PedidosBrAlAr
Serão retornadas as seguintes informações:
Text
CREATE PROCEDURE [usp_PedidosBrAlAr] AS
SELECT * From Pedidos
WHERE PaísDeDestino IN (‘Brasil’,‘Argentina’,‘Alemanha’)
ORDER BY PaísDeDestino
ou seja, exatamente os comandos que definem o stored procedure.
O COMANDO SP_STORED_PROCEDURES
Este comando simplesmente retorna uma listagem dos stored procedures existentes no Banco de
Dados atual.
Por exemplo, para obter uma listagem de todos os stored procedures do Banco de Dados NwindAccess,
execute o seguinte comando:
USE Northwind
exec sp_stored_procedures
Com isto, encerramos o nosso estudo básico sobre stored procedures. Existem livros inteiros sobre a criação
de stored procedures e a linguagem T-SQL. No Books OnLine, existe uma referência completa da linguagem
T-SQL, a qual é acessada através da opção: SQL Server Language Reference -> Transact-SQL Reference.
Agora vamos ao estudo de triggers.
DESENVOLVIMENTO EM: TEORIA E DESENVOLVIMENTO

DE TRIGGERS NO SQL SERVER 2005
PRÉ-REQUISITOS
♦ Noções sobre integridade de dados e os tipos de integridade de dados existentes no SQL Server 2005.
METODOLOGIA
♦ Apresentação do conceito de triggers e dos principais comandos para a criação e utilização de triggers.
TÉCNICA
♦ Utilização da janela de execução de comandos T-SQL e do SQL Server Management Studio para a criação e execução de triggers.
Uma trigger é um tipo especial de stored procedure, que é executado automaticamente, quando
ocorrem operações INSERT, UPDATE ou DELETE, na tabela na qual a trigger foi configurada.
Chamamos este executar automaticamente de “disparar a trigger”. Podemos ter triggers associadas
com uma ou mais das operações que alteram dados. Por exemplo, podemos ter uma trigger
associada com a operação INSERT, porém não ter nenhuma trigger associada com as operações
UPDATE e DELETE.
Triggers somente são executadas automaticamente, não podendo ser executadas através da utilização
do comando Exec. Uma trigger é sempre associada a uma tabela, porém os comandos que formam a
trigger podem acessar dados de outra tabela do mesmo Banco de Dados. Por exemplo, podemos criar
uma trigger para a operação INSERT na tabela Detalhes do Pedido. Sempre que for inserido um novo
item de pedido (operação INSERT) será disparada uma trigger que atualiza o nível de estoque do produto
que está sendo vendido.
Com o uso de triggers, podemos definir regras mais complexas do que com a utilização de uma
constraint do tipo CHECK. Estas regras mais complexas são conhecidas como “Regras do Negócio”,
ou seja, um conjunto de regras que define relações entre os dados do Banco de Dados. Estas relações
representam regras do mundo real. Por exemplo, podemos ter uma regra que impeça um gerente de
aprovar financiamentos maiores do que um determinado valor. Neste caso, quando o gerente for
inserir um novo financiamento no Banco de Dados, podemos criar uma trigger que verifica se o
valor do financiamento está dentro do limite definido pela empresa, para este gerente. Caso o valor
esteja dentro do limite, o registro é inserido no Banco de Dados; caso contrário, o registro é rejeitado
e uma ação, como por exemplo enviar um e-mail para o chefe imediato, pode ser automaticamente
executada pela trigger.
Vamos tornar um pouco mais complexa a nossa regra de negócio do exemplo anterior. Vamos supor
que o gerente não tenha um limite individual para cada financiamento que aprova, mas sim um
limite mensal, isto é, a soma de todos os empréstimos aprovados por um gerente, dentro do mês
corrente, não pode ultrapassar um determinado valor. Esta regra, aparentemente complexa, também
pode ser implementada através de uma trigger. Quando o gerente tenta inserir um novo empréstimo,
a trigger faz a totalização dos empréstimos já feitos pelo gerente, durante o mês corrente, já incluindo
o valor do empréstimo que está sendo inserido. Se o somatório estiver abaixo do limite definido pelo
gerente, o novo empréstimo é inserido, caso contrário o novo empréstimo será rejeitado e uma ação
será tomada pela trigger.
Além de regras de negócios, podemos utilizar triggers para modificações em cascata, em tabelas do
Banco de Dados. Por exemplo, suponha que você esteja excluindo um cliente da tabela Clientes.
Podemos criar uma trigger associada à ação DELETE da tabela Clientes, a qual exclui todos os pedidos
(na tabela Pedidos) do cliente que está sendo excluído. Na tabela Pedidos, podemos ter uma trigger
associada à ação DELETE, que exclui todos os itens, na tabela Detalhes do Pedido, do pedido que está
sendo excluído da tabela Pedidos. Estes itens estão gravados em uma tabela Detalhes do pedido. Além
da exclusão, também podemos criar triggers que façam atualização em cascata. Por exemplo, se
alterarmos o código de um cliente, na tabela Clientes (ação UPDATE), podemos fazer com que uma
trigger altere o código nos pedidos do cliente, na tabela Pedidos.
Uma trigger somente é executada após o comando que a “disparou” ter sido completado. Por exemplo, se tivermos uma trigger associada
NOTA
com uma ação INSERT, a trigger não será disparada enquanto a ação INSERT não tiver sido concluída. Porém, uma trigger é incluída como
parte de uma transação, juntamente com o comando que a disparou. No nosso exemplo, o comando INSERT e a trigger estariam no contexto
de uma transação. Se o comando INSERT violar alguma regra definida pela trigger, podemos utilizar um roll back na trigger, para cancelar
a inserção dos dados feitos pelo comando INSERT. Este mecanismo é ilustrado na Figura 10.8.
Figura 10.8 Trigger no contexto de uma transação.
Se o comando, que está sendo executado (INSERT, DELETE ou UPDATE), violar a definição de uma
constraint definida para uma das colunas da tabela, a trigger não irá disparar. Além disso, uma trigger
dispara uma única vez para cada comando, mesmo que o comando altere dados em diversos registros.
Por exemplo, um comando UPDATE que aumenta em 20% o valor do campo PreçoUnitário de todos
os registros. Para este comando, a trigger associada irá disparar uma única vez e não uma vez para cada
registro que for alterado.
Podemos ter mais do que uma trigger definida para uma mesma ação – INSERT, UPDATE ou DELETE. Não
existe uma ordem definida para a execução de múltiplas triggers associadas com o mesmo comando. A
utilização de múltiplas triggers para o mesmo comando não é uma prática muito comum e não é recomendada,
pois torna difícil o acompanhamento e o gerenciamento da lógica associada ao Banco de Dados.
O usuário dono da tabela (dbo) e membros das roles sysadmin, db_owner e db_ddladmin têm permissão
para criar e excluir triggers. Estas permissões não podem ser transferidas para outros usuários e roles.
Além disso, o usuário dono da trigger deve ter permissão para executar todos os comandos que fazem
parte da trigger. Por exemplo, se a trigger precisa excluir dados em uma determinada tabela, o usuário
que a cria precisa ter permissão para excluir dados nesta tabela. Se o usuário que criou a trigger não
tiver permissão para executar qualquer um dos comandos que a compõem, a trigger irá falhar e um roll
back será utilizado para reverter as alterações feitas pela trigger e pelo comando que disparou.
No SQL Server 2005, temos cinco tipos de triggers, conforme o comando com a qual a mesma é
associada:
♦ DELETE.
♦ INSERT.
♦ UPDATE.
♦ INSTEAD OF.
♦ AFTER.
♦ .NET (novidade no SQL Server 2005).
Uma trigger dos tipos DELETE, INSERT e UPDATE é disparada quando os respectivos comandos são
executados. Uma trigger do tipo INSTEAD OF é disparada em substituição a uma das triggers DELETE,
INSERT ou UPDATE. Podemos criar triggers INSTEAD OF relacionadas com qualquer um dos comandos
– DELETE, INSERT ou UPDATE. Já uma trigger do tipo AFTER é disparada após todos os comandos de
uma trigger associada com um DELETE, INSERT ou UPDATE terem sido executados. Se tivermos múltiplas
triggers AFTER definidas em uma determinada tabela, para um determinado conjunto de comandos,
podemos especificar a ordem de execução das diversas triggers do tipo AFTER.
Uma novidade introduzida com o SQL Server 2000 é que podemos especificar triggers em views que
alteram dados. Já o SQL Server 2005 introduziu as chamadas .NET Triggers. Este tipo de trigger pode ser
tanto do tipo INSTEAD OF quanto do tipo AFTER. A novidade é que um .NET Trigger, ao invés de
executar comandos T-SQL, é capaz de chamar código de um módulo .NET, o qual foi instalado no SQL
Server 2005. A integração do SQL Server 2006 com o Framework .NET é, sem dúvidas, a principal novidade
de programação do SQL Server 2005. Foge ao escopo deste livro abordar todas as possibilidades de
desenvolvimento da integração entre o SQL Server 2005 e o .NET. Existem livros inteiros, só sobre esta
integração. Para começar a estudar esta integração, eu sugiro o seguinte livro: “A First Look at SQL Server
2005 for Developers, Editora Addison Wesley, autores: Bob Beauchemin, Niels Berglund e Dan Sullivan.
Os comandos que compõem uma trigger têm acesso a duas tabelas especiais. Estas tabelas são
chamadas de “deleted table” e “inserted table”. Estas tabelas somente existem na memória do
servidor, não sendo gravadas em disco. Os registros destas tabelas somente são acessíveis durante
a execução da trigger. Para fazer referência a estas tabelas, dentro de uma trigger, utilizamos os
nomes deleted e inserted.
A tabela deleted armazena cópias dos registros afetados por um comando DELETE ou UPDATE (armazena
o registro antes das alterações). Quando um comando DELETE ou UPDATE é executado, os registros
são excluídos da tabela em questão e armazenados na tabela deleted. No caso de registros que estão
sendo alterados, na tabela deleted fica uma cópia do registro antes das alterações. Desta forma, a tabela
que está sendo alterada e a tabela deleted jamais terão registros coincidentes.
A tabela inserted armazena cópias dos registros afetados por um comando INSERT ou UPDATE. Os
registros na tabela inserted são cópias dos novos registros da tabela que disparou a trigger.
Bem, já vimos bastante teoria, agora é o momento de aprendermos a criar e a testar o funcionamento
de triggers.
CRIANDO TRIGGERS COM COMANDOS T-SQL

Para criar triggers utilizamos o comando CREATE TRIGGER.
Sintaxe básica para o comando CREATE TRIGGER:
CREATE TRIGGER nome_da_trigger

ON {tabela ou view}
[WITH ENCRYPTION]
{FOR | AFTER | INSTEAD OF}
{[DELETE] [,] [INSERT] [,] [UPDATE]}
[WITH APPEND]
[NOT FOR REPLICATION]
AS
comando 1
comando 2
comando 3
...
comando n
Com este comando podemos criar triggers associadas com qualquer dos comandos básicos – DELETE,
INSERT ou UPDATE –, e também triggers do tipo INSTEAD OF e AFTER. Uma trigger pode ser associada
com mais de uma opção, por exemplo, podemos criar uma trigger que dispara em resposta a um
comando INSERT e também a um comando UPDATE.
Nos comandos que definem a trigger (comando 1, ..., comando n), podemos incluir a maioria dos
comandos, inclusive as estruturas IF...ELSE e WHILE. Não são permitidos os seguintes comandos:
♦ ALTER DATABASE
♦ CREATE DATABASE
♦ DISK INIT
♦ DISK RESIZE
♦ DROP DATABASE
♦ LOAD DATABASE
♦ LOAD LOG
♦ RECONFIGURE
♦ RESTORE DATABASE
♦ RESTORE LOG
NOTA
Ao criarmos uma trigger, informações sobre a trigger são armazenadas nas tabelas de sistema, sysobjects e syscomments.
Vamos ver alguns exemplos práticos. À medida que formos implementando os exemplos, vou explicando
novos conceitos e comandos que forem sendo utilizados.
Exemplo prático 1: Vamos iniciar com um exemplo simples. Vamos criar uma trigger que evita que
sejam inseridos novos clientes na tabela Clientes, do Banco de Dados NwindAccess, em que o campo
País seja igual a China ou Indonésia. Esta trigger será criada para a ação INSERT. Vamos chamá-la de
tg_ExcluiChinaIndonésia. Esta trigger verifica se o campo País é igual a China ou Indonésia. Em caso
afirmativo, um roll back será chamado para cancelar a inserção do registro, caso contrário a transação
será concluída.
Para criar a trigger tg_ExcluiChinaIndonésia, siga os passos indicados a seguir:
Banco de Dados atual.
USE NwindAccess
GO
CREATE TRIGGER tg_ExcluiChinaIndonésia
ON Customers
FOR INSERT
AS
IF EXISTS(SELECT * FROM inserted WHERE Country IN (‘China’,‘Indonésia’))
PRINT ‘PAÍS PROIBIDO !!!’
ELSE
PRINT ‘PAÍS PERMITIDO’
NOTA
Observe a utilização da função EXISTS(comando SQL). Esta função retorna verdadeiro, caso o comando SQL retorne algum registro, e falso,
caso contrário.
Agora vamos testar o funcionamento da trigger, utilizando um comando INSERT.

USE NwindAccess
GO
INSERT INTO [Clientes]
( [CódigoDoCliente],[NomeDaEmpresa],[NomeDoContato],[CargoDoContato],
[Endereço],[Cidade],[Região],[CEP], [País], [Telefone], [Fax])
VALUES
(‘xxxxx’,‘Empresa ABC Ltda.’,‘José da Silva’,‘Gerente’,
‘Rua Riachuelo – 80’,‘Santa Maria’,‘Centro’,‘97050-010’,‘China’,‘220-1335’,‘220-1314’)
PAÍS PROIBIDO !!!
(1 row(s) affected)
Mas, ao invés da mensagem “PAÍS PROIBIDO !!!’, nós queremos que a inserção do registro seja cancelada,
caso o país seja China ou Indonésia. Para isso, vamos alterar a trigger tg_ExcluiChinaIndonésia. Ao
invés da mensagem, vamos dar um roll back. Como a operação INSERT e a trigger ocorrem no contexto
de uma transação, conforme descrito anteriormente, ao cancelarmos a transação iremos também cancelar
a trigger e também o comando INSERT.
Para alterar uma trigger, utilizamos o comando ALTER TRIGGER. A sintaxe básica para este comando é
a seguinte:
USE NwindAccess
GO
ALTER TRIGGER nome_trigger
ON nome_tabela
FOR { INSERT | UPDATE | DELETE }
AS
comando 1
comando 2
comando 3
...
comando n
6. Para alterar a trigger tg_ExcluiChinaIndonésia, utilizamos o seguinte comando:

USE NwindAccess
GO
ALTER TRIGGER tg_ExcluiChinaIndonésia
ON Clientes
FOR INSERT
AS
IF EXISTS(SELECT * FROM inserted WHERE País IN (‘China’,‘Indonésia’))
BEGIN
PRINT ‘INSERÇÃO DO REGISTRO CANCELADA !!!!!!’
ROLLBACK
END
ELSE
Agora vamos tentar inserir um cliente em que o campo Country é igual a Indonésia. Vamos
verificar se a trigger foi disparada e depois daremos um SELECT para verificar se a inserção do
registro foi realmente cancelada.
Para inserir um registro em que o país é Indonésia, execute o seguinte comando:

USE NwindAccess
GO
VALUES
(‘ABC12’,‘Empresa 123 Ltda.’,‘Para Pedro’,‘Gerente’,
‘Rua Riachuelo – 444’,‘Porto Alegre’,‘Centro’,‘97051-230’,‘Indonésia’,‘220-4444’,’223-1344')
INSERÇÃO DO REGISTRO CANCELADA !!!!!!
7. Vamos conferir se o comando INSERT realmente foi cancelado. Para verificar se o registro para
a Indonésia não foi inserido, execute o seguinte comando:
USE Northwind
GO
SELECT * FROM Customers
WHERE CustomerID=‘ABC12’
O resultado será:
(0 row(s) affected)
Isto comprova que o comando INSERT, para o cliente ABC12, foi realmente cancelado.
Veja que agora temos uma trigger, que dispara sempre que tentarmos inserir um registro na tabela
Clientes. Esta trigger verifica se o registro que está sendo inserido possui um valor igual a China ou
Indonésia, no campo País. Caso o registro tenha um destes valores no campo País, a inserção do novo
registro será cancelada através da utilização de um comando ROLLBACK. O comando ROLLBACK
cancela a execução da transação, da qual fazem parte a trigger e o comando INSERT que disparou a
trigger. Como o comando INSERT faz parte da transação que está sendo cancelada, este é cancelado e
a inserção do registro também.
8. Mantenha aberta a janela de execução de comandos T-SQL.
Com este exemplo vimos, na prática, a ação de uma trigger. Agora, vamos a mais alguns exemplos,
para ilustrar outros tipos de triggers.
Exemplo prático 2: Vamos supor que, por ordem da administração, não devem ser feitas alterações
nem inserções na tabela Clientes. Para garantir que esta norma seja respeitada, você deve implementar
uma trigger, que dispare em resposta aos comandos INSERT e UPDATE na tabela Clientes. Esta trigger
deve emitir um aviso de que as alterações e inserções de clientes estão suspensas e registrar em uma
tabela, chamada TentouAlterar, o nome do cliente que se tentou alterar ou inserir e também o nome
do usuário logado que tentou fazer a inserção ou alteração. Vamos chamar esta trigger de
tg_NãoAlteraInsereCliente. A tabela TentouAlterar terá a estrutura indicada na Tabela 10.4.
Tabela 10.4 Estrutura da tabela TentouAlterar.
Campo Tipo
Cliente nvarchar(50)
Usuário char(30)
Para criar a trigger tg_NãoAlteraInsereCliente, siga os passos indicados a seguir:
1. Você já deve estar com a janela de execução de comandos T-SQL aberta. O primeiro passo é
criar a tabela TentouAlterar. Para isso, execute o seguinte comando:
USE NwindAccess
CREATE TABLE TentouAlterar
(
Cliente nvarchar(50) NOT NULL,
Usuário char(30) NOT NULL
)
2. Para criar a trigger tg_NãoAlteraInsereCliente, utilize o seguinte comando:

USE NwindAccess
GO
CREATE TRIGGER tg_NãoAlteraInsereCliente
ON Clientes
FOR INSERT,UPDATE
AS
— Variável que será utilizada na trigger

DECLARE @NomeCliente nvarchar(50)
— Verificamos se foi feita uma alteração.

IF EXISTS(SELECT * FROM deleted)
BEGIN
— Defino o valor da variável @NomeCliente
SET @NomeCliente = (SELECT NomeDaEmpresa FROM deleted)
INSERT INTO [TentouAlterar]
([Cliente],[Usuário])
VALUES
(@NomeCliente,CURRENT_USER)
PRINT ‘VOCÊ NÃO PODE ALTERAR O REGISTRO DE UM CLIENTE !!!!’
ROLLBACK
END
— Verifico se foi feita uma inserção.

ELSE
IF EXISTS(SELECT * FROM inserted)
BEGIN
SET @NomeCliente = (SELECT NomeDaEmpresa FROM inserted)
VALUES
PRINT ‘VOCÊ NÃO PODE INSERIR NOVOS CLIENTES!!!!’
ROLLBACK
END
ELSE
BEGIN
PRINT ‘ESTA MENSAGEM NUNCA SERÁ EXIBIDA !!!!’
END
Observe que, na definição da trigger, associamos a trigger com as ações INSERT e UPDATE – FOR INSERT,UPDATE. Também observe a
NOTA
utilização, novamente, da função EXISTS. Também utilizamos a função CURRENT_USER para capturar o nome do usuário atualmente logado
no SQL Server e que executou o comando INSERT ou UPDATE.

USE NwindAccess
GO
VALUES
(‘123hh’,‘Empresa hhh Ltda.’,‘José Pereira’,‘Gerente’,
Você receberá a seguinte mensagem:
E agora, José? A mensagem não deveria ser:
‘VOCÊ NÃO PODE INSERIR NOVOS CLIENTES!!!!’
4. Acontece que temos uma outra trigger, criada anteriormente, chamada

tg_ExcluiChinaIndonésia, a qual também está associada com a ação INSERT. Foi esta trigger
que disparou, emitiu a mensagem INSERÇÃO DO REGISTRO CANCELADA !!!!!! e deu um roll
back na transação. Vamos excluir esta trigger. Para excluir uma trigger, utilizamos o comando
DROP TRIGGER nome_trigger. Execute o seguinte comando:
USE NwindAccess
GO
DROP TRIGGER tg_ExcluiChinaIndonésia
5. Agora execute novamente o seguinte comando INSERT:

USE NwindAccess
GO
VALUES
(‘123hh’,‘Empresa hhh Ltda.’,‘José Pereira’,‘Gerente’,
Agora a mensagem é a seguinte:

(1 row(s) affected)
VOCÊ NÃO PODE INSERIR NOVOS CLIENTES!!!!
Esta mensagem é emitida pela trigger tg_NãoAlteraInsereCliente, a qual detectou que tentamos executar
uma operação INSERT, na tabela Clientes e impediu que a operação fosse executada.
6. Vamos conferir se a operação realmente foi cancelada. Execute o seguinte comando:

USE NwindAccess
GO
SELECT * FROM Clientes
WHERE NomeDaEmpresa=’123hh’
O resultado deve ser:
(0 row(s) affected)
Isto comprova que o registro não foi inserido.
Agora vamos testar se a trigger está realmente funcionando para alterações UPDATE.

USE NwindAccess
GO
— Executo o UPDATE para disparar a trigger.
UPDATE [Clientes]
SET [CódigoDoCliente] = ‘XXX12’,
[NomeDaEmpresa] = ‘XXX Ltda.’,
[NomeDoContato] = ‘José Costa’,
[CargoDoContato] = ‘Gerente’,
[Endereço] = ‘Rua ABC – 123’,
[Cidade] = ‘Lajeado’,
[Região] = ‘Central’,
[CEP] = ‘11111-111’,
[País] = ‘Brazil’,
[Telefone] = ‘111-1111’,
[Fax] = ‘111-1111’
WHERE [CódigoDoCliente]=‘RICAR’

(1 row(s) affected)
VOCÊ NÃO PODE ALTERAR O REGISTRO DE UM CLIENTE !!!!
Esta mensagem é emitida pela trigger tg_NãoAlteraInsereCliente, a qual detectou que tentamos executar
uma operação UPDATE e impediu que a operação fosse executada.
8. Vamos conferir se a operação realmente foi cancelada. Execute o seguinte commando:

USE NwindAccess
GO
SELECT * FROM Clientes
WHERE CódigoDoCliente=‘XXX12’
(0 row(s) affected)
9. Isto comprova que o registro não foi alterado. Neste caso inclusive as alterações em cascata, feitas
na tabela Pedidos, foram canceladas. Para comprovar este fato, execute o seguinte comando:
USE NwindAccess
GO
WHERE CódigoDoCliente=’XXX12'
(0 row(s) affected)
10. Mantenha a janela de execução de commandos T-SQL aberta.
Com estes exemplos, podemos ver como uma trigger é disparada e como a trigger interage com as
tabelas de um Banco de Dados. A utilização de triggers abre um leque de opções para a implementação
de regras de negócio. Quanto mais conhecermos da linguagem T-SQL, mais resultados práticos
poderemos obter com a utilização de triggers. Para uma referência completa da linguagem T-SQL,
consulte o tópico SQL Server Language Reference -> Transact-SQL Reference, no Books OnLine.
Agora vamos aprender a criar triggers utilizando o SQL Server Management Studio.
CRIANDO TRIGGERS COM O SQL SERVER MANAGEMENT STUDIO

Podemos criar, alterar e excluir triggers, utilizando o SQL Server Management Studio. Por exemplo,
para gerenciar as triggers da tabela Clientes, do Banco de Dados NwindAccess, da instância
SERVIDOR\SQL2005, siga os passos indicados a seguir:

2. Na janela Object Explorer, navegue até a tabela Clientes, do Banco de Dados NwindAccess, da
3. Dê um clique no sinal de + lado da tabela Clientes, para exibir as opções disponíveis. Observe
que uma das opções é Triggers.
4. Clique no sinal de + ao lado da opção Triggers, para exibir as triggers da tabela Clientes.
Figura 10.9 Janela para a criação de uma nova trigger.
5. Para criar uma nova trigger, clique com o botão direito do mouse na opção Triggers. No menu
de opções que é exibido clique em New Trigger. Será aberta a janela para a criação de uma nova
trigger, conforme indicado na Figura 10.9. Nesta janela você informa o nome da Trigger, o tipo
After ou Instead of, e a qual ou quais eventos ela irá responder: INSERT, UPDATE ou DELETE.
Você também define algumas outras opções da trigger, tais como se ela será habilitada ou não,
se os comandos serão criptografados ou não e se ela deve ser replicada ou não. Além destas
opções, na parte de baixo, você define os comandos da trigger.
6. Após definir as opções e os comandos da trigger, pressione Ctrl+S para salvar a trigger e feche a
janela de criação (clique no botão x mais de baixo).
7. Você também pode excluir uma trigger usando o SQL Server Management Studio. Para isso
basta clicar na trigger e, no menu de opções que é exibido, clicar em Delete. Será exibida uma
janela de confirmação. Clique em OK para confirmar a exclusão.
8. Você também pode modificar uma trigger usando o SQL Server Management Studio. Para isso
basta clicar na trigger e, no menu de opções que é exibido, clicar em Modify. Será aberta a
janela com as configurações e os comandos da trigger. Faça as modificações desejadas, pressione
Ctrl+S para salvar e feche a janela da trigger.
Conforme podemos constatar, a criação, exclusão e modificação de triggers com o SQL Server Manage-
ment Studio não difere muito da criação com a janela de comandos T-SQL. Em resumo, temos que
conhecer a linguagem T-SQL para que possamos criar ou modificar uma trigger.
MAIS ALGUNS COMANDOS RELACIONADOS COM TRIGGERS

Vamos ver mais alguns comandos relacionados com triggers. Podemos executar estes comandos na
janela de execução de comandos T-SQL.
O COMANDO SP_HELPTEXT
Este comando retorna o código da trigger. A sintaxe para este comando é a seguinte:
exec sp_helptext nome_trigger1
Se executarmos o seguinte comando:
USE NwindAccess
GO
exec sp_helptext tg_NãoAlteraInsereCliente
obteremos o seguinte resultado:
CREATE TRIGGER tg_NãoAlteraInsereCliente

ON Clientes
FOR INSERT,UPDATE
AS
— Variávies que serão utilizadas na trigger
DECLARE @NomeCliente nvarchar(50)
— Verificamos se foi feita uma alteração.
IF EXISTS(SELECT * FROM deleted)
BEGIN
SET @NomeCliente = (SELECT NomeDaEmpresa FROM deleted)
VALUES
PRINT ‘VOCÊ NÃO PODE ALTERAR O REGISTRO DE UM CLIENTE !!!!’
ROLLBACK
END
— Verifico se foi feita uma inserção.
ELSE
IF EXISTS(SELECT * FROM inserted)
BEGIN
SET @NomeCliente = (SELECT NomeDaEmpresa FROM inserted)
VALUES
PRINT ‘VOCÊ NÃO PODE INSERIR NOVOS CLIENTES!!!!’
ROLLBACK
END
ELSE
BEGIN
PRINT ‘ESTA MENSAGEM NUNCA SERÁ EXIBIDA !!!!’
END
Este é exatamente o código da trigger.
O COMANDO SP_HELPTRIGGER
Este comando retorna o nome das triggers existentes em uma tabela. A sintaxe para este comando é a
seguinte:
exec sp_helptrigger nome_tabela
Se executarmos o seguinte comando:
USE NwindAccess
GO
exec sp_helptrigger Clientes
obteremos o seguinte resultado:
trigger_name trigger_owner isupdate isdelete isinsert isafter isinsteadof

tg_NãoAlteraInsereCliente dbo 1 0 1 1 0
As colunas is... indicam o tipo de trigger. Por exemplo, isupdate=1 indica que a trigger é disparada
por um comando UPDATE; isdelete=1 indica que a trigger é disparada por um comando DELETE
e assim por diante.
HABILITANDO E DESABILITANDO TRIGGERS

Podemos desabilitar temporariamente uma trigger. Para desabilitar uma trigger utilizamos o comando:
DISBLE TRIGGER nome_da_trigger
Por exemplo, para desabilitar a trigger tg_NãoAlteraInsereCliente, da tabela Customers, utilizamos o

seguinte comando:
USE NwindAccess
GO
DISABLE TRIGGER tg_NãoAlteraInsereCliente
Para habilitar novamente a trigger tg_NãoAlteraInsereCliente, utilizamos o seguinte comando:
USE NwindAccess
GO
ENABLE TRIGGER tg_NãoAlteraInsereCliente
Poderíamos desabilitar uma trigger, por exemplo, quando estamos fazendo uma importação de um
grande volume de dados para uma determinada tabela. Se estivermos certos de que os dados atendem
às regras do negócio, podemos desabilitar a trigger durante a importação, para evitar que a trigger seja
disparada a cada novo registro que é importado, o que pode agilizar, bastante, a importação. Uma vez
finalizada a importação, voltamos a habilitar a trigger.
Com isso encerramos o nosso estudo de triggers. Vamos agora estudar alguns comandos avançados da
linguagem T-SQL.
DESENVOLVIMENTO EM: COMANDOS AVANÇADOS DA LINGUAGEM T-SQL

PRÉ-REQUISITOS
METODOLOGIA
♦ Apresentação de alguns comandos avançados da linguagem T-SQL.
TÉCNICA
♦ Criação de exemplos que utilizam os comandos avançados apresentados.
Neste item, vamos tratar de alguns comandos e técnicas avançadas da linguagem T-SQL. Falaremos
sobre os seguintes itens:
♦ Pesquisando múltiplas tabelas.
♦ Utilizando subconsultas.
PESQUISANDO DADOS EM MÚLTIPLAS TABELAS

É comum a situação em que, para construir uma view (consulta), temos que acessar dados de duas ou
mais tabelas. Por exemplo, se quisermos uma listagem com o nome do funcionário, o número do
pedido, a data do pedido e o país de destino, teremos que acessar dados das seguintes tabelas do Banco
de Dados NwindAccess.
♦ Clientes
♦ Pedidos
♦ Detalhes do Pedido
Para que possamos acessar dados de duas ou mais tabelas, em uma consulta, utilizamos uma cláusula
JOIN. Um JOIN é uma operação que nos permite acessar dados de duas ou mais tabelas. O JOIN é
efetuado com base em uma coluna que seja comum a duas ou mais tabelas. Por exemplo, se fizermos
um join entre as tabelas Pedidos e Detalhes do Pedido, o join será efetuado através do campo
NúmeroDoPedido, que é o campo que relaciona estas duas tabelas. Na tabela Detalhes do Pedido, o
campo NúmeroDoPedido é utilizado para indicar a qual pedido pertence cada um dos itens.
Vamos a um exemplo de utilização de uso da cláusula JOIN.
Exemplo: Escrever um comando SQL que retorne os campos indicados na Tabela 10.5.
Tabela 10.5 Campos – Tabelas.
Campo Tabela
NúmeroDoPedido Pedidos
DataDoPedido Pedidos
CódigoDoProduto Detalhes do Pedido
PreçoUnitário Detalhes do Pedido
Quantidade Detalhes do Pedido
Esta listagem irá retornar uma linha para cada item de cada pedido, com os campos indicados na
Tabela 10.3. Por exemplo, se um campo tiver cinco itens, serão retornadas cinco linhas, com o mesmo
valor para os campos NúmeroDoPedido e DataDoPedido (que são as informações do cabeçalho do
pedido), e diferentes valores para os demais campos (que são as informações dos itens do pedido). Para
construir a listagem solicitada, utilizamos o seguinte comando:
SELECT [Pedidos].[NúmeroDoPedido], [Pedidos].[DataDopedido], [Detalhes do

Pedido].[CódigoDoproduto],
[Detalhes do Pedido].[PreçoUnitário],[Detalhes do Pedido].[Quantidade]
FROM [Detalhes do Pedido]
JOIN
[Pedidos]
ON
[Detalhes do Pedido].[NúmeroDoPedido] = [Pedidos].[NúmeroDoPedido]
NOTA
Observe que estamos utilizando a sintaxe [NomeDaTabela].[NomeDoCampo].
O resultado parcial, da execução deste comando, é indicado na listagem a seguir:
NúmeroDoPedido DataDoPedido CódigoDoProduto PreçoUnitário Quantity

10248 4/7/1996 11 14 12
10248 4/7/1996 42 9,8 10
10248 4/7/1996 72 34,8 5
10249 5/7/1996 14 18,6 9
10249 5/7/1996 51 42,4 40
10250 8/7/1996 41 7,7 10
10250 8/7/1996 51 42,4 35
10250 8/7/1996 65 16,8 15
Observe que, para cada pedido, aparecem tantas linhas quantos forem os itens do pedido.
Vamos analisar a sintaxe básica do join.
SELECT Campo1, Campo2, ..., Campon

FROM Tabela1
JOIN Tabela2
ON [Tabela1].[CampoComun]= [Tabela2].[CampoComun]
Além do join ligando as duas tabelas, devemos especificar qual o campo em comum nas duas tabelas.
Isto é feito pela cláusula ON.
TIPOS DE JOIN
Existem três tipos de join, conforme listado a seguir:
♦ INNER JOIN: Este é o join padrão, isto é, se não especificarmos o tipo a ser utilizado, será
utilizado um INNER JOIN. A característica do INNER JOIN é que somente são retornados os
registros que têm valores coincidentes nas duas ou mais tabelas, relacionadas através de uma
ou mais cláusulas JOIN. Por exemplo, se tivermos um INNER JOIN ligando as tabelas Clientes
e Pedidos, somente serão retornados os registros para os clientes que têm algum pedido na
tabela Pedidos. Clientes que não efetuaram pedidos (portanto, não têm registros coincidentes
na tabela Pedidos) não farão parte do resultado da operação INNER JOIN. A seguir, um exemplo
de utilização de um INNER JOIN, entre as tabelas Clientes e Pedidos:
SELECT [Clientes].[CódigoDoCliente], [Clientes].[NomeDaEmpresa],
[Clientes].[Cidade],[Pedidos].[NúmeroDoPedido], [Pedidos].[DataDoPedido]
FROM [Clientes] INNER JOIN [Pedidos]
ON [Clientes].[CódigoDoCliente]= [Pedidos].[CódigoDoCliente]
Este comando retorna todos os clientes que têm pedidos e os respectivos pedidos. Se um cliente tiver
dez pedidos, retornarão dez registros para este cliente, um para cada pedido. Clientes que não têm
pedido não aparecerão na listagem.
♦ LEFT OUTER JOIN: Este tipo retorna todos os registros da primeira tabela e os registros
relacionados da segunda tabela. No nosso exemplo, na listagem anterior, se trocarmos o IN-
NER JOIN por um LEFT OUTER JOIN, serão retornados todos os Clientes e os pedidos
relacionados, e também os clientes que não possuem pedidos. Para os que não possuem pedidos,
os campos NúmeroDoPedido e DataDoPedido terão o valor Null. A seguir, temos o comando
que utiliza um LEFT OUTER JOIN:
FROM [Clientes] INNER JOIN [Pedidos]
ORDER BY [Clientes].[CódigoDoCliente]
Na Figura 10.21, podemos observar que foram retornados inclusive os clientes que não possuem pedidos,
o que é indicado pelos valores NULL nos campos NúmeroDoPedido e DataDoPedido.
NOTA
Se você utilizar o Banco de Dados NwindAccess, o qual importamos para o SQL SERVER 2005 em um exemplo anterior, serão retornados
todos os clientes, pois existem pedidos para todos. Para poder exemplificar neste exercício, eu excluí os pedidos para os clientes com os
seguintes códigos:
ALFKI
ANATR
ANTON
AROUT
Figura 10.10 Utilizando LEFT OUTER JOIN.
RIGHT OUTER JOIN: Este tipo retorna todos os registros da segunda tabela e os registros
relacionados da primeira tabela. Um exemplo de RIGHT OUTER JOIN:

FROM [Clientes] RIGHT OUTER JOIN [Pedidos]
ORDER BY [Clientes].[CódigoDoCliente]
Na Figura 10.11, podemos observar que foram retornados todos os pedidos da tabela pedidos, e apenas
os clientes que possuem pedidos, isto é, todos os registros da segunda tabela (Pedidos) e apenas os
registros relacionados da primeira tabela (Clientes).
Figura 10.11 Utilizando RIGHT OUTER JOIN.
JOIN COM MAIS DO QUE DUAS TABELAS

Também podemos fazer um join com mais do que duas tabelas. Sempre o número de joins será igual ao
número de tabelas menos um. Por exemplo, se estivermos relacionando quatro tabelas, teremos três
joins; se estivermos relacionando três tabelas, teremos dois joins, e assim por diante.
Exemplo: Criar uma listagem com os campos indicados na Tabela 10.6.
Tabela 10.6 Campos – Tabelas.
Campo Tabela
CódigoDoCliente Clientes
NomeDaEmpresa Clientes
NúmeroDoPedido Pedidos
DataDoPedido Pedidos
TotalPedido ([Quantidade]*[PreçoUnitário])*(1-[Desconto]) da tabela Detalhes do pedido.
Teremos uma listagem com o código e o nome do cliente, o número, a data e o total do pedido, sendo
que o total é calculado a partir de dados da tabela Detalhes do Pedido. Com isso estamos acessando
campos de três tabelas: Clientes, Pedidos e Detalhes do Pedido. Três tabelas = dois joins.
A seguir temos o comando que retorna a listagem solicitada:

[Pedidos].[NúmeroDoPedido],[Pedidos].[DataDoPedido],
SUM(([Detalhes do Pedido].[Quantidade] * [Detalhes do Pedido].[PreçoUnitário])
* (1 - [Detalhes do Pedido].Desconto)) AS TotalPedido
INNER JOIN
[Pedidos] ON [Detalhes do Pedido].[NúmeroDoPedido] =
[Pedidos].[NúmeroDoPedido]
INNER JOIN
[Clientes] ON [Pedidos].[CódigoDoCliente] = [Clientes].[CódigoDoCliente]
GROUP BY
[Clientes].[CódigoDoCliente], [Clientes].[NomeDaEmpresa],
[Pedidos].[NúmeroDoPedido],[Pedidos].[DataDoPedido]
ORDER BY
[Clientes].[CódigoDoCliente]
Na Figura 10.12, temos a parte inicial do resultado retornado:
Figura 10.12 Utilizando dois Joins no mesmo comando.
Vamos fazer alguns comentários sobre o comando anterior.
Vamos considerar o trecho onde é feito o join entre as três tabelas. Na verdade, o join é feito sempre
entre duas tabelas; fizemos duas a duas, conforme indicado no trecho a seguir:

INNER JOIN
[Pedidos] ON [Detalhes do Pedido].[NúmeroDoPedido] =
[Pedidos].[NúmeroDoPedido]
INNER JOIN
[Clientes] ON [Pedidos].[CódigoDoCliente] = [Clientes].[CódigoDoCliente]
Fizemos o join entre as tabelas [Detalhes do Pedido] e [Pedidos], através do campo [NúmeroDoPedido].
Depois é feito o join entre as tabelas [Pedidos] e [Clientes], através do campo CódigoDoCliente.
Também utilizamos GROUP BY, para agrupar os diversos itens de cada pedido e a função SUM, para calcular
a soma de todos os itens de um mesmo pedido. No final, ordenamos pelo código do cliente – [CódigoDoCliente].
NOTA
No Apêndice, veremos mais alguns detalhes sobre operações join.
UTILIZANDO SUBCONSULTAS
Uma subconsulta é um comando SELECT dentro de outro comando SELECT, ou seja, uma consulta
dentro da outra. Uma consulta pode ser utilizada em qualquer local onde uma expressão seja aceita.
Em alguns casos, podemos obter os mesmos resultados utilizando joins ao invés de subconsultas. Um
detalhe a que devemos estar atentos quando utilizamos subconsultas é em relação ao desempenho. De
uma forma geral, devemos utilizar subconsultas quando quisermos dividir uma consulta complexa,
em uma série de passos mais simples, mas que combinados geram o resultado da consulta complexa.
Alguns detalhes a serem considerados quando utilizamos subconsultas:
♦ Subconsultas devem estar dentro de parênteses.
♦ Podemos ter diversos níveis de subconsultas, isto é, uma consulta dentro da outra, dentro da outra
e assim por diante. Porém, mais uma vez quero chamar atenção para a questão do desempenho.
Para vermos as subconsultas em ação, vamos a um exemplo prático.
Exemplo: Criar uma listagem onde são exibidos os campos NúmeroDoPedido da tabela Pedidos, o
campo DataDoPedido da tabela Pedidos e o maior preço unitário dentre os itens que fazem parte do
pedido. Para criar esta consulta, utilizamos o seguinte comando:
SELECT [Pedidos].[NúmeroDoPedido], [Pedidos].[DataDoPedido],

(SELECT MAX([Detalhes do Pedido].[PreçoUnitário]) FROM [Detalhes do Pedido]
WHERE [Pedidos].[NúmeroDoPedido] = [Detalhes do Pedido].[NúmeroDoPedido]) AS
MaiorPreçoUnitário
FROM [Pedidos]
Na Figura 10.13, temos a parte inicial do resultado retornado.
Observe a subconsulta:
(SELECT MAX([Detalhes do Pedido].[PreçoUnitário]) FROM [Detalhes do Pedido]

WHERE [Pedidos].[NúmeroDoPedido] = [Detalhes do Pedido].[NúmeroDoPedido]) AS
MaiorPreçoUnitário
Esta consulta pesquisa os diversos itens para cada pedido e retorna o maior preço unitário.
Outro uso típico de uma subconsulta é como parâmetro da filtragem da consulta principal. Considere
o comando a seguir:
SELECT NúmeroDoPedido, CódigoDoCliente,DataDoPedido As MaisRecente

FROM Pedidos
WHERE DataDoPedido=(Select MAX(DataDoPedido) FROM Pedidos)
Figura 10.13 O primeiro exemplo com subconsultas.
Este comando retorna os pedidos mais recentes, ou seja, para o valor máximo da data. O valor máximo
da data significa a data mais recente no Banco de Dados. O resultado desta consulta é o seguinte:
NúmeroDoPedido CódigoDoCliente MaisRecente
11074 SIMOB 1998-05-06 00:00:00.000
11075 RICSU 1998-05-06 00:00:00.000
11076 BONAP 1998-05-06 00:00:00.000
11077 RATTC 1998-05-06 00:00:00.000
A subconsulta determina a data mais recente, data esta que é utilizada como critério para a cláusula
WHERE. Em resumo, o resultado retornado pela subconsulta é passado como critério de filtragem para
a cláusula WHERE.
Se trocarmos o MAX por MIN, teremos uma listagem dos pedidos mais antigos. Execute o seguinte
comando:
SELECT NúmeroDoPedido, CódigoDoCliente,DataDoPedido As MaisAntigo

FROM Pedidos
WHERE DataDoPedido=(Select MIN(DataDoPedido) FROM Pedidos)
Com este comando obtemos o seguinte resultado:
NúmeroDoPedido CódigoDoCliente MaisAntigo

10248 VINET 1996-07-04 00:00:00.000
Temos um tipo especial de subconsulta chamada de “Subconsulta correlacionada” (Correlated subqueries).

Neste tipo de subconsulta, são utilizadas informações da consulta principal e é executada para cada linha
retornada pela consulta externa. Neste tipo de subconsulta é que temos que tomar cuidados com o desempenho.
Por exemplo, se a consulta principal retorna 5000 registros, a subconsulta será executada 5000 vezes.
Mais uma vez vamos utilizar um exemplo para ilustrar este conceito.
Exemplo: Criar uma consulta que liste o nome de todos os funcionários que fizeram pedidos para o
Brasil, em que o campo DataDoPedido é para o ano de 1997. Para obter esta listagem, utilizamos o
seguinte comando:
SELECT
[Funcionários].[Nome]+ ‘ ‘+[Funcionários].[Sobrenome] As NomeCompleto, CódigoDoFuncionário
FROM Funcionários
WHERE EXISTS
( SELECT * FROM [Pedidos]
WHERE
[Funcionários].[CódigoDoFuncionário]=[Pedidos].[CódigoDoFuncionário]
AND Year([DataDoPedido])=‘1997’)
ORDER BY [Funcionários].[Nome]
Vamos explicar o funcionamento desta subconsulta em quatro passos:
1. Os valores obtidos pela consulta externa (primeiro SELECT) são passados para a consulta interna.
Lembre que, para cada registro obtido pela consulta externa, a consulta interna é executada.
2. A consulta interna (segundo SELECT) utiliza o valor passado pela consulta externa e executa o
comando SELECT da subconsulta interna.
3. Após a execução, a subconsulta interna retorna o seu resultado para a consulta principal.
4. Com base no valor retornado pela subconsulta, em conjunto com a função EXITS, o registro
retornado pela consulta externa é incluído ou descartado do resultado final. O próximo registro
retornado pela consulta externa é passado para a consulta interna, a qual executa novamente.
E o processo continua, até que todos os registros da consulta principal tenham sido passados
para a consulta interna. Desta maneira vemos que a consulta interna é executada tantas vezes
quantos forem os registros retornados pela consulta externa.
A seguir, temos os resultados do comando deste exemplo:
NomeCompleto CódigoDoFuncionário
Andrew Fuller 2
Anne Dodsworth 9
Janet Leverling 3
Laura Callahan 8
Margaret Peacock 4
Michael Suyama 6
Nancy Davolio 1
Robert King 7
Steven Buchanan 5
A correta utilização de subconsultas pode facilitar a obtenção de resultados aparentemente complexos

de se obter com um único comando SELECT. Porém, mais uma vez, vou ressaltar o cuidado em relação
ao desempenho quando tratamos com subconsultas.
CONCLUSÃO
Neste capítulo, tratamos de assuntos importantes relacionados ao desenvolvimento de aplicativos com o
SQL Server 2005. Tratamos de elementos que são criados no próprio Banco de Dados, como por exemplo:
♦ Stored procedures
♦ Triggers
Um stored procedure, de uma maneira simples, é um conjunto de comandos que é gravado no Banco
de Dados com um determinado nome. Uma vez gravado, o stored procedure pode ser executado a
qualquer momento, utilizando a seguinte sintaxe:
exec nome_stored_procedure parâmetros
Uma das grandes vantagens dos stored procedures é que estes ficam na memória cache após a primeira
execução. Isso faz com que as execuções subseqüentes sejam bem mais rápidas, o que melhora o
desempenho em relação, por exemplo, à utilização de consultas.
Triggers são um tipo especial de stored procedure executado em resposta a um comando SELECT,
INSERT ou UPDATE, em uma tabela do Banco de Dados. Quando uma trigger é executada, dizemos
que a trigger foi “disparada”. A principal função das triggers é impor as chamadas “Regras de Negócio”
ao Banco de Dados.
Na parte final do capítulo, vimos algumas técnicas avançadas dos comandos T-SQL. Tratamos da cláusula
join, a qual é utilizada quando temos um comando que acessa dados de várias tabelas.
Também tratamos e apresentamos alguns exemplos sobre utilização de subconsultas. Com uma subconsulta,
podemos estruturar um comando SQL complexo, em partes menores e mais simples de entender.
Capítulo 11
DESENVOLVENDO APLICAÇÕES QUE
ACESSAM DADOS NO SQL SERVER 2005
INTRODUÇÃO
Desenvolver aplicativos que acessam dados em um servidor SQL Server 2005 é bastante simples. Com
as tecnologias para acesso de dados, ficou mais fácil criar aplicações que acessam dados de variadas
fontes: SQL Server 2005, ORACLE, Mainframe, dados no formato Dbase, dados não estruturados, etc.
Neste capítulo, veremos os modelos para o desenvolvimento de aplicativos e também as tecnologias

da Microsoft para acesso a dados. Vamos falar sobre modelos de desenvolvimento em uma, duas, três
ou n camadas. Veremos a definição e as vantagens de cada modelo. Neste capítulo abordarei as
tecnologias clássicas, tais como ODBC, ADO e a linguagem de programação ASP. No Capítulo 13
abordarei o .NET e a criação de páginas ASP.NET que acessam banco de dados do SQL Server 2005. A
integração com o .NET (assunto do Capítulo 15) é, sem dúvidas, a grande novidade do SQL Server
2005 para o desenvolvimento de aplicações, em relação às versões anteriores do SQL Server.
A maioria das ferramentas de desenvolvimento modernas são capazes de trabalhar com as tecnologias
de acesso a dados da Microsoft. Poderíamos citar o Visual Basic, Delphi, Power Builder, Visual C++,
VB.NET, C#, C++.NET, a linha Visual Age da IBM, Microsoft Access, Lotus Notes, etc. Seria mais fácil
listar quais ferramentas não dão suporte às tecnologias de acesso a dados da Microsoft.
De uma maneira geral, o conjunto destas tecnologias é chamado de UDA – Universal Data Access.
Dentro deste bojo de tecnologias, temos como principais componentes o ODBC – Open Database
Connectivity (uma tecnologia mais antiga, mas ainda presente em muitas aplicações) e OLE DB – não
vou traduzir, pois a sigla é mais do que consagrada e não existe uma tradução que reflita exatamente o
que é OLE DB. O ODBC é mantido para compatibilidade com aplicações mais antigas, porém, para
novas aplicações, a Microsoft aconselha a utilização de OLE DB. Falaremos mais sobre estas tecnologias,
no decorrer deste capítulo. A tecnologia OLE DB é utilizada em conjunto com a tecnologia ADO –
Activex Data Objects. Também veremos detalhes sobre ADO, neste capítulo.
Neste capítulo darei ênfase em como acessar os dados do servidor SQL Server 2005, dentro de uma
aplicação. Apresentarei exemplos de acesso a dados, utilizando a tecnologia de páginas ASP – Active
Server Pages. De maneira alguma este capítulo tem a pretensão de ensinar sobre o desenvolvimento de
aplicações em ASP. O objetivo é ilustrar a parte referente ao acesso dos dados do servidor SQL Server
2005, através de páginas ASP. No Capítulo 12 tratarei do acesso aos dados de um servidor SQL Server
2005, utilizando o Microsoft Access.
NOTA
Para maiores informações sobre a criação de aplicações utilizando ASP, consulte o e-book “Criando Sites Dinâmicos com ASP 3.0”, de minha
autoria, o qual pode ser adquirido em http://www.juliobattisti.com.br/ebooksdoautor
Uma vez apresentada a teoria básica sobre os modelos de aplicações e sobre as tecnologias para acesso
a dados, partiremos para alguns exemplos práticos. Nos exemplos, aprenderemos a estabelecer conexões
com o servidor SQL Server 2005 e a enviar comandos para serem executados no servidor. Após a
execução dos comandos, os resultados são retornados para a aplicação que, no nosso caso, será ou uma
página ASP (Capítulo 11), ou um Banco de Dados do Microsoft Access (Capítulo 12) ou uma página
ASP.NET (Capítulo 13).
CAPÍTULO 11 – DESENVOLVENDO APLICAÇÕES QUE ACESSAM DADOS NO SQL SERVER 2005
Veremos que, mais uma vez, um bom entendimento dos comandos básicos da linguagem SQL é de
fundamental importância. Para um tutorial sobre os comandos básicos da linguagem SQL, consulte o
Apêndice, no final do livro.
Para que você possa acompanhar todos os exemplos deste capítulo, é preciso um conhecimento básico da linguagem HTML, principalmente
NOTA
no referente à criação de formulários com HTML e da linguagem VBScript da Microsoft. Maiores informações sobre estes tópicos podem ser
encontradas no e-book sobre ASP 3.0, de minha autoria, citado anteriormente http://www.juliobattisti.com.br/ebooksdoautor
DESENVOLVIMENTO EM: UMA INTRODUÇÃO AO

DESENVOLVIMENTO DE APLICAÇÕES EM N CAMADAS
PRÉ-REQUISITOS
♦ Não há.
METODOLOGIA
♦ Apresentação dos principais modelos de desenvolvimento de aplicações e sua evolução.
As aplicações atuais são, sem nenhuma dúvida, muito mais complexas de projetar, desenvolver,
implementar e manter do que as aplicações de uma ou duas décadas atrás. São as mais diversas aplicações
e para as mais diversas finalidades, tais como: Comércio Eletrônico, BI – Business Intelligence, CRM –
Customer Relationship Management (Gerenciamento das Relações com o cliente), ERP – Enterprise
Resource Planning, etc. São muitas siglas, muitas necessidades e, conseqüentemente, muita
complexidade no desenvolvimento e, principalmente, na manutenção e atualização das aplicações
empresariais. Por isso novos modelos de desenvolvimento vêm sendo propostos para facilitar o
desenvolvimento e, o mais importante, a atualização e manutenção de aplicações. Neste tópico, farei
uma retrospectiva desde o modelo em duas camadas, o tradicional Cliente/Servidor, até os modelos
mais atuais, em n camadas.
O objetivo é que o amigo leitor possa identificar, claramente, os problemas do modelo tradicional de
desenvolvimento em duas camadas e quais as soluções propostas pelos modelos em três ou mais camadas.
MODELO EM DUAS CAMADAS – CLIENTE/SERVIDOR TRADICIONAL

O modelo Cliente/Servidor foi criado tendo como objetivo básico a descentralização dos dados e recursos
de processamento, em oposição ao modelo centralizado utilizado na época em que o mainframe
dominava absoluto. Neste modelo, conforme indicado pela Figura 11.1, em uma rede de computadores,
existem uma ou mais máquinas que atuam como servidores, disponibilizando recursos para as demais
máquinas, as quais atuam como clientes.
Conforme pode ser visto na Figura 11.1, temos servidores de arquivos, servidores de Banco de Dados e
outras funções, tais como: servidores de impressão, servidores de segurança (Firewall, Proxy, Sistemas
de Detecção de Invasões), servidores Web, servidores FTP, etc. Estas redes, tipicamente, são formadas
por servidores, os quais são equipamentos com um maior poder de processamento e armazenamento,
e pelos clientes, os quais, na maioria dos casos, são microcomputadores PCs, ligados em rede.
Figura 11.1 O modelo Cliente/Servidor tradicional.
APLICAÇÕES EM DUAS CAMADAS

No início da utilização do modelo Cliente/Servidor (na primeira metade da década de 90), as aplicações
foram desenvolvidas utilizando-se um modelo de desenvolvimento em duas camadas. Neste modelo,
um programa, normalmente criado em um ambiente de desenvolvimento, como o Visual Basic, Delphi
ou Power Builder, é instalado em cada cliente. Este programa acessa dados em um servidor de Banco de
Dados, conforme ilustrado na Figura 11.2.
Figura 11.2 O modelo de desenvolvimento em duas camadas.
No modelo em duas camadas, temos um programa que é instalado no cliente, programa esse que faz
acesso a um Banco de Dados que fica residente no servidor de Banco de Dados (no nosso caso,
evidentemente, este servidor é o SQL Server 2005). Na maioria dos casos, a máquina do cliente é um
PC rodando Windows, e a aplicação cliente é desenvolvida utilizando-se um dos ambientes conhecidos,
conforme citado anteriormente. Sendo a aplicação cliente, um programa para Windows (na grande
maioria dos casos), a aplicação deve ser instalada em cada um dos computadores da rede, que farão uso
da aplicação. É o processo de instalação normal, para qualquer aplicação Windows. No modelo de
duas camadas, a aplicação cliente é responsável pelas seguintes funções:
♦ Apresentação: O código que gera a interface visível do programa faz parte da aplicação
cliente. Todos os formulários, menus e demais elementos visuais, de interação com o usuário
final, estão contidos no código da aplicação cliente. Caso sejam necessárias alterações na
interface do programa, faz-se necessária a geração de uma nova versão do programa, e
todos os computadores que possuem a versão antiga devem receber a nova versão, para
que o usuário possa ter acesso às alterações da interface. Aí que começam a surgir os
problemas no modelo de duas camadas. Uma simples alteração de interface é suficiente
para gerar a necessidade de atualizar a aplicação em centenas ou milhares de computadores,
dependendo do porte da empresa. O gerenciamento desta tarefa é algo extremamente
complexo e que envolve custos elevados.
♦ Lógica do Negócio: As regras, que definem a maneira como os dados serão acessados e
processados, são conhecidas como “Regras de Negócio”. Fazem parte das regras de negócio
desde funções simples para validação da entrada de dados, como o cálculo do dígito verificador
de um CPF, até funções mais complexas, como descontos escalonados para os maiores clientes,
de acordo com o volume da compra. Questões relativas à legislação fiscal e escrita contábil
também fazem parte das regras de negócio. Por exemplo, um programa para gerência de
recursos humanos, desenvolvido para a legislação dos EUA, evidentemente, não pode ser
utilizado, sem as devidas adaptações, por uma empresa brasileira. Isso acontece porque a
legislação dos EUA é diferente da legislação brasileira. Em síntese, as regras para o sistema de
recursos humanos são diferentes. Além isso, alterações nas regras de negócio são bastante
freqüentes, ainda mais com as repetidas mudanças na legislação do nosso país. Com isso,
faz-se necessária a geração de uma nova versão do programa, cada vez que uma determinada
regra muda, ou quando regras forem acrescentadas ou retiradas. Desta forma, todos os
computadores que possuem a versão anterior devem receber a nova versão, para que o usuário
possa ter acesso às alterações. Aí que se agravam os problemas no modelo de duas camadas.
Qualquer alteração nas regras do negócio, é suficiente para gerar a necessidade de atualizar a
aplicação, em centenas ou milhares de computadores. O gerenciamento desta tarefa é algo
extremamente complexo e de custo elevado. Aliás, já dissemos isso no parágrafo anterior, só
que é tão importante que sempre é bom repetir.
Com a evolução do mercado e as alterações da legislação, mudanças nas regras do negócio são bastante
freqüentes. Com isso, o modelo de duas camadas demonstrou-se de difícil manutenção e gerenciamento,
além de apresentar um TCO – Total Cost Ownership (Custo Total de Propriedade) muito elevado. O
TCO é uma medida que leva em conta diversos fatores, para calcular qual o custo em se manter uma
estação em rede e funcionando no período de um ano. Alguns cálculos apontam para valores próximos
de 10.000 dólares, por estação, por ano. Convenhamos que é um custo considerável.
A outra camada vem a ser o Banco de Dados, o qual fica armazenado em servidor da rede. Uma aplicação
desenvolvida em Visual Basic, a qual acessa um Banco de Dados em um servidor Microsoft SQL Server,
é um típico exemplo de uma aplicação em duas camadas.
Em busca de soluções para os problemas e para os custos do modelo de duas camadas é que surge a
proposta do modelo de três camadas, conforme analisaremos a seguir.
APLICAÇÕES EM TRÊS CAMADAS

Como uma evolução do modelo de duas camadas, surge o modelo de três camadas. A idéia básica do
modelo de três camadas é retirar as regras de negócio do cliente e centralizá-las em um determinado
ponto, ponto este que é chamado de servidor de aplicações. O acesso ao Banco de Dados é feito através
das regras contidas no servidor de aplicações. Ao centralizar as Regras do Negócio em um servidor de
aplicações, fica muito mais fácil a atualização destas regras. A Figura 11.3 nos dá uma idéia geral do
modelo em três camadas.
Figura 11.3 O modelo de desenvolvimento em três camadas.
Todo o acesso do cliente, ao Banco de Dados, é feito de acordo com as regras contidas no servidor de
aplicações. O cliente não tem acesso direto ao Banco de Dados, sem antes passar pelo servidor de aplicações.
Neste modelo, as três camadas são as seguintes:
♦ Apresentação: Continua no programa instalado no cliente. Alterações na interface do programa

continuam gerando a necessidade de atualizar a aplicação em todos os computadores, onde a
aplicação está sendo utilizada. Porém, cabe ressaltar que alterações na interface são menos
freqüentes do que alterações nas regras de negócio.
♦ Lógica: São as regras de negócio, as quais determinam de que maneira os dados serão utilizados.
Esta camada foi deslocada para o servidor de aplicações. Desta maneira, quando uma regra de
negócio for alterada, basta atualizá-la no servidor de aplicações. Após a atualização, a qual só
precisa ser feita no servidor de aplicações, todos os usuários passarão a ter acesso à nova versão,
sem que seja necessário reinstalar o programa cliente em cada um dos computadores da rede.
Vejam que, ao centralizar as regras do negócio em um servidor de aplicações, estamos facilitando,
enormemente, a tarefa de manter a aplicação atualizada.
necessária para o funcionamento da aplicação. Cabe ressaltar que os dados somente são acessados
através do servidor de aplicação, e não diretamente pela aplicação cliente.
Com a introdução da uma camada de lógica, resolvemos o problema de termos que atualizar a aplicação,
em centenas ou milhares de computadores, cada vez que uma regra de negócio for alterada. Porém,
continuamos com o problema de atualização da aplicação, cada vez que sejam necessárias mudanças
na interface. Por isso que surgiram os modelos de n-camadas. No próximo tópico, iremos falar um
pouco sobre o modelo de quatro camadas.

Como uma evolução do modelo em três camadas, surge o modelo em quatro camadas. A idéia básica
do modelo em quatro camadas é retirar a camada de apresentação do cliente e centralizá-la em um
determinado ponto, o qual na maioria dos casos é um servidor Web. Com isso, o próprio cliente deixa
de existir como um programa que precisa ser instalado em cada computador da rede. O acesso à
aplicação é feito através de um navegador, como o Internet Explorer ou o Netscape Navigator. A Figura
11.4 nos dá uma idéia geral do modelo em quatro camadas.
Para acessar a aplicação, o cliente acessa o endereço da aplicação, utilizando o seu navegador. Por
exemplo http://www.empresa-abc.com.br/sistemas/cadastro.asp. Todo o acesso do cliente ao Banco de
Dados é feito de acordo com as regras contidas no servidor de aplicações. O cliente não tem acesso
direto ao Banco de Dados, sem antes passar pelo servidor de aplicações. Com isso, as quatro camadas
são as seguintes:
♦ Cliente: Neste caso, o cliente é o navegador utilizado pelo usuário, quer seja o Internet Ex-
plorer, quer seja o Netscape Navigator, FireFox ou outro navegador qualquer.
♦ Apresentação: Passa para o servidor Web. A interface pode ser composta de páginas HTML,
ASP, ASP.NET, PHP ou qualquer outra tecnologia capaz de gerar conteúdo para o navegador,
dinamicamente a partir do conteúdo contido em um banco de dados. Com isso, alterações na
interface da aplicação são feitas diretamente no servidor Web, sendo que estas alterações estarão,
automaticamente, disponíveis para todos os clientes. Atualizar uma aplicação é, basicamente,
atualizar as páginas da aplicação, no servidor Web. Desta maneira, não existe a necessidade de
reinstalar a aplicação em todos os computadores da rede, cada vez que forem feitas alterações
na interface da aplicação. Fica muito mais fácil garantir que todos estão tendo acesso à versão
mais atualizada da aplicação. A única coisa que o cliente precisa ter instalado na sua máquina
é o navegador. O acesso ao Banco de Dados é feito através do servidor de aplicações, o qual por
sua vez faz e gerencia todas as conexões com o Banco de Dados.
♦ Lógica: São as regras de negócio, as quais determinam de que maneira os dados serão utilizados.
Esta camada está no servidor de aplicações. Desta maneira, quando uma regra de negócio for
alterada, basta atualizá-la no servidor de aplicações. Após a atualização, todos os usuários passarão
a ter acesso à nova versão, sem que seja necessário reinstalar o programa em cada um dos
computadores da rede. Vejam que, ao centralizar as regras do negócio em um servidor de
aplicações, estamos facilitando a tarefa de manter a aplicação atualizada.
necessária para o funcionamento da aplicação.
Com o deslocamento da camada de apresentação para um servidor Web, resolvemos o problema de

termos que atualizar a aplicação, em centenas ou milhares de computadores, cada vez que houver
alguma alteração na interface da aplicação. Neste ponto, a atualização das aplicações é uma tarefa bem
mais gerenciável, muito diferente do que acontecia no caso do modelo em duas ou três camadas.
Os servidores de aplicação, Web e Banco de Dados não precisam, necessariamente, ser servidores
separados, isto é, uma máquina para fazer o papel de cada um dos servidores. O conceito de servidor de
aplicação, Web ou Banco de Dados é um conceito relacionado com a função que o servidor desempenha.
Podemos ter, em um mesmo equipamento, um servidor de aplicações, um servidor Web e um servidor
de Banco de Dados. Claro que questões de desempenho devem ser levadas em consideração, conforme
analisaremos no próximo tópico.
QUESTÕES A CONSIDERARMOS NOS MODELOS DE TRÊS OU MAIS CAMADAS

Muitas são as vantagens dos modelos de três ou mais camadas, em relação à facilidade de
gerenciamento, redução de custos, facilidade de implementação e atualização das aplicações. Porém,
considerações devem ser feitas em relação a desempenho e dimensionamento dos equipamentos
que atuarão como servidores.
A partir do momento em que estamos deslocando funcionalidades (tipicamente lógica e apresentação),

do cliente para um ou mais servidores, também estamos deslocando capacidade de processamento em
termos de memória RAM e processador. Funções que antes eram executadas pelos clientes, utilizando
memória e processador da estação cliente, agora foram deslocadas para os servidores, com isso
consumindo memória e processador do servidor. Por isso, um dos fatores mais importantes a considerar
é o correto dimensionamento dos equipamentos servidores.
Para fazer o dimensionamento dos servidores, precisamos estimar o número de usuários que irão acessar
cada aplicação simultaneamente, o nível de exigência de cada usuário, os recursos necessários pelos
software do servidor, dentre outros. Para determinar o nível de recursos necessários em cada um dos
servidores, você precisa fazer um estudo bem detalhado, de tal forma que o servidor não fique sub-
dimensionado. Quando o servidor não está corretamente dimensionado, a tendência é que o acesso à
aplicação fique bastante lento, causando insatisfação entre os usuários.
Dentro deste modelo de desenvolvimento para a Web, em três ou mais camadas, existem diversos pontos,
nos quais podemos utilizar a tecnologia ASP (assunto deste capítulo). Para desenvolver a interface da
aplicação, combinamos código HTML com código ASP. Utilizando ASP, podemos desenvolver páginas
que acessam o Banco de Dados, através do servidor de aplicações. Questões como autenticação de usuários,
determinação do nível de acesso e segurança da aplicação podem ser desenvolvidas com a utilização de
ASP. Neste capítulo vamos utilizar a tecnologia ASP para acessar dados no servidor SQL Server 2005.
DESENVOLVIMENTO EM: PREPARAÇÃO DO SERVIDOR

PARA ACOMPANHAR OS EXEMPLOS DESTE CAPÍTULO
PRÉ-REQUISITOS
♦ Noções básicas do Windows.
♦ Noções básicas de aplicações Web.
♦ Noções básicas do Windows 2000 Server ou Windows Server 2003.
METODOLOGIA
♦ Preparação de um servidor Windows 2000 e configuração do IIS.
Antes que você possa acompanhar os exemplos deste capítulo, precisamos verificar se o servidor que
você está utilizando está configurado corretamente. Os dados do servidor que estou utilizando estão
Tabela 11.1 Características do equipamento que estou utilizando.
Característica Descrição
Sistema Operacional Windows 2000 Server em português.

Nome Servidor
SQL Server SQL Server 2005
Instâncias SERVIDOR\SQL2005
SERVIDOR\CURSOSJB
Endereço Web http://servidor (*) ou www.groza.com
(*) Este endereço faz parte da minha intranet residencial. Não é um endereço que possa ser acessado pela Internet, a não ser que alguém tenha criado um site com este endereço.
Se as configurações do equipamento que você está utilizando forem diferentes, utilize as configurações
do seu equipamento, ao invés das indicadas na Tabela 11.1.
Neste tópico, vamos fazer duas configurações. A primeira é criar uma pasta onde colocaremos os
exemplos deste capítulo. A segunda é configurar esta pasta como uma pasta virtual do servidor IIS –
Internet Information Services. Para que possamos testar as páginas ASP de exemplo, precisamos que o
IIS esteja instalado e testado. Para maiores informações sobre a instalação e teste do IIS, consulte a
introdução deste livro.
CRIANDO A PASTA ONDE IREMOS GRAVAR OS EXEMPLOS DESTE CAPÍTULO

Utilizando o Windows Explorer, crie uma pasta chamada LivroSQL2005, no drive C:. Dentro da pasta
LivroSQL2005, crie uma subpasta chamada Capitulo11 (Capitulo sem acento), conforme indicado na
Figura 11.5.
Figura 11.5 Criando a pasta C:\LivroSQL2000\Capitulo11.
Agora vamos fazer com que a pasta LivroSQL2005 (e, conseqüentemente, todas as suas subpastas; no
nosso exemplo temos somente a subpasta Capitulo 11) passe a fazer parte do servidor Web que estou
utilizando para os exemplos deste capítulo -> http://www.groza.com.
NOTA
Lembrando mais uma vez, estou utilizando os parâmetros da Tabela 11.1, em que o nome do servidor é Servidor. Se o nome do seu equipamento
for diferente, substitua Servidor pelo nome que você está utilizando. O servidor também pode ser acessado com o endereço www.groza.com. Para
associar o nome www.groza.com com o seu servidor (este tipo de associação só pode ser feito para um servidor interno, o qual não esteja como
servidor na Internet. Você não pode usar um nome na Internet, sem antes tê-lo registrado no site http://www.registro.br), vamos configurar o
arquivo hosts. O arquivo hosts fica na pasta C:\Winnt\system32\drivers\etc. Substitua C: pela pasta onde o Windows está instalado e Winnt, pela
pasta onde o Windows está instalado. Você deve editar o arquivo hosts (é hosts mesmo, sem nenhuma extensão) e acrescentar a seguinte linha,
no final do arquivo: 127.0.0.1 www.groza.com Muito cuidado ao salvar o arquivo, pois se ele for salvo com uma extensão, como por exemplo
hosts.txt, esta configuração não irá funcionar. O nome do arquivo tem que ser somente hosts, sem nenhuma extensão.
TORNANDO A PASTA LIVROSQL2005, PARTE DO SERVIDOR IIS

Agora vamos aprender, passo a passo, como tornar a pasta LivroSQL2005 parte do servidor IIS. Para
isso utilizaremos o console Gerenciador do Internet Services, do Windows 2000 Server. Para maiores
informações sobre MMC, Snap-in e Consoles administrativos, consulte a Unidade IV, do seguinte e-
book de minha autoria: “Microsoft Windows 2000 Server Curso Básico & Rápido”, o qual pode ser
adquirido através do endereço http://www.juliobattisti.com.br/cursos
Para tornar a pasta LivroSQL2005 parte do servidor IIS http://servidor (tornar parte significa que a
pasta LivroSQL2005 passará a ser uma pasta virtual do servidor IIS), siga os passos indicados a seguir:
1. Faça o logon com uma conta com direitos de administrador no Windows 2000 Server.
2. Clique em Iniciar -> Programas -> Ferramentas administrativas -> Gerenciador do Internet Services.
3. Será aberta a janela Internet Information Services. Dê um clique duplo no nome do computador
para abri-lo. No exemplo da Figura 11.6, o nome do computador é Servidor. São exibidas,
dentre outras opções disponíveis, três opções padrão, conforme indicado pela Figura 11.6.
Figura 11.6 Opções de gerenciamento para o IIS 5.0.
4. Dê um clique no sinal de +, ao lado da opção Site da Web padrão, para expandir esta opção. As
opções que aparecem são as pastas virtuais que já fazem parte do site padrão.
5. Dê um clique com o botão direito do mouse, sobre Site da Web padrão. No menu que surge,
aponte para Novo. Nas opções que surgem, dê um clique na opção Pasta virtual, conforme
indicado pela Figura 11.7.
6. Esta pasta virtual será associada à pasta LivroSQL2005, criada anteriormente. Será exibida a
primeira tela do assistente para a criação de pasta virtual. A primeira etapa é apenas informativa.
Dê um clique no botão Avançar, seguindo para a próxima etapa do assistente.
Nesta segunda etapa, você precisa definir um nome (Alias) para esta pasta virtual. Utilizaremos o
mesmo nome da pasta: LivroSQL2005. Porém não é obrigatório que seja utilizado o mesmo nome. Por
questão de facilidade de administração e gerenciamento, sempre utilizo nomes iguais para o nome da
pasta no disco rígido e o nome/apelido a ser utilizado no IIS.
Figura 11.7 Criando uma nova pasta virtual no servidor IIS.
7. Digite LivroSQL2005, conforme indicado pela Figura 11.8. Dê um clique no botão Avançar.
Figura 11.8 Digitando um nome para a pasta no IIS.
Nesta etapa, o assistente pergunta qual a pasta a ser associada com o nome virtual informado na etapa
anterior. Podemos digitar o caminho completo para a pasta, ou utilizar o botão Procurar, para localizar
a pasta desejada. No nosso exemplo, vamos digitar C:\LivroSQL2005. Com isso estamos associando a
pasta C:\LivroSQL2005, com a pasta virtual LivroSQL2005, do servidor IIS.
8. Digite C:\LivroSQL2005, conforme indicado na Figura 11.9, e dê um clique no botão Avançar,

para ir para a próxima etapa do assistente.
Figura 11.9 Informando o caminho da pasta C:\LivroSQL2005.
Nesta etapa do assistente, podemos configurar as permissões de acesso à pasta LivroSQL2005. Certifique-
se de que as opções “Leitura” e “Executar Scripts (ASP por exemplo)” estejam marcadas, conforme
indicado pela Figura 11.10. Se a opção “Executar Scripts (ASP por exemplo)” não estiver marcada, o
código ASP será ignorado pelo IIS e, com isso, os exemplos deste capítulo não irão funcionar.
9. Dê um clique em Avançar. Surge a tela final do assistente.
10. Dê um clique no botão Concluir, para finalizar o assistente.
Você estará de volta ao gerenciador do Internet Services.
Observe que um novo diretório virtual chamado LivroSQL2005 já aparece como parte integrante Site
da Web Padrão.
11. Feche o gerenciador do Internet Services.
Figura 11.10 Configurando as opções de segurança.

NOTA
Uma vez criado o diretório virtual LivroSQL2005, o qual está associado à pasta C:\LivroSQL2005, como posso acessar, através do navegador,
o conteúdo que for colocado dentro da pasta C:\LivroSQL2005, ou em uma das suas subpastas?
A resposta para a questão acima é bastante simples, basta que entendamos como são formados os
endereços em um servidor como o IIS. No nosso exemplo, o endereço do servidor é http://servidor. Ao
digitarmos este endereço, estamos acessando a página principal do servidor. Vamos supor que dentro
da pasta virtual LivroSQL2005 (associada com a pasta C:\LivroSQL2005) fosse colocada uma página
chamada index.asp. Como faríamos para acessar esta página, através do navegador? O endereço da
página em questão seria o seguinte: http://servidor/LivroSQL2005/index.asp.
A Figura 11.11 descreve em detalhes a formação deste endereço.
Figura 11.11 A formação de endereços no servidor IIS.
Observe que, primeiro, vem o nome do servidor (http://servidor), depois o nome do diretório virtual
(LivroSQL2005) e, finalmente, o nome da página a ser acessada (index.asp).
NOTA
Como é que fica o endereço, quando eu quero acessar uma página que está dentro de uma subpasta da pasta LivroSQL2005?
Seguindo o mesmo raciocínio anterior, fica fácil responder a esta pergunta. Vamos supor que você
queira acessar uma página chamada cep.asp, que está na subpasta Capitulo11, a qual está na pasta
LivroSQL2005. Como fica o endereço para acessar esta página? A Figura 11.12 responde esta questão.
Figura 11.12 A formação de endereços em subpastas

do diretório virtual, no servidor IIS.
Com isso, podemos ver que existe uma lógica bem definida para a formação dos endereços. Apenas
para confirmar, vamos dar mais alguns exemplos de formação de endereços. Considere os casos
abaixo indicados:
♦ Qual o endereço de uma página chamada teste.htm, gravada na subpasta Testes (que ainda
não existe), da pasta virtual LivroSQL2005? Resposta: http://servidor/LivroSQL2005/Tes-
tes/teste.htm
♦ Qual o endereço de uma página chamada cadastro.asp, gravada no diretório Capitulo10?
Resposta: http://servidor/LivroSQL2005/Capitulo10/cadastro.asp
É importante que você entenda bem a maneira como o servidor IIS constrói os endereços de acesso
para as páginas gravadas em suas pastas virtuais. Observe que a pasta virtual é simplesmente um nome
que nos leva até o diretório real, gravado no HD. Podemos criar diversos diretórios virtuais, em um
único servidor IIS.
Agora estamos com o nosso servidor “quase” pronto para acompanhar os exemplos deste capítulo.
Só falta configurarmos algumas fontes ODBC, que serão utilizadas nos exemplos práticos. Mas
antes de configurarmos as fontes ODBC, vamos fazer um estudo sobre ODBC, OLE DB e ADO.
Com isso, ficaremos sabendo o que é uma fonte ODBC, bem como uma série de outros conceitos
importantes para a criação de aplicações que acessam dados no servidor SQL Server 2005, a
partir de páginas ASP. Então, mãos à obra.
DESENVOLVIMENTO EM: UM POUCO SOBRE ODBC, OLE DB E ADO

PRÉ-REQUISITOS
♦ Noções sobre os modelos de desenvolvimento de aplicações.
♦ Noções sobre o modelo relacional de Banco de Dados.
METODOLOGIA
♦ Apresentação das tecnologias ODBC, ADO/OLE DB.
A Microsoft vem, há muito tempo, desenvolvendo tecnologias que permitam acesso às mais variadas
fontes de dados, quer sejam dados estruturados em Bancos de Dados tradicionais como o Microsoft
SQL Server, dados nos formatos mais tradicionais como os armazenados em mainframes, até dados
não estruturados, como mensagens de correio eletrônico e arquivos com conteúdo multimídia, como
som e imagem. A expressão por trás deste esforço é conhecida como “Acesso Universal aos Dados” ou
UDA, do inglês Universal Data Access.
Porém, na tentativa de disponibilizar o acesso universal aos dados, muitas tecnologias foram criadas, o
que muitas vezes causa uma certa confusão e até desconforto para quem trabalha com desenvolvimento
de aplicações. A cada nova tecnologia anunciada, um novo ciclo de aprendizado tem início, sem
contar que muitas vezes a comunicação entre as diferentes tecnologias não é exatamente a esperada.
Neste mundo de tecnologias, já nos deparamos com siglas como:
♦ DAO – Data Access Objects.
♦ RDS – Remote Data Access.
♦ ADO – Activex Data Object.
♦ ODBC – Open Database Connectivity.
♦ OLE DB – prefiro não traduzir.
♦ ADO.NET – A tecnologia de acesso a dados do .NET. Veremos no Capítulo 13.
É normal que o desenvolvedor fique um pouco confuso com esta “sopa de letrinhas” (na verdade
bem confuso). Mais importante do que decorar o significado de cada sigla é entender a tecnologia
que fornece acesso aos dados e saber utilizá-las corretamente. Hoje, a tecnologia mais utilizada e
recomendada pela Microsoft é a dobradinha ADO/OLE DB. “A utilização de ODBC é bastante forte e
deve se manter por um bom período – digamos por mais três ou quatro anos ainda teremos que, no
mínimo, dar suporte a aplicações que utilizam ODBC” (escrevi o texto entre aspas no ano 2000,
quando eu estava escrevendo o livro SQL Server 2000 – Curso Completo. Porém como toda boa
previsão, errei feio, ou seja, hoje, cinco anos depois, continuamos tendo que trabalhar com aplicações
baseadas em ODBC. Não vou arriscar uma nova previsão; só sei que todo profissional de banco de
dados continua tendo que conhecer sobre ODBC. Por isso que veremos esta tecnologia também
neste livro de SQL Server 2005). Por isso, analisaremos estas duas opções neste capítulo – ODBC e
ADO/OLE-DB –, sendo que muitas vezes utilizaremos as duas ao mesmo tempo. Agora vamos procurar
entender um pouco melhor estas tecnologias.
UM POUCO SOBRE ODBC – OPEN DATABASE CONNECTIVITY

ODBC é um padrão da indústria de informática para acesso a Bancos de Dados estruturados. Um Banco
de Dados estruturado utiliza o modelo Relacional (veja o Capítulo 1 para um estudo detalhado sobre o
Modelo Relacional de Dados), onde temos tabelas e relacionamentos entre tabelas. São exemplos de
Bancos de Dados relacionais: MS SQL Server, ORACLE, MS Access, Sybase, DB2 da IBM, etc.
NOTA
Para uma revisão dos fundamentos do modelo Relacional, consulte o Capítulo 1.
ODBC é uma interface que permite que os aplicativos acessem qualquer base de dados para a qual
existe um driver ODBC. Utilizando ODBC, podemos criar páginas ASP que acessem dados para os
quais existam drives ODBC, de uma maneira simples e rápida.
Com a utilização de ODBC, podemos criar aplicações que se tornam independentes do sistema de
Banco de Dados que está sendo utilizado. Por exemplo, desenvolvemos uma aplicação para acessar
uma fonte de dados ODBC. Esta fonte de dados está ligada a um Banco de Dados do Microsoft Access.
Em determinado momento, resolvemos migrar do Microsoft Access para o Microsoft SQL Server 2005.
Sem problemas. Basta alterar nossa fonte de dados ODBC para que a fonte passe a referenciar o Banco
de Dados no Microsoft SQL Server 2005 e, pronto, a nossa aplicação passa a utilizar a nova fonte de
dados de maneira transparente, através do driver ODBC.
Na Figura 11.13, temos uma visão geral do acesso aos dados utilizando ODBC.
Figura 11.13 ODBC para acesso a dados.
Para que uma fonte ODBC possa ser utilizada, a fonte precisa ser previamente criada, utilizando-se o
gerenciador ODBC, o qual é acessível através da opção Ferramentas administrativas do menu Iniciar -
> Programas -> Ferramentas Administrativas -> Fontes de dados (ODBC). Agora aprenderemos a criar
fontes de dados ODBC, na prática.
Ao desenvolver um aplicativo, o desenvolvedor fará referência à fonte ODBC criada. A título de exemplo,
iremos criar duas fontes, uma para um Banco de Dados Microsoft Access e outra para um Banco de
Dados Microsoft SQL Server 2005. A fonte ODBC para o SQL Server 2005 será utilizada neste capítulo
e a fonte para o Microsoft Access, no Capítulo 12.
CRIANDO UMA FONTE ODBC PARA UM BANCO DE DADOS DO MICROSOFT ACCESS

Vamos criar uma fonte para um Banco de Dados do Microsoft Access. Utilizaremos uma base de exemplo
que já vem com o Microsoft Access – Northwind.mdb. No nosso exemplo, o banco de dados
Northwind.mdb estará localizado em C:\Meus documentos.
NOTA
A estrutura (tabelas e relacionamentos) deste Banco de Dados é praticamente igual ao Northwind instalado com o SQL Server 2000, o qual
pode ser importado para o SQL Server 2005, usando o DTS Import/Export Wizard, o qual já foi exemplificado, anteriormente, neste livro.
Para criar uma fonte ODBC chamada nwind, associada com o banco de dados Northwind.mdb, siga os
NOTA
Dependendo da versão do ODBC instalada em seu computador, as telas apresentadas podem ser um pouco diferentes das aqui apresentadas.
1. Abra o gerenciador de fontes ODBC (Iniciar -> Programas -> Ferramentas administrativas ->
Fontes de dados (ODBC). Surge a janela indicada na Figura 11.14.
Figura 11.14 O gerenciador de fontes ODBC.
Uma fonte de dados é chamada de DSN (Data Source Name), a qual pode ser de três tipos:
♦ DSN de Usuário (User DSN): Este tipo de fonte ODBC contém as informações necessárias para
se conectar com um determinado Banco de Dados. Somente pode ser utilizada pelo usuário
que criou a fonte e no computador onde a fonte foi criada. É um tipo pouco utilizado.
♦ DSN de Sistema (System DSN): Este é, sem dúvidas, o tipo mais utilizado. Este tipo de fonte
ODBC contém as informações necessárias para se conectar com um determinado Banco de
Dados. É visível para todos os usuários que acessam o servidor, inclusive para os serviços do
Windows 2000.
♦ DSN de Arquivo (File DSN): Este tipo de fonte ODBC contém as informações necessárias para
se conectar com um determinado Banco de Dados. As informações são gravadas em um arquivo
e podem ser compartilhadas por vários usuários.
No nosso exemplo, vamos trabalhar, sempre, com uma fonte ODBC do tipo System DSN.
NOTA
Para maiores informações sobre os diferentes tipos de DSN consulte o site http://msdn.microsoft.com.
2. Dê um clique na guia DNS de Sistema. Surge a janela indicada na Figura 11.15.
Figura 11.15 Criando uma fonte do tipo System DSN.
3. Dê um clique no botão Adicionar para criar uma nova fonte ODBC.
4. Surge uma janela perguntando qual o tipo de Banco de Dados que a fonte ODBC irá selecionar.
Selecione Driver do Microsoft Access (*.mdb), conforme indicado na Figura 11.16.
Figura 11.16 Selecionando o Banco de Dados a ser usado.
5. Dê um clique no botão Concluir. É aberta a janela “Configurar ODBC para Microsoft Access”,
Figura 11.17 Definições para a fonte ODBC para o Microsoft Access.
Nesta janela, devemos fornecer diversas informações, tais como o nome para a fonte ODBC, a localização
do arquivo .mdb, etc.
6. No campo Nome da fonte de dados, digite nwind.
7. No campo Descrição, digite Dados do Microsoft Access.
A janela Configurar ODBC para Microsoft Access deve estar conforme indicado na Figura 11.18.
Figura 11.18 Definindo a fonte ODBC.
8. Dê um clique no botão Selecionar. Utilizamos este botão para selecionar o arquivo .mdb que
será acessado pela fonte ODBC que está sendo criada. Surgirá a janela “Selecionar Banco de
Dados do sistema”.
9. Navegue até a pasta onde está o arquivo .mdb. No nosso exemplo vamos navegar até a pasta
Meus documentos do drive C:, e dentro da pasta Meus documentos vou selecionar
Northwind.mdb, conforme indicado na Figura 11.19.
Figura 11.19 Selecionando o arquivo C:\Meus documentos\Northwind.mdb
10. Dê um clique no botão OK e você estará de volta à janela Configurar ODBC para Microsoft Access.
11. Dê um clique no botão OK para fechar a janela Configurar ODBC para Microsoft Access.
12. Você estará de volta à janela do gerenciador de fontes ODBC, com a fonte ODBC “nwind” já
criada. Feche o gerenciador.
NOTA
Vamos utilizar esta fonte ODBC em diversos exemplos do Capítulo 12.
CRIANDO UMA FONTE ODBC PARA UM BANCO DE DADOS PUBS, DA INSTÂNCIA SERVIDOR\SQL2005
Vamos criar uma fonte para um Banco de Dados do Microsoft SQL Server 2005. Utilizaremos o banco
de dados Pubs, o qual era instalado automaticamente com o SQL Server 2000. No SQL Server 2005 não
está disponível este banco de dados. Para os exemplos deste capítulo, eu utilizei o DTS Import/Export
Wizard, para importar o banco de dados Pubs de uma instância do SQL Server 2000 para a instância
SERVIDOR\SQL2005, do SQL Server 2005. Você aprendeu a utilizar o DTS Import/Export Wizard nos
Capítulos 7 e 9. Nestes Capítulos você encontra exemplos práticos, passo a passo, de como usar o DTS
Import/Export Wizard. No nosso exemplo, o nome do Servidor SQL é SERVIDOR e a instância é
SERVIDOR\SQL2005. Caso você esteja trabalhando em um servidor com um nome diferente, utilize o
nome do servidor no qual você está trabalhando.
NOTA
O Banco de Dados pubs é modelado com base em uma editora fictícia. Existe tabela para cadastro de autores, títulos de livro, etc.
Para criar uma fonte ODBC chamada ST1_pubs, fonte esta associada ao banco de dados Pubs, da
instância SERVIDOR\SQL2005, siga os passos indicados a seguir:
NOTA
Dependendo da versão do ODBC instalado em seu computador, as telas apresentadas podem ser um pouco diferentes das aqui apresentadas.
Fontes de dados ODBC).
2. Dê um clique na guia DSN de Sistema.
3. Dê um clique no botão Adicionar, para criar uma nova fonte ODBC.
4. Surge uma janela perguntando qual o tipo de Banco de Dados que você deseja acessar. Selecione
SQL Server, conforme indicado na Figura 11.20.
5. Dê um clique no botão Concluir. É aberta a janela “Criar uma nova fonte de dados para o SQL Server”.
6. No campo Nome, digite ST1_pubs.
7. No campo Descrição, digite Banco pubs no SQL Server 2005.
Figura 11.20 Selecionando o Banco de Dados a ser usado.
8. Na lista Servidor, selecione o nome do Servidor SQL a ser utilizado. No nosso exemplo
SERVIDOR\SQL2005.
A janela “Criar uma nova fonte de dados para o SQL Server” deve estar conforme indicado na
Figura 11.21.
Figura 11.21 Definições para a fonte ODBC.
9. Dê um clique no botão Avançar para ir para a próxima etapa.
10. Nesta etapa, definimos o tipo de autenticação a ser utilizado. Como estamos nos conectando
com SERVIDOR\SQL2005, certifique-se de que a opção “Com a identificação do Windows NT
usando ident. de logon na rede” esteja selecionada, conforme indicado na Figura 11.22.
Figura 11.22 Definindo o tipo de autenticação.
11. Dê um clique no botão Avançar, seguindo para a próxima etapa do assistente. Nesta tela,
vamos definir com qual Banco de Dados nos conectamos por padrão, ao estabelecer a conexão
com SERVIDOR\SQL2005, usando a fonte ODBC que está sendo crida. Clique na opção “Alterar
o banco de dados padrão para”. A lista abaixo desta opção é habilitada. Nesta lista, selecione
Pubs, conforme indicado na Figura 11.23.
Em um servidor SQL Server, podem existir diversos Bancos de Dados. Neste caso, estamos definindo a
qual Banco de Dados a nossa fonte ODBC irá conectar-se.
12. Dê um clique no botão Avançar para ir para a última etapa. Nesta etapa podemos definir
diversas opções, tais como:
♦ O idioma para as mensagens do SQL Server.
♦ Se devemos ou não utilizar criptografia dos dados para aumentar a segurança.
♦ Se devemos utilizar as configurações regionais, tais como hora, data e formato para números
em geral e para valores monetários.
13. Selecione as opções conforme indicado na Figura 11.24.
Figura 11.23 Definindo a qual Banco de Dados a fonte ODBC se conecta.
Figura 11.24 Finalizando a configuração da fonte ODBC.
14. Dê um clique no botão Concluir para finalizar a criação da fonte ODBC.
Surge a janela Instalação do ODBC para Microsoft SQL Server, a qual informa as diversas opções
selecionadas, conforme indicado na Figura 11.25. Nesta janela, podemos clicar no botão “Testar fonte
de dados”, para verificar se a conexão com o Banco de Dados está OK.
Figura 11.25 Resumo das opções selecionadas para a fonte ODBC.
15. Dê um clique no botão Testar fonte de dados. Deve surgir uma janela indicando que o teste foi
realizado com sucesso, conforme indicado na Figura 11.26.
Figura 11.26 Teste indicando que a conexão está OK.
16. Dê um clique em OK para fechar a janela de teste.
17. Dê um clique em OK para fechar a janela de resumo.
18. Você estará de volta à janela do gerenciador de fontes ODBC, com a fonte ODBC ST1_pubs já
criada. Dê um clique em OK para fechar o gerenciador.
NOTA
Utilizaremos esta fonte ODBC nos exemplos deste capítulo.
Agora que já sabemos um pouco sobre ODBC, vamos falar sobre a dobradinha ADO/OLE DB.
UM POUCO SOBRE OLE DB E ADO

OLE DB é uma tecnologia, baseada na tecnologia COM – Common Object Model – da Microsoft, para
acesso a Bases de dados. Uma das grandes novidades trazidas pela tecnologia OLE DB é a possibilidade de
acesso a bases de dados não estruturadas, como por exemplo arquivos de mensagens de correio eletrônico,
arquivos de texto, e Bancos de Dados de documentos como o Lotus Notes ou o Microsoft Exchange.
Além disso, a tecnologia OLE DB foi construída tendo a performance como uma de suas diretivas.
Diferente do ODBC, não existe um Driver OLE DB para cada fonte de dado. Na tecnologia OLE DB, o
conector para uma fonte de dados é chamado de OLE DB Provider. Por exemplo, existe um OLE DB
Provider para Microsoft Access, um OLE DB Provider para Microsoft SQL Server, um para mensagens
de correio do Microsoft Exchange, um para Bancos de Dados Oracle e assim por diante.
OLE DB
OLE DB Providers
Exchange Gerenciador ODBC

Jet SQL Server
Server
Provider Provider
Provider
Driver ODBC Driver ODBC Driver ODBC

Drivers ODBC
SQL Server Microsoft Access Oracle
Microsoft Microsoft Microsoft Microsoft Microsoft ORACLE

Access SQL Server Exchange SQL Server Access
Server
Fontes de dados: Estruturadas e Não estruturadas.
Figura 11.27 Acessando fontes de dados com OLE DB.
Muitos usuários pensam que OLE DB veio para substituir completamente o padrão ODBC. Na verdade
isto pode até acontecer daqui a algum tempo. Porém, na prática, existe um OLE DB Provider para
ODBC. Com isso, utilizando OLE DB podemos ter acesso a qualquer fonte de dados ODBC. Na prática,
ODBC funciona como se fosse um subconjunto de OLE DB, uma vez que OLE DB fornece acesso a
todas as fontes de dados ODBC (através da utilização do OLE DB Provider para ODBC), mais as fontes
de dados não estruturadas para as quais existem OLE DB Provider disponíveis.
Na Figura 11.27, temos uma visão geral do acesso a fontes de dados, utilizando OLE DB.
Veja que é possível o acesso a qualquer fonte de dados ODBC. Também é possível o acesso sem a
utilização de ODBC, utilizando-se o OLE DB Provider adequado para cada situação. Quando estamos
utilizando OLE DB, temos a figura da fonte de dados e do consumidor de dados. Um OLE DB Provider
é a fonte de dados, já o aplicativo é o consumidor de dados. No próximo item, criaremos páginas ASP
que acessam dados de um Banco de Dados do Microsoft SQL Server 2005. Com isso, nossas páginas
ASP atuarão como consumidores de dados.
Porém OLE DB, na verdade, é uma API (Application Programming Interface) baseada na tecnologia
COM da Microsoft. Utilizar diretamente uma API é algo que requer conhecimentos avançados
de programação, tais como o domínio das linguagens C e C++. Embora seja factível utilizar
diretamente OLE DB, é muito pouco produtivo, além de exigir profissionais com conhecimentos
avançados de programação.
ADO
OLE DB
OLE DB Providers
Jet Exchange Gerenciador ODBC

SQL Server
Provider Server
Provider
Provider

Drivers ODBC
Microsoft Microsoft Microsoft Microsoft Microsoft

Exchange ORACLE
Access SQL Server SQL Server Access
Server
Figura 11.28 Acessando fontes de dados com ADO/OLE DB.
Para solucionar o problema de utilização direta de OLE DB foi criada uma camada adicional de
programação, a qual é conhecida como ADO – Activex Data Objects. Com a utilização de ADO, temos
acesso a uma série de objetos e seus métodos. A utilização dos objetos ADO é bem mais simples do que
a utilização direta da API OLE DB. Com a utilização de ADO, a produtividade do desenvolvedor aumenta
bastante, pois os objetos de ADO são de fácil aprendizagem e utilização, principalmente para quem já
programa em Visual Basic ou Delphi. Quando utilizamos um objeto ADO, o próprio objeto sabe como
converter a chamada feita, para comandos que a API OLE DB entende e é capaz de executar.
Neste e no próximo capítulos sempre que formos fazer acesso a bases de dados, vamos utilizar objetos ADO.
Por exemplo, para estabelecer uma conexão com um Banco de Dados, estaremos utilizando o objeto Connec-
tion; para acessar registros de uma ou mais tabelas do Banco de Dados, utilizaremos um objeto chamado
RecordSet e assim por diante. No Capítulo 13, passaremos a utilizar o ADO.NET, que é a tecnologia de acesso
a dados do .NET. Por exemplo, para criar uma página ASP.NET que consulta dados em um banco de dados do
SQL Server 2005, utilizaremos objetos do ADO.NET. Bem, mas este já é assunto para o Capítulo 13.
Na Figura 11.28, representamos o acesso a dados através de ADO, o qual se comunica com a API OLE DB.
Com isso terminamos nosso estudo sobre os aspectos teóricos necessários ao entendimento da conexão de páginas ASP com Bancos de Dados.
NOTA
A partir do próximo item aprenderemos, na prática, a criar páginas ASP que fazem conexão com Banco de Dados. Grande parte do nosso
trabalho será estudar os objetos, métodos, propriedades e eventos da tecnologia ADO. Nunca é demais salientar que ADO é a forma de
acesso a dados indicada pela Microsoft, para as tecnologias anteriores ao .NET, tais como ASP e Visual Basic 6.0. No site http://
msdn.microsoft.com existem diversos documentos que ensinam como migrar de outras tecnologias mais antigas (como DAO por exemplo),
para a tecnologia ADO/OLE DB. Além disso a Microsoft vem anunciando que as tecnologias mais antigas (como DAO e RDO) serão
descontinuadas, isto é, serão substituídas por ADO.
Outro ponto importante a salientar é que ADO não é somente para uso em aplicações Web. Podemos
utilizar ADO para qualquer aplicação, como as tradicionais aplicações Cliente/Servidor de duas ou três
camadas desenvolvidas em Visual Basic ou qualquer outra linguagem com suporte a ADO/OLE DB.
Neste capítulo, criaremos as páginas ASP utilizando um editor de textos padrão, como o Bloco de Notas. Existem ambientes de desenvolvimento
NOTA
do tipo RAD (Rapid Application Development), para a criação de páginas ASP. Dois dos mais conhecidos são o Visual Interdev, da própria
Microsoft, e o Dreamweaver, da Macromedia.
DESENVOLVIMENTO EM: O MODELO DE OBJETOS

DO ADO – ACTIVEX DATA OBJECTS
PRÉ-REQUISITOS
♦ Noções sobre os modelos de desenvolvimento.
♦ Conhecimento básico de ODBC e OLE DB.
METODOLOGIA
♦ Apresentação dos principais objetos do ADO, para acesso aos dados do servidor SQL Server 2005.
Neste item, teremos uma visão geral do Modelo de Objetos do ADO. Nos demais itens deste capítulo,
vamos utilizar, na prática, alguns destes objetos. Para um estudo detalhado dos objetos do modelo
ADO, consulte o e-book “Criando Sites Dinâmicos com ASP 3.0”, de minha autoria, disponível para
venda no meu site, em http://www.juliobattisti.com.br/ebooksdoautor
Na Figura 11.29, temos uma visão geral dos principais objetos do Modelo de Objetos ADO.
Figura 11.29 O Modelo de Objetos ADO.
Abaixo uma descrição resumida dos principais objetos:
♦ Connection: Este objeto é utilizado para estabelecer uma conexão com uma fonte de dados,
seja através de um driver ODBC ou de um OLE DB Provider. O primeiro passo para acessar uma
fonte de dados é estabelecer uma conexão com esta fonte. Uma vez estabelecida esta conexão,
podemos utilizar outros objetos para extrair, alterar e inserir dados ou qualquer outra operação
que seja permitida pela fonte de dados. Quando estabelecemos a conexão, também podemos
passar informações de autenticação, tais como o nome do usuário e senha, de tal forma que
seja dado acesso aos dados de acordo com as permissões de cada usuário. Por exemplo, podem
existir usuários que devam ter permissão somente para leitura dos dados, já outros usuários
podem necessitar de permissão para leitura e alteração e assim por diante.
Um detalhe importante a ser salientado é que a criação de uma conexão com um Banco de Dados,
através da utilização do objeto Connection, não é obrigatória. Podemos utilizar diretamente os objetos
Command, RecordSet e Record, pois, cada vez que utilizarmos um destes objetos, uma conexão será
automaticamente criada. Porém pode ser mais prática a criação explícita de uma conexão, principalmente
em situações em que muitos comandos são executados contra a fonte de dados. Neste caso, a criação
de uma conexão, com a utilização do objeto Connection, pode melhorar o desempenho da aplicação
Web. Se deixarmos que cada objeto crie a sua própria conexão, teremos um número grande de conexões
com o banco de dados. Cada conexão consome recursos, principalmente memória RAM, no servidor.
Se criarmos um objeto Connection e os demais objetos utilizarem esta conexão, teremos um número
reduzido de conexões, o que melhora bastante o desempenho. Pode parecer pouco significativo para
uma única página ASP. Agora imagine uma página ASP que é acessada por milhares de usuários.
Multiplique o número de usuários pelo número de conexões que a página ASP cria com o Banco de
Dados, e você terá um bom motivo para utilizar o objeto Connection, ao invés de deixar cada objeto
criar a sua própria conexão.
♦ Command: Este objeto pode ser utilizado para executar um comando (uma instrução SQL por
exemplo) em uma fonte de dados. Podemos utilizar este objeto para efetuar uma consulta em
uma ou mais tabelas de um Banco de Dados e retornar o resultado em um objeto RecordSet.
Também podemos utilizar este objeto para alterar a estrutura de um Banco de Dados, desde
que tenhamos permissão para isso. Um dos usos mais comuns do objeto Command é para
executar um stored procedure em um Banco de Dados. Com o uso deste objeto podemos,
inclusive, passar parâmetros de entrada e receber parâmetros de saída de um Stored Procedure.
♦ RecordSet: Este objeto representa um conjunto de registros obtidos a partir de um Banco de

Dados. Este conjunto de registros pode, por exemplo, ter sido retornado devido a uma operação
do objeto Command. Todo objeto RecordSet é formado por linhas e colunas, como se fosse
uma tabela de um Banco de Dados.
♦ Record: Este objeto representa uma única linha (ou seja, um único registro) de um objeto
RecordSet.
♦ Stream: Este objeto é utilizado para manipular dados não estruturados, normalmente
organizados em formas de árvores hierárquicas. Pode ser utilizado para acessar informações de
um sistema de arquivos ou um sistema de correio eletrônico.
Cada um destes objetos apresenta uma série de métodos, propriedades, eventos e coleções.
Na maioria das situações utilizamos os objetos Connection e RecordSet juntos em uma mesma página ASP. No próximo item vamos estudar
NOTA
o objeto Connection, porém já fazendo uso do objeto RecordSet. Nos exemplos práticos será apresentado apenas o básico sobre o objeto
RecordSet. Nos próximos itens deste capítulo, estudaremos mais detalhes sobre o objeto RecordSet.
Antes do primeiro exemplo prático, vamos à definição do que é uma página ASP.
DESENVOLVIMENTO EM: APLICAÇÕES COM ASP – ACTIVE SERVER PAGES

PRÉ-REQUISITOS
♦ Modelo de Objetos do ADO.
METODOLOGIA
♦ Apresentação dos objetos, métodos e propriedades do modelo ADO para acesso aos dados do servidor SQL Server 2005, através de páginas ASP.
TÉCNICA
♦ Utilização dos objetos, métodos e propriedades do modelo ADO para a criação de páginas ASP que acessam aos dados do servidor SQL
Server 2005.
Definir exatamente o que é ASP é uma tarefa que pode gerar controvérsias. Eu, particularmente, gosto
de definir ASP, como sendo: “Uma tecnologia que permite a criação de páginas dinâmicas, nas quais,
além de código HTML, temos código ASP. É justamente este código que fornece toda a funcionalidade
que torna os sites criados em ASP dinâmicos, possibilitando a criação de aplicações Web”.
Uma página ASP é uma “mistura” de código HTML tradicional com código ASP. O código ASP é colocado
entre os marcadores <% (início de um bloco de código ASP) e %> (final de um bloco de código ASP).
Em uma página, podemos ter diversos blocos de código ASP. Desta forma, posso ir intercalando código
ASP e código HTML padrão. O código ASP é que fornece a capacidade de execução de comandos que
fazem conexões com Banco de Dados, retornam resultados e executam cálculos e operações que tornam
as páginas mais dinâmicas. A seguir, um exemplo simples de um arquivo em que temos código ASP e
código HTML na mesma página:
Exemplo 11.1 – A primeira página ASP!!
1 <HTML>
2 <HEAD>
3 <TITLE>Minha primeira página ASP !!</TITLE>
4 </HEAD>
5 <BODY>
6 <%
7 Response.Write “<H1>Data de hoje: “ & Date( ) & “</H1>”
8 Response.Write “<H1>Hora atual: “ & Time( ) & “</H1>”
9 %>
10 </BODY>
11 </HTML>
NOTA
Não digite o número das linhas. A numeração apenas aparece na listagem, para servir como referência na hora de explicarmos o código ASP.
Ao abrir esta página no navegador, obtemos o resultado indicado na Figura 11.30.
Figura 11.30 Nossa primeira página ASP.

NOTA
Salvei este arquivo na pasta Capítulo11 criada anteriormente, com o nome de Exemplo11-1.asp. Por isso o endereço para esta página é o
seguinte: http://servidor/LivroSQL2005/Capitulo11/Exemplo11-1.asp
Se você pressionar F5 para recarregar a página, será exibida a data e hora, já atualizadas. Em resumo,
cada vez que você carregar a página, as funções Date( ) e Time( ) retornarão a data e hora atualizadas.
Veja que é o código ASP que torna a página dinâmica.
Não defino ASP como uma linguagem de script, porque, para a criação de páginas ASP, podemos utilizar
diferentes linguagens de script, tais como VBScript e Java Script. Neste capítulo, utilizaremos o VBScript.
NOTA
Para maiores detalhes sobre o VBScript consulte o endereço http://msdn.microsoft.com/scriptin ou o endereço http://www.serachvb.com.
Você também encontrará informações sobre VBScript e-book “Criando Sites Dinâmicos com ASP 3.0”, citado anteriormente.
Melhor do que definições formais é entender como funciona uma página ASP. Vamos nos basear na
Figura 11.31.
Vamos fazer alguns comentários sobre esta figura.
O servidor Web, no nosso caso o IIS da Microsoft, reconhece que a página solicitada é uma página ASP,
pela extensão da página. As páginas ASP devem ter a extensão .asp. Se criarmos uma página ASP e
salvarmos a página com a extensão .htm ou .html, o IIS simplesmente ignora o código ASP. A criação
de páginas ASP está ligada à utilização do IIS. Não podemos, por exemplo, criar páginas ASP e
disponibilizá-las utilizando outros servidores Web, como o Netscape Web Server ou o Apache.
Internet Servidor Web

www.abc.com
http://www.abc.com/cep.asp
A página ASP é processada no servidor. O resultado do processamento é uma página HTML.

O que retorna para o cliente é a página HTML, já resultante do processamento no servidor Web.
Figura 11.31 Como funciona o ASP.
O usuário digita o endereço http://www.abc.com/cep.asp e tecla Enter. Feito isso, o pedido é enviado
para o servidor www.abc.com. O servidor identifica a extensão do arquivo – .asp. Como a extensão é
.asp, a página cep.asp é passada para o “Interpretador ASP”, o qual faz parte do IIS. O interpretador
percorre toda a página, executando o código ASP e retornando o código HTML, resultante deste
processamento. Com isso, o que é retornado para o usuário que solicitou a página ASP é apenas o
código HTML resultante do processamento do código ASP da página. Este fato pode ser comprovado,
pedindo para que o navegador exiba o código-fonte da página. No caso do Internet Explorer, basta
selecionar a opção Código-fonte, do menu Exibir. O fato de o retorno ser HTML puro traz diversos
benefícios, dentre os quais podemos destacar:
♦ Os algoritmos, bem como o próprio código ASP, ficam protegidos. Isto significa que o usuário
não tem acesso ao código das aplicações Web, desenvolvidas em ASP. Isto é bastante desejável,
uma vez que não seria interessante que qualquer usuário pudesse copiar, livremente, os
algoritmos e códigos da sua empresa.
♦ O acesso a páginas ASP é independente do navegador utilizado. Não importa se estamos

utilizando o Netscape Navigator, o Internet Explorer, ou qualquer outro navegador. Uma vez
que o que retorna é código HTML, qualquer navegador é capaz de acessar uma página ASP.
Em contrapartida, o servidor precisa ser o IIS da Microsoft. Outros servidores ainda não possuem um
interpretador ASP.
Outra questão importante a considerar é o fato de uma página ASP ser interpretada no servidor. Isto
significa que você não pode criar uma página ASP e testá-la localmente, simplesmente abrindo-a no
navegador. Se você criar uma página ASP, salvá-la no seu disco rígido local e tentar abri-la no navegador,
todo o código ASP será ignorado, uma vez que não existe o interpretador ASP. Para poder testar as suas
páginas ASP, você terá que salvá-las em um servidor Web, que esteja rodando o IIS.
Já conversamos bastante e agora é hora de ação. No próximo item, vamos estudar o objeto Connection
e criar uma página ASP que utiliza este objeto para retornar dados de uma tabela de um Banco de
Dados do SQL Server 2005.
O OBJETO CONNECTION
Conforme descrevemos anteriormente, o primeiro passo para conectar uma página ASP com uma
fonte de dados é estabelecer uma “conexão” com a fonte de dados. Para estabelecermos uma conexão
com um Banco de Dados, utilizamos o objeto Connection. Podemos criar uma conexão utilizando
uma fonte ODBC ou um OLE DB Provider. Neste tópico, vamos estudar o objeto Connection, e aprender
a criar conexões utilizando ODBC e também OLE DB. Também veremos alguns exemplos práticos,
onde criaremos páginas .asp que fazem conexão com Bancos de Dados no servidor SQL Server 2005.
CRIANDO CONEXÕES ODBC

Vamos aprender a criar conexões com um Banco de Dados, utilizando fontes ODBC.
O código a seguir cria uma conexão com a fonte ODBC nwind criada anteriormente:
Set conn = Server.CreateObject(“ADODB.Connection”)

conn.Open “nwind”
O primeiro passo é criar a conexão com o Banco de Dados. Para isto, crio um objeto do tipo
ADODB.Connection, depois abro a conexão utilizando o método Open. Como parâmetro para o método
Open, passo o nome da fonte de dados ODBC. No nosso exemplo, o nome da fonte é nwind. Lembre
que esta fonte nwind está associada com o Banco de Dados C:\Meus documentos\Northwind.mdb,
do Microsoft Access.
NOTA
Os objetos ADO têm diversos métodos e propriedades. Um método executa uma ação específica, ação esta representada por um verbo –
abrir, fechar, retornar, etc. As propriedades de um objeto retornam valores ou características do objeto.
Para acessarmos um método ou propriedade de um objeto, utilizamos a seguinte sintaxe:
♦ Para métodos: nome_objeto.nome_método parâmetros
♦ Para propriedades: nome_objeto.propriedade
Um objeto também pode conter eventos. Um evento é uma determinada ação que acontece com o
objeto, como, por exemplo, ao encerrar uma conexão, é gerado o evento Disconnect do objeto Con-
nection. Podemos escrever código ASP que deve ser executado quando um evento é disparado.
O código a seguir cria uma conexão com a fonte ODBC ST1_pubs, criada anteriormente, a qual está
associada ao banco de dados Pubs, da instância SERVIDOR\SQL2005:
conn.Open “ST1_pubs”
Observe que apenas trocamos o nome da fonte ODBC, em relação ao exemplo anterior. Neste exemplo,
o nome da fonte é ST1_pubs. Lembre que esta fonte – ST1_pubs – está associada com o Banco de Dados
pubs da instância SERVIDOR\SQL2005, do servidor SQL Server 2005.
O OBJETO CONNECTION – MÉTODOS, PROPRIEDADES E EVENTOS

Ao estabelecermos uma conexão, estamos informando para a nossa página ASP uma série de detalhes
que a página necessita para poder acessar os dados. Utilizando o objeto Connection podemos definir
qual o OLE DB Provider a ser utilizado, qual a fonte de dados e demais informações tais como nome de
usuário e senha, caso sejam necessários.
Na Tabela 11.2, temos uma breve descrição dos principais métodos do objeto Connection.
Tabela 11.2 Os principais métodos do objeto Connection.
Método Descrição
BeginTrans Inicia uma nova transação.

Cancel Cancela a execução assíncrona dos comandos Execute e Open.
Close Fecha uma conexão que esteja aberta e quaisquer objetos que sejam dependentes desta conexão.
CommitTrans Salva as alterações que foram feitas e encerra a transação corrente.
Execute Executa um consulta, um comando ou uma instrução SQL e retorna um objeto do tipo Recordset. Por
exemplo, pode ser utilizado para obter uma listagem de vendas de um Banco de Dados, ou qualquer
outra listagem que possa ser obtida a partir de uma instrução SQL.
Open Abre uma conexão com uma fonte de dados. Feito isso, comandos podem ser executados através desta
conexão.
OpenSchema Utilizado para obter informação sobre a estrutura de uma fonte de dados, tais como as definições de
tabelas e relacionamentos de um Banco de Dados Relacional.
RoolbackTrans Cancela quaisquer alterações que tenham sido feitas pela transação e finaliza a transação.
Na Tabela 11.3, temos uma breve descrição das principais propriedades do objeto Connection.
Tabela 11.3 As principais propriedades do objeto Connection.
Propriedade Descrição
Attributes Indica uma ou mais características de um objeto Connection. Retorna um valor Long.
CommandTimeout Indica o tempo máximo de execução de um comando. Caso o comando demore mais do que o tempo definido nesta
propriedade, será gerado um erro. O valor padrão é 30 segundos.
ConnectionString Contém todas as informações utilizadas para estabelecer a conexão com a fonte de dados.
ConnectionTimeout Indica o tempo máximo para tentativa de estabelecer uma conexão. Caso a conexão não seja estabelecida em um
tempo menor ou igual ao definido em ConnectionTimeout, a conexão será encerrada e um erro gerado. Por padrão
este valor é definido em 15 segundos.
CursorLocation Define ou retorna a localização do cursor, se no servidor ou no cliente.
continua
continuação
DefaultDatabase Indica qual o Banco de Dados padrão para um objeto Connection. Por exemplo, quando estamos conectando com um
Servidor SQL precisamos definir qual o Banco de Dados que será acessado.
Fazemos isso definindo qual o Banco de Dados padrão, através da utilização da propriedade DefaultDatabase.
Errors Contém todos os objetos Error criados em resposta a falhas envolvendo o provedor de dados.
IsolationLevel Define o nível de isolamento das transações para um objeto Connection.
Mode Indica as permissões disponíveis para modificação de dados através de uma conexão.
Properties Contém todos os objetos Property de um determinado objeto Connection.
Provider Retorna o nome do provedor para uma determinada conexão.
State Indica se a conexão está aberta ou fechada.
Version Retorna a versão da tecnologia ADO. Por exemplo, 2.0 ou 2.5.
Na Tabela 11.4, temos uma breve descrição dos principais eventos do objeto Connection.
Tabela 11.4 Os principais eventos do objeto Connection.
Evento Descrição
BeginTransComplete Ocorre após o término de uma operação BeginTrans.

CommitTransComplete Ocorre após o término de uma operação CommitTrans.
ConnectComplete Ocorre após o início de uma conexão.
Disconnect Ocorre após o término de uma conexão.
ExecuteComplete Ocorre após o término da execução de um comando.
InfoMessage Ocorre toda vez que a operação ConnectionEvent ocorre com sucesso e informação adicional é retornada pelo
provedor de dados.
RollBackTransComplete Ocorre após a execução da operação RollbackTrans.
WillConnect Ocorre antes do início de uma conexão.
WillExecute Ocorre antes que um comando pendente é executado em uma determinada conexão.
CRIANDO CONEXÕES UTILIZANDO OLE DB

Vamos aprender a criar conexões com um Banco de Dados, utilizando fontes da tecnologia OLE DB.
Ao utilizarmos OLE DB, não precisamos criar uma “fonte OLE DB”; ao invés disso, todo o código
necessário para estabelecer a conexão está na própria página ASP que, conforme veremos a seguir, é
simplesmente a definição da propriedade ConnectionString, do objeto Connection.
Conforme ilustrado na Figura 11.27, é possível o acesso a uma fonte de dados, sem a utilização de
ODBC. Este é um ponto de confusão entre muitos programadores iniciantes em ASP. Em diversas
conversas com colegas que estavam iniciando o estudo de ASP, surgiu esta dúvida:
“É possível conectar com uma fonte de dados, como, por exemplo, um Banco de Dados do Microsoft
Access ou do SQL Server 2005, sem a utilização de um driver ODBC?”
A resposta é sim; é perfeitamente possível, e para isto basta criar um objeto Connection e configurar
corretamente a sua propriedade ConnectionString.
A propriedade ConnectionString deve conter as informações necessárias para estabelecer a conexão

com uma fonte de dados. Através desta propriedade, devemos fornecer informações tais como:
♦ Provedor
♦ Nome do usuário
♦ Senha do usuário
♦ Nome do arquivo (como no caso de um Banco de Dados do Microsoft Access)
♦ Nome do servidor\instância (como no caso de um Servidor SQL Server)
♦ Nome do Banco de Dados no servidor.
São informações necessárias para que a página ASP possa estabelecer a conexão com a fonte de dados,
utilizando o OLE DB Provider correto. Pode até ser que seja utilizado o OLE DB Provider para ODBC,
mas isto não é obrigatório.
Agora aprenderemos um pouco mais sobre a propriedade ConnectionString. Também veremos alguns
exemplos de utilização desta propriedade.
A PROPRIEDADE CONNECTIONSTRING
Esta propriedade é configurada de diferentes maneiras, de acordo com a fonte de dados que estiver
sendo utilizada. Por exemplo, a configuração para acessar um Banco de Dados do Microsoft Access é
diferente da configuração para acessar um Banco de Dados do Microsoft SQL Server ou do Oracle.
Vamos estudar como configurar esta propriedade para acessar algumas das principais fontes de dados:
Microsoft Access, Microsoft SQL Server e Oracle.
A propriedade ConnectionString tem uma série de parâmetros no formato:
argumento = valor
onde argumento pode ser a informação sobre o provedor, o nome do usuário, etc. Apenas a título de
exemplo, mostramos a seguir a propriedade ConnectionString para conexão com um Banco de Dados
do Microsoft Access:
Provider=MSDASQL.1;Data Source=nwind;
Extended Properties=”DSN=nwind;
DBQ=C:\MEUS DOCUMENTOS\NWIND.MDB;DriverId=281;FIL=MS Access;MaxBufferSize=2048;PageTimeout=5;”
NOTA
Exibimos a propriedade em diversas linhas, por questão de espaço. Quando estiver criando uma página .asp, coloque, sempre, um comando
em cada linha.
Agora vamos decifrar o que significam estes parâmetros e aprender a utilizar esta propriedade,
configurando conexões OLE DB, com um Banco de Dados do Microsoft Access.
Vamos configurar a propriedade ConnectionString para estabelecer uma conexão com um Banco de
Dados do Microsoft Access. Para tal, devemos configurar os parâmetros indicados na Tabela 11.5.
Tabela 11.5 Definindo a propriedade ConnectionString para uma fonte do Microsoft Access.
Parâmetro Descrição
Provider Deve ser especificado o OLE DB Provider para o Microsoft Access. Para esta propriedade, utilizamos o seguinte valor:
Microsoft.Jet.OLEDB.4.0.
Data Source Informamos o caminho para o arquivo .mdb. Por exemplo, C:\Arquivos de programas\office\nwind.mdb.
User ID Especifica o nome do usuário com o qual a conexão será estabelecida. Caso esta propriedade não seja informada, esta
será definida como “admin”, o qual é o usuário padrão.
Password Informa a senha para o usuário que fará a conexão. Caso esta propriedade não seja informada, a senha será definida
como “ “.
Por padrão, o OLE DB Provider para Microsoft Access (também chamado de Jet OLE DB Provider) abre o Banco de Dados com permissão de
NOTA
leitura e escrita, isto é, os dados também podem ser modificados. Para alterar o modo de abertura para, por exemplo, somente escrita,
devemos utilizar a propriedade Mode, do objeto Connection.
A seguir, temos um exemplo de uma conexão com um Banco de Dados do Microsoft Access, utilizando
a propriedade ConnectionString:
Set conn=Server.CreateObject(“ADODB.Connection”)
conn.Open “PROVIDER=MICROSOFT.JET.OLEDB.4.0;
DATA SOURCE=c:\meus documentos\Northwind.mdb”
Primeiro, criamos um objeto do tipo Connection. Depois, utilizamos o método Open, para abrir esta
conexão. Observe que, após o método Open, é passada uma string de conexão como parâmetro para o
método Open. Este parâmetro é a propriedade ConnectionString.
Poderíamos obter o mesmo resultado de uma maneira diferente: primeiro, vamos definir a propriedade
ConnectionString, depois simplesmente chamamos o método Open. Ao chamar o método Open, este verifica
se a propriedade ConnectionString já está definida e utiliza esta propriedade. Nosso exemplo ficaria assim:
1 Set conn=Server.CreateObject(“ADODB.Connection”)
2 conn.ConnectionString = “PROVIDER=MICROSOFT.JET.OLEDB.4.0;DATA
SOURCE=c:\meus documentos\Northwind.mdb”
3 conn.Open
Neste caso, na linha 1, foi definida a propriedade ConnectionString e, depois, na linha 3, utilizamos o
método Open.
NOTA
Utilizamos os números de linha apenas para referência. Quando criamos nossas páginas ASP, não devemos utilizar números de linhas.
NOTA
A linha 2 aparece “quebrada” em duas linhas por questões de espaço para exibição, mas os comandos devem ser digitados em uma única linha.
No exemplo a seguir, temos um caso onde foi fornecido o nome do usuário e a senha para conexão.
2 conn.ConnectionString = “PROVIDER=MICROSOFT.JET.OLEDB.4.0;
DATA SOURCE=c:\meus documentos\nwind.mdb;
User ID=jsilva;Password=senha12"
3 conn.Open
Para maiores detalhes sobre segurança de Bancos de Dados do Microsoft Access, consulte o curso
– Access Avançado e VBA – 550 páginas, de minha autoria. Maiores detalhes no meu site, em
http://www.juliobattisti.com.br
CONFIGURANDO CONEXÕES COM BANCOS DE DADOS

DO MICROSOFT SQL SERVER 2005
Para configurar a propriedade ConnectionString para estabelecer uma conexão com um Banco
de Dados de uma instância do Microsoft SQL Server 2005, configuramos os parâmetros indicados
na Tabela 11.6.
Tabela 11.6 Definindo a propriedade ConnectionString para uma fonte do Microsoft SQL Server 2005.
Provider Deve ser especificado o OLE DB Provider para o Microsoft SQL Server. Para esta propriedade utilizamos o seguinte
valor: SQLOLEDB.
Data Source ou Server Informamos o nome do servidor SQL, no formato Servidor\Instância. Por exemplo: SERVIDOR\SQL2005 ou
SERVIDOR\CURSOSJB
Initial Catalog ou Database Nome do Banco de Dados a ser utilizado. Em um Servidor SQL Server, podem existir
vários Bancos de Dados.
User ID ou uid Especifica o nome do usuário com o qual a conexão será estabelecida.
Password ou pwd Informa a senha para o usuário que fará a conexão. Caso esta propriedade não seja informada, a senha será
definida como “ “.
O PRIMEIRO EXEMPLO – CONECTANDO COM O BANCO DE DADOS NORTHWIND,

DA INSTÂNCIA SERVIDOR\SQL2005
NOTA
É importante lembrar que o banco de dados Northwind não é instalado juntamente com o SQL Server 2005. Nós importamos o banco de
dados Northwind, de uma instância do SQL Server 2000, para a instância SERVIDOR\SQL2005, do SQL Server 2005. Fizemos isso usando o
DTS Import/Export Wizard, o qual você aprendeu a utilizar, na prática, nos Capítulos 7 e 9.
No Exemplo 11.2, temos um exemplo de uma conexão com um Banco de Dados do Microsoft SQL
Server, utilizando a propriedade ConnectionString.
NOTA
Crie este exemplo utilizando o editor de textos de sua preferência. Não inclua o número das linhas, os quais servem apenas para referência.
Salve este exemplo na pasta C:\LivroSQL2005\Capitulo11, com o nome de Exemplo11-2.asp.
Exemplo 11.2 – Conectando com um Banco de Dados do Microsoft SQL Server 2005 – Exemplo11-2.asp.
1 <%@ Language=VBScript %>

2 <HTML>
3 <HEAD>
4 <TITLE>Conectando com o SQL Server 2005</TITLE>
5 </HEAD>
6 <BODY>
7 <H1>
8 <FONT color=navy>Registros da tabela Orders !!!!</FONT>
9 </H1>
10 <%
11 ‘O primeiro passo é criar a conexão com o Banco de Dados
12 ‘Para isto crio um objeto do tipo Connection
13 ‘Cria um objeto do tipo ADODB.Connection
15 ‘Agora defino a propriedade ConnectionString do objeto Connection

16 ‘criado anteriormente.
17 conn.ConnectionString = “PROVIDER=SQLOLEDB;
Data Source=SERVIDOR\SQL2005 ;Initial Catalog=Northwind;
User ID=sa;Password=abc123"
18 conn.Open
19 ‘O próximo passo é criar uma instrução SQL
20 inst_sql=“SELECT Orders.OrderID, Orders.OrderDate, Orders.ShipCity, Orders.ShipCountry

FROM Orders ORDER BY Orders.OrderDate”
21 ‘Esta instrução SQL retorna os campos OrderID, OrderDate,

‘ShipCity e ShipCountry, da tabela Orders, do Banco de Dados NorthWind.
22 ‘Agora criamos um objeto RecordSet.

23 ‘Este objeto irá executar a instrução SQL e
24 ‘receber o resultado da consulta.
25 Set Pedidos = Server.CreateObject(“ADODB.Recordset”)
26 ‘Agora executamos a instrução SQL

27 Pedidos.Open inst_sql, conn, 3, 3
28 ‘Neste ponto, já tenho todos os registros retornados

29 ‘pela instrução SQL. Estes registros estão armazenados
30 ‘no objeto Clientes, que é um objeto do tipo Recordset.
31 ‘Agora, passo a montar a página que será retornada para o
32 ‘navegador do Cliente. Vamos montar uma tabela com o
33 ‘resultado da consulta.
34 %>
35 <P>
36 <HR>
37 <TABLE bgColor=gray border=1 borderColor=navy cellPadding=1 cellSpacing=1 width=“100%”>
38 <TR>
39 <TD align=middle bgColor=gray>Código </TD>
40 <TD align=middle bgColor=gray>Data </TD>
41 <TD align=middle bgColor=gray>Cidade </TD>
42 <TD align=middle bgColor=gray>País </TD>
43 </TR>
44 <%
45 ‘Inicio um Loop para percorrer todos os registros

46 ‘do RecordSet Clientes, exibindo um registro em
47 ‘cada linha da tabela.
48 Do Until Pedidos.eof %>
49 <TR>
50 <TD align=middle bgColor=gray><%=Pedidos.Fields(“OrderID”)%></TD>
51 <TD align=middle bgColor=gray><%=Pedidos.Fields(“OrderDate”)%></TD>
52 <TD align=middle bgColor=gray><%=Pedidos.Fields(“ShipCity”)%></TD>
53 <TD align=middle bgColor=gray><%=Pedidos.Fields(“ShipCountry”)%></TD>
54 </TR>
55 <%
56 Pedidos.MoveNext
57 loop
58 %>
59 </TABLE>
60 </P>
61 <HR>
62 </BODY>
63 </HTML>
Ao acessarmos este arquivo, obtemos o resultado indicado na Figura 11.32.

NOTA
Para que você possa utilizar a conta sa para login no servidor SQL Server, o modo de segurança precisa estar configurado para “SQL
Server and Windows Authentication Mode”. Para informações sobre como alterar o modo de segurança de uma instância do servidor
SQL Server 2005, consulte o Capítulo 6 – Segurança no SQL Server 2005.
Vamos comentar alguns detalhes sobre o código do Exemplo 11.2.
Primeiro, vamos considerar o seguinte fragmento de código:
Data Source=SERVIDOR\SQL2005 ;Initial Catalog=Northwind;
User ID=sa;Password=abc123”
18 conn.Open
Observe que, neste caso, primeiro definimos a propriedade ConnectionString. Depois, utilizamos o método
Open, para abrir a conexão. Como a propriedade ConnectionString já estava definida, o método Open
utiliza as informações da propriedade ConnectionString para estabelecer a conexão com o Banco de Dados.
Figura 11.32 Registros da tabela Orders do Banco de Dados Northwind

da instância SERVIDOR\SQL2005 do servidor SQL Server 2005.
Segundo, vamos considerar a string de conexão:
“PROVIDER=SQLOLEDB;
Data Source=SERVIDOR\SQL2005;
Initial Catalog=Northwind;
Observe que estamos informando os parâmetros indicados na Tabela 11.7.
Tabela 11.7 Parâmetros para a string de conexão com o servidor SQL Server 2005.
Parâmetro Valor fornecido
Provider SQLOLEDB
Data Source ou Server SERVIDOR\SRVINST01
Initial Catalog/Database Northwind
User ID ou uid sa
Password ou pwd senha123
Temos dois parâmetros que merecem comentários.
O parâmetro Data Source ou Server foi informado da seguinte maneira:
SERVIDOR\SQL2005
Este formato, conforme descrito nos capítulos iniciais do livro, é uma novidade que foi introduzida no
SQL Server 2000 e que também faz parte do Microsoft SQL Server 2005. O valor antes da barra (\) é o
nome do servidor e o valor depois da barra é o nome da “instância” do SQL Server a ser utilizada. Com
o Microsoft SQL Server 2005, posso ter várias instâncias do servidor SQL em um único servidor, isto é,
como se eu tivesse vários servidores SQL Server 2005 diferentes no mesmo servidor, sendo que cada
um deles deve possuir um nome diferente. Neste livro estamos utilizando um servidor com duas
instâncias, conforme indicado a seguir:
SERVIDOR\SQL2005
SERVIDOR\CURSOSJB
Quando vou definir a string de conexão, preciso definir qual a instância que quero conectar à página ASP.
Se você estiver utilizando o Microsoft SQL Server 7.0 ou versão inferior, basta fornecer o nome do
servidor. Neste caso definiríamos a propriedade ConnectionString da seguinte maneira:
“PROVIDER=SQLOLEDB;
Data Source=SERVIDOR;
Initial Catalog=Northwind;
Observe que estamos conectando com o Banco de Dados Northwind. Dentre deste Banco de Dados, a
nossa instrução SQL acessa dados da tabela Orders, conforme indicado pelo seguinte fragmento de código:
20 inst_sql=“SELECT Orders.OrderID, Orders.OrderDate, Orders.ShipCity, Orders.ShipCountry

FROM Orders ORDER BY Orders.OrderDate”
Com esta instrução são retornados os campos OrderID, OrderDate, ShipCity e ShipCountry. Além
disso, a listagem obtida é classificada pelo campo OrderDate, conforme pode ser confirmado pelos
resultados exibidos na Figura 11.32.
O restante do código é para a construção da tabela e exibição de um registro em cada linha.
CONFIGURANDO CONEXÕES OLE DB, COM BANCOS DE DADOS ORACLE

Para configurar a propriedade ConnectionString para estabelecer uma conexão com um Banco de
Dados de um servidor ORACLE, podemos configurar os parâmetros indicados na Tabela 11.8.
Tabela 11.8 Definindo a propriedade ConnectionString para uma fonte ORACLE.
Provider Deve ser especificado o OLE DB Provider para o ORACLE. Para esta propriedade utilizamos o seguinte valor: MSDAORA.
Data Source Informamos o nome do Servidor ORACLE.
User ID Especifica o nome do usuário com o qual a conexão será estabelecida.
Password Informa a senha para o usuário que fará a conexão.
A seguir, temos um exemplo de uma conexão com um Banco de Dados, utilizando a propriedade
ConnectionString:
2 conn.Open “Provider=MSDAORA;Data Source=SERVIDOR;User ID=admin;
Password=admin123”
Primeiro, criamos um objeto do tipo Connection. Depois, utilizamos o método Open, para abrir esta
conexão. Observe que, após o método Open, é passada uma string de conexão como parâmetro para
este método. Este parâmetro é a propriedade ConnectionString.
Poderíamos obter o mesmo resultado de uma maneira diferente: primeiro, vamos definir a propriedade
ConnectionString, depois simplesmente chamamos o método Open. Ao chamar o método Open, este
verifica se a propriedade ConnectionString já está definida e utiliza o valor definido nesta propriedade.
Nosso exemplo ficaria assim:
2 conn.ConnectionString = “ Provider=MSDAORA;Data Source=SERVIDOR;
User ID=admin; Password=admin123”
3 conn.Open
Neste caso, na linha 2 foi definida a propriedade ConnectionString e, na linha 3, utilizamos o método Open.
NOTA
Utilizamos os números de linha apenas para referência. Quando criamos nossas páginas ASP, não devemos utilizar números de linhas.
A linha 2 aparece “quebrada” em duas linhas por questões de espaço para exibição, mas a mesma deve ser digitada em uma única linha.
Para detalhes sobre o ORACLE, consulte a documentação do produto.
Microsoft Access, Microsoft SQL Server e ORACLE são os casos mais comuns de conexões de páginas ASP
com fontes de dados. Porém, conforme descrito no Capítulo 5, através de OLE DB podemos estabelecer
conexões com qualquer fonte de dados, para a qual esteja disponível um OLE DB Provider, inclusive
fontes de dados não estruturadas no formato de Bancos de Dados Relacionais. Como exemplos de fontes
que não possuem o tradicional formato dos Bancos de Dados Relacionais, poderíamos citar os arquivos
de mensagens de correio eletrônico do Microsoft Exchange ou do Lotus Notes, um catálogo de indexação
do Microsoft Index Server ou, até mesmo, uma fonte de dados residente em um mainframe.
COMENTÁRIOS FINAIS SOBRE O OBJETO CONNECTION

Agora veremos mais alguns detalhes importantes sobre o objeto Connection.
Conforme mostrado no Exemplo 11.2, para conectar uma página ASP com uma fonte de dados, estamos
utilizando os seguintes passos:
♦ Criamos um objeto do tipo Connection e conectamos este objeto com uma fonte de dados,
seja via ODBC, seja via OLE DB.
♦ Criamos um objeto do tipo RecordSet e executamos uma instrução SQL. Feito isto, o objeto
RecordSet conterá os dados retornados pela fonte de dados.
Uma vez obtidos os dados, utilizamos código ASP para exibir os resultados desejados. Esta metodologia funciona
sem maiores problemas, porém existem alguns aspectos importantes a serem considerados, tais como o
encerramento de uma conexão e o nível de acesso aos dados oferecido por uma determinada conexão.
O MÉTODO CLOSE
O método Close é utilizado para fechar/encerrar uma conexão e quaisquer outros objetos que sejam
dependentes da conexão. Por exemplo, se criamos um objeto RecordSet que obteve dados a partir da
conexão que está sendo encerrada, o objeto RecordSet também será encerrado.
A sintaxe deste método é bastante simples. Vamos supor que tenhamos criado uma conexão chamada
clientes; para encerrá-la, poderíamos utilizar o seguinte código:
<% Clientes.Close %>
Ao fecharmos um objeto, estaremos liberando os recursos computacionais que o objeto utilizava no

servidor, tais como memória e processador. Porém, o objeto continua na memória, e com isso podemos
utilizar o método Open para abrir novamente a conexão e voltar a utilizá-lo. No exemplo abaixo,
fechamos o objeto clientes e depois voltamos a abri-lo, utilizando o método Open.
<% Clientes.Close
Clientes.Open
%>
Neste caso poderíamos voltar a utilizar o objeto clientes. Para remover um objeto, em definitivo, da
memória, devemos definir o seu valor como “Nothing”, conforme indicado no exemplo:
<%
Set Clientes = Nothing
%>
Feito isso, somente poderemos voltar a utilizar o objeto se este for novamente criado, utilizando o
seguinte código:
Set Clientes = Server.CreateObject(“ADODB.Connection”)
Observe que, pelo fato de clientes ser um objeto (do tipo Connection) e não simplesmente uma variável,
devemos utilizar o operador Set. Se tentarmos criar ou remover um objeto, sem a utilização do operador
Set, obteremos uma mensagem de erro e a página não será exibida.
“POOL” DE CONEXÕES
Quando um usuário fecha uma conexão, através da utilização do método Close, conforme descrito
anteriormente, esta conexão é mantida na memória e a conexão é adiciona a um “pool” de conexões
inativas. Da próxima vez que o mesmo usuário, ou qualquer outro usuário, for abrir uma nova conexão,
o OLE DB primeiro verifica se, no pool de conexões inativas, existe uma conexão exatamente igual à
que o usuário está solicitando. Se for encontrada, esta conexão será utilizada, caso contrário uma nova
conexão será criada e enviada para o usuário que solicitou.
O OLE DB mantém um pool de conexões, porque o processo de criar uma conexão é o que mais exige
recursos do servidor Web. Sempre que uma conexão puder ser reaproveitada, a partir do pool de
conexões, economizaremos preciosos recursos do servidor.
As conexões inativas não permanecem indefinidamente no pool de conexões. Após um período padrão
sem utilização, estas são removidas, de tal forma a não onerar os recursos do servidor Web, sem que as
conexões estejam sendo utilizadas.
A utilização de pool de conexões é de grande importância, principalmente para servidores Web
muito acessados, em que novas conexões estão sendo criadas e fechadas a todo instante. Neste
caso, o pool de conexões representa um alívio na carga de recursos de hardware do servidor, tais
como memória RAM e processador.
Com isso, encerramos nosso estudo básico sobre conexões com a utilização de OLE DB. Na seqüência,
vamos ver um exemplo simples de conexão com Banco de Dados, utilizando uma fonte ODBC.
UM EXEMPLO UTILIZANDO ODBC

Neste item, vamos utilizar a fonte ODBC, nwind, criada anteriormente, para criar uma página ASP que
conecta o Banco de Dados Northwind.mdb do Access e mostra uma listagem de clientes com as seguintes
informações da tabela clientes:
♦ Código do cliente (CódigoDoCliente).
♦ Cargo (CargoDoContato).
♦ Endereço (Endereço).
♦ Telefone (Telefone).
NOTA
O nome entre parênteses é o nome do campo na tabela clientes do Banco de Dados C:\Meus documentos\Northwind.mdb, o qual é o banco
associado à fonte ODBC nwind.mdb. Caso você esteja utilizando outro Banco de Dados ou outra tabela, utilize os nomes de campo adequados.
Na Figura 11.33, podemos ver a estrutura da tabela clientes que está sendo utilizada no nosso exemplo.
Figura 11.33 A tabela clientes do Banco de Dados Northwind.
No Exemplo 11.3 apresentamos uma página ASP que faz a conexão com o Banco de Dados Northwind.mdb
e exibe uma listagem de clientes. Após a listagem explicaremos cada um dos comandos utilizados.
NOTA
Crie este exemplo utilizando o editor de textos de sua preferência. Não inclua o número das linhas, os quais servem apenas para referência.
Salve este exemplo na pasta C:\LivroSQL2005\Capitulo11, com o nome de Exemplo11-3.asp.
Exemplo 11.3 – Uma página ASP que conecta com o Banco de Dados Northwind – Exemplo11-3.asp.
1. <%@ Language=VBScript %>

2 <HTML>
3 <HEAD>
4 <TITLE>Clientes no Banco de Dados Northwind !</TITLE>
5 </HEAD>
6 <BODY>
7 <H1>
8 <FONT color=navy>Listagem de Clientes !!!</FONT>
9 </H1>
10 <%

13 ‘Cria um objeto do Tipo ADODB.Connection
14 Set conn = Server.CreateObject(“ADODB.Connection”)
15 ‘Agora abro uma conexão com a fonte ODBC “nwind”

16 ‘criada anteriormente.
17 conn.Open “nwind”
18 ‘O próximo passo é criar uma instrução SQL

19 ‘a qual é utilizada para criar a listagem de Clientes.
20 inst_sql=“SELECT Clientes.CódigoDoCliente, Clientes.CargoDoContato,

Clientes.Endereço,Clientes.Telefone FROM Clientes”
21 ‘Esta instrução SQL retorna os campos CódigoDoCliente, CargoDoContato,

22 ‘Endereço e Telefone, da tabela Clientes.

26 Set Clientes = Server.CreateObject(“ADODB.Recordset”)

28 ‘retornando os registros da tabela Clientes.
29 Clientes.Open inst_sql, conn, 3, 3
30 ‘Os dois últimos parâmetros serão discutidos

31 ‘no próximo item, quando estudarmos o objeto RecordSet em detalhes.
32 ‘Neste ponto já tenho todos os registros retornados

33 ‘pela instrução SQL. Estes registros estão armazenados
34 ‘no objeto Clientes, que é um objeto do tipo RecordSet.
35 ‘Agora passo a montar a página que será retornada para o

36 ‘navegador do Cliente. Vamos montar uma tabela com o
37 ‘resultado da consulta.
38 %>
39 <P>
40 <HR>
42 <TR>
43 <TD align=middle bgColor=gray>Código</TD>
44 <TD align=middle bgColor=gray>Cargo</TD>
45 <TD align=middle bgColor=gray>Endereço</TD>
46 <TD align=middle bgColor=gray>Telefone</TD>
47 </TR>
48 <%
49 ‘Inicio um Loop para percorrer todos os registros

50 ‘do RecordSet Clientes, exibindo um registro em
51 ‘cada linha da tabela.
52 Do Until Clientes.eof %>
53 <TR>
54 <TD align=middle bgColor=gray><%=Clientes.Fields(“CódigoDoCliente”)%></TD>
55 <TD align=middle bgColor=gray><%=Clientes.Fields(“CargoDoContato”)%></TD>
56 <TD align=middle bgColor=gray><%=Clientes.Fields(“Endereço”)%></TD>
57 <TD align=middle bgColor=gray><%=Clientes.Fields(“Telefone”)%></TD>
58 </TR>
59 <%
60 Clientes.MoveNext
61 loop %>
62 </TABLE>
63 </P>
64 <HR>
65 </BODY>
66 </HTML>
Ao carregar esta página no Internet Explorer, o usuário recebe uma listagem conforme indicado na
Figura 11.34.
Antes de comentarmos esta listagem gostaria, mais uma vez, de salientar a natureza dinâmica das
páginas criadas com ASP. Neste exemplo, qualquer alteração que seja feita nos dados da tabela clientes
refletirá na listagem de clientes, na próxima vez que o usuário carregar a página Exemplo11-3.asp. Isto
acontece porque a listagem é montada, a partir do Banco de Dados, cada vez que a página é carregada.
Com isso, ao carregar a página, todos os dados existentes na tabela clientes serão exibidos. Por isso que
dizemos que a página é criada dinamicamente, ou seja, cada vez que a página é solicitada, o código
ASP estabelece a conexão com o Banco de Dados, solicita a listagem atualizada de clientes e apresenta
a listagem no formato de uma tabela, conforme definimos.
Agora vamos às explicações a respeito do código do Exemplo11.3. Embora existam diversos comentários
na própria listagem, cabem aqui alguns esclarecimentos. Vamos detalhar diversos trechos de código
deste exemplo.
Trecho 1: Considere o seguinte trecho de código:
14 Set conn = Server.CreateObject(“ADODB.Connection”)
Figura 11.34 A listagem de clientes do Banco de Dados Northwind.mdb
Esta linha cria um objeto Connection chamado conn. Poderíamos utilizar qualquer nome válido para
este objeto. Um ponto importante a salientar é a utilização da instrução Set. Sempre que formos criar
um objeto (Connection, Recordset, etc.), devemos usar a instrução Set. Se não utilizarmos a instrução
Set na criação de objetos, obteremos um erro na hora de carregar a página.
Também é importante observarmos o seguinte:
Server.CreateObject(“ADODB.Connection”)
Este código cria um objeto no servidor, sendo que este objeto é do tipo ADODB.Connection, ou seja,
uma conexão ADO para Banco de Dados.
Após a execução deste comando, um objeto Connection foi criado, porém o objeto ainda não faz
referência a nenhum Banco de Dados específico.
Trecho 2: Considere o seguinte trecho de código:
15 ‘Agora abro uma conexão com a fonte ODBC “nwind”

16 ‘criada anteriormente.
17 conn.Open “nwind”
Na linha 17, estou associando a conexão conn a uma fonte ODBC nwind. Lembrando que esta fonte
ODBC foi criada previamente. Caso você esteja utilizando uma fonte ODBC diferente, utilize o nome
adequado. Esta associação é feita através do método Open, do objeto Connection. A partir deste
momento, a minha conexão conn está associada ao Banco de Dados Northwind.mdb, conforme definido
pela fonte ODBC nwind.
Uma vez estabelecida a conexão, é hora de retornar dados, isto é, registros, a partir do Banco de Dados.
Isto é feito pelo trecho de código a seguir.
Trecho 3: Considere o seguinte trecho de código.
20 inst_sql=“SELECT Clientes.CódigoDoCliente, Clientes.CargoDoContato,

Clientes.Endereço,Clientes.Telefone FROM Clientes”
21 ‘Esta instrução SQL retorna os campos CódigoDoCliente, CargoDoContato,

22 ‘Endereço e Telefone, da tabela Clientes.

26 Set Clientes = Server.CreateObject(“ADODB.Recordset”)

28 ‘retornando os registros da tabela Clientes.
30 ‘Os dois últimos parâmetros serão discutidos

31 ‘durante o estudo do objeto Recordset.
Na linha 20, simplesmente, criamos uma variável chamada inst_sql, a qual contém a instrução SQL
que será executada no Banco de Dados Northwind.mdb. Observe que é uma instrução SQL bastante
simples, a qual, basicamente, seleciona os campos CódigoDoCliente, CargoDoContato, Endereço e
Telefone da tabela clientes do Banco de Dados Northwind.mdb.
Uma vez definida a instrução SQL, partimos para a criação de um objeto RecordSet. A criação deste
objeto é feita na linha 26, onde é criado um RecordSet chamado clientes. Poderíamos ter escolhido
qualquer nome para este objeto. Observe a utilização da instrução Set. Como estamos criando um
objeto (do tipo RecordSet), devemos utilizar a instrução Set.
Agora devemos executar a instrução SQL, para que o objeto Recordset contenha os registros retornados
pela instrução SQL. Isto é feito pelo seguinte código:
Neste caso, utilizamos o método Open do objeto RecordSet Clientes. O primeiro parâmetro é a instrução
SQL a ser utilizada – inst_sql. O segundo parâmetro é o nome da conexão a ser utilizada – conn. O terceiro
e quarto parâmetros definem comportamentos para o objeto RecordSet, tais como se é possível mover-se
para frente e para trás, avançando e voltando pelos registros, se os registros retornados são apenas para
leitura ou para leitura e alterações e assim por diante. Estudaremos estas opções no próximo tópico.
Bem, neste momento já temos um objeto RecordSet chamado clientes, o qual possui uma série de
registros obtidos a partir da tabela clientes do Banco de Dados Northwind. Cada registro tem quatro
campos, conforme foi definido pela nossa instrução SQL, que somente retorna os campos
CódigoDoCliente, CargoDoContato, Endereço e Telefone.
Uma vez que o RecordSet Clientes foi criado com sucesso, é hora de criarmos uma tabela que exibe os
dados do objeto RecordSet. Começamos criando a primeira linha da tabela, a qual irá conter o título
das colunas. Isto é feito pelo código descrito a seguir.
Trecho 4: Considere o seguinte trecho de código.
42 <TR>
43 <TD align=middle bgColor=gray>Código</TD>
44 <TD align=middle bgColor=gray>Cargo</TD>
45 <TD align=middle bgColor=gray>Endereço</TD>
46 <TD align=middle bgColor=gray>Fone</TD>
47 </TR>
Observe que, para criar o cabeçalho da tabela, utilizamos código HTML puro. Veja que estamos criando
uma tabela com quatro colunas. Vamos exibir um registro por linha; como cada registro tem quatro
campos, precisamos de uma tabela com quatro colunas. Esta tabela terá tantas linhas quantos forem os
registros do objeto Clientes.
A construção do corpo da tabela é feita com o seguinte trecho de código:
52 Do Until Clientes.eof %>
53 <TR>
58 </TR>
59 <%
61 loop %>
62 </TABLE>
Na linha 52, iniciamos um laço Do Until Condição... Loop. Como condição utilizamos a propriedade
Eof do objeto Clientes. O laço continua sendo executado, até que a condição Clientes.eof se torne
verdadeira. Esta condição somente irá tornar-se verdadeira quando o indicador de registro já estiver
além do último registro, ou seja, após ter sido atingido o último registro do objeto RecordSet. Com
isso, o laço somente será encerrado depois que tivermos percorrido todos os registros do objeto Clientes,
que é exatamente o que queremos.
Para cada registro é criada uma nova linha na tabela. Isto é feito pelo seguinte trecho de código:
53 <TR>
58 </TR>
Observe o fragmento de código:
<%=Clientes.Fields(“CódigoDoCliente”)%>
Este fragmento retorna o valor do campo CódigoDoCliente do registro atual do RecordSet Clientes.
Com isso, vamos preenchendo cada coluna com os respectivos valores de cada campo de cada registro.
A primeira coluna com o campo CódigoDoCliente, a segunda com o campo CargoDoContato e assim
por diante. Neste caso, utilizamos a coleção Fields do RecordSet Clientes, a qual nos dá acesso aos
campos individuais de cada registro.
As linhas seguintes são de grande importância:
59 <%
61 loop %>
62 </TABLE>
Se não colocássemos a linha 60, esta página ASP entraria em Loop infinito e somente o primeiro
registro seria exibido repetidamente, até congelar a página. Quando criamos um objeto RecordSet, por
padrão, o indicador de registro é posicionado no primeiro registro. Utilizamos o método MoveNext
para mover o indicador para o próximo registro. Com isso, a cada passagem do laço Do Until, o
indicador é posicionado no próximo registro, até o momento em que todos os registros foram
percorridos. Se não houvesse esta linha, o indicador ficaria sempre no primeiro registro e o laço nunca
seria encerrado, pois a condição Clientes.eof seria sempre verdadeira, impedindo que o laço fosse
encerrado. A linha 62 é simplesmente a tag HTML de fechamento da tabela.
Já vimos alguns exemplos nos quais utilizamos o objeto RecordSet. Agora vamos estudá-lo em detalhes.
Vamos falar sobre seus métodos, propriedades e eventos. Também veremos exemplos de utilização do
objeto RecordSet.
O OBJETO RECORDSET
Nos exemplos que foram apresentados até aqui, já utilizamos o objeto RecordSet. Agora chegou o
momento de fazer um estudo mais aprofundado deste objeto.
O objeto RecordSet contém o resultado de uma instrução SQL, executada em um Banco de Dados. Um
objeto RecordSet contém um conjunto de registros. É como se fosse uma tabela, onde cada linha é um
registro, sendo que cada registro é formado por um conjunto de campos (colunas da tabela). Por
exemplo, ao executarmos a seguinte instrução SQL:
Select * from Pedidos
Com este comando selecionamos todos os registros da tabela Pedidos, os quais poderão ser acessados
através de um objeto do tipo RecordSet.
Existem detalhes importantes que devemos conhecer a respeito do acesso aos dados. Devemos considerar
questões como:
♦ O acesso deve ser somente para leitura dos dados ou devem ser permitidas alterações e inserções
de novos registros?
♦ Como tratar questões sobre o acesso simultâneo aos dados, por exemplo, como tratar a situação
em que dois usuários tentam alterar o mesmo registro, ao mesmo tempo?
Estas são questões importantes e devem ser consideradas sempre que formos disponibilizar acesso aos
dados da nossa empresa, para usuários da Internet. Também precisamos conhecer o que são cursores, quais
os tipos de cursores disponíveis e para que utilizamos cursores. Vamos estudar estes pontos neste tópico.
Para criar um objeto RecordSet, utilizamos a seguinte sintaxe:
Set Pedidos = Server.CreateObject(“ADODB.RecordSet”)
Neste exemplo, estamos criando um RecordSet chamado Pedidos. Uma vez criado o RecordSet, o próximo
passo é utilizarmos o método Open. O método Open possui a seguinte sintaxe:
recordset.Open Source, ActiveConnection, CursorType, LockType, Options
Considere o exemplo:
Pedidos.Open inst_sql, conn, 3, 3
Os parâmetros a serem passados para o método Open estão descritos na Tabela 11.9.
Tabela 11.9 Parâmetros do método Open do objeto RecordSet.
Source Pode ser o nome de um objeto Command, uma instrução SQL ou o nome de uma variável que contém uma instrução
SQL, o nome de uma tabela ou de um stored procedure do Banco de Dados ou até uma URL que aponta para uma
fonte de dados.
ActiveConnection O nome da conexão a ser utilizada ou a string de conexão para uma fonte de dados ODBC ou OLE DB. É opcional.
CursorType É um valor que determina o tipo de cursor que será utilizado pelo provedor de dados na abertura do RecordSet. É
opcional. Falaremos mais sobre tipos de cursores ainda neste item.
LockType É um valor que determina o tipo de lock que será utilizado pelo provedor de dados na abertura do RecordSet. É
opcional. Falaremos mais sobre tipos de lock ainda neste item.
Options Um valor do tipo Long, o qual define como o provedor de dados deve avaliar o argumento Source, quando este
argumento for algo diferente de um objeto Command ou quando o RecordSet deve ser recuperado a partir de um
arquivo salvo previamente.
UM POUCO SOBRE CURSORES

Um cursor é o mecanismo utilizado pela tecnologia ADO para gerenciar o conjunto de registros de um
objeto RecordSet. Somente podemos ter acesso a um registro por vez. Este registro é chamado de registro
corrente. Quando utilizamos o método Open, por padrão, o primeiro registro é o registro corrente.
Um cursor também é utilizado para determinar qual o registro corrente, bem como para movimentar
o indicador de registro entre os diversos registros do objeto RecordSet. O mecanismo que identifica
qual é o registro corrente é chamado de “Record pointer”. Quem lida com a manipulação do Record
pointer é o cursor. Por isso, quando utilizamos os métodos MoveNext (mover para o próximo registro),
MovePrevious (mover para o registro anterior) ou qualquer outro método de movimentação, estamos
utilizando o cursor.
O mecanismo do cursor também gerencia situações em que tentamos avançar além do último registro
ou voltar além do primeiro registro, ou quando acessamos o valor de um campo de um registro. De
uma maneira simples, podemos afirmar que grande parte da funcionalidade de um objeto RecordSet é
fornecida pelo mecanismo do cursor.
Quando utilizamos o método Open, podemos definir diferentes formas de comportamento para o
mecanismo do cursor. Estas formas de comportamento é que determinam os tipos de cursores
disponíveis, os quais estão descritos na Tabela 11.10. O tipo do cursor pode ser definido com um valor
numérico ou através de uma constante, conforme indicado na Tabela 11.10.
Tabela 11.10 Tipos de cursores disponíveis.
Valor/Constante Tipo/Descrição
3 – adOpenStatic Define um cursor do tipo Static. Um cursor deste tipo contém uma cópia estática dos
registros. O conteúdo do RecordSet é definido no momento da criação do objeto.
Caso sejam feitas alterações no Banco de Dados, estas alterações não serão visíveis
para o RecordSet que utiliza um cursor do tipo Static. Somente recriando o
RecordSet é que poderemos ter acesso às alterações efetuadas. Podemos
movimentar o ponteiro de registro em ambas as direções, isto é, podemos
utilizar os métodos MoveNext, MovePrevious e assim por diante.
0 – adOpenForwardOnly Cria um cursor do tipo Forward Only. Este é o valor padrão que será utilizado caso
não seja definido nenhum outro tipo. Somente podemos utilizar o método
MoveNext. Se tentarmos utilizar um outro método de movimentação, será gerado
um erro e a página não será carregada. Também é um cursor do tipo Static, com a
diferença de que somente podemos nos movimentar para a frente.
2 – adOpenDynamic Cria um cursor do tipo Dynamic. Um cursor deste tipo não possui um conjunto fixo
de registros. Quaisquer alterações, adições e exclusões feitas por outros usuários
serão visíveis para o objeto RecordSet, sem que o objeto tenha que ser eliminado e
recriado. Podemos nos movimentar em ambas as direções dentro do RecordSet.
1 – adOpenKeyset Cria um cursor do tipo Keyset. Um cursor deste tipo é parecido com um cursor
Dynamic, com a exceção de que o conjunto de registros é fixo. O RecordSet enxerga
as alterações feitas por outros usuários, porém a adição de novos registros não é
visível para um RecordSet do tipo Keyset. Caso algum registro seja eliminado por
outros usuários, o respectivo registro estará inacessível no RecordSet. Podemos nos
movimentar em ambas as direções dentro do RecordSet.
O tipo de cursor a ser utilizado depende da aplicação que estamos desenvolvendo. Por exemplo, se
estamos desenvolvendo uma página ASP apenas para exibir um conjunto de registros, podemos utilizar
um cursor do tipo Static. Cursores mais simples, como o do tipo Static, consomem menos recursos de
hardware no servidor. Cursores mais sofisticados, como o do tipo Dynamic, consomem mais recursos
computacionais. Estes recursos podem ser consumidos na estação do cliente ou no servidor Web,
dependendo da localização do cursor. Veremos como definir a localização do cursor através da utilização
da propriedade CursorLocation, no próximo item.
Agora alguns exemplos de utilização do método Open.
Este exemplo cria um RecordSet chamado Clientes e define um cursor do tipo Static.
<%
inst_sql=“Select * from Clientes”
Set Clientes = Server.CreateObject(“ADODB.Recordset”)
Clientes.Open inst_sql, conn, 3, 3
%>
Ao invés de utilizarmos o valor 3, podemos utilizar a constante correspondente – adOpenStatic –,

conforme o exemplo:
<%
Clientes.Open inst_sql, conn, adOpenStatic, 3
%>
O próximo exemplo cria um RecordSet chamado Clientes e define um cursor do tipo Keyset.
<%
%>
Ao invés de utilizarmos o valor 1, podemos utilizar a constante correspondente – adOpenKeyset –,

conforme o exemplo:
<%
Clientes.Open inst_sql, conn, adOpenKeyset, 3
%>
LOCALIZAÇÃO DO CURSOR
O cursor pode estar localizado no servidor Web ou no cliente que está acessando os dados. Algumas
fontes de dados, como o Microsoft SQL Server, podem oferecer serviços de cursor no servidor. O Microsoft
Access não oferece serviços de cursor, e com isso o cursor fica localizado no cliente. Quando acessamos
fontes de dados, utilizando OLE DB, podemos utilizar o serviço de cursor oferecido pelo próprio OLE
DB. A opção padrão, caso não seja definido nada em contrário, é que o cursor esteja no servidor.
Para definir a localização do cursor, devemos utilizar a propriedade CursorLocation do objeto RecordSet.
Definimos esta propriedade antes da utilização do método Open do objeto RecordSet. A Tabela 11.11
descreve os valores possíveis para esta propriedade.
Tabela 11.11 Valores para a propriedade CursorLocation.
3/adUseClient Utiliza serviços de cursor no cliente.

1/adUseNone Não utiliza serviços de cursor. Somente é mantido por questões de compatibilidade
com as versões anteriores.
2/adUseServer Utiliza serviços de cursor do servidor ou do provedor OLE DB.
No próximo exemplo, definimos o cursor no cliente:
<%
Clientes.CursorLocation = 3
%>
NOTA
A propriedade CursorLocation deve ser definida antes da utilização do método Open. Ao tentarmos definir a propriedade CursorLocation,
com o RecordSet aberto, obteremos a seguinte mensagem de erro:
Tipo de erro:
ADODB.Recordset (0x800A0E79)
Operation is not allowed when the object is open.
A mensagem indica que a operação (definir a localização do cursor) não é permitida quando o objeto
está aberto.
Ao invés de utilizarmos o valor 3, podemos utilizar a constante correspondente – adUseClient –,

conforme o exemplo:
<%
Clientes.CursorLocation = adUseClient
%>
Quando criamos um objeto RecordSet com o cursor no servidor, é responsabilidade do servidor gerenciar
a navegação e as atualizações do RecordSet, sendo que serão consumidos recursos no servidor.
Ao utilizar o cursor no cliente, todo o conteúdo do RecordSet é copiado para a estação do cliente e
gerenciado por um cursor local. Devemos considerar a questão da velocidade da conexão do usuário
com a Internet ou com a intranet da empresa, pois se o RecordSet for muito grande, isto é, um grande
número de registros, o tempo para copiar todo o RecordSet pode ser inaceitável. Porém uma vez copiado
o RecordSet para a estação do cliente, a utilização do RecordSet é mais rápida, pois não é preciso acessar
o Servidor para simples operações, tais como movimentar-se para o próximo registro.
Quando uma aplicação Web é desenvolvida, a localização dos cursores deve ser discutida na fase de
projeto, sempre procurando propiciar o melhor desempenho possível para a aplicação. Em uma mesma
aplicação posso ter páginas que utilizam o cursor no servidor e outras que utilizam o cursor no cliente,
dependendo apenas da natureza de cada página.
No próximo exemplo, definimos o cursor no servidor:
<%
Clientes.CursorLocation = 2
%>
Ao invés de utilizarmos o valor 2, podemos utilizar a constante correspondente – adUseServer –, conforme
o exemplo:
<%
Clientes.CursorLocation = adUseServer
%>
Lembrando que não é necessário definir o cursor no servidor, pois essa é a definição padrão, ou seja, se
não for definida, explicitamente, a propriedade CursorLocation assume o valor adUseServer.
LOCK DE REGISTROS
Os Bancos de Dados utilizam o lock de registros como uma maneira de garantir a integridade dos
dados. Com a utilização do lock, garantimos que um mesmo registro não esteja sendo alterado,
simultaneamente, por mais do que um usuário. Quando um usuário acessa um registro para fazer
alguma alteração, o registro é bloqueado, de tal forma que outros usuários não possam ter acesso ao
registro. O acesso ao registro somente será liberado após as alterações terem sido salvas no Banco de
Dados. O tipo de lock é definido pela propriedade LockType do objeto RecordSet. Existem diferentes
maneiras de se fazer o lock dos registros, conforme descrito na Tabela 11.12.
Tabela 11.12 Tipos de lock.
1/adLockReadOnly Cria um lock do tipo Read Only. É o tipo padrão de lock. O RecordSet é somente leitura, isto é, os
registros não podem ser modificados, logo não precisam ser bloqueados. Com isso tenho um
processamento mais rápido, porém perco a capacidade de fazer alterações nos registros.
2/adLockPessimistic Cria um lock do tipo Pessimistic. O provedor OLE DB tenta bloquear o registro no momento em que o
registro começa a ser editado. Isso é feito para tentar garantir que o registro será editado com sucesso.
3/adLockOptimistic Cria um lock do tipo Optimistic. O registro não é bloqueado enquanto as alterações no registro não
forem salvas no Banco de Dados através da utilização do método Update do RecordSet.
4/adLockBatchOptimistic Cria um lock do tipo Batch Optimistic. Este tipo de lock permite que vários registros sejam modificados.
Os registros somente serão bloqueados quando for chamado o método UpdateBatch do objeto RecordSet.
-1/adLockUnspecified Não define o tipo de lock. Quando utilizamos o método Clone, para criar uma cópia do RecordSet, o
Clone será criado com o mesmo tipo de lock do RecordSet original.
A maneira e os tipos de lock possíveis de serem utilizados também dependem da fonte de dados que
está sendo utilizada. Quando não existe a necessidade de fazer alterações nos registros, devemos utilizar,
sempre um lock do tipo Read Only (ou seja, como o RecordSet é apenas leitura, os registros não precisam
ser bloqueados), pois isso evita que o provider tenha que fazer verificações ao acessar cada registro,
para verificar se o registro não está bloqueado no momento. Com isso teremos um processamento
bem mais rápido.
Um registro bloqueado não pode nem sequer ser visualizado pelos usuários, e com isso evita-se que
seja exibido um registro que está sendo alterado.
Para definir o tipo de lock, utilizamos a propriedade LockType, conforme indicado no exemplo a
seguir, onde definimos o tipo de lock como Optimistic:
<%
Clientes.LockType = 3
%>
NOTA
A propriedade LockType deve ser definida antes da utilização do método Open. Ao tentarmos definir a propriedade LockType, com o
RecordSet aberto, obteremos a seguinte mensagem de erro:
Tipo de erro:
ADODB.Recordset (0x800A0E79)
Operation is not allowed when the object is open.
A mensagem indica que a operação (definir o tipo de lock) não é permitida quando o objeto está aberto.
Ao invés de utilizarmos o valor 3, podemos utilizar a constante correspondente – adLockOptimistic –,

conforme o exemplo:
<%
Clientes.LockType = adLockOptimistic
%>
Agora que já discutimos um pouco sobre cursores, localização do cursor e lock de registros, podemos
partir para o estudo de mais alguns detalhes do objeto RecordSet.
PROPRIEDADES DO OBJETO RECORDSET

Através da utilização de propriedades de um objeto podemos definir algumas características do objeto
e também retornar as características do objeto. Algumas propriedades são somente para leitura, o que
significa que apenas podemos verificar o valor da propriedade. Outras propriedades são de leitura e
escrita, isto é, podemos definir o valor da propriedade. Para definir o valor de uma propriedade,
utilizamos a seguinte sintaxe:
<% RecordSet.nome_da_propriedade = valor %>
Na Tabela 11.13 estão listadas as principais propriedades do objeto RecordSet.
Tabela 11.13 Principais propriedades do objeto RecordSet.
AbsolutePage Retorna a página do registro corrente. Página é um conceito de armazenamento de Banco de Dados.
AbsolutePosition Indica a posição do registro corrente, dentro do RecordSet.
ActiveCommand Retorna o objeto Command utilizado para criar o RecordSet, caso tenha sido utilizado um objeto Command. Esta
propriedade é somente leitura.
continua
continuação
BOF Esta propriedade torna-se verdadeira quando estivermos no primeiro registro e utilizarmos o método MovePrevious, ou
seja, indica uma tentativa de voltarmos além do primeiro registro. É somente leitura.
Bookmark Retorna um marcador (bookmark) que identifica de maneira única cada registro do RecordSet. Também pode ser
utilizado para tornar o registro identificado pelo bookmark como o registro corrente. Nem todos as fontes de dados e
seus respectivos OLE DB Providers oferecem esta propriedade.
CacheSize Indica o número de registros do RecordSet que devem ser mantidos no cache local de memória. Também pode ser
utilizada para definir este número de registros.
CursorLocation Pode ser utilizada para definir ou retornar a posição do cursor.
CursorType Indica o tipo de cursor utilizado em um objeto RecordSet. Também pode ser utilizado para definir o tipo de cursor. Deve
ser usado antes do método Open, caso contrário irá provocar um erro quando a página for carregada.
EditMode Retorna um valor que indica o status de edição do registro atual. Este valor pode ser:
0 – indica que não existe edição em andamento;
1– indica que os dados do registro atual foram modificados, porém ainda não foram salvos;
2 – indica que o método AddNew foi chamado e o registro que está sendo criado ainda não foi salvo no Banco de Dados;
4 – indica que o registro atual foi deletado.
É somente leitura.
EOF Esta propriedade torna-se verdadeira quando estivermos no último registro e utilizarmos o método MoveNext, ou seja,
indica uma tentativa de avançarmos além do último registro. É somente leitura.
Filter Pode ser utilizado para filtrar os registros de um RecordSet de acordo com um critério definido.
LockType Indica o tipo de lock que está sendo utilizado. Também pode ser utilizado para definir o tipo de lock, antes que o
método Open tenha sido utilizado.
MaxRecords Define o número máximo de registros que uma consulta deve retornar para o objeto RecordSet. O valor padrão é zero,
o que significa sem limite de registros.
PageCount Indica quantas páginas de dados o objeto RecordSet contém. É somente leitura.
PageSize Indica o número de registros por página.
RecordCount Indica o número de registros do objeto RecordSet. É somente leitura.
Sort Especifica um ou mais campos para ordenação do RecordSet, além do tipo de ordenação, se ascendente ou
descendente.
Para utilizarmos esta propriedade devemos utilizar o cursor no cliente.
Source Indica as fontes dos dados de um objeto RecordSet. Por exemplo, exibe a instrução SQL que deu origem aos dados ou o
nome da tabela ou consulta que originou os dados do objeto RecordSet.
State Indica o estado do objeto RecordSet. Indica se o mesmo está aberto, fechado ou executando uma operação de maneira
assíncrona. É somente leitura.
MÉTODOS DO OBJETO RECORDSET

O objeto RecordSet nos fornece diversos métodos, os quais podem ser utilizados para nos deslocar
através dos registros, fazer uma cópia do RecordSet, etc. Para utilizarmos um método do objeto RecordSet,
utilizamos a seguinte sintaxe:
<% RecordSet.nome_do_método parâmetro1, parâmetro2, ..., parâmetron %>
Na Tabela 11.14 estão listados os principais métodos do objeto RecordSet.
Tabela 11.14 Principais métodos do objeto RecordSet.
Método Descrição
AddNew Utilizado para adicionar um novo registro em um RecordSet que seja atualizável.
Cancel Cancela a execução de uma operação Open assíncrona.
CancelBatch Cancela uma operação de atualização em batch.
CancelUpdate Cancela qualquer alteração feita no registro corrente, ou alterações feitas em um
novo registro antes da chamada ao método Update.
Clone Cria uma cópia do objeto RecordSet.
Close Fecha o objeto RecordSet e todos os objetos dele dependentes.
Delete Elimina o registro corrente ou um grupo de registros selecionados.
Find Pesquisa no RecordSet por um registro que atende um critério especificado.
GetRows Retorna registros de um RecordSet e os armazena em um array.
GetString Retorna todo o RecordSet como uma string.
Move Movimenta o indicador de registro a partir de uma posição especificada um
determinado número de registros. Por exemplo, posso movimentar o indicador dez
registros a partir do registro 10, com isso o indicador fica no registro 20.
MoveFirst Movimenta o indicador para o primeiro registro.
MoveLast Movimenta o indicador para o último registro.
MoveNext Movimenta o indicador para o próximo registro.
MovePrevious Movimenta o indicador para o registro anterior.
Open Abre o objeto RecordSet.
Requery Atualiza o conjunto de registros do RecordSet, executando novamente a consulta
que deu origem ao RecordSet.
Resync Atualiza os dados do RecordSet, buscando os dados a partir do Banco de Dados.
Save Salva o conteúdo do RecordSet em um arquivo.
Update Salva quaisquer alterações que tenham sido feitas para o objeto RecordSet.
Agora vamos aprender a executar algumas operações bastante comuns em aplicações Web do dia-a-
dia. Aprenderemos a inserir registros, excluir registros e alterar um determinado registro.
UMA PÁGINA ASP PARA INSERIR INFORMAÇÕES NO BANCO DE DADOS

Neste exemplo, aprenderemos a construir uma página ASP que recebe os dados digitados em um
formulário HTML e armazena estes dados no registro de uma tabela. Também faremos a validação para
verificar se todos os campos obrigatórios foram preenchidos; caso algum campo obrigatório não tenha
sido preenchido, devolvemos o formulário para o usuário informando qual ou quais campos obrigatórios
não foram preenchidos. Caso todos os campos tenham sido preenchidos corretamente, os valores
digitados serão gravados no Banco de Dados.
Podemos utilizar este exemplo para criar um formulário de cadastro de usuários ou qualquer outra
aplicação que necessite armazenar os dados digitados em um formulário.
Eu, por exemplo, utilizo uma aplicação deste tipo para fazer a avaliação dos treinamentos que ministro em todo o país. Ao final do treinamento
NOTA
os usuários, sem se identificar, preenchem um formulário com as opiniões sobre o treinamento, o material e o desempenho do instrutor. Estes
dados são armazenados diretamente em um Banco de Dados do Microsoft Access; a partir do qual faço uma série de estatísticas.
Nos exemplos, estarei utilizando a linguagem VBScript. Para maiores informações sobre VBScript, consulte um dos seguintes sites:
msdn.microsoft.com/vbscript; www.searchvb.com; e www.vbscripts.com.
Você também pode consultar o e-book “Criando Sites Dinâmicos com ASP 3.0”, já citado anteriormente.
Neste e-book, você também encontrará informações sobre a criação de formulários utilizando HTML.
No Exemplo 11.4, temos o código HTML para a criação do formulário de cadastro, no qual o usuário
poderá digitar os dados. Os dados digitados neste formulário serão inseridos na tabela Customers, do
Banco de Dados Northwind, da instância SERVIDOR\SQL2005. O exemplo da Listagem 11.4 tem apenas
o código HTML para a criação do formulário, com os campos para digitação dos dados. Ao clicar no
botão Enviar dados, os dados digitados serão enviados para a página cadastro.asp. O nome da página
ASP que irá processar os dados é definido na propriedade ACTION, do botão de comando Enviar
dados. Após o código, apresentarei mais explicações sobre este exemplo. Este exemplo deve ser salvo
com o nome Cadastro.htm, na página C:\LivroSQL2005\Capitulo11
Exemplo 11.4 – O formulário para digitação dos dados – Cadastro.htm.
1 <HTML>
2 <HEAD>
3 <TITLE>Cadastro de novos Clientes !!</TITLE>
4 </HEAD>
5 <BODY bgColor=#c0c0c0>
6 <P>
7 <FONT color=white size=6 style=“BACKGROUND-COLOR: navy”>
8 <B>Tabela Customers – Northwind </B>
9 </FONT>
10 </P>
11 <P>
12 <FONT color=#ffffff size=5 style=“BACKGROUND-COLOR: darkred”>
13 <B><EM>Cadastro de Clientes !</EM></B>
14 </FONT>
15 </P>
16 <P>
17 <FONT color=navy size=4>
18 <EM>Digite os dados solicitados e clique no botão Enviar.</EM>
19 </FONT>
20 </P>
21 <P>
22 <FORM ACTION=cadastro.asp METHOD=POST>
23 <TABLE bgColor=#ffffff border=1 cellPadding=1 cellSpacing=1 width=“100%” style=“HEIGHT:

161px; WIDTH: 340px”>
24 <TR>
25 <TD>Código:</TD>
26 <TD><INPUT id=CustomerID maxLength=50 name=CustomerID size=35>
27 <FONT color=red><B>(*)</B></FONT></TD>
28 </TR>
29 <TR>
30 <TD>Nome:</TD>
31 <TD><INPUT id=CompanyName maxLength=30 name=CompanyName size=35>
33 </TR>
34 <TR>
35 <TD>Contato:</TD>
36 <TD><INPUT id=ContactName maxLength=20 name=ContactName >
38 </TR>
39 <TR>
40 <TD>Cargo:</TD>
41 <TD><INPUT id=ContactTitle maxLength=25 name=ContactTitle size=25>
43 </TR>
44 <TR>
45 <TD>Endereço:</TD>
46 <TD><INPUT id=Address maxLength=20 name=Address></TD>
47 </TR>
48 <TR>
49 <TD>Cidade:</TD>
50 <TD><INPUT id=City maxLength=20 name=City></TD>
51 </TR>
52 <TR>
53 <TD>Região:</TD>
54 <TD><INPUT id=Region maxLength=20 name=Region></TD></TR>
55 <TR>
56 <TR>
57 <TD>CEP:</TD>
58 <TD><INPUT id=PostalCode maxLength=20 name=PostalCode></TD></TR>
59 <TR>
60 <TR>
61 <TD>País:</TD>
62 <TD><INPUT id=Country maxLength=20 name=Country></TD></TR>
63 <TR>
64 <TR>
65 <TD>Telefone:</TD>
66 <TD><INPUT id=Phone maxLength=20 name=Phone></TD></TR>
67 <TR>
68 <TR>
69 <TD>FAX:</TD>
70 <TD><INPUT id=Fax maxLength=20 name=Fax></TD></TR>
71 <TR>
72 <TR>
73 <TD colSpan=2>
74 <INPUT id=enviar name=enviar style=“HEIGHT: 24px; WIDTH:109px” type=submit
value=“Enviar dados.”>
70 <INPUT id=limpar name=limpar type=submit value=“Limpar Formulário.”>
71 </TD>
72 </TR>
73 </TABLE>
74 </FORM>
75 </P><BR>
76 <FONT color=red><B>(*)
77 <FONT color=navy>Campos de preenchimento obrigatório.</FONT></B></FONT>
78 </BODY>
79 </HTML>
Ao carregarmos o Exemplo 11.4, obteremos o resultado indicado na Figura 11.35.
Figura 11.35 O formulário cadastro.htm, para digitação dos dados.
Agora precisamos construir a página Cadastro.asp, a qual irá verificar se todos os campos obrigatórios
foram preenchidos. Se todos os campos obrigatórios foram preenchidos, os dados serão gravados em
um Banco de Dados, caso contrário o formulário é enviado de volta para o usuário, solicitando que o
usuário preencha os campos que estão faltando.
Para armazenar os dados, utilizaremos a tabela Customers, do Banco de Dados Northwind, da instância
SERVIDOR\SQL2005. A estrutura da tabela Customers está indicada na Figura 11.36.
Figura 11.36 Tabela Customers do Banco Northwind no SQL Server 2005.
Para acessar este Banco de Dados utilizaremos OLE DB, sem a necessidade da criação de uma fonte
ODBC. Faremos isto através da utilização da propriedade ConnectionString, já descrita neste capítulo.
A página cadastro.asp fará o seguinte:
♦ Estabelece uma conexão com o Banco de Dados Northwind e cria um RecordSet chamado
Cadastro, o qual está ligado à tabela Customers.
♦ Depois, a página verifica se algum campo obrigatório não foi preenchido.
♦ Caso todos os campos obrigatórios tenham sido preenchidos, os dados são gravados na tabela
Customers.
♦ Caso algum campo obrigatório não tenha sido preenchido, a página ASP informa quais cam-
pos obrigatórios não foram preenchidos, retorna o formulário para o usuário, mantendo os
campos que já haviam sido preenchidos, para que o usuário possa preencher somente os que
estão faltando.
No Exemplo 11.5, temos o código para a página Cadastro.asp.
Exemplo 11.5 – Página ASP para processamento dos dados – Cadastro.asp.

2 <HTML>
4 <HEAD>
5 </HEAD>
6 <BODY>
7 <%
10 ‘Cria um objeto do Tipo ADODB.Connection
12 ‘Agora abro uma conexão com o Banco de Dados Northwind
13 ‘da instância SERVIDOR\SQL2005, utilizando OLE DB.
Data Source=SERVIDOR\SQL2005;Initial Catalog=Northwind;
15 conn.Open

17 ‘Este objeto irá acessar a tabela Customers.
18 Set Cadastro = Server.CreateObject(“ADODB.Recordset”)

19 Cadastro.Open “Customers”, conn, 3, 3
20 ‘Neste ponto tenho o objeto Cadastro ligado com a tabela

21 ‘Cadastro do Banco de Dados clientes.mdb.
22 ‘**************************************************
23 ‘ Inicia a verificação para saber se todos
24 ‘ os campos obrigatórios foram preenchidos.
25 ‘ Atribuo os campos obrigatórios a variáveis, para facilitar a verificação.

26 ‘Os dados recebidos pelo formulário são acessados através do objeto Request e do
27 ‘seu método Form. Por exemplo, Request.Form(“CustomerID”) contém o valor digitado
‘no campo CustomerID do formulário Cadastro.htm.
28 Codigo = Request.Form(“CustomerID”)
29 Nome = Request.Form(“CompanyName”)
30 Contato = Request.Form(“ContactName”)
31 Cargo = Request.Form(“ContactTitle”)
32 ‘Verifica se os campos obrigatórios foram preenchidos.

33 ‘Qualquer dado obrigatório que não tenha sido preenchido,
34 ‘definirá a variável faltou_dado em Sim.
35 If (Codigo=“”)Then
36 mensagem_codigo=“Preencha o campo Código:”
37 faltou_dado=“Sim”
38 faltou_codigo=“Sim”
39 End If
40 If (Nome=“”)Then
41 mensagem_nome=“Preencha o campo Nome:”
43 faltou_nome=“Sim”
44 End If
45 If (Contato=“”)Then
46 mensagem_contato=“Preencha o campo Contato:”
48 faltou_contato=“Sim”
49 End If
50 If (Cargo=“”)Then
51 mensagem_cargo=“Preencha o campo Cargo:”
53 faltou_cargo=“Sim”
54 End If
55 ‘Caso todos os campos obrigatórios tenham sido

56 ‘preenchidos, gravo os dados no Banco de Dados.
57 ‘e informo que a operação foi realizada com sucesso.
58 If faltou_dado<>“Sim” Then
59 Cadastro.AddNew
60 Cadastro.Fields(“CustomerID”)= Request.Form(“CustomerID”)
71 Cadastro.Fields(“CompanyName”)= Request.Form(“CompanyName”)
72 Cadastro.Fields(“ContactName”)= Request.Form(“ContactName”)
73 Cadastro.Fields(“ContactTitle”)= Request.Form(“ContactTitle”)
74 Cadastro.Fields(“Address”)= Request.Form(“Address”)
75 Cadastro.Fields(“City”)= Request.Form(“Region”)
76 Cadastro.Fields(“Region”)= Request.Form(“Region”)
77 Cadastro.Fields(“PostalCode”)= Request.Form(“PostalCode”)
78 Cadastro.Fields(“Country”)= Request.Form(“Country”)
79 Cadastro.Fields(“Phone”)= Request.Form(“Phone”)
80 Cadastro.Fields(“Fax”)= Request.Form(“Fax”)
81 Cadastro.Update
82 Cadastro.Close
83 Set Cadastro = Nothing
84 Response.Write “CLIENTE CADASTRADO COM SUCESSO<BR>”

85 Response.Write “<A href=cadastro.htm>Clique aqui para Cadastrar outro Cliente</A>”
86 Response.Write “<HR>”
87 End If
88 ‘Caso algum dado obrigatório não tenha sido digitado

89 ‘Envia o formulário de volta para o Cliente,
90 ‘preservando os valores que o mesmo já digitou.
91 ‘Observe que utilizamos Response.Write para ir
92 ‘recriando todo o formulário. Também observe que o formulário é enviado de volta
93 ‘na página cadastro.asp e que o atributo action da tag FORM é definido como
94 ‘cadastro.asp, ou seja a página cadastro.asp chama a si mesma após o
95 ‘usuário clicar no botão Enviar. Esta é uma técnica bastante interessante.
96 ‘Antes de enviar o formulário, informamos quais
97 ‘os campos obrigatório que não foram preenchidos.
98 If faltou_codigo=“Sim” Then
99 Response.Write “<B>O campo Código deve ser preenchido.</B> <br>”
100 End If
101 If faltou_nome=“Sim” Then

102 Response.Write “<B>O campo Nome deve ser preenchido.</B> <br>”
103 End If
104 If faltou_contato=“Sim” Then

105 Response.Write “<B>O campo Contato deve ser preenchido.</B> <br>”
106 End If
107 If faltou_cargo=“Sim” Then

108 Response.Write “<B>O campo cargo deve ser preenchido.</B> <br>”
109 End If
110 %>
111 <%
112 ‘Começo a reenviar o formulário para o usuário, utilizando Response.Write.
113 ‘Caso esteja faltando algum dado, envio o formulário.

114 ‘para o usuário preencher os campos que estão faltando.
115 ‘Os valores já digitados são preservados.
116 %>
117 <% If faltou_dado=“Sim” Then
118 Response.Write “<BODY bgColor=#c0c0c0>”
119 Response.Write “<P><FONT color=white size=6 style=BACKGROUND-COLOR: navy><STRONG>Cadastro
de Clientes”
120 Response.Write “CLIENTES:</EM></STRONG></FONT> <BR></FONT><FONT color=navy
size=4><EM>Digite os dados solicitados e clique no botão “
121 Response.Write “Enviar.</EM></FONT></P>”
122 Response.Write “<P>”
123 Response.Write “Caso queira alterar algum dado”

124 Response.Write “ digite no formulário abaixo.<HR>”
125 Response.Write “<FORM ACTION=cadastro.asp METHOD=post id=form1 name=form1>”
126 Response.Write “<TABLE bgColor=#ffffff border=1 cellPadding=1 cellSpacing=1 width=100%

style=HEIGHT: 161px; WIDTH: 340px>”
127 Response.Write “<TR>”

128 Response.Write “<TD>Código:</TD>”
129 Response.Write “<TD><INPUT id=CustomerID maxLength=50 name=CustomerID size=35 value=” &
Chr(34) & Request.Form(“CustomerID”) & Chr(34) & “> <FONT “
130 Response.Write “color=red><B>(*)</B></FONT></TD></TR>”

132 Response.Write “<TD>Nome:</TD>”
133 Response.Write “<TD><INPUT id=CompanyName maxLength=50 name=CompanyName size=35 value=”
& Chr(34) & Request.Form(“CompanyName”) & Chr(34) & “> <FONT “

136 Response.Write “<TD>Contato:</TD>”
137 Response.Write “<TD><INPUT id=ContactName maxLength=50 name=ContactName size=35 value=”
& Chr(34) & Request.Form(“ContactName”) & Chr(34) & “> <FONT “

140 Response.Write “<TD>Cargo:</TD>”
141 Response.Write “<TD><INPUT id=ContactTitle maxLength=50 name=ContactTitle size=35
value=” & Chr(34) & Request.Form(“ContactTitle”) & Chr(34) & “> <FONT “

144 Response.Write “<TD>Endereço:</TD>”
145 Response.Write “<TD><INPUT id=Address maxLength=50 name=Address
size=35 value=” & Chr(34) & Request.Form(“Address”) & Chr(34) & “>”
146 Response.Write “</TD></TR>”

148 Response.Write “<TD>Cidade:</TD>”
149 Response.Write “<TD><INPUT id=City maxLength=50 name=City
size=35 value=” & Chr(34) & Request.Form(“City”) & Chr(34) & “>”

152 Response.Write “<TD>Região:</TD>”
153 Response.Write “<TD><INPUT id=Region maxLength=50 name=Region
size=35 value=” & Chr(34) & Request.Form(“Region”) & Chr(34) & “>”

156 Response.Write “<TD>CEP:</TD>”
157 Response.Write “<TD><INPUT id=PostalCode maxLength=50 name=PostalCode
size=35 value=” & Chr(34) & Request.Form(“PostalCode”) & Chr(34) & “>”
160 Response.Write “<TD>País:</TD>”
161 Response.Write “<TD><INPUT id=Country maxLength=50 name=Country
size=35 value=” & Chr(34) & Request.Form(“Country”) & Chr(34) & “>”

164 Response.Write “<TD>Telefone:</TD>”
165 Response.Write “<TD><INPUT id=Phone maxLength=50 name=Phone
size=35 value=” & Chr(34) & Request.Form(“Phone”) & Chr(34) & “>”

168 Response.Write “<TD>Fax:</TD>”
169 Response.Write “<TD><INPUT id=Fax maxLength=50 name=Fax
size=35 value=” & Chr(34) & Request.Form(“Fax”) & Chr(34) & “>”
171 Response.Write “<FONT color=red><B>(*)</B></FONT></TD></TR>”

173 Response.Write “<TD colSpan=2><INPUT id=enviar name=enviar style=HEIGHT: 24px; WIDTH:
109px type=submit value=Enviar_dados.> ”
174 Response.Write “<INPUT id=limpar name=limpar type=submit value=Limpar_formulário.></TD></TR>”
175 Response.Write “</TABLE>”

176 Response.Write “</FORM>”
177 Response.Write “</P><FONT color=red><B>(*) <FONT color=navy>Campos de preenchimento “
178 Response.Write “obrigatório.</FONT></B></FONT>”
179 End If
180 %>
181 </BODY>
182 </HTML>
NOTA
Algumas linhas aparecem divididas em duas ou mais linhas. Nunca é demais lembrar que estas linhas devem ser digitadas como uma linha
única. As linhas estão exibidas em duas ou mais linhas apenas por questão de espaço.
Algumas observações sobre o Exemplo 11.5:
♦ A primeira observação a ser feita é a respeito do código que insere um novo registro na tabela
Customers do Banco de Dados Northwind. O código ASP que realiza esta tarefa é o seguinte:
58 If faltou_dado<>“Sim” Then
59 Cadastro.AddNew
60 Cadastro.Fields(“CustomerID”)= Request.Form(“CustomerID”)
71 Cadastro.Fields(“CompanyName”)= Request.Form(“CompanyName”)
72 Cadastro.Fields(“ContactName”)= Request.Form(“ContactName”)
73 Cadastro.Fields(“ContactTitle”)= Request.Form(“ContactTitle”)
74 Cadastro.Fields(“Address”)= Request.Form(“Address”)
75 Cadastro.Fields(“City”)= Request.Form(“Region”)
76 Cadastro.Fields(“Region”)= Request.Form(“Region”)
77 Cadastro.Fields(“PostalCode”)= Request.Form(“PostalCode”)
78 Cadastro.Fields(“Country”)= Request.Form(“Country”)
79 Cadastro.Fields(“Phone”)= Request.Form(“Phone”)
80 Cadastro.Fields(“Fax”)= Request.Form(“Fax”)
81 Cadastro.Update
82 Cadastro.Close
83 Set Cadastro = Nothing
81 Response.Write “CLIENTE CADASTRADO COM SUCESSO<BR>”
82 Response.Write “<A href=cadastro.htm>Clique aqui para Cadastrar outro Cliente</
A>”
83 Response.Write “<HR>”
84 End If
Neste código, utilizamos o método AddNew do objeto RecordSet Cadastro. Depois vamos preenchendo
cada novo campo do registro, com o respectivo valor preenchido pelo usuário no formulário. No final,
utilizamos o método Update para salvar o registro na tabela.
O método Close é utilizado para fechar o RecordSet Cadastro e, por fim, tiramos o objeto Cadastro da
memória. Isto é feito atribuindo-se o valor “Nothing” para o objeto Cadastro. É importante lembrar
que, para atribuir valor para um objeto, devemos utilizar o operador Set, caso contrário obteremos
uma mensagem de erro.
♦ Também gostaria de observar a situação em que o usuário deixa de preencher algum campo
obrigatório. Neste caso, o usuário é informado a respeito de qual ou quais campos não foram
preenchidos. O formulário é retornado para o usuário, juntamente com os valores já digitados,
para que ele não precise digitar todos os valores novamente. Observe que todo o código HTML
que gera o formulário é retornado utilizando-se Response.Write.
Vamos testar o funcionamento da página Cadastro.asp.
Na Figura 11.37, o usuário preencheu alguns campos, porém não preencheu os campos obrigatórios
Contato e Cargo.
Figura 11.37 Os campos obrigatórios Contato e Cargo não foram preenchidos.
Ao clicar no botão “Enviar dados”, a página Cadastro.asp detecta que alguns campos obrigatórios não
foram preenchidos e informa o usuário a este respeito, conforme indicado na Figura 11.38.
Figura 11.38 O usuário é informado quais campos obrigatórios não foram preenchidos.
Agora o usuário preenche os campos obrigatórios que estão faltando, conforme indicado na
Figura 11.39.
Ao clicar no botão “Enviar dados”, as informações serão salvas no Banco de Dados. A página Cadastro.asp
informa que os dados foram salvos com sucesso e retorna um link para que o usuário possa voltar ao
formulário de cadastro e cadastrar outro cliente, conforme indicado na Figura 11.40.
Na Figura 11.41, acessamos a tabela Customers e podemos constatar que o cliente foi realmente
cadastrado.
Figura 11.39 O usuário preenche os campos que estão faltando.
Figura 11.40 O cliente foi cadastrado com sucesso.
Figura 11.41 Os dados enviados pela página ASP foram gravados na tabela Customers.
DEMAIS OPERAÇÕES UTILIZANDO ASP

Neste tópico, veremos como efetuar as demais operações utilizando ASP. Veremos quais os métodos
utilizados para efetuar as seguintes operações:
♦ Localizar um registro.
♦ Editar um registro.
♦ Excluir um registro.
PARA LOCALIZAR UM REGISTRO

Para que possamos localizar um registro, ou um conjunto de registros com base em um ou mais critérios,
basta construirmos uma instrução SQL que retorna os dados desejados. Por exemplo, se quisermos
pesquisar um determinado produto na tabela Products, do Banco de Dados Northwind, criamos um
formulário HTML onde o usuário pode digitar o código do produto. O valor digitado é passado para
uma página ASP, utilizando a opção Action, da tag FORM. A página ASP recebe o valor digitado, utilizando
Request.Form(“NomeDoCampoNoFormulário”). Com o valor recebido, a página ASP monta uma
instrução SQL, utilizando o código digitado como filtro. Os resultados são exibidos em uma tabela
criada com código HTML.
Vamos a um exemplo bastante simples. O nosso exemplo será composto de duas páginas ASP. A primeira
página será chamada ListaPaises.asp. Esta página obtém uma lista de todos os países para os quais
existe pedidos na tabela Orders do Banco de Dados Northwind da instância SERVIDOR\SQL2005.
Selecionamos um dos países da lista e clicamos em um botão Pesquisar. Ao clicarmos no botão Pesquisar,
será chamada uma segunda página ASP – PaisesObtidos.asp. Esta segunda página exibe uma listagem
com os campos OrderID, OrderDate, ShipCity e ShipCountry para todos os pedidos do país selecionado
na página ListaPaises.asp.
No Exemplo 11.6, temos a listagem que cria a página ListaPaises.asp.
Exemplo 11.6 – Página ASP que cria a listagem de países – ListaPaises.asp.

2 <HTML>
3 <HEAD>
4 </HEAD>
5 <TITLE>Selecione o País de destino.</TITLE>
6 <BODY>
7 <%
8 ‘O primeiro passo é criar a conexão com o Banco de Dados.

9 ‘Para isto crio um objeto do tipo Connection.
12 ‘Agora abro uma conexão com o Banco de Dados Northwind

13 ‘utilizando OLE DB.
15 conn.Open

17 ‘Este objeto irá acessar o campo ShipCountry
18 ‘da tabela Produtos
19 Set Paises = Server.CreateObject(“ADODB.Recordset”)
20 Paises.Open “Select ShipCountry from Orders Group By ShipCountry Order By ShipCountry”,

conn, 3, 3
21 ‘Neste ponto tenho o objeto Paises com uma listagem

22 ‘em ordem ascendente, dos países para os quais existem
23 ‘pedidos efetuados.
24 %>
25 <P><B>Selecione o país a ser pesquisado.</B></P>

26 <P><B><I>Depois clique no botão Pesquisar.</I></B></P>
27 <FORM action=PaisesObtidos.asp method=post id=form1 name=form1>

28 <SELECT id=listapaises name=listapaises>
29 <%
30 ‘Agora construo a lista de opções a partir dos

31 ‘dados obtidos da tabela Orders.
32 ‘Para cada país obtido, crio uma nova opção
33 ‘na lista.
34 Do While Not Paises.EOF

35 Response.Write “<OPTION value=” & Chr(34) & Paises.Fields(“ShipCountry”) & Chr(34)
& “>” & Paises.Fields(“ShipCountry”)& “</OPTION>”
36 Paises.MoveNext
37 Loop
38 %>
39 </SELECT>
40 <BR>
41 <HR>
42 <INPUT type=“submit” value=Pesquisar id=Pesquisar name=Pesquisar>

43 </FORM>
44 </BODY>
45 </HTML>
Ao carregarmos a página ListaPaises.asp, obtemos o resultado indicado na Figura 11.42.
Figura 11.42 A página ListaPaises.asp.
Agora precisamos construir a página PaisesObtidos.asp. Esta página receberá o valor selecionado na
lista, e utilizará este valor como critério de pesquisa. O nome da lista na página ListaPaises.asp é
listapaises. O que define o nome de um campo em um formulário é a opção id, como indicado no
fragmento de código a seguir:
A página PaisesObtidos.asp também exibirá os resultados obtidos.
Na Listagem 11.7, temos o código que cria a página PaisesObtidos.asp.
Exemplo 11.7 – Utilizando o país selecionado como critério de pesquisa – PaisesObtidos.asp.

2 <HTML>
3 <HEAD>
4 </HEAD>
5 <TITLE>Resultados da pesquisa para <%=Request.Form(“listapaises”) %>.</TITLE>
6 <BODY>
7 <%
8 ‘O primeiro passo é criar a conexão com o Banco de Dados.
9 ‘Para isto crio um objeto do tipo Connection.
13 conn.Open

15 ‘Este objeto irá utilizar o país selecionado como critério de pesquisa
18 ‘na tabela Orders. Feito isso teremos os pedidos para o país selecionado na lista.
19 Set Pedidos = Server.CreateObject(“ADODB.Recordset”)
20 Pedidos.Open “Select OrderID, OrderDate, ShipCity, ShipCountry from Orders WHERE

ShipCountry=’” & Request.Form(“listapaises”) & “‘“ , conn, 3, 3
21 ‘Vamos exibir novamente a lista de países para que o usuário

22 ‘possa selecionar outro país e fazer outra pesquisa.

24 ‘Este objeto irá acessar o campo ShipCountry
25 ‘da tabela Orders.
26 Set Paises = Server.CreateObject(“ADODB.Recordset”)
27 Paises.Open “Select ShipCountry from Orders Group By ShipCountry Order By ShipCountry”,

conn, 3, 3
28 ‘Neste ponto tenho o objeto Paises com uma listagem

29 ‘em ordem ascendente, dos países para os quais existem
30 ‘pedidos efetuados.
31 %>
32 <B>Selecione outro país para fazer uma nova pesquisa.</B><BR>

33 <B><I>Depois clique no botão Pesquisar.</I></B><BR>
34 <FORM action=PaisesObtidos.asp method=post id=form1 name=form1>

36 <%
37 ‘Agora construo a lista de opções a partir dos

38 ‘dados obtidos da tabela Orders.
39 ‘Para cada país obtido, crio uma nova opção
40 ‘na lista.
41 Do While Not Paises.EOF
42 Response.Write “<OPTION value=” & Chr(34) & Paises.Fields(“ShipCountry”) & Chr(34)
43 If Paises.Fields(“ShipCountry”)= Request.Form(“listapaises”) Then

44 Response.Write “SELECTED”
45 End If
46 Response.Write “>” & Paises.Fields(“ShipCountry”)& “</OPTION>”
47 Paises.MoveNext
48 Loop
49 %>
50 </SELECT>
51
52 <HR>
53 <INPUT type=“submit” value=Pesquisar id=Pesquisar name=Pesquisar>
54 </FORM>
55 <%
56 ‘Exibo os resultados obtidos.
57 %>
58 <B>Relação de pedidos para: <% =Request.Form(“listapaises”) %>.</B>

59 <HR>
60 <% ‘Agora exibo os resultados utilizando uma tabela. %>
61 <TABLE border=1>
62 <TR>
63 <TD><B>Código</B></TD>
64 <TD><B>Data</B></TD>
65 <TD><B>Cidade</B></TD>
66 <TD><B>País</B></TD>
67 </TR>
68 <%
69 Do While Not Pedidos.EOF

70 %>
71 <TR>
72 <TD><% =Pedidos.Fields(“OrderID”) %></TD>
73 <TD><% =Pedidos.Fields(“OrderDate”) %></TD>
74 <TD><% =Pedidos.Fields(“ShipCity”) %></TD>
75 <TD><I><% =Pedidos.Fields(“ShipCountry”) %></I></TD>
76 </TR>
77 <% Pedidos.MoveNext
78 Loop
79 %>
80 </TABLE>
81 <BR>
82 <HR>
83 </BODY>
84 </HTML>
UTILIZANDO O NOSSO EXEMPLO

Agora vamos utilizar o nosso exemplo para comprovar o correto funcionamento do mesmo.
Ao carregar a página ListaPaises.asp, obtemos o resultado indicado na Figura 11.42, indicada
anteriormente.
Vamos supor que o usuário selecionou Norway, na lista de países. Ao clicar no botão Pesquisar, serão
exibidos apenas os pedidos para o país selecionado, conforme indicado na Figura 11.43.
Figura 11.43 Exibindo os pedidos para a Norway.
Observe que novamente é exibida a lista de países e o país selecionado anteriormente aparece selecionado
na lista. Para pesquisar os pedidos para outro país é só selecionar o país desejado na lista, e clicar no
botão Pesquisar. Veja que com isso construímos um formulário de pesquisa bastante interativo. O
usuário seleciona o país desejado, e manda pesquisar. Cada vez que o usuário seleciona um país diferente
na lista e clica no botão Pesquisar; o novo valor selecionado é utilizado como critério de filtragem e
somente os registros que atendem ao critério serão retornados.
EDITANDO E EXCLUINDO REGISTROS

Para editar um registro, em primeiro lugar devemos localizá-lo, isto é, o registro a ser editado deve ser
o registro atual. Uma vez localizado, começamos a alterar os seus campos, utilizando a seguinte sintaxe:
NomeObjeto.Fields(“Campo1”) = valor
...
NomeObjeto.Fields(“Campon”) = valor
onde Campo1, Campo2, etc. é o nome de cada campo, conforme definido na estrutura da tabela.
Depois, utilizamos o método Update, para gravar as alterações na tabela no Banco de Dados:
NomeObjeto.Update.
No trecho de código a seguir, estamos alterando um registro da tabela Customers do Banco de Dados Northwind.
Neste fragmento, o objeto Clientes deve ser um objeto do tipo RecordSet que está ligado à tabela Customers
do Banco de Dados Northwind. Para alterar o registro atual, utilizaríamos os seguintes comandos:
Clientes.Fields(“CustomerID”)=“XXXXX”
Clientes.Fields(“CompanyName”)=“Empresa ABC Ltda.”
Clientes.Fields(“ContactName”)=“José da Silva Pereira”
Clientes.Fields(“ContactTitle”)=“Gerente”
Clientes.Fields(“Address”)=“Rua das amoreiras – 999”
Clientes.Fields(“City”)=“Cafundó”
Clientes.Fields(“Region”)=“Fim do Mundo”
Clientes.Fields(“PostalCode”)=“12345-678”
Clientes.Fields(“Country”)=“Brasil”
Clientes.Fields(“Phone”)=“(55)222-2222”
Clientes.Fields(“Fax”)=“(55)333-4455”
Clientes.Update
Para excluir o registro atual, utilizamos o método Delete, do objeto RecordSet. Por exemplo, para
excluir o registro atual do RecordSet Clientes, utilizamos o seguinte comando:
Clientes.Delete
O registro atual será excluído, lá na tabela do Banco de Dados, tabela que está associada com o objeto
RecordSet Clientes.
CONCLUSÃO
Neste capítulo, tratamos de uma série de assuntos relacionados com o acesso aos dados de um servidor
SQL Server 2005, utilizando a dobradinha ADO/OLE DB. Também falamos sobre a utilização de ODBC,
porém salientando que esta é uma tecnologia mais antiga (porém ainda utilizada em muitas aplicações;
até mesmo novas aplicações têm sido desenvolvidas usando ODBC, por falta de conhecimentos sobre
as novas tecnologias, por parte dos projetistas e programadores).
Iniciamos o capítulo falando do modelo de desenvolvimento em duas, três ou n camadas. Vimos os

problemas com o modelo tradicional Cliente/Servidor em duas camadas. Também aprendemos sobre
o modelo de n camadas e como este modelo se propõe a minimizar ou até eliminar a maioria dos
problemas relacionados à manutenção e atualização de aplicações.
Na seqüência, aprendemos a preparar o servidor para que o amigo leitor pudesse acompanhar os
exemplos deste capítulo. Aprendemos a criar uma pasta virtual no IIS e a acessar arquivos criados
dentro desta pasta.
Em seguida, estudamos um pouco de OLE DB e ADO. Vimos qual o modelo de acesso através da
utilização de OLE DB Providers. Também vimos qual o papel do ADO no acesso aos dados.
No restante do capítulo, estudamos alguns objetos do Modelo de Objetos do ADO e mostramos alguns
exemplos práticos, através da utilização de páginas ASP para acesso a dados no servidor SQL Server
2005. Aprendemos a realizar as operações básicas com os dados do servidor, tais como:
♦ Pesquisar
♦ Inserir novos registros
♦ Alterar registros
♦ Excluir registros
No próximo capítulo, falaremos um pouco sobre o acesso aos dados do SQL Server 2005 utilizando o
Microsoft Access 2000. Também apresentaremos uma noção básica sobre XML e como o SQL Server
2005 dá suporte ao padrão XML.
Capítulo 12
ACESSANDO DADOS COM O MICROSOFT
ACCESS E O PADRÃO XML
INTRODUÇÃO
Neste capítulo, vamos tratar de dois assuntos relacionados ao desenvolvimento de aplicações:
♦ Utilizando o Microsoft Access 2000 como Front-End para os dados do SQL Server 2005.
♦ Uma Introdução ao padrão XML.
Na primeira parte do capítulo, tratarei sobre a utilização do Microsoft Access para acessar os dados do
SQL Server 2005. A idéia básica é utilizar as facilidades de desenvolvimento do Microsoft Access, em
conjunto com as facilidades de manipulação e armazenamento de dados do SQL Server. Para que isso
seja possível o Microsoft Access precisa ter acesso aos dados armazenados no SQL Server.
Iremos apresentar uma breve introdução ao Microsoft Access e a seus elementos principais. Esta
introdução será importante para que possamos prosseguir com os próximos tópicos, onde iremos
analisar diversas maneiras de conectar um Banco de Dados do Access com dados de um Banco de
Dados do SQL Server.
Veremos que existem diversas maneiras de estabelecer esta comunicação. Tratarei, dentre outras, das
seguintes formas de comunicação entre o Microsoft Access e o SQL Server:
♦ Importando dados do SQL Server em tabelas do Microsoft Access.
♦ Anexando tabelas no Microsoft Access.
♦ Criando consultas no Microsoft Access, baseadas em tabelas do SQL Server 2005.
Sempre focaremos a conexão dos elementos de um Banco de Dados do Microsoft Access com dados do
SQL Server 2005. De maneira alguma este capítulo é um tratado completo sobre o desenvolvimento de
aplicações utilizando o Microsoft Access e o SQL Server 2005. Também é aconselhável que o leitor já
tenha alguma experiência com o Microsoft Access e com a linguagem de programação VBA.
Em seguida, veremos como acessar dados do SQL Server 2005 utilizando simplesmente o nosso
navegador. Veremos quais as condições necessárias para que possamos acessar dados, simplesmente
utilizando o protocolo HTTP – Hypertext Transfer Protocol. Veremos como executar um comando SQL
embutido em uma URL, através do protocolo HTTP. Esta é uma das novidades do SQL Server 2002 em
relação às versões anteriores, a qual também faz parte do SQL Server 2005.
Na parte final do capítulo, falaremos um pouco sobre o padrão (muitos classificam como linguagem)
XML – Extensible Markup Language. Veremos o que é o XML, qual a sua importância e qual o suporte
do SQL Server 2005 em relação a este padrão. Também veremos como fazer com que uma consulta
retorne os resultados no formato XML, utilizando a cláusula FOR XML. Esta cláusula é mais uma das
novidades do SQL Server 2005. Sem dúvida que a capacidade de trabalhar de forma nativa com o XML
é uma grande vantagem do SQL Server 2005. Só o uso do XML no SQL Server 2005 daria, certamente,
um livro. Está fora do escopo deste livro abordar o uso do XML no SQL Server 2005. No Books Online
você encontra informações detalhadas sobre o uso do XML no SQL Server 2005.
Para maiores informações sobre XML, consulte os seguintes endereços:
♦ www.xml.org.
♦ www.wdvl.com/Software/XML.
CAPÍTULO 12 – ACESSANDO DADOS COM O MICROSOFT ACCESS E O PADRÃO XML
♦ www.w3.org/xml.
♦ www.internet.com.
♦ xml101.com.
♦ www.xmlpitstop.com/.
♦ www.xml.com.
DESENVOLVIMENTO EM: UMA RÁPIDA REVISÃO SOBRE A ESTRUTURA

DE UM BANCO DE DADOS DO MICROSOFT ACCESS
PRÉ-REQUISITOS
♦ Noções sobre o Microsoft Access.
METODOLOGIA
♦ Apresentação dos objetos que compõem um Banco de Dados do Microsoft Access.
Neste tópico, vamos fazer uma rápida revisão sobre a estrutura de um Banco de Dados do Microsoft
Access: como é armazenado e do que é composto.
O Microsoft Access 2000, XP e 2003, a exemplo das versões anteriores, armazena todos os elementos
de um Banco de Dados, em um único arquivo com a extensão .mdb. Quer o Banco de Dados tenha
uma ou dezenas de tabelas e outros elementos, sempre será criado um único arquivo com a extensão
.mdb, arquivo este onde estão gravados todos os elementos deste Banco de Dados. Esta forma de
armazenamento difere de sistemas mais antigos, como por exemplo o Dbase III e Dbase IV, onde cada
tabela era armazenada em um arquivo separado, cada índice em um arquivo diferente, cada formulário
em um arquivo diferente e assim por diante. Esta estrutura também é diferente da utilizada pelo SQL
Server 2005, o qual cria, no mínimo, um arquivo primário (.mdf) e um arquivo de log (.log), podendo
ter zero ou mais arquivos secundários (.ndf), para cada Banco de Dados.
NOTA
Para maiores informações sobre a maneira como o SQL Server 2005 armazena um Banco de Dados e sobre arquivos primários, secundários
e de log, consulte o Capítulo 3 – Trabalhando com Banco de Dados no Microsoft SQL Server 2005.
Um Banco de Dados do Microsoft Access 2000 pode conter diversos elementos. Os principais são:
♦ Tabelas
♦ Consultas
♦ Formulários
♦ Relatórios
♦ Páginas de Dados (novidade a partir do Microsoft Access 2000)
♦ Macros
♦ Módulos
Na Figura 12.1, vemos o arquivo de exemplo Northwind.mdb carregado no Microsoft Access. No painel
da esquerda vemos as opções para os principais elementos que formam um Banco de Dados do Access
2000. Se clicarmos, por exemplo, na opção Consultas, será exibida uma listagem das consultas do
Banco de Dados Northwind; se clicarmos na opção Relatórios, será exibida uma listagem com os relatórios
do Banco de Dados Northwind e assim por diante. Estes diversos elementos são também conhecidos
como objetos do Banco de Dados. Uma tabela é um objeto, uma consulta é um objeto e assim por
diante. Para acessar um determinado objeto basta dar um clique duplo no objeto.
Figura 12.1 Elementos básicos de um Banco de Dados do Microsoft Access.
A seguir, vamos a uma descrição básica dos diversos elementos que compõem um Banco de Dados do
Microsoft Access.
TABELAS
As tabelas são os objetos onde ficam gravados os dados inseridos pelos usuários. Uma tabela é um
conjunto de dados sobre um tópico específico, como produtos, clientes, pedidos ou fornecedores.
Utilizar uma tabela separada para cada tópico significa armazenar os dados somente uma vez, o que
torna o Banco de Dados mais eficiente e reduz os erros de entrada de dados, conforme descrito no
Capítulo 1, quando falamos do modelo Relacional de dados.
É importante salientar que o único local onde ficam gravados os dados é em objetos do tipo tabela.
Para criar novas tabelas podemos utilizar a opção Criar tabela no modo estrutura ou a opção Criar
tabela usando assistente. Todo objeto no Microsoft Access 2000 possui um modo chamado modo
estrutura. No modo estrutura é que definimos as características e propriedades do objeto. Por exemplo,
no modo estrutura de uma tabela definimos quais os campos que farão parte da tabela e quais as
características de cada campo. Na Figura 12.2, temos uma visão do modo estrutura da tabela Clientes,
onde são exibidas as propriedades para o campo CódigoDoCliente.
Figura 12.2 Modo estrutura da tabela Clientes.
Para acessar o modo estrutura de um objeto, dê um clique com o botão direito do mouse no objeto e,
no menu que surge, selecione a opção Modo Estrutura.
CONSULTAS
Utilizamos consultas para poder visualizar os dados de diversas maneiras diferentes. Por exemplo,
podemos querer uma listagem onde são acessados dados de duas ou mais tabelas. Também podemos
querer uma listagem onde somente são exibidos registros que atendam um ou mais critérios. Tudo o
que falamos sobre views, no Capítulo 9, também é válido para consultas no Microsoft Access 2000. Na
verdade views são consultas.
O tipo mais comum de consulta é a consulta seleção. Uma consulta seleção recupera dados de uma ou
mais tabelas através de critérios especificados e exibe os dados na ordem escolhida. Também podemos
criar consultas para alterar e excluir dados, para fazer uma referência cruzada entre os dados ou para
criar uma nova tabela com base nos resultados obtidos.
É importante salientar que as consultas não armazenam dados. Quando uma consulta é gravada no Banco
de Dados, a única coisa que é salva no banco de dados é o comando SQL que define a consulta. Quando for
executada, a consulta busca os dados em uma ou mais tabelas e exibe os resultados para o usuário.
A exemplo das tabelas, uma consulta também possui um modo estrutura. Na Figura 12.3, temos o
modo estrutura da consulta – Consulta Pedidos. Este modo é conhecido por QBE – Query By Example.
Figura 12.3 Modo estrutura da consulta – Consulta Pedidos.
Para consultas, além do modo estrutura, temos o modo SQL, onde é exibido o comando SQL que define
a consulta. Para exibir o modo SQL, estando no modo estrutura, selecione o comando Exibir -> Modo
SQL. Na Figura 12.4, temos o modo SQL da consulta – Consulta Pedido – do Banco de Dados
Northwind.mdb. O comando que aparece nesta figura é o que é gravado no Banco de Dados. Em resumo,
o que define uma consulta é um comando SQL e é este comando que é salvo no Banco de Dados.
No modo estrutura é que definimos as características e propriedades do objeto. Por exemplo, no modo
estrutura de uma consulta, definimos quais os campos que farão parte da consulta, quais os critérios de
filtragem e ordenação e assim por diante. Ao fazermos alterações neste modo, o Microsoft Access altera
o comando SQL para refletir as mudanças efetuadas.
Figura 12.4 Modo SQL da consulta – Consulta Pedidos.
FORMULÁRIOS
Um formulário permite que sejam criadas telas gráficas mais fáceis de utilizar. Com a utilização de
formulários podemos criar um aplicativo com aparência profissional, onde podemos inserir botões de
comando, menus e todos os elementos de desenvolvimento do ambiente Windows. Os formulários
também expõem um modelo de eventos, os quais facilitam uma série de operações, como por exemplo
a validação de dados.
Podemos criar formulários para executar diversas ações, dentre as quais podemos destacar as seguintes:
♦ Servir para entrada de dados em uma ou mais tabelas.
♦ Servir como interface de navegação do aplicativo.
♦ Servir como uma caixa de diálogo onde o usuário pode inserir informações.
Um formulário obtém dados a partir de uma tabela ou a partir de uma consulta. No caso de um
formulário baseado em uma consulta, quando o formulário é aberto, a consulta associada é executada.
A consulta obtém dados de uma ou mais tabelas e retorna os dados obtidos para o formulário. O
formulário pode exibir os dados e pode ou não permitir que os dados sejam alterados ou que novos
dados sejam inseridos.
O formulário possui um modo estrutura que é onde construímos o formulário. A criação de um

formulário é semelhante à criação de formulários em ferramentas de desenvolvimento como o
Visual Basic ou Delphi. Basicamente, vamos arrastando e configurando elementos em uma tela
gráfica. Também podemos escrever código para responder a eventos que acontecem no formulário.
Na Figura 12.5, temos o modo estrutura do formulário Pedidos, do banco de dados Northwind.mdb.
Observe que temos uma “Caixa de Ferramentas”, a partir da qual podemos arrastar elementos para
a construção do formulário.
Figura 12.5 Modo estrutura do formulário Pedidos.
Na Figura 12.6, temos o formulário carregado, já no modo Formulário, para ser utilizado pelo usuário.
Este modo é conhecido como Modo Formulário. Observe que temos um formulário onde são exibidas
(e podem ser inseridas) informações, de duas tabelas diferentes: Pedidos e Detalhes do Pedido. Esta
facilidade de podermos digitar as informações do cabeçalho do pedido (tabela Pedidos) e dos itens do
pedido (tabela Detalhes do Pedido), em uma mesma tela, ilustra bem a utilidade dos formulários.
Figura 12.6 Modo formulário do formulário Pedidos.
RELATÓRIOS
Com a utilização de consultas podemos obter diversas listagens, inclusive com a especificação de um
ou mais critérios de pesquisa/filtragem. Porém não temos como formatar com um layout mais
profissional a listagem retornada por uma consulta. Para solucionar este problema podemos utilizar
relatórios. Por exemplo, um relatório pode ser baseado em uma consulta. Ao abrir o relatório, a consulta
é executada, os dados são retornados a partir das tabelas e são passados para o relatório. O relatório
recebe os dados retornados pela consulta e acrescenta elementos de formatação que deixam a aparência
da listagem bem mais profissional.
Quero salientar novamente que os dados somente ficam armazenados nas tabelas. O relatório é baseado
na consulta, e esta por sua vez é executada ao abrirmos o relatório. A consulta busca os dados em uma
ou mais tabelas e retorna a listagem obtida, para o relatório. Este, por sua vez, dá uma aparência
profissional aos resultados.
Também podemos ter um relatório baseado em uma tabela. Neste caso, ao abrirmos o relatório, este vai
buscar dados diretamente na tabela associada.
Figura 12.7 Modo estrutura do relatório Resumo de Vendas por Ano.
O relatório tem um modo estrutura que é onde construímos e definimos a formatação do relatório. A
criação de um relatório é semelhante à criação de relatórios em ferramentas de desenvolvimento como
o Visual Basic ou Delphi. Basicamente, vamos arrastando e configurando elementos em uma tela
gráfica. Também podemos escrever código para responder a eventos que acontecem no formulário. Na
Figura 12.7, temos o relatório aberto no modo estrutura do relatório Resumo de Vendas por Ano.
Observe que temos uma “Caixa de Ferramentas”, a partir da qual podemos arrastar elementos para a
construção do relatório.
Na Figura 12.8, temos o relatório aberto no modo de visualização de impressão. Este modo permite
que o usuário visualize o relatório na tela do micro, antes de enviar o relatório para a impressora.
Figura 12.8 Modo visualizar impressão do relatório Resumo de Vendas por Ano.
Também gostaria de comentar que este relatório é baseado na consulta Resumo de Vendas por Ano.
Esta consulta é que consolida os dados de vendas anuais, por trimestre. Esta consolidação é feita a
partir de dados das tabelas Pedidos e Detalhes do Pedido. Este exemplo demonstra bem o inter-
relacionamento entre os diversos objetos que compõem um banco de dados do Access.
PÁGINAS
Uma página de acesso a dados é um tipo especial de página da Web, projetado para exibir e trabalhar
com dados da Internet ou de uma intranet – dados que são armazenados em um Banco de Dados do
Microsoft Access ou do Microsoft SQL Server. A página de acesso a dados também pode incluir dados
de outras fontes como, por exemplo, o Microsoft Excel.
NOTA
Esta é uma das novidades do Microsoft Access 2000 em relação às versões anteriores.
Podemos estruturar as páginas de acesso a dados no modo estrutura de página no Microsoft Access. A
página é um arquivo separado armazenado fora do Microsoft Access; entretanto, quando você cria o
arquivo, o Microsoft Access automaticamente adiciona um atalho ao arquivo na janela Banco de Dados.
Estruturar uma página de acesso a dados é semelhante a estruturar formulários e relatórios – você usa
uma lista de campos, a caixa de ferramentas, os controles, a caixa de diálogo Classificar e agrupar etc.
Entretanto, há algumas diferenças significativas na maneira como você estrutura e interage com as
páginas de acesso a dados, em oposição a formulários e relatórios. A forma como você estrutura a
página depende para que ela será usada:
♦ Relatório interativo: Este tipo de página de acesso a dados é freqüentemente usado para
consolidar e agrupar informações armazenadas no Banco de Dados e, em seguida, publicar
resumos dos dados. Por exemplo, uma página poderia publicar o desempenho de vendas de
cada região em que você faz negócios. Usando indicadores de expansão, você pode ir de um
resumo geral das informações como, por exemplo, uma lista de todas as regiões e suas vendas
combinadas totais, a detalhes específicos sobre vendas individuais dentro de cada região. Embora
a página de acesso a dados também possa fornecer botões da barra de ferramentas para classificar
e filtrar os dados, você não pode editar dados nesse tipo de página.
♦ Entrada de dados: Este tipo de página de acesso a dados é usado para exibir, adicionar e
editar registros.
♦ Análise de dados: Este tipo de página de acesso a dados pode incluir uma lista de tabelas
dinâmicas, semelhante a um formulário de tabela dinâmica do Microsoft Access ou um relatório
de tabela dinâmica do Microsoft Excel, que permite que você reorganize os dados para analisá-
los de maneiras diferentes. A página poderia conter um gráfico que você usaria para analisar
tendências, detectar padrões e comparar dados em seu Banco de Dados. Ou a página poderia
conter uma planilha na qual você poderia inserir e editar dados, e usar fórmulas para calcular
como você faz no Microsoft Excel.
Na Figura 12.9, temos a página de dados Analisar Vendas, no modo estrutura.
Como usar páginas de acesso a dados no Internet Explorer?
Uma página de acesso a dados é conectada diretamente a um Banco de Dados. Quando usuários exibem
a página de acesso a dados no Microsoft Internet Explorer, eles estão exibindo sua própria cópia da
página. O que significa que qualquer filtragem, classificação e outras alterações que eles fazem na
maneira com que os dados são exibidos – incluindo alterações que eles fazem dentro de uma lista de
tabelas dinâmicas ou planilha – afetam somente sua cópia da página de acesso a dados. Entretanto,
alterações feitas nos próprios dados – como, por exemplo, modificar valores e adicionar ou excluir
dados – são armazenadas no Banco de Dados base e, portanto, estão disponíveis para qualquer pessoa
que exiba a página de acesso a dados.
Figura 12.9 Modo estrutura da página Analisar Vendas.

NOTA
Para exibir e trabalhar com a página de acesso a dados na Internet ou em uma intranet, os usuários precisam do Microsoft Internet Explorer
5 ou Superior.
Na Figura 12.10, temos a página de dados Analisar Vendas, carregada no Internet Explorer.
Observe o sinal de + ao lado do nome do cliente. Se dermos um clique no sinal de + ao lado do nome
do cliente, serão exibidos detalhes sobre as vendas para este cliente.
Como usar páginas de acesso a dados no Microsoft Access?
Você também pode trabalhar com uma página de acesso a dados no modo página no Microsoft Access.
As páginas de acesso a dados podem suplementar os formulários e relatórios que você usa em seu
aplicativo de Banco de Dados.
Na Figura 12.11, temos a página de dados Analisar Vendas, carregada no Microsoft Access.
Figura 12.10 Página Analisar Vendas no Internet Explorer.
Figura 12.11 Página Analisar Vendas no Microsoft Access.
MACROS
Macros são utilizadas em diversos programas para automatizar tarefas repetitivas. Por exemplo, se para
obter um determinado resultado temos que executar uma série de quatro consultas em seqüência, e
depois exportar os dados para uma planilha do Microsoft Excel, podemos criar uma macro que faça
estas ações para nós, de uma maneira automatizada.
Existem diversas ações de macros predefinidas que podem ser utilizadas no Microsoft Access. Por
exemplo, temos macros para abrir tabelas, consultas e formulários, para exportar dados para o Excel,
para o Dbase III e assim por diante.
A exemplo de outros objetos, uma macro também tem um modo estrutura. Neste modo, vamos
definindo uma ou mais ações que farão parte da macro. Se houver mais do que uma ação, estas serão
executadas na ordem em que foram definidas, na estrutura da macro.
Na Figura 12.12, temos a estrutura da macro Fornecedores do Banco de Dados Northwind. Esta macro
possui diversas ações.
Figura 12.12 Modo estrutura da macro Fornecedores.
Podemos fazer com que uma macro seja executada em resposta a um evento de um formulário ou de
um relatório. Também podemos executar macros com a utilização de comandos da linguagem VBA.
MÓDULOS
Os módulos contêm código VBA – Visual Basic for Application. Com a utilização do VBA, podemos
criar aplicações profissionais, utilizando o Microsoft Access. Para se ter uma idéia, através do VBA
temos acesso a todos os objetos do modelo ADO – Activex Data Object. Com isso podemos criar
objetos dos tipos Connection e RecordSet, como os que criamos com páginas ASP, no capítulo anterior.
A linguagem VBA é bastante poderosa. Através dela podemos ter acesso a todos os objetos do ambiente
do Microsoft Access. Por exemplo, utilizando VBA podemos criar tabelas, configurar a segurança, criar
e executar consultas, e assim por diante.
A exemplo de outros objetos, um módulo também tem um modo estrutura. Na verdade, o modo
estrutura de um módulo é o ambiente de desenvolvimento onde podemos escrever código VBA. Neste
ambiente, temos algumas facilidades para a escrita e depuração de código em VBA.
Na Figura 12.13, podemos ver o modo estrutura do módulo Funções Utilitárias do Banco de Dados
Northwind.mdb.
Figura 12.13 Modo estrutura do módulo Funções Utilitárias.
Podemos fazer com que um módulo seja executado em resposta a um evento de um formulário ou de
um relatório.
Com isso encerramos a nossa breve visão sobre os principais elementos de um Banco de Dados do
Microsoft Access. Maiores informações sobre o Microsoft Access 2000 podem ser encontradas com a
documentação do produto.
DESENVOLVIMENTO EM: COMO ACESSAR DADOS DO SERVIDOR

SQL SERVER 2005 UTILIZANDO O MICROSOFT ACCESS
PRÉ-REQUISITOS
♦ Noções sobre os elementos que compõem um Banco de Dados do Microsoft Access.
♦ Conhecimento básico de ODBC.
METODOLOGIA
♦ Apresentação de diferentes maneiras, para acessar os dados do SQL Server 2005, a partir do Microsoft Access.
TÉCNICA
♦ Utilização dos comandos apresentados para acessar os dados no Servidor SQL Server 2005.
Temos várias opções para, a partir do Microsoft Access, ter acesso aos dados do SQL Server 2005.
Iremos aprender a utilizar as seguintes opções:
♦ Importando dados do SQL Server em tabelas do Microsoft Access.
♦ Anexando tabelas no Microsoft Access.
♦ Criando consultas no Microsoft Access, baseadas em tabelas do SQL Server 2005.
Cada uma destas abordagens tem suas vantagens, desvantagens e se aplica em situações específicas.
Vamos estudá-las individualmente.
IMPORTANDO DADOS DO SQL SERVER EM TABELAS DO MICROSOFT ACCESS

Podemos importar os dados que estão em tabelas de um Banco de Dados do SQL Server 2005, para
tabelas em um Banco de Dados do Microsoft Access. Com a importação, os dados são copiados das
tabelas de um Banco de Dados para as do outro.
Uma das vantagens da importação é que os dados ficam gravados no arquivo .mdb, do Banco de Dados
do Microsoft Access. Desta forma os dados são acessados localmente, o que pode propiciar um melhor
desempenho. Outra vantagem é que os dados podem ser acessados, mesmo que a conexão de rede com
o servidor SQL Server 2005 tenha sido temporariamente interrompida.
Como nem tudo são vantagens, temos a desvantagem da falta de sincronização dos dados. Explicando
melhor, com a importação, não existe nenhuma vinculação entre as tabelas no Microsoft Access e no
SQL Server 2005. Em outras palavras, se os dados no SQL Server 2005 forem alterados, as alterações não
serão repassadas para as tabelas do Microsoft Access. A única maneira de receber as alterações é excluir
as tabelas no Microsoft Access e fazer a importação novamente.
Por isso não é muito comum a utilização de importação. Uma situação específica em que pode ser
aconselhada a importação é quando alguém (por exemplo, um auditor) precisa ter uma cópia dos
dados em sua estação de trabalho ou notebook, para depois trabalhar nestes dados e realizar consultas
específicas. Nesta situação, pode ser interessante fazer uma importação dos dados e trabalhar localmente.
No caso de um notebook que será utilizado, por exemplo, em casa, sem comunicação com a rede da
empresa, a importação durante o horário do expediente, enquanto o notebook está conectado à rede,
pode ser a única solução.
Para que possamos fazer a importação, uma fonte ODBC deve ter sido previamente criada. Além disso,
deve ser uma fonte ODBC de um dos seguintes tipos:
♦ File DSN.
♦ Machine DSN.
Se a importação tiver que ser feita por vários usuários em várias estações ou notebooks diferentes, pode
ser mais interessante utilizar uma fonte do tipo File DSN. Nesta situação, o administrador cria a fonte
ODBC, a qual será gravada em um arquivo e envia este arquivo, por disquete ou por e-mail, para todos
os usuários que precisam fazer a importação dos dados. Estes, por sua vez, utilizam a fonte ODBC para
proceder à importação dos dados. Uma fonte ODBC do tipo File DSN é gravada em um arquivo, o que
facilita a distribuição da fonte para vários usuários.
Já uma fonte ODBC do tipo Machine DSN somente pode ser utilizada na estação de trabalho onde foi criada.
Antes de aprendermos a importar dados do SQL Server 2005 para o Microsoft Access, vamos criar uma
fonte ODBC do tipo File DSN.
Exercício: Criar uma fonte ODBC do tipo File DSN, a qual aponta para a instância SERVIDOR\SQL2005
e faz conexão com o Banco de Dados pubs. Vamos salvar esta fonte com o nome de Instancia2.dsn, na
pasta C:\Meus documentos.
Para criar a fonte ODBC Instancia2.dsn, siga os passos indicados a seguir:
Fontes de dados (ODBC)).
2. Dê um clique na guia DSN de arquivo. Irá surgir uma lista com as fontes do tipo File DSN já
existentes. Por padrão, são exibidas as fontes do tipo File DSN gravadas na pasta X:\Arquivo
de Programas\Arquivos comuns\Data Sources\ODBC, onde X: é o drive onde está instalado
o Windows.
3. Dê um clique no botão Adicionar, para criar uma nova fonte ODBC.
4. Surge uma janela perguntando qual o tipo de Banco de Dados que você deseja acessar. Selecione
SQL Server, conforme indicado na Figura 12.14, e dê um clique no botão Avançar.
5. Surge a janela para você definir a pasta e o nome do arquivo onde serão salvas as informações
sobre a fonte que está sendo criada. Digite C:\Meus documentos\Instancia2.dsn, conforme
indicado na Figura 12.15, e clique no botão Avançar.
Figura 12.14 Definindo uma fonte para o SQL Server.
Figura 12.15 Definindo a pasta e o nome da fonte do tipo File DSN.
6. Será exibido um resumo sobre as informações selecionadas até o momento. Dê um clique no

botão Concluir. É aberta a janela “Criar uma nova fonte de dados para o SQL Server”, conforme
Figura 12.16 Definições para a fonte ODBC para o SQL Server.
Nesta janela, devemos fornecer diversas informações, tais como um comentário para a fonte que está
sendo criada e a instância à qual queremos que a mesma faça conexão.
7. No campo Descrição, digite Conexão ODBC com a instância SQL2005.
8. Na lista Server, selecione o nome do Servidor SQL a ser utilizado. No nosso exemplo,
SERVIDOR\SQL2005-06-11.
A janela deve estar conforme indicado na Figura 12.17.
Figura 12.17 Definições para a fonte ODBC.
9. Dê um clique no botão Avançar, seguindo para a próxima etapa.
10. Nesta etapa definimos o tipo de autenticação a ser utilizado. Como estamos nos conectando
com SERVIDOR\SQL2005, certifique-se de que “Com autenticação do SQL Server usando ident.
de logon e senha inseridos pelo usuário” esteja selecionada; para o campo Login ID digite sa e
para o campo Password digite a senha para o usuário sa.
11. Dê um clique no botão Avançar para ir para a próxima etapa. Nesta etapa, vamos definir com
qual Banco de Dados nos conectamos por padrão, ao estabelecer a conexão com
SERVIDOR\SQL2005. Clique na opção “Alterar banco de dados padrão para”. A lista abaixo
desta opção é habilitada. Nesta lista, selecione Pubs.
Em um servidor SQL Server podem existir diversos Bancos de Dados. Neste caso, estamos definindo a
qual Banco de Dados a nossa fonte ODBC irá conectar-se.
12. Dê um clique no botão Avançar, seguindo para a última etapa. Nesta etapa, podemos definir
diversas opções, tais como:
♦ O idioma para as mensagens do SQL Server.
♦ Se devemos ou não utilizar criptografia dos dados para aumentar a segurança.
♦ Se devemos utilizar as configurações regionais tais como hora, data e formato para números
em geral e para valores monetários.
13. Selecione as opções conforme indicado na Figura 12.18.
Figura 12.18 Finalizando a configuração da fonte ODBC.
14. Dê um clique no botão Concluir para finalizar a criação da fonte ODBC.
Surge a janela Instalação do ODBC para Microsoft SQL Server, a qual informa as diversas opções
selecionadas.
Nesta janela, podemos clicar no botão Testar fonte de dados, para verificar se a conexão com o Banco
de Dados está OK.
15. Dê um clique no botão Testar fonte de dados. Deve surgir uma janela indicando que o teste foi
realizado com sucesso.
16. Dê um clique em OK para fechar a janela de teste.
17. Dê um clique em OK para fechar a janela de resumo.
18. Você estará de volta à janela do gerenciador de fontes ODBC. Dê um clique em OK para fechá-lo.
Agora que temos a nossa fonte DSN de Arquvio – Instancia2.dsn, vamos criar um novo Banco de Dados
do Microsoft Access, na pasta C:\Meus documentos, com o nome de pubs.mdb. Após criarmos o Banco
de Dados, vamos utilizar a fonte Instancia2.dsn, para importar os dados das tabelas do Banco de Dados
pubs de SERVIDOR\SQL2005, para tabelas do Banco de Dados pubs.mdb do Microsoft Access.
Exercício: Importar os dados do Banco de Dados pubs da instância SERVIDOR\SQL2005, do servidor

SQL Server 2005, para o pubs.mdb do Microsoft Access, o qual será criado neste exercício.
Procedimento 1: Criar o Banco de Dados C:\Meus documentos\pubs.mdb.
Para criar o Banco de Dados C:\Meus documentos\pubs.mdb, faça o seguinte:
2. Na janela que surge, dê um clique na opção Banco de Dados vazio do Access, conforme indicado
na Figura 12.19 e clique em OK.
Surge a janela Novo arquivo de Banco de Dados.
3. Utilize a lista Salvar em, para navegar até a pasta C:\Meus documentos. No campo Nome do
arquivo, digite pubs.mdb e, depois, dê um clique no botão Criar.
O Banco de Dados pubs.mdb é criado e aberto no Microsoft Access. Por padrão, vem a guia Tabelas
selecionada. Observe que, como o banco acaba de ser criado, ainda não existe nenhuma tabela.
Com isso criamos o Banco de Dados pubs.mdb, vazio.
4. Mantenha o Microsoft Access aberto.
Procedimento 2: Importar as tabelas do Banco de Dados pubs, da instância SERVIDOR\SQL2005, do

SQL Server 2005.
Para importar as tabelas do Banco de Dados pubs, de SERVIDOR\SQL2005, siga os passos indicados a seguir.
Figura 12.19 Criando um novo Banco de Dados no Microsoft Access.
1. Estando com o Microsoft Access aberto e com o arquivo pubs.mdb carregado, selecione o
seguinte comando: Arquivo -> Obter dados externos -> Importar.
Surge a janela Importar, indicada na Figura 12.20.
Figura 12.20 A janela Importar.
Na lista Arquivos do tipo, devemos selecionar em qual formato estão os dados a serem importados
para o Microsoft Access. Podemos importar dados de diversos formatos, como por exemplo de outros
arquivos do Microsoft Access, de arquivos do Dbase, etc.
Para importar arquivos do SQL Server, temos que utilizar uma fonte ODBC.
2. Na lista Arquivos do tipo, selecione ODBC Databases( ).
Surge a janela Selecione a fonte de dados. Nesta janela, podemos selecionar uma fonte ODBC do tipo
DSN de arquivo ou fonte de dados de máquina.
3. Dê um clique na guia DSN de Arquivo e, no campo Nome da fonte, digite C:\Meus

documentos\Instancia2. dsn, conforme indicado na Figura 12.21.
Figura 12.21 Utilizando a fonte Instancia2.dsn criada anteriormente.
Surge a janela Logon do SQL Server. Nesta janela, devemos fornecer o nome de usuário e senha para
fazer a conexão com o servidor SQL Server 2005.
5. Digite sa para usuário e a senha para este usuário, conforme indicado na Figura 12.22.
Figura 12.22 Informações de login.
Surge a janela Importar Objetos, onde podemos selecionar quais tabelas serão importadas.
7. Dê um clique no botão Selecionar Tudo, para selecionar todas as tabelas. Sua tela estará conforme
Figura 12.23 Selecionando todas as tabelas.

NOTA
Você também pode selecionar as tabelas individualmente, caso não queira importar todas. Para ir selecionando as tabelas individualmente,
mantenha a tecla Ctrl pressionada e vá clicando nas tabelas a serem selecionadas.
Surge uma janela informando o progresso da importação. Uma vez encerrada a importação você
estará de volta ao Microsoft Access, onde já são exibidas as tabelas importadas, conforme indicado
na Figura 12.24.
Figura 12.24 Tabelas importadas com sucesso.
Observe que as tabelas são importadas com o nome no seguinte formato:
dono_da_tabela_Nome_da_Tabela
Podemos renomear as tabelas caso seja necessário. Para renomear uma tabela, clique com o botão
direito do mouse na tabela e, no menu que surge, dê um clique na opção Renomear. Digite o novo
nome e pressione Enter.
Ao importar as tabelas não é definido nenhum tipo de relacionamento entre as tabelas. Caso você precise definir relacionamentos do tipo Um
NOTA
para Vários ou do tipo Um para Um, terá que fazer isso manualmente. Para definir relacionamentos no Microsoft Access, utilizamos o
comando Ferramentas -> Relacionamentos.
ANEXANDO TABELAS NO MICROSOFT ACCESS

Anexar é diferente de importar. Ao anexarmos uma tabela, os dados não serão copiados para o Banco
de Dados .mdb, do Microsoft Access. Ao anexarmos uma tabela do SQL Server 2005, o Microsoft Access
cria uma referência à tabela que está sendo anexada, ao invés de copiar os dados da tabela. A referência
contém as informações necessárias para que o Banco de Dados do Microsoft Access possa acessar os
dados da tabela do SQL Server 2005. Os demais elementos do Microsoft Access – consultas, formulários,
relatórios, páginas, macros e módulos – podem acessar a tabela anexada, como se ela fosse uma tabela
local do próprio Access.
Uma das grandes vantagens da anexação é que os dados mantêm-se atualizados, ou seja, sempre que
alterações forem feitas nos dados no SQL Server, estas alterações tornam-se imediatamente visíveis no
Microsoft Access, utilizando o gerenciador de tabelas vinculado, o qual é acessado através do menu
Ferramentas -> Utilitários de Banco de Dados. Em contrapartida, se o servidor SQL Server estiver em
um computador da rede e perdermos o acesso à rede, também perderemos o acesso às tabelas anexadas.
Questões de desempenho também devem ser consideradas, uma vez que, ao utilizarmos tabelas anexadas,
poderemos ter uma grande quantidade de dados trafegando pela rede. Esta consideração torna-se mais
importante em situações de acesso remoto, onde o Banco de Dados do Microsoft Access e o servidor
SQL Server estão ligados através de um link de WAN de baixa velocidade.
Para aprendermos a anexar tabelas vamos criar um Banco de Dados chamado pubs_anexado.mdb, na
pasta C:\Meus documentos. Depois iremos anexar as tabelas (o Microsoft Access 2000 chama de vincular)
do Banco de Dados pubs, da instância SERVIDOR\SQL2005. Para que possamos anexar tabelas,
precisamos de uma fonte ODBC que faça a conexão com o Banco de Dados do SQL Server 2005, onde
estão as tabelas a serem anexadas. Nós já temos esta fonte ODBC, que foi criada no exemplo anterior:
C:\Meus documentos\Instancia2.dsn. Utilizaremos esta fonte no nosso exemplo prático.
Exercício: Utilizando as orientações do item anterior, crie um Banco de Dados chamado

pubs_anexado.mdb, na pasta C:\Meus documentos. Ao criar este Banco de Dados, este será,
automaticamente, carregado no Microsoft Access. Mantenha aberto o Banco de Dados pubs_anexado.mdb.
Para anexar tabelas do Banco de Dados pubs, da instância SERVIDOR\SQL2005, ao banco de dados
pubs_anexado.mdb do Microsoft Access, siga os passos indicados a seguir:
1. Estando com o Microsoft Access 2000 aberto, e com o arquivo pubs_anexado.mdb carregado,
selecione o seguinte comando: Arquivo -> Obter dados externos -> Vincular tabelas.
Surge a janela Vincular, indicada na Figura 12.25.
Na lista Arquivos do tipo, devemos selecionar em qual formato estão os dados cujas tabelas serão
anexadas ao Microsoft Access. Podemos anexar dados de diversos formatos, como por exemplo de
outros arquivos do Microsoft Access, de arquivos do Dbase, etc.
Para anexar arquivos do SQL Server, temos que utilizar uma fonte ODBC.
2. Na lista Arquivos do tipo selecione ODBC Databases( ).
Surge a janela Selecione a fonte de dados. Nesta janela, podemos selecionar uma fonte ODBC do tipo
Fonte de dados de Arquivo ou Fonte de dados de máquina.
3. Dê um clique na guia Fonte de dados de arquivo e, no campo Nome da fonte, digite C:\Meus
documentos\Instancia2.dsn, conforme indicado na Figura 12.26.
Figura 12.25 A janela Vincular.
Figura 12.26 Utilizando a fonte Instancia2.dsn criada anteriormente.
Surge a janela Logon do SQL Server. Nesta janela, devemos fornecer o nome de usuário e senha para
fazer a conexão com o servidor SQL Server 2005.
5. Digite sa para usuário e a senha para este usuário, conforme indicado na Figura 12.27.
Surge a janela Vincular tabelas, onde podemos selecionar quais tabelas serão anexadas, ou no idioma
do Microsoft Access, vinculadas.
7. Dê um clique no botão Selecionar Tudo, para selecionar todas as tabelas. Sua tela estará conforme
Figura 12.28 Selecionando todas as tabelas.

NOTA
Você também pode selecionar as tabelas individualmente, caso não queira anexar todas. Para ir selecionando as tabelas individualmente,
mantenha a tecla Ctrl pressionada e vá clicando nas tabelas a serem vinculadas.
Surge uma janela informando o progresso da vinculação.
9. Caso o Microsoft Access não consiga definir qual o relacionamento entre as tabelas, será exibida
uma janela solicitando que você defina informações adicionais para cada tabela na qual existem
dúvidas. No exemplo da Figura 12.29, o Microsoft Access está nos pedindo que informemos
qual o campo, ou conjunto de campos, que formam a chave primária para a tabela Dependentes.
Selecione os campos CPF e Nome, e dê um clique no botão OK.
Figura 12.29 Definindo uma chave primária composta por dois campos.

NOTA
Podem surgir mais janelas pedindo que sejam definidas informações adicionais. Se não informarmos todos os dados solicitados, pode
acontecer de algumas tabelas não poderem ter seus dados atualizados através do Microsoft Access.
Uma vez encerrada a anexação você estará de volta ao Microsoft Access, onde já são exibidas as tabelas
anexadas.
Observe que o ícone ao lado das tabelas anexadas é a figura de um pequeno globo. Este ícone é o indicativo
que permite diferenciar entre tabelas anexadas e as que fazem parte do Banco de Dados do Access.
Agora você pode utilizar as tabelas anexadas como se estas fizessem parte do banco de dados. Podemos
criar consultas, formulários, relatórios e demais objetos do Microsoft Access, os quais utilizam dados
das tabelas anexadas.
11. Feche o Microsoft Access 2000.

NOTA
Ao clicar com o botão direito do mouse em uma tabela anexada e selecionar o comando Excluir, você não irá excluir a tabela no Banco de
Dados do Microsoft SQL Server 2005; você irá apenas excluir as informações de vinculação com a tabela. A tabela no SQL Server 2005 não
será afetada. Ao fazer esta exclusão no Microsoft Access, você receberá uma mensagem semelhante à indicada na Figura 12.30.
Figura 12.30 Excluindo informações de vínculo.
CRIANDO CONSULTAS NO MICROSOFT ACCESS,

BASEADAS EM TABELAS DO SQL SERVER 2005
Vamos iniciar o nosso estudo, aprendendo a criar consultas baseadas em tabelas do SQL Server 2005,
ou seja, criamos uma consulta normalmente no Microsoft Access, porém a consulta acessa dados
diretamente em tabelas de um banco de dados do SQL Server 2005. É importante diferenciar que, neste
caso, não estamos acessando dados de uma tabela anexada, mas sim diretamente do SQL Server 2005.
Para que uma consulta do Microsoft Access possa acessar tabelas no SQL Server 2005, precisamos
configurar a propriedade SourceConnectStr (Seq de conexão da origem). Nesta propriedade informamos
uma string para que a consulta consiga estabelecer uma conexão ODBC com o SQL Server 2005. Outro
detalhe que devemos observar é que, uma vez estabelecida a conexão, as tabelas do SQL Server serão
acessadas com o nome no formato NomeDoSchemaDonoDaTabela.NomeDaTabela. Porém, no Microsoft
Access, o ponto (.) não é um caracter permitido como nome de tabela. Por isso, antes de executarmos
a consulta, iremos criar “aliases” para as tabelas. Criaremos aliases sem o ponto.
Vamos fazer um exemplo prático.
Exemplo: Criar um novo Banco de Dados chamado BuscaDadosNoSQL.mdb e salvá-lo na pasta C:\Meus
documentos. Neste Banco de Dados, criar uma consulta baseada nas tabelas Orders e Order Details do Banco
de Dados Northwind da instância SERVIDOR\SQL2005, do SQL Server 2005. Esta consulta deve retornar os
campos OrderID, OrderDate, ShipCountry e um campo calculado que forneça o valor total do pedido. Este
exercício será composto de dois procedimentos. No Procedimento 1, iremos criar o Banco de Dados
BuscaDadosNoSQL.mdb. No Procedimento 2, iremos criar a consulta “Relação de Pedidos a partir do SQL.
Procedimento 1: Para criar o Banco de Dados BuscaDadosNoSQL.mdb, faça o seguinte:

2. Na janela que surge, dê um clique na opção Banco de Dados vazio do Access, e depois dê um
clique no botão OK.
3. Surge a janela Novo arquivo de Banco de Dados. Utilize a lista Salvar em, para navegar até a
pasta C:\Meus documentos. No campo Nome do arquivo, digite BuscaDadosNoSQL.mdb.
4. Dê um clique no botão Criar.
O Banco de Dados BuscaDadosNoSQL.mdb é criado e aberto no Microsoft Access 2000. Por padrão,
vem a guia Tabelas selecionada. Observe que, como o banco acaba de ser criado, ainda não existe
nenhuma tabela.
Com isso, criamos o Banco de Dados BuscaDadosNoSQL.mdb.
5. Mantenha o Microsoft Access aberto.
Procedimento 2: Para criar a consulta Relação de Pedidos, a partir do SQL, siga os passos indicados a seguir:
1. Dê um clique na guia Consultas.
2. Dê um clique na opção Criar consulta, no modo Estrutura. Surge a janela Mostrar tabela, indicada na
Figura 12.31. Como acabamos de criar o Banco de Dados BuscaDadosNoSQL.mdb, a lista de tabelas
está vazia. Neste caso, faremos com que a nossa consulta busque dados no servidor SQL Server 2005.
Figura 12.31 A janela Mostrar tabela, sem nenhuma tabela na lista.
3. Dê um clique no botão Fechar.
A janela Mostrar tabela será fechada e você estará no modo estrutura para a criação de uma nova
consulta.
NOTA
Para maiores informações sobre a criação de views, consulte o Capítulo 9. Para maiores informações sobre a criação de consultas no
Microsoft Access 2000, consulte a documentação do produto.
Para fazer com que a consulta possa acessar tabelas em um Banco de Dados do servidor SQL Server,
precisamos configurar as propriedades da consulta. Mais especificamente, temos que definir a
propriedade Seq da conexão da origem.
4. Para acessar as propriedades da consulta, selecione o comando Exibir -> Propriedades. Surge a
janela Propriedades da consulta, indicada na Figura 12.32. Nesta janela, podemos definir a
propriedade Seq da conexão da origem.
5. Nesta propriedade temos que definir uma string de conexão ODBC para o Banco de Dados
Nortwhind, da instância SERVIDOR\SQL2005. Digite a seguinte string:
ODBC;DRIVER=SQL Server;UID=sa;PWD=abc123 LANGUAGE=Português
(Brasil);DATABASE=Northwind;WSID=SERVIDOR;APP=Microsoft Open Database
Connectivity;SERVER=SERVIDOR\SQL2005;
Uma string de conexão ODBC informa os parâmetros necessários para a conexão. Os parâmetros são
informados na forma de pares Nome_parâmetro = valor e os pares são separados por ponto-e-vírgula
(;). A única exceção é o primeiro parâmetro – ODBC –, o qual não é no formato de um par. Este
parâmetro informa que o que vem a seguir é a definição de uma string de conexão ODBC.
Figura 12.32 A janela de propriedades da consulta.
Na Tabela 12.1, temos a descrição dos parâmetros informados na string anterior.
Tabela 12.1 Parâmetros para a string de conexão ODBC.
DRIVER=SQL Server Este parâmetro informa o driver que será utilizado pela conexão ODBC. No caso, estamos informando que iremos
conectar utilizando o drive para o SQL Server.
UID Informa o nome do usuário, com o qual faremos a conexão com o servidor SQL Server. No nosso exemplo é o
usuário as.
PWD Informa a senha para o usuário informado no parâmetro UID.
LANGUAGE Informa o idioma para as mensagens de retorno, caso aconteça algum erro durante a conexão.
DATABASE Define com qual Banco de Dados iremos nos conectar, uma vez que podemos ter diversos Bancos de Dados em
uma instância do SQL Server 2005.
APP Informa que estamos utilizando ODBC.
Connectivity Define a qual instância iremos nos conectar. No nosso exemplo, estamos conectando com SERVIDOR\SQL2005.
6. Uma vez definida esta propriedade, feche a janela de propriedades da consulta. Para isso clique
no botão Fechar (x), da janela de propriedades.
Você estará de volta à consulta. Antes de testar se a nossa conexão ODBC está funcionando, vamos
salvar a consulta.
7. Selecione o comando Arquivo -> Salvar, ou dê um clique no botão Salvar (botão com o desenho
de um disquete).
8. Surge uma janela pedindo que você digite o nome da consulta. Digite Relação de Pedidos a
partir do SQL.
9. Dê um clique no botão OK e pronto, a consulta é salva.
O próximo passo é adicionar as tabelas Order e Order Details, para que possamos criar a consulta proposta.
10. Para adicionar tabelas, selecione o comando Consulta -> Mostrar tabela, ou dê um clique no
botão Mostrar tabela (botão com um sinal de + amarelo).
É exibida a janela Mostrar tabela, porém agora com a listagem das tabelas disponíveis no Banco de
Dados Northwind da instância SERVIDOR\SQL2005, conforme indicado na Figura 12.33.
Figura 12.33 Consulta no Microsoft Access acessando tabelas do SQL Server 2005.
11. Dê um clique duplo na tabela dbo.Orders para adicioná-la à consulta.

12. Dê um clique duplo na tabela dbo.Order Details para adicioná-la à consulta.
13. Dê um clique no botão Fechar para voltar à consulta. As tabelas dbo.Orders e dbo.Order Details
já estarão adicionadas.
Conforme comentado anteriormente, o Microsoft Access não aceita um ponto no nome das tabelas. Se
tentarmos criar uma consulta mantendo os nomes como estão, ao executarmos a consulta, receberemos
a mensagem de erro indicada na Figura 12.34.
Figura 12.34 Mensagem de erro devido ao ponto (.) no nome das consultas.
Não podemos renomear as tabelas no SQL Server 2005, até porque o dbo. significa o usuário dono da
tabela. O que podemos fazer é criar um alias (apelido) para a tabela. Este apelido é válido na consulta.
14. Para criar um apelido para a tabela Orders, clique com o botão direito no nome da tabela
(dbo.Orders) e, no menu que surge, selecione Propriedades. Na janela que surge digite um
alias, no nosso caso, digite Orders, conforme indicado na Figura 12.35. Após digitar o alias,
clique no botão Fechar (x), para voltar à consulta.
Figura 12.35 Criando um alias para a tabela Orders.
15. Repita o passo 14 e crie o alias OrderDetails para a tabela dbo.Order Details. A sua tela deve
estar conforme indicado na Figura 12.36.
Figura 12.36 Já foram definidos aliases para as duas tabelas.
Agora precisamos definir o relacionamento entre as duas tabelas. As tabelas Orders e Orders Details são
relacionadas através do campo OrderID. Ao criarmos um relacionamento em uma consulta, o
relacionamento somente é válido na consulta, ou seja, não estaremos definindo um relacionamento
no Banco de Dados Northwind da instância SERVIDOR\SQL2005. Na verdade, ao criarmos um
relacionamento, estamos utilizando uma cláusula Join, no comando T-SQL que define a consulta.
16. Para criar o relacionamento entre as duas tabelas, na consulta, clique no campo OrderID na
tabela Orders, mantenha o mouse pressionado e arraste o campo OrderID da tabela Orders sobre
o campo OrderID da tabela Order Details. Ao largar o mouse, surge uma linha unindo os dois
campos. Esta linha é um indicativo do relacionamento, conforme indicado na Figura 12.37.
Figura 12.37 Relacionamento definido na consulta.
De agora em diante é como se estivéssemos construindo uma consulta no Microsoft Access. Vamos
adicionar os campos OrderID, OrderDate e ShipCountry, além de um campo calculado.
17. Adicione o campo OrderID da tabela Orders. Para fazer isso você pode dar um clique duplo no
campo OrderID ou pode arrastá-lo da tabela Orders até a primeira coluna da consulta.Também
adicione os campos OrderDate e ShipCountry, da tabela Orders. A consulta deve estar conforme
18. Agora vamos adicionar um campo calculado. Na coluna em branco, ao lado do campo
ShipCountry, digite a seguinte fórmula, na primeira linha:
Total: ([Quantity]*[UnitPrice])*(1-[Discount])
A parte antes dos dois-pontos é um alias para o campo calculado, e o que vêm depois dos dois-pontos
é a fórmula para o cálculo.
Figura 12.38 Adicionando campos à consulta.
Esta fórmula calcula o total para cada item do pedido. Para calcular o total do pedido, temos que
agrupar os diversos itens de cada pedido e somá-los. Para fazer este agrupamento, temos que exibir a
linha de totais, na estrutura da consulta.
19. Para exibir a linha de totais, selecione o comando Exibir -> Total. Uma nova linha chamada
Total aparecerá abaixo da linha Tabela.
20. Agora vamos às configurações finais. Na linha de totais selecione Agrupar Por, para os campos
OrderID, OrderDate e ShipCountry. Para o campo calculado, selecione Soma.
Estamos quase prontos para executar a consulta e observar os resultados obtidos.
Antes de executarmos a consulta, vamos formatar os dados da coluna calculada.
21. Clique com o botão direito do mouse em qualquer linha da coluna calculada Total. No menu
que surge, selecione Propriedades. É aberta a janela de propriedades desta coluna.
22. Defina a propriedade Formato como sendo Moeda e a propriedade Casas decimais, como sendo
2, conforme indicado na Figura 12.39.
23. Clique no botão Fechar (x) da janela de propriedades para voltar à estrutura da consulta.
Classifique o campo OrderId em ordem crescente.
Agora estamos em condições de executar a consulta e observar os resultados obtidos.
Figura 12.39 Definindo as propriedades do campo calculado.
24. Para executar a consulta, selecione o comando Consulta -> Executar, ou dê um clique no botão
Executar (botão com uma exclamação vermelha).
Na Figura 12.40, temos os resultados da consulta.
Figura 12.40 Resultados da consulta.
25. Para você ter uma idéia do comando SQL associado à consulta, selecione o comando Exibir ->
Modo SQL. Deverá ser exibido o seguinte comando:
SELECT Orders.OrderID, Orders.OrderDate, Orders.ShipCountry,

Sum(([Quantity]*[UnitPrice])*(1-[Discount])) AS Total
FROM dbo.Orders AS Orders
INNER JOIN
dbo.[Order Details] AS [Orde Details]
ON
Orders.OrderID = [Orde Details].OrderID
IN
‘ ‘
[ODBC;DRIVER=SQL
Server;UID=sa;PWD=abc123;LANGUAGE=Português
(Brasil);DATABASE=Northwind;WSID=SERVIDOR;APP=Microsoft Open
Database Connectivity;SERVER=SERVIDOR\SQL2005;]
GROUP BY
Orders.OrderID, Orders.OrderDate, Orders.ShipCountry;
Observe a utilização da cláusula IN. Esta cláusula recebe dois parâmetros. O primeiro é um parâmetro
vazio (‘ ‘), no caso de estarmos utilizando uma conexão ODBC como o segundo parâmetro. Observe
que a string de conexão ODBC faz parte do comando SQL que retorna os dados, ou seja, a informação
para acessar o Banco de Dados Northwind da instância SERVIDOR\SQL2005 é passada no próprio
comando SQL.
26. Clique no botão Salvar para salvar a consulta.

27. Selecione o comando Arquivo -> Fechar para sair da consulta.
Neste tópico procurei mostrar algumas maneiras de acessar os dados do SQL Server 2005 de dentro do Microsoft Access. Falar sobre o
NOTA
desenvolvimento de aplicações, utilizando o Microsoft Access como Front End e o SQL Server 2005 como Back End, é assunto para um livro
inteiro. Aliás é um dos projetos nos quais estou pensando com carinho.
DESENVOLVIMENTO EM: ACESSANDO DADOS DO SERVIDOR

SQL SERVER 2005 COM O NAVEGADOR E O PADRÃO XML
PRÉ-REQUISITOS
METODOLOGIA
♦ Apresentação dos passos necessários para a configuração e acesso aos dados do servidor SQL Server 2005 através do navegador.
TÉCNICA
♦ Utilização do SQL Server Management Studio para configurar o acesso via navegador, aos dados do SQL Server 2005 e utilização do
navegador para testar o acesso.
Uma das grandes novidades do SQL Server 2000 e que também está disponível no SQL Server 2005 é a
possibilidade de acessarmos dados do SQL Server 2005, utilizando apenas um navegador. Antes que
isto seja possível, precisamos fazer algumas configurações para habilitar o acesso aos dados, através do
navegador. Por padrão, os dados são retornados no formato XML. Falaremos um pouco sobre XML na
parte final deste capítulo.
Para configurar o acesso a um Banco de Dados do SQL Server 2005, através do navegador, empregamos
o utilitário “IIS Virtual Directory Management for SQL Server”. Este utilitário permite a criação de um
diretório virtual no servidor IIS, pasta esta que faz conexão com o servidor SQL Server. Para que possamos
configurar esta pasta virtual, as seguintes condições devem ser atendidas:
♦ O servidor deve estar rodando Windows NT 4.0, Windows 2000 Server ou Windows Server 2003.
♦ Para o caso do Windows NT, temos algumas condições adicionais. Deve estar instalado o IIS
4.0 ou superior ou o PWS (Personal Web Server), para o caso do Windows NT Workstation 4.0.
Também deve estar instalado o MMC (Microsoft Management Console) 1.2. Esta versão do
MMC é instalada com o Option Pack 4.0 ou com o SQL Server 2005.
♦ Para computadores rodando Windows 2000 Professional, deve ser instalado o pacote de
ferramentas administrativas – Adminpak.msi. Este arquivo pode ser encontrado na pasta
%Windir%\System32 de computadores onde está instalado o Windows 2000 Server. Onde
%Windir% deve ser substituído pela pasta onde está instalado o Windows 2000 Server. Este
arquivo também pode ser encontrado na pasta I386 do CD de instalação do Windows 2000
Server. Para instalar este pacote de ferramentas administrativas, é só localizar o arquivo
Adminpak.msi, clicar com o botão direito do mouse no arquivo e, no menu de opções que
surge, clicar em Instalar.
Conforme citado anteriormente, precisamos usar o utilitário IIS Virtual Directory Management for
SQL Server, para criar um diretório virtual no IIS. Este utilitário cria uma associação entre o diretório
virtual do IIS e um Banco de Dados de uma instância do SQL Server 2005. Para acessar este utilitário
empregamos o seguinte caminho: Iniciar -> Programas -> SQLXML 4.0 -> Configure IIS Support.
O nome do servidor IIS e o nome do diretório virtual devem ser informados como parte da URL de
acesso. As informações definidas para o diretório virtual (como login, senha e permissões de acesso)
são utilizadas para estabelecer uma conexão com um Banco de Dados de uma instância do servidor
SQL Server 2005 e executar uma consulta.
Através do navegador, fazer os seguintes tipos de acessos:
♦ Acessar diretamente uma tabela do Banco de Dados. Neste caso, a URL deve incluir um nome
virtual do tipo dbobject. Veremos exemplos mais adiante.
NOTA
URL – Uniform Resource Locattor – nada mais é do que um endereço da Web. Por exemplo: http:www.microsoft.com/windows2000/
library/default.asp é uma URL.
♦ Executar um arquivo de modelo. Um arquivo de modelo é um documento no formato XML,
no qual temos um ou mais comandos SQL. Quando um arquivo de modelo é especificado em
uma URL, os comandos SQL armazenados no arquivo de modelo são executados. Também
podemos especificar uma consulta SQL (normalmente um comando SELECT), diretamente na
URL, porém esta não é uma prática recomendada por questões de segurança.
CONFIGURANDO O ACESSO ATRAVÉS DO NAVEGADOR

Agora chega de conversa e vamos ver este acesso via navegador funcionar na prática. O primeiro passo
é criar um diretório virtual associado a um Banco de Dados de uma instância do SQL Server 2005.
Vamos fazer isto no exemplo a seguir.
Exemplo: Criar um diretório virtual chamado NorthwindSQL, o qual é associado ao Banco de Dados
Northwind, da instância SERVIDOR\SQL2005.
Para criar o diretório virtual NorthwindSQL, faça o seguinte:
1. Antes de configurarmos o diretório virtual NorthwindSQL no IIS, precisamos criar a estrutura de

pastas que dá suporte a este diretório virtual. Esta estrutura de pastas e subpastas deve ser criada
abaixo do diretório raiz do servidor IIS. Por padrão, o diretório raiz é D:\Inetpub\wwwroot. Caso
o seu diretório esteja em outra unidade, troque o D:\ pela unidade correspondente. Dentro da
pasta wwwroot vamos criar uma pasta chamada NorthwindSQL. Dentro da pasta NorthwindSQL
vamos criar duas subpastas schema e template, conforme indicado na Figura 12.41.
Figura 12.41 Criando a estrutura de pastas e subpastas para o diretório virtual.
Uma vez criada esta estrutura de pastas e subpastas, vamos à criação do diretório virtual.
2. Abra o utilitário Configure IIS Support (Iniciar -> Programas -> SQLXML 4.0 -> Configure IIS
Support).
Surge o console IIS Virtual Directory Management for SQLXML 4.0, indicado na Figura 12.42.
Figura 12.42 O console IIS Virtual Directory Management for SQL Server.
3. Clique no sinal de + ao lado do nome do servidor. No meu exemplo, o nome é Servidor.

4. Surgem as opções Site da Web padrão e Site de administração na Web. Clique com o botão
direito do mouse na opção Site da Web padrão. No menu que surge, aponte para Novo ->
Virtual Directory.
Ao clicar em Virtual Directory, surge a janela Propriedades de New Virtual Directory, indicada na
Figura 12.43.
5. Na guia General, vamos definir o nome do diretório virtual (NorthwindSQL) e a pasta à qual
está associado o diretório virtual (C:\InetPub\wwwroot\NorthwindSQL), conforme indicado
na Figura 12.44.
NOTA
Mais uma vez quero lembrar que C:\Inetpub\wwwroot é a localização do diretório raiz, para o servidor IIS que eu estou utilizando. Caso você
esteja utilizando outras configurações, utilize-as no lugar das configurações apresentadas neste exemplo.
6. Dê um clique na guia Security.
Nesta guia, temos que fornecer informações sobre o tipo de autenticação que será utilizado e o nome
e senha do usuário para conexão com o servidor SQL Server.
7. Selecione SQL Server, na opção Account Type, digite sa no campo User Name e a senha do
usuário sa, no campo Password, conforme indicado na Figura 12.45.
Figura 12.43 Criando um novo diretório virtual.
Figura 12.44 Definindo o nome e a localização.
8. Dê um clique na guia Data Source.
9. Nesta guia definimos a instância do SQL Server 2005 associada com o diretório virtual que está
sendo criado e dentro da instância qual o Banco de Dados. Para instância, vamos selecionar
SERVIDOR\SQL2005 e, para o Banco de Dados, Northwind, conforme indicado na Figura 12.46.
10. Dê um clique na guia Settings.
11. Nesta guia, selecione todas as opções:
♦ Allow URL Queries.

♦ Allow template queries.
♦ Allow XPath.
♦ Allow POST.
12. Clique na guia Virtual Names. Nesta guia, associaremos nomes às subpastas template e schema.
13. Clique em New virtual name. No lado direito você define as opções para o novo nome virtual
que está sendo criado.
Figura 12.46 O Banco de Dados Northwind da instância SERVIDOR\SQL2005.
14. No campo Name, digite template. Na lista type, selecione template. No campo Path, digite:
C:\Inetpub\wwwroot\NorthwindSQL\template. Sua janela deve estar conforme indicado
na Figura 12.47.
15. Dê um clique no botão Save. O nome template já aparece na lista da esquerda.
16. Clique em New virtual name. No lado direito você define as opções para o novo nome virtual
que está sendo criado.
17. No campo Name, digite dbobject. Na lista type, selecione dbobject.
18. Dê um clique no botão Save.
19. Dê um clique no botão OK para salvar as configurações e criar o diretório virtual NorthwindSQL.
Feito isso o nosso diretório virtual terá sido criado, conforme indicado na Figura 12.48.
Figura 12.47 Associando nomes virtuais à pasta template.
Figura 12.48 O diretório virtual NorthwindSQL.
20. Feche o console IIS Virtual Directory Management for SQL Server.
No próximo tópico, iremos testar o acesso aos dados do SQL utilizando o navegador.
TESTANDO O ACESSO AOS DADOS DO SQL SERVER 2005, ATRAVÉS DO NAVEGADOR

Após termos configurado um diretório virtual associado com o Banco de Dados Northwind, podemos
testar o acesso aos dados utilizando HTTP. O nosso diretório virtual é chamado NorthwindSQL, conforme
configurado no exemplo anterior. Lembre que estou utilizando um computador com o nome de Servidor.
Se você estiver utilizando um nome diferente, substitua pelo nome correspondente.
Outro detalhe a ser observado é que os dados são retornados no formato XML – Extensible Markup
Language. No próximo item, falaremos um pouco sobre este padrão que vem sendo utilizado cada vez
mais na indústria de informática.
Para testar o acesso via HTTP, abra o Internet Explorer e digite o seguinte endereço:
http://servidor/NorthwindSQL?sql=SELECT * FROM Orders FOR XML AUTO&root=root
Este endereço envia o comando SELECT * FROM Orders para o Banco de Dados Northwind, associado
com o diretório virtual NorthwindSQL. Os dados são retornados no formato XML, conforme indicado
na Figura 12.49.
Figura 12.49 Dados no formato XML.
Ainda não conhecemos o formato XML, mas posso adiantar que um documento no formato XML
contém apenas dados, sem nenhuma informação a respeito do formato de exibição dos dados. A
seguir, temos a parte inicial do documento, onde é retornado o registro para o Pedido 10248:
<Orders OrderID=”10248" CustomerID=”VINET” EmployeeID=”5" OrderDate=”1996-07-04T00:00:00"
RequiredDate=”1996-08-01T00:00:00" ShippedDate=”1996-07-16T00:00:00" ShipVia=”3"
Freight=”32.38" ShipName=”Vins et alcools Chevalier” ShipAddress=”59 rue de l’Abbaye”
ShipCity=”Reims” ShipPostalCode=”51100" ShipCountry=”France” />
Também temos a cláusula FOR XML, a qual faz com que os dados sejam retornados no formato XML.
Podemos executar, praticamente, qualquer comando SELECT, com todas as suas cláusulas. Por exemplo,
o endereço a seguir retorna apenas os pedidos da tabela Orders, em que o país é Brazil:
http://servidor/NorthwindSQL?sql=SELECT * FROM Orders WHERE ShipCountry=‘Brazil’ FOR XML

AUTO&root=root
Alterando um pouco o endereço, podemos ordenar o resultado pela data do pedido, isto é, pelo campo
OrderDate
http://servidor/NorthwindSQL?sql=SELECT * FROM Orders WHERE ShipCountry=‘Brazil’ Order By

OrderDate FOR XML AUTO&root=root
Vejam que é apenas uma questão de utilizar o comando T-SQL correto.
Será que podemos utilizar uma cláusula Join? A melhor maneira de descobrir é tentando. Tente utilizar
o seguinte endereço:
http://servidor/NorthwindSQL?sql=SELECT Orders.OrderID, Orders.OrderDate, Orders.ShipCountry,

SUM(([Quantity]*[UnitPrice])*(1-[Discount])) As Total FROM Orders INNER JOIN [Order Details]
ON [Orders].[OrderID]=[Order Details].[OrderID]
GROUP BY Orders.OrderID, Orders.OrderDate, Orders.ShipCountry
HAVING (Orders.ShipCountry = ‘Brazil’) FOR XML AUTO&root=root
A sintaxe para o nosso comando está correta e irá rodar sem problemas no SQL Server 2005. Já no SQL
Server 2000, se você tentasse executar este comando, iria receber a seguinte mensagem de erro:
MSSQLError HResult=“0x80040e14” Source=“Microsoft OLE DB Provider for SQL Server”

Description=“GROUP BY and aggregate functions are currently not supported with FOR XML AUTO.”
A mensagem nos informa que a cláusula GROUP BY e funções de agregação (no nosso exemplo
utilizamos o SUM) não são suportadas com a cláusula FOR XML AUTO, do SQL Server 2000. Esta foi
uma das melhorias introduzidas pelo SQL Server 2005 em relação ao SQL Server 2000.
Para que este comando funcione no SQL Server 2000, você terá que alterá-lo. Vamos modificar um
pouco o comando; ao invés de agrupar e totalizar vamos, simplesmente, calcular o total de cada item
de cada pedido. Para isso, utilize o seguinte endereço:
http://servidor/NorthwindSQL?sql=SELECT Orders.OrderID, Orders.OrderDate, Orders.ShipCountry,

(([Quantity]*[UnitPrice])*(1-[Discount])) As Total FROM Orders INNER JOIN [Order Details]
ON [Orders].[OrderID]=[Order Details].[OrderID]
WHERE Orders.ShipCountry = ‘Brazil’ FOR XML AUTO&root=root
A seguir, temos a parte inicial dos resultados obtidos:
<Orders OrderID=“10250”OrderDate=“1996-07-08T00:00:00”ShipCountry=“Brazil”Total=“77” />

<Orders OrderID=“10250”OrderDate=“1996-07-08T00:00:00”ShipCountry=“Brazil”Total=“1261.4” />
<Orders OrderID=”10261"OrderDate=”1996-07-19T00:00:00"ShipCountry=”Brazil”Total=”288" />
<Orders OrderID=”10287"OrderDate=”1996-08-22T00:00:00"ShipCountry=”Brazil”Total=”472.60001" />
Você já deve ter observado que o navegador converte o endereço digitado para um formato diferente.
Por exemplo, os espaços em branco são substituídos por “%20”. Isto acontece porque existem alguns
caracteres especiais que não podem fazer parte de um endereço. Por isso, estes caracteres especiais são
substituídos pelos correspondentes permitidos.
Na Tabela 12.2, temos a descrição dos caracteres especiais e os correspondentes pelos quais são
substituídos.
Tabela 12.2 Caracteres especiais em endereços HTTP.
Este caracter É substituído por este (em hexadecimal)
Espaço em branco %20

/ %2F
? %3F
% %25
# %23
& %26
Agora que já vimos como acessar dados do servidor SQL Server 2005, através de um navegador, vamos
ver uma breve introdução sobre o padrão XML. O tópico XML é assunto para vários livros. O SQL
Server vem melhorando o suporte ao XML, desde o SQL Server 2000. Está fora do escopo deste livro
tratar sobre o uso do XML no SQL Server 2005. No tópico a seguir, eu farei apenas uma breve apresentação
do XML. No Books Online, você encontra grande quantidade de informações sobre o uso do XML no
SQL Server 2005. Pesquise no tópico: Database Engine -> Using XML in SQL Server. Além disso,
certamente, serão publicados livros inteiros sobre o uso do XML no SQL Server 2005.
UM POUCO SOBRE EXTENSIBLE MARKUP LANGUAGE – XML

Neste tópico vamos entender por que tanto “se fala” em XML e a que veio este, que alguns classificam
como linguagem e outros como um padrão. No endereço – http://www-106.ibm.com/developerworks/
education/xmlintro/xmlintro-1-1.html, eu encontro três definições que muito me agradam. A primeira
diz que XML é uma nova tecnologia para desenvolvimento de aplicações Web. Em seguida, o texto
afirma que XML é um “padrão”, que permite que o desenvolvedor crie suas próprias tags. E, por
último, temos que XML simplifica as transações business-to-business na Web. Na seqüência, vamos
procurar entender por que cada uma destas afirmações é verdadeira.
PRIMEIRO UM POUCO DE HISTÓRIA

Nos primeiros tempos da informatização nas empresas, tínhamos, basicamente, aplicativos baseados
em mainframe. O aplicativo e o Banco de Dados ficavam no mainframe, sendo que estes eram acessados
através dos famosos terminais verdes que, com o advento da arquitetura Cliente/Servidor, vieram a ser,
pejorativamente, chamados de “terminais burros”. O formato dos dados dependia do fornecedor do
mainframe que, na grande maioria dos casos, era a IBM. Um dos formatos mais conhecidos é o formato
de arquivos seqüenciais, que nada tem a ver com o formato dos Bancos de Dados Relacionais como o
utilizado pelo SQL Server 2005. Este era um ambiente centralizado e com maiores facilidades de
gerenciamento, segurança e controle.
No final da década de 80 e início dos anos 90, surgiu com toda a força a arquitetura Cliente/Servidor.
Junto com esta arquitetura, começaram a ser utilizados os chamados Bancos de Dados Relacionais.
Podemos citar como exemplos de Bancos de Dados Relacionais os seguintes produtos:
♦ Microsoft SQL Server.
♦ ORACLE.
♦ DB2 da IBM.
♦ Sybase.
♦ Ingress.
Neste momento, já começavam a surgir algumas dificuldades de convivência com diferentes formatos
de dados. Muitas empresas começavam a migrar sistemas de grande porte (mainframe) para a arquitetura
Cliente/Servidor, porém, durante um bom tempo, as duas arquiteturas precisavam conviver. Em muitas
empresas, a convivência entre sistemas em mainframe e sistemas em arquitetura Cliente/Servidor de
duas ou mais camadas perdura até hoje.
Mas o problema começa a se agravar, pois hoje, na rede da empresa, temos dados nos mais diferentes
formatos. São dados no formato de planilhas, de texto, de mensagens de e-mail, etc. Para piorar um pouco
mais, com o advento da Internet, as empresas passaram a trocar informações entre si, cada vez mais
intensamente. Como é possível trocar informações entre sistemas que utilizam diferentes formatos para os
dados? Uma série de soluções foi proposta de maneira que os sistemas possam acessar dados em diversos
formatos. A própria Microsoft apresentou soluções como ODBC e mais recentemente OLE DB.
Aqui, temos o primeiro ponto onde o XML pode ser de grande valor. O padrão XML pode vir a ser – e
eu até diria que está se tornando – o formato comum para troca de dados entre diferentes sistemas e
diferentes empresas. Neste ponto, começa a fazer sentido a afirmação colocada na introdução deste
tópico: XML simplifica as transações business-to-business na Web. Simplifica pelo fato de servir como
um formato padrão para os dados a serem trocados entre as diferentes empresas. Por exemplo, imagine
uma empresa que vende pela Internet. O sistema que suporta o site de comércio eletrônico é desenvolvido
no mainframe. Esta empresa precisa trocar dados com fornecedores e com empresas de cartão de
crédito, as quais, no nosso exemplo, utilizam sistemas mais modernos com formatos de dados diferentes
do existente no mainframe. Antes do XML, fazer esta comunicação seria um grande desafio, talvez até
inviável, devido aos custos de implementação. Com o XML, o site transforma os dados para o padrão
XML e os envia neste formato para os fornecedores e empresas de cartão de crédito. Estas empresas
recebem os dados no formato XML e convertem para o formato dos sistemas internos da empresa.
Vejam que, desta forma, o XML funciona como uma espécie de formato universal para troca de dados
entre diferentes sistemas. Trocar dados no formato .xml é muito mais simples e prático do que utilizar
uma série de gateways e drivers de conversão de dados entre diferentes formatos. Que seja bem vindo
o XML.
O que acontece, hoje, é que a maioria dos sistemas já tem a capacidade de exportar e importar dados
no formato XML. Porém, uma tendência que notamos é que os sistemas estão sendo adaptados para
trabalhar diretamente com dados XML. No momento em que escrevo este capítulo, a Microsoft anuncia
que a próxima versão do Office terá suporte a arquivos no formato XML. Já pensou que maravilha,
nada de arquivos proprietários no formato .doc ou .xls, apenas arquivos .xml?
Os documentos que definem o padrão XML podem ser encontrados nos seguintes endereços:
♦ http://www.w3.org/XML.
♦ http://www.xml.com/axml/axml.html.
Mas o padrão XML não é apenas um formato comum para troca de dados. Veremos o que mais XML é
no próximo item.
O QUE MAIS TEM A OFERECER ESTE TAL DE XML?

Em primeiro lugar, XML é uma linguagem que utiliza tags, semelhante ao HTML. Um dos principais
pontos a favor do XML é o fato de ser extensível (Extensible). Isto significa que não estamos limitados
a um conjunto fixo de tags. Podemos criar tags de acordo com a nossa necessidade. Podemos utilizar
XML para descrever a estrutura e a semântica de um conjunto de dados. Por exemplo, até hoje, não
existem tags HTML para tipos específicos de dados, como por exemplo equações matemáticas (símbolos
de integral, derivada, matriz, etc.), escalas musicais (sustenidos, claves de sol, etc.), fórmulas químicas,
etc. Com HTML, estamos limitados às tags que fazem parte da definição original da linguagem. Por
exemplo, para representar uma equação matemática, temos que utilizar uma figura, pois não existe
uma tag para o símbolo da integral ou da derivada. Com XML, podemos ir um muito mais adiante.
Não existe a tag que precisamos, então vamos criá-la. É neste ponto que o XML começa a se diferenciar
das demais linguagens. Podemos utilizar XML para definir tags associadas com um domínio específico.
Por exemplo, as operadoras de cartão de crédito podem se reunir e criar um conjunto específico de tags
para troca de informações no formato XML, em operações de comércio eletrônico na Web.
Um documento HTML contém informações sobre como o seu conteúdo deve ser exibido, e é facilmente
interpretado por um navegador que foi desenvolvido para entender HTML. Já seres humanos dificilmente
conseguem extrair alguma informação útil de um documento no formato HTML. Já um documento
no formato XML não contém qualquer informação sobre como os dados devem ser exibidos ou
formatados; ao invés disso, o documento XML contém os dados e informações sobre a estrutura dos
dados. Ao lermos um documento XML conseguimos extrair informações úteis do documento. A estrutura
dos dados está descrita no próprio documento XML. Tags de documentos XML são mais amistosas. Por
exemplo, considere o seguinte trecho do exemplo anterior:

Podemos identificar que temos informações sobre o campo OrderID da tabela Orders. Na seqüência,
também podemos identificar os campos OrderDate, ShipCountry e Total. Veja que as tags XML são
mais amistosas do que as tradicionais tags HTML, como por exemplo <TD>, <TR> <STRONG>, etc.
Você deve estar pensando que, em contrapartida, os dados no formato XML não são muito apresentáveis.
Para resolver esta situação, podemos associar uma folha de estilo a um documento XML. As folhas de
estilo fornecem um layout mais profissional a um documento XML. Podemos utilizar a tecnologia de
CSS (Cascading Style Sheets), para formatar os dados de um documento XML. Com isto, obtemos um
efeito interessante. Observe que estamos separando o conteúdo (que está no documento XML) da
apresentação (que está definida no arquivo .css). Com isso podemos, facilmente, apresentar os dados
de diferentes maneiras para diferentes usuários, simplesmente associando diferentes folhas de estilo.
Em resumo, XML é extensível, ou seja, podemos criar as tags que forem necessárias e pode ser utilizado
como um formato padrão para troca de informações, uma vez que um documento XML contém, além
dos dados, informações sobre a estrutura dos dados, o que facilita a leitura do documento, por qualquer
sistema que entenda o padrão XML.
Uma coisa é certa. o XML veio para ficar e cada vez mais soluções são baseadas neste padrão. Para se ter
uma idéia da força do XML, empresas como Microsoft, IBM, Sun, ORACLE e outras gigantes da indústria
de informática “abraçaram” este padrão e anunciam produtos com suporte a XML.
Com o SQL Server 2005 já temos suporte ao padrão XML, conforme vimos neste capítulo. Aprendemos
a retornar dados no formato XML, utilizando o navegador. XML é assunto para um livro inteiro. Quem
sabe um Curso Completo de XML. Com os links do início do capítulo, você pode ter uma boa idéia do
que é capaz o padrão XML.
CONCLUSÃO
Neste capítulo, tratamos de mais alguns assuntos relacionados com o desenvolvimento de aplicações
com base nos dados de um servidor SQL Server 2005.
Iniciamos o capítulo aprendendo diferentes maneiras de utilizar o Microsoft Access para interagir com
os dados do SQL Server 2005. Aprendemos a importar dados do SQL Server 2005 para tabelas do
Microsoft Access, utilizando fontes ODBC. Vimos que a vantagem deste método é que os dados estão
disponíveis localmente, e a grande desvantagem é que não existe uma sincronização dos dados. Quando
dados são alterados ou novos registros são inseridos no Banco de Dados do SQL Server 2005, estas
alterações não são sincronizadas com as tabelas importadas no Microsoft Access.
Outro método que aprendemos foi anexar tabelas do SQL Server 2005 utilizando fontes ODBC. Com a
anexação os dados continuam no servidor SQL Server 2005 e podem ser facilmente sincronizados. A
desvantagem é que posso perder o acesso aos dados se o servidor estiver fora do ar ou houver algum
problema de comunicação com a rede.
Depois, aprendemos a criar consultas baseadas, diretamente, em tabelas do SQL Server 2005. Para isso
configuramos uma string ODBC de conexão com o SQL Server 2005.
Em seguida, aprendemos a configurar um diretório virtual associado com um Banco de Dados de uma
instância do SQL Server 2005. Para isso empregamos o utilitário “Configure IIS Support”. Criamos um
diretório virtual chamado NorthwindSQL e depois testamos o acesso aos dados do SQL Server 2005,
utilizando o navegador. Vimos que os dados são retornados no formato XML.
Encerramos o capítulo falando um pouco sobre o que é o XML e quais as características do XML que o
tornam um padrão de grande aceitação para a criação de aplicações de comércio eletrônico e troca de
dados em geral.
No próximo capítulo você aprenderá sobre o .NET (ou Framework .NET, como é também conhecida
esta nova tecnologia/modelo de desenvolvimento de aplicações) e sobre a criação de páginas ASP.NET
que fazem conexão com dados do SQL Server 2005.
Capítulo 13
.NET E PÁGINAS ASP.NET
COM O SQL SERVER 2005
INTRODUÇÃO
Na área de desenvolvimento de aplicações, sem dúvida, a grande novidade do SQL Server 2005, em
relação às versões anteriores, foi a integração entre o SQL Server 2005 e o .NET. Com o SQL Server 2005
você pode criar funções de usuário, stored procedures e outras rotinas, facilmente, usando a sua
linguagem de programação preferida e depois utilizar estas rotinas no SQL Server 2005.
Este capítulo é dedicado a explicar o que é o Framework .NET, qual a sua proposta, como instalar o
Framework .NET e os demais componentes de suporte ao desenvolvimento de aplicativos no .NET.
Também mostrarei como criar páginas ASP.NET, as quais acessam dados de Bancos de Dados do SQL
Server 2005. No Capítulo 15 mostrarei como criar funções usando as linguagens do .NET e como
utilizar estas funções no SQL Server 2005.
Neste capítulo apresentarei, em detalhes, o.NET, o qual também chamarei de Framework .NET. Mostrarei
qual a proposta da Microsoft com mais esta iniciativa. Iniciarei o capítulo com uma visão geral, sobre
as propostas do Framework .NET. Em outras palavras: “A que veio e a que se propõe o .NET?”. Vou
mostrar quais os principais componentes e quais soluções pode nos oferecer o Framework .NET. Antes
de entrar nos detalhes sobre cada elemento e das funções de cada elemento é importante entendermos
como este novo modelo poderá ajudar no desenvolvimento de software e, em conseqüência, ajudar as
empresas a terem sistemas melhores, mais rápidos, mais econômicos, mais seguros e mais sintonizados
com as reais necessidades de cada empresa.
Uma vez devidamente apresentado o Framework .NET, falarei sobre os modelos atuais de
desenvolvimento e utilização de software. Mostrarei quais os problemas do modelo atual e quais as
soluções propostas pelo Framework .NET para estes problemas.
Um novo paradigma de desenvolvimento tem que mostrar que é capaz de resolver, se não todos, pelo
menos a grande maioria dos problemas dos modelos atualmente existentes. Já passou o tempo, se é
que um dia esta prática foi aceitável, de mudar de tecnologia somente para estar atualizado com o
mercado. Aprender novas técnicas e ferramentas envolve tempo, um longo aprendizado e,
principalmente, pesados investimentos financeiros. Para que uma empresa esteja disposta a fazer todos
estes investimentos, o Framework .NET terá que demonstrar que realmente é capaz de apresentar
soluções para os grandes problemas dos modelos atuais de desenvolvimento de software.
Em seguida passaremos a apresentar os principais elementos que compõem o Framework .NET:
♦ CLR – Common Language Runtime
♦ metadata
♦ Assemblies
♦ Linguagens habilitadas ao .NET
♦ Common Type System
♦ Interoperabilidade entre diferentes linguagens
♦ Web Services
♦ Os servidores .NET
♦ ADO.NET
CAPÍTULO 13 – .NET E PÁGINAS ASP.NET COM O SQL SERVER 2005
Apresentarei, de uma maneira genérica, o papel de cada um destes componentes no Framework .NET.
Apresentarei uma visão geral de cada um deles, para que o leitor possa ter uma boa idéia do Framework
.NET e de seus principais componentes, bem como da função de cada um.
Na segunda metade do capítulo vou apresentar mais alguns detalhes sobre o elemento principal, o
“motor” do Framework .NET: CLR – Common Language Runtime. O CLR é o componente principal do
Framework .NET.
Apresentarei mais alguns detalhes sobre a estrutura de uma aplicação .NET e a maneira como os diversos
elementos são “empacotados”, através do uso de assemblies. Vou apresentar informações detalhadas
sobre o uso de assemblies, os benefícios da utilização dos assemblies, questões de segurança, questões
sobre versão e utilização de um cache de assemblies para acelerar a execução dos programas .NET.
Falarei um pouco sobre as linguagens habilitadas ao .NET, a geração do códgio MSIL, a compilação
do código MSIL para código nativo – JIT Compile – e a execução deste código. Estes aspectos são
importantes para que o amigo leitor possa entender a maneira como as aplicações .NET são executadas
e gerenciadas pelo CLR.
Detalharei o conceito e a função dos assemblies. Mostrarei que estes formam os blocos básicos para a
construção de aplicações .NET. Também mostrarei quais os componentes de um assembly, com destaque
para a importância do “manifesto” contido em um assembly.
Na seqüência apresentarei mais detalhes sobre o CTS – Common Type System. Você verá quais os
principais benefícios de termos um sistema de tipos comum a todas as linguagens habilitadas ao .NET.
Também falarei sobre as diferenças entre “value types” e “reference types”.
Também apresentarei as principais classes e tipos da Biblioteca de Classes do Framework .NET (.NET
Framework Class Library). Veremos os tipos básicos, bem como as principais classes disponíveis para
utilização em programas criados com o Framework .NET.
Na seqüência do capítulo faremos uma revisão dos conceitos básicos de orientação a objetos. Uma vez
que o Framework .NET é fortemente baseado em conceitos de orientação a objetos, também a linguagem
C#, que é uma das novidades do Framework .NET, é baseada nos conceitos de orientação a objetos. Por
isso é bastante oportuno que revisemos os seguintes conceitos:
♦ O que é um objeto?
♦ Métodos e propriedades
♦ O que são classes?
♦ Herança
♦ Polimorfismo e funções virtuais
♦ Encapsulamento e visibilidade
Todo o Framework .NET foi criado com base nos conceitos de Orientação a Objetos. A linguagem C# é
totalmente orientada a objetos, onde tudo são classes. Claro que alguns “puristas” poderiam dizer que
o C# não é completamente orientado a objetos porque não suporta herança múltipla. Na verdade
veremos que o C# foi projetado para conciliar os benefícios da orientação a objetos e ao mesmo tempo
ser simples e prático. Para isso foram eliminadas algumas características da orientação a objetos,
características estas que mais causavam problemas do que propriamente forneciam soluções.
Uma vez que o Framework .NET tenha sido devidamente apresentado e explicado, mostrarei como
utilizar o ASP.NET, para criar páginas que acessam, editam e alteram dados em tabelas de um Banco de
Dados do SQL Server 2005. Você verá que o uso do ASP.NET é tão ou mais fácil do que o uso do ASP 3.0
(visto no Capítulo 11) e que o ASP.NET apresenta dezenas de novos recursos e facilidades. Seguindo a
metodologia utilizada nos demais capítulos, mostrarei, através de exemplos práticos, os principais
comandos do ASP.NET, para a conexão com Bancos de Dados do SQL Server 2005.
DESENVOLVIMENTO EM: O PRIMEIRO CONTATO

COM O FRAMEWORK .NET
PRÉ-REQUISITOS
♦ Conhecimento básico do Windows 2000 Server ou Windows Server 2003 e do SQL Server 2005.
METODOLOGIA
♦ Apresentação do Framework .NET.
Definir exatamente o que é o Framework .NET não é uma tarefa das mais simples. Como não sou
muito afeito a definições formais, vou mostrar qual a proposta do Framework .NET, quais os componentes
e qual a função de cada componente.
Em primeiro lugar podemos afirmar que, com a iniciativa .NET, a Microsoft está mudando radicalmente
o modelo de desenvolvimento e utilização de software. No livro “Introducint .NET”, da editora Wrox
(www.wrox.com), encontramos duas afirmações interessantes sobre o Framework .NET:
♦ É uma mudança tão grande ou até maior do que a mudança do DOS para o Windows;
♦ O Framework .NET foi todo projetado já tendo a Internet como objetivo, diferente de outras plataformas
que foram adaptadas para a Internet, à medida que a rede mundial crescia em importância.
APRESENTANDO O CONCEITO DE SERVIÇOS – WEB SERVICES

Realmente a mudança é bastante grande. Programadores, analistas e gerentes de projeto precisarão de
muito estudo e tempo para absorver os conceitos desta nova plataforma. Também é verdade que, desde
a sua concepção, o .NET foi projetado para a Internet. Em muitas publicações especializadas aparece a
seguinte afirmação: “A iniciativa .NET é a visão da Microsoft de um mundo, onde o software se transforma
em serviços, na verdade pequenos componentes que podem ser utilizados por qualquer aplicação.”
Por exemplo, um software de uma empresa brasileira pode utilizar um serviço que está residente em um
servidor de uma empresa do Japão, desde que tenha permissões para isso. Este serviço pode oferecer, por
exemplo, a funcionalidade para validação de uma transação via cartão de crédito. Um dispositivo móvel,
como um celular WAP ou um Handled, pode utilizar um serviço de cotação de ações de um servidor da
bolsa de valores de Londres. E como todos estes componentes fazem para se comunicar? Evidentemente
que através da Internet. Por isso a Internet é vista como ponto principal do projeto .NET.
Conforme veremos mais adiante, estes serviços, que podem ser acessados via Internet ou através de
qualquer intranet, são chamados de “Web Services”.
Ao invés de programas monolíticos, em que toda a funcionalidade necessária está contida no código
do próprio programa, construiremos programas como se fosse um jogo de montar. As diversas
funcionalidades necessárias ao programa podem ser oferecidas através do acesso a serviços já
implementados. Na Figura 13.1 temos uma pequena ilustração deste conceito.
Oferece um Web Service

para validação do número
de cartão de crédito.
www.validacao.com
INTERNET
www.minhaempresa.com
Oferece um Web Service
com cotações atualizadas
Criamos uma página ASP.NET que utili-
de diversas moedas.
za o serviço de validação de número
de cartão de crédito que está no servi-
dor www.validacao.com e também utili-
za o serviço que fornece cotações
atualizadas de diversas moedas e que www.cotacoes.com
está no servidor www.cotacoes.com.
Figura 13.1 Um programa que utiliza diversos serviços.
No site da empresa www.minhaempresa.com, criamos, por exemplo, uma página ASP.NET para venda de
livros. O preço dos livros está em dólares e deve ser convertido, para a moeda do país do cliente, no
momento da compra. No exemplo da Figura 13.1, a página ASP.NET utiliza um Web Service do servidor
www.cotacoes.com, para obter a cotação atualizada do dólar em relação à moeda do país do cliente. A
página ASP.NET recebe esta informação, faz os cálculos necessários e exibe para o cliente. O próximo passo
é efetivar a venda. Agora o cliente digita o número do seu cartão de crédito. Para validar o número do cartão
de crédito do cliente, é acessado um outro Web Service, o qual está instalado no servidor www.validacao.com.
Com esta arquitetura, a criação de software fica bastante simplificada, uma vez que podemos agregar
ao nosso programa funcionalidades disponibilizadas através de Web Services que estão instalados em
qualquer servidor da Internet. Desta maneira somente precisamos criar o código que é específico do
nosso programa. Isto é reaproveitamento de código ou como preferem os puristas: reutilizando código,
um dos pilares da Programação Orientada a Objetos.
Como diferentes Web Services, criados por diferentes empresas, poderão se comunicar e trocar
informações? Esta comunicação é possível, porque todo programa criado para a plataforma .NET utiliza
um padrão para troca de informações. No caso temos dois padrões:
♦ Para o formato dos dados, o Framework .NET utiliza XML: Extensible Markup Language.
Conforme veremos mais adiante, o XML vem ganhando força como um padrão para troca de
informações na Internet, principalmente para troca de informações entre empresas em sites de
comércio eletrônico. No Capítulo 12 você encontra uma breve introdução ao XML. Você também
encontra livros inteiros só sobre o uso do XML no SQL Server 2005.
♦ Como protocolo de transporte, o Framework .NET utiliza o SOAP: Single Object Access
Protocol. Com SOAP podemos fazer com que toda a comunicação entre diferentes Web Ser-
vices e demais componentes de um programa seja feita através do protocolo padrão da Internet
que é o HTTP. O SOAP não é um protocolo criado pela Microsoft para ser utilizado pelo .NET.
O SOAP é um padrão da indústria, sendo utilizado por produtos de diversas empresas, tais
como IBM, Sun e ORACLE.
Pode parecer que não existe nada de novo nesta abordagem, pois tecnologias para criar programas a
partir de componentes prontos já existem há um bom tempo: COM+, CORBA, etc. Porém a grande
vantagem dos Web Services, no Framework .NET, é que estes podem ser acessados, facilmente, através
da utilização de um protocolo padrão: SOAP, e trocando informações em um formato padrão: XML.
Esta abordagem torna a criação e utilização dos Web Services uma tarefa muito mais simples do que,
por exemplo, a criação de componentes COM+ ou CORBA, os quais utilizam formatos de dados e
protocolos de comunicação proprietários e de difícil implementação.
APRESENTANDO O CLR – COMMON LANGUAGE RUNTIME

O CLR é um ambiente de execução, poderíamos até dizer que é o “Coração do .NET”, o qual dá suporte
a todas as linguagens de programação habilitadas para o .NET. Ao instalarmos o Microsoft .NET Frame-
work SDK, temos disponíveis as seguintes linguagens:
♦ VB.NET (Visual Basic .NET)
♦ C# (leia-se C Sharp)
♦ ASP.NET
♦ Jscript.NET
O Runtime (ambiente de execução) é o ambiente que dá suporte à execução das aplicações .NET.
Quando um programa .NET é executado, todo o controle do programa é feito através do CLR.
Para aplicações anteriores, desenvolvidas utilizando a tecnologia COM/COM+, o programador era

responsável por inserir no código do programa uma série de funções necessárias ao correto
funcionamento do programa, como por exemplo o gerenciamento de memória, criação e destruição
de objetos e assim por diante. A codificação destas funções não era uma tarefa fácil, o que exigia muito
tempo do programador, além de conhecimentos avançados. Com aplicações .NET, todas estas funções
são executadas pelo CLR, ou seja, o programador não precisa preocupar-se com a codificação destas
funções. Desta forma somente precisamos nos preocupar com a funcionalidade do nosso programa, o
que poupa tempo e agiliza o processo de desenvolvimento.
As aplicações criadas em uma das linguagens habilitadas para o .NET (como VB.NET, C# ou ASP.NET),
ao serem compiladas, geram um código intermediário conhecido como MSIL – Microsoft Intermediate
Language, o qual é abreviado simplesmente como IL – Intermediate Language. Este código é que é
executado pelo CRL. Vamos analisar o diagrama apresentado na Figura 13.2:
ASP.NET VB.NET C#
COMPILA
MSIL
CLR
COMMON LANGUAGE RUNTIME
Figura 13.2 O ambiente de execução do CLR.
A partir da Figura 13.2 temos algumas observações importantes para apresentar:
♦ Para que uma linguagem seja habilitada ao .NET, o seu compilador deve ser capaz de gerar
código MSIL.
♦ O código MSIL gerado é executado pelo CRL.
A própria Microsoft não nega que a idéia é bastante semelhante ao ambiente de execução para aplicações
desenvolvidas em Java, onde temos um ambiente de execução comum – a Máquina Virtual Java, a qual
executa byte code, que é o código gerado pelas aplicações Java.
Todas as linguagens habilitadas ao .NET têm a sua disposição um rico conjunto de classes e objetos, os
quais fornecem desde conexão com Banco de Dados até funções mais específicas, como funções gráficas,
funções de gravação em disco e assim por diante. Este conjunto de classes e objetos é conhecido como
“.NET Framework class library”.
Todo código habilitado a rodar no CLR, ou seja, que pode ser compilado para MSIL é conhecido como
“managed code” ou código gerenciado. Código antigo, como por exemplo COM ou COM+, os quais
não estão habilitados para rodar sob controle do CLR, são chamados de “unmanaged code” ou código
não gerenciado. Veremos mais aspectos a respeito destas definições mais adiante neste capítulo, onde
trataremos sobre o CLR em mais detalhes.
.NET FRAMEWORK CLASS LIBRARY

Este é o segundo elemento fundamental do Framework .NET. A .NET Framework class library (biblioteca
de classes do Framework .NET), como o próprio nome sugere, é uma coleção (uma gigantesca coleção)
de classes ou tipos completamente integrada com o ambiente de execução – CLR. Quando falamos em
um conjunto de classes, estamos utilizando o conceito originado no modelo de Programação Orientado
a Objetos. O Framework .NET é fortemente baseado nos conceitos de orientação a objetos,
principalmente nos conceitos de Classes, Herança e Polimorfismo.
Os programas criados em qualquer linguagem habilitada ao .NET podem utilizar este conjunto de
tipos e classes. Por exemplo, existe uma classe chamada System.Data, a qual oferece uma série de
objetos e métodos para acesso às mais variadas fontes de dados. Vamos a um exemplo mais específico:
Existe uma classe chamada System.SqlCliente, a qual fornece uma série de métodos para acesso nativo
aos dados de um servidor Microsoft SQL Server. Podemos utilizar a classe System.SqlCliente em um
programa feito em VB.NET, C#, ou em uma página ASP.NET ou qualquer linguagem que venha a ser
habilitada para o .NET.
Ao fornecer um conjunto de classes e tipos, o Framework .NET está facilitando a vida do programador,
uma vez que grande parte da funcionalidade necessária é fornecida diretamente pelas classes do Frame-
work .NET e, o principal, é utilizada de uma maneira padronizada (mesmos parâmetros para cada
chamada de classe, mesmo tipo de parâmetro e assim por diante) pois a maneira de utilizar uma classe
da biblioteca de classes do .NET é a mesma, independente da linguagem que estamos utilizando
(evidentemente, desde que seja uma linguagem habilitada ao .NET).
NOTA
Já existem diversos fabricantes trabalhando para habilitar suas linguagens de desenvolvimento para o Framework .NET. O Delphi, que é um
dos maiores concorrentes do Visual Basic, já está habilitado ao .NET.
São muitas as funções disponibilizadas pela biblioteca de classes do .NET. Apenas a título de exemplo,
vamos citar algumas funções disponibilizadas:
♦ Manipulação de string
♦ Conectividade com Banco de Dados
♦ Acesso a arquivos
♦ Configurações de segurança
♦ Manipulação de dados
Na Figura 13.3, apresento uma visão geral dos principais elementos que formam o Framework .NET.
ASP.NET VB.NET C# XYZ ...
.NET Framework Class Library
System.Data Microsoft.CSharp System.Io
System.Net System.Security ...
CLR
Figura 13.3 Principais elementos do Framework .NET.
DESENVOLVIMENTO EM: UM PEQUENO PARÊNTESES

PARA “FALAR MAL” DOS MODELOS ANTERIORES
PRÉ-REQUISITOS
♦ Conhecimento básico do Framework .NET.
METODOLOGIA
♦ Comparação com modelos anteriores de desenvolvimento de aplicações.
Vamos falar um pouco sobre o modelo de desenvolvimento anterior ao .NET, mais especificamente
sobre o modelo baseado em COM/COM+ da Microsoft. Para falar sobre este assunto vamos fazer um
histórico sobre o desenvolvimento de aplicações, desde os bons e velhos tempos do MS-DOS.
AI QUE SAUDADE DO MS-DOS!

Não, não é saudade da época do MS-DOS, apenas uma breve recapitulação. Para desenvolver aplicações
para o ambiente MS-DOS, utilizamos diversas linguagens de programação, tais como:
♦ Clipper
♦ Pascal – Turbo Pascal
♦ Basic
♦ C – Turbo C
♦ C++
Um programa para o ambiente MS-DOS, na grande maioria das vezes, era composto por um arquivo
executável (.exe). Os demais arquivos necessários ao funcionamento do programa, tais como imagens
gráficas ou arquivos de dados, eram salvos, normalmente, no mesmo diretório (na época do MS-DOS
não falávamos em pastas) do arquivo executável e tudo funcionava perfeitamente bem (ou tão bem
quanto possível para a época).
Para instalar o programa em outro computador, bastava copiar o diretório do programa e pronto, nada
mais precisava ser feito – nada de entradas na Registry, nada de DLLs e outros problemas que tanto nos
atormentam. Podemos ver que o processo de instalação era bastante simplificado, mas em contrapartida
o desenvolvimento era todo manual e as funcionalidades bastante limitadas. As redes locais ainda não
eram realidade e a grande maioria dos programas era feito para trabalhar em um único computador,
acessando dados locais.
Comunicação entre programas, reaproveitamento de código e acesso via rede, eram coisas raras ou
inexistentes. Para as necessidades da época, era um modelo plenamente satisfatório. A maior prova
disso é que, ainda hoje, facilmente encontramos programas feitos em Clipper, para o ambiente MS-
DOS, rodando em pequenos estabelecimentos, dando suporte a todas as operações diárias. Tente você
propor que estas pessoas substituam seus programas em Clipper, que atendem perfeitamente às
necessidades destes pequenos estabelecimentos, por programas para Windows com interface gráfica.
Com certeza você receberá um sonoro “NÃO”.
Porém logo as redes começariam a invadir as empresas, os programas a tornarem-se mais complexos.
Com o advento das redes e do sucesso dos PCs, mais e mais pessoas começaram a utilizar computadores.
A velha interface a caractere do MS-DOS não atendia mais as necessidades. Neste momento é que o
Windows começa a surgir no mercado.
PRAZER. EU SOU O WINDOWS!

Com a chegada doWindows tivemos a popularização das interfaces gráficas e de termos como: mouse,
ícone, atalho e janelas. As ferramentas para desenvolvimento no ambiente Windows custaram a chegar.
No início a programação tinha que ser feita em linguagem C, utilizando as APIs (Application Program
Interface) do Windows.
Com o lançamento do Visual Basic 1.0 teve início a era das ferramentas gráficas para desenvolvimento
de programas para o ambiente Windows.
Com o Windows já passou a existir o conceito de instalar o programa. A instalação do programa não se
limita a uma simples cópia de arquivos. Ao instalar um programa no Windows, o programa gravava
uma série de informações de configuração: no Windows 3.x em arquivos .ini e no Windows 9x na
Registry do sistema operacional. Além destas informações de configuração, partes do programa eram
disponibilizadas no formato de arquivos .DLL (Dynamic Link Library). Falando assim parecia um modelo,
digamos, bastante elegante. Um local centralizado para informações sobre configuração e o programa
dividido em partes menores, que no conjunto forneciam a funcionalidade do programa.
Porém o modelo de programação para o Windows começou a apresentar uma série de inconvenientes.
Vamos falar destes inconvenientes, através de exemplos:
♦ Se alguma das configurações, necessárias ao funcionamento do programa, fossem alteradas, o
programa deixava de funcionar. Isto gerava uma chamada ao pessoal de suporte que, na maioria
das vezes, somente conseguia resolver a situação reinstalando o programa.
♦ Os arquivos .DLL poderiam ser utilizados por mais do que um programa. Pode acontecer uma
situação em que um programa que esteja sendo instalado substitua uma determinada .DLL por
uma versão mais nova do que a versão da .DLL atualmente existente no sistema. O problema é
que podem existir programas que dependam da versão mais antiga. Nesta situação os programas
que dependem da situação mais antiga simplesmente deixarão de funcionar. Pode também
acontecer o contrário, ou seja, um programa que está sendo instalado substitui uma .DLL por
uma versão mais antiga, fazendo com que outros programas deixem de funcionar. Em situações
mais críticas poderia acontecer de o programa que está sendo instalado substituir uma .DLL
vital para o Windows. Nestas situações todo o sistema deixaria de funcionar e, em alguns
casos, somente uma reinstalação poderia resolver o problema.
Vejam que o que parecia uma boa solução acabou se mostrando um verdadeiro pesadelo para gerenciar
e manter em funcionamento. Neste époco surge, inclusive, a expressão “DLL Hell”, que poderíamos
traduzir por: “O Inferno das DLLs.”
♦ Cada vez que um programa fosse alterado, o programa precisaria ser reinstalado em todos os
computadores onde fosse necessária a nova versão. E se, ao fazer a atualização para a nova versão,
fosse substituída alguma .DLL necessária ao funcionamento de algum outro programa? Novos
problemas para o pessoal do suporte técnico. Vejam que este modelo gera uma grande carga de
suporte, o que encarece muito a manutenção em funcionamento de uma estação de trabalho da
empresa. Para mais detalhes sobre esta questão, consulte o Capítulo 2, onde falo sobre os modelos
de aplicação Cliente/Servidor e a solução para esta questão, usando o modelo em n Camadas.
REDES E INTERNET – MAIS PROBLEMAS (OU SOLUÇÕES) À VISTA!

Com o advento das redes como uma realidade nas empresas e com a explosão da Internet como
uma plataforma viável para fazer negócios, os modelos de desenvolvimento de aplicações sofreram
profundas mudanças.
Primeiro, com as redes, foi a época da “febre” em descentralizar as estruturas de TI e migrar para o
modelo Cliente/Servidor, baseado em redes locais. Neste modelo, também conhecido como modelo de
duas camadas, temos um ou mais equipamentos de maior capacidade de processamento, atuando
como servidores. Nas estações de trabalho dos usuários, conhecidas como clientes, são instalados
programas, que fazem acesso a recursos residentes nos servidores. O exemplo mais típico de aplicação
Cliente/Servidor seria uma aplicação desenvolvida em Visual Basic ou Delphi, a qual acessa dados de
um servidor SQL Server, instalado em um servidor da rede. Na Figura 13.4, temos uma visão geral do
modelo Cliente/Servidor.
NOTA
Para uma descrição detalhada do modelo de duas camadas e de seus problemas, consulte o Capítulo 2.
Servidor de Arquivos Banco de Dados Outros Servidores
Cliente Cliente Cliente Cliente Cliente
Figura 13.4 O modelo Cliente/Servidor.
Sempre que um determinado modelo apresenta problemas, aparentemente intransponíveis, a indústria

de informática parte para a criação de novos modelos. Em busca de soluções para os problemas do
modelo de duas camadas é que surgiu a proposta do modelo de 3 camadas, conforme analisaremos,
brevemente, a seguir. Para uma descrição detalhada sobre o modelo de desenvolvimento em 3 camadas,
APLICAÇÕES EM 3 CAMADAS.
Como uma evolução do modelo de 2 camadas, surge o modelo de três camadas. A idéia básica do modelo
de 3 camadas é retirar as regras do negócio, da aplicação Cliente e centralizá-las em um determinado ponto,
o qual é chamado de Servidor de Aplicações. O acesso ao Banco de Dados é feito através das regras contidas
no Servidor de Aplicações. Ao centralizar as regras do negócio em um único ponto, fica muito mais fácil a
atualização das mesmas. A Figura 13.5 nos dá uma visão geral do modelo em 3 camadas:
Servidor de Aplicações Servidor de Banco de Dados
No modelo de 3 camadas, toda a “Lógica do

negócio” fica no Servidor de Aplicações. Com
isso, a atualização das regras do negócio fica
mais fácil.
Figura 13.5 O Modelo de desenvolvimento em três camadas.
NOTA
Para uma descrição detalhada do modelo em três camadas, consulte o Capítulo 2.
Com a introdução da camada de Lógica, resolvemos o problema de termos que atualizar a aplicação,
em centenas ou milhares de estações de trabalho da rede da empresa, toda vez que uma regra do
negócio for alterada. Porém continuamos com o problema de atualização da interface da aplicação,
cada vez que forem necessárias mudanças na interface. Por isso que surgiram os modelos de n-camadas.
No próximo tópico, iremos falar, brevemente, sobre o modelo de 4 ou mais camadas

Como uma evolução do modelo de três camadas, surge o modelo de quatro camadas. A idéia básica do
modelo de 4 camadas é retirar a apresentação do cliente e centralizá-las em um determinado ponto, o
qual na maioria dos casos é um servidor Web. Com isso o próprio cliente deixa de existir como um
programa que precisa ser instalado em cada computador da rede da empresa. O acesso à aplicação, é
feito através de um navegador, como por exemplo o Internet Explorer, Firefox ou o Netscape Naviga-
tor. A Figura 13.6 nos dá uma visão geral do modelo em quatro camadas:
Servidor Web Servidor de Aplicações Servidor de Banco de Dados
O cliente só precisa de um navegador para ter acesso à aplicação.
Para acessar a aplicação, o cliente acessa o endereço da aplicação, utilizando o seu navegador, como no
exemplo a seguir:
http://intranet.minhaempresa.com/sistemas/vendas.aspx.
Todo o acesso do cliente ao Banco de dados é feito de acordo com as regras contidas no servidor de
aplicações. O cliente não tem acesso ao Banco de dados, sem antes passar pelo servidor de aplicações.
NOTA
Para uma descrição detalhada do modelo em quatro camadas, consulte o Capítulo 2.
UM MODELO BASEADO EM COMPONENTES

O modelo de programação anterior ao .NET, para o ambiente Windows, é fortemente baseado no
conceito de componentes. No exemplo do modelo em 4 camadas, quando uma aplicação cliente acessa
uma regra de negócio, esta regra de negócio é implementada na forma de um componente COM/
COM+. o regra de negócio pode utilizar um outro componente para fazer a conexão com o Banco de
Dados e retornar os dados solicitados pela aplicação. Para que os diversos componentes possam
comunicar-se e trocar informações, eles precisam de um padrão para a troca de mensagens. O padrão
determina a estrutura interna do componente e a maneira como cada componente expõe suas
funcionalidades. O padrão para o ambiente Windows é chamado, a partir do Windows 2000, de
COM+. Para o Windows NT 4.0 e versões anteriores, tínhamos o COM/DCOM trabalhando em conjunto
com o MTS – Microsoft Transaction Server.
Mas se existe um padrão para troca de mensagens qual é o problema? Acontece que a implementação de
componentes utilizando COM/COM+ nunca foi tarefa fácil. Se utilizarmos linguagens como o Visual C++,
a criação e disponibilização de componentes é uma tarefa que exige programadores altamente especializados.
Já com ferramentas como o Visual Basic e Delphi, a criação de componentes para o padrão COM+ é um
pouco mais fácil. Porém a grande dificuldade é fazer com que componentes implementados em diferentes
linguagens sejam capazes de trabalhar em conjunto e trocar mensagens entre si.
Agora imagine as dificuldades em um ambiente onde devemos criar aplicações para a Internet e deve
existir uma maneira padronizada para que os diversos componentes sejam capazes de se comunicar. A
Microsoft, com a sua iniciativa DNA, procurou disponibilizar informações para que seja possível tirar
o máximo do modelo COM+, na criação de aplicações em n-camadas para a Internet. Porém a própria
Microsoft reconheceu as limitações e dificuldades deste modelo, ao propor uma nova revolução nos
métodos e práticas de desenvolvimento, revolução essa que atende pelo singelo nome de .NET (ou
Framework .NET, como venho também utilizando neste livro).
Outro fator importante a considerar é que o padrão COM/COM+ é um padrão proprietário, desenvolvido
pela Microsoft. Como fazer com que um padrão proprietário possa ser utilizado, sem maiores problemas
para aplicações distribuídas na Internet? Fica muito difícil, para não dizer impraticável. Já com o .NET,
conforme comentamos anteriormente, utiliza-se padrões não proprietários, como XML para os dados
e SOAP sobre HTTP como protocolo de transporte. Desta forma a comunicação entre Web Services
acontece de uma maneira fácil, sem maiores problemas.
Para que um componente COM/COM+ possa ser utilizado, este precisa ser registrado no servidor que
irá disponibilizar o componente. Ao registrar o componente, são gravadas informações sobre o
componente, na registry do sistema operacional. O programador precisa preocupar-se em garantir que
o componente seja registrado corretamente, pois, caso contrário, este não poderá ser acessado. Já os
serviços do .NET não necessitam de registro, sendo que toda a informação necessária para que estes
funcionem corretamente está contida no próprio serviço, no formato de metadados – metadata. Mais
adiante falaremos um pouco mais sobre metadata.
Com componentes COM/COM+, o programador precisa preocupar-se em carregar o componente na memória,
retirar o componente da memória quando este não for mais utilizado e uma série de outras funções necessárias
ao correto funcionamento de cada componente. Com o .NET, todas estas “preocupações” foram transferidas
para o Framework .NET. Isto faz com que o programador somente tenha que codificar a funcionalidade do
serviço que está sendo desenvolvido, a parte mais, digamos assim, “chata” será de responsabilidade do Frame-
work .NET, mais especificamente do CLR. Isso aumenta a produtividade do programador e evita erros mais
graves, os quais normalmente fazem com que o componente não funcione corretamente.
Já apresentamos os principais problemas do modelo atual e, no restante deste capítulo, veremos os

demais elementos que compõem o Framework .NET e como cada um destes elementos procura
solucionar problemas que os modelos anteriores não foram capazes de resolver. Também mostrarei
como utilizar páginas ASP.NET, para conectar com Bancos de Dados do SQL Server 2005.
DESENVOLVIMENTO EM: OS ELEMENTOS DO FRAMEWORK

.NET EM DETALHES
PRÉ-REQUISITOS
♦ Conhecimento básico do Windows 2000 ou 2003 e do Framework .NET.
METODOLOGIA
♦ Descrição dos elementos que compõem o Framework .NET.
Agora vamos falar um pouco mais sobre os diversos componentes do Framework .NET e como cada um
destes componentes/funcionalidades se propõe a solucionar problemas do modelo de desenvolvimento
baseado em componentes COM/COM+.
LINGUAGENS DE PROGRAMAÇÃO HABILITADAS AO .NET

O que significa uma linguagem ser “habilitada ao .NET?”
Significa que a linguagem é capaz de gerar, como resultado da compilação, código MSIL. Uma vez
gerado o código MSIL, este é executado sob o controle do CLR. Ou seja, para o Framework .NET, uma
vez gerado o código MSIL, não importa a partir de qual linguagem o código foi gerado, pois a maneira
como o código MSIL é executado é sempre a mesma.
Juntamente com o Framework .NET, a Microsoft disponibiliza as seguintes linguagens:
♦ Visual Basic .NET (VB.NET)
♦ C++.NET
♦ C#
NOTA
No endereço a seguir, você encontra uma listagem atualizada de todas as linguagens que já estão habilitadas ao .NET: http://
www.jasonbock.net/dotnetlanguages.html
Podemos criar nossos programas em qualquer uma destas linguagens. Ao compilarmos o programa, o
resultado será a geração de código MSIL, o qual passa a ser executado pelo CLR. Quando a Inprise
lançou o Delphi habilitado ao .NET, o que foi feito é fazer com que o Compilador Delphi seja capaz de
gerar código MSIL. Uma vez gerado o código MSIL, para o CLR não importa em qual linguagem o
programa foi codificado.
UMA RÁPIDA APRESENTAÇÃO DO VB.NET.

Com exceção do C#, que é uma nova linguagem, o VB.NET é a linguagem que mais sofreu modificações
em relação às versões anteriores (VB 6.0). Foram introduzidas algumas características a muito tempo
esperadas, tais como:
♦ Foram adicionadas mais características de orientação a objetos, tais como herança verdadeira,
construtores parametrizados e overriding de métodos e propriedades.
♦ Mais facilidades para o desenvolvimento de aplicações Internet. Por exemplo, para criar páginas
ASP.NET, ao invés de VBScript, utilizado com ASP, utilizamos diretamente o VB.NET ou o C# e
a criação de páginas Web com o Visual Studio .NET ficou bem mais simples do que usando o
Visual InterDev, que era a ferramenta para programação Web antes da disponibilidade do Vi-
sual Studio .NET.
♦ Herança visual: Esta é uma características que os desenvolvedores do Delphi já tinham a algum
tempo. Com o VB.NET podemos criar um formulário com as características básicas para todos
os formulários da aplicação. Quando precisarmos de um formulário com características
adicionais, podemos construir este novo formulário baseado, isto é, herdando as características
do formulário básico, e depois é só adicionar os elementos necessários. Ao criarmos o nosso
formulário, herdando do formulário básico, o formulário que está sendo criado terá,
automaticamente, todos os elementos do formulário básico. Além dos elementos, o código
para tratamento de eventos também é herdado. O melhor de tudo, ao alterarmos o formulário
básico, todas as alterações são refletidas nos formulários herdados. A herança visual facilita,
enormemente, a criação de aplicações que tenham uma interface consistente, padronizada e
de fácil manutenção.
♦ Tratamento estruturado de exceções: com o VB.NET, temos muito mais recursos para o
tratamento de erros e exceções do que o bom e velho On Error do Visual Basic. Isso faz com que
possamos criar programas mais confiáveis.
Falar sobre as novidades do VB.NET é assunto para um capítulo inteiro. Ensinar o VB.NET: assunto
para um livro inteiro.
UM RÁPIDA APRESENTAÇÃO DO C#
O C# é a nova linguagem da Microsoft, apresentada juntamente com o Framework .NET. O C# foi
construído com base nos conceitos de orientação a objetos. As diretivas básicas para a criação do C#
foram as seguintes:
♦ Uma linguagem orientada a objetos e tão poderosa quanto o C++
♦ Uma linguagem tão fácil de utilizar quanto o VB
O pessoal da Microsoft realmente conseguiu aliar estas duas características em uma só linguagem:
Poder e Simplicidade. Conforme você pode conferir nos capítulos 3, 4 e 5, do seguinte e-book de
minha autoria: ASP.NET: Uma Nova Revolução na Criação de Sites e Aplicações Web (mais detalhes em
http://www.juliobattisti.com.br/ebooksdoautor), o C# é de fácil aprendizagem e utilização, ao mesmo
tempo que nos fornece poderosos mecanismos, antes só encontrados no C++.
Como não poderia deixar de ser, vamos dar o tradicional exemplo do Hello Word!!!, utilizando o C#.
Apresentarei o código e os passos para compilar e rodar o nosso primeiro programa em C#. Para criar o
nosso primeiro programa, utilizaremos o Bloco de Notas do Windows.
NOTA
Esse programa só poderá ser executado se você já tiver o Framework .NET instalado em seu computador. Por padrão, ao instalar o SQL
Server 2005, o Framework .NET é também instalado.
Abra o Bloco de notas e digite o texto indicado na Listagem 1.1.
Listagem 13.1 – Hello Word !

using System;
class primeiroprograma
{
// Meu primeiro programa em C#
// O tradicional Hello Word!!
public static void Main()
{
string umamensagem = “Hello Word!!!”;
Console.WriteLine(umamensagem);
}
}
Salve este programa em uma pasta no HD com o nome de primeiroprograma.cs. Agora vamos compilar
o programa e executá-lo.
Para compilar o programa, abra um prompt de comando. Na janela do prompt vá para a pasta onde
você salvou o arquivo primeiroprograma.cs e execute o seguinte comando:
csc primeiroprograma.cs
Se der um erro, informando que não foi possível localizar o comando csc, use o recurso Iniciar -> Pesquisar -> Arquivos ou pastas, para
NOTA
localizar a pasta onde está o compilador do C#, que é o arquivo csc.exe. Uma vez localizado o compilador do C#, salve o arquivo
primeiroprograma.cs na mesma pasta do compilador, abra um prompt de comando, navegue até a pasta onde está o arquivo csc.exe e
execute novamente o comando: csc primeiroprograma.cs
Com este comando compilamos o arquivo fonte primeiroprograma.cs, para gerar um executável .exe.
O resultado deste comando é indicado na Figura 13.7, onde utilizamos o comando dir, para mostrar
que a compilação gerou o executável primeiroprograma.exe.
Figura 13.7 Compilando o primeiro programa em C#.
Para executar o nosso programa, basta digitar primeiroprograma e pressinar Enter. O programa será
executado, conforme indicado na Figura 13.8:
Figura 13.8 Executando o primeiro programa em C#.

NOTA
Apenas um último detalhe ao qual gostaria de chamar a atenção: Observe, para aqueles que conhecem Java ou C++, a semelhança entre a
estrutura de um programa em C# e um programa em uma destas linguagens.
COMMON TYPE SYSTEM

O Framework .NET disponibiliza, na forma de objetos, um conjunto de tipos de dados comuns, os
quais podem ser utilizados por todas as linguagens habilitadas ao .NET. Isso significa, por exemplo,
que uma variável do tipo Long terá a mesma estrutura e ocupará o mesmo número de bytes, quer seja
no VB.NET, no C#, no C++ ou em qualquer outra linguagem habilitada ao .NET. Este conjunto de tipos
comuns, que pode ser utilizado por qualquer linguagem habilitada ao .NET, é chamado de Common
Type System, que a partir de agora abreviaremos por CTS.
Dentre outras coisas, é o CTS que facilita a integração entre os programas e serviços criados, utilizando-
se diferentes linguagens habilitadas ao .NET. No modelo antigo, uma das dificuldades de fazer com
que um componente COM+ criado com o Visual C++ pudesse ser utilizado por um programa escrito
em Visual Basic é que as linguagens possuíam um conjunto diferente de tipos básicos. Para que os
componentes, escritos em diferentes linguagens, pudessem se comunicar, o programador tinha que
mapear os tipos de uma linguagem, para os tipos correspondentes em outra linguagem, fazendo as
conversões necessárias. Vejam o quanto este procedimento é trabalhoso. Com o CTS do .NET
simplesmente esta preocupação deixa de existir, uma vez que todas as linguagens têm acesso a um
conjunto de tipos comum e padronizado.
Conforme descrito na documentação do Framework .NET, são as seguintes as principais funções do CTS:
♦ Fornece uma estrutura que possibilita a integração entre diferentes linguagens habilitadas ao
.NET, com uma execução mais rápida, uma vez que a sobrecarga para a conversão entre os
diferentes tipos de diferentes linguagens deixa de existir.
♦ Fornece uma estrutura de tipos com base em um modelo orientado a objetos, o que facilita a
criação de novas linguagens habilitadas ao .NET, favorecendo a utilização de boas práticas de
programação, como por exemplo a herança. Uma vez que os tipos são objetos, podemos criar
tipos derivados (herdados) dos objetos básicos, os quais herdam todas as características dos
objetos básicos.
♦ O CTS define algumas regras que toda linguagem deve seguir, para ser habilitada ao .NET. Por
seguir um conjunto de regras comum, a interação entre programas escritos em diferentes
linguagens fica bem mais fácil.
NOTA
Mais adiante, farei uma descrição detalhada do CLR e dos seus componentes, dentre os quais está o CTS.
METADATA
Na seção “Questões a considerarmos nos modelos de 3 ou mais camadas utilizados atualmente”,
descrevemos, como uma das inconveniências do modelo de componentes baseados em COM/COM+,
o fato de que estes, para poderem ser utilizados, precisam ser registrados. Ao registrarmos um componente
COM/COM+, uma série de informações sobre o componente é gravada na Registry do sistema. Estas
informações são utilizadas pelos programas que precisam acessar o componente. Se alguma destas
informações estiver errada ou tiver sido alterada, o componente não poderá ser acessado e os programas
que utilizam o componente deixarão de funcionar corretamente.
No Framework .NET, para utilizarmos os componentes .NET (.NET Componentes), não é necessário
que estes sejam registrados. O próprio componente .NET possui todas as informações necessárias ao
seu funcionamento, bem como as informações necessárias para que outros aplicativos possam utiliza-
los. Estas informações fazem parte do próprio componente .NET e ficam gravadas no arquivo que
compõe componente, na forma de Metadados – metadata (dados sobre si mesmo). Uma tradução
“popularmente conhecida” para metadata seria: dados sobre dados. No nosso caso, metadata seriam as
informações que o componente .NET possui a respeito de si mesmo, informações estas que podem ser
utilizadas por outros componentes e serviços, para utilizar o componente em questão.
Além de fazer com que não seja necessário o registro do componente, as informações de metadata
facilitam a interoperabilidade entre diferentes componentes, mesmo entre componentes escritos em
diferentes linguagens. Estas informações são geradas, automaticamente, no momento da compilação
do componente e são gravadas no arquivo .DLL ou .EXE do componente. São muitas as informações
que podem ser inseridas no componente, na forma de metadata, tais como:
♦ Nome e versão do componente.
♦ Uma chave pública para verificação da origem e da autenticidade do componente.
♦ Informações sobre todas as classes ou componentes, dos quais o componente depende para
funcionar corretamente.
♦ Tipos disponibilizados (exportados) pelo componente.
♦ Permissões de segurança para o acesso ao componente, seus métodos e propriedades.
♦ Classes básicas e interfaces do Framework .NET, utilizadas pelo componente.
♦ Atributos personalizados, implementados no componente.
♦ Membros do componente (métodos, campos, propriedades, eventos, etc.).
Quando o componente é acessado, o CLR carrega os metadados do componente na memória e faz

referência a estes metadados, para obter informações sobre as classes, membros, herança e dependências
do componente.
São diversos os benefícios do uso de metadados, dentre os quais podemos destacar os seguintes:
♦ Módulos de código autodescritivos: O próprio componente contém toda a informação

necessária para interagir com outros componentes. Desta forma o componente pode ser
implementado como um único arquivo, o qual contém a sua definição (na forma de metadados)
e a sua implementação, o código do componente.
♦ Nunca é demais repetir: A utilização de metadados facilita, enormemente, a interoperabilidade
entre componentes criados usando diferentes linguagens.
ASSEMBLIES
Uma aplicação .NET é constituída de um conjunto de “blocos” chamados Assembly. Através dos as-
semblies (plural de assembly) é que podemos controlar a distribuição de uma aplicação, fazer o controle
de versões, além de definir as configurações de segurança. Um assembly é uma coleção de tipos e
recursos que foram construídos para trabalharem juntos, formando, com isso, uma unidade com
funcionalidade e escopos bem definidos. Um assembly fornece ao CLR importantes informações sobre
a implementação de tipos da aplicação. Para o CLR, um tipo somente existe no contexto de um assem-
bly. De uma maneira mais simples, poderíamos dizer que um assembly é o mecanismo utilizado pelo
.NET, para “empacotar” todos os elementos e informações necessárias ao funcionamento de uma
aplicação ou componente. Vamos simplificar mais ainda: o assembly é uma maneira de juntar e organizar
os diversos elementos que formam uma aplicação ou componente.
Os assemblies foram criados para simplificar a distribuição de aplicações e resolver o problema de

“versões”, existentes em aplicações baseadas em componentes. Lembram que no início deste capítulo
falamos sobre o termo “DLL Hell” (Inferno das DLL). Com este termo estávamos nos referindo ao
problema de um programa, ao ser instalado, substituir uma DLL por uma versão mais nova ou mais
antiga, fazendo com que programas que dependiam da versão anterior da DLL deixassem de funcionar.
Através do uso de assemblies e dos metadados contidos em cada componente, é possível que diferentes
versões, do mesmo componente, estejam disponíveis, ao mesmo tempo, em um mesmo computador.
Desta forma, cada programa utiliza a versão do componente para o qual o programa foi criado. Ao
instalarmos uma nova versão do componente, o qual vem embutido em um assembly, as versões
anteriores serão mantidas, se estas estiverem sendo utilizadas por outros programas. Isso faz com que
o inferno das DLLs (DLL Hell) seja coisa do passado.
Para resolver o problema de versões e evitar o inferno das DLLs, o CLR utiliza assemblies da seguinte
maneira:
♦ Permite que o desenvolvedor defina regras sobre o uso de diferentes versões entre diferentes
componentes .NET.
♦ Fornece a infra-estrutura necessária para que as regras de versão definidas pelo desenvolvedor,
sejam respeitadas.
♦ Fornece a infra-estrutura necessária, para que diferentes versões de um mesmo componente de

software possam rodar, simultaneamente. Esta execução simultânea é conhecida como “syde-
by-syde execution”.
Um assembly é composto de dois elementos básicos:
♦ Manifesto
♦ Um conjunto de módulos.
NOTA
Você aprenderá mais detalhes sobre assemblies e seus elementos mais adiante neste capítulo, onde apresentarei mais detalhes sobre o CLR
– Common Language Runtime.
DESENVOLVIMENTO EM: INTERFACES COM O USUÁRIO

PRÉ-REQUISITOS
♦ Conhecimento básico do Windows 2000 e 2003 e do Framework .NET.
METODOLOGIA
♦ Descrição dos elementos para criação da interface dos programas.
No Framework .NET a nomenclatura utilizada para representar os elementos que compõem uma
aplicação Web é diferente dos termos utilizados para representar uma aplicação tradicional para o
Windows, também conhecidas como aplicações Win32. Aliás este é um dos pontos que gostaria de
destacar, pois o Framework .NET não foi concebido apenas para a criação de aplicações Web. Com
Framework .NET, podemos criar qualquer tipo de aplicação, desde aplicações Web, passando por
aplicações Win32 tradicionais, até aplicações de Console, também conhecidas como aplicações de
linha de comando.
Em termos de interface com o usuário, temos dois elementos a considerar:
♦ Windows Forms
♦ Web Forms
WINDOWS FORMS
Que o Framework .NET foi todo projetado tendo em vista a Internet nós já sabemos. Porém nem todas
as aplicações são ou serão desenvolvidas para a Web. A utilização de Windows Forms (Win Forms ou,
se preferirem formulários do Windows) é o mecanismo que nos permite criar as tradicionais aplicações
para Windows.
Windows Forms é o novo mecanismo para construção de aplicações Windows, baseadas no Frame-
work .NET.
Um Windows Form é bastante semelhante ao conceito de formulário utilizado pelas versões atuais do
VB e do Delphi. O formulário é o elemento básico, sobre o qual adicionamos controles e código para
determinados eventos associados com o formulário e seus controles. O Windows Form é tudo isso,
porém com a diferença de poder utilizar todos os mecanismo do Framework .NET. Dentre os principais
mecanismos disponíveis, destaca-se o mecanismo de herança, o qual é chamado, para o caso dos
Windows Forms, de herança visual. Anteriormente havíamos comentado sobre herança visual.
Windows Forms
Controles e demais elementos constituintes do Windows Form
CLR
Figura 13.9 Uma aplicação Win32 com o Framework .NET.
Um Windows Form, como tudo no Framework .NET, é um objeto, o qual é obtido a partir da instância de
uma classe básica. Todos os formulários no Framework .NET são baseados em uma das seguintes classes:
♦ System.Windows.Forms.
♦ São baseadas em um formulário padrão criado pelo usuário, através do mecanismo de herança.
Em resumo, o Windows Form é o elemento básico de criação de interfaces para interação do usuário
com a aplicação; em outras palavras, o Windows Form é o elemento visual das aplicações, elemento
este com o qual o usuário irá trabalhar.
Na Figura 13.9, temos uma visão geral dos elementos que compõem uma aplicação Win32 típica,
construída com o Framework .NET.
WEB FORMS
Para aplicações Win32 a interface com o usuário são os Windows Forms, vistos no item anterior. Para
aplicações Web, criadas com ASP.NET, as páginas são construídas utilizando-se Web Forms.
Um dos objetivos da utilização de Web Forms é trazer para o desenvolvimento Web as facilidades de
“arrastar e soltar”, existentes no desenvolvimento de aplicações tradicionais. Com isso poderemos,
com o uso do Visual Studio .NET, criar páginas Web, simplesmente arrastando componentes sobre um
Web Form.
Com o uso de Web Forms, uma página ASP.NET é dividida em dois componentes básicos:
♦ Um modelo (template), o qual contém os elementos visuais e de formatação da página,

normalmente conteúdo baseado em HTML, ou HTML gerado pelo código ASP.NET.
♦ Uma seção de código, a qual é responsável por todo o processamento lógico dos elementos da
página. Por exemplo, na seção de código podemos colocar os comandos necessários para
estabelecer uma conexão com um Banco de Dados do SQL Server 2005 e um comando para
retornar os dados que serão utilizados pela página. Também podemos colocar comandos que
atualizam os dados no Banco de Dados, de acordo com as informações digitadas na página.
Observe que com estes dois elementos: template e seção de código, temos uma separação entre o
código de processamento e o conteúdo da página propriamente dito. Isso evita a criação de códigos do
tipo “macarrão”, onde temos seções de código alternadas com seções de HTML, sucessivamente. O
código “macarrão” é bastante comum nas versões anteriores do ASP (ASP 2.0 e ASP 3.0).
Com o Framework .NET é disponibilizada uma série de novos controles para utilização em páginas
ASP.NET. Estes novos controles apresentam novas características e propriedades que facilitam a criação
de páginas, digamos, “mais inteligentes”, onde podemos inserir código em resposta a uma série de
eventos. O melhor disso tudo é que o funcionamento destes controles é independente do navegador
utilizado pelo cliente, uma vez que os controles são processados no servidor Web e o que retorna para
o cliente é o código HTML puro, resultante do processamento do código no servidor.
A seção de código de um Web Form pode ser criada utilizando qualquer linguagem do Framework
.NET, como por exemplo: VB.NET, C# ou Jscript.NET.
Com a utilização de Web Forms é bem mais simples manter o “estado” de uma página, entre diferentes
requisições do usuário, isso tudo sem a necessidade de implementar a manutenção de estado utilizando
os objetos Session e Application, como era necessário no ASP 3.0.
Além disso, com o uso de Web Forms, podemos construir aplicações Web com interfaces bastante
sofisticadas e funcionais, de uma maneira fácil através da utilização de ferramentas de desenvolvimento
como o Visual Studio .NET e outras que já estão disponíveis, como Delphi 7.0, Webmatrix, Dreamweaver
MX 2004 e assim por diante.
Na Figura 13.10, temos uma visão geral dos elementos que compõem uma aplicação Web típica, criada
com ASP.NET, com a utilização de Web Forms.
ASP.NET
Web Forms:
1. Apresentação
2. Código
CLR
Figura 13.10 Uma aplicação Web com ASP.NET e Web Forms.
DESENVOLVIMENTO: OS SERVIDORES .NET

PRÉ-REQUISITOS
♦ Conhecimento básico do Windows 2000 ou 2003 e do Framework .NET.
METODOLOGIA
♦ Descrição dos servidores que dão suporte ao desenvolvimento de aplicações .NET.
Além do Framework .NET, a Microsoft vem disponibilizando novas versões dos servidores da família
Back Office. Estas novas versões vêm sendo adaptadas para dar suporte ao modelo de desenvolvimento
.NET. Por exemplo, os servidores estão sendo adaptados para o padrão de dados XML, que é o padrão
de dados para troca de informações entre componentes e serviços do Framework .NET. Outra
preocupação para esta linha de servidores é com a “escalabilidade”. Estes servidores foram projetados
para atender um grande volume de usuários, além de terem a capacidade de utilizar a tecnologia de
Cluster e Balanceamento de Cargas do Windows 2000 e do Windows Server 2003. Outras diretivas
básicas para estes servidores são as seguintes:
♦ Interoperabilidade: Ao contrário do que muitos anunciaram, os mainframes continuam vi-

vos. Além disso, o ambiente de TI das empresas é bastante heterogêneo, onde convivem
diferentes sistemas operacionais e diferentes fontes e formatos de dados. O Framework .NET e
os servidores .NET facilitam a tarefa de integrar dados das mais variadas fontes, desde o
tradicional mainframe, passando por fontes de dados estruturados como o SQL Server 2005
(este você, certamente, já conhece bem) ou ORACLE e chegando a fontes não estruturadas,
como mensagens de correio eletrônico, arquivos de vídeo e imagens gráficas.
♦ Facilidade de gerenciamento: Dentro da filosofia da Microsoft de construir interfaces de
administração intuitivas e fáceis de utilizar. Todos os servidores utilizam interfaces padronizadas,
através do uso do MMC – Microsoft Management Console – e snap-ins específicos para a
administração de cada servidor.
Neste tópico descreveremos, rapidamente, quais os servidores .NET e qual a função de cada um no
ambiente empresarial. Veremos uma breve descrição dos seguintes servidores:
♦ SQL Server 2005
♦ Exchange Server 2000
♦ BizTalk Server 2000
♦ Commerce Server 2000
♦ Application Center 2000
♦ Host Integration Server 2000
♦ Internet Security and Acceleration Server 2000
♦ Mobile Information 2001 Server
SQL SERVER 2000

O SQL Server 2005. Este, certamente, dispensa maiores comentários, pois é o objeto de estudos de todo
este livro.
EXCHANGE SERVER 2003

É um servidor de mensagens e correio eletrônico, completamente integrado com o Active Directory e
com o Framework .NET, além de ser uma plataforma para desenvolvimento de aplicações do Workflow.
Cada vez mais o Exchange vem ganhando mercado de concorrentes como o Lotus Notes da IBM e o
Novel Groupwise da Novel. O Exchange 2003 é completamente integrado com o Active Directory, o
que facilita a criação e manutenção de contas de usuários. O suporte ao XML também está presente
nesta versão do Exchange. Maiores informações sobre Exchange podem ser encontradas nos seguintes
endereços:
♦ http://www.microsoft.com/exchange
♦ http://www.swynk.com
BIZTALK SERVER
Com a consolidação do comércio eletrônico, principalmente do chamado B2B – Business to Business que
é o comércio entre empresas, cada vez faz-se mais necessária a integração entre sistemas de informação
de diferentes empresas. Um dos maiores problemas é que estes diferentes sistemas de informação utilizam
diferentes formatos de dados e diferentes mecanismos para troca de informações. Durante muito tempo,
uma das soluções adotadas foi o EDI – Exchange Data Interchange. Porém o EDI apresenta algumas
limitações, além de um custo elevado. Com o advento da Internet e do padrão XML, a troca de informações
entre empresas tem migrado para soluções onde o XML é o formato universalmente aceito, o que facilita
a troca de informações. O Biztalk Server é a solução da Microsoft que facilita a criação, desde o modelo
conceitual até a implementação, de aplicações baseadas em XML, para troca de informações entre diferentes
empresas ou até mesmo entre diferentes sistemas, da mesma empresa. Maiores informações e uma versão
de avaliação para download podem ser encontradas no seguinte endereço:
http://www.microsoft.com/biztalk
COMMERCE SERVER 2000

O Commerce Server trabalha em conjunto com o IIS. Na verdade o Commerce Server facilita a criação
de um site para comércio eletrônico, quer seja B2C – Business to Consumer, quer seja B2B – Business to
Business. Através de uma série de modelos prontos e através da utilização de assistentes, podemos
rapidamente criar um site para comércio eletrônico. Após a criação, é possível personalizar o site de
acordo com as necessidades da empresa. Pode trabalhar integrado com os demais servidores .NET. Por
exemplo, pode utilizar o SQL Server 2000 para armazenar informações sobre o catálogo de produtos,
preços e estoque. Maiores informações e uma versão de avaliação para download podem ser encontradas
no seguinte endereço:
http://www.microsoft.com/commerceserver
APPLICATION CENTER 2000

O Application Center 2000 é a ferramenta da Microsoft para a implementação e gerenciamento de
Web sites que deverão suportar uma elevada carga de acesso, com um grande número de acessos
simultâneos. Também oferece ferramentas para a distribuição de um site entre diversos servidores,
com o objetivo de distribuir a carga entre diversos equipamentos. Com o uso do Application Center
fica mais fácil realizar tarefas como por exemplo manter sincronizado o conteúdo dos diversos servidores,
bem como fazer o gerenciamento e a distribuição de cargas.
HOST INTEGRATION SERVER 2000

Esta é a nova versão do antigo SNA Server da Microsot, só que com o nome alterado. O Host Integra-
tion Server possibilita a integração de redes Windows com outros ambientes, como, por exemplo,
mainframes baseados na arquitetura SNA da IBM. Maiores informações e uma versão de avaliação para
download podem ser encontradas no seguinte endereço:
http://www.microsoft.com/hiserver
INTERNET SECURITY AND ACCELERATION SERVER 2004 – ISA SERVER 2004

De certa maneira é o successor do Proxy Server 2.0 da Microsoft, com algumas melhorias. É
utilizado para conectar a rede local da empresa, de uma maneira segura, à Internet. Suas funções
básicas são as seguintes:
♦ Firewall
♦ Cache de páginas
Maiores informações e uma versão de avaliação para download podem ser encontradas no seguinte
endereço:
http://www.microsoft.com/isaserver
MOBILE INFORMATION 2001 SERVER

O Framework .NET não foi concebido apenas para o desenvolvimento de aplicações que serão acessadas
através de PCs ligados em rede ou computadores tradicionais. Com o Framework .NET, a Microsoft
pretende fornecer uma sólida plataforma de desenvolvimento, também para os diversos dispositivos
móveis existentes, tais como telefones celulares, assistentes pessoais, Palm Pilots, etc. Dentro desta
estratégia, o Mobile Information 2001 Server desempenha um papel fundamental, fornecendo suporte
ao protocolo WAP 1.1. Usando o Mobile Information 2001 Server é possível, por exemplo, fazer com
que as suas mensagens do Exchange sejam convertidas para o formato em que possam ser lidas por um
celular ou qualquer outro dispositivo habilitado ao WAP.
Maiores informações e uma versão de avaliação para download podem ser encontradas no seguinte
endereço:
http://www.microsoft.com/servers/miserver/default.htm
DESENVOLVIMENTO EM: ADO.NET

PRÉ-REQUISITOS
METODOLOGIA
♦ Descrição do ADO.NET.
Com o ASP 3.0, a tecnologia preferida para o acesso a diferentes fontes de dados é a tecnologia ADO –
Activex Data Objects, trabalhando em conjunto com OLE-DB, conforme ilustrado na Figura 13.11.
O “Activex Data Objects para o Framework .NET” (ADO.NET) é um conjunto de classes que expõem serviços
para acesso a diversas fontes e formatos de dados, para os programadores, utilizando qualquer linguagem
habilitada ao .NET. Cabe ressaltar que ADO.NET não é um substituto para o ADO, pois as duas versões de
componentes para acesso a dados podem continuar existindo em um mesmo servidor Web, por exemplo.
Ao instalarmos o Framework .NET, é instalado, além do suporte a páginas ASP.NET, todo o conjunto de
classes do Framework .NET. Porém o acesso a páginas ASP tradicionais continua disponível, o que significa
que mesmo após instalar o Framework .NET, todas as aplicações criadas com ASP 3.0 ou versões anteriores
do ASP, continuarão funcionando sem problemas, até que você possa migrá-las para ASP.NET. Então em
um mesmo servidor Web podemos ter uma página ASP, que acessa dados de um arquivo .mdb do Access
utilizando ADO, convivendo com um aplicativo criado com ASP.NET, o qual acessa informações de uma
caixa de correio do Exchange e em Bancos de Dados do SQL Server 2005, utilizando ADO.NET.
ADO
OLE DB
OLE DB Providers
Exchange Gerenciador ODBC

Jet SQL Server
Server
Provider Provider
Provider

Drivers ODBC
Microsoft Microsoft Microsoft Microsoft Microsoft

Exchange ORACLE
Access SQL Server SQL Server Access
Server
Figura 13.11 Acessando dados com ASP 3.0.
ADO.NET foi projetado pensando nos desafios de criar programas baseados no modelo de n camadas,
para a Internet, os quais precisam acessar dados de diferentes fontes. Além disso, as aplicações Internet
atuais estão bem mais sofisticadas, onde é necessário manter o conceito de estado, o que é difícil em
um mundo como o da Internet, conhecido como Connection Less. Na Internet o usuário faz a conexão
com o servidor, requisita a página, recebe o resultado e desfaz a conexão. Para manter o estado entre
uma conexão e outra, no ASP 3.0, utilizávamos os objetos Session e Application. Manter o estado ficou
muito mais simples com ASP.NET e ADO.NET.
Outro fator importante a ser considerado é que, cada vez mais, as aplicações estão utilizando dados no
padrão XML. ADO.NET fornece meios de utilizar dados no padrão XML.
Os objetos e métodos de ADO.NET são bastante diferentes dos utilizados com ADO. Um dos primeiros
objetos de que “sentiremos falta” é do tradicional Recordet, o qual era muito utilizado no ASP 3.0. Na
Figura 13.12 temos uma visão geral da arquitetura do ADO.NET.
NOTA
Esta figura foi retirada da documentação do Framework .NET.
.NET Data Provider DataSet

Connection DataAdapter DataTableCollection
Transaction SelectCommand DataTable
DataRowCollection
InsertCommand
Command
DataColumnCollection
Parameters UpdateCommand
ConstrainCollection
DeleteCommand
DataReader
DataRelationCollection
Database XML
Figura 13.12 Uma visão geral da arquitetura do ADO.NET.
Observe que não temos o tradicional objeto Recordet. No próximo item você aprenderá mais detalhes
sobre o “coração” do Framework .NET: CLR – Common Language Runtime.
DESENVOLVIMENTO EM: CLR – COMMON LANGUAGE RUNTIME

PRÉ-REQUISITOS
METODOLOGIA
♦ Descrição detalhada do CLR.
Nos tópicos anteriores falei rapidamente sobre o CLR. Agora chegou o momento de apresentar mais
alguns detalhes sobre este, que, com certeza, é o principal elemento do Framework .NET.
O CLR é o ambiente de execução do Framework .NET. O CLR gerencia a execução de qualquer aplicativo
.NET, além de fornecer uma série de serviços que facilitam e agilizam o desenvolvimento de aplicações.
Conforme discutido anteriormente, o maior benefício do CLR é que ele fornece uma série de serviços
e funcionalidades, que nos modelos de desenvolvimento anteriores ao .NET tinham que ser codificados
na própria aplicação. Ao fornecer este conjunto de serviços e funcionalidades, evita-se que o programador
tenha que se preocupar com a maneira com a aplicação vai ser executada, com a alocação de memória,
com liberação de memória e tantos outros aspectos que dificultavam o desenvolvimento de aplicações.
Com o suporte fornecido pelo CLR, o programador somente precisa se preocupar com a lógica da sua
aplicação e não com a infra-estrutura necessária para a aplicação funcionar corretamente e sem problemas
– isso é delegado ao CLR.
O código que é executado sob o controle do CLR é chamado de “Managed Code”. Vamos arriscar uma
tradução: Código Gerenciado. Este gerenciado significa: “Sob o controle do CLR”. Em contrapartida,
código que não for executado sob o controle do CLR, no caso de programas não .NET, é chamado de
“no Managed Code”, que traduziremos por código não gerenciado.
Os programas criados com linguagens habilitadas ao .NET e, portanto, executados sob o comando do
CLR, podem se beneficiar das seguintes vantagens:
♦ Fácil integração e interoperabilidade entre programas criados em diferentes linguagens.
♦ Fácil implementação e controle da segurança da aplicação.
♦ Utilizar a biblioteca de classes do Framework .NET.
♦ Melhor gerenciamento das diferentes versões de um mesmo componente, inclusive com a

possibilidade de execução simultânea de diferentes versões do mesmo componente, o que é
conhecido por: “Syde-by-syde execution”.
♦ Gerenciamento automático da alocação e liberação da memória.
COMPILAR OU NÃO COMPILAR, EIS A QUESTÃO?

Outro ponto importante a esclarecer é se os programas .NET são compilados ou interpretados. Con-
fesso que, na opinião deste autor, pouca importância tem se é compilado ou interpretado, desde que o
desempenho final seja satisfatório. Mas como todo programador que se preza é um pouco teimoso, e
apaixonado por uma discussão acalorada, vamos esclarecer este assunto antes que os ânimos se exaltem.
Ao criarmos um programa, utilizando uma linguagem habilitada ao .NET, como por exemplo o VB.NET
ou o C#, o código-fonte do programa, ao ser compilado-gera código MSIL – Microsoft Intermediate
Language. Senhores! Com calma. Ainda não é hora de começar a malhar o .NET. O CLR, que será
responsável pela execução e controle do código MSIL gerado, COMPILA o código MSIL para código
nativo. Com isso, o código que é executado pelo CLR é código COMPILADO nativo da plataforma
onde está instalado o Framework .NET. Até o momento, a única plataforma compatível é a dobradinha
Windows/Intel. Porém a Microsoft está tornando disponível, publicamente, as especificações para
CLR e MSIL, o que possibilita que outras empresas desenvolvam um Framework .NET para outras
plataformas, como, por exemplo, o UNIX ou LINUX.
Nos veremos mais adiante que, mesmo uma página ASP.NET, é compilada no servidor Web, antes de
ser enviada para o navegador do cliente. Em resumo, todo e qualquer código executado pelo CLR, é
código compilado nativo. Agora sim. Fiquem à vontade para discutir, dizer que não é bem assim, que
esse tal de MSIL não tem nada a ver, mais um chope e assim por diante.
O PAPEL DOS METADADOS (METADATA).

Para que o CLR possa fornecer uma série de serviços ao “managed code”, os compiladores das linguagens
habilitadas ao .NET devem ser capazes de criar metadados. Os metadados contêm informações sobre
os tipos, membros e referências contidas no código do programa. Os metadados são gravados com o
próprio código do programa. Desta maneira toda a informação necessária para que o programa funcione
está contida no seu próprio código, o que faz com que não seja necessário o registro dos componentes
do programa, diferente do que acontecia com os componentes COM/COM+. O CLR utiliza metadados
para localizar e carregar programas ou componentes, organizar as várias instâncias de um mesmo
componente na memória, resolver a chamada de métodos, gerar código nativo, garantir a segurança
de acesso e definir os limites para o contexto de execução de um componente ou programa.
O CLR automaticamente gerencia a alocação de objetos na memória, bem como as referências aos
objetos. Quando não houver mais nenhuma referência ao objeto, o que significa que este não está
mais sendo utilizado, o CLR automaticamente remove o objeto, liberando mais memória para o sistema.
Com isso os tradicionais problemas de “memory leaks” – programas que alocam recursos de memória
e não liberam, fazendo com que a quantidade de memória disponível fique reduzida, até o ponto de
fazer com que o próprio sistema operacional fique instável e a máquina tenha que ser reinicializada –
deixam de existir ou, mais realisticamente, são bastante minimizados. Vejam o quanto fica simplificada
a tarefa de desenvolvimento, uma vez que o programador não precisa preocupar-se com alocação e
liberação de memória, apenas com a lógica do seu programa.
INTEGRAÇÃO ENTRE DIFERENTES LINGUAGENS: PROMESSA OU REALIDADE?

Com o CLR fica fácil a criação de componentes e aplicações nas quais os objetos sejam capazes de
interagir, mesmo que codificados em diferentes linguagens. Por exemplo, podemos criar uma classe
chamada Clientes, em VB.NET. Podemos criar uma classe Clientes Especiais, em C#, herdada da classe
Clientes, que foi criada em VB.NET. Com isso a nossa classe Clientes Especiais irá herdar todas as
propriedades e métodos da classe Clientes.
NOTA
Mais adiante apresentarei os principais conceitos de orientação a objetos, como por exemplo: classes e herança.
Essa integração entre diferentes linguagens é possível, pois todas as linguagens habilitadas ao .NET,
têm acesso a um sistema de tipos comuns CTS – Common Type System. Falaremos um pouco mais
sobre o CTS mais adiante, neste capítulo. Além disso cada componente ou aplicativo possui informações,
na forma de metadados, sobre a sua estrutura, sobre os métodos e propriedades que o objeto possui e
que podem ser acessados por outros componentes.
DESENVOLVIMENTO EM: O PROCESSO DE EXECUÇÃO DE CÓDIGO DO CLR

PRÉ-REQUISITOS
♦ Conhecimento básico do Framework .NET e do CLR.
METODOLOGIA
♦ Descrição detalhada do processo de execução de código no CLR.
Vamos ver quais os passos envolvidos, desde a criação de uma aplicação utilizando uma das linguagens
habilitadas ao .NET, até a execução da aplicação, sob o controle do CLR.
Os passos para a criação e execução de uma aplicação .NET podem ser resumidos da seguinte maneira:
♦ Criar a aplicação ou componente utilizando uma linguagem habilitada ao .NET (VB.NET, C#, etc.).
♦ Compile o código da sua aplicação ou componente para gerar código MSIL. O compilador da
linguagem que você está utilizando compila o seu código fonte para MSIL e acrescenta os
metadados necessários.
♦ Em tempo de execução, um compilador JIT (Just In Time) do CLR transforma o código MSIL
em código nativo, COMPILADO.
♦ O código nativo é executado, utilizando toda a infra-estrutura disponibilizada pelo CLR.
Na Figura 13.13, temos uma ilustração destes passos.
CÓDIGO-FONTE DA APLICAÇÃO
(VB.NET, C#, etc.)
Compilador VB.NET, C#, etc.
MSIL
Compilador JIT - Just In

Time
do CLR
CÓDIGO NATIVO PARA EXECUÇÃO
Figura 13.13 O processo de execução de código do CLR.
Conforme ilustrado na Figura 13.13, quando compilamos o código-fonte criado por uma linguagem
habilitada ao .NET, geramos código MSIL, a qual é um conjunto de instruções, independente da CPU,
conjunto este que pode ser convertido (pelo JIT) para código nativo. O código MSIL inclui instruções
para carregar, armazenar, inicializar e chamar métodos, instruções para operações aritméticas e lógicas,
controle de fluxo do programa, acesso direto a memória, tratamento de exceções e demais operações
necessárias à execução do programa.
Antes que o código MSIL possa ser executado ele precisa ser convertido para código específico da CPU
em questão. Isto é feito pelo JIT – Just in time compiler. O CLR disponibiliza compiladores JIT para
cada arquitetura suportada pelo CLR; desta maneira o mesmo conjunto de instruções MSIL pode ser
compilada e executada em qualquer arquitetura para a qual exista um compilador JIT.
Esta é a estratégia da Microsoft para fazer com que o código MSIL de aplicações .NET possa ser executado
em diferentes plataformas, desde servidores Windows ou não Windows, até dispositivos móveis para
os quais esteja disponível um compilador JIT. É claro que a implementação em outras plataformas que
não o Windows, como por exemplo o UNIX, dependerá da implementação de terceiros. Por exemplo,
a HP pode querer implementar um compilador JIT que rode no HP-UX, fazendo com que aplicações
.NET possam rodar nesta plataforma. Se surgirão implementações para outras plataformas é uma questão
que somente o tempo e o mercado dirão.
Quando o compilador de uma linguagem habilitada ao .NET produz o código MSIL, este também cria os
metadados necessários. O código MSIL e os metadados estão contidos em um arquivo PE – portable
executable. O portable significa que este arquivo pode, em tese, ser compilado e executado em qualquer
plataforma para a qual existe um compilador JIT. A presença dos metadados, juntamente com o código
MSIL, torna o código autodescritivo, o que significa que não temos mais a necessidade de “bibliotecas de
tipo” (type libraries) ou IDL – Interface Definition Language – dispositivos que eram necessários ao
funcionamento de componentes baseados no modelo COM/COM+. Voltamos a salientar este ponto, o
componente criado para o .NET possui, na forma de metadados, toda a informação necessária ao seu
funcionamento e necessária para que possa ser acessado por outros componentes. O CLR localiza e extrai
os metadados do arquivo PE durante a execução, à medida que isso vai sendo necessário.
MAIS ALGUMAS OBSERVAÇÕES SOBRE O JIT

O processo de compilação utilizado pelo JIT procura fazer uma série de otimizações, para tornar o
código nativo gerado, o mais enxuto e com o melhor desempenho possível.
O JIT detecta se algum método ou propriedade não será utilizado durante a execução do programa. Ao
invés de converter todo o código MSIL, contido no arquivo PE, o JIT converte apenas o código que
realmente será necessário para a execução do programa. Isso faz com que a compilação seja mais
rápida, com que sejam poupados recursos como por exemplo memória e o código resultante é otimizado,
tanto em termos de tamanho quanto em termos de velocidade de execução.
Como parte da compilação do MSIL para código nativo, o código deve passar por um processo de
verificação, a não ser que tenha sido definida uma política de segurança que permite ao código passar
pela verificação. O processo de verificação faz uma análise do código MSIL e dos metadados, para definir
se o código pode ser definido como “type safe”. Para que o código possa ser definido como type safe, ele
somente deve acessar regiões de memória para as quais tenha autorização. Este processo é necessário
para garantir que os objetos estão isolados uns dos outros, de tal maneira que um objeto não tente
alterar ou corromper dados de outros objetos. Na plataforma Windows 9x, quando um programa tenta
acessar a área de memória utilizada por outro programa, é gerada uma “Falha Geral de Proteção”, com
a famigerada mensagem “Você Executou uma Operação Ilegal e o seu programa será fechado”.
Para que o código passe no teste de “type safe”, ele deve atender as seguintes condições:
♦ Todas as referências feitas a um determinado tipo são compatíveis com o tipo que está sendo
referenciado.
♦ Somente operações devidamente definidas são invocadas pelo objeto.
♦ É possível verificar e confirmar a identidade do objeto. Isso evita que um componente, por
exemplo um vírus, se faça passar por um componente válido, porém com um comportamento
bem diferente do verdadeiro componente.
O processo de verificação também faz uma análise do código MSIL, para ver se este foi
corretamente gerado. Se as políticas de segurança da nossa aplicação definem que o código deve
passar na verificação de “type safe” e o código não passar nesta verificação, uma exceção será
gerada quando o código for executado.
NOTA
O mecanismo de verificação do código é um exemplo típico de funcionalidade disponibilizada pelo Framework .NET, a qual, nos modelos
anteriores, precisava ser desenvolvida pelo programador.
Um detalhe importante é que nem todo o código MSIL é compilado para código nativo de uma só vez.
A compilação acontece em nível de método. Quando um método é chamado, o código MSIL do método
é compilado, o código nativo é gerado pelo JIT e o método é executado. O código nativo gerado é
mantido. Quando o método for chamado pela segunda vez, o código nativo gerado na primeira chamada
será executado, evitando, com isso, que o código do método tenha que ser compilado a cada chamada
do método, o que acarretaria uma perda considerável de desempenho.
DESENVOLVIMENTO EM: ASSEMBLIES

PRÉ-REQUISITOS
METODOLOGIA
♦ Descrição dos assemblies.
Conforme descrito anteriormente, chegou o momento de apresentarmos mais alguns detalhes sobre
assemblies e sobre o formato (ou quem sabe anatomia) de uma aplicação .NET.
UMA DEFINIÇÃO EM POUCAS PALAVRAS

Para aplicações tradicionais do Windows, anteriores ao modelo .NET, a aplicação final é um arquivo
executável ou um arquivo executável mais um conjunto de .DLL e componentes. Uma DLL pode
conter um objeto COM/COM+ em uma biblioteca de tipos (typelib).
Para o Framework .NET, os diversos componentes de uma aplicação são “empacotados” através da
utilização de assemblies. Um assembly contém todo o código MSIL gerado pelo compilador, os
metadados e os demais arquivos necessários ao funcionamento da aplicação. Cada assembly também
contém um “manifesto”. O manifesto contém as seguintes informações:
♦ Uma lista dos arquivos contidos no assembly.
♦ A definição de quais tipos e recursos do assembly podem ser acessados por outros componentes
ou programas.
♦ Um mapeamento entre os tipos e recursos disponibilizados pelo assembly e os arquivos que
contêm os tipos e recursos.
♦ Uma lista de outros assemblies, dos quais o assembly depende para o seu correto funcionamento.
♦ Informações sobre a identidade do assembly, incluindo o nome e a versão do assembly.
♦ Se o assembly for público, como por exemplo um Web Service, o manifesto também pode
conter a chave pública do assembly. Este é um mecanismo semelhante, em funcionalidade, à
utilização de um certificado digital, para identificar a origem de um controle ActiveX.
Um assembly contém toda a informação necessária ao seu funcionamento. Ao definirmos um assem-

bly, ele pode estar contido em um único arquivo ou em múltiplos arquivos. A vantagem de utilizar
múltiplos arquivos é que as diferentes partes do assembly podem ser carregadas e executadas à medida
que forem sendo utilizadas e não todos de uma só vez.
FUNÇÕES DO ASSEMBLY
Pela descrição anterior podemos concluir que o assembly é um elemento fundamental na criação de
aplicações .NET. Os assemblies foram projetados, principalmente, para simplificar o processo de
distribuição de aplicações e para solucionar o problema do controle de versões existente no modelo
COM/COM+. Um assembly é responsável pelas seguintes funções:
♦ Contém o código executado pelo CLR. O código MSIL contido em um arquivo PE (portable
executable) não poderá ser executado se o código MSIL não estiver associado a um manifesto,
o qual por sua vez faz parte de um assembly.
♦ É a unidade básica para atribuição de permissões e configurações de segurança. Podemos definir,
em nível de assembly, quem pode acessar o assembly e com que nível de acesso.
♦ É uma unidade de referência, pois as informações contidas no manifesto do assembly são utilizadas
para resolver tipos e para atender requisições de outros assemblies. Estas informações definem
quais métodos e propriedades são visíveis e podem ser acessados externamente. O manifesto
também contém informações a respeito de quais assemblies o assembly em questão depende.
♦ É uma unidade para definição de versão. A atribuição de um número de versão é feita em nível
de assembly.
♦ É uma unidade de distribuição das aplicações .NET. Quando uma aplicação é inicializada,
somente o assembly chamado na inicialização da aplicação precisa estar disponível. Outros
assemblies somente são chamados à medida que forem sendo utilizados. Essa é uma característica
muito importante, principalmente para aplicações Web, onde a velocidade das conexões é
sempre um fator crítico a ser considerado.
Assemblies podem ser estáticos ou dinâmicos. Assemblies estáticos podem incluir tipos do Framework
.NET (interfaces e classes), além dos recursos utilizados pelo assembly (bitmaps, .jpg, arquivos de som
ou imagem, etc.). Assemblies estáticos são gravados em disco em arquivos PE. Na verdade um arquivo
PE pode ser gravado na forma de um EXE ou uma DLL.
Assemblies dinâmicos rodam diretamente da memória e não são salvos no disco antes de serem
executados. Após a execução podemos salvar assemblies dinâmicos em disco.
COMPONENTES DO ASSEMBLY
Um assembly estático é formado pelos seguintes componentes:
♦ Manifesto, o qual contém metadados do assembly.
♦ Metadados sobre os tipos do assembly (Type metadata).
♦ Código MSIL.
♦ Demais recursos necessários, como por exemplo arquivos gráficos, arquivos de vídeo, etc.
Podemos agrupar todos os elementos constituintes do assembly em um único arquivo, conforme

ilustrado na Figura 13.14.
Metadados do
Assembly
Type metadata
Código MSIL
Demais recursos
Figura 13.14 Assembly e seus componentes em um único arquivo.
Os componentes do assembly também podem estar divididos em diversos arquivos. Estes arquivos
podem conter módulos de código compilado, recursos (como por exemplo arquivos gráficos ou de
vídeo) ou qualquer outro arquivo necessário ao funcionamento da aplicação .NET.
Existem duas razões para a colocação dos componentes de um assembly em múltiplos arquivos:
♦ Quando precisamos combinar, na mesma aplicação, componentes ou módulos criados em

diferentes linguagens.
♦ Para otimizar o download dos componentes de uma aplicação, de tal maneira que os
componentes ou módulos menos utilizados somente sejam carregados quando forem
necessários. Esta é uma alternativa importante, principalmente para aplicações Web.
Na Figura 13.15 temos o exemplo de um assembly composto de quatro arquivos:
♦ Um arquivo é o módulo principal. – criado em VB.NET.
♦ Outro arquivo é o módulo com funções (Criado em C#) usadas pelo assembly principal.
♦ Um arquivo .bmp.
♦ Um arquivo .jpg.
MeuAssembly.dll Módulo utilitário

Criado em VB.NET Criado em C#
Metadados do Assembly Type metadata
Type metadata Código MSIL
Código MSIL
File1.bmp
File2.jpg
Recursos:
gráficos e outros
Figura 13.15 Um assembly, vários arquivos.
O QUE TEMOS NO “MANIFESTO”?

O Manifesto contém o seguinte conjunto de informações (metadados):
♦ Qual a relação entre os diferentes componentes do assembly.
♦ Informações sobre a versão do assembly.
♦ Escopo.
♦ Informações para resolver referências a outras classes e componentes.
O manifesto pode estar contido em um arquivo PE – Portable executable (pode ser um .exe ou uma
.dll), juntamente com o código MSIL ou pode estar em um arquivo PE separado, o qual contém somente
o manifesto. Esta última situação acontece quando temos um assembly formado de diversos arquivos.
As informações contidas no manifesto são responsáveis pelas seguintes funções:
♦ Relação dos arquivos que compõem o assembly.
♦ Gerencia o mapeamento entre os tipos e recursos disponibilizados pelo assembly e os arquivos

onde estão contidas as declarações e implementações dos respectivos tipos e recursos.
♦ Relaciona os assemblies dos quais o assembly em questão é dependente.
Em resumo, reforçando o que já foi comentado anteriormente, este conjunto de informações fornece
uma autonomia ao assembly, de tal maneira que o assembly contém toda a informação necessária ao seu
próprio funcionamento e sobre como ser acessado por outros objetos. Isso evita que o assembly tenha
que ser registrado. Com estes recursos, o processo de instalar uma aplicação .NET está resumido a copiar
os arquivos necessários; como diriam os ainda apaixonados pelo DOS, voltamos ao estilo “xcopy” de
instalação, em referência ao comando xcopy, o qual é utilizado para copiar arquivos ou pastas.
DESENVOLVIMENTO EM: CTS – COMMON TYPE SYSTEM

PRÉ-REQUISITOS
METODOLOGIA
♦ Descrição do CTS.
O CTS desempenha um papel fundamental para garantir e facilitar e interoperabilidade entre programas
e componentes criados em diferentes linguagens do .NET. O CTS define a maneira como os tipos de
dados são declarados, usados e gerenciados pelo CLR. Através do CTS temos a garantia de que, por
exemplo, um inteiro terá as mesmas características, independente da linguagem na qual o inteiro
estiver sendo utilizado.
Uma das maiores dificuldades, no modelo COM/COM+, em fazer com que componentes escritos em
diferentes linguagens pudessem interagir é o fato de que cada linguagem possui o seu próprio conjunto
de tipos, o qual não é compatível com o conjunto de tipos das demais linguagens. Colocando de uma
maneira mais simples: No modelo COM/COM+, o tamanho, forma de armazenamento e demais
características de cada tipo são dependentes da linguagem.
O CTS é responsável pelas seguintes funções:
♦ Fornecer uma estrutura de dados e tipos padronizados, estrutura esta que torna a integração
entre diferentes linguagens uma realidade, além de garantir uma execução mais rápida, uma
vez que as conversões de tipo passam a ser coisa do passado.
♦ Fornece um modelo orientado a objetos, o qual é capaz de suportar qualquer linguagem
habilitada ao .NET.
♦ Define algumas regras e padrões que as linguagens habilitadas ao .NET devem obedecer, o que ajuda
a garantir que objetos escritos em diferentes linguagens sejam capazes de interagir e trocar mensagens.
CLASSIFICAÇÃO DOS TIPOS DO CTS

Temos duas categorias principais de tipos no CTS:
♦ Value types: Toda linguagem de programação fornece um conjunto de tipos básicos de dados,
como por exemplo: inteiros, caracteres, números reais, strings, etc. Estes tipos básicos são passados
por valor. Em outras palavras, se tenho uma variável x cujo valor é 5 utilizo o seguinte comando:
y=x
Neste caso estou passando o valor contido na variável x para a variável y. Alterações feitas na variável
y não afetarão o valor original da variável x. No Framework .NET estes tipos básicos, passados por
valor, são chamados de value types.
Estes tipos básicos fazem parte do conjunto de classes disponibilizado pelo Framework .NET. Por
exemplo, um inteiro é acessado como System.Int32 e um valor boleano como System.Boolean. Estes
tipos disponibilizados na própria biblioteca de classes do Framework .NET são chamados de “built-
in value types”.
Para fornecer uma maior flexibilidade, o Framework .NET também permite que sejam criados os
chamados “User-defined value types”. Com isso o programador pode definir tipos personalizados, os
quais são derivados da classe básica System.ValueType. Isso permite a criação de tipos específicos, de
acordo com as necessidades de cada aplicação. Por exemplo, para aplicações de engenharia, podemos
criar um tipo para representar números complexos ou matrizes com características definidas.
♦ Reference types: Este tipo contém uma referência para a localização do valor do tipo. Em
outras palavras, contém o endereço de memória onde está armazenado o valor da variável.
Vamos imaginar que x seja uma variável do tipo reference type. Agora vamos fazer uma outra
variável y, também do tipo reference type, como sendo igual a x:
y=x
Neste caso, o endereço onde está armazenado o valor de x foi atribuído à variável y. Se alterarmos o
valor de x, o que acontece com y? Como y contém uma referência ao endereço da variável x, ao
alterarmos x, y passará a enxergar o valor modificado. Por exemplo, se utilizarmos o comando
Console.Writeline(y), será exibido o novo valor da variável x.
DESENVOLVIMENTO EM: .NET FRAMEWORK CLASS LIBRARY –

BIBLIOTECA DE CLASSES DO FRAMEWORK .NET
PRÉ-REQUISITOS
METODOLOGIA
♦ Descrição do .NET Framework Class Library.
O Framework .NET fornece uma biblioteca hierárquica de classes. Esta biblioteca pode ser acessada por
qualquer linguagem habilitada ao .NET. Nesta biblioteca temos milhares de classes, interfaces e estruturas,
que disponibilizam os mais variados tipos de serviços e funcionalidades, como por exemplo:
♦ Acesso a fontes variadas de dados.
♦ Configurações de segurança.
♦ Desenvolvimento de componentes e Web services.
♦ Manipulação de objetos gráficos.
♦ Leitura e escrita em disco.
♦ Serviço de sockets, com a possibilidade do envio e recebimento de dados utilizando uma grande
variedade de protocolos de rede.
♦ Criação de aplicações Web, com serviços de fila de mensagens, correio eletrônico, etc.
♦ Manipulação de dados e esquemas XML.
♦ Criar aplicações Win32 tradicionais através do uso de Win Forms.
♦ Criar aplicações ASP.NET utilizando Web Forms.
♦ Acessar as informações contidas nos assemblies, na forma de metadados.
As funcionalidades oferecidas pela biblioteca de classes do Framework .NET facilitam a criação de

programas, uma vez que muitas funções já estão prontas para serem utilizadas, evitando que estas
tenham que ser implementadas em cada programa. A utilização de classes comuns a todas as linguagens
do Framework .NET também facilita a interoperabilidade entre diferentes linguagens.
Podemos utilizar as classes diretamente em nossos programas ou podemos criar classes que herdam os
métodos e propriedades de uma determinada classe e adicionar as modificações necessárias. Vejam
que aqui estamos utilizando o conceito de herança.
System.Int32
System.String
System
...
System.Security System.Data ...
Figura 13.16 Uma representação parcial do espaço de nomes System.
Como são milhares de classes, cada uma com seus métodos e propriedades, o Framework .NET precisa
organizar estas classes de uma maneira a evitar conflito de nomes. A maneira encontrada pelo Frame-
work .NET é através da utilização de um espaço de nomes (namespace). Um espaço de nomes é
simplesmente um agrupamento lógico das classes, estruturas e interfaces relacionadas. A maioria das
classes está contida no espaço de nomes System. Diretamente ligado a system temos a definição de
tipos básicos como por exemplo: Int32, String, etc. Um exemplo de classe de segundo nível, dentro do
espaço de nomes System, é a classe System.Data, a qual fornece uma série de objetos, métodos e
propriedades, para acesso às mais variadas fontes de dados. Temos também uma classe de segundo
nível chamada System.Security, a qual fornece serviços para configurações da segurança de acesso às
aplicações .NET. E assim vamos formando uma imensa hierarquia de classes. As classes de segundo
nível, como System.Data e System.Security, herdam todos os métodos e propriedades da classe mãe
System. Este é um dos princípios da orientação a objetos: Herança. No próximo item falaremos mais
sobre a herança e os demais fundamentos da orientação a objetos.
Na Figura 13.16, temos uma representação parcial do espaço de nomes System, no qual representamos
apenas alguns tipos básicos, ligados diretamente a System e às classes derivadas System.Data e
System.Security.
Podemos continuar nos aprofundando na hierarquia de classes. Por exemplo, existem classes derivadas
de System.Data. A classe System.Data.SqlClient contém toda a funcionalidade necessária para acessar
dados de um servidor SQL Server 2000 ou SQL Server 2005. Já a classe System.Data.OleDb fornece
funcionalidades para conexão com qualquer fonte de dados, para a qual esteja disponível um OLE-DB
Provider (para mais detalhes sobre OleDB Provider, consulte o Capítulo 12). Se acrescentássemos mais
estas duas classes, o espaço de nomes System ficaria conforme indicado na Figura 13.17.
System.Int32
System.String
System
...
System.Security System.Data ...
System.Data.SqlClient System.Data.OleDB ...
Figura 13.17 System.SqlClient e System.OleDb.
Vejam que a hierarquia de classes vai crescendo.
Para uma descrição completa, de todas as classes do Framework .NET, consulte o item “.NET Framework Class Library”, dentro do tópico “.NET
NOTA
Framework Reference”, na documentação do Framework .NET, conforme indicado na Figura 13.18. Lembrando que, uma vez instalado o Visual
Studio .NET (com o qual você aprenderá a trabalhar no Capítulo 15), você pode acessar a documentação do produto utilizando o comando: Iniciar
-> Todos os Programas -> Microsoft .NET Framework SDK -> Documentation.
Figura 13.18 Documentação do Framework .NET.
Vamos fazer uma breve descrição das principais classes do .NET Framework Class Library.
♦ Microsoft.Csharp: Suporte a linguagem C# do Framework .NET.
♦ Microsoft.Jscrip: Suporte a linguagem JScript no Framework .NET.
♦ Microsoft.VisualBasic: Contém o Run Time para o VB.NET e fornece o suporte a linguagem

no Framework .NET.
♦ Microsoft.Win32: Fornece dois tipos de classes; um que trata dos eventos gerados pelo sistema
operacional e outro que fornece funções para acessar e gravar informações na registry do sistema
operacional.
♦ System: É a classe principal para todo o espaço de nomes System. Contém todas as características
comuns a todas as classes, uma vez que as classes derivadas de System herdam suas características.
Também contém os tipos básicos, como por exemplo inteiros de 16, 32 ou 64 bits, string, byte,
etc.
♦ System.Collections: Contém as interfaces e classes que definem várias coleções de objetos,
como por exemplo listas, filas, arrays e dicionários.
♦ System.Data: Contém a maioria das classes que compõem a arquitetura do ADO.NET. Com
ADO.NET, podemos construir componentes capazes de gerenciar, de uma maneira eficiente,
dados de múltiplas fontes. Em um ambiente desconectado (connection less) como a Internet,
ADO.NET disponibiliza uma série de ferramentas para requisitar, alterar e sincronizar dados
em uma arquitetura de múltiplas camadas. O principal elemento do ADO.NET é uma classe
chamada DataSet.
♦ System.Data.Common: Contém as classes que são compartilhadas por todos os .NET data
providers (provedores de dados para o .NET). Um .NET data provider é uma coleção de classes
que fornece acesso para uma determinada fonte de dados, como por exemplo dados em um
mainframe ou em um servidor SQL Server 2000 ou SQL Server 2005.
♦ System.Data.OleDb: Contém as classes que fornecem acesso a qualquer fonte de dados para a
qual exista um OLE-DB Provider disponível.
♦ System.Data.SqlClient: Contém um conjunto de classes que fornece um acesso otimizado ao
SQL Server. Utiliza o driver nativo para o SQL Server, ao invés de um OLE-DB Provider ou uma
fonte ODBC. Por isso o acesso é mais rápido.
♦ System.Diagnostics: Um conjunto de classes que permite que seja feita a depuração e
acompanhamento da execução do código das aplicações .NET. Também fornece classes para
leitura e escrita no log de eventos, para inicializar serviços do sistema operacional, para monitorar
a performance do sistema através da utilização de contadores de desempenho.
♦ System.DirectoryServices: Um conjunto de classes que fornece para as aplicações .NET acesso

ao Active Directory do Windows 2000 Server ou do Windows Server 2003. As classes de
System.DirectoryServices podem ser utilizadas com qualquer Active Directory Service Provider
disponível. Atualmente estão disponíveis os seguintes:
1. IIS – Internet Information Server
2. LDAP – Lightweight Directory Access Protocol
3. NDS – Novel Directory Services
4. WinNT – Para acesso ao diretório do Windows NT 4.0.

NOTA
Para que o programador possa utilizar de maneira eficiente estas classes, um bom conhecimento do diretório em questão é exigido.
♦ System.Drawing: Um conjunto de classes com funções gráficas da biblioteca gráfica do Frame-

work .NET, a qual é conhecida como GDI+ (bem que poderia ser GDI.NET). Fornece métodos
para desenhar elementos básicos no vídeo, como por exemplo retângulos, círculos, uma linha
reta, um ponto, etc.
♦ System.Globalization: Este namespace contém o conjunto de classes com as funcionalidades
necessárias para a construção de aplicações com suporte a diferentes idiomas.
♦ System.IO: Um conjunto de classes com suporte a leitura e escrita, síncrona e assíncrona para
stream de dados e arquivos em disco.
♦ System.Messaging: Contém um conjunto de classes para habilitar os programas .NET a trabalhar
com filas, enviar mensagens para uma fila, ler mensagens de uma fila, etc. No Windows NT 4.0
tínhamos o MSMQ – Microsoft Message Queue – que atuava como servidor, disponibilizando
serviços de filas para aplicações COM.
♦ System.Net: Disponibiliza uma interface de programação bastante fácil de utilizar, a qual nos
dá acesso para a grande maioria dos protocolos disponíveis na Internet.
♦ System.Security: Um conjunto de classes com métodos para a definição das configurações

básicas de segurança para aplicações .NET.
♦ System.Security.Cryptography: Disponibiliza serviços de criptografia, incluindo codificação
e decodificação de dados, hashing, geração de números aleatórios e autenticação de mensagens.
♦ System.Web: Contém uma série de classes e interfaces para a comunicação browser/servidor

web. Por exemplo, existe uma classe chamada HTTPRequest, a qual disponibiliza uma série de
informações a respeito da requisição HTTP feita pelo cliente. Existem outros namespaces,
herdados de System.Web, como por exemplo: System.Web.Caching, System.Web.Configuration,
System.Web.Hosting, System.Web.Mail, System.Web.SessionState, etc.
♦ System.Windows.Forms: Contém classes para a criação de aplicações Win32, as quais podem

ter acesso a todos os elementos da interface do Windows, como por exemplo botões, menus,
barras de rolagem, etc. Neste namespace encontraremos uma classe chamada Form além de
muitos outros controles que podem ser utilizados para a criação da interface do usuário.
♦ System.XML: É o namespace que contém as classes que dão suporte ao padrão XML.
Apresentamos apenas uma descrição básica dos principais namespaces do Framework .NET. Livros
inteiros podem ser escritos sobre um único namespace como por exemplo System.Net ou
System.Security. A melhor fonte de consulta para as classes, métodos e propriedades de um namespace
é a própria documentação do Visual Studio .NET.
Agora vamos fazer uma revisão dos principais conceitos de Orientação a Objetos. É importante a
revisão destes conceitos uma vez que a linguagem C# e todo o Framework .NET são baseados nos
conceitos de Orientação a Objetos.
DESENVOLVIMENTO EM: CONCEITOS BÁSICOS DE ORIENTAÇÃO A OBJETOS

PRÉ-REQUISITOS
METODOLOGIA
♦ Descrição dos princípios básicos de orientação a objetos.
Vamos fazer uma revisão dos principais conceitos de orientação a objetos. A orientação a objetos, quer
seja como metodologia de análise, projeto ou programação, foi criada com o objetivo de resolver
problemas que a programação estruturada não foi capaz. A orientação a objetos possui os seguintes
objetivos básicos:
♦ Produtividade.
♦ Incentivo a boas práticas de programação.
♦ Uma modelagem mais próxima do entendimento do usuário final.
♦ Reutilização de código.
♦ Facilidade de manutenção do código.
Embora a proposta de orientação a objetos seja bastante consistente, esta ainda não teve o nível de
implementação esperado. Não cabe aqui discutir os motivos que fizeram com que a velocidade de
adoção ficasse abaixo da esperada. Este fato é ainda mais interessante, uma vez que a grande maioria
das empresas admite que a orientação a objetos oferece uma série de vantagens em relação ao modelo
de programação estruturada. Porém a mudança para um novo modelo envolve uma nova maneira de
pensar, uma necessidade de treinamento e, principalmente, uma mudança cultural. Esta última sem
sombra de dúvidas a mudança mais difícil.
Vamos revisar os seguintes conceitos básicos:
♦ O que é um objeto?
♦ Mensagens
♦ Classes
♦ Herança
♦ Instâncias
♦ Reutilização de código
O QUE É UM OBJETO?
Na programação estruturada nós temos uma separação entre procedimentos e os dados sobre os quais os
procedimentos atuam. Um procedimento pode ser uma função que retorna um valor ou uma procedure
que realiza uma série de operações, podendo ou não retornar um valor. Porém este modelo apresenta
sérias dificuldades do ponto de vista do usuário. Ao fazer a análise e projeto de um programa, o analista
precisa traduzir as necessidades dos usuários em termos de procedimentos, funções, módulos, etc. Existe
uma diferença muito grande entre a linguagem dos usuários e a linguagem dos analistas/programadores.
Um objeto é uma entidade que contém, além dos dados, todas as funções que atuam sobre estes dados.
Ou seja, um objeto é composto dos dados que descrevem o objeto (propriedades) e das operações que
podem ser realizadas sobre estes dados (métodos). Esta abordagem já é um pouco mais próxima da
abordagem entendida pelos usuários finais do sistema. Vamos imaginar um sistema para o departamento
de recursos humanos. Os usuários falam em termos de empregados, cargos, etc. Poderíamos ter um
objeto chamado Funcionário. Este objeto poderia conter diversas propriedades, tais como:
♦ Matrícula
♦ Nome
♦ Endereço
♦ Fone
♦ Data de Admissão
♦ Data de Aniversário
♦ Nome do Pai
♦ Nome da Mãe
♦ Número da Identidade
♦ Número do CPF
♦ Cargo
♦ Salário
Com isso podemos observar que as propriedades descrevem as características de um determinado

objeto. O conjunto de valores contidos nas propriedades de um determinado objeto define o seu
estado atual.
Além das propriedades o objeto pode conter métodos. Os métodos descrevem ações que podem ser
realizadas pelo objeto ou no objeto. Por exemplo, o nosso objeto funcionário poderia ter um método
chamado pagamento, outro chamado transferência, mais um chamado promoção e assim por diante.
Um método, na prática é uma função ou procedimento que realiza uma determinada ação. Os métodos
de um objeto podem receber parâmetros e ter o seu comportamento alterado, dependendo do valor
dos parâmetros recebidos. Por exemplo, o método Promoção, de um objeto funcionário, pode receber,
como parâmetros, a matrícula do funcionário, a data da promoção e o código do novo cargo. Dentro
do método Promoção pode ser chamado um método AtualizaSalário, o qual atualiza o valor do salário
do funcionário, de acordo com o novo cargo que o funcionário irá ocupar.
Na Figura 13.19 temos uma representação do objeto Funcionário.
FUNCIONÁRIO
Propriedades Métodos
Representam as
Representam as ações.
características do objeto.
Figura 13.19 Objeto Funcionário – métodos e propriedades.
MENSAGENS
Os objetos se comunicam através de um mecanismo de troca de mensagens. Mensagens é um mecanismo
de comunicação entre objetos através do qual se desencadeia a execução de um método específico.
Através do mecanismos de troca de mensagens um objeto pode invocar métodos de outros objetos e
receber os resultados da execução do método invocado.
No desenvolvimento baseado em padrões tais como COM/COM+, existem métodos proprietários para
troca de mensagens. Além disso, cada linguagem de programação possui um conjunto distinto de
tipos de dados. Desta maneira a troca de mensagens entre objetos criados em diferentes linguagens
não é uma tarefa simples, fato este já bastante salientado anteriormente. Já no Framework .NET existe
um sistema de tipos comuns a todas as linguagens: CTS – Common Type System. A existência do CTS
facilita, enormemente, a interação entre objetos criados em diferentes linguagens. Outra vantagem do
Framework .NET é que ele utiliza um sistema para troca de mensagens, baseado no padrão XML e no
protocolo SOAP, ambos adotados como um padrão de fato pela indústria de TI.
Outro termo relacionado com orientações a objetos é instância. Quando um programa carrega um
determinado objeto na memória, dizemos que foi feita uma instância do objeto. Ao carregar na memória
estamos reservando recursos para armazenar as características do objeto – através da definição dos
valores de suas propriedades e também recursos para que os métodos do objeto possam ser executados.
CLASSES
Se pesquisarmos a bibliografia sobre orientação a objetos encontraremos um sem-fim de definições
para classes. Vamos inicialmente apresentar algumas das definições formais encontradas na bibliografia.
Depois vamos a uma, digamos, explicação “menos formal”:
♦ Classes constituem modelos que são utilizados para a criação de objetos. Nas classes são descritos
a estrutura de dados (através das propriedades) e o comportamento (através de seus métodos)
de um ou mais objetos similares que possuem seus dados estruturados da mesma forma e são
manipulados pelos mesmos métodos.
♦ Um objeto é uma instância de uma classe que é criada em tempo de execução. Classes são
puramente uma descrição estática de um conjunto de possíveis objetos.
Na prática, o que significa, por exemplo, termos uma classe chamada Funcionários? Esta classe serve
como modelo para a criação de objetos do tipo Funcionário. Na classe Funcionários estão as definições
das propriedades e dos métodos para um objeto Funcionário. Ou seja, sempre que criarmos um objeto
do tipo funcionário este será criado com todas as propriedades e métodos da classe Funcionários ou
como preferem os puristas“ herdando as propriedades e métodos da classe Funcionários”.
Como eu sou apaixonado por definições simples e sem meias-palavras, adorei esta definição que
encontrei na Internet: “Classe é uma forma para fazer objetos”. Acho que essa frase resume tudo.
Grande parte da funcionalidade do Framework .NET é fornecida por um grande número de classes, as
quais fazem parta de “.NET Framework Class Library”, já descrita anteriormente. O Framework .NET
agrupa as classes de acordo com suas funcionalidades. Um agrupamento de classes criadas para um
determinado fim é também conhecido como um namespace (espaço de nomes). Por exemplo, temos o
namespace System.Data. Dentro deste namespace existem várias classes que fornecem os métodos
necessários para a conexão e manipulação de fontes variadas de dados. Existem classes para a conexão
com o SQL Server, outras para a conexão com fontes ODBC e assim por diante. A biblioteca de classes
do Framework .NET é organizada de uma forma hierárquica, onde as classes de níveis inferiores herdam
todas as características da classe mãe. Falaremos mais sobre herança no próximo item.
NOTA
Na linguagem C# tudo (ou quase tudo como preferem alguns) são classes. Até para criar um simples programa como o Hello Word apresentado
anteriormente e exibido novamente na Listagem 25.2, é criada uma classe. Observe a palavra “class” na segunda linha do exemplo.
Listagem 13.2 – Hello Word !

using System;
class primeiroprograma
{
// Meu primeiro programa em C#
// O tradicional Hello Word !!
public static void Main()
{
string umamensagem = “Hello Word !!!”;
Console.WriteLine(umamensagem);
}
}
HERANÇA
“É o mecanismo que permite definir uma nova classe a partir de uma classe já existente. A classe que
está sendo criada é dita subclasse ou classe filha da classe já existente. Em contrapartida a classe já
existente é chamada de superclasse da classe que está sendo criada. A subclasse herda a estrutura de
dados e os métodos da superclasse, podendo adicionar variáveis na estrutura de dados herdada, bem
como adicionar novos métodos e reescrever métodos herdados.
Uma classe pode possuir uma única superclasse – herança simples, ou pode conter mais do que uma
superclasse – herança múltipla. A herança múltipla tem sido alvo de muitas discussões e controvérsias.
A única linguagem, do Framework .NET, que implementa diretamente a herança múltipla é o C++. A
grande discussão em torno da herança múltipla tem a ver com a relação custo x benefício, uma vez que
esta é de difícil implementação e concepção, embora os benefícios nem sempre sejam os esperados.
Herança é um conceito fundamental para a orientação a objetos. Através do mecanismo de herança

podemos criar uma classe baseada em outra já existente. A nova classe que está sendo criada “herda”
todas as propriedades e métodos da classe base, também chamada de classe mãe ou superclasse conforme
descrito anteriormente. A herança evita que as propriedades e métodos da classe mãe tenham que ser
redefinidos na classe filho, embora a classe filho ou subclasse possa redefinir os métodos da classe mãe,
através de um mecanismo conhecido como Overwrite.
Para ilustrar o mecanismo de herança vamos a um exemplo prático. Vamos imaginar que você esteja
projetando um programa de controle de vendas, baseado na orientação a objetos. Uma das prováveis
classes seria a classe Clientes. Nesta classe poderíamos definir as características e métodos básicos para
um cliente típico.
Para a classe Clientes poderíamos definir as seguintes propriedades:
♦ Nome
♦ CPF
♦ RG
♦ Identidade
♦ Endereço
♦ Cidade
♦ CEP
♦ Fone
♦ E-mail
Para a classe Clientes poderíamos definir os seguintes métodos:
♦ Cadastrar
♦ Excluir
♦ Atualizar
Observe que a nossa classe Clientes possui apenas as propriedades e métodos comuns a qualquer
cliente, quer seja um grande cliente ou um pequeno correntista. Este é um dos princípios da utilização
de classes: Nas classes de primeiro nível definimos apenas as propriedades e métodos comuns, os quais
deverão ser utilizados pelas classes dos demais níveis.
Clientes
Nome Cadastrar
CPF Excluir
RG Atualizar
Identidade
Endereço
Cidade
CEP
Fone
E-mail
Figura 13.20 A classe Clientes.
Na Figura 13.20 temos uma visão geral da classe Clientes.
Continuando o nosso exemplo, o banco tem clientes com características diferenciadas. Por exemplo:
♦ Correntistas
♦ Contas de poupança
♦ Empréstimos pessoais
♦ Financiamentos habitacionais
Cada um destes tipos de clientes possui propriedades e relações diferenciadas com o banco. Por isso
precisamos de objetos que representem estas diferenças. A primeira sugestão seria criar uma classe para
cada tipo de cliente. A título de exemplo poderíamos criar as seguintes classes:
♦ ClienteCorrentista
♦ ClientePoupança
♦ ClienteEmpréstimo
♦ ClienteHabitacional
Ao criar a classe ClienteCorrentista podemos criá-la como uma subclasse da classe Clientes. Com isso
a classe ClienteCorrentista herda todas as propriedades e métodos da classe pai – Clientes. Somente
precisaremos implementar as propriedades e métodos que são específicas da subclasse ClienteCorrentista.
A título de exemplo vamos definir algumas propriedades e métodos da classe ClienteCorrentista.
Para a classe ClienteCorrentista poderíamos definir as seguintes propriedades:
♦ NumConta
♦ NumAgência
♦ Limite
♦ Categoria
Para a classe ClienteCorrentista poderíamos definir os seguintes métodos:
♦ DefinirLimite
♦ AumentarLimite
♦ BloquearConta
♦ LiberarConta
Juntando as propriedades que foram herdadas da classe pai – Clientes, a classe ClienteCorrentista teria
as seguintes propriedades:
♦ Nome (herdada da classe pai)
♦ CPF (herdada da classe pai)
♦ RG (herdada da classe pai)
♦ Identidade (herdada da classe pai)
♦ Endereço (herdada da classe pai)
♦ Cidade (herdada da classe pai)
♦ CEP (herdada da classe pai)
♦ Fone (herdada da classe pai)
♦ E-mail (herdada da classe pai)
♦ NumConta
♦ NumAgência
♦ Limite
♦ Categoria
Juntando os métodos que foram herdados da classe pai – Clientes, a classe ClienteCorrentista teria os
seguintes métodos:
♦ Cadastrar (herdada da classe pai)
♦ Excluir (herdada da classe pai)
♦ Atualizar (herdada da classe pai)
♦ DefinirLimite
♦ AumentarLimite
♦ BloquearConta
♦ LiberarConta
Na Figura 13.21 temos uma visão geral da classe ClienteCorrentista, já incluindo as propriedades e
métodos herdados da classe pai – Clientes..
O mesmo raciocínio também é válido para a criação das classes ClientePoupança, ClienteEmpréstimo
e ClienteHabitacional, como subclasses da classe pai Clientes.
Caso haja necessidade, uma subclasse pode sobrescrever um método herdado da classe pai. Por exemplo, a
subclasse ClienteCorrentista poderia sobrescrever o método Cadastrar da classe pai – Clientes. Isso pode ser
feito para que sejam atendidas necessidades específicas do cadastramento de um cliente correntista. As
linguagens do Framework .NET suportam esta técnica, a qual também é conhecida como Overwrite.
Após termos criado as demais classes do nosso exemplo, estaremos com a hierarquia de classes ilustrada
na Figura 13.22.
Conforme descrevemos anteriormente, uma hierarquia de classes também pode ser chamada de
namespace ou “espaço de nomes”. Também já descrevemos antes que “.NET Framework Class Library”
é, na verdade, um grande número de namespaces, cada um com funcionalidades específicas,
funcionalidades estas disponibilizadas por um grande número de classes dentro de cada um dos
namespaces. Também gostaria de reforçar que este é um dos grandes atrativos do .NET, ou seja, oferecer
uma infinidade de classes, as quais facilitam muito o desenvolvimento das aplicações e, ainda por
cima, classes estas que podem ser acessadas a partir de qualquer linguagem do Framework .NET.
ClienteCorrentista
Nome Cadastrar
CPF Excluir
RG Atualizar
Identidade DefinirLimite
Endereço AumentarLimite
Cidade BloquearConta
CEP LiberarConta
Fone
E-mail
NumConta
NumAgência
Limite
Categoria
Figura 13.21 A classe Clientes.
Clientes
ClienteCorrentista ClienteCorrentista ClienteCorrentista ClienteEmpréstimos
Figura 13.22 Uma hierarquia de classes.
REUTILIZAÇÃO DE CÓDIGO
Ao utilizar uma das classes do Framework .NET qual o princípio de orientação a objetos que estamos
utilizando? Herança. Certo. Mas não era bem deste princípio que eu gostaria de tratar. Então vamos
colocar as coisas de uma maneira um pouco diferente: “Ao utilizarmos a herança, qual o princípio de
orientação a objetos que estamos utilizando? Reutilização ou reaproveitamento de código ou, de uma
maneira mais “chique”: Reusabilidade.
Ao invés de termos que implementar a funcionalidade de determinada classe, em cada programa onde
a funcionalidade for necessária, simplesmente criamos uma classe que herda estas funcionalidades, já
prontas, de uma classe do Framework .NET. Com isso reutilizamos o código já desenvolvido. Isso
poupa trabalho e facilita o desenvolvimento das aplicações. Melhor ainda. Vamos imaginar que tenha
sido descoberto um pequeno “bug” em um método de uma determinada classe. Ao corrigirmos este
“bug” na classe em questão, todos os programas que utilizam a classe passarão a ter acesso às
modificações, ou seja, irão herdar as alterações. Isso facilita, enormemente, a manutenção e alteração
das aplicações. Mas era de esperarmos tal comportamento, uma vez que reutilização de código, herança
e facilidade de manutenção dos programas são alguns dos princípios básicos da orientação a objetos.
Em uma empresa, a equipe de desenvolvimento pode criar classes básicas, as quais podem ser utilizadas
em diversos programas da empresa. Sempre que forem feitas alterações nas classes básicas, as alterações
serão herdadas por todos os programas que utilizam as classes básicas. Vejam que este cenário é muito
diferente do que acontece, na prática, hoje. Muitas vezes cada projeto de desenvolvimento parte do
zero, sem que nada seja reaproveitado de projetos anteriores. Com isso uma série de funcionalidades
básicas precisa ser reescrita a cada novo projeto. Desta forma temos projetos mais longos, com maior
custo e que muito raramente são concluídos no prazo.
Todos os conceitos apresentados, para o desenvolvimento de aplicações no Windows Server 2003, são baseados no Framework .NET. Em
NOTA
versões anteriores do Windows, o Framework .NET era um componente separado, o qual você deveria copiar do site da Microsoft e instalar.
Ou, se você instalasse o Visual Studio .NET, o Framework .NET seria automaticamente instalado a partir da mídia de instalação do Visual
Studio .NET. Ao instalar o Windows Server 2003, o Framework .NET é automaticamente instalado. Ao instalar o SQL Server 2005, o Frame-
work .NET será atualizado, caso a versão atual seja mais antiga do que a versão do Framework .NET que faz parte do SQL Server 2005.
Com o Windows Server 2003, o Framework .NET faz parte do sistema operacional. Ele já é instalado
por padrão, durante a instalação do Windows Server 2003. Você poderá configurar algumas opções do
Framework .NET, usando uma das seguintes ferramentas:
♦ Start -> Administrative Tools -> Microsoft .NET Framework 1.1 Configuration
♦ Start -> Administrative Tools -> Microsoft .NET Framework 1.1 Wizards.
A documentação do Framework .NET pode ser acessada no seguinte caminho:

C:\WINDOWS\Microsoft.NET\Framework\1033\Admim.chm
E na Internet você encontra a documentação completa do Framework .NET, no endereço a seguir:

http://msdn.microsoft.com/library/en-us/dnanchor/html/netdevanchor.asp
NOTA
Importante: Ao instalar o Visual Studio .NET, será instalada a documentação completa do Framework .NET, localmente, sem necessidade de
acesso à Internet. No Capítulo 15 você aprenderá a instalar o Visual Studio .NET 2005, passo a passo e a utilizá-lo para criar funções e
procedimentos que serão utilizados pelo SQL Server 2005.
DESENVOLVIMENTO EM: UMA RÁPIDA INTRODUÇÃO

À TECNOLOGIA ASP.NET
PRÉ-REQUISITOS
♦ Configurações básicas do IIS e modelos de aplicações Web.
METODOLOGIA
♦ Apresentação da tecnologia ASP.NET.
TÉCNICA
♦ Exemplos práticos, passo a passo.
Neste tópico apresentarei uma rápida introdução à tecnologia ASP.NET. Mostrarei o que é o ASP.NET e dois
exemplos bem simples. No próximo tópico, veremos mais alguns exemplos, avançados, sobre a conexão de
páginas ASP.NET, com Bancos de Dados SQL Server 2005. Os exemplos deste capítulo serão colocados na
pasta C:\LivroSQL2005\Capitulo13. Para acompanhar os exemplos, basta você criar a pasta Capitulo13,
dentro da pasta C:\LivroSQL2005, já criada no Capítulo 11. Como ao pasta C:\LivroSQL2005\ já é um
diretório virtual do IIS (configuração esta que foi feita no Capítulo 11), a criar uma pasta Capitulo13,
dentro da pasta C:\LivroSQL2005\Capitulo13, a pasta Capitulo13 já passa a estar acessível a partir do
seguinte endereço: http://localhost/livrosql2005/capitulo13. Se você criar um página teste.aspx, dentro da
pasta Capitulo13, para acessá-la, basta usar o seguinte endereço: http://localhost/livrosql2005/capitulo13/
teste.aspx. Os exemplos que utilizarei neste tópico. serão todos salvos na pasta Capitulo13.
MAIS UMA VERSÃO DE ASP

ASP, ASP 2.0, ASP 3.0 e agora ASP.NET.
Menos de dois anos após o lançamento do ASP 3.0, o qual faz parte do IIS 5.0 que é instalado com o
Windows 2000 Server e também tem suporte no IIS 6.0, a Microsoft lança mais uma versão da tecnologia
ASP – Active Server Pages. Na verdade não é apenas o lançamento de mais uma versão. O ASP.NET está
inserido em um contexto maior, que é a iniciativa .NET da Microsoft, mais conhecida como Frame-
work .NET, tecnologia esta que foi detalhadamente descrita neste capítulo. Além de estar inserido no
contexto do .NET, a tecnologia ASP.NET apresenta “enormes” diferenças em relação ao ASP 3.0, o que
não permite que a caracterizemos simplesmente como um upgrade do ASP 3.0.
A tecnologia ASP.NET segue os mesmos princípios do Framework .NET, cujo principal objetivo é facilitar
o desenvolvimento de aplicações. No caso específico do ASP.NET, aplicações Web. Com o uso do ASP.NET
as aplicações Web passam a usufruir de todos os recursos do Framework .NET.
A tecnologia ASP teve uma enorme aceitação por parte da comunidade de desenvolvedores. Para
comprovar tal afirmação basta conferir o número de sites que utilizam ASP. Esta aceitação não se deve
somente à força de mercado da Microsoft, mas também à facilidade de desenvolvimento propiciada
pela utilização de ASP.
NOVIDADES E MELHORIAS DO ASP.NET

Neste item vamos apresentar as novidades e vantagens do ASP.NET. Mais do que uma simples
justificativa para uma nova versão, procuro demonstrar os benefícios de utilizarmos ASP.NET para a
criação de aplicações WEB.
FAZ PARTE DO FRAMEWORK .NET.

Pode parecer óbvio, mas nunca é demais salientar este aspecto. ASP.NET é parte integrante do Frame-
work .NET, e desta maneira tem acesso a todos os benefícios da plataforma .NET da Microsoft (veja o
início do capítulo para detalhes sobre o Framework .NET).
Em uma página ASP.NET temos acesso a todas as classes da biblioteca de classes do Framework .NET –
.NET Framework Class Library. Também temos acesso a um tipo comum de dados e a todos os benefícios
do Framework .NET. Só estes benefícios já justificam uma migração do ASP 3.0 para o ASP.NET.
SUPORTE A MÚLTIPLAS LINGUAGENS

Com as versões anteriores do ASP estávamos limitados praticamente a duas linguagens de script: VBScript
e JScript. Além disso, por serem linguagens de script estas eram interpretadas, ou seja, ao carregar uma
página ASP, o IIS precisa ler linha por linha de código, interpretar e executar.
NOTA
Para detalhes sobre a criação de páginas ASP para acessar dados do SQL Server 2005, consulte o Capítulo 11.
Com ASP.NET podemos utilizar qualquer linguagem que esteja habilitada para o Framework .NET.
Inicialmente são disponibilizadas as linguagens VB.NET, C# e Jscript.NET. Apesar do nome JScript, esta
e as demais linguagens são compiladas, o que significa que toda página ASP.NET é compilada no
servidor, antes de ser executada e o seu resultado retornado para o cliente. A primeira vez que uma
página ASP.NET é acessada, ela é compilada em uma classe do Framework .NET. A versão compilada é
mantida em cache no servidor, para melhorar o desempenho para os próximos acessos. Qualquer
alteração na página é automaticamente detectada pelo Framework .NET; a página é recompilada e a
versão em cache é atualizada, fazendo com que o cliente tenha sempre acesso à versão mais atualizada
da página. Se não houver mudanças, continuará sendo utilizada a versão que está no cache, o que
torna a carga da página muito mais rápida.
Além disso diversas empresas de software já anunciaram que estão portando suas linguagens para que
sejam compatíveis com o Framework .NET. Desta maneira você poderá utilizar, para a criação de páginas
ASP.NET, a linguagem com a qual está mais familiarizado, desde que ela esteja habilitada ao .NET. Você
prefere Delphi? Sem problemas. É fã do COBOL? Por que não?
MENOS CÓDIGO PARA MAIS TRABALHO

Com o ASP.NET temos acesso a uma série de facilidades que diminuem a quantidade de código que o
programador precisa escrever, principalmente no trato com funções básicas. Estas funções básicas,
como a manutenção de estado entre chamadas de uma página, são responsabilidade do Framework
.NET. Isso faz com que o programador tenha que desenvolver apenas a lógica da aplicação, sem ter que
se preocupar com aspectos básicos da infra-estrutura necessária ao funcionamento da aplicação Web.
Uma série de controles mais inteligentes e com melhores funcionalidades foi criada, os chamados
Server controls. Estes controles fornecem grande funcionalidade com um mínimo de programação.
Alguns artigos fazem referência a “inteligência” dos Server controls. Um dos aspectos considerados
inteligentes é que, no momento da carga da página, o controle detecta, por exemplo, se o navegador
do cliente é o Internet Explorer ou o Netscape Navigator e adapta o seu comportamento e exibição de
acordo com o navegador do cliente.
Com ASP tarefas simples, como por exemplo validar os dados digitados em um formulário, exigem a
criação de código específico. Com os controles “inteligentes” do ASP.NET, fazer a validação é
simplesmente questão de configurar algumas propriedades do controle e pronto, a verificação será
feita no momento em que a página for acessada.
NOTA
Para um estudo completo sobre os novos controles do ASP.NET, consulte o seguinte e-book de minha autoria: “Programação ASP.NET Com
C#”, disponível para venda em http://www.juliobattisti.com.br/ebooksdoautor
SEPARAÇÃO ENTRE O CÓDIGO HTML E O CÓDIGO ASP

Esta é uma das melhorias que eu mais aprecio. Com ASP 3.0 ou versões anteriores, nós tínhamos uma
mistura (literalmente) entre o código ASP e o código HTML, o que torna o código de difícil leitura e
documentação. Apenas para exemplificar, vamos apresentar uma página ASP que faz conexão com um
Banco de Dados do Microsoft Access e exibe todos os registros de uma determinada tabela do Banco de
Dados. Os registros são exibidos na forma de uma tabela. O código HTML para a criação da tabela, que
será exibida para o usuário, é gerado a partir de uma mescla entre código ASP e código HTML.
Na Listagem 13.3 temos um exemplo de página ASP que faz conexão com um Banco de Dados do
Microsoft Access. Para detalhes sobre os comandos deste exemplo, consulte o Capítulo 11.
Listagem 13.3 – Uma página ASP – código ASP e HTML “misturado”.
<%@ Language=VBScript %>

<HTML>
<HEAD>
<TITLE>Listagem de Clientes</TITLE>
</HEAD>
<BODY>
<H1>
<FONT color=navy>Clientes da Empresa ABC LTDA.</FONT>
</H1>
<%
‘O Primeiro passo é criar a conexão com o Banco de dados
‘Para isto crio um objeto do tipo Connection
‘Cria um Objeto do Tipo ADODB.Connection
‘ Agora abro uma conexão utilizando OLE-DB
‘ O código a seguir aparece em duas linhas por questão de espaço, porém o código
‘ deve ser digitado em uma única linha.
conn.Open “PROVIDER=MICROSOFT.JET.OLEDB.4.0;DATA SOURCE=c:\meus documentos\nwind.mdb”

‘ O próximo passo é criar uma instrução SQL
‘ a qual é utilizada para criar a listagem de Clientes.
‘ O código a seguir aparece em duas linhas por questão de espaço, porém o código
‘ deve ser digitado em uma única linha.
inst_sql=”SELECT Clientes.CodigoCliente, Clientes.Cargo, Clientes.Endereco,Clientes.Fone FROM
Clientes”
‘Esta instrução SQL retorna os campos CodigoCliente, Cargo,
‘Endereco e Fone, da tabela Clientes.
‘Agora criamos um Objeto RecordSet.
‘Este Objeto irá executar a instrução SQL e
‘receber o resultado da Consulta.
‘Agora executamos a Instrução SQL
‘retornando os registros da tabela Clientes.
‘ Neste ponto já tenho todos os registros retornados
‘ pela instrução SQL. Estes registros estão armazenados
‘ no objeto Clientes, que é um objeto do tipo Recordset.
‘ Agora passo a montar a página que será retornada para o
‘ Navegador do Cliente. Vamos montar uma tabela com o
‘ resultado da consulta.
%>
<P>
<HR>
<TABLE bgColor=gray border=1 borderColor=navy cellPadding=1 cellSpacing=1
width=”100%”>
<TR>
<TD align=middle bgColor=gray>Código</TD>
<TD align=middle bgColor=gray>Cargo</TD>
<TD align=middle bgColor=gray>Endereço</TD>
<TD align=middle bgColor=gray>Fone</TD>
</TR>
<%
‘ Inicio um Loop para percorrer todos os registros
‘ do RecordSet Clientes, exibindo um Registro em
‘ cada Linha da tabela.
Do Until Clientes.eof %>
<TR>
<TD align=middle bgColor=gray><%=Clientes.Fields(“CodigoCliente”)%></TD>
<TD align=middle bgColor=gray><%=Clientes.Fields(“Cargo”)%></TD>
<TD align=middle bgColor=gray><%=Clientes.Fields(“Endereco”)%></TD>
<TD align=middle bgColor=gray><%=Clientes.Fields(“Fone”)%></TD>
</TR>
<%
Clientes.MoveNext
loop %>
</TABLE>
</P>
<HR>
</BODY>
</HTML>
Na Figura 13.23 temos esta página carregada no IE – Internet Explorer.
Observe que, por mais organizados que sejamos, inserindo comentários e endentações no código, não
é nada fácil a leitura e interpretação de uma página ASP. Isso acontece devido, principalmente, à
intercalação de código ASP e código HTML. Em uma mesma página ASP posso ter várias seções de
código ASP. Cada seção inicia com <% e encerra com %>. Tudo o que não estiver entre estes dois
marcadores é código HTML.
Já com ASP.NET isto não acontece. A parte de apresentação da página é separada da parte de
processamento, isto é, da parte onde está o código responsável pela lógica de processamento
da página. Com isto estamos separando a lógica da apresentação, o que facilita a manutenção
das páginas.
Na Listagem 13.4 temos o exemplo de uma página ASP.NET que faz a separação entre o código
responsável pela conexão com o Banco de Dados e retorno dos dados (lógica) e o código responsável
por exibir os dados (apresentação). Na parte final deste capítulo, você aprenderá mais detalhes sobre os
comandos e objetos do ASP.NET, utilizados para conexão com dados do SQL Server 2005.
Figura 13.23 Página ASP de exemplo.
Listagem 13.4 – O segundo exemplo: conectando com o Banco de Dados pubs, de uma instância do SQL Server 2005, usando ASP.NET –
<%@ Import Namespace=”System.Data” %>
<%@ Import Namespace=”System.Data.SqlClient” %>
<html>
<script language=”C#” runat=”server”>
protected void Page_Load(Object Src, EventArgs E )
{
// Crio uma conexão com o Banco de Dados pubs localizado no servidor local.
// Vamos acessar a instância SERVIDOR\SQL2005.
SqlConnection myConnection = new SqlConnection(“server=SERVIDOR\\SQL2005;” +
“ uid=sa;pwd=abc123;database=pubs”);
// Conectamos com o Banco de Dados utilizando um comando SQL,
// o qual retorna todos os dados da tabela “Authors”, do banco de
// dados pubs.
SqlDataAdapter myCommand = new SqlDataAdapter(“SELECT “ * FROM Authors”; myConnection);
// Criamos e preenchemos um objeto DataSet.
// Observe que não temos mais o objeto Recordset,
// como era de praxe com o ASP 3.0.
DataSet ds = new DataSet();
myCommand.Fill(ds);
// Conectamos um controle DataGrid com o DataSet criado anteriormente.
// MyDataGrid é o id (nome) de um controle do tipo
// DataGrid que está na seção de apresentação da página.
DataView source = new DataView(ds.Tables[0]);
MyDataGrid.DataSource = source ;
MyDataGrid.DataBind();
}
</script>
<body>
<%— Exibe as informações do DataGrid no corpo da página. —%>
<h3><font face=”Verdana”>Registros da tabela Authors!</font></h3>
<%— Os registros da tabela Authors são exibidos no DataGrid. —%>
<ASP:DataGrid id=”MyDataGrid” runat=”server”
Width=”700"
BackColor=”#ccccff”
BorderColor=”black”
ShowFooter=”false”
CellPadding=3
CellSpacing=”0"
Font-Name=”Verdana”
Font-Size=”8pt”
HeaderStyle-BackColor=”#aaaadd”
MaintainState=”false”
/>
</body>
</html>
Ao carregarmos esta página no Internet Explorer obtemos o resultado indicado na Figura 13.24:
Figura 13.24 A página ASP.NET da Listagem 2 carregada no IE.
Observe a separação entre a seção de código e a seção de apresentação, conforme detalharemos a seguir.
Alguns comentários sobre o exemplo, sem entrar em maiores detalhes sobre o código do exemplo.
♦ Cadê o meu objeto RecordSet usado no ASP?
Nada de objetos do tipo RecordSet. Com ASP.NET utilizamos ADO.NET para fazer a conexão com
Banco de Dados. ADO.NET utiliza o objeto Dataset ao invés do objeto RecordSet. Para a conexão com
Bancos de Dados utilizamos uma série de classes do namespace System.Data, o qual faz parte do .NET
Framework Class Library.
Para ter acesso às classes de um determinado namespace, precisamos adicionar uma referência ao
namespace, no início da página ASP.NET, utilizando a diretiva Import, conforme indicado no trecho
de código a seguir:
Observe que estamos fazendo referência a dois namespaces: System.Data e
System.Data.SqlCliente.
♦ Conectando com o Banco de Dados.
Na seção de código da página temos os comandos para conexão com o Banco de Dados pubs da
instância SERVIDOR\SQL2005 de um servidor com o SQL Server 2005. Um detalhe importante é a
maneira como informamos o nome da instância, conforme indicado pelo trecho de código a seguir:
Observe que utilizamos duas barras invertidas ao invés de uma única barra. Isto é necessário porque a
barra invertida é considerada um caractere de escape com significado especial para a linguagem C#
utilizada no exemplo da Listagem 2. Quando, ao invés do caractere de escape, queremos que o C# o
entenda como um caractere normal, temos que precedê-lo de uma barra invertida. Na prática as duas
barras invertidas são interpretadas, pelo C#, como uma única barra, o que produz o resultado desejado:
SERVIDOR\NETSDK.
Neste exemplo utilizamos as seguintes classes do namespace System.Data.SqlClient:
1. SqlConnection
2. SqlDataAdapter
Também utilizamos as seguintes classes do namespace System.Data:
1. DataSet
2. DataView
♦ Um controle poderoso para exibir os dados:
Na seção de apresentação utilizamos o controle DataGrid para fazer a exibição dos registros da tabela
Authors. Observe o quão poderoso é este controle. Simplesmente através da configuração da sua
propriedade DataSource, na seção de código, definimos os registros a serem exibidos pelo controle.
Esta definição é feita nas seguintes linhas de código:
MyDataGrid.DataSource = source ;
MyDataGrid.DataBind();
Veja que não precisamos utilizar um laço While para percorrer todos os registros da tabela Authors,
como tínhamos que fazer com o objeto RecordSet usando ASP, como no exemplo da Listagem 1.
♦ Posso ter um comando que ultrapassa uma linha?
A resposta é um sonoro Sim.
Diferente do ASP 3.0, em nossas páginas ASP.NET, os comandos da seção de código podem estar em
mais do que uma linha, sem problemas. Inclusive na Listagem 2 temos comandos que ultrapassam
uma linha e a página carrega sem maiores problemas, conforme exemplificado no trecho a seguir:
SqlDataAdapter myCommand = new SqlDataAdapter(“SELECT “ +
“ * FROM Authors”; myConnection);
Isso é possível pois cada comando do C# é finalizado com um ponto-e-vírgula (;).
♦ O bom e velho SQL continua o mesmo?
A resposta é outro sonoro Sim.
Você deve ter observado que utilizamos um comando SQL para retornar os dados da tabela authors.
Utilizamos um comando SELECT, conforme indicado a seguir:
Vamos alterar o comando SQL para introduzir uma condição. Queremos que sejam retornados somente
os registros para os autores em que a cidade (city) é Oakland. Para isso basta que seja utilizada uma
cláusula where para especificar a condição city=’Oakland’, conforme indicado a seguir:
SqlDataAdapter myCommand = new SqlDataAdapter(“SELECT “ +
“ * FROM Authors where city=’Oakland’”; myConnection);
Fazendo esta alteração obteremos o resultado indicado na Figura 13.25.
Figura 13.25 Definindo um critério com a cláusula where.
COMPATIBILIDADE COM QUALQUER NAVEGADOR

O resultado da execução de uma página ASP.NET é código HTML retornado para o cliente. Qualquer
navegador é capaz de interpretar corretamente HTML, em tese. Na prática o que acontece é que existem
pequenas diferenças e até mesmo “inconsistências” entre a maneira como o código HTML é interpretado.
Para minimizar este problema, o ASP.NET conta com os controles que rodam no servidor e são capazes
de fornecer diferente saídas, dependendo do navegador que fez a solicitação da página. Na prática isto
significa que um controle da interface de uma página ASP.NET, que roda no servidor, é capaz de gerar
diferentes saídas, dependendo do navegador do cliente. Esta característica é conhecida por AUI –
Adaptative User Interface.
A EXTENSÃO DO ARQUIVO MUDOU .ASPX

A primeira diferença que notamos é na extensão dos arquivos. As páginas ASP, desde a versão inicial
até a versão 3.0, têm a extensão .asp. Esta extensão é obrigatória, para que o IIS reconheça a página
como uma página ASP e passe o processamento para o interpretador ASP (ASP.DLL). Já as páginas
ASP.NET têm a extensão .aspx, a qual é reconhecida pelo IIS (após a instalação do Framework .NET). O
processamento da página ASP.NET é passada para o controle do Framework .NET. O serviço responsável
pelo processamento das páginas ASP.NET está contido na DLL – XSPISAPI.DLL. No próximo tópico,
vamos estender um pouco mais o nosso estudo sobre a conexão de páginas ASP.NET com Bancos de
Dados do SQL Server 2005.
UM VISÃO GERAL DO ACESSO A DADOS

Existe uma frase que resume bem a necessidade de acesso a dados: “A informação certa, para a pessoa
certa, na quantidade certa e no momento certo”.
Esta frase apresenta alguns aspectos importantes:
♦ A informação certa: A informação deve estar correta, isto é, deve ser confiável. A informação
é utilizada para a tomada de decisões, nos mais variados níveis de uma empresa. Se a informação
estiver incorreta, as decisões serão equivocadas e não irão gerar os resultados esperados. Pior
do que não ter a informação é ter informação incorreta, não confiável.
♦ Para a pessoa certa: Independente do nível hierárquico, quer seja o operário da fábrica ou o
presidente da empresa, todos precisam de informação para trabalhar e alcançar os resultados
desejados. A informação correta precisa estar à disposição para as pessoas que dela necessitam.
♦ Na quantidade certa: Informação demais também é um problema e pode atrapalhar ao invés
de ajudar. E hoje as informações vêm das mais diversas fontes. Internet, e-mail, relatórios,
Banco de Dados da empresa, arquivos do Office, jornais, revistas, livros, manuais técnicos.
Precisamos garimpar as informações que realmente são necessárias ao nosso trabalho.
♦ No momento certo: Este é um aspecto fundamental. Lembro-me da época em que somente

tínhamos o mainframe e um “bando” de terminais espalhados pela empresa. Você
solicitava um novo relatório para a turma do CPD. Duas semanas depois vinha o relatório.
Hoje, evidentemente, esta situação é inaceitável. Precisamos da informação instantânea,
sempre à disposição.
Quando as empresas começaram a descentralizar seus ambientes computacionais, passando do modelo
Mainframe/Terminal para um modelo Cliente/Servidor com redes locais, novas possibilidades, e também
problemas, começaram a surgir. Bancos de dados departamentais não integrados, diferentes formatos
de dados, aplicações Cliente/Servidor rodando em cada estação de trabalho, etc., o que fez com que a
informação ficasse distribuída por toda a empresa e não mais centralizada no mainframe.
Um ambiente descentralizado é mais flexível, mas em contrapartida é mais difícil de gerenciar e de

manter o controle. à medida que o volume de informações começou a crescer, ficou difícil ter acesso
aos dados de diferentes departamentos de uma maneira consistente e rápida. Na Figura 13.26 temos
uma pequena ilustração deste ambiente:
Figura 13.26 Dados de múltiplas e heterogêneas fontes.
Além de múltiplas fontes de dados, temos diferentes formatos de dados. Evidentemente que a
estrutura de um arquivo de mensagens de correio é muito diferente da estrutura de uma planilha
do Excel, por exemplo.
Para que possamos criar aplicações que acessam dados de diversas fontes, precisamos de tecnologias
capazes de acessar dados de fontes tão diversas como o mainframe e um documento do Microsoft
Word ou uma planilha do Microsoft Excel. O Framework .NET fornece, principalmente através do
namespace System.Data, uma série de classes para conexão e manipulação de dados dos mais variados
formatos. Este conjunto de classes também é conhecido como ADO.NET.
A seguir vamos estudar as classes que dão acesso a fontes de dados estruturadas, que seguem o modelo
de dados relacionais. Podemos citar como exemplos de Bancos de Dados relacionais o Microsoft Ac-
cess, o SQL Server 2000, o ORACLE, o DB2 da IBM, etc.
NOTA
Para maiores detalhes sobre o modelo de dados relacionais, consulte o Capítulo 1.
QUAIS AS PRINCIPAIS DIFERENÇAS DO ADO.NET EM RELAÇÃO AO ADO?

Com ADO estabelecíamos uma conexão com uma fonte de dados e utilizávamos ou o método Open
do Objeto Connection ou um objeto do tipo Command, para executar um comando SQL e retornar
dados, no formato de uma tabela, para um objeto do tipo RecordSet. A característica principal é que
para trabalhar com os dados e fazer alterações nos dados, precisamos estabelecer uma conexão com o
Banco de Dados.
Com ADO.NET temos um modelo de dados “desconectado”. O protocolo HTTP é conhecido como
Connection Less. Ao solicitar uma página, é estabelecida uma conexão com o servidor Web, os arquivos
e imagens necessários são solicitados e enviados para o navegador do cliente e a conexão é fechada,
por isso o Connection Less, pois não é mantida uma conexão permanente entre o servidor Web e o
navegador do cliente. Esta natureza “desconectada” da Web causa alguns inconvenientes quando
desenvolvemos aplicações de Banco de Dados.
ADO.NET resolve este problema, fornecendo uma série de objetos que permitem que os dados, uma
vez carregados para o navegador do cliente, sejam manipulados, mesmo sem existir uma conexão
permanente com o Banco de Dados. Uma vez feitas as alterações, inclusões ou exclusões necessárias,
podemos, facilmente, sincronizar os dados que estão no cliente com o Banco de Dados no servidor.
O principal objeto do modelo ADO, para trabalhar com dados, é o objeto RecordSet. Para exibir os
dados de um objeto RecordSet, precisamos escrever uma boa quantia de código. Com ADO.NET, o
principal objeto, que funciona como um container para dados, é o DataSet, o qual pode conter uma ou
mais tabelas (o objeto RecordSet somente pode conter uma tabela) e também os relacionamentos entre
as tabelas e informações sobre chaves primárias e chaves estrangeiras.
Com o modelo “desconectado” do ADO.NET, não utilizamos cursores, nem no lado cliente, nem no
lado servidor. As classes de acesso a dados fornecem os mecanismos necessários para a manipulação
dos dados. O formato adotado para armazenar os dados no cliente é o XML, um padrão amplamente
aceito e utilizado pela indústria de TI. Com ADO, ao utilizar tecnologias como RDS para trabalhar com
dados desconectados, temos um formato proprietário para os dados, formato este que somente é aceito
pelo Internet Explorer.
NOTA
Para maiores informações sobre Tabelas, Atributos, Chaves Primárias, Chaves Estrangeiras e Relacionamentos entre tabelas, consulte o
Capítulo 1, no tópico sobre os Fundamentos do Modelo Relacional de Dados.
Neste tópico vamos aprender a utilizar alguns objetos básicos para o acesso a dados relacionais, mais
especificamente a dados do SQL Server. Veremos como estabelecer uma conexão com o Banco de
Dados, acessar dados de uma ou mais tabelas e exibir estes dados em uma página ASP.NET.
Para exibição dos resultados obtidos, vamos utilizar o Web Server Control – DataGrid. Estudaremos
este controle em detalhes. Veremos que o controle DataGrid facilita, enormemente, a tarefa de exibir
dados em uma página ASP.NET. No nosso exemplo mais simples, apresentado no tópico anterior,
vimos que o que no ASP 3.0 exige várias linhas de código, no ASP.NET, com o controle DataGrid, pode
ser feito em uma única linha de código.
BANCOS DE DADOS UTILIZADOS NOS EXEMPLOS

Para os exemplos deste tópico, utilizarei o Banco de Dados Pubs, da instância SERVIDOR\SQL2005 do
SQL Server 2005. Conforme já descrevi em capítulos anteriores, o Banco de Dados Pubs não é fornecido
com o SQL Server 2005. Para trabalhar com este Banco de Dados, nós importamos o Banco de Dados
Pubs, de uma instância do SQL Server 2000 para a instância SERVIDOR\SQL2005. Para isso, usamos o
DTS Import/Export Wizard, o qual foi, detalhadamente, explicado e exemplificado nos Capítulos 7 e 10.
O BANCO DE DADOS DO SQL SERVER – PUBS

NOTA
Importante: Os nomes de empresas, produtos, pessoas, personagens e/ou dados apresentados neste Banco de Dados são fictícios e não
representam de forma alguma qualquer indivíduo, produto, empresa ou evento, salvo menção contrária.
Os nomes de tabelas e campos do Banco de Dados pubs estão em inglês.
As principais tabelas deste Banco de Dados são as seguintes:
♦ authors (autores)
♦ discounts (descontos)
♦ employee (funcionários, empregados)
♦ jobs (funções, cargos)
♦ publishers (editoras)
♦ sales (vendas)
♦ stores (lojas, livrarias)
♦ titles (livros, títulos)
♦ titleauthor (relaciona os livros de cada autor)
O Banco de Dados pubs é utilizado por uma rede de livrarias, para o controle de vendas e pesquisa dos
títulos existentes no catálogo da livraria.
Na Figura 13.27 temos o diagrama Entidades x Relacionamentos para este Banco de Dados:
Figura 13.27 O diagrama Entidades x Relacionamentos do Banco de Dados pubs.

NOTA
Os campos indicados por uma pequena chave amarela são campos do tipo chave primária. Os campos indicados pelo sinal de infinito (um 8 deitado) são
campos do tipo chave estrangeira. Para detalhes sobre os conceitos de chave primária e chave estrangeira, consulte o Capítulo 1.
UMA INTRODUÇÃO AO ADO.NET

Agora vamos iniciar o estudo das principais classes para acesso a dados. O conjunto destas classes é
conhecido como ADO.NET. As classes que iremos estudar fazem parte dos seguintes namespaces da
biblioteca de classes do Framework .NET:
♦ System.Data: Contém as principais classes utilizadas para acessar bases de dados relacionais. A
classe DataSet faz parte deste namespace.
♦ System.Data.SqlClient: Classes utilizadas para acessar Bancos de Dados do SQL Server 2000 e
do SQL Server 2005. As classes deste namespace fornecem melhor desempenho para acesso ao
SQL Server, pois utilizam a interface TDS – Tabular Data Stream, nativa do SQL Server.
♦ System.Data.Common: Contém as classes onde são definidas as propriedades e métodos
básicos, herdados por classes de outros namespaces.
♦ System.Data.OleDb: Neste namespace encontramos as classes para acesso a fontes de dados,

via OLE-DB Providers.
No ASP 3.0, utilizando ADO, o objeto que utilizamos para retornar dados é o RecordSet. No ADO.NET
não temos o objeto RecordSet. De início você que já estava acostumado com o objeto RecordSet pode
estranhar um pouco, mas, conforme veremos nos exemplos deste tópico, os objetos do ADO.NET além
de mais poderosos são também mais fáceis de utilizar. A principal facilidade é notada no momento de
exibir os resultados obtidos, quando podemos utilizar alguns Web Server Controls bastante poderosos,
mais especificamente o controle DataGrid.
INFORMANDO QUE VOCÊ DESEJA UTILIZAR CLASSES DE UM DETERMINADO NAMESPACE

Para que possamos utilizar classes de um destes namespaces precisamos, explicitamente, fazer referência
a eles no início da página ASP.NET. O que eu chamei de fazer referência é chamado pelo Framework
.NET de “importar” um namespace.
Temos duas maneiras diferentes para “importar” (ou fazer referência, como preferirem) um namespace,
em uma página ASP.NET.
1. Utilizando a diretiva @Import, no início da página. No fragmento de código a seguir, estamos

importando os namespaces System.Data, System.Data.SqlClient e System.OleDb:
<%@Import Namespace=”System.Data” %>
<%@Import Namespace=”System.Data.SqlClient %>
<%@Import Namespace=”System.Data..OleDb”%>
2. Utilizando o comando using do C#. No fragmento de código a seguir, estamos importando os

namespaces System.Data e System.Data.SqlClient:
using System.Data;
using System.Data.Sqlclient;
Uma vez feitas as devidas importações (ou referências), estamos aptos a utilizar as classes dos namespaces
referenciados.
CLASSE OU OBJETO; OBJETO OU CLASSE?

Muitas vezes os termos classe e objeto são utilizados, indiscriminadamente, com o mesmo sentido.
Vamos fazer uma definição formal para estes termos, através de um exemplo:
No namespace System.Data existe uma classe chamada DataSet. Quando declaramos e inicializamos
uma variável, como sendo do tipo DataSet, estamos criando um objeto baseado na classe DataSet. No
trecho de código a seguir, temos um exemplo onde criamos um objeto chamado MeusDados, o qual é
baseado na classe DataSet:
DataSet MeusDados = new DataSet( );
ESTABELECENDO CONEXÕES
Uma coisa não mudou no ADO.NET, em relação ao ADO: o primeiro passo é estabelecer uma conexão
com o Banco de Dados. Embora com ADO.NET tenhamos um modelo desconectado, conforme descrito
anteriormente, o primeiro passo é fazer uma conexão com o Banco de Dados. Uma vez estabelecida a
conexão, obtemos os dados desejados e podemos trabalhar com estes dados diretamente no navegador,
desconectados do Banco de Dados. Uma vez feitas as alterações necessárias, sincronizamos os dados
com o Banco de Dados.
Para estabelecer uma conexão com um Banco de Dados do SQL Server, devemos utilizar,
preferencialmente, a classe SqlConnection, do namespace System.Data.SqlClient.
Para acessar um Banco de Dados utilizando o OLE-DB Provider correspondente, utilizamos a classe
OleDbConnection do namespace System.Data.OleDb. Como existe um OLE-DB Provider para o SQL
Server, também poderíamos utilizar a classe OleDbConnection para fazer uma conexão com o SQL
Server, porém a classe SqlConnection é bem mais eficiente, em termos de desempenho, pois foi
especificamente projetada para trabalhar com o SQL Server 2000, assim como foram todas as classes do
namespace System.Data.SqlClient.
Vamos estudar estas duas classes.
ESTABELECENDO UMA CONEXÃO COM O SQL SERVER 2000 OU SQL SERVER 2005 – SQLCONNECTION
A classe SqlConnection faz parte do namespace System.Data.SqlClient. Esta classe é utilizada para
estabelecer uma conexão com um servidor SQL Server. Diferente do que acontecia com ADO, não
podemos executar um comando SQL, utilizando a classe SqlConnection. Ainda neste tópico estudaremos
as classes utilizadas para executar comandos em um Banco de Dados.
A seguir temos um exemplo de criação de um objeto do tipo SqlConnection:

SqlConnection MinhaConecção = new SqlConnection(“server=SERVIDOR\\SQL2005;” +
“ uid=sa;pwd=senhadosa;database=pubs”);
O parâmetro passado é uma string que contém as informações necessárias para estabelecer a conexão
com o Banco de Dados. No tópico anterior você já viu uma pequena demonstração do uso do objeto
SqlConnection.
Na Tabela 13.1 temos uma descrição das principais propriedades da classe SqlConnection:
Tabela 13.1 Principais propriedades da classe SqlConnection.
ConnectionString É utilizada para definir ou retornar uma string de texto onde são informados os diversos parâmetros
para estabelecer a conexão, como por exemplo o nome do servidor, a instância, o nome do banco de
dados, o nome de login e senha.
ConnectionTimeOut Define por quanto tempo é feita a tentativa de estabelecer a conexão. Após o tempo definido nesta
propriedade, a tentativa é cancelada e um erro é gerado.
Database É utilizada para definir ou retornar o nome do banco de dados que será utilizado quando a conexão for
estabelecida.
DataSource Retorna o nome da instância do SQL Server com a qual foi estabelecida uma conexão.
ServerVersion Retorna uma string informando a versão do servidor SQL Server com o qual a conexão foi estabelecida.
State Retorna o estado atual da conexão.
Vamos apresentar um pequeno exemplo, onde criamos uma conexão com o Banco de Dados pubs da
instância SERVIDOR\SQL2005 (conforme descrito anteriormente). Uma vez estabelecida a conexão, vamos
exibir as propriedades desta conexão em um Web Server Control do tipo TextArea. Vamos utilizar o
evento Page_Load, da página ASP.NET, para estabelecer a conexão com o Banco de Dados pubs.
Na Listagem 13.5 temos o código para o exemplo proposto.
Listagem 13.5 – A classe SqlConnection.

<html>
{
// Crio uma conexão com o Banco de Dados pubs localizado no servidor local.
// Vamos acessar a instância SERVIDOR\SQL2005.
SqlConnection MinhaConexão = new
SqlConnection(“server=SERVIDOR\\SQL2005;uid=sa;pwd=senha;database=pubs”);
// Declaro uma variável do tipo String: auxPropriedades.
// A variável auxPropriedades irá conter o valor das propriedades
// da conexão minhaConexão.
String auxPropriedades;
auxPropriedades = “Propriedades da conexão:”;
auxPropriedades = auxPropriedades + “\n\n” + “ConnectionString: “ +
MinhaConexão.ConnectionString.ToString();
auxPropriedades = auxPropriedades + “\n\n” + “Database: “ +
MinhaConexão.Database.ToString();
auxPropriedades = auxPropriedades + “\n\n” + “DataSource: “ +
MinhaConexão.DataSource.ToString();
auxPropriedades = auxPropriedades + “\n\n” + “State: “ +
MinhaConexão.State.ToString();
ExibePropriedades.Font.Bold=true;
ExibePropriedades.Text=auxPropriedades;
}
</script>
<body>
<h3><font face=”Verdana”>Classe SqlConnection!!!</font></h3>
<asp:TextBox
runat=server
id=”ExibePropriedades”
Text=””
Rows=”10"
Cols=”70"
Font_Face=”Arial” Font_Size=”3"
BackColor=”lightblue”
TextMode=”MultiLine”
/>
</body>
</html>
Ao carregar a página você irá obter uma página semelhante à página indicada na Figura 13.28:
Comentários sobre o código do exemplo:
♦ Observe que a primeira coisa que fizemos foi referenciar os namespaces System.Data e
System.Data.SqlClient:
Se não fizéssemos essa referência, obteríamos um erro de compilação, ao carregar a página, conforme
Figura 13.28 A classe SqlConnection.
Figura 13.29 Erro por não referenciar os namespaces necessários.
Observe o texto em destaque, onde é dito que não foi possível encontrar SqlConnection. Isto
acontece porque esta classe faz parte do namespace System.Data.SqlClient, o qual não foi
referenciado na página ASP.NET.
♦ Em seguida criamos um variável MinhaConexão, baseada na classe SqlConnection:

SqlConnection MinhaConexão = new
SqlConnection(“server=SERVIDOR\\SQL2005;uid=sa;pwd=senha;database=pubs”);
Observe que este é um comando único, que foi dividido em duas linhas por falta de espaço. No ASP.NET,
um único comando pode ser dividido em duas ou mais linhas, o que não era possível no ASP 3.0.
Declaramos a variável MinhaConexão como sendo do tipo SqlConnection, ao mesmo tempo que
inicializamos esta variável, passando como parâmetro uma string de conexão. Na string passada como
parâmetro são definidas as seguintes informações:
Nome da instância do SQL Server: SERVIDOR\SQL2005.
Nome do usuário: uid=sa.
Senha: pwd=senha,
Banco de dados para fazer a conexão: database=pubs.
É importante salientar que o objeto do tipo SqlConnection foi criado, porém ainda não foi estabelecida
a conexão, conforme pode ser confirmado pelo valor da propriedade State=Closed, na Figura 13.29,
exibida anteriormente.
♦ No restante do evento Load, montamos uma string (auxPropriedades), onde vamos

concatenando o nome e o valor das propriedades do objeto MinhaConexão. Observe que
anexamos dois caracteres de nova linha - \n\n. Isso é feito para ir para uma nova linha a
cada propriedade (um \n) e para deixar uma linha em branco entre a exibição de cada
propriedade (mais um \n).
Após termos montado a string auxPropriedades, definimos a fonte do controle ExibePropriedades para
negrito e atribuímos o valor da variável auxPropriedades à propriedade Text do controle
ExibePropriedades, conforme indicado no fragmento a seguir:
ExibePropriedades.Font.Bold=true;
ExibePropriedades.Text=auxPropriedades;
♦ O controle ExibePropriedades é um Web Server Control do tipo TextBox com múltiplas linhas.
Para maiores informações sobre este controle, consulte o Capítulo 9 do e-book: Programação
ASP.NET com C#, 803 páginas, de minha autoria, o qual pode ser adquirido em http://
www.juliobattisti.com.br/ebooksdoautor
Na Tabela 13.2 temos uma descrição dos principais métodos da classe SqlConnection:
Tabela 13.2 Principais métodos da classe SqlConnection.
Método Descrição
Open Abre a conexão de acordo com as definições da propriedade ConnectionString.

Close Fecha a conexão com o banco de dados.
ChangeDatabase Altera o banco de dados associado com a conexão.
O principal evento do objeto SqlConnection é o evento StateChange. Este evento ocorre quando o
estado da conexão é alterado de Open para Closed ou vice-versa.
No exemplo anterior, podemos adicionar o seguinte comando, logo após a criação da conexão
MinhaConexão:
MinhaConexão.Open();
Este comando abre a conexão MinhaConexão. Após inserirmos este comando e recarregarmos a página,
obteremos o resultado indicado na Figura 13.30.
Muito bem, já sabemos estabelecer uma conexão com um Banco de Dados. E agora? Ainda precisamos
aprender como se fazer as seguintes operações:
♦ Definir um comando para ser executado no Banco de Dados.
♦ Retornar dados de uma ou mais tabelas.
♦ Retornar informações sobre os relacionamentos entre as tabelas.
♦ Exibir os resultados obtidos.
Nos próximos tópicos aprenderemos a realizar estas operações.
Figura 13.30 Utilizando o método Open da classe SqlConnection.
UMA VISÃO GERAL DO PROCESSO DE ACESSO A DADOS

Existem muitas maneiras de estabelecer uma conexão com uma fonte de dados, retornar um conjunto
de dados e exibir estes dados em uma página ASP.NET.
Estaremos utilizando a seguinte abordagem:
♦ Criar uma conexão com uma fonte de dados utilizando SqlConnection.
♦ Definir um comando SQL a ser executado no Banco de Dados. O comando é definido utilizando
um objeto do tipo SqlDataAdapter. O comando SQL define os dados que serão retornados a
partir do Banco de Dados. Também podemos utilizar um objeto SqlCommand. Uma opção é
criar um objeto Command e depois a propriedade SelectCommand do objeto DataAdapter
como sendo igual ao objeto Command. Outra opção é passar o comando SQL como parâmetro
do objeto DataAdapter, o que faz com que não seja necessária a criação explícita de um objeto
Command. O objeto DataAdapter faz a ligação de um ou mais objetos do tipo Command com
um objeto do tipo DataSet. Por exemplo, podemos ligar vários objetos Command com um
único DataSet. Iremos detalhar todos estes aspectos nos exemplos que serão apresentados até o
final do capítulo.
♦ Utilizamos os dados retornados pelo(s) comando(s) SQL para popular um objeto do tipo DataSet.
♦ Vamos utilizar um Web Server Control – Datagrid, para exibir os dados associados ao objeto do
tipo DataSet.
Na Figura 13.31 temos uma visão geral deste processo.
SQL Server
SqlConnection OleDbConnection
SqlDataAdapter OleDbDataAdapter
DataSet DataSet
DataGrid na página DataGrid na página

ASP.NET ASP.NET
Página Página
ASP.NET que ASP.NET que
exibe os exibe os
dados. dados.
Figura 13.31 Passos para acessar e exibir dados em uma página ASP.NET.
É importante salientar que esta é apenas uma das maneiras de acessarmos dados e exibi-los em uma
página ASP.NET.
CRIANDO OBJETOS COMMAND

Para criar objetos Command temos duas opções:
♦ SqlCommand: Este objeto é utilizado para definir um comando que será executado através de
uma conexão do tipo SqlConnection.
♦ OleDbCommand: Utilizado para definir um comando que será executado através de uma
conexão do tipo OleDbConnection.
Conforme descrevemos no tópico anterior, podemos criar um objeto Command, no qual definimos
um comando SQL a ser executado através de uma conexão. As propriedades dos objetos SqlCommand
e OleDbCommand são semelhantes.
Na Tabela 13.3 temos uma descrição das principais propriedades das classes SqlCommand/
OleDbCommand:
Tabela 13.3 Principais propriedades das classes SqlCommand/OleDbCommand.
CommandText Esta propriedade é utilizada para definir ou retornar o comando SQL ou o nome de um stored procedure associado
com o comando.
CommandTimeOut Define por quanto tempo o Framework .NET tenta executar o comando. Se, no tempo definido por esta
propriedade, o comando não for executado com sucesso, o comando é suspenso e uma mensagem de erro é retornada.
CommandType Pode ser definida como Text, que é o valor padrão e significa que o valor atribuído à propriedade CommandText é
um comando SQL. Também pode assumir o valor StoredProcedure, neste caso significando que o valor atribuído à
propriedade CommandText é o nome de um stored procedure.
Connection Esta propriedade é utilizado para definir ou retornar a conexão através da qual o comando é executado.
Na Tabela 13.4 temos uma descrição dos principais métodos das classes SqlCommand/OleDbCommand:
Tabela 13.4 Principais métodos das classes SqlCommand/OleDbCommand.
Método Descrição
Cancel Cancela a execução do comando.

CreateParameter Utilizada para a criação e definição de parâmetros. Podemos utilizar parâmetros quando estamos
executando um Stored Procedure ou uma consulta parametrizada do Microsoft Access.
ExecuteNonQuery Executa o comando definido na propriedade CommandText, através da conexão definida na propriedade
Connection, para consultas que não retornam dados. Exemplo de consultas que não retornam dados são
consultas de atualização, adição ou exclusão. Este método retorna um valor inteiro, valor este que indica
o número de registros afetadas pela execução do comando.
RETORNANDO DADOS COM DATAADAPTER

Para criar objetos DataAdapter temos duas opções:
♦ SqlDataAdapter: Este objeto é utilizado para executar um ou mais comandos ou stored proce-
dures, em um Banco de Dados do SQL Server e associar os resultados obtidos com um objeto
do tipo DataSet.
♦ OleDbDataAdapter: Utilizado para executar um ou mais comandos em uma fonte de dados,
utilizando o OLE-DB Provider respectivo, e associar os resultados obtidos com um objeto do
tipo DataSet.
Os objetos SqlDataAdapter/OleDbDataAdapter funcionam como uma ponte entre uma fonte de dados
e o objeto DataSet, tanto para acesso quanto para alterações nos dados. Esta ponte pode ser estabelecida
de duas maneiras:
1. Através da utilização do método Fill do objeto DataAdapter, para retornar dados de uma fonte
de dados e colocar estes dados em um objeto DataSet.
2. Através da utilização do método Update do objeto DataAdapter, método este que sincroniza os
dados da fonte de dados original, com as modificações feitas nos dados do objeto DataSet.
Na Tabela 13.5 temos uma descrição das principais propriedades das classes SqlDataAdapter/
OleDbDataAdapter:
Tabela 13.5 Principais propriedades das classes SqlDataAdapter/OleDbDataAdapter.
Propriedade TTAB= Descrição
DeleteCommand Utilizada para definir ou retornar um comando SQL para exclusão de dados, normalmente
um comando DELETE.
InsertCommand Utilizada para definir ou retornar um comando SQL para inserção de novos dados, normalmente um
comando INSERT.
SelectCommand Utilizada para definir ou retornar um comando SQL, utilizado para retornar dados, normalmente um
comando SELECT. Também podemos atribuir, a esta propriedade, um objeto Command previamente criado.
UpdateCommand Utilizada para definir ou retornar um comando SQL que atualiza dados. Normalmente um comando UPDATE.
Na Tabela 13.6 temos uma descrição dos principais métodos das classes SqlDataAdapter/
OleDbDataAdapter.
Tabela 13.6 Principais métodos das classes SqlDataAdapter/OleDbDataAdapter.
Método Descrição
Fill Com certeza é o método mais utilizado. Este método executa o comando definido na propriedade SelectCommand.
Os dados retornados pela execução do comando definido na propriedade SelectCommand são associados com um
objeto do tipo DataSet.
FillSchema Este método retorna uma tabela em branco, isto é, com zero registros, porém com a mesma estrutura da
tabela original. Na prática o que este método faz é copiar a estrutura de uma tabela.
Update Com ASP.NET trabalhamos com um modelo de dados desconectados, conforme descrito no início deste tópico. Uma
vez retornados os dados em um objeto do tipo DataSet, a conexão com o banco de dados é fechada. Alterações
podem ser feitas nos dados desconectados, porém estas alterações precisam ser enviadas para o banco de dados,
quer seja o SQL Server, quer seja um arquivo .mdb do Microsoft Access. O método Update é utilizado para enviar
estas alterações para o banco de dados. O método executa os comandos InsertCommand, UpdateCommand e
DeleteCommand para cada inserção, atualização ou exclusão, feitas nos dados desconectados, de tal forma que
estas alterações sejam enviadas para a fonte de dados original. Em poucas palavras: sincroniza os dados do objeto
DataSet com o conjunto de dados originais, no servidor.
Na Tabela 13.7 temos uma descrição dos principais eventos das classes SqlDataAdapter/
OleDbDataAdapter.
Tabela 13.7 Principais eventos das classes SqlDataAdapter/OleDbDataAdapter.
Evento Descrição
FillError Ocorre quando um erro é retornado durante a execução do método Fill.

RowUpdated Ocorre durante uma atualização, após o respectivo comando ter sido executado na fonte de dados original.
RowUpdating Ocorre durante uma atualização, antes do respectivo comando ter sido executado na fonte de dados original.
O OBJETO DATASET
Os objetos SqlDataAdapter/OleDbDataAdapter, descritos no tópico anterior, são utilizados para executar
um comando SQL ou uma stored procedure, em um Banco de Dados e retornar um ou mais conjuntos
de dados. Precisamos de uma estrutura capaz de receber e manipular os dados retornados; esta estrutura
é o objeto DataSet. O objeto DataSet é derivado da classe DataSet, do namespace System.Data.
O objeto DataAdapter executa um comando através de uma conexão e retorna os dados para um
objeto DataSet. A conexão é desfeita, pois o objeto DataSet fornece as funcionalidades necessárias para
acessarmos e manipularmos os dados, estando desconectados do servidor. Acessamos e alteramos os
dados conforme necessário e depois as alterações efetuadas são sincronizadas com o servidor.
DataSet é, sem dúvida, o principal objeto do ADO.NET, assim como o objeto RecordSet é o principal
objeto do ADO.
Um objeto DataSet é formado por uma coleção de objetos do tipo DataTable, os quais pertencem à
coleção Tables. Para representar o relacionamento entre dois objetos do tipo DataTable, utilizamos um
objeto do tipo DataRelation. Por exemplo, podemos criar um DataSet que contém duas tabelas: Pedidos
e Clientes. A tabela Clientes relaciona-se com a tabela Pedidos, através de um relacionamento do tipo
um para vários, ou seja, um cliente pode fazer vários pedidos. Podemos representar este relacionamento
utilizando um objeto do tipo DataRelation.
Podemos garantir a integridade dos dados através da definição de campos do tipo Chave Primária –
utilizando o objeto UniqueConstraint; e da definição de Chaves Estrangeiras – utilizando o objeto
ForeignKeyConstraint.
O objeto DataSet lê e grava dados e a estrutura dos dados no formato de documentos XML, os quais
podem ser enviados pela Internet via protocolo HTTP, o que facilita a troca de informações com sistemas
de outras empresas, sistemas estes também habilitados ao XML.
Na Tabela 13.8 temos uma descrição das principais propriedades da classe DataSet:
Tabela 13.8 Principais propriedades da classe DataSet.
DataSetName Utilizada para definir ou retornar o nome do DataSet.

EnforceConstraints Pode ser utilizada para definir ou retornar um valor True ou False. Se o valor desta propriedade for
True, as regras de integridade serão observadas em uma operação de atualização. Por exemplo, se
alterarmos o código do cliente em um pedido da tabela pedidos para 01010 e não existir o cliente com o
código 01010 na tabela Clientes, a operação não será realizada. Se o valor da propriedade
EnforceConstraints for False, a operação descrita no nosso exemplo será realizada sem que nenhuma
verificação seja feita.
Relations Retorna uma coleção com todos os relacionamentos existentes entre as tabelas do DataSet.
Tables Retorna uma coleção com todas as tabelas do DataSet.
Na Tabela 13.9 temos uma descrição dos principais métodos da classe DataSet:
Tabela 13.9 Principais métodos da classe DataSet.
Método Descrição
AcceptChanges Torna definitivas todas as alterações feitas nas tabelas ou relacionamentos do DataSet, desde que este
foi inicializado ou desde a última vez que o método AcceptChanges foi chamado.
Clear Remove todos os dados do DataSet, zerando todas as linhas de todas as tabelas.
Clone Faz uma cópia idêntica do DataSet, inclusive dos seus dados, para um outro objeto do tipo DataSet.
GetChanges Retorna um objeto do tipo DataSet, contendo todas as alterações que foram feitas desde a inicialização
do DataSet original, ou desde a última chamada do método AcceptChanges.
HasChanges Retorna um valor do tipo Boleano. True indica que houve alterações nos dados do DataSet – adições,
alterações ou exclusões. False indica que não houve alterações.
Neste momento já somos capazes de estabelecer uma conexão com o Banco de Dados, definir um
objeto DataAdapter para executar um comando através da conexão estabelecida e preencher um objeto
DataSet com os dados retornados. A próxima etapa é exibir os dados obtidos. A exibição dos dados é a
única coisa que o usuário vê, ao acessar a página. Existem maneiras variadas para exibir os dados em
uma página ASP.NET. Nos exemplos a seguir, utilizarei o controle DataGrid.
O OBJETO DATAVIEW
Para entender a função do objeto DataView, vamos fazer uma recapitulação dos objetos que já estudamos,
neste tópico:
♦ Utilizamos um objeto OleDbConnection ou SqlConnection para estabelecer uma conexão com

o Banco de Dados.
♦ O objeto DataAdapter faz a ponte entre um ou mais objetos Command (SqlCommand ou
OleDbCommand) e um objeto DataSet. Ao final deste processo, os dados estão armazenados
em um objeto DataSet.
♦ O objeto DataView faz a ponte entre o objeto DataSet e um Web Form ou Web Form Control,
onde serão exibidos os dados. Na Figura 13.32, temos uma visão geral deste processo:
Nesta figura, fica bem destacado o papel de ponte entre o objeto DataSet e o controle DataGrid, exercido
pelo objeto DataView. No exemplo da figura, utilizamos o controle DataGrid, mas poderia ser qualquer
outro Web Form Control capaz de acessar dados de um DataView.
Um objeto DataView pode ser configurado para retornar apenas uma parte dos dados de um
objeto DataTable. Podemos, por exemplo, ter dois objetos DataView, ligados com o mesmo
objeto DataTable, porém exibindo diferentes dados. Vamos estudar mais alguns detalhes sobre
o objeto DataView.
Fonte Página
de Connection DataSet Controle DataGrid ASP.NET
dados
DataAdapter DataView
Figura 13.32 Acessando dados com ASP.NET.
Na Tabela 13.10 temos uma descrição das principais propriedades da classe DataView:
Tabela 13.10 Principais propriedades da classe DataView.
AllowDelete Propriedade do tipo Boleana. Se contiver o valor True, podemos excluir registros; se contiver o valor
False, não são permitidas exclusões. Esta propriedade pode ser utilizada para definir ou para retornar
um valor True ou False.
AllowEdit Utilizada para definir ou retornar um valor do tipo Boleano. Se o valor da propriedade for True, são
permitidas alterações nos dados, caso contrário os dados não poderão ser alterados.
AllowNew Utilizada para definir ou retornar um valor do tipo Boleano. Se o valor da propriedade for True,
poderemos adicionar novos registros, utilizando o método AddNew, caso contrário novos registros não
poderão ser adicionados.
Count Retorna o número de registros no DataView.
RowFilter Utilizada para definir ou retornar uma expressão que determina quais os dados do objeto DataView, que
serão exibidos.
RowStateFilter Com ADO.NET é mantido um histórico das alterações feitas nos dados. O objeto DataView mantém as
versões anteriores de registros que foram alterados ou excluídos. Podemos utilizar esta propriedade
para retornar ou definir uma expressão que filtra apenas os registros em um determinado estado, como
por exemplo: alterados, excluídos, etc.
Sort Utilizada para definir ou retornar informações sobre a(s) coluna(s) e a ordem de classificação dos dados.
Table Utilizada para definir ou retornar a tabela a partir da qual o DataView obtém os dados.
Na Tabela 13.11 temos uma descrição dos principais métodos da classe DataView:
Tabela 13.11 Principais métodos da classe DataView.
Método Descrição
AddNew Adiciona um novo registro ao DataView.

Delete Exclui um registro do DataView.
Find Localiza um determinado registro, com base no valor da chave primária.
AddNew Adiciona um novo registro ao DataView.
Vamos apresentar alguns exemplos de utilização do objeto DataView.
Exemplo 1: Neste exemplo faremos uma conexão com o Banco de Dados C:\Meus
documentos\Northwind.mdb. Vamos retornar os seguintes campos da tabela Funcionários:
♦ CódigoDoFuncionário
♦ Nome
♦ Cargo
♦ DataDeNascimento
♦ Cidade
Os dados serão apresentados na página, utilizando um controle DataGrid. Também apresentaremos
um controle ListBox, onde o usuário poderá selecionar um campo pelo qual os dados serão ordenados
em ordem crescente. Por padrão os dados são classificados pelo CódigoDoFuncionário.
Na listagem 13.6 a seguir temos o código para o exemplo proposto.
Listagem 13.6 – Um exemplo completo de conexão com um Banco de Dados do Access, usando o objeto DataView.
<%@ Import Namespace=”System.Data.OleDb” %>
<html>
{
// Crio uma conexão com o Banco de Dados do Microsoft Access.
// C:\Meus documentos\NorthWind.mdb.
String DefineConexão= “PROVIDER=MICROSOFT.JET.OLEDB.4.0;” +
“DATA SOURCE=c:\\meus documentos\\NorthWind.mdb”;
OleDbConnection MinhaConexão = new OleDbConnection(DefineConexão);
// Utilizamos um objeto DataAdapter para executar um comando SQL,
// o qual retorna todos os dados da tabela “Clientes”.
OleDbDataAdapter MeuComando = new OleDbDataAdapter(“SELECT
CódigoDoFuncionário,” + “Nome,Cargo,DataDeNascimento,Cidade
FROM Funcionários”, MinhaConexão);
// Observe que não temos mais o objeto Recordset,
// como era de praxe com o ASP 3.0.
// Utilizo o método Fill do objeto DataAdapter, para preencher
// o objeto DataSet, com os dados retornados pelo comando SQL.
MeuComando.Fill(ds);
// Conectamos um controle DataGrid com o DataSet criado anteriormente.
// MinhaGrade é o id (nome) de um controle do tipo
DataView source = new DataView(ds.Tables[0]);
// Utilizamos uma instrução Switch para definir a

// classificação dos dados com base no valor selecionado
// na lista CampoClassificar.
string aux = CampoClassificar.SelectedItem.Value;
switch (aux)
{
case “Cargo”:
source.Sort=”Cargo ASC”;
break;
case “Cidade”:
source.Sort=”Cidade ASC”;
break;
case “Código do Funcionário”:
source.Sort=”CódigoDoFuncionário ASC”;
break;
case “Data de Nascimento”:
source.Sort=”DataDeNascimento ASC”;
break;
case “Nome”:
source.Sort=”Nome ASC”;
break;
default:
// outras opções.
break;
}
MinhaGrade.DataSource = source ;
MinhaGrade.DataBind();
}
</script>
<%— Exibe as informações do DataGrid no corpo da página. —%>
<h3><font face=”Verdana”>Funcionários da empresa North Wind!!!</font></h3>
<BR>
<form runat=server>
<h3><font face=”Verdana”>Classificar por:</font></h3>
<asp:ListBox id=”CampoClassificar”
Rows=”1"
Width=”200px”
runat=”server”>
<asp:ListItem>Cargo</asp:ListItem>
<asp:ListItem>Cidade</asp:ListItem>
<asp:ListItem selected=”True”>Código do Funcionário</asp:ListItem>
<asp:ListItem>Data de Nascimento</asp:ListItem>
<asp:ListItem>Nome</asp:ListItem>
</asp:ListBox>
<ASP:DataGrid id=”MinhaGrade” runat=”server”

Width=”700"
BackColor=”#ccccff”
CellPadding=3
CellSpacing=”0"
Font-Size=”8pt”
/>
<BR>
<B>Clique para Classificar —></B></td>
<input type=submit value=”Classificar” runat=”server”>
</form>
</body>
</html>
Ao carregar esta página, você irá obter o resultado indicado na Figura 13.33:
Figura 13.33 Relação de funcionários – classificada pelo Código do Funcionário.
Observe que a listagem está classificada em ordem crescente do Código do Funcionário. Vamos testar
o nosso exemplo. Na lista “Classificar Por”, selecione Nome e dê um clique no botão Classificar. Você
obterá uma listagem classificada pelo nome do funcionário, conforme indicado na Figura 13.34:
Figura 13.34 Relação de funcionários – classificada pelo Nome.
Comentários sobre o código do exemplo anterior:
♦ O código para conectar com o Banco de Dados e retornar dados é muito semelhante ao código
utilizado nos exemplos anteriores, onde fizemos conexões com um Banco de Dados do SQL Server.
♦ Na seção de apresentação da página criamos um formulário e adicionamos um Web Server
Control do tipo ListBox chamado CampoClassificar. Este controle exibe as opções de
classificação. O código que define o controle ListBox está indicado a seguir:
<asp:ListBox id=”CampoClassificar”
Rows=”1"
Width=”200px”
runat=”server”>
<asp:ListItem>Cargo</asp:ListItem>
<asp:ListItem>Cidade</asp:ListItem>
<asp:ListItem selected=”True”>Código do Funcionário</asp:ListItem>
<asp:ListItem>Data de Nascimento</asp:ListItem>
<asp:ListItem>Nome</asp:ListItem>
</asp:ListBox>
Observe que, por padrão, ao carregarmos a página, a opção Código do Funcionário vem selecionada –
selected=”True”. Para maiores informações sobre o controle ListBox, consulte o Capítulo 9 do e-book:
“Programação ASP.NET com C#, de minha autoria, já citado anteriormente.
♦ Na seção de código precisamos verificar qual a opção selecionada no ListBox e, com base na
opção selecionada, classificar os dados do DataView. Para isso utilizamos a instrução switch/
case do C#, conforme indicado a seguir:
switch (aux)
{
case “Cargo”:
source.Sort=”Cargo ASC”;
break;
case “Cidade”:
source.Sort=”Cidade ASC”;
break;
case “Código do Funcionário”:
break;
case “Data de Nascimento”:
source.Sort=”DataDeNascimento ASC”;
break;
case “Nome”:
source.Sort=”Nome ASC”;
break;
default:
// outras opções.
break;
}
Primeiro criamos uma string aux e atribuímos a esta string o valor do item selecionado na ListBox
CampoClassificar:
Em seguida, utilizamos a string aux como variável de comparação para a instrução switch/case. Com base
no valor da string aux, definimos a classificação dos dados do DataView. Para definir a classificação utilizamos
a propriedade Sort do objeto source, objeto este que é do tipo DataView, como no exemplo a seguir:
A propriedade Sort é uma string que contém o nome do campo seguido de um espaço e da palavra ASC
para classificação crescente ou DESC para classificação decrescente.
NOTA
Para maiores informações sobre a instrução switch/case e sobre as demais instruções de controle de fluxo do C#, consulte o Capítulo 3 do e-
book “Programação ASP.NET com C#”. Maiores detalhes em http://www.juliobattisti.com.br/ebooksdoautor.
UM POUCO MAIS SOBRE O CONTROLE DATAGRID

O controle DataGrid, sem sombra de dúvidas, é assunto para um capítulo inteiro. Como não dispomos
de tanto espaço, caso contrário teríamos um livro de mais de 2000 páginas, vamos apresentar as principais
características deste poderoso controle, através de alguns exemplos práticos. Neste tópico veremos
como algumas propriedades e métodos do controle DataGrid são capazes de efetuar verdadeiras
maravilhas. Para mais detalhes sobre o controle DataGrid, consulte os Capítulos 11 e 12 do e-book
“Programação ASP.NET com C#”.
PRIMEIRA MARAVILHA DO DATAGRID: PAGINAÇÃO

Quando obtemos um número grande de registros é interessante dividir a exibição dos registros em
páginas, onde exibimos um determinado número de registros por vez. Isso é o que chamamos de
paginação. Por exemplo, podemos fazer com que 1000 registros sejam divididos em páginas onde são
exibidos 20 ou 50 registros por vez.
Fazer paginação com ASP 3.0 não era uma tarefa das mais fáceis. Um boa quantidade de código era
necessária e tudo tinha que ser implementado manualmente. Com o controle DataGrid, definir
paginação está resumido a configurar duas propriedades:
♦ AllowPaging: Esta propriedade é do tipo Boleana. Se for True, a paginação é habilitada, se for
False, a paginação é desabilitada. Por padrão esta propriedade é False. Ao tornarmos AllowPaging
True, na última linha do DataGrid, são exibidos os símbolos “<” para voltar à página anterior
e “>” para ir à próxima página. Podemos alterar estes valores utilizando as propriedades
PagerStyle-NextPageText para alterar o texto do link que vai para a próxima página e PagerStyle-
PrevPageText, para alterar o texto do link que volta para a página anterior.
Quando estamos na primeira página, o link para a página anterior é automaticamente desabilitado,
pois não existe página anterior à primeira. Quando estamos na última página, o link para a próxima
página é automaticamente desabilitado, pois não existe página após a última.
♦ PageSize: O valor desta propriedade define o número de registros que serão exibidos por vez.
Se esta propriedade não for definida, serão exibidos 10 registros por página.
Para definir que sejam exibidos 20 registros por página, sendo “Próxima página >” o texto do link para
a próxima página e “< Página anterior” o texto para o link para a página anterior, definimos as seguintes
propriedades/valores do controle DataGrid:
AllowPaging=”True”
PageSize=”20”
PagerStyle-NextPageText=”Próxima página >”
PagerStyle-PrevPageText=”< Página anterior”
Inserindo a definição para essas propriedades, a tag que define o controle DataGrid ficaria da seguinte
maneira:
<ASP:DataGrid
id=”MeuDataGrid”
runat=”server”
Width=”600"
BackColor=”#bbccff”
AllowPaging=”True”
PageSize=”20”
PagerStyle-NextPageText=”Próxima página >”
PagerStyle-PrevPageText=”< Página anterior”
CellPadding=3
CellSpacing=”0"
Font-Size=”8pt”
/>
NOTA
Para que a paginação seja feita, além de definir a propriedade AllowPaging como True, temos que criar código para trocar de página. O
método que faz a troca de página é definido na propriedade OnPageIndexChanged do DataGrid.
SEGUNDA MARAVILHA DO DATAGRID: MAIS DO QUE UM CONJUNTO DE DADOS NA MESMA PÁGINA

Vamos ver um exemplo prático, onde exibiremos dados de duas tabelas, do Banco de Dados NorthWind,
na mesma página ASP.NET. Para isso faremos uso de dois controles do tipo DataGrid.
O exemplo Proposto: Exibir, na mesma página, informações da tabela Funcionários e da tabela

Transportadores.
Na listagem 13.7 a seguir temos o código para o exemplo proposto.
Listagem 13.7 – Exibindo dados de múltiplas tabelas em uma página ASP.NET.

<%@ Import Namespace=”System.Data.OleDb” %>
<html>
{
// Crio uma conexão com o Banco de Dados do Microsoft Access.
// C:\Meus documentos\NorthWind.mdb.
// Para podermos acessar múltiplas tabelas vamos criar
// um objeto Command, conforme indicado a seguir:
OleDbCommand MeuComando = new OleDbCommand();
// defino algumas propriedades do objeto Command.

MeuComando.Connection = MinhaConexão;
MeuComando.CommandType = CommandType.Text;
// Utilizamos um objeto DataAdapter para executar dois comandos SQL.

// Um comando para retornar dados da tabela Funcionários.
// Um comando para retornar dados da tabela Transportadoras.
OleDbDataAdapter MeuDataAdapter = new OleDbDataAdapter();
// Definimos o comando a ser utilizado pelo objeto DataAdapter.

// Para isso definimos a sua propriedade SelectCommand.
MeuDataAdapter.SelectCommand = MeuComando;
// Vamos preencher o DataSet com dados das tabelas
// Funcionários e Transportadores.
// Para isso precisamos executar dois comandos SQL.
// ************************************************
// Na prática vamos chamar o método Fill do DataAdapter
// duas vezes.
// Antes de cada chamada alteramos a propriedade
// CommandText do objeto Command.
MeuComando.CommandText=”Select CódigoDoFuncionário,Nome,Sobrenome,Cargo
From Funcionários”;
MeuDataAdapter.Fill(ds,”Funcionários”);
// Altero a propriedade CommandText para retornar dados
// da tabela Transportadores.
// Chamo novamente o método Fill.
MeuComando.CommandText = “Select * From Transportadoras”;

MeuDataAdapter.Fill(ds,”Transportadoras”);
// Conectamos um controle DataGrid com
// cada tabela do DataSet criado anteriormente.
// ******************************************************
// GradeFuncionários é o id (nome) de um controle do tipo
// Este controle exibirá dados dos Funcionários.
// ******************************************************
// GradeTransportadoras é o id (nome) de um controle do tipo
// Este controle exibirá dados das Transportadoras.
DataView Funcionários = new DataView(ds.Tables[0]);
GradeFuncionários.DataSource = Funcionários ;
GradeFuncionários.DataBind();
DataView Transportadoras = new DataView(ds.Tables[1]);

GradeTransportadoras.DataSource = Transportadoras ;
GradeTransportadoras.DataBind();
}
</script>
<h3><font face=”Verdana”>Funcionários da empresa North Wind!!!</font></h3>

<HR>
<ASP:DataGrid
id=”GradeFuncionários”
runat=”server”
Width=”450"
BackColor=”#bbccff”
BorderColor=”blue”
CellPadding=3
CellSpacing=”0"
Font-Size=”8pt”
HeaderStyle-Font-Bold=”True”
/>
<BR>
<HR>
<h3><font face=”Verdana”>Transportadoras da empresa North Wind!!!</font></h3>
<ASP:DataGrid
id=”GradeTransportadoras”
runat=”server”
Width=”400"
BackColor=”#bbddff”
BorderColor=”blue”
CellPadding=3
CellSpacing=”0"
Font-Size=”8pt”
HeaderStyle-Font-Bold=”True”
/>
<HR>
</body>
</html>
Ao acessar esta página, você irá obter o resultado indicado na Figura 13.35:
Figura 13.35 Exibindo dados de múltiplas tabelas em uma página ASP.NET.
Comentários sobre o código do exemplo anterior.
♦ Vamos descrever os passos utilizados para acessar e exibir dados das tabelas Funcionários e
Pedidos. Alguns passos já foram explicados em exemplos anteriores, mas iremos repetir a
explicação, para fazermos uma revisão do conteúdo deste capítulo:
1. Utilizamos o evento Pge_Load para colocar o código necessário ao nosso exemplo.
2. Iniciamos estabelecendo uma conexão com o Banco de Dados NorthWind.mdb:

3. A partir deste ponto temos algumas mudanças em relação aos exemplos anteriores. Primeiro
vamos criar um objeto OleDbCommand e definir as propriedades Connection e CommandType
do objeto OleDbCommand:
OleDbCommand MeuComando = new OleDbCommand();
// defino algumas propriedades do objeto Command.
MeuComando.Connection = MinhaConexão;
MeuComando.CommandType = CommandType.Text;
4. Agora criamos um objeto DataAdapter e definimos a sua propriedade SelectCommand. Ao definirmos
esta propriedade informamos qual o objeto OleDbCommand que estará associado ao DataAdapter:
OleDbDataAdapter MeuDataAdapter = new OleDbDataAdapter();
MeuDataAdapter.SelectCommand = MeuComando;
5. Declaramos um objeto ds do tipo DataSet. O objeto DataSet será o container para as tabelas
Funcionários e Transportadores. Recapitulando o que estudamos anteriormente, o objeto DataSet
pode conter uma ou mais tabelas, as quais estão contidas na coleção Tables do objeto.
6. Chegamos ao ponto principal do nosso exemplo. Utilizamos a seguinte técnica:

Definimos a propriedade CommandText do objeto MeuComando. Esta propriedade contém a
string SQL que acessa dados de uma determinada tabela:
MeuComando.CommandText=”Select CódigoDoFuncionário,Nome,Sobrenome,Cargo
From Funcionários”;
Em seguida chamamos o método Fill do objeto DataAdapter. Ao chamarmos este método, o comando definido
na propriedade CommandText é executado e os dados retornados são passados para o DataSet definido no
primeiro parâmetro. O segundo parâmetro é o nome do conjunto de dados no DataSet. No nosso exemplo
utilizamos o mesmo nome da tabela, no Banco de Dados NorthWind, porém isso não é obrigatório:
MeuDataAdapter.Fill(ds,”Funcionários”);
Repetimos os mesmos passos para retornar dados da tabela Transportadoras e colocá-los no DataSet ds:
MeuComando.CommandText = “Select * From Transportadoras”;
MeuDataAdapter.Fill(ds,”Transportadoras”);
Após a execução destes comandos, a coleção Tables, do DataSet ds, contém duas tabelas com dados
retornados a partir do Banco de Dados NorthWind.mdb.
7. O próximo passo é exibir os dados do objeto DataSet na página ASP.NET. Isto é feito utilizando
um objeto do tipo DataView para cada tabela a ser exibida. Ao criarmos o objeto DataView, já
passamos como parâmetro a tabela associada ao objeto. Em seguida definimos a propriedade
DataSource do controle DataGrid como sendo igual ao objeto DataView recém-criado. O passo
final é chamar o método DataBind do controle DataGrid:
DataView Funcionários = new DataView(ds.Tables[0]);
GradeFuncionários.DataSource = Funcionários ;
GradeFuncionários.DataBind();
DataView Transportadoras = new DataView(ds.Tables[1]);

GradeTransportadoras.DataSource = Transportadoras ;
GradeTransportadoras.DataBind();
Para cada tabela do DataSet criamos um objeto DataView. Para o DataView Funcionários, passamos
como parâmetro: ds.Tables[0], ou seja, a primeira tabela, da coleção de tabelas do DataSet ds. Para o
DataView Transportadoras, passamos como parâmetro ds.Tables[1], ou seja, a segunda tabela, da coleção
de tabelas do DataSet ds. Depois é só ligar cada DataView com o respectivo DataGrid.
8. Na seção de apresentação, utilizamos algumas propriedades do DataGrid para definir a sua

aparência. Por exemplo:
♦ HeaderStyle-BackColor=”#aaaadd”: Define a cor de segundo plano da primeira linha do

DataGrid, a linha que contém os títulos das colunas.
♦ HeaderStyle-Font-Bold=”True”: Define que o texto da primeira linha deve ser exibido com
fonte em negrito.
Este exemplo demonstra, mais uma vez, o poder e flexibilidade dos novos objetos para acesso a dados
oferecidos pelo ADO.NET e também demonstra o poder dos Web Server Controls, mais especificamente
do controle DataGrid.
CONCLUSÃO
Neste capítulo “apresentei” o Framework .NET ao amigo leitor.
Iniciamos o capítulo apresentando uma visão geral e uma definição genérica para a iniciativa .NET da
Microsoft. Tratamos de conceitos como Web Services, CLR – Common Language Runtime e .NET
Framework Class Library. Vimos que o .NET é a visão da Microsoft em um mundo onde o Software
passa a ser desenvolvido e comercializado na forma de serviços. Os programas são construídos a partir
de unidades menores, os assemblies. Dentro de um assembly tenho todos os elementos que garantem
uma funcionalidade específica, para a qual o assembly foi projetado. Dentro deste contexto podemos
concluir que, mais do que uma atualização tecnológica, o .NET é uma mudança de paradigma.
Destacamos os dois principais componentes do Framework .NET. Em primeiro lugar um ambiente de

execução comum a todas as linguagens habilitadas ao .NET - CLR – Common Language Runtime.
Qualquer linguagem habilitada ao .NET, ao ser compilada, gera código MSIL – Microsoft Intermediate
Language, sendo que é o código MSIL que é executado pelo CLR.
Além disso é fornecida uma biblioteca de classes que pode ser utilizada por qualquer linguagem habilitada
ao .NET. .NET é uma mudança de paradigma. Ao colocar à disposição do programador um conjunto de
classes padronizadas, o Framework .NET está incentivando boas práticas de programação, como a
herança e a conseqüente reutilização de código.
Em seguida apresentamos os problemas com o modelo de desenvolvimento baseado em componentes

que seguem o padrão COM/COM+. Vimos que para que, um componente possa ser utilizado, este
precisa ser registrado e que diferentes versões de um mesmo componente não podem coexistir em um
mesmo computador, o que pode fazer com que, ao instalarmos um programa, este substitua a versão
atual do componente por uma versão diferente, a qual não pode ser utilizada por outros programas
que dependem da versão anteriormente instalada. Isto faz com que o programa que depende da versão
substituída deixe de funcionar. Esta situação também é conhecida como “DLL Hell.”
Em seguida continuamos tratando dos componentes do Framework .NET apresentando, em primeiro

lugar, as linguagens que fazem parte do Framework .NET, com destaque para a facilidade em fazer com
que programas escritos em diferentes linguagens possam se comunicar e trocar informações. Fizemos
uma descrição breve do VB.NET e da nova linguagem C#.
Continuando nossa jornada pela Framework .NET apresentamos o CTS – Common Type System. Vimos a
importância de todas as linguagens utilizarem um conjunto padronizado de dados, principalmente para
garantir a interoperabilidade entre programas, componentes e serviços criados em diferentes linguagens.
Também tratamos do conceito de metadados (metadata), o qual faz com que cada componente contenha
todas as informações necessárias ao seu funcionamento, o que evita que o componente tenha que ser
registrado, como acontecia com os componentes COM/COM+. Além disso os metadados é que
possibilitam que diferentes versões de um componente coexistam em um computador, podendo in-
clusive as diferentes versões serem executadas simultaneamente.
Vimos que a unidade básica de “empacotamento” é chamada de assembly. Um assembly contém todos
os elementos necessários ao funcionamento de um componente. Falaremos mais sobre assemblies no
próximo capítulo.
Seguindo, passamos a tratar das interfaces com o usuário, onde vimos os conceitos de Windows Forms
e Web Forms, onde foram apresentados diagramas ilustrativos da utilização destes elementos.
Também não poderíamos deixar de fora uma breve apresentação dos servidores .NET. Uma linha de
servidores da Microsoft, para facilitar o desenvolvimento de aplicações .NET, os quais fornecem uma
série de funcionalidades, desde um servidor de Banco de Dados Relacionais (SQL Server 2005) até um
servidor para garantir a segurança na Internet – Internet Security and Acceleration Server 2004.
Para encerrar fizemos uma breve apresentação do ADO.NET.

NOTA
Para a documentação sempre atualizada sobre o .NET, não deixe de consultar o endereço: http://msdn.microsoft.com/net.
Em seguida aprendemos a conectar páginas ASP.NET com Bancos de Dados do SQL Server 2005 e do
Microsoft Access. Utilizamos classes, basicamente, dos seguintes namespaces:
♦ System.Data
♦ System.Data.OleDb
♦ System.Data.SqlClient
Estudamos, em detalhes, diversas classes destes namespaces:
♦ SqlConnection/OleDbConnection
♦ SqlCommand/OleDbCommand
♦ SqlDataAdapter/OleDbDataAdapter
♦ DataSet
♦ DataView
Também estudamos algumas características do poderoso controle DataGrid.
Evidentemente que este capítulo não tem a pretensão de ser um estudo completo e detalhado sobre
o .NET e sobre a criação de páginas ASP.NET para a conexão com Bancos de Dados do SQL Server
2005. Estes seriam assuntos para livros inteiros (aliás existem dezenas de livros sobre estes assuntos).
Dentro da proposta deste livro, o objetivo deste capítulo foi fazer com que o amigo leitor tenha uma
idéia clara do que é o Framework .NET, como ele se relaciona com o SQL Server 2005 e como a
tecnologia ASP.NET é a alternativa mais indicada para a criação de aplicações Web que fazem conexão
com Bancos de Dados.
CAPÍTULO 14 – REPORTING SERVICES – O SERVIÇO DE RELATÓRIOS DO SQL SERVER 2005
Capítulo 14
REPORTING SERVICES – O SERVIÇO DE
RELATÓRIOS DO SQL SERVER 2005
INTRODUÇÃO
O trabalho com banco de dados tem um lado interessante. Você inicia pelo projeto do banco de dados,
através da definição das tabelas, chaves primárias e estrangeiras, relacionamentos e todos os demais
tópicos do modelo relacional. Você implementa as tabelas, índices, views (consultas), triggers, stored
procedures, configurações de replicação, segurança enfim, um arsenal de recursos para colocar as
informações nos bancos de dados do SQL Server.
Obviamente que todos estes passos são meios para se atingir um objetivo maior: “A informação
correta, para quem dela precisar, no momento adequado”. Esta máxima da indústria de TI é bem
conhecida e dispensa maiores comentários. Porém depois de colocar todas as informações para “dentro
do banco de dados”, você precisa tirar estas informações através de relatórios e consultas, para atender
as demandas dos usuários.
Temos diferentes maneiras de acessar os dados do SQL Server. No Capítulo 11 você aprendeu sobre a
criação de páginas ASP, para o acesso a dados do SQL Server. No Capítulo 13 você aprendeu sobre o
Framework .NET e sobre a criação de páginas ASP.NET, para acesso a dados do SQL Server. Você também
poderia criar aplicativos usando VB.NET, Delphi, C## ou qualquer outra linguagem de programação,
aplicativos estes que acessam dados do SQL Server.
Todo o acesso a dados, cálculos, formatações pode ser feito usando ASP, ASP.NET ou linguagens como
VB.NET, C# e Delphi. Porém usar programação para a criação de relatórios e a formatação das telas de
saída é bastante trabalhoso. Por isso que foram desenvolvidas opções específicas para a criação e
formatação de relatórios. Até o SQL Server 7.0, o próprio SQL Server não tinha nenhum sistema ou
serviço para a criação de relatórios. Com estas versões, a única opção disponível seria usar um cliente
como o Access para acessar dados do SQL Server e, usando os recursos do Access, criar os relatórios
necessários. Outra opção era usar aplicativos específicos para a criação de relatórios, tais como o Crys-
tal Reports. Você usava o Crystal Reports para conectar com o SQL Server, criar e formatar relatórios.
Os relatórios criados pelo Crystal Reports poderiam, então, ser utilizados por aplicativos desenvolvidos
em Visual Basic, VB.NET, C#, Delphi ou em páginas Web, criadas em ASP, ASP.NET, PHP ou Java.
A partir do SQL Server 2000 (na verdade foi lançado como um sistema separado, bem depois do
lançamento do SQL Server 2000), foi disponibilizado um serviço específico para a geração de relatórios.
Este serviço facilita, bastante, a criação de relatórios a partir de bancos de dados do SQL Server, sem a
necessidade de usar um aplicativo separado, como por exemplo o Access ou o Crystal Reports. A boa
notícia é que, no SQL Server 2005, o serviço de relatórios – Reporting Services – foi bastante melhorado
em relação ao serviço oferecido pelo SQL Server 2000. Ele está bem mais fácil de utilizar, com bem mais
recursos e, principalmente, com mais facilidades para que os relatórios gerados sejam acessados usando
diferentes opções, tais como: Acesso via Web, uso dos relatórios por aplicativos desenvolvidos nas
mais variadas linguagens e assim por diante.
O nosso trabalho neste capítulo é justamente este, ou seja, entender o que é, qual a sua arquitetura e
como funciona o Reporting Services. Além disso, aprenderemos, na prática, a utilizar o Reporting
Services, para criar e acessar relatórios, a partir de bancos do SQL Server 2005. Você aprenderá, através
de exemplos práticos, a criar relatórios usando o Reporting Services. Veremos que, para quem já conhece
o Access, usar o Reporting Services será bastante simples, pois os seus assistentes são muito semelhantes
aos assistentes de criação de relatórios do Microsoft Access. Então, mãos à obra.
DESENVOLVIMENTO EM: ENTENDENDO O REPORTING SERVICES

PRÉ-REQUISITOS
♦ Conhecimento básico dos objetos que compõem um banco de dados do SQL Server.
METODOLOGIA
♦ Apresentação dos elementos que compõem o Reporting Services.
INTRODUÇÃO AO REPORTING SERVICES

O Reporting Services é bem mais do que somente uma ferramenta para a criação de relatórios. Ele é
uma plataforma que, além da criação de relatórios, permite que os relatórios sejam armazenados no
servidor SQL Server, permite que sejam configuradas as permissões de acesso aos relatórios, disponibiliza
diversos formatos de saída para os relatórios, permite que se use tecnologias push (onde o SQL Server
envia uma cópia do relatório para um ou mais destinatários, sempre que houver mudanças ou em
horários agendados) ou tecnologia Pull (onde o usuário é que solicita um determinado relatório). Além
de tudo isso, o Reporting Services fornece toda a infra-estrutura e serviços necessários para a distribuição
dos relatórios. Sem dúvida, muito mais do que uma ferramenta para a criação de relatórios, o Report-
ing Services constitui toda uma plataforma para a criação, configuração, distribuição e gerenciamento
de relatórios. E ainda é bastante simples de ser utilizado.
O Reporting Services é uma plataforma para geração e distribuição de relatórios baseada no servidor
SQL Server 2005. Com o Reporting Services é possível a criação desde os tradicionais relatórios no
formato de tabelas/listagens, relatórios matriciais ou de referência cruzada, relatórios gráficos e em
formatos não padronizados. Outro detalhe importante é que, usando o Reporting Services, você não
está limitado a usar fontes de dados do SQL Server 2005. Você poderá usar qualquer fonte de dados –
relacional ou não – para a qual o SQL Server 2005 tenha conectores. Por exemplo, você poderá usar, em
um mesmo relatório, dados de tabelas do SQL Server 2005 em conjunto com dados de uma planilha do
Excel e dados vindos de uma fonte não estruturada, tais como dados de caixas de e-mail do Exchange
Server 2003. Os relatórios gerados pelo Reporting Services podem, facilmente, ser acessados usando
simplesmente um navegador, como o Internet Explorer, Netscape Navigator ou FireFox.
O Reporting Services foi implementado pela Microsoft, usando uma arquitetura modular, onde ele
foi dividido em diversos componentes. Cada componente executa funções específicas e todos os
componentes interagem entre si. Por exemplo, um processo é responsável por fazer a conexão com
as fontes de dados utilizadas no relatório e retornar os dados solicitados. Outro componente é o
responsável por receber a requisição dos clientes e retornar os dados no formato solicitado. Muitas
são as vantagens de se utilizar esta arquitetura. Vamos citar apenas a mais óbvia. Ao separar as
funcionalidades de conectar com as fontes de dados e retornar os dados, da funcionalidade de retornar
os resultados para os clientes, é possível ao Reporting Services fornecer o mesmo relatório, para
diferentes clientes, em diferentes formatos, simultaneamente, sem ter que fazer várias conexões com
as diferentes fontes de dados. Por exemplo, se um mesmo relatório está sendo solicitado, por diferentes
clientes, em formato .PDF, HTML, .XLS e XML, o Reporting Services fará uma única conexão com as
fontes de dados, retornará os dados solicitados, e o componente de formatação irá criar diferentes
formatos, para atender a solicitação de cada um dos clientes. Isso melhora bastante o desempenho e
economiza recursos preciosos no servidor.
RELATÓRIOS ACESSADOS VIA WEB – VANTAGENS

Conforme já descrevi anteriormente, o Reporting Services tem como uma de suas principais
características a geração de relatórios que são facilmente acessados, usando-se tão-somente um
Navegador. Esta característica é chamada, na documentação do SQL Server 2005, de “Web-enabled
foundation”. Por que foi utilizada esta diretiva e quais as suas vantagens? Tentarei explicar na seqüência.
O Reporting Services trabalha em conjunto com o Internet Information Services (IIS), funcionando
como um servidor intermediário, entre o cliente e o IIS. Isso permite a criação de relatórios baseados
em qualquer fonte de dados que possa ser acessada via ADO.DB, OLE-DB Provider e, até mesmo, via
ODBC. Opa, quer dizer que, se eu precisar utilizar dados de um bom e velho arquivo do Dbase III
(arquivo .dbf), basta criar uma fonte ODBC para este arquivo e pronto, ele estará disponível para ser
utilizado, como uma fonte de dados, em um relatório do Reporting Services? Sim, não só para o bom
e velho arquivo do Dbase III, mas como para qualquer fonte que possa ser acessada via ODBC.
Vejam que aqui o Reporting Services está cumprindo – e bem o seu papel de servir como uma infra-
estrutura intermediária entre uma grande variedade de fontes de dados e o acesso via Web a relatórios
baseados nestas fontes. Na Figura 14.1, temos uma ilustração desta integração do Reporting Services,
com o IIS, para a criação de relatórios que podem ser acessados via Web.
Figura 14.1 Integração entre o Reporting Services e o IIS.
Claro que os formatos para acesso via Web e o acesso via Web trazem inúmeras vantagens, já bem
conhecidas. Para maiores detalhes sobre estas vantagens, consulte os tópicos sobre os modelos de
desenvolvimento em 3 ou n-camadas, apresentados nos Capítulos 1 e 2. Mas uma solução para a
criação de relatórios deve ser flexível e permitir, além do formato e acesso via Web, a criação de relatórios
em formatos mais tradicionais, para acesso através de aplicações já conhecidas do usuário. O Report-
ing Services permite, também, a criação de relatórios nos mais variados formatos, tais como:
♦ HTML
♦ Excel
♦ Text
♦ XML
♦ Image
♦ PDF
NOTA
Os formatos para os quais o Reporting Services pode gerar relatórios são conhecidos como “Rendering Extensions”. O Reporting Services é uma
plataforma aberta, que pode ser extendida através de suas APIs de programação. Por exemplo, você pode usar as APIs de programação do Reporting
Services para fazer com que seja possível a geração de relatórios em formatos adicionais, de acordo com as necessidades da sua empresa.
Importante: Outro detalhe importante é que o Reporting Services faz parte do SQL Server 2005. Ao adquirir as licenças do SQL Server 2005,
NOTA
você está também adquirindo licença para usar o Reporting Services, no mesmo servidor onde está sendo instalado o SQL Server 2005. Se
você precisar instalar e utilizar o Reporting Services em servidores adicionais, onde não está instalado o SQL Server 2005, você precisará
entrar em contato com a Microsoft para adquirir licença de uso do Reporting Services, nestes servidores adicionais.
PRINCIPAIS COMPONENTES DO REPORTING SERVICES

Agora que já temos uma visão geral do que é o Reporting Services e de que papel ele desempenha na
geração e distribuição de relatórios, vamos analisar, rapidamente, os principais componentes do Re-
porting Services. Na Figura 14.2, apresento uma figura do Books Online do SQL Server 2005, na qual
temos uma visão geral da arquitetura e dos principais componentes do Reporting Services. Na seqüência,
farei uma breve descrição de cada um dos componentes do Reporting Services e das funções
desempenhadas por cada um.
Figura 14.2 Arquitetura e componentes do Reporting Services.
REPORT DESIGNER
O Report Designer talvez seja a face mais “visível” do Reporting Services, para quem fica responsável
pela criação dos relatórios. Por exemplo, quando chega um pedido do chefe: “Preciso de um relatório
de vendas, que mostre o total mensal de vendas por produto e por mês, para o ano de 2004. Além
disso, preciso do relatório para acesso via browser e também no formato de planilha do Excel.” O
funcionário responsável pela criação do relatório irá utilizar o Report Designer para conectar com as
tabelas do SQL Server e criar o relatório, conforme solicitação do chefe.
Além da criação do relatório, você também utiliza o Report Designer, para publicar o relatório em um
servidor de relatórios. Outro detalhe importante é que o Report Designer é integrado com o Visual
Studio. Uma vez instalado o Report Designer, as suas funcionalidades estarão também disponíveis para
serem utilizadas, através do Visual Studio.
Para a criação de um relatório usando o Report Designer, primeiro você cria um novo projeto no Visual
Studio. Este novo projeto será baseado no template “Report Project”. Depois de criar um novo projeto
do tipo Report Project, você adiciona um ou mais relatórios (você aprenderá a fazer isso na parte
prática deste capítulo, em um dos próximos tópicos). Você poderá criar diferentes tipos de relatórios,
desde as tradicionais listagens, relatórios do tipo matriciais e, viva, relatórios do tipo “Tabela de Referência
Cruzada”. Uma grande “queixa” em relação ao SQL Server era em relação à dificuldade em se criar
relatórios de referência cruzada, uma vez que a cláusula TRANSFORM, utilizada no Microsoft Access,
para a criação deste tipo de relatório, é uma cláusula proprietária do Access e não faz parte do padrão
da linguagem T-SQL, utilizada pelo SQL Server. Com o Report Designer, conforme você verá na parte
prática, ficou bem mais fácil a criação de relatórios do tipo “Tabela de referência cruzada”.
Você verá que a criação de relatórios, usando o Report Designer, é bem semelhante à criação de relatórios
usando o Microsoft Access. Você poderá utilizar assistentes ou simplesmente arrastar campos e outros
elementos, em uma interface visual, de fácil utilização. Você também tem a opção de testar o relatório,
localmente, antes de publicá-lo em um servidor de relatórios. Com isso, você pode, rapidamente,
testar os resultados do seu relatório e corrigir os erros ainda existentes, antes de enviá-lo para publicação
em um servidor de relatórios.
Uma vez publicado um relatório, você usa o console SQL Server Management Studio ou o console
Report Manager, para administração dos relatórios. Para a criação e definição dos relatórios é utilizada
uma linguagem conhecida como Report Definition Language (RDL). Todas as funcionalidades deste
padrão estão disponíveis no Report Designer. Foge ao escopo deste livro tratar sobre o padrão RDL. No
Books Online você encontra mais informações sobre a linguagem RDL.
REPORT SERVER
O Report Server é o principal componente do Reporting Services. Ele é responsável pela grande maioria
das funcionalidades do Reporting Services. Ele é composto de dois componentes principais: Um Web
Service (dentro do conceito de Webservices do Framework .NET. Para mais detalhes sobre o Framework
.NET, consulte o Capítulo 13) e um Serviço do Windows. O Web Service é responsável por disponibilizar
uma série de interfaces de programação (na verdade um grande conjunto de objetos, métodos e
propriedades), as quais são utilizadas pelas aplicações clientes (quer sejam aplicações Web, por exemplo
baseadas em ASP ou ASP.NET ou aplicações tradicionais, baseadas em VB.NET, Delphi, etc.), para acessar
os recursos e funcionalidades do Report Server. O serviço Windows é responsável pelo agendamento e
envio de serviços. Por exemplo, um relatório pode ser agendado, para ser enviado via e-mail para um
grupo de usuários, em datas e horários previamente agendados. Além disso, o Report Server tem uma
série de subcomponentes, os quais são responsáveis pela formatação dos relatórios, publicação dos
relatórios, atender as requisições dos clientes, verificar se o cliente tem permissão para acessar
determinado relatório e assim por diante.
A seguir apresento uma breve descrição dos principais subcomponentes do Report Server.
♦ Programmatic Interfaces (Interfaces de Programação): O Report Server, através de um Web

Service, disponibiliza uma série de Interfaces de Programação (na verdade um grande conjunto
de objetos, métodos e propriedades), as quais são utilizadas pelas aplicações clientes (quer
sejam aplicações Web, por exemplo baseadas em ASP ou ASP.NET, ou aplicações tradicionais,
baseadas em VB.NET, Delphi, etc.), para acessar os recursos e funcionalidades do Report Server.
Estes objetos trabalham com padrões do Framework .NET, tal como o protocolo SOAP, o qual
permite “encapsular” diferentes protocolos e formatos para uso através do protocolo HTTP.
Para detalhes sobre o SOAP como protocolo e o XML como formato de dados, consulte o
Capítulo 13.
♦ Report Processor: Este é o componente que carrega as informações de definição sobre um

determinado relatório, a partir do banco de dados do Report Server (todas as informações sobre
os relatórios são mantidas em um banco de dados do Reporting Services), e combina estas
informações com os dados obtidos a partir das fontes de dados do relatório, para gerar o relatório
final. Observe a modularização do processo. Ou seja, as definições do relatório são armazenadas
separadamente dos dados do relatório. As definições são armazenadas em um banco de dados
do Report Server. Os dados que compõem o relatório ficam em seu formato original, nas fontes
de dados que serão utilizadas no relatório. Ou seja, o Report Server somente armazena as
informações necessárias para acessar os dados, mas não os dados em si. Com isso, quando um
relatório é solicitado, o Report Server acessa as informações de definição do relatório e combina
estas informações com os dados obtidos a partir das fontes de dados, para gerar o relatório
solicitado. Após gerado o relatório, ele ainda é enviado para o componente de formatação, o
qual irá colocar o relatório no formato de saída, solicitado pelo cliente e com as formatações
especificadas, quando da criação do relatório.
♦ Data Processing Extensions: Uma extensão de processamento de dados é uma funcionalidade

específica, que o Report Server usa para acessar determinada fonte de dados. Diferentes extensões
são utilizadas para interagir com diferentes fontes de dados. Você pode usar as extensões que já
estão disponíveis com o Report Server ou pode criar suas próprias extensões, para acessar
diferentes fontes de dados. Por padrão, o Report Server apresenta extensões para as seguintes
fontes de dados:
1. SQL Server
2. Oracle
3. ODBC
4. OLE DB
5. ADO.NET data provider
As extensões para ODBC e OLE-DB fazem com que seja possível se conectar, com praticamente qualquer
fonte de dados estruturada, disponível atualmente.
As extensões de processmaento de dados são responsáveis por uma série de tarefas, para que seja
possível o acesso a uma fonte de dados:
1. Abrir uma conexão com a fonte de dados.

2. Retornar uma lista de tabelas e campos disponíveis na fonte de dados.
3. Executar uma consulta contra a fonte de dados e retornar um conjunto de registros.
4. Se for uma consulta parametrizada, as extensões de dados é que são responsáveis por passar os
parâmetros esperados pela consulta.
5. Passar informações de logon, para a fonte de dados (nome de usuário e senha, se necessário).
♦ Report server database (banco de dados do servidor de relatórios): Conforme já descrevi
anteriormente, o Reporting Services utiliza um banco de dados, para armazenar uma série de
informações, tais como as definições dos relatórios, informações para acessar as fontes de dados,
informações sobre permissões de acesso, informações para formatação dos relatórios,
informações sobre agendamentos de envio de relatórios e assim por diante. O banco de dados
do servidor de relatórios pode estar no mesmo servidor onde está instalado o Reporting Ser-
vices ou em um outro servidor SQL Server.
♦ Scheduling and Delivery Processor (processador de agendamento e de envio de relatórios):
Este é o componente responsável pelo agendamento e envio de relatórios para os usuários. Um
relatório pode ser agendado para ser executado uma única vez, ou pode ser agendado para ser
executado e enviado para um grupo de usuários em períodos definidos. Este componente é
responsável por duas tarefas distintas: Executar os relatórios agendados e Enviar o relatório
para um ou mais destinos, que pode ser desde um grupo de usuários, para um envio via e-mail,
ou a publicação da versão atualizada do relatório para acesso via Web. A execução periódica é
importante para que o relatório esteja sempre atualizado. Por exemplo, um relatório diário de
vendas, com o total de vendas por produto, tem que ser constantemente atualizado (digamos
de 10 em 10 minutos), para que seja útil. O responsável por esta atualização periódica é o
processador de agendamento e envio de relatórios.
Quando um relatório agendado é executado, é criado um snapshot do relatório, no momento em que ele
é executado. Ou seja, é criada uma nova versão do relatório, com base nos dados disponíveis no momento
de sua execução. O relatório é enviado para o banco de dados do servidor de relatórios e fica disponível
para ser acessado. Se necessário, é possível armazenar no banco de dados do servidor de relatórios múltiplas
versões de um relatório. Por exemplo, as últimas 20 versões, ou todas as versões dos últimos quinze dias.
A possibilidade de agendar a execução dos relatórios é um auxiliar valioso para manter um bom
desempenho no servidor de relatórios. Com isso, os usuários podem acessar versões já prontas dos
relatórios, as quais estão tão atualizadas quanto for o agendamento de execução. Claro que, em
determinadas situações, pode ser necessário acessar uma versão 100% atualizada do relatório. Nestes
casos, tem que ser feito um estudo detalhado para ver o que é mais interessante em termos de desempenho.
Por exemplo, agendar o relatório para executar de minuto em minuto ou não agendar uma execução e
fazer com que o relatório seja executado, cada vez que houver uma solicitação dos clientes?
Após criado o agendamento dos relatórios, os usuários podem se inscrever para um ou mais relatórios.
Depois que um relatório agendado for executado, ele será enviado para o destino especificado no
momento da inscrição. O Reporting Services pode formatar o relatório para ser enviado como uma
mensagem de e-mail, pode enviar o relatório como um arquivo anexado a uma mensagem de e-mail
ou pode enviar apenas um link via e-mail ou um aviso via pager, com o link para acesso à nova versão
do relatório, via browser.
NOTA
Mais uma vez cabe ressaltar a natureza “extensível” do Reporting Services. Os programadores podem criar outras opções de entrega dos
relatórios, diferentes das que são fornecidas pelo Reporting Services.
As informações de agendamento também são armazenadas no banco de dados do servidor de realtórios.

O servidor de relatórios coloca os agendamentos em uma fila e envia as requisições para a máquina de
agendamento, para processamento nos horários e datas previamente agendadas. Para criar os
agendamentos, o Reporting Services se baseia nos serviços oferecidos pelo SQL Server Agent. Os
agendamentos não serão processados se o SQL Server Agent não estiver rodando ou houver algum
problema com este serviço.
♦ Delivery extensions: O componente Scheduling and Delivery Processor, descrito anteriormente,

utiliza o componente conhecido como “Delivery extensions”, para enviar os relatórios para
diferentes localizações e destinos. Juntamente com o Reporting Services são instaladas extensões
de entrega para envio dos relatórios via e-mail ou para uma pasta compartilhada em um servidor.
Evidentemente que outras extensões podem ser criadas pelos programadores, usando as APIs
de programação disponíveis.
O mecanismo de envio de relatórios (delivery extensions) trabalha em conjunto com o mecanismo de

inscrições (subscriptions). Quando um usuário faz uma inscrição, ele define qual o método de entrega
a ser utilizado, o que determinará como os relatórios serão enviados para ele.
♦ E-Mail Delivery Extension: Esta extensão permite que os relatórios sejam enviados via e-
mail, usando o protocolo SMTP. Para isso deve estar disponível um servidor SMTP. Pode ser
o servidor SMTP que vem junto com o IIS ou um servidor mais sofisticado, tal com o
Exchange Server 2003.
♦ File Share Delivery Extension: Com esta extensão, os relatórios podem ser salvos em uma
pasta compartilhada, em um servidor da rede, no formato de saída definido durante a criação
do relatório. Por exemplo, pode ser criada uma pasta compartilhada chamada Indicadores, em
um servidor de arquivos da rede. Posso configurar uma série de relatórios, os quais serão gerados
no formato de planilhas do Excel e salvos, automaticamente, na pasta compartilhada
Indicadores. Além disso, usando o agendamento, posso fazer com que os relatórios sejam
atualizados, periodicamente. Por exemplo, atualização de hora em hora. Com isso, terei uma
pasta Indicadores, com planilhas sempre atualizadas (com no máximo uma hora de defasagem),
planilhas estas geradas, automaticamente, pelo Reporting Services. Este exemplo demonstra
bem que o Reporting Services, mais do que uma plataforma para geração de relatórios, é também
um framework para atualização e distribuição destes relatórios, nos mais variados formatos,
através da rede da empresa.
♦ Rendering Extensions: Estes são os componentes responsáveis por fazer a formatação final do
relatório. Ou seja, são estes componentes que definem em quais formatos os relatórios podem
ser disponibilizados. Por enquanto, estão disponíveis seis formatos de saída:
♦ HTML
♦ Excel
♦ Text
♦ XML
♦ Image
♦ PDF
NOTA
Nunca é demais salientar que podem ser criadas extensões adicionais, para permitir a saída em outros formatos.
Quando um relatório é gerado no formato de uma planilha do Excel, é preciso do Excel XP ou superior. Esta
opção cria arquivos no formato MHTML. Este é um tipo MIME par ao Excel e contém tags HTML e XML
que são específicas para o Excel XP ou superior, não sendo compatíveis com versões anteriores do Excel.
Uma opção que também está disponível é a geração dos relatórios no formato CSV Comma-Separated
Value. Um arquivo .CSV é um arquivo de texto, o qual é reconhecido por qualquer versão do Excel, e
também pode ser importado pela maioria dos bancos de dados, como por exemplo o Microsoft Access.
Com a extensão Image Rendering Extension, é possível gerar os relatórios como figuras nos formatos:
BMP, EMF, GIF, JPEG, PNG, TIFF, and WMF. Por padrão é utilizado o formato TIFF. A vantagem do uso
do formato de imagem é que a aparência do relatório será exatamente a mesma, para todos os clientes
que acessarem o relatório. Já com formatos como o HTML, dependendo do cliente que estiver sendo
utilizado para acessar o relatório, poderão haver diferenças na apresentação do relatório.
Ao usar o PDF Rendering Extension, você poderá gerar arquivos .PDF os quais são compatíveis com o
Adove Reader 4.0 ou superior.
Bem. Com isso acredito que já tivemos uma “boa dose” de teoria, com a qual foi possível ter uma
noção clara do que é e quais os usos do Reporting Services. A partir do próximo tópico, faremos uma
série de exemplos práticos, passo a passo.
DESENVOLVIMENTO EM: REQUISITOS PARA QUE O

REPORTING SERVICES FUNCIONE CORRETAMENTE
PRÉ-REQUISITOS
♦ Conhecimento sobre os elementos do Reporting Services.
METODOLOGIA
♦ Apresentação dos pré-requisitos para funcionamento do Reporting Services.
O Reporting Services é instalado durante a instalação do SQL Server 2005. Em uma das etapas da
instalação, mostradas no Capítulo 2, você marca a opção Reporting Services. As funcionalidades do
Reporting Services são dependentes do IIS. Por isso, antes de instalar o Reporting Services, você deve
certificar-se de que o IIS esteja corretamente instalado e esteja funcionando. Para testar se o IIS está
instalado e funcionando é só abrir o seu navegador e digitar o seguinte endereço http://localhost. Se
for aberta a tela inicial do site padrão, é sinal de que o IIS está corretamente instalado e está funcionando.
Caso dê erro ao acessar o endereço http://localhost você deve, inicialmente, verificar se o IIS está instalado.
Se o IIS não estiver instalado, você deve instalá-lo, usando os passos descritos no Capítulo 13.
REQUISITOS DO IIS E DO ASP.NET PARA A INSTALAÇÃO DO REPORTING SERVICES

Para que a instalação do Reporting Services possa ser feita com sucesso, alguns requerimentos devem
ser atendidos, principalmente em relação ao IIS e ao funcionamento do ASP.NET, do qual depende o
funcionamento do IIS. Devem ser atendidos os seguintes requisitos:
♦ Deve existir um Web Site padrão, configurado no IIS, para que o Reporting Services possa criar
as pastas virtuais, necessárias ao seu funcionamento. Ao instalar o IIS, já é, automaticamente,
criado um Web Site padrão. Pode ser utilizado este Web site, criado pelo IIS.
♦ Configuração de contas padrão com as quais o IIS irá rodar. Estas configurações também são
feitas, automaticamente, durante a instalação do IIS.
♦ O ASP.NET deve estar funcionando corretamente e configurado para rodar com a conta padrão
configurada para o ASP.NET. Esta configuração é feita também, automaticamente, durante a
instalação do Framework .NET.
Observe que, ao instalar o IIS e o Framework .NET, com as configurações padrão, você já atenderá os
pré-requisitos para que o Reporting Services possa ser instalado e possa funcionar, corretamente.
Claro que sempre existe a possibilidade de surgirem problemas. No Books Online, na seção: Installing
SQL Server -> Installing SQL Server 2005 Components -> Installing Reporting Services, você encontra
informações detalhadas sobre todo o processo de instalação do Reporting Services e sobre como re-
solver problemas que podem surgir, durante a instalação.
DESENVOLVIMENTO EM: IMPORTANDO O NORTHWIND.MDB

E DEFININDO OS RELACIONAMENTOS
PRÉ-REQUISITOS
♦ Conhecimento sobre Importação/Exportação de dados com o SQL Server 2005.
METODOLOGIA
♦ Exemplo prático, passo-a-passo.
Antes de começarmos a criação de relatórios, vamos preparar o ambiente. Eu optei por importar o
banco de dados Northwind.mdb, do Access, para dentro do SQL Server 2005 e definir, dentro do SQL
Server, os relacionamentos entre as tabelas importadas. Optei por importar e utilizar o Northwind.mdb,
por ser um banco de dados bem conhecido, com o qual a maioria dos leitores já deve ter trabalhado. O
banco de dados AdventureWorks é um banco bastante normalizado, com um grande número de tabelas.
Demora um bom tempo até que consigamos entender bem a estrutura do banco de dados
AdventureWorks. Como o objetivo deste capítulo é mostrar como utilizar o Reporting Services, optei
por utilizar o Northwind.mdb, por ser este um banco já bem conhecido dos amigos leitores. A seguir
faremos a importação do Northwind.mdb para dentro do SQL Server 2000 e, logo em seguida,
definiremos as chaves primárias e os relacionamentos entre as tabelas.
Primera etapa: Usar o assistente de Importação/Exportação, para importar as tabelas do banco de dados
Northwind.mdb para um banco de dados NorthwindReport, no SQL Server. O banco de dados
NorthwindReport será criado durante a importação.
Para importar o banco de dados Northwind.mdb, para dentro do SQL Server 2005, siga os passos
indicados a seguir:
1. Abra o DTS Import/Export Wizard: Iniciar -> Programas -> Microsoft SQL Server 2005 -> DTS
Import/Export Wizard.
2. Será aberto o assistente para importação e exportação de dados. A primeira tela do assistente é
somente informativa. Clique em Next para seguir para a próxima etapa do assistente.
Figura 14.3 Criando o banco de dados NorthwindReport.
3. Nesta etapa você informa os dados sobre a origem dos dados. Na lista Data source selecione a
opção Microsoft Access. No campo File name você informa o caminho completo para o banco
de dados Northwind.mdb. Normalmente, este banco de dados está gravado no seguinte
caminho: C:\Arquivos de programas\Microsoft Office\Office\Samples\Northwind.mdb. Digite
o caminho para acessar o banco de dados Northwind.mdb
5. Nesta etapa definimos para qual banco de dados do SQL Server iremos importar os dados do
Northwind.mdb. Na lista Destination selecione a opção Microsoft OLE DB Provider for SQL
Server. Na lista Server name, selecione a instância para a qual serão importados os dados.
6. Vamos criar um novo banco de dados chamado NortwhindReport, para o qual serão importados
os dados. Clique no botão New. Será aberta a janela Create database. Defina as opções indicadas
na Figura 14.3. Clique em OK para criar o banco de dados NorthwindReport.
7. Você estará de volta ao assistente de importação. Clique em Next para seguir para a próxima
8. Nesta etapa marque a opção “Copy data from one or more tables or views”. Clique em Next
9. Nesta etapa você marca as tabelas a serem importadas. Marque as tabelas Categorias, Clientes,
Detalhes do Pedido, Fornecedores, Funcionários, Pedidos, Produtos e Transportadoras, conforme
Figura 14.4 Selecionando as tabelas a serem importadas.
10. Clique em Next para seguir para a próxima etapa do assistente.
11. Nesta etapa, certifique-se de que a opção Execute immediately esteja selecionada e que a opção
Save DTS Package esteja desmarcada. Clique em Next para seguir para a próxima etapa do assistente.
12. Será exibido um resumo das opções selecionadas. Caso você precise alterar alguma opção, você
pode usar o botão Back. Clique em Finish.
13. Será iniciado o processo de importação. Uma janela, indicando o andamento dos trabalhos
será exibida, conforme indicado na Figura 14.5:
Figura 14.5 Importação em andamento.
14. Ao ser concluída a importação, o botão Close será habilitado. Clique em Close para encerrar o
DTS Import/Export Wizard.
15. Muito bem, o banco de dados NorthwindReport terá sido criado e todas as tabelas do
Northwind.mdb foram importadas para dentro do banco de dados NorthwindReport, como
pode ser conferido usando o SQL Server Management Studio, conforme indicado na Figura 14.6.
Muito bem, agora já estamos aptos a ir para a segunda etapa, na qual vamos definir as chaves primárias
e os relacionamentos para as tabelas do banco de dados NorthwindReport. Quando você importa
tabelas do Microsoft Access, as definições de chave primária e relacionamentos não são importadas
para o SQL Server 2005. Na Figura 14.7 temos o Diagrama Entidade x Relacionamentos, no qual estão
exibidos os relacionamentos que serão definidos para o banco de dados NorthwindReport.
Figura 14.6 Importação concluída com sucesso.
Figura 14.7 Relacionamentos para o banco de dados NorthwindReport.
Segunda etapa: Para definir as chaves primárias e relacionamentos para o banco de dados
NorthwindReport, siga os passos indicados a seguir:
1. Abra o SQL Server Management Studio e navegue até o banco de dados NorthwindReport,
criado na etapa anterior.
2. Navegue até o banco de dados NorthwindReport e clique no sinal de + ao lado deste banco de
dados, para exibir as opções disponíveis.
3. Clique no sinal de + ao lado da opção Tables, para exibir a lista de tabelas disponíveis. Deverão ser
exibidas as tabelas Categorias, Clientes, Detalhes do Pedido, Fornecedores, Funcionários, Pedidos,
Produtos e Transportadores. Vamos começar por definir as chaves primárias para as tabelas.
4. Clique com o botão direito do mouse na tabela Categorias e, no menu de opções que é exibido,
clique em Modify Table. Será exibida a janela para modificação da estrutura da tabela Categorias.
5. A chave primária da tabela Categorias será o campo CódigoDaCategoria. Selecione a linha
CódigoDaCategoria (para selecionar uma linha, clique no botão cinza, ao lado do nome do
campo). Estando a linha CódigoDaCategoria selecionada, selecione o comando Table Designer
-> Set Primary Key. O desenho de uma pequena chave amarela será exibido ao lado do campo
CódigoDaCategoria, conforme indicado na Figura 14.8. Este desenho indica que o campo foi
configurado como chave primária da tabela.
Figura 14.8 Campo CódigoDaCategoria definido como chave primária.
6. Pressione Ctrl+S para salvar as alterações. Selecione o comando File -> Close, para fechar a
janela de edição da estrutura da tabela Categorias.
7. Agora vamos definir as chaves primárias para os demais campos. Seguindo as orientações dos
passos anteriores, defina os seguintes campos como chave primária:
♦ CódigoDoCliente da tabela Clientes
♦ CódigoDoFornecedor da tabela Fornecedores
♦ CódigoDoFuncionário da tabela Funcionários
♦ NúmeroDoPedido da tabela Pedidos
♦ CódigoDoProduto da tabela Produtos
♦ CódigoDaTransportadora da tabela Transportadoras
Muito bem, uma vez definidas as chaves primárias, vamos definir os relacionamentos entre as tabelas.
Por exemplo, tem um relacionamento entre as tabelas Pedidos e Detalhes do Pedido. O relacionamento
é através do campo NúmeroDoPedido. Na tabela Pedidos, o campo NúmeroDoPedido é uma chave
primária. Na tabela Detalhes do Pedido, o campo número do pedido é uma chave estrangeira. O
relacionamento é do tipo Um-para-vários. Um do lado pedidos, ou seja, cada pedido somente pode ser
cadastrado uma única vez. Vários no lado Detalhes do Pedido, ou seja, um mesmo pedido pode ter
vários itens. Estes são princípios básicos do modelo relacional de dados, princípios estes que foram
abordados no Capítulo 1.
No nosso exemplo, temos que definir os relacionamentos indicados na tabela a seguir:
Tabela 14.1 Relacionamentos a serem criados.
Lado Um Lado Vários
NúmeroDoPedido da tabela Pedidos NúmeroDoPedido da tabela Detalhes do Pedido

CódigoDoFuncionário da tabela Funcionários CódigoDoFuncionário da tabela Pedidos
CódigoDaTransportadora da tabela Transportadoras Via da tabela Pedidos
CódigoDoCliente da tabela Clientes CódigoDoCliente da tabela Pedidos
CódigoDoProduto da tabela Produtos CódigoDoProduto da tabela Detalhes do Pedido
CódigoDaCategoria da tabela Categorias CódigoDaCategoria da tabela Produtos
CódigoDoFornecedor da tabela Fornecedores CódigoDoFornecedor da tabela Produtos
Vamos então à prática, implementar estes sete relacionamentos, no banco de dados NorthwindReport.
8. Você já deve estar com a lista de tabelas do banco de dados NorthwindReport sendo exibida.
Vamos iniciar criando o relacionamento entre as tabelas Pedidos e Detalhes do Pedido, através
do campo NúmeroDoPedido.
9. Clique com o botão direito do mouse na tabela Detalhes do Pedido e, no menu que é exibido,
clique em Modify Table. Será exibida a estrutura da tabela Detalhes do Pedido. Observe que o
relacionamento é criado, acessando a estrutura da tabela que está no lado vários do
relacionamento. Neste primeiro caso, o relacionamento é entre as tabelas Pedidos (lado um) e
Detalhes do Pedido (lado vários), através do campo NúmeroDoPedido.
10. Execute o comando Table Designer -> Relationships. Será aberta a janela Foreign Key Relation-
ship, na qual iremos criar o relacionamento.
11. Clique no botão Add.
12. Um novo relacionamento será criado e um nome será, automaticamente, atribuído a este
relacionamento. Agora temos que informar ao SQL Server quais os campos que compõem o
relacionamento.
13. No lado direito da janela clique no sinal de + ao lado da opção Tables and Columns Specifica-
tion, destacada na Figura 14.9:
Figura 14.9 A janela para criação do relacionamento.
14. Clique no botão com as reticências, ao lado da opção Tables and Columns Specification. Será
aberta a janela Tables and Columns, na qual você define qual campo em qual tabela é o lado
um do relacionamento e qual campo de qual tabela é o lado vários. Na lista Primary Key Table,
selecione a tabela Pedidos. O lado um do relacionamento é o campo NúmeroDoPedido da
tabela Pedidos. Clique na linha em branco, abaixo da tabela Pedidos. Será habilitada a lista de
campos da tabela Pedidos. Nesta lista selecione o campo NúmeroDoPedido. Pronto, acabamos
de definir o lado Um do relacionamento. Na lista Foreign Key Table já vem selecionada a tabela
Detalhes do Pedido. Como clicamos com o botão direito do mouse nesta tabela e selecionamos
Modify Table, ela já vem selecionada como sendo o lado vários. Clique na linha em branco,
abaixo de Detalhes do Pedido. Será habilitada uma lista, com os campos da tabela Detalhes do
Pedido. Abra a lista e selecione o campo NúmeroDoPedido. No campo Relationship name
digite um nome para o relacionamento. Vamos digitar o nome: Pedidos_DetalhesDoPedido.
Figura 14.10 Criando um novo relacionamento.
15. Clique em OK. Você estará de volta à janela Foreign Key RelationShips. Clique em Close para
fechá-la. Você estará de volta à estrutura da tabela Detalhes do Pedido. Pressione Ctrl + S para
salvar as alterações. Será aberta uma janela informando que serão salvas alterações nas tabelas
Pedidos e Detalhes do Pedido, ou seja, justamente as tabelas que compõem o relacionamento
que acabamos de criar. Clique em Yes para confirmar. Selecione o comando File -> Close para
fechar a janela para alterações na tabela Detalhes do Pedido.
16. Com base nas explicações que foram apresentadas, crie os demais relacionamentos propostos
para o banco de dados NorthwindReport. Lembre-se que você deve clicar com o botão direito
do mouse, sempre na tabela que será o lado Vários do relacionamento. Por exemplo, para criar
o seguinte relacionamento:
Tabela 14.2 Relacionamento Funcionários x Pedidos.
Lado Um Lado Vários
CódigoDoFuncionário da tabela Funcionários CódigoDoFuncionário da tabela Pedidos
Você deve clicar com o botão direito do mouse na tabela Pedidos. No menu de opções que surge, clique
em Modify Table e siga os passos descritos anteriormente, para criar este novo relacionamento.
Muito bem, após ter criado todos os relacionamentos propostos, estamos prontos para começar a criar
os relatórios, usando serviço de relatórios do SQL Server 2005. Esse é justamente o assunto do próximo
tópico. Feche o SQL Server Management Studio.
DESENVOLVIMENTO EM: UTILIZANDO O REPORTING SERVICES

PRÉ-REQUISITOS
♦ Conhecimento básico dos componentes do Reporting Services.
METODOLOGIA
♦ Exemplos práticos de criação e utilização de relatórios.
EXEMPLO PRÁTICO – O PRIMEIRO RELATÓRIO

Neste item vamos criar o nosso primeiro relatório este relatório será baseado no banco de dados
NorthwindReport (o qual preparamos no tópico anterior). Este banco de dados tem algumas tabelas
tradicionais, para clientes, funcionários, pedidos, produtos e vendas. É o já mais do que conhecido
Northwind.mdb, o qual importamos para dentro do SQL Server 2005. Para iniciar o nosso trabalho
com o Reporting Services, vamos criar um exemplo bastante simples, onde criaremos uma listagem
dos clientes. Esta listagem apresentará o nome do cliente e alguns dados adicionais, tais como endereço,
cidade, país e região.
Exemplo prático: Criar um relatório, o qual gera uma listagem de clientes. Devem constar da listagem
informações tais como Nome do cliente, endereço, cidade, país, região e telefone de contato. Ordenar
a listagem pelo nome do cliente.
Para criar a listagem proposta, siga os passos indicados a seguir:
1. Abra o Business Intelligence Development Studio: Iniciar -> Programas -> Microsoft SQL Server
2005 -> Business Intelligence Development Studio.
NOTA
O Business Intelligence Development Studio é assunto, não para um livro inteiro, mas sim para uma enciclopédia inteira. O que dá para fazer
com esta ferramenta é algo realmente incrível. Neste capítulo, me limitarei a mostrar como usar esta ferramenta para criar diferentes tipos
de relatórios.
2. Será aberto o Business Intelligence Development Studio, com uma tela em branco, sem nenhum
projeto. Para criar um novo relatório, vamos criar um novo projeto. Selecione o comando File
-> New -> Project.
3. Será aberta a janela New Project. Na lista Project Types selecione a opção Business Intelligence
Projects. Nas opções que são exibidas no painel da direita, marque a opção Report Project
Wizard, conforme indicado na Figura 14.11:
Figura 14.11 A opção Report Server Project Wizard.
4. No campo Name digite Listagem de Clientes.

5. No campo Location, vamos aceitar a pasta padrão para gravação das definições de relatórios
que, no nosso caso, é em: F:\Documents and Settings\Administrador\Meus documentos\Visual
Studio\Projects. Você poderia escolher qualquer outra pasta a ser utilizada, inclusive poderia
ser uma pasta compartilhada, em um servidor de arquivos da rede.
6. Clique em OK.
7. Será exibida a tela inicial do assistente. Esta tela é apenas informativa. Clique em Next, para
8. Nesta etapa você definirá as informações sobre a fonte de dados a ser utilizada. No campo
Name, você deve digitar um nome que irá identificar a fonte de dados. Digite: NortwindReport.
Na lista Type, você define qual o tipo da fonte de dados. Aparecem nesta lista os tipos para os
quais o Reporting Services tem Data Processing Extensions instalados. No nosso exemplo,
certifique-se de que a opção Microsoft SQL Server esteja selecionada.
9. O próximo passo seria digitar a string de conexão, no campo Connection String. Porém, como
não estamos habituados a digitar, manualmente, os dados para a string de conexão, não
conhecemos a sintaxe para uma string de conexão. Felizmente o assistente também pode nos
ajudar nesta etapa. Dê um clique no botão Edit. Será aberta a janela Propriedades de vinculação
de dados, indicada na Figura 14.12:
Figura 14.12 – A janela Propriedades de vinculação de dados.
10. Clique no botão Change. Será aberta a janela Change Data Source. Clique na opção OLE DB
para marcá-la e clique em OK.
11. Você estará de volta à jenela Connection Properties. Na lista OLE DB Provider selecione a
opção Microsoft OLE DB Provider for SQL Server.
12. Clique no botão Data Links. Será aberta a janela Data Link Properties, indicada na Figura 14.13:
Figura 14.13 A janela para selecionar o servidor SQL Server a ser utilizado.
13. Abra a lista “Select or enter a server name” e selecione o nome do SERVIDOR\INSTÂNCIA,
onde está o banco de dados a ser utilizado para criação do relatório. No nosso exemplo,
selecionarei a instância SERVIDOR2\JBCURSOS. Selecione a instância que você está utilizando
para criar este relatório.
14. Depois você deve informar o tipo de autenticação que você está utilizando. Para o nosso exemplo,
marque a opção “Use Windows NT Integraded security”.
15. Abra a lista Select the database on the server e clique na opção NorthwindReport. Sua janela
deve estar com as configurações indicadas na Figura 14.14.
NOTA
Você pode testar se está tudo OK com as configurações da fonte de dados. Para isso clique no botão Test Connection. Será exibida uma
mensagem informando que está tudo OK com a conexão. Clique em OK para fechar esta mensagem.
16. Você estará de volta à janela Propriedades de vinculação de dados. Clique em OK para fechá-la.
Você estará de volta à janela Connection Properties. Clique em OK para fechá-la. Você estará
de volta ao assistente de criação do relatório e a string de conexão terá sido definida. No nosso
exemplo, a string de conexão ficou assim:
Provider=SQLOLEDB.1;Data Source=SERVIDOR2\JBCURSOS;Initial Catalog=NortwindReport
Figura 14.14 Definindo o banco de dados a ser utilizado.
Você pode marcar a opção Make this a shared data source, para que esta fonte de dados esteja disponível
para outros relatórios que venham a ser criados. Marque esta opção. Sua janela deve estar conforme
Figura 14.15 A fonte de dados já está definida.
18. Nesta etapa você poderá digitar diretamente o comando T-SQL da consulta ou usar o Construtor
de consultas (Query Builder). O construtor de consultas é muito semelhante à grade de criação
de consultas do Microsoft Access. Dê um clique no botão Query Builder. Será aberta a janela
Query Builder. A janela aparece, por padrão, sem todas as funcionalidades habilitadas. Dê um
clique no primeiro botão (bem à esquerda). É o botão Generic Query Designer. Ao clicar neste
botão, será exibida a interface completa do Query Builder.
19. O primeiro passo é adicionar as tabelas nas quais será baseada a consulta. Para adicionar uma
ou mais tabelas, clique no botão Add table (último botão, bem à direita, com um sinal de +
amarelo). Será aberta a janela Add tables, com a lista de tabelas do banco de dados
NorthwindReport. Você pode selecionar mais de uma tabela, pressionando e mantendo
pressionada a tecla Ctrl. Mantendo Ctrl pressionada, vá clicando nas tabelas a serem adicionadas
à consulta. Neste nosso primeiro exemplo, vamos utilizar uma única tabela: A tabela Clientes.
Marque a tabela: Clientes. Clique no botão Add, para adicionar a tabela selecionada. Clique
em Close. Sua janela deve estar semelhante à indicada na Figura 14.16:
Figura 14.16 A janela Query Builder.
20. Muito bem, o nosso próximo passo é marcar quais campos farão parte do relatório. Para isso,
basta marcar a caixa de seleção, ao lado do nome do campo.
21. Marque os seguintes campos:
♦ NomeDaEmpresa
♦ Endereço
♦ Cidade
♦ Região
♦ País
♦ Telefone
Figura 14.17 Selecionando os campos que farão parte do relatório.
Observe que, à medida que você vai selecionando os campos que farão parte do relatório, o comando
T-SQL vai sendo atualizado, na parte de baixo da janela. Esta tela é praticamente igual à tela para
a criação de consultas utilizada no Access. Você pode ver uma prévia dos registros que serão
retornados, clicando no botão Executar (botão com um ponto de exclamação vermelho). Ao clicar
neste botão, após alguns instantes, é exibida a listagem de registros, na parte de baixo da tela,
22. Vamos ordenar o relatório pelo campo NomeDaEmpresa. Na linha NomeDaEmpresa, na coluna
Sort Type, selecione a opção Ascending, para fazer ordenar os resultados em ordem alfabética
do campo NomeDaEmpresa. Você pode fazer a ordenação por mais de um campo. Ao fazer a
ordenação por mais de um campo, você pode usar a coluna Sort Order, para definir qual o
primeiro campo a ser considerado na ordenação, qual o segundo e assim por diante. Por exemplo,
se você quisesse classificar primeiro pelo País e dentro do País pelo Nome da empresa, você
selecionaria Sort Order = 1 para o campo País e Sort Order = 2 para o campo NomeDaEmpresa.
Figura 14.18 Uma prévia dos resultados.
23. Muito bem, para o primeiro exemplo, são basicamente estas as definições para os dados que
farão parte do relatório. Dê um clique em OK para fechar a janela do Query Builder e voltar ao
assistente de criação do relatório.
24. Você estará de volta ao assistente, com o comando T-SQL já definido. Para o nosso exemplo, o
Query Builder nos ajudou a criar o seguinte comando:
SELECT NomeDaEmpresa, Endereço, Cidade, Região, País, Telefone
FROM Clientes
ORDER BY NomeDaEmpresa
NOTA
Se você se sente à vontade com os comandos T-SQL, pode digitar o comando diretamente, sem ter que utilizar o Query Builder.

26. Nesta etapa você define se irá criar um relatório do tipo Tabular, que são as tradicionais listagens,
ou um relatório do tipo Matrix, que são conhecidas no Access como “Consultas de Tabela de
Referência Cruzada”. No próximo exemplo faremos um exemplo de relatório do tipo Matrix,
passo a passo. Para este nosso primeiro exemplo, selecione a opção Tabular.
28. Nesta etapa você deve definir se serão feitos agrupamentos no relatório. Neste nosso primeiro exemplo
não iremos trabalhar com agrupamentos. Em um dos próximos exemplos eu explicarei o que é o
agrupamento e como utilizá-lo. Clique em Next, para seguir para a próxima etapa do assistente.
29. Nesta etapa você pode escolher um, dentre diversos layouts sugeridos. Selecione a opção Bold,
Figura 14.19 Selecionando um layout predefinido.

31. Nesta etapa você deve informar o servidor Web onde o relatório será publicado. Você deve informar
o endereço para o servidor onde o Reporting Services está instalado. No nosso exemplo vamos
usar o servidor local. Informe o seguinte endereço http://localhost/ReportServer$JBCURSOS ( o
padrão de nome é ReportServer, o sinal de $ mais o nome da instância). Você também pode
informar o nome de uma pasta. Esta pasta será criada, configurada como um diretório virtual e o
relatório será gravado nesta pasta. Para o nome da pasta digite Exemplos.
33. Será exibida a tela final do assistente, com um resumo das opções que foram selecionadas nas
etapas anteriores. Nesta etapa você também pode definir um nome para o relatório. No campo
Report name, digite: Listagem de Clientes. Marque a opção Preview report para que seja exibida
uma prévia do que será a versão final do relatório. Você pode utilizar o botão Back, para voltar
a qualquer uma das etapas e fazer as alterações necessárias. Clique em Finish para encerrar o
assistente e criar o relatório.
34. O relatório será criado e uma prévia será exibida no SQL Server Business Intelligence Develop-
ment Studio, conforme indicado na Figura 14.20:
35. Mantenha o relatório aberto no SQL Server Business Intelligence Development Studio, pois
vamos continuar a trabalhar com ele, nos próximos tópicos.
Figura 14.20 – Visualização do relatório.
SALVANDO O RELATÓRIO EM DIFERENTES FORMATOS

Muito bem, criamos o relatório. Mas o principal objetivo em criar um relatório é que ele possa ser
utilizado pelos usuários que dele necessitarem. Aí entra em cena mais uma funcionalidade importante
do Reporting Services. Permitir que um relatório seja acessado em diferentes formatos e de diferentes
maneiras. Por exemplo, você pode exportar o relatório para uma série de formatos suportados pelo
Reporting Services. Você pode publicar o relatório no servidor Web, para ser acessado via browser.
Muito bem, vamos aprender a salvar o relatório em diferentes formatos.
Exemplo: Para salvar um relatório em diferentes formatos, siga os passos indicados a seguir:
1. O relatório já deve estar aberto dentro do SQL Server Business Intelligence Development Studio.
NOTA
Se o relatório não estiver aberto, basta abrir o SQL Server Business Intelligence Development Studio e usar o comando File -> Open ->
Project/Solution para abrir o projeto no qual está o relatório.
2. Na área onde o relatório está sendo visualizado, clique com o botão direito do mouse, em
qualquer parte do relatório. Na lista de opções que é exibida aponte para Export. Será exibida
a lista de formatos disponíveis, conforme indicado na Figura 14.21:
Figura 14.21 – Formatos de exportação disponíveis.
3. Clique no formato a ser utilizado. Para o nosso exemplo, clique na opção Acrobat (PDF) file.
Será aberta a janela Save as, para que você selecione a pasta onde serão gravados o arquivo .PDF
e o nome do arquivo. No nosso exemplo, selecionei a pasta Meus documentos e para o nome
do arquivo mantive Listagem de Clientes.pdf, conforme indicado na Figura 14.22:
Figura 14.22 Salvando o relatório no formato .PDF.
4. Clique em Save. Pronto, será gerado um arquivo .PDF, com o nome Listagem de Clientes, na
pasta Meus documentos. Para abrir o relatório no formato .PDF você deve ter o Adobe Reader
instalado no computador. Vá para a pasta Meus documentos e dê um clique duplo no arquivo
Listagem de Clientes.pdf. Pronto, o relatório será aberto, conforme indicado na Figura 14.23:
Figura 14.23 Abrindo o relatório no formato .PDF.
5. Feche o arquivo Listagem de Clientes.PDF.

6. A título de teste, vamos salvar o relatório para o formato de uma planilha do Excel, com o
nome de Pedidos dos Clientes.xls, na pasta Meus documentos.
7. No SQL Server Business Intelligence Development Studio, clique com o botão direito do mouse
em qualquer local do relatório. No menu de opções que é exibido clique em Export -> Excel.
Será aberta a janela Save as, para que você selecione a pasta onde será gravado o arquivo .XLS
e o nome do arquivo. No nosso exemplo, selecionei a pasta Meus documentos e para o nome
do arquivo mantive Listagem de Clientes.xls, conforme indicado na Figura 14.24.
8. Clique em Save. Pronto, será gerado um arquivo .XLS, com o nome Listagem de Clientes.xls,
na pasta Meus documentos. Para abrir o relatório no formato .XLS você deve ter o Microsoft
Excel instalado no computador. Vá para a pasta Meus documentos e dê um clique duplo no
arquivo Listagem de Clientes.xls. Pronto, o relatório será aberto no Excel, conforme indicado
na Figura 14.25.
9. Feche o Excel.
Muto bem. Você viu que para exportar um relatório em um ou mais formatos é bastante simples. Volto
a salientar que uma das principais carecterísticas do Reporting Services é a sua capacidade de ter suas
funcionalidades extendidas. Os programadores podem criar extensões para o Reporting Services, para
permitir que os relatórios sejam exportados para os mais variados formatos.
Figura 14.24 Salvando o relatório no formato .XLS.
Figura 14.25 Abrindo o relatório no formato .XLS.
Agora vamos aprender a publicar o relatório no IIS, de tal forma que ele possa ser acessado usando o
navegador.
PUBLICANDO O RELATÓRIO NO SERVIDOR WEB

Você pode, facilmente, publicar um relatório no servidor Web, de tal forma que o relatório possa ser
acessado usando o navegador. A vantagem deste método é que, uma vez publicado no servidor Web, o
relatório poderá ser acessado a partir de qualquer estação de trabalho da rede, por qualquer usuário
(desde que o usuário tenha permissão de acesso ao relatório), simplesmente usando um navegador.
Muito bem, vamos aprender a publicar o relatório no servidor Web e acessá-lo, usando um navegador.
Exemplo: Para publicar um relatório no servidor Web e acessá-lo usando um navegador, siga os passos
indicados a seguir:
1. O relatório já deve estar aberto dentro do SQL Server Business Intelligence Development Studio.
NOTA
Se o relatório não estiver aberto, basta abrir o SQL Server Business Intelligence Development Studio e usar o comando File -> Open ->
Project/Solution para abrir o projeto no qual está o relatório.
2. Para publicar o relatório no servidor Web, utilize o comando Build -> Deploy Listagem de
Clientes e aguarde até que o SQL Server Business Intelligence Development Studio publique o
relatório no servidor Web. O relatório será publicado, com base nas informações que você
forneceu em uma das últimas etapas do assistente de criação do relatório, onde você informou
o nome do servidor e o nome da pasta onde será publicado o relatório. No nosso exemplo
utilizamos o servidor http://localhost/ReportServer$JBCURSOS, dentro do qual será criada a
pasta Exemplos.
3. Muito bem, o relatório foi publicado no servidor Web. Vamos acessá-lo, usando o Internet
Explorer.
4. Abra o Internet Explorer e acesse o seguinte endereço: http://localhost/ReportServer$JBCURSOS
NOTA
Lembrando que Report Server é o padrão sugerido durante a instalação do SQL Server 2005. Depois deste padrão vem um sinal de $ e
depois o nome da instância. Este padrão pode ser modificado, durante a instalação do SQL Server 2005.
5. Será exibida a listagem de pastas disponíveis no servidor de relatórios, conforme indicado na

Figura 14.26.
6. Dê um clique em Exemplos. Será exibida a lista de relatórios disponíveis.
7. Dê um clique em Listagem de Clientes.
8. O relatório será carregado e exibido no Internet Explorer, conforme indicado na Figura 14.27:
Muito bem, com esse exemplo foi possível mostrar ao amigo leitor o quão fácil é criar um relatório,
publicá-lo no servidor Web e acessá-lo usando o navegador.
Figura 14.26 A pasta Exemplos já criada no servidor Web.
Figura 14.27 Acessando o relatório Listagem de Clientes, usando o Internet Explorer.
Importante: O relatório não é uma página HTML estática, gerada no momento da criação do relatório. Não mesmo. O relatório é uma página
NOTA
dinâmica. Sempre que o relatório é solicitado, é feita uma conexão com o banco de dados e são retornados os dados atualizados, a partir do
SQL Server. Ou seja, no relatório não são gravados os dados obtidos no momento da criação do relatório. Ao invés disso, são gravados os
comandos para acessar os dados a partir do SQL Server. Quando o relatório é solicitado, estes comandos são executados e os dados atualizados
são retornados a partir do SQL Server. Definitivamente, nunca foi tão fácil e produtivo criar relatórios dinâmicos.
A seguir vamos a mais dois exemplos práticos de relatórios, onde criaremos relatórios do tipo Matrix e
usando Grupos. Porém, antes, um pouco de teoria sobre relatórios do tipo Matrix, os quais são conhecidos
no Access como “Consulta de Tabela de Referência Cruzada”. No item a seguir vamos entender o que
é este tal de Matrix (que não tem nada a ver com a trilogia de filmes) ou Referência Cruzada.
DESENVOLVIMENTO EM: CRIANDO RELATÓRIOS DO TIPO MATRIX

PRÉ-REQUISITOS
♦ Conhecimento sobre a criação básica de relatórios com o Reporting Services.
METODOLOGIA
♦ Apresentação dos conceitos sobre relatórios do tipo Matrix e criação de um exemplo prático, passo a passo.
O que é chamado de relatório do tipo Matrix no Reporting Services é muito semelhante às tão famosas
“Consultas de Referências Cruzadas no Access”. Um dos tópicos que mais aparece em fóruns de discussão
do SQL Server é justamente sobre o uso da cláusula TRANSFORM do Access, no SQL Server. A resposta
é que a cláusula TRANSFORM é uma “invenção” do Access. Não é um padrão que existe no T-SQL e,
portanto, não está disponível no SQL Server. Por isso que sempre foi muito mais difícil criar uma
referência cruzada no SQL Server do que no Access.
Mas com o Reporting Sevices do SQL Server 2005 (conforme você poderá constatar na prática), as
coisas ficaram bem mais fáceis. Ficou muito fácil criar um relatório do tipo Referência Cruzada. Porém
antes de partirmos para a prática é fundamental que você entenda o que são, como funcionam e quais
os elementos que compõem uma referência cruzada ou, melhor, usando a terminologia do Reporting
Services, um relatório do tipo “matrix”.
ENTENDENDO AS REFERÊNCIAS CRUZADAS – MATRIX

Inicialmente vamos entender como funcionam as referências cruzadas no Access. Por analogia, será
fácil entender como elas funcionam no Reporting Services e também será fácil cria-las, usando o SQL
Server Business Intelligence Development Studio.
Uma consulta do tipo Tabela de Referência cruzada (ou um relatório do tipo Matrix), conforme o
próprio nome sugere, é utilizada para cruzar valores de duas grandezas. Por exemplo, posso criar uma
consulta do tipo Tabela de Referência cruzada para exibir o número de pedidos (quantitativo de pedidos)
por País De Destino e por ano do campo DataDoPedido, conforme indicado na Figura 14.27.
Podemos observar que as informações retornadas por uma consulta deste tipo são informações
consolidadas, onde estamos cruzando informações do PaísDeDestino, com o Ano da DataDoPedido. A
informação que estamos obtendo é o Quantitativo de Pedidos por Ano e PaísDeDestino.
Numa consulta do tipo Tabela de referência cruzada, temos três elementos básicos:
♦ Linha
♦ Coluna
♦ Valor
Figura 14.28 Informações do quantitativo de Pedidos por PaísDeDestino e ano da DataDoPedido.
Linha: No exemplo da Figura 14.28, o campo que forma as linhas é o campo PaísDeDestino, o que
significa que, para cada país de destino diferente, será retornada uma linha diferente.
Coluna: No exemplo da Figura 14.28, o campo que forma as colunas é o Ano da DataDoPedido, o que
significa que para cada Ano diferente será retornada uma nova coluna.
Valor: No exemplo da figura anterior, os valores que preenchem o restante da consulta são obtidos a
partir da contagem do número de pedidos.
Na Figura 14.29 temos um outro exemplo de referência cruzada:
Figura 14.29 Total anual de vendas por país de destino.
♦ Quais as grandezas que estão sendo “cruzadas” neste relatório?
♦ Quais os elementos Ceste relatório do tipo Matrix?
Respondendo a primeira pergunta: Neste exemplo estamos cruzando valores do campo PaísDeDestino
com o Ano do campo DataDoPedido. No cruzamento, calculamos o total de venda. Ou seja, é um
relatório que nos dá o total anual de vendas por país de destino.
Respondendo a segunda pergunta: O país de destino é o campo linha, ou seja, para cada país diferente,
temos uma linha diferente no resultado do relatório. O Ano da Data do Pedido é o campo coluna, ou
seja, para cada ano diferente, temos uma coluna diferente no resultado do relatório. E por fim a soma
das vendas, por país e por ano, é o campo Valor.
Acredito que com estes dois exemplos teóricos foi possível ter uma boa noção dos elementos que
compõem uma referência cruzada, ou melhor, um relatório do tipo Matrix. Agora vamos fazer um
exemplo prático. Vamos usar o SQL Server Business Intelligence Development Studio para criar o
exemplo da Figura 14.28.
Exemplo prático 01: Criar um relatório do tipo Matrix, o qual exibe o total anual de vendas, por país de
destino. Este relatório será baseado nas tabelas Pedidos e Detalhes do pedido, do banco de dados
NorthwindReport.
Para criar o relatório do tipo Matrix, siga os passos indicados a seguir:
projeto aberto. Para criar um novo relatório, vamos criar um novo projeto. Selecione o comando
File -> New -> Project.
Wizard (já indicada anteriormente na Figura 14.11).
4. No campo Name digite Total de Vendas por País.
6. Clique em OK.
Name, você deve digitar um nome que irá identificar a fonte de dados. Digite: Northwind. Na
lista Type, você define qual o tipo da fonte de dados. Aparecem nesta lista os tipos para os
9. O próximo passo seria digitar a string de conexão, no campo Connection String. Porém, como não
estamos habituados a digitar, manualmente, os dados para a string de conexão, não conhecemos a
sintaxe para uma string de conexão. Felizmente o assistente também pode nos ajudar nesta etapa.
Dê um clique no botão Edit. Será aberta a janela Propriedades de vinculação de dados.
11. Você estará de volta à janela Connection Properties. Na lista OLE DB Provider selecione a
12. Clique no botão Data Links. Será aberta a janela Data Link Properties.
14. Depois você deve informar o tipo de autenticação que está utilizando. Para o nosso exemplo,
15. Abra a lista Select the database on the server e clique na opção NorthwindReport. Sua janela
deve estar com as configurações indicadas na Figura 14.30:
Figura 14.30 Definindo o banco de dados a ser utilizado.
NOTA
Você pode testar se está tudo OK com as configurações da fonte de dados. Para isso clique no botão Test Connection. Será exibida uma
mensagem informando que está tudo OK com a conexão. Clique em OK para fechar esta mensagem.
Você pode marcar a opção Make this a shared data source, para que esta fonte de dados esteja disponível
para outros relatórios que venham a ser criados, dentro deste mesmo projeto. Em um único projeto
criado com o SQL Server Business Intelligence Development Studio, é possível criar vários relatórios.

18. Nesta etapa você poderá digitar diretamente o comando T-SQL da consulta ou usar o Construtor
de consultas (Query Builder). O construtor de consultas é muito semelhante à grade de criação
de consultas do Microsoft Access. Dê um clique no botão Query Builder. Será aberta a janela
Query Builder. A janela aparece, por padrão, sem todas as funcionalidades habilitadas. Dê um
clique no primeiro botão (bem à esquerda). É o botão Generic Query Designer. Ao clicar neste
botão, será exibida a interface completa do Query Builder (sinceramente eu não consegui
entender o porquê de o padrão não vir já com a interface completa).
19. O primeiro passo é adicionar as tabelas nas quais será baseado o relatório. Para adicionar uma ou
mais tabelas, clique no botão Add table (último botão, bem à direita, com um sinal de + amarelo).
Será aberta a janela Add tables, com a lista de tabelas do banco de dados NorthwindReport. Você
pode selecionar mais de uma tabela, pressionando e mantendo pressionada a tecla Ctrl. Mantendo
Ctrl pressionada, vá clicando nas tabelas a serem adicionadas à consulta. Neste nosso primeiro
exemplo, vamos utilizar as tabelas Pedidos e Detalhes do pedido. Marque as tabelas Pedidos e
Detalhes do pedido. Clique no botão Add, para adicionar as tabelas selecionadas.
21. Inicialmente marque o campo PaísDeDestino da tabela Pedidos.
Agora temos uma novidade, que é a criação de campos calculados. Ou seja, vamos criar campos que
não existem diretamente em nenhuma das tabelas. Estes campos serão calculados, quando da execução
do relatório e serão exibidos no relatório. Vamos criar um campo para exibir somente o ano do campo
DataDoPedido e um outro campo que calcula o valor do item de cada pedido. A criação de campos
calculados é bastante simples, conforme mostrarei logo a seguir.
22. Para criar um campo calculado, você coloca a fórmula de cálculo na coluna Column e o nome
do campo vai na coluna Alias. No nosso exemplo, na primeira linha já temos o campo
PaísDeDestino. Na segunda linha, logo abaixo de PaísDeDestino, vamos criar o campo para
extrair somente o ano da DataDoPedido. Vamos iniciar digitando a fórmula de cálculo. Para
isso, utilizaremos a função Year. Na coluna Column, da segunda linha, digite a seguinte fórmula:
Year([DataDoPedido])
Esta fórmula irá extrair somente o ano do campo DataDoPedido. Na coluna Alias, da segunda linha,
digite AnoRef. Este nome é você que escolhe, ou seja, você define o nome da coluna calculada. Agora
vamos criar a outra coluna calculada.
23. Na terceira linha, logo abaixo da linha que extrai o ano, vamos criar o campo para calcular o
total por item de cada pedido. Vamos iniciar digitando a fórmula de cálculo. Na coluna Col-
umn, da terceira linha, digite a seguinte fórmula:
Esta fórmula irá calcular o valor de cada item de cada pedido. Depois, ao ser executado o relatório, será
feito o cruzamento entre País e Ano e, no cruzamento destas informações, será feita a soma de todos os
itens correspondentes. Ou seja, o resultado prático é que teremos a soma do total de vendas por ano,
por país de destino. Mas estas configurações serão feitas em uma das próximas etapas do assistente. Na
coluna Alias, da terceira linha, digite TotalDeVendas. Este nome é você que escolhe, ou seja, você
define o nome da coluna calculada. Agora vamos criar a outra coluna calculada.
Figura 14.31 Criando campos calculados.
24. Vamos ordenar o relatório pelo campo PaísDeDestino. Na linha PaísDeDestino, na coluna Sort
Type, selecione a opção Ascending, para fazer ordenar os resultados em ordem alfabética do
campo PaísDeDestino.
25. Dê um clique em OK para fechar a janela do Query Builder e voltar ao assistente de criação do
relatório.
SELECT Pedidos.PaísDeDestino,
YEAR(Pedidos.DataDoPedido) AS AnoRef,
([Detalhes do Pedido].Quantidade * [Detalhes do Pedido].PreçoUnitário)

* (1 - [Detalhes do Pedido].Desconto)
AS TotalDeVendas
FROM
Pedidos INNER JOIN [Detalhes do Pedido]
ON
Pedidos.NúmeroDoPedido = [Detalhes do Pedido].NúmeroDoPedido
NOTA

Referência Cruzada”. Opa, chegamos exatamente na etapa onde vamos definir que o nosso
relatório será do tipo Matrix. Para o nosso exemplo, selecione a opção Matrix.
30. Nesta etapa é que você irá definir qual campo será o campo linha (Rows), qual campo será o
campo Coluna (Columns) e qual campo será o campo Valor (Details). Temos também uma
opção adicional que é o campo Page, o qual será utilizado no próximo exemplo prático.
No nosso exemplo, temos a seguinte configuração:
♦ PaísDeDestino -> Rows
♦ AnoRef -> Columns
♦ TotalDeVendas -> Details
31. Clique no campo PaísDeDestino para marcá-lo em seguida; clique no botão Rows, para defini-
lo como o campo Linha do Relatório.
32. Clique no campo AnoRef para marcá-lo, em seguida, clique no botão Columns, para defini-lo
como o campo Coluna do Relatório.
33. Clique no campo TotalDeVendas para marcá-lo, em seguida, clique no botão Details, para definí-
lo como o campo Valor do Relatório. Sua janela deve estar conforme indicado na Figura 14.3.
35. Nesta etapa você pode escolher um, dentre diversos layouts sugeridos. Selecione a opção Bold.
37. Nesta etapa você deve informar o servidor Web onde o relatório será publicado. Você deve informar
o endereço para o servidor onde o Reporting Services está instalado. No nosso exemplo vamos
usar o servidor local. Informe o seguinte endereço http://localhost/ReportServer$JBCURSOS (o
padrão de nome é ReportServer, o sinal de $ mais o nome da instância). Você também pode
informar o nome de uma pasta. Esta pasta será criada, configurada como um diretório virtual, e
o relatório será gravado nesta pasta. Para o nome da pasta digite VendasAnuais.
Figura 14.32 Definindo os elementos linha, coluna e valor.

Report name, digite: Vendas Anuais por País. Marque a opção Preview report para que seja
exibida uma prévia do que será a versão final do relatório. Você pode utilizar o botão Back,
para voltar a qualquer uma das etapas e fazer as alterações necessárias. Clique em Finish para
encerrar o assistente e criar o relatório.
ment Studio, conforme indicado na Figura 14.33.
41. Agora vamos publicar o relatório no servidor Web e acessá-lo usando o browser.
42. Para publicar o relatório no servidor Web, utilize o comando Build -> Deploy Total de Vendas
por País e aguarde até que o SQL Server Business Intelligence Development Studio publique o
forneceu em uma das últimas etapas do assistente de criação do relatório, onde você informou
o nome do servidor e o nome da pasta onde será publicado o relatório. No nosso exemplo
utilizamos o servidor http://localhost/ReportServer$JBCURSOS, dentro do qual será criada a
pasta VendasAnuais.
Figura 14.33 Visualização do relatório.
43. Muito bem, o relatório foi publicado no servidor Web. Vamos acessá-lo, usando o Internet Explorer.
NOTA
Lembrando que ReportServer é o padrão sugerido durante a instalação do SQL Server 2005. Depois deste padrão vem um sinal de $ e depois
o nome da instância. Este padrão pode ser modificado, durante a instalação do SQL Server 2005.
Figura 14.33, onde podemos observar que já está disponível a pasta VendasAnuais.
46. Dê um clique em VendasAnuais. Será exibida a lista de relatórios disponíveis.
47. Dê um clique em Vendas Anuais por País.
48. O relatório será carregado e exibido no Internet Explorer, conforme indicado na Figura 14.34.
Ao criar o relatório, o SQL Server Business Intelligence Development Studio cria também uma barra de
ferramentas. A barra de ferramentas é exibida abaixo da barra de endereços do navegador. Nesta barra
você tem botões para se deslocar entre as páginas do relatório (para listagens grandes, que são divididas
em mais de uma página), você também tem um campo para pesquisa dentro do relatório e tem uma
lista para selecionar um formato (lista Select a format). Você pode selecionar um dos formatos disponíveis
e depois clicar no botão Export, para salvar uma cópia do relatório, no formato selecionado. O link
Export só será habilitado depois que for selecionado um formato na lista Select a format. Na barra de
ferramentas você também tem um botão para atualizar o relatório (penúltimo botão) e um botão para
imprimir o relatório (último botão da barra de ferramentas).
Figura 14.34 A pasta VendasAnuais já criada no servidor Web.
Figura 14.35 Acessando o relatório do tipo Matrix, usando o Internet Explorer.
Eu não me canso de elogiar o Reporting Services e as ferramentas relacionadas. Esta, sem dúvida, foi
uma das áreas onde o SQL Server 2005 mais evoluiu, em relação às versões anteriores. Agora vamos a
mais um exemplo prático de criação de relatório do tipo Matrix, onde utilizaremos também o campo
Page. Você verá que a utilização deste campo é capaz de fazer “pequenas maravilhas”.
Exemplo prático 02: Criar um relatório do tipo Matrix, o qual exibe o total anual de vendas, por
produto. Este relatório terá como campo Page o nome do funcionário, para que seja possível filtrar o
relatório para exibir somente as vendas para um determinado funcionário. Este relatório será baseado
nas tabelas Pedidos, Detalhes do pedido, Produtos e Funcionários, do banco de dados NorthwindReport.
Para criar o relatório solicitado, siga os passos indicados a seguir:
projeto aberto. Para criar um novo relatório, vamos criar um novo projeto. Selecione o comando
File -> New -> Project.
Wizard (já indicada anteriormente na Figura 14.11).
4. No campo Name digite Total de Vendas por Produto.
6. Clique em OK.
Name, você deve digitar um nome que irá identificar a fonte de dados. Digite: VendasProduto.
Na lista Type, você define qual o tipo da fonte de dados. Aparecem nesta lista os tipos para os
9. O próximo passo seria digitar a string de conexão, no campo Connection String. Porém, como não
estamos habituados a digitar, manualmente, os dados para a string de conexão, não conhecemos a
sintaxe para uma string de conexão. Felizmente o assistente também pode nos ajudar nesta etapa.
Dê um clique no botão Edit. Será aberta a janela Propriedades de vinculação de dados.
11. Você estará de volta à janela Connection Properties. Na lista OLE DB Provider selecione a
12. Clique no botão Data Links. Será aberta a janela Data Link Properties.
14. Depois você deve informar o tipo de autenticação que você está utilizando. Para o nosso exemplo,
15. Abra a lista Select the database on the server e clique na opção NorthwindReport.
Você pode marcar a opção Make this a shared data source, para que esta fonte de dados esteja disponível para outros relatórios que venham
DICA
a ser criados, dentro deste mesmo projeto. Em um único projeto criado com o SQL Server Business Intelligence Development Studio, é
possível criar vários relatórios.

18. Nesta etapa você poderá digitar diretamente o comando T-SQL da consulta ou usar o construtor
de consultas (Query Builder). Dê um clique no botão Query Builder. Será aberta a janela Query
Builder. A janela aparece, por padrão, sem todas as funcionalidades habilitadas. Dê um clique
no primeiro botão (bem à esquerda). É o botão Generic Query Designer. Ao clicar neste botão,
será exibida a interface completa do Query Builder.
19. O primeiro passo é adicionar as tabelas nas quais será baseado o relatório. Para adicionar uma
à consulta. Neste nosso exemplo, vamos utilizar as tabelas Pedidos, Detalhes do pedido, Produtos
e Funcionários. Marque as tabelas: Pedidos, Detalhes do pedido, Produtos e Funcionários. Clique
no botão Add, para adicionar as tabelas selecionadas.
21. Inicialmente marque o campo NomeDoProduto da tabela Produtos.
Vamos criar um campo para exibir somente o ano do campo DataDoPedido e um outro campo que
calcula o valor do item de cada pedido. A criação de campos calculados é bastante simples, conforme
mostrarei logo a seguir.
22. Para criar um campo calculado, você coloca a fórmula de cálculo na coluna Column e o nome do
campo vai na coluna Alias. No nosso exemplo, na primeira linha já temos o campo
NomeDoProduto. Na segunda linha, logo abaixo de NomeDoProduto, vamos criar o campo para
extrair somente o ano da DataDoPedido. Vamos iniciar digitando a fórmula de cálculo. Para isso,
utilizaremos a função Year. Na coluna Column, da segunda linha, digite a seguinte fórmula:
Year([DataDoPedido])
Esta fórmula irá extrair somente o ano do campo DataDoPedido. Na coluna Alias, da segunda linha,
digite AnoRef. Este nome é você que escolhe, ou seja, você define o nome da coluna calculada. Agora
vamos criar a outra coluna calculada.
23. Na terceira linha, logo abaixo da linha que extrai o ano, vamos criar o campo para calcular o
total por item de cada pedido. Vamos iniciar digitando a fórmula de cálculo. Na coluna Col-
umn, da terceira linha, digite a seguinte fórmula:
([Detalhes do Pedido].Quantidade * [Detalhes do Pedido].PreçoUnitário) * (1 - [Detalhes
do Pedido].Desconto)
NOTA
Observe que aqui usei a nomenclatura complet: [NomeDaTabela].[NomeDoCampo]. Esta nomenclatura é necessária porque o campo
PreçoUnitário está presente tanto na tabela Produtos quanto na tabela Detalhes do Pedido. Por isso, na fórmula de cálculo, temos que utilizar
a nomenclatura completa, para indicar de qual das tabelas deve ser pego o campo PreçoUnitário.
Esta fórmula irá calcular o valor de cada item de cada pedido. Depois, ao ser executado o relatório, será
feito o cruzamento entre Produto e Ano e, no cruzamento destas informações, será feita a soma de
todos os itens correspondentes. Ou seja, o resultado prático é que teremos a soma do total de vendas
por ano, por Produto. Mas estas configurações serão feitas em uma das próximas etapas do assistente.
Na coluna Alias, da terceira linha, digite TotalDeVendas. Este nome é você que escolhe, ou seja, você
define o nome da coluna calculada. Agora vamos criar a outra coluna calculada.
24. Vamos criar mais um campo calculado. Na verdade não é um campo que fará cálculos, mas que
tão-somente irá juntar os campos Nome e Sobrenome, da tabela Funcionários, para exibir o nome
completo do funcionário. Na quarta linha, logo abaixo da linha que calcula o total por item do
pedido, vamos criar o campo para exibir o nome completo do funcionário. Vamos iniciar digitando
a fórmula de cálculo. Na coluna Column, da quarta linha, digite a seguinte fórmula:
Funcionários.Nome + N’ ‘ + Funcionários.Sobrenome
Na coluna Alias, da quarta linha, digite Funcionário. Este nome é você que escolhe, ou seja, você
define o nome da coluna calculada.
Sua janela deve estar semelhante a indicada na Figura 14.36.
25. Vamos ordenar o relatório pelo campo NomeDoProduto. Na linha NomeDoProduto, na coluna
do campo NomeDoProduto.
relatório.
SELECT Produtos.NomeDoProduto, YEAR(Pedidos.DataDoPedido) AS AnoRef, ([Detalhes do
Pedido].Quantidade * [Detalhes do Pedido].PreçoUnitário)
* (1 - [Detalhes do Pedido].Desconto) AS TotalDeVendas,
Funcionários.Nome + N’ ‘ + Funcionários.Sobrenome AS Funcionário
FROM Pedidos INNER JOIN
[Detalhes do Pedido] ON Pedidos.NúmeroDoPedido = [Detalhes do
Pedido].NúmeroDoPedido INNER JOIN
Funcionários ON Pedidos.CódigoDoFuncionário =
Funcionários.CódigoDoFuncionário INNER JOIN
Produtos ON [Detalhes do Pedido].CódigoDoProduto =
Produtos.CódigoDoProduto
ORDER BY Produtos.NomeDoProduto
Figura 14.36 Criando campos calculados.
Se você se sente à vontade com os comandos T-SQL, pode digitar o comando diretamente, sem ter que utilizar o Query Builder. Porém
NOTA
observe que à medida que as consultas se tornam mais complexas fica bastante difícil a criação dos comandos, manualmente, sem a ajuda
do Query Builder.

Referência Cruzada”. Opa, chegamos exatamente na etapa onde vamos definir que o nosso
relatório será do tipo Matrix. Para o nosso exemplo, selecione a opção Matrix.
31. Nesta etapa é que você irá definir qual campo será Page, qual campo será o campo linha (Rows),
qual campo será o campo Coluna (Columns) e qual campo será o campo Valor (Details).
No nosso exemplo, temos a seguinte configuração:
♦ Funcionário -> Page
♦ PaísDeDestino -> Rows
♦ AnoRef -> Columns
♦ TotalDeVendas -> Details
32. Clique no campo NomeDoProduto para marcá-lo; em seguida, clique no botão Rows, para
defini-lo como o campo Linha do Relatório.
33. Clique no campo AnoRef para marcá-lo; em seguida, clique no botão Columns, para defini-lo
como o campo Coluna do Relatório.
34. Clique no campo TotalDeVendas para marcá-lo; em seguida, clique no botão Details, para
defini-lo como o campo Valor do Relatório.
35. Clique no campo Funcionário para marcá-lo; em seguida, clique no botão Page, para defini-lo
como o campo Page do Relatório. Sua janela deve estar conforme indicado na Figura 14.37:
Figura 14.37 Definindo os elementos linha, coluna, valor e page.

37. Nesta etapa você pode escolher um, dentre diversos layouts sugeridos. Selecione a opção Bold.
39. Nesta etapa você deve informar o servidor Web onde o relatório será publicado. Você deve
informar o endereço para o servidor onde o Reporting Services está instalado. No nosso exemplo
vamos usar o servidor local. Informe o seguinte endereço http://localhost/
ReportServer$JBCURSOS (o padrão de nome é ReportServer, o sinal de $ mais o nome da
instância). Você também pode informar o nome de uma pasta. Esta pasta será criada, configurada
como um diretório virtual e o relatório será gravado nesta pasta. Para o nome da pasta digite
VendasPorProduto.
Report name, digite: Vendas Anuais por Produto. Marque a opção Preview report para que seja
44. Para publicar o relatório no servidor Web, utilize o comando Build -> Deploy Total de Vendas por
Produto e aguarde até que o SQL Server Business Intelligence Development Studio publique o
relatório no servidor Web. O relatório será publicado, com base nas informações que você forneceu
em uma das últimas etapas do assistente de criação do relatório, onde você informou o nome do
servidor e o nome da pasta onde será publicado o relatório. No nosso exemplo utilizamos o servidor
http://localhost/ReportServer$JBCURSOS, dentro do qual será criada a pasta VendasPorProduto.
Explorer.
NOTA
47. Será exibida a listagem de pastas disponíveis no servidor de relatórios, onde podemos observar
que já está disponível a pasta VendasPorProduto.
48. Dê um clique em VendasPorProduto. Será exibida a lista de relatórios disponíveis.
49. Dê um clique em Vendas Anuais por Produto.
Figura 14.39 Acessando o relatório do tipo Matrix, usando o Internet Explorer.
Observe que o relatório foi separado por funcionário. Ou seja, na primeira página são exibidos os
dados apenas para o funcionário Andrew Fuller. Se você clicar no botão >, para ir para a próxima
página, continuam sendo exibidos dados para o funcionáiro Andrew Fuller. Clique em > para ir para a
página 3. Observe que começaram a ser exibidos dados para o funcionário Anne Dodsworth e assim
por diante. Esta separação é resultado do uso de um campo – justamente o campo Funcionário, como
um elemento Page, do relatório do tipo Matrix.
Muito bem, no próximo item vamos aprender a criar um relatório que usa a opção de Grupos. Depois,
para finalizar o capítulo, vamos aprender a utilizar as funções básicas do console de gerenciamento do
Reporting Services. Mais uma vez, vamos aprender, novamente, através de exemplos práticos.
CRIANDO RELATÓRIOS USANDO A OPÇÃO GRUPOS

Nosso último exemplo de criação de relatórios utilizará a opção Grupos. Com esta opção, podemos
dividir um relatório em um ou mais grupos. Já me explico melhor. Por exemplo, vamos imaginar uma
listagem de pedidos. Esta listagem pode ser dividida em grupos. Por exemplo, vamos definir o campo
PaísDeDestino como sendo um grupo. Com isso, seriam listados todos os pedidos de um país, depois
todos os pedidos do próximo país e assim por diante. O nome do país só seria exibido uma vez, no
início da listagem de pedidos do respectivo país. Agora vamos acrescentar mais um nível de grupo, o
campo CidadeDeDestino. Com isso teríamos todos os pedidos de um país juntos e, dentro destes
pedidos, uma divisão por cidades. Por exemplo, todos os pedidos para o Brasil ficariam juntos. Dentro
do Brasil, viriam primeiro todos os pedidos de Campinas, depois todos os pedidos do Rio de Janeiro,
depois todos os pedidos de São Paulo e assim por diante. O nome da cidade é exibido somente uma
vez, no início da listagem dos pedidos da respectiva cidade.
Logo em seguida vamos fazer um exemplo prático de relatório que usa a opção de grupos. No exemplo
prático, vamos utilizar uma abordagem um pouco diferente da que vínhamos utilizando até aqui. Em
todos os exemplos anteriores, eu sempre criava um novo projeto e, dentro do novo projeto, eu criava
um novo relatório. No próximo exemplo, eu vou abrir um dos projetos criados anteriormente e, dentro
deste novo projeto, vou criar um novo relatório. O objetivo é salientar que, dentro de um mesmo
projeto, posso ter diversos relatórios. Muto bem, vamos à prática.
Exemplo prático: Criar um relatório de pedidos, onde são exibidos os seguintes campos:
NúmeroDoPedido, DataDoPedido, NomeDaEmpresa (da tabela Clientes), PaísDeDestino,
CidadeDeDestino e TotalDoPedido (que será um campo calculado). Defini os campos PaísDeDestino e
CidadeDeDestino como campos de grupo.
Para criar o relatório proposto siga os passos indicados a seguir:
projeto aberto. Vamos abrir o projeto Listagem de Clientes, criado em um dos exemplos
anteriores. Para abrir um novo projeto selecione o comando File -> Open -> Project/Solution.
Será aberta a janela Open Project. Clique no projeto Listagem de Clientes para selecioná-lo,
Figura 14.40 Abrindo o projeto Listagem de Clientes.
3. Clique no botão Open.

4. Será exibida a lista de arquivos disponíveis na pasta do projeto. Dê um clique duplo no arquivo
Listagem de Clientes.sln, que é o arquivo de projeto a ser aberto.
5. Agora vamos adicionar um novo relatório ao projeto Listagem de Clientes. Para adicionar um
novo relatório selecione o comando Project -> Add New Item.
6. Será aberta a janela Add New Item – Listagem de Clientes. Clique na opção Report Wizard para
marcá-la. No campo Name digite ListagemPaisCidade.rdl e depois clique no botão Add.
7. Será aberto o assistente para criação de um novo relatório, o qual já é bem conhecido, uma vez
que utilizamos este assistente nos exemplos anteriores. A primeira tela do assistente é apenas
informativa. Clique em Next, para seguir para a próxima etapa do assistente.
8. Como estamos trabalhando com um projeto já existente, poderemos utilizar as fontes de dados
que já foram criadas anteriormente, desde que estas tenham sido configuradas para ser uma
fonte de dados compartilhada (Make this a shared data source). É o caso do nosso exemplo,
onde vamos utilizar a fonte de dados NorthwindReport, já criada quando foi criado o projeto
Listagem de Clientes. Você pode usar uma fonte de dados já criada anteriormente ou criar uma
nova fonte de dados, se isso for necessário. Para criar uma nova fonte de dados, você deve
marcar a opção New data source e fornecer as informações sobre a nova fonte. No nosso exemplo,
vamos utilizar a fonte já existente NorthwindReport, conforme indicado na Figura 14.41.
9. Clique em Next para seguir para a próxima etapa do assistente.
10. Nesta etapa você poderá digitar diretamente o comando T-SQL da consulta ou usar o construtor
de consultas (Query Builder). Dê um clique no botão Query Builder. Será aberta a janela Query
Builder. A janela aparece, por padrão, sem todas as funcionalidades habilitadas. Dê um clique
no primeiro botão (bem à esquerda). É o botão Generic Query Designer. Ao clicar neste botão,
será exibida a interface completa do Query Builder (sinceramente eu não consegui entender o
porquê de o padrão não vir já com a interface completa).
Figura 14.41 Usando uma fonte de dados já existente.
11. O primeiro passo é adicionar as tabelas nas quais será baseado o relatório. Para adicionar uma
à consulta. Neste nosso exemplo, vamos utilizar as tabelas Pedidos, Detalhes do pedido e Clientes.
Marque as tabelas: Pedidos, Detalhes do pedido e Clientes. Clique no botão Add, para adicionar
as tabelas selecionadas.
13. Inicialmente marque os campos NomeDaEmpresa da tabela Clientes e os campos
NúmeroDoPedido, DataDoPedido, PaísDeDestino e CidadeDeDestino, da tabela Pedidos.
14. Agora vamos criar o campo calculado, para ter o total por item de cada pedido. Para criar um
campo calculado, você coloca a fórmula de cálculo na coluna Column e o nome do campo vai
na coluna Alias. Na primeira linha em branco, logo abaixo de CidadeDeDestino, vamos criar o
campo para cálculo do total por item do pedido. Vamos iniciar digitando a fórmula de cálculo.
Na coluna Column, da terceira linha, digite a seguinte fórmula:
Esta fórmula irá calcular o valor de cada item de cada pedido. Na coluna Alias, digite Valor Total.
Importante: Se deixarmos a listagem assim como está, será exibido o valor total para cada item de cada pedido. Por exemplo, se um pedido
NOTA
tiver 5 itens, serão exibidas cinco linhas no relatório, uma para cada item. O que queremos é agrupar todos os itens de um mesmo pedido e
fazer a soma destes valores. Se fosse no Access, usaríamos a linha Total. Mas acontece que esta funcionalidade também está disponível no
Query Builder. Para isso, clique no botão Group by (penúltimo botão, do lado esquerdo do botão Add table). Observe que, após clicar no
botão Group by, uma nova coluna será exibida, justamente a coluna Group by. Nesta coluna, mantenha a opção Group by selecionada para
todos os campos, com exceção do campo Valor Total. Para este campo, selecione a opção Sum, para que seja feita a soma de todos os itens
de um mesmo pedido.
Figura 14.42 A opção Group by.
15. Vamos ordenar o relatório pelo campo NúmeroDoPedido. Na linha NúmeroDoPedido, na coluna
do campo NúmeroDoPedido.
relatório.
SELECT Pedidos.NúmeroDoPedido, Clientes.NomeDaEmpresa, Pedidos.DataDoPedido,
Pedidos.PaísDeDestino, Pedidos.CidadeDeDestino,
SUM(([Detalhes do Pedido].Quantidade * [Detalhes do
Pedido].PreçoUnitário) * (1 - [Detalhes do Pedido].Desconto)) AS ValorTotal
FROM Clientes INNER JOIN
Pedidos ON Clientes.CódigoDoCliente = Pedidos.CódigoDoCliente INNER
JOIN
[Detalhes do Pedido] ON Pedidos.NúmeroDoPedido = [Detalhes do
GROUP BY Clientes.NomeDaEmpresa, Pedidos.NúmeroDoPedido, Pedidos.DataDoPedido,
Pedidos.PaísDeDestino, Pedidos.CidadeDeDestino
NOTA

Referência Cruzada”. Para este nosso exemplo será um relatório do tipo Tabular. Certifique-se
de que esta opção esteja marcada.
21. Nesta etapa é que vamos definir quais os campos que formarão os grupos do relatório. No
nosso exemplo são os campos PaísDeDestino e CidadeDeDestino. Clique no campo
PaísDeDestino para selecioná-lo, depois clique no botão Group. Clique no campo
CidadeDeDestino para selecioná-lo e depois clique no botão Group. Os demais campos farão
parte da seção detalhes do relatório. Use a tecla Ctrl para marcar os demais campos e depois
clique no botão Details. Sua janela deve estar conforme indicado na Figura 14.43:
Figura 14.4 Definindo os elementos linha, coluna e valor.
23. Nesta etapa você pode escolher um, dentre diversos layouts sugeridos. Selecione a opção Stepped.
Nesta etapa você também define se devem ser incluídos, nos relatórios, subtotais por grupo.
Por exemplo, você pode incluir ao final da lista de pedidos de cada cidade a soma de todos os
pedidos da cidade; ao final dos pedidos de um país, a soma de todos os pedidos do país e assim
por diante. Para isso, marque a opção Include subtotals. Marque também a opção Enable
drilldown, para adicionar mais interatividade ao relatório, conforme mostrarei na hora de
acessar o relatório, mais adiante.
25. Nesta etapa você pode escolher um dentre diversos estilos disponíveis. Marque a opção Bold.
NOTA
O relatório será publicado no servidor Web associado ao projeto (que no nosso exemplo é em http://localhost/ReportServer$JBCURSOS) e
na pasta associada ao projeto, que no nosso exemplo é a pasta Exemplos. Estas opções foram configuradas quando o projeto foi criado e
todos os relatórios que fazem parte do projeto utilizarão estas definições.
Report name, digite: Listagem por País e Cidade. Marque a opção Preview report para que seja
30. Para publicar o relatório no servidor Web, utilize o comando Build -> Deploy Listagem de
Clientes e aguarde até que o SQL Server Business Intelligence Development Studio publique o
forneceu durante a criação do projeto, onde você informou o nome do servidor e o nome da
pasta onde será publicado o relatório. No nosso exemplo utilizamos o servidor http://localhost/
ReportServer$JBCURSOS, dentro do qual será utilizada a pasta Exemplos.
Explorer.
NOTA
Figura 14.45, onde podemos observar que já está disponível a pasta Exemplos:
Figura 14.45 A pasta Exemplos, associada ao projeto.
34. Dê um clique em Exemplos. Será exibida a lista de relatórios disponíveis. No nosso exemplo
estão disponíveis dois relatórios no mesmo projeto: Listagem de Clientes (criado anteriormente)
e Listagem por País e Cidade (criado no nosso último exemplo).
35. Dê um clique em Listagem por País e Cidade.
Figura 14.46 Acessando o relatório com grupos, usando o Internet Explorer.
37. Observe o sinal de + ao lado do nome de cada país. Este sinal de + é a chamada capacidade de
Drilldown, a qual você marcou para ser criada, em uma das etapas do assistente. Experimente
clicar no sinal de + ao lado de Alemanha. Observe que agora foi exibida a listagem de cidades
da Alemanha, juntamente com o total de vendas para a cidade. Clique no sinal de + ao lado da
primeira cidade Aachen. Observe que agora é exibida a listagem de todos os pedidos para
Aachen, conforme indicado na Figura 14.47.
Muito bem, com isso encerramos os nossos exemplos práticos, sobre a criação, publicação e utilização
de relatórios, usando o Reporting Services. É ou não é uma verdadeira maravilha este serviço?
No próximo tópico, no qual encerraremos o capítulo, falarei sobre o console Reporting Services Con-
figuration e mostrarei como executar as principais tarefas de configuração do Reporting Services,
utilizando este console.
Figura 14.47 Usando a capacidade de Drilldown.
DESENVOLVIMENTO EM: O CONSOLE REPORTING SERVICES CONFIGURATION

PRÉ-REQUISITOS
♦ Conhecimento básico dos elementos que compõem o Reporting Services.
METODOLOGIA
♦ Apresentação dos elementos que compõem o console Reporting Services Configuration.
INTRODUÇÃO AO CONSOLE REPORTING SERVICES CONFIGURATION

Este console permite que você faça uma série de configurações, tais como a pasta virtual através da
qual são acessados os relatórios, a pasta virtual através da qual é possível configurar diversas opções do
Reporting Services usando o navegador e uma série de outras configurações. Neste tópico, mostrarei
um exemplo prático, onde você fará um passeio pelas opções disponíveis no console Reporting Ser-
vices Configuration.
Exemplo prático: Abrir o console Reporting Services Configuration e verificar as opções de configuração
disponíveis. Siga os passos indicados a seguir:
1. Abra o console Reporting Services Configuration: Iniciar -> Programas -> Microsoft SQL Server
2005 -> Configuration tools -> Reporting Services Configuration.
2. Será aberta uma janela para que você informe o nome do servidor a ser conectado e da instância.
Por padrão, vem selecionado o servidor local onde você está executando o console Reporting
Services Configuration. Clique no botão Find, para localizar as instâncias disponíveis neste servidor.
3. Na lista Instance name selecione a instância desejada, conforme exemplo da Figura 14.48:
Figura 14.48 Informando o servidor e a instância.
4. Clique no botão Connect.

5. A conexão será efetuada e será exibida a tela principal do console Reporting Services Configu-
ration. No painel da esquerda são exibidas as opções disponíveis, conforme indicado na Figura
14.49, onde por padrão vem selecionada a opção para gerenciamento do serviço Report Server.
Nesta tela você pode inicializar ou parar o serviço. No exemplo da Figura 14.49, o serviço está
sendo executado. Se fosse necessário, você poderia clicar no botão Stop para parar o serviço.
Figura 14.49 O console Reporting Services Configuration.
6. No painel da direita, dê um clique na opção Report Server Virtual Directory. Nesta opção você
define a pasta virtual, através da qual os relatórios publicados podem ser acessados e em qual
dos sites (lembrando que em um único servidor IIS posso ter vários sites configurados) estará
esta pasta. No nosso exemplo estamos usando a pasta virtual ReportServer$JBCURSOS e o Web
site padrão. Defina as configurações desejadas e clique no botão Apply para salvá-las.
7. No painel da direita, dê um clique na opção Report Manager Virtual Directory. Nesta opção
você define a pasta virtual, através da qual é possível acessar praticamente todas as opções para
configuração e gerenciamento dos relatórios disponíveis. No nosso exemplo estamos usando a
pasta virtual Reports$JBCURSOS e o Web site padrão. O padrão sugerido, durante a instalação
do Reporting Services, é o nome Reports, um sinal de $ e o nome da instância. No nosso
exemplo, ao acessar o endereço http://localhost/Reports$JBCURSOS, você terá acesso a uma
grande quantidade de opções de configuração dos relatórios. Na Figura 14.50 podemos ver esta
página, carregada no navegador:
Figura 14.50 Acessando http://localhost/Reports$JBCURSOS
8. Defina as configurações desejadas e clique no botão Apply para salvá-las.

9. No painel da direita, dê um clique na opção Windows Service Identity. Nesta opção você de-
fine a conta com a qual irá rodar o serviço Report Server. Defina as configurações desejadas e
clique no botão Apply para salvá-las. Na guia Web Service Identity, você define no contexto de
qual aplicação Web o serviço do Report Server irá rodar. Defina as configurações desejadas e
clique no botão Apply para salvá-las.
10. No painel da direita, dê um clique na opção Database Setup. Nesta opção, indicada na Figura
14.51, você define em qual servidor e instância ficará o banco de dados utilizado pelo Reporting
Services. Informações sobre os relatórios publicados, configurações do serviço configurações de
segurança e demais informações necessárias ao funcionamento do Reporting Services ficam todas
neste banco de dados. Defina as configurações desejadas e clique no botão Apply para salvá-las.
Figura 14.51 Definindo onde ficará o banco de dados do Reporting Services.
11. Você também tem a opção para gerenciar as chaves de criptografia – Encription Keys; uma
opção que exibe o status da inicialização do serviço Report Server – Initialization; uma opção
para configurar as opções para envio de relatórios via e-mail – Email Settings; e uma opção para
definir uma conta no contexto da qual serão executados os relatórios – Execution Account.
12. Para fechar o console Reporting Services Configuration clique no botão Exit.
CONCLUSÃO
Este foi um capítulo completamente dedicado ao Reporting Services. Este, na minha opinião, foi um
dos serviços que mais apresentou melhorias e novidades em relação às versões anterioes do SQL Server.
Iniciei o capítulo apresentando o Reportng Services, falando sobre os elementos que o compõem e a
funcionalidade de cada um destes elementos.
Em seguida passei a mostrar como criar uma série de relatórios, a publicar os relatórios, a acessá-los via
browser e a salvá-los em diferentes formatos. Apresentei exemplos, passo a passo, que mostraram
como criar os seguintes tipos de relatórios:
♦ Listagem simples
♦ Matrix
♦ Matrix com a opção Page
♦ Listagem com grupos
Para encerrar o capítulo, apresentei a ferramenta Reporting Services Configuration, a qual nos dá
acesso a uma série de opções de configuração do Reporting Services.
Evidentemente que existem muito mais coisas sobre o Reporting Services. Mas dentro do escopo proposto
para este capítulo, vamos parando por aqui. Sem nenhuma dúvida, daria para escrever um livro inteiro
sobre o Reporting Services (e certamente serão lançados livros inteiros, só sobre o Reporting Services).
No próximo capítulo mostrarei, através de exemplos práticos, como utilizar algumas das principais
novidades do SQL Server 2005, as quais, por questões de organização do livro, não puderam ser
apresentadas, juntamente com as demais novidades, apresentadas nos capítulos anteriores.
Capítulo 15
EXEMPLOS PRÁTICOS E MAIS
NOVIDADES DO SQL SERVER 2005
INTRODUÇÃO
Neste capítulo eu apresentarei, na forma de exemplos práticos, mais algumas novidades do SQL Server
2005. Apresentarei novidades que, por motivos de organização do livro, não puderam ser colocadas
nos capítulos anteriores. Também apresentarei alguns exemplos práticos sobre tarefas comuns ao dia-
a-dia do DBA (Database Administrator). Este é o típico capítulo do tipo “Salada de Frutas”. Ou seja, um
tópico aqui, outro ali e assim por diante. Julguei importante incluir este capítulo, porque nele abordo
tópicos práticos, que certamente o DBA usará no seu trabalho diário.
Vamos iniciar o capítulo aprendendo a trabalhar com uma importante novidade do SQL Server 2005:
A criação de snapshots de um banco de dados – Database snapshot. Um snapshot de um banco de
dados é uma cópia estática, somente-leitura do banco de dados (o snapshot é uma cópia somente
leitura do banco de dados original). Podemos criar vários snapshots de um mesmo banco de dados. O
snapshot só pode ser criado na mesma instância do banco de dados original. O snapshot é uma cópia
fiel do banco de dados original. O snapshot é mantido, até que seja excluído pelo administrador.
Vários são os usos práticos que justificam a criação de um ou mais snapshots de um banco de dados.
Por exemplo, posso criar um snapshot só para atender requisições de relatórios, os quais não têm a
necessidade de serem gerados em tempo real. Serve como uma cópia adicional de segurança, pois o
snapshot pode ser usado para restaurar um banco de dados, ao estado em que este se encontrava,
quando foi gerado o snapshot. Esta pode ser uma opção útil quando outras opções, tais como o restore,
falharam. Neste capítulo você aprenderá mais sobre snapshots e verá exemplos práticos de como criar
um snapshot de um banco de dados.
NOTA
Importante: A opção Database snapshot está disponível somente no SQL Server 2005 Enterprise Edition.
O próximo tópico que irei abordar neste capítulo é sobre a criação de diagramas de um banco de
dados. Os diagramas nos permitem ter uma visão geral da estrutura do banco de dados: tabelas, chaves
primárias, chaves estrangeiras e relacionamentos. É uma excelente ferramenta também para
documentação da estrutura do banco de dados.
Na seqüência apresentarei o passo-a-passo sobre como realizar uma série de tarefas úteis, bastante
comuns ao dia-a-dia do DBA:
♦ Como transferir um banco de dados de uma instância para outra.
♦ Como trabalhar com tabelas, diretamente no SQL Server Management Studio.
♦ Usar a opção de geração de scripts do SQL Server Management Studio.
Para encerrar o capítulo farei uma descrição detalhada das diferentes edições do SQL Server 2005. Estão
disponíveis as seguintes edições:
♦ SQL Server 2005 Enterprise Edition (32-bits e 64-bits)
♦ SQL Server 2005 Standard Edition (32-bits e 64-bits)
♦ SQL Server 2005 Workgroup Edition (somente 32-bits)
CAPÍTULO 15 – EXEMPLOS PRÁTICOS E MAIS NOVIDADES DO SQL SERVER 2005
♦ SQL Server 2005 Developer Edition (32-bits e 64-bits)
♦ SQL Server 2005 Express Edition (somente 32-bits)
DESENVOLVIMENTO EM: SNAPSHOT DATABASES

PRÉ-REQUISITOS
METODOLOGIA
♦ Exemplo prático de criação e administração de snapshot Databases.
QUANDO USAR A OPÇÃO DE SNAPSHOT

Um snapshot de um banco de dados é uma cópia estática, somente-leitura deste banco de dados (o
snapshot é uma cópia somente leitura do banco de dados original). Podemos criar vários snapshots de
um mesmo banco de dados. O snapshot só pode ser criado na mesma instância do banco de dados
original. O snapshot é uma cópia fiel do banco de dados original. O snapshot é mantido, até que seja
excluído pelo administrador.
A seguir apresento algumas situações onde pode ser indicada a criação de snapshots de um banco de dados.
♦ Manter um histórico dos dados, para a geração de relatórios: Imagine um banco de dados
de pedidos. Pode ser que você queira manter no banco de dados somente os pedidos do ano
corrente. Porém, você pode querer fazer relatórios que englobem estatísticas completas, com
dados dos pedidos de todos os anos. Uma opção é fazer um snapshot do banco de dados, ao
final de cada ano e depois zerar os pedidos, para iniciar o ano seguinte só com os pedidos do
ano corrente. Havendo espaço em disco, você pode até mesmo criar e manter snapshots de
períodos diferentes, para facilitar a geração de relatórios.
♦ Criar uma cópia para ser usada em emergências: Em caso de erros graves com o banco de
dados principal e tendo também falhado os processos de restore, o snapshot é uma opção para
que a perda não seja total. Ou seja, ao usar um snapshot do banco de dados, serão perdidas
somente as alterações feitas após a geração do snapshot. Claro que não é uma situação ideal,
mas em caso de “catástrofes maiores”, é uma maneira de evitar a perda total dos dados, ou pelo
menos, minimizar a perda.
♦ Proteger os dados contra erros de operação e criar um banco de dados de teste: Erros do
DBA podem ocorrer e geralmente são desastrosos. Como o DBA, geralmente, tem poderes
totais sobre o banco de dados, os erros cometidos pelo DBA causam grandes estragos. Quando
você precisa fazer testes, verificar se um script está funcionando corretamente, testar um stored
procedure ou uma operação que irá alterar um grande volume de dados, você pode seguir os
seguintes passos: Criar um snapshot do banco de dados e fazer os testes que precisam ser feitos
no snapshot. Se tudo der certo, você pode aplicar os mesmos passos no banco de dados princi-
pal. Se algo der errado, o problema ocorrerá no snapshot. Ou seja, o banco de dados original
estará intacto. É muito melhor descobrir os erros enquanto você testa as operações no snap-
shot do que descobri-los, testando diretamente no banco de dados de produção.
♦ Criar snapshots, periodicamente, para minimizar problemas com erros de operação:
Se houver espaço em disco suficiente, você pode criar uma série de snapshots no decorrer
do dia, para minimizar possíveis perdas com erros de operação no banco de dados. Além
disso, você pode definir um determinado número de snapshots a serem mantidos. Quando
um novo snapshot é gerado, o mais antigo é excluído, para manter apenas o número de
snapshots que você definiu. Quando houver um erro de operação, você pode utilizar o
snapshot mais recente, para recuperar o banco de dados. Claro que sempre haverá o
problema da perda das alterações efetuadas entre o último snapshot e o momento em
que ocorreu o problema.
LIMITAÇÕES EM RELAÇÃO AO USO DE SNAPSHOTS

Neste tópico, apresentarei as limitações que existem em relação ao uso de snapshots Databases.
LIMITAÇÕES EM RELAÇÃO AO BANCO DE DADOS FONTE

O banco de dados fonte é o banco de dados original, a partir do qual serão criados um ou mais snap-
shots. Após a criação do primeiro snapshot, algumas restrições passam a ser impostas para o banco de
dados fonte:
♦ O banco de dados fonte não poderá ser mais excluído, desanexado (ou “desatachado”, como
preferirem) ou sofrer um restore a partir de um backup. O backup do banco de dados funciona
normalmente, após a criação de um ou mais snapshots.
♦ Ao criar o snapshot, as páginas de dados não são copiadas do banco de dados fonte para o
snapshot. Ao invés disso, somente um ponteiro é criado no snapshot, ponteiro este que aponta
para a página original de dados. Quando uma página de dados for atualizada pela primeira vez,
após a criação do snapshot, a página, sem a atualização, será copiada para o snapshot. Com
isso fica no banco de dados fonte a página modificada (a qual terá também todas as subseqüentes
modificações) e no snapshot, a página original, como estava, no momento em que o snapshot
foi gerado. Esta operação de cópia da página original para o snapshot, na primeira vez que a
página original é modificada, é conhecida como “copy-on-write operation”. Dependendo do
número de operações “copy-on-write operation” que são executadas e do número de snap-
shots que forem criados, pode ocorrer um grande aumento de operações de I/O no banco de
dados original, o que pode afetar o desempenho deste banco de dados.
♦ Não é possível excluir arquivos de dados do banco de dados fonte e nem dos snapshots, enquanto
existir um ou mais snapshots do banco de dados.
LIMITAÇÕES EXISTENTES NOS SNAPSHOTS DO BANCO DE DADOS

A partir de um banco de dados, podem ser criados um ou mais snapshots. Nos snapshots, existem
algumas limitações, as quais descrevo a seguir:
♦ O snapshot só pode ser criado na mesma instância do banco de dados original.
♦ O banco de dados snapshot é uma cópia fiel do banco de dados original, no momento em
que o snapshot é criado, menos as transações que ainda estão com o estado “uncommitted”,
no banco de dados original. As transações neste estado sofrem um roll back no snapshot. O
banco de dados original não é afetado. As alterações que forem feitas no banco de dados
original não serão replicadas para os snapshots existentes (se não seria replicação e não um
simples snapshot).
♦ Os snapshots são bancos de dados do tipo Read Only, ou seja, não é possível incluir, alterar ou
excluir dados das tabelas do snapshot.
♦ Não é possível criar snapshots dos bancos de dados model, master e temp.
♦ Não é possível fazer alterações nas propriedades dos arquivos (primário, secundário ou de log)
dos snapshots.
♦ Não é possível excluir arquivos (secundários ou de log) de um snapshot.
♦ Não é possível fazer backup ou restore de um snapshot.
♦ Não é possível “atachar” ou “desatachar” arquivos de um snapshot.
♦ Só é possível criar snapshots em partições formatadas com NTFS.
♦ O serviço Full-text indexing não é suportado nos snapshots e os full-text catalogs criados no
banco de dados original não são copiados para os snapshots.
♦ Quando o snapshot é criado, ele herda as restrições de segurança contidas no banco de dados
original. Como os snapshots são “somente leitura” (read only), as permissões herdadas não
podem ser alteradas e alterações feitas nas permissões de segurança do banco de dados original
não serão propagadas para os snapshots.
REQUERIMENTOS DE ESPAÇO EM DISCO

Aqui é importante lembrar como funciona a criação de snapshots, em termos das páginas de dados
do banco de dados. Ao criar o snapshot, as páginas de dados não são copiadas do banco de dados
fonte para o snapshot. Ao invés disso, somente um ponteiro é criado no snapshot, ponteiro este
que serve como uma referência para a página original de dados. Quando uma página de dados for
atualizada pela primeira vez, após a criação do snapshot, a página, sem a atualização, ou seja,
como era no momento da criação do snapshot, será copiada para o snapshot. Com isso fica no
banco de dados fonte a página modificada (a qual terá também todas as subseqüentes modificações)
e no snapshot, a página original, como estava no momento em que o snapshot foi gerado. Esta
operação de cópia da página original para o snapshot, na primeira vez que a página original é
modificada, é conhecida como “copy-on-write operation”. Dependendo do número de operações
“copy-on-write operation” que são executadas e do número de snapshots que forem criados, pode
ser necessária uma grande quantidade de espaço em disco, para que as páginas possam ser copiadas
para os snapshots.
Se ocorrer de não haver espaço em disco, quando o SQL Server precisar copiar uma página, o snapshot
será marcado com o status “suspect” e não poderá mais ser utilizado, tendo que ser excluído. Mais uma
vez é importante salientar que isso não afeta, de maneira alguma, o banco de dados original.
Por isso é importante que você faça um planejamento cuidadoso, de tal forma que tenha espaço suficiente
em disco, enquanto um ou mais snapshots estiverem em uso.
RECOMENDAÇÕES PARA A CRIAÇÃO DE UM SNAPSHOT

Antes de partirmos para a parte prática, apresentarei algumas recomendações contidas no Books online,
relacionadas com diversos aspectos sobre a criação de snapshot Databases, tais como: nomeação dos
snapshots e limitações para o número de snapshots a serem mantidos.
RECOMENDAÇÕES SOBRE A NOMEAÇÃO DOS SNAPSHOTS

Ao criar um snapshot de um banco de dados, você deverá atribuir um nome a ele. Neste tópico,
apresento algumas sugestões em relação à nomeação dos snapshots de um banco de dados.
Conforme já descrito anteriormente, é possível criar mais de um snapshot de um banco de dados.

Cada snapshot que for criado deverá ter um nome que seja único dentro da instância do SQL Server
onde o snapshot for criado (lembrando que os snapshots somente podem ser criados na mesma instância
do banco de dados original). O nome do snapshot deve incluir informações, tais como:
♦ O nome do banco de dados original.
♦ Um prefixo que identifique que é um snapshot, tal como snp ou sns.
♦ A data e hora da criação do snapshot ou um número seqüencial.
Vamos a um exemplo prático. Vamos considerar o banco de dados Northind. Para este banco de dados,
imagine que estamos criando três snapshots por dia, com um intervalo de seis horas de diferença,
dentro do período das 6 da manhã até as 6 da tarde (18 horas). Ou seja, são criados snapshots às 6 da
manhã, meio-dia (12 horas) e as 18 horas. Considere também que cada snapshot será mantido por 24
horas antes de ser excluído e substituído por um novo snapshot, com o mesmo nome. Para este exemplo,
podemos criar um esquema de nomeação como o indicado a seguir, onde em cada snapshot constam
o nome do banco de dados, a indicação de que é um snapshot e a hora em que foi criado. Como cada
snapshot é substituído por outro, de igual nome, 24 horas após ter sido criado, não é necessária a
inclusão da data de criação, no nome do snapshot:
♦ Northwind_snp_0600
Agora vamos modificar um pouco o nosso exemplo. Vamos supor que o horário de criação dos snap-
shots não seja tão bem definido. Seja apenas um de manhã, outro mais ou menos ao meio-dia e um à
tarde. Neste caso, poderíamos usar os seguintes nomes:
♦ Northwind_snp_manhã
♦ Northwind_snp_almoço
♦ Northwind_snp_tarde
LIMITAR O NÚMERO DE SNAPSHOTS A SEREM MANTIDOS

Conforme descrevi anteriormente, à medida que as páginas de dados são atualizadas no banco de
dados original, a versão antes da alteração é copiada para o snapshot, na operação conhecida como
“copy-on-write operation”. À medida que as páginas são copiadas, mais e mais espaço faz-se necessário
no disco. Além disso, um snapshot será mantido, até que ele seja excluído. Por isso, você deve definir
qual o número máximo de snapshots que serão mantidos, simultaneamente. Este número,
evidentemente, depende do tamanho do banco de dados e do espaço disponível para manter os snap-
shots. Mas é algo que tem que ser previsto e, cuidadosamente, planejado.
Muito bem, chega de teoria. A seguir você aprenderá a criar snapshots de um banco de dados. Um
detalhe interessante é que, para a criação de um snapshot, temos que utilizar comandos T-SQL. Não é
possível criar um snapshot, usando a interface gráfica do SQL Server Management Studio. Para a criação
de um snapshot, teremos que abrir uma janela de execução de comandos T-SQL, dentro do SQL Server
Management Studio.
CRIANDO SNAPSHOTS DE UM BANCO DE DADOS

Finalmente vamos à prática. Neste tópico mostrarei como criar um snapshot de um banco de dados.
Antes de criar um snapshot, você deve certificar-se de que dispõe de espaço suficiente em disco, para a
criação do snapshot. O espaço máximo que o snapshot irá precisar será o tamanho do banco de dados
original, quando da criação do snapshot. Já foi explicado anteriormente mas nunca é demais repetir.
Quando da criação do snapshot, as páginas de dados são mantidas no banco de dados fonte. Somente
quando uma página é alterada, pela primeira vez, é que ela é copiada para o snapshot e a página, com
as alterações, fica no banco de dados fonte. Com isso, à medida que mais páginas são alteradas, mais
páginas serão copiadas para o snapshot. As páginas do snapshot ficam em um arquivo conhecido
como sparse file, o qual tem a extensão .ss.
A criação de um snapshot é feita usando o comando CREATE DATABASE, em conjunto com a cláusula
AS SNAPSHOT OF. Ou seja, vamos criar um novo banco de dados, o qual será um snapshot de um
banco de dados já existente. Para criar um snapshot, você terá que especificar o nome lógico de todos
os arquivos do banco de dados fonte.
Exemplo prático: Criar um snapshot do banco de dados AdventureWorks. Vamos chamar o snapshot
de AdventureWorks_sns_Exem. O arquivo sparso (.ss) do snapshot será criado no seguinte caminho:
C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\AdventureWorks_sns_Exem.ss
NOTA
A extensão .ss é apenas uma sugestão, você pode escolher qualquer outra extensão.
Muito bem, para criar o snapshot proposto, siga os passos indicados a seguir:
1. Abra o SQL Server Management Studio e faça conexão com a instância onde está o banco de
dados AdventureWorks, para o qual você deseja criar um snapshot.
2. Navegue até o banco de dados AdventureWorks, clique com o botão direito do mouse neste
banco de dados e, no menu de opções que é exibido, clique em New Query, para abrir uma
janela de execução de comandos T-SQL.
CREATE DATABASE AdventureWorks_sns_Exem ON
( NAME = AdventureWorks_Data, FILENAME =
‘C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\AdventureWorks_sns_exem.ss’ )
AS SNAPSHOT OF AdventureWorks;
GO
O comando será executado e a seguinte mensagem será exibida:

Muito bem, isso indica que o snapshot foi criado. E agora, como podemos verificar se ele foi realmente
criado? Muito simples. Na instância onde o snapshot foi criado, a qual deve ser obrigatoriamente a
mesma instância do banco de dados original, acesse a opção Databases -> Databases snapshot. Será
exibida a lista de snapshots que foram criados, conforme exemplo da Figura 15.1, onde já aparece na
lista o snapshot AdventureWorks_sns_Exem, criado no nosso exemplo:
Figura 15.1 Lista de snapshots.
É fundamentel salienter que, uma vez criado, o snapshot é uma cópia fiel, somente leitura, do banco de dados original. Você poderá navegar
NOTA
pelas tabelas, views e demais elementos do snapshot. Apenas não poderá alterá-los ou não poderá alterar, inserir ou excluir dados das
tabelas do snapshot.
Outro detalhe de grande importância é o fato de que as alterações que são feitas no banco de dados
fonte não serão repassadas para o snapshot. O snapshot é uma cópia fiel do banco de dados, no
momento em que o snapshot é criado. Alterações, adições e exclusões feitas nos dados do banco de
dados fonte, após a criação do snapshot, não são replicadas para o snapshot.
Para excluir um snapshot é o mesmo procedimento para exclusão de um banco de dados qualquer.
Clique com o botão direito do mouse no snapshot e, no menu de opções que é exibido, clique em
Delete. Será aberta uma janela pedindo confirmação. Clique em OK e pronto, o snapshot foi excluído.
Sobre snapshot Databases era basicamente isso.
DESENVOLVIMENTO EM: CRIAÇÃO DE DIAGRAMAS DO BANCO DE DADOS

PRÉ-REQUISITOS
♦ Conhecimento básico do Modelo Relacional de Dados.
METODOLOGIA
♦ Exemplo prático de criação de um diagrama.
Os diagramas nos permitem ter uma visão geral da estrutura do banco de dados: tabelas, chaves
primárias, chaves estrangeiras e relacionamentos. É uma excelente ferramenta também para
documentação da estrutura do banco de dados. Os diagramas são mais conhecidos como
diagramas Entidade x Relacionamentos. Na Figura 15.2, temos um exemplo de um diagrama
Entidade x Relacionamentos:
Figura 15.2 Um exemplo de diagrama Entidades x Relacionamentos.
Neste tópico, mostrarei um exemplo prático de como criar um diagrama deste tipo, no SQL Server
2005. Este diagrama é bastante útil, pois nos dá uma visão geral da estrutura do banco de dados,
mostrando as tabelas existentes, os campos de cada tabela, um indicativo de quais campos são chave
primária e os relacionamentos entre as tabelas. Vamos ao exemplo prático.
Exemplo prático: Criar um diagrama para o banco de dados AdventureWorks. Para criar o diagrama
proposto, siga os passos indicados a seguir:
1. Abra o SQL Server Management Studio e acesse a instância onde está o banco de dados
AdventureWorks.
2. Navegue até a opção Databases e clique no sinal de +, ao lado da opção Databases, para exibir
os bancos de dados disponívies nesta instância.
3. Clique no sinal de + ao lado do banco de dados AdventureWorks, para exibir as opções
disponíveis. Observe que uma das opções é justamente Database Diagrams, conforme indicado
na Figura 15.3:
Figura 15.3 A opção Database Diagrams.
4. Para criar um novo diagrama, clique com o botão direito do mouse na opção Database Dia-
grams e, no menu de opções que é exibido, dê um clique em New Database Diagram.
5. Será aberta a janela Add Table, para que você adicione as tabelas que farão parte do diagrama.
Não é obrigatório que você adicione todas as tabelas. Outro detalhe importante é que você pode
criar vários diagramas, no mesmo banco de dados. Por exemplo, você pode criar um diagrama
onde sejam exibidas as tabelas relacionadas com clientes e pedidos e um outro diagrama onde
sejam exibidas as tabelas relacionadas com funcionários e fornecedores. No nosso exemplo, vamos
adicionar todas as tabelas cujo dono é o schema Person. Aqui cabe mais um comentário. No
Capítulo 6, quando tratei sobre segurança, salientei as novidades do SQL Server 2005 na área de
segurança. Uma delas era o fato de o dono dos objetos ser um schema e não mais um usuário ou
role. Um dos benefícios do uso de Schema é justamente facilitar a segmentação de um banco de
dados em áreas bem definidas, tais como Clientes, Pedidos, Funcionários, etc., onde as tabelas
relacionadas com cada área têm como dono o respectivo schema.
6. Para selecionar várias tabelas você usa a tecla Ctrl. Pressione e mantenha pressionada a tecla
Ctrl e vá clicando em todas as tabelas cujo dono seja o schema Person. Aparece (Person) após
o nome da tabela. Sua janela deve estar semelhante à indicada na Figura 15.4:
Figura 15.4 Selecionando as tabelas do schema Person.
7. Dê um clique no botão Add e depois um clique em Close.

8. As tabelas serão adicionadas ao diagrama com um layout um “pouco bagunçado”. Use o
mouse para arrastar e arranjar as tabelas de uma maneira mais “organizada”, conforme
sugestão da Figura 15.5.
Observe que são exibidos os relacionamentos existentes entre as tabelas, através de linhas que ligam as
tabelas relacionadas.
9. Quando o diagrama está sendo exibido, é habilitada uma barra de ferramentas com diversas
opções, relacionadas a edição e configuração do diagrama. Na Figura 15.6 é apresentada a barra
de ferramentas.
Figura 15.5 O diagrama recém-criado.
Figura 15.6 A barra de ferramentas Database Diagram.
A seguir descrevo a funcionalidade dos principais botões da barra de ferramentas Database Diagram.
♦ O segundo botão, da esquerda para a direita, é o botão Add table. Ao clicar neste botão será
aberta a janela Add Table, para que você possa adicionar outras tabelas ao diagrama.
♦ O terceiro botão, da esquerda para a direita é, sem dúvida, o mais interessante de todos. É o botão
Add Related Tables. Ao clicar neste botão, serão adicionadas ao diagrama, todas as tabelas que
possuem pelo menos um relacionamento com uma das tabelas já existentes no diagrama.
♦ O quarto botão, da esquerda para a direita, exclui do banco de dados a tabela selecionada no
diagrama. MUITA ATENÇÃO: Este botão irá excluir a tabela diretamente do banco de dados. Este
botão é equivalente a clicar com o botão direito do mouse na tabela e clicar na opção Delete.
♦ O quinto botão, da esquerda para a direita, é o Remove frome Diagram. Este botão apenas
retira a tabela do diagrama, sem excluí-la do banco de dados. Ao clicar neste botão, será excluída
a tabela que estiver selecionada no diagrama. A tabela selecionada é indicada pela sua linha de
título com o fundo azul e letras brancas. As tabelas não selecionadas no diagrama são exibidas
com a linha de título em cinza e cor de fonte preta. Você pode selecionar mais de uma tabela,
usando a tecla Ctrl e clicando nas tabelas a serem selecionadas. Você também pode remover
uma tabela do diagrama, selecionando a tabela e pressionando a tecla Delete. Não será emitida
uma mensagem para confirmação da exclusão da tabela do diagrama.
♦ A lista Table View permite que você exiba as tabelas do diagrama de diferentes maneiras.
Experimente as diferentes opções de visualização. Na Figura 15.7, temos a opção de visualização
Names Only. As configurações de exibição são individuais para cada tabela do diagrama. Você
pode selecionar uma tabela e usar a lista Table View para alterar somente a forma de exibição
da tabela selecionada. Em um mesmo diagrama, diferentes tabelas podem estar com diferentes
configurações de visualização.
Figura 15.7 A opção de visualização Name Only.
♦ Botão Show Relationship Labels. É o primeiro botão, à direita da lista Table View. Este botão
exibe informações adicionais sobre os relacionamentos presentes no diagrama. Pode ser utilizado
como uma forma de documentar os relacionamentos existentes no banco de dados.
Os demais botões desta barra de ferramentas são relacionados com configurações de layout do diagrama
e são auto-explicativos.
10. Pressione Ctrl + S para salvar o diagrama. Será exibida a janela Choose Name, para que você
informe um nome para o diagrama. Digita Tabelas – Person, conforme indicado na Figura 15.8:
Figura 15.8 Salvando o diagrama.
11. Clique em OK.

12. Selecione o comando File -> Close, para fechar o diagrama.
13. O diagrama Tabelas – Person já deve ser exibido na lista Database Diagramas, do banco de
dados AdventureWorks. Caso você precise editar o diagrama, basta dar um clique duplo nele,
para abri-lo no modo de edição.
DESENVOLVIMENTO EM: TRANSFERIR BANCOS DE

DADOS ENTRE INSTÂNCIAS
PRÉ-REQUISITOS
METODOLOGIA
♦ Exemplo prático de transferência de um banco de dados.
Em determinadas situações, pode ser necessário tirar um banco de dados de uma instância (chamamos
de Desatachar, Desanexar ou o termo em inglês ‘Detach’) e movê-lo para outra instância. Após desanexar
o banco de dados de uma isntância, podemos anexá-lo (o termo técnico é atachar, anexar ou em inglês
‘Attach’) em uma outra instância do mesmo servidor ou de outro servidor. São diversas as situações
práticas onde pode ser necessário mover um banco de dados de uma instância para outra. Por exemplo,
pode ser que você queira mover um banco de dados para um novo servidor, o qual será dedicado ao
banco de dados, para obter um melhor desempenho.
O processso de desanexar um banco de dados de uma instância e anexá-lo em outra instância é bastante
simples. Vamos aprender a executar esta operação através de um exemplo prático. O processo é
constituído de três etapas:
1. Desanexar o banco de dados da instância onde ele está.

2. Copiar todos os arquivos do banco de dados para a pasta onde eles serão utilizados. Devem ser
copiados o arquivo primário (.mdf), todos os arquivos secundários (.ndf) e todos os arquivos
de log (.ldf).
3. Anexar o banco de dados na instância de destino.
Muito bem, vamos a um exemplo prático.
Etapa 1: Desanexar o banco de dados da instância de origem. Para desanexar um banco de dados, siga
os passos indicados a seguir:
1. Abra o SQL Server Management Studio, faça a conexão com a instância onde está o banco de
dados a ser desanexado.
2. Navegue até o banco de dados a ser desanexado, clique com o botão direito do mouse no
banco de dados e, no menu de opções que é exibido, clique em Tasks -> Detach.
3. Será aberta a janela Detach Database, na qual você pode marcar diversas opções, tais como
Drop Connections (para cancelar as conexões que estejam abertas com o banco de dados),
Keep Full Text Catalogs, para manter os catálogos para pesquisa de Full Text e assim por diante.
Esta tela está indicada na Figura 15.9.
4. Marque as opções desejadas e dê um clique em OK.
Pronto, o banco de dados foi desanexado e não será mais exibido na lista Databases, da instância.
Etapa 2: Copiar todos os arquivos do banco de dados para a pasta onde eles serão utilizados. Devem ser
copiados o arquivo primário (.mdf), todos os arquivos secundários (.ndf) e todos os arquivos de log (.ldf):
1. Copie todos os arquivos que compõem o banco de dados (arquivo .mdf, arquivos .ndf e arquivos
.log) para a pasta de destino. Por exemplo, se você vai anexar o banco de dados em uma
instância de um outro servidor, deve criar uma pasta no servidor de destino e copiar os arquivos
para dentro desta pasta.
Figura 15.9 Desanexando um banco de dados.
Etapa 3: Anexar o banco de dados da instância de destino. Para anexar um banco de dados, siga os
1. Abra o SQL Server Management Studio, faça a conexão com a instância onde será anexado o
banco de dados.
2. Navegue até a opção Databases, clique com o botão direito do mouse na opção Databases e, no
menu de opções que é exibido, clique em Attach.
3. Será exibida a janela Attach Databases. Você pode usar esta janela para anexar mais de um
banco de dados, ao mesmo tempo. Para anexar o banco de dados você deve informar onde está
gravado o arquivo primário (.mdf) do banco de dados. Clique no botão Add.
4. Será aberta a janela Locate Database Files. Navegue até a pasta onde está o arquivo primário
(.mdf) do banco de dados a ser anexado. Marque o arquivo primário, conforme exemplo da
Figura 15.10 e clique em OK.
5. Você estará de volta à janela Attach Databases. As informações sobre o banco de dados terão
sido carregadas a partir do arquivo .mdf, conforme indicado na Figura 15.11.
6. Clique em OK e pronto, o banco de dados terá sido anexado e estar disponível para ser utilizado.
A seguir apresento algumas situações que impedem que seja possível desanexar um banco de dados de
uma instância do SQL Server 2005:
♦ Se o banco de dados estiver sendo replicado ou contiver publicações.
Figura 15.10 Selecionando o arquivo primário do banco de dados.
Figura 15.11 A janela Attach Databases.
♦ Se existirem um ou mais snapshots do banco de dados. Antes de poder desanexar o banco de

dados, você terá que excluir todos os snapshots que tenham sido criados.
♦ Um snapshot não pode ser anexado ou desanexado.
♦ Se houver uma seção de espelhamento do banco de dados – database mirroring – em andamento,

não será possível desanexar o banco de dados. O banco somente poderá ser desanexado, depois
que a sessão de espelhamento for encerrada.
O COMANDO SP_DETACH_DB
Você também pode usar o comando sp_detach_db, para desanexar um banco de dados de uma
instância do SQL Server 2005. Este comando desanexa o banco de dados e pode, opcionalmente,
rodar o comando UPDATE STATISTICS em todas as tabelas do banco de dados, antes de fazer a
desanexação do banco de dados.
Syntax – conforme Books online:

sp_detach_db [ @dbname= ] ‘dbname’
[ , [ @skipchecks= ] ‘skipchecks’ ]
[ , [ @KeepFulltextIndexFile= ] ‘KeepFulltextIndexFile’ ]
Este comando tem os seguintes argumentos:
♦ [ @dbname = ] ‘dbname’: É o nome do banco de dados a ser desanexado.
♦ [ @skipchecks = ] ‘skipchecks’: Esta opção define se o comando UPDATE STATISTICS deve ou

não ser executado ou não em todas as tabelas do banco de dados, antes de fazer a desanexação
do banco de dados. Se esta opção for definida com o valor True, a atualização das estatísticas
não será efetuada. Para fazer com que o comando UPDATE STATISTIS seja executado, esta
opção deve ser definida com o valor False. É recomendado que as atualizações sejam executadas,
principalmente quando o banco de dados for movido para uma mídia do tipo somente leitura,
como por exemplo um CD-ROM ou DVD-ROM.
♦ [ @KeepFulltextIndexFile = ] ‘KeepFulltextIndexFile’: Esta opção é utilizada para definir se

os índices para pesquisas do tipo full-text serão ou não excluídos, durante a desanexação do
banco de dados. Se o valor for NULL ou false, todos os índices serão excluídos; se o valor for
True, os índices serão mantidos.
NOTA
Para executar o comando sp_detach_db, o usuário deve ser membro da seguinte role de servidor: db_owner
Exemplo: O comando a seguir faz a desanexação do banco de dados AdventureWorks e define o valor
do parâmetro skipchecks como True, ou seja, não será executado o comando UPDATE STATISTICS, nas
tabelas do banco de dados, para atualização das estatísticas, antes da desanexação do banco de dados.
EXEC sp_detach_db ‘AdventureWorks’, ‘true’
Também é possível anexar um banco de dados, usando comandos T-SQL. Para isso, usamos o comando
CREATE DATABASE, com a seguinte sintaxe:
CREATE DATABASE database_name
ON <filespec> [ ,...n ]
FOR { ATTACH [ WITH <service_broker_option> ]
| ATTACH_REBUILD_LOG }
Considere o exemplo a seguir. Este exemplo faz a anexação de um banco de dados chamado Northwind,
usando a cláusula FOR ATTACH. Observe que é informado o caminho para o arquivo primário do
banco de dados (arquivo .mdf):
CREATE DATABASE Archive
ON (FILENAME = ‘c:\program files\microsoft sql server\mssql.1\mssql\data\archdat1.mdf’)
FOR ATTACH;
GO
Muito bem, sobre anexação e desanexação de arquivos era basicamente isso. No próximo tópico
mostrarei como acessar, alterar, excluir e inserir dados nas tabelas de um banco de dados, diretamente
através da interface do SQL Server Management Studio.
DESENVOLVIMENTO EM: ACESSANDO DADOS DAS

TABELAS DO BANCO DE DADOS
PRÉ-REQUISITOS
♦ Conhecimento básico da interface do SQL Server Management Studio.
METODOLOGIA
♦ Exemplo prático de acesso e alteração dos dados das tabelas.
Embora não seja muito usual, você pode acessar, alterar, incluir e excluir registros das tabelas de um
banco de dados do SQL Server 2005, usando o SQL Server Management Studio. Eu afirmo que não é
muito usual porque normalmente os dados são acessados por aplicações clientes, desenvolvidas em
VB.NET, C#, Delphi ou através de aplicações Web, desenvolvidas em ASP, ASP.NET, PHP ou Java. Mas
pode haver situações, onde você precise acessar os dados de uma ou mais tabelas de um banco de
dados, usando o SQL Server Management Studio. Neste tópico, mostrarei, através de um exemplo
prático, como ter acesso aos dados, como alterá-los, como adicionar e excluir registros.
Exemplo prático: Para acessar registros das tabelas de um banco de dados, incluir novos registros,
alterar os registros já existentes e excluir registros, usando o SQL Server Management Studio, siga os
1. Abra o SQL Server Management Studio e navegue até o banco de dados onde estão as tabelas a
serem acessadas.
2. Clique no sinal de + ao lado do nome do banco de dados, para exibir as opções disponívies.
3. Clique no sinal de + ao lado da opção Tables, para exibir a lista de tabelas do banco de dados.
4. Clique com o botão direito do mouse na tabela a ser acessada e, no menu de opções que é
exibido, clique em Open Table. A tabela será aberta em modo de edição, semelhante ao modo
Folha de dados das tabelas do Access, conforme indicado na Figura 15.12.
5. Esta é uma grade normal de edição, como se fosse o modo folha de dados de uma tabela do Access
ou, até mais simples, uma planilha do Excel. Na parte de baixo da tela, você também tem os botões
de navegação, para ir para o Próximo registro, Registro anterior, Primeiro registro e Último registro.
Na parte de baixo tem também um campo com o número do registro atual. Você pode digitar o
número de um registro e pressionar Enter, para se deslocar para o respectivo registro. Ou seja, tudo
exatamente igual ao modo folha de dados de uma tabela do Microsoft Access.
Figura 15.12 Tabela no modo de edição.
6. Para excluir um registro basta clicar na linha do registro, para selecioná-lo e depois pressionar
Delete. Será exibida uma mensagem solicitando a confirmação da exclusão do registro, conforme
indicado na Figura 15.13. Clique em Sim e pronto, o registro foi excluído. Você pode também
excluir vários registros de uma só vez. Para isso basta selecionar com o mouse os registros a
serem excluídos e pressionar a tecla Delete. Será exibida uma mensagem para que você confirme
a exclusão dos registros. Clique em Sim e pronto, os registros selecionados serão excluídos.
Figura 15.13 Confirmando a exclusão de um registro.
7. Na parte de baixo, ao lado do botão Último registro, está disponível o botão Novo registro,
indicado na Figura 15.14. Ao clicar neste botão, será aberta uma nova linha, em branco, para
que você insira um novo registro na tabela.
Figura 15.14 Botão para adicionar um novo registro.
Em resumo, para editar registros, usando o SQL Server Management Studio, basta clicar com o botão direito
do mouse na tabela a ser editada e, no menu de opções que é exibido, clicar em Open Table. Feito isso, será
carregada uma interface praticamente idêntica ao modo folha de dados do Microsoft Access.
DESENVOLVIMENTO EM: USAR A OPÇÃO DE GERAÇÃO

DE SCRIPTS DO SQL SERVER MANAGEMENT STUDIO
PRÉ-REQUISITOS
♦ Conhecimento básico da interface do SQL Server Management Studio.
METODOLOGIA
♦ Exemplo prático de geração de scripts, usando o SQL Server Management Studio.
Que podemos fazer “literalmente qualquer ação do SQL Server 2005” usando comandos T-SQL nós já
sabemos. Que a linguagem T-SQL, embora simples, pode tornar-se difícil devido à infinidade de
comandos e opções disponíveis, nós também já sabemos. Que a interface gráfica facilita, muito, o
trabalho com o SQL Server 2005, sabemos também.
Muito bem, então para que serve este tópico, se já sabemos todos estes detalhes sobre o T-SQL? Tópico
novo é para aprender coisas novas. E o objetivo deste tópico é mostrar uma funcionalidade bem
interessante do SQL Server Management Studio: A geração de scripts. O SQL Server Management Stu-
dio vem com uma série de opções, que permite a geração automática de scripts. Um script nada mais é
do que uma seqüência de comandos T-SQL, necessários para realizar uma determinada tarefa, tal como
criar um banco de dados ou as tabelas de um banco de dados. O SQL Server Management Studio
permite que façamos o caminho inverso, ou seja, a partir dos objetos já existentes, gerar o script que
seria necessário para recriar o referido objeto. Estes scripts podem ser úteis, especialmente em situações
de emergência, onde precisamos recriar, rapidamente, um ou mais objetos. Vamos a um exemplo
prático.
Exemplo prático: Para gerar scripts, usando o SQL Server Management Studio, siga os passos indicados
a seguir:
2. Navegue até a opção Databases e clique no sinal de + ao lado desta opção, para exibir a lista de
bancos de dados disponíveis.
3. Vamos inicialmente mostrar como gerar um script, o qual contém todos os comandos necessários
para a criação do banco de dados. Por exemplo, clique com o botão direito do mouse no banco
de dados AdventureWorks e, no menu de opções que é exibido, clique em Script Database as –
> CREATE To -> New Query Editor Window. Será aberta uma janela de execução de comandos
T-SQL, com todos os comandos necessários para criar o banco de dados, exatamente com as
opções atualmente definidas para o banco. A seguir coloco uma cópia do script gerado pelo
SQL Server Management Studio:
********************************************************************************
USE [master]
GO
/****** Object: Database [AdventureWorks] Script Date: 07/12/2005 12:30:14 ******/
CREATE DATABASE [AdventureWorks] ON PRIMARY
( NAME = N’AdventureWorks_Data’, FILENAME = N’C:\Arquivos de programas\Microsoft SQL
Server\MSSQL.1\MSSQL\Data\AdventureWorks_Data.mdf’ , SIZE = 184448KB , MAXSIZE =
UNLIMITED, FILEGROWTH = 16384KB )
LOG ON
( NAME = N’AdventureWorks_Log’, FILENAME = N’C:\Arquivos de programas\Microsoft SQL
Server\MSSQL.1\MSSQL\Data\AdventureWorks_Log.ldf’ , SIZE = 2048KB , MAXSIZE = 2048GB ,
FILEGROWTH = 16384KB )
COLLATE SQL_Latin1_General_CP1_CI_AS
GO
EXEC dbo.sp_dbcmptlevel @dbname=N’AdventureWorks’, @new_cmptlevel=90
GO
EXEC [AdventureWorks].[dbo].[sp_fulltext_database] @action = ‘enable’
GO
ALTER DATABASE [AdventureWorks] SET ANSI_NULL_DEFAULT OFF
GO
ALTER DATABASE [AdventureWorks] SET ANSI_NULLS ON
GO
ALTER DATABASE [AdventureWorks] SET ANSI_PADDING ON
GO
ALTER DATABASE [AdventureWorks] SET ANSI_WARNINGS ON
GO
ALTER DATABASE [AdventureWorks] SET ARITHABORT ON
GO
ALTER DATABASE [AdventureWorks] SET AUTO_CLOSE OFF
GO
ALTER DATABASE [AdventureWorks] SET AUTO_CREATE_STATISTICS ON
GO
ALTER DATABASE [AdventureWorks] SET AUTO_SHRINK OFF
GO
ALTER DATABASE [AdventureWorks] SET AUTO_UPDATE_STATISTICS ON
GO
ALTER DATABASE [AdventureWorks] SET CURSOR_CLOSE_ON_COMMIT OFF
GO
ALTER DATABASE [AdventureWorks] SET CURSOR_DEFAULT GLOBAL
GO
ALTER DATABASE [AdventureWorks] SET CONCAT_NULL_YIELDS_NULL ON
GO
ALTER DATABASE [AdventureWorks] SET NUMERIC_ROUNDABORT OFF
GO
ALTER DATABASE [AdventureWorks] SET QUOTED_IDENTIFIER ON
GO
ALTER DATABASE [AdventureWorks] SET RECURSIVE_TRIGGERS OFF
GO
ALTER DATABASE [AdventureWorks] SET ENABLE_BROKER
GO
ALTER DATABASE [AdventureWorks] SET AUTO_UPDATE_STATISTICS_ASYNC OFF
GO
ALTER DATABASE [AdventureWorks] SET DATE_CORRELATION_OPTIMIZATION OFF
GO
ALTER DATABASE [AdventureWorks] SET ALLOW_SNAPSHOT_ISOLATION OFF
GO
ALTER DATABASE [AdventureWorks] SET READ_WRITE
GO
ALTER DATABASE [AdventureWorks] SET RECOVERY SIMPLE
GO
ALTER DATABASE [AdventureWorks] SET MULTI_USER
GO
ALTER DATABASE [AdventureWorks] SET PAGE_VERIFY CHECKSUM
GO
ALTER DATABASE [AdventureWorks] SET DB_CHAINING OFF
GO
EXEC [AdventureWorks].sys.sp_addextendedproperty @name=N’MS_Description’,
@value=N’AdventureWorks Sample OLTP Database’
********************************************************************************
É importante salientar que estes comandos são os comandos para recriar o banco de dados tão-somente. Os
objetos do banco de dados, tais como tabelas, views, stored procedures e as configurações de segurança, de
replicação, diagramas, etc. teriam que ser recriadas. Claro que podemos criar scripts para cada um destes
objetos, conforme mostrarei nos próximos passos, para os objetos dos tipos Tabela e View.
4. Clique no sinal de + ao lado da opção Tables, para exibir as tabelas do banco de dados
AdventureWorks.
5. Clique com o botão direito do mouse na tabela HumanResources.Employee. No menu de opções
que é exibido, selecione o comando: Script Table as -> CREATE To -> New Query Editor Window.
6. Será aberta a janela de execução de comandos T-SQL, com a lista de comandos necessários para
recriar a tabela HumanResources.Employee, caso necessário. A seguir apresento a seqüência de
comandos que foi gerada:
*****************************************************************************
USE [AdventureWorks]
GO
/****** Object: Table [HumanResources].[Employee] Script Date: 07/12/2005 13:55:42
******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TABLE [HumanResources].[Employee](
[EmployeeID] [int] IDENTITY(1,1) NOT NULL,
[NationalIDNumber] [nvarchar](15) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL,
[ContactID] [int] NOT NULL,
[LoginID] [nvarchar](256) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL,
[ManagerID] [int] NULL,
[Title] [nvarchar](50) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL,
[BirthDate] [datetime] NOT NULL,
[MaritalStatus] [nchar](1) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL,
[Gender] [nchar](1) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL,
[HireDate] [datetime] NOT NULL,
[SalariedFlag] [dbo].[Flag] NOT NULL CONSTRAINT [DF_Employee_SalariedFlag]
DEFAULT ((1)),
[VacationHours] [smallint] NOT NULL CONSTRAINT [DF_Employee_VacationHours]
DEFAULT ((0)),
[SickLeaveHours] [smallint] NOT NULL CONSTRAINT [DF_Employee_SickLeaveHours]
DEFAULT ((0)),
[CurrentFlag] [dbo].[Flag] NOT NULL CONSTRAINT [DF_Employee_CurrentFlag] DEFAULT
((1)),
[rowguid] [uniqueidentifier] ROWGUIDCOL NOT NULL CONSTRAINT [DF_Employee_rowguid]
DEFAULT (newid()),
[ModifiedDate] [datetime] NOT NULL CONSTRAINT [DF_Employee_ModifiedDate] DEFAULT
(getdate()),
CONSTRAINT [PK_Employee_EmployeeID] PRIMARY KEY CLUSTERED
(
[EmployeeID] ASC
) ON [PRIMARY]
) ON [PRIMARY]
GO
SET ANSI_NULLS OFF
GO
SET QUOTED_IDENTIFIER OFF
GO
EXEC sys.sp_addextendedproperty @name=N’MS_Description’, @value=N’Primary key for
Employee records.’ ,@level0type=N’SCHEMA’, @level0name=N’HumanResources’,
@level1type=N’TABLE’, @level1name=N’Employee’, @level2type=N’COLUMN’,
@level2name=N’EmployeeID’
GO
EXEC sys.sp_addextendedproperty @name=N’MS_Description’, @value=N’Unique national
identification number such as a social security number.’ ,@level0type=N’SCHEMA’,
@level0name=N’HumanResources’, @level1type=N’TABLE’, @level1name=N’Employee’,
@level2type=N’COLUMN’, @level2name=N’NationalIDNumber’
GO
EXEC sys.sp_addextendedproperty @name=N’MS_Description’, @value=N’Identifies the employee
in the Contact table. Foreign key to Contact.ContactID.’ ,@level0type=N’SCHEMA’,
@level2type=N’COLUMN’, @level2name=N’ContactID’
GO
EXEC sys.sp_addextendedproperty @name=N’MS_Description’, @value=N’Network login.’
,@level0type=N’SCHEMA’, @level0name=N’HumanResources’, @level1type=N’TABLE’,
@level1name=N’Employee’, @level2type=N’COLUMN’, @level2name=N’LoginID’
GO
<lc>EXEC sys.sp_addextendedproperty @name=N’MS_Description’, @value=N’Manager to whom the
employee is assigned. Foreign Key to Employee.M’ ,@level0type=N’SCHEMA’,
@level2type=N’COLUMN’, @level2name=N’ManagerID’
GO
EXEC sys.sp_addextendedproperty @name=N’MS_Description’, @value=N’Work title such as
Buyer or Sales Representative.’ ,@level0type=N’SCHEMA’, @level0name=N’HumanResources’,
@level2name=N’Title’
GO
EXEC sys.sp_addextendedproperty @name=N’MS_Description’, @value=N’Date of birth.’
@level1name=N’Employee’, @level2type=N’COLUMN’, @level2name=N’BirthDate’
GO
EXEC sys.sp_addextendedproperty @name=N’MS_Description’, @value=N’M = Married, S =
Single’ ,@level0type=N’SCHEMA’, @level0name=N’HumanResources’, @level1type=N’TABLE’,
@level1name=N’Employee’, @level2type=N’COLUMN’, @level2name=N’MaritalStatus’
GO
EXEC sys.sp_addextendedproperty @name=N’MS_Description’, @value=N’M = Male, F = Female’
@level1name=N’Employee’, @level2type=N’COLUMN’, @level2name=N’Gender’
GO
EXEC sys.sp_addextendedproperty @name=N’MS_Description’, @value=N’Employee hired on this
date.’ ,@level0type=N’SCHEMA’, @level0name=N’HumanResources’, @level1type=N’TABLE’,
@level1name=N’Employee’, @level2type=N’COLUMN’, @level2name=N’HireDate’
GO
EXEC sys.sp_addextendedproperty @name=N’MS_Description’, @value=N’Job classification. 0 =
Hourly, not exempt from collective bargaining. 1 = Salaried, exempt from collective
bargaining.’ ,@level0type=N’SCHEMA’, @level0name=N’HumanResources’, @level1type=N’TABLE’,
@level1name=N’Employee’, @level2type=N’COLUMN’, @level2name=N’SalariedFlag’
GO
EXEC sys.sp_addextendedproperty @name=N’MS_Description’, @value=N’Number of available
vacation hours.’ ,@level0type=N’SCHEMA’, @level0name=N’HumanResources’,
@level2name=N’VacationHours’
GO
EXEC sys.sp_addextendedproperty @name=N’MS_Description’, @value=N’Number of available
sick leave hours.’ ,@level0type=N’SCHEMA’, @level0name=N’HumanResources’,
@level2name=N’SickLeaveHours’
GO
EXEC sys.sp_addextendedproperty @name=N’MS_Description’, @value=N’0 = Inactive, 1 =
Active’ ,@level0type=N’SCHEMA’, @level0name=N’HumanResources’, @level1type=N’TABLE’,
@level1name=N’Employee’, @level2type=N’COLUMN’, @level2name=N’CurrentFlag’
GO
EXEC sys.sp_addextendedproperty @name=N’MS_Description’, @value=N’ROWGUIDCOL number
uniquely identifying the record. Used to support a merge replication sample.’
@level1name=N’Employee’, @level2type=N’COLUMN’, @level2name=N’rowguid’
GO
EXEC sys.sp_addextendedproperty @name=N’MS_Description’, @value=N’Date and time the
record was last updated.’ ,@level0type=N’SCHEMA’, @level0name=N’HumanResources’,
@level2name=N’ModifiedDate’
GO
EXEC sys.sp_addextendedproperty @name=N’MS_Description’, @value=N’Employee information
such as salary, department, and title.’ ,@level0type=N’SCHEMA’,
@level0name=N’HumanResources’, @level1type=N’TABLE’, @level1name=N’Employee’
GO
EXEC sys.sp_addextendedproperty @name=N’MS_Description’, @value=N’Unique nonclustered
index.’ ,@level0type=N’SCHEMA’, @level0name=N’HumanResources’, @level1type=N’TABLE’,
@level1name=N’Employee’, @level2type=N’INDEX’, @level2name=N’AK_Employee_LoginID’
GO
index.’ ,@level0type=N’SCHEMA’, @level0name=N’HumanResources’, @level1type=N’TABLE’,
@level1name=N’Employee’, @level2type=N’INDEX’,
@level2name=N’AK_Employee_NationalIDNumber’
GO
index.Used to support replication samples.’ ,@level0type=N’SCHEMA’,
@level2type=N’INDEX’, @level2name=N’AK_Employee_rowguid’
GO
EXEC sys.sp_addextendedproperty @name=N’MS_Description’, @value=N’Nonclustered index.’
@level1name=N’Employee’, @level2type=N’INDEX’, @level2name=N’IX_Employee_ManagerID’
GO
EXEC sys.sp_addextendedproperty @name=N’MS_Description’, @value=N’Primary key (clustered)
constraint’ ,@level0type=N’SCHEMA’, @level0name=N’HumanResources’, @level1type=N’TABLE’,
@level1name=N’Employee’, @level2type=N’CONSTRAINT’, @level2name=N’PK_Employee_EmployeeID’
GO
EXEC sys.sp_addextendedproperty @name=N’MS_Description’, @value=N’INSTEAD OF DELETE
trigger which keeps Employees from being deleted.’ ,@level0type=N’SCHEMA’,
@level2type=N’TRIGGER’, @level2name=N’dEmployee’
GO
EXEC sys.sp_addextendedproperty @name=N’MS_Description’, @value=N’AFTER UPDATE trigger
setting the ModifiedDate column in the Employee table to the current date.’
@level1name=N’Employee’, @level2type=N’TRIGGER’, @level2name=N’uEmployee’
GO
USE [AdventureWorks]
GO
ALTER TABLE [HumanResources].[Employee] WITH CHECK ADD CONSTRAINT
[FK_Employee_Contact_ContactID] FOREIGN KEY( [ContactID])
REFERENCES [Person].[Contact] ( [ContactID])
GO
EXEC sys.sp_addextendedproperty @name=N’MS_Description’, @value=N’Foreign key constraint
referencing Contact.ContactID.’ ,@level0type=N’SCHEMA’, @level0name=N’HumanResources’,
@level1type=N’TABLE’, @level1name=N’Employee’, @level2type=N’CONSTRAINT’,
@level2name=N’FK_Employee_Contact_ContactID’
GO
[FK_Employee_Employee_ManagerID] FOREIGN KEY( [ManagerID])
REFERENCES [HumanResources].[Employee] ( [EmployeeID])
GO
EXEC sys.sp_addextendedproperty @name=N’MS_Description’, @value=N’Foreign key constraint
referencing Employee.ManagerID.’ ,@level0type=N’SCHEMA’, @level0name=N’HumanResources’,
@level2name=N’FK_Employee_Employee_ManagerID’
GO
[CK_Employee_BirthDate] CHECK (([BirthDate]>=’1930-01-01' AND
[BirthDate]<=dateadd(year,(-18),getdate())))
GO
EXEC sys.sp_addextendedproperty @name=N’MS_Description’, @value=N’Check constraint
[BirthDate]>=’’1930-01-01'’ AND [BirthDate]<=dateadd(year,(-18),GETDATE())’
@level1name=N’Employee’, @level2type=N’CONSTRAINT’,
<lc>@level2name=N’CK_Employee_BirthDate’
GO
ALTER TABLE [HumanResources].[Employee] WITH CHECK ADD CONSTRAINT [CK_Employee_Gender]
CHECK ((upper([Gender])=’F’ OR upper([Gender])=’M’))
GO
[Gender]=’’f’’ OR [Gender]=’’m’’ OR [Gender]=’’F’’ OR [Gender]=’’M’’’
@level1name=N’Employee’, @level2type=N’CONSTRAINT’, @level2name=N’CK_Employee_Gender’
GO
[CK_Employee_HireDate] CHECK (([HireDate]>=’1996-07-01' AND
[HireDate]<=dateadd(day,(1),getdate())))
GO
[HireDate]>=’’1996-07-01'’ AND [HireDate]<=dateadd(day,(1),GETDATE())’
@level1name=N’Employee’, @level2type=N’CONSTRAINT’, @level2name=N’CK_Employee_HireDate’
GO
[CK_Employee_MaritalStatus] CHECK ((upper([MaritalStatus])=’S’ OR
upper([MaritalStatus])=’M’))
GO
[MaritalStatus]=’’s’’ OR [MaritalStatus]=’’m’’ OR [MaritalStatus]=’’S’’ OR
[MaritalStatus]=’’M’’’ ,@level0type=N’SCHEMA’, @level0name=N’HumanResources’,
@level2name=N’CK_Employee_MaritalStatus’
GO
[CK_Employee_SickLeaveHours] CHECK (([SickLeaveHours]>=(0) AND [SickLeaveHours]<=(120)))
GO
[SickLeaveHours]>=(0) AND [SickLeaveHours]<=(120)’ ,@level0type=N’SCHEMA’,
@level2type=N’CONSTRAINT’, @level2name=N’CK_Employee_SickLeaveHours’
GO
[CK_Employee_VacationHours] CHECK (([VacationHours]>=(-40) AND [VacationHours]<=(240)))
GO
[VacationHours]>=(-40) AND [VacationHours]<=(240)’ ,@level0type=N’SCHEMA’,
@level2type=N’CONSTRAINT’, @level2name=N’CK_Employee_VacationHours’
*****************************************************************************
Claro que esta é uma tabela bem complexa, onde foi definida uma série de propriedades e opções. A
seguir um exemplo de script bem mais simples, gerado a partir da opção CREATE TO, para a tabela
Clientes, do banco de dados Northwind:
*****************************************************************************
USE [NortwindReport]
GO
/****** Object: Table [dbo].[Clientes] Script Date: 07/12/2005 13:59:36 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TABLE [dbo].[Clientes](
[CódigoDoCliente] [nvarchar](5) COLLATE Latin1_General_CI_AS NOT NULL,
[NomeDaEmpresa] [nvarchar](40) COLLATE Latin1_General_CI_AS NOT NULL,
[NomeDoContato] [nvarchar](30) COLLATE Latin1_General_CI_AS NULL,
[CargoDoContato] [nvarchar](30) COLLATE Latin1_General_CI_AS NULL,
[Endereço] [nvarchar](60) COLLATE Latin1_General_CI_AS NULL,
[Cidade] [nvarchar](15) COLLATE Latin1_General_CI_AS NULL,
[Região] [nvarchar](15) COLLATE Latin1_General_CI_AS NULL,
[CEP] [nvarchar](10) COLLATE Latin1_General_CI_AS NULL,
[País] [nvarchar](15) COLLATE Latin1_General_CI_AS NULL,
[Telefone] [nvarchar](24) COLLATE Latin1_General_CI_AS NULL,
[Fax] [nvarchar](24) COLLATE Latin1_General_CI_AS NULL,
CONSTRAINT [PK_Clientes] PRIMARY KEY CLUSTERED
(
[CódigoDoCliente] ASC
) ON [PRIMARY]
) ON [PRIMARY]
GO
SET ANSI_NULLS OFF
GO
SET QUOTED_IDENTIFIER OFF
*****************************************************************************
O recurso de geração de scripts é um recurso bastante útil, que o administrador deve conhecer.
DESENVOLVIMENTO EM: EDIÇÕES DO SQL SERVER 2005

PRÉ-REQUISITOS
METODOLOGIA
♦ Descrição e comparação entre as Edições do SQL Server 2005.
INTRODUÇÃO
O SQL Server 2005, a exemplo do que ocorria com as versões anteriores do SQL Server, é fornecido em
diferentes edições. Desde edições bastante limitadas, tais como o SQL Server 2005 Express Edition até
edições “peso-pasado”, tais como o SQL Server 2005 Enterprise Edition.
Existem diferenças de funcionalidades e de limites, em termos de desempenho e uso de recursos de

hardware, entre as diferentes edições. Neste tópico apresentarei estas diferenças, para que você possa
decidir qual à edição do SQL Server 2005 é a mais adequada, para uso na sua empresa.
Neste tópico, o qual encerra o capítulo e o livro, farei uma breve descrição de cada uma das edições,
bem como um estudo comparativo entre as edições.
SQL SERVER 2005 ENTERPRISE EDITION (32-BITS E 64-BITS)

Esta, sem dúvida, é a edição “peso-pesado”, ou seja, a mais completa, a que tem mais funcionalidades.
Esta, provavelmente, é a edição a ser usada para aplicações de grande porte, com um grande número de
usuários e em ambientes de elevada segurança. O SQL Server 2005 Enterprise Edition é recomendado
para uso em aplicações de grande porte, onde temos um grande número de usuários conectados, fazendo
alterações, adições ou exclusões de registro. O típico ambiente chamado de OLTP – Online Transaction
Processing. Um exemplo típico deste tipo de aplicação é um sistema de reserva de passagens de uma
companhia aérea, o qual é utilizado por milhares de atendentes, simultaneamente. O Enterprise Edition
também é recomendado para o uso em soluções que envolvem análises e consultas complexas, devido à
necessidade de elevado volume de processamento e cálculos, neste tipo de aplicação. Esta edição suporta
recursos importantes para garantir a disponibilidade do banco de dados, tais como os recursos de “failover
clustering” e “database mirroring”. Esta edição esta disponível em versões de 32 e de 64 bits.
SQL SERVER 2005 STANDARD EDITION (32-BITS E 64-BITS)

Esta é uma versão mais “light”, em relação à Enterprise Edition e é a edição indicada para pequenas e
médias empresas. Por exemplo, se você tem um banco de dados para cadastro de clientes e acompanhamento
de pedidos, banco de dados este que será utilizado por 100 usuários da sua empresa, certamente o SQL
Server 2005 Standard Edition, dará conta deste trabalho, com folga. Ele também inclui funcionalidades
necessárias para a implementação de e-comerce, data warehousing e para ambientes OLTP com um número
pequeno ou médio de usuários. Esta edição está disponível em versões de 32 e de 64 bits.
SQL SERVER 2005 WORKGROUP EDITION (SOMENTE EM 32 BITS)

Esta é uma edição ainda mais light, em comparação com o SQL Server 2005 Enterprise Edition e o SQL
Server 2005 Standard Edition. Ele é indicado para aplicações típicas de gerenciamento de dados, para
pequenas organizações, com um número limitado de usuários. Ela também é indicada para aplicações
de uma intranet interna da empresa, como suporte ao banco de dados de um servidor Web, para uso
departamental ou para uso por filiais da empresa, com um número reduzido de usuários. Esta edição
inclui as funcionalidades principais do SQL Server 2005 e pode, quando necessário, sofrer um upgrade
para as edições Standard Edition ou Enterprise Edition. Está disponível somente na versão em 32 bits.
SQL SERVER 2005 DEVELOPER EDITION (32-BITS E 64-BITS)

Esta é uma edição para testes ou para ser utilizada em um ambiente de desenvolvimeno. Ela apresenta
todas as funcionalidades do SQL Server 2005 Enterprise Edition, porém não pode ser colocada em um
ambiente de produção. A licença de uso desta edição é para teste e desenvolvimento de aplicações.
Uma vez criado o banco de dados e demais objetos, eles devem ser movidos para uma instância do
SQL Server 2005 Enterprise, Workgroup Edition ou Standard Edition, para serem colocados em produção.
Se necessário, o SQL Server 2005 Developer Edition pode sofrer um upgrade para o SQL Server 2005
Enterprise Edition, sem problemas. Está disponível em versões de 32 bits e 64 bits.
SQL SERVER 2005 EXPRESS EDITION (DISPONÍVEL SOMENTE EM 32-BITS)

Esta edição é gratuita e pode ser baixada diretamente do site da Microsoft, no seguinte endereço:
http://www.microsoft.com/sql/2005/productinfo/ctp.mspx
Esta edição pode ser utilizada para criar aplicações baseadas em bancos de dados. Ela é integrada com o
Visual Studio 2005, o que facilita bastante o desenvolvimento. Por exemplo, ao invés de criar aplicações
baseadas no Access, você pode criá-las baseadas no SQL Server 2005 Express Edition, o qual é bem mais
confiável, robusto e seguro do que o Microsoft Access. Esta edição é recomendada para o uso com aplicações
que precisam de um banco de dados no cliente, para armazenar informações localmente, ou até mesmo
para banco de dados no servidor, mas para um número pequeno de usuários e acessos simultâneos.
COMPARAÇÃO ENTRE AS VERSÕES

A seguir apresento algumas tabelas comparativas entre os recursos das diferentes edições. Estas tabelas,
sempre atualizadas, podem ser acessadas diretamente no site da Microsoft, no seguinte endereço:
♦ http://www.microsoft.com/sql/2005/productinfo/sql2005features.mspx
Tabela 15.1 Comparação entre Escalabilidade e Performance.
Característica Express Workgroup Standard Enterprise
Número de CPUs 1 2 4 Sem limites

RAM 1 GB 3 GB Sem Limites Sem limites
Suporte 64-bits Sim Sim
Tamanho de banco de dados 4 GB Sem Limites Sem Limites Sem limites
Particionamento Sim
Parallel Index Operations Sim
Tabela 15.2 Disponibilidade.
Característica/Edição Express Workgroup Standard Enterprise
Database Mirroring Sim Sim

Failover Clustering Sim Sim
Backup Log-shipping Sim Sim Sim
continuação
continuação
Online System Changes Sim Sim Sim Sim

Online Indexing Sim
Online Page and File Restore Sim
Fast Redo Sim
Tabela 15.3 Gerenciamento e Administração.
Auto Tuning Sim Sim Sim Sim

Express Manager Sim Sim Sim Sim
Management Studio Sim Sim Sim
Database Tuning Advisor Sim Sim Sim
Serviceability Enhancements Sim Sim Sim Sim
Full Text Search Sim Sim Sim
SQL Agent Job Scheduling Service Sim Sim Sim
NOTA
No endereço a seguir, você encontra diversas outras tabelas, comparando uma série de características do SQL Server 2005, em relação às
suas diferentes edições. Esta é uma informação importante na hora de definir qual a melhor edição do SQL Server 2005 a ser utilizada na
sua empresa: http://www.microsoft.com/sql/2005/productinfo/sql2005features.mspx
CONCLUSÃO
Neste capítulo, que encerra o livro, apresentei mais alguns itens e novidades do SQL Server 2005.
Inicialmente você aprendeu sobre a criação e uso de um ou mais snapshots de um banco de dados.
Conforme destaquei neste tópico, esta funcionalidade está disponível somente no SQL Server 2005
Enterprise Edition.
Em seguida abordei sobre a criação de diagramas de um banco de dados. Os diagramas nos permitem ter
uma visão geral da estrutura do banco de dados: tabelas, chaves primárias, chaves estrangeiras e
relacionamentos. É uma excelente ferramenta também para documentação da estrutura do banco de dados.
Na seqüência apresentei o passo-a-passo sobre como realizar uma série de tarefas úteis, bastante comuns
ao dia-a-dia do DBA:
♦ Como transferir um banco de dados de uma instância para outra.
♦ Como trabalhar com tabelas, diretamente no SQL Server Management Studio.
♦ Usar a opção de geração de scripts do SQL Server Management Studio.
Para encerrar o capítulo apresentei uma descrição detalhada das diferentes edições do SQL Server 2005.
Estão disponíveis as seguintes edições:
♦ SQL Server 2005 Enterprise Edition (32-bits e 64-bits)
♦ SQL Server 2005 Standard Edition (32-bits e 64-bits)
♦ SQL Server 2005 Workgroup Edition (somente 32-bits)
♦ SQL Server 2005 Developer Edition (32-bits e 64-bits)
♦ SQL Server 2005 Express Edition (somente 32-bits)
Muito bem, amigo leitor. Com isso encerramos mais um trabalho. Espero que este livro tenha sido útil
e tenha ajudado bastante no seu aprendizado. Para dúvidas sobre os exemplos do livro, para enviar
suas críticas, elogios e sugestões e para relatar eventuais erros contidos no livro, entre em contato
através do e-mail webmaster@juliobattisti.com.br
Acesse também, seguidamente, o site http://www.juliobattisti.com.br, no qual publicarei artigos e

tutoriais sobre o SQL Server 2005, abordando tópicos não contidos neste livro ou tópicos que
complementam a abordagem contida aqui no livro. No site você encontrará também um fórum de
discussão sobre o SQL Server 2005, no seguinte endereço: http://www.juliobattisti.com.br/forum.
Anexo
REFERÊNCIA ATRAVÉS DE EXEMPLOS, DOS
PRINCIPAIS COMANDOS DA LINGUAGEM T-SQL
INTRODUÇÃO
Neste anexo, apresentaremos um guia de referência rápida para os principais comandos da linguagem
T-SQL. Apresentarei alguns dos exemplos colocados nos demais capítulos do livro. O objetivo é pôr os
diversos exemplos em um único local para que o leitor possa utilizar como uma referência rápida.
Em inúmeros exemplos deste livro, utilizei comandos da linguagem T-SQL. Em alguns, utilizamos
estes comandos na janela de execução de comandos T-SQL. Nesta janela, os comandos são digitados
utilizando a sintaxe da linguagem T-SQL e depois executados. Mas também executamos uma série de
comandos utilizando o SQL Server Management Studio. Cada vez que utilizamos um assistente ou
uma janela de propriedades, estamos passando informações para o servidor SQL Server. O servidor
recebe as informações passadas pela interface gráfica e monta um comando T-SQL para execução da
respectiva tarefa. Em resumo, o SQL Server Management Studio é, simplesmente, uma interface gráfica
que facilita a criação e execução de comandos T-SQL.
O mais importante é estarmos cientes de que a grande maioria das ações realizadas, em um servidor
SQL Server 2005, é executada através de um ou mais comandos T-SQL. Estes comandos podem ter sido
digitados e executados diretamente na janela de execução de comandos T-SQL, ou montados com
auxílio do SQL Server Management Studio. Por isso é importante conhecermos os principais comandos
T-SQL e a sintaxe destes comandos.
Neste anexo, veremos a sintaxe dos principais comandos T-SQL, bem como exemplos de utilização
destes comandos. Para acompanhar os exemplos, aqui apresentados, o amigo leitor deverá utilizar a
janela de execução de comandos T-sQL. Utilizarei, na maioria dos exemplos, o Banco de Dados
Northwind. Este Banco de Dados, não é instalado por padrão com o SQL Server 2005. No capítulo
sobre o DTS Import/Export Wizard, eu mostrei como importar este banco de dados de uma instância
do SQL Server 2000 para uma instância do SQL Server 2005.
Apresentarei dois grupos distintos de comandos:
♦ Para seleção, atualização, exclusão e inserção de dados: Ao estudarmos este grupo de comandos,
veremos exemplos de utilização dos comandos SELECT, INSERT, UPDATE e DELETE. Veremos
as diversas cláusulas e opções destes comandos. Veremos como utilizar a cláusula JOIN para
criar views que retornam dados de duas ou mais tabelas. Também trataremos de cláusulas
como WHERE, IN, LIKE, etc.
♦ Para criação e manipulação de objetos de um Banco de Dados: Neste grupo de comandos

veremos como criar e manipular objetos do Banco de Dados, tais como: Bancos de Dados,
tabelas, views, stored procedures, etc.
Alguns dos comandos que veremos neste anexo exigem que você tenha permissão de administrador,
no SQL Server 2005, para executá-los. Se a instância do SQL Server 2005, que você está utilizando, está
no modo de segurança Windows Authentication, você deverá fazer o logon com uma conta de
administrador do Windows. Esta conta, automaticamente, possuirá permissões de administrador no
SQL Server 2005. Se a instância do SQL Server 2005, que você está utilizando, está no modo de segurança
Windows and SQL Server Authentication, você pode utilizar tanto uma conta de administrador do
Windows, quanto a conta sa ou qualquer outra conta que pertença à role sysadmin.
ANEXO – REFERÊNCIA ATRAVÉS DE EXEMPLOS, DOS PRINCIPAIS COMANDOS DA LINGUAGEM T-SQL
Você também pode fazer o logon com uma conta de usuário, no sistema operacional, e depois fazer o
logon com a conta sa no SQL Server 2005.
NOTA
Para maiores informações sobre segurança no SQL Server 2005, consulte o Capítulo 6.
NOÇÕES BÁSICAS DA LINGUAGEM SQL –

COMANDOS PARA CONSULTAR DADOS
Como o próprio nome sugere – Microsoft SQL Server 2005 – a linguagem utilizada pelo Microsoft SQL
Server 2005 é o T-SQL (Transaction – Structured Query Language). O T-SQL é utilizado para uma série
de operações, como por exemplo:
♦ Selecionar um conjunto de registros com base em um ou mais critérios de pesquisa.
♦ Criar Bancos de Dados.
♦ Criar novas tabelas.
♦ Configurar opções de segurança.
♦ Excluir registros, etc.
Embora a maioria destas operações possa ser feita através da interface gráfica do Microsoft SQL Server
2005, existem situações em que precisamos conhecer e utilizar a linguagem T-SQL. Nos capítulos deste
livro, para a criação de store procedures, triggers e outros recursos avançados, utilizamos a linguagem
T-SQL.
Neste anexo, apresentaremos uma referência para os principais comandos da linguagem T-SQL.
Aprenderemos os comandos para manipulação de dados – consultar, inserir, alterar e excluir.
NOTA
Quando for utilizada a sigla SQL, é porque faço referência ao padrão SQL de uma maneira genérica. Quando for utilizada a sigla T-SQL
estarei me referindo à implementação da linguagem SQL feita pela Microsoft no SQL Server 2005.
INTRODUÇÃO
O SQL foi desenvolvido para ser uma linguagem padrão para operações em Banco de Dados. A linguagem
SQL foi elaborada para ser independente de hardware ou software. Ao usar SQL, você não precisa saber
a respeito do software de Banco de Dados ou do hardware envolvido em uma operação. Tudo o que
você precisa conhecer é o método (instrução) SQL padrão para solicitar informações, método este que,
obrigatoriamente, é o mesmo em todos os sistemas que utilizam o SQL (na verdade deveria ser o
mesmo mas não é. Na prática existem diferenças e inconsistências entre os padrões SQL utilizados em
diferentes bancos de dados, tais como o SQL Server, ORACLE, DB2 e outros).
NOTA
Existem pequenas diferenças nas implementações do SQL de diferentes fabricantes. Desta forma algumas rotinas escritas utilizando, por
exemplo, o SQL Plus do Oracle podem não rodar, sem as devidas adaptações, no Microsoft SQL Server e vice-versa.
Uma instrução SQL descreve o conjunto de dados que você deseja recuperar (quais campos, de quais
tabelas, critérios de filtragem, classificação, expressões calculadas, etc.).
Todas as instruções T-SQL são conduzidas como um único comando que contém uma descrição completa
da informação exigida. Ao escrever uma instrução T-SQL, você não deve se preocupar em como os
dados são recuperados, mas somente com o conteúdo do conjunto de dados. Esse é o principal benefício
do método T-SQL.
Lembre-se que o SQL é um padrão genérico para expressões de consulta em Banco de Dados. Embora
a maior parte das versões do SQL compartilhe elementos básicos, elas não são idênticas. O Access SQL
usa algumas palavras-chave que você não encontra em outras versões do SQL. Também existem pequenas
diferenças entre o Microsoft Access e o Microsoft SQL Server.
Veremos através de exemplos a utilização das principais palavras-chave do T-SQL para a construção de
expressões SQL para pesquisa em Banco de Dados.
A INSTRUÇÃO SELECT
Esta, sem dúvida, é a instrução T-SQL mais importante; não existe pesquisa que não utilize esta instrução.
Vamos conhecê-la em detalhes.
A instrução SELECT é utilizada para especificar quais campos de quais tabelas farão parte da consulta,
quais os critérios de pesquisa que serão utilizados, qual a ordem de classificação, qual o relacionamento
entre as tabelas e assim por diante.
A sintaxe simplificada da instrução é conforme indicado abaixo:
SELECT
campo1, campo2, campo3
FROM nome_da_tabela
[WHERE condição ]
[GROUP BY nome_do_campo ]
[HAVING ... ]
ORDER BY... ]
Na Tabela A.1 temos uma descrição destes elementos:
Tabela A.1 Os principais elementos da instrução SELECT.
Elemento Descrição
campo1, campo2, campon Nome dos campos a serem retornados a partir de uma ou mais tabelas.
nome_da_tabela Nome da tabela a partir da qual os dados devem ser recuperados.
WHERE Permite que sejam especificados critérios de pesquisa.
GROUP BY Podemos agrupar os resultados em torno de um ou mais campos de dados. Por exemplo, em
um relatório de vendas anuais, posso ter os resultados agrupados por mês, com a soma das
vendas do mês logo após a listagem de vendas daquele mês.
HAVING Especifica critérios para serem utilizados juntamente com Group By. Quando utilizamos Group
By, não podemos utilizar a cláusula WHERE para especificar critérios, ao invés disso devemos
utilizar a cláusula HAVING.
ORDER BY Podemos ordenar os resultados obtidos com base em um ou mais campos de dados. Por
exemplo, podemos ordenar uma listagem de vendas em ordem alfabética do nome do cliente
ou do nome do vendedor.
Vamos analisar alguns exemplos práticos de utilização da linguagem SQL.

NOTA
Para os exemplos deste anexo vou utilizar o Banco de Dados Nortwhind. Este Banco de Dados está com os nomes de tabelas e nomes de
campos em inglês. Utilizarei os nomes em inglês nos exemplos deste anexo. Você pode utilizar a janela de execução de comandos T-SQL,
conforme já descrito nos capítulos do livro, para executar e testar os exemplos apresentados aqui.
Para que possamos executar uma instrução SELECT em uma ou mais tabelas de um Banco de Dados, na
janela de execução de comandos T-SQL, o Banco de Dados onde estão as tabelas deve ser o banco de
dados atual. Para tornar um banco de dados o Banco de Dados atual, utilizamos o comando USE
nome_banco_de_dados. Por exemplo, para tornar o Banco de Dados Northwind o Banco de Dados
atual, utilizamos o seguinte comando:
USE Northwind
Agora alguns exemplos práticos.
Exemplo 1: Criar uma instrução SQL que retorne os campos OrderID, OrderDate, Freight e ShipCountry
da tabela Orders.
SELECT Orders.OrderID, Orders.OrderDate, Orders.ShipCountry, Orders.Freight FROM Orders
Observe que os nomes dos campos estão separados por vírgula, e além disso estamos utilizando o
nome completo, isto é: Nome_da_tabela.Nome_do_campo. Também poderíamos utilizar o comando,
sem o nome da tabela, antes do nome do campo, conforme indicado no seguinte comando:
SELECT OrderID, OrderDate, ShipCountry,Freight FROM Orders
NOTA
Somente é obrigatória a utilização do nome da tabela antes do nome do campo quando o mesmo campo existir em duas ou mais tabelas que
fazem parte da instrução SELECT.
Por exemplo, imagine que estejamos escrevendo uma instrução T-SQL para criar uma listagem com o
código e o nome do cliente, bem como todos os pedidos efetuados pelo cliente. Acontece que o código
do cliente, no nosso exemplo, existe nas duas tabelas: Customers e Orders. Neste caso, devemos
especificar o nome da tabela, antes do nome do campo.
Exemplo 2: Alterar a instrução SQL anterior para que os registros sejam classificados em ordem crescente
pelo valor do campo Freight.
Para classificar a listagem obtida, utilizamos uma cláusula ORDER BY Nome_do_campo.
SELECT OrderID, OrderDate, ShipCountry, Freight FROM Orders

ORDER BY Freight
Observe a utilização da cláusula “ORDER BY Freight” para classificar os registros em ordem crescente
do campo Freight (frete). A classificação em ordem crescente é a padrão. Quando formos classificar em
ordem decrescente, precisamos especificar a palavra DESC, conforme indicado a seguir:

ORDER BY Freight DESC
Exemplo 3: Agora vamos começar a inserir condições. Muitas vezes as condições são chamadas de
filtro. Uma vez estabelecida uma condição, somente os registros que “atendem” a condição especificada
serão retornados. Desta forma a condição atua como se fosse um filtro. Neste exemplo, vamos alterar
a instrução SQL anterior para que sejam exibidos somente os pedidos cujo campo ShipCountry seja
igual a Brazil.

WHERE ShipCountry=‘Brazil’
ORDER BY Freight
NOTA
Estou utilizando Brazil com “z” porque os dados do Banco de Dados Northwind estão em inglês.
Observe a utilização da cláusula WHERE para filtrar somente os pedidos cujo país (campo ShipCountry)
seja Brazil. Como o campo ShipCountry é um campo do tipo texto, o valor do critério (Brazil) tem que
vir entre apóstrofes. Vamos trabalhar um pouco mais com a cláusula WHERE.
Exemplo 4: Altere a instrução SQL anterior para que sejam exibidos somente os pedidos para o Brasil
ou Alemanha.

WHERE Orders.ShipCountry=‘Brazil’ OR Orders.ShipCountry=‘Alemanha’
ORDER BY Freight
Observe a utilização da cláusula OR ligando os dois critérios. Lembre que esta cláusula retorna um
registro se o campo ShipCountry atender um dos dois critérios, isto é, se for Brasil ou se for Alemanha,
o registro será selecionado, que é exatamente o que desejamos, ou seja, todos os pedidos para o Brasil
ou para a Alemanha.
Exemplo 5: Altere a instrução SQL anterior, retirando o critério para o campo ShipCountry. Adicione
um critério para o campo OrderID com valor maior do que 10500, retire a classificação do campo
Freight e classifique pelo campo OrderID.

WHERE OrderID > 10500
ORDER BY OrderID
Observe a cláusula WHERE utilizando o operador de comparação maior do que ( > ) e a classificação
através da cláusula ORDER BY no campo OrderID.
Na Tabela A.2 temos uma relação com os principais operadores de comparação.
Tabela A.2 Operadores de comparação.
Operador Descrição
= Igual
<> Diferente
!= Diferente
> Maior do que
< Menor do que
>= Maior ou igual à
<= Menor ou igual à
!> Não maior do que
!< Não menor do que
Podemos ver, através dos exemplos, que a linguagem SQL não é tão difícil como pode parecer à primeira
vista. Observe que a sintaxe da linguagem é bastante intuitiva e orientada à extração de dados através
das consultas.
Vamos continuar analisando alguns exemplos de aplicação da linguagem SQL com a utilização de
recursos mais avançados.
Exemplo 6: Alterar a instrução SQL anterior, e adicionar um critério de tal maneira que somente sejam
exibidos os pedidos para o ano de 1997. Tirar o critério do campo OrderID.

WHERE Year([OrderDate])=1997
ORDER BY OrderID
Observe a utilização da função Year([Nome_do_campo]), para extrairmos apenas o ano do campo
OrderDate e especificarmos como critério o Ano=1997. Também a cláusula ORDER BY foi mantida,
classificando a listagem em ordem crescente pelo número do pedido. A utilização de funções junto
com os comandos T-SQL nos fornece inúmeras possibilidades de refinamento em nossas consultas.
Exemplo 7: Alterar a instrução SQL anterior, para que sejam exibidos somente os pedidos no período
de 01/01/1997 até 31/07/1997 e que tenham ShipCountry=Brazil, Argentina, Alemanha ou Canadá.

WHERE OrderDate Between ‘1/1/97’ And ‘7/31/97’
AND
ShipCountry In (‘Brazil’,‘Argentina’,‘Alemanha’,‘Canadá’)
ORDER BY OrderID
Observe a utilização de vários critérios em diferentes campos. Colocamos critérios nos campos OrderDate
e ShipCountry. Os critérios de dois ou mais campos são ligados através do operador AND, indicando
que um registro deve atender ambos os critérios para ser selecionado. Também temos a utilização dos
operadores BETWEEN (Entre) para selecionar as datas dentro de um determinado intervalo, e do operador
IN (Em), para selecionar o campo ShipCountry que seja igual a um dos valores apresentados na lista.
Observe também que os valores de data vêm delimitados por apóstrofes (‘).
O operador IN pode ser utilizado para definirmos uma série de valores aceitáveis em um determinado
campo. No exemplo temos a seguinte utilização da cláusula IN:
ShipCountry In (‘Brazil’,‘Argentina’,‘Alemanha’,‘Canadá’)
Neste caso, definimos que o campo ShipCountry pode assumir um dos valores definidos na lista de
valores, ou seja: Brazil, Argentina, Alemanha ou Canadá. Somente serão retornados os pedidos para
estes países. Utilizamos o operador IN ao invés de uma série de operadores OR.
Embora o efeito seja o mesmo, o comando ficaria maior e mais difícil de interpretar. Por exemplo, ao
invés do operador IN anterior, poderíamos utilizar a seguinte seqüência de operadores OR:
WHERE OrderDate Between ‘1/1/97’ And ‘7/31/97’

AND
(ShipCountry=‘Brazil’ OR ShipCountry=‘Argentina’ OR ShipCountry=‘Alemanha’ OR ShipCountry=‘Canadá’)
Utilizamos os parênteses para garantir que a série de testes com o operador OR seja executada como
um todo e o resultado desta avaliação seja utilizado como segundo parâmetro para o operador AND.
Exemplo 8: Criar uma instrução T-SQL que retorne os campos OrderID, OrderDate, OrderDate, Freight
e ShipCountry da tabela Orders. Criar uma coluna adicional que calcula o número de dias entre os
campos ShippedDate e OrderDate. Chamar esta coluna de Dias_Ped_Entr. Manter os critérios
estabelecidos no exemplo anterior.
SELECT OrderID, OrderDate, ShippedDate, ShipCountry, Freight,

ShippedDate-OrderDate AS Dias_Ped_Entr FROM Orders
WHERE (OrderDate Between ‘1/1/97’ And ‘7/31/97’)
AND
(ShipCountry In (‘Brasil’,‘Argentina’,‘Alemanha’,‘Canadá’))
ORDER BY Orders.OrderID
Veja que a coluna calculada ShippedDate - OrderDate está junto com a listagem dos campos no início
da instrução SELECT. Além disso foi utilizada a palavra AS para atribuir um nome (apelido) para esta
coluna calculada. Este nome é o que será utilizado para fazer referência à coluna, em uma página ASP
ou um programa desenvolvido em Visual Basic, por exemplo.
Desta forma, para criar uma coluna calculada a partir de outras colunas, basta colocar a expressão de
cálculo e utilizar a cláusula AS para atribuir um nome à coluna calculada.
Você também pode classificar a listagem em ordem crescente ou decrescente de um campo calculado.
Por exemplo, se você quisesse classificar a listagem do item anterior, em ordem crescente, do número
de dias entre a Data de envio e a Data do pedido, bastaria utilizar a seguinte instrução SQL:
SELECT OrderID, OrderDate, ShippedDate, ShipCountry, Freight, ShippedDate-OrderDate AS

Dias_Ped_Entr
FROM Orders
WHERE (OrderDate Between ‘1/1/97’ And ‘8/31/97’)
AND
(ShipCountry In (‘Brasil’,‘Argentina’,‘Alemanha’,‘Canadá’))
ORDER BY DataDeEntrega-OrderDate
O OPERADOR LIKE
Utilizamos o operador LIKE para fazer pesquisas aproximadas ou por parte do conteúdo de um campo.
Por exemplo para pesquisar todos os pedidos em que o nome do cliente contenha a palavra Silva em
qualquer parte do nome. Esta é uma pesquisa aproximada, pois retornará os pedidos para José da Silva,
Paulo Costa e Silva, Antônio da Silva, Silvano Farias e assim por diante. Observe que o nome Silvano
contém a string Silva e por isso também é retornado. Por exemplo, para retornar somente os clientes
em que o nome se inicia com a letra J, podemos utilizar o seguinte comando:
SELECT *
FROM Customers
WHERE (ContactName LIKE ‘J%’)
ORDER BY ContactName
O símbolo % significa “qualquer coisa”, ou seja, o campo ContactName deve se iniciar com a letra J,
não importando o que venha depois.
Na Tabela A.3, temos uma relação com os caracteres especiais que podem ser utilizados com o operador LIKE.
Tabela A.3 Caracteres especiais do operador LIKE.
Operador Significa
% Qualquer string de zero ou mais caracteres.

_ Qualquer caracter simples.
[] Qualquer caracter simples, dentro de uma faixa. Por exemplo, para pesquisar somente os
clientes em que a primeira letra do nome esteja na faixa de A até L, utilizamos o seguinte
critério: WHERE ContactName LIKE ‘[A-L]%’.
[^] Qualquer caracter simples, que não esteja dentro de uma faixa. Por exemplo, para pesquisar
somente os clientes em que a primeira letra do nome não esteja na faixa de A até L,
utilizamos o seguinte critério: WHERE ContactName LIKE ‘[^A-L]%’.
Agora alguns exemplos de utilização.
Exemplo 9: Alterar a instrução SQL do Exemplo 8, eliminando os critérios para a OrderDate e para o
ShipCountry. Colocar um novo critério para ShipCountry, onde sejam exibidos apenas os pedidos em
que o campo ShipCountry tem a primeira letra na faixa de A até M. Utilize o operador LIKE.
SELECT OrderID, OrderDate, ShippedDate, ShipCountry, Freight, ShippedDate-OrderDate AS

Dias_Ped_Entr
FROM Orders
WHERE ShipCountry LIKE ‘[A-M]%’
ORDER BY ShipCountry
Observe a utilização do operador LIKE no critério de pesquisa para esta consulta. Nunca é demais
salientar que a utilização das instruções T-SQL, juntamente com as funções e operadores como o LIKE,
nos fornece um amplo conjunto de possibilidades. O caracter % é utilizado como um curinga. Por
exemplo, se especificarmos o seguinte critério:
WHERE NomeDoCLiente LIKE ‘João%’
serão retornados todos os registros para clientes cujo nome se inicia com João. O caracter curinga %
significa, em termos simples, “qualquer coisa”, ou seja, o critério especifica que o nome inicie com
João, não importando (qualquer coisa) o que vier depois.
Aqui cabe um aviso importante para os usuários do Microsoft Access. No Microsoft Access, o caracter curinga é o *, já no Microsoft SQL Server
NOTA
2005, utilizamos como caracter curinga o %, o qual também é utilizado na construção de páginas ASP.
Para maiores informações sobre a tecnologia ASP – Active Server Pages, consulte o e-book “Criando Sites Dinâmicos com ASP 3.0”, 732
páginas, de minha autoria. Maiores informações em http://www.juliobattisti.com.br/ebooksdoautor
Até agora trabalhamos com exemplos de instruções que selecionam registros de uma única tabela.
Porém é bastante comum criarmos instruções SQL baseadas em duas ou mais tabelas. Quando criamos
instruções SQL que buscam dados em duas ou mais tabelas, dizemos que está sendo feito um join entre
as duas tabelas.
Normalmente este “join” (ou ligação) é feito através de um campo comum às duas tabelas. Por exemplo,
OrderID na tabela Orders e OrderID na tabela Order Details. Outro exemplo, CustomerID na tabela
Orders e CustomerID na tabela Customers. Pode acontecer de termos consultas que trabalham com
três ou mais tabelas, e neste caso teremos diversos joins.
NOTA
O número de joins sempre é igual ao número de tabelas menos um. Por exemplo, se a nossa consulta acessar dados de quatro tabelas,
teremos três joins.
Agora passaremos e explorar na prática, através de exemplos, a construção de instruções SQL que
trabalham com duas ou mais tabelas.
Exemplo 10: Criar uma instrução SQL que selecione os campos relacionados a seguir.
♦ OrderID da tabela Orders.
♦ OrderDate da tabela Orders.
♦ ShipCountry da tabela Orders.
♦ Freight da tabela Orders.
♦ ProductID da tabela Order Details.
♦ UnitPrice da tabela Order Details.
♦ Quantity da tabela Order Details.
Além disso, as tabelas Orders e Order Details estão relacionadas pelo campo OrderID, através de um
relacionamento do tipo Um para Vários.
Classificar a listagem em ordem crescente do número do pedido.
Para resolver este exemplo podemos utilizar a seguinte instrução SQL:
SELECT Orders.OrderID, Orders.OrderDate, Orders.ShipCountry, Orders.Freight,

[Order Details].[ProductID], [Order Details].[UnitPrice], [Order Details].[Quantity]
FROM Orders
INNER JOIN
[Order Details]
ON Orders.OrderID = [Order Details].[OrderID]
Primeiro, devemos observar que, pelo fato de estarmos tratando com dados de duas tabelas, utilizamos
a nomenclatura completa, isto é, [Nome_da_tabela].[Nome_do_campo].
Observe a utilização da cláusula INNER JOIN, ligando as tabelas Orders e [Order Details], através do
campo OrderID, conforme especificado na cláusula ON, onde temos o seguinte:
ON Orders.OrderID = [Order Details].OrderID
Observe que esta listagem irá trazer vários registros para cada pedido, tantos quantos forem os itens de
cada pedido, conforme indicado na listagem parcial a seguir:
OrderID OrderDate ShipCountry Freight ProductID UnitPrice

10248 1996-07-04 France 32.3800 11 14.0000
10248 1996-07-04 France 32.3800 42 9.8000
10248 1996-07-04 France 32.3800 72 34.8000
10249 1996-07-05 Germany 11.6100 14 18.6000
10249 1996-07-05 Germany 11.6100 51 42.4000
10250 1996-07-08 Brazil 65.8300 41 7.7000
Mas, se ao invés do ProductID, nós quiséssemos que fosse exibida a descrição do produto?
Em primeiro lugar, esta informação encontra-se na tabela Products; logo, teremos que adicionar a
tabela Products à nossa consulta, a qual irá se ligar à tabela Order Details através do campo ProductID,
de forma que teremos mais um join. Para três tabelas teremos dois joins.
Após adicionar a tabela Products e substituir o campo ProductID pelo campo ProductName, a nossa
instrução SQL deve ficar conforme indicado no seguinte exemplo:

Products.ProductName, [Order Details].[UnitPrice], [Order Details].[Quantity]
FROM Products
INNER JOIN
(Orders INNER JOIN [Order Details]
ON
Orders.OrderID = [Order Details].[OrderID])
ON
Products.ProductID = [Order Details].[ProductID]
Observe que, neste caso, temos um INNER JOIN dentro do outro. Dentro do parênteses é feita a ligação
entre as tabelas Orders e Order Details, através do campo OrderID, e externamente é feita a ligação
entre as tabelas Products e Order Details, através do campo ProductID.
Podemos utilizar diversos níveis de INNER JOIN, embora esta não seja uma prática recomendada, pois,
se aumentarmos muito os níveis de INNER JOIN, podemos ter, como resultado, pesquisas mais lentas
em conseqüência do aumento da complexidade das consultas. Até três ou quatro níveis é considerado
normal, mas acima disso é preciso repensar a maneira de construir a consulta.
Vamos a um exemplo em que utilizamos join, uma cláusula WHERE e o operador LIKE.
Exemplo 11: Alterar a instrução SQL do item anterior para que somente sejam exibidos os pedidos para
os produtos cujo campo ProductName inicie com uma letra na faixa de A até J. Tirar a classificação do
campo OrderID e classificar em ordem crescente do campo ProductName.

Products.ProductName, [Order Details].[UnitPrice], [Order Details].[Quantity]
FROM Products
INNER JOIN
(Orders INNER JOIN [Order Details]
ON
Orders.OrderID = [Order Details].[OrderID])
ON
Products.ProductID = [Order Details].[ProductID]
WHERE (Products.ProductName LIKE ‘[A-J]%’)
ORDER BY Products.ProductName
Observe, além dos dois INNER JOIN, a utilização da cláusula WHERE em conjunto com operador LIKE
para especificar o critério desejado.
Até este momento apresentei exemplos de instruções SQL que executam consultas no Banco de
Dados. Especificamos quais campos serão exibidos, critérios de filtragem para estes campos e uma
ordem de classificação. A partir de agora, aprenderemos a utilizar comandos T-SQL para a construção
de outros tipos de instruções SQL, as quais realizam alterações, inclusões e exclusões em tabelas do
Banco de Dados.
NOÇÕES BÁSICAS DA LINGUAGEM T-SQL – COMANDOS

PARA ALTERAR, MODIFICAR E EXCLUIR DADOS
ATUALIZANDO DADOS – A INSTRUÇÃO UPDATE
A instrução UPDATE é utilizada para alterar registros em uma ou mais tabelas de um Banco de Dados.
Poderíamos, por exemplo, criar um formulário ASP ou ASP.NET, onde o usuário pode alterar os seus
dados cadastrais. Primeiro, os dados são recuperados a partir do Banco de Dados; em seguida, as alterações
são enviadas de volta para o Banco de Dados, através de uma instrução UPDATE. Vamos estudar esta
instrução através de exemplos, assim como fizemos com a instrução SELECT.
Exemplo 1: Criar uma instrução T-SQL que aumenta o campo UnitPrice em 20% na tabela Order
Details, devido a um ajuste na moeda e uma desvalorização do Real em relação ao Dólar.
UPDATE [Order Details]

SET UnitPrice = UnitPrice*1.2
Observe a simplicidade da instrução UPDATE. Utilizamos uma instrução UPDATE, seguida do nome da
tabela onde será feita a atualização. Em seguida, uma instrução SET com a expressão de atualização
para aumentar em 20% o valor do campo UnitPrice em todos os registros da tabela Order Details.
Na Tabela A.4, temos uma relação com os principais operadores matemáticos para realização de cálculos
básicos.
Tabela A.4 Operadores matemáticos.
Operador Descrição
+ Adição
- Subtração
* Multiplicação
/ Divisão
Vamos alterar a instrução anterior, para incluir um critério na consulta de atualização. Quando utilizamos
um critério em conjunto com a instrução UPDATE, somente os registros que atendem o critério
especificado serão atualizados.
Exemplo 2: Alterar a instrução SQL do exemplo anterior para que somente seja aumentado em 20% o
campo UnitPrice dos registros cujo PreçoUnitário for maior ou igual a R$ 20,00.

WHERE UnitPrice >= 20
Adicionamos uma cláusula WHERE, para atualizar apenas os registros cujo PreçoUnitário seja maior
ou igual a R$ 20,00.
Exemplo 3: Alterar a instrução T-SQL do exemplo anterior para que somente sejam aumentados os registros
cujo PreçoUnitário seja maior ou igual a R$ 20,00 e cujo campo OrderID seja menor do que 10500.

WHERE (UnitPrice >= 20)
AND
(OrderID<10500)
Observe que utilizamos critérios em dois campos (UnitPrice e OrderID) e que estes critérios estão
ligados por um operador AND, o que significa que um registro** somente será atualizado se atender
aos dois critérios ao mesmo tempo (UnitPrice maior ou igual a 20 e OrderID menor do que 10500). Se
o registro atender apenas uma das condições, o registro não terá o seu preço unitário atualizado.
Vamos refinar um pouco mais a nossa consulta de atualização. Vamos fazer com que somente sejam
atualizados os pedidos em que o ano do campo OrderDate seja igual a 1997, e ainda iremos manter os
critérios adicionados nos exemplos anteriores.
Exemplo 4: Alterar a instrução T-SQL do exemplo anterior para incluir um critério para que o ano do
campo OrderDate seja 1997. Você terá que incluir a tabela Orders, uma vez que o campo OrderDate
encontra-se nesta tabela. Neste caso, vamos utilizar uma instrução UPDATE, em conjunto com uma
cláusula WHERE.

SET [Order Details].[UnitPrice]=[Order Details].[UnitPrice]*1.2
FROM [Order Details], Orders
WHERE
[Order Details].[OrderID]=[Orders].[OrderID]
AND
([Order Details].[UnitPrice]>=20)
AND
([Order Details].[OrderID]<10500)
AND
Year(OrderDate)=1997
Observe que fizemos o relacionamento entre as duas tabelas, através da definição de um critério na
cláusula WHERE, conforme indicado a seguir:
WHERE
[Order Details].[OrderID]=[Orders].[OrderID]
AND
...
Novamente, a utilização de operadores e funções nos fornece uma grande flexibilidade em termos de
construção de nossas consultas.
INSERINDO NOVOS REGISTROS – A INSTRUÇÃO INSERT

A instrução INSERT é utilizada para adicionar registros em uma tabela de um Banco de Dados. Por
exemplo, quando o usuário preenche os dados de um formulário de cadastro e os envia para o
Banco de Dados, podemos utilizar a instrução INSERT para inserir estes dados em uma tabela do
Banco de Dados.
Vamos analisar alguns exemplos.
Exemplo 1: Este exemplo cria um novo registro na tabela Funcionários:
INSERT INTO Employees (EmployeeID,FirstName, LastName, Title)

VALUES (10,‘Paulo’, ‘Braga’, ‘Estagiário’,‘RH Manager’)
Esta instrução insere um registro na tabela Funcionários com os seguintes dados:
♦ EmployeeID: 10.
♦ FirstName: Paulo.
♦ LastName: Braga.
♦ Title: RH Manager.
Exemplo 2: Este exemplo seleciona todos os estagiários de uma tabela Estagiários que tenham sido
contratados há mais de 30 dias e adiciona os registros selecionados à tabela Funcionários.
Este exemplo não leva em consideração o Banco de Dados Northwind. Estamos considerando um Banco de Dados qualquer, onde tenhamos
NOTA
as tabelas Estagiários e Funcionários.

INSERT INTO Funcionários
SELECT Estagiários.* FROM Estagiários
WHERE DataDaContratação < Date() - 30
Observe que utilizamos a função Date( ) para capturar a data do sistema e subtraímos 30, para obter
apenas os funcionários contratados há mais do que 30 dias.
EXCLUINDO DADOS – A INSTRUÇÃO DELETE

A instrução DELETE é utilizada para excluir registros de um Banco de Dados. Vamos supor que você
tenha desenvolvido uma aplicação Web para agenda eletrônica, onde o usuário pode cadastrar contatos,
endereços, telefones e compromissos. Podemos criar uma página ASP que permite ao usuário eliminar
dados que não sejam mais necessários na agenda. Neste caso, podemos fazer uso da instrução DELETE.
Exemplo 1: Criar uma instrução SQL que elimine todos os pedidos da tabela Orders em que o campo
ShipCountry seja Germany (Alemanha).
DELETE FROM Orders

WHERE Orders.ShipCountry=‘Germany’
A instrução é tão simples que praticamente dispensa comentários. A única recomendação importante
é que não devemos utilizar uma instrução DELETE, sem a utilização de uma cláusula WHERE. Utilizar
um DELETE sem uma cláusula WHERE significa que iremos excluir todos os registros da tabela.
Neste item, apresentamos uma breve introdução à linguagem T-SQL, que no Microsoft SQL Server é
chamada de Transact-SQL.
COMANDOS PARA CRIAÇÃO E MANIPULAÇÃO

DOS OBJETOS DO BANCO DE DADOS
Agora veremos uma série de comandos para criação e manipulação de objetos de um Banco de Dados.
Vamos tratar, dentre outros, de comandos para as seguintes funções:
♦ Criação de Bancos de Dados.
♦ Criação de tabelas em um Banco de Dados.
♦ Criação de índices em uma tabela.
♦ Criação de views.
♦ Criação de stored procedures.
♦ Criação de triggers.
♦ Criação de logins e usuários.
♦ Atribuição de permissões de acesso.
Os comandos que aprenderemos neste item são executados utilizando a janela de execução de comandos
T-SQL, janela esta que você aprendeu a utilizar nos capítulos do livro.
CRIANDO UM BANCO DE DADOS –

O COMANDO CREATE DATABASE
Para criar um Banco de Dados, utilizamos o comando CREATE DATABASE. A seguir, a sintaxe para este
comando com alguns comentários.
Sintaxe comentada para o comando CREATE DATABASE:
CREATE DATABASE NOME_DO_BANCO_DE_DADOS

ON
— *************************
— *************************
(NAME= Nome_Lógico_Arquivo_Primário,
FILENAME = ‘Caminho para gravar o arquivo, por ex. C:\livrosql\exemplo3\ex3-prim.mdf’,
FILEGROWTH = Incremento),
— ***************************
— ***************************
(NAME= Nome_Lógico_Arquivo_Secundário,
FILENAME = ‘Caminho para gravar o arquivo, por ex. C:\livrosql\exemplo3\ex3-sec.ndf’,
— *************************
— *************************
LOG ON
(NAME= Nome_Lógico_Arquivo_Log,
FILENAME = ‘Caminho para gravar o arquivo, por ex. C:\livrosql\exemplo3\ex3-log.ldf’,
— ***************************************
— ***************************************
Conforme vimos no Capítulo 3, um Banco de Dados pode conter um arquivo primário (.mdf), um ou
mais arquivos secundários (.ndf) e um ou mais arquivos de log (.ldf).
Agora, vamos utilizar o comando CREATE DATABASE para criar um Banco de Dados chamado
BDExemplo, com as características definidas na Tabela A.5. Os arquivos primário, secundário e de log
deverão ser salvos em C:\livrosql\exemplo3. Esta pasta já deve existir antes da execução do comando,
caso contrário ao executarmos o comando este será encerrado e uma mensagem de erro será emitida.
Exemplo: Criar um Banco de Dados com as características definidas na Tabela A.5.
Tabela A.5 Banco de Dados BDExemplo.
Primário C:\livrosql\BDExemplo\BDExemplo-prim.mdf.
Secundário C:\livrosql\BDExemplo\BDExemplo-sec1.ndf.
Arquivo de log C:\livrosql\BDExemplo\BDExemplo-log1.ldf.
Para criar o Banco de Dados BDExemplo, utilizamos o seguinte comando:
CREATE DATABASE BDExemplo

ON
— *************************
— *************************
(NAME= BDExemplo_prim,
FILENAME = ‘C:\livrosql\BDExemplo\BDExemplo-prim.mdf ‘,
SIZE= 7MB,
MAXSIZE= 25MB,
FILEGROWTH = 1MB),
— ***************************
— ***************************
(NAME= BDExemplo_sec1,
FILENAME = ‘C:\livrosql\BDExemplo\BDExemplo-sec1.ndf ‘,
SIZE= 10MB,
MAXSIZE= 50MB,
FILEGROWTH = 10%)
— *************************
— *************************
LOG ON
(NAME= BDExemplo_log1,
FILENAME = ‘C:\livrosql\BDExemplo\BDExemplo-log1.ldf ‘,
SIZE= 7MB,
MAXSIZE= 25MB,
FILEGROWTH = 2MB)
— ***************************************
— ***************************************
NOTA
Veja que utilizei o caracter de sublinhado _ para os nomes lógicos, pois não podemos utilizar o sinal de -, o qual não é um caracter válido
para um nome lógico. Se utilizarmos o sinal de - , devemos colocar os nomes entre apóstrofes.
BDExemplo terá sido criado e já deverá ser exibido na lista de banco de dados.
CRIAÇÃO DE TABELAS EM UM BANCO DE DADOS – O COMANDO CREATE TABLE

Para criar uma tabela em um Banco de Dados, utilizamos o comando CREATE TABLE.
A seguir, a sintaxe para este comando, com alguns comentários.
Sintaxe comentada para o comando CREATE TABLE:
CREATE TABLE Nome_da_tabela
— Agora inicio a definição básica dos campos da tabela
(
Campon tipo_do_Campon NULL ou NOT NULL

)
A título de exemplo, vamos criar a tabela Produtos, no Banco de Dados BDExemplo criado anteriormente,
com os campos indicados na Tabela A.6.
Tabela A.6 A tabela Produtos.
CódigoProduto Integer
NomeProduto Texto de no máximo 50 caracteres.
CódigoCategoria Integer
PreçoUnitário money
UnidadesEstoque Integer
EstoqueMínimo Integer
Descontinuado bit (0=sim, 1=não)
Agora, vamos criar esta tabela no Banco de Dados BDExemplo. Vamos utilizar, para isso, o comando
CREATE TABLE indicado a seguir:
— Primeiro torno o Banco de Dados BDExemplo

— o Banco de Dados atual
USE BDExemplo
(
CódigoProduto int,
NomeProduto char(50),
EstoqueMínimo int,
Descontinuado bit
)
NOTA
Certifique-se de ter alternado para o Banco de Dados BDExemplo, utilizando o comando Use BDExemplo.
Ao executar este comando, se você não tiver cometido nenhum erro de digitação, a tabela Produtos
terá sido criada no Banco de Dados BDExemplo e a seguinte mensagem será exibida:
CRIAÇÃO DE ÍNDICES EM UMA TABELA – O COMANDO CREATE INDEX

Para criar um índice em uma tabela de um Banco de Dados, utilizamos o comando CREATE INDEX.
A seguir, a sintaxe para este comando, com alguns comentários.
Sintaxe comentada para o comando CREATE INDEX:

ON { table | view }
( column [ ASC | DESC ] [ ,...n ] )
Para criar o seguinte índice:
♦ Nome: CityIndex
♦ Colunas: City
♦ Permitir valores duplicados
utilizaríamos o seguinte comando:
CREATE INDEX CityIndex ON Customers (City)
Vamos a um exemplo um pouco mais elaborado. Qual seria o comando para criar o seguinte índice?
♦ Nome: PK_Customers
♦ Colunas: CustomerID
Neste caso, utilizaríamos o seguinte comando:
CREATE UNIQUE CLUSTERED

INDEX PK_Customers ON Customers (CustomerID)
WITH DROP_EXISTING
Ao utilizarmos a opção WITH DROP_EXISTING, orientamos o SQL Server a excluir o índice, caso ele já
exista e a recriá-lo novamente. Se não utilizarmos esta opção e o índice já existir, será emitida a seguinte
mensagem de erro:

There is already an index on table ‘Customers’ named ‘PK_Customers’.
Vamos a mais um exemplo.
Agora, vamos criar um índice composto com as seguintes características:
♦ Nome: EnderecoIndex.
♦ Colunas: Address, City e Region.
♦ Ignorar valores duplicados.
Neste caso utilizaríamos o seguinte comando:

WITH IGNORE_DUP_KEY
Neste caso, utilizamos a opção UNIQUE para criar um índice único e a opção WITH IGNORE_DUP_KEY
para ignorar valores duplicados já existentes.
Algumas considerações para a criação de índices compostos por mais do que um campo:
1. Podemos criar um índice composto por, no máximo, 16 colunas. Além disso, a soma do tamanho
das 16 colunas não pode ultrapassar 900 bytes.
2. Todas as colunas de um índice composto devem pertencer à mesma tabela. Como no SQL
Server 2005 podemos criar índices em views (consultas), e uma view pode retornar dados de
várias colunas de diferentes tabelas; ao criarmos um índice composto em uma view, as colunas
que formam o índice composto devem pertencer à mesma tabela.
3. Em termos de desempenho, devemos definir a coluna que possui valores mais diferenciados
em primeiro lugar. Por exemplo, no índice EnderecoIndex, do qual fazem parte as colunas:
Address, City e Region, a coluna que apresenta a maior variação, com certeza, é a coluna
Address (existem muitos endereços em uma cidade), depois a coluna City (existem muitas
cidades em uma região) e por último a coluna Region. Ao definirmos o índice, devemos passar
as colunas nesta mesma ordem, pois isso auxilia no desempenho da consulta.
4. Desta maneira podemos concluir que a ordem das colunas importa no desempenho, e além
disso os dois comandos a seguir definem índices diferentes. Observe que a única diferença
entre os dois é a ordem das colunas:

WITH IGNORE_DUP_KEY
e
ON Customers (City, Address, Region)
WITH IGNORE_DUP_KEY
5. Ao construirmos uma consulta, a cláusula WHERE deve fazer referência a todas as colunas do
índice composto, caso contrário o índice não será utilizado.
Seguindo a nossa metodologia de utilização de exemplos, vamos criar um índice utilizando a janela de
execução de comandos T-SQL. O índice terá as seguintes características:
♦ Tabela Customers do Banco de Dados Northwind.
♦ Nome: CountryIndex.
♦ Colunas: Country.
♦ Permitir valores duplicados.
Exemplo:
Criando o índice CountryIndex com a janela de execução de comandos T-SQL:
1. Abra o SQL Server Management Studio, navegue até o banco de dados Northwind, clique com
o botão direito do mouse no banco de dados e, no menu de opções que é exibido, clique em
New Query.
2. Pronto, será aberta a janela de execução de comandos T-SQL.
3. Execute o comando USE Northwind.
4. Digite e execute o seguinte comando:
CREATE INDEX
CountryIndex ON Customers (Country)
Deverá ser emitida a seguinte mensagem:

NOTA
Para maiores informações sobre os tipos de índices e a criação de índices consulte o Capítulo 4.
CRIAÇÃO DE VIEWS NO BANCO DE DADOS – O COMANDO CREATE VIEW

Para criar uma view em um Banco de Dados, utilizamos o comando CREATE VIEW. A seguir, a sintaxe
para este comando com alguns comentários.
CREATE VIEW [ < database_name > . ] [ < owner > . ] view_name [ ( column [ ,...n ] ) ]
[ WITH < view_attribute > [ ,...n ] ]
AS
select_statement
WITH CHECK OPTION ]
Simplificando a sintaxe para o comando CREATE VIEW, teríamos o seguinte:
CREATE VIEW Nome_da_View

AS
Comando SQL
Por exemplo, para criar uma view chamada Pedidos_Teste, que retorna os campos OrderID,
OrderDate, ShipCountry e ShipCity, da tabela Orders do Banco de Dados Northwind, utilizamos o
seguinte comando:
USE Northwind
GO
CREATE VIEW Pedidos_Teste
AS
SELECT OrderID, OrderDate, ShipCountry
FROM Orders
NOTA
É importante que você coloque o comando GO, antes do comando CREATE VIEW, caso o comando CREATE VIEW não seja o primeiro comando.
Se não utilizarmos GO, será emitida a seguinte mensagem de erro:

‘CREATE VIEW’ must be the first statement in a query batch.
O mais importante para a criação de views é conhecer a linguagem T-SQL. Uma view nada mais é do
que um comando T-SQL gravado em um Banco de Dados. Uma vez gravada a view, podemos executá-
la quantas vezes forem necessárias. Por exemplo, para executar a view Pedidos_Teste, utilizamos o
seguinte comando:
SELECT * FROM Pedidos_Teste

NOTA
Quando criamos uma view, o que é gravado no Banco de Dados, é apenas o comando T-SQL, além de informações sobre permissões de
acesso. Os dados que a view retorna são obtidos a partir das tabelas do Banco de Dados, toda vez que a view for executada.
Informações sobre as views são armazenadas nas tabelas sysobjects. Informações sobre as colunas
referenciadas em cada view são armazenadas na tabela syscolumns. Informações sobre os objetos das
quais a view depende são armazenadas na tabela sysdepends. O texto que define o comando T-SQL da
view é armazenado na tabela syscomments.
Podemos fazer com que o texto da view, que é armazenado na tabela syscomments, seja criptografado.
Isto impede que o código da view seja acessado, simplesmente através de um SELECT na tabela
syscomments. Ou melhor, o código até que pode ser acessado, só que estará criptografado, o que
impede que seja lido, a menos que a criptografia seja quebrada.
A seguir, um exemplo de criação de uma view com a utilização da opção WITH ENCRYPTION:
CREATE VIEW Pedidos_Criptografada

WITH ENCRYPTION
AS
SELECT OrderID, OrderDate, ShipCountry, ShipCity
FROM Orders
WHERE ShipCountry = ‘Brazil’
Vamos a um exemplo: Criar uma view chamada Média_Vendas_por_Ano. Esta view deve exibir um
registro para cada ano em que existem pedidos e o valor médio de vendas para cada ano.
O detalhe nesta view é que temos que utilizar dados da tabela Orders e da tabela Order Details. Os
cálculos do total por pedido, os quais vão possibilitar o cálculo da média anual, são realizados a partir
dos campos da tabela Order Details. Além disso, teremos que utilizar a função Year, para extrair apenas
o ano do campo OrderDate. Depois, agrupamos o campo ano e utilizamos a função AVG na coluna que
calcula o valor das vendas. Ao mesmo tempo que aprendemos a criar a view também reforçamos a
utilização das principais cláusulas do comando SELECT.
Para criar esta view, utilize o seguinte comando:
USE Northwind
GO
CREATE VIEW Média_Vendas_por_Ano
AS
SELECT YEAR(OrderDate) AS [Ano do Pedido],
AVG(([Quantity] * [UnitPrice])* (1 -[Discount])) AS [Média Anual]
FROM [Orders]
INNER JOIN
[Order Details]
ON
[Orders].[OrderID] = [Order Details].[OrderID]
GROUP BY YEAR(OrderDate)
Agora vamos testar se a view Média_Vendas_por_Ano está retornando os resultados desejados.

NOTA
Para maiores informações sobre a criação de views, consulte o Capítulo 9.
CRIAÇÃO DE STORED PROCEDURES NO BANCO DE DADOS –

O COMANDO CREATE PROCEDURE
Para criar um stored procedure em um Banco de Dados, utilizamos o comando CREATE PROCEDURE.
A seguir a sintaxe para este comando com alguns comentários.
CREATE PROCEDURE nome_do_stored_procedure

[
{@nome_parâmetro1 tipo_de_dados_do_parâmetro} [=valor_default] [OUTPUT]
]
[,..n]
AS
comando 1
comando 2
...
comando n
Vamos a um exemplo simples.
Exemplo: Criar e testar um store procedure que retorna todos os registros da tabela orders, em que o
campo ShipCity é igual a London. Gravar o stored procedure com o nome usp_PedidosLondon. O
stored procedure será criado no Banco de Dados Northwind.
NOTA
Utilizei o prefixo usp_ para indicar user stored procedure. Porém, esta não é uma convenção obrigatória, apenas uma recomendação.
Para criar o stored procedure usp_PedidosLondon, utilize o seguinte comando:
USE Northwind
GO
CREATE PROCEDURE usp_PedidosLondon
AS
WHERE ShipCity = ‘London’
Agora podemos executar o stored procedure sempre que for necessário. Para executá-lo, execute o
seguinte comando:
exec usp_PedidosLondon
O stored procedure é executado, os comandos que compõem o Stored procedure são executados e os
resultados são retornados (somente os pedidos em que o campo ShipCity é igual a London).
Quando criamos um stored procedure, o SQL Server 2005 grava informações em uma série de tabelas
no próprio Banco de Dados onde o stored procedure é criado. O nome do stored procedure é armazenado
na tabela sysobjects. Os comandos do stored procedure são armazenados na tabela syscomments.
Podemos fazer com que estes comandos sejam criptografados. Para isso utilizamos a opção WITH
ENCRYPTION. No exemplo a seguir, temos um comando que cria um stored procedure chamado
usp_Customers e criptografa os comandos do stored procedure, armazenados na tabela syscomments:
USE Northwind
GO
CREATE PROCEDURE usp_Customers
WITH ENCRYPTION
AS
CRIANDO STORED PROCEDURES

COM PARÂMETROS DE ENTRADA
A utilização de parâmetros de entrada permite a criação de stored procedures mais flexíveis. Vamos
considerar o stored procedure usp_PedidosLondon, criado no exemplo anterior. Da maneira como este
stored procedure foi criado, sem parâmetros de entrada, o critério de pesquisa será sempre o mesmo:
ShipCity = ‘London’.
Podemos criar um stored procedure mais genérico, o qual aceita o nome da cidade como parâmetro e
retorna todos os pedidos para a cidade passada como parâmetro.
Para criar um stored procedure, com um ou mais parâmetros de entrada, utilizamos a seguinte sintaxe:
CREATE PROCEDURE nome_StorProc

@nome_parâmetro tipo_parâmetro
AS
comando 1
comando 2
...
comando n
Caso tenhamos mais do que um parâmetro de entrada, devemos separá-los por vírgula, conforme
indicado a seguir:
CREATE PROCEDURE
...
@nome_parâmetron tipo_parâmetron
AS
comando 1
comando 2
...
comando n
Para utilizar o parâmetro nos comandos do Store Procedure, basta utilizar @nome_do_parâmetro.
Exemplo 1: Criar um stored procedure chamado usp_Pedidos_Cidade. Este será criado no Banco de
Dados Northwind e deve aceitar um parâmetro chamado Cidade, o qual é do tipo nvarchar(15). O
stored procedure usará o valor passado neste parâmetro como critério de pesquisa, para retornar apenas
os pedidos para a cidade passada como parâmetro.
Para criar o stored procedure usp_Pedidos_Cidade, utilize o seguinte comando:
USE Northwind
GO
CREATE PROCEDURE usp_Pedidos_Cidade
@cidade nvarchar(15)
AS
WHERE ShipCity = @cidade
Para executar o stored procedure usp_Pedidos_Cidade, passando Campinas como parâmetro, utilizamos
o seguinte comando:
Execute usp_Pedidos_Cidade “Campinas”
Serão retornados apenas os pedidos para a cidade de Campinas.
Para executar o stored procedure usp_Pedidos_Cidade, passando Bruxelles como parâmetro, utilizamos
o seguinte comando:
Execute usp_Pedidos_Cidade “Bruxelles”
Serão retornados apenas os pedidos para a cidade de Bruxelles e assim por diante, ou seja, cada vez que
executarmos o stored procedure, podemos passar um parâmetro diferente, o que o torna bem mais flexível.
Vamos a mais um exemplo, onde temos dois parâmetros de entrada.
Exemplo 2: Criar um stored procedure chamado usp_Ped_Cid_País. Este será criado no Banco de Dados
Northwind e deve aceitar dois parâmetros: um chamado cidade, o qual é do tipo nvarchar(15), e outro
chamado país, o qual é do tipo nvarchar(15). O stored procedure usará os valores passados nestes
parâmetros como critério de pesquisa, para retornar apenas os pedidos para a cidade e país de destino
passados como parâmetros.
Para criar o stored procedure usp_Ped_Cid_País, utilize o seguinte comando:
USE Northwind
GO
CREATE PROCEDURE usp_Ped_Cid_País
@cidade nvarchar(15),
@país nvarchar(15)
AS
WHERE (ShipCity = @cidade) and (ShipCountry=@país)
Para executar o stored procedure usp_Ped_Cid_País, passando como parâmetros “Buenos Aires” como valor
para o parâmetro cidade, e “Argentina”, como valor para o parâmetro país, utilizamos o seguinte comando:
Exec usp_Ped_Cid_País “Buenos Aires”, “Argentina”
<body tePara executar o stored procedure usp_Ped_Cid_País, passando como parâmetros “Sao
Paulo”, como valor para o parâmetro cidade, e “Alemanha” como valor para o parâmetro país,
Exec usp_Ped_Cid_País “Sao Paulo”, “Alemanha”
Evidentemente que esta última execução não irá retornar nenhum registro, apenas a seguinte mensagem
será exibida:
(0 row(s) affected)
Se passarmos apenas o parâmetro cidade, ignorando o parâmetro país, conforme indicado no seguinte
comando:
Execute usp_Ped_Cid_País “Sao Paulo”
Server: Msg 201, Level 16, State 3, Procedure usp_Ped_Cid_País, Line 0

Procedure ‘usp_Ped_Cid_País’ expects parameter ‘@país’, which was not supplied.
Observe que a mensagem informa que é esperado um parâmetro chamado país (@país) e que este não
foi informado.
Se passarmos parâmetros a mais, conforme indicado no seguinte comando:
Execute usp_Ped_Cid_País “Sao Paulo”, “Alemanha”, “12/06/2001”
Server: Msg 8144, Level 16, State 2, Procedure usp_Ped_Cid_País, Line 0

Procedure or function usp_Ped_Cid_País has too many arguments specified.
NOTA
Para maiores informações sobre a criação e o conceito de stored procedures, consulte o Capítulo 10.
CRIAÇÃO DE TRIGGERS – O COMANDO CREATE TRIGGER

Para criar uma trigger em uma tabela de um Banco de Dados, utilizamos o comando CREATE TRIG-
GER. A seguir a sintaxe para este comando com alguns comentários.
CREATE TRIGGER nome_da_trigger

ON {tabela ou view}
[WITH ENCRYPTION]
{FOR | AFTER | INSTEAD OF}
{[DELETE] [,] [INSERT] [,] [UPDATE]}
[WITH APPEND]
[NOT FOR REPLICATION]
AS
comando 1
comando 2
comando 3
...
comando n
Com este comando podemos criar triggers associadas com qualquer dos comandos básicos de inserção,
alteração ou exclusão de dados – DELTE, INSERT ou UPDATE – e também triggers do tipo INSTEAD OF
e AFTER. Uma trigger pode ser associada com mais de uma opção, por exemplo, podemos criar uma
trigger que dispara em resposta a um comando INSERT e também a um comando UPDATE.
Nos comandos que definem a trigger (comando 1, ..., comando n), podemos incluir a maioria dos
comandos, inclusive as estruturas IF...ELSE e WHILE. Não são permitidos os seguintes comandos:
♦ ALTER DATABASE
♦ CREATE DATABASE
♦ DISK INIT
♦ DISK RESIZE
♦ DROP DATABASE
♦ LOAD DATABASE
♦ LOAD LOG
♦ RECONFIGURE
♦ RESTORE DATABASE
♦ RESTORE LOG
Vejamos um exemplo prático.
Exemplo: Vamos criar uma trigger que evita que sejam inseridos novos clientes na tabela Customers
do Banco de Dados Northwind, em que o campo Country seja igual a China ou Indonésia. Será criada
para a ação INSERT. Vamos chamá-la de tg_ExcluiChinaIndonésia. Esta trigger verifica se o campo
Country é igual a China ou Indonésia. Em caso afirmativo, um ROLLBACK será chamado para cancelar
a inserção do registro, caso contrário a transação será concluída.
Para criar a trigger tg_ExcluiChinaIndonésia, execute o seguinte comando:
USE Northwind
GO
CREATE TRIGGER tg_ExcluiChinaIndonésia
ON Customers
FOR INSERT
AS
IF EXISTS(SELECT * FROM inserted WHERE Country IN (‘China’,‘Indonésia’))
PRINT ‘PAÍS PROIBIDO !!!’
ELSE
NOTA
Observe a utilização da função EXISTS (comando SQL). Esta função retorna verdadeiro, caso o comando SQL retorne algum registro e falso,
caso contrário.
USE Northwind
GO
INSERT INTO [Customers]
( [CustomerID],[CompanyName],[ContactName],[ContactTitle],
[Address],[City],[Region],[PostalCode], [Country], [Phone], [Fax])
VALUES
(‘xxxxx’,‘Empresa ABC Ltda.’,‘José da Silva’,‘Gerente’,
PAÍS PROIBIDO !!!

(1 row(s) affected)
Mas, ao invés da mensagem “PAÍS PROIBIDO !!!’, nós queremos que a inserção do registro seja cancelada
caso o país seja China ou Indonésia. Para isso vamos alterar a trigger tg_ExcluiChinaIndonésia. Ao
invés da mensagem, vamos dar um ROLLBACK. Como a operação INSERT e a trigger ocorrem no
contexto de uma transação, conforme descrito no Capítulo 10, ao cancelarmos a transação, vamos
cancelar o restante de execução da trigger e também o comando INSERT.
Para alterar uma trigger, utilizamos o comando ALTER TRIGGER. A sintaxe básica para este comando é
a seguinte:
USE Northwind
GO
ALTER TRIGGER nome_trigger
ON nome_tabela
FOR { INSERT | UPDATE | DELETE }
AS
comando 1
comando 2
comando 3
...
comando n
Para alterar a trigger tg_ExcluiChinaIndonésia, utilizamos o seguinte comando:
USE Northwind
GO
ALTER TRIGGER tg_ExcluiChinaIndonésia
ON Customers
FOR INSERT
AS
IF EXISTS(SELECT * FROM inserted WHERE Country IN (‘China’,’Indonésia’))
BEGIN
PRINT ‘INSERÇÃO DO REGISTRO CANCELADA !!!!!!’
ROLLBACK
END
ELSE
Agora vamos tentar inserir um cliente em que o campo Country é igual a Indonésia. Vamos verificar se a trigger
foi disparada e depois daremos um SELECT para verificar se a inserção do registro foi realmente cancelada.
Para inserir um registro em que o país é Indonésia, execute o seguinte comando:
USE Northwind
GO
INSERT INTO [Customers]
([CustomerID],[CompanyName],[ContactName],[ContactTitle],
[Address],[City],[Region],[PostalCode], [Country], [Phone], [Fax])
VALUES
(‘ABC12’,‘Empresa 123 Ltda.’,‘Para Pedro’,‘Gerente’,
‘Rua Riachuelo – 444’,‘Porto Alegre’,‘Centro’,‘97051-230’,‘Indonésia’,‘220-
4444’,‘223-1344’)
Vamos conferir se o comando INSERT realmente foi cancelado.
Para verificar se o registro para a Indonésia não foi inserido, execute o seguinte comando:
USE Northwind
GO
WHERE CustomerID=‘ABC12’
O resultado será:
(0 row(s) affected)
Isto comprova que o comando INSERT foi cancelado.
Veja que agora temos uma trigger, que dispara sempre que tentarmos inserir um registro na tabela
Customers. Esta trigger verifica se o registro que está sendo inserido possui um valor igual a China ou
Indonésia, no campo Country. Caso o registro possua um destes valores no campo Country, a inserção
será cancelada, através da utilização de um comando ROLLBACK. O comando ROLLBACK cancela a
execução da transação, da qual fazem parte a trigger e o comando INSERT que disparou a trigger.
Como o comando INSERT faz parte da transação que está sendo cancelada, o comando INSERT também
é cancelado e a inserção do registro é cancelada.
NOTA
Para detalhes teóricos e exemplos práticos sobre triggers, consulte o Capítulo 10.
COMANDOS PARA GERENCIAR “LOGINS” NO SQL SERVER 2005

Na Tabela A.7 temos alguns comandos para criação de logins.
Tabela A.7 Comandos para adicionar logins.
Comando Utilizado
sp_grantlogin Para adicionar logins do domínio do Windows 2000. Podemos adicionar usuários ou grupos.
Utilizamos o formato DOMÍNIO\nome.
sp_addlogin Para adicionar novos logins do SQL Server 2005, para o caso de estarmos utilizando o modo
de segurança SQL Server and Windows.
Sintaxe para o comando sp_grantlogin:
exec sp_grantlogin ‘DOMÍNIO\nome’
ou
exec sp_grantlogin [DOMÍNIO\nome]
Por exemplo, para adicionarmos o usuário chico, do domínio GROZA, utilizamos o seguinte comando:
exec sp_grantlogin ‘GROZA\chico’
ou
exec sp_grantlogin [GROZA\chico]
Algumas observações sobre o comando sp_grantlogin:
♦ sp_grantlogin não pode ser executado como parte de uma transação definida pelo usuário ou
(securityadmin) têm permissão, por padrão, para utilizar o comando sp_grantlogin.
Podemos remover a permissão de login para um usuário ou grupo do domínio do Windows, utilizando
o comando sp_revokelogin.
Sintaxe para o comando sp_revokelogin:
exec sp_revokelogin ‘DOMÍNIO\nome’
ou
exec sp_revokelogin [DOMÍNIO\nome]
Por exemplo, para removermos a permissão de login do usuário chico, do domínio GROZA, adicionado
anteriormente, utilizamos o seguinte comando:
exec sp_revokelogin ‘GROZA\chico’
ou
exec sp_revokelogin [GROZA\chico]
Algumas observações sobre o comando sp_revokelogin:
♦ Ao removermos a permissão de login, o usuário não poderá mais conectar-se com a respectiva
instância do servidor SQL, a menos que um dos grupos aos quais o usuário pertença tenha
permissão de login. Lembre que o usuário sempre herda as permissões do grupo. Se o usuário
pertencer a vários grupos que possuem permissão de login e a um único grupo que tem o login
explicitamente negado, o usuário não poderá conectar-se com o servidor SQL. Lembre que
negar (deny) tem precedência sobre permitir.
(securityadmin) têm permissão, por padrão, para utilizar o comando sp_revokelogin.
Podemos negar, explicitamente, a permissão de login para um usuário ou grupo do domínio do Win-
dows, utilizando o comando sp_denylogin. Neste caso, a conta do usuário ou grupo continua na lista
de logins, porém com o direito de conexão com o servidor SQL, explicitamente negado.
Sintaxe para o comando sp_denylogin:

exec sp_denylogin ‘DOMÍNIO\nome’
ou
exec sp_denylogin [DOMÍNIO\nome]
Por exemplo, para negarmos, explicitamente, a permissão de login do usuário chico, do domínio
GROZA, utilizamos o seguinte comando:
exec sp_denylogin ‘GROZA\chico’
ou
exec sp_denylogin [GROZA\chico]
Algumas observações sobre o comando sp_denylogin:
♦ sp_denylogin não pode ser executado como parte de uma transação definida pelo usuário ou

(securityadmin) têm permissão, por padrão, para utilizar o comando sp_denylogin.
♦ Para permitir que o usuário volte a se conectar, removendo o efeito de sp_denylogin, podemos
utilizar sp_grantlogin.
Agora vamos tratar dos comandos para adicionar e remover logins do próprio SQL Server, para o caso
de trabalharmos no modo de segurança misto.
Para adicionar um login do SQL Server 2005, podemos utilizar o comando sp_addlogin.
Sintaxe para o comando sp_addlogin, conforme descrito no Books OnLine:
sp_addlogin [ @loginame = ] ‘login’

[ , [ @passwd = ] ‘password’ ]
[ , [ @defdb = ] ‘database’ ]
[ , [ @deflanguage = ] ‘language’ ]
[ , [ @sid = ] sid ]
, [ @encryptopt = ] ‘encryption_option’ ]
Observe que podemos definir uma série de opções, tais como a senha (passwd), o Banco de Dados associado
com o login (defdb), a linguagem associada com o login (deflanguage), um identificador de segurança único
(sid) e a definição se a senha deve ou não ser criptografada ao ser armazenada no servidor SQL Server
(encryptopt). Normalmente não especificamos o parâmetro sid, e com isso o identificador único de segurança
será gerado pelo próprio SQL Server 2005, no momento da criação do login. O sid é um número do tipo
varbinary(16). Os valores possíveis para o parâmetro encryptopt estão descritos na Tabela A.8.
Tabela A.8 Valores do parâmetro encryptopt.
Valor Descrição
NULL A senha será criptografada. Este é o valor padrão.

skip_encryption A senha já está criptografada. O valor será gravado sem a necessidade de criptografá-lo novamente.
skip_encryption_old A senha deve ser criptografada de acordo com versões anteriores do SQL Server. O valor será gravado
sem criptografá-lo novamente. Esta opção normalmente é utilizada durante a fase de migração de
versões anteriores.
Por exemplo, para adicionarmos o usuário flavio1, com senha em branco e associado ao Banco de
Dados master, que é o Banco de Dados padrão quando nenhum outro for definido, utilizamos o
seguinte comando:
exec sp_addlogin ‘flavio1’
Agora vamos adicionar um usuário chamado luciano, com uma senha nene e associado ao Banco de
Dados Clientes:
exec sp_addlogin ‘luciano’, ‘nene’, ‘Clientes’
Algumas observações sobre o comando sp_addlogin:
♦ sp_addlogin não pode ser executado como parte de uma transação definida pelo usuário ou
(securityadmin) têm permissão, por padrão, para utilizar o comando sp_addlogin.
Em nosso exemplo, descrito na Tabela A.8, utilizaremos o comando sp_addlogin, para adicionar os
usuários: sqluser1 e sqluser2.
Para excluirmos um login do SQL Server, podemos utilizar o comando sp_droplogin.
Sintaxe para o comando sp_droplogin:
exec sp_droplogin ‘nome’
Por exemplo, para excluirmos o usuário luciano, anteriormente adicionado, podemos utilizar o seguinte comando:
exec sp_droplogin. ‘luciano’
Algumas observações sobre o comando sp_droplogin.:

(securityadmin) têm permissão, por padrão, para utilizar o comando sp_droplogin.
♦ Caso o login, que está sendo excluído, esteja adicionado como usuário de algum Banco de
Dados, o login não poderá ser excluído. Primeiro, precisamos remover o login da lista de usuários,
utilizando o comando sp_drpouser, o qual aprenderemos a utilizar mais adiante.
♦ Os seguintes logins não poderão ser excluídos:
♦ ____________O login de administração sa.
♦ ____________Um login que seja dono de um job no Banco de Dados msdb.
♦ ____________Um login que esteja atualmente conectado com o servidor SQL Server.
♦ O comando sp_droplogin deverá checar todos os Bancos de Dados para verificar se o login que
está sendo excluído não está adicionado à lista de usuários com permissão de acesso ao Banco
de Dados. Por isso, para que este comando possa ser executado com sucesso, as seguintes
condições devem ser atendidas:
♦ ____________O usuário logado, que está executando sp_droplogin, deve ter permissão de acesso
aos Bancos de Dados ou;
♦ ____________A conta guest deve estar habilitada a acessar o Banco de Dados.
Ao criarmos novos logins no SQL Server, devemos levar os seguintes fatos em consideração:
♦ Um login não pode conter o caracter barra invertida. Não confundir com a barra invertida
utilizada para separar o nome do domínio do nome do usuário.
♦ Logins e senhas podem conter até 128 caracteres, incluindo letras, símbolos e dígitos.
♦ Não podemos adicionar um login com o mesmo nome de um login reservado, como por exemplo
sa ou public.
♦ O nome de login não pode conter o valor NULL ou ser uma string vazia ‘ ‘.
Exemplo:
O comando a seguir cria uma série de logins do próprio SQL Server 2005 e também garante direito de
login a usuários do domínio GROZA, do Windows 2000.
— Utilizo sp_grantlogin para adicionar

— usuário do domínio do Windows 2000
exec sp_grantlogin ‘GROZA\jose’

exec sp_grantlogin ‘GROZA\maria’
exec sp_grantlogin ‘GROZA\pedro’
exec sp_grantlogin ‘GROZA\paulo’
exec sp_grantlogin ‘GROZA\jovina’
exec sp_grantlogin ‘GROZA\grupo1’
exec sp_grantlogin ‘GROZA\grupo2’
— Agora utilizo sp_addlogin para adicionar

— logins do SQL Server 2005
exec sp_addlogin ‘sqluser1’, ‘senha123’, ‘pubs’

exec sp_addlogin ‘sqluser2’, ‘senha123’, ‘pubs’
Pressione Ctrl+E para executar o comando.
Agora vamos alterar o Banco de Dados padrão para os usuários do domínio GROZA. Para alterar o
Banco de Dados padrão de um usuário, utilizamos o comando sp_defautldb, com a seguinte sintaxe:
exec sp_defaultdb ‘usuário’, ‘Banco de Dados’.
Para alterar o Banco de Dados padrão para os usuários do domínio GROZA, digite os seguintes comandos:
exec sp_defaultdb ‘GROZA\jose’, ‘pubs’

exec sp_defaultdb ‘GROZA\maria’, ‘pubs’
exec sp_defaultdb ‘GROZA\pedro’, ‘pubs’
exec sp_defaultdb ‘GROZA\paulo’, ‘pubs’
exec sp_defaultdb ‘GROZA\jovina’, ‘pubs’
Pressione Ctrl+E para executar o comando.
Pronto, os logins foram adicionados e o Banco de Dados padrão,s alterado para pubs.
COMANDOS PARA A CRIAÇÃO DE ROLES

Para adicionar uma nova role a um Banco de Dados, utilizamos o comando sp_addrole.
Sintaxe para o comando sp_addrole:
exec sp_addrole ‘nome’, ‘dono da role’
Por exemplo, para adicionar uma Role chamada teste, cujo dono seja o usuário chico, utilize o seguinte comando:
exec sp_addrole ‘teste’, ‘chico’
NOTA
Se não for especificado o parâmetro dono, o dono da role será o usuário dbo – database owner.
Algumas observações sobre o comando sp_addrole:
♦ O nome de uma role pode conter até 128 caracteres, porém não pode conter a barra invertida
e nem pode ser um valor nulo (NULL) ou uma string vazia – ‘ ‘.
♦ Somente membros das roles sysadmin e das roles db_securityadmin e db_owner têm permissão
para utilizar o comando sp_addrole.
♦ Não podemos criar novas roles em nível de servidor, somente de Banco de Dados.
Para excluir uma role, podemos utilizar o comando sp_droprole.

Sintaxe para o comando sp_droprole:
exec sp_droprole ‘nome’
Por exemplo, para excluir a role chamada teste, criada anteriormente, utilize o seguinte comando:
exec sp_droprole ‘teste’
Algumas observações sobre o comando sp_droprole:
♦ Somente membros das roles sysadmin e das roles db_securityadmin e db_owner têm permissão
para utilizar o comando sp_addrole.
♦ Não podemos excluir uma role que possui membros. Antes temos que excluir todos os membros
da role, para depois poder excluí-la. Aprenderemos a adicionar e a excluir membros de uma
role, no próximo item.
♦ O comando sp_droprole não pode ser executado no contexto de uma transação definida pelo usuário.
♦ Não podemos excluir roles predefinidas – Fixed Server Roles e Fixed Database Roles.
Também podemos utilizar o comando sp_helprole para obter informações sobre as diversas roles em
um Banco de Dados. Considere o exemplo a seguir:
use pubs
exec sp_helprole
Exemplo: Utilizando comandos T-SQL, crie as roles indicadas na Tabela A.9.
Tabela A.9 Roles a serem criadas com o Query Analyzer.
Nome da role Banco de Dados/Instância.

Para criar as roles da Tabela A.9, faça o seguinte:
1. Execute os seguintes comandos:
— Alterna para o Banco de Dados Exemplo1

use exemplo1
|— Utilizo sp_addrole para criar as novas roles.

2. Pressione Ctrl+E para executar estes comandos.
As roles role1, role2 e role3 são adicionadas ao Banco de Dados Exemplo1, da instância
SERVIDOR\SRVINST01 e a seguinte mensagem é exibida:
New role added.
New role added.
New role added.
CONCLUSÃO
Neste anexo, apresentamos uma consolidação dos principais comandos para execução de consultas e
manipulação de objetos em um Banco de Dados do SQL Server 2005.
Para uma referência completa de todos os comandos e funções da linguagem T-SQL, acesse o item
“Transact-SQL Reference” no Books OnLine.
A seguir alguns links com informações úteis sobre o SQL Server 2005, na Internet:
♦ http://www.microsoft.com/sql
♦ http://support.microsoft.com/sql
♦ http://www.sqlmag.com
♦ http://msdn.microsoft.com/sqlserver
♦ http://databases.about.com/compute/databases/cs/sqlserver/index.htm
♦ http://www.allexperts.com/software/mssql.shtml
♦ http://www.dblinks.net/Microsoft_Sql_Server/
♦ http://www.sqlsecurity.com
♦ http://www.sqlteam.com
♦ http://www.sql-server-performance.com/
♦ http://sqlserver.superexpert.com/
♦ http://www.sqlwire.com/links.asp
Índice
Remissivo
.NET FRAMEWORK CLASS LIBRARY, 797 Criando conexões, 825 Conceito, 45
Conceito, 797 Data Adapter, 832 Dados, 46
Estrutura, 799 DataSet, 834 Exemplo, 45
Introdução, 797 DataView, 836 Lógica, 46
O que é, 797 Estrutura, 786 Problemas, 46
Principais Classes, 800 Exemplo prático, 826 Vantagens, 46
.NET, 762 Introdução, 824 Aplicações em 4 camadas, 56
.NET FRAMEWORK CLASS Principais classes, 824 Apresentação, 47
LIBRARY, 766 Versus ADO, 822 Cliente, 46
CLR, 764 AdventureWorks, 118 Conceito, 46
Conceito, 762 Agendamento de Tarefas, 269 Dados, 47
Introdução, 762 Conceito, 269 Exemplo, 47
Web Services, 762 Criação de Jobs, 271 Lógica, 47
Definir agendamento, 275 Application Center 2000, 784
Executar o Job, 277 Armazenamento básico, 121
A Histórico de execução, 278 Boot partition, 123
Access, 709 Introdução, 269 Definição, 122
Acessar dados do SQL Server, 722 Job, 269 Partição estendida, 122
Anexar tabelas, 731 Vários passos, 274 Partição primária, 122
Banco de dados, 709 Agendamento do backup, 250 Partições, 122
Consultas, 711 Tarefa agendada, 253 Stripe set, 124
Consultas usando dados do SQL Agentes de Replicação, 493 System partition, 123
Server, 736 Criados pela replicação, 493 Volume set, 124
Estrutura do banco, 709 Alertas, 433 Armazenamento dinâmico, 121
Exemplo prático, 736 Conceito, 433 Conceito, 125
Fonte ODBC, 723 Exemplo prático, 433 Definição, 122
Formulários, 713 Introdução, 433 RAID-0, 125
Importar dados do SQL Server, 722 ALTER DATABASE, 151 RAID-5, 125
Macros, 720 Exemplo prático, 151 Volume espelhado, 125
Módulos, 721 Sintaxe, 151 Volume expandido, 125
Páginas, 716 ALTER INDEX, 378 Volume simples, 125
Relatórios, 715 Exemplos, 378 Arquitetura de aplicações, 43
Tabelas, 710 Sintaxe, 378 ASP, 658
Acessar dados via Browser, 746 ALTER TABLE, 183 Como funciona, 659
Configurações necessárias, 746 Exemplo prático, 184 Conceito, 658
Configurando o IIS, 746 Opções, 184 Introdução, 658
Exemplo prático, 752 Sintaxe, 184 Primeiro exemplo, 658
Acesso HTTP SOAP Nativo, 49 Alteração de tabelas, 182 ASP.NET, 812
ADD CONSTRAINT, 536 Comando ALTER TABLE, 183 Conexão com o SQL Server, 814
ADO, 642 Excluir campos, 183 Introdução, 812
Command, 656 Exemplo prático, 182 Novidades do, 812
Como funciona, 653 Alteração do banco de dados, 150 O que é, 812
Conceito, 653 Comando ALTER DATABASE, 151 Primeiro exemplo, 814
Connection, 656 Alterar tabela, 170 Suporte a múltiplas linguagens, 813
Definição, 653 Analysis Services, 84 Assemblies, 792
Estrutura, 653 Aplicações em 2 camadas, 44 Componentes, 794
Modelo de objetos, 655 Apresentação, 44 Conceito, 792
O que é, 653 Conceito, 44 Estrutura dos, 794
Record, 656 Exemplo, 44 Funções dos, 793
RecordSet, 656 Lógica do negócio, 44 Introdução, 792
Stream, 656 Problemas, 44 Manifesto, 795
ADO.NET, 785 TCO, 44 O que são, 792
Conceito, 785 Aplicações em 3 camadas, 45 Atomicidade, 225
Conectando o SQL Server, 826 Apresentação, 46 ATTACH_REBUILD_LOG, 51
ÍNDICE REMISSIVO
B Exemplo prático, 130

Roles, 121
Integração, 789
Introdução, 787
B2B, 38 Stored Procedures, 119 JIT, 791
Exemplo, 41 Tabelas, 118 Processo de execução, 789
B2C, 38 Views, 119 Vantagens, 788
BACKUP DATABASE, 254 Bancos de dados da instância, 116 Clustered Index, 200
Exemplo prático, 254 AdventureWorks, 118 Conceito, 200
Opções, 256 database msdb, 117 Considerações, 203
Sintaxe, 254 master database, 117 CREATE INDEX, 209
Backup devices, 236 model database, 117 Criação de, 206
Comando System databases, 117 Estrutura, 201
Comando sp_addumpdevice, 241 tempdb database, 118 Funcionamento, 202
Conceito, 236 Bancos de Dados Relacionais, 6 Introdução, 200
Criando um, 238 Componentes de, 6 Leaf pages, 203
Devices Físicos, 237 Conceito, 6 Nom-leaf pages, 202
Devices lógicos, 237 Elementos básicos, 6 Colunas Calculadas, 26
Excluindo, 242 Projeto do, 19 COM COM+, 772
Exemplo prático, 238 Regra número 1, 9 Comandos DBCC, 376
Introdução, 236 BizTalk Server, 784 ALTER INDEX, 378
O que são, 236 Boost SQL Server priority on Windows, DBCC CHECKDB, 386
BACKUP LOG, 256 111 DBCC CHECKTABLE, 387
Exemplo prático, 257 Business Intelligence Development DBCC DBREINDEX, 376
Opções, 257 Studio, 868 DBCC DBREPAIR, 378
Sintaxe, 256 DBCC HELP, 388
Backup, 226 DBCC INDEXDEFRAG, 379
Agendamento do backup, 250 C DBCC SHOWCONTIG, 383
Backup de arquivos de dados, 232 C#, 774 DBCC SHRINKDATABASE, 379
Backup de filegroups, 232 Apresentação, 774 DBCC SHRINKFILE, 381
Backup devices, 236 Exemplo prático, 775 DBCC UPDATEUSAGE, 382
Backup diferencial, 232 Chave Estrangeira, 14 DBCC USEROPTIONS, 385
Backup do log de transações, 232 Chave Primária, 9 Introdução, 376
Comando BACKUP DATABASE, 254 Comando ALTER TABLE, 198 O que são, 376
Comando BACKUP LOG, 256 Composta, 10 Comandos T-SQL, 139
Concurrente Database and Log Conceito, 9 ADD CONSTRAINT, 536
Backups, 231 Definição de, 195 ALTER DATABASE, 151
Considerações, 228 Dicas de escolha, 21 ALTER INDEX, 378
Estratégias de backup Exemplo prático, 195 ALTER TABLE, 183
Exemplo prático, 244 Exemplos, 10 BACKUP DATABASE, 254
Fazendo o backup, 244 Introdução, 9 BACKUP LOG, 256
Full backup, 231 Cláusula Where, 25 Conceito, 139
Full recovery model, 245 Cliente Servidor, 43 CREATE DATABASE, 143
Guia database, 244 Aplicações em 2 camadas, 44 CREATE INDEX, 209
Introdução, 226 Definição, 43 CREATE PROCEDURE, 586
Logged recovery model, 246 Introdução, 43 CREATE TABLE, 178
Métodos de Backup, 229 Modelo, 43 CREATE TRIGGUER, 607
Opções do backup, 247 CLR, 764 CREATE VIEW, 574
Recovery model, 245 Código MSIL, 765 DBCC CHECKDB, 386
restore, 232 Conceito, 764 DBCC CHECKTABLE, 387
Simple recovery model, 246 Definição, 764 DBCC DBREINDEX, 376
Tipos de backup, 231 Estrutura do, 765 DBCC DBREPAIR, 378
Banco de dados, 117 Funções, 764 DBCC HELP, 388
Criando um banco de dados, 130 Introdução, 764 DBCC INDEXDEFRAG, 379
Defaults, 121 CLR, 787 DBCC SHOWCONTIG, 383
Elementos do, 118 Como funciona, 789 DBCC SHRINKFILE, 381
Estrutura de armazenamento, 126 Conceito, 787 DBCC UPDATEUSAGE, 382
DBCC USEROPTIONS, 385 Guia Misc Server Settings, 114 Desabilitando, 547
Definição, 139 Guia Permissions, 114 DROP CONSTRAINT, 547
DENY, 357 Guia Processors, 111 Excluindo, 547
DROP CONSTRAINT, 547 Guia Security, 112 Exemplo prático, 536, 548
DROP DATABASE, 154 Parâmetros de inicialização, 100 Foreign Key Constraints, 542
DROP INDEX, 215 Running Values, 111 Habilitando, 547
DROP TABLE, 195 Startup Parameters, 110 Introdução, 534
Executar comandos, 141 Connection, 661 Not Null Constraint, 536
Exemplo prático, 141 Attributes, 661 Primary Key Constraints, 540
GRANT, 348, 356 BeginTrans, 661 Tipos de, 535
Janela de execução de comandos, 140 BeginTransComplete, 662 Unique Constraints, 542
RESTORE DATABASE, 263 Cancel, 661 Verificação de dados com, 546
RESTORE LOG, 263 Close, 661 Constraints, 534
REVOKE, 350 CommandTimeOut, 661 Check Constraints, 538
sp_addlogin, 320 CommitTrans, 661 Comando Alter Table Add
sp_addrole, 328 CommitTransComplete, 662 Contas de usuários no Windows, 298
sp_addrolemember, 341 Conceito, 661 Conceito, 298
sp_addrolemember, 341 ConnectComplete, 662 Criação de contas, 301
sp_addsrvrolemember, 340 ConnectionString, 664 Exemplo prático, 301
sp_addumpdevice, 241 ConnectionTimeOut, 661 Padrão de nomes, 300
sp_denylogin, 320 Criando conexões ODBC, 660 CREATE DATABASE, 143
SP_DETACH_DB, 929 Criar conexões OLE-DB, 662 Exemplo com Filegroups, 147
sp_dropdevice, 242 DefaultDatabase, 662 Exemplo prático, 145
sp_droplogin, 321 Disconnect, 662 Opções importantes, 147
sp_droprole, 328 Errors, 662 Sintaxe, 144
sp_dropsrvrolemember, 340 Eventos, 661 CREATE INDEX, 209
sp_grantdbaccess, 334 Execute, 661 Dicas, 211
sp_grantlogin, 318 ExecuteComplete, 662 Exemplo prático, 210
sp_help, 215 Exemplo prático, 664 Sintaxe, 209
sp_helpindex, 214 InfoMessage, 662 CREATE PROCEDURE, 586
sp_helprole, 329 IsolationLevel, 662 Exemplos, 587
SP_HELPTEXT, 602 Métodos, 661 Sintaxe, 586
SP_HELPTRIGGER, 616 Mode, 662 CREATE TABLE, 178
sp_revokedbaccess, 336 Open, 661 Exemplo prático, 178
sp_revokelogin, 319 OpenSchema, 661 Opções, 178
sp_spaceused, 214 Properties, 662 Sintaxe, 178
SP_STORED_PROCEDURES, 603 Propriedades, 661 CREATE TRIGGUER, 607
Command, 656 Provider, 662 Exemplos, 607
Commerce Server 2000, 784 RollBackTrans, 661 Sintaxe, 607
COMMON TYPE SYSTEM, 796 RollBackTransComplete, 662 CREATE VIEW, 574
Classificação de tipos, 796 State, 662 Exemplos, 575
Conceito, 796 Utilização, 661 Sintaxe, 574
Introdução, 796 Version, 662 Criação de tabelas, 163
O que é, 796 WillConnect, 662 Definindo campos, 165
Componentes, 772 WillExecute, 662 Exemplo prático, 163
Configurações Utilizadas, 37 Consistência, 225 Propriedades dos campos, 166
Configurar opções da instância, 109 Console desempenho, 407 Criar um banco de dados, 130
Configurações de memória, 110 Console SQL Computer Manager, 95 Arquivos de dados, 131
Configured values, 111 Ações disponíveis, 96 Comando CREATE DATABASE, 143
Exemplo prático, 109 Conceito, 95 Definindo configurações, 131
Guia Advanced, 114 Tela inicial, 96 Exemplo prático, 130
Guia Connections, 113 Constraint, 536 Nome do banco, 132
Guia Database settings, 113 Conceito, 534 Opções de autocrescimento, 132
Guia General, 109 Criando Constraints, 536 Usando comandos T-SQL, 143
Guia Memory, 110 Default Constraints, 537 CRM, 40
ÍNDICE REMISSIVO
Cursores, 680 Exemplo prático, 922 Caminho padrão, 70
Conceito, 680 Introdução, 921 Estrutura padrão de pastas, 69
Localização do cursor, 682 DROP CONSTRAINT, 547 Pasta padrão, 69
O que são, 680 DROP DATABASE, 154 Visão geral, 69
Tipos de cursores, 681 Exemplo prático, 154 Exchange Server 2003, 783
DROP INDEX, 215 Excluir banco de dados, 153
Exemplo prático, 215 Comando DROP DATABASE, 154
D Sintaxe, 215 Excluir tabelas, 194
Databases Snapshots, 52 DROP TABLE, 195 Comando DROP TABLE, 195
DataGrid, 841 Exemplo prático, 195 Exemplo prático, 194
Múltiplos conjuntos de dados, 843 Sintaxe, 195
Paginação, 842 DTS, 389
DB2 – IBM, 5 Como funciona, 389 F
DBCC CHECKDB, 386 Conceito, 389 Filegroups, 127
Exemplos, 386 Data Source, 393 Conceito, 127
Sintaxe, 386 Definir destino, 394 Default Filegroup, 128
DBCC CHECKTABLE, 387 Definir origem, 393 Definição, 127
Exemplos, 387 Exemplo prático, 390 Primary filegroup, 128
Sintaxe, 387 Exportando dados, 398 User-defined filegroups, 128
DBCC DBREINDEX, 376 Formatos suportados, 393 FILLFACTOR OPTION, 212
Exemplos, 377 Importar dados do Access, 390 Definição, 212
Sintaxe, 377 Introdução, 389 Importância, 212
DBCC DBREPAIR, 378 Durabilidade, 225 Valor default, 213
DBCC HELP, 388 Framework .NET, 762
Exemplos, 388 Ver .NET, 762
Sintaxe, 388 E FRAMEWORK CLASS LIBRARY, 767
DBCC INDEXDEFRAG, 379 Edições do SQL Server 2005, 55, 938 Inferno das DLLs, 779
Exemplos, 379 Comparação entre as edições, 940 Linguagens .NET, 773
Sintaxe, 379 Cuidados antes da instalação, 57 Metadata, 777
DBCC SHOWCONTIG, 383 Developers Edition, 55 O que é, 766
Exemplos, 383 Edições do Windows, 57 Web Forms, 781
Opções, 384 Enterprise Edition, 55 Windows Forms, 780
Sintaxe, 383 Express Edition, 55 Função Year, 26
DBCC SHRINKDATABASE, 379 Mobile Edition, 56 Funções definidas pelo Usuário, 49
Exemplos, 380 SQL Server 2005 Enterprise Edition, 939
Sintaxe, 380 SQL Server 2005 Express Edition, 940
DBCC SHRINKFILE, 381 SQL Server 2005 Standard Edition, 939 G
Exemplos, 381 SQL Server 2005 Workgroup GRANT, 348
Sintaxe, 381 Edition, 939 Exemplos práticos, 348
DBCC UPDATEUSAGE, 382 Edições do Windows, 57 Sintaxe, 348
Exemplos, 382 Estrutura de pastas do, 69 GRANT, 356
Sintaxe, 382 Serviços do, 80 Exemplos práticos, 356
DBCC USEROPTIONS, 385 Suporte a edições do SQL Server Sintaxe, 356
Exemplos, 385 2005, 57
Grupos de usuários no Windows, 303
Sintaxe, 383 Entidades e Atributos, 6
Adicionar usuários ao grupo, 307
Dedicated Administrator Connection, 52 Conceito, 7
Built-in groups, 310
DENY, 357 Exemplo, 7
Conceito, 303
Exemplos práticos, 357 Projeto das, 8
Criação de grupos, 306
Sintaxe, 357 Regra número 1, 9
Definições, 304
Diagrama entidades x relacionamentos, 21 Estrutura de armazenamento, 126
Grupos de distribuição, 305
Exemplo, 21 Arquivo primário, 127
Grupos de segurança, 305
Diagramas Entidades x Arquivo secundário, 127
Grupos globais, 305
Relacionamentos, 921 Log de transações, 127
Grupos locais, 305
Conceito, 921 Estrutura de pastas e arquivos, 69
Grupos universais, 305
Introdução, 303 Exemplo, 72 Conceito, 223
Utilização, 303 Instrução DELETE, 31 Conceito de transação, 224
Definição, 31 Consistência, 225
Exemplos, 31 Definição, 223
H-I Sintaxe, 31 Durabilidade, 225
Host Integration Server 2000, 784 Instrução INSERT, 31 Fazer o backup do, 249
Hot-Add Memory, 52 Definição, 31 Introdução, 223
IF…ELSE, 592 Exemplos, 31 Isolamento, 225
Exemplos, 592 Sintaxe, 31 Logins, 311
Sintaxe, 592 Instrução SELECT, 23 Comando sp_addlogin, 320
IIS, 636 Colunas Calculadas, 26 Comando sp_denylogin, 320
Criando pasta virtual, 636 Exemplos, 24 Comando sp_droplogin, 321
Formação de endereços, 640 Introdução, 23 Comando sp_grantlogin, 318
Importação e Exportação de dados, 389 Sintaxe, 24 Comando sp_revokelogin, 319
Ver DTS, 389 Instrução UPDATE, 29 Criando logins, 312
Índices, 200 Definição, 29 Deny Server access, 315
Clustered Index, 200 Exemplos, 29 Exemplo prático, 322
Conceito, 200 Sintaxe, 29 Grant Server access, 315
Criação de índices, 206 Integridade de dados, 528 Inclusão em roles, 315
Desativação de índices, 216 Implementação, 528 Logs e alertas de desempenho, 419
DROP INDEX, 215 Integridade de domínio, 533 Agendamento, 425
Excluindo, 215 Integridade de entidade, 533 Análise dos dados, 426
FILLFACTOR OPTION, 212 Integridade referencial, 533 Captura de dados, 418
Index keys, 205 Tipos de integridade, 532 Criando gráficos de desempenho, 429
Index Uniqueness, 205 Integridade referencial, 15 Exemplo prático, 422
Introdução, 200 Atualizar em cascata, 16 Exemplo prático de gráfico de
Nomclustered Index, 203 Conceito, 15 desempenho, 429
Novidades no SQL 2005, 216 Excluir em cascata, 16 Formato de gravação, 424
sp_help, 215 Exemplos, 16 Iniciando o serviço, 421
sp_helpindex, 214 Introdução, 15 Intervalo de captura, 424
sp_spaceused, 214 ISA Server 2004, 785
Isolamento, 225
Inferno das DLLs, 779
Instalação do SQL Server 2005, 60
M
Collation, 66 Merge Replication, 464
Conta para rodar, 65 J Microsoft Access, 5, 709
Cuidados antes da instalação, 57 Job, 269 Ver Access, 709
Exemplo prático, 60 JOIN, 28 Microsoft Reporting Services, 84
Instalar nova instância, 70 Exemplos, 28 MMC, 85
Instância default, 64 Exemplos práticos, 618 Abrir o MMC, 86
Instância nomeada, 64 Inner Join, 619 Conceito, 85
Modo de autenticação, 73 LEFT OUTER JOIN, 619 Criar console personalizado, 88
No Windows Server 2003, 60 Níveis de, 29 Salvar console personalizado, 90
Nomeação de instâncias, 59 Número de Joins, 618 MOBILE INFORMATION 2001
Pré-requisitos, 61 RIGHT OUTER JOIN, 619 SERVER, 785
Recomendações de segurança, 58 Modelo baseado em Componentes, 772
Recomendações preliminares, 57 Como funciona, 772
Senha da conta sa, 66 L Conceito, 772
Serviços a instalar, 64 Modelo de segurança, 281
LIKE, 27
Tela inicial, 61 Modelos de aplicações, 37
Linguagem SQL, 22
Instalar uma segunda instância, 70 Conceito, 37
Lock de Registros, 684
Exemplo prático, 70 Introdução, 37
Log de Transações, 223
Instância default, 64 Modo de autenticação, 73
Agendamento do backup, 250
Instância nomeada, 64 Monitoração de desempenho, 403
Atomicidade, 225
Criando uma, 72 Captura de dados, 418
Como funciona, 225
Conceito, 403
ÍNDICE REMISSIVO
Contador, 405 Definição, 653 Create default, 344
Contadores do SQL Server, 436 Estrutura, 653 Create function, 344
Exemplo prático, 407 O que é, 653 Create rule, 344
Gargalos, 403 OLTP, 454 Create SP, 344
Instância, 405 Online Restores, 52 Create table, 344
Introdução, 403 Opção databases, 116 Create view, 344
Limites de desempenho, 416 Operador In, 26 Criar banco de dados, 342
Logs e alertas de desempenho, 419 Oracle, 5 Estudo de caso, 351
Monitoramento do sistema de ORDER BY, 25 Excluir banco de dados, 342
discos, 412 Order by, 25, Where, 25 Exemplo prático, 345
Monitorando a RAM, 407 Colunas Calculadas, 26 Introdução, 341
Monitorando o processador, 407 Função Year, 26 Permissões de banco de dados, 349
Objeto, 405 IN, 26 Permissões de objetos de banco de
MSDTC, 83 Orientação a Objetos, 802 dados, 353
MySQL – Linux, 5 Classes, 805 Atribuindo, 353
Exemplo prático, 806 Comando DENY, 357
Herança, 806 Comando GRANT, 356
N Introdução, 802 Plano de manutenção, 367
Nomclustered Index, 203 Mensagens, 805 Alterar o plano, 374
Conceito, 203 O que é um Objeto, 803 Comandos T-SQL do, 374
Considerações, 204 Reutilização de Código, 810 Conceito, 367
Estrutura, 204 Ous, 298 Criando um, 368
Funcionamento, 204 Executar todas as tarefas, 374
Introdução, 203 Exemplo prático, 368
Nomeação de instâncias, 59 P Maintenance Plan Wizard, 368
Conceito, 59 Tarefas do, 367
Páginas ASP, 658
Dicas, 59 Primeira forma normal, 17
Conectando com o SQL Server, 666
Exemplos, 59 Conceito, 17
Conexões com o ORACLE, 670
Normalização, 16 Definição, 17
Editar registros, 704
Conceito, 16 Exemplo, 17
Excluir registros, 704
Introdução, 16 Grupos de repetição, 17
Exemplo de conexão com SQL
Objetivos da, 16 Server, 666 Profiler, 438
Primeira forma normal, 17 Exemplo de inserção no banco, 687 Conceito, 438
Segunda forma normal, 17 Exemplo prático com ODBC, 673 Exemplo prático, 440
Terceira forma normal, 18 Inserindo dados no banco, 687 Modelos de trace, 439
Novidades do SQL Server 2005, 48 Localizar registros, 699 Utilização, 438
Melhorias na disponibilidade, 52 Pool de conexões, 672 Programação DOS, 767
No desenvolvimento de aplicações, 49 Ver ASP, 658 Programação Windows, 768
No gerenciamento do banco de Permissões de acesso aos bancos de Projeto de banco de dados, 19
dados, 51 dados, 330 Conceito, 19
Nos utilitários de administração, 53 Comando sp_grantdbaccess, 334 Dicas, 19
Comando sp_revokedbaccess, 336 Passos, 19
Conceito, 330 Propriedades dos campos, 171
O Exemplo prático, 331 Collation, 172
ODBC, 642 Introdução, 330 Default Value or Binding, 171
Criar fonte ODBC, 644 Permissões de acesso aos objetos do Description, 171
Definição, 643 banco de dados, 341 Formula, 171
Estrutura, 643 Agendar tarefas, 342 Identity increment, 171
Exemplo prático, 644 Alterar banco de dados, 342 Identity, 171
Fonte para o SQL Server, 648 Backup DB, 344 Identity seed, 171
O que é, 643 Backup log, 344 Indexed, 172
OLAP, 454 Características das, 345 Is ROWGuid, 171
OLE-DB, 642 Comando GRANT, 348 Publicações, 480
Como funciona, 653 Comando REVOKE, 350 Acessar propriedades, 480
Conceito, 653 Conceito, 341 Administração de, 480
Configurar, 480 O que é, 448 Windows Service Identity, 910
Criação de, 480 Para outros Subscribers, 507 RESTORE DATABASE, 263
Pubs, 525 Publicações, 459 Exemplo prático, 265
Importando Pubs, 525 Publisher, 455 Opções, 263
Pull Subscription, 461 Sintaxe, 263
Snapshot folder, 468 RESTORE LOG, 263
Q-R Snapshot Replication, 462 Exemplo prático, 265
Query Notification, 51 Subscriber, 457 Opções, 263
RAID-1, 124 Subscrições, 460 Sintaxe, 263
RAID-5, 124 Tipos de replicação, 462 Restore, 259
RecordSet, 679 Tipos de subscrições, 460 Comando RESTORE DATABASE, 263
Conceito, 679 Transactional Replication, 463 Comando RESTORE LOG, 263
Criação de, 680 Velocidade links de WAN, 453 Conceito, 259
Métodos, 686 Reporting Services, 850 Diferentes estratégias, 259
Propriedades, 685 Acessar via Browser, 880 Exemplo prático, 260
Registrar instância, 106 Arquitetura, 853 Introdução, 259
Configurar opções da instância, 109 Business Intelligence Dvelopment Opções do, 262
Studio, 868 REVOKE, 350
Exemplo prático, 106
Console de configuração, 907 Exemplos, 350
Relacionamentos, 11
Criando relatórios Matrix, 882 Sintaxe, 350
Conceito, 11
Criando um relatório simples, 867 Roles, 311
Exemplos, 12
Data Processing Extensions, 855 Adicionando usuários, 336
Introdução, 11
Definir campos, 873 Comando sp_addrole, 328
Quebra de, 15
Definir fonte de dados, 869 Comando sp_addrolemember, 341
Tipos de, 12
Definir layout, 875 Comando sp_addsrvrolemember, 340
Um para um, 12
Delivery extensions, 857 Comando sp_droprole, 328
Um para vários, 13
Diretório virtual, 909 Comando sp_dropsrvrolemember, 340
Vários para vários, 15
Exemplo prático tipo Matrix, 882 Comando sp_helprole, 329
Replicação, 448
Fonte compartilhada, 882 Conceito, 324
Agentes de replicação, 464
Formatos dos relatórios, 852 Criando roles, 326
Análise de cenários, 450
Formatos suportados, 852 Excluir membro, 340
Artigo, 457
Funções, 851 Exemplo prático, 337
Autonomia da réplica, 453
Gerenciamento de serviços, 908 Fixed Database Roles, 325
Benefícios da replicação, 453
Grupos – Exemplo prático, 899 Server roles, 325
Cenário teórico, 449
Introdução, 851 Utilização, 324
Conceito, 448
O que é, 851
Configurar um Distributor, 467
Opção Grupos, 899
Configurar um Publisher, 467
Conflitos de atualização, 453
Ordenar campos, 873 S
Principais componentes, 853
Criação de artigos, 471 Schemas, 291
Programmatic Interfaces, 855
Criando filtros, 475 Adicionar objetos ao, 362
Publicando relatórios no IIS, 880
Definir o dono do artigo, 474 Alterar o dono, 363
Referências cruzadas, 882
Distribution agent, 464 Como funcionam, 291
Relatórios via Web, 852
Distributor, 456 Conceito, 291
Rendering Extensions, 858
Excluindo elementos da, 505 Criando schemas, 360
Report Designer, 854
Exemplo prático, 466 Dono do objeto, 292
Report processor, 855
Filtro horizontal, 458 Dono do Schema, 292
Report server, 854
Filtro vertical, 458 Funções dos, 291
Report server database, 856
Habilitação de Subscribers, 482 Introdução, 291
Reporting Services Configuration, 907
Introdução, 448 O que são, 360
Requisitos de ASP.NET, 858
Latência, 453 Separação usuários x Schemas, 293
Requisitos do IIS, 858
Log reader agent, 465 Scripts, 932
Requisitos para o funcionamento, 858
Merge agent, 465 Exemplo prático, 932
Salvar em diferentes formatos, 876
Merge Replication, 464 Geração automática de, 932
Scheduling and Delivery Processor, 856
Modelo de Replicação, 454 Segunda forma normal, 17
Vantagens, 852
Necessidade de, 448
ÍNDICE REMISSIVO
Conceito, 17 Recomendações, 918 Sintaxe, 616
Definição, 17 Snapshot Replication, 462 sp_revokedbaccess, 336
Exemplo, 18 Como funciona, 462 Exemplo, 336
Segurança no Windows 2000 Server, 295 Conceito, 462 Sintaxe, 336
Active Directory, 297 Quando utilizar, 462 sp_revokelogin, 319
Contas de usuários, 299 SOAP, 764 Exemplos, 319
Domínios, 295 sp_addlogin, 320 Sintaxe, 319
Unidades Organizacionais, 298 Exemplos, 321 sp_spaceused, 214
Workgroups, 295 Sintaxe, 320 SP_STORED_PROCEDURES, 603
Segurança no Windows Server 2003, 295 sp_addrole, 328 Exemplos, 603
Active Directory, 297 Exemplos, 328 Sintaxe, 603
Contas de usuários, 299 Sintaxe, 328 SQL Computer Manager, 54
Domínios, 295 sp_addrolemember, 341 SQL Server 2005, 55
Unidades Organizacionais, 298 Exemplos práticos, 341 Edições, 55
Workgroups, 295 Sintaxe, 341 Requisitos de Hardware, 56
Seguranças 281 sp_addrolemember, 341 Requisitos de Software, 56
Acessar o banco de dados, 288 Exemplos práticos, 341 SQL Server and Windows
Conexão com o servidor, 283 Sintaxe, 341 Authentication mode, 285
Logins, 311 sp_addsrvrolemember, 340 Alterar o modo, 287
Modelo de segurança, 283 Exemplos, 340 SQL Server Management Studio, 53
Modos de autenticação, 285 Sintaxe, 340 Conceito, 103
Roles, 311 sp_addumpdevice, 241 Configurar opções da instância, 109
Schemas, 291 Exemplo prático, 241 Criar banco de dados, 130
Users, 311 Sintaxe, 241 Criar tabelas, 163
Serviços do SQL Server 2005, 80 sp_denylogin, 320 Definição, 103
Analysis Services, 84 Exemplos, 320 Exemplo prático, 103
Gerenciamento de Serviços, 85 Sintaxe, 320 Introdução, 103
MICROSOFT DISTRIBUTED SP_DETACH_DB, 929 Logon no, 104
TRANSACTION CORDINATOR – sp_dropdevice, 242 Navegando pelo, 103
MSDTC, 83 Exemplo prático, 242 Object Explorer, 106
Microsoft Reporting Services, 84 Sintaxe, 242 Opção databases, 116
Microsoft Search, 84 sp_droplogin, 321 Opções de navegação, 103
SQL SERVER AGENT, 83 Exemplos, 321 Registered servers, 105
SQL Server, 80 Sintaxe, 321 Registrar instância, 106
SNAP-IN SERVICE MANAGER, 91 sp_droprole, 328 Tela inicial do, 105
Conceito, 91 Exemplos, 328 SQL, 22
Continuar serviços, 92 Sintaxe, 328 Conceito, 22
Dependências, 94 sp_dropsrvrolemember, 340 Definição, 22
Exemplo prático, 91 Exemplos, 340 Instrução SELECT, 23
Guia geral, 93 Sintaxe, 340 Instrução SQL, 23
Guia logon, 93 sp_grantdbaccess, 334 Introdução, 22
Iniciar serviços, 92 Exemplos práticos, 335 Noções básicas, 22
Parar serviços, 92 Sintaxe, 334 Operações, 22
Pausar serviços, 92 sp_grantlogin, 318 Stored procedures, 583
Recuperação, 94 Exemplos, 318 Comando
Snap-in, 85 Sintaxe, 318 CREATE PROCEDURE, 586
Conceito, 85 sp_help, 215 SP_HELP, 602
Snapshot Databases, 915 sp_helpindex, 214 SP_HELPTEXT, 602
Como funcionam, 915 sp_helprole, 329 SP_STORED_PROCEDURES, 603
Conceito, 915 Exemplos, 329 Conceito, 583
Espaço em disco, 917 SP_HELPTEXT, 602 Criação de, 586
Exemplo prático, 919 Exemplos, 602 Estruturas de decisão, 592
Introdução, 915 Sintaxe, 602 Excluindo, 600
Limitações, 916 SP_HELPTRIGGER, 616 Executar, 590
Quando usar, 915 Exemplos, 616 Exemplo prático, 589
Extended Stored Procedures, 585 image, 160 Users, 311
Introdução, 583 integer, 160 VB.NET, 774
O que é, 583 money, 160 Apresentação, 774
Parâmetros de entrada, 588 nchar, 160 Views, 551
Parâmetros de saída, 598 ntext, 160 Acessar dados
System Stored Procedures, 585 nvarchar, 160 Acessar via Browser, 752
Temporary Stored Procedures, 585 real, 160 Comando CREATE VIEW, 754
User-defined Stored Procedures, 585 smallditetime, 161 Criando campos calculados, 559
Vantagens, 584 smallint, 161 Criando Views, 554
Subconsultas, 623 smallmoney, 161 Definição, 551
Conceito, 623 sql_variant, 161 Exemplo prático, 555
Cuidados com, 624 table, 161 Introdução, 551
Exemplos práticos, 623 text, 161 Limitações das, 553
Sintaxe, 623 timestamp, 161 Por que utilizar, 553
Subscrições, 460 tinyint, 161 Tipos de View, 552
Conceito, 460 unique-identifier, 161 Totalizações, 566
Configurar Pull Subscriptions, 498 varbinary, 161 Utilização de, 551
Exemplo prático, 483, 499 varchar, 161 Web Services, 762
Habilitação de Subscribers, 482 XML, 161 Conceito, 762
Introdução, 460 Transações, 42 Definição, 762
Pull Subscription, 461 Conceito, 42 Exemplo, 763
Push Subscription, 461 Exemplo, 42 Introdução, 762
Sybase, 5 Transactional Replication, 463 WHERE, 25
Como funciona, 463 WHILE...CONTINUE, 595
Conceito, 463 Exemplos, 595
T Quando utilizar, 463 Sintaxe, 595
Tabelas e Campos, 6 Transferir bancos entre instâncias, 926 Windows Authentication mode, 285
Conceito, 7 Comando SP_DETACH_DB, 929 Alterar o modo, 287
Exemplo, 7 Conceito, 926 XML, 754
TCO, 45 Exemplo prático, 927 O que é, 745
Terceira forma normal, 18 Quando usar, 926 Usos, 754
Conceito, 18 Triggers, 603 Visão geral, 754
Definição, 17 Comando CREATE TRIGGUER, 607
Exemplo, 19 Comando SP_HELPTRIGGER, 616
Tipo de Dados XML, 49 Comandos permitidos, 607
Tipos de dados definidos pelo usuário, Conceito, 604
185 Criar triggers, 607
Comando sp_addtype, 191 Definição, 604
Comando sp_droptype, 194 Desabilitar, 617
Conceito, 185 Exemplos práticos, 607
Criar um, 186 Habilitar, 616
Excluindo tipos, 192 Regra de negócio, 604
Usando um, 189 Trigger DELETE, 606
Tipos de dados, 159 Trigger INSERTE, 606
bigint, 159 Trigger INSTEAD OF, 606
binary, 159 Trigger NET, 606
bit, 160 Trigger UPDATE, 606
Char, 160 Utilização, 604
Conceito, 159 Unidades Organizacionais, 298
cursor, 160 Acesso aos objetos, 330
datetime, 160 Upgrdade do SQL Server 2000, 75
Definição, 159 Caminhos de Upgrade, 75
Dicas de definição, 162 Exemplo prático, 75
float, 160 Introdução, 75
Use Windows fibers, 112

Administraçao e Desenvolvimento - Curso Completo PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Administraçao e Desenvolvimento - Curso Completo PDF

Enviado por

Direitos autorais:

Formatos disponíveis

É proibido o uso deste material em Sala de Aula e Para Ministrar Treinamentos!!!

SQL SERVER 2005 ADMINISTRAÇÃO E DESENVOLVIMENTO

Nenhuma parte desta publicação poderá ser reproduzida

Editora de Produção: Gisella Narcisi

SQL Server 2005 Administração e Desenvolvimento Curso Completo

Suporte Técnico ao Leitor

Os conceitos emitidos nesta obra são de inteira responsabilidade do Autor.

Visite nossa Home Page

Axcel Books do Brasil Editora

Nota sobre direitos autorais:

• ESTE E-BOOK NÃO PODE SER FORNECIDO EM UM CD

PIRATARIA É CRIME, COM PENA DE CADEIA. EU

SE VOCÊ BAIXOU UMA CÓPIA DESTE ARQUIVO

ESTE ARQUIVO NÃO PODE SER DISTRIBUIDO

SE VOCÊ RECEBEU UMA CÓPIA ILEGAL DESTE

A QUEM SE DESTINA ESTE LIVRO?

MAS E OS USUÁRIOS QUE JÁ POSSUEM ALGUMA EXPERIÊNCIA?

♦ Introdução à linguagem XML.

♦ Utilização de ADO e OLE DB para acesso aos dados.

♦ Utilização do novo serviço de relatórios do SQL Server 2005-03-08.

♦ E muitos outros tópicos, indicados para os usuários intermediários e avançados.

VISÃO GERAL DOS CAPÍTULOS DO LIVRO

Capítulo 5: Informações fundamentais estão armazenadas em Bancos de Dados. A perda destas

EQUIPAMENTO E SOFTWARE NECESSÁRIOS

♦ Windows 2000 Professional

♦ Windows 2000 Server

♦ Windows Server 2003

A configuração mínima de hardware necessário depende de uma série de fatores.

♦ Aplicações implementadas no servidor, número de usuários simultâneos e recursos de hard-

♦ Processador Pentium 1 GHz ou superior.

♦ 256 MB de RAM, quanto mais melhor.

♦ Internet Explorer 6.x ou superior.

♦ Microsoft Access 2000 ou superior.

INSTALANDO E TESTANDO O IIS

1. Faça o logon no Windows com uma conta com permissões de administrador.

Figura i.1 Janela Adicionar ou remover programas.

Figura i.2 A janela para alterar a instalação do Windows.

Utilizando o Assistente de componentes do Windows, podemos adicionar novos serviços do Windows

Figura i.3 O grupo Application Server.

Figura i.4 Selecionando o IIS para instalação.

Figura i.5 Instalando todos os componentes do IIS.

Figura i.6 Opções do servidor World Wide Web.

Figura i.7 O IIS instalado e funcionando e a página padrão sendo exibida.

1. Abra o Internet Explorer.

O código-fonte, com os exemplos de programação, e os scripts SQL, apresentados no livro, estão

Com o deslocamento do modelo de desenvolvimento do mainframe; primeiro para o modelo Cliente/

♦ Microsoft Access – para aplicações de menor porte.

♦ MySQL para Linux.

Um exemplo de Banco de Dados Orientado a Objetos é o Jasmine da CA.

♦ Selecionar um conjunto de registros com base em um ou mais critérios especificados.

♦ Ordenar um conjunto de registros com base em um ou mais campos de dados.

♦ Alterar informações no Banco de Dados.

♦ Excluir informações no Banco de Dados.

♦ Inserir informações no Banco de Dados.

FUNDAMENTOS EM: CONCEITOS BÁSICOS

Apresentarei os seguintes tópicos teóricos, sobre o Modelo Relacional de Dados:

♦ Entidades e Atributos, os elementos básicos de um Banco de Dados.

♦ Relacionamentos entre Entidades (Tabelas).

♦ Análise de um Banco de Dados relacional.

O conjunto de todos os atributos de um cliente e os valores de cada atributo formam o Registro

♦ Entidade ou Tabela -> Um conjunto de registros.

♦ Campos ou Atributos -> Características individuais de cada entidade.

Figura 1.1 A entidade (tabela) Clientes e seus diversos atributos (campos).