Migração de dados utilizando Pentaho Data Integration - Revista SQL Magazine 106

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.

" [...] continue lendo...