Donar $20 Donar $50 Donar $100 Donar mensualmente
 


Enviar respuesta 
 
Calificación:
  • 0 votos - 0 Media
  • 1
  • 2
  • 3
  • 4
  • 5
Buscar en el tema
[Aporte] Final de Gestión De Datos - 05/12/2017
Autor Mensaje
Degue1297 Sin conexión
Empleado del buffet
XD
*

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 3
Agradecimientos dados: 1
Agradecimientos: 4 en 2 posts
Registro en: Mar 2016
Mensaje: #1
[Aporte] Final de Gestión De Datos - 05/12/2017 Finales Gestión de Datos
Hola, qué tal. Quería aportar mi grano de arena al foro con el final de GDD que se dio el 05/12/2017. Era sencillo: todas las preguntas teóricas se pueden sacar de finales anteriores y la práctica también era tranqui, con algún que otro palito.

Final
Spoiler: Mostrar

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

Respuestas
Spoiler: Mostrar
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



Espero que les sirva. Cualquier cosa que esté mal o turbia... Arreglenlo ustedes. Yo ya formatié GDD XD Saludos.
(Este mensaje fue modificado por última vez en: 06-12-2017 18:25 por Degue1297.)
06-12-2017 13:29
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
[-] Degue1297 recibio 3 Gracias por este post
CarooLina (06-12-2017), chrisgel15 (06-12-2017), macyn (06-12-2017)
Omnipresent Sin conexión
Campeon del cubo Rubik
The Winter is gone
****

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 145
Agradecimientos dados: 41
Agradecimientos: 41 en 35 posts
Registro en: Sep 2014
Mensaje: #2
RE: [Aporte] Final de Gestión De Datos - 05/12/2017
Nota al margen:
El 1.a) es Falsa (fue un error que tuve).
Yo caí en esa porque no dice "siempre" y entonces pensé que se referían solamente al caso más feliz. Pero bueno, si justificabas que igual existían casos en los que no es más perfomante te lo tomaban como bien que hayas puesto "Verdadera".

Detalles solo para buscar bajarte la nota =)
06-12-2017 17:07
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
[-] Omnipresent recibio 1 Gracias por este post
CarooLina (06-12-2017)
Degue1297 Sin conexión
Empleado del buffet
XD
*

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 3
Agradecimientos dados: 1
Agradecimientos: 4 en 2 posts
Registro en: Mar 2016
Mensaje: #3
RE: [Aporte] Final de Gestión De Datos - 05/12/2017
Jajaja XD Está bien. Me cuestioné eso en su momento. Pero no quise entrar en duda y desesperación y lo mandé así. Pensándolo bien, que tan performante es una consulta depende de como están distribuidos los datos y todas esas cosas. Si tenés que hacer rehashing 10000 veces para acceder directo a una clave cuando podías agarrar la dirección de la primer hoja del árbol B, bueno, ahí sí es más performante Árbol B. Se ve que el profe justo se buggeó cuando me corrigió y me lo puso bien XD Ahora lo agrego igual por las dudas.
06-12-2017 18:21
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
[-] Degue1297 recibio 1 Gracias por este post
CarooLina (06-12-2017)
Buscar en el tema
Enviar respuesta 




Usuario(s) navegando en este tema: 1 invitado(s)



    This forum uses Lukasz Tkacz MyBB addons.