Printer Friendly

A Methodology for Data WareHousing Processes Based on Experience/Una Metodologia para Procesos Data WareHousing Basada en la Experiencia.

1. Introduccion

Actualmente las organizaciones utilizan la informacion y el conocimiento para apoyar la toma de sus decisiones estrategicas, y de este modo lograr sus metas y mejorar sus procesos. Lo anterior, en un contexto actual de alta competitividad y requerimiento de certificacion de procesos, globalizacion de mercados, etc. En el ambito de educacion superior, las universidades en Chile se encuentran en procesos de alta exigencia para asegurar la calidad en su gestion administrativa y academica, a traves de procesos de acreditacion institucional donde estas instituciones deben rendir cuentas de toda su actividad academica.

Uno de los desafios que enfrentan hoy las organizaciones, es el aumento de datos, lo que ha generado dos grandes problemas; el primero, identificar los datos relevantes para dar seguimiento a su estrategia organizacional, y lograr que se cumplan los planes con las metas establecidas. Y el segundo problema, la capacidad para administrar esta gran cantidad de datos.

Para lo anterior, las organizaciones requieren no solamente sistemas de informacion para dar soporte tecnologico a sus procesos operacionales, sino que requieren de soluciones tecnologicas que les proporcionen, por un lado, indicadores que les permitan medir el desempeno de sus procesos de gestion en general y, por otro lado, patrones o reglas que les permitan describir o predecir comportamientos en sus movimientos o transacciones de sus procesos de negocios. Todo esto, para apoyar la toma de decision estrategica de una manera mejor preparada (Illescas, Sanchez & Canziani, 2015), (Prieto & Piattini, (2015).

Lo descrito se puede lograr con el uso de tecnologias y herramientas de analisis de datos masivos, que permiten la administracion y generacion de conocimiento utilizando data historica de la organizacion. Entre estas tecnologias se encuentran; herramientas ETL, almacenes de datos o Data Warehouse (DW), herramientas OLAP, mineria de datos y otras. Y que son parte de lo que se conoce como Inteligencia de Negocios (IN o BI; acronimo del ingles Business Intelligence).

Una definicion formal de IN, es que corresponde al conjunto de estrategias y herramientas tecnologicas enfocadas a la administracion y creacion de conocimiento, a traves del analisis de datos existentes en una organizacion (Back, 2002) (Golfarelli, Rizzi & Cella, 2004). Si bien un DW corresponde al repositorio de datos central de un sistema de IN, su diseno, desarrollo e implementacion son parte de lo que se denomina Proceso de Data Warehousing (PDW).

Estas tecnologias son muy demandadas actualmente por las organizaciones, que teniendo satisfechas las prestaciones tecnicas de sus sistemas informaticos para apoyar los procesos operacionales, requieren de nuevas prestaciones que les permitan mantenerse competitivas en un entorno cambiante y globalizado, siendo los DW una de las tecnologias IN con mas desarrollo de proyectos en Chile (Palocsay, Markham & Markham, 2010).

En las instituciones de educacion superior, tambien ha ido en aumento la cantidad de universidades, que utilizan la tecnologia de IN para obtener indicadores de su gestion, y con esto enfrentar de mejor manera un proceso de acreditacion. Para esto, requieren contar con: unidades administrativas de analisis institucional, recurso humano preparado en tecnologia de IN, herramientas de IN, y proyectos de desarrollo de sistemas orientados hacia la toma de decisiones estrategicas.

Bajo este contexto, el articulo presenta y describe una metodologia para el desarrollo de PDW que se basa principalmente en la experiencia de desarrollo de varios proyectos llevados a cabo en la Universidad Arturo Prat de Chile (UNAP). Proyectos orientados a obtener indicadores de productividad academica y de gestion de la universidad. No obstante, para elaborar y formalizar esta nueva metodologia, se toman como base conceptual dos modelos de desarrollo de PDW, por un lado, el modelo clasico de desarrollo para un DW de (Kimball & Ross, 2002), combinado con la actual metodologia Hefesto de (Bernabeu, 2010), de ambas se extraen las fases comunes y se refunden.

Adicionalmente, la metodologia propuesta integra diversos enfoques, tecnicas y metodologias, tales como: especificacion de requisitos de informacion utilizada en ingenieria de software, proceso aumentado de ETL con una fase de validacion de indicadores (ETL+V; Extraction, Transformation, Loading, and Validation), y visualizaciones integradas e interactivas para el analisis multidimensional de los indicadores, basado en el concepto de tablero de control (dashboard en ingles).

La estructura del articulo es la siguiente: la seccion 2 provee un marco teorico sobre conceptos y tecnologias asociadas al trabajo. La seccion 3 describe la metodologia propuesta. La seccion 4 presenta la aplicacion de esta metodologia en el desarrollo de un PDW para la generacion de indicadores de productividad academica de una universidad. En la seccion 5 se presentan las conclusiones del trabajo. Finalmente, en la seccion 6 se listan las referencias bibliograficas.

2. Marco Teorico

En esta era conocida como la sociedad del conocimiento, una de las caracteristicas tecnologicas es la utilizacion y consolidacion de las bases de datos, para el registro de transacciones a traves de Internet, lo cual representa actualmente, la herramienta principal que proporciona informacion en una organizacion. Sin embargo, con el paso de los anos esta informacion tiende a crecer y generar grandes volumenes de datos, por lo que surge la necesidad de como manejarla y que hacer con ella. Es aqui donde aparece el termino IN, que surge como solucion para analizar y explotar areas especificas de informacion, generando nuevas perspectivas y conocimiento con el fin de apoyar la toma de decisiones.

Una de las primeras definiciones de IN se conoce a partir de 1958 con Hans Petter Luhn, investigador de IBM que lo define como: "La habilidad de aprehender las relaciones de hechos presentados de forma que guien las acciones hacia una meta deseada" (Conesa & Curto, 2010), para luego en la decada de los 60 dar origen a los Sistemas de Soporte de Decisiones (SSD). Luego evolucionan en Sistemas de Informacion Ejecutivos (SIE), que son sistemas mas robustos capaces de generar reportes consolidados. Si bien estos sistemas cumplen su labor en la administracion de la informacion, aun son insuficientes, ya que estas herramientas no cuentan adecuadamente, con visualizacion y explotacion de la informacion.

El termino IN se acuna formalmente en el ano 1989 por Howard Dresden, analista de Gartner que lo define como: "Conceptos y metodos para mejorar las decisiones de negocio mediante el uso de sistemas de soporte basado en hechos" (Venter, 2005). IN actualmente se encuentra presente en las organizaciones mas prestigiosas del mundo, ya que sirve como respaldo y soporte a la toma de decisiones de la parte estrategica de una organizacion, mediante el analisis de gran cantidad de datos en forma rapida y sencilla, que son procesados segun reglas y criterios del negocio. IN es un concepto que se aplica de forma transversal a cualquier tipo de negocio, ademas de integrar informacion de diferentes procesos, en distintos periodos, generando un analisis completo de la situacion actual de la organizacion, con el fin de progresar en el rendimiento interno de sus procesos.

Desde un punto de vista pragmatico, IN es el conjunto de estrategias y herramientas enfocadas a la administracion y creacion de conocimiento a traves del analisis de datos existentes en una organizacion. Esto permite a la organizacion, contar con informacion privilegiada para responder a problemas internos del negocio como: optimizacion de costos, rentabilidad tanto de clientes, obtener perfiles de clientes, mejorar procesos de produccion entre otras, todo lo anterior se puede responder de forma rapida y eficiente, con un buen proceso e implementacion de la IN, lo cual brinda a la organizacion una ventaja competitiva y estrategica en el mercado (Mazon, Trujillo & Lechtemborger, 2007).

Una de las tecnologias centrales de IN son los DW y DataMart (DM). Segun la clasica y mas referenciada definicion de Inmon, un DW: "es una coleccion de datos orientada a un determinado ambito (empresa, organizacion, etc.), integrado, no volatil y variable en el tiempo, que ayuda a la toma de decisiones en la entidad en la que se utiliza" (Inmon, 2005).

Un DW corresponde al almacen de datos corporativo que abarca todas las areas o procesos de la organizacion. El origen de esta informacion proviene de diferentes fuentes de datos, ya sean de sistemas operacionales, plantillas de calculos o archivos de textos planos. Estas fuentes de datos se integran para darle un formato homogeneo y consistente a los datos. Ademas, un DW se compone de bases de datos multidimensionales denominadas DM, que se enfocan al analisis de un area de negocio en particular, y tiene como objeto proporcionar indicadores o KPI.

Existen 2 enfoques respecto a los conceptos DW y DM (Kimball & Ross, 2002):

* Bill Inmon propone la idea que los DM se sirven de un DW para extraer informacion que esta almacenada de manera estructurada en un modelo relacional, a esto se le conoce como enfoque top-down.

* Ralph Kimball, plantea la idea de un enfoque dimensional para el diseno de un DW, y afirma que la union de todos los DM de una organizacion constituye el DW corporativo, a lo cual se le conoce como el enfoque bottom-up.

El esquema convencional de un sistema de IN lo componen las siguientes etapas (Vaisman & Zimanyi, 2014):

i. Especificacion de requisitos estrategicos; que corresponde a la definicion del proyecto IN, la naturaleza del negocio y sus propositos, asi como la especificacion de indicadores claves de desempeno (Key Performance Indicator o KPI), que se requieren medir en los procesos de la organizacion.

ii. El proceso ETL; tiene como funcion la integracion de los datos provenientes desde las distintas fuentes heterogeneas, ya sean de sistemas transaccionales, archivo de textos, planillas de calculos, etc. La integracion consiste en la extraccion, transformacion, calculos preliminares de KPI, limpieza y homogenizacion de datos, y carga de datos en el DW. Para esto, se pueden utilizar herramientas ETL, lenguajes de programacion y/o lenguaje de consultas de base de datos relacional (Structured Query Language o SQL).

iii. El DW; corresponde al repositorio de datos, cuyo diseno conceptual esta basado en un Modelo Multidimensional (MM). Esto es, considera a la base de datos como un conjunto de hechos u objeto de analisis, y dimensiones que son los puntos de vistas desde los que se pueden analizar estos hechos. Las informaciones relevantes sobre los hechos se representan por un conjunto de indicadores o medidas (valores numericos) y que corresponde a los KPI a calcular. La informacion descriptiva de cada dimension se presenta por un conjunto de atributos alfanumericos. La tecnologia utilizada por lo general son sistemas gestores de base de datos relacionales.

iv. Explotacion del DW; a traves de herramientas de analisis de datos tales como: OLAP (On-Line Analytical Processing), data mining, generadores de reportes y graficos estadisticos, dashboard, y en general todo tipo de SSD.

Como se senala en la seccion anterior, un PDW corresponde al proceso que permite el diseno, implementacion y explotacion de un DW. Por lo general, un PDW incluye las estrategias y tecnologias descritas en i), ii), iii), y respecto a la explotacion del DW, las que tienen relacion al procesamiento analitico en linea (OLAP).

