Datamart
icono-linkedin  icono-twitter  icono-blog  icono-youtube  icono-facebook
logo-hi-spins-mobile-2

Hi-Spins Data Mart: El Business Intelligence de Software Greenhouse

 

Del Query a Data Mining

En la inform谩tica, tanto en hardware como en software se pueden distinguir claramente distintas generaciones de productos, seg煤n surgen, tienen su auge y posteriormente su declive las distintas tecnolog铆as. Al principio, en la prehistoria de la inform谩tica, nos colmaba de satisfacci贸n el haber impreso los recibos de n贸mina o las facturas. M谩s adelante, los usuarios empezaron a interesarse por la posibilidad de explotar para su trabajo la informaci贸n almacenada en los sistemas transaccionales. Entonces, han surgido dos tecnolog铆as muy importantes, como son los queries (software de consultas) y EIS (Sistemas de Informaci贸n para la Direcci贸n).
 

Los proyectos EIS

Un t铆pico proyecto EIS, comienza por una fase previa muy extensa, en la cual se define la informaci贸n que necesita tener la alta direcci贸n en su 'tablero de mandos'. A continuaci贸n se desarrolla un proyecto, cuyo objetivo es extraer de las bases de datos operativas la informaci贸n necesaria, sintetizarla y presentarla, generalmente de una manera muy espectacular, tal como se lo merecen 'los consumidores', los m谩s altos ejecutivos de una gran empresa. Los resultados suelen ser muy satisfactorios, queda un solo problema, el muy alto coste de este tipo de proyectos. Pero peor a煤n, la evoluci贸n del mercado y de la empresa demanda que el EIS de la empresa tambi茅n evolucione y el coste del mantenimiento es igual de alto como el del proyecto inicial. Por este mismo motivo el EIS no es una herramienta apropiada para el an谩lisis de datos a nivel departamental.
 

Los productos Query

Al realizarse el an谩lisis detallado de ventas, costes, m谩rgenes, rotaciones etc., las preguntas que se plantea un usuario var铆an constantemente. Por cierto, tard贸 bastante tiempo, para que los inform谩ticos nos di茅ramos cuenta que esto no es un capricho del usuario, sino una necesidad objetiva del negocio. Aqu铆 no hay un tablero de mando. No se constata el 'qu茅 esta pasando', se analiza el 'porqu茅 puede estar pasando'. Por esto los queries son un software con una capacidad de extraer la informaci贸n sin ning煤n proyecto previo. La informaci贸n se presenta en forma poco espectacular, muchas de las consultas son para 'usar y tirar.
 
Los queries son un avance fabuloso tanto para el inform谩tico como para el usuario. El usuario puede por s铆 solo extraer informaci贸n de la base de datos, sin esperar que los inform谩ticos, generalmente ya bastante agobiados por otros proyectos, programen la salida en el formato solicitado por el usuario.
 

La evoluci贸n hacia Data Warehouse

Una vez descubierta la posibilidad de obtener informaci贸n sin programar, su uso aumenta constantemente. Pero el verdadero desbordamiento se produce con las hojas electr贸nicas bajo Windows y la posibilidad de alimentarlas con la informaci贸n de la base de datos operativa. Ahora los usuarios pueden no solamente acceder a la informaci贸n, sino realmente trabajar con ella. Adem谩s las hojas electr贸nicas permiten presentar la informaci贸n en una forma muy atractiva.
 
Aparece un nuevo tipo de productos que permite al usuario, directamente desde su PC y trabajando con interfaz gr谩fica, solicitar la informaci贸n a la base de datos central. La utilidad del binomio query - hoja electr贸nica es tan enorme, que en muchas instalaciones la ocupaci贸n del hardware por los queries representa un porcentaje elevado. Este fen贸meno constituye la mejor prueba de la importancia que tiene para una empresa el trabajar con la informaci贸n. Sin embargo, la masificaci贸n del uso de las consultas, llega a poner en evidencia algunas deficiencias intr铆nsecas de este tipo de productos.
 
En primer lugar, la velocidad. Los tiempos de respuesta son muy lentos y se convierten en un freno importante del an谩lisis de la informaci贸n, puesto que cada consulta resuelta, genera nuevas preguntas. Los tiempos de respuesta lentos, interrumpen el hilo del razonamiento del usuario, dificultando as铆 la tarea de profundizar el an谩lisis. Pero adem谩s de la lentitud, tambi茅n la alta ocupaci贸n de los recursos de hardware por los queries constituye un problema. La sobrecarga aumenta a煤n m谩s la lentitud de las consultas y baja el rendimiento de las propias aplicaciones operativas. Esta situaci贸n conduce a constantes y costosos upgrades de ordenadores.
 
