Diseño de un data warehouse: tabla de hecho

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.

Data Warehousing, Data Warehouse y Datamart

¿Qué pasa cuando hemos identificado la necesidad de mejorar los sistemas que dan soporte a la toma de decisiones en nuestra organización? Rápidamente, nos hallamos en un contexto que si bien tiene puntos en común con nuestro modelo de negocio y nuestras aplicaciones transaccionales, nos deja descolocados. Más de la mitad de términos que se usan en las presentaciones de productos nos son desconocidos.

Así que de nuevo nos situamos desde el marco de establecer significados etimológicos. Recordemos que dimos ya las definiciones de Inmon y Kimball. Para empezar es necesario tener claro que significan los términos Data Warehousing, Data Warehouse y Data Mart que participan en las fases iniciales de implantación de una herramienta Business Intelligence.

Definición de Data Warehousing

Entendemos por Data Warehousing el proceso de extraer y filtrar datos de las operaciones comunes de la organización, procedentes de los distintos sistemas de información operacionales y/o sistemas externos, para transformarlos, integrarlos y almacenarlos en un depósito o almacén de datos (Data Warehouse, en inglés) con el fin de acceder a ellos para dar soporte en el proceso de toma de decisiones de una organización. Es decir, la finalidad es convertir los datos operacionales en información relacionada y estructurada, homogénea y de mayor calidad, identificada convenientemente y que se mantenga en el tiempo, es decir, los datos más recientes no sustituyen a los precedentes, pero tampoco se acumulan de cualquier manera, sino que se suelen mantener con un mayor nivel de detalle los datos actuales, y de manera más agregada los datos anteriores. Se pretende crear un círculo virtuoso para la información.

Definición de Data Warehouse

Un Data Warehouse proporciona una visión global, común e integrada de los datos de la organización, independiente de cómo se vayan a utilizar posteriormente por los consumidores o usuarios, con las propiedades siguientes: estable, coherente, fiable y con información histórica. Al abarcar un ámbito global de la organización y con un amplio alcance histórico, el volumen de datos puede ser muy grande (centenas de terabytes). Las bases de datos relacionales son el soporte técnico más comúnmente usado para almacenar las estructuras de estos datos y sus grandes volúmenes. Normalmente en el almacén de datos habrá que guardar información histórica que cubra un amplio período de tiempo. Pero hay ocasiones en las que no se necesita la historia de los datos, sino sólo sus últimos valores, siendo además admisible generalmente un pequeño desfase o retraso sobre los datos operacionales. En estos casos el almacén se llama almacén operacional (ODS, Operational Data Store).

Definición de Data Mart

Podemos entender un Data Mart como un subconjunto de los datos del Data Warehouse con el objetivo de responder a un determinado análisis, función o necesidad y con una población de usuarios específica. Al igual que en un data warehouse, los datos están estructurados en modelos de estrella o copo de nieve y un data mart puede ser dependiente o independiente de un data warehouse. Por ejemplo, un posible usos sería para el data mining.

¿Qué diferencia existe entonces entre un data mart y un data warehouse? Su alcance. El data mart está pensado para cubrir las necesidades de un grupo de trabajo o de un determinado departamento dentro de la organización. Es el almacén natural para los datos departamentales. En cambio, el ámbito del data warehouse es la organización en su conjunto. Es el almacén natural para los datos corporativos comunes.

Continuaremos, en una futura entrada, definiendo los conceptos necesarios y con la mira puesta a hablar sobre el diseño de un Data Warehouse.