Vantagens e desvantagens da normalização

Aqui está um artigo da Microsoft que faz um bom trabalho explicando a normalização e as diferentes formas , embora um pouco datado em relação ao Microsoft Access, a teoria e os princípios ainda se aplicam.

Em resumo, a normalização do banco de dados emprega os seguintes benefícios:

1. Reduz a redundância de dados, o que melhora a capacidade de manutenção. Como você vê em sua tabela de exemplo Customer_Sale, coisas que não são centrais para uma Venda são repetidas desnecessariamente.

   Um bom exemplo disso é a ItemDesccoluna. Imagine o cenário para onde ItemNo = 123foi vendido Customersno ano passado, 10s de milhares de vendas, por exemplo. E então o negócio percebe que ItemDescestá errado e precisa ser atualizado. Com o design desnormalizado atual de armazenar o ItemDescna Customer_Saletabela, você precisaria atualizar todos os 10s de milhares de registros para corrigir o ItemDesc.

   A normalização seria ter outra tabela chamada Itemsque armazenaria uma linha por exclusiva Iteme é onde ItemDescela ficaria. A chave primária dessa tabela provavelmente seria ItemNo(assumindo que é o identificador exclusivo de um Itemaqui). Portanto, haveria apenas um registro para ItemNo = 123com a ItemDesccoluna na Itemstabela. A Customer_Saletabela não teria mais uma coluna chamada ItemDesc(você poderia fazer referência a ela na Itemstabela juntando-se ao ItemNocampo em ambas as tabelas). Agora, se a descrição de um Itemprecisa mudar, você só precisa atualizá-lo em um lugar, essa única linha na Itemstabela.

2. Por razões semelhantes, isso melhoraria o desempenho, minimizando a quantidade de trabalho que o tipo de manutenção acima exige. Menos linhas para atualizar geralmente significam tempos de bloqueio mais curtos e menos chance de escalonamento de bloqueio (quando aplicável). Portanto, em geral, seu sistema de banco de dados e os aplicativos que o consomem poderão ser executados com mais eficiência.

3. Outra razão pela qual o desempenho pode melhorar devido à normalização é porque suas tabelas (e mais ainda os objetos em que vivem no disco - geralmente chamados de páginas de dados) ficam menores em tamanho de dados.

   Isso ajuda a melhorar o desempenho de um mecanismo SQL ao localizar e carregar essas páginas de dados do disco, que normalmente é o maior gargalo no hardware provisionado de um servidor. Como sua tabela e efetivamente suas linhas ficam menores em tamanho, isso significa que mais linhas podem caber em uma única página de dados, o que significa que menos páginas precisariam ser localizadas e carregadas no disco como resultado também.

4. Do ponto de vista do aplicativo de consumo, geralmente você também ganha mais flexibilidade quando a arquitetura do seu banco de dados é normalizada adequadamente.

   Ao ter os campos de seus pontos de dados divididos em tabelas apropriadamente menos amplas, que fazem sentido geral para seu modelo de domínio, e mantendo os campos intimamente relacionados de uma entidade específica juntos na mesma tabela, você maximiza sua capacidade de utilizar, consultar, e manipular esses pontos de dados e entidades conforme necessário em seus aplicativos de consumo (uma refatoração de seus dados em um sentido muito livre da palavra).

   Um exemplo disso novamente usando sua Customer_Saletabela seria se você tivesse um aplicativo de Pedido de Vendas com duas telas. Um que era a lista exclusiva do Itemsnegócio que vende com suas descrições, e o outro era a lista do Customer_Salesque foi feito pelo negócio até agora.

   Se você não tivesse a tabela normalizada que armazenou o campo (como meu primeiro ponto exemplificado), para dar suporte a ambas as telas e seus casos de uso, você teria mais dificuldade com a tabela desnormalizada menos flexível por causa de seus dados redundância das informações.ItemsItemDesc Customer_SaleItems

   É claro que em sua linguagem de programação consumidora você pode usar um operador distinto para transformar os dados de sua Customer_Saletabela para se adequar ao modelo da Itemstela disponível para venda, mas esse é um conjunto adicional de trabalho que o aplicativo consumidor precisa fazer sempre essa tela é carregada. Também se torna arriscado com o gerenciamento do código, especialmente à medida que regras de negócios mais complexas entram em jogo ao longo do tempo, em oposição a uma arquitetura de banco de dados normalizadaItems em que a tabela já existe.

As possíveis desvantagens da normalização são:

1. A normalização excessiva pode levar a possíveis problemas de desempenho. Ao dividir os campos em muitas tabelas, pode complicar demais as consultas que sempre envolvem a rejunção da maioria dessas tabelas para obter as linhas de que você precisa. Alguns sistemas de banco de dados se esforçam mais com muitas junções, mas sua milhagem pode variar.

2. Em uma estrutura de banco de dados destinada a suportar OLAP pesado ( Processamento Analítico Online - essencialmente para fins de armazenamento de dados e relatórios pesados), às vezes as tabelas desnormalizadas têm melhor desempenho, mantendo em cache e pré-calculados fatos e números comumente necessários nas proximidades.

Há muito mais raciocínio técnico e aprofundado não discutido nesta resposta que está no artigo que vinculei no início desta resposta. Portanto, recomendo a leitura desse artigo depois de obter uma breve visão geral desta resposta.