Vídeo: Curso MySQL #16 - INNER JOIN com várias tabelas 2024
Seu ambiente de data warehousing ou um mercado de dados específico que o seu principal o armazenamento de dados irá alimentar pode ter a missão de gerar um conjunto finito e previsível de relatórios. Aqui está uma abordagem para projetar um banco de dados relacional para suportar essa missão, construída em torno do princípio de base de dados de denormalização , ou violar deliberadamente os bons princípios de design de banco de dados relacionais no interesse da eficiência de desempenho.
A desnormalização é mais adequada para soluções rápidas, em que você deve obter um armazenamento de dados relacionais de pequena escala ou um data mart em funcionamento rapidamente. Por exemplo, você pode criar um banco de dados relacional desnormalizado para uma carta específica para produzir um determinado conjunto de relatórios que não estarão mais disponíveis como resultado de um esforço de migração do sistema herdado.
Embora a desnormalização não seja um ponto morto, ele cria uma grande quantidade de dados duplicados, e as estruturas de banco de dados que você cria não possuem muita flexibilidade. Além disso, você provavelmente possui capacidades de consulta limitadas (além de seus relatórios padrão) porque esses recursos estão intimamente ligados às estruturas de relatórios formalizadas no design da tabela. Ainda assim, você pode querer verificar essa abordagem.
Um exemplo simples de desnormalização, mostrado na figura, mostra como as tabelas de banco de dados de origem se parecem em um aplicativo que rastreia o desempenho das vendas, com essas tabelas estruturadas principalmente de acordo com os princípios padrão de projeto de banco de dados relacional (eles 'normalizado).
Para suportar o formato do relatório mostrado na parte inferior da figura, as estruturas de origem são mapeadas em uma tabela desnormalizada a partir da qual o relatório pode ser gerado sem ter que se juntar a tabelas. (Para colocá-lo de forma mais simples, seu relatório é executado muito rapidamente.)
Nota : Um exemplo do mundo real envolveria muitas outras tabelas (de 10 a 50 ou mais) e muitos mais relatórios do que o mostrado na figura. No entanto, essa figura deve ter a ideia.
Alternativamente, você pode querer seguir os princípios e técnicas de design dimensional. Como os RDBMS agora têm muito menos problemas para lidar com estruturas dimensionalmente orientadas do que no passado, é provável que você obtenha um desempenho adequado para suas necessidades de relatórios e ainda tenha a flexibilidade para suportar uma grande variedade de consultas ad hoc multidimensionais.
Para uma implantação rápida orientada para relatórios, no entanto, considere design baseado em desenergização para dados relacionais.
