Ao longo dos anos, trabalhando como modelador de dados e arquiteto de banco de dados, percebi que existem algumas regras que devem ser seguidas durante a modelagem e desenvolvimento de dados. Aqui eu descrevo algumas dicas na esperança de que eles possam ajudá-lo. Listei as dicas na ordem em que ocorrem durante o ciclo de vida do projeto, em vez de listá-las por importância ou por quão comuns são.
1. Planeje com antecedência
Não planejar é planejar falhar.
Alan Lakein
Um problema que tenho visto é quando a modelagem de dados ocorre ao mesmo tempo que o desenvolvimento de software. Isso é como construir a base antes de completar os projetos. No passado, o planejamento parecia um passo óbvio antes de iniciar o desenvolvimento. As equipes de desenvolvimento não criariam bancos de dados sem planejamento, assim como os arquitetos não construiriam edifícios sem plantas.
No desenvolvimento de aplicativos, é fundamental entender a natureza dos dados.
O planejamento é frequentemente ignorado para que os desenvolvedores possam apenas “começar a codificar”. O projeto começa e quando surgem problemas, não há folga no cronograma para resolvê-los. Os desenvolvedores usam atalhos com a intenção de corrigi-los mais tarde, mas isso raramente acontece.
O planejamento cuidadoso é como garantir que você tenha um banco de dados adequado que não seja invadido. Se você não gastar tempo e esforço antecipadamente tratando dos dados exigidos pelos processos, pagará por isso mais tarde com um banco de dados que deve ser retrabalhado, substituído ou descartado.
Mesmo que o planejamento nem sempre seja feito, muitos modeladores de dados ainda seguem essas diretrizes. Isso não quer dizer que podemos prever todas as necessidades de design com antecedência, mas a maioria dos modeladores acredita que vale a pena o esforço para entender os dados e seu uso. Você não gostaria de um design para processamento de transações quando a necessidade é a criação de relatórios analíticos.
Os tempos mudaram; As metodologias ágeis são mais prevalentes, portanto, as equipes de banco de dados devem repensar sua abordagem à modelagem de dados. No Agile, o Modelo de Domínio de Casos de Uso é usado em vez de Diagramas de Relacionamento de Entidade. No entanto, a necessidade de planejamento não diminuiu. Precisamos entender os dados e o que eles devem fazer. Em geral, os primeiros Sprints devem se concentrar no design de dados.
Portanto, não é Agile que é o problema para modeladores de banco de dados, mas sim indivíduos que não entendem a natureza dos dados. Alguns vêem o desenvolvimento de banco de dados como o mesmo que desenvolvimento de aplicativos. A modelagem de banco de dados e o desenvolvimento de software são diferentes e precisam de foco adequado.
O banco de dados é o núcleo da maioria dos aplicativos de software. Você deve dedicar um tempo para analisar os requisitos e como o modelo de dados os atenderá. Isso diminui a chance de o desenvolvimento perder o rumo e a direção.
Os desenvolvedores devem entender a importância dos dados e sua contribuição para o processo de desenvolvimento. Vivemos na era da informação. Os aplicativos exibem e manipulam dados. São as informações contidas nos dados que dão sentido à aplicação.
Não é possível prever todos os requisitos nem todos os problemas, mas é importante se preparar para os problemas por meio de um planejamento cuidadoso.
2. Documente seu modelo
Ao fazer um modelo de dados, tudo parece óbvio. Você nomeia os objetos para que seu propósito seja evidente e todos entendam o significado apenas lendo o nome. Isso pode ser verdade, mas não é tão óbvio quanto você imagina. Ao escolher nomes para tabelas e colunas, deixe claro qual será o uso de cada objeto. Com o tempo, o significado dos objetos não ficará claro sem documentação.
Usar uma convenção de nomenclatura é um passo para uma documentação eficaz. Quando você precisar fazer alterações no futuro, apreciará qualquer documentação existente. Um documento curto e simples que descreve as decisões que você tomou e descreve o projeto ajudará a explicar a escolha do projeto naquele momento.
Você quer documentação suficiente para que o banco de dados possa ser gerenciado por um novo administrador e eles possam entender o significado sem precisar retornar a você para obter explicações. Se o modelo de dados e o ambiente não estiverem documentados, é difícil mantê-los ou alterá-los à medida que os requisitos mudam.
Até certo ponto, a documentação tem pouco a ver com a modelagem de dados. A documentação é sobre comunicar o design e torná-lo compreensível no futuro.
A documentação é muitas vezes uma reflexão tardia. Quando os cronogramas são curtos, a documentação é ignorada. Ainda assim, trata-se de uma dívida técnica de alto custo. Cortar cantos durante o ciclo de desenvolvimento irá acumular custos no futuro para alterações de banco de dados, identificação de problemas, rastreamento de bugs e para entender o modelo de dados e a natureza dos dados.
Como exemplo, os modelos de dados geralmente têm um campo “ID” como chave primária para uma tabela ou parte do nome de uma chave. Pode ser uma chave primária como
TransactionID na Transaction tabela. Se algumas tabelas usam “Número” como parte do nome de uma chave, é bom documentar o motivo. Talvez ReferenceNumber é usado como o nome da chave primária na Mensagem porque é assim que a referência é chamada na área de negócios. Por exemplo, em serviços financeiros, as mensagens financeiras geralmente incluem um número de referência. Documente a definição de tabelas, colunas e relacionamentos para que os programadores possam acessar as informações. A documentação deve descrever as expectativas da estrutura do banco de dados.
Na ferramenta Vertabelo, posso incluir imediatamente comentários em qualquer item:tabelas, colunas, referências, chaves alternativas, o que significa que a documentação é armazenada imediatamente com meu modelo e não em algum documento extra a ser mantido separadamente.
Documentação pobre ou ausente é muitas vezes devido ao pensamento míope, mas não ignore sua importância. Esta ainda é uma questão a ser abordada.
3. Siga as convenções
As convenções de nomenclatura podem não parecer importantes durante o design. Na realidade, os nomes fornecem o insight para entender um modelo. Eles são uma introdução e devem ser lógicos.
A nomenclatura inconsistente não serve para nada. Isso apenas frustra os desenvolvedores que precisam acessar os dados, os administradores do banco de dados e os modeladores que precisam fazer alterações no futuro.
Quando “ID” é usado para algumas chaves artificiais, mas algumas tabelas usam uma convenção de nomenclatura diferente (como Número), desenvolvedores, analistas e DBAs podem perder tempo para entender as exceções. Convenções de nomenclatura fracas também levam a erros no desenvolvimento porque a nomenclatura não é consistente.
De mãos dadas com a documentação, usar uma convenção de nomenclatura faz com que no futuro alguém entenda o modelo. Não alterne aleatoriamente entre o uso de “ID” (como
CustomerID ) e “Número” (AccountNumber ) como chaves para tabelas. Apenas faça exceções às convenções quando elas forem justificadas. Documente qual é a exceção e por que a convenção não é respeitada. O mesmo se aplica a nomes enigmáticos como “XRT1” – são as tabelas de referência estendidas? Seu palpite é tão bom quanto o meu. Espero que o designer saiba por que escolheu um nome tão enigmático, mas duvido que a próxima pessoa a acessar o banco de dados possa adivinhar o motivo.
As convenções de nomenclatura são uma questão de escolha pessoal. Certifique-se de que as decisões sejam consistentes e documentadas.
Se eu consegui convencê-lo a aplicar a convenção de nomenclatura em seu design de banco de dados, sinta-se à vontade para ler meu próximo artigo inteiramente dedicado a esse assunto.
4. Pense com cuidado nas chaves
As chaves geralmente geram controvérsia:chaves primárias, chaves estrangeiras e chaves artificiais. As tabelas precisam de uma chave primária que identifique cada linha. A arte é decidir quais colunas devem fazer parte da chave primária e quais valores incluir.
Para normalização adequada, cada tabela precisa de uma chave de identificação. A exclusividade deve ser garantida. No entanto, chaves naturais e chaves primárias não precisam ser iguais. Na verdade, eles podem não ser, desde que a tabela tenha uma chave natural.
Alguns modeladores de dados preferem uma chave artificial para exclusividade. No entanto, alguns modeladores preferem uma chave natural para garantir a integridade dos dados.
Então, devemos usar uma chave natural como chave primária? Um desafio surge se a chave natural deve ser alterada. Se a chave natural consistir em muitas colunas, pode ser necessário fazer alterações em vários lugares. Outro desafio é usar uma chave artificial como única chave para uma tabela.
Como exemplo, você pode ter uma tabela armazenando informações sobre produtos. A tabela pode ser definida com uma chave artificial como uma sequência, um código para o nome alfabético curto do produto e a definição do produto. Se a exclusividade for garantida apenas pela chave artificial, pode haver duas linhas com o mesmo código de produto. Este é o mesmo produto que é inserido duas vezes? Talvez uma chave com o código do produto seja mais apropriada.
5. Use as verificações de integridade com cuidado
Para garantir a integridade dos dados, precisamos de chaves estrangeiras e restrições. Tenha cuidado para não usar demais ou subutilizar essas verificações de integridade.
As tabelas de domínio são eficazes para impor a integridade. As tabelas de domínio funcionam bem quando há muitos valores a serem verificados ou os valores a serem verificados mudam com frequência.
Um problema pode ser que os desenvolvedores decidam que o aplicativo verificará a integridade. A questão aqui é que um banco de dados central pode ser acessado por muitos aplicativos. Além disso, você geralmente deseja proteger os dados onde eles estão:no banco de dados.
Se os valores possíveis estiverem limitados ou em um intervalo, uma restrição de verificação pode ser preferível. Digamos que as mensagens sejam definidas como Incoming ou Outgoing, caso em que não há necessidade de uma chave estrangeira. Mas, para algo como moedas válidas, embora possam parecer estáticas, elas realmente mudam de tempos em tempos. Os países aderem a uma união monetária e as moedas mudam.
Os aplicativos também devem realizar verificações de integridade, mas não dependem apenas do aplicativo para verificação de integridade. Definir regras de integridade no banco de dados garante que essas regras nunca sejam violadas. Desta forma, os dados satisfazem sempre as regras de integridade definidas.
6. Não se esqueça dos índices em seu design
Algum design de indexação é útil durante a modelagem do banco de dados, mesmo que os índices possam ser alterados durante a implantação e o uso reais. Claro, é possível ter muitos índices, assim como é possível ter poucos.
A indexação é um processo contínuo. Durante o projeto, você inicia o processo em seu modelo. O trabalho de design está nas chaves primárias e restrições.
Os índices são importantes ao considerar consultas nos dados. Ao modelar, você deve considerar como os dados serão consultados. Tome cuidado para não indexar em excesso. A indexação gira em torno da otimização de consultas.
7. Evite tabelas de pesquisa comuns
Muitas vezes vi uma tabela de pesquisa comum para pares de atributos. A definição de uma única tabela de domínio genérica é percebida para simplificar o design. Este estilo de tabela de domínio faz uma definição abstrata para armazenar texto. Eu ouvi isso chamado de tabela de “Valor Permitido” ou “Valid Values”, mas o termo tabela “MUCK” foi cunhado para esse antipadrão em 2006:Massively Unified Code-Key.
As tabelas MUCK contêm dados não relacionados.
Por exemplo, você pode ter uma tabela que define o domínio, a entrada e uma descrição. Pensando no exemplo de mensagem acima, duas entradas podem ser:
| Domínio | Entrada | Descrição |
|---|---|---|
| 1 | Eu | Mensagem recebida pelo banco |
| 1 | O | Mensagem de saída enviada pelo banco |
Agora adicione entradas para outro domínio:
| Domínio | Entrada | Descrição |
|---|---|---|
| 2 | TAMPA | Pagamento de cobertura |
| 2 | SÉRIE | Pagamento em série |
| 2 | SSI | Instruções padrão de liquidação |
Isso é apenas uma bagunça. O que a tabela significa?
Apenas por diversão, eu modelei um exemplo simples de uma tabela MUCK (ou OTLT, “One True Lookup Table” se você é um fã de Tolkien) e incluí alguns comentários. Observe que este é um antipadrão e não estou recomendando que você o use em seu modelo de dados.
Com tabelas MUCK, as restrições não podem ser definidas. MUCKs podem se tornar muitas linhas sem nenhum significado. Quando você deve consultar outra tabela para entender o significado de um campo, isso não é o ideal.
Essas tabelas “vale tudo” tornam as verificações de integridade complexas ou mesmo impossíveis. Uma razão pela qual essas tabelas podem ser criadas é porque várias tabelas no banco de dados têm uma definição semelhante. Então as verificações de integridade de dados tornam-se impossíveis. Além disso, seu tamanho pode se tornar bastante grande.
A normalização deve afastar as tabelas MUCK. Uma única tabela deve representar um único domínio; em vez de uma única tabela (MUCK) representando todos os domínios. Sem tabelas MUCK, podemos implementar restrições de chave estrangeira.
Use tabelas separadas para objetos de domínio em vez de agrupá-los em uma única tabela. Isso permite tipos de coluna, restrições e relacionamentos adequados. Uma tabela de “Valores Permitidos” é apenas um lixo e não tem lugar em um modelo de dados.
8. Defina uma estratégia de arquivamento
Com demasiada frequência, tenho visto bancos de dados criados sem uma estratégia adequada de retenção e arquivamento de dados. Por quanto tempo os dados serão mantidos online disponíveis em tabelas de banco de dados ativas? A maioria dos sistemas é construída para manter os dados no banco de dados “para sempre”. Para a maioria dos sistemas, essa não é uma estratégia razoável de retenção de dados de longo prazo. Em algum momento, os dados ativos devem ser arquivados.
Uma abordagem que defendo é incluir a retenção de dados como parte de suas considerações de design. Você terá tabelas ativas e históricas para que as inserções de novas linhas nas tabelas ativas permaneçam rápidas, enquanto as pesquisas em dados históricos podem ser otimizadas?
Isso evita ter que redesenhar o arquivamento em seu banco de dados sobre o design original.
9. Teste com antecedência, teste com frequência
Parafraseando Al Capone (ou John Van Buren, filho do 8º presidente dos EUA), “teste cedo, teste com frequência”. Dessa forma, você segue o caminho da Integração Contínua. Testar em um estágio inicial de desenvolvimento economiza tempo e dinheiro.
O teste é sempre um desafio no plano de desenvolvimento. Geralmente, há uma fase de teste no final de um Agile Sprint e um teste de sistema no final do desenvolvimento. O teste geralmente é a primeira coisa a ser espremida quando o tempo fica curto.
Ao testar o banco de dados, o objetivo deve ser simular um ambiente de produção:“Um dia na vida do banco de dados”. Que volumes podem ser esperados? Quais interações do usuário são prováveis? Os casos limite estão sendo tratados?
Portanto, o plano de teste e o teste adequado devem ser parte integrante da modelagem de dados e desenvolvimento do banco de dados.
Conclusão
Esses são os principais problemas que tenho visto ao trabalhar com modeladores de dados e revisar modelos de dados. Ao prestar atenção a essas dicas, seu banco de dados ficará melhor projetado e mais robusto. No entanto, o retorno de alguns desses investimentos nem sempre é óbvio ou visível. Planeje, documente, use padrões, crie chaves, garanta integridade, execute indexação, evite MUCK, desenvolva estratégias e TESTE!
Nenhuma dessas atividades levará muito tempo, mas terá um enorme impacto na qualidade do seu modelo de dados.
Qual sua opinião sobre essas dicas?
