Banco de Dados Evolutivo – Parte 7

Nesse post da série Banco de Dados Evolutivo, você irá efetuar a primeira refatoração no database AdventureWorks_Homolog através da ferramenta de versionamento de banco de dados Liquibase. Iremos aprender um pouco sobre o funcionamento do comando UPDATE (Para informações teóricas sobre este comando, leia a Parte 4 do conjunto de posts).


Antes de iniciarmos, para que fique mais claro do que o exposto na Parte 5 da série e não tenhamos erros futuros, se você executou todos os passos para instalação e configuração do ambiente de testes você percebeu que no link para download do arquivo jdbc para o SQL Server existem várias opções. Você precisará fazer o download do arquivo sqljdbc_4.1.5605.100_ptb.tar.gz. Após o download concluído será necessário que você descompacte o arquivo e copie o sqljdbc4.jar para dentro da pasta do Liquibase que está no diretório C:\ (conforme explicado na Parte 5 do conjunto de posts).

Agora finalmente começaremos os testes na ferramenta Liquibase. Dentro do diretório C:\changelog (gerado com base no post anterior – Parte 6) crie o arquivo master.xml usando o código da Listagem 1.

 <databaseChangeLog
        xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns:ext="http://www.liquibase.org/xml/ns/dbchangelog-ext"
        xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog
 http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-2.0.xsd
        http://www.liquibase.org/xml/ns/dbchangelog-ext
 http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-ext.xsd">

 <include file="C:/changelog/versao_1.0/master_1.0.xml" />

 </databaseChangeLog>

Listagem 1. Comando usado dentro do arquivo master.xml criado.

Após isso, dentro do diretório C:\changelog\versao_1.0 crie o arquivo master_1.0.xml segundo o codigo da Listagem 2.

 <databaseChangeLog
        xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns:ext="http://www.liquibase.org/xml/ns/dbchangelog-ext"
        xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog
 http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-2.0.xsd
        http://www.liquibase.org/xml/ns/dbchangelog-ext
 http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-ext.xsd">

 <include file="C:/changelog/versao_1.0/changelog_1.xml" />

 </databaseChangeLog>

Listagem 2. Comando usado dentro do arquivo master_1.0.xml criado.

Faremos a nossa primeira experiência com a ferramenta criando uma tabela chamada teste_liquibase no nosso banco de dados AdventureWorks_Homolog. Para isso criaremos um arquivo chamado changelog_1.xml (use o código da Listagem 3). Não precisaremos alterar o arquivo master_1.0.xml pois, quando o criamos, já adicionamos a tag que inclui esse XML de refatoração. A tag changeset, como fora dito anteriormente (Parte 4 do conjunto de posts), contém as alterações DDL e/ou DML da base de dados para qual está sendo apontada.

 <databaseChangeLog
        xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns:ext="http://www.liquibase.org/xml/ns/dbchangelog-ext"
        xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog
 http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-2.0.xsd
        http://www.liquibase.org/xml/ns/dbchangelog-ext
 http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-ext.xsd">

 <changeSet author="arthur" id="cria tabela teste_liquibase">
     <createTable
          tableName="teste_liquibase">
             <column name="id" type="integer"/>
             <column name="nome" type="varchar(255)"/>
             <column name="telefone" type="varchar(11)"/>
     </createTable>
 </changeSet>

 </databaseChangeLog>

Listagem 3. Comando usado dentro do arquivo changelog_1.xml criado.

Para que seja possível executar o comando UPDATE é necessário que passemos uma serie de parâmetros via linha de comando para o Liquibase. Para que não seja necessário redigitar todos esses parâmetros todas as vezes que formos realizar alguma alteração em nosso banco de dados é possível que criemos um arquivo de propriedades. Esse arquivo que se chamará liquibase.properties irá armazenar todas as informações necessárias para que possamos trabalhar de forma mais simples. Para criá-lo utilize o código da Listagem 4. Salve-o dentro do diretório do Liquibase localizado em C:\. Atribua aos parâmetros <user> e <password> respectivamente o usuário e senha com permissões de alterações DDL, DML e DCL no database.

driver: com.microsoft.sqlserver.jdbc.SQLServerDriver 
classpath: C:/liquibase-3.0.8-bin/sqljdbc4.jar 
url: jdbc:sqlserver://localhost:1433;databaseName=AdventureWorks_Homolog 
username: 
password:  
changeLogFile: C:/changelog/master.xml

Listagem 4. Comando usado dentro do arquivo liquibaseHomolog.properties criado.

