Sistema de Registro y Seguimiento paraTitulacion de la U.M.S.N.H.

Heriberto Quezada Moreno

3 de diciembre de 2007

Indice general

1. Generalidades 11.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2. ERwin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2.1. Definicion de fuentes de datos ODBC . . . . . . . . . . 31.2.2. El metamodelo de ERwin . . . . . . . . . . . . . . . . 3

1.3. Delphi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3.1. Version de Delphi . . . . . . . . . . . . . . . . . . . . . 61.3.2. El entorno de desarrollo . . . . . . . . . . . . . . . . . 7

1.4. Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.4.1. Oracle Server . . . . . . . . . . . . . . . . . . . . . . . 81.4.2. Seguridad en Oracle . . . . . . . . . . . . . . . . . . . 81.4.3. Gestion del espacio . . . . . . . . . . . . . . . . . . . . 91.4.4. Conectividad de caracter abierto . . . . . . . . . . . . 91.4.5. Herramientas de desarrollo . . . . . . . . . . . . . . . . 101.4.6. Accesibilidad de los datos . . . . . . . . . . . . . . . . 101.4.7. Componente procedimental . . . . . . . . . . . . . . . 101.4.8. SQL *PLUS . . . . . . . . . . . . . . . . . . . . . . . . 111.4.9. Base de datos orientada a objetos . . . . . . . . . . . . 121.4.10. Arquitectura de la Base de Datos . . . . . . . . . . . . 131.4.11. Objetos de la Base de Datos . . . . . . . . . . . . . . . 141.4.12. PL/SQL . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.5. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2. Modelado de la base de datos 162.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.2. Requerimientos del usuario . . . . . . . . . . . . . . . . . . . . 162.3. Identificacion de entidades y atributos . . . . . . . . . . . . . 222.4. Normalizacion . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

i

2.4.1. Primera forma normal . . . . . . . . . . . . . . . . . . 242.4.2. Segunda forma normal . . . . . . . . . . . . . . . . . . 252.4.3. Tercera forma normal . . . . . . . . . . . . . . . . . . . 27

2.5. Modelo logico . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.6. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3. Implementacion de la base de datos 313.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.2. Tablas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.2.1. FINANZAS.FCXCOBR . . . . . . . . . . . . . . . . . 323.2.2. FINANZAS.FCLIENTES . . . . . . . . . . . . . . . . 323.2.3. FINANZAS.FPERSONAS . . . . . . . . . . . . . . . . 323.2.4. FINANZAS.FURES . . . . . . . . . . . . . . . . . . . 333.2.5. FINANZAS.FPROGRAM . . . . . . . . . . . . . . . . 333.2.6. FINANZAS.FINGRESOS . . . . . . . . . . . . . . . . 333.2.7. ESCOLAR.EREVEXPED . . . . . . . . . . . . . . . . 343.2.8. ESCOLAR.EDGPCARRERA . . . . . . . . . . . . . . 343.2.9. ESCOLAR.ESINODALES . . . . . . . . . . . . . . . . 343.2.10. ESCOLAR.ETSINODAL . . . . . . . . . . . . . . . . . 353.2.11. ESCOLAR.ECITATRAM . . . . . . . . . . . . . . . . 353.2.12. ESCOLAR.EDCITATRAM . . . . . . . . . . . . . . . 353.2.13. ESCOLAR.EPAIS . . . . . . . . . . . . . . . . . . . . 353.2.14. ESCOLAR.EEDOS . . . . . . . . . . . . . . . . . . . . 353.2.15. ESCOLAR.EMUNIPS . . . . . . . . . . . . . . . . . . 363.2.16. ESCOLAR.EMODATITU . . . . . . . . . . . . . . . . 363.2.17. ESCOLAR.ETITULOS . . . . . . . . . . . . . . . . . . 36

3.3. Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.3.1. FINANZAS.FCXCOBR . . . . . . . . . . . . . . . . . 373.3.2. FINANZAS.FCLIENTES . . . . . . . . . . . . . . . . 393.3.3. FINANZAS.FPERSONAS . . . . . . . . . . . . . . . . 403.3.4. FINANZAS.FURES . . . . . . . . . . . . . . . . . . . 413.3.5. FINANZAS.FPROGRAM . . . . . . . . . . . . . . . . 423.3.6. ESCOLAR.EREVEXPED . . . . . . . . . . . . . . . . 423.3.7. ESCOLAR.EDGPCARRERA . . . . . . . . . . . . . . 433.3.8. ESCOLAR.ESINODALES . . . . . . . . . . . . . . . . 433.3.9. ESCOLAR.ETSINODALES . . . . . . . . . . . . . . . 443.3.10. ESCOLAR.ECITATRAM . . . . . . . . . . . . . . . . 443.3.11. ESCOLAR.EDCITATRAM . . . . . . . . . . . . . . . 45

ii

3.3.12. ESCOLAR.EPAIS . . . . . . . . . . . . . . . . . . . . 463.3.13. ESCOLAR.EEDOS . . . . . . . . . . . . . . . . . . . . 463.3.14. ESCOLAR.EMUNIPS . . . . . . . . . . . . . . . . . . 463.3.15. ESCOLAR.EMODATITU . . . . . . . . . . . . . . . . 463.3.16. ESCOLAR.ETITULOS . . . . . . . . . . . . . . . . . . 47

3.4. Triggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483.4.1. ESCOLAR.EVTCXCOBR$II . . . . . . . . . . . . . . 493.4.2. ESCOLAR.EVTCXCOBR$IU . . . . . . . . . . . . . . 513.4.3. ESCOLAR.EREVEXPED$AU . . . . . . . . . . . . . . 523.4.4. ESCOLAR.ETITULOS$AU . . . . . . . . . . . . . . . 543.4.5. ESCOLAR.ETITULOS$BU . . . . . . . . . . . . . . . 55

3.5. Vistas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563.5.1. ESCOLAR.EVTCXCOBR . . . . . . . . . . . . . . . . 563.5.2. ESCOLAR.EVREVEXPED . . . . . . . . . . . . . . . 573.5.3. ESCOLAR.EVTITULOS . . . . . . . . . . . . . . . . . 573.5.4. ESCOLAR.EVSEGCESC . . . . . . . . . . . . . . . . 583.5.5. ESCOLAR.EVFORMATODGP . . . . . . . . . . . . . 59

3.6. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4. Programas 604.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604.2. EVTCXCOBR . . . . . . . . . . . . . . . . . . . . . . . . . . 604.3. EVREVEXPED . . . . . . . . . . . . . . . . . . . . . . . . . . 614.4. EVTITULOS . . . . . . . . . . . . . . . . . . . . . . . . . . . 624.5. EVIMPRDOCTOS . . . . . . . . . . . . . . . . . . . . . . . . 624.6. EVSEGCESC . . . . . . . . . . . . . . . . . . . . . . . . . . . 624.7. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5. Conclusiones y Sugerencias 64

A. Manual de Usuario 68A.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68A.2. Generacion de Deuda . . . . . . . . . . . . . . . . . . . . . . . 68A.3. Revision de expediente . . . . . . . . . . . . . . . . . . . . . . 71

A.3.1. Datos Generales . . . . . . . . . . . . . . . . . . . . . . 73A.3.2. Asignacion Por Sinodal . . . . . . . . . . . . . . . . . . 74A.3.3. Asignacion Por Mesa . . . . . . . . . . . . . . . . . . . 74

A.4. Registro Examen Recepcional . . . . . . . . . . . . . . . . . . 77

iii

A.5. Impresion del Tıtulo . . . . . . . . . . . . . . . . . . . . . . . 78A.6. Seguimiento del Tıtulo . . . . . . . . . . . . . . . . . . . . . . 83

B. Diagramas Entidad-Relacion (Modelo Fısico) 88B.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88B.2. Tablas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88B.3. Vistas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

B.3.1. EVTCXCOBR . . . . . . . . . . . . . . . . . . . . . . 90B.3.2. EVREVEXPED . . . . . . . . . . . . . . . . . . . . . . 91B.3.3. EVTITULOS . . . . . . . . . . . . . . . . . . . . . . . 91B.3.4. EVFORMATODGP . . . . . . . . . . . . . . . . . . . 91B.3.5. EVIMPRDOCTOS . . . . . . . . . . . . . . . . . . . . 94B.3.6. EVSEGCESC . . . . . . . . . . . . . . . . . . . . . . . 94

iv

Indice de figuras

2.1. Primera Forma Normal . . . . . . . . . . . . . . . . . . . . . . 252.2. Segunda Forma Normal . . . . . . . . . . . . . . . . . . . . . . 262.3. Tercera Forma Normal . . . . . . . . . . . . . . . . . . . . . . 282.4. Modelo Logico . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

A.1. Generacion de Fichas de Deposito para Pagos de Titulacion . 69A.2. Generacion de Ordenes de Pago . . . . . . . . . . . . . . . . . 70A.3. Revision de Expediente . . . . . . . . . . . . . . . . . . . . . . 73A.4. Captura de Datos Generales . . . . . . . . . . . . . . . . . . . 75A.5. Asignacion de Sinodales por Mesas Predefinidas . . . . . . . . 76A.6. Registro de Examen Recepcional . . . . . . . . . . . . . . . . 77A.7. Captura de Datos del Resultado de Examen Recepcional . . . 79A.8. Impresion de Tıtulos . . . . . . . . . . . . . . . . . . . . . . . 80A.9. Detalle de Impresion de Tıtulos . . . . . . . . . . . . . . . . . 81A.10.Seguimiento de Tıtulos . . . . . . . . . . . . . . . . . . . . . . 82A.11.Reporte de Tıtulos Impresos . . . . . . . . . . . . . . . . . . . 83A.12.Captura de Datos . . . . . . . . . . . . . . . . . . . . . . . . . 84A.13.Captura de Datos de la Direccion General de Profesiones . . . 85A.14.Captura de Datos de Digitalizacion . . . . . . . . . . . . . . . 86A.15.Captura de Datos Entrega de Entrega de Documentos . . . . . 87

B.1. Modelo Fisico . . . . . . . . . . . . . . . . . . . . . . . . . . . 89B.2. Vista de Generacion de Deudas . . . . . . . . . . . . . . . . . 90B.3. Vista de Revision de Expediente . . . . . . . . . . . . . . . . . 91B.4. Vista de Tıtulos . . . . . . . . . . . . . . . . . . . . . . . . . . 92B.5. Vista del Formato de la Direccion General de Profesiones . . . 93B.6. Vista de Impresion de Tıtulos . . . . . . . . . . . . . . . . . . 94B.7. Vista del Seguimiento de Tıtulos . . . . . . . . . . . . . . . . 95

v

Indice de cuadros

2.1. Tipos de Tramites . . . . . . . . . . . . . . . . . . . . . . . . . 20

A.1. Conceptos de Ingreso para pagos de Titulacion . . . . . . . . . 72

vi

Resumen

La tecnologıa no cesa de evolucionar en todos sus aspectos. Nuevos pro-cesadores, posibilidades insospechadas de tratamiento de informacion, capa-cidades de almacenamiento asombrosas y, obviamente, el software necesariopara administrar todo ello.

En este ultimo punto se ha pasado del desarrollo de programas que tenıancomo finalidad principal llevar a cabo una determinada funcion, sin importardemasiado el diseno o la facilidad de uso, a la necesidad cada vez mayorde que sea el software el que se adapte al usuario y no al contrario. Lacausa determinante de este giro es, sin duda alguna, la necesidad de usar unacomputadora, algo que unos anos atras estaba reservado solo a unos pocos.

El Departamento de Titulacion de la Universidad Michoacana se encargade los tramites ante gobierno del estado y la direccion general de profesionespara que el alumno pueda obtener la cedula profesional y el tıtulo, por lo quese tienen las siguientes necesidades:

Contar con un sistema en el cual se registren todos los datos que unalumno requiera para empezar con su tramite de titulacion.

Disponer de los datos en una base de datos en la cual se pueda llevarun seguimiento del tıtulo,

Poder tanto el personal del departamento de titulacion como el alumnoconocer en que tramite se encuentra el tıtulo.

Disponer de una interfaz amigable con la cual poder trabajar. Por con-siguiente se ha desarrollado este trabajo con los siguientes objetivos:

Automatizar el Modulo de Titulacion existente a traves de herramien-tas mas robustas como son la base de datos Oracle y Delphi comoplataforma.

Normalizar el modulo Titulacion e integrarlo al Modulo Escolar delSistema Integral de Informacion Administrativa (SIIA), de acuerdo conlos lineamientos establecidos por la Direccion General de Educacion Su-perior, a traves de la coordinacion del Programa para la normalizacionAdministrativa (PRONAD).

Proporcionar una herramienta al departamento de Titulacion con lacual puedan llevar un mejor control de sus procesos.

El proceso que lleva a cabo el departamento de Titulacion desde el momentoque llega un alumno a solicitar una revision de expediente hasta el momentoque se le entrega un tıtulo es el siguiente:

El alumno acude al departamento de titulacion con los documentos reque-ridos para solicitar la revision de expediente, el departamento de titulacion legenera las deudas correspondientes y por cada deuda generada se le entregauna orden de pago para el banco y le asigna una fecha de revision, ademasse le hace saber de la documentacion que tendra que presentar en la fecha derevision.

Una vez llegada la fecha de revision el alumno acude al departamento detitulacion con la documentacion previamente solicitada, el departamento detitulacion hace la revision de expediente y de la documentacion. Si el alumnocumple con los requisitos se le asigna una fecha de examen y para algunasdependencias se le asigna ademas una mesa sinodal.

Pasada la fecha de examen el departamento de titulacion toma datos delos libros de actas de examen y a los que fueron aprobados se procede agenerar el documento llamado tıtulo que despues sera enviado al director deControl Escolar para firma. Despues es enviado a la Secretaria General dela Universidad para firma del Rector y del Secretario General. El tıtulo seenvıa despues a Gobierno del Estado para su certificacion y registro. Despuesse envıa el numero de tıtulo y otros datos en un formato preestablecido ala Direccion General de Profesiones para registrarlo y mandar despues lacertificacion y la cedula profesional.

Continuando los tramites el tıtulo es enviado al Departamento de Digi-talizacion para ser digitalizado.

Digitalizado el tıtulo, puede ser entregado a la persona interesada identi-ficada previamente, ademas que debe de firmar de recibido.

En conclusion, el trabajo que se presenta pretende poner al alcance delusuario un sistema amigable y sencillo en el cual puedan tener el control deregistro y seguimiento de tıtulos, ademas de unir en el SIIA ( sistema integralde informacion administrativa) los submodulos Escolar con el de Finanzasen cuanto a la generacion de deudas y pago a sinodales.

ii

Capıtulo 1

Generalidades

1.1. Introduccion

La sofisticacion de las interfaces de usuario, cada vez mas complejasy completas, acarrean una carga extra de trabajo al programador. Ya no solotiene que preocuparse de que su programa realice la funcion para la queesta pensado sino que, ademas, debe tener en cuenta que el aspecto de laaplicacion sea agradable y que sea facil de usar por cualquier usuario, inclusosin necesidad de consultar manuales.

La cantidad de trabajo necesaria para el desarrollo de la interfazde usuario puede, en ocasiones, ser superior a la empleada en el nucleo de laaplicacion, que es realmente el punto importante y en el que el programadordeberıa de centrar la mayor parte de sus esfuerzos.

En este capıtulo se hablara de la interfaz que se utilizara para larealizacion de este proyecto (Delphi), ası como de la base de datos utilizada(Oracle) y el software usado para poder implementarla (ERwin).

1.2. ERwin

ERwin 3.5 es una version de Logic Works [15] que confiere gananciasa las herramientas de modelado de datos, esta construido con caracterısticasrobustas para el diseno de base de datos. ERwin 3.5 puede ayudar al desarro-llo mas seguro y eficiente de base de datos. ERwin es poderoso y economizatiempo en el diseno de una base de datos. Tiene las siguientes caracterısticas:

1

1.2. ERWIN 2

Diseno de almacenamiento de datos construido con herramientas demodelos dimensionales.

Calculo de tamano de la base de datos basados en objetos fısicos yespacio de los datos estimados que se pueden proporcionar en un editorespecializado.

Atributos independientes y columnas que se pueden arrastrar y borrardesde un browser dentro de una entidad o tabla que ayuda rapidamentea definir atributos propios o columnas con una logica predefinida ypropiedades fısicas.

Capacidad del usuario para definir propiedades en Objetos de Erwinque se pueden crear y guardar con el modelo y generarlo a la base dedatos.

Mejora la interfaz de usuario al seleccionar la opcion para generar elesquema de modelo de datos de ingenierıa inversa desde la base dedatos.

Opcion de pantalla gr’fica reforzada que ayuda entre otras cosas a iden-tificar objetos en el modelo de datos tales como llaves primarias, tipode datos y roles de tablas dimensionales. Incluye una fuente de mu-chos iconos (archivos bitmap) que se pueden asignar a objetos logicosy fısicos; o se pueden importar iconos propios.

Edicion de reportes dinamicos que se pueden crear o modificar. Porejemplo: Se puede cambiar el nombre a una tabla en la edicion delreporte y Erwin automaticamente cambia el nombre a la tabla corres-pondiente en el modelo de datos.

ERwin tiene muchos rasgos poderosos que le permiten el diseno demodelado de datos entidad - relacion y modelos dimensionales, se puede creary puede mantener bases de datos en muchos diferentes servidores. Pero quizasel rasgo mas poderoso es su simplicidad y facilidad de uso.

ERwin usa muchos de los rasgos del sistema operativo Windowsnormales y convenciones. Ası como se puede crear, modificar, guardar e im-primir documentos en otras aplicaciones de Windows, se pueden realizar estasmismas tareas en ERwin que usa dialogos familiares de Windows.

FIE UMSNH

1.2. ERWIN 3

1.2.1. Definicion de fuentes de datos ODBC

ERwin usa ODBC (Conectividad a una base de datos abierta) comosoftware para acceder bases de datos desde una PC. ODBC divide las tareasde acceso de datos entre un driver de la base de datos y una fuente de datos.Un driver ODBC de base de datos es una librerıa de enlace dinamico quecomunica las demandas a un sistema particular de direccion de bases dedatos, como Access, Paradox, o dBASE, etc.

Una fuente de datos ODBC es una especificacion guardada eso aso-cia a un driver particular con los archivos de la base de datos a los que sequiere accesar con ese driver, como acceso de un archivo .MDB o dBASEque son archivos .DBF. Para conectar una base de datos de PC especıfico aERwin, debe definirse como un ODBC datos fuente que usa el ODBC Admi-nistrador programa. El ODBC Administrador viene con Acceso de Microsoft,FoxPro, Aventaje, Formule para Windows, y otros paquetes del software queapoyan a drivers de ODBC para los datos Acceso. El ODBC Administradormetodo se explica debajo. Para informacion en usar herramientas del clientecomo PowerBuilder configurar ODBC datos fuentes, vea la documentacionque viene con sus herramientas de desarrollo de cliente, como PowerBuilderesta Conectando a la Guıa de la base de datos.

El Administrador de ODBC esta disponible en versiones de 16 bitsy 32 bits.

1.2.2. El metamodelo de ERwin

Un modelado de datos completo de ERwin contiene toda la infor-macion que se requiere para generar una base de datos fısica en un servidordesignado. Similarmente, toda la definicion de la informacion interior queERwin exige para dibujar un modelo de datos esta contenido en un modeloespecial de datos llamado Diccionario de datos del Meta modelo de ERwin.

Se puede generar el meta modelo de ERwin para crear un diccionariode datos que guarde informacion sobre las estructuras de los datos usadas enmodelos de ERwin.

Se describe cada entidad en el meta modelo de ERwin en ordenalfabetico y listas de nombres, descripcion del tipo de datos, valores validos, ylas llaves foraneas propias de cada uno de sus atributos en una tabla separada.La informacion de la entidad del meta modelo es seguida por tablas en lasque listan valores validos por varios atributos el meta modelo.

FIE UMSNH

1.3. DELPHI 4

Cada tabla incluye el nombre de todos los atributos incluidos en esaentidad en el orden en que ellos aparecen en el meta modelo. Las columnasen la tabla incluyen:

Nombre del Atributo cuando aparece en el modelo logico.