3. Metodologia Propuesta

La metodologia elaborada y propuesta en este trabajo, recoge la experiencia obtenida por el desarrollo de diferentes proyectos de PDW, orientados a generar indicadores o KPI que miden el desempeno y productividad, tanto academica como de gestion, de una universidad chilena. Desde el punto de vista conceptual, esta metodologia integra diversos enfoques, tecnicas y metodologias.

La elaboracion de esta metodologia, se basa en el modelo clasico de desarrollo para un DW de (Kimball & Ross, 2002) combinado con la actual metodologia Hefesto de (Bernabeu, 2010), de ambas se extraen las fases comunes y se refunden. La metodologia de Kimball se basa en lo que denomina Ciclo de Vida Dimensional del Negocio (Business Dimensional Lifecycle). Se consideran de esta metodologia las siguientes etapas: definicion de requerimientos del negocio, modelado dimensional, diseno fisico, y diseno e implementacion del subsistema ETL. Por otro lado, la metodologia Hefesto consta de 4 etapas: analisis de requerimientos, analisis de los OLTP, modelo logico del DW, e integracion de datos. Estas etapas son consideradas, pero refundiendolas y dando un orden de desarrollo distinto.

Como se puede observar en la Figura 1, se funden las primeras etapas de ambas metodologias, en una sola etapa inicial llamada Analisis en la nueva metodologia, agregando a esta la segunda etapa de Hefesto (analisis de los OLTP). Luego, se combinan las etapas modelado dimensional y diseno fisico de Kimball con la tercera etapa de Hefesto (modelo logico del DW), lo que da a lugar la segunda etapa denominada Diseno MM. En la tercera etapa denominada Proceso ETL+V, se integra la etapa diseno e implementacion del subsistema ETL de Kimball, con la etapa integracion de datos de Hefesto. La cuarta etapa Procesamiento Analitico, corresponde a una fusion entre lo que propone Kimball en su ciclo de vida de un DW y las de varios autores, que consideran a OLAP, como una opcion de herramienta, entre otras, para la explotacion del almacen y no como parte de su metodo de desarrollo.

