Recursos: nota Quickupdate, Modelagem
Do que se trata o artigo:
O artigo apresenta técnicas fundamentais para migração de dados e as suas melhores práticas através da utilização de ferramenta especialista gratuita, de código aberto, Pentaho Data Integration (PDI).
O case utilizado é o de uma suposta fusão entre duas lojas de e-Commerce, no qual o sistema de uma delas, armazenado em MySQL, se tornará responsável por gerir as informações sendo necessária, portanto, uma migração de dados do SQL Server para o MySQL.
Em que situação o tema é útil:
Sistemas de informação têm um ciclo de vida útil e, com o
tempo, tornam-se obsoletos, sendo necessária a evolução deste. Nestes casos,
existe a preocupação de não perder informação e de melhorar a qualidade dos
dados armazenados. Ocorre que muitas vezes a migração exige que seja feita “à
quente”, ou seja, com a base Destino em operação, e algumas técnicas são
fundamentais para garantir a integridade dos dados e minimizar o tempo deste
processo, independente dos bancos de dados envolvidos.
Migração de dados utilizando o Pentaho Data Integration:
Processos de migração de dados são sempre desafiadores e estão se tornando cada vez mais necessários.
Embasado em um case do cotidiano de um Administrador de Dados, este artigo mostra de forma prática soluções para resolver alguns dos problemas mais comuns em processos de migração de dados, situações carentes de análise pela doutrina especializada. São abordadas a instalação e a configuração do Pentaho Data Integration, assim como técnicas de validação, formatação e “desduplicação” de dados, técnicas para minimizar o tempo de execução do processo de migração e também para permitir a rastreabilidade dos dados, fundamental para que o resultado possa ser aferido de forma segura.
Com o implemento de novas tecnologias e o aumento da competitividade é de se esperar que todas as organizações passem por um processo de evolução em seus sistemas de informação. Independente de ser motivada pelas deficiências do sistema atual ou pelos ganhos que o novo sistema trará, a preocupação em não perder informação é unânime.
Existem ferramentas que movem os dados de uma estrutura para a outra, entretanto não permitem maiores tratamentos, pois resumem-se a um "de-para" nos tipos de dados. Entretanto, como na maioria dos casos a mudança do Sistema Gerenciador de Banco de Dados Relacional (SGBDR) vem aliada a uma nova versão do sistema, esse tipo de ferramenta pouco auxilia.
É normal que os sistemas tenham estruturas de dadose regras distintas entre si e por isso o processo de migração pode ser bastantetrabalhoso e o risco de haver uma restrição que impeça este processo de serexecutado até o fim é muito grande. Como seria impossível encapsular todo oprocesso em uma única transação do banco de dados, o que permitiria um rollbackem caso de erro, algumas técnicas são fundamentais para manter arastreabilidade dos dados e poder retomar o processo de migração de onde parou.
O início da execução de qualquer projeto de Tecnologia da Informação e Comunicação (TIC) é o levantamento de requisitos e de regras de negócio. Esta etapa é fundamental para delimitar o que se espera como resultado deste trabalho e como ele será validado e com a migração de dados não é diferente. Abaixo apresentam-se os requisitos e regras de negócio do case proposto.
Requisitos e Regras de Negócio
Neste estudo de caso iremos considerar que o diretor da “Magazine Setorial”, uma grande empresa de e-commerce, contrata os serviços de administração de dados de uma empresa especializada e explica, nos itens a seguir, as características e as necessidades do projeto:
1. Duas grandes lojas de departamento foram fundidas e a administração da nova organização será unificada;
2.A empresa “Magazine Setorial” comprou a empresa “Setorianas”. Ambas as empresaspossuem um software funcional, capaz de gerir a organização. Entretanto, asempresas gostariam de unificar seu programa de fidelização do cliente e acentralização destes dados é fundamental;
3. O sistema da empresa “Magazine Setorial” foi definido como o responsável pela gestão a partir da fusão e vai receber todos os dados do sistema da empresa “Setorianas”;
4. A estrutura de dados dos sistemas são similares, mas não idênticos;
5. O SGBDR do sistema Origem é SQL Server enquanto o do sistema Destino é o MySQL;
6. A migração de dados deve ser feita sem que o sistema da empresa “Magazine Setorial” fique inoperante, pois o e-Commerce não pode ser prejudicado;
7. O processo de migração de dados deve prever a sua execução de forma parcial, para o caso do processo ser interrompido por alguma exceção acarretada, por exemplo, por inconsistência nos dados ou falha na rede, permitindo a retomada de onde parou;
8. A base de dados do sistema Destino não aceita:
-E-mailsduplicados ou nulos para clientes;
-E-mailsduplicados ou nulos para vendedores;
-Nomes duplicados ou nulos para filiais;
-Produtos com Códigos de Barra duplicados ou nulos;
-Categoria de Produtos com nomes duplicados ou nulos.
9. Um cliente de uma empresa pode já estar cadastrado como cliente na outra, com o mesmo e-mail.
-Deveser possível emitir uma listagem destes clientes pré-existentes na base Destino.
10. O sistema Destino deverá emitir relatórios de vendas por Filial, Vendedor, Produto e Categoria do Produto, respeitando um intervalo de datas;
11. Um Vendedor pode estar alocado somente a uma Filial;
12. Respeitando o conceito de Registro Ativo (Active Record), as entidades têm como chave primária um código de autoincremento, a chamada “chave burra”;
13. É necessária a rastreabilidade dos dados, para saber o que foi migrado e qual o destino de cada informação a fim de possibilitar conferência;
14. Resumidamente, o modelo de classes dos dois sistemas pode ser representado pela Figura 1.
Figura 1. Modelo de Classesresumido do Sistema Destino, em MySQL.
Base de Dados Origem – SQL Server
Na Figura 2 é apresentado o Modelo de Entidade Relacionamento (MER ou ER) da base que armazena os dados do sistema Origem, no SGBDR SQL Server 2008 R2. Analisando a base, percebe-se que a sua estrutura é simples e a desnormalização na tabela de produtos, por exemplo, é facilmente identificável, uma vez que armazena em sua estrutura o nome, suas categoria e subcategoria. A desnormalização também pode ser visualizada na tabela cliente com o nome da cidade em sua estrutura, ao invés do código apontando para uma tabela de cidades.
Figura 2. Modelo de ER dabase Origem em SQL Server.
Base de Dados Destino – MySQL
Na Figura 3 é apresentado o Modelo de ER da base que armazena os dados do sistema Destino, no SGBDR gratuito MySQL. Analisando suas tabelas extrai-se que estas já possuem dados e foram criadas com a engine InnoDB, que permite, entre outras coisas, a integridade referencial. Percebe-se também uma base de dados bastante similar ao sistema Origem. A tabela de produto, diferentemente da base Origem, está normalizada, pois possui referência para a tabela de produtocategorias, que tem um autorrelacionamento para possibilitar a criação da árvore de categorias em vários níveis. Entretanto, a tabela cliente, assim como na base Origem, está redundando o nome da cidade. Com isso, tem-se inicialmente que não será necessário tratamento algum ao migrar essa informação.
Com essa análise prévia das bases, bem como dos requisitos e regras de negócio, é possível mensurar com assertividade o esforço que será empreendido nessa migração.
Figura 3. Modelo de ER da base Destino em MySQL.
Pentaho Data Integration (Kettle)
A migração será realizada entre SGBDRs distintos e
a utilização de uma ferramenta de Extract, Transform and Load (ETL – veja a ...
