Notas sobre los contenidos de la asignatura

Un data warehouse (DW) es un repositorio de gran tamaño de datos integrados obtenidos de diversas fuentes en una organización con el fin de analizar los datos.

Los data warehouses están optimizados para consultas que manejan grandes volúmenes de datos, necesitando el historial de los datos.

Su principal objetivo es proporcionar acceso a los datos de la organización para apoyar el análisis estratégico y la toma de decisiones.

A diferencia de las bases de datos operacionales (OLTP), que están optimizadas para las operaciones del día a día, los data warehouses se centran en el análisis y la generación de informes.

Un data warehouse es una colección de datos orientados a temas, integrados, no volátiles y dependientes del tiempo, diseñados para dar soporte a la toma de decisiones.

Orientación a temas: Los data warehouses se diseñan en torno a temas importantes relacionados con el negocio, facilitando el análisis. Por ejemplo, un data warehouse para un vendedor de libros podría centrarse en el análisis de las ventas, con entidades como libros, tiendas, vendedor, comprador y fecha.

Integración de datos: Los data warehouses consolidan datos de diversas fuentes heterogéneas, como catálogos de proveedores, sistemas de inventario y facturación, que pueden utilizar diferentes formatos y unidades. Los procesos ETL (Extracción, Transformación y Carga) son cruciales para extraer, limpiar y transformar los datos antes de cargarlos en el data warehouse.

No volatilidad: Los datos cargados en un data warehouse no se actualizan ni eliminan (salvo para correcciones), siendo el único cambio permitido la carga de nuevos datos. Esto contrasta con los sistemas operacionales, que se diseñan para soportar actualizaciones concurrentes.

Dependencia del tiempo: Los data warehouses almacenan datos históricos, lo que permite analizar tendencias y patrones a lo largo del tiempo.

El modelado multidimensional es una técnica de diseño de bases de datos utilizada para analizar datos de negocio, que organiza los datos en dimensiones y hechos, facilitando la creación de informes y análisis.

Este modelo utiliza una estructura en forma de estrella o copo de nieve para organizar los datos del negocio. Las dimensiones son categorías de datos para el análisis, mientras que los hechos son los datos numéricos que se miden.

Los modelos de datos multidimensionales (MDM) están diseñados para dar soporte al análisis de datos, siendo la base de la industria de Business Intelligence.

Un data warehouse típicamente incluye las siguientes capas:

Los data warehouses pueden ser departamentales (data marts) con datos muy resumidos, o globales/corporativos con registros históricos y datos poco resumidos.

Los procesos ETL (Extract, Transform, Load) son fundamentales en la construcción de data warehouses.

Estos procesos implican la extracción de datos de diversas fuentes, su transformación para que sean adecuados para el análisis, y su carga en el data warehouse.

Los pipelines de datos automatizan los procesos ETL y permiten definir flujos de trabajo complejos desde las fuentes transaccionales hasta los data warehouses.

En la operación continua de un data warehouse, los procesos ETL se encargan de actualizar los datos regularmente.

Los data warehouses almacenan principalmente datos estructurados. Los datos suelen organizarse en tablas con filas y columnas, con relaciones entre los datos definidas mediante claves.

Sin embargo, también pueden manejar datos semi-estructurados y no estructurados a través de data lakes, que pueden integrarse en arquitecturas de data warehouses modernos.

La implementación y gestión de un data warehouse puede ser compleja debido a la necesidad de integrar y estructurar grandes volúmenes de datos.

Los costos de licencias, hardware y mantenimiento pueden ser significativos.

Los procesos de limpieza y transformación de datos pueden ser largos y laboriosos.

Los datos en el data warehouse pueden no estar actualizados con los cambios más recientes en las bases de datos de origen.

Almacenar grandes cantidades de datos sensibles en una ubicación centralizada puede aumentar el riesgo de brechas de seguridad y violaciones de privacidad.

La arquitectura de los data warehouses ha evolucionado hacia modelos más modernos como los data lakehouses, que combinan la flexibilidad de los data lakes con la capacidad de análisis de los data warehouses.

Los data lakes almacenan los datos en su formato nativo sin imponer un esquema fijo, mientras que los lakehouses añaden una capa de metadatos para facilitar el análisis.

Los data warehouses relacionales (RDW) siguen siendo necesarios debido a la dificultad de generar informes directamente desde un data lake, su valor continuo y la dependencia de los usuarios en ellos.

Los almacenes de datos están optimizados para consultas que manejan grandes volúmenes de datos, necesitando el histórico de los datos.

Los datos cargados en un almacén de datos no se actualizan ni se eliminan, salvo para correcciones. El único cambio permitido es la carga de datos nuevos.

Los almacenes de datos están orientados a temas importantes relacionados con el negocio para facilitar el análisis. En cambio, los sistemas operacionales se crean en función de cómo se llevan a cabo los procesos.

Los almacenes de datos almacenan los datos en una base de datos multidimensional para dar respuesta a consultas de análisis.

Un almacén de datos es el lugar donde se almacenan los datos para los sistemas informacionales, que están orientados al análisis estratégico y a la toma de decisiones.

Los almacenes de datos permiten a los usuarios finales crear informes de manera autónoma sin depender del departamento de TI.

Reducir la carga en el sistema de producción, minimizando el impacto en los sistemas operacionales al centralizar el análisis en el almacén de datos.

Optimizar el acceso de lectura para mejorar el rendimiento en la consulta y generación de informes.

Integrar múltiples fuentes de datos para consolidar datos de diversas fuentes y obtener una visión unificada.

Generar informes históricos precisos que proporcionen información detallada sobre tendencias y datos históricos.

Reestructurar y renombrar tablas para adaptar la estructura de datos para facilitar el análisis.

Proteger contra actualizaciones de aplicaciones, asegurando que los cambios en las aplicaciones no afecten a los informes.

Reducir las preocupaciones de seguridad implementando medidas para proteger los datos sensibles.

Mantener datos históricos a lo largo del tiempo para realizar análisis en profundidad.

Gestionar los datos maestros para garantizar una única fuente de verdad para los datos clave.

Mejorar la calidad de los datos corrigiendo los problemas en los sistemas de origen para asegurar datos precisos y completos.

Complejidad: La implementación y gestión de un DW puede ser complicada debido a la necesidad de integrar y estructurar grandes volúmenes de datos.

Altos costos: Los costos de licencias, hardware y mantenimiento pueden ser significativos.

