Projetando um banco de dados relacional para consultar e dar suporte a relatórios
O seu ambiente de armazenamento de dados ou um data mart específico que a sua principal armazém de dados irá alimentar pode ter a missão de gerar um conjunto finito e previsível de relatórios. Aqui é uma abordagem para a concepção de um banco de dados relacional para apoiar essa missão, construído em torno do princípio da desnormalização de banco de dados, ou deliberadamente violando bons princípios de design de banco de dados relacionais no interesse da eficiência do desempenho.
Desnormalização É mais adequado para soluções de golpes rápidos, em que você deve ter uma pequena escala de armazém de dados relacionais ou data mart em funcionamento rapidamente. Por exemplo, você pode criar um banco de dados relacional desnormalizada para uma específico charter para produzir um determinado conjunto de relatórios que não vai mais estar disponíveis como resultado de um esforço de migração de sistema legado.
Embora desnormalização não é um final completamente morto, ele cria uma grande quantidade de dados duplicados, e as estruturas de banco de dados criado não tem muita flexibilidade. Além disso, você provavelmente já capacidades Consultando limitada (para além de seus relatórios padrão), porque esses recursos estão intimamente ligadas às estruturas de relatórios formais no design da tabela. Ainda assim, você pode querer verificar para fora esta abordagem.
Um exemplo simples de desnormalização, mostrado na figura, mostra o que as tabelas de banco de dados de código parecido em um aplicativo que rastreia o desempenho de vendas, com essas tabelas estruturado primordialmente de acordo com os princípios de design de banco de dados relacionais padrão (eles são normalizados).
Para suportar o formato do relatório mostrado na parte inferior da figura, as estruturas de origem são mapeados em uma tabela desnormalizada partir do qual o relatório pode ser gerado sem ter que aderir a qualquer tabelas. (Para colocá-lo mais simplesmente, o seu relatório é executado muito rapidamente.)
Nota: Um exemplo do mundo real implicaria muitas mais tabelas (de 10 a 50 ou mais) e muitos mais relatórios do que mostrado na figura. Este valor deve ficar com a ideia do outro lado, no entanto.
Alternativamente, você pode querer seguir os princípios e técnicas de desenho dimensional. Porque RDBMSs agora têm muito menos problemas para lidar com estruturas orientadas dimensionalmente do que no passado, é provável que você obter um desempenho adequado para suas necessidades de relatórios e ainda tem a flexibilidade para suportar uma grande variedade de ad hoc, consultas multidimensionais.
Para implantação rápida que está reporte orientada, porém, pelo menos, considerar design baseado em desnormalização para dados relacionais.