Free Press

A modelagem dimensional (DM) faz parte da metodologia do Ciclo de Vida Dimensional do Negócio desenvolvida por Ralph Kimball que inclui um conjunto de métodos, técnicas e conceitos para uso na concepção de data warehouses. A abordagem centra-se na identificação dos principais processos de negócio dentro de um negócio e na modelação e implementação destes primeiro antes de adicionar processos de negócio adicionais, uma abordagem de baixo para cima.

Quais são os objectivos da Modelação de Data Warehouse?

Os objetivos, estabelecidos por Ross e Kimball, são simples:

• tornar a informação facilmente acessível
• apresentar informação consistentemente
• adaptável e receptiva a mudanças
• apresentar informação atempadamente
• proteger os activos de informação
• serve como uma base autorizada e confiável para melhorar a tomada de decisões (fonte única de verdade em linguagem de Engenharia de Dados)
• os VIPs devem aceitar o seu sistema

Se você trabalhou ou usou um sistema ETL, você teria notado que a consistência da informação é conseguida através de medidas de conformidade, a atualidade fornecida pelos ciclos ETL e a adaptabilidade também depende em grande parte do design ETL.

Porquê Modelar?

Como engenheiro de dados, você conhece SQL muito bem e provavelmente pode escrever consultas SQL durante todo o dia. Mas você não pode assumir que o usuário final típico será um especialista em escrever consultas SQL. Portanto, nosso objetivo é construir um DW tão fácil para os analistas escreverem consultas de análise de forma rápida e eficaz.

O que você não gostaria que seus analistas fizessem:

• Queries based on ID
• Cascading outer joins(even you would not want to do that)
• grouped or join multiple subqueries
• recursive subqueries(just visit Hackerrank SQL and you would understand the pain)
• Subquery correlation: buscar dados através de múltiplas colunas em diferentes subconsultas
• Joins sem PK/FK: mesmo para mim(1.5 anos de experiência DE), é difícil de visualizar.

Coisas que você poderia e deveria esperar dos seus analistas:

>

• Juntas simples
• Colunas com nomes e texto compreensivo
• Gregação simples
• Funções com janelas analíticas
• DISTINTO

Nota, os pontos acima não são os fáceis e que o seu sistema deve ser escalável o suficiente para todos estes tipos de consultas.

As bases de dados OLTP são transformadas em factos e dimensões devido aos objectivos acima mencionados.

Transição de bases de dados transaccionais para factos

A maioria das empresas mede o seu sucesso e eficiência através da medição de certos tipos de dados. Estes dados capturam as atividades reais do negócio e seu progresso. Estes dados são chamados como fatos.

As bases de dados orientadas OLTP registram transações de cada vez, tipo de streaming de eventos similares, mas centralizados em torno de transações. O DW é diferente. O DW não precisa registrar detalhes no nível transacional. O DW precisa ter fatos em diferentes critérios do seu negócio. DW precisa agregar (ou deixar que os analistas agreguem) as informações necessárias para melhorar os negócios. E assim, a redundância é um pecado imperdoável em DW.

O que são medidas e porque você deve preencher suas tabelas de fatos com elas?

Em um data warehouse, uma medida é uma propriedade na qual cálculos podem ser feitos.

Os fatos que derivamos dos data stores operacionais vêm com alguns dados adicionais que são tipicamente somados em nossa análise. Estes são os aspectos de um fato que permitem que o analista, ou o executivo visualizando a análise, veja o valor no fato.

Por que você precisa manter um grão consistente?

Para que você possa assegurar que seu sistema possa legitimamente correlacionar e agregar através dos fatos.

Mas nem sempre é possível ter dados a nível atômico. Assim, para preencher esta lacuna, existem dois métodos:

• Tabelas de Fatos Instantâneos Periódicos
• Aumular Tabelas de Fatos Instantâneos

Tabelas de Fatos Instantâneos Periódicos

Como o nome sugere, eles são coletados em intervalos regulares de tempo. Consumo de gás, auditoria e inspeções são algumas instâncias de coleta de dados que têm instantâneos periódicos habilitados para eles.

Acumular Tabelas de Fatos Instantâneos

Quando um indicador de desempenho empresarial é uma taxa de conclusão de um processo empresarial de múltiplos passos, você pode querer capturar no grão de todo o processo e registrar o início, a conclusão e os passos intermediários. Isto pode ser granulado pela transação, mas tem muitas medidas no meio. Portanto, você usa tabelas de fatos acumulados para responder perguntas complexas em business intelligence onde há o passar do tempo entre os fatos. Um bom exemplo seria uma linha de tabela de fatos do seu pedido de um sanduíche de frango e a linha de tabela de fatos do saco sendo entregue através da janela do carro no drive-thru do McDonald’s.