Desafíos en la integración de datos: Consolidar datos de múltiples fuentes puede ser complicado y requerir soluciones personalizadas.

Transformación de datos que consume tiempo: Los procesos de limpieza y transformación de datos pueden ser largos y laboriosos.

Latencia de datos: Los datos en el almacén de datos pueden no estar actualizados con los cambios más recientes en las bases de datos de origen.

Ventana de mantenimiento: Las actualizaciones y el mantenimiento del sistema pueden requerir tiempos de inactividad programados.

Flexibilidad limitada: Los DW están diseñados para soportar tipos específicos de análisis, lo que puede limitar su flexibilidad para otros tipos de procesamiento o análisis de datos.

Preocupaciones de seguridad y privacidad: Almacenar grandes cantidades de datos sensibles en una ubicación centralizada puede aumentar el riesgo de brechas de seguridad y violaciones de privacidad.

Extracción: Los datos pueden ser extraídos de forma completa o incremental.

Transformación: Los datos pueden ser transformados para adaptarlos al modelo de datos del almacén.

Carga: Los datos transformados se cargan en el almacén de datos.

Data Lakes: Almacenan los datos en su formato natural o bruto, sin necesidad de estructurarlos o procesarlos primero. Los data lakes son especialmente útiles para almacenar y analizar datos semiestructurados y no estructurados. Sin embargo, los data lakes no contaban con características como el soporte de transacciones, la aplicación de esquemas y las trazas de auditoría.

Data Lakehouses: Combinan la capacidad de los data lakes para manejar datos en su formato bruto con la robustez de los almacenes de datos relacionales para realizar análisis complejos y mantener la calidad e integridad de los datos. Los data lakehouses eliminan la necesidad de tener un almacén de datos relacional y utilizan un data lake como único repositorio. Los data lakehouses utilizan una capa de software de almacenamiento transaccional llamada Delta Lake que se ejecuta sobre un data lake existente y hace que funcione de manera más parecida a una base de datos relacional.

Almacenes de datos modernos (MDW): Combinan la estructura de los RDWs con la flexibilidad de los data lakes, utilizando el data lake para la preparación y el almacenamiento de datos, y el RDW para la presentación y la seguridad.

Fábricas de datos: Integran y orquestan datos a través de múltiples entornos y plataformas, proporcionando una capa unificada de gestión de datos que abarca tanto datos estructurados como no estructurados. La arquitectura de una fábrica de datos se puede considerar como una evolución de la arquitectura del almacén de datos moderno.

OLTP vs OLAP: Los sistemas OLTP (On-Line Transaction Processing) son bases de datos operacionales o transaccionales, optimizadas para soportar operaciones de inserción, actualización y borrado de datos. Los sistemas OLAP (On-Line Analytical Processing) se utilizan para realizar análisis de datos de forma eficiente y rápida. Los sistemas OLAP dan respuestas rápidas a consultas que agregan gran cantidad de datos y presentan los resultados en forma multidimensional.

Modelado dimensional: Técnica de diseño de bases de datos que se utiliza para analizar datos de negocios, organizando los datos en dimensiones y hechos.

Cubos OLAP: Estructura multidimensional para la captura y análisis de datos que se basa en el modelado dimensional.

Propósito: Los sistemas OLTP están diseñados para soportar las operaciones del día a día de una organización, como la inserción, actualización y eliminación de datos. Un ejemplo es un sistema de control de stock de libros, donde al venderse un libro, el stock disminuye.

Optimización: Estos sistemas están optimizados para recuperar y modificar un número reducido de tuplas, de manera eficiente.

Datos: Los sistemas OLTP almacenan sus datos en una base de datos relacional (BDR) normalizada para evitar anomalías de modificación. Los datos en un sistema OLTP suelen ser datos detallados (datos primitivos) y actuales.

Acceso: El acceso a los datos es repetitivo y se enfoca en transacciones pequeñas.

Usuarios: Los usuarios comunes de los sistemas OLTP son empleados sin función de dirección en la organización.

Redundancia: No hay redundancia en los datos.

Ejemplo: Un sistema para el control de stock de libros donde se reduce el stock cuando se vende una copia de un libro y aumenta el stock cuando se compran nuevos ejemplares.

Esquema: Los datos se organizan utilizando un enfoque conocido como schema-on-write, donde el esquema se define antes de almacenar los datos.

Bases de datos: Las bases de datos relacionales son la herramienta preferida para las aplicaciones operacionales que necesitan almacenar datos de manera permanente.

Limitaciones: Las bases de datos relacionales tienen limitaciones en cuanto a la escalabilidad y la gestión de grandes volúmenes de datos no estructurados.

Propósito: Los sistemas OLAP están diseñados para el análisis de datos, permitiendo a los usuarios realizar consultas complejas sobre grandes conjuntos de datos. Estos sistemas dan respuestas rápidas a consultas que agregan grandes cantidades de datos y presentan los resultados en forma multidimensional.

Optimización: Estos sistemas están optimizados para consultas que manejan grandes cantidades de datos, necesitando la historia de los datos. Los datos en un sistema OLAP son datos resumidos y refinados (datos derivados) e históricos.

Datos: Los datos se almacenan en una base de datos multidimensional para dar respuesta a consultas de análisis. Los sistemas OLAP guardan cada venta individual, incluyendo detalles como dónde, cuándo, quién y a quién se realizó la venta.

Acceso: El acceso a los datos se realiza a través de consultas complejas.

Usuarios: Los usuarios principales de los sistemas OLAP son ejecutivos y analistas.

Actualizaciones: Los sistemas OLAP normalmente solo añaden datos periódicamente y no eliminan ni modifican los datos existentes. La actualización se realiza por lotes.

Redundancia: La redundancia es habitual.

Ejemplo: Un sistema que permite analizar el libro de cocina más vendido o el promedio de libros infantiles vendidos antes de un día festivo durante los últimos tres años.

Modelo: Los sistemas OLAP se basan en el modelo de datos multidimensional (MDM), que permite una manipulación más directa e intuitiva de los datos, incluyendo slicing y dicing.

Implementaciones: Los sistemas OLAP se pueden implementar mediante ROLAP (OLAP relacional), que almacena los datos en bases de datos relacionales, o mediante HOLAP (OLAP híbrido), que combina datos resumidos en MOLAP y datos detallados en ROLAP.

