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.
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:
No todos los conjuntos de datos mencionados en estas fuentes son apropiados para el proyecto con respecto a las consideraciones previamente discutidas; p.ej., hay conjuntos de datos que no tienen un formato apropiado, etc. No hay que usar todos los datos disponibles en un conjunto de datos; se pueden seleccionar algunas tablas, columnas, filas, etc. También se pueden seleccionar datos de otra fuente no listada aquí, o datos personales (por ejemplo, datos de ventas, datos de sensores, etc.). Se pueden combinar dos o más fuentes, siempre y cuando las tablas satisfagan los criterios mencionados acá.
Cada grupo debe indicar (en el hilo del foro habilitado para este propósito) cuál conjunto de datos desean ocupar. Esto es para que cada grupo trabaje en un conjunto de datos distinto. Hay que publicar el número del grupo, un URL (o una descripción de los datos de ser datos privados), y el título del dataset (para facilitar detectar duplicados).
Enviar propuesta de proyecto (en PDF) que debe contener:
Título del proyecto
Número de grupo
Nombres de integrantes
Descripción del conjunto de datos (con enlace, de estar disponible; indicar qué datos se utilizarán)
Descripción y motivación del problema
Opción elegida entre aplicación web o reporte de análisis de datos. La idea del análisis debe ser responder algunas preguntas de investigación o de interés general utilizando consultas complejas sobre los datos.
Exploración inicial de los datos:
Cantidad de filas por tabla
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 (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. 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.