Observe que por termos os apontamentos realizados através das tags de include dentro do arquivo master.xml, sempre que você o executar, estará efetuando todas as mudanças construídas através dos demais changelogs (Lembrando que graças aos registros dentro da tabela de controle databasechangelog o Liquibase não se perde e refaz algo que já tenha sido executado anteriormente. Ou seja, ele varre essa tabela de controle e procura tudo que foi executado para realizar somente aquilo que ainda não foi executado).

Para realizar o UPDATE abra o cmd, vá para a pasta raiz do sistema operacional e digite os comandos da Listagem 5. Primeiramente o Liquibase é executado. Depois a ferramenta receberá os parâmetros que foram guardados no arquivo liquibaseHomolog.properties e, por último, teremos a execução do comando UPDATE que será responsável pela criação da tabela teste_liquibase na nossa base AdventureWorks_Homolog.

java -jar C:\liquibase-3.0.8-bin\liquibase.jar --defaultsFile=C:\liquibase-3.0.8-bin\liquibaseHomolog.properties update

Listagem 5. Comando usado no cmd para execução do comando UPDATE através do Liquibase.

capture 1
Figura 1. Tabelas de controle databasechangelog e databasechangeloglock e tabela teste_liquibase.

Após a execução do comando você poderá ver que as duas tabelas de controle (databasechangelog e databasechangeloglock) foram criadas na base AdventureWorks_Homolog. E poderá ver também que temos uma nova tabela chamada teste_liquibase no schema dbo – Veja na Figura 1. Se você realizar um SELECT na tabela databesechangelog será possível observar que ela guardou os dados da alteração executada no campo description. Veja também os campos id e autor – Figura 2.

Capture 2
Figura 2. SELECT executado na tabela de controle databasechangelog após a execução do comando UPDATE.

Caso ao executar o comando da Listagem 5 a tela do cmd apresentar o seguinte erro:

Liquibase update Failed: com.microsoft.sqlserver.jdbc.SQLServerException:
The TC P/IP connection to the host localhost, port 1433 has failed. Error:
 "Connection refused: connect. Verify the connection properties. Make sure
 that an instance o f SQL Server is running on the host and accepting TCP/
IP connections at the port . Make sure that TCP connections to the port 
are not blocked by a firewall.". C:\>
Captura de Tela 2015-06-27 às 2.12.24 AM
Figura 3. Configurando a porta TCP/IP para que o Liquibase consiga acessar o SQL Server.

Você precisará da seguinte configuração:

  1. Abrir o Sql Server Configuration Manager;
  2. Expandir a aba SQL Server Network Configuration;
  3. Clicar em Protocols for <instance_name>;
  4. Abrir a opção TCP/IP (dentro de Protocol Name);
  5. Marcar como YES a opção Enabled (caso esteja diferente disso);
  6. Ir até a aba IP Addresses;
  7. Descer a barra de rolagem até a opção IPAII;
  8. preencher a opção TCP Port com o valor 1433 (Veja a Figura 3).
  9. Reiniciar a instância de banco de dados.

Depois do término da configuração exposta acima, você poderá executar novamente o comando da Listagem 5 que receberá uma mensagem de sucesso.


No próximo post aprenderemos sobre o comando RollbackCount (um dos tipos de rollbacks permitidos pela ferramenta de versionamento de banco de dados Liquibase).

Anúncios

Banco de Dados Evolutivo – Parte 6

Para finalizar a criação do ambiente de teste, vamos à definição das boas práticas para uso do Liquibase (Para mais informações sobre instalação e conceitos para implementação de um banco de dados evolutivo, leia os demais posts da série – seguem links no rodapé do post).


É necessário que você organize os arquivos de changelog de forma a não perde-los, alterá-los ou desorganizá-los. Para isso, criaremos uma estrutura de diretórios para guardarmos os nossos arquivos de alteração.

Crie os diretórios segundo a Figura 1. Após criados os diretórios e os arquivos XML não renomeie e nem apague nenhuma pasta ou arquivo que estiver sendo usando como refatoração. Isso faria com que a ferramenta se perdesse nos apontamentos destruindo todo o projeto de versionamento.

Estrutura de diretórios para uso do Liquibase.
Figura 1: Estrutura de diretórios para uso do Liquibase.