Tipos de Datos: Lista el tipo de dato predefinido asignado a la colum-na de la tabla. El actual tipo de datos usado es dependiente en cadaservidor designado que acostumbra a sostener el diccionario de ERwin.

Descripcion: indica el tipo de informacion guardada por el atributo.

Valores Validos: Lista los valores validos, la referencia de la tabla quecontiene la lista de valores validos, o expresion de validacion para elatributo. Donde no se ha definido la regla de validacion, los datos debenconformar los atributos del tipo de datos.

FK indica si el atributo es una llave Foranea (FK). Esta columna estavacıa para los atributos de una llave no foranea.

La lınea gris en cada tabla separa los atributos importantes (sobre lalınea) de los atributos no importantes (debajo de la lınea) para cada entidad.Para entidades que tienen solamente un solo atributo, ese atributo es uncampo de llave.

1.3. Delphi

Actualmente las plataformas que cuentan con una mayor base deaplicaciones utiles, construidas y tambien en desarrollo, son las que se basanen una interfaz grafica tipo Windows u OS/2, centrandonos en el mundo delos compatible PC. Los programas para sistemas como DOS poco a pocovan dejando de aparecer, lo cual provoca que los existentes vayan quedandoanticuados y, por lo tanto, su utilidad se vaya viendo mermada.

El exito de Windows 95/98 y Windows NT entre los usuarios tienecomo consecuencia que este sea el entorno para el que se desarrollan masaplicaciones en la actualidad. Inicialmente, el lenguaje practicamente obli-gado para poder programar en Windows era C, que aun hoy es el elegidopor muchos programadores. Posteriormente aparecieron los compiladores deC++ con jerarquıas de clases especıficas para facilitar la programacion en

FIE UMSNH

1.3. DELPHI 5

Windows, como Objeto Windows de Borland o Foundation Classes de Mi-crosoft. El desarrollo de aplicaciones mediante estas herramientas, salvandolas dificultades de la programacion orientada a objetos, se veıa simplificadoen gran medida, gracias a que muchos aspectos de Windows se encuentran.embebidos.en objetos no siendo necesario conocer ni usar la mayor parte delAPI de Windows.

El siguiente paso en el avance hacia un desarrollo mas facil de apli-caciones Windows lo constituye la aparicion de las herramientas de desarrollovisual, cuyos componentes mas conocidos son Borland Delphi de Inprise yVisual Basic de Microsoft. La creacion de aplicaciones mediante un entornode este tipo se basa en el uso de componentes o controles prefabricados, queson dispuestos en ventanas y personalizados mediante propiedades. De estaforma, la creacion de la interfaz de usuario ha pasado de ser un tedioso tra-bajo de escritura de codigo a unas simples operaciones de raton y poco mas.El programador puede volver a centrarse en el nucleo del programa, en eltratamiento de la informacion, y no necesita preocuparse de la gestion de laventana sobre la que se visualizan los datos, ni de la forma en que el usuariose puede desplazar de un lugar a otro, por poner un ejemplo.

Los entornos de desarrollo visual, ademas de simplificar la creacionde la interfaz, tambien facilitan en gran medida otras operaciones habitualesen Windows como la comunicacion con otras aplicaciones, el uso de cuadrosde dialogo comunes, la gestion de bases de datos, etc. Cada elemento, visualo no, de un programa viene representado por un componente.

A pesar de la simplicidad que denota este tipo de entornos, hay quetener en cuenta que siempre sera necesario escribir algo de codigo para queuna aplicacion realice una funcion util.

Aunque es posible crear programas consistentes tan solo en lo quees la interfaz, al ejecutarlos, obviamente, solo tendremos eso: una ventanacon algunos elementos que pueden responder a las acciones del usuario, peroque no generaran ningun resultado a partir de la informacion introducida,que es la finalidad principal de cualquier aplicacion. El codigo necesario pararealizar determinadas funciones de la aplicacion estara escrito en un lenguajeconcreto, que sera la base del entorno de desarrollo visual que estemos usando.El lenguaje base de Borland Delphi es Object Pascal, una potente version dePascal que hereda toda la experiencia que Inprise ha adquirido durante masde una decada de desarrollo de compiladores de este lenguaje.

Borland Delphi [13], que represento la primera apuesta de Inpri-se por un entorno de desarrollo netamente visual, sigue evolucionando y lo

FIE UMSNH

1.3. DELPHI 6

hace convirtiendose en una herramienta de ultima generacion sumamenteavanzada. El entorno de desarrollo de Delphi es simple, flexible y potenteal mismo tiempo, contando con un gran numero de componentes prefabrica-dos que simplificaran de forma notable la creacion de cualquier aplicacion.El lenguaje de base de Borland Delphi, como se ha dicho antes, es ObjectPascal.

Algo que diferencia a Delphi de muchos de sus competidores es elhecho de tratarse de un compilador altamente optimizado, que genera codigodirectamente ejecutable, no pseudo-codigo que debe ser interpretado poste-riormente en tiempo de ejecucion. Esto tiene basicamente dos consecuencias:el ejecutable es mas rapido, al no tener que ser interpretado en tiempo deejecucion y el tamano final total de la aplicacion suele ser inferior, ya queno es necesaria la distribucion adicional del programa que interpreta y eje-cuta el codigo al que se suele denominar runtime. Delphi no es un lenguajede programacion simple, como su antecesor Pascal. Es mas bien un sistemade desarrollo que combina un potente lenguaje de programacion orientado aobjetos y eventos(Object Pascal), con un entorno de desarrollo grafico. Paradesarrollar nuestras aplicaciones no simplemente escribimos codigo que luegose compila y enlaza: Gran parte de la aplicacion, sobre todo la interfaz grafica,se genera automaticamente de forma interactiva gracias a las herramientasgraficas que son los componentes de Delphi.

Esta tecnica de trabajo ahorra muchos laboriosos pasos en la quela programacion si la comparamos con los sistemas convencionales. Antes,en Windows, era necesario disenar previamente los recursos en un editor derecursos. Hoy ya se integra el diseno y el codigo del recurso en el propio codigode la aplicacion. Esta manera de programar una aplicacion en un lenguajevisual se denomina RAD (Rapid Application Development).

1.3.1. Version de Delphi

La version Client/Server Suite incluye el entorno visual, el BorlandDatabase Engine de 32 bits y todos los componentes necesarios para el desa-rrollo de aplicaciones, incluyendo reportes en QuickReport, un servidor localy licencia de desarrollo de Interbase, un controlador de versiones de codigofuente, drivers de acceso nativo a Oracle, Sysbase, Informix, etc., y las he-rramientas SQL Explorer y SQL Monitor. Esta version esta disenada parael desarrollo de aplicaciones en entorno Cliente/Servidor, con bases de datosSQL, y plataformas varias (NT, Unix, Novell, etc.).

FIE UMSNH

1.4. ORACLE 7

1.3.2. El entorno de desarrollo

El modulo basico de una aplicacion en Delphi consta de dos partes:el ”Form”(ventana), y sus componentes. La ventana define el area de trabajoy se comporta como contenedor de los componentes, cuya mision consisteen realizar los procesos especıficos. Delphi obtiene una gran parte de su ca-pacidad productiva de la utilizacion de una biblioteca de objetos conocidacomo VCL (Biblioteca de Componentes Visuales). Es ademas, SDI (SingleDocumentation Interfase) en la cual tenemos una ventana principal que sereconoce por ser la que contiene el menu.

1.4. Oracle

Oracle [14] es una empresa lıder e innovadora en el campo de latecnologıa informatica. Comenzo con la tecnologıa portable de bases de da-tos relacionales, que aparecio en el mercado a finales de los anos setenta.En 1984, Oracle consiguio portar su base de datos relacional al entorno delas computadoras de escritorio. La siguiente version de Oracle, la version 5,hizo que el mercado fuera consciente de las posibilidades de la arquitecturacliente/servidor y la distribucion de datos. Ası como de la vialidad de eje-cutar un downsizing de las aplicaciones para grandes sistemas informaticos.La base de datos relacional de la version 6 de Oracle, con su revolucionariomodelo de bloqueo a nivel fila, el innovador lenguaje PL/SQL y la posibili-dad de ejecutarse las aplicaciones de bases de datos relacionales dentro de unmercado completamente nuevo. Oracle 7 proporciono la tecnologıa necesariapara construir aplicaciones con una fiabilidad y una disponibilidad muy altas,para el ambito empresarial y de trabajo en grupo en red.

Con las nuevas versiones de Oracle, los disenadores y desarrolladoresde sistemas pueden construir aplicaciones que van desde sistemas de misioncrıtica para el procesamiento de transacciones interactivas que admiten milesde usuarios, hasta almacenes de datos multiterabyte para la asistencia ala toma de decisiones. Oracle, un componente integral de la arquitecturade computacion en red de Oracle, proporciona una base comun para lasaplicaciones cliente/servidor y las basadas en la World Wide Web.

Los sistemas de procesamiento interactivo de transacciones requie-ren un rendimiento muy alto, y los usuarios demandan velocidad de precisiony un tiempo de desarrollo razonable. Los sistemas de almacen de datos tra-

FIE UMSNH

1.4. ORACLE 8

tan, hoy en dıa, cantidades de informacion en el rango de terabytes, y losusuarios necesitan poder acceder a dicha informacion rapidamente.

Oracle es uno de los principales actores en el mercado de las ba-ses de datos. El nucleo de la oferta de Oracle es su tecnologıa de servidorcooperativo, que es la base de los demas productos y servicios que ofrece.

1.4.1. Oracle Server

El servidor de Oracle es un entorno avanzado de gestion de la infor-macion. Permite almacenar grandes cantidades de datos y proporciona a losusuarios acceso rapido a los mismos. El servidor Oracle permite la compar-ticion de datos entre aplicaciones; la informacion se almacena en un ciertolugar y puede ser utilizada por muchos sistemas. Al principio, el servidor Ora-cle estaba disponible en versiones para Solaris de Sun y Windows NT. Losnuevos servidores Oracle corren sobre docenas de diferentes computadoras,permitiendo las configuraciones siguientes:

Basada en host: Los usuarios se conectan directamente a la mismacomputadora en que reside la base de datos.

Cliente/servidor: Los usuarios acceden a la base de datos desde sucomputadora personal (cliente) a traves de una red, y la base de datosse encuentra en una computadora diferente (servidor).

Procesamiento distribuido. Los usuarios acceden a una base de datosque reside en mas de una computadora. La base de datos esta repartidaentre varias maquinas, y los usuarios no tienen por que conocer lalocalizacion fısica de los datos con los que se estan trabajando.

Computacion Compatible con la Web. La posibilidad de acceder a losdatos desde una aplicacion basada en Internet.

1.4.2. Seguridad en Oracle

Mecanismos de seguridad.Los sofisticados mecanismos de seguridad de Oracle controlan el ac-

ceso a los datos sensibles utilizando un conjunto de privilegios. En funciondel nombre con el que se conectan a la base de datos, a los usuarios se lesconceden derechos para consultar, modificar y crear datos. Los clientes usan

FIE UMSNH

1.4. ORACLE 9

estos mecanismos para asegurarse de que ciertos usuarios pueden consultarlos datos de caracter sensible, mientras que a otros se les niega dicha posibi-lidad.

Realizacion de copias de seguridad y recuperacion.Oracle proporciona sofisticados procedimientos de realizacion de

copias de seguridad y recuperacion de datos. Las copias de seguridad permi-ten crear una copia secundaria de los datos de Oracle; los procedimientos derecuperacion restauran los datos a partir de una copia de seguridad. La es-trategia de copias de seguridad y recuperacion de Oracle permite minimizarla perdida de datos y el tiempo de parada cuando se produce un problema.Oracle Server tambien proporciona esquemas de copia de seguridad y recupe-racion que permite un acceso ininterrumpido a los datos 7 dıas a la semana,24 horas al dıa y 365 dıas al ano.

1.4.3. Gestion del espacio

Oracle ofrece una gestion flexible del espacio. Se puede asignar uncierto espacio de disco para el almacenamiento de los datos, y controlar lassubsiguientes asignaciones instruyendo a Oracle sobre cuanto espacio reservarpara los requerimientos futuros. Tambien tiene una serie de caracterısticasque fueron disenadas teniendo en cuanta las necesidades de las bases de datosde muy gran tamano. De hecho, muchas de las mas recientes caracterısticasde Oracle y de la versiones anteriores fueron disenadas pensando en los al-macenes de datos (data warehouses), que son, por su propio diseno, bases dedatos de tamano muy grande.

1.4.4. Conectividad de caracter abierto

Oracle proporciona conectividad hacia y desde paquetes softwarede otros fabricantes. Utilizando extensiones a la base de datos Oracle, sepuede trabajar con informacion almacenada con otros sistemas de bases dedatos, como DB2 de IBM, Sysbase o Microsoft Access. Tambien se puedenalmacenar los datos en la base de datos de Oracle y acceder a ellos desdeotros paquetes software, como Visual Basic, Borland Delphi, Powerbuilderde Powersoft,o SQL*Windows de Gupta.

FIE UMSNH

1.4. ORACLE 10

1.4.5. Herramientas de desarrollo

El servidor de Oracle, al que normalmente se denomina motor de labase de datos, funciona con un amplio conjunto de herramientas de desarrollo,herramientas de consulta para un usuario final, aplicaciones comerciales yherramientas de gestion de la informacion de ambito corporativo.

1.4.6. Accesibilidad de los datos

Con Oracle Server, se adquiere una serie completa de funcionalida-des basicas para ayudarnos a almacenar los datos y mantenerlos accesibles.Esto incluye utilidades para realizar copias de seguridad de los datos, lascuales se pueden llevar a cabo incluso mientras los usuarios estan trabajandocon ellos. El termino que se acostumbra utilizar para explicar este conceptoes el de Copia de Seguridad en Caliente”, pero el termino oficial de Oraclepara designar esta capacidad de hacer una copia de seguridad de una seriede daros activos es Copias de Seguridad en Modo Archivo”(Archive ModeBackups). Ya no es necesario que se interrumpa el acceso a los datos porparte de las aplicaciones mientras se realiza la copia de seguridad de la basede datos, por lo que se puede mantener en funcionamiento todo el tiempo.

El servidor de Oracle tambien se encarga de la integridad de la basede datos. Si se produce cualquier tipo de fallo mientras un usuario esta cam-biando los datos en una base de datos, esta tiene la capacidad de deshacero cancelar cualquier transaccion sospechosa. Con Oracle Server nunca se al-bergan dudas en lo referente al estado de una determinada transaccion. Elservidor incluye tambien un bloqueo completo por filas de todos los datosalmacenados.

1.4.7. Componente procedimental

Esta opcion forma parte del nucleo del servidor Oracle, con lo que elservidor ofrece toda la funcionalidad procedimental. El fundamento de estaopcion es el lenguaje de programacion de Oracle, PL/SQL.

Con esta opcion se pueden implementar las funcionalidades siguien-tes:

Procedimiento almacenado. Se pueden almacenar programas (o seg-mentos de codigo) en la base de datos de Oracle, parar realizar funcio-nes de importancia para nuestro sistema.

FIE UMSNH

1.4. ORACLE 11

Disparadores de la base de datos(Triggers). Son segmentos de codigoalmacenados en la base de datos, y que se disparan como respuesta asucesos que tienen lugar en las aplicaciones.

Paquetes (Packages). Los procedimientos se suelen agrupar, almacenando-se el codigo como una unica unidad de programacion en la base dedatos.

1.4.8. SQL *PLUS

.Es la forma en que se definen y manipulan los datos en la base

de datos relacional de Oracle. SQL (Structured Query Languajes, Lenguajede Consulta Estructurado) es el estandar adoptado por todos los fabrican-tes de bases de datos. El SQL *Plus de Oracle es un superconjunto de SQLestandar: cumple con el estandar de los lenguajes compatibles con SQL, ytiene ademas una serie de extensiones especıficas de Oracle (de ahı el nombre:SQL + Plus). Antiguamente SQL *Plus se denominaba UFI (User-FriendlyInterface, interfaz amigable de usuario). Comparado con el uso de un lengua-je de programacion tıpico, como FORTRAN, resulta, desde luego, amigable.El servidor Oracle solo entiende las ordenes expresadas mediante SQL; cuan-do alguna herramienta, como Oracle Forms, interactua con la base de datos,lo unico que trasmite para su procesamiento son ordenes SQL. La imple-mentacion de SQL de Oracle, SQL *Plus, cumple con los estandares ANSI(American National Standars Institute) e ISO (International Standards Or-ganization). Casi todas las herramientas de Oracle admiten identica sintaxisSQL. SQL fue disenado para sacar el maximo partido del modelo relacional.Puesto que todos los datos se almacenan mediante la relacion, es posibletrabajar con los datos en forma de conjuntos, en lugar de con filas indepen-dientes de datos. Con SQL *Plus, la mayor parte del trabajo asociado con laextraccion de datos de una base de datos tradicional desaparece. Por ejemplo,no es necesario leer un registro; en lugar de ello, lo que se hace es escribir unprograma que maneja todos los registros asociados con una cierta entidad.Ningun registro es diferente de los otros. En SQL *Plus, cualquier accion quese realice se ejecuta como un conjunto completo.

FIE UMSNH

1.4. ORACLE 12

1.4.9. Base de datos orientada a objetos

Oracle7 fue la primera version de la base de datos de Oracle queincorporo la tecnologıa orientada a objetos. Se trata de una base de datosobjeto-relacional, dado que esta implementacion no es una base de datosorientada a objetos pura, ni tampoco es una base de datos relacional, re-presenta un hıbrido de ambas. El termino base de datos objeto-relacional seusa para describir una base de datos que ha evolucionado desde el modelorelacional hasta una base de datos hıbrida, que contiene ambas tecnologıas,relacional y de objeto. Una base de datos orientada a objetos es aquella quepuede almacenar datos, las relaciones entre ellos y su comportamiento (es de-cir, la forma en que interactuan unos datos con otros). El metodo orientadoa objetos trata los objetos que circundan a los datos. En una base de datosorientada a objetos, cuando se trata con el cliente, se trabaja con un objetodenominado cliente”. Cuando se trabaja con un pedido, se hace referenciaun objeto denominado ”pedido”. Puesto que una base de datos de objetosentiende el objeto cliente y todas sus relaciones, puede facilmente tratar conel objeto cliente y todo aquello que sea necesario para trabajar con el. Enel modelo relacional, un pedido es realmente una combinacion de diferentestablas, con tablas de interseccion que contienen todos los atributos necesariospara admitir y mantener dicho pedido. A diferencia del modelo de objetos, enel que la base de datos conoce las interrelaciones, en el modelo relacional estono es ası. Cuando en el modelo relacional se efectua un cambio, usualmentese traduce en una nueva serie completa de tablas que deben desarrollarse sise quiere continuar trabajando con el modelo.

Objeto: Son representaciones software de las entidades del mundo real.Los objetos contienen informacion operacional y atributos.

Clase: Son plantillas para los objetos

Encapsulacion: Significa que cada objeto de la base de datos tiene unainterfaz bien definida, con lımites precisos.

Extensibilidad. Es la capacidad de una base de datos orientada a ob-jetos para anadir nuevos objetos y sus comportamientos asociados, sinafectar a los demas objetos y aplicaciones.

Herencia. Es la capacidad de crear clases de objetos nuevas como espe-cializaciones de clases existentes.

FIE UMSNH

1.4. ORACLE 13

Polimorfismo. Es la capacidad de los objetos para reaccionar de formadiferente a un mensaje identico. Un objeto reacciona de distinta ma-nera en base a la informacion suministrada, es capaz de interpretar elcontexto de la informacion que ha sido introducida.

1.4.10. Arquitectura de la Base de Datos

Base de Datos Es una coleccion de programas que manipula los archivosde datos. En esta se almacenan dos tipos de datos:

Datos del usuario: Son los datos de la aplicacion, junto con todala informacion relativa a las aplicaciones.

Datos del sistema: Constituyen la informacion que la base de datosnecesita para gestionar los datos de usuario y a sı misma.

Espacios de tablas Es una coleccion de uno o mas archivos de datos. Enmuchas bases de datos se requieren o son habituales los siguientes es-pacios de tablas:

System: Contiene la informacion que Oracle necesita para gestio-narse a sı misma y a los datos.

