Artigos Banco de Dados Normalização e desnormalização de dados
Por que eu devo ler este artigo:Este artigo trata de técnicas de normalização de dados para implementação de um modelo de dados considerando um banco de dados relacional. Trata também da técnica de desnormalização de dados para obter ganhos de performance em bancos de dados relacionais. A normalização de dados é uma etapa importantíssima na modelagem de um banco de dados relacional que garante principalmente a eliminação de redundâncias indesejadas, enquanto a desnormalização de dados se aplica à construção de algumas redundâncias de dados que, em termos práticos, contribuirão para o ganho de performance geral do banco de dados relacional.

No momento da modelagem de dados, o processo de normalização irá evitar que dados sejam duplicados desnecessariamente gerando certas perdas de performance geral do banco de dados bem como consumo excessivo de espaço em disco para armazenamento de dados. Em contrapartida a desnormalização, apesar de apresentar o efeito colateral da redundância de informações, permite que a performance geral do banco de dados seja significativamente melhorada fazendo com que, por exemplo, menos junções entre tabelas sejam necessárias para o retorno de determinada informação.

Uma das etapas primordiais no projeto de bancos de dados é a normalização de dados. Esta técnica permite, entre outras coisas, evitar a duplicidade de informações, garantindo uma economia de espaço de armazenamento e também tornando o modelo de dados mais simples e fácil de gerenciar. Esta técnica é composta por um conjunto de regras que definem a metodologia de normalização e cada conjunto de regra forma uma camada de normalização. Basicamente, as camadas de normalização são 5 onde chamamos cada uma delas de Forma Normal, portanto teremos a 1ª, 2ª, 3ª, 4ª e 5ª Formas Normais. A aplicação de todas as formas normais é uma característica marcante em ambientes acadêmicos, mas que, na prática, podem causar problemas sérios de performance geral do banco de dados devido à necessidade de junções excessivas para se encontrar determinada informação. Para evitar este problema, algumas dicas são apresentadas nesta primeira parte do artigo e, uma abordagem mais “hard core” será apresentada na segunda parte, que é a Desnormalização de dados.

Em minhas “andanças” pela internet, encontrei dois artigos fantásticos escritos por Gavin JT Powell falando exatamente sobre normalização e desnormalização, porém de uma forma bastante informal. São dois artigos realmente interessantes que auxiliam muito no entendimento deste “bicho de sete cabeças” e me senti na obrigação de escrever este artigo, com base nestes dois, para compartilhar com o leitor estas pérolas que encontrei.

Modelos de dados para um banco de dados relacional envolvem a necessidade de remoção de duplicidades e, para atingir este objetivo, usamos um processo chamado de “normalização”. Este processo é composto por um conjunto de regras conhecidas como “formas normais” (ou simplesmente “FN”).

A normalização é aplicada a um conjunto de dados ou tabelas em um banco de dados relacional, enquanto as tabelas são utilizadas para armazenar diretamente os dados associados a ela. As tabelas podem ser relacionadas ou ligadas entre sí através de índices identificadores. Este índice identificador é usado para identificar a linha de dados da mesma forma que um índice tradicional em um livro. Veja que o índice é usado para encontrar uma determinada informação de interesse sem a necessidade de leitura de todo o livro.

Basicamente existem 5 níveis de normalização conhecidos como 1ª, 2ª, 3ª, 4ª e 5ª formas normais (ou 1FN, 2FN, 3FN, 4FN e 5FN) e cada uma das formas normais é um refinamento da forma normal anterior, ou seja, para dizermos que o modelo se encontra na 2ª forma normal, entende-se que este modelo também atende as regras da 1ª forma normal.

Quando desenhamos uma tabela considerando a performance do SGBDr (Sistema de Gerenciamento de Banco de Dados Relacional), é comum ignorar os primeiros passos da normalização e pular diretamente para a 2FN. A 3FN também é muitas vezes ignorada, a não ser que junções muitos-para-muitos (n:m), no nível da aplicação, necessitem demasiadamente de valores únicos. As 4FN e 5FN também são raramente usadas.

Vale lembrar que a normalização excessiva pode ser a causadora de perda considerável de performance tanto para ambientes de banco de dados transacionais (conhecidos como OLTP – OnLine Transational Processing, ou Processamento Transacional em Tempo Real) (ver Nota 1) quanto para ambientes de bancos de dados analíticos (conhecidos como OLAP – OnLine Analitical Processing, que significa Processamento Analítico em Tempo Real ou também como DSS – Decision Support System, que significa Sistema de Suporte a Decisão ou ainda os famosos DatawareHouse) (ver Nota 2).

