Melhor forma de converter base de dados de um sistema?

cara recetemente fiz uma integração dessas, de um sistema em cobol para oracle e ainda estamos fazendo, mas ja estamos quase no final, so tenho a te dizer. ta fudido!

a solucao que utilizamos foi fazer um programa que envia e recebe os dados durante a noite, como os modulos migrados estao totalmente separados foi possivel fazer isso, nao sei como sera o seu caso.

boa sorte! xD

A idéia é ir usando o banco de dados deles saca ? Pq assim a empresa não para, entende ? Assim podemos ir usando o banco de dados deles, no caso inserindo com nosso sistema no banco de dados deles até q o nosso esteja pronto e depois assim migrar totalmente.
Pra isso, estou procurando uma ferramenta q mostre quais tabelas foram usadas numa transação qualquer de Insert/Update/Delete/Select…Assim daria pra saber quais tabelas foram usadas no Select e ainda em quais foram gravadas as informações.
Seria algo assim, acredito eu que seria a melhor opção para se trabalhar agora no inicio, não sei se teria solução melhor mas acredito que não, pois converter iria parar a empresa totalmente o q é impossivel.

Tem alguma ferramenta que mostra as tabelas que estão recebendo Insert/Update/Delete e Select ???

obrigado

Olá amigo, dê uma olhada nesse arquivo, acho que pode te ajudar.
http://blog.sqlauthority.com/2008/01/03/sql-server-2005-last-ran-query-recently-ran-query/

Experiência própria: evite ao máximo substituir este ERP. Sempre da tragédia. O melhor argumento a favor deste fato é este artigo do Joel Spoolsky: http://www.joelonsoftware.com/articles/fog0000000069.html

Use a seguinte estratégia: conforme novos módulos forem sendo necessários, implemente-os em qualquer coisa FORA deste ERP. Conforme os módulos antigos do ERP forem caindo em desuso, vá substituindo-os também. É importante lembrar que normalmente em sistemas legados há uma verdadeira odisséia de regras de negócio embutidas em interface gráfica, relatórios, etc que difícilmente você vai conseguir extrair.

Com relação a descobrir quais as tabelas mais usadas, se não me engano o SQL Server tem um log que, uma vez habilitado, diz quais as consultas mais frequentes. Ai é pá-pum, você já vai saber mais ou menos aonde atacar.

kicolobo:

Experiência própria: evite ao máximo substituir este ERP. Sempre da tragédia. O melhor argumento a favor deste fato é este artigo do Joel Spoolsky: http://www.joelonsoftware.com/articles/fog0000000069.html

Use a seguinte estratégia: conforme novos módulos forem sendo necessários, implemente-os em qualquer coisa FORA deste ERP. Conforme os módulos antigos do ERP forem caindo em desuso, vá substituindo-os também. É importante lembrar que normalmente em sistemas legados há uma verdadeira odisséia de regras de negócio embutidas em interface gráfica, relatórios, etc que difícilmente você vai conseguir extrair.

Com relação a descobrir quais as tabelas mais usadas, se não me engano o SQL Server tem um log que, uma vez habilitado, diz quais as consultas mais frequentes. Ai é pá-pum, você já vai saber mais ou menos aonde atacar.

realmente é uma odisséia…kk !!! tenso d++ !
e ainda vc pega um banco de dados modelado de uma maneira toda proprietaria ai ja viu, é pano pra manga…kk !

mas to na pesquisa de qual seria a melhor forma.

muito obrigado.

Oi Fernando, nossa cara não entendo essas atitudes do tipo:

se você tivesse o modelo ER seria tudo diferente bastaria fazer uma analise bem grande do sistema antigo na parte de modelagem mesmo, até mesmo se pudesse conversar com quem o projetou, ver os dados que são realmente relevantes, como as partes de todos os cadastros, a parte de notas, entradas, saidas, terceiros e bla bla bla… e trazer só o que realmente importa, o banco ainda tem problemas de relacionamento entre as entidades, pois se o único problema fosse os nomes pouco intuitivos você poderia construir seu ERP baseado na estrutura do banco atual apenas alterando os nomes dos mapemantos das entidades na aplicação web, assim você manteria uma compatibilidade entre o sistema antigo e o novo, a dificuldade que o pessoal encontra em criar modulos novos deve ser devido as limitações da propria linguagem que foi utilizada, sabemos o que é um ERP completo, mas é um desafio bem interessante, aqui na empresa migramos um ERP CLIPPER para Java estamos concluindo com 1 ano de desenvolvimento, a sorte que o ERP antigo havia sido escrito pela própria empresa que trabalho a 20 anos atras, motivo fundamental pelo nosso sucesso em concluir, pois tinhampos toda documentação necessaria.

bom tem o SQL Server Management Studio que você ja deve conhecer, nele vejo tudo que rola.

acredito que a conversão tenha que ser braçal mesmo, eu contruiria um programa para fazer isto pra min, mas isto depende de conhecer a modelagem do sistema antigo.

