Tablas de hecho
Denominamos “hechos” a los indicadores de negocio. Por ejemplo, son “hechos” las ventas, los pedidos, los envíos, las reclamaciones, las compras, etc. Es decir, son todas aquellas medidas numéricas que incluiremos en nuestro sistema Business Intelligence.
Técnicamente, una tabla de hecho es la tabla central de un modelo en estrella. En el siguiente diagrama, la tabla de ventas es la tabla de hechos:
Una característica importante de las tablas de hecho es el “nivel de detalle” de la información que se almacena. En el anterior ejemplo, las ventas están guardadas a nivel de cliente, producto, almacén, promoción y fecha.
La tabla de hechos contiene las claves subrogadas de aquellas dimensiones que definen su nivel de detalle, y los indicadores. Nada más.
Por lo tanto, antes de crear la tabla de hechos debe entenderse perfectamente la información que se guardará, o se estará cometiendo el error número 7 de esta serie sobre cómo construir un datawarehouse…
Error 7: Añadir dimensiones en una tabla de hechos antes de definir su granularidad.
De hecho, la creación de una tabla de hechos es una tarea con poco margen a la imaginación. Antes que nada, debe localizarse el origen de la información que se quiere cargar, debe entenderse perfectamente el significado de estos indicadores, y debe determinarse el nivel de detalle de estos datos. Una vez hecho esto, la creación de la estructura de la tabla es inmediata. Tal y como comentaba anteriormente:La tabla de hechos contiene las claves subrogadas de aquellas dimensiones que definen su nivel de detalle, y los indicadores. Nada más. Y nada menos.
En particular, es un error desnormalizar cualquier dimensión en la tabla de hechos. Por ejemplo, si la información está a nivel de cliente, no necesitamos poner la población o el país en la tabla de hechos. Resultaría redundante e impactaría directamente en el tamaño de la tabla (y en los tiempos de respuesta).
Categoría: Serie DWH
Comentarios: Este artículo tiene 13 comentarios.¡Deja un comentario!
- ManuelSaturday, November 28, 2009
EXCELENTE MATERIAL
- IsaacBGSunday, May 16, 2010
Hola a todos!!
Me a surgido una duda respecto a las tablas de hechos;
Es posible tener una tabla de hechos sin hechos?? es decir, supongamos que queremos representar la asistencia a clase de un alumno...es decir la tabla de hechos es asistencia y las dimensiones; alumno, aula, asignatura, profesor, fecha, etc...como se representaría esta tabla de hechos???
Saludos y gracias,
Isaac BG
- BI FACILMonday, May 17, 2010
Hola Isaac,
Sí, aunque no es lo habitual, puede que exista una tabla de hechos sin indicador. Y el ejemplo que pones es un buen ejemplo. De hecho, el propio registro es el "hecho", y el "indicador" es el conteo de registros...
A partir de esta tabla que mencionas, podríamos tener el listado de alumnos que más asisten a clase, o el promedio de asistencia semanal... Definitivamente, sí, puede haber una tabla de hechos que sin campo de indicador... aunque no es lo habitual...
- IsaacBGWednesday, May 19, 2010
Entonces físicamente en el DW esta tabla de hechos, tendría las claves de las demás tablas de dimensión.. ningún hecho..ok..gracias,
Isaac
- PatoThursday, August 12, 2010
Estimado,
Quisiera saber lo optimo para el rendimiento de consultas sobre una tabla de hechos, teniendo en cuenta que el DW quiere responder el top 5 de eventos (diarias,mensual, semanal, etc). Si son cientos de consultas diarias, seria bueno tener tablas agregadas?
Teniendo en cuenta una tabla de hechos donde el evento es el hecho y las dimensiones tiempo, intruso, etc. (por el momento). Otra cosa, la dimension intruso tiene uno solo atributo que es el identificador unico RUT, es necesario tener la dimension intruso o seria mejor solo tener el RUT en la tabla de hechos?
Que me recomienda al respecto?... espero se entienda...
Excelente informacion la de su web..
Saludos
- BI FACILMonday, August 16, 2010
Hola Pato,
Con los datos que me das, no veo necesidad de crear tablas agregadas. Que sean cientos o miles de consultas diarias no es lo más relevante... Más importante sería saber el volumen de la tabla de hechos, y la "complejidad" del modelo de datos (si es estrella, o copo de nieve, o...). También dependerá del HW, y de tus requerimientos... ¿Puedes esperar 30 segundos para tener el resultado? ¿10 segundos? ¿3 segundos?... En fin, que no puedo ni podré responder tu pregunta. Son varias cosas que has de valorar. De entrada, yo NO haría tablas agregadas, y sólo las añadiría cuando se demuestre necesario. Espero haberte orientado...
La otra pregunta también es interesante... ¿Debes crear la "dimensión intruso" que sólo tiene el atributo RUT? Es una pregunta bastante común... ¿Se debe crear una tabla de dimensión de un solo campo? como siempre, depende, y son varias cosas que has de valorar... ¿Es un campo de muchos bytes? ¿Se utiliza en otras tablas de hechos? ¿Es probable que se añadan más atributos en el futuro? Si has respondido que sí a cualquiera de las preguntas, pienso que convendrá crear una clave subrogada y una tabla independiente...
- PatoThursday, August 19, 2010
Estimado,
Gracias por su rapida respuesta. Con respecto al consejo indicado, me faltó decir que el volumen de datos es realmente importante, ya que se grabaran diariamente cientos de registros, en las pruebas tendre que evaluar el desempeño para ver si es factible tablas agregadas (sumarizadas) por dia o mes (falta definir granularidad).
Por otro lado lo que me aconseja sobre la dimension intruso (atributo unico rut), es realmente importante para realizar graficos en el cliente web final, y no se necesita mas atributos para esa dimension, ni tampoco son muchos bytes, ahora creo que sera innecesario tenerla como dimension y ademas en la tabla de hechos (teniendo en cuenta el gran volumen que tendra la tabla de hechos)... sera mejor una dimension degenerada (atributo en la tabla de hechos), creo que seran mas optimas las respuestas... que opina?
gracias por compartir su conocimiento..
saludos!
- BI FÁCILFriday, August 20, 2010
Hola Pato,
La suerte de los que nos dedicamos al desarrollo BI es que tenemos más ocasión de probar (incluso en producción) que los que desarrollan aplicaciones de gestión...
Si el resultado de tu diseño no cubre las expectativas, ¡siempre estás a tiempo de aplicar cambios a tu diseño!
Suerte.
- ClaudiaFriday, September 09, 2011
Hola!!
Estoy dando mis primeros pasos en el análisis y diseño de cubos. Y tengo una duda en cuanto a cómo modelar los hechos.
El tema es que en mi negocio medimos la evolución de inmuebles y sus inquilinos. Entonces he identificado dimensiones como inmueble, tiempo(sería mensual), zona geográfica, inquilino, etc. El problema lo tengo cuando trato de diseñar los hechos, ya que los datos de los inmuebles que quiero medir pueden cambiar en el tiempo(su área, valor, actividad a la que se dedica,etct.) pero además cambia en el tiempo la relación entre inquilinos (un inmueble puede tener 0 o más inquilinos) ya que se puede dejar de alquilarle, el area que se le aquila cambia, el precio, entre otros.
Inicialmente he diseñado dos tablas de hechos en las que he puesto los datos que quiero cuantificar en la primera reflejo la valoración del inmueble en el tiempo, y en la segunda reflejo el cambio entre la relación del inmueble y el inquilino.
El asunto es que necesito de alguna forma asociar (sumarizar) los datos entre el inmueble y sus inquilinos, como si fuera un encabezado detalle.
Pensé luego en crear una sola tabla de hechos, pero creo que este no es el camino porque si sumo datos que corresponden al inmueble (por ejmplo el area), al mezclar los inquilinos en una misma tabla estaría duplicando los valores.
Les agradecería si pueden darme una guía.
Saludos cordiales.
- ClaudiaFriday, September 09, 2011
Hola, solo para aclarar, al duplicar los valores me refería a que si quiero sumar datos por ejemplo por zona geografica, si todos los datos existen en una misma tabla de hechos, estaría sumando datos repetidos (del inmueble) por cada inquilino asociado.
Saludos.
- Fredy RiveraTuesday, September 13, 2011
Hola Claudia...
Y porque no unes en el hecho, la relacion entre cliente e inmueble?
De manera que los inmuebles sean una dimension (son sus respectivos atributos y de tipo SCD2) y los inquilinos sean otra, de iguales caracteristicas...
Saludos!
- Fredy RiveraTuesday, September 13, 2011
Hola Claudia...
Y porque no unes en el hecho, la relacion entre cliente e inmueble?
De manera que los inmuebles sean una dimension (son sus respectivos atributos y de tipo SCD2) y los inquilinos sean otra, de iguales caracteristicas...
Saludos!
- BI FÁCILWednesday, September 28, 2011
Hola Claudia,
Planteas una pregunta interesante. Aunque creo que será mejor que la plantees en el foro. Ahí es más fácil que obtengas respuesta, y es más fácil redactar (puedes poner imágenes, negritas, listas, ...).
Si aún lees los comentarios de este artículo, pásate por el foro y tal vez ahí obtengas opiniones...