O esquema da estrela

Hoje, relatórios e análises são quase tão importantes quanto o core business. Os relatórios podem ser criados a partir de seus dados ao vivo; muitas vezes essa abordagem funcionará para pequenas e médias empresas sem muitos dados. Mas quando as coisas ficam maiores – ou a quantidade de dados começa a aumentar drasticamente – é hora de pensar em separar seus sistemas operacionais e de relatórios.

Antes de abordarmos a modelagem básica de dados, precisamos de algumas informações sobre os sistemas envolvidos. Podemos dividir os sistemas em duas categorias:sistemas operacionais e sistemas de relatórios. Os sistemas operacionais são frequentemente chamados de Processamento de Transações Online (OLTP). Os sistemas de relatórios e analíticos são chamados de Processamento Analítico Online (OLAP). Os sistemas OLTP suportam os processos de negócios. Eles trabalham com dados operacionais “ao vivo”, são altamente normalizados e reagem muito rapidamente às ações do usuário. Por outro lado, o objetivo principal dos sistemas OLAP é a análise. Esses sistemas usam dados resumidos, que geralmente são colocados em uma estrutura de armazenamento de dados desnormalizada, como o esquema em estrela. (O que é desnormalização? Simplificando, é ter registros de dados redundantes para melhorar o desempenho. Leia mais.)

Agora que sabemos um pouco sobre os sistemas, vamos começar a examinar o data warehouse e suas peças e processos.

Data Warehouses x Data Marts

Um armazém de dados (DWH) é um sistema usado para armazenar informações para uso em análise de dados e relatórios. Data marts são áreas de um data warehouse usadas para armazenar informações necessárias para um único departamento ou mesmo para um usuário individual. (Pense no DWH como um prédio e nos data marts como escritórios dentro do prédio.)

Por que os data marts são necessários? Todos os dados relevantes são armazenados dentro da empresa DWH. A maioria dos usuários, no entanto, só precisa acessar determinados subconjuntos de dados, como os relacionados a vendas, produção, logística ou marketing. Os data marts são importantes tanto do ponto de vista da segurança (limitando o acesso desnecessário) quanto do ponto de vista do usuário (não queremos confundi-los ou forçá-los a percorrer dados estranhos).

Existem duas abordagens diferentes para o relacionamento data warehouse-data mart:

De cima para baixo :os data marts são criados a partir do data warehouse. (Isso é algo com o qual Bill Inmon, o “pai do data warehouse”, concordaria, junto com a ideia de que os warehouses deveriam estar na 3NF.)
De baixo para cima :os data marts são criados primeiro e depois combinados em um data warehouse. (Essa abordagem está mais próxima do que defende Ralph Kimball, especialista em data warehouse e modelagem dimensional.)

O processo ETL é usado para adicionar dados “novos” ao sistema OLAP regularmente. ETL é a abreviação de Extract, Transform and Load. Como o nome sugere, vamos extrair dados de um ou mais bancos de dados operacionais, transformá-los para se adequar à nossa estrutura de armazém e carregar os dados no DWH.

Modelagem dimensional , que faz parte do projeto de data warehouse, resulta na criação do modelo dimensional. Existem dois tipos de tabelas envolvidas:

Tabelas de dimensão são usados para descrever os dados que queremos armazenar. Por exemplo:um varejista pode querer armazenar a data, a loja e o funcionário envolvido em uma compra específica. Cada tabela de dimensão é sua própria categoria (data, funcionário, loja) e pode ter um ou mais atributos . Para cada loja, podemos salvar sua localização em nível de cidade, região, estado e país. Para cada data, podemos armazenar o ano, mês, dia do mês, dia da semana, etc. Isso está relacionado à hierarquia de atributos na tabela de dimensões.

No esquema em estrela, geralmente descobriremos que alguns atributos são um subconjunto de outros atributos no mesmo registro. Essa redundância é deliberada e feita em nome de um melhor desempenho. Poderíamos usar as dimensões de data, local e agente de vendas para agregar (a parte de transformação do processo ETL) e armazenar dados dentro do DWH. Na modelagem dimensional, é muito importante definir as dimensões certas e escolher a granulação adequada.
Tabelas de fatos contêm os dados que queremos incluir nos relatórios, agregados com base nos valores das tabelas de dimensões relacionadas. Uma tabela de fatos tem apenas colunas que armazenam valores e chaves estrangeiras que fazem referência às tabelas de dimensão. A combinação de todas as chaves estrangeiras forma a chave primária da tabela de fatos. Por exemplo, uma tabela de fatos pode armazenar vários contatos e o número de vendas resultantes desses contatos.

Com essas informações em vigor, agora podemos nos aprofundar no modelo de dados do esquema em estrela.

O Esquema Estelar

O esquema em estrela é o modelo mais simples usado em DWH. Como a tabela de fatos está no centro do esquema com tabelas de dimensões ao redor, ela se parece aproximadamente com uma estrela. Isso é especialmente aparente quando a tabela de fatos é cercada por tabelas de cinco dimensões. Uma variante do esquema em estrela, o esquema centopéia , em que a tabela de fatos é cercada por um grande número de tabelas de pequenas dimensões.

Os esquemas em estrela são muito usados em data marts. Podemos relacioná-los com a abordagem de modelo de dados de cima para baixo. Vamos analisar dois esquemas em estrela (data marts) e depois combiná-los para criar um único modelo.

Exemplo de esquema em estrela:vendas

