Enfoque Práctico

Continuando con el curso, el siguiente concepto por desarrollar será el diseño OLAP. Este concepto fue introducido en el capítulo anterior. Se define como el procesamiento analítico. También puede ser visualizado como una estructura que le permite al analista enfocarse en la información de negocio contextualizando desde múltiples perspectivas. Este análisis será denominada como tren de pensamiento.

¿Datamart o Datawarehouse?

Una datamart se puede definir como una base de datos desnormalizada, que se enfoca en un área específica de negocio. Puede encontrarse el datamart de ventas, finanzas, recursos humanos, producción, mercadeo, entre otros. Un datawarehouse consistiría en un conjunto de datamarts.

La estructura que conforma un datamart será objeto de análisis en este mismo módulo más adelante. Ahora bien, si el datamart es un componente del datawarehouse, ¿es lógico pensar en que el orden de contrucción es primero los datamarts y luego el datawarehouse? No necesariamente. Si hubiese que tomar una decisión, se recomendaría iniciar por un enfoque de datawarehouse, y a partir de este, derivar los datamarts.

Pero eso es la teoría. La realidad indica que el enfoque correcto no existe y dependerá de las circunstancias de cada organización en la que se esté implementando la plataforma de business intelligence. Por ejemplo, si una empresa ya ha desarrollado su datamart de ventas y finanzas, sería un poco ilógico tirar por la borda ese esfuerzo para comenzar a diseñar e implementar un datawarehouse corporativo empresarial.

La justificación para iniciar con un diseño integral se basa en que, al no tener el detalle de las necesidades de cada área o departamento es posible, al menos en el diseño, la reutilización de componentes.

Seguidamente se definirán algunos elementos o conceptos que son necesarios para el diseño de un datamart:

• Dimensión: corresponde a un conjunto de elementos con características comunes que responden a una pregunta de negocio, tal como el qué, quién, dónde, cuándo, cómo, etc. Por ejemplo, la dimensión cliente (quién), producto (qué),  tiempo (cuándo), ubicación (dónde), canal (cómo), entre otras.

• Jerarquía: una dimensión debe contener al menos una jerarquía. Esta puede contener a su vez uno o más niveles. Por ejemplo, la dimensión cliente puede tener una jerarquía que organiza los clientes por su ubicación geográfica. Por ejemplo, un nivel regional, luego se encuentran los países, ciudades y finalmente el nombre del cliente. Por otro lado, es posible que esa misma dimensión también organice los clientes por una clasificación con base en el volumen de compras, así se tienen solo dos niveles: la clasificación y el cliente como tal.

• Nivel: Si una dimensión contiene una jerarquía que se ha estructurado tipo árbol, se denominará nivel a cada peldaño de la estructura. Continuando con el ejemplo indicado anteriormente, la dimensión cliente, en la jerarquía por ubicación geográfica tiene el nivel Región, el nivel País, el nivel Ciudad y el nivel Cliente.

• Categoría: por último, las categorías corresponde a los elementos individuales que van a poblar los niveles. En el ejemplo anterior, en el nivel País, se encuentran las categorías USA, Costa Rica, Colombia, Venezuela, etc. En el nivel ciudad se tiene New York y Miami (como descendientes de USA); San José, Heredia y Cartago (para el caso de Costa Rica); Bogotá y Medellín (Colombia); y finalmente Caracas, Barquisimeto, Valencia y Maracaibo para el caso de Venezuela.

El secreto de un buen diseño es contar con las dimensiones correctas conformadas por las jerarquías correctas. Es recomendable comenzar con un diseño sencillo y posteriormente agregar jerarquías y niveles a medida que el negocio va asimilando la funcionalidad del BI. No es conveniente comenzar con un diseño complejo que más bien generará rechazo en los usuarios finales.

