Differences

This shows you the differences between two versions of the page.

--- proyecto:propuesta_inicial [2023/04/28 23:32] – [Propuesta de Proyecto] ahogan
+++ proyecto:propuesta_inicial [2024/04/25 21:23] (current) – ahogan
@@ Line 1: / Line 1: @@
-======Propuesta de Proyecto======
+======Propuesta de Datos/Proyecto======
 Primero, cada equipo debe seleccionar algunos datos para su proyecto. Algunas consideraciones:
   * El proyecto será más fácil si los datos ya están en un formato de tablas (como, p.ej., CSV, TSV, etc.).
   * **El esquema final debería tener al menos tres tablas y un buen diseño relacional** (p.ej., estar en BCNF) independientemente del formato de los datos crudos. Está bien si los datos crudos tienen menos de tres tablas si, a normalizar los datos, resulta en tres tablas apropiadas.
-  * Las consultas finales de la aplicación deberían demostrar una mezcla de operadores de SQL, es decir, joins, consultas anidadas, agregación, funciones de ventana, etc. Los datos que ustedes elijan deben tener la "complejidad" suficiente para permitir consultas interesantes y no triviales. **Es importante que se pueden hacer joins entre las tres tablas finales.** No sirven, por ejemplo, tres tablas del mismo contenido dividido por alguna categoría (por ejemplo, año, género, etc.) pues en el esquema final estas tablas deberían ser juntadas en una tabla con una nueva columna para la categoría; estas tablas no permiten joins.
+  * Las consultas finales de la aplicación deberían demostrar una mezcla de operadores de SQL, es decir, joins, consultas anidadas, agregación, funciones de ventana, etc. Los datos que ustedes elijan deben tener la "complejidad" suficiente para permitir consultas interesantes y no triviales. **Es importante que se pueden hacer joins entre las tres tablas finales.**
+  * Muchas veces los archivos crudos no van a corresponder uno-a-uno a tablas normalizadas. No sirven, por ejemplo, tres tablas del mismo contenido dividido por alguna categoría (por ejemplo, año, género, etc.) pues en el esquema final estas tablas deberían ser juntadas en una tabla con una nueva columna para la categoría.
   * Los datos deben tener una escala razonable, es decir, al menos 10000 tuplas en total (sumando el número de tuplas de cada tabla) pero preferiblemente más.
   * Por otro lado, sería una buena idea trabajar con menos de un millón de tuplas para evitar problemas de escala que pueden retrasar el proyecto. Cada máquina virtual tiene aprox. 2.7GB de espacio libre en el disco, y aprox. 350MB de RAM total; estos recursos son más que suficientes para un conjunto de datos pequeño, pero no para un conjunto de datos grande (p.ej., más de un millón de tuplas). En el caso de tener un conjunto grande, se puede considerar trabajar con un sub-conjunto de los datos.
+  * No se pueden usar datos ya usados en el contexto de un lab, ni datos muy similares.
 La selección de datos es parte del proyecto, es decir que cada grupo debería encontrar sus propios datos. La siguiente lista da algunos ejemplos de fuentes de datos:
@@ Line 36: / Line 38: @@
     * Distribución/valores típicos de atributos relevantes
     * Dominio para cada atributo (string, int, etc.); indicar si la columna puede tener múltiples valores; indicar porcentaje de nulos
-  * Para el caso de elegir análisis de datos, agregar al menos 6 preguntas a contestar con el análisis. Las preguntas deben tratar de encontrar tendencias en los datos, predecir algún comportamiento futuro en base a estas tendencias, etc.
+  * Para el caso de elegir análisis de datos, agregar al menos 6 preguntas a contestar con el análisis (por ejemplo, //¿Las películas más recientes tienden a tener una mayor proporción de actrices?//). Las preguntas deben tratar de encontrar tendencias en los datos, predecir algún comportamiento futuro en base a estas tendencias, etc. Cada pregunta debería necesitar de una o más consultas para contestar. No es necesario llegar a una respuesta concluyente a la pregunta, pero se espera al menos poder lograr conclusiones parciales y observaciones interesantes al respecto.
-  * Para el caso de elegir la aplicación web, describir las funcionalidades posibles de la aplicación
+  * Para el caso de elegir la aplicación web, describir las funcionalidades posibles de la aplicación. La aplicación debería permitirle al usuario contestar 3 tipos de consultas con parámetros, donde el usuario puede reemplazar cada parámetro con un valor particular mediante la aplicación web (por ejemplo, "//¿En qué películas ha participado [actor]?//" donde //[actor]// es un parámetro que el usuario entra mediante la aplicación web).
 Esta propuesta puede ser **aprobada**, **aprobada con cambios menores**, o **rechazada**. En caso de ser rechazada, se deberá reformular el proyecto, tomando en cuenta los comentarios asociados de quien revise la propuesta.