La proliferaci贸n de queries no s贸lo ha llegado a colapsar muchos ordenadores, sino que tambi茅n absorbe un volumen significativo de los recursos humanos de los departamentos de inform谩tica. Ello se debe al hecho de que la petici贸n de la consulta se especifica en t茅rminos de la base de datos. Hay que utilizar los nombres de columnas y tablas y por tanto, hay que saber c贸mo est谩n dise帽adas las bases de datos. Muchas veces hay que definir joints, e inclusive, tablas especiales para poder unir informaci贸n de una aplicaci贸n con otra, cuando sus tablas no son compatibles. Demasiadas veces, el resultado de una petici贸n no es el pretendido por el usuario. Por todo esto, en las instalaciones, donde no se haya hecho una inversi贸n considerable para que los usuarios adquieran un grado de cultura inform谩tica relativamente elevado, hay que dedicar recursos importantes al soporte de los queries.
 
Otro problema es la inconsistencia de la informaci贸n obtenida. Frecuentemente, los usuarios omiten alg煤n factor importante al formular sus peticiones de consulta. Como resultado, en el mejor caso hay que repetir las consultas, modificando la petici贸n, en el peor se trabaja con informaci贸n distorsionada. Y no es nada raro que en una reuni贸n de ventas o un consejo, diferentes personas se presentan con informaci贸n distinta. M谩s de una reuni贸n ha degenerado en un intento de conciliar la informaci贸n que traen consigo los distintos participantes.
 

Data Warehouse

Todos estos problemas no son deficiencias de productos determinados, ni mucho menos culpa de los desarrolladores. Se producen, porque una tecnolog铆a llega al l铆mite de sus posibilidades. La soluci贸n ya no se puede producir por la v铆a del 'm谩s de lo mismo'.
 
Los problemas de velocidad y de sobrecarga de procesadores se deben al hecho que las bases de datos relacionales han sido dise帽adas para el trabajo transaccional y no para atender consultas. El objetivo de obtener cualquier informaci贸n en cualquier momento, existan o no los 铆ndices necesarios en la base de datos, es una tarea demasiado dif铆cil para las bases de datos relacionales. Por ello, ha surgido la tecnolog铆a Data Warehouse que se apoya en otro tipo de bases de datos. Se define un nuevo entorno, el OLAP (Procesamiento Anal铆tico en Tiempo Real) en contraste con el existente OLTP (Procesamiento de Transacciones en Tiempo Real).
 
Las bases de datos para OLAP tienen una estructura totalmente distinta, orientada a alta velocidad de recuperaci贸n de la informaci贸n para consultas. Se les suele llamar bases de datos multi-dimensionales o tambi茅n 'hiper-cubos'. Los conceptos como Zona, Producto, Vendedor o Per铆odo de Venta se convierten en las m煤ltiples dimensiones de estos cubos, y en las intersecciones de sus coordenadas, est谩n almacenados los valores correspondientes. De esta manera, los Data Warehouse homogenizan la informaci贸n en unas estructuras que permiten acceder m谩s f谩cilmente a cualquier dimensi贸n y de all铆 navegar mediante funciones espec铆ficas tales como 'la rotaci贸n del cubo' (detallar determinada informaci贸n siguiendo el criterio de otra dimensi贸n, como por ejemplo, detallar zona por producto); 'drill down' (bajar al siguiente nivel, como por ejemplo, detallar zona por comercial) etc.
 
Estas nuevas estructuras de datos, adem谩s de responder a las consultas bastante m谩s r谩pidamente, lo hacen con menor utilizaci贸n de recursos. Pero sobre todo, al trabajar sobre otra base de datos, se separan los procesos transaccionales de los procesos de consulta, colocando los procesos de consulta generalmente en otro ordenador, a veces con caracter铆sticas especiales de procesadores.
 
La idea de la coexistencia de dos bases de datos que almacenan esencialmente la misma informaci贸n estructurada en formas distintas, seg煤n el tipo de proceso a que se est茅n sometiendo los datos, resultaba inicialmente un tanto chocante. No es de sorprenderse, puesto que los inform谩ticos est谩bamos ense帽ados a perseguir con insistencia el inalcanzable objetivo de la integraci贸n total de las aplicaciones y la eliminaci贸n de todo tipo de redundancias. En la actualidad, esta idea est谩 apoyada por la existencia de cada vez m谩s evidencias de los buenos resultados y tambi茅n por la baja de los precios de hardware. Adem谩s en muchas de las aplicaciones, la replicaci贸n de la informaci贸n no tiene que ocurrir estrictamente en tiempo real y en aquellos casos donde s铆 sea indispensable, tenemos a mano otra nueva tecnolog铆a: la de 'mirroring'. Los productos que usan esta tecnolog铆a son capaces de replicar datos y objetos en tiempo real, con garant铆a de una sincronizaci贸n exacta. En este punto tambi茅n conviene hacer la observaci贸n, que la redundancia es uno de los conceptos inherentes de Data Warehouse, utilizado para aumentar las velocidades de acceso.
 