Cada una de estas etapas tienen definidas sus entradas y salidas, representadas a traves de flechas con linea segmentada. A su vez, estas etapas tienen un sentido bidireccional de funcionamiento, que permite retroceder a la anterior o avanzar a la siguiente, sin perder el sentido del PDW. Tambien, se establece la relacion y participacion de los usuarios, con flecha de linea continua y en sentido bidireccional, tanto en la entrada al proceso, como en la salida.

Se destacan en esta metodologia, elementos claves senalados de la Figura 1 con un circulo de color rojo: plantilla ad-hoc para la especificacion de los KPI, repositorio temporal como area de staging, el codigo SQL de validacion de los KPI, y las visualizaciones graficas integradas a traves de tableros de control o dashboard. Lo anterior, segun las conclusiones del equipo de desarrollo del DW y los usuarios finales, favorecieron la efectividad y exito del desarrollo de los proyectos en que se ha utilizado esta metodologia. Se explica a continuacion, cada una de las etapas de la metodologia propuesta en este trabajo.

3.1. Etapa Analisis.

Esta etapa inicial se vincula fuertemente con los usuarios estrategicos. Consta de dos actividades; analisis de los requerimientos de KPI, y analisis de los sistemas operacionales. Para la primera actividad, la entrada corresponde a una plantilla ad-hoc disenada para la especificacion de los requisitos de informacion estrategica o KPI. La estructura de esta plantilla, es considerada como uno de los elementos claves en el PDW, y se disena tomando como referencia las plantillas y patrones linguisticos de (Duran, 2000), que estan enfocados para el proceso de educcion de requisitos de informacion en un proyecto de software. Esta plantilla, permite definir y entender claramente, por parte de todos los usuarios, los indicadores obtenidos, tanto como interfaz o herramienta, en la educcion inicial de los requisitos de KPI, su analisis, asi como en la validacion de cada uno. La salida de esta actividad, es el conjunto de KPI especificados a traves de la plantilla disenada.

La segunda actividad de esta etapa, corresponde al analisis de los sistemas operacionales, cuyas entradas la componen las fuentes de datos de la organizacion, ya sean internas o externas, mas toda la informacion acerca de los datos que se dispongan, tales como modelo dato-logico, meta-datos, etc. Estas fuentes de datos, deben ser analizadas para contrastar los KPI especificados, y entender con que datos poder realizar sus calculos, o en caso de no contar con ellos poder obtenerlos. Tiene como salida esta actividad, el meta-datos con la seleccion de tablas, atributos y datos, que son necesarios para lograr calcular los KPI requeridos.

3.2. Etapa Diseno del MM.

Las salidas de la etapa de analisis, son las entradas en esta etapa. Y en ella, se encuentran dos actividades; el diseno conceptual y el diseno fisico (relacional) del MM, cuyas salidas, corresponden a los modelos bajo el mismo nombre, conceptual y fisico respectivamente. Para esto, es necesario analizar los KPI especificados junto al meta-datos de las fuentes de origen, para poder realizar el diseno conceptual. La parte tecnologica de esta etapa la constituye las bases de datos.

