Limpeza e migração de banco de dados Access para Microsoft SQL Server - Parte 1

Todo mundo que faz alguma coisa com bancos de dados, especialmente os produtos da Microsoft, vai acabar em um trabalho ou cliente, onde o Microsoft Access está sendo usado para algum banco de dados de missão crítica e que não foi devidamente projetado ou mantido. Não me interpretem mal, eu gosto de Microsoft Access e achar que é muito poderoso e estável para usar quando o banco de dados é projetado corretamente. Mas eu também acredito que o aplicativo de banco de dados atinge um determinado tamanho ou complexidade, onde poderia se beneficiar de migração para o SQL Server.

Atualmente, estou enfrentando esse problema. Eu herdei uma aplicação de banco de dados contábil que estava cheio de lixo e insetos. Os dados era suspeito e todo mundo tinha medo de tocá-lo. Só para dar uma idéia do que estamos tratando, o banco de dados contém: 349 mesas (sem relações de tabela em todos), 1.569 consultas, 427 macros, 312 relatórios e mais de 50 centrais. Esta é uma aplicação de banco de dados para processamento de contas a pagar, a receber, folha de pagamento e não algo usado para decodificar DNA!

Agora que você sabe o lixo que estamos lidando com você não pode considerar a sua fossa de um banco de dados tão ruim. Então, para as coisas boas.

Parte 1 - Quando eu começo??

A primeira coisa que você precisa fazer é documentar todos os objetos no banco de dados e como, em respeito a todos os outros. Isso parece difícil, e pode ser, mas é necessário para você entender como funciona cada peça antes que você possa começar a remover o lixo. Se o seu banco de dados usa um painel de comando e tem um complicado, eu recomendaria também gerar um diagrama que mostra todos os menus que os usuários realmente acessar.

Eu recomendo usar um produto pela FMS incorporado chamado Analisador Acesso Total. Ele analisa um banco de dados e cria documentação sobre todos os objetos. Esta documentação inclui objetos que fazem referência cruzada com outros objetos que os utilizam. A versão que eu tinha usado um problema. Não parecia a verificar o quadro de tabela de itens quando foi construir referências cruzadas, de modo que alguns itens não podem ser cruzados corretamente. Isso pode ter sido um problema de minha própria criação, ou talvez não, eu não tenho certeza. De qualquer forma, o uso do produto é me 90% do caminho documentada. Os outros 10% eu fiz com a mão, criando o diagrama dos itens telefonistas que as pessoas realmente utilizados.

Agora que eu tinha o doumentation eu poderia começar a gerar uma lista de itens potencialmente não utilizados. Comecei listando todos os itens que estavam no diagrama dos itens telefonistas usados ​​como "produção" itens. Eu, então, verificou a documentação Analyzer Total Access gerado e adicionado os itens que cruzam referenciados os itens a partir do quadro. Por exemplo, se o quadro abriu um relatório específico, o Analisador Total Access também lista a consulta que fornece os dados para esse relatório, sob a referência cruzada. Se você começar a seguir todas as referências que você pode encontrar uma cadeia de itens que estão relacionados uns aos outros, mas não têm relação com o resto da aplicação mais. Anote todos esses itens. Não se preocupe se você não levá-los todos na primeira vez, você vai fazer um passe mais finos sobre o banco de dados como você analisar os processos de negócios que usam o aplicativo e como eles funcionam juntos.

Faça uma cópia de desenvolvimento de banco de dados. Remova os itens da sua cópia de desenvolvimento e verificar se o aplicativo ainda funciona como o esperado. Já um dos usuários do aplicativo reais testar seu banco de dados. Repita esse processo até que você sinta satisfeito que você tenha removido tudo o que atualmente pode ser removido.

Na próxima parte, vamos começar a olhar para a análise de processos de negócios e garantir a funcionalidade do aplicativo se adapta ao processo de negócio ... não o contrário....