sql >> Base de Datos >  >> RDS >> Database

Esquema de estrella frente a esquema de copo de nieve

En los dos artículos anteriores, consideramos los dos modelos de almacenamiento de datos más comunes:el esquema de estrella y el esquema de copo de nieve. Hoy examinaremos las diferencias entre estos dos esquemas y explicaremos cuándo es mejor utilizar uno u otro.

El esquema de estrella y el esquema de copo de nieve son formas de organizar data marts o almacenes de datos completos utilizando bases de datos relacionales. Ambos usan tablas de dimensiones para describir datos agregados en una tabla de hechos .

Todo el mundo vende algo, ya sea conocimiento, un producto o un servicio. El almacenamiento de esta información, ya sea en un sistema operativo o en un sistema de informes, también es una necesidad. Por lo tanto, podemos esperar encontrar algún tipo de modelo de ventas dentro del almacén de datos de casi todas las empresas.

Echemos un vistazo más al modelo de ventas en los esquemas de estrella y copo de nieve.

El esquema de estrella



La característica más obvia del esquema en estrella es que las tablas de dimensiones no están normalizadas. En el modelo de arriba, el fact_sales La tabla almacena datos agregados creados a partir de nuestras bases de datos operativas. Las tablas de color azul claro son tablas de dimensiones. Decidimos usar estas cinco dimensiones porque necesitamos crear informes usándolas como parámetros. La granulación dentro de cada dimensión también está determinada por nuestras necesidades de generación de informes.

A partir de este modelo, podemos ver fácilmente por qué este esquema se llama "esquema de estrella":parece una estrella, con las tablas de dimensiones que rodean la tabla de hechos central.

El esquema del copo de nieve



Este esquema de copo de nieve almacena exactamente los mismos datos que el esquema de estrella. La tabla de hechos tiene las mismas dimensiones que en el ejemplo del esquema en estrella. La diferencia más importante es que las tablas de dimensiones en el esquema de copo de nieve están normalizadas. Curiosamente, el proceso de normalización de las tablas de dimensiones se llama copos de nieve.

Una vez más, visualmente el esquema del copo de nieve nos recuerda a su homónimo, con varias capas de tablas de dimensiones que crean una forma irregular similar a un copo de nieve.

La Primera Diferencia:Normalización

Como se mencionó, la normalización es una diferencia clave entre los esquemas de estrella y copo de nieve. Con respecto a esto, hay un par de cosas que debe saber:

  • Los esquemas de copo de nieve usarán menos espacio para almacenar tablas de dimensiones. Esto se debe a que, por regla general, cualquier base de datos normalizada produce muchos menos registros redundantes.
  • Los modelos de datos desnormalizados aumentan las posibilidades de problemas de integridad de datos. Estos problemas también complicarán futuras modificaciones y mantenimiento.
  • Para los modeladores de datos experimentados, el esquema de copo de nieve parece tener una organización más lógica que el esquema de estrella. (Esta es mi opinión personal, no un hecho concreto. :) )

Pasemos a la segunda gran diferencia entre estos dos esquemas.

La segunda diferencia:complejidad de la consulta

En nuestros primeros dos artículos, demostramos una consulta que podría usarse en el modelo de ventas para obtener la cantidad de todos los productos de tipo teléfono vendidos en las tiendas de Berlín en 2016.

La consulta del esquema de estrella tiene este aspecto:

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 obtener el mismo resultado del esquema del copo de nieve, tenemos 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, la consulta de esquema de copo de nieve es más compleja. Debido a que las tablas de dimensiones están normalizadas, debemos profundizar más para obtener el nombre del tipo de producto y la ciudad. Tenemos que agregar otro JOIN para cada nuevo nivel dentro de la misma dimensión.

En el esquema en estrella, solo unimos la tabla de hechos con las tablas de dimensiones que necesitamos. Como máximo, solo tendremos un JOIN por tabla de dimensiones. Y si no estamos usando una tabla de dimensiones, ni siquiera necesitamos molestarnos con ella. En la consulta de esquema de copo de nieve, no sabemos qué tan profundo tendremos que ir para obtener el nivel de dimensión correcto, por lo que complica el proceso de escribir consultas.