Se recomienda utilizar una herramienta de la tecnologia CASE (Computer Aided Software Engineering), donde se puede utilizar una de las notaciones graficas existentes para diagramar el MM, ya sea entidad-relacion, UML (Unified Modeling Language), u otra. Para generar el diseno fisico del MM, en este caso relacional ya que se utiliza el enfoque de Kimball, basta con utilizar la opcion en la herramienta CASE para generarlo, indicando algunos parametros como: el motor de base de datos, nombre del servidor, y otros datos de conexion.

3.3. Etapa Proceso ETL+V.

La tercera etapa atane al clasico proceso ETL de extraccion, transformacion y carga, aumentado con una cuarta actividad incorporada explicitamente, y denominada validacion de KPI. Se trata de la etapa mas tecnica y que mayor tiempo demanda, la de mayor complejidad, y la que mas entradas y salidas tiene. Las entradas a esta etapa son; la especificacion de los KPI, el MM relacional, la descripcion (meta-datos) de los datos seleccionados, y las fuentes de datos originales. Sus salidas corresponden a; diagrama de flujo de trabajo del proceso ETL (generada a traves de una herramienta o software para esto, tal como Kettle de Pentaho u otras, o simplemente con el uso de lenguaje SQL), el repositorio temporal o area de staging, los DM cargados con los KPI, y el codigo SQL de validacion.

La etapa ETL+V, cuya variante es la mas destacada en este trabajo, tiene como funcion realizar toda la extraccion y calculo preliminar de los datos desde las fuentes de datos originales, y que necesarios para el calculo de los KPI, para luego ser depositados en el repositorio temporal relacional. En este repositorio, se realizan todas las transformaciones, calculos, agregaciones y validaciones de calidad de los datos. Tambien se debe realizar la actividad de carga de los datos hacia los DM con los KPI ya calculados.

Sin embargo, antes de la carga es necesario verificar la validez de los KPI. Para esto, la actividad de validacion, permite realizar la revision de estos en forma eficiente, utilizando el lenguaje de consulta para base de datos relacionales (SQL), y asi poder realizar consultas, calculos y validaciones necesarias. Se trata de verificar que los KPI obtenidos sean consistentes, con los datos integrados en el repositorio temporal, las fuentes de datos originales, y el DM.

3.4. Etapa Procesamiento Analitico.

La ultima etapa corresponde a la explotacion y analisis de la informacion contenida en los DM, y para esto se requiere una herramienta de la tecnologia OLAP, con la cual generar el analisis multidimensional de los datos, y las visualizaciones graficas de los KPI. Adicionalmente, se considera como segunda actividad la integracion de visualizaciones de los distintos objetos de analisis y KPI, utilizando el concepto de tablero de control o dashboard (Marcus, 2006), y que permiten proporcionar a los usuarios finales, una mirada integral de los indicadores provistos por los DM, a traves de interfaces graficas y con reportabilidad interactiva e intuitiva.

4. Caso de Uso: PDW de Productividad Academica

Se describe a continuacion, la aplicacion de la metodologia propuesta para un caso de uso en particular, y que corresponde a un PDW cuyo objetivo es generar indicadores de productividad academica de una universidad chilena.

4.1. Descripcion de la Problematica.

En su plan estrategico institucional, la UNAP declara como eje estrategico la "Gestion Moderna y competitiva", que apunta a administrar de manera eficiente los procesos de gestion institucional tanto en recursos humanos, infraestructura y sistemas de informacion. Para esto, se requiere el fortalecimiento de los sistemas de informacion a nivel de reportes de indicadores, para la toma de decisiones internas en vicerrectorias, sedes, facultades y centros docentes de la institucion.

La Unidad de Analisis Institucional (UAI) de la UNAP, es la encargada de generar y administrar los DM de la institucion, con el fin de poder entregar informes tanto cualitativos como cuantitativos del estado actual de la gestion de las diferentes areas de la institucion. Para esta ocasion, la UAI plantea la necesidad del desarrollo de un PDW cuyo objetivo es obtener indicadores sobre la productividad academica. Esto, con el proposito de dar respuesta a requerimientos de informacion tanto de entidades internas y externas a la Universidad. Ademas, se busca definir y establecer criterios para la obtencion de estos indicadores.

Por lo anterior, se realiza un analisis de los procesos de internos involucrados en la productividad academica de todos los funcionarios del estamento academico de la institucion. Se plantean tres aspectos fundamentales dentro de sus actividades que son: docencia, investigacion y vinculacion con el medio. Para este trabajo, se llega a acuerdo en abordar en las dos primeras labores, ya que son las mas requeridas en el trabajo diario de la universidad.

En cuanto a la actividad de docencia, los indicadores buscan conocer como es la distribucion del personal academico en las distintas institutos, sedes, facultades y carreras de la universidad, como tambien la cantidad de horas semanales que dedican a sus labores docentes. Tambien es relevante conocer la cantidad de jornadas completas equivalentes que los docentes representan en la institucion, ya que es un indicador que se compara con la cantidad de alumnos matriculados, con el fin de establecer la relacion que existen entre ellos.

