Por que as tabelas de relatório costumam ser desnormalizadas quando os bancos transacionais são normalizados?

A normalização otimiza para escrita e integridade, então um banco transacional evita duplicar dados e atualiza uma linha em um único lugar. Relatório otimiza para leitura em varreduras enormes, onde cada join custa tempo e cada tabela extra custa clareza para o analista. Um star schema desnormalizado significa menos joins, queries mais rápidas em armazenamento colunar e nomes de coluna que o analista entende sem um dicionário de dados.

Eles resolvem problemas diferentes. Um banco transacional é feito para muitas escritas pequenas com integridade estrita, então normalizar significa que o endereço de um cliente existe uma vez e atualizá-lo é uma escrita só. Uma tabela analítica é feita para varrer milhões de linhas de uma vez, onde cada join é um custo e um join de quinze tabelas é lento e difícil de acertar. Então a gente desnormaliza em fatos e dimensões conformadas, o que corta joins e dá aos analistas nomes de coluna legíveis em vez de um diagrama de schema e três tabelas de lookup. O armazenamento colunar deixa isso barato, porque repetir uma string de país por milhões de linhas comprime para quase nada. O outro motivo é operacional. Rodar uma varredura analítica pesada contra o banco de produção compete por recursos com a aplicação, e eu já vi uma query pontual derrubar um serviço de checkout. Mesmo ignorando modelagem por completo, a carga analítica pertence a um lugar onde ela não pode prejudicar clientes.