Localizando Fatos via Dimensions

Você e seus analistas precisam saber como consultar e filtrar fatos para derivar o business intelligence deles. Este propósito é servido pelas dimensões.

Desenhar Dimensões a partir de Dados de Referência e Raw-Meta

As dimensões são quase sempre criadas com uma chave de substituição; a chave de substituição, naturalmente, é referenciada pela chave (ou chaves) estrangeira na tabela de fatos. Nós pesquisamos a tabela pesquisando as dimensões em que estamos interessados. Todos os outros dados que descrevem os nossos factos, tais como carimbos temporais, agentes de clientes, localização da loja, produto e cliente são o que transformamos em dimensões.

A beleza da modelação dimensional é que os factos não são definidos pelas chaves primárias ou qualquer tipo de identificador único, em vez disso, eles são definidos pela combinação de dimensões. Isto dá origem ao Star Schema.

É muito importante que tenhamos uma singularidade nas nossas dimensões. Quando nós chegamos a consultas através dos fatos, as duplicações entre as combinações de dimensões se transformarão em um desastre. Se você não puder, então adicione ou agregue dimensões para torná-las únicas.

Hierarquia em Dimensões

Consulte as duas imagens a seguir.

Um analista terá uma vida fácil se você configurar a tabela da segunda dimensão para ele/ela.

>

Então, com a segunda tabela, você tem a seguinte hierarquia:

>

>

>

>>

>

Existem todos os tipos de hierarquias – múltiplas hierarquias, hierarquia única, etc. Não estou me dirigindo a elas neste post.

Uma coisa que eu gostaria de salientar é que a dimensão do tempo é uma verdadeira dor no pescoço. Você tem que cuidar dos dias mágicos, do calendário fiscal, dos fusos horários, dos ciclos (lucro sobre os tipos de trimestre). E não seja péssimo ou muito confiante nisto, mesmo as bases de dados de séries temporais não o ajudarão nas hierarquias se o seu ETL estiver estragado. Você pode querer dar uma olhada nas dimensões do Outrigger. Há também ocasiões em que uma dimensão é naturalmente dependente de outra. Nesse caso, os designers podem colocar uma chave estrangeira de uma para a outra. Isto é o que constitui uma “dimensão de Outrigger”. Em dimensões de calendário, isto é muito comum.

Você não pode usar uma data em um grão diferente em um outrigger a partir das datas que você usa na tabela de fatos. Não se pode permitir a agregação sobre as dimensões do outrigger. Se necessário, mascarar valores numéricos no outrigger com prefixos ou sufixos textuais para obstruir isto.

Slowly Changing Dimensions

Por muito que eu gostaria de escrever sobre isso, eu ainda acho que é melhor para os meus leitores entenderem bem este conceito a partir daqui.

Não estou discutindo as dimensões do Floco de Neve, mas apenas para apontar, elas ainda estão em uso com bancos de dados OLAP.

Integrate seus Grandes Dados em seu Sistema ETL

Você tratará seus Grandes Dados tabulares como tendo sido adquiridos através de uma de suas fases padrão de Extrato. Assim, você aplicará a ele os mesmos passos que você aplicou na transform:

1. Limpeza de dados
2. Conformidade de unidades e formatos
3. Desduplicação
4. Reestruturação
5. Estágio

Resumo

Queria entender os aspectos teóricos do design da base de dados que me levaram a ler o livro, Ross e Kimball. Fiquei então curioso para desenhar diferenças e analogias em seus métodos e no das empresas líderes de dados de hoje como Netflix, Airbnb, Uber, etc.

Nesta busca, posso dizer com justiça que o formato estruturado da modelagem dimensional é preferido do que apenas um ETL hardcore. Porque desta forma, você remove a dependência de você, sua equipe de BI não lhe liga para a Slack para criar um novo DAG para cada outra visão, ao invés disso, com a modelagem correta, você os habilita a agir e explorar livremente sem a sua necessidade.

Por favor deixe um feedback sobre como eu poderia melhorar, tenho a certeza que esta não foi a sua melhor leitura. Obrigado pelo seu tempo.

>

Pés

https://en.wikipedia.org/wiki/Dimensional_modeling

https://en.wikipedia.org/wiki/Measure_(data_warehouse)

Ross e Kimball, ch 2 e ch 18

Kimball/Ross pp103-109