En lo que concierne a la actividad de investigacion, los indicadores deben permitir establecer la produccion cientifica de la universidad, a traves de medidas tales como la cantidad de publicaciones y proyectos de investigacion realizadas por los academicos de las distintas institutos, sedes, facultades y carreras. Ademas, se buscan determinar porcentajes y tasas de aumento entre los periodos estudiados. Otro aspecto importante es, conocer el porcentaje de docentes con grado de doctor que realizan las labores de investigacion, ya que con este indicador se pueden tomar medidas preventivas o de incentivo, para aumentar la productividad cientifica, y de ser necesario, contratar nuevos academicos con grado de doctor.

4.2.Etapa Analisis: Requerimientos de KPI.

La toma de requerimientos se lleva a cabo a traves de tecnicas de educcion que son utilizadas en un proceso de software, con la salvedad que el tipo de usuario corresponde al nivel estrategico de la institucion. Por lo anterior, se realizan un conjunto de reuniones ejecutivas con las dos vicerrectorias (academica y de investigacion) en conjunto con la UAI, que estan directamente ligadas a la problematica, con el fin de tomar las inquietudes y necesidades sobre la productividad academica de estas entidades tanto en sus actividades docentes y de investigacion. Y de este modo, lograr definir y especificar los KPI requeridos.

Tambien, se consideran relevante en esta etapa, los requerimientos externos provistos por instituciones de gobierno y otras, tales como: Consejo Nacional de Acreditacion (CNA), Sistema de Informacion de Educacion Superior (SIES), Consejo de Rectores de Universidad Chilenas (CRUCH), y el Consejo Nacional de Educacion (CNED). Por esto, se realiza tambien un analisis de todos los informes entregados por estas instituciones, y de sus instructivos de solicitud de informacion. Con ambas visiones, interna y externa, se consolidan los requerimientos de productividad academica, de docencia y de investigacion, utilizando la plantilla de requerimientos ad-hoc disenada para esta actividad. Como muestra se presenta en la Figura 2, la especificacion de un KPI de investigacion, y uno de docencia en la Figura 3, de un total de catorce especificados (7 de cada uno).

Se puede observar en ambas figuras, la detallada especificacion del indicador que incluye, no solo su descripcion y objetivo, sino que ademas su periodicidad, las dimensiones involucradas, las formulas sobre la cual se calculan los KPI. Toda esta informacion es acordada y validad por los usuarios estrategicos, y la plantilla sirve como interfaz de comunicacion en todo el proceso de educcion de requerimientos.

4.3. Etapa Analisis: Sistemas Operacionales.

Una vez definidos los indicadores, se prosigue con la identificacion de las fuentes de datos que son necesarias para su calculo. Para esta actividad, es necesario reunirse con la Unidad de Informatica y Comunicaciones (UNICO) de la institucion, en conjunto con la UAI, con el objeto de identificar los diferentes modelos de datos involucrados y seleccionar las fuentes de datos. Luego de varias revisiones y analisis a los sistemas de informacion que maneja la UNAP, se filtran los que se van a utilizar, dando como resultado los que se listan en la Tabla 1.

Se obtiene de esta actividad; el listado de los sistemas que contienen los datos a utilizar, el meta-datos de estos, su modelo dato-logico, y se seleccionan las tablas y atributos especificos que se requieren para el calculo de los KPI.

4.4.Etapa Diseno: MM Conceptual.

Debido a que la UNAP cuenta con algunos DM previamente desarrollados, es necesario conocer las dimensiones que se encuentran presentes en estos, con el objeto de reutilizar la informacion en la elaboracion de los nuevos DM, y asi evitar la redundancia de datos junto con la duplicidad de dimensiones a nivel institucional. Luego de analizar los requerimientos y modelos existentes, se elaboran dos MM, para cumplir con los indicadores a obtener.

Uno de estos modelos enfocado a los indicadores de docencia, y el otro de investigacion. El primer modelo es del tipo esquema "Copo de Nieve" (Snowflake), donde se hace un trabajo de jerarquizacion de algunas dimensiones, y reutilizacion de otras. Por otro lado, el DM de investigacion es un esquema estrella, y la gran mayoria de sus dimensiones son creadas en este trabajo. Las dimensiones utilizadas en este PDW, se puede ver en la Tabla 2.

En cuanto a los indicadores de ambos MM, se presentan en las Figuras 4 a) y b), en sus respectivas tablas hechos con los KPI especificados para el esquema copo de nieve de docencia, y estrella de investigacion.

En la Tabla 3 se describen cada uno de los indicadores considerados en el diseno conceptual del MM, para estas dos tablas de hechos.

Una vez definidas las componentes (hechos y dimensiones), se diagraman los disenos conceptuales de ambos MM en una herramienta CASE, conectandolos a traves de las dimensiones comunes, y el nivel de las jerarquias que sea necesario. En este trabajo se utiliza la herramienta CASE PowerDesigner.

4.5. Etapa Diseno: Modelo Relacional del MM.

Una vez terminado el diseno conceptual, se genera el modelo relacional a traves de la herramienta CASE, generando el codigo script en lenguaje de definicion de datos (o DDL: Data Definition Language), indicando el motor de base de datos a utilizar en la implementacion. Se presenta como anexo al final del articulo, el MM en la Figura 12, esto debido al tamano de la imagen.

4.6. Etapa Proceso ETL+V: Extraccion.

