trabajo de fin de carrera mariano pérez herraiz bases de datos relacionales itig consultor: manel...

Trabajo de Fin de Carrera Mariano Pérez Herraiz

Bases de Datos RelacionalesITIG

Consultor: Manel Rella RuizUniversidad Oberta de Catalunya - 2011

1. Introducción y Objetivos pág 42. Enfoque y Planificación pág 6

Enfoque del Trabajo pág 6 Planificación pág 8 Productos Obtenidos pág 9

3. Análisis pág 10 Visión general del sistema pág 10 Criterios para los requisitos pág 11 Resumen requisitos Funcionales pág 11 Resumen requisitos no Funcionales pág 12

4. Diseño pág 135. Implementación pág 14

Procedimientos de Mantenimiento pág 14 Módulo Estadístico pág 15 Módulo de Consulta pág 15

6. Pruebas pág 16 Criterios de Pruebas pág 16

Indice

TFC - 2011 Sistema de gestión de amonestaciones y sanciones en centros educativos 2

Pruebas pág 167. Conclusiones pág 17

Indice

TFC - 2011 Sistema de gestión de amonestaciones y sanciones en centros educativos 3

TFC - 2011 Sistema de gestión de amonestaciones y sanciones en centros educativos

1. Introducción y Objetivos Objetivos

Poner en práctica los conocimientos adquiridos Utilizar un SGBD extendido en el mercado Realizar un proyecto siguiendo una planificación

Metodología Desarrollo en cascada Una fase no comienza hasta que finaliza la anterior Las fases se realimentan con la información de las fases siguientes: no

son cerradas Productos

Memoria del proyecto Presentación de diapositivas Script de creación de tablas Script de creación de procedimientos Script de carga de datos estáticos Script para pruebas

4


1. Introducción y Objetivos Fases del proyecto

Análisis Definir claramente las funcionalidades que tendrá el sistema: requisitos

Diseño Llegar a obtener la estructura física de la BD a partir de los requisitos

Implementación Codificar los procedimientos almacenados necesarios

Pruebas Comprobar funcionamiento

5


2. Enfoque y PlanificaciónEnfoque del trabajo El primer paso ha sido realizar un análisis inicial de los requerimientos recogidos

en el enunciado y elaborar un plan realista y ajustado para alcanzar en plazo, alcance y calidad los objetivos establecidos.

Para conseguir una estimación ajustada del volumen de trabajo y una planificación lo más realista posible, se ha estimado conveniente utilizar el ciclo de vida clásico (o en cascada). Las fases seguidas han sido las siguientes:

Análisis. Diseño. Implementación. Pruebas.

En los procesos de desarrollo de los productos previstos en el trabajo se utilizaran los métodos, técnicas y herramientas aprendidos en las diferentes asignaturas realizadas y que más adecuados resulten para obtener cada uno de los productos a desarrollar:

La planificación se ha realizado de acuerdo con los métodos aprendidos en la asignatura de Informática Aplicada a la Gestión.

Se han aplicado los métodos y técnicas de diseño de bases de datos relacionales aprendidos en la asignatura Bases de Datos I (diagramas Entidad/Relación, diseño lógico, normalización de tablas, etc.) para el desarrollo de la base de datos y la elaboración de sus scripts correspondientes.

6


2. Enfoque y Planificación Los métodos de desarrollo aprendidos en Bases de Datos I y II se han utilizado para

desarrollar los procedimientos almacenados requeridos para la realización de operaciones sobre la base de datos.

7


2.Enfoque y PlanificaciónPlanificación La planificación y la estimación del

esfuerzo presentan un plan de trabajo adecuado para alcanzar los objetivos marcados. Para su elaboración se realizaron las siguientes actividades:

Se identificaron los objetivos previstos, el alcance de los entregables y los hitos principales del proyecto.

Se eligió una estructura de proyecto basada en el ciclo de vida en cascada para alcanzar estos objetivos.

Se realizó una descomposición estructural en actividades adecuada, y se detalló el contenido y alcance de las actividades identificadas

Una vez identificadas las tareas y actividades requeridas, se realizó su planificación temporal, elaborando una tabla de precedencias entre actividades y estimando su duración de acuerdo con mi experiencia y conocimientos.

8


2. Enfoque y PlanificaciónProductos Obtenidos Tras la realización del proyecto completo, los entregables que obtenidos en

este Trabajo Final de Carrera son los siguientes: Plan de Trabajo: planificación y estimación de las tareas necesarias para llevar a