Você irá gerar um arquivo de changelog chamado master.xml – esse estará no diretório changelog – que será responsável por executar dentro de si os arquivos master_xx.xml, onde xx corresponde à versão em que o banco se encontra – esses estarão em um diretório abaixo do changelog com o nome da respectiva versão. Por sua vez, cada arquivo de nome versao_xx.xml conterá dentro de si cada um dos arquivo changelog.xml de alteração.


No próximo post iniciaremos nossos testes práticos na ferramenta de versionamento Liquibase. Veremos um primeiro exemplo do comando Update.

Para ler o conteúdo completo da série:

Banco de Dados Evolutivo – Parte 1
Banco de Dados Evolutivo – Parte 2
Banco de Dados Evolutivo – Parte 3
Banco de Dados Evolutivo – Parte 3
Banco de Dados Evolutivo – Parte 4
Banco de Dados Evolutivo – Parte 5

Banco de Dados Evolutivo – Parte 5

Como vimos no post anterior Banco de Dados Evolutivo – Parte 4, iniciamos a etapa prática no aprendizado sobre versionamento de banco de dados. Nessa post da série Banco de Dados Evolutivo vamos aprender como instalar e configurar a ferramenta de versionamento de banco de dados Liquibase. 


Vamos usar como nosso ambiente de testes a plataforma Windows e o SQL Server 2014. Você poderá usar também, caso seja de seu interesse, o Linux, outros bancos de dados ou outra versão do SQL Server. O Liquibase trabalha com vários bancos de dados, dentre eles: MySQL, PostgreSQL, Oracle, Sybase_Enterprise, DB2, Firebird. Para uma lista completa, acesse liquibase.org/databases.

Não será exposto neste artigo informações sobre instalação do sistema operacional e do banco de dados. Partirei do pressuposto de que você já os tenha instalados e funcionando perfeitamente.

figura 1
Figura 1 – Restores realizados da base AdventureWorks2014.

Vamos usufruir também da base de dados AdventureWorks2014 disponível para download aqui. Será necessário que você faça dois restores dessa base. Uma com o nome AdventureWorks_Prod e outra com o nome AdventureWorks_Homolog conforme a figura 1.

Após configuradas as duas bases de dados será necessário fazer o download do arquivo jdbc para que seja possível conectarmos o Liquibase ao banco. Você poderá efetuar o download aqui.

Agora você irá realizar o download, instalar e configurar o Liquibase. Para download clique aqui. Para instalação é necessário que você tenha o Java JDK instalado e as variáveis de ambiente configuradas. (Para mais informações sobre como instalar e configurar o Java JDK, clique aqui). Caso esteja tudo correto em seu ambiente, siga o passo a passo abaixo para configurar o Liquibase:

  1. Descompacte o arquivo dentro da unidade C:\;
  2. Coloque o arquivo jdbc que foi baixado anteriormente dentro da pasta descompactada.

Para testar se o Liquibase está instalado e configurado devidamente abra o cmd, vá até a pasta raiz do servidor e execute o comando abaixo.

java –jar liquibase-3.0.8-bin\liquibase.jar –-version

Se o resultado da execução do comando for o texto Liquibase Version: 3.0.8, a instalação foi realizada com sucesso.


No próximo post veremos quais são as Boas Práticas recomendadas para utilização da ferramenta de versionamento de banco de dados Liquibase.

Banco de Dados Evolutivo – Parte 4

A partir desse post da série Banco de Dados Evolutivo vamos entender e aprender como automatizar a maior parte do trabalho de controle de versionamento de banco de dados.

Existem várias ferramentas que ajudam essa tarefa, entretanto, veremos a partir de agora como implementar esses conceitos de banco de dados evolutivo abordados nos posts Parte 1, Parte 2 e Parte 3 usando a ferramenta Liquibase.


O LiquiBase é uma ferramenta de versionamento open source em Java criada para gerenciar as mudanças de banco de dados. Ao invés de o desenvolvedor escrever o SQL diretamente no banco de dados para criar, atualizar ou descartar objetos, essas definições são escritas em arquivos XML. Esse arquivo XML é denominado changelog que, por sua vez contém vários changesets que nada mais são que cada uma das alterações de banco. Na Listagem 1 e 2 constam um exemplo da estrutura do changelog e changeset respectivamente.

 <databaseChangeLog
        xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns:ext="http://www.liquibase.org/xml/ns/dbchangelog-ext"
        xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog
 http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-2.0.xsd
        http://www.liquibase.org/xml/ns/dbchangelog-ext
 http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-ext.xsd">

 </databaseChangeLog>