Enfoque: Los sistemas OLTP se centran en la gestión de transacciones, mientras que los sistemas OLAP se centran en el análisis de los datos.

Datos: Los sistemas OLTP manejan datos detallados y actuales, mientras que los sistemas OLAP trabajan con datos resumidos e históricos.

Consultas: Los sistemas OLTP están optimizados para consultas simples y rápidas, mientras que los sistemas OLAP están diseñados para consultas complejas que involucran grandes volúmenes de datos.

Es una técnica para la presentación de datos analíticos.

Ofrece a los usuarios de negocio datos fáciles de entender.

Ofrece alto rendimiento en las consultas.

Se basa en el modelo de datos multidimensional.

Hechos: Son los datos numéricos que se miden. Los hechos tienen medidas asociadas que se encuentran en las celdas de un cubo OLAP. Las medidas representan las propiedades de los hechos que se quieren estudiar. Las medidas pueden ser aditivas, semiaditivas o no aditivas.

Dimensiones: Son las categorías de datos que se utilizan para analizar los hechos. Las dimensiones se utilizan para seleccionar y agrupar datos al nivel de detalle deseado. Las dimensiones se organizan en jerarquías, formadas por niveles, donde cada nivel representa un nivel de detalle de interés para el análisis de datos. Cada nivel puede tener sus propias propiedades. Las instancias de las dimensiones se conocen como miembros. Las dimensiones describen el quién, qué, dónde, cuándo, cómo y por qué asociado al evento o hecho. Las dimensiones suelen tener muchas menos filas que las tablas de hechos, pero tienen gran cantidad de columnas.

Cubos: Estructura multidimensional para la captura y análisis de datos. Los cubos son una generalización de la hoja de cálculo 2D. Permiten el uso de jerarquías en las dimensiones. Un cubo es un conjunto de cubos relacionados, también considerado como la base de datos multidimensional. La intersección de los valores de los ejes forman celdas, cada celda vacía se denomina hecho y cada hecho tiene medidas asociadas. Los cubos pueden ser más o menos densos en función de la aplicación.

Esquema en estrella: Tabla central (tabla de hechos) rodeada de tablas de dimensión desnormalizadas. Hay una tabla de dimensión para cada dimensión. La tabla de hechos contiene una fila para cada hecho, una columna para cada medida y una columna para cada dimensión que también es clave foránea a las tablas de dimensión. Las dimensiones en esquemas en estrella suelen ser generadas, facilitan los cambios en las dimensiones y contienen redundancia en los datos de los niveles superiores. Las dimensiones suponen un pequeño porcentaje del espacio total (1-5%). Las actualizaciones se realizan de forma centralizada por los procesos de carga y las consultas son más rápidas y sencillas. Un objetivo importante en el modelado multidimensional es proporcionar el mayor contexto posible a los hechos, y las dimensiones son la forma de proporcionar este contexto.

Esquema en copo de nieve: Algunas tablas de dimensión tienen relaciones con otras tablas de dimensión habiendo sufrido un proceso de normalización.

Granularidad: Se debe establecer la granularidad del proceso, que responde a la pregunta: ¿qué representa cada fila de la tabla de hechos?. Se debe tratar de elegir siempre el máximo nivel de detalle posible.

Identificar dimensiones: Las dimensiones responden a la pregunta: ¿cómo describen los expertos los datos resultantes de los eventos de medida del proceso de negocio?. Las dimensiones dan contexto a las medidas y representan el quién, qué, dónde, cuándo, por qué y cómo asociado al evento.

Dimensiones de fecha: Las dimensiones de fecha son necesarias porque SQL no permite realizar operaciones extendidas con fechas. Se recomienda almacenar la clave como un valor numérico, usar flags e indicadores como texto y tener atributos dinámicos (por ejemplo, isCurrentDay, isCurrentMonth, isPrior60Days). La hora suele ir en una dimensión aparte.

Dimensiones de tienda: Pueden tener varias jerarquías en la misma tabla (por ejemplo, Tienda-Ciudad-Condado-Estado, Tienda-Distrito-Región).

Dimensiones de promoción: Es una dimensión causal, se debe incluir una fila "No promoción".

Dimensiones degeneradas: Dimensiones sin atributos, solo con identificador. Los atributos se han distribuido en otras dimensiones, pero se mantiene el número para poder realizar análisis de la cesta. Los números de control operacionales suelen dar lugar a dimensiones degeneradas.

Tablas factless: Comparten dimensiones con otras tablas, pero no tienen medidas, solo indican que se ha producido un evento. Se puede añadir un 1 a cada hecho para facilitar la cuenta.

Dimensiones junk: Agrupan atributos variados con dominios discretos y reducidos, como flags o indicadores. Guardan una fila para cada combinación de valores. Al crear una dimensión junk, se eliminan los flags de la tabla de hechos y se colocan en un marco dimensional útil.

Las dimensiones pueden sufrir cambios. Es un error colocar todo lo que cambie en los hechos. Se debe definir una estrategia de cambio para cada atributo. Existen diferentes técnicas para manejar los cambios en las dimensiones (SCD, Slowly Changing Dimensions). Algunos de ellos son:

La redundancia está en las dimensiones, nunca en los hechos.

Un almacén de datos se diseña sobre temas importantes relacionados con el negocio. Los sistemas operacionales se crean en función de cómo se llevan a cabo los procesos.

Es importante usar dimensiones compartidas comunes para diseñar modelos dimensionales que puedan integrarse.

La operación drill-across permite combinar cubos con dimensiones comunes que han de ser comparables (conformadas). Dos dimensiones están conformadas si son idénticas o una es subconjunto de otra en cuanto a valores y atributos.

En dimensiones conformadas, se debe ir a la mínima granularidad común.

Se deben usar varias tablas de hechos, cada una con su propia granularidad, medidas y dimensiones.

Si se siguen en la cadena de tiendas, la dimensión producto es la misma. Si es aprovisionamiento para la fabricación, hay que añadir otra dimensión diferente a los productos en venta.

Es importante no mezclar granularidades de hechos, como encabezado de pedido y líneas de pedido, en una única tabla de hechos. En su lugar, se debe asignar los hechos de nivel superior a un nivel más detallado o crear dos tablas de hechos separadas para manejar los hechos con diferente granularidad.

Es un error representar explícitamente la relación 1:M entre pedidos y líneas, ya que genera problemas al hacer slice/dice de líneas en atributos del pedido.