También es buena práctica incluir al usuario final en las pruebas de los cubos que se van generando. Es sumamente valioso la retroalimentación que se puede obtener en esta etapa. Cambios tan sutiles como la etiqueta (caption) de un nivel o el fundir o dividir una dimensión. Esto solo es posible si el usuario está comprometido con el proyecto desde una etapa temprana.

El concepto de dimensión tienen la característica de que las categorías generalmente van a ser alfanuméricas. Es una tendencia mas no una regla. Es posible que bajo algunas circunstancias estas correspondan a valores numéricos.

Para completar de responder las preguntas de negocio (cuándo, qué, quién, dónde, cómo, etc.) es necesario cuantificar. Para ello, existe una dimensión particular que se conoce como Medidas.

Esta dimensión (algunos expertos no consideran las medidas como una dimensión) se encarga de enlazar todas las anteriores. Por ejemplo, un tren de análisis puede dar como resultado que se encuentre que el cliente ABC, compró el producto XYZ, en los meses Ene, Feb y May en los últimos dos años con una tendencia de Precio creciente en un 20% para le mercado local.

Por lo tanto, las medidas son categorías de la dimensión que responden a la pregunta de negocio ¿cuánto? Al unir dimensiones con medidas, se obtienen objetos que se denominarán cubos, y los cubos conformarán un área de análisis particular del negocio, la cual se denominará datamart.

Arquitectura OLAP

Los datamarts han venido implementándose con modelos de datos tipo estrella. Es decir, una tabla de hechos (medidas) central y las tablas de dimensiones alrededor. Bajo este esquema deberían existir al menos dos dimensiones, siendo 10 el número máximo recomendado.

En las tablas de hechos deberán encontrarse valores numéricos de dos tipos:

• Surrogates keys: o llaves surrogadas. Corresponde a un valor numérico que sirve de llave para obtener el valor respectivo de la dimensión en la tabla correspondiente. Habrá solo un surrogate key por dimensión por cada registro indicado en la tabla de hechos.
• Medidas: como se indicó en la sección anterior, corresponden a los valores que cuantifican el análisis.

Además de estar formada por valores numéricos en un 99% de las ocasiones, las tablas de hechos también tienen las siguientes características:

• Son tablas de alto volumen de datos. Se manejan valores en el orden de los cientos de miles hacia arriba.
• Es frecuente encontrarlas fraccionadas por tiempo. El particionamiento con base en el tiempo tienen la ventaja de permitir trabajar con los valores recientes del contexto de una forma práctica y mantener los históricos aislados. Esto no quiere decir que se modifiquen datos.
• La relación con la dimensión tiempo se hace a través de una llave (surrogate key) inteligente. Este punto fue discutido anteriormente acá.

Una variante poco utilizada, pero existente es el empleo de modelos tipo copo de nieve (snow flake), los cuales permiten tener más de una tabla físicamente en la base de datos para una dimensión. Dependerá de la experiencia del arquitecto durante el diseño para identificar la circunstancia adecuada para implementar un diseño de copo de nieve.

Si se está realizando un diseño datamart-datawarehouse, se notará a partir de la implementación del segundo datamart que algunas dimensiones pueden ser utilizadas en más de un área de análisis. Por ejemplo, la dimensión Cliente podría ser utilizada tanto por el área de ventas como por finanzas. De ahí surge el concepto de dimensión compartida.

Por el contrario, si se está diseñando un datawarehouse, todas las dimensiones serán compartidas desde el momento inicial. No es sino hasta entrar en los detalles de cada datamart que se identificarán particularidades que evitan compartir una dimensión en más de un lugar.

¿Cuál es la forma correcta de hacer? Dependerá de las circunstancias. Parece ser más escalable un enfoque que considera toda la organización desde su concepción, no obstante, no implica que dos o más datamarts ya implementados no puedan ser unificados en un gran datawarehouse.

Una vez realizado el diseño de los componentes tipo estrella o copo de nieve en papel, es hora de realizar el diseño físico. Ese tema será desarrollado en el próximo módulo.