Normalização de banco de dados: Da teoria ao cenário exotérico da prática

Segundo a Microsoft, normalização de banco de dados é o processo de organizar os dados em um banco de dados. Que geralmente são fundamentados na criação de tabelas e relacionamentos entre as mesmas, visando além da integridade do banco, a eliminação de redundância de inconsistência dos dados.

E comum, a partir das primeiras aulas de ‘BD’, o evidenciamento das cinco formas de normalização de dados, as quais são:

  • Eliminar grupos repetidos.
  • Eliminar dados redundantes.
  • Eliminar Colunas com chaves (KEY) não dependentes.
  • Isolamento de múltiplos relacionamentos independentes.
  • Isolamento semântico de relações de relacionamentos múltiplos.

No que tange a criação de um banco de dados, cabe ao Analista elencar todas as particularidades do sistema (fazendo uso das TLD’s, o que não é foco dessa discussão de hoje) a fim de determinar todas as particularidades do software, ao qual o Arquiteto de Software, comumente o mesmo DBA, sintetiza toda estrutura da informação coletada para estrutura de um banco de dados. A grande particularidade é que o ‘parto’ do banco de dados é feito, ou deveria ser, baseado nas formas de normalização de banco de dados.

Assim como qualquer engenheiro de software desenvolve de forma estruturada, seguindo os conceitos de segurança, estabilidade, durabilidade, etc. O profissional que é responsável pela criação do banco de dados deve ter a preocupação de projetar o mesmo, fundamentado ao menos, nas características básicas de um banco de dados, sendo elas: seguro, estável, consistente, dentre outras, que descrevem um banco normalizado.

Considerando essa preocupação com a integridade dos bancos de dados, obviamente o que se pode esperar no mercado, são bases de dados normalizadas, consistentes e integras. Bom ao menos deveria ser!

Hoje, não é raro um aluno ou profissional da área trabalhar com softwares de empresas reconhecidas no mercado, aos quais suas soluções possuem bases de dados, com falhas graves de segurança, integridade e consistência. Chega a ser preocupante como diversas empresas de grande porte, não possuem a preocupação a com as regras simples de normalização de dados.

A problemática não finda nisso; o infeliz DBA, assim como eu, acaba por ter uma dificuldade muito maior em estruturar os dados de maneira consistente afim de que o mesmo esteja mais próximo da realidade do cliente. Essa dificuldade muita das vezes é ocasionada por falhas simples na estrutura de tabela, as quais a primeira e segunda forma de normalização impediriam tal cenário.

Outra particularidade para os profissionais da área é a falta de viabilidade de normalizar um banco em uso, pois, qualquer modificação poderia não contemplar o software que ainda visualizaria a estrutura entregue pela empresa desenvolvedora. Ou ainda quando a implementação é possível para determinado software, e deixa de ser eficaz quando o mesmo recebe um novo pacote de atualização.

Para esses casos, gatilhos e views, tornam-se rotina para que determinadas informações possam ser apresentadas adequadamente. A dúvida que fica é: Como pode um software dessa magnitude possuir um banco de dados com diversas ‘anomalias’.

A cínica resposta é que as empresas vendem soluções. Por maior que sejam as irregularidades o software atende ao cenário proposto. Cabe ao profissional de TI adapatar-se aos adversos cenários exotéricos que pode haver dentro de um TI. A esperança é que em futuro próximo esses problemas serão minimizados, isso é claro, com uma base sólida de teoria de normalização aplicada aos projetos vindouros.

Em outra oportunidade abordarei sobre: Normalização de banco de dados, ACID e TLD’s.

Até a próxima.