Es recomendable usar una dimensión de auditoría que permita saber si hay medidas fuera de límites, establecer la fiabilidad de los datos o utilizar técnicas de distribución de gastos generales.

Optimización para el Análisis: Los modelos MDM están diseñados para dar soporte al análisis de datos y no a la gestión de transacciones en línea. La gestión de datos multidimensionales facilita la creación de informes y análisis de datos, ya que los datos se organizan de una manera que refleja la forma en que las personas piensan sobre ellos.

Consultas Agregadas: Las consultas en un MDM agregan valores de medidas sobre valores de rangos de dimensión.

Flexibilidad: La gestión de datos multidimensionales ofrece flexibilidad para analizar los datos desde diferentes puntos de vista y combinarlos bajo cualquier dimensión.

Redundancia: En el modelado multidimensional es habitual la redundancia, lo que no es apropiado en sistemas transaccionales, pero la redundancia está en las dimensiones, nunca en los hechos.

Base de los sistemas OLAP: El MDM es la base de los sistemas OLAP (On-Line Analytical Processing). Los sistemas OLAP dan respuestas rápidas a consultas que agregan gran cantidad de datos y presentan los resultados en forma multidimensional.

Almacenamiento multidimensional: Los sistemas OLAP almacenan sus datos en una base de datos multidimensional para dar respuesta a consultas de análisis.

Esquemas en estrella: Los datos se organizan utilizando un modelo de esquema en estrella o copo de nieve, en donde los datos del negocio se organizan en dimensiones y hechos. Los esquemas en estrella tienen una tabla central (tabla de hechos) rodeada de tablas de dimensión desnormalizadas. Una tabla de dimensión se crea para cada dimensión, que contendrá una columna clave, una columna para cada nivel (excepto la raíz), y una columna para cada propiedad de nivel. La tabla de hechos contiene una fila para cada hecho y una columna para cada medida y dimensión (que también son claves foráneas a las tablas de dimensión).

Granularidad: Un aspecto importante en el diseño de un MDM es establecer la granularidad del proceso, que define qué representa cada fila de la tabla de hechos. Se debe tratar de elegir siempre el máximo nivel de detalle posible.

Dimensiones degeneradas: Son dimensiones sin atributos, solo con identificador, como los atributos ticket (Número, Fecha, Supermercado, etc.) que se han distribuido en otras dimensiones. Estas dimensiones se mantienen para poder realizar análisis de la cesta.

Dimensiones conformadas: La operación drill-across permite combinar cubos con dimensiones comunes que han de ser comparables (conformadas). Dos dimensiones están conformadas si son idénticas o una es subconjunto de otra en cuanto a valores y atributos. En dimensiones conformadas se debe ir a la mínima granularidad común.

Cambios en las dimensiones: Las dimensiones pueden sufrir cambios, por lo que es necesario definir una estrategia de cambio para cada atributo. No se debe colocar todo lo que cambie en los hechos.

Minidimensiones: Si los cambios en las dimensiones son frecuentes, sobre todo con dimensiones con gran cantidad de filas, se puede mover a una nueva dimensión los atributos cambiantes (minidimensión). En la minidimensión hay una fila para cada combinación (discretizada) de valores.

Vistas de Dimensión: Para manejar varias fechas se pueden definir varias claves externas en la tabla de hechos, pero puede haber problemas al hacer join de varias claves externas con la misma tabla de dimensión. La solución es crear la ilusión de varias tablas de fecha independientes mediante vistas de dimensión.

Tablas de hechos con demasiadas dimensiones: Se deben evitar nuevas dimensiones para atributos relacionados y confundir elementos de análisis con niveles de dimensión.

Manejo de varias granularidades: No se deben mezclar granularidades de hechos como cabecera de pedido y hechos de línea de pedido dentro de una única tabla de hechos. Se debe asignar los hechos de nivel superior a un nivel más detallado o crear dos tablas de hechos separadas para manejar los hechos con diferente granularidad. La asignación es el enfoque preferido.

Dimensiones junk: Las dimensiones junk son dimensiones auxiliares para evitar problemas de rendimiento al consultar en tablas con muchas filas.

Tabla central de hechos: El esquema en estrella se compone de una tabla central, llamada tabla de hechos, que está rodeada de tablas de dimensiones. La tabla de hechos contiene las medidas o datos numéricos que se analizan, así como las claves foráneas que enlazan a las tablas de dimensiones.

Tablas de dimensiones desnormalizadas: Alrededor de la tabla de hechos se encuentran las tablas de dimensiones, que contienen los atributos que describen las dimensiones del negocio. Estas tablas están desnormalizadas, lo que significa que pueden contener redundancia, pero esto mejora el rendimiento de las consultas y simplifica el diseño.

Estructura: Una tabla de dimensión se crea para cada dimensión.

Relaciones: La tabla de hechos se relaciona con cada tabla de dimensión a través de una relación uno a muchos, donde una fila en la tabla de dimensión puede estar relacionada con múltiples filas en la tabla de hechos. La tabla de hechos contiene una fila para cada hecho y una columna para cada medida y dimensión.

Simplicidad: La estructura simple del esquema en estrella facilita su comprensión e implementación.

Rendimiento de las consultas: Las consultas son más rápidas y sencillas debido a que hay menos joins y la desnormalización de las tablas de dimensión reduce la necesidad de múltiples joins.

Facilidad de uso: Los esquemas en estrella son muy útiles para presentar y consultar datos multidimensionales.

Claves generadas: Las claves de las dimensiones suelen ser generadas, lo que supone un ahorro considerable de espacio en la tabla de hechos. También facilitan los cambios en las dimensiones y aíslan al Data Warehouse de cambios de clave en los sistemas operacionales. Las claves generadas también permiten manejar valores nulos o desconocidos y cambios en las dimensiones.

Redundancia: Las dimensiones desnormalizadas contienen redundancia en los datos de los niveles superiores. Sin embargo, las dimensiones suponen un pequeño porcentaje del espacio total (1-5%) y las actualizaciones se realizan de forma centralizada por los procesos de carga, lo que asegura la consistencia.

Contexto: Un objetivo importante en el modelado multidimensional es proporcionar el mayor contexto posible a los hechos, y las dimensiones son la forma de proporcionar este contexto.

Tablas de dimensión: Las tablas de dimensión describen el "Quién, Qué, Dónde, Cuándo, Cómo y Por qué" asociado al evento o hecho. Estas tablas incluyen atributos para elaborar informes, valores legibles y atributos para expresar parte de códigos con "significado".