no sql server tem as sp who e who2. Basta rodar um desses dois comandos e ver a saída.

Sobre migrar, recomendo fazer da seguinte forma (já fiz algumas migrações, e provavelmente vou falar muita coisa aqui que você já sabe):

1. Antes de mais nada, estabeleça uma estratégia para organizar a ordem de criação dos módulos, de preferência, os módulos que você não tem no outro ERP primeiro.
2. Seguindo essa ordem, você só coloca em produção, em paralelo ao outro ERP, quando o módulo já estiver bem testado.
3. Estabeleça uma rotina de ETL do sistema novo para o sistema antigo, mas de forma que fique bem testado antes de colocar em produção, e em determinados horários do dia essa rotina “execute” o processo ETL e transfira a informação do novo para o antigo, criando um log de quantidade de linhas transformadas, quantidade de linhas lidas da origem e quantidade de linhas inseridas no destino para cada tabela/módulo/magnitude, ao final do dia sempre conferindo esses logs. Recomendo como ferramenta ETL gratuita o Kettle, uso bastante essa ferramenta e é muito boa. (procure sempre versões Stable, versões non-stable pode funcionar legal em uma máquina e ruim em outra com a mesma transformação dependendo da JVM, já tive problemas de em ambiente de testes funcionar perfeito e em produção mudar valores do nada)
4. Crie uma rotina para comparar os dados entre as bases de dados, por exemplo, relatórios agregados de somas de valores, contagens de registros, etc… E comparar esses resultados todos os dias, fazer um checklist de todas as variáveis do sistema e comparar os valores dado um instante temporal, sempre cogitando também que no sistema antigo pode não estar 100% (mas a chance de não estar 100% é pequena), portanto, se tiver algum dado estranho no sistema legado, converse com os administradores para entender bem se é assim mesmo ou se tem algo errado (já encontrei muitos erros em bases de dados legado, que o sistema não fazia a lógica de negócios direito, ou fazia incompleta).
5. Dependendo do tamanho do sistema, deixe pelo menos 1 ano rodando em paralelo, muitas características do negócio do cliente é sazonal, e muitos recursos são voltados para datas específicas.

Esqueci de dizer uma coisa, a própria empresa que construiu o sistema legado pode te ajudar a migrar esses dados, pois os dados são da empresa, eles não precisam te passar o modelo ER, mas precisam colocar (desde que paguem as taxas equivalentes) os dados num formato que vocês possam entender.

Esse é um dos problemas, a empresa q fez o ERP não tem a obrigação de nos ajudar até mesmo pq a idéia é abandonar essa empresa entende ?
Com certeza não irão passar a estrutura e muito menos o modelo ER do banco, estou dando uma analisada nas tabelas e realmente é muito complicado de entender, estou ainda na letra F por exemplo F0013(isso é nome de tabela) kkk !!! affs…Até agora achei mais de 50 tabelas q não possuem nenhuma informação(acredito serem não usadas ou com informações temporarias), umas tabelas q possuem os mesmos dados q outras e outras tabelas q tem mais de 5 ou 10PK…affs !!! Estranho d++. Ainda me falta mais de 1000 tabelas para olhar. aff duplo. kk !

Com o SQLServer Management Studio da pra saber as tabelas q receberam INSERT/UPDATE/DELETE e as q foram consultadas num SELECT ? Vou dar uma fuçada aqui pra ver se encontro onde fica isso no SSMS.

Entaum como não podemos ainda abandonar esse ERP pois a empresa(industria) precisa disso para funcionar, estamos procurando uma solução para continuar usando o banco de dados deles e em paralelo ir criando o nosso próprio, mas o primordial agora é saber em quais tabelas por exemplo o “Movimento de Baixa” é inserido e em quais tabelas ele pega os codigos por exemplo contas, bancos, movimentos etc…entende ?

Pra isso é q preciso encontrar uma ferramenta q me mostre a tabela q levou um INSERT qdo faço a baixa, e quais tabelas levaram o SELECT qdo pego por exemplo o Codigo da Conta. Assim da pra saber e ter nocao de onde se deve pegar e gravar as informacoes.

Meu 2012 ja vai começar bem…affs !!! Muita fé em Deus. kk.

obrigado.

bom, normalmente, o contrato de prestação de serviços referente a um software interno, diz que os dados são de propriedade da empresa, e ainda as prestadoras de serviço devem fornecer os dados quando requisitados. Mas vou dar sugestões sobre como você pode mapear as informações (já passei por situações em que eles dificultavam em passar a informação, assim como você está passando):