O relatório de vendas é um dos relatórios mais comuns de hoje. Como mencionamos anteriormente, na maioria dos casos, poderíamos gerar relatórios de vendas do sistema ao vivo. Mas quando os dados ou o tamanho da empresa tornam isso muito complicado, teremos que construir um data warehouse ou um data mart para agilizar o processo. Depois de projetar nosso esquema em estrela, um ETL O processo obterá os dados do(s) banco(s) de dados operacional(is), transformará os dados no formato adequado para o DWH e carregará os dados no warehouse.

O modelo apresentado acima contém uma tabela de fatos (colorida em vermelho claro) e cinco tabelas de dimensão (colorida em azul claro). As tabelas do modelo são:

fact_sales – Esta tabela contém referências às tabelas de dimensão mais dois fatos (preço e quantidade vendida). Observe que todas as cinco chaves estrangeiras juntas formam a chave primária da tabela.
dim_sales_type – Esta é uma tabela de dimensão do tipo vendas com apenas um atributo, “type_name ”.
dim_employee – Esta é uma tabela de dimensões de funcionários que armazena atributos básicos de funcionários:nome completo e ano de nascimento.
dim_product – Esta é uma tabela de dimensão do produto com apenas dois atributos (além da chave primária):nome do produto e tipo de produto.
dim_time – Esta tabela trata da dimensão de tempo. Ele contém cinco atributos além da chave primária. Os dados de nível mais baixo são vendas por data (action_date ). A action_week atributo é o número da semana naquele ano (ou seja, a primeira semana de janeiro receberia o número 1; a última semana de dezembro receberia o número 52, etc.) O actual_month e actual_year os atributos armazenam o mês e o ano do calendário em que a venda ocorreu. Estes podem ser extraídos do action_date atributo. O action_weekday O atributo armazena o nome do dia em que a venda ocorreu.
dim_store – Esta é uma dimensão de loja. Para cada loja salvaremos a cidade, região, estado e país onde está localizada. Aqui podemos notar claramente que o esquema em estrela está desnormalizado.

Exemplo de esquema em estrela:pedidos de fornecimento

Existem muitas semelhanças entre este modelo, mostrado abaixo, e o modelo de vendas.

Este modelo destina-se a armazenar o histórico de pedidos realizados. Temos uma tabela de fatos e quatro tabelas de dimensão. As tabelas de dimensão dim_employee , dim_product e dim_time são exatamente os mesmos do modelo de vendas. No entanto, as seguintes tabelas são diferentes:

fact_supply_order – contém dados agregados sobre os pedidos feitos.
dim_supplier – é uma tabela de dimensão que armazena dados de fornecedores da mesma maneira que dim_store manteve os dados da loja no modelo de vendas.

Vantagens e desvantagens do esquema em estrela

Há muitas vantagens em usar o esquema em estrela. A tabela de fatos está relacionada a cada tabela de dimensão exatamente por uma relação e não precisamos de dicionários adicionais para descrever as tabelas de dimensão. Isso simplifica as consultas e diminui o tempo de execução da consulta. Poderíamos produzir o mesmo relatório diretamente de nosso sistema OLTP, mas a consulta seria muito mais complexa e poderia afetar o desempenho geral do sistema. A consulta de amostra a seguir para o modelo de vendas retornará a quantidade de todos os tipos de produtos do tipo telefone vendidos nas lojas de Berlim em 2016:

SELECT 
  dim_store.store_address,
  SUM(fact_sales.quantity) AS quantity_sold

FROM 
  fact_sales
  INNER JOIN dim_product ON fact_sales.product_id = dim_product.product_id
  INNER JOIN dim_time ON fact_sales.time_id = dim_time.time_id
  INNER JOIN dim_store ON fact_sales.store_id = dim_store.store_id

WHERE 
  dim_time.action_year = 2016
  AND dim_store.city = 'Berlin'
  AND dim_product.product_type = 'phone'

GROUP BY 
  dim_store.store_id,
  dim_store.store_address

A maior desvantagem do esquema em estrela é a redundância. Cada dimensão é armazenada em uma tabela de dimensões separada e isso causa a desnormalização. Em nosso exemplo, cidade pertence a uma região ou estado, que pertence a um país; não armazenamos essa relação como regra em nosso banco de dados, mas a repetimos continuamente. Isso significa que gastaremos mais espaço em disco e teremos um risco de integridade de dados.

O Esquema da Galáxia

Podemos olhar para os dois modelos anteriores como dois data marts, um para o departamento de vendas e outro para o departamento de suprimentos. Cada um deles consiste em apenas uma tabela de fatos e algumas tabelas dimensionais. Se quiséssemos, poderíamos combinar esses dois data marts em um modelo. Esse tipo de esquema, contendo várias tabelas de fatos e compartilhando algumas tabelas de dimensão, é chamado de esquema de galáxia . O compartilhamento de tabelas de dimensões pode reduzir o tamanho do banco de dados, especialmente onde as dimensões compartilhadas têm muitos valores possíveis. Idealmente, em ambos os data marts, as dimensões são definidas da mesma maneira. Se não for esse o caso, teremos que ajustar as dimensões para atender às duas necessidades.

Um esquema de galáxia, construído a partir de nossos dois data marts de exemplo, é mostrado abaixo:

O esquema em estrela é uma abordagem para organizar um data warehouse. É muito simples e é mais frequentemente usado em data marts. Se não precisarmos nos preocupar com espaço em disco e cuidarmos bem da integridade dos dados, o esquema em estrela será a primeira e melhor escolha viável. Se não, devemos pensar em outra abordagem. Um é o esquema de floco de neve, que discutiremos em um próximo artigo.