No tienes acceso a esta clase

¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera

Tabla de hechos (fact)

12/26
Recursos

¿Cómo combinar dimensiones tipo 1, 2 y 3 en un modelo dimensional?

En este segmento, exploraremos cómo integrar las dimensiones tipo 1, 2 y 3 para crear lo que se conoce como dimensión tipo 6. Esta dimensión combina las características de las dimensiones anteriores para registrar cambios de manera eficaz y flexible en nuestro modelo de datos. El ejemplo se centrará en un caso donde la información de un estudiante cambia a lo largo del tiempo.

¿Qué son la fecha de inicio y la fecha fin?

Para gestionar los cambios temporales en los registros, es esencial utilizar las columnas de fecha de inicio y fecha fin.

  • Fecha de inicio: Representa el momento preciso en que una nueva vigencia para un registro comienza.
  • Fecha fin: A menudo se define como nulo o con un valor futuro, por ejemplo, '9.9.9.9', para representar que el registro sigue vigente.

Dichos campos permiten seguir la evolución histórica de los registros, asegurando que siempre podamos determinar el estado de un dato en cualquier momento del tiempo.

¿Cómo manejar registros de cambios complejos?

La combinación de las dimensiones tipo 1, 2 y 3 nos permite manejar registros de cambios de manera más completa. Imaginemos que tenemos un estudiante llamado Pepito Pérez, quien cambia de facultades a lo largo del tiempo, desde ingeniería a comercio y luego de vuelta a salud. Al realizar cada cambio, se crea un nuevo registro con un ID único, reflejando las características y vigencias actualizadas.

¿Cómo se llena la tabla de hechos (FAC)?

La tabla de hechos es el núcleo del modelo dimensional y almacenará todos los indicadores que se deseen medir. Se debe construir con cuidado, asegurándose de cargar las dimensiones antes de procesar los registros de hechos.

¿Qué pasos seguir para llenar la tabla?

  1. Descargar y procesar dimensiones: Es crucial que todas las dimensiones estén cargadas primero, ya que actuarán como un catálogo de datos para cruzar con los hechos.

  2. Ejemplo práctico de carga: Supongamos que se genera una factura el 14 de junio de 2030, para un vendedor con código VEN01, referencia de producto 10 y cliente 1000. Se registran 500 unidades vendidas por $100. Los pasos son buscar en las dimensiones correspondientes:

    • Vendedor: Se identifica el ID correcto (ID1) en base a la fecha de venta.
    • Producto: Se asigna el ID del producto correspondiente (ID50).
    • Cliente: Se identifica al cliente y se asigna el ID correspondiente (ID1).

¿Cómo se manejan los niveles de detalle?

El nivel de detalle al que se maneja un modelo puede ser tan granular como el usuario desee. En este ejemplo, el modelo se lleva al nivel de factura, pero podría simplificarse al nivel de vendedor, producto y cliente, sumando métricas y desechando la granularidad de la factura, si se decide así en el proceso de extracción, transformación y carga (ETL).

¿Qué otras consideraciones tener en cuenta?

Es esencial definir claramente la agregación que se aplicará a las métricas, ya sea suma, conteo, media o mediana. Además, campos adicionales como la fecha de carga proporcionan trazabilidad y valor de auditoría al modelo.

Esta estructura permite no solo flexibilidad en el análisis histórico, sino también una robustez a la hora de integrar nuevas actualizaciones o cambios sin pérdida de información relevante. Así se construye un sistema dimensional eficiente y confiable.

Aportes 4

Preguntas 4

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad?

