Unificar los hechos

Submitted by Crono on 19 October, 2010 - 12:04
 
En la definición de datawarehouse de Bill Inmon (y en todas las definiciones posteriores de cualquier menda aficionado al BI, como el autor de este blog de Business Intelligence en español) se señala que un DWH es un repositorio donde la información corporativa se encuentra "integrada".
A warehouse is a subject-oriented, integrated, time-variant and non-volatile collection of data in support of managements decision making process (Bill Inmon, 1990)

La cuadratura del círculo. Fundamental en el Business Intelligence

Efectivamente, cualquier empresa tiene múltiples sistemas operacionales, cada uno de ellos con sus propios maestros y su propia información. Uno de los objetivos del DWH es unificar toda esa información dispersa en un único repositorio. Sin embargo, no se trata sólo de juntar todos estos datos, el objetivo es unificarlos, integrarlos y conformarlos, es decir, dar la misma forma y el mismo significado a dimensiones y hechos aparentemente distintos (en inglés dicen "conform information").
Por ejemplo, una empresa de distribución puede tener dos canales de ventas a través de los cuales vende los mismos productos (venta al mayor y venta retail). Habitualmente, la gestión de estos dos negocios la realizarán personas diferentes de diferentes departamentos, y cada uno de ellos tendrá sus sistemas informáticos con diferencias significativas entre ellos. Es muy diferente el negocio minorista del negocio mayorista.
Pues bien, en este ejemplo, uno de los retos de la creación del DWH sería la unificación de estos dos negocios, porque sin duda existirán usuarios que querrán conocer la "facturación", y la facturación evidentemente incluye las ventas al mayor y al ventas retail. Para realizar esta unificación, las dos tablas de hechos deberán compartir las mismas dimensiones, y deberán definirse con precisión los términos de cada negocio para que resulten agregables entre sí… Incluso, podría ser recomendable unificar los dos hechos en una misma tabla de hechos, donde la dimensión "tipo de venta" permitiese diferenciar las ventas al mayor de las ventas retail.
A esta unificación se refiere el penúltimo error de esta serie sobre cómo no construir un datawarehouse:
Error 2: No unificar los hechos entre distintas tablas de hechos
Tal como comentaba, independientemente de que los hechos se modelicen en una o varias tablas de hechos, estos deben tener la misma forma. Deben tener dimensiones compartidas que permitan la comparación y/o agregación entre sí. Si se quiere sumar o dividir la información de distintos hechos, estos deben tener la misma forma y deben haberse cargado aplicando los mismos criterios.
Otro ejemplo de "conformar" adecuadamente los hechos sería aplicar los mismos criterios al cargar las compras y las ventas. Si se quiere calcular el cociente de ventas sobre compras, deberemos asegurarnos que en los dos indicadores se están considerando los mismos productos. No debemos, por ejemplo, olvidarnos de aquellos productos que sólo se venden por Internet o que forman parte de un negocio secundario de la compañía. Si estos productos se incluyen en las ventas, deben incluirse también en las compras (aunque provengan de fuentes distintas).

 

 

Contenido relacionado

  • Unificar las dimensiones

     

    Unificar las dimensionesEn la anterior entrada de esta serie sobre cómo construir un datawarehouse se describía la importancia de unificar los hechos. Ahora hablaremos de unificar las dimensiones. No es más importante una cosa que la otra. Las dos son imprescindibles.
    Sabemos que es normal que dentro de una compañía convivan muchas aplicaciones informáticas, cada una de ellas con sus propios maestros. Una función importante del DWH es la unificación de estas aplicaciones en unos maestros únicos...
     
     
  • Tablas de hecho

    Tablas de hechoDenominamos “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...

     

     

     

  • Tablas agregadas

    Tablas agregadasEl datawarehouse tiene, y debe tener, todo el detalle de información en su nivel atómico. Así, las ventas estarán detalladas por fecha, cliente, producto y punto de venta. Rápidamente nos daremos cuenta que estaremos trabajando con un volumen muy importante de información. Por poner algún ejemplo, en los sectores de distribución retail, telecomunicaciones o banca es habitual encontrarse con datawarehouses con miles de millones de registros...

     

     

  • Cómo no construir un datawarehouse

    Cómo no construir un datawarehouseEsta 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...

     

  • Los mejores recursos para seguir la actualidad de SAP Business Objects

    Los mejores recursos para seguir la actualidad de SAP Business ObjectsSon tantas las novedades que se producen en el día a día de las soluciones Business Intelligence que es dificil encontrar buenos recursos que nos encaucen esta información.

    Para el caso de SAP Business Objects, os ponemos los enlaces que consideramos imprescindibles...

     

 

 

 

Gestion del Conocimiento    |    Business Intelligence y Analítica    |     Bases de Datos    |      ERP     |      CRM      |     Tendencias tecnológicas