Uploaded by Francisco Chicote Martin

wuolah 1252591 5pgdkv5e

advertisement
Examen Julio 2018 - Examen Final...
Artyman13
Bases de Datos
2º Grado en Ingeniería Informática
Escuela Técnica Superior de Ingenieros Informáticos
Universidad Politécnica de Madrid
Reservados todos los derechos.
No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad.
Examen Bases de Datos
Examen de convocatoria de Julio
Ingeniería Informática/Grado en Matemáticas e Informática/Doble Grado en Ing.
Informática y ADE
2-julio – 2018
FECHA PREVISTA DE PUBLICACIÓN DE NOTAS: 18 de julio de 2018
FECHA PREVISTA DE REVISIÓN DE NOTAS: 20 de julio de 2018
Duración del examen: 2:30 horas
IMPORTANTE:
Cada alumno debe realizar solo la parte que le corresponda (que tenga
suspensa por no haber obtenido una nota de 5 puntos o superior según los
criterios publicados recientemente). Aquellos alumnos que realicen partes que ya
tengan aprobadas, no serán corregidas. De igual forma, si un alumno no realiza
una parte que tenía suspensa, supone el suspenso automático de dicha parte, del
examen y de la asignatura. En cualquier caso, deben entregarse todas las
hojas con nombre, apellidos y DNI y simplemente marcar la casilla que hay
en la parte superior de cada parte indicando que dicha parte está aprobada.
Instrucciones y aclaraciones:
Cada ejercicio es corregido por un profesor y se puntúa de 0 a 10. Se debe
entregar cada parte en hojas separadas y ponerse todos los datos del alumno
(nombre, apellidos y matrícula/DNI) en cada hoja. Deben entregarse todas las
partes, aunque estas se entreguen vacías. Aquellas hojas que se entreguen sin
haber identificado correctamente al alumno no se corregirán y no cabrá
reclamación posterior. Los pesos que corresponden a cada parte del examen,
son:
•
•
•
•
Modelo E/R, Paso a Tablas y SQL: 40%
Modelo relacional: 20%
Acceso programático: 20%
Seguridad: 20%
Las notas se publicarán especificando la nota de cada parte por separado (de 0 a
10) así como la nota final también en escala 0-10.
Reservados todos los derechos. No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad.
a64b0469ff35958ef4ab887a898bd50bdfbbe91a-1252591
Apellidos:
Nombre:
DNI:
Ejercicio: Modelo Entidad/Relación, Paso a Tablas y SQL
Marcar con una X en caso de tener esta parte aprobada y por lo tanto no ser susceptible de corrección:
El sistema de atención de llamadas de una empresa quiere realizar una base de datos para
automatizar todos sus procesos. En particular se quiere almacenar la información que se extrae
de la siguiente descripción.
Cada vez que se realiza una llamada se le asigna un identificador y se almacena la fecha y la
duración de la llamada en minutos.
Además, es necesario saber el cliente que ha realizado la llamada del que se almacena su
identificador y nombre. No se guardará ninguna llamada de la que se desconozca el cliente que la
realiza y obviamente un cliente puede realizar muchas llamadas o ninguna.
También es necesario saber el empleado que ha atendido la llamada del que se tendrá su nombre
e identificador y la lista de idiomas (identificador y nombre) que habla. Al menos es siempre
necesario saber un idioma que habla. Se van a guardar asimismo los departamentos (identificador
y nombre) donde ha estado asignado cada empleado a lo largo de su vida sabiendo que el mismo
empleado ha podido estar asignado al mismo departamento en distintos momentos del tiempo y
es necesario guardar esta información.
El empleado que atiende la llamada analizará la misma y es necesario poder almacenar en la base
de datos todos los motivos de la llamada. Obviamente habrá más de una llamada por el mismo
motivo y una llamada tendrá más de un motivo. La tipología del motivo se tiene que almacenar en
la base de datos puesto que lleva asociado la duración máxima (en días) para atender la llamada.
Una vez terminado el proceso de análisis y establecidos los motivos de la llamada se abrirán
tantos partes de incidencias como sean necesarios para resolver los temas planteados. Todo parte
de incidencia tiene un número que lo identifica y se le asigna la fecha. No se guardarán partes de
incidencia de los que se desconozca la llamada con la que están asociados. Además, será
necesario saber los departamentos asignados para resolver el parte de incidencias asociado a una
llamada.
Se pide:
Reservados todos los derechos. No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad.
a64b0469ff35958ef4ab887a898bd50bdfbbe91a-1252591
Apellidos:
Nombre:
DNI:
Diagrama E/R que mejor modelice la base de datos planteada (6 ptos).
Transformación a modelo relacional (paso a tablas) de la parte del diagrama planteado que sea
necesario para realizar las siguientes consultas: (1 pto)
Llamada (n, fecha)
Incidencia (n, fecha, n_llamada)
Asigna ( Cod_dpto, Cod_incidencia)
Departamento (Id, Nombre)
•
Listar el numero y la fecha de todas las incidencias asignadas al departamento con
Identificador= I23 (0,5 ptos)
SELECT I.n, I.fecha
FROM Dpto D, Asigna A, Incidencia I
WHERE D.id=A.Cod_dpto AND I.n=A.Cid_incidencia
AND Departamento.Id=”I23”
•
Listar el numero de llamada junto con el numero de partes de incidencia que ha generado
(0,5 ptos)
SELECT n_llamada, COUNT(*)
FROM Incidencia
GROUP BY n_llamadas
•
Insertar el parte de incidencia numero 27 de fecha 3 de noviembre de 1970 en la base de
datos (0,5 ptos)
Reservados todos los derechos. No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad.
a64b0469ff35958ef4ab887a898bd50bdfbbe91a-1252591
Apellidos:
Nombre:
DNI:
INSERT INTO Incidencias (n, fecha) VALUES (27, 3-11-1970)
•
Crear la tabla de incidencias (0,5 ptos)
CREATE TABLE Incidencias(
n INT,
Fecha DATE,
N_llamada INT
PRIMARY KEY (n)
FOREIGN KEY N_llamada REFERENCES Llamada (n)
ON UPDATE CASCADE
ON DELETE RESTRICT)
•
Visualizar el código de los departamentos que resolvieron incidencias asignadas entre
2016 y 2018
SELECT A.cod_departamento
FROM Incidencia I, Asigna A
WHERE I.id=A.cod_incidencia
AND year(I.fecha) BETWEEN 2016 AND 2018
•
Aumenta la duración en dos minutos de todas las llamadas que se recibieron en los meses
de julio, agosto, septiembre, octubre y diciembre.
UPDATE Llamada
SET duración=duración +2
WHERE month( fecha) IN (julio, agosto, septiembre, octubre y diciembre)
Reservados todos los derechos. No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad.
a64b0469ff35958ef4ab887a898bd50bdfbbe91a-1252591
Apellidos:
Nombre:
DNI:
Ejercicio: Modelo relacional
Marcar con una X en caso de tener esta parte aprobada y por lo tanto no ser susceptible de corrección:
Un cierto sistema está caracterizado por los parámetros siguientes:
T= {A, B, C, D, E, F}
Que verifican las reglas (dependencias) siguientes:
L= {B-> CD, DE-> A, A->B}
Diseñar una Base de Datos Relacional para dicho sistema, usando el Algoritmo de J.
Ullmann.
Reservados todos los derechos. No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad.
a64b0469ff35958ef4ab887a898bd50bdfbbe91a-1252591
Apellidos:
Nombre:
DNI:
Solución:
L:
B->CD
DE->A
A->B
L1:
1 B->C
2 B->D
3 DE->A
4 A->B
Análisis del implicante DE:
D+L1 = D, E+L1 = E; ni D ni E son superfluos.
Análisis de redundancia:
B+L1-1 =BD, B+L1-2 = BC, DE+L1-2= DE, A+L1-4 = A; No hay dependencias redundantes. L2 es
recubrimiento no redundante de L
Cálculo de una clave:
I={E}, D={C}, ID={A, B, D}, N={F}
Z=EF, Z0=EF, Z0+= EF, Z1= EFA, Z1+=ABCDEF
AEF es una clave.
Subesquemas:
R1 (BCD), R2 (ADE), R3 (AB), R0 (AEF)
Reservados todos los derechos. No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad.
a64b0469ff35958ef4ab887a898bd50bdfbbe91a-1252591
Apellidos:
Nombre:
DNI:
Ejercicio: Acceso Programático
Marcar con una X en caso de tener esta parte aprobada y por lo tanto no ser susceptible de corrección:
Ejercicio 1 (6 puntos):
Dados los siguientes fragmentos de código, rellenar lo que corresponda en cada uno. Nótese que
en el fragmento 2, la operación que se quiere ejecutar es una inserción. La respuesta debe
entregarse en la tabla anexa, simplemente incluyendo la solución propuesta. Sólo se considerará
válida la respuesta si es 100% correcta (se diferencia mayúsculas y minúsculas y una sola letra
omitida es motivo para no dar la respuesta por válida), no habiendo interpretaciones o
valoraciones parciales. Es también responsabilidad del alumno asegurarse de que pone la
respuesta correcta asociada a cada hueco, no siendo susceptible de revisión problemas asociados
a “equivocarse” al indicar el número y cosas similares. Cada respuesta correcta suma 0.3 puntos.
Las respuestas vacías o incorrectas ni suman ni restan.
Comentarios:
-
Para el hueco 6, se solicita la excepción más general que existe en Java.
Para el hueco 7, la excepción más correcta y específica que aplique a todo el método.
El hueco 13 pretende que se ejecute y se inserten los datos en la base de datos.
El hueco 17 pretende que se cierre el PreparedStatement.
Fragmento 1:
Fragmento 2:
Reservados todos los derechos. No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad.
a64b0469ff35958ef4ab887a898bd50bdfbbe91a-1252591
Apellidos:
Nombre:
DNI:
Respuestas:
Hueco
1
2
3
4
5
Respuesta
jdbc.Driver
3306
mysql
DriverManager
url
Hueco
6
7
8
9
10
Respuesta
Exception
SQLException
VALUES/values
?,?,?
1
Hueco
11
12
13
14
15
Respuesta
2
3
executeUpdate
Int
String
Hueco
16
17
18
19
20
Respuesta
Date
close
prepare
INTO/into
INSERT/insert
Ejercicio/pregunta 2 (1,5 puntos): Explicar que es un Trigger, sobre que operaciones aplica y
cuales son las opciones a la hora de crearlo. Máximo 5 líneas.
Respuesta:
Un trigger es un objeto asociado a una tabla. Aplica sobre las operaciones de modificación de la
BD (INSERT, UPDATE, DELETE). A la hora de crear un trigger, este puede crearse en base a que la
acción de ejecución del trigger se ejecute antes (BEFORE) de modificar la tabla o después (AFTER)
de ello.
Ejercicio/pregunta 3 (2,5 puntos): Explicar en que consiste una transacción. Explicar que es el
AUTOCOMMIT en MySQL, que valores puede tener y que implica cada uno (incluyendo en ambos
modos cuando empieza y acaba una transacción). Máximo 10 líneas.
Respuesta:
Una transacción es un conjunto de operaciones que se ejecutan de forma atómica (indivisible). El
autocommit es un flag del SGBD que permite que las operaciones se puedan ejecutar de forma
atómica o no. Si AC = 1, cada operación será en sí misma una transacción (salvo que se ejecute
una sentencia para que una transacción la conforme un conjunto de operaciones (e.g.: START
TRANSACTION)). Sin embargo, si AC = 0, una transacción la definirá el conjunto de operaciones
desde el fin de una transacción previa hasta que la transacción en curso se cierre (commit, rollback
o mediante fallo del SGBD).
Reservados todos los derechos. No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad.
a64b0469ff35958ef4ab887a898bd50bdfbbe91a-1252591
Apellidos:
Nombre:
DNI:
Ejercicio Seguridad y Acceso a Bases de Datos
Marcar con una X en caso de tener esta parte aprobada y por lo tanto no ser susceptible de corrección:
(30 Minutos)
Sea una Organización que dispone de un sistema Gestor MySQL que gestiona las Bases de Datos
de la Organización. Con el objetivo de garantizar la seguridad de la información almacenada en las
Bases de Datos, se ha decidido incorporar servicios de seguridad en el Gestor MySQL. En concreto,
estos servicios deberán garantizar la confidencialidad de las consultas y la autenticación e
integridad de los datos en el acceso al Gestor MySQL. Para ello se propone utilizar la capa de
seguridad TLS (Transport Layer Security).
En este contexto se pide:
a) Describir en qué consiste el servicio de Confidencialidad respecto de la transmisión en red de
las consultas/respuestas en el acceso a un SGBD (Sistema Gestor de Bases de Datos). (1p)
La confidencialidad es la protección de los datos frente a intrusos. En el caso de las consultas
transmitidas en el acceso al Gestor de la Base de Datos, el servicio de confidencialidad debe de
garantizar que el contenido de dichas consultas no es accesible a un intruso.
b) Describir en qué consiste el servicio de autenticación e integridad respecto de la transmisión
en red de las consultas/respuestas en el acceso a un SGBD (Sistema Gestor de Bases de Datos).
(1p)
El servicio de autenticación debe de garantizar que los datos provienen de la entidad alegada. El servicio
de integridad debe de garantizar a la vez que los datos no han sido modificados en tránsito. En resumen
el servicio de autenticación e integridad debe de garantizar que las consultas vienen de la entidad
alegada y no han sido modificadas en tránsito.
c) ¿Qué infraestructura de seguridad, certificados y/o claves necesita el SGBD para que un usuario
pueda implementar los anteriores servicios de seguridad en el acceso al SGBD con el protocolo
TLS? Razonar la respuesta. (2p)
Para que el Gestor MySQL pueda arrancar con con servicios de seguridad se necesitan 3 ficheros:
SR_certificado.pem, SR_ClavePrivada.pem y CA_Certificado.pem. El primero contiene el certificado del
Gestor MySQL que a su vez contiene la clave pública que el cliente utilizará más adelante para distribuir
claves de sesión y autenticación. Se envía en el mensaje “Certificado” del servidor. El segundo fichero
contiene la clave privada del Gestor MySQL que se utilizará para descifrar las claves de sesión y
autenticación que enviará el cliente al Gestor MySQL en el mensaje “Intercambio de clave de Cliente”. El
tercer fichero contiene la Autoridad de Certificación que se utilizará para validar el certificado enviado
por el cliente (mensaje “Certificado”), es decir, se utilizará para comprobar que está firmado por ésta
autoridad.
Reservados todos los derechos. No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad.
a64b0469ff35958ef4ab887a898bd50bdfbbe91a-1252591
Apellidos:
Nombre:
DNI:
d) Explicar cómo el protocolo TLS puede implementar el servicio de Confidencialidad respecto de
consultas realizadas a un SGBD. (2p)
La forma de implementar el servicio de confidencialidad consiste en distribuir una clave de sesión entre
el cliente y el Gestor MySQL de forma segura. Para ello se utiliza el modelo de clave pública, siendo el
cliente y el Gestor MySQL participantes de este modelo. Mediante el protocolo TLS el servidor envía al
cliente un certificado de clave pública del servidor emitido por una entidad confiable. El cliente toma
parte en la generación de una clave de sesión que distribuye al Gestor MySQL cifrándola con la clave
pública del Gestor. Una vez distribuida la clave de sesión de forma segura las consultas al Gestor MySQL
son cifrada mediante un mecanismo de cifrado simétrico tomando como entrada la clave de sesión
distribuida.
e) Explicar cómo el protocolo TLS puede implementar el servicio autenticación e integridad de los
datos en el acceso al Gestor MySQL. (2p)
La forma de implementar el servicio de autenticación e integridad consiste en distribuir una clave de
autenticación entre el cliente y el Gestor MySQL de forma segura. Para ello se utiliza el modelo de clave
pública, siendo el cliente y el Gestor MySQL participantes de este modelo. Mediante el protocolo TLS el
servidor envía al cliente un certificado de clave pública del servidor emitido por una entidad confiable. El
cliente toma parte en la generación de una clave de autenticación que distribuye al Gestor MySQL
cifrándola con la clave pública del Gestor. Una vez distribuida la clave de autenticación de forma segura
los datos correspondientes a las consultas al Gestor MySQL se agrupan en segmentos de modo que a
cada segmento se le añade un bloque criptográfico formado por el código de autenticación del
segmento tomado como entrada la clave de autenticación distribuida. Este bloque criptográfico se
comprueba en destino y si se recibe inalterado confirmaría la autenticación e integridad de los
segmentos recibidos.
f) Especificar en qué Base de Datos y en qué Tabla del sistema de Gestión de MySQL se almacena
la información relativa al usuario, dirección IP de acceso, login y password. Razonar la
respuesta. (1p)
La Base de Datos de Gestión de MySQL se llama “mysql” y la tabla en la que se almacena la información
relativa al usuario, dirección IP de acceso, login y password es la Tabla “user”
g) ¿Se almacena en claro la password de acceso del usuario en el sistema de Gestión MySQL?.
Razonar la respuesta. (1p)
La password de los usuarios no se almacena nunca en claro en el SGBD sólo se almacena un resumen
(hash) de la password en la Tabla mysql.user. El cliente presenta una password cuyo hash coincida con el
almacenado por el SGBD
Reservados todos los derechos. No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad.
a64b0469ff35958ef4ab887a898bd50bdfbbe91a-1252591
Download