Modelado de datos: ¿los límites del modelo entidad-relación?
Atributos Los campos del modelo entidad-relacion no siempre representan información sobre el modelo de negocio que están tratando. A menudo, son campos auxiliares que ayudan a la implementación del modelo dentro de la base de datos. Los atributos del modelo Clase-Colección representan siempre información sobre el modelo de negocio. Si es necesario algún campo auxiliar en alguna tabla, es completamente transparente tanto para el usuario como para el analista (y en la mayoría de los casos para el desarrollador). Por otro lado, además de los tipos de datos clásicos en una base de datos (carácter, numérico, fecha, etc.) en este modelado se incluyen otros dos tipos de atributos. En general, en el modelo Clase-Colección existen tres tipos de atributos: Atributos de tipo valor, de tipo objeto y de tipo colección. La incorporación más importante del modelo clase-colección es la asociación de los atributos tipo objeto y tipo colección en parejas. Como decíamos antes, en el modelo entidad-relación las relaciones se ven siempre desde un único punto de vista a la hora de modelizar. Como en el mundo real, las relaciones en un modelo de negocio siempre tienen dos puntos de vista, y nuestro modelo de datos intenta representar eso. Una relación se representa por un par de atributos, enlazados entre sí. De esta forma, no hay que pensar en estructuras predefinidas y ver cuál se adapta mejor, sino analizar la realidad y representarla de la mejor forma posible. Más adelante lo veremos con más detalle. A continuación se hace una pequeña introducción a los tres tipos de atributos:Todos los que programamos sistemas de información para empresas tenemos que tener conocimientos de modelado de datos en bases de datos relacionales. Bases de datos y SQL son habilidades imprescindibles para nuestro trabajo.
Desde siempre ha habido cosas que no me han acabado de convencer del modelo entidad-relación, o mejor dicho, de la implementación que los sistemas de bases de datos relaciones hacen del mismo. Hay algunas cosas que no me han parecido naturales, y hemos desarrollado una teoría que, al menos a nosotros, nos ha servido los últimos 5 años para los proyectos que hemos desarrollado.
Cosas raras en el modelo entidad-relación (con todo respeto)
Nuestra teoría (la llamamos, a falta de un término mejor, el modelo objeto-colección) se basa dos ideas, aparentemente sin nada que ver una con la otra:
Primero, la programación orientada a objetos (estaba claro, habiendo en el título la palabra “objeto”). Segundo, la idea de que las relaciones siempre se pueden ver, de forma distinta, desde el punto de vista de las dos entidades involucradas…
En la implementación de una relación 1 a N entre dos tablas, la relación se establece creando una clave ajena que ‘apunta’ a la tabla ‘madre’. Sin acceder a los metadatos de la base, no se puede saber, mirando una tabla, cuántas tablas están relacionadas con ella. Es como si la relación sólo se estuviera viendo desde el lado de la tabla ‘hija’, sólo desde un punto de vista. No nos ‘suena’ bien.
Otra cosa es la implementación de las relaciones M..N. Implica la existencia de una tabla intermedia en la que se almacenan las duplas de claves ajenas que representan la relación. En teoría (nos enseñaban en la facultad), cada entidad tiene que tener una representación física en el sistema que estamos modelizando, y durante las clases se pasaba de puntillas por el hecho de que estas tablas eran ‘auxiliares’, que ayudaban a montar la relación pero no tenían existencia como entidades. Hmpf!
Lo que hacemos
Proponemos una forma similar, pero ligeramente diferente, de entender las relaciones, y una forma de implementarla utilizando los sistemas de base de datos relacionales existentes actualmente.
El modelo entidad-relación y las bases de datos relacionales están intimamente relacionados (como sus nombres indican) y todas las bases de datos modernas están orientadas en este sentido. Existen otras aproximaciones, como las bases de datos orientadas a objetos, pero su implantación en sistemas en producción es más bien escasa. Por otro lado, con esta técnica y un poco de imaginación se puede modelizar cualquier negocio que pueda presentarse. Por tanto, parece la metodología óptima para el desarrollo de aplicaciones de gestión. Sin embargo, presenta una serie de dificultades para la modelización.
Principalmente, la implementación de las relaciones, sobre todo las 1 a N , se basa en una representación desde un sólo punto de vista. La relación “todas las facturas tienen un cliente” también puede enunciarse “un cliente tiene n facturas”. A la hora de modelizar, esta dualidad de la representación puede crear problemas de identificación que afecten a la calidad del modelo creado.
Por otro lado, esta forma de trabajo “descubre” demasiado de la implementación al diseñador. Para hacer un buen diseño de base de datos el analista debe conocer hasta cierto punto el diseño de las bases de datos relacionales, lo que quizá sean demasiados requerimientos para alguien que debe dedicarse a modelizar procesos de negocio.
El modelo Objeto-Colección
El modelo se basa actualmente en una implementación similar del mismo, pero presentando las ideas de una forma diferente, extraída de la orientación a objetos, con el objetivo de facilitar tanto el diseño de los modelos de datos como su mantenimiento. En este modelo de datos se introducen varios cambios sobre el modelo entidad-relación:
Clases
El concepto de tabla se altera ligeramente en este modelo, y se asocia con el concepto de clase de la orientación a objetos. Una clase es una estructura que contiene tanto los datos como los procesos que se aplican a los mismos, y lo mismo se trata de hacer aquí. Además de una serie de atributos (que sustituyen a los campos, y que analizaremos posteriormente), una clase también posee una serie de métodos (o procesos que se aplican sobre sus datos) y consultas, o informes que presentan al usuario información sobre sus datos. Por otro lado, el modelo entidad-relación identifica una entidad con una tabla. En el modelo Clase-Colección no es necesariamente así. De hecho, la implementación actual, que no es la única y que puede cambiar, presenta cada clase como dos tablas y una secuencia.
Atributos
Los campos del modelo entidad-relacion no siempre representan información sobre el modelo de negocio que están tratando. A menudo, son campos auxiliares que ayudan a la implementación del modelo dentro de la base de datos. Los atributos del modelo Clase-Colección representan siempre información sobre el modelo de negocio. Si es necesario algún campo auxiliar en alguna tabla, es completamente transparente tanto para el usuario como para el analista (y en la mayoría de los casos para el desarrollador). Por otro lado, además de los tipos de datos clásicos en una base de datos (carácter, numérico, fecha, etc.) en este modelado se incluyen otros dos tipos de atributos. En general, en el modelo Clase-Colección existen tres tipos de atributos: Atributos de tipo valor, de tipo objeto y de tipo colección. La incorporación más importante del modelo clase-colección es la asociación de los atributos tipo objeto y tipo colección en parejas. Como decíamos antes, en el modelo entidad-relación las relaciones se ven siempre desde un único punto de vista a la hora de modelizar. Como en el mundo real, las relaciones en un modelo de negocio siempre tienen dos puntos de vista, y nuestro modelo de datos intenta representar eso. Una relación se representa por un par de atributos, enlazados entre sí. De esta forma, no hay que pensar en estructuras predefinidas y ver cuál se adapta mejor, sino analizar la realidad y representarla de la mejor forma posible. Más adelante lo veremos con más detalle. A continuación se hace una pequeña introducción a los tres tipos de atributos:
Tipo valor
Los atributos tipo valor se asocian con datos que vaya a escribir el usuario o información real del modelo de negocio. Dentro de los atributos tipo valor existen todos los tipos de datos especificados anteriomente (carácter, etc.). Por ejemplo, atributos tipo valor son el nombre de un cliente, su NIF, el número de una factura o la fecha de creación de una factura.
Tipo objeto
Los atributos tipo objeto tienen su origen en los campos de clave ajena que se utilizan en el modelo entidad- relación para implementar las relaciones. Son un enlace en una clase a un objeto de otra, de forma que se integra en la información de la clase como un atributo más, y se comporta como cualquier otro.
Tipo colección
Los atributos tipo colección representan un conjunto de objetos de otra clase, y son la incorporación de este tipo de modelado. Anteriormente, analizando aisladamente la clase Clientes es imposible saber que está relacionada con facturas. De esta forma, la ingeniería inversa de los modelos de datos se complica enormemente. Actualmente, la clase clientes tiene un atributo tipo colección llamado “Facturas”, de forma que es muy fácil identificar todas las relaciones que la clase clientes tiene con otras clases. Además, la relación se puede ver desde los dos lados. La factura tiene un cliente y el cliente tiene un conjunto de facturas.
Implementación de las relaciones
Al crear un atributo tipo objeto o colección, el sistema solicita al usuario la creación del atributo enlazado de la clase de destino, así se asegura la integridad del sistema. Después a la hora de utilizar dichas relaciones, siempre se tratarán en parejas de forma transparente para el usuario. Por ejemplo, si se modifica el atributo “Cliente” de un objeto de la clase Facturas, y se cambia su enlace, el sistema automáticamente actualizará la colección de “Facturas” de los clientes implicados: Sacará la factura del cliente antiguo y la meterá en el nuevo. Este proceso ayuda bastante a la modelización de los datos, creandose así varios tipos de relaciones: Relaciones Objeto-Objeto En general no son recomendables, porque representan relaciones 1 a 1 que son erróneas normalmente, pero en algunas ocasiones son necesarias. Por ejemplo, la implementación de los pares de atributos (atributo y atributo enlazado), se hace a través de una relación objeto-objeto Relaciones Objeto-Colección Representan las relaciones 1 a N del modelo entidad-relación, con la salvedad que ambas clases incluyen una relación, los que ayuda a la comprensión del modelo de datos, a su mantenimiento y a la visualización por parte del usario. Relaciones Colección-Colección Representan las relaciones M a N del modelo entidad-relación, con la diferencia que no existen tablas intermedias o auxiliares, y resulta mucho más visual para todas las partes implicadas.
