[Gestion de Datos] 6 FINALES (2018-2019) ¡RESUELTOS! - Versión para impresión +- UTNianos (https://www.utnianos.com.ar/foro) +-- Foro: Carreras de Grado (/foro-carreras-de-grado) +--- Foro: Sistemas (/foro-sistemas) +--- Tema: [Gestion de Datos] 6 FINALES (2018-2019) ¡RESUELTOS! (/tema-gestion-de-datos-6-finales-2018-2019-resueltos) Páginas: 1 2 |
[Gestion de Datos] 6 FINALES (2018-2019) ¡RESUELTOS! - manurocck - 25-09-2019 23:52 ¡ Qué tal UTNianos ! Se me está empezando a hacer un poco de costumbre hacer este tipo de posts, espero que les sirva Acá los FINALES RESUELTOS :
- Si crees que algún final tiene un error dejá un comentario y lo modificamos - Si tienen algún final que no esté incluido en algún pueden publicarlo o mandarlo por m.d así lo incluyo en el post Saludos! Edit: Aprobada el 4/12/2019 RE: [Gestion de Datos] Final 25/09/2019, 26/02/2019 ¡RESUELTOS! - Diesel - 16-10-2019 15:47 Buenas ! Con respecto al final de 25 de septiembre de 2019 Me animé a hacer el 3a de otra forma SIN QUE SEA CONSULTA aclaro... mas o menos parecida a la resolución. Algun crack en SQL me lo verifica?? gracias!
RE: [Gestion de Datos] Final 25/09/2019, 26/02/2019 ¡RESUELTOS! - manurocck - 16-10-2019 19:33 (16-10-2019 15:47)Diesel escribió: Buenas ! Cómo te va Diesel, calculo que funciona también. Comparando las diferencias entre las consultas me di cuenta de que lo que hiciste fue aislar la subquery del HAVING para asignarle el valor a una variable. Lo que sí, muchas veces te piden que lo hagas todo en solo una consulta, sin funciones auxiliares ni otras cosas. No se si te dirían algo por hacer eso o no.. Yo entre las dos me arriesgaría por la primera por las dudas (aunque den el mismo resultado) Saludos! RE: [Gestion de Datos] Final 25/09/2019, 26/02/2019 ¡RESUELTOS! - Diesel - 17-10-2019 08:35 (16-10-2019 19:33)manurocck escribió:(16-10-2019 15:47)Diesel escribió: Buenas ! Asi es manu ! Tenes razon aislé el having de la query. También entregaría la query en lugar del procedure. Ya que te metiste a pensarlo nuevamente conmigo te hago una consulta. Ves la nota que puse en le filtro "where"?? Filtramos por puesto 1. Y luego hacemos el SUM... pero al hacer el SUM estamos haciendo el SUM de las carreras que obtuvo el primer puesto ese caballo... o sea la cantidad de guita que recibió en apuestas solamente para la fecha y para el primer puesto... eso no esta medio mal ?? porque en el ejercicio te pedía la cantidad de guita q haya sacado el caballo en apuestas sin importar q haya sido en primeros puestos digamos y que esa guita sea la menor que se apostó ever... o sea como que habria que anidar todo el resultado y LUEGO hacer el filtro del primer puesto y la fecha... o no? Si no se entiende reformulo xD Gracias de nuevo! RE: [Gestion de Datos] Final 25/09/2019, 26/02/2019 ¡RESUELTOS! - manurocck - 17-10-2019 14:35 (17-10-2019 08:35)Diesel escribió: Ya que te metiste a pensarlo nuevamente conmigo te hago una consulta. Creo que tenés razón .. Tal vez se podría solucionar reemplazando el SUM por otra subquery que calcule el total de apuestas del caballo sin importar el puesto en el que salió
Qué te parece? RE: [Gestion de Datos] Final 25/09/2019, 26/02/2019, 12/02/2019 ¡RESUELTOS! - Diesel - 17-10-2019 15:34 (17-10-2019 14:35)manurocck escribió:(17-10-2019 08:35)Diesel escribió: Ya que te metiste a pensarlo nuevamente conmigo te hago una consulta. Testeado y funciona! muy bien.
En el Having no tiene sentido poner MENOR IGUAL dado que siempre va a tener que ser igual. Si yo agrego un caballo que se llama "pobreton" al cual le apostamos menos que a "ROCKY" (el cual salio primero) y le apostaron "POCO" entonces la query no va a traer nada... porque POBRETON tendria le menor apuesta y lo que le apostaorn a rocky es mayor. Si le agregamos 400 a pobreton entonces ahi sobrepasa a rocky, teniendo asi rocky lo menor apostado y devolviendo ESE valor en el having.. es como que el having dice "este caballo que salio primero posee lo menor que se le aposto en la vida del sistema?" y si la respuesta es "si" entonces lo devuelve en la consulta. Le borré el filtor del dia asi funcionaba abrazo. Edit: Aprobada el dia 11/12/19 !!!!! gracias Pablit por tu resumen y Manurocck ! 19 finales de practica me hice. No se lo deseo a nadie. RE: [Gestion de Datos] Final 25/09/2019, 26/02/2019, 12/02/2019 ¡RESUELTOS! - pablit - 18-11-2019 15:03 Hola gente, yo lo rendí en Septiembre y no llegué a los 6 puntos (4,5 sumé). Respecto del 3a, lo había hecho así: [attachment=18432] Corrigiendo errores, entiendo que el código debería haber sido algo así:
Creo que estaría bien... ¿cómo lo ven ustedes? Ya que estoy, dejo el 3b donde me calificaron con 0,5 puntos (de 2)... [attachment=18433] Hay 2 cosas que no entiendo sobre las correcciones... 1. El INSERT está tachado, dando a antender que el trigger actuará solament ante un UPDATE. ¿Por qué el INSERT estaría mal? 2. Dentro del WHILE, en la parte del UPDATE, en un IF me indicaron que "era validación". ¿A qué se refieren con eso? RE: [Gestion de Datos] Final 25/09/2019, 26/02/2019, 12/02/2019 ¡RESUELTOS! - xavi82 - 18-11-2019 16:17 Hola pablit, para mi el tema es que el enunciado dice que la ejecucion del objeto a desarrollar depende del valor NO NULO del campo Puesto, por lo que si es no nulo el registro ya existe y tiene un valor asignado, entonces que Puesto sea no nulo es una precondicion (por eso lo de validacion entiendo) y te tachan el insert porque seria en el caso de un UPDATE que deberias ejecutarlo. Saludos! RE: [Gestion de Datos] Final 25/09/2019, 26/02/2019, 12/02/2019 ¡RESUELTOS! - pablit - 21-11-2019 20:34 (18-11-2019 16:17)xavi82 escribió: Hola pablit, (Siempre hablando del 3b...) Entiendo lo que decís y creo que sí, está bien, tiene sentido que así sea. Ahora bien, no me cierra por qué está mal pensar en un INSERT y bien en un UPDATE El enunciado indica que "en la actualidad dicha regla se cumple y que la BD es accedida por n aplicaciones de diferentes tipos y tecnologías". ¿Cómo te das cuenta si es un INSERT o un UPDATE en ese caso? Hay casos donde me doy cuenta enseguida, porque me parecen claros, pero acá no... RE: [Gestion de Datos] 5 FINALES (2018-2019) ¡RESUELTOS! - pablit - 05-12-2019 00:15 Subo el final que tomaron hoy, 4/12: [attachment=18514] Y ya que estoy acerco las respuestas, que creo que están bien: 1. - a. FALSO. Si bien es cierto que no puede almacenar valores repetidos, UNIQUE sí puede almacenar un NULL (uno solo, más no). - b. VERDADERO. Hashing es más performante que el árbol-B para búsquedas directas o accesos directos. 2. Tanto para el a. como para el b. recomiendo [autobombo]mi resumen teórico[/autobombo], donde está desarrollado lo que piden acá: - a. Objetos de BD que garanticen la integridad: triggers, vistas, índices... con desarrollar 2 de esos ya estaría (está todo en el resumen). - b. Sobre los niveles de aislamiento, bueno, marcar las diferencias entre el Uncommitted Read, el Committed Read, el Repeatable Read y el Serializable Read... contando el asunto de las lecturas sucias, las lecturas no repetibles y las lecturas fantasmas (está todo en el resumen). 3. - a. OPCIÓN 3: Devuelve un conjunto vacío de datos porque como no hay datos en al tabla DEPOSITO es imposible que esa tabla tenga algún dato en común con la tabla PRODUCTOS. - b. La solución brindada es incorrecta. Para hacer cambios en la BD, no puedo usar funciones (las funciones no pueden hacer cambios en la base de datos!). Debería haber usado un stored procedure. Los cambios a hacer serían los siguientes: (1) cambiar el function por el procedure; (2) eliminar el returns bit; y, si no me olvido de nada más (3) eliminar el RETURN 1 que aparece abajo. Gracias a manurocck por el dato del 3.b. RE: [Gestion de Datos] 6 FINALES (2018-2019) ¡RESUELTOS! - nanohueso - 17-12-2019 19:25 En el final del 17 de Julio de 2018, El ejercicio 3.a) para mi la opcion correcta es la B. Hace un join entre EMPRESA y AREAS . Ahi ya tenes si o si las empresas con sus areas. Si una empresa no tiene area, entonecs no va a estar en el resultado de ese join. Luego, hacemos un left join con EMPLEADOS, lo que va a pasar es que si un area no tiene empleados, la columna va a quedar en null. Al hacer count(em.empresa_id) va a contabilizarlo como 0. El 3.b) me hace ruido el left join que haces entre empresa y empleado. Si bien esta la fk, esta punteando la relacion con area. Yo lo hice asi: select e.id_empresa,count(distinct(area.id_area)),count(e.cuit) from empresa e join area on (area.id_empresa = e.id_empresa) // me quedo con las empresa que tengan areas join empleado emp on (area.id_area = emp.id_area and area.id_empresa = emp.id_empresa) // multiplico x empleado where e.id_empresa not in ( select area.id_empresa from area a1 join empleado e1 on (a1.id_area = e1.id_area and a1.id_empresa = e1.id_empresa) group by area.id_area,area_id.empresa having empleados > 10 ) // de todas esas filas empresa-area-empleado, me quedo solamente con aquellas empresas que no tengan areas con mas de 10 empleados group by e.id_empresa // luego al agrupar x empresa, cuento las areas distintas, y cuento con los cuits. En el final del 12 de Marzo: El ejercicio 3a ) Concuerdo con la opcion II , yo reescribi la view sin el UNION: Haciendo un left join me traigo todos los usuarios y en caso de matchear tmb sus ingresos. Dps agrupo x usuario y hago un case validando si es null o tomo el max() select u.Nombre,u.Apellido, CASE WHEN i.Fecha IS NULL then u.FechaAlta ELSE max(i.Fecha) USUARIOS u LEFT JOIN INGRESOS i ON ( u.IdUsuario = i.idUsuario) group by u.Nombre,u.Apellido,u.FechaAlta (25-09-2019 23:52)manurocck escribió: ¡ Qué tal UTNianos ! RE: [Gestion de Datos] 6 FINALES (2018-2019) ¡RESUELTOS! - marcos32 - 17-12-2019 22:56 Otra solucion para el 3.b del final del 12/02/2019
RE: [Gestion de Datos] 6 FINALES (2018-2019) ¡RESUELTOS! - .-Fede-. - 09-02-2020 19:44 (17-12-2019 19:25)nanohueso escribió: En el final del 17 de Julio de 2018, Mire todos los comentarios justo para buscar alguien que haya comentado esto respecto al 3a del 17 La respuesta correcta estoy casi seguro que es la B (La C de entrada no puede ser porque es un LEFT JOIN, asi que no hace falta que la empresa tenga un empleado para salir en los resultados) Respecto al del 12 de marzo: El 3a lo hice igual usando un CASE para la fecha, pero me comi el LEFT JOIN, esta bien eso. el 3b se me ocurrio hacerlo modificando la constraint de foreign key por ON DELETE CASCADE RE: [Gestion de Datos] 6 FINALES (2018-2019) ¡RESUELTOS! - nanohueso - 18-02-2020 19:44 Del final del 25 de septiembre 2019: El 3.b del trigger , no concuerdo con la resolucion. Igual pienso que es muy bardo lo que estan pidiendo y tampoco llegue a resolverlo todo. El trigger es unicamente UPDATE porque dice que al momento de crearse la carrera se insertan los caballos con puesto null. Entonces una vez que se sucede la carrera, se updatean los caballos para setearle el puesto. Ahora bien, para validar que los numeros sean consecutivos : - caso I ) el triggger se ejecuta y en el update se esta actualizando un unico registro. Este caso es dentro de todo facil. - caso II) el trigger se ejecuta y en el update se estan actualizando N registros. Esto lo complejiza porque tenes que validar que esa secuencia de puestos sean sucesivas. Y a su vez, hay que validar si esa secuencia en conjunto con las filas que estan en la tabla(-inserted) resultan en una secuencia consecutiva. Aca dejo una solución parcial. El caso II no me puse a codearlo porque en SQL no termino mas.
RE: [Gestion de Datos] 6 FINALES (2018-2019) ¡RESUELTOS! - chrisgel15 - 24-02-2020 12:52 manurocck como estas? El final practico del 26 de febrero de 2019, esta mal me parece. Adjunte una imagen para mostrar que tanto el IF como el ELSE estan haciendo lo mismo. [attachment=18860] En el ELSE solo se deberia arrojar una excepcion para avisar que la clave que se esta intentando insertar no existe. Por otro lado, CREO que tambien faltaria un trigger para DELETE sobre ciudades, borrando en cascada sobre la tabla PERSONAS. Saludos! |