No está mal, pero no acabas de ceñirte a las especificaciones que te han dado.
Por ejemplo, para los cocineros se especifica esto:
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"
TblMenus
________
Primary Key Id_Menu
Y luego tienes otra tabla de detalles de cada menú:
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:
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:
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...