Temp: Es un area utilizada como borrador por Oracle. En deter-minadas ocasiones, Oracle necesita espacio de disco para gestionarsus propias transacciones o una transaccion de usuario.

Tools: Almacena los objetos que necesitan las herramientas que seejecutan sobre una base de datos Oracle.

Users: Almacena los objetos de la base de datos que pertenecen alos usuarios.

Rollback: Es donde normalmente se almacenan los segmentos deanulacion del objeto de la base de datos.

Los espacios de tablas de datos e ındices almacenan los datos dela aplicacion.

Index: Un ındice es un tipo especial de objeto de la base de datos.Oracle utiliza ındices para acelerar la recuperacion de datos.

Programas Existen dos tipos de programas o procesos:

FIE UMSNH

1.4. ORACLE 14

Proceso del Usuario: Solicitan informacion a los procesos del ser-vidor. Por ejemplo SQL *PLUS.

Proceso del Servidor: Reciben las solicitudes de los procesos deusuario e interactuan con la base de datos.

1.4.11. Objetos de la Base de Datos

Cada objeto tiene una tarea o proposito especıfico que cumplir, losprincipales objetos de la base de datos son los siguientes:

Tablas Es un objeto de la base de datos que almacena datos. Esta formadapor varıas columnas. Cada una de estas columnas tiene un tipo de datoasociado. Este tipo de dato es el mapa de carreteras que Oracle siguepara saber como manipular correctamente los contenidos.

Vistas Es un objeto de la base de datos que permite crear una seleccionpersonalizada de una tabla o de una coleccion de tablas. No contieneningun dato, solamente una consulta SQL que se presenta en forma detabla.

Indices Es una forma rapida de acceder a los datos.

Sinonimos Es un objeto de la base de datos que permite crear nombresalternativos para las vistas y tablas.

Concesiones Oracle proporciona un control amplio sobre lo que un usuariopuede ver, modificar, borrar o cambiar. Las concesiones se usan paradar a un usuario privilegios para trabajar con los datos de otro usuario.

Select Permite a los demas usuarios mirar los contenidos de la tablas de lasque no son propietarios.

Insert Permite crear filas en tablas de otros usuarios.

Update Permite a otros usuarios modificar o cambiar datos de las tablas delas que no son propietarios.

Delete Permite a los usuarios borrar filas de informacion de las tablas es-pecificadas.

FIE UMSNH

1.5. CONCLUSIONES 15

1.4.12. PL/SQL

Oracle ha implementado un lenguaje de procesamiento procedimen-tal denominado PL/SQL. Tiene estructuras de programacion parecidas a lasde la mayorıa de los lenguajes de programacion.

Hay dos versiones de PL/SQL: una es parte del motor de base dedatos, y la otra es un motor separado incluido en algunas herramientas deOracle. Se denominan, respectivamente, PL/SQL de base de datos y PL/SQLde herramienta. Son muy similares: utilizan las mismas estructuras, sintaxis,y mecanismos logicos de programacion. El PL/SQL de herramienta tiene unasintaxis adicional, disenada para satisfacer los requisitos de las herramientas.

Toda la codificacion de Procedimientos, Disparadores de bases dedatos (triggers), paquetes (packages) y funciones se hace utilizando PL /SQL.

1.5. Conclusiones

La decision de optar por Oracle es porque es una de las bases dedatos mas confiables, seguras, comerciales y dinamicas que existen, y Delphiaprovecha estas cualidades para poder interactuar con ella, utiliza compo-nentes nativos con los cuales se hacen los accesos directos a la base de datos.

Para facilitar el diseno e implementacion de la base de datos seutilizo el ERwin, tambien por el facil acceso y compatibilidad con Oracle.

FIE UMSNH

Capıtulo 2

Modelado de la base de datos

2.1. Introduccion

Una base de datos es una coleccion integrada de datos organizadapara satisfacer los requerimientos de informacion de los usuarios de una em-presa, por medio de procesos de captura, validacion, almacenamiento, actua-lizacion, integridad, calculo, presentacion, respaldo y restauracion de datos;ademas de incluir los recursos, polıticas y metodos de diseminacion de lainformacion.

Para poder realizar un buen modelado de una base de datos serequiere analizar la informacion para los requerimientos del usuario ya que deestos datos obtenidos se obtienen el estado de los principios de normalizacion.

Las reglas de normalizacion estan encaminadas a eliminar redun-dancias e inconsistencias de dependencia en el diseno de las tablas. Para esose siguen algunos pasos progresivos para normalizar, y ası obtener una basede datos funcional y eficiente.

2.2. Requerimientos del usuario

El departamento de titulacion se encarga de los tramites ante go-bierno del estado y la direccion general de profesiones para que el alumnopueda obtener la cedula profesional y el tıtulo. Para ello, se requiere elabo-rar ordenes de pago con diferentes conceptos como pueden ser derechos detitulacion y pago a sinodales. Para la elaboracion de estas, el departamentode titulacion necesita saber el identificador que la universidad le otorga a

16

2.2. REQUERIMIENTOS DEL USUARIO 17

la persona cuando esta ingresa a cualquier dependencia de la universidad,ademas se necesitan tener datos de los alumnos como son nombre completo(nombre(s), primer apellido y segundo apellido), fecha de nacimiento, sexo,foto, paıs, estado y municipio de nacimiento.

Al elaborarse las ordenes de pago se necesitan conocer la Depen-dencia (Unidad Responsable) de la que egresaron y el tıtulo al cual aspiran,ademas se establece una fecha lımite de pago que es la fecha de revision deexpediente, controlando un cupo maximo de 20 revisiones por dıa. La Direc-cion General de Profesiones establecio claves unicas asignadas a cada carreraque se ofrece en las diferentes dependencias educativas del paıs, para elloproporciono un catalogo el cual tiene dos columnas que son Clave y Descrip-cion, la primera es el identificador unico para cada carrera y la segunda esuna descripcion de la carrera, estas claves deben de ir relacionadas con unaunidad responsable y un programa.

Una vez llegada la fecha de revision el interesado se presenta al de-partamento de titulacion en el cual se le revisa la documentacion que requierela Direccion General de Profesiones. El numero y tipo de documentos variadependiendo de la Dependencia, pero en general son los siguientes:

1. Acta de Nacimiento original y dos copias fotostaticas tamano carta,recientes y en buen estado

2. Dos copias de la C.U.R.P. (Clave unica de registro de poblacion)

3. Servicio Social UMSNH Original y Copia fotostatica tamano carta

4. Solicitud de Registro de Tıtulo y expedicion de Cedula profesional (ori-ginal y copia a maquina)

5. Oficio de Practicas Profesionales (Direccion de la Escuela)

6. Carta de no adeudo a la Biblioteca Publica del Centro

7. Oficio de Aprobacion de Tema de Tesis

8. Oficio de Aprobacion de Tesis

9. Oficio Asignacion de Jurado

10. Dos Tesis al Departamento de Titulacion y seis para la Escuela, total8 empastados y originales

FIE UMSNH

2.2. REQUERIMIENTOS DEL USUARIO 18

11. Recibo de Cooperacion a la Escuela

12. Certificado Medico de la Facultad de Medicina.

13. Recibos de pago a Tesorerıa U.M.S.N.H. (Por concepto de: Certificados,Honorarios de Jurado, Gastos diversos de examen) basados en las fichasde deposito anexas

14. Pagar recibo de legalizacion de firmas en Gobernacion (Palacio de Go-bierno)

15. Fotografıas blanco y negro ovaladas de frente (Fondo blanco) con elnombre al reverso con lapiz: 3 Tıtulo, 6 Credencial, 4 Infantil papelmate. Nota: Los hombres las fotografıas tıtulo y credencial de saco ycorbata, sin lentes y sin barba

Esta revision se hace con los siguientes fines

Corregir datos del nombre, apellidos, fecha y lugar de nacimiento en elsistema,

Recabar toda la documentacion e informacion que requieren el Depar-tamento de Titulacion y la direccion General de Profesiones para laexpedicion del tıtulo y de la cedula profesional.

En la revision de expediente, para aquellos que cumplieron con todos losrequisitos solicitados por el departamento se procede a:

asignar una fecha de examen recepcional,

registrar la modalidad de titulacion que pueden ser:

• examen general por conocimiento,

• diplomado,

• servicio profesional,

• tesis, tesina,

• por promedio,

• por curso y

• por seminario,

FIE UMSNH

2.2. REQUERIMIENTOS DEL USUARIO 19

registrar el asesor de tesis o tesina,

registrar el tema de tesis y para algunas dependencias

asignar la mesa sinodal que evaluara la presentacion de dicho examen.

En los otros casos la dependencia es la que asigna la mesa sinodal.Las mesas sinodales se componen de un presidente de mesa, se-

cretario (solo para algunas dependencias), vocales y suplentes por lo que esnecesario saber el nombre de estas personas para despues generarle sus pagospor su participacion.

Finalizada la revision para el caso de la Facultad de IngenierıaQuımica que se titularon por curso se envıa un oficio al Director de la Fa-cultad donde se le informa que el alumno aprobo el curso y se le asigna unafecha de examen recepcional. Para la Facultad Derecho y Ciencias Sociales seenvıa un oficio de autorizacion en el que se avisa que el alumno cumplio contodos los requisitos y que pueden asignarle fecha de examen y mesa sinodal.Para las demas dependencias se envıa una circular a cada miembro de lamesa sinodal para comunicarles la fecha de examen del alumno y ademas seenvıa un oficio al presidente de la mesa para comunicarle que se le propu-so para fungir como presidente la Mesa de Jurados que aplicara el examenrecepcional a dicha persona.

Una vez presentado el examen recepcional se procede a registrarel resultado, el cual puede ser Aprobado, No Aprobado, No se Presento oPendiente. Solo en el caso de que el resultado sea Aprobado se procede a laimpresion del tıtulo y su seguimiento:

Se pasa al Director de Control de Escolar para sello y firma

Se envıa a la Secretaria General para su firma.

De la Secretaria General pasa al Rector para su firma.

Rectorıa regresa el tıtulo al Departamento de Titulacion.

El Departamento de Titulacion imprime la leyenda de Gobierno deEstado en la parte posterior del tıtulo.

Se envıa con oficio a certificacion y firma del responsable en Gobiernodel Estado

FIE UMSNH

2.2. REQUERIMIENTOS DEL USUARIO 20

CLAVE DESCRIPCION

C EXPEDICION DE CEDULA

D DUPLICADO DE CEDULA

ES EXPEDICION DE ESPECIALIDADDE DUPLICADO DE ESPECIALIDADM MAESTRIADC DOCTORADO

RP REPOSICIONEX EXTRANJERO

Cuadro 2.1: Tipos de Tramites

Gobierno del Estado regresa el tıtulo al Departamento de Titulacioncon los datos de fecha y numero de registro.

El Departamento de Titulacion envıa los datos del egresado en un for-mato especıfico a la Direccion General de profesiones. El Formato que seenvıa a la Direccion General de Profesiones tiene los siguientes campos

• Clave unica de registro de poblacion (CURP)

• Id. de la Institucion (para la Universidad Michoacana la clave es160001)

• Paterno

• Materno

• Nombre

• Matricula (solo aplica para extranjeros)

• Id. Carrera (Se tomara del catalogo de carreras proporcionado)

• Tipo (A1 si es Especialidad, C1 para expedicion de cedula, D2duplicado de Especialidad, D1 duplicado de expedicion)

• Tipo Tramite ( se tomara de la tabla 2.1)

• Fecha Nacimiento (En el formato ano, mes, DIA AAAAMMDD)

• Entidad de Nacimiento (Se tomara del catalogo de entidades)

• Cedula Anterior (Aplica para tıtulos de Maestrıa o doctorado)

• Sexo (1 Masculino, 2 Femenino)

FIE UMSNH

2.2. REQUERIMIENTOS DEL USUARIO 21

• Fecha Captura (En el formato ano, mes, dıa AAAAMMDD)

• Causa de Reposicion (en caso de reposicion se pone una brevedescripcion del o de los errores en la cedula)

• Nacionalidad (se pondra la clave del paıs, 003 para la nacionalidadMexicana).

La Direccion General de Profesiones regresa al Departamento de Titu-lacion la Cedula profesional y el numero de registro del tıtulo.

El Departamento de Titulacion envıa el tıtulo al Departamento de Di-gitalizacion.

El Departamento de Digitalizacion regresa el tıtulo al Departamentode Titulacion.

El Departamento de Titulacion entrega el tıtulo.

El alumno firma de recibido tıtulo y Cedula Profesional.

Para este seguimiento del tıtulo es necesario registrar fechas de envıoy de recibido a los lugares donde se manda, ademas de registrar datos delgobierno como son la fecha de registro y numero de registro en Gobierno delEstado. Se registra tambien los datos de la Direccion general de Profesionesque son:

registro a fojas,

numero de libro,

grados academicos bajo el numero,

numero de cedula y

la fecha de registro.

Al momento de entrega el interesado debera firmar de recibido tıtuloy cedula profesional.

FIE UMSNH

2.3. IDENTIFICACION DE ENTIDADES Y ATRIBUTOS 22

2.3. Identificacion de entidades y atributos

En base a los requerimientos del usuario se definio la siguiente listade datos:

1. Referencia bancaria

2. Matricula del alumno

3. Nombre completo del alumno

4. Clave unica de Registro de Poblacion (CURP)

5. Fecha de nacimiento del alumno

6. Sexo del alumno

7. Paıs de Nacimiento

8. Estado de nacimiento del alumno

9. Municipio de nacimiento del alumno

10. Nombre del tıtulo otorgado por la Direccion General de Profesiones

11. Unidad Responsable

12. Programa

13. Predecesor del Programa

14. Concepto a pagar

15. Monto

16. Fecha limite

17. Numero de revision de expediente

18. Fecha de revision

19. Fecha de examen propuesta por el Departamento de Titulacion

20. Modalidad de titulacion

FIE UMSNH

2.3. IDENTIFICACION DE ENTIDADES Y ATRIBUTOS 23

21. Asesor

22. Tema de tesis

23. Resultado de la revision

24. Sinodales

25. Tipo de sinodal

26. Numero de Registro del tıtulo

27. Observaciones

28. Fecha de presentacion del examen

29. Resultado del Examen

30. Fecha de elaboracion o impresion del tıtulo

31. Folio del tıtulo

32. Fecha de envıo a la Secretaria General

33. Fecha de firma del Secretario General

34. Fecha de firma del rector

35. Fecha de recibido de rectorıa

36. Fecha de impresion de la certificacion de Gobierno del Estado

37. Fecha de envıo a Gobierno del Estado

38. Numero de oficio para envıo a Gobierno del Estado

39. Fecha de recibido de Gobierno del Estado

40. Fecha de registro en Gobierno del Estado

41. Numero de registro en Gobierno del Estado

42. Fecha de envıo a la Direccion General de Profesiones

43. Fecha de recibido de la Direccion General de Profesiones

FIE UMSNH

2.4. NORMALIZACION 24

44. Registro a Fojas en la Direccion General de Profesiones

45. Numero de libro en la Direccion General de Profesiones

46. Numero de grados academicos en la Direccion General de Profesiones

47. Numero de cedula profesional

48. Fecha de registro en la Direccion General de Profesiones

49. Fecha de envıo a digitalizacion o a archivo

50. Fecha de recibido de digitalizacion o archivo

51. Numero de expediente

52. Fecha de entrega de documentos al interesado

53. Firma digital

2.4. Normalizacion

El diseno logico agrupa los atributos de la BD por medio de rela-ciones de datos estructuradas que se obtienen mediante transformaciones:

Relacion: exige que las celdas de una tabla dispongan de un solovalor, y no permite que ningun renglon tenga los mismos valores que losdemas; ademas de que todos los valores de cualquier columna deben ser delmismo tipo y disponer de un nombre unico, pero el orden de las columnasno es significativo ni el de los renglones valor en cada atributo

2.4.1. Primera forma normal

Remueve grupos repetidos de datos, dedicando un solo valor encada atributo - es decir, el dato almacenado en el espacio representado en lainterseccion entre cada renglon y columna de una tabla.

Se hace una tabla separada para cada conjunto de atributos rela-cionados, y se le da a cada tabla una llave primaria. Para nuestro caso secrearıan tres tablas, que serian CUENTAS POR COBRAR, tomando comollave primaria la Referencia bancaria que es un numero consecutivo; REVI-SION DE EXPEDIENTE, teniendo como llave primaria tambien un numero

FIE UMSNH

2.4. NORMALIZACION 25

Figura 2.1: Primera Forma Normal

Figura 2.2: Segunda Forma Normal

consecutivo unico y TITULOS, que tendrıa un numero consecutivo comollave primaria tambien. La primera forma Normal quedarıa como la figura2.1

2.4.2. Segunda forma normal

En este paso de Normalizacion se eliminan datos redundantes. Siun atributo depende solamente en una parte de una llave multivaluada sequita y se pone en una tabla separada, es el caso de las descripciones de lasllaves, por ejemplo la Descripcion Unidad Responsable, descripcion Progra-ma, Descripcion modalidad de Titulacion, nombre alumno, nombre sinodal,nombre asesor, y descripcion Direccion General de Profesiones, se crean nue-vas tablas, por lo que la segunda forma normal quedarıa como se muestra enla figura 2.2

2.4.3. Tercera forma normal

En esta forma se eliminan las columnas no dependientes de la lla-ve. Si los atributos no contribuyen para la descripcion de la llave. Se quitanlas dependencias transitivas, atributos que no son llaves, llamados determi-nantes, al no contener valores unicos o no ser usados como referencias paraacceso directo son dependientes de uno o mas atributos que tampoco no sonllaves. Por ejemplo, en la tabla de Tıtulos existe una Numero de revisionde Expediente, ademas estan las llaves de Matricula Alumno, Clave Progra-ma, Clave Unidad Responsable, Clave Modalidad de Titulacion, estos datosno contribuyen a al descripcion de la llave, ademas a traves de la tabla deRevision Expediente se pueden conocer esos datos. Otros atributos que nocontribuyen a la descripcion de llave son las claves programa y Clave UnidadResponsable en la tabla de Revision de Expediente, esos datos se pasarıan a

FIE UMSNH

2.5. MODELO LOGICO 26

Figura 2.3: Tercera Forma Normal

Figura 2.4: Modelo Logico

la tabla de Direccion General de Profesiones, ya que ahı si contribuyen a ladescripcion de la llave. La tercera forma normal quedarıa como se muestraen la figura 2.3:

2.5. Modelo logico

El diseno logico agrupa los atributos de la BD por medio de relacio-nes de datos estructuradas que se obtienen mediante transformaciones, paranuestro caso el modelo logico es el que se muestre en la figura 2.4

Figura 2.4 Modelo Logico.

2.6. Conclusiones

La normalizacion es una tecnica que se utiliza para crear relacio-nes logicas apropiadas entre tablas de una base de datos. Ayuda a prevenirerrores logicos en la manipulacion de datos. Facilita tambien agregar nuevascolumnas sin romper el esquema actual ni las relaciones.

Las reglas de normalizacion existen como guıas para crear tablasque sean faciles de manejar, ademas que sean flexibles y eficientes. A vecespuede ocurrir que normalizar los datos hasta el nivel mas alto no tengasentido. Las tres formas presentadas proveen suficiente nivel de normalizacionpara cumplir con las necesidades de la base de datos. Normalizar demasiadopuede conducir a tener una base de datos ineficiente y hacer al esquemademasiado complejo para trabajar. Un balance apropiado de sentido comunpuede ayudarnos a decidir cuando normalizar.

FIE UMSNH

Capıtulo 3

Implementacion de la base dedatos

3.1. Introduccion

Una base de datos es una serie de archivos estructurados en unacomputadora que estan organizados de una manera muy eficiente. Estos ar-chivos pueden almacenar bastante informacion que puede ser manipulada yllamada cuando se le necesite. Esta organizada en forma jerarquica de arri-ba hacia abajo. Inicia con una base de datos que contiene cierto numero detablas. Cada tabla esta compuesta por columnas o campos. Los datos estanalmacenados en filas o registros, el lugar donde cada fila se intercepta conuna columna se llama celda.

La base de datos es creada en tres principales esquemas: Escolar,Finanzas y personal, todos los esquemas estan relacionados entre sı.

