Índice:
- Noções básicas
- Existe um limite para o número de dimensões?
- Como você deve escolher os níveis em uma hierarquia?
- Estruturas de banco de dados físico em um MDDB
Vídeo: Vídeo 4 - Hands On. Entendendo o projeto e criando nossa primeira modelagem de BI 2024
Os bancos de dados multidimensionais (MDDBs) descartam as convenções de seus antepassados relacionais e organizam dados de forma altamente favorável à análise multidimensional. Para entender bancos de dados multidimensionais, portanto, você deve primeiro entender os conceitos básicos das funções analíticas realizadas com os dados armazenados neles.
A análise multidimensional é construída em torno de alguns conceitos simples de organização de dados - especificamente, fatos e dimensões:
-
Fatos: A fato é uma instância de ocorrência ou evento particular e as propriedades do evento armazenadas em um banco de dados. Você vendeu um relógio para um cliente na última sexta-feira à tarde? Isso é um fato. Sua loja recebeu ontem um envio de 76 anéis de classe de um determinado fornecedor? Esse é outro fato.
-
Dimensões: A dimensão é um descritor chave, um índice, pelo qual você pode acessar fatos de acordo com o valor (ou valores) desejado. Por exemplo, você pode organizar seus dados de vendas de acordo com essas dimensões: tempo, cliente e produto.
Noções básicas
Nestes exemplos simples, você pode organizar e exibir seus dados de vendas como uma matriz tridimensional, indexada pelas dimensões do tempo, do cliente e do produto:
-
Em outubro 2008 (a dimensão do tempo), o Cliente A (a dimensão do cliente) comprou anéis de classe (a dimensão do produto) - 79 deles por US $ 8, 833.
-
Em 2007 (a dimensão do tempo), o Cliente A (a dimensão do cliente) comprou muitos produtos diferentes (a dimensão do produto) - um total de 3, 333 unidades por US $ 55, 905 (os fatos).
Observe o subtil diferente entre a forma como as dimensões são usadas nestes dois exemplos. Na primeira, a dimensão do tempo se relaciona com um mês; a dimensão do cliente se relaciona com um cliente específico; e a dimensão do produto é para um produto específico.
No segundo exemplo, no entanto, o tempo é por um ano, e não um mês; O cliente ainda é o mesmo (um cliente individual); e o produto é para toda a linha de produtos.
A análise multidimensional suporta a noção de hierarquias em dimensões. Por exemplo, você pode organizar o tempo em uma hierarquia do ano → trimestre → mês. Você pode visualizar fatos (ou a consolidação de fatos) no banco de dados em qualquer um desses níveis: por ano, trimestre ou mês.
Da mesma forma, você pode organizar produtos em uma hierarquia de família de produtos → tipo de produto → produtos específicos. Os anéis de classe podem ser um tipo de produto; "Anel de classe, estilo moderno, pedra onyx" pode ser um produto específico.Além disso, anéis de classe, relógios, outros anéis e outros itens, todos rolariam na família de produtos de jóias.
Existe um limite para o número de dimensões?
Teoricamente, você pode ter tantas dimensões em seu modelo multidimensional quanto necessário. A questão sempre existe, no entanto, se o seu produto de banco de dados multidimensional pode suportá-los. Mas aqui está uma questão mais importante - mesmo que um produto permita um certo número de dimensões (15, por exemplo), faz sentido criar um modelo desse tamanho?
Você deve trabalhar em estreita colaboração com seus usuários para determinar se o número de dimensões torna sua solução muito complexa - e, portanto, limita a população de usuários - ou melhora a facilidade de uso - e, portanto, a expansão da população de usuários.
Você pode, por exemplo, adicionar geografia à lista de dimensões que contém tempo, cliente e produto para que você possa ver e organizar fatos de acordo com territórios de vendas, estados, cidades e lojas específicas.
Como você deve escolher os níveis em uma hierarquia?
Os níveis em uma hierarquia permitem que você execute a funcionalidade drill-down . E, ao ter vários níveis dentro de uma hierarquia, você pode obter respostas rapidamente às suas perguntas por causa da informação que foi configurada em cada um desses níveis especificados, de modo que a informação está apenas aguardando suas consultas.
Como os bancos de dados multidimensionais têm estruturas bastante rígidas construídas em torno do pre - cálculo de fatos (criando e armazenando agregados no banco de dados, em vez de realizar agregação e cálculo de tempo de relatório) quanto mais dimensões você tiver e quanto mais níveis em cada dimensão você tiver, maiores serão os requisitos de armazenamento e maiores serão os tempos de compilação ou carregamento.
Estruturas de banco de dados físico em um MDDB
Embora quase todos os produtos MDDB sejam construídos em torno do conceito de fatos, dimensões e hierarquias, ninguém apresentou uma definição padrão MDDB. No mundo relacional, a não padronização também tem sido um pouco um problema, particularmente em relação aos recursos de valor agregado, como restrições e procedimentos armazenados.
A estrutura de tabela-linha-coluna relacional básica, no entanto, foi bastante fácil de exportar ou descarregar em um arquivo plano de algum tipo e, em seguida, recarregá-lo em outro produto RDBMS.
No mundo da MDDB, os fornecedores adotaram uma variedade de abordagens diferentes para as representações físicas de seus respectivos produtos. Todos estão buscando maneiras de superar problemas de armazenamento e complexidade causados por grandes dimensões (por exemplo, mais de 15) e níveis profundos de hierarquias (por exemplo, 20 níveis de profundidade).
Quando você está avaliando os produtos, não se preocupe com as técnicas de armazenamento físico: apenas certifique-se de que as representações lógicas que acompanham os produtos (como hierarquias, níveis e fatos) podem atender às necessidades de sua empresa. Elimine produtos que pareçam fracos ou que tenham, por exemplo, um modelo de hierarquia que não pareça bastante correto para seus dados.
Então, depois de encontrar produtos que parecem se adequar ao seu negócio, chute os pneus um pouco (por assim dizer) para ver como funcionam dentro.