Unir dos tablas lleva tiempo porque el DMBS tarda más en procesar la solicitud. La dim_store y dim_city las mesas se colocan muy cerca en nuestro modelo, pero es posible que no estén ubicadas cerca unas de otras en el disco. Existe una mejor posibilidad de que los datos estén físicamente más cerca en el disco si viven dentro de la misma tabla.

Básicamente, una consulta ejecutada en un data mart de esquema de copo de nieve se ejecutará más lentamente. Pero en la mayoría de los casos esto no presentará ningún problema:no importa mucho si obtenemos el resultado en un milisegundo o en un segundo.

Acelerar las cosas

Para acelerar los informes, podemos:

  • Agregar datos al nivel que necesitamos en los informes. Esto comprimirá los datos significativamente. Tendremos que crear procedimientos que transformarán nuestros datos en vivo para que encajen en la estructura del esquema de informes (el proceso ETL).
  • Construya un área de almacenamiento central para todos los datos agregados de la empresa, no solo los datos de ventas.
  • Proporcione a los usuarios solo los datos que necesitan para el análisis y los informes.

Esquemas de copo de nieve frente a estrella:¿cuál debería usar?

Ahora que hemos analizado la teoría y las velocidades de consulta, entremos directamente en el meollo del asunto:¿cómo sabe qué esquema usar en un proyecto determinado?

Considere usar el esquema de copo de nieve :

  • En almacenes de datos. Como el almacén es Data Central para la empresa, podríamos ahorrar mucho espacio de esta manera.
  • Cuando las tablas de dimensiones requieren una cantidad significativa de espacio de almacenamiento. En la mayoría de los casos, las tablas de hechos serán las que ocupen la mayor parte del espacio. Probablemente también crezcan mucho más rápido que las tablas de dimensiones. Pero hay ciertas situaciones en las que eso no se aplica. Por ejemplo, las tablas de dimensiones podrían contener muchos atributos redundantes pero necesarios. En nuestro ejemplo, usamos la ciudad atributo para describir la ciudad donde se encuentra la tienda. ¿Y si quisiéramos una descripción mucho más detallada de la ciudad, incluyendo población, código postal, datos demográficos, etc.? Describir otras subdimensiones, por ejemplo, tienda , región , estado y país – con más atributos convertiría el dim_store tabla de dimensiones en una tabla grande con mucha redundancia.
  • Si utiliza herramientas que requieren un esquema de copo de nieve en segundo plano. (Afortunadamente, la mayoría de las herramientas modernas admiten ambos esquemas e incluso el esquema de la galaxia).

Considere usar el esquema de estrella :

  • En data marts. Los data marts son subconjuntos de datos extraídos del almacén de datos central. Por lo general, se crean para diferentes departamentos y ni siquiera contienen todos los datos del historial. En esta configuración, ahorrar espacio de almacenamiento no es una prioridad.

    Por otro lado, el esquema en estrella simplifica el análisis. No se trata solo de la eficiencia de las consultas, sino también de simplificar las acciones futuras para los usuarios comerciales. Puede que entiendan las bases de datos y sepan cómo escribir consultas, pero ¿por qué complicar las cosas e incluir más uniones si podemos evitarlo? Un usuario comercial podría tener una consulta de plantilla que combine la tabla de hechos con todas las tablas de dimensiones. Luego, solo necesitan agregar las selecciones y agrupaciones apropiadas. (Este enfoque es similar a las tablas dinámicas de Excel).

  • Si utiliza herramientas que requieren un esquema de estrella en segundo plano. (De nuevo, esto no suele ser un problema).

Tanto el esquema de estrella como el esquema de copo de nieve son modelos relacionales que se utilizan para organizar almacenes de datos y/o data marts. No importa cuán similares sean, demuestran dos enfoques diferentes y tienen sus propias ventajas y desventajas. Personalmente, preferiría el esquema de copo de nieve al implementar un almacén de datos (para ahorrar espacio de almacenamiento) y el esquema de estrella para data marts (para facilitar la vida de los usuarios comerciales).