Para el primer caso, tienes que crear una tabla intermedia de préstamos entre Libros y Lectores, que debe “robarse” las claves del libro (CODLIB) y la del lector que no se ve, pero que debería haber un Lector_ID para identificar unívocamente cada lector, pues como está, tiene es NOMLECTOR como clave y no es lo más adecuado, porque podrían haber homónimos.
Para el segundo caso, tienes que crear una tabla intermedia de matriculados o matricula como la quieras llamar, que será una intermedia entre el alumno y el curso y que debe “robarse” las claves del curso (CODCUR) y la del alumno (CODALU).
Para el tercer caso, tienes que crear una tabla intermedia entre ordenes y clientes, es decir, un detalle de esa orden que es donde se especifican las cantidades de productos adquiridos, ese detalle de orden debe tener como llaves foráneas las claves del cliente (Id_Cliente) y de la orden o pedido general como tal (id_Orden).
La clave para normalizar una BD, está en detectar aquellos atributos que pueden adquirir más de un valor para un mismo registro, y en caso de darse, es porque faltan estructuras por crear y que normalicen adecuadamente, por lo menos llevar hasta 3FN; se puede incluso normalizar hasta 4 y 5 FN, pero eso depende de que escenario se esté modelando y amerite evitar redundancia de información más allá de 3FN, y en cuyo caso puede traer problemas de rendimiento, a la hora de extraer información dada la cantidad de joins que habría que efectuar. Para este caso no le veo necesario y con llevarle hasta 3FN es más que suficiente.
