Teste

Uma Palavra sobre Desnormalização

O idealizador do banco de dados relacional, Edgar Frank Codd, foi também o criador do conceito de normalização de bancos de dados. A normalização foi, inicialmente, definida como um conjunto de três regras, ou formas normais, que regem um determinado projeto de banco de dados em sua fase de análise. Estas regras tem a finalidade de garantir o armazenamento consistente e um eficiente acesso aos dados.

A desnormalização é um processo que vai na contra-mão da normalização e tem, paradoxalmente, a mesma finalidade de aumentar o desempenho no acesso aos dados. O problema é que a normalização é um requisito puramente lógico, com argumentos sustentados apenas na teoria matemática e consta de um trabalho a ser feito na fase de análise de um projeto de banco de dados. Em contrapartida, temos um software que gerencia estes dados e que precisa guardá-los, fisicamente, em dispositivos com características muito peculiares; neste momento, inicia-se a fase de implementação. O resultado disto pode ser resumido em uma frase bem conhecida: Na prática, a teoria é outra! Assim, não basta fazer uma simplificação lógica e natural do modelo de um banco de dados, é preciso entender como o dado é fisicamente guardado e acessado, bem como este armazenamento e acesso interfere no desempenho das consultas.

Com a desnormalização, os dados redundantes passam a existir para minimizar a carga de junções (joins) necessárias em uma consulta e, como objetivo final, realizar uma quantidade menor de acesso a I/O, de forma que o desempenho desejável seja alcançado. A partir desta necessidade, alguns SGBD’s implementaram recursos para garantir a desnormalização física, enquanto o projeto lógico pode permanecer normalizado. Um exemplo disso é a visão materializada do Oracle e a visão indexada do Microsoft SQL Server. Ao utilizar estas tecnologias particulares de cada SGBD, existe um recurso interno que tenta garantir o máximo de desempenho nas consultas