Your question's phrasings are not clearly using technical terms so it's not clear what exactly your expectations are or why. But that seems moot if you just reason from the basics below.
there should not be any relationship between the attributes CustomerInvoiceID and SupplierInvoiceID
In the relational model relation(ship)s/associations are represented by relations. From Codd's original 1970 paper:
The relation depicted is called component. [...] The meaning of component(x, y, z) is that part x is an immediate component (or subassembly) of part y, and z units of part x are needed to assemble one unit of part y.
Your 1NF table Shop already represents a relationship on CustomerInvoiceID, SupplierInvoiceID, etc. It holds rows that make a true statement (proposition) from a statement template ((characteristic) predicate) something like:
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
In your quoted phrase you are maybe trying to capture some kind of impression that the sets of supplier invoice ids & customer invoice ids are in some sense independent. And in some sense they are. But in another sense they are not: we can imagine a business rule that invoice ids are constrained such that customer invoices involve products that supplier invoices involve. Certainly ids are so constrained in this relationship/table. Regardless of what precise definitions & claims one might produce to address such ideas, normalization to higher NFs (normal forms) is just producing relationships/tables from given ones. Component relationships are certain transformations of conjuncts of original relationships. (Sometimes logically equivalent to the conjuncts themselves.) Not knowing that a component represents a relationship & what it is may be why 2NF/3NF Shop seems odd to you.
when moving from 1 NF to 2 NF, a table is created to maintain a relationship between the Primary Keys from 1 NF
Normalization to higher NFs replaces a table by others that are projections of it that natural join back to it. It involves FDs (functional dependencies) & CKs (candidate keys). Not PKs (primary keys) per se--a PK is just some CK you decided to call "PK". Normalization "maintains" the original relationship in that that relationship is expressible as the conjunction/AND of the components' relationships & is represented by their natural join.
Your 1NF design is not capable of recording re products, suppliers or customers not invoiced. You might discover that fact while normalizing to higher NFs--but normalization to higher NFs does not eliminate such problems (update & deletion anomalies)--despite (poor) presentations saying that it does. Also it only records re products that appear in both some supplier invoice & some customer invoice. That may be why it seems odd to you. Starting with a single table on all those attributes is not part of a good information modeling method. 2NF/3NF Shop is a product of a correct normalization, but not from a "good" original.
It is also not from a "good" normalization. In general there is more than one decomposition to a NF. We use some proven algorithm(s) with pros & cons, and we may still have to decide which among multiple decompositions we prefer. We do not normalize to a given NF by going through lower NFs--despite (poor) presentations saying that we do. Here you chose a 2NF design with component Shop--but then when you chose further components, component Shop became redundant--it's a projection of the natural join of other components. That may be why it seems odd to you.
Re the relational model, database design & normalization.
Is there any rule of thumb to construct SQL query from a human-readable description?
PS "0NF" & "1NF" have no fixed meaning.
PS Re 2NF/3NF Shop
A component is a projection of an original. It is rows where its columns form a subrow of the original. So it is rows where there exist values for the other columns so that the component column values & other column values form a row in the original. That's the same as saying that the component's relationship is a FOR SOME or THERE EXISTS on the other columns applied to the original's relationship.
Assuming & repeating the expression above for 1NF Shop's relationship, 2NF/3NF Shop represents the following relationship:
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
]
Ie rows where:
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
Assuming that products have descriptions, that suppliers & customers have names & that an invoice bills a product in some quantity or quantities, this is rows where:
invoice SupplierInvoiceID bills for product ProductID
AND invoice CustomerInvoiceID bills for product ProductID
Those are the rows returned by the projection on the 3 attributes of 1NF Shop. If we have as bases/components a table for every conjunct I gave for the 1NF Shop predicate--the tables of your 3NF design--or the tables of your 2NF design, then, in the sense that you can thus query for those rows, 2NF/3NF Shop is redundant as a base/component.
