IIC2413 / Syllabus-2023-1

76 stars 24 forks source link

Entrega 2: Penalización columnas redundantes y múltiples llaves minimales #120

Open KainaBGR opened 1 year ago

KainaBGR commented 1 year ago

Hola :) quisiera saber si es que existirá alguna penalización al evaluar nuestros esquemas por la existencia de columnas redundantes. Lo pregunto porque en los archivos .csv que nos entregaron en los datos oficiales, existen columnas con la misma información. Por ejemplo, para las licencias, el id que toma la licencia es el id correspondiente al id_personal, por lo que ambas columnas quedan iguales, o también para los despachos, id_despacho = id_compra. Con esto en consideración ¿debemos elegir una columna y borrar la otra? o ¿debemos dejar ambas columnas en las tablas?. Otra duda bien parecida es respecto a la existencia de más de una llave minimal ¿cada tabla debe tener solo una llave minimal?. En la tabla vehículos del .csv tanto el id como la patente pueden usarse como llave primaria y en la retroalimentación de la entrega 1 indicaron que era redundante tener id_vehículo si ya está la patente. Pero en la tabla repartidores se usa el id_vehiculo en lugar de patente_vehiculo, por lo que no podríamos deshacernos de la columna id sin antes trabajar harto los datos haciendo join y luego proyecciones en sql. Para la tabla clientes y la tabla repartidores sucede algo similar con id y rut - en la tabla repartidores, además, al sacar los duplicados, el nombre también queda como llave- . Entonces ¿podemos dejar tablas con más de una llave minimal cuando una de ellas contiene información importante como el rut o la patente y otra de ellas ha sido utilizada como llave foránea en otras tablas? Gracias.

NicolasOlmosQuiroga commented 1 year ago

¡Hola!, en el esquema, efectivamente se descontaria por tener datos redundantes, pero toma en consideracion que no se espera que ustedes solo hagan las tablas para cada uno de los archivos, si no que hagan hartas tablas de manera que cada una solo tenga lo minimo necesario para que sea util, y otras que relacionen las entidades entre si.

Sobre si cada tabla debe tener solo una llave minimal o candidata, recuerda que el esquema tiene que estar en BCNF o 3NF, y ambas tienen en común el requerimiento de que cada atributo dependa completamente de la llave primaria de la tabla.

Por ejemplo, en la tabla "vehículos" del archivo CSV, si se elige la "patente" como llave primaria y se mantiene el "id" como una llave candidata, se debe asegurar que cada atributo dependa completamente de la "patente" o del "id". Pero como dices, si hay atributos que dependen de ambas llaves, entonces se debe crear una tabla adicional para almacenar esa información y evitar la redundancia, y asi se sigue el formato BCNF o 3NF. Un detalle importante es que el formato 3NF permite un poco mas de redundancia, pero tendrias que investigar mas y dejar una buena explicacion en el sistema del por que es si o si necesario tener redundancia, pero no lo recomiendo (y se podria bajar la nota).

Saludos.