Artigos Banco de Dados Desnormalizar para Otimizar - Revista SQL Magazine 99
Atenção: esse artigo tem um vídeo complementar. Clique e assista!

Do que se trata o artigo:

Descreve os conceitos e limitações fundamentais que circunscrevem à desnormalização, uma das estratégias de melhoria de desempenho de consultas SQL. Também é discutido um processo que avalia a desnormalização e realiza a sua implementação por meio de refatorações de banco de dados.

Em que situação o tema útil:

Na busca pela melhor configuração de desempenho de consultas SQL, atividade que requer do projetista a contraposição e combinação de diferentes estratégias de melhoria de maneira harmoniosa.

Resumo DevMan:

A desnormalização é uma estratégia que melhora o desempenho das consultas SQL. Esse benefício, porém, carrega consigo efeitos colaterais. Este artigo caracteriza e descreve um processo de avaliação desta estratégia com o objetivo de garantir sua aplicação mais adequada.

Dados representam a matéria-prima pelos quais organizações tomam decisões com o intuito de continuarem vivas competindo em ambientes de negócio cada vez mais acirrados. O status de ativo corporativo associado ao grande volume produzido e armazenado, por outro lado, desafiam as mesmas organizações quanto à administração dos dados. Apesar do crescente interesse e investimento sobre o tema, organizações ainda enfrentam restrições e desperdício de recursos resultantes da baixa qualidade semântica e estrutural dos seus modelos de dados (veja a Nota DevMan 1).

Nota DevMan 1. Modelo de dados

O termo “Modelo de Dados” será aqui utilizado de forma abrangente. Quando necessário, será indicado explicitamente se este se refere ao produto do projeto de banco de dados ou se é um esquema em produção.

Possuir um Sistema Gerenciador de Banco de Dados Relacional – SGBDR – não pressupõe em modelos de dados de alta qualidade, livres de inconsistências e semanticamente bem definidos. Tratar dados em tabelas de forma semelhante a arquivos convencionais acoberta os recursos e propriedades superiores oferecidos pelos SGBDRs no manejo dos dados. Na realidade, a qualidade do modelo de dados decorre do seu projeto e evolução, etapas que clamam por cuidado e esmero por parte do projetista de banco de dados.

O projeto de banco de dados é visto como um processo sistematizado e difundido – envolvendo os aspectos conceitual, lógico e físico – com o objetivo primeiro de desenvolver ou evoluir um modelo de dados com qualidade observada sob perspectivas não mutuamente exclusivas; a da qualidade semântica e da qualidade estrutural.

A primeira perspectiva, produto da modelagem conceitual e lógica de dados, busca capturar os requisitos de dados, integrar visões distintas de seus significados e arranjá-los em um modelo relacional – na abordagem Entidade-Relacionamento Estendida ou UML – que explicita as restrições do mundo real por meio de diferentes abstrações diagramáticas e complementos textuais.

Por outro lado, o foco da segunda perspectiva é, a partir do modelo lógico, obter um modelo físico, implementável em um SGBDR, e capaz de atender adicionalmente a requisitos não funcionais como desempenho. Nesta etapa, conhecida como projeto físico de dados, o projetista emprega diferentes estratégias que, por apresentar níveis distintos de interconexão, precisam de análise conjunta de forma a evitar situações de “canibalização”, na qual uma estratégia reduz os ganhos de outra aplicada concomitantemente.

Tema deste artigo, a qualidade estrutural é tangenciada por meio da caracterização da desnormalização, estratégia utilizada para reduzir o tempo de execução das consultas SQL.

A Normalização

Discutir desnormalização passa por compreender a representatividade de um modelo de dados normalizado. O termo normalizar se refere ao processo de organizar os atributos de um modelo de dados de forma que cada uma de suas entidades constituintes apresente um único significado e esteja livre de redundâncias, maximizando a acessibilidade dos dados.

As etapas de Projeto Conceitual e Lógico, conjuntamente, balizam o projetista de banco de dados para o desenvolvimento de um modelo de dados normalizado ou muito próximo disso. Contudo, como estas dependem do bom-senso do projetista, a normalização, neste caso, atua como um mecanismo de aferição ou depuração do modelo.

Adicionalmente, a normalização também é aplicada como uma etapa da Engenharia Reversa, processo que usa uma estratégia ascendente para modelar um diagrama Entidade-Relacionamento a partir de estruturas de dados não normalizadas, como as encontradas em arquivos convencionais ou mesmo em modelos de dados mal projetados. Uma estrutura é dita não-normalizada quando não atende a 1FN e armazena dados de conceitos distintos, gerando problemas de perda de dados e inabilidade para representar outros dados.

O processo de normalização é composto de estágios sucessivos com um conjunto de regras distintas de dependência de dados que são aplicadas sobre cada atributo das entidades. Conhecidas como Formas Normais – FN –, tais regras descrevem exigências que se enrijecem a cada estágio; começa pelo estágio da 1FN e pode seguir até a 5FN, passando pela forma de Boyce-Codd (ler Nota DevMan 2), conforme ilustrado na Tabela 1.

...
Quer ler esse conteúdo completo? Tenha acesso completo