Ayuda con ejercicio base de datos (DED)

[derrator]

Buenas, les planteo el siguiente ejercicio, me pide un diagrama de estructura de datos:

1. UNA EMPRESA DEDICADA A LA FORMACIÓN-RESTAURACIÓN (ENSEÑANZA-COCINA; ESCUELA DE HOSTELERÍA) DESEA INFORMATIZAR SU SISTEMA DE INFORMACIÓN, SE HA EFECTUADO UNA ENTREVISTA Y HAN APARECIDO LOS SIGUIENTES DOCUMENTOS:
LISTADO DE COCINEROS:
NIF/NOMBRE Y APELLIDOS/TELÉFONO DE CONTACTO/NOMBRE DEL RESTAURANTE
LISTADO DE RECETAS:
NOMBRE DE LA RECETA /TIPO DE RECETA/COMPOSICIÓN:
           INGREDIENTE 1/CANTIDAD/
           INGREDIENTE 2 /CANTIDAD .......
           TIEMPO/ORDEN.......... (LO MISMO PARA N RECETAS).
LISTADO DE RESTAURANTES:
NOMBRE/DIRECCIÓN/TELÉFONO
LISTADO DE MENÚS (RECETAS):
NOMBRE DEL RESTAURANTE/NOMBRE  DEL PLATO (DE LA RECETA)/PRECIO.
ALMACÉN COMÚN A TODOS LOS RESTAURANTES:
NOMBRE DE INGREDIENTE/EXISTENCIAS/NIF DEL PROVEEDOR
LISTADO DE PROVEEDORES:
NIF DEL PROVEEDOR/NOMBRE DEL INGREDIENTE QUE SUMINISTRA/TELÉFONO
LISTADO DE RESTAURANTES POR CIUDADES:
CIUDAD 1: NOMBRE RESTAURANTE 1......NOMBRE RESTAURANTE N.
..............................
CIUDAD N:.........................................
REGLAS DE GESTIÓN:
•   EN UNA CIUDAD HAY MÁS DE UN RESTAURANTE.
•   UN COCINERO PUEDE TRABAJAR EN MÁS DE UN RESTAURANTE.
•   UNA MISMA RECETA (PLATO) PUEDE ESTAR EN MÁS DE UN RESTAURANTE.
•   UN MISMO INGREDIENTE PUEDE ESTAR EN MÁS  DE UNA RECETA.
•   UN INGREDIENTE SOLO ES SUMINISTRADO POR UN PROVEEDOR, PERO ESTE PUEDE SUMINISTRARNOS MÁS DE UN INGREDIENTE.

Estoy repasando para un examen y este ejercicio se me a atrancado... :S si me pueden ayudar se lo agradeceria. Un saludo y muchas gracias de ante mano

[Serapis]

La ayuda no es correcta proporcionarla sin saber como te va a ayudar.

Mejor indica como tienes pensado aocmeterlo y desde ahí se ve si el enfoque que llevas es válido, correcto, tiene defectos, qué fallos o complejidades te encontrarás, etc...

Cuéntanos, tu enfoque primero, así la ayuda será precisa y no genérica.

[derrator]

Pues yo lo tengo hecho así, pero no estoy seguro si esta bien, asi que como varias cabezas piensan mejor que una... opiniones?

https://gyazo.com/5f3c3ec3c1076c7cf33929e9e48afa1b

[Serapis]

No está mal, pero no acabas de ceñirte a las especificaciones que te han dado.

Por ejemplo, para los cocineros se especifica esto:

Código [Seleccionar] Expandir

LISTADO DE COCINEROS:
NIF/NOMBRE Y APELLIDOS/TELÉFONO DE CONTACTO/NOMBRE DEL RESTAURANTE
Pero luego en el diagrama para los cocineros, no especificas restaurante (dodne trabaja)
Entonces el cocinero debería tener un campo "Foreign Key Cod_Restaurante", en el que el cocinero opera. Ahora mismo si miras un cocinero, no sabes donde trabaja.

Del mismo modo te faltan listas.... más simples una lista es una tabla con un solo campo , por ejemplo te falta una lista de cocineros, de restaurantes, de menús... así yo modificaría tu tabla de "Menus"

Código [Seleccionar] Expandir

TblMenus
________
Primary Key Id_Menu

Y luego tienes otra tabla de detalles de cada menú:

Código [Seleccionar] Expandir

TblMenuDetalles
_______________
Foreign Key Id_Menu
    Nombre
    NumIngredientes
    Ingredientes()
    RacionGr // peso aprox. en gramos por cada ración.
    Precio
    Descuento // opcional  
    InfoNutricional: (Calorías, Proteínas, Grasas, Azúcares) conforme a RacionGr
    ______________

Cuando de un dato hay muchos, creas una lista (una tabla de Ids (códigos), que referencian luego a otra tabla con todos los detalles que se precisen.
Así la tabla para buscar es muy rápida y sencilla y una vez encontrado el código, se usa para ir a al tabla de detalles (si se precisa tomar más info que sólo la existencia).

- De igual modo habría que proceder con la tabla cocineros, dividiéndola en dos, en una solo la lista de códigos de cocineros y en otra los detalles de cada cocinero.
- Lo mismo con la tabla restaurantes, una tabla sólo con los códigos y otra con los detalles de cada uno.
- Ídem con los proveedores.
- Como también te piden restaurantes por ciudades:
puedes tener, el campo Ciudad en la tabla tblRestaurantesDestalles.

En cambio las recetas, salvo que un mismo menú tenga diferentes recetas (y esto suceda con muchísimos menús), yo la descartaría. En su caso ese sería un campo en la tabla tblMenuDetalles.
Ingredientes() es un array, dentro de menús que podría referenciarse conforme al campo NumIngredientes, cada Ingrediente puede disponerse como una pareja de campos, para otra tabla:

Código [Seleccionar] Expandir

tblIngredientesMenu
________________
PK Cod_Menu
Producto
Cantidad
Incluso podría ponerse un tercer campo: un FK Cod_Menu, para saber en qué menú aparece este ingrediente en esa cantidad... No obstante quizás sea demasiado detallar si no se ha especificado expresamente, pero la menos si lo siguiente:

Donde producto es Cod_Producto (ó Cod_Ingrediente).
La razón de esto, es que con ello se puede al mismo tiempo llevar la cuenta de existencias y consumo de ingredientes y por tanto facilitar hacer un pedido cuando esté próximo a agotarse...

Por tanto te faltaría también dos tablas:

Código [Seleccionar] Expandir

tblIngredientes
_______________
Pk Cod_Ingrediente


tblIngredientesDetalles
____________________
FK  Cod_Ingrediente
Fk  Cod_Proveedor
    CantidadStock  //Cantidad que queda en el almacén
    CantidadPedido  // cantidad que se suele pedir de cada vez (kg, cajas, palets, camiones).
    CantidadReserva // Cantidad mínima que cuando se alcanza (o menos) dispara un trigger, para hacer el pedido.
    PrecioKg  // precio aprox. porkg. para facilitar hechar cuentas sobre costes al ahcer un pedido. sería un dato a actualizar constantemente con cada nuevo pedido 8probablemente).
    DetallesIngrediente //un string que defina el ingrediente de modo básico.


y bueno, mirándolo así por encima básicamente esa es la idea... pero no lo tienes mal, aunque se puede mejorar en la forma indicada...

[derrator]

Muchisimas gracias! Me ha servido bastante . Un saludo