08 Nov Modelo de datos abstracto
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.
En este artículo nos vamos a centrar en el «modelo de datos abstracto»
Si te has perdido el primer post de esta serie, te recomiendo leerlo antes de continuar…
¿Seguro que lo has leído ya?
Pues continuamos.
¿Qué es un modelo de datos abstracto?
Cada una de las tablas de nuestra aplicación se divide en:
- Registros: Tipo de información que vamos a almacenar en nuestra tabla
- Campos: Propiedades del mismo tipo de cada uno de los registros que forman un registro
- Índices: Estructura de datos que mejora la velocidad de las operaciones, por medio de identificador único de cada fila de una tabla, permitiendo un rápido acceso a los registros.
Aplicando la «teoría del kiwi«, que mas da que sean clientes, que proveedores, que contactos, que vendedores, que …. Al final todos estos tipos (registros) tendrán unas propiedades (campos) comunes.
Por lo tanto podemos crear una tabla común («Entidades») que englobe a todos ellos.
Puestos a abstraer…
- ¿Qué diferencia hay entre las líneas de un presupuesto y las líneas de un pedido?
- ¿Qué diferencia hay entre las líneas de un albarán de venta y las líneas de una factura de venta?
- ¿Qué diferencia hay entre las líneas de un albarán de compra y una factura de compra?
- Y ¿entre un cobro y un pago?
Si os fijáis, no me he referido en ningún momento a los datos que guardamos (registros) si no a las propiedades que tienen (campos).
Ventajas e inconvenientes de este modelo de datos
Como casi todo es relativo… este modelo de datos también tiene sus ventajas y sus inconvenientes. Vamos a verlas tomando como ejemplo la tabla de «Entidades«:
Ventajas del modelo de datos abstracto
Evitamos tener duplicada la información. Si, por ejemplo, una entidad es de tipo cliente y además nos vende, no tendremos que volver a dar de alta toda su información para que también sea proveedor. Tendremos que ser nosotros como programadores los que dotemos a las aplicaciones de los mecanismos para diferenciar los distintos tipos de registros que guardaremos en la tabla.
Creamos campos en el proyecto de datos una sola vez. Al tener una sola tabla (por ejemplo de entidades) si añadimos un nuevo campo, ya estará accesible para los distintos tipos que tengamos en la tabla (por ejemplo un nuevo teléfono).
Creamos objetos en el proyecto de aplicación una sola vez. Es probable que tengamos el mismo formulario de edición para todos los tipos de entidad. Por lo tanto si añadimos un nuevo campo (el ejemplo de un nuevo teléfono) , con crearlo en un único formulario bastará.
Inconvenientes del modelo de datos abstracto
Creación de mas índices en la tabla. Por lo tanto las reindexaciones consumirán mas tiempo. Al tener todas las entidades en la misma tabla, a nivel de datos las tendremos que tener diferenciadas para cuando nos pidan la información.
Mas registros en la misma tabla. Al tener los datos del mismo tipo almacenados en la misma tabla, habrá mas registros por tabla. En entidades no resulta problemático pero ¿y en líneas de documentos?.
Peligro de superar la longitud máxima recomendable del registro. La longitud recomendada para los registros está fijada en 4000 bytes... aunque siempre podemos utilizar tablas de extensión.
Consideraciones a tener en cuenta a nivel de tabla
Como hemos dicho anteriormente,
en este modelo de datos, debemos ser nosotros como programadores los que deberemos crear los mecanismos para diferenciar la información que guardamos en las distintas tablas.
Siguiendo con el ejemplo de la tabla de «Entidades«, vamos a ver como podemos crear estos mecanismos.
Campos a crear en la tabla
Para diferenciar los distintos tipos de entidad que guardaremos en la tabla, tendremos que crear un campo booleano por cada uno de los tipos. Esta es la estructura de campos para los tipos de entidad en vErp:
Además a nivel de tabla, también tendremos que encargarnos de crear los distintos índices para que el usuario pueda obtener los datos por tipos de entidad:
En este caso hemos creado un índice por id, nombre, palabras y trozos por cada uno de los distintos tipos de entidad que vayamos a tener en nuestra base de datos.
Consideraciones a tener en cuenta a nivel de objetos de interfaz
Ya que estamos…. ¿por qué no facilitarles la vida a nuestros usuarios?
Vamos a proporcionarles las herramientas para que puedan obtener la información por los distintos tipos de entidad que hayan guardado.
A nivel de proyecto de aplicación, esto lo conseguimos por medio de los localizadores:
En este caso hemos creado un localizador por cada uno de los tipos de entidad que tenemos y en cada uno de ellos, le hemos añadido los índices correspondientes creados anteriormente. De este modo podemos añadir acciones para que el usuario además de obtener los datos generales de todas las entidades, pueda localizar los datos de un tipo concreto.
¿Se te ocurre alguna ventaja o algún inconveniente mas de este modelo de datos?
Déjame un comentario mas abajo y comenzamos el debate.
No Comments