В формулировках вашего вопроса явно не используются технические термины, поэтому неясно, каковы именно ваши ожидания и почему. Но это кажется спорным, если вы просто исходите из приведенных ниже основ.

не должно быть никакой связи между атрибутами CustomerInvoiceID и SupplierInvoiceID

В реляционной модели отношения/ассоциации представлены отношениями. Из исходной статьи Кодда 1970 года:

Изображенное отношение называется component. [...] Значение component(x, y, z) состоит в том, что часть x является непосредственным компонентом (или составной частью) детали y, и z единиц детали x необходимы для сборки одной единицы части y.

Ваша таблица 1NF Shop уже представляет отношение для CustomerInvoiceID, SupplierInvoiceID и т. д. Она содержит строки, которые составляют истинное утверждение (предложение) из шаблона заявления ((характеристика) предикат) примерно так:

    product ProductID is described as ProductDesc
AND supplier SupplierID is named SupplierName
AND invoice SupplierInvoiceID is from supplier SupplierID
AND invoice SupplierInvoiceID bills for QtyBought of product ProductID
AND customer CustomerID is named CustomerName
AND invoice CustomerInvoiceID is to customer CustomerID
AND invoice CustomerInvoiceID bills for QtySold of product ProductID

В вашей цитируемой фразе вы, возможно, пытаетесь создать какое-то впечатление, что наборы идентификаторов счетов-фактур поставщиков и идентификаторов счетов-фактур клиентов в некотором смысле независимы. И в каком-то смысле они есть. Но в другом смысле это не так: мы можем представить себе бизнес-правило, согласно которому идентификаторы счетов-фактур ограничены таким образом, что счета-фактуры клиентов включают продукты, которые включают счета-фактуры поставщиков. Конечно, идентификаторы настолько ограничены в этой связи/таблице. Независимо от того, какие точные определения и утверждения можно было бы привести для решения таких идей, нормализация к более высоким НФ (нормальным формам) просто создает отношения/таблицы из заданных. Компонентные отношения — это определенные преобразования конъюнктов исходных отношений. (Иногда это логически эквивалентно самим конъюнктам.) Незнание того, что компонент представляет отношение и что это такое, может быть причиной того, что 2NF/3NF Shop кажется вам странным.

при переходе с 1 НФ на 2 НФ создается таблица для поддержания связи между Первичными Ключами из 1 НФ

Нормализация к более высоким NF заменяет таблицу другими, которые являются ее проекциями, которые естественным образом присоединяются к ней. Он включает в себя FD (функциональные зависимости) и CK (ключи-кандидаты). Не PK (первичные ключи) как таковые - PK - это просто некоторый CK, который вы решили назвать "PK". Нормализация «поддерживает» исходное отношение в том смысле, что это отношение выражается как соединение/И отношений компонентов и представлено их естественным соединением.

Ваш проект 1NF не может регистрировать продукты, поставщиков или клиентов, которым не выставлены счета. Вы можете обнаружить этот факт при нормализации к более высоким NF, но нормализация к более высоким NF не устраняет такие проблемы (аномалии обновления и удаления) — несмотря на (плохие) презентации, в которых говорится, что это происходит. Кроме того, он записывает только те продукты, которые указаны как в счете-фактуре поставщика, так и в счете-фактуре клиента. Возможно, поэтому вам это кажется странным. Использование одной таблицы для всех этих атрибутов не является частью хорошего метода информационного моделирования. 2NF/3NF Shop - продукт правильной нормализации, а не "хорошего" оригинала.

Тоже не от "хорошей" нормализации. В общем случае существует более одного разложения НФ. Мы используем некоторые проверенные алгоритмы с плюсами и минусами, и нам, возможно, все же придется решить, какой из множества декомпозиций мы предпочитаем. Мы не нормализуем данную НФ, проходя через более низкие НФ, несмотря на то, что в (плохих) презентациях говорится, что мы это делаем. Здесь вы выбрали дизайн 2NF с магазином компонентов, но затем, когда вы выбрали другие компоненты, магазин компонентов стал избыточным — это проекция естественного соединения других компонентов. Возможно, поэтому вам это кажется странным.

Реляционная модель, дизайн базы данных и нормализация.
Есть ли какое-нибудь эмпирическое правило для создания SQL-запроса из описания, понятного человеку?

PS "0NF" и "1NF" не имеют фиксированного значения.

PS Re 2NF/3NF Магазин

Компонент — это проекция оригинала. Это строки, в которых его столбцы образуют подстроку оригинала. Таким образом, это строки, в которых существуют значения для других столбцов, так что значения столбцов компонентов и другие значения столбцов образуют строку в оригинале. Это то же самое, что сказать, что отношение компонента является ДЛЯ НЕКОТОРЫХ или СУЩЕСТВУЕТ в других столбцах, применяемых к исходному отношению.

Предполагая и повторяя приведенное выше выражение для отношений 1NF Shop, 2NF/3NF Shop представляет следующие отношения:

FOR SOME values for ProductDesc,
    SupplierID, SupplierName, QtyBought,
    CustomerID, CustomerName & QtySold
    [   product ProductID is described as ProductDesc
    AND supplier SupplierID is named SupplierName
    AND invoice SupplierInvoiceID is from supplier SupplierID
    AND invoice SupplierInvoiceID bills for QtyBought of product ProductID
    AND customer CustomerID is named CustomerName
    AND invoice CustomerInvoiceID is to customer CustomerID
    AND invoice CustomerInvoiceID bills for QtySold of product ProductID
    ]

Т.е. строки, где:

    product ProductID is described as something
AND some supplier is named something
AND invoice SupplierInvoiceID is from that supplier
AND invoice SupplierInvoiceID bills for some quantity of product ProductID
AND some customer is named something
AND invoice CustomerInvoiceID is to that customer
AND invoice CustomerInvoiceID bills for some quantity of product ProductID

Предполагая, что у продуктов есть описания, у поставщиков и клиентов есть имена и что в счете-фактуре выставляется счет за продукт в определенном количестве или количествах, это строки, где:

    invoice SupplierInvoiceID bills for product ProductID
AND invoice CustomerInvoiceID bills for product ProductID

Это строки, возвращаемые проекцией на 3 атрибута магазина 1NF. Если у нас есть в качестве основы/компонента таблица для каждого конъюнкта, который я дал для предиката Магазина 1НФ, таблицы вашего проекта 3НФ или таблицы вашего проекта 2НФ, то в том смысле, что вы можете таким образом запросить для этих строк 2NF/3NF Shop является избыточным в качестве базы/компонента.