Continuamos después de cierto tiempo hablando del diseño de un data warehouse. Esta vez hablaremos de uno de los conceptos más importantes: la tabla de hecho (fact table).
¿Qué es una tabla de hecho?
Una tabla de hecho es una representación de un proceso de negocio. A nivel de diseño es una tabla que permite guardar dos tipus de atributos diferenciados:
- Medidas del proceso / actividad / flujo de trabajo / evento que se pretende modelizar.
- Claves foráneas hacia registros en una tabla de dimensión (o en otras palabras, como ya sabemos, hacia una vista de negocio).
Hemos ya hablado de esos conceptos en artículos anteriores. Otra forma de pensar en una tabla de hecho es que es una colección de fotografías de un evento que nos permiten determinar la evolución del mismo.
Tipos de tablas de hecho
En el momento de hablar de los diferentes tipos de tabla de hechos que existen es preciso indicar que se va a usar la terminología original por ser mucho más precisa:
- Transaction Fact Tables: representan eventos que suceden en un determinado espacio-tiempo. Se caracterizan por permitir analizar los datos con el máximo detalle.
- Factless Fact Tables/Coverage Tables: Son tablas que no tienen medidas y tiene sentido dado que representan el hecho que el evento suceda. Frecuentemente se añaden contadores a dichas tablas para facilitar las consultas SQL.
- Periodic Snapshot Fact Tables: Son tablas de hecho usadas para recoger información de forma periódica a intervalos de tiempo regulares. Dependiendo de la situación medida o de la necesidad de negocio este tipo de tablas de hecho son una agregación de las anteriores o están diseñadas específicamente.
- Accumulating Snapshot Fact Table: representan el ciclo de vida completo de una actividad o proceso, que tiene un principio y final. Se caracterizan por presentar múltiples dimensiones que relacionadas con los eventos presentes en un proceso.
En un próximo post pondremos ejemplos de los diferentes tipos.
Me encantó tu artículo, de hecho, no sabía que existían diferentes tablas de hechos, me encantaría que colocaras los ejemplos de los diferentes tipos, para comprender mejor los conceptos.
Saludos,
Hola, María.
Me alegro que te gustara el post.
Tengo en mente para uno de los futuros post poner ejemplos para hacer comprender mejor los diferentes tipos de tablas de hecho que existen.
Un saludo.
Hola,
¿Es posible generar tablas de hechos que contengan campos con los valores de las dimensiones, en lugar de apuntar a tablas de dimensiones? Por ejemplo, en una tabla de ventas por vendedor, incluir el nombre del mismo, en lugar de una foreign key a una tabla de vendedores.
Gracias.
Hola, José Luis.
Si es posible. Esa forma de proceder es típica en las dimensiones degeneradas. Me explico. Es una dimensión con muy poca información. Por ejemplo, pensemos en la dimensión sexo. Sólo tenemos los valores hombre y mujer. ¿Es necesario tener una tabla con primary key y el valor? Inicialmente no dado que así evitamos un joint en nuestras consultas. Pero al final depende del diseño que se realiza.
En el ejemplo que comentas… inicialmente seguro que tienes más información interesante de vendedores y convertirla en degenerate dimension significa perder parte de la información. Pero si no es el caso, puedes diseñarla como indicas.
Espero haber respondido a tu pregunta.
Un cordial saludo.
Muchas gracias por la aclaración.
La verdad es que estaba generando muchas dimensiones degeneradas que he visto que pueden ser transformadas en tablas de dimensiones.
El problema está en que muchas de estas tablas de dimensiones son copias parciales de las existentes en el sistema operacional (poblaciones, provincias, servicios, etc.), que hago con el ETL correspondiente.
¿Es buena práctica esta aunque duplico información existente en la bd operacional?
Gracias de nuevo.
Jose Luís:
Me alegro haber sido de ayuda. Respecto lo que comentas. Un Data Warehouse es un repositorio de información orientado al análisis de la información y diseñado de forma que optimice tal análisis. Es normal que al diseñarlo pienses que estas duplicando información pero el hecho es que por una parte liberas al sistema transaccional de ser consultado (y por lo tanto que penalice al modelo de negocio) y por otra asegurarte tener información de calidad e indentificada como hechos y dimensiones.
Además piensa que las dimensiones bien diseñadas son compartidas por diferentes hechos y por lo tanto permiten cruzar datos.
Por lo que es una buena práctica.
Un saludo.
Buen dia
Estuve leyendo su articulo, soy Gerente de Proyecto, en la actualidad estoy gerenciando un proyecto de aplicacion de BI y uno de los entregables es el DW. Tu me podrias indicar en cuestion de tiempo, de manera general, cuanto tiempo toma cargar cerca de 200 tablas de hecho?
Un saludo
Javier:
Dicha carga siempre va a depender de varias cosas como la volumetría de datos de las tablas de origen, la dificultad de las transformaciones, el tipo de herramienta ETL o EAI usada, las características del servidor,…
Deberías hacer una estimación de todos esos parámetros.
Un cordial saludo.
Hola alguien podría explicarme paso por paso como crear una tabla de hecho desde SSIS?? se los voy a agradecer mucho!!
Estimado Josep,
Lei tu articulo sobre los tipos de tablas de hechos, hace muy poco me inicié en el campo de BI. Estoy tratando de desarrollar un modelo de stock que maneja entradas y salidas y uno de cobranza que maneja saldos y me parece que el modo convencional de hacer una tabla de hechos para un sistema como el de ventas que sigue una línea de fechas y sólo suma cantidades e importes, no me sirve. Podrías guiarme como para tener una idea o tirarme algun link con ejemplos?
Muchas gracias!
Abrazos,
Matias
La Granularidad, tomando como ejemplo el modelo presentado por wiley (caso de la empresa de ventas de producto al por menor), donde la s dimensiones son producto, fecha, tienda, empleado preferente, promociones y la tabla de hechos posee una granularidad diara (fin de la jronada de venta diaria).
La pregunta es la siguiente, que almacena la tabla de hechos por cada registro:
1. podria ser un producto(ejemplo leche), la fecha en que se vendio, en la tienda donde se vendio, la promocion, quien fue el clientes y la cantidad del mismo. Y asi para cada producto vendido en ese dia.
2. que pasaria si la granularidad fuera semanal, almacenaria los registros de los dias y por toda la semana?
3. y por otro lado, la tabla de hecho soporta la redundancia de datos como por ejemplo del cliente ya que este compra varios productos?
Al final la funciones como SUM, avg son aplicados a la tabla de hechos solo cuando se desea realizar las consultas y estas funciones no son aplicables al momento de la carga de datos en la tabla de hechos.
estoy pensando en diseñar un almacen de datos para un hotel, pero no se cual seria mi tabla de hechos, cual me propondrias? espero tu respuesta lo antes posible Gracias