25 Oct Introducción al modelo de datos en Velneo

Nos encargan un nuevo desarrollo abrimos vDevelop y, sin pensar en qué  modelo de datos vamos a utilizar, nos ponemos a escribir código como si no hubiese un mañana.

¿Has solucionado el problema que tienes que resolver?

¿Sabes ya qué relación hay entre las tablas?

Definición de modelo de datos

Según la Wikipedia:

Un modelo de datos es un lenguaje orientado a hablar de una base de datos, que permite describir las estructuras, las restricciones de integridad y las operaciones de manipulación de los datos.

Velneo nos proporciona una herramienta muy valiosa, y me atrevería a afirmar que muy poco utilizada, para describir las relaciones entre las tablas de nuestra base de datos: el objeto esquema.

Además el «lenguaje natural» también nos ayuda a definir estas relaciones entre las tablas de nuestro modelo de datos, sobre todo para saber si un dato es maestro o plural:

• Para definir los plurales de un maestro, utilizaremos la frase «los/las….. del……..»
  • Los albaranes del cliente
  • Las direcciones del contacto
  • Las líneas del pedido
• Para definir el maestro de los plurales, utilizaremos la frase contraria «el …. del….»
  • El cliente de la factura
  • El artículo de la línea de pedido
  • El proveedor de la compra.

¿Modelo de datos concreto o abstracto?

Jorge Hontoria hacía una interesante reflexión sobre cuál es el mejor modelo de datos. Como siempre digo… pues depende.

Antes de comenzar con el modelo de datos, tendremos que dar respuesta a una serie de preguntas.

Vamos a ver un ejemplo, centrándonos en las entidades de nuestra aplicación.

• ¿Nuestra aplicación va a servir de base para que otras apps la hereden? (ejemplo vErp)
• ¿Es una aplicación para un departamento de una empresa?
• ¿Vamos a crear un vertical?
• ¿Será una solución de tipo mixto?

Modelo de datos abstracto (vErp)

Esta es la estructura de las entidades en vErp:

• En la tabla de contactos, tenemos todos los posibles tipos de entidades que necesitemos: clientes, proveedores, transportistas, contactos, etc. etc. (en próximos artículos veremos esta estructura con mas detalle).
• En la tabla de direcciones (plural) tendremos las direcciones de cualquier tipo de contacto.
• Esta solución, como hemos dicho servirá de base para otras apps. Por lo tanto si la heredamos, en la solución de nivel superior tendremos que añadir los campos específicos de las entidades para ese módulo. Si creamos una solución de CRM que herede vErp, tendremos que extender la funcionalidad de la tabla «Contactos» en dicho módulo.

Modelo de datos concreto

Vamos a ver ahora un ejemplo del caso contrario:

• En este caso, he creado una tabla por cada uno de los tipos de entidad que voy a tener en mi aplicación.
  • Una tabla para Clientes
  • Una tabla para Vendedores
  • Una tabla para transportistas
  • Una tabla para Proveedores
• Después, en lugar de crear una tabla de direcciones por tipo de entidad, he creado una sola tabla que sea plural de todas las anteriores.
• Lo mismo para los ficheros adjuntos y los contactos.

En próximos artículos veremos estas estructuras en detalle.

¿Qué modelo de datos es el que utilizas tu? ¿Cuál te parece mas sencillo?

Déjame un comentario mas abajo y comenzamos el debate.