Buenos dias. Como estan? No se puede en la fact\_table de ventas poner directamente el nombre del vendedor en vez del id\_vendedor (de la tabla de dimensiones) asi cuando leamos desde analitica nos ahorramos joins inncesarios? Es decir.. aplicable a cualquier armado de fact\_table: Se puede en la fact\_table usar datos ya listos para consumir que estarian en una dim\_table? El objetivo es minimizar el join de las tablas cuando se consulte mas adelante.. Y obviamente dejar en una columna de la fact el id que relacione a la tabla dimensional por si precisamos mas datos que no estemos guardando directamente en la fac. EJ fact\_table: * id\_venta = 1 * Factura = 123 * Vendedor = Jaime * Producto = Jean * id\_producto = 1 * id\_camisa = 2 Teniendo la tabla fact asi, mas adelante si necesitamos datos minimos como el nombre de producto y el nombre de vendedor, no tendriamos que hacer un join a la tabla dim\_vendedor ni a dim\_producto. En caso que se necesite el campo ROL de dim\_vendedor, podriamos traerlo con el id que dejamos en la fac para no perder la relacion.
Una **tabla de hechos** (o *fact table*) es un componente esencial en el diseño de un Data Warehouse. Contiene **datos cuantitativos o métricas medibles** que representan los eventos o transacciones del negocio. Estas métricas están asociadas con las dimensiones para proporcionar un contexto que facilite el análisis y la toma de decisiones. ### **Características principales de una tabla de hechos:** 1. **Métricas y medidas:** * Almacena valores numéricos como ventas, ingresos, cantidad de unidades vendidas, costos, etc. * Estas métricas son las que se analizan y calculan. 2. **Llaves foráneas (FK):** * Incluye llaves foráneas que referencian las tablas de dimensiones. * Estas llaves permiten que los hechos se relacionen con sus dimensiones correspondientes (tiempo, producto, ubicación, cliente, etc.). 3. **Granularidad:** * Define el nivel de detalle de la tabla (por ejemplo, por día, por producto, por transacción). * Especificar la granularidad es clave para el diseño adecuado del Data Warehouse. 4. **Tamaño:** * Generalmente es la tabla más grande en un esquema dimensional debido al alto volumen de datos transaccionales. ### **Tipos de tablas de hechos:** 1. **Tablas de hechos transaccionales:** * Capturan datos sobre eventos o transacciones individuales (por ejemplo, una venta, una llamada). * Ejemplo: Cantidad de productos vendidos en cada transacción. 2. **Tablas de hechos acumulativas:** * Contienen datos acumulados o consolidados a lo largo del tiempo (por ejemplo, saldo mensual de una cuenta bancaria). * Ejemplo: Total acumulado de ventas por cliente. 3. **Tablas de hechos instantáneas:** * Capturan el estado de un proceso en un momento específico (por ejemplo, inventario diario). * Ejemplo: Niveles de inventario al final de cada mes. ### **Ejemplo de una tabla de hechos:** #### Contexto: * Queremos analizar las ventas por cliente, producto, y fecha. #### Tabla de hechos: `Fact_Ventas` FactIDFechaIDProductoIDClienteIDTiendaIDCantidadImporte\_Venta12024011013001501250.0022024011023002502130.00320240210330035015150.00 #### Tablas de dimensiones relacionadas: 1. **Dim\_Fecha:** Información detallada sobre fechas (día, mes, año, etc.). 2. **Dim\_Producto:** Detalles sobre productos (categoría, nombre, precio, etc.). 3. **Dim\_Cliente:** Información del cliente (nombre, región, etc.). 4. **Dim\_Tienda:** Detalles de la tienda (ubicación, nombre, etc.). ### **Componentes clave:** * **Llaves foráneas:** Conectan la tabla de hechos con las tablas de dimensiones. * **Columnas métricas:** Datos numéricos que representan hechos del negocio, como cantidades o ingresos. ### **Diferencias clave entre hechos y dimensiones:** **AspectoTabla de hechosTabla de dimensiones**ContenidoMétricas cuantitativasAtributos descriptivosNaturalezaTransaccionalContextualTamañoGrande (volumen de transacciones)Relativamente pequeñaRelaciónLlaves foráneasLlaves primarias ### **Importancia de las tablas de hechos:** * Permiten realizar análisis detallados de métricas y tendencias. * Sirven como el centro de un modelo dimensional, conectándose con múltiples dimensiones para proporcionar un contexto analítico completo.
Duda, El atributo valor no debe pertenecer a la dimension de Producto? O en que momento se "calcula" el total de esa venta? Saludos.
Todo bien y bonito, con tal no le metan dimension de fecha.