Nota 1: OLTP

Online transaction processing (Processamento de transações em tempo real), ou OLTP, refere-se a uma classe de sistemas que facilitam o gerenciamento de aplicações orientadas a transações, normalmente para a entrada de dados e processamento de transações de recuperação. O termo é um pouco ambíguo, alguns entendem uma "transação" no contexto de operações de computador ou banco de dados, enquanto outros definem em termos de negócios ou transações comerciais. OLTP também tem sido utilizada para se referir ao processamento no qual o sistema responde imediatamente a pedidos do usuário.

OLTP é uma metodologia para fornecer aos usuários finais o acesso a grandes quantidades de dados em uma forma intuitiva e rápida para ajudar com as deduções com base em raciocínio investigativo.

Em aplicações de grande porte, sistemas OLTP eficientes podem depender de um sofisticado software de gerenciamento de transações e / ou táticas de otimização de banco de dados para facilitar o processamento de um grande número de atualizações simultâneas para um banco de dados orientado a OLTP.

Para ainda mais exigentes sistemas de banco de dados descentralizados, programas de intermediação de OLTP podem distribuir o processamento de transações entre vários computadores em uma rede. OLTP é muitas vezes integrado em arquitetura orientada a serviços (SOA) e Web Services.

Nota 2: OLAP

Em computação, processamento analítico em tempo real, ou OLAP, é uma abordagem para responder rapidamente consultar analíticas multidimensionais. OLAP é parte da categoria mais ampla de inteligência de negócios, que também abrange relatórios relacionais e mineração de dados.

Aplicações típicas de OLAP são relatórios de negócios para vendas, marketing, relatórios gerenciais, business process management (BPM)(processo de gerenciamento de negócio), orçamento e previsão, relatórios financeiros e áreas similares, e também para novas aplicações que estão surgindo, como os de agricultura. O termo OLAP foi criado como uma ligeira modificação do tradicional banco de dados OLTP (online Transaction Processing).

Ferramentas OLAP permitem que os usuários, de forma interativa, analisem dados multidimensionais através de múltiplas perspectivas. OLAP é composta por três operações básicas de análise: consolidação, drill down, e fatiamento. Consolidação envolve a agregação de dados que podem ser acumulados e computados em uma ou mais dimensões. Por exemplo, todos os escritórios de vendas são acumulados para o departamento de vendas ou divisão de vendas para antecipar as tendências de vendas. Em contraste, o drill down é uma técnica que permite aos usuários navegar através dos detalhes. Por exemplo, os usuários podem acessar as vendas por produtos individuais que compõem as vendas de uma região. Fatiamento é um recurso pelo qual os usuários podem tirar (cortar) um conjunto específico de dados do cubo e ver as fatias de diferentes pontos de vista.

Bancos de dados configurados para OLAP usam um modelo de dados multidimensional, permitindo consultas analíticas complexas e ad-hoc com um tempo de execução rápida.

O núcleo de qualquer sistema OLAP é um cubo OLAP (também chamado de "cubo multidimensional", ou um hipercubo). Ele consiste de fatos numéricos chamados medidas que são classificados por dimensões. Os metadados do cubo são normalmente criados a partir de um esquema de estrela ou esquema floco de neve de tabelas em um banco de dados relacional. As medidas são derivadas dos registros na tabela de fatos e dimensões são derivadas das tabelas de dimensão.

Cada medida pode ser pensada como tendo um conjunto de etiquetas, ou metadados associado a ele. A dimensão é o que descreve esses rótulos, que fornece informações sobre a medida.

Um exemplo simples seria um cubo que contém as vendas de uma loja como uma medida, e Data/Hora como uma dimensão. Cada venda tem um rótulo Data/Hora que descreve mais sobre essa venda.

Qualquer número de dimensões pode ser adicionado à estrutura, tais como loja, caixa, ou do cliente por adição de uma coluna de chave estrangeira para a tabela fato. Isto permite que um analista veja as medidas ao longo de qualquer combinação das dimensões.

Esta normalização excessiva é bastante comum em aplicações orientadas a objeto. Nesta situação, a estrutura do objeto é imposta ao banco de dados relacional. Mas vale lembrar que estruturas de orientação a objetos e a estrutura de dados relacionais são metodologias completamente distintas.

A normalização é algo muito formal e, em muitos casos não se aplica a aplicações comerciais. Pense na normalização como uma maneira poética e, principalmente, acadêmica de se pensar em termos de modelagem de dados e o motivo disso é o fato de que usar a normalização de dados de forma estrita é impraticável quando se fala em desempenho, especialmente as 3FN, 4FN e 5FN.

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