El lenguaje utilizado en la creacion de las tablas, vistas contrainstses SQL, y para la creacion de triggers su utiliza el lenguaje PL/SQL ( Pro-cedural Language extension to SQL), introducido por Oracle en 1988 en laversion Oracle 6.

3.2. Tablas

Una tabla es un sistema relacional que se compone de una fila decabeceras de columna, junto con cero o mas filas de valores de datos.

27

3.2. TABLAS 28

3.2.1. FINANZAS.FCXCOBRTabla donde se almacenan las deudas generadas a los alumnos, lla-

madas tambien cuentas por cobrar, creada en el esquema de finanzas.

Create Table FINANZAS.FCXCOBR

(cxco_cxcobr number(15, 0) not null ,

cxco_cliente varchar2(12),

cxco_fecha date ,

cxco_ingreso varchar2(8) ,

cxco_materia varchar2(8) ,

cxco_ciclo varchar2(8) ,

cxco_prog varchar2(8) ,

cxco_sfdo varchar2(8) ,

cxco_ures varchar2(8) ,

cxco_monto number(16, 2) ,

cxco_pagado number(16, 2) ,

cxco_descrip varchar2(35) ,

cxco_texto varchar2(300) ,

cxco_usu varchar2(30) default user,

cxco_fec date default sysdate,

cxco_feclimite date ,

cxco_feccancel date)

3.2.2. FINANZAS.FCLIENTES

Tabla donde se almacen los datos de alumnos, creada en el esquemade finanzas.

Create Table FINANZAS.FCLIENTES

(clie_cliente varchar2(12) not null ,

clie_rfc varchar2(14) ,

clie_nombre varchar2(35) ,

clie_apepat varchar2(35) ,

clie_apemat varchar2(35) ,

clie_curp varchar2(18) ,

clie_fechanac date ,

clie_pais varchar2(3),

clie_edonac varchar2(3),

clie_mponac varchar2(3),

clie_direccion varchar2(300) ,

clie_telefono varchar2(100) ,

clie_contactos varchar2(100) ,

clie_sexo varchar2(1) default ’m’,

clie_estud varchar2(1) default ’s’,

clie_activo varchar2(1) default ’s’,

clie_foto long raw,

clie_usu varchar2(30) default user,

clie_fec date default sysdate,

clie_fecfoto date)

3.2.3. FINANZAS.FPERSONASTabla donde se almacenan los datos de los empleados de la Uni-

versidad Michoacana, tanto academicos como administrativos. Creada en elesquema Finanzas.

Create Table FINANZAS.FPERSONAS

(pers_persona varchar2(12) not null ,

pers_rfc varchar2(14) ,

pers_nombre varchar2(35) ,

pers_apepat varchar2(35) ,

pers_apemat varchar2(35) ,

pers_usuario varchar2(30) ,

pers_direccion varchar2(300) ,

FIE UMSNH

3.2. TABLAS 29

pers_telefono varchar2(100) ,

pers_contactos varchar2(100) ,

pers_sexo varchar2(1) default ’m’,

pers_empleado varchar2(1) default ’n’,

pers_cajero varchar2(1) default ’n’,

pers_cancela varchar2(1) default ’n’,

pers_proveedor varchar2(1) default ’n’,

pers_activo varchar2(1) default ’s’,

pers_foto long raw,

pers_curp varchar2(18) ,

pers_tercero varchar2(1) ,

pers_jurado varchar2(1) default ’n’,

pers_usu varchar2(30) default user,

pers_fec date default sysdate)

3.2.4. FINANZAS.FURESTabla de almacenamiento de Unidades Responsables o dependen-

cias. Creada en el esquema de Finanzas.

create table FINANZAS.FURES

(ures_tures varchar2(8) ,

ures_ures varchar2(8) not null ,

ures_pures varchar2(8) ,

ures_pures_pres varchar2(8) ,

ures_descrip varchar2(35) ,

ures_texto varchar2(300) ,

ures_ent_data varchar2(1) default ’s’,

ures_usu varchar2(30) default user,

ures_fec date default sysdate,

ures_imss varchar2(35))

3.2.5. FINANZAS.FPROGRAM

Tabla creada para almacenar el catalogo de programas. Creada enel esquema de Finanzas.

create table FINANZAS.FPROGRAM

(prog_prog varchar2(8) not null ,

prog_pprog varchar2(8) ,

prog_funcion varchar2(8) ,

prog_descrip varchar2(35) ,

prog_texto varchar2(300) ,

prog_ent_data varchar2(1) default ’s’,

prog_usu varchar2(30) default user,

prog_fec date default sysdate,

prog_titulo varchar2(300) ,

prog_feccancel date)

3.2.6. FINANZAS.FINGRESOSTabla donde se almacenan los conceptos de ingreso, esta creada en

el esquema finanzas.

create table FINANZAS.FINGRESOS

(ingr_ingreso varchar2(8) not null ,

ingr_descrip varchar2(35) ,

ingr_texto varchar2(300) ,

ingr_cnta varchar2(8) ,

ingr_scta varchar2(12) ,

ingr_punit number(16, 2) default 0,

ingr_prog varchar2(8) ,

ingr_ures varchar2(8) ,

FIE UMSNH

3.2. TABLAS 30

ingr_sfdo varchar2(8) default ’1100’,

ingr_cntag varchar2(8) ,

ingr_sctag varchar2(12) ,

ingr_porciento number(5, 2) default 100.00)

3.2.7. ESCOLAR.EREVEXPEDTabla de Revision de Expediente, creada en el esquema Escolar.

Create table ESCOLAR.EREVEXPED

(reve_revision number not null ,

reve_cliente varchar2(12) ,

reve_prog varchar2(8) ,

reve_ures varchar2(8) ,

reve_dgpcarrera varchar2(8),

reve_dcita number,

reve_fecharev date ,

reve_fechaexamen date ,

reve_asesor varchar2(12) ,

reve_tematesis varchar2(300) ,

reve_numexped varchar2(20) ,

reve_mesa number(15, 0) ,

reve_modaclave varchar2(4) ,

reve_resultado varchar2(3) ,

reve_fecdig date ,

reve_cxcobr number(15, 0) ,

reve_usu varchar2(30) default user,

reve_fec date default sysdate,

reve_cusu varchar2(30) ,

reve_cfec date)

3.2.8. ESCOLAR.EDGPCARRERATabla del catalogo de claves y descripciones de la Direccion General

de Profesiones, esta creada en esquema Escolar.

Create table ESCOLAR.EDGPCARRERA

(dgpc_dgpcarrera varchar2(8) not null ,

dgpc_descrip varchar2(255) ,

dgpc_prog varchar2(8) ,

dgpc_titulo varchar2(300) ,

dgpc_texto varchar2(300) ,

dgpc_ures varchar2(8) ,

dgpc_usu varchar2(30) default user,

dgpc_fec date default sysdate,

dgpc_cusu varchar2(30) ,

dgpc_cfec date)

3.2.9. ESCOLAR.ESINODALESTabla en donde se registran los sinodales asignados a cada revision.

Creada en el esquema Escolar.

Create Table ESCOLAR.ESINODALES

(sino_sinodal number(15, 0) not null ,

sino_revision number ,

sino_numemp varchar2(12) ,

sino_tipo varchar2(8) ,

sino_insext varchar2(8) ,

sino_polid number(10, 0) ,

sino_usu varchar2(30) default user,

sino_fec date default sysdate)

FIE UMSNH

3.2. TABLAS 31

3.2.10. ESCOLAR.ETSINODALTabla donde se almacenan los diferente tipos de sinodales. Creada

en el esquema Escolar.

Create Table ESCOLAR.ETSINODAL

(tsin_tsinodal varchar2(8) not null ,

tsin_descripcion varchar2(35) ,

tsin_consecutivo number(1, 0))

3.2.11. ESCOLAR.ECITATRAMTabla donde se almacenan las citas para tramites, para el caso de

este trabajo se almacena la cita para el tramite revision de expediente. Creadaen el esquema Escolar.

create table ESCOLAR.ECITATRAM

(cita_cita number not null ,

cita_descrip varchar2(35) ,

cita_tramite varchar2(5) ,

cita_lugadm varchar2(2) ,

cita_ures varchar2(8))

3.2.12. ESCOLAR.EDCITATRAMTabla para almacenar las fechas de revision de expediente, y el con-

trol de cupos para citas. Creada en el esquema Escolar.

create table ESCOLAR.EDCITATRAM

(dcit_dcita number not null ,

dcit_cita number ,

dcit_lugar varchar2(35) ,

dcit_fecha date ,

dcit_activa varchar2(1) default ’s’,

dcit_cupo number default 0,

dcit_citas number default 0)

3.2.13. ESCOLAR.EPAISTabla para almacenar el catalogo de Paıses. Creada en el esquema

Escolar.

create table ESCOLAR.EPAIS

(pais_pais varchar2(3) not null ,

pais_descrip varchar2(35) ,

pais_texto varchar2(300))

3.2.14. ESCOLAR.EEDOSTabla para almacenar el catalogo de Estados ( solo estados de Mexi-

co). Creada en el esquema Escolar.

create table ESCOLAR.EEDOS

(edos_edo varchar2(3) not null ,

edos_descrip varchar2(35) ,

edos_texto varchar2(300))

FIE UMSNH

3.2. TABLAS 32

3.2.15. ESCOLAR.EMUNIPSTabla para almacenar el catalogo de Municipios por estado. Creado

en el esquema de Escolar.

create table ESCOLAR.EMUNIPS

(muni_edo varchar2(2) not null ,

muni_mpo varchar2(3) not null ,

muni_descrip varchar2(40) ,

muni_texto varchar2(300))

3.2.16. ESCOLAR.EMODATITUTabla donde se almacena el catalogo de modalidades u opcion de

titulacion. Creada en el esquema Escolar.

create table ESCOLAR.EMODATITU

(moda_clave varchar2(4) not null ,

moda_descrip varchar2(50) ,

moda_fec date default sysdate,

moda_usu varchar2(30) default user)

3.2.17. ESCOLAR.ETITULOSTabla donde se almacena el registro del tıtulo, ası como el segui-

miento. Creada en el esquema Escolar.

create table ESCOLAR.ETITULOS

(titu_titulo number(15, 0) not null ,

titu_folio number(15, 0) ,

titu_docto varchar2(8) ,

titu_revision number(15, 0) ,

titu_fecha_titulacion date ,

titu_modaclave varchar2(4) ,

titu_resultado varchar2(3) ,

titu_calig varchar2(8) ,

titu_fecimprtitulo date ,

titu_fecha_certce date ,

titu_fecenvsg date ,

titu_fecha_certsg date ,

titu_fecha_certrect date ,

titu_frecibrect date ,

titu_fcertenvgob date ,

titu_fecha_envgob date ,

titu_oficiogob varchar2(15) ,

titu_fecha_reggob date ,

titu_numreggob varchar2(20) ,

titu_frecibgob date ,

titu_fecha_envdgp date ,

titu_oficiodgp varchar2(4) ,

titu_fojasdgp number(4, 0) ,

titu_librodgp varchar2(10) ,

titu_numerodgp number(4, 0) ,

titu_ceduladgp varchar2(12) ,

titu_fecha_regdgp date ,

titu_frecibdgp date ,

titu_fecha_envdig date ,

titu_frecibdig date ,

titu_entrtitulo varchar2(1) ,

titu_entrcedula varchar2(1) ,

titu_fecha_entrega date ,

titu_firma long raw,

titu_observaciones varchar2(300) ,

titu_usu varchar2(30) default user,

titu_fec date default sysdate,

titu_cusu varchar2(30) default user,

titu_cfec date default sysdate)

FIE UMSNH

3.3. CONSTRAINTS 33

3.3. Constraints

Permiten implementar las reglas de Integridad. Previenen el borradode una tabla si hay dependencias de esta y son de los siguientes tipos

Not Null (NN). Especifica que la columna no debe contener valoresnulos

Unique (UK). Especifica una columna o combinacion de columnas lascuales deben tener valores unicos para todos los registros en la tabla

Primary Key (PK). Identificador unico de cada registro de la tabla. Nopuede ser repetido.

Foreign Key (FK). Establece y forza a una relacion con una llaveforanea entre la columna y una columna de una tabla referenciada.

Check (CC). Especifica una condicion que puede ser verdadera.

3.3.1. FINANZAS.FCXCOBRFINANZAS.PK*FCXCOBR*CXCOBR

Llave primaria

Alter table FINANZAS.FCXCOBR

add Constraint PK*FCXCOBR*CXCOBR

primary key ( CXCO_CXCOBR )

using index tablespace INDX

FINANZAS.FK$FCXCOBR$CLIENTE

Llave foranea: Referencia a la columna CLIE_Cliente de la Tabla FINANZAS.FCLIENTES

Alter table FINANZAS.FCXCOBR

add Constraint FK$FCXCOBR$CLIENTE

foreign key (CXCO_CLIENTE)

references FINANZAS.FCLIENTES

( CLIE_CLIENTE )

FINANZAS.FK*FCXCOBR*INGRESO

Llave foranea: Referencia a la columna INGR_Ingreso de la Tabla FINANZAS.FINGRESO

Alter table FINANZAS.FCXCOBR

add Constraint FK*FCXCOBR*INGRESO

foreign key (CXCO_INGRESO)

references FINANZAS.FINGRESOS

( INGR_INGRESO )

FINANZAS.FK*FCXCOBR*PROG

Llave foranea: Referencia a la columna CXCO_Prog de la Tabla FINANZAS.FPROGRAM

Alter table FINANZAS.FCXCOBR

add Constraint FK*FCXCOBR*PROG

foreign key (CXCO_PROG)

references FINANZAS.FPROGRAM

( PROG_PROG )

FINANZAS.FK*FCXCOBR*SFDO

Llave foranea:Referencia a la columna SFON_SFdo de la Tabla FINANZAS.FPROGRAM

Alter table FINANZAS.FCXCOBR

FIE UMSNH

3.3. CONSTRAINTS 34

add Constraint FK*FCXCOBR*SFDO

foreign key (CXCO_SFDO)

references FINANZAS.FSFONDOS

( SFON_SFDO )

FINANZAS.FK*FCXCOBR*URES

Llave foranea: Referencia a la columna URES_URes de la Tabla FINANZAS.FURES

Alter table FINANZAS.FCXCOBR

add Constraint FK*FCXCOBR*URES

foreign key (CXCO_URES)

references FINANZAS.FURES

( URES_URES )

FINANZAS.NN$FCXCOBR$CXCOBR

Validacion para la columna CXCO_CxCobr: no permite valores nulos

Alter table FINANZAS.FCXCOBR

add Constraint NN$FCXCOBR$CXCOBR

check (CXCO_CXCOBR IS NOT NULL)

FINANZAS.NN$FCXCOBR$FECHA

Validacion para la columna CXCO_CxCobr: no permite valores nulos

Alter table FINANZAS.FCXCOBR

add Constraint NN$FCXCOBR$FECHA

check (CXCO_FECHA IS NOT NULL)

FINANZAS.NN$FCXCOBR$FECLIMITE

Validacion para la columna CXCO_FecLimite: no permite valores nulos

Alter table FINANZAS.FCXCOBR

add Constraint NN$FCXCOBR$FECLIMITE

check (CXCO_FECLIMITE IS NOT NULL)

FINANZAS.NN$FCXCOBR$INGRESO

Validacion para la columna CXCO_Ingreso: no permite valores nulos

Alter table FINANZAS.FCXCOBR

add Constraint NN$FCXCOBR$INGRESO

check (CXCO_INGRESO IS NOT NULL)

FINANZAS. NN$FCXCOBR$MONTO

Validacion para la columna CXCO_Monto: no permite valores nulos

Alter table FINANZAS.FCXCOBR

add Constraint NN$FCXCOBR$MONTO

check (CXCO_MONTO IS NOT NULL)

FINANZAS. NN$FCXCOBR$PROG

Validacion para la columna CXCO_Prog: no permite valores nulos

Alter table FINANZAS.FCXCOBR

add Constraint NN$FCXCOBR$PROG

check (CXCO_PROG IS NOT NULL)

FINANZAS. NN$FCXCOBR$SFDO

Validacion para la columna CXCO_SFdo: no permite valores nulos

Alter table FINANZAS.FCXCOBR

add Constraint NN$FCXCOBR$SFDO

check (CXCO_SFDO IS NOT NULL)

FINANZAS. CC$FCXCOBR$FECLIMITE

Validacion para la columna CXCO_FecLimite, debe ser mayor o igual a CXCO_Fecha

Alter table FINANZAS.FCXCOBR

add Constraint CC$FCXCOBR$FECLIMITE

check (CXCO_FECLIMITE >= CXCO_FECHA)

FINANZAS. CC$FCXCOBR$MONTO_CERO

Validacion para la columna CXCO_Monto: Debe ser mayor a cero.

Alter table FINANZAS.FCXCOBR

add Constraint CC$FCXCOBR$MONTO_CERO

check (CXCO_MONTO > 0)

FIE UMSNH

3.3. CONSTRAINTS 35

FINANZAS. CC$FDCXCOBR$DESCUENTO

Validacion para la columna CXCO_Descuento:debe ser mayor o igual a cero y menor o igual a 100.

Alter table FINANZAS.FDCXCOBR

add Constraint CC$FDCXCOBR$DESCUENTO

check (DCXC_DESCUENTO >=0 AND DCXC_DESCUENTO <=100)

FINANZAS. NN$FCXCOBR$CLIENTE

Validacion para la columna CXCO_Cliente: No permite valores nulos.

Alter table FINANZAS.FCXCOBR

add Constraint NN$FCXCOBR$CLIENTE

check (CXCO_CLIENTE IS NOT NULL)

3.3.2. FINANZAS.FCLIENTESFINANZAS. PK*FCLIENTES*CLIENTE

Llave primaria

Alter table FINANZAS.FCLIENTES

add Constraint PK*FCLIENTES*CLIENTE

primary key ( CLIE_CLIENTE )

using index tablespace INDX

FINANZAS. NN*FCLIENTES*ACTIVO

Validacion para la columna CLIE_Activo: No permite valores nulos.

Alter table FINANZAS.FCLIENTES

add Constraint NN*FCLIENTES*ACTIVO

check (CLIE_ACTIVO IS NOT NULL )

FINANZAS. NN*FCLIENTES*ESTUD

Validacion para la columna CLIE_Estud:No permite valores nulos.

Alter table FINANZAS.FCLIENTES

add Constraint NN*FCLIENTES*ESTUD

check (CLIE_ESTUD IS NOT NULL)

FINANZAS. NN$FCLIENTES$NOMBRE

Validacion para la columna CLIE_Nombre: No permite valores nulos.

Alter table FINANZAS.FCLIENTES

add Constraint NN$FCLIENTES$NOMBRE

check (CLIE_NOMBRE IS NOT NULL)

FINANZAS.NN*FCLIENTES*NOMBRE

Validacion para la columna CLIE_Nombre: No permite valores nulos.

Alter table FINANZAS.FCLIENTES

add Constraint NN*FCLIENTES*NOMBRE

check (CLIE_NOMBRE IS NOT NULL)

FINANZAS.NN$FCLIENTES$SEXO

Validacion para la columna CLIE_Sexo:No permite valores nulos.

Alter table FINANZAS.FCLIENTES

add Constraint NN$FCLIENTES$SEXO

check (CLIE_SEXO IS NOT NULL)

FINANZAS.CC*FCLIENTES*ACTIVO

Validacion para la columna CLIE_Activo:sus valores deben ser S o N.

Alter table FINANZAS.FCLIENTES

add Constraint CC*FCLIENTES*ACTIVO

check (CLIE_ACTIVO IN (’S’,’N’) )

FINANZAS.CC$FCLIENTES$CURP

Validacion para la columna CLIE_CURP: La longitud debe ser igual a 18 caracteres.

Alter table FINANZAS.FCLIENTES

add Constraint CC$FCLIENTES$CURP

check (length(CLIE_CURP) = 18)

FIE UMSNH

3.3. CONSTRAINTS 36

FINANZAS. CC*FCLIENTES*ESTUD

Validacion para la columna CLIE_Estud:sus valores deben ser S o N.

Alter table FINANZAS.FCLIENTES

add Constraint CC*FCLIENTES*ESTUD

check (CLIE_ESTUD IN (’S’,’N’) )

FINANZAS.CC$FCLIENTES$SEXO

