UNIVERSIDAD VERACRUZANA Facultad de Contaduría y Administración Propuesta de Diseño de un Datamart para el Sistema de Apoyo a la Toma de Decisiones de Asignación de Sinodales TESINA para obtener el Titulo de: Licenciado en Sistemas Computacionales Administrativos Presenta: Beatriz Santiago Herrera Asesor: M.T.E. María Luisa Velasco Ramírez Cuerpo Académico: Tecnologías de la información y organizaciones inteligentes en la sociedad del conocimiento Xalapa-Enríquez, Veracruz Agosto 2009 UNIVERSIDAD VERACRUZANA Facultad de Contaduría y Administración Propuesta de Diseño de un Datamart para el Sistema de Apoyo a la Toma de Decisiones de Asignación de Sinodales TESINA para obtener el Titulo de: Licenciado en Sistemas Computacionales Administrativos Presenta: Beatriz Santiago Herrera Asesor: M.T.E. María Luisa Velasco Ramírez Cuerpo Académico: Tecnologías de la información y organizaciones inteligentes en la sociedad del conocimiento Xalapa-Enríquez, Veracruz Agosto 2009 DEDICATORIA Y AGRADECIMIENTO Son muchas las personas que debería nombrar en estas líneas, pero tratare de mencionar aquellas que no han bajado la guardia y siempre me han apoyado, tanto a lo largo del desarrollo de esta Tesina como a lo largo de mi vida. Dedico este proyecto y toda mi carrera universitaria a Dios por ser quien ha estado a mi lado en todo momento dándome las fuerzas necesarias para continuar luchando día tras día y seguir adelante rompiendo todas las barreras que se me presenten pero sobre todo porque gracias a él he llegado a esta meta y sé que seguirá ayudándome a lo largo de mi caminar. Primero, debo dar gracias a mi madre Lis. A aquella incansable mujer que desde que era pequeña me ha guiado y acompañado en los momentos en que más le he necesitado. Por su apoyo, por su incondicionalidad de madre y principalmente por su amor que no espera nada a cambio. Mamá, todo mi trabajo va dedicado a ti. Mis hermanas son mis ojos y no puedo sino darle las gracias por el tiempo, por entender las veces en que no pude estar con ellas, pero sobre todo por el inmenso amor que siento de su parte. Ely y Chela para que ninguna se sienta primero, todos los días le doy gracias a Dios por haberlas traído a mi vida. También les agradezco a mis amigos más cercanos, a esos amigos que siempre me han acompañado y con los cuales he contado desde que los conocí, a ellos que en equipo logré paso a paso cada una de las metas que se presentaba en semestre tras semestre. Pero sobre todo amigos que me abrieron su corazón y amistad y que con cada uno de ustedes compartí momentos estresantes pero también a su vez muchos pero muchos momentos muy felices. No he querido mencionar nombres, pero si estás leyendo estas líneas es porque formas parte de mi vida y puedes estar segura (o) que estas líneas también son para ti. También dedico esta tesina a mi asesora la Mtra. María Luisa Velasco Ramírez quien me ayudo a poder culminar este trabajo, con su apoyo y consejos, pero sobre todo por su tiempo y correcciones para que este fuera una tesina de calidad, gracias por ayudarme. Y porque no agradecer también a cada uno de los maestros que me formaron como profesionistas, los cuales compartieron sus conocimientos conmigo y con ellos poder llegar al final de esta etapa universitaria. Y a todos aquellos, que han quedado en los recintos más escondidos de mi memoria y corazón, pero que fueron participes en cincelar a Beatriz Santiago Herrera, MIL GRACIAS!!!!! INDICE Resumen . .............................................................................................................. .1 Introducción ............................................................................................................ .2 Capítulo I: Toma de decisiones y Datamart............................................................. 8 1.1 Antecedentes.................................................................................... 9 1.2 Información como fuente para la Toma de Decisiones................... 10 1.3 Sistemas de Soporte a la Decisión (DSS) ...................................... 13 1.4 Datamart como soporte a la toma de decisiones............................ 14 1.5 Datamart Vs Sistemas Transaccionales ........................................ 17 1.5.1 Procesamiento Transaccional en Línea. OLTP ................. 17 1.5.2 Procesamiento Analítico en Línea. OLTP .......................... 18 1.6 Datamart en la Organización .......................................................... 20 Capítulo II: Entorno de un Datamart ...................................................................... 22 2.1 Definición de un Datamart .............................................................. 23 2.2 Características de un Datamart ...................................................... 26 2.3 Estructura de un Datamart ............................................................. 29 2.4 Arquitectura de un Datamart........................................................... 32 2.4.1 Niveles que integran la arquitectura de un Datamart ........ 32 2.4.2 Componentes de la arquitectura de un Datamart ............. 35 2.4.2.1 Fuentes de datos operacionales ......................... 36 2.4.2.2 Proceso ETL ........................................................ 37 2.4.2.3 Servidor de Datos ................................................ 38 2.4.2.4 Herramientas de acceso...................................... 42 2.4.2.5 Metadatos............................................................ 43 2.5 Explotación de un Datamart ........................................................... 44 2.6 Dos enfoques Sobre Datamart ....................................................... 45 2.6.1 Bill Inmon .......................................................................... 46 2.6.1.1 Dependientes de Datamarts ................................ 46 2.6.2 Ralph Kimball .................................................................... 48 2.6.2.1 Estructura de autobús ......................................... 48 III Capítulo III. Modelo y Diseño de los datos de un Datamart .................................. 51 3.1 Análisis Multidimensional ............................................................... 52 3.2 Procesamiento Analítico en Línea (OLAP) ..................................... 53 3.3 Modelos Multidimensionales .......................................................... 54 3.3.1 Esquemas para modelamiento Multidimensional .............. 55 3.3.2 Esquemas Relac. para modelado multidimensional ........ 57 3.3.2.1 Esquema de Estrella (“Star Schema”) ................. 58 3.3.2.2 Esquema Copo de Nieve (“snow flake schema”) 60 3.3.2.3 Esquema de Constelaciones ............................... 61 3.3.3 Operaciones con Cubos.................................................... 62 3.4 Servidores de Procesamiento Analítico .......................................... 65 3.5 Utilización de Herramientas OLAP ................................................. 67 Capítulo IV. Propuesta de Diseño de un Datamart para el Sistema de Asignación de Sinodales: Análisis de la propuesta ............................ 68 4.1 Propuesta de Diseño de Datamart ................................................. 69 4.1.1 Estructura y Módulos del Sistema de Asignación de Sinodales .............................................................................. 72 4.2 Beneficios del Diseño de un Datamart ........................................... 76 4.3 Etapas de Creación de un Datamart .............................................. 77 4.4 Alcance de la Propuesta de Diseño de un Datamart ...................... 79 4.4.1 Objetivo General de la propuesta ..................................... 80 4.4.2 Objetivo Particular de la propuesta ................................... 80 4.5 Actividades realizadas en la etapa de análisis ............................... 81 4.5.1 Descripción de entidades del modelo de datos fuentes .... 82 4.5.2 Descripción de atributos del modelo de datos fuentes ...... 84 4.5.3 Descripción del modelo de datos fuentes ......................... 91 IV Capítulo V. Diseño de la Propuesta ...................................................................... 92 5.1 Actividades realizadas en la etapa de Diseño ................................ 93 5.1.1 Descripción de entidades del modelo del Datamart .......... 95 5.1.2 Descripción de atributos del modelo del Datamart............ 96 5.1.3 Descripción del modelo del Datamart ............................. 102 5.1.3.1 Esquemas Copo de Nieve del Datamart ........... 103 Conclusiones.….. ................................................................................................ 108 Fuentes de Información ....................................................................................... 114 Glosario…………................................................................................................. 117 Índice de Figuras. ................................................................................................ 119 Índice de Tablas.. ................................................................................................ 120 V RESUMEN La toma de decisiones dentro de las organizaciones se ha hecho indispensable en cada una de las etapas en las que se desarrolla esta. Por tal motivo es importante adoptar las tecnologías que permiten realizar este proceso de toma de decisiones mucho más eficiente y eficaz. Por esto de habla de Datamart, describiendo en forma general el concepto, arquitectura, implementación y explotación de este. Y tomando el Datamart, como un subconjunto del Datawarehouse, buscando obtener los mismos beneficios de esté, pero aplicados a un área en particular. Por lo cual se presenta el diseño de un Datamart dentro del sistema de asignación de sinodales, demostrando las ventajas que este traería en el proceso de toma de decisiones del sistema. 1 INTRODUCCIÓN Los sistemas de información forman parte importante dentro de las organizaciones actuales tanto en sus procesos como en la toma de decisiones. Es importante mencionar que estos procesos y la toma de decisiones son realizados y tomados por los seres humanos los cuales son capaces de realizar estas actividades como parte primordial dentro de las organizaciones en las que ellos forman parte. La toma de decisiones dentro de las organizaciones requiere que la información fluya en la mayor cantidad posible en el menor tiempo posible, lo cual hace que se realice una adecuada toma de decisiones. Esto requiere del manejo de mucha información dentro de las organizaciones la cual podrá ser recolectada y almacenada dentro de grandes fuentes de datos los cuales serán el sustento para la toma de decisiones. Por esta razón las organizaciones tienen como objetivo buscar y conocer las nuevas tecnologías que les permitan desarrollarse más rápidamente así como poder manejar la información generada dentro de las organizaciones con la mayor eficacia y eficiencia posible. Además de esto saber el cómo utilizarlas y aplicarlas satisfactoriamente para el benéfico de las organizaciones actuales, las cuales van a generar su propia desarrollo y una adecuada toma de decisiones. Es por esto que se convierte conoce como el en tema del siguiente trabajo lo que se Datamart, un subconjunto de un almacén de datos (Datawarehouse) con un propósito específico, el cual presenta las mismas Es importante partir del concepto de Datamart, el cual se ha convertido en la única tecnología de negocios capaz de sustentar, almacenar y analizar la información que se manejan en las organizaciones, por lo se convierten en el centro de atención de las organizaciones ya que lo que buscan es tener toda la información concentrada y además de esto que esta sea segura, confiable y de calidad, para así las organizaciones estén seguras de que las decisiones tomadas las llevaran hacia el éxito. 3 El Datamart se convierte en la tecnología que sirve como apoyo a la toma de decisiones ya que esta representa datos históricos los cuales sirven como fuente de información para la capa gerencial de las organizaciones y con ello estos son capaces de tomar decisiones. De este almacén da datos se extrae toda esa información y la analiza para que esta sea la fuente en la toma de decisiones. Por ello que es posible hablar de cómo el Datamart es una opción para las organizaciones para favorecer su adecuado proceso de toma de decisiones como resultado de sus sistemas de información, y así poder tener centralizada toda la información que se genera dentro los diversos sistemas de información que integran a la organización y que pueda servir de apoyo en la toma de decisiones en un tema determinado que sea relevante para la organización en un momento determinado. Logrando con ello tener acceso mucha más rápido a la información y sobre todo lograrla tener de manera inmediata sobre un área determinada o de interés que sea oportuna, relevante y exacta, teniendo la seguridad de que se puede confiar plenamente en la información que genera. Y a lo largo de este trabajo se aborda el tema de la importancia de la toma de decisiones en las organizaciones y sobre todo el porqué las organizaciones están tomando al Datamart como una herramienta para esto. Esto permitirá comprende mejor la relevancia que tiene el Datamart, el cual presenta las mismas características que un Datawarehouse, con la diferencia que este se especifica es un área determinada de toda la organización, permitiendo con ello comprender todo el entorno donde podemos encontrar un Datamart, pensando en un futuro que no solo sea un Datamart, el cual dentro de este trabajo se enfocara a un área en especifico, pero podría realizarse en distintas etapas y pensar poderlas integrar a un Datawarehouse el cual cumpliría con los mismos objetivos que un Datamart, pero enfocados a todas y cada una de las áreas de la organización de estudio. 4 Por esta razón los primeros capítulos se abordarán los temas generales del Datamart, para poder centrar la atención en el diseño, el cual será aplicado a la propuesta de Diseño del un Datamart para el sistema de asignación. En nuestro primer capítulo se abordará el tema acerca de la toma de decisiones, que es un parte importante en las organizaciones, y con ello pensar en el Datamart como una herramienta para la toma de decisiones, además se hace hincapié en los beneficios que tiene el adoptar esta herramienta, y además de esto saber de dónde se alimentara este y que resultados se obtendrá mediante el procesamiento transaccional en línea (OLTP) y el procesamiento analítico en línea (OLAP). Haciendo las diferencias correspondientes entre estos diversos ambientes en los que se desenvuelve el Datamart. Por otra parte en el segundo capítulo se busca conceptualizar el término de Datamart, así como definir la arquitectura de este, describiendo cada uno de los elementos de esta arquitectura e identificar las necesidades para implementar un Datamart en la organización. Y con esto determinar todo el entorno donde están involucrados los Datamart, es decir, se describirá él entorno del Datamart, y poder identificar las metodologías correspondientes sobre el uso de Datamarts, para tomar la que mas convengan para el Diseño propuesto. Y así poder la importancia de las fuentes primarias donde se alimenta el Datamart, el proceso de extracción, transformación y carga de estos dato de las fuentes primarias al almacén de datos y por último la explotación de esta información desde el almacén de datos a los usuarios finales mediante técnicas que lo permiten. También se mencionan los dos paradigmas en la construcción de un Datawarehouse en los que de identifican cada una de las metodologías de los paradigmas propuestos y poder identificar la creación de Datamart y cual se involucra más, para poder continuar con la propuesta de Diseño y hacerlo crecer en un futuro. 5 En el tercer capítulo se muestra la descripción del modelado multidimensional, para el Datamart, en donde se centralizará más los conceptos de modelado para el diseño del mismo. Se menciona el procesamiento analítico en línea (OLAP) el cual es importante para la presentación de la información a los usuarios finales del Datamart. Además de ellos los diferentes esquemas para el modelamiento relacional del Datamart, así como las operaciones de los cubos para la extracción de información. Y por último la importancia de de utilizar herramientas OLAP para la representación de la información de un Datamart. Y finalmente en los últimos dos capítulos se desarrollara la propuesta de diseño de un Datamart en donde se comenzará por la etapa de análisis, en la cual se describirá el entorno de la organización donde se planteará el Diseño del Datamart, el cual es el área de Coordinación de Experiencia Recepcional. Así como el modelamiento mediante algunos indicadores que permitan demostrar las ventajas de incorporar un Datamart al sistema. Dentro de la Faculta de de Contaduría y Administración está desarrollándose un sistema de apoyo a la toma de decisiones el cual tiene como objetivo el de asignar los sinodales que participarán dentro del examen profesional de un alumno. Dentro del sistema de apoyo a la toma de decisiones de asignación de sinodales no existe aplicada una tecnología que pueda servir como almacén de datos (Datamart), la cual permita la extracción de información de las áreas que sean importantes en el objetivo del sistema de apoyo a la toma de decisiones. Pero también que esta pueda ser analizada y permita que el apoyo a la toma de decisiones sea lo más eficiente posible, y con ello se reduzca tiempo, costo y sobre todo generación de información innecesaria, pero sobre todo permita que la información sea analizada y arroje resultados estructurados de tal manera que pueda ser analizado el comportamiento de los agentes que participan en el proceso de asignación de sinodales, y de las variables relacionadas a estos. 6 Es por esto que en estos últimos capítulos radica la importancia de la propuesta de diseño del Datamart, además permitirá identificar las diversas etapas para poder llegar a pensar en un futuro continuar con diversas áreas de la organización y poderlas integrar en la implementación de un Datawarehouse. 7 CAPÍTULO I. TOMA DE DECISIONES Y DATAMART Introducción. En este capítulo se conocerán los aspectos del entorno de la organización, buscando entender los beneficios de un Datamart. Además la importancia de un Datamart como apoyo a la toma de decisiones. Y los beneficios de contar con un esté dentro de las organizaciones que ayuden a la óptima a toma de decisiones pero sobre todo poder mostrar la relevancia que tiene el adoptar esta herramienta de almacenamiento dentro de una organización . 1.1 Antecedentes. Desde los inicios del uso de las tecnologías dentro de las organizaciones se ha hecho uso de la información y así como de la acumulación de datos que son procesados para generar resultados. Pero es importante mencionar que a lo largo del tiempo han mejorado las estrategias para poder procesar la información y que esta pueda servir a los diversos niveles organizacionales que intervienen en el proceso de toma de decisión. Las tecnologías de información han venido a provocar grandes cambios en la forma en que es manejado el conocimiento, dentro de ellas, el desarrollo de sistemas para el soporte de decisiones (DSS) ha tomado gran auge en los últimos años, mediante herramientas que han permitido hacer y utilizar la información de distinta manera a lo tradicional permitiendo con ellos generar técnicas que lo permitan, y por lo tanto se ha logrado tomar mejores decisiones en un mínimo de tiempo. Así también han modificado de manera significativa la manera tradicional en que se realizaba el trabajo, el desarrollo de nuevas tecnologías no solo en el área de hardware sino también de software nos han permitido incorporar procesos de sistematización en las organizaciones (Garcia,2009). 9 En los años de los 90 la competencia entre las organizaciones comenzó a incrementarse de forma singular. Las necesidades de las organizaciones cambiaron, por lo cual los directivos comenzaron a ver el valor de la información que se generaba dentro de sus organizaciones, pero con una característica en particular que esta pudiera ser consultada en un momento determinado y brindar a las organizaciones una ventaja competitiva sobre las demás organizaciones. Para lograr esta competitividad, es necesario que los directivos cuenten con toda la información necesaria de cada uno de los departamentos o áreas que existen dentro de la organización, y con ello implica que esta información sea recolectada en el menor tiempo posible para que así la toma de decisiones sea la más rápida y eficiente que les permita entrar en competencia. 1.2. Información como fuente para la toma de decisiones. Hoy en día los sistemas de información hay ido abarcando una gran cantidad de organizaciones y los cuales les han permitido y favorecido al éxito obtenido. Ya que estos sistemas de información les permite tener una mayor control sobre los diferentes niveles de la organización y sobre todo ir de la mano con las diversas etapas del proceso administrativo como son la organización, planeación, dirección y control, lo cual les ha permitido una correcta administración y por lo cual se obtiene como resultado tomar mejores decisiones que han beneficiado a las organizaciones. La toma de decisiones dentro de la organización es un proceso altamente complejo ya que no solo requiere que los directivos piensen que es lo mejor para la organización si no que tienen que basarse en hechos e información, lo cual les permita determinar mediante un proceso adecuado la mejor decisión ante una situación. Por lo cual hay que contar con lo necesario para que esto sea posible. 10 Y lo necesario para que esto sea posible es el manejo de la información que genera la organización, porque no solo sirve la está en bruto si no que esta tiene que ser analizada y presentada en forma de que esta genere un valor a la toma de decisiones y sobre todo le de las armas a los directivos para que puedan tomar la mejor decisión. Pero esto no se logra con solo contar con los grandes volúmenes de información sino que se necesita contar con la tecnología de vanguardia que haga los procesos necesarios para que esta información obtenga el valor necesario que le sirven a los directivos de las organizaciones, y una de las tecnologías que son de vanguardia es el Datawarehouse el cual es un almacén de datos que agrupa toda la información que existe dentro de una organización, lo que en la actualidad viene a formar parte de las organizaciones y sobre todo de la información que estas generan. Y a la par se puede comenzar a hablar de un Datamart el cual le permita a la organización realizar el análisis de un área en especifica y de pueda observar mediante el uso de un Datamart los beneficios de contar con un herramienta de análisis. La información que se maneja dentro de las organizaciones reside en bases de datos diseñadas fundamentalmente para introducir y almacenar los datos operacionales de las actividades diarias. Esta información, por la forma en la que está estructurada, no permite dar una respuesta ágil y fiable a todas las preguntas que se hacen los directores ejecutivos y analistas de negocio de la organización, en orden a facilitarles una óptima toma de decisiones. La forma en que se manejaba la información de las organizaciones era mediante informes generados de las distintas fuentes de información que integraban la organización. Por consiguiente el hoy, es mucho más prometedor ya que el éxito de la organizaciones depende de la información y como sea utilizada. Por esto hay que distinguir la importancia de contar con un Datawarehouse que permita a las 11 organizaciones llegar a ese éxito o mediante el Datamart generar que un área en específica de la organización pueda generar información de valor. Por lo cual se describe de forma general el porqué un Datamart puede ser la clave del éxito de las organizaciones: • Una sola fuente de información: Los datos que se encuentran en las distintas fuentes, las cuales pueden ser internas o externas, y en una gran diversidad de formatos, ya que la información es manejada en las distintas fuentes por diversos usuarios, por lo cual la información de una fuente a otra puede llegar a ser diferentes. Por lo tanto se buscan que estos llegan a estandarizarse en una sola fuente para que los usuarios finales no tengan que liderar con la diversidad de formatos entre los distintos sistemas operaciones. • Disponibilidad de la información de las diversas fuentes: Se menciono que la información proviene de diversas fuentes, pero esto implica que la información se encuentre en otros lugares dentro de la organización así como fuera de ella. Por lo cual la fuente única donde se almacenan toda la información sin importan su procedencia, es así que logra la integración de los datos sin importar su lugar de origen. • La información específica del negocio: Los usuarios finales buscan que la información sea específica de acuerdo las necesidades de las organizaciones, es decir, busca contar con la información sobre temas específicos, donde los directivos puedan manejar y manipular la información. • Calidad de la información y seguridad: La información es el activo principal de toda organización, por lo cual se busca que esta información sea 12 protegida y sobre todo resguardada con calidad. Esto asegura también el valor de la misma. Por estas razones, es importante tomar un Datamart como solución de negocios, existen muchas soluciones de negocios las cuales pueden ser utilizadas en cada uno de los departamentos de la organización, pero la información a los directivos les es necesario tener la información concentrada para que tenga el valor suficiente para soporta una decisión. 1.3 Sistemas de Soporte a la Decisión (DSS) Un Sistema de Soporte a la Decisión (DSS) es una herramienta de Business Intelligence enfocada al análisis de los datos de una organización. En principio, puede parecer que el análisis de datos es un proceso sencillo, y fácil de conseguir mediante una aplicación hecha a medida o un ERP sofisticado. Sin embargo, no es así, estas aplicaciones suelen disponer de una serie de informes predefinidos en los que presentan la información de manera estática, pero no permiten profundizar en los datos, navegar entre ellos, manejarlos desde distintas perspectivas, etc. (Sinnexus, 2007). El DSS es una de las herramientas más emblemáticas del Business Intelligence ya que, entre otras propiedades, permiten resolver gran parte de las limitaciones de los programas de gestión. Estas son algunas de sus características principales: • Informes dinámicos, flexibles e interactivos, de manera que el usuario no tenga que ceñirse a los listados predefinidos que se configuraron en el momento de la implantación, y que no siempre responden a sus dudas reales. • No requiere conocimientos técnicos. Un usuario no técnico puede crear nuevos gráficos e informes y navegar entre ellos, haciendo 13 drag&drop o drill through. Por tanto, para examinar la información disponible o crear nuevas métricas no es imprescindible buscar auxilio en el departamento de informática. • Rapidez en el tiempo de respuesta, ya que la base de datos subyacente suele ser un Datawarehouse corporativo o un Datamart, con modelos de datos en estrella o copo de nieve. Este tipo de bases de datos están optimizadas para el análisis de grandes volúmenes de información. • Integración entre todos los sistemas/departamentos de la compañía. El proceso de ETL previo a la implantación de un Sistema de Soporte a la Decisión garantiza la calidad y la integración de los datos entre las diferentes unidades de la empresa. • Cada usuario dispone de información adecuada a su perfil. No se trata de que todo el mundo tenga acceso a toda la información, sino de que tenga acceso a la información que necesita para que su trabajo sea lo más eficiente posible. • Disponibilidad de información histórica. En estos sistemas está a la orden del día comparar los datos actuales con información de otros períodos históricos de la compañía, con el fin de analizar tendencias, fijar la evolución de parámetros de negocio, etc. 1.4 Datamart como soporte a la toma de decisiones Dentro del proceso de toma de decisiones de una organización o primordial es contar con las herramientas o técnicas necesarias para poder hacer un uso eficiente de a información es por esto que ha surgido la necesidad de contar con almacenes de datos los cuales procesen toda la información existente dentro de una organización en las diversas áreas que intervienen en la organización. Y con esto surge el término de “Datamart”, el cual es una parte fundamental en las organizaciones actuales que han buscado adoptar un Datawarehouse para eficientar sus procesos de obtención de información y toma de decisiones, las 14 cuales buscan tener un grado de competitividad el cual les permita sobre salir de las demás organizaciones que están en constante competencia. Por lo cual se busca profundizar en el concepto de Datamart y saber que este puede adoptarse y obtener los beneficios de un Datawarehouse pero aplicados solo aun área en especifico de la organización. No solo hay que pensar que la información que se requiere es la actual, sino que las organizaciones también necesitan tener información histórica sobre cada una de las áreas de la organización, esto se genera demasiada información y para procesar toda esta información es necesario contar con un Datamart, el cual permite tener concentrada toda la información histórica y actual de un área en particular, para que gracias a este se pueda consultar y generar resultados rápidos y que puedan impactar directamente a la organización. En forma general los Datamart surgen por las siguientes razones muy particulares (Bustamante, 2005): • Contar con un almacén de datos que permita que la información de un departamento pueda ser almacenada ahi. • Contar con información consistente, ya que la información tendría que ser limpiada para así poder estandarizar la información que existen en las diversas áreas. • Poder analizar la información para así realizar una toma de decisiones eficiente. • Y por último que el ocupar la información de los sistemas operacionales no afecte a estos directamente, por ello la necesidad de contar con un Datamart donde se pueda manipular dicha información. También hay que tener claro que lo que las organizaciones actuales buscan entre sus grandes necesidades contar con estructuras de información con mayor 15 procesamiento, y sobre todo que permita la obtención de información con valor, que les permita hacer de sus necesidades un oportunidad que les haga sobre salir de las demás organizaciones. Este tipo de necesidades sirven para reflejar tendencias, evoluciones, hechos históricos en el negocio y posibilidades futuras son algo que la los directivos de las organizaciones o empresas debe manejar y manejan de una forma habitual y es la causante de que hayan aparecido en el mercado herramientas del tipo de ayuda a la toma de decisiones. Por otra parte, las necesidades de información hoy en día han variado. La disponibilidad de gran cantidad de información es de vital importancia para los negocios ya que las decisiones del futuro se suelen tomar sobre la base de dicha información. Con la sociedad buscando información y dentro de estas las empresas, ha crecido a nivel mundial la capacidad de generación y almacenamiento de la información, quizá no puede ser analizada por los métodos tradicionales existentes, mientras mayor es la capacidad para almacenar más y más datos, mayor es la incapacidad para extraer información realmente útil de éstos en las empresas. Mucha información importante, quedaba sepultada y disgregada, y los sistemas existentes no estaban preparados para el nuevo reto. Mucho se ha hablado de la Era de la Información y sus ventajas con las nuevas posibilidades se acortan las distancias y crecen los beneficios para quienes tienen acceso a la gran cantidad de datos. Sin embargo, lo que constituye un valioso recurso para todos, se ha tornado en el gran problema de principios de siglo, manejar de forma óptima grandes volúmenes de información. 16 La competencia en el nuevo ambiente corporativo donde todo está marcado por la información, el conocimiento del mercado y la toma de decisiones, es muy importante saber dónde y cómo se organiza toda la información. 1.5 Datamart vs Sistemas Transaccionales. Estos son dos tipos de ambientes, dentro de los cuales la información que se genera y sobre todo como es tratada son muy diferentes, cada uno con sus correspondientes procesos. Por esto se busca diferenciar uno del otro, y así poder describir cada una de sus características para entender mejor que el Datamart es la solución optima cuando se requiere tomar decisiones. Es por esta razón que mocionaremos las características que diferencian un ambiente del otro: 1.5.1 Procesamiento de Transacciones en Línea. OLTP Los sistemas OLTP son bases de datos orientadas al procesamiento de transacciones. Una transacción genera un proceso atómico los cuales deben de ser validados mediante un commit o invalida por un rollback, y que puede involucrar operaciones de inserción, modificación y borrado de datos. El proceso transaccional es típico de las bases de datos operacionales (Sinnexus 2007). El acceso a los datos está optimizado para tareas frecuentes de lectura y escritura. Ya que estos sistemas tienen una enorme cantidad de transacciones día a día como por ejemplo los bancos. Los datos se estructuran según el nivel aplicación, por ejemplo un sistema de información utilizado en un departamento específico de una organización, como puede ser un sistema de Planeación de Recursos de la Empresa (ERP) o un sistema de Gestión sobre la Relación con los Consumidores (CRM) implantado en la misma. 17 Los formatos de los datos no son necesariamente uniformes en los diferentes departamentos por lo que es común la falta de compatibilidad y la existencia de diversas fuentes de datos. El historial de datos suele limitarse a los datos actuales o recientes. 1.5.2 Procesamiento Analítico en Línea. OLAP Los sistemas OLAP son bases de datos orientadas al procesamiento analítico. Este análisis suele implicar, generalmente, la lectura de grandes cantidades de datos para llegar a extraer algún tipo de información útil: tendencias de ventas, patrones de comportamiento de los consumidores, elaboración de informes complejos, etc. Este sistema es típico de los almacenes de datos departamentales (Sinnexus 2007). El acceso a los datos suele ser de sólo lectura. La acción más común es la consulta, con muy pocas inserciones, actualizaciones o eliminaciones, ya que este tipo de ambiente representa el histórico de la información por lo cual la finalidad es sola de obtener información que sea histórica, por lo cual solo se hacen consultas de extracción de la información. El historial de la información se lleva a cabo en plazo aproximando de dos a cinco años. Los datos se estructuran según las áreas de negocio, y los formatos de los datos están integrados de manera uniforme en toda la organización. A continuación en el Tabla 1.1 se presenta una comparación entre los ambientes OLTP y los OLAP, para que así sean más comprensibles las diferencias entre estos: 18 OLTP OLAP 1. Organizados por aplicación 1. Organizados por dimensiones definidas por el negocio 2. Cada tema de negocios puede 2. Toda la información de un tener información en diferentes tema, Sistemas y base de datos. alimentado de varios sistemas, reunido en una sola Base de Datos 3. Los usuarios son los que giran 3. Los usuarios observan cómo las ruedas de la Organización giran las ruedas (Consultas(Actualizaciones) Análisis) 4. Mantienen la Integridad de los 4. datos el análisis del negocio 5. El DBA/usuario mueven datos 5. registros a registros 6. Soporta Se manejan DBA/usuario carga y accesa datos de forma masiva cientos de 6. Se maneja una transacción registros por día (insert, update, con delete, select) El cientos de registros (selects) 7. Los datos operacionales son 7. Los Datos del altamente volátiles, cambien en Datawarehouse son altamente medida que opera la empresa y estables, sus sistemas de reflejan la operación son insertados en información intervalos de tiempo definidos. Y no son modificados. Tabla 1.1 Cuadro comparativo entre ambientes OLTP y OLAP. Fuente: Flores,2009 19 1.6 Datamart dentro de la organización. Como se ha mencionado dentro de este capítulo el Datamart resulta ser una solución de negocio muy atractiva en estos tiempos en que la información se ha convertido en la principal fuente de éxito de una organización. Por tal motivo hay que pensar que contar con un Datamart viene a revolucionar la idea que se tiene de negocio ya que no solo permitirá conocer el valor de la información que genera una organización sino que además permitirá que esa información sea explotada de la manera más eficiente mostrando resultados con información ya estructurada. Esta búsqueda de explotación de la información permite que las organizaciones puedan administrar la información generando conocimiento. Y en la actualidad esa administración del conocimiento la orientan hacia los procesos de negocios. Por lo cual las organizaciones requieren la implementación de una solución integral que habilite a la organización para administrar su información, centralizándola y almacenándola en un solo repositorio, es decir, la solución integral de un Datamart. Para tal efecto, se propone la integración un Datamart en un área específica de la organización en donde se pueda centralizar la información que los sistemas transaccionales manejan. Esto involucra la correspondiente recopilación, estructuración, estandarización, y almacenamiento de datos en una arquitectura de Datamart, pero sobre todo aprovechando cada uno de los componentes con la que este cuenta para poderlos desarrollar dentro de las organizaciones y explotándoles en todo su potencial. Hay una premisa en el mundo del negocio que plantea que el futuro pertenece a quienes pueden verlo y llegar a él primero. Por tanto, es una recomendación a todas las empresas que tengan automatizados todos o 20 parcialmente sus procesos y cuenten con información acumulada sobre los mismos, la implementación de un Datamart permitirá tener automatizados los procesos dentro del área donde sea aplicado, ya que éste permite no solo comprender lo que está pasando, sino predecir lo que va a suceder. Por esta razón el Datamart tiene ciertas características y procesos los cuales interactúan unos con otros para que la implementación de este sea exitosa dentro de la organización y los resultados esperados sean satisfactorios. Dado este punto de vista se podrá describir esas características y procesos para comprender en qué consiste esta solución de negocio que es el Datamart. Esto se irá describiendo en los siguientes capítulos buscando que sea comprendido todo el proceso de Datamart y cómo es que la integración de cada una de sus características y procesos permitirá la generación de conocimiento a partir de la información que esta arroja día a día. En los siguientes capítulos se abordaran los temas correspondientes al Datamart, para comprender esta tecnología e identificando que para la propuesta de Diseño del Datamart se emplearan los mismos conceptos, ya que el Datamart representa las mismas características para el diseño que las del Datawarehouse. 21 CAPÍTULO II. ENTORNO DE UN DATAMART Introducción. Dentro del siguiente capítulo se abordarán los conceptos generales dentro de un ambiente Datamart, como lo son el concepto de Datamart, sus características y propiedades, así como se describirán cada uno de los componentes que integran al Datamart. 2.1 Definición de un Datamart. El concepto de Datamart nace en la década de los 80, en donde los investigadores estaban en la busca de desarrollar un sistema que permitiera el manejo de constante y permanente de la información y que este fuera al mismo tiempo organizado por áreas especificas de la organización para poder ser utilizado por los cargos directivos y pudieran estar en contacto eficiente con esa información. El sistema Datamart se maneja a través de dos conceptos centrales: el de integración y combinación de diferentes tipos de datos que son utilizados en el área donde es aplicado y que podría abarcar distintos espacios de la organización por un lado, y el de separación y selección de esa misma información de acuerdo a las necesidades específicas de cada usuario o sección de la empresa. Se ha hablado de un Datamart como un repositorio de información que integra toda la información que se genera dentro de un departamento, el cual la analiza y arroja a los usuarios finales mediante herramientas de explotación. 23 Aquí se hablara del término de Datamart el cual es un concepto relativamente nuevo para las organizaciones, orientado al manejo de grandes volúmenes de datos, provenientes de los sistemas transaccionales que controlan la información en el área donde se encuentra aplicado, y que pueden ser de muy diversos tipos. Estos datos cubren largos períodos de tiempo, lo que trae consigo que se tengan diferentes esquemas de las bases de datos fuentes. La concentración de esta información está orientada a su análisis para apoyar la toma de decisiones oportunas y fundamentadas (Méndez Duque, 2006). Un Datamart es una base de datos departamental, especializada en el almacenamiento de los datos de un área de negocio específica. Se caracteriza por disponer la estructura óptima de datos para analizar la información al detalle desde todas las perspectivas que afecten a los procesos de dicho departamento. Un Datamart puede ser alimentado desde los datos de un Datawarehouse, o integrar por sí mismo un compendio de distintas fuentes de información (Sinnexus 2007). Por tanto, para crear él Datamart de un área funcional de la empresa es preciso encontrar la estructura óptima para el análisis de su información, estructura que puede estar montada sobre una base de datos OLTP, como el propio Datamart, o sobre una base de datos OLAP. La designación de una u otra dependerá de los datos, los requisitos y las características específicas de cada departamento. De esta forma se pueden plantear dos tipos de Datamarts: • Datamart OLAP Se basan en los populares cubos OLAP, que se construyen agregando, según los requisitos de cada área o departamento, las dimensiones y los indicadores necesarios de cada cubo relacional. El modo de creación, explotación 24 y mantenimiento de los cubos OLAP es muy heterogéneo, en función de la herramienta final que se utilice. • Datamart OLTP Pueden basarse en un simple extracto del Datamart, no obstante, lo común es introducir mejoras en su rendimiento (las agregaciones y los filtrados suelen ser las operaciones más usuales) aprovechando las características particulares de cada área de la empresa. Las estructuras más comunes en este sentido son las tablas report, que vienen a ser fact-tables reducidas (que agregan las dimensiones oportunas), y las vistas materializadas, que se construyen con la misma estructura que las anteriores, pero con el objetivo de explotar la reescritura de queries (aunque sólo es posible en algunos SGBD avanzados). Por lo tanto los Datamarts son pequeños almacenes de datos concentrados en un tema o área del negocio especifico dentro de una organización, es decir, una versión especial de Datawarehouse, la cual facilita la toma de decisiones. Los Datamarts que están dotados con estas estructuras óptimas de análisis presentan las siguientes ventajas: • Fácil acceso a los datos que se necesiten frecuentemente • Crea una vista colectiva para un grupo definido de usuarios • Mejora el tiempo de respuesta del usuario final • Es de fácil creación • Costo inferior al de la aplicación de un completo almacén de datos. • Los usuarios potenciales son más claramente identificables que en un almacén de datos completo. 25 Esta parte es fundamental ya que de esta depende directamente la Propuesta de Diseño de un Datamart, ya que el desarrollo de un Datawarehouse, puede adaptarse de forma gradual o departamental creando soluciones específicas para cada área de la organización, y sabiendo que se obtendrán resultados a corto plazo. Y Sabiendo que el Datamart posee las mismas características que un Datawarehouse. El Datamart se define como un Datawarehouse departamental (Barrientos, 2002), orientado a un grupo de usuarios en específico, por tal motivo las actividades de planificación, diseño e implementación son las mismas encontradas en el Datawarehouse. Y en el ambiente de Datamart se adaptan a tecnologías multidimensionales y es donde se aplican técnicas de análisis especializadas. Además de lo anterior, el ciclo de implementación es mucho menor, lo que hace que la creación de Datamarts de las diversas áreas de la organización sea el comienzo para la creación de un Datawarehouse. Por lo cual dentro de los siguientes capítulos será más familiar hablar de Datamart, ya que en ese es enfocada la Propuesta de Diseño de un Datamart 2.2 Características de un Datamart. Cuando se habla de un Datamart se hace referencia a un sistema que organiza la información en base a temas o asignaturas especiales, que permite entonces que los datos y la información de mismo tipo queden siempre conectados. Del mismo modo, es un sistema que puede evolucionar con el tiempo y asimilar los cambios en la información de manera tal que cada nuevo acceso refleje las diferencias necesarias. 26 También se define como un sistema de tipo volátil porque no se pierde nunca ningún tipo de información, lo cual hace más fácil recurrir a datos antiguos o que no estaban en uso. Finalmente, se dice que el Datamart es un sistema integrado ya que está diseñado para funcionar y ser útil para captar las diversas fuentes que se manejan. Las características de un Datamart se definen a continuación (Sinnexus, 2007): Integrado: El aspecto más importante del ambiente Datamart es que la información encontrada al interior está siempre integrada. Los datos almacenados en el Datamart 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: dentro de esta característica es importante saber que la información se clasifica en base a los intereses que tiene una organización. Por esta razón solo 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 Datamart. 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 Datamart. 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 Datamart sirve, entre otras cosas, para realizar análisis de 27 tendencias. Por lo tanto, el Datamart 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 Datamart existe para ser leído, pero no modificado. La información es por tanto permanente, significando la actualización del Datamart 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. Estas son las características principales que debe contener un Datamart, pero sean propuesto una lista de 12 reglas que definen un almacén de datos (Willian, H.I., Chuck, K. 1994) y que son necesarios para que este sea considerado como tal: 1. El almacén de datos y los ambientes operativos están separados. 2. Los datos guardados en el almacén de datos están integrados. 3. El almacén de datos contiene datos históricos que abarcan un amplio horizonte de tiempo. 4. Los datos en el almacén de datos son capturados instantáneamente en un punto dado de tiempo. 5. Los datos en el almacén de datos están orientados a sujetos. 6. Los datos en el almacén de datos principalmente son de solo lectura, con actualizaciones por lotes periódicas a partir de datos operativos. No se permiten actualizaciones en línea. 7. El ciclo de vida del desarrollo de un almacén de datos difiere del desarrollo de los sistemas clásicos. Los datos motivan el desarrollo del almacén de datos; los procesos motivan al método clásico. 8. El almacén de datos contiene datos con varios niveles de detalle: datos detallados, actuales, datos detallados antiguos, datos ligeramente resumidos y datos altamente resumidos. 28 9. El ambiente del almacén de datos se caracteriza por transacciones de solo lectura por numerosas transacciones de actualización de unas cuantas entidades e datos a la vez. 10. El ambiente del almacén de datos dispone de un sistema que rastrea fuentes, transformaciones y almacenamientos de datos. 11. Los metadatos del almacén de datos son un componente crítico de este ambiente. Los metadatos identifican y definen todos los elementos de datos; proporcionan la fuente, transformación, integración, almacenamiento, uso, relaciones e historial de cada elemento de datos. 12. El almacén de datos contiene un mecanismo de retrocarga para el uso de los recursos que exige la utilización óptima de los datos por parte de los usuarios. 2.3 Estructura de un Datamart. El Datamart puede llegar a tener una estructura distinta. Hay niveles diferentes de esquematización y detalle que delimitan el Datamart. La estructura de un Datamart se muestra en la Figura 2.1 en donde se muestran los diferentes niveles de información del mismo, como lo son: • Detalle de datos actuales • Detalle de datos antiguos • Datos ligeramente resumidos • Datos completamente resumidos • Meta data Detalle de datos actuales.- En gran parte, el interés más importante radica en el detalle de los datos actuales, debido a que: Refleja las ocurrencias más recientes, las cuales son de gran interés. Es voluminoso, ya que se almacena al 29 más bajo nivel de granularidad. Casi siempre se almacena en disco, el cual es de fácil acceso, aunque su administración sea costosa y compleja. Detalle de datos antiguos.- La data antigua es aquella que se almacena sobre alguna forma de almacenamiento masivo. No es frecuentemente accesada y se almacena a un nivel de detalle, consistente con los datos detallados actuales. Mientras no sea prioritario el almacenamiento en un medio de almacenaje alterno, a causa del gran volumen de datos unido al acceso no frecuente de los mismos, es poco usual utilizar el disco como medio de almacenamiento. Datos ligeramente resumidos.- La data ligeramente resumida es aquella que proviene desde un bajo nivel de detalle encontrado al nivel de detalle actual. Este nivel del Datamart casi siempre se almacena en disco. Los puntos en los que se basa el diseñador para construirlo son: Que la unidad de tiempo se encuentre sobre la esquematización hecha. Qué contenidos (atributos) tendrá la data ligeramente resumida. Datos completamente resumidos.- El siguiente nivel de datos encontrado en el Datamart es el de los datos completamente resumidos. Estos datos son compactos y fácilmente accesibles. 30 FIGURA 2.1 Niveles de Información de un Datamart Fuente: RealITech, 2001 31 2.4 Arquitectura de un Datamart. 2.4.1 Niveles que integran la Arquitectura de un Datawarehouse Se habla de los elementos dentro de la arquitectura Datamart que es una forma de representar la estructura global de los datos, la comunicación, los procesos y la presentación del usuario final. Como se sabe la construcción del Datamart se establece como elemento crítico en el proceso de implantación de una herramienta de negocios y por lo tanto resulta interesante recordar todos estos conceptos por lo tanto en la Figura 2.3 se muestran los niveles de la arquitectura de un Datamart: FIGURA 2.2 Niveles de la Arquitectura de un Datamart Fuente: Spin, 2005 32 1. Nivel de acceso a la información: Es la capa de interacción del usuario cuya finalidad es la conversión de los datos almacenados en información fácil y transparente para las herramientas de los usuarios finales. 2. Nivel de acceso a los datos: Comunica el nivel de acceso a la información con el nivel operacional de forma universal. 3. Nivel de directorio de datos (metadatos): Repositorio de metadatos de los datos almacenados que proporcionan información sobre el origen y sobre la transformación de los mismos en el proceso de Datamart 4. Nivel de gestión de procesos: Planificación de las tareas y procesos para la construcción y mantenimiento actualizado del Datamart. 5. Nivel de mensaje de la aplicación: Determina el transporte de información a lo largo del entorno de computación de la organización a modo de middleware pero más allá de meramente protocolos de red. 6. Nivel Datamart (físico): Es el repositorio central altamente flexible de información donde residen copias de los datos operacionales y/o externos optimizados para su acceso para la consulta. 7. Nivel de organización de datos: Incluye todos los procesos necesarios para seleccionar, editar, combinar y cargar en el Datamart y en la capa de acceso a la información los datos operacionales y/o externos. 33 Respecto la arquitectura del Datamart, se puede considerar tres aspectos como los de mayor importancia y los presentamos en orden decreciente: 1. Nivel de organización de datos: Las organizaciones suelen tener fuentes de datos sumamente interesantes y con un gran potencial de información para la estrategia de negocio. Por lo tanto, es absolutamente necesario que exista un proceso ágil que homogenice los datos, los depure, los transforme adecuadamente y los cargue siguiendo las necesidades de negocio de la organización. De lo que deviene que este nivel de arquitectura sea el de mayor importancia en la arquitectura dado que si no se realiza con la mayor excelencia el proyecto puede no aportar nada a la organización. 2. Nivel de directorio de datos: El uso de metadatos es crucial para el éxito del Datamart porque permiten integrar datos de diferentes fuentes, permite evitar inconsistencias en el modelo de datos, son un soporte a la calidad de los datos, es una guía para el mapeo de datos en la transformación del ambiente operacional al Datamart, describiendo la localización, la estructura y el significado. Debe incluir dominio, reglas de validación, derivación y transformación de los datos extraídos y es una guía de los algoritmos usados para la esquematización entre el detalle de datos actual con los datos ligeramente resumidos, y éstos con los datos completamente resumidos, etc. 3. Nivel de gestión de procesos: Los procesos de actualización y mantenimiento del Datamart es el tercer aspecto que se debe comentar. Dado que las necesidades de una organización evolucionan, exactamente ocurre para la información que necesita. De modo que, a través de los metadatos, pueda realizarse un mantenimiento de los datos almacenados con una periodicidad fijada y sea fácil extender los datos almacenados. 34 2.4.2 Componentes de la Arquitectura de un Datamart Una de las razones por las que el desarrollo de un Datamart crece rápidamente, es que realmente es una tecnología muy entendible. De hecho, Datamart representa mejor la estructura amplia de una empresa para administrar los datos informacionales dentro de un área específica de la organización. A fin de comprender cómo se relacionan todos los componentes involucrados en una estrategia Datamart, es esencial tener una Arquitectura Datamart. La arquitectura de un Datamart incluye herramientas para la extracción de datos de múltiples fuentes de bases de datos operativas y fuentes externas, para la limpieza, transformación, en la Figura 2.3 se muestran a detalle los componentes de la arquitectura de un Datawarehouse: FIGURA 2.3 Flujo de Información dentro de un Datamart Fuente: Torres, 2007. 35 2.4.2.1.- Fuentes de datos Operacionales: Este componente es el que está presente originariamente en todas las organizaciones que manejan la información como fuente para realizar sus actividades, y es esta fuente de información a partir del cual se realiza la obtención de los datos que se contemplará en el Datamart. Estas fuentes de datos pueden ser sistemas operacionales corporativos los representan el entorno del que se obtienen la mayor parte de los datos significativos de la operatividad diaria de la organización, sistemas operacionales departamentales, fuentes externas, archivos planos entre otros. : Fuentes de datos comprende los siguientes elementos: • Bases operacionales de datos: contienen datos provenientes de aplicaciones de transacciones habituales de un área. • Datos de herencia: son datos no necesarios para ejecutar procesos de operaciones actuales, pero que resultan importantes por su valor histórico; deben, por lo tanto, ser incorporados al Datamart, incluyendo la fecha de su vigencia • Fuentes externas: se refiere a datos que interesan con relación a la materia a la que se orienta el Datamart, pero que deben ser obtenidos fuera de la empresa, tales como aquellos datos que surgen de informes de organismos especializados en temas financieros, bursátiles, de investigación del mercado, etc., y que por lo tanto deben ser adquiridos Los datos administrados por los sistemas de aplicación operacionales son la fuente principal de datos para el Datamart por eso es importante saber identificar nuestras fuentes primarias para la obtención de la información en la que está inmersa la organización así como la información que esta genera. 36 2.4.2.2. Extracción, Transformación y Carga. Proceso ETL Como se ha dicho, los volúmenes que maneja la organización cada vez incrementan más y mucho más cuando son utilizados dentro de un Datamart. Es por esta razón que dentro de la arquitectura del Datamart se encuentra una pieza fundamental para la creación de este, y esa pieza es denominada Proceso de Extracción, Transformación y Carga de Datos (ETL). Este es el componente responsable de que la información pueda moverse, con las transformaciones que sean necesarias, desde las fuentes de datos que acabamos de mencionar, al Datamart En este sentido hay que decir que por Datamart puede entenderse tanto el sistema completo como únicamente las bases de datos en las que se almacenan tanto la información extraída de los sistemas anteriores como los metadatos. Se requieren herramientas de gestión de datos para extraer datos desde bases de datos y/o archivos operacionales, luego es necesario manipular o transformar los datos antes de cargar los resultados en el Datamart. Tomar los datos desde varias bases de datos operacionales y transformarlos en datos requeridos para el depósito, se refiere a la transformación o a la integración de datos. Las bases de datos operacionales, diseñadas para el soporte de varias aplicaciones de producción, frecuentemente difieren en el formato. Los mismos elementos de datos, si son usados por aplicaciones diferentes o administradas por diferente software manejadores de base de datos, pueden definirse al usar nombres de elementos inconsistentes, que tienen formatos inconsistentes y/o ser codificados de manera diferente. Todas estas 37 inconsistencias deben resolverse antes que los elementos de datos sean almacenados en el Datamart. En la Figura 2.4 se muestra el entorno del proceso de extracción, transformación y carga de los datos: FIGURA 2.4 Proceso de extracción, transformación y carga Fuente: Faktos, 2008 A continuación se describirá a detalle cada una de las etapas de dicho proceso: • Extraer: La primera parte del proceso de extracción, transformación y carga de datos consiste en extraer los datos desde los sistemas de origen. La mayoría de los proyectos de almacenamiento de datos fusionan datos provenientes de diferentes sistemas de origen. Cada sistema separado puede usar una organización diferente de los datos o formatos distintos. Los formatos de las fuentes normalmente se encuentran en bases de datos relacionales o ficheros planos, pero pueden incluir bases de datos no relacionales u otras estructuras diferentes. La extracción convierte los datos a un formato preparado para iniciar el proceso de transformación. 38 Una parte intrínseca del proceso de extracción es la de analizar los datos extraídos, de lo que resulta un chequeo que verifica si los datos cumplen la pauta o estructura que se esperaba. De no ser así los datos son rechazados. Un requerimiento importante que se debe exigir a la tarea de extracción es que ésta cause un impacto mínimo en el sistema origen. Si los datos a extraer son muchos, el sistema de origen se podría ralentizar e incluso colapsar, provocando que éste no pueda utilizarse con normalidad para su uso cotidiano. Por esta razón, en sistemas grandes las operaciones de extracción suelen programarse en horarios o días donde este impacto sea nulo o mínimo. • Transformar La fase de transformación aplica una serie de reglas de negocio o funciones sobre los datos extraídos para convertirlos en datos que serán cargados. Algunas fuentes de datos requerirán alguna pequeña manipulación de los datos. No obstante en otros casos pueden ser necesarias aplicar algunas de las siguientes transformaciones: • Seleccionar sólo ciertas columnas para su carga (por ejemplo, que las columnas con valores nulos no se carguen). • Traducir códigos (por ejemplo, si la fuente almacena una "H" para Hombre y "M" para Mujer pero el destino tiene que guardar "1" para Hombre y "2" para Mujer). • Codificar valores libres (por ejemplo, convertir "Hombre" en "H" o "Sr" en "1"). • Obtener nuevos valores calculados (por ejemplo, total_venta = cantidad * precio). • Unir datos de múltiples fuentes (por ejemplo, búsquedas, combinaciones, etc.). • Calcular totales de múltiples filas de datos (por ejemplo, ventas totales de cada región). 39 • Generación de campos clave en el destino. • Transponer o pivotar (girando múltiples columnas en filas o viceversa). • Dividir una columna en varias (por ejemplo, columna "Nombre: García, Miguel"; pasar a dos columnas "Nombre: Miguel" y "Apellido: García"). • La aplicación de cualquier forma, simple o compleja, de validación de datos, y la consiguiente aplicación de la acción que en cada caso se requiera: • Datos OK: Entregar datos a la siguiente etapa (Carga). • Datos erróneos: Ejecutar políticas de tratamiento de excepciones (por ejemplo, rechazar el registro completo, dar al campo erróneo un valor nulo o un valor centinela). • Carga La fase de carga es el momento en el cual los datos de la fase anterior de transformación son cargados en el sistema de destino. Dependiendo de los requerimientos de la organización, este proceso puede abarcar una amplia variedad de acciones diferentes. En algunas bases de datos se sobrescribe la información antigua con nuevos datos. Los Datamart mantienen un historial de los registros de manera que se pueda hacer una auditoría de los mismos y disponer de un rastro de toda la historia de un valor a lo largo del tiempo. Existen dos formas básicas de desarrollar el proceso de carga: • Acumulación simple: La acumulación simple es la más sencilla y común, y consiste en realizar un resumen de todas las transacciones comprendidas en el período de tiempo seleccionado y transportar el resultado como una única transacción hacia el datamart, almacenando un valor calculado que consistirá típicamente en un sumatorio o un promedio de la magnitud considerada. • Rolling: El proceso de Rolling por su parte, se aplica en los casos en que se opta por mantener varios niveles de granularidad. Para ello se almacena 40 información resumida a distintos niveles, correspondientes a distintas agrupaciones de la unidad de tiempo o diferentes niveles jerárquicos en alguna o varias de las dimensiones de la magnitud almacenada (por ejemplo, totales diarios, totales semanales, totales mensuales, etc.). La fase de carga interactúa directamente con la base de datos de destino. Al realizar esta operación se aplicarán todas las restricciones y que se hayan definido en ésta como por ejemplo, valores únicos, integridad referencial, campos obligatorios, rangos de valores. Estas restricciones y si están bien definidos contribuyen a que se garantice la calidad de los datos en el proceso ETL, y deben ser tenidos en cuenta. 2.4.2.3. Servidor de datos Este servidor de datos también podría denominarse componente de gestión. Los servicios que debe ofrecer incluyen un servicio de mantenimiento de datos y un servicio de distribución para exportar datos del Datamart a servidores de bases de datos descentralizadas y a otros sistemas de soporte de decisiones de usuario. El componente de gestión también ofrece servicios de seguridad como lo son de archivo, backup, recuperación y monitorización. Generalmente estos servicios utilizan los medios suministrados por el software del sistema operativo y de bases de datos subyacente. El componente de SGBD (Sistema de Gestión de Bases de Datos) consiste en el software de base de datos que se utilice para mantener y extraer datos. Hay dos enfoques diferentes para el almacenamiento de la información: las bases de datos relacionales y las multidimensionales. Así, tendremos gestores de bases de datos relacionales (SGBDR) o gestores de bases de datos multidimensionales 41 (SGBDM). A continuación se discuten las ventajas e inconvenientes de ambas tecnologías de bases de datos. • Ventajas • Proceso de consultas muy rápido en preguntas predeterminadas, aprovechando las dimensiones definidas en la BD (tiempo, geográficas, etc.). • • Alta oferta de productos. • Independencia de plataforma. • Permite todo tipo de consultas no predeterminadas. • Alta escalabilidad. • Altas prestaciones en los productos punteros. Inconvenientes • El tratamiento de las consultas no previstas (fuera de sus dimensiones) es muy lento. • Aumentar el número de dimensiones supone "explosionar" el tamaño de la base de datos. • Falta de estándares. • Proceso lento en consultas complejas, en bases de datos muy grandes, si no se cuenta con plataforma paralela y capacidad de consultas paralelizadas. 2.4.2.4. Herramientas de acceso: Sin las herramientas adecuadas de acceso y análisis el Datamart se puede convertir en una aglomeración de datos sin ninguna utilidad. Es necesario poseer técnicas que capturen los datos importantes de manera rápida y puedan ser analizados desde diferentes puntos de vista. También deben transformar los datos capturados en información útil para el negocio. 42 Actualmente a este tipo de herramientas se las conocen como business intelligence tool (BIT) y están situadas conceptualmente sobre el Datamart. Cada usuario final debe seleccionar que herramienta se ajusta mejor a sus necesidades y a su Datamart. 2.4.2.5 Metadatos: Los metadatos son básicamente datos acerca de los datos contenidos en el Datamart. Así, uno de los problemas con el que pueden encontrarse los usuarios de un Datamart es saber lo que hay en él y cómo pueden acceder a lo que quieren. El repositorio les ayuda a conseguirlo. Es sólo una de las utilidades del repositorio, pero éste tiene muchas funcionalidades: catalogar y describir la información disponible, especificar el propósito de la misma, indicar las relaciones entre los distintos datos, establecer quién es el propietario de la información, relacionar las estructuras técnicas de datos con la información de negocio, establecer las relaciones con los datos operacionales y las reglas de transformación y además limitar la validez de la información. Entonces se pude decir que los metadatos son los datos acerca de los datos. Pueden ser utilizados como una herramienta que almacena datos u otro punto de apoyo para los sistemas de información, guardando la pista de las relaciones entre el Datamart y las Bases de Datos Operacionales, incluyendo además los pasos requeridos para el almacenamiento de los datos. Los metadatos de clasifican en: Metadatos de Transformación y Metadatos de Aplicación. Para comprender más a fondo los metadatos se describe el contenido de estos: • Tablas de Estructura del Datamart • Tabla de Atributos del Datamart 43 • Datos de origen del Datamart (El sistema de registros) • El mapeo desde los sistemas de registros hasta el Datamart. • La especificación de los Modelos de Datos. • La extracción y el registro • Las rutinas de acceso a los datos • Las equivalencias de tipos de datos entre Base de Datos Fuente y Destino. 2.5. Explotación de un Datamart. Es importante recordar que el Datamart no es un fin en sí mismo, sino que es un medio para solucionar una necesidad: el análisis de información y la toma de decisiones a través de los datos de que genera el área específica, objetivo que se logra con el proceso de explotación del Datamart. Este es un componente esencial, ya que es el punto de contacto directo con el usuario final, quien es el encargado de tomar decisiones o acciones que redundan en beneficio de la organización. La explotación de un Datamart consiste en hacer consultas dentro de este, como son el análisis, manipulación y visualización de la información guardada en el Datamart. La forma en la que los datos que contiene el Datamart puede ser explotada es a través de aplicaciones OLAP, el cual se refiere a análisis multidimensional de los datos que contiene el Datamart. Las herramientas de soporte a la toma de decisiones que utilizan las técnicas de análisis multidimensional se conocen como herramienta de procesamiento analítico en línea (OLAP). Las herramientas OLAP son herramientas de minería de datos, las cuales muestran el verdadero problema de las organizaciones, por esta razón es que se 44 crean estas herramientas avanzadas para el análisis de la información que ayudan a la toma de decisiones a los usuarios finales (Rozic &Coronel 2004). Uno de los objetivos de estas herramientas es agilizar la consulta de grandes cantidades de datos. Por ello se utilizan estructuras multidimensionales que contienen datos resumidos de grandes base de datos o sistemas transaccionales. Es por esto que su resultado son informes de negocios de ventas, marketing, informes de dirección, minería de datos y áreas similares. Y esto hará también que el usuario explore la información de manera que vaya descubriendo los intereses de negocios para así analizar la información y llegar a un punto en específico. Los Datamart son identificados como ambientes OLAP en contraposición a los ambientes transaccionales clásicos. Los sistemas OLAP están alineados por dimensión y se focalizan en el cumpliendo de requerimientos del análisis de la organización, o en este caso de un área en especifico de la organización. Sin embargo, en los ambientes OLAP, los datos deben estar integrados. Son conocidos como datos derivados o datos DSS (Sistema de Soporte de Decisión) dado que provienen de sistemas transaccionales o sistemas de archivos maestros preexistentes en las mismas organizaciones o de sistemas externos de información. 2.6. Dos enfoques sobre Datamarts: Inmon y Kimball. Bill Inmon y Ralph Kimball2 son los dos percusores sobre el tema de Datawarehousing, y responsables de los dos enfoques a los que se hace referencia a continuación, ya que hacen mención del uso del los Datamart dentro del ambiente Datawarehouse y podrá ilustrar como es que los Datamarts son los responsables de la integración de la información por áreas especificas del negocio. 45 El hablar de un Datamart como disciplina ha alcanzado ya un grado de madurez considerable a lo largo de estos años, por lo cual también se presentan diferentes enfoques. 2.6.1 Bill Inmon. Bill Inmon es el creador del término Datawarehouse así como del Corporate Information Factory (CIF), conjuntamente con Claudia Imhoff. Es considerado por todos el padre de la disciplina (Exforsys Inc, 2009). Según Bill Inmon, un Datawarehouse es un conjunto de datos orientados por temas, integrados, variantes en el tiempo y no volátiles, que tienen por objetivo dar soporte a la toma de decisiones. Bill Inmon de paradigma: el almacén de datos es una parte del sistema global de inteligencia de negocios. Una empresa tiene un almacén de datos, y los datos marts fuente de su información desde el almacén de datos. 2.6.1.1 Dependientes de la estructura de Data Marts: El enfoque de arriba hacia abajo Bill Inmon vio la necesidad de transportar los datos de las diversas fuentes de la organización a un única fuente que estuviera centralizada, el cual serviría como fuente de análisis de la información obtenida de todos los sistemas operacionales. Donde buscaba que los datos estuvieran almacenados por temas, integrados, variantes en el tiempo y no volátiles (Curto, J., 2009). 46 Cuyo enfoque consta de dos etapas: • Obtención de datos: incluye los procesos en los que los datos son transformados e integrado, de las fuentes de origen (que incluyen Data Quality, Data Staging u otros procesos), creación del Datamart y, en caso de ser necesario, ODS y Staging Area. • Salida de Información: procesos en los que la información extraída, trasformada y cargada se distribuyen a las diferentes bodegas departamentales que responden a necesidades diferentes (lo que llamamos Data Delivery). Las herramientas de explotación de datos atacan las bodegas departamentales y en casos excepcionales al mismo Datawarehouse Corporativo. El enfoque de arriba hacia abajo se determina por el flujo de datos de las diversas fuentes, comenzando con la extracción de los datos de estas fuentes operacionales. Continuando después con el proceso de calidad de los datos, buscando con esto la precisión de los datos obtenidos de las diversas fuentes y con ellos poderlos almacenar en un almacenamiento intermedio. Una vez que estos son pasados por el proceso de calidad son transferidos al almacén de datos o Datamart Una vez que el Datamart ha sido cargado con la información de las diversas fuentes, los datos que contiene el Datawarehouse estos van a ser cargados a los distintos repositorios departamentales, los cuales permitirán tener un área de ensayo y transformación de los datos. Con esto podrán los repositorios de información cargar la información a los diversos sistemas OLAP, los cuales se encuentran en el medio ambiente donde la información estará disponible para los usuarios, los cuales podrán hacer uso para su análisis y así poder realizar el proceso de toma de decisiones. 47 2.6.2 Ralph Kimball. Ralph Kimball es considerado el principal promotor del enfoque dimensional para el diseño de almacenes de datos, el cual determina que un Datawarehouse es una copia de los datos transaccionales específicamente estructurada para la consulta y el análisis. Por su parte, Ralph Kimball es un gurú del diseño de Datawarehouse y creador del enfoque de Modelo Dimensional (MD) (Exforsys Inc, 2009). Ralph Kimball de paradigma: el almacén de datos es el conglomerado de todos los diversos repositorios departamentales que existen dentro de la empresa. La información es siempre almacenada en el modelo dimensional. Kimball también propone el modelo de almacén de datos arquitectura de bus. 2.6.2.1. Almacén de datos de estructura de autobús: El enfoque de abajo hacia arriba Ralph Kimball determina el almacén de datos con la integración de los repositorios intermedios conectados a él con una estructura de bus. La cual contiene todos los elementos comunes que son que son usados por los repositorios intermedios y los cuales conforman las dimensiones. Las cuales determinan toda la información dentro de la organización como un todo (Curto, J., 2009). Por lo cual determinó que la conformación de estos elementos, les permite a los usuarios tener toda la información concentrada en los distintos repositorios departamentales. Todos los repositorios departamentales podrían estar situados en un servidor o en diferentes servidores en toda la organización, mientras que el almacén de datos solo sería una entidad virtual la cuál no sería más que la suma total de todos los repositorios departamentales. 48 En este contexto, incluso la metodología multidimensional que es construida utilizando herramientas OLAP podría ser considerada como repositorios departamentales. Este modelo logra un buen equilibrio entre flexibilidad y la centralización de la información. Los Repositorios departamentales pueden ser entregados con mayor rapidez y las estructuras de datos compartidas a lo largo del autobús eliminan los esfuerzos en la construcción de múltiples repositorios departamentales. El enfoque ascendente invierte las posiciones de los datos y el almacén de repositorios departamentales. Los repositorios departamentales se cargan directamente con los datos de los sistemas operativos a través de la zona. Sin embargo, este método aumenta la complejidad del proceso de coordinación. El flujo de datos en el enfoque ascendente se inicia con la extracción de datos procedentes de bases de datos operacionales en el área donde es procesada y consolidada y, a continuación, cargan la in formación de los sistemas operacionales. Los datos de los sistemas operacionales se añaden o sustituyen por el nuevo almacén de datos donde serán cargados los datos extraídos de los sistemas operacionales. Después de la carga, se actualiza los datos actuales, una vez más, se extrajeron en el área de procesado y para encajar en la estructura de repositorios departamentales. Los datos de los repositorios departamentales a continuación, se extrae al área de agregados, que se resumen y así sucesivamente y cargado en el depósito de datos y puesta a disposición del usuario final para el análisis. La arquitectura MD está separada en dos capas de procesos y servicios: • Back Room: realizan todos los procesos ETL para conseguir los datos de las fuentes de origen (involucrando procesos de data quality, data staging u otros), pero además también se consideran aquellos procesos ETL que alimenta cada uno de los repositorios departamentales independientes 49 existentes en la organización. Kimball distingue además dos tipos de Data Marts: • Atomic Data Marts: contienen la información al nivel de detalle máximo. • Aggregated Data Marts: contienen la información departamento, por áreas o funcional que puede estar alimentado por los anteriores o directamente de la Staging Area. • Front Room: consistente por las herramientas de análisis que usan la información consolidada en los repositorios intermedios de la back room. Es por lo tanto claro, que para cada unidad de negocio se creará un repositorio departamental (o varios) sin tener en cuenta las necesidades de otra unidad. No prima la visión única del dato. 50 CAPÍTULO III. MODELO DE DATOS DE UN DATAMART Introducción. En este capítulo se describirá cada una de las metodologías para el diseño de un Datamart, así como las características de cada uno de estas metodologías, además de ellos los modelados de las base de datos dentro de un Datamart. 3.1 Análisis Multidimensional Se ha descrito cada uno de los componentes de un Datamart, y se ha tomado el este como una solución más rápida para un departamento en especifico, pero también es importante mencionar como es que mediante el diseño multidimensional el Datamart se puede analizar la información y como mediante diversas técnicas se pude obtener información valiosa, pero que cada uno de estas técnicas requieren realizar ciertos procesos para que la información sea procesada, analizada y arroje resultados a los usuarios finales (Wolff, 2008). Es importante mencionar que los sistemas de información cada vez son más complejos y sobre todo la información que manejan es demasiada. Es por esto que se ha hablado de la solución de un Datamart para que esta información no sea desperdiciada y sobre todo buscar su utilidad para que ayuden al soporte de toma de decisiones. Dentro de la organización podría haber miles de datos pero el Datamart permite recolectar y sobre todo analizar esos datos, pero este análisis solo es un aparte de lo que integra al entorno de un Datamart. Una parte importante del entorno del Datamart es el modelado de los datos, ya que el Datamart sin esta parte integrada en su entorno sería inútil, porque no habría forma de que la información pueda ser estructurada para poder tener 52 acceso a ella y mucho menos podría obtenerse información de un Datamart. El Datamart debido a su orientación analítica, impone un procesamiento y pensamiento distinto, la cual se sustenta por un modelamiento de Bases de Datos propio, conocido como Modelamiento Multidimensional, el cual busca ofrecer al usuario su visión respecto de la operación del negocio (Wolff, 2008). El Modelamiento Dimensional es una técnica para modelar bases de datos simples y entendibles al usuario final. La idea fundamental es que el usuario visualice fácilmente la relación que existe entre las distintas componentes del modelo. 3.2 Procesamiento analítico en línea (OLAP) En un almacén de datos, a diferencia de un OLTP, se realizan operaciones de procesamiento analítico en línea (“OLAP - On-Line Analytical Processing”), cuya operación consiste principalmente de consultas sobre grandes volúmenes de datos y de proveer una interfaz en línea que ofrece reportes y gráficos. El procesamiento analítico en línea es una tecnología que permite a los analistas y administradores visualizar y navegar los datos accediendo a una amplia variedad de vistas posibles de la información de manera interactiva, rápida y eficiente (Hurtado Larrain, 2005). Como parte de los servicios de explotación de una arquitectura de análisis de información, los datos tienen que ser modelados multidimensionalmente para satisfacer los requerimientos de desempeño de este tipo de consultas en línea. En esta tesis se hace una diferencia entre el concepto de Datamart y los modelos de datos multidimensionales o cubos puesto que en la arquitectura propuesta los cubos se generan a partir de datos que ya se encuentran en el Datamart, creando redundancia en algunos casos pero ofreciendo al usuario la posibilidad de hacer consultas al almacén de datos sin necesidad de conocer sobre cubos y su 53 manipulación. Otra opción arquitectural es que los cubos estén almacenados en un repositorio de datos separado denominado un servidor de procesamiento analítico en línea y el almacén de datos incluya los datos de detalle almacenados en forma de tablas (Hernández Orallo). En las siguientes secciones se describirán los conceptos sobre cubos, servidores de procesamiento analítico en línea y la visualización y navegación interactiva de modelos dimensionales (González Rosas, 2005) . 3.3 Modelos multidimensionales Un modelo de datos es una representación de los datos y sus relaciones con otros datos que se utiliza para conocer como se organizarán los datos en bases de datos u otro medio de almacenaje y administración de datos. Por ejemplo en el modelo de datos entidad relación (ER) uno puede conceptualizar cada entidad de datos, sus atributos y sus relaciones. En la Figura 3.1 se tiene un modelo o diagrama ER de un sistema operacional. Figura 3.1 Ejemplo de Diagrama Entidad Relación (ER) Fuente: González Rosas, 2005 54 Para construir un Datamart se debe primero tener claro que existe una diferencia entre la estructura de la información y la semántica de la información, y que esta última es mucho más difícil de abarcar y que también es precisamente con ella con la que se trabaja en la construcción de un Datamart. Aquí se encuentra la principal diferencia entre los sistemas operacionales y el Datamart: Cada uno de ellos es sostenido por un modelo de datos diferente. Los sistemas operacionales se sustentan en el Modelo Entidad Relación (MER) y DDW trabaja con el Modelo Multidimensional (Norberto Mazón ,2007). Y este es el modelo de datos utilizado para representar la información contenida en el Datamart: un Datamart puede ser visto como una base de datos dimensional, estructura los datos en forma de dimensiones, de forma que la información pueda combinarse mezclando distintas dimensiones y conceptualización de los modelos de negocio tomados como un conjunto de medidas o vistas descritas por las facetas ordinarias del negocio. Los modelos multidimensionales se prestan fácilmente a representaciones jerárquicas en lo que se conoce como exploración ascendente (roll-up ) y exploración descendente (drill- down). La exploración ascendente desplaza la jerarquía hacia arriba, agrupándola en unidades mayores a través de una dimensión. La exploración descendente ofrece la función contraria (Diaz, 2007). 3.3.1 Esquemas para modelado multidimensional Un reto fundamental en la implementación de un Datamart es mapear el esquema inicial de la base de datos a un modelo multidimensional. Esto requiere de un significativo esfuerzo de programación con muchos de los productos en el mercado hoy en día. 55 En la mayoría de las implementaciones del modelado multidimensional, se asume que los datos han sido preparados para el análisis a través del almacenamiento de datos y que la información se ha extraído de sistemas operacionales, limpiado, validado y resumido antes de incorporarse en una aplicación OLAP. Este es un paso vital en el proceso, que asegura que los datos que son vistos por el usuario OLAP son correctos, consistentes y que llenan las definiciones organizacionales para los datos (Diaz, 2007). Con este tipo de esquemas se simplifica el entendimiento de los datos por parte del usuario, maximiza el desempeño de las peticiones de la base de datos para aplicaciones de soporte de decisiones y requiere menor espacio de almacenamiento para bases de datos grandes. Un modelo de datos multidimensional o cubo es una colección de medidas las cuales dependen de un conjunto de dimensiones, es una representación de los datos que permite organizarlos en la forma de hechos, dimensiones y agregados, los hechos contienen medidas, es decir, la información a nivel transacción que vamos a analizar, por ejemplo: compras, ventas, prestamos, etc. Las dimensiones contienen información descriptiva de esas transacciones por ejemplo: fecha, cliente, producto, etc. Un modelo multidimensional se utiliza para el análisis de información. En la Figura 3.2 se muestra gráficamente los conceptos de hechos y dimensiones: 56 Figura 3.2 Los conceptos de dimensión y hechos Fuente: González Rosas, 2005 La Figura 3.2 muestra el concepto de modelo multidimensional del tema “compras”; a la izquierda se muestran datos transaccionales fuente de ejemplo, a la derecha y abajo se tiene un diagrama de cubo donde hay 2 medidas a analizar: la cantidad y el costo, esos atributos o campos formaran la tabla de hechos del cubo, y se analizarán por 3 dimensiones: La dimensión “producto” que contiene los atributos del producto que se compró. La dimensión “proveedor” que contiene los atributos del proveedor a quien se le compró ese producto y finalmente la dimensión “tiempo” que contiene la fecha en la que se realizó esa transacción de compra. 3.3.2 Esquemas relacionales para representar modelos multidimensionales El esquema relacional almacena datos en tablas relacionales especializadas, llamadas tablas de hechos y de dimensiones, que proveen una vista multidimensional de los datos usando un modelo relacional de soporte. Los hechos son almacenadas en tablas de que son designadas para almacenar los hechos denominada tablas de hechos así mismo sucede con las dimensiones la cual es denomina tabla de dimensiones (Rob & Coronel 2004). El uso de esquemas relacionales normalizados no se adapta bien a la concepción del esquema lógico de un Datamart. Esto se explica por el gran 57 número de relaciones y restricciones causadas por el tratamiento de las consultas típicas de los sistemas OLAP. Para evitar este tipo de inconvenientes, se han propuesto los esquemas desnormalizados en forma de estrella, copo de nieve y constelación. Se tienen diferentes esquemas relacionales para hacer el modelado multidimensional, ver la Figura 3.3 donde se encuentran los diversos esquemas relacionales, a continuación se describe cada uno de ellos: Figura 3.3 Esquemas para representar modelos multidimensionales Fuente: González Rosas, 2005 3.3.2.1 Esquema de estrella (“star schema”): Esquema de la estrella es la arquitectura de Datamart más simple. En este diseño del Datamart la tabla de Variables (Hechos) está rodeada por Dimensiones y juntos forman una estructura que permite implementar mecanismos básicos para poder utilizarla con una herramienta de consultas OLAP (González Rosas, 2005). El esquema de estrella es una técnica de modelado de datos usada para hacer corresponder un modelo multidimensional a una base de datos relacional, debe su nombre debido a que gráficamente parece una estrella. El esquema de estrella tiene cuatro componentes: hechos, dimensiones, atributos y jerarquías de atributos. 58 El motivo por dejar de mantener las tablas en el modelo relacional y permitir el almacenamiento de información redundante, es optimizar el tiempo de respuesta de base datos y dar información a un usuario en menos tiempo posible. Se puede encontrar casi cada información de una tabla de hechos en una tabla de dimensiones. Lo característico de la arquitectura de estrella es que sólo existe una tabla de dimensiones para cada dimensión y esta tabla representa la segunda forma normal (ETL-Tools, 2009). Los hechos y dimensiones son representados por tablas físicas en el almacén de datos, la tabla de hechos está relacionada a cada dimensión en una relación uno a muchos. Las tablas de hechos y dimensiones están relacionadas por llaves foráneas y están sujetas a las restricciones de las llaves foráneas y primarias. A continuación, en la Figura 3.4 se muestra un ejemplo de un esquema de estrella: Figura 3.4 Modelo de estrella con 3 dimensiones y una tabla de hechos Fuente: González Rosas, 2005 Para calcular el total de compras realizadas a proveedores de Internet el esquema de estrella tendría que realizar estos pasos: 1. De la dimensión Proveedor, seleccionar todos los proveedores donde el canal es Internet. 59 2. De la tabla de hechos, seleccionar y calcular la suma de todas las cantidades y costos de las transacciones de compra a los proveedores del paso 1. 3.3.2.2 Esquema de copo de nieve (“snow flake schema”): El esquema de copo de nieve es una variación de la estrella tradicional, lo que se hace es que en cada dimensión se almacenan jerarquías de atributos o bien simplemente se separan atributos en otra entidad por razones de desempeño y mejor utilización del espacio. El afinamiento está orientado a facilitar mantenimiento de dimensiones Con varios usos del esquema en bola de nieve, el más común es cuando las tablas de dimensiones están muy grandes o complejas y es muy difícil representar los datos en esquema estrella (ETL-Tools, 2009). En la Figura 3.5 la dimensión producto se ha modificado separando sus datos generales de sus otras características. Figura 3.5 Modelo de copo de nieve Fuente: González Rosas, 2005 60 3.3.2.3 Esquema de constelaciones (“fact constellation schema”) El modelo de constelaciones nuevamente es una variación del esquema de estrella tradicional, en este modelo algunos atributos de las dimensiones se separan formando una nueva entidad que puede ser compartida con otros cubos, es decir pueden ser dimensione de otros cubos como se muestra en la figura 3.6. La utilidad principal de este modelo es que al tener dimensiones que puede ser compartidas por diferentes cubos se tendrá un mejor uso del espacio de almacenamiento evitando la redundancia (González Rosas, 2005). Este esquema es más complejo que las otras arquitecturas debido al facto de que contiene múltiples tablas de hechos. Con esta solución las tablas de dimensiones pueden estar compartidas entre más que una tabla de los factos. El esquema de constelación de hechos tiene mucha flexibilidad y este facto es su grande virtud. Sin embargo, el problema es que cuando el número de las tablas vinculadas aumenta, la arquitectura puede llegar a ser muy compleja y difícil para mantener (ETL-Tools, 2009). En una esquema de constelación de factos las distintas tablas de los hechos están asignadas a las dimensiones relevantes para cada de los hechos. Esto puede ser útil cuando los hechos están asignadas a un nivel de una dimensión y los otros hechos a otro nivel de detalle de un dimensión. 61 Figura 3.6 Esquema de constelaciones Fuente: González Rosas, 2005 3.3.3 Operaciones con cubos Una vez que se tienen los cubos se puede realizar diferentes operaciones sobre ellos para visualizar y analizar la información, las operaciones son: • Generalizar y especializar, o como en la bibliografía se conoce: abstracción y concreción. (generalizar y especializar). • Corte y corte de cubos (“Slice & Dice”). • Filtrar • Pivotear Estas operaciones se realizan sobre los cubos y generan como resultados subcubos llamados “cuboides”. La especialización y la generalización son operaciones que sirven para navegar un cubo sobre sus dimensiones. Las 62 dimensiones que ofrecen diferentes niveles de abstracción podrán ser navegables, por ejemplo supongamos que tenemos la dimensión tiempo que tiene los nivel de abstracción año, semestre, mes, semana y día, una operación de especialización nos permitirá interactivamente visualizar los hechos desde el agregado total por año e ir descendiendo hasta el detalle por día, la operación generalizar permitirá lo contrario desde cualquier nivel podrá generalizar a un nivel superior por ejemplo de semana a mes. En la figura 3.7 se muestra gráficamente el proceso. Figura 3.7 Operaciones sobre cubos: especializar y generalizar Fuente: González Rosas, 2005 Las operaciones de corte y corte de cubo sirven para ver subconjuntos de cubos, es más, se dice que como resultado generan “subcubos” o “cuboides”. La operación “corte” como la palabra lo indica es una operación que genera una rebanada del cubo, por ejemplo, si de una dimensión tiempo de un cubo únicamente tomamos el mes de “Marzo” y dejamos ver el resto de las dimensiones entonces tendremos la rebanada o corte que corresponde al mes de “Marzo”. Si además de eso condicionamos la dimensión “proveedor”, seleccionando el proveedor “X” de un cubo de “compras”, entonces estaremos obteniendo un “subcubo”, este último es el resultado de una operación de corte de cubo, el ejemplo se puede ver en la figura 3.8. 63 Figura 3.8 Operaciones sobre cubos: corte y corte de cubos Fuente: González Rosas, 2005 Finalmente, la operación filtrar consiste en realizar una selección sobre los datos de un cubo utilizando alguna constante mientras que la operación pivotear sirve para visualizar desde distintos ángulos el cubo, permite rotar los ejes del cubo para examinarlo desde ese punto de vista. La figura 3.9 muestra esas operaciones. 64 Figura 3.9 Operaciones sobre cubos: filtrar y pivotear Fuente: González Rosas, 2005 3.4 Servidores de procesamiento analítico en línea Un servidor de procesamiento analítico en línea permite definir y navegar un modelo multidimensional. El servidor de procesamiento analítico en línea es un administrador de base de datos especializado en el almacenamiento de cubos y en responder de manera optima a las operaciones sobre ellos. El servidor de procesamiento analítico en línea puede ser implementado sobre un DBMS relacional (RDBMS), en cuyo caso se denomina servidor de procesamiento analítico en línea relacional (servidor ROLAP). Este servidor de procesamiento analítico en línea almacena los cubos en tablas relacionales y las operaciones sobre ellos se realizan con SQL o con un SQL extendido para manejar cubos. Además, el RDBMS proporciona algunas funcionalidades para implementar tanto los cubos como las operaciones sobre ellos, por ejemplo: las vistas materializadas o los índices “bitmap”. Cuando se utiliza un servidor especializado para almacenar modelos de datos multidimensionales el servidor se conoce como servidor de procesamiento analítico en línea multidimensional (“servidor MOLAP”), el cual almacena los datos multidimensionales directamente en estructuras de datos especiales (arreglos) e implementa las operaciones de procesamiento analítico en línea sobre esas estructuras. 65 También existe un tipo híbrido de servidor para procesamiento analítico en línea llamado servidor de procesamiento analítico en línea híbrido (HOLAP) que implementa las ventajas de ROLAP y MOLAP utilizando cubos en MOLAP y cuando se quiere ir al detalle de la información utiliza la que se encuentran en tablas relacionales. En cualquiera de los tres casos es necesario almacenar tres tipos de datos: datos de la tabla de hechos (las transacciones), los agregados y las dimensiones. En un servidor ROLAP cada fila en una tabla de hechos tiene una columna para cada dimensión y medida. Las bases de datos MOLAP almacenan los datos de hechos en un formato multidimensional, pero si hay muchas dimensiones, estos datos estarán dispersos y el formato multidimensional no tendrá buen desempeño. Un sistema HOLAP resuelve este problema dejando los datos de mayor granularidad en la base de datos relacional, pero almacena los agregados en un formato multidimensional. También es necesario precalcular agregados cuando el conjunto de datos es muy grande, de otra forma ciertas consultas se responderán haciendo un barrido completo de la tabla de hechos. Los agregados en MOLAP frecuentemente son una imagen de la estructura de datos en memoria, separada en páginas y almacenada en disco. Los agregados ROLAP son almacenados en tablas. En algunos sistemas ROLAP los agregados son manejados explícitamente por el servidor de procesamiento analítico en línea, en otros sistemas, las tablas son declaradas como vistas materializadas y son usadas implícitamente cuando el servidor de procesamiento analítico en línea lanza una consulta con la combinación correcta de columnas en la cláusula "group by" de una instrucción "select". Para mejorar el desempeño de las operaciones de agregación se puede utilizar un caché en la memoria, donde se calculen. 66 En una arquitectura para análisis de información, los datos administrados por el servidor OLAP pueden estar almacenados en la misma base de datos que el almacén de datos o bien en otra por separado, en la misma computadora o en otra diferente. 3.5 Utilización de herramientas OLAP Se dice que las herramientas de procesamiento analítico en línea son de naturaleza reactiva puesto que el trabajador de conocimiento o analista la utilizará para ver lo que ha pasado e identificará indicadores que le permitan corregir el rumbo, por ejemplo, si al darse cuenta que la tendencia ha sido comprar en “Internet” probablemente debería revisar si está recibiendo los descuentos que podría obtener en librerías o valdría la pena revisar cuanto está pagando por gastos de envío para saber si realmente está ahorrando. El procesamiento analítico en línea nos ofrece reportes y gráficos interactivos que si se tuvieran que hacer a partir de las fuentes operacionales seria un proceso complejo de integración de datos que generaría resultados de poca precisión y por lo tanto poca confiabilidad, además de que se invertiría mucho tiempo en completar la construcción de los reportes, tiempo que sería más valioso si se empleará para analizar y tomar decisiones. Esta es una de las grandes ventajas del procesamiento analítico en línea. 67 CAPÍTULO IV. PROPUESTA DE DISEÑO DE UN DATAMART PARA EL SISTEMA DE ASIGNACIÓN DE SINODALES: ANÁLISIS DE LA PROPUESTA Introducción. En este capítulo se presenta la propuesta de diseño Datamart del sistema de asignación de sinodales de la Facultad de Contaduría y Administración, en donde se identificará el entorno de la organización y sobre todo de las necesidades que se puedan identificar para realizar la toma de decisiones, así como la determinación de los requerimientos necesarios para realizar el diseño del Datamart. 4.1 Propuesta de Datamart para el sistema de asignación de sinodales. En la Faculta de de Contaduría y Administración está desarrollándose un sistema de apoyo a la toma de decisiones el cual tiene como objetivo el de asignar los sinodales que participarán dentro del examen profesional de un alumno. Ahora es importante saber cómo se maneja la información dentro del sistema de asignación de sinodales. Pero con ello se busca que este sea eficiente en la toma de decisiones. El proceso de asignación de sinodales se lleva a cabo mediante un conjunto de reglas que ayudan a la elección de los mismos, evaluando la experiencia de los maestros en el tema, es como se seleccionan los dos sinodales titulares y los dos suplentes. Cuyo propósito es facilitarle, al encargado de experiencia recepcional, el proceso de evaluación del perfil de los maestros, dándole a conocer como resultado quienes son los maestros más aptos para 69 fungir como sinodales en los exámenes profesionales. Tomando como referencia el perfil tanto del maestro como del trabajo recepcional. Para la elaboración de este sistema de apoyo a la toma de decisiones se utilizo árboles de decisión, el cual ayuda a arrojar el resultado más óptimo comparando el perfil del trabajo con el de los maestros, ya que los arboles de decisión es un diagrama que representan en forma secuencial condiciones y acciones, mostrando qué condiciones se consideran en primer lugar, en segundo lugar y así sucesivamente (UNSL, 2006). Esta técnica permite mostrar la relación que existe entre cada condición y el grupo de acciones permisibles asociado con ella. Además de la toma de decisiones, el sistema ayuda a controlar las peticiones de los alumnos llevando un registro de los trabajos recepcionales, siendo los propios alumnos quienes introducen el perfil de su trabajo al sistema, en lugar de el encargado de la experiencia recepcional, éste solo atiende las peticiones aceptándolas o rechazándolas según su criterio, luego de aceptarlas les asigna a sus sinodales, con la ayuda antes mencionada que proporciona el sistema. De esta manera se facilita el trabajo de asignación y el tiempo que se llevaría en hacerlo manualmente. Ahora se busca lograr un mejor desempeño en la toma de decisiones con el sistema de asignación de sinodales, es por esta razón que se propone el diseño de un Datamart, que permita tener un histórico de la información que maneja el sistema de asignación de sinodales y pueda realizarse el modelado multidimensional permitiendo con ello solo obtener la información de relevancia para el proceso de toma de decisiones, permitiendo con ello que se ligue los perfiles de los maestros, sus líneas de investigación, si el trabajo recepcional pertenece a un cuerpo académico, el comportamiento de calificaciones, y las tendencias de las modalidades seleccionadas por los alumnos, etc. 70 Para poder desarrollar la propuesta de Diseño un Datamart para el sistema de asignación de sinodales se ha abordado el tema de Datawarehouse, en donde se menciono los componentes de un Datawarehouse, y que una parte importante es el componente Datamart, el cual permite tener la información de un departamento en especifico de toda una organización, permitiendo con ello facilitar la obtención de información de acuerdo a un área en especifico, sin afectar a los sistemas transaccionales y sobre todo permitiendo conservar los datos históricos de los sistemas transaccionales. En este caso del sistema de asignación de sinodales. Pero también se hace énfasis en la Metodología propuesta por Ralph Kimball, la cual ha sido mencionada en capítulos anteriores, y que indica que para poder realizar un Datawarehouse, es necesario realizar diversos Datamarts que identifique las diversas áreas de la organización. Y poder realizar una eficiente recolección de datos de los sistemas transaccionales. Teniendo en cuenta la demanda de alumnos que cada año se gradúan mediante la modalidad de Trabajo Recepcional en cualquiera de sus variantes (tesis, tesina, monografía); y que como se sabe dentro de la Facultad de Contaduría y Administración existen cuatro carreras como lo son la de Administración , Contaduría y Sistemas Computacionales Administrativos y las actual carrera de Dirección y Gestión de Negocios que actualmente no tiene una demanda de titulación pero que al cabo de tres años se agregara a esta demanda pudiendo contar con las ventajas que la propuesta desea aplicar al sistema de asignación de sinodales. Y tomando en cuenta el diseño de un Datamart del sistema se buscara identificar y analizar las tendencias que abarca el departamento de experiencia recepcional, ya que no solo se analizara al sistema si no que se buscara analizar la situación de cada uno de los actores que intervienen en la información que genera dicho sistema. 71 Es por esto que la propuesta va encaminada al diseño de un Datamart con la información que se maneja en el sistema de asignación de sinodales, tratando de que un Datamart sea una solución que tenga los beneficios de contar con un almacén de datos pero con contenidos específicos, volumen de datos más limitado y un alcance histórico menor, permita dar soporte al área de Coordinación Experiencia Recepcional. 4.1.1 Estructura y Módulos del sistema de apoyo a la toma de decisiones El sistema de apoyo a la toma de decisiones en el proceso de asignación de sinodales está conformado por dos módulos: • Módulo de alumno • Módulo de coordinación de experiencia recepcional. Módulo de alumno En la opción de Experiencia Recepcional el alumno podrá: • Registrarse En la opción de registrarse el alumno, en primer lugar verifica sus datos personales generales y elije la modalidad a cursar la experiencia recepcional: Trabajo recepcional o Examen de CENEVAL. En caso de seleccionar Examen, el proceso de registro termina aquí. Para el caso de trabajo recepcional, el alumno debe continuar detallado los datos generales de su trabajo como el título, a que cuerpo académico va a pertenecer o no, el contenido de su trabajo y la modalidad, en este caso refiriéndose a: Monografía, Tesina o Tesis. 72 Por último el alumno deberá especificar los datos referentes al perfil del trabajo recepcional de acuerdo al contenido antes especificado. Si el trabajo pertenece a un cuerpo académico el sistema muestra los profesores pertenecientes a ese cuerpo y el alumno debe elegir director y codirector de trabajo, en caso de que no, el sistema muestra a todos los profesores disponibles en el plan de estudios que cursa el alumno y solo debe elegir a un director. El alumno debe seleccionar al menos un área a la que va a pertenecer su trabajo recepcional. Este punto es primordial e importante puesto que de este dato se tomara la información para poder mostrar la propuesta de sinodales. El trabajo puede tener dos áreas de desarrollo. Una vez concluidos los datos solicitados, la solicitud de registro es asentada en la base de datos y estará lista para que sea validada por el coordinador de experiencia recepcional. • Ver Estado Si el alumno no ha registrado su solicitud, entonces el sistema hará que registre sus datos. En caso de que ya haya registrado la solicitud, en este apartado el alumno podrá ver si ha sido aceptada o rechazada en función al coordinador de experiencia recepcional. Si la solicitud fue rechazada, mostrara las observaciones que haya hecho el coordinador de experiencia recepcional y tendrá la opción de modificar sus datos. De manera similar a como el alumno se registro por primera vez. Si la solicitud fue aceptada, el alumno podrá saber que está en proceso de asignación de sus sinodales. 73 Finalmente, una vez asignados los sinodales, el sistema le mostrará al alumno los datos generales de su registro junto con la lista de sinodales que le han sido asignados. Módulo de coordinación de experiencia recepcional En coordinador de Experiencia Recepcional deberá seleccionar el plan de estudios dentro de las dos opciones que tiene: • Trabajo recepcional En esta parte el coordinador de la experiencia recepcional podrá ver a todos los alumnos que han registrado la solicitud inscritos con la modalidad de trabajo recepcional. El listado de alumnos se mostrara en función a su estado, las solicitudes que no han sido atendidas se manejan con estado PENDIENTE y son las primeras en salir puesto que no han sido revisadas por primera vez. Posteriormente vera las rechazadas y finalmente las aceptadas. El coordinador selecciona una solicitud pendiente y de esta manera el sistema muestra la información de la solicitud de alumno, si los datos registrados son correctos, la solicitud será aceptada. En caso contrario el coordinador deberá escribir las observaciones y la solicitud tendrá un estado de RECHAZADA. En caso de que el coordinador seleccione solicitudes RECHAZADAS o ACEPTADAS, el sistema mostrará los datos generales de la solicitud y si es el caso las observaciones realizadas. En caso de seleccionar Examen, el proceso de registro termina aquí. Para el caso de trabajo recepcional, el alumno debe continuar detallado los 74 datos generales de su trabajo como el título, a que cuerpo académico va a pertenecer o no, el contenido de su trabajo y la modalidad, en este caso refiriéndose a: Monografía, Tesina o Tesis. Para poder atender y dar prioridad a las solicitudes pendientes, en la página de inicio, por default, el sistema mostrara solo las solicitudes pendientes de todos los planes de estudios. • Sinodales Dependiendo del plan de estudios seleccionado, el sistema mostrara solo las solicitudes que han sido aceptadas. El coordinador deberá seleccionar asignar y de esta manera podrá ver los datos de la solicitud. En ese caso el coordinador deberá elegir dos sinodales titulares y dos sinodales suplentes. En caso de que haya pertenecido a un cuerpo académico, el sistema deshabilitara la opción del primer sinodal titular y deberá elegir solo los tres sinodales restantes, ya que al pertenecer al cuerpo académico puede existir un co-director el cual automáticamente será asignado como sinodal, por lo tanto solo estaría cubrir tres sinodales vacantes. Para cada sinodal el coordinador puede elegir entre la lista de todos los profesores activos pertenecientes a ese plan de estudios o seleccionar la opción de SATD, sistema de apoyo a la toma de decisiones. En este apartado el sistema implementará, de acuerdo a los arboles de decisión antes mencionados, la búsqueda de los profesores que tengan mayor afinidad con las áreas a las que pertenece el trabajo. El sistema dividirá el listado de profesores en las dos áreas en caso de que pertenezca a dos áreas el trabajo recepcional. Por cada profesor 75 que salga, se mostrará el numero de asesorados y el porcentaje con el que ese profesor cubre con el perfil del trabajo. De esta manera el coordinador puede elegir la opción que más le conviene. Por seguridad e integridad en el sistema los profesores asignados para cada sinodales no pueden ser los mismo, por lo tanto ya sea de manera directa del listado o con ayuda del sistema para las mejores opciones, por cada alumno se tendrá un jurado con cinco diferentes profesores. 4.2 Beneficios del Diseño de un Datamart para el sistema de asignación de sinodales. Una de las claves del éxito en la construcción de un Datamart 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 en este caso se hará del área de Experiencia Recepcional el cual se tomara como base para poder realizar el Diseño de un Datamart. 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 pueda obtener y medir resultados a corto plazo. A continuación se enumera los beneficios que un Datamart puede aportar: 1. Proporciona una herramienta para la toma de decisiones en el área funcional, basándose en información integrada y global. 2. 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. 76 3. Proporciona la capacidad de aprender de los datos del pasado y de predecir situaciones futuras en diversos escenarios. 4. 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. 4.3 Etapas de Creación de un Datamart. Dentro del desarrollo de un Datamart se tiene contemplado diversas etapas que definen el proceso desde la identificación de la problemática y la solución para esta el diseño de un Datamart, en donde brindara a los usuarios las herramientas necesarias para la obtención de la información y que esta sea la fuente para la correcta toma de decisiones. Es por este que se definen a continuación las etapas que abarcan la construcción de un Datamart y cuales serán tomadas para la realización de esta investigación, es decir, identificar cuáles serán analizadas y desarrollas dentro de esta investigación: Figura 4.1 Etapas de Creación del Datamart del sistema de asignación de sinodales 77 Etapa Actividades Analizar las necesidades del cliente. • Definición de los Objetivos Hacer comprender al cliente lo que puede aportar el nuevo Sistema Definir los parámetros para evaluar el nivel de éxito a conseguir Análisis de las fuentes de • Análisis: información Identificar las transformaciones a realizar sobre la información • Diseño y Modelamiento Definición del Modelo Conceptual Definición del Modelo Lógico Definición Modelo Físico Extracción de la Información. • Implementación Transformación de la Información Carga de la Información Explotación de la Información • Revisión Tarea iterativa con los usuarios. Planteamiento de preguntas para potenciar la explotación. 78 Identificación de mejoras en el Sistema Tabla 4.1 Descripción de Actividades de las etapas de Creación de un Datamart 4.4 Alcance de la Propuesta de Diseño de un Datamart para el sistema de asignación de sinodales. Dentro de este trabajo se abarcará hasta la etapa de diseño y modelización de los datos buscado con ellos poder identificar y apreciar el valor de contar con un Datamart que permita ser el repositorio central de la información de valor para el departamento de experiencia recepcional y de los directivos de la Facultad de Contaduría y Administración. Figura 4.2 Etapas desarrolladas del Datamart por la propuesta de Diseño de un Datamart al sistema de asignación de sinodales 79 Dentro de la etapa a la que se llegara se mostrara la parte física de los datos en la base de datos que manejaran el Datamart así como cada uno de los actores que intervienen el proceso de toma de decisiones del sistema de asignación de sinodales. Hasta este punto ya se ha abarcado la definición de los objetivos donde ya se identificaron las necesidades de la organización en particular el área de Experiencia Recepcional donde se propone el diseño de un Datamart, además de esto también se mencionaron las ventajas que conllevaría contar con esta tecnología de negocio haciendo hincapié en el hecho que fortalecerá la toma de decisiones que se lleva dentro en el proceso de asignación de sinodales y por último el análisis y diseño de la propuesta la cual dará un reflejo del éxito que se tendrá al contar con esta tecnología de negocio, buscando con ello el interés de contar con esta tecnología en diversas áreas dentro de la organización. 4.4.1 Objetivo General de la propuesta Permitir identificar las necesidades del sistema de asignación de sinodales, lo cual permita conocer la base de datos actual, y con el diseño de un Datamart de cómo resultado una fuente de información confiable, adecuada y que esté disponible en el momento en que los usuarios la necesiten para poder ser analizada y ayude a la toma de de decisiones. 4.4.2 Objetivos particulares de la propuesta Se contemplan los siguientes objetivos: • Tener el conocimiento de la existencia de un único lugar de acceso a la información en el área de Experiencia Recepcional. 80 • Identificar un único acceso a información preparada para el análisis lo cual facilitará el proceso de toma de decisiones • Identificar la información que genera el sistema. • Conocer la información, poder realizar un diseño y modelamiento para un mejor análisis de la información que genera el sistema. • Establecer los fundamentos de lo que es ahora llamado Inteligencia de Negocios en la universidad 4.5 Actividades realizadas en la etapa de Análisis: La siguiente etapa a desarrollar en el diseño, para esto es primordial identificar los requisitos para realizar el diseño y sobre todo las actividades a realizar dentro de la etapa, para ellos en la tabla 4.1 se muestra de manera concreta las actividades planeadas para poder llevar con éxito la etapa de diseño, la cual posteriormente se mostrara su desarrollo: Actividad Tareas 1.- Describir entidades del modelo de datos Análisis de estado de La fuente de información Productos Documento de texto Técnicas o Practicas Descripción fuente 2.- Describir atributos del modelo de datos fuente Documento de texto Descripción 81 3.- Describir el modelo de datos Modelo de datos fuente fuente Diseño Físico Tabla 4.2 Actividades de la etapa de análisis de la propuesta de diseño de un Datamart 4.5.1 Descripción de entidades del modelo de datos fuentes Es importante mencionar que la fuente de datos del sistema de asignación de sinodales la provee el Sistema Integral de Gestión Administrativa denominado SIGA, el cual tiene como objetivo gestionar e integrar los procesos académicos y administrativos de la Facultad de Contaduría y Administración. Permitiendo la eficiencia entre ellos y la adecuada toma de decisiones, por lo tanto se utilizo la base de datos del SIGA, y el sistema de asignación de sinodales solo toma aquellas entidades que le son importante para el proceso que tiene definido, y se han agregado otras dentro del sistema para hacer mas eficiente y cumplir con el objetivos del sistema de asignación de sinodales. Se mostrara el diseño físico en esta etapa, aun cuando se está acostumbrado a verlo en la parte de diseño, pero en este las fuentes de datos se convierten en parte del análisis de la propuesta ya que ella se desglosa la información necesaria para realizar el diseño del Datamart. A continuación en la tabla 4.3 se muestra las entidades que intervienen en el sistema así como sus descripciones: 82 NOMBRE LÓGICO NOMBRE FÍSICO DESCRIPCIÓN Nombres de academias Academias academias y áreas a las que pertenecen. Alumnos alumnos Datos personales de los alumnos. Catalogo de las áreas a Área Académica area_cademica las que pertenecen las academias. Área General. Especifica las áreas a Área del Trabajo Recepcional area_trabajo las que puede pertenecer un trabajo recepcional. Datos personales de los Catalogo de Profesores cat_profesor Profesores y el estado en que se encuentran. Contenido de trabajos recepcionales Cuerpo académico contenido_trabajorec cuerpo_academico Capítulos de cada trabajo recepcional. Catalogo del cuerpo académico. Catalogo de Experiencias educativas materias Experiencias educativas y su perfil. Cuerpo académico y profesores Profesores y cuerpo prof_cuerpo_acad académico al que pertenecen 83 Áreas a las que Perfil de profesores profesor pertenecen los profesores. Sesiones Datos del usuario que sesiones exceda al sistema. Relaciona al jurado con Sinodales y alumnos cada alumno inscrito en sinodal_alumno la modalidad de experiencia recepcional. Trabajo Recepcional Perfil y estado de cada trabajo_recep trabajo recepcional. Tabla 4.3 Descripción de entidades del Sistema de Asignación de Sinodales 4.5.2 Descripción de atributos del modelo de datos fuente Se mostraran en las Tablas de la 4.4 a la 4.16 los atributos de cada una de las entidades que conforman al sistema de asignación de sinodales: ACADEMIAS ATRIBUTO id_academia Nom_academia Id_nombre DESCRIPCION Numero de academia. Nombre de academia. Área a la que pertenece la academia. Tabla 4.4 Atributos de la entidad Academias 84 ALUMNOS ATRIBUTO Mat_ext DESCRIPCION Matricula externa, de la universidad Apellido_paterno Apellido_materno Nombre Calle Colonia Ciudad Codigo_postal Estado Carrera Tel_emergencia Matricula_interna Sexo Email Apellido paterno Apellido materno Nombre (s) del alumno Dirección Colonia Ciudad donde vive código postal estado donde vive plan de estudios que está cursando teléfono para emergencias matricula interna, dentro de la facultad sexo Correo electrónico. 85 Nombre de usuario para ingresar Usuario al sistema. Contraseña para ingresar al Contraseña sistema. Tabla 4.5 Atributos de la entidad Alumnos ÁREA ACADÉMICA DESCRIPCION ATRIBUTO numero de área académica No_area nombre del área académica Nombre_area Tabla 4.6 Atributos de la entidad Area Academia ÁREA DEL TRABAJO RECEPCIONAL ATRIBUTO No_area Nombre_area DESCRIPCION Numero de área Nombre del área Tabla 4.7 Atributos de la entidad Area Trabajo recepcional CATALOGO DE PROFESORES ATRIBUTO No_personal Apellido_paterno DESCRIPCION Numero de personal dentro de la institución apellido paterno apellido materno 86 Apellido_materno Nombre Email Teléfono Sexo Activo Num_asesorados Contraseña nombre(s) del profesor correo electrónico número de teléfono sexo si el maestro esta activo en el periodo actual numero de asesorados para trabajos recepcionales Contraseña de acceso al sistema Tabla 4.8 Atributos de la entidad Catalogo de Profesores CONTENIDO DE TRABAJOS RECEPCIONALES ATRIBUTO Mat_ext Num_capitulo Nom_capitulo DESCRIPCION clave de alumno para identificar su trabajo numero de capitulo nombre del capitulo Tabla 4.9 Atributos de la entidad Contenido De Trabajos Recepcionales 87 SESIONES ATRIBUTO DESCRIPCION nombre de usuario Usuario nivel de acceso Nivel_acceso fecha en la que accede Fecha_acceso Tabla 4.10 Atributos de la entidad Sesiones MATERIAS ATRIBUTO DESCRIPCION numero de materia id_materia nombre de la materia Nombre id_academia No_area clave de academia a la que pertenece numero de área general Tabla 4.11 Atributos de la entidad Materias CUERPO ACADÉMICO ATRIBUTO No_cuerpo Nombre_cuerpo DESCRIPCION numero de la subárea de cuerpo académico nombre del la subárea de cuerpo académico Tabla 4.12 Atributos de la entidad Cuerpo Académico 88 CUERPO ACADÉMICO Y PROFESORES ATRIBUTO No_personal DESCRIPCION numero de personal del profesor nombre completo del profesor Nombre No_cuerpo Clave del cuerpo académico al que pertenece. Tabla 4.13 Atributos de la entidad Cuerpo Académico y Profesores PERFIL DE PROFESORES ATRIBUTO No_personal No_area Id_academia Id_materia DESCRIPCION numero de personal del profesor clave del área general calve de la academia clave de la materia Tabla 4.14 Atributos de la entidad Perfil de Profesores SINODALES Y ALUMNOS ATRIBUTO Mat_ext No_personal sinodal1 DESCRIPCION matricula del alumno numero de personal del director del trabajo numero de personal del primer 89 sinodal del trabajo Sinodal2 suplente1 Suplente2 numero de personal del segundo sinodal del trabajo numero de personal del primer suplente del trabajo numero de personal del segundo suplente del trabajo Tabla 4.15 Atributos de la entidad Sinodales y Alumnos TRABAJO RECEPCIONAL ATRIBUTO Mat_ext Nombre Area1 Area2 Observaciones No_cuerpo Id_edo Id_mod DESCRIPCION matricula del alumno nombre del trabajo área específica a la que puede pertenecer segunda área especifica muestra si fue aceptado o rechazada la solicitud de registro clave del cuerpo académico al que pertenece Clave del estado en que se encuentra el trabajo recepcional Clave de la modalidad del trabajo Tabla 4.16 Atributos de la entidad Trabajo Recepcional 90 4.5.3 Descripción del modelo de datos fuente En esta actividad en la Figura 4.3 se muestra el diseño físico actual de la base de datos con la que cuenta en sistema de asignación de sinodales: Figura 4.3 Modelo Físico de la base de datos del Sistema de Asignación de sinodales Se ha concluido satisfactoriamente la identificación de la fuente de datos que actualmente tiene el sistema de asignación de sinodales y así poder continuar con la siguiente etapa de diseño. 91 CAPÍTULO V. DISEÑO DE LA PROPUESTA Introducción. Dentro de este capítulo de presenta la el diseño de la propuesta de Datamart al sistema de asignación de sinodales, en donde se mostraran diversos esquemas de la información y su transformación para ser utilizada por el Datamart, dando como resultados diseño conceptual, lógico, físico y además de ellos el modelado mediante los indicadores que se planteen como necesarios. 5.1 Actividades de la Etapa de Diseño del Datamart En la Tabla 5.1 se muestran las actividades que se realizaran durante esta etapa y posteriormente se mostraran los resultados de dichas actividades: Actividad Tareas Productos 1.- Describir entidades del Datamart Documento de 2.- Describir atributos Datamart Documento de Análisis de estado de La fuente de información 3.- Describir el modelo de datos de Datamart texto texto Modelo de datos fuente Técnicas o Practicas Descripción Descripción Diseños Tabla 5.1 Actividades de la Etapa de Diseño de Datamart 93 Para poder comenzar con las actividades que se plantea en el diseño del Datamart, se harán unos cambios al modelo físico de la base de datos del sistema de asignación de sinodales, ya que se encontró que hace falta contar con otra información que sería de relevancia para el Datamart, dichas modificaciones se muestran en modelo lógico en la Figura 5.1, donde se agrega un catalogo de las modalidades manejadas dentro del departamento de experiencia recepcional y otro catalogo del estado de la solicitud : Figura 5.1 Modelo Lógico Modificado 94 5.1.1 Descripción entidades del Datamart Aquí en las Tablas 5.2 y 5.3 se mostraran las tablas de dimensiones y hechos que serán ocupadas para el modelamiento multidimensional y así poder obtener información de relevancia de la base de datos operacional y también el conocer que información será de utilidad para el Datamart y cual seguirá solo siendo parte del sistema de apoyo a la toma de decisiones: NOMBRE LÓGICO NOMBRE FÍSICO Dimensión Carrera DimCarrera Dimensión Area DimArea Dimensión Generacion DimGeneracion Dimensión Modalidad DimModalidad Dimensión Profesor DimProfesor Dimensión Cuerpo Académico DimCuerpoAcademico Dimensión Calificación DimCalificacion Dimensión Estado DimEstado Dimensión Alumno DimAlumno Dimensión Trabajo Recepcional DimTraRec Dimensión Academia DimAcademia DESCRIPCIÓN Entidad dimensional contiene a las carreras y sus datos Entidad dimensional contiene las áreas de academias y sus datos Entidad dimensional contiene las generaciones y sus datos Entidad dimensional contiene las diversas modalidades y sus datos Entidad dimensional contiene a los profesores y sus datos Entidad dimensional contiene los cuerpos académicos y sus datos Entidad dimensional contiene las calificaciones y sus datos Entidad dimensional contiene los diversos tipos de estados y sus datos Entidad dimensional contiene los datos de los alumnos Entidad dimensional contiene los datos del trabajo recepcional Entidad dimensional contiene los datos las academias 95 Dimensión Area Académica DimAreaAcademica Entidad dimensional contiene los datos las academias Tabla 5.2 Tablas de dimensiones para el Datamart NOMBRE LÓGICO Hecho Trabajos Recepcionales Hecho Calificaciones Hecho Modalidad Hecho Cuerpo Academico NOMBRE FÍSICO DESCRIPCIÓN Entidad de hecho que HecTrabRec contiene la los trabajos Recepcionales Entidad de hecho que contiene las HecCalifiacion calificaciones obtenidas en la presentación de trabajo recepcional Entidad de hecho que contiene las Modalidades con las HecModalidad cuales son elaborados los trabajos recepcionales Entidad de hecho que contiene las los cuerpos HecCuerpoAcademico académicos que realizan algún trabajo recepcional Tabla 5.3 Tablas de hechos para el Datamart 5.1.2 Descripción atributos del modelo de datos del Datamart DIMENSIÓN CARRERA DESCRIPCION ATRIBUTO Id_carrera Nom_carrera Identificador de la carrera Nombre de la carrera Tabla 5.4 Atributos de la Tabla Dimensión Carrera 96 DIMENSIÓN ÁREA DESCRIPCION Id_area Nom_area Des_area Id_academia ATRIBUTO Identificador del área a la que pertenece el trabajo Nombre del area Descripción del área correspondiente Identificador de la academia ala que pertenece de la tabla DimAcademia Tabla 5.5 Atributos de la Tabla Dimensión Area DIMENSIÓN GENERACION DESCRIPCION ATRIBUTO Id_generacion Año_generacion Identificador del año de análisis Numero del año del historico Tabla 5.6 Atributos de la Tabla Dimensión Tiempo DIMENSIÓN MODALIDAD DESCRIPCION ATRIBUTO Identificador del modalidad a la Id_modalidad que pertenece el trabajo Nom_modalidad Nombre del modalidad Tabla 5.7 Atributos de la Tabla Dimensión Modalidad 97 DIMENSIÓN PROFESOR DESCRIPCION ATRIBUTO Identificador del profesor del Id_profesor trabajo recepcional Nom_profesor Id_cuerpoacademico Nombre del profesor Identificador del cuerpo académico al que pertenece de la tabla DimCuerpoAcademico Tabla 5.8 Atributos de la Tabla Dimensión Profesor DIMENSIÓN CUERPO ACADEMICO DESCRIPCION ATRIBUTO Identificador del cuerpo académico al que pertenece el Id_cuerpoacademico trabajo Nom_cuerpoacademico Nombre del cuerpo académico Tabla 5.9 Atributos de la Tabla Dimensión Cuerpo Académico DIMENSIÓN CALIFICACIÓN DESCRIPCION ATRIBUTO Identificador de la calificación del Id_calificacion trabajo ponderación Numero de ponderación del 1 al 10 Tabla 5.10 Atributos de la Tabla Dimensión Calificación DIMENSIÓN ESTADO DESCRIPCION ATRIBUTO Identificador del estado del Id_estado trabajo, aprobad o reprobado Nom_estado Nombre del estado 98 Tabla 5.11 Atributos de la Tabla Dimensión Estado DIMENSIÓN ALUMNO DESCRIPCION ATRIBUTO Identificador del alumno al que Id_alumno pertenece el trabajo Nom_alumno Direcc_alummo Id_carrera Nombre del alumno Dirección del alumno Identificador de la carrera a la que pertenece de la tabla DimCarrera Tabla 5.12 Atributos de la Tabla Dimensión Alumno DIMENSIÓN TRABAJO RECEPCIONAL DESCRIPCION ATRIBUTO Id_trabrec Nom_trabrec Id_alumno Identificador del trabajo Nombre del trabajo Identificador del alumnos que realizó el trabajo recepcional de la tabla DimAlumno Tabla 5.13 Atributos de la Tabla Dimensión Trabajo Recepcional DIMENSIÓN ACADEMIA DESCRIPCION ATRIBUTO Identificador de la academia Id_academia correspondiente Nom_academia Id_areaacademiaca Nombre de la academia Identificador del área académica a la que pertenece de la tabla 99 DimAreaAcademica Tabla 5.14 Atributos de la Tabla Dimensión Academia DIMENSIÓN AREA ACADEMICA DESCRIPCION ATRIBUTO Identificador del área académica Id_areaacademia a la que pertenece Nom_areaacademia Nombre del área academia Tabla 5.15 Atributos de la Tabla Dimensión Area Academia HECHO TRABAJO RECEPCIONAL DESCRIPCION ATRIBUTO Código de identificación en la Id_trabrec tabla DimTraRec Id_area Código de identificación en la tabla DimArea Id_generacion Código de identificación en la tabla DimTiempo Id_alumno Código de identificación en la tabla DimAlumno Id_profesor Código de identificación en la tabla DimProfesor Tabla 5.16 Atributos de la Tabla Hecho Trabajo Recepcional HECHO CALIFICACION DESCRIPCION ATRIBUTO Código de identificación en la Id_trabrec tabla DimTraRec Id_cuerpoacademico Código de identificación en la tabla DimCuerpoAcademico 100 Id_generacion Código de identificación en la tabla DimGeneracion Id_carrera Código de identificación en la tabla DimCarrera Id_calificacion Código de identificación en la tabla DimCalificacion Id_estado Código de identificación en la tabla DimEstado Tabla 5.17 Atributos de la Tabla Hecho Calificación HECHO MODALIDAD DESCRIPCION ATRIBUTO Código de identificación en la Id_modalidad tabla DimModalidad Id_area Código de identificación en la tabla DimArea Id_generacion Código de identificación en la tabla DimGeneracion Id_alumno Código de identificación en la tabla DimAlumno Id_profesor Código de identificación en la tabla DimProfesor Id_cuerpoacademico Código de identificación en la tabla DimCuerpo Id_carrera Código de identificación en la tabla DimCarrera Tabla 5.18 Atributos de la Tabla Hecho Modalidad HECHO CUERPO ACADEMICO DESCRIPCION ATRIBUTO Código de identificación en la Id_modalidad tabla DimModalidad Id_generacion Código de identificación en la tabla DimGeneracion 101 Id_alumno Código de identificación en la tabla DimAlumno Id_cuerpoacademico Código de identificación en la tabla DimCuerpo Id_carrera Código de identificación en la tabla DimCarrera Tabla 5.19 Atributos de la Tabla Hecho Cuerpo Académico 5.1.3 Descripción el modelo de datos de Datamart Con la construcción del Datamart se tiene una estructura de datos simplificada y pensada para que los datos puedan ser extraídos de manera eficiente. Una de las técnicas utilizadas para la extracción de datos es a través del análisis multidimensional, como ya se ha mencionado antes. Para realizar el análisis multidimensional se realizan modelos de datos especiales, conocidos como Modelo en Estrella y Modelo Copo de Nieve, los acules ya fueron descritos anteriormente, y ahora serán aplicados al diseño del Datamart. Este tipo de modelo es importante a fin de dar soporte a las necesidades del sistema. Para realizar el modelamiento de datos del Datamart se analizó de una serie de herramientas para modelar base de datos. El seleccionado fue DBDesigner versión 4, a continuación describiremos la herramienta seleccionada: • DBDesigner es un sistema totalmente visual de diseño de bases de datos, que combina características y funciones profesionales con un diseño simple, muy clara y fácil de usar, a fin de ofrecerte un método efectivo para gestionar tus bases de datos. Te permite administrar la base de datos, diseñar tablas, hacer peticiones SQL manuales y mucho más, como ingeniería inversa en 102 MySQL, Oracle, MSSQL y otras bases de datos ODBC, modelos XML y soporte para la función drag-and-drop. El programa dispone además de una interfaz profesional y de detallados manuales de uso 5.1.3.1 Esquema de copo de nieve del Datamart Desde la Figura 5.2 hasta la Figura 5.5 se presentan los distintos modelos para cubrir las necesidades de las funciones presentadas anteriormente. 103 Figura 5.2 Esquema Copo de Nieve para los Trabajos Recepcionales elaborados 104 Figura 5.3 Esquema Copo de Nieve las Calificaciones obtenidas mediante los trabajos recepcionales 105 Figura 5.4 Esquema Copo de Nieve las Modalidades existentes para los trabajos recepcionales 106 Figura 5.5 Esquemas Copo de Nieve los Cuerpos académicos que participan en los trabajos recepcionales Una vez realizado el modelamiento mediante el esquema copo de nieve, es concluida la etapa de diseño. La propuesta fue concluida satisfactoriamente buscando con esto demostrar la capacidad de análisis de información que se desea obtener con el diseño de un Datamart al sistema de asignación de sinodales. 107 CONCLUSIONES Es importante destacar que en el desarrollo de este trabajo se cumplió con el objetivo principal que era de dar a conocer los beneficios de realizar el Diseño de un Datamart para el sistema de asignación de sinodales, ya que el diseño propuesto dentro de este trabajo, permite identificar y mostrar que el Datamart es una tecnología que puede desarrollarse por completo y permitirá que el sistema pueda aportar información de relevancia a los Directivos, sobre el comportamiento del área de Experiencia Recepcional y así pode realizar toma de decisiones que permita analizar y estudiar la información que este pudiera arrojar y así poder detectar estándares o definir estadísticas. Mediante el Diseño de Datamart se determinó los indicadores que son serían de utilidad para ser analizados y que son las calificaciones obtenidas en los trabajos de experiencia recepcional, los cuerpos académicos que participan para la elaboración de trabajos recepcionales, las modalidades seleccionadas por los alumnos y toda la información de los Trabajos como con los creadores y áreas a la que pertenecen, y poder determinar los estándares estos permitirán conocer por ejemplo las áreas generales mas seleccionadas por los alumnos y con ello poder determinar en qué áreas se está realizando mas generación de conocimientos, las modalidades seleccionadas por los alumnos permitiendo conocer que es lo que los estudiantes y maestros realizan, es decir, si solo realizan trabajos de investigación o llegan a desarrollar alguna solución práctica ante una situación, también el comportamiento de calificaciones de acuerdo a modalidades y cuerpos académicos, el funcionamiento de los las líneas de investigación de los cuerpos académicos, etc. Y entre otras más que son definidas por los modelados de los indicadores, y que mediante cada una de sus dimensiones se puede llegar a obtener diversos reportes reflejando el comportamiento de cada uno de los indicadores respecto a las variables que tienen definidas Queda claro que el adoptar una tecnología de Datamart, es importante en las organizaciones que manejan grandes cantidades de información y este es el caso de la Facultad de Contaduría y Administración, donde cada semestre se 109 genera grandes cantidades de información y que en ocasiones resulta difícil pensar que obtener esa información es una tarea complicada. Es por esta razón, que en desarrollo de este trabajo se aborda el tema de Datamart, desde el concepto, que aborda términos muy importantes y que son fáciles de comprender y desde ese momento se comienza a tener una idea de lo que abarca un Datamart, y así se describen los términos que son respaldados por los que son denominados los precursores del uso de Datamarts y se toma la idea central del Datamart como parte de un ambiente OLAP, pero que este puede desarrollarse de forma individual abarcando un área en particular sin afectar a toda la organización. . Por otra parte se destacan cada uno de los elementos que conforman al Datamart permitiendo con ello poder, identificar los requerimientos para su implementación. Y darse una idea de que cada uno de los elementos que lo conforman son de gran importancia y sobre todo, que integrados logran que un Datamart sea una herramienta de negocios eficiente y sobre todo conocer el análisis que hace de la información, y con ello se destaca lo eficaz y eficiente que llegar a ser en la obtención de información mediante la explotación mediante herramientas OLAP, las cuales permitirán arrojar los resultados necesarios y solicitados por los usuarios finales. Para que esas herramientas pueden a llegar a cumplir su objetivo, es importante la etapa de diseño, que es la parte que abarca esta investigación, de ella depende el éxito del diseño de un Datamart, ya que permite identificar las fuentes de datos que van a proveer al Datamart sobre todo conocer la información que es de relevancia y no llevar al Datamart información basura, que solo generaría que este sea más robusto sin necesidad de que lo sea. Además de esto poder diseñar el modelado multidimensional, para poder realizar el análisis de la información del Datamart propuesto. 110 Dentro de las etapas abarcadas en este trabajo, la etapa de análisis permitió poder dar idea de la propuesta de Diseño del Datamart, comenzando por mostrar los beneficios de realizar el diseño de un Datamart para el área de Experiencia Recepcional en especifico en el sistema de asignación de sinodales, el cual se describió de manera general cada uno de los módulos que lo conforman. En esta etapa también se tomo la etapa de análisis para comenzar a diseñar el Datamart, se analizo la fuente de datos actual dentro del sistema para poder identificar que datos se maneja dentro de la base de datos actual del sistema, analizando esta se identificaron que algunos campos podrían ser necesarios para poder obtener mejores resultados con el diseño de Datamart, una vez hecho esto se realizo el modelo relacional, el cual muestra las entidades que conforman la base de datos actual y los atributos de cada una de ellas, los cuales fueron descritos con detenimiento por cada una de las entidades. Y fueron concluidas todas las actividades marcadas dentro de la eta de análisis, y con ello se obtuvo los requerimientos necesarios para el inicio de la siguiente etapa que sería el Diseño del Datamart. Dentro de la etapa de Diseño, es importante el modelado de los datos que contendrá el Datamart, por esta razón una vez identificados los datos fuentes del Datamart, que es importante distinguir que para este caso se realizo una modificación a la base de datos actual en donde se solicitaron agregar campos los cuales permitieran realizar un mejor análisis dentro del Datamart, una vez identificado estos campos de información, se determinaron las actividades a desarrollarse dentro de esta etapa. Se desarrollaron las actividades identificando las entidades que estarían dentro del Datamart, en donde se hizo la selección de las entidades que fueran de utilidad y sus atributos, ya que no todos son indispensables para el análisis que se pretende identificar dentro del Datamart. Una vez que se seleccionaron de permitió 111 comenzar con el modela multidimensional de los datos en donde se ocupo el esquema en copo de nieve la cual fue la más práctica para el diseño del Datamart. Para poder realizar el modelado se identificaron las tablas de hechos y dimensiones, las cuales se describieron y mostraron los atributos que serian necesarios para el funcionamiento del Datamart. Una vez hecho esto de comenzó a realizar el diseño del esquema de copo de nieve, se utilizo una herramienta para el diseño de modelos para base de datos. Esto se realizo permitiendo identificar cuatro indicadores que fueron: trabajos recepcionales, calificaciones, modalidad y cuerpos académicos, que son los indicadores que permitirán analizar y ver los comportamiento que poseen, y así poder analizar el historial almacenado en el Datamart, y con ellos poder realizar toma de decisiones que permitan un mejor desempeño dentro del área de Experiencia Recepcional, ya sea los alumnos, maestros que participan como asesores de los trabajos recepcionales y los que participan como sinodales en los exámenes profesionales, y el funcionamiento de los cuerpos académicos mostrando que proyectos ha generado y que conocimiento han generado. Con esto se busco comenzar una parte de la creación de un Datamart, buscando que sea la base para que comience el interés dentro de la Facultad de Contaduría y Administración, en buscar nuevas herramientas que permita que la información que fluye semestre a semestre sea mucho mejor manejada y que esta pueda ser no solo una fuente para la toma de decisiones si no que sea un almacén de información de las generaciones que surgen dentro de la Facultad, que pueda arrojar información de relevancia sin tener que buscar en cada una de las fuentes de datos disponibles dentro de la Facultad. Este trabajo es una buena base, para aquellos que deseen continuar con un aporte de relevancia, y pueda demostrarse que la integración de un Datamart, 112 puede eficientar de manera radical a la información que la organización genera día a día. Por último, este trabajo fue una gran experiencia en la que como autor pude desarrollar y entender mucho mejor el proceso de toma de decisiones y su importancia hoy en día dentro de las organizaciones, y que ahora no solo basta con saber que se tienen bases de datos que respaldan los sistemas de información con los que se cuenta, si no que están surgiendo mejores herramientas que permiten actualizar la tecnología con la que una organización desarrolla sus actividades o la toma de decisiones, y con este trabajo queda claro que el Datamart, es una herramienta que cumple con el objetivo que buscan ahora las organizaciones. Y sería muy importante buscar en un futuro poder terminar esta investigación llevando a la práctica la implementación de un Datamart dentro de la Facultad de Contaduría y Administración en su área de Experiencia Recepcional, y por qué no pensar que se puedan integrar un mayor número de áreas, y con ello poder decir, que se cuenta con la herramienta de Datawarehouse dentro de la Facultad de Contaduría y Administración. 113 FUENTES DE INFORMACIÓN Alva Matteucci, Juan Mario Datawarehouse. Recuperado el (2001). Revista de Derecho Informático: 13 de Julio de 2009, de http://www.alfa- redi.org/rdi-articulo.shtml?x=665 Bustamante, Juan Carlos (2005) Datawarehousing y su aplicación como apoyo a la toma de decisiones en la Espol. Recuperado el 28 de Abril de 2009, de http://www.dspace.espol.edu.ec/bitstream/123456789/18/1/1.pdf Curto, J. (12 de Enero, 2009). CIF vs MD : Dos enfoques clásicos en el diseño de la arquitectura de un Data Warehouse. Recuperado el 12 de abril de 2009 de http://bibusinessintelligence.blogspot.com/2009/01/cif-vs-md-dos-enfoques-clsicosen-el.html Dataprix (2007). Conceptos y funcionalidades básicas de Data Warehouse. Recuperado el 24 de Abril, de www.dataprix.com/book/export/html/76 Exforsys Inc (2009). Tutorial 4: Diseño de la base de datos Kimball Vs. Inmon. Recuperado el 10 de abril de 2009, de http://www.exforsys.com/tutorials/msas/data-warehouse-design-kimball-vs inmon.html ETL-Tools (2009). Esquemas multidimensionales. Recuperado el 6 de Junio de 2009, de http://etl-tools.info/es/bi/almacendedatos_esquema-constelacion.htm Faktos (2008). Soluciones Business Intelligence (BI) Recuperado el 28 de Mayo de 2009, de http://www.faktos.com/soluciones.php 114 García, Sorey (2009) Inteligencia de Negocios. 15 de Mayo de 2009, de http://www.slideshare.net/soreygarcia/inteligencia-de-negocios-1092940 González Rosas, Leopoldo(2005) Zombi: una arquitectura para el análisis de información que integra procesamiento analítico en línea con minería de datos. Universidad de las Américas Puebla. Recuperado el 3 de Abril de 2009, de http://catarina.udlap.mx/u_dl_a/tales/documentos/msp/gonzalez_r_l/apendiceB.pdf Guillermo A Cuéllar M (2008). Data warehouse, aspectos técnicos, características, usos, beneficios, componentes, herramientas OLAP, Universidad del Cauca, Santo Domingo. Recuperado el 27 de Junio de 2009, de http://fccea.unicauca.edu.co/old/datawarehouse.htm Hernández Orallo, José. Curso de Datawarehouse. Departamento de Sistemas Informáticos y Computación, Universidad Politécnica de Valencia. Recuperado el 15 de Abril de 2009, de http://users.dsic.upv.es/~jorallo/cursoDWDM/dwdm-I.pdf Hurtado Larrain, Carlos (2005). Repositorios (Datawarehouse) OLAP. Departamento de Ciencias de la Computación, Universidad de Chile. Recuperado el 25 de Marzo de 2009, de http://www.dcc.uchile.cl/~churtado/olapTulua.pdf Méndez Duque, D,J. (2006). Curso de Base de Datos. Programa Universidad Virtual. Universidad Nacional de Colombia. Recuperado el 5 de Mayo de 2009, de http://www.virtual.unal.edu.co/cursos/sedes/manizales/4060029/lecciones/cap81.html Murrillo, Alfaro Félix (2003) Manual de Construcción de un Datawarehouse. Recuperado el 8 de Junio de 2009, de http://www.ongei.gob.pe/publica/metodologias/Lib5084/151.HTM 115 Nocturnabsas.com (2009). Articulo Datawarehouse. Recuperado el 5 de Julio de 2009, de http://www.nocturnabsas.com.ar/forum/informes/228221- datawarehouse.html Norberto Mazón, José (2007) Desarrollo de modelos multidimensionales de almacenes de datos basado en MDA: del análisis de requisitos al modelo lógico. Recuperado el 20 de Junio de 2009, de http://www.sistedes.es/sistedes/pdf/2007/dsdm-07-mazon-almacenes.pdf RealITech (2001). Data Warehousing. Recuperado el 17 de Junio de 2009, de http://www.sqlmax.com/dataw1.asp Rozic, S., Coronel (2004). Base de datos y su aplicación con SQL. Buenos Aires: MP Ediciones. Sinnexus (2007). Bases de datos OLTP y OLAP. Recuperado el 5 de Mayo de 2009, de http://www.sinnexus.com/business_intelligence/olap_vs_oltp.aspx UNSL (2006). Universidad Nacional de San Luis. Aprendizaje de árboles de decisión. Recuperado el 15 de Julio de 2009, de http://www.dirinfo.unsl.edu.ar/~aamd/Teorias/dec_tree.pdf Victoria, Definicion ABC (2009) Articulo definición de MySqL. Recuperado el 7 de Mayo de 2009, de http://www.definicionabc.com/tecnologia/mysql.php Willian, H.I., Chuck, K. (1994) Developing a Data Warehouse (Hardcover) by William H. Inmon, Chuck Kelley. Wolff, Carmen Gloria (2008) Modelamiento dimensional. Recuperado el 3 de Julio de 2009, de http://www.inf.udec.cl/~revista/ediciones/edicion4/modmulti.PDF 116 GLOSARIO Toma de Decisiones: proceso mediante el cual se realiza una elección entre las alternativas o formas para resolver diferentes situaciones de la vida, estas se pueden presentar en diferentes contextos: a nivel laboral, familiar, sentimental, empresarial, etc., es decir, en todo momento se toman decisiones, la diferencia entre cada una de estas es el proceso o la forma en la cual se llega a ellas. La toma de decisiones consiste, básicamente, en elegir una alternativa entre las disponibles, a los efectos de resolver un problema actual o potencial, (aún cuando no se evidencie un conflicto latente). OLAP: es la sigla en inglés de Procesamiento de Transacciones En Línea (OnLine Transaction Processing) es un tipo de sistemas que facilitan y administran aplicaciones transaccionales, usualmente para entrada de datos y recuperación y procesamiento de transacciones (gestor transaccional). Los paquetes de software para OLTP se basan en la arquitectura cliente-servidor ya que suelen ser utilizados por empresas con una red informática distribuida. OLAP: procesamiento analítico en línea (On-Line Analytical Processing). Es una solución utilizada en el campo de la llamada Inteligencia empresarial (o Business Intelligence) cuyo objetivo es agilizar la consulta de grandes cantidades de datos. Para ello utiliza estructuras multidimensionales (o Cubos OLAP) que contienen datos resumidos de grandes Bases de datos o Sistemas Transaccionales (OLTP). Se usa en informes de negocios de ventas, marketing, informes de dirección, minería de datos y áreas similares. 117 DSS: es un sistema de información basado en un computador interactivo, flexible y adaptable, especialmente desarrollado para apoyar la solución de un problema de gestión no estructurado para mejorar la toma de decisiones. Utiliza datos, proporciona una interfaz amigable y permite la toma de decisiones en el propio análisis de la situación Transacción: en un sistema de gestión de bases de datos (SGBD), es un conjunto de órdenes que se ejecutan formando una unidad de trabajo, es decir, en forma indivisible o atómica. ERP: son sistemas de información gerenciales que integran y manejan muchos de los negocios asociados con las operaciones de producción y de los aspectos de distribución de una compañía comprometida en la producción de bienes o servicios. CRM: es parte de una estrategia de negocio centrada en el cliente. Una parte fundamental de su idea es, precisamente, la de recopilar la mayor cantidad de información posible sobre los clientes, para poder dar valor a la oferta. La empresa debe trabajar para conocer las necesidades de los mismos y así poder adelantar una oferta y mejorar la calidad en la atención. DataMart: es una versión especial de almacén de datos (data warehouse). Son subconjuntos de datos con el propósito de ayudar a que un área específica dentro del negocio pueda tomar mejores decisiones. Los datos existentes en este contexto pueden ser agrupados, explorados y propagados de múltiples formas para que diversos grupos de usuarios realicen la explotación de los mismos de la forma más conveniente según sus necesidades. 118 ÍNDICE DE FIGURAS FIGURA 2.1 Niveles de Información de un Datamart ........................................... 31 FIGURA 2.2 Niveles de la Arquitectura de un Datamart ...................................... 32 FIGURA 2.3 Componentes de un Datamart ......................................................... 35 FIGURA 2.4 Proceso de extracción, transformación y carga ............................... 38 FIGURA 3.1 Ejemplo de Diagrama Entidad Relación (ER) ............................... 54 FIGURA 3.2 Los conceptos de dimensión y hechos ............................................. 57 FIGURA 3.3 Esquemas para representar modelos multidimensionales................ 58 FIGURA 3.4 Modelo de estrella con 3 dimensiones y una tabla de hechos .......... 59 FIGURA 3.5 Modelo de copo de nieve .................................................................. 60 FIGURA 3.6 Esquema de constelaciones ............................................................. 62 FIGURA 3.7 Operaciones sobre cubos: especializar y generalizar ....................... 63 FIGURA 3.8 Operaciones sobre cubos: corte y corte de cubos ............................ 64 FIGURA 3.9 Operaciones sobre cubos: filtrar y pivotear ....................................... 65 FIGURA 4.1 Etapas de Creación de un Datamart ................................................. 77 FIGURA 4.2 Alcance de la propuesta para el Datamart ........................................ 79 FIGURA 4.3 Modelo Físico de la Base de Datos del Sistema de Asignación ....... 91 FIGURA 5.1 Modelo Lógico Modificado ................................................................ 94 FIGURA 5.2 Esquema Copo de Nieve de Trabajos Recepcionales .................... 104 FIGURA 5.3 Esquema Copo de Nieve de Calificaciones ................................... 105 FIGURA 5.4 Esquema Copo de Nieve de Modalidad.......................................... 106 FIGURA 5.5 Esquema Copo de Nieve de Cuerpo Académico ............................ 107 119 ÍNDICE DE TABLAS TABLA 1.1 Cuadro comparativo entre ambientes OLTP y OLAP.......................... 19 TABLA 4.1 Descripción de Actividades ................................................................. 79 TABLA 4.2 Actividades de la Etapa de Análisis .................................................... 82 TABLA 4.3 Descripción de las Entidades del Sistema de Asignación ................... 84 TABLA 4.4 Atributos de la Entidad Academia ....................................................... 84 TABLA 4.5 Atributos de la Entidad Alumno ........................................................... 85 TABLA 4.6 Atributos de la Entidad Área Académica ............................................. 86 TABLA 4.7 Atributos de la Entidad Área Trabajo Recepcional .............................. 86 TABLA 4.8 Atributos de la Entidad Catalogo de Profesores ................................. 86 TABLA 4.9 Atributos de la Entidad Contenido ....................................................... 87 TABLA 4.10 Atributos de la Entidad Sesiones ...................................................... 88 TABLA 4.11 Atributos de la Entidad Materias ....................................................... 88 TABLA 4.12 Atributos de la Entidad Cuerpo Académico ....................................... 88 TABLA 4.13 Atributos de la Entidad Cuerpo Académico y Profesores .................. 89 TABLA 4.14 Atributos de la Entidad Profesores .................................................... 89 TABLA 4.15 Atributos de la Entidad Sinodal Alumno ............................................ 89 TABLA 4.16 Atributos de la Entidad Trabajo Recepcional .................................... 90 TABLA 5.1 Actividades de la Etapa de Diseño...................................................... 93 TABLA 5.2 Tablas Dimensión para el Datamart .................................................... 95 TABLA 5.3 Tablas Hechos para el Datamart......................................................... 96 TABLA 5.4 Atributos de la Tabla Dimensión Carrera ............................................ 96 TABLA 5.5 Atributos de la Tabla Dimensión Área ................................................. 97 TABLA 5.6 Atributos de la Tabla Dimensión Tiempo ............................................ 97 TABLA 5.7 Atributos de la Tabla Dimensión Modalidad ........................................ 97 TABLA 5.8 Atributos de la Tabla Dimensión Profesor ........................................... 98 TABLA 5.9 Atributos de la Tabla Dimensión Cuerpo Académico .......................... 98 120 TABLA 5.10 Atributos de la Tabla Dimensión Calificaciones ................................ 98 TABLA 5.11 Atributos de la Tabla Dimensión Estado ........................................... 98 TABLA 5.12 Atributos de la Tabla Dimensión Alumno .......................................... 99 TABLA 5.13 Atributos de la Tabla Dimensión Trabajo Recepcional...................... 99 TABLA 5.14 Atributos de la Tabla Dimensión Academia ...................................... 99 TABLA 5.15 Atributos de la Tabla Dimensión Área Académica .......................... 100 TABLA 5.16 Atributos de la Tabla Hecho de Trabajo Recepcional ..................... 100 TABLA 5.17 Atributos de la Tabla Hecho de Calificaciones ................................ 100 TABLA 5.18 Atributos de la Tabla Hecho de Modalidad ..................................... 101 TABLA 5.19 Atributos de la Tabla Hecho de Cuerpo Académico........................ 101 121