Final - Gestión De Datos - 2017-05-12.docx (Tamaño: 14,37 KB / Descargas: 533)

NOTA: Las contesto resumidas para que se hagan una idea. Todo esto está en los apuntes de la cátedra y lo que explican en la cursada.

1) Contestar por Verdadero o Falso

A) VERDADERO En el caso más general, Hashing es más performante que Árbol B: Hashing, a partir de una clave, devuelve un índice de una tabla con la dirección de memoria del registro con dicha clave, con el riesgo de que ocurran colisiones, por eso es más performante que Árbol B en búsqueda por clave. De hecho, Árbol B es mejor para búsquedas por rango. Sin embargo, siempre hay que tener en cuenta la distribución de datos y como esté configurada la función de hash: si una búsqueda por hash produce muchas colisiones para una misma clave, es probable que un Árbol B sea más performante que Hashing.

B) FALSO El árbol binario no es necesariamente balanceado. Tomen como ejemplo el árbol que surge de comprimir el texto "Tomemos como ejemplo esta frase. " con Huffman.

2) Responder exactamente lo solicitado en la pregunta en no más de 15 renglones.

A) Un trigger es un conjunto de instrucciones que se asignan a un tabla y se ejecutan antes, en vez de o después de un evento, que puede ser un INSERT, DELETE o UPDATE. Entre otros usos, se destacan la validación de reglas de integridad del sistema impuestas por el negocio, DELETE's en cascada, etc.

B) Estos son los cuatro niveles de aislamiento para transacciones:

READ UNCOMMITTED: No tiene bloqueos por tabla. Es el más performante, pero sufre de lecturas sucias, no repetibles y fantasmas, por lo cual, ante una misma consulta puedo obtener filas que no fueron commiteadas en una transacción.

READ COMMITTED: Tiene bloqueos compartidos por tabla. Soluciona lecturas sucias, pero no sufre de lecturas no repetibles y fantasmas, por lo que ante una misma consulta puedo obtener filas distintas con valores desactualizados.

REPETEABLE READ: Tiene bloqueos exclusivos por tabla, pero no son por rango, por lo cual soluciona lecturas no repetibles, pero no así las fantasmas, por lo que ante una misma consulta puedo obtener filas de más o de menos. Puede causar deadlock.

SERIALIZABLE: Tiene bloqueos exclusivos por tabla y por rangos, por lo no tiene problemas de lectura, es el más consistente, y las transacciones parecen ocurrir en serie. Pero puede causar deadlock: un hilo de ejecución 1 quiere lo que tiene el hilo de ejecución 2 y viceversa, pero no puede acceder al recurso porque están bloqueados simultáneamente.

3) Parte práctica

A) La respuesta correcta es la 2. Hacer un FROM <Tabla1>, <Tabla2> es lo mismo que hacer el producto cartesiano entre dos tablas. Como en la consulta tenemos FROM empleados e, perfiles y perfiles es una tabla sin datos, el producto cartesiano da un conjunto vacío de datos.

B) Lo resolví de esta manera:

 

CREATE VIEW empleados_con_jefe_view AS



	SELECT



		j.cod_empleado AS Código_Jefe,

		j.des_empleado AS Nombre_Jefe,

		e.cod_empleado AS Código_Empleado,

		e.des_empleado AS Nombre_Empleado



	FROM empleados j



	JOIN empleados e ON j.cod_empleado = e.cod_jefe



	WHERE (SELECT COUNT(*) FROM empleados WHERE cod_jefe = j.cod_empleado) > 4

Se puede hacer una consulta parecida con la BD para resolver ejercicios de la cátedra. Se las paso para que prueben y vean que no fruteo:

 

SELECT



	j.empl_codigo AS jefe_codigo,

	j.empl_nombre AS jefe_nombre,

	j.empl_apellido As jefe_apellido,

	e.empl_codigo AS empl_codigo,

	e.empl_nombre AS empl_nombre,

	e.empl_apellido As empl_apellido



FROM Empleado j



JOIN Empleado e ON j.empl_codigo = e.empl_jefe



WHERE (SELECT COUNT(*) FROM Empleado WHERE empl_jefe = j.empl_codigo) > 4

 

create view estructura_jefes

(cod_empleado)

as



select j.cod_empleado from

empleados e join empleados j on e.cod_jefe=j.cod_empleado



group by j.cod_empleado

having count(*)>4

 

CREATE TABLE empleados

(

  cod_empleado int,

  cod_jefe int,

  PRIMARY KEY (cod_empleado)

  FOREIGN KEY (cod_jefe) REFERENCES empleados(cod_empleado)

);



INSERT INTO empleados (cod_empleado, cod_jefe)

VALUES

(1, NULL),

(2, NULL),

(3, NULL),

(4, 1),

(5, 2),

(6, 2),

(7, 2),

(8, 2),

(9, 3),

(10, 3),

(11, 3),

(12, 3),

(13, 3),

(14, 4),

(15, 5),

(16, 5),

(17, 5),

(18, 5),

(19, 6),

(20, 6),

(21, 6),

(22, 6),

(23, 6)



create view estructura_jefes

(cod_empleado)

as



select j.cod_empleado from

empleados e join empleados j on e.cod_jefe=j.cod_empleado



group by j.cod_empleado

having count(*)>4