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...

Buenas.
Después de varias horas de dedicación he terminado de actualizar en su totalidad la versión On Line de HEFESTO que se encuentra en Dataprix: ver hefesto online...
Por otra parte, Nicolas Gutierrez, se ha tomado la molestia de convertir HEFESTO en formato ePub (formato estándar para archivos e-book): descargar hefesto.epub...

En la anterior entrega de esta serie sobre cómo construir un datawarehouse ya introducía el concepto de las “claves subrogadas”.
Una clave subrogada es un identificador único que se asigna a cada registro de una tabla de dimensión. Esta clave, generalmente, no tiene ningún sentido específico de negocio. Son siempre de tipo numérico. Preferiblemente, un entero autoincremental.
Habitualmente, el sistema operacional ya utiliza sus propias claves, aunque suelen ser de tipo carácter y tienen un sentido específico para los empleados de la compañía. Por ejemplo, el código BCN puede utilizarse para referirse a Barcelona, o el DNI de cada empleado puede ser la clave única de la tabla de empleados...

IBM ha anunciado hoy que ha llegado a un acuerdo para adquirir Netezza y fortalecer así más aún su oferta de Business Intelligence y analítica empresarial. Netezza aprovecha las ventajas que ofrece la virtualización y comercializa con éxito 'Apliances' de Data warehouse preconfiguradas, con lo que permite reducir mucho los tiempos de puesta en marcha de sistemas de Data Warehousing, y asegurar un alto rendimiento y facilidad de administración, incluso en sistemas complejos que manejen gran cantidad de datos...

En los anteriores comentarios de esta serie sobre cómo construir un datawarehouse, explicaba las características de las dimensiones y las jerarquías. Sin embargo, estaba omitiendo un aspecto principal de estas tablas.
La información de las dimensiones no es estática, ya que puede modificarse en el operacional por diferentes motivos. Por ejemplo, puede corregirse la fecha de nacimiento de un cliente, o éste puede cambiar de ciudad, o una delegación puede asignarse a un delegado diferente, etc. ¿Cómo debe gestionarse esta información?
En primer lugar, debe tenerse en cuenta que el tratamiento que se realizará dependerá de cada dimensión y de las necesidades del negocio...

Las dimensiones se agrupan en jerarquías mediante relaciones uno-a-muchos. Una población agrupa a muchos clientes. Una provincia agrupa a muchas poblaciones. Una región está formada por varias provincias. Etcétera. Las jerarquías típicas, que aparecen en cualquier sistema Business Intelligence, son:

...

Evidentemente, pueden existir jerarquías adicionales, o incluso puede haber diferentes maneras de jerarquizar una misma información. En particular, es habitual la existencia de diferentes jerarquías de producto (lo que es una "pesadez" muchas veces necesaria, otro día lo comentaré…).

Ofrece aplicaciones preconfiguradas para una serie de casos de uso geoespaciales, incluido el almacenamiento, la edición, visualización, análisis y manipulación de datos...

Denominamos dimensiones a aquellos datos que nos permiten filtrar, agrupar o seccionar la información. El término "dimensión" sigue teniendo un cierta connotación técnica, por lo que muchas personas lo siguen denominando "atributo", "característica", "propiedad", "campo", o incluso "cuadradito azul" (en el caso de una instalación de BO).

Algunas aplicaciones Business Intelligence utilizan el término "dimensión" como equivalente a "jerarquía" (especialmente en bases de datos multidimensionales). De esta manera, se habla de la dimensión geográfica que agrupa los diferentes niveles de continentes, países, regiones, provincias y localidades...

Como podemos observar, gracias a los post del blog, la Inteligencia Artificial está presente en el quehacer diario de los diferentes sectores de actividad, o incluso en nuestro tiempo libre: videojuegos o deporte.

Esta serie de artículos se publicó inicialmente en el portal de Business Intelligence de @bifacil. Dado la buena acogida de esta serie sobre cómo construir un datawarehouse, he decidido publicarlo también en mi blog de DATAPRIX. Espero que os guste.

El origen de esta serie es un artículo muy interesante de Ralph Kimball (¿Algún despistado que no lo conoce?) donde detalla los 12 errores más comunes en la construcción de un datawarehouse.

Los doce errores más comunes en la construcción de un datawarehouse son...