cabo los objetivos previstos. Producto: desarrollos correspondientes a la Base de Datos. Memoria: síntesis del trabajo realizado y muestra que se han alcanzado los

objetivos propuestos. Presentación: resumen claro y conciso, en diapositivas, del trabajo realizado y

de los resultados obtenidos.

9


3. Análisis El primer paso ha sido realizar un análisis inicial de los requerimientos

recogidos en el enunciado, detectando tanto los requisitos funcionales como los no funcionales.

Visión general del sistema: Gestión de amonestaciones y sanciones en centros educativos Almacena la información de alumnos matriculados, los cursos donde están

matriculados y los profesores que impartiesen estos cursos. El sistema debe permitir introducir las incidencias o amonestaciones de los alumnos. En caso de tener una amonestación suficientemente grave o una acumulación de

amonestaciones se debe poder introducir una sanción indicando los motivos y la resolución de la misma.

Adicionalmente a este funcionamiento, la base de datos se encargará de precalcular y almacenar diversa información estadística, la cual debe de responder a las siguientes preguntas:

El número de amonestaciones por alumno (independientemente del curso). El número de sanciones por alumno y año. La media de amonestaciones por profesor y año. El número de sanciones por curso y año. El nombre del alumno más sancionado en un año dado. El nombre del profesor más amonestador (que pone más amonestaciones) por curso. La media de sanciones que tienen los alumnos por curso. El número de alumnos que no tienen ninguna amonestación.

10


3. Análisis Criterios para los requisitos

Detectar funcionalidades a partir de la descripción del cliente. Una funcionalidad para cada requisito y un requisito para cada funcionalidad. Requisitos cortos, claros y concisos. Funcionalidades no descritas por el cliente pero necesarias o convenientes

también tienen requisito asociado. Resumen de requisitos funcionales

Alta baja y modificación de: Alumnos, Profesores, Calendarios escolares, Cursos, Asignaturas, Amonestaciones, Sanciones, Tipos de amonestación y sanción, reglas de activación automática de sanción y horas y días de atención a los padres.

Se debe de poder saber que curso pertenece cada alumno, que profesores dan cada asignatura y que profesores son responsables de cada curso.

En cualquier momento se debe de poder saber que amonestaciones y sanciones se han asignado a cada alumno.

Procedimientos de consulta que permita obtener: Listado de todas las amonestaciones impuestas Listado de todos los alumnos de un curso Listado de todos los tipos de amonestaciones y sanciones disponibles para aplicar en el

centro Listado de todas las amonestaciones y sanciones de un alumno

Módulo estadístico, descrito en la diapositiva anterior.

11


3. Análisis Resumen de requisitos no funcionales

Sistema gestor de Bases de Datos: Oracle. Utilización de procedimientos almacenados:

Devolución de parámetro de salida indicativo del éxito o fracaso. Control de excepciones.

Tabla de logs para almacenar el resultado de la ejecución de los procedimientos. No se especifica nada respecto a la política de seguridad. No se impone restricción respecto al sistema operativo. No se especifica ninguna tarea de mantenimiento a realizar sobre la Base de

Datos.

12


4. Diseño El diseño del sistema se ha realizado en tres etapas:

Diseño conceptual: se busca un diseño independiente de la tecnología que se va a emplear obteniendo un modelo UML como resultado de esta etapa. Para ello se realizan las siguientes tareas:

Identificar entidades principales, intermedias y auxiliares. Identificar relaciones entre ellas. Decidir conectividad y dependencias de existencia.

Diseño lógico: se transforma el modelo UML en un modelo relacional, ya que utilizaremos como tecnología un SGBD relacional, según las siguientes reglas:

Las entidades originan relaciones. Las interrelaciones binarias 1:1 y 1:N originan claves foráneas. Las interrelaciones binarias M:N originan nuevas relaciones.

Diseño físico: A partir del paso anterior, se decide cómo crear los objetos necesarios en nuestro SGBD particular, además, se buscan otros objetivos:

Disminuir tiempo de respuesta. Minimizar espacio en disco. Seguridad de los datos. Optimizar recursos. Módulo estadístico: se ha creado una tabla para cada una de las

consultas a las que debe de dar respuesta.

13


5. Implementación La implementación se ha dividido en tres partes, todos los procedimientos al

finalizar insertan en la tabla de log el resultado de la ejecución: Procedimientos de Mantenimiento (A/B/M): estos procedimientos se encargan

de mantener la información de las tablas principales del sistema. Se ha optado por crear una serie de packages los cuales contienen procedimientos que realizan el mantenimiento de las tablas del bloque al que van asociados. Los packages creados son los siguientes:

PCK_CENTROS: gestiona toda la información relacionada con el centro (Centros, Cursos, Asignaturas, Calendario Escolar y Año Escolar).

PCK_PROFESORES: gestiona toda la información relacionada con los profesores (Profesores, Horario de Atención, Asignatura que imparte).

PCK_ALUMNOS: gestiona toda la información relacionada con los alumnos (Alumnos, Curso en el que está matriculado el Alumno).

PCK_AMONESTACIONES: gestiona toda la información relacionada con las amonestaciones (Tipos de Amonestación, Amonestaciones).

PCK_SANCIONES: gestiona toda la información relacionada con las sanciones (Tipos de Sanción, Sanciones).

Cada procedimiento realiza una serie de comprobaciones antes de realizar la función para la que fue creado (Alta/Baja/Modificación).

14


5. Implementación Módulo de Estadísticas: este módulo se basa en una serie de disparadores o

trigger que se activan después de realizar alguna operación (inserción, modificación o borrado) sobre determinadas tablas de la Base de datos, estas son: Amonestaciones, Sanciones, Curso Alumno y Alumno.

Y a su vez también tiene un procedimiento que es invocado por estos disparadores que se encarga de ver si se debe de activar una regla automática para aplicar una sanción.

Módulo de consultas: Este módulo está formado por una serie de funciones las cuales devuelven un conjunto de registros que contienen la información solicitada. Estas funciones la ventaja que tienen es que pueden ser invocadas por programas de alto nivel o bien consultadas por el propio usuario, vía SQL, consultándolas como si fuera una tabla cualquiera.

Se ha creado una función para cada una de las siguientes consultas: Listado de todas las amonestaciones impuestas. Listado de todos los alumnos de un curso. Listado de todos los Tipos de Amonestación disponibles para aplicar en el centro. Listado de todos los Tipos de Sanción disponibles para aplicar en el centro. Listado de todas las Amonestaciones impuestas a un alumno. Listado de todas las Sanciones impuestas a un alumno.

15


6. Pruebas Criterios para las pruebas:

Las pruebas no comprueban exhaustivamente todas y cada una de las funcionalidades del sistema (casos de errores posibles, casos particulares…), sino que se ha tratado de hacer que fuese una prueba representativa de las funcionalidades más importantes, al tiempo que se han provocado algunos errores controlados para mostrar el comportamiento ante ellos.

Las Pruebas se han realizado en dos etapas: Carga de datos: Antes se realiza una carga de datos, para poder realizar las pruebas.

Esta carga se realiza a través de la ejecución de los procedimientos de inserción de cada una de las tablas a cargar. Con esto se consigue un doble objetivo: cargar las tablas y probar los procedimientos de inserción. Se cargan las siguientes tablas: Año Académico, Centro, Horario Atención, Profesores, Cursos, Asignaturas, Asignaturas Profesor, Calendario, Alumnos, Cursos Alumnos, Tipos de Amonestación, Tipos de Sanción, Reglas de Activación.

Ejecución de las pruebas: estas se realizan mediante la ejecución de un script, el cual realiza una serie de pruebas que se dividen en las siguientes fases: Prueba de Alta, Baja y Modificación de todas las tablas del sistema. Prueba de creación, modificación y borrado de amonestaciones y sanciones, validando que se

creen sanciones por la activación de las reglas automáticas. Consulta de la estadísticas obtenidas después de la ejecución de las pruebas anteriores. Ejecución de las funciones de Consulta. Consulta de la tabla de log.

La ejecución de las pruebas dieron los resultados esperados según los requisitos.

16


7. Conclusiones La planificación es esencial:

Contemplar vacaciones y otras ausencias. Tiempo extra para imprevistos. Tiempo suficiente para pruebas y correcciones.

Compromiso de las partes: Comunicación ágil y frecuente entre cliente y desarrollador. Ambos deben cumplir con sus tareas en su tiempo.

Importancia de la documentación: Lo único que conoce el cliente hasta la entrega.

Metodología: Imprescindible buen análisis y diseño. Detección temprana de errores. Realimentación de etapas anteriores con información de etapas siguientes.

Utilización de procedimientos almacenados: Alternativa al desarrollo de complejas funcionalidades en aplicaciones. Se asegura integridad de datos y eficiencia. Se aseguran restricciones en valores y cumplimiento de condiciones. Fácil mantenimiento.

17

trabajo de fin de carrera mariano pérez herraiz bases de datos relacionales itig consultor: manel...

Documents