Creación de una solución de Business Intelligence: problemas entre bastidores

En la tercera entrega de su serie de inteligencia comercial, Dan Pratte se enfoca en las actividades involucradas en el diseño y llenado de un almacén de datos, detrás de escena.

Reconociendo que la mayoría de las organizaciones son ricas en datos pero pobres en información, el problema central que los sistemas de inteligencia de negocios (BI) buscan resolver es convertir la «paja» de datos de una organización en oro de información. El crisol del éxito toma la forma de una simple pregunta: ¿está entregando la información correcta a la persona correcta en la forma correcta en el momento correcto para avanzar en las metas estratégicas de su organización? Puede sonar como un cliché, pero es importante hacer esta pregunta con frecuencia al planificar su sistema.

En mi último artículo, cubrí una arquitectura común para una solución de BI (que se muestra en la Figura A a continuación). Como puede verse en este diagrama, el cubo multidimensional es el corazón del sistema. Las actividades que incluyen la construcción del cubo pueden denominarse actividades de «segundo plano», mientras que las actividades relacionadas con la distribución de la información del cubo a los usuarios finales pueden denominarse actividades de «primer plano». En este artículo, me referiré a las actividades y problemas detrás de escena de una solución de BI. (Las actividades de la sala principal serán el tema de futuros artículos). Tenga en cuenta que estos artículos están pensados ​​como artículos introductorios, ya que cualquier tema fácilmente podría llenar un libro.

Figura A

Esta es una arquitectura conceptual común para las soluciones de Business Intelligence (BI).

Almacenes y Bazares
Como punto de calificación, aunque uso el término «almacén de datos», los conceptos arquitectónicos se aplican igualmente a los «mercados de datos», aunque estos últimos difieren en enfoque y alcance. Los almacenes de datos tienden a abarcar todo el alcance y estar orientados a la empresa, y pueden ser bastante complejos. Bazaar, por otro lado, es más simple y está más enfocado a un área comercial específica. Por ejemplo, la eficacia de las campañas de marketing de su organización se mide mejor mediante un data mart.

Tenga en cuenta que, si se diseñan correctamente, los data marts individuales pueden combinarse con el tiempo para crear un almacén de datos empresarial. Sin embargo, generalmente se recomienda usar un solo data mart temporalmente porque le permite traer rápidamente información crítica en línea de una manera más simple que crear un almacén de datos.
No te pierdas las dos primeras partes de esta serie:

Los artículos futuros cubrirán las actividades de front-office de BI, así como las herramientas y técnicas de BI.
El proceso de creación de una solución de BI
A nivel conceptual, el proceso de creación de una solución de BI es simple, comenzando con la replicación de datos de origen (a menudo de múltiples sistemas operativos) en una sola base de datos relacional o almacén de datos. Puede pensar en un almacén de datos como una serie de «instantáneas» tomadas a intervalos regulares que representan con precisión el estado de alguna medida comercial. Es fácil ver, por ejemplo, que al combinar instantáneas individuales de las ventas diarias, puede recuperar rápidamente una vista semanal o mensual. (También tenga en cuenta que debido a que el almacén de datos es un registro histórico, sus datos solo se pueden recuperar como información de solo lectura).

En el pasado, el proceso en segundo plano terminaba llenando un almacén de datos relacional y ejecutando consultas SQL complejas directamente en él. Sin embargo, en una implementación moderna, querrá convertir el almacén relacional en un cubo multidimensional.

Esto lleva a una pregunta obvia: ¿por qué se necesita un cubo si proporciona los mismos datos que su almacén de datos relacional subyacente? Los cubos ofrecen varias ventajas, tales como:

• Respuesta de consulta más rápida.
• Un lenguaje de consulta más intuitivo. (SQL puede volverse difícil de manejar cuando se trata de estructuras multidimensionales).
• Controles de seguridad integrados (quién puede acceder a qué datos).

Los cubos también permiten la flexibilidad de asignar bits físicamente a través de los sistemas, lo que permite un ajuste fino del almacenamiento y el acceso. Finalmente, en cuanto al almacenamiento, los cubos suelen contener datos comprimidos, lo que hace un uso eficiente del almacenamiento en línea.

Problemas de calidad de los datos de origen
Apuesto a que los problemas de calidad de los datos de origen serán sus mayores dolores de cabeza y deben abordarse antes de que se pueda desarrollar algo particularmente útil o significativo a partir de la información. Este es un ejemplo de lo que quiero decir: un cliente mío quería identificar tendencias relacionadas con el costo de limpieza de equipos industriales específicos. Los datos de origen contienen solo un campo de texto de forma libre «Descripción» como identificador del dispositivo. El problema es que no se utilizan los descriptores de dispositivo estándar. Me he encontrado con cosas como «Reactor No. 32» y «Reactor, Número 32», refiriéndose al mismo dispositivo. Obviamente, la falta de un identificador único crea problemas cuando desea «dividir» los datos por dispositivos individuales.

En este caso, podemos volver atrás y corregir manualmente los descriptores (quizás 600 000 registros) o considerar simplemente corregir el sistema de entrada de datos para que los datos subsiguientes sean correctos. En última instancia, las necesidades del negocio determinarán cuánto dolor estamos dispuestos a sufrir y qué enfoque tomaremos en última instancia.

El punto aquí es que este tipo de problemas son más comunes que infrecuentes: casi siempre tiene que hacer algún tipo de validación o transformación creativa de datos al copiar datos de una base de datos de origen a un almacén de datos. Sin embargo, puede solicitar la ayuda de las herramientas de extracción, transformación y carga (ETL), de las cuales los Servicios de transformación de datos de Microsoft (o DTS, como parte de SQL 2000) son una buena opción.

mirar la pelota
Las actividades de fondo giran en torno al diseño y el llenado del almacén de datos. A partir de ahí, es un proceso bastante sencillo de construir cubos multidimensionales utilizando las herramientas y técnicas actuales.

A estas alturas, debería quedar claro que durante el proceso de diseño del almacén de datos, debe ir y venir constantemente para ver el panorama general para no pintarse en una esquina.

Concéntrese siempre en el problema comercial (el problema que está tratando de resolver) mientras observa la realidad de los datos de origen, que es lo que más importa al final para determinar lo que puede y no puede hacer.