Validacion para la columna CLIE_Sexo:Sus valores deben ser F o M.

Alter table FINANZAS.FCLIENTES

add Constraint CC$FCLIENTES$SEXO

check (CLIE_SEXO IN (’F’,’M’))

3.3.3. FINANZAS.FPERSONASFINANZAS.CC$FPERSONAS$CURP

Validacion para la columna PERS_CURP: La longitud debe ser igual a 18 caracteres.

Alter table FINANZAS.FPERSONAS

add Constraint CC$FPERSONAS$CURP

check (length(PERS_CURP) = 18)

FINANZAS.NN*FPERSONAS*ACTIVO

Validacion para la columna PERS_Activo:No permite valores nulos.

Alter table FINANZAS.FPERSONAS

add Constraint NN*FPERSONAS*ACTIVO

check (PERS_ACTIVO IS NOT NULL )

FINANZAS.NN*FPERSONAS*CAJERO

Validacion para la columna PERS_Cajero: No permite valores nulos.

Alter table FINANZAS.FPERSONAS

add Constraint NN*FPERSONAS*CAJERO

check (PERS_CAJERO IS NOT NULL)

FINANZAS.NN*FPERSONAS*CANCELA

Validacion para la columna PERS_Cancela: No permite valores nulos.

Alter table FINANZAS.FPERSONAS

add Constraint NN*FPERSONAS*CANCELA

check (PERS_CANCELA IS NOT NULL )

FINANZAS.NN*FPERSONAS*EMPLEADO

Validacion para la columna PERS_Empleado: No permite valores nulos.

Alter table FINANZAS.FPERSONAS

add Constraint NN*FPERSONAS*EMPLEADO

check (PERS_EMPLEADO IS NOT NULL)

FINANZAS.NN*FPERSONAS*NOMBRE

Validacion para la columna PERS_Nombre: No permite valores nulos.

Alter table FINANZAS.FPERSONAS

add Constraint NN*FPERSONAS*NOMBRE

check (PERS_NOMBRE IS NOT NULL)

FINANZAS.NN*FPERSONAS*PROVEEDOR

Validacion para la columna PERS_Proveedor: No permite valores nulos.

Alter table FINANZAS.FPERSONAS

add Constraint NN*FPERSONAS*PROVEEDOR

check (PERS_PROVEEDOR IS NOT NULL)

FINANZAS.PK*FPERSONAS*PERSONA

Llave primaria

Alter table FINANZAS.FPERSONAS

add Constraint PK*FPERSONAS*PERSONA

primary key ( PERS_PERSONA )

using index tablespace INDX

FIE UMSNH

3.3. CONSTRAINTS 37

3.3.4. FINANZAS.FURESFINANZAS.CC*FURES*ENT_DATA

Validacion para la columna URES_Ent_Data: Sus valores deben ser S o N.

Alter table FINANZAS.FURES

add Constraint CC*FURES*ENT_DATA

check (URES_ENT_DATA IN (’S’,’N’) )

FINANZAS. FK*FURES*PURES

Llave foranea: Referencia a la columna URES_Ures de la Tabla FINANZAS.FURES

Alter table FINANZAS.FURES

add Constraint FK*FURES*PURES

foreign key (URES_PURES)

references FINANZAS.FURES

( URES_URES )

FINANZAS.FK*FURES*PURES_PRES

Llave foranea: Referencia a la columna URES_Ures de la Tabla FINANZAS.FURES

Alter table FINANZAS.FURES

add Constraint FK*FURES*PURES_PRES

foreign key (URES_PURES_PRES)

references FINANZAS.FURES

( URES_URES )

FINANZAS.FK*FURES*TURES

Llave foranea: Referencia a la columna TURE_TURes de la Tabla FINANZAS.FTURES

Alter table FINANZAS.FURES

add Constraint FK*FURES*TURES

foreign key (URES_TURES)

references FINANZAS.FTURES

( TURE_TURES )

FINANZAS.NN*FURES*DESCRIP

Validacion para la columna URES_Descrip: No permite valores nulos.

Alter table FINANZAS.FURES

add Constraint NN*FURES*DESCRIP

check (URES_DESCRIP IS NOT NULL)

FINANZAS.NN*FURES*FEC

Validacion para la columna URES_Fec: No permite valores nulos.

Alter table FINANZAS.FURES

add Constraint NN*FURES*FEC

check (URES_FEC IS NOT NULL)

FINANZAS.NN*FURES*PURES_PRES

Validacion para la columna URES_PURes_Pres: No permite valores nulos.

Alter table FINANZAS.FURES

add Constraint NN*FURES*PURES_PRES

check (URES_PURES_PRES IS NOT NULL)

FINANZAS.NN*FURES*TURES

Validacion para la columna URES_TURes: No permite valores nulos.

Alter table FINANZAS.FURES

add Constraint NN*FURES*TURES

check (URES_TURES IS NOT NULL)

FINANZAS.NN*FURES*USU

Validacion para la columna URES_Usu: No permite valores nulos.

Alter table FINANZAS.FURES

add Constraint NN*FURES*USU

check (URES_USU IS NOT NULL)

FINANZAS.PK*FURES*URES

Llave primaria

Alter table FINANZAS.FURES

add Constraint PK*FURES*URES

primary key ( URES_URES )

FIE UMSNH

3.3. CONSTRAINTS 38

using index tablespace indx

3.3.5. FINANZAS.FPROGRAMFINANZAS.CC*FPROGRAM*ENT_DATA

Validacion para la columna PROG_Ent_Data: Sus valores deben ser S o N.

Alter table FINANZAS.FPROGRAM

add Constraint CC*FPROGRAM*ENT_DATA

check (PROG_ENT_DATA IN (’S’,’N’) )

FINANZAS. FK*FPROGRAM*FUNCION

Llave foranea: Referencia a la columna FUNC_Funcion de la Tabla FINANZAS.FFUNCION

Alter table FINANZAS.FPROGRAM

add Constraint FK*FPROGRAM*FUNCION

foreign key (PROG_FUNCION)

references FINANZAS.FFUNCION

( FUNC_FUNCION )

FINANZAS. FK*FPROGRAM*PROG_PPROG

Llave foranea: Referencia a la columna PROG_Prog de la Tabla FINANZAS.FPROGRAM

Alter table FINANZAS.FPROGRAM

add Constraint FK*FPROGRAM*PROG_PPROG

foreign key (PROG_PPROG)

references FINANZAS.FPROGRAM

( PROG_PROG )

FINANZAS. NN*FPROGRAM*DESCRIP

Validacion para la columna PROG_Descrip: No permite valores nulos.

Alter table FINANZAS.FPROGRAM

add Constraint NN*FPROGRAM*DESCRIP

check (PROG_DESCRIP IS NOT NULL)

FINANZAS.NN*FPROGRAM*FECHA

Validacion para la columna PROG_Fec: No permite valores nulos.

Alter table FINANZAS.FPROGRAM

add Constraint NN*FPROGRAM*FECHA

check (PROG_FEC IS NOT NULL)

FINANZAS. NN*FPROGRAM*FUNCION

Validacion para la columna PROG_Funcion: No permite valores nulos.

Alter table FINANZAS.FPROGRAM

add Constraint NN*FPROGRAM*FUNCION

check (PROG_FUNCION IS NOT NULL)

FINANZAS.NN*FPROGRAM*USU

Validacion para la columna PROG_Usu: No permite valores nulos.

Alter table FINANZAS.FPROGRAM

add Constraint NN*FPROGRAM*USU

check (PROG_USU IS NOT NULL)

FINANZAS.PK*FPROGRAM*PROG

Llave primaria

Alter table FINANZAS.FPROGRAM

add Constraint PK*FPROGRAM*PROG

primary key ( PROG_PROG )

using index tablespace indx

3.3.6. ESCOLAR.EREVEXPEDESCOLAR.CC$EREVEXPED$FECHA_EXAMEN

Validacion para la columna REVE_FechaExamen: Debe ser mayor o igual a REVE_FechaRev

Alter table ESCOLAR.EREVEXPED

FIE UMSNH

3.3. CONSTRAINTS 39

add Constraint CC$EREVEXPED$FECHA_EXAMEN

check (REVE_FECHAEXAMEN>=REVE_FECHAREV)

ESCOLAR.FK$EREVEXPED$DGPCARRERA

Llave foranea: Referencia a la columna DGPC_DGPCarrera de la Tabla EDGPCARRERA

Alter table ESCOLAR.EREVEXPED

add Constraint FK$EREVEXPED$DGPCARRERA

foreign key (REVE_DGPCARRERA)

references ESCOLAR.EDGPCARRERA

( DGPC_DGPCARRERA )

ESCOLAR.FK$EREVEXPED$DGPCARRERA

Llave foranea:Referencia a la columna MODA_Clave de la Tabla EMODATITU

Alter table ESCOLAR.EREVEXPED

add Constraint FK$EREVEXPED$MODACLAVE

foreign key (REVE_MODACLAVE)

references ESCOLAR.EMODATITU

( MODA_CLAVE )

ESCOLAR.NN$EREVEXPED$CLIENTE

Validacion para la columna REVE_Cliente: No permite valores nulos.

Alter table ESCOLAR.EREVEXPED

add Constraint NN$EREVEXPED$CLIENTE

check (REVE_Cliente IS NOT NULL)

ESCOLAR.PK$EREVEXPED$REVISION

Llave primaria

Alter table ESCOLAR.EREVEXPED

add Constraint PK$EREVEXPED$REVISION

primary key ( REVE_REVISION )

3.3.7. ESCOLAR.EDGPCARRERA

ESCOLAR.PK$EDGPCARRERA$DGPCARRERA

Llave primaria

Alter table ESCOLAR.EDGPCARRERA

add Constraint PK$EDGPCARRERA$DGPCARRERA

primary key ( DGPC_DGPCARRERA )

using index tablespace indx

ESCOLAR.FK$EDGPCARRERA$PROG

Llave foranea: Referencia a la columna PROG_Prog de la Tabla FINANZAS.FPROGRAM

Alter table ESCOLAR.EDGPCARRERA

add Constraint FK$EDGPCARRERA$PROG

foreign key (DGPC_PROG)

references FINANZAS.FPROGRAM

( PROG_PROG )

ESCOLAR.FK$EDGPCARRERA$URES

Llave foranea: Referencia a la columna URES_URES de la Tabla FINANZAS.FURES

Alter table ESCOLAR.EDGPCARRERA

add Constraint FK$EDGPCARRERA$URES

foreign key (DGPC_URES)

references FINANZAS.FURES

( URES_URES )

3.3.8. ESCOLAR.ESINODALESESCOLAR.FK$ESINODALES$REVISION

Llave foranea: Referencia a la columna TSIN_Sinodal de la Tabla ESCOLAR.EREVEXPED

FIE UMSNH

3.3. CONSTRAINTS 40

Alter table ESCOLAR.ESINODALES

add Constraint FK$ESINODALES$REVISION

foreign key (SINO_REVISION)

references ESCOLAR.EREVEXPED

( REVE_REVISION )

ESCOLAR.FK$ESINODALES$TIPO

Llave foranea: Referencia a la columna TSIN_TSinodal de la Tabla ESCOLAR.ETSINODAL

Alter table ESCOLAR.ESINODALES

add Constraint FK$ESINODALES$TIPO

foreign key (SINO_TIPO)

references ESCOLAR.ETSINODAL

( TSIN_TSINODAL )

ESCOLAR.PK$ESINODALES$SINODAL

Llave primaria

Alter table ESCOLAR.ESINODALES

add Constraint PK$ESINODALES$SINODAL

primary key ( SINO_SINODAL )

using index tablespace USERS

ESCOLAR.UK$ESINODALES$REVEMP

Llave compuesta entre las columnas SINO_Revision y SINO_NumEmp

Alter table ESCOLAR.ESINODALES

add Constraint UK$ESINODALES$REVEMP

unique ( SINO_REVISION, SINO_NUMEMP )

using index tablespace USERS

ESCOLAR.UK$ESINODALES$REVTIPO

Llave compuesta entre las columnas SINO_Revision y SINO_Tipo

Alter table ESCOLAR.ESINODALES

add Constraint UK$ESINODALES$REVTIPO

unique ( SINO_REVISION, SINO_TIPO )

using index tablespace USERS

3.3.9. ESCOLAR.ETSINODALESESCOLAR.PK$ETSINODAL$TSINODAL

Llave primaria

Alter table ESCOLAR.ETSINODAL

add Constraint PK$ETSINODAL$TSINODAL

primary key ( TSIN_TSINODAL )

using index tablespace USERS

3.3.10. ESCOLAR.ECITATRAMESCOLAR.FK$ECITATRAM$LUGADM

Llave foranea: Referencia a la columna LUGA_LugAdm de la Tabla ESCOLAR.ELUGADMIS

Alter table ESCOLAR.ECITATRAM

add Constraint FK$ECITATRAM$LUGADM

foreign key (CITA_LUGADM)

references ESCOLAR.ELUGADMIS

( LUGA_LUGADM )

ESCOLAR.NN$ECITATRAM$TRAMITE

Validacion para la columna CITA_Tramite: No permite valores nulos.

Alter table ESCOLAR.ECITATRAM

add Constraint NN$ECITATRAM$TRAMITE

check (CITA_Tramite is not null)

ESCOLAR.PK$ECITATRAM$CITA

Llave primaria

FIE UMSNH

3.3. CONSTRAINTS 41

Alter table ESCOLAR.ECITATRAM

add Constraint PK$ECITATRAM$CITA

primary key ( CITA_CITA )

using index tablespace USERS

3.3.11. ESCOLAR.EDCITATRAMESCOLAR.ESCOLAR.EDCITATRAM

Validacion para la columna DCIT_Activa: sus valores deben ser S o N.

Alter table ESCOLAR.EDCITATRAM

add Constraint CC$EDCITATRAM$ACTIVA

check (DCIT_Activa in (’S’,’N’) )

ESCOLAR.CC$EDCITATRAM$CITAS

Validacion para la columna DCIT_Citas: Debe ser menor o igual a DCIT_Cupo

Alter table ESCOLAR.EDCITATRAM

add Constraint CC$EDCITATRAM$CITAS

check (DCIT_Citas <= DCIT_Cupo)

ESCOLAR.FK$EDCITATRAM$CITA

Llave foranea: Referencia a la columna CITA_Cita de la Tabla ESCOLAR.ECITATRAM

Alter table ESCOLAR.EDCITATRAM

add Constraint FK$EDCITATRAM$CITA

foreign key (DCIT_CITA)

references ESCOLAR.ECITATRAM

( CITA_CITA )

ESCOLAR.NN$EDCITATRAM$ACTIVA

Validacion para la columna DCIT_Activa: No permite valores nulos.

Alter table ESCOLAR.EDCITATRAM

add Constraint NN$EDCITATRAM$ACTIVA

check (DCIT_Activa is not null)

ESCOLAR.NN$EDCITATRAM$CITA

Validacion para la columna DCIT_Cita: No permite valores nulos.

Alter table ESCOLAR.EDCITATRAM

add Constraint NN$EDCITATRAM$CITA

check (DCIT_Cita is not null)

ESCOLAR.NN$EDCITATRAM$CITAS

Validacion para la columna DCIT_Citas: No permite valores nulos.

Alter table ESCOLAR.EDCITATRAM

add Constraint NN$EDCITATRAM$CITAS

check (DCIT_Citas is not null)

ESCOLAR.NN$EDCITATRAM$CUPO

Validacion para la columna DCIT_Cupo: No permite valores nulos.

Alter table ESCOLAR.EDCITATRAM

add Constraint NN$EDCITATRAM$CUPO

check (DCIT_Cupo is not null)

ESCOLAR.NN$EDCITATRAM$FECHA

Validacion para la columna DCIT_Fecha: No permite valores nulos.

Alter table ESCOLAR.EDCITATRAM

add Constraint NN$EDCITATRAM$FECHA

check (DCIT_Fecha is not null)

ESCOLAR.PK$EDCITATRAM$DCITA

Llave primaria

Alter table ESCOLAR.EDCITATRAM

add Constraint PK$EDCITATRAM$DCITA

primary key ( DCIT_DCITA )

using index tablespace USERS

FIE UMSNH

3.3. CONSTRAINTS 42

3.3.12. ESCOLAR.EPAISESCOLAR.NN$EPAIS$DESCRIP

Validacion para la columna PAIS_Descrip: No permite valores nulos.

Alter table ESCOLAR.EPAIS

add Constraint NN$EPAIS$DESCRIP

check (PAIS_Descrip is not null)

ESCOLAR.PK$EPAIS$PAIS

Llave primaria

Alter table ESCOLAR.EPAIS

add Constraint PK$EPAIS$PAIS

primary key ( PAIS_PAIS )

using index tablespace USERS

3.3.13. ESCOLAR.EEDOSESCOLAR.NN$EEDOS$DESCRIP

Validacion para la columna EDOS_Descrip: No permite valores nulos.

Alter table ESCOLAR.EEDOS

add Constraint NN$EEDOS$DESCRIP

check (EDOS_Descrip is not null)

ESCOLAR.PK$EEDOS$EDO

Llave primaria

Alter table ESCOLAR.EEDOS

add Constraint PK$EEDOS$EDO

primary key ( EDOS_EDO )

using index tablespace USERS

3.3.14. ESCOLAR.EMUNIPSESCOLAR.NN$EMUNIPS$DESCRIP

Validacion para la columna MUNI_Descrip: No permite valores nulos.

Alter table ESCOLAR.EMUNIPS

add Constraint NN$EMUNIPS$DESCRIP

check (MUNI_Descrip is not null)

ESCOLAR.PK$EMUNIPS$MPO

Llave primaria

Alter table ESCOLAR.EMUNIPS

add Constraint PK$EMUNIPS$MPO

primary key ( MUNI_EDO, MUNI_MPO )

using index tablespace USERS

3.3.15. ESCOLAR.EMODATITUESCOLAR.PK$EMODATITU$CLAVE

Llave primaria

Alter table ESCOLAR.EMODATITU

add Constraint PK$EMODATITU$CLAVE

primary key ( MODA_CLAVE )

using index tablespace INDX

FIE UMSNH

3.3. CONSTRAINTS 43

3.3.16. ESCOLAR.ETITULOSESCOLAR.CC$ETITULOS$FCERTENVGOB

Validacion para la columna TITU_FCertEnvGob: Debe ser mayor o igual a TITU_FRecibRect

Alter table ESCOLAR.ETITULOS

add Constraint CC$ETITULOS$FCERTENVGOB

check (TITU_FCERTENVGOB >= TITU_FRECIBRECT)

ESCOLAR.CC$ETITULOS$FECENVSG

Validacion para la columna TITU_FecEnvSG: Debe ser mayor o igual a TITU_Fecha_CertCE

Alter table ESCOLAR.ETITULOS

add Constraint CC$ETITULOS$FECENVSG

check ( TITU_FECENVSG>=TITU_FECHA_CERTCE)

ESCOLAR.CC$ETITULOS$FECHA_CERTCE

Validacion para la columna TITU_Fecha_CertCE: Debe ser mayor o igual a TITU_FecImprTitulo

Alter table ESCOLAR.ETITULOS

add Constraint CC$ETITULOS$FECHA_CERTCE

check (TITU_FECHA_CERTCE >=TITU_FecImprTitulo)

ESCOLAR.CC$ETITULOS$FECHA_ENTREGA

Validacion para la columna TITU_Fecha_Entrega: Debe ser mayor o igual a TITU_Fecha_EnvDig

Alter table ESCOLAR.ETITULOS

add Constraint CC$ETITULOS$FECHA_ENTREGA

check (TITU_FECHA_ENTREGA >= TITU_FECHA_ENVDIG)

ESCOLAR.CC$ETITULOS$FECHAENVDGP

Validacion para la columna TITU_Fecha_EnvDGP: Debe ser mayor o igual a TITU_FRecibGob

Alter table ESCOLAR.ETITULOS

add Constraint CC$ETITULOS$FECHAENVDGP

check (TITU_FECHA_ENVDGP >= TITU_FRECIBGOB)

ESCOLAR.CC$ETITULOS$FECHA_ENVDIG

Validacion para la columna TITU_Fecha_EnvDig: Debe ser mayor o igual a TITU_Fecha_RegDGP

