Cita: ya que la forma en la que creé el diagrama E/R fue diseñando una jerarquía entre PROVEEDOR como supertipo y GAS, ALIMENTOS, MEDICINAS y ROPA como subtipo.
Gas, Alimentos y Ropa
no pueden ser jamás "subtipos" de Proveedor. Eso no tiene sentido.
Por lo pronto, no existe la clasificación de "subtipos" en BBDD, al menos como concepto de clase. Son herencias de entidades jerárquicas, pero en una estructura de herencia, las entidades hijas deben forzosamente ser una especialización de la entidad padre. SIEMPRE.
Y no es posible establecer desde Proveedor una especialización que te de como resultado Gas, Ropa o Alimentos. Es imposible. Simplemente no es racional.
En todo caso los tres componentes mencionados son hijos de otra entidad, llámale "provisión", "abastos", o como quieras. Pero es esa otra entidad la que se relaciona con Proveedor.
¿Se entiende?
Con una entidad "Abastos", por ejemplo, sí puedes establecer una especialización de ese tipo.
Luego de eso, obtienes la relacion entre proveedor y compras. Esa relación es N:M porque un mismo tipo de abasto o producto puede ser provisto por N proveedores, y cada proveedor puede proveer N tipos de productos o subproductos.
De todos modos, el modelo queda incompleto, porque si existen proveedores, hay que consiuderar que:
1) Cada proveedor debe recibir una orden de pedido.
2) Cada proveedor entrega facturas, remitos y emite recibos por los pagos.
3) La Prisión debe tener asentado en algula parte qué facturas de que proveedor debe abonar, y cuando.
4) Los remitos de los proveedores deben ingresar como compras realizadas en alguna parte.
5) Cada ingreso de provisiones debe ser asentada en fecha de ingreso y cantidad.
6) Los tipos de producto pueden tener fechas de vencimiento, por lo que hay que considerar qu eal ser usadas la lógica de stock puede ser FIFO o LIFO. De acuerdo a eso se deben resolver procesos y datos.
Todo esto y mucho mas debe ser relevado, o planteado como supuestos asumidos antes de diseñar la solución. Y deben quedar escritos.
Otros detalles:
La relación entre Proveedor y Prision sí puede ser 1:1 mirada desde el proveedor, pero es 1:N desde la optica de la Prisión, por lo que la tabla Proveedor contiene la FK de Prisión.
El hecho que haya una sola Prisión en la isla es irrelevante. De todos modos a nivel de diseño se exige que exista la entidad Prisión, aunque tenga un solo registro.