Relación de muchos a muchos con 3 claves foráneas
Estoy a punto de crear una aplicación Java (con Spring Boot y React en el front) que simula un banco y, para almacenar los datos, he elegido PostgreSQL como mi sistema de gestión de bases de datos. Este proyecto es solo con fines de estudio.
La aplicación permitirá al usuario:
- crear una cuenta;
- realizar operaciones bancarias (como simular depósitos y transferencias a otra cuenta);
- verificar su propio estado de cuenta;
- verificar el historial de transacciones.
Estoy creando toda la aplicación desde cero y estaba modelando los datos, cambiando de un modelo de datos lógicos a uno físico, cuando me encontré con este problema (soy nuevo en Stack Overflow, por lo que no se me permite publicar una imagen directamente):
La entidad “Transaction” se refiere a dos cuentas, porque en el mundo real una transacción se realiza desde una cuenta (idCuentaOrigen) hacia otra (idCuentaDestino). Y al igual que en el mundo real, una cuenta puede realizar muchas transacciones y una transacción involucra obligatoriamente dos cuentas (origen/destino).
El principal problema es que, en una relación N:M, necesitamos crear una tabla intermedia para romper la relación N:M. En este caso, “Account_Transaction” tendría dos claves foráneas de “Account”, lo cual no rompe correctamente la relación N:M, como se muestra en la imagen:
¿Estoy modelando incorrectamente este problema? ¿Qué puedo hacer para resolver esto?
PD: He buscado en Internet y no he encontrado un modelo que tenga sentido con la realidad (como una entidad “Transaction” con solo una “idCuenta”).
ACTUALIZACIÓN: ¿Es este un enfoque posible?
davy.ai
Como experto en TI especializado en SQL, claves foráneas, relaciones de muchos a muchos y modelado de datos, creo que la solución propuesta de crear una tabla intermedia llamada Account_Transaction con dos claves foráneas de la tabla Account no es el mejor enfoque para romper la relación N:M entre cuentas y transacciones en este escenario.
En su lugar, recomiendo crear una nueva tabla llamada Transaction_Account que tenga tres columnas: una clave primaria de autoincremento, una clave foránea a la tabla Account para la cuenta de origen (idSourceAccount) y una clave foránea a la tabla Account para la cuenta de destino (idDestinationAccount). Esta tabla intermedia romperá adecuadamente la relación N:M y permitirá que varias transacciones involucren las mismas cuentas.
El modelo de datos lógico actualizado presentado en la imagen “Modelo Lógico Alternativo” parece ser una solución adecuada. Las entidades Transaction y Transaction_Account se pueden implementar como una relación uno a muchos, ya que cada transacción puede involucrar múltiples cuentas. La entidad Account puede permanecer como una entidad independiente, ya que solo se relaciona con Transaction_Account a través de claves foráneas.
Con este modelo de datos, debería poder almacenar los datos de manera precisa, realizar operaciones bancarias y permitir a los usuarios verificar su propio estado de cuenta y verificar su historial de transacciones de manera segura y eficiente.