diseño e implementación de una base de datos...
TRANSCRIPT
PROYECTO FINAL DE CARRERA
DISEÑO E IMPLEMENTACIÓN DEUNA BASE DE DATOS RELACIONAL
PARA LA GESTIÓN DE APUESTASDE FÚTBOL
LUIS ALBORS AZNARESTUDIOS: INGENIERIA
INFORMÁTICA
CONSULTOR: JUAN MARTÍNEZBOLAÑOS
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
Índice de contenidoCapitulo 1. Introducción.......................................................................................................................4
Justificación del Proyecto................................................................................................................4Objetivos..........................................................................................................................................5Método seguido................................................................................................................................5Planificación....................................................................................................................................6Productos obtenidos.......................................................................................................................14Descripción del resto de capítulos.................................................................................................14
Capitulo 2 Análisis de Requisitos.......................................................................................................15Casos de uso...................................................................................................................................15Requisitos Funcionales..................................................................................................................19Requisitos no funcionales..............................................................................................................24Análisis de procedimientos almacenados necesarios:...................................................................24Análisis del sistema operacional....................................................................................................30Análisis del data warehouse...........................................................................................................32
Capitulo 3 Diseño...............................................................................................................................35Diseño sistema operacional...........................................................................................................35Diseño sistema data warehouse.....................................................................................................42Diseño de procedimientos almacenados........................................................................................48
Capitulo 4 Implementación................................................................................................................53Implementación de la base de datos operacional...........................................................................53Implementación de la base de datos del DataWarehouse..............................................................54Implementación de procedimientos almacenados.........................................................................54
Capitulo 5 Validación.........................................................................................................................55Validación de la base de datos operacional....................................................................................55Validación de la base de datos del data warehouse........................................................................68Validación de procedimientos almacenados..................................................................................73
Valoración económica del proyecto....................................................................................................76Conclusiones.......................................................................................................................................78Glosario..............................................................................................................................................79Bibliografía.........................................................................................................................................81Anexos................................................................................................................................................81
2
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
Índice de ilustracionesTareas....................................................................................................................................................7Diagrama de Gantt..............................................................................................................................13Diagrama de Casos de Uso.................................................................................................................19Diagrama Entidades Sistema Operacional.........................................................................................31Modelo Sistema Multidimensional.....................................................................................................34Diagrama Entidad Relación Sistema Operacional..............................................................................35Diagrama Entidad Relación Sistema data warehouse........................................................................43Lista de equipos de las ligas de fútbol................................................................................................57Fichajes de los equipos.......................................................................................................................60Alineaciones de Partidos....................................................................................................................65Goles de los Jugadores.......................................................................................................................66Apuestas de Usuarios.........................................................................................................................68Caso de Prueba 6................................................................................................................................70Caso de Prueba 7................................................................................................................................72Caso de Prueba 8................................................................................................................................73Caso de Prueba 9................................................................................................................................75
Índice de tablasTabla 1: Tareas del Proyecto...............................................................................................................13Tabla 2: Caso de Uso 1.......................................................................................................................16Tabla 3: Caso de Uso 2.......................................................................................................................16Tabla 4: Caso de Uso 3.......................................................................................................................17Tabla 5: Caso de Uso 4.......................................................................................................................17Tabla 6: Caso de Uso 5.......................................................................................................................18Tabla 7: Funciones y Procedimientos Almacenados..........................................................................30Tabla 8: Entidad ALINEACIONES....................................................................................................36Tabla 9: Entidad APUESTAS.............................................................................................................37Tabla 10: Entidad EQUIPOS..............................................................................................................37Tabla 11: Entidad EQUIPOS_LIGA..................................................................................................38Tabla 12: Entidad FICHAJES.............................................................................................................38Tabla 13: Entidad GOLES..................................................................................................................39Tabla 14: Entidad JUGADORES.......................................................................................................39Tabla 15: Entidad LIGAS...................................................................................................................39Tabla 16: Entidad MODALIDADES.................................................................................................40Tabla 17: Entidad PAISES..................................................................................................................40Tabla 18: Entidad PARTIDOS............................................................................................................40Tabla 19: Entidad TEMPORADAS....................................................................................................41Tabla 20: Entidad USUARIOS...........................................................................................................41Tabla 21: Relaciones Tablas Operacional...........................................................................................42Tabla 22: Entidad APUESTAS_F.......................................................................................................44Tabla 23: Entidad USUARIOS_D......................................................................................................45Tabla 24: Entidad FECHAS_D...........................................................................................................45Tabla 25: Entidad PARAMETROS_D...............................................................................................46
3
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
Tabla 26: Entidad JORNADAS_D.....................................................................................................47Tabla 27: Entidad RANGOS_EDAD.................................................................................................47Tabla 28: Entidad GANADORA_D...................................................................................................47Tabla 29: Relaciones entre Tablas Data Warehouse...........................................................................48Tabla 30: Diseño Funciones...............................................................................................................52Tabla 31: Diseño Procedimientos Almacenados................................................................................53Tabla 32: Caso de Prueba 1................................................................................................................55Tabla 33: Resultado Caso de Prueba 1...............................................................................................56Tabla 34: Caso de Prueba 2................................................................................................................57Tabla 35: Resultado Caso de Prueba 2...............................................................................................59Tabla 36: Caso de Prueba 3................................................................................................................61Tabla 37: Resultado Caso de Prueba 3...............................................................................................64Tabla 38: Caso de Prueba 4................................................................................................................65Tabla 39: Resultados Caso de Prueba 4..............................................................................................66Tabla 40: Caso de Prueba 5................................................................................................................67Tabla 41: Resultados Caso de Prueba 5..............................................................................................67Tabla 42: Caso de Prueba 6................................................................................................................69Tabla 43: Resultados Caso Prueba 6...................................................................................................69Tabla 44: Caso de Prueba 7................................................................................................................70Tabla 45: Resultados Caso Prueba 7...................................................................................................72Tabla 46: Caso de Prueba 8................................................................................................................72Tabla 47: Resultados Caso de Preuba 8..............................................................................................73Tabla 48: Recursos Humanos.............................................................................................................76Tabla 49: Coste Jefe proyecto.............................................................................................................77Tabla 50: Coste Analista.....................................................................................................................78Tabla 51: Coste Programador.............................................................................................................78
Capitulo 1. Introducción
Justificación del Proyecto
En el desarrollo de un sistema informático (aplicativo u otro) es primordial disponer de un sistemade base de datos que almacene la información que va a ser objeto de tratamiento; los sistemas debase de datos relacionales son los mas extendidos, y mediante un buen diseño, suponen unagarantía de integridad, disponibilidad y confidencialidad en los datos.
Integridad en cuanto a que los SGBD disponen de mecanismos que evitan la duplicidad de los datoso la pérdida de consistencia
Disponibilidad en cuanto a qué disponen de mecanismos de salvaguarda de los datos y derecuperación de transacciones
4
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
Confidencialidad en cuanto a que disponen de sistemas de autenticación y autorización segurosfrente a accesos no deseados
En nuestro caso este proyecto nace de la necesidad de disponer un sistema de base de datosrelacional que almacene la información relativa a Ligas de fútbol en diferentes países, paradiferentes temporadas, con el objetivo de tener disponible información de los diferentes equipos,jugadores y resultados a lo largo de las diferentes temporadas; asímismo, se debe almacenarinformación de apuestas deportivas de diferentes tipos y de los usuarios que las realizan; el sistemaestá preparado para proporcionar un interface con un aplicativo para acceder a consultar y modificarlos datos.
Además, se ha diseñado un data warehouse que dé soporte a la elaboración de estadísticas, a partirde los mismos datos que tenemos en el sistema operacional pero organizados en un estructuramultidimensional e implementados de la misma forma en la base de datos relacional
Objetivos
A nivel de proyecto:
• Definir los requisitos que ha de proporcionar la base de datos del sistema de apuestas que sepretende desarrollar
• Definir los requisitos de información que ha de proporcionar el DataWarehouse para obtenerinformación estadística
• Desarrollar un sistema de base de datos relacional que dé soporte a la gestión de apuestas deresultados de partidos de fútbol a nivel de cualquier liga mundial de fútbol
• Desarrollar un data warehouse que dé soporte a la generación de estadísticas a nivel deapostantes, resultados de partidos de fútbol y de futbolistas
• Establecer un mecanismo de acceso a la base de datos a partir de procedimientosalmacenados
• Diseñar un sistema escalable, de manera que se pueda ampliar a otro tipo de apuestasdeportivas en la medida de lo posible
A nivel personal:
• Consolidar y ampliar los conocimientos adquiridos durante los estudios de ingenieríainformática en las materias de bases de datos y gestión de proyectos
Método seguido
5
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
La metodología que se va a seguir para el desarrollo va a ser la clásica en cascada:
• Toma de requisitos
• Análisis
• Diseño
• Implementación
• Pruebas
• Explotación
• Mantenimiento
Las fases de Implementación y pruebas serán iterativas y en menor medida las de análisis y diseño.
El motivo por el que se usa esta metodología, y no otras, como la iterativa, o ágil, es que ladefinición de los requisitos va a formar parte del propio proyecto y por lo tanto una vez fijados estosrequisitos no van a haber cambios o van a ser mínimos; el cambio en los requisitos suele ser uno delos motivos por el cual un proyecto software tiene que volver atrás en las fases de análisis y toma derequisitos, y en nuestro caso esto no se va a dar o si ocurre será en menor medida.
Las fases de explotación y mantenimiento no se planificarán en el presente proyecto, aunqueformarían parte de un proyecto real
Planificación
Para llevar a cabo el proyecto lo primero que vamos a hacer es definir una serie de hitos que nosllevarán a la entrega final del proyecto, éstos empezarán con la propia planificación, y coincidiráncon las fechas de entrega de las PAC de la asignatura y estarán basadas en la metodología seguida yexplicada en el apartado anterior; de esta forma, vamos a tener los siguientes hitos principales:
• Hito 1 : Alcance, objetivos y planificación del proyecto: PAC1
• Hito 2 : Análisis y diseño: PAC2
• Hito 3: Sistema implementado, probado y validado: PAC3
• Hito 4 : Memoria y presentación completada: Entrega final
• Hito 5: Cierre del proyecto
A partir de cada hito vamos a definir una serie de tareas junto con los recursos necesarios para
llevarlas a cabo, entendiendo los recursos como capital humano y horas de trabajo; se van a definirtres perfiles de recursos humanos Jefe del proyecto, analista y programador, no obstante, no se
6
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
consideran tareas que se puedan desarrollar en paralelo como ocurriría en un proyecto en el quedispusiéramos de recursos humanos para cada perfil.
En la siguiente tabla se explica el cometido de cada una de las tareas así como su duración:
Tarea Duración Inicio Fin Descripción
Inicio del proyecto
4 días 28/02/14 8:00 3/03/14 21:00
7
Figura 1: Tareas
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
Tarea Duración Inicio Fin Descripción
Descarga material
1 día 28/02/14 8:00 28/02/14 21:00 Descarga de todo el material necesario: enunciado de la practica,plan de estudios, y software necesario
Lectura enunciado
1 día 1/03/14 19:00 1/03/14 21:00 Primera lectura detallada del enunciado, recomendaciones delconsultor y de ejemplos de proyectos similares
Instalación software
1 día 2/03/14 19:00 2/03/14 21:00 Instalación del software necesario: Oracle 11g, LibreOffice, ProjectLibre y SQLDeveloper
Búsqueda de material
1 día 3/03/14 19:00 3/03/14 21:00 Búsqueda de material complementario como ejemplos de proyectos similares
PAC1 Plan de Trabajo
13 días 4/03/14 19:00 16/03/14 21:00
Análisis preliminar
3 días 4/03/14 19:00 6/03/14 21:00 Se realiza un análisispreliminar del alcance del proyecto
Plan de trabajo 4 días 7/03/14 19:00 10/03/14 21:00 Elaboración del presente plan de trabajo, tareas, hitos,recursos, etc.
Análisis de Riesgos
3 días 11/03/14 19:00 13/03/14 21:00 Se detectan posibles riesgos a evitar y se establecen planes de contingencia para cada uno
8
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
Tarea Duración Inicio Fin Descripción
Elaborar documentaciónPAC1
3 días 14/03/14 19:00 16/03/14 21:00 Se documenta todo el trabajo hecho hasta el momento y se elabora un documento para la PAC1
Entrega PAC1 0 días 16/03/14 19:00 16/03/14 19:00 Hito 1 : Alcance, objetivos y planificación del proyecto
PAC2 Análisis y Diseño
28 días 17/03/14 19:00 13/04/14 21:00
Toma de requisitos funcionales
4 días 17/03/14 19:00 20/03/14 21:00 Toma de los requisitos funcionales que vamos a desarrollar a lo largo del proyecto, a nivel del sistema operacional determinaremos qué información queremos obtener y a nivel del DW qué indicadores y dimensiones queremos analizar
Elaboración documento de Análisis sistema operacional
3 días 21/03/14 19:00 23/03/14 21:00 En esta tarea definiremos el modelo entidad/relación del sistema operacional y elaboraremos la documentación para la memoria del proyecto
9
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
Tarea Duración Inicio Fin Descripción
Elaboración documento de Análisis sistema DW
2 días 24/03/14 19:00 25/03/14 21:00 En esta tarea definiremos las dimensiones e indicadores y el modelo entidad/relación del DW y elaboraremos la documentación para la memoria del proyecto
Elaboración documento de Análisis procedimientosalmacenados
3 días 26/03/14 19:00 28/03/14 21:00 En esta tarea definiremos los procedimientos almacenados que vamos a implementar junto con sus entradas y sus salidas
Diseño modelode datos operacional
3 días 29/03/14 19:00 31/03/14 21:00 Diseño lógico del esquema relacional del sistema operacional y documentación del mismo
Diseño modelode datos DW
2 días 1/04/14 19:00 2/04/14 21:00 Diseño lógico del esquema relacional del DW y documentación del mismo
Diseño procedimientosalmacenados
3 días 3/04/14 19:00 5/04/14 21:00 Diseño de los procedimientos almacenados a nivel de pseudocódigo
Elaboración Documento de Diseño
3 días 6/04/14 19:00 8/04/14 21:00 Elaboramos la documentación del diseño de cara a la entrega final de la memoria
10
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
Tarea Duración Inicio Fin Descripción
Elaboración documentaciónPAC2
5 días 9/04/14 19:00 13/04/14 21:00 Elaboración de la documentación de laPAC2 con la documentación del análisis y el diseño Implementación y pruebas
Entrega PAC2 0 días 13/04/14 19:00 13/04/14 19:00 Hito 2 : Análisis y diseño completados
PAC3 28 días 14/04/14 19:00 11/05/14 21:00
Construcción de la base de datos operacional
5 días 14/04/14 19:00 18/04/14 21:00 Implementación y ejecución de sentencias SQL para el sistema operacional
Validación y pruebas base de datos operacional
3 días 19/04/14 19:00 21/04/14 21:00 Validación de la bse de datos operacional y pruebas
Construcción de la base de datos DW
4 días 22/04/14 19:00 25/04/14 21:00 Implementación y ejecución de sentencias SQL para el DW
Validación y pruebas base de datos DW
3 días 26/04/14 19:00 28/04/14 21:00 Validación de la basede datos del DW y pruebas
Implementación de procedimientosalmacenados
5 días 29/04/14 19:00 3/05/14 21:00 Implementación y ejecución de sentencias PL/SQL para los procedimientos almacenados
Validación y pruebas procedimientosalmacenados
3 días 4/05/14 19:00 6/05/14 21:00 Validación de procedimientos almacenados y pruebas
11
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
Tarea Duración Inicio Fin Descripción
Elaboración documentaciónPAC3
5 días 7/05/14 19:00 11/05/14 21:00 Elaboración de la documentación de laPAC3 con la documentación de pruebas realizadas
Entrega PAC3 0 días 11/05/14 21:00 11/05/14 21:00 Hito 3: Sistema implementado, probado y validado
Presentación 35 días 12/05/14 19:00 15/06/14 21:00
Elaboración Memoria
20 días 12/05/14 19:00 31/05/14 21:00 Recopilación de todoel trabajo realizado en la memoria del proyecto
Elaboración Presentación
5 días 1/06/14 19:00 5/06/14 21:00 Elaboración de la presentación del proyecto
Revisión Documentación
10 días 6/06/14 19:00 15/06/14 21:00 Revisión de la documentación y últimos retoques
Entrega Proyecto
0 días 15/06/14 21:00 15/06/14 21:00 Hito 4 : Memoria y presentación completada
Tribunal Virtual
3 días 25/06/14 0:00 27/06/14 21:00 Hito 5: Cierre del proyecto
12
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
Tabla 1: Tareas del Proyecto
A continuación se presenta el diagrama de Gantt:
13
Ilustración 2: Diagrama de Gantt
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
Productos obtenidos
• Base de datos operacional
• Base de datos del data warehouse
• Procesos sql de creación de base de datos operacional
• Procesos sql de creación de base de datos del data warehouse
• Procesos sql de validación de la base de datos operacional
• Procesos sql de inserción de datos en la base de datos del data warehouse
• Procesos sql de validación de la base de datos del data warehouse
• Procesos sql de creación de procedimientos almacenados
• Procesos sql de validación de procedimientos almacenados
Descripción del resto de capítulos
En el capítulo 2 analizaremos los requisitos, primeramente modelamos los casos de uso y losactores del sistema, esto nos dará una visión global de todo el sistema, posteriormente elaboramosuna lista con los requisitos funcionales y no funcionales; a partir de aquí definimos 3 subsistemas delos cuales vamos a realizar un análisis diferenciado: el sistema operacional, los procedimientosalmacenados y el data warehouse
En el capítulo 3 se realizará el diseño de cada uno de los subsistemas detectados en el análisis, elmodelo entidad relación para el sistema operacional y el data warehouse y la especificacióndetallada de cada procedimiento almacenado
En el capítulo 4 se realiza la implementación, se generan los seripts sql a aprtir de lasespecificaciones detalladas del capítulo anterior
En el capítulo 5 se realiza una validación de cada uno de los subsistemas, para el operacional serealiza una carga de datos y se ejecutan una serie de casos de prueba que consisten en en ejecutaruna serie de consultas que deben de devolver en caso de éxito unos resultados concretos; para elcaso del data warehouse ejecutamos también una carga de datos y ejecutamos consultas estadísticas.
Seguidamente se realiza una valoración económica del coste de desarrollo del proyecto atendiendoa tres perfiles de recursos humanos, Jefe de proyecto, Analista y Programador con arreglo a lashoras planificadas para cada tarea asignada a cada uno de los recursos.
Finalmente se extraen conclusiones del proyecto desarrollado
14
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
Capitulo 2 Análisis de RequisitosLos requisitos del sistema constituyen el primer paso en el desarrollo propiamente dicho del sistemaque queremos implementar, vamos a distinguir dos tipos de requisitos, los funcionales y los nofuncionales; los primeros describen funciones que el sistemas debe llevar a cabo y los segundoscaracterísticas que debe cumplir el software a desarrollar o el mismo proceso de desarrollo.
Previamente a la enumeración de los requisitos y como método de descubrimientos de los requisitosvamos a elaborar un diagrama de casos de uso del sistema
Casos de uso
Vamos a distinguir los siguientes actores que son los que interactuarán con el sistema final quevamos a desarrollar:
• Admin B.D. será el administrador de la propia base de datos a desarrollar, se encargará delas tareas de administración
• Sistema externo: representa cualquier sistema (aplicativo u otros ) que acceden al sistemapara realizar consultas en la base de datos operacional y actualizaciones de datos; este actordebe interactuar con la base de datos a través de un interface bien definido y a través de unasoperaciones definidas, en nuestro caso se implementarán a partir de procedimientosalmacenados en base de datos
• Analista: representa el usuario o sistema que hace uso del data warehouse, su función es lade ejecutar consultas contra la base de datos del data warehouse; en ningún momento puederealizar operaciones de actualización de datos ni acceder al sistema operacional
Casos de uso:
• Administrar Base de datos
15
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
Caso de Uso CU.1 Administrar base de datos
Actor Admin B.D
Descripción Proceso de administración de la base de datos
Pre-condiciones El Administrador se ha autenticado en la base de datos
Flujo 1.Usuario administrador se conecta a la base de datos
2. Realiza tareas de mantenimiento, entre ellas se incluye creación de usuarios, asignación de permisos, creación de tablespaces, ejecución y programación de backups, etc.
3.Desconexión
Tabla 2: Caso de Uso 1
• Conectar Base de datos
Caso de Uso CU.2 Conectar base de datos
Actores Admin B.D, Sistema externo, Analista
Descripción Proceso de login en la base de datos
Post-condiciones El usuario se ha autenticado en el sistema
Flujo
Tabla 3: Caso de Uso 2
• Ejecutar Procedimiento almacenado
16
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
Caso de Uso CU3 Ejecutar Procedimiento almacenado
Actor Sistema externo
Descripción Ejecución de procedimientos almacenados en base de datos
Pre-condiciones El sistema externo se ha autenticado en la base de datos
Flujo 1.Sistema externo se conecta a la base de datos
2. Se ejecuta procedimiento almacenados
3. El sistema devuelve un código de ejecución si se trata de una función o muestra datos si se trata de un procedimiento
3.Desconexión
Tabla 4: Caso de Uso 3
• Desconectar Base de datos
Caso de Uso CU4 Desconectar base de datos
Actores Admin B.D, Sistema externo, Analista
Descripción Proceso de logout en la base de datos
Post-condiciones El usuario se ha desconectado del sistema
Flujo
Tabla 5: Caso de Uso 4
• Consulta data warehouse
17
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
Caso de Uso CU5 Consulta data warehouse
Actor Analista
Descripción Ejecución de consultas en el sistema de data warehouse
Pre-condiciones El analista se ha autenticado en la base de datos
Flujo 1.Analista se conecta a la base de datos
2. Se ejecuta consulta en base de datos multidimensional
3. El sistema devuelve un conjunto de datos
3.Desconexión
Tabla 6: Caso de Uso 5
Diagrama de casos de uso:
18
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
Requisitos Funcionales
A continuación se muestran los requisitos funcionales del sistema, los requisitos estarán numeradosde manera que se pueda establecer una trazabilidad entre los mismos el diseño e implementación
RF1: La base de datos almacenará información de: equipos, ligas de diferentes países, resultados departidos, jugadores, goles que han marcado en cada partido y en qué orden
RF2: Datos históricos de forma que se pueda consultar el historial de cada jugador y de cada equipopara diferentes temporadas
RF3: Gestión de apuestas: se almacenará el usuario de la apuesta con los siguientes datos nombre yapellidos, ubicación geográfica y edad
RF4: Se almacenarán datos de las apuestas de cada usuario en un partido concreto con el importejugado y la fecha en que se realiza la apuesta; existirán las siguientes modalidades de apuesta:
• Victoria empate o derrota del primer equipo (el que juega en casa) → modalidad 1
19
Ilustración 3: Diagrama de Casos de Uso
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
• Jugador que marcará primero → modalidad 2• Resultado al final del primer tiempo → modalidad 3• Resultado al final del partido → modalidad 4
RF5: Se diseñará un data warehouse con estructura multidimensional, implementado con un modelorelacional, a partir del cual será posible extraer, al menos, las siguientes estadísticas:
• Distribución geográfica de los apostantes• Edades de los apostantes• Importe que juegan los usuarios por rangos de edades• Equipos a los que mas se apuesta a lo largo del tiempo
RF6: Se implementarán procedimientos almacenados en base de datos para el acceso a la base dedatos operacional que permitirán realizar las siguientes operaciones con los jugadores:
• Alta de jugador : se dará de alta un jugador proporcionando el nombre, el sistema le asignaráun número único que será retornado por el procedimiento
• Baja de jugador : dado un identificador se podrá realizar la baja del jugador, esta operaciónsolo se podrá realizar si el jugador no forma parte de ninguna plantilla ni esta referenciadopor ninguna otra entidad de la base de datos; el procedimiento devolverá un valor indicandosi la baja se ha realizado o no
• Actualizar jugador : dado un identificador de jugador se podrá actualizar sus datospersonales, el procedimiento devolverá un valor indicando si la actualización se ha realizadoo no ha sido posible porque no existe tal jugador
RF7: Se implementarán procedimientos almacenados en base de datos para el acceso a la base dedatos operacional que permitirán realizar las siguientes operaciones con los países:
• Alta de país : se dará de alta un país proporcionando el nombre, el sistema le asignará unnúmero único que será retornado por el procedimiento
• Baja de país: dado un identificador se podrá realizar la baja del país, esta operación solo sepodrá realizar si el país no tiene ninguna liga de fútbol asignada ni esta referenciado porninguna otra entidad de la base de datos; el procedimiento devolverá un valor indicando si labaja se ha realizado o no
• Actualizar país : dado un identificador de país se podrá actualizar su nombre , elprocedimiento devolverá un valor indicando si la actualización se ha realizado o no ha sidoposible porque no existe tal país
RF8: Se implementarán procedimientos almacenados en base de datos para el acceso a la base dedatos operacional que permitirán realizar las siguientes operaciones con las ligas de fútbol:
• Alta de liga : se dará de alta una liga proporcionando el nombre, el sistema le asignará unnúmero único que será retornado por el procedimiento
• Baja de liga : dado un identificador se podrá realizar la baja la liga de fútbol, esta operaciónsolo se podrá realizar si la liga no tiene asignados equipos, ni esta referenciado por ningunaotra entidad de la base de datos; el procedimiento devolverá un valor indicando si la baja seha realizado o no
• Actualizar liga : dado un identificador de liga se podrá actualizar sus datos, el procedimientodevolverá un valor indicando si la actualización se ha realizado o no ha sido posible porqueno existe tal liga de fútbol
20
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
RF9: Se implementarán procedimientos almacenados en base de datos para el acceso a la base dedatos operacional que permitirán realizar las siguientes operaciones con las temporadas de fútbol:
• Alta de temporada : se dará de alta una temporada proporcionando el nombre, el sistema leasignará un número único que será retornado por el procedimiento
• Baja de temporada : dado un identificador se podrá realizar la baja de la temporada, estaoperación solo se podrá realizar si no existen equipos de una liga ni partidos asignados adicha temporada ni esta referenciado por ninguna otra entidad de la base de datos; elprocedimiento devolverá un valor indicando si la baja se ha realizado o no
• Actualizar temporada : dado un identificador de temporada, se podrá actualizar sus datos, elprocedimiento devolverá un valor indicando si la actualización se ha realizado o no ha sidoposible porque no existe tal temporada
RF10: Se implementarán procedimientos almacenados en base de datos para el acceso a la base dedatos operacional que permitirán realizar las siguientes operaciones con los equipos:
• Alta de equipo: se dará de alta un equipo proporcionando el nombre, el sistema le asignaráun número único que será retornado por el procedimiento
• Baja de equipo : dado un identificador se podrá realizar la baja del equipo, esta operaciónsolo se podrá realizar si el equipo no forma parte de ninguna liga ni tiene fichajes ni estareferenciado por ninguna otra entidad de la base de datos; el procedimiento devolverá unvalor indicando si la baja se ha realizado o no
• Actualizar equipo : dado un identificador de equipo se podrá actualizar sus datos, elprocedimiento devolverá un valor indicando si la actualización se ha realizado o no ha sidoposible porque no existe tal equipo
RF11: Se implementarán procedimientos almacenados en base de datos para el acceso a la base dedatos operacional que permitirán realizar las siguientes operaciones con los equipos que formanparte de una liga de fútbol:
• Alta de equipo-liga : se dará de alta un equipo en una liga de fútbol proporcionando elidentificador del equipo, el identificador de la liga de fútbol y el identificador de latemporada, el sistema le asignará un número único que será retornado por el procedimiento
• Baja de equipo-liga : dado un identificador se podrá realizar la baja del equipo en la liga,esta operación solo se podrá realizar si el equipo en la liga y temporada, no tiene asignadospartidos ni esta referenciado por ninguna otra entidad de la base de datos; el procedimientodevolverá un valor indicando si la baja se ha realizado o no
RF12: Se implementarán procedimientos almacenados en base de datos para el acceso a la base dedatos operacional que permitirán realizar las siguientes operaciones con los fichajes de los equipos:
• Alta de fichaje : se dará de alta un fichaje proporcionando el identificador del equipo, elidentificador del jugador y la fecha de alta, el sistema le asignará un número único que seráretornado por el procedimiento
• Baja de fichaje : dado un identificador se podrá realizar la baja del fichaje• Actualizar fichaje : dado un identificador de fichaje se podrá actualizar su fecha de baja, el
procedimiento devolverá un valor indicando si la actualización se ha realizado o no ha sidoposible porque no existe tal equipo
21
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
RF13: Se implementarán procedimientos almacenados en base de datos para el acceso a la base dedatos operacional que permitirán realizar las siguientes operaciones con los partidos de una liga enuna temporada
• Alta de partido : se dará de alta un partido en una liga de fútbol proporcionando elidentificador del equipo1 (local), equipo2 (visitante), el identificador de la liga de fútbol y elidentificador de la temporada, el sistema le asignará un número único que será retornado porel procedimiento
• Baja de partido : dado un identificador se podrá realizar la baja del partido en la liga ytemporada, esta operación solo se podrá realizar si el partido en la liga y temporada, no tieneasignados alineaciones ni goles ni apuestas, ni esta referenciado por ninguna otra entidad dela base de datos; el procedimiento devolverá un valor indicando si la baja se ha realizado ono
• Actualizar partido : dado un identificador de partido se podrá actualizar sus datos, elprocedimiento devolverá un valor indicando si la actualización se ha realizado o no ha sidoposible porque no existe tal partido
RF14: Se implementarán procedimientos almacenados en base de datos para el acceso a la base dedatos operacional que permitirán realizar las siguientes operaciones con las alineaciones dejugadores en partidos de fútbol
• Alta alineación : se dará de alta un jugador de un equipo en un partido proporcionando elidentificador del equipo, el partido y el jugador, el sistema le asignará un número único queserá retornado por el procedimiento
• Baja de alineación : dado un identificador se podrá realizar la baja de la alineación, estaoperación solo se podrá realizar si el partido todavía no se ha jugado, ni esta referenciadopor ninguna otra entidad de la base de datos; el procedimiento devolverá un valor indicandosi la baja se ha realizado o no
RF15: Se implementarán procedimientos almacenados en base de datos para el acceso a la base dedatos operacional que permitirán realizar las siguientes operaciones con los goles que los jugadoresmarcan en los partidos
• Alta gol : se dará de alta un gol de un jugador en un partido proporcionando el identificadordel partido y el de jugador; para que el alta se produzca, el jugador debe formar parte de laalineación del partido; el sistema le asignará un número único que será retornado por elprocedimiento; si el alta no se produce se devolverá -1
• Baja de gol : dado un identificador se podrá realizar la baja del gol, esta operación solo sepodrá realizar si el partido todavía no ha finalizado, ni esta referenciado por ninguna otraentidad de la base de datos; el procedimiento devolverá un valor indicando si la baja se harealizado o no
RF16: Se implementarán procedimientos almacenados en base de datos para el acceso a la base dedatos operacional que permitirán realizar las siguientes operaciones con los usuarios de apuestas
• Alta usuario : se dará de alta un usuario proporcionando el nombre, la localidad y la fecha denacimiento; el sistema le asignará un número único que será retornado por el procedimiento
• Baja de usuario : dado un identificador se podrá realizar la baja de usuario, esta operaciónsolo se podrá realizar si el usuario no tiene ninguna apuesta, ni esta referenciado por ninguna
22
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
otra entidad de la base de datos; el procedimiento devolverá un valor indicando si la baja seha realizado o no
• Actualizar usuario : dado un identificador de usuario se podrá actualizar sus datos, elprocedimiento devolverá un valor indicando si la actualización se ha realizado o no ha sidoposible porque no existe tal usuario
RF17: Se implementarán procedimientos almacenados en base de datos para el acceso a la base dedatos operacional que permitirán realizar las siguientes operaciones con las modalidades deapuestas
• Alta modalidad : se dará de alta un usuario proporcionando la descripción de la modalidadde apuesta; el sistema le asignará un número único que será retornado por el procedimiento
• Baja de modalidad : dado un identificador se podrá realizar la baja de una modalidad, estaoperación solo se podrá realizar si no existe ninguna apuesta de dicha modalidad, ni estareferenciado por ninguna otra entidad de la base de datos; el procedimiento devolverá unvalor indicando si la baja se ha realizado o no
• Actualizar modalidad : dado un identificador de modalidad, se podrá actualizar sus datos, elprocedimiento devolverá un valor indicando si la actualización se ha realizado o no ha sidoposible porque no existe tal modalidad
RF18: Se implementarán procedimientos almacenados en base de datos para el acceso a la base dedatos operacional que permitirán realizar las siguientes operaciones con las apuestas
• Alta apuesta : se dará de alta un apuesta proporcionando el identificador del usuario, laidentificación de la modalidad de la apuesta y el identificador del partido al que apuesta;dependiendo del tipo de apuesta deberá proporcionar el identificador del jugador que marcaprimero o el resultado al final del primer tiempo y al final del partido; el sistema le asignaráun número único que será retornado por el procedimiento o un -1 si la alta no se produceporque faltan datos o son inconsistentes con la modalidad de apuesta.
• Baja de apuesta : dado un identificador se podrá realizar la baja de la apuesta, esta operaciónsolo se podrá realizar si el partido sobre el que se apuesta no se ha disputado aún, ni estareferenciado por ninguna otra entidad de la base de datos; el procedimiento devolverá unvalor indicando si la baja se ha realizado o no
RF19: Se implementará un procedimiento almacenado para obtener la plantilla actual de un equipo:• Obtener plantilla: se proporcionará el identificador del equipo y el sistema devolverá la lista
de jugadores con identificador del jugador, nombre y fecha en que se produjo el fichaje.
RF20: Se implementará un procedimiento almacenado para obtener la alineación de jugadores de unequipo en un partido:
• Obtener alineación: se proporcionará el identificador del equipo y el identificador delpartido; el sistema devolverá la lista de jugadores con identificador del jugador, nombre yfecha en que se produjo el fichaje.
RF21: Se implementará un procedimiento almacenado para obtener los equipos que forman parte deuna liga en una temporada:
• Obtener equipos-liga: se proporcionará el identificador de la liga, el identificador de latemporada y el sistema devolverá la lista de equipos con el nombre del equipo
23
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
RF22: Se implementará un procedimiento almacenado para obtener los goles de un jugador en unpartido:
• Obtener goles-jugador-partido: se proporcionará el identificador del jugador y del partido yel sistema devolverá cada gol marcado y el orden en el que se produjo en el partido
RF23: Se implementará un procedimiento almacenado para obtener las apuestas de un usuario en unpartido:
• Obtener apuestas-usuario: se proporcionará el identificador del usuario y el identificador delpartido y el sistema devolverá la lista de apuestas con la modalidad de la apuesta y elcontenido de la apuesta en función de la modalidad
RF24: Se implementará un procedimiento almacenado para obtener los partidos en una liga y unatemporada
• Obtener partidos-liga: se proporcionará el identificador de la liga y el identificador de latemporada, y el sistema devolverá una lista de los partidos con el nombre del equipo local yel visitante
Requisitos no funcionales
Como requisitos no funcionales vamos a tener los siguientes:
RNF1: El sistema se implementará sobre la base de datos relacional Oracle
RNF2: El acceso a la base de datos se realizará a partir de procedimientos almacenados, siendo estala única forma de acceder a los datos
RNF3: Existirá un sistema de logs para todas las acciones de la base de datos
RNF4: Se diseñarán mecanismo para testear el correcto funcionamiento de la base de datos y elcumplimiento de los requisitos funcionales
Análisis de procedimientos almacenados necesarios:
Los requisitos funcionales RF6 a RF24 implican el desarrollo de procedimientos almacenados enbase de datos, a continuación se realiza un análisis de las entradas y salidas de dichosprocedimientos a sí como de las restricciones que se deben de cumplir en los datos para elmantenimiento de la integridad de los mismos
24
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
ENTIDAD AFECTADA /REQUISITO
OPERACIÓN /PROCEDIMIENTO
ENTRADAS SALIDAS RESTRICCIONES
JUGADORESRF6
Alta Nombre del jugador
código asignado aljugador;-1 -> si no se realizó el alta
El nombre del jugador debe ser único, si se repite con otro almacenado, no serealizará el alta
Baja Código jugador 0 → baja realizada-1 → error al dar de baja
El jugador no debe formar parte de ningún fichaje, ni tener goles ni formar parte de ninguna apuesta niestar en ninguna alineación de ningún partido
Actualización Código del jugador, nombre del jugador
0 → operación realizada-1 → No se actualizó
Debe existir el código del jugador, el nombrea actualizar debe ser único
PAISESRF7
Alta Nombre del país código asignado alpaís;-1 -> si no se realizó el alta
El nombre del paísdebe ser único, si se repite con otro almacenado, no serealizará el alta
Baja Código país 0 → baja realizada-1 → error al dar de baja
El país no debe tener asignada ninguna liga de fútbol
Actualización Código país, nombre del país
0 → operación realizada-1 → No se actualizó
Debe existir el código del país, el nombre de país a actualizar debe serúnico
LIGASRF8
Alta Nombre de la liga código asignado a la liga;-1 -> si no se realizó el alta
El nombre de la liga debe ser único, si se repite con otro almacenado, no serealizará el alta
25
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
ENTIDAD AFECTADA /REQUISITO
OPERACIÓN /PROCEDIMIENTO
ENTRADAS SALIDAS RESTRICCIONES
Baja Código liga 0 → baja realizada-1 → error al dar de baja
La liga no debe tener asignada ningún equipo de fútbol
Actualización Código de la liga,Nombre de la liga
0 → operación realizada-1 → No se actualizó
Debe existir el código de la liga, el nombre de la liga a actualizar debe ser único
TEMPORADASRF9
Alta Nombre de la temporada
código asignado a la temporada;-1 -> si no se realizó el alta
El nombre de la temporada debe ser único, si se repite con otro almacenado, no serealizará el alta
Baja Código temporada 0 → baja realizada-1 → error al dar de baja
La temporada no debe tener equiposni partidos asignados
Actualización Código de la temporada,Nombre de la temporada
0 → operación realizada-1 → No se actualizó
Debe existir el código de la temporada, el nombre de la temporada a actualizar debe serúnico
EQUIPOSRF10
Alta Nombre del equipo
código asignado alequipo;-1 -> si no se realizó el alta
El nombre del equipo debe ser único, si se repite con otro almacenado, no serealizará el alta
Baja Código equipo 0 → baja realizada-1 → error al dar de baja
El equipo no debe formar parte de ninguna liga ni tener fichajes
26
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
ENTIDAD AFECTADA /REQUISITO
OPERACIÓN /PROCEDIMIENTO
ENTRADAS SALIDAS RESTRICCIONES
Actualización Código del equipo,Nombre del equipo
0 → operación realizada-1 → No se actualizó
Debe existir el código del equipo,el nombre del equipo a actualizardebe ser único
EQUIPOS-LIGARF11
Alta Código equipoCódigo ligaCódigo temporada
código asignado alequipo-liga;-1 -> si no se realizó el alta
Deben existir el código del equipo de la liga y de la temporada
Baja Código equipo-liga
0 → baja realizada-1 → error al dar de baja
El equipo-liga no debe tener partidos asignados
FICHAJESRF12
Alta Código equipoCódigo jugadorFecha alta
código asignado alfichaje;-1 -> si no se realizó el alta
Debe existir el código del equipo,del jugador y ser una fecha correcta
Baja Código fichaje 0 → baja realizada-1 → error al dar de baja
Actualización-baja Código fichajeFecha de baja
0 → operación realizada-1 → No se actualizó
La fecha de baja debe ser posterior a la fecha de alta onula
PARTIDOSRF13
Alta Código equipo1 (local), Código equipo2 (visitante) Código de la ligaCódigo temporadaFecha del partido
código asignado alpartido;-1 -> si no se realizó el alta
Debe existir el código del equipo1, equipo2, de la liga y de la temporadaLa fecha del partido debe ser única para una ligay una temporada
Baja Código partido 0 → baja realizada-1 → error al dar de baja
El partido no debetener asignados alineaciones ni goles ni apuestas
27
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
ENTIDAD AFECTADA /REQUISITO
OPERACIÓN /PROCEDIMIENTO
ENTRADAS SALIDAS RESTRICCIONES
Actualización Código partidoFecha
0 → operación realizada-1 → No se actualizó
La fecha del partido debe ser única para una ligay una temporada
ALINEACIONESRF14
Alta Código jugadorCódigo partidoCódigo equipo
código asignado a la alineación;-1 -> si no se realizó el alta
Debe de existir el código del jugador, del partido y del equipoEl equipo debe seruno de los equiposdel partido equipo1(local) equipo2 (visitante)El jugador debe deestar de alta en un fichaje del equipo
Baja Código alineación 0 → baja realizada-1 → error al dar de baja
La fecha del partido todavía no ha pasado
GOLESRF15
Alta Código jugadorCódigo partido
código asignado algol;-1 -> si no se realizó el alta
El jugador debe formar parte de la alineación del partidoEl partido no debehaberse disputado
Baja Código del gol 0 → baja realizada-1 → error al dar de baja
El partido no debehaber finalizado
USUARIOSRF16
Alta NombreLocalidadFecha de nacimiento
código asignado alusuario;-1 -> si no se realizó el alta
El nombre debe ser únicoLa localidad debe ser correcta
Baja Código usuario 0 → baja realizada-1 → error al dar de baja
El usuario no debetener apuestas
28
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
ENTIDAD AFECTADA /REQUISITO
OPERACIÓN /PROCEDIMIENTO
ENTRADAS SALIDAS RESTRICCIONES
Actualización Código usuarioNombreLocalidadFecha de nacimiento
0 → operación realizada-1 → No se actualizó
El nombre de usuario debe ser único
MODALIDADES APUESTASRF17
Alta Descripción modalidad
código asignado a la modalidad;-1 -> si no se realizó el alta
La descripción debe ser única
Baja Código modalidad 0 → baja realizada-1 → error al dar de baja
La modalidad de apuesta no debe tener apuestas definidas
Actualización Código modalidadesDescripción
0 → operación realizada-1 → No se actualizó
La descripción debe ser única
APUESTASRF18
Alta Código usuario Código modalidadCódigo partidoCódigo del jugador que marcaprimero(opcional)Resultado al final del primer tiempo (opcional)Resultado al final del partido (opcional)
código asignado a la apuesta;-1 -> si no se realizó el alta
Debe de existir el usuario, la modalidad y el partidoEl partido no debehaber finalizadoDependiendo de lamodalidad serán obligatorios unos datos
Baja Código apuesta 0 → baja realizada-1 → error al dar de baja
El partido sobre elque se apuesta no debe haber finalizado
FICHAJESRF19
Obtener-plantilla Código equipo lista jugadores
ALINEACIONESRF20
Obtener-alineación
Código equipoCódigo partido
lista jugadores
EQUIPOS-LIGARF21
Obtener-equipos-liga
Código ligaCódigo temporada
lista equipos
29
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
ENTIDAD AFECTADA /REQUISITO
OPERACIÓN /PROCEDIMIENTO
ENTRADAS SALIDAS RESTRICCIONES
GOLESRF22
Obtener-goles-jugador-partido
Código jugadorCódigo partido
lista goles
APUESTASRF23
Obtener-apuestas-usuario-partido
Código usuarioCódigo partido
lista de apuestas
PARTIDOSRF24
Obtener-partidos-liga-temporada
Código ligaCódigo temporada
lista de partidos
Tabla 7: Funciones y Procedimientos Almacenados
Análisis del sistema operacional
Primeramente vamos a definir el esquema Entidad Relacion E/R del sistema operacional:
30
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
vamos a explicar a continuación las diferentes entidades y sus relaciones:
• Jugadores: esta entidad representa a los jugadores de fútbol , cualquier persona puede formarparte de ella
• Equipos: son los equipos de fútbol , cualquier equipo de fútbol puede formar parte de estaentidad
• Países: países en los que se desarrollan las ligas de fútbol, cualquier país o continente puedeformar parte de esta entidad
• Ligas: diferentes ligas de fútbol existentes a nivel mundial, una liga de fútbol siempre estarárelacionada con una entidad país
• Temporadas: son las diferentes temporadas de fútbol, por ejemplo temporada 2013/2014
• Usuarios: son los usuarios de las apuestas, cualquier persona puede ser un usuario
31
Ilustración 4: Diagrama Entidades Sistema Operacional
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
• Modalidades: son las diferentes modalidades de apuestas que pueden existir
• Apuestas: son las diferentes apuestas, una apuesta siempre será de una modalidad concreta yserá realizada por un usuario y sobre un partido, además, puede estar relacionada(dependiendo de la modalidad) con un jugador concreto
• Equipos-Liga: son los equipos que forman parte de una liga de fútbol en una temporadaconcreta, un equipo formará parte de una liga de fútbol en una temporada concreta
• Fichajes: son los jugadores que forman o han formado parte en algún momento de un equipode fútbol, se pueden distinguir dos tipos de elementos de esta entidad, los fichajes activos,serian los jugadores que forman la plantilla de un equipo y los históricos, que serian losjugadores que formaron parte de la plantilla del equipo en algún momento anterior
• Partidos: son los partidos de fútbol, un partido siempre estará relacionado con una liga defútbol, con una temporada y con dos equipos
• Alineaciones: un elemento de esta entidad representa la alineación de un jugador de unequipo en un partido de fútbol
• Goles: son los goles que se marcan en diferentes partidos, un gol siempre habrá sidomarcado por un jugador en un partido
Análisis del data warehouse
Para modelar el sistema multidimensional vamos a seguir un proceso iterativo, primeramenteescogemos el hecho que vamos a a analizar , establecemos las dimensiones de análisis,seguidamente los atributos de dichas dimensiones y finalmente las medidas del hecho:
Escoger el hecho: la apuesta, en nuestro caso una apuesta será una transacción mediante la cual seestablece una cantidad económica para la posible ocurrencia de unas determinadas condicionesrelacionadas con partidos de fútbol y/o jugadores
Granularidad: una apuesta de un usuario un día concreto sobre un partido y con unos parámetros dela apuesta concretos, es decir un resultado final, un resultado al final de la primera parte, jugadorque marca primero o victoria, empate; si un usuario realizara un día concreto dos apuestas idénticasa nivel del DW se consideraría que es una apuesta con la suma de los importes de las dos apuestas
Dimensiones:
• usuario
• tiempo, es decir cuando se realiza la apuesta
• parámetros de la apuesta: es el contenido de la apuesta en sí misma, quien ha ganado, si hahabido empate, resultado o jugador que marca primero
• partido sobre el que se apuesta, es decir, la jornada de la liga
32
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
Atributos de las dimensiones:
• Usuario: Nombre, sexo, fecha de nacimiento, localidad
• Fecha: fecha en que se realiza la apuesta dd/mm/yyyy
• Parámetros de la apuesta: modalidad de la apuesta (victoria-empate, jugador que marcaráprimero, resultado al final del partido, resultado al final de la primera parte)
• Partido: Jornada en que se desarrolla el partido, fecha del partido y equipos involucrados
• Edad: rango de edad al que pertenece el apostante
• Ganadora: indica si la apuesta ha sido ganadora o no
Medidas:
importe: es la cantidad que se juega en cada apuesta
33
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
34
Ilustración 5: Modelo Sistema Multidimensional
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
Capitulo 3 Diseño
Diseño sistema operacional
En este apartado vamos a proceder al diseño lógico del sistema operacional, para ello a partir de lasentidades y relaciones que hemos modelado en el capítulo anterior, vamos a diseñar las tablaslógicas del sistema, vamos a definir los atributos de cada una de ellas, las restricciones y lasrelaciones entre las tablas; en nuestro caso cada entidad se va a corresponder con una tabla lógica:
Para cada tabla vamos a diseñar una clave primaria de tipo numérico, éste atributo identificará unregistro de manera unívoca en cada una de las tablas, el esquema de cada una de las tablas seexplica a continuación :
• alineaciones(id_alineacion, id_jugador, id_equipo, id_partido) : una alineación será de unjugador de un equipo en un partido
35
Ilustración 6: Diagrama Entidad Relación Sistema Operacional
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
Atributo Tipo Tipo datos No Nulo Descripción
id_alineacion Clave primaria INTEGER Clave primaria auto-generada
id_jugador Clave ajena INTEGER Clave ajena a jugadores
id_equipo Clave ajena INTEGER Clave ajena a equipos
id_partido Clave ajena INTEGER Clave ajena a partidos
Tabla 8: Entidad ALINEACIONES
• apuestas(id_apuesta,id_usuario, id_modalidad, id_partido, id_jugador, goles_local_1_parte,goles_local_2_parte, goles_visitante_1_parte, goles_visitante_2_parte, v_e_d, importe) : unaapuesta será de un usuario de una modalidad y sobre un partido, dependiendo de lamodalidad, podrá referenciar a un jugador o indicar los goles que se marcan por cada equipoo indicar si se produce victoria empate o derrota; Dependiendo del tipo de apuestatendemos:
• Modalidad 1 Victoria o empate: el campo v_e_d: debera tener un valor; id_jugadornull, goles_local_1_parte null, goles_local_2_parte null, goles_visitante_1_partenull, goles_visitante_2_parte null
• Modalidad 2 Jugador que marcará primero: id_jugador not null y resto de camposnull
• Modalidad 3 Resultado al final del primer tiempo: goles_local_1_parte not null,goles_visitante_1_parte not null y resto de campos null
• Modalidad 4 Resultado al final del partido: goles_local_2_parte not null,goles_visitante_2_parte not null y resto de campos null
36
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
Atributo Tipo Tipo datos No Nulo Descripción
id_apuesta Clave primaria
INTEGER Clave primaria auto-generada
id_usuario Clave primaria
INTEGER Clave ajena a usuarios
id_modalidad Clave ajena
INTEGER Clave ajena a modalidades
id_partido Clave ajena
INTEGER Clave ajena a partidos
id_jugador Clave ajena
INTEGER Clave ajena a jugadores
goles_local_1_parte Atributo INTEGER goles que marcará el equipo local al final de la primera parte
goles_local_2_parte Atributo INTEGER goles que marcará el equipo local al final de la segunda parte
goles_visitante_1_parte Atributo INTEGER goles que marcará el equipo visitante al final de la primera parte
goles_visitante_2_parte Atributo INTEGER goles que marcará el equipo visitante al final de la segunda parte
v_e_d Atributo CHAR(1) V: victoria equipo local, E: empate, D: derrota equipo local
importe Atributo FLOAT Importe de la apuesta
Tabla 9: Entidad APUESTAS
• equipos(id_equipo, nombre) : tabla de equipos, cada equipo posee una clave única y unnombre
Atributo Tipo Tipo datos No Nulo Descripción
id_equipo Clave primaria
INTEGER Clave primaria auto-generada
nombre Atributo CHAR(40) Nombre del equipo
Tabla 10: Entidad EQUIPOS
• equipos_liga(id_equipo_liga, id_equipo, id_liga, id_temporada): Tabla de los equipos queforman parte de una liga, un equipo estará asociado a una liga de fútbol en una temporada
37
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
Atributo Tipo Tipo datos No Nulo Descripción
id_equipo_liga Clave primaria
INTEGER Clave primaria auto-generada
id_equipo Clave ajena
INTEGER Clave ajena a equipos
id_liga Clave ajena
INTEGER Clave ajena a ligas
id_temporada Clave ajena
INTEGER Clave ajena a temporadas
Tabla 11: Entidad EQUIPOS_LIGA
• fichajes(id_fichaje, f_alta, f_baja, id_jugador, id_equipo): un fichaje es de un jugador en unequipo y a una fecha determinada, si el jugador ya no forma parte del equipo entoncestendrá una fecha de baja diferente de null
Atributo Tipo Tipo datos No Nulo Descripción
id_fichaje Clave primaria
INTEGER Clave primaria auto-generada
f_alta Atributo DATE fecha de alta del jugador en el equipo
f_baja Atributo DATE fecha de baja del jugador en el equipo
id_jugador Clave ajena
INTEGER Clave ajena a jugadores
id_equipo Clave ajena
INTEGER Clave ajena a equipos
Tabla 12: Entidad FICHAJES
• goles(id_gol, orden, id_jugador, id_partido) : un gol corresponde a un jugador en un partidoy tiene un orden dentro del partido
38
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
Atributo Tipo Tipo datos No Nulo Descripción
id_gol Clave primaria
INTEGER Clave primaria auto-generada
orden Atributo INTEGER Orden del gol en el partido
id_jugador Clave ajena
INTEGER Clave ajena a jugadores
id_partido Clave ajena
INTEGER Clave ajena a partidos
Tabla 13: Entidad GOLES
• jugadores(id_jugador, nombre) : tabla de jugadores
Atributo Tipo Tipo datos No Nulo Descripción
id_jugador Clave primaria
INTEGER Clave primaria auto-generada
nombre Atributo CHAR(40) Nombre del jugador
Tabla 14: Entidad JUGADORES
• ligas(id_liga, nombre, id_pais) : tabla de ligas, una liga de fútbol pertenece a un país
Atributo Tipo Tipo datos No Nulo Descripción
id_liga Clave primaria
INTEGER Clave primaria auto-generada
nombre Atributo CHAR(40) Nombre de la liga
id_pais Clave ajena
INTEGER Clave ajena a paises
Tabla 15: Entidad LIGAS
• modalidades(id_modalidad, descripcion) : modalidades de apuestas
39
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
Atributo Tipo Tipo datos No Nulo Descripción
id_modalidad Clave primaria
INTEGER Clave primaria auto-generada
descripcion Atributo CHAR(40) Descripción de la modalidad
Tabla 16: Entidad MODALIDADES
• paises(id_pais, nombre): tabla de países
Atributo Tipo Tipo datos No Nulo Descripción
id_pais Clave primaria
INTEGER Clave primaria auto-generada
nombre Atributo CHAR(40) Nombre del pais
Tabla 17: Entidad PAISES
• partidos(id_partido, jornada, id_temporada, id_liga, id_equipo_local, id_equipo_visitante):tabla de partidos, un partido se juega en una liga una temporada y lo conforman un equipolocal y uno visitante
Atributo Tipo Tipo datos No Nulo Descripción
id_partido Clave primaria
INTEGER Clave primaria auto-generada
jornada Atributo DATE fecha de la jornada de liga
id_temporada Clave ajena
INTEGER Clave ajena a temporadas
id_liga Clave ajena
INTEGER Clave ajena a ligas
id_equipo_local Clave ajena
INTEGER Clave ajena a equipos_liga
id_equipo_visitante Clave ajena
INTEGER Clave ajena a equipos_liga
Tabla 18: Entidad PARTIDOS
• temporadas(id_temporada, nombre): tabla de temporadas
40
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
Atributo Tipo Tipo datos No Nulo Descripción
id_temporada Clave primaria
INTEGER Clave primaria auto-generada
nombre Atributo CHAR(40) Nombre de la temporada
Tabla 19: Entidad TEMPORADAS
• usuarios(id_usuario, nombre, localidad, fecha_nacimiento): tabla de usuarios, con los datosde nombre, localidad donde reside y fecha de nacimiento
Atributo Tipo Tipo datos No Nulo Descripción
id_usuario Clave primaria
INTEGER Clave primaria auto-generada
nombre Atributo CHAR(40) Nombre del usuario
localidad Atributo CHAR(40) Localidad del usuario
fecha_nacimiento Atributo DATE Fecha de nacimiento del usuario
Tabla 20: Entidad USUARIOS
Relaciones entre tablas:
41
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
Nombre de Relación Entidad padre Entidad hija Cardinalidad
equipo-alineaciones EQUIPOS ALINEACIONES 1:N
equipo-ligas EQUIPOS EQUIPOS_LIGA 1:N
equipo-local EQUIPOS_LIGA PARTIDOS 1:N
equipo-visitante EQUIPOS_LIGA PARTIDOS 1:N
equipos-fichajes EQUIPOS FICHAJES 1:N
jugador-alineaciones JUGADORES ALINEACIONES 1:N
jugador-apuestas JUGADORES APUESTAS 1:N
jugador-goles JUGADORES GOLES 1:N
jugadores-fichajes JUGADORES FICHAJES 1:N
liga-equipos LIGAS EQUIPOS_LIGA 1:N
liga-partidos LIGAS PARTIDOS 1:N
modalidad-apuestas MODALIDADES APUESTAS 1:N
pais-ligas PAISES LIGAS 1:N
partido-alineaciones PARTIDOS ALINEACIONES 1:N
partido-apuestas PARTIDOS APUESTAS 1:N
partido-goles PARTIDOS GOLES 1:N
temporada-equipos TEMPORADAS EQUIPOS_LIGA 1:N
temporada-partidos TEMPORADAS PARTIDOS 1:N
usuario-apuestas USUARIOS APUESTAS 1:N
Tabla 21: Relaciones Tablas Operacional
Diseño sistema data warehouse
Vamos a implementar un diseño en estrella debido a su simplicidad y mayor velocidad a la hora delprocesamiento, por lo tanto se van a des-normalizar las tablas de dimensiones:
42
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
a continuación se muestra el esquema lógico de las tablas del data warehouse:
• apuestas_f (id_usuario, fecha_id, id_parametros, id_jornada, id_rango, id_ganadora,importe) : tabla de hechos, la clave primaria o base la forman el identificador de usuario, lafecha, los parámetros de la apuesta y la jornada, luego tenemos otras dimensiones que noforman parte de la base como son el rango de edad y si la apuesta es ganadora o no
43
Ilustración 7: Diagrama Entidad Relación Sistema data warehouse
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
Atributo Tipo Tipo datos No Nulo Descripción
id_usuario Clave primaria/ajena
INTEGER Clave primaria/ajena a usuarios_d
fecha_id Clave primaria/ajena
INTEGER Clave primaria/ajena a fechas_d
id_parametros Clave primaria/ajena
INTEGER Clave primaria/ajena a parametros_d
id_jornada Clave primaria/ajena
INTEGER Clave primaria/ajena a jornadas_d
id_rango Clave ajena
INTEGER Clave ajena a rangos_edad
id_ganadora Clave ajena
INTEGER Clave ajena a ganadora_d
importe Atributo FLOAT Importe de la apuesta
Tabla 22: Entidad APUESTAS_F
• usuarios_d (id_usuario, nombre, id_localidad, nombre_localidad, id_provincia,nombre_provincia, id_c_autonoma, nombre_c_autonoma) : dimensión de usuarios, estatabla engloba la jerarquía de usuario->localidad->provincia->comunidad autónoma
44
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
Atributo Tipo Tipo datos No Nulo Descripción
id_usuario Clave primaria
INTEGER Clave primaria
nombre Atributo CHAR(40) Nombre del usuario
id_localidad Atributo INTEGER Identificador de la localidad del usuario
nombre_localidad Atributo CHAR(40) Nombre de la localidad del usuario
id_provincia Atributo INTEGER Identificador de la provincia de la localidad del usuario
nombre_provincia Atributo CHAR(40) Nombre de la provincia de la localidaddel usuario
id_c_autonoma Atributo INTEGER Identificador de la comunidad autónoma de la localidad del usuario
nombre_c_autonoma Atributo CHAR(40) Nombre de la comunidad autónoma de la localidad del usuario
Tabla 23: Entidad USUARIOS_D
• fechas_d (fecha_id, fecha, semanaid, semana, mesid, mes, anyo) : dimensión de tiempo conla jerarquía fecha-> semana->mes->año
Atributo Tipo Tipo datos No Nulo Descripción
fecha_id Clave primaria
INTEGER Clave primaria
fecha Atributo DATE Fecha de la apuesta
semana_id Atributo INTEGER Identificador de la semana formato añosemana
semana Atributo INTEGER Número de la semana dentro del año
mesid Atributo INTEGER Identificador del mes formato añomes
mes Atributo CHAR(10) Nombre del mes
anyo Atributo INTEGER Año de la apuesta
Tabla 24: Entidad FECHAS_D
• parametros_d (id_parametros, id_modalidad, modalidad, id_jugador, nombre_jugador,resultado_1_parte, resultado_final, id_partido, jornada_partido) : dimensión de parametrosde la apuesta, estará compuesta por la modalidad de la apuesta el partido sobre el que se
45
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
apuesta, la jornada, y el resultado dependiendo del tipo de modalidad
Atributo Tipo Tipo datos No Nulo Descripción
id_parametros Clave primaria
INTEGER Clave primaria
id_modalidad Atributo INTEGER Identificador de la modalidad de la apuesta
modalidad Atributo CHAR(40) Nombre de la modalidad de la apuesta
id_jugador Atributo INTEGER id del jugador que marca primero
nombre_jugador Atributo CHAR(40) Nombre del jugador que marca primero
resultado_1_parte Atributo CHAR(5) Resultado al final de la primera parte en formato 2-0
resultado_final Atributo CHAR(5) Resultado al final del partido formato 2-3
id_partido Atributo INTEGER Identificador del partido sobre el que se apuesta
jornada_partido Atributo DATE Fecha en que se juega el partido
Tabla 25: Entidad PARAMETROS_D
• jornadas_d ( id_jornada, fecha_jornada, id_temporada, nombre_temporada, id_liga,nombre_liga, id_equipo_local, nombre_equipo_local,id_equipo_visitante,nombre_equipo_visitante) : dimensión de temporada con la jerarquía jornada → temporada, jornada → liga, jornada → equipo_local, jornada →equipo_visitante
46
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
Atributo Tipo Tipo datos No Nulo Descripción
id_jornada Clave primaria
INTEGER Clave primaria
fecha_jornada Atributo DATE Fecha de la jornada del partido de liga
id_temporada Atributo INTEGER Identificador de la temporada de liga
nombre_temporada Atributo CHAR(40) Nombre de la temporada de liga
id_provincia Atributo INTEGER Identificador de la provincia de la localidad del usuario
nombre_provincia Atributo CHAR(40) Nombre de la provincia de la localidaddel usuario
id_c_autonoma Atributo INTEGER Identificador de la comunidad autónoma de la localidad del usuario
nombre_c_autonoma Atributo CHAR(40) Nombre de la comunidad autónoma de la localidad del usuario
Tabla 26: Entidad JORNADAS_D
• rangos_edad (id_rango, edad_desde, edad_hasta) : dimensión de rangos de edad
Atributo Tipo Tipo datos No Nulo Descripción
id_rango Clave primaria
INTEGER Clave primaria
edad_desde Atributo INTEGER Edad de inicio del rango de edad
edad_hasta Atributo INTEGER Edad final del rango de edad
Tabla 27: Entidad RANGOS_EDAD
• ganadora_d (id_ganadora, desc_ganadora) : dimensión ganadora
Atributo Tipo Tipo datos No Nulo Descripción
id_ganadora Clave primaria
INTEGER Clave primaria
desc_ganadora Atributo CHAR(20) Descripción de ganadora
Tabla 28: Entidad GANADORA_D
Relaciones entre tablas:
47
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
Nombre de relación Entidad padre Entidad hija Cardinalidad
usuario_apuestas USUARIOS_D APUESTAS_F 1:N
fecha_apuestas FECHAS_D APUESTAS_F 1:N
parametros_apuestas PARAMETROS_D APUESTAS_F 1:N
jornada-apuestas JORNADAS_D APUESTAS_F 1:N
rango_edad_apuestas RANGOS_EDAD APUESTAS_F 1:N
ganadora_apuestas GANADORA_D APUESTAS_F 1:N
Tabla 29: Relaciones entre Tablas Data Warehouse
Diseño de procedimientos almacenados
Vamos a implementar funciones y procedimientos almacenados para llevar a cabo los requisitosRF6 a RF24, los requisitos que requieran operaciones atómicas como altas bajas, actualizaciones sevan a llevar a cabo con funciones que siempre devolverán un código en el caso de las altas será laclave primaria del elemento de la entidad afectada, y en el caso de bajas y actualizaciones será uncódigo de error o 0 en el caso de que la operación se haya llevado a cabo correctamente.
Las funciones que supongan una alteración en los datos (altas y actualizaciones) se realizarán deforma atómica y será la propia función la que lleve a cabo el COMMIT en la base de datos si losdatos son coherentes con nuestro modelo, a este efecto se contemplarán las siguientes restricciones:valores no nulos y únicos en nombres de todas las entidades
El tratamiento de excepciones se va a llevar a cabo en las propias funciones y procedimientos secapturan todas las condiciones de error, ya sea de inconsistencias de datos como de cualquier otrotipo y se devuelve un código del error, se van a definir excepciones para las siguientes condiciones:
48
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
FUNCIÓN PAR. ENTRADA SALIDA ERRORES
alta_jugador nombre_in id_jugador -1 → nombre duplicado-2 → nombre nulo-3 → nombre demasiado largo
baja_jugador id_jugador_in 0 -1 → error al borrar-2 → código jugador nulo-3 → no existe código jugador
actualizar_jugador id_jugador_innombre_in
0 -1 → nombre duplicado-2 → nombre demasiado corto-3 → nombre demasiado largo-4 → no existe código de jugador
alta_pais nombre_in id_pais -1 → nombre duplicado-2 → nombre nulo-3 → nombre demasiado largo
baja_pais id_pais_in 0 -1 → error al borrar-2 → código país nulo-3 → no existe código país
actualizar_pais id_pais_innombre_in
0 -1 → nombre duplicado-2 → nombre demasiado corto-3 → nombre demasiado largo-4 → no existe código de país
alta_liga nombre_in id_liga -1 → nombre duplicado-2 → nombre nulo-3 → nombre demasiado largo
baja_liga id_liga_in 0 -1 → error al borrar-2 → código liga nulo-3 → no existe código liga
actualizar_liga id_liga_innombre_in
0 -1 → nombre duplicado-2 → nombre demasiado corto-3 → nombre demasiado largo-4 → no existe código de liga
alta_temporada nombre_in id_temporada -1 → nombre duplicado-2 → nombre nulo-3 → nombre demasiado largo
baja_temporada id_temporada_in 0 -1 → error al borrar-2 → código temporada nulo-3 → no existe código temporada
49
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
FUNCIÓN PAR. ENTRADA SALIDA ERRORES
actualizar_temporada
id_temporada_innombre_in
0 -1 → nombre duplicado-2 → nombre demasiado corto-3 → nombre demasiado largo-4 → no existe código de temporada
alta_equipo nombre_in id_equipo -1 → nombre duplicado-2 → nombre nulo-3 → nombre demasiado largo
baja_equipo id_equipo_in 0 -1 → error al borrar-2 → código equipo nulo-3 → no existe código equipo
actualizar_equipo id_equipo_innombre_in
0 -1 → nombre duplicado-2 → nombre demasiado corto-3 → nombre demasiado largo-4 → no existe código de equipo
alta_equipo_liga id_equipo_inid_liga_inid_temporada_in
id_equipo_liga -1 → datos inconsistentes-2 → no se indica temporada-3 → no se indica liga -4 → no se indica equipo
baja_equipo_liga id_equipo_liga 0 -1 → error al borrar-2 → código equipo_liga nulo-3 → no existe código equipo_liga
alta_fichaje id_equipo_inid_jugador_inf_alta_in
id_fichaje -1 → datos inconsistentes-2 → no se indica fecha de alta-3 → no se indica jugador-4 → no se indica equipo
baja_fichaje id_fichaje_in 0 -1 → error al borrar-2 → código fichaje nulo-3 → no existe código fichaje
actualizar_fichaje id_fichaje_inf_baja_in
0 -1 → error-2 → fecha de baja anterior a fecha alta-3 → no existe código de equipo
50
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
FUNCIÓN PAR. ENTRADA SALIDA ERRORES
alta_partido jornada_inid_liga_inid_temporada_inid_equipo_liga1_inid_equipo_liga2_in
id_partido -1 → datos inconsistentes-2 → falta equipo visitante y/o local-3 → falta temporada-4 → falta liga-5 → falta fecha jornada
baja_partido id_partido_in 0 -1 → error al borrar, existen registros relacionados-2 → código partido nulo-3 → no existe código partido
actualizar_partido id_partido_injornada_in
0 -1 → error-2 → falta jornada-3 → falta partido-4 → no existe código partido
alta_alineacion id_partido_inid_jugador_inid_equipo_in
id_alineacion -1 → error datos inconsistentes-2 → falta equipo-3 → falta jugador-4 → falta partido
baja_alineacion id_alineacion_in 0 -1 → error al borrar, existen registros relacionados-2 → código alineación nulo-3 → no existe código alineación
alta_gol id_partido_inid_jugador_inorder_in
id_gol -1 → error datos inconsistentes-2 → falta orden del gol -3 → falta jugador-4 → falta partido
baja_gol id_gol_in 0 -1 → error al borrar, existen registros relacionados-2 → código golnulo-3 → no existe código gol
alta_usuario nombre_inlocalidad_infecha_in
id_usuario -1 → nombre duplicado-2 → nombre nulo-3 → nombre demasiado largo
baja_usuario id_usuario_in 0 -1 → error al borrar, existen registros relacionados-2 → código usuario nulo-3 → no existe código usuario
51
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
FUNCIÓN PAR. ENTRADA SALIDA ERRORES
actualizar_usuario id_usuario_innombre_inlocalidad_infecha_in
0 -1 → duplicado u otro error-2 → falta código usuario-3 → no existe código usuario
alta_modalidad nombre_in id_modalidad -1 → nombre duplicado-2 → nombre nulo-3 → nombre demasiado largo
baja_modalidad id_modalidad_in 0 -1 → error al borrar, existen registros relacionados-2 → código modalidad nulo-3 → no existe código modalidad
actualizar_modalidad
id_modalidad_indescripcion_in
0 -1 → error-2 → falta descripción-3 → descripción demasiado larga-4 → no existe código modalidad
alta_apuesta id_usuario_inid_modalidad_inid_partido_inid_jugador_ingoles_local_1_parte_ingoles_local_2_parte_ingoles_visitante_1_parte_ingoles_visitante_2_parte_inv_e_d_inimporte_in
id_apuesta -1 → datos inconsistentes-2 → no se indica goles 2 parte-3 → no se indica goles 1 parte-4 → no se indica jugador-5 → no se indica v_e_d-6 → no se indica importe-7 → no se indica partido-8 → no se indica modalidad-9 → no se indica usuario
baja_apuesta id_pauesta_in 0 -1 → error al borrar, existen registros relacionados-2 → código apuesta nulo-3 → no existe código apuesta
Tabla 30: Diseño Funciones
52
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
PROCEDIMIENTO PAR. ENTRADA SALIDA ERRORES
obtener_alineacion id_equipo_inid_partido_in
Lista de jugadores
ErrorNo se especificó equipo o partidoNo existe el equipo
obtener_apuestas_usuario id_usuario_inid_partido_in
Lista de apuestas
ErrorNo existe el usuario o partidoNo se especificó jugador o partido
obtener_equipos_liga id_liga_inid_temporada_in
Lista de equipos
ErrorNo existe la liga o la temporadaNo se especificó liga o temporada
obtener_goles_jugador_partido id_jugador_inid_partido_in
Lista de goles
ErrorNo existe el jugador o partidoNo se especificó jugador o partido
obtener_partidos_liga id_liga_inid_temporada_in
Lista de partidos
ErrorNo existe la liga o la temporadaNo se especificó liga o temporada
obtener_plantilla id_equipo_in Lista de jugadores
ErrorNo existe el equipoNo se especificó equipo
Tabla 31: Diseño Procedimientos Almacenados
Capitulo 4 Implementación
Implementación de la base de datos operacional
La implementación del sistema operacional se llevará a cabo en las siguientes fases:
• Creación de esquema de base de datos: el esquema será operational y lo crearemos con elusuario system (ver anexo crear_esquema_operacional.sql)
• Creación de secuencias: se van a crear secuencias para cada una de las tablas, éstas serviránpara generar las claves primarias de cada entidad:
• SEQ_ALINEACIONES
• SEQ_APUESTAS
• SEQ_EQUIPOS
• SEQ_EQUIPOS_LIGA
• SEQ_FICHAJES
• SEQ_GOLES
• SEQ_JUGADORES
53
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
• SEQ_LIGAS
• SEQ_MODALIDADES
• SEQ_PAISES
• SEQ_PARTIDOS
• SEQ_TEMPORADAS
• SEQ_USUARIOS
para crear las secuencias usaremos el script crear_secuencias.sql
• Creación de tablas: para crear las tablas usaremos el sript crear_tablas_operacional.sql
• Creación de claves primarias e índices : usaremos el script crear_indices_operacional.sql
• Crear claves ajenas: usaremos el script crear_restricciones_operacional.sql
Implementación de la base de datos del data warehouse
La implementación del data warehouse se llevará a cabo en las siguientes fases:
• Creación de esquema de base de datos del data warehouse script crear_esquema_dw.sql
• Creación de tablas script crear_tablas_dw.sql
• Creación de índices y claves primarias script crear_indices_dw.sql
• Creación de claves ajenas script crear_restricciones_dw.sql
Implementación de procedimientos almacenados
La implementación de los procedimientos y funciones almacenados se llevará a cabo en lassiguientes fases:
• Creación de funciones script crear_funciones_operacional.sql
• Creación de procedimientos script crear_procedimientos_operacional.sql
Capitulo 5 Validación
Validación de la base de datos operacional
Para la validación de la base de datos operacional vamos a realizar una serie de pruebas deintegración que nos confirmen que la información obtenida se corresponde con los requisitos, para
54
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
ello vamos a introducir en la base de datos una serie de información referente a diferentestemporadas, ligas de fútbol, equipos, jugadores, usuarios y apuestas
Los casos de prueba son los siguientes
Caso de prueba 1: Lista de equipos de las ligas
Identificador CP1
Nombre Lista de equipos de las ligas
Propósito Validar que el sistema almacena equipos en diferentes ligas de fútbol en diferentes temporadas
Salida esperada Para cada equipo se sacará una linea por cada liga de cada temporada en la que haya participado
Resultado Ok
Script cp1.sql
Tabla 32: Caso de Prueba 1
55
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
PAIS LIGA TEMPORADA EQUIPO
ESPAÑA COPA DEL REY TEMPORADA 2013-2014 ESPAÑOL
ESPAÑA COPA DEL REY TEMPORADA 2013-2014 ATLETICO DE MADRID
ESPAÑA COPA DEL REY TEMPORADA 2013-2014 SEVILLA C.F.
ESPAÑA COPA DEL REY TEMPORADA 2013-2014 F.C. BARCELONA
ESPAÑA COPA DEL REY TEMPORADA 2013-2014 REAL BETIS BALONPIÉ
ESPAÑA COPA DEL REY TEMPORADA 2013-2014 REAL MADRID
ESPAÑA COPA DEL REY TEMPORADA 2013-2014 LEVANTE U.D.
ESPAÑA COPA DEL REY TEMPORADA 2013-2014 VALENCIA C.F.
ESPAÑA LIGA NACIONAL DE FUTBOL
TEMPORADA 2013-2014 SEVILLA C.F.
ESPAÑA LIGA NACIONAL DE FUTBOL
TEMPORADA 2013-2014 REAL BETIS BALONPIÉ
ESPAÑA LIGA NACIONAL DE FUTBOL
TEMPORADA 2013-2014 LEVANTE U.D.
ESPAÑA LIGA NACIONAL DE FUTBOL
TEMPORADA 2013-2014 ATLETICO DE MADRID
ESPAÑA LIGA NACIONAL DE FUTBOL
TEMPORADA 2013-2014 REAL MADRID
ESPAÑA LIGA NACIONAL DE FUTBOL
TEMPORADA 2013-2014 F.C. BARCELONA
ESPAÑA LIGA NACIONAL DE FUTBOL
TEMPORADA 2013-2014 ESPAÑOL
ESPAÑA LIGA NACIONAL DE FUTBOL
TEMPORADA 2013-2014 VALENCIA C.F.
Tabla 33: Resultado Caso de Prueba 1
56
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
Caso de prueba 2 : fichajes de los equipos
Identificador CP2
Nombre Fichajes de los equipos
Propósito Validar que el sistema almacena los jugadores que han sido fichados
Salida esperada Sacará una lista de jugadores con el equipo al que pertenecen y su fecha de alta
Resultado Ok
Script cp2.sql
Tabla 34: Caso de Prueba 2
57
Ilustración 8: Lista de equipos de las ligas de fútbol
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
EQUIPO JUGADOR F_ALTA
VALENCIA C.F. Diego Alves 01/01/13
VALENCIA C.F. Vicente Guaita 01/01/13
VALENCIA C.F. Rúben Vezo 01/01/13
VALENCIA C.F. Philippe Senderos 01/01/13
VALENCIA C.F. Víctor Ruiz 01/01/13
VALENCIA C.F. Ricardo Costa 01/01/13
VALENCIA C.F. Jérémy Mathieu 01/01/13
VALENCIA C.F. Juan Bernat 01/01/13
VALENCIA C.F. José Gayá 01/01/13
VALENCIA C.F. João Pereira 01/01/13
VALENCIA C.F. Antonio Barragán 01/01/13
VALENCIA C.F. Oriol Romeu 01/01/13
VALENCIA C.F. Javi Fuego 01/01/13
VALENCIA C.F. Seydou Keita 01/01/13
VALENCIA C.F. Dani Parejo 01/01/13
VALENCIA C.F. Míchel 01/01/13
VALENCIA C.F. Pablo Piatti 01/01/13
VALENCIA C.F. Federico Cartabia 01/01/13
VALENCIA C.F. Sofiane Feghouli 01/01/13
VALENCIA C.F. Eduardo Vargas 01/01/13
VALENCIA C.F. Jonas 01/01/13
VALENCIA C.F. Paco Alcácer 01/01/13
VALENCIA C.F. Vinícius Araújo 01/01/13
F.C. BARCELONA MESSI 01/01/13
F.C. BARCELONA Víctor Valdés Arribas 01/01/13
F.C. BARCELONA Martín Montoya Torralbo 01/01/13
F.C. BARCELONA Gerard Piqué Bernabeu 01/01/13
F.C. BARCELONA Francesc Fàbregas Soler 01/01/13
F.C. BARCELONA Carles Puyol Saforcada 01/01/13
F.C. BARCELONA Xavier Hernández Creus 01/01/13
F.C. BARCELONA Pedro Rodríguez Ledesma 01/01/13
F.C. BARCELONA Andrés Iniesta Luján 01/01/13
58
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
F.C. BARCELONA Alexis Alejandro Sánchez 01/01/13
F.C. BARCELONA Neymar da Silva Santos Júnior 01/01/13
F.C. BARCELONA Jonathan Dos Santos Ramírez 01/01/13
F.C. BARCELONA Pinto José Manuel 01/01/13
F.C. BARCELONA Javier Alejandro Mascherano 01/01/13
F.C. BARCELONA Marc Bartra Aregall 01/01/13
F.C. BARCELONA Sergio Busquets Burgos 01/01/13
F.C. BARCELONA Alexandre Song 01/01/13
F.C. BARCELONA Jordi Alba Ramos 01/01/13
F.C. BARCELONA Ibrahim Afellay 01/01/13
F.C. BARCELONA Cristian Tello Herrera 01/01/13
F.C. BARCELONA Adriano Correia Claro 01/01/13
F.C. BARCELONA Daniel Alves da Silva 01/01/13
F.C. BARCELONA Isaac Cuenca López 01/01/13
F.C. BARCELONA Sergi Roberto Carnicer 01/01/13
F.C. BARCELONA Oier Olazábal Paredes 01/01/13
F.C. BARCELONA Gerardo Daniel Martino 01/01/13
Tabla 35: Resultado Caso de Prueba 2
59
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
Caso de prueba 3: alineaciones de los partidos
60
Ilustración 9: Fichajes de los equipos
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
Identificador CP3
Nombre Alineaciones de los partidos
Propósito Validar que el sistema almacena los jugadores alineados en cada partido
Salida esperada Sacará una lista de jugadores con el equipo al que pertenecen la jornada del partido y los equipos involucrados
Resultado Ok
Script cp3.sql
Tabla 36: Caso de Prueba 3
61
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
62
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
JORNADA PARTIDO JUGADOR EQUIPO
14/03/13 VALENCIA C.F. F.C. BARCELONA MESSIF.C. BARCELONA
14/03/13 VALENCIA C.F. F.C. BARCELONA Víctor Valdés ArribasF.C. BARCELONA
14/03/13 VALENCIA C.F. F.C. BARCELONA Martín Montoya TorralboF.C. BARCELONA
14/03/13 VALENCIA C.F. F.C. BARCELONA Gerard Piqué BernabeuF.C. BARCELONA
14/03/13 VALENCIA C.F. F.C. BARCELONA Francesc Fàbregas SolerF.C. BARCELONA
14/03/13 VALENCIA C.F. F.C. BARCELONA Carles Puyol SaforcadaF.C. BARCELONA
14/03/13 VALENCIA C.F. F.C. BARCELONA Xavier Hernández CreusF.C. BARCELONA
14/03/13 VALENCIA C.F. F.C. BARCELONA Pedro Rodríguez LedesmaF.C. BARCELONA
14/03/13 VALENCIA C.F. F.C. BARCELONA Andrés Iniesta LujánF.C. BARCELONA
14/03/13 VALENCIA C.F. F.C. BARCELONA Alexis Alejandro SánchezF.C. BARCELONA
14/03/13 VALENCIA C.F. F.C. BARCELONA Neymar da Silva Santos JúniorF.C. BARCELONA
14/03/13 VALENCIA C.F. F.C. BARCELONA Diego Alves VALENCIA C.F.14/03/13 VALENCIA C.F. F.C. BARCELONA Vicente Guaita VALENCIA C.F.14/03/13 VALENCIA C.F. F.C. BARCELONA Rúben Vezo VALENCIA C.F.14/03/13 VALENCIA C.F. F.C. BARCELONA Philippe Senderos VALENCIA C.F.14/03/13 VALENCIA C.F. F.C. BARCELONA Víctor Ruiz VALENCIA C.F.14/03/13 VALENCIA C.F. F.C. BARCELONA Ricardo Costa VALENCIA C.F.14/03/13 VALENCIA C.F. F.C. BARCELONA Jérémy Mathieu VALENCIA C.F.14/03/13 VALENCIA C.F. F.C. BARCELONA Juan Bernat VALENCIA C.F.14/03/13 VALENCIA C.F. F.C. BARCELONA José Gayá VALENCIA C.F.14/03/13 VALENCIA C.F. F.C. BARCELONA João Pereira VALENCIA C.F.14/03/13 VALENCIA C.F. F.C. BARCELONA Antonio Barragán VALENCIA C.F.
21/03/13 F.C. BARCELONA VALENCIA C.F. MESSIF.C. BARCELONA
21/03/13 F.C. BARCELONA VALENCIA C.F. Víctor Valdés ArribasF.C. BARCELONA
21/03/13 F.C. BARCELONA VALENCIA C.F. Martín Montoya TorralboF.C. BARCELONA
21/03/13 F.C. BARCELONA VALENCIA C.F. Gerard Piqué BernabeuF.C. BARCELONA
21/03/13 F.C. BARCELONA VALENCIA C.F. Francesc Fàbregas SolerF.C. BARCELONA
21/03/13 F.C. BARCELONA VALENCIA C.F. Carles Puyol SaforcadaF.C. BARCELONA
63
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
21/03/13 F.C. BARCELONA VALENCIA C.F. Xavier Hernández CreusF.C. BARCELONA
21/03/13 F.C. BARCELONA VALENCIA C.F. Pedro Rodríguez LedesmaF.C. BARCELONA
21/03/13 F.C. BARCELONA VALENCIA C.F. Andrés Iniesta LujánF.C. BARCELONA
21/03/13 F.C. BARCELONA VALENCIA C.F. Alexis Alejandro SánchezF.C. BARCELONA
21/03/13 F.C. BARCELONA VALENCIA C.F. Neymar da Silva Santos JúniorF.C. BARCELONA
21/03/13 F.C. BARCELONA VALENCIA C.F. Jonathan Dos Santos RamírezF.C. BARCELONA
21/03/13 F.C. BARCELONA VALENCIA C.F. Diego Alves VALENCIA C.F.21/03/13 F.C. BARCELONA VALENCIA C.F. Vicente Guaita VALENCIA C.F.21/03/13 F.C. BARCELONA VALENCIA C.F. Rúben Vezo VALENCIA C.F.21/03/13 F.C. BARCELONA VALENCIA C.F. Philippe Senderos VALENCIA C.F.21/03/13 F.C. BARCELONA VALENCIA C.F. Víctor Ruiz VALENCIA C.F.21/03/13 F.C. BARCELONA VALENCIA C.F. Ricardo Costa VALENCIA C.F.21/03/13 F.C. BARCELONA VALENCIA C.F. Jérémy Mathieu VALENCIA C.F.21/03/13 F.C. BARCELONA VALENCIA C.F. Juan Bernat VALENCIA C.F.21/03/13 F.C. BARCELONA VALENCIA C.F. José Gayá VALENCIA C.F.21/03/13 F.C. BARCELONA VALENCIA C.F. João Pereira VALENCIA C.F.21/03/13 F.C. BARCELONA VALENCIA C.F. Antonio Barragán VALENCIA C.F.
Tabla 37: Resultado Caso de Prueba 3
64
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
Caso de prueba 4: goles de los jugadores
Identificador CP4
Nombre Goles de los jugadores
Propósito Validar que el sistema almacena los goles que los jugadores marcan, en qué partido y en qué orden
Salida esperada Sacará una lista de con el jugador que marca el gol, el partido, la jornada y el orden del gol en el partido
Resultado Ok
Script cp4.sql
Tabla 38: Caso de Prueba 4
65
Ilustración 10: Alineaciones de Partidos
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
JORNADA PARTIDO JUGADOR GOL_NUMERO
14/03/13 VALENCIA C.F. F.C. BARCELONA
MESSI 1
14/03/13 VALENCIA C.F. F.C. BARCELONA
MESSI 2
14/03/13 VALENCIA C.F. F.C. BARCELONA
Diego Alves 3
14/03/13 VALENCIA C.F. F.C. BARCELONA
Vicente Guaita 4
14/03/13 VALENCIA C.F. F.C. BARCELONA
Rúben Vezo 5
Tabla 39: Resultados Caso de Prueba 4
66
Ilustración 11: Goles de los Jugadores
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
Caso de prueba 5: apuestas de usuarios
Identificador CP5
Nombre Apuestas de usuarios
Propósito Validar que el sistema almacena las apuestas de los usuarios con su modalidad
Salida esperada Sacará una lista de con el usuario, la modalidad de apuesta, el valor apostado, la jornada, y dependiendo de la modalidad el jugador, el resultado intermedio, el final o quien ha ganado o empatado
Resultado Ok
Script cp5.sql
Tabla 40: Caso de Prueba 5
USUARIOIMPORTE JORNADA PARTIDO RESULTADO
PEPE 20,00 € 14/03/13VALENCIA C.F. F.C. BARCELONA
MODALIDAD 1- VICTORIA EMPATE DERROTA: V
PEPE 20,00 € 14/03/13VALENCIA C.F. F.C. BARCELONA
MODALIDAD 1- VICTORIA EMPATE DERROTA: E
PEPE 20,00 € 14/03/13VALENCIA C.F. F.C. BARCELONA
MODALIDAD 2 - JUGADOR QUE MARCA PRIMERO: PEPE
PEPE 100,00 € 14/03/13VALENCIA C.F. F.C. BARCELONA
MODALIDAD 3-RESULTADO FINAL PRIM. TIEMPO: 2 - 1
PEPE 100,00 € 14/03/13VALENCIA C.F. F.C. BARCELONA
MODALIDAD 4-RESULTADO FINAL PARTIDO: 3 - 2
Tabla 41: Resultados Caso de Prueba 5
67
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
Validación de la base de datos del data warehouse
Para validar el data warehouse vamos a a seguir los siguientes pasos:
• Carga del data warehouse: esta parte la vamos a realizar insertando datos directamente en lastablas, para ello vamos a usar dos scripts:
1. Proceso para insertar datos en la tabla de tiempo FECHAS_D : se trata de unprocedimiento almacenado que inserta valores entre las fechas 01/01/2012 y31/12/2014, estos dos valores se pueden cambiar, de esta manera, se puede tener unatabla de tiempos para el intervalo de análisis en el tiempo que queramos considerar(carga_tabla_tiempo.sql)
2. Proceso que inserta valores en el resto de tablas de dimensiones y en la tabla dehechos (carga_dw.sql)
68
Ilustración 12: Apuestas de Usuarios
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
• Ejecución de consultas estadísticas que nos servirán de casos de prueba:
Caso de prueba 6: Estadística de usuarios
Identificador CP6
Nombre Estadística de usuarios
Propósito Extraer una estadística para cada usuario del número de apuestas, el importe total y medio de las mismas
Salida esperada Sacará una lista de con el usuario, el número de apuestas, el importe totaly el importe media de todas ellas
Resultado Ok
Script cp6.sql
Tabla 42: Caso de Prueba 6
ID_USUARIO NOMBRE_USUARIO
NUM_APUESTAS
SUM(IMPORTE) AVG(IMPORTE)
4 USUARIO 4 8 775 96,875
1 USUARIO 1 5 414 82,8
3 USUARIO 3 10 288 28,8
2 USUARIO 2 8 218 27,25
Tabla 43: Resultados Caso Prueba 6
69
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
Caso de prueba 7: Estadística de modalidades de apuestas
Identificador CP7
Nombre Estadística de modalidades de apuestas
Propósito Extraer una estadística para cada modalidad de apuesta del número de apuestas, el importe total y medio de las mismas
Salida esperada Sacará una lista de con la modalidad, el número de apuestas, el importe total y el importe medio de todas ellas
Resultado Ok
Script cp7.sql
Tabla 44: Caso de Prueba 7
70
Ilustración 13: Caso de Prueba 6
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
MODALIDAD RESULTADO_APUESTA
NUM_APUESTAS
SUM(IMPORTE)
AVG(IMPORTE)
MODALIDAD 1- VICTOIA EMPATE DERROTA
D 4 96 24
MODALIDAD 1- VICTOIA EMPATE DERROTA
E 4 156 39
MODALIDAD 1- VICTOIA EMPATE DERROTA
V 3 463 154,3333333
MODALIDAD 2-Jugador que marcará primero
Leo Messi
3 340 113,3333333
MODALIDAD 2-Jugador que marcará primero
Paco Alcacer
2 47 23,5
MODALIDAD 3- Resultado al final 1 parte
2-1 4 222 55,5
MODALIDAD 3- Resultado al final 1 parte
3-1 3 164 54,66666667
MODALIDAD 4- Resultado al final partido
0-2 4 121 30,25
MODALIDAD 4- Resultado al final partido
3-2 4 86 21,5
71
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
Tabla 45: Resultados Caso Prueba 7
Caso de prueba 8: Estadística de partidos
Identificador CP8
Nombre Estadística de partidos
Propósito Extraer una estadística para cada partido de fútbol del número de apuestas, el importe total y medio de las mismas
Salida esperada Sacará una lista de con la jornada, los equipos del parido y el número de apuestas, el importe total y el importe medio de todas ellas
Resultado Ok
Script cp8.sql
Tabla 46: Caso de Prueba 8
72
Ilustración 14: Caso de Prueba 7
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
FECHA_JORNADA
PARTIDO NUM_APUESTAS
SUM(IMPORTE) AVG(IMPORTE)
01/01/13 VALENCIA C.F.-F.C.BARCELONA
14 713 50,92857143
08/01/13 F.C.BARCELONA-VALENCIA C.F.
17 982 57,76470588
Tabla 47: Resultados Caso de Preuba 8
Validación de procedimientos almacenados
Para validar los procedimientos almacenados vamos a crear un procedimiento almacenado que utilizando las funciones creadas, dé de alta registros en las tablas creadas y luego los borre:
73
Ilustración 15: Caso de Prueba 8
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
Caso de Prueba 9: Ejecución de Funciones
74
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
Identificador CP9
Nombre Ejecución de Funciones
Propósito Comprobar que ejecutando las funciones creadas se pueden dar de alta y posteriormente borrar registros en todas las tablas creadas
Salida esperada Sacará una lista con los identificadores de los registros creados y luego un cero por cada registro indicando que se ha borrado
Resultado Ok
Script cp9.sql
75
Ilustración 16: Caso de Prueba 9
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
Valoración económica del proyectoDe acuerdo con la planificación efectuada, vamos a considerar tres perfiles: Jefe de Proyecto,Analista y Programador, cada uno encargado de una serie de tareas, y con un coste/horadeterminado, el horario de trabajo será de 19.00 a 21:00 y se podrá trabajar todos los días
Tipo de recurso Días asignado Horas pordía
Totalhoras
Coste hora Coste total
Jefe de Proyecto 58 2 116 50 € 5800 €
Analista 28 2 56 45 € 2520 €
Programador 15 2 30 40 € 1200 €
Tabla 48: Recursos Humanos
76
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
Jefe de Proyecto
Tarea Horas Trabajo Inicio Terminado
Búsqueda de material 2 3/03/14 19:00 3/03/14 21:00
Entrega PAC2 0 13/04/14 21:00 13/04/14 21:00
Tribunal Virtual 6 25/06/2014 19:00 27/06/14 21:00
Elaborar documentación PAC1 6 14/03/14 19:00 16/03/14 21:00
Descarga material 2 28/02/14 19:00 28/02/14 21:00
Elaboración documentación 10 7/05/14 19:00 11/05/14 21:00
Toma de requisitos funcionales 8 17/03/14 19:00 20/03/14 21:00
Plan de trabajo 8 7/03/14 19:00 10/03/14 21:00
Entrega Proyecto 0 15/06/14 21:00 15/06/14 21:00
Entrega PAC1 0 16/03/14 21:00 16/03/14 21:00
Análisis preliminar 6 4/03/14 19:00 6/03/14 21:00
Entrega PAC3 0 11/05/14 21:00 11/05/14 21:00
Elaboración documentación 10 9/04/14 19:00 13/04/14 21:00
Elaboración Memoria 40 12/05/14 19:00 31/05/14 21:00
Elaboración Presentación 10 1/06/14 19:00 5/06/14 21:00
Análisis de Riesgos 6 11/03/14 19:00 13/03/14 21:00
Lectura enunciado 2 1/03/14 19:00 1/03/14 21:00
Total: 116
Coste hora Jefe Proyecto 50 €
Total coste Jefe Proyecto 5800 €
Tabla 49: Coste Jefe proyecto
77
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
Analista
Tarea Horas Trabajo Inicio Terminado
Elaboración documento de 4 24/03/14 19:00 25/03/14 21:00
Elaboración documento de 6 21/03/14 19:00 23/03/14 21:00
Diseño modelo de datos DW 4 1/04/14 19:00 2/04/14 21:00
Validación y pruebas 6 4/05/14 19:00 6/05/14 21:00
Elaboración documento de 6 26/03/14 19:00 28/03/14 21:00
Diseño modelo de datos 6 29/03/14 19:00 31/03/14 21:00
Diseño procedimientos 6 3/04/14 19:00 5/04/14 21:00
Validación y pruebas base de 6 26/04/14 19:00 28/04/14 21:00
Validación y pruebas base de 6 19/04/14 19:00 21/04/14 21:00
Elaboración Documento de 6 6/04/14 19:00 8/04/14 21:00
Total: 56
Coste hora Analista 45 €
Total coste Analista 2520 €
Tabla 50: Coste Analista
Programador
Tarea Horas Trabajo Inicio Terminado
Construcción de la base de datos 8 22/04/14 19:00 25/04/14 21:00
Construcción de la base de datos 10 14/04/14 19:00 18/04/14 21:00
Instalación software 2 2/03/14 19:00 2/03/14 21:00
Implementación de 10 29/04/14 19:00 3/05/14 21:00
Total: 30
Coste hora Programador 40 €
Total coste programador 1200 €
Tabla 51: Coste Programador
ConclusionesEl desarrollo de un proyecto software requiere una toma de requisitos y planificación adecuadas, ennuestro caso, hemos llevado a cabo un proyecto de desarrollo de un sistema de base de datosrelacional, con unos requisitos claros y concretos, la planificación estimada ha podido llevarse acabo con algunas desviaciones debidas principalmente a circunstancias personales, difíciles de
78
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
evitar; por mi experiencia personal, en un proyecto real los requisitos suelen cambiar a lo largo delproyecto, lo cual provoca que las fases de análisis y diseño tengan que ser iterativas. y que laestimación de plazos no pueda ser todo lo precisa que seria deseable.
La planificación se ha llevado a cabo siguiendo el ciclo de vida en cascada, se han definido los hitosy a partir de ellos se han definido las tareas para llevarlos a cabo y se han asignado recursos a éstastareas, en nuestro caso recursos humanos y tiempo.
En la fase de análisis se han definido unos requisitos y se han elaborado diagramas y modelos quehan servido para en la fase de diseño, desarrollar los modelos entidad-relación y lasespecificaciones de entradas y salidas de los procedimientos y funciones, a partir de los cuales laimplementación solo supone una traducción a sql de las estructuras de datos y el desarrollo en PL-SQL de dichos procedimientos y funciones.
El sistema es fácilmente ampliable en el sentido de incorporar nuevos atributos referentes a algunasentidades, e incluso para otros deportes de equipo añadiendo nuevas entidades y relaciones sinafectar a los datos que pudieran existir y añadiendo nuevos procedimientos almacenados paraacceder a la nueva información
En cuanto al sistema de data warehouse, se ha implementado un sistema básico con muy pocastablas pero que cumple con los requisitos planteados y que puede ser ampliado con nuevasdimensiones de análisis o atributos que en el futuro se pudieran requerir;
Personalmente el proyecto me ha servido para ahondar en algunos de los ámbitos en los quedesarrollo mi trabajo diario, como es el desarrollo de bases de datos Oracle, el diseño de procesosde extracción de datos o el diseño de sistemas multidimensionales, y para adquirir conocimientos enprogramación en PL-SQL
Glosario
• Diagrama de Gantt: herramienta gráfica cuyo objetivo es exponer el tiempo de dedicaciónprevisto para diferentes tareas o actividades a lo largo de un tiempo total determinado. Apesar de esto, el diagrama de Gantt no indica las relaciones existentes entre actividades.
• SGBD: Sistema de Gestión de Bases de Datos
• E/R: Entity Relationship (entidad relación)
• Modelo relacional: es un modelo de datos basado en la lógica de predicados y en la teoría deconjuntos. Es el modelo más utilizado en la actualidad para modelar problemas reales yadministrar datos dinámicamente. fue postulado en 1970 por Edgar Frank Codd
• Metodología de desarrollo ágil: métodos de ingeniería del software basados en el desarrolloiterativo e incremental, donde los requisitos y soluciones evolucionan mediante lacolaboración de grupos auto organizados y multidisciplinarios. Existen muchos métodos dedesarrollo ágil; la mayoría minimiza riesgos desarrollando software en lapsos cortos.
• Trazabilidad: en el ámbito del desarrollo del software y concretamente en la gestión de
79
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
requisitos se refiere a la habilidad de seguir el ciclo de un requerimiento en las siguientesfases de análisis y desarrollo
• Pseudocódigo: es una descripción de alto nivel compacta e informal del principio operativode un programa informático u otro algoritmo.
• script: programa usualmente simple, que por lo regular se almacena en un archivo de textoplano, un script sql es un script que contiene sentencias sql
• SQL: en inglés Structured Query Language, lenguaje de consulta estructurado es unlenguaje declarativo de acceso a bases de datos relacionales que permite especificar diversostipos de operaciones en ellas. Una de sus características es el manejo del álgebra y el cálculorelacional que permiten efectuar consultas con el fin de recuperar de forma sencillainformación de interés de bases de datos, así como hacer cambios en ellas.
• PL-SQL: (Procedural Language/Structured Query Language) es un lenguaje deprogramación incrustado en Oracle.
•
• PL/SQL soportara todas las consultas, ya que la manipulación de datos que se usa es lamisma que en SQL, incluyendo nuevas características: el manejo de variables, estructurasmodulares, estructuras de control de flujo y control de excepciones.
• tablespace : una unidad lógica de almacenamiento dentro de una base de datos oracle.
• Clave primaria: campo o a una combinación de campos que identifica de forma única a cadafila de una tabla. Una clave primaria comprende de esta manera una columna o conjunto decolumnas. No puede haber dos filas en una tabla que tengan la misma clave primaria.
• Clave ajena: limitación referencial entre dos tablas. La clave ajena identifica una columna ogrupo de columnas en una tabla (tabla hija) que se refiere a una columna o grupo decolumnas en otra tabla (tabla maestra). Las columnas en la tabla hija deben ser la claveprimaria u otra clave candidata en la tabla maestra.
• Cardinalidad : la forma en que se relacionan las Entidades, o expresa cuantas entidades serelacionan con otras entidades.
• data warehouse: una colección de datos orientada a un determinado ámbito (empresa,organización, etc.), integrado, no volátil y variable en el tiempo, que ayuda a la toma dedecisiones en el ámbito en el que se utiliza.
• sistema multidimensional: se utilizan principalmente para crear aplicaciones OLAP ypueden verse como bases de datos de una sola tabla, su peculiaridad es que por cadadimensión tienen un campo (o columna), y otro campo por cada métrica o hecho, es decirestas tablas almacenan registros cuyos campos son de la forma:
{(d_1, d_2, d_3, ..., f_1, f_2, f_3, ...)}
donde los campos '{d_i}' hacen referencia a las dimensiones de la tabla, y los campos '{f_i}'a las métricas o hechos que se quiere almacenar, estudiar o analizar
• OLAP: es el acrónimo en inglés de procesamiento analítico en línea (On-Line AnalyticalProcessing). Es una solución utilizada en el campo de la llamada Inteligencia empresarial (oBusiness Intelligence) cuyo objetivo es agilizar la consulta de grandes cantidades de datos.
80
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
Para ello utiliza estructuras multidimensionales (o Cubos OLAP) que contienen datosresumidos de grandes Bases de datos
• tabla de hechos: tabla central de un esquema dimensional (en estrella o en copo de nieve) ycontiene los valores de las medidas de negocio o dicho de otra forma los indicadores denegocio.
• tabla de dimensión: tabla que contienen atributos (o campos) que se utilizan para restringir yagrupar los datos almacenados en una tabla de hechos cuando se realizan consultas sobredicho datos en un entorno de data warehouse
• Granularidad: especificidad a la que se define un nivel de detalle en una tabla, es decir, sihablamos de una jerarquía la granularidad empieza por la parte más alta de la jerarquía,siendo la granularidad mínima, el nivel más bajo.
Bibliografía• http://www.techonthenet.com/oracle/
• http://plsql-tutorial.com/
• http://www.tutorialspoint.com/plsql/index.htm
• http://www.oracle.com/technetwork/database/index.html
• http://es.wikipedia.org/wiki/Metodolog%C3%ADa_de_desarrollo_de_software
• http://es.wikipedia.org/wiki/Base_de_datos_multidimensional
• http://www.businessintelligence.info/
• http://mundodb.es/diseno-data-warehouse-hechos-y-dimensiones-modelo-estrella-vs-copo-de-nieve
• http://es.wikipedia.org/wiki/Esquema_en_estrella
AnexosCreación de estructuras de datos:
• crear_tablas_operacional.sql
• crear_tablas_dw.sql
• crear_secuencias.sql
• crear_restricciones_operacional.sql
• crear_restricciones_dw.sql
• crear_indices_operacional.sql
• crear_indices_dw.sql
81
Diseño e implementación de una base de datos relacional para la gestión de apuestas deportivas
Consultor: Juan Martínez BolañosLuis Albors Aznar
Creación de Procedimientos y Funciones
• crear_funciones_operacional.sql
• crear_procedimientos_operacional.sql
Carga de datos
• carga_tabla_tiempo.sql
• carga_dw.sql
• borrar_dw.sql
Casos de prueba
• cp1.sql
• cp2.sql
• cp3.sql
• cp4.sql
• cp5.sql
• cp6.sql
• cp7.sql
• cp8.sql
• cp9.sql
82