Para este proceso, se utiliza la herramienta Pentaho's Data Integration (PDI), que permite modelar el proceso ETL con diagramas de flujos de transformaciones, que consisten en un conjunto de pasos fijos encapsulados en flujos integrados denominados trabajos (job), que pueden contener sentencias o script de ejecucion.

En la actividad de extraccion, se utiliza el meta-datos, donde esta registrada la informacion de las fuentes de datos seleccionadas, en conjunto con las especificaciones de los KPI, y se proceden a extraer los datos y se van dejando de manera agregada, en caso de ser necesario, directamente en el repositorio temporal. Se genera un flujo de trabajo que realiza las transformaciones necesarias para esta parte del proceso, y a modo de ejemplo se presenta en la Figura 5 un job que extrae informacion de los academicos.

4.7. Etapa Proceso ETL+V: Transformacion.

Al disenar dos DM, se opta por elaborar un flujo de trabajos para cada uno, lo cual permite una depuracion mas sencilla. En la Figura 6 a) se presenta el flujo de trabajo para el DM que calcula los indicadores de docencia. En la Figura 6 b), se presenta el flujo de trabajo para calcular los indicadores asociados a la actividad de investigacion. Cabe senalar, que solo se presentan los flujos de trabajos resumidos para ambos DM, y el detalle de cada transformacion se deja fuera por limitacion de numeros de paginas para el articulo

4.8. Etapa Proceso ETL+V: Carga.

La carga de las tablas hechos es la parte mas compleja de esta etapa, puesto que se debe realizar la comprobacion de los datos cargados o cambio de algun nodo de la transformacion. Antes de la carga, se deben verificar si los calculos obtenidos son validos en relacion a los datos en los sistemas operacionales. Para el DM de docencia, la transformacion que presenta la Figura 7, calcula las metricas a nivel mensual, y luego las carga a la tabla hechos de docencia.

Primero se realiza una limpieza de la carga anterior de los datos si es que es necesario, para que en el nodo "extra_docencia" de la Figura 7, ejecute la consulta que extrae los datos de las asignaturas impartidas a una carrera y la cantidad de horas involucradas. En los pasos siguientes se hacen cruces de informacion para extraer los identificadores unicos de las dimensiones que correspondan.

El nodo agrupa las dimensiones para realizar el calculo total de horas semanales de la actividad a una carrera en particular. Luego en el siguiente nodo, se suman todas las horas semanales calculadas con el fin de evitar duplicacion de informacion, y no romper las reglas de integridad al momento de cargar los datos. Posterior a este paso, se genera un filtro para separar los docentes segun su tipo de jornada, con el fin de poder calcular cual es su aporte a las JCE de su actividad. Finalmente, se procede a cargar la informacion a la tabla de hechos de docencia. Algo similar se realiza para el DM de investigacion.

4.9. Etapa Proceso ETL+V: Validacion de KPI.

Finalmente, se validan que los indicadores obtenidos sean iguales o semejantes a los que se puedan obtener desde los sistemas operacionales. Para esto, se utiliza como metodo de prueba, calcular cada indicador mediante una consulta SQL a la base de datos desde los sistemas transaccionales, comparandolo con la consulta que se genera con las tablas del MM. En la Figura 8, se muestra la validacion de un indicador de un total de 14. En particular, para este ejemplo se puede corroborar que el KPI esta bien calculado, ya que su valor corresponde a los datos de origen.

4.10. Etapa Procesamiento Analitico: OLAP.

Se presentan los resultados del DM mediante la explotacion y visualizacion de los indicadores a traves de la herramienta OLAP Qlikview. De esta forma se da respuesta a los requerimientos definidos y planteados en un comienzo del proyecto. Estos resultados son expuestos con graficas, las que permiten visualizar la informacion y poder realizar el analisis que corresponda. A modo de muestra, se presenta en la Figura 9, una grafica de un indicador de docencia. En total son 14 graficas, una por cada KPI.

4.11. Etapa Procesamiento Analitico: Dashboard.

Una vez generadas las graficas de los indicadores, se pueden integrar en un formato tipo tablero de control (dashboard), que permite a los usuarios finales, realizar un analisis multidimensional con distintos controles y mecanismos de interaccion. El dashboard que muestra la Figura 10, presenta una consolidacion de los indicadores relacionados a docencia en la cual, en los extremos tanto izquierdo como derecho, se encuentran las dimensiones manejadas por el modelo, y que pueden ser seleccionadas para cambiar los graficos presentados al interior del panel. Los datos resaltados en color verde significan las selecciones actuales, y los de color gris que esos valores no estan relacionados a la seleccion actual.

En la Figura 11, se muestran indicadores de proyectos de investigacion en un dashboard, que se pueden visualizar por diferentes dimensiones. Los graficos se encuentran agrupados en un elemento contenedor en la cual se muestra la pestana sobre la dimension en la que se muestra el indicador con algun grafico asociado.

5. Conclusiones

Para el desarrollo de un PDW, toma gran relevancia la comunicacion efectiva con las unidades con las que se realizan los trabajos en general. En particular, en el trabajo de educcion fue clave la plantilla de especificacion de requisitos de los KPI, ya que actuo como interfaz entre los usuarios estrategicos y el equipo del DW.

Durante el proceso de desarrollo de un DM, muchas veces se tiene que volver a un paso anterior para corregir o ajustar detalle del proceso en si, es decir, a prueba y error lo que se ve reflejado mayormente en el proceso ETL+V.

