我有一个关于数据库建模的任务，我必须为商店建模数据库。当从0NF标准化为3NF时，我最终得到一个表，其属性似乎并不相关。
注意
根据我用作参考的书籍和资源，当从1NF移动到2NF时，创建一个表来维持1NF的主键之间的关系（这里，Shop表假定这个工作）。但是，从逻辑角度来看，CustomerInvoiceID和SupplierInvoiceID属性之间不应存在任何关系。
你的问题的措辞并没有明确地使用技术术语，因此不清楚你的期望是什么或为什么。但是，如果你只是从下面的基础知识推理，这似乎没有实际意义。
CustomerInvoiceID和SupplierInvoiceID属性之间不应该存在任何关系
在关系模型关系（船）中，s /关联由关系表示。来自Codd's original 1970 paper：
描述的关系称为组件。 [...]组件（x，y，z）的含义是部分x是部分y的立即组件（或子组件），并且需要部分x的z个单元来组装部分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
在您引用的短语中，您可能试图捕获某种形式的供应商发票ID和客户发票ID在某种意义上是独立的印象。从某种意义上说，他们是。但从另一个意义上说，它们不是：我们可以设想一个业务规则，即发票ID受到限制，以致客户发票涉及供应商发票涉及的产品。当然，在这种关系/表格中，ID是如此受限制。无论为解决这些想法可能产生什么样的精确定义和主张，对更高NF（正常形式）的归一化只是从给定的关系/表格中产生关系/表格。组件关系是原始关系的合并的某些转换。 （有时在逻辑上等同于合取本身。）不知道某个组件代表一种关系及其含义可能就是为什么2NF / 3NF Shop对你来说很奇怪。
当从1 NF移动到2 NF时，创建一个表以维持1个NF的主键之间的关系
归一化到更高的NF会将一个表替换为其自然联接回来的其他人的表。它涉及FD（功能依赖）和CK（候选键）。不是PK（主键）本身 - PK只是你决定称之为“PK”的CK。规范化“维持”原始关系，因为该关系可表示为组件关系的连接/ AND，并由其自然连接表示。
您的1NF设计无法记录未开具发票的产品，供应商或客户。您可能会发现这一事实，同时归一化为更高的NF - 但归一化到更高的NF并不能消除这些问题（更新和删除异常） - 尽管（差）演示文稿说它确实如此。此外，它仅记录出现在某个供应商发票和某些客户发票中的重新产品。这可能就是为什么你觉得这很奇怪。从所有这些属性上的单个表开始不是良好信息建模方法的一部分。 2NF / 3NF Shop是正确标准化的产物，但不是来自“好”原件。
它也不是来自“良好”的正常化。通常，对NF的分解不止一次。我们使用一些经过验证的优点和缺点的算法，我们可能仍然需要决定我们喜欢多个分解中的哪一个。我们没有通过较低的NF来规范化给定的NF - 尽管（差）演示说我们这样做。在这里，您选择了带有组件Shop的2NF设计 - 但是当您选择其他组件时，组件Shop变得多余 - 它是其他组件的自然连接的投影。这可能就是为什么你觉得这很奇怪。
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商店
组件是原件的投影。它是行，其列形成原始的子行。因此，存在其他列的值的行，以便组件列值和其他列值在原始列中形成一行。这就像说组件的关系是应用于原始关系的其他列上的FOR SOME或THERE EXISTS一样。
假设并重复上述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
这些是1NF Shop的3个属性上的投影返回的行。如果我们为1NF Shop谓词 - 3NF设计的表格 - 或2NF设计表格的每个合取作为基础/组件的表格，那么，您可以因此查询这些行，2NF / 3NF Shop作为基础/组件是多余的。