Esquemas en copo de nieve: Un esquema en copo de nieve es un modelo en estrella con dimensiones normalizadas. La normalización de dimensiones implica una mayor complejidad y dificultad de uso, un descenso del rendimiento debido a joins adicionales, y un ahorro de espacio despreciable.

Un ejemplo común de esquema en estrella es el análisis de ventas, donde la tabla de hechos contendría las ventas y las tablas de dimensiones podrían ser tiempo, producto, y tienda.

Otro ejemplo es el análisis de datos de ventas de libros, con dimensiones como ciudad y libro. Se podrían incorporar más dimensiones como fechas y autores.

No tienen medidas numéricas: A diferencia de las tablas de hechos tradicionales, las tablas factless no almacenan valores numéricos como cantidades o importes. En cambio, pueden incluir un contador (=1) para indicar la ocurrencia de un evento.

Relación entre dimensiones: Su principal objetivo es registrar la relación entre las diferentes dimensiones involucradas en un evento. Por lo tanto, estas tablas comparten las dimensiones con otras tablas de hechos, pero tienen una granularidad diferente.

Granularidad: La granularidad de una tabla factless se define por la combinación de las dimensiones que la componen.

Utilidad: Las tablas factless son útiles cuando se quiere analizar eventos que no tienen una medida numérica asociada, o cuando el análisis se centra en la presencia o ausencia de una relación entre dimensiones. Por ejemplo, se pueden usar para analizar qué productos en promoción no se han vendido.

Promociones: Se puede usar una tabla factless para registrar qué productos están en promoción, en qué fecha y en qué tienda.

Relación entre clientes y vendedores: Se puede usar una tabla factless para registrar las asignaciones de vendedores a clientes.

Eventos sin medidas: Se puede usar una tabla factless para registrar la asistencia a eventos, la participación en programas, etc.

Eficiencia: Permiten registrar la información de forma eficiente, sin tener que almacenar medidas numéricas que no son relevantes para el análisis.

Flexibilidad: Permiten analizar relaciones complejas entre dimensiones, facilitando la detección de patrones y tendencias.

Análisis de eventos: Son ideales para el análisis de eventos que no tienen una medida numérica asociada.

Evitan el crecimiento excesivo de tablas de hechos: Cuando queremos analizar eventos que no siempre se producen, es mejor usar una tabla factless que añadir un gran número de filas con valores nulos en la tabla de hechos principal.

Granularidad: Es importante definir correctamente la granularidad de la tabla factless, de modo que capture la información necesaria para el análisis.

Dimensiones: Se deben incluir todas las dimensiones relevantes para el análisis.

Relaciones: Se debe asegurar que la tabla factless tenga las relaciones adecuadas con otras tablas de hechos y dimensiones.

Reutilización: Son dimensiones que se comparten entre varias tablas de hechos. Esto significa que la misma dimensión se puede utilizar para analizar diferentes tipos de eventos o transacciones.

Consistencia: Las dimensiones conformadas deben ser idénticas o un subconjunto en cuanto a valores y atributos. Esto garantiza que la información se pueda agregar y comparar de manera consistente en diferentes tablas de hechos.

Integración: Permiten integrar datos de diferentes fuentes y procesos de negocio, facilitando el análisis global y la toma de decisiones estratégicas.

Operación drill-across: La principal ventaja de las dimensiones conformadas es que permiten la operación drill-across, la cual consiste en combinar cubos con dimensiones comunes que han de ser comparables.

Dimensión Fecha: Una dimensión fecha que se utiliza en diferentes tablas de hechos, como ventas, inventario, o compras. De esta forma, se puede analizar cómo evolucionan las ventas, el inventario y las compras a lo largo del tiempo.

Dimensión Producto: Una dimensión producto que se utiliza en las tablas de hechos de ventas y de inventario. Así, se puede analizar la relación entre las ventas y los niveles de inventario de cada producto.

Dimensión Tienda: Una dimensión tienda que se utiliza en las tablas de hechos de ventas y de devoluciones. De esta forma, se puede analizar el rendimiento de cada tienda en términos de ventas y devoluciones.

Análisis multidimensional: Permiten realizar análisis multidimensionales complejos, combinando datos de diferentes tablas de hechos en función de las dimensiones compartidas.

Visión global del negocio: Facilitan la obtención de una visión global del negocio, al poder integrar y analizar datos de diferentes áreas y procesos.

Reducción de la complejidad: Al reutilizar las mismas dimensiones en diferentes tablas de hechos, se reduce la complejidad del modelo dimensional y se facilita su mantenimiento.

Calidad de los datos: Al utilizar dimensiones conformadas, se mejora la calidad de los datos, ya que se garantiza la consistencia y la integridad de la información.

Granularidad común: Las dimensiones conformadas deben tener la misma o la mínima granularidad común.

Identificadores: Las dimensiones conformadas deben tener los mismos identificadores.

Atributos: Las dimensiones conformadas deben tener los mismos atributos.

Jerarquías: Las jerarquías de las dimensiones conformadas deben estar bien definidas y ser coherentes entre las diferentes tablas de hechos.

Planificación: Es importante planificar cuidadosamente las dimensiones conformadas, asegurándose de que satisfagan las necesidades de análisis de diferentes áreas del negocio.

Gobernanza de datos: Se debe establecer una gobernanza de datos para garantizar la consistencia y la calidad de las dimensiones conformadas a lo largo del tiempo.

Gestión de cambios: Se debe tener en cuenta que los atributos de las dimensiones pueden sufrir cambios con el tiempo.

Roles de dimensión: Una misma tabla de dimensión puede aparecer varias veces en la misma tabla de hechos, jugando diferentes roles. Por ejemplo, las fechas de pedido, envío, y entrega.

Cambios frecuentes en atributos: En algunas dimensiones, ciertos atributos pueden cambiar con frecuencia. Por ejemplo, la edad, los ingresos o el estado civil de un cliente pueden cambiar a lo largo del tiempo.

Impacto en el rendimiento: Cuando se tienen dimensiones con una gran cantidad de filas y atributos que cambian con frecuencia, el rendimiento de las consultas puede verse afectado negativamente si estos cambios se gestionan directamente en la tabla de dimensiones principal.

