Spring Vaadin Hibernate Tutorial > 3. Estructura de la Base de Datos

Escrito por 18 abril, 2016Desarrollo de software
Tutorial Spring Vaadin HIbernate, Estructura de la base de datos

En este tercer paso del tutorial Spring Vaadin Hibernate vamos a crear las entidades necesarias para replicar el modelo relacional que, tal y como comentamos en el anterior post, viene de una base de datos creada en memoria. La estructura de esta base de datos es la siguiente:

1

Hemos subido al repositorio la base de datos en memoria (se puede localizar dentro de la carpeta database). Para poder utilizarla simplemente tenemos que ejecutar el archivo start-petshop-database-server.bat. Con esto ya podemos realizar cualquier operación en ella desde la aplicación que estamos creando.

Si lo que quieres es probarla, hemos incluido un cliente para tal fin. Es necesario ejecutar el archivo start-petshop-database-client.bat y definir las siguientes propiedades de conexión, que más adelante definiremos también en nuestro proyecto:

  • Type: HSQL Database Engine In-Memory
  • Driver: org.hsqldb.jdbcDriver
  • URL: jdbc:hsqldb:hsql://localhost:9001/petshop
  • User: sa

Creación de entidades

Para representar la estructura de base de datos presentada anteriormente, crearemos las siguientes entidades en nuestro módulo persistence, el cual se encargará de toda la parte de persistencia y acceso a datos.

estructuraEntities

Como podemos observar, creamos una entidad por cada tabla representada en base de datos, añadiendo una clase abstracta (AbstractEntity, de la cual heredarán todas nuestras entidades). Para la tabla TAG_ITEM no hemos añadido ninguna entidad, algo que ya explicaremos en pasos posteriores a esta entrada.

Creación de entidad

Vamos a ver un ejemplo de la creación de una entidad (Address), siguiendo el modelo anterior. Como vimos en el paso anterior de este tutorial, vamos a utilizar JPA e Hibernate para nuestro modelo de persistencia.

@Entity: con esta anotación indicamos a JPA que se trata de una entidad que se almacena en base de datos.

@Table: con esta anotación indicamos a JPA que la tabla a la que apunta esta entidad será la que definamos en name. En el anterior ejemplo se ve como la entidad Address apunta a la tabla de base de datos ADDRESS. Es importante mantener una coherencia entre el nombre de las tablas y el nombre de las clases definidas, tal y como hemos definido nosotros, donde la tabla ADDRESS en base de datos será representada por la clase Address en código. De esta manera el código será más legible para cualquier desarrollador ajeno al código.

Definiendo atributos de la entidad

En el paso anterior hemos visto la creación de una entidad, ahora veremos como definir sus atributos, los cuales nos pueden indicar: relaciones entre tablas, tipos de datos, si son autogenerados, etc. Vamos a ver como se define cada tipo de atributo que nos podemos encontrar normalmente:

  • Clave primaria de la tabla

  1. @ID: este parámetro nos indica que éste atributo que vamos a definir es la clave primaria de nuestra tabla.
  2. @SequenceGenerator: indicamos que nuestro atributo addressId será generado siguiendo la secuencia descrita en address_sequence , la cual comienza en initialValue y se incrementa el número especificado en allocationSize. Se genera siguiendo la estrategia especificada en strategy de @GeneratedValue (las diferentes estrategias de generación pueden consultarse en http://www.objectdb.com/java/jpa/entity/generated).
  3. @Column: indicando que este atributo hace referencia a la columna de base de datos descrita en name, en este caso ADDRESSID.
  • Relaciones con otras tablas

  1. @OneToMany: con esta anotación indicamos que existe una relación de uno a muchos entre dos tablas (Address e Item), la cual está «conectada» a través del atributo especificado en mappedBy. A su vez, este atributo tiene que estar definido en la tabla con la que queremos conectar, en nuestro caso Item, de manera inversa. Es decir, en la entidad Item deberá de existir una relación en «sentido contrario» @ManyToOne definida de la siguiente manera:
  2. Nos encontramos también con la anotación fetch, que nos indica la manera en que serán obtenidos los datos «asociados a esta entidad» desde base de datos. ¿Qué quiere decir esto? Que si el atributo FetchType es LAZY no se traerán de primeras los Items asociados a este Address, sino que se traerán bajo petición. En cambio, si FetchType es EAGER se traerán todos los Items asociados a este Address desde el principio.

    Por ejemplo, si sólo vamos a visualizar datos relacionados con Address es probable que no vayamos a necesitar los datos de sus Items, por lo que lo anotamos como LAZY. En cambio, podríamos querer ver sus Items asociados directamente en la misma pantalla definiendo la relación como EAGER, trayéndonos los Items al cargar la entidad Address.

    Por ello hay que tener cuidado con el atributo FetchType, dado que si todas las entidades de nuestra base de datos se encuentran conectadas entre ellas y todas las relaciones tienen FetchType tipo EAGER, puede ocurrir que una única petición nos traiga toda la base de datos.

  3. También podemos observar el modificador cascade, el cual nos permite «propagar» los cambios entre entidades que tengan relaciones entre sí (como por ejemplo, ManyToOne o OneToMany). De esta manera todos los cambios realizados en el objeto Address se verán reflejados en los Items asociados. Los tipos de cascade podemos consultarlos en http://vladmihalcea.com/2015/03/05/a-beginners-guide-to-jpa-and-hibernate-cascade-types/.
  • Un atributo normal de la tabla

  1. @Size: nos indica el tamaño máximo del campo (utilizado para cadenas de texto, tipo String). Dado que el tipo de dato en base de datos es un VARCHAR el mapeo se hace a un String, pero varía dependiendo del tipo de dato almacenado en base de datos. Para profundizar más en la conversión de tipos entre SQL y Java puede consultarse la página http://www.service-architecture.com/articles/database/mapping_sql_and_java_data_types.html.

    Si se quiere definir el formato de un atributo tipo número, se puede usar la anotación @Digits para tal fin, indicando el tamaño de la parte entera y de la parte decimal. Por ejemplo para un tipo Float podría definirse como:

  2. @NotBlank: el valor no puede ser nulo y el tamaño (eliminando espacios en blanco al principio y al final de la cadena de texto) debe ser mayor a 0.

Siguiendo el ejemplo, ya solo nos faltaría crear todas y cada una de las entidades que necesitamos en nuestro modelo (ver imagen del inicio de la entrada) y autogenerar todos los métodos getter/setter para poder trabajar con ellos.

Como se puede observar, realmente no es complejo replicar una base de datos en código, únicamente es algo tedioso porque hay que definir cada uno de los atributos de nuestras tablas de base de datos, relaciones y anotaciones.

Join the discussion 2 comentarios

Dejar un comentario

Uso de cookies

Este sitio web utiliza cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies.

ACEPTAR
Aviso de cookies