Alter table ESCOLAR.ETITULOS

add Constraint CC$ETITULOS$FECHA_ENVDIG

check (TITU_FECHA_ENVDIG >= TITU_FECHA_REGDGP)

ESCOLAR.CC$ETITULOS$FECHA_ENVGOB

Validacion para la columna TITU_Fecha_EnvGob: Debe ser mayor o igual a TITU_Fecha_CertRect

Alter table ESCOLAR.ETITULOS

add Constraint CC$ETITULOS$FECHA_ENVGOB

check (TITU_FECHA_ENVGOB >= TITU_FECHA_CERTRECT)

ESCOLAR.CC$ETITULOS$FECHAENVGOB

Validacion para la columna TITU_Fecha_EnvGob: Debe ser mayor o igual a TITU_FCertEnvGob

Alter table ESCOLAR.ETITULOS

add Constraint CC$ETITULOS$FECHAENVGOB

check (TITU_FECHA_ENVGOB >= TITU_FCERTENVGOB )

ESCOLAR.CC$ETITULOS$FECHA_REGDGP

Validacion para la columna TITU_Fecha_RegDGP: Debe ser mayor o igual a TITU_Fecha_EnvDGP

Alter table ESCOLAR.ETITULOS

add Constraint CC$ETITULOS$FECHA_REGDGP

check (TITU_FECHA_REGDGP >= TITU_FECHA_ENVDGP)

ESCOLAR.CC$ETITULOS$FECHA_REGGOB

Validacion para la columna TITU_Fecha_RegGob: Debe ser mayor o igual a TITU_Fecha_EnvGob

Alter table ESCOLAR.ETITULOS

add Constraint CC$ETITULOS$FECHA_REGGOB

check (TITU_FECHA_REGGOB >= TITU_FECHA_ENVGOB)

ESCOLAR.CC$ETITULOS$FECIMPRTITULO

Validacion para la columna TITU_FecImprTitulo: Debe ser mayor o igual a TITU_Fecha_Titulacion

Alter table ESCOLAR.ETITULOS

add Constraint CC$ETITULOS$FECIMPRTITULO

FIE UMSNH

3.4. TRIGGERS 44

check (TITU_FecImprTitulo >= TITU_FECHA_TITULACION)

ESCOLAR.CC$ETITULOS$FRECIBDIG

Validacion para la columna TITU_FRecibDig: Debe ser mayor o igual a TITU_Fecha_EnvDig

Alter table ESCOLAR.ETITULOS

add Constraint CC$ETITULOS$FRECIBDIG

check (TITU_FRECIBDIG >= TITU_FECHA_ENVDIG)

ESCOLAR.CC$ETITULOS$FRECIBGOB

Validacion para la columna TITU_FRecibGob: Debe ser mayor o igual a TITU_Fecha_EnvGob

Alter table ESCOLAR.ETITULOS

add Constraint CC$ETITULOS$FRECIBGOB

check (TITU_FRECIBGOB >= TITU_FECHA_ENVGOB)

ESCOLAR.CC$ETITULOS$FRECIBRECT

Validacion para la columna TITU_FRecibRect: Debe ser mayor o igual a TITU_FecEnvSG

Alter table ESCOLAR.ETITULOS

add Constraint CC$ETITULOS$FRECIBRECT

check (TITU_FRECIBRECT >=TITU_FECENVSG)

ESCOLAR.CC$ETITULOS$FRECIDGP

Validacion para la columna TITU_FRecibDGP: Debe ser mayor o igual a TITU_Fecha_EnvDGP

Alter table ESCOLAR.ETITULOS

add Constraint CC$ETITULOS$FRECIDGP

check (TITU_FRECIBDGP >= TITU_FECHA_ENVDGP)

ESCOLAR.CC$ETITULOS$RESULTADO

Validacion para la columna TITU_Resultado: sus valores deben ser entre A, NA, NSP o P.

Alter table ESCOLAR.ETITULOS

add Constraint CC$ETITULOS$RESULTADO

check (TITU_Resultado in (’A’,’NA’,’NSP’, ’P’) )

ESCOLAR.FK$ETITULOS$REVISION

Llave foranea: Referencia a la columna REVE_Revision de la Tabla ESCOLAR.EREVEXPED

Alter table ESCOLAR.ETITULOS

add Constraint FK$ETITULOS$REVISION

foreign key (TITU_REVISION)

references ESCOLAR.EREVEXPED

( REVE_REVISION )

ESCOLAR.NN$ETITULOS$FECHA_TITULACION

Validacion para la columna TITU_Fecha_Titulacion: No permite valores nulos.

Alter table ESCOLAR.ETITULOS

add Constraint NN$ETITULOS$FECHA_TITULACION

check (TITU_FECHA_TITULACION IS NOT NULL)

ESCOLAR.PK$ETITULOS$TITULO

Llave primaria

Alter table ESCOLAR.ETITULOS

add Constraint PK$ETITULOS$TITULO

primary key ( TITU_TITULO )

3.4. Triggers

Se ejecutan cuando una instruccion insert, update o delete se ejecutaen la tabla asociada a este.

FIE UMSNH

3.4. TRIGGERS 45

3.4.1. ESCOLAR.EVTCXCOBR$II

Trigger de la vista EVTCXCOBR. Si el ingreso correspondiente aesta cuenta por cobrar genera pago a sinodales busca una fecha para revi-sion de expediente, si existe fecha actualiza el numero de citas. Se insertael registro en revision de expediente y en cuentas por cobrar. En el caso deque el ingreso no genere pago a sinodales solamente se inserta un registro encuentas por cobrar.

CREATE OR REPLACE TRIGGER ESCOLAR.EVTCXCOBR$II

INSTEAD OF INSERT

ON ESCOLAR.EVTCXCOBR

DECLARE

cfecha integer;

NCitas integer;

Cupo integer;

Cita integer;

DCita integer;

crev integer := 0;

Cont Number;

SecRevision Integer;

procedure DaCita is

begin

SELECT Cita_Cita

INTO Cita

FROM ECitaTram

where Cita_Tramite = ’REXPE’;

-- Buscamos fecha para revision de expediente

SELECT count(*)

into cfecha

from EDCitaTram

where Dcit_Cita = cita

and Dcit_fecha = :new.VTCX_FecLimite;

-- Si no existe fecha, creamos nuevo registro

if cfecha = 0 then

INSERT into edcitatram

(dcit_Dcita, dcit_cita, Dcit_Lugar,Dcit_Fecha, Dcit_cupo)

VALUES

(ESQDcitaTram.NextVal, Cita,’EDIF Q PLANTA ALTA’, :new.VTCX_FecLimite,20);

else

-- verificamos cupo

SELECT DCit_Citas, DCit_Cupo

into NCitas, Cupo from EDCitaTram

where Dcit_Cita = cita

and Dcit_fecha = :new.VTCX_FecLimite;

if NCitas = Cupo then

Raise_Application_Error(-20001,’No hay cupo para esta fecha’);

return;

end if;

end if;

-- Insertamos cita en ECitaspi

SELECT DCit_DCita

into DCita from EDCitaTram

where Dcit_Cita = Cita

and Dcit_fecha = :new.VTCX_FecLimite;

INSERT INTO ECITASPI

(CITA_Matri, CITA_DCita)

VALUES

(:new.VTCX_Cliente, DCita) ;

end;

begin

FIE UMSNH

3.4. TRIGGERS 46

-- Verificamos que no exista cuenta x cobrar con el mismo ingreso

Select count(*) into Cont

From FVCXCOBR

Where VCXC_CLIENTE = :new.VTCX_CLIENTE

And VCXC_INGRESO = :new.VTCX_INGRESO

And VCXC_URES = :new.VTCX_URES

And VCXC_PEND <> 0;

If :new.VTCX_URes is null then

Raise_Application_Error(-20001,’La URes no puede ser Nula’);

end if;

If :new.VTCX_Prog is null then

Raise_Application_Error(-20001,’El programa no puede ser no puede ser Nulo’);

end if;

If Cont <> 0 then

Raise_Application_Error(-20001, ’Este Alumno ya tiene una deuda por el mismo

concepto para la misma Unidad Responsable’);

End If;

IF :new.VTCX_INGRESO in

(’0814’,’0812’,’0817’,’0815’,’0816’,’0813’,’0818’,

’0822’,’0823’,’0824’,’0825’,’0821’,’0838’,’0839’,’0810’)

then

-- Verificamos si ya tiene fecha para revision

SELECT COUNT(*)

INTO crev

FROM EREVEXPED

WHERE REVE_Cliente = :new.VTCX_Cliente

AND REVE_Prog = :new.VTCX_Prog

AND REVE_FechaRev = :new.VTCX_FecLimite;

if crev = 0 then

DaCita;

Select ESQRevExped.nextval

Into SecRevision

from Dual;

-- Insertamos en Cuentas por cobrar

INSERT INTO FCXCOBR

(cxco_cxcobr, cxco_cliente, cxco_fecha, cxco_ingreso, cxco_materia,

cxco_ciclo, cxco_prog, cxco_sfdo, cxco_ures, cxco_monto,

cxco_pagado, cxco_descrip, cxco_texto, cxco_feclimite)

values

(:new.vtcx_cxcobr, :new.vtcx_cliente, :new.vtcx_fecha, :new.vtcx_ingreso,

:new.vtcx_materia,:new.vtcx_ciclo,:new.vtcx_prog, :new.vtcx_sfdo,

:new.vtcx_ures, :new.vtcx_monto,0,:new.vtcx_descrip, secrevision,

:new.vtcx_feclimite);

-- Insertamos en Revision de Expedientes

INSERT INTO EREVEXPED

(reve_revision, reve_cliente, reve_prog, reve_fecharev, reve_numexped,

reve_ures, reve_cxcobr, reve_dgpcarrera )

values

(secrevision,:new.vtcx_cliente,:new.vtcx_prog, :new.vtcx_feclimite,

:new.vtcx_numexped, :new.vtcx_ures, :new.vtcx_cxcobr,:new.vtcx_dgpcarrera) ;

end if;

else

INSERT INTO FCXCOBR

(cxco_cxcobr, cxco_cliente, cxco_fecha, cxco_ingreso, cxco_materia,cxco_ciclo,

cxco_prog, cxco_sfdo, cxco_ures, cxco_monto, cxco_pagado, cxco_descrip, cxco_texto, cxco_feclimite)

values

(:new.vtcx_cxcobr, :new.vtcx_cliente,:new.vtcx_fecha, :new.vtcx_ingreso,

:new.vtcx_materia,:new.vtcx_ciclo, :new.vtcx_prog, :new.vtcx_sfdo,

:new.vtcx_ures, :new.vtcx_monto, 0,:new.vtcx_descrip, :new.vtcx_texto, :new.vtcx_feclimite);

end if;

end ;

FIE UMSNH

3.4. TRIGGERS 47

3.4.2. ESCOLAR.EVTCXCOBR$IU

Trigger de la vista EVTCXCOBR. Se actualizan datos de las tablasde revision de expediente, cuentas por cobrar y detalle de citas (actualizacupos en el caso de que exista una cita con la fecha de revision y en el casode que no inserta un registro).

CREATE OR REPLACE TRIGGER ESCOLAR.EVTCXCOBR$IU

INSTEAD OF UPDATE

ON ESCOLAR.EVTCXCOBR

DECLARE

cfecha integer;

NCitas integer;

Cupo integer;

Cita integer;

DCita integer;

procedure ActualizaTablas is

begin

-- Actualizamos en Revision de Expedientes

IF :new.VTCX_INGRESO in

(’0814’,’0812’,’0817’,’0815’,’0816’,’0813’,’0818’,’0822’,’0823’,’0824’,’0825’,’0821’,’0838’,’0839’,’0810’ ) then

update EREVEXPED

set REVE_FechaRev = :new.VTCX_FecLimite,

REVE_Prog=:new.VTCX_Prog,

REVE_NUMEXPED=:new.VTCX_NUMEXPED,

REVE_URES= :new.VTCX_URES,

REVE_CXCOBR =:new.VTCX_CXCOBR,

REVE_DGPCarrera= :new.VTCX_DGPCarrera,

REVE_CUSU=USER,

REVE_CFEC=SYSDATE

where REVE_Cliente = :old.VTCX_Cliente

and REVE_PROG = :old.VTCX_Prog

and REVE_FechaRev = :old.VTCX_FecLimite;

ELSE

update EREVEXPED

set REVE_FechaRev = :new.VTCX_FecLimite,

REVE_Prog=:new.VTCX_Prog,

REVE_NUMEXPED=:new.VTCX_NUMEXPED,

REVE_URES= :new.VTCX_URES,

REVE_CXCOBR =Null,

REVE_DGPCarrera= :new.VTCX_DGPCarrera,

REVE_CUSU=USER,

REVE_CFEC=SYSDATE

where REVE_Cliente = :old.VTCX_Cliente

and REVE_PROG = :old.VTCX_Prog

and REVE_FechaRev = :old.VTCX_FecLimite;

END IF;

--- Actualizamos la Cuenta por Cobrar

Update FCXCOBR Set

CXCO_Ingreso= :new.VTCX_Ingreso,

CXCO_Ciclo= :new.VTCX_Ciclo,

CXCO_Prog= :new.VTCX_Prog,

CXCO_Ures= :new.VTCX_Ures,

CXCO_Monto= :new.VTCX_Monto,

CXCO_Descrip= :new.VTCX_Descrip,

CXCO_FecLimite=:new.VTCX_FecLimite

Where CXCO_CXCOBR= :new.VTCX_CXCOBR;

end;

begin

If :new.VTCX_URes is null then

Raise_Application_Error(-20001,’La URes no puede ser Nula’);

end if;

If :new.VTCX_Prog is null then

Raise_Application_Error(-20001, ’El programa no puede ser no puede ser Nulo’);

end if;

FIE UMSNH

3.4. TRIGGERS 48

-- checamos cambio de fecha

if :new.VTCX_FecLimite <> :old.VTCX_FecLimite then

-- Borramos cita

DELETE FROM ECITASPI

Where CITA_Matri = :old.VTCX_Cliente;

-- Buscamos cita

SELECT Cita_Cita

INTO Cita

FROM ECitaTram

where Cita_Tramite = ’REXPE’;

-- Buscamos fecha para revision de expediente

SELECT count(*)

into cfecha

from EDCitaTram

where Dcit_Cita = cita

and Dcit_fecha = :new.VTCX_FecLimite;

-- Si no existe fecha, creamos nuevo registro

if cfecha = 0 then

INSERT into edcitatram

(dcit_Dcita, dcit_cita, Dcit_Lugar,Dcit_Fecha, Dcit_cupo)

VALUES

(ESQDcitaTram.NextVal, Cita,’EDIF Q PLANTA ALTA’, :new.VTCX_FecLimite, 20);

else

-- verificamos cupo

SELECT DCit_Citas, DCit_Cupo

into NCitas, Cupo from EDCitaTram

where Dcit_Cita = cita

and Dcit_fecha = :new.VTCX_FecLimite;

if NCitas = Cupo then

Raise_Application_Error(-20001,’No hay cupo para esta fecha’) ;

return;

end if;

end if;

-- Insertamos cita en ECitaspi

SELECT DCit_DCita

into DCita from EDCitaTram

where Dcit_Cita = Cita

and Dcit_fecha = :new.VTCX_FecLimite;

INSERT INTO ECITASPI

(CITA_Matri, CITA_DCita)

VALUES

(:old.VTCX_Cliente, DCita) ;

ActualizaTablas;

else -- De la condicion principal

ActualizaTablas;

end if; -- De la condicion principal

end ;

3.4.3. ESCOLAR.EREVEXPED$AU

Se ejecuta antes de hacer actualizaciones en la tabla EREVEXPED.Su funcion es la de actualizar el registro en la tabla de tıtulos en caso deexistir, en caso contrario inserta un registro nuevo en la tabla mencionada,ademas de hacer algunas Validaciones de fechas en la tabla de revision deexpediente.

CREATE OR REPLACE TRIGGER ESCOLAR.EREVEXPED$BU

BEFORE UPDATE

FIE UMSNH

3.4. TRIGGERS 49

ON ESCOLAR.EREVEXPED

REFERENCING NEW AS NEW OLD AS OLD

FOR EACH ROW

DECLARE

cfecha integer;

NCitas integer;

Cupo integer;

Cita integer;

DCita integer;

Cont number;

ContTit Number;

begin

If (:new.REVE_Ures <> :old.REVE_Ures) Or (:new.REVE_Prog <> :old.REVE_Prog) Then

Select Count(*)

Into Cont

From SAUTORIZA

Where AUTO_Usuario = User

And AUTO_Modulo = ’EVREVEXPED’;

If Cont = 0 Then

Raise_Application_Error(-20001,’El Usuario ’|| User|| ’ NO tiene derechos para modificar la Ures o el Prog’) ;

End If;

End If;

Select count(*) Into ContTit

From ETITULOS

Where TITU_Revision = :old.REVE_Revision;

if :new.REVE_FECHAEXAMEN is not null then

if :new.REVE_Resultado is null then

Raise_Application_Error(-20001, ’Resultado de la Revision No debe ser Nulo’);

end if;

if :new.REVE_Resultado <>’A’ then

Raise_Application_Error(-20001, ’No se puede asignar fecha de Examen porque no se Aprobo la Revision’);

end if;

If ContTit<>0 then

Update ETITULOS

set

TITU_Fecha_Titulacion = :new.REVE_FechaExamen,

TITU_URes=:new.REVE_URes,

TITU_Prog=:new.REVE_Prog,

TITU_DGPCarrera=:new.REVE_DGPCarrera,

TITU_CUSU=User,

TITU_CFEC=SysDate

Where TITU_Revision = :old.REVE_Revision;

Else

Insert Into ETITULOS

(TITU_Titulo,

TITU_Docto,

TITU_Revision,

TITU_Cliente,

TITU_Prog,

TITU_DGPCarrera,

TITU_Ures,

TITU_Fecha_Titulacion,

TITU_ModaClave)

Values

(ESQTitulos.nextval,

’TITULO’,

:new.REVE_Revision,

:new.REVE_Cliente,

:new.REVE_Prog,

:new.REVE_DGPCarrera,

:new.REVE_URes,

:new.REVE_FechaExamen,

:new.REVE_ModaClave );

end if;

End if;

if to_date(:new.REVE_FECHAREV) <> to_date(:old.REVE_FECHAREV) then

-- Borramos cita

DELETE FROM ECITASPI

Where CITA_Matri = :old.REVE_Cliente;

FIE UMSNH

3.4. TRIGGERS 50

-- Buscamos cita

SELECT Cita_Cita

INTO Cita

FROM ECitaTram

where Cita_Tramite = ’REXPE’;

-- Buscamos fecha para revision de expediente

SELECT count(*)

into cfecha

from EDCitaTram

where Dcit_Cita = cita

and Dcit_fecha = :new.REVE_FECHAREV;

-- Si no existe fecha, creamos nuevo registro

if cfecha = 0 then

INSERT into edcitatram

(dcit_Dcita, dcit_cita, Dcit_Lugar,Dcit_Fecha, Dcit_cupo)

VALUES

(ESQDcitaTram.NextVal, Cita,’EDIF Q PLANTA ALTA’,:new.REVE_FECHAREV, 20);

else

-- verificamos cupo

SELECT DCit_Citas, DCit_Cupo

into NCitas, Cupo from EDCitaTram

where Dcit_Cita = cita

and Dcit_fecha = :new.REVE_FECHAREV;

if NCitas = Cupo then

Raise_Application_Error(-20001, ’No hay cupo para esta fecha’);

return;

end if;

end if;

-- Insertamos cita en ECitaspi

SELECT DCit_DCita

into DCita from EDCitaTram

where Dcit_Cita = Cita

and Dcit_fecha = :new.REVE_FECHAREV;

INSERT INTO ECITASPI

(CITA_Matri, CITA_DCita)

VALUES

(:old.REVE_CLIENTE, DCita) ;

end if; -- De la condicion principal

end ;

3.4.4. ESCOLAR.ETITULOS$AU

Se ejecuta despues de hacer actualizaciones en la tabla de tıtulos.Su funcion es la de actualizar el registro en la tabla de certificados globales.

CREATE OR REPLACE TRIGGER ESCOLAR.ETITULOS$AU

AFTER UPDATE