1. Procure quais as tabelas que possuem mais registros, essas costumam ser as tabelas “completas”. As outras costumam ser tabelas com informações agregadas para otimizar a performance. (mas atenção, as vezes tem tabelas que são junções de duas outras tabelas, contendo filtros limitando regras de negócios. ). Tente entender primeiro as tabelas com maior quantidade de linhas. Aproveite e crie listas de perguntas para os fornecedores do ERP, se eles estiverem relutantes em dizer para que servem as tabelas, pode dizer a eles que quer algum relatório específico e que virão outros relatórios semelhantes mas não iguais, que você precisa saber esse módulo inteiro para conseguir aplicar as regras de negócio para extrair as informações.
2. crie “grupos” de tabelas por palavras “chave” no nome. Por exemplo, você marca como baixa (talvez de clientes), a regra de negócios pode indicar como movimento de clientes (altas + baixas). Tabelas que contém a mesma informação você pode buscar as regras de negócio que tornam os valores equivalentes entre as duas tabelas. Em geral, tendo agrupado tabelas com de acordo com palavras chave no nome não precisa conhecer todas as tabelas do sistema, quando você fizer engenharia reversa (por exemplo, SQL Power Architect faz engenharia reversa e te desenha o ER para vc, bem como o SQuireL). Olhando somente esses grupos fica mais fácil entender o relacionamento entre elas.
3. Procure os módulos mais importantes e que se relacionam com as outras tabelas primeiro(por exemplo, clientes, produtos, etc…) e veja as PK e FK dessas tabelas.

Nunca vi um SGBD que permitisse mais de uma PK numa única tabela.

O Sql Server tem uma ferramenta chamada Profiler que mostra todos os comandos que o banco está recebendo.
Com ela acredito conseguirá mapear quais tabelas são afetadas por cada tela/funcionalidade.

Sobre a migração, conforme recomendado, vá comendo pelas beiradas.
Implemente funcionalidades que precisa e o ERP não tem, as que dão mais problemas, as piores de se usar.
Provavelmente nunca terminará de migrar o sistema todo (talvez nem valha a pena).

evefuji:

no sql server tem as sp who e who2. Basta rodar um desses dois comandos e ver a saída.

Sobre migrar, recomendo fazer da seguinte forma (já fiz algumas migrações, e provavelmente vou falar muita coisa aqui que você já sabe):

1. Antes de mais nada, estabeleça uma estratégia para organizar a ordem de criação dos módulos, de preferência, os módulos que você não tem no outro ERP primeiro.
2. Seguindo essa ordem, você só coloca em produção, em paralelo ao outro ERP, quando o módulo já estiver bem testado.
3. Estabeleça uma rotina de ETL do sistema novo para o sistema antigo, mas de forma que fique bem testado antes de colocar em produção, e em determinados horários do dia essa rotina “execute” o processo ETL e transfira a informação do novo para o antigo, criando um log de quantidade de linhas transformadas, quantidade de linhas lidas da origem e quantidade de linhas inseridas no destino para cada tabela/módulo/magnitude, ao final do dia sempre conferindo esses logs. Recomendo como ferramenta ETL gratuita o Kettle, uso bastante essa ferramenta e é muito boa. (procure sempre versões Stable, versões non-stable pode funcionar legal em uma máquina e ruim em outra com a mesma transformação dependendo da JVM, já tive problemas de em ambiente de testes funcionar perfeito e em produção mudar valores do nada)
4. Crie uma rotina para comparar os dados entre as bases de dados, por exemplo, relatórios agregados de somas de valores, contagens de registros, etc… E comparar esses resultados todos os dias, fazer um checklist de todas as variáveis do sistema e comparar os valores dado um instante temporal, sempre cogitando também que no sistema antigo pode não estar 100% (mas a chance de não estar 100% é pequena), portanto, se tiver algum dado estranho no sistema legado, converse com os administradores para entender bem se é assim mesmo ou se tem algo errado (já encontrei muitos erros em bases de dados legado, que o sistema não fazia a lógica de negócios direito, ou fazia incompleta).
5. Dependendo do tamanho do sistema, deixe pelo menos 1 ano rodando em paralelo, muitas características do negócio do cliente é sazonal, e muitos recursos são voltados para datas específicas.

Também já realizei migrações de sistemas, mais recentemente de um sistema desenvolvido em Delphi com banco de dados FireBird para o sistema da TOTVS utilizando base de dados SQL Server, cujo nome é Microsiga Protheus. E nesse sistema da Microsiga, não sei se todos conhecem; com ele podemos customizar o sistema e adicionar novas implementações utilizando uma linguagem própria da empresa TOTVS, ADVPL. Customizamos alguns módulos desse software. Após realizar as customizações, testamos e colocamos em paralelo ao sistema ERP da empresa desenvolvido em Delphi, para avaliar os resultados. Após todos os dados estarem corretos no sistema da Microsiga é que abandonamos o sistema antigo.
Faça muito teste, mas vários testes mesmo, antes de implantar um sistema novo se possível rode o sistema pelo menos 1 ano em paralelo

Apesar de o post ser bem antigo. Esses dias precisei migrar de cobol e pesquisei bastante até encontrar o aplicativo desse site www.fullcopyconvert.com.br me ajudou e muito. Resolvi postar aqui para ajudar para quem precisar.

Na boa, todas as suas mensagens foram pra indicar esse troço aí…

http://www.guj.com.br/posts/listByUser/159030.java

Já deu, né?