Solución Taller - Bases de datos

Vista previa del material en texto

Taller 1: Diseño y desarrollo de una base de datos (v2)
Autor: Luis Carlos Berrocal Sarmiento
Tutor: Elḱın Daŕıo González Mart́ınez
Asignatura: Administración de Bases de Datos — 56617 — 22v06
Programa de Ingenieŕıa de Sistemas
Corporación Unificada Nacional de Educación Superior - CUN
Seccional Bogotá - Virtual
Marzo, 2023
1
1. Introducción
Este documento presenta de forma general, la solución para una problematica que se descrirbira en
breve. Cabe aclarar que, en este documento se muestran fragmentos de códigos, los cuales hacen parte del
lenguaje SQL y, cuando se habla del motor de bases de datos, se hace referencia a SSMS (SQL Management
Studio) de Microsoft.
2. Necesidades de información
2.1. Descripción del problema
Empezaremos por describir la situación problema para la cual se planea diseñar y desarrollar esta base
de datos.
Inicialmente partimos de que, muchos jóvenes (me incluyo) tenemos las destrezas y habilidades para practi-
car algún deporte especifico, sin embargo, en la ciudad donde vivimos no hay escuelas y/o clubes deportivos
donde podamos inscribirnos, o torneos en los cuales podamos participar o, sencillamente queremos diver-
tirnos disfrutando con otros jugadores. Entonces, a continuación, se plantea la solución al problema.
2.2. Solución del problema
La idea es crear una aplicación móvil, por medio de la cual, los jóvenes puedan organizar torneos o
simplemente poder reunirse en un partido de cualquier deporte en la ciudad donde viven.
2.3. Propuesta de la base de datos
2.3.1. Tipo de datos a almacenar
Como ya sabemos, la idea es crear una app para que se reúnan un grupo de jóvenes, en un lugar
determinado a practicar un deporte especifico. Por ende, es necesario guardar información como:
Información personal del jugador (hasta cierto punto): Esto incluye nombres, edad, donde vive, de
donde es, sexo, número de contacto.
Información de los deportes que practica: En este punto es solo anotar en que deportes es hábil el
jugador.
Información del lugar: Esta información guarda datos como para que tipo de deporte esta destinado el
lugar, tipo de suelo (si aplica), peŕımetro jugable (si aplica), condiciones del lugar, horas disponibles,
sobre si es necesario realizar reserva (y su precio, si aplica), entre otros datos.
2.3.2. Utilización de los datos
Los datos serán usados solo para fines dentro de la app, es decir, para mostrar la información a otros
jugadores, para realizar un match en un partido, entre otros casos.
2.3.3. Usuarios de la base de datos
Dado que la app es solo para jugadores, solo se establecerá el rol de Jugador. Este rol, que seŕıa nuestro
cliente final y para quien estaŕıa dirigdo (en un futuro se pueden agregar más roles).
3. Procesos de negocio
Hasta aqúı, tenemos claro lo siguiente:
La información a guardar en la base de datos.
2
Los roles que existirán en la base de datos.
Con eso claro, podemos determinar una estructura inicial de nuestra base de datos. Partiendo entonces por
el comienzo, valga la redundancia, tenemos lo siguiente:
Jugadores: Los jugadores deben tener un perfil en nuestra app con su información personal actua-
lizada e información de los deportes que practica, aśı como sus habilidades en cada uno de ellos. El
jugador puede reunirse con otros jugadores en un determinado sitio (acordado en la partida dentro
de la app) y a una hora determinada. El jugador puede pertenecer a un equipo (si aplica).
Lugar de juego: Este lugar es donde se ejecutara el encuentro. Debe tener actualizados datos,
dirección, precio (si aplica), tipo de deporte, horas disponibles. Este lugar puede ser publico (hablamos
de complejos deportivos públicos, canchas publicas, playas, entre otros) o, ser privado (hablamos de
que tiene un propietario y se debe pagar por el uso del lugar). Este lugar puede o no aceptar torneos,
y se pueden ejecutar varios encuentros en un mismo d́ıa.
4. Modelo de datos
El siguiente esquema, representa de forma general, el modelo de datos que se implementaŕıa como
solución al problema propuesto.
Figura 1: Modelo relacional: Solución del proyecto
En el anterior modelo, podemos ver las tablas que contendrá la base de datos del aplicativo. Cabe
destacar algunos puntos como:
Tablas padre: Son jugador y deporte. Contienen información del jugador y el deporte que esta
alojado en nuestra app, respectivamente. Son llamadas padre porque de ellas parten otras tablas
como deporte jugador y escenario.
Tablas hijo: Estas tablas guardan la relación entre dos tablas (no necesariamente tienen que ser
padre). Por ejemplo, la tabla deporte jugador guarda la relación entre las tablas jugador y deporte
(seŕıa el deporte que practica cada jugador) y, la tabla escenario torneo guarda la relación entre las
tablas escenario y torneo (en que escenario se jugaŕıan los torneos abiertos).
Las otras tablas (equipo, escenario y torneo) guardan la información de cada equipo, los escenarios
disponibles para cada deporte y los torneos dentro de la app, respectivamente.
3
5. Esquema de la base de datos
Se definió de manera general, el esquema de la base de datos y las tablas, acorde al modelo de datos
presentado anteriormente, aśı:
Lo primero es crear la base de datos, podemos hacerlo con la siguiente instrucción:
1 CREATE DATABASE app;
Luego procedemos a la creación de la estructura de la base de datos:
1 USE [app]
2 GO
3 CREATE TABLE jugador (
4 identificacion bigint NOT NULL PRIMARY KEY ,
5 nombre nvarchar (100) NOT NULL ,
6 apellido nvarchar (100) NOT NULL ,
7 email nvarchar (250) NOT NULL ,
8 edad nvarchar (2) NOT NULL ,
9 contacto nvarchar (10) NOT NULL ,
10 direccion nvarchar (200) NOT NULL ,
11 genero nchar (1) NOT NULL
12 );
13 GO
14 CREATE TABLE deporte (
15 id bigint NOT NULL PRIMARY KEY ,
16 nombre nvarchar (50) NOT NULL
17 );
18 GO
19 CREATE TABLE deporte_jugador (
20 id bigint NOT NULL PRIMARY KEY ,
21 jugador bigint NOT NULL ,
22 deporte bigint NOT NULL
23 );
24 GO
25 CREATE TABLE equipo (
26 id bigint NOT NULL PRIMARY KEY ,
27 nombre nvarchar (200) NOT NULL ,
28 tipoDeporte nvarchar (50) NOT NULL ,
29 deporteJugador bigint NOT NULL
30 );
31 GO
32 CREATE TABLE escenario (
33 id bigint NOT NULL PRIMARY KEY ,
34 nombre nvarchar (200) NOT NULL ,
35 privacidad nvarchar (50) NOT NULL ,
36 direccion nvarchar (250) NOT NULL ,
37 capacidad nvarchar (10) NOT NULL ,
38 precio bigint ,
39 deporte bigint NOT NULL
40 );
41 GO
42 CREATE TABLE torneo (
43 id bigint NOT NULL PRIMARY KEY ,
44 nombre nvarchar (200) NOT NULL ,
45 fechaInicio DATE NOT NULL ,
46 fechaFin DATE NOT NULL ,
47 edad nvarchar (7) NOT NULL ,
48 equipo bigint NOT NULL
49 );
50 GO
51 CREATE TABLE escenario_torneo (
52 id bigint NOT NULL PRIMARY KEY ,
53 idTorneo bigint NOT NULL ,
54 idEscenario bigint NOT NULL
55 );
El anterior código crea cada una de las tablas que necesitamos para el ejercicio, aśı como la asignación de
claves primarias en cada uno de los campos en los que es necesario.
4
6. Inserción de datos
Veamos entonces un pequeño ejemplo de algunos datos que se almacenaŕıan en nuestra base de datos.
Se aclara que estos datos son totalmente ficticios y fueron creados mediante la herramienta de generación
de datos: Mockaroo.
El siguiente fragmento de código inserta los datos de un jugador en la tabla jugador:
1 USE [app]
2 GO
3 INSERT INTO jugador (identificacion , nombre , apellido , email , edad , contacto , direccion ,
genero) VALUES (’1377257177 ’, ’Waldon ’, ’McRill ’, ’wmcrill0@quantcast.com’, 21, ’
3106811166 ’, ’216 Gale Parkway ’, ’M’);
El siguiente fragmento de código inserta los datos de un deporte en la tabla deporte:
1 USE [app]
2 GO
3 INSERT INTO deporte (id, nombre) VALUES (100, ’Futbol ’);
El siguiente fragmento de código inserta los datos del deporte que practica un jugador en la tabla depor-
te jugador:
1 USE[app]
2 GO
3 INSERT INTO deporte_jugador (id , jugador , deporte) VALUES (1, ’1377257177’, ’200’);
7. Pruebas y ajustes
En esta sección vamos a realizar algunas consultas a la base de datos mediante instrucciones en lenguaje
SQL para determinar que funciona correctamente la misma y que existe congruencia en los datos que
obtenemos.
Listar los jugadores masculinos que tengan entre 18 y 30 años, registrados en la app.
1 USE [app]
2 GO
3 SELECT * FROM jugador WHERE genero=’M’ AND (edad >= 18 AND edad <= 30)
Obtenemos lo siguiente en el motor de base de datos:
Figura 2: Resultado consulta 1
Listar los jugadores que jueguen fútbol.
1 USE [app]
2 GO
3 SELECT j.identificacion AS IDJugador , j.nombre , j.apellido , d.id AS ID_Deporte , d.
nombre AS Deporte , dp.jugador , dp.deporte AS ID_Deporte
4 FROM jugador AS j, deporte AS d, deporte_jugador AS dp
5 WHERE j.identificacion = dp.jugador AND d.id = dp.deporte AND d.nombre = ’Futbol ’
5
Obtenemos los siguientes datos en el motor:
Figura 3: Resultado consulta 2
Vamos a aclarar algo respecto a lo que muestra la consulta: En la sección de color rojo, muestra las
columnas seleccionadas en la sentencia SELECT correspondientes a la tabla jugador. La sección de
color verde, incluye los campos seleccionados de la tabla deporte y, en la ultima sección, los campos
de la tabla deporte jugador.
Listar los escenarios en los que se practica el fútbol y además, que son privados.
1 USE [app]
2 GO
3 SELECT e.nombre AS Esc_Nombre , e.privacidad , d.nombre AS Deporte
4 FROM escenario AS e, deporte AS d
5 WHERE d.nombre = ’Futbol ’ AND e.privacidad = ’Privado ’
6
Obtenemos los siguientes datos en el motor:
Figura 4: Resultado consulta 3
Listar los equipos en los que se practique el fútbol.
1 USE [app]
2 GO
3 SELECT *
6
4 FROM equipo AS e
5 WHERE e.tipoDeporte = ’Futbol ’
6
Obtenemos lo siguiente en el motor:
Figura 5: Resultado consulta 4
Listar los escenarios privados aptos para fútbol
1 USE [app]
2 GO
3 SELECT e.nombre , e.privacidad , d.nombre
4 FROM escenario AS e, deporte AS d
5 WHERE e.privacidad = ’privado ’ AND e.deporte = d.id AND d.nombre = ’Futbol ’
6
Obtenemos como resultado en el motor:
Figura 6: Resultado consulta 5
Dado los ejemplos anteriores podemos concluir que la información almacenada en la base de datos, aśı como
su estructura y la de las tablas, es correcta y concreta.
8. Documentación de la base de datos
En este punto vamos a documentar de forma general, la usabilidad de la base de datos y algo de su
estructura.
7
8.1. Información estructural de las tablas
Las tablas en general, soportan de forma nativa escritura en formato ANSII, tienen llave primaria en la
primera columna de cada una y no incluyen llaves foraneas.
8.2. Datos almacenados
Los datos almacenados en las distintas tablas se relacionan aśı:
Jugador: Guarda la información de los jugadores registrados en nuestra app.
Deporte: Guarda la información de los deportes disponibles en la app (No es modificable por el
usuario final).
Deporte Jugador: Guarda la información relacionada con el deporte que practica cada jugador.
Escenario: Guarda la información de los escenarios disponibles en la app (No es modificable por el
usuario final).
Torneo: Guarda la información de los torneos registrados en la app (Es modificable por el usuario
final).
Equipo: Guarda la información de los equipos registrados en la app (Cabe resaltar que un equipo
solo puede estar conformado por jugadores que practiquen un mismo deporte.
Escenario Deporte: Guarda la información relacionada con los lugares en los que se puede practicar
X deporte (No es modificable por el usuario final).
9. Anexos
El siguiente enlace redirige a la carpeta en Google Drive (Click aqúı) donde se encuentran todos los
códigos utilizados en este ejercicio, aśı como los modelos y las imágenes de los resultados de las consultas.
8
https://drive.google.com/drive/folders/1rmbAZorUE4S7_IasOJ33gdKtA6hMWgAL?usp=sharing
	Introducción
	Necesidades de información
	Descripción del problema
	Solución del problema
	Propuesta de la base de datos
	Tipo de datos a almacenar
	Utilización de los datos
	Usuarios de la base de datos
	Procesos de negocio
	Modelo de datos
	Esquema de la base de datos
	Inserción de datos
	Pruebas y ajustes
	Documentación de la base de datos
	Información estructural de las tablas
	Datos almacenados
	Anexos