entre Desarrolladores

Recibe ayuda de expertos

Registrate y pregunta

Es gratis y fácil

Recibe respuestas

Respuestas, votos y comentarios

Vota y selecciona respuestas

Recibe puntos, vota y da la solución

Pregunta

1voto

Desarrollo de aplicación de base de datos

preguntó Jul 6, 2016
Software
440 Vistas
1 Respuestas
solucionada

Hola, voy hacer una aplicación para fin de proyecto donde gestionaré un taller mecánico que tendrá una página web y una aplicación java de escritorio que gestionará varias tablas y que el acceso estará controlado por roles que tendrán varios permisos, la cuestión es la siguiente los trabajos pueden estar realizados por varios trabajadores y tendrán varias piezas, por tanto, me convendría una relación muchos a muchos entre las tablas trabajador, trabajo y trabajo, piezas o si me vendría mejor realizar campos multivaluados. La administración de la aplicación la haré con hibernate.

preguntado por manuel26892 (1.360 puntos) Jul 6, 2016 en Software

1 Respuesta

3votos

Leonardo-Tadei Puntos227320

Hola @manuel26892,

Siempre, pero siempre, conviene tener las tablas al menos en 3ra Forma Normal.

Esto implica que al normalizar te aparecerán muchas tablas, pero te garantiza luego poder hacer cualquier operación sobre el conjunto de datos. Este abordaje es independiente de la tecnología usada para almacenar o acceder a los datos.

Tu descripción del problema es breve, pero así, a ojo, te harán falta tablas para:

Roles
Trabajadores
Piezas
Trabajos
TrabajosTrabajadores
TrabajosPiezas

Según la especificación también puedne hacer falta Clientes y Vehículos...

Luego, si te piden hacerlo en Java y usar Hibernate, deberías platear un Modelo en Objetos que resuelva el problema, en dónde posiblemente el Trabajo sea un Objeto que tenga una colección de Trabajadores y otra colección de Piezas...

En ese escenario usarás Hibernate, que es un Mapeador Objeto/Relacional, para darle las reglas de cómo se acceden a los datos sin sacribificar la estrubtura del Modelo.

Noo sé el enfoque de la materia, pero si fuera de Programación Orientada a Objetos y me dieras un software que usa Hibernate para implementar un DAO, yo no podría aprobarte, porque estarías modelando un esquema de ddatos "con olor a Objetos" en vez de aplicar los conceptos de la POO... es más complicado hacerlo bien, pero se aprende muchísimo!

respondido por Leonardo-Tadei (227.320 puntos) Jul 6, 2016

seleccionada por manuel26892 Jul 7, 2016

0voto

manuel26892 comentado Jul 6, 2016

Roles crearía un campo dentro de la tabla trabajador que mediante la introducción de los datos al hacer la consulta para verificar los datos consultaría el rol de este y así sabría que tipo de usuario estaría entrando, la aplicación de escritorio solo sería de uso para la empresa, no para el público. Tienes razón que me faltaría tablas pero ahora mismo estoy planteando el problema, haciendo diagramas y viendo como afrontarlo para después pasar al código. Respecto a hibernate y java usaría POO lógicamente y hql para la manipulación de datos.

comentado por manuel26892 (1.360 puntos) Jul 6, 2016

1voto

Leonardo-Tadei comentado Jul 6, 2016

Hola @manuel26892, lo de que los roles sean un campo implica que te perdés la posibilidad de descripción de los roles... poniendo una tabla de Roles y relacionándola vía su ID con el Trabajador, tenés mejor estructura y la misma funcionalidad con poco esfuerzo extra.

Sobre Hibernate, se puede usar de 2 maneras: una, que es conceptualmente incorrecta e hija de la Programación Estructurada, es usarlo apra hacer querys vía HDL.

La otra, la verdaderamente interesante, es plantear una solución Orientada a Objetos y pensar en las clases del Modelo para que todo funcione, y usar Hibernet para que haga el Mapeo Objeto/Relacional y persista los datos.

Por el problema del desajuste por impedancia de paradigmas entre la POO y el modelo relacional, usar HQL implica que no estás trabajando con POO, porque estarías ejecuntado querys, en vez de pedirle a Hibernate que hidrate y persista los Objetos de tu modelo.

Dicho de otra manera: en POO no podés derivar el código de las tablas, como decís, porque las entidades de un lado y del otro no pueden ser las mismas.

Bueno, no quiero darte la lata: al final tendrás que hacer lo que te pidan en la materia para aprobarla, pero en honor a la verdad, no puedo evitar decirte el conflicto metodológico que plantea lo que exponés en el comentario.

Saludos cordiales!

comentado por Leonardo-Tadei (227.320 puntos) Jul 6, 2016

0voto

manuel26892 comentado Jul 6, 2016

No es ninguna lata, ya que puedo aprender y así entender bien en que se basa cada cosa. Hasta ahora lo trabajado con hibernate tenía un mapeo/objeto donde a través de la creación de objetos y posteriormente el uso de un objeto Session e HibernateUtil conseguía crear los registros en tablas, no entiendo bien lo que dices en el caso de POO, ya que con el objeto ya estaría usando la POO por el hecho de crear distintas clases para los distintos objetos que serán las tuplas de las distintas tablas que formarán la base de datos.

comentado por manuel26892 (1.360 puntos) Jul 6, 2016

1voto

Leonardo-Tadei comentado Jul 6, 2016

Hola @manuel26892,

si bien por el lenguaje puede ser que estés usando Objetos, no es cierto que "...con el objeto ya estaría usando la POO por el hecho de crear distintas clases para los distintos objetos que serán las tuplas de las distintas tablas que formarán la base de datos.", porque en ese caso tenés un modelo relacional al que accedés mediante una semántica de Objetos.

El punto es que una tupla de una tabla no tiene nada que ver, como concepto, con la POO, salvo por supuesto en el caso de que estés escribiendo una interfaz para manejar tablas, en cuyo caso tu modelo tendrá una clase Base de Datos, una clase Tabla y una clase Registro, con lo que podrás modelar ua representación de Objetos de estos elementos.

Pero en este caso, lo que tenés que modelar es un Trabajador, una Pieza, un Trabajo, los que tendrán ciertas responsabilidades y que no tendrán todos sus atributos POJO, sino que el Trabajador tedrán un objeto Rol por agregación, el Trabajo tendrá una colección de Trabajadores y otra de Piezas, ambas por composición, etc, y estas clases no tienen, por el problema del desajuste por impedancia de paradigmas, ninguna representación posible directa en un esquema relacional.

Cuando se piensa en Objetos, jamás se piensa en tablas, y viceversa, porque ambos mundos no comparten ningún concepto. Es por esto que siempre hay que tener en mente que se clasifican Objetos por su comportamiento, y nunca por sus atributos.

Te dejo un enlace en dónde se discute un poco estrategias de mapeo e hidratación en Hibernate.

Ahora bien: en Java se puede perfectamente escribir un software que use registros como tuplas de objetos que no tengan ningún comportamiento, y que los algoritmos con las reglas de funcionamiento estén escritos en las interfaces en en los métodos de "guardar"... pero en este caso, no es correcto decir que estamos trabajando con Programación Orientada a Objetos.

Con ambos enfoques se puede escribir un software que funcione bien, lo importante, creo yo, es no confundirse con lo que se está haciendo. Así como ir al mercado en un Fórmula 1 no me convierte en un piloto de carreras, usar Java y Hibernate per se no implica estar haciendo POO.

Saludos cordiales!

comentado por Leonardo-Tadei (227.320 puntos) Jul 6, 2016