Lo dicho en el p谩rrafo anterior no significa de ninguna manera que un proyecto de definici贸n de un Data Warehouse y su alimentaci贸n es algo simple. Todo lo contrario: los grandes Data Warehouse son sistemas sumamente sofisticados y para su implantaci贸n hace falta un conocimiento muy profundo, tanto del producto, como de la problem谩tica de usuario. La forma de plantear la distribuci贸n de datos en un Data Warehouse tiene un impacto decisivo en su rendimiento. Hay muchos proyectos que han resultado una decepci贸n porque se subestimaron estos factores.
 
La homogeneizaci贸n de las estructuras de datos tiende a resolver otro gran problema de los queries: El del soporte requerido por los usuarios. La tecnolog铆a Data Warehouse facilita que el usuario especifique sus peticiones de consulta en su lenguaje propio, en vez de usar la terminolog铆a de base de datos. (Esto, cuando los dise帽adores del producto logran evitar la tentaci贸n de sustituir una jerga inform谩tica 'plana' por otra 'multi-dimensional', que puede resultar a煤n m谩s dif铆cil para los mortales.)
 
Finalmente, el problema de inconsistencia de la informaci贸n elaborada por los queries, tambi茅n puede encontrar su soluci贸n en Data Warehouse: Cuando se define el contenido del Data Warehouse, es necesario definir con exactitud la correspondencia de conceptos entre la base de datos transaccional y el Data Warehouse. A partir de all铆, cualquier usuario que seleccione una consulta como 'Venta del Producto X en el mes corriente con detalle por Clientes', obtiene la misma respuesta.
 

El avance de Data Warehouse

Es natural que una nueva tecnolog铆a, con un potencial para resolver problemas tan importantes como los sufridos por los usuarios de los queries y sus departamentos de inform谩tica, tenga un 茅xito notable. Las predicciones de crecimiento del mercado hablan de 700% de incremento inter-anual en pr贸ximos 5 a帽os y textualmente cada mes aparecen nuevos productos. En grandes empresas, los productos Data Warehouse han asumido la mayor铆a de funciones antes realizadas con queries y tambi茅n una parte de las funciones del EIS. La eliminaci贸n total de los queries normalmente no es pr谩ctica ni debe ser el objetivo, puesto que siempre existir谩n consultas puntuales. Como en todos los proyectos, aqu铆 tambi茅n es aplicable la regla 80 / 20 - el 煤ltimo 20 % cuesta 80% del esfuerzo. Por tanto, el proponerse el objetivo que todas las consultas tienen que ser satisfechas por el Data Warehouse, encarece el proyecto de una forma muy significativa.
 
Las funciones de los EIS que conviene que sean absorbidas por Data Warehouse son aquellas, que requieren una presentaci贸n menos espectacular y tienen una variedad de posibles consultas muy grande. Absorbiendo estas funciones, un Data Warehouse puede producir muy significativos ahorros de coste de mantenimiento del EIS. De hecho est谩n surgiendo nuevos productos que combinan la tecnolog铆a Data Warehouse con la opci贸n de definir output tipo EIS. Es una combinaci贸n muy l贸gica y a la vez potente, que le da un alto valor a los productos que la usen.
 

Data Mart: el hermano menor de Data Warehouse

A pesar de las grandes ventajas de Data Warehouse, parecen existir unas importantes barreras para su utilizaci贸n en empresas de tama帽o mediano. Los productos Data Warehouse han nacido para resolver problemas de an谩lisis de grandes masas de informaci贸n, en empresas donde una peque帽a diferencia en el valor de una variable, puede afectar la cuenta de resultado con unas diferencias de millones de d贸lares.
 
Los productos y proyectos Data Warehouse est谩n dimensionados para este tipo de empresas, contando con hardware muy potente (muchas veces especializado) y la masiva intervenci贸n de consultores externos, expertos en la realizaci贸n de la puesta en marcha. Un proyecto de este tipo resulta en todos los aspectos excesivo para un departamento de ventas que necesita analizar la informaci贸n de 500.000 - 3.000.000 de l铆neas de pedidos, o una cantidad equivalente de informaci贸n financiera, que es lo normal para una empresa mediana.
Para resolver este tipo de necesidades han surgido los Data Mart, productos que utilizan la tecnolog铆a Data Warehouse adaptada a las necesidades de las empresas medias. Data Mart se destaca por una definici贸n de requerimientos m谩s f谩cil y r谩pida. Tambi茅n se simplifica el desarrollo de todo el mecanismo de su base de datos y con ello baja substancialmente todo el coste del proyecto, as铆 como su duraci贸n. Normalmente, Data Mart resuelve aplicaciones a nivel departamental, aunque en ocasiones se desarrolla una aplicaci贸n que integre todas ellas y proporciona las funciones de un EIS.
 
