Representación de asociaciones en bases de datos

[Ernesto Revilla]

Hola de nuevo,

al ver la manera de persistir las asociaciones (incluídas agregación y
composición) se me ocurren 2 posibilidades para crear el diseño de las
tablas para RDBMS.

Suponed que sólo tenemos relaciones de 0..1:* y 1:*   (siendo *, 1..* ó
0..*), ya que una relación de n:m puede descomponerse en dos relaciones,
0..1:n y 0..1:m, podemos

1. incluir la clave de objeto en la parte muchos, (tipo poner el código del
albarán en las líneas de albarán, o el código de Equipo de Trabajo al
Empleado).

2. Crear una tabla de relación de objetos ('RelObjs') con las columnas OID1,
OID2, CDG.Asociación. Lo que significa que el objetos con OID 1 está
relacionado con OID 2 por el motivo que indica la asociación (Persona 1 está
relacionada con Albarán 10, por ser cliente).

Las consecuencias son:
para 1. No hay tabla de objetos que podría crecer mucho. El acceso es más
directo.
Cada vez que a alguién se ocurre cambiar una cardinalidad de 1 ó 0..1 a más
de o aparece una nueva asociación, hay que rediseñar el esquema de la base
de datos.

para 2. Cada vez que tengamos que acceder a los atributos de una clase
asociada (Albaran.Cliente.Nombre) hay que pasar por la tabla intermedia
RelObjs para posteriormente cargar el otro objeto (ralentiza). Los cambios
de cardinalidad, así como modificación de asociaciones (agregación, borrados
y otros) no afectan de ninguna manera el esquema de la base de datos. Se
podrían agregar asociaciones dinámicamente.

¿Qué pensáis es más importante, velocidad o flexibidad del esquema de base
de datos (¿reduce mantenimiento?)?

No sé todavía en qué factor va a ralentizar. Intentaremos implementar los
dos esquemas y hacer comparaciones.

Saludos, Erny