Justificar modelo Entrega 2

[dsepulveda3]

Estoy un poco confundido, en el enunciado de la entrega2 dice "Debes mostrar que tu modelo está en BCNF, o si prefieres en 3NF. Para ello debes listar las dependencias funcionales de cada tabla y mostrar que está todo normalizado." Me podrían mostrar un ejemplo de como mostrar que una tabla esta en BCNF y un ejemplo de como mostrar que esto está normalizado. Quede muy confundido con el video de la clase del profe.

De antemano muchas gracias.

[arpincheira]

Hola, en primer lugar te recomiendo ver las issues #105 , #133, #139 y la #149.

Luego, con el objetivo de enfocarme un poco más en tu pregunta, para mostrar que una tabla está normalizada lo ideal es que hagas lo siguiente:

• Mostrar las dependencias de los atributos internos de la tabla
• Justificar la elección de la llave primaria y explicar el motivo por el cual dices que es única
• Explicar el motivo por el cual el atributo X puede determinar todos los demás(muy ligado a lo que viene siendo el punto anterior)

Si cumples con todo esto, entonces estará muy bien justificada tu normalización. Recuerda que también debes decir si lo estás haciendo en BCNF o en 3NF

[dsepulveda3]

Mmm vale. Creo que es practica, me cuesta entenderlo. Otra cosa, en nuestra entrega1 pusimos esta tabla y nos dijeron que tuviéramos cuidado con la redundancia, pero no logro ver donde esta la redundancia. Lo único que hemos cambiado desde la entrega es que antes tenía un id_permisos que eliminamos.

[arpincheira]

Hola, en primer lugar no puedo revisar si lo que haces es correcto o no dado que sería darte una ventaja frente al resto de grupos, de todas formas aquí hay un punteo de cosas a considerar ahí:

• Ojo con el nombre, pusiera PERSIMOS envés de PERMISOS
• Recuerda que tus tablas no deberían tener valores nulos y que algunos permisos poseen algunos atributos que otros tipos de permisos no tienen.
• Cuidado con el uso de dos primary keys, pues genera mayor dificultad al momento de realizar consultas

[castrillini]

Hola, ¿por qué eliminaron id_permisos? Al existir la tabla Permisos, debiese tener primary key (así poder identificar a cada permiso), y generalmente el mejor atributo para ser primary key suele ser el id. Con respecto al feedback que les dieron en la entrega 1, les recomiendo que vuelvan a leer lo que dice el enunciado sobre los permisos. Si se dan cuenta hay un/os atributo/s que es/son específico/s para los permisos de los muelles y otro/s atributo/s que es/son específico/s para los permisos de los astilleros. Aquí les hago énfasis sobre lo que dijo mi compañero @arpincheira sobre tener cuidado con los NULLs.

[dsepulveda3]

Eliminamos id_permisos porque creímos que quizás por ahí iba lo de la redundancia (como teníamos id_barco y id_instalacion con eso podíamos identificar los permisos), pero ya los volví a agregar (los id_permisos). No entendí bien lo de los nulls, hay muchas cosas en la tabla permisos que nos dieron que no tienen información (a veces en descripcion_actividad y a veces en fecha_cierre), que debo hacer con estas líneas que poseen NULLS ?? ELiminarlas ?

[castrillini]

Recuerda que tus tablas no deberían tener valores nulos al momento de poblarlas. En el caso de tu grupo, si es que eliminas esas líneas estarías perdiendo información, esto no debiese ocurrir en ningún caso. Por lo que sugiero que apliques un cambio a tu tabla, (y capaz por ende a tu diagrama E/R). Piensa un poco con tu compañero y denle una vuelta qué cambio/s aplicar. Después, si tienen más dudas, sigan preguntando por este medio :)

[dsepulveda3]

Perfecto, ya entendí, en muelle solo nos interesa la descripción y en astillero las fechas! gracias ! Una ultima pregunta, tengo id_permiso, id_barco y id_instalacion en una tabla. Para saber si hay redundancia me gustaría saber lo siguiente ... si es que un barco va a la instalación de Antofagasta, por ejemplo, pero va 3 veces, necesita 3 permisos diferentes ?? o con 1 permiso ya puede ir todas las veces que quiera a descargar a Antofagasta ??