Sobrecarga de la tabla de dimensiones: Almacenar todos los cambios de atributos directamente en la tabla de dimensiones puede llevar a un crecimiento excesivo de la misma, haciendo que las consultas sean más lentas.

Nueva dimensión para atributos cambiantes: En lugar de almacenar los atributos que cambian con frecuencia en la tabla de dimensiones principal, se crea una nueva tabla de dimensión para almacenar las combinaciones de estos atributos.

Una fila por cada combinación: En la minidimensión, se guarda una fila para cada combinación discretizada de los valores de los atributos cambiantes. Es decir, las combinaciones posibles, no cada cambio específico.

Clave foránea en la tabla de hechos: En la tabla de hechos, se añade una clave foránea que hace referencia a la minidimensión. De esta manera, cada hecho se asocia a una combinación específica de valores de los atributos cambiantes en la minidimensión.

Relación con la dimensión principal: La tabla de dimensiones principal mantiene la información básica y estable, mientras que la minidimensión contiene la información que cambia con frecuencia.

Actualización de la tabla de hechos: La solución también requiere añadir una columna a la tabla de hechos.

SCD Tipo 4: Añadir una minidimensión. Se mueve una nueva dimensión los atributos cambiantes, con una fila en la minidimensión por cada combinación de valores.

SCD Tipo 5: Minidimensión + Sobreescritura (4 + 1). Consiste en añadir un outrigger a una dimensión. Se añade un atributo clave de minidimensión a la dimensión, y este atributo clave se actualiza con cada cambio de perfil.

SCD Tipo 6: Minidimensión + Sobreescritura (3+2+1). Se añade una fila para capturar el cambio (Tipo 2) y se añade una columna para poder hacer asignaciones previas (Tipo 3), permitiendo la actualización de atributos.

Tabla de dimensión Cliente: Contiene información básica del cliente como el nombre, la dirección y la fecha de nacimiento.

Minidimensión Demographics: Contiene filas para combinaciones discretizadas de edad (rangos como "21-25", "26-30", etc.), frecuencia de compra (rangos como "Baja", "Media", "Alta") y nivel de ingresos (rangos como "<$30,000", "$30,000-$39,999").

Tabla de Hechos: Incluye una clave foránea que referencia a la minidimensión Demographics.

Mejora del rendimiento: Al separar los atributos cambiantes en una tabla separada, se reduce el tamaño de la tabla de dimensión principal y se mejora el rendimiento de las consultas.

Reducción de la sobrecarga: Se evita el crecimiento excesivo de la tabla de dimensión principal.

Flexibilidad: Permite una mejor gestión de los atributos que cambian con frecuencia, permitiendo que los datos históricos se mantengan y analicen correctamente.

Soporte a diferentes tipos de análisis: Al relacionar cada hecho con una combinación concreta de los valores de los atributos cambiantes en la minidimensión, se facilita el análisis de cómo los cambios en estos atributos afectan a las medidas en la tabla de hechos.

Complejidad: Añaden complejidad al modelo dimensional, lo que requiere una buena comprensión de cómo funcionan y cómo se deben utilizar.

Mantenimiento: Requieren un proceso de carga y mantenimiento adicional para actualizar las minidimensiones.

Potencial explosión de la minidimensión: Si se incluyen demasiados atributos o si los atributos tienen muchos valores posibles, la minidimensión puede crecer rápidamente.

Agrupación de atributos: Las dimensiones junk agrupan atributos que no están relacionados directamente entre sí pero que comparten características de cardinalidad baja. Estos atributos suelen tener un número limitado de valores posibles.

Cardinalidad baja: Los atributos incluidos en una dimensión junk tienen un número reducido de valores posibles, lo que permite almacenar todas las combinaciones de valores en una tabla de dimensión relativamente pequeña. Por ejemplo, un atributo que representa un indicador booleano (verdadero o falso) o un atributo con tres valores posibles.

Eliminación de flags de la tabla de hechos: Al crear una dimensión junk, se eliminan los atributos tipo flag de la tabla de hechos y se colocan en un marco dimensional útil. Esto reduce el tamaño y la complejidad de la tabla de hechos.

Mejora del rendimiento: El uso de dimensiones junk puede mejorar el rendimiento de las consultas al evitar búsquedas complejas en la tabla de hechos. Además, la creación de índices bitmap sobre la columna de clave de la dimensión junk puede mejorar el rendimiento.

Una fila por cada combinación de valores: La dimensión junk guarda una fila para cada combinación posible de valores de los atributos que contiene. Por ejemplo, una dimensión que almacena 5 indicadores de 3 valores cada uno, contendrá 243 filas (3⁵).

Indicadores booleanos (verdadero/falso, activo/inactivo).

Categorías con pocos valores (tipo de pedido, tipo de cliente, tipo de pago).

Banderas o flags que indican el estado de un proceso o evento.

Indicadores que señalan características concretas de un producto.

Atributos con dominios discretos y reducidos.

Cuando se tienen varios atributos que no encajan en las dimensiones existentes y que tienen un número limitado de valores posibles.

Cuando incluir estos atributos en la tabla de hechos aumentaría significativamente su tamaño y complejidad.

Cuando se busca mejorar el rendimiento de las consultas al evitar búsquedas complejas en la tabla de hechos.

Cuando se desea simplificar la estructura del modelo dimensional y hacerlo más fácil de entender.

Tipo de pedido: "Normal", "Urgente" o "Programado".

Forma de pago: "Tarjeta", "Efectivo" o "Transferencia".

Canal de venta: "Web", "Tienda" o "Teléfono".

Reducción del tamaño de la tabla de hechos: Al mover los atributos de flag a una tabla de dimensión, se reduce la cantidad de información almacenada en la tabla de hechos.

Simplificación del modelo: El modelo dimensional se vuelve más fácil de entender, ya que los atributos que no encajan bien en las dimensiones principales se agrupan en una dimensión específica.

Mejora del rendimiento de las consultas: Las consultas son más rápidas al evitar búsquedas complejas en la tabla de hechos y al permitir la creación de índices bitmap.

Potencial crecimiento de la dimensión: Si se incluyen demasiados atributos, o si los atributos tienen muchos valores posibles, la dimensión junk puede crecer rápidamente.

Dificultad para entender los datos: Es necesario conocer el código y la codificación de las combinaciones para entender los datos almacenados en la dimensión junk.

