Quando você deve desnormalizar?

Acho que todos estamos familiarizados com a normalização do banco de dados .

Minha pergunta é: Quais são algumas diretrizes que você usa quando deseja desnormalizar as tabelas?

Desnormalizar quando são operações OLAP, normalizar quando OLTP (do artigo vinculado na seção Desnormalização)

Os bancos de dados destinados ao processamento de transações on-line (OLTP) geralmente são mais normalizados do que os bancos de dados destinados ao processamento analítico on-line (OLAP). Os aplicativos OLTP são caracterizados por um alto volume de pequenas transações, como a atualização de um registro de vendas em um caixa de supermercado. A expectativa é que cada transação deixe o banco de dados em um estado consistente. Por outro lado, os bancos de dados destinados a operações OLAP são principalmente "lidos principalmente". Os aplicativos OLAP tendem a extrair dados históricos acumulados por um longo período de tempo. Para esses bancos de dados, dados redundantes ou "desnormalizados" podem facilitar os aplicativos de inteligência de negócios. Especificamente, as tabelas dimensionais em um esquema em estrela geralmente contêm dados desnormalizados. Os dados desnormalizados ou redundantes devem ser cuidadosamente controlados durante o processamento de extração, transformação, carregamento (ETL) e os usuários não devem ter permissão para ver os dados até que estejam em um estado consistente. A alternativa normalizada para o esquema em estrela é o esquema de floco de neve. Em muitos casos, a necessidade de desnormalização diminuiu à medida que os computadores e o software RDBMS se tornaram mais poderosos, mas como os volumes de dados geralmente aumentam junto com o desempenho de hardware e software, os bancos de dados OLAP geralmente ainda usam esquemas desnormalizados.

A desnormalização também é usada para melhorar o desempenho em computadores menores, como em caixas registradoras e dispositivos móveis computadorizados, pois esses dados podem usar os dados apenas para consulta (por exemplo, consultas de preços). A desnormalização também pode ser usada quando não existe RDBMS para uma plataforma (como Palm), ou nenhuma alteração deve ser feita nos dados e uma resposta rápida é crucial.

Normalize até doer, desnormalize até que funcione (ou seja: o desempenho se torna aceitável) :)

Uma razão potencialmente sensata para aplicar a desnormalização controlada é se ela permite aplicar alguma restrição de integridade aos dados que, de outra forma, não seriam possíveis. A maioria dos DBMSs SQL possui suporte extremamente limitado para restrições de várias tabelas. Às vezes, no SQL, a única maneira eficaz de implementar certas restrições é garantir que todos os atributos envolvidos na restrição estejam presentes na mesma tabela - mesmo quando a normalização exigir que eles pertençam a tabelas separadas.

A desnormalização controlada significa que mecanismos são implementados para garantir que inconsistências não possam surgir devido a dados redundantes. O custo desses controles extras e o risco de dados inconsistentes precisam ser considerados ao decidir se a desnormalização vale a pena.

Outro motivo comum para a desnormalização é permitir alguma alteração nas estruturas de armazenamento ou outra otimização física que o DBMS não permitiria. De acordo com o princípio da Independência de Dados Físicos, um SGBD deve ter os meios para configurar estruturas de armazenamento interno sem alterar desnecessariamente a representação lógica dos dados no banco de dados. Infelizmente, muitos DBMSs são muito restritivos às opções de implementação física disponíveis para qualquer esquema de banco de dados. Eles tendem a comprometer a independência do banco de dados físico, suportando apenas uma implementação subótima do modelo lógico desejado.

Deveria ser óbvio, mas ainda precisa ser dito: em todos os casos, são apenas as mudanças nos recursos de implementação física que podem ditar o desempenho - recursos como estruturas de dados internas, arquivos, indexação, hardware e assim por diante. Normalização e desnormalização não têm nada a ver com desempenho ou otimização de armazenamento.

Desnormalize se você está acessando com frequência dados computados, conforme sugerido nas respostas a esta pergunta . O custo de armazenamento e manutenção dos dados computados geralmente será menor que o custo de recalculá-los repetidamente se o seu perfil de carga for pesado para leitura.

Rotineiramente desnormalizo para que eu possa impor a integridade dos dados com restrições. Um exemplo é uma pergunta recente neste site - replico uma coluna em outra tabela, para que eu possa usar uma restrição CHECK para compará-la com outra coluna. Outro exemplo dessa técnica é o meu post no blog .

Não é possível usar restrições CHECK para comparar colunas em linhas diferentes ou em tabelas diferentes, a menos que você agrupe essa funcionalidade em UDFs escalares invocadas de uma restrição CHECK. E se você realmente precisar comparar colunas em linhas diferentes ou em tabelas diferentes para aplicar uma regra de negócios? Por exemplo, suponha que você saiba o horário de trabalho de um médico e deseja garantir que todas as consultas se ajustem dentro do horário de trabalho? Obviamente, você pode usar um gatilho ou um procedimento armazenado para implementar essa regra de negócios, mas nem um gatilho nem um procedimento armazenado podem garantir 100% de que todos os seus dados estão limpos - alguém pode desativar ou soltar o gatilho, inserir algumas dados sujos e reative ou recrie seu gatilho. Além disso, alguém pode modificar diretamente sua tabela ignorando os procedimentos armazenados.

Deixe-me demonstrar como implementar essa regra de negócios usando apenas restrições FK e CHECK - que garantirão que todos os dados satisfaçam a regra de negócios, desde que todas as restrições sejam confiáveis.

Ainda outro exemplo é uma maneira de impor que períodos de tempo não tenham lacunas e sem sobreposições .