ON ESCOLAR.ETITULOS

REFERENCING NEW AS NEW OLD AS OLD

FOR EACH ROW

Declare

ContCert Number;

BEGIN

If (:new.TITU_Ures = :old.TITU_Ures) And (:new.TITU_Prog = :old.TITU_Prog) Then

Return;

End If;

Update ECERTIFICADOS

Set CERT_URes= :new.TITU_URes,

CERT_Prog=:new.TITU_Prog

Where CERT_TITULO =:Old.TITU_Titulo;

end ;

FIE UMSNH

3.4. TRIGGERS 51

3.4.5. ESCOLAR.ETITULOS$BUSe ejecuta antes de hacer actualizaciones en la tabla de tıtulos. Su

funcion principal es la de validar fechas, ademas de actualizar o insertar (encaso de no existir el registro) en certificados globales.

CREATE OR REPLACE TRIGGER ESCOLAR.ETITULOS$BU

BEFORE UPDATE

ON ESCOLAR.ETITULOS

REFERENCING NEW AS NEW OLD AS OLD

FOR EACH ROW

Declare

ContCert Number;

BEGIN

If ((:new.titu_resultado <> ’A’) and (:new.titu_fecImprtitulo is not null)) then

Raise_Application_Error(-20001,’No se puede asignar Fecha de Emision a Alumno que no esta Aprobado’) ;

end if;

If ((:new.titu_resultado <> ’A’) and (:new.titu_calig is not null)) then

Raise_Application_Error(-20001,’No se puede asignar Caligrafo a Alumno que no esta Aprobado’) ;

end if;

If Updating(’TITU_FCERTENVGOB’) THEN

if (:old.TITU_FRECIBRECT is null) then

Raise_Application_Error(-20001,’Fecha de Certificacion de envıo a Gobierno no debe ser Nula’) ;

end if ;

end if;

If Updating(’TITU_FECHA_ENVDGP’) THEN

if (:old.TITU_FECHA_ENVGOB is null) then

Raise_Application_Error(-20001,’Fecha de Envıo a Gobierno no debe ser Nula’) ;

end if ;

end if;

If Updating(’TITU_FECHA_ENVDIG’) THEN

if (:old.TITU_FECHA_ENVDGP is null) then

Raise_Application_Error(-20001,’Fecha de Envıo a Direccion General de Profesiones No Debe ser Nula’) ;

end if ;

end if;

If Updating(’TITU_FRECIBDGP’) THEN

if (:old.TITU_FECHA_ENVDGP is null) then

Raise_Application_Error(-20001,’Fecha de Envıo a Direccion General de Profesiones no debe ser Nula’) ;

end if ;

end if;

If Updating(’TITU_FRECIBDIG’) THEN

if (:old.TITU_FECHA_ENVDIG is null) then

Raise_Application_Error(-20001,’Fecha de Recibido en Rectorıa no debe ser mayor a la de Certificacion’) ;

end if ;

end if;

If Updating(’TITU_FRECIBGOB’) THEN

if (:old.TITU_FECHA_ENVGOB is null) then

Raise_Application_Error(-20001, ’Fecha de Envıo a Gobierno No debe ser Nulo’) ;

end if ;

end if;

If Updating(’TITU_FRECIBRECT’) THEN

if (:old.TITU_FECHA_CERTRECT is null) then

Raise_Application_Error(-20001,’No debe ser nula la Certificacion en Rectorıa’) ;

end if ;

end if;

If Updating(’TITU_ENTRCEDULA’) THEN

if (:NEW.TITU_ENTRCEDULA IN(’s’,’n’)) then

:NEW.TITU_ENTRCEDULA := upper(:NEW.TITU_ENTRCEDULA);

end if ;

end if;

If Updating(’TITU_ENTRTITULO’) THEN

if (:NEW.TITU_ENTRTITULO IN(’s’,’n’)) then

:NEW.TITU_ENTRTITULO := upper(:NEW.TITU_ENTRTITULO);

end if ;

end if;

FIE UMSNH

3.5. VISTAS 52

If Updating(’TITU_FecImprTitulo’) then

Select count(*) Into ContCert

From ECERTIFICADOS

where CERT_Titulo=:old.TITU_Titulo

And CERT_Cliente=:old.TITU_Cliente

And CERT_Prog =:old.TITU_Prog;

if :new.TITU_FecImprTitulo is not null then

if contCert=0 then

Insert Into ECERTIFICADOS

(CERT_CERTIFICADO,

CERT_TITULO,

CERT_CLIENTE,

CERT_URES,

CERT_PROG )

Values

(ESQCertificados.nextval,

:old.TITU_Titulo,

:old.TITU_Cliente,

:old.TITU_URes,

:old.TITU_Prog );

end if;

end if;

if :new.TITU_FecImprTitulo is null then

if contCert<>0 then

Delete from ECERTIFICADOS

Where CERT_Titulo = :old.TITU_Titulo

And CERT_Cliente = :old.TITU_Cliente

And CERT_Prog = :old.TITU_Prog;

end if;

End if;

end if;

end ;

3.5. Vistas

Una vista es un objeto de la base de datos que permite crear unaseleccion personalizada de una tabla o de una coleccion de tablas. A diferenciade una tabla, una vista no contiene ningun dato, unicamente contiene unaconsulta SQL. Los datos que se recuperan de esa consulta se presentan enforma de tabla.

3.5.1. ESCOLAR.EVTCXCOBR

Vista para la generacion de cuentas por cobrar.

Create or Replace View ESCOLAR.EVTCXCOBR

AS

Select --+Rule

distinct(cxco_cxcobr) as vtcx_cxcobr,

cxco_cliente as vtcx_cliente,

substr(clie_apepat||’ ’||clie_apemat||’ ’||clie_nombre, 1,45)

as vtcx_nombre,

cxco_fecha as vtcx_fecha,

cxco_ingreso as vtcx_ingreso,

cxco_monto as vtcx_monto,

cxco_pagado as vtcx_pagado,

nvl(cond_descuento,0) as vtcx_condonado,

FIE UMSNH

3.5. VISTAS 53

( nvl(cxco_monto,0) - nvl(cxco_pagado,0)

- nvl(cond_descuento,0))

as vtcx_pend,

cxco_prog as vtcx_prog,

reve_dgpcarrera as vtcx_dgpcarrera,

cxco_materia as vtcx_materia,

cxco_ciclo as vtcx_ciclo,

cxco_sfdo as vtcx_sfdo,

cxco_ures as vtcx_ures,

cxco_descrip as vtcx_descrip,

cxco_texto as vtcx_texto ,

cxco_feclimite as vtcx_feclimite,

cxco_feccancel as vtcx_feccancel,

to_char(cxco_fec, ’dd/mm/yyyy’) as vtcx_fec,

reve_numexped as vtcx_numexped

From FCXCOBR, FCONDONACIONES ,EREVEXPED,FCLIENTES

Where cxco_cxcobr = cond_cxcobr(+)

And cxco_cliente = reve_cliente(+)

And cxco_prog = reve_prog(+)

And clie_cliente= cxco_cliente

And cxco_ingreso in (’0812’,’0802’,’0810’,’0813’, ’0814’,

’0815’,’0816’,’0817’,’0818’, ’0819’,

’0804’,’0823’,’0821’,’0824’, ’0825’,

’0822’,’0829’,’0830’,’0836’,’0838’,’0839’)

3.5.2. ESCOLAR.EVREVEXPED

Vista en la que se presenta la Revision de Expediente.

Create or Replace View ESCOLAR.EVREVEXPED

AS

Select --+First_Rows

reve_revision as vrev_revision,

reve_cliente as vrev_matricula,

clie_apepat||’ ’||clie_apemat||’ ’||clie_nombre as vrev_nombre,

reve_dgpcarrera as vrev_dgpcarrera,

reve_prog as vrev_prog,

reve_ures as vrev_ures,

ures_descrip as vrev_uresdescrip,

moda_clave as vrev_modalidad,

moda_descrip as vrev_descmodalidad,

reve_resultado as vrev_resultado,

to_date(reve_fec, ’dd/mm/yy’) as vrev_fecha,

to_date(reve_fecharev, ’dd/mm/yy’) as vrev_fecharev,

reve_fechaexamen as vrev_fechaexamen,

to_char(reve_fechaexamen,’hh24:mi:ss am’) as vrev_hora,

reve_asesor as vrev_asesor,

reve_numexped as vrev_numexped,

reve_tematesis as vrev_tematesis,

reve_mesa as vrev_mesa,

reve_fecdig as vrev_fecdig

From EREVEXPED, FCLIENTES,EMODATITU,FURES

Where clie_cliente = reve_cliente

And reve_ures = ures_ures

And reve_modaclave= moda_clave(+)

3.5.3. ESCOLAR.EVTITULOS

Vista en la que se presentan los datos del registro de examen recep-cional.

Create or Replace View ESCOLAR.EVTITULOS

AS

Select --+First_Rows

titu_titulo as vtit_titulo,

titu_folio as vtit_folio,

FIE UMSNH

3.5. VISTAS 54

titu_docto as vtit_docto,

titu_revision as vtit_revision,

titu_cliente as vtit_matricula,

clie_apepat||’ ’||clie_apemat||’ ’||clie_nombre as vtit_nombre,

clie_sexo as vtit_sexo,

titu_dgpcarrera as vtit_dgpcarrera,

titu_prog as vtit_prog,

prog_descrip as vtit_pdescrip,

titu_ures as vtit_ures,

ures_descrip as vtit_urdescrip,

titu_modaclave as vtit_modalidad,

titu_fecha_titulacion as vtit_fectitulacion,

titu_resultado as vtit_resultado,

titu_fec as vtit_fecha,

titu_calig as vtit_persona,

titu_fecimprtitulo as vtit_fecimprtitulo,

titu_fecha_certce as vtit_feccertce,

reve_numexped as vtit_numexped,

titu_observaciones as vtit_observaciones

From ETITULOS, FCLIENTES, FPROGRAM, FURES, EREVEXPED

Where titu_cliente = clie_cliente

And reve_revision= titu_revision

And titu_ures = ures_ures

And titu_prog = prog_prog

3.5.4. ESCOLAR.EVSEGCESC

Vista en la que se presenta los datos del seguimiento de tıtulos.

Create or Replace View ESCOLAR.EVSEGCESC

AS

Select --+first_rows

titu_titulo as vseg_titulo,

titu_revision as vseg_revision,

reve_cliente as vseg_matricula,

clie_apepat||’ ’||clie_apemat||’ ’||clie_nombre as vseg_nombre,

reve_dgpcarrera as vseg_dgpcarrera,

reve_ures as vseg_ures,

reve_prog as vseg_prog,

prog_descrip as vseg_pdescrip,

to_date(titu_fecha_titulacion,’dd/mm/yy’) as vseg_fectitulacion,

to_date(titu_fecimprtitulo,’dd/mm/yy’) as vseg_fecimprtitulo,

to_date(titu_fecha_certce,’dd/mm/yy’) as vseg_feccertce,

to_date(titu_fecenvsg, ’dd/mm/yy’) as vseg_fecenvsg,

to_date(titu_frecibrect, ’dd/mm/yy’) as vseg_frecibrect,

to_date(titu_fcertenvgob, ’dd/mm/yy’) as vseg_fenvimprcertg,

to_date(titu_fecha_envgob, ’dd/mm/yy’) as vseg_fecenvgob,

titu_oficiogob as vseg_oficiogob,

to_date(titu_fecha_reggob, ’dd/mm/yy’) as vseg_fecreggob,

titu_numreggob as vseg_numreggob,

to_date(titu_fecha_envdgp, ’dd/mm/yy’) as vseg_fecenvdgp,

titu_oficiodgp as vseg_oficiodgp,

titu_fojasdgp as vseg_fojasdgp,

titu_librodgp as vseg_librodgp,

titu_numerodgp as vseg_numerodgp,

titu_ceduladgp as vseg_ceduladgp,

to_date(titu_fecha_regdgp, ’dd/mm/yy’) as vseg_fecregdgp,

to_date(titu_fecha_envdig, ’dd/mm/yy’) as vseg_fecenvdig,

to_date(titu_fecha_entrega, ’dd/mm/yy’) as vseg_fecentrega,

substr(effirma(titu_titulo),1,2) as vseg_firmadig,

titu_firma as vseg_firma,

to_date(titu_frecibgob, ’dd/mm/yy’) as vseg_frecibgob,

to_date(titu_frecibdgp, ’dd/mm/yy’) as vseg_frecibdgp,

to_date(titu_frecibdig, ’dd/mm/yy’) as vseg_frecibdig,

reve_numexped as vseg_numexped,

titu_entrcedula as vseg_entrcedula,

titu_entrtitulo as vseg_entrtitulo,

titu_observaciones as vseg_observaciones

From EREVEXPED Join ETITULOS On (titu_revision= reve_revision)

Join FCLIENTES On (reve_cliente= clie_cliente)

Join FPROGRAM On (reve_prog = prog_prog)

FIE UMSNH

3.6. CONCLUSIONES 55

Where titu_fecha_certce is not null

3.5.5. ESCOLAR.EVFORMATODGP

Vista de los datos del Formato que se envıa a la Direccion Generalde Profesiones.

Create or Replace View ESCOLAR.EVFORMATODGP

AS

Select --+First_Rows

clie_curp as vfor_curp,

’160001’ as vfor_idinstitucion,

clie_apepat as vfor_paterno,

clie_apemat as vfor_materno,

clie_nombre as vfor_nombre,

’ ’ as vfor_matricula,

reve_dgpcarrera as vfor_idcarrera,

decode(prog_pprog, ’107’,’a1’, ’c1’) as vfor_tipo,

decode(prog_pprog, ’107’,’es’,’105’,’m’,’106’,’m’,’c’)

as vfor_ttramite,

to_char(clie_fechanac,’yyyymmdd’) as vfor_fecnacimiento,

to_char(titu_fecha_titulacion,’yyyymmdd’) as vfor_fechaexamen,

dgal_edo as vfor_entnacimiento,

’ ’ as vfor_cedulaant,

decode(clie_sexo,’m’,1,2) as vfor_sexo,

to_char(titu_fecha_envdgp,’yyyymmdd’) as vfor_feccaptura,

’ ’ as vfor_causrepo,

’003’ as vfor_nacionalidad

From ETITULOS, EREVEXPED, FCLIENTES, EDGALUMNO, FPROGRAM

Where reve_cliente = clie_cliente

And reve_revision = titu_revision

And clie_cliente= dgal_alumno

And reve_prog = prog_prog

And titu_fecha_envdgp is not null

3.6. Conclusiones

La creacion de tablas se hizo en base al proceso de normalizacionpresentado en el capitulo anterior, en cambio la creacion de vistas, contraintsy triggers se hicieron en base a los requerimientos del modulo para poderobtener una mejor integridad de datos en la base de datos.

FIE UMSNH

Capıtulo 4

Programas

4.1. Introduccion

Los programas que a continuacion se mencionan son los que compo-nen el modulo de titulacion. En estos se encuentran los modulos de generacionde deudas, registro de revision de expediente, registro de examen recepcional,impresion de tıtulos y el seguimiento de tıtulos.

4.2. EVTCXCOBR

En este programa se controla el modulo que se encuentra en Escolar -Fichas de deposito- Titulaciones. La funcion de este programa es la de generarlas deudas para los alumnos que solicitan una revision de expediente. Comodatos el programa requiere la matricula del Alumno, la clave del ingreso apagar, la clave de la carrera de la Direccion General de Profesiones, la fechade revision de expediente (que a la vez es la fecha lımite que tienen parapagar) y el numero de expediente del alumno. Al tener todos estos datos yaceptarlos el programa a traves del trigger EVTCXCOBR$II valida que losdatos de la Unidad Responsable (URes) y Programa nos sean valores nulos yque no tenga una deuda generada con el mismo concepto de ingreso. Si no secumplen cualquiera de los casos anterior, verifica que el concepto de ingresosea de los que generan pago a sinodales.

Si es el caso concepto de ingreso es de los que no generan sinodalesse inserta el registro solo en la tabla de cuentas por cobrar (FCXCOBR), enel caso contrario ademas de insertar el registro en la tabla FCXCOBR, con la

56

4.3. EVREVEXPED 57

cita de revision de expediente que se encuentra en la tabla ECITATRAM sele asigna un detalle de cita para poder controlar los cupos, una vez validadoel proceso el trigger hace una insercion del registro en la tabla de revisionde expediente (EREVEXPED) y el programa imprime una orden de pagopara que puedan saldarla en las cajas de la universidad o en el banco que seespecifica en la orden.

4.3. EVREVEXPED

Este programa se encuentra en el submodulo Escolar, en la opcionTitulacion - Revision de Expediente.Cuando el alumno se presenta al depar-tamento de titulacion a su revision, el (la) jefe (a) del departamento utilizaeste programa para proporcionar los siguientes datos:

Fecha y hora de examen recepcional

Modalidad de titulacion

Clave de la persona que asesoro la tesis o tesina

Tema de tesis (en caso de tesis o tesina)

Resultado de la aprobacion

Aprobado

No Aprobado

No se Presento

Asignacion de sinodales

Clave de la persona

Tipo de Sinodal

Una vez capturado y aceptados los datos, el programan actualizala tabla de Revision de Expediente (EREVEXPED) con lo nuevos datos, in-serta los sinodales y su tipo en la tabla de sinodales (ESINODALES), si elresultado de la revision es Aprobado a traves del trigger EREVEXPED$BUinserta un registro en la tabla de Tıtulos (ETITULOS), y si la fecha de

FIE UMSNH

4.4. EVTITULOS 58

revision es diferente se actualizan los cupos en la tabla de detalle de citas(EDCITATRAM). Si la clave de la URes o la clave del Programa son diferen-tes el trigger EREVEXPED$AU actualiza los datos en la tabla de cuentaspor cobrar (FCXCOBR), y si la deuda ya esta pagada modifica datos en lastablas correspondientes de finanzas.

4.4. EVTITULOS

El programa se encuentra en el submodulo Escolar, en la opcionTitulacion - Registro Examen Recepcional. Aquı, como su nombre lo indica,se registra el resultado del examen recepcional, se recaban datos como sonFecha y hora de titulacion y el resultado del examen recepcional que puedeser:

Aprobado

No Aprobado

No se Presento

Pendiente

Todos los datos se actualizan en la tabla ETITULOS.

4.5. EVIMPRDOCTOS

El programa se encuentra en el submodulo Escolar, en la opcionEmision de Documentos Oficiales - Tıtulos por imprimir. En este modulose encuentran los tıtulos que no han sido impresos o emitidos. Cuando seimprime un tıtulo el programa actualiza la columna de Folio y fecha deimpresion en la tabla de ETITULOS para el registro correspondiente, ademasactualiza la tabla ECTROLDOCTOS con el ultimo numero de folio impreso.

4.6. EVSEGCESC

El programa se ejecuta en el submodulo Escolar, en la Opcion Ti-tulacion- Seguimiento del tıtulo. En este modulo se actualiza la Tabla ETI-TULOS, se capturan datos de las fechas de envıo y recibido de la Secretaria

FIE UMSNH

4.7. CONCLUSIONES 59

General, Gobierno del Estado, Direccion General de Profesiones y Archivo,fechas de registro de Gobierno del Estado y Direccion General de Profesio-nes, y datos como son el registro de Gobierno del Estado, y numero de cedulaprofesional.

Para hacer estas actualizaciones el trigger ETITULOS$BU (BeforeUpdate) valida las fechas que esten en orden cronologico, por ejemplo, nose puede registrar una fecha de envıo a la secretaria General sin haber unafecha menor o igual de impresion, no puede haber fechas de recibido sinexistir fechas de envıo.

4.7. Conclusiones

La presentacion del sistema o la llamada interfaz grafica se hace atraves de Delphi, el nombre de los proyectos son llamados de la misma formaen que se llamaron las vistas ya que estas contienen toda la informacion nece-saria para hacer los procesos de actualizacion, insercion o solamente consultade las diferentes tablas que participan en la base de datos.

FIE UMSNH

Capıtulo 5

Conclusiones y Sugerencias