Múltiples roles para una misma dimensión: En un modelo dimensional, es común que una misma dimensión, como la dimensión Fecha, participe en una tabla de hechos con diferentes roles. Por ejemplo, una tabla de hechos de pedidos podría tener la fecha del pedido, la fecha de envío solicitada y la fecha de envío real.

Ambigüedad en joins: Al hacer joins con la misma tabla de dimensión varias veces, SQL podría interpretar que todas las fechas son la misma. Por lo tanto, se necesita una forma de distinguir entre estos roles diferentes de la dimensión en la tabla de hechos.

Vistas de dimensión: La solución es crear vistas lógicas o aliases de la misma tabla de dimensión para cada rol. Estas vistas son independientes para las herramientas de Business Intelligence.

Creación de vistas SQL: Se crean estas vistas usando sentencias SQL CREATE VIEW. Cada vista selecciona los datos de la tabla de dimensión base y les asigna nombres específicos para su rol en la tabla de hechos.

Por ejemplo, se podría crear una vista order_date para la fecha de pedido y otra vista req_ship_date para la fecha de envío solicitada.

Renombrar atributos: Los atributos en las vistas deben ser renombrados para evitar ambigüedades en los informes. Por ejemplo, en la vista order_date, el atributo date_key podría ser renombrado como order_date_key.

En una tabla de hechos de pedidos, la dimensión Fecha puede aparecer varias veces:

Para cada uno de estos roles, se crea una vista de dimensión diferente.

Cada vista contiene los mismos datos, pero se presenta con nombres diferentes para evitar confusión y permitir que las herramientas de BI los traten por separado.

Claridad: Facilita la comprensión del modelo y de los diferentes roles de una misma dimensión en una tabla de hechos.

Evita ambigüedades: Previene problemas al hacer joins en las consultas, ya que cada rol de la dimensión está claramente definido.

Flexibilidad: Permite que una misma tabla de dimensión sea reutilizada en múltiples contextos sin crear redundancia en la base de datos.

Análisis con diferentes perspectivas: Permite realizar análisis utilizando diferentes fechas relacionadas con un mismo evento.

Dimensiones compartidas: El uso de vistas de dimensión es crítico para diseñar modelos dimensionales que puedan integrarse, utilizando dimensiones compartidas entre diferentes tablas de hechos.

Matriz del bus: El uso de roles de dimensión se suele representar en una matriz del bus que muestra cómo cada proceso de negocio utiliza una dimensión concreta con un determinado rol.

Herramientas BI: Las herramientas de BI deben ser capaces de reconocer estas vistas como entidades separadas y permitir a los usuarios interactuar con ellas de forma individual.

Roles en otras dimensiones: Aunque el ejemplo más común es con la dimensión Fecha, la misma lógica se puede aplicar a otras dimensiones como la dimensión Cliente. Por ejemplo, una tabla de hechos podría tener un cliente comprador y un cliente receptor del envío.

Vinculados a atributos de una dimensión: Un outrigger se relaciona con los atributos de una tabla de dimensión específica.

No son habituales: No son un componente común en los modelos dimensionales, y se usan con moderación.

Implican joins: El uso de outriggers implica realizar joins adicionales al consultar los datos, por lo que su uso debe ser moderado.

Reducción de redundancia: Se utilizan principalmente para evitar redundancia en dimensiones grandes o con datos compartidos entre diferentes dimensiones.

Los outriggers se utilizan generalmente para introducir un grado de normalización las dimensiones, pero sin llevar la desnormalización al extremo del modelo en copo de nieve.

Sirven para evitar redundancia de información en dimensiones grandes.

Se usan cuando hay datos compartidos entre diferentes dimensiones, evitando la repetición de los mismos datos.

Sirven para mover atributos de una dimensión a otra tabla cuando estos atributos son usados por otras dimensiones, de tal manera que estos atributos estén en un lugar común.

Dimensión Cliente con información geográfica o demográfica: La Dimensión Cliente puede tener un outrigger que contenga información de ubicación geográfica o demográfica del cliente.

Atributos de fecha en la Dimensión Producto: En lugar de tener todos los atributos relacionados con la fecha (como la fecha de introducción del producto) directamente en la tabla de la Dimensión Producto, estos atributos se pueden mover a un outrigger llamado "Dimensión Fecha de Introducción del Producto". No obstante, en este caso habría que valorar si es más eficiente incluir estos atributos directamente en la tabla de la Dimensión Producto o relacionar la Dimensión Producto con la Dimensión Fecha.

Complejidad: Introducen complejidad en el modelo dimensional, ya que se necesitan joins adicionales para acceder a la información.

Rendimiento: Al implicar joins, pueden tener un impacto negativo en el rendimiento de las consultas si no se usan de manera adecuada. Por ello, se debe usar con moderación.

Alternativas: Hay que valorar si el uso de outriggers es la mejor solución, o si es más eficiente incluir los atributos directamente en la tabla de dimensión o usar una tabla de hechos separada.

Snowflaking: El uso de outriggers se relaciona con el concepto de snowflaking, que es la normalización de las dimensiones. Sin embargo, el snowflaking suele ser contraproducente, por lo que se recomienda su uso solo cuando realmente sea necesario.

Dimensiones conformadas: Los outriggers pueden afectar la conformación de las dimensiones, ya que se debe asegurar que el outrigger tenga sentido para todas las tablas de hechos en las que se utilice la dimensión.

Tablas de hechos: Algunos atributos que podrían ser considerados para un outrigger podrían ser también implementados como una nueva tabla de hechos en función de la granularidad del modelo.

Copia de datos: Permite mover datos entre diferentes fuentes y destinos.

Flujo de datos: Permite transformar los datos.

Cuadernos (notebooks): Permiten ejecutar código Python, Spark, SQL, etc.

Flujos de control: Permiten definir la lógica de ejecución del pipeline.

Modelado dimensional: La metodología Kimball se basa en el modelado dimensional, donde los datos se organizan en torno a tablas de hechos y dimensiones, facilitando el análisis y la consulta. Los datos se categorizan como hechos, que tienen medidas numéricas asociadas, y dimensiones, que caracterizan los hechos.

Énfasis en la facilidad de uso: La metodología está orientada a los usuarios de negocio, proporcionando datos fáciles de entender y de consultar.

Diseño iterativo: La metodología Kimball se basa en un enfoque iterativo, donde se construye el almacén de datos de forma incremental, comenzando con un subconjunto de datos y expandiéndose a medida que se conocen mejor las necesidades del negocio. Se recomienda un enfoque de desarrollo paulatino de los Data Marts.

