Embed Size (px)
Citation preview
USO DE TRIGGERS Y SNAPSHOTS COMO TÉCNICA INCREMENTAL EN EL PROCESO DE EXTRACCIÓN, TRANSFORMACIÓN Y TRANSFERENCIA
DE DATOS (ETT) EN UN DATA WAREHOUSE.
TESIS
MAESTRÍA EN CIENCIAS EN TECNOLOGÍA INFORMÁTICA
INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY CAMPUS MONTERREY
DIVISIÓN DE GRADUADOS EN ELECTRÓNICA, COMPUTACIÓN, INFORMÁTICA Y COMUNICACIONES
POR MA. ELIZABETH ALCALÁ FLORES
JUNIO 2003
INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY
DIVISIÓN DE ELECTRÓNICA, COMPUTACIÓN, INFORMACIÓN Y COMUNICACIONES
PROGRAMAS DE GRADUADOS EN ELECTRÓNICA, COMPUTACIÓN, INFORMACIÓN Y COMUNICACIONES
Los miembros del comité de tesis recomendamos que la presente tesis de Ma. Elizabeth Alcalá Flores sea aceptada como requisi to parcial para obtener el grado académico de Maestra en Ciencias en Tecnología Informática.
Comité de tesis:
Carmen Isabel Reyes Peraza, MC
Asesor
Juan Carlos Lavariega Jarquín, PhD.Sinodal
María Cristina Hernández Rodríguez, MC.Sinodal
_________________________________________ David Alejandro Garza Salazar, PhD.
Director del Programa de Graduados en Electrónica, Computación, Información y Comunicaciones.
JUNIO 2003
USO DE TRIGGERS Y SNAPSHOTS COMO TÉCNICA INCREMENTAL EN EL PROCESO DE EXTRACCIÓN, TRANSFORMACIÓN Y TRANSFERENCIA
DE DATOS (ETT) EN UN DATA WAREHOUSE.
POR:
MA. ELIZABETH ALCALÁ FLORES
TESIS
Presentada al Programa de Graduados en Electrónica, Computación, Información y Comunicaciones.
Este trabajo es requisito parcial para obtener el título de Maestro en Ciencias en Tecnología Informática
INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY
JUNIO 2003
iv
DEDICATORIA
A mis padres, por haberme dado la vida, por su inmenso amor, porque los quiero mucho y por ser mi mayor bendición.
A Marisol, a Norma, a Nora y a Thelma, por tantos momentos que hemos compartido y que sé son inolvidables para las cinco, por
ser mis hermanas.
A Horacio, por tener un lugar especial en mi corazón, por ser el ADMV y por contar con él en estos momentos.
A mis sobrinos, Isis Vianney y Héctor Josué por siempre tener una sonrisa para mí.
A Oraldo y a Susy, por ser mis mejores amigos y por los ánimos que siempre me dieron para terminar este trabajo.
Dedico especialmente este trabajo a Dios, porque gracias a él tengo a tantas personas que me quieren a mi lado.
v
AGRADECIMIENTOS
A la Lic. Carmen Isabel Reyes Peraza por su apoyo, sus consejos, su paciencia, su tiempo y sobre todo por haber aceptado ser parte de
este trabajo como asesora.
A la Ing. María Cristina Hernández Rodríguez y al Dr. Juan Carlos Lavariega Jarquín por las valiosas recomendaciones y observaciones
que me hicieron para realizar un mejor trabajo.
A mis padres, por esa confianza que tienen en mí y por el apoyo incondicional que siempre me han demostrado.
A mis hermanas, por hacerme sentir cerca cuando estoy lejos y por creer en mí.
A Horacio (ADMV) por estar conmigo cuando lo necesito, pero sobre todo por su amor incondicional.
A todas la personas que de una u otra forma me apoyaron para la realización de esta tesis.
vi
RESUMEN
En la actualidad, nuestra sociedad ha colocado a la información en un lugar de vital importancia, particularmente en las organizaciones ya que éstas necesitan tener un buen control y manejo de los datos para poder obtener mejores resultados en sus acciones. Como parte primordial para esto, es necesario contar con sistemas de información apropiados, dentro de ellos se encuentra el Data Warehousing.
Un sistema Data Warehousing cuenta con varios procesos para su funcionamiento,
uno de ellos y quizá el más importante es aquel que se encarga de la extracción, la transformación y la transferencia de los datos del sistema operacional fuente hacia el Data Warehouse, mismo que es conocido como el proceso ETT. Este proceso es uno de los que más tiempo y recursos demanda en la implementación de un Data Warehouse, y a pesar de ello existe una limitada investigación y documentación en torno a él.
Para llevar a cabo el desarrollo del proceso ETT existen dos tipos de técnicas que se
pueden emplear, las secuenciales y las incrementales. Las secuenciales se caracterizan por extraer, transformar y transferir todos los datos del sistema operacional fuente que son requeridos en el Data Warehouse, en cambio las incrementales se concentran en extraer, transformar y transferir únicamente las actualizaciones que surgieron en el sistema operacional fuente.
La tesis que se presenta proporciona un estudio, con información necesaria, para
llevar a cabo el proceso ETT con la técnica secuencial a través de archivos de datos y con la técnica incremental utilizando una combinación de Triggers y Snapshots.
Además ofrece una comparación entre dichas técnicas para determinar en que
medida es mejor una que otra y cuáles son los beneficios que cada una ofrece en el proceso de extracción, transformación y transferencia de datos desde un sistema operacional fuente hacia el Data Warehouse.
vii
TABLA DE CONTENIDO
Dedicatoria ...................................................................................iv
Agradecimientos..............................................................................v
Resumen .......................................................................................vi Tabla de contenido ........................................................................vii
Lista de Figuras.............................................................................. x
Lista de Tablas .............................................................................xii
CAPÍTULO 1. Introducción ................................................................. 1
1.1 Definición del problema....................................................................2 1.2 Objetivos .....................................................................................2
1.2.1 Objetivos Específicos............................................................................2 1.3 Justificación..................................................................................3 1.4 Hipótesis ......................................................................................3 1.5 Restricciones .................................................................................4 1.6 Aportaciones de la investigación..........................................................4 1.7 Organización del Documento ..............................................................5
CAPÍTULO 2. Marco Conceptual.......................................................... 6
2.1 Definiciones del Data Warehouse .........................................................6
2.2 Características del Data Warehouse ......................................................8 2.3 Ventajas del Uso del Data Warehouse....................................................9 2.4 Desventajas del Uso del Data Warehouse.............................................. 10 2.5 Procesos que conforman la operación de un Data Warehouse...................... 10
2.6 Proceso de Extracción, Transformación y Transferencia (ETT) de datos.......... 12 2.6.1 Extracción ....................................................................................... 13 2.6.2 Transformación................................................................................. 13 2.6.3 Transferencia ................................................................................... 13 2.6.4 Problemas en el proceso ETT ................................................................ 14
CAPÍTULO 3. Técnicas Empleadas en el Proceso de Extracción, Transformación y Transferencia de Datos (ETT)..................16
viii
3.1 Clasificación de las técnicas empleadas en el proceso ETT......................... 16 3.2 Técnicas Secuenciales .................................................................... 16
3.2.1 Archivos de datos. ............................................................................. 17 3.2.2 Queries distribuidos ........................................................................... 17
3.3 Técnicas Incrementales................................................................... 18 3.3.1 Snapshots ........................................................................................ 19 3.3.2 Time Stamp ..................................................................................... 20 3.3.3 Particionamiento............................................................................... 21 3.3.4 Triggers ......................................................................................... 21 3.3.5 Snapshots diferenciales ....................................................................... 22 3.3.6 Habilitación de Consultas (Queryable) ..................................................... 22 3.3.7 Monitoreo de registros ........................................................................ 22
3.4 Ejemplos para el uso de las técnicas secuenciales e incrementales ............... 23 3.4.1 Con archivos de datos. ........................................................................ 24 3.4.2 Con queries distribuidos ...................................................................... 26 3.4.3 Con Snapshots .................................................................................. 27 3.4.4 Con Triggers..................................................................................... 27
CAPÍTULO 4. Definición del Caso de Estudio: El Data Warehouse del Área de Escolar del Tecnológico de Monterrey y su Proceso ETT ....29
4.1 Los servicios escolares del Tecnológico de Monterrey en el Data Warehouse .... 29 4.2 Proceso ETT que se siguió en el caso de estudio ..................................... 32
4.2.1 Extracción y Transformación................................................................. 37 4.2.2 Transferencia ................................................................................... 39
4.3 Pruebas realizadas ........................................................................ 40
CAPÍTULO 5. Combinación de Triggers y Snapshots para el proceso ETT....42
5.1 Explicación general del Proceso ETT que se propone con una combinación de Triggers y Snapshots. ..................................................................... 42
5.2 Cambios estructurales al Data Warehouse del área de escolar del Tecnológico de Monterrey................................................................ 44
5.3 Desarrollo de Triggers, para la extracción local ...................................... 46 5.3.1 Validación ....................................................................................... 46 5.3.2 Extracción - Actualización.................................................................... 48 5.3.3 Manejo de Excepciones ....................................................................... 51
5.4 Desarrollo de Trigger para la transferencia de los datos a la tabla concentradora. ............................................................................ 51 5.4.1 String de Conexíón............................................................................. 52 5.4.2 DbLink… .......................................................................................... 52
5.5 Desarrollo de Snapshot ................................................................... 53
ix
5.5.1 Creación del Snapshot......................................................................... 53 5.5.2 Creación del Snapshot Log.................................................................... 53
5.6 Pruebas realizadas ........................................................................ 54
CAPÍTULO 6. Resultados Obtenidos....................................................56
6.1 Proceso ETT utilizando archivos de datos.............................................. 56 6.1.1 Ventajas. ........................................................................................ 57 6.1.2 Desventajas ..................................................................................... 57
6.2 Proceso ETT utilizando Snapshots y Triggers .......................................... 58 6.2.1 Ventajas. ........................................................................................ 60 6.2.2 Desventajas ..................................................................................... 60
6.3 Comparación de las dos técnicas del proceso ETT realizadas....................... 61
CAPÍTULO 7. Conclusiones y Trabajos Futuros .....................................63
7.1 Conclusiones ............................................................................... 63 7.2 Trabajos futuros ........................................................................... 65
Bibliografía ..................................................................................66
Anexos ........................................................................................68
A.1 Diccionario de datos de la tabla ST4ORGN ............................................ 68 A.2 Diccionario de datos (modelo de datos del sistema operacional que se utilizó
para crear la tabla Profesor del Data Warehouse).................................... 68 A.3 Indicaciones para extraer los datos y manejo de errores ........................... 73
A.4 Código del programa para la extracción y transformación de los datos del sistema operacional del Tecnológico de Monterrey. ................................. 77
A.5 Código del programa de transferencia de datos en el Data Warehouse........... 79 A.6 Trigger SP1PERS_UPDATE................................................................. 84 A.7 Trigger SI1FACD_UPDATE................................................................. 84
A.8 Trigger SIBINST_UPDATE.................................................................. 85 A.9 Trigger SP1IDEN_UPDATE................................................................. 86 A.10 Trigger SO1DEGR_UPDATE................................................................ 87 A.11 Trigger DWH_ESCOLAR_UPDATE......................................................... 89
Vita… . .........................................................................................91
x
LISTA DE FIGURAS
Figura 2-1 Procesos en un Data Warehouse .................................................... 11
Figura 2-2 Operaciones involucradas en el proceso ETT...................................... 14
Figura 3-1 Proceso ETT con archivo de datos .................................................. 17
Figura 3-2 Proceso ETT con Snapshot ........................................................... 20
Figura 3-3 Estructura de las tablas de unidades organizacionales .......................... 23
Figura 4-1 Sistemas operacionales relacionados con el Modelo de datos del Data Warehouse del Área de Escolar .................................................................. 30
Figura 4-2 Modelo de datos de la base de datos operacional utilizado para la generación de la tabla Profesor del Data Warehouse....................................................... 31
Figura 4-3 Tabla Profesor del Data Warehouse del área de escolar. ....................... 33
Figura 4-4 Ejemplo del contenido del archivo de datos de Profesores..................... 38
Figura 5-1 Representación gráfica de lo que se propone para llevar a cabo el proceso ETT con una combinación del uso de Snapshots y Triggers .................................. 43
Figura 5-2 Tabla Profesor del Data Warehouse ................................................ 45
Figura 5-3 Ejemplo de la primera validación que se hace en los triggers creados para la actualización de la tabla Profesor. .............................................................. 47
Figura 5-4 Ejemplo de la segunda validación que se hace en uno de los triggers creados para la actualización de la tabla Profesor...................................................... 47
Figura 5-5 Campos que actualiza el triggers SP1IDEN_UPDATE en la tabla PROFESOR... 48
Figura 5-6 Campos que actualiza el trigger SP1PERS_UPDATE en la tabla PROFESOR.... 49
Figura 5-7 Campos que actualiza el trigger SI1FACD_UPDATE en la tabla PROFESOR.... 49
Figura 5-8 Campos que actualiza el triggers SIBINST_UPDATE en la tabla PROFESOR.... 49
Figura 5-9 Campos que actualiza el triggers SO1DEGR_UPDATE en la tabla PROFESOR . 50
Figura 5-10 Campos que actualiza el triggers SO1DEGR_UPDATE en la tabla PROFESOR 52
xi
Figura 5-11 Estructura de la tabla MLOG$_DWH_PROFESOR, generada con el Snapshot Log ................................................................................................... 54
xii
LISTA DE TABLAS
Tabla 3-1 Extracción de cambios utilizando time stamp ..................................... 21
Tabla 4-1 Diccionario de datos de la estructura Profesor. ................................... 34
Tabla 4-2 Origen de los datos para la tabla Profesor ......................................... 35
Tabla 4-3 Ejemplo de dónde y cómo obtener los posibles valores para el campo CLAVE_CAMPUS de la tabla Profesor del Data Warehouse ................................... 36
1
CAPÍTULO 1. INTRODUCCIÓ N
El Data Warehouse no es un producto sino un conjunto de procesos, para consolidar y administrar datos de variadas bases de datos fuentes, con el propósito de responder preguntas de negocios, así como tomar decisiones de una manera más rápida y sencilla que antes no era posible.
El Data Warehouse ha evolucionado de tal forma que se ha convertido en una clase
de aplicación popular en los negocios, debido a que intenta responder a la compleja necesidad de obtener información útil, sin sacrificar el rendimiento de las aplicaciones operacionales; es decir, cumple con las necesidades actuales y futuras para el manejo, explotación y administración de la información.
Los procesos principales que conforman la operación de un Data Warehouse son los
siguientes: 1. Obtención de los datos operacionales: origen de los datos. 2. Extracción de los datos: selección sistemática de los datos operacionales que
serán usados para poblar el Data Warehouse. 3. Transformación de los datos: proceso de cambio en los datos operacionales para
lograr los objetivos de orientación a la toma de decisiones del Data Warehouse. 4. Transferencia o carga de los datos: inserción de los datos en el Data Warehouse. 5. Herramientas de acceso al Data Warehouse. Los procesos 2, 3 y 4, conforman lo que se conoce como el proceso de Extracción,
Transformación y Transferencia de datos, desde su origen en los sistemas operacionales hasta su destino en el Data Warehouse, estos tres procesos se identifican mejor como el proceso ETT por sus siglas, es en este proceso en donde se lleva a cabo la extracción y transformación de los datos que son necesarios del sistema operacional fuente y la transferencia de los mismos hacia el Data Warehouse. Este proceso es el que más tiempo y recursos demanda en el proyecto, y en el que se enfoca este trabajo de tesis.
Las técnicas para realizar el proceso ETT pueden clasificarse en dos tipos,
secuenciales que se caracterizan por extraer, transformar y transferir todos los datos del sistema operacional fuente que son requeridos en el Data Warehouse e incrementales que se concentran en extraer, transformar y transferir únicamente las actualizaciones que surgieron en el sistema operacional fuente. Las primeras requieren más inversión de tiempo para lograr su propósito, mientras que las segundas pueden ser más rápidas, siempre y cuando se empleen adecuadamente y se cuente con las capacidades necesarias para realizarlas.
2
1.1 Definición del problema
En la actualidad toda organización requiere un uso adecuado de la información, por lo que la implementación de un Data Warehouse es cada vez más frecuente. Es por ello que resulta necesario contar con documentación que ayude a realizar dicha implementación.
Una de las partes más importantes en un proyecto Data Warehouse es el proceso ETT
encargado de extraer los datos, transformarlos y transferirlos de uno o varios sistemas operacionales fuente al Data Warehouse.
Sin embargo, a pesar de lo anterior, existe una limitada investigación y estudios
sobre este tema, esto conlleva a la elección de una técnica para realizar la extracción, transformación y transferencia de datos sin haber hecho una evaluación previa del rendimiento y/o los beneficios que ésta ofrece.
En otros casos se decide adquirir un software comercial para realizar dichas tareas lo
cual representa una gran inversión económica, que independientemente de que se cuente con los recursos económicos para ello, es un gasto innecesario.
1.2 Objetivos
El objetivo de esta tesis es proporcionar un estudio con información necesaria para utilizar los archivos de datos y una combinación de Triggers y Snapshots como técnicas de extracción, transformación y transferencia de datos en un Data Warehouse. Además de determinar en que medida el uso de la combinación de Snapshots y Triggers es más eficiente y ofrece mejores resultados que el uso de archivos, como técnicas incrementales.
1.2.1 Objetivos Específicos
Los objetivos específicos a cumplir en el trabajo presentado son: ? Realizar el proceso ETT, del Data Warehouse del área de escolar del Tecnológico de
Monterrey, con técnicas incrementales usando una combinación de Triggers y Snapshots, así como archivos de datos para hacer una comparación entre las dos técnicas.
? Definir las ventajas, desventajas y características que ofrecen el uso de la combinación de Triggers y Snapshots y el uso de archivos de datos en el proceso ETT.
? Llevar a cabo la investigación de acción, utilizando la base de datos de Escolar del Instituto Tecnológico y de Estudios Superiores de Monterrey, Campus Monterrey.
3
? Desarrollar los programas computacionales en lenguaje Pro*C para extraer, transformar y transferir los datos de los sistemas operacionales fuente a una de las entidades del área de escolar del Data Warehouse del Tecnológico de Monterrey.
? Crear los Triggers y Snapshots necesarios para extraer, transformar y transferir los datos del sistema operacional al Data Warehouse de manera incremental, para una de las tablas del Data Warehouse del Tecnológico de Monterrey.
1.3 Justificación
Es evidente que estamos en la era de la información, es decir, todo gira en torno a ésta; ello implica que se debe tener el mejor manejo de la misma para obtener beneficios óptimos.
El proceso de extracción, transformación y transferencia de datos en un proyecto
Data Warehouse es de mucha importancia debido, precisamente, a que los datos son la materia prima principal en dicho proyecto, tener los datos correctos en el momento correcto en el Data Warehouse es lo que se requiere para que la toma de decisiones sea eficiente. Este proceso aún no se realiza mediante una técnica estándar y son pocos los estudios que se han hecho en torno al tema, a pesar de que éste es una parte importante en el proyecto Data Warehouse [Burleson, 1997].
Con base en el señalamiento de Burleson sobre la escasa existencia de estudios que
ayuden en el desarrollo del proceso ETT, y la propia experiencia al trabajar con dicho proceso de un Data Warehouse, se manifestó la inquietud e interés por realizar un estudio sobre las técnicas incrementales usadas en el proceso mencionado, tomando en cuenta principalmente como punto de comparación una técnica con uso de la combinación de Triggers y Snapshots y una técnica con el uso de archivos de datos. Con lo anterior se pretende conocer las características, ventajas y desventajas que cada una de las técnicas analizadas puede ofrecer, además de cómo pueden ser utilizadas en un Proyecto Data Warehosue.
1.4 Hipótesis
El uso de una combinación de Snapshots y Triggers como técnica incremental en el proceso (ETT) de extracción, transformación y transferencia de datos de los sistemas operacionales fuente al Data Warehouse, es mejor en cuanto a tiempo de procesamiento en comparación con el uso de los archivos de datos, en un esquema de múltiples bases de datos.
4
1.5 Restricciones
La tesis que se presenta considera algunas restricciones, debido a que el proceso de ETT en un proyecto Data Warehouse es extenso y su desarrollo depende de las capacidades que los sistemas operacionales y el Data Warehouse tengan. Así pues, las restricciones que será preciso tener en cuenta son:
? Únicamente se realizará el estudio del proceso ETT y las técnicas para llevarlo a
cabo en una parte de un proyecto Data Warehouse. ? En este documento no se analizarán todas las técnicas existentes de extracción,
transformación y transferencia de datos. ? La comparación de dos técnicas será únicamente entre el uso de archivos de datos
y uso de Snapshots en combinación con el uso de Triggers. ? La investigación de acción se reduce a una parte del Data Warehouse que se está
implementando para el área de Servicios Escolares en el Instituto Tecnológico y de Estudios Superiores de Monterrey, Campus Monterrey.
? La base de datos que funge como sistema operacional fuente en el Data Warehouse mencionado anteriormente, se encuentra en plataforma Oracle y cuenta con las siguientes características. o Oracle8 Enterprise Edition Release 8.0.6.3.0 o PL/SQL Release 8.0.6.3.0
? La base de datos en el Data Warehouse que se utilizará también está en plataforma Oracle, pero con las siguientes características. o Oracle8 Enterprise Edition Release 8.0.6.0.0 o PL/SQL Release 8.0.6.0.0
1.6 Aportaciones de la investigación
Con la culminación de esta tesis se pretende generar las siguientes aportaciones: 1. Obtener una técnica incremental que sea una solución factible de implementar
en el proceso ETT, para llevar a cabo la extracción, transformación y transferencia de datos de una base de datos operacional a un Data Warehouse, a través de una combinación que haga uso de Snapshots y Triggers.
2. La técnica incremental que se proponga con el uso de una combinación de Snapshots y Triggers para la plataforma Oracle sirva como base para dar solución en otras plataformas.
3. Hacer la comparación entre el proceso ETT utilizando archivos de datos y el que se propone utilizando una combinación de Snapshots y Triggers.
4. Los encargados del Data Warehouse en el Tecnológico de Monterrey podrán contar con un estudio sobre la extracción, transformación y transferencia de datos de una base de datos operacional a un Data Warahouse usando la técnica propuesta, que fue realizado exclusivamente para el proyecto de Data Warehouse del área de escolar del Tecnológico de Monterrey.
5
1.7 Organización del Documento
El presente documento de tesis, está estructurado con siete capítulos, el primero de ellos constituye la parte introductoria a todo el documento, enunciando el planteamiento del problema, los propósitos y justificación de este estudio, así como las hipótesis, restricciones y aportaciones.
En el capítulo dos se incluye una breve introducción de lo qué es el Data Warehouse,
diferentes definiciones, características, ventajas y desventajas que ofrece un Data Warehouse, así como la descripción del proceso de Extracción, Transformación y Transferencia (ETT) de datos y los problemas que éste puede presentar en un proyecto de Data Warehouse.
La clasificación y descripción de las técnicas empleadas en el proceso ETT y algunos
ejemplos de ellas forman el capítulo tres. El capítulo cuatro trata sobre la definición, documentación técnica y de ejecución
del caso de estudio, como lo es: las bases de datos involucradas y la forma en que se realiza el proceso ETT actualmente en el Data Warehouse del Tecnológico de Monterrey.
En el capítulo cinco se describe el proceso ETT que se llevo a cabo con el uso de la
técnica incremental propuesta, es decir, usando la combinación de Snapshots y Triggers. Los resultados obtenidos con la implementación de la técnica usando la combinación
de Triggers y Snpashots y de la técnica usando archivos de datos en el proceso ETT, así como la comparación de los resultados de ambas técnicas, están concentrados en el capítulo seis.
Por último, en el capítulo siete se plasman las conclusiones generales que se
obtuvieron de la realización del trabajo de tesis y el planteamiento de trabajos futuros que se pudieran derivar del trabajo presentado.
6
CAPÍTULO 2. MARCO CONCEPTUAL
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 para el futuro se suelen tomar con base a dicha información. Los procesos que obtienen información con la estructura adecuada (resumidos, globalizados, etc.) son sistemas que, a priori, involucran un alto costo en consumo de recursos, dado el gran volumen de datos sobre el que actúan y el tiempo de procesamiento que conlleva la obtención de las nuevas estructuras.
Está claro que las denominadas "bases de datos operacionales" o "de producción" de
una empresa, no se pueden ver afectadas en sus tiempos de respuesta por dicho consumo en recursos, esto, unido al hecho de que la estructura de las bases de datos de producción puede no ser la opción óptima para la obtención de la información deseada, obliga a la aparición de una nueva estructura en la información: el Data Warehouse, el cual consiste en una "réplica masiva de los datos" disponibles en las bases de datos operacionales, de tal forma que su estructura ya no responde a las necesidades del modelo relacional puro, puesto que en la base de datos del Data Warehouse no se van a efectuar las operaciones que se hacen sobre las base de datos operacionales que le dieron origen. Dado lo anterior ya no existe la necesidad de mantener una estructura de información que esté normalizada, lo que supone un ahorro en el fraccionamiento de la información y en las costosas operaciones de recuperación, y al mismo tiempo, se puede tener una "réplica" conjunta de todas las bases de datos operacionales de la organización.
Así pues tras las dificultades de los sistemas tradicionales para satisfacer las
necesidades de información, surge el concepto de Data Warehouse como solución. Este término establecido por Bill Inmon, se traduce literalmente como almacén de datos. No obstante, si el Data Warehouse fuese exclusivamente un almacén de datos, los problemas seguirían siendo los mismos que en los Centros de Información.
El presente capítulo tiene como objetivo principal dar una breve introducción de lo
que es un Data Warehouse, mencionando diferentes definiciones, ventajas, desventajas, así como los procesos que lo conforman. De igual manera se hace una descripción del proceso de Extracción, Transformación y Transferencia (ETT) de datos dentro de un proyecto Data Warehouse y los problemas que se pueden presentar en este proceso.
2.1 Definiciones del Data Warehouse
El concepto de Data Warehousing surgió a mediados de los 80’s, y en esencia pretendía proporcionar un modelo arquitectónico para el flujo de datos de los sistemas operacionales hacia los ambientes de soporte en la toma de decisiones, al mismo tiempo
7
era un intento por solucionar los diversos problemas asociados con este flujo y con los altos costos inmersos en él [Manning, 1999].
Existen muchas definiciones de Data Warehouse, que han ido surgiendo con el paso
de los años. En opinión de algunos autores [Inmon, Gupta, Jonhson, Mayer] un Data Warehouse
puede definirse de muchas maneras, la siguiente definición toma las puntos más importantes que cada uno de los autores mencionados considera como Data Warehouse.
Un Data Warehouse es una colección de datos orientados a temas específicos,
integrados, no volátiles, variantes en el tiempo, organizados para soportar necesidades empresariales, transformados lógica y físicamente a partir de varias aplicaciones fuentes con el fin de proveer beneficios empresariales, eliminar una gran cantidad de datos inútiles y no deseados, y cubrir todos los aspectos de los procesos, productos y consumidores de la compañía; en otras palabras, es una estructura de base de datos que concentra información de manera detallada o resumida que puede provenir de múltiples fuentes de datos, que está orientada a servir para el proceso de toma de decisiones, y que se encuentra almacenada en una forma fácil de comprender por los usuarios finales. Los datos están estructurados de tal forma que permiten hacer más fácil y efectiva su administración, acceso y análisis.
Castañeda [2001], menciona que las definiciones del Data Warehouse lo presentan
de una u otra manera como una solución que se basa en: 1. Datos que pueden provenir de diferentes y variadas fuentes de información. 2. Datos que ayudan a establecer la situación de la empresa desde una perspectiva
histórica. 3. Datos que se convierten en información básica para la toma de decisiones de la
organización 4. Datos que deben de tener una presentación ideal para su entendimiento y
alineación con los objetivos de la empresa, permitiendo así la generación del conocimiento.
La innovación de la Tecnología de Información dentro de un ambiente Data
Warehousing, puede permitir a cualquier organización hacer mejor uso de los datos, tratándolos como ingredientes clave para hacer más efectivo el proceso de toma de decisiones. Las organizaciones tienen que aprovechar sus recursos de información para crear la información de la operación del negocio, pero deben considerarse las estrategias tecnológicas necesarias para la implementación de una arquitectura completa de Data Warehouse.
Actualmente el Data Warehouse es el centro de atención de las grandes
instituciones, porque provee un ambiente para que éstas hagan un mejor uso de la información que es administrada por diversas aplicaciones operacionales.
8
2.2 Características del Data Warehouse
El Data Warehouse puede verse como un lugar en donde están almacenados todos los datos necesarios para realizar las funciones de administración de la empresa, de manera que puedan utilizarse fácilmente según se necesite. El contenido de los datos, la organización y la estructura son dirigidos a satisfacer las necesidades de información.
A continuación se dan a conocer algunas de las características más importantes de
un Data Warehouse [Solis], [Inmon, 1996]: ? Contiene datos históricos, resumidos y consolidados: o Bases de datos muy grandes. o Datos de fuentes heterogéneas que requieren de integración para formar parte
del Data Warehouse. ? Se puede realizar un procesamiento intensivo de búsquedas-consultas: o Dirigidas por tiempo. o Modelos multidimensionales y nuevas operaciones como la CUBE*
? Es orientado al tema: o Los datos se organizan de acuerdo al tema, no a la aplicación, por ejemplo una
compañía de seguros podría organizar sus datos por cliente, premios, y reclamaciones, en lugar de por diferentes productos (automóviles, vida, etc.).
o Los datos organizados por sujetos contienen sólo la información necesaria para los procesos de soporte en la toma de decisiones.
? Es integrado: o Cuando los datos residen en muchas aplicaciones separados por los distintos
entornos operacionales, la descodificación de éstos es a menudo inconsistente. Por ejemplo, en una aplicación, la palabra género podría codificarse como "m" y "f" en otra como "0" y "1"; cuando los datos fluyen de un entorno operacional a un entorno de Data Warehouse, estos asumen una codificación consistente, por ejemplo género siempre se transformaría a "m" y "f".
? Tiene variación-temporal: o El Data Warehouse contiene un lugar para guardar datos con una antigüedad de
5 a 10 años, o incluso más antiguos, para poder ser usados en comparaciones, tendencias y previsiones. Estos datos no se modificarán.
o Se pueden establecer pronósticos para planificar esfuerzos. ? No es inestables: o Los datos no serán modificados o cambiados de ninguna manera una vez que
han sido introducidos en el Data Warehouse, solamente podrán ser cargados, leídos y/o accedidos.
? Ayuda a realizar la toma de decisiones estratégicas a mediano y largo plazo. ? Permite que la información de administración sea accesible, correcta, uniforme y
actualizada. ? Acceso interactivo e inmediato a información estratégica de un área de negocios.
* Operación utilizada para calcular subtotales de todas las posibles combinaciones de un grupo de dimensiones y además calcular un gran total [ORACLE 8i].
9
2.3 Ventajas del Uso del Data Warehouse
Es necesario conocer las ventajas que puede ofrecer un Data Warehouse para justificar la elección de un proyecto de este tipo, a continuación se mencionan algunas de las más importantes que describe [Díaz]:
? La implementación de un Data Warehouse permite centralizar todos los datos de la
organización dentro de un único almacenamiento. ? La administración de un Data Warehouse es más eficiente que administrar varios
Data marts*. ? El uso de un Data Warehouse permite identificar nuevas oportunidades de negocios. ? En un Data Warehouse se obtienen respuestas en tiempos razonables. ? El Data Warehouse permite analizar desde una perspectiva en el tiempo, con la
información histórica que se brinde, proporcionando la capacidad de aprender de los datos del pasado y de predecir situaciones futuras en diversos escenarios.
? Permite tener fuentes externas para ayudar con la información que se requiere. ? La información proveniente de fuentes operacionales es transformada y limpiada
para lograr consistencia. ? Simplifica dentro de la empresa la implantación de sistemas de administración
integral de la relación con el cliente. ? Menor costo en la toma de decisiones: se suprime el despilfarro de tiempo que se
producía al intentar ejecutar consultas de datos largas y complejas en las bases de datos operacionales, las cuales están diseñadas específicamente para transacciones cortas y sencillas.
? Mayor flexibilidad ante el entorno: el Data Warehouse convierte los datos operacionales en información relacionada y estructurada que genera el "conocimiento" necesario para la toma de decisiones. Esto permite establecer una base única del modelo de información de la organización, que puede dar lugar a una visión global de la información en base a los conceptos de negocio que tratan los usuarios. Además, aporta una mejor calidad y flexibilidad en el análisis del mercado, y del entorno en general.
? Mejor servicio al cliente: lo que repercute en la relación directa con el cliente, que como se sabe, es uno de los pilares básicos en los que descansa cualquier organización. De hecho, el que un Data Warehouse implique una mayor flexibilidad ante el entorno tiene una consecuencia directa en una mayor capacidad para responder a las necesidades de los clientes.
? Rediseño de procesos: ofrecer a los usuarios una capacidad de análisis de la información de su negocio que tiende a ser ilimitada y permite con frecuencia obtener una visión más profunda y clara de los procesos de negocio propiamente dichos, lo que a su vez permite obtener ideas renovadoras para el rediseño de los mismos.
? La capacidad de decisiones distribuidas es cada vez más necesaria para las empresas, y es uno de los aspectos en los que el Data Warehouse puede aportar una contribución esencial.
* Los Data Marts generalmente se conocen como un componente del Data Warehouse, están enfocados en un conjunto de datos específicos o en un proceso del negocio [Hammergren, 1996].
10
La ventaja principal de este tipo de sistemas se basa en la estructura de la información. Este concepto significa el almacenamiento de información homogénea y fiable, en una estructura basada en la consulta y el tratamiento jerarquizado de la misma, y en un entorno diferenciado de los sistemas operacionales.
2.4 Desventajas del Uso del Data Warehouse
Así como es importante conocer las ventajas de un Data Warehouse, también lo es conocer cuáles pueden ser algunas de sus desventajas.
? Realizar una consulta muy compleja en un Data Warehouse con una base de datos
muy grande puede ser un proceso lento, sobre todo si no se cuenta con una plataforma paralela y una capacidad de consultas paralelizadas.
? La implementación de un Data Warehouse requiere de un equipo considerable de analistas, de desarrolladores, de hardware, de software, de tiempo y de dinero.
? El tiempo de desarrollo e implementación de un Data Warehouse puede durar muchos meses o más de un año.
? La construcción y manejo final de un Data Warehouse por parte de los usuarios puede ser muy complejo y difícil sino se cuenta con la capacitación y las herramientas adecuadas.
2.5 Procesos que conforman la operación de un Data Warehouse
Es importante considerar los procesos que conforman la operación de un Data Warehouse, ya que estos son los que hacen posible la existencia del mismo. A continuación se describen dichos procesos clave en la administración y operación de un Data Warehouse:
1. Obtención de los datos operacionales: origen de los datos. 2. Extracción: obtener los datos de las distintas fuentes tanto internas como
externas, para poblar el Data Warehouse. 3. Transformación: filtrar, limpiar, depurar, homogeneizar y agrupar los datos
para lograr los objetivos orientados a la toma de decisiones. 4. Transferencia y/o Carga: organizar y actualizar los datos en el Data Warehouse. 5. Explotación: extraer y analizar los datos en los distintos niveles de agrupación
del Data Warehouse. Desde el punto de vista del usuario, el único proceso visible es la explotación del
Data Warehouse, aunque el éxito del Data Warehouse radica en los procesos 2, 3 y 4, que alimentan la información del mismo, y suponen el mayor porcentaje de esfuerzo (aproximadamente un 80%) a momento de desarrollar un Data Warehouse.
11
En la figura 2-1, se muestran gráficamente los procesos que se llevan a cabo en un proyecto Data Warehousing, en ésta se puede ver que los datos operaciones pueden tener su origen en fuentes internas y/o externas, ya sean sistemas operacionales corporativos, sistemas operacionales departamentales u otros; los datos operacionales son los que normalmente están presentes en las organizaciones y es a partir de los cuales se realiza la captura de datos que se contemplará en el Data Warehouse. De igual manera se pueden ver las tres funciones u operaciones clave en el proceso ETT, mostradas en orden, la Extracción, la Transformación y la Transferencia de los datos operacionales al Data Warehouse. Y por último se ve la Explotación de los datos existentes en el Data Warehouse.
Figura 2-1 Procesos en un Data Warehouse
Las tareas de Extracción, Transformación, Transferencia (ETT) o carga de datos
requieren de mucho tiempo en un proyecto de Data Warehouse; en estas tareas es donde se demanda el mayor esfuerzo [ORACLE].
El proceso de Explotación, también podría denominarse como un componente de
administración, y los servicios que ofrece incluye un servicio de mantenimiento de datos y un servicio de distribución para exportar datos del Data Warehouse a servidores de bases de datos descentralizadas, y a otros sistemas de soporte en la toma de decisiones de los usuarios. El componente de administración también ofrece servicios de seguridad (archivo, respaldos, recuperación) y monitorización.
El Data Warehouse no produce resultados en forma mágica. Los administradores de
empresas y los analistas deben acceder y recuperar los datos del Data Warehouse y convertirlos en información y en hechos. Estos hechos conforman los cimientos de una base de conocimientos que sirve para determinar la salud de la empresa y la dirección futura del negocio. Como en las granjas, los usuarios sólo cosecharán la información que se pueda derivar de los datos que sembraron en el Data Warehouse, y sólo mediante el uso de herramientas adecuadas, algunas de ellas son:
? Las de acceso y recuperación. ? Las de reportes de base de datos
Extracción
Transformación
Transferencia
Data
Warehouse
Expl
otac
ión
Fuentes
Externas
Fuentes Interna
s
Dato
s O
pera
cion
ales
Proceso ETT
12
? Las de análisis ? Las de data mining (minería de datos). Uno de los retos al cosechar un Data Warehouse consiste en no convertir montículos
de información en montañas de datos. Es fácil caer en la trampa de "entre más, mejor". No es esencial conocer todos los hechos, sólo los cruciales.
Herramientas de soporte de decisiones es el término genérico para referirse a las
aplicaciones y herramientas del Data Warehouse que se emplean para recuperar, manipular y analizar los datos, y para presentar después los resultados. Estas herramientas se usan en dos modalidades: verificación y descubrimiento. En la modalidad de verificación, el usuario empresarial crea una hipótesis -una cuestión empresarial- e intenta confirmarla accediendo a los datos en el Data Warehouse. Las herramientas que implementan la modalidad de verificación son de consulta, de sistemas de reporte y de análisis multidimensional. En la modalidad de descubrimiento, las herramientas intentan descubrir características en los datos como patrones de compra o la asociación entre la adquisición de artículos diferentes. En la modalidad de descubrimiento, o eureka, el usuario empresarial no conoce ni sospecha los patrones y asociaciones descubiertos. La herramienta de Data Mining es un ejemplo de la modalidad de descubrimiento. Desde la perspectiva de disponibilidad de herramientas, las dos modalidades de verificación y descubrimiento se clasifican en tres enfoques: Procesamiento Informático, Procesamiento Analítico y Data Mining*.
2.6 Proceso de Extracción, Transformación y Transferencia (ETT) de datos.
La extracción, transformación y transferencia de los datos de los sistemas operacionales fuente al Data Warehouse forman el proceso mejor conocido como ETT en un proyecto Data Warehouse.
El propósito del Data Warehouse de servir como un medio para poder analizar el
negocio, hace latente la necesidad mantener actualizados los datos regularmente, en otras palabras, el proceso ETT no se realiza una sola vez, constantemente se lleva a cabo, razón por la cual frecuentemente se ha considerado como una tarea difícil en el proyecto del Data Warehouse.
En el proceso ETT se encuentran los pasos por los que atraviesan los datos para ir
desde el sistema operacional (fuente de datos utilizada) hasta el Data Warehouse. La extracción es lo primero que se hace, después en algunas ocasiones se requiere
de la transformación y por último se lleva a cabo la Transferencia de los datos.
* es al análisis de la información con el fin de descubrir patrones, relaciones, reglas, asociaciones o incluso excepciones que sean útiles para la toma de decisiones [Estivill, 1997].
13
2.6.1 Extracción
La extracción se refiere al mecanismo por medio del cual los datos operacionales son leídos desde su fuente original.
Diseñar y crear el proceso de extracción usualmente es la tarea que más tiempo
consume en el proceso ETT y por supuesto en el proyecto de Data Warehouse completo. Los sistemas operacionales fuente pueden ser muy complejos, por lo que determinar cuales datos son necesarios para el proyecto en ocasiones es una tarea difícil, sobre todo porque dichos sistemas no pueden ser modificados, su accesibilidad y desempeño no pueden ser afectados para satisfacer las necesidades del proceso de extracción del Data Warehouse [Oracle].
2.6.2 Transformación
La transformación (también conocida como limpieza) es la etapa por la que algunas veces pueden atravesar los datos de las distintas fuentes para ser estandarizados, normalizando y fijando una estructura para ellos en el Data Warehouse. En algunas ocasiones esta operación no es requerida debido a que en e Data Warehouse se espera el dato tal y como se encuentra en el sistema operacional.
Algunas de tipos de transformaciones que comenta [Flower, 2003] que pueden ser
aplicadas, son las siguientes: ? Tipo de coerción, es cuando se necesita hacer una transformación en los datos
porque el tipo de columna en las tablas del Data Warehouse son diferentes del tipo de columna en los sistemas operacionales. Por ejemplo, supóngase que existen dos sistemas operacionales fuentes que tienen información sobre productos, en uno de los sistemas el identificador del producto es de tipo char(10) porque los códigos usados son alfanuméricos y en el otro sistemas está definido como numérico. Esto quiere decir que el dato en el campo numérico deberá ser transformado a un dato alfanumérico.
? Manipulación de cadenas (strings), es cuando se requiere aplicar operaciones de concatenación, eliminación de espacios (trim), convertir a mayúsculas (up case), etc., en los datos.
? Cálculos matemáticos, es cuando se hace uso de las funciones aritméticas. ? Asignación condicional, se refiere a derivar el valor para los campos de las tablas
de Data Warehouse a través de la aplicación de ciertas condiciones a los datos de los sistemas operacionales.
? Agregación, es cuando se necesita un dato resultado de generar una consulta con una función de agregación.
2.6.3 Transferencia
La transferencia literalmente consiste en el acto de mover los datos de un sistema operacional a otro; en el ambiente del Data Warehouse consiste básicamente en llevar
14
(remota o localmente) los datos leídos y estandarizados (extraídos y transformados) al Data Warehouse.
Una forma gráfica de ver las operaciones involucradas en el proceso ETT es la
mostrada en la figura 2-2, como se menciono anteriormente, la transformación de los datos puede o no existir ya que depende de cómo se encuentren los datos en las bases de datos fuente y la necesidad de integración.
Figura 2-2 Operaciones involucradas en el proceso ETT
2.6.4 Problemas en el proceso ETT
Al ser el proceso ETT uno de los más importantes en un proyecto Data Warehouse, es necesario tener presente los problemas que pueden ocurrir en éste.
El proceso ETT tiene como meta llevar los datos del sistema operacional fuente al
Data Warehouse; para lograrlo es necesario que tanto la extracción como la transformación y la transferencia de los datos se lleve a cabo satisfactoriamente, sin embargo [Montolio, 2001] argumenta que esto plantea una serie de problemas que son inherentes a dicho proceso, mismos que a continuación se describen.
? El primero de estos problemas es el de la integración de los datos, dado que una
situación normal en este entorno es que cada una de las bases de datos operacionales esté soportada por manejadores de bases de datos de diferentes fabricantes, esto puede provocar que un atributo sea de tipo diferente en cada uno de los sistemas operacionales, aún cuando los sistemas provengan del mismo fabricante se puede presentar lo anterior, debido a que las bases de datos pudieron haber sido diseñadas e implementadas por distintos equipos/departamentos y en
Extracción
Sistemas Operacionales
Datos externos
Transformación Transferencia
Data Warehouse
15
diferentes fechas. Es evidente que, por trivial que sea, dicha integración supone un trabajo extra.
? El segundo de los problemas que conlleva este proceso es elegir el momento en que se produce la carga o transferencia al Data Warehouse. Lo importante en este tema se centra en que la extracción se debe realizar en un momento en que todas las bases de datos estén en un estado “estable” de tal forma que se minimicen las posibles inconsistencias, que por otra parte, de producirse, deben detectarse y corregirse en este punto, ya que es el único en el que se debe permitir la actualización.
? Asociado a lo anteriormente expuesto, está el hecho de que para realizar la carga o transferencia de datos, no se puede parar la operación diaria de la organización porque normalmente es fundamental para su buen funcionamiento. Esto nos lleva a diseñar y preparar los procedimientos necesarios para minimizar el tiempo destinado a dichas actividades. Todo ello lleva a que, en general, se realice una carga en un área temporal sobre la que sí está permitido hacer transformaciones asociadas a la integración y comprobación de coherencia anteriormente mencionadas.
? Adquiere especial importancia también, la existencia de un buen diccionario de datos o “metadatos” ya que es absolutamente necesario conocer, de la estructura final del Data Warehouse, todos los detalles posibles. Esto quiere decir que un diccionario de datos de estas características no puede ser un mero registro de las características principales de los atributos, sino que debe contemplar todas las especificaciones tales como el atributo del que proviene, de qué base de datos, qué transformación ha sufrido, por qué es necesario para el Data Warehouse, etc.
? Por último hay que tener en cuenta detalles de más bajo nivel que pueden afectar al proceso de carga debido a las características del sistema usado. Así, una mejora en la carga la constituye el hecho de eliminar completamente los índices de la base de datos para pasar a proceder con la carga y, finalmente volver a generar los índices (ya que de mantenerse los índices, lo normal es que por cada registro que se inserta en una tabla el manejador de bases de datos debe proceder a reordenar todos los índices).
16
CAPÍTULO 3. TÉCNICAS EMPLEADAS EN EL PROCESO DE EXTRACCIÓ N, TRANSFORMACIÓ N Y TRANSFERENCIA DE DATOS (ETT)
El proceso ETT es la clave para el éxito de un Data Warehouse, es por ello que se considera importante que la elección de las técnicas a usar en dicho proceso esté en función principalmente de la plataforma en la que se encuentren las bases de datos, tanto de los sistemas operacionales fuente como del Data Warehouse, del volumen y de la volatilidad de los datos [Hammergren, 1996].
Como parte de este capítulo se describen algunas de esas técnicas empleadas en el
proceso ETT, dando una breve explicación y algunos ejemplos de técnicas secuenciales y técnicas incrementales.
3.1 Clasificación de las técnicas empleadas en el proceso ETT
Es muy poca la documentación publicada que existe en cuanto a la forma en que se pueden clasificar las técnicas usadas en el proceso ETT, una clasificación general de éstas es separarlas en técnicas secuenciales y en técnicas incrementales [Palomar, 2002].
? Las técnicas secuenciales son aquellas en las que se extraen y transfieren todos los
datos del sistema operacional fuente que son requeridos para el Data Warehouse, es decir se obtienen todos los datos sin importar si hubo alguna actualización o no en ellos.
? Las técnicas incrementales son las que se concentran únicamente en la extracción y transferencia de los datos que sufrieron alguna actualización en el sistema operacional fuente y que tiene que ser actualizado en el Data Warehouse.
3.2 Técnicas Secuenciales
De acuerdo a [ORACLE 8i], existen dos categorías para las técnicas secuenciales del proceso ETT.
? Las técnicas para extraer datos de un sistema operacional colocándolos dentro de
un archivo (por ejemplo descargas de datos y exportaciones a través de programas computacionales que generan archivos de datos).
17
? Las técnicas para extraer datos de un sistema operacional y transferirlos directamente al Data Warehouse (por ejemplo gateway y queries distribuidos).
3.2.1 Archivos de datos.
La extracción y transferencia de datos con archivos puede realizarse con queries hechos en SQL (Standard Query Language) dirigiendo la salida a un archivo de datos, los queries obtendrán los datos que se encuentren en las tablas indicadas y que cumplan con las condiciones dadas.
Otra forma de obtener los datos es con programas computacionales, en un lenguaje
que sea soportado por la plataforma, como se puede ver en la figura 3-1 esta técnica consiste en hacer un programa para la extracción de los datos operacionales de las fuentes existentes y la transformación de los que lo requieran, dichos datos son guardados en un archivo plano, el cual se transfiere a la máquina del Data Warehouse, a través de otro programa computacional se hace la carga de los datos, usando el archivo que resulto con el primer programa. El primer programa, obviamente se ejecuta en la o las bases de datos fuente y el segundo en la base de datos del Data Warehouse.
Figura 3-1 Proceso ETT con archivo de datos
3.2.2 Queries distribuidos
La técnica de queries distribuidos consiste en extraer datos de una tabla del sistema operacional fuente y transferirlos directamente a otra tabla en el Data Warehouse. Éste es quizá el método más simple para mover datos entre las bases de datos involucradas, porque se combina la extracción y la transferencia en un sólo paso, y por otra parte, requiere un mínimo de programación. Para hacer uso de los queries distribuidos, ambas bases de datos, la del sistema operacional fuentes y la del Data Warehouse, deben de tener la capacidad de accesar tablas en una base de datos diferente.
Programa de extracción y
transformación
Transferencia del archivo generado
Programa de transferencia
y/o carga
Data
Warehouse
Lee los datos del archivo Extracc_datos.dat
Genera el archivo Extracc_datos.dat
Datos operacionales
fuente 2
Datos operacionales
fuente 1
18
3.3 Técnicas Incrementales
Las técnicas incrementales permiten reducir considerablemente el tiempo destinado, tanto para la extracción como para la transferencia de datos, esto se debe a que sólo se extraen, se transforman y se transfieren los datos que han tenido alguna modificación, o que son nuevos para el Data Warehouse [Fiore, 1998]. De ahí que, resulta deseable el uso de técnicas incrementales como parte del proceso ETT.
Para [Bokun, 1998] existen dos categorías de técnicas incrementales, él las nombra
captura estática e incremental de cambios en los datos. ? Las técnicas para la captura estática de los datos que han cambiado, son las que
extraen los datos en un tiempo determinado. A veces todos los datos son recuperados, pero solamente un subconjunto será utilizado. Para realizar este tipo de técnicas se pueden utilizar: Snapshots, Timestamp, Comparación de Archivos también conocida como Snapshots Diferenciales, Partitioning, Monitoreo de registros, entre otros.
? Las técnicas para la captura incremental de los datos que han cambiado, son técnicas que dependen del tiempo para capturar los cambios en un sistema operacional, son la mejor opción cuando los cambios en los datos son significativamente más pequeños que el tamaño del conjunto de datos en un periodo de tiempo especifico. Estas técnicas son más complejas que las anteriores, porque están más relacionadas con los DBMS (Sistema manejador de Bases de datos) o con el software operacional que actualiza los DBMS. Para llevar a cabo este tipo de técnica se utilizan: captura asistida por aplicaciones, captura basada en triggers y captura de registro de transacciones.
El uso de técnicas incrementales para detectar y extraer los cambios en los datos del
sistema operacional fuente, depende de la capacidad de soporte que tenga los propios sistemas, tanto el operacional como el Data Warehouse [Adiwijaya, 1997].
Previo a utilizar una técnica incremental por lo menos debe existir una extracción y
transferencia completa de los datos operacionales para alimentar el Data Warehouse, por lo que parece necesario hacer uso de una técnica secuencial antes de utilizar por primera vez una técnica incremental.
En algunos proyectos de Data Warehouse las técnicas incrementales no son usadas
como parte del proceso de extracción. En lugar de esto, las tablas completas del Data Warehosue son extraídas en un momento determinado, para ser comparadas con una previa extracción que se hace del sistema operacional fuente, identificando el cambio en los datos y de esta manera actualizar el Data Warehouse. Esta actividad no tiene un impacto significante en los sistemas fuentes, pero si lo tiene en el Data Warehouse, particularmente si el volumen de los datos es muy grande [Oracle 8i].
Para que una técnica de extracción incremental tenga el mínimo impacto en el
sistema operacional fuente según [Ram, 2000] se requiere:
19
? No afectar en el desempeño del sistema operacional fuente. Esto debido a que uno de los propósitos primarios de un Data Warehouse es tomar el proceso de la carga de sistemas operacionales.
? Tener la facilidad de capturar los cambios en los datos. ? No modificar las aplicaciones existentes.
3.3.1 Snapshots
Un Snaphot captura los datos que se encuentran en una estructura, de la base de datos fuente, en un momento determinado. Para [Corke, 2000] un Snapshots es como un proceso programado para ejecutarse automáticamente y satisfacer tanto la volatibilidad de los datos como los requerimientos de actualización de los mismos.
La extracción y transferencia de los datos con el Snapshot pueden darse de dos
formas [Bokun, 1998]: ? Recargar, consiste en obtener todos los datos de los sistemas operacionales que son
necesarios en el Data Warehouse tal y como están en un tiempo determinado, para ello se asume que previamente a la ejecución del Snapshot se eliminan y recrean la o las tablas en el Data Warehouse o se borran todos los registros que contienen dichas tablas.
? Añadir, es cuando se asume que existen datos en las tablas en donde se hará la carga de información y que la información en esas tablas cumple con reglas predefinidas, por ejemplo que si un registro existe se sobrescribirá y sino se insertará.
El resultado de las operaciones que realiza el Snapshot es casi igual que el de
realizar una copia tradicional; la principal diferencia es que el tiempo requerido para crear una copia con Snapshots se mide en segundos a diferencia del tiempo que se requiere para realizar la duplicación tradicional la cual se mide en minutos u horas.
El uso de Snapshots como herramienta para la extracción y transferencia de los
datos al Data Warehouse, puede o no tener resultados benéficos dependiendo de cómo y cuándo se utilice.
20
Figura 3-2 Proceso ETT con Snapshot
3.3.2 Time Stamp
El timestamp especifica la hora y la fecha en que un registro fue modificado por última vez. Está técnica se puede emplear cuando las tablas de algún sistema operacional tiene columnas timestamp (guardar la fecha de actualización), entonces el dato más reciente puede ser fácilmente identificado usando dichas columnas.
Si el timestamp no está disponible en un sistema operacional, el sistema puede ser
modificado para incluirlos. Esto requiere, primero, modificación de las tablas del sistema operacional para incluir la nueva columna timestamp y segundo, crear un trigger para actualizar la columna timestamp cada vez que una operación modifique un registro.
Las técnicas basadas en timestamp requieren un barrido completo de la tabla, a
menos de que exista un índice definido en el atributo de la fecha de actualización. Esta técnica es claramente aplicable a la extracción de datos de los sistemas operacionales fuente que soportan timestamp nativamente y que tienen poca actividad de cambio.
La tabla 3.1 muestra los resultados obtenidos por [Ram, 1998] del tiempo requerido
para la extracción de datos que sufrieron algún cambio en una base de datos fuente, aplicado a una tabla de 1G con 10 millones de registros de 100 bytes. Se hizo la extracción para tamaños de 100, 200, 400, 600, 800 Megas y la tabla completa. Así mismo se muestran los tiempos cuando los datos son dirigidos a un archivo, a una tabla y a una tabla con exportación.
SISTEMA OPERACIONAL
Data
Warehouse Estado de la tabla de 10:00 am a 11:00 am
SNAPSHOT Dato 1
Actualiza 2 Dato 3
Estado del Snapshot de la tabla X a las 10:30 am
Tabla X Dato 1
Actualiza 2 Dato 3
Tabla X Actualiza 1 Actualiza 2 Actualiza 3
Estado de la tabla de 11:00 am a 12:00 am
21
Tabla 3-1 Extracción de cambios utilizando time stamp
3.3.3 Particionamiento
El concepto de particionamiento es dividir una tabla en partes separadas, lo cual aumenta la velocidad de acceso a una partición individual de las bases de datos y también puede ser utilizado como una técnica incremental en el proceso ETT del Data Warehouse, para esto es necesario que las tablas tengan una partición por fechas que permitan identificar rápidamente un nuevo dato o cambios en los datos.
3.3.4 Triggers
Los triggers almacenan procedimientos que pueden contener instrucciones de actualización, eliminación o inserción de datos que se invocan cuando ciertas condiciones o eventos ocurren. Así pues al hacer uso de los triggers no se tienen que extraer y transferir los datos que no sufrieron algún cambio y esto disminuye la cantidad de registros que tienen que ser procesados. Cabe aclarar que la base de datos fuente tiene doble trabajo de carga cuando toda la población que es parte del Data Warehouse sufre algún cambio.
La técnica de extracción de datos basada en triggers es considerada muy simple de
implementar y no requiere de cambios en la aplicación del sistema operacional fuente. Debido a que esta técnica está basada en eventos, es una de las mejores opciones cuando la captura de cambios es requerida para mantener actualizado el Data Warehouse.
Hay dos formas de emplear los triggers: a nivel base de datos y a nivel de aplicación.
Cabe mencionar que la primera opción es menos costosa que la segunda. Los triggers se pueden crear en los sistemas operacionales para no perder de vista
los registros actualizados recientemente. Se pueden usar en conjunto con las columnas timestamp para permitir identificar la hora y fecha exacta cuando un registro tuvo la última modificación. Para esto se crea un trigger en cada una de las tablas fuente de las que se requiere capturar el cambio en los datos. Siguiendo cada instrucción que es ejecutada en la tabla fuente, los triggers actualizan la columna timestamp con la hora actual. Así, la columna timestamp provee la hora y la fecha de la última actualización realizada al registro.
Extracción de Cambios
Salida a 100M 200M 400M 600M 800M 1G
Archivo 17min 26min 43min 59min 1hr 19min 1hr 36min
Tabla 29min 55min 1hr 45min 2hr 40min 3hr 29min 4hr 24min
Tabla + exportación 32min 1hr 8min 2hr 8min 3hr
17min 4hr 25min 5hr 56min
22
Con el uso de triggers se pueden actualizar e insertar registros del Data Warehouse, dependiendo de la acción que se realice en los sistemas operacionales fuente.
3.3.5 Snapshots diferenciales
Está técnica también es conocida como comparación de archivos y consiste en mantener una imagen de los datos importantes para el Data Warehouse antes y después de los últimos cambios registrados. Se hace una descarga del estado actual de las tablas de la base de datos del sistema operacional fuente en un tiempo indicado, para compararla con el Snapshot generado en el mismo sistema y que previamente fue almacenado. Para detectar los cambios, uno a uno los registros obtenidos antes y después del cambio son comparados y para detectar los datos nuevos (inserción) y los datos que ya no existen (eliminación) se hace una comparación de la llave de los registros.
Como se puede ver esta forma de extraer y transferir los datos requiere del uso de
una técnica de carga y descarga de la base de datos de los sistemas operacionales fuente y además programación computacional para comparar los Snapshots obtenidos antes y después de que suceden los cambios y poder detectar los cambios en los datos.
Esta técnica es compleja por naturaleza y se recomienda usarla sólo cuándo es la
única solución, es decir en casos donde ninguna otra técnica es factible de usar [Bokun, 1988].
3.3.6 Habilitación de Consultas (Queryable)
Para esta técnica se asume que el sistema operacional fuente es queryable. Para detectar y extraer los cambios del sistema operacional fuente, los queries deben ser editados. El valor actual de los datos relevantes es comparado con su valor anterior, una diferencia en el valor indica que ocurrió un cambio, en este caso el sistema central es el que realiza la mayor parte de las tareas de detección y extracción de cambios.
3.3.7 Monitoreo de registros
El monitoreo de registros consiste en aplicar los cambios que están archivados en los registros del sistema de procesamiento en línea, también conocido como OLTP por sus siglas en inglés On Line Transaction Processing, a los datos que se encuentran en el Data Warehouse.
Cada una de las técnicas anteriormente descritas debe de ser cuidadosamente
evaluada por los dueños de los sistemas operacionales fuente antes de la implementación, sobre todo cuando es necesario realizar modificaciones en dichos sistemas.
23
Identificar y extraer sólo los datos que han cambiado después de la última actualización del Data Warehouse, hace más eficiente el proceso ETT porque sólo se extrae un volumen de datos muy pequeño. Desafortunadamente para muchos sistemas operacionales esta tarea puede ser muy difícil o inapropiada para la operación del sistema.
Las técnicas incrementales pueden trabajar en conjunto con las técnicas
secuenciales. Por ejemplo, la técnica timestamp puede ser usada cuando los datos se descargan en archivos de datos y cuando se accesan vía query distribuido o Snapshots.
Así mismo, las ventajas y desventajas que cada una de las técnicas pueda ofrecer
depende particularmente de las capacidades que tengan los sistemas operacionales fuente y el Data Warehouse, así como también del tiempo promedio de cambio en dichos datos.
3.4 Ejemplos para el uso de las técnicas secuenciales e incrementales
Para efecto de los ejemplos se considerará lo siguiente: ? En el sistema operacional fuente existe una tabla que almacena las unidades
organizacionales de una institución educativa, esta tabla es nombrada ST4ORGN (diccionario de datos, en el anexo A.1) cuya estructura se muestra en la figura 3-1 a.
? El Data Warehouse tiene una tabla llamada UNID_ORG, la cual contendrá los campos mostrados en la figura 3-1 b.
? El origen de los campos de la tabla UNID_ORG se indica en la figura 3-1 con las flechas.
Figura 3-3 Estructura de las tablas de unidades organizacionales
a) Base de datos fuente b) Base de datos del Data Warehouse
24
Tomando en cuenta lo anterior, la aplicación de las técnicas para mantener actualizada la tabla UNID_ORG con los datos operacionales, es presentada a continuación.
3.4.1 Con archivos de datos.
En la base de datos fuente, se genera una consulta, usando SQL, para obtener los datos que se requieren de la tabla ST4ORGN para alimentar la tabla UNID_ORG del Data Warehouse.
SET ECHO OFF SPOOL unidades_org.dat /* Se direcciona la salida a un archivo */ SELECT ST4ORGN_CODE, /* Se hace la consulta de los datos que ST4ORGN_EFF_DATE, se ocupan */ ST4ORGN_CODE_PRED, ST4ORGN_EFF_DATE_PRED, ST4ORGN_NOMBRE, ST4ORGN_SIGLAS FROM SATURN.ST4ORGN SPOOL OFF;
Haciendo uso de un programa computacional, en un lenguaje permitido por la
plataforma del sistema operacional fuente, por ejemplo Pro*C, el siguiente código corresponde a una función para extraer los datos de la tabla indicada en un archivo plano. Primero se genera un archivo tipo texto con el nombre de Unidades_Org.dat, después con la ayuda de un query (utilizando lenguaje SQL) se hace el cursor para extraer todos los datos de la tabla ST4ORGN, cada registro producido por el query se escribe (utilizando lenguaje C) en el archivo que previamente fue creado.
void Unidades_Organiacionales() { FILE *datos; int contador = 0; str10 CODE, CODE_PRED, SIGLAS; str15 EFF_DATE, EFF_DATE_PRED, DATE; str70 NOMBRE; shoirt CODE_i, CODE_PRED_i, SIGLAS_i, DATE_i, NOMBRE_i, EFF_DATE_i, EFF_DATE_PRED_i; Crea_Archivo("Unidades_Org.dat",&datos,"w"); EXEC SQL DECLARE Cursor_ST4ORGN CURSOR FOR SELECT ST4ORGN_CODE, ST4ORGN_EFF_DATE, ST4ORGN_CODE_PRED, ST4ORGN_EFF_DATE_PRED, ST4ORGN_NOMBRE, ST4ORGN_SIGLAS, ST4ORGN_ACTIVITY_DATE FROM SATURN.ST4ORGN; EXEC SQL OPEN Cursor_ST4ORGN; for (;;) { EXEC SQL WHENEVER NOT FOUND DO break; EXEC SQL FETCH Cursor_ST4ORGN INTO :CODE :CODE_i, :EFF_DATE :EFF_DATE_i;
/*Declaración de variables*/ /*Crea el archivo en donde se escribirán los datos extraídos*/ /*Declaración del cursor principal, sólo se consultan los datos que se ocupan en el Data Warehouse */ /*Para cada registro arrojado por la
25
:CODE_PRED :CODE_PRED_i, :EFF_DATE_PRED :EFF_DATE_PRED_i, :NOMBRE :NOMBRE_i, :SIGLAS :SIGLAS_i, :DATE :DATE_i; EXEC SQL WHENEVER NOT FOUND continue; if (CODE_i < 0) strcpy(CODE,""); if (EFF_DATE_i < 0) strcpy(EFF_DATE,""); if (CODE_PRED_i < 0) strcpy(CODE_PRED,""); if (EFF_DATE_PRED_i < 0) strcpy(EFF_DATE_PRED,""); if (NOMBRE_i < 0) strcpy(NOMBRE,""); if (SIGLAS_i < 0) strcpy(SIGLAS,""); if (DATE_i < 0) strcpy(DATE,""); fprintf(datos,"%s|%s|%s|",CODE,EFF_DATE,CODE_PRED); fprintf(datos,"%s|%s|",EFF_DATE_PRED,NOMBRE); fprintf(datos,"%s|%s|\n", SIGLAS,DATE); contador ++; } EXEC SQL CLOSE Cursor_ST4ORGN; EXEC SQL COMMIT WORK; Cierra_Archivo(datos); }
consulta se revisa que no haya errores*/ /*Escritura de los datos de un registro en el archivo*/ /*Se cierra el archivo*/
Después de que ya se tiene el archivo plano con los datos necesarios, se procede a la
transferencia y carga de los datos en el Data Warehouse. Para la transferencia se puede utilizar FTP* (File Transfer Protocol). Una vez que el archivo de datos se encuentra en la máquina del Data Warehouse se hace uso de otro programa computacional, también hecho en Pro*C, para realizar la carga, la función para poblar la tabla UNID_ORG con los datos que contiene el archivo generado, es la siguiente:
void CargaTabla_UNID_ORG() { int cont_update=0, cont_insert=0, cont_error=0, existen_errores=0, k=0, j=0; char cadena[150], cadena_num[20]; Abre_Archivo("Unidades_Org.dat",&datos,"r"); Crea_Archivo("Unidades_Org.ctl",&control,"w"); while (!feof(datos)) { leer_campo(datos,cadena); strcpy(CODE,cadena); leer_campo(datos,cadena); strcpy(EFF_DATE,cadena); leer_campo(datos,cadena); strcpy(CODE_PRED,cadena); leer_campo(datos,cadena); strcpy(EFF_DATE_PRED,cadena); leer_campo(datos,cadena); strcpy(NOMBRE,cadena); leer_campo(datos,cadena); strcpy(SIGLAS,cadena); leer_campo(datos,cadena); strcpy(DATE,cadena); leer_fin(datos); if (feof(datos)) break;
/*Declaración de variables*/ /*Abre el archivo de datos y crea un archivo para resumir las operaciones que se realizaron*/ /*Se leen las columnas de un renglón para obtener cada campo de la tabla UNID_ORG, haciendo uso de la función leer_campo*/
* Se recomienda el uso del protocolo de transferencia de archivos, debido a que el método más común para transportar datos es éste [ORACLE, 8I].
26
existen_errores = 0; EXEC SQL SELECT COUNT(*) INTO :cant :cant_i FROM UNID_ORGN WHERE CLAVE_UNID_ORG = :CODE; if (cant > 0) { EXEC SQL UPDATE UNID_ORG SET UNID_ORG_FECHA_EFF = :EFF_DATE, CLAVE_UNID_ORG_PRED = :CODE_PRED, UNID_ORG_FECHA_EFF_PRED = :EFF_DATE_PRED NOMBRE_UNID_ORG = :NOMBRE SIGLAS_UNID_ORG = :SIGLAS UNID_ORG_ACTIVITY_DATE = :SYSDATE WHERE CLAVE_UNID_ORG = :CODE; cont_update ++; } else { EXEC SQL INSERT INTO UNID_ORG (CLAVE_UNID_ORG, UNID_ORG_FECHA_EFF, CLAVE_UNID_ORG_PRED, UNID_ORG_FECHA_EFF_PRED, NOMBRE_UNID_ORG, SIGLAS_UNID_ORG, UNID_ORG_ACTIVITY_DATE) VALUES(:CODE, :EFF_DATE, :CODE_PRED, :EFF_DATE_PRED, :NOMBRE, :SIGLAS, :SYSDATE); cont_insert ++; } fprintf(control,"\nProcesando # : %d. %c",k-1,13); fprintf(control,"\n\n Terminado .... \n"); fprintf(control,"\nRegistros Totales %d",k-1); fprintf(control,"\nRegistros Insertados UNID_ORG %d",cont_insert); fprintf(control,"\nRegistros Actualizados UNID_ORG %d",cont_update); fprintf(control,"\nRegistros Con Error UNID_ORG %d",cont_error); EXEC SQL COMMIT WORK; Cierra_Archivo(datos); Cierra_Archivo(control); }
/*Para cada registro leído se hace una consulta para saber si ya existe o no en la tabla UNID_ORG*/ /*Si existe el registro se hace una actualización de los datos*/ /*Sino existe se hace una inserción*/ /*Se escribe en el archivo de control el resumen de las operaciones realizadas*/ /*Se cierran los archivo de lectura y escritura*/
3.4.2 Con queries distribuidos
Para extraer los datos del sistema fuente haciendo uso de los queries distribuidos es necesario que la base de datos tenga los permisos necesarios para ser accesada remotamente. Una vez que se ha establecido conexión entre el Data Warehouse y el sistema fuente se hace un query similar al que se hizo en el punto 3.4.1.
CREATE TABLE UNID_ORG AS SELECT ST4ORGN_CODE, /* Se hace la consulta de los datos que se ST4ORGN_EFF_DATE, ocupan */ ST4ORGN_CODE_PRED,
27
ST4ORGN_EFF_DATE_PRED, ST4ORGN_NOMBRE, ST4ORGN_SIGLAS FROM ST4ORGN@SOURSE_DB /* Se hace referencia a la tabla remota En la que se ejecutará el query */
3.4.3 Con Snapshots
Para hacer la extracción con el uso de Snapshots, el db link de conexión al sistema operacional es creado con el nombre de OPERA_PROD.
create snapshot S_UNID_ORG /* Se crea el snapshot tablespace DEVL_DWH refresh complete /* Forma de pasar los datos start with SysDate as SELECT ST4ORGN_CODE, /* Se hace la consulta de los datos que se ST4ORGN_EFF_DATE, ocupan */ ST4ORGN_CODE_PRED, ST4ORGN_EFF_DATE_PRED, ST4ORGN_NOMBRE, ST4ORGN_SIGLAS FROM ST4ORGN@OPERA_PPRD;
Al ejecutarse el snapshots la tabla en el Data Warehouse tendrá todos los datos que
hasta ese momento se encontraban la base de datos operacional.
3.4.4 Con Triggers
El uso de Triggers en el proceso ETT para este ejemplo, hace necesario que las tablas del Data Warehouse puedan ser accesadas por otra base de datos, en este caso por la del sistema operacional, la actividad aquí consiste en colgar triggers, para las tres operaciones DML*, a la tabla ST4ORGN. Cada uno de los triggers hará la acción correspondiente en la tabla UNID_ORG.
El trigger a ejecutarse después de una operación de UPDATE en la tabla ST4ORGN es
el siguiente:
CREATE OR REPLACE TRIGGER UPDATE_ST4ORGN AFTER UPDATE ON ST4ORGN FOR EACH ROW DECLARE ID VARCHAR2(9); contador NUMBER(8); descrFstp VARCHAR2(30); descrFctg VARCHAR2(30); BEGIN ID := NULL; IF UPDATING ('ST4ORGN_SIGLAS') OR UPDATING('ST4ORGN_NOMBRE') OR UPDATING ('ST4ORGN_EFF_DATE_PRED') OR
/*El trigger es lanzado después de un UPDATE a la tabla SIBINST*/ /*Se revisa que se haya actualizado uno de los campos que afecta al Data Warehouse */
* Operaciones de Update, Insert o Delete en una base de datos.
28
UPDATING('ST4ORGN_CODE_PRED') THEN IF (:OLD.ST4ORGN_SIGLAS= :NEW.ST4ORGN_SIGLAS) AND (:OLD.ST4ORGN_NOMBRE = :NEW.ST4ORGN_NOMBRE) AND (:OLD.ST4ORGN_EFF_DATE_PRED = :NEW.ST4ORGN_EFF_DATE_PRED) AND (:OLD.ST4ORGN_CODE_PRED = :NEW.ST4ORGN_CODE_PRED) AND THEN NULL; ELSE UPDATE UNID_ORG SET UNID_ORG_NOMBRE = :NEW.ST4ORGN_NOMBRE, UNID_ORG_SIGLAS = :NEW.ST4ORGN_SIGLAS, UNID_ORG_CODE_PRED = :NEW.STR4ORGN_CODE_PRED, UNID_ORG_EFF_DATE_PRED = :NEW.ST4ORGN_EFF_DATE_PRED WHERE UNID_ORG_CLAVE = :NEW.ST4ORGN_CODE; END IF; END IF; EXCEPTION WHEN NO_DATA_FOUND THEN RETURN ; END; /
/*Se valida que el dato actualizado sea diferente al que se tenía*/ /*Se lleva a cabo la actualización en el Data Warehouse*/ /*Manejo de excepciones*/
29
CAPÍTULO 4. DEFINICIÓ N DEL CASO DE ESTUDIO: EL DATA WAREHOUSE DEL ÁREA DE ESCOLAR DEL TECNOLÓ GICO DE MONTERREY Y SU PROCESO ETT
La información ha tomado un papel muy importante dentro de las organizaciones y es la materia principal en la toma de decisiones, razón por la cual ésta debe ser relevante, resumida, importante y sobre todo oportuna.
El Instituto Tecnológico y de Estudios Superiores de Monterrey requiere y necesita,
como entidad educativa, toda la información relacionada con los alumnos, profesores y/o empleados, y para administrarla cuenta con el sistema de información Banner.
El Banner es un sistema de información integral especialmente desarrollado para la
administración universitaria por la Systems & Computer Technology Corp (SCT), y está compuesto por seis subsistemas que apoyan la operación universitaria, los cuales son: Administración del Portafolio de Inversiones, Administración de Ayuda Financiera a Estudiantes, Administración de la Interacción con los Exalumnos, Administración de Servicios Escolares, Administración de Recursos Financieros y Administración de Recursos Humanos. El Tecnológico de Monterrey sólo adquirió los tres últimos módulos.
El Tecnológico de Monterrey cuenta con 36 Campus en diferentes estados de la
República Mexicana; para almacenar la información que ellos generan y necesitan para su funcionamiento en los servicios escolares, los recursos financieros y los recursos humanos, existen cuatro grandes bases de datos, cada una de éstas mantiene información de cierto grupo de Campus, distribuidas por zonas geográficas. Estas bases de datos operacionales están sobre la plataforma Oracle.
Actualmente, el Tecnológico de Monterrey está trabajando en la implementación de
un Data Warehouse para los servicios escolares, con la finalidad de ofrecer a los usuarios finales únicamente la información que necesitan en el momento y formato adecuado, pero sobre todo que ésta sea de utilidad para la toma de decisiones. Para decidir esta implementación fue necesario realizar un minucioso análisis de requerimientos tanto actuales como futuros, de los usuarios finales, lo cual no fue una tarea fácil pero si muy importante para el Data Warehouse.
4.1 Los servicios escolares del Tecnológico de Monterrey en el Data Warehouse
Centrándose en el caso de estudio, los servicios escolares, para la elaboración del análisis de requerimientos primero se hizo una revisión de la información que estaba almacenada en las bases de datos operacionales, después se hizo una selección de las
30
tablas y los datos operacionales que ofrecían información útil para los usuarios finales, y por último se llevo a cabo una agrupación de datos para poder definir las estructuras que integrarían el área de escolar para el Data Warehouse.
Así pues, cuatro de las bases de datos que tiene el Tecnológico de Monterrey a nivel
rectoría, y que funcionaran como fuente de datos para poblar el Data Warehouse del área de escolar, se muestran en la parte superior de la figura 4-1. Cabe aclarar que estas cuatro bases de datos tienen el mismo modelo de datos, por lo que de todas se obtendrá el mismo tipo de información para el Data Warehouse, como se verá más adelante.
En la parte inferior de la figura 4-1 se encuentra el modelo de datos que se creo
para el Área de Escolar del Data Warehouse, como se puede ver en ella, existen 12 entidades entre las se encuentran: Alumnos, Profesores, Grupos, Alumno-Grupo, Profesor-Grupo, Escolaridades, Direcciones y Exámenes (de ubicación y admisión) por mencionar algunas.
Figura 4-1 Sistemas operacionales relacionados con el Modelo de datos del Data Warehouse del
Área de Escolar
Con el propósito de ofrecer un ejemplo completo y detallado de cómo se puede
llevar a cabo el proceso ETT, con el uso de archivo de datos, para poblar un Data Warehouse, se decidió sólo hacer uso única y exclusivamente de la tabla Profesor que
Data Warehouse
ITESM Escolar
Rectoría zona
metropoli-tana de MTY
Rectoría zona sur
Rectoría Universidad
Virtual
Rectoría zona norte
Alumno_Graduado
Alumno Inscrito
Alumno_Grupo
Horario_Grupo
Grupo
Grupo_Terminal Modalidad_Grupo
Profesor_Grupo
Profesor
Examen
Escolaridad
Direccion
31
forma del área escolar del Data Warehouse. Por lo anterior solo es necesario conocer la estructura PROFESOR y a partir de este punto sólo se hará referencia a esta tabla del modelo de datos, la cual se encuentra resaltada en la figura 4-1. Obviamente el proceso es aplicable para poblar todas las tablas que forman el Data Warehouse.
Las bases de datos de las cuatro rectorías cuentan con el mismo modelo de datos, lo
que hace que éstas contribuyan con el mismo tipo de información para alimentar la tabla Profesor. En la figura 4-2 se presenta la parte del modelo de datos operacional que se utilizó para crear la tabla PROFESOR del Data Warehouse.
Figura 4-2 Modelo de datos de la base de datos operacional utilizado para la generación de la
tabla Profesor del Data Warehouse
De manera general a continuación se indica que es lo que almacena cada una de las
entidades del modelo de datos anterior:
SI1ASGN
SIRASGN_TERM_CODESIRASGN_CRNSIRASGN_PIDMSIRASGN_CATEGORYSI1ASGN_INDICADORPAGOGRUPOSI1ASGN_FECASIGNACPROFGPOSI1ASGN_FECBAJAPROFGPOSI1ASGN_FECBAJAPAGOPROFGPOSI1ASGN_HORAS_CLASE_PAGOSI1ASGN_HORAS_LAB_PAGOSI1ASGN_USERSI1ASGN_ACTIVITY_DATE
SI1FACD
SIBFACD_PIDMSI1FACD_YRS_EXPSI1FACD_ACTIVITY_DATE
SI2CSAC
SIRASGN_TERM_CODESIRASGN_CRNSIRASGN_PIDMSIRASGN_CATEGORYSI2CSAC_CUMPLE_CRITERIO_SACSSI2CSAC_CVE_NIVEL_ACAD_SACSSI2CSAC_RESPONS_DEF_CRIT_SACSSI2CSAC_JUSTIFIC_CUMPLIMIENTOSI2CSAC_ACTIVITY_DATE
SIBINST
SIBINST_PIDMSIBINST_TERM_CODE_EFFSIBINST_FCST_CODESIBINST_FCTG_CODESIBINST_FSTP_CODESIBINST_FCNT_CODESIBINST_SCHD_INDSIBINST_ADVR_INDSIBINST_FCST_DATESIBINST_WKLD_CODESIBINST_CNTR_CODESIBINST_APPOINT_DATESIBINST_ACTIVITY_DATE
SIRASGN
SIRASGN_TERM_CODESIRASGN_CRNSIRASGN_PIDMSIRASGN_CATEGORYSIRASGN_PERCENT_RESPONSESIRASGN_WORKLOAD_ADJUSTSIRASGN_PERCENT_SESSSIRASGN_PRIMARY_INDSIRASGN_OVER_RIDESIRASGN_POSITIONSIRASGN_ACTIVITY_DATESIRASGN_FCNT_CODESIRASGN_POSNSIRASGN_SUFFSIRASGN_ASTY_CODE
SIRDPCL
SIRDPCL_PIDMSIRDPCL_TERM_CODE_EFFSIRDPCL_COLL_CODESIRDPCL_DEPT_CODESIRDPCL_HOME_INDSIRDPCL_PERCENTAGESIRDPCL_ACTIVITY_DATE
SO1DEGR
SORDEGR_PIDMSORDEGR_SBGI_CODESORDEGR_DEGC_CODESORDEGR_DEGR_SEQ_NOSO1DEGR_ESTATUSESCOLARIDADSO1DEGR_ACTIVITY_DATESO1DEGR_USERSO1DEGR_FECHA_FORMA_TITULACIONSO1DEGR_NUM_DOCTO_AMPARA_GRADOSO1DEGR_FECHA_EXPED_DOCTOAMPGRSO1DEGR_TIPO_DOCTO_AMPARA_GRAD
SORDEGR
SORDEGR_PIDMSORDEGR_SBGI_CODESORDEGR_DEGC_CODESORDEGR_DEGR_SEQ_NOSORDEGR_ATTEND_FROMSORDEGR_ATTEND_TOSORDEGR_HOURS_TRANSFERREDSORDEGR_GPA_TRANSFERREDSORDEGR_DEGC_DATESORDEGR_DEGC_YEARSORDEGR_COLL_CODESORDEGR_HONR_CODESORDEGR_ACTIVITY_DATESORDEGR_TERM_DEGREESORDEGR_EGOL_CODESORDEGR_PRIMARY_IND
SP1IDEN
SPRIDEN_PIDMSPRIDEN_IDSP1IDEN_FIRST_NAMESP1IDEN_MISP1IDEN_LAST_NAMESP1IDEN_BIRTH_DATESP1IDEN_SEARCH_FIRSTSP1IDEN_SEARCH_MIDDLESP1IDEN_SEARCH_LAST_FNSP1IDEN_SEARCH_LAST_SNSP1IDEN_SEARCH_LAST_RNSP1IDEN_SOUNDEX_LAST_FNSP1IDEN_SOUNDEX_LAST_SNSP1IDEN_SOUNDEX_LAST_RNSP1IDEN_SOUNDEX_MIDDLESP1IDEN_SOUNDEX_BIRTHSP1IDEN_FORCESIMILARSP1IDEN_USERSP1IDEN_ACTIVITY_DATESP1IDEN_SOUNDEX_FIRST
SP1PERS
SPBPERS_PIDMSP1PERS_HEIGHTSP1PERS_FECHA_MATRIMONIOST4TTRA_TITULO_TRATOSTVNATN_CODEGTVZIPC_CODE_LUGAR_NACIMIENTOGTVZIPC_CODE_LUGAR_PROCEDENCIASP1PERS_CURPSP1PERS_ACTIVITY_DATESP1PERS_USER
SP2IDEX
SPRIDEN_PIDMSP2IDEX_IDSP2IDEX_ACTIVITY_DATESP2IDEX_USER
SPBPERS
SPBPERS_PIDMSPBPERS_SSNSPBPERS_BIRTH_DATESPBPERS_LGCY_CODESPBPERS_ETHN_CODESPBPERS_MRTL_CODESPBPERS_RELG_CODESPBPERS_SEXSPBPERS_CONFID_INDSPBPERS_DEAD_INDSPBPERS_VETC_FILE_NUMBERSPBPERS_LEGAL_NAMESPBPERS_PREF_FIRST_NAMESPBPERS_NAME_PREFIXSPBPERS_NAME_SUFFIXSPBPERS_ACTIVITY_DATESPBPERS_VERA_INDSPBPERS_CITZ_INDSPBPERS_DEAD_DATESPBPERS_PINSPBPERS_CITZ_CODESPBPERS_HAIR_CODESPBPERS_EYES_CODESPBPERS_CITY_BIRTHSPBPERS_STAT_CODE_BIRTHSPBPERS_DRIVER_LICENSESPBPERS_STAT_CODE_DRIVERSPBPERS_NATN_CODE_DRIVERSPBPERS_UOMS_CODE_HEIGHTSPBPERS_HEIGHTSPBPERS_UOMS_CODE_WEIGHTSPBPERS_WEIGHTSPBPERS_SDVET_INDSPBPERS_LICENSE_ISSUED_DATESPBPERS_LICENSE_EXPIRES_DATESPBPERS_INCAR_INDSPBPERS_WEBIDSPBPERS_WEB_LAST_ACCESSSPBPERS_PIN_DISABLED_INDSPBPERS_ITIN
STVDEGC
STVDEGC_CODESTVDEGC_DESCSTVDEGC_LEVEL_ONESTVDEGC_LEVEL_TWOSTVDEGC_LEVEL_THREESTVDEGC_FA_COUNT_INDSTVDEGC_ACTIVITY_DATESTVDEGC_ACAT_CODESTVDEGC_SYSTEM_REQ_INDSTVDEGC_DLEV_CODESTVDEGC_VR_MSG_NOSTVDEGC_DISP_WEB_IND
SIBFACD
SIBFACD_PIDMSIBFACD_1ST_APPT_DATESIBFACD_RANK_CODESIBFACD_RANK_DATESIBFACD_TENR_CODESIBFACD_TENURE_DATESIBFACD_TENURE_REV_DATESIBFACD_LAST_SABB_DATESIBFACD_NEXT_SABB_DATESIBFACD_YRS_EXPSIBFACD_BIRTH_STATESIBFACD_AAUP_MEM_INDSIBFACD_ACTIVITY_DATESIBFACD_ACADEMIC_TITLESIBFACD_PRIMARY_ACTIVITYSIBFACD_DISP_CODE
SPRIDEN
SPRIDEN_PIDMSPRIDEN_IDSPRIDEN_LAST_NAMESPRIDEN_FIRST_NAMESPRIDEN_MISPRIDEN_CHANGE_INDSPRIDEN_ENTITY_INDSPRIDEN_ACTIVITY_DATESPRIDEN_USERSPRIDEN_ORIGINSPRIDEN_SEARCH_LAST_NAMESPRIDEN_SEARCH_FIRST_NAMESPRIDEN_SEARCH_MISPRIDEN_SOUNDEX_LAST_NAMESPRIDEN_SOUNDEX_FIRST_NAMESPRIDEN_NTYP_CODE
32
? SP2IDEX, tabla de identificación nómina-persona y/o identificación matricula-persona.
? SPBPERS, tabla de información básica de personas. ? SP1PERS, tabla complementaria de información básica de personas. ? SPRIDEN, tabla para identificación de personas. ? SP1IDEN, tabla complementaria para identificación de personas. ? SIRASGN, tabla de asignación Profesor-Grupos. ? SI1ASGN, tabla complementaria de la asignación profesor-grupo. ? SIBINST, tabla de personas habilitadas como profesor a partir de un ejercicio
académico. ? SIRDPCL, tabla de información de división y departamento al que pertenece un
profesor. ? SORDEGR, tabla de escolaridades a nivel universidad (grados académicos). ? SO1DEGR, tabla complementaria de las escolaridades a nivel universidad. ? STVDEGC, tabla de información general de los grados académicos. ? SIC2SAC, tabla re registro de cumplimiento SACS* por profesor-grupo. ? SIBFACD, tabla de facultad del profesor. ? SI1FACD, tabla complementaria de facultad del profesor. Para ver el detalle del diccionario de datos de las entidades que se presentan en la
figura 4-2 y que contribuyen con datos para la tabla Profesor del Data Warehouse, revisar el Anexo A.2.
4.2 Proceso ETT que se siguió en el caso de estudio
En este punto se detallara la extracción, la transformación y la transferencia de los datos desde su origen en los sistemas operaciones hasta su destino en el Data Warehouse.
Como primer punto se comenzará por conocer la estructura de la tabla PROFESOR,
en la figura 4-3 se puede ver que esta estructura cuenta con 42 campos, en ella se almacena información de tipo personal y profesional de los profesores que imparten clases por ejercicio académico, en el Instituto Tecnológico y de Estudios Superiores de Monterrey.
Esta estructura es el producto de un minucioso análisis de requerimientos y está
basada en una parte del modelo de datos de los sistemas operacionales, como ya fue mencionado en el apartado 4.1 de este documento.
* Southern Association of Colleges and Schools
33
Figura 4-3 Tabla Profesor del Data Warehouse del área de escolar.
En la siguiente tabla 4-1 se despliega el diccionario de datos de la estructura
Profesor, que contiene información de profesores activos para un determinado ejercicio académico.
Nombre del Campo Descripción
clave_campus clave con el que se identifica al campus nombre_campus nombre del campus siglas_campus abreviatura del campus clave_ejercicio_academico clave del ejercicio académico procesado desc_ejercicio_academico ejercicio académico procesado clave_ejercicio_academico_efec clave del ejercicio académico efectivo del profr. desc_ejercicio_academico_efec ejercicio académico efectivo del profesor clave_persona identificador único del profesor nomina nomina del profesor apellido_paterno_profesor apellido paterno del profesor apellido_materno_profesor apellido materno del profesor nombre_profesor nombre del profesor titulo_trato_profesor titulo para trato de una persona clave_division_pertenece_prof clave de la división acad. asociada al profesor desc_division_pertenece_pr división académica a la que pertenece el profesor siglas_division_pertenece_prof siglas de la división acad. asociada al profesor clave_depto_pertenece_prof clave del depto. acad. asociado al profesor desc_depto_pertenece_prof depto. acad. al que pertenece el profesor
PROFESOR
CLAVE_CAMPUSNOMBRE_CAMPUSSIGLAS_CAMPUSCLAVE_EJERCICIO_ACADEMICODESC_EJERCICIO_ACADEMICOCLAVE_EJERCICIO_ACADEMICO_EFECDESC_EJERCICIO_ACADEMICO_EFECCLAVE_PERSONANOMINAAPELLIDO_PATERNO_PROFESORAPELLIDO_MATERNO_PROFESORNOMBRE_PROFESORTITULO_TRATO_PROFESORCLAVE_DIVISION_PERTENECE_PROFDESC_DIVISION_PERTENECE_PROFSIGLAS_DIVISION_PERTENECE_PROFCLAVE_DEPTO_PERTENECE_PROFDESC_DEPTO_PERTENECE_PROFCLAVE_CATEGORIA_LABORALDESC_CATEGORIA_LABORALCLAVE_CLASIFICACION_DOCENTEDESC_CLASIFICACION_DOCENTECLAVE_GRADO_MAXIMO_PROFDESC_GRADO_MAXIMO_PROFPERIODOS_EXPERIENCIA_PROFDOCTORADO_ITESMMAESTRIA_ITESMALGUN_GRADO_ITESMESTUDIA_DOCTORADO_ITESMESTUDIA_MAESTRIA_ITESMESTUDIA_DOCTORADO_FUERA_ITESMESTUDIA_MAESTRIA_FUERA_ITESMESTATUS_ACTIVIDAD_PROFESORIMPARTE_MATERIA_PLAN_ESTUDIOSCLAVE_MODALIDAD_PGMA_ALUM_PROFDESC_MODALIDAD_PGMA_ALUM_PROFCLAVE_MODALIDAD_GRUPOS_PROFDESC_MODALIDAD_GRUPOS_PROFESTATUS_CARGA_PROFESORFECHA_ALTA_REGISTROFECHA_ULTIMA_MODIFICACION
34
clave_categoria_laboral clave de la categoría laboral asignada al profesor desc_categoria_laboral categoría laboral del profesor clave_clasificacion_docente clave de la clasificación docente del profesor desc_clasificacion_docente clasificación docente del profesor clave_grado_maximo_prof clave del grado máximo del profesor desc_grado_maximo_prof grado máximo del profesor periodos_experiencia_prof periodos de experiencia del profesor doctorado_itesm indica si el profesor tiene un grado de doctorado
terminado en un campus del ítems maestria_itesm indica si el profesor tiene un grado de maestría
terminado en un campus del ítems licenciatura_itesm indica si el profesor tiene un grado de
licenciatura terminado en un campus del ITESM algun_grado_itesm indica si el profesor tiene un grado terminado en
un campus del ítems estudia_doctorado_itesm indica si el profesor estudia un doctorado en un
campus del ítems estudia_maestria_itesm indica si el profesor estudia una maestría en un
campus del ítems estudia_doctorado_fuera_itesm indica si el profesor estudia un doctorado en una
institución que no es un campus del ITESM estudia_maestria_fuera_itesm indica si el profesor estudia una maestría en una
institución que no es un campus del ítems estatus_actividad_profesor estatus de actividad del profesor en el ejercicio
académico imparte_materia_plan_estudios indica si el profesor imparte materias oficial clave_modalidad_pgma_alum_prof clave de la modalidad de la mayoría de los
alumnos inscritos en los gpo que imparte el prof. desc_modalidad_pgma_alum_prof modalidad de la mayoría de los alumnos inscritos
en los grupos que imparte el profesor clave_modalidad_grupos_prof clave de la modalidad de la mayoría de los grupos
que imparte el profesor desc_modalidad_grupos_prof modalidad de la mayoría de los grupos que
imparte el profesor estatus_carga_profesor estatus de ultima carga de los datos de esta tabla fecha_alta_registro Fecha de alta del registro por primera vez fecha_ultima_modificacion fecha de modificación del registro por última vez
Tabla 4-1 Diccionario de datos de la estructura Profesor.
Como se vio en el capítulo dos, antes de realizar el proceso ETT es necesario saber
cuáles son los datos operacionales a extraer y el origen de estos, en la tabla 4-2 se indica el origen que cada campo de la tabla Profesor tiene en el sistema operacional fuente.
Nombre Columna en la
tabla Profesor Nombre Columna de la tabla
fuente Tabla origen
CLAVE_CAMPUS STVCAMP_CODE STVCAMP
35
NOMBRE_CAMPUS STVCAMP_DESC STVCAMP SIGLAS_CAMPUS ST1CAMP_ABREVIATURA ST1CAMP CLAVE_EJERCICIO_ACADEMICO SIRASGN_TERM_CODE SIRASGN DESC_EJERCICIO_ACADEMICO STVTERM_DESC STVTERM CLAVE_EJERCICIO_ACADEMICO_EFEC SIBINST_TERM_CODE_EFF SIBINST DESC_EJERCICIO_ACADEMICO_EFEC STVTERM_DESC STVTERM CLAVE_PERSONA SIRASGN_PIDM SIRASGN NOMINA SP2IDEX_ID SP2IDEX APELLIDO_PATERNO_PROFESOR SP1IDEN_FIRST_NAME SP1IDEN APELLIDO_MATERNO_PROFESOR SP1IDEN_MI SP1IDEN NOMBRE_PROFESOR SP1IDEN_LAST_NAME SP1IDEN TITULO_TRATO_PROFESOR ST4TTRA_TITULO_TRATO SP1PERS CLAVE_DIVISION_PERTENECE_PROF SIRDPCL_COLL_CODE SIRDPCL DESC_DIVISION_PERTENECE_PROF STVCOLL_DESC STVCOLL SIGLAS_DIVISION_PERTENECE_PROF ST4ORGN_SIGLAS ST4ORGN CLAVE_DEPTO_PERTENECE_PROF SIRDPCL_DEPT_CODE SIRDECL DESC_DEPTO_PERTENECE_PROF STVDEPT_DESC STVDEPT CLAVE_CATEGORIA_LABORAL SIBINST_FCTG_CODE SIBINST DESC_CATEGORIA_LABORAL STVFCTG_DESC STVFCTG CLAVE_CLASIFICACION_DOCENTE SIBINST_FSTP_CODE SIBINST DESC_CLASIFICACION_DOCENTE STVFSTP_DESC STVFSTP CLAVE_GRADO_MAXIMO_PROF MAX(STVDEGC_DLEV_CODE)
en el join JOIN STVDEGC, SORDEGR
DESC_GRADO_MAXIMO_PROF STVDEGC_DESC STVDEGC PERIODOS_EXPERIENCIA_PROF SI1FACD_YRS_EXP SI1FACD DOCTORADO_ITESM SI o NO MAESTRIA_ITESM SI o NO LICENCIATURA_ITESM SI o NO ALGUN_GRADO_ITESM SI o NO ESTUDIA_DOCTORADO_ITESM SI o NO ESTUDIA_MAESTRIA_ITESM SI o NO ESTUDIA_DOCTORADO_FUERA_ITESM SI o NO ESTUDIA_MAESTRIA_FUERA_ITESM SI o NO
JOIN SO1DEGR, STVDEGC
ESTATUS_ACTIVIDAD_PROFESOR Activo o Inactivo JOIN SIRASGN, SSBSECT
IMPARTE_MATERIA_PLAN_ESTUDIOS SI o NO JOIN SSBSECT, SMRARUL
CLAVE_MODALIDAD_PGMA_ALUM_PROF SGBSTDN_SESS_CODE JOIN SGBSTDN, SFRSTCR, SIRASGN
DESC_MODALIDAD_PGMA_ALUM_PROF STVSESS_DESC STVSESS CLAVE_MODALIDAD_GRUPOS_PROF SSBSECT_SESS_CODE JOIN SSBSECT,
SIRASGN DESC_MODALIDAD_GRUPOS_PROF STVSESS_DESC STVSESS
Tabla 4-2 Origen de los datos para la tabla Profesor
36
Igualmente para apoyar el proceso ETT, en el documento de análisis de requerimientos para la tabla Profesor se explica detalladamente la forma para obtener cada uno de los campos; además, en caso de que la base de datos operacional tena inconsistencias o ausencia de información que es requerida para la tabla Profesor en el Data Warehouse, se indica como tratar el error y el valor que debe ser asignado al campo, en caso de que se presente alguna de esas situaciones.
Para cada uno de los campos que forman la tabla Profesor, existe un apartado como
el que se muestra en la tabla 4-3 para el campo CLAVE_CAMPUS.
Nombre del campo: Clave_campus Caso esperado: Campus en que el profesor tiene (o el que tuvo
en la temporalidad del term) clases asignadas. Si el profesor imparte clases en más de un campus entonces deberá existir una línea por cada campus-profesor.
Ejemplo: A PETICIÓ N: Se requiere que el profesor esté asociado a un
campus o a una serie de campus. (Porque puede impartir clases en diferentes campus y para diferentes divisiones o departamentos).
Razones para tener *: Caso no se presenta. Razones para tener vacío: Caso no se presenta. Motivos de error: Caso no se presenta. Tabla 4-3 Ejemplo de dónde y cómo obtener los posibles valores para el campo CLAVE_CAMPUS
de la tabla Profesor del Data Warehouse
El apartado para cada campo contiene cinco indicaciones que son: 1. Nombre del campo: indica cual es el nombre con el que está identificado el
campo en la tabla del Data Warehouse. 2. Caso Esperado: indica qué es lo que espera que contenga el campo,
descriptivamente y con un ejemplo. 3. Razones para tener *: indica las condiciones que se deben cumplir para que un
campo tenga como valor asignado un *. El asterisco (*) se utiliza para indicar que el campo que se desea obtener tiene algún error, ya sea de inconsistencias en la base de datos, un valor mal capturado o registro inexistente cuando debería existir.
4. Razones para tener vacío: indica las condiciones que se deben cumplir para que un campo tenga como valor Nulo.
5. Motivos de error: indica cuándo algún dato es considerado como error y el valor que se le debe asignar, en este caso los valores únicamente pueden ser un * o un Nulo.
En el anexo A.3 se encuentran las indicaciones para obtener cada uno de los campos
de la tabla Profesor, lo que representa cada uno y la forma de tratar los posibles errores, como el ejemplo de la tabla 4-3.
37
Lo anteriormente descrito corresponde a la actividad previa al inicio del proceso ETT, es decir a la obtención de los datos operacionales, ahora se mencionará cómo se lleva a cabo la extracción, la transformación y la transferencia de los datos de los sistemas operacionales a la tabla Profesor del Data Warehouse.
El hecho de tener cuatro sistemas operaciones fuente, para alimentar el Data
Warehouse, que comparten el mismo modelo de datos y que funcionan de igual manera en las cuatro rectorías, permite realizar el proceso ETT cómo si sólo existiera una base de datos fuente, es decir, no es necesario hacer extracciones, transformaciones y transferencias de datos diferentes para cada base de datos, un sólo proceso ETT aplica para las cuatro.
El proceso ETT que se describirá a continuación es utilizando la técnica secuencial
con uso de archivos de datos.
4.2.1 Extracción y Transformación
Como primer paso del proceso ETT está la extracción de los datos, para ello se hizo uso de la programación computacional, se desarrollo el programa de extracción y transformación de datos en lenguaje Pro*C (Lenguaje C++ y SQL Standard Query Language), en él se hicieron los queries necesarios para extraer los datos requeridos y especificados en la tabla 4-2.
El mismo programa contiene el código necesario para transformar los datos que
tengan alguna indicación de cambio, por ejemplo, cuando un dato obtenido del sistema operacional no se ocupa tal como está almacenado o cuando un dato para el Data Warehouse se genera de la combinación de los resultados de varias consultas y condiciones realizadas en el sistema operacional.
Una vez que los datos obtenidos ya están como el Data Warehouse los espera, son
escritos en archivos de datos. En los archivos de datos se escribe un renglón por cada registro a insertar o actualizar en la tabla Profesor, y cada registro tiene separados sus datos en campos utilizando el símbolo (|), se decidió el uso de este símbolo para separar los campos de cada registro debido a que no es común que éste forme parte de algún dato alfanumérico almacenado en los sistemas operacionales.
El código fuente de la función, programada en Pro*C, para realizar la extracción y
transformación de los datos del sistema operacional fuente a la tabla Profesor del Data Warehouse, se agrego en el anexo A.4.
Esta parte del proceso ETT se puede llevar a cabo de manera simultánea en las
cuatro bases de datos y se debe de ejecutar para cada uno de los campus existentes en los sistemas operacionales fuente, debido a que en una base de datos existe más de un Campus y todos pueden realizar la extracción de los datos al mismo tiempo, el nombre del archivo salida de datos se crea con un nombre particular que se forma con la concatenación de las siguientes cadenas de caracteres:
[Campus][Usuario].DatosDWH_Profesores_[Ejercicio Académico].dat
38
En dónde Campus es un parámetro de entrada que se solicita al momento de ejecutar el programa y además identifica a que Campus pertenecen los datos del archivo, Usuario es el login de la persona que ejecutó el programa, DatosDWH_Profesores es propiamente el nombre del archivo, para identificar fácilmente que pertenece a una extracción de datos, Ejercicio Académico también es un parámetro de entrada que se agrega al nombre del archivo para identificar de que periodo académico son los datos, y por último se tiene la extensión .dat para identificar que es un archivo de datos. Con este nombre de archivo compuesto por varios datos se evita el riesgo de sobrescribir los archivos cuando los parámetros de entrada son diferentes.
El archivo de datos tiene como encabezado, en el primer renglón, el nombre de los
campos de la tabla Profesor del Data Warehouse, cada uno separado por el símbolo (|), después del encabezado están todos los datos que cumplieron con las condiciones de la extracción y que deberán ser insertados en el Data Warehouse, como ya se menciono cada renglón representa un registro y cada símbolo (|) representa un campo, en la figura 4-4 se muestra una parte del contenido de un archivo de datos que se genera para PROFESOR.
Figura 4-4 Ejemplo del contenido del archivo de datos de Profesores
Este programa de extracción y transformación, actualmente se ejecuta una vez al
día, generalmente por la noche para no afectar el desempeño de la base de datos operacional.
Culminada la extracción y transformación de los datos del sistema operacional
fuente sigue el proceso de transferencia de datos y para la ejecución de éste es necesario del archivo generado con la extracción, el cual está localizado en cualquiera de las cuatro máquinas, dependiendo del campus para el que se haya procesado la información:
? Info1, máquina donde está la base de datos de la rectoría zona metropolitana de
monterrey, físicamente está en Monterrey. ? Rmx, máquina donde está la base de datos de la rectoría zona sur, físicamente está
en Estado de México.
39
? Rzn, máquina donde está la base de datos de la rectoría zona norte, físicamente está en Torreón.
? Ruv, máquina donde está la base de datos de la rectoría universidad virtual, físicamente está en Monterrey
El archivo de datos tiene que ser enviado a la máquina Indacad-44p, que es donde se
encuentra la base de datos del Data Warehouse, para poder continuar con la transferencia y/o la carga de datos. El envío se hace a través de FTP (File Transfer Protocol).
4.2.2 Transferencia
Para la transferencia de los datos al Data Warehouse, se desarrolla un programa computacional en Pro*C para insertar y/o actualizar la información en la tabla Profesor, dicho programa hace uso del archivo de datos generado con el proceso de extracción y transformación.
El programa lee renglón por renglón cada registro y busca en la base de datos el
registro que cumpla con los datos de los campos llaves, si se encuentra el registro entonces se hace una actualización de los campos restantes, sino se hace la inserción del nuevo registro.
Este programa genera dos archivos de salida, el primero es el archivo de descartes,
que contiene los registros que causaron algún error al momento de hacer la carga de los datos. Identificado con el siguiente nombre:
[campus][usuario].ErroresDWH_Profesores_[Ejercicio Académico].err El segundo archivo es de control, que contiene el resumen de las operaciones que
realizaron, total de registros insertados, total de registros actualizados, total de registros con error. El nombre del archivo es igual al archivo de descartes, sólo con extensión diferente.
[campus][usuario].ControlDWH_Profesores_[Ejercicio Académico].ctl La creación del nombre de estos archivos, se hace de la misma manera que con el
nombre de archivo de datos utilizado en la extracción, únicamente cambiando la palabra Datos por Errores Control y la extención .dat por .err y .ctl, respectivamente para el archivo de errores y el archivo de control.
Después de que los archivos de datos ya se encuentran en la máquina Indacad-44p se
procede a la ejecución del programa computacional de carga de datos. En el anexo A.5 se muestra el código fuente de la función que se programo para hacer la carga de datos.
La transferencia y carga de los datos se debe realizar con una base de datos a la vez
y en el orden siguiente, primero se cargan los datos pertenecientes a los campus de la rectoría de la zona metropolitana de Monterrey, después los de la rectoría zona sur, enseguida la rectoría zona norte y por último se cargan los datos de la rectoría
40
universidad virtual. El motivo por el que se sigue este orden es porque hay profesores que imparten clases en más de un campus.
Este proceso de extracción, transformación y transferencia de datos de las bases de
datos operacionales al Data Warehouse se realiza diariamente, en la noche se lleva a cabo la extracción y transformación y por la mañana se hace la transferencia.
Para la extracción y transformación, cada rectoría define si una persona estará
encargada de ejecutar el programa para todos los campus de esa rectoría, o si en cada campus existirá una persona encargada de realizar esta actividad día con día.
En la transferencia de los datos, hay dos personas encargadas. El desarrollo del proceso ETT utilizando programación y archivos de datos, requiere
de mucho tiempo para su ejecución, en el caso del Data Warehouse del área de escolar del Instituto Tecnológico y de Estudios Superiores, debido a que diariamente se está bajando la información necesaria, aunque los datos no hayan sufrido algún cambio durante el día, y estos son reemplazados de igual manera en el Data Warehouse por medio del proceso de carga de datos.
Lo descrito en este capítulo es la forma cómo se tiene planeado y se está llevando a
cabo el proceso ETT actualmente, en el área de escolar del Data Warehouse del Tecnológico de Monterrey, en el cual se participa directamente.
4.3 Pruebas realizadas
Para definir las ventajas, desventajas y poder hacer la comparación entre el proceso ETT con uso de archivos de datos y con uso de Triggers en combinación con Snapshots, se llevaron acabo una serie de pruebas, durante el periodo de octubre de 2002 a abril del 2003, en la base de datos correspondiente a la Rectoría de la zona metropolitana de Monterrey.
El programa de extracción se ejecutó a diferentes horas del día para diferentes
Campus, y se encontró lo siguiente: ? El tiempo de procesamiento es mayor en los horarios intermedios de oficina, entre
10:00 am y 5:00 pm, esto indica que el sistema operacional tiene bastante actividad durante la mañana-tarde. Esta fue una de las razones por la que se decidió hacer la extracción de datos por las noches.
? El tiempo promedio en extraer 1500 registros en la mañana fue de dos horas y media, en la tarde de dos horas y en la noche de una hora y media.
? El tiempo promedio de transferir 1500 registros al Data Warehouse fue de media hora.
? El promedio de inserciones es bajo. ? Generalmente la inserción de registros nuevos se antes de iniciar un nuevo periodo
escolar.
41
? De los 1500 registros, en promedio el 1% sufrió algún cambio en el rango de una semana entre una extracción y otra; esto se debe a que los datos, necesarios para el Data Warehouse, de una persona como profesor no son muy cambiantes.
El programa de transferencia se ejecutó únicamente en la mañana porque es la hora
en la que para el caso de estudio, el Data Warehouse tiene menos actividad. Se hicieron las correspondientes cargas de información con los archivos generaos con la extracción y se encontró lo siguiente:
? El periodo de tiempo en el que el Data Warehouse del área de escolar del
Tecnológico de Monterrey tiene menos actividad es por la mañana, razón por la que las cargas se hacen en durante ese periodo.
? El tiempo promedio de transferir 1500 registros al Data Warehouse fue de media hora.
? La ejecución del proceso de transferencia ayudo a detectar y corregir fallas en el programa de extracción.
42
CAPÍTULO 5. COMBINACIÓ N DE TRIGGERS Y SNAPSHOTS PARA EL PROCESO ETT
En este capítulo se hablará sobre el uso de Triggers y Snapshots como alternativa de actualización del Data Warehouse, que pretende ofrecer una mejora en el tiempo y en el procedimiento utilizado para la Extracción, Transformación y Transferencia (ETT) de datos del sistema operacional fuente al Data Warehouse del área de Escolar del Instituto Tecnológico y de Estudios Superiores de Monterrey.
Como se mencionó en el capítulo anterior, actualmente la forma como se lleva a
cabo el proceso ETT del Data Warehouse de Escolar del Tecnológico de Monterrey es a través de programación computacional utilizando el lenguaje Pro*C (Lenguaje de programación C++ y Standard Query Language SQL). Existen dos programas computacionales, uno para extraer y transformar los datos del sistema operacional fuente y otro para transferir esos datos al Data Warehouse, el primer programa se ejecutan una vez al día por cada campus que existe, generalmente esta acción se lleva a cabo por la noche para no incurrir en el desempeño de las máquinas de los sistemas operacionales, en horas de oficina.
Con la finalidad de centralizar en el Data Warehouse, datos depurados y correctos
procedentes de varias instancias de bases de datos, como se hace con la programación computacional; en este documento se realiza el proceso ETT con el uso combinado de triggers y Snapshots.
A continuación se describirán cada uno de los pasos que se realizaron para llevar a
cabo el proceso ETT de la manera propuesta.
5.1 Explicación general del Proceso ETT que se propone con una combinación de Triggers y Snapshots.
El mantener continuamente actualizados los datos en el Data Warehouse del área de escolar del Tecnológico de Monterrey es una de las razones por las que el proceso ETT con uso de archivos se lleva a cabo diariamente, sin embargo, esto puede llegar a ser una tarea repetitiva e 3y por el volumen de datos que se maneja, incluso hasta puede ser tardada.
Lo que se propone para extraer sólo los datos que sufrieron algún cambio en el
sistema operacional fuente, y por consecuencia transformar y transferir únicamente esos datos al Data Warehouse, es lo siguiente:
43
? Crear en las bases de datos operacionales de cada rectoría y en la base de datos del Data Warehouse, una tabla idéntica a la tabla Profesor, pero llamada dwh_profesor.
? Hacer triggers que sean disparados por las tablas del sistema operacional fuente, que están directamente relacionadas con los datos que se debe tener en el Data Warehouse, y que se encarguen de la actualización de la tabla dwh_profesor de cada rectoría.
? Hacer un trigger para concentrar las actualizaciones, de las cuatro tablas dwh_profesor creadas para cada base de datos de las cuatro rectorías, en la tabla dwh_profesor creada en la misma máquina que el Data Warehouse.
? Crear el Snapshot y Snapshot Log en la máquina del Data Warehouse, para poblar la tabla profesor, con los datos concentrados en la tabla dwh_profesor y que tengan registro en el Snapshot Log de que sufrieron algún cambio
Figura 5-1 Representación gráfica de lo que se propone para llevar a cabo el proceso ETT con una
combinación del uso de Snapshots y Triggers
En la figura 5-1, se muestra de manera gráfica lo que se propone. La creación de los
triggers en las tablas que ya existían en el modelo de datos del sistema operacional, permitirán la actualización de los datos en la tabla dwh_profesor, ésta última también creada como parte de lo que se propone, a través de un trigger asociado a ella, a su vez, actualizará la tabla dwh_profesor que se encuentra en la base de datos del Data Warehouse y la cual se creó con el propósito de concentrar los registros originados en cada base de datos operacional antes de que sean cargados en el Data Warehouse y sobre todo para registrar los descartes o errores que se pudieran presentar con la ejecución del trigger. Finalmente el Snapshot propuesto, haciendo uso del Snapshot Log
Bases de datos operacionales
ITESM
Data Warehouse ITESM
Agregados propuestos
SP1IDEN
SP1PERS
SIBINST
SO1DEGR
SI1FACD
Crea
r tr
igge
r qu
e se
eje
cute
n de
spué
s de
la a
ctua
lizac
ión
de
esta
s ta
blas
.
DWH_PROFESOR
Crear la siguiente estructura y un trigger que se accione después
después de su actualización
Crear la estructura DWH_PROFESOR
La tabla DWH_PROFESOR concentrará los datos y se mantendrá actualizada con cada uno de los trigger que se crearan en las bases de datos operacionales.
PROFESOR
Snapshot de la tabla DWH_PROFESOR para mantener actualizada la tabla Profesor el Data Warehouse
44
detectará los registros de la tabla dwh_profesor que tuvieron algún cambio para copiar esos registros a la tabla Profesor.
La forma que se propone para hacer uso de Triggers y Snapshots, como técnica
incremental, en el proceso ETT del Data Warehouse del área de escolar, es debido al volumen de información que se maneja, a la forma como están distribuidos los sistemas operacionales y sobre todo a la necesidad de poder detectar los conflictos o colisiones entre la información de una base de datos operacional y otra, antes de que los datos sean cargados en el Data Warehouse.
5.2 Cambios estructurales al Data Warehouse del área de escolar del Tecnológico de Monterrey.
Una vez que se determinó la posibilidad de obtener las actualizaciones de los datos requeridos en el Data Warehouse sin necesidad de ejecutar los programas computacionales de extracción, transformación y transferencia diariamente, se realizaron algunos cambios y adecuaciones a las estructuras de las tablas. En este caso particular, al igual que en el capítulo 4, se hablará de lo que se hizo en relación con la tabla Profesor del Data Warehouse para que ésta pudiera ser actualizada a través de Snapshots.
Se adecuó el análisis de requerimientos que se utilizó en el proceso ETT con el uso
de archivos para utilizarlo en el proceso ETT con uso de triggers y Snapshots. La tabla Profesor del Data Warehouse inicialmente tenía 42 campos, para almacenar
información personal y profesional de los profesores activos en un ejercicio académico determinado. Para la implementación del proceso ETT ya mencionado, es necesario redefinir la estructura de dicha tabla que consiste en eliminar 14 campos de ella, esto con la finalidad de que la tabla Profesor guarde información de las personas habilitadas como profesor a partir de un ejercicio académico. Así pues algunos campos se deben eliminar porque no son propios de la tabla Profesor, como entidad y otros porque la extracción de la información, como se mencionó antes, ya no será para un ejercicio académico determinado; en la figura 5-2 (a) se muestra la estructura de la tabla Profesor original y en la (b) la nueva estructura que se propone.
Los campos CLAVE_EJERCICIO_ACADEMICO y DESC_EJERCICIO_ACADEMICO se deben
eliminar porque en ellos se almacena la clave y descripción del ejercicio académico de ejecución, respectivamente, de los programas computacionales. Con el uso de triggers esta información ya no es necesaria, debido a que no se requiere programar la ejecución de un proceso, sino que esto se lleva cabo en el momento justo de la actualización.
Los campos CLAVE_DIVISION_PERTENECE_PROF, DESC_DIVISION_PERTENECE_PROF,
SIGLAS_DIVISION_PERTENECE_PROF, CLAVE_DEPTO_PERTENECE_PROF y DESC_DEPTO_ PERTENECE_PROF también deben ser eliminados debido a una redefinición en el sistema operacional fuente, ya que actualmente el profesor puede tener más de un departamento asignado a él para un Campus. Al dejar los campos anteriores en la tabla
45
Profesor del Data Warehouse ocasionaría repetición de información por lo que se optó por generar otra tabla para almacenar dicha información.
Figura 5-2 Tabla Profesor del Data Warehouse
Los campos ESTATUS_ACTIVIDAD_PROFESOR, IMPARTE_MATERIA_PLAN_ESTUDIOS,
CLAVE_MODALIDAD_PGMA_ALUM_PROF, DESC_MODALIDAD_PGMA_ALUM_PROF, CLAVE_ MODALIDAD_GRUPOS_PROF y DESC_MODALIDAD_GRUPOS_PROF almacenan información propia de la relación de un profesor con los grupos que imparte, por lo que en realidad no son atributos de un profesor como tal y no deben de estar en la tabla Profesor.
Después de haber hecho la redefinición de la estructura de la tabla Profesor del Data
Warehouse, se creó una copia idéntica de dicha tabla en cada uno de los sistemas operacionales fuente para que en ella se guarden todas las actualizaciones e inserciones que surjan en el sistema operacional, dicha tabla fue nombra DWH_PROFESOR.
Realizar el proceso ETT con el uso de Snapshots, para que sólo se actualicen los
datos de las tablas del Data Warehouse, que han sufrido algún cambio en el correspondiente dato del sistema operacional fuente, y que esto no afecte el desempeño de la base de datos fuente considerablemente, hace necesario recurrir al uso de triggers.
PROFESOR
CLAVE_CAMPUSNOMBRE_CAMPUSSIGLAS_CAMPUSCLAVE_EJERCICIO_ACADEMICODESC_EJERCICIO_ACADEMICOCLAVE_EJERCICIO_ACADEMICO_EFECDESC_EJERCICIO_ACADEMICO_EFECCLAVE_PERSONANOMINAAPELLIDO_PATERNO_PROFESORAPELLIDO_MATERNO_PROFESORNOMBRE_PROFESORTITULO_TRATO_PROFESORCLAVE_DIVISION_PERTENECE_PROFDESC_DIVISION_PERTENECE_PROFSIGLAS_DIVISION_PERTENECE_PROFCLAVE_DEPTO_PERTENECE_PROFDESC_DEPTO_PERTENECE_PROFCLAVE_CATEGORIA_LABORALDESC_CATEGORIA_LABORALCLAVE_CLASIFICACION_DOCENTEDESC_CLASIFICACION_DOCENTECLAVE_GRADO_MAXIMO_PROFDESC_GRADO_MAXIMO_PROFPERIODOS_EXPERIENCIA_PROFDOCTORADO_ITESMMAESTRIA_ITESMALGUN_GRADO_ITESMESTUDIA_DOCTORADO_ITESMESTUDIA_MAESTRIA_ITESMESTUDIA_DOCTORADO_FUERA_ITESMESTUDIA_MAESTRIA_FUERA_ITESMESTATUS_ACTIVIDAD_PROFESORIMPARTE_MATERIA_PLAN_ESTUDIOSCLAVE_MODALIDAD_PGMA_ALUM_PROFDESC_MODALIDAD_PGMA_ALUM_PROFCLAVE_MODALIDAD_GRUPOS_PROFDESC_MODALIDAD_GRUPOS_PROFESTATUS_CARGA_PROFESORFECHA_ALTA_REGISTROFECHA_ULTIMA_MODIFICACION
(a) estructura anterior (b) estructura generada para el uso de triggers y snapshots
Campos que se eliminan de la tabla profesor
original.
PROFESOR
CLAVE_CAMPUSNOMBRE_CAMPUSSIGLAS_CAMPUSCLAVE_EJERCICIO_ACADEMICOCLAVE_EJERCICIO_ACADEMICO_EFECDESC_EJERCICIO_ACADEMICO_EFECCLAVE_PERSONANOMINAAPELLIDO_PATERNO_PROFESORAPELLIDO_MATERNO_PROFESORNOMBRE_PROFESORTITULO_TRATO_PROFESORCLAVE_DIVISION_PERTENECE_PROFCLAVE_CATEGORIA_LABORALDESC_CATEGORIA_LABORALCLAVE_CLASIFICACION_DOCENTEDESC_CLASIFICACION_DOCENTECLAVE_GRADO_MAXIMO_PROFDESC_GRADO_MAXIMO_PROFPERIODOS_EXPERIENCIA_PROFDOCTORADO_ITESMMAESTRIA_ITESMALGUN_GRADO_ITESMESTUDIA_DOCTORADO_ITESMESTUDIA_MAESTRIA_ITESMESTUDIA_DOCTORADO_FUERA_ITESMESTUDIA_MAESTRIA_FUERA_ITESMESTATUS_ACTIVIDAD_PROFESORIMPARTE_MATERIA_PLAN_ESTUDIOSCLAVE_MODALIDAD_PGMA_ALUM_PROF
FECHA_ALTA_REGISTROFECHA_ULTIMA_MODIFICACION
56
CAPÍTULO 6. RESULTADOS OBTENIDOS
Como se ha mencionado en capítulos anteriores, para efectos de este trabajo se analizó el proceso ETT a través de archivos de datos y se llevó a cabo la implementación del mismo haciendo uso de una combinación de Snapshots y Triggers. Para ello se utilizó la documentación existente sobre la implementación del Data Warehouse del Tecnológico de Monterrey, y se enfocó en sólo una parte del área de servicios escolares para realizar pruebas y poder hacer las comparaciones pertinentes.
Después de haber llevado a la práctica uno de los procesos más importantes, que en
ocasiones determina el éxito o fracaso del Data Warehouse, se puede decir que el proceso ETT realmente es uno de los que requiere más tiempo en toda la implementación de un Data Warehouse, y que una adecuada elección de la técnica para desarrollarlo depende de todo el trabajo que se haya realizado previo a él, como lo es el modelo de datos, el análisis de requerimientos, la información de los sistemas operacionales fuente, así como las características propias del sistema del Data Warehouse.
Todos los procesos y en especial el ETT, deben estar acompañados de una
administración responsable, robusta y en un ambiente seguro para evitar corrupción o violación en los datos, ya que estos son la materia prima y más valiosa de un Data Warehouse. El proceso ETT involucra la extracción de los datos desde su ambiente actual para transformaros y transferirlos a un modelo de datos que sea amigable para el usuario final.
6.1 Proceso ETT utilizando archivos de datos
Como se mencionó en el capítulo tres, el uso de archivos de datos para extraer, transformar y transferir información, resulta una técnica accesible para la mayoría de las implementaciones de un Data Warehouse, y dicha técnica es la que se emplea en el Tecnológico de Monterrey.
Al estudiar las tres actividades que forman parte del proceso ETT, es decir, la
extracción, la transformación y la transferencia de los datos, se detectaron los siguientes puntos importantes:
? Para realizar el programa computacional de extracción y transformación es
necesario que, como parte del documento de análisis o como un documento extra, se disponga de la información del origen (campo-tabla) de cada uno de los datos que van a ser extraídos, asimismo las consideraciones o condiciones que se deben cumplir para que los datos que lo requieran sean transformados en datos útiles cuando el dato que provee el sistema operacional no lo es.
57
? Cada uno de los queries que se programa, debe ser optimizado en la medida de lo posible con el fin de no afectar el desempeño de los sistemas operacionales. Es recomendable hacer los queries tomando en cuenta los índices de las tablas para que no se tenga que hacer un barrido completo de las mismas, así se minimiza el tiempo de acceso y overhead en el sistema operacional fuente.
? El programa de transferencia de los datos al Data Warehouse debe estar preparado para recibir los datos tal como se generan en la extracción.
? La ejecución del programa de extracción de datos se puede hacer de forma automática, aprovechando los recursos de puedan ofrecer los sistemas operativos; por ejemplo se puede hacer uso del comando “at” de unix en caso de trabajar con éste.
? Al hacer la ejecución automática del proceso de transferencia y carga de los datos, se asume que los archivos de los datos extraídos ya están en la máquina del Data Warehouse, ya que de no encontrarse se tendría que verificar qué datos fueron los que no se pasaron al Data Warehouse.
Realizar el proceso ETT con el uso de archivos de datos, resulta una tarea fácil para
el desarrollador y/o personas encargadas de este proceso, principalmente porque sólo implica conocer y saber programar en un lenguaje que sea soportado por lo sistemas operacionales fuente y por el Data Warehouse.
6.1.1 Ventajas
Al estudiar del proceso ETT con uso de archivos de datos en una parte del Data Warehouse del área de Escolar del Tecnológico de Monterrey y como miembro del equipo de desarrollo del proceso ETT en el mismo, se observaron las siguientes ventajas.
? Es fácil de implementar debido a que no se necesita hacer cambios o agregados
estructurales en los sistemas operacionales ni en el Data Warehouse. ? Se puede realizar al mismo tiempo en todos los sistemas operacionales, es decir,
simultáneamente. ? Se puede programar su ejecución automática. ? Los sistemas operacionales fuente sólo se usan para la extracción de datos, es decir
únicamente se hacen queries en ellos.
6.1.2 Desventajas
Al participar directamente en el proceso ETT que se realiza actualmente para el Data Warehouse del área de escolar del Tecnológico de Monterrey, se detectaron algunas desventajas con el uso de archivos de datos, mismas que a continuación se enlistan:
? El proceso de extracción, transformación y transferencia se ejecuta una vez por
cada campus existente en un sistema operacional. ? Se corre el riesgo de que se modifiquen los datos del archivo generado en la
extracción, después de que ha terminado la propia extracción. Es decir, la
58
información no pasa directamente entre el sistema operacional y el sistema del Data Warehouse lo que permite la posibilidad de que haya alteración a los datos extraídos.
? La cantidad de registros que se extraen diariamente en los archivos de datos, es relativamente grande, sin embargo, los registros que presentan algún cambio o que son nuevos con respecto a la última actualización hecha en el Data Warehouse son pocos.
? El volumen de datos de algunas fuentes no permite hacer una extracción secuencial (completa) de los datos, y en el intento de manejar esos grandes volúmenes de información se puede incurrir en la adquisición de software y hardware muy costoso.
6.2 Proceso ETT utilizando Snapshots y Triggers
Hacer una extracción incremental de los datos es lo deseable para un Data Warehouse, ésta se puede realizar con varias herramientas, utilizando para efectos de esta tesis una combinación de Triggers y Snapshots.
Con base a la descripción del caso de estudio que se hizo previamente en el capítulo
cuatro sobre el Data Warehouse que se está implementando en el área de escolar del Tecnológico de Monterrey, las características generales que presenta dicha implementación son las siguientes:
? Los sistemas operacionales fuente que alimentan el Data Warehouse son varios,
pero homogéneos. ? Las plataformas en las que se encuentran las bases de datos operacionales y el Data
Warehouse permiten el uso de Triggers y Snapshots. ? Los datos en los sistemas operacionales no son muy cambiantes. ? El porcentaje de cambios en los datos, entre una aplicación del proceso ETT y otra,
es relativamente bajo. Adicionalmente a las características anteriores, para el proceso ETT del Data
Warehouse del área de escolar del Tecnológico de Monterrey se debe considerar los siguientes aspectos que actualmente son cubiertos con el uso de archivos de datos:
? Concentrar la información de varias bases de datos, en las que se pueden presentar
registros similares y se debe tomar la decisión de elegir solamente uno. ? Manejar los errores que puedan surgir en la transferencia de los datos, antes de
hacer cualquier modificación en le Data Warehouse. ? Generar un archivo de logs en el que se detecten rápidamente los registros que
tuvieron algún problema para ser actualizados. Dadas las características del Data Warehouse en cuestión y los aspectos que deben
ser cubiertos en su proceso ETT, en esta tesis se propone una técnica incremental usando una combinación de Triggers y Snapshots para llevar a cabo las tres operaciones involucradas en el proceso ETT. Los pasos que se siguieron en la aplicación de la técnica
59
propuesta para el Data Warehouse del área de escolar del Tecnológico de Monterrey, son los siguientes:
1. Se delimitó el alcance de aplicación del proceso ETT para realizar las pruebas
necesarias a sólo la tabla Profesor del Data Warehouse. 2. Se investigó en que medida los sistemas operacionales y el Data Warehouse
soportan el uso de Triggers y Snapshots. 3. Se revisó la parte del análisis de requerimientos existente que está relacionada
con la tabla profesor del Data Warehouse. 4. Se analizó la parte de los modelos de datos operacionales que está involucrada
con el proceso ETT de la tabla Profesor del Data Warehouse. 5. Se comprendió y analizó la tabla Profesor del Data Warehouse. 6. Se detectaron los campos de la tabla Profesor que deberían ser eliminados por
ser innecesarios debido a: a. Que la extracción de datos ya no se haría para cierta selección de población,
sino más bien para todos aquellos datos que sufrieran algún cambio. b. Que existían campos para datos que no eran propios de un profesor, sino
más bien de la relación profesor – grupo. 7. Se redefinió la estructura de la tabla Profesor. 8. Se hizo una copia de la nueva estructura de la tabla profesor, con el nombre de
dwh_profesor, en cada una de las cuatro bases de datos operacionales y en el Data Warehouse.
9. Con base en el origen de los datos para la tabla Profesor, tabla-campo de los sistemas operacionales, se determinaron los triggers necesarios en cada una de las tablas propias del sistema operacional.
10. En el desarrollo de todos los triggers se consideran dos validaciones importantes: a. Que los campos actualizados en las tablas del sistema operacional fuente
sean campos que proveen datos al Data Warehouse. Esta validación se hace tomando en cuenta que, en general, cada una de las tablas del sistema operacional contribuye máximo con cuatro campos para la tabla Profesor.
b. Que los datos actualizados en el sistema operacional correspondan a una persona que está habilitada como profesor; esto debido a que en dichos sistemas existe información de otras personas como alumnos, investigadores, etc.
11. Se definieron los requerimientos de conexión remota para establecer comunicación desde los sistemas operacionales fuente al Data Warehouse.
12. Se hizo un trigger en la tabla dwh_profesor, ubicada en los sistemas operacionales para mantener actualizada la tabla dwh_profesor en el Data Warehouse. Debido a que el trigger ejecuta una acción en una tabla idéntica a la que lo disparó, sólo se hace una validación de existencia e inexistencia del registro.
13. Por último se creó el Snapshot de la tabla dwh_profesor del Data Warehouse para mantener actualizada la tabla Profesor. Con el objetivo de que el Snapshot únicamente reproduzca los datos que sufrieron algún cambio en la tabla dwh_profesor, se creó un Snapshot Log.
Después de haber aplicado la técnica incremental propuesta a una parte del Data
Warehouse del área de escolar del Tecnológico de Monterrey, y de haber obtenido resultados satisfactorios tal y como se puede ver en el punto 5.6 del capitulo 5, se
60
puede decir que, Para hacer uso de la combinación de Triggers y Snapshots propuesta como técnica incremental en el proceso ETT de un Data Warehouse que cuente con características iguales o similares a las del caso de estudio que fueron mencionadas con anterioridad, es necesario tomar en cuenta, de manera general, lo siguientes pasos:
1. Revisar el análisis de requerimientos existente. 2. Entender y comprender las parte de los modelos de datos operacionales
involucradas en el modelo de datos del Data Warehouse. 3. Detectar posibles campos de las tablas del Data Warehouse que con el uso de la
técnica incremental propuesta, dejan de ser necesarios. 4. Realizar la reestructuración de las tablas que lo necesiten. 5. Crear tablas iguales a las del Data Warehouse en los sistemas operacionales. 6. Determinar los triggers necesarios en cada una de las tablas propias del sistema
operacional. 7. Hacer las validaciones pertinentes en los triggers para filtrar los datos necesarios
al Data Warehouse desde un principio. 8. Definir los requerimientos de comunicación para establecer la conexión remota. 9. Crear tablas concentradoras de las actualizaciones que se presenten en las tablas
similares a las del Data Warehouse que se crearon en los sistemas operacionales. 10. Crear los triggers para mantener actualizada las tablas concentradoras. 11. Crear los Snapshots para las tablas concentradoras en el Data Warehouse. 12. Crear los Snapshots Logs correspondientes, para que los Snapshots únicamente
reproduzcan los datos que tuvieron alguna operación de DML (Data Manipulation Languaje).
6.2.1 Ventajas
Las ventajas que se observaron al usar los triggers y snapshots en el proceso ETT aplicado a una parte del Data Warehouse del área de escolar del Tecnológico de Monterrey, son las siguientes:
? Se obtienen solo los datos que sufrieron algún cambio en el sistema operacional. ? No hay intermediario humano entre la extracción y la transferencia de los datos. ? Se concentra información de varias bases de datos, al mismo tiempo.
6.2.2 Desventajas
Como parte de la aplicación que se hizo de usar triggers y snapshots en el proceso ETT, se detectaron las siguientes desventajas:
? Es laborioso de implementar por los cambios y agregados estructurales que se
deben de hacer a los sistemas operacionales y al Data Warehouse, en ocasiones pueden requerir varias modificaciones y para ello se debe tener conocimiento claro de los modelos de datos involucrados.
61
? Se crean tablas, similares a las del Data Warehouse, en los sistemas operacionales, para que en ellas se registren los cambios que den con los datos requeridos.
? Se requiere de una tabla extra en cada uno de los sistemas operacionales, para almacenar los cambios que sufran los registros.
? La tabla extra se debe depurar y/o limpiar, dependiendo de cada situación particular del Data Warehouse, para que no vaya creciendo igual que la tabla del Data Warehouse pero que si cumpla su función de mantenerlo actualizado, ya que el objetivo de ésta es que sólo sirva como un paso previo a la transferencia, no como una copia de los datos.
? Se necesita tener un trigger que hace actualizaciones remotas, esto puede demandar mayor trabajo, del esperado, en el sistema operacional.
? Dada la seguridad que tienen los sistemas operacionales, los triggers deben ser evaluados por el o los encargados de éstos.
? Hay que estar dando mantenimiento a las estructuras que se crearon.
6.3 Comparación de las dos técnicas del proceso ETT realizadas.
Como se puede ver en los puntos 6.1 y 6.2, tanto la técnica existente como la que se propuso para realizar el proceso ETT del Data Warehouse del Tecnológico de Monterrey, haciendo uso de los archivos de datos y utilizando una combinación de Triggers y Snapshots respectivamente, ofrecen ciertas ventajas y desventajas; asimismo a lo largo del análisis y desarrollo de dichas técnicas se pudo percibir que invariablemente de la técnica o técnicas que se utilicen para el proceso ETT el resultado final, en cuanto a datos se refiere, es el mismo.
Por otro lado, en cuanto a tiempo de procesamiento se refiere, y como fue detallado
en los puntos 4.3 y 5.6, en el proceso ETT con uso de archivos de datos el tiempo requerido fue de dos horas y media con una población de 1500 registros, mientras que con el uso de Triggers y Snapshots sólo se requirió de 2 minutos para realizar dicho proceso con la misma población, lo cual hace notar la mejora en lo que a tiempo de procesamiento se refiere, que puede ofrecer el uso de la técnica incremental propuesta.
El diseño del proceso de extracción debe cubrir dos situaciones: la extracción,
transformación y transferencia total e incremental de los datos, esto se deduce porque para poder aplicar un proceso ETT incremental, antes, el Data Warehouse debe de tener datos iniciales a partir de los que se va a monitorear la actualización o eliminación de los mismos, así como la inserción de nuevos datos.
La extracción secuencial de los datos operacionales y transferencia al Data
Warehouse, es relativamente fácil de manejar, pero se recomienda no hacer uso continuo de ella, la mejor decisión es utilizar estas técnicas sólo para poblar inicialmente el Data Warehouse y en algunas otras ocasiones que se considere pertinente. Principalmente porque los recursos involucrados o relacionados con los sistemas operacionales y con el Data Warehouse, tales como las redes, los procesadores y la memoria, pueden quedar obsoletos, si sólo se pone en práctica una técnica
62
secuencial, es decir, si el proceso ETT extrae, transforma y transfiere, siempre, todos los datos que se necesitan en el Data Warehouse.
Es por ello que se debe estar consiente de que este proceso es importante, y que las
técnicas tanto secuenciales como incrementales son necesarias en algún momento de la vida del Data Warehouse.
63
CAPÍTULO 7. CONCLUSIONES Y TRABAJOS FUTUROS
En el contexto de una sociedad globalizada, en el que los avances tecnológicos en información y comunicación cobran cada vez más importancia, implementar un Data Warehouse día con día se está convirtiendo en una realidad en las organizaciones, principalmente porque resulta ser una eficaz herramienta de organización y análisis de los complejos volúmenes de información que las compañías generan, lo que consecuentemente, a su vez, permite el desarrollo de estrategias más efectivas y rentables para las empresas.
7.1 Conclusiones
Para que el Data Warehouse cumpla con su propósito, es decir, organizar y analizar de manera óptima, eficaz y eficiente la información que las organizaciones requieren, es necesario que los datos originarios de los sistemas operacionales sirvan para generar información real y relevante que ayude en la toma de decisiones, por consiguiente es importante considerar un proceso que afecta directamente al logro de tales objetivos, dicho proceso es el conocido como ETT (extracción, transformación y transferencia de datos), mediante el cual se lleva a cabo la extracción de los datos de los sistemas operacionales, la transformación de los mismos (en caso de ser requerida) y su transferencia al Data Warehouse.
Existen múltiples y variadas técnicas para la aplicación del proceso ETT, de manera
que una acertada elección de las mismas, asegura un buen porcentaje de éxito en un proyecto de Data Warehouse, ya que aún cuando se ha haya realizado la mejor planeación, el mejor análisis de requerimientos y se emplee la mejor herramienta de explotación, todo esto no es suficiente si los datos extraídos y transferidos al Data Warehouse no están ni en el tiempo indicado ni en el formato requerido.
Proporcionar el uso de una combinación de triggers y snapshots como técnica
incremental en el proceso ETT es una aportación particular de esta tesis, que nace de la necesidad de llevar a cabo dicho proceso en un ambiente que integra múltiples bases de datos. Además se incluye la descripción del funcionamiento de las técnicas secuenciales con uso de archivos de datos y queries distribuidos, al igual que de las técnicas incrementales con uso de: timestap, monitoreo de registros y snapshots diferenciales, triggers, snapshots, partitioning y queryable.
Asimismo fue posible comprobar la hipótesis planteada para efectos de esta tesis:
“El uso de una combinación de Snapshots y Triggers como técnica incremental en el proceso (ETT) de extracción, transformación y transferencia de datos de los sistemas operacionales fuente al Data Warehouse, es mejor en cuanto a tiempo de procesamiento en comparación con el uso de los archivos de datos, en un esquema de
64
múltiples bases de datos”. Dicha comprobación se obtuvo al realizar las pruebas para medir los tiempos de ejecución del proceso ETT que es parte del Data Warehouse del área de escolar del Tecnológico de Monterrey, a través de una técnica secuencial basada en archivos de datos, y una técnica incremental que combina Triggers y Snapshots. Como se detalla en los puntos 4.3 y 5.6 de los capítulos 4 y 5 respectivamente, el tiempo de procesamiento requerido en el proceso ETT con uso de archivos de datos fue de dos horas y media con una población de 1500 registros, mientras que con el uso de Triggers y Snapshots sólo requirió de 2 minutos para realizar dicho proceso con la misma población, lo cual hace notar la mejora que ofrece la técnica propuesta en lo que a tiempo de procesamiento se refiere.
Además de la comprobación de la hipótesis planteada, se obtuvieron las siguientes
conclusiones generales: ? El desarrollo del proceso ETT con uso de archivos de datos: o Es fácil de comprender para el implementador. o Es adaptable a las necesidades particulares de las organizaciones. o Por cada sistema operacional fuente requiere de un programa computacional
que realice la extracción y transformación. o Sólo se puede requerir un programa computacional para realizar la
transferencia de los datos. o Se extraen todos los datos de los sistemas operacionales que forman parte del
Data Warehouse, sin importar si hubo modificación en ellos, después de la última extracción realizada.
? El desarrollo del proceso ETT con uso de Snapshots y Triggers: o Permite extraer únicamente los datos que sufrieron algún cambio, y por
consiguiente solo se hace la transferencia de éstos al Data Warehouse. o Es complicado para el implementador, principalmente porque debe de incurrir
en cambios en el sistema operacional o Afecta directamente a las bases operacionales, por lo que se debe tener un
claro conocimiento de ellas. ? Ambas técnicas ofrecen los mismos resultados en cuanto a datos finales, después
de la ejecución del proceso ETT, en el Data Warehouse se refiere. ? Decidir entre una u otra técnica de las analizadas está en función de los propios
sistemas operacionales y del Data Warehouse. ? Con base a la aplicación que se hizo del proceso ETT con uso de Triggers y
Snapshots la técnica propuesta se puede utilizar en proyectos de Data Warehouse cuyas características principales son: el uso de Triggers y Snapshtos es permitido por las plataformas en las que están las bases de datos operacionales y del Data Warehouse, además de que pueden existir varios sistemas operacionales fuente pero homogéneos y de que el porcentaje de cambios en los datos entre una extracción y la siguiente es relativamente bajo. La forma de llevar a cabo dicha técnica se describe completamente en el punto 6.2 del capítulo 6.
Así mismo, se puede decir que una técnica no es mejor ni peor que otra, cada una
tiene ventajas y desventajas, que dependen entre otras cosas de la situación de las bases de datos, de la infraestructura computacional y del expertise del personal que esta a cargo de la implementación del Data Warehouse y particularmente del proceso ETT.
65
El proceso ETT, como se menciono a lo largo de este trabajo, es muy importante en el ciclo de vida del Data Warehouse y el realizarlo de una u otra forma debe estar en función de los recursos disponibles y las necesidades de los usuarios, el resultado final al utilizar cualquier técnica es el mismo, lo único que cambia es la forma como se llego a ese resultado.
Encontrar sistemas que nos permitan manejar la inmensa cantidad de información
que se genera en la actualidad es una necesidad apremiante, ya que las organizaciones, requieren poder asimilar y analizar la que se genera día con día, es por ello que se considera pertinente emplear procesos que la sistematicen de manera tal que economicen gastos, tiempos y esfuerzos de quien las requiere.
7.2 Trabajos futuros
Con la culminación de este trabajo, se cumplió con las expectativas que se esperaba, sin embargo, nos deja la necesidad de continuar investigando en ciertas áreas específicas, por lo que se puede decir que quedan abiertas las siguientes líneas de investigación:
? Aplicación del proceso ETT con la técnica propuesta, en un ambiente de sistemas
operacionales fuente, heterogéneo. ? Aplicación de cualquier técnica secuencial o incremental en el proceso ETT de un
Data Warehouse completo. ? Desarrollo de una aplicación que ayude a corregir los logs que se presentan con el
uso de triggers. ? Documentar los factores clave para tener éxito en un proceso ETT.
66
BIBLIOGRAFÍA
ADIWIJAYA, Igg; Investigación sobre detección de cambios con Snapshots "Effective and efficient periodic change detection for legacy system and/or highly autonomous information source".
BOKUN, Michele; Incremental Data Warehouse Updates; DM Review, May 1998 . BURLESON, Donald; “High Performance Oracle Data Warehousing”; Ed. Coriolis Group
Books; USA 1997. CASTAÑEDA, Corvera Oraldo, “Identificación de los Elementos Críticos de Éxito en la
Implementación de la Fuente Primaria de Información: DW”; Tesis de Maestría, Diciembre 2001.
CORKE, Randy; “Keeping Data Warehouse Current: Automating Incremental Updates
With Data Movement”, DMReview.com, 1999. Database Inc., 2000; Database Inc. (2000), “Data Warehousing – An Executive’s
Perspective”, consultado en Agosto 2002, URL: http://www.dspace.com/whatman.htm
ESTIVILL, Castro Vladimir, Mineria de datos, LANIA, Universidad Tecnológica de
Queensland, Australia, 1997, documento recuperado de Internet el día 26 de mayo 2003, URL: http://www.lania.mx/spanish/actividades/newsletters/1997-otono-invierno/mineria.html
FIORE, Peter; “Everyone is talking about Data Wareousing”, Volving Enterprise, Vol 1,
Num. 1, Spring 1998, consultado en Octubre 2002, URL: http://www.lionhrtpub.com/ee/ee-spring98/fiore.html
FLOWER, Andrew; “The ETL silver bullet”, Dataspace Incorporated, documento
recuperado de internet el 26 de mayo de 2003, URL: http://www.dataspace.com/ GUPTA, Vivek R. Gupta, “An Introduction to Data Warehousing”, System Services
Corporation Papers, Agosto 1997 INMON, W.H., Building the Data Warehouse, Wiley Computer Publishing, segunda
edición, Estados Unidos, 1996. JOHNSON, Amy Helen Johnson, “Data Warehouse”, Computerworld, 6-Diciembre-1999 LINDSAY, Bruce; “A snapshot differential refresh algorithm”, 2000
67
MANNING, Jan, “Data Warehousing”, consultado en Agosto 2002, URL: http://www.manning.demon.co.uk/, Octubre 2000.
MAYER, Don; Cannon Casey, “Show Me The Data”, consultado en agosto 2002, URL:
http://www.donmayer.com/DSSART.html, Octubre 1999. MONTOLIO, Garcia V. “Data Warehouse”, Departamento Ingeniería y Ciencia de la
Computadora, Universitat JaumeI. ORACLE, Documentación de varias versiones de Oracle que mantiene el departamento de
Ingeniería Informática en el Tecnológico de Monterrey, última consulta enero 2003, URL: http://www.echobase.mty.itesm.mx/Oracle 8i/index.html
LONEY, Kevin; Oracle8i: the complete reference; Osborne McGraw-Hill, c2000; décima
edición PALOMAR, Sanz M. “Curso de doctorado: Uso y diseño de bases de dato s
multidimensionales y almacén de datos”, 2002, Universidad de Alicante, consultado en octubre 2002, URL: http://www.dlsi.ua.es/~mpalomar/mpalomar.html
RAM, Prabhu & DO, Lyman; “Extracting Delta for Incremental Data Warehouse
Maintenance”, 16th International Conference on Data Engineering, February 28 - March 03, 2000; San Diego, CA.
SOLIS, Almonacid Froilan; “Data Warehouse”, consultado en agosto 2002, URL:
http://www.monografias.com/trabajos6/dawa/dawa.shtml
68
ANEXOS
A.1 Diccionario de datos de la tabla ST4ORGN Tabla para el registro de la estructura organizacional académica
Nombre del Campo Descripción st4orgn_code clave única asignada a una unidad organizacional en
particular. st4orgn_eff_date fecha a partir de la cual resulta efectiva la definición
de las características de la unidad organizacional especificada por medio de la clave almacenada en el campo st4orgn_code.
st4orgn_code_pred clave de la unidad organizacional de la cual depende la unidad organizacional especificada por medio de la clave almacenada en el campo st4orgn_code.
st4orgn_eff_date_pred fecha a partir de la cual resulta efectiva la definición de la unidad organizacional de la cual depende la unidad especificada por medio de la clave almacenada en el campo st4orgn_code.
st4orgn_nombre nombre asignado a la unidad organizacional. st4orgn_nombre_abreviado abreviatura del nombre asignado a la unidad
organizacional. st4orgn_siglas siglas con las cuales se identifica a la unidad
organizacional. st4orgn_responsable_unid_org clave de persona correspondiente al responsable de la
unidad organizacional. st4ocla_code clave que determina la clase organizacional a la cual
pertenece la unidad organizacional (ie. rectoría, campus, división, departamento, etc).
st4lseo_code clave que determina la línea de servicio a la cual pertenece la unidad organizacional (ie. enseñanza, apoyo académico, investigación)
st4orgn_tabla_original_banner nombre de la tabla en la cual la unidad organizacional tiene almacenada a su equivalente en los términos originales de banner.
st4orgn_clave_original_banner clave que corresponde al equivalente de la unidad organizacional en términos de las definiciones de banner.
st4orgn_activity_date fecha cuando el registro es creado o actualizado.
A.2 Diccionario de datos (modelo de datos del sistema operacional que se utilizó para crear la tabla Profesor del Data Warehouse ).
69
Tabla de personas habilitadas como profesor en un ejercicio académico SIBINST.
Nombre del Campo Descripción sibinst_pidm clave interna única de la persona. sibinst_term_code_eff
clave del ejercicio académico al que corresponde la información de la persona como profesor.
sibinst_fcst_code estatus professor. sibinst_fctg_code categoría laboral de profesor. sibinst_fstp_code clasificación docente de profesor. sibinst_fcnt_code tipo de contrato del profesor para el calculo del área de
trabajo. sibinst_schd_ind indicador del tipo de clases que imparte. sibinst_advr_ind indicador advisment professor. sibinst_fcst_date fecha del estatus del profesor. sibinst_wkld_code código de la regla de trabajo de profesor. sibinst_cntr_code código de las reglas del contrato del profesor. sibinst_appoint_date fecha de cuando fue dada la cita del profesor. sibinst_activity_date ultima fecha de actualización del registro.
Tabla complementaria de escolaridad a nivel universidad, SO1DEGR.
Nombre del Campo Descripción sordegr_pidm primera parte de la llave primaria heredada. sordegr_sbgi_code segunda parte de la llave primaria heredada. sordegr_degc_code tercera parte de la llave primaria heredada. sordegr_degr_seq_no cuarta parte de la llave primaria heredada. so1degr_estatusescolaridad estatus de la escolaridad (cursando, pendiente,
inconclusa, terminada) so1degr_activity_date ultima fecha de actualización del registro. so1degr_user usuario que la dio de alta. so1degr_fecha_forma_titulacion
fecha de examen recepcional o fecha de acta de tesis.
so1degr_num_docto_ampara_grado número del documento que ampara el grado. so1degr_fecha_exped_doctoampgr
fecha de expedición del documento que ampara el grado.
so1degr_tipo_docto_ampara_grad
tipo de documento que ampara el grado (certificado, titulo).
Tabla complementaria para identificación de personas, SP1IDEN. Nombre del Campo Descripción
spriden_pidm clave interna única de la persona spriden_id clave de identificación de la persona sp1iden_first_name apellido paterno de la persona (el nombre del campo no
concuerda con el contenido por adaptarse a las longitudes
70
de los ampos de spriden sp1iden_mi apellido materno de la persona (no concuerda el nombre
del campo con el contenido por adaptarse a las longitudes de los campos de spriden
sp1iden_last_name nombres de la persona (no concuerda el nombre del campo con el contenido por adaptarse a las longitudes de los campos de spriden
sp1iden_birth_date fecha de nacimiento de la persona sp1iden_search_first apellido materno de la persona en mayúsculas sin espacios
y signos. sp1iden_search_middle apellido materno de la persona en mayúsculas sin espacios
y signos. sp1iden_search_last_fn nombre de búsqueda del primer nombre. sp1iden_search_last_sn nombre de búsqueda del segundo nombre. sp1iden_search_last_rn nombre de búsqueda del resto del nombre. sp1iden_soundex_last_fn soundex del primer nombre (operación separa_nombres). sp1iden_soundex_last_sn soundex del segundo nombre (operación
separar_nombres). sp1iden_soundex_last_rn soundex del resto del nombres (operación
separar_nombres). sp1iden_soundex_middle string fonético minimizado del apellido materno (para
identificación de personas similares) sp1iden_soundex_birth string fonético minimizado de la fecha de nacimiento en
formato alfabético (0 -> a, 1 -> b, ... ejemplo: 01/12/1990 -> ab/ac/biia) (para identificación de personas similares)
sp1iden_forcesimilar valor que indica si la persona fue forzada a ser duplicada. sp1iden_user usuario que realizo la ultima actualización de los datos de
identificación de persona sp1iden_activity_date fecha de ultima actualización de los datos de
identificación de persona Tabla complementaria de información básica de personas, SP1PERS.
Nombre del Campo Descripción spbpers_pidm identificador interno único de la persona. sp1pers_height altura de la persona en metros y centímetros. sp1pers_fecha_matrimonio fecha en que contrajo matrimonio la persona, en
caso de que su estado civil sea casado(a) . st4ttra_titulo_trato titulo para trato de la persona (sr., sra., ing.,lic.,
dr., etc.). gtvzipc_code_lugar_nacimiento
clave de ubicación geográfica que identifica a la ciudad, municipio o población de donde nació la persona.
gtvzipc_code_lugar_procedencia clave de ubicación geográfica que identifica a la ciudad, municipio o población de donde procede la persona.
sp1pers_curp clave única del registro poblacional (curp) de la
71
persona. sp1pers_activity_date fecha de alta o ultima modificación del registro. sp1pers_user cuenta del usuario que realizó la ultima
actualización al registro. Tabla de información del departamento y división de profesor, SIRDPCL.
Nombre del Campo Descripción sirdpcl_pidm identificador interno único de la persona. sirdpcl_term_code_eff clave del ejercicio académico al que corresponde la
información de la persona como profesor. sirdpcl_coll_code división a la que está asignada el profesor. sirdpcl_dept_code departamento al que esta asignado el profesor. sirdpcl_home_ind identificador administrativo del departamento y de la
división. sirdpcl_percentage porcentaje de responsabilidad para los departamentos. sirdpcl_activity_date fecha de alta o ultima modificación del registro.
Tabla complementaria de sibfacd, SI1FACD. Nombre del Campo Descripción
sibfacd_pidm identificador interno único de la persona. si1facd_yrs_exp periodos de experiencia docente del profesor en el itesm. si1facd_activity_date fecha de alta o última modificación del registro.
Tabla registro de asistencia de profesores, SI2CSAC
Nombre del Campo Descripción sirasgn_term_code ejercicio académico de asignación al profesor. sirasgn_crn identificador interno único del grupo. sirasgn_pidm identificador interno único de la persona. sirasgn_category categoría del profesor. si2csac_cumple_criterio_sacs
indicador que define si un profesor cumple o no para una de terminada materia con el nivel académico de la sacs requerido. valores posibles: (s)i o (n)o.
si2csac_cve_nivel_acad_sacs nivel académico de la sacs con el cual un profesor debe cumplir para poder impartir una materia determinada. estos niveles se encuentra definidos en la tabla stvlevl.
si2csac_respons_def_crit_sacs
usuario responsable de la definición del cumplimiento de un profesor con respecto al nivel académico de sacs requerido para impartir una materia determinada.
si2csac_justific_cumplimiento indicador que determina el motivo por el que se
72
considerado que un profesor cumple con los criterios sacs para impartir un grupo en particular. Posibles valores: (g)rado, caso (e)xcepcional, criterio (i)tesm .
si2csac_activity_date fecha de creación del registro o última actualización. Tabla de asignación de grupos a profesores, SIRASGN Nombre del Campo Descripción
sirasgn_term_code ejercicio académico de asignación al profesor. sirasgn_crn identificador interno único del grupo. sirasgn_pidm identificador interno único de la persona. sirasgn_category categoría del profesor. sirasgn_percent_response porcentaje de responsabilidad del profesor. sirasgn_workload_adjust ajuste de la carga de trabajo. sirasgn_percent_sess porcentaje de responsabilidad del instructor. sirasgn_primary_ind profesor titular. sirasgn_over_ride indicador override. sirasgn_position posición de facultad. sirasgn_activity_date fecha de creación del registro o última actualización. sirasgn_fcnt_code tipo de contrato del profesor para el calculo del área de
trabajo. sirasgn_posn Número de posición. usado para empatar a una posición
definida en el banner de recursos humanos. sirasgn_suff sufijo del número de posición. usado para empatar a una
posición definida en el banner de recursos humanos. sirasgn_asty_code código asignado a la facultad.
Tabla complementaria de sirasgn, SI1ASGN Nombre del Campo Descripción
sirasgn_term_code ejercicio académico de asignación al profesor. sirasgn_crn identificador interno único del grupo. sirasgn_pidm identificador interno único de la persona. sirasgn_category categoría del profesor. si1asgn_indicadorpagogrupo indicador que define si un curso será remunerado al
profesor que lo imparte. posibles valores: (s)e paga el curso, (n)o se paga el curso.
si1asgn_fecasignacprofgpo fecha en que un determinado profesor fue asignado a un grupo en especifico.
si1asgn_fecbajaprofgpo fecha a partir de la cual se hace efectiva la baja de la asignación de un profesor a un grupo determinado.
si1asgn_fecbajapagoprofgpo fecha a partir de la cual se considera dado de baja a un profesor con respecto a un grupo para efectos de pagos.
si1asgn_horas_clase_pago
horas de clase que serán consideradas para el pago del profesor con respecto a un grupo determinado.
73
si1asgn_horas_lab_pago
horas de laboratorio que serán consideradas para el pago del profesor con respecto a un grupo determinado.
si1asgn_user
usuario que dio de alta o actualizo por ultima vez la información de la tabla sirasgn o de la tabla si1asgn.
si1asgn_activity_date fecha de creación del registro o última actualización. Tabla para manejo de identificadores extra (matriculas, nominas, etc.), SP2IDEX.
Nombre del Campo Descripción spriden_pidm identificador único interno de la persona sp2idex_id identificador extra de la persona según el rol (matrícula,
nómina, etc.). sp2idex_activity_date la fecha en mas reciente en que el registro ha sido creado o
modificado sp2idex_user usuario que realizó la última modificación
A.3 Indicaciones para extraer los datos y manejo de errores
Nombre del campo: Nombre_campus Caso esperado: El nombre del campus donde el profesor imparte clases Ejemplo: Campus Monterrey PETICIÓ N: No aplica Razones para tener *: Caso no se presenta. Razones para tener vacío: Caso no se presenta. Motivos de error: Caso no se presenta. Nombre del campo: Siglas_campus Caso esperado: Las siglas del campus en que el profesor imparte clases Ejemplo: Mty PETICIÓ N: No aplica Razones para tener *: Caso no se presenta. Razones para tener vacío: Cuando la Clave campus está vacío. Motivos de error: Caso no se presenta. Nombre del campo: Clave_ejercicio_academico_efec Caso esperado: El ejercicio académico que el profesor tiene en SIAINST y
de donde se toma la información referente al profesor. Ejemplo: 199913 PETICIÓ N: No aplica Razones para tener *: Cuando el profesor no tiene ningún registro en SIAINST Razones para tener vacío: Caso no se presenta Motivos de error: El profesor no tiene ningún registro en SIAINST Nombre del campo: Desc_ejercicio_academico_efec Caso esperado: Descripción de Clave_ejercicio_academico_efec Ejemplo: Semestral Ago - Dic de 1999 PETICIÓ N: No aplica Razones para tener *: Cuando Clave_ejercicio_academico_efec tiene *
74
Razones para tener vacío: Caso no se presenta Motivos de error: Caso no se presenta. Nombre del campo: Clave_persona Caso esperado: El identificador @ del profesor Ejemplo: @00123456 PETICIÓ N: No aplica Razones para tener *: Caso no se presenta. Razones para tener vacío: Caso no se presenta Motivos de error: Caso no se presenta. Nombre del campo: Nómina Caso esperado: La nómina que tiene asignada el profesor Ejemplo: L00123456 PETICIÓ N: No aplica Razones para tener *: Cuando el profesor no tiene una nómina asociada. Razones para tener vacío: Caso no se presenta Motivos de error: Caso no se presenta. Nombre del campo: Apellido_paterno_profesor Caso esperado: El apellido paterno que tiene asociada la persona. Ejemplo: Juárez PETICIÓ N: No aplica Razones para tener *: Caso no se presenta. Razones para tener vacío: Si no tiene apellido paterno capturado. (Es correcto ya
que existen algunas personas que sólo tienen apellido materno y debe ser capturado como apellido materno.
Motivos de error: Caso no se presenta. Nombre del campo: Apellido_materno_profesor Caso esperado: El apellido materno que tiene asociado el profesor. Ejemplo: Garza PETICIÓ N: No aplica Razones para tener *: Caso no se presenta. Razones para tener vacío: Si no tiene apellido materno capturado. (Es correcto para
profesores extranjeros) Motivos de error: Caso no se presenta. Nombre del campo: Nombre_profesor Caso esperado: El nombre que tiene asociado el profesor. Ejemplo: Ma. De Lourdes PETICIÓ N: No aplica Razones para tener *: Caso no se presenta. Razones para tener vacío: Caso no se presenta. Motivos de error: Caso no se presenta. Nombre del campo: Titulo_trato_profesor Caso esperado: El título de trato del profesor. Ejemplo: Ing. PETICIÓ N: No aplica Razones para tener *: Caso no se presenta. Razones para tener vacío: Cuando no tiene capturado el título de trato Motivos de error: Caso no se presenta.
75
Nombre del campo: Clave_categoria_laboral Caso esperado: El valor de la categoría que el profesor tiene capturado
en SIAINST. Ejemplo: PLA PETICIÓ N: No aplica Razones para tener *: Cuando el profesor no tiene la categoría capturada en
SIAINST Razones para tener vacío: Caso no se presenta. Motivos de error: El profesor no tiene la categoría capturada en SIAINST Nombre del campo: Desc_categoria_laboral Caso esperado: Descripción de Clave_categoria_laboral Ejemplo: Planta PETICIÓ N: No aplica Razones para tener *: Cuando Clave_ categoria_laboral tiene * Razones para tener vacío: Caso no se presenta. Motivos de error: Caso no se presenta. Nombre del campo: Clave_clasficacion_docente Caso esperado: La clasificación docente que el profesor tiene capturada
en SIAINST (staff type) Ejemplo: 0001 PETICIÓ N: No aplica Razones para tener *: Cuando un profesor que no tiene categoría PLA o MPL
tiene capturada una clasificación docente. Razones para tener vacío: Cuando el profesor no tiene una clasificación docente
(staff type) capturado. Motivos de error: Tener categoría diferente PLA o MPL y tener capturada la
clasificación docente en SIAINST Nombre del campo: Desc_clasficacion_docente Caso esperado: Descripción de Clave_clasficacion_docente Ejemplo: Instructor (Enseñanza) PETICIÓ N: No aplica Razones para tener *: Cuando Clave_clasficacion_docente tenga * Razones para tener vacío: Cuando Clave_clasficacion_docente sea vacio Motivos de error: Caso no se presenta. Nombre del campo: Clave_grado_maximo_prof Caso esperado: El nivel académico del grado de estudios máximo que el
profesor tiene terminado en SOAPCOL. Se considera que el grado de Especialidad es menor que el de maestría.
Ejemplo: 05 PETICIÓ N: No aplica Razones para tener *: Cuando el profesor no tiene ningún grado académico
terminado en SOAPCOL y en SIACSAC no tiene ningún grupo con cumplimiento N 05
Razones para tener vacío: Cuando el profesor no tiene ningún grado académico terminado en SOAPCOL y en SIACSAC tiene algún grupo con cumplimiento N 05.
Motivos de error: El profesor no tiene ningún grado académico terminado en SOAPCOL y en SIACSAC no tiene ningún grupo con
76
cumplimiento N 05 Nombre del campo: Desc_grado_maximo_prof Caso esperado: Descripción del nivel del grado máximo. Ejemplo: Maestría PETICIÓ N: No aplica Razones para tener *: Cuando Clave_ grado_maximo_prof tenga * Razones para tener vacío: Cuando Clave_ grado_maximo_prof sea vacio Motivos de error: Caso no se presenta. Nombre del campo: Doctorado_Itesm Caso esperado: SI/NO indica si el profesor tiene o no un grado terminado
de doctorado en SOAPCOL en un campus del ITESM. Ejemplo: Si PETICIÓ N: No aplica Razones para tener *: Caso no se presenta. Razones para tener vacío: Caso no se presenta. Motivos de error: Caso no se presenta. Nombre del campo: Maestria_Itesm Caso esperado: SI/NO indica si el profesor tiene o no un grado terminado
de maestría en SOAPCOL en un campus del ITESM. Ejemplo: No PETICIÓ N: No aplica Razones para tener *: Caso no se presenta. Razones para tener vacío: Caso no se presenta. Motivos de error: Caso no se presenta. Nombre del campo: Licenciatura_Itesm Caso esperado: SI/NO indica si el profesor tiene o no un grado terminado
de licenciatura en SOAPCOL en un campus del ITESM. Ejemplo: Si PETICIÓ N: No aplica Razones para tener *: Caso no se presenta. Razones para tener vacío: Caso no se presenta. Motivos de error: Caso no se presenta. Nombre del campo: Algun_grado_itesm Caso esperado: SI/NO indica si el profesor tiene o no algún grado
terminado de profesional, especialidad, maestría o doctorado SOAPCOL en un campus del ITESM.
Ejemplo: Si PETICIÓ N: No aplica Razones para tener *: Caso no se presenta. Razones para tener vacío: Caso no se presenta. Motivos de error: Caso no se presenta. Nombre del campo: Estudia_doctorado_itesm Caso esperado: SI/NO indica si el profesor está estudiando o no el grado
de doctorado en SOAPCOL en un campus del ITESM. Ejemplo: Si PETICIÓ N: No aplica Razones para tener *: Caso no se presenta.
77
Razones para tener vacío: Caso no se presenta. Motivos de error: Caso no se presenta. Nombre del campo: Estudia_maestria_itesm Caso esperado: SI/NO indica si el profesor está estudiando o no el grado
de maestría en SOAPCOL en un campus del ITESM. Ejemplo: No PETICIÓ N: No aplica Razones para tener *: Caso no se presenta. Razones para tener vacío: Caso no se presenta. Motivos de error: Caso no se presenta. Nombre del campo: Estudia_doctorado_fuera_itesm Caso esperado: SI/NO indica si el profesor está estudiando o no el grado
de doctorado en SOAPCOL en una institución que no es un campus del ITESM.
Ejemplo: No PETICIÓ N: No aplica Razones para tener *: Caso no se presenta. Razones para tener vacío: Caso no se presenta. Motivos de error: Caso no se presenta. Nombre del campo: Estudia_maestria_fuera_itesm Caso esperado: SI/NO indica si el profesor está estudiando o no el grado
de maestría en SOAPCOL en una institución que no es un campus del ITESM.
Ejemplo: Si PETICIÓ N: No aplica Razones para tener *: Caso no se presenta. Razones para tener vacío: Caso no se presenta. Motivos de error: Caso no se presenta. Nombre del campo: Fecha_alta_registro Caso esperado: La fecha en que se dio de alta el registro Ejemplo: 15-AUG-2002 PETICIÓ N: No aplica Razones para tener *: Caso no se presenta. Razones para tener vacío: Caso no se presenta. Motivos de error: Caso no se presenta. Nombre del campo: Fecha_ultima_modificacion Caso esperado: La fecha en que se dio de alta o la última modificación en
el registro Ejemplo: 10-DIC-2002 PETICIÓ N: No aplica Razones para tener *: Caso no se presenta. Razones para tener vacío: Caso no se presenta. Motivos de error: Caso no se presenta.
A.4 Código del programa para la extracción y transformación de los datos del sistema operacional del Tecnológico de Monterrey .
78
void Tabla_Profesores(void) { fprintf(datos_Profesor,"CLAVE CAMPUS|NOMBRE CAMPUS|SIGLAS CAMPUS|CLAVE EJERCICIO ACADEMICO|DESCR EJERCICIO ACADEMICO|ID|NOMINA|ESTATUS ACTIVIDAD DEL PROFESOR|CLAVE EJERCICIO ACADEMICO SIAINST|DESCR EJERCICIO ACADEMICO SIAINST|"); fprintf(datos_Profesor,"MODALIDAD PROGRAMA ALUM-PROF|MODALIDAD GRUPO-PROF|IMPARTE MATERIAS DENTRO PLAN DE ESTUDIOS|APELLIDO PATERNO|APELLIDO MATERNO|NOMBRES|TITULO TRATO|CLAVE DIV PERTENECE PROF|DESCR DIV PERTENECE PROF|"); fprintf(datos_Profesor,"SIGLAS DIV PERTENECE PROF|CLAVE DEPTO PERTENECE PROFESOR|DESCR DEPTO PERTENECE PROFESOR|CATEGORIA PROFESOR|CLASIFICACION DOCENTE|GRADO MAXIMO DE ESTUDIOS|PERIODOS EXPERIENCIA DEL PROFESOR|"); fprintf(datos_Profesor,"DOCTORADO ITESM|MAESTRIA ITESM|LICENCIATURA ITESM|ALGUN GRADO ITESM|ESTUDIA MAESTRIA ITESM|ESTUDIA DOCTORADO ITESM|ESTUDIA MAESTRIA FUERA ITESM|ESTUDIA DOCTORADO FUERA ITESM|\n"); Obtiene_dCampusTerm(); EXEC SQL DECLARE Cur_ProfesorActivo CURSOR FOR SELECT /*+ USE_HASH(A) */ A.SIRASGN_PIDM FROM SATURN.SIRASGN A, SATURN.SSBSECT B WHERE B.SSBSECT_TERM_CODE = :TermCode AND B.SSBSECT_CAMP_CODE = :Campus AND A.SIRASGN_TERM_CODE = B.SSBSECT_TERM_CODE AND B.SSBSECT_CRN = A.SIRASGN_CRN GROUP BY A.SIRASGN_PIDM; EXEC SQL OPEN Cur_ProfesorActivo; for (;;) { EXEC SQL WHENEVER NOT FOUND DO break; EXEC SQL FETCH Cur_ProfesorActivo INTO :Pidm :Pidm_i; EXEC SQL WHENEVER NOT FOUND continue; if (Pidm_i < 0) Pidm = 0; Obtiene_NominaNombre(); Obtiene_EstatusActividad(); Obtiene_ContratoClasificacion(); Obtiene_Sess_AlumnoProfesor(); Obtiene_Sess_GrupoProfesor(); Obtine_CollDpto_Profesor(); Obtiene_GdoMaxEstudiaItesmFuera(); Obtiene_PeriodoExperiencia(); Imparte_Mat_Oficiales(); fprintf(datos_Profesor,"%s|%s|%s|%s|%s|%s|%s|%s|%s|%s|",Campus,dCampus,sCampus,TermCode,dTermCode,ID_PROFESOR,NOMINA,ESTATUS_ACTIVIDAD,cTERM_SIBINST,dTERM_SIBINST); fprintf(datos_Profesor,"%s|%s|%s|%s|%s|%s|%s|%s|%s|%s|",cSESS_ALUMNO,cSESS_GRUPO,IMPARTE_MAT_OFICIAL,APATERNO,AMATERNO,NOMBRES,TITULO_TRATO,cCOLL_PROFESOR,dCOLL_PROFESOR,sCOLL_PROFESOR); fprintf(datos_Profesor,"%s|%s|%s|%s|%s|%s|%s|%s|%s|%s|",cDPTO_PROFESOR,dDPTO_PROFESOR,cTIPO_CONTRATO,cCLASIF_DOCENTE,dGRADO_MAXIMO_EST,PERIODOS_EXPERIENCIA,DOCTORADO_ITESM,MAESTRIA_ITESM,LIC_ITESM,ALGUN_GRADO_ITESM);
79
fprintf(datos_Profesor,"%s|%s|%s|%s|\n",EST_MAES_ITESM,EST_DOC_ITESM,EST_MAES_FUERA,EST_DOC_FUERA); } EXEC SQL CLOSE Cur_ProfesorActivo; EXEC SQL COMMIT WORK; Cierra_Archivo(datos_Profesor); }
A.5 Código del programa de transferencia de datos en el Data Warehouse
void Modulo_Profesores() { int cont_update=0, cont_insert=0, cont_error=0, k=0, j=0, cant=0; char cadena[210], cadena_num[20]; char nombre[100]; exec sql select TO_CHAR(SYSDATE,'DD-MON-YYYY'),TO_CHAR(SYSDATE,'HH24:MI:SS') into :FechaInicioProceso:FechaInicioProcesoi, :HoraInicioProceso:HoraInicioProcesoi from dual; fprintf(control_DWH_ProfesoresActivos,"\n Inicia Proceso\n %s %s\n",FechaInicioProceso,HoraInicioProceso); fprintf(control_DWH_ProfesoresActivos,"\n Inicia Carga de Profesores Activos\n"); EXEC SQL UPDATE DWHESCOLAR.PROFESOR SET ESTATUS_CARGA_PROFESOR = 'I' WHERE CLAVE_CAMPUS = :Campus AND CLAVE_EJERCICIO_ACADEMICO = :TermCode; EXEC SQL UPDATE NIVEL_BO SET ESTATUS_CARGA_NIVEL_BO = 'I' WHERE SIGLAS_RECTORIA = :SIGLAS_RECTORIA; while (!feof(datos_DWH_ProfesoresActivos)) { k++; j++; if (j>99) { fprintf(control_DWH_ProfesoresActivos,"\nProcesando # : %d. %c",k,13); j=0; EXEC SQL COMMIT WORK; } leer_hasta_pipe(datos_DWH_ProfesoresActivos,cadena); strcpy(aCampus,cadena); leer_hasta_pipe(datos_DWH_ProfesoresActivos,cadena); strcpy(dCampus,cadena); leer_hasta_pipe(datos_DWH_ProfesoresActivos,cadena); strcpy(sCampus,cadena);
80
leer_hasta_pipe(datos_DWH_ProfesoresActivos,cadena); strcpy(aTermCode,cadena); leer_hasta_pipe(datos_DWH_ProfesoresActivos,cadena); strcpy(dTermCode,cadena); leer_hasta_pipe(datos_DWH_ProfesoresActivos,cadena); strcpy(ID_PROFESOR,cadena); leer_hasta_pipe(datos_DWH_ProfesoresActivos,cadena); strcpy(NOMINA,cadena); leer_hasta_pipe(datos_DWH_ProfesoresActivos,cadena); strcpy(ESTATUS_ACTIVIDAD,cadena); leer_hasta_pipe(datos_DWH_ProfesoresActivos,cadena); strcpy(cTERM_SIBINST,cadena); leer_hasta_pipe(datos_DWH_ProfesoresActivos,cadena); strcpy(dTERM_SIBINST,cadena); leer_hasta_pipe(datos_DWH_ProfesoresActivos,cadena); strcpy(cSESS_ALUMNO,cadena); leer_hasta_pipe(datos_DWH_ProfesoresActivos,cadena); strcpy(cSESS_GRUPO,cadena); leer_hasta_pipe(datos_DWH_ProfesoresActivos,cadena); strcpy(IMPARTE_MAT_OFICIAL,cadena); leer_hasta_pipe(datos_DWH_ProfesoresActivos,cadena); strcpy(APATERNO,cadena); leer_hasta_pipe(datos_DWH_ProfesoresActivos,cadena); strcpy(AMATERNO,cadena); leer_hasta_pipe(datos_DWH_ProfesoresActivos,cadena); strcpy(NOMBRES,cadena); leer_hasta_pipe(datos_DWH_ProfesoresActivos,cadena); strcpy(TITULO_TRATO,cadena); leer_hasta_pipe(datos_DWH_ProfesoresActivos,cadena); strcpy(cCOLL_PROFESOR,cadena); leer_hasta_pipe(datos_DWH_ProfesoresActivos,cadena); strcpy(dCOLL_PROFESOR,cadena); leer_hasta_pipe(datos_DWH_ProfesoresActivos,cadena); strcpy(SIGLAS_DIVISION_PERTENECE_PROF,cadena); leer_hasta_pipe(datos_DWH_ProfesoresActivos,cadena); strcpy(cDPTO_PROFESOR,cadena); leer_hasta_pipe(datos_DWH_ProfesoresActivos,cadena); strcpy(dDPTO_PROFESOR,cadena); leer_hasta_pipe(datos_DWH_ProfesoresActivos,cadena); strcpy(cTIPO_CONTRATO,cadena); leer_hasta_pipe(datos_DWH_ProfesoresActivos,cadena); strcpy(cCLASIF_DOCENTE,cadena); leer_hasta_pipe(datos_DWH_ProfesoresActivos,cadena); strcpy(dGRADO_MAXIMO_EST,cadena); leer_hasta_pipe(datos_DWH_ProfesoresActivos,cadena); strcpy(PERIODOS_EXPERIENCIA,cadena); leer_hasta_pipe(datos_DWH_ProfesoresActivos,cadena); strcpy(DOCTORADO_ITESM,cadena); leer_hasta_pipe(datos_DWH_ProfesoresActivos,cadena); strcpy(MAESTRIA_ITESM,cadena); leer_hasta_pipe(datos_DWH_ProfesoresActivos,cadena); strcpy(LIC_ITESM,cadena); leer_hasta_pipe(datos_DWH_ProfesoresActivos,cadena); strcpy(ALGUN_GRADO_ITESM,cadena); leer_hasta_pipe(datos_DWH_ProfesoresActivos,cadena); strcpy(EST_MAES_ITESM,cadena); leer_hasta_pipe(datos_DWH_ProfesoresActivos,cadena); strcpy(EST_DOC_ITESM,cadena); leer_hasta_pipe(datos_DWH_ProfesoresActivos,cadena); strcpy(EST_MAES_FUERA,cadena); leer_hasta_pipe(datos_DWH_ProfesoresActivos,cadena); strcpy(EST_DOC_FUERA,cadena);
81
leer_fin(datos_DWH_ProfesoresActivos); if (feof(datos_DWH_ProfesoresActivos)) break; strcpy(error,""); IndicaError = 0; ChecaNulos(); NIVEL_BO(); EXEC SQL SELECT COUNT(*) INTO :cant :cant_i FROM DWHESCOLAR.PROFESOR WHERE CLAVE_CAMPUS = :Campus AND CLAVE_EJERCICIO_ACADEMICO = :TermCode AND CLAVE_PERSONA = :ID_PROFESOR; if (cant_i < 0) cant = 0; if (cant_i < 0) IndicaError = 1; if (IndicaError == 1) { fprintf(error_DWH_ProfesoresActivos,"Tabla PROFESORES, Campus %s TERM %s ID: %s Campos: %s \n",Campus,TermCode,ID_PROFESOR,error); cont_error ++; } else { if (cant > 0) { EXEC SQL UPDATE DWHESCOLAR.PROFESOR SET NOMBRE_CAMPUS =:dCampus, SIGLAS_CAMPUS =:sCampus, DESC_EJERCICIO_ACADEMICO =:dTermCode, CLAVE_EJERCICIO_ACADEMICO_EFEC =:cTERM_SIBINST, DESC_EJERCICIO_ACADEMICO_EFEC =:dTERM_SIBINST, NOMINA =:NOMINA, APELLIDO_PATERNO_PROFESOR =:APATERNO, APELLIDO_MATERNO_PROFESOR =:AMATERNO, NOMBRE_PROFESOR =:NOMBRES, TITULO_TRATO_PROFESOR =:TITULO_TRATO, CLAVE_DIVISION_PERTENECE_PROF =:cCOLL_PROFESOR, DESC_DIVISION_PERTENECE_PROF =:dCOLL_PROFESOR, SIGLAS_DIVISION_PERTENECE_PROF =:SIGLAS_DIVISION_PERTENECE_PROF, CLAVE_DEPTO_PERTENECE_PROF =:cDPTO_PROFESOR, DESC_DEPTO_PERTENECE_PROF =:dDPTO_PROFESOR, CLAVE_CATEGORIA_LABORAL =:cTIPO_CONTRATO, DESC_CATEGORIA_LABORAL = '*', CLAVE_CLASIFICACION_DOCENTE =:cCLASIF_DOCENTE, DESC_CLASIFICACION_DOCENTE = '*', CLAVE_GRADO_MAXIMO_PROF = '*', DESC_GRADO_MAXIMO_PROF =:dGRADO_MAXIMO_EST, PERIODOS_EXPERIENCIA_PROF =:PERIODOS_EXPERIENCIA, DOCTORADO_ITESM =:DOCTORADO_ITESM, MAESTRIA_ITESM =:MAESTRIA_ITESM, LICENCIATURA_ITESM =:LIC_ITESM, ALGUN_GRADO_ITESM =:ALGUN_GRADO_ITESM, ESTUDIA_DOCTORADO_ITESM =:EST_DOC_ITESM, ESTUDIA_MAESTRIA_ITESM =:EST_MAES_ITESM, ESTUDIA_DOCTORADO_FUERA_ITESM =:EST_DOC_FUERA, ESTUDIA_MAESTRIA_FUERA_ITESM =:EST_MAES_FUERA,
82
ESTATUS_ACTIVIDAD_PROFESOR =:ESTATUS_ACTIVIDAD, IMPARTE_MATERIA_PLAN_ESTUDIOS =:IMPARTE_MAT_OFICIAL, CLAVE_MODALIDAD_PGMA_ALUM_PROF =:cSESS_ALUMNO, DESC_MODALIDAD_PGMA_ALUM_PROF = '*', CLAVE_MODALIDAD_GRUPOS_PROF =:cSESS_GRUPO, DESC_MODALIDAD_GRUPOS_PROF = '*', ESTATUS_CARGA_PROFESOR = 'A', FECHA_ULTIMA_MODIFICACION = SYSDATE WHERE CLAVE_CAMPUS = :Campus AND CLAVE_EJERCICIO_ACADEMICO = :TermCode AND CLAVE_PERSONA = :ID_PROFESOR; cont_update ++; } else { EXEC SQL INSERT INTO DWHESCOLAR.PROFESOR ( CLAVE_CAMPUS ,NOMBRE_CAMPUS ,SIGLAS_CAMPUS ,CLAVE_EJERCICIO_ACADEMICO ,DESC_EJERCICIO_ACADEMICO ,CLAVE_EJERCICIO_ACADEMICO_EFEC ,DESC_EJERCICIO_ACADEMICO_EFEC ,CLAVE_PERSONA ,NOMINA ,APELLIDO_PATERNO_PROFESOR ,APELLIDO_MATERNO_PROFESOR ,NOMBRE_PROFESOR ,TITULO_TRATO_PROFESOR ,CLAVE_DIVISION_PERTENECE_PROF ,DESC_DIVISION_PERTENECE_PROF ,SIGLAS_DIVISION_PERTENECE_PROF ,CLAVE_DEPTO_PERTENECE_PROF ,DESC_DEPTO_PERTENECE_PROF ,CLAVE_CATEGORIA_LABORAL ,DESC_CATEGORIA_LABORAL ,CLAVE_CLASIFICACION_DOCENTE ,DESC_CLASIFICACION_DOCENTE ,CLAVE_GRADO_MAXIMO_PROF ,DESC_GRADO_MAXIMO_PROF ,PERIODOS_EXPERIENCIA_PROF ,DOCTORADO_ITESM ,MAESTRIA_ITESM ,LICENCIATURA_ITESM ,ALGUN_GRADO_ITESM ,ESTUDIA_DOCTORADO_ITESM ,ESTUDIA_MAESTRIA_ITESM ,ESTUDIA_DOCTORADO_FUERA_ITESM ,ESTUDIA_MAESTRIA_FUERA_ITESM ,ESTATUS_ACTIVIDAD_PROFESOR ,IMPARTE_MATERIA_PLAN_ESTUDIOS ,CLAVE_MODALIDAD_PGMA_ALUM_PROF ,DESC_MODALIDAD_PGMA_ALUM_PROF ,CLAVE_MODALIDAD_GRUPOS_PROF ,DESC_MODALIDAD_GRUPOS_PROF ,ESTATUS_CARGA_PROFESOR ,FECHA_ALTA_REGISTRO ,FECHA_ULTIMA_MODIFICACION) VALUES (:aCampus, :dCampus,
83
:sCampus, :aTermCode, :dTermCode, :cTERM_SIBINST, :dTERM_SIBINST, :ID_PROFESOR, :NOMINA, :APATERNO, :AMATERNO, :NOMBRES, :TITULO_TRATO, :cCOLL_PROFESOR, :dCOLL_PROFESOR, :SIGLAS_DIVISION_PERTENECE_PROF, :cDPTO_PROFESOR, :dDPTO_PROFESOR, :cTIPO_CONTRATO, '*', :cCLASIF_DOCENTE, '*', '*', :dGRADO_MAXIMO_EST, :PERIODOS_EXPERIENCIA, :DOCTORADO_ITESM, :MAESTRIA_ITESM, :LIC_ITESM, :ALGUN_GRADO_ITESM, :EST_DOC_ITESM, :EST_MAES_ITESM, :EST_DOC_FUERA, :EST_MAES_FUERA, :ESTATUS_ACTIVIDAD, :IMPARTE_MAT_OFICIAL, :cSESS_ALUMNO, '*', :cSESS_GRUPO, '*', 'A', sysdate, sysdate); cont_insert ++; } } } fprintf(control_DWH_ProfesoresActivos,"\nProcesando # : %d. %c",k-1,13); fprintf(control_DWH_ProfesoresActivos,"\n\n Terminado .... \n"); fprintf(control_DWH_ProfesoresActivos,"\nRegistros Totales %d",k-1); fprintf(control_DWH_ProfesoresActivos,"\nRegistros Insertados PROFESOR %d",cont_insert); fprintf(control_DWH_ProfesoresActivos,"\nRegistros Actualizados PROFESOR %d",cont_update); fprintf(control_DWH_ProfesoresActivos,"\nRegistros Con Error PROFESOR %d",cont_error); exec sql select TO_CHAR(SYSDATE,'DD-MON-YYYY'), TO_CHAR(SYSDATE,'HH24:MI:SS') into :FechaFinProceso:FechaFinProcesoi, :HoraFinProceso:HoraFinProcesoi from dual;
84
fprintf(control_DWH_ProfesoresActivos,"\nTermina Proceso Profesores Activos\n %s %s ",FechaFinProceso,HoraFinProceso); EXEC SQL COMMIT WORK; }
A.6 Trigger SP1PERS_UPDATE Este trigger se ejecuta cuando algún registro de la tabla SP1PERS (información
personal de la población escolar, es decir de profesores y/o alumnos) es actualizada. Para efectos del Data Warehouse solo es necesario tomar en cuenta del campo en donde se guarda el titulo de trato de las personas.
CREATE OR REPLACE TRIGGER SP1PERS_UPDATE AFTER UPDATE ON SP1PERS FOR EACH ROW DECLARE ID VARCHAR2(9); contador NUMBER(8); BEGIN ID := NULL; IF UPDATING ('ST4TTRA_TITULO_TRATO') THEN IF (:OLD.ST4TTRA_TITULO_TRATO = :NEW.ST4TTRA_TITULO_TRATO) THEN NULL; ELSE SELECT COUNT(*) INTO contador FROM SATURN.SIBINST WHERE SIBINST_PIDM = :NEW.SPRIDEN_PIDM; IF contador > 0 THEN SELECT SP2IDEX_ID INTO ID FROM SATURN.SP2IDEX WHERE SP2IDEX.SPRIDEN_PIDM = :OLD.SPBPERS_PIDM AND SP2IDEX_ID LIKE '@%'; UPDATE SATURN.DWH_PROFESOR SET TITULO_TRATO_PROFESOR = :NEW.ST4TTRA_TITULO_TRATO, FECHA_ULTIMA_MODIFICACION = SYSDATE WHERE CLAVE_PERSONA = ID; END IF; END IF; ELSE NULL; END IF; EXCEPTION WHEN NO_DATA_FOUND THEN RETURN; END; /
/*El trigger es lanzado después de una actualización a la tabla SP1PERS*/ /*Se valida que el campo actualizado sea el que tiene el dato el título de trato*/ /*Se valida que el dato actualizado sea diferente al que se tenía*/ /*Se revisa que registro actualizado sea de una persona habilitada como profesor*/ /*Se obtienen los datos que forman la llave en el Data Warehouse*/ /*Se lleva a cabo la actualización en la tabla que transferirá los datos al Data Warehouse*/ /*Manejo de excepciones*/
A.7 Trigger SI1FACD_UPDATE
CREATE OR REPLACE TRIGGER SI1FACD_UPDATE AFTER UPDATE ON SI1FACD
/*El trigger es
85
FOR EACH ROW DECLARE ID VARCHAR2(9); contador NUMBER(8); BEGIN ID := NULL; IF UPDATING ('SI1FACD_YRS_EXP') THEN IF ( :OLD.SI1FACD_YRS_EXP = :NEW.SI1FACD_YRS_EXP) THEN NULL; ELSE SELECT COUNT(*) INTO contador FROM SATURN.SIBINST WHERE SIBINST_PIDM = :NEW.SIBFACD_PIDM; IF contador > 0 THEN SELECT SP2IDEX_ID INTO ID FROM SATURN.SP2IDEX WHERE SP2IDEX.SPRIDEN_PIDM = :OLD.SIBFACD_PIDM AND SP2IDEX_ID LIKE '@%'; UPDATE SATURN.DWH_PROFESOR SET PERIODOS_EXPERIENCIA_PROF = :NEW.SI1FACD_YRS_EXP, FECHA_ULTIMA_MODIFICACION = SYSDATE WHERE CLAVE_PERSONA = ID; END IF; END IF; ELSE NULL; END IF; EXCEPTION WHEN NO_DATA_FOUND THEN RETURN; END; /
lanzado después de una actualización a la tabla SI1FACD */ /*Se valida que el campo actualizado sea el que tiene el dato el semestres de experiencia*/ /*Se valida que el dato actualizado sea diferente al que se tenía*/ /*Se revisa que registro actualizado sea de una persona habilitada como profesor*/ /*Se obtienen los datos que forman la llave en el Data Warehouse*/ /*Se lleva a cabo la actualización en la tabla que transferirá los datos al Data Warehouse*/ /*Manejo de excepciones*/
A.8 Trigger SIBINST_UPDATE
CREATE OR REPLACE TRIGGER SIBINST_UPDATE AFTER UPDATE ON SIBINST FOR EACH ROW DECLARE ID VARCHAR2(9); contador NUMBER(8); descrFstp VARCHAR2(30); descrFctg VARCHAR2(30); BEGIN ID := NULL; IF UPDATING ('SIBINST_FCTG_CODE') OR UPDATING('SIBINST_FSTP_CODE') THEN IF (:OLD.SIBINST_FCTG_CODE = :NEW.SIBINST_FCTG_CODE) AND (:OLD.SIBINST_FSTP_CODE = :NEW.SIBINST_FSTP_CODE) THEN NULL; ELSE SELECT SP2IDEX_ID INTO ID FROM SATURN.SP2IDEX WHERE SP2IDEX.SPRIDEN_PIDM = :OLD.SIBINST_PIDM AND SP2IDEX_ID LIKE '@%'; SELECT STVFSTP_DESC
/*El trigger es lanzado después de una actualización a la tabla SIBINST*/ /*Se valida que se haya actualizado alguno de los campos en los que esta el dato de la categoría laboral o clasificación docente */ /*Se valida que el dato actualizado sea diferente al que se tenía*/ /*Se obtienen los datos que forman la llave en el Data Warehouse*/
86
INTO descrFstp FROM SATURN.STVFSTP WHERE STVFSTP_CODE = :NEW.SIBINST_FSTP_CODE; SELECT STVFCTG_DESC INTO descrFctg FROM SATURN.STVFCTG WHERE STVFCTG_CODE = :NEW.SIBINST_FCTG_CODE; UPDATE SATURN.DWH_PROFESOR SET CLAVE_CATEGORIA_LABORAL = :NEW.SIBINST_FCTG_CODE, DESC_CATEGORIA_LABORAL = descrFctg, CLAVE_CLASIFICACION_DOCENTE = :NEW.SIBINST_FSTP_CODE, DESC_CLASIFICACION_DOCENTE = descrFstp, FECHA_ULTIMA_MODIFICACION = SYSDATE WHERE CLAVE_PERSONA = ID AND CLAVE_EJERCICIO_ACADEMICO_EFEC = :OLD.SIBINST_TERM_CODE_EFF; END IF; ELSE NULL; END IF; EXCEPTION WHEN NO_DATA_FOUND THEN RETURN ; END; /
/*Descripción de la clave de clasificación laboral que tiene el profesor asociada*/ /*Descripción de la clave de categoría laboral que tiene el profesor asociada*/ /*Se lleva a cabo la actualización en la tabla que transferirá los datos al Data Warehouse*/ /*Manejo de excepciones*/
A.9 Trigger SP1IDEN_UPDATE
CREATE OR REPLACE TRIGGER SP1IDEN_UPDATE AFTER UPDATE ON SP1IDEN FOR EACH ROW DECLARE contador NUMBER; ID VARCHAR2(9); BEGIN ID := NULL; contador := 0; IF UPDATING('SP1IDEN_FIRST_NAME') OR UPDATING('SP1IDEN_LAST_NAME') OR UPDATING('SP1IDEN_MI') THEN IF (:OLD.SP1IDEN_FIRST_NAME = :NEW.SP1IDEN_FIRST_NAME) AND (:OLD.SP1IDEN_LAST_NAME = :NEW.SP1IDEN_LAST_NAME) AND (:OLD.SP1IDEN_MI = :NEW.SP1IDEN_MI) THEN NULL; ELSE SELECT COUNT(*) INTO contador FROM SATURN.SIBINST WHERE SIBINST_PIDM = :NEW.SPRIDEN_PIDM; IF contador > 0 THEN SELECT SP2IDEX_ID INTO ID FROM SATURN.SP2IDEX WHERE SP2IDEX.SPRIDEN_PIDM = :OLD.SPRIDEN_PIDM AND SP2IDEX_ID LIKE '@%'; UPDATE SATURN.DWH_PROFESOR SET APELLIDO_PATERNO_PROFESOR = :NEW.SP1IDEN_FIRST_NAME, APELLIDO_MATERNO_PROFESOR = :NEW.SP1IDEN_MI, NOMBRE_PROFESOR = :NEW.SP1IDEN_LAST_NAME,
/*El trigger es lanzado después de una actualización a la tabla SP1IDEN*/ /*Se valida que se hay actualizado alguno de los campos en los que esta el nombre, apellido paterno o matrno */ /*Se valida que el dato actualizado sea diferente al que se tenía*/ /*Se revisa que registro actualizado sea de una persona habilitada como profesor*/ /*Se obtienen los datos que forman la llave en el Data Warehouse*/ /*Se lleva a cabo la actualización en la tabla que
87
FECHA_ULTIMA_MODIFICACION = SYSDATE WHERE CLAVE_PERSONA = ID; END IF; END IF; ELSE NULL; END IF; EXCEPTION WHEN NO_DATA_FOUND THEN RETURN; END; /
transferirá los datos al Data Warehouse*/ /*Manejo de excepciones*/
A.10 Trigger SO1DEGR_UPDATE
CREATE OR REPLACE TRIGGER SO1DEGR_UPDATE AFTER UPDATE ON SO1DEGR FOR EACH ROW DECLARE contador number; Nivel VARCHAR2(5); GradMax varchar2(5); ID varchar2(10); Cambio number; DocITESM number; MaesITESM number; LicITESM number; GradITESM number; EdITESM number; EmITESM number; EdNoITESM number; EmNoITESM number; BEGIN contador := null; GradMax := null; Nivel := null; Cambio := 0; DocITESM := 0; MaesITESM:= 0; LicITESM := 0; GradITESM:= 0; IF UPDATING ('SO1DEGR_ESTATUSESCOLARIDAD') THEN IF (:OLD.SO1DEGR_ESTATUSESCOLARIDAD = :NEW.SO1DEGR_ESTATUSESCOLARIDAD) THEN NULL; ELSE SELECT SP2IDEX_ID INTO ID FROM SATURN.SP2IDEX WHERE SPRIDEN_PIDM = :OLD.SORDEGR_PIDM AND SP2IDEX_ID LIKE '@%'; IF (:NEW.SO1DEGR_ESTATUSESCOLARIDAD = 'T') THEN SELECT CLAVE_GRADO_MAXIMO_PROF, DOCTORADO_ITESM, MAESTRIA_ITESM, LICENCIATURA_ITESM, ALGUN_GRADO_ITESM, ESTUDIA_DOCTORADO_ITESM, ESTUDIA_MAESTRIA_ITESM, ESTUDIA_DOCTORADO_FUERA_ITESM, ESTUDIA_MAESTRIA_FUERA_ITESM INTO GradMax, DocITESM,MaesITESM,LicITESM,GradITESM,EdITESM, EmITESM, EdNoITESM, EmNoITESM FROM SATURN.DWH_PROFESOR WHERE CLAVE_PERSONA = ID; IF (GradMax = '09') THEN NULL; ELSE SELECT STVDEGC_DLEV_CODE
/*El trigger es lanzado después de una actualización a la tabla SO1DEGR*/ /*Declaración de variables a usar*/ /*Se valida que el campo actualizado sea el que tiene el dato del estatus de una escolaridad*/ /*Se valida que el dato actualizado sea diferente al que se tenía*/ /*Se revisa que registro actualizado sea de una persona habilitada como profesor*/ /* Si el estatus del grado acádemico se actualiza con Terminado ‘T’ se extraen los datos referentes a los grados académicos de la tabla dwh_profesor*/
88
INTO Nivel FROM SATURN.STVDEGC WHERE STVDEGC_CODE = :NEW.SORDEGR_DEGC_CODE; IF (Nivel='14') THEN IF (GradMax<='05') THEN Cambio := 1; END IF; ELSE IF (GradMax < Nivel) THEN Cambio := 1; END IF; END IF; IF (Cambio = 1) THEN UPDATE SATURN.DWH_PROFESOR SET CLAVE_GRADO_MAXIMO_PROF = Nivel WHERE CLAVE_PERSONA = ID; END IF; END IF; Cambio := 0; Nivel := Null; SELECT STVDEGC_DLEV_CODE INTO Nivel FROM SATURN.STVDEGC WHERE STVDEGC_CODE = :NEW.SORDEGR_DEGC_CODE AND SUBSTR(STVDEGC_CODE,1,1) NOT IN ('0','1','2','3','4','5','6','7','8','9'); IF (Nivel='09') THEN DocITESM := DocITESM + 1; GradITESM := GradITESM + 1; END IF; IF (Nivel='08') THEN MaesITESM := MaesITESM + 1; GradITESM := GradITESM + 1; END IF; IF (Nivel='05') THEN LicITESM := LicITESM + 1; GradITESM := GradITESM + 1; END IF; IF (:OLD.SO1DEGR_ESTATUSESCOLARIDAD = 'C') THEN SELECT COUNT(*) INTO contador FROM DUAL WHERE SUBSTR(:NEW.SORDEGR_DEGC_CODE,1,1) NOT IN ('0','1','2','3','4','5','6','7','8','9'); IF contador > 0 THEN IF (Nivel='09') THEN EdITESM := EdITESM-1; END IF; IF (Nivel='08') THEN EmITESM := EmITESM-1; END IF; ELSE IF (Nivel='09') THEN EdNoITESM:=EdNoITESM-1; END IF; IF (Nivel='08') THEN EmNoITESM := EmNoITESM-1; END IF; END IF; END IF; UPDATE SATURN.DWH_PROFESOR SET DOCTORADO_ITESM = DocITESM, MAESTRIA_ITESM = MaesITESM, LICENCIATURA_ITESM = LicITESM, ALGUN_GRADO_ITESM = GradITESM, ESTUDIA_DOCTORADO_ITESM = EdITESM, ESTUDIA_MAESTRIA_ITESM = EmITESM, ESTUDIA_DOCTORADO_FUERA_ITESM = EdNoITESM, ESTUDIA_MAESTRIA_FUERA_ITESM = EmNoITESM, FECHA_ULTIMA_ACTUALIZACION = SYSDATE WHERE CLAVE_PERSONA = ID; ELSE
/*Se obtienen el nivel del grado académico*/ /*Se actualiza el grado máximo cuando el nivel obtenido es menor al de la tabla dwh_profesor*/ /*Si el grado académico pertenece al ITESM, se incrementa en 1 la variable correspondiente al nivel del grado*/ /*Si el estatus anterior del grado era Cursando ‘C’, se decrementa en 1 la variable correspondiente al nivel del grado */ /*Se lleva a cabo la actualización en la tabla que transferirá los datos al Data Warehouse*/
89
IF (:NEW.SO1DEGR_ESTATUSESCOLARIDAD = 'C') THEN SELECT ESTUDIA_DOCTORADO_ITESM, ESTUDIA_MAESTRIA_ITESM, ESTUDIA_DOCTORADO_FUERA_ITESM, ESTUDIA_MAESTRIA_FUERA_ITESM INTO EdITESM, EmITESM, EdNoITESM, EmNoITESM FROM SATURN.DWH_PROFESOR WHERE CLAVE_PERSONA = ID; BEGIN SELECT STVDEGC_DLEV_CODE INTO Nivel FROM SATURN.STVDEGC WHERE STVDEGC_CODE = :NEW.SORDEGR_DEGC_CODE AND SUBSTR(STVDEGC_CODE,1,1) NOT IN ('0','1','2','3','4','5','6','7','8','9'); IF (Nivel='09') THEN EdITESM := EdITESM + 1; Cambio := 1; END IF; IF (Nivel='08') THEN EmITESM := EmITESM + 1; Cambio := 1; END IF; EXCEPTION WHEN NO_DATA_FOUND THEN Nivel := NULL; END; IF (Nivel is Null) THEN SELECT STVDEGC_DLEV_CODE INTO Nivel FROM SATURN.STVDEGC WHERE STVDEGC_CODE = :NEW.SORDEGR_DEGC_CODE; IF (Nivel='09') THEN EdNoITESM := EdNoITESM + 1; Cambio := 1; END IF; IF (Nivel='08') THEN EmNoITESM := EmNoITESM + 1; Cambio := 1; END IF; END IF; IF (Cambio = 1) THEN UPDATE SATURN.DWH_PROFESOR SET ESTUDIA_DOCTORADO_ITESM = EdITESM, ESTUDIA_MAESTRIA_ITESM = EmITESM, ESTUDIA_DOCTORADO_FUERA_ITESM = EdNoITESM, ESTUDIA_MAESTRIA_FUERA_ITESM = EmNoITESM, FECHA_ULTIMA_ACTUALIZACION = SYSDATE WHERE CLAVE_PERSONA = ID; END IF; END IF; END IF; END IF; END IF; EXCEPTION WHEN NO_DATA_FOUND THEN RETURN; WHEN TOO_MANY_ROWS THEN RETURN; END; /
/*Si el estatus nuevo del grado es Cursando ‘C’, se extraen los datos referentes a los grados académicos de la tabla dwh_profesor*/ /*Incrementa la variable correspondiente al nivel del grado académico que se está estudiando y si pertenece al ITESM o no*/ /*Se lleva a cabo la actualización en la tabla que transferirá los datos al Data Warehouse*/ /*Manejo de excepciones*/
A.11 Trigger DWH_ESCOLAR_UPDATE
CREATE OR REPLACE TRIGGER DWH_PROFESOR_UPDATE AFTER UPDATE ON DWH_PROFESOR
/*El trigger es
90
FOR EACH ROW DECLARE contador NUMBER(8); BEGIN SELECT COUNT(*) INTO contador FROM DWHDIRECTIVOS.dhw_profesor@DWH_PPRD WHERE CLAVE_CAMPUS = :NEW.CLAVE_CAMPUS AND CLAVE_EJERCICIO_ACADEMICO_EFEC = :NEW_CLAVE_EJERCICIO_ACADEMICO_EFEC AND CLAVE_PERSONA = :NEW.CLAVE_PERSONA; IF contador > 0 THEN UPDATE DWHDIRECTIVOS.DWH_PROFESOR@DWH_PPRD SET NOMINA = :NEW.NOMINA, APELLIDO_PATERNO_PROFESOR=:NEW.APELLIDO_PATERNO_PROFESOR, APELLIDO_MATERNO_PROFESOR=:NEW.APELLIDO_MATERNO_PROFESOR, NOMBRE_PROFESOR=:NEW.NOMBRE_PROFESOR, TITULO_TRATO_PROFESOR=:NEW.TITULO_TRATO_PROFESOR, CLAVE_CATEGORIA_LABORAL=:NEW.CLAVE_CATEGORIA_LABORAL, DESC_CATEGORIA_LABORAL=:NEW.DESC_CATEGORIA_LABORAL, CLAVE_CLASIFICACION_DOCENTE=:NEW.CLAVE_CLASIFICACION_DOCENTE, DESC_CLASIFICACION_DOCENTE=:NEW.DESC_CLASIFICACION_DOCENTE, CLAVE_GRADO_MAXIMO_PROF=:NEW.CLAVE_GRADO_MAXIMO_PROF, DESC_GRADO_MAXIMO_PROF=:NEW.DESC_GRADO_MAXIMO_PROF, PERIODOS_EXPERIENCIA_PROF=:NEW.PERIODOS_EXPERIENCIA_PROF, DOCTORADO_ITESM=:NEW.DOCTORADO_ITESM, MAESTRIA_ITESM=:NEW.MAESTRIA_ITESM, LICENCIATURA_ITESM=:NEW.LICENCIATURA_ITESM, ALGUN_GRADO_ITESM=:NEW.ALGUN_GRADO_ITESM, ESTUDIA_DOCTORADO_ITESM=:NEW.ESTUDIA_DOCTORADO_ITESM, ESTUDIA_MAESTRIA_ITESM=:NEW.ESTUDIA_MAESTRIA_ITESM, ESTUDIA_DOCTORADO_FUERA_ITESM= :NEW.ESTUDIA_DOCTORADO_FUERA_ITESM, ESTUDIA_MAESTRIA_FUERA_ITESM= :NEW.ESTUDIA_MAESTRIA_FUERA_ITESM, FECHA_ULTIMA_MODIFICACION=SYSDATE WHERE CLAVE_CAMPUS=:NEW.CLAVE_CAMPUS AND CLAVE_EJERCICIO_ACADEMICO_EFEC= :NEW_CLAVE_EJERCICIO_ACADEMICO_EFEC AND CLAVE_PERSONA=:NEW.CLAVE_PERSONA; ELSE NULL; INSERT INTO DWHDIRECTIVOS.DWH_PROFESOR@DWH_PPRD VALUES (CLAVE_CAMPUS,NOMBRE_CAMPUS,SIGLAS_CAMPUS, CLAVE_EJERCICIO_ACADEMICO_EFEC,DESC_EJERCICIO_ACADEMICO_EFEC, CLAVE_PERSONA,NOMINA,APELLIDO_PATERNO_PROFESOR, APELLIDO_MATERNO_PROFESOR,NOMBRE_PROFESOR, TITULO_TRATO_PROFESOR,CLAVE_CATEGORIA_LABORAL, DESC_CATEGORIA_LABORAL,CLAVE_CLASIFICACION_DOCENTE, DESC_CLASIFICACION_DOCENTE,CLAVE_GRADO_MAXIMO_PROF, DESC_GRADO_MAXIMO_PROF,PERIODOS_EXPERIENCIA_PROF, DOCTORADO_ITESM,MAESTRIA_ITESM,LICENCIATURA_ITESM, ALGUN_GRADO_ITESM,ESTUDIA_DOCTORADO_ITESM, ESTUDIA_MAESTRIA_ITESM,ESTUDIA_DOCTORADO_FUERA_ITESM, ESTUDIA_MAESTRIA_FUERA_ITESM); END IF; EXCEPTION WHEN NO_DATA_FOUND THEN RETURN; END; /
lanzado después de una actualización en la tabla DWH_PROFESOR*/ /*Se valida que el registro exista en la tabla DWH_PROFESOR remota*/ /*Si ya existe se actualizan los datos*/ /*Sino se inserta un registro nuevo*/ /*Manejo de excepciones*/
