Ao escrever uma postagem no blog sobre modelagem de banco de dados, você deve estar preparado para que seu modelo abstrato não atenda às necessidades da maioria dos leitores. A razão é simples. Os modelos de banco de dados da vida real geralmente são criados em estreita relação com requisitos específicos de negócios e desenvolvimento, enquanto os modelos de blog não são.
Nas últimas semanas, tenho escrito postagens no blog sobre a criação de modelos de banco de dados. Os tópicos variaram de uma abordagem geral para modelagem de banco de dados por meio de um simples fórum online a um modelo para uma pesquisa online mais complexa.
Para cada modelo de banco de dados que crio, tento entender claramente o domínio do negócio e elaborar em minha mente o quadro geral do modelo.
O desafio do desenvolvimento de banco de dados abstrato
Normalmente, como solução arquiteto , eu pego requisitos de negócios específicos e os converto em detalhes técnicos do que precisa ser criado do lado técnico:traduzindo da linguagem de negócios para a linguagem técnica – projetando os algoritmos em alto nível e modelando os requisitos de dados para os algoritmos.
Infelizmente, não posso blogar sobre os modelos de banco de dados do mundo real que crio no trabalho. Por um lado, eles são muito específicos para o domínio dos negócios e por outro estou restrito por acordos de confidencialidade. Para o blog, crio um puramente abstrato conceito sem requisitos de negócios específicos, exceto aqueles que imagino existirem dentro do domínio de negócios. Agora, tudo bem; Tenho uma imaginação muito boa e aponto com frequência que suas necessidades podem ser diferentes quando descrevo as escolhas que estou fazendo. Mas esse processo de blog me fez pensar em como esse processo é diferente de criar os modelos em um projeto real.
O Processo de Desenvolvimento da Vida Real
Em uma situação real, eu trabalharia em estreita colaboração com a equipe de desenvolvimento depois de criar a solução de alto nível e o design técnico em um interativo para que o modelo se ajuste às necessidades de desenvolvimento.
Os desenvolvedores podem reclamar que o modelo de dados é muito normalizado para oferecer suporte a alto desempenho ou podem solicitar normalização adicional em determinadas áreas. Se alguma Chave Alternativa estivesse faltando, os desenvolvedores reclamariam rapidamente e também notávamos isso durante o teste de desempenho do banco de dados.
Consideraríamos quais deveriam ser os comprimentos de campo exatos com base no comprimento máximo dos dados a serem armazenados e nos designs de telas para entrada e exibição dos dados. É claro que os comprimentos de campo exatos em um modelo de banco de dados conceitual não são importantes.
Trabalharíamos com exemplos de quais dados serão armazenados nas tabelas e como serão usados pelo aplicativo, além de criar scripts para pré-preencher as tabelas para teste de unidade do aplicativo. Dessa forma, pegaríamos os casos de canto para garantir que o modelo suporte os limites do aplicativo.
Então, basicamente, massageamos o modelo até que ele realmente suporte os requisitos de negócios e não funcionais do sistema usando um processo iterativo até que tenhamos evoluído um modelo para algo que todos possamos aceitar, apesar dos compromissos embutidos nele.
Como eu disse, seria um processo muito iterativo que poderia continuar por muitos meses enquanto o código do aplicativo, as interfaces do usuário e as interfaces do aplicativo estivessem sendo desenvolvidas.
Limitações do feedback bem-intencionado
Na situação atual dos blogs, embora meu número reconhecidamente limitado de leitores me forneça feedback sobre questões e desafios que eles observam com os modelos, é necessariamente superficial. Duvido que algum dos leitores esteja usando diretamente os modelos para criar um aplicativo e descobrir o que realmente funciona e onde há problemas.
Portanto, os comentários como “modelo mal pensado” quase certamente estão certos. Por outro lado, “faltam FKs” são bastante precisos, mas espero ter explicado no texto do artigo por que estou incluindo uma chave estrangeira ou não.
Conclusão
Agora, por favor, não leia este post como uma reclamação ou comentário sobre o feedback que os leitores estão fazendo, mas estou refletindo sobre a dificuldade de fazer um modelo de banco de dados quando você não está em um ambiente que permite uma troca interativa com um processo de desenvolvimento.
Provavelmente existem outras situações em que os modeladores de banco de dados são excluídos do processo de desenvolvimento, mas agora percebi o quão perigoso isso seria e quão propenso a problemas eles seriam.
Você pode imaginar um modelo de banco de dados que nunca é alterado? Nunca um único ajuste de uma coluna, nunca a adição de uma chave estrangeira, nunca a necessidade de uma nova tabela. Sinceramente, a única situação que consigo imaginar assim é quando o aplicativo que usa o banco de dados não está mais evoluindo e chegou a um beco sem saída:fim de vida.
