Хитрость заключается в том, чтобы думать о FD как об определяющих ключах, не в вашей заданной схеме, а в ее ПРОЕКТАХ.
Например, в вашей стартовой схеме {ABCDE} FD A -> BC говорится, что A ({A}, фактически) представляет собой ключ в этой таблице, спроецированный до {ABC}. Таким образом, объединение LHS и RHS FD определяет, какая проекция, а LHS определяет ключ в этой проекции.
Теперь перейдем к разложенной версии, в которой у вас есть две отдельные таблицы (схемы) {ABC} и {ADE}.
Ваш первый и последний FD все еще можно выразить в этих схемах. Первый FD в первой схеме / таблице и последний в последней.
Но остальные два стали невыразимыми (то есть невыразимыми AS FD , то есть) из-за разложения. Для всего проекта базы данных это означает, что вам придется объявить / определить / реализовать ограничение базы данных, которое говорит и делает то же самое, что и исходный FD. (Общий рецепт для этого заключается в следующем: воссоздать исходную таблицу, снова объединив декомпозиции, спроектировать, объединяющий упомянутые атрибуты, и применить ключ к этой проекции. Достижение этого не совсем будет тривиальным для таких случаев, как эти упражнения курса.)
Решение о том, находятся ли R1 / R2 в xNF, теперь должно быть сделано с учетом только тех из оригинальных FD, которые все еще выразимы (a-> BC).
Полагаю, вам следует прийти к выводу, что R1 находится в 3 / BC NF, а R2 все еще нет.
Примеры, подобные этим (и большинство курсовых упражнений такого рода) на самом деле иллюстрируют, насколько нелепо переоценено понятие нормализации в области проектирования баз данных. Важна общая картина, включающая ALL ограничения, применимые к базе данных.