Tablas de hechos: Las tablas de hechos contienen medidas numéricas y claves foráneas que apuntan a las tablas de dimensiones. Cada celda vacía se denomina "hecho" y cada hecho tiene medidas asociadas que se encuentran en las celdas. Las medidas representan las propiedades de los hechos que se quieren estudiar, como por ejemplo, para optimizarlas. Los cubos pueden ser más o menos densos en función de la aplicación.

Tablas de dimensiones: Las tablas de dimensiones se utilizan para seleccionar y agrupar los datos al nivel de detalle deseado. Las dimensiones se organizan en jerarquías formadas por niveles, y cada nivel puede tener sus propiedades. Las instancias de las dimensiones se conocen como miembros.

Granularidad: Se debe elegir la granularidad adecuada de los datos. Una granularidad más detallada permite responder a cualquier pregunta, pero puede generar grandes volúmenes de datos. Una granularidad menos detallada permite una mayor flexibilidad y manipulación de los datos, pero puede no responder a todas las preguntas. Se debe elegir el nivel más detallado posible.

Esquema en estrella: La Metodología Kimball promueve el uso de esquemas en estrella para organizar los datos, con una tabla de hechos central y tablas de dimensiones desnormalizadas.

Dimensiones degeneradas: Estas son dimensiones sin atributos, que solo tienen un identificador, por ejemplo, el número de ticket.

Dimensiones poco cambiantes (SCD): Hay diferentes tipos de SCD para manejar los cambios en los atributos de las dimensiones. Por ejemplo, SCD Tipo 2 añade una nueva fila a la dimensión para guardar la historia anterior al cambio.

Manejo de varias granularidades: Se debe tener cuidado al manejar diferentes niveles de granularidad en los datos. Se recomienda crear tablas de hechos separadas para cada nivel de granularidad o asignar los hechos de nivel superior a un nivel más detallado.

Vistas de dimensión: Para manejar varias fechas (solicitud, expedición, llegada, etc.), se pueden crear vistas de dimensión que simulan varias tablas de fecha independientes.

Análisis de ventas: Analizar qué productos se venden en función del supermercado, fecha y condiciones promocionales. Las dimensiones podrían ser fecha, producto, supermercado, promoción, cajero, método de pago y ticket. Los hechos podrían ser unidades vendidas, importe de unidades vendidas, coste de unidades vendidas y beneficio.

Análisis del aprovisionamiento: El proceso de aprovisionamiento (peticiones, pedidos, notificaciones de compra, facturación y pagos) se puede modelar con dimensiones como producto, fecha, vendedor, transacción y condiciones, y hechos como unidades e importe de la transacción.

Análisis de pedidos: Se puede modelar con una granularidad de una fila por cada línea de pedido. Las dimensiones podrían ser fecha de solicitud, fecha de envío, producto, cliente, vendedor y condiciones. Los hechos podrían ser unidades, total bruto, descuento y total neto.

Identificadores Únicos: Las claves generadas aseguran que cada fila en una tabla de dimensiones tenga un identificador único. Esto es fundamental para mantener la integridad referencial en el modelo dimensional.

Secuenciales: Las claves generadas suelen ser números enteros secuenciales que se incrementan automáticamente a medida que se añaden nuevas filas a la tabla de dimensiones.

Aislamiento del DW: Las claves generadas aíslan el Data Warehouse de los cambios que puedan ocurrir en las claves de los sistemas operacionales. Esto evita que los cambios en las claves de los sistemas de origen afecten al Data Warehouse.

Tamaño Eficiente: Las claves generadas son más eficaces debido a su menor tamaño. Al ser típicamente de 4 bytes, permiten un gran número de combinaciones (alrededor de 4000 millones). Esto también reduce el tamaño de la tabla de hechos.

Independencia del Sistema Operacional: Las claves generadas no están ligadas a los sistemas operacionales. Esto permite que el Data Warehouse sea independiente de las claves de los sistemas de origen.

Soporte para valores nulos: Las claves generadas permiten manejar valores nulos o desconocidos en las dimensiones. Se puede añadir una fila especial en la dimensión para representar estos valores.

Manejo de cambios en dimensiones: Las claves generadas facilitan el manejo de los cambios que pueden ocurrir en las dimensiones, ya que las claves de las dimensiones pueden ser modificadas sin afectar la relación con la tabla de hechos. Esto es especialmente útil cuando se implementan estrategias de dimensiones de cambio lento (SCD, por sus siglas en inglés).

Simplificación de joins: Las claves generadas, por su tamaño reducido, hacen que los joins entre las tablas sean más rápidos.

Tabla de correspondencia: Se requiere una tabla de correspondencia en el área de staging para la carga ETL con las claves generadas.

Soporte para conflictos de claves: Las claves generadas soportan conflictos de claves en sistemas heterogéneos.

Identificación Única de Filas: Las claves generadas se utilizan en la tabla de hechos como claves externas (foreign keys) para relacionar cada fila de la tabla de hechos con sus dimensiones correspondientes.

Comprobación de progreso en ETL: Se usan también para la comprobación de progreso en cargas masivas de datos en el proceso ETL.

Soporte para actualizaciones: Facilitan la conversión de operaciones de update en operaciones de insert y delete.

Uso en esquemas padre/hijo: Se pueden usar en esquemas padre/hijo, donde filas de una tabla de hechos pueden ser padre de otras en una tabla de hechos con menor granularidad.

Es esencial no usar claves operacionales en las dimensiones del Data Warehouse.

Se debe generar nuevas claves secuenciales y usarlas solamente para joins entre las tablas.

Rendimiento: Mejoran el rendimiento de las consultas, ya que los joins entre tablas utilizando claves generadas suelen ser más rápidos que los joins utilizando claves operacionales.

Mantenibilidad: Facilitan el mantenimiento del Data Warehouse, ya que los cambios en los sistemas operacionales no afectan directamente la estructura del Data Warehouse.

Flexibilidad: Permiten una mayor flexibilidad en el diseño del Data Warehouse, ya que las claves generadas pueden ser adaptadas a las necesidades del modelo dimensional.

Calidad de los datos: Mejoran la calidad de los datos, ya que las claves generadas garantizan la integridad referencial entre tablas.

Snapshot periódico (periodic snapshot):

Transacciones:

Snapshot acumulativo (accumulating snapshot):