Práticas recomendadas para redesenhar um banco de dados

Estou ciente de algumas práticas recomendadas gerais ao projetar um banco de dados para um aplicativo, mas e a reformulação?

Estou em uma equipe encarregada de redesenhar um aplicativo comercial interno, embora, apesar de eu dizer "interno", infelizmente esteja muitas, muitas camadas de pessoas afastadas do contato com os usuários reais do sistema.

O programa atual está no Oracle Forms, espalhado por várias tabelas não normalizadas, às vezes com várias tabelas quase duplicadas, mantendo pequenas variações nos dados uns dos outros. As restrições geralmente estão na forma de procedimentos armazenados mal aplicados. Mesmo os tipos não parecem estar armazenados corretamente. Encontrei todos os tipos de dados incorretos que a Oracle parece ignorar, mas deu ajustes (e com razão) ao Assistente de Importação / Exportação do SQL Server. (Por exemplo, números inteiros de dois dígitos não constituem uma data e hora completa!)

O programa original provavelmente remonta a vinte anos, e todos os desenvolvedores originais se aposentaram há tanto tempo que nem mesmo os idosos aqui têm idéia de quem eles eram. Como resultado, também não existem requisitos limpos - apenas devemos duplicar a funcionalidade do aplicativo existente e manter os dados existentes.

O resultado final da reescrita será uma versão baseada na Web em execução no ASP.NET com o MS SQL Server para o back-end.

Meus outros dois colegas de equipe de desenvolvedores são muito, muito mais velhos que eu, ambos com formação em negócios / MIS, enquanto o meu é CS. A experiência do membro sênior tem sido quase exclusivamente formulários Oracle e o outro membro fez o trabalho de aplicativos de negócios principalmente no Visual Basic. Embora meu histórico em bancos de dados tenha sido limitado ao design de novos bancos de dados para projetos no MySQL ou SQLite, principalmente para minhas aulas de graduação, pareço ser o único com experiência na criação de bancos de dados.

Eu já escrevi um pequeno programa em C # que lê todos os dados existentes em um formato neutro, pronto para ser convertido novamente e colocado em um novo banco de dados. Eu pretendo escrever o código de carregamento após o design do banco de dados de destino, para que os dados possam ser divididos corretamente nas novas tabelas normalizadas, adicionadas na ordem correta para seguir novas restrições etc. O mesmo programa pode ser executado novamente mais tarde para copiar os dados de produção para o real redesenhado final recém-implantado. Isso deixa o redesenho real do banco de dados como a principal coisa a descobrir.

Portanto, o cerne da minha pergunta: quais são algumas das práticas recomendadas para fazer uma reformulação a partir do nível do banco de dados de um aplicativo existente?

Eu acho que você já sabe como normalizar um banco de dados.

O que você precisa são estratégias para minimizar o risco ao mover todo o software para o novo banco de dados.

O que estou sugerindo é mais trabalho como compensação por menos riscos.

Normalize o banco de dados e crie um processo para preencher o banco de dados normalizado com dados do banco de dados original. O banco de dados original será o banco de dados para inserções, atualizações e exclusões. O banco de dados normalizado será o banco de dados de consulta apenas durante a conversão.

Seu processo de preenchimento precisará ser executado quantas vezes for necessário para os dados da consulta. Se dados antigos forem aceitáveis, você poderá executar um processo de preenchimento noturno. Se você precisar de dados mais atuais, precisará executar um processo de preenchimento contínuo.

Crie a parte da consulta do seu novo sistema ASP.NET, apontando para o novo banco de dados normalizado.

Os resultados da consulta do seu novo sistema devem ser comparados com os resultados da consulta do sistema original.

Você pode parar neste momento. Essa é uma decisão de negócios, não uma decisão técnica.

Ao seu lazer, você cria uma nova funcionalidade de inserção / atualização / exclusão no seu novo sistema ASP.NET. Ao criar a nova funcionalidade, você desativa as partes do sistema original que correspondem. Em algum momento, nada do sistema original permanece.

As vantagens da conversão dessa maneira estão reduzindo o risco construindo a parte da consulta primeiro. Geralmente, as funções de consulta são simples em comparação com a lógica de negócios incorporada na funcionalidade de inserção / atualização / exclusão.

Você converte a funcionalidade de inserção / atualização / exclusão, um processo por vez. Se houver algum problema com o entendimento incorreto da lógica comercial, ela poderá ser corrigida enquanto seus usuários estiverem usando o sistema original.

Não é preciso dizer que é melhor que seu processo de preenchimento seja absolutamente consistente.

Tente convencê-los a contratar o desenvolvimento do novo sistema para uma empresa externa. Existem muitas empresas de desenvolvimento boas que têm recursos para desenvolver aplicativos de maneira mais rápida e melhor do que sua equipe limitada. Uma boa empresa de desenvolvimento também poderá forçar seus superiores a fazer coisas que eles não podem fazer se você solicitar, o gerente da empresa que está sendo pago muito dinheiro para desenvolver um aplicativo tem muito mais atratividade para envolver o usuário do que o cara da TI muitos níveis abaixo da autoridade de gerenciamento para organizar essas coisas.

