Beatriz Santiago Herrera - Repositorio Institucional de la

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