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.

Sobre Data Warehouse Lifecycle Management (DWLM)

Hay veces que nos olvidamos que en la base de cualquier sistema de Business Intelligence existe un data warehouse. ¡Hombre, qué exagerado me dirás! Pero es que al final de lo único de lo que tienen constancia nuestros usuarios es de la parte final. Traducción: del reporting, de los cuadros de mando, de los mapas geográficos, del análisis OLAP, del balanced Scorecard,…

A veces incluso podemos caer en el craso error que un sistema Business Intelligence es un simple proyecto cerrado que una vez terminado se queda en un lugar sin sufrir ningún cambio. Y sin embargo, ¿no es cierto que nuestra organización evoluciona? Entonces, tal cual debe pasar con nuestro sistema BI para que refleje nuestra organización. Deberíamos tener un Business Intelligence Lifecycle Management (BILM). Sin duda, es un aspecto a tener en cuenta.

Ah, atención no penséis que loa acrónimos son en balde. La economía del lenguaje es importante una vez introducidos los conceptos.

Pero vayamos en la dirección de lo que quería hablar. Me gustaría centrarme en el corazón de un sistema BI: en el data warehouse.
A este nivel, estaremos hablando de Data Warehouse Lifecycle Management (DWLM).

Pongámonos en contexto. Hemos ya terminado nuestro primer proyecto de BI en nuestra organización. Ello se ha traducido en que una de nuestra áreas se realiza una explotación correcta y beneficiosa de la información. El éxito de este primer hito nos impulsa con brío y como CIO decidimos continuar con una siguiente fase mucho más ambiciosa. Queremos que un tanto por ciento importante de las áreas de nuestra organización entre en el segundo proyecto y que toda la información este conformada y conforme con la evolución de nuestra organización.

Llegados hasta este punto debemos mirar atrás un momento. Tenemos un data mart que evolucionará a un data warehouse. ¿Cómo continuará ofreciéndonos el rendimiento actual? ¿Cómo se podrá conseguir cruzar la información? ¿Cómo se debe plantear la evolución de sistema existente?

Estamos hablando sin duda alguna de:

  • Cuál debe ser la arquitectura del data warehouse: por ejemplo, es necesario tener un DW central y un data mart por cada departamento.
  • Si es necesario o no el uso de tablas agregadas: hemos detectado unas consultas más lentas de lo normal, hemos identificado las consultas típicas.
  • Si es necesario el uso de Raid

Uhm, quedémonos un momento en el uso de RAID en DW.

El rendimiento a nivel I/O es uno de los aspectos importantes en el diseño de un data warehouse. Esto contrasta con lo que sucede para los sistemas OLTP donde el cuello de botella potencial depende de los patrones de acceso y la carga de trabajo del usuario. Por definición:

  • Cuando un sistema presenta restricciones a nivel I/O, se dice que está limitado o tiene un cuello de botella I/O.
  • Cuando un sistema presenta restricciones a nivel de CPU, se dice que está limitado o tiene un cuello de botella CPU.

Los arquitectos de bases de datos frecuentemente usan sistemas RAID (Redundant Arrays of Inexpensive Disks) para evitar cuellos de botella I/O y proporcionar una mayor disponibilidad de datos. Existen múltiples implementaciones RAID algunas de ellas consistentes a nivel de mejoras por parte de fabricantes para superar defectos propios de diseño.

En definitiva existen muchos aspectos que debe tenerse en cuenta. ¿Los tenemos?

Volveremos en el futuro a tratar sobre todos estos interesantes temas.