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.
