Los KPI constituyen un conjunto de métricas enfocadas en medir aquellos aspectos de performance organizacional que impactan en mayor forma en el éxito actual y futuro de la empresa. En cualquier organización sólo podemos hallar pocos KPI (generalmente no más de 10) que cumplan con ciertas características; ellas son:
• Métricas no financieras (que no puedan expresarse en cifras monetarias)
• Alta frecuencia, generalmente 24/7 (KPI no se miden mensualmente)
• Bajo supervisión directa del GG o directivos del alto staff
• Empleados conscientes de la importancia de la métrica y de las acciones correctivas que requiere
• Responsabilidad ligada directamente a los responsables individuales o a equipos.
• Efecto crítico sobre la mayorías de las restantes métricas que puedan incluirse en el BSC
• Originadotes de acciones positivas sobre la totalidad de la empresa
Las métricas monetarias no son las mejores a la hora de buscar lo que realmente puede impulsar el cambio. Esto es así porque las métricas monetarias expresan resultados. Pero los inductores de dichos resultados son otras acciones relacionadas con marketing, operaciones, productos, servicios, etc. que son las que terminan en resultados.
Los KPI más importantes deben ser monitoreados en forma constante, casi diríamos 24/7. Si Ud. selecciona un KPI de frecuencia mensual probablemente sea un indicador de resultados en lugar de un inductor de acciones. KPI son generalmente métricas de acción hacia el futuro, en contraposición de métricas que expresan el resultado ya pasado, histórico. Un error muy común al diseñar un BSC es seleccionar indicadores que expresan datos históricos. Esos indicadores no son KPI ni lo serán nunca. Por ejemplo el indicador Satisfacción de Cliente, que toma datos sobre encuestas tomadas a los clientes durante los últimos 6 meses no es un KPI.
Cuando una métrica es un verdadero KPI cuenta con la dedicación y atención constante del GG para su seguimiento. Tener que defender un error ante el GG es algo que a ningún empleado le gusta hacer ni repetir pues compromete su carrera en la empresa. Las soluciones a los problemas se hallan mucho más rápido cuando el GG está atento al problema.
Un buen KPI dice de inmediato qué acciones deben ejecutarse de inmediato. Por ejemplo, los KPI de impuntualidad en los vuelos de BA eran una manera de decir a todo individuo involucrado en el proceso que había que hacer algo rápido para solucionar el problema. Desde operarios de limpieza, caterers, aeromozas, tripulantes hasta pilotos y oficiales de tráfico trabajan en equipo y producían soluciones mágicas para ahorrar un minuto aquí y otro allá sin menoscabar la calidad del servicio o incluso aumentarlo.
Un KPI debe ser lo suficientemente claro como para identificar perfectamente al responsable del mismo. En otras palabras el GG debe poder tomar el teléfono y preguntar ¿Por qué? Directamente a quien puede solucionar el problema. En ese sentido las métricas financieras no son buenos KPI pues no se las puede vincular directamente con un responsable sino que son el resultado del trabajo de muchos responsables. ¿Podemos imaginar al GG de una gran corporación llamar a su gerente financiero y decirle: Juan, quiero que aumentes la tasa de retorno de capital usado en el día de hoy??
Un correcto KPI tendrá impacto sobre todas las Perspectivas e influirá en casi todo otro tipo de métrica que esté en el Balanced Scorecard. Por ejemplo reducir la demora en la salida de vuelos mejorará las métricas sobre mejoras en los servicios de tierra, ya que el personal de esa área perderá menos tiempo en “apagar incendios” que los distraen de tareas básicas de atención a los pasajeros.
Cuatro tipos de métricas
De mi trabajo de investigación, capacitación e implementación llego a la conclusión que hay cuatro tipos definidos de métricas relacionadas con la performance:
Tipos de métricas de performance
IRC: reflejan los resultados históricos críticos. Son ideales para comunicar los resultados alcanzados.
IP: Indicadores de performance, indican al personal qué hacer
IR: Indicadores de resultados, indican al personal qué se ha hecho.
KPI: Indican al personal y directivos qué debe hacer para aumentar la perfomance drásticamente.
El gráfico anterior es como “pelar una cebolla” y describe la relación entre los cuatro tipos de métricas. La corteza exterior nos muestra el estado general de la cebolla: cuánto ha recibido de sol, agua y nutriientes; y cómo se la ha tratado desde la cosecha hasta la góndola del supermercado. Por ello la corteza exterior es un IRC, indicador de resultado crítico. Las hojas internas representan a varios indicadores de performance y resultado mientras que el núcleo central es el corazón de la cebolla y es donde se encuentran los KPI en nuestra analogía.
La regla 10/80/10
Kaplan y Norton recomiendan no más de 20 KPI, y Jeremy Hope no más de 10. Para ayudar a todos los involucrados en la definición de la cantidad de KPI hemos creado la regla 10/80/10. Esto implica que una empresa debe trabajar con alrededor de 10 ICR, con 80 indicadores IP e IR y con no más de 10 KPI. Pocas veces se necesitan más métricas que éstas, en incluso menos en muchas ocasiones.
ICR, Indicadores Clave de Resultados
La característica más común entre los ICR es que ellos son el resultado de muchas acciones. Nos dan una clara idea de si la empresa está tomando el camino adecuado y de si se alcanzan los objetivos estratégicos buscados. Sin embargo ellos nos comunican al personal y directivos sobre qué hacer para lograr los efectos deseados. Esto sólo lo pueden hacer los IP y los KPI.
Algunos ejemplos de ICR tomados equivocadamente como KPI son:
• Satisfacción del cliente
• Ganancias netas antes de impuestos
• Rentabilidad por cliente
• Satisfacción del personal
• Tasa de retorno del capital
El hecho de separar los KPI del resto de las métricas tiene un profundo impacto en la forma en que se monitorea la performance. Los KPI están relacionados con la estrategia básica de la empresa mientras que el resto de las métricas están más relacionadas con aspectos de management.
La velocidad de un auto nos permite realizar la siguiente analogía: Los directivos sólo quieren conocer la velocidad a la que el auto (empresa) está yendo. Los gerentes ejecutivos necesitan más información pues la velocidad del auto depende de aspectos claves como las RPM del motor o el nivel de marcha elegido. De hecho hay veces que los gerentes ejecutivos pueden estar concentrándose en algo completamente distinto como cuán económico es la marcha (ej. Un reloj que muestra la eficiencia en el uso de combustible o cómo está funcionando el motor. Estos son indicadores de performance completamente distintos.
Indicadores de Performance y de Resultados (IP & IR)
La porción de 80 métricas que están entre los KPI y los ICR son los llamados Indicadores de Performance (IP) y los Indicadores de Resultados (IR). Los IP si bien son importantes no son clave para el negocio. Estas métricas ayudan a los distintos departamentos y responsables a alinearse con la estrategia de la empresa. Los IP complementan a los KPI y se muestran en los distintos tableros que componen un Balanced Scorecard empresarial.
Algunos ejemplos de IP son:
• Porcentaje de aumento en ventas en el segmento del 10% de los clientes top
• Numero de recomendaciones de staff adoptadas en los últimos 30 días
• Quejas recibidas de clientes selectos
• Cantidad de visitas a clientes planeadas para los próximos 15 días
• Entregas demoradas a clientes selectos
Algunos ejemplos de IR son:
• Resultados netos de principales productos
• Ventas diaries
• Ventas semanales a clientes selectos
• Cobranzas realizadas en la semana
• Cantidad de visitas a clientes potenciales
viernes, 21 de noviembre de 2008
lunes, 17 de noviembre de 2008
El Datawarehouse y el Business Intelligence en Gobierno
Introducción
El Datawarehouse es un deposito donde se almacenan los datos que la organización utiliza para saber como esta funcionando. El almacenamiento de datos concentra mucha información proveniente de los procesos, de los sistemas operativos y financieros de los GRP’s y CRM’s entre otros.
El Datawarehouse es un componente del modelo de Bussines Intelligence, en cuya base se encuentra el almacén, la infraestructura conformada por la base de datos donde se integra toda la información; sobre él están las herramientas para presentar informes y hacer consultas; mas arriba esta la estrategia de inteligencia de negocios formada metodologías que se ciñen a las mejores practicas, la cultura organizacional y las habilidades de desarrollo con las que se cuenta para sacar mayor provecho de la infraestructura y de las aplicaciones.
La Inteligencia de Negocios consiste en convertir datos en información útil, en utilizar datos para conocer el desempeño de una organización. Él vinculo entre la inteligencia de Negocios y la tecnología es fundamental, porque es la zona donde se traducen los datos en información útil para la organización. Es un puente que transforma, depura e integra datos.
Los Fracasos
La mayoría de los fracasos se debieron a que las organizaciones adoptaron una perspectiva equivocada: lo vieron como un asunto tecnológico y no como un asunto institucional. Las personas que estaban a cargo de las tecnologías de la información propusieron hacer un Datawarehouse "Lo Construimos y se lo entregamos a la Empresa"
En segundo lugar, muchos buscan solucionar demasiados problemas de un solo golpe, en lugar de alcanzar la madurez con las aplicaciones, las herramientas y la metodología.
Un tercer problema esta relacionado con la persona que autoriza el financiamiento, Puede irse de la organización y entonces alguien puede decir: "¿Por qué estamos gastando esta cantidad de dinero?" No entiendo, el presupuesto se está acabando y tengo otras prioridades.
El cuarto problema surge con el cambio de requisitos
Finalmente esta el tema de la falta de capacitación de los usuarios. Aunque en teoría haya un buen DataWarehouse y se hayan implementado exitosas herramientas en sus aplicaciones, si no se capacita a los usuarios para que utilicen los datos para tomar decisiones, jamás lo usaran y todo mundo acabara diciendo que no sirve porque no añade valor le dará la espalda y dirá que fue un fracaso.
La interoperabilidad
El Datawarehouse puede ser utilizado para incorporar y reunir la información de todas las dependencias y conformar así una visión integral de la operación de la institución.
Los datos se encuentran en múltiples sistemas; hay que traducirlos a un idioma común, es decir; hay datos que generan el procesador central, el GRP, el CRM y todos están en un lenguaje distinto.
La calidad de los datos
El mejor indicador de que los datos cuentan con suficiente calidad es que sean susceptibles de ser utilizados por la organización, pero las tecnologías de la información no pueden decidir cual es el nivel de calidad necesario que deben tener los datos.
Es la parte directiva de la institución la que debe indicar cuáles son las metas de calidad que deben tener los datos, y por lo tanto deben especificarlos y luego dar la instrucción para que se desarrollen en esa dirección, si estos desarrollos se dan desde la perspectiva de toda la organización, si hay alguien que realmente dirija el proyecto desde un punto de vista integral, la eficacia del Datawarehouse se multiplicara y encontrara éxito.
Los gobiernos deben aprender a administrar información y crear conocimiento
El volumen de información que se produce ha crecido tanto, que la eficiencia en el manejo de los factores de la producción depende cada vez más de la manera en que se administra y planifica el ciclo de creación y utilización de la información. La información es una activo, pero su utilización no esta ligada a los procesos que la generan: se produce en un tiempo y lugar distinto al de su utilización y aplicación, por lo que su valor esta determinado por quien la usa, y no por quien la produce. Los gobiernos no están exentos de esta situación.
En el Reporte Mundial del Sector Publico de 2003, la Organización de las Naciones Unidas (ONU) indica que uno de los factores clave para el éxito de los e-gobiernos es que los gobiernos aprendan a administrar información para crear conocimiento. Dicho de otro modo: para que los gobiernos generen valor público deben utilizar eficientemente la información, esto es, información que genere conocimiento.
Los gobiernos son el mayor, retenedor y proveedor de información, y agrega que en un mundo globalizado donde los mercados enfrentan una creciente competencia, la innovación es más importante que la
Productividad o la eficiencia en costos, y que tanto los individuos como los gobiernos no solo tienen que resolver nuevas ecuaciones para alcanzar sus objetivos, sino que estas ecuaciones contienen un porcentaje cada vez mayor de variables desconocidas. Este entorno exige que los gobiernos eleven su capacidad para administrar información y crear conocimiento; de lo contrario enfrentaran una situación de abundancia información y déficit de conocimiento.
La Inteligencia de Negocios
Para enfrentar este reto los gobiernos, implantan complejos sistemas de información gracias a las tecnologías de la información y la comunicación (TIC). Él desafió es que las instituciones implementen estrategias de administración de información y creación de conocimiento que combinen herramientas tecnológicas, procesos aplicaciones y mejores practicas. Una estrategia de esta índole pondrá a prueba, típicamente, a la organización en su conjunto: su gente, su cultura organizacional, sus procesos y aplicaciones que generen información, y su infraestructura tecnológica.
Las estrategias encaminadas a resolver los problemas de administración de información y creación de conocimiento se encuadran bajo el concepto de inteligencia de negocios o BI por sus siglas en ingles (Bussiness Intelligence).
En México los gobiernos hacen esfuerzos para que cualquier persona y en cualquier momento disponga de información publica, pero se hace cada vez más evidente que nuestra sociedad requiere, mas bien, no solo el acceso a la abundante información publica, sino que sea confiable y precisa, lo que significa confiar en la fuente que provee esa información.
El gobierno esta obligado a realizar una serie e esfuerzos que tendrán una alta probabilidad de fracaso si no se reconoce que la incumbencia en el tema no es solo de las áreas informáticas y/o tecnológicas, sino de toda la organización.
El reto no es resolver el problema tecnológico de múltiples bases de datos, sino de resolver el problema estructural que consiste en la abundancia de información y de la falta de conocimiento al interior de las instituciones.
El riesgo de no hacer nada
La compleja política y la escasez presupuestaria que enfrentan los gobiernos en México exigen que los proyectos de BI. Sean evaluados tanto por los beneficios que representan como por el riesgo de no llevarlos a cabo. Por esto, lo más recomendable es que las estrategias BI se aborden bajo el enfoque mixto de maximización de beneficios y minimización de riesgos. Las estrategias deben maximizar la eficiencia en el manejo de la información y la eficacia de los procesos y aplicaciones; pero al mismo tiempo deben minimizar el riesgo de la rigidez institucional motivada por la inexistencia de información accesible para generar los conocimientos necesarios, así como el riesgo de tener procesos y sistemas redundantes.
La Inteligencia Institucional
No es lo mismo Inteligencia de Negocios que la Inteligencia Institucional porque los indicadores para medir el desempeño de las organizaciones en cada caso no son iguales
"La información es el capital más valioso de toda organización"
La Información sobre el desempeño de una organización es la única fuente para evaluar su funcionamiento, y la herramienta primaria para planificar su futuro. Sirve para medir la eficiencia de las inversiones y su retorno en beneficios para corregir oportunamente los posibles errores y desviaciones, y permite generar un ciclo virtuoso de ejecución y evaluación permanente, siempre ligado a la operación diaria de los programas de trabajo.
Esta actividad no quedó restringida al mundo empresarial. Para la administración pública se creo el concepto Inteligencia Institucional, que gana en precisión y pertinencia al advertí en su desarrollo las complejidades y rasgos característicos de la tarea gubernamental.
La diferencia más importante entre la Inteligencia de Negocios y la Inteligencia Institucional es la medición del Retorno de Inversión (ROI por sus siglas en ingles). Para las instituciones gubernamentales, el ROI no es únicamente un balance de resultados financieros. Su medición tiene indicadores tales como: más y mejor educación, más y mejores empleos, o reducción de la pobreza, por citar algunos ejemplos. De ahí que los datos que sirven para medir el desempeño de los gobiernos no se encuentran en las oficinas públicas, sino en la calle, en las ciudades y pueblos, o de dicho de otro modo, en la satisfacción ciudadana y en una mejor calidad de vida para todos.
Una segunda gran diferencia entre la implementación de una estrategia de Inteligencia de Negocios y una Inteligencia Institucional, es la heterogeneidad de las fuentes de información. Para una empresa, cruzar diferentes datos sobre su operación puede resultar complejo, pero cuando se trata de organismos gubernamentales las fuentes son mucho más diversas. El gobierno es la suma de una gran variedad de dependencias, organismos, empresas paraestatales, organizaciones sociales y ciudadanas, entre otras, que trabajan en distinto ámbitos territoriales.
Homologar la diversidad
¿Es posible entonces, homologar peras con manzanas? ¿Existe la herramienta tecnológica que haga posible cruzar datos tan diversos de Instituciones tan disímiles?
Conclusiones
El interés del gobierno en aplicaciones de Inteligencia Institucional se debe a que estas herramientas son capaces de integrar información proveniente de distintos sistemas. Las dependencias pueden tener datos dispersos tanto en sistemas tecnológicos avanzados como en programas elementales tipo Excel. Pero gracias a esta herramienta podrán extraer automáticamente la información relevante que requieren aquellos que tomen decisiones.
Construir herramientas de análisis
La información seleccionada y extraída de las bases de datos se presenta al usuario en su escritorio a través de pantallas dinámicas, con amplias capacidades para analizar y proyectarla de manera multidimensional, o bien, combinarla con distintos parámetros que arrojen mejores interpretaciones.
Medir el desempeño y los resultados.
Al provenir la información de las bases de datos operativas de la dependencia, el funcionario se asegura que esta conociendo información de la fuente original, sin "maquillajes" ni sorpresas en cuanto a sí veracidad, por su parte, el responsable de los datos sabe que únicamente podrá mejorar los resultados de su información si el conjunto de la institución mejora su desempeño.
El Datawarehouse es un deposito donde se almacenan los datos que la organización utiliza para saber como esta funcionando. El almacenamiento de datos concentra mucha información proveniente de los procesos, de los sistemas operativos y financieros de los GRP’s y CRM’s entre otros.
El Datawarehouse es un componente del modelo de Bussines Intelligence, en cuya base se encuentra el almacén, la infraestructura conformada por la base de datos donde se integra toda la información; sobre él están las herramientas para presentar informes y hacer consultas; mas arriba esta la estrategia de inteligencia de negocios formada metodologías que se ciñen a las mejores practicas, la cultura organizacional y las habilidades de desarrollo con las que se cuenta para sacar mayor provecho de la infraestructura y de las aplicaciones.
La Inteligencia de Negocios consiste en convertir datos en información útil, en utilizar datos para conocer el desempeño de una organización. Él vinculo entre la inteligencia de Negocios y la tecnología es fundamental, porque es la zona donde se traducen los datos en información útil para la organización. Es un puente que transforma, depura e integra datos.
Los Fracasos
La mayoría de los fracasos se debieron a que las organizaciones adoptaron una perspectiva equivocada: lo vieron como un asunto tecnológico y no como un asunto institucional. Las personas que estaban a cargo de las tecnologías de la información propusieron hacer un Datawarehouse "Lo Construimos y se lo entregamos a la Empresa"
En segundo lugar, muchos buscan solucionar demasiados problemas de un solo golpe, en lugar de alcanzar la madurez con las aplicaciones, las herramientas y la metodología.
Un tercer problema esta relacionado con la persona que autoriza el financiamiento, Puede irse de la organización y entonces alguien puede decir: "¿Por qué estamos gastando esta cantidad de dinero?" No entiendo, el presupuesto se está acabando y tengo otras prioridades.
El cuarto problema surge con el cambio de requisitos
Finalmente esta el tema de la falta de capacitación de los usuarios. Aunque en teoría haya un buen DataWarehouse y se hayan implementado exitosas herramientas en sus aplicaciones, si no se capacita a los usuarios para que utilicen los datos para tomar decisiones, jamás lo usaran y todo mundo acabara diciendo que no sirve porque no añade valor le dará la espalda y dirá que fue un fracaso.
La interoperabilidad
El Datawarehouse puede ser utilizado para incorporar y reunir la información de todas las dependencias y conformar así una visión integral de la operación de la institución.
Los datos se encuentran en múltiples sistemas; hay que traducirlos a un idioma común, es decir; hay datos que generan el procesador central, el GRP, el CRM y todos están en un lenguaje distinto.
La calidad de los datos
El mejor indicador de que los datos cuentan con suficiente calidad es que sean susceptibles de ser utilizados por la organización, pero las tecnologías de la información no pueden decidir cual es el nivel de calidad necesario que deben tener los datos.
Es la parte directiva de la institución la que debe indicar cuáles son las metas de calidad que deben tener los datos, y por lo tanto deben especificarlos y luego dar la instrucción para que se desarrollen en esa dirección, si estos desarrollos se dan desde la perspectiva de toda la organización, si hay alguien que realmente dirija el proyecto desde un punto de vista integral, la eficacia del Datawarehouse se multiplicara y encontrara éxito.
Los gobiernos deben aprender a administrar información y crear conocimiento
El volumen de información que se produce ha crecido tanto, que la eficiencia en el manejo de los factores de la producción depende cada vez más de la manera en que se administra y planifica el ciclo de creación y utilización de la información. La información es una activo, pero su utilización no esta ligada a los procesos que la generan: se produce en un tiempo y lugar distinto al de su utilización y aplicación, por lo que su valor esta determinado por quien la usa, y no por quien la produce. Los gobiernos no están exentos de esta situación.
En el Reporte Mundial del Sector Publico de 2003, la Organización de las Naciones Unidas (ONU) indica que uno de los factores clave para el éxito de los e-gobiernos es que los gobiernos aprendan a administrar información para crear conocimiento. Dicho de otro modo: para que los gobiernos generen valor público deben utilizar eficientemente la información, esto es, información que genere conocimiento.
Los gobiernos son el mayor, retenedor y proveedor de información, y agrega que en un mundo globalizado donde los mercados enfrentan una creciente competencia, la innovación es más importante que la
Productividad o la eficiencia en costos, y que tanto los individuos como los gobiernos no solo tienen que resolver nuevas ecuaciones para alcanzar sus objetivos, sino que estas ecuaciones contienen un porcentaje cada vez mayor de variables desconocidas. Este entorno exige que los gobiernos eleven su capacidad para administrar información y crear conocimiento; de lo contrario enfrentaran una situación de abundancia información y déficit de conocimiento.
La Inteligencia de Negocios
Para enfrentar este reto los gobiernos, implantan complejos sistemas de información gracias a las tecnologías de la información y la comunicación (TIC). Él desafió es que las instituciones implementen estrategias de administración de información y creación de conocimiento que combinen herramientas tecnológicas, procesos aplicaciones y mejores practicas. Una estrategia de esta índole pondrá a prueba, típicamente, a la organización en su conjunto: su gente, su cultura organizacional, sus procesos y aplicaciones que generen información, y su infraestructura tecnológica.
Las estrategias encaminadas a resolver los problemas de administración de información y creación de conocimiento se encuadran bajo el concepto de inteligencia de negocios o BI por sus siglas en ingles (Bussiness Intelligence).
En México los gobiernos hacen esfuerzos para que cualquier persona y en cualquier momento disponga de información publica, pero se hace cada vez más evidente que nuestra sociedad requiere, mas bien, no solo el acceso a la abundante información publica, sino que sea confiable y precisa, lo que significa confiar en la fuente que provee esa información.
El gobierno esta obligado a realizar una serie e esfuerzos que tendrán una alta probabilidad de fracaso si no se reconoce que la incumbencia en el tema no es solo de las áreas informáticas y/o tecnológicas, sino de toda la organización.
El reto no es resolver el problema tecnológico de múltiples bases de datos, sino de resolver el problema estructural que consiste en la abundancia de información y de la falta de conocimiento al interior de las instituciones.
El riesgo de no hacer nada
La compleja política y la escasez presupuestaria que enfrentan los gobiernos en México exigen que los proyectos de BI. Sean evaluados tanto por los beneficios que representan como por el riesgo de no llevarlos a cabo. Por esto, lo más recomendable es que las estrategias BI se aborden bajo el enfoque mixto de maximización de beneficios y minimización de riesgos. Las estrategias deben maximizar la eficiencia en el manejo de la información y la eficacia de los procesos y aplicaciones; pero al mismo tiempo deben minimizar el riesgo de la rigidez institucional motivada por la inexistencia de información accesible para generar los conocimientos necesarios, así como el riesgo de tener procesos y sistemas redundantes.
La Inteligencia Institucional
No es lo mismo Inteligencia de Negocios que la Inteligencia Institucional porque los indicadores para medir el desempeño de las organizaciones en cada caso no son iguales
"La información es el capital más valioso de toda organización"
La Información sobre el desempeño de una organización es la única fuente para evaluar su funcionamiento, y la herramienta primaria para planificar su futuro. Sirve para medir la eficiencia de las inversiones y su retorno en beneficios para corregir oportunamente los posibles errores y desviaciones, y permite generar un ciclo virtuoso de ejecución y evaluación permanente, siempre ligado a la operación diaria de los programas de trabajo.
Esta actividad no quedó restringida al mundo empresarial. Para la administración pública se creo el concepto Inteligencia Institucional, que gana en precisión y pertinencia al advertí en su desarrollo las complejidades y rasgos característicos de la tarea gubernamental.
La diferencia más importante entre la Inteligencia de Negocios y la Inteligencia Institucional es la medición del Retorno de Inversión (ROI por sus siglas en ingles). Para las instituciones gubernamentales, el ROI no es únicamente un balance de resultados financieros. Su medición tiene indicadores tales como: más y mejor educación, más y mejores empleos, o reducción de la pobreza, por citar algunos ejemplos. De ahí que los datos que sirven para medir el desempeño de los gobiernos no se encuentran en las oficinas públicas, sino en la calle, en las ciudades y pueblos, o de dicho de otro modo, en la satisfacción ciudadana y en una mejor calidad de vida para todos.
Una segunda gran diferencia entre la implementación de una estrategia de Inteligencia de Negocios y una Inteligencia Institucional, es la heterogeneidad de las fuentes de información. Para una empresa, cruzar diferentes datos sobre su operación puede resultar complejo, pero cuando se trata de organismos gubernamentales las fuentes son mucho más diversas. El gobierno es la suma de una gran variedad de dependencias, organismos, empresas paraestatales, organizaciones sociales y ciudadanas, entre otras, que trabajan en distinto ámbitos territoriales.
Homologar la diversidad
¿Es posible entonces, homologar peras con manzanas? ¿Existe la herramienta tecnológica que haga posible cruzar datos tan diversos de Instituciones tan disímiles?
Conclusiones
El interés del gobierno en aplicaciones de Inteligencia Institucional se debe a que estas herramientas son capaces de integrar información proveniente de distintos sistemas. Las dependencias pueden tener datos dispersos tanto en sistemas tecnológicos avanzados como en programas elementales tipo Excel. Pero gracias a esta herramienta podrán extraer automáticamente la información relevante que requieren aquellos que tomen decisiones.
Construir herramientas de análisis
La información seleccionada y extraída de las bases de datos se presenta al usuario en su escritorio a través de pantallas dinámicas, con amplias capacidades para analizar y proyectarla de manera multidimensional, o bien, combinarla con distintos parámetros que arrojen mejores interpretaciones.
Medir el desempeño y los resultados.
Al provenir la información de las bases de datos operativas de la dependencia, el funcionario se asegura que esta conociendo información de la fuente original, sin "maquillajes" ni sorpresas en cuanto a sí veracidad, por su parte, el responsable de los datos sabe que únicamente podrá mejorar los resultados de su información si el conjunto de la institución mejora su desempeño.
domingo, 16 de noviembre de 2008
Definiciones, descripciones y ... Datawarehouse
Descripción de un Data Warehouse
En el contexto de la informática, un almacén de datos (del ingles data warehouse) es una colección de datos orientada a un determinado ámbito (empresa, organización, etc.), integrado, no volátil y variable en el tiempo, que ayuda a la toma de decisiones en la entidad en la que se utiliza. Se trata, sobre todo, de un expediente completo de una organización, más allá de la información transaccional y operacional, almacenado en una base de datos diseñada para favorecer el análisis y la divulgación eficiente de datos (especialmente OLAP, procesamiento analítico en línea). El almacenamiento de los datos no debe usarse con datos de uso actual. Los almacenes de datos contienen a menudo grandes cantidades de información que se subdividen a veces en unidades lógicas más pequeñas dependiendo del subsistema de la entidad del que procedan o para el que sean necesario.
Definiciones de almacén de datos
Definición de Bill Inmon
Bill Inmon fue uno de los primeros autores en escribir sobre el tema de los almacenes de datos, define un data warehouse (almacén de datos) en términos de las características del repositorio de datos:
• Orientado a temas.- Los datos en la base de datos están organizados de manera que todos los elementos de datos relativos al mismo evento u objeto del mundo real queden unidos entre sí.
• Variante en el tiempo.- Los cambios producidos en los datos a lo largo del tiempo quedan registrados para que los informes que se puedan generar reflejen esas variaciones.
• No volátil.- La información no se modifica ni se elimina, una vez almacenado un dato, éste se convierte en información de sólo lectura, y se mantiene para futuras consultas.
• Integrado.- La base de datos contiene los datos de todos los sistemas operacionales de la organización, y dichos datos deben ser consistentes.
Inmon defiende una metodología descendente (top-down) a la hora de diseñar un almacén de datos, ya que de esta forma se considerarán mejor todos los datos corporativos. En esta metodología los Data marts se crearán después de haber terminado el data warehouse completo de la organización.
Definición de Ralph Kimball
Este es otro conocido autor en el tema de los data warehouse, define un almacén de datos como: "una copia de las transacciones de datos específicamente estructurada para la consulta y el análisis". También fue Kimball quien determinó que un data warehouse no era más que: "la unión de todos los Data marts de una entidad". Defiende por tanto una metodología ascendente (bottom-up) a la hora de diseñar un almacén de datos.
Una definición más amplia de almacén de datos
Las definiciones anteriores se centran en los datos en sí mismos. Sin embargo, los medios para obtener y analizar esos datos, para extraerlos, transformarlos y cargarlos, así como las diferentes formas para realizar la gestión de datos son componentes esenciales de un almacén de datos. Muchas referencias a un almacén de datos utilizan esta definición más amplia. Por lo tanto, en esta definición se incluyen herramientas para la inteligencia empresarial, herramientas para extraer, transformar y cargar datos en el almacén de datos, y herramientas para gestionar y recuperar los metadatos.
Función de un almacén de datos
En un almacén de datos lo que se quiere es contener datos que son necesarios o útiles para una organización, es decir, que se utiliza como un repositorio de datos para posteriormente transformarlos en información útil para el usuario. Un almacén de datos debe entregar la información correcta a la gente indicada en el momento óptimo y en el formato adecuado. El almacén de datos da respuesta a las necesidades de usuarios expertos, utilizando Sistemas de Soporte a Decisiones (DSS), Sistemas de información ejecutiva (EIS) o herramientas para hacer consultas o informes. Los usuarios finales pueden hacer fácilmente consultas sobre sus almacenes de datos sin tocar o afectar la operación del sistema.
En el funcionamiento de un almacén de los datos son muy importantes las siguientes ideas:
• Integración de los datos provenientes de bases de datos distribuidas por las diferentes unidades de la organización y que con frecuencia tendrán diferentes estructuras (fuentes heterogéneas). Se debe facilitar una descripción global y un análisis comprensivo de toda la organización en el almacén de datos.
• Separación de los datos usados en operaciones diarias de los datos usados en el almacén de datos para los propósitos de divulgación, de ayuda en la toma de decisiones, para el análisis y para operaciones de control. Ambos tipos de datos no deben coincidir en la misma base de datos, ya que obedecen a objetivos muy distintos y podrían entorpecerse entre sí.
Periódicamente, se importan datos al almacén de datos de los distintos sistemas de planeamiento de recursos de la entidad (ERP) y de otros sistemas de software relacionados con el negocio para la transformación posterior. Es práctica común normalizar los datos antes de combinarlos en el almacén de datos mediante herramientas de extracción, transformación y carga (ETL). Estas herramientas leen los datos primarios (a menudo bases de datos OLTP de un negocio), realizan el proceso de transformación al almacén de datos (filtración, adaptación, cambios de formato, ...) y escriben en el almacén.
Data marts
Los Data marts son subconjuntos de datos de un data warehouse para áreas especificas.
Entre las características de un data mart destacan:
• Usuarios limitados.
• Área especifica.
• Tiene un propósito especifico.
• Tiene una función de apoyo.
Cubos de información
Los cubos de información o cubos OLAP funcionan como los cubos de rompecabezas en los juegos, en el juego se trata de armar los colores y en el data warehouse se trata de organizar los datos por tablas o relaciones; los primeros (el juego) tienen 3 dimensiones, los cubos OLAP tienen un número indefinido de dimensiones, razón por la cual también reciben el nombre de hipercubos. Un cubo OLAP contendrá datos de una determinada variable que se desea analizar, proporcionando una vista lógica de los datos provistos por el sistema de información hacia el data warehouse, esta vista estará dispuesta según unas dimensiones y podrá contener información calculada. El análisis de los datos está basado en las dimensiones del hipercubo, por lo tanto, se trata de un análisis multidimensional.
A la información de un cubo puede acceder el ejecutivo mediante "tablas dinámicas" en una hoja de cálculo o a través de programas personalizados. Las tablas dinámicas le permiten manipular las vistas (cruces, filtrados, organización, totales) de la información con mucha facilidad. Las diferentes operaciones que se pueden realizar con cubos de información se producen con mucha rapidez. Llevando estos conceptos a un data warehouse, éste es una colección de datos que está formada por «dimensiones» y «variables», entendiendo como dimensiones a aquellos elementos que participan en el análisis y variables a los valores que se desean analizar.
Dimensiones
Las dimensiones de un cubo son atributos relativos a las variables, son las perspectivas de análisis de las variables (forman parte de la tabla de dimensiones). Son catálogos de información complementaria necesaria para la presentación de los datos a los usuarios, como por ejemplo: descripciones, nombres, zonas, rangos de tiempo, etc. Es decir, la información general complementaria a cada uno de los registros de la tabla de hechos.
Variables
También llamadas indicadores de gestión?, son los datos que están siendo analizados. Forman parte de la tabla de hechos. Más formalmente, las variables representan algún aspecto cuantificable o medible de los objetos o eventos a analizar. Normalmente, las variables son representadas por valores detallados y numéricos para cada instancia del objeto o evento medido. En forma contraria, las dimensiones son atributos relativos a la variables, y son utilizadas para indexar, ordenar, agrupar o abreviar los valores de las mismas. Las dimensiones poseen una granularidad menor, tomando como valores un conjunto de elementos menor que el de las variables; ejemplos de dimensiones podrían ser: productos?, localidades? (o zonas), el tiempo? (medido en días, horas, semanas, etc.), ...
Ejemplos
Ejemplos de variables podrían ser:
• Beneficios
• Gastos
• Ventas
• etc.
Ejemplos de dimensiones podrían ser:
• producto (diferentes tipos o denominaciones de productos)
• localidades (o provincia, o regiones, o zonas geográficas)
• tiempo (medido de diferentes maneras, por horas, por días, por meses, por años, ...)
• tipo de cliente (casado/soltero, joven/adulto/anciano, ...)
• etc.
Según lo anterior, podríamos construir un cubo de información sobre el indice de ventas (variable a estudiar) en función del producto vendido, la provincia, el mes del año y si el cliente está casado o soltero (dimensiones). Tendríamos un cubo de 4 dimensiones.
Elementos que integran un almacén de datos
Metadatos
Uno de los componentes más importantes de la arquitectura de un almacén de datos son los metadatos. Se define comúnmente como "datos acerca de los datos", en el sentido de que se trata de datos que describen cuál es la estructura de los datos que se van a almacenar y cómo se relacionan.
El metadato documenta, entre otras cosas, qué tablas existen en una base de datos, qué columnas posee cada una de las tablas y qué tipo de datos se pueden almacenar. Los datos son de interés para el usuario final, el metadato es de interés para los programas que tienen que manejar estos datos. Sin embargo, el rol que cumple el metadato en un entorno de almacén de datos es muy diferente al rol que cumple en los ambientes operacionales. En el ámbito de los data warehouse el metadato juega un papel fundamental, su función consiste en recoger todas las definiciones de la organización y el concepto de los datos en el almacén de datos, debe contener toda la información concerniente a:
• Tablas
• Columnas de tablas
• Relaciones entre tablas
• Jerarquías y Dimensiones de datos
• Entidades y Relaciones
Funciones ETL (extracción, transformación y carga)
Los procesos de extracción, transformación y carga (ETL) son importantes ya que son la forma en que los datos se guardan en un data warehouse (o en cualquier base de datos). Implican las siguientes operaciones:
• Extracción.- Acción de obtener la información deseada a partir de los datos almacenados en fuentes externas.
• Transformación.- Cualquier operación realizada sobre los datos para que puedan ser cargados en el data warehouse o se puedan migrar de éste a otra base de datos.
• Carga.- Consiste en almacenar los datos en la base de datos final, por ejemplo el data warehouse objetivo.
Middleware
Middleware es un término genérico que se utiliza para referirse a todo tipo de software de conectividad que ofrece servicios u operaciones que hacen posible el funcionamiento de aplicaciones distribuidas sobre plataformas heterogéneas. Estos servicios funcionan como una capa de abstracción de software distribuida, que se sitúa entre las capas de aplicaciones y las capas inferiores (sistema operativo y red). El middleware puede verse como una capa API, que sirve como base a los programadores para que puedan desarrollar aplicaciones que trabajen en diferentes entornos sin preocuparse de los protocolos de red y comunicaciones en que se ejecutarán. De esta manera se ofrece una mejor relación costo/rendimiento que pasa por el desarrollo de aplicaciones más complejas, en menos tiempo.
La función del middleware en el contexto de los data warehouse es la de asegurar la conectividad entre todos los componentes de la arquitectura de un almacén de datos.
Diseño de un almacén de datos
Para construir un Data Warehouse se necesitan herramientas para ayudar a la migración y a la transformación de los datos hacia el almacén. Una vez construido, se requieren medios para manejar grandes volúmenes de información. Se diseña su arquitectura dependiendo de la estructura interna de los datos del almacén y especialmente del tipo de consultas a realizar. Con este criterio los datos deben ser repartidos entre numerosos data marts. Para abordar un proyecto de data warehouse es necesario hacer un estudio de algunos temas generales de la organización o empresa, los cuales se describen a continuación:
• Situación actual de partida.- Cualquier solución propuesta de data warehouse debe estar muy orientada por las necesidades del negocio y debe ser compatible con la arquitectura técnica existente y planeada de la compañía.
• Tipo y características del negocio.- Es indispensable tener el conocimiento exacto sobre el tipo de negocios de la organización y el soporte que representa la información dentro de todo su proceso de toma de decisiones.
• Entorno técnico.- Se debe incluir tanto el aspecto del hardware (mainframes, servidores, redes,...) así como aplicaciones y herramientas. Se dará énfasis a los Sistemas de soporte a decisiones (DSS), si existen en la actualidad, cómo operan, etc.
• Expectativas de los usuarios.- Un proyecto de data warehouse no es únicamente un proyecto tecnológico, es una forma de vida de las organizaciones y como tal, tiene que contar con el apoyo de todos los usuarios y su convencimiento sobre su bondad.
• Etapas de desarrollo.- Con el conocimiento previo, ya se entra en el desarrollo de un modelo conceptual para la construcción del data warehouse.
• Prototipo.- Un prototipo es un esfuerzo designado a simular tanto como sea posible el producto final que será entregado a los usuarios.
• Piloto.- El piloto de un data warehouse es el primero (o cada uno de los primeros) resultados generados de forma iterativa que se harán para llegar a la construcción del producto final deseado.
• Prueba del concepto tecnológico.- Es un paso opcional que se puede necesitar para determinar si la arquitectura especificada del data warehouse funcionará finalmente como se espera.
Almacén de datos espacial
Almacén de datos espacial es una colección de datos orientados al tema, integrados, no volátiles, variantes en el tiempo y que añaden la geografía de los datos, para la toma de decisiones. Sin embargo la componente geográfica no es un dato agregado, sino que una dimensión o variable en la tecnología de la información, de tal manera que permita modelar todo el negocio como un ente holístico, y que a través de herramientas de procesamiento analítico en línea (OLAP), no solamente se posea un alto desempeño en consultas multidimensionales sino que adicionalmente se puedan visualizar espacialmente los resultados.
El almacén de datos espacial forma el corazón de un extensivo Sistema de Información Geográfica para la toma de decisiones, éste al igual que los SIG, permiten que un gran número de usuarios accedan a información integrada, a diferencia de un simple almacén de datos que está orientado al tema, el Data warehouse espacial adicionalmente es Geo-Relacional, es decir que en estructuras relacionales combina e integra los datos espaciales con los datos descriptivos. Actualmente es geo-objetos, esto es que los elementos geográficos se manifiestan como objetos con todas sus propiedades y comportamientos, y que adicionalmente están almacenados en una única base de datos Objeto-Relacional. Los Data Warehouse Espaciales son aplicaciones basadas en un alto desempeño de las bases de datos, que utilizan arquitecturas Cliente-Servidor para integrar diversos datos en tiempo real. Mientras los almacenes de datos trabajan con muchos tipos y dimensiones de datos, muchos de los cuales no referencian ubicación espacial, a pesar de poseerla intrínsecamente, y sabiendo que un 80% de los datos poseen representación y ubicación en el espacio, en los Data warehouse espaciales, la variable geográfica desempeña un papel importante en la base de información para la construcción del análisis, y de igual manera que para un Data warehouse, la variable tiempo es imprescindible en los análisis, para los Data warehouse espaciales la variable geográfica debe ser almacenada directamente en ella.
Ventajas e inconvenientes de los almacenes de datos
Ventajas
Hay muchas ventajas por las que es recomendable usar un almacén de datos. Algunas de ellas son:
• Los almacenes de datos hacen más fácil el acceso a una gran variedad de datos a los usuarios finales
• Facilitan el funcionamiento de las aplicaciones de los sistemas de apoyo a la decisión tales como informes de tendencia', por ejemplo: obtener los ítems con la mayoría de las ventas en un área en particular dentro de los últimos dos años; informes de excepción, informes que muestran los resultados reales frente a los objetivos planteados a priori.
• Los almacenes de datos pueden trabajar en conjunto y, por lo tanto, aumentar el valor operacional de las aplicaciones empresariales, en especial la gestión de relaciones con clientes.
Inconvenientes
Utilizar almacenes de datos también plantea algunos inconvenientes, algunos de ellos son:
• A lo largo de su vida los almacenes de datos pueden suponer altos costos. El almacén de datos no suele ser estático. Los costos de mantenimiento son elevados.
• Los almacenes de datos se pueden quedar obsoletos relativamente pronto.
• A veces, ante una petición de información estos devuelven una información subóptima, que también supone una perdida para la organización.
• A menudo existe una delgada línea entre los almacenes de datos y sistemas operativos. Hay que determinar qué funcionalidades de estos se pueden aprovechar y cuáles se deben implementar en el data warehouse, resultaría costoso implementar operaciones no necesarias o dejar de implementar alguna que sí vaya a necesitarse.
En el contexto de la informática, un almacén de datos (del ingles data warehouse) es una colección de datos orientada a un determinado ámbito (empresa, organización, etc.), integrado, no volátil y variable en el tiempo, que ayuda a la toma de decisiones en la entidad en la que se utiliza. Se trata, sobre todo, de un expediente completo de una organización, más allá de la información transaccional y operacional, almacenado en una base de datos diseñada para favorecer el análisis y la divulgación eficiente de datos (especialmente OLAP, procesamiento analítico en línea). El almacenamiento de los datos no debe usarse con datos de uso actual. Los almacenes de datos contienen a menudo grandes cantidades de información que se subdividen a veces en unidades lógicas más pequeñas dependiendo del subsistema de la entidad del que procedan o para el que sean necesario.
Definiciones de almacén de datos
Definición de Bill Inmon
Bill Inmon fue uno de los primeros autores en escribir sobre el tema de los almacenes de datos, define un data warehouse (almacén de datos) en términos de las características del repositorio de datos:
• Orientado a temas.- Los datos en la base de datos están organizados de manera que todos los elementos de datos relativos al mismo evento u objeto del mundo real queden unidos entre sí.
• Variante en el tiempo.- Los cambios producidos en los datos a lo largo del tiempo quedan registrados para que los informes que se puedan generar reflejen esas variaciones.
• No volátil.- La información no se modifica ni se elimina, una vez almacenado un dato, éste se convierte en información de sólo lectura, y se mantiene para futuras consultas.
• Integrado.- La base de datos contiene los datos de todos los sistemas operacionales de la organización, y dichos datos deben ser consistentes.
Inmon defiende una metodología descendente (top-down) a la hora de diseñar un almacén de datos, ya que de esta forma se considerarán mejor todos los datos corporativos. En esta metodología los Data marts se crearán después de haber terminado el data warehouse completo de la organización.
Definición de Ralph Kimball
Este es otro conocido autor en el tema de los data warehouse, define un almacén de datos como: "una copia de las transacciones de datos específicamente estructurada para la consulta y el análisis". También fue Kimball quien determinó que un data warehouse no era más que: "la unión de todos los Data marts de una entidad". Defiende por tanto una metodología ascendente (bottom-up) a la hora de diseñar un almacén de datos.
Una definición más amplia de almacén de datos
Las definiciones anteriores se centran en los datos en sí mismos. Sin embargo, los medios para obtener y analizar esos datos, para extraerlos, transformarlos y cargarlos, así como las diferentes formas para realizar la gestión de datos son componentes esenciales de un almacén de datos. Muchas referencias a un almacén de datos utilizan esta definición más amplia. Por lo tanto, en esta definición se incluyen herramientas para la inteligencia empresarial, herramientas para extraer, transformar y cargar datos en el almacén de datos, y herramientas para gestionar y recuperar los metadatos.
Función de un almacén de datos
En un almacén de datos lo que se quiere es contener datos que son necesarios o útiles para una organización, es decir, que se utiliza como un repositorio de datos para posteriormente transformarlos en información útil para el usuario. Un almacén de datos debe entregar la información correcta a la gente indicada en el momento óptimo y en el formato adecuado. El almacén de datos da respuesta a las necesidades de usuarios expertos, utilizando Sistemas de Soporte a Decisiones (DSS), Sistemas de información ejecutiva (EIS) o herramientas para hacer consultas o informes. Los usuarios finales pueden hacer fácilmente consultas sobre sus almacenes de datos sin tocar o afectar la operación del sistema.
En el funcionamiento de un almacén de los datos son muy importantes las siguientes ideas:
• Integración de los datos provenientes de bases de datos distribuidas por las diferentes unidades de la organización y que con frecuencia tendrán diferentes estructuras (fuentes heterogéneas). Se debe facilitar una descripción global y un análisis comprensivo de toda la organización en el almacén de datos.
• Separación de los datos usados en operaciones diarias de los datos usados en el almacén de datos para los propósitos de divulgación, de ayuda en la toma de decisiones, para el análisis y para operaciones de control. Ambos tipos de datos no deben coincidir en la misma base de datos, ya que obedecen a objetivos muy distintos y podrían entorpecerse entre sí.
Periódicamente, se importan datos al almacén de datos de los distintos sistemas de planeamiento de recursos de la entidad (ERP) y de otros sistemas de software relacionados con el negocio para la transformación posterior. Es práctica común normalizar los datos antes de combinarlos en el almacén de datos mediante herramientas de extracción, transformación y carga (ETL). Estas herramientas leen los datos primarios (a menudo bases de datos OLTP de un negocio), realizan el proceso de transformación al almacén de datos (filtración, adaptación, cambios de formato, ...) y escriben en el almacén.
Data marts
Los Data marts son subconjuntos de datos de un data warehouse para áreas especificas.
Entre las características de un data mart destacan:
• Usuarios limitados.
• Área especifica.
• Tiene un propósito especifico.
• Tiene una función de apoyo.
Cubos de información
Los cubos de información o cubos OLAP funcionan como los cubos de rompecabezas en los juegos, en el juego se trata de armar los colores y en el data warehouse se trata de organizar los datos por tablas o relaciones; los primeros (el juego) tienen 3 dimensiones, los cubos OLAP tienen un número indefinido de dimensiones, razón por la cual también reciben el nombre de hipercubos. Un cubo OLAP contendrá datos de una determinada variable que se desea analizar, proporcionando una vista lógica de los datos provistos por el sistema de información hacia el data warehouse, esta vista estará dispuesta según unas dimensiones y podrá contener información calculada. El análisis de los datos está basado en las dimensiones del hipercubo, por lo tanto, se trata de un análisis multidimensional.
A la información de un cubo puede acceder el ejecutivo mediante "tablas dinámicas" en una hoja de cálculo o a través de programas personalizados. Las tablas dinámicas le permiten manipular las vistas (cruces, filtrados, organización, totales) de la información con mucha facilidad. Las diferentes operaciones que se pueden realizar con cubos de información se producen con mucha rapidez. Llevando estos conceptos a un data warehouse, éste es una colección de datos que está formada por «dimensiones» y «variables», entendiendo como dimensiones a aquellos elementos que participan en el análisis y variables a los valores que se desean analizar.
Dimensiones
Las dimensiones de un cubo son atributos relativos a las variables, son las perspectivas de análisis de las variables (forman parte de la tabla de dimensiones). Son catálogos de información complementaria necesaria para la presentación de los datos a los usuarios, como por ejemplo: descripciones, nombres, zonas, rangos de tiempo, etc. Es decir, la información general complementaria a cada uno de los registros de la tabla de hechos.
Variables
También llamadas indicadores de gestión?, son los datos que están siendo analizados. Forman parte de la tabla de hechos. Más formalmente, las variables representan algún aspecto cuantificable o medible de los objetos o eventos a analizar. Normalmente, las variables son representadas por valores detallados y numéricos para cada instancia del objeto o evento medido. En forma contraria, las dimensiones son atributos relativos a la variables, y son utilizadas para indexar, ordenar, agrupar o abreviar los valores de las mismas. Las dimensiones poseen una granularidad menor, tomando como valores un conjunto de elementos menor que el de las variables; ejemplos de dimensiones podrían ser: productos?, localidades? (o zonas), el tiempo? (medido en días, horas, semanas, etc.), ...
Ejemplos
Ejemplos de variables podrían ser:
• Beneficios
• Gastos
• Ventas
• etc.
Ejemplos de dimensiones podrían ser:
• producto (diferentes tipos o denominaciones de productos)
• localidades (o provincia, o regiones, o zonas geográficas)
• tiempo (medido de diferentes maneras, por horas, por días, por meses, por años, ...)
• tipo de cliente (casado/soltero, joven/adulto/anciano, ...)
• etc.
Según lo anterior, podríamos construir un cubo de información sobre el indice de ventas (variable a estudiar) en función del producto vendido, la provincia, el mes del año y si el cliente está casado o soltero (dimensiones). Tendríamos un cubo de 4 dimensiones.
Elementos que integran un almacén de datos
Metadatos
Uno de los componentes más importantes de la arquitectura de un almacén de datos son los metadatos. Se define comúnmente como "datos acerca de los datos", en el sentido de que se trata de datos que describen cuál es la estructura de los datos que se van a almacenar y cómo se relacionan.
El metadato documenta, entre otras cosas, qué tablas existen en una base de datos, qué columnas posee cada una de las tablas y qué tipo de datos se pueden almacenar. Los datos son de interés para el usuario final, el metadato es de interés para los programas que tienen que manejar estos datos. Sin embargo, el rol que cumple el metadato en un entorno de almacén de datos es muy diferente al rol que cumple en los ambientes operacionales. En el ámbito de los data warehouse el metadato juega un papel fundamental, su función consiste en recoger todas las definiciones de la organización y el concepto de los datos en el almacén de datos, debe contener toda la información concerniente a:
• Tablas
• Columnas de tablas
• Relaciones entre tablas
• Jerarquías y Dimensiones de datos
• Entidades y Relaciones
Funciones ETL (extracción, transformación y carga)
Los procesos de extracción, transformación y carga (ETL) son importantes ya que son la forma en que los datos se guardan en un data warehouse (o en cualquier base de datos). Implican las siguientes operaciones:
• Extracción.- Acción de obtener la información deseada a partir de los datos almacenados en fuentes externas.
• Transformación.- Cualquier operación realizada sobre los datos para que puedan ser cargados en el data warehouse o se puedan migrar de éste a otra base de datos.
• Carga.- Consiste en almacenar los datos en la base de datos final, por ejemplo el data warehouse objetivo.
Middleware
Middleware es un término genérico que se utiliza para referirse a todo tipo de software de conectividad que ofrece servicios u operaciones que hacen posible el funcionamiento de aplicaciones distribuidas sobre plataformas heterogéneas. Estos servicios funcionan como una capa de abstracción de software distribuida, que se sitúa entre las capas de aplicaciones y las capas inferiores (sistema operativo y red). El middleware puede verse como una capa API, que sirve como base a los programadores para que puedan desarrollar aplicaciones que trabajen en diferentes entornos sin preocuparse de los protocolos de red y comunicaciones en que se ejecutarán. De esta manera se ofrece una mejor relación costo/rendimiento que pasa por el desarrollo de aplicaciones más complejas, en menos tiempo.
La función del middleware en el contexto de los data warehouse es la de asegurar la conectividad entre todos los componentes de la arquitectura de un almacén de datos.
Diseño de un almacén de datos
Para construir un Data Warehouse se necesitan herramientas para ayudar a la migración y a la transformación de los datos hacia el almacén. Una vez construido, se requieren medios para manejar grandes volúmenes de información. Se diseña su arquitectura dependiendo de la estructura interna de los datos del almacén y especialmente del tipo de consultas a realizar. Con este criterio los datos deben ser repartidos entre numerosos data marts. Para abordar un proyecto de data warehouse es necesario hacer un estudio de algunos temas generales de la organización o empresa, los cuales se describen a continuación:
• Situación actual de partida.- Cualquier solución propuesta de data warehouse debe estar muy orientada por las necesidades del negocio y debe ser compatible con la arquitectura técnica existente y planeada de la compañía.
• Tipo y características del negocio.- Es indispensable tener el conocimiento exacto sobre el tipo de negocios de la organización y el soporte que representa la información dentro de todo su proceso de toma de decisiones.
• Entorno técnico.- Se debe incluir tanto el aspecto del hardware (mainframes, servidores, redes,...) así como aplicaciones y herramientas. Se dará énfasis a los Sistemas de soporte a decisiones (DSS), si existen en la actualidad, cómo operan, etc.
• Expectativas de los usuarios.- Un proyecto de data warehouse no es únicamente un proyecto tecnológico, es una forma de vida de las organizaciones y como tal, tiene que contar con el apoyo de todos los usuarios y su convencimiento sobre su bondad.
• Etapas de desarrollo.- Con el conocimiento previo, ya se entra en el desarrollo de un modelo conceptual para la construcción del data warehouse.
• Prototipo.- Un prototipo es un esfuerzo designado a simular tanto como sea posible el producto final que será entregado a los usuarios.
• Piloto.- El piloto de un data warehouse es el primero (o cada uno de los primeros) resultados generados de forma iterativa que se harán para llegar a la construcción del producto final deseado.
• Prueba del concepto tecnológico.- Es un paso opcional que se puede necesitar para determinar si la arquitectura especificada del data warehouse funcionará finalmente como se espera.
Almacén de datos espacial
Almacén de datos espacial es una colección de datos orientados al tema, integrados, no volátiles, variantes en el tiempo y que añaden la geografía de los datos, para la toma de decisiones. Sin embargo la componente geográfica no es un dato agregado, sino que una dimensión o variable en la tecnología de la información, de tal manera que permita modelar todo el negocio como un ente holístico, y que a través de herramientas de procesamiento analítico en línea (OLAP), no solamente se posea un alto desempeño en consultas multidimensionales sino que adicionalmente se puedan visualizar espacialmente los resultados.
El almacén de datos espacial forma el corazón de un extensivo Sistema de Información Geográfica para la toma de decisiones, éste al igual que los SIG, permiten que un gran número de usuarios accedan a información integrada, a diferencia de un simple almacén de datos que está orientado al tema, el Data warehouse espacial adicionalmente es Geo-Relacional, es decir que en estructuras relacionales combina e integra los datos espaciales con los datos descriptivos. Actualmente es geo-objetos, esto es que los elementos geográficos se manifiestan como objetos con todas sus propiedades y comportamientos, y que adicionalmente están almacenados en una única base de datos Objeto-Relacional. Los Data Warehouse Espaciales son aplicaciones basadas en un alto desempeño de las bases de datos, que utilizan arquitecturas Cliente-Servidor para integrar diversos datos en tiempo real. Mientras los almacenes de datos trabajan con muchos tipos y dimensiones de datos, muchos de los cuales no referencian ubicación espacial, a pesar de poseerla intrínsecamente, y sabiendo que un 80% de los datos poseen representación y ubicación en el espacio, en los Data warehouse espaciales, la variable geográfica desempeña un papel importante en la base de información para la construcción del análisis, y de igual manera que para un Data warehouse, la variable tiempo es imprescindible en los análisis, para los Data warehouse espaciales la variable geográfica debe ser almacenada directamente en ella.
Ventajas e inconvenientes de los almacenes de datos
Ventajas
Hay muchas ventajas por las que es recomendable usar un almacén de datos. Algunas de ellas son:
• Los almacenes de datos hacen más fácil el acceso a una gran variedad de datos a los usuarios finales
• Facilitan el funcionamiento de las aplicaciones de los sistemas de apoyo a la decisión tales como informes de tendencia', por ejemplo: obtener los ítems con la mayoría de las ventas en un área en particular dentro de los últimos dos años; informes de excepción, informes que muestran los resultados reales frente a los objetivos planteados a priori.
• Los almacenes de datos pueden trabajar en conjunto y, por lo tanto, aumentar el valor operacional de las aplicaciones empresariales, en especial la gestión de relaciones con clientes.
Inconvenientes
Utilizar almacenes de datos también plantea algunos inconvenientes, algunos de ellos son:
• A lo largo de su vida los almacenes de datos pueden suponer altos costos. El almacén de datos no suele ser estático. Los costos de mantenimiento son elevados.
• Los almacenes de datos se pueden quedar obsoletos relativamente pronto.
• A veces, ante una petición de información estos devuelven una información subóptima, que también supone una perdida para la organización.
• A menudo existe una delgada línea entre los almacenes de datos y sistemas operativos. Hay que determinar qué funcionalidades de estos se pueden aprovechar y cuáles se deben implementar en el data warehouse, resultaría costoso implementar operaciones no necesarias o dejar de implementar alguna que sí vaya a necesitarse.
Manual para la adquisición de un sistema de Data Warehouse
Manual para la adquisición de un sistema de Data Warehouse
1.- INTRODUCCIÓN
1.1. Justificación histórica
En la actualidad, las tecnologías de la información han automatizado los procesos de carácter típicamente repetitivo o administrativo, haciendo uso de lo que llamaremos sistemas de información operacionales. Entendemos por aplicaciones operacionales, aquellas que resuelven las necesidades de funcionamiento de la empresa. En este tipo de sistemas, los conceptos más importantes son la actualización y el tiempo de respuesta.
Una vez satisfechas las necesidades operacionales más acuciantes, surge un nuevo grupo de necesidades sobre los sistemas de la empresa, a las cuales vamos a calificar como necesidades informacionales. Por necesidades informacionales, entendemos aquellas que tienen por objeto obtener la información necesaria, que sirva de base para la toma de decisiones tanto a escala estratégica como táctica. Estas necesidades informacionales se basan en gran medida en el análisis de un número ingente de datos, en el que es tan importante el obtener un valor muy detallado de negocio como el valor totalizado para el mismo. Es fundamental también la visión histórica de todas las variables analizadas, y el análisis de los datos del entorno. Estos requerimientos no son, a priori, difíciles de resolver dado que la información está efectivamente en los sistemas operacionales. Cualquier actividad que realiza la empresa está reflejada de forma minuciosa en sus bases de datos.
La realidad, sin embargo, es distinta, puesto que al atender las necesidades de tipo informacional, los responsables de sistemas se tropiezan con múltiples problemas. En primer lugar, al realizar consultas masivas de información (con el fin de conseguir el ratio, valor agrupado o grupo de valores solicitados), se puede ver perjudicado el nivel de servicio del resto de sistemas, dado que las consultas de las que estamos hablando, suelen ser bastante costosas en recursos. Además, las necesidades se ven insatisfechas por la limitada flexibilidad a la hora de navegar por la información y a su inconsistencia debido a la falta de una visión global (cada visión particular del dato está almacenada en el sistema operacional que lo gestiona).
En esta situación, el siguiente paso evolutivo ha venido siendo la generación de un entorno gemelo del operativo, que se ha denominado comúnmente Centro de Información, en el cual la información se refresca con menor periodicidad que en los entornos operacionales y los requerimientos en el nivel de servicio al usuario son más flexibles.
Con esta estrategia se resuelve el problema de la planificación de recursos ya que las aplicaciones que precisan un nivel de servicio alto usan el entorno operacional y las que precisan consultas masivas de información trabajan en el Centro de Información. Otro beneficio de este nuevo entorno, es la no inferencia con las aplicaciones operacionales.
Pero no terminan aquí los problemas. La información mantiene la misma estructura que en las aplicaciones operacionales por lo que este tipo de consultas debe acceder a multitud de lugares para obtener el conjunto de datos deseado. El tiempo de respuesta a las solicitudes de información es excesivamente elevado. Adicionalmente, al proceder la información de distintos sistemas, con visiones distintas y distintos objetivos, en muchas ocasiones no es posible obtener la información deseada de una forma fácil y además carece de la necesaria fiabilidad.
De cara al usuario estos problemas se traducen en que no dispone a tiempo de la información solicitada y que debe dedicarse con más intensidad a la obtención de la información que al análisis de la misma, que es donde aporta su mayor valor añadido.
1.2. Sumario
En los capítulos siguientes expondremos, por un lado qué es un Data Warehouse, un Data Mart y el porqué de estos conceptos. Por otro lado, veremos sus componentes de base (hardware y software) y el "estado del arte" de las distintas tecnologías disponibles. Analizaremos las distintas partes de las que se compone un sistema Data Warehouse y presentaremos una metodología de construcción del mismo. Examinaremos el uso que se le puede dar (Explotación del Data Warehouse), con especial hincapié en el Data Mining y las posibilidades de acceso a esta información. También presentaremos cómo algunas áreas se han beneficiado de las tecnologías de Data Warehouse: Marketing, Departamento Financiero, Área de Riesgo de Crédito, etc. Y por último, expondremos algunas recomendaciones generales a considerar para un buen uso de los sistemas de este tipo.
2.- ANÁLISIS DEL ENTORNO DATA WAREHOUSE
2.1. - ¿QUÉ ES UN DATA WAREHOUSE?
Tras las dificultades de los sistemas tradicionales en satisfacer las necesidades informacionales, surge el concepto de Data Warehouse, como solución a las necesidades informacionales globales de la empresa. Este término acuñado por Bill Inmon, se traduce literalmente como Almacén de Datos. No obstante si el Data Warehouse fuese exclusivamente un almacén de datos, los problemas seguirían siendo los mismos que en los Centros de Información.
La ventaja principal de este tipo de sistemas se basa en su concepto fundamental, la estructura de la información. Este concepto significa el almacenamiento de información homogénea y fiable, en una estructura basada en la consulta y el tratamiento jerarquizado de la misma, y en un entorno diferenciado de los sistemas operacionales. Según definió Bill Inmon, el Data Warehouse se caracteriza por ser:
Integrado: los datos almacenados en el Data Warehouse deben integrarse en una estructura consistente, por lo que las inconsistencias existentes entre los diversos sistemas operacionales deben ser eliminadas. La información suele estructurarse también en distintos niveles de detalle para adecuarse a las distintas necesidades de los usuarios.
Temático: sólo los datos necesarios para el proceso de generación del conocimiento del negocio se integran desde el entorno operacional. Los datos se organizan por temas para facilitar su acceso y entendimiento por parte de los usuarios finales. Por ejemplo, todos los datos sobre clientes pueden ser consolidados en una única tabla del Data Warehouse. De esta forma, las peticiones de información sobre clientes serán más fáciles de responder dado que toda la información reside en el mismo lugar.
Histórico: el tiempo es parte implícita de la información contenida en un Data Warehouse. En los sistemas operacionales, los datos siempre reflejan el estado de la actividad del negocio en el momento presente. Por el contrario, la información almacenada en el Data Warehouse sirve, entre otras cosas, para realizar análisis de tendencias. Por lo tanto, el Data Warehouse se carga con los distintos valores que toma una variable en el tiempo para permitir comparaciones.
No volátil: el almacén de información de un Data Warehouse existe para ser leído, y no modificado. La información es por tanto permanente, significando la actualización del Data Warehouse la incorporación de los últimos valores que tomaron las distintas variables contenidas en él sin ningún tipo de acción sobre lo que ya existía.
E.F. Codd, considerado como el padre de las bases de datos relacionales, ha venido insistiendo desde principio de los noventa, que disponer de un sistema de bases de datos relacionales, no significa disponer de un soporte directo para la toma de decisiones. Muchas de estas decisiones se basan en un análisis de naturaleza multidimensional, que se intentan resolver con la tecnología no orientada para esta naturaleza. Este análisis multidimensional, parte de una visión de la información como dimensiones de negocio.
Estas dimensiones de negocio se comprenden mejor fijando un ejemplo, para lo que vamos a mostrar, para un sistema de gestión de expedientes, las jerarquías que se podrían manejar para el número de los mismo para las dimensiones: zona geográfica, tipo de expediente y tiempo de resolución. La visión general de la información de ventas para estas dimensiones definidas, la representaremos, gráficamente como el cubo de la derecha:
Un gerente de una zona estaría interesado en visualizar la información para su zona en el tiempo para todos los productos que distribuye, lo podría tener una representación gráfica como el cubo de la derecha:
Un director de producto, sin embargo querría examinar la distribución geográfica de sus productos, para toda la información histórica almacenada en el Data Warehouse.
Esto se podría representar como la siguiente figura:
O se podría también examinar los datos en un determinado momento o una visión particularizada.
A su vez estas dimensiones tienen una jerarquía, interpretándose en el cubo como que cada cubo elemental es un dato elemental, del que se puede extraer información agregada. En el ejemplo anterior podría ser:
Y así por ejemplo se podría querer analizar la evolución de las ventas en Galicia de libros de Física por meses desde Febrero del 1996 hasta Marzo del 1997.
Ello es fácil de obtener (incluso a "golpe de ratón") si la información de ventas se ha almacenado en un Data Warehouse, definiendo estas jerarquías y estas dimensiones de negocio.
En este sentido citamos las palabras de D. Wayne Calloway Director Ejecutivo de Operaciones de Pepsico en una asamblea general de accionistas:
"Hace diez años les pude decir cuántos Doritos vendimos al Oeste del Mississipi. Hoy no sólo les puedo decir eso mismo, sino cuántos vendimos en California, en el Condado de Orange, en la ciudad de Irvine, en el Supermercado local Von’s, en una promoción especial, al final del pasillo 4, los jueves".
Otra característica del Data Warehouse es que contiene datos relativos a los datos, concepto que se ha venido asociando al término de metadatos. Los metadatos permiten mantener información de la procedencia de la información, la periodicidad de refresco, su fiabilidad, forma de cálculo, etc., relativa a los datos de nuestro almacén.
Estos metadatos serán los que permitan simplificar y automatizar la obtención de la información desde los sistemas operacionales a los sistemas informacionales.
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 auditoría, 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.
Para comprender el concepto de Data Warehouse, es importante considerar los procesos que lo conforman. A continuación se describen dichos procesos clave en la gestión de un Data Warehouse:
Extracción: obtención de información de las distintas fuentes tanto internas como externas.
Elaboración: filtrado, limpieza, depuración, homogeneización y agrupación de la información.
Carga: organización y actualización de los datos y los metadatos en la base de datos.
Explotación: extracción y análisis de la información en los distintos niveles de agrupación.
Desde el punto de vista del usuario, el único proceso visible es la explotación del almacén de datos, aunque el éxito del Data Warehouse radica en los tres procesos iniciales que alimentan la información del mismo y suponen el mayor porcentaje de esfuerzo (en torno a un 80%) a la hora de desarrollar el almacén.
Una de las claves del éxito en la construcción de un Data Warehouse es el desarrollo de forma gradual, seleccionando a un departamento usuario como piloto y expandiendo progresivamente el almacén de datos a los demás usuarios. Por ello es importante elegir este usuario inicial o piloto, siendo importante que sea un departamento con pocos usuarios, en el que la necesidad de este tipo de sistemas es muy alta y se puedan obtener y medir resultados a corto plazo.
Terminamos este apartado, resumiendo los beneficios que un Data Warehouse puede aportar:
• Proporciona una herramienta para la toma de decisiones en cualquier área funcional, basándose en información integrada y global del negocio.
• Facilita la aplicación de técnicas estadísticas de análisis y modelización para encontrar relaciones ocultas entre los datos del almacén; obteniendo un valor añadido para el negocio de dicha información.
• Proporciona la capacidad de aprender de los datos del pasado y de predecir situaciones futuras en diversos escenarios.
• Simplifica dentro de la empresa la implantación de sistemas de gestión integral de la relación con el cliente.
• Supone una optimización tecnológica y económica en entornos de Centro de Información, estadística o de generación de informes con retornos de la inversión espectaculares.
2.2.- CONCEPTOS Y FUNCIONALIDADES BÁSICAS
2.2.1.- DATA WAREHOUSE VS. DATA MART
La duplicación en otro entorno de datos es un término que suele ser mal interpretado e incomprendido. Así es usado por los fabricantes de SGBD en el sentido de simple réplica de los datos de un sistema operacional centralizado en sistemas distribuidos. En un contexto de Data Warehouse, el término duplicación se refiere a la creación de Data Marts locales o departamentales basados en subconjuntos de la información contenida en el Data Warehouse central o maestro.
Según define Meta Group, "un Data Mart es una aplicación de Data Warehouse, construida rápidamente para soportar una línea de negocio simple". Los Data Marts, tienen las mismas características de integración, no volatilidad, orientación temática y no volatilidad que el Data Warehouse. Representan una estrategia de "divide y vencerás" para ámbitos muy genéricos de un Data Warehouse.
Esta estrategia es particularmente apropiada cuando el Data Warehouse central crece muy rápidamente y los distintos departamentos requieren sólo una pequeña porción de los datos contenidos en él. La creación de estos Data Marts requiere algo más que una simple réplica de los datos: se necesitarán tanto la segmentación como algunos métodos adicionales de consolidación.
La primera aproximación a una arquitectura descentralizada de Data Mart, podría ser venir originada de una situación como la descrita a continuación.
El departamento de Marketing, emprende el primer proyecto de Data Warehouse como una solución departamental, creando el primer Data Mart de la empresa.
Visto el éxito del proyecto, otros departamentos, como el de Riesgos, o el Financiero se lanzan a crear sus Data Marts. Marketing, comienza a usar otros datos que también usan los Data Marts de Riesgos y Financiero, y estos hacen lo propio.
Esto parece ser una decisión normal, puesto que las necesidades de información de todos los Data Marts crecen conforme el tiempo avanza. Cuando esta situación evoluciona, el esquema general de integración entre los Data Marts pasa a ser, la del gráfico de la derecha.
En esta situación, es fácil observar cómo este esquema de integración de información de los Data Marts, pasa a convertirse en un rompecabezas en el que la gestión se ha complicado hasta convertir esta ansia de información en un auténtico quebradero de cabeza. No obstante, lo que ha fallado no es la integración de Data Marts, sino su forma de integración.
En efecto, un enfoque más adecuado sería la coordinación de la gestión de información de todos los Data Marts en un Data Warehouse centralizado.
En esta situación los Data Marts obtendrían la información necesaria, ya previamente cargada y depurada en el Data Warehouse corporativo, simplificando el crecimiento de una base de conocimientos a nivel de toda la empresa.
Esta simplificación provendría de la centralización de las labores de gestión de los Data Marts, en el Data Warehouse corporativo, generando economías de escala en la gestión de los Data Marts implicados.
Según un estudio de IDC (International Data Corporation) tras analizar 541 empresas, la distribución de las implantaciones de Data Warehouse y Data Marts en la actualidad, y sus opiniones respecto a esta distribución en el futuro, nos muestra los siguientes datos:
En la gráfica, observamos, cómo en la actualidad, de las empresas consultadas, un 80% de ellas cuentan con implantaciones de Data Warehouse o Data Marts.
La proporción actual de implantaciones de Data Warehouse es casi el doble que el de Data Mart.
No obstante, seguramente tras la andadura inicial de alguno de estos proyectos de Data Mart, se ve como más adecuado para el futuro este enfoque "divide y vencerás", previéndose una inversión de estos papeles y duplicando la implantación de Data Marts a los Data Warehouse.
Probablemente, el 5% de usuarios que disponen de tecnología de Data Warehouse y piensan renunciar a ella en el futuro, no han realizado previamente un estudio de factores implicados en un Data Warehouse, o han pasado por la situación inicial de partida, y no se han planteado una reorganización del mismo.
2.2.2.- COMPONENTES A TENER EN CUENTA A LA HORA DE CONSTRUIR UN DW
2.2.2.1.-Hardware
Un componente fundamental a la hora de poder contar con un Data Warehouse que responda a las necesidades analíticas avanzadas de los usuarios, es el poder contar con una infraestructura hardware que la soporte.
En este sentido son críticas, a la hora de evaluar uno u otro hardware, dos características principales:
Por un lado, a este tipo de sistemas suelen acceder pocos usuarios con unas necesidades muy grandes de información, a diferencia de los sistemas operacionales, con muchos usuarios y necesidades puntuales de información. Debido a la flexibilidad requerida a la hora de hacer consultas complejas e imprevistas, y al gran tamaño de información manejada, son necesarias unas altas prestaciones de la máquina.
Por otro lado, debido a que estos sistemas suelen comenzar con una funcionalidad limitada, que se va expandiendo con el tiempo (situación por cierto aconsejada), es necesario que los sistemas sean escalables para dar soporte a las necesidades crecientes de equipamiento. En este sentido, será conveniente el optar por una arquitectura abierta, que nos permita aprovechar lo mejor de cada fabricante.
En el mercado se han desarrollado tecnologías basadas en tecnología de procesamiento paralelo, dan el soporte necesario a las necesidades de altas prestaciones y escalabilidad de los Data Warehouse. Estas tecnologías son de dos tipos:
• SMP (Symmetric multiprocessing, o Multiprocesadores Simétricos): Los sistemas tienen múltiples procesadores que comparten un único bus y una gran memoria, repartiéndose los procesos que genera el sistema, siendo el sistema operativo el que gestiona esta distribución de tareas. Estos sistemas se conocen como arquitecturas de "casi todo compartido". El aspecto más crítico de este tipo de sistemas es el grado de rendimiento relativo respecto al número de procesadores presentes, debido a su creciente no lineal.
• MPP (Massively parallel processing, o Multiprocesadores Masivamente Paralelos): Es una tecnología que compite contra la SMP, en la que los sistemas suelen ser casi independientes comunicados por intercambiadores de alta velocidad que permiten gestionarlos como un único sistema. Se conocen por ello como arquitecturas de "nada compartido". Su escalabilidad es mayor que la de los SMP.
Según Meta Group, las tendencias de mercado indican que las arquitecturas SMP aportan normalmente suficientes características de escalabilidad, con una mayor oferta y un menor riesgo tecnológico. Sin embargo, cuando las condiciones de escalabilidad sean extremas, se puede plantear la opción MPP.
No obstante, se están produciendo avances significativos en arquitecturas SMP, que han logrado máquinas con un crecimiento lineal de rendimiento hasta un número de 64 procesadores.
Recomendamos desde estas páginas, la visita a la dirección Internet:
http://www.tpc.org/bench.results.html
en donde la Transaction Processing Council (de la que son miembros ALR, Amdahl, Bull, Compaq, Data General, Dell, Digital, Fujitsu, HP, IBM, Intergraph, NCR , Siemens-Nixdorf, Sun o Unisys), realiza una comparativa entre las máquinas de sus miembros, proporcionando para diferentes modelos y diferentes configuraciones de Sistemas Operativos y Software de Base de Datos, un análisis de rendimiento (throughput), y un resumen de características (precio, número de procesadores, arquitectura y futuras versiones y fecha de disponibilidad).
2.2.2.2.-Software de almacenamiento (SGBD)
Como hemos comentado, el sistema que gestione el almacenamiento de la información (Sistema de Gestión de Base de Datos o SGBD), es otro elemento clave en un Data Warehouse. Independientemente de que la información almacenada en el Data Warehouse se pueda analizar mediante visualización multidimensional, el SGBD puede estar realizado utilizando tecnología de Bases de Datos Relacionales o Multidimensionales.
Las bases de datos relacionales, se han popularizado en los sistemas operacionales, pero se han visto incapaces de enfrentarse a las necesidades de información de los entornos Data Warehouse. Por ello, y puesto que, como hemos comentado, las necesidades de información suelen atender a consultas multidimensionales, parece que unas Bases de Datos multidimensionales, parten con ventaja. En este sentido son de aplicación los comentarios que realizamos en el apartado de hardware, por requerimientos de prestaciones, escalabilidad y consolidación tecnológica.
Al igual que en el hardware, nuevos diseños de las bases de datos relacionales, las bases de datos post-relacionales, abren un mayor abanico de elección. Estas bases de datos post-relacionales, parten de una tecnología consolidada y dan respuesta al agotamiento de las posibilidades de los sistemas de gestión de bases de datos relacionales, ofreciendo las mismas prestaciones aunque implantadas en una arquitectura diseñada de forma más eficiente.
Esta mayor eficiencia se consigue instaurando relaciones lógicas en vez de físicas, lo que hace que ya no sea necesario destinar más hardware a una solución para conseguir la ejecución de las funciones requeridas. El resultado es que la misma aplicación implantada en una BD post-relacional requiere menos hardware, puede dar servicio a un mayor número de usuarios y utilizar mecanismos intensivos de acceso a los datos más complejos. Asimismo, esta tecnología permite combinar las ventajas de las bases de datos jerárquicas y las relacionales con un coste más reducido. Ambos sistemas aportan como ventaja que no resulta necesario disponer de servidores omnipotentes, sin que puede partirse de un nivel de hardware modesto y ampliarlo a medida que crecen las necesidades de información de la compañía y el uso efectivo del sistema.
Dejamos fuera del ámbito de esta guía el detallar cómo los proveedores de bases de datos han optimizado los accesos a los índices, o las nuevas posibilidades que ofrece la compresión de datos (menos espacio para la misma información lo que implica, entre otras ventajas, que más información se puede tener en caché), para lo que remitimos a la prensa especializada o a las publicaciones de los fabricantes.
2.2.2.3.- Software de extracción y manipulación de datos
En este apartado analizaremos un componente esencial a la hora de implantar un Data Warehouse, la extracción y manipulación. Para esta labor, que entra dentro del ámbito de los profesionales de tecnologías de la información, es crítico el poder contar con herramientas que permitan controlar y automatizar los continuos "mimos" y necesidades de actualización del Data Warehouse.
Estas herramientas deberán proporcionar las siguientes funcionalidades:
• Control de la extracción de los datos y su automatización, disminuyendo el tiempo empleado en el descubrimiento de procesos no documentados, minimizando el margen de error y permitiendo mayor flexibilidad.
• Acceso a diferentes tecnologías, haciendo un uso efectivo del hardware, software, datos y recursos humanos existentes.
• Proporcionar la gestión integrada del Data Warehouse y los Data Marts existentes, integrando la extracción, transformación y carga para la construcción del Data Warehouse corporativo y de los Data Marts.
• Uso de la arquitectura de metadatos, facilitando la definición de los objetos de negocio y las reglas de consolidación.
• Acceso a una gran variedad de fuentes de datos diferentes.
• Manejo de excepciones.
• Planificación, logs, interfaces a schedulers de terceros.
• Interfaz independiente de hardware.
• Soporte en la explotación del Data Warehouse.
A veces, no se suele prestar la suficiente atención a esta fase de la gestión del Data Warehouse, aun cuando supone una gran parte del esfuerzo en la construcción de un Data Warehouse. Existen multitud de herramientas disponibles en el mercado que automatizan parte del trabajo, para lo cual recomendamos la visita a la página Internet:
http://pwp.starnetinc.com/larryg/clean.html
en la que se proporciona una lista de mas de 100 herramientas de extracción y manipulación de datos, con links a sus páginas Internet, y una somera descripción de la funcionalidad cubierta por cada herramienta.
2.2.2.4.- Herramientas Middleware
Como herramientas de soporte a la fase de gestión de un Data Warehouse, analizaremos a continuación dos tipos de herramientas:
• Por un lado herramientas Middleware, que provean conectividad entre entornos diferentes, para ayudar en la gestión del Data Warehouse.
• Por otro, analizadores y aceleradores de consultas, que permitan optimizar tiempos de respuestas en las necesidades analíticas, o de carga de los diferentes datos desde los sistemas operacionales hasta el Data Warehouse.
Las herramientas Middleware deben ser escalables siendo capaces de crecer conforme crece el Data Warehouse, sin problemas de volúmenes. Tambien deben ser flexibles y robustas, sin olvidarse de proporcionar un rendimiento adecuado. Estarán abiertas a todo tipos de entornos de almacenamiento de datos, tanto mediante estándares de facto (OLE, ODBC, etc.), como a los tipos de mercado más populares (DB2, Access, etc.). La conectividad, al menos en estándares de transporte (SNA LU6.2, DECnet, etc.) debe estar tambien asegurada.
Con el uso de estas herramientas de Middleware lograremos:
• Maximizar los recursos ejecutando las aplicaciones en la plataforma más adecuada.
• Integrar los datos y aplicaciones existentes en una plataforma distribuida.
• Automatizar la distribución de datos y aplicaciones desde un sistema centralizado.
• Reducir tráfico en la red, balanceando los niveles de cliente servidor (mas o menos datos en local, mas o menos proceso en local).
• Explotar las capacidades de sistemas remotos sin tener que aprender multiples entornos operativos.
• Asegurar la escalabilidad del sistema.
• Desarrollar aplicaciones en local y explotarlas en el servidor.
Los analizadores y aceleradores de querys trabajan volcando sobre un fichero de log las consultas ejecutadas y datos asociados a las mismas (tiempo de respuesta, tablas accedidas, método de acceso, etc). Este log se analiza, bien automáticamente o mediante la supervisión del administrador de datos, para mejorar los tiempos de accesos.
Estos sistemas de monitorización se pueden implementar en un entorno separado de pruebas, o en el entorno real. Si se ejecutan sobre un entorno de pruebas, el rendimiento del entorno real no se vé afectado. Sin embargo, no es posible optimizar los esfuerzos, puesto que los análisis efectuados pueden realizarse sobre consultas no críticas o no frecuentemente realizadas por los usuarios.
El implantar un sistema analizador de consultas, en el entorno real tiene además una serie de ventajas tales como:
• Se pueden monitorizar los tiempos de respuesta del entorno real.
• Se pueden implantar mecanismos de optimización de las consultas, reduciendo la carga del sistema.
• Se puede imputar costes a los usuarios por el coste del Data Warehouse.
• Se pueden implantar mecanismos de bloqueo para las consultas que vayan a implicar un tiempo de respuesta excesivo.
2.2.3.- FASES DE IMPLANTACIÓN DE UN DATA WAREHOUSE
Tal y como aparecía en un artículo en ComputerWorld: "Un Data Warehouse no se puede comprar, se tiene que construir". Como hemos mencionado con anterioridad, la construcción e implantación de un Data Warehouse es un proceso evolutivo.
Este proceso se tiene que apoyar en una metodología específica para este tipo de procesos, si bien es más importante que la elección de la mejor de las metodologías, el realizar un control para asegurar el seguimiento de la misma.
En las fases que se establezcan en el alcance del proyecto es fundamental el incluir una fase de formación en la herramienta utilizada para un máximo aprovechamiento de la aplicación. El seguir los pasos de la metodología y el comenzar el Data Warehouse por un área específica de la empresa, nos permitirá obtener resultados tangibles en un corto espacio de tiempo.
Planteamos aquí la metodología propuesta por SAS Institute: la "Rapid Warehousing Methodology". Dicha metodología es iterativa, y está basada en el desarrollo incremental del proyecto de Data Warehouse dividido en cinco fases:
• Definición de los objetivos
• Definición de los requerimientos de información
• Diseño y modelización
• Implementación
• Revisión
2.2.3.1-Definición de los objetivos
2.2.3.2.-Definición de los requerimientos de información
Tal como sucede en todo tipo de proyectos, sobre todo si involucran técnicas novedosas como son las relativas al Data Warehouse, es analizar las necesidades y hacer comprender las ventajas que este sistema puede reportar.
Es por ello por lo que nos remitimos al apartado de esta guía de Análisis de las necesidades del comprador. Será en este punto, en donde detallaremos los pasos a seguir en un proyecto de este tipo, en donde el usuario va a jugar un papel tan destacado.
2.2.3.3.-Diseño y modelización
Los requerimientos de información identificados durante la anterior fase proporcionarán las bases para realizar el diseño y la modelización del Data Warehouse.
En esta fase se identificarán las fuentes de los datos (sistema operacional, fuentes externas,..) y las transformaciones necesarias para, a partir de dichas fuentes, obtener el modelo lógico de datos del Data Warehouse. Este modelo estará formado por entidades y relaciones que permitirán resolver las necesidades de negocio de la organización.
El modelo lógico se traducirá posteriormente en el modelo físico de datos que se almacenará en el Data Warehouse y que definirá la arquitectura de almacenamiento del Data Warehouse adaptándose al tipo de explotación que se realice del mismo.
La mayor parte estas definiciones de los datos del Data Warehouse estarán almacenadas en los metadatos y formarán parte del mismo.
2.2.3.4.-Implementación
La implantación de un Data Warehouse lleva implícitos los siguientes pasos:
• Extracción de los datos del sistema operacional y transformación de los mismos.
• Carga de los datos validados en el Data Warehouse. Esta carga deberá ser planificada con una periodicidad que se adaptará a las necesidades de refresco detectadas durante las fases de diseño del nuevo sistema.
• Explotación del Data Warehouse mediante diversas técnicas dependiendo del tipo de aplicación que se de a los datos:
Query & Reporting
On-line analytical processing (OLAP)
Executive Information System (EIS) ó Información de gestión
Decision Support Systems (DSS)
Visualización de la información
Data Mining ó Minería de Datos, etc.
La información necesaria para mantener el control sobre los datos se almacena en los metadatos técnicos (cuando describen las características físicas de los datos) y de negocio (cuando describen cómo se usan esos datos). Dichos metadatos deberán ser accesibles por los usuarios finales que permitirán en todo momento tanto al usuario, como al administrador que deberá además tener la facultad de modificarlos según varíen las necesidades de información.
Con la finalización de esta fase se obtendrá un Data Warehouse disponible para su uso por parte de los usuarios finales y el departamento de informática.
2.2.3.5.-Revisión
La construcción del Data Warehouse no finaliza con la implantación del mismo, sino que es una tarea iterativa en la que se trata de incrementar su alcance aprendiendo de las experiencias anteriores.
Después de implantarse, debería realizarse una revisión del Data Warehouse planteando preguntas que permitan, después de los seis o nueve meses posteriores a su puesta en marcha, definir cuáles serían los aspectos a mejorar o potenciar en función de la utilización que se haga del nuevo sistema.
2.2.3.6.-Diseño de la estructura de cursos de formación
Con la información obtenida de reuniones con los distintos usuarios se diseñarán una serie de cursos a medida, que tendrán como objetivo el proporcionar la formación estadística necesaria para el mejor aprovechamiento de la funcionalidad incluida en la aplicación. Se realizarán prácticas sobre el desarrollo realizado, las cuales permitirán fijar los conceptos adquiridos y servirán como formación a los usuarios.
2.2.4.- ESTRATEGIAS DE IMPLANTACIÓN
Resaltamos en esta guía algunas consideraciones que recomendamos deben seguirse a la hora de abordar un proyecto de este tipo:
"La Base de Datos de Riesgos debe estar separada de las Bases de Datos Operacionales" con objeto de no interferir en la actividad del día a día, disponiendo de la información necesaria para Riesgos (interna y externa) y en un entorno orientado hacia la consulta y el análisis (Data Warehouse).
"Concepción del sistema como un conjunto de herramientas de análisis", debido a que las actividades de Análisis de Riesgos no se pueden automatizar completamente, puesto que requieren análisis y decisiones del usuario.
"Diseño del sistema no orientado a procesos"; se debe disponer de un conjunto abierto de herramientas que se utilizan con propósitos determinados no relacionados con las necesidades operativas.
"Abordar el sistema con un enfoque de desarrollo gradual", se debe comenzar con un esqueleto básico de funcionalidad y datos que produzcan resultados a corto plazo y permita aprender en la práctica, y a continuación ir configurando progresivamente nuevas funcionalidades conforme la experiencia lo vaya requiriendo.
Son de aplicación en este apartado las consideraciones que realizamos en los apartados Data Warehouse vs. Data Marts y Fases de Implantación de un Data Warehouse.
2.2.5.-TÉCNICAS DE EXPLOTACIÓN DE LA IMPLANTACIÓN
Dentro del esquema de Gestión y Explotación del Data Warehouse que se muestra en el gráfico, pasamos a detallar las posibilidades que nos ofrece esta última fase.
En ella, examinaremos
1. el uso que se puede realizar de las utilidades OLAP del Data Warehouse para análisis multidimensionales,
2. las facilidades de obtención de información mediante consultas e informes libre, y el uso de técnicas de Data Mining que nos permitan descubrir "información oculta" en los datos mediante el uso de técnicas estadísticas.
2.2.5.1.- OLAP, ROLAP, MOLAP
La explotación del Data Warehouse mediante información de gestión, se fundamenta básicamente en los niveles agrupados o calculados de información.
La información de gestión se compone de conceptos de información y coeficientes de gestión, que los cuadros directivos de la empresa pueden consultar según las dimensiones de negocio que se definan.
Dichas dimensiones de negocio se estructuran a su vez en distintos niveles de detalle (por ejemplo, la dimensión geográfica puede constar de los niveles nacional, provincial, ayuntamientos y sección censal).
Este tipo de sistemas ha existido desde hace tiempo, en el mundo de la informática bajo distintas denominaciones: cuadros de mando, MIS, EIS, etc.
Su realización fuera del entorno del Data Warehouse, puede repercutir sobre estos sistemas en una mayor rigidez, dificultad de actualización y mantenimiento, malos tiempos de respuesta, incoherencias de la información, falta del dato agregado, etc.
Los sistemas de soporte a la decisión usando tecnologías de Data Warehouse, se llaman sistemas OLAP (siglas de On Line Analytical Processing (OLAP). En general, estos sistemas OLAP deben:
• Soportar requerimientos complejos de análisis
• Analizar datos desde diferentes perspectivas
• Soportar análisis complejos contra un volumen ingente de datos
La funcionalidad de los sistemas OLAP se caracteriza por ser un análisis multidimensional de datos corporativos, que soportan los análisis del usuario y unas posibilidades de navegación, seleccionando la información a obtener.
Normalmente este tipo de selecciones se ve reflejada en la visualización de la estructura multidimensional, en unos campos de selección que nos permitan elegir el nivel de agregación (jerarquía) de la dimensión, y/o la elección de un dato en concreto, la visualización de los atributos del sujeto, frente a una(s) dimensiones en modo tabla, pudiendo con ello realizar, entre otras las siguientes acciones:
Rotar (Swap): alterar las filas por columnas (permutar dos dimensiones de análisis)
Bajar (Down): bajar el nivel de visualización en las filas a una jerarquía inferior
Detallar (Drilldown): informar para una fila en concreto, de datos a un nivel inferior
Expandir (Expand): id. anterior sin perder la información a nivel superior para éste y el resto de los valores
Colapsar (Collapse): operación inversa de la anterior.
Para ampliar el glosario sobre exploraciones en análisis OLAP, recomendamos la visita a la página Internet:
http://www.kenan.com/acumate/olaptrms.htm
en donde se describen en torno a 50 términos relacionados con las posibilidades de navegación que permiten este tipo de análisis.
Existen dos arquitecturas diferentes para los sistemas OLAP: OLAP multidimensional (MOLAP) y OLAP relacionales (ROLAP).
2.2.5.1.1.-Sistemas MOLAP
La arquitectura MOLAP usa unas bases de datos multidimensionales para proporcionar el análisis, su principal premisa es que el OLAP está mejor implantado almacenando los datos multidimensionalmente. Por el contrario, la arquitectura ROLAP cree que las capacidades OLAP están perfectamente implantadas sobre bases de datos relacionales
Un sistema MOLAP usa una base de datos propietaria multidimensional, en la que la información se almacena multidimensionalmente, para ser visualizada multidimensionalmente.
El sistema MOLAP utiliza una arquitectura de dos niveles: La bases de datos multidimensionales y el motor analítico.
• La base de datos multidimensional es la encargada del manejo, acceso y obtención del dato.
• El nivel de aplicación es el responsable de la ejecución de los requerimientos OLAP. El nivel
de presentación se integra con el de aplicación y proporciona un interfaz a través del cual
los usuarios finales visualizan los análisis OLAP. Una arquitectura cliente/servidor permite a varios usuarios
acceder a la misma base de datos multidimensional.
La información procedente de los sistemas operacionales, se carga en el sistema MOLAP, mediante una serie de rutinas batch. Una vez cargado el dato elemental en la Base de Datos multidimensional (MDDB), se realizan una serie de cálculos en batch, para calcular los datos agregados, a través de las dimensiones de negocio, rellenando la estructura MDDB.
Tras rellenar esta estructura, se generan unos índices y algoritmos de tablas hash para mejorar los tiempos de accesos a las consultas.
Una vez que el proceso de compilación se ha acabado, la MDDB está lista para su uso. Los usuarios solicitan informes a través del interface, y la lógica de aplicación de la MDDB obtiene el dato.
La arquitectura MOLAP requiere unos cálculos intensivos de compilación. Lee de datos precompilados, y tiene capacidades limitadas de crear agregaciones dinámicamente o de hallar ratios que no se hayan precalculados y almacenados previamente.
2.2.5.1.2.-Sistemas ROLAP
La arquitectura ROLAP, accede a los datos almacenados en un Data Warehouse para proporcionar los análisis OLAP. La premisa de los sistemas ROLAP es que las capacidades OLAP se soportan mejor contra las bases de datos relacionales.
El sistema ROLAP utiliza una arquitectura de tres niveles. La base de datos relacional maneja los requerimientos de almacenamiento de datos, y el motor ROLAP proporciona la funcionalidad analítica.
• El nivel de base de datos usa bases de datos relacionales para el manejo, acceso y obtención del dato.
• El nivel de aplicación es el motor que ejecuta las consultas multidimensionales de los usuarios.
• El motor ROLAP se integra con niveles de presentación, a través de los cuales los usuarios realizan
los análisis OLAP.
Después de que el modelo de datos para el Data Warehouse se ha definido, los datos se cargan desde el sistema operacional. Se ejecutan rutinas de bases de datos para agregar el dato, si así es requerido por el modelos de datos.
Se crean entonces los índices para optimizar los tiempos de acceso a las consultas.
Los usuarios finales ejecutan sus análisis multidimensionales, a través del motor ROLAP, que transforma dinámicamente sus consultas a consultas SQL. Se ejecutan estas consultas SQL en las bases de datos relacionales, y sus resultados se relacionan mediante tablas cruzadas y conjuntos multidimensionales para devolver los resultados a los usuarios.
La arquitectura ROLAP es capaz de usar datos precalculados si estos están disponibles, o de generar dinámicamente los resultados desde los datos elementales si es preciso. Esta arquitectura accede directamente a los datos del Data Warehouse, y soporta técnicas de optimización de accesos para acelerar las consultas. Estas optimizaciones son, entre otras, particionado de los datos a nivel de aplicación, soporte a la desnormalización y joins múltiples.
2.2.5.1.3.-ROLAP vs. MOLAP (Comparativa)
Cuando se comparan las dos arquitecturas, se pueden realizar las siguientes observaciones:
• El ROLAP delega la negociación entre tiempo de respuesta y el proceso batch al diseño del sistema.
Mientras, el MOLAP, suele requerir que sus bases de datos se precompilen para conseguir un rendimiento aceptable
en las consultas, incrementando, por tanto los requerimientos batch.
• Los sistemas con alta volatilidad de los datos (aquellos en los que cambian las reglas de agregación
y consolidación), requieren una arquitectura que pueda realizar esta consolidación ad-hoc. Los sistemas
ROLAP soportan bien esta consolidación dinámica, mientras que los MOLAP están más orientados
hacia consolidaciones batch.
• Los ROLAP pueden crecer hasta un gran número de dimensiones, mientras que los MOLAP generalmente son
adecuados para diez o menos dimensiones.
• Los ROLAP soportan análisis OLAP contra grandes volúmenes de datos elementales, mientras que
los MOLAP se comportan razonablemente en volúmenes más reducidos (menos de 5 Gb)
Por ello, y resumiendo, el ROLAP es una arquitectura flexible y general, que crece para dar soporte a amplios requerimientos OLAP. El MOLAP es una solución particular, adecuada para soluciones departamentales con unos volúmenes de información y número de dimensiones más modestos.
2.2.5.2.- QUERY & REPORTING
Las consultas o informes libres trabajan tanto sobre el detalle como sobre las agregaciones de la información.
Realizar este tipo de explotación en un almacén de datos supone una optimización del tradicional entorno de informes (reporting), dado que el Data Warehouse mantiene una estructura y una tecnología mucho más apropiada para este tipo de solicitudes.
Los sistemas de "Query & Reporting", no basados en almacenes de datos se caracterizan por la complejidad de las consultas, los altísimos tiempos de respuesta y la interferencia con otros procesos informáticos que compartan su entorno.
La explotación del Data Warehouse mediante "Query & Reporting" debe permitir una gradación de la flexibilidad de acceso, proporcional a la experiencia y formación del usuario. A este respecto, se recomienda el mantenimiento de al menos tres niveles de dificultad:
• Los usuarios poco expertos podrán solicitar la ejecución de informes o consultas predefinidas según unos parámetros predeterminados.
• Los usuarios con cierta experiencia podrán generar consultas flexibles mediante una aplicación que proporcione una interfaz gráfica de ayuda.
• Los usuarios altamente experimentados podrán escribir, total o parcialmente, la consulta en un lenguaje de interrogación de datos.
Hay una extensa gama de herramientas en el mercado para cumplir esta funcionalidad sobre entornos de tipo Data Warehouse, por lo que se puede elegir el software más adecuado para cada problemática empresarial concreta.
2.2.5.3.- DATA MINING O MINERÍA DE DATOS
El Data Mining es un proceso que, a través del descubrimiento y cuantificación de relaciones predictivas en los datos, permite transformar la información disponible en conocimiento útil de negocio. Esto es debido a que no es suficiente "navegar" por los datos para resolver los problemas de negocio, sino que se hace necesario seguir una metodología ordenada que permita obtener rendimientos tangibles de este conjunto de herramientas y técnicas de las que dispone el usuario.
Constituye por tanto una de las vías clave de explotación del Data Warehouse, dado que es este su entorno natural de trabajo.
Se trata de un concepto de explotación de naturaleza radicalmente distinta a la de los sistemas de información de gestión, dado que no se basa en coeficientes de gestión o en información altamente agregada, sino en la información de detalle contenida en el almacén. Adicionalmente, el usuario no se conforma con la mera visualización de datos, sino que trata de obtener una relación entre los mismos que tenga repercusiones en su negocio.
2.2.5.3.2.Técnicas de Data Mining
Para soportar el proceso de Data Mining, el usuario dispone de una extensa gama de técnicas que le pueden ayudar en cada una de las fases de dicho proceso, las cuales pasamos a describir:
Análisis estadístico:
Utilizando las siguientes herramientas:
1. ANOVA: o Análisis de la Varianza, contrasta si existen diferencias significativas entre las medidas de una o más variables continuas en grupo de población distintos.
2. Regresión: define la relación entre una o más variables y un conjunto de variables predictoras de las primeras.
3. Ji cuadrado: contrasta la hipótesis de independencia entre variables.
4. Componentes principales: permite reducir el número de variables observadas a un menor número de variables artificiales, conservando la mayor parte de la información sobre la varianza de las variables.
5. Análisis cluster: permite clasificar una población en un número determinado de grupos, en base a semejanzas y desemejanzas de perfiles existentes entre los diferentes componentes de dicha población.
6. Análisis discriminante: método de clasificación de individuos en grupos que previamente se han establecido, y que permite encontrar la regla de clasificación de los elementos de estos grupos, y por tanto identificar cuáles son las variables que mejor definan la pertenencia al grupo.
Métodos basados en árboles de decisión:
El método Chaid (Chi Squared Automatic Interaction Detector) es un análisis que genera un árbol de decisión para predecir el comportamiento de una variable, a partir de una o más variables predictoras, de forma que los conjuntos de una misma rama y un mismo nivel son disjuntos. Es útil en aquellas situaciones en las que el objetivo es dividir una población en distintos segmentos basándose en algún criterio de decisión.
El árbol de decisión se construye partiendo el conjunto de datos en dos o más subconjuntos de observaciones a partir de los valores que toman las variables predictoras. Cada uno de estos subconjuntos vuelve después a ser particionado utilizando el mismo algoritmo. Este proceso continúa hasta que no se encuentran diferencias significativas en la influencia de las variables de predicción de uno de estos grupos hacia el valor de la variable de respuesta.
La raíz del árbol es el conjunto de datos íntegro, los subconjuntos y los subsubconjuntos conforman las ramas del árbol. Un conjunto en el que se hace una partición se llama nodo.
El número de subconjuntos en una partición puede ir de dos hasta el número de valores distintos que puede tomar la variable usada para hacer la separación. La variable de predicción usada para crear una partición es aquella más significativamente relacionada con la variable de respuesta de acuerdo con test de independencia de la Chi cuadrado sobre una tabla de contingencia.
Algoritmos genéticos:
Son métodos numéricos de optimización, en los que aquella variable o variables que se pretenden optimizar junto con las variables de estudio constituyen un segmento de información. Aquellas configuraciones de las variables de análisis que obtengan mejores valores para la variable de respuesta, corresponderán a segmentos con mayor capacidad reproductiva. A través de la reproducción, los mejores segmentos perduran y su proporción crece de generación en generación. Se puede además introducir elementos aleatorios para la modificación de las variables (mutaciones). Al cabo de cierto número de iteraciones, la población estará constituida por buenas soluciones al problema de optimización.
Redes neuronales:
Genéricamente son métodos de proceso numérico en paralelo, en el que las variables interactúan mediante transformaciones lineales o no lineales, hasta obtener unas salidas. Estas salidas se contrastan con los que tenían que haber salido, basándose en unos datos de prueba, dando lugar a un proceso de retroalimentación mediante el cual la red se reconfigura, hasta obtener un modelo adecuado.
Lógica difusa:
Es una generalización del concepto de estadística. La estadística clásica se basa en la teoría de probabilidades, a su vez ésta en la técnica conjuntista, en la que la relación de pertenencia a un conjunto es dicotómica (el 2 es par o no lo es). Si establecemos la noción de conjunto borroso como aquel en el que la pertenencia tiene una cierta graduación (¿un día a 20ºC es caluroso?), dispondremos de una estadística más amplia y con resultados más cercanos al modo de razonamiento humano.
Series temporales:
Es el conocimiento de una variable a través del tiempo para, a partir de ese conocimiento, y bajo el supuesto de que no van a producirse cambios estructurales, poder realizar predicciones. Suelen basarse en un estudio de la serie en ciclos, tendencias y estacionalidades, que se diferencian por el ámbito de tiempo abarcado, para por composición obtener la serie original. Se pueden aplicar enfoques híbridos con los métodos anteriores, en los que la serie se puede explicar no sólo en función del tiempo sino como combinación de otras variables de entorno más estables y, por lo tanto, más fácilmente predecibles.
2.2.5.3.3. Metodología de aplicación:
Para utilizar estas técnicas de forma eficiente y ordenada es preciso aplicar una metodología estructurada, al proceso de Data Mining. A este respecto proponemos la siguiente metodología, siempre adaptable a la situación de negocio particular a la que se aplique:
Muestreo
Extracción de la población muestral sobre la que se va a aplicar el análisis. En ocasiones se trata de una muestra aleatoria, pero puede ser también un subconjunto de datos del Data Warehouse que cumplan unas condiciones determinadas. El objeto de trabajar con una muestra de la población en lugar de toda ella, es la simplificación del estudio y la disminución de la carga de proceso. La muestra más óptima será aquella que teniendo un error asumible contenga el número mínimo de observaciones.
En el caso de que se recurra a un muestreo aleatorio, se debería tener la opción de elegir
• El nivel de confianza de la muestra (usualmente el 95% o el 99%).
• El tamaño máximo de la muestra (número máximo de registros), en cuyo caso el sistema deberá informar del el error cometido y la representatividad de la muestra sobre la población original.
• El error muestral que está dispuesto a cometer, en cuyo caso el sistema informará del número de observaciones que debe contener la muestra y su representatividad sobre la población original.
Para facilitar este paso s debe disponer de herramientas de extracción dinámica de información con o sin muestreo (simple o estratificado). En el caso del muestreo, dichas herramientas deben tener la opción de, dado un nivel de confianza, fijar el tamaño de la muestra y obtener el error o bien fijar el error y obtener el tamaño mínimo de la muestra que nos proporcione este grado de error.
Exploración
Una vez determinada la población que sirve para la obtención del modelo se deberá determinar cuales son las variables explicativas que van a servir como "inputs" al modelo. Para ello es importante hacer una exploración por la información disponible de la población que nos permita eliminar variables que no influyen y agrupar aquellas que repercuten en la misma dirección.
El objetivo es simplificar en lo posible el problema con el fin de optimizar la eficiencia del modelo. En este paso se pueden emplear herramientas que nos permitan visualizar de forma gráfica la información utilizando las variables explicativas como dimensiones.
También se pueden emplear técnicas estadísticas que nos ayuden a poner de manifiesto relaciones entre variables. A este respecto resultará ideal una herramienta que permita la visualización y el análisis estadístico integrados
Manipulación
Tratamiento realizado sobre los datos de forma previa a la modelización, en base a la exploración realizada, de forma que se definan claramente los inputs del modelo a realizar (selección de variables explicativas, agrupación de variables similares, etc.).
Modelización
Permite establecer una relación entre las variables explicativas y las variables objeto del estudio, que posibilitan inferir el valor de las mismas con un nivel de confianza determinado.
Valoración
Análisis de la bondad del modelo contrastando con otros métodos estadísticos o con nuevas poblaciones muestrales.
2.2.5.4.- WEBHOUSING
La popularización de Internet y la tecnología Web, ha creado un nuevo esquema de información en el cual los clientes tienen a su disposición unas cantidades ingentes de información. La integración de las tecnologías Internet y Data Warehouse tienen una serie de ventajas como son:
• Consistencia: toda la organización accede al mismo conjunto de datos y ve los informes que reflejan
sus necesidades. Hay una "única versión de la verdad".
• Accesibilidad: la empresa acede a la información a través de un camino común (el browser
de Internet), simplificando el proceso de búsqueda de la información.
• Disponibilidad: la información es accesible en todo momento, independientemente de los sistemas operacionales.
• Bajos costes de desarrollo y mantenimiento, debidos a la estandarización de las aplicaciones de consultas
basadas en Internet, independientemente del sistema operativo que soporte el browser, y de la reducción
de los costes de distribución de software en los puestos clientes.
• Protección de los datos, debido al uso de tecnologías consolidadas de protección en entornos
de red (firewalls).
• Bajos costes de formación, debido al uso de interfaces tipo Web.
La interactividad de las aplicaciones en este entorno pueden tener varios niveles:
• Publicación de datos: las páginas distribuyen información obtenida del Data Warehouse,
volcada en las páginas intra/internet.
• Distribución de reportes: dando soporte a consultas simples elaboradas por los usuarios.
• Aplicaciones dinámicas: sirviendo de soporte de decisión a servicios solicitados desde el puesto
cliente, ejecutando la petición en el servidor y devolviéndolas al cliente, vía el browser
de Internet o haciendo uso de "applets" de Java.
Las arquitecturas base de una implantación de Data Warehouse en Internet, pueden tener las siguientes
alternativas:
1. Usar el Servidor Internet como router, y ejecutar la petición desde el cliente al servidor directamente.
2. Hacer uso del navegador para visualizar una página Internet residente en el servidor de Internet. Esta
página contendría información que se actualizaría en el servidor Internet, desde el
servidor DW, a petición del usuario haciendo uso de CGI's.
3. El cliente podría lanzar su consulta directamente al servidor de DW, con "applets" de Java,
haciendo el servidor Internet únicamente de encaminamiento (router).
4. El cliente podría ejecutar la aplicación DW desde el navegador, pero con un plug-in, que haría
que se tuvieran las mismas opciones que la aplicación DW.
5. Realizar una descarga masiva de datos con un protocolo de transferencia de ficheros (FTP), para su proceso
en local.
El alcance funcional de la implantación del Data Warehouse, basado en tecnologías Internet, puede ser la misma que la realizada sin su uso. En este sentido las críticas que se le pueden achacar en la actualidad, provienen de la baja velocidad de las líneas actuales, que se solventa parcialmente mediante el uso de aplicaciones Java, en lugar de hacer uso de páginas HTML, o CGI. Solución parcial, mientras la velocidad de transferencia se incrementa día a día mediante nuevos algoritmos de compresión de datos o el uso de líneas de alta capacidad RDSI.
2.2.6.- TIPOS DE APLICACIONES EN LAS QUE UTILIZAR LAS TÉCNICAS DISPONIBLES SOBRE EL DW
2.2.6.1. Data Warehouse y Sistemas de Marketing
La aplicación de tecnologías de Data Warehouse supone un nuevo enfoque de Marketing, haciendo uso del Marketing de Base de Datos. En efecto, un sistema de Marketing Warehouse implica un marketing científico, analítico y experto, basado en el conocimiento exhaustivo de clientes, productos, canales y mercado.
Este conocimiento se deriva de la disposición de toda la información necesaria, tanto interna como externa, en un entorno de Data Warehouse, persiguiendo con toda esta información, la optimización de las variables controladas del Marketing Mix y el soporte a la predicción de las variables no controlables (mediante técnicas de Data Mining). Basándose en el conocimiento exhaustivo de los clientes se consigue un tratamiento personalizado de los mismos tanto en el día a día (atención comercial) como en acciones de promoción específicas.
Las áreas en las que se puede aplicar las tecnologías de Data Warehouse a Marketing son, entre otras:
• Investigación Comercial
• Segmentación de mercados
• Identificación de necesidades no cubiertas y generación de nuevos productos, o modificación de productos existentes
• Fijación de precios y descuentos
• Definición de la estrategia de canales de comercialización y distribución
• Definición de la estrategia de promoción y atención al cliente
• Relación con el cliente:
• Programación, realización y seguimiento de acciones comerciales
• Lanzamiento de nuevos productos
• Campañas de venta cruzada, vinculación, fidelización, etc.
• Apoyo al canal de venta con información cualificada
2.2.6.2. Data Warehouse y Análisis de Riesgo Financiero
El Data Warehouse aplicado al análisis de riesgos financieros ofrece capacidades avanzadas de desarrollo de aplicaciones para dar soporte a las diversas actividades de gestión de riesgos. Es posible desarrollar cualquier herramienta utilizando las funciones que incorpora la plataforma, gracias a la potencionalidad estadística aplicada al riesgo de crédito.
Así se puede usar para llevar a cabo las siguientes funcionalidades:
• Para la gestión de la posición:
Determinación de la posición, Cálculo de sensibilidades, Análisis what/if, Simulaciones, Monitorización riesgos contra límites, etc.
• Para la medición del riesgo:
Soporte metodología RiskMetrics (Metodología registrada de J.P. Morgan / Reuters), Simulación de escenarios históricos, Modelos de covarianzas, Simulación de Montecarlo, Modelos de valoración, Calibración modelos valoración, Análisis de rentabilidad, Establecimiento y seguimiento. de límites, Desarrollo/modificación modelos, Stress testing, etc.
El uso del Data Warehouse ofrece una gran flexibilidad para creación o modificación de modelos propios de valoración y medición de riesgos, tanto motivados por cambios en la regulación, como en avances en la modelización de estos instrumentos financieros.
Ello por cuanto se puede almacenar y poner a disposición información histórica de mercado y el uso de técnicas de Data Mining nos simplifica la implantación de cualquier método estadístico. Los métodos de previsión, se pueden realizar usando series históricas, (GARCH, ARIMA, etc.)
Pero la explotación de la información nos permite no solo la exploración de los datos para un conocimiento de la información histórica, sino también para examinar condiciones de normalidad de las que la mayoría de las metodologías de valoración del riesgo parten.
Además de implantar modelos ya existentes, se pueden acometer análisis con vistas a determinar modelos propios, basados en análisis de correlación para el estudio de la valoración del riesgo de carteras o procesos de simulación de Montecarlo.
Todo ello en una plataforma avanzada de gestión de la información basada en la fácil visualización de la misma y de su análisis estadístico como soporte a metodologías estándar de facto, o a las particularidades de cada entorno.
2.2.6.3. Data Warehouse y Análisis de Riesgo de Crédito
La información relativa a clientes y su entorno se ha convertido en fuente de prevención de Riesgos de Crédito. En efecto, existe una tendencia general en todos los sectores a recoger, almacenar y analizar información crediticia como soporte a la toma de decisiones de Análisis de Riesgos de Crédito.
Los avances en la tecnología de Data Warehouse hacen posible la optimización de los sistemas de Análisis de Riesgo de Crédito:
Para la gestión del riesgo de crédito los sistemas operacionales han ofrecido:
• Sistemas de Información para Gerencia (MIS) e informes de Soporte a la Decisión de Problemas (DSS) estáticos y no abiertos a nuevas relaciones y orígenes de datos, situación en la que la incorporación de nuevas fuentes de información ha sido un problema en lugar de una ventaja.
• Exploraciones de datos e informes cerrados y estáticos.
• Análisis sin inclusión de consideraciones temporales lo que imposibilita el análisis del pasado y la previsión del futuro.
• Herramientas de credit-scoring no flexibles, construidas sobre algoritmos difícilmente modificables, no adaptados al entorno de la empresa, o exclusivamente basados en la experiencia personal no contrastada, con lo que los sistemas han ayudado a repetir los errores en vez de a corregirlos.
Pero estos sistemas tradicionales se enfrentan a una problemática difícil de resolver para acomodarse a las necesidades analíticas de los Sistemas de Análisis del Riesgo, necesidades que se pueden cubrir mediante el uso de tecnologías de Data Warehouse
Dentro de la Prevención de Impagados, utilizando sistemas OLAP se puede obtener el grado interno de concentración de riesgos con el cliente, y almacenar la variedad de fuentes internas o externas de información disponibles sobre el mismo. Ello nos permite obtener sin dificultad la posición consolidada respecto al riesgo del cliente. El análisis se puede realizar asimismo por las diferentes características de la operación para la que se realiza el análisis, en cuanto al plazo y la cuantía de la misma, la modalidad de crédito elegida, la finalidad de la operación o las garantías asociadas a la misma. Usando las mismas capacidades es fácil el establecer una segmentación ABC de la cartera de clientes potenciales o reales que nos optimicen el nivel de esfuerzo en el Análisis de Riesgos.
En el soporte al proceso de Anticipación al Riesgo, se puede dar un adecuado soporte a la correcta generación y consideración de señales de alerta, teniendo en cuenta las pautas y condicionantes diferenciados dependiendo del tipo de cliente y producto usando Data Mining
Para el caso del Seguimiento del ciclo de Impagados, de nuevo el uso de sistemas OLAP, simplifican el análisis la diversidad de los diferentes parámetros que intervienen en el mismo, tales como la jerarquía de centros de recobro a contemplar, la diferente consideración dependiendo de la antigüedad del impago, del cliente o del importe impagado. Un sistema de Data Mining puede aconsejar la mejor acción en caso de impagados, litigio, precontencioso, etc. frente a los parámetros de importe, antigüedad, zona geográfica, etc.
Estos sistemas hacen que el analista se dedique con más intensidad al análisis de la información, que es donde aporta su mayor valor añadido, que a la obtención de la misma. No obstante, estos sistemas deben de huir de las automatizaciones completas sin intervención del analista: es él el que mejor sabe lo que quiere descubrir. "La herramienta debe ser un medio y no un fin".
2.2.6.4. Data Warehouse: Otras áreas de aplicación
Otras áreas de la empresa han aplicado las soluciones que proporciona la tecnología Data Warehouse para mejorar gran parte de sus procesos actuales. Entre ellas destacamos:
• Control de Gestión:
Sistemas de Presupuestación, Análisis de Desviaciones, Reporting (EIS, MIS, etc.)
• Logística:
Mejora de la relación con proveedores, Racionalización de los procesos de control de inventarios, Optimización de los niveles de producción, Previsión de la demanda en infraestructura.
• Recursos Humanos
Planificación de incorporaciones, Gestión de carreras profesionales, Asignación de recursos a proyectos alternativos, etc.
2.2.7.- SEGURIDAD DE ACCESO Y MANIPULACIÓN DE LA INFORMACIÓN EN EL DW
A continuación trataremos las consideraciones a contemplar en cuanto a seguridad de accesos y seguridad de datos (backup), puesto que si bien la seguridad de accesos (al nivel de datos y de aplicación) debe ser tratada de la misma manera que en los sistemas operacionales, los procedimientos de copias de seguridad merecen un especial tratamiento.
Tal y como ocurre en los sistemas operacionales, un sistema Data Warehouse debe poder realizar procedimientos de recuperación de la información desde cualquier momento en el que los datos estaban validados. Un Data Warehouse, debe poder contar con procedimientos de recuperación, que permitan recuperar los datos ante cualquier situación de catástrofe.
No obstante, es preciso tener en cuenta otras consideraciones, así por ejemplo dependiendo del tamaño de un Data Mart, se puede elegir no realizar un backup, sino realizar un refresco especial desde los datos operacionales, dependiendo de la periodicidad estándar de carga.
En cuanto a la seguridad de acceso, se cumple en los sistemas de Data Warehouse, que es preciso el implantar niveles de acceso a la información, realizando un plan completo de seguridad que contemple:
• Acceso a recursos de la red (local o intranet)
• Asignación de usuarios a grupos con perfiles de seguridad diferenciados
• Asignación de niveles de autorización de aplicación a grupos de usuarios
• Seguridad a nivel de Base de Datos, mediante los procedimientos provistos por las mismas.
• Etc.
2.3.- TENDENCIAS TECNOLÓGICAS Y DE MERCADO
Describimos a continuación una recopilación de las principales tendencias observadas en el mercado. Estas tendencias se han comentado con anterioridad en otros apartados de esta Guía y se hace referencia a dichos puntos.
Tendencias hacia herramientas especializados:
El uso de herramientras de propósito general no satisface por completo las necesidades de un proyecto de Data Warehouse. Se ha comentado en esta guía las Herramientas de usuario final y tecnológicas, en el que se muestran para cada paso de la creación de un Data Warehouse, una lista de los principales vendedores y sus direcciones Web.
Webhousing
El uso de Internet como fuente de información hacia el exterior e interior (via intranets), crece constantemente, y la integración de una herramienta de Data Warehouse con Internet, se comenta en el apartado de Webhousing
Uso generalizado de Data Marts
Las peculiaridades de un proyecto Data Warehouse, y el enfoque progresivo de su construcción, hace que cada vez mas organizaciones realicen sus desarrollos mediante el uso de Data Marts integrados, tal y como comentabamos en el apartado Data Warehouse vs. Data Mart
Uso de tecnología OLAP
Este aspecto está comentado con amplitud en el apartado OLAP, ROLAP, MOLAP
3.- ASPECTOS TÉCNICOS EN EL PROCESO DE CREACIÓN Y EXPLOTACIÓN DEL DW
En este capítulo se pretende dar la orientación suficiente al comprador para la preparación del conjunto de especificaciones que definirán los requisitos que han de cumplir la Creación y Explotación de un Data Warehouse.
Se realiza en primer lugar un análisis de las necesidades del comprador, a continuación se recogen los factores relevantes a tener en cuenta en el proceso de adquisición y, finalmente, se describe cómo deben ser planteadas las especificaciones técnico - funcionales para la elaboración del Pliego de Prescripciones Técnicas, qué normas, estándares y cláusulas tipo pueden ser de aplicación, y cuál es el cuestionario técnico diseñado para normalizar las ofertas y facilitar su evaluación.
3.1.- ANÁLISIS DE LAS NECESIDADES DEL COMPRADOR
Incluimos aquí unos pasos que, tal y como se comentaban en la Fases de implantación de un Data Warehouse , son previos al inicio de un proyecto de este tipo.
En efecto, como punto de arranque de todo, es preciso "vender la idea" a los usuarios finales de un Data Warehouse. Esto es así, por ser una idea bastante novedosa y sobre la que pueden surgir recelos de su efectividad. Estos recelos se pueden eliminar comenzando por un pequeño módulo, del cual se valoren los beneficios posteriores, para iniciar progresivamente el desarrollo de nuevos módulos, cada uno con un coste unitario cada vez más reducido, pero sin embargo con unos beneficios distribuidos cada vez mayores por poder cada vez incluir más información. (Ver Data Warehouse vs. Data Mart) para comprobar un caso de este tipo.
El simple hecho de realizar un informe de necesidades previas en el que se enumeren la situación de los datos entre los diversos sistemas operacionales, puede ser un hecho decisivo para emprender un proyecto de este tipo. Muchas veces la información existente se encuentra tan poco normalizada, existen tantas discrepancias entre estos sistemas, que el abordar un Data Warehouse en el que se limpien estos datos y se normalicen pueden aportar un valor intangible: "la calidad y fiabilidad de la información".
La venta de esta idea no sólo se ha de realizar frente a la Dirección sino que es preciso realizarla a todos los niveles: a la Dirección, Gerencia e incluso al área de Desarrollo.
Tras esta venta de la idea, comienzan dos fases similares al análisis de requisitos del sistema (ARS según abreviaturas de la metodología METRICA): la definición de objetivos y requerimientos de información, en el que se analicen las necesidades del comprador.
Definición de los objetivos
En esta fase se definirá el equipo de proyecto que debe estar compuesto por representantes del departamento informático y de los departamentos usuarios del Data Warehouse además de la figura de jefe de proyecto.
Se definirá el alcance del sistema y cuales son las funciones que el Data Warehouse realizará como suministrador de información de negocio estratégica para la empresa. Se definirán así mismo, los parámetros que permitan evaluar el éxito del proyecto.
Definición de los requerimientos de información
Durante esta fase se mantendrán sucesivas entrevistas con los representantes del departamento usuario final y los representantes del departamento de informática. Se realizará el estudio de los sistemas de información existentes, que ayudaran a comprender las carencias actuales y futuras que deben ser resueltas en el diseño del Data Warehouse
Asimismo, en esta fase el equipo de proyecto debe ser capaz de validar el proceso de entrevistas y reforzar la orientación de negocio del proyecto. Al finalizar esta fase se obtendrá el documento de definición de requerimientos en el que se reflejarán no solo las necesidades de información de los usuarios, sino cual será la estrategia y arquitectura de implantación del Data Warehouse.
3.2.- FACTORES RELEVANTES EN EL PROCESO DE ADQUISICIÓN
En la definición del objeto del contrato y los requisitos inherentes al mismo, así como en la valoración y comparación de ofertas de los licitadores pueden intervenir muchos factores y de muy diversa índole.
Es de suma importancia que todos los factores relevantes que intervienen en el proceso de contratación queden debidamente recogidos en el pliego de prescripciones técnicas que regule el contrato. Así mismo, es conveniente que las soluciones ofertadas por los licitadores sean recogidas en los cuestionarios disponibles a tal efecto:
• De empresa
• Económicos
• Técnicos particulares
Se van a relacionar a continuación algunos de los factores que suelen tener mayor peso al seleccionar una herramienta de Data Warehouse. Sin embargo, debe tenerse en cuenta que la importancia de cada factor variará en función de cada caso particular, por lo que siempre será necesario identificar la importancia relativa de cada punto. Los puntos a contemplar son bastante similares a los contemplados en el apartado homónimo de los SGBD, que adaptaremos a la casuística particular de un Data Warehouse.
Pruebas en condiciones reales
Tal y como sucedía en los SGBD, el rendimiento real de un Data Warehouse es muy difícil de predecir mediante procedimientos teóricos. Por ello, de igual forma que en el SGBD, si se va a instalar un Data Warehouse que contendrá un gran volumen de datos o, si por cualquier otra razón, existen dudas sobre la capacidad del Data Warehouse de dar unas prestaciones adecuadas en las máquinas disponibles se debe exigir al suministrador una prueba anterior a la adquisición del Data Warehouse. Esta prueba debe realizarse en la propia instalación de destino.
La prueba se debería realizar en las condiciones más parecidas a las reales que se puedan conseguir. Para ello se deberá cargar el Data Warehouse con un volumen de datos adecuado y se deberán crear procesos de prueba similares a los más costosos de los que se vayan a desarrollar.
A diferencia de con los SGBD, no es preciso realizar la prueba en momentos de gran carga, por la diferente filosofía de un almacén de datos orientado al conocimiento, pero sí que será preciso la comprobación de la compatibilidad de la herramienta para los procesos de extracción y carga desde los diferentes sistemas operacionales (sistemas operativos, bases de datos, etc.) implicados .
Volumen y organización de los datos
Debe estar garantizado que el Data Warehouse es capaz de tratar el volumen de datos que se vaya a necesitar en la instalación. Para ello debe verificarse no sólo que el Data Warehouse puede manejar el volumen total de datos, sino que no existe ninguna limitación que impide organizarlo de la forma más conveniente.
No obstante, en este sentido y como factor común de un SGBD con un Data Warehouse, cabe reseñar que muchos problemas de rendimiento se deben más veces a un mal diseño del modelo de datos del Data Warehouse que a un problema de rendimiento de la herramienta en sí.
Dimensionamiento de la plataforma de instalación
De lo comentado en los dos puntos anteriores puede deducirse que existe la posibilidad de que sea necesario redimensionar la máquina en la que se instale el Data Warehouse, o mejor aun, disponer de una dedicada al Data Warehouse.
Es necesario que el suministrador detalle cual de las dos versiones está ofreciendo para cada una de las licencias que se compren y si alguna de ellas fuese una versión limitada, que especifique claramente cuales de las funcionalidades ofertadas no se encuentran presentes en la versión restringida.
Condiciones económicas y del soporte
Existen actualmente varios sistemas de cobro por el uso de Data Warehouse según el fabricante. Los más utilizados son facturar por:
• Cada máquina y/o tipo de máquina en la que se instale.
• Cada usuario que acceda al SGBD.
• Por tiempo de utilización (usualmente renovación anual).
• Por combinación de las anteriores.
Es imprescindible que el suministrador indique con toda claridad el método utilizado.
También debe explicitarse que, salvo indicación en contrario, todas las licencias son de versiones completas sin ninguna restricción respecto a las funcionalidades ofertadas.
También es conveniente pedir los precios de los productos adicionales que no se desee instalar en el momento pero que puedan ser interesantes en el futuro.
Otro factor importante es la duración de la garantía, período de tiempo durante el que el suministrador proporcionará soporte gratuito a sus productos y, también el precio del soporte en años sucesivos. Este último precio debe fijarse sobre variables presentes en el contrato no sobre futuros precios de lista del fabricante.
Otro factor que debe evaluarse es la calidad del soporte ofrecido. Este puede dividirse en un gran número de puntos cuya importancia variará en función de las necesidades del comprador. Entre ellos, se pueden citar:
• La inclusión o no de la instalación en el precio del producto.
• El tiempo máximo de entrega.
• La inclusión o no de prestaciones adicionales gratuitas como puede ser un cierto número de horas de formación.
• Capacitación y experiencia del personal que presta soporte técnico y consultoría.
• Calidad de la documentación, idioma en que está escrita, número de copias suministradas gratuitamente y precio de las copias adicionales.
• Capacidad técnica de la empresa y de la asistencia técnica que presta para lo que es recomendable pedir referencias a otros usuarios de la Administración de este tipo de productos.
3.3.- DISEÑO DEL PLIEGO DE PRESCRIPCIONES TÉCNICAS PARTICULARES
Debido a la no existencia de ninguna norma o estándar aplicable a un Data Warehouse, mas que estándares de facto, describimos a continuación cuestionarios técnicos de normalización y valoración de ofertas de SGBD.
Estos cuestionarios han de partir de unas especificaciones previas de:
Entorno Hardware:
Host: (Tipo Máquina, Sistema Operativo y Base de Datos Operacional)
Servidor de la aplicación de DW (Tipo Máquina, Nº procesadores, Memoria total y por procesador, Sistema Operativo, Capacidad de Disco)
Clientes (Tipo de Máquina, Memoria, Sistema Operativo, Capacidad de Disco)
Red local (Topología, Protocolos, Sofware de Cliente y Número de Usuarios soportados)
Entorno Software:
Gestor de Base de Datos para el Data Warehouse
Volumen estimado de la Base de Datos
A continuación y dependiendo del ámbito de aplicación del Data Warehouse describimos un cuestionario aplicado a la creación del Data Warehouse por un lado, por otro del Análisis de la Calidad del dato y la depuración, y por último de su Explotación.
3.3.1.- CUESTIONARIO PARA LA EXTRACCIÓN, MOVIMIENTO Y CARGA
Con carácter general y a fin de utilizar la información recopilada de cara a la contratación, es importante destacar que los datos recogidos en este cuestionario están dirigidos a obtener un resumen estructurado de la oferta y a demostrar la solvencia técnica o profesional de la empresa en aquellos casos en que no sea requerida la clasificación de la misma. Dicha información sólo servirá de base a la valoración cuando esté relacionada con lo expresado en la cláusula "Criterios de adjudicación del contrato", siendo, en el resto de los casos, de carácter meramente informativo.
Nota: (*) significa que hay que indicar "1" en caso afirmativo.
(**) significa que hay que repetir para cada sistema operativo ofertado.
Cuestión Respuesta Referencia a
oferta (Página)
------------------------------------------
ENTORNO OPERATIVO
- REQUERIMIENTOS LÓGICOS
. Especificar para cada uno de las paquetes software ofertados la o las posibles
plataformas (servidor central, servidor intermedio y cliente) donde podrían instalarse, detallando los requerimientos
físicos y lógicos asociados a cada alternativa, junto con los procesos que se ejecutarían
en cada una de las posibles plataformas [ ] [ ]
. Compatibilidad con Sistemas operativos (Enumerar) [ ] [ ]
. Compatibilidad con software de red [ ] [ ]
. Necesidad de software adicional [ ] [ ]
- REQUERIMIENTOS FÍSICOS
. Especificar detalladamente los requerimientos físicos mínimos
y recomendados, tales como memoria RAM, espacio libre en disco, procesadores, etc... [ ] [ ]
CARACTERÍSTICAS GENERALES
- FUENTES DE DATOS (ORIGEN) SOPORTADAS
. Permite extraer datos desde varias plataformas origen simultáneamente [ ] [ ]
. Indicar las distintas fuentes de datos operacionales a las que es posible acceder,
especificando en los casos que sea necesario las últimas versiones certificadas. [ ] [ ]
Ficheros planos [ ] [ ]
Acceso a bases de datos [ ] [ ]
Otras fuentes operacionales [ ] [ ]
Consideraciones a tener en cuenta [ ] [ ]
- BASES DE DATOS DESTINO SOPORTADAS
. Permite cargar datos en varias plataformas destino simultáneamente [ ] [ ]
.Gestores de bases de datos destino soportados, especificando las
últimas versiones certificadas
- FUNCIONALIDADES
. Enumerar las funcionalidades de la o las herramientas propuestas:
Permite manejar (leer/escribir) cadenas de caracteres de longitud variable
No limita el número de dígitos de los formatos numéricos
Es posible aplicar reglas de transformación a los números con
formato en coma flotante
Otras funcionalidades (especificar) [ ] [ ]
- TRATAMIENTO INTERMEDIO DE LOS DATOS RECUPERADOS
.Realiza un almacenamiento intermedio de los datos recuperados a partir de
los sistemas operacionales
. Especificar
Almacenamiento intermetdio físico de los datos
Fichero plano
Memoria
BBDD propia
BBDD externa
Otros
Localización
Puesto cliente
Servidor intermedio
Servidor central
Otros
Técnicas aplicadas sobre los datos intermedios
Compresión
Encriptación
Otros
Explicar el consumo de recursos asociado a este almacenamiento intermedio de los datos [ ] [ ]
- BASE DE DATOS COMO FUENTE DE DATOS OPERACIONALES
. Conocimiento de la estructura de la base de datos
Requiere algún software adicional que permita el acceso a las BBDD
para tal funcionalidad [ ] [ ]
. Detección a captura de modificaciones en la estructura de las bases
de datos
Requiere algún software adicional que permita el acceso a las BBDD
para tal funcionalidad
Explicar con detalle los mecanismos utilizados para la detección de
cambios en la estructura de las bases de datos
Es posible automatizar la detección de dichos cambios
Es posible automatizar la captura de los cambios realizados en la estructura
de las bases de datos
Indicar si la herramienta es capaz de detectar automáticamente las
transformaciones a las que afectan las modificaciones realizadas
Es necesario parar las bases de datos para realizar el proceso de captura
de cambios
Observaciones [ ] [ ]
. Acceso a las bases de datos
Requiere algún software adicional que permita el acceso a las BBDD
para tal funcionalidad
Acceden directamente a la base de datos los programas generados por la herramienta
Indicar cómo se obtienen los ficheros de descarga de los datos
Mediante una utilidad de la propia herramienta
A través de una utilidad de la BBDD
Mediante un desarrollo a medida
Otros (especificar)) [ ] [ ]
. Detección y captura de las modificaciones en los datos
Requiere algún software adicional que permita el acceso a las BBDD
para tal funcionalidad
Es posible automatizar la detección de estas modificaciones
Explicar detalladamente los mecanismos utilizados para la captura de dichas
modificaciones
Es posible automatizar la captura de dichas modificaciones
Indicar si la herramienta es capaz de detectar automáticamente las
transformaciones a las que afectan las modificaciones realizadas.
Es necesario parar las bases de datos para realizar el proceso de captura de las modificaciones realizadas sobre
los datos (Observaciones) [ ] [ ]
- RECOMENDACIONES PRÁCTICAS
. Enumerar las principales recomendaciones prácticas para asegurar una
plena explotación de la potencialidad de los paquetes software ofertados
. Enumerar y justificar brevemente los puntos fuertes tanto de la arquitectura funcional propuesta como de
las herramientas ofertadas [ ] [ ]
FUNCIONALIDAD
- FACILIDAD DE USO
. Especificar los idiomas soportados en cada una de las siguientes áreas:
Aplicación
Ayuda on-line
Manuales de ayuda
Soporte
. Soporta alfabetización internacional
. Dispone de ayuda on-line
. Es posible la presentación preliminar de la documentación
generada antes de imprimirla
. Posee un interfaz gráfico que permita tener una visión global
de las tablas incluidas en los sistemas operacionales y en el Data Warehouse
. Especificar detalladamente los diferentes perfiles de usuario contemplados
para cada una de las herramientas ofertadas, así como la curva de aprendizaje (en horas) para cada uno de
ellos.
. Posee un Editor de Diagramas que facilite las tareas de diseño de
los flujos de datos y de las transformaciones a aplicar [ ] [ ]
- PROCESOS DE EXTRACCIÓN Y TRANSFORMACIÓN
. Indicar el paquete software ofertado que incluye esta funcionalidad
y la plataforma o plataformas donde ha de instalarse
. Requiere algún software adicional que complemente esta funcionalidad
. Es posible automatizar completamente los procesos de extracción y
transformación
. Se puede integrar con el planificador externo de tareas
. Explicar detalladamente el mecanismo de acceso a las estructuras de
las bases de datos, tanto operacionales como del Data Warehouse
. Explicar el mecanismo de extracción de los datos desde los sistemas
operacionales detallando concretamente de dónde los extraen y si se utilizan ficheros secuenciales intermedios
. Detallar los procedimientos de depuración incorporados
. Indicar las funciones de transformación más importantes incluidas
en el producto:
Importación desde ficheros planos de reglas de transformación
previamente definidas Validación y sustitución de los campos de una tabla en base a los campos de
otras tablas
Cálculos aritméticos propios de sumarización de la información
Conversión de formatos de fecha
Definición de reglas de negocio
Llamadas a subrutinas externas
Otras
. Es posible definir reglas de transformación generales que se puedan
parametrizar mediante variables para casos concretos
. En caso de exclusión de datos en base a reglas de transformación,
indicar si se pueden almacenar
. Indicar:
Almacenamiento físico de los datos excluidos
Fichero plano
Base de Datos propia
Base de Datos externa
Otros
Localización física de los datos excluidos
Puesto cliente
Servidor intermedio
Servidor central
Otros [ ] [ ]
- CARACTERÍSTICAS DE LOS PROGRAMAS GENERADOS
. Especificar el lenguaje utilizado en la generación de código
para las distintas fuentes soportadas
. Indicar si genera también los JCL o scripts de compilación y ejecución
. Es posible modificar los esqueletos de los programas a generar
. Enumerar los tipos de programas generados, con una breve descripción de los mismos, y las plataformas
(destino u origen) donde deben ser ejecutados [ ] [ ]
- GENERACIÓN DE DOCUMENTACIÓN
. Posee un Generador de Informes que automatice la generación de la
documentación sobre los procesos de extracción y transformación
. Indicar el paquete software ofertado que incluye esta funcionalidad
y la plataforma o plataformas donde ha de instalarse
. Requiere algún software adicional que complemente esta funcionalidad
. Describir la información incluida en dicha documentación
Origen de los datos
Correspondencias
Transformaciones
Reglas de negocio aplicadas
Otras (especificar))
. Soporta el versionado de la documentación generada
. Se proporciona algún software que facilite el mantenimiento
y versionado de la documentación [ ] [ ]
- CARACTERÍSTICAS DEL ENTORNO FUNCIONAL
. Especificar el software mínimo que es necesario tener instalado
en las diferentes plataformas
. La transferencia de los programas generados desde el puesto cliente hasta los sistemas operacionales y el Data
Warehouse es automática
. Son necesarios otros requisitos software adicionales, como por ejemplo compiladores (Observaciones) [ ] [ ]
- DETECCIÓN Y CAPTURA DE MODIFICACIONES
. Indicar el paquete software ofertado que incluye esta funcionalidad
y la plataforma o plataformas donde ha de instalarse
. Requiere algún software adicional que complemente esta funcionalidad
. Explicar con detalle los mecanismos utilizados para la detección de cambios en la estructura de las
bases de datos del Data Warehouse
. Es posible automatizar la detección de dichos cambios
. Explicar detalladamente los mecanismos utilizados para la captura de dichos cambios
. Es posible automatizar la captura de los cambios realizados en la estructura de las bases de datos del Data Warehouse
. Indicar si la herramienta es capaz de detectar automáticamente las transformaciones a las que afectan
los cambios realizados
. Es necesario parar las bases de datos del Data Warehouse para realizar el proceso de captura de cambios (Observaciones) [ ] [ ]
- DETECCIÓN Y CAPTURA DE MODIFICACIONES EN LA ESTRUCTURA DE LAS BASES
DE DATOS DE DATA WAREHOUSE
. Indicar el paquete software ofertado que incluye esta funcionalidad y
la plataforma o plataformas donde ha de instalarse
. Requiere algún software adicional que complemente esta funcionalidad
. Explicar con detalle los mecanismos utilizados para la detección de modificaciones en los datos de
los sistemas operacionales fuente, enumerando las principales consideraciones a tener en cuenta
. Es posible automatizar la detección de estas modificaciones
. Explicar detalladamente los mecanismos utilizados para la captura de dichas modificaciones
. Es posible automatizar la captura de dichas modificaciones
. Indicar si la herramienta es capaz de detectar automáticamente las transformaciones a las que afectan
las modificaciones realizadas
. Es necesario parar las bases de datos operacionales para realizar el proceso de captura de las modificaciones
realizadas sobre los datos (Observaciones) [ ] [ ]
. Detección y captura de modificaciones en los datos de los
sistemas operacionales.
Indicar el paquete software ofertado que incluye esta funcionalidad y la plataforma
o plataformas donde ha de instalarse.
Requiere algún software adicional que complemente esta funcionalidad [ ] [ ]
Explicar con detalle los mecanismos utilizados para la detección de modificaciones
en los datos de los sistemas operacionales fuente, enumerando las principales consideraciones a tener en cuenta.
Posibilidad de automatizar la detección de estas modificaciones [ ] [ ]
Explicar detalladamente los mecanismos utilizados para la captura de dichas modificaciones.
Posibilidad de automatizar la captura de dichas modificaciones [ ] [ ]
Herramienta es capaz de detectar automáticamente las transformaciones
a las que afectan las modificaciones realizadas [ ] [ ]
Es necesario parar las bases de datos operacionales para realizar el proceso
de captura de las modificaciones realizadas sobre los datos [ ] [ ]
- MOVIMIENTO Y CARGA
. Indicar el paquete software ofertado que incluye esta funcionalidad
y la plataforma o plataformas donde ha de instalarse
. Requiere algún software adicional que complemente esta funcionalidad [ ] [ ]
. Explicar detalladamente los mecanismos de movimiento y carga de
los datos en las bases de datos destino del Data
Warehouse, enumerando las principales consideraciones
a tener en cuenta. En este sentido indicar si la transferencia se realiza
directamente o a través de un servidor intermedio, en este último caso detallar requerimientos físicos y lógicos de dicho servidor intermedio
. Transferencia de datos desde los Sistemas
Operacionales al Data Warehouse automática [ ] [ ]
. Control de las filas que sean rechazadas en el proceso de carga [ ] [ ]
Indicar qué ocurre con el proceso de carga
. Para el caso de los datos rechazados indicar
Si se especifica el motivo del rechazo [ ] [ ]
Almacenamiento físico de los datos rechazados
Fichero plano [ ] [ ]
Base de Datos propia [ ] [ ]
Base de Datos externa (especificar los gestores soportados en observaciones) [ ] [ ]
Otros (especificar) [ ] [ ]
Localización física de los datos rechazados
Puesto cliente [ ] [ ]
Servidor intermedio [ ] [ ]
Servidor central [ ] [ ]
Otros (especificar) [ ] [ ]
Explicar el mecanismo de tratamiento de los datos rechazados
. Indicar las alternativas para realizar la carga final del Data Warehouse
A través de la propia herramienta [ ] [ ]
A través de programas externos [ ] [ ]
Utilidades propias del gestor [ ] [ ]
Otras (especificar) [ ] [ ]
. Incorpora la herramienta algún proceso de comunicación automática de la disponibilidad
de los datos en el Data Warehouse a los usuarios finales [ ] [ ]
. En caso afirmativo indicar
El paquete software ofertado que incluye esta funcionalidad.
Requiere algún software adicional que complemente esta funcionalidad [ ] [ ]
El medio de comunicación automático utilizado
Correo electrónico [ ] [ ]
Otros (especificar) [ ] [ ]
En caso de poder utilizar correo electrónico, indicar los paquetes del
mercado perfectamente integrables con la herramienta propuesta
- CARGA INCREMENTAL
. Explicar detalladamente el mecanismo de carga incremental de los
datos en las bases de datos destino del Data Warehouse, especificando si se realiza en base a un chequeo de los
ficheros log de los sistemas operacionales, o en base al cruce de los fichero de carga, etc.
. Enumerar las principales diferencias respecto al proceso de carga
masiva y las consideraciones a tener en cuenta
- FUNCIONALIDADES ADICIONALES
. Análisis y control de la calidad
Incorpora funcionalidades para realizar un análisis y control de la calidad
de los datos [ ] [ ]
Especificar el paquete software ofertado que incluye esta funcionalidad y la
plataforma o plataformas donde ha de instalarse.
Requiere algún software adicional que complemente esta funcionalidad [ ] [ ]
. Limpieza
Incorpora funcionalidades para llevar a cabo una limpieza de los datos [ ] [ ]
Especificar el paquete software ofertado que incluye esta funcionalidad y la
plataforma o plataformas donde ha de instalarse
Requiere algún software adicional que complemente esta funcionalidad [ ] [ ]
Explicar detalladamente los mecanismos de limpieza proporcionados, indicando
la plataforma donde se ejecutan estos
- GESTIÓN DEL METADATA
. Procedimientos de creación, mantenimiento y consulta
Indicar cómo se almacenan físicamente los metadatos generados
Fichero plano [ ] [ ]
Base de Datos propia [ ] [ ]
Base de Datos externa (especificar los gestores soportados en observaciones) [ ] [ ]
Otros (especificar) [ ] [ ]
Dónde se almacenan dichos metadatos
Puesto cliente [ ] [ ]
Servidor intermedio [ ] [ ]
Servidor central del Data Warehouse [ ] [ ]
Servidor central operacional [ ] [ ]
La creación y actualización de los metadatos es completamente automática [ ] [ ]
Es posible definir plantillas para los metadatos que se desean generar [ ] [ ]
Todos los datos y reglas de transformación que intervienen en la creación
y mantenimiento del Data Warehouse se almacenan como metadatos [ ] [ ]
Dispone de alguna herramienta específica para el mantenimiento y consulta
de los metadatos asociados al Data Warehouse, permitiendo la navegación dentro del directorio de metadatos [ ] [ ]
En caso afirmativo indicar
* El nombre del paquete software ofertado que incluye tal funcionalidad
* La plataformas o plataformas donde ha de instalarse
* Si requiere algún software adicional para completar tal funcionalidad
* Describir el mecanismo de integración con las otras herramientas
ofertadas
Es posible crear vistas adaptadas de los metadatos para diferentes proyectos [ ] [ ]
Utiliza un formato propio de metadatos [ ] [ ]
Indicar la información contenida en los metadatos
Descripción de los esquemas de datos origen y destino [ ] [ ]
Reglas de transformación y validación de datos [ ] [ ]
Variables de conversión [ ] [ ]
Mappings origen-destino [ ] [ ]
Opciones de recuperación de datos [ ] [ ]
Opciones de manejo de excepciones [ ] [ ]
Secuencia de acciones a realizar en las conversiones (queries, sorts y merges) [ ] [ ]
Especificaciones detalladas de las conversiones [ ] [ ]
Otras (especificar) [ ] [ ]
Indicar el grado de seguridad en el acceso a los metadatos.
No incorpora funciones de seguridad (utiliza la dada por el gestor) [ ] [ ]
Sí incorpora funciones de seguridad [ ] [ ]
Explicar en detalle
Dispone de alguna herramienta específica que permita el acceso vía
Web a los metadatos asociados al Data Warehouse [ ] [ ]
En caso afirmativo especificar qué navegadores son compatibles
Microsoft Internet Explorer [ ] [ ]
Netscape [ ] [ ]
En caso afirmativo indicar
El nombre del paquete software ofertado que incluye tal funcionalidad y dónde
ha de instalarse, detallando los requerimientos lógicos y físicos asociados
Requiere algún software adicional para completar tal funcionalidad, además
del propio navegador [ ] [ ]
En base a la pregunta anterior indicar las funcionalidades disponibles vía
Web y las principales diferencias respecto a un acceso cliente/servidor directo
. Integración de los metadatos
Es posible que los metadatos generados por dicha herramienta de extracción
puedan ser interpretados e integrados con los metadatos generados por las herramientas de acceso al Data Warehouse [ ] [ ]
En base a la pregunta anterior explicar detalladamente los mecanismos de integración
utilizados, enumerando las consideraciones a tener en cuenta
Dicha integración de los metadatos completamente automática [ ] [ ]
Posibilidad de la integración entre metadatos de negocio y técnicos
provenientes de múltiples fuentes [ ] [ ]
En caso afirmativo explicar detalladamente los mecanismos de integración
utilizados, así como el grado de automatización de dicha integración
. Control de versiones y documentación del metadato
Mantiene un histórico sobre los cambios realizados que permita realizar
un control de versiones [ ] [ ]
Está automatizada la generación de documentación asociada
con los metadatos [ ] [ ]
En caso afirmativo indicar si es posible imprimir dicha documentación.
No [ ] [ ]
Sí, pero sin presentación preliminar [ ] [ ]
Sí, con presentación preliminar [ ] [ ]
. Importación y exportación de metadatos
Permite capturar los metadatos desde fuentes externas [ ] [ ]
En caso afirmativo indicar las fuentes soportadas
Procesadores de texto [ ] [ ]
Amipro [ ] [ ]
Word [ ] [ ]
WordPerfect [ ] [ ]
Otros (especificar) [ ] [ ]
Bases de datos (especificar) [ ] [ ]
Hojas de cálculo [ ] [ ]
Lotus 123 [ ] [ ]
Excel [ ] [ ]
Otros (especificar) [ ] [ ]
Ficheros planos [ ] [ ]
Otras (especificar) [ ] [ ]
Posibilidad de exportar los metadatos [ ] [ ]
En caso afirmativo indicar los formatos soportados.
CDIF (formato estándar de intercambio de datos) [ ] [ ]
Otros (especificar) [ ] [ ]
ADMINISTRACIÓN
- GESTIÓN DE RECURSOS
. Administración centralizada
Posee una herramienta de administración y control centralizada
No [ ] [ ]
Sí, pero sin interfaz gráfica [ ] [ ]
Sí, con interfaz gráfica [ ] [ ]
Indicar el paquete software ofertado que incluye esta funcionalidad
Indicar las plataformas donde es necesario instalar el software de esta herramienta
de administración
Puesto cliente [ ] [ ]
Servidor intermedio [ ] [ ]
Servidor central [ ] [ ]
Requiere algún software adicional que complemente dicha funcionalidad [ ] [ ]
Indicar las funcionalidades que incorpora esta herramienta
Gestión de la seguridad [ ] [ ]
Monitorización de tareas en curso [ ] [ ]
Realización de pruebas de funcionalidad a volumen pequeño [ ] [ ]
Otras (especificar) [ ] [ ]
Puede ser utilizada esta herramienta de administración desde varios puestos
No [ ] [ ]
Sí, pero no simultáneamente [ ] [ ]
Sí, simultáneamente [ ] [ ]
. Estadísticas y logs de los procesos de extracción,
transformación, movimiento y carga
Elabora automáticamente estadísticas y logs de dichos procesos [ ] [ ]
En caso afirmativo, especificar la información incluida en dichos logs
y estadísticas
Total de registros leídos [ ] [ ]
Total de registros cargados [ ] [ ]
Tiempos de ejecución [ ] [ ]
Número de registros a los que se aplica una determinada regla de transformación [ ] [ ]
Número de registros que cumplen cada una de las condiciones de una regla
de transformación [ ] [ ]
Otras (especificar) [ ] [ ]
Indicar el almacenamiento físico de dicha información
Fichero plano [ ] [ ]
Base de Datos propia [ ] [ ]
Base de Datos externa (especificar los gestores soportados en observaciones) [ ] [ ]
Otros (especificar) [ ] [ ]
Almacen de dicha información
Puesto cliente [ ] [ ]
Servidor intermedio [ ] [ ]
Servidor central [ ] [ ]
Indicar los tiempos estimados de extracción y transformación, en
base a volúmenes de información
Indicar los tiempos estimados de carga, en base a volúmenes de información
- SEGURIDAD
. Indicar los niveles de seguridad soportados
Por usuario [ ] [ ]
Por grupo de usuario [ ] [ ]
Otros (especificar) [ ] [ ]
. En qué plataforma se gestiona la seguridad
Puesto cliente [ ] [ ]
Servidor intermedio [ ] [ ]
Servidor central [ ] [ ]
. Se realiza una identificación del usuario a la hora de acceder al sistema [ ] [ ]
. Almacenamiento físico de la password
Fichero plano [ ] [ ]
Base de datos propia [ ] [ ]
Base de datos externa (especificar los gestores soportados en observaciones) [ ] [ ]
Otros (especificar) [ ] [ ]
. Localización física de la password
Puesto cliente [ ] [ ]
Servidor intermedio [ ] [ ]
Servidor central [ ] [ ]
Otros (especificar) [ ] [ ]
. Explicar en detalle los mecanismos de seguridad que incorporan la
o las herramientas ofertadas
- PROCEDIMIENTO DE PLANIFICACIÓN Y MANTENIMIENTO
. Posible construir procedimientos que automaticen las tareas de planificación
y mantenimiento
No [ ] [ ]
Sí, pero no dispone de un interfaz gráfico que facilite la programación
dedichas tareas. [ ] [ ]
Sí, con un interfaz gráfico que facilite la programación
de dichas tareas [ ] [ ]
. En caso afirmativo, indicar las posibles bases de dicha planificación
Eventos [ ] [ ]
Ventanas de tiempo [ ] [ ]
Otras (especificar) [ ] [ ]
. Indicar el paquete software ofertado que incluye esta funcionalidad y la plataforma
o plataformas donde ha de instalarse
. Requiere algún software adicional que complemente dicha funcionalidad [ ] [ ]
ACLARACIONES GENERALES
REFERENCIAS
3.3.2.- CUESTIONARIO DE ANÁLISIS DE CALIDAD
Con carácter general y a fin de utilizar la información recopilada de cara a la contratación, es importante destacar que los datos recogidos en este cuestionario están dirigidos a obtener un resumen estructurado de la oferta y a demostrar la solvencia técnica o profesional de la empresa en aquellos casos en que no sea requerida la clasificación de la misma. Dicha información sólo servirá de base a la valoración cuando esté relacionada con lo expresado en la cláusula "Criterios de adjudicación del contrato", siendo, en el resto de los casos, de carácter meramente informativo.
Nota: (*) significa que hay que indicar "1" en caso afirmativo.
(**) significa que hay que repetir para cada sistema operativo ofertado.
Cuestión Respuesta Referencia a oferta (Página)
------------------------------------------ ---------- ----------
ENTORNO OPERATIVO
- REQUERIMIENTOS LÓGICOS
. Especificar para cada uno de las paquetes software ofertados la o las posibles plataformas (servidor central,
servidor intermedio y cliente) donde podrían instalarse, detallando los requerimientos físicos y
lógicos asociados a cada alternativa, junto con los procesos que se ejecutarían en cada una de las
posibles plataformas. [ ] [ ]
. Compatibilidad con Sistemas operativos. (Enumerar) [ ] [ ]
. Compatibilidad con software de red [ ] [ ]
. Necesidad de software adicional. (Enumerar) [ ] [ ]
- REQUERIMIENTOS FÍSICOS
. Memoria RAM Mínima requerida [ ] [ ]
. Memoria RAM Recomendada [ ] [ ]
. Espacio libre de disco Mínimo requerido [ ] [ ]
. Espacio libre de disco Recomendado [ ] [ ]
. Procesador mínimo requerido [ ] [ ]
. Porcesador recomendado [ ] [ ]
. Observaciones
CARACTERISTICAS GENERALES [ ] [ ]
- ORIGEN DE LOS DATOS A ANALIZAR
. Indicar si se analiza el total de los datos o bien sólo una muestra
significativa de los mismos
Todos los datos [ ] [ ]
Muestra
Ambos [ ] [ ]
. Observaciones
. Indicar y explicar detalladamente el mecanismo de obtención de los datos
a analizar.
Acceso directo a las fuentes de datos y análisis de la calidad de los
datos [ ] [ ]
Acceso directo a las fuentes de datos, extracción de los datos a analizar
y almacenamiento de los mismos para su análisis. [ ] [ ]
Análisis de la calidad de los datos que otras herramientas han extraído
de las fuentes de datos. [ ] [ ]
. Observaciones
. Explicación detallada del mecanismo seguido
. En el caso de acceder directamente a las fuentes de datos indicar
Si es posible analizar la calidad de los datos de varias fuentes simultáneamente [ ] [ ]
Observaciones
Las fuentes de datos a las que es posible acceder, especificando en los casos
en que sea necesario las últimas versiones certificadas
Ficheros planos [ ] [ ]
Bases de datos (especificar) [ ] [ ]
Otras fuentes de datos (especificar) [ ] [ ]
Observaciones
. En el caso de extraer los datos a analizar desde las fuentes soportadas y almacenarlos
para su análisis, indicar
Almacenamiento físico de los datos analizar
Fichero plano [ ] [ ]
Memoria [ ] [ ]
Base de Datos propia [ ] [ ]
Base de Datos externa (especificar los gestores soportados en observaciones) [ ] [ ]
Otros (especificar) [ ] [ ]
Observaciones
Localización física de los datos
Puesto cliente [ ] [ ]
Servidor intermedio [ ] [ ]
Servidor central [ ] [ ]
Otros (especificar) [ ] [ ]
Observaciones
Técnicas aplicadas sobre los datos intermedios
Compresión [ ] [ ]
Encriptación [ ] [ ]
Otros (especificar) [ ] [ ]
En caso de aplicar compresión, indicar la relación de compresión
Observaciones
En base a las preguntas anteriores, explicar en detalle el consumo de recursos
asociado a este almacenamiento intermedio de los datos.
. En el caso de analizar los datos que otras herramientas han extraído
de las fuentes de datos, especificar de qué herramientas se trata. así como sus requerimientos lógicos
y físicos y la plataforma o plataformas donde han de instalarse.
- ELECCION Y TRATAMIENTO DE LAS MUESTRAS
. Describir el mecanismo de elección de la muestra, para asegurar la aleatoriedad
de la misma
Lo fija la herramienta sin intervención del usuario [ ] [ ]
El usuario selecciona un criterio de entre los posibles que proporciona la herramienta [ ] [ ]
El usuario puede confeccionar los criterios de elección de la muestra
a medida [ ] [ ]
Otros (especificar) [ ] [ ]
Describir detalladamente el mecanismo seguido
Observaciones
. Indicar el almacenamiento físico de la muestra de datos
Fichero plano [ ] [ ]
Memoria [ ] [ ]
Base de Datos propia [ ] [ ]
Base de Datos externa (especificar los gestores soportados en observaciones) [ ] [ ]
Otros (especificar) [ ] [ ]
Observaciones
. Indicar la localización física de la muestra de datos
Puesto cliente [ ] [ ]
Servidor intermedio [ ] [ ]
Servidor central [ ] [ ]
Otros (especificar) [ ] [ ]
Observaciones
. Porcentaje que supone la muestra sobre el volumen total de datos
Observaciones
. Técnicas aplicadas sobre la muestra de datos
Compresión [ ] [ ]
Encriptación [ ] [ ]
Otras (especificar) [ ] [ ]
En caso de aplicar compresión, indicar la relación de compresión.............................
Observaciones
- MECANISMOS DE ANALISIS DE LA CALIDAD Y FUNCIONALIDADES
. Explicar detalladamente el mecanismo de análisis de calidad utilizado
y las funcionalidades disponibles
. Indicar los niveles de análisis de calidad disponibles
A nivel de campo [ ] [ ]
A nivel de grupo de campos [ ] [ ]
A nivel de registros [ ] [ ]
Otros (especificar) [ ] [ ]
Observaciones
. Indicar la plataforma o plataformas donde se ejecutan los procesos de análisis
de calidad de los datos
Puesto cliente [ ] [ ]
Servidor intermedio [ ] [ ]
Servidor central del Data Warehouse [ ] [ ]
Servidor central operacional [ ] [ ]
Otros (especificar) [ ] [ ]
Observaciones
. Indicar las métricas que proporciona la herramienta por defecto para
cuantificar la calidad de los datos
Validación de formatos [ ] [ ]
Ausencia de información en campos obligatorios [ ] [ ]
Cardinalidad de las variables [ ] [ ]
Comprobación de reglas de integridad: [ ] [ ]
Entre campos del mismo fichero [ ] [ ]
Entre campos de distintos ficheros [ ] [ ]
Rango de valores [ ] [ ]
Comprobación cruzada de valores contra una tabla de referencia [ ] [ ]
Validación de fechas [ ] [ ]
Rango de fechas [ ] [ ]
Otras (especificar): [ ] [ ]
Observaciones
. Posibilidad de utilizar "métricas" definidas por el usuario
para cuantificar la calidad de los datos
No [ ] [ ]
Sí, pero no posee un asistente que facilita la definición de dichas
métricas [ ] [ ]
Sí, y posee un asistente que facilita la definición de dichas métricas [ ] [ ]
Observaciones. Describir el mecanismo de definición de métricas
utilizado [ ] [ ]
- LIMITACIONES
. Existencia de alguna limitación interna de la herramienta en cuanto
al volumen máximo de información que se puede analizar
Sí , limitado por número de registros [ ] [ ]
Sí , limitado por volumen de información [ ] [ ]
No [ ] [ ]
En caso afirmativo, especificar el límite definido
Observaciones
- RECOMENDACIONES PRACTICAS
. Enumerar las principales recomendaciones prácticas para asegurar una
plena explotación de la potencialidad de los paquetes software ofertados.
. Enumerar y justificar brevemente los puntos fuertes tanto de la arquitectura
funcional propuesta como de las herramientas ofertadas.
FUNCIONALIDAD
- FACILIDAD DE USO
. Especificar los idiomas soportados en cada una de las siguientes áreas
A nivel de aplicación
Español [ ] [ ]
Inglés [ ] [ ]
Otros (especificar) [ ] [ ]
A nivel de ayuda on-line
Español [ ] [ ]
Inglés [ ] [ ]
Otros (especificar) [ ] [ ]
A nivel de manuales de ayuda
Español [ ] [ ]
Inglés [ ] [ ]
Otros (especificar) [ ] [ ]
A nivel de soporte
Español [ ] [ ]
Inglés [ ] [ ]
Otros (especificar) [ ] [ ]
. Incluye los caracteres exclusivos del español: Ñ, ñ y
vocales acentuadas [ ] [ ]
. Interfaz gráfico [ ] [ ]
. Ayuda on-line [ ] [ ]
. Presentación preliminar de la documentación antes
de la impresión [ ] [ ]
. Observaciones
. Especificar detalladamente los diferentes perfiles de usuario contemplados
para cada una de las herramientas ofertadas, así como la curva de aprendizaje (en horas)para cada uno de
ellos.
- ACCESO A LAS FUENTES DE DATOS
. Conocimiento de la estructura de las bases
de datos
Requerimiento de algún software adicional que permita conocer la estructura
de las bases de datos [ ] [ ]
En caso afirmativo indicar la plataforma o plataformas donde ha de instalarse
dicha herramienta
Explicar detalladamente el mecanismo que utiliza la herramienta para conocer
la estructura de las bases de datos
. Detección y captura de modificaciones en la estructura de
las bases de datos
Requiere algún software adicional que permita detectar y capturar las
modificaciones hechas en la estructura de las bases de datos [ ] [ ]
Explicar con detalle los mecanismos utilizados para la detección de cambios
en la estructura de las bases de datos.
Posibilidad de automatizar la detección de dichos cambios [ ] [ ]
Explicar detalladamente los mecanismos utilizados para la captura de dichos cambios
Posibilidad de automatizar la captura de los cambios realizados en la estructura
de las bases de datos [ ] [ ]
Es necesario parar las bases de datos para realizar el proceso de captura de
cambios [ ] [ ]
. Acceso a las bases de datos
Requiere algún software adicional que permita el acceso a las bases de
datos [ ] [ ]
Accede directamente a la base de datos [ ] [ ]
En caso afirmativo describir el mecanismo de acceso seguido
En caso de no acceder directamente a la base de datos indicar cómo se
obtienen los ficheros de datos
Mediante una utilidad de la propia herramienta [ ] [ ]
A través de una utilidad del gestor [ ] [ ]
Mediante un desarrollo a medida. [ ] [ ]
Otros (especificar) [ ] [ ]
- PROCEDIMIENTOS DE ANALISIS DE CALIDAD
. Indicar el paquete software ofertado que incluye esta funcionalidad
y la plataforma o plataformas donde ha de instalarse
. Requiere algún software adicional que complemente esta funcionalidad [ ] [ ]
. Es posible automatizar completamente los procesos de análisis
de calidad [ ] [ ]
. Es posible mantener un histórico sobre evolución temporal
de la calidad de los datos [ ] [ ]
. Formatos soportados para la exportación de los resultados
obtenidos
Hojas de cálculo [ ] [ ]
Lotus 123 [ ] [ ]
Excel [ ] [ ]
Otras (especificar) [ ] [ ]
Procesadores de texto [ ] [ ]
Amipro [ ] [ ]
WordPerfect [ ] [ ]
Word [ ] [ ]
Otros (especificar) [ ] [ ]
Herramientas gráficas [ ] [ ]
FreeLance [ ] [ ]
PowerPoint [ ] [ ]
Otros (especificar) [ ] [ ]
Bases de datos (especificar) [ ] [ ]
Ficheros Planos [ ] [ ]
Otros (especificar) [ ] [ ]
. Adjuntar como anexo un ejemplo, lo más completo posible,
que contenga la información sobre un análisis
de calidad, efectuado con la herramienta propuesta
- GENERACION DE DOCUMENTACION
. Posee un Generador de Informes que permita la generación
de la documentación sobre los resultados
obtenidos
No [ ] [ ]
Sí, pero bajo la petición del usuario [ ] [ ]
Sí, automáticamente [ ] [ ]
. Indicar el paquete software ofertado que incluye esta funcionalidad
y la plataforma o plataformas donde ha de instalarse
. Requiere algún software adicional que complemente esta funcionalidad [ ] [ ]
. Describir la información incluida en dicha documentación
Origen de los datos [ ] [ ]
Posibles correspondencias entre datos [ ] [ ]
Métricas aplicadas [ ] [ ]
Otras (especificar) [ ] [ ]
. Soporta el versionado de la documentación generada [ ] [ ]
. Se proporciona algún software que facilite el mantenimiento
y versionado de la documentación [ ] [ ]
- CARACTERISTICAS DEL ENTORNO FUNCIONAL
. Especificar el software mínimo que es necesario tener instalado
en las diferentes plataformas
. Son necesarios otros requisitos software adicionales [ ] [ ]
- FUNCIONALIDADES ADICIONALES
. Limpieza de datos
Incorpora alguna funcionalidad que permita la limpieza de datos [ ] [ ]
Especificar el paquete software ofertado que incluye esta funcionalidad y la
plataforma o plataformas donde ha de instalarse
Requiere algún software adicional que complemente esta funcionalidad [ ] [ ]
Explicar detalladamente los mecanismos de limpieza proporcionados, indicando
la plataforma donde se ejecutan estos
. Otras funcionalidades
Incorpora otras funcionalidades (enumerarlas) [ ] [ ]
Especificar el paquete o paquetes software ofertados que incluyen estas funcionalidades
y la plataforma o plataformas donde ha de instalarse
Requiere algún software adicional que complemente estas funcionalidades [ ] [ ]
Explicar detalladamente los mecanismos asociados a dichas funcionalidades, indicando
la plataforma donde se ejecutan estos
- GESTION DE LOS METADATOS DE CALIDAD
. Se generan metadatos sobre la calidad de los datos [ ] [ ]
. Procedimientos de creación, mantenimiento y consulta
Indicar cómo se almacenan físicamente los metadatos generados.
Fichero plano [ ] [ ]
Base de Datos propia [ ] [ ]
Base de Datos externa (especificar los gestores soportados en observaciones) [ ] [ ]
Otros (especificar) [ ] [ ]
Dónde se almacenan dichos metadatos
Puesto cliente [ ] [ ]
Servidor intermedio [ ] [ ]
Servidor central [ ] [ ]
La creación y actualización de los metadatos es completamente automática [ ] [ ]
En caso negativo indicar qué metadatos se alimentan automáticamente
y cuáles no, especificando en este último caso el mecanismo seguido
Es posible definir plantillas para los metadatos que se desean generar [ ] [ ]
Dispone de alguna herramienta específica para el mantenimiento y consulta
de los metadatos de calidad asociados al Data Warehouse, así como para la navegación dentro del directorio
de metadatos [ ] [ ]
El nombre del paquete software ofertado que incluye tal funcionalidad
La plataformas o plataformas donde ha de instalarse
Requiere algún software adicional para completar tal funcionalidad [ ] [ ]
Es posible crear vistas adaptadas de los metadatos para diferentes proyectos [ ] [ ]
Utiliza un formato propio de metadatos [ ] [ ]
Indicar la información contenida en los metadatos
Descripción de los esquemas de datos origen [ ] [ ]
Métricas definidas por defecto [ ] [ ]
Métricas definidas por el usuario [ ] [ ]
Otras (especificar) [ ] [ ]
Indicar el grado de seguridad en el acceso a los metadatos
No incorpora funciones de seguridad [ ] [ ]
Sí incorpora funciones de seguridad [ ] [ ]
Dispone de alguna herramienta específica que permita el acceso vía
Web a los metadatos de calidad [ ] [ ]
especificar qué navegadores son compatibles
El nombre del paquete software ofertado que incluye tal funcionalidad y dónde
ha de instalarse, detallando los requerimientos lógicos y físicos asociados
Requiere algún software adicional para completar tal funcionalidad, además
del propio navegador [ ] [ ]
En base a la pregunta anterior indicar las funcionalidades disponibles vía
Web y las principales diferencias respecto a un acceso cliente/servidor directo
. Integración de los metadatos de calidad con otros metadatos
Es posible que los metadatos generados por dicha herramienta de análisis
puedan ser interpretados e integrados con los generados por otras herramientas, tanto de usuario final como de
extracción, movimiento y carga [ ] [ ]
En caso afirmativo especificar las herramientas de compatibles, indicando si
son o no del mismo fabricante
En base a la pregunta anterior explicar detalladamente los mecanismos de integración
utilizados, enumerando las consideraciones a tener en cuenta
Dicha integración de los metadatos completamente automática [ ] [ ]
. Control de versiones y documentación del metadato de calidad
Se mantiene un histórico sobre los cambios realizados en los metadatos
de calidad que permita realizar un control de versiones [ ] [ ]
si existe algún límite en el número de versiones [ ] [ ]
Está automatizada la generación de documentación asociada
con los metadatos de calidad [ ] [ ]
Posibilidad de imprimir dicha documentación
No [ ] [ ]
Sí, pero sin presentación preliminar [ ] [ ]
Sí, con presentación preliminar [ ] [ ]
. Importación y exportación de los metadatos de calidad
Permite importar los metadatos de calidad desde fuentes externas [ ] [ ]
Indicar las fuentes soportadas
Procesadores de texto [ ] [ ]
Amipro [ ] [ ]
Word [ ] [ ]
WordPerfect [ ] [ ]
Otros (especificar) [ ] [ ]
Bases de datos (especificar) [ ] [ ]
Hojas de cálculo [ ] [ ]
Lotus 123 [ ] [ ]
Excel [ ] [ ]
Otros (especificar) [ ] [ ]
Ficheros planos [ ] [ ]
Otras (especificar) [ ] [ ]
Consideraciones a tener en cuenta
Posibilidad de exportar los metadatos de calidad [ ] [ ]
Formatos soportados
CDIF (formato estándar de intercambio de datos) [ ] [ ]
Otros (especificar) [ ] [ ]
- PLANIFICACION DEL ANALISIS DE CALIDAD
. Posibilidad de construir procedimientos que automaticen las tareas de análisis
de la calidad de los datos
No [ ] [ ]
Sí, pero no dispone de un interfaz gráfico que facilite la programación
de dichas tareas. [ ] [ ]
Sí, con un interfaz gráfico que facilite la programación
de dichas tareas [ ] [ ]
. Indicar las posibles bases de dicha planificación
Eventos [ ] [ ]
Ventanas de tiempo [ ] [ ]
Otras (especificar) [ ] [ ]
. Indicar el paquete software ofertado que incluye esta funcionalidad y la plataforma
o plataformas donde ha de instalarse
. Requiere algún software adicional que complemente dicha funcionalidad [ ] [ ]
ACLARACIONES GENERALES
REFERENCIAS
Resumen de las principales instalaciones donde se encuentran instaladas las herramientas
propuestas, con una breve descripción del entorno tecnológico y de los volúmenes de información
manejados
3.3.3.- CUESTIONARIO DE HERRAMIENTAS DE USUARIO FINAL: OLAP, EIS, REPORTING
Con carácter general y a fin de utilizar la información recopilada de cara a la contratación, es importante destacar que los datos recogidos en este cuestionario están dirigidos a obtener un resumen estructurado de la oferta y a demostrar la solvencia técnica o profesional de la empresa en aquellos casos en que no sea requerida la clasificación de la misma. Dicha información sólo servirá de base a la valoración cuando esté relacionada con lo expresado en la cláusula "Criterios de adjudicación del contrato", siendo, en el resto de los casos, de carácter meramente informativo.
Nota: (*) significa que hay que indicar "1" en caso afirmativo.
(**) significa que hay que repetir para cada sistema operativo ofertado.
Cuestión Respuesta Referencia a oferta (Página)
------------------------------------------ ---------- ----------
ENTORNO OPERATIVO
- REQUERIMIENTOS LÓGICOS
Es compatible con los sistemas operativos de las plataformas
[ ]
[ ]
Es compatible con otros sistemas operativos (enumerar)
[ ]
[ ]
Es compatible con el software de red del entorno
[ ]
[ ]
Necesidad software adicional (enumerar)
[ ]
[ ]
- REQUERIMIENTOS FÍSICOS
. Memoria RAM Mínima requerida [ ] [ ]
. Memoria RAM Recomendada [ ] [ ]
. Espacio libre de disco Mínimo requerido [ ] [ ]
. Espacio libre de disco Recomendado [ ] [ ]
. Procesador mínimo requerido [ ] [ ]
. Porcesador recomendado [ ] [ ]
. Observaciones
CARACTERÍSTICAS GENERALES
- INTERFACES DE USUARIO FINAL APORTADAS Y SOPORTADAS
. Especificar los diferentes interfaces de usuario final que aportan
las herramientas ofertadas, indicando el perfil de usuario adecuado a cada uno de ellos
Aplicaciones EIS [ ] [ ]
Entornos OLAP [ ] [ ]
Reporting [ ] [ ]
Otros (especificar) [ ] [ ]
. Especificar los diferentes interfaces de usuario final que se soportan,
indicando el perfil de usuario adecuado a cada uno de ellos
Aplicaciones EIS [ ] [ ]
Entornos OLAP [ ] [ ]
Reporting [ ] [ ]
Lotus 123 [ ] [ ]
Excel [ ] [ ]
Otros (especificar) [ ] [ ]
- DESCRIPCIÓN DEL ACCESO
. Especificar el tipo de acceso efectuado
ROLAP [ ] [ ]
MOLAP [ ] [ ]
Observaciones
. Indicar las arquitecturas cliente/servidor soportadas
2 niveles (acceso directo a la base de datos desde el puesto cliente) [ ] [ ]
3 niveles (acceso a la base de datos a través de un servidor intermedio) [ ] [ ]
4 niveles (acceso vía Web) [ ] [ ]
Observaciones
. Indicar los gestores de bases de datos que soporta, así como
las últimas versiones certificadas para cada uno de ellos
Adabas....................... [ ] [ ]
DB2....................... [ ] [ ]
Informix....................... [ ] [ ]
Oracle....................... [ ] [ ]
Redbrick....................... [ ] [ ]
SQL Server....................... [ ] [ ]
Sybase Adaptive Server Enterprise....................... [ ] [ ]
Sybase Adaptive Server IQ ....................... [ ] [ ]
Teradata....................... [ ] [ ]
Otros (especificar)....................... [ ] [ ]
. Almacenamiento físico de los datos recuperados
Fichero plano [ ] [ ]
Memoria [ ] [ ]
Base de datos propia [ ] [ ]
Base de datos externa (especificar los gestores soportados en observaciones) [ ] [ ]
Otros (especificar) [ ] [ ]
. Dónde se almacena la información recuperada
Puesto cliente [ ] [ ]
Servidor intermedio [ ] [ ]
Servidor central [ ] [ ]
Otros (especificar) [ ] [ ]
. Indicar la visión lógica de los datos recuperados.
Relacional [ ] [ ]
Multidimensional (cubos) [ ] [ ]
. En caso de almacenar la información recuperada de manera
multidimensional indicar cómo y cuándo se genera el cubo
En el momento de la consulta [ ] [ ]
En un proceso diferido [ ] [ ]
Otros (especificar) [ ] [ ]
Para cualquiera de las respuestas describir en detalle el mecanismo seguido
. En caso de almacenamiento multidimensional explicar qué ocurre
si los datos necesarios para dar respuesta a una consulta no se encuentran en el cubo
Genera en el momento un nuevo acceso a la base de datos del Data [ ] [ ]
Warehouse [ ] [ ]
Se indica que la consulta en cuestión no puede ser ejecutada [ ] [ ]
Otros (especificar) [ ] [ ]
Para cualquiera de las respuestas describir en detalle el mecanismo seguido
- TÉCNICAS DE EXPLORACIÓN DE DATOS
. Técnicas de exploración de datos soportadas
Drill down [ ] [ ]
Drill up [ ] [ ]
Drill across [ ] [ ]
Otras (especificar) [ ] [ ]
. Para las técnicas de navegación soportadas indicar
en qué casos se vuelve a lanzar una query contra la base de datos con el fin de obtener los detalles solicitados,
especificando si se hace de forma desatendida o no
. En el caso de utilizar alguna de las técnicas de exploración
de datos, se mantiene la visualización de los datos asociados a cada uno de los pasos seguidos, de manera
que siempre tendremos los datos anteriores para poder iniciar otro camino de navegación. [ ] [ ]
Observaciones
. Es posible navegar por más de una ocurrencia
del mismo atributo simultáneamente [ ] [ ]
Especificar si existe algún límite en el número de ocurrencias
desde las que iniciar una navegación
Observaciones
- FUNCIONALIDADES. POTENCIA DE CÁLCULO
. Principales funcionalidades proporcionadas
Rankings
[ ]
[ ]
Tendencias
[ ]
[ ]
Comparativas
[ ]
[ ]
Otras (especificar)
[ ]
[ ]
Descripción de las funcionalidades
. Enumerar las funciones estadísticas disponibles
. Funcionalidades de cálculo dinámico soportadas
Definición de múltiples criterios de ordenación dentro de
un informe
[ ]
[ ]
Redimensionamiento automático de la anchura de las columnas
[ ]
[ ]
Cálculo automático de totales y estadísticas
[ ]
[ ]
Otras (especificar)
[ ]
[ ]
. Posibilidad de utilizar fechas dinámicas,
tomando como base la fecha actual
[ ]
[ ]
(especificar)
. Posible realizar cálculos dinámicos
entre las columnas o incluso celdas que componen un informe ya calculado, de forma semejante a como lo hace una hoja de cálculo, sin necesidad de lanzar una nueva consulta
No
[ ]
[ ]
Sí, pero es necesario definir una nueva métrica
[ ]
[ ]
Sí, sin necesidad de definir nuevas métricas
[ ]
[ ]
- VISIÓN DEL MODELO DE NEGOCIO
. Posee un interfaz gráfica que muestre el modelo de negocio
utilizado, es decir, las dimensiones de forma jerarquizada
y los atributos que las componen
No
[ ]
[ ]
Sí, pero sin la posibilidad de limitar la expansión de los atributos
hasta el nivel deseado.
[ ]
[ ]
Sí, con la posibilidad de limitar la expansión.
[ ]
[ ]
. En caso de poder limitar esta expansión especificar los posibles
criterios a seguir, y describir el mecanismo de
limitación utilizado
Por usuario
[ ]
[ ]
Por grupo de usuario
[ ]
[ ]
Otros (especificar)
[ ]
[ ]
. Posible en dicho interfaz gráfico visualizar
los valores de los atributos que forman parte del
modelo de negocio
[ ]
[ ]
afirmativo explicar la técnica utilizada para obtener dichos valores
- LIMITACIONES
. Limitación interna de la herramienta
en cuanto al volumen máximo de información
que se puede recuperar
Sí , limitado por número de registros
[ ]
[ ]
Sí , limitado por volumen de información
[ ]
[ ]
No
[ ]
[ ]
Especificar el límite definido
. Limitación en cuanto al número
de dimensiones o atributos a incluir dentro del
modelo de datos de negocio
[ ]
[ ]
(especificar)
. Especificar detalladamente las principales limitaciones de los paquetes
software ofertados
- RECOMENDACIONES PRÁCTICAS
. Indicar el modelo de datos recomendado (en el servidor de datos)
Copo de nieve
[ ]
[ ]
Estrella
[ ]
[ ]
Relacional
[ ]
[ ]
Otros (especificar)
[ ]
[ ]
. Especificar detalladamente las principales recomendaciones prácticas
para asegurar una plena explotación de la
potencialidad de las herramientas ofertadas
. Enumerar y justificar brevemente los puntos fuertes tanto de la
arquitectura funcional propuesta como de las herramientas
ofertadas
3.3.3.- CUESTIONARIO DE HERRAMIENTAS DE USUARIO FINAL: OLAP, EIS, REPORTING
Con carácter general y a fin de utilizar la información recopilada de cara a la contratación, es importante destacar que los datos recogidos en este cuestionario están dirigidos a obtener un resumen estructurado de la oferta y a demostrar la solvencia técnica o profesional de la empresa en aquellos casos en que no sea requerida la clasificación de la misma. Dicha información sólo servirá de base a la valoración cuando esté relacionada con lo expresado en la cláusula "Criterios de adjudicación del contrato", siendo, en el resto de los casos, de carácter meramente informativo.
Nota: (*) significa que hay que indicar "1" en caso afirmativo.
(**) significa que hay que repetir para cada sistema operativo ofertado.
Cuestión Respuesta Referencia a oferta (Página)
------------------------------------------ ---------- ----------
ENTORNO OPERATIVO
- REQUERIMIENTOS LÓGICOS
Es compatible con los sistemas operativos de las plataformas
[ ]
[ ]
Es compatible con otros sistemas operativos (enumerar)
[ ]
[ ]
Es compatible con el software de red del entorno
[ ]
[ ]
Necesidad software adicional (enumerar)
[ ]
[ ]
- REQUERIMIENTOS FÍSICOS
. Memoria RAM Mínima requerida [ ] [ ]
. Memoria RAM Recomendada [ ] [ ]
. Espacio libre de disco Mínimo requerido [ ] [ ]
. Espacio libre de disco Recomendado [ ] [ ]
. Procesador mínimo requerido [ ] [ ]
. Porcesador recomendado [ ] [ ]
. Observaciones
CARACTERÍSTICAS GENERALES
- INTERFACES DE USUARIO FINAL APORTADAS Y SOPORTADAS
. Especificar los diferentes interfaces de usuario final que aportan
las herramientas ofertadas, indicando el perfil de usuario adecuado a cada uno de ellos
Aplicaciones EIS [ ] [ ]
Entornos OLAP [ ] [ ]
Reporting [ ] [ ]
Otros (especificar) [ ] [ ]
. Especificar los diferentes interfaces de usuario final que se soportan,
indicando el perfil de usuario adecuado a cada uno de ellos
Aplicaciones EIS [ ] [ ]
Entornos OLAP [ ] [ ]
Reporting [ ] [ ]
Lotus 123 [ ] [ ]
Excel [ ] [ ]
Otros (especificar) [ ] [ ]
- DESCRIPCIÓN DEL ACCESO
. Especificar el tipo de acceso efectuado
ROLAP [ ] [ ]
MOLAP [ ] [ ]
Observaciones
. Indicar las arquitecturas cliente/servidor soportadas
2 niveles (acceso directo a la base de datos desde el puesto cliente) [ ] [ ]
3 niveles (acceso a la base de datos a través de un servidor intermedio) [ ] [ ]
4 niveles (acceso vía Web) [ ] [ ]
Observaciones
. Indicar los gestores de bases de datos que soporta, así como
las últimas versiones certificadas para cada uno de ellos
Adabas....................... [ ] [ ]
DB2....................... [ ] [ ]
Informix....................... [ ] [ ]
Oracle....................... [ ] [ ]
Redbrick....................... [ ] [ ]
SQL Server....................... [ ] [ ]
Sybase Adaptive Server Enterprise....................... [ ] [ ]
Sybase Adaptive Server IQ ....................... [ ] [ ]
Teradata....................... [ ] [ ]
Otros (especificar)....................... [ ] [ ]
. Almacenamiento físico de los datos recuperados
Fichero plano [ ] [ ]
Memoria [ ] [ ]
Base de datos propia [ ] [ ]
Base de datos externa (especificar los gestores soportados en observaciones) [ ] [ ]
Otros (especificar) [ ] [ ]
. Dónde se almacena la información recuperada
Puesto cliente [ ] [ ]
Servidor intermedio [ ] [ ]
Servidor central [ ] [ ]
Otros (especificar) [ ] [ ]
. Indicar la visión lógica de los datos recuperados.
Relacional [ ] [ ]
Multidimensional (cubos) [ ] [ ]
. En caso de almacenar la información recuperada de manera
multidimensional indicar cómo y cuándo se genera el cubo
En el momento de la consulta [ ] [ ]
En un proceso diferido [ ] [ ]
Otros (especificar) [ ] [ ]
Para cualquiera de las respuestas describir en detalle el mecanismo seguido
. En caso de almacenamiento multidimensional explicar qué ocurre
si los datos necesarios para dar respuesta a una consulta no se encuentran en el cubo
Genera en el momento un nuevo acceso a la base de datos del Data [ ] [ ]
Warehouse [ ] [ ]
Se indica que la consulta en cuestión no puede ser ejecutada [ ] [ ]
Otros (especificar) [ ] [ ]
Para cualquiera de las respuestas describir en detalle el mecanismo seguido
- TÉCNICAS DE EXPLORACIÓN DE DATOS
. Técnicas de exploración de datos soportadas
Drill down [ ] [ ]
Drill up [ ] [ ]
Drill across [ ] [ ]
Otras (especificar) [ ] [ ]
. Para las técnicas de navegación soportadas indicar
en qué casos se vuelve a lanzar una query contra la base de datos con el fin de obtener los detalles solicitados,
especificando si se hace de forma desatendida o no
. En el caso de utilizar alguna de las técnicas de exploración
de datos, se mantiene la visualización de los datos asociados a cada uno de los pasos seguidos, de manera
que siempre tendremos los datos anteriores para poder iniciar otro camino de navegación. [ ] [ ]
Observaciones
. Es posible navegar por más de una ocurrencia
del mismo atributo simultáneamente [ ] [ ]
Especificar si existe algún límite en el número de ocurrencias
desde las que iniciar una navegación
Observaciones
- FUNCIONALIDADES. POTENCIA DE CÁLCULO
. Principales funcionalidades proporcionadas
Rankings
[ ]
[ ]
Tendencias
[ ]
[ ]
Comparativas
[ ]
[ ]
Otras (especificar)
[ ]
[ ]
Descripción de las funcionalidades
. Enumerar las funciones estadísticas disponibles
. Funcionalidades de cálculo dinámico soportadas
Definición de múltiples criterios de ordenación dentro de
un informe
[ ]
[ ]
Redimensionamiento automático de la anchura de las columnas
[ ]
[ ]
Cálculo automático de totales y estadísticas
[ ]
[ ]
Otras (especificar)
[ ]
[ ]
. Posibilidad de utilizar fechas dinámicas,
tomando como base la fecha actual
[ ]
[ ]
(especificar)
. Posible realizar cálculos dinámicos
entre las columnas o incluso celdas que componen un informe ya calculado, de forma semejante a como lo hace una hoja de cálculo, sin necesidad de lanzar una nueva consulta
No
[ ]
[ ]
Sí, pero es necesario definir una nueva métrica
[ ]
[ ]
Sí, sin necesidad de definir nuevas métricas
[ ]
[ ]
- VISIÓN DEL MODELO DE NEGOCIO
. Posee un interfaz gráfica que muestre el modelo de negocio
utilizado, es decir, las dimensiones de forma jerarquizada
y los atributos que las componen
No
[ ]
[ ]
Sí, pero sin la posibilidad de limitar la expansión de los atributos
hasta el nivel deseado.
[ ]
[ ]
Sí, con la posibilidad de limitar la expansión.
[ ]
[ ]
. En caso de poder limitar esta expansión especificar los posibles
criterios a seguir, y describir el mecanismo de
limitación utilizado
Por usuario
[ ]
[ ]
Por grupo de usuario
[ ]
[ ]
Otros (especificar)
[ ]
[ ]
. Posible en dicho interfaz gráfico visualizar
los valores de los atributos que forman parte del
modelo de negocio
[ ]
[ ]
afirmativo explicar la técnica utilizada para obtener dichos valores
- LIMITACIONES
. Limitación interna de la herramienta
en cuanto al volumen máximo de información
que se puede recuperar
Sí , limitado por número de registros
[ ]
[ ]
Sí , limitado por volumen de información
[ ]
[ ]
No
[ ]
[ ]
Especificar el límite definido
. Limitación en cuanto al número
de dimensiones o atributos a incluir dentro del
modelo de datos de negocio
[ ]
[ ]
(especificar)
. Especificar detalladamente las principales limitaciones de los paquetes
software ofertados
- RECOMENDACIONES PRÁCTICAS
. Indicar el modelo de datos recomendado (en el servidor de datos)
Copo de nieve
[ ]
[ ]
Estrella
[ ]
[ ]
Relacional
[ ]
[ ]
Otros (especificar)
[ ]
[ ]
. Especificar detalladamente las principales recomendaciones prácticas
para asegurar una plena explotación de la
potencialidad de las herramientas ofertadas
. Enumerar y justificar brevemente los puntos fuertes tanto de la
arquitectura funcional propuesta como de las herramientas
ofertadas
3.3.3.- CUESTIONARIO DE HERRAMIENTAS DE USUARIO FINAL: OLAP, EIS, REPORTING (cont.)
Con carácter general y a fin de utilizar la información recopilada de cara a la contratación, es importante destacar que los datos recogidos en este cuestionario están dirigidos a obtener un resumen estructurado de la oferta y a demostrar la solvencia técnica o profesional de la empresa en aquellos casos en que no sea requerida la clasificación de la misma. Dicha información sólo servirá de base a la valoración cuando esté relacionada con lo expresado en la cláusula "Criterios de adjudicación del contrato", siendo, en el resto de los casos, de carácter meramente informativo.
Nota: (*) significa que hay que indicar "1" en caso afirmativo.
(**) significa que hay que repetir para cada sistema operativo ofertado.
Cuestión Respuesta Referencia a oferta (Página)
------------------------------------------ ---------- ----------
ADMINISTRACIÓN
- GESTIÓN DE RECURSOS
. Administración centralizada
Posee una herramienta de administración centralizada
No
[ ]
[ ]
Sí, pero sin interfaz gráfica
[ ]
[ ]
Sí, con interfaz gráfica
[ ]
[ ]
Indicar y describir las funcionalidades que incorpora esta herramienta
Gestión de la seguridad
[ ]
[ ]
Monitorización de tareas en curso
[ ]
[ ]
Definición de perfiles de usuario
[ ]
[ ]
Asignación y limitación de recursos
[ ]
[ ]
Otras (especificar)
[ ]
[ ]
Observaciones. Describir las funcionalidades soportadas
Posibilidad de utilización de esta herramienta de administración
desde varios puestos
No
[ ]
[ ]
Sí, pero no simultáneamente
[ ]
[ ]
Sí, simultáneamente
[ ]
[ ]
Indicar el paquete software ofertado que incluye esta funcionalidad
Indicar las plataformas donde es necesario instalar el software de esta herramienta
de administración
Puesto cliente
[ ]
[ ]
Servidor intermedio
[ ]
[ ]
Servidor central
[ ]
[ ]
Requierimiento de algún software adicional que complemente dicha funcionalidad
[ ]
[ ]
Observaciones (especificar
en caso afirmativo)
Observaciones
. Tratamiento de los datos recuperados
Técnicas aplicadas sobre los datos recuperados
Compresión
[ ]
[ ]
Encriptación
[ ]
[ ]
Otros (especificar)
[ ]
[ ]
En caso de aplicar compresión, indicar la relación de compresión
Salva el resultado de la consulta
No
[ ]
[ ]
Sí, bajo petición del usuario
[ ]
[ ]
Sí, automáticamente
[ ]
[ ]
En caso afirmativo especificar los formatos soportados
HTML
[ ]
[ ]
Dbase
[ ]
[ ]
RTF
[ ]
[ ]
Lotus 123
[ ]
[ ]
Excel
[ ]
[ ]
Amipro
[ ]
[ ]
WordPerfect
[ ]
[ ]
Word
[ ]
[ ]
Tablas del gestor
[ ]
[ ]
Otros (especificar)
[ ]
[ ]
Utilización tablas temporales en la resolución de las consultas
efectuadas
[ ]
[ ]
Observaciones. Indicar el volumen de almacenamiento recomendado para dichas tablas,
en función del volumen de datos
En caso afirmativo especificar la posible localización física de
dichas tablas
Puesto cliente (base de datos auxiliar)
[ ]
[ ]
Servidor intermedio (base de datos auxiliar)
[ ]
[ ]
Servidor central (base de datos del Data Warehouse)
[ ]
[ ]
Observaciones
. Estadísticas de ejecución
Realización una elaboración automática de estadísticas
sobre la utilización de recursos
[ ]
[ ]
Información incluida en dichas estadísticas
Tipos de consultas más frecuentes
[ ]
[ ]
Tiempos de ejecución
[ ]
[ ]
Número de accesos realizados por usuario
[ ]
[ ]
Volúmenes recuperados de información
[ ]
[ ]
Estadísticas asociadas a threads de diferentes prioridades
[ ]
[ ]
Otras estadísticas (especificar)
[ ]
[ ]
Almacenamiento físico de dicha información estadística
Fichero plano
[ ]
[ ]
Base de Datos propia
[ ]
[ ]
Base de Datos externa (especificar los gestores soportados en observaciones)
[ ]
[ ]
Otros (especificar)
[ ]
[ ]
Dónde se almacena la información estadística
Puesto cliente
[ ]
[ ]
Servidor intermedio
[ ]
[ ]
Servidor central
[ ]
[ ]
Observaciones
. Simulación, estimaciones de consumo y
recomendaciones sobre el diseño del Data Warehouse
Dispone de alguna herramienta de simulación que permita estimar el consumo
de recursos y el tiempo de respuesta de las consultas
[ ]
[ ]
Permite estimar el consumo de recursos y tiempo de respuesta de una consulta
antes de su ejecución
No
[ ]
[ ]
Sí, en base a ejecuciones anteriores (especificar qué ocurre si
es la primera vez que se ejecuta dicha consulta
[ ]
[ ]
Sí, en base a otros criterios (especificar)
[ ]
[ ]
Dispone de alguna herramienta que en base a estadísticas de ejecución
haga recomendaciones sobre el diseño del Data Warehouse
No
[ ]
[ ]
Sí, con la ayuda del usuario final
[ ]
[ ]
Sí, hace las recomendaciones automáticamente, sin necesitar
al usuario final
[ ]
[ ]
En caso afirmativo, explicar en qué consisten dichas recomendaciones
Observaciones
. Asignación dinámica de recursos
Es posible definir threads de consulta con diferentes prioridades de acceso para
queries simultáneas
[ ]
[ ]
Indicar el abanico de prioridades asignadas a dichos threads
Los posibles criterios de definición de dichos threads
Por tiempo estimado de ejecución de la consulta
[ ]
[ ]
Por perfil de usuario
[ ]
[ ]
Por grupo de usuario
[ ]
[ ]
Por consulta específica
[ ]
[ ]
Por volumen estimado de datos a recuperar
[ ]
[ ]
Ventana de ejecución (temporal)
[ ]
[ ]
Otras (especificar)
[ ]
[ ]
Observaciones
. Limitación del consumo de recursos en las consultas
Posibilidad de la herramienta de limitar el consumo de recursos
No
[ ]
[ ]
Sí. La herramienta lo hace automáticamente, sin pedir confirmación
al usuario y sin tener en cuenta el perfil de usuario
[ ]
[ ]
Sí. Se pide confirmación al usuario siempre para lanzar o no la
consulta independientemente del perfil del mismo
[ ]
[ ]
Sí. Para ciertos perfiles se limita automáticamente
y para otros no se limita
[ ]
[ ]
Sí. Para ciertos perfiles se limita automáticamente y para otros
se pide confirmación al usuario para lanzar o no la consulta
[ ]
[ ]
Permite evitar la ejecución de una consulta si el tiempo estimado de ejecución
es superior a un umbral definido
No
[ ]
[ ]
Sí, totalmente
[ ]
[ ]
Sí, pero permite al menos la ejecución batch de la consulta para
cualquier perfil de usuario final
[ ]
[ ]
Sí, pero permite al menos la ejecución batch de la consulta
para ciertos perfiles
[ ]
[ ]
Permite evitar la ejecución de una consulta si el número estimado
de filas a devolver es superior a un umbral definido
No
[ ]
[ ]
Sí, totalmente
[ ]
[ ]
Sí, pero permite al menos la ejecución batch de la consulta para
cualquier perfil de usuario final
[ ]
[ ]
Sí, pero permite al menos la ejecución batch de la consulta
para ciertos perfiles
[ ]
[ ]
Permite evitar la ejecución de una consulta si el número estimado
de filas a acceder es superior a un umbral definido
No
[ ]
[ ]
Sí, totalmente
[ ]
[ ]
Sí, pero permite al menos la ejecución batch de la consulta para
cualquier perfil de usuario final
[ ]
[ ]
Sí, pero permite al menos la ejecución batch de la consulta
para ciertos perfiles
[ ]
[ ]
Permite evitar la ejecución de una consulta si el volumen estimado de
datos a devolver es superior a un umbral definido
No
[ ]
[ ]
Sí, totalmente
[ ]
[ ]
Sí, pero permite al menos la ejecución batch de la consulta para
cualquier perfil de usuario final
[ ]
[ ]
Sí, pero permite al menos la ejecución batch de la consulta
para ciertos perfiles
[ ]
[ ]
Permite evitar la ejecución de una consulta si el volumen estimado de
datos a acceder es superior a un umbral definido
No
[ ]
[ ]
Sí, totalmente
[ ]
[ ]
Sí, pero permite al menos la ejecución batch de la consulta para
cualquier perfil de usuario final
[ ]
[ ]
Sí, pero permite al menos la ejecución batch de la consulta
para ciertos perfiles
[ ]
[ ]
Cancela automáticamente la ejecución de una consulta cuando el
tiempo de respuesta sobrepasa un umbral definido
No
[ ]
[ ]
Sí, totalmente (no devuelve nada) independientemente del perfil de usuario
[ ]
[ ]
Sí, totalmente (no devuelve nada) para ciertos perfiles de usuario, y
para otros no la cancela
[ ]
[ ]
Sí, pero devuelve al menos la información recuperada hasta ese
momento,independientemente del perfil de usuario
[ ]
[ ]
Cancela automáticamente la ejecución de una consulta cuando el
número de filas devueltas sobrepasa un umbral definido
No
[ ]
[ ]
Sí, totalmente (no devuelve nada) independientemente del perfil de usuario
[ ]
[ ]
Sí, totalmente (no devuelve nada) para ciertos perfiles de usuario, y
para otros no la cancela
[ ]
[ ]
Sí, pero devuelve al menos la información recuperada hasta ese
momento,independientemente del perfil de usuario
[ ]
[ ]
Cancela automáticamente la ejecución de una consulta cuando el
número de filas accedido sobrepasa un umbral definido
No
[ ]
[ ]
Sí, totalmente (no devuelve nada) independientemente del perfil de usuario
[ ]
[ ]
Sí, totalmente (no devuelve nada) para ciertos perfiles de usuario, y
para otros no la cancela
[ ]
[ ]
Sí, pero devuelve al menos la información recuperada hasta ese
momento, independientemente del perfil de usuario
[ ]
[ ]
Cancela automáticamente la ejecución de una consulta cuando el
volumen de información recuperado sobrepasa un umbral definido
No
[ ]
[ ]
Sí, totalmente (no devuelve nada) independientemente del perfil
de usuario
[ ]
[ ]
Sí, totalmente (no devuelve nada) para ciertos perfiles de usuario, y
para otros no la cancela
[ ]
[ ]
Sí, pero devuelve al menos la información recuperada hasta ese
momento, independientemente del perfil de usuario
[ ]
[ ]
Cancela automáticamente la ejecución de una consulta cuando el
volumen deinformación accedido sobrepasa un umbral definido
No
[ ]
[ ]
Sí, totalmente (no devuelve nada) independientemente del perfil de usuario
[ ]
[ ]
Sí, totalmente (no devuelve nada) para ciertos perfiles de usuario, y
para otros no la cancela
[ ]
[ ]
Sí, pero devuelve al menos la información recuperada hasta ese
momento, independientemente del perfil de usuario
[ ]
[ ]
Permite rechazar consultas en base a la franja horaria
No
[ ]
[ ]
Sí, totalmente
[ ]
[ ]
Sí, pero permite al menos la ejecución batch de la consulta para
cualquier perfil de usuario final
[ ]
[ ]
Sí, pero permite al menos la ejecución batch de la consulta
para ciertos perfiles
[ ]
[ ]
Permite rechazar consultas en base a la carga del sistema
No
[ ]
[ ]
Sí, totalmente
[ ]
[ ]
Sí, pero permite al menos la ejecución batch de la consulta para
cualquier perfil de usuario final
[ ]
[ ]
Sí, pero permite al menos la ejecución batch de la consulta
para ciertos perfiles
[ ]
[ ]
Observaciones
- GESTIÓN DE ACCCESO Y EJECUCIÓN
. Seguridad de acceso
Indicar los niveles de seguridad soportados
Por usuario
[ ]
[ ]
Por grupo de usuario
[ ]
[ ]
Por consulta específica
[ ]
[ ]
Otros (especificar)
[ ]
[ ]
En qué plataforma se gestiona la seguridad
Puesto cliente
[ ]
[ ]
Servidor intermedio
[ ]
[ ]
Servidor central
[ ]
[ ]
Se realiza una identificación del usuario a la hora de acceder al sistema
No
[ ]
[ ]
Sí, sin password
[ ]
[ ]
Sí, con password
[ ]
[ ]
Almacenamiento físico de la password
Fichero plano
[ ]
[ ]
Base de datos propia
[ ]
[ ]
Base de datos externa (especificar los gestores soportados en observaciones)
[ ]
[ ]
Otros (especificar)
[ ]
[ ]
Localización física de la password
Puesto cliente
[ ]
[ ]
Servidor intermedio
[ ]
[ ]
Servidor central
[ ]
[ ]
Otros (especificar)
[ ]
[ ]
Se permite a nivel de seguridad auditar las operaciones realizadas por los diferentes
usuarios
[ ]
[ ]
En caso afirmativo, ¿cómo se almacena esta información?
Ficheros planos
[ ]
[ ]
Base de datos propia
[ ]
[ ]
Base de datos externa (especificar los gestores soportados en observaciones)
[ ]
[ ]
Otros (especificar)
[ ]
[ ]
En caso afirmativo, dónde se almacena esta información
Puesto cliente
[ ]
[ ]
Servidor intermedio
[ ]
[ ]
Servidor central
[ ]
[ ]
Otros (especificar)
[ ]
[ ]
Observaciones
. Limitaciones a nivel de acceso
Número máximo de accesos concurrentes para el mismo usuario
[ ]
[ ]
Número máximo de usuarios concurrentes
[ ]
[ ]
Existe la posibilidad de limitar el acceso a la información a nivel de
registro
[ ]
[ ]
En caso afirmativo, en base a qué criterio
Por consulta específica
[ ]
[ ]
Por grupo de usuario
[ ]
[ ]
Por usuario
[ ]
[ ]
Otros (especificar)
[ ]
[ ]
Es posible lanzar desde un mismo puesto cliente una consulta, y sin esperar a
recibir la respuesta lanzar otra
[ ]
[ ]
Observaciones
. Prioridades de ejecución
Se pueden establecer distintos grados de prioridad a la hora de ejecutar varias
consultas
[ ]
[ ]
En base a qué criterios se pueden dar prioridades de ejecución
Por usuario
[ ]
[ ]
Por grupo de usuario
[ ]
[ ]
Consultas específicas
[ ]
[ ]
Otros (especificar)
[ ]
[ ]
Observaciones
ACLARACIONES GENERALES
Observaciones
REFERENCIAS
Resumen de las principales instalaciones donde se encuentran instaladas las herramientas
propuestas, con una breve descripción del entorno tecnológico y de los volúmenes de información
manejados
Observaciones
4.- PRUEBAS DE VERIFICACIÓN Y CONTROL
Un Data Warehouse precisa de un conjunto de pasos desde su creación hasta su explotación final. En todos estos pasos se precisa de una herramienta que nos permita simplificar su ejecución. Debido a la amplia variedad de herramientas disponibles, y para asegurar la idoneidad de la herramienta, caben varias alternativas:
Evaluación distribuida: En ella se evaluaría cada herramienta en un paso concreto. Se vería cual es la que mejor se adapta a nuestras necesidades, y a continuación, examinaríamos la compatibilidad en cascada de todas ellas.
Evaluación centralizada: En ella se evaluaría el soporte que cada herramienta proporciona a todos los pasos, y a continuación se examina cual es la que globalmente se adecua de forma global a nuestras necesidades.
La elección de una u otra alternativa tiene sus ventajas e inconvenientes: la primera nos permitiría obtener la mejor herramienta (la de mejor relación cumplimiento expectativas/ precio), pero podría comprometer la cadena completa de uso de un Data Warehouse. Lo contrario ocurriría en la segunda alternativa.
Debido a la creciente información disponible de cada fabricante en Internet, y a su frecuente actualización, recomendamos la visita al Data Warehousing Information Center (LGI Systems Incorporated), desde su página principal en http://pwp.starnetinc.com/larryg/index.html en donde, desde donde se encuentran enlaces a:
Vendedores de herramientas de usuario final:
• Herramientas de Query and Reporting
• Bases de Datos OLAP y Multidimensionales
• Sistemas EIS (Executive Information Systems)
• Herramientas de Data Mining
• Recuperación de Documentos
• Sistemas de Información Geográfica (GIS)
• Herramientas de Análisis de Decisiones
• Estadísticas
• Modelado de Procesos
• Filtrado de Información
• Obtención de Informes
• Otras herramientas
Vendedores de Infraestrutura Tecnológica:
• Extracción de Datos, Limpieza y Carga
• Catalogación de la Información
• Bases de Datos para Data Warehousing
• Administración de Consulas y Almacenamiento
• Modelado de Datos para Data Warehouse
• Herramientas iddleware
• Aceleradoras de Query's y Carga
• Otras utilidades de BD
• Hardware
Vendedores por Función e Industria:
• Herramientas de Análisis Financiero
• Herramientas de Marketing y Análisis de Ventas
• Herramientas de Análisis de la cadena de suministro
• Herramientas para la Industria de la Salud
• Herramientas para la Industria Detallista
• Herramientas para el Sector Financiero
• Otras herramientas específicas
1.- INTRODUCCIÓN
1.1. Justificación histórica
En la actualidad, las tecnologías de la información han automatizado los procesos de carácter típicamente repetitivo o administrativo, haciendo uso de lo que llamaremos sistemas de información operacionales. Entendemos por aplicaciones operacionales, aquellas que resuelven las necesidades de funcionamiento de la empresa. En este tipo de sistemas, los conceptos más importantes son la actualización y el tiempo de respuesta.
Una vez satisfechas las necesidades operacionales más acuciantes, surge un nuevo grupo de necesidades sobre los sistemas de la empresa, a las cuales vamos a calificar como necesidades informacionales. Por necesidades informacionales, entendemos aquellas que tienen por objeto obtener la información necesaria, que sirva de base para la toma de decisiones tanto a escala estratégica como táctica. Estas necesidades informacionales se basan en gran medida en el análisis de un número ingente de datos, en el que es tan importante el obtener un valor muy detallado de negocio como el valor totalizado para el mismo. Es fundamental también la visión histórica de todas las variables analizadas, y el análisis de los datos del entorno. Estos requerimientos no son, a priori, difíciles de resolver dado que la información está efectivamente en los sistemas operacionales. Cualquier actividad que realiza la empresa está reflejada de forma minuciosa en sus bases de datos.
La realidad, sin embargo, es distinta, puesto que al atender las necesidades de tipo informacional, los responsables de sistemas se tropiezan con múltiples problemas. En primer lugar, al realizar consultas masivas de información (con el fin de conseguir el ratio, valor agrupado o grupo de valores solicitados), se puede ver perjudicado el nivel de servicio del resto de sistemas, dado que las consultas de las que estamos hablando, suelen ser bastante costosas en recursos. Además, las necesidades se ven insatisfechas por la limitada flexibilidad a la hora de navegar por la información y a su inconsistencia debido a la falta de una visión global (cada visión particular del dato está almacenada en el sistema operacional que lo gestiona).
En esta situación, el siguiente paso evolutivo ha venido siendo la generación de un entorno gemelo del operativo, que se ha denominado comúnmente Centro de Información, en el cual la información se refresca con menor periodicidad que en los entornos operacionales y los requerimientos en el nivel de servicio al usuario son más flexibles.
Con esta estrategia se resuelve el problema de la planificación de recursos ya que las aplicaciones que precisan un nivel de servicio alto usan el entorno operacional y las que precisan consultas masivas de información trabajan en el Centro de Información. Otro beneficio de este nuevo entorno, es la no inferencia con las aplicaciones operacionales.
Pero no terminan aquí los problemas. La información mantiene la misma estructura que en las aplicaciones operacionales por lo que este tipo de consultas debe acceder a multitud de lugares para obtener el conjunto de datos deseado. El tiempo de respuesta a las solicitudes de información es excesivamente elevado. Adicionalmente, al proceder la información de distintos sistemas, con visiones distintas y distintos objetivos, en muchas ocasiones no es posible obtener la información deseada de una forma fácil y además carece de la necesaria fiabilidad.
De cara al usuario estos problemas se traducen en que no dispone a tiempo de la información solicitada y que debe dedicarse con más intensidad a la obtención de la información que al análisis de la misma, que es donde aporta su mayor valor añadido.
1.2. Sumario
En los capítulos siguientes expondremos, por un lado qué es un Data Warehouse, un Data Mart y el porqué de estos conceptos. Por otro lado, veremos sus componentes de base (hardware y software) y el "estado del arte" de las distintas tecnologías disponibles. Analizaremos las distintas partes de las que se compone un sistema Data Warehouse y presentaremos una metodología de construcción del mismo. Examinaremos el uso que se le puede dar (Explotación del Data Warehouse), con especial hincapié en el Data Mining y las posibilidades de acceso a esta información. También presentaremos cómo algunas áreas se han beneficiado de las tecnologías de Data Warehouse: Marketing, Departamento Financiero, Área de Riesgo de Crédito, etc. Y por último, expondremos algunas recomendaciones generales a considerar para un buen uso de los sistemas de este tipo.
2.- ANÁLISIS DEL ENTORNO DATA WAREHOUSE
2.1. - ¿QUÉ ES UN DATA WAREHOUSE?
Tras las dificultades de los sistemas tradicionales en satisfacer las necesidades informacionales, surge el concepto de Data Warehouse, como solución a las necesidades informacionales globales de la empresa. Este término acuñado por Bill Inmon, se traduce literalmente como Almacén de Datos. No obstante si el Data Warehouse fuese exclusivamente un almacén de datos, los problemas seguirían siendo los mismos que en los Centros de Información.
La ventaja principal de este tipo de sistemas se basa en su concepto fundamental, la estructura de la información. Este concepto significa el almacenamiento de información homogénea y fiable, en una estructura basada en la consulta y el tratamiento jerarquizado de la misma, y en un entorno diferenciado de los sistemas operacionales. Según definió Bill Inmon, el Data Warehouse se caracteriza por ser:
Integrado: los datos almacenados en el Data Warehouse deben integrarse en una estructura consistente, por lo que las inconsistencias existentes entre los diversos sistemas operacionales deben ser eliminadas. La información suele estructurarse también en distintos niveles de detalle para adecuarse a las distintas necesidades de los usuarios.
Temático: sólo los datos necesarios para el proceso de generación del conocimiento del negocio se integran desde el entorno operacional. Los datos se organizan por temas para facilitar su acceso y entendimiento por parte de los usuarios finales. Por ejemplo, todos los datos sobre clientes pueden ser consolidados en una única tabla del Data Warehouse. De esta forma, las peticiones de información sobre clientes serán más fáciles de responder dado que toda la información reside en el mismo lugar.
Histórico: el tiempo es parte implícita de la información contenida en un Data Warehouse. En los sistemas operacionales, los datos siempre reflejan el estado de la actividad del negocio en el momento presente. Por el contrario, la información almacenada en el Data Warehouse sirve, entre otras cosas, para realizar análisis de tendencias. Por lo tanto, el Data Warehouse se carga con los distintos valores que toma una variable en el tiempo para permitir comparaciones.
No volátil: el almacén de información de un Data Warehouse existe para ser leído, y no modificado. La información es por tanto permanente, significando la actualización del Data Warehouse la incorporación de los últimos valores que tomaron las distintas variables contenidas en él sin ningún tipo de acción sobre lo que ya existía.
E.F. Codd, considerado como el padre de las bases de datos relacionales, ha venido insistiendo desde principio de los noventa, que disponer de un sistema de bases de datos relacionales, no significa disponer de un soporte directo para la toma de decisiones. Muchas de estas decisiones se basan en un análisis de naturaleza multidimensional, que se intentan resolver con la tecnología no orientada para esta naturaleza. Este análisis multidimensional, parte de una visión de la información como dimensiones de negocio.
Estas dimensiones de negocio se comprenden mejor fijando un ejemplo, para lo que vamos a mostrar, para un sistema de gestión de expedientes, las jerarquías que se podrían manejar para el número de los mismo para las dimensiones: zona geográfica, tipo de expediente y tiempo de resolución. La visión general de la información de ventas para estas dimensiones definidas, la representaremos, gráficamente como el cubo de la derecha:
Un gerente de una zona estaría interesado en visualizar la información para su zona en el tiempo para todos los productos que distribuye, lo podría tener una representación gráfica como el cubo de la derecha:
Un director de producto, sin embargo querría examinar la distribución geográfica de sus productos, para toda la información histórica almacenada en el Data Warehouse.
Esto se podría representar como la siguiente figura:
O se podría también examinar los datos en un determinado momento o una visión particularizada.
A su vez estas dimensiones tienen una jerarquía, interpretándose en el cubo como que cada cubo elemental es un dato elemental, del que se puede extraer información agregada. En el ejemplo anterior podría ser:
Y así por ejemplo se podría querer analizar la evolución de las ventas en Galicia de libros de Física por meses desde Febrero del 1996 hasta Marzo del 1997.
Ello es fácil de obtener (incluso a "golpe de ratón") si la información de ventas se ha almacenado en un Data Warehouse, definiendo estas jerarquías y estas dimensiones de negocio.
En este sentido citamos las palabras de D. Wayne Calloway Director Ejecutivo de Operaciones de Pepsico en una asamblea general de accionistas:
"Hace diez años les pude decir cuántos Doritos vendimos al Oeste del Mississipi. Hoy no sólo les puedo decir eso mismo, sino cuántos vendimos en California, en el Condado de Orange, en la ciudad de Irvine, en el Supermercado local Von’s, en una promoción especial, al final del pasillo 4, los jueves".
Otra característica del Data Warehouse es que contiene datos relativos a los datos, concepto que se ha venido asociando al término de metadatos. Los metadatos permiten mantener información de la procedencia de la información, la periodicidad de refresco, su fiabilidad, forma de cálculo, etc., relativa a los datos de nuestro almacén.
Estos metadatos serán los que permitan simplificar y automatizar la obtención de la información desde los sistemas operacionales a los sistemas informacionales.
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 auditoría, 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.
Para comprender el concepto de Data Warehouse, es importante considerar los procesos que lo conforman. A continuación se describen dichos procesos clave en la gestión de un Data Warehouse:
Extracción: obtención de información de las distintas fuentes tanto internas como externas.
Elaboración: filtrado, limpieza, depuración, homogeneización y agrupación de la información.
Carga: organización y actualización de los datos y los metadatos en la base de datos.
Explotación: extracción y análisis de la información en los distintos niveles de agrupación.
Desde el punto de vista del usuario, el único proceso visible es la explotación del almacén de datos, aunque el éxito del Data Warehouse radica en los tres procesos iniciales que alimentan la información del mismo y suponen el mayor porcentaje de esfuerzo (en torno a un 80%) a la hora de desarrollar el almacén.
Una de las claves del éxito en la construcción de un Data Warehouse es el desarrollo de forma gradual, seleccionando a un departamento usuario como piloto y expandiendo progresivamente el almacén de datos a los demás usuarios. Por ello es importante elegir este usuario inicial o piloto, siendo importante que sea un departamento con pocos usuarios, en el que la necesidad de este tipo de sistemas es muy alta y se puedan obtener y medir resultados a corto plazo.
Terminamos este apartado, resumiendo los beneficios que un Data Warehouse puede aportar:
• Proporciona una herramienta para la toma de decisiones en cualquier área funcional, basándose en información integrada y global del negocio.
• Facilita la aplicación de técnicas estadísticas de análisis y modelización para encontrar relaciones ocultas entre los datos del almacén; obteniendo un valor añadido para el negocio de dicha información.
• Proporciona la capacidad de aprender de los datos del pasado y de predecir situaciones futuras en diversos escenarios.
• Simplifica dentro de la empresa la implantación de sistemas de gestión integral de la relación con el cliente.
• Supone una optimización tecnológica y económica en entornos de Centro de Información, estadística o de generación de informes con retornos de la inversión espectaculares.
2.2.- CONCEPTOS Y FUNCIONALIDADES BÁSICAS
2.2.1.- DATA WAREHOUSE VS. DATA MART
La duplicación en otro entorno de datos es un término que suele ser mal interpretado e incomprendido. Así es usado por los fabricantes de SGBD en el sentido de simple réplica de los datos de un sistema operacional centralizado en sistemas distribuidos. En un contexto de Data Warehouse, el término duplicación se refiere a la creación de Data Marts locales o departamentales basados en subconjuntos de la información contenida en el Data Warehouse central o maestro.
Según define Meta Group, "un Data Mart es una aplicación de Data Warehouse, construida rápidamente para soportar una línea de negocio simple". Los Data Marts, tienen las mismas características de integración, no volatilidad, orientación temática y no volatilidad que el Data Warehouse. Representan una estrategia de "divide y vencerás" para ámbitos muy genéricos de un Data Warehouse.
Esta estrategia es particularmente apropiada cuando el Data Warehouse central crece muy rápidamente y los distintos departamentos requieren sólo una pequeña porción de los datos contenidos en él. La creación de estos Data Marts requiere algo más que una simple réplica de los datos: se necesitarán tanto la segmentación como algunos métodos adicionales de consolidación.
La primera aproximación a una arquitectura descentralizada de Data Mart, podría ser venir originada de una situación como la descrita a continuación.
El departamento de Marketing, emprende el primer proyecto de Data Warehouse como una solución departamental, creando el primer Data Mart de la empresa.
Visto el éxito del proyecto, otros departamentos, como el de Riesgos, o el Financiero se lanzan a crear sus Data Marts. Marketing, comienza a usar otros datos que también usan los Data Marts de Riesgos y Financiero, y estos hacen lo propio.
Esto parece ser una decisión normal, puesto que las necesidades de información de todos los Data Marts crecen conforme el tiempo avanza. Cuando esta situación evoluciona, el esquema general de integración entre los Data Marts pasa a ser, la del gráfico de la derecha.
En esta situación, es fácil observar cómo este esquema de integración de información de los Data Marts, pasa a convertirse en un rompecabezas en el que la gestión se ha complicado hasta convertir esta ansia de información en un auténtico quebradero de cabeza. No obstante, lo que ha fallado no es la integración de Data Marts, sino su forma de integración.
En efecto, un enfoque más adecuado sería la coordinación de la gestión de información de todos los Data Marts en un Data Warehouse centralizado.
En esta situación los Data Marts obtendrían la información necesaria, ya previamente cargada y depurada en el Data Warehouse corporativo, simplificando el crecimiento de una base de conocimientos a nivel de toda la empresa.
Esta simplificación provendría de la centralización de las labores de gestión de los Data Marts, en el Data Warehouse corporativo, generando economías de escala en la gestión de los Data Marts implicados.
Según un estudio de IDC (International Data Corporation) tras analizar 541 empresas, la distribución de las implantaciones de Data Warehouse y Data Marts en la actualidad, y sus opiniones respecto a esta distribución en el futuro, nos muestra los siguientes datos:
En la gráfica, observamos, cómo en la actualidad, de las empresas consultadas, un 80% de ellas cuentan con implantaciones de Data Warehouse o Data Marts.
La proporción actual de implantaciones de Data Warehouse es casi el doble que el de Data Mart.
No obstante, seguramente tras la andadura inicial de alguno de estos proyectos de Data Mart, se ve como más adecuado para el futuro este enfoque "divide y vencerás", previéndose una inversión de estos papeles y duplicando la implantación de Data Marts a los Data Warehouse.
Probablemente, el 5% de usuarios que disponen de tecnología de Data Warehouse y piensan renunciar a ella en el futuro, no han realizado previamente un estudio de factores implicados en un Data Warehouse, o han pasado por la situación inicial de partida, y no se han planteado una reorganización del mismo.
2.2.2.- COMPONENTES A TENER EN CUENTA A LA HORA DE CONSTRUIR UN DW
2.2.2.1.-Hardware
Un componente fundamental a la hora de poder contar con un Data Warehouse que responda a las necesidades analíticas avanzadas de los usuarios, es el poder contar con una infraestructura hardware que la soporte.
En este sentido son críticas, a la hora de evaluar uno u otro hardware, dos características principales:
Por un lado, a este tipo de sistemas suelen acceder pocos usuarios con unas necesidades muy grandes de información, a diferencia de los sistemas operacionales, con muchos usuarios y necesidades puntuales de información. Debido a la flexibilidad requerida a la hora de hacer consultas complejas e imprevistas, y al gran tamaño de información manejada, son necesarias unas altas prestaciones de la máquina.
Por otro lado, debido a que estos sistemas suelen comenzar con una funcionalidad limitada, que se va expandiendo con el tiempo (situación por cierto aconsejada), es necesario que los sistemas sean escalables para dar soporte a las necesidades crecientes de equipamiento. En este sentido, será conveniente el optar por una arquitectura abierta, que nos permita aprovechar lo mejor de cada fabricante.
En el mercado se han desarrollado tecnologías basadas en tecnología de procesamiento paralelo, dan el soporte necesario a las necesidades de altas prestaciones y escalabilidad de los Data Warehouse. Estas tecnologías son de dos tipos:
• SMP (Symmetric multiprocessing, o Multiprocesadores Simétricos): Los sistemas tienen múltiples procesadores que comparten un único bus y una gran memoria, repartiéndose los procesos que genera el sistema, siendo el sistema operativo el que gestiona esta distribución de tareas. Estos sistemas se conocen como arquitecturas de "casi todo compartido". El aspecto más crítico de este tipo de sistemas es el grado de rendimiento relativo respecto al número de procesadores presentes, debido a su creciente no lineal.
• MPP (Massively parallel processing, o Multiprocesadores Masivamente Paralelos): Es una tecnología que compite contra la SMP, en la que los sistemas suelen ser casi independientes comunicados por intercambiadores de alta velocidad que permiten gestionarlos como un único sistema. Se conocen por ello como arquitecturas de "nada compartido". Su escalabilidad es mayor que la de los SMP.
Según Meta Group, las tendencias de mercado indican que las arquitecturas SMP aportan normalmente suficientes características de escalabilidad, con una mayor oferta y un menor riesgo tecnológico. Sin embargo, cuando las condiciones de escalabilidad sean extremas, se puede plantear la opción MPP.
No obstante, se están produciendo avances significativos en arquitecturas SMP, que han logrado máquinas con un crecimiento lineal de rendimiento hasta un número de 64 procesadores.
Recomendamos desde estas páginas, la visita a la dirección Internet:
http://www.tpc.org/bench.results.html
en donde la Transaction Processing Council (de la que son miembros ALR, Amdahl, Bull, Compaq, Data General, Dell, Digital, Fujitsu, HP, IBM, Intergraph, NCR , Siemens-Nixdorf, Sun o Unisys), realiza una comparativa entre las máquinas de sus miembros, proporcionando para diferentes modelos y diferentes configuraciones de Sistemas Operativos y Software de Base de Datos, un análisis de rendimiento (throughput), y un resumen de características (precio, número de procesadores, arquitectura y futuras versiones y fecha de disponibilidad).
2.2.2.2.-Software de almacenamiento (SGBD)
Como hemos comentado, el sistema que gestione el almacenamiento de la información (Sistema de Gestión de Base de Datos o SGBD), es otro elemento clave en un Data Warehouse. Independientemente de que la información almacenada en el Data Warehouse se pueda analizar mediante visualización multidimensional, el SGBD puede estar realizado utilizando tecnología de Bases de Datos Relacionales o Multidimensionales.
Las bases de datos relacionales, se han popularizado en los sistemas operacionales, pero se han visto incapaces de enfrentarse a las necesidades de información de los entornos Data Warehouse. Por ello, y puesto que, como hemos comentado, las necesidades de información suelen atender a consultas multidimensionales, parece que unas Bases de Datos multidimensionales, parten con ventaja. En este sentido son de aplicación los comentarios que realizamos en el apartado de hardware, por requerimientos de prestaciones, escalabilidad y consolidación tecnológica.
Al igual que en el hardware, nuevos diseños de las bases de datos relacionales, las bases de datos post-relacionales, abren un mayor abanico de elección. Estas bases de datos post-relacionales, parten de una tecnología consolidada y dan respuesta al agotamiento de las posibilidades de los sistemas de gestión de bases de datos relacionales, ofreciendo las mismas prestaciones aunque implantadas en una arquitectura diseñada de forma más eficiente.
Esta mayor eficiencia se consigue instaurando relaciones lógicas en vez de físicas, lo que hace que ya no sea necesario destinar más hardware a una solución para conseguir la ejecución de las funciones requeridas. El resultado es que la misma aplicación implantada en una BD post-relacional requiere menos hardware, puede dar servicio a un mayor número de usuarios y utilizar mecanismos intensivos de acceso a los datos más complejos. Asimismo, esta tecnología permite combinar las ventajas de las bases de datos jerárquicas y las relacionales con un coste más reducido. Ambos sistemas aportan como ventaja que no resulta necesario disponer de servidores omnipotentes, sin que puede partirse de un nivel de hardware modesto y ampliarlo a medida que crecen las necesidades de información de la compañía y el uso efectivo del sistema.
Dejamos fuera del ámbito de esta guía el detallar cómo los proveedores de bases de datos han optimizado los accesos a los índices, o las nuevas posibilidades que ofrece la compresión de datos (menos espacio para la misma información lo que implica, entre otras ventajas, que más información se puede tener en caché), para lo que remitimos a la prensa especializada o a las publicaciones de los fabricantes.
2.2.2.3.- Software de extracción y manipulación de datos
En este apartado analizaremos un componente esencial a la hora de implantar un Data Warehouse, la extracción y manipulación. Para esta labor, que entra dentro del ámbito de los profesionales de tecnologías de la información, es crítico el poder contar con herramientas que permitan controlar y automatizar los continuos "mimos" y necesidades de actualización del Data Warehouse.
Estas herramientas deberán proporcionar las siguientes funcionalidades:
• Control de la extracción de los datos y su automatización, disminuyendo el tiempo empleado en el descubrimiento de procesos no documentados, minimizando el margen de error y permitiendo mayor flexibilidad.
• Acceso a diferentes tecnologías, haciendo un uso efectivo del hardware, software, datos y recursos humanos existentes.
• Proporcionar la gestión integrada del Data Warehouse y los Data Marts existentes, integrando la extracción, transformación y carga para la construcción del Data Warehouse corporativo y de los Data Marts.
• Uso de la arquitectura de metadatos, facilitando la definición de los objetos de negocio y las reglas de consolidación.
• Acceso a una gran variedad de fuentes de datos diferentes.
• Manejo de excepciones.
• Planificación, logs, interfaces a schedulers de terceros.
• Interfaz independiente de hardware.
• Soporte en la explotación del Data Warehouse.
A veces, no se suele prestar la suficiente atención a esta fase de la gestión del Data Warehouse, aun cuando supone una gran parte del esfuerzo en la construcción de un Data Warehouse. Existen multitud de herramientas disponibles en el mercado que automatizan parte del trabajo, para lo cual recomendamos la visita a la página Internet:
http://pwp.starnetinc.com/larryg/clean.html
en la que se proporciona una lista de mas de 100 herramientas de extracción y manipulación de datos, con links a sus páginas Internet, y una somera descripción de la funcionalidad cubierta por cada herramienta.
2.2.2.4.- Herramientas Middleware
Como herramientas de soporte a la fase de gestión de un Data Warehouse, analizaremos a continuación dos tipos de herramientas:
• Por un lado herramientas Middleware, que provean conectividad entre entornos diferentes, para ayudar en la gestión del Data Warehouse.
• Por otro, analizadores y aceleradores de consultas, que permitan optimizar tiempos de respuestas en las necesidades analíticas, o de carga de los diferentes datos desde los sistemas operacionales hasta el Data Warehouse.
Las herramientas Middleware deben ser escalables siendo capaces de crecer conforme crece el Data Warehouse, sin problemas de volúmenes. Tambien deben ser flexibles y robustas, sin olvidarse de proporcionar un rendimiento adecuado. Estarán abiertas a todo tipos de entornos de almacenamiento de datos, tanto mediante estándares de facto (OLE, ODBC, etc.), como a los tipos de mercado más populares (DB2, Access, etc.). La conectividad, al menos en estándares de transporte (SNA LU6.2, DECnet, etc.) debe estar tambien asegurada.
Con el uso de estas herramientas de Middleware lograremos:
• Maximizar los recursos ejecutando las aplicaciones en la plataforma más adecuada.
• Integrar los datos y aplicaciones existentes en una plataforma distribuida.
• Automatizar la distribución de datos y aplicaciones desde un sistema centralizado.
• Reducir tráfico en la red, balanceando los niveles de cliente servidor (mas o menos datos en local, mas o menos proceso en local).
• Explotar las capacidades de sistemas remotos sin tener que aprender multiples entornos operativos.
• Asegurar la escalabilidad del sistema.
• Desarrollar aplicaciones en local y explotarlas en el servidor.
Los analizadores y aceleradores de querys trabajan volcando sobre un fichero de log las consultas ejecutadas y datos asociados a las mismas (tiempo de respuesta, tablas accedidas, método de acceso, etc). Este log se analiza, bien automáticamente o mediante la supervisión del administrador de datos, para mejorar los tiempos de accesos.
Estos sistemas de monitorización se pueden implementar en un entorno separado de pruebas, o en el entorno real. Si se ejecutan sobre un entorno de pruebas, el rendimiento del entorno real no se vé afectado. Sin embargo, no es posible optimizar los esfuerzos, puesto que los análisis efectuados pueden realizarse sobre consultas no críticas o no frecuentemente realizadas por los usuarios.
El implantar un sistema analizador de consultas, en el entorno real tiene además una serie de ventajas tales como:
• Se pueden monitorizar los tiempos de respuesta del entorno real.
• Se pueden implantar mecanismos de optimización de las consultas, reduciendo la carga del sistema.
• Se puede imputar costes a los usuarios por el coste del Data Warehouse.
• Se pueden implantar mecanismos de bloqueo para las consultas que vayan a implicar un tiempo de respuesta excesivo.
2.2.3.- FASES DE IMPLANTACIÓN DE UN DATA WAREHOUSE
Tal y como aparecía en un artículo en ComputerWorld: "Un Data Warehouse no se puede comprar, se tiene que construir". Como hemos mencionado con anterioridad, la construcción e implantación de un Data Warehouse es un proceso evolutivo.
Este proceso se tiene que apoyar en una metodología específica para este tipo de procesos, si bien es más importante que la elección de la mejor de las metodologías, el realizar un control para asegurar el seguimiento de la misma.
En las fases que se establezcan en el alcance del proyecto es fundamental el incluir una fase de formación en la herramienta utilizada para un máximo aprovechamiento de la aplicación. El seguir los pasos de la metodología y el comenzar el Data Warehouse por un área específica de la empresa, nos permitirá obtener resultados tangibles en un corto espacio de tiempo.
Planteamos aquí la metodología propuesta por SAS Institute: la "Rapid Warehousing Methodology". Dicha metodología es iterativa, y está basada en el desarrollo incremental del proyecto de Data Warehouse dividido en cinco fases:
• Definición de los objetivos
• Definición de los requerimientos de información
• Diseño y modelización
• Implementación
• Revisión
2.2.3.1-Definición de los objetivos
2.2.3.2.-Definición de los requerimientos de información
Tal como sucede en todo tipo de proyectos, sobre todo si involucran técnicas novedosas como son las relativas al Data Warehouse, es analizar las necesidades y hacer comprender las ventajas que este sistema puede reportar.
Es por ello por lo que nos remitimos al apartado de esta guía de Análisis de las necesidades del comprador. Será en este punto, en donde detallaremos los pasos a seguir en un proyecto de este tipo, en donde el usuario va a jugar un papel tan destacado.
2.2.3.3.-Diseño y modelización
Los requerimientos de información identificados durante la anterior fase proporcionarán las bases para realizar el diseño y la modelización del Data Warehouse.
En esta fase se identificarán las fuentes de los datos (sistema operacional, fuentes externas,..) y las transformaciones necesarias para, a partir de dichas fuentes, obtener el modelo lógico de datos del Data Warehouse. Este modelo estará formado por entidades y relaciones que permitirán resolver las necesidades de negocio de la organización.
El modelo lógico se traducirá posteriormente en el modelo físico de datos que se almacenará en el Data Warehouse y que definirá la arquitectura de almacenamiento del Data Warehouse adaptándose al tipo de explotación que se realice del mismo.
La mayor parte estas definiciones de los datos del Data Warehouse estarán almacenadas en los metadatos y formarán parte del mismo.
2.2.3.4.-Implementación
La implantación de un Data Warehouse lleva implícitos los siguientes pasos:
• Extracción de los datos del sistema operacional y transformación de los mismos.
• Carga de los datos validados en el Data Warehouse. Esta carga deberá ser planificada con una periodicidad que se adaptará a las necesidades de refresco detectadas durante las fases de diseño del nuevo sistema.
• Explotación del Data Warehouse mediante diversas técnicas dependiendo del tipo de aplicación que se de a los datos:
Query & Reporting
On-line analytical processing (OLAP)
Executive Information System (EIS) ó Información de gestión
Decision Support Systems (DSS)
Visualización de la información
Data Mining ó Minería de Datos, etc.
La información necesaria para mantener el control sobre los datos se almacena en los metadatos técnicos (cuando describen las características físicas de los datos) y de negocio (cuando describen cómo se usan esos datos). Dichos metadatos deberán ser accesibles por los usuarios finales que permitirán en todo momento tanto al usuario, como al administrador que deberá además tener la facultad de modificarlos según varíen las necesidades de información.
Con la finalización de esta fase se obtendrá un Data Warehouse disponible para su uso por parte de los usuarios finales y el departamento de informática.
2.2.3.5.-Revisión
La construcción del Data Warehouse no finaliza con la implantación del mismo, sino que es una tarea iterativa en la que se trata de incrementar su alcance aprendiendo de las experiencias anteriores.
Después de implantarse, debería realizarse una revisión del Data Warehouse planteando preguntas que permitan, después de los seis o nueve meses posteriores a su puesta en marcha, definir cuáles serían los aspectos a mejorar o potenciar en función de la utilización que se haga del nuevo sistema.
2.2.3.6.-Diseño de la estructura de cursos de formación
Con la información obtenida de reuniones con los distintos usuarios se diseñarán una serie de cursos a medida, que tendrán como objetivo el proporcionar la formación estadística necesaria para el mejor aprovechamiento de la funcionalidad incluida en la aplicación. Se realizarán prácticas sobre el desarrollo realizado, las cuales permitirán fijar los conceptos adquiridos y servirán como formación a los usuarios.
2.2.4.- ESTRATEGIAS DE IMPLANTACIÓN
Resaltamos en esta guía algunas consideraciones que recomendamos deben seguirse a la hora de abordar un proyecto de este tipo:
"La Base de Datos de Riesgos debe estar separada de las Bases de Datos Operacionales" con objeto de no interferir en la actividad del día a día, disponiendo de la información necesaria para Riesgos (interna y externa) y en un entorno orientado hacia la consulta y el análisis (Data Warehouse).
"Concepción del sistema como un conjunto de herramientas de análisis", debido a que las actividades de Análisis de Riesgos no se pueden automatizar completamente, puesto que requieren análisis y decisiones del usuario.
"Diseño del sistema no orientado a procesos"; se debe disponer de un conjunto abierto de herramientas que se utilizan con propósitos determinados no relacionados con las necesidades operativas.
"Abordar el sistema con un enfoque de desarrollo gradual", se debe comenzar con un esqueleto básico de funcionalidad y datos que produzcan resultados a corto plazo y permita aprender en la práctica, y a continuación ir configurando progresivamente nuevas funcionalidades conforme la experiencia lo vaya requiriendo.
Son de aplicación en este apartado las consideraciones que realizamos en los apartados Data Warehouse vs. Data Marts y Fases de Implantación de un Data Warehouse.
2.2.5.-TÉCNICAS DE EXPLOTACIÓN DE LA IMPLANTACIÓN
Dentro del esquema de Gestión y Explotación del Data Warehouse que se muestra en el gráfico, pasamos a detallar las posibilidades que nos ofrece esta última fase.
En ella, examinaremos
1. el uso que se puede realizar de las utilidades OLAP del Data Warehouse para análisis multidimensionales,
2. las facilidades de obtención de información mediante consultas e informes libre, y el uso de técnicas de Data Mining que nos permitan descubrir "información oculta" en los datos mediante el uso de técnicas estadísticas.
2.2.5.1.- OLAP, ROLAP, MOLAP
La explotación del Data Warehouse mediante información de gestión, se fundamenta básicamente en los niveles agrupados o calculados de información.
La información de gestión se compone de conceptos de información y coeficientes de gestión, que los cuadros directivos de la empresa pueden consultar según las dimensiones de negocio que se definan.
Dichas dimensiones de negocio se estructuran a su vez en distintos niveles de detalle (por ejemplo, la dimensión geográfica puede constar de los niveles nacional, provincial, ayuntamientos y sección censal).
Este tipo de sistemas ha existido desde hace tiempo, en el mundo de la informática bajo distintas denominaciones: cuadros de mando, MIS, EIS, etc.
Su realización fuera del entorno del Data Warehouse, puede repercutir sobre estos sistemas en una mayor rigidez, dificultad de actualización y mantenimiento, malos tiempos de respuesta, incoherencias de la información, falta del dato agregado, etc.
Los sistemas de soporte a la decisión usando tecnologías de Data Warehouse, se llaman sistemas OLAP (siglas de On Line Analytical Processing (OLAP). En general, estos sistemas OLAP deben:
• Soportar requerimientos complejos de análisis
• Analizar datos desde diferentes perspectivas
• Soportar análisis complejos contra un volumen ingente de datos
La funcionalidad de los sistemas OLAP se caracteriza por ser un análisis multidimensional de datos corporativos, que soportan los análisis del usuario y unas posibilidades de navegación, seleccionando la información a obtener.
Normalmente este tipo de selecciones se ve reflejada en la visualización de la estructura multidimensional, en unos campos de selección que nos permitan elegir el nivel de agregación (jerarquía) de la dimensión, y/o la elección de un dato en concreto, la visualización de los atributos del sujeto, frente a una(s) dimensiones en modo tabla, pudiendo con ello realizar, entre otras las siguientes acciones:
Rotar (Swap): alterar las filas por columnas (permutar dos dimensiones de análisis)
Bajar (Down): bajar el nivel de visualización en las filas a una jerarquía inferior
Detallar (Drilldown): informar para una fila en concreto, de datos a un nivel inferior
Expandir (Expand): id. anterior sin perder la información a nivel superior para éste y el resto de los valores
Colapsar (Collapse): operación inversa de la anterior.
Para ampliar el glosario sobre exploraciones en análisis OLAP, recomendamos la visita a la página Internet:
http://www.kenan.com/acumate/olaptrms.htm
en donde se describen en torno a 50 términos relacionados con las posibilidades de navegación que permiten este tipo de análisis.
Existen dos arquitecturas diferentes para los sistemas OLAP: OLAP multidimensional (MOLAP) y OLAP relacionales (ROLAP).
2.2.5.1.1.-Sistemas MOLAP
La arquitectura MOLAP usa unas bases de datos multidimensionales para proporcionar el análisis, su principal premisa es que el OLAP está mejor implantado almacenando los datos multidimensionalmente. Por el contrario, la arquitectura ROLAP cree que las capacidades OLAP están perfectamente implantadas sobre bases de datos relacionales
Un sistema MOLAP usa una base de datos propietaria multidimensional, en la que la información se almacena multidimensionalmente, para ser visualizada multidimensionalmente.
El sistema MOLAP utiliza una arquitectura de dos niveles: La bases de datos multidimensionales y el motor analítico.
• La base de datos multidimensional es la encargada del manejo, acceso y obtención del dato.
• El nivel de aplicación es el responsable de la ejecución de los requerimientos OLAP. El nivel
de presentación se integra con el de aplicación y proporciona un interfaz a través del cual
los usuarios finales visualizan los análisis OLAP. Una arquitectura cliente/servidor permite a varios usuarios
acceder a la misma base de datos multidimensional.
La información procedente de los sistemas operacionales, se carga en el sistema MOLAP, mediante una serie de rutinas batch. Una vez cargado el dato elemental en la Base de Datos multidimensional (MDDB), se realizan una serie de cálculos en batch, para calcular los datos agregados, a través de las dimensiones de negocio, rellenando la estructura MDDB.
Tras rellenar esta estructura, se generan unos índices y algoritmos de tablas hash para mejorar los tiempos de accesos a las consultas.
Una vez que el proceso de compilación se ha acabado, la MDDB está lista para su uso. Los usuarios solicitan informes a través del interface, y la lógica de aplicación de la MDDB obtiene el dato.
La arquitectura MOLAP requiere unos cálculos intensivos de compilación. Lee de datos precompilados, y tiene capacidades limitadas de crear agregaciones dinámicamente o de hallar ratios que no se hayan precalculados y almacenados previamente.
2.2.5.1.2.-Sistemas ROLAP
La arquitectura ROLAP, accede a los datos almacenados en un Data Warehouse para proporcionar los análisis OLAP. La premisa de los sistemas ROLAP es que las capacidades OLAP se soportan mejor contra las bases de datos relacionales.
El sistema ROLAP utiliza una arquitectura de tres niveles. La base de datos relacional maneja los requerimientos de almacenamiento de datos, y el motor ROLAP proporciona la funcionalidad analítica.
• El nivel de base de datos usa bases de datos relacionales para el manejo, acceso y obtención del dato.
• El nivel de aplicación es el motor que ejecuta las consultas multidimensionales de los usuarios.
• El motor ROLAP se integra con niveles de presentación, a través de los cuales los usuarios realizan
los análisis OLAP.
Después de que el modelo de datos para el Data Warehouse se ha definido, los datos se cargan desde el sistema operacional. Se ejecutan rutinas de bases de datos para agregar el dato, si así es requerido por el modelos de datos.
Se crean entonces los índices para optimizar los tiempos de acceso a las consultas.
Los usuarios finales ejecutan sus análisis multidimensionales, a través del motor ROLAP, que transforma dinámicamente sus consultas a consultas SQL. Se ejecutan estas consultas SQL en las bases de datos relacionales, y sus resultados se relacionan mediante tablas cruzadas y conjuntos multidimensionales para devolver los resultados a los usuarios.
La arquitectura ROLAP es capaz de usar datos precalculados si estos están disponibles, o de generar dinámicamente los resultados desde los datos elementales si es preciso. Esta arquitectura accede directamente a los datos del Data Warehouse, y soporta técnicas de optimización de accesos para acelerar las consultas. Estas optimizaciones son, entre otras, particionado de los datos a nivel de aplicación, soporte a la desnormalización y joins múltiples.
2.2.5.1.3.-ROLAP vs. MOLAP (Comparativa)
Cuando se comparan las dos arquitecturas, se pueden realizar las siguientes observaciones:
• El ROLAP delega la negociación entre tiempo de respuesta y el proceso batch al diseño del sistema.
Mientras, el MOLAP, suele requerir que sus bases de datos se precompilen para conseguir un rendimiento aceptable
en las consultas, incrementando, por tanto los requerimientos batch.
• Los sistemas con alta volatilidad de los datos (aquellos en los que cambian las reglas de agregación
y consolidación), requieren una arquitectura que pueda realizar esta consolidación ad-hoc. Los sistemas
ROLAP soportan bien esta consolidación dinámica, mientras que los MOLAP están más orientados
hacia consolidaciones batch.
• Los ROLAP pueden crecer hasta un gran número de dimensiones, mientras que los MOLAP generalmente son
adecuados para diez o menos dimensiones.
• Los ROLAP soportan análisis OLAP contra grandes volúmenes de datos elementales, mientras que
los MOLAP se comportan razonablemente en volúmenes más reducidos (menos de 5 Gb)
Por ello, y resumiendo, el ROLAP es una arquitectura flexible y general, que crece para dar soporte a amplios requerimientos OLAP. El MOLAP es una solución particular, adecuada para soluciones departamentales con unos volúmenes de información y número de dimensiones más modestos.
2.2.5.2.- QUERY & REPORTING
Las consultas o informes libres trabajan tanto sobre el detalle como sobre las agregaciones de la información.
Realizar este tipo de explotación en un almacén de datos supone una optimización del tradicional entorno de informes (reporting), dado que el Data Warehouse mantiene una estructura y una tecnología mucho más apropiada para este tipo de solicitudes.
Los sistemas de "Query & Reporting", no basados en almacenes de datos se caracterizan por la complejidad de las consultas, los altísimos tiempos de respuesta y la interferencia con otros procesos informáticos que compartan su entorno.
La explotación del Data Warehouse mediante "Query & Reporting" debe permitir una gradación de la flexibilidad de acceso, proporcional a la experiencia y formación del usuario. A este respecto, se recomienda el mantenimiento de al menos tres niveles de dificultad:
• Los usuarios poco expertos podrán solicitar la ejecución de informes o consultas predefinidas según unos parámetros predeterminados.
• Los usuarios con cierta experiencia podrán generar consultas flexibles mediante una aplicación que proporcione una interfaz gráfica de ayuda.
• Los usuarios altamente experimentados podrán escribir, total o parcialmente, la consulta en un lenguaje de interrogación de datos.
Hay una extensa gama de herramientas en el mercado para cumplir esta funcionalidad sobre entornos de tipo Data Warehouse, por lo que se puede elegir el software más adecuado para cada problemática empresarial concreta.
2.2.5.3.- DATA MINING O MINERÍA DE DATOS
El Data Mining es un proceso que, a través del descubrimiento y cuantificación de relaciones predictivas en los datos, permite transformar la información disponible en conocimiento útil de negocio. Esto es debido a que no es suficiente "navegar" por los datos para resolver los problemas de negocio, sino que se hace necesario seguir una metodología ordenada que permita obtener rendimientos tangibles de este conjunto de herramientas y técnicas de las que dispone el usuario.
Constituye por tanto una de las vías clave de explotación del Data Warehouse, dado que es este su entorno natural de trabajo.
Se trata de un concepto de explotación de naturaleza radicalmente distinta a la de los sistemas de información de gestión, dado que no se basa en coeficientes de gestión o en información altamente agregada, sino en la información de detalle contenida en el almacén. Adicionalmente, el usuario no se conforma con la mera visualización de datos, sino que trata de obtener una relación entre los mismos que tenga repercusiones en su negocio.
2.2.5.3.2.Técnicas de Data Mining
Para soportar el proceso de Data Mining, el usuario dispone de una extensa gama de técnicas que le pueden ayudar en cada una de las fases de dicho proceso, las cuales pasamos a describir:
Análisis estadístico:
Utilizando las siguientes herramientas:
1. ANOVA: o Análisis de la Varianza, contrasta si existen diferencias significativas entre las medidas de una o más variables continuas en grupo de población distintos.
2. Regresión: define la relación entre una o más variables y un conjunto de variables predictoras de las primeras.
3. Ji cuadrado: contrasta la hipótesis de independencia entre variables.
4. Componentes principales: permite reducir el número de variables observadas a un menor número de variables artificiales, conservando la mayor parte de la información sobre la varianza de las variables.
5. Análisis cluster: permite clasificar una población en un número determinado de grupos, en base a semejanzas y desemejanzas de perfiles existentes entre los diferentes componentes de dicha población.
6. Análisis discriminante: método de clasificación de individuos en grupos que previamente se han establecido, y que permite encontrar la regla de clasificación de los elementos de estos grupos, y por tanto identificar cuáles son las variables que mejor definan la pertenencia al grupo.
Métodos basados en árboles de decisión:
El método Chaid (Chi Squared Automatic Interaction Detector) es un análisis que genera un árbol de decisión para predecir el comportamiento de una variable, a partir de una o más variables predictoras, de forma que los conjuntos de una misma rama y un mismo nivel son disjuntos. Es útil en aquellas situaciones en las que el objetivo es dividir una población en distintos segmentos basándose en algún criterio de decisión.
El árbol de decisión se construye partiendo el conjunto de datos en dos o más subconjuntos de observaciones a partir de los valores que toman las variables predictoras. Cada uno de estos subconjuntos vuelve después a ser particionado utilizando el mismo algoritmo. Este proceso continúa hasta que no se encuentran diferencias significativas en la influencia de las variables de predicción de uno de estos grupos hacia el valor de la variable de respuesta.
La raíz del árbol es el conjunto de datos íntegro, los subconjuntos y los subsubconjuntos conforman las ramas del árbol. Un conjunto en el que se hace una partición se llama nodo.
El número de subconjuntos en una partición puede ir de dos hasta el número de valores distintos que puede tomar la variable usada para hacer la separación. La variable de predicción usada para crear una partición es aquella más significativamente relacionada con la variable de respuesta de acuerdo con test de independencia de la Chi cuadrado sobre una tabla de contingencia.
Algoritmos genéticos:
Son métodos numéricos de optimización, en los que aquella variable o variables que se pretenden optimizar junto con las variables de estudio constituyen un segmento de información. Aquellas configuraciones de las variables de análisis que obtengan mejores valores para la variable de respuesta, corresponderán a segmentos con mayor capacidad reproductiva. A través de la reproducción, los mejores segmentos perduran y su proporción crece de generación en generación. Se puede además introducir elementos aleatorios para la modificación de las variables (mutaciones). Al cabo de cierto número de iteraciones, la población estará constituida por buenas soluciones al problema de optimización.
Redes neuronales:
Genéricamente son métodos de proceso numérico en paralelo, en el que las variables interactúan mediante transformaciones lineales o no lineales, hasta obtener unas salidas. Estas salidas se contrastan con los que tenían que haber salido, basándose en unos datos de prueba, dando lugar a un proceso de retroalimentación mediante el cual la red se reconfigura, hasta obtener un modelo adecuado.
Lógica difusa:
Es una generalización del concepto de estadística. La estadística clásica se basa en la teoría de probabilidades, a su vez ésta en la técnica conjuntista, en la que la relación de pertenencia a un conjunto es dicotómica (el 2 es par o no lo es). Si establecemos la noción de conjunto borroso como aquel en el que la pertenencia tiene una cierta graduación (¿un día a 20ºC es caluroso?), dispondremos de una estadística más amplia y con resultados más cercanos al modo de razonamiento humano.
Series temporales:
Es el conocimiento de una variable a través del tiempo para, a partir de ese conocimiento, y bajo el supuesto de que no van a producirse cambios estructurales, poder realizar predicciones. Suelen basarse en un estudio de la serie en ciclos, tendencias y estacionalidades, que se diferencian por el ámbito de tiempo abarcado, para por composición obtener la serie original. Se pueden aplicar enfoques híbridos con los métodos anteriores, en los que la serie se puede explicar no sólo en función del tiempo sino como combinación de otras variables de entorno más estables y, por lo tanto, más fácilmente predecibles.
2.2.5.3.3. Metodología de aplicación:
Para utilizar estas técnicas de forma eficiente y ordenada es preciso aplicar una metodología estructurada, al proceso de Data Mining. A este respecto proponemos la siguiente metodología, siempre adaptable a la situación de negocio particular a la que se aplique:
Muestreo
Extracción de la población muestral sobre la que se va a aplicar el análisis. En ocasiones se trata de una muestra aleatoria, pero puede ser también un subconjunto de datos del Data Warehouse que cumplan unas condiciones determinadas. El objeto de trabajar con una muestra de la población en lugar de toda ella, es la simplificación del estudio y la disminución de la carga de proceso. La muestra más óptima será aquella que teniendo un error asumible contenga el número mínimo de observaciones.
En el caso de que se recurra a un muestreo aleatorio, se debería tener la opción de elegir
• El nivel de confianza de la muestra (usualmente el 95% o el 99%).
• El tamaño máximo de la muestra (número máximo de registros), en cuyo caso el sistema deberá informar del el error cometido y la representatividad de la muestra sobre la población original.
• El error muestral que está dispuesto a cometer, en cuyo caso el sistema informará del número de observaciones que debe contener la muestra y su representatividad sobre la población original.
Para facilitar este paso s debe disponer de herramientas de extracción dinámica de información con o sin muestreo (simple o estratificado). En el caso del muestreo, dichas herramientas deben tener la opción de, dado un nivel de confianza, fijar el tamaño de la muestra y obtener el error o bien fijar el error y obtener el tamaño mínimo de la muestra que nos proporcione este grado de error.
Exploración
Una vez determinada la población que sirve para la obtención del modelo se deberá determinar cuales son las variables explicativas que van a servir como "inputs" al modelo. Para ello es importante hacer una exploración por la información disponible de la población que nos permita eliminar variables que no influyen y agrupar aquellas que repercuten en la misma dirección.
El objetivo es simplificar en lo posible el problema con el fin de optimizar la eficiencia del modelo. En este paso se pueden emplear herramientas que nos permitan visualizar de forma gráfica la información utilizando las variables explicativas como dimensiones.
También se pueden emplear técnicas estadísticas que nos ayuden a poner de manifiesto relaciones entre variables. A este respecto resultará ideal una herramienta que permita la visualización y el análisis estadístico integrados
Manipulación
Tratamiento realizado sobre los datos de forma previa a la modelización, en base a la exploración realizada, de forma que se definan claramente los inputs del modelo a realizar (selección de variables explicativas, agrupación de variables similares, etc.).
Modelización
Permite establecer una relación entre las variables explicativas y las variables objeto del estudio, que posibilitan inferir el valor de las mismas con un nivel de confianza determinado.
Valoración
Análisis de la bondad del modelo contrastando con otros métodos estadísticos o con nuevas poblaciones muestrales.
2.2.5.4.- WEBHOUSING
La popularización de Internet y la tecnología Web, ha creado un nuevo esquema de información en el cual los clientes tienen a su disposición unas cantidades ingentes de información. La integración de las tecnologías Internet y Data Warehouse tienen una serie de ventajas como son:
• Consistencia: toda la organización accede al mismo conjunto de datos y ve los informes que reflejan
sus necesidades. Hay una "única versión de la verdad".
• Accesibilidad: la empresa acede a la información a través de un camino común (el browser
de Internet), simplificando el proceso de búsqueda de la información.
• Disponibilidad: la información es accesible en todo momento, independientemente de los sistemas operacionales.
• Bajos costes de desarrollo y mantenimiento, debidos a la estandarización de las aplicaciones de consultas
basadas en Internet, independientemente del sistema operativo que soporte el browser, y de la reducción
de los costes de distribución de software en los puestos clientes.
• Protección de los datos, debido al uso de tecnologías consolidadas de protección en entornos
de red (firewalls).
• Bajos costes de formación, debido al uso de interfaces tipo Web.
La interactividad de las aplicaciones en este entorno pueden tener varios niveles:
• Publicación de datos: las páginas distribuyen información obtenida del Data Warehouse,
volcada en las páginas intra/internet.
• Distribución de reportes: dando soporte a consultas simples elaboradas por los usuarios.
• Aplicaciones dinámicas: sirviendo de soporte de decisión a servicios solicitados desde el puesto
cliente, ejecutando la petición en el servidor y devolviéndolas al cliente, vía el browser
de Internet o haciendo uso de "applets" de Java.
Las arquitecturas base de una implantación de Data Warehouse en Internet, pueden tener las siguientes
alternativas:
1. Usar el Servidor Internet como router, y ejecutar la petición desde el cliente al servidor directamente.
2. Hacer uso del navegador para visualizar una página Internet residente en el servidor de Internet. Esta
página contendría información que se actualizaría en el servidor Internet, desde el
servidor DW, a petición del usuario haciendo uso de CGI's.
3. El cliente podría lanzar su consulta directamente al servidor de DW, con "applets" de Java,
haciendo el servidor Internet únicamente de encaminamiento (router).
4. El cliente podría ejecutar la aplicación DW desde el navegador, pero con un plug-in, que haría
que se tuvieran las mismas opciones que la aplicación DW.
5. Realizar una descarga masiva de datos con un protocolo de transferencia de ficheros (FTP), para su proceso
en local.
El alcance funcional de la implantación del Data Warehouse, basado en tecnologías Internet, puede ser la misma que la realizada sin su uso. En este sentido las críticas que se le pueden achacar en la actualidad, provienen de la baja velocidad de las líneas actuales, que se solventa parcialmente mediante el uso de aplicaciones Java, en lugar de hacer uso de páginas HTML, o CGI. Solución parcial, mientras la velocidad de transferencia se incrementa día a día mediante nuevos algoritmos de compresión de datos o el uso de líneas de alta capacidad RDSI.
2.2.6.- TIPOS DE APLICACIONES EN LAS QUE UTILIZAR LAS TÉCNICAS DISPONIBLES SOBRE EL DW
2.2.6.1. Data Warehouse y Sistemas de Marketing
La aplicación de tecnologías de Data Warehouse supone un nuevo enfoque de Marketing, haciendo uso del Marketing de Base de Datos. En efecto, un sistema de Marketing Warehouse implica un marketing científico, analítico y experto, basado en el conocimiento exhaustivo de clientes, productos, canales y mercado.
Este conocimiento se deriva de la disposición de toda la información necesaria, tanto interna como externa, en un entorno de Data Warehouse, persiguiendo con toda esta información, la optimización de las variables controladas del Marketing Mix y el soporte a la predicción de las variables no controlables (mediante técnicas de Data Mining). Basándose en el conocimiento exhaustivo de los clientes se consigue un tratamiento personalizado de los mismos tanto en el día a día (atención comercial) como en acciones de promoción específicas.
Las áreas en las que se puede aplicar las tecnologías de Data Warehouse a Marketing son, entre otras:
• Investigación Comercial
• Segmentación de mercados
• Identificación de necesidades no cubiertas y generación de nuevos productos, o modificación de productos existentes
• Fijación de precios y descuentos
• Definición de la estrategia de canales de comercialización y distribución
• Definición de la estrategia de promoción y atención al cliente
• Relación con el cliente:
• Programación, realización y seguimiento de acciones comerciales
• Lanzamiento de nuevos productos
• Campañas de venta cruzada, vinculación, fidelización, etc.
• Apoyo al canal de venta con información cualificada
2.2.6.2. Data Warehouse y Análisis de Riesgo Financiero
El Data Warehouse aplicado al análisis de riesgos financieros ofrece capacidades avanzadas de desarrollo de aplicaciones para dar soporte a las diversas actividades de gestión de riesgos. Es posible desarrollar cualquier herramienta utilizando las funciones que incorpora la plataforma, gracias a la potencionalidad estadística aplicada al riesgo de crédito.
Así se puede usar para llevar a cabo las siguientes funcionalidades:
• Para la gestión de la posición:
Determinación de la posición, Cálculo de sensibilidades, Análisis what/if, Simulaciones, Monitorización riesgos contra límites, etc.
• Para la medición del riesgo:
Soporte metodología RiskMetrics (Metodología registrada de J.P. Morgan / Reuters), Simulación de escenarios históricos, Modelos de covarianzas, Simulación de Montecarlo, Modelos de valoración, Calibración modelos valoración, Análisis de rentabilidad, Establecimiento y seguimiento. de límites, Desarrollo/modificación modelos, Stress testing, etc.
El uso del Data Warehouse ofrece una gran flexibilidad para creación o modificación de modelos propios de valoración y medición de riesgos, tanto motivados por cambios en la regulación, como en avances en la modelización de estos instrumentos financieros.
Ello por cuanto se puede almacenar y poner a disposición información histórica de mercado y el uso de técnicas de Data Mining nos simplifica la implantación de cualquier método estadístico. Los métodos de previsión, se pueden realizar usando series históricas, (GARCH, ARIMA, etc.)
Pero la explotación de la información nos permite no solo la exploración de los datos para un conocimiento de la información histórica, sino también para examinar condiciones de normalidad de las que la mayoría de las metodologías de valoración del riesgo parten.
Además de implantar modelos ya existentes, se pueden acometer análisis con vistas a determinar modelos propios, basados en análisis de correlación para el estudio de la valoración del riesgo de carteras o procesos de simulación de Montecarlo.
Todo ello en una plataforma avanzada de gestión de la información basada en la fácil visualización de la misma y de su análisis estadístico como soporte a metodologías estándar de facto, o a las particularidades de cada entorno.
2.2.6.3. Data Warehouse y Análisis de Riesgo de Crédito
La información relativa a clientes y su entorno se ha convertido en fuente de prevención de Riesgos de Crédito. En efecto, existe una tendencia general en todos los sectores a recoger, almacenar y analizar información crediticia como soporte a la toma de decisiones de Análisis de Riesgos de Crédito.
Los avances en la tecnología de Data Warehouse hacen posible la optimización de los sistemas de Análisis de Riesgo de Crédito:
Para la gestión del riesgo de crédito los sistemas operacionales han ofrecido:
• Sistemas de Información para Gerencia (MIS) e informes de Soporte a la Decisión de Problemas (DSS) estáticos y no abiertos a nuevas relaciones y orígenes de datos, situación en la que la incorporación de nuevas fuentes de información ha sido un problema en lugar de una ventaja.
• Exploraciones de datos e informes cerrados y estáticos.
• Análisis sin inclusión de consideraciones temporales lo que imposibilita el análisis del pasado y la previsión del futuro.
• Herramientas de credit-scoring no flexibles, construidas sobre algoritmos difícilmente modificables, no adaptados al entorno de la empresa, o exclusivamente basados en la experiencia personal no contrastada, con lo que los sistemas han ayudado a repetir los errores en vez de a corregirlos.
Pero estos sistemas tradicionales se enfrentan a una problemática difícil de resolver para acomodarse a las necesidades analíticas de los Sistemas de Análisis del Riesgo, necesidades que se pueden cubrir mediante el uso de tecnologías de Data Warehouse
Dentro de la Prevención de Impagados, utilizando sistemas OLAP se puede obtener el grado interno de concentración de riesgos con el cliente, y almacenar la variedad de fuentes internas o externas de información disponibles sobre el mismo. Ello nos permite obtener sin dificultad la posición consolidada respecto al riesgo del cliente. El análisis se puede realizar asimismo por las diferentes características de la operación para la que se realiza el análisis, en cuanto al plazo y la cuantía de la misma, la modalidad de crédito elegida, la finalidad de la operación o las garantías asociadas a la misma. Usando las mismas capacidades es fácil el establecer una segmentación ABC de la cartera de clientes potenciales o reales que nos optimicen el nivel de esfuerzo en el Análisis de Riesgos.
En el soporte al proceso de Anticipación al Riesgo, se puede dar un adecuado soporte a la correcta generación y consideración de señales de alerta, teniendo en cuenta las pautas y condicionantes diferenciados dependiendo del tipo de cliente y producto usando Data Mining
Para el caso del Seguimiento del ciclo de Impagados, de nuevo el uso de sistemas OLAP, simplifican el análisis la diversidad de los diferentes parámetros que intervienen en el mismo, tales como la jerarquía de centros de recobro a contemplar, la diferente consideración dependiendo de la antigüedad del impago, del cliente o del importe impagado. Un sistema de Data Mining puede aconsejar la mejor acción en caso de impagados, litigio, precontencioso, etc. frente a los parámetros de importe, antigüedad, zona geográfica, etc.
Estos sistemas hacen que el analista se dedique con más intensidad al análisis de la información, que es donde aporta su mayor valor añadido, que a la obtención de la misma. No obstante, estos sistemas deben de huir de las automatizaciones completas sin intervención del analista: es él el que mejor sabe lo que quiere descubrir. "La herramienta debe ser un medio y no un fin".
2.2.6.4. Data Warehouse: Otras áreas de aplicación
Otras áreas de la empresa han aplicado las soluciones que proporciona la tecnología Data Warehouse para mejorar gran parte de sus procesos actuales. Entre ellas destacamos:
• Control de Gestión:
Sistemas de Presupuestación, Análisis de Desviaciones, Reporting (EIS, MIS, etc.)
• Logística:
Mejora de la relación con proveedores, Racionalización de los procesos de control de inventarios, Optimización de los niveles de producción, Previsión de la demanda en infraestructura.
• Recursos Humanos
Planificación de incorporaciones, Gestión de carreras profesionales, Asignación de recursos a proyectos alternativos, etc.
2.2.7.- SEGURIDAD DE ACCESO Y MANIPULACIÓN DE LA INFORMACIÓN EN EL DW
A continuación trataremos las consideraciones a contemplar en cuanto a seguridad de accesos y seguridad de datos (backup), puesto que si bien la seguridad de accesos (al nivel de datos y de aplicación) debe ser tratada de la misma manera que en los sistemas operacionales, los procedimientos de copias de seguridad merecen un especial tratamiento.
Tal y como ocurre en los sistemas operacionales, un sistema Data Warehouse debe poder realizar procedimientos de recuperación de la información desde cualquier momento en el que los datos estaban validados. Un Data Warehouse, debe poder contar con procedimientos de recuperación, que permitan recuperar los datos ante cualquier situación de catástrofe.
No obstante, es preciso tener en cuenta otras consideraciones, así por ejemplo dependiendo del tamaño de un Data Mart, se puede elegir no realizar un backup, sino realizar un refresco especial desde los datos operacionales, dependiendo de la periodicidad estándar de carga.
En cuanto a la seguridad de acceso, se cumple en los sistemas de Data Warehouse, que es preciso el implantar niveles de acceso a la información, realizando un plan completo de seguridad que contemple:
• Acceso a recursos de la red (local o intranet)
• Asignación de usuarios a grupos con perfiles de seguridad diferenciados
• Asignación de niveles de autorización de aplicación a grupos de usuarios
• Seguridad a nivel de Base de Datos, mediante los procedimientos provistos por las mismas.
• Etc.
2.3.- TENDENCIAS TECNOLÓGICAS Y DE MERCADO
Describimos a continuación una recopilación de las principales tendencias observadas en el mercado. Estas tendencias se han comentado con anterioridad en otros apartados de esta Guía y se hace referencia a dichos puntos.
Tendencias hacia herramientas especializados:
El uso de herramientras de propósito general no satisface por completo las necesidades de un proyecto de Data Warehouse. Se ha comentado en esta guía las Herramientas de usuario final y tecnológicas, en el que se muestran para cada paso de la creación de un Data Warehouse, una lista de los principales vendedores y sus direcciones Web.
Webhousing
El uso de Internet como fuente de información hacia el exterior e interior (via intranets), crece constantemente, y la integración de una herramienta de Data Warehouse con Internet, se comenta en el apartado de Webhousing
Uso generalizado de Data Marts
Las peculiaridades de un proyecto Data Warehouse, y el enfoque progresivo de su construcción, hace que cada vez mas organizaciones realicen sus desarrollos mediante el uso de Data Marts integrados, tal y como comentabamos en el apartado Data Warehouse vs. Data Mart
Uso de tecnología OLAP
Este aspecto está comentado con amplitud en el apartado OLAP, ROLAP, MOLAP
3.- ASPECTOS TÉCNICOS EN EL PROCESO DE CREACIÓN Y EXPLOTACIÓN DEL DW
En este capítulo se pretende dar la orientación suficiente al comprador para la preparación del conjunto de especificaciones que definirán los requisitos que han de cumplir la Creación y Explotación de un Data Warehouse.
Se realiza en primer lugar un análisis de las necesidades del comprador, a continuación se recogen los factores relevantes a tener en cuenta en el proceso de adquisición y, finalmente, se describe cómo deben ser planteadas las especificaciones técnico - funcionales para la elaboración del Pliego de Prescripciones Técnicas, qué normas, estándares y cláusulas tipo pueden ser de aplicación, y cuál es el cuestionario técnico diseñado para normalizar las ofertas y facilitar su evaluación.
3.1.- ANÁLISIS DE LAS NECESIDADES DEL COMPRADOR
Incluimos aquí unos pasos que, tal y como se comentaban en la Fases de implantación de un Data Warehouse , son previos al inicio de un proyecto de este tipo.
En efecto, como punto de arranque de todo, es preciso "vender la idea" a los usuarios finales de un Data Warehouse. Esto es así, por ser una idea bastante novedosa y sobre la que pueden surgir recelos de su efectividad. Estos recelos se pueden eliminar comenzando por un pequeño módulo, del cual se valoren los beneficios posteriores, para iniciar progresivamente el desarrollo de nuevos módulos, cada uno con un coste unitario cada vez más reducido, pero sin embargo con unos beneficios distribuidos cada vez mayores por poder cada vez incluir más información. (Ver Data Warehouse vs. Data Mart) para comprobar un caso de este tipo.
El simple hecho de realizar un informe de necesidades previas en el que se enumeren la situación de los datos entre los diversos sistemas operacionales, puede ser un hecho decisivo para emprender un proyecto de este tipo. Muchas veces la información existente se encuentra tan poco normalizada, existen tantas discrepancias entre estos sistemas, que el abordar un Data Warehouse en el que se limpien estos datos y se normalicen pueden aportar un valor intangible: "la calidad y fiabilidad de la información".
La venta de esta idea no sólo se ha de realizar frente a la Dirección sino que es preciso realizarla a todos los niveles: a la Dirección, Gerencia e incluso al área de Desarrollo.
Tras esta venta de la idea, comienzan dos fases similares al análisis de requisitos del sistema (ARS según abreviaturas de la metodología METRICA): la definición de objetivos y requerimientos de información, en el que se analicen las necesidades del comprador.
Definición de los objetivos
En esta fase se definirá el equipo de proyecto que debe estar compuesto por representantes del departamento informático y de los departamentos usuarios del Data Warehouse además de la figura de jefe de proyecto.
Se definirá el alcance del sistema y cuales son las funciones que el Data Warehouse realizará como suministrador de información de negocio estratégica para la empresa. Se definirán así mismo, los parámetros que permitan evaluar el éxito del proyecto.
Definición de los requerimientos de información
Durante esta fase se mantendrán sucesivas entrevistas con los representantes del departamento usuario final y los representantes del departamento de informática. Se realizará el estudio de los sistemas de información existentes, que ayudaran a comprender las carencias actuales y futuras que deben ser resueltas en el diseño del Data Warehouse
Asimismo, en esta fase el equipo de proyecto debe ser capaz de validar el proceso de entrevistas y reforzar la orientación de negocio del proyecto. Al finalizar esta fase se obtendrá el documento de definición de requerimientos en el que se reflejarán no solo las necesidades de información de los usuarios, sino cual será la estrategia y arquitectura de implantación del Data Warehouse.
3.2.- FACTORES RELEVANTES EN EL PROCESO DE ADQUISICIÓN
En la definición del objeto del contrato y los requisitos inherentes al mismo, así como en la valoración y comparación de ofertas de los licitadores pueden intervenir muchos factores y de muy diversa índole.
Es de suma importancia que todos los factores relevantes que intervienen en el proceso de contratación queden debidamente recogidos en el pliego de prescripciones técnicas que regule el contrato. Así mismo, es conveniente que las soluciones ofertadas por los licitadores sean recogidas en los cuestionarios disponibles a tal efecto:
• De empresa
• Económicos
• Técnicos particulares
Se van a relacionar a continuación algunos de los factores que suelen tener mayor peso al seleccionar una herramienta de Data Warehouse. Sin embargo, debe tenerse en cuenta que la importancia de cada factor variará en función de cada caso particular, por lo que siempre será necesario identificar la importancia relativa de cada punto. Los puntos a contemplar son bastante similares a los contemplados en el apartado homónimo de los SGBD, que adaptaremos a la casuística particular de un Data Warehouse.
Pruebas en condiciones reales
Tal y como sucedía en los SGBD, el rendimiento real de un Data Warehouse es muy difícil de predecir mediante procedimientos teóricos. Por ello, de igual forma que en el SGBD, si se va a instalar un Data Warehouse que contendrá un gran volumen de datos o, si por cualquier otra razón, existen dudas sobre la capacidad del Data Warehouse de dar unas prestaciones adecuadas en las máquinas disponibles se debe exigir al suministrador una prueba anterior a la adquisición del Data Warehouse. Esta prueba debe realizarse en la propia instalación de destino.
La prueba se debería realizar en las condiciones más parecidas a las reales que se puedan conseguir. Para ello se deberá cargar el Data Warehouse con un volumen de datos adecuado y se deberán crear procesos de prueba similares a los más costosos de los que se vayan a desarrollar.
A diferencia de con los SGBD, no es preciso realizar la prueba en momentos de gran carga, por la diferente filosofía de un almacén de datos orientado al conocimiento, pero sí que será preciso la comprobación de la compatibilidad de la herramienta para los procesos de extracción y carga desde los diferentes sistemas operacionales (sistemas operativos, bases de datos, etc.) implicados .
Volumen y organización de los datos
Debe estar garantizado que el Data Warehouse es capaz de tratar el volumen de datos que se vaya a necesitar en la instalación. Para ello debe verificarse no sólo que el Data Warehouse puede manejar el volumen total de datos, sino que no existe ninguna limitación que impide organizarlo de la forma más conveniente.
No obstante, en este sentido y como factor común de un SGBD con un Data Warehouse, cabe reseñar que muchos problemas de rendimiento se deben más veces a un mal diseño del modelo de datos del Data Warehouse que a un problema de rendimiento de la herramienta en sí.
Dimensionamiento de la plataforma de instalación
De lo comentado en los dos puntos anteriores puede deducirse que existe la posibilidad de que sea necesario redimensionar la máquina en la que se instale el Data Warehouse, o mejor aun, disponer de una dedicada al Data Warehouse.
Es necesario que el suministrador detalle cual de las dos versiones está ofreciendo para cada una de las licencias que se compren y si alguna de ellas fuese una versión limitada, que especifique claramente cuales de las funcionalidades ofertadas no se encuentran presentes en la versión restringida.
Condiciones económicas y del soporte
Existen actualmente varios sistemas de cobro por el uso de Data Warehouse según el fabricante. Los más utilizados son facturar por:
• Cada máquina y/o tipo de máquina en la que se instale.
• Cada usuario que acceda al SGBD.
• Por tiempo de utilización (usualmente renovación anual).
• Por combinación de las anteriores.
Es imprescindible que el suministrador indique con toda claridad el método utilizado.
También debe explicitarse que, salvo indicación en contrario, todas las licencias son de versiones completas sin ninguna restricción respecto a las funcionalidades ofertadas.
También es conveniente pedir los precios de los productos adicionales que no se desee instalar en el momento pero que puedan ser interesantes en el futuro.
Otro factor importante es la duración de la garantía, período de tiempo durante el que el suministrador proporcionará soporte gratuito a sus productos y, también el precio del soporte en años sucesivos. Este último precio debe fijarse sobre variables presentes en el contrato no sobre futuros precios de lista del fabricante.
Otro factor que debe evaluarse es la calidad del soporte ofrecido. Este puede dividirse en un gran número de puntos cuya importancia variará en función de las necesidades del comprador. Entre ellos, se pueden citar:
• La inclusión o no de la instalación en el precio del producto.
• El tiempo máximo de entrega.
• La inclusión o no de prestaciones adicionales gratuitas como puede ser un cierto número de horas de formación.
• Capacitación y experiencia del personal que presta soporte técnico y consultoría.
• Calidad de la documentación, idioma en que está escrita, número de copias suministradas gratuitamente y precio de las copias adicionales.
• Capacidad técnica de la empresa y de la asistencia técnica que presta para lo que es recomendable pedir referencias a otros usuarios de la Administración de este tipo de productos.
3.3.- DISEÑO DEL PLIEGO DE PRESCRIPCIONES TÉCNICAS PARTICULARES
Debido a la no existencia de ninguna norma o estándar aplicable a un Data Warehouse, mas que estándares de facto, describimos a continuación cuestionarios técnicos de normalización y valoración de ofertas de SGBD.
Estos cuestionarios han de partir de unas especificaciones previas de:
Entorno Hardware:
Host: (Tipo Máquina, Sistema Operativo y Base de Datos Operacional)
Servidor de la aplicación de DW (Tipo Máquina, Nº procesadores, Memoria total y por procesador, Sistema Operativo, Capacidad de Disco)
Clientes (Tipo de Máquina, Memoria, Sistema Operativo, Capacidad de Disco)
Red local (Topología, Protocolos, Sofware de Cliente y Número de Usuarios soportados)
Entorno Software:
Gestor de Base de Datos para el Data Warehouse
Volumen estimado de la Base de Datos
A continuación y dependiendo del ámbito de aplicación del Data Warehouse describimos un cuestionario aplicado a la creación del Data Warehouse por un lado, por otro del Análisis de la Calidad del dato y la depuración, y por último de su Explotación.
3.3.1.- CUESTIONARIO PARA LA EXTRACCIÓN, MOVIMIENTO Y CARGA
Con carácter general y a fin de utilizar la información recopilada de cara a la contratación, es importante destacar que los datos recogidos en este cuestionario están dirigidos a obtener un resumen estructurado de la oferta y a demostrar la solvencia técnica o profesional de la empresa en aquellos casos en que no sea requerida la clasificación de la misma. Dicha información sólo servirá de base a la valoración cuando esté relacionada con lo expresado en la cláusula "Criterios de adjudicación del contrato", siendo, en el resto de los casos, de carácter meramente informativo.
Nota: (*) significa que hay que indicar "1" en caso afirmativo.
(**) significa que hay que repetir para cada sistema operativo ofertado.
Cuestión Respuesta Referencia a
oferta (Página)
------------------------------------------
ENTORNO OPERATIVO
- REQUERIMIENTOS LÓGICOS
. Especificar para cada uno de las paquetes software ofertados la o las posibles
plataformas (servidor central, servidor intermedio y cliente) donde podrían instalarse, detallando los requerimientos
físicos y lógicos asociados a cada alternativa, junto con los procesos que se ejecutarían
en cada una de las posibles plataformas [ ] [ ]
. Compatibilidad con Sistemas operativos (Enumerar) [ ] [ ]
. Compatibilidad con software de red [ ] [ ]
. Necesidad de software adicional [ ] [ ]
- REQUERIMIENTOS FÍSICOS
. Especificar detalladamente los requerimientos físicos mínimos
y recomendados, tales como memoria RAM, espacio libre en disco, procesadores, etc... [ ] [ ]
CARACTERÍSTICAS GENERALES
- FUENTES DE DATOS (ORIGEN) SOPORTADAS
. Permite extraer datos desde varias plataformas origen simultáneamente [ ] [ ]
. Indicar las distintas fuentes de datos operacionales a las que es posible acceder,
especificando en los casos que sea necesario las últimas versiones certificadas. [ ] [ ]
Ficheros planos [ ] [ ]
Acceso a bases de datos [ ] [ ]
Otras fuentes operacionales [ ] [ ]
Consideraciones a tener en cuenta [ ] [ ]
- BASES DE DATOS DESTINO SOPORTADAS
. Permite cargar datos en varias plataformas destino simultáneamente [ ] [ ]
.Gestores de bases de datos destino soportados, especificando las
últimas versiones certificadas
- FUNCIONALIDADES
. Enumerar las funcionalidades de la o las herramientas propuestas:
Permite manejar (leer/escribir) cadenas de caracteres de longitud variable
No limita el número de dígitos de los formatos numéricos
Es posible aplicar reglas de transformación a los números con
formato en coma flotante
Otras funcionalidades (especificar) [ ] [ ]
- TRATAMIENTO INTERMEDIO DE LOS DATOS RECUPERADOS
.Realiza un almacenamiento intermedio de los datos recuperados a partir de
los sistemas operacionales
. Especificar
Almacenamiento intermetdio físico de los datos
Fichero plano
Memoria
BBDD propia
BBDD externa
Otros
Localización
Puesto cliente
Servidor intermedio
Servidor central
Otros
Técnicas aplicadas sobre los datos intermedios
Compresión
Encriptación
Otros
Explicar el consumo de recursos asociado a este almacenamiento intermedio de los datos [ ] [ ]
- BASE DE DATOS COMO FUENTE DE DATOS OPERACIONALES
. Conocimiento de la estructura de la base de datos
Requiere algún software adicional que permita el acceso a las BBDD
para tal funcionalidad [ ] [ ]
. Detección a captura de modificaciones en la estructura de las bases
de datos
Requiere algún software adicional que permita el acceso a las BBDD
para tal funcionalidad
Explicar con detalle los mecanismos utilizados para la detección de
cambios en la estructura de las bases de datos
Es posible automatizar la detección de dichos cambios
Es posible automatizar la captura de los cambios realizados en la estructura
de las bases de datos
Indicar si la herramienta es capaz de detectar automáticamente las
transformaciones a las que afectan las modificaciones realizadas
Es necesario parar las bases de datos para realizar el proceso de captura
de cambios
Observaciones [ ] [ ]
. Acceso a las bases de datos
Requiere algún software adicional que permita el acceso a las BBDD
para tal funcionalidad
Acceden directamente a la base de datos los programas generados por la herramienta
Indicar cómo se obtienen los ficheros de descarga de los datos
Mediante una utilidad de la propia herramienta
A través de una utilidad de la BBDD
Mediante un desarrollo a medida
Otros (especificar)) [ ] [ ]
. Detección y captura de las modificaciones en los datos
Requiere algún software adicional que permita el acceso a las BBDD
para tal funcionalidad
Es posible automatizar la detección de estas modificaciones
Explicar detalladamente los mecanismos utilizados para la captura de dichas
modificaciones
Es posible automatizar la captura de dichas modificaciones
Indicar si la herramienta es capaz de detectar automáticamente las
transformaciones a las que afectan las modificaciones realizadas.
Es necesario parar las bases de datos para realizar el proceso de captura de las modificaciones realizadas sobre
los datos (Observaciones) [ ] [ ]
- RECOMENDACIONES PRÁCTICAS
. Enumerar las principales recomendaciones prácticas para asegurar una
plena explotación de la potencialidad de los paquetes software ofertados
. Enumerar y justificar brevemente los puntos fuertes tanto de la arquitectura funcional propuesta como de
las herramientas ofertadas [ ] [ ]
FUNCIONALIDAD
- FACILIDAD DE USO
. Especificar los idiomas soportados en cada una de las siguientes áreas:
Aplicación
Ayuda on-line
Manuales de ayuda
Soporte
. Soporta alfabetización internacional
. Dispone de ayuda on-line
. Es posible la presentación preliminar de la documentación
generada antes de imprimirla
. Posee un interfaz gráfico que permita tener una visión global
de las tablas incluidas en los sistemas operacionales y en el Data Warehouse
. Especificar detalladamente los diferentes perfiles de usuario contemplados
para cada una de las herramientas ofertadas, así como la curva de aprendizaje (en horas) para cada uno de
ellos.
. Posee un Editor de Diagramas que facilite las tareas de diseño de
los flujos de datos y de las transformaciones a aplicar [ ] [ ]
- PROCESOS DE EXTRACCIÓN Y TRANSFORMACIÓN
. Indicar el paquete software ofertado que incluye esta funcionalidad
y la plataforma o plataformas donde ha de instalarse
. Requiere algún software adicional que complemente esta funcionalidad
. Es posible automatizar completamente los procesos de extracción y
transformación
. Se puede integrar con el planificador externo de tareas
. Explicar detalladamente el mecanismo de acceso a las estructuras de
las bases de datos, tanto operacionales como del Data Warehouse
. Explicar el mecanismo de extracción de los datos desde los sistemas
operacionales detallando concretamente de dónde los extraen y si se utilizan ficheros secuenciales intermedios
. Detallar los procedimientos de depuración incorporados
. Indicar las funciones de transformación más importantes incluidas
en el producto:
Importación desde ficheros planos de reglas de transformación
previamente definidas Validación y sustitución de los campos de una tabla en base a los campos de
otras tablas
Cálculos aritméticos propios de sumarización de la información
Conversión de formatos de fecha
Definición de reglas de negocio
Llamadas a subrutinas externas
Otras
. Es posible definir reglas de transformación generales que se puedan
parametrizar mediante variables para casos concretos
. En caso de exclusión de datos en base a reglas de transformación,
indicar si se pueden almacenar
. Indicar:
Almacenamiento físico de los datos excluidos
Fichero plano
Base de Datos propia
Base de Datos externa
Otros
Localización física de los datos excluidos
Puesto cliente
Servidor intermedio
Servidor central
Otros [ ] [ ]
- CARACTERÍSTICAS DE LOS PROGRAMAS GENERADOS
. Especificar el lenguaje utilizado en la generación de código
para las distintas fuentes soportadas
. Indicar si genera también los JCL o scripts de compilación y ejecución
. Es posible modificar los esqueletos de los programas a generar
. Enumerar los tipos de programas generados, con una breve descripción de los mismos, y las plataformas
(destino u origen) donde deben ser ejecutados [ ] [ ]
- GENERACIÓN DE DOCUMENTACIÓN
. Posee un Generador de Informes que automatice la generación de la
documentación sobre los procesos de extracción y transformación
. Indicar el paquete software ofertado que incluye esta funcionalidad
y la plataforma o plataformas donde ha de instalarse
. Requiere algún software adicional que complemente esta funcionalidad
. Describir la información incluida en dicha documentación
Origen de los datos
Correspondencias
Transformaciones
Reglas de negocio aplicadas
Otras (especificar))
. Soporta el versionado de la documentación generada
. Se proporciona algún software que facilite el mantenimiento
y versionado de la documentación [ ] [ ]
- CARACTERÍSTICAS DEL ENTORNO FUNCIONAL
. Especificar el software mínimo que es necesario tener instalado
en las diferentes plataformas
. La transferencia de los programas generados desde el puesto cliente hasta los sistemas operacionales y el Data
Warehouse es automática
. Son necesarios otros requisitos software adicionales, como por ejemplo compiladores (Observaciones) [ ] [ ]
- DETECCIÓN Y CAPTURA DE MODIFICACIONES
. Indicar el paquete software ofertado que incluye esta funcionalidad
y la plataforma o plataformas donde ha de instalarse
. Requiere algún software adicional que complemente esta funcionalidad
. Explicar con detalle los mecanismos utilizados para la detección de cambios en la estructura de las
bases de datos del Data Warehouse
. Es posible automatizar la detección de dichos cambios
. Explicar detalladamente los mecanismos utilizados para la captura de dichos cambios
. Es posible automatizar la captura de los cambios realizados en la estructura de las bases de datos del Data Warehouse
. Indicar si la herramienta es capaz de detectar automáticamente las transformaciones a las que afectan
los cambios realizados
. Es necesario parar las bases de datos del Data Warehouse para realizar el proceso de captura de cambios (Observaciones) [ ] [ ]
- DETECCIÓN Y CAPTURA DE MODIFICACIONES EN LA ESTRUCTURA DE LAS BASES
DE DATOS DE DATA WAREHOUSE
. Indicar el paquete software ofertado que incluye esta funcionalidad y
la plataforma o plataformas donde ha de instalarse
. Requiere algún software adicional que complemente esta funcionalidad
. Explicar con detalle los mecanismos utilizados para la detección de modificaciones en los datos de
los sistemas operacionales fuente, enumerando las principales consideraciones a tener en cuenta
. Es posible automatizar la detección de estas modificaciones
. Explicar detalladamente los mecanismos utilizados para la captura de dichas modificaciones
. Es posible automatizar la captura de dichas modificaciones
. Indicar si la herramienta es capaz de detectar automáticamente las transformaciones a las que afectan
las modificaciones realizadas
. Es necesario parar las bases de datos operacionales para realizar el proceso de captura de las modificaciones
realizadas sobre los datos (Observaciones) [ ] [ ]
. Detección y captura de modificaciones en los datos de los
sistemas operacionales.
Indicar el paquete software ofertado que incluye esta funcionalidad y la plataforma
o plataformas donde ha de instalarse.
Requiere algún software adicional que complemente esta funcionalidad [ ] [ ]
Explicar con detalle los mecanismos utilizados para la detección de modificaciones
en los datos de los sistemas operacionales fuente, enumerando las principales consideraciones a tener en cuenta.
Posibilidad de automatizar la detección de estas modificaciones [ ] [ ]
Explicar detalladamente los mecanismos utilizados para la captura de dichas modificaciones.
Posibilidad de automatizar la captura de dichas modificaciones [ ] [ ]
Herramienta es capaz de detectar automáticamente las transformaciones
a las que afectan las modificaciones realizadas [ ] [ ]
Es necesario parar las bases de datos operacionales para realizar el proceso
de captura de las modificaciones realizadas sobre los datos [ ] [ ]
- MOVIMIENTO Y CARGA
. Indicar el paquete software ofertado que incluye esta funcionalidad
y la plataforma o plataformas donde ha de instalarse
. Requiere algún software adicional que complemente esta funcionalidad [ ] [ ]
. Explicar detalladamente los mecanismos de movimiento y carga de
los datos en las bases de datos destino del Data
Warehouse, enumerando las principales consideraciones
a tener en cuenta. En este sentido indicar si la transferencia se realiza
directamente o a través de un servidor intermedio, en este último caso detallar requerimientos físicos y lógicos de dicho servidor intermedio
. Transferencia de datos desde los Sistemas
Operacionales al Data Warehouse automática [ ] [ ]
. Control de las filas que sean rechazadas en el proceso de carga [ ] [ ]
Indicar qué ocurre con el proceso de carga
. Para el caso de los datos rechazados indicar
Si se especifica el motivo del rechazo [ ] [ ]
Almacenamiento físico de los datos rechazados
Fichero plano [ ] [ ]
Base de Datos propia [ ] [ ]
Base de Datos externa (especificar los gestores soportados en observaciones) [ ] [ ]
Otros (especificar) [ ] [ ]
Localización física de los datos rechazados
Puesto cliente [ ] [ ]
Servidor intermedio [ ] [ ]
Servidor central [ ] [ ]
Otros (especificar) [ ] [ ]
Explicar el mecanismo de tratamiento de los datos rechazados
. Indicar las alternativas para realizar la carga final del Data Warehouse
A través de la propia herramienta [ ] [ ]
A través de programas externos [ ] [ ]
Utilidades propias del gestor [ ] [ ]
Otras (especificar) [ ] [ ]
. Incorpora la herramienta algún proceso de comunicación automática de la disponibilidad
de los datos en el Data Warehouse a los usuarios finales [ ] [ ]
. En caso afirmativo indicar
El paquete software ofertado que incluye esta funcionalidad.
Requiere algún software adicional que complemente esta funcionalidad [ ] [ ]
El medio de comunicación automático utilizado
Correo electrónico [ ] [ ]
Otros (especificar) [ ] [ ]
En caso de poder utilizar correo electrónico, indicar los paquetes del
mercado perfectamente integrables con la herramienta propuesta
- CARGA INCREMENTAL
. Explicar detalladamente el mecanismo de carga incremental de los
datos en las bases de datos destino del Data Warehouse, especificando si se realiza en base a un chequeo de los
ficheros log de los sistemas operacionales, o en base al cruce de los fichero de carga, etc.
. Enumerar las principales diferencias respecto al proceso de carga
masiva y las consideraciones a tener en cuenta
- FUNCIONALIDADES ADICIONALES
. Análisis y control de la calidad
Incorpora funcionalidades para realizar un análisis y control de la calidad
de los datos [ ] [ ]
Especificar el paquete software ofertado que incluye esta funcionalidad y la
plataforma o plataformas donde ha de instalarse.
Requiere algún software adicional que complemente esta funcionalidad [ ] [ ]
. Limpieza
Incorpora funcionalidades para llevar a cabo una limpieza de los datos [ ] [ ]
Especificar el paquete software ofertado que incluye esta funcionalidad y la
plataforma o plataformas donde ha de instalarse
Requiere algún software adicional que complemente esta funcionalidad [ ] [ ]
Explicar detalladamente los mecanismos de limpieza proporcionados, indicando
la plataforma donde se ejecutan estos
- GESTIÓN DEL METADATA
. Procedimientos de creación, mantenimiento y consulta
Indicar cómo se almacenan físicamente los metadatos generados
Fichero plano [ ] [ ]
Base de Datos propia [ ] [ ]
Base de Datos externa (especificar los gestores soportados en observaciones) [ ] [ ]
Otros (especificar) [ ] [ ]
Dónde se almacenan dichos metadatos
Puesto cliente [ ] [ ]
Servidor intermedio [ ] [ ]
Servidor central del Data Warehouse [ ] [ ]
Servidor central operacional [ ] [ ]
La creación y actualización de los metadatos es completamente automática [ ] [ ]
Es posible definir plantillas para los metadatos que se desean generar [ ] [ ]
Todos los datos y reglas de transformación que intervienen en la creación
y mantenimiento del Data Warehouse se almacenan como metadatos [ ] [ ]
Dispone de alguna herramienta específica para el mantenimiento y consulta
de los metadatos asociados al Data Warehouse, permitiendo la navegación dentro del directorio de metadatos [ ] [ ]
En caso afirmativo indicar
* El nombre del paquete software ofertado que incluye tal funcionalidad
* La plataformas o plataformas donde ha de instalarse
* Si requiere algún software adicional para completar tal funcionalidad
* Describir el mecanismo de integración con las otras herramientas
ofertadas
Es posible crear vistas adaptadas de los metadatos para diferentes proyectos [ ] [ ]
Utiliza un formato propio de metadatos [ ] [ ]
Indicar la información contenida en los metadatos
Descripción de los esquemas de datos origen y destino [ ] [ ]
Reglas de transformación y validación de datos [ ] [ ]
Variables de conversión [ ] [ ]
Mappings origen-destino [ ] [ ]
Opciones de recuperación de datos [ ] [ ]
Opciones de manejo de excepciones [ ] [ ]
Secuencia de acciones a realizar en las conversiones (queries, sorts y merges) [ ] [ ]
Especificaciones detalladas de las conversiones [ ] [ ]
Otras (especificar) [ ] [ ]
Indicar el grado de seguridad en el acceso a los metadatos.
No incorpora funciones de seguridad (utiliza la dada por el gestor) [ ] [ ]
Sí incorpora funciones de seguridad [ ] [ ]
Explicar en detalle
Dispone de alguna herramienta específica que permita el acceso vía
Web a los metadatos asociados al Data Warehouse [ ] [ ]
En caso afirmativo especificar qué navegadores son compatibles
Microsoft Internet Explorer [ ] [ ]
Netscape [ ] [ ]
En caso afirmativo indicar
El nombre del paquete software ofertado que incluye tal funcionalidad y dónde
ha de instalarse, detallando los requerimientos lógicos y físicos asociados
Requiere algún software adicional para completar tal funcionalidad, además
del propio navegador [ ] [ ]
En base a la pregunta anterior indicar las funcionalidades disponibles vía
Web y las principales diferencias respecto a un acceso cliente/servidor directo
. Integración de los metadatos
Es posible que los metadatos generados por dicha herramienta de extracción
puedan ser interpretados e integrados con los metadatos generados por las herramientas de acceso al Data Warehouse [ ] [ ]
En base a la pregunta anterior explicar detalladamente los mecanismos de integración
utilizados, enumerando las consideraciones a tener en cuenta
Dicha integración de los metadatos completamente automática [ ] [ ]
Posibilidad de la integración entre metadatos de negocio y técnicos
provenientes de múltiples fuentes [ ] [ ]
En caso afirmativo explicar detalladamente los mecanismos de integración
utilizados, así como el grado de automatización de dicha integración
. Control de versiones y documentación del metadato
Mantiene un histórico sobre los cambios realizados que permita realizar
un control de versiones [ ] [ ]
Está automatizada la generación de documentación asociada
con los metadatos [ ] [ ]
En caso afirmativo indicar si es posible imprimir dicha documentación.
No [ ] [ ]
Sí, pero sin presentación preliminar [ ] [ ]
Sí, con presentación preliminar [ ] [ ]
. Importación y exportación de metadatos
Permite capturar los metadatos desde fuentes externas [ ] [ ]
En caso afirmativo indicar las fuentes soportadas
Procesadores de texto [ ] [ ]
Amipro [ ] [ ]
Word [ ] [ ]
WordPerfect [ ] [ ]
Otros (especificar) [ ] [ ]
Bases de datos (especificar) [ ] [ ]
Hojas de cálculo [ ] [ ]
Lotus 123 [ ] [ ]
Excel [ ] [ ]
Otros (especificar) [ ] [ ]
Ficheros planos [ ] [ ]
Otras (especificar) [ ] [ ]
Posibilidad de exportar los metadatos [ ] [ ]
En caso afirmativo indicar los formatos soportados.
CDIF (formato estándar de intercambio de datos) [ ] [ ]
Otros (especificar) [ ] [ ]
ADMINISTRACIÓN
- GESTIÓN DE RECURSOS
. Administración centralizada
Posee una herramienta de administración y control centralizada
No [ ] [ ]
Sí, pero sin interfaz gráfica [ ] [ ]
Sí, con interfaz gráfica [ ] [ ]
Indicar el paquete software ofertado que incluye esta funcionalidad
Indicar las plataformas donde es necesario instalar el software de esta herramienta
de administración
Puesto cliente [ ] [ ]
Servidor intermedio [ ] [ ]
Servidor central [ ] [ ]
Requiere algún software adicional que complemente dicha funcionalidad [ ] [ ]
Indicar las funcionalidades que incorpora esta herramienta
Gestión de la seguridad [ ] [ ]
Monitorización de tareas en curso [ ] [ ]
Realización de pruebas de funcionalidad a volumen pequeño [ ] [ ]
Otras (especificar) [ ] [ ]
Puede ser utilizada esta herramienta de administración desde varios puestos
No [ ] [ ]
Sí, pero no simultáneamente [ ] [ ]
Sí, simultáneamente [ ] [ ]
. Estadísticas y logs de los procesos de extracción,
transformación, movimiento y carga
Elabora automáticamente estadísticas y logs de dichos procesos [ ] [ ]
En caso afirmativo, especificar la información incluida en dichos logs
y estadísticas
Total de registros leídos [ ] [ ]
Total de registros cargados [ ] [ ]
Tiempos de ejecución [ ] [ ]
Número de registros a los que se aplica una determinada regla de transformación [ ] [ ]
Número de registros que cumplen cada una de las condiciones de una regla
de transformación [ ] [ ]
Otras (especificar) [ ] [ ]
Indicar el almacenamiento físico de dicha información
Fichero plano [ ] [ ]
Base de Datos propia [ ] [ ]
Base de Datos externa (especificar los gestores soportados en observaciones) [ ] [ ]
Otros (especificar) [ ] [ ]
Almacen de dicha información
Puesto cliente [ ] [ ]
Servidor intermedio [ ] [ ]
Servidor central [ ] [ ]
Indicar los tiempos estimados de extracción y transformación, en
base a volúmenes de información
Indicar los tiempos estimados de carga, en base a volúmenes de información
- SEGURIDAD
. Indicar los niveles de seguridad soportados
Por usuario [ ] [ ]
Por grupo de usuario [ ] [ ]
Otros (especificar) [ ] [ ]
. En qué plataforma se gestiona la seguridad
Puesto cliente [ ] [ ]
Servidor intermedio [ ] [ ]
Servidor central [ ] [ ]
. Se realiza una identificación del usuario a la hora de acceder al sistema [ ] [ ]
. Almacenamiento físico de la password
Fichero plano [ ] [ ]
Base de datos propia [ ] [ ]
Base de datos externa (especificar los gestores soportados en observaciones) [ ] [ ]
Otros (especificar) [ ] [ ]
. Localización física de la password
Puesto cliente [ ] [ ]
Servidor intermedio [ ] [ ]
Servidor central [ ] [ ]
Otros (especificar) [ ] [ ]
. Explicar en detalle los mecanismos de seguridad que incorporan la
o las herramientas ofertadas
- PROCEDIMIENTO DE PLANIFICACIÓN Y MANTENIMIENTO
. Posible construir procedimientos que automaticen las tareas de planificación
y mantenimiento
No [ ] [ ]
Sí, pero no dispone de un interfaz gráfico que facilite la programación
dedichas tareas. [ ] [ ]
Sí, con un interfaz gráfico que facilite la programación
de dichas tareas [ ] [ ]
. En caso afirmativo, indicar las posibles bases de dicha planificación
Eventos [ ] [ ]
Ventanas de tiempo [ ] [ ]
Otras (especificar) [ ] [ ]
. Indicar el paquete software ofertado que incluye esta funcionalidad y la plataforma
o plataformas donde ha de instalarse
. Requiere algún software adicional que complemente dicha funcionalidad [ ] [ ]
ACLARACIONES GENERALES
REFERENCIAS
3.3.2.- CUESTIONARIO DE ANÁLISIS DE CALIDAD
Con carácter general y a fin de utilizar la información recopilada de cara a la contratación, es importante destacar que los datos recogidos en este cuestionario están dirigidos a obtener un resumen estructurado de la oferta y a demostrar la solvencia técnica o profesional de la empresa en aquellos casos en que no sea requerida la clasificación de la misma. Dicha información sólo servirá de base a la valoración cuando esté relacionada con lo expresado en la cláusula "Criterios de adjudicación del contrato", siendo, en el resto de los casos, de carácter meramente informativo.
Nota: (*) significa que hay que indicar "1" en caso afirmativo.
(**) significa que hay que repetir para cada sistema operativo ofertado.
Cuestión Respuesta Referencia a oferta (Página)
------------------------------------------ ---------- ----------
ENTORNO OPERATIVO
- REQUERIMIENTOS LÓGICOS
. Especificar para cada uno de las paquetes software ofertados la o las posibles plataformas (servidor central,
servidor intermedio y cliente) donde podrían instalarse, detallando los requerimientos físicos y
lógicos asociados a cada alternativa, junto con los procesos que se ejecutarían en cada una de las
posibles plataformas. [ ] [ ]
. Compatibilidad con Sistemas operativos. (Enumerar) [ ] [ ]
. Compatibilidad con software de red [ ] [ ]
. Necesidad de software adicional. (Enumerar) [ ] [ ]
- REQUERIMIENTOS FÍSICOS
. Memoria RAM Mínima requerida [ ] [ ]
. Memoria RAM Recomendada [ ] [ ]
. Espacio libre de disco Mínimo requerido [ ] [ ]
. Espacio libre de disco Recomendado [ ] [ ]
. Procesador mínimo requerido [ ] [ ]
. Porcesador recomendado [ ] [ ]
. Observaciones
CARACTERISTICAS GENERALES [ ] [ ]
- ORIGEN DE LOS DATOS A ANALIZAR
. Indicar si se analiza el total de los datos o bien sólo una muestra
significativa de los mismos
Todos los datos [ ] [ ]
Muestra
Ambos [ ] [ ]
. Observaciones
. Indicar y explicar detalladamente el mecanismo de obtención de los datos
a analizar.
Acceso directo a las fuentes de datos y análisis de la calidad de los
datos [ ] [ ]
Acceso directo a las fuentes de datos, extracción de los datos a analizar
y almacenamiento de los mismos para su análisis. [ ] [ ]
Análisis de la calidad de los datos que otras herramientas han extraído
de las fuentes de datos. [ ] [ ]
. Observaciones
. Explicación detallada del mecanismo seguido
. En el caso de acceder directamente a las fuentes de datos indicar
Si es posible analizar la calidad de los datos de varias fuentes simultáneamente [ ] [ ]
Observaciones
Las fuentes de datos a las que es posible acceder, especificando en los casos
en que sea necesario las últimas versiones certificadas
Ficheros planos [ ] [ ]
Bases de datos (especificar) [ ] [ ]
Otras fuentes de datos (especificar) [ ] [ ]
Observaciones
. En el caso de extraer los datos a analizar desde las fuentes soportadas y almacenarlos
para su análisis, indicar
Almacenamiento físico de los datos analizar
Fichero plano [ ] [ ]
Memoria [ ] [ ]
Base de Datos propia [ ] [ ]
Base de Datos externa (especificar los gestores soportados en observaciones) [ ] [ ]
Otros (especificar) [ ] [ ]
Observaciones
Localización física de los datos
Puesto cliente [ ] [ ]
Servidor intermedio [ ] [ ]
Servidor central [ ] [ ]
Otros (especificar) [ ] [ ]
Observaciones
Técnicas aplicadas sobre los datos intermedios
Compresión [ ] [ ]
Encriptación [ ] [ ]
Otros (especificar) [ ] [ ]
En caso de aplicar compresión, indicar la relación de compresión
Observaciones
En base a las preguntas anteriores, explicar en detalle el consumo de recursos
asociado a este almacenamiento intermedio de los datos.
. En el caso de analizar los datos que otras herramientas han extraído
de las fuentes de datos, especificar de qué herramientas se trata. así como sus requerimientos lógicos
y físicos y la plataforma o plataformas donde han de instalarse.
- ELECCION Y TRATAMIENTO DE LAS MUESTRAS
. Describir el mecanismo de elección de la muestra, para asegurar la aleatoriedad
de la misma
Lo fija la herramienta sin intervención del usuario [ ] [ ]
El usuario selecciona un criterio de entre los posibles que proporciona la herramienta [ ] [ ]
El usuario puede confeccionar los criterios de elección de la muestra
a medida [ ] [ ]
Otros (especificar) [ ] [ ]
Describir detalladamente el mecanismo seguido
Observaciones
. Indicar el almacenamiento físico de la muestra de datos
Fichero plano [ ] [ ]
Memoria [ ] [ ]
Base de Datos propia [ ] [ ]
Base de Datos externa (especificar los gestores soportados en observaciones) [ ] [ ]
Otros (especificar) [ ] [ ]
Observaciones
. Indicar la localización física de la muestra de datos
Puesto cliente [ ] [ ]
Servidor intermedio [ ] [ ]
Servidor central [ ] [ ]
Otros (especificar) [ ] [ ]
Observaciones
. Porcentaje que supone la muestra sobre el volumen total de datos
Observaciones
. Técnicas aplicadas sobre la muestra de datos
Compresión [ ] [ ]
Encriptación [ ] [ ]
Otras (especificar) [ ] [ ]
En caso de aplicar compresión, indicar la relación de compresión.............................
Observaciones
- MECANISMOS DE ANALISIS DE LA CALIDAD Y FUNCIONALIDADES
. Explicar detalladamente el mecanismo de análisis de calidad utilizado
y las funcionalidades disponibles
. Indicar los niveles de análisis de calidad disponibles
A nivel de campo [ ] [ ]
A nivel de grupo de campos [ ] [ ]
A nivel de registros [ ] [ ]
Otros (especificar) [ ] [ ]
Observaciones
. Indicar la plataforma o plataformas donde se ejecutan los procesos de análisis
de calidad de los datos
Puesto cliente [ ] [ ]
Servidor intermedio [ ] [ ]
Servidor central del Data Warehouse [ ] [ ]
Servidor central operacional [ ] [ ]
Otros (especificar) [ ] [ ]
Observaciones
. Indicar las métricas que proporciona la herramienta por defecto para
cuantificar la calidad de los datos
Validación de formatos [ ] [ ]
Ausencia de información en campos obligatorios [ ] [ ]
Cardinalidad de las variables [ ] [ ]
Comprobación de reglas de integridad: [ ] [ ]
Entre campos del mismo fichero [ ] [ ]
Entre campos de distintos ficheros [ ] [ ]
Rango de valores [ ] [ ]
Comprobación cruzada de valores contra una tabla de referencia [ ] [ ]
Validación de fechas [ ] [ ]
Rango de fechas [ ] [ ]
Otras (especificar): [ ] [ ]
Observaciones
. Posibilidad de utilizar "métricas" definidas por el usuario
para cuantificar la calidad de los datos
No [ ] [ ]
Sí, pero no posee un asistente que facilita la definición de dichas
métricas [ ] [ ]
Sí, y posee un asistente que facilita la definición de dichas métricas [ ] [ ]
Observaciones. Describir el mecanismo de definición de métricas
utilizado [ ] [ ]
- LIMITACIONES
. Existencia de alguna limitación interna de la herramienta en cuanto
al volumen máximo de información que se puede analizar
Sí , limitado por número de registros [ ] [ ]
Sí , limitado por volumen de información [ ] [ ]
No [ ] [ ]
En caso afirmativo, especificar el límite definido
Observaciones
- RECOMENDACIONES PRACTICAS
. Enumerar las principales recomendaciones prácticas para asegurar una
plena explotación de la potencialidad de los paquetes software ofertados.
. Enumerar y justificar brevemente los puntos fuertes tanto de la arquitectura
funcional propuesta como de las herramientas ofertadas.
FUNCIONALIDAD
- FACILIDAD DE USO
. Especificar los idiomas soportados en cada una de las siguientes áreas
A nivel de aplicación
Español [ ] [ ]
Inglés [ ] [ ]
Otros (especificar) [ ] [ ]
A nivel de ayuda on-line
Español [ ] [ ]
Inglés [ ] [ ]
Otros (especificar) [ ] [ ]
A nivel de manuales de ayuda
Español [ ] [ ]
Inglés [ ] [ ]
Otros (especificar) [ ] [ ]
A nivel de soporte
Español [ ] [ ]
Inglés [ ] [ ]
Otros (especificar) [ ] [ ]
. Incluye los caracteres exclusivos del español: Ñ, ñ y
vocales acentuadas [ ] [ ]
. Interfaz gráfico [ ] [ ]
. Ayuda on-line [ ] [ ]
. Presentación preliminar de la documentación antes
de la impresión [ ] [ ]
. Observaciones
. Especificar detalladamente los diferentes perfiles de usuario contemplados
para cada una de las herramientas ofertadas, así como la curva de aprendizaje (en horas)para cada uno de
ellos.
- ACCESO A LAS FUENTES DE DATOS
. Conocimiento de la estructura de las bases
de datos
Requerimiento de algún software adicional que permita conocer la estructura
de las bases de datos [ ] [ ]
En caso afirmativo indicar la plataforma o plataformas donde ha de instalarse
dicha herramienta
Explicar detalladamente el mecanismo que utiliza la herramienta para conocer
la estructura de las bases de datos
. Detección y captura de modificaciones en la estructura de
las bases de datos
Requiere algún software adicional que permita detectar y capturar las
modificaciones hechas en la estructura de las bases de datos [ ] [ ]
Explicar con detalle los mecanismos utilizados para la detección de cambios
en la estructura de las bases de datos.
Posibilidad de automatizar la detección de dichos cambios [ ] [ ]
Explicar detalladamente los mecanismos utilizados para la captura de dichos cambios
Posibilidad de automatizar la captura de los cambios realizados en la estructura
de las bases de datos [ ] [ ]
Es necesario parar las bases de datos para realizar el proceso de captura de
cambios [ ] [ ]
. Acceso a las bases de datos
Requiere algún software adicional que permita el acceso a las bases de
datos [ ] [ ]
Accede directamente a la base de datos [ ] [ ]
En caso afirmativo describir el mecanismo de acceso seguido
En caso de no acceder directamente a la base de datos indicar cómo se
obtienen los ficheros de datos
Mediante una utilidad de la propia herramienta [ ] [ ]
A través de una utilidad del gestor [ ] [ ]
Mediante un desarrollo a medida. [ ] [ ]
Otros (especificar) [ ] [ ]
- PROCEDIMIENTOS DE ANALISIS DE CALIDAD
. Indicar el paquete software ofertado que incluye esta funcionalidad
y la plataforma o plataformas donde ha de instalarse
. Requiere algún software adicional que complemente esta funcionalidad [ ] [ ]
. Es posible automatizar completamente los procesos de análisis
de calidad [ ] [ ]
. Es posible mantener un histórico sobre evolución temporal
de la calidad de los datos [ ] [ ]
. Formatos soportados para la exportación de los resultados
obtenidos
Hojas de cálculo [ ] [ ]
Lotus 123 [ ] [ ]
Excel [ ] [ ]
Otras (especificar) [ ] [ ]
Procesadores de texto [ ] [ ]
Amipro [ ] [ ]
WordPerfect [ ] [ ]
Word [ ] [ ]
Otros (especificar) [ ] [ ]
Herramientas gráficas [ ] [ ]
FreeLance [ ] [ ]
PowerPoint [ ] [ ]
Otros (especificar) [ ] [ ]
Bases de datos (especificar) [ ] [ ]
Ficheros Planos [ ] [ ]
Otros (especificar) [ ] [ ]
. Adjuntar como anexo un ejemplo, lo más completo posible,
que contenga la información sobre un análisis
de calidad, efectuado con la herramienta propuesta
- GENERACION DE DOCUMENTACION
. Posee un Generador de Informes que permita la generación
de la documentación sobre los resultados
obtenidos
No [ ] [ ]
Sí, pero bajo la petición del usuario [ ] [ ]
Sí, automáticamente [ ] [ ]
. Indicar el paquete software ofertado que incluye esta funcionalidad
y la plataforma o plataformas donde ha de instalarse
. Requiere algún software adicional que complemente esta funcionalidad [ ] [ ]
. Describir la información incluida en dicha documentación
Origen de los datos [ ] [ ]
Posibles correspondencias entre datos [ ] [ ]
Métricas aplicadas [ ] [ ]
Otras (especificar) [ ] [ ]
. Soporta el versionado de la documentación generada [ ] [ ]
. Se proporciona algún software que facilite el mantenimiento
y versionado de la documentación [ ] [ ]
- CARACTERISTICAS DEL ENTORNO FUNCIONAL
. Especificar el software mínimo que es necesario tener instalado
en las diferentes plataformas
. Son necesarios otros requisitos software adicionales [ ] [ ]
- FUNCIONALIDADES ADICIONALES
. Limpieza de datos
Incorpora alguna funcionalidad que permita la limpieza de datos [ ] [ ]
Especificar el paquete software ofertado que incluye esta funcionalidad y la
plataforma o plataformas donde ha de instalarse
Requiere algún software adicional que complemente esta funcionalidad [ ] [ ]
Explicar detalladamente los mecanismos de limpieza proporcionados, indicando
la plataforma donde se ejecutan estos
. Otras funcionalidades
Incorpora otras funcionalidades (enumerarlas) [ ] [ ]
Especificar el paquete o paquetes software ofertados que incluyen estas funcionalidades
y la plataforma o plataformas donde ha de instalarse
Requiere algún software adicional que complemente estas funcionalidades [ ] [ ]
Explicar detalladamente los mecanismos asociados a dichas funcionalidades, indicando
la plataforma donde se ejecutan estos
- GESTION DE LOS METADATOS DE CALIDAD
. Se generan metadatos sobre la calidad de los datos [ ] [ ]
. Procedimientos de creación, mantenimiento y consulta
Indicar cómo se almacenan físicamente los metadatos generados.
Fichero plano [ ] [ ]
Base de Datos propia [ ] [ ]
Base de Datos externa (especificar los gestores soportados en observaciones) [ ] [ ]
Otros (especificar) [ ] [ ]
Dónde se almacenan dichos metadatos
Puesto cliente [ ] [ ]
Servidor intermedio [ ] [ ]
Servidor central [ ] [ ]
La creación y actualización de los metadatos es completamente automática [ ] [ ]
En caso negativo indicar qué metadatos se alimentan automáticamente
y cuáles no, especificando en este último caso el mecanismo seguido
Es posible definir plantillas para los metadatos que se desean generar [ ] [ ]
Dispone de alguna herramienta específica para el mantenimiento y consulta
de los metadatos de calidad asociados al Data Warehouse, así como para la navegación dentro del directorio
de metadatos [ ] [ ]
El nombre del paquete software ofertado que incluye tal funcionalidad
La plataformas o plataformas donde ha de instalarse
Requiere algún software adicional para completar tal funcionalidad [ ] [ ]
Es posible crear vistas adaptadas de los metadatos para diferentes proyectos [ ] [ ]
Utiliza un formato propio de metadatos [ ] [ ]
Indicar la información contenida en los metadatos
Descripción de los esquemas de datos origen [ ] [ ]
Métricas definidas por defecto [ ] [ ]
Métricas definidas por el usuario [ ] [ ]
Otras (especificar) [ ] [ ]
Indicar el grado de seguridad en el acceso a los metadatos
No incorpora funciones de seguridad [ ] [ ]
Sí incorpora funciones de seguridad [ ] [ ]
Dispone de alguna herramienta específica que permita el acceso vía
Web a los metadatos de calidad [ ] [ ]
especificar qué navegadores son compatibles
El nombre del paquete software ofertado que incluye tal funcionalidad y dónde
ha de instalarse, detallando los requerimientos lógicos y físicos asociados
Requiere algún software adicional para completar tal funcionalidad, además
del propio navegador [ ] [ ]
En base a la pregunta anterior indicar las funcionalidades disponibles vía
Web y las principales diferencias respecto a un acceso cliente/servidor directo
. Integración de los metadatos de calidad con otros metadatos
Es posible que los metadatos generados por dicha herramienta de análisis
puedan ser interpretados e integrados con los generados por otras herramientas, tanto de usuario final como de
extracción, movimiento y carga [ ] [ ]
En caso afirmativo especificar las herramientas de compatibles, indicando si
son o no del mismo fabricante
En base a la pregunta anterior explicar detalladamente los mecanismos de integración
utilizados, enumerando las consideraciones a tener en cuenta
Dicha integración de los metadatos completamente automática [ ] [ ]
. Control de versiones y documentación del metadato de calidad
Se mantiene un histórico sobre los cambios realizados en los metadatos
de calidad que permita realizar un control de versiones [ ] [ ]
si existe algún límite en el número de versiones [ ] [ ]
Está automatizada la generación de documentación asociada
con los metadatos de calidad [ ] [ ]
Posibilidad de imprimir dicha documentación
No [ ] [ ]
Sí, pero sin presentación preliminar [ ] [ ]
Sí, con presentación preliminar [ ] [ ]
. Importación y exportación de los metadatos de calidad
Permite importar los metadatos de calidad desde fuentes externas [ ] [ ]
Indicar las fuentes soportadas
Procesadores de texto [ ] [ ]
Amipro [ ] [ ]
Word [ ] [ ]
WordPerfect [ ] [ ]
Otros (especificar) [ ] [ ]
Bases de datos (especificar) [ ] [ ]
Hojas de cálculo [ ] [ ]
Lotus 123 [ ] [ ]
Excel [ ] [ ]
Otros (especificar) [ ] [ ]
Ficheros planos [ ] [ ]
Otras (especificar) [ ] [ ]
Consideraciones a tener en cuenta
Posibilidad de exportar los metadatos de calidad [ ] [ ]
Formatos soportados
CDIF (formato estándar de intercambio de datos) [ ] [ ]
Otros (especificar) [ ] [ ]
- PLANIFICACION DEL ANALISIS DE CALIDAD
. Posibilidad de construir procedimientos que automaticen las tareas de análisis
de la calidad de los datos
No [ ] [ ]
Sí, pero no dispone de un interfaz gráfico que facilite la programación
de dichas tareas. [ ] [ ]
Sí, con un interfaz gráfico que facilite la programación
de dichas tareas [ ] [ ]
. Indicar las posibles bases de dicha planificación
Eventos [ ] [ ]
Ventanas de tiempo [ ] [ ]
Otras (especificar) [ ] [ ]
. Indicar el paquete software ofertado que incluye esta funcionalidad y la plataforma
o plataformas donde ha de instalarse
. Requiere algún software adicional que complemente dicha funcionalidad [ ] [ ]
ACLARACIONES GENERALES
REFERENCIAS
Resumen de las principales instalaciones donde se encuentran instaladas las herramientas
propuestas, con una breve descripción del entorno tecnológico y de los volúmenes de información
manejados
3.3.3.- CUESTIONARIO DE HERRAMIENTAS DE USUARIO FINAL: OLAP, EIS, REPORTING
Con carácter general y a fin de utilizar la información recopilada de cara a la contratación, es importante destacar que los datos recogidos en este cuestionario están dirigidos a obtener un resumen estructurado de la oferta y a demostrar la solvencia técnica o profesional de la empresa en aquellos casos en que no sea requerida la clasificación de la misma. Dicha información sólo servirá de base a la valoración cuando esté relacionada con lo expresado en la cláusula "Criterios de adjudicación del contrato", siendo, en el resto de los casos, de carácter meramente informativo.
Nota: (*) significa que hay que indicar "1" en caso afirmativo.
(**) significa que hay que repetir para cada sistema operativo ofertado.
Cuestión Respuesta Referencia a oferta (Página)
------------------------------------------ ---------- ----------
ENTORNO OPERATIVO
- REQUERIMIENTOS LÓGICOS
Es compatible con los sistemas operativos de las plataformas
[ ]
[ ]
Es compatible con otros sistemas operativos (enumerar)
[ ]
[ ]
Es compatible con el software de red del entorno
[ ]
[ ]
Necesidad software adicional (enumerar)
[ ]
[ ]
- REQUERIMIENTOS FÍSICOS
. Memoria RAM Mínima requerida [ ] [ ]
. Memoria RAM Recomendada [ ] [ ]
. Espacio libre de disco Mínimo requerido [ ] [ ]
. Espacio libre de disco Recomendado [ ] [ ]
. Procesador mínimo requerido [ ] [ ]
. Porcesador recomendado [ ] [ ]
. Observaciones
CARACTERÍSTICAS GENERALES
- INTERFACES DE USUARIO FINAL APORTADAS Y SOPORTADAS
. Especificar los diferentes interfaces de usuario final que aportan
las herramientas ofertadas, indicando el perfil de usuario adecuado a cada uno de ellos
Aplicaciones EIS [ ] [ ]
Entornos OLAP [ ] [ ]
Reporting [ ] [ ]
Otros (especificar) [ ] [ ]
. Especificar los diferentes interfaces de usuario final que se soportan,
indicando el perfil de usuario adecuado a cada uno de ellos
Aplicaciones EIS [ ] [ ]
Entornos OLAP [ ] [ ]
Reporting [ ] [ ]
Lotus 123 [ ] [ ]
Excel [ ] [ ]
Otros (especificar) [ ] [ ]
- DESCRIPCIÓN DEL ACCESO
. Especificar el tipo de acceso efectuado
ROLAP [ ] [ ]
MOLAP [ ] [ ]
Observaciones
. Indicar las arquitecturas cliente/servidor soportadas
2 niveles (acceso directo a la base de datos desde el puesto cliente) [ ] [ ]
3 niveles (acceso a la base de datos a través de un servidor intermedio) [ ] [ ]
4 niveles (acceso vía Web) [ ] [ ]
Observaciones
. Indicar los gestores de bases de datos que soporta, así como
las últimas versiones certificadas para cada uno de ellos
Adabas....................... [ ] [ ]
DB2....................... [ ] [ ]
Informix....................... [ ] [ ]
Oracle....................... [ ] [ ]
Redbrick....................... [ ] [ ]
SQL Server....................... [ ] [ ]
Sybase Adaptive Server Enterprise....................... [ ] [ ]
Sybase Adaptive Server IQ ....................... [ ] [ ]
Teradata....................... [ ] [ ]
Otros (especificar)....................... [ ] [ ]
. Almacenamiento físico de los datos recuperados
Fichero plano [ ] [ ]
Memoria [ ] [ ]
Base de datos propia [ ] [ ]
Base de datos externa (especificar los gestores soportados en observaciones) [ ] [ ]
Otros (especificar) [ ] [ ]
. Dónde se almacena la información recuperada
Puesto cliente [ ] [ ]
Servidor intermedio [ ] [ ]
Servidor central [ ] [ ]
Otros (especificar) [ ] [ ]
. Indicar la visión lógica de los datos recuperados.
Relacional [ ] [ ]
Multidimensional (cubos) [ ] [ ]
. En caso de almacenar la información recuperada de manera
multidimensional indicar cómo y cuándo se genera el cubo
En el momento de la consulta [ ] [ ]
En un proceso diferido [ ] [ ]
Otros (especificar) [ ] [ ]
Para cualquiera de las respuestas describir en detalle el mecanismo seguido
. En caso de almacenamiento multidimensional explicar qué ocurre
si los datos necesarios para dar respuesta a una consulta no se encuentran en el cubo
Genera en el momento un nuevo acceso a la base de datos del Data [ ] [ ]
Warehouse [ ] [ ]
Se indica que la consulta en cuestión no puede ser ejecutada [ ] [ ]
Otros (especificar) [ ] [ ]
Para cualquiera de las respuestas describir en detalle el mecanismo seguido
- TÉCNICAS DE EXPLORACIÓN DE DATOS
. Técnicas de exploración de datos soportadas
Drill down [ ] [ ]
Drill up [ ] [ ]
Drill across [ ] [ ]
Otras (especificar) [ ] [ ]
. Para las técnicas de navegación soportadas indicar
en qué casos se vuelve a lanzar una query contra la base de datos con el fin de obtener los detalles solicitados,
especificando si se hace de forma desatendida o no
. En el caso de utilizar alguna de las técnicas de exploración
de datos, se mantiene la visualización de los datos asociados a cada uno de los pasos seguidos, de manera
que siempre tendremos los datos anteriores para poder iniciar otro camino de navegación. [ ] [ ]
Observaciones
. Es posible navegar por más de una ocurrencia
del mismo atributo simultáneamente [ ] [ ]
Especificar si existe algún límite en el número de ocurrencias
desde las que iniciar una navegación
Observaciones
- FUNCIONALIDADES. POTENCIA DE CÁLCULO
. Principales funcionalidades proporcionadas
Rankings
[ ]
[ ]
Tendencias
[ ]
[ ]
Comparativas
[ ]
[ ]
Otras (especificar)
[ ]
[ ]
Descripción de las funcionalidades
. Enumerar las funciones estadísticas disponibles
. Funcionalidades de cálculo dinámico soportadas
Definición de múltiples criterios de ordenación dentro de
un informe
[ ]
[ ]
Redimensionamiento automático de la anchura de las columnas
[ ]
[ ]
Cálculo automático de totales y estadísticas
[ ]
[ ]
Otras (especificar)
[ ]
[ ]
. Posibilidad de utilizar fechas dinámicas,
tomando como base la fecha actual
[ ]
[ ]
(especificar)
. Posible realizar cálculos dinámicos
entre las columnas o incluso celdas que componen un informe ya calculado, de forma semejante a como lo hace una hoja de cálculo, sin necesidad de lanzar una nueva consulta
No
[ ]
[ ]
Sí, pero es necesario definir una nueva métrica
[ ]
[ ]
Sí, sin necesidad de definir nuevas métricas
[ ]
[ ]
- VISIÓN DEL MODELO DE NEGOCIO
. Posee un interfaz gráfica que muestre el modelo de negocio
utilizado, es decir, las dimensiones de forma jerarquizada
y los atributos que las componen
No
[ ]
[ ]
Sí, pero sin la posibilidad de limitar la expansión de los atributos
hasta el nivel deseado.
[ ]
[ ]
Sí, con la posibilidad de limitar la expansión.
[ ]
[ ]
. En caso de poder limitar esta expansión especificar los posibles
criterios a seguir, y describir el mecanismo de
limitación utilizado
Por usuario
[ ]
[ ]
Por grupo de usuario
[ ]
[ ]
Otros (especificar)
[ ]
[ ]
. Posible en dicho interfaz gráfico visualizar
los valores de los atributos que forman parte del
modelo de negocio
[ ]
[ ]
afirmativo explicar la técnica utilizada para obtener dichos valores
- LIMITACIONES
. Limitación interna de la herramienta
en cuanto al volumen máximo de información
que se puede recuperar
Sí , limitado por número de registros
[ ]
[ ]
Sí , limitado por volumen de información
[ ]
[ ]
No
[ ]
[ ]
Especificar el límite definido
. Limitación en cuanto al número
de dimensiones o atributos a incluir dentro del
modelo de datos de negocio
[ ]
[ ]
(especificar)
. Especificar detalladamente las principales limitaciones de los paquetes
software ofertados
- RECOMENDACIONES PRÁCTICAS
. Indicar el modelo de datos recomendado (en el servidor de datos)
Copo de nieve
[ ]
[ ]
Estrella
[ ]
[ ]
Relacional
[ ]
[ ]
Otros (especificar)
[ ]
[ ]
. Especificar detalladamente las principales recomendaciones prácticas
para asegurar una plena explotación de la
potencialidad de las herramientas ofertadas
. Enumerar y justificar brevemente los puntos fuertes tanto de la
arquitectura funcional propuesta como de las herramientas
ofertadas
3.3.3.- CUESTIONARIO DE HERRAMIENTAS DE USUARIO FINAL: OLAP, EIS, REPORTING
Con carácter general y a fin de utilizar la información recopilada de cara a la contratación, es importante destacar que los datos recogidos en este cuestionario están dirigidos a obtener un resumen estructurado de la oferta y a demostrar la solvencia técnica o profesional de la empresa en aquellos casos en que no sea requerida la clasificación de la misma. Dicha información sólo servirá de base a la valoración cuando esté relacionada con lo expresado en la cláusula "Criterios de adjudicación del contrato", siendo, en el resto de los casos, de carácter meramente informativo.
Nota: (*) significa que hay que indicar "1" en caso afirmativo.
(**) significa que hay que repetir para cada sistema operativo ofertado.
Cuestión Respuesta Referencia a oferta (Página)
------------------------------------------ ---------- ----------
ENTORNO OPERATIVO
- REQUERIMIENTOS LÓGICOS
Es compatible con los sistemas operativos de las plataformas
[ ]
[ ]
Es compatible con otros sistemas operativos (enumerar)
[ ]
[ ]
Es compatible con el software de red del entorno
[ ]
[ ]
Necesidad software adicional (enumerar)
[ ]
[ ]
- REQUERIMIENTOS FÍSICOS
. Memoria RAM Mínima requerida [ ] [ ]
. Memoria RAM Recomendada [ ] [ ]
. Espacio libre de disco Mínimo requerido [ ] [ ]
. Espacio libre de disco Recomendado [ ] [ ]
. Procesador mínimo requerido [ ] [ ]
. Porcesador recomendado [ ] [ ]
. Observaciones
CARACTERÍSTICAS GENERALES
- INTERFACES DE USUARIO FINAL APORTADAS Y SOPORTADAS
. Especificar los diferentes interfaces de usuario final que aportan
las herramientas ofertadas, indicando el perfil de usuario adecuado a cada uno de ellos
Aplicaciones EIS [ ] [ ]
Entornos OLAP [ ] [ ]
Reporting [ ] [ ]
Otros (especificar) [ ] [ ]
. Especificar los diferentes interfaces de usuario final que se soportan,
indicando el perfil de usuario adecuado a cada uno de ellos
Aplicaciones EIS [ ] [ ]
Entornos OLAP [ ] [ ]
Reporting [ ] [ ]
Lotus 123 [ ] [ ]
Excel [ ] [ ]
Otros (especificar) [ ] [ ]
- DESCRIPCIÓN DEL ACCESO
. Especificar el tipo de acceso efectuado
ROLAP [ ] [ ]
MOLAP [ ] [ ]
Observaciones
. Indicar las arquitecturas cliente/servidor soportadas
2 niveles (acceso directo a la base de datos desde el puesto cliente) [ ] [ ]
3 niveles (acceso a la base de datos a través de un servidor intermedio) [ ] [ ]
4 niveles (acceso vía Web) [ ] [ ]
Observaciones
. Indicar los gestores de bases de datos que soporta, así como
las últimas versiones certificadas para cada uno de ellos
Adabas....................... [ ] [ ]
DB2....................... [ ] [ ]
Informix....................... [ ] [ ]
Oracle....................... [ ] [ ]
Redbrick....................... [ ] [ ]
SQL Server....................... [ ] [ ]
Sybase Adaptive Server Enterprise....................... [ ] [ ]
Sybase Adaptive Server IQ ....................... [ ] [ ]
Teradata....................... [ ] [ ]
Otros (especificar)....................... [ ] [ ]
. Almacenamiento físico de los datos recuperados
Fichero plano [ ] [ ]
Memoria [ ] [ ]
Base de datos propia [ ] [ ]
Base de datos externa (especificar los gestores soportados en observaciones) [ ] [ ]
Otros (especificar) [ ] [ ]
. Dónde se almacena la información recuperada
Puesto cliente [ ] [ ]
Servidor intermedio [ ] [ ]
Servidor central [ ] [ ]
Otros (especificar) [ ] [ ]
. Indicar la visión lógica de los datos recuperados.
Relacional [ ] [ ]
Multidimensional (cubos) [ ] [ ]
. En caso de almacenar la información recuperada de manera
multidimensional indicar cómo y cuándo se genera el cubo
En el momento de la consulta [ ] [ ]
En un proceso diferido [ ] [ ]
Otros (especificar) [ ] [ ]
Para cualquiera de las respuestas describir en detalle el mecanismo seguido
. En caso de almacenamiento multidimensional explicar qué ocurre
si los datos necesarios para dar respuesta a una consulta no se encuentran en el cubo
Genera en el momento un nuevo acceso a la base de datos del Data [ ] [ ]
Warehouse [ ] [ ]
Se indica que la consulta en cuestión no puede ser ejecutada [ ] [ ]
Otros (especificar) [ ] [ ]
Para cualquiera de las respuestas describir en detalle el mecanismo seguido
- TÉCNICAS DE EXPLORACIÓN DE DATOS
. Técnicas de exploración de datos soportadas
Drill down [ ] [ ]
Drill up [ ] [ ]
Drill across [ ] [ ]
Otras (especificar) [ ] [ ]
. Para las técnicas de navegación soportadas indicar
en qué casos se vuelve a lanzar una query contra la base de datos con el fin de obtener los detalles solicitados,
especificando si se hace de forma desatendida o no
. En el caso de utilizar alguna de las técnicas de exploración
de datos, se mantiene la visualización de los datos asociados a cada uno de los pasos seguidos, de manera
que siempre tendremos los datos anteriores para poder iniciar otro camino de navegación. [ ] [ ]
Observaciones
. Es posible navegar por más de una ocurrencia
del mismo atributo simultáneamente [ ] [ ]
Especificar si existe algún límite en el número de ocurrencias
desde las que iniciar una navegación
Observaciones
- FUNCIONALIDADES. POTENCIA DE CÁLCULO
. Principales funcionalidades proporcionadas
Rankings
[ ]
[ ]
Tendencias
[ ]
[ ]
Comparativas
[ ]
[ ]
Otras (especificar)
[ ]
[ ]
Descripción de las funcionalidades
. Enumerar las funciones estadísticas disponibles
. Funcionalidades de cálculo dinámico soportadas
Definición de múltiples criterios de ordenación dentro de
un informe
[ ]
[ ]
Redimensionamiento automático de la anchura de las columnas
[ ]
[ ]
Cálculo automático de totales y estadísticas
[ ]
[ ]
Otras (especificar)
[ ]
[ ]
. Posibilidad de utilizar fechas dinámicas,
tomando como base la fecha actual
[ ]
[ ]
(especificar)
. Posible realizar cálculos dinámicos
entre las columnas o incluso celdas que componen un informe ya calculado, de forma semejante a como lo hace una hoja de cálculo, sin necesidad de lanzar una nueva consulta
No
[ ]
[ ]
Sí, pero es necesario definir una nueva métrica
[ ]
[ ]
Sí, sin necesidad de definir nuevas métricas
[ ]
[ ]
- VISIÓN DEL MODELO DE NEGOCIO
. Posee un interfaz gráfica que muestre el modelo de negocio
utilizado, es decir, las dimensiones de forma jerarquizada
y los atributos que las componen
No
[ ]
[ ]
Sí, pero sin la posibilidad de limitar la expansión de los atributos
hasta el nivel deseado.
[ ]
[ ]
Sí, con la posibilidad de limitar la expansión.
[ ]
[ ]
. En caso de poder limitar esta expansión especificar los posibles
criterios a seguir, y describir el mecanismo de
limitación utilizado
Por usuario
[ ]
[ ]
Por grupo de usuario
[ ]
[ ]
Otros (especificar)
[ ]
[ ]
. Posible en dicho interfaz gráfico visualizar
los valores de los atributos que forman parte del
modelo de negocio
[ ]
[ ]
afirmativo explicar la técnica utilizada para obtener dichos valores
- LIMITACIONES
. Limitación interna de la herramienta
en cuanto al volumen máximo de información
que se puede recuperar
Sí , limitado por número de registros
[ ]
[ ]
Sí , limitado por volumen de información
[ ]
[ ]
No
[ ]
[ ]
Especificar el límite definido
. Limitación en cuanto al número
de dimensiones o atributos a incluir dentro del
modelo de datos de negocio
[ ]
[ ]
(especificar)
. Especificar detalladamente las principales limitaciones de los paquetes
software ofertados
- RECOMENDACIONES PRÁCTICAS
. Indicar el modelo de datos recomendado (en el servidor de datos)
Copo de nieve
[ ]
[ ]
Estrella
[ ]
[ ]
Relacional
[ ]
[ ]
Otros (especificar)
[ ]
[ ]
. Especificar detalladamente las principales recomendaciones prácticas
para asegurar una plena explotación de la
potencialidad de las herramientas ofertadas
. Enumerar y justificar brevemente los puntos fuertes tanto de la
arquitectura funcional propuesta como de las herramientas
ofertadas
3.3.3.- CUESTIONARIO DE HERRAMIENTAS DE USUARIO FINAL: OLAP, EIS, REPORTING (cont.)
Con carácter general y a fin de utilizar la información recopilada de cara a la contratación, es importante destacar que los datos recogidos en este cuestionario están dirigidos a obtener un resumen estructurado de la oferta y a demostrar la solvencia técnica o profesional de la empresa en aquellos casos en que no sea requerida la clasificación de la misma. Dicha información sólo servirá de base a la valoración cuando esté relacionada con lo expresado en la cláusula "Criterios de adjudicación del contrato", siendo, en el resto de los casos, de carácter meramente informativo.
Nota: (*) significa que hay que indicar "1" en caso afirmativo.
(**) significa que hay que repetir para cada sistema operativo ofertado.
Cuestión Respuesta Referencia a oferta (Página)
------------------------------------------ ---------- ----------
ADMINISTRACIÓN
- GESTIÓN DE RECURSOS
. Administración centralizada
Posee una herramienta de administración centralizada
No
[ ]
[ ]
Sí, pero sin interfaz gráfica
[ ]
[ ]
Sí, con interfaz gráfica
[ ]
[ ]
Indicar y describir las funcionalidades que incorpora esta herramienta
Gestión de la seguridad
[ ]
[ ]
Monitorización de tareas en curso
[ ]
[ ]
Definición de perfiles de usuario
[ ]
[ ]
Asignación y limitación de recursos
[ ]
[ ]
Otras (especificar)
[ ]
[ ]
Observaciones. Describir las funcionalidades soportadas
Posibilidad de utilización de esta herramienta de administración
desde varios puestos
No
[ ]
[ ]
Sí, pero no simultáneamente
[ ]
[ ]
Sí, simultáneamente
[ ]
[ ]
Indicar el paquete software ofertado que incluye esta funcionalidad
Indicar las plataformas donde es necesario instalar el software de esta herramienta
de administración
Puesto cliente
[ ]
[ ]
Servidor intermedio
[ ]
[ ]
Servidor central
[ ]
[ ]
Requierimiento de algún software adicional que complemente dicha funcionalidad
[ ]
[ ]
Observaciones (especificar
en caso afirmativo)
Observaciones
. Tratamiento de los datos recuperados
Técnicas aplicadas sobre los datos recuperados
Compresión
[ ]
[ ]
Encriptación
[ ]
[ ]
Otros (especificar)
[ ]
[ ]
En caso de aplicar compresión, indicar la relación de compresión
Salva el resultado de la consulta
No
[ ]
[ ]
Sí, bajo petición del usuario
[ ]
[ ]
Sí, automáticamente
[ ]
[ ]
En caso afirmativo especificar los formatos soportados
HTML
[ ]
[ ]
Dbase
[ ]
[ ]
RTF
[ ]
[ ]
Lotus 123
[ ]
[ ]
Excel
[ ]
[ ]
Amipro
[ ]
[ ]
WordPerfect
[ ]
[ ]
Word
[ ]
[ ]
Tablas del gestor
[ ]
[ ]
Otros (especificar)
[ ]
[ ]
Utilización tablas temporales en la resolución de las consultas
efectuadas
[ ]
[ ]
Observaciones. Indicar el volumen de almacenamiento recomendado para dichas tablas,
en función del volumen de datos
En caso afirmativo especificar la posible localización física de
dichas tablas
Puesto cliente (base de datos auxiliar)
[ ]
[ ]
Servidor intermedio (base de datos auxiliar)
[ ]
[ ]
Servidor central (base de datos del Data Warehouse)
[ ]
[ ]
Observaciones
. Estadísticas de ejecución
Realización una elaboración automática de estadísticas
sobre la utilización de recursos
[ ]
[ ]
Información incluida en dichas estadísticas
Tipos de consultas más frecuentes
[ ]
[ ]
Tiempos de ejecución
[ ]
[ ]
Número de accesos realizados por usuario
[ ]
[ ]
Volúmenes recuperados de información
[ ]
[ ]
Estadísticas asociadas a threads de diferentes prioridades
[ ]
[ ]
Otras estadísticas (especificar)
[ ]
[ ]
Almacenamiento físico de dicha información estadística
Fichero plano
[ ]
[ ]
Base de Datos propia
[ ]
[ ]
Base de Datos externa (especificar los gestores soportados en observaciones)
[ ]
[ ]
Otros (especificar)
[ ]
[ ]
Dónde se almacena la información estadística
Puesto cliente
[ ]
[ ]
Servidor intermedio
[ ]
[ ]
Servidor central
[ ]
[ ]
Observaciones
. Simulación, estimaciones de consumo y
recomendaciones sobre el diseño del Data Warehouse
Dispone de alguna herramienta de simulación que permita estimar el consumo
de recursos y el tiempo de respuesta de las consultas
[ ]
[ ]
Permite estimar el consumo de recursos y tiempo de respuesta de una consulta
antes de su ejecución
No
[ ]
[ ]
Sí, en base a ejecuciones anteriores (especificar qué ocurre si
es la primera vez que se ejecuta dicha consulta
[ ]
[ ]
Sí, en base a otros criterios (especificar)
[ ]
[ ]
Dispone de alguna herramienta que en base a estadísticas de ejecución
haga recomendaciones sobre el diseño del Data Warehouse
No
[ ]
[ ]
Sí, con la ayuda del usuario final
[ ]
[ ]
Sí, hace las recomendaciones automáticamente, sin necesitar
al usuario final
[ ]
[ ]
En caso afirmativo, explicar en qué consisten dichas recomendaciones
Observaciones
. Asignación dinámica de recursos
Es posible definir threads de consulta con diferentes prioridades de acceso para
queries simultáneas
[ ]
[ ]
Indicar el abanico de prioridades asignadas a dichos threads
Los posibles criterios de definición de dichos threads
Por tiempo estimado de ejecución de la consulta
[ ]
[ ]
Por perfil de usuario
[ ]
[ ]
Por grupo de usuario
[ ]
[ ]
Por consulta específica
[ ]
[ ]
Por volumen estimado de datos a recuperar
[ ]
[ ]
Ventana de ejecución (temporal)
[ ]
[ ]
Otras (especificar)
[ ]
[ ]
Observaciones
. Limitación del consumo de recursos en las consultas
Posibilidad de la herramienta de limitar el consumo de recursos
No
[ ]
[ ]
Sí. La herramienta lo hace automáticamente, sin pedir confirmación
al usuario y sin tener en cuenta el perfil de usuario
[ ]
[ ]
Sí. Se pide confirmación al usuario siempre para lanzar o no la
consulta independientemente del perfil del mismo
[ ]
[ ]
Sí. Para ciertos perfiles se limita automáticamente
y para otros no se limita
[ ]
[ ]
Sí. Para ciertos perfiles se limita automáticamente y para otros
se pide confirmación al usuario para lanzar o no la consulta
[ ]
[ ]
Permite evitar la ejecución de una consulta si el tiempo estimado de ejecución
es superior a un umbral definido
No
[ ]
[ ]
Sí, totalmente
[ ]
[ ]
Sí, pero permite al menos la ejecución batch de la consulta para
cualquier perfil de usuario final
[ ]
[ ]
Sí, pero permite al menos la ejecución batch de la consulta
para ciertos perfiles
[ ]
[ ]
Permite evitar la ejecución de una consulta si el número estimado
de filas a devolver es superior a un umbral definido
No
[ ]
[ ]
Sí, totalmente
[ ]
[ ]
Sí, pero permite al menos la ejecución batch de la consulta para
cualquier perfil de usuario final
[ ]
[ ]
Sí, pero permite al menos la ejecución batch de la consulta
para ciertos perfiles
[ ]
[ ]
Permite evitar la ejecución de una consulta si el número estimado
de filas a acceder es superior a un umbral definido
No
[ ]
[ ]
Sí, totalmente
[ ]
[ ]
Sí, pero permite al menos la ejecución batch de la consulta para
cualquier perfil de usuario final
[ ]
[ ]
Sí, pero permite al menos la ejecución batch de la consulta
para ciertos perfiles
[ ]
[ ]
Permite evitar la ejecución de una consulta si el volumen estimado de
datos a devolver es superior a un umbral definido
No
[ ]
[ ]
Sí, totalmente
[ ]
[ ]
Sí, pero permite al menos la ejecución batch de la consulta para
cualquier perfil de usuario final
[ ]
[ ]
Sí, pero permite al menos la ejecución batch de la consulta
para ciertos perfiles
[ ]
[ ]
Permite evitar la ejecución de una consulta si el volumen estimado de
datos a acceder es superior a un umbral definido
No
[ ]
[ ]
Sí, totalmente
[ ]
[ ]
Sí, pero permite al menos la ejecución batch de la consulta para
cualquier perfil de usuario final
[ ]
[ ]
Sí, pero permite al menos la ejecución batch de la consulta
para ciertos perfiles
[ ]
[ ]
Cancela automáticamente la ejecución de una consulta cuando el
tiempo de respuesta sobrepasa un umbral definido
No
[ ]
[ ]
Sí, totalmente (no devuelve nada) independientemente del perfil de usuario
[ ]
[ ]
Sí, totalmente (no devuelve nada) para ciertos perfiles de usuario, y
para otros no la cancela
[ ]
[ ]
Sí, pero devuelve al menos la información recuperada hasta ese
momento,independientemente del perfil de usuario
[ ]
[ ]
Cancela automáticamente la ejecución de una consulta cuando el
número de filas devueltas sobrepasa un umbral definido
No
[ ]
[ ]
Sí, totalmente (no devuelve nada) independientemente del perfil de usuario
[ ]
[ ]
Sí, totalmente (no devuelve nada) para ciertos perfiles de usuario, y
para otros no la cancela
[ ]
[ ]
Sí, pero devuelve al menos la información recuperada hasta ese
momento,independientemente del perfil de usuario
[ ]
[ ]
Cancela automáticamente la ejecución de una consulta cuando el
número de filas accedido sobrepasa un umbral definido
No
[ ]
[ ]
Sí, totalmente (no devuelve nada) independientemente del perfil de usuario
[ ]
[ ]
Sí, totalmente (no devuelve nada) para ciertos perfiles de usuario, y
para otros no la cancela
[ ]
[ ]
Sí, pero devuelve al menos la información recuperada hasta ese
momento, independientemente del perfil de usuario
[ ]
[ ]
Cancela automáticamente la ejecución de una consulta cuando el
volumen de información recuperado sobrepasa un umbral definido
No
[ ]
[ ]
Sí, totalmente (no devuelve nada) independientemente del perfil
de usuario
[ ]
[ ]
Sí, totalmente (no devuelve nada) para ciertos perfiles de usuario, y
para otros no la cancela
[ ]
[ ]
Sí, pero devuelve al menos la información recuperada hasta ese
momento, independientemente del perfil de usuario
[ ]
[ ]
Cancela automáticamente la ejecución de una consulta cuando el
volumen deinformación accedido sobrepasa un umbral definido
No
[ ]
[ ]
Sí, totalmente (no devuelve nada) independientemente del perfil de usuario
[ ]
[ ]
Sí, totalmente (no devuelve nada) para ciertos perfiles de usuario, y
para otros no la cancela
[ ]
[ ]
Sí, pero devuelve al menos la información recuperada hasta ese
momento, independientemente del perfil de usuario
[ ]
[ ]
Permite rechazar consultas en base a la franja horaria
No
[ ]
[ ]
Sí, totalmente
[ ]
[ ]
Sí, pero permite al menos la ejecución batch de la consulta para
cualquier perfil de usuario final
[ ]
[ ]
Sí, pero permite al menos la ejecución batch de la consulta
para ciertos perfiles
[ ]
[ ]
Permite rechazar consultas en base a la carga del sistema
No
[ ]
[ ]
Sí, totalmente
[ ]
[ ]
Sí, pero permite al menos la ejecución batch de la consulta para
cualquier perfil de usuario final
[ ]
[ ]
Sí, pero permite al menos la ejecución batch de la consulta
para ciertos perfiles
[ ]
[ ]
Observaciones
- GESTIÓN DE ACCCESO Y EJECUCIÓN
. Seguridad de acceso
Indicar los niveles de seguridad soportados
Por usuario
[ ]
[ ]
Por grupo de usuario
[ ]
[ ]
Por consulta específica
[ ]
[ ]
Otros (especificar)
[ ]
[ ]
En qué plataforma se gestiona la seguridad
Puesto cliente
[ ]
[ ]
Servidor intermedio
[ ]
[ ]
Servidor central
[ ]
[ ]
Se realiza una identificación del usuario a la hora de acceder al sistema
No
[ ]
[ ]
Sí, sin password
[ ]
[ ]
Sí, con password
[ ]
[ ]
Almacenamiento físico de la password
Fichero plano
[ ]
[ ]
Base de datos propia
[ ]
[ ]
Base de datos externa (especificar los gestores soportados en observaciones)
[ ]
[ ]
Otros (especificar)
[ ]
[ ]
Localización física de la password
Puesto cliente
[ ]
[ ]
Servidor intermedio
[ ]
[ ]
Servidor central
[ ]
[ ]
Otros (especificar)
[ ]
[ ]
Se permite a nivel de seguridad auditar las operaciones realizadas por los diferentes
usuarios
[ ]
[ ]
En caso afirmativo, ¿cómo se almacena esta información?
Ficheros planos
[ ]
[ ]
Base de datos propia
[ ]
[ ]
Base de datos externa (especificar los gestores soportados en observaciones)
[ ]
[ ]
Otros (especificar)
[ ]
[ ]
En caso afirmativo, dónde se almacena esta información
Puesto cliente
[ ]
[ ]
Servidor intermedio
[ ]
[ ]
Servidor central
[ ]
[ ]
Otros (especificar)
[ ]
[ ]
Observaciones
. Limitaciones a nivel de acceso
Número máximo de accesos concurrentes para el mismo usuario
[ ]
[ ]
Número máximo de usuarios concurrentes
[ ]
[ ]
Existe la posibilidad de limitar el acceso a la información a nivel de
registro
[ ]
[ ]
En caso afirmativo, en base a qué criterio
Por consulta específica
[ ]
[ ]
Por grupo de usuario
[ ]
[ ]
Por usuario
[ ]
[ ]
Otros (especificar)
[ ]
[ ]
Es posible lanzar desde un mismo puesto cliente una consulta, y sin esperar a
recibir la respuesta lanzar otra
[ ]
[ ]
Observaciones
. Prioridades de ejecución
Se pueden establecer distintos grados de prioridad a la hora de ejecutar varias
consultas
[ ]
[ ]
En base a qué criterios se pueden dar prioridades de ejecución
Por usuario
[ ]
[ ]
Por grupo de usuario
[ ]
[ ]
Consultas específicas
[ ]
[ ]
Otros (especificar)
[ ]
[ ]
Observaciones
ACLARACIONES GENERALES
Observaciones
REFERENCIAS
Resumen de las principales instalaciones donde se encuentran instaladas las herramientas
propuestas, con una breve descripción del entorno tecnológico y de los volúmenes de información
manejados
Observaciones
4.- PRUEBAS DE VERIFICACIÓN Y CONTROL
Un Data Warehouse precisa de un conjunto de pasos desde su creación hasta su explotación final. En todos estos pasos se precisa de una herramienta que nos permita simplificar su ejecución. Debido a la amplia variedad de herramientas disponibles, y para asegurar la idoneidad de la herramienta, caben varias alternativas:
Evaluación distribuida: En ella se evaluaría cada herramienta en un paso concreto. Se vería cual es la que mejor se adapta a nuestras necesidades, y a continuación, examinaríamos la compatibilidad en cascada de todas ellas.
Evaluación centralizada: En ella se evaluaría el soporte que cada herramienta proporciona a todos los pasos, y a continuación se examina cual es la que globalmente se adecua de forma global a nuestras necesidades.
La elección de una u otra alternativa tiene sus ventajas e inconvenientes: la primera nos permitiría obtener la mejor herramienta (la de mejor relación cumplimiento expectativas/ precio), pero podría comprometer la cadena completa de uso de un Data Warehouse. Lo contrario ocurriría en la segunda alternativa.
Debido a la creciente información disponible de cada fabricante en Internet, y a su frecuente actualización, recomendamos la visita al Data Warehousing Information Center (LGI Systems Incorporated), desde su página principal en http://pwp.starnetinc.com/larryg/index.html en donde, desde donde se encuentran enlaces a:
Vendedores de herramientas de usuario final:
• Herramientas de Query and Reporting
• Bases de Datos OLAP y Multidimensionales
• Sistemas EIS (Executive Information Systems)
• Herramientas de Data Mining
• Recuperación de Documentos
• Sistemas de Información Geográfica (GIS)
• Herramientas de Análisis de Decisiones
• Estadísticas
• Modelado de Procesos
• Filtrado de Información
• Obtención de Informes
• Otras herramientas
Vendedores de Infraestrutura Tecnológica:
• Extracción de Datos, Limpieza y Carga
• Catalogación de la Información
• Bases de Datos para Data Warehousing
• Administración de Consulas y Almacenamiento
• Modelado de Datos para Data Warehouse
• Herramientas iddleware
• Aceleradoras de Query's y Carga
• Otras utilidades de BD
• Hardware
Vendedores por Función e Industria:
• Herramientas de Análisis Financiero
• Herramientas de Marketing y Análisis de Ventas
• Herramientas de Análisis de la cadena de suministro
• Herramientas para la Industria de la Salud
• Herramientas para la Industria Detallista
• Herramientas para el Sector Financiero
• Otras herramientas específicas
Suscribirse a:
Entradas (Atom)
