В примере по ссылке на википедии - представьте, что у вас есть таблица с ресторанами, таблица с видами пиццы и таблица с районами доставки. Теперь Вам надо заложить в схему БД объекты для указания: а) в каком ресторане какой вид пиццы производят и б) из какого ресторана в какой район можно доставить. В примере рассмотрены 2 варианта - 1) таблица с полями (ид_ресторана, ид_вида_пиццы, ид_района_доставки) и 2) две таблицы, одна с полями (ид_ресторана, ид_вида_пиццы) и вторая с полями (ид_ресторана, ид_района_доставки) - и описано, почему первый вариант не в 4НФ. Суть в том, что при первом варианте реализации в БД возможны случаи, когда какие-то из ресторанов одни виды пицц могут поставлять в определенный районы, а другие виды пицц - не могут. Кроме этого, при добавлении нового вида пиццы, мало создать 1 элемент таблицы в справочнике и 1 элемент в таблице связи, а надо сделать это для всех районов доставки. И далее рассматривается другой случай, когда цена пиццы определяется как функция от ресторана, вида пиццы и района доставки (видимо. в этом примере стоимость доставки включена в стоимость пиццы). Вот для этого случая, из-за наличия функциональной зависимости, таблица с ценами будет иметь альтернативный ключ из трех полей как в примере 1) и этого уже не будет нарушением 4НФ.
Вы можете не использовать первичные составные ключи. Однако, более-менее сложная система скорее всего будет иметь сущности с составными альтернативными ключами - если такой ключ не сделать, возможны логические дубли, составной альтернативный ключ в виде констрейна или уникального индекса убережет от этого. Например, когда в таблице связи ресторанов и видов пиццы будут 2 или более строки с одинаковым набором значений (ид_ресторана, ид_пиццы).
Средний