Derivado del reconocimiento compartido entre las autoridades dediversas instituciones publicas de educacion superior y la Direccion de Educa-cion Superior (DGES), de la Secretarıa de Educacion Publica (SEP), ası comode la necesidad de adoptar un lenguaje comun en el manejo de la informacionadministrativa y financiera, a principios de 1996 se iniciaron los trabajos en elambito de la Subsecretarıa de Educacion Superior e Investigacion Cientıficade la SEP, de un proyecto de alcance nacional tendiente a la normalizaciony estandarizacion de los sistemas de informacion administrativa y financierade las instituciones de educacion superior. Ası se iniciaron los trabajos deun proyecto de alcance nacional el: Programa para la Normalizacion de laInformacion Administrativa PRONAD.

La Universidad Michoacana de San Nicolas de Hidalgo, en el marcode las acciones del Programa Nacional de Desarrollo Educativo, tendientesa impulsar el desarrollo de la gestion universitaria y en ella el uso de la tec-nologıa informatica, con el apoyo de la Subsecretarıa de Educacion Superiore Investigacion Cientıfica (SESIC), y la Direccion General de Educacion Su-perior, a traves del PRONAD, se propuso desarrollar e implantar dentrode nuestra Universidad un Sistema Integral de Informacion Administrativa(SIIA).

El sistema tiene como proposito fundamental organizar el flujo dela informacion de caracter administrativo que generan las diferentes unida-des organicas dentro de la institucion, con el objeto de que los datos quese obtienen lleguen con oportunidad, eficiencia y calidad suficientes para laadecuada toma de decisiones en los diversos niveles jerarquicos de destino dela institucion.

60

61

El uso de este sistema requiere la instalacion de un software de-sarrollado por ASV Software llamado Shake, en este software es donde seunieron los modulos del Sistema de Registro y Seguimiento para titulacionde la UMSNH.

El sistema contiene los elementos necesarios para organizar el flujode la informacion, desde que un alumno solicita su revision de expedientehasta que recibe el tıtulo, y pretende ser una fuente confiable de informacion,tanto para el departamento de Titulacion como para el alumno, que ya seaa traves del sistema o de Internet puedan saber en que tramite se encuentrael proceso del tıtulo.

El modulo de Servicio Social se encuentra en el proceso de desarrolloen el SIIA, por lo que una vez terminado se sugiere incorporarlo al sistemade titulacion, ya que de esta forma el sistema podra validar que el egresadohaya cumplido con ese requisito.

Actualmente el SIIA cuenta con el historial academico (llamadotambien Kardex) de los alumnos inscritos del 2003 a la fecha, por lo quese sugiere validar con esta informacion el avance que tiene el egresado paraası poder empezar con los tramites de titulacion si el alumno cumple con elrequisito de haber cursado completo el plan de estudios o el total de creditospara poder titularse.

Para finalizar se sugiere que las dependencias (unidades responsa-bles) tengan acceso al Sistema de Registro y Seguimiento para Titulacionpara que se haga el registro del resultado del examen recepcional y ahorrartiempo en el tramite del tıtulo.

FIE UMSNH

Bibliografıa

[1] C.J.Date Introduccion a los Sistemas de Bases de Datos, Editorial Ad-disson Wesley, Quinta Edicion.

[2] David M. Kroenke Procesamiento de Bases de Datos,Fundamentos, Di-seno e Instrumentacion,Editorial Prentice Hall, Quinta Edicion.

[3] Annet Scott Data Modeling and Relational Database Design, OracleCorporation, Student Guide.

[4] Neena Kochhar, Eileen Lad Introduction to Oracle: SQL and PL/SQL,Oracle Corporation, Student Guide.

[5] Neena Kochhar, Eileen Lad Introduction to Oracle: SQL and PL/SQL,Oracle Corporation, Student Guide, Volumen 2.

[6] Christian Bauwens, Ellen Gravina Develop PL/SQL Program Units,Oracle Corporation, Student Guide.

[7] Christian Bauwens Advanced SQL and SQL *Plus, Oracle Corporation,Student Guide.

[8] Nancy GreenbergOracle 9i: Advanced PL/SQ, Oracle Corporation, Stu-dent Guide.

[9] Lex de Haan, Nancy Greenber Oracle 8i: SQL Statement Tuning Works-hop, Oracle Corporation, Student Guide.

[10] Donna Keesling, Priya Nathan Oracle 9i: New Features for Developers,Oracle Corporation, Student Guide.

[11] Luıs Joyanes Aguilar, Antonio Munoz Clemente Borland Delp-hi,Inicializacion y Referencia ,Editorial McGraw Hill .

62

BIBLIOGRAFIA 63

[12] Inprise Borland Delphi 5, Developer’s Guide ,Inprise Corporations .

[13] Francisco Charte Ojeda Programacion con Delphi 4,Editoria Anaya Mul-timedia.

[14] Michael Abbey, Michael J. Corey Oracle 8, Guıa de Aprendiza-je,Editorial Mac Graw Hill.

[15] ERWin, References Guide.

FIE UMSNH

Apendice A

Manual de Usuario

A.1. Introduccion

El Sistema Integral de Informacion Administrativa SIIA se compo-ne de 3 principales subsistemas que son Escolar, Finanzas y Recursos Huma-nos.En el subsistema Escolar se encuentran los modulos de Fichas de depositode Titulacion, Mesas Sinodales, Revision de Expediente, Registro de examenrecepcional y seguimiento de Tıtulos los cuales se explicaran a continuacion.

A.2. Generacion de Deuda

La generacion de las cuentas por cobrar que por el servicio de trami-tes de titulacion presta la Institucion a los estudiantes se genera en las oficinasde Control Escolar en el Departamento de Titulacion. Este proceso se iniciacon el registro, dentro del SIIA, de los conceptos de ingreso y sus correspon-dientes montos, por parte de la Direccion de Ingresos de la Tesorerıa Generalde la Universidad.

Una vez registrados los conceptos de ingresos es posible la gene-racion de las cuentas por cobrar, que por concepto de Titulacion debe decubrir un estudiante para realizar su examen para la obtencion de un gradoacademico.

Este modulo esta disponible a los usuarios en el subsistema Escolar,en el modulo de Fichas de deposito, en la opcion Titulaciones en donde tienela opcion de generar (Insertar), modificar y cancelar una deuda, como semuestra en la figura A.1.

64

A.2. GENERACION DE DEUDA 65

Figura A.1: Generacion de Fichas de Deposito para Pagos de Titulacion

Figura A.2: Generacion de Ordenes de Pago

En esta opcion se tiene la vista general de las Cuentas generadas alos diferentes alumnos que solicitan revision de expediente.

Para tener acceso a las opciones de detalle (Muestra el detalle delregistro en modo de solo lectura), Insertar (Permite agregar una nueva deuda)o Editar (Muestra el detalle de la deuda para poder ser modificado) hay quedar clic en el icono correspondiente. La pantalla es la que se muestra en lafigura A.2.

La descripcion de cada uno de los datos contenidos en esta pantallaes:

Cuenta: Es llenado en forma automatica por el SIIA, representa unidentificador numerico de la Cuenta por Cobrar. El campo contiguo esla descripcion del campo.

Matricula: identificador del alumno.

Subfondo: En este caso se utiliza la clave del Subfondo Generico que esla 1100, el sistema lo asigna de forma automatica.

Ingreso: Es la clave del concepto de ingreso. Los conceptos que se pue-den manejar son descritos en la A.1:

Fecha: Fecha en que se captura la cuenta por cobrar. El sistema laasigna automaticamente.

Monto: Este campo es llenado automaticamente por el sistema al teclearel concepto de ingreso. Corresponde a la cantidad que debe de pagar elalumno.

Ures: Clave de la unidad responsable donde estudio el alumno.

FIE UMSNH

A.2. GENERACION DE DEUDA 66

Conceptos de Ingreso para pagos de titulacion

Clave Descripciondel Concepto del Concepto Texto0802 Derechos Es el concepto de derecho de

examen recepcional.0804 Derechos PG. Derecho de Examen Recep-

cional para posgrado.0812 Examen Recepcional Es el pago del Examen Recep-

cional para Licenciatura.0813 Aplazamiento de Examen Recepcional Aplazamiento de Examen Re-

cepcional0814 Examen Recepcional Posgrado Examen Recepcional Posgra-

do0815 Examen Recepcional II Derecho a examen Recepcio-

nal con 5 sinodales0816 Examen Recepcional Posgrado II Examen Recepcional para

Posgrado con 5 sinodales0817 Examen Recepcional PG I. Examen Recepcional Para

Posgrado Nacionales Depen-dientes.

0818 Examen Recepcional PG I Examen Recepcional ParaPosgrado Nacionales Inde-pendientes.

0819 Aplazamiento Examen Recep I Aplazamiento Del ExamenRecepcional.

0821 Examen Recepcional III C/R Examen Recepcional Con 3Sinodales Y Reduccion Detıtulo Y Cedula.

0822 Examen Recepcional Lic IV C/R Examen Recepcional Con 5Sinodales Y Reduccion Detıtulo Y Cedula

0823 Examen Recepcional PG III C/R Examen recepcional de pos-grado con reduccion de tıtuloy cedula

0824 Examen Recepcional PG IV C/R Examen recepcional de pos-grado para alumnos indepen-dientes con reduccion de tıtu-lo y cedula.

0825 Aplazamiento exam, recep. c/r Aplazamiento del examen re-cepcional con reduccion detıtulo y cedula profesional

0829 Complemento de derechos0830 Complemento de titulacion0836 Examen recepcional pg s/s Examen recepcional para

posgrado sin sinodales0838 Examen recepc. pg v c/r Examen recepcional para

posgrado con reduccion ytres sinodales

0839 Examen recep. pg vi c/r Examen recepcional de pos-grado para alumnos indepen-dientes con reduccion y tressinodales

Cuadro A.1: Conceptos de Ingreso para pagos de Titulacion

FIE UMSNH

A.3. REVISION DE EXPEDIENTE 67

Figura A.3: Revision de Expediente

tıtulo: Clave de la Direccion General de Profesiones. El siguiente campoes la descripcion del tıtulo otorgado.

Programa: Clave del programa o carrera en la que curso el alumno.

Fecha de Revision de Expediente: Fecha en que el alumno debe de acu-dir al Departamento de Titulacion a realizar la revision de expediente.

Numero de Expediente: Numero con el que se encuentra registrado elexpediente del alumno en el archivo.

Pagado y Pendiente: Son llenados por el sistema e indica la cantidadque esta pagada o pendiente de pago.

Al estar en modo de insercion o en modo de edicion al aceptar datosel sistema preguntara si desea imprimir la orden de pago.

A.3. Revision de expediente

Una vez generada la deuda se desencadenan eventos como son lainsercion o actualizacion de una cita para el control de cupos y la insercionde un registro en el modulo de revision de expediente.

En la fecha de revision de expediente el alumno debe de acudir aldepartamento de titulacion en la que se revisaran a detalle los documentosque se presentan en el capitulo 2.

Finalizada la revision de expediente se prosigue a asignarle una fe-cha de examen y una mesa sinodal. Este proceso se hace en el SubsistemaEscolar, en el modulo de Titulacion que tiene la opcion Revision de Expe-diente (Figura A.3)

A.3.1. Datos Generales

Los jurados para la realizacion de los examenes profesionales, enla mayorıa de las dependencias, se asignan por parte del Departamento de

FIE UMSNH

A.3. REVISION DE EXPEDIENTE 68

Figura A.4: Captura de Datos Generales

Titulacion, ademas se le asigna la fecha y hora del examen recepcional. Parala asignacion de estos, se accesa con la opcion editar ( Figura A.4 y A.5 )

Datos

Revision: Numero de revision de expediente.

Expediente: Numero de expediente.

Matricula: Identificador del alumno.

Ures: Unidad responsable o dependencia.

Carrera DGP. Clave de la carrera en la Direccion General de Profesio-nes.

Tıtulo: Tıtulo otorgado.

Programa: Carrera en la que se va a titular.

Los datos anteriores no son modificables.

Fecha de Revision: Fecha de revision de expediente.

Fecha de Examen: Fecha en que se realizara el examen recepcional.

Hora: Hora del examen recepcional

Modalidad: Modalidad de titulacion

Asesor: Asesor.

Tema de Tesis. Tema de tesis o tesina.

Resultado de la Revision: Resultado de la revision de expediente.

FIE UMSNH

A.4. REGISTRO EXAMEN RECEPCIONAL 69

Figura A.5: Asignacion de Sinodales por Mesas Predefinidas

Figura A.6: Registro de Examen Recepcional

A.3.2. Asignacion Por Sinodal

La asignacion de los sinodales que componen la mesa sinodal sehace en la pantalla que se muestra en la figura A.5 con los datos siguien-tes: Sinodal: Clave y nombre del sinodal Tipo de Sinodal: Tipo de sinodal,Presidente, vocal, suplente, secretario, etc.

A.3.3. Asignacion Por Mesa

En la pantalla A.5 aparecen los mismos datos que en la de Asig-nacion por Sinodal, solo que el campo de Mesa es editable, este campo seusa para mesas completas preestablecidas, los campos de Sinodal y Tipo deSinodal Apareceran no editables.

A.4. Registro Examen Recepcional

Una vez realizado el examen recepcional se procede a hacer el re-gistro del resultado del examen. Esta opcion se encuentra en el modulo Es-colar, submodulo Titulacion en la opcion Registro de Examen Recepcional,se muestra en la figura A.6

En esta opcion solo se tiene los iconos de detalle y editar. Al darclic en el icono de editar aparecera una pantalla como la de la figura A.7:La descripcion de los campos es la siguiente:

Registro: Es el numero de tıtulo con el que se registro en el sistema

Folio : Este campo se refiere al numero de folio del tıtulo impreso.

Revision: Muestra el numero de revision de expediente.

FIE UMSNH

A.5. IMPRESION DEL TITULO 70

Figura A.7: Captura de Datos del Resultado de Examen Recepcional

Figura A.8: Impresion de Tıtulos

Matricula: Es el identificador del alumno.

Carrera DGP. Clave de la carrera en la Direccion General de Profesio-nes.

Programa: Programa al que corresponde la carrera.

Ures: Unidad responsable o dependencia.

Modalidad: Modalidad de titulacion.

Fec. Titulacion: Fecha en que presenta el examen recepcional.

Hora de Titulacion: Hora en que presenta el examen recepcional.

Calıgrafo. Persona a la que se mando hacer el tıtulo, esto fue para lostıtulos de pergamino.

Fec. Impresion. Fecha en la que fue impreso el tıtulo, en el caso de lostıtulos de pergamino es la fecha en que se emitio el tıtulo.

Resultado del Examen recepcional. Resultado del examen recepcional.

A.5. Impresion del Tıtulo

Ya registrado el tıtulo se procede a hacer la impresion de este. Es-ta opcion la encontramos en el Modulo de Escolar-Emision de DocumentosOficiales- tıtulos x Imprimir. Aquı tenemos la lista de tıtulos que aun no sehan impreso. La pantalla es como la de la figura A.8:

FIE UMSNH

A.6. SEGUIMIENTO DEL TITULO 71

Figura A.9: Detalle de Impresion de Tıtulos

Figura A.10: Seguimiento de Tıtulos

Sobre el registro podemos dar clic sobre el icono de detalle, nosaparece una pantalla ( Figura A.9 en la que nos muestra los detalles quetiene el tıtulo.

Una vez corroborado que todos los datos estan bien se acepta en elboton Ok para hacer la impresion del tıtulo.

A.6. Seguimiento del Tıtulo

Impreso el tıtulo se hace el seguimiento del tıtulo, esta opcion lapodemos encontrar en el modulo de Escolar-Titulacion-Seguimiento del tıtulo(Figura A.10).

En este modulo se hace una relacion de tıtulos que se envıan a laSecretaria General de la Universidad Michoacana para firma del SecretarioGeneral y del Rector, para sacar este reporte se da clic en el boton de reporte,y aparecera el reporte de los tıtulos impresos en ese dıa ( Figura A.11).

Al cerrar el reporte, el sistema preguntara que si se desea actualizarla fecha de envıo a la secretaria general, esto nos sirve para ver el dıa en quese mandaron los tıtulos a la secretaria General.

Una vez que los tıtulos son certificados por el Secretario General yel Rector se regresan al departamento de titulacion lo cual se registra en elmodulo de seguimiento de tıtulo, esta vez usando la opcion de modificar. Lapantalla se muestra en la figura A.12

En esta pantalla se registran los siguientes datos:

Figura A.11: Reporte de Tıtulos Impresos

FIE UMSNH

A.6. SEGUIMIENTO DEL TITULO 72

Figura A.12: Captura de Datos

Figura A.13: Captura de Datos de la Direccion General de Profesiones

Impr. de Cert. de Gobierno. Es la fecha en que se imprime la certifica-cion en la que se registra el numero y fecha de registro en Gobierno delEstado en el Tıtulo.

Envıo a Gobierno. Es la fecha en que se envıa a Gobierno del Estado

Oficio de Envıo a Gob. Numero de oficio en el que se envıa a Gobiernodel Estado.

Cuando regresa el tıtulo de Gobierno del Estado se registran en elsistema los siguientes datos:

Recibido. Es la fecha en que se recibio.

Fecha de Registro. Fecha en que se registro en Gobierno del Estado

Numero de Registro. Registro en Gobierno del estado

Los datos de Fecha de Registro y Numero de Registro de toman de laparte posterior del tıtulo.

Despues de registrar estos datos, se pasa la pestana de Direccion Ge-neral de Profesiones, la figura A.13 muestra la pantalla.

Una vez que se tienes los datos capturados de la Direccion Generalde Profesiones el tıtulo se envıa a Digitalizacion o al Archivo, los datos quese capturan se muestran en la figura A.14 y se describen a continuacion:

Envıo a Digitalizacion. Es la fecha en que se envıa al departamento deDigitalizacion o al archivo.

FIE UMSNH

A.6. SEGUIMIENTO DEL TITULO 73

Figura A.14: Captura de Datos de Digitalizacion

Figura A.15: Captura de Datos Entrega de Entrega de Documentos

Num. Expediente. Este dato es capturado desde el momento de la ge-neracion de la deuda que se explico en la seccion de la Generacion dedeuda, por lo que no se puede editar, es de solo lectura. El numero deexpediente le sirve al Departamento de Titulacion para conocer si eltıtulo se envıa al Departamento de Digitalizacion o al Archivo.

Recibido. Es la fecha en que se recibio el tıtulo.

En la pestana de Entrega de documentos se registra la fecha en quefue entregado y los documentos que se entregaron, ya sea el Tıtulo, la CedulaProfesional o los dos, la pantalla se muestra en la figura A.15

FIE UMSNH

Apendice B

Diagramas Entidad-Relacion(Modelo Fısico)

B.1. Introduccion

Un modelo Entidad- Relacion exhibe las entidades, atributos, rela-ciones y cardinalidad de los datos a modelar.

B.2. Tablas

El modelo Fısico de la figura B.1 muestra las tablas creadas, susatributos y la relacion que existe entre cada una de ellas.

Figura B.1: Modelo Fisico

74

B.3. VISTAS 75

Figura B.2: Vista de Generacion de Deudas

B.3. Vistas

Modelos Entidad Relacion de las vistas, se muestran las tablas queparticipan para su creacion.

B.3.1. EVTCXCOBR

En el diagrama de la Figura B.2 se muestran las tablas necesariaspara crear la vista.

FIE UMSNH

B.3. VISTAS 76

Figura B.3: Vista de Revision de Expediente

Figura B.4: Vista de Tıtulos

B.3.2. EVREVEXPED

En el diagrama de la Figura B.3 se muestran las tablas necesariaspara crear la vista.

B.3.3. EVTITULOS

En el diagrama de la Figura B.4 se muestran las tablas necesariaspara crear la vista.

B.3.4. EVFORMATODGP

En el diagrama de la Figura B.5 se muestra las tablas necesariaspara crear la vista.

B.3.5. EVIMPRDOCTOS

En el diagrama de la Figura B.6 se muestra las tablas necesariaspara crear la vista.

B.3.6. EVSEGCESC

En el diagrama de la Figura B.7 se muestra las tablas necesariaspara crearla.

Figura B.5: Vista del Formato de la Direccion General de Profesiones

FIE UMSNH

B.3. VISTAS 77

Figura B.6: Vista de Impresion de Tıtulos

Figura B.7: Vista del Seguimiento de Tıtulos

FIE UMSNH