Custa muito dinheiro adiantado, mas valerá muito a pena ter os recursos adequados para desenvolvimento e implementação. Se você conseguir fazer uma solicitação de proposta, aposto que os lances recebidos indicam que o que você está tentando fazer é muito mais complicado do que seus gerentes imaginam.

Projete o banco de dados normalizado necessário com os tipos de dados necessários. Então a parte mais difícil é migrar os dados. Primeiro, você precisa ter um plano para mapear do antigo para o novo e o que fará com os dados que não atendem à nova estrutura. Por exemplo, você pode ter dados que agora não são identificáveis ​​se você não tiver restrições de integridade adequadas. Você pode simplesmente não mover esses dados ou pode precisar movê-los, mas anexá-los a um novo registro pai chamado "Desconhecido". Se uma data não é realmente uma data real, você pode colocar um nulo no campo ao migrar? Você precisará de respostas para esses tipos de perguntas. Sugiro que alguns dos desenvolvedores trabalhem na alteração da interface gráfica para usar a nova estrutura de banco de dados e outros para trabalhar estritamente na migração. A migração é uma tarefa enorme, é preciso muita habilidade e muito tempo. Não deixe como uma reflexão tardia.

Como você está usando o SQL Server, você pode fazer a migração real através do SSIS.

Crie um bom conjunto sólido de casos de teste para poder comparar os resultados com o sistema antigo e os mesmos com o novo sistema.

Como você tem muitos anos de dados, convém migrar em duas partes. Primeiro migre a maioria dos dados e, quando chegar a hora de entrar no ar, migre apenas os dados alterados. É claro que você precisaria colocar controles no banco de dados para encontrar dados alterados que você ainda não possui. Você também pode considerar neste momento se desejar arquivar alguns dados.

Sou confrontado com a reformulação do esquema do banco de dados quase diariamente devido ao suporte e desenvolvimento de vários aplicativos herdados que nasceram como arquivos do MS Access (.mdb) e, em seguida, cresci em grandes bancos de dados com várias centenas de tabelas agora localizadas no MS SQL Servidor, mas ainda tendo a "criança falecida" do design original. Aqui estão algumas práticas que achei úteis para mim:

Tente minimizar a superfície disponível publicamente do seu esquema de banco de dados.

Isso significa que você deve tentar criar alguma API pública que você disponibiliza para aplicativos externos. Normalmente, tento implementar os dados estáticos como visualizações (mesmo que sejam baseados apenas em uma única tabela) e dados dinâmicos como visualizações parametrizadas ou como procedimentos armazenados. Para consultas de dados em que apenas um único valor é suficiente, também é possível usar funções escalares.

Somente esses (visualizações, procedimentos armazenados e funções escalares) são visíveis para aplicativos externos (via ORM ou diretamente) e usados ​​para todas as operações CRUD. Esse esquema é congelado completamente, enquanto internamente você pode alterar as tabelas subjacentes, melhorar seus procedimentos etc. - isso não prejudica a compatibilidade com seu aplicativo.

Tente otimizar para os critérios do mundo real, não para os livros.

A normalização é um grande tópico em todos os livros sobre design de banco de dados. Mas, na vida real, há casos em que a normalização não causa muita desaceleração no banco de dados, por exemplo, se você repetir alguns dados, mas a porcentagem de repetições é muito baixa etc. Não sou contra a normalização, o que estou tentando dizer aqui é que você precisa enfrentá-lo com algum ceticismo e prudência.

Grave a sessão de criação de perfil e analise-a.

O design novo do banco de dados com base apenas no esquema do banco de dados não foi concluído. Observe o seu banco de dados em sua dinâmica, tente encontrar os gargalos durante os testes de carga e resolvê-los. No caso do MS SQL Server, há um Tuning Advisor especial que pode gerar algumas recomendações no rastreamento de atividade registrado.

Aqui está a minha resposta:

1. Primeiro, entenda o sistema de banco de dados atual o máximo que puder. Você precisa conhecer todos os usos desses sistemas, bem como os usuários. Você precisa conhecer todas as fontes do sistema, bem como os sistemas que possam estar servindo como sistema de origem.

2. Você precisa identificar todos os diferentes usos do sistema, seja para operacional ou para relatórios ou ambos. Identifique os aplicativos e o sistema upstream que pode estar usando o banco de dados. Ao fazer isso, você conhecerá os elementos do banco de dados atual que estão obsoletos e não são mais necessários.

3. Também analise e entenda o processo ETL atual que carrega dados no banco de dados e extrai dados do banco de dados.

4. Entenda todos os elementos de dados do banco de dados e se você pode criar uma matriz de caixa que pode ajudá-lo a identificar elementos duplicados.

5. Depois de obter todas as informações, é possível abordar o redesenho como se estivesse projetando o banco de dados pela primeira vez com as informações coletadas como parte da coleta de requisitos.

6. Boa sorte!