Trabajo Práctico: Bases de Datos I
UNGS – Primer Semestre 2025
1 Modelo de Datos
A continuación se presenta el modelo de datos que se utiliza para almacenar información relativa
a la reserva y la compra de entradas, que les clientes realicen para el complejo de salas de cine
Jardines de Noviembre.
cliente(
id_cliente: int,
nombre: text,
apellido: text,
dni: int,
fecha_nacimiento: date,
telefono: char(12),
email: text --válido
)
sala_cine(
id_sala: int,
nombre: text,
formato: char(10), --`2d', `3d', `4d'
nro_filas: int,
nro_butacas_por_fila: int,
capacidad_total: int --filas por butacas_por_fila
)
pelicula(
id_pelicula: int,
titulo: text,
duracion: interval,
director: varchar(40),
origen: varchar(60), --país/es que la produjo
formato: char(10) --`2d', `3d', `4d'
)
funcion(
id_funcion: int,
id_sala: int,
fecha_inicio: date,
hora_inicio: time,
fecha_fin: date, --considerar duración de la película
hora_fin: time, --considerar duración de la película
id_pelicula: int,
butacas_disponibles: int
)
butaca_por_funcion(
id_funcion: int,
nro_fila: int, --entre 1 y sala_de_cine.nro_filas
nro_butaca: int, --entre 1 y sala_de_cine.nro_butacas_por_fila
id_cliente: int,
estado: char(15) --`reservada', `comprada', `anulada'
)
error(
id_error: int,
operacion: char(20),
--`nueva funcion', `reserva butaca', `compra butaca', `anulacion reserva'
id_sala: int,
f_inicio_funcion: timestamp, --fecha y hora de inicio de la función
id_pelicula: int,
id_funcion: int,
nro_fila: int,
nro_butaca: int,
id_cliente: int,
f_error: timestamp,
motivo: varchar(80)
)
envio_email(
id_email: int,
f_generacion: timestamp,
email_cliente: text,
asunto: text,
cuerpo: text,
f_envio: timestamp,
estado: char(10) --`pendiente', `enviado'
)
-- Esta tabla *no* es parte del modelo de datos, pero se incluye para
-- poder probar la funcionalidad del sistema.
´datos_de_prueba(
id_orden: int, --en qué orden se ejecutarán las transacciones
operacion:char(20),
--`nueva funcion', `reserva butaca', `compra butaca', `anulacion reserva'
id_sala: int,
f_inicio_funcion: timestamp, --fecha y hora de inicio de la función
id_pelicula: int,
id_funcion: int,
nro_fila: int,
nro_butaca: int,
id_cliente: int
)
El sistema debe administrar el calendario de las proyecciones de películas en las salas del complejo,
así como la reserva y la compra de entradas para las diferentes funciones, y mantener toda la
información de les clientes, de las salas de cine y de las películas que se proyectan en ellas.
Además, les clientes deben ser informades vía email cuando se confirmen las acciones de reserva,
compra o anulación de sus entradas.
2 Creación de la Base de Datos
La base de datos deberá nombrarse con el apellido de cada integrante del equipo en orden alfabético,
separados con underscores, y seguidos del string _db1, por ejemplo:
giunta_maradona_palermo_riquelme_db1
No respetar esto, automáticamente implica la desaprobación del trabajo práctico.
Se deberán crear las tablas respetando exactamente los nombres de tablas, atributos, y tipos de
datos especificados.
Se deberán agregar las PK’s y FK’s de todas las tablas, por separado de la creación de las mismas.
Además, se deberá tener la posibilidad de borrar todas las PK’s y FK’s.
3 Instancia de los Datos
Los datos de les clientes, de las salas de cine y de las películas, así como los datos de entrada para las
transacciones de prueba, deberán cargarse en las tablas correspondientes a partir de los siguientes
documentos JSON:
• [Link]
• salas_de_cine.json
• [Link]
• datos_de_prueba.json
Estos archivos json se encuentran en el directorio compartido de Google Drive de la materia, junto
a este archivo pdf.
4 Stored Procedures y Triggers
El trabajo práctico deberá incluir los siguientes stored procedures ó triggers:
• apertura de función: se deberá proveer la lógica que dé por abierta la venta y la reserva de
entradas para una función. Se debe recibir un id de sala, una fecha y hora de inicio, y un id de
película, y retornar el id de función si se logró confirmar la apertura, ó -1 en caso contrario.
El procedimiento deberá validar los siguientes elementos antes de confirmar la apertura de la
función:
– Que el id de sala exista. En caso de que no se cumpla, se debe cargar un error con el mensaje
?id de sala no válido.
– Que el id de película exista. En caso de que no se cumpla, se debe cargar un error con el
mensaje ?id de película no válido.
– Que la fecha y hora de inicio sea posterior a la hora actual. En caso de que no se cumpla,
se debe cargar un error con el mensaje ?no se permite abrir una nueva función con
retroactividad.
– Que la función que se intenta abrir no se superponga en el tiempo con otra función que ya
haya sido abierta previamente en la misma sala. En caso de que no se cumpla, se debe cargar
un error con el mensaje ?no se permite solapar funciones en una sala.
– Que el formato de la sala coincida con el formato de la película. En caso de que no se
cumpla, se debe cargar un error con el mensaje ?sala no habilitada para el formato
de la película.
Si las validaciones pasan correctamente, se deberá insertar un registro en la tabla funcion con
los datos recibidos, tomando la cantidad de butacas disponibles de la capacidad total de la sala.
Calcular y grabar la fecha y hora de fin de la función, a partir de la fecha y hora de inicio, y de
la duración de la película.
• reserva de butaca: se deberá proveer la lógica que permita reservar una butaca de una función
para une cliente. Se debe recibir un id de función, un id de cliente, un número de fila y un
número de butaca, y retornar true si se logra marcar la butaca como reservada, ó false en
caso contrario. El procedimiento deberá validar los siguientes elementos antes de confirmar la
reserva:
– Que el id de función exista. En caso de que no se cumpla, se debe cargar un error con el
mensaje ?id de función no válido.
– Que tanto el número de fila como el número de butaca se encuentren dentro del rango válido
para la sala asignada a la función. En caso de que no se cumpla, se debe cargar un error con
el mensaje ?no existe número de fila ó butaca.
– Que la función tenga butacas disponibles. En caso de que no se cumpla, se debe cargar un
error con el mensaje ?sala completa para la función.
– Que el número de fila y butaca no esté reservada ó comprada. En caso de que no se cumpla,
se debe cargar un error con el mensaje ?butaca no disponible para la función.
Si las validaciones pasan correctamente, se deberá insertar un registro con los valores recibidos
en la tabla butaca_por_funcion (o actualizarlo, si existía previamente con el estado anulada),
grabando el estado como reservada.
Además, se deberá restar una de las butacas disponibles del registro correspondiente en la tabla
funcion.
• compra de butaca: se deberá incluir la lógica que permita marcar una butaca de una función
como comprada por une cliente. El lugar en la butaca puede comprarse directamente, o también
haber sido reservado con anterioridad por le misme cliente. Se debe recibir un id de función, un
id de cliente, un número de fila y un número de butaca, y retornar true si se logra marcar la
butaca como comprada, ó false en caso contrario. El procedimiento deberá validar los siguientes
elementos antes de confirmar la compra:
– Que el id de función exista. En caso de que no se cumpla, se debe cargar un error con el
mensaje ?id de función no válido.
– Que tanto el número de fila como el número de butaca se encuentren dentro del rango válido
para la sala asignada a la función. En caso de que no se cumpla, se debe cargar un error con
el mensaje ?no existe número de fila ó butaca.
– Que el número de fila y butaca no esté ya reservada ó comprada por otre cliente. En caso
de que no se cumpla, se debe cargar un error con el mensaje ?butaca ocupada por otre
cliente.
Si las validaciones pasan correctamente, se deberá insertar un registro con los valores recibidos en
la tabla butaca_por_funcion (o actualizarlo, si ya existía previamente con el estado reservada
por le misme cliente, ó con el estado anulada sin importar le cliente), grabando el estado como
comprada.
Además, sólo en el caso de que la butaca no estuviera reservada previamente, se deberá restar
una de las butacas disponibles del registro correspondiente en la tabla funcion.
• anulación de reserva: (opcional) se deberá incluir la lógica que permita anular la reserva de
una butaca. Se debe recibir un id de función, un id de cliente, un número de fila y un número de
butaca, y retornar true si se logra marcar la butaca como anulada, ó false en caso contrario.
El procedimiento deberá validar los siguientes elementos antes de confirmar la anulación:
– Que el id de función exista. En caso de que no se cumpla, se debe cargar un error con el
mensaje ?id de función no válido.
– Que tanto el número de fila como el número de butaca se encuentren dentro del rango válido
para la sala asignada a la función. En caso de que no se cumpla, se debe cargar un error con
el mensaje ?no existe número de fila ó butaca.
– Que el número de fila y butaca esté reservada por le cliente recibide por parámetro. En
caso de que no se cumpla, se debe cargar un error con el mensaje ?butaca no reservada
por le cliente.
Si las validaciones pasan correctamente, se deberá actualizar el registro correspondiente de la
tabla butaca_por_funcion, grabando el estado como anulada.
Además, se deberá incrementar las butacas disponibles del registro correspondiente en la tabla
funcion.
• envío de emails a clientes: el trabajo práctico deberá proveer la funcionalidad de generar
emails para ser enviados a la dirección de email de le cliente—en la tabla envio_emails—cuando
sucedan las siguientes novedades:
– Cada vez que se confirme la reserva de una butaca, se debe ingresar automáticamente un
email con el asunto ‘Jardines de Noviembre - reserva de butaca’, informando en el
cuerpo del email los datos de le cliente y los datos importantes de la reserva—nombre de la
sala, título y formato de la película, fecha y hora de inicio de la función, número de fila y
número de butaca.
– Cada vez que se confirme la compra de una butaca, se debe ingresar automáticamente
un email con el asunto ‘Jardines de Noviembre - compra de butaca’, informando en el
cuerpo del email los datos de le cliente y los datos importantes de la compra—nombre de la
sala, título y formato de la película, fecha y hora de inicio de la función, número de fila y
número de butaca.
– (opcional) Cada vez que se confirme la anulación de una reserva, se debe ingresar auto-
máticamente un email con el asunto ‘Jardines de Noviembre - anulación de reserva’,
informando en el cuerpo del email los datos de le cliente y los datos importantes de la
anulación—nombre de la sala, título y formato de la película, fecha y hora de inicio de la
función, número de fila y número de butaca.
Se deberá crear una tabla con datos de entrada de las operaciones para poder probar la funcio-
nalidad del sistema, que deberá contener los siguientes atributos: id_orden, operacion, id_sala,
f_inicio_funcion, id_pelicula, id_funcion, nro_fila, nro_butaca, id_cliente.
A partir de esta tabla, se deberá hacer un procedimiento de testeo que invoque a las transacciones
correspondientes de acuerdo a la operación. Los datos para realizar dichas pruebas, deberán tomarse
del archivo datos_de_prueba.json provisto en el directorio compartido de Google Drive.
5 JSON y Bases de datos NoSQL
Por último, para poder comparar el modelo relacional con un modelo no relacional NoSQL, se pide
guardar los datos de clientes, salas de cine, películas, funciones (al menos tres) y butacas compradas
(al menos cinco) en una base de datos NoSQL basada en JSON. Para ello, utilizar la base de datos
BoltDB.
6 Aplicación Solicitada
Todo el código SQL escrito para este trabajo práctico, deberá ejecutarse desde una aplicación
simple command line escrita en Go.
A modo de ejemplo:
$ go run .
### Menú ###
1 Crear base de datos
2 Crear tablas
3 Agregar PKs y FKs
4 Eliminar PKs y FKs
5 Cargar datos
6 Crear stored procedures y triggers
7 Iniciar pruebas
8 Cargar datos en BoltDB
0 Salir
opción> 1
Base de datos creada!
opción> 2
Tablas creadas!
opción> 3
(etc ...)
Tener en cuenta, que en la opción 5 deben cargarse todos los datos provistos, incluidos los datos
de prueba.
Observar, que la aplicación no debe solicitar datos individuales a le usuarie—más allá de los números
de las opciones mencionadas.
Por último, el código NoSQL, puede ejecutarse, como se muestra en el ejemplo, desde la opción 8
de este menú, ó si el equipo lo considera, se puede hacer otra aplicación simple en Go por separado.
7 Condiciones de Entrega y Aprobación
No respetar alguna de las siguientes condiciones, representa la desaprobación del tra-
bajo práctico:
• El trabajo es grupal, en grupos de, exactamente, cuatro integrantes. El trabajo práctico se
debe realizar en un repositorio privado git, hosteado en GitLab con el apellido de les cua-
tro integrantes, separados con guiones, seguidos del string -db1 como nombre del proyecto,
e.g. giunta-maradona-palermo-riquelme-db1. Agregar como owner’s a les docentes de la ma-
teria, los usernames de Gitlab hdr y ximeebertz al momento de la creación del reposito-
rio.
• La fecha de entrega máxima es el 23 de junio de 2025 en horario de clase, con una defensa
presencial del trabajo práctico por cada grupo, en la cual se mirará lo que se encuentre en el
repositorio git hasta ese momento, y se harán distintas preguntas a cada integrante del grupo.
• El informe del trabajo práctico debe incluirse en el directorio principal del repositorio con el
nombre de archivo [Link], y debe realizarse en formato Asciidoc. Para ello, cuentan con
una guía en [Link]/adoc.
• Usar apropiadamente git y GitLab. No usar branches, no usar rebase, no borrar el repo
una vez creado. Asegurarse de configurar merge, nombre y apellido, y email:
$ git config --global [Link] false
$ git config --global [Link] 'diego@[Link]'
$ git config --global [Link] 'Diego Armando Maradona'
Durante la creación de la cuenta de GitLab, configurarla para uso personal.
No subir archivos al repo desde Windows (a menos que se aseguren que los archivos
tengan el formato Unix).
• Trabajo de investigación: En este trabajo práctico van a tener que investigar por su cuenta cómo
se hacen algunas cosas en PostgreSQL. No usen ChatGPT, ni busquen en Stack Overflow
ó sitios similares, para eso tienen la documentación oficial de PostgreSQL.
• Advertencia: La copia o la consulta de un repo de otro grupo, sea de este semestre o de semestres
anteriores, implica la desaprobación automática del trabajo práctico y, por lo tanto, también
de la cursada. Además, estos casos se informarán a la coordinación académica de la
carrera, para que evalúe si fuera necesario aplicar alguna otra medida.