sistema de registro y seguimiento para titulaci´on de la u...
Post on 18-Apr-2020
12 Views
Preview:
TRANSCRIPT
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
top related