Los esfuerzos de los desarrolladores de productos Data Mart, junto con los mejoras del 铆ndice precio/rendimiento del hardware, suben constantemente el l铆mite de penetraci贸n de Data Mart, permitiendo asumir proyectos m谩s y m谩s importantes. La simplicidad de los proyectos de Data Mart y el menor coste en comparaci贸n con Data Warehouse, significan una ventaja competitiva muy grande a favor de Data Mart, donde el mercado de los dos tipos de productos se solapa.
 

Data Mining

Data Mining es aparentemente hasta ahora la forma m谩s avanzada de extraer la informaci贸n de las bases de datos. En su m谩xima expresi贸n, ya no es el usuario quien formula las consultas. 'Agentes inteligentes' recorren las bases de datos y buscan en ellas posibles relaciones. Veamos un ejemplo distinto al que casi siempre se ha visto en las revistas, (el de la relaci贸n de la hora en que se compran los pa帽ales y la cerveza por cajas):

Si en la base de datos est谩 la informaci贸n de venta de agua mineral por d铆as y las condiciones climatol贸gicas, lo obvio es que existir谩 una relaci贸n y no se necesita data mining para cuantificarla. Sin embargo si esta relaci贸n cuantificada la comparamos con la del a帽o pasado, seguro que no coincidir谩. 驴Qu茅 ha cambiado? Aqu铆 es d贸nde empieza tener sentido utilizar data mining. Las preguntas que surgen aqu铆 son: 驴Cu谩ntos de los factores que han producido el cambio est谩n reflejados en nuestra base de datos y con qu茅 precisi贸n? 驴Hasta qu茅 punto se las pueden arreglar los agentes inteligentes con las deficiencias del dise帽o de una base de datos y la falta de su normalizaci贸n? 驴Cu谩nto tratamiento previo hay que darle a la base de datos, para que tenga sentido empezar con data mining y cu谩ntas posibles relaciones 煤tiles se perder谩n en este tratamiento? Pero indudablemente, data mining nos puede aportar ideas muy importantes. La cuesti贸n es qu茅 coste de hardware, software y recursos humanos tienen.
 
Parece por todas las preguntas sugeridas y muchas otras que seguramente quedan en el tintero, que aunque se hacen muchas presentaciones de data mining a empresas medianas y hasta peque帽as, este tipo de tecnolog铆a, por alg煤n tiempo, solo puede resultar rentable para empresas muy grandes.
 

Conclusiones

He tratado aqu铆 de escribir en forma sumamente resumida sobre las distintas herramientas, usadas para poder trabajar con la informaci贸n que se oculta en nuestras bases de datos transaccionales, sus caracter铆sticas y su evoluci贸n. Las caracter铆sticas de cada tipo de producto tal como se han comentado, muchas veces no se presentan en forma tan tajante como en este art铆culo, puesto que existen productos h铆bridos. Por otro lado la forma de implantar un producto y la calidad profesional de los instaladores, pueden significar una diferencia enorme entre dos instalaciones de un mismo producto. Si el art铆culo les ha ayudado a pensar qu茅 tipo de preguntas se debe hacer a los proveedores de este tipo de herramientas, considero que haya cumplido su misi贸n.
 
Aparte de esto nunca sobra volver a recordar las reglas b谩sicas, tales como la regla 80 / 20, la que distintos tipos de tarea requieren herramientas distintas y que para cada tama帽o del problema hay que calibrar el tama帽o de la soluci贸n (mejor un martillo y un destornillador que un martillo m谩s grande). Ni el uso de las m谩s avanzadas tecnolog铆as se escapa a las reglas b谩sicas del sentido com煤n.
 

para-mas-info-software-greenhouse
Para m谩s informaci贸n sobre Proyectos de Business Intelligence, no dudes en consultarnos
 
DOCUMENTACI脫N HI-SPINS

Presentaci贸n Hi-Spins - Flash Video
hi-spins-flash-video


hi-spins-novedades-10.3.xHi-Spins   Novedades 10.3.x

(Para versiones anteriores, no dudes en consultarnos)

CONTACTO
500 caracteres restantes
D脫NDE ESTAMOS
BARCELONA
Figueres, 8
08022 Barcelona
MADRID
Santo 脕ngel, 110
(Entrada por Ctra. de Canillas, 16)
28043 Madrid
Centralita: +34 93 253 16 50
Soporte clientes: +34 93 212 15 66

S5 Box (1/2-50%, 3/4-40, 5/6-30, 7/8-20, 9/10-80%)

Login

Register

You need to enable user registration from User Manager/Options in the backend of Joomla before this module will activate.