Listagem 1. Estrutura do arquivo de ChangeLog da ferramenta de versionamento de banco de dados LiquiBase.

 <changeSet author="arthur" id="apresentacao_liquibase">

    <createTable tableName="datas_light">
         <column name="id" type="int"/>
    	<column name="nome" type="varchar(255)"/>
    </createTable>

 </changeSet>

Listagem 2. Estrutura do arquivo de ChangeSet da ferramenta de versionamento de banco de dados LiquiBase.

O funcionamento da ferramenta é bem simples. O LiquiBase cria no banco de dados a ser versionado duas tabelas de controle: databasechangelog e databasechangeloglock. Essas tabelas serão geradas no primeiro comando que você executar através da ferramenta. Na tabela databasechangelog o Liquibase guarda as informações de changesets aplicadas na base de dados sendo que o XML de alteração é identificado por uma chave composta formada por id e autor. Já a tabela databasechangeloglock serve para não permitir que dois usuários apliquem alterações simultâneas na mesma base de dados.

As mudanças são feitas em arquivos XML (como já foi dito) e são executados através de comandos via DOS (Windows) ou Terminal (Linux). Os principais comandos são de:

  • Update – Usado para os comandos de criação, alteração ou descarte de objetos;
  • Rollback – Usado para desfazer uma alteração executada na base de dados;
  • Diff – Usado para verificar o que há de diferente entre duas bases de dados;
  • SQL Output – Usado para transformar os changelogfiles XML em arquivos SQL;

Com relação às refatorações o LiquiBase possui inúmeras possibilidades que vão de comandos simples como um create ou drop database até comandos complexos como lookup table e merge columns.

No próximo post iniciaremos a preparação de um ambiente de testes para que seja possível usufruímos do potencial da ferramenta de versionamento na base de dados Adventure Works. 


Para se ler o conteúdo completo desta série – Banco de Dados Evolutivo – Parte 1, Banco de Dados Evolutivo – Parte 2 e Banco de Dados Evolutivo – Parte 3.

Banco de Dados Evolutivo – Parte 3

Nesse próximo post da série Banco de Dados evolutivo iremos entender acerca dos diferentes tipos de refatorações de bancos de dados. Veremos também uma melhor prática para utilização das SandBox (para mais informações sobre as SandBox, leia Banco de Dados Evolutivo – Parte 2)


Refatorações de Banco de Dados

Toda e qualquer alteração feita na base de dados é denominada refatoração. Essa técnica de refatoração do SGBD torna-se complexa porque no banco existem três diferentes mudanças que ora são feitas em conjunto, ora não. São elas:

  1. Alteração no Schema de Banco de Dados – Mudanças executas com base em queries DDL (Data Definition Language);
  2. Alteração de Dados do SGBD – Mudanças executadas com base em queries DML (Data Manipulation Language);
  3. Alteração de Acessos do Banco de Dados – Mudanças executadas com base em queries DCL (Data Control Language).

Muitas refatorações, tais como adicionar uma coluna, podem ser feitas sem ser preciso atualizar áreas do código da aplicação. Por outro lado, existem mudanças que são caracterizadas como alterações destrutivas. Essas refatorações são conhecidas dessa forma porque sua implementação pode fazer com que surjam erros no sistema. Como exemplo teríamos tornar uma coluna NULL como NOT NULL.

Alterações destrutivas precisam de um pouco mais de cuidado cujo grau de atenção irá depender do quanto a mudança é prejudicial ao ambiente. O importante é escolher em conjunto com o time um procedimento apropriado para cada tipo de mudança. Se houver um controle adequado do sistema, mesmo que ocorra algum problema, não será difícil revertê-lo e corrigi-lo.

Atualização automática e simuntânea das SandBox

Uma boa prática para o conceito de banco de dados evolutivo é sempre atualizar automaticamente todas as sandbox quando o banco de dados master for alterado. O mesmo script que atualiza a base de dados central atualizará todas as instancias de banco de dados dos desenvolvedores. Dessa maneira há uma impossibilidade de um desenvolvedor executar um commit em uma alteração e modificar a base master que já havia sido atualizada por outro programador.

No próximo post veremos como utilizar todos esses conceitos listados através da ferramenta de versionamento de banco de dados Liquibase.


Para saber mais, leia: Banco de Dados Evolutivo – Parte 1 Banco de Dados Evolutivo – Parte 2

Banco de Dados Evolutivo – Parte 2

Nesse artigo da série Banco de Dados Evolutivo Veremos mais uma parte dos conceitos usados entre a equipe de desenvolvimento x equipe de banco de dados para que seja possível construir um banco de dados que evolua junto à aplicação. 