Un factor importante es el analisis y comprension, que se debe realizar sobre las estructuras de datos y modelos de los sistemas operacionales.

El desarrollo de un repositorio temporal, ayuda a dar repuesta eficiente a requerimientos operacionales durante la elaboracion de un DM.

La validacion de los KPI fue otro elemento clave en el proceso, ya que permitio generar confianza en el equipo, y las unidades de la institucion sobre los resultados obtenidos a traves del PDW.

Las visualizaciones graficas integradas a traves de los dashboard fueron muy bien valoradas por parte de los usuarios estrategicos.

Los resultados generaron un gran impacto en los usuarios, ya que en algunos casos los indicadores no se encontraban sobre la media de la institucion, por el contrario, existian casos que los resultados presentados eran bastante buenos y aceptables, sin embargo, esta presentacion de los resultados, implica que se tome cierta atencion a ello, con el fin de apoyar la toma de decisiones desde la perspectiva estrategica y asi" poder mantener y mejorar los indicadores en general.

Finalmente, la metodologia elaborada y utilizada en este PDW, fue muy valorada en general por la institucion, asi como en el equipo de trabajo.

En cuanto a trabajo futuro, si bien la metodologia tiene definidas sus etapas y funciones en cada una de estas, asi como tiene determinadas sus entradas y salidas en cada una de sus etapas, le falta establecer una formalizacion para que pueda responder a un proceso repetible. En esta linea, el trabajo a seguir es documentar detalladamente todos los aspectos y metodos de esta nueva metodologia. Asi como tambien aplicarlas en nuevos PDW, y realizar un analisis comparativo de los resultados con y sin la metodologia propuesta.

Submission/Recebido: 09/12/2017

Acceptance/Aceitacao: 06/02/2018

Referencias

Rocha, A. (2012). Framework for a Global Quality Evaluation of a Website. Online Information Review, 36(3), 374-382. douio.1108/14684521211241404

Antunes, A. A. (2004). Sistemas XYZ. In Sousa A. J. (Ed.), Tecnologias Internet. Lisboa: Editora Xxxpto.

Back, T. (2002). Adaptive business intelligence based on evolution strategies: some application examples of self-adaptive software. Information Sciences, 148(1-4), 131-121.

Golfarelli, M., Rizzi, S., & Cella, I. (2004). Beyond Data Warehousing: What's Next in Business Intelligence. In: Proceedings of the 7th ACM international workshop on data warehousing and OLAP, (pp. 1-6). Washington DC, USA: ACM.

Palocsay, S., Markham, I., & Markham, S. (2010). Utilizing and teaching data tools in Excel for exploratory analysis. Journal of Business Research, 63 (2), 191-206.

Kimball, R., & Ross, M. (2002). The Data WarehouseToolkit-The Complete Guide to Dimensional Modeling (2nd edition). Hoboken, NJ, USA: Jhon Wiley and Sons, Inc.

Bernabeu, R. (2010). HEFESTO: Metodologia para la Construccion de un Data Warehouse. Cordob, Argentina.

Conesa, J., & Curto, J. (2010). Introduccion al Bussiness Intelligence [en linea]. Barcelona: Editorial UOC, ISBN 978-84-9788-886-8.

Venter, M. (2005). Business Intelligence Initiatives: Failures Versus Success. Revista Interdisciplinary Journal [en linea], 4 (1).

Mazon, J., Trujillo, J., & Lechtenborger, J. (2007). Reconciling requirement-driven data warehouses with data sources via multidimensional normal forms. Data & Knowledge Engineering, 63(3) 725-751.

Inmon, W. (2005). Building the Data Warehouse (3rd edition). Hoboken, NJ, USA: Jhon Wiley and Sons, Inc.

Vaisman, A., & Zimanyi, E. (2014). Data Warehouse Systems Design and Implementation. Springer Series: Data-Centric Systems and Applications, (XXVI), 603.

Duran, A. (2000). Un Entorno Metodologico de Ingenieria de Requisitos para Sistemas de Informacion, Tesis doctoral Universidad de Sevilla.

Marcus, A. (2006). Dashboards in Your Future. The Art of Prototyping, 13 (1), 48-60.

Illescas, G., Sanchez, M., & Canziani, G. (2015). Metodos de Pronostico por Indicadores dentro de la Gestion del Conocimiento Organizacional. RISTI-Revista iberica de Sistemas y Tecnologias de Informacion, (E3), 29-41. DOI: 10.17013/risti.e3. 29-41.

Prieto, A., & Piattini, M. (2015). Propuesta de marco de mejora continua de gobierno TI en entidades financieras. RISTI-Revista iberica de Sistemas y Tecnologias de Informacion (15), 51-67. DOI: 10.17013/risti.15.51-67.

Anexo

Wilson Castillo-Rojas (1), Fernando Medina Quispe (2), Francisco Farina Molina (2)

wilson.castillo@uda.cl, femedina@unap.cl, franciscofarina@unap.cl

(1) Universidad de Atacama, Facultad de Ingenieria / DIICC, 1530000, Copiapo, Chile.

(2) Universidad Arturo Prat, Facultad de Ingenieria y Arquitectura, 1100000, Iquique, Chile.

DOI: 10.17013/risti.26.83-103

Caption: Figura 1-Metodologia propuesta para PDW (elaboracion propia)

