Esquema en estrella

El esquema en estrella es la representación más importante del modelo dimensional. En el modelo dimensional encontramos hechos y dimensiones.
Todo objeto de análisis es un hecho. Este hecho se representa en el modelo dimensional en forma de tabla de hechos o fact table. Los hechos son analizados a su vez, a través de las dimensiones o componentes (tantas como dimensiones participen en la descripción del hecho), que se representan en el modelo dimensional a partir de las tablas de dimensiones.

Si realizamos este esquema mental (tabla de hechos en el centro y tablas de dimensiones alrededor), todo parece dibujar una forma de estrella, origen del nombre.

Los hechos tienen columnas de datos denominadas métricas y las dimensiones tienen columnas que representan los niveles de jerarquías.

Un ejemplo: Tenemos un hecho archifamoso: ventas. Y sus dimensiones: Tiempo, localización y producto. Alguna métrica de ventas seria número de unidades vendidas y valor de la venta. En cuanto a los niveles de jerarquía de las dimensiones encontraríamos día, semana y mes (para el tiempo), almacén, población, provincia (para la localización), producto, familia, departamento (para los productos). Creo que así queda más claro:

Para acabar, decir que las métricas son indicadores que nos permiten cuantificar los hechos y siempre hay que intentar buscar estas métricas que sean aditivas. Una métrica es aditiva cuando es sumarizable por todas sus dimensiones. Otro ejemplo: Una fabrica tiene 50 unidades en el almacén en Enero. En Febrero tiene 30 y en Marzo 10. Esta métrica no es sumarizable, ya que 50+30+10 no da el inventario final del trimestre. Esto suele pasar bastante con la dimensión TIEMPO.

Metadatos

Los metadatos de un DWH están formados por aquellas tablas, campos y registros que mantienen información sobre los datos del propio DWH. En las bases de datos operacionales también existen estos tipos de datos, pero están ocultos de cara al usuario, así que la gran diferencia con los DWH esta en que en estos se pueden ver y se puede interaccionar con ellos. Existen herramientas en el mercado que hacen una gestión automática de los mismos a través de los diferentes procesos ejecutas, pero también se puede realizar mantenimientos manuales.

Los metadatos como tal, contienen información como la procedencia de la información, la periodicidad de refresco, su fiabilidad, forma de cálculo, etc. y una cosa importante, si los datos cambian, los metadatos tienen que cambiar con ellos.

Además los sistemas BI almacenan en ellos información vital como las relaciones de negocio que se establecen entre atributos (jerarquías), operaciones de agrupación a realizar con los diferentes indicadores definidos, etc.

Los objetivos que deben cumplir los metadatos, según el colectivo al que va dirigido, serían:

- Soportar al usuario final, ayudándole a acceder al Data Warehouse con su propio lenguaje de negocio, indicando qué información hay y qué significado tiene. Ayudar a construir consultas, informes y análisis, mediante herramientas de navegación.

- Soportar a los responsables técnicos del Data Warehouse en aspectos de auditoria, gestión de la información histórica, administración del Data Warehouse, elaboración de programas de extracción de la información, especificación de las interfaces para la realimentación a los sistemas operacionales de los resultados obtenidos, etc..

Data Warehouse: ¿Alguien habló de redundancia de datos?

Dicen que hay un mito de que tener y mantener un DWH es mantener repositorio con datos duplicados, ya que estos se extraen de las Bases de datos operacionales.
Evidentemente el origen de estos datos es ciertamente uno que ya poseemos, pero podríamos decir que para nada encontramos una relación directa entre estos datos y los de la BD operacional. Un dato cuando pasa un DWH sufre alteraciones como:

• Normalización
• Depuración
• Creación de metadatos asociado
• Sello de tiempo
• Postproceso para integrarlo como dato agregado, resumido o calculado.

Entonces, ¿podemos hablar del mismo dato? Difícilmente vamos a entender que es el mismo.
Además en los DWH no se cargan todos los datos de la BD operacionales, solo aquellos que se consideran necesarios para el proceso de apoyo a la toma de decisiones.

Otro punto importante a tener en cuenta es, que en el espacio histórico (años), las BD operaciones y el DWH solo comparten un tiempo (meses) relativamente pequeño.
Evidentemente se puede asumir que el mantenimiento del DWH tiene un coste y que los datos ya los teníamos en las otras BD…. pero el resultado final, tanto en informes como en análisis deja libre de toda duda de que los datos del DWH no pueden entenderse como una simple réplica.

