Dedicatoria
A mis padres por ser mis mayores guías y amigos...
Yissell María
A mis padres y abuelos por el apoyo y cariño que me han brindado a lo largo de todos estos años….
Roberto Llerena
De Yissell María:
Quiero agradecerles a todas las personas que me apoyaron e hicieron posible que el trabajo se realizara de manera exitosa.
Les agradezco a mi familia y en especial a mis padres por su dedicación, su amor, y su apoyo incondicional.
Le agradezco a mi novio pues con un amor incondicional me apoyó en todo momento durante el desarrollo de mi carrera.
A Fidel y la Revolución cubana por permitir mis estudios y graduarme en esta universidad de gran prestigio nacional e internacional.
Le agradezco a mis tutores y a todo el colectivo del proyecto Akademos por su ayuda y esfuerzo brindado.
A mis amigos que me aconsejan y me apoyaron todo este tiempo.
Muchas Gracias
De Roberto Llerena:
Agradezco a Fidel y a la Revolución por hacer posible que los sueños de miles de jóvenes cubanos se hagan realidad…
A mí querida abuela Aida, por ser mi inspiración y educarme como un joven revolucionario…
A mi papá, por toda la confianza que ha depositado en mí…
A mi familia, quienes siempre han estado presente en cada momento importante de mi vida brindándome su apoyo…
A mis dos tutores, Norges y Molina, quienes me han soportado durante estos años y quienes siempre me han brindado su apoyo incondicional…
A Acralys, Ivonne, Andry, Fernando, Reinaldo, mis amigos, compañeros, hermanos…
Al piquete de Gastex 3, Orlando, Darien (Pepin), Frank, Grisel, Rosmel, Camejo, Dianly (El Loco), Miño, Olivia, Yaniris, Joe, Catherine, Alexey (El Titi), por los años que hemos compartido, nunca los olvidare…
A Marianny, Ygraine y Damián por toda la ayuda que me han brindado en la tesis…
A todos los que los de una manera u otra han tenido que ver con este trabajo…
Muchas Gracias
Declaración de Autoría
Declaramos ser autores del presente trabajo de Diploma y reconocemos a la Universidad de las Ciencias Informáticas con los derechos patrimoniales de la misma, con carácter exclusivo.
Para que así conste firmo la presente a los ____ días del mes de Junio del año 2008.
____________________________
Yissell María Castro García
__________________________
Roberto Llerena Villar
____________________________
Ing. Norges Sánchez Tumbarell (Tutor)
__________________________
Ing. Yulier Molina Ramírez (Tutor)
Opinión del tutor del trabajo de diploma
Título: Propuesta de diseño de la base de datos de Akademos 2.0 Autores: Yissell María Castro García; Roberto Llerena Villar
El tutor del presente Trabajo de Diploma considera que durante su ejecución los estudiantes mostraron las cualidades que a continuación se detallan.
Una alta independencia en cuanto al trabajo realizado, de personas cuya influencia podría equivocar el curso del trabajo; originalidad a la hora de resolver los distintos problemas que se le presentaron, creatividad para hallarle solución a los mismos. Ambos mostraron una gran laboriosidad y responsabilidad para realizar las tareas y orientaciones que se le hicieron.
Este documento posee conocimientos científicos que tributan a las bases de documentación del centro donde se encuentre. Esto contrasta con la realidad de ser un trabajo auténtico y la virtud de poseer ideas que puedan ser usadas en posteriores estudios sobre diseños e implementación de la base de datos.
Por todo lo anteriormente expresado considero que los estudiantes están aptos para ejercer como Ingenieros en Ciencias Informáticas; y propongo que se le otorgue al Trabajo de Diploma la calificación de ____ puntos.
____ días del mes de Junio del año 2008.
___________________________ _____________________________
Ing. Norges Sánchez Tumbarell Ing. Yulier Molina Ramírez
Resumen
El Sistema de Gestión Académica “Akademos”, como su nombre lo indica, es un software cuyo objetivo fundamental es gestionar toda la información académica que se genera en un centro de estudios. Este sistema desarrollado en la Universidad de las Ciencias Informáticas (UCI) es funcional en la actualidad, aunque presenta dificultades en varias de sus áreas, una de ellas es la base de datos. El diseño novedoso de esta base de datos para su época o fecha en que se elaboraron las primeras ideas para concepción del sistema, asociado a una implementación en un corto período de tiempo, los constantes cambios y el gran volumen de información que se almacena en la misma, ha provocado serios problemas de rendimiento y escalabilidad del sistema. Al equipo de desarrollo para la nueva versión del sistema le es imprescindible la elaboración de un nuevo esquema de datos que no arrastre los problemas que presenta el diseño de la versión anterior, e incluya las nuevas funcionalidades que se incorporan a las ya existentes. En el presente trabajo de tesis, cuyo título es: Propuesta de Diseño de la Base de Datos de Akademos 2.0, se realiza un estudio de varios software y herramientas vinculadas con la investigación, y se propone un modelo de la base de datos que se ajusta a las necesidades del sistema.
Índice
Introducción ... 1
Capítulo #1: Fundamentación teórica ... 5
1.1 Introducción ... 5
1.2 Ámbito internacional ... 6
1.2.1 ALBA: Sistema Libre de Gestión Educativa ... 6
1.3 Ámbito nacional ... 7
1.3.1 GESTACAD: Sistema de Gestión Académica ... 7
1.3.2 UCIMAT ... 7
1.3.3 AKADEMOS ... 8
1.4 Aporte obtenido de los sistemas de gestión académica estudiados ... 13
1.5 Herramientas, estrategias y metodologías utilizadas en la propuesta de diseño ... 13
1.5.1 Gestor de base de datos ... 13
1.5.1.1 PostgreSQL ... 14
1.5.2 Metodología ... 16
1.5.3 Herramientas de modelado... 17
1.5.3.1 Visual Paradigm ... 17
1.5.3.2 DBDesigner 4.0 ... 17
Conclusiones ... 19
Capítulo #2: Análisis y descripción de la solución propuesta ... 20
2.1 Introducción ... 20
2.2 Estructura general del área de la base de datos ... 20
2.3 Selección y argumentación de los requisitos funcionales y no funcionales del sistema propuesto ... 22
2.3.1 Requisitos funcionales ... 22
2.3.2 Requerimientos no funcionales ... 25
2.4 Estrategia de integración de la solución con otros módulos o sistemas ... 27
2.5 Descripción de la arquitectura propuesta y su fundamentación ... 27
2.6 Diseño de la base de datos ... 28
2.6.1 Diagrama de clases persistentes ... 29
2.6.2 Descripción de las clases persistentes ... 33
2.6.3 Diagrama entidad-relación de la base de datos... 44
2.6.4 Descripción de las tablas del diagrama entidad-relación ... 47
2.7 Análisis de optimización de querys ... 63
2.8 Conclusiones ... 66
Capítulo 3. Validación del diseño realizado ... 67
3.1 Introducción ... 67
3.2 Validación teórica del diseño ... 67
3.2.1 Integridad ... 67
3.2.1.1 Integridad de datos ... 67
3.2.1.2 Integridad de clave ... 68
3.2.1.3 Integridad de dominio ... 68
3.2.1.4 Integridad referencial ... 68
3.2.1.5 Integridad semántica ... 69
3.2.2 Normalización de la base de datos ... 69
3.2.3 Análisis de redundancia de la información ... 71
3.2.4 Análisis de la seguridad de la base de datos ... 72
3.2.5 Trazabilidad de las acciones... 73
3.3 Valoración funcional ... 73
3.4 Resultados ... 75
3.5 Conclusiones ... 76
Conclusiones ... 77
Recomendaciones ... 78
Bibliografía referenciada ... 79
Bibliografía consultada... 80
Glosario de términos ... 82
Anexos ... 85
Índice de tablas
Tabla 2.1 Descripción de la clase: CEGrupoAcadémico... 33
Tabla 2.2 Descripción de la clase: CENota ... 33
Tabla 2.3 Descripción de la clase: CEAsistencia ... 33
Tabla 2.4 Descripción de la clase: CETipoAsistencia ... 33
Tabla 2.5 Descripción de la clase: CEEdicionMomento... 34
Tabla 2.6 Descripción de la clase: CEBonificación ... 34
Tabla 2.7 Descripción de la clase: CEEstado ... 34
Tabla 2.8 Descripción de la clase: CEDocumentoExterno... 34
Tabla 2.9 Descripción de la clase: CEEstudiante ... 35
Tabla 2.10 Descripción de la clase: CECampo ... 35
Tabla 2.11 Descripción de la clase: CEPlantilla ... 35
Tabla 2.12 Descripción de la clase: CENomenclador ... 35
Tabla 2.13 Descripción de la clase: CENivel ... 36
Tabla 2.14 Descripción de la clase: CEPlanEstudio ... 36
Tabla 2.15 Descripción de la clase: CEMomento ... 36
Tabla 2.16 Descripción de la clase: CEFormaCalifConjunto ... 37
Tabla 2.17 Descripción de la clase: CEAsignatura ... 37
Tabla 2.18 Descripción de la clase: CEPerfil ... 37
Tabla 2.19 Descripción de la clase: CEDisciplina ... 37
Tabla 2.20 Descripción de la clase: CETipoAsignatura ... 38
Tabla 2.21 Descripción de la clase: CEConceptoBonificacion ... 38
Tabla 2.22 Descripción de la clase: CEUsuario ... 38
Tabla 2.23 Descripción de la clase: CEGrupoEvaluacion ... 38
Tabla 2.24 Descripción de la clase: CEFormaCalificacion... 39
Tabla 2.25 Descripción de la clase: CEEvaluacion ... 39
Tabla 2.26 Descripción de la clase: CETipoEvaluacion ... 39
Tabla 2.27 Descripción de la clase: CEClasificacion ... 39
Tabla 2.28 Descripción de la clase: CEAsignaturaAsignacion ... 40
Tabla 2.29 Descripción de la clase: CEProfesor ... 40
Tabla 2.30 Descripción de la clase: CEPermisos ... 40
Tabla 2.31 Descripción de la clase: CETipoProfesor ... 40
Tabla 2.32 Descripción de la clase: CECategoriaDocente ... 41
Tabla 2.33 Descripción de la clase: CERol ... 41
Tabla 2.34 Descripción de la clase: CETipoObjeto ... 41
Tabla 2.35 Descripción de la clase: CEAccion ... 41
Tabla 2.36 Descripción de la clase: CEPersona ... 42
Tabla 2.37 Descripción de la clase: CEIncidencia ... 42
Tabla 2.38 Descripción de la clase: CEError ... 42
Tabla 2.39 Descripción de la clase: CEPerfilTesis ... 42
Tabla 2.40 Descripción de la clase: CETesis ... 43
Tabla 2.41 Descripción de la clase: CEProblemaTesis ... 43
Tabla 2.42 Descripción de la clase: CECargo ... 43
Tabla 2.43 Descripción de la clase: CETutor ... 43
Tabla 2.45 Descripción de la tabla: Tbl_GrupoAcademico ... 47
Tabla 2.46 Descripción de la tabla: Tbl_TipoAsistencia ... 47
Tabla 2.47 Descripción de la tabla: Tbl_Asistencia ... 47
Tabla 2.48 Descripción de la tabla: Tbl_EstudianteAsignatura ... 47
Tabla 2.49 Descripción de la tabla: Tbl_GrupoEstudiante ... 48
Tabla 2.50 Descripción de la tabla: Tbl_Nota ... 48
Tabla 2.51 Descripción de la tabla: Tbl_Nivel ... 48
Tabla 2.52 Descripción de la tabla: Tbl_EdicionMomento ... 49
Tabla 2.53 Descripción de la tabla: Tbl_Bonificacion ... 49
Tabla 2.54 Descripción de la tabla: Tbl_PlanEstudio ... 49
Tabla 2.55 Descripción de la tabla: Tbl_Momento ... 50
Tabla 2.56 Descripción de la tabla: Tbl_Asignatura ... 50
Tabla 2.57 Descripción de la tabla: Tbl_AsignaturaPlanEstudio ... 50
Tabla 2.58 Descripción de la tabla: Tbl_Perfil ... 51
Tabla 2.59 Descripción de la tabla: Tbl_Disciplina ... 51
Tabla 2.60 Descripción de la tabla: Tbl_TipoAsignatura ... 51
Tabla 2.61 Descripción de la tabla: Tbl_ConceptoBonificacion ... 51
Tabla 2.62 Descripción de la tabla: Tbl_GrupoEvaluacion ... 52
Tabla 2.63 Descripción de la tabla: Tbl_FormaCalificacion ... 52
Tabla 2.64 Descripción de la tabla: Tbl_FormaCalifConjunto ... 52
Tabla 2.65 Descripción de la tabla: Tbl_Clasificacion ... 53
Tabla 2.66 Descripción de la tabla: Tbl_Evaluacion ... 53
Tabla 2.67 Descripción de la tabla: Tbl_EvaluacionAsignaturaPlanEstudio ... 53
Tabla 2.68 Descripción de la tabla: Tbl_TipoEvaluacion ... 53
Tabla 2.69 Descripción de la tabla: Tbl_TipoProfesor ... 54
Tabla 2.70 Descripción de la tabla: Tbl_Profesor ... 54
Tabla 2.71 Descripción de la tabla: Tbl_CategoriaDocente ... 54
Tabla 2.72 Descripción de la tabla: Tbl_Rol ... 55
Tabla 2.73 Descripción de la tabla: Tbl_UsuarioRol ... 55
Tabla 2.74 Descripción de la tabla: Tbl_Permisos ... 55
Tabla 2.75 Descripción de la tabla: Tbl_TipoObjeto ... 55
Tabla 2.76 Descripción de la tabla: Tbl_Accion ... 56
Tabla 2.77 Descripción de la tabla: Tbl_Error ... 56
Tabla 2.78 Descripción de la tabla: Tbl_Incidencia ... 56
Tabla 2.79 Descripción de la tabla: Tbl_Usuario ... 57
Tabla 2.80 Descripción de la tabla: Tbl_Persona ... 57
Tabla 2.81 Descripción de la tabla: Tbl_PerfilTesis ... 57
Tabla 2.82 Descripción de la tabla: Tbl_TesisTribunal ... 57
Tabla 2.83 Descripción de la tabla: Tbl_ProblemaTesis ... 58
Tabla 2.84 Descripción de la tabla: Tbl_Tribunal ... 58
Tabla 2.85 Descripción de la tabla: Tbl_Tesis ... 58
Tabla 2.86 Descripción de la tabla: Tbl_Tutor ... 59
Tabla 2.87 Descripción de la tabla: Tbl_EstructuraTribunal... 59
Tabla 2.88 Descripción de la tabla: Tbl_Cargo ... 59
Tabla 2.89 Descripción de la tabla: Tbl_Nomenclador... 60
Tabla 2.90 Descripción de la tabla: Tbl_EstudianteEstado ... 60
Tabla 2.91 Descripción de la tabla: Tbl_Estudiante ... 60
Tabla 2.92 Descripción de la tabla: Tbl_DocumentoExterno ... 60
Tabla 2.93 Descripción de la tabla: Tbl_CamposNomenclador ... 61
Tabla 2.94 Descripción de la tabla: Tbl_EstudianteCampos ... 61
Tabla 2.95 Descripción de la tabla: Tbl_Campos ... 61
Tabla 2.96 Descripción de la tabla: Tbl_Plantilla ... 62
Tabla 2.97 Descripción de la tabla: Tbl_CampoPlantilla ... 62
Tabla 2.98 Descripción de la tabla: Tbl_PlantillaPlanEstudio ... 62
Tabla 2.99 Descripción de la tabla: Tbl_Estado ... 62
Índice de figuras:
Figura 1 Estructura general del área de la base de datos. Akademos... 21
Figura 2 Diagrama de Clases Persistentes ... 30
Figura 3 Diagrama de Clases Persistentes(Continuación) ... 31
Figura 4 Diagrama de Clases Persistentes(Continuación) ... 32
Figura 5 Diagrama Entidad-Relación ... 44
Figura 6 Diagrama Entidad-Relación(Continuación) ... 45
Figura 7 Diagrama Entidad-Relación(Continuación) ... 46
Introducción
La UCI arriba a su sexto curso de haber abierto sus puertas por primera vez. Como parte de sus objetivos se ha logrado informatizar procesos dentro y fuera del ámbito universitario. Uno de vital importancia para cualquier centro de estudios es la gestión académica, por esta razón fue creado el software “Akademos”, caracterizado por su gran dinamismo, forma de adaptarse a los cambios de la nueva universidad y la incorporación de todos los implicados en el proceso (estudiantes, profesores, secretarias docentes, directivos y otros).
En base a las necesidades de migrar a software libre y con el objetivo de obtener un producto más genérico, desplegable en cualquier centro universitario, el equipo de proyecto trabaja en una nueva versión del software, se le añaden funcionalidades a los módulos ya existentes y se incorporan otros nuevos. Esto trae como consecuencia que el actual esquema de los datos no se ajuste a los nuevos requerimientos del sistema, por otra parte esta área posee dificultades en su modelo y utiliza un gestor de datos propietario, SQL Server 2000.
El objetivo principal de esta investigación es darle solución a los problemas presentes en dicha área. Se realiza un estudio de la base de datos actual y de los nuevos requisitos que posee cada área del software, así como de las nuevas técnicas y herramientas utilizadas en el mundo para la construcción de base de datos. Y como resultado se propone un diseño que da solución a las dificultades actuales que presenta la base de datos de Akademos y que se ajusta a las características de la nueva versión.
Debido a la mala gestión de cambios en el proyecto, Akademos sufrió un gran número de modificaciones desde su concepción original, ya sea por la necesidad de incorporar nuevas funcionalidades, o modificar muchas de las ya existentes. Cambios que en su mayoría fueron llevados a cabo por desarrolladores que no poseían suficiente conocimiento del software y sin la
supervisión de sus creadores. Los defectos añadidos provocaron que la base de datos se volviese difícil de manipular, y disminuyera en rendimiento. De ahí el problema científico a resolver en la investigación, expresado a través de la siguiente incógnita: ¿Cómo perfeccionar la gestión de bases de datos relacionales vinculadas a la gestión académica?
Para el cual se define como objeto de estudio: la gestión de bases de datos relacionales vinculadas a la gestión académica y como campo de acción: la base de datos de Akademos 2.0
Para dar respuesta al problema planteado se trazó el siguiente objetivo general: Diseñar una propuesta de base de datos del sistema Akademos 2.0 adaptable a cualquier centro de estudios.
Tareas a cumplir:
Estudio del arte sobre las alternativas más usadas actualmente a nivel nacional e internacional sobre software y herramientas vinculadas con bases de datos.
Propuesta y construcción del diseño a utilizar en la base de datos del Sistema Akademos 2.0.
Validación de la investigación realizada.
Como hipótesis de investigación se propone el siguiente planteamiento:
Si se diseña la base de datos del sistema Akademos 2.0 con los nuevos requerimientos, se perfeccionaría la gestión de bases de datos relacionales para beneficio del Sistema de Gestión Académica.
Métodos científicos de investigación
Los métodos científicos en los cuales se basa la investigación son los métodos teóricos y empíricos. Estos permiten organizar el trabajo, lo cual posibilita el desarrollo de un amplio
conocimiento referente al estado del arte tratado, su evolución en etapas determinadas, así como adquirir de bibliografías elementos importantes para el desarrollo del mismo.
Métodos teóricos
En la investigación científica son usados los siguientes métodos teóricos:
Analítico – sintético: Una vez realizado el análisis de una amplia bibliografía referente a los sistemas de gestión académica y en especial el funcionamiento de sus bases de datos, permitió descubrir la diferencia entre los distintos modelos de datos y la propuesta que se pretende desarrollar a lo largo del trabajo, proporcionando detalles específicos que se podrían mejorar en la misma.
Inductivo – deductivo: Será utilizado en el momento de diseñar la base de datos, pues se debe definir toda una nueva propuesta de diseño para la misma que cumpla con los requisitos deseados.
Análisis histórico – lógico: Mediante este método serán analizados trabajos y ficheros que abarquen información necesaria para el perfeccionamiento de la investigación.
Métodos empíricos
En la investigación se usará el método:
Entrevista: Permitirá la coordinación de reuniones con los jefes de módulos del proyecto Akademos, para que informen según el levantamiento de requisitos realizado, la información que debe almacenar la base de datos una vez terminada.
Estructura del contenido
La investigación constará de 3 capítulos, en los cuales se desarrollarán aspectos de importancia para lograr el objetivo que se persigue.
Capítulo #1: Fundamentación teórica
Estudio de los sistemas de gestión académica existentes a nivel nacional e internacional.
Herramientas y metodologías a utilizar en la propuesta de desarrollo.
Capítulo #2: Análisis y descripción de la solución propuesta
Selección y argumentación de los requisitos funcionales y no funcionales.
Estrategia de integración de la solución con otros módulos o sistemas.
Descripción de la arquitectura y su fundamentación.
Diagrama de clases persistentes obtenido a partir del diagrama de clases del diseño y la descripción correspondiente.
Diagrama Entidad-Relación de la base de datos y la descripción de sus tablas.
Análisis de optimización de querys.
Capítulo #3: Validación del diseño realizado
Validación teórica del diseño
Integridad
Normalización de la Base de datos
Análisis de redundancia de información
Análisis de la seguridad
Trazabilidad de la acciones
Validación funcional del diseño
Conclusiones: Valoración de resultados y propuesta de iteración en el diseño
Capítulo #1: Fundamentación teórica
1.1 Introducción
Una base de datos o banco de datos es un conjunto de datos que pertenecen al mismo contexto almacenados sistemáticamente para su posterior uso. En este sentido es válido decir que, una biblioteca puede considerarse una base de datos, en este caso compuesta en su mayor parte por documentos y textos impresos en papel e indexados para su posterior consulta. Actualmente, y debido al progresivo desarrollo tecnológico alcanzado en la informática y la electrónica, la mayoría de las bases de datos tienen formato electrónico.(1)
Las bases de datos se clasifican según su modelo de datos, que son básicamente una descripción de algo conocido como contenedor de datos, así como de los métodos para almacenar y extraer información de los mismos. Estos modelos no son elementos físicos, son abstracciones que permiten la implementación de un sistema eficiente de bases de datos, por lo general hacen referencia a algoritmos y conceptos matemáticos. El modelo utilizado en la base de datos es el relacional, siendo este el más usado en la actualidad para modelar problemas reales y administrar datos dinámicamente, para esto se apoya en la normalización, en el álgebra y el cálculo relacional.
En el presente capítulo se realiza un estudio del estado del arte de los sistemas de gestión académica, herramientas y metodologías utilizadas en el mundo, vinculadas al área de la base de datos.
A continuación se presenta el estudio realizado a sistemas de gestión académica en el ámbito nacional e internacional, él cual ha servido de apoyo en la investigación.
1.2 Ámbito internacional
1.2.1 ALBA: Sistema Libre de Gestión Educativa
Software desarrollado por un grupo de estudiantes argentinos pertenecientes al Proyecto Alba, el sistema es desarrollado en PHP, utiliza como servidor de base de datos MySQL 4.1 y el sistema operativo Linux. El software está dividido en varias secciones, entre las que encontramos Seguridad, Gestión Escolar, Docentes, Calendario, Horario Escolar, entre otros.
Entre las funcionalidades que brinda este sistema se encuentran la gestión de los alumnos dentro del centro de estudios, posibilita que sean dados de alta y baja, que sean realizados listados y búsquedas de alumnos dadas ciertas características. Permite además la gestión de notas, asistencias y ciertos registros médicos de los alumnos. Se encarga además de la gestión de los profesores de los centros de estudios y de la confección de los horarios para cada uno de estos.
Otra de las principales funcionalidades que ofrece el sistema es la gestión escolar, en esta se definen los grados/ años que componen un plan de estudios, así como la gestión de secciones /divisiones en la que son agrupadas la materias/ actividades.
Posee además secciones de informes o consultas donde se puede obtener información acerca de los estudiantes y docentes que componen el centro. Además brinda una ayuda detallada del sistema a los usuarios del mismo, la cual puede ser consultada a través de la aplicación o de internet.
1.3 Ámbito nacional
1.3.1 GESTACAD: Sistema de Gestión Académica
Este sistema fue desarrollado por la Universidad de Matanzas, surgió con la idea de desarrollar un software que permitiera automatizar la gestión académica de dicha universidad, entre las funcionalidades que brinda se encuentra la gestión de la información académica de los estudiantes universitarios, así como la información de los profesores que forman parte del proceso docente. El sistema está concebido por módulos, entre los que podemos encontrar los módulos de actualización de datos y el sitio Web, a través del cual se muestran las funcionalidades principales de la aplicación. El módulo de actualización permite matricular los nuevos ingresos, dar baja, re matricular un estudiante que ha sido baja, en cambio, no permite confirmar la matrícula, efectuar traslados, ni registrar datos necesarios para los graduados. El módulo de información permite buscar un estudiante, mostrar una estadística general de cuántos hay dado un grupo de criterios. Pero el sistema no abarca todas las esferas de la gestión universitaria y se centra en aquellos reportes que a solicitud de los usuarios fueron destacándose por su urgencia.
Este software fue utilizado por la UCI durante los dos primeros cursos docentes, resultó incapaz de adaptarse al dinamismo del centro por lo que fue sustituido por el sistema Akademos. Además presentó problemas con la navegabilidad, el ambiente de trabajo resulta en ocasiones limitado e inflexible, aspectos que obstaculizan la búsqueda de información; la interfaz requiere ser más agradable, interesante y atractiva a la vista del usuario.
1.3.2 UCIMAT
Sistema desarrollado por la UCI durante el curso 2002-2003 con el objetivo de agilizar el censo de estudiantes en el centro. Permite búsquedas de estudiantes por determinados criterios, incluye la matrícula y modificación de los datos de los mismos, así como reportes generales de
los datos de los estudiantes que están matriculados en el sistema, impidiendo que se puedan realizar otras operaciones importantes entre los que se puede destacar el re-ingreso, registro de traslado u otros datos requeridos.
El sistema está concebido por módulos, entre los que se destacan, los de actualización de datos y el sitio Web, a través del cuál se muestran las diversas salidas de la aplicación. Este software utilizaba el gestor de base de datos SQL Server 2000. Con la creación del proyecto Akademos, las funcionalidades de este sistema pasaron a ser parte de este último, las cuales están implementadas en la primera versión del sistema Akademos.
1.3.3 AKADEMOS
Actualmente este sistema presta servicios en la UCI; al mismo acceden unos 10 mil estudiantes, más de mil profesores, personal de secretaría y directivos del centro. El sistema brinda información a aplicaciones externas como son el Entorno Virtual de Aprendizaje, el Sistema de Control de Acceso, y los Directorios de Personas y Telefónicos. El proyecto y la dirección de informatización han decidido migrar este sistema a software libre y así lograr un producto libre de licencias y trabas impuestas por los desarrolladores de software propietario, surge así la versión 2.0 del sistema Akademos, la misma tiene en cuenta las funcionalidades de la versión anterior y otras nuevas que le son incorporadas.
Akademos es la principal fuente de experiencia para el nuevo software que se desarrolla. A continuación, se presentan algunas reflexiones sobre el área de la base de datos de este sistema, a pesar de que ésta posee problemas de rendimiento e implementación, aporta gran cantidad de ideas para la nueva versión.
La utilización del gestor de base de datos SQL Server 2000 es una de las dificultades que presenta el sistema, este gestor durante el tiempo que ha sido utilizado por el proyecto no ha
reportado problemas; pero es propietario y utiliza el sistema operativo Windows, lo que implica el pago de costosas licencias por el uso de los mismos. En el mundo, hoy en día existen reconocidos gestores de bases de datos libres como son PostgreSQL y MySQL, ambos multiplataforma y con las mismas prestaciones que el gestor utilizado. Por otra parte no son utilizadas al máximo las potencialidades que brinda este gestor, existe mucho código SQL incluido en las clases de acceso a datos, siendo poco factible ya que la aplicación es mucho más lenta.
Como se menciona anteriormente las principales dificultades se encuentran en el diseño, a partir de las entrevistas realizadas y de los conocimientos del equipo de trabajo se han obtenido las causas que producen estas deficiencias:
Muchos de los analistas que participaron en la creación del proyecto, abandonaron el mismo, quedando en algunos casos, en manos de desarrolladores que no poseían los conocimientos necesarios sobre el diseño realizado de la base de datos.
Durante los años de desarrollo del proyecto han variado las funcionalidades del software, influyendo esto negativamente en el modelo de datos.
La existencia de poca documentación acerca del diseño.
Como consecuencia de lo anteriormente descrito, la aplicación ha perdido rapidez, legibilidad y funcionalidad.
La base de datos de Akademos cuenta con 149 vistas, 54 procedimientos almacenados, 146 tablas, y 9 diagramas. A continuación se presenta un estudio general de la situación de cada uno de estos elementos existentes en la base de datos, con el objetivo de describir el estado de los mismos.
En las 149 tablas que posee la base de datos se almacena información de los módulos del sistema:
Módulo Plan de Estudio: Planes de estudio, niveles, momentos, asignaturas y las evaluaciones correspondientes a cada una de estas. Se almacenan además grupos de evaluaciones, conceptos, formas de calificación, disciplinas, perfiles, entre otros datos.
Módulo Registro: Notas de las distintas evaluaciones por asignatura, premios y bonificaciones. Incluye además promedios, registros de asistencia, etc.
Módulo Matrícula: Las estructuras que componen una universidad (facultades, grupos, áreas, etc.), así como toda la información personal de los estudiantes y movimientos de los mismos a través del centro de estudios.
Módulo Expediente: Documentos y plantillas asociadas a los distintos planes de estudio.
Módulo Profesor: Datos personales de los profesores del centro y la asignación de los grupos a los que estos le imparten clases.
Módulo Seguridad: Permisos e incidencias de los distintos usuarios o grupos de usuarios sobre el sistema, así como las acciones que pueden realizar sobre los distintos objetos del sistema.
Módulo Reporte: información acerca de determinados reportes estáticos.
Una vez vista la información que almacenan las tablas de la base de datos, se describe el estado de las mismas:
No todas las tablas de la base de datos siguieron la misma nomenclatura al ser nombradas, el estándar seguido es: tbl [nombre_tabla], ejemplo: tblPlanEstudio, tblAccion, tblProfesor, con el mismo existen 122 tablas, sin embargo las restantes 24 tiene nomenclatura variada, ejemplo: t_ [nombre_tabla], con este estándar fueron nombradas 18 tablas, ejemplos de ellas son: t_Hoja de matricula_114, t_Hoja de prematricula_109. Las restantes tablas fueron nombradas de una manera aleatoria, por ejemplo: Ciego, Granma, CI.
Existen tablas en la base de datos que no son utilizadas, ejemplo: tblActividad, tblCampoValorDato, tblCargo.
Se encuentran varias tablas que poseen columnas enteras sin utilizar o que permanecen en “NULL”.
Pese a que las tablas poseen estos problemas, de ella se pueden obtener experiencias positivas como son:
La nomenclatura utilizada es un elemento a tener en cuenta independientemente de los errores descritos anteriormente. Existen nombres de tablas y de atributos más generales que permiten que se ajuste a los distintos lugares donde pueda ser instalada. Además todas las tablas poseen índices numéricos, facilitando la ejecución de las consultas.
El uso de claves en todas las tablas y la correcta relación existente entre las mismas, lo que garantiza la integridad referencial.
El uso de nomencladores; este elemento es sumamente importante ya con la generación de plantillas y documentos que contienen información variada, resuelve problemas con duplicación de los datos. Pero, el uso de estos nomencladores no es tratado con toda la profundidad necesaria, por lo que existe redundancia de la información.
Las vistas al igual que las tablas, poseen deficiencias, algunas de implementación y otras de nomenclatura. Por lo general el patrón utilizado para nombrar las vistas es: v_ [nombre_vista], hay 80 vistas que cumplen con el mismo, sin embargo el resto utiliza otra nomenclatura en sus nombres. No se debe descartar que estas vistas fueron implementadas por distintos desarrolladores, que no tenían en su gran mayoría conocimientos necesarios del diseño de la base de datos, por lo que muchas de éstas son óptimas y poseen una buena implementación, mientras que otras todo lo contrario. Además existen vistas que no son utilizadas porque fueron construidas para resolver un problema en un momento determinado y actualmente no se hace referencia a las mismas. Por otra parte existen vistas que devuelven datos semejantes, éstas
fueron implementadas sin tener el conocimiento de la información que es retornada por muchas de las ya existentes.
Existen 54 procedimientos almacenados, los que son utilizados en su gran mayoría, en la creación de nuevos objetos en la base de datos, lo que constituye una medida importante de seguridad contra el SQL Injection. Estos poseen una correcta implementación y utilización.
La redundancia en la información es otro elemento que esta presente en los datos almacenados, las áreas que presentan más problemas son plan de estudio y matrícula; con la creación de un plan de estudio nuevo se crean un conjunto de asignaturas, formas de calificación, grupos de evaluación, conceptos, etc., muchos de estos comunes con los ya existentes en otros planes de estudios; por citar un ejemplo, la tabla que almacena las asignaturas posee 13 columnas y 3838 tuplas de datos, de ellas 3432 pertenecen a asignaturas optativas, estas son comunes entre 7 de los planes de estudios existentes hoy en la UCI, por lo que en verdad existen 510 asignaturas de esta clasificación, las demás 2922 tuplas son información redundante. En cuanto al área de matrícula, existen varias hojas de matrícula y de pre-matrícula, cada una de estas posee tablas para almacenar información, siendo común en muchos casos. Existe además la tabla TblValorCampo que posee información frecuente para varias de las áreas del sistema , existen por ejemplo 25 tuplas con el nombre de la provincia de Cienfuegos, Matanzas, y así con el resto de los datos almacenados, esto provoca que la tabla posea más de 6000 registros, cuando debería poseer poco más de 100.
De manera general lo anteriormente describe la base de datos del sistema Akademos, quedando expuesto lo bueno y lo malo de la misma, teniéndose en cuenta en la nueva propuesta de diseño.
1.4 Aporte obtenido de los sistemas de gestión académica estudiados
El estudio de estos sistemas ha servido como base para detallar los modelos que presentan estos sistemas en sus bases de datos, se ha analizado además algunos de los métodos utilizados en el manejo de los nomencladores, con el objetivo de eliminar la redundancia de información. Se ha detallado además en el manejo de los datos históricos de los estudiantes ya graduados. En el caso de la UCI, los datos de los mismos permanecen junto a los no graduados, por lo que al realizar consultas sobre estos se analizan un conjunto de tuplas que pertenecen a datos ya históricos, trayendo consigo un mayor consumo de recursos y una demora en el tiempo de respuesta. Se obtienen además importantes aportes en cuanto al manejo de la seguridad y trazabilidad de la información.
1.5 Herramientas, estrategias y metodologías utilizadas en la propuesta de diseño
1.5.1 Gestor de base de datos
Un gestor de bases de datos es un tipo de software específico, dedicado a servir de interfaz entre la base de datos, el usuario y las aplicaciones que la utilizan. Se compone de un lenguaje de manipulación de datos y de un lenguaje de consulta. El propósito general de los gestores de base de datos es el de manejar de manera clara, sencilla y ordenada un conjunto de datos que posteriormente se convertirán en información relevante, para un buen manejo de datos. Los principales objetivos de los gestores de base de datos son:
Abstracción de la información: Los gestores ahorran a los usuarios detalles acerca del almacenamiento físico de los datos.
Independencia: Consiste en la capacidad de modificar el esquema físico o lógico de una base de datos sin tener que realizar cambios en las aplicaciones que se sirven de ella.
Respaldo y recuperación: Los gestores deben proporcionar una forma eficiente de realizar copias de respaldo de la información almacenada en ellos, y de restaurar a partir de estas copias datos perdidos.
Seguridad: La información almacenada en una base de datos puede llegar a tener un gran valor, los gestores deben garantizar que esta información se encuentre segura frente a usuarios malintencionados, que intenten acceder a la misma con el objetivo de manipularla o destruirla. Los gestores de base de datos cuentan con un complejo sistema de permisos y grupos de usuarios, que permiten otorgar diversas categorías de permisos.
Hoy en día existe gran cantidad de gestores, cada uno con características distintas, así como ventajas y desventajas a la hora de ser usado, los dos principales gestores libres son:
PostgreSQL y MySql, ambos muy populares. En la investigación es utilizado el PostgreSQL, este gestor ha sido elegido por la dirección de informatización y del proyecto por sus características, las que se describen a continuación junto a algunos datos de interés del mismo.
1.5.1.1 PostgreSQL
PostgreSQL es un gestor de base de datos relacional orientada a objetos, ya que incluye características como la herencia, tipos de datos, funciones, restricciones, disparadores, reglas e integridad transaccional. El único costo asociado a PostgreSQL es el de conocerlo, este posee licencia BSD, permitiendo la libertad de uso, modificación y distribución en productos comerciales o no comerciales.
De manera general estas son las principales características del gestor, reflejando el por qué fue elegido por el equipo de desarrollo para la nueva versión del sistema.
Implementa el estándar SQL92/SQL99.
Alta concurrencia, mediante un sistema denominado MVCC (Acceso concurrente multiversión, por sus siglas en inglés). Este permite que mientras un proceso escribe en una tabla, otros accedan a la misma tabla sin necesidad de bloqueos. Cada usuario
obtiene una visión consistente de lo último que se le hizo commit. Esta estrategia es superior al uso de bloqueos por tablas o por filas común en otros gestores, eliminando la necesidad del uso de bloqueos explícitos.
Posee soporte para distintos tipos de datos.
Incorpora funciones de diversa índole como son para el manejo de fechas, geométricas, orientadas a operaciones con redes, etc.
Al igual que con los tipos de datos, PostgreSQL permite la declaración de funciones propias.
Soporta transacciones, subconsultas, rollback’s y desde la versión 7.0, claves ajenas (con comprobación de integridad referencial).
Posee un buen soporte para triggers y procedimientos en el servidor.
Posee soporte para el uso de índices, reglas y vistas.
Además corre en la mayoría de los sistemas operativos más utilizados, Linux, varias versiones de UNIX (AIX, BSD, HP-UX, SGI IRIX, Mac OS X, Solaris, SunOS, Tru64), BeOS y Windows.
Escritura adelantada de registros (WAL) para evitar pérdidas de datos en caso de falla de energía, sistema operativo o de hardware.
Posee productos que lo complementan, y que ayudan a mejorar su desempeño, eficiencia y manipulación:
PgCluster y Slony-I: Utilizados en la replicación de datos, el primero en réplicas multi- maestro y el segundo en réplicas maestro esclavo.
PgAdmin3, PgAccess, PhpPgAdmin, Psql: Herramientas de administración.(2)
El principal soporte de PostgreSQL lo provee la gran comunidad de usuarios que existe en el mundo, quienes aportan experiencias y soluciones obtenidas del trabajo con este gestor. Posee además soporte comercial, destacándose la aportada por su equipo de desarrollo.
De manera general estas son las características de PostgreSQL, las cuales se ajustan a las principales demandas del proyecto en cuanto al gestor de datos, estas son:
Debe poseer altos niveles de confiabilidad y escalabilidad.
Sea estable durante el manejo de grandes volúmenes de información.
Soporte altos volúmenes de concurrencia.
Soporte integridad referencial.
Soporte procedimientos almacenados o funciones y vistas.(3)
La versión utilizada del gestor propuesto es PostgreSQL 8.1.2 1.5.2 Metodología
Durante la construcción de la propuesta de diseño es utilizada la metodología RUP para el desarrollo de la misma, ya que más que un simple proceso; es un marco de trabajo genérico que puede especializarse para una gran variedad de software, para diferentes áreas de aplicación, tipos de organizaciones, niveles de actitud y tamaños de proyecto. La dirección del proyecto Akademos, decidió el uso de dicha metodología en el desarrollo del sistema en general.
Además es usado el Lenguaje de Modelado Unificado (UML), es usado para visualizar, especificar, construir y documentar los artefactos de un sistema que involucra gran cantidad de software.
UML proporciona una forma estándar de escribir los planos de un sistema, cubriendo tanto l os elementos conceptuales, procesos del negocio y funciones del sistema, como elementos concretos: las clases escritas en un lenguaje de programación específico, esquemas de bases de datos y componentes de software reutilizables.
1.5.3 Herramientas de modelado 1.5.3.1 Visual Paradigm
El Visual Paradigm es una herramienta CASE de fácil uso. Tiene la ventaja de ser multiplataforma. No es de libre distribución, pero la UCI pagó la licencia de Visual Paradigm para UML, tiene la ventaja de que soporta el ciclo de vida completo del desarrollo de software: análisis y diseño orientados a objetos, construcción, pruebas y despliegue. Este software de modelado ayuda a una más rápida construcción de aplicaciones de calidad, mejores y a menor costo.
Permite dibujar todos los tipos de diagramas de clases, código inverso, generar código desde diagramas y generar documentación. Dentro de los diagramas que permite crear en el modelado de datos se encuentra el diagrama de Entidad-Relación (ERD), dicho diagrama es usado en el diseño de la propuesta de la base de datos para Akademos 2.0.
1.5.3.2 DBDesigner 4.0
Es un software totalmente visual de diseño de bases de datos, que combina características y funciones profesionales con un diseño simple, muy claro y fácil de usar, a fin de ofrecer un método efectivo para gestionar bases de datos para aplicaciones desarrolladas en Java, C++, Visual C# ó Visual Basic, Perl ó PHP, para el uso en la web.
Con esta herramienta totalmente libre se pueden desarrollar las siguientes tareas en el momento de construir la base de datos:
Crear y modificar las diferentes tablas que tiene el diseño.
Crear y modificar las diferentes relaciones.
Crear y generar las llaves primarias y secundarias.
Crear y modificar los índices.
Crear y generar las condiciones que deben existir para asegurar la integridad relacional.
Crear y visualizar el diagrama entidad relación.
Crear y generar el código que permite crear la base de datos en el servidor. Que también generan los índices y se encargan de asegurar la integridad relacional.
A través del DER se puede visualizar todos los datos y así es mucho mas fácil saber si todo está en su sitio y si las relaciones de las diferentes tablas están creadas correctamente.
Se puede crear un diagrama a partir de una base de datos que no haya sido creada por uno mismo, sino que ya estaba existente en el momento de comenzar el proyecto. A este proceso se le conoce con el nombre de ingeniería inversa.(4)
Conclusiones
Hasta el momento ha sido abordado el estado del arte relacionado con los sistemas de gestión académica en el ámbito internacional y nacional. De estos sistemas estudiados se ha obtenido un conjunto de experiencias que han servido de apoyo a la investigación, en el caso de Akademos, se realizó un estudio detallado de su base de datos y de su interacción con el sistema de manera general, presentando problemas de rendimiento y escalabilidad, debido a una implementación en un corto período de tiempo, los constantes cambios y el gran volumen de información que se almacena en la base de datos. Por otra parte se describió la tecnología utilizadas durante la investigación, es válido señalar que no se realiza un estudio comparativo entre los distintos tipos de software utilizados en el mundo hoy en día en esta área, ya que la investigación se ajusta a las políticas de la dirección de informatización en cuanto al uso de determinados software para el desarrollo de sus proyectos productivos. El conjunto de software descrito se ajusta a las necesidades del sistema, estos cuentan con las funcionalidades y el soporte adecuado para ser utilizados durante el desarrollo de la nueva versión del sistema.
Capítulo #2: Análisis y descripción de la solución propuesta
2.1 Introducción
En el presente capítulo se describen actividades de vital importancia para la construcción de la base de datos, entre ellas se encuentra la selección y argumentación de los requisitos del sistema, la descripción de la arquitectura propuesta y la estrategia de integración de la base de datos con los módulos del sistema y otras aplicaciones externas, a partir de la arquitectura propuesta.
Se construye la propuesta de diseño de la base de datos, para lograr este objetivo es desarrollado el modelo lógico y físico de los datos. Se describen además las clases obtenidas de ambos modelos.
2.2 Estructura general del área de la base de datos
Partiendo del estudio realizado del estado del arte y con las experiencias adquiridas, se propone que la información de los estudiantes graduados se guarde en una base de datos dedicada al almacenamiento de la misma. Al ser movida esta información hacia la base de datos histórica, es eliminada de la base de datos central, evitando la redundancia de la información. En estos momentos no existe un estudio realizado por el equipo de analistas que indique la información que se debe almacenar en la base de datos histórica, por el momento se propone el mismo diseño realizado para la base de datos central del sistema Akademos 2.0.
Por otra parte, si el centro de estudios posee más de una sede, como en el caso de la UCI, la información que contiene la base de datos de Akademos no esta almacenada en un solo lugar, actualmente existen 3 facultades regionales de la universidad en todo el país donde ha sido
desplegado el sistema, cada una de ellas posee una base de datos independiente, la información que se genera en las mismas debe ser almacenada en la sede central; se propone un sistema de replicas con el objetivo de mantener actualizada la base de datos central del sistema.
El siguiente esquema representa gráficamente las ideas expuestas anteriormente, para el caso de la UCI:
Figura 1 Estructura general del área de la base de datos. Akademos.
Es válido aclarar que a partir de este momento cuando se hable de base de datos de Akademos, se hace referencia a la base de datos central, ya que el diseño de la misma difiere de las demás bases de datos que se proponen para el sistema, las cuales no son abordadas en lo adelante ya que no son objetivo de la investigación.
2.3 Selección y argumentación de los requisitos funcionales y no funcionales del sistema propuesto
Los requisitos son condiciones o capacidades que tienen que ser alcanzada o poseída por un sistema o componente de un sistema para satisfacer un contrato, estándar, u otro documento impuesto formalmente. Se clasifican en requisitos funcionales y requisitos no funcionales. Los primeros son capacidades o condiciones que el sistema debe cumplir y los segundos propiedades o cualidades que el producto debe tener.
2.3.1 Requisitos funcionales
La tesis da respuesta a un gran número de requisitos funcionales de los distintos módulos que componen el Sistema Akademos 2.0, así como de distintas aplicaciones que necesitan información de la base de datos para su funcionamiento. A continuación aparece una descripción de los principales requerimientos propuestos por los analistas del sistema:
R1 Matricular asignatura de adelanto.
R2 Eliminar asignatura de estudiante.
R3 Elaborar modelos de actas de evaluaciones.
R4 Personalizar registro del profesor.
R5 Gestionar grupo docente.
R6 Gestionar asistencia.
R7 Gestionar evaluaciones.
R8 Gestionar bonificaciones.
R9 Gestionar premios.
R10 Generar hoja de resultado académico.
R11 Gestionar alertas.
R12 Gestionar datos del estudiantes.
R13 Buscar estudiante.
R14 Gestionar datos de los estados.
R15 Gestionar datos de una definición de movimiento.
R16 Aplicar movimiento.
R17 Consultar matrícula actual.
R18 Consultar estudiante por tipo de estado.
R19 Matricular estudiantes.
R20 Gestionar disciplina.
R21 Gestionar forma de calificación.
R22 Gestionar evaluación de una asignatura.
R23 Gestionar asignatura.
R24 Gestionar perfiles.
R25 Gestionar nivel académico.
R26 Gestionar momento académico.
R27 Gestionar concepto de bonificación.
R28 Gestionar plan de estudio.
R29 Gestionar tipo de asignatura.
R30 Gestionar concepto.
R31 Adicionar profesor.
R32 Modificar profesor.
R33 Eliminar profesor.
R34 Buscar profesor.
R35 Adicionar grupos al profesor.
R36 Eliminar grupos al profesor.
R37 Crear tipo de profesor.
R38 Actualizar tipo de profesor.
R39 Eliminar tipo de profesor.
R40 Crear categoría docente.
R41 Actualizar categoría docente.
R42 Eliminar categoría docente.
R43 Consultar información.
R44 Autenticar.
R45 Comprobar permisos.
R46 Registrar incidencia.
R47 Gestionar permiso.
R48 Gestionar rol.
R49 Generar reportes.
R50 Gestionar asignación de rol.
R51 Gestionar problemas.
R52 Buscar problema.
R53 Gestionar asignación de problema.
R54 Gestionar tutor.
R55 Solicitar problema.
R56 Proponer problema.
R57 Aprobar propuesta de problema.
R58 Aprobar perfil.
R59 Modificar perfil.
R60 Gestionar estructura de tribunal.
R61 Gestionar tribunal de tesis.
R62 Asignar tribunal de tesis.
R63 Gestionar evaluación de tesis.
R64 Entregar tesis.
R65 Mostrar tesis.
R66 Imprimir tesis.
2.3.2 Requerimientos no funcionales
Los requisitos no funcionales se clasifican según la categoría a la que pertenecen. Debe pensarse en estas propiedades como las características que hacen al producto atractivo, usable, rápido y confiable. A continuación se describen los principales requerimientos relacionados con la base de datos.
Seguridad
Confidencialidad:
El servidor de la base de datos deberá estar Linux, al que solo tendrán acceso los administradores de la base de datos.
La conexión será través de un usuario y contraseña definidos por el administrador del servidor.
Integridad:
Se propondrán valores válidos para dominios, atributos y relaciones.
No se permitirá el uso de operaciones y transacciones de actualización que dejen cualquier relación en un estado que viole sus restricciones de integridad.
Las claves o llaves primarias deberán satisfacer las propiedades de unicidad e irreductibilidad.
Disponibilidad
La base de datos tendrá que estar disponible las 24 horas del día.
Hardware
Para el desarrollo:
PC con las siguientes características: Pentium 4 CPU 3.00 GHz ; 512 MB de RAM ; 160 GB de disco duro
Para la explotación:
Servidor con las siguientes características: Dual Core CPU 2.0 GHz; 2 GB de RAM mínima, 4 GB de RAM recomendada; 250 GB de disco duro
Software
Sistema operativo Linux del servidor: Ubuntu Server 7.10
Gestor de base de datos: PostgreSQl 8.1.2
Herramienta de administración de base de datos: pgAdmin III v 1.8.2
Herramienta de modelado: Visual Paradigm for UML 6.0 Enterprise Edition
Herramienta de modelado: DBDesigner 4
Soporte
Se confeccionará el manual de usuario del sistema.
Usabilidad
Se permitirá el acceso a la base de datos a todo usuario autorizado.
2.4 Estrategia de integración de la solución con otros módulos o sistemas
La nueva versión del sistema Akademos esta actualmente dividida en varios módulos, estos son:
Plan de Estudio, Matrícula-Expediente, Control Docente, Seguridad, Profesor, Tesis y Postgrado.
Estos módulos gestionan en conjunto toda la información referente a la gestión académica de un centro de estudios, es de vital importancia que esta persista, por lo que la interacción de los mismos con la base de datos es muy estrecha.
La base de datos no solo esta integrada por los distintos módulos que componen el sistema, sino que brinda información a otras aplicaciones que requieren datos personales y académicos contenida en la misma. En la UCI por ejemplo ofrece información a través de servicios WEB; al Entorno Virtual de Aprendizaje, Sistema de Comedores, Sistema de Reservación de Pases y Sistema de acreditación, por solo mencionar algunos.
El intercambio de información con la base de datos en ambos casos se realiza a través de clases de acceso a datos, generadas por los frameworks utilizados en el desarrollo, a su vez serán implementados una serie de funciones que estarán encargadas de chequear la integridad y seguridad de los datos.
2.5 Descripción de la arquitectura propuesta y su fundamentación
El sistema Akademos en su versión 2.0 utiliza como lenguaje de programación PHP 5, y como framework el Symfony, el cuál es compatible con el gestor de base de datos utilizado en el sistema, además este framework se puede ejecutar en plataformas Unix, Linux y Windows. Son utilizados a la par de Symfony los framework Propel y Creole, el primero de estos es un framework de mapeo de objetos a bases de datos (ORM) utilizado por PHP5, permite el acceso a bases de datos a través del uso de objetos, ofrece una API sencilla para almacenar y recuperar datos, de manera general permite la generación automática del la estructura básica de las clases de acceso a datos. Por otra parte el framework Creole permite la abstracción de la base de datos
al programador, de manera que si es cambiado el gestor de base de datos no es necesario modificar el código, ya que a través de la modificación de un fichero de configuración es asimilado el cambio.
El modelo lógico y el modelo físico son realizados en el Visual Paradigm, pero Propel y Creole utilizan esquemas de datos generados por el DBDesigner, por lo que se utiliza esta herramienta para convertir los archivos generados por el Visual Paradigm, a esquemas que puedan ser interpretados por estos frameworks. [Ver anexo 3].
De manera general el software que es utilizado en el desarrollo del proyecto es el PostgreSQL como gestor de base de datos, el DBDesigner y Visual Paradigm como herramientas de modelado, y el Eclipse Europa 3.3.0 con el plugins PDT(PHP Development Tools) como herramienta de desarrollo.
2.6 Diseño de la base de datos
En dicho epígrafe se describen los patrones de diseño utilizados en la construcción de la base de datos, así como el diagrama de clases persistentes y el diagrama entidad-relación de los datos.
Patrones utilizados.
Durante la confección del diagrama de clases persistentes y el diagrama entidad-relación de la base de datos se utilizan varios patrones de diseño, entre los que se encuentran los patrones de Brown, a continuación se describen los mismos.
Nombre: Representación de objetos como tablas
Este patrón es utilizado cuando se quiere representar un objeto en un esquema de base de datos relacional. Se propone como solución definir una tabla para cada clase de objetos persistente.
Los atributos de la clase que son tipos primitivos serán las columnas de la tabla.
Nombre: Intermediario de base de datos:
Al presentarse el siguiente problema: ¿Quién debe ser responsable de la persistencia de los objetos?, es utilizado este patrón, propone como solución construir una clase, “bróker”, que es responsable de la materialización y desmaterialización de cada uno de los objetos persistentes.
Nombre: Representación de relaciones como tablas
Al diseñar una base de datos se debe tener en cuenta como representar una relación en un esquema de base de datos relacional, este patrón de diseño propone soluciones para los distintos tipos de relaciones que posee este modelo de datos.
Para las relaciones uno a uno ó uno a muchos:
Colocar una clave ajena en la tabla de cardinalidad uno, para representar la relación entre los objetos.
O, crear una tabla asociativa para registrar los identificadores de cada uno de los objetos de la relación.
Para las relaciones muchos a muchos:
Crear una tabla asociativa para registrar los identificadores de cada uno de los objetos de la relación.
2.6.1 Diagrama de clases persistentes
El diagrama de clases persistentes es obtenido a partir del diagrama de clases del diseño. La persistencia es la propiedad de los objetos de trascender su estado en el tiempo y el espacio.
Estos datos existen durante las ejecuciones de un programa, entre distintas versiones del programa o sobreviven a la eliminación del mismo. Debido al tamaño del diagrama este se ha dividido en 3 secciones para su mejor visualización.
Figura 2 Diagrama de Clases Persistentes
Figura 3 Diagrama de Clases Persistentes(Continuación)
Figura 4 Diagrama de Clases Persistentes(Continuación)
2.6.2 Descripción de las clases persistentes
A continuación se representa la descripción de las clases persistentes modeladas anteriormente, de cada una de ellas se especifica el nombre, el tipo de clase, atributos y el tipo de cada uno de estos.
Tabla 2.1 Descripción de la clase: CEGrupoAcadémico Nombre: CEGrupoAcademico
Tipo de clase Entidad
Atributo Tipo
Id_GrupoAcademico Int
Nombre String
Activo Boolean
Tabla 2.2 Descripción de la clase: CENota Nombre: CENota
Tipo de clase Entidad
Atributo Tipo
Tabla 2.3 Descripción de la clase: CEAsistencia Nombre: CEAsistencia
Tipo de clase Entidad
Atributo Tipo
Fecha String
Tabla 2.4 Descripción de la clase: CETipoAsistencia Nombre: CETipoAsistencia
Tipo de clase Entidad
Atributo Tipo
Id_TipoAsistencia Int
Nombre String
Tabla 2.5 Descripción de la clase: CEEdicionMomento Nombre: CEEdicionMomento
Tipo de clase Entidad
Atributo Tipo
Id_EdicionMomento Int
Nombre String
FechaInicio String
FechaFin String
Tabla 2.6 Descripción de la clase: CEBonificación Nombre: CEBonificacion
Tipo de clase Entidad
Atributo Tipo
Id_Bonificacion Int
Valor Float
Fecha String
Tabla 2.7 Descripción de la clase: CEEstado Nombre: CEEstado
Tipo de clase Entidad
Atributo Tipo
Id_Estado Int
Nombre String
Color String
Sistema Boolean
Terminal Boolean
Tabla 2.8 Descripción de la clase: CEDocumentoExterno Nombre: CEDocumentoExterno
Tipo de clase Entidad
Atributo Tipo
Id_Documento Int
Valor String
Tabla 2.9 Descripción de la clase: CEEstudiante Nombre: CEEstudiante
Tipo de clase Entidad
Atributo Tipo
Tabla 2.10 Descripción de la clase: CECampo Nombre: CECampo
Tipo de clase Entidad
Atributo Tipo
Id_Campo Int
Nombre String
Descripción String
Es_Nomenclador Boolean
Fecha String
Tabla 2.11 Descripción de la clase: CEPlantilla Nombre: CEPlantilla
Tipo de clase Entidad
Atributo Tipo
Id_Plantilla Int
Nombre String
Descripción String
Fecha String
Tabla 2.12 Descripción de la clase: CENomenclador Nombre: CENomenclador
Tipo de clase Entidad
Atributo Tipo
Id_Nomenclador Int
Valor String
Id_Estandar Int
Id_Padre Int
Tabla 2.13 Descripción de la clase: CENivel Nombre: CENivel
Tipo de clase Entidad
Atributo Tipo
Id_Nivel Int
Nombre String
Descripcion String
Activo Boolean
Orden Int
Tabla 2.14 Descripción de la clase: CEPlanEstudio Nombre: CEPlanEstudio
Tipo de clase Entidad
Atributo Tipo
Id_PlanEstudio Int
Nombre String
Descripcion String
ValorMaxEscalaGeneral Int
ValorMinEscalaGeneral Int
Aprobado Int
DocAsociado String
Tabla 2.15 Descripción de la clase: CEMomento Nombre: CEMomento
Tipo de clase Entidad
Atributo Tipo
Id_Momento Int
Nombre String
Descripcion String
Activo Boolean
Orden Int
Tabla 2.16 Descripción de la clase: CEFormaCalifConjunto Nombre: CEFormaCalifConjunto
Tipo de clase Entidad
Atributo Tipo
Valor String
ValorEquivalente String
Tabla 2.17 Descripción de la clase: CEAsignatura Nombre: CEAsignatura
Tipo de clase Entidad
Atributo Tipo
Id_Asignatura Int
Nombre String
Descripcion String
Tabla 2.18 Descripción de la clase: CEPerfil Nombre: CEPerfil
Tipo de clase Entidad
Atributo Tipo
Id_Perfil Int
Nombre String
Descripcion String
Tabla 2.19 Descripción de la clase: CEDisciplina Nombre: CEDisciplina
Tipo de clase Entidad
Atributo Tipo
Id_Disciplina Int
Nombre String
Descripcion String
