Cita:
Iniciado por gnzsoloyo 
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.
Si algo me quedaba claro es que una tabla con los datos de la PRISIÓN debía existir, aunque solo exista un registro, si no deja de tener sentido toda la BD.
Por lo pronto he añadido datos a las tablas conforme a lo que has dicho, los datos de albarán, las fechas de vencimiento, recibos, incluyendo la FK de la PRISIÓN en PROVEEDORES...
Si no me equivoco son los del departamento de contabilidad los que emiten los recibos, mientras que los datos de albarán pueden incluirse dentro de una tabla tipo ALMACENAJE o cualquier otro nombre más conveniente. Es decir, lo recomendable es crear tablas para recibir los datos de los envíos y ligarlos con FK a la tabla PROVEEDORES o ABASTOS.
También he normalizado algunas tablas que tenían exceso de columnas que, tal y como se explica en la normalización, es necesario crear más tablas con FK ligadas a ellas para no saturar de datos una sola tabla.
Pero voy a aprovechar que tengo contactos en una Prisión por mi zona y a preguntarle varias cosas, o quizás me sea más conveniente ir y ver cómo se organiza todo... Si no, al final voy a terminar creando una BD incompleta.
Gracias por la información.