Data Warehouse en profundidad

Empieza el primer tema hablando de los Data Warehouses, los almacenes de datos.
Los sistemas tradicionales empezaron a tener problemas para satisfacer las necesidades de los usuarios y de esta problematica, surgen los Data Warehouse como sistemas de apoyo a la toma de decisiones, en que los datos de una organización se transforman en información estratégica. Ayudan a su vez a disponer de un acceso sencillo e inmediato a determinada información de negocio estructurada y de calidad.

Acceder a los datos directamente en sistemas operacionales (del dia a dia, no DWH) suponía algunos problemas:

• Conocer lenguajes como SQL
• Rendimiento
• Los datos no están preparados para las consultas necesarias.
• No suelen tener un horizonte histórico como para detectar tendencias o realizar seguimientos.

Data Warehousing versus Data Warehouse
Data Warehousing es el proceso de crear y mantener un almacén central de datos, es decir un Data Warehouse.

Características de un DWH

• Orientado a temas: en contra de la orientación a procesos de los sistemas operacionales, facilitando su acceso y entendimiento.
• Integrado: Los datos de un DWH son íntegros en unidades de medida, nombres, codificación, etc...
• Variante en el tiempo: Se guardan datos históricos (del orden de años) que facilitan la evaluación e identificación de tendencias.
• No volátil: Los valores permanecen en el DWH sin modificación.

Diferencias entre un DWH y una BD Operacional
La principal diferencia entre un Data Warehouse y una BD operacional es su objetivo, el primero esta orientado a las operaciones del día a día y el segundo al análisis y la toma de decisiones. Por tanto podemos preveer que uno recibe multitud de transacciones repetitivas y conocidas y el DWH consultas masivas, puntuales y no conocidas. También como diferencia encontramos el rendimiento, la volatilidad, los usuarios (más expertos), estructura (relacional versus multidimensional), alcance histórico, detalle de los datos y por último el volumen, mucho mayor en un DWH.

Arquitectura de un DWH
Cuando hablamos de la arquitectura, nos referimos a la manera de representar la estructura global de los datos, los procesos y las interfaces de usuario. Las bases de esta arquitectura son:

• Mezclar los datos de la BD operacional con otras fuentes de datos, incluidas las externas.
• Información fácil y transparente
• Proveer al usuario de un acceso universal a los datos (apoyado en lenguaje SQL)
• Metadatos: De donde proviene un dato, que formato tenía, significado, como se ha calculado, etc...
• Construir y mantener el directorio de datos.
• Gestión de copia y de replicación: todos los procesos necesarios para asegurar la calidad de los datos.

Estructura del DWH
¿Qué nivel de detalle tienen los datos? Normalmente difiere de los sistemas de producción por contener agregaciones y por guardar al detalle los datos de otros años.
Dentro del DWH también encontramos los famosos Metadatos, que los podríamos definir como un directorio para ayudar a ubicar los contenidos, una guía de donde provienen los datos y una descripción de los algoritmos utilizados para calcular las agregaciones pertinentes.

Data Mart
Un Data Mart cumple los mismos principios que un Data Warehouse, pero difiere principalmente en el alcance del mismo, que seria de un departamento o grupo de personas y no de toda la organización. De Data Marts podemos encontrar de dos tipos: dependientes e independientes según si los datos son extraidos del DWH o directamente de los sistemas operacionales (a la larga un desastre).

Explotar un Data Warehouse
El reto es sacar datos y convertirlo en información, que se dice pronto... y encima querer crear una ventaja empresarial. Este reto va des de la edición de informes hasta una minería de datos avanzada, con análisis multidimensional. Por tanto, un DWH es un medio, no un fin en si mismo. Ningún proyecto debería tener como finalidad construir un DWH, sino obtener información... si bien, cabe decir que el construirlo debe suponer una gran meta.
Para la explotación encontramos tres técnicas principalmente: Query and reporting, OLAP (análisis multidimensional) y Minería de datos . La primera consiste en realizar informes y generar consultas flexibles, con una interfaz gráfica, permitiendo también escribir total o parcialmente la consula en SQL (o similar). La segunda (OLAP) consiste en realizar análisis desde un conjunto de perspectivas o dimensiones. Muy adecuada para grandes volúmenes de datos.
La tercera consiste en el descubrimiento de conocimiento no accesible de manera directa... si no que se encuentra oculto, por ejemplo, buscar patrones de información en los datos.

El valor del cliente

El Business Intelligence puede ayudarnos en saber que clientes son los más rentables. Una buena política de clientes establecería 4 categorías:

• Categoría A: Clientes muy rentables.
• Categoría B. Clientes rentables
• Categoría C: Clientes poco rentables
• Categoría D: Clientes con un valor nulo o negativo para la compañía.

En cada grupo se establecen políticas diferentes, siempre teniendo en cuenta un factor: el valor que estos podían tener en el futuro.
Categoría A: Política para mantener la satisfacción del cliente. Tener un contacto con todos ellos: carta, email, teléfono, solo para preguntar si están contentos, si tienen alguna sugerencia para el servicios, etc.. (Aproximadamente un 15% de nuestros clientes)

Categoría B: Política para aumentar la rentabilidad. Los clientes con alto valor futuro en esta categoría hemos de tenerlos entre algodones, ya que son buena parte del futuro de nuestra compañía. Un análisis de los servicios que tienen y por similitud, los que les podrían interesar, es una buena manera de seguir con esta plácida relación. Otra buena política es ampliar la oferta de productos, quizas no son mejores clientes porque no les ofrecemos lo que necesitan. (Aproximadamente un 25% de nuestros clientes)

Categoría C: Tener una política más agresiva de ventas, estos clientes tienen que decantarse por el grupo B o en el D... Los cliente con buenas perspectivas de futuro en esta categoría, podríamos mantenerlos esperando una mejor oportunidad a medio plazo. En este grupo encontraremos un 50% de nuestros clientes, pero que representa solo el 10% de nuestra facturación. No hay que tener miedo.

Categoría D:Suponen un 10% de nuestros clientes. Aquí el desafío es intentar cambiar la situación. mejorando sus productos. Si esto no fuera posible, la mejor opción es no contar con estos clientes. Como siempre, es mejor tener pocos y buenos, que muchos y malos.

Shopping 2.0

Los clientes no somos tontos, pero a veces se nos vende humo, quizás una manera de tapar la poca información que tenemos de ellos... un poco de inversión en BI no vendría nada mal para acercar más los anuncios al target de cliente que van dirigidos.
Por ejemplo, se escucha un anuncio por la radio sobre un centro comercial, en donde dicen, se practica shopping 2.0. Supongo que nada más lejos de la realidad... un comercio 2.0 debería tener una participación activa del usuario, cosa que en las tiendas no pasa... somos seres pasivos, nos gusta lo que hay o fuera, a otra tienda.

Una tienda física 2.0 debería tener:

• Junto a cada articulo, un lugar donde poder apuntar comentarios del producto, así como preguntas o dudas al respecto.
• Los productos tendrían que poderse buscar o conseguir ordenados por el voto de los usuarios. En el escaparate se encontrarían los más valorados.
  
• Los clientes tendrían que poder apuntar sus productos favoritos, así otro día que vuelvan los pueden volver a comprar sin olvidarse ninguno.
• Evidentemente buscadores repartidos por la tienda... con TAGS como fashion, novedad, sin azúcar, niños, etc...
• Ranking de productos más vendidos, comentados, valorados, etc...
• Diferentes entradas a la tienda: una normal y otra muy simple, en donde encontrar solo las últimas novedades.
  

Realmente una tienda con todo eso, si que seria shopping 2.0 de verdad...

¿Qué debe "almacenar" un DataWarehouse?

Me ha parecido super interesante el debate del blog Sistemas Decisionales sobre que debe almacenar un DW.
La verdad... nunca me había planteado tan a fondo como una gran duda... de entrada y sin leer los comentarios pensé "Datos, of course". Después de leer todos los comentarios, me decidí por datos estructurados por eso de que estos se guardan en una cierta estructura.
Creo que se le puede dar una vuelta más. Conocimiento o Información yo creo que un DW lo contiene, pero depende de la persona a la que va dirigido simplemente. El DW solo contiene el dato (o dato estructurado), pero para alguien que sepa interpretarlo el DW tien conocimiento e información, pero al final depende de la persona que lo usa, no del DW en si, por tanto, entiendo que este en si mismo no contiene ni información, ni conocimiento.

Destacaría dos puntos interesantes de la conversación:

• Los usuarios de la empresa, están de paso. Debemos tener cuidado de adaptar el DW a ellos.
• ¿Podría la capa semántica estar contenida en el propio DW? es decir el modelo de negocio podría ser creado a partir de una reglas incluidas en el DW y "en el aire" crearse el modelo, así, este permitiría poderse cambiar sin problemas, a partir de modificar las reglas. Quizás es parte del futuro...