Caption: Figura 2-Indicador: Tasa anual de crecimiento en proyectos de investigacion

Caption: Figura 3-Indicador: Numero de jornadas completas equivalentes

Caption: Figura 5-Flujo de trabajo para la extraccion de datos seleccionados

Caption: Figura 6-Flujo de trabajo para el calculo de indicadores de: a) docencia b) investigacion

Caption: Figura 7-Flujo de trabajo para la carga de tabla hechos de docencia

Caption: Figura 8-Codigo SQL para validacion de un KPI

Caption: Figura 9-Grafica: cantidad de profesores por carrera

Caption: Figura 10-Tablero de control de indicadores de docencia

Caption: Figura 11-Tablero de control indicadores de proyectos de investigacion

Caption: Figure 12-MM relacional de los DM
Tabla 1--Seleccion de fuentes de datos a utilizar

Sistema      Descripcion de la fuente de datos

ICON         Sistema contable y financiero.
SIPER        Sistema de Personal.
SICDO        Sistema Curricular y Docente.
GEDO         Sistema de Gestion de Documentos Online.
VRIIP        Sistema que almacena proyectos de investigacion.

Tabla 2-Dimensiones a utilizar en el MM

Dimension                   Descripcion

Tiempo                      Meses, semestres y anos.

Academico                   Nombre, fecha nac., fecha ingreso, sexo
                            y nacionalidad.

Jerarquia                   identifica la jerarquia docente de cada
                            academico, estas son: "Profesor
                            Asociado", "Profesor Titular", "Profesor
                            Asistente", "Instructor", "Sin
                            Jerarquia".

Forma Contractual           Tipos de contratos: Jornada Completa,
                            Media Jornada o Horas.

Grado Academico             Doctorado, Magister, Profesional,
                            Licenciado, Tecnico y Sin titulo.

Tipo de Actividad           "Docencia" o "Investigacion".

Carrera                     Actividad del docente asociado a una
                            carrera, cuenta con 3 jerarquias
                            distintas: unidad academica, sede, y
                            nivel de formacion.

Tipo de Formacion           Tipo de asignatura: Formacion General o
                            Formacion Profesional.

Fuente de Financiamiento    Internos (UNAP), o externos (publicos o
                            privados).

Area del Conocimiento       Clasificacion de un programa academico:
                            Agropecuaria y Ciencias del Mar,
                            Administracion y Comercio, Arte y
                            Arquitectura, Ciencias Naturales y
                            Matematicas, Ciencias Sociales, Derecho,
                            Humanidades, Educacion, Tecnologia y
                            Salud.

Region                      Nombre de regiones

Tipo de Proyecto            El tipo de proyecto categoriza en
                            investigacion o prestacion de servicios
                            a las postulaciones que realiza un
                            docente a un proyecto en particular.

Estado del Proyecto         Estado del proyecto: adjudicado, en
                            postulacion, decretado, o finalizado.

Formato de Publicacion      Articulo cientifico, capitulo de libro,
                            revision de articulo (review).

Tipo de Indexacion          ISI, SCOPUS y SCIELO.

Posicion de la              Que tiene la institucion en un articulo
Publicacion                 cientifico.

Tabla 3--Descripcion de indicadores

Indicador               Descripcion (hecho docencia)

HORA_SEMANAL_ACT        Cantidad de horas semanales que imparte un
                        docente.

HORA_MENSUAL_ACT        Total de horas mensuales de un docente en una
                        actividad.

HORA_SEM_PF             Cantidad de horas semanales que un docente
                        realiza.

HORA_SEM_PP             Total de horas semanales que imparte un
                        docente.

JCE                     Cantidad de Jornada Completas Equivalentes.

Indicador               Descripcion (hecho Investigacion)

NRO_PUBLICACIONES_PP    Cantidad de publicaciones proporcionales.

NRO_PUBLICACIONES       Cantidad total de publicaciones que realiza
                        el docente.

NRO_PROYECTOS           Cantidad total de proyectos en el que
                        participa un docente.

NRO_PROYECTOS_PP        Numero de proyectos proporcionales que
                        realiza el docente.

Figura 4-Tablas de hechos: a) docencia, b) investigacion

DIM_HORAS_ ACADEMICO                 DMJNVESTIGACION

HORA_SEMANAL_ACT       Number        NRO_PUBLICACIONES_PP     Number
HORA_MENSUAL_ACT       Number        NRO_PUBLICACIONES        Number
HORA SEMANAL CONT      Number        NRO_PROVECTOS            Number
HORA_SEM_PF            Number        NR0_PR0YECT0S_PP         Number
HORA_SEM_PP            Number
JCE                    Number        b)

a)
COPYRIGHT 2018 AISTI (Iberian Association for Information Systems and Technologies)
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2018 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Author:Castillo-Rojas, Wilson; Quispe, Fernando Medina; Molina, Francisco Farina
Publication:RISTI (Revista Iberica de Sistemas e Tecnologias de Informacao)
Date:Mar 1, 2018
Words:6582
Previous Article:Usability evaluation of collaborative applications with multimodal user interface/Proceso de evaluacion de usabilidad en aplicaciones colaborativas...
Next Article:Towards Semantic Interoperability for Smart and Sustainable Management of High Biodiversity Territories using SmartLand-LD/Hacia la Interoperabilidad...
Topics:

Terms of use | Privacy policy | Copyright © 2020 Farlex, Inc. | Feedback | For webmasters