Hoje aprenderemos sobre as SandBox e o Database Master.


Instâncias de Banco de Dados – SandBox

O conceito de metodologia ágil reconhece que as pessoas aprendem coisas por tentar executá-las. Na programação podemos ver que os desenvolvedores experimentam formas de fazer determinada característica, podendo assim escolher uma melhor forma de implementá-la. Com a base de dados não deve ser diferente. É preciso conceder a cada um dos desenvolvedores um banco de dados próprio (conhecido como sandbox). Dessa maneira, assim como na programação, o desenvolvedor poderá usar a imaginação em seu próprio ambiente, mexendo na estrutura da base de dados como bem quiser, sem que essas variações afetem de alguma forma alguém.

Segundo alguns utilizadores desse conceito de versionamento, muitos especialistas DBAs veem essa opção como um quase insulto por ser muito difícil de funcionar na prática. Porém, vem-se observando que sim, é possível trabalhar com inúmeras bases. Mas para isso é essencial possuir ferramentas que manipulem as bases tão facilmente quanto se manipulam arquivos.

Banco de Dados Central – Master

Embora os desenvolvedores possam experimentar com frequência em suas próprias sandbox, é importante unir essas diferentes mudanças realizadas em um único lugar novamente. Ou seja, para aplicar o conceito de banco de dados evolutivo é necessário que exista um banco de dados Central ou Master que integre todos essas alterações de estrutura de banco feita por cada um dos programadores.

 A cada dia uma foto do banco de dados Central é feito e o sua imagem é implantada em cada uma das sandbox de cada um dos desenvolvedores. E ao final de cada dia, essas mudanças são reintegradas à base Master. É claro que o DBA deve estar ciente de todas as mudanças feitas pelos desenvolvedores. Por isso fora dito mais acima sobre a importância de uma comunicação continua e sem barreiras.

É importante que as integrações das sandbox com o banco de dados central seja feito constantemente pois foi descoberto que fazer várias pequenas alterações em um ambiente é mais fácil do que executar uma única grande mudança.

No próximo post iremos falar sobre as diferentes refatorações de banco de dados.

Banco de Dados Evolutivo – Parte 1

A primeira etapa desse conjunto de artigos da série Banco de Dados Evolutivo irá tratar de alguns conceitos para que seja possível por em prática essa metodologia de desenvolvimento de banco de dados. Em segundo momento, demonstraremos de forma prática esse conceito usando a ferramenta de versionamento de banco de dados Liquibase.


A fim de aceitar o desafio de lidar com variações constantes no projeto de construção de um sistema é necessário adotar um pensamento diferenciado. Ao invés de conceber o design como uma fase isolada e, em grande parte, concluída antes do início do desenvolvimento, é preciso olhar para ele como um processo continuo que intercala com a construção até o momento da entrega do software. Esse é o principal contraste entre o design planejado, como o da metodologia sequencial, e o design evolutivo das metodologias ágeis.

Apesar dessas novas técnicas terem crescido em uso e interesse, uma das maiores questões é como fazer o trabalho de design evolutivo para banco de dados. É necessário que a estrutura do SGBD evolua em conjunto com o sistema para que se tenha sucesso na implementação dos métodos ágeis. E é sobre isso que esse conjunto de artigos trata. Sobre conceitos e técnicas de implementar a construção evolutiva da estrutura de banco de dados.

Colaboração continua

Para que a ideia de design de banco de dados evolutivo possa funcionar e fluir bem onde ela estiver sendo aplicada é necessário que algumas medidas sejam adotadas. Uma delas é uma colaboração continua e irrestrita entre todo o time de desenvolvimento. Não pode existir barreiras para essa comunicação. Ao invés de decisões tomadas em reuniões formais, por exemplo, é preciso que ocorra conversas abertas entre todos os profissionais de forma a facilitar a comunicação.

Outra medida consiste em fazer com que cada atividade executada por um programador que afete de alguma forma a estrutura DDL ou DML do banco de dados seja feita em colaboração com o administrador de dados. Assim como o desenvolvedor sabe acerca da precisão de uma nova funcionalidade o responsável pelo SGBD possui uma visão global dos dados e da estrutura do banco. Dessa forma será possível descobrir de que forma essa nova implementação irá afetar o esquema de banco de dados e qual a melhor forma de executa-la.

No próximo post iremos falar sobre as SandBox e DataBase Master