Esquema Estelar vs. Esquema Floco de Neve

O Esquema Estelar

O esquema do floco de neve

A primeira diferença:normalização

• Os esquemas de floco de neve usarão menos espaço para armazenar tabelas de dimensão. Isso ocorre porque, como regra, qualquer banco de dados normalizado produz muito menos registros redundantes .
• Modelos de dados desnormalizados aumentam as chances de problemas de integridade de dados. Esses problemas também complicarão futuras modificações e manutenções.
• Para modeladores de dados experientes, o esquema floco de neve parece mais organizado logicamente do que o esquema estrela. (Esta é minha opinião pessoal, não é um fato difícil. :))

A segunda diferença:complexidade da consulta

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

Para obter o mesmo resultado do esquema floco de neve, temos que usar esta consulta:

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_product_type ON dim_product.product_type_id = dim_product_type.product_type_id
  INNER JOIN dim_time ON fact_sales.time_id = dim_time.time_id
  INNER JOIN dim_year ON dim_time.year_id = dim_year.year_id
  INNER JOIN dim_store ON fact_sales.store_id = dim_store.store_id
  INNER JOIN dim_city ON dim_store.city_id = dim_city.city_id

WHERE 
  dim_year.action_year = 2016
  AND dim_city.city = 'Berlin'
  AND dim_product_type.product_type_name = 'phone'

GROUP BY 
  dim_store.store_id,
  dim_store.store_address

Obviamente, a consulta do esquema floco de neve é ​​mais complexa. Como as tabelas de dimensão são normalizadas, precisamos nos aprofundar para obter o nome do tipo de produto e a cidade. Temos que adicionar outro JOIN para cada novo nível dentro da mesma dimensão.

No esquema em estrela, juntamos apenas a tabela de fatos com as tabelas de dimensão que precisamos. No máximo, teremos apenas um JOIN por tabela de dimensão. E se não estivermos usando uma tabela de dimensões, nem precisamos nos preocupar com isso. Na consulta de esquema de floco de neve, não sabemos o quão profundo teremos que ir para obter o nível de dimensão correto, então isso complica o processo de escrever consultas.

A junção de duas tabelas leva tempo porque o DMBS leva mais tempo para processar a solicitação. O dim_store e dim_city as tabelas são colocadas próximas em nosso modelo, mas podem não estar localizadas em nenhum lugar próximo uma da outra no disco. Há uma possibilidade melhor de que os dados estejam fisicamente mais próximos no disco se estiverem dentro da mesma tabela.

Basicamente, uma consulta executada em um data mart de esquema floco de neve será executada mais lentamente. Mas na maioria dos casos isso não será um problema:não importa muito se obtivermos o resultado em um milissegundo ou um segundo.

Acelerando as coisas

• Agregue dados no nível que precisamos nos relatórios. Isso comprimirá os dados significativamente. Precisaremos criar procedimentos que transformarão nossos dados ativos para se adequarem à estrutura do esquema de relatórios (o processo ETL).
• Crie uma área de armazenamento central para todos os dados agregados da empresa, não apenas os dados de vendas.
• Forneça aos usuários apenas os dados necessários para análises e relatórios.

Esquemas de floco de neve x estrela:qual você deve usar?

• Em data warehouses. Como o warehouse é o Data Central da empresa, poderíamos economizar muito espaço dessa forma.
• Quando as tabelas de dimensão exigem uma quantidade significativa de espaço de armazenamento. Na maioria dos casos, as tabelas de fatos serão as que ocuparão a maior parte do espaço. Eles provavelmente também crescerão muito mais rápido do que as tabelas de dimensão. Mas há certas situações em que isso não se aplica. Por exemplo, as tabelas de dimensão podem conter muitos atributos redundantes, mas necessários. Em nosso exemplo, usamos a cidade atributo para descrever a cidade onde a loja está localizada. E se quiséssemos uma descrição muito mais detalhada da cidade, incluindo a população, código postal, dados demográficos, etc.? Descrevendo outras subdimensões – por exemplo, loja , região , estado e país – com mais atributos transformaria o dim_store tabela de dimensão em uma tabela grande com muita redundância.
• Se você usa ferramentas que exigem um esquema de floco de neve em segundo plano. (Felizmente, a maioria das ferramentas modernas suporta tanto esquemas quanto esquemas de galáxias.)

• 
  Em data marts. Data marts são subconjuntos de dados retirados do data warehouse central. Eles geralmente são criados para diferentes departamentos e nem contêm todos os dados do histórico. Nesta configuração, economizar espaço de armazenamento não é uma prioridade.
  
  Por outro lado, o esquema em estrela simplifica a análise. Não se trata apenas de eficiência de consulta, mas também de simplificar ações futuras para usuários corporativos. Eles podem entender bancos de dados e saber como escrever consultas, mas por que complicar as coisas e incluir mais junções se podemos evitá-lo? Um usuário de negócios pode ter uma consulta de modelo que une a tabela de fatos com todas as tabelas de dimensão. Em seguida, eles só precisam adicionar as seleções e agrupamentos apropriados. (Esta abordagem está próxima das tabelas dinâmicas do Excel.)
  
• Se você usa ferramentas que exigem um esquema em estrela em segundo plano. (Novamente, isso geralmente não é um problema.)