SQL Server Development Tools

O projeto 'Juneau' de banco de dados

Jamie Laflen

Barlay Hill

O SQL Server Developer Tools, ou SSDT (codinome “Juneau”), representa o compromisso contínuo da Microsoft em fornecer ferramentas integradas para desenvolvedores que desejam criar no Microsoft SQL Server. Aqueles que já conhecem as versões anteriores do Projeto de banco de dados no Visual Studio acharão que o Juneau é uma evolução das ferramentas para SQL Server, acrescida de novos recursos e aprimoramentos. O Juneau fornece um conjunto de ferramentas unificado que combina os projetos encontrados no SQL Server Business Intelligence Design Studio (BIDS) — incluindo projetos do Reporting, Analysis e Integration Services — com o Projeto de banco de dados do SQL Server.

Embora você possa instalar o Juneau de forma independente e obter tudo o que você precisa para desenvolver bancos de dados para SQL Server, ele também é parte integrante do Visual Studio, o que significa que agora você pode desenvolver seu banco de dados no mesmo ambiente que seu aplicativo. O Juneau está disponível como parte da versão 2011 do SQL Server (chamada de “Denali”), mas também estará disponível com versões futuras do Visual Studio.

Este artigo enfoca o projeto Juneau de banco de dados. Esse sistema de projetos e seus recursos relacionados fornecem as ferramentas para editar, compilar, refatorar e publicar bancos de dados em versões específicas do SQL Server e SQL Azure. No Juneau, há um projeto do banco de dados para todas as versões do SQL Server, e ele pode incluir scripts Transact-SQL (T-SQL) e código que define objetos SQL CLR. Vamos começar observando como configurar um projeto de banco de dados.

O Projeto de banco de dados

O Projeto de banco de dados é um projeto do Visual Studio que permite o desenvolvimento offline de bancos de dados do SQL Server. Uma equipe de desenvolvimento de banco de dados pode migrar para um desenvolvimento baseado em projetos para aproveitar os benefícios que esse tipo de desenvolvimento oferece à equipe, em vez de desenvolver em um banco de dados ao vivo e compartilhado, incluindo:

• Isolamento das alterações do desenvolvedor
• Suporte avançado para edição T-SQL
• Verificação da fonte antes do desenvolvimento e da imposição dos padrões de codificação da equipe por meio de regras de análise de código
• Geração automatizada de script de migração

O sistema de projetos principal é muito semelhante ao seu predecessor do Projeto de banco de dados do Visual Studio (.dbproj), no qual os desenvolvedores expressam os objetos de forma declarativa como instruções CREATE. Para obter outras informações sobre desenvolvimento de esquema offline, consulte bit.ly/raDMNx.

Configuração de um projeto

Quando você cria um projeto de banco de dados pela primeira vez, ele parece vazio, assim como a maioria dos outros projetos criados pelo Visual Studio. Isso significa que você pode adicionar o código-fonte e depois criá-lo e depurá-lo antes de verificá-lo no controle de código-fonte. Ao contrário da maioria dos outros projetos, nos quais você precisa começar pelo código-fonte, um projeto de banco de dados pode ser criado a partir de um banco de dados existente do SQL Server. Há várias maneiras de preencher um projeto com código-fonte, dependendo do nível que controle que você deseja:

• Importar um banco de dados completo
• Importar scripts
• Importar um pacote de banco de dados (.dacpac)
• Escrever atualizações para objetos específicos a partir de uma comparação entre um projeto e um banco de dados
• Arrastar e soltar do Server Explorer
• Converter um projeto existente do Visual Studio 2010 (banco de dados/SQL CLR) em um Projeto de banco de dados do SQL Server

O projeto que você criou tem o modelo de um banco de dados; as propriedades do banco de dados (por exemplo, agrupamento) são armazenadas nas propriedades do projeto e os objetos do usuário são armazenados como fonte dentro do projeto. O projeto de banco de dados é a representação offline de seu banco de dados na forma de código-fonte.

