Esquemas E2

[rieg-ec]

Hola, para los esquemas se puede hacer uso de funcionalidades como check? o eso lo ponemos después nosotros al crear las tablas en postgres si queremos?

[arpincheira]

Hola, para que querrías utilizar check? No sería mejor realizar un buen preprocesamiento de datos antes de poner constrains como esas al interior de su base de datos.

Con respecto a si ponerlo en el esquema, si decides ponerlo no es estrictamente necesario, pero te recomendaría anotarlo y justificar el motivo por el cual lo usaste.

Espero haber contestado tu pregunta

[rieg-ec]

Para la entidad instalaciones tenemos un atributo 'tipo' que solo puede ser 'astillero' o 'muelle', por lo que me parece buena idea poner ese constraint en la base de datos (si después no seguiremos ocupando el mismo esquema no tiene mucho sentido pues no hay input de datos para esta entrega, pero entiendo que más adelante si habran)

[arpincheira]

De hecho, si lo pones así está bastante bien, aunque tengo la duda de cómo accederías a los atributos de las instalaciones(aquellos que ambos tipos comparten) si es que hacen una consulta que sea independiente del tipo de instalación que haya.

En ese caso no sería mejor modelar algo como.... una herencia y tener tres tablas(una de instalación y una por cada tipo de instalación), en las que, pese a que 2 de ellas sólo posean primary y foreing key por ahora, permita la adición de atributos(columnas) particulares por tipo o generales?. Así además evitarías la duplicidad de los datos y evitaría que hubieran problemas con los permisos(dado que estos si cambian según el tipo de instalación).

Se que para lo último que dije hay que hacer un poco más de preprocesamiento, pero podría ser una alternativa altamente viable en el contexto de un trabajo a futuro, así que lo dejó aquí para que se lo planteen con tu grupo.

[rieg-ec]

Respecto a lo primero, no creo que haya problema pues en caso de no ser importante el tipo de instalación se puede omitir esa columna al hacer la consulta. Claramente si después se irán agregando datos a las instalaciones tiene sentido separarlas altiro, asi que tomaré tu consejo. Pero me queda la duda de si conviene planear a futuro detalles como esos y complejizar el esquema, cuando no debiese ser muy dificil pasar de una tabla para los dos tipos a una tabla para atributos comunes + 1 para cada tipo más adelante cuando se necesite?

[arpincheira]

Hola, lamento la demora, la idea es que de todas formas piensen a futuro, pues cambiar los esquemas de las bases de datos en la vida real siempre va a implicar gastos. Además, por lo general, las aplicaciones en si dependen completamente en como se estructuran los datos, dado que interactúan con estos constantemente.

Es por esto que yo te diría que no te preocuparas por la complejidad del esquema(especialmente considerando que eres de grupo par) y que te enfocaras más en respetar las normas de normalización y las buenas prácticas de la creación de bases de datos pensando que lo ideal es que no debas cambiar la estructura de tu base de datos a futuro.

Además, como hint podría decir que el esquema de los grupos pares es más complejo especialmente por los permisos y las instalaciones, así que mucho ojo ahí, en una de esas puede suceder que exista un tipo de relación especial que debas considerar en el diagrama E/R que se repita en estas dos partes.(no puedo decir mucho más dado que es una gran pista).

[rieg-ec]

Ok, lo tendremos en cuenta. Gracias por la ayuda!