andy.s, продолжайте использовать корректное сокращения - значительно упрощает общение :)

С вашей подачи уже имеем pages, page_types

andy.sДобавляем таблицу, где будут хранится файлы (имя, размер и прочее).
files

andy.s Теперь добавляем еще одну таблицу, где будут хранится группы файлов: (id группы, id типа страницы, название группы).

Не "группы файлов", а "виды групп файлов на конкретных типах страниц": file_group_types (_for_page_types - но это уж слишком длинно).

Ещё раз, file_group_types - потому что это не группы конкретных файлов, а именно названия (типы, виды) для групп файлов в зависимости от типа страницы.

andy.sНо что делать с таблицей самих файлов?
Получается, что там нужны как id страницы, так и id группы, в которой этот файл на этой странице находится. Тогда никто не запрещает добавить запись с такими значениями этих полей, при которых эти id соответствуют разным типам страниц (группа 1->тип страницы 1 + страница 8->тип страницы 2).
В чём тут фокус? Вроде пытался рассуждать логически, а получилась какая-то, простите, хрень :D

а хрень тут в том, что у вас в таблицах "file_groups" и "pages" по привычке суррогатные первичные ключи из одного идентификатора.
А атрибут "ид типа страницы - page_types.id..." мог бы являться частью первичного ключа для этих таблиц "file_groups" и "pages".
И тогда при проектировании таблички files вы бы завели просто два внешних ключа на:
pages (id_page, id_page_type)
file_group_types(id_fgtype, id_page_type)
и у вас бы образовалось в files три атрибута: id_page, id_fgtype, id_page_type. То что id_page_type - это одно и то же поле, и гарантировало бы вам отсутствие херни в виде возможности "добавить запись с такими значениями этих полей, при которых эти id соответствуют разным типам страниц"...
Т.е. чтобы у вас в таблице files не возникло ошибки, напрямую связанной с типом страницы, нужно: внести этот атрибут "тип страницы" в таблицу и внешними ключами обеспечить контроль заполнения этого поля.

Ещё варианты:
1. НЕ обязательно заводить сложные первичные ключи, можно завести дополнительные альтернаивные ключи, оставив суррогатные.
2. Не заводить атрибут и обеспечить целостность триггерами, которые лазят в pages и file_group_types и сверяют совпадение в них id_page_type.
3.
andy.sТеперь при добавлении страницы какого-то типа можно сразу вывести названия групп, в которые можно добавить файлы.

Можно "вывести", а можно завести таблицу "file_group_types_on_page" (ид страницы, ид типа группы файлов) - группы файлов на конкретной странице. Поскольку формируете автоматически - сами решайте, хотите ли контролировать со стороны БД корректность этого добавления. Если хотите, то история та же, что и вашего первого варианта...
теперь при добавлении файлов вы их связываете с конкретной записью file_group_types_on_page.

П.С.: Рисуйте схему при проектировании - помогает разобраться даже в трёх соснах...

andy.s, вы не всё поняли.
пусть остаётся суррогатное поле (id_gt_type). Оно кстати может и не быть суррогатным, а трансформироватья в поле "number_for_sort"
Варианты:
1) или сделайте первичным ключом (id_gt_type, id_page_type) - при этом будет ли id_gt_type уникальным в пределах id_page_type, или уникальным по всей таблице - ваше дело...
2) или оставьте первичным ключом (id_gt_type) и сделайте альтренативный ключ (id_gt_type, id_page_type).

Ключ (первичный или альтернативный) нужен только для того, чтоб на него можно было сослаться внешним ключом из files....