Para apresentar o projeto de banco de dados, vamos começar com um projeto de banco de dados novo e vazio e analisar seus vários recursos. Há várias maneiras de criar um projeto de banco de dados. Como vamos começar com um projeto vazio, basta clicar em Arquivo | Novo | Projeto e depois selecionar o Projeto de banco de dados do SQL Server, como mostra a Figura 1.

Figura 1 Criação de um novo Projeto de banco de dados do SQL Server

Adição de fonte ao seu projeto

A maioria dos bancos de dados tem pelo menos uma tabela, então vamos adicionar uma agora. O Projeto de banco de dados do SQL Server fornece modelos T-SQL padrão para vários objetos SQL usados com mais frequência. Para criar um novo objeto, clique com o botão direito do mouse no nó do projeto e selecione Adicionar | Tabela, depois especifique o nome da tabela na caixa de diálogo; vamos usar “Customer”.

A Figura 2 mostra a aparência de uma nova tabela no novo designer de tabela.

Figura 2 O novo designer de tabela

Assim como o designer de HTML, o designer de tabela usa uma exibição de painel de divisão como padrão. A janela do designer contém uma representação gráfica e a definição de script da tabela. Independentemente da exibição escolhida, suas alterações serão sincronizadas com a outra exibição.

Frequentemente, o acesso direto a uma tabela é restrito, e você deverá escrever um procedimento armazenado para fornecer a um aplicativo o acesso programático aos dados da tabela. Com isso em mente, vamos adicionar um procedimento armazenado chamado “CreateCustomer” da mesma maneira que adicionamos a tabela Customer. O editor é aberto e um esqueleto de procedimento padrão a ser preenchido é exibido. Isso pode parecer um pouco desanimador porque, para muitos desenvolvedores, os procedimentos armazenados são desenvolvidos em um banco de dados ao vivo para que seja possível executar e validar o código à medida que ele é escrito. Mas não se preocupe, pois o projeto de banco de dados cria um novo banco de dados de depuração para tornar o desenvolvimento baseado em projetos muito mais produtivo. No editor, você pode selecionar algum texto e clicar com o botão direito do mouse para obter o menu de contexto mostrado na Figura 3.

Figura 3 Execução do código-fonte do projeto no banco de dados de depuração

Como funciona a execução do texto usando Executar Consulta sem que uma cadeia de conexão tenha sido configurada? Quando qualquer código-fonte é aberto, o editor é configurado para executar no banco de dados de depuração quando é solicitado a executar o script ou o texto selecionado. Além disso, o banco de dados de depuração é atualizado quando você inicia a depuração (por exemplo, pressionando F5 ou Ctrl+F5) para corresponder à fonte de seu projeto de banco de dados. O Juneau aproveita um novo recurso no Denali chamado SQL Server Express LocalDB para fornecer uma instância e bancos de dados automaticamente nos quais são realizados o desenvolvimento e a depuração. Para obter mais informações, consulte “Introdução ao SQL Server Express LocalDB” a seguir.

Desenvolvimento da fonte

Após analisar o LocalDB e ver como você pode desenvolver procedimentos armazenados dentro de seu código-fonte, você desejará conhecer alguns outros recursos interessantes disponíveis no Projeto de banco de dados. Um típico herói desconhecido, o IntelliSense dentro do sistema de projetos foi aprimorado com base nos comentários sobre o SQL Server Management Studio (SSMS) e o Projeto de banco de dados. Muitas das alterações apenas apararam algumas arestas, mas algumas são significativas:

• Modo de visualização: uma das principais reclamações sobre o T-SQL IntelliSense era centrada nos preenchimentos involuntários ao referenciar tipos a serem definidos. Por exemplo, sua intenção pode ser digitar: 

    select t.id from Table1 as t

Mas colocar um ponto depois de digitar:

    select t

resultaria em:

    select Table1.

Esse problema foi resolvido ao adicionar um “modo de visualização” ao IntelliSense. Com o modo de visualização, os usuários verão um conjunto de preenchimentos, mas não haverá preenchimento automático até que os preenchimentos sejam “ativados” (por meio das teclas de seta para baixo e para cima).

• IntelliSense com arquivos não salvos: nos projetos de banco de dados anteriores, era preciso salvar um arquivo para que os objetos definidos nele ficassem disponíveis no IntelliSense. Por exemplo, antes uma tabela recém-adicionada não apareceria no IntelliSense até que o arquivo da tabela tivesse sido salvo. Agora, a tabela aparecerá no IntelliSense mesmo que o arquivo não seja salvo.

Ao planejar o Juneau, a equipe achou importante elevar a experiência de desenvolvimento em T-SQL para o nível desfrutado pelos desenvolvedores em outras linguagens gerenciadas. Como parte desse objetivo, o editor dentro do sistema de projetos foi aprimorado para fornecer recursos de Common Language, como definição GOTO, encontrar todas as referências e refatorar diretamente a partir do editor ao clicar com o botão direito do mouse em uma definição ou referência de objeto.

Como você sabe, refatorar bancos de dados é muito mais difícil do que refatorar o código do aplicativo porque bancos de dados têm dados, e uma alteração de nome aparentemente inofensiva pode resultar em várias outras alterações devido às dependências de outros objetos — ou, pior ainda, pode ocorrer perda de dados quando essas alterações são implantadas. O Juneau controla as operações de refatoração realizadas dentro do projeto ao controlar as alterações no MsdnDemo.refactorlog (em nosso caso) para que possa considerar essas operações e gerar as instruções sp_rename ou ALTER SCHEMA adequadas.

Em outras linguagens gerenciadas, a ação de criar seu projeto é a etapa final antes de executar o novo código. No desenvolvimento de banco de dados, o análogo seria criar todos os objetos de banco de dados em seu projeto dentro de uma instância em execução. Para oferecer uma verificação completa de banco de dados para uma compilação de projeto de banco de dados, o Juneau aproveita outro novo recurso no SQL Server Denali, chamado SQL Server T-SQL Compiler Services. Esse componente fornece uma verificação completa de seu código-fonte sem a necessidade de executar essa fonte em um SQL Server ao vivo. Para ver isso em execução, adicione o código a seguir depois do procedimento CreateCustomer:

    go
    
    create table dbo.ExtendedVerificationDemo
    
    (
    
      c1 int null,
    
      c2 as c2 + 5
    
    )
``` T-SQL    

Quando o projeto for criado, você verá o seguinte erro na lista de erros e na janela de saída:

``` xml
E:\projects\MsdnDemo\MsdnDemo\CreateCustomer.sql(12,1): Error:  SQL01759: Computed column 'c2' in table 'ExtendedVerificationDemo' is not allowed to be used in another computed-column definition.

Como você pode ver, essa mensagem de erro é exatamente o que seria informado pelo mecanismo do SQL Server — neste caso, porque uma coluna computada não pode se referenciar. Por mais valioso que seja esse recurso, há situações em que pode ser preciso desabilitá-lo, por exemplo:

• O mecanismo de verificação é criado com base no mecanismo do SQL Server Denali e impõe regras baseadas nesse mecanismo. Se o seu projeto usar uma sintaxe preterida que foi removida no SQL Server Denali, a verificação falhará.
• O mecanismo de verificação não entende objetos referenciados por um nome totalmente qualificado de três ou quatro partes. O mecanismo sinalizará um aviso ou um erro com base nas regras adiadas de resolução de nomes do SQL Server, sobre as quais você pode ler mais em bit.ly/pDStXE.

Se você se deparar com esse tipo de limitação, é possível desativar a verificação estendida no nível do arquivo ou do projeto.

Depois que todos os avisos e erros tiverem sido resolvidos durante a compilação, verifique se o seu código realmente funciona.

Verificação da fonte

Após criar seu projeto, você precisa executar (e possivelmente depurar) seu código antes de verificá-lo no controle de código-fonte. Você tem várias opções, dependendo de onde você se encontra no ciclo de desenvolvimento e do que deseja fazer, como indicado na Figura 4.

Figura 4 Opções para a verificação do código

Migração de alterações

Quando seu código atingir um ponto estável, será o momento de migrá-lo para uma instância para ser testado e, com o tempo, usado pelos seus clientes. O Juneau tem um mecanismo de atualização incremental que gerará um script de atualização baseado na diferença entre a sua fonte e o banco de dados de destino. Embora exista um mecanismo subjacente, ele é exposto de três maneiras diferentes no Juneau para oferecer suporte à migração das suas alterações, como descreve a Figura 5.

Figura 5 Opções para a migração do código

Para oferecer suporte a esses três cenários diferentes, o mecanismo de atualização incremental expõe várias opções diferentes para controlar o comportamento. Você pode esperar que o padrão dessas configurações mude ao longo do tempo à medida que a equipe ajusta cada cenário. Por exemplo, no caso do tempo de design, talvez faça sentido que o mecanismo seja mais agressivo para garantir que a alteração será feita e se importe menos com a perda de dados, por se tratar de um banco de dados de depuração. Embora existam muitas opções, quero chamar a atenção para alguns comportamentos e suas opções correspondentes, como mostra a Figura 6.

Figura 6 Opções para o controle do comportamento de atualização

A possibilidade de criar um script de atualização incremental é muito útil durante a migração das alterações de uma fonte para um banco de dados de destino. No entanto, por mais preciso que o script de atualização incremental seja, às vezes é desafiador determinar exatamente o que está ocorrendo no script ou resumir o que o script está fazendo. Como uma ajuda para resumir e compreender o que o script de incremental realizará, o Juneau cria um relatório de visualização que realça os potenciais problemas com as ações tomadas pelo script, além de resumir as ações tomadas se o script for executado. Por exemplo, você pode publicar o seu projeto na instância do LocalDB padrão, como a seguir:

1. Abra a janela de atividade de segundo plano clicando em Exibir | Outras Janelas | Monitor de Atividade do Banco de Dados.
2. Clique com o botão direito do mouse no projeto e selecione Publicar.
3. Preencha a caixa de diálogo Publicar, como mostra a Figura 7.
4. Clique em Publicar.

Figura 7 Caixa de diálogo Publicação do Banco de Dados

Quando a publicação estiver concluída, abra a etapa de publicação e clique no link View Plan. Um relatório como o mostrado na Figura 8 será exibido.

Figura 8 O relatório de visualização da implantação

Como você pode ver, o relatório indica que as duas tabelas (corrigimos o erro na tabela ExtendedVerificationDemo) e o procedimento que escrevemos antes serão criados quando o script for executado. A seção de destaques está vazia, mas você pode ver que o relatório realçará as ações que podem causar um impacto significativo no desempenho ou perda de dados. Se tivéssemos apenas gerado um script, em vez de publicá-lo, poderíamos usar esse relatório para ajudar a verificar o script antes da execução.

Desenvolvimento conectado

Até aqui, falamos sobre maneiras de usar o Projeto de banco de dados para desenvolver o nosso código de forma declarativa fora do contexto de um banco de dados em execução. Toda essa tecnologia é extremamente útil ao trabalhar em ambientes de equipe, mas às vezes você deseja apenas interagir com um servidor ao vivo! A Microsoft sabe que servidores ao vivo são importantes para desenvolvedores, por isso, investiu em uma experiência avançada, conectada e orientada para desenvolvedores. Para demonstrar, vamos abrir o banco de dados no qual acabamos de realizar a publicação. Para se conectar a esse banco de dados:

1. Clique no menu Exibir.
2. Selecione Gerenciador de Servidores.
3. Clique com o botão direito do mouse no nó do SQL Server.
4. Selecione Adicionar SQL Server.
5. Preencha a caixa de diálogo de conexão com (localdb)\v11.0.
6. Navegue até o banco de dados MsdnDemo recém-publicado, como mostra a Figura 9.

Figura 9 Banco de dados MsdnDemo no novo nó do SQL Server no Gerenciador de Servidores

A primeira coisa que você pode perceber é que a árvore é muito parecida com a árvore no SSMS. Isso é proposital; a equipe queria limitar a quantidade de reaprendizagem necessária ao mudar para o Juneau. Você pode abrir um editor de consultas T-SQL diretamente na árvore e começar a escrever o código como você faria normalmente; esse editor é o mesmo editor aprimorado sobre o qual falamos antes. Ao contrário de alguns recursos do SSMS, a árvore do Juneau é destinada expressamente a ações orientadas para desenvolvedores. Por exemplo, se você clicar com o botão direito do mouse na tabela Customer e selecionar Excluir, você verá uma caixa de diálogo que exibe o mesmo relatório de visualização que você viu antes. No entanto, neste caso, há um aviso que o procedimento dbo.CreateCustomer será interrompido se a eliminação for executada, como mostra a Figura 10.

Figura 10 Caixa de diálogo de visualização de Atualizar Banco de Dados

** Warnings

     The object [dbo].[CreateCustomer] will be broken if the

       change is executed.

 

** Highlights

     Tables that will be rebuilt

       None

     Clustered indexes that will be dropped

       None

     Clustered indexes that will be created

       None

     Possible data issues

       None

 

** User actions

     Drop

       [dbo].[Customer] (Table)

 

** Supporting actions

Um relatório similar será criado se a tabela for renomeada. Em ambos os casos, antes que as ações sejam executadas, você é informado do impacto da alteração; esse relatório permite que você veja o que as suas alterações farão no banco de dados e o que pode precisar ser corrigido (ou excluído) se você aplicar as alterações.

Se você cancelar a exclusão e depois clicar com o botão direito do mouse na tabela Customer e selecionar Exibir Designer, você verá o mesmo designer de tabela com o qual você se familiarizou no sistema de projetos — exceto que desta vez ele está hospedado na definição da tabela recuperada do servidor. Como você pode esperar, o designer tem uma instrução de tabela CREATE usando o mesmo modelo de programação declarativa que o sistema de projetos. No designer, renomeie a coluna Id para CustomerId e adicione uma segunda coluna int chamada Age. Agora, se você observar a lista de erros, você verá um aviso que CreateCustomer foi interrompido porque a coluna foi renomeada, como mostra a Figura 11.

Figura 11 Erro porque a coluna foi renomeada

Para corrigir esse erro, você pode Exibir Código no procedimento CreateCustomer ou simplesmente clicar duas vezes no aviso e modificar a instrução INSERT para atualizar os nomes das colunas e fornecer @param2 como o valor para a coluna Age. Neste ponto, você tem duas janelas (uma fonte e um designer) com definições declarativas de objeto recuperadas do banco de dados definindo um conjunto de alterações nos objetos do servidor. Se você clicar no botão Atualizar Banco de Dados, verá o relatório, agora conhecido, que irá informá-lo de que a coluna será renomeada e que a tabela e o procedimento serão alterados. Execute o script clicando em Atualizar Banco de Dados e depois navegue até a tabela Customer no Gerenciador de Servidores. Você verá que a árvore será atualizada para incluir as colunas CustomerId e Age.

A experiência de desenvolvimento conectado no Gerenciador de Servidores fornece muita eficiência a você ao oferecer suporte ao mesmo modelo de programação declarativa e aprimorar as alterações online com avisos e suporte a erros em tempo real à medida que você faz as alterações.

Obtenção dos bits

O Juneau está disponível na versão CTP3 do SQL Server Denali. Ele também ficará disponível como um download da Web autônomo, e se integrará às instalações existentes do Visual Studio 2010 e da próxima versão do Visual Studio. Além disso, o Juneau tem um instalador separado de ferramentas de linha de comando para a publicação de banco de dados sem exigir que o Visual Studio esteja instalado e para cenários do Team Foundation Server com compilação automatizada.

Introdução ao SQL Server Express LocalDB

O SQL Server Express LocalDB (ou apenas LocalDB) é basicamente a próxima geração das Instâncias de Usuário do SQL Express, mas sem a necessidade de gerenciar explicitamente uma instância do SQL Express em sua área de trabalho. O LocalDB não tem um serviço de segundo plano que hospeda uma instância nomeada; em vez disso, fornece uma maneira para que os desenvolvedores definam instâncias nomeadas personalizadas e depois interajam com elas. Quando uma instância do LocalDB é iniciada, ela executa um processo sob as credenciais do usuário que a iniciou. Por exemplo, se você iniciar uma instância do LocalDB, no Gerenciador de Tarefas você verá um processo sqlservr.exe sendo executado sob suas próprias credenciais. Por si só, isso é interessante porque significa que não é preciso fazer instalações para depurar seu código T-SQL! Depois que a instância for iniciada, ela será como uma instância do SQL Express. Quando a instância não for usada por um período de tempo, ela será encerrada para que uma instância ociosa do SQL Server não consuma recursos em sua máquina.

Uma instalação do LocalDB vem com uma ferramenta de linha de comando que pode ser usada para gerenciar as instâncias do LocalDB criadas por você. Por exemplo, você pode criar uma nova instância do LocalDB chamada LocalDBDemo executando o seguinte:

C:\Program Files\Microsoft SQL Server\110\Tools\Binn>SqlLocalDB.exe create LocalDBDemo

Local Database instance "LocalDBDemo" created with version 11.0.

Quando a instância tiver sido criada, você poderá iniciá-la usando a ferramenta de linha de comando ou simplesmente tentar se conectar à instância por meio do Juneau, do SQL Server Management Studio (SSMS) ou de seu aplicativo. Como as instâncias do LocalDB não são residentes, elas não podem ser acessadas usando o prefixo (local) usado para lidar com instâncias na máquina local. Em vez disso, use (localdb); nesse exemplo, você digitaria (localdb)\LocalDBDemo no Juneau para se conectar e gerenciar a instância.

Quando você cria uma nova instância, um novo diretório é criado em seu perfil de usuário e os quatro bancos de dados internos (master, tempdb, msdb e model) são colocados dentro desse diretório. Por padrão, qualquer banco de dados novo irá para o diretório da instância como o caminho de dados padrão. Em nosso exemplo, o diretório é:

C:\Users\user1\AppData\Local\Microsoft\Microsoft SQL Server Local DB\Instances\LocalDBDemo

Se não quiser criar uma instância personalizada, você pode usar a instância padrão interna do LocalDB chamada v11.0. Para acessar a instância, basta registrar uma conexão com “(localdb)\v11.0” no Juneau, e a instância será criada automaticamente para você pelo LocalDB.

Como o LocalDB é novo, um patch do Microsoft .NET Framework 4 é exigido para usar o prefixo (LocalDB) ao acessar uma instância por meio do SSMS ou do código de aplicativo gerenciado. A instalação do Juneau incluirá esse patch. O suporte para o prefixo será incorporado à próxima versão do .NET Framework.

Os desenvolvedores de banco de dados enfrentam um problema semelhante ao enfrentado por desenvolvedores da Web (e que o IISExpress resolveu para eles): como desenvolver e depurar um código que exige ser executado por um servidor sem a necessidade de executar um produto de servidor completo localmente na máquina de desenvolvimento. O LocalDB oferece uma solução para desenvolvedores de banco de dados. Como o LocalDB é uma parte crucial do desenvolvimento de banco de dados, ele é instalado em sua área de trabalho quando você instala o Juneau. Quando um projeto de banco de dados é adicionado a uma solução, o Juneau cria uma nova instância do LocalDB que recebe o nome da solução e cria um banco de dados dentro dessa instância para cada projeto de banco de dados. O Juneau cria os dados e o arquivo de log para cada projeto de banco de dados em um diretório dentro do diretório do projeto. Para obter mais informações sobre o LocalDB, consulte go.microsoft.com/fwlink/?LinkId=221201.

Jamie Laflen é um desenvolvedor que trabalha no SQL Server Developer Tools. Anteriormente, ele trabalhava em projetos de banco de dados do Visual Studio.

Barclay Hill é um gerente de programas sênior que trabalha no SQL Server Developer Tools. Anteriormente, ele trabalhava em projetos de banco de dados do Visual Studio.

Agradecemos aos seguintes especialistas técnicos pela revisão deste artigo: Jeffrey Davis, Mike Kaufman